Bevy: A data-driven game engine and app framework built in Rust | Hacker News Reader

Bevy: A data-driven game engine and app framework built in Rust

bevyengine.org

556 pointsadamnemecek103 comments

Creator of Bevy here. I just announced Bevy yesterday and the response so far has exceeded my wildest expectations.

I'm happy to answer whatever questions people have!

Awesome work! I love how it feels so easy to make a system (I'm actually digging your crates wondering how the hell did you achieve that Trait Extension).

I just hope that the `Turtles All The Way Down` philosophy won't hinder game devs from supporting scripting language of their choice. Because at some point someone is going to need domain specific language somewhere.

Great start here and a very compelling intro post. A couple of things I wondered about and didn't see answers to:

1. How ambitious is Bevy as an engine? Do you see it as aimed squarely at the casual-game space like ggez, or do you think it could eventually compete with Godot, growing more advanced features like GI? (I appreciate that competing with Unreal is probably, well, Unrealistic for the forseeable future.)

2. You talk a lot about keeping the build light, which is great to hear. Does this extend to deployment too? What kind of binary filesizes are you looking at for a "hello, world" game?

1. I want to be ambitious while also being realistic. AAA studios won't even consider using Bevy until it has more features and has stood the test of time. So in the short term our market is essentially "indies and enthusiasts". I want Bevy to cater to those people, but with an eye toward larger projects. We don't want to design ourselves into a "locally optimal" corner that prevents us from appealing to large studio. That being said, even in the short term I am extremely interested in advanced rendering techniques and will be investing a good portion of my time on adding things like GI and PBR.

2. Small binaries is absolutely something I care about. Last time I checked we could produce a "hello world" game with windowing + rendering thats just a little bit over 1 MB. I think we could probably make that smaller with some effort.

edit for some additional clarity: this involved running a post-processing "strip" process on the binary.

As someone who may be tinkering with a game this decade, one big factor which favors “use prebuilt engine” in my thinking is that some of them abstract away the work required to port between different systems. Is this really a very big hurdle in your opinion? And do you see console ports being part of this engine in the future?

The API looks great in any case, and I’ll try it out, at least as a starting point to get back into Rust and ECS. Nice work!

You can't just port something to work on Sony / MS / Nintendo platform, only them manage the toolchain and they just don't usually support things outside of C++ / C#.

Console adoption and porting essentially require a game or games that need to be ported. Typically this happens through third party companies for games built on open source projects.

Video games don't really care about binary size.

Some don't, some do. Users living out in the sticks with poor satellite connectivity care about binary size. The HTML5 platform, which I see becoming increasingly important as things like wasm and webgpu mature, cares about binary size because you're potentially downloading it every time you play. It's slightly surreal poking about on itch.io where practically every game is 50 MB, even when most of them are simpler than a 4k demo.

I would expect that for most games the vast majority of bytes will be assets (textures, models, sounds, etc.), not code. Even reducing the code size to 0 is unlikely to make much of a difference in the total size.

For AAA titles, sure, but there's a long tail of indies, game jam entries etc. For something retro-styled like Dwarf Fortress or Baba Is You, I can absolutely believe that asset size is relatively minor compared to e.g. a Unity baseline footprint.

Harking back to ancient history for a moment, Frontier: Elite II was a AAA title for its day and was basically all code.

The days of all code AAA games is over. Binary sizes are still mostly irrelevant. They matter to you, but they don't matter to the market.

Is this a game engine dedicated to making games for people living out in the sticks, or a game engine for making some serious games?

Sure they do, when targeting consoles and mobile devices.

Their overlords always stress on developer conferences how install size is the number one reason for users to remove applications and games from their devices.

On a console every 1mb of binary is one less mb for assets.

We ran LTCG on every game I shipped.

When your game is 125GB it does not really matters if your dll is 20MB instead of 30, it was the case 15 years ago now it's a much different story.

It does a bit when you have 8GB of shared memory between the graphics card, OS and your game. Download size isn't the only memory constraint affected by binary size.

You're thinking about on-disk space and not in-memory space which is much smaller.

I think you might be underestimating the binary size by at least an order of magnitude

How much control do you have over rendering without having to discard Bevy's renderer and asset server entirely? A big problem I had with Amethyst (and, honestly, other big engines like Unity and Godot) is that you have very little ability to use custom formats that have prebaked visibility, lighting and so forth because there’s no good way to efficiently control how the renderer gets called. You can only convert your scene to their format, usually discarding useful information. I want to use BSP as the level format in my games because I’m familiar with it and it allows for modders to easily create content, but no engine with a pre-built renderer allows you to render them anywhere close to efficiently. This isn’t just being able to have custom file format loaders and render pipelines, you need to be able to have a single vertex buffer while creating a number of index buffers based on various precalculated visibility clusters, and then be able to choose the index buffer to be rendered based on the camera's location.

Hi _cart, creator of Planimeter's Grid Engine (a Lua game engine) here. Congratulations on your phenomenal work! I'm very familiar with the fact that posts like these on HN that help drive adoption, so thanks to adamnemecek as well.

I'm quite excited to give this a try. I'd just point out that I'm seeming to run into errors, even on the examples. I love debugging just as much as the next developer and will probably figure this out, but I thought I would suggest that you get a forum like Stack Exchange or something custom. Most people develop via Google or DuckDuckGo and not being able to Google an error code or make a post is a serious hindrance to development. (Discord is great but not a replacement)

The error that I am currently facing (if you're curious):

EDIT: This is because I was using Rust 1.40 rather than 1.45. Oops.

  $ cargo run --example breakout
     Compiling glam v0.9.3
     Compiling same-file v1.0.6
     Compiling anyhow v1.0.32
     Compiling once_cell v1.4.0
     Compiling adler32 v1.2.0
     Compiling anymap v0.12.1
     Compiling crc32fast v1.2.0
     Compiling remove_dir_all v0.5.3
     Compiling pin-project-internal v0.4.23
  error[E0599]: no method named `map_or` found for type `std::result::Result<std::string::String, std::env::VarError>` in the current scope
   --> /home/myname/.cargo/registry/src/github.com-1ecc6299db9ec823/glam-0.9.3/build.rs:7:10
    |
    7 |         .map_or(false, |cfg| cfg.split(',').find(|&f| f == "sse2").is_some());
    |          ^^^^^^ help: there is a method with a similar name: `map_err`

  error: aborting due to previous error

  For more information about this error, try `rustc --explain E0599`.
  error: could not compile `glam`.
  warning: build failed, waiting for other jobs to finish...
  error: build failed

I hope you don't mind a piece of constructive criticism about the web page but: the syntax coloring scheme you're using makes the comments nearly invisible. Code comments are useful, and therefore should be easily readable, IMHO.

I didn't see anything about networking - is that a feature you intend to include eventually?

Yup! High level and low level networking is definitely on our radar, but it also isn't our immediate priority.

Wow! What great timing. I've been working on CRDTs for the last couple years and realized the structure we're settling on is similar to ECS. Last week, I figured I'd dive into ECS and also scratch my game-making itch by trying out Amethyst. I've had a suspicion that the API could be a bit simpler, and well, you nailed it! After an afternoon of playing around, Bevy has been a pleasure! Really great work!

Congrats! This looks great. The website and the info presented looks very well thought out!

In the features section would really like to see about how Text rendering is handled by Bevy. It is a big feature.

Edit: To clarify, I wanted to know if it uses any known lib (Skia) or technique (signed distance fields) for some fancy text rendering.

Everything is beautiful so far, the website is nice looking, the overview is self-explanitory. If I wasn't so in love with Godot I would use this. I think one thing that would sell this would be an editor like Godot has, it's one of the strongest selling points with Godot for me.

Hey! An editor is definitely on the roadmap. Bevy want's to dogfood here and make the editor using bevy!

That's what I figure, I saw that Bevy does support UIs, which is how Godot makes their own UI, and how RPG In a Box[0] was born from Godot itself (I'm not affiliated with RPG In a Box nor Godot, just someone who is learning Godot). I think it's going to be wonderful to see a spawn of powerful and open source game engines in the coming years.

[0]: https://www.rpginabox.com/

Bevy even mentions Godot as an inspiration for building the editor using Bevy itself. The creator of Bevy has a lot of experience with Godot, so I'd assume we're going to see bits and pieces resembling how Godot works.

I realized that recently, the author is working on a game in Godot as you said. It makes a lot of sense. Godot is a good standard to look up to. I can't wait to see this project as it matures.

For anyone curious this is the game from the author:

https://www.youtube.com/watch?v=FxW4PcX0fa8

It looks like a lot of fun honestly!

The integrated code editor in Godot is actually something I don't like. The text editor doesn't support the usual Mac keyboard shortcuts, scrolling isn't always responsive and it can't be used to view text files such as json files.

I hope that Bevy users won't be forced to use the Bevy editor for coding. VS Code, vim, emacs and other editors have lots of extensions and work well for coding. I'd rather see some kind of project builder UI for Bevy, which would allow using existing code editors.

You're technically allowed to edit code elsewhere I thought? The editor for Godot is there out of convenience. It's also Open Source and I'm sure you could raise issues about these problems. If they're not voiced in the proper channels they might not get resolved.

This is really cool. As someone who doesn't know a lick of Rust I was surprised at how fast I was able to get it installed with the demo running.

The engine really looks awesome and docs are a pleasure to read. Great job!

I have to say the API seems to be very pleasant and simple at a glance. Kudos to the author!

> Being able to use Rust functions directly as systems might feel like magic, but I promise it's not! You may have noticed that we do this when registering systems in our App (...)

> (...) This works because we implement the IntoQuerySystem trait for all functions that match a certain set of function signatures.

This pattern is a great example of how Rust achieves to be both very ergonomic or dynamic (in the sense of expressiveness) and type safe at the same time.

That's pretty cool! Is there any material you'd recommend me reading that gives examples of these kinds of ergonomics with traits as they pertain to, say, vanilla web development?

I merely a beginner and learn the language on the side.

Things that come to mind are (incomplete list):

- From trait

- derive

- traits you can implement to convert a data structure into a iterator

- Deref, Drop traits, MutexGuard

These things appear magical at first but make for very expressive abstractions.

In regards to web-dev: a framework that makes heavy use of traits and macros is Rocket.

As for material: when I’m learning I typically have The Book, Rust by Example and some tabs of the standard library open. Then just go by curiosity. Perhaps not the best approach?

This might be the killer app that finally gets me to use Rust. I've tried so many engine libs/frameworks in so many languages now, and none of them look nearly as complete and ergonomic as this.

I don't really want to have to write my own 3d renderer or ECS because the engine's one is bad or nonexistent... this really scratches an itch for me.

Clojure take note...

Not only that, but the way it is written draws you in. It tells you its scope, function and methodology right from the start. I kept reading but I know little of Rust.

> This might be the killer app that finally gets me to use Rust.

For me that would be a multiplatform GUI library.

Relm looks promising. Actually there are a couple of promising GUI libraries coming up in Rust.

Yes. There's https://areweguiyet.com/

But I'm secretly hoping for a multiplatform GUI library that covers smartphones too. I realize that might be too much to ask though ;)

There are multiple projects which show significant promise to deliver this. In addition to Druid, I've been impressed by Iced, and there are several others that are seeing some development.

MIT License, well done! It's so refreshing to see things released with no strings attached. Yes there is value being created, and the creator should be compensated. But, it's such a breathe of fresh air as a potential end user to not have to worry about intricacies of GPL etc. inclusion.

Yep, it is so refreshing to have shareware and PD back.

This is amazing. Seriously: I had a look at nearly every game engine/GUI solution in Rust and this is by far the most thought out, ergonomic and complete thing I found.

Color me stoked!

Just curious, have you seen amethyst? https://amethyst.rs/

I'm wondering what you find not well thought out about it.

I've tried using Amethyst a few times but never finished anything. Upon each attempt I ended up moving to another language/framework due to the frustration of horrible compile times. Also, while there are lots of comprehensive docs, but the docs were written for a variety of versions so there was a lot of friction to get something simple started. It has been several months since my last attempt, so perhaps Amethyst has improved since then. I do love the promises Amethyst makes and for the same reason I'm very interested in Bevy.

I gave Amethyst a serious try about a year ago. I even joined the Gitter intending to contribute, as I needed some more dynamic rendering features, and read the foundational research on the wiki that seemed to inspire the project.

I found the application of the research -- the execution -- too early in development for my needs. I have the feeling it will grow into something more flexible with time, but at least back then, I wasn't able to render to a texture being applied to a mesh. Not being able to get around the deeply integrated ECS was hard, as well.

I tried Amethyst but found the API had quite rough edges in practise, and there was too much boilerplate for my taste. I certainly had the feeling they did certain things in certain ways not because it was the best solution, but because they didn't find a better way.

This was a while ago so it might not be fair as things probably improved since then and one should definitely give it a try as well.

That being said the whole bevy way of doing things looks very well considered indeed — maybe both projects can profit from each others existence?

Got the chance of running the examples and glance over the code. Also checked the book and docs. As I mentioned in another post about Bevy, it looks incredibly elegant and clean. Almost feels like this could make engine development fun again. And custom engines feasible.

Contrary to popular belief, the need to build your own engine is real for a significant amount of projects. I look forward to being able to quickly put together a few building blocks, customize the renderer and experiment with new systems.

I'd like to see how it compares to https://github.com/amethyst/specs, a rust-based ECS engine, for use in the multiplayer voxel world game Veloren (https://veloren.net), or https://github.com/TomGillen/legion

Here's a writeup comparing Specs (Amethyst sub-project) and Legion ECS. https://csherratt.github.io/blog/posts/specs-and-legion/

There’s not a particularly thrilling benchmark here: https://bevyengine.org/news/introducing-bevy/

Basically an ECS is not really a secret easy pattern to cache coherent data access. This benchmark shows its fast for the easy cases but says nothing about typical game requirements.

ECS has been used relatively heavily in game dev since like late 90's.

So? That has nothing to do with the performance of an implementation which is what I commented on. Data oriented design is about managing data organisation to match access patterns in order to best exploit the hardware cache. That requires more design than simply using the ECS pattern. Which is why a lot of generic engines introduce other concepts like Grouping and Archetypes to try to alleviate this. And even if you do use a generic ECS engine with performance sensitive features it’s still perfectly feasible to end up thrashing.

Also as a claim I also find this highly doubtful particularly as I’ve been working as a game developer for many years and not really seen it used on a single project in that time. There’s a reason why there are dozens of hobby implementations but no full scale games written using them.

Overwatch is built using an ECS. https://youtube.com/watch?v=W3aieHjyNvw

Serious sam and a lot of bohemia interactive games are written with ECS.

They are? Because you can see the source for the Serious Engine 1 here: https://github.com/Croteam-official/Serious-Engine

Looking at that it has way more in common with an OOPish inheritance/composition approach to entities than the ECS view of an entity being a primary key into a data store of components with a pipeline of systems acting in a component centric manner to update the game state.

Just a note that data-driven is not the same as data-oriented-design [1].

I was trying to see how Bevy embraced data-orientation, but I think it doesn't necessarily do so, since data orientation is more about reducing indirection, for ex., reducing or removing excessive data hierarchies. I think dod is also related to "mechanical sympathy" [2].

Edit: maybe the ECS part is the dod part? I saw the tree demo and it did not look very ECS to me. Maybe it is just the UI? :-)

