Some great stuff in this release. I contributed some rendering code, most notably reducing the renderer to O(number of changed entities) on the CPU, that went unmentioned in the release notes.
I do have to say, however, that BSN syntax isn't good and is getting worse. There are too many sigils, and -- to separate list elements (!) is an indication that it's been designed into a corner. The fact that it's not LR(1) should have been an indication that it was misdesigned. The scene format should be redesigned to be editor-first, with ease of VCS merging as a paramount consideration.
I was curious how the design was arrived at and found some of the trade-offs discussed in this issue[0]. I personally liked the idea of using a combination of semicolons and commas to separate entities and components; but oh well, I guess we'll get used to the double-dash.
It's not that dissimilar to how Dioxus does this kind of thing with rsx! but yeah, it first got released in 0.19 and got big improvements in this release. It'll be interesting to see how uptake and adoption goes.
I love the work you are doing in Bevy. I often filter the PR list based on your handle just to see what big graphics/performance work you are cooking up.
I unfortunately do agree with you on the BSN syntax, I guess it's a matter of tradeoffs, but I don't think backward breaking changes are off the table for the foreseeable future, so curious what can be done to improve the syntax in the next couple of releases.
Although what I really look forward to is auto-formatting of the syntax, I care about the feel and look of the syntax, but I care even more about consistency across my code base.
What a coincidence! I had been thinking of trying to make my own version of a city builder game (like sim city or cities skylines) for years and finally started last week - using rust and Bevy for the simulator
I’m trying to make the most realistic city simulator I can, using published papers on economy models, welfare, immigration, social policies… to drive each aspect of the simulation - and then use it to drive the game
So far I’ve used a team of agents to build the firsg phases of the simulator, and it’s looking really promising!
It’s my first time making such a complex game, but I’m super excited to see where it goes :)
I keep seeing people mention they're starting a game using Bevy in response to this news...and then they mention a "team of agents" making the game. :P
I have been learning Bevy for fun lately, it's been a blast. They have been introducing breaking changes left and right but I think its in the service of addressing important things. It's probably too immature to stake a real commercial product on it at the moment, and I'm saying that as the kind of person who is attracted to a cool architecture rather than the pragmatics of shipping.
I mostly use Godot, and I've been happy with that choice, but one thing I've been sligthly envious of with Bevy is that (from afar) many of the people involved with building the engine seem to be both very opinionated and knowledgable in the area they are contributing (I get the impression that this might just be more common with Rust in general).
In Godot it happens pretty often that the focus is on just implementing some feature first, and then it takes a number of releases (and passes by people who care about UX) before it feels "polished".
The Bevy team are doing amazing work and it's great to see it being worked on all the time. I'm not a game developer, but it's interesting to see it listed in some jobs for companies building simulations.
I built a real time strategy game using Bevy, sort of like Starcraft 2, once I learned that SC3 would be an FPS. I relied on a team of claude fable/opus/sonnet agents to develop assets in blender, generative models for the art, and to do most of the coding, but I have a feeling that Bevy's design played a role in shaping the game and the ease of adding new features. The whole thing took a week of running the agents in the background / overnight and the result is very fun to play and includes a LAN mode. Not the level of polish and balance of SC2, but its actually comparable, which is mind blowing to me.
By some coincidence I've been looking at bevy and other engines lately. Bevy sounds like it had thought put into it's library to make it more modular. However so far it very hard to even get started in it. (Haven't even gotten it to build)
The breaking Rendering changes have always been the big challenge, especially with external plugins that need time to migrate too. They're starting to get less disruptive over this past year.
different people struggle with different things. your existing experience is a major factor. there are a lot of concepts in rust that you may have already figured out in another language.
personally, i started learning rust two years after i started programming. at that point i had basic experience with c, c++, and some assembly.
i struggled with pretty much everything. i recall traits being particularly confusing. i’m not sure i fully got them until i messed with typeclasses in haskell at some later point.
but, honestly, i don’t remember struggling too much with lifetimes. i think the compiler is pretty good at suggesting fixes for common issues. i think it was helpful that i knew what a pointer was and had debugged segfaults. also, i didn’t really have an existing way of structuring programs that i was trying to reconcile with rust.
Box, Arc, and Rc you’ll figure out as you need them. you can think of them as tools which let you escape lifetimes.
Pin you won’t need to think about for a very long time [0]. You should check out my guide [1] if you’re interested though :). There are many others.
[0]: unless you’re the guy i’ve tasked with fully understanding FuturesUnordered as his very first introduction to Rust, lmao.
All they do is guarantee that a type has methods A,B,C available.
What might be slightly confusing are trait bounds on generics. They are kind of like traits themselves but not exactly. They implicitly say "this generic parameter must make methods A, B, C available via Trait X".
Traits are confusing if you came from C or Python but they work a lot like interfaces in Java or some other class based OOP language. Until you get to the difference between impl and dyn, that is.
While I don't disagree with the toy/game distinction I also think the lines are blurry enough that I'd place the former as a subset of the latter.
They are sold in the same places, run on the same hardware, use the same conventions and interactions, fill the same place in our lives, and are discussed in the same places. A lot of "proper" games also have digital toy modes: Minecraft and various sim games come to mind, but there are many. Insisting that they are completely distinct things seems mostly silly TBH. Almost everyone in the world would recognize Tiny Glade and its ilk as a kind of "computer/video game".
Some great stuff in this release. I contributed some rendering code, most notably reducing the renderer to O(number of changed entities) on the CPU, that went unmentioned in the release notes.
I do have to say, however, that BSN syntax isn't good and is getting worse. There are too many sigils, and -- to separate list elements (!) is an indication that it's been designed into a corner. The fact that it's not LR(1) should have been an indication that it was misdesigned. The scene format should be redesigned to be editor-first, with ease of VCS merging as a paramount consideration.
I was curious how the design was arrived at and found some of the trade-offs discussed in this issue[0]. I personally liked the idea of using a combination of semicolons and commas to separate entities and components; but oh well, I guess we'll get used to the double-dash.
[0]: https://github.com/bevyengine/bevy/issues/25616
It's not that dissimilar to how Dioxus does this kind of thing with rsx! but yeah, it first got released in 0.19 and got big improvements in this release. It'll be interesting to see how uptake and adoption goes.
I love the work you are doing in Bevy. I often filter the PR list based on your handle just to see what big graphics/performance work you are cooking up.
I unfortunately do agree with you on the BSN syntax, I guess it's a matter of tradeoffs, but I don't think backward breaking changes are off the table for the foreseeable future, so curious what can be done to improve the syntax in the next couple of releases.
Although what I really look forward to is auto-formatting of the syntax, I care about the feel and look of the syntax, but I care even more about consistency across my code base.
What a coincidence! I had been thinking of trying to make my own version of a city builder game (like sim city or cities skylines) for years and finally started last week - using rust and Bevy for the simulator
I’m trying to make the most realistic city simulator I can, using published papers on economy models, welfare, immigration, social policies… to drive each aspect of the simulation - and then use it to drive the game
So far I’ve used a team of agents to build the firsg phases of the simulator, and it’s looking really promising!
It’s my first time making such a complex game, but I’m super excited to see where it goes :)
I keep seeing people mention they're starting a game using Bevy in response to this news...and then they mention a "team of agents" making the game. :P
I have been learning Bevy for fun lately, it's been a blast. They have been introducing breaking changes left and right but I think its in the service of addressing important things. It's probably too immature to stake a real commercial product on it at the moment, and I'm saying that as the kind of person who is attracted to a cool architecture rather than the pragmatics of shipping.
https://taintedcoders.com/ has been updated to 0.20
This is my go-to resource
The whole Solari path tracing work is nothing short of impressive.
If you want to learn more, Jasmine gave a good introductory talk about it last week at the Bevy meetup which is available on YouTube.
https://youtube.com/watch?v=V1XJtUOsY2s
I mostly use Godot, and I've been happy with that choice, but one thing I've been sligthly envious of with Bevy is that (from afar) many of the people involved with building the engine seem to be both very opinionated and knowledgable in the area they are contributing (I get the impression that this might just be more common with Rust in general).
In Godot it happens pretty often that the focus is on just implementing some feature first, and then it takes a number of releases (and passes by people who care about UX) before it feels "polished".
The Bevy team are doing amazing work and it's great to see it being worked on all the time. I'm not a game developer, but it's interesting to see it listed in some jobs for companies building simulations.
I built a real time strategy game using Bevy, sort of like Starcraft 2, once I learned that SC3 would be an FPS. I relied on a team of claude fable/opus/sonnet agents to develop assets in blender, generative models for the art, and to do most of the coding, but I have a feeling that Bevy's design played a role in shaping the game and the ease of adding new features. The whole thing took a week of running the agents in the background / overnight and the result is very fun to play and includes a LAN mode. Not the level of polish and balance of SC2, but its actually comparable, which is mind blowing to me.
I'd love to give it a shot if it's available!
By some coincidence I've been looking at bevy and other engines lately. Bevy sounds like it had thought put into it's library to make it more modular. However so far it very hard to even get started in it. (Haven't even gotten it to build)
yes it's very well designed, and because if it's modularity it's well positioned both to support an editor (eg. jackdaw) and llm assisted coding.
Bevy has great ergonomics until a point release drops. You end up maintaining engine migrations instead of shipping gameplay.
The breaking Rendering changes have always been the big challenge, especially with external plugins that need time to migrate too. They're starting to get less disruptive over this past year.
You could probably point claude at these release notes and have it need no further instructions.
As the Rust folks are here.
What's the toughest thing in Rust to learn? Lifetimes? Or these Box/Arc/Rc/Pin etc?
unfortunately, It Depends.
different people struggle with different things. your existing experience is a major factor. there are a lot of concepts in rust that you may have already figured out in another language.
personally, i started learning rust two years after i started programming. at that point i had basic experience with c, c++, and some assembly.
i struggled with pretty much everything. i recall traits being particularly confusing. i’m not sure i fully got them until i messed with typeclasses in haskell at some later point.
but, honestly, i don’t remember struggling too much with lifetimes. i think the compiler is pretty good at suggesting fixes for common issues. i think it was helpful that i knew what a pointer was and had debugged segfaults. also, i didn’t really have an existing way of structuring programs that i was trying to reconcile with rust.
Box, Arc, and Rc you’ll figure out as you need them. you can think of them as tools which let you escape lifetimes.
Pin you won’t need to think about for a very long time [0]. You should check out my guide [1] if you’re interested though :). There are many others.
[0]: unless you’re the guy i’ve tasked with fully understanding FuturesUnordered as his very first introduction to Rust, lmao.
[1]: https://github.com/soooch/async-intuition/blob/main/src/pin_...
How are traits not intuitive?
All they do is guarantee that a type has methods A,B,C available.
What might be slightly confusing are trait bounds on generics. They are kind of like traits themselves but not exactly. They implicitly say "this generic parameter must make methods A, B, C available via Trait X".
Traits are confusing if you came from C or Python but they work a lot like interfaces in Java or some other class based OOP language. Until you get to the difference between impl and dyn, that is.
Of those, Pin, by some margin.
But also Pin is the one you're least likely to run into in most projects.
What are some good games made with Bevy?
https://github.com/ThierryBerger/bevy_awesome_prod
I'd probably mention Tiny Glade (Bevy ECS only) and Polders specifically.
Tiny Glade is probably the most successful/well-known one but it's not really a game and it's most impressive feature (renderer) is not Bevy's.
While I don't disagree with the toy/game distinction I also think the lines are blurry enough that I'd place the former as a subset of the latter.
They are sold in the same places, run on the same hardware, use the same conventions and interactions, fill the same place in our lives, and are discussed in the same places. A lot of "proper" games also have digital toy modes: Minecraft and various sim games come to mind, but there are many. Insisting that they are completely distinct things seems mostly silly TBH. Almost everyone in the world would recognize Tiny Glade and its ilk as a kind of "computer/video game".
Tiny Glade is absolutely a game - it's a "cozy" building game, that's a whole genre.
It even landed a nomination in the 2025 BAFTA Game Awards.
Tiny Glade is great, and it looks like Tunnet is on there too.
Go bevy!