The Bevy Foundation | Hacker News Reader

The Bevy Foundation

bevyengine.org

102 points_cart80 comments

"You may notice that every member of the board is an active Bevy Maintainer. This is not a coincidence. We believe that people actually developing the project should be at the helm. There is currently no way to buy a board seat. We have no plans to hire "professional board members" that aren't in the thick of it. For now we plan to stick to the Maintainer == Board Member policy. Functionally, new Board Members are selected via an election of the current board. "Board Member" is currently not a paid position."

Thank you for setting the Foundation up like this!

To make this work in the long run donations are crucial: https://bevyengine.org/donate/

Hi! I'm the fabled "project manager" that we'd like to hire! Helping run Bevy has been an incredible experience, and I'm very excited about the idea of being able to do this full-time. There are a ton of efforts I'd like to lead, and even more that I'd like to be able to help nudge along.

Any plan for Physics? There is no mention on front page of the website.

When do the team think the would be comfortable telling people they can build and release game on it?

Physics is 3rd party currently, but it's on our roadmap for "some day, definitely". Writing your own physics engine is... a lot of work, and not something that I'm excited to volunteer the engine itself for immediately.

There are two popular physics engines used in Bevy today: Rapier[0] and bevy_xpbd[1]. Both are candidates for upstreaming, but both have their own challenges. I've spent some time working with each of the authors recently, laying out my concerns and thoughts.

On the Rapier side, the documentation is sparse and aggressively mathematical, it uses a distinct math library from the rest of Bevy, the API to work with Bevy is sometimes clunky and unidiomatic, and it can be quite hard to figure out how to do Ordinary Game Dev Things with it.