1: https://meetingcpp.com/mcpp/slides/2018/Data-oriented%20desi...

2: https://mechanical-sympathy.blogspot.com/2011/07/why-mechani...

> maybe the ECS part is the dod part?

Yes, ECS' usually give you at least a good default that is data oriented. At a glance it seems like it does[0]. Notice how some systems (functions) iterate over components rather than entities, which implies a "struct of arrays" layout that benefits caching.

[0] https://bevyengine.org/news/introducing-bevy/#bevy-ecs

Also check here (in their book):

https://bevyengine.org/learn/book/getting-started/ecs/

I'm getting security warnings visiting the site, on both Firefox and Chrome (though chrome's could be due to an external check, redirects me to malware.opendns.com). "Error code: SEC_ERROR_UNKNOWN_ISSUER" on FF at least.

edit: and seems like I'm not the only one, as there's at least one upvote already. probably worth checking!

Hmm I'm hosting this on github pages, so maybe its related to how they're issuing certs for my domain. I'll look into it. Thanks for the report!

It's working today! Did you have to make a change, or did some caches just get flushed or something? I've seen a couple other github-hosted-page issues like this, but I have no idea what the cause or fix is.

Nope no changes on our end. Very weird / makes me trust github pages a little less.

Same here.

It's also blocked by my workplace's corporate firewall, possibly for the same reason.

