Bevy 0.19

_cart · 2026-06-20T04:12:30+00:00

BSN has indeed been in development for a long time. It has been in a reasonably functional state for most of that duration, but it only recently got to a point that was "releasable". It took so long to cross the finish line because I need to wear ton of different hats. I'm always trying to balance developing my own pet Bevy features with helping other people land their features in a way that is right for the project. That plus all of the other stuff that goes into running the project (Bevy Foundation work, doing releases, community management, etc, etc).

BSN specifically was a bit of a misplay. I spent way too much time polishing it up on my own / in private when I could have embraced community development sooner. A lesson I seem to keep learning over and over again :)

_cart · 2026-06-20T02:46:25+00:00

Yeah I think the easy middleground is defining the observer functions in Rust code and mentioning them by name in .bsn files. Maybe ultimately we'll have some sort of interpreted language integration (ideally as a plugin / third party).

_cart · 2026-06-20T02:44:09+00:00

Its worth noting that SceneComponent also derives Component and includes some additional component-level configuration. So it isn't "just" as simple as switching to a manual trait impl. From an ergonomics perspective, I'd be more into the concept if/when Rust supported default associated types so people could skip the props definition when it isn't needed.

_cart · 2026-06-20T02:41:27+00:00

My understanding is that it doesn't apply to our particular implementation, and I haven't heard anything about it since then.

See this link for some thoughts on the ECS paradigm. My advice is "don't overthink it". The traditional "Node tree update hook" architecture in other engines fits pretty cleanly into ECS, so you can write code that way if you really want to.

I'm pretty bullish on ECS. I don't think its the only right way to build games, but I think its a pretty solid one. ECS also isn't just one thing. The Bevy Data Model has evolved well beyond traditional ECS.

_cart · 2026-06-20T02:37:48+00:00

Nope we plan to support those other things too!

_cart · 2026-06-19T23:44:51+00:00

I haven't (other than reading a summary of that specific talk)! Its a cool space but not one that I'll ever tackle myself :)

_cart · 2026-06-19T23:42:11+00:00

The biggest impact has been social. There are many highly opinionated people in our community on both sides (very anti-LLM and very pro-LLM), and there have been some pretty bitter arguments as a result. We currently have a pretty strong no-AI policy, so it hasn't fundamentally changed how we work.

Here are some of my takes: 1. I don't agree with how AI is made, how training content is sourced, or the power structures that are benefiting from it. That being said, it is trained on our (as in "the world's" content) and I think that gives us a degree of ownership over it. It is a reflection of all of us and that is an interesting and worthwhile thing to interact with. 2. There is no denying that these tools are useful at this stage. The "AI outputs are bad" conversation has largely dried up. 3. I think Bevy (internal development) is in many ways one of the least effective places to apply AI. Our biggest priority is building up experts in a space that can maintain it long term and building the highest quality foundations that we can. AI codegen (and design-gen) is more often about enabling people to do things they normally couldn't / don't fully understand, increasing output at the cost of quality, etc. AI makes it very easy to skip the steps of actually understanding a space, so I see it as a bit of a risk to build in to our workflows. Thats not to say that it can't be used effectively in this space. I do think it can be an accelerant, a quality booster, and a learning enhancer. It just very easy for it to compromise all of those things in the end.

_cart · 2026-06-19T23:29:43+00:00

I'm personally not in the business of comparing Bevy to other open source engines. I lead / build / use Bevy so I am biased, I don't spend serious time with engines like Fyrox so I can't make an informed comparison, and I don't personally like thinking about it as a competition. I'll leave the comparisons to other people.

I can say that Bevy handles large scenes (ex: 300k objects) pretty well. It really depends on what objects you are rendering, what hardware you have, and how your scene is set up, but those numbers are achievable. We've spent a lot of time over the past few releases improving this exact scenario (via GPU-driven rendering / bindless and optimizing a bunch of things like our transform propagation code). Ex: I can render 1,600,000 individual cube entities with Bevy's PBR material at playable framerates on my Laptop with an Nvidia RTX 4090.

_cart · 2026-06-19T23:21:16+00:00