On the bevy_xpbd side, the performance is subpar, there can be physical stability issues, it's generally immature, and the XPBD solver that they use is, unbeknownst to the young author at the time of the crate's creation, patented by NVIDIA [2] :(

Both of them are working to improve (and I'm very pleased to see that even independent of this discussion), but neither is ready for imminent official endorsement or integration. One day we'll have a Blessed Choice though.

As for telling people "go forth and build your game!": things are stabilizing, and key functionality gaps are gradually getting filled. I have a terrible tendency to be overly honest, even in my marketing text, so there's going to be a long period of time where the actual answer is "it depends on what you're making".

Today, if you're building a weird game-adjacent bit of software (think CAD) for desktop platforms: totally ready! There are several very happy companies doing that. If you wanna mess around with Rust and nurse the Next Great Solo Dev Science-Based MMORPG Voxel Game: you'll have a blast, and it won't affect your chance of shipping a whit. If you want to build a simulation-y desktop game with lots of procedural generation and complex logic: honestly probably a good fit. You'll hit bugs and limitations, but you will in every other engine you use so...

If you want to ship high-performance web games, AAA graphics or mobile: eh, probably doable but dicey. If you want to ship to console: uh we'll find out if we can jump through all of the hoops and convince the right people to get Rust on console before the Steam Deck knockoffs devour the market (please!).

These will all slowly change, but an answer for "is it ready" will be hard to pin me down on until it's a full-fledged competitor to Unity, Unreal and Godot.

[0]: https://rapier.rs/docs/

[1]: https://github.com/Jondolf/bevy_xpbd

[2]: https://github.com/Jondolf/bevy_xpbd/issues/346

My personal opinion (and I don't speak for anyone else) is that Bevy 0.13 is usable for 2D games if you use Tiled as your editor. Most 3D games will have to wait until 0.14 (the next release) though, since there isn't animation blending yet (though note [1]), and most 3D games need that. Since I landed animation blending in 0.14, once that version is out I think Bevy will be ready for advanced users who aren't afraid to get their hands dirty to build serious stuff, using space_editor as your editor.

[1]: https://github.com/mbrea-c/bevy_animation_graph

Hi! Thank you, I'm having lots of fun using Bevy!!!

The first thing I looking for was whether it is 501(c)(3) or 501(c)(6). While that alone doesn't guarantee anything, it is still a good indication on the motivation of a project. Thank you Team Bevy!

https://www.unsungnovelty.org/posts/05/2023/open-source-proj...

Bevy's creator, project lead, and now president of the Bevy Foundation here. Feel free to ask me anything!

How does it feel to have a small project where you are the only programmer turn into such an organization which asks very different things from you?

It has certainly been a wild ride. Running an organization is certainly a different skill set. I've learned that I'm pretty good at that side too, but it drains me in a way that programming does not. Bevy's success has definitely been a mixed bag for me. It has been extremely fulfilling and a dream come true. But things were also much simpler, calmer, and pleasant when I was building Bevy alone incognito.

Nothing to ask right now, just -- thank for your (and Alice's) work!

The (non-game) things that I do would be infinitely more painful without Bevy ECS, so I sponsored personally at Diamond for now.

Very excited for relations and I'm hoping that the Bevy Foundation can attract the support it's looking for (and I'll switch over to corporate in a few months if things don't go unexpectedly sideways with my company). :)

If you are trying Bevy for the first time, and it runs slow, put this on your Cargo.toml

    [profile.dev.package."*"]
    opt-level = 3

This + more is described if you follow the Quickstart, which if it's your first time, is probably the best place to get started quickly :)

https://bevyengine.org/learn/quick-start/getting-started/set...

Yes. But when I tried the tutorials, the performance issue was an instant turn down.

With this, the frame rate immediately went from 13 fps to 60 fps.

The curse of "zero cost abstraction" strikes again :/ A 5x performance difference between debug and release mode isn't uncommon in C++ either and a real problem for game development (plus the slow build times, but those two problems go hand in hand - you can have "high-level abstractions" that build slowly and run fast, or build fast and run slowly).

That's why there's so much advice to write C-like C++ and also ignore the stdlib in gamedev circles. The Rust equivalent is probably to write "embedded style Rust".

Debug mode isn't always needed, though - E.g. C++ with RelWithDebInfo gets you far enough, unless you specifically want to run debugger - I'm one of those who do not use a debugger in their workflow, so a non-issue for me.

That's been my fallback solution too in C++ in the past and it kinda works (and Visual Studio has a special option /Zo since quite a while https://learn.microsoft.com/en-us/cpp/build/reference/zo-enh..., not sure though if that's actually used by cmake's "RelWithDebugInfo" config), but there's still downsides even when not using a debugger. Most importantly: if you have a crash/assert handler which logs out a callstack, that callstack may sometimes be quite misleading (depending on how much the optimiser passes have mangled the compiler output relative to the input source code).

How is that a curse?

With rust you can simply compile your dependencies in release mode while keeping your own code in debug, and it's often performant enough because most of the time the perf sensitive stuff isn't in the app logic itself.

Yeah, I'm guessing that's exactly why that step is like step #3 in the official quickstart tutorial.

Using LLD/Mold is another pro-tip from Bevy that all projects - possibly RustC - should adopt.

Agree! Also outlined in the official Quickstart docs, and that one I've gotten a lot of use of outside of Bevy too.

I've been using Bevy recently so here are some thoughts on this:

Firstly, the overall quality is high and seeing this attention being paid to the project's organization is another good sign.

Documentation is not great. The Bevy book runs out of content very quickly. The "Cheat Book" has additional useful information: https://bevy-cheatbook.github.io/. With these plus the examples I've been able to figure out everything I need, but it's slow going.

I'm not 100% sold on ECS. It loses a lot of type safety and there doesn't seem to be any way to ensure cleanup of entities and their components.

How does it lose type safety?

I was under the impression that bevy's Query system is type safe.

ECS is basically a very simple relational database. There is no equivalent of foreign keys or other constraints between components. I can't say, for example, "every entity that has a location must also have an associated mesh". If I forget to add a component it's just a silent failure. Everything runs fine, just the expected result doesn't happen.

You can probably write runtime tests for this. Some system which queries for component Location, and then does an assert for each component that the associated entity also has a mesh.

Granted, this is annoying and not a particularly great solution, but it would serve to give you a reminder for when you forget. I don't mean to diminish from your overall point either, it's a valid and good one I think.

Yeah, runtime checks are not very desirable.

I have this vague thought that Rust needs a different kind of type system.

Standard type systems[0] basically rely on references between values[1]. I seem to read about numerous Rust systems that don't use references for various reasons. Usually the borrow checker gets in the way or they want a different memory layout[2]. This makes me think that what's needed is a type system that allows constraints to be expressed between values without requiring a reference between them. I don't know what this type system looks like, though.

[0]: Rust's type system is a fairly standard type system from an academic POV. The novelty is that it's the first language with traction to use a linear / affine type system, but these are relatively well studied in academia.

[1]: The theory is not formulated this way, but the representation they compile into is a bunch of references.

[2]: ECS, as I understand it, is not a reaction to Rust's type system but an architecture driven by memory layout, parallelism, and breaking-out-of-OO-hierarchy concerns. However the net result is the same.

Totally agreed, like when using an int to reference into an array, there's no way to guarantee that the int won't be out of range, so it needs a check every time

Also no ideas here, but its fun to think about anyways

I wonder if a compile-time array-of-structs (AoS) to struct-of-arrays (SoA) transformation like the one done by Zig [1] could fix that issue.

[1] https://zig.news/kristoff/struct-of-arrays-soa-in-zig-easy-i...

In theory this is what Bundles are for, though it's easy to not realize that there's a bundle for what you want to do.

I should note that this is a problem with most game engines, not something unique to Bevy. For example, Unity is infamous for requiring arcane combinations of components to avoid silent failures.

Thanks (I am the aforementioned project manager) :) Docs are a high priority for me, especially beginner content, assets, and rendering for me. Rust's in-repo examples are really helpful for ensuring they stay up to date, but aren't a replacement for a guided tour.

As for the ECS, I've absolutely felt that: the flexibility of the polymorphism created by "just add another component!" can be both chaotic and freeing. Can you say more about what you're looking for with entity cleanup? I haven't heard that complaint before and want to make sure I understand what you mean.

The release notes are great btw. Usually if I’m doing something for the first time I look it up in the bevy cheat book, get something that doesn’t work (because it’s two or three versions out of date), then check the intervening release notes. Usually there’s enough direction to figure it out.

They're so, so much work. Carefully going over the log, and patiently explaining / showcasing and contextualizing them is even more work than writing docs for the same feature, since you don't have the API to help structure things.

I'm glad it pays off! Seeing them come together makes my day every time, even when I'm writing half of it.

Oh, I know! I’m a maintainer of another open source project and the release notes are such a chore. For the quality of Bevy’s I could easily see it being a full time job, albeit a mostly thankless one. So thank you for the effort you’ve put in!

And I know so many people who think you could automate them from commit messages. Hell, no!

Most games have different states. For example, you have the main menu screen and perhaps different levels. Each of these could be a state. I think Bevy already has an abstraction for this[0] but it only records the current state. There is no other information associated with it IIUC.

What I think would be useful is essentially an arena allocator associated with a state. So any components and entities created when a state is active would be removed when that state is exited. Otherwise it seems that one must do manual GC, which is error-prone and will almost certainly lead to slow leaks over time.

[0]: https://docs.rs/bevy/latest/bevy/ecs/prelude/struct.State.ht...

Ah okay! I can see the need for this. This is a large part of why the States machinery exists, but I see your point about it being error-prone to remember to tag and then despawn everything.

I'll chew on solutions here: we might be able to get away with a nice well-documented convention in user-space code, or we may need to add a small extension to the internals to make this more robust.

Isn't the typical way to do this by using a janitor? This would typically need to be done in user space (the framework doesn't know what cleanup you want to do), but Bevy could provide an interface for it with callbacks or whatever is more idiomatic in Rust/Bevy.

Last time I was using Bevy I had a cleanup system to solve exactly that issue. It queried for entities with the AssociatedWithState component, or whatever I called it, and destroyed any where the was a mismatch.

I could see an efficient version of that being a nice thing to have built in, though. It’s definitely a very common thing.

Personally i think the flexibility of ECS is worth the tradeoffs, but that’s just me.

I’m not sure what you mean by cleanup entities. Whenever i load a level i put it under a root entity and just despawn the root when im done.

ECS is an architecture proposed by the same group that has said "if you know you're not going to use that memory again, just allocate over it". For certain domains, this is a superior solution to management than more costly cleanup. Re-initializing an allocator and leaving behind old data in now uninitialized memory is a lot faster than doing anything with that memory.

For type safety, entities define mapping of types [components are types]. The whole point of ECS is effectively managing types and ensuring correctly typed data is operated on.

A note on the ECS: This is largely due to poor understanding on my part, but I moved my computational chemistry (egui-based) GUI program (Visualizes various wave function properties) from Bevy to WGPU directly, because the ECS was difficult to grok and debug. It felt like more work to reinvent wheels regarding rendering than manipulate the ECS. I had it working in Bevy, but ported. Not a canonical use case for a game engine!

It's been ~2 years, but my main reason was wanting to write plain rust, vice using a DSL.

I moved my game away from Bevy to WGPU too because I needed tighter, more efficient control of the data than ECS could provide. Though being able to query data with types is amazing and really demonstrates how powerful Rust's type system is, it's not a solution for everything, and feels more geared towards one-off arcade style video game design.

Why can't I just donate once?

I'm too stupid to use Rust, I just don't have it in me right now, but I really want to support this engine. Please add a one-time donation option!

https://github.com/bevyengine/bevy-website/issues/1097 Yep, on our wishlist and will be added :)

Thanks, I'll donate soon.

Also this is a long shot, but any chance of supporting higher level languages. Maybe it calls the underlying Rust code from C#

I think that's impossible. Bevy works heavily with Rust types and generic monomorphization. You couldn't do that in another language without literally generating Rust code and calling the compiler.

A scripting language is an explicit non-goal for first-party support, but there have been tools for using the ECS entirely without Rust types which can be exposed via FFI or embedded languages like Lua.

Just search "_by_id" in the bevy_ecs docs, and you'll find all of the associated APIs for access. There are then (unsafe) APIs for creating the internal mappings necessary to use them. These are normally called via the monomorphized generics automatically, but need to be manually called since we don't have compile time knowledge of the data being stored and accessed.

So basically it's possible, but not recommended.

Maybe the next time I'm on vacation I'll embrace rust...

Given the fact that foreign values inherently require the use of unsafe due to not being able to verify anything about the value and it's behavior, yes, it's generally not recommended unless you're looking to write your own scripting integration plugin. Likewise, most of these scripting language runtimes are almost always not threadsafe in the slightest, requiring either single threading all scripted behavior, expensive locks, and heavy use of marshalling, which negates a lot of the performance benefits of the engine.

For more developer experience oriented reasons why this is done, I strongly suggest reading cart's reasons for making Bevy to begin with: https://github.com/bevyengine/bevy/discussions/8107#discussi.... More specifically the "Turtles all the way down" bullet point.

Although Bevy says it's an engine, I think that's a bit of an overstatement. It's more of a library/framework. There's a lot you need to do from scratch.

If you are looking for a more full featured game engine-- I recommend Godot.

I have been using Godot lately and it's refreshing how nicely it flows and how the experience mirrors other OSes (from a Linux user's perspective). If you haven't tried Godot lately, give it a try.

