He ain't kidding about the ergonomics of the ECS boys and girls. Especially in Rust...it's so good that it's not longer just tool for performance optimization but code readability/comprehensibility. It's either that or having a lot of `Arc<RwLock<T>>` s flying around (atomic ref counted read write locks for the uninitiated). I say this as someone who's making use of bevy_ecs separately in this toy renderer project of mine and I've not had to do any wrestling-matches with the compiler since I pulled it in. Absolute joy to use.
Entity-relationships (foreign keys basically) are an interesting idea and can't wait to see what they look like.
Also, I want to add that the bevy community and generally rust_gamedev are pretty great and full of welcoming and inspiring people as such.
Congrats and good work! I thoroughly enjoy every blog post update.
Here’s a suggestion. Bevy should invest in a couple of moderately complex sample games that are maintained. I think a critical failure of Unity is their refusal “eat their own dog food” so to speak.
My recommendation is to put ZERO effort into game design here. Build a few straight clones (within legal bounds, of course).
PacMan, Link to the Past, Doom, Quake, Threes, Angry Birds, etc. Pick like 3 that represent a sample of 2D, 3D, etc.
And I mean a “full” clone, in terms of functionality although not content. By that I mean main menus, persistent high scores, multiple levels, numerous scenes/levels, etc.
I’m extremely confident this will pay off. You could debate whether t should be done sooner or later. I recommend resisting the urge to pushing until more systems stabilize. You need “real” examples to help stabilize and discover the warts.
This is definitely something I believe in wholeheartedly. Game development is an important part of my life and I will be dogfooding Bevy for my own projects, as well as building official "template projects" for various game genres. I probably should have included this in "The Next Year of Bevy" section as I agree that dogfooding is critical when building an engine. And we are at the point in our maturity where this needs to happen.
I'd say this is Godot's biggest mistake. I appreciate and respect the work that has been put into it, but whenever I go back to try it I bounce right off the moment I need to import a 3D model. Either animations don't work, or the materials are off, or some other minor thing that I can't figure out how to fix because there are a ton of buttons and the documentation is too short. There is no good workflow.
To be fair, asset import is incredibly complex and a relative disaster. Content pipelines are the hardest and most complicated problem in modern development imho.
Unity grew in an FBX world. Bevy is focusing on the new kid GLTF. I don’t have enough experience with GLTF to predict if it’s full of landmines or not. I’m gonna guess probably.
First things first: congratulations on your success! You seem to have single-handedly lit a fire under the Rust gamedev ecosystem :)
When I heard about Bevy last year, I was skeptical that game developers could achieve good iteration times by compiling Rust code in debug mode. It clearly works well for small programs, but I was concerned that it might not scale; in particular, that large dependencies might slow down linking, that CPU-intensive games would be likely to run at non-interactive speeds in debug mode, and that just a few seconds of compile time might be enough to break developers' flow.
When people are working on large game projects in Bevy, have they encountered these problems in practice? If not, how have the problems been avoided?
(Full disclosure: I developed GameLisp, a scripting language for Rust games, partly motivated by compiled languages' poor iteration times.)
Iterative compile times are definitely a constant consideration for us. Some various thoughts on this topic:
* For faster iteration on game logic, you can compile app logic in debug mode and the engine in release mode. App logic is rarely the bottleneck when compared to internal systems like rendering.
* Dynamic linking has been a huuuuge win for us. Dynamically linking often gives sub-second iteration times for our examples. Of course, as your app logic/crates get bigger it is more important for you to manage compile time complexity on your end (and we have seen bigger projects notice this trend). Developers can control this by modularizing their code (and dynamically linking these modules when necessary). I'd like to build templates and tooling that encourages people to follow these patterns.
* We have an optional "fast compiles" configuration (check out our quick start guide), which gives additional significant compile time boosts (ex: faster linkers, generic sharing, etc).
* Dynamic linking is just one piece of the puzzle. We need to constantly drive down code size and complexity (by limiting things like generic usage) and dependencies to ensure that userspace compiles as quickly as possible, with or without dynamic linking. Macroquad is the pinnacle of this minimization in the rust ecosystem (imo), but they make way more compromises in terms of "rust ecosystem usage" and api design than I am willing to. My goal is to strike an ideal balance between these (often conflicting) goals.
Sadly we don't yet have top tier compile time tests like rust does (https://perf.rust-lang.org/). We have a history of CI durations over time, but this is a rough metric given that we both optimize our CI constantly and testing on github vms isn't the cleanest environment.
I run `cloc` on our repo every so often, but this also isn't a "metric" we drive down.
We can (and should) build up testing infrastructure for all of this.
Entity-relationships (foreign keys basically) are an interesting idea and can't wait to see what they look like.
Also, I want to add that the bevy community and generally rust_gamedev are pretty great and full of welcoming and inspiring people as such.