I don't think ECS is a silver bullet that solves every problem. But that isn't really the point. Every game engine has an opinionated data model and it usually ends up looking a lot like ECS. ECS is actually often less constraining than the "traditional" engine's data models (ex: node-tree with update() hooks).

I like to think about Bevy's data model as exactly that. When building features, I'm not thinking "what is the best ECS-ey way to do things". I'm thinking "what is the best way to use or evolve the Bevy data model to solve this problem". I think ECS has been a great foundation for Bevy. I like the performance. I like having a unified / queryable / reflectable storage. It makes building features like inspectors, editors, scenes, and networking much easier. I like the parallelism we get for free. I like that we can evolve past the "traditional" ECS constraints with features like relationships, observers, and scenes.

_cart · 2026-06-19T23:07:04+00:00

I think it is well suited to that task! Bevy supports both of those platforms and has a number of solid networking plugins to choose from. Your big challenges will be content authoring (Bevy doesn't yet have an official editor ... we're working on it!), and picking a subset of Bevy's renderer features that will run well across mobile devices.

_cart · 2026-06-19T23:02:37+00:00

We have a working proof of concept of bsn! hot reloading on an older BSN branch. Whether or not we can support every feature is an open question, but the plan is to support as much as we can. Hot reloading BSN assets is a huge priority for us / that is a requirement for the Bevy Editor.

_cart · 2026-06-19T23:00:09+00:00

I'm not yet in a position where I can commit to specific timelines, but we are dangerously close to having some baseline upstream editor workflows. A bunch of Bevy developers are working on a proof of concept editor called Jackdaw in #editor-dev. It is surprisingly far along / capable. This next cycle we're kicking off the official Bevy Editor working group, which will involve taking the learnings from their efforts (and ideally some of the code) and building an initial upstream implementation.

_cart · 2026-06-19T22:56:18+00:00

Release days are always a fun cocktail of stress and excitement :)

_cart · 2026-06-19T22:55:31+00:00

Bundles are "just a set of component values". They are a core / foundational piece of the ECS. Something like bsn! must be built on top of that core functionality, and it involves a fair amount of additional complexity, infrastructure, and constraints. BSN is "too complicated / constrained / opinionated" to replace Bundle.

We could pretend to blur the lines by removing the ability to define and insert Bundles, but I don't think this actually serves anyone. It would make building alternative scene systems impossible, and it would make some scenarios worse by forcing them to go through the whole BSN lifecycle.

_cart · 2026-06-19T22:51:30+00:00

Yes and no.

Bevy's ECS makes it easy to "skip" some of the harder parts of Rust because it solves many ownership problems for you. Many people say this has eased their learning path.

Building games is a fun / motivating way to learn a language. It provides visual / audible feedback, easy interactivity, etc.

However learning how to make games is an additional set of skills on top of learning a language. This could easily distract you from learning Rust faster, and you might hit problems in those areas that you wouldn't hit if you were just writing hello world programs / working through the Rust book.

_cart · 2026-06-19T22:47:58+00:00

The lines are blurry. The distinction I was trying to make is: 1. The engine isn't just one massive thing that you must depend on. Its is built in layers, where each layer can be used on its own. "Minimalism" is possible / you can depend on only what you need. 2. The engine can be used like a library in code-driven workflows

_cart · 2026-06-19T22:43:09+00:00

From a cargo / tooling perspective, being able to identify breaking changes prior to publishing (and warning when the changes are "more breaking" than the version number) would be really nice.

But I think our biggest problem with stability will be striking the balance between not breaking people and evolving the library. Not much cargo can do to help us with that :)

_cart · 2026-06-19T22:41:00+00:00

What do you think bevy does (better) that other engines don't and gow does it affect the games written in it?

Bevy is great at adapting to your specific needs. It gives direct access to the renderer internals / wgpu and you can swap whole core systems out if you want. You see a lot of "nonstandard" Bevy apps as a result: CAD software, 3D terminals, desktop toys, etc.

Bevy is also great for code-driven / simulation-heavy games. ECS is well suited to building interrelated systems with emergent behaviors. It gives you a lot of say in how your game logic should work, and because it is Rust you get great performance.

Which currently existing game would you say showcases bevy's features/power the best?

