Marking the first week Rituals has been on HMN (...a day late since it's taken me so long to write), I'd like to start this series to record what I've worked on and track how much I've streamed (approx 11h30m this week). From last Tuesday, I've added a basic spacial partitioning and a simple animation system, while working on particle effects and tweaks to entity rendering.

Funnily enough, these all end up being interrelated, but I'll go through them one-by-one, anyway.

Spacial Partitioning is the general term for what I've added in the form of a grid. It's a fixed size array of singly-linked lists of static bodies. This is probably the simplest kind of grid you can implement, and while I'm certainly looking at other options (hierarchical hashed grids, quadtrees, k-d trees), it isn't vastly inefficient for the current terrain I have. (Right now the generator throws out a largely uniform random pattern, so I'm not losing too much efficiency to empty cells in the dense array.) When working on the game, I've found a few times that I've wanted a way to find bodies close to a point, and the array-based sweep-and-prune method I'm using doesn't let you do that without sorting some number of query AABBs into the array of bodies. That seemed bad, if not egregiously awful performance-wise (though, I didn't test), and would have been a headache to work with, so, when I decided particles needed should collide with terrain, I put this together. It's already made it possible to quadruple the size of maps by removing around half the area's bodies from the sweep-and-prune phase (and my physics code still has a lot of room for improvement), and will probably be useful elsewhere in the future.

As I mentioned in the last paragraph, the motivation for adding a grid was my inclusion of in-world particle effects, which I initially worked on off-stream. While we're talking about code with room for improvement, this certainly needs some before it'll really be usable game-wide. On-stream I wrote a Particle_Style struct, which exposes all the values hard-coded in the initial version, and it's a huge pain to use. Someone in chat mentioned writing a particle editor, which I'm not entirely sure I want or need, but would imply that particle styles are something stored globally and accessed at particle emission, which might remedy the code clutter that either making a new particle style inline or copying one and modifying tens of fields generates. I actually don't know much about how bigger engines handle particles, (beyond the Team Fortress 2 developer commentary) and it'll certainly be interesting to see how Casey implements them in Handmade Hero, but I've gone ahead with this straightforward implementation, and performance seems fine so far.

Particles in Rituals exist in 3D space, as I wanted them to bounce off the ground. After getting it working I realized that it wouldn't be too hard to move all my in-world graphics into 3D, considering the Zelda-style orthographic view (for those who don't know, v3(x, y, z) becomes v2(x, y - z)). While I haven't gotten that far yet, I have added a z-coordinate and shadows to entities, which together give a better illusion of 3D than before. I keep asking myself how far I should go with 3D-ness, but I generally come back to "No, it adds too many headaches for not enough gained." The Legend of Zelda: A Link to the Past has multiple layers of floors which you can jump between, but the later Gameboy titles don't feature them; it seems that cliffs and ledges in Link's Awakening and the Oracles are simply solid blocks with specific sides you can jump over. Stairs simply move you up on the screen. I plan on Rituals having mutable terrain, so pushing towards real 3D would mean straying closer to re-implementing Minecraft (or OBBG or YAVE), which seems out of scope for this project.

The other part of the tweaks to entities comes with the animation system I added on Sunday. Combined with adding support for flipping sprites in the vertex shader and automatically setting the entity's facing to either left or right based on how it's walking, I've eliminated the old player-only animation code. While the abomination that replaces the old walking animation is just that, the code behind it certainly easier to understand and modify. The system is split up into several types: Animated_Sprite (more on the problems with it after this), isn't really a sprite at all: it holds animations and tracks the frame and timer; Animation holds all the frames, the FPS and whether or not it loops; Animation_Frame holds almost all the information a Sprite holds, except with a Vec3 position. There are still a few problems, the biggest one is the addition of Animated_Sprite, which isn't really a sprite at all, it's more like an animation instance and dictionary (well, array), and its nature touches on something I was hinting at earlier: the state of the different sprite-like things is a mess. Entities shouldn't have a Sprite baked into them. Particle and Animation_Frame are almost the same thing. Animated_Sprite isn't.

Rituals is still quite a small project (~6000loc that I've written, HMH is around 18-20k), but I need to clean up basically everything if I'm to continue working on it (assuming I value my sanity). Obviously this is par for the course, but I feel like there are a few ways to go about it. Rather than rushing into ripping files apart and mass-renaming things, I'd like to write a header and introspection generator, which would make it much easier to move code around and clean up a few places in particular. Using the introspection data, generating serialization procedures would be possible too. Those aren't substitutes for moving and changing large amounts of code around, but it would make it easier. Tomorrow's stream will probably be some amount of taking inventory on things that need tweaking and changing (the TODO section needs rewriting, for sure), and after that I'll be playing around with a lexer (either mine, 4cpp/4c++, or stb_c_lexer) and seeing what I can do.

Anyway, I'm falling asleep as I write this. I've had a number of follows to my Twitter and Twitch, which is good! Hopefully as the project grows closer to being a "game" (or, maybe, only after a tipping point in features), more people will be interested in watching it develop.

If you'd like to watch the development of Rituals live, please consider following my channel. This project is supported through my Patreon.

Thanks for reading!
--William Bundy