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.
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?
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.
What's missing is tutorial type documentation, but individual features are generally documented.
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?
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.
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".
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...
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.
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
It's not that I don't like programming, I'm just brutally time-constrained (kids).
I have a post about this (with working prototypes) here: https://github.com/bevyengine/bevy/discussions/9538
Is it possible to access compute shader functionality through Bevy / Vulkan? Basically, offload arbitrary GPU appopriate calculations to the GPU?
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.
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".
Maybe this would come as part of the Bevy editor that's planned?
Your pages are great and readable!
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?
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.
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
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…
I've been playing with Bevy a bit, and I just checked my repo; it has 0 lifetimes.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I tested on an iPhone 11 Pro w/ iOS 17 and it worked well.
Is there a list of actual games written in Bevy?
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.
Keep up the good work.
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!
