https://taintedcoders.com/ has been updated to 0.20
334 karma · joined July 7, 2022
Check out the new Bevy Scene Notation: https://taintedcoders.com/bevy/bsn
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.
He's also got plenty of free resources which I love to watch: https://www.youtube.com/@chrisbiscardi
- https://taintedcoders.com/ (I'm the author)
- https://bevy.org/learn/book/intro/
- https://www.youtube.com/@chrisbiscardi
- https://www.youtube.com/@PhaestusFox
Lots of good stuff on the official Bevy discord too
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.
To create them declaratively (not needing to call them in a set order) you just create a module that defines `before_template` and calls `vanish`: https://www.phlex.fun/miscellaneous/v2-upgrade.html#removed-...
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.
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.
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.
If anyone needs ideas, making [boids](https://slsdo.github.io/steering-behaviors/) in Bevy is a great weekend project.
There is a Ruby version that is also very readable: https://github.com/ileitch/disruptor
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.
Here is one in Ruby: https://github.com/ileitch/disruptor
Both languages are quite readable and I've used these to teach the concepts to beginners.
An interesting alternative in the Bevy space is Bevy XPBD which I also wrote about: https://taintedcoders.com/bevy/xpbd/
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.
I've written about the details here: https://taintedcoders.com/bevy/archetypes/
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.
There are lots of stuff missing on the bevy cheatbook (https://bevy-cheatbook.github.io) and lots more hidden in the Discord that are unsearchable on Google so I hoped this would help fill the gap for teaching some friends.
As it stands its pretty common to hold a `HashMap<Index, Entity>` and manually manage the data structure through derefs or some system that keeps it consistent. Ideally only using it for lists of entities that remain static like a tilemap.
Recently I've been exploring Bevy and rust game development and my learning has been so much better when I create docs for myself: https://taintedcoders.com/
I've been learning about Rust game development with some friends after being a long time Ruby developer and am looking for better ways of explaining the low level stuff to high level rubyists.
Other resources that go great with this guide:
Youtube video of Astrofox: https://www.youtube.com/watch?v=IbvuniqNPPw