The community is really exceptional. I ask questions daily and get helpful responses usually within minutes. Bevy hides some of the complexities of Rust, such as lifetimes, away from normal development. This was a pleasant surprise for someone coming in with little awareness of Rust.
Writing in ECS is pretty confusing to begin with and, IMO, represents the steepest part of the learning curve. After a while ECS starts to feel more natural though and you'll wonder why you were ever comfortable doing OOP.
The main sore spots for me are: UI needs a lot of work to be ergonomic and beautiful, there's a lot of footguns related to performance and event handling/change detection, which do have workarounds, but at the cost of ergonomics, and, specifically for WASM, everything (including rendering) is still single-threaded which makes the app perform worse than well written JavaScript for now.
I'd be happy to try and answer any questions about my experience as a complete noob to Rust/Bevy/ECS/game development and having immersed myself ~full time on a game for the past year.
FYI, you can browse my game's code here: https://github.com/MeoMix/symbiants
Keep me posted!!
I recommend checking out Bevy Jam games (which are pretty much always open source) for more complete / real world examples: https://itch.io/jam/bevy-jam-4
Definitely a bit of a gap in our official learning material. Hopefully we can close it soon!
Any concrete plans for a GUI editor?
Does stuff like Lumen/Nanite from UE5 have any chance of existing in Bevy?
As far as Lumen goes, there are a few experimental early-stage projects that add real-time global illumination to Bevy, such as bevy-solari [1]. Most of them rely on hardware raytracing support, as this simplifies a lot of things, and the new baked GI stuff that just shipped in 0.13 is fine for non-RTX. Besides, there's a good chance that hardware raytracing support will be very commonplace by the time any of this reaches production quality.
For Nanite, the closest thing that's being actively worked on is meshlets [2]. These actually are pretty close to ready and likely to land in 0.14 (no guarantees of course). These provide some, but not all, of the benefits of Nanite. LOD features can potentially be layered on top of meshlets in the future to provide a solution to roughly the same set of problems that Nanite solves, with some advantages relative to Nanite and some disadvantages.
We can definitely deliver on global illumination in some way, as shown with the irradiance volume support added in this release, though it may not match Lumen 1:1. Nanite is definitely more involved, but worth investigating.
And yet no teapot! Literally unusable.
What is the expected ECS overhead per frame (not including graphics interaction, i.e. code specifically in the ECS model)?
Since an ECS is typically a flattened scene graph, is there still a game loop? Wouldn't be necessary, correct? You only need to respond to the inputs...
As for ECS overhead, I've made it one of my top priorities to eliminate it wherever possible since it underpins the entire engine. We're at the point where most optimizations are saving a few tens or low-hundreds of microseconds per frame in your average game/app (i.e. lowering context switch costs from parallel system execution). If you're pushing below 60 FPS in your app, chances are the performance issues are not coming from the ECS, but some other part of the engine, or the app's own code.
How do you plan to have stuff moving then? You need to update their position every frame, so...
Is it portable to Browser? Or is that on the roadmap?
While bevy is a decent piece of tech, it gets way more hype than it deserves, especially when there are more mature and capable alternatives.
Bevy, despite being written by an army of contributors is continually behind Fyrox which is developed mostly by one guy. Fyrox not only has an editor and a UI toolkit, both of which bevy devs keep just talking about, it recently also added a UI editor. In addition the author is writing 2 games to dogfood Fyrox.
Yet despite all this, Fyrox gets a fraction of the attention and money. Maybe it's because it uses proven old tech instead of being a resaerch project, maybe it's because the author is russian, maybe because people are afraid of a 3D-first engine, maybe fyrox doesn't focus on promotion enough. Idk, but here i am doing my bit to make the world a tiny bit more fair even if I annoy all the bevy fans who kept posting about bevy on every single fyrox post that wasn't completely downvoted and ignored.
All of the major engines are written in C++. I've tried Unreal, Unity and Godot. They all have their flaws. With Unreal and Godot those flaws are mainly the scripting languages BP and GDScript which one can get tired of quite easily, especially BP. You can of course use C++ for all your scripting but both engines strongly encourage you to use their scripting solution for a big chunk of your game. (Unity has a bunch of other issues and isn't source available, although C# is fairly pleasant to work with IMO).
There is definitely need for an OOP engine in Rust just as there is need for an ECS engine in Rust.
Heh Bevy sounds like Rust itself. Good PR with money behind it is its no1 cause of adoption.
