Bevy 0.9: data oriented game engine built in Rust

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).

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.

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

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.

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.

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.

http://gameprogrammingpatterns.com/data-locality.html

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.

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.