Plus, the whole thing is a single binary (~100mb).

I actually recently switched a project from bevy to Godot and agree, it was really nice and easy to get started. Godot is shockingly simple and intuitive compared to something like unreal engine.

Bevy was also great, but is definitely more of a library and there's not a lot of mature plugins. My use case was a web browser compatible game (wasm compiled bevy) that used websockets for networking. It didn't seem like too much of a stretch, but I didn't end up getting anywhere I wanted to be with bevy unfortunately. Hopefully as it grows it becomes a better option!

But with Godot I ported my code and had it working in the browser with websockets based multiplayer shockingly fast, even having never touched gdscript before!

Any particular reason these 501(c)(3) non-profit public charity designations are no longer granted as freely as before?

From what we could tell, not really! It seems like a slow policy change, basically dictated at the level of the individual bureaucrat.

That said, the Zig Foundation got status in 2020, and the Amethyst Foundation (another Rust gamedev group) also got status recently, so we figured it was worth it to apply since we really do feel like it's the best-fitting designation for how we want to run things and what we want to do.

Does Bevy have a graphical editor yet (or one on the roadmap)?

It seems like it has good bones, but taking real territory away from Unity or Godot will be hard without an editor (not just for non-programmers; some game dev tasks are just way easier with a GUI)

Of course it's open so somebody could build one, but it seems to me this deserves to be a first-class citizen

