Bevy 0.15 released
bevyengine.orgBevy's creator and project lead here. Feel free to ask me anything!
I'm not quite sure why, but this release feels special, there are a ton of new features that I'm really excited to try out. All kinds of applications for the remote protocol even beyond the editor or games.
Two questions: is there any timeframe on the new declarative scene system (BSN)? and if mod_picking was moved into bevy itself, are there any plans to do the same with xpbd or rapier in the future?
We'd like to land initial BSN features within the next two cycles (obviously sooner is better than later).
We do have plans to upstream a physics plugin, but we aren't yet in a rush to do so, given how great the 3rd party options are. Once visual Bevy Editor workflows start being viable, the pressure to bless a physics plugin will go up I think.
Bevy keeps coming up on my radar, and I wish you guys the best! It's a huge undertaking.
Do people need to learn Rust to use the engine? Or is/will there be the option of scripting in a simpler language?
Do you get much in donations? Corporate or individuals?
Also do you have a transparency page that details how you spend donations?
I'm always more confident in donating to projects that have one.
Thanks for the kind words!
Practically at the moment you do need to learn Rust to use the engine. Our public APIs are all Rust APIs. I'll note that Bevy's ECS makes a lot of Rust more approachable, as it is written to "feel" high level, and it solves a lot of the ownership problems for you that normally trip up newbies. I am of the opinion that Rust is a productive gamedev language, especially in the context of Bevy.
That being said, we've built Bevy ECS and our Bevy Reflect (our Rust reflection library) in a way that enable bindings to other languages to be built. People have built partial Lua and Javascript scripting support on top already. For ecosystem health reasons, I believe that Bevy should have one official language (Rust), but we still want to give people the tools they need to build the integrations they want.
We do get a healthy amount of donations, both from corporations and individuals (see https://bevyengine.org/donate). If you navigate from there to our foundation page, you can see how we spend it. We are a 501c3 non-profit, so each year we MUST file a public annual report as well outlining our activities.
As a casual onlooker, reading blog posts here and there, it's evident the topic of Rusts' suitability for game development is a hot topic of discussion and research. Sometimes it feels there is a sort of existential dread coming with the thought that Rusts' design maybe simply makes it too much of a pain in the long run in attempt to force code to comply with it's required way of thinking.
Do you ever find yourself wondering if its the right path to commit to for future games?
The strong criticism Rust got in this area is being poorly suited for rapid throwaway prototyping. I think that's fair — slow compile times and language's focus on writing things properly on the first try are the opposite of what you want when trying out random ideas and seeing what sticks. I think that may be fixable. Partly it's a skill issue (with enough experience, you can cut corners when you known which ones to cut). Partly it could be improved by tooling for hot reloading, and perhaps a scripting language integrated with Rust.
In Bevy in particular almost everything happens through ECS, and the ECS has a Reflection API, so you can hook it up to whatever you want, and manipulate it from any language.
I also wonder what about the rest of the game development lifecycle. Games are taking many years to develop, and not all of that is quick exploration. The more of the game starts taking shape, the more you actually need stuff to work. You need ability to refactor, polish, and extend the implementation without breaking things. You need to be fixing gameplay bugs, not wasting time on hard-to-reproduce crashes.
These days it seems as though game stability is a complete afterthought, at least for the big publishers. :/
I personally love working with Rust. I think it delivers on the various buzzwords that made it popular. In general when people critique Rust in this context, it comes down to:
1. Rust's ownership / mutability features
Bevy ECS specifically alleviates a lot of the ownership problems that newbies often encounter in Rust. It doesn't solve _all_ of those problems ... there are definitely still UX rough edges. This _will_ be a sticking point for some people. The cost / benefit here is also hard for newbies to evaluate, as it is a _very complicated problem that requires years of experience in the space_.
From my perspective, the cost is worth it. Strict mutability and ownership rules allow us to parallelize everything safely and automatically. Strict mutability allows us to (via the DerefMut trait) _perfectly and automatically_ detect all changes to components and allow developers to react to them. This is something that is unique to Rust, at least in the mainstream. You will not find this type of feature in ECS-es written in other languages, as they literally don't have the semantics to globally distinguish between a read vs write pointer deref.
Opt-in garbage collected ECS is something that people are experimenting with in Rust right now), which would allow people to define "do whatever you want" code.
And _right now_ you can always just use Bevy ECS's unsafe api variants to do whatever you want when the "safety" isn't worth it to you.
2. Rust is "too low-level"
Rust can feel "high level" when it needs to, and Bevy is built in a way that takes advantage of that. If you look at our example code, it _looks_ high level: https://github.com/bevyengine/bevy/blob/main/examples/3d/3d_...
I value what I like to call "progressive disclosure of complexity". I want people to be able to quickly and easily use the tools I build without much experience. And as they gain experience, I want them to be able to seamlessly dive further down the stack. I believe Rust handles the encoding the "low level" stuff better than every other language, both by more accurately modeling system constraints and by protecting people from doing the "wrong thing". It also allows you to use those low level pieces to "climb up" the stack until you have something like the Bevy API.
Unlike most engines, in Bevy you can start "at the top" in your program, hit F12 in your IDE to "go to definition", and keep going until you hit the core language APIs. And _then_ you can hit F12 one more time and go into Rust's source code. This experience is extremely empowering, coming from engines like Godot, which have a "high level" API with a "hard cut" before you go into the engine with a completely different language and paradigm (and no good way for your IDE to bridge the gap).
Bevy (and Rust) are for the developers that care about understanding (and controlling) their tools from top to bottom, and are willing to undergo a bit of initial pain (relative to scripting languages) to make that happen. Rust is not a perfect language and it isn't the best "constraint solve" for everyone. But I am most interested in building a holistic experience that empowers people that value that kind of thing.
3. Compile times
Rust compile times can be long if you aren't intentional about it. That being said, Bevy is built in a way to make compile times reasonable. With our "fast compiles" setup (see the getting started guide on our website), I can compile a change to our examples in ~0.5 seconds. Thats close enough to "instant" for me. The trick in general is (1) make sure you aren't writing code in a such a way that requires recompiling EVERYTHING (2) use dynamic linking for large deps (we do this for you in Bevy via the dynamic_linking cargo feature) (3) use a fast linker (covered in our guide).
Ensuring you follow principle (1) in large projects is a skill that needs to be honed. But on the Bevy side, via our opinionated Plugin structure (and dynamically linking those plugins), I think we can provide bounds that discourage people from shooting themselves in the foot.
I will close by saying that it is worth thinking critically about what tools you use and not following hype trains blindly. Picking Rust _and/or_ Bevy for your project _is_ currently something that many people should not do. However I think that Rust and Bevy are both VERY good tools that will be right for some people. And due to their "carefully and seamlessly climb up the stack" approach instead of "riskily climbing down when necessary", they have extremely solid foundations, and their user experience improves constantly. They are both increasingly suitable tools for more and more categories of people, and I expect that trend to continue.
Wow. This seems like a really huge and impressive release, honestly. My impression of Bevy hasn’t always been the greatest for a number of reasons but I could possibly be convinced to see the light on this one! Kinda wish there was a C API though.
> My impression of Bevy hasn’t always been the greatest for a number of reasons but I could possibly be convinced to see the light on this one!
As one of the Bevy contributors, I'd love to hear what you didn't like in the past, and what you liked from this release. User feedback is super useful - I don't see the same set of pain points most users see since I work on the engine internals.
In general building a game engine is an _extremely_ large task - we're under no illusions that we're going to get it perfect the first time, or even the first few rewrites. But I'm fairly confident in the long term direction of the project, and the community we built and amount of developers contributing means I'm confident that we'll get there eventually :)
> As one of the Bevy contributors, I'd love to hear what you didn't like in the past, and what you liked from this release.
One issue that I always had with Bevy's development direction was how it felt a bit incongruent in a way. Like we get all these advanced rendering features but the boring basics are only slowly getting added. But of course it makes sense, its much more fun to work on a super advanced state of the art virtual geometry renderer (that is very impressive stuff) than it is to work on the boring parts.
I hope one day the foundation gets proper funding and can fund development with a clear focus and direction like the Blender foundation.
Why this release feels somehow different is because there are many mundane, boring but very foundational features added, like sorry but I do not give a fuck about chromatic aberration, but I do care about required components, animation masks, additive blending and events, box shadows, cosmic text, ui scrolling, interpolation functions and event propagation / bubbling.
Take the only now added animation masks, what use is an engine that supports visualized geometry (added in previous release) rendering but I can't render the hand movements of a character separate from the body? That's what I mean by incongruent, its not meant as a criticism, that's just how open source works of course but its still frustrating sometimes.
For the things still missing, for example: declarative scenes (in the works with BSN), asset streaming and pipeline events, (proper) rich text rendering, pointer and text selection events to name a few.
So seeing these "boring" things slowly getting added with each release also makes me very optimistic for the future of Bevy!
(notice how I didn't even mention the editor ;)
You're not at all wrong, but like you said it's the (sometimes unfortunate) reality of open source. We have a lot of rendering contributors, but less so for every other area except probably the core ECS.
Here's to hoping we get more boring contributions in the future!
What is pipeline events though? I haven't heard of that, and google isn't bringing anything up.
P.S. I'm actually the author of the virtual geometry feature, so that was a particularly well chosen example :)
> What is pipeline events though? I haven't heard of that, and google isn't bringing anything up.
Last time I checked there is no way to know if the async (render) pipeline compilation is completed. If I add a large scene to the world I don't know when it will be ready to render. In other words, its non-trivial to add a loading screen in many circumstances, or to do things like adding and removing scene bundles without causing pop-in or freezes, something that no game engine should struggle with. With something like pipeline events I mean if we could get events from the render world about the state of the pipelines or some other way to know, then we would at least be able to implement some kind of shader compilation stage / loading screen properly. I care more about that kind of stuff than rendering a gazillion triangles at 60fps, although that is pretty cool ofc.
> P.S. I'm actually the author of the virtual geometry feature, so that was a particularly well chosen example :)
I didn't realize lol It's really impressive work regardless!
Ah yeah pipeline compilation is a very non-trivial problem[1]. Unreal is also struggling with this a lot. I hear you that it's an issue.
The Bevy issue you want to follow is https://github.com/bevyengine/bevy/issues/10871.
[1]: https://therealmjp.github.io/posts/shader-permutations-part1 + https://therealmjp.github.io/posts/shader-permutations-part2
Totally subjective and superficial outsider view, but it has been my perception both that Bevy does not make great use of Rust features (i.e. I’ve heard it relies a lot on dynamic dispatch / there are things that can be done wrong which aren’t caught by the typesystem?) and that it lacks feature parity on certain important points (which I couldn’t be asked to enumerate) — which could be forgivable if its use of Rust’s typesystem was more advantageous given the first point but could be an issue if it wasn’t well differentiated by it.
I mean, kind of. It's a bit of a vague comment. Dynamic dispatch is not bad by itself, and as not-an-ECS-developer, I couldn't actually answer how much it is or is not used in the ECS internals. Probably more than I expect, but not enough to be an issue. Performance is plenty fast, we profile that pretty often.
As for things that can't be caught by the type system, it's not like we can enforce that the logic in system_b that expects a given entity to be alive won't accidentally break if you introduce some system_a later on that despawns the entity at some point. We can't compile-time validate that kind of safety for game logic - it's just not possible.
On the other hand there are things we can do that C++ based engines can't thanks to Rust. Compile-time variable mutability means we can know exactly what set of systems modify which pieces of data, which means we can automatically schedule different systems in parallel without any safety issues, or detect what when and who touched a piece of data last.
In terms of features, Bevy is still early in development. Feature parity with existing, 10-20 year engines with many paid developers is going to take a while. But I think we have some pretty compelling features on our own even today, foremost our focus on ECS and modularity.
In terms of what Rust brings, it has the performance of C++, but with better memory safety (mostly in terms of engine internals - not like user code touches lifetimes that often), thread safety, a way better and standard build system, some modern features like pattern matching and enums, etc. The usual ways in which Rust is better than C++.
The answer isn't so much "why would I want to use an engine in Rust" (although I personally love Rust and would absolutely choose it over a C++) but more "we want to make a new engine". You want C++ levels of performance, but without having to use C++, so Rust is an obviously compelling choice for a game engine.
Like I said: superficial, subjective, outsider perspective. :)
Heyo, another contributor here. I work in rust now professionally, and Bevy is part of what opened my eyes to the power of the language. The project makes deep complex use of rust’s memory safety and type system, but also takes great pains to wrap this complexity in simple and approachable APIs. We’re also almost always one of the first consumers of newly stabilized compiler features, usually bumping MSRV and incorporating the new features (for instance const float arithmetic) within days. I don’t see how it could have been written in any other language.