Bevy 0.20
bevy.org
bevy.org
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 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.
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 :)
Maybe I should throw some agents at it and then maybe I can stop thinking about it?
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?
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.
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.
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".
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.
Or you're without both Wayland and X11?
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.
What's the toughest thing in Rust to learn? Lifetimes? Or these Box/Arc/Rc/Pin etc?
is this directly enough?
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_...
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".
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.
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.
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.
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 :|
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'd probably mention Tiny Glade (Bevy ECS only) and Polders specifically.
It even landed a nomination in the 2025 BAFTA Game Awards.
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".
bevy_app 0.17.3
bevy_derive 0.17.3
bevy_ecs 0.17.3
bevy_ecs_macros 0.17.3
bevy_input 0.17.3
bevy_macro_utils 0.17.3
bevy_math 0.17.3
bevy_platform 0.17.3
bevy_ptr 0.17.3
bevy_reflect 0.17.3
bevy_reflect_derive 0.17.3
bevy_state 0.17.3
bevy_state_macros 0.17.3
bevy_tasks 0.17.3
bevy_time 0.17.3
bevy_utils 0.17.3
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.