Bevy 0.9: data oriented game engine built in Rust

https://bevyengine.org/news/bevy-0-9/

by _cart • 4 years ago

176 48 4 years ago

bevyengine.org

_cart8• 4 years ago

Creator and lead developer of Bevy here. Feel free to ask me anything!

prideout2• 4 years ago

The ECS looks really nice. Can it be used independently of the rest of Bevy?

_cart8• 4 years ago

Yup! Bevy ECS is a fully standalone Rust ECS library.

aquariusDue2• 4 years ago

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.

_cart8• 4 years ago

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

Waterluvian• 4 years ago

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?

alice-i-cecile3• 4 years ago

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.

SeanAnderson2• 4 years ago

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.

alice-i-cecile3• 4 years ago

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

nextaccountic3• 4 years ago

It's called Bevy and not Bevvy

mwcampbell• 4 years ago

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?

alice-i-cecile3• 4 years ago

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.

DDSDev• 4 years ago

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!

_cart8• 4 years ago

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.

User23• 4 years ago

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.

_cart8• 4 years ago

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.

james71324• 4 years ago

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.

gkhartman• 4 years ago

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!

turboponyy• 4 years ago

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.

codetrotter• 4 years ago

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

ummonk• 4 years ago

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?

james71324• 4 years ago

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.

nullifidian• 4 years ago

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?

james71324• 4 years ago

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.

echelon2• 4 years ago

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?

_cart8• 4 years ago

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.

pvg3• 4 years ago

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

Narishma• 4 years ago

Those are different releases.

pvg3• 4 years ago

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.

password4321• 4 years ago

Per dang@https://news.ycombinator.com/item?id=23071428 [2020]

brink• 4 years ago

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?

_cart8• 4 years ago

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.

Bevy 0.9: data oriented game engine built in Rust

Related Stories