Bevy 0.9: data oriented game engine built in Rust(bevyengine.org)
bevyengine.org
Bevy 0.9: data oriented game engine built in Rust
https://bevyengine.org/news/bevy-0-9/
4 comments
Creator and lead developer of Bevy here. Feel free to ask me anything!
Oh! I have so much to ask you but feel so ill prepared! I literally have the Bevvy website open-and-pinned in my browser at the moment.
I have never written in Rust or built a serious game, but have 10+ years programming experience and have worked heavily in frameworkless canvas/webgl rendering. I've become very used to declarative programming after sinking my teeth into React. As I start to learn more about game programming I've realized that almost all engines expect an imperative approach.
Recently, started poking at game engines trying to find something reasonable. I thought I'd start with PixiJS + react-pixi (not a full engine, I know), but found my FPS getting absolutely crushed trying to run a simulation game through React's reconciler. Code was simple to reason about, though! I started to feel like I was forcing a round peg through a square hole by doubling-down on React frameworks to interface with WebGL. So, I'm abandoning that approach and looking for other options that don't push me towards a fully imperative approach.
Bevvy is, by an incredibly large margin, what I am most interested in using. If there were even vague notions of having a stable API in the next year I'd start building now, but I am trying to be respectful of the message on your website, "If you are currently trying to pick an engine for your Next Big Project™, we recommend that you check out Godot Engine. "
Do you have any estimations on when you might reach 1.0? Do you have guidance on which areas you feel are most stable and/or experimental? If I'm a noob with game development am I likely to challenge Bevvy in ways that I'd regret as the interface changes or is it too early to tell?
What trade-offs are you making in building Bevvy that would cause someone to choose Godot over your long-term vision?
Are there any concerns specific to Bevvy around compiling its output to WASM? I assume not, but might as well ask.
I have never written in Rust or built a serious game, but have 10+ years programming experience and have worked heavily in frameworkless canvas/webgl rendering. I've become very used to declarative programming after sinking my teeth into React. As I start to learn more about game programming I've realized that almost all engines expect an imperative approach.
Recently, started poking at game engines trying to find something reasonable. I thought I'd start with PixiJS + react-pixi (not a full engine, I know), but found my FPS getting absolutely crushed trying to run a simulation game through React's reconciler. Code was simple to reason about, though! I started to feel like I was forcing a round peg through a square hole by doubling-down on React frameworks to interface with WebGL. So, I'm abandoning that approach and looking for other options that don't push me towards a fully imperative approach.
Bevvy is, by an incredibly large margin, what I am most interested in using. If there were even vague notions of having a stable API in the next year I'd start building now, but I am trying to be respectful of the message on your website, "If you are currently trying to pick an engine for your Next Big Project™, we recommend that you check out Godot Engine. "
Do you have any estimations on when you might reach 1.0? Do you have guidance on which areas you feel are most stable and/or experimental? If I'm a noob with game development am I likely to challenge Bevvy in ways that I'd regret as the interface changes or is it too early to tell?
What trade-offs are you making in building Bevvy that would cause someone to choose Godot over your long-term vision?
Are there any concerns specific to Bevvy around compiling its output to WASM? I assume not, but might as well ask.
So, I'm currently part of a team making a Real Commercial Video Game in Bevy. The stability issues aren't bad: it's half a day of work fixing compiler errors every 3 months, even on a massive project. The Rust compiler (and tests!) make it way easier, and ecosystem crates are pretty good about updating (and will often merge PRs to do so, even if the author isn't super active).
I would expect 1.0 in two to three years, but of course, that's not a promise.
Missing features are definitely the larger challenge still: animation is crude, there's no editor yet (but `bevy_inspector_egui` rocks), UI is very heavy on boilerplate and needs widgets. But the ability to rapidly prototype and refactor rock-solid, high performance gameplay code simply can't be matched. Rust's type system makes writing robust code easy and Bevy's ECS nearly eliminates data plumbing nuisances.
> What trade-offs are you making in building Bevvy that would cause someone to choose Godot over your long-term vision?
Even in the long-term, I would choose Godot if you're looking for a more traditional, editor-driven approach. Bevy is likely to prioritize code over nodes for gameplay purposes, and you really want anyone implementing game designs to have some Rust (it's not that bad when working in an established framework!).
> Are there any concerns specific to Bevvy around compiling its output to WASM? I assume not, but might as well ask.
Bevy generally works quite well on WASM [0], but there's some frustrations. Audio has weirdness at startup, there are random compiler issues, some graphics APIs are unavailable, and of course, parallelism is still very limited. Steadily improving, but most of that work is being done upstream from us.
[0]: https://itch.io/jam/bevy-jam-2
I would expect 1.0 in two to three years, but of course, that's not a promise.
Missing features are definitely the larger challenge still: animation is crude, there's no editor yet (but `bevy_inspector_egui` rocks), UI is very heavy on boilerplate and needs widgets. But the ability to rapidly prototype and refactor rock-solid, high performance gameplay code simply can't be matched. Rust's type system makes writing robust code easy and Bevy's ECS nearly eliminates data plumbing nuisances.
> What trade-offs are you making in building Bevvy that would cause someone to choose Godot over your long-term vision?
Even in the long-term, I would choose Godot if you're looking for a more traditional, editor-driven approach. Bevy is likely to prioritize code over nodes for gameplay purposes, and you really want anyone implementing game designs to have some Rust (it's not that bad when working in an established framework!).
> Are there any concerns specific to Bevvy around compiling its output to WASM? I assume not, but might as well ask.
Bevy generally works quite well on WASM [0], but there's some frustrations. Audio has weirdness at startup, there are random compiler issues, some graphics APIs are unavailable, and of course, parallelism is still very limited. Steadily improving, but most of that work is being done upstream from us.
[0]: https://itch.io/jam/bevy-jam-2
Awesome! Thank you for the thoughtful response. It's really encouraging to hear that a RCVG™ is building using Bevy and happy with it! I'll start playing this weekend based on that feedback.
I am not super interested in an editor-driven approach at the moment, but perhaps I'll regret that as the project grows in complexity.
Thanks for the specific remarks on WASM, Animation FX, etc. I'll be happy with those problems if I can get my project to the point of experiencing them.
Good luck on your project! Let me know when it's out and I'll give it a spin :)
I am not super interested in an editor-driven approach at the moment, but perhaps I'll regret that as the project grows in complexity.
Thanks for the specific remarks on WASM, Animation FX, etc. I'll be happy with those problems if I can get my project to the point of experiencing them.
Good luck on your project! Let me know when it's out and I'll give it a spin :)
It's called Bevy and not Bevvy
I know of a few ROS (Robot Operating System) community members that use Bevy to simulate hundreds to thousands of mobile robots in various commercial and industrial contexts, finding it operates drastically better than Gazebo Sim
Does your team exclusively focus on game dev? How aware are you of non-gaming applications where Bevy works great?
Does your team exclusively focus on game dev? How aware are you of non-gaming applications where Bevy works great?
Another maintainer: very aware of it, Foresight Mining Software Company is a major force in the ecosystem and makes CAD tools! We try to be responsive to the needs of those communities (robotics, CAD, GIS, scientific simulation...), but focus on tackling the needs of game development first.
Definitely naturally synergy here though, and the flexible model makes it very easy for different groups of users to pick and choose what they care about.
Definitely naturally synergy here though, and the flexible model makes it very easy for different groups of users to pick and choose what they care about.
Hi, sorry if this question might not be appropriate but I was wondering what are the main differences between Godot's way of doing things and Bevy's.
Also more importantly thank you for the work you've done on Bevy! For someone like me picking up Rust recently it's great knowing I can even develop games in it without going into the nitty-gritty part of game dev.
Also more importantly thank you for the work you've done on Bevy! For someone like me picking up Rust recently it's great knowing I can even develop games in it without going into the nitty-gritty part of game dev.
I've summarized a lot of my thoughts in this blog post: https://bevyengine.org/news/bevys-first-birthday/#things-i-m...
But in short (slight copy-paste of my generic Bevy pitch):
The Developer's Engine: most engines are built using multiple languages, with significant abstraction between "user code" and "engine code". Bevy is built with a consistent stack and data model (see the blog post I linked to for details). If you "go to definition" on a Bevy app symbol in your IDE, the underlying engine code will look the same as your app code. You can also swap out basically everything. We have a vibrant plugin ecosystem (https://bevyengine.org/assets) as a result. These blurred lines also make it _way_ easier for "Bevy app developers" to make direct contributions to the engine. Bevy App developers _are_ Bevy Engine developers, they just don't know it yet. The new Bevy renderer (in 0.6) was also built with this principle in mind. It exposes low, mid, and high level renderer apis in a way that makes it easy to "insert yourself" into the engine.
Fully embraces ECS: No popular engines are currently all-in on ECS (either they have no official support ... or they are half-in half-out). I reflect on some of the benefits we've enjoyed thanks to Bevy ECS in the blog post I linked to. Note that there is _a lot_ of pro _and_ anti ECS hype. Don't just blindly follow dogma and hype trains. ECS isn't one thing and Bevy ECS intentionally blurs the lines between paradigms.
We can't currently compete with the "big engines" on features, but we are adding features at a rapid (and growing) pace. Bevy was released about a year and a half ago. Most popular engines have been in development for almost 20 years (Godot since 2007, Unity since 2005, Unreal since 1998), so we have plenty of "time" from my perspective.
I'm a huge fan of Godot and used it to build my game High Hat over the course of about 4 years. I also contributed to it every once and awhile. When I was initially building Bevy, Godot's design decisions were always at the top of my mind (and they still are to this day). I love they way they do scenes (and our system draws inspiration from it). We also plan on borrowing their "dogfooding" approach to editor building (the Bevy Editor will be a normal Bevy App).
But in short (slight copy-paste of my generic Bevy pitch):
The Developer's Engine: most engines are built using multiple languages, with significant abstraction between "user code" and "engine code". Bevy is built with a consistent stack and data model (see the blog post I linked to for details). If you "go to definition" on a Bevy app symbol in your IDE, the underlying engine code will look the same as your app code. You can also swap out basically everything. We have a vibrant plugin ecosystem (https://bevyengine.org/assets) as a result. These blurred lines also make it _way_ easier for "Bevy app developers" to make direct contributions to the engine. Bevy App developers _are_ Bevy Engine developers, they just don't know it yet. The new Bevy renderer (in 0.6) was also built with this principle in mind. It exposes low, mid, and high level renderer apis in a way that makes it easy to "insert yourself" into the engine.
Fully embraces ECS: No popular engines are currently all-in on ECS (either they have no official support ... or they are half-in half-out). I reflect on some of the benefits we've enjoyed thanks to Bevy ECS in the blog post I linked to. Note that there is _a lot_ of pro _and_ anti ECS hype. Don't just blindly follow dogma and hype trains. ECS isn't one thing and Bevy ECS intentionally blurs the lines between paradigms.
We can't currently compete with the "big engines" on features, but we are adding features at a rapid (and growing) pace. Bevy was released about a year and a half ago. Most popular engines have been in development for almost 20 years (Godot since 2007, Unity since 2005, Unreal since 1998), so we have plenty of "time" from my perspective.
I'm a huge fan of Godot and used it to build my game High Hat over the course of about 4 years. I also contributed to it every once and awhile. When I was initially building Bevy, Godot's design decisions were always at the top of my mind (and they still are to this day). I love they way they do scenes (and our system draws inspiration from it). We also plan on borrowing their "dogfooding" approach to editor building (the Bevy Editor will be a normal Bevy App).
Slight correction needed caused by the aforementioned copy/paste: Bevy was released a little over two years ago, not the one and a half stated above. Sorry for the confusion! I'll have to update my elevator pitch text :)
Thank you! I'm even more excited for Bevy after you've put the engine development timelines into perspective!
As far as I understand Bevy isn't built on top of the latest fully featured graphics APIs such as DirectX 12 and Vulkan (with ray tracing, mesh shaders, and all the latest features) but on an ex firefox's library that was supposed to implement the yet unfinished WebGpu standard which doesn't have a lot of the more modern features (And it's not known when it will have them). Is there some escape hatch in wgpu that allows access to the more modern features? Or maybe not targeting them was a deliberate choice in Bevy's design/strategy?
wgpu (the implementation, not the WebGPU standard) does have quite a few of those aforementioned escape hatches on native platforms. Bevy currently doesn't use many of them due to aiming for maximum platform compatibility, but their use is not off the table.
Haven’t really looked into Bevy much before but it looks like a great engine with a nice clean data oriented design.
I’m curious as to what level of functionality it has beyond the basic nuts and bolts. Is there readymade support (either built-in to the engine or via community libraries) for features like skeletal animation, terrains, collision detection, text rendering, and prebuilt UI elements?
I’m curious as to what level of functionality it has beyond the basic nuts and bolts. Is there readymade support (either built-in to the engine or via community libraries) for features like skeletal animation, terrains, collision detection, text rendering, and prebuilt UI elements?
Skeletal animation is supported in the renderer, and there is a (very basic) implementation of an animation player available, but more complex animation (blending, state machines, masking, IK, etc.) is currently still in the design phase right now.
Terrain and collision detection are currently reliant on a third party ecosystem integration with rapier via bevy_rapier. It may be a while before Bevy has a native physics system.
Text rendering is fully supported, and IMO is significantly better looking than anything Unity currently offers by default, though that might not be a particularly high bar, haha.
Prebuilt UI elements are in the works but not upstreamed in any way right now. The UI system has a lot of flexbox-esque primitives that currently lack a way to bind it to gameplay elements. This is a very active area of development though, given that the goal is to dogfood these UI elements for the engine's editor.
Terrain and collision detection are currently reliant on a third party ecosystem integration with rapier via bevy_rapier. It may be a while before Bevy has a native physics system.
Text rendering is fully supported, and IMO is significantly better looking than anything Unity currently offers by default, though that might not be a particularly high bar, haha.
Prebuilt UI elements are in the works but not upstreamed in any way right now. The UI system has a lot of flexbox-esque primitives that currently lack a way to bind it to gameplay elements. This is a very active area of development though, given that the goal is to dogfood these UI elements for the engine's editor.
Could you explain a bit more what "Data Oriented" means in this context? How is it different from the main stream engines?
I've only done a bit of game dev as a hobby, and have only worked with a few of the usual suspects (unity, unreal, etc), so I might be missing the big picture.
The engine looks great, and I'm excited to give it a go when I get some free time.
Thanks!
I've only done a bit of game dev as a hobby, and have only worked with a few of the usual suspects (unity, unreal, etc), so I might be missing the big picture.
The engine looks great, and I'm excited to give it a go when I get some free time.
Thanks!
Data oriented design is about designing for data locality, so that at runtime the program will utilise CPU caches efficiently.
http://gameprogrammingpatterns.com/data-locality.html
http://gameprogrammingpatterns.com/data-locality.html
In short, the implementation (and this applies to ECSs in general) tries to optimize data access for cache locality, and the APIs exposed to the users don't abstract over that principle too much.
Congrats on the new release!
In the near future I want to begin work on a server-side renderer (3D scene -> video) and a web-based scene editor. Would Bevy deployed as WASM be a reasonable choice for this?
In the near future I want to begin work on a server-side renderer (3D scene -> video) and a web-based scene editor. Would Bevy deployed as WASM be a reasonable choice for this?
Server side rendering is interesting because Bevy uses GPU apis for rendering, and finding servers with GPUs is harder. But we do support "headless" rendering to images without a window, and there are CPU-only shims that implement GPU apis.
As for the web-based scene editor, Bevy is perfect for that scenario. We already have good WASM support, and we'll be building our own scene editor directly in Bevy.
As for the web-based scene editor, Bevy is perfect for that scenario. We already have good WASM support, and we'll be building our own scene editor directly in Bevy.
Brilliant info, thanks!
How far along is the Bevy UI toolkit? From what I've heard, it seems fairly common to use an external GUI toolkit like egui in Bevy projects. Is anyone using Bevy UI in production yet?
Totally fine for simple game menus, but heavy on boilerplate.
It needs more widgets, the data flow needs some love, and text rendering is so-so. We're steadily improving it though, and every release it really does get better.
It needs more widgets, the data flow needs some love, and text rendering is so-so. We're steadily improving it though, and every release it really does get better.
Are there plans to reduce boilerplate on the UI? What about adopting the Elm architecture?
What about using egui, iced, etc? The problem is lack of integration with ECS, right? But you can still draw inspiration from them I guess?
What about using egui, iced, etc? The problem is lack of integration with ECS, right? But you can still draw inspiration from them I guess?
What does data oriented mean in this context? My gamedev experience is limited to writing MUDs and roguelikes over two decades ago so I have basically no context.
https://en.wikipedia.org/wiki/Data-oriented_design
The intent is to layout structures in memory in a way that is conducive to how it's actually accessed in the physical hardware.
For video games, this typically means leveraging contiguous pieces of memory to minimize cache misses while iterating over the objects in the game. This can see some huge performance gains over other ways of structuring the game's code.
Think of Bevy's ECS as a ultra-high performance in-memory columnar database that you're scanning 60+ times a second. Then building your game as a series of (potentially parallelizable) mutative queries over that database.
The intent is to layout structures in memory in a way that is conducive to how it's actually accessed in the physical hardware.
For video games, this typically means leveraging contiguous pieces of memory to minimize cache misses while iterating over the objects in the game. This can see some huge performance gains over other ways of structuring the game's code.
Think of Bevy's ECS as a ultra-high performance in-memory columnar database that you're scanning 60+ times a second. Then building your game as a series of (potentially parallelizable) mutative queries over that database.
It is a pretty broad term, but it generally implies some combination of cache-friendly design and composable (sometimes component-driven) behaviors. ECS intersects with it, but "data oriented" is a much broader category.
What are your feelings on the direction of game engines across the industry right now?
What is an innovation you hope you see wider adoption of in the space?
Thank you for your efforts!
What is an innovation you hope you see wider adoption of in the space?
Thank you for your efforts!
Some broad strokes on hot topics:
Raytracing: Exciting, useful, pretty. We need to support it asap. A pull request was recently opened to add initial support to Bevy's low level gpu abstraction (wgpu), so I'm excited!
Nanite-style rendering: Very cool. Not yet sure its the best approach for Bevy, but I'd love to explore this!
Proprietary Engines Taking Cuts Of Sales: Game developers should be investing their time in open tooling without contracts or restrictive licensing. We have the experience. We should own our own tools. And there are so many more of us than there are Unity or Unreal developers. Proprietary tooling is a massive loss of potential.
AI Generated Art and Code: empowering and definitely the future, but currently an ethical disaster. Licenses are ignored. Artist's work and identity is assimilated without consent.
Raytracing: Exciting, useful, pretty. We need to support it asap. A pull request was recently opened to add initial support to Bevy's low level gpu abstraction (wgpu), so I'm excited!
Nanite-style rendering: Very cool. Not yet sure its the best approach for Bevy, but I'd love to explore this!
Proprietary Engines Taking Cuts Of Sales: Game developers should be investing their time in open tooling without contracts or restrictive licensing. We have the experience. We should own our own tools. And there are so many more of us than there are Unity or Unreal developers. Proprietary tooling is a massive loss of potential.
AI Generated Art and Code: empowering and definitely the future, but currently an ethical disaster. Licenses are ignored. Artist's work and identity is assimilated without consent.
> Game developers should be investing their time in open tooling without contracts or restrictive licensing
Unfortunately, this is not possible in consoles, because of issues with NDA. Even Bevy can't have an open licensing there: https://github.com/rust-gamedev/wg/issues/90 (Godot also can't: https://docs.godotengine.org/en/stable/tutorials/platform/co...)
I expect that Bevy ports to consoles will take a cut of sales rather than a flat fee :(
Unfortunately, this is not possible in consoles, because of issues with NDA. Even Bevy can't have an open licensing there: https://github.com/rust-gamedev/wg/issues/90 (Godot also can't: https://docs.godotengine.org/en/stable/tutorials/platform/co...)
I expect that Bevy ports to consoles will take a cut of sales rather than a flat fee :(
From what I've heard with Godot there's basically two paths you can take there. Pay another studio who has experience getting the engine to run on consoles to share their engine modifications with you or even port your game to the console for you, or you can have your developers take the time to get the engine working on the consoles yourself. For a studio without many engine programmers, the former is probably more likely to happen and they may either take a cut or charge a flat fee, but the option to do the engineering yourself is still always on the table.
The ECS looks really nice. Can it be used independently of the rest of Bevy?
Yup! Bevy ECS is a fully standalone Rust ECS library.
How are entity id's managed? When an entity "dies", can its id be re-used?
From a Rust-on-WASM perspective, it might be useful to limit the entity id's to ~52 bits or less, since native JavaScript numbers are doubles.
From a Rust-on-WASM perspective, it might be useful to limit the entity id's to ~52 bits or less, since native JavaScript numbers are doubles.
> From a Rust-on-WASM perspective, it might be useful to limit the entity id's to ~52 bits or less, since native JavaScript numbers are doubles.
Since compiling to web uses WebAssembly, we can just use native 64 bit integers for our entities. In general, we avoid introducing differences between web and native targets, and this is no exception.
If you do need to round-trip full entities using JavaScript, you should either store them in one of the native non-broken integer types (such as `BigInt` or `BigUint64Array`), or just store the `index` and `generation` as seperate `number`s. It's worth recognising that in most cases, you should only need to exchange the entity `id` with different systems, as the `generation` is mainly used to panic on use-after-free conditions.
Since compiling to web uses WebAssembly, we can just use native 64 bit integers for our entities. In general, we avoid introducing differences between web and native targets, and this is no exception.
If you do need to round-trip full entities using JavaScript, you should either store them in one of the native non-broken integer types (such as `BigInt` or `BigUint64Array`), or just store the `index` and `generation` as seperate `number`s. It's worth recognising that in most cases, you should only need to exchange the entity `id` with different systems, as the `generation` is mainly used to panic on use-after-free conditions.
Entity as a type is an generational ID. We only support up to 2^32 entities in a World, which makes up the bottom 32 bits. The top 32 bits is the generation. Once we destroy an entity, it's ID is reused, but the generation is increased.
Entity is essentially a u64, which is composed of a 32 bit index and a 32 bit generation. Despawned entities free their index, and which ever new Entity takes its place gets a new generation.
cowtools(1)
Pardon my lack of technical terms, but when I worked with Bevy in 0.7, applying a part of a texture to a surface was really difficult. (It wants to apply the entire texture, and stretch it to fit.)
Has this improved?
Has this improved?
This is already possible if you control the mesh UVs and/or the shader (both in 2D and 3D). In Bevy 0.9, in 2D sprites can now define the bounds of the texture they want to display.
Discussed recently 4, 7 and 10 months ago
https://news.ycombinator.com/item?id=32287828 18 comments
https://news.ycombinator.com/item?id=31043668 63 comments
https://news.ycombinator.com/item?id=29854416 89 comments
https://news.ycombinator.com/item?id=32287828 18 comments
https://news.ycombinator.com/item?id=31043668 63 comments
https://news.ycombinator.com/item?id=29854416 89 comments
Those are different releases.
Per dang@https://news.ycombinator.com/item?id=23071428 [2020]
Yes but for the most part, releases (within a year or so) are HN dupes short of big doses of snee. Otherwise the front page would look like the freshmeat.net of yore.
"snee" = "SNI" = "significant new information" which is sort of a moderation buzzword
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
would be a fair point if the releases weren't actually significant changes
We're certainly not denying that the work is significant and valuable! From an HN point of view, the only question is whether the submissions are different enough to support substantially different discussions in the thread.
[deleted]
[deleted]