Bevy 0.8: data oriented game engine built in Rust | Hacker News Reader

Bevy 0.8: data oriented game engine built in Rust

bevyengine.org

97 points_cart18 comments

I watched a recorded livestream the other day of a game developer making a game in Bevy. It was maybe the 5th one and I hadn't caught the first 4. It had about 500 views. The video started off reviewing a PR made by a viewer who improved the inventory system they had going on as well as a few other contributions.

It was delightful to watch. Regardless of any criticisms of Rust compared to other "next C++" languages (e.g. Zig, Vale, Hare, Odin, Carbon, etc) the amazing community is what's already ensured Rust's place at the top made me realize that the community is going to drive Rust to stardom

Was it https://youtu.be/jkHqrkcEHRc ?

No. Like I said it was some recorded livestream. The video was like an hour long and kind of a "code-along" vibe. It's literally just someone recording themselves making some (rogue-like crafting/survival?) game in Bevy

The pace of Bevy improvement is amazing. I think the current lack of an editor may almost be a blessing in disguise - game engines like Unity invest a ton of effort into their editor and if you don't use it you start to feel the pain of leaving the beaten path. (e.g. built-in unity components with fields that can't be easily modified through scripting, or have crazy-unintuitive APIs). Bevy has no such distractions and they put a lot of effort in making their API great. (You can see multiple examples of that into these release notes!) Though Bevy is still limited, it's not uncommon for me to write something in Bevy and imagine what a pain it would have been in Unity. The reverse is true even more often, but that's because Unity has a huge first-party library of plug-n-play features like pathfinding and physics that Bevy simply doesn't have yet. When bevy is nicer, it's because their architecture and API is nicer :D

Edit: this is coming from an ex-professional Unity dev

Nice to see this release!

I hope the rendering pipeline is much more ergonomic -- I found doing shaders in Bevy 0.7 was incredibly painful. Most things in Bevy just "make sense", but the render internals were somehow both low-level (lots of explicit memory sizing and boilerplate) and convoluted (think FizzBuzzEnterpriseEdition). It doesn't help that WGPU and WGSL have very limited resources online compared to, well, OpenGL and GLSL or anything DirectX. It almost made me just reach for good old C++, especially since the normally amazing Rust errors were absolutely terrible with anything going on in render land. Hopefully I can check out 0.8 soon and see those improvements!

I hope Bevy going forward continues to put a lot of effort into the render pipeline so it is as ergonomic and intuitive as the rest of it. I think the ECS core is absolutely brilliant -- the rest just needs to be at the same level. A challenging language plus a difficult render path and a niche library (WGPU) is a tough sell to game devs IMO.

Lead Bevy developer (and creator) here. Ask me anything!

Outside of the docs on your site, are there good community tutorials for Bevy?

Bevy Community-Made Learning Materials: https://bevyengine.org/assets/#learning

Some Youtube Content: https://www.youtube.com/playlist?list=PL6uRoaCCw7GN_lJxpKS3j...

https://www.youtube.com/channel/UC7v3YEDa603x_84PgCPytzA

https://www.youtube.com/c/chrisbiscardi/featured

Here is a bevy video tutorial I did: https://youtu.be/j7qHwb7geIM

Source on GitHub.

What are some projects where people use Bevy for simulations (as opposed to gaming)? It’s something I’m going to do, and I’d love to see how it’s worked out for others.

I wrote a thesis for my bachelor's regarding the development of an agent-based simulation framework in Rust where I managed the visualization side. The project takes inspiration from other frameworks such as MASON (in particular for the architecture), NetLogo, Agent.jl and others. I initially developed the visualization subsystem with Amethyst, after my thesis Amethyst was discontinued and, since I was already following Bevy since it went public and it looked like it was gaining a lot of momentum, I refactored our framework to switch to Bevy. Our project is open source: https://github.com/krABMaga/krABMaga . Being my first approach to Rust and my first serious greenfield project, I think there are a lot of parts which can be improved, but I was able to get by with my extremely limited knowledge of both Rust and Bevy and obtain decent results. The things I loved the most of Bevy was the low amount of boilerplate code needed, the WASM+WebGL support which allowed me to easily let guests run simulations from our github.io site (https://krabmaga.github.io/) at near native (sequential) performance and, just like the whole Rust ecosystem, the friendliness of the community. Even though I bothered quite a bit on the Discord server since the documentation wasn't the clearest for me back when I started (Bevy 0.5), both the team members and users always led me a hand. I also think the ECS approach is extremely useful for our usecase, by defining agents as entities with the Agent component, along with a system which acts as an event loop by executing a simulation step and triggering the agents' behaviour rules. I also noticed the Bevy team might be interested in the simulation field (https://github.com/bevyengine/bevy/discussions/1678), I am sure more projects of this kind would be hugely appreciated!

I remember reading about the conceptualizing of a Bevy editor of some kind a while ago. I recently tried to find information about its progress but came up empty. What's the current status of the game editor for Bevy?

