Comment by pcwalton
9 months ago
> And my other biggest problem is that they keep painting other non-Rust things as being fundamentally flawed for not being Rust. "It's not memory safe" is the biggest one thrown around, but when was the last time memory safety was actually a big problem in games? Unity uses C# which is garbage collected, Godot uses its own scripting language which makes it nigh impossible to leak memory, Unreal AFAIK has its own tools that makes memory management trivial. Rust game development feels like a solution looking for a problem to fix.
Memory safety may or may not be important in games, but the ability of engines like Bevy to analyze system dependencies and automatically scale to multiple CPUs is a big deal. Job queuing systems have been popular in gamedev for a very long time, and Rust's insistence on explicit declaration of mutability is a big part of the reason that "just works" in Bevy.
> but the ability of engines like Bevy to analyze system dependencies and automatically scale to multiple CPUs is a big deal
Is it? The article addresses that, and basically calls it a pointless feature that is almost never used and when it is the benefits are mostly lost because of real world needs and constraints, and that the problems it solves are easier solved through other solutions and add-on systems that are well understood.
I think this might be a case where explaining the real-world benefit instead of the theoretical benefit is needed, if only to counter what are very pointed criticisms that are definitely deeper than at the theoretical level.
Here's a trace of a Bevy demo: https://i.imgur.com/oXUxC2h.png
You can see that all the CPUs are being maxed out. This actually does result in significant FPS increases. Does it matter for every game? No. But it does result in better performance!
>> but the ability of engines like Bevy to analyze system dependencies and automatically scale to multiple CPUs is a big deal
>> Is it? The article addresses that, and basically calls it a pointless feature
> You can see that all the CPUs are being maxed out.
You're missing the forest for the trees - the poster above basically said "seeing all the CPUs being maxed out is a pointless feature" and you reply with "but see, all the CPUs are being maxed out".
You're literally ignoring the complaint and replying with marketing.
5 replies →
The problem is that most of the gameplay code is linear, and people have already gotten good at splitting parallel work across threads. Serious physics engines (see jolt) are already designed to run on another thread and distribute the work across multiple cores. The main part of graphics drivers when using opengl or vulkan run on another thread and the UI you access just passes data to it. Rust's parallelism hasn't proven to be faster than C/C++, let alone less annoying to achieve.
4 replies →
The context of this article, and my comment, is game development. Not game performance or engine optimization, which while related seem like related but smaller aspects of the overall topic.
The way I interpret the claims is that bevy is putting far too much focus on performance and multi-threading when by far the important thing to focus on for game development is allowing the actual game developers to rapidly iterate.
Bevy might be very fast and performant, but if that seems to have come at the cost of (or been optimized for over) features that make it easier to use in ways that game developers need, then the criticism may have merit. Whether that's true or not I don't know, but hopefully that explains why a response about how it definitely can use lots of threads and make good use of many cores isn't really seen as a good rebuttal to the criticisms leveled.
That makes no difference if the game is boring.
2 replies →
It's a good feature, but still a niche one. It's a bit like choosing Unity only because of DOTS. For a few projects perhaps it make sense. But just a few ones.
Nobody said that every game needs that level of performance. But saying that it's a solution looking for a problem is not true.
I'm fully in favor of having Bevy support dynamic languages, as implemented in for example bevy_mod_scripting [1], for projects that don't need that parallel performance.
[1]: https://github.com/makspll/bevy_mod_scripting
Good scripting support is probably the way to go for Rust game development anyway in order to achieve high iteration/idea testing velocity. We could have a script engine that memory-manages various in-game objects and the scripts call into Rust functions to do the heavy lifting. Those Rust functions will typically take things by reference from the script engine so that memory-management is mostly a non-issue.
> automatically scale to multiple CPUs
We've been promised automatic CPU scaling in programming languages since at least 2001, and I've yet to see any practical version of it.