Bevy TLDR – Game development with Bevy summarized
9 comments
·October 18, 2025the__alchemist
all2
Architecture > UX?
I'd love to avoid this in my personal projects. Programming paradigms are useful within their bounds, but at some point UX has to take the front seat.
spicyusername
Of all the programming-first video game frameworks I've tried, including Bevy, I found Monogame to hit the sweet spot.
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
Ninjinka
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.
runevault
First: Godot is rad, and if you're willing to use third party tooling you can even use rust to code your logic (official Godot languages are gdscript, c#, and c++, but the community has added support for a lot more like rust and swift).
Second: building the editor (in Bevy, same way godot's editor is built with the game engine) is an active project so if you think Bevy is interesting it is worth keeping an eye on whenever that gets released.
jvanderbot
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.
SeanAnderson
Yeah, my experience has been similar. On the one hand, it's exciting to have new features every few months. Some of those features very much so addressed pain points in my code and I was excited to adopt them. Other times, changes were introduced which offered new ways of developing, but didn't deprecate old ways nor were they strongly opinionated in which way should be applied in which scenarios.
Overall, I had a lot of fun learning the ECS paradigm, and I found Bevy to make working with Rust easier than learning Rust on its own because it did a good job of hiding lifetimes from me in a lot of situations, but I never got to a point where I felt like I was able to develop ideas quickly.
I'm optimistic about revisiting the code I wrote at some point and seeing how things have improved. It's been maybe a year and a half since I stopped working on a pet project, but I still keep up with all the release notes and have seen lots of things to be excited about. For example, hot reloading is well on its way to being stable and their UI components are becoming much more robust.
https://ant.care/ I built this with Bevy (code here: https://github.com/MeoMix/symbiants/) but have moved on to other projects for the time being.
It's a cute lil sim. It'll crash on you at some point 'cuz there's a race condition when ants come back from the outer-world while hauling food, but it's still kinda fun to watch 'em go.
(Also, while I'm yapping. https://loglog.games/blog/leaving-rust-gamedev/ is very true BUT ALSO people have made successful games using Bevy, or parts of it, e.g. https://store.steampowered.com/app/2198150/Tiny_Glade/)
runevault
Yeah I've mostly been keeping an eye on Bevy from a distance for this reason. cart is still willing to break API compat if he finds a better solution (and since it is pre-1.0 I do not blame him). The API breaks and an editor are probably the two biggest features Bevy needs, and the editor is an active project so I'm anxious to see how that goes.
null
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.