Bevy is one of those things that I've tried to use, but quickly realized why people believe that "rust is changing too quickly". Well the language doesn't but the libraries do.
It's changed quickly enough that docs, examples, copilot, agents, and chat assistants are all a few versions off from each other.
My only game dev experience is with Babylon.js, but I decided to give Bevy a shot a couple weeks ago. I gave up once I realized they don't have any sort of editor or scene inspector. Something as simple as seeing what assets are loaded into your scene is not possible with official tooling. Tried Unity, but was ultimately more complex than what I needed. Tried Godot next, and so far it's been great. Super straight forward, and iteration speed is so much faster than Bevy or Unity because the compilation times are so low.
The language of the article (starting at the top) reinforces a suspicion that Bevy may be developed with a goal of prioritizing its ECS system over practical goals, or facilitating the game dev itself. I see this in early Rust OSS tools regularly. Actix the web framework marketing, articles, and community being focused on the Actor paradigm; Embassy in Embedded being focused on the Async paradigm; the older gen being focused on the Typestate, Ownership-of-peripheral, and Trait paradigms.
It's OK to have a backbone concept you're proud of and anchors your lib! If it becomes the ends rather than the means, it's worth re-evaluating.
6 comments
[ 2.5 ms ] story [ 15.1 ms ] threadIt's changed quickly enough that docs, examples, copilot, agents, and chat assistants are all a few versions off from each other.
It's OK to have a backbone concept you're proud of and anchors your lib! If it becomes the ends rather than the means, it's worth re-evaluating.
C# is a super underrated language and Monogame has just enough batteries to get going without being in your way too much.
For ECS, I've been using Friflo ECS and haven't had issues so far: https://github.com/friflo/Friflo.Engine.ECS