I think ECS is a new enough architecture that the patterns are still very much folk lore.
I think a lot of the way I try and structure my Bevy apps comes down to trying to separate the rendering from my game logic. Its very easy to confuse the two responsibilities.
Coming from the web and Ruby I find the lack of automated testing and TDD to be foreign to me. So I've been trying to figure out patterns that make my games easier to test. Hoping to write about it soon.
I found using partials between projects to be a headache. I wanted a way to standardize my UI for accessibility across all projects and not have to re-implement the same standards over and over. It's nice to be able to package the UI up into a gem and keep it maintained everywhere.
It's got a nice path for incremental adoption, so there is no need to go all-in unless you want to. Personally my Rails projects are all 95%+ ruby now.
Another nice knock off effect is that the LSP and integration with my IDE (neovim) is much nicer with Phlex components than it is with ERB.
I also think personally I don't like "magic" spaces like ERB where its hard for me to follow the code path. How does ERB manage multiline blocks with html in them? Hard to understand, harder to explain. To me it feels like there is less to worry about in Phlex where I'm thinking more in Ruby, less in the specifics of the view context.
Slots are pretty easy in Phlex. Have a look at the README in the repo I linked for an idea. I just create `with_column` or `with_header` methods that take a block and store it.
Phlex is an amazing project. Makes frontend fun again. I've built my own UI library using DaisyUI and Tailwindcss that we use in all our Rails projects: https://github.com/inhouse-work/protos
It cannot be overstated how nice it is to move away from erb and into pure ruby. Private methods as partials is a game changer for refactoring your UI.
As someone who's worked with Ruby for 12 years here are some insights:
Ruby makes message passing first class. That just changes how you think about programs. In exchange you give up passing functions so our anonymous functions are our blocks (actually just another object that can receive messages). So you don't `list(something)` you `something.list` and that lets you change what `.list` does depending on who `something` is very easily.
Ruby's defining feature is that the line between language author and program author is razer thin. You can completely change the language yourself by extending core classes. This is why we have `1.day` in Rails even though its not supported in the main language. DHH (author of Rails) could add that without consulting Matz (author of Ruby). So lots of stuff gets prioritized to make developers happy because its easy to add.
In Ruby the messages you receive are passed up the chain of ancestors. Your ancestors are a linked list of classes going back to a root class like `Object`. You can modify this linked list at will with mixins and inheritance with complete control (should I go before or after this other receiver).
Ruby's REPL and debugging experience is amazing. I often keep one tab with an `irb` or `rails console` open to sketch things while developing the code for it elsewhere. I'm also always inside a debugger to figure things out. When I'm in Rust or Python I'm met with a very different environment.
I would suggest taking a look at Phlex (https://www.phlex.fun/). This kind of ruby maximalism is very pleasing to the dev process. For the interaction I'm using hotwire and stimulus. Been using pure Phlex views in production for 2 years now. I wrote Protos (https://github.com/inhouse-work/protos) which is built on top of Phlex and adds a bunch of quality of life features I wanted.
I wrote https://taintedcoders.com/ for anyone looking for an introduction to Rust game development with Bevy.
Bevy is still early, but the sweet spot right now is simulations. It's particularly weak in its UI, but that's the coming focus for getting the editor built.
Sounds a lot like what Wolfram is working on with categorizing cellular automota. Strikes me that a lot of his work is very biological in its search for axioms from experimentation
Author of https://taintedcoders.com/ here. Thanks for the mention. I hope to one day be a "consistently up to date" resource :p.
Bevy is the first game engine that made me feel the way Rails did about web development but for game dev. Most game development is focused on the art and the editor which makes sense. But Bevy is really centered around the coder which I found refreshing.
Love to see writeups like these, especially the gore. Great read.
I learned a lot about Rust by making games with Bevy and writing down everything I learned: https://taintedcoders.com/
The smaller the game the more likely you are to finish. I usually started with making the movement fun and then developed some game like concepts around it.
I also highly recommend starting by making simulations instead of games as when you're alone they are still a blast to see come alive. Building boids is a fantastic exercise I do in any new engine.
The gist is that instead of partitioning by type you sub partition by usage. Bevy does this by optimizing your storage based on the bundles (groups of components) you create. Flecs does the same but I'm not sure of the exact mechanism.
Check out the new Bevy Scene Notation: https://taintedcoders.com/bevy/bsn