What (dis)advantages does writing a game in Rust (with Bevy) have compared to other languages? Keen to hear about performance, safety, and dev velocity.
What (dis)advantages does writing a game in Rust (with Bevy) have compared to other languages? Keen to hear about performance, safety, and dev velocity.
I gave a talk about this recently![0]
But, to answer your question directly:
- Rust performance is comparable to C/C++, but Bevy has had much less time to get optimized than C/C++. Our ECS is fast, but slower than flecs, and our rendering performance is about Unity level IIRC.
- Safety / correctness is a huge benefit. Memory safety is obviously nice for reducing horrible segfaults, but ultimately I end up really loving enums, traits and the ease of unit testing to make refactoring games (and the libraries they rely on).
- Talking to experienced game devs, velocity is quite good! Once you're off the ground, a ton of your time comes from a) refactoring b) bug fixing c) adding bog-standard but tedious functionality like localization. I've talked about the first two, but Rust's first class packaging ecosystem (and Bevy's modularity) means that you can actually share work for that, rather than rewriting it at every company like you see in a lot of other game dev.
Gameplay features are wildly easy to write, but GUI creation is still miserably tedious with a fragmented ecosystem.
On development velocity, I will note that Linux's compilation times for Rust are meaningfully better than Windows, although M1 Macs are compelling too. The lack of visual editor tooling definitely slows things down too, even though good ecosystem options for that are emerging.
[0]: https://elk.zone/mastodon.gamedev.place/@alice_i_cecile/1113...
Also, consoles are out of the question, right? Well, maybe Xbox.. maybe. And what about mobile?
That's a big leap, what makes you say consoles are out of the question?
The console toolchains are proprietary and locked behind NDAs. An engine cannot be both open source and support consoles. What it can (and Godot does) is have a closed-source version of the engine (or just plugins) that you are only permitted to license once Sony/Nintendo/MS has approved you. That version or those plugins can then contain the code required for the consoles.
Yes, exactly this with an added hurdle of Rust which isn't supported by any of the mainstream consoles.
An engine can be open source with proprietary extensions.
Steam Deck functions great, Xbox is a well, maybe. Playstation and Switch are "negotiate with the console owners" situation.
Mobile is functional but immature, same with XR.
The biggest disavantage is that no one uses Rust to create games, it's all C++ or C#. So all the documentation, knowledge, libraries etc ... are missing and / or different.
Or JavaScript, surprisingly. Vampire Survivors is the most famous recent one. Pretty cool to think about.
You need to be comfortable with Rust and with ECS.
If you’re coming from a GC language and `Player extends Entity` mutable OOP approach, you will have to completely re-learn how you architect games.
The upside is that Rust is pretty fast, and Bevy takes advantage of Rust’s relatively easy multi-threading.
Have you considered moving off of 0.x.x? You have people consuming this software, it's public, and if you plan on breaking it quarterly, just be upfront with people and move through major versions.
LÖVE made the same mistake for years, and their version history looks odd as a result due to the sudden jump from 0.10 to 11.0.
You'll be working on Bevy for years. When do you decide it's ready for public "stable" usage, and how do you plan on communicating this to users?
> and if you plan on breaking it quarterly, just be upfront with people and move through major versions.
Isn’t that exactly what a 0.x version means? This seems far more up front with people that releasing a 1.0 that bumps to 2.0 3 months later.
I think until the engine is baked enough that the API avoids breaking changes for years at a time it should remain pre 1.0.
What will most likely happen is that there with be large subsets of Bevy users who never use a formally stable Bevy codebase, and then leave for something different, because there are no guarantees.
Maintainers of all sorts of different projects also signal to their users their investment value in working with a large critical dependency.
> What will most likely happen is that there with be large subsets of Bevy users who never use a formally stable Bevy codebase, and then leave for something different, because there are no guarantees.
But naming it 1.0 won't give them guarantees either. If it's assumed, it would just be annoying when breakages do occur. What you're really asking for (it sounds like) is for there to be less breakages or longer term releases .. and that's a staffing issue imo.
If users avoid it because they don't want churn, and the devs are choosing churn - then everyone is in agreement currently, no? The bevy devs are writing software in a way that fits them currently, and users who prefer to wait for 1.0 are doing so currently. Everyone gets as advertised.
Do you see it working differently?
> What will most likely happen is that there with be large subsets of Bevy users who never use a formally stable Bevy codebase, and then leave for something different, because there are no guarantees.
But you haven't asked for them to release a formally stable Bevy codebase. You just asked them to change to a 1.0 version that implicitly promises a stable codebase. You specifically asked:
"and if you plan on breaking it quarterly, just be upfront with people and move through major versions."
That's not being up-front with people. A game-engine that breaks quarterly absolutely isn't ready to be versioned with a major-version. As I said in response to your first post, a "0.x" versioning system *is* being up-front with people.
If instead of suggesting: "can you switch to a 1.0 major version that you increment quarterly", you're instead suggesting: "can you stabilize the API and not release breaking changes quarterly" I think those are two entirely different requests. Your first post made the former request, which is what I was responding to.
I think it depends on how the developer views 0.x releases. In Bevy's case there has been discussions around backwards compatibility and I think it'll happen but right now it doesn't make sense until the major systems are in place.
My impression from being in the community for awhile is that the devs don't want to perpetually stay with 0.x releases. It's just that a game engine is a big thing with a lot of moving parts.
We've discussed this pretty recently on GitHub [0].
I'm personally in favor of shipping 1.0 within the next year or so. The most interesting part of that to me is figuring out how to decouple the crates without creating major confusion, in order to reduce trivial plugin churn.
For the most part, this is just marketing and semantics, but Bevy is nearly ready for commercial users and we should start communicating that. Quite a few brave users are already building production games (and non-games), and feedback is generally very good! [1]
[0]: https://github.com/bevyengine/bevy/discussions/9789 [1]: https://github.com/Vrixyz/bevy_awesome_prod
I'm hoping public/private dependencies RFC will help some. One idea we have for a follow up is to declare that you should get the version req for one crate from another.
It can be communicated when it becomes stable and goes to 1.0.0 for the version. Until then it shouldn't dare move past 0.x.0 just because people think it should.
I'm put off by the limited docs. I've read the Bevy book, only takes a few minutes, and just like that I'm out of resources to turn to when I get stuck.
When will the docs improve? I look at the release notes and ideally every one of those features would have several pages of docs. I understand that's a lot of work, and maybe things will have to stabilize before we get full docs?
There's an unofficial complement to the docs that covers a lot of different topics here: https://bevy-cheatbook.github.io/introduction.html
Unfortunately it's somewhat out of date
I mean, Bevy 0.12 was released... Yesterday.
Most pages are for version 0.11 or 0.12 already, and not much changed between the two versions besides the assets, if you already have a game written in 0.11. Together with the release notes, you'll survive :)
Among Bevy contributors (including myself) there is a general hesitance to invest too much time in official learning material that will be obsolete by the next release. Bevy's APIs are beginning to stabilize ... and the appetite (both from users and from Bevy devs) for official material is increasing. The time is coming (soon)!
While you wait, there are a sizeable number of tutorials on YouTube, and we have learning material linked in https://bevyengine.org/assets/#learning as well.
Nit: developers who use bevy should be called bevy devys.
Bevy does have plenty of documentation here: https://docs.rs/bevy/latest/bevy/
What's missing is tutorial type documentation, but individual features are generally documented.
The examples in the github repo are fantastic and cover a lot of ground. That's usually my goto when trying to figure things out.
Any chance for some sort of "Bevy Studio" app to appear in the future?
It's not that I don't like programming, I'm just brutally time-constrained (kids).
Not the author but there's a Bevy Editor on the roadmap.
Yep. Built with Bevy similar to how Godot is self-hosted. They are still figuring out the details like which UI framework to use and how to save scenes. Which abstractions to introduce - nodes like Godot, objects+components like unity, etc? Then debate on how "prefabs" are designed - are they just bundles? Entity and component serialization.... Tons of architectual decisions.
It's coming together.
The UI framework will be bevy_ui just like godot uses godot ui library. What needs to be done is improve it so it can actually work for making a complex app.
Yup! The Bevy Editor is our current highest priority. The first step is building out a new Scene / UI system that will serve as the foundation for the editor (as the Bevy Editor will be built as a Bevy App).
I have a post about this (with working prototypes) here: https://github.com/bevyengine/bevy/discussions/9538
Oh wow, that is a detailed post. Thank you for your hard work!
Thanks for posting - hobby game dev here, know just enough to be dangerous.. if I was going to start a new project, it would be in your engine, seems like it splits the diff between Love + Godot, more robust than Love, not as geared towards novices as Godot.
How opinionated is bevy? Have you ever had to make tradeoffs between features and developer accessibility?
What is the "ideal" project to use bevy for right now?
Yeah, that's not a bad way to describe its positioning.
Currently not a lot of batteries included: the experience is much more like "writing a web app using a framework" than it is "boot up RPG Maker".
Generally speaking, Bevy is extremely flexible, with pretty generous defaults for enabled features to let beginners avoid worrying about toggling feature flags and controlling plugins.
In game engine development, features are typically strictly additive, so features vs developer accessibility isn't a great way to frame the tradeoff. Instead, we often push work into the third-party plugin ecosystem to ease maintenance burden or let it mature.
As for the ideal project, I would either say "solo programmer who wants to learn Rust and game dev for fun", or "small, serious team looking to build an unusual systems-heavy game".
Bevy tries to have its cake and eat it too. We have a large, opinionated featureset (ex: how should rendering code look, high level materials, sprites, meshes, animation, scenes, etc) where everything works nicely together. However we are extremely modular to the point that you can do pretty much anything in Bevy. People build their own renderers, do command line only terminal UIs, custom UI systems, etc etc.
We make tradeoffs all the time. We prioritize accessibility / developer UX to a pretty high degree. But this very rarely means cutting features. The hard part is generally _how_ we expose a feature, not _if_.
"What is the "ideal" project to use bevy for right now?"
Bevy is well suited to many project types. The biggest missing piece is a lack of a visual editor (we are working on this, and while you wait you can use programs like Blender or ldtk to compose your scenes). I'd say the ideal project is (1) Small-to-medium-sized in scope, to help mitigate the risk of using a younger engine (2) doesn't need a full Bevy Editor / can get away with code driven or external-editor-driven scenes.
I’m a rank beginner at game programming, GPU programming, and Rust.
Is it possible to access compute shader functionality through Bevy / Vulkan? Basically, offload arbitrary GPU appopriate calculations to the GPU?
Yup! Here is a Bevy example that simulates Conway's Game Of Life in a compute shader: https://github.com/bevyengine/bevy/blob/main/examples/shader...
Thanks!
Learning here - long time sw eng, but mostly back ends. So I’m starting down the emulator path. Would this work with the display/ui portion of an emu like an 8080/chip8? Since the logic is in the opcodes, most of what I think is needed is displaying vram, ui, windowing (screen, options, stack etc). It is still fuzzy where “ui” ends and “game engine” begins.
Your pages are great and readable!
I suspect that as a visualizer for an emulator, Bevy would be a reasonable fit. You could use Bevy UI or build your own for the emulator interface. You might want to build a custom shader to display emulator outputs. You could also consider doing a custom renderer in Bevy if you see the need. Theres also always the option of dropping down a level and using a graphics api like wgpu (which is the "low level" api we use under the hood that allows us to target Vulkan / DX12 / Metal / OpenGL / WebGL2)
Thanks! I’ll give it a try!
Sweet! Always a suprise to see how much ends up in a release. It seems like the last three weeks there are as much features merged as in the rest of the release window.
Technical question: will there ever be a guide that talks through how the rendering part of bevy works? The graph and all is great, but really difiicult to get into without the help of discord.
Haha yeah we have a tendency to merge a lot of "ready" work near the end.
We do plan to have a thorough rendering guide. We've just been putting it off as the renderer has been (and still is) in flux. Once the dust settles a bit we'll start investing in "documentation on-ramps".
We're building a fairly big WASM app in Bevy (relative to our company's size), and it's been a pleasure to work with the engine.
Bevy and the community are awesome. We needed a couple of tickets worked on, and it was so easy to find one of the core contributors to sponsor and push our request over the line (morph targets).
Thank you so much for everything, Carter! You're building something incredibly important that has fantastic momentum behind it.
Bevy is wonderfully easy to deploy to the web, and people should be checking it out. The community is great, and it's easy to find help.
Thank you for the kind words! Messages like these are what help me push through the hard days.
when we will see dynamic systems and other features necessary to unlock first class bevy scripting?
there are some scripting plugins (mainly focusing on rhai atm) but I feel that they are stonewalled by lack of proper bevy support
i mean regardless of whether the current bevy focus is in rust-only games, there is demand for scripting and people are already scrambling for third party solutions. I don't expect to see first party bevy scripting just yet but I think that bevy should adopt foundations for third party crates to work with
Thanks for creating and maintaining Bevy! Has there been much thought given to embedding Bevy in regular GUIs, say if I wanted to display a 3D model inside of an Iced app? I was only able to find things that worked the other way, embedding Iced in Bevy.
Maybe this would come as part of the Bevy editor that's planned?
To me, Bevy is a completely different way of making games vs traditional engines like Unity, Godot, etc.
There’s no UI or scripting, everything is done in Rust code. This makes it more like more like libGDX and Cocos2D-x.
But unlike those engines, it uses ECS and Rust which makes coding in it completely different. So it’s kind of in its own little island.
I’d love to see successful indie games use Bevy. However, I know most game developers aren’t going to prefer it over the more traditional tools which they’ve been taught and everyone around them is using. I’m not sure the intersection of people who want to make games and people who prefer Rust is large; and even within this intersection, most people aren’t going to dedicate considerable amount of time and effort into learning and using an experimental new engine, they’re going to use something with existing trust and resources.
Personally I think Bevy needs a sort of IDE and scripting language which is powered by Bevy and Rust. This won’t remove the “considerable effort into a new project” obstacle, but it would make Bevy much more inviting to newcomers who don’t have experience with Rust and who would be too intimidated to start from a wall of code (vs a canvas like Unity or Godot where you can have a very basic prototype within hours). Plus, I believe the developer is against scripting languages, but I really think that hot reload and more invasive debugging is necessary and can’t be effectively done in Rust (plus as just mentioned, many game developers will be overwhelmed with Rust and it’s borrow checker). But those are just my thoughts, and right now I don’t have the time, resources, and dedication to implement them myself…
Bevy is structured in a way that you really don't have to interact with the borrow-checker very much. Components and Resources will probably always use owned types, and Querys and Refs let you interact with them without having to worry too much.
I've been playing with Bevy a bit, and I just checked my repo; it has 0 lifetimes.
That is usually the case in Rust. One mostly deals with lifetimes in library code
>However, I know most game developers aren’t going to prefer it over the more traditional tools which they’ve been taught and everyone around them is using
IME, the most time consuming parts of game development is asset management,closely followed by the programming. An engine like Bevy does a lot to try and cut down on bug fix time, but the lack of some sort of asset pipeline means you lose those savings on the asset side. scripting language would help a bit, but the sort of people using Bevy at the moment don't have a strong need for it (very technical people, not necessarily full time designers).
I do strongly look forward to how the Rust community impacts game development, and I want to eventually contribute. But I'm sticking to C++/C# pipelines for the reasons you lay out. I can properly learn rust on the side and perhaps consider it for later projects as tools mature.
> Plus, I believe the developer is against scripting languages, but I really think that hot reload and more invasive debugging is necessary and can’t be effectively done in Rust
I understand where you're coming from, but consider another angle. Hot reloading is often a band-aid around when compilations times grow unwieldy. If your code compiles in 4 seconds on average (and lets say, 20 seconds for a full re-compilation. These numbers are completely arbitrary), then there's not as much need to focus resources on ways to get around full compilations.
That said, I hear Rust in general takes longer to compile programs, so I can imagine the need for scripting/hot reloading to come sooner rather than later. But current indie projects being worked on likely won't run into that barrier.
It should also be mentioned that there are a bunch of ways to improve compile times. Bevy for example has a feature to compile itself as a dylib, which helps avoiding the cost of relinking everything together. The Cranelift backend for rustc will also help reducing compile times in debug mode. In Bevy's case it could be used for the binary crate only, leaving Bevy itself and other dependencies built with optimizations and dynamically linked, while the binary crate gets rebuilt very quickly but with less optimizations.
Hot reloading still has a place for quickly prototyping thanks to not resetting the state of the running program, but this is a lot trickier to do with Rust. I think we'll likely see better scripting support (with hot reload for the scripts) instead.
IDE has been planned for awhile and I believe it’s top priority after this release.
Cart (the creator of bevy) believes bevy should be rust first. Personally I agree, but that doesn’t mean people can’t create plugins for various scripting languages. In fact there are some already.
I've been building a game in Bevy for a while now. Feel free to browse code or ask questions:
https://github.com/MeoMix/symbiants
For me, some pain points so far have been:
- UI system was too verbose to comfortably build widgets. Swapped to using egui, but expect to go back to native Bevy within a year. egui has significant limitations, too.
- Parent/Child relationships don't have a ton of support (ECS sort-of discourages).
- It was tougher than expected to associate a label with a sprite, move/rotate the sprite, and keep the label following position without following rotation.
- Persisting entities across sessions isn't supported out of the box (Entity is intended for client-side uniqueness) and easily regenerating persisted parent/child relationships doesn't happen automatically.
- No support for WASM parallelism yet, but a lot of Bevy architecture design wants system ordering to be flexible to squeeze perf benefits by parallelizing the work.
- Spatial querying feels like it pushes against the goals of ECS. Wanting to look stuff up by value (value of Position) rather than type (entity has Position) results in lots of secondary caches that need to stay sync'ed with query engine.
- Mutating world via `commands` is deferred to batch for perf, but it's hard to have systems which aggressively mutate the world with so many deferred actions. I end up calling `apply_deferred` a lot and using custom commands to resolve races.
- WASM on Android (Pixel 6) + Chrome doesn't work at the moment, but it's a down-stream dependency issue. Should be fixed in Bevy 13.
Pros have been:
- Very nice to work in Rust engine + Rust game.
- Rust + WASM has been good, don't feel like this aspect of the tech gets in the way much
- Once you get your brain thinking ECS it's tough to go back, feels very flexible (maybe too flexible)
- Very lively community, usually easy to find someone to talk to about a problem you're having
- Lots of examples (not a lot of docs, but a lot of examples)
- Lot of optimism about the future. Very strong development pace, each release makes significant headway on concerns.
Heads up, ant.care doesn’t work on my iPhone, tested both in safari and Firefox. The website reloads after a while in an endless loop.
That's pretty interesting. Can you tell me more about your phone specs?
I tested on an iPhone 11 Pro w/ iOS 17 and it worked well.
I’m on ios16, can’t update for unrelated reasons, perhaps it’s that. Other than this, I’m on 13 pro max.
To elaborate, the website loads, I can click “sandbox mode”, I see background being drawn, a sprite appears and then the page reloads.
Okay, thank you! I assume all the Bevy examples load for you fine? https://bevyengine.org/examples/Games/alien-cake-addict/
Yes, they seem to be fine. I’ve tested the linked “alien cake” and “2d gizmos” (from list of examples), both work and no reload happened. I couldn’t do anything with the demos but I suppose mobile input is just not supported there.
>Bevy is a refreshingly simple data-driven game engine built in Rust
All frameworks set out to be simple, clean, and fast implementations of something more established but they lack more fancy bells and whistles. Then as they catch up in features, they became the same complex beasts and the cycle repeats.
I think the test is for this is whether the project is willing to break with the past to _keep_ the api simple, clean, and fast. You're right that is easier for new projects who have no backward compatibility to speak of. From what I've seen bevy has a strong culture of demanding good ergonomics for the users and reducing the api surface, and maybe it's thanks to rust's packaging, but they're very willing to break with the past to get it, which I appreciate.
The nice thing too is with cargo, should you ever commit to bevy, they can break the future, and you don't have to chase a moving target. You can just stick to your version. But they also provide guides to make moving up to the latest and greatest easy. Or at least that's been my experience as a bevy dabbler.
I don't disagree, but Bevy has something going for it that most other frameworks don't - modularity. Not just in concept, but something that's proven to actually work out well in practice.
Tiny glade is a game that uses bevy_ecs, but doesn't use bevy's rendering crates at all. Personally I have several WIP PRs that implement alternative rendering paths (raytracing, GPU-driven meshlet + visibility buffer rendering) and nothing internal to Bevy really changes. For users, again nothing really changes, they just add a FeatureFooPlugin to their app and then use FooComponent or whatever and it all works.
While individual crates/plugins might get bloated, Bevy as a whole will be fine. Users can choose to ignore those plugins, and use something else that works better for them.
I would also like to point out that this is a game engine - by definition, they're bloated and complex beasts, and absorb every feature under the sun because _someone_ will have a use case for some kind of game. The key is how the feature bloat affects ergonomics. It's totally fine to have 1000 features, as long as you don't _need_ to interact with most of them unless you want to.
This is a reasonable "broad strokes" view of the lifecycle of a software project. But it could be applied to literally any claim about software simplicity / ease-of-use, so I don't find it to be a particularly helpful critique. The takeaway appears to be "all easy-to-use software that adds features is doomed", which seems a bit dramatic.
Do you have specific ideas (or concerns) about how Bevy is architected (or how it adds new features)? We're doing our best to avoid this fate.
I saw a joke that there are 5 games written in Rust, and 50 game engines.
Is there a list of actual games written in Bevy?
Plenty!
Tiny Glade (https://pouncelight.games/tiny-glade) Super popular ... lots of social media presence. Uses Bevy ECS / Bevy App + a custom renderer. https://store.steampowered.com/app/2198150/Tiny_Glade/
tunnet (https://puzzled-squid.itch.io/tunnet)
Noumenal (https://noumenal.app/) Foresight Mining (https://www.foresightmining.com/) Mining "CAD" software. Employs a number of Bevy devs
Axie Infinity: Homeland (https://app.axieinfinity.com/games/homeland-alpha/). Uses Bevy ECS + Unity Shifting Chamber (https://maciekglowka.itch.io/shifting-chamber)
Hytopia (https://hytopia.com/)
Titleless Comfy City Builder (https://twitter.com/i_am_feenster/status/1710714877231186323)
Molecoole (https://store.steampowered.com/app/1792170/Molecoole/)
Titleless industrial revolution builder (https://twitter.com/ElmoSampedro/status/1684920884811698176)
Jarl Game (https://twitter.com/jarl_game) Dwarf Fortress-like with cool dynamic lighting
The "bevy" tag on itch.io has hundreds of games: https://itch.io/games/tag-bevy Also lots of activity in the #showcase channel on the Bevy discord.
I just played Not Snake (https://ramirezmike2.itch.io/not-snake) after finding it in the Bevy tag. It's pretty fun. I'll definitely check out some of the other games there.
Keep up the good work.
just tried it, pretty fun game :)
I was looking at the web examples and saw the ui section which seems to all be done inside the canvas. Is it possible to do the ui in the dom instead and hook it up to the wasm?
Yup I've seen this done before! You need to build a way to pass information to/from the UI to Bevy. Plenty of ways to do this, both from the Rust (wasm) side (ex: web_sys) or the Javascript side (invoking wasm functions)
The article claims that deferred rendering doesn't support MSAA, but this is only true for a naive implementation.
You can, for example, generate a stencil mask of complex pixels in the prepass and use hierarchical early stencil reject to run a per-sample pass for complex pixels and a per-pixel pass for non-complex pixels (with imperfect SIMD lane utilization).
You can also use a pass to process the complex pixels mask and collect a buffer of (x, y, sample) coordinates to allow a later single hybrid per-pixel/per-sample compute shader pass with perfect SIMD lane utilization.
Noted!
Bevy is a lot of fun to play with and least the versions I toyed around with had pretty good docs too.
Very cool!! On the last update 0.10 -> 0.11, I had to make quite a few changes on my app, but this time it compiled out of the box!
Fantastic release notes.
Perhaps some of this is too introductory for seasoned game/engine developers, but as someone who doesn't live in those worlds regularly i found this struck an excellent balance between discussing changes and explaining topics in a consumable way. Bravo!
Do any commercial video games that use Bevy exist? Could I find somewhere a list of games using the engine?
Amazing progress. Any updates on UI overhaul or planned timeline for it? I'm looking to make Bevy my go-to for GUI as well as for games (sometimes the line is blurred).
Bevy's creator and project lead here. Feel free to ask me anything!