Bevy is working on a graphical editor, but its still in its prototyping phase.

https://bevyengine.org/news/bevy-0-13/#more-editor-experimen...

> ...taking real territory away from Unity or Godot

I used to think this too. But having written a lot of hobby code using Godot (via Gdext, an excellent Rust wrapper for it) I feel the editor is a nice to have but not indispensable.

Very soon into the game you'll find that you need an editor that lets you add your own game abstractions into the game. And at that point you're better off writing an editor "in game" than shoe horning your abstractions into the game engine editor.

There's a bit more nuance I probably outght to the above description but too tired to type it all out on my phone now.

There are a few third-party ones. https://github.com/rewin123/space_editor is the one I use. It's not pretty, but it works well enough.

Having an official editor is definitely on the roadmap.

Good luck with the efforts, we need more variety in programming language landscape for game engines.

Loved bevy since the reddit post (i think that was even pre 0.1). It's a bummer I was in the middle of learning rust, so I wasn't of much help. Would've loved to contribute

Don't worry, you still can! I've been actively contributing to the past 4 months, working on improving CI and the website. I started out doing PRs for typos and little improvements, and so can you! (I recommend looking for issues marked as "Good-First-Issue," they are the best entry-level things to work on.)

Which post?

I write a simple 2d game in bevy to learn rust and ECS. I like it a lot.

