undefined | Better HN

0 pointsvalcron10002y ago0 comments

Very interesting article but I feel the need to question some things.

- The very first thing that comes to mind is why actually use Rust for gamedev. From the article it seems like the author got into Rust through Godot, but that does not explain why commit to use Rust for a full game. What was the reasoning behind picking Rust?

- It feels to me that there's a mix of criticism to Rust as a language, Rust as a community and libraries/frameworks written in Rust (in particular Bevy). Personally I think these are completely separated matters so I would like to know why the author treats them all as a unit.

- I've always got the impression that gamedevs try to have their cake and eat it too which is almost always impossible: they want to have quick iterations and write "simple code" while having low level control of everything (ex. manual memory management, usage of pointers, etc.). For example, the author mentions wanting access to methods like "play_sound()" but at the same time mentions that some patterns are unacceptable given the "overhead [...] due to memory locality". I've never heard of an ecosystem where you can have everything without any compromises.

- In particular, I get the impression that the author has a lot of troubles with ECS and instead it tries to bend it to work in a OOP fashion (for example, through the usage of "fat components" as he calls them or preferring virtual dispatch over `match` statements). He claims that he has put in a "lot of time" in trying to make it work but I get the impression that this effort was mostly wasted in trying to bend the language and libraries into something that just won't work out. It's like trying to use a circular saw to polish mechanical watch pieces: an exercise in frustration. At some point in time I'm sure he asked himself why to keep on pushing on, and I would like to know why he continued to be committed to such process.

- The author claims multiple times that they work in a single threaded environment where they should not care about concurrent access so they should not pay the price in the type system. I agree that this should be the case but then it proceeds to list examples that show a different situation. One of them is the claim that they cannot use a "god" context to pass down every dependency due to the borrow checker, listing code that tries to hold a reference to a "camera" system while passing the context to the "player" system. In particular this does not make sense because: 1) If you're in a single threaded environment you don't have two systems using the same context at the same time (because there is no "at the same time"); 2) if the "player" system does not need the camera then it won't change it, and if it does not change it then there is no need to take a reference to it earlier, you can just take it after the "player" system has finished. I know that coming up with brief examples is extremely difficult but either the example does not properly represent the reality, or the author is actually working in a multi threaded environment (maybe without actually knowing about it).

As an observation, the author mentions multiple times that Rust pushes you to write "good code" and I fundamentally disagree. "Good code" is very contextual, just like the idea of "simple code" where he checks for all collisions and plays a sound in 3 lines (is this actually "simple"?), so instead I would say that Rust forces you to write "correct code", that is, code that won't (or is unlikely to) fail at runtime. I believe this is a very important distinction that you always need to keep in mind when evaluating a tool such as a programming language.

Finally, I do believe though that Rust is a bad choice if what you're interested in is to build games quickly without consideration for performance (and you most likely don't need to care in 2d games) and their decision is very reasonable: C# and Unity are just aligned better with what the author is actually interested in doing.

0 comments

1 comments · 1 top-level

dragonwriter2y ago

I’ve only done a few toy projects using ECS, but the author seems to be struggling with ECS on a basic conceptual level. E.g.,

---quote---

For example, modelling Health as a general purpose mechanism might be useful in a simple simulation, but in every game I end up wanting very different logic for player health and enemy health. I also often end up wanting different logic for different types of non-player entities, e.g. wall health and mob health. If anything I've found that trying to generalize this as "one health" leads to unclear code full of if player { ... } else if wall { ... } inside my health system, instead of having those just be part of the big fat player or wall systems.

---end quote---

The solution here is to have a Health component but not a generic Health system (actually, a generic Health system sounds like a code smell for another reason, because systems map to actions, while components map to attributes; systems that interact with a Health component would be things like a damage or healing system) -- but if you need something to work different for player health and wall health and enemy health, you can just have three systems, which, respectively, do Query<Player, Health>, Query<Enemy, Health>, Query<Wall, Health>.

j / k navigate · click thread line to collapse