Hacker News new | past | comments | ask | show | jobs | submit login
Bevy 0.3: game engine built in Rust (bevyengine.org)
243 points by _cart 11 months ago | hide | past | favorite | 55 comments



Playing with Bevy and its ECS made me shocked (in a really nice way) how much like a dependency injection framework it worked. Writing a system and simply specifying what resources and queries it needs as function arguments and it magically getting them for me makes it really quick to get to the fun part of writing game code. Are other ECSs this ergonomic?

Still struggling to really get in the flow of where what data should live, but with time it's getting easier. The realization that you don't need all data to be in components also really helps. For example for my game grid I store it as a Resource and inside I store entities I care about such that I can run a normal path search algo.

Overall very impressive and fun project and the discord community is active and friendly.


Flagrant brag: I think we've advanced the state of the art when it comes to ECS ergonomics and (according to my taste) I think we're the most ergonomic ecs in existence.

That being said, Legion (another rust ECS framework) recently added a similar approach. But they use macros instead of pure Rust, which is slightly more verbose.


I'd been using entt in C++, and recently have been working on a wrapper for entt in Nim (since Nim can just generate C++ output, works fine with templates, and lets you even emit your own C++ code, this is doable), and found that Nim is quite ergonomic for ECS code: https://gist.github.com/nikki93/694524b8c007b4269c899b2e046b...

That's the entire main file for a simple demo with rectangles, some of which oscillate, and you can touch to remove (multitouch supported).


Macros or pure Rust is more verbose? I could parse your last sentence either way.


I had the impression macros are used to make code less verbose.


In legion the macro attributes are used as "labels" for parameters to configure resource types. Theres also the additional boilerplate of annotating the function with a `#[system]`.

Bevy ECS relies solely on the type system, which means these additional annotations are not necessary.



Author here. I'm happy to answer any questions you have about Bevy!


In your benchmarks of insertion/add/remove[1] you use different units of time for each of the three graphs. I didn't notice until staring at them for some time wondering what was up. Maybe you could make it clearer or use the same unit?

I think it is an awesome project and I'm looking forward to trying it out soon!

[1]https://bevyengine.org/news/bevy-0-3/#component-insertion-in...


Sorry my benchmark test suite "fits" the units it reports to the duration. I totally get that its a bit confusing. I probably won't update them for this blog post because generating the graphs isn't fully automated yet (i manually theme the svgs to match the blog style).

But for future releases ill keep that in mind.


It seems like there's a ton of interest in Bevy! You must be spending a lot of time discussing things, reviewing PRs, doing outreach and community building like here. Is there any time left for the hard feature work? Are there any core members apart from you?

(Don't burn out!)


I'll be honest: the success of the initial release totally blew me away (both in a good way and a bad way). It took me a little over a month to adapt and develop ways to manage all of the threads (prs, community, dev work) without feeling burnt out.

Fortunately I've largely sorted out a workflow that works for my mental health, (i think) works for the community, and still leaves me plenty of time to do dev work. It helps that I can make this my full time job thanks to all of my awesome sponsors.

I am currently the only member of the Bevy organization that can merge prs, but a number of people have stepped up to review prs which helps a lot.

Eventually I do want to grant more people merge rights, but I'm holding off for as long as possible because I think having a single filter that ensures a cohesive vision is valuable.


I'd be happy to hear more about this workflow you've set up for yourself. The more I do development work the more I've come to appreciate having a framework to offload mental overhead onto. I don't think I've found one that quite fits me quite yet, but hopefully soon :fingers_crossed:


I want to second the request to learn more about your workflow. I shepherd OSS projects in addition to dev work, and striking a balance between outreach, admin, and getting things done is always a challenge.


Hi! I just wanted to say that the sub-asset loading feature is really neat! Beautiful way to handle that use case. One question: if you load two sub-assets from the same gltf, is the gltf cached or loaded twice?


Thanks! It is cached. It will only reload if the asset hasnt been loaded yet or was previously freed.


Any plans for scripting/logic other than Rust? I can't imagine it working well to quickly iterative on gameplay


Rust isn't inherently slow to iterate, its just easy to write code that compiles slowly if you aren't careful. One of Bevy's primary focuses is to have fast iterative compile times. Changes to our examples can be recompiled in ~0.8-3 seconds (according to your hardware, os, and linker). We have a "fast compiles" configuration that works quite well.

First we do plan on exposing hooks to allow scripting languages to be plugged in to Bevy. We actually already have a pull request out for that.

However my default answer to the scripting question is that it is a non-goal for Bevy, and is in fact maybe even an anti-feature. I want Rust to be the "one language" people use to build Bevy games. I think a cohesive ecosystem is an incredibly important part of an engine's success. If half of Bevy devs use rust and the other half use C#, then compatibility and interop become a huge problem. The Rust language choice does set a high bar, but Bevy doesn't need to be all things to all people. Additionally, the Bevy API is a Rust API. Defining FFI on top means we need a second api surface that is the "lowest common denominator" (aka a C api). This both increases maintenance burden and creates the "rust experience" and the "everyone else" experience.

In the near future 3rd party Bevy scripting plugins will start popping up, but I doubt I will ever officially endorse them.


I also think on of the major selling points of Bevy is that "bevy game devs" are actually "bevy engine devs" ... they just don't know it yet. Bevy is implemented using the same plugin interface that games use, which blurs the line between engine code and game code.

Adding scripting languages into the mix removes this benefit and cuts down on the number of people capable of contributing back to the engine.


what about using rust for scripting but compiled to wasm, so beavy can (hot-re)load wasm modules?


thats a scenario im definitely thinking about :)