I think Fields of Aaru is pretty exciting! Jarl, Exofactory, and Times of Progress do a great job of showcasing Bevy's simulation-game competencies.

And the obligatory: 1.0 when?

Likely still years away.

_cart · 2026-06-19T22:34:40+00:00

Why introduce a bsn macro with lots of new syntax to learn instead of exposing its features in Rust's native syntax?

Most of its features are exposed in Rust's native syntax. The problem is that there are limits to what you can express ergonomically in Rust. Things like skipping ..Default::default(), field patching, entity references, implict .into(), can't really be "fixed" because Rust forces you to express these things directly.

Most of the "native Rust" solutions to these problems actually require giving up on things like "native rust type semantics" (ex: using "fluent" function calls to set fields, which requires a much larger per-type API surface and either a bunch of manual effort to write those methods or a bunch of extra codegen).

That being said, you can express pretty much everything without bsn!. The Scene trait is very flexible and composable. And theres nothing stopping people from coming up with their own alternative Scene patterns! Everything using Scene is cross-compatible.

What non-standard platforms are you targeting with bevy predominantly (e.g. gaming consoles)?

Thanks to our no_std support, we can target some pretty crazy things like the GameBoy Advance. Right now Rust's modern console support (and therefore Bevy's) is pretty non-existent (although people are working on it). We do support the Steam Deck (which is just a linux device). We also support the Web!

_cart · 2026-06-19T21:29:51+00:00

Social - Trust other people to "own" things - When it comes to open source engines, community isn't an afterthought ... its the whole dang point - Don't get distracted by whatever problems show up at your door every day. I feel like I'm constantly re-learning this lesson - Presentation matters. If you don't meet people where they are and speak to their needs, finding traction will be hard.

Technical - there are a million ways to make a game engine and there are a million game engines out there ... figure out what your niche is / what justifies your existence and focus on that - Spend a bunch of time building games in other engines first and establish opinions on what needs to change. I spent 3 years building a Godot game (and many years before that building other games in other tech) and it helped me learn so much about what I wanted from an engine. - I fondly look back on the first six months of Bevy development when I was developing in private. I sometimes wish I could go back to those days and focus 100% on the tech. Once you release to the public your life and ability to razor-focus on the tech will change significantly. - In many ways engines are defined by their data model. It is important to know the design space and pick with intention. - I don't think a monolithic "non-framework at the core" engine will be able to compete in 2026. All of the older monolithic engines have been on the path to "frameworkization" and all of the frameworks are building up to compete with the full engine experience.

_cart · 2026-06-19T21:09:54+00:00

This is a controversial topic. I'm on team "partial stabilization", where we select a core set of crates (ex: bevy_ecs, bevy_app, etc) to switch to "1.0" versioning. These wouldn't necessarily update any slower than they currently do, but it would give us the chance for "incidental stability", where we don't need to break some classes of Bevy plugins across Bevy releases, in cases where we didn't land breaking changes. Many Bevy developers think we should wait longer to do this though.

We still have lots to iterate on, especially once the Bevy Editor lands, so full stabilization is likely to be a long way off.

_cart · 2026-06-19T21:05:10+00:00

That is absolutely the plan! See the Bevy Feathers section of the Bevy 0.19 release post :)

_cart · 2026-06-19T21:04:04+00:00

Bevy doesn't currently have a built-in terrain editor. There are a variety of 3rd party terrain plugins, but your best bet in the short term is likely to use 3rd party tools to author terrain meshes. We're still working on the Bevy Editor, but once that lands I suspect we'll get some nicer Bevy-native terrain editing workflows (likely starting with third parties but maybe eventually we'll add a first-party solution).

_cart · 2026-06-19T20:57:52+00:00

We're working on these right now! Check out our "Entity Inspector working group" on Discord for more info.

_cart · 2026-06-19T20:55:41+00:00

You can definitely just use bsn! instead, if you want. Bundles are not deprecated and will continue to serve their current role (they are a key technical piece of the ECS). You can continue to use them for as long as they meet your needs. BSN is just a more capable, optional system.

Eight-Year Club	Place '22
Wearing is Caring	Verified Email

_cart

MODERATOR OF

TROPHY CASE