"You may notice that every member of the board is an active Bevy Maintainer. This is not a coincidence. We believe that people actually developing the project should be at the helm. There is currently no way to buy a board seat. We have no plans to hire "professional board members" that aren't in the thick of it. For now we plan to stick to the Maintainer == Board Member policy. Functionally, new Board Members are selected via an election of the current board. "Board Member" is currently not a paid position."
Thank you for setting the Foundation up like this!
Hi! I'm the fabled "project manager" that we'd like to hire! Helping run Bevy has been an incredible experience, and I'm very excited about the idea of being able to do this full-time. There are a ton of efforts I'd like to lead, and even more that I'd like to be able to help nudge along.
My personal opinion (and I don't speak for anyone else) is that Bevy 0.13 is usable for 2D games if you use Tiled as your editor. Most 3D games will have to wait until 0.14 (the next release) though, since there isn't animation blending yet (though note [1]), and most 3D games need that. Since I landed animation blending in 0.14, once that version is out I think Bevy will be ready for advanced users who aren't afraid to get their hands dirty to build serious stuff, using space_editor as your editor.
Physics is 3rd party currently, but it's on our roadmap for "some day, definitely". Writing your own physics engine is... a lot of work, and not something that I'm excited to volunteer the engine itself for immediately.
There are two popular physics engines used in Bevy today: Rapier[0] and bevy_xpbd[1]. Both are candidates for upstreaming, but both have their own challenges. I've spent some time working with each of the authors recently, laying out my concerns and thoughts.
On the Rapier side, the documentation is sparse and aggressively mathematical, it uses a distinct math library from the rest of Bevy, the API to work with Bevy is sometimes clunky and unidiomatic, and it can be quite hard to figure out how to do Ordinary Game Dev Things with it.
On the bevy_xpbd side, the performance is subpar, there can be physical stability issues, it's generally immature, and the XPBD solver that they use is, unbeknownst to the young author at the time of the crate's creation, patented by NVIDIA [2] :(
Both of them are working to improve (and I'm very pleased to see that even independent of this discussion), but neither is ready for imminent official endorsement or integration. One day we'll have a Blessed Choice though.
As for telling people "go forth and build your game!": things are stabilizing, and key functionality gaps are gradually getting filled. I have a terrible tendency to be overly honest, even in my marketing text, so there's going to be a long period of time where the actual answer is "it depends on what you're making".
Today, if you're building a weird game-adjacent bit of software (think CAD) for desktop platforms: totally ready! There are several very happy companies doing that. If you wanna mess around with Rust and nurse the Next Great Solo Dev Science-Based MMORPG Voxel Game: you'll have a blast, and it won't affect your chance of shipping a whit. If you want to build a simulation-y desktop game with lots of procedural generation and complex logic: honestly probably a good fit. You'll hit bugs and limitations, but you will in every other engine you use so...
If you want to ship high-performance web games, AAA graphics or mobile: eh, probably doable but dicey. If you want to ship to console: uh we'll find out if we can jump through all of the hoops and convince the right people to get Rust on console before the Steam Deck knockoffs devour the market (please!).
These will all slowly change, but an answer for "is it ready" will be hard to pin me down on until it's a full-fledged competitor to Unity, Unreal and Godot.
The first thing I looking for was whether it is 501(c)(3) or 501(c)(6). While that alone doesn't guarantee anything, it is still a good indication on the motivation of a project. Thank you Team Bevy!
Nothing to ask right now, just -- thank for your (and Alice's) work!
The (non-game) things that I do would be infinitely more painful without Bevy ECS, so I sponsored personally at Diamond for now.
Very excited for relations and I'm hoping that the Bevy Foundation can attract the support it's looking for (and I'll switch over to corporate in a few months if things don't go unexpectedly sideways with my company). :)
It has certainly been a wild ride. Running an organization is certainly a different skill set. I've learned that I'm pretty good at that side too, but it drains me in a way that programming does not. Bevy's success has definitely been a mixed bag for me. It has been extremely fulfilling and a dream come true. But things were also much simpler, calmer, and pleasant when I was building Bevy alone incognito.
The curse of "zero cost abstraction" strikes again :/ A 5x performance difference between debug and release mode isn't uncommon in C++ either and a real problem for game development (plus the slow build times, but those two problems go hand in hand - you can have "high-level abstractions" that build slowly and run fast, or build fast and run slowly).
That's why there's so much advice to write C-like C++ and also ignore the stdlib in gamedev circles. The Rust equivalent is probably to write "embedded style Rust".
With rust you can simply compile your dependencies in release mode while keeping your own code in debug, and it's often performant enough because most of the time the perf sensitive stuff isn't in the app logic itself.
Debug mode isn't always needed, though - E.g. C++ with RelWithDebInfo gets you far enough, unless you specifically want to run debugger - I'm one of those who do not use a debugger in their workflow, so a non-issue for me.
That's been my fallback solution too in C++ in the past and it kinda works (and Visual Studio has a special option /Zo since quite a while https://learn.microsoft.com/en-us/cpp/build/reference/zo-enh..., not sure though if that's actually used by cmake's "RelWithDebugInfo" config), but there's still downsides even when not using a debugger. Most importantly: if you have a crash/assert handler which logs out a callstack, that callstack may sometimes be quite misleading (depending on how much the optimiser passes have mangled the compiler output relative to the input source code).
I've been using Bevy recently so here are some thoughts on this:
Firstly, the overall quality is high and seeing this attention being paid to the project's organization is another good sign.
Documentation is not great. The Bevy book runs out of content very quickly. The "Cheat Book" has additional useful information: https://bevy-cheatbook.github.io/. With these plus the examples I've been able to figure out everything I need, but it's slow going.
I'm not 100% sold on ECS. It loses a lot of type safety and there doesn't seem to be any way to ensure cleanup of entities and their components.
Thanks (I am the aforementioned project manager) :) Docs are a high priority for me, especially beginner content, assets, and rendering for me. Rust's in-repo examples are really helpful for ensuring they stay up to date, but aren't a replacement for a guided tour.
As for the ECS, I've absolutely felt that: the flexibility of the polymorphism created by "just add another component!" can be both chaotic and freeing. Can you say more about what you're looking for with entity cleanup? I haven't heard that complaint before and want to make sure I understand what you mean.
Most games have different states. For example, you have the main menu screen and perhaps different levels. Each of these could be a state. I think Bevy already has an abstraction for this[0] but it only records the current state. There is no other information associated with it IIUC.
What I think would be useful is essentially an arena allocator associated with a state. So any components and entities created when a state is active would be removed when that state is exited. Otherwise it seems that one must do manual GC, which is error-prone and will almost certainly lead to slow leaks over time.
Ah okay! I can see the need for this. This is a large part of why the States machinery exists, but I see your point about it being error-prone to remember to tag and then despawn everything.
I'll chew on solutions here: we might be able to get away with a nice well-documented convention in user-space code, or we may need to add a small extension to the internals to make this more robust.
Isn't the typical way to do this by using a janitor? This would typically need to be done in user space (the framework doesn't know what cleanup you want to do), but Bevy could provide an interface for it with callbacks or whatever is more idiomatic in Rust/Bevy.
Last time I was using Bevy I had a cleanup system to solve exactly that issue. It queried for entities with the AssociatedWithState component, or whatever I called it, and destroyed any where the was a mismatch.
I could see an efficient version of that being a nice thing to have built in, though. It’s definitely a very common thing.
The release notes are great btw. Usually if I’m doing something for the first time I look it up in the bevy cheat book, get something that doesn’t work (because it’s two or three versions out of date), then check the intervening release notes. Usually there’s enough direction to figure it out.
They're so, so much work. Carefully going over the log, and patiently explaining / showcasing and contextualizing them is even more work than writing docs for the same feature, since you don't have the API to help structure things.
I'm glad it pays off! Seeing them come together makes my day every time, even when I'm writing half of it.
Oh, I know! I’m a maintainer of another open source project and the release notes are such a chore. For the quality of Bevy’s I could easily see it being a full time job, albeit a mostly thankless one. So thank you for the effort you’ve put in!
ECS is an architecture proposed by the same group that has said "if you know you're not going to use that memory again, just allocate over it". For certain domains, this is a superior solution to management than more costly cleanup. Re-initializing an allocator and leaving behind old data in now uninitialized memory is a lot faster than doing anything with that memory.
For type safety, entities define mapping of types [components are types]. The whole point of ECS is effectively managing types and ensuring correctly typed data is operated on.
A note on the ECS: This is largely due to poor understanding on my part, but I moved my computational chemistry (egui-based) GUI program (Visualizes various wave function properties) from Bevy to WGPU directly, because the ECS was difficult to grok and debug. It felt like more work to reinvent wheels regarding rendering than manipulate the ECS. I had it working in Bevy, but ported. Not a canonical use case for a game engine!
It's been ~2 years, but my main reason was wanting to write plain rust, vice using a DSL.
I moved my game away from Bevy to WGPU too because I needed tighter, more efficient control of the data than ECS could provide. Though being able to query data with types is amazing and really demonstrates how powerful Rust's type system is, it's not a solution for everything, and feels more geared towards one-off arcade style video game design.
ECS is basically a very simple relational database. There is no equivalent of foreign keys or other constraints between components. I can't say, for example, "every entity that has a location must also have an associated mesh". If I forget to add a component it's just a silent failure. Everything runs fine, just the expected result doesn't happen.
You can probably write runtime tests for this. Some system which queries for component Location, and then does an assert for each component that the associated entity also has a mesh.
Granted, this is annoying and not a particularly great solution, but it would serve to give you a reminder for when you forget. I don't mean to diminish from your overall point either, it's a valid and good one I think.
I have this vague thought that Rust needs a different kind of type system.
Standard type systems[0] basically rely on references between values[1]. I seem to read about numerous Rust systems that don't use references for various reasons. Usually the borrow checker gets in the way or they want a different memory layout[2]. This makes me think that what's needed is a type system that allows constraints to be expressed between values without requiring a reference between them. I don't know what this type system looks like, though.
[0]: Rust's type system is a fairly standard type system from an academic POV. The novelty is that it's the first language with traction to use a linear / affine type system, but these are relatively well studied in academia.
[1]: The theory is not formulated this way, but the representation they compile into is a bunch of references.
[2]: ECS, as I understand it, is not a reaction to Rust's type system but an architecture driven by memory layout, parallelism, and breaking-out-of-OO-hierarchy concerns. However the net result is the same.
Totally agreed,
like when using an int to reference into an array, there's no way to guarantee that the int won't be out of range, so it needs a check every time
Also no ideas here, but its fun to think about anyways
In theory this is what Bundles are for, though it's easy to not realize that there's a bundle for what you want to do.
I should note that this is a problem with most game engines, not something unique to Bevy. For example, Unity is infamous for requiring arcane combinations of components to avoid silent failures.
A scripting language is an explicit non-goal for first-party support, but there have been tools for using the ECS entirely without Rust types which can be exposed via FFI or embedded languages like Lua.
Just search "_by_id" in the bevy_ecs docs, and you'll find all of the associated APIs for access. There are then (unsafe) APIs for creating the internal mappings necessary to use them. These are normally called via the monomorphized generics automatically, but need to be manually called since we don't have compile time knowledge of the data being stored and accessed.
Given the fact that foreign values inherently require the use of unsafe due to not being able to verify anything about the value and it's behavior, yes, it's generally not recommended unless you're looking to write your own scripting integration plugin. Likewise, most of these scripting language runtimes are almost always not threadsafe in the slightest, requiring either single threading all scripted behavior, expensive locks, and heavy use of marshalling, which negates a lot of the performance benefits of the engine.
For more developer experience oriented reasons why this is done, I strongly suggest reading cart's reasons for making Bevy to begin with: https://github.com/bevyengine/bevy/discussions/8107#discussi.... More specifically the "Turtles all the way down" bullet point.
I think that's impossible. Bevy works heavily with Rust types and generic monomorphization. You couldn't do that in another language without literally generating Rust code and calling the compiler.
Although Bevy says it's an engine, I think that's a bit of an overstatement. It's more of a library/framework. There's a lot you need to do from scratch.
If you are looking for a more full featured game engine-- I recommend Godot.
I have been using Godot lately and it's refreshing how nicely it flows and how the experience mirrors other OSes (from a Linux user's perspective). If you haven't tried Godot lately, give it a try.
Plus, the whole thing is a single binary (~100mb).
I actually recently switched a project from bevy to Godot and agree, it was really nice and easy to get started. Godot is shockingly simple and intuitive compared to something like unreal engine.
Bevy was also great, but is definitely more of a library and there's not a lot of mature plugins. My use case was a web browser compatible game (wasm compiled bevy) that used websockets for networking. It didn't seem like too much of a stretch, but I didn't end up getting anywhere I wanted to be with bevy unfortunately. Hopefully as it grows it becomes a better option!
But with Godot I ported my code and had it working in the browser with websockets based multiplayer shockingly fast, even having never touched gdscript before!
From what we could tell, not really! It seems like a slow policy change, basically dictated at the level of the individual bureaucrat.
That said, the Zig Foundation got status in 2020, and the Amethyst Foundation (another Rust gamedev group) also got status recently, so we figured it was worth it to apply since we really do feel like it's the best-fitting designation for how we want to run things and what we want to do.
Does Bevy have a graphical editor yet (or one on the roadmap)?
It seems like it has good bones, but taking real territory away from Unity or Godot will be hard without an editor (not just for non-programmers; some game dev tasks are just way easier with a GUI)
Of course it's open so somebody could build one, but it seems to me this deserves to be a first-class citizen
> ...taking real territory away from Unity or Godot
I used to think this too. But having written a lot of hobby code using Godot (via Gdext, an excellent Rust wrapper for it) I feel the editor is a nice to have but not indispensable.
Very soon into the game you'll find that you need an editor that lets you add your own game abstractions into the game. And at that point you're better off writing an editor "in game" than shoe horning your abstractions into the game engine editor.
There's a bit more nuance I probably outght to the above description but too tired to type it all out on my phone now.
Loved bevy since the reddit post (i think that was even pre 0.1). It's a bummer I was in the middle of learning rust, so I wasn't of much help. Would've loved to contribute
Don't worry, you still can! I've been actively contributing to the past 4 months, working on improving CI and the website. I started out doing PRs for typos and little improvements, and so can you! (I recommend looking for issues marked as "Good-First-Issue," they are the best entry-level things to work on.)
I write a simple 2d game in bevy to learn rust and ECS. I like it a lot.
I just wish it was slightly better with backward compatibility. There's many useful libraries I can't use because they depend on different bevy versions, and updating the code to new major versions is a hassle. And the bevy cheatbook has some pages refering to behavior that changed several versions earlier.
Love where Bevy is going.
On the UI/UX side it has a long way to go, but on the non-rendering backend architecture side it can beat Unity, Unreal, and Godot in the long run.
Just crossing my fingers because by the time Bevy reaches that goal, compute power may have just 10x'd again, and the existing game engine giants will have added AI creation tooling by then.
It sounds like 3 is for charities and 6 is for business organizations like a chamber of commerce. The former has tax-deductible donations and can’t participate in lobbying or political campaigns. It seems like 6 would have been a weird choice here.
Not so weird, the Rust Foundation is a 501(c)(6) after all, like the .NET Foundation or the Eclipse Foundation, but from all I know about Bevy and the people behind it a 501(c)(3) suits it much better.
Thank you for setting the Foundation up like this!
To make this work in the long run donations are crucial: https://bevyengine.org/donate/