From the docs [1]

> "Bevy is a refreshingly simple data-driven game engine built in Rust."

The strange use of the word refreshingly implies that "bevy" could be related to beverage ... (bevy is Australian slang for beverage).

But apparently this is not the origin of the name...

> A bevy is a group of birds!

[1] https://bevyengine.org/learn/book/introduction/

What would be the difference between this (which looks really cool!) and https://amethyst.rs ?

From my limited experience (doing Amethyst's Pong tutorial and glancing through Bevy's home page), Amethyst is more mature and also seems more complex (and presumably more powerful). There's quite a bit of boilerplate to get started, but it gives you very fine-grained control over everything like how assets are loaded, how components are laid out in memory, etc. It seems like it's aiming more for the "real game studio" market than for enthusiasts, although last I checked it's also mainly focused on 2D for the time being.

It's funny, I've been doing something similar in Rust. A GUI framework that renders to Vulkan, and at the bottom is an ECS system(multiple systems) for rendering, layout, animation. But this one is very far ahead and looks very polished.

Congrats to the author on great work.

Purely a question. So why would I use rust instead of C++ or C# to develop games? what are the potential advantages of that.

Over C#:

* Garbage collectors often scare game developers since they can lead to hard-to-fix latency spikes.

* Rust has some cool libraries (specs, rayon, etc.) that let you safely parallelize computation.

