Interesting that the ECS you linked beats out Flecs .net bindings. I wonder if it is because of copying to/from the dotnet heap.
Looking over the readme.md I find it interesting they don't list dotnet 9 support but they do list 7 so they do seem to support non-LTS versions but skipped 9 (mind you maybe they just didn't update the readme?)
Up until midway through Hades 1 development Supergiant was a c# shop with their own engine on top of libraries (the fact they rewrote their core tech in the middle of a game project that was already available to the public remains insane to me).
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.
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.
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.
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.
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.
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.
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.
It's solving problems that are so far down on the list of priorities of a video game project that it will never evolve beyond a mere toy unless they really wise up. "My performance is bad because I didn't design this in a data-oriented way" is a different problem when 65% of your game is finished as opposed to solving it at "Hello, world." Hell, you can't even solve that problem unless you understand what your actually real game is doing at a data level in the first place.
Before software can be reusable it first has to be usable. There is a good reason why every existing popular engine was purpose built for a game in its infancy.
Makes sense to me. Lots of folks attracted to Rust seem to enjoy code-golfing more than solving problems. Designing the “perfect” game architecture vs shipping games seems to match that and my take on much of the Rust ecosystem.
Bevy has the best developer experience of any game framework I've ever tried (I have worked with mainstream engines - which warmed up to ECS over time - and engines that started with ECS like ECSY and playcanvas) but it's too low level for most studios.
I get your point about actix and actors but I think the difference there was that the author wanted to build Elixir in Rust, while the community wanted an Express (from node.js). The vast majority of web services I see don't need an explicit actor model.
ECS instead has a significant impact on developer experience, so I appreciate their focus on data structures.
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
This looks great, thanks for sharing Do you know what the C# to wasm story is?
Interesting that the ECS you linked beats out Flecs .net bindings. I wonder if it is because of copying to/from the dotnet heap.
Looking over the readme.md I find it interesting they don't list dotnet 9 support but they do list 7 so they do seem to support non-LTS versions but skipped 9 (mind you maybe they just didn't update the readme?)
Oh wow, had no idea Bastion was made with Monogame and C#!
Up until midway through Hades 1 development Supergiant was a c# shop with their own engine on top of libraries (the fact they rewrote their core tech in the middle of a game project that was already available to the public remains insane to me).
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.
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.
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/)
Bevy is very explicit about this in its guide, though!
People made games and software in bevy despite the API flux, and the migration guidelines are really good too.
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.
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.
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.
It's solving problems that are so far down on the list of priorities of a video game project that it will never evolve beyond a mere toy unless they really wise up. "My performance is bad because I didn't design this in a data-oriented way" is a different problem when 65% of your game is finished as opposed to solving it at "Hello, world." Hell, you can't even solve that problem unless you understand what your actually real game is doing at a data level in the first place.
Before software can be reusable it first has to be usable. There is a good reason why every existing popular engine was purpose built for a game in its infancy.
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.
Makes sense to me. Lots of folks attracted to Rust seem to enjoy code-golfing more than solving problems. Designing the “perfect” game architecture vs shipping games seems to match that and my take on much of the Rust ecosystem.
Building a game engine is a titanic effort.
Bevy has the best developer experience of any game framework I've ever tried (I have worked with mainstream engines - which warmed up to ECS over time - and engines that started with ECS like ECSY and playcanvas) but it's too low level for most studios.
I get your point about actix and actors but I think the difference there was that the author wanted to build Elixir in Rust, while the community wanted an Express (from node.js). The vast majority of web services I see don't need an explicit actor model.
ECS instead has a significant impact on developer experience, so I appreciate their focus on data structures.
Out of the loop here, how does Bevy compare to Fyrox this year?
Since Bevy still has no editor I guess Fyrox is still winning in that field.
Apart from that, Bevy's community seems a lot bigger.