I was curious too, and found he answered this question during the reddit AMA for this release (https://old.reddit.com/r/rust/comments/wc0sqc/bevy_08/):

We've been peeling back the layers of the "editor onion" for awhile now. We've been focused on "foundational engine systems" since Bevy first released. But from here on out, our focus will be shifting. My next big project is "asset preprocessing", which is an important part of editor workflows. Other prominent Bevy developers have started to shift their focus toward preparing Bevy UI for editor scenarios.

I would like to break ground on the editor by the end of the year and have some sort of scene editor MVP proved out. This is ambitious, but I think it is possible given where we are at now. It will be awhile before we have a final editor workflow sorted out, but this will be an open, iterative process that the community will be able to follow along with as it develops.

Mobile is in a pretty good spot at this point: iOS support is pretty stable now. People have already started publishing Bevy iOS apps to the Apple App Store: https://noumenal.app.

Android is close, but not quite there yet. As of this release, Android builds kind of work again. You can build and deploy android apps, but they lose their renderer context if you suspend or resume the app. Audio also doesn't work yet :)

It is something we've been building toward for awhile. We've been focused on core systems like the renderer and ecs for awhile now, but we're finally at the point where we can start moving up the stack.

We will be focusing on scenes, asset workflows, ui, and the editor from here on out (with scenes, asset workflows, and UI being the focus for the next release).

I'd like to have some sort of editor MVP by the end of the year.

Until then, there are community efforts like: https://github.com/jakobhellermann/bevy_editor_pls

Do you know how big the performance cost would be when scripting with the new ECS APIs? Does the indirection involved mean that we lose some benefits of cache locality?

This Javascript / TypeScript implementation is still doing table + sparse set iteration, so I suspect cache locality is still reasonable. But you'd want to test to be sure.

https://github.com/jakobhellermann/bevy_mod_js_scripting/blo...

Given how new this effort is, I suspect there are plenty of areas with room for improvement.

Bevy 0.7: data oriented game engine built in Rust - https://news.ycombinator.com/item?id=31043668 - April 2022 (63 comments)

Bevy game engine 0.6 - https://news.ycombinator.com/item?id=29854416 - Jan 2022 (89 comments)

Bevy's First Birthday: a year of open source Rust game engine development - https://news.ycombinator.com/item?id=28132114 - Aug 2021 (13 comments)

Bevy 0.5: data oriented game engine built in Rust - https://news.ycombinator.com/item?id=26716166 - April 2021 (65 comments)

Bevy: A game engine built in Rust - https://news.ycombinator.com/item?id=26131350 - Feb 2021 (117 comments)

Bevy 0.4: data oriented game engine built in Rust - https://news.ycombinator.com/item?id=25480321 - Dec 2020 (23 comments)

Making a Snake Clone with Bevy - https://news.ycombinator.com/item?id=24999073 - Nov 2020 (11 comments)

Bevy 0.3: game engine built in Rust - https://news.ycombinator.com/item?id=24983956 - Nov 2020 (55 comments)

Bevy 0.2 - https://news.ycombinator.com/item?id=24530698 - Sept 2020 (43 comments)

Bevy: A Game Engine in Rust - https://news.ycombinator.com/item?id=24334307 - Aug 2020 (42 comments)

Bevy: A data-driven game engine and app framework built in Rust - https://news.ycombinator.com/item?id=24123283 - Aug 2020 (103 comments)

Wow, I remember Bevy 0.7 being recent, wasn't that just released a few months ago? (Update: 0.7 was released 3 months ago, 0.6 was released 6 months ago, Bevy itself was introduced around 2 years ago).

Anyways, Rust seems viable for gamedev and IMO Bevy is taking a great approach wrt the borrow checker (by using ECS, more liberal types even if it technically creates UB). I really hope this project takes off and actually leads to some great games, and maybe it will manage to be less bloated than some other game engines...

> Bevy officially only supports Rust as the "one true way to define app logic". We have very good reasons for this and that philosophy likely won't change any time soon

This is one thing disagree with. At least until/unless Rust gets a way to write code without worrying about borrow checker, like a Rust DSL which provides automatic Cow or Rc<RefCell on everything.

Rust's performance is critical for some game logic but a lot of logic really doesn't need performance, and the borrow checker is going to make that non-performance-sensitive code much harder to write, for no gain. This is especially an issue because most game devs work in teams and have team members who aren't as experienced with performance or the borrow checker or coding in general. It would be nice to have a "sandboxed" environment where a) you don't worry about the borrow checker and b) everything it checked so you don't worry about annoying memory corruption issues, but in exchange the code is a lot slower.

> These, when combined with our reflection APIs, provide the tools needed to start building scripting support!

> @jakobhellermann has started building their own JavaScript / TypeScript plugin for Bevy.

But it looks like they're making it possible to interface with other languages anyways! Which is the right move IMO. The Bevy maintainers and I can disagree with using multiple languages, but it doesn't matter as long as they provide the minimal bare-bones tools to do whatever.

Reply on news.ycombinator.com