Over C++:

* It's a memory-safe language, which instantly avoids tons of bugs.

* Library interfaces are usually higher-level in Rust than in C++, for various reasons (sum types being a big one).

* It's a much smaller language, so there aren't any dark corners that you'll randomly be forced to learn.

* It has an easy-to-use package manager, and I'm not sure where C++ is on that front.

> * It has an easy-to-use package manager, and I'm not sure where C++ is on that front.

In the inescapable hell of n+1 competing standards.

You mean that every langauge has its own package manager?

No, rather C++ has many competing package managers, none of which have majority buy in from the C++ community.

To name a few:

https://github.com/cpp-pm/hunter

https://conan.io/

https://docs.microsoft.com/en-us/cpp/build/vcpkg?view=vs-201...

https://buckaroo.pm/

I think they mean that C++ isn’t one thing, it varies a lot by the specific compiler and version you’re using.

I think they mean that people keep coming along and saying "the existing N competing standards suck, let's make a new one everyone can use" and now there's N+1 competing standards.

A reference to this xkcd https://xkcd.com/927/

To clarify, for C++ specifically.

There are many reasons, but to name a few important to me: rust gives performance on the level of C++, but with the memory safety of a garbage-collected language. It also provides protection against data races so that you can use concurrency with less chance of hard-to-debug issues.

