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.
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.
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.
Dioxus is much easier to understand though, and Leptos and Yew are just HTML. One of the core issues is that (a) a scene format for editors, (b) a SwiftUI-like DSL for UI, and (c) a DSL for spawning game objects are just different problems. A single syntax that tries to cover all three ends up being a compromise that satisfies few.
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
"The first agent curls his brow and listens to the human tell him exactly how to win. He expects me to pass on this info/intel to the next bot to snatch victory from me? I've smiled and nodded plenty to win this one."
> 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
Sounds like you're building a simulation, not a game :) Games usually aren't so realistic as to be based on a ton of academic models, and gets "not so fun" when you try to make things too realistic. Maybe it'll be different in your game, maybe it'll be fun! Just worth watching out for the typical "if I just make it hyper-realistic it'll be hyper-fun" trap that myself and others have fallen into many times, including when building our own city simulations :) Again, don't wanna discourage, go for it! Worst case scenario you've learnt something new!
I’m approaching it as a simulator core that provides a bunch of entities and primitives, that then couples with plugins providing simulation layers, all of which are optional or changeable
So should be trivial layer to adjust any part or provide simple/complex versions or whatever!
And thank you for the feedback! Did you publish your simulator anywhere?
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.
In the Rust ecosystem, the "0" in a "0.x" semver means very little :) Lots of widely used and stable projects version themselves like this indefinitely.
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.
WESL developer here, we are absolutely enjoying working with Bevy to build a great shading language! Building things at scale comes with so many interesting challenges for me.
Feel free to ask anything about the language server wgsl-analyzer and our wesl compilers! And if you have ideas about how to make shading languages better, do let me know. I think about that a lot.
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'm doing something similar. Building a text/tactical RPG with typed/structured markdown as the authoring language. So far I've built libraries for character and item rendering, as well as scene graph parsing with procedural generation (also in markdown). Now I'm actually introducing Bevy to enable animation and interactivity. First time using Bevy, and I'm also using teams of agents to do the development, driven by a custom system of plans and review/feedback.
All my graphics are procedural, with no assets apart from open fonts.
The first game is meant to be a sort of Isekei parody, so the animation and character design is anime inspired, with tactical RPG gameplay, and some time-travel/reset mechanics. The story gets into the irony of being a game so magic not being real on Earth, and some historical Earth scientists play a part in the deeper lore modules. The magic construction is an actual MLP puzzle with polar coordinates.
I'm going to put the dmg up on a website next week maybe. I just tested LAN for the first time with a few friends and it was very fun, but we found some major imbalances.
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)
> However so far it very hard to even get started in it. (Haven't even gotten it to build)
Haven't been my experience on either Linux, macOS or Windows, what errors are you seeing here?
Bevy is somewhat modular but it's also kind of coupled. You could use bevy_ecs by itself, and lots of things by themselves, but lots of them also kind of assume you use the rest too. Although it seems there are games that use everything-sans-renderer, so modular it is, in some ways.
Yeah I was wondering if some things are more coupled together. The issue I'm having is building it on a system without Wayland installed is very hard (or possibly impossible).
Without Wayland and X11? I'm targeting both (one shared build though), using Wayland when available otherwise defaulting to X11, and seems to work out in most cases.
No just without Wayland. My system didn't have Wayland installed because it's old enough not to include it by default and my card doesn't support it. However, a short while ago I got it to build by installing libwayland. (I was afraid my system might break by installing it but that doesn't seem to be the case so far.)
Then I don't see why you'd need libwayland at all? Build only for X11 and it won't try to use Wayland? X11 is enabled by default (wayland is even behind a feature flag), and you can force it with WINIT_UNIX_BACKEND=x11 as well.
People should be giving more credit to Bevy regarding Tiny Glade, particularly the people who like to bring up Tiny Glade's custom renderer to detract from Bevy's accomplishments and capabilities. It takes substantially more software infrastructure to make a game engine than just the renderer. Looking through Tiny Glade's third party licenses, the following are listed:
The fact that Tiny Glade was even able to just turn off Bevy's renderer while keeping the entire rest of the needed infrastructure so that they could write their own custom renderer on top of it is nothing short of remarkable.
> particularly the people who like to bring up Tiny Glade's custom renderer to detract from Bevy's accomplishments and capabilities
You're reading it the wrong way. Tiny Glade is just a poor example to show off Bevy because the only impressive thing about it is its graphics, which is not Bevy's.
> The fact that Tiny Glade was even able to just turn off Bevy's renderer while keeping the entire rest of the needed infrastructure so that they could write their own custom renderer on top of it is nothing short of remarkable.
A lot of that is pretty standard for a game engine, actually. For example, if you were to compare with Unity, you can run the engine headless in server environments and it swaps between renderer implementations (DirectX, Vulkan, WebGL, etc.) internally. There's also Scriptable Render Pipeline which lets you customize the renderer at a level above the platform graphics APIs.
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".
Learning lifetimes in Rust I've found to be quite like when I first learned pointers in C/C++. They're the hardest most enigmatic thing in the world until at one point something suddenly "clicks" and they just make sense, and you'll wonder how you ever struggled with them in the first place.
For me the actual toughest thing to learn were procedural macros, and the reason for that is because actually implementing them is more on the niche side of programming compared to using them, so most "learning Rust" resources just hand wave them away, and their usage is so special cased that all the limited learning resources around them target specific niche use cases that might not be what you in particular would use them for.
I guess we may be talking at cross purposes here - idiomatic usages of the pin macros don't really mean you need to understand whats going on here (beyond "async futures need to be pinned in order to repeatedly mutate them").
If you need to produce a type that interacts with Pin, it's a whole other level of hell.
I think if you are coming from systems programming languages, or even if managed, languages that have explicit notion of stack and heap, Rust concepts are easier to learn, as they are quite similar.
What is probably more complicated to learn, and me as polyglot dev with limited brain capacity, are the ways of async Rust, Pin and co.
I feel like your answer is maybe tuned towards general Rust system programming, programming with Rust and Bevy is very different, as their ECS kind of hides a lot of warts. You basically don't even have to understand stack vs heap, or Pin or Box and a whole lot of other stuff, to build a simple Bevy game, as Bevy as a sort of automatic dependency injection in functions registered as systems, and more.
With that said, of course you'd eventually come across those things, especially as you try to troubleshoot your own code and go down the Bevy internals stack, and it's generally helpful to know the language you use for your game :) But I don't think it's a requirement to know those things before you get your feet wet.
Edit: I maybe realize now that parent didn't actually ask for "Rust+Bevy answer" but just Rust so I might be the one who tuned my answer incorrectly :|
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".
The answer to all forms of "How is [X] not intuitive?" is that the person finding it unintuitive doesn't have other points of reference that make it intuitive. Lots of people have spent their programming life working with languages that don't have the concept of generics, or maybe have even worked on things where they were using generics but didn't know that's what they were doing.
Very few things are truly intuitive, they just happen to be similar to other things you've done and so you've got a step up on understanding them. Really good software engineers tend to be constantly playing with things outside their usual domain and so have broader range of concepts they can reach for when the time comes.
because i was stupid lol. i’d only done (very) basic duck typed generics in c++ before then.
all i wanted was to add a new method i could call in the same way as all the methods on Iterator (map, filter, etc.). and was suddenly confronted with `impl Trait2 for T where T: Trait1`. which makes perfect sense now. but at the time was unparseable.
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.
My Bevy game (released on Steam) has ~37k lines of Rust, and is stuck on Bevy 0.15 for this reason. It's not been a big problem for me though, because Iv'e ran into very few Bevy bugs (none that forced an update) and I was deep enough into production that I had already solved all problems with the 0.15 feature set. Overall, it's been a pleasure, and at the time of the 0.14->0.15 upgrade my codebase was small enough that it was done in an hour or so.
Most of the time, the time you spend on these upgrades isn't "I spent 10 hours rewriting code to use new APIs" but rather "I spent 1 hour rewriting the code, 10 hours testing", and no LLMs can do those 10 hours of testing properly yet.
Sure they can. Make the AI play the game pre and post bevy update. And difference down to a pixel can be flagged. In fact you can get hundreds of hours of testing this way using sub-agents.
Sure, the AI plays the game, says everything makes sense, does this mean it's coherent and consistent? No.
I'd urge you to try this yourself and you'll see how much they miss and misunderstand. They're nowhere near to being close to be able to do that sort of playtesting themselves.
Any game that been 100% made by LLMs in a vibe-coding way where the author does no testing themselves, will guaranteed be an absolutely mess and incoherent. This is the state of the art today at least, who knows what tomorrow will bring.
You’ve taken my statement, that an LLM can help test a game by running hundreds of hours of gameplay equivalence between versions(which btw means the AI doesn't say "it makes sense", your equivalence checker does), and stretched it into a claim that I’m saying games can be made entirely by LLMs through vibe coding with zero human testing. That’s such a blatant misrepresentation of my argument that I struggle to take your comment in good faith.
The difference would likely not be down to a pixel, either by dependence on how a model provider feels that day, the hallucinations of the day, or just some odd tangent that would get solved by ~100x tokens for verification. The hundreds of hours of testing could all effectively be 1===1, but it all looks green.
You have the model play both versions of the game in the same way at the same time. The equality would of course not come from the model, it comes from your testing harness. You just use the model to automatically play the game. SO you are checking game version A(inputs) == game version B(inputs). Where the AI generates the inputs that play through the game 10 times in different ways for example.
The testing harness would have to be updated per game feature and to accommodate model tendencies or quirks. This sounds like regression tests with llms and some extra steps.
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.
It's been smooth sailing upgrading for me. I think .17 was the one with the most pain for me? It's been a while but things have been relatively stable.
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
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.
Bevy is 0.x, this breaking change can happen. But for that to be possible, there should be a credible alternative to the current BSN syntax
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.
Dioxus is much easier to understand though, and Leptos and Yew are just HTML. One of the core issues is that (a) a scene format for editors, (b) a SwiftUI-like DSL for UI, and (c) a DSL for spawning game objects are just different problems. A single syntax that tries to cover all three ends up being a compromise that satisfies few.
https://taintedcoders.com/ has been updated to 0.20
So has my gimmick https://crates.rugaex.com/
Interesting to see what projects are first to update to 0.20. In the first few days it's mostly AI lead, e.g. titan engine and ai game kit.
This is my go-to resource
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
Haha well, as much as I’d love making this by hand I don’t have the time - so this way I get to focus on gameplay and simulator mechanics!
"The first agent curls his brow and listens to the human tell him exactly how to win. He expects me to pass on this info/intel to the next bot to snatch victory from me? I've smiled and nodded plenty to win this one."
> 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
Sounds like you're building a simulation, not a game :) Games usually aren't so realistic as to be based on a ton of academic models, and gets "not so fun" when you try to make things too realistic. Maybe it'll be different in your game, maybe it'll be fun! Just worth watching out for the typical "if I just make it hyper-realistic it'll be hyper-fun" trap that myself and others have fallen into many times, including when building our own city simulations :) Again, don't wanna discourage, go for it! Worst case scenario you've learnt something new!
For sure!
I’m approaching it as a simulator core that provides a bunch of entities and primitives, that then couples with plugins providing simulation layers, all of which are optional or changeable
So should be trivial layer to adjust any part or provide simple/complex versions or whatever!
And thank you for the feedback! Did you publish your simulator anywhere?
I've been meaning to do the same one day but the time/energy just hasn't been available.
Maybe I should throw some agents at it and then maybe I can stop thinking about it?
That’s exactly what I’ve been doing, and so far so good!
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.
The 0.2 version number would typically imply that breaking changes are to be expected and that it’s not ready for commercial projects
In the Rust ecosystem, the "0" in a "0.x" semver means very little :) Lots of widely used and stable projects version themselves like this indefinitely.
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.
WESL developer here, we are absolutely enjoying working with Bevy to build a great shading language! Building things at scale comes with so many interesting challenges for me.
Feel free to ask anything about the language server wgsl-analyzer and our wesl compilers! And if you have ideas about how to make shading languages better, do let me know. I think about that a lot.
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'm doing something similar. Building a text/tactical RPG with typed/structured markdown as the authoring language. So far I've built libraries for character and item rendering, as well as scene graph parsing with procedural generation (also in markdown). Now I'm actually introducing Bevy to enable animation and interactivity. First time using Bevy, and I'm also using teams of agents to do the development, driven by a custom system of plans and review/feedback.
All my graphics are procedural, with no assets apart from open fonts.
The first game is meant to be a sort of Isekei parody, so the animation and character design is anime inspired, with tactical RPG gameplay, and some time-travel/reset mechanics. The story gets into the irony of being a game so magic not being real on Earth, and some historical Earth scientists play a part in the deeper lore modules. The magic construction is an actual MLP puzzle with polar coordinates.
I'd love to give it a shot if it's available!
I'm going to put the dmg up on a website next week maybe. I just tested LAN for the first time with a few friends and it was very fun, but we found some major imbalances.
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)
> However so far it very hard to even get started in it. (Haven't even gotten it to build)
Haven't been my experience on either Linux, macOS or Windows, what errors are you seeing here?
Bevy is somewhat modular but it's also kind of coupled. You could use bevy_ecs by itself, and lots of things by themselves, but lots of them also kind of assume you use the rest too. Although it seems there are games that use everything-sans-renderer, so modular it is, in some ways.
Yeah I was wondering if some things are more coupled together. The issue I'm having is building it on a system without Wayland installed is very hard (or possibly impossible).
Without Wayland and X11? I'm targeting both (one shared build though), using Wayland when available otherwise defaulting to X11, and seems to work out in most cases.
Or you're without both Wayland and X11?
No just without Wayland. My system didn't have Wayland installed because it's old enough not to include it by default and my card doesn't support it. However, a short while ago I got it to build by installing libwayland. (I was afraid my system might break by installing it but that doesn't seem to be the case so far.)
Then I don't see why you'd need libwayland at all? Build only for X11 and it won't try to use Wayland? X11 is enabled by default (wayland is even behind a feature flag), and you can force it with WINIT_UNIX_BACKEND=x11 as well.
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.
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.
People should be giving more credit to Bevy regarding Tiny Glade, particularly the people who like to bring up Tiny Glade's custom renderer to detract from Bevy's accomplishments and capabilities. It takes substantially more software infrastructure to make a game engine than just the renderer. Looking through Tiny Glade's third party licenses, the following are listed:
The fact that Tiny Glade was even able to just turn off Bevy's renderer while keeping the entire rest of the needed infrastructure so that they could write their own custom renderer on top of it is nothing short of remarkable.> particularly the people who like to bring up Tiny Glade's custom renderer to detract from Bevy's accomplishments and capabilities
You're reading it the wrong way. Tiny Glade is just a poor example to show off Bevy because the only impressive thing about it is its graphics, which is not Bevy's.
> The fact that Tiny Glade was even able to just turn off Bevy's renderer while keeping the entire rest of the needed infrastructure so that they could write their own custom renderer on top of it is nothing short of remarkable.
A lot of that is pretty standard for a game engine, actually. For example, if you were to compare with Unity, you can run the engine headless in server environments and it swaps between renderer implementations (DirectX, Vulkan, WebGL, etc.) internally. There's also Scriptable Render Pipeline which lets you customize the renderer at a level above the platform graphics APIs.
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.
As the Rust folks are here.
What's the toughest thing in Rust to learn? Lifetimes? Or these Box/Arc/Rc/Pin etc?
Learning lifetimes in Rust I've found to be quite like when I first learned pointers in C/C++. They're the hardest most enigmatic thing in the world until at one point something suddenly "clicks" and they just make sense, and you'll wonder how you ever struggled with them in the first place.
For me the actual toughest thing to learn were procedural macros, and the reason for that is because actually implementing them is more on the niche side of programming compared to using them, so most "learning Rust" resources just hand wave them away, and their usage is so special cased that all the limited learning resources around them target specific niche use cases that might not be what you in particular would use them for.
Of those, Pin, by some margin.
But also Pin is the one you're least likely to run into in most projects.
Yeah, I can't really see why anyone outside of the implementers of the low-level futures runtimes would need to interact with Pin directly.
https://docs.rs/async-stream/latest/async_stream/#usage
is this directly enough?
I guess we may be talking at cross purposes here - idiomatic usages of the pin macros don't really mean you need to understand whats going on here (beyond "async futures need to be pinned in order to repeatedly mutate them").
If you need to produce a type that interacts with Pin, it's a whole other level of hell.
I mean, in practice Rc is the one I run into the least, but pin only comes up occasionally, yes. Maybe once or twice a year on one of my projects.
As polyglot dev, depends.
I think if you are coming from systems programming languages, or even if managed, languages that have explicit notion of stack and heap, Rust concepts are easier to learn, as they are quite similar.
What is probably more complicated to learn, and me as polyglot dev with limited brain capacity, are the ways of async Rust, Pin and co.
I feel like your answer is maybe tuned towards general Rust system programming, programming with Rust and Bevy is very different, as their ECS kind of hides a lot of warts. You basically don't even have to understand stack vs heap, or Pin or Box and a whole lot of other stuff, to build a simple Bevy game, as Bevy as a sort of automatic dependency injection in functions registered as systems, and more.
With that said, of course you'd eventually come across those things, especially as you try to troubleshoot your own code and go down the Bevy internals stack, and it's generally helpful to know the language you use for your game :) But I don't think it's a requirement to know those things before you get your feet wet.
Edit: I maybe realize now that parent didn't actually ask for "Rust+Bevy answer" but just Rust so I might be the one who tuned my answer incorrectly :|
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".
The answer to all forms of "How is [X] not intuitive?" is that the person finding it unintuitive doesn't have other points of reference that make it intuitive. Lots of people have spent their programming life working with languages that don't have the concept of generics, or maybe have even worked on things where they were using generics but didn't know that's what they were doing.
Very few things are truly intuitive, they just happen to be similar to other things you've done and so you've got a step up on understanding them. Really good software engineers tend to be constantly playing with things outside their usual domain and so have broader range of concepts they can reach for when the time comes.
because i was stupid lol. i’d only done (very) basic duck typed generics in c++ before then.
all i wanted was to add a new method i could call in the same way as all the methods on Iterator (map, filter, etc.). and was suddenly confronted with `impl Trait2 for T where T: Trait1`. which makes perfect sense now. but at the time was unparseable.
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.
for my own sake, i’ll note that i started learning rust in 2020. i’m no longer confused about Traits.
Go bevy!
[flagged]
My Bevy game (released on Steam) has ~37k lines of Rust, and is stuck on Bevy 0.15 for this reason. It's not been a big problem for me though, because Iv'e ran into very few Bevy bugs (none that forced an update) and I was deep enough into production that I had already solved all problems with the 0.15 feature set. Overall, it's been a pleasure, and at the time of the 0.14->0.15 upgrade my codebase was small enough that it was done in an hour or so.
You could probably point claude at these release notes and have it need no further instructions.
Most of the time, the time you spend on these upgrades isn't "I spent 10 hours rewriting code to use new APIs" but rather "I spent 1 hour rewriting the code, 10 hours testing", and no LLMs can do those 10 hours of testing properly yet.
Sure they can. Make the AI play the game pre and post bevy update. And difference down to a pixel can be flagged. In fact you can get hundreds of hours of testing this way using sub-agents.
Sure, the AI plays the game, says everything makes sense, does this mean it's coherent and consistent? No.
I'd urge you to try this yourself and you'll see how much they miss and misunderstand. They're nowhere near to being close to be able to do that sort of playtesting themselves.
Any game that been 100% made by LLMs in a vibe-coding way where the author does no testing themselves, will guaranteed be an absolutely mess and incoherent. This is the state of the art today at least, who knows what tomorrow will bring.
You’ve taken my statement, that an LLM can help test a game by running hundreds of hours of gameplay equivalence between versions(which btw means the AI doesn't say "it makes sense", your equivalence checker does), and stretched it into a claim that I’m saying games can be made entirely by LLMs through vibe coding with zero human testing. That’s such a blatant misrepresentation of my argument that I struggle to take your comment in good faith.
The difference would likely not be down to a pixel, either by dependence on how a model provider feels that day, the hallucinations of the day, or just some odd tangent that would get solved by ~100x tokens for verification. The hundreds of hours of testing could all effectively be 1===1, but it all looks green.
You have the model play both versions of the game in the same way at the same time. The equality would of course not come from the model, it comes from your testing harness. You just use the model to automatically play the game. SO you are checking game version A(inputs) == game version B(inputs). Where the AI generates the inputs that play through the game 10 times in different ways for example.
The testing harness would have to be updated per game feature and to accommodate model tendencies or quirks. This sounds like regression tests with llms and some extra steps.
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.
It's been smooth sailing upgrading for me. I think .17 was the one with the most pain for me? It's been a while but things have been relatively stable.