Bevy's First Birthday: a year of open source Rust game engine development
bevyengine.org
bevyengine.org
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.
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.
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.
https://github.com/KhronosGroup/glTF-Sample-Models/blob/mast...
I appreciate bug reports submitted via the Godot Engine bug tracker with notify to @fire, but sad letters here in HN are acceptable too.
https://github.com/godotengine/godot/issues
On Godot Engine master work currently.
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.)
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.
* 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.