For some, theoretically it's easier to train new Rust developers than it is to fix the bugs of new C/C++ programmers. Folks are trying to move the cost to training and dev bringup time instead of bug-fixing time.

Rust has other more technical advantages. But if you want to know why management is choosing it, it's because getting good C/C++ developers is a painful process nowadays.

Getting good developers is painful process no matter what, usually those are the ones that don't answer headhunters, search for their own gigs via their own contact network, and don't get to change jobs just for a couple of more coins.

True. Guess I just meant some folks are willing to trade one problem for another.

Also, I setup a discord channel for Rust GPU programming. https://discord.gg/YbawFYt

Having spent a good deal of time working in a dogmatic data driven entity component system very similar to this one, I'd like to point out that while it's very aesthetically pleasing to write code like that, it's not necessarily more productive or pleasant than a more conventional 'entity's behavior lives on the entity' approach.

Impressive!

this has the potential to be rust’s flutter! (Bevy UI)

I’d love to see a deep dive on how the Trait extension methods work! Great job!

Always want to create a game engine myself, do you know where to start?

This is awesome! The focus on productivity really sets this apart.

Github link https://github.com/bevyengine/bevy

dang, do you want to swap the link to github?

Rather than the GitHub link, I would recommend this page: https://bevyengine.org/news/introducing-bevy/

