
Bevy: A data-driven game engine and app framework built in Rust - adamnemecek
https://bevyengine.org/news/introducing-bevy/
======
_cart
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!

~~~
mrec
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?

~~~
Thaxll
Video games don't really care about binary size.

~~~
mrec
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.

~~~
necubi
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.

~~~
mrec
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.

~~~
sitkack
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.

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

~~~
cthonicthulu
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?

~~~
dgb23
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?

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

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

For me that would be a multiplatform GUI library.

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

~~~
amelius
Yes. There's [https://areweguiyet.com/](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 ;)

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

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

------
atoav
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!

~~~
leshow
Just curious, have you seen amethyst?
[https://amethyst.rs/](https://amethyst.rs/)

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

~~~
NTARelix
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.

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

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

~~~
meheleventyone
There’s not a particularly thrilling benchmark here:
[https://bevyengine.org/news/introducing-
bevy/](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.

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

~~~
meheleventyone
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.

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

~~~
meheleventyone
They are? Because you can see the source for the Serious Engine 1 here:
[https://github.com/Croteam-official/Serious-
Engine](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.

------
emmanueloga_
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...](https://meetingcpp.com/mcpp/slides/2018/Data-
oriented%20design%20in%20practice_Nikolov_MeetingCpp18.pdf)

2: [https://mechanical-sympathy.blogspot.com/2011/07/why-
mechani...](https://mechanical-sympathy.blogspot.com/2011/07/why-mechanical-
sympathy.html)

~~~
dgb23
> 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](https://bevyengine.org/news/introducing-bevy/#bevy-ecs)

Also check here (in their book):

[https://bevyengine.org/learn/book/getting-
started/ecs/](https://bevyengine.org/learn/book/getting-started/ecs/)

------
Groxx
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!

~~~
_cart
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!

~~~
Groxx
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.

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

------
gitgud
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/](https://bevyengine.org/learn/book/introduction/)

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

~~~
brundolf
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.

------
6d65
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.

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

~~~
rainbow-road
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.

~~~
PrototypeNM1
> * 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.

~~~
adamnemecek
You mean that every langauge has its own package manager?

~~~
ShinTakuya
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/](https://xkcd.com/927/)

~~~
ShinTakuya
To clarify, for C++ specifically.

------
adamnemecek
Also, I setup a discord channel for Rust GPU programming.
[https://discord.gg/YbawFYt](https://discord.gg/YbawFYt)

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

------
AbuAssar
Impressive!

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

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

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

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

------
amelius
> Turtles All The Way Down

Does Rust also compile to the GPU?

~~~
Rhedox
For now it isnt.

There are people working on this.
[https://github.com/MaikKlein/rlsl](https://github.com/MaikKlein/rlsl)

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

------
adamnemecek
Github link
[https://github.com/bevyengine/bevy](https://github.com/bevyengine/bevy)

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

~~~
kibwen
Rather than the GitHub link, I would recommend this page:
[https://bevyengine.org/news/introducing-
bevy/](https://bevyengine.org/news/introducing-bevy/)

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

------
kibwen
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/](https://bevyengine.org/news/introducing-bevy/)

Yesterday's thread on /r/rust:
[https://www.reddit.com/r/rust/comments/i7bcwu/introducing_be...](https://www.reddit.com/r/rust/comments/i7bcwu/introducing_bevy_a_refreshingly_simple_datadriven/)

~~~
dang
Ok, we'll change the URL to that from
[https://bevyengine.org/](https://bevyengine.org/). Thanks!

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

~~~
tpxl
The size, complexity, feature set and language?

~~~
maps7
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?

~~~
setr
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