I just wish it was slightly better with backward compatibility. There's many useful libraries I can't use because they depend on different bevy versions, and updating the code to new major versions is a hassle. And the bevy cheatbook has some pages refering to behavior that changed several versions earlier.

Love where Bevy is going. On the UI/UX side it has a long way to go, but on the non-rendering backend architecture side it can beat Unity, Unreal, and Godot in the long run.

Just crossing my fingers because by the time Bevy reaches that goal, compute power may have just 10x'd again, and the existing game engine giants will have added AI creation tooling by then.

Can't wait for the days when bug reports are closed with "don't know why this is happening, the AI did it, can't fix"

Apparently Bevy is a game engine.

I hope this will one day become as large and productive as the Blender Foundation

I applaud the decision for a 501(c)(3) and not a 501(c)(6).

Can you explain the difference?

https://en.wikipedia.org/wiki/501(c)_organization

This has complete sections defining both.

A summary for people not expert in legalese and American law?

Not a lawyer and what I'm going to say is vastly oversimplified, but the gist is:

- A 501(c)(3) is for the benefit of the public

- A 501(c)(6) is for the common interests of their members

They both have advantages and disadvantages and are appropriate for certain scenarios.

Examples are:

- A 501(c)(3) Python, Scala, Zig, Mozilla, Apache, SFC, FSF

- A 501(c)(6) .NET, Rust, Eclipse

It sounds like 3 is for charities and 6 is for business organizations like a chamber of commerce. The former has tax-deductible donations and can’t participate in lobbying or political campaigns. It seems like 6 would have been a weird choice here.

Not so weird, the Rust Foundation is a 501(c)(6) after all, like the .NET Foundation or the Eclipse Foundation, but from all I know about Bevy and the people behind it a 501(c)(3) suits it much better.

For anyone trying to understand the difference, please read :

https://www.unsungnovelty.org/posts/05/2023/open-source-proj...

Revy – proof-of-concept time-travel debugger for the Bevy game engine - https://news.ycombinator.com/item?id=39590683 - March 2024 (36 comments)

Bevy 0.13: ECS-driven game engine built in Rust - https://news.ycombinator.com/item?id=39412940 - Feb 2024 (59 comments)

Bevy 0.12 - https://news.ycombinator.com/item?id=38144417 - Nov 2023 (84 comments)

Three Years of Bevy - https://news.ycombinator.com/item?id=37477971 - Sept 2023 (1 comment)

Bevy's Third Birthday - https://news.ycombinator.com/item?id=37081501 - Aug 2023 (6 comments)

Bevy 0.11: ECS-driven game engine built in Rust - https://news.ycombinator.com/item?id=36657970 - July 2023 (29 comments)

Bevy XPBD: A physics engine for the Bevy game engine - https://news.ycombinator.com/item?id=36642867 - July 2023 (20 comments)

Bevy and WebGPU - https://news.ycombinator.com/item?id=35994106 - May 2023 (40 comments)

Bevy 0.10: data oriented game engine built in Rust - https://news.ycombinator.com/item?id=35045224 - March 2023 (91 comments)

Scaling Bevy Development - https://news.ycombinator.com/item?id=34387062 - Jan 2023 (20 comments)

Bevy 0.9: data oriented game engine built in Rust - https://news.ycombinator.com/item?id=33577284 - Nov 2022 (50 comments)

Automated testing in Bevy - https://news.ycombinator.com/item?id=32802402 - Sept 2022 (81 comments)

Bevy 0.8: data oriented game engine built in Rust - https://news.ycombinator.com/item?id=32287828 - July 2022 (18 comments)

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)

You had me at:

> game engine built in Rust

I hope it succeeds and gets significant market penetration. Will donate monthly

The joke goes: "rust has 5 games and 120 game engines written in it" :)

"did you write frontend or backend in rust?"

"??? No. The browser"

Bevy is great!

Great news!

Reply on news.ycombinator.com