I've already posted it in https://news.ycombinator.com/item?id=24121947 but it didn't get traction :/ +1 on using that URL

> Turtles All The Way Down

Does Rust also compile to the GPU?

For now it isnt.

There are people working on this. https://github.com/MaikKlein/rlsl

This is supposed to produce SPIRV though, Becy uses WebGPU which has a custom shading language.

The original link posted here (the homepage) doesn't really get in to what makes Bevy interesting, I would recommend this great blog post instead that introduces it: https://bevyengine.org/news/introducing-bevy/

Yesterday's thread on /r/rust: https://www.reddit.com/r/rust/comments/i7bcwu/introducing_be...

Ok, we'll change the URL to that from https://bevyengine.org/. Thanks!

Probably a completely silly question but what is the difference between this and the Unreal engine?

The size, complexity, feature set and language?

I'm not sure if that is an answer or an additional question. If an indie game maker wanted to make a game, why would they use Bevy over the Unreal Engine? It it just because it's different or are there advantages?

Rust, ECS-core, slimmer abstractions, less tooling (less to learn, but also less pre-built), less complex as a general rule since its less featureful, which also means less cruft/bloat; unreal engine also has a general preference towards "realistic graphics & FPS gaming", to whatever detriment this means for any other type of game (e.g. afaik 2D games are not well-supported or tooled, and probably never will be; graphics tooling can be dramatically overcomplicated when you're chasing something stupidly simple, like replicating King's Field style billboard-3D graphics), etc

The big three specifically, which is pretty close to the reasoning for choosing any game engine thats not Unreal/Unity probably would be:

1. Rust

2. ECS

3. More likely to understand the damned thing

Sorry, the sentence has a question mark at the end because basically everything is different.

Size: Bevy is probably thousands of times smaller than UE. That is either a feature or a bug, depending on your needs.

Complexity/feature set: Bevy is a lot simpler because it's simply smaller. This of course means it's less capable. Again, feature or bug, depending on needs.

Language: UE is written in C++, so you can make games in C++ and its own language UnrealScript. Bevy is written in rust. Feature/bug depending on needs.

License: UE has a source-available commercial license, while bevy is FOSS (MIT license). A more open license is obviously better, but the commercial licenses generally come with support.

That said, I'm not a professional game developer, but am currently experimenting with the Godot engine (Also an indie FOSS engine, but a little older). I don't really like GDScript, but I can just use C++ bindings anyways.

Reply on news.ycombinator.com