Can you easily serialize/deserialize the game state with your ECS system? I haven't looked closely at it.

If it were possible, your iteration times could be ridiculously low. Play the game until the bossfight you're iterating on. Dump it out to disk. Edit the code, recompile and run from saved state in a couple of seconds? That sounds amazing.

Unity has pretty good edit and continue for simple stuff, but it quickly falls apart once you start doing non trivial things.


Not sure about bevy specifically, but I know the rapier physics engine (which integrates with bevy) can serialize all of the physics state.

Plus, in Rust, if you mark types as Serialize you can serialize nearly anything you want. And it seems like Bevy makes full use of the powerful Rust type system.

So I’d guess “yes, you can probably easily serialize the game state in most cases”.


To do edit and continue with it you're really going to want full serialization, so if you eg model events as a closure instead of plain data, you're toast (coming from an outsider's perspective).

If the base engine supplies you with full serialization support for the inbuilt features and a list of rules to follow to maintain it, you're golden.


Wow you've got some good engine design sense. Have you by chance shipped a commercial game before? Most open source engines lak such concrete experience and sense.


The developers of EVE Online had this same thought, about C++, so they used python as the gameplay scripting language. A few years later faced with unsolveable performance issues with large scale battles they had to resort to slowing down time by a factor of 4, during large scale battles.

Just a single anecdote but can be important to keep in mind. As well, some types of scripting languages can have their own productivity problems as projects get large. Lack of types making code hard to follow, bugs harder to track down, refactors riskier etc.


The difference is that Rust is still quite far to support the dynamic capabilities and code reloading of C++.


People have been doing hot code reloading with rust for years now. I'm not sure what are all the pros/cons and limitations with each today. I wouldn't think there are fundamental differences.


Kudos for building a game engine, especially in Rust.

What was the machine's spec to run the benchmark on the ECS? I don't mean to pour rain on the parade, but 1 millisecond to retrieve a component looks really slow. Was it mislabeled as in 1 microsecond? For a game with a 1000 entities, there would mean one whole second to process one component of all the entities.


I think you missed the part where we run the test 100,000 times per iteration. I promise its really fast :)

edit: but i do agree that the title is a bit unclear. ill fix that now


Ah I see. Didn't see the 100K runs in the paragraphs below. That's more reasonable. Good job.


Great work! I have developed games in several game engines, but I'm new to Rust. Can it run inside a WebView and communicate with Java (Android) thru a JS interface? That would be awesome.


It should be able to run in a webview via WASM, but im less certain about the java communication part. If its a normal JS interface then you can probably do it.


Does it have any graphical editors?


Not yet, but it's one of our current focus areas: https://github.com/bevyengine/bevy/issues/254


I enjoyed reading this release announcement. Thanks for all the details.


Man, you guys really kill it with blog/changelog announcements. Great job!


That's a great pace of changes!

For my use case, Bevy web (and mobile is nice too) support would mean switching from Godot, 100%.

It will be interesting to see if cross platform support will trickle down to amethyst (I think they share the gfx upstream), who is currently migrating to a faster ECS library (legion).

Exciting times!


Isn't Legion more different then just faster? Last I heard the big change was switching to an archetype based ECS which gains speed in some scenarios but does worse if you regularly add/remove components (so temporary effects are just a component you add for a brief time then remove).


What graphics backend does this use? I can’t seem to find one listed after a quick search.


Our main backend is wgpu, which is backed by Vulkan, DX11, DX12, Metal, and WebGPU (according to whats available on each platform).

We also have a work-in-progress WebGL2 backend (which will eventually become a desktop OpenGL backend too).


If you can nail WebGL, this project becomes so tempting. There's basically nothing out there that gives you good cross platform.

We're using Unity, and optimizing for wasm performance and size is so awful (they don't have a good solution for streaming).

Our parent company uses a js engine, which has meant a far better story on the web, but porting successful games to mobile is awful.

You could quite easily become the natural choice to develop a decent cross platform game in.


It's really nice that this has Android and iOS support. I think the main problems for Rust game development are that and stability.


How does this compare to Amethyst or Piston?


(author here)

Here is a link to a conversation we had about this in the Amethyst community: https://community.amethyst.rs/t/bevy-engine-addressing-the-e...


Thanks for posting this.

I really want to learn low level programing, but I learn best when building a project.

Does it have networking support ?


We don't (yet) have official networking apis, but there are a number of 3rd party plugins:

https://github.com/bevyengine/awesome-bevy#networking


Any Xbox controller support And even Unity uses 3rd party networking solutions, so I wouldn't sweat it that much


_______________ BUILT IN RUST!


I totally get that Rust is sometimes over-hyped. But I'm not sure what you want here. Do you want me to stop building things in Rust? Or is it ok to build things in Rust, but I shouldn't share them? Or is that ok, but if people like it enough to reach the top of hacker news, its just another RIIR (rewrite it in rust) project?

The anti-rust backlash is so interesting to me because the Rust community is by far the friendliest programming community I've been a part of. And theres so much high quality new and interesting work being done. Trivializing that really rubs me the wrong way.


I want you to define a title that lets readers know it's more than just any old game engine. Being written in Rust doesn't change that.


I'd like to call out that the title _was_ longer with more description, but the mods (understandably) trimmed it down.


Bevy 0.3: game engine


I care about what language I use to interact with engines or libraries. For me, that's objectively worse than Game Engine XXX in language XXX


You guys should also check out rg3d https://github.com/mrDIMAS/rg3d

Join the discord channel https://discord.gg/xENF5Uh




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: