William Bundy
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
William Bundy
I'm very excited that my project has (finally) made it on to Handmade Network! Rituals kind of started on stream, subbing for the Handmade Dev show, so to have it on handmade.network feels natural.

At this point, the game itself is very much in development, with almost no gameplay to speak of. The plan is to build a game much like a procedurally-generated The Legend of Zelda, but with survival and production/automation aspects to vary and expand gameplay while giving longevity to individual sessions. I don't like discussing design specifics yet because much of the game's planned design is likely to change as development continues. Too, I don't like trying to provide a complete roadmap because immediate decisions influence subsequent ones; however, I can say for sure the finished project will feature at least these things:

- Extensive procedural generation
- Gameplay (as described above)
- Robust modding support
- Some metaprogramming and scripting features

I'm sure I'll elaborate on all of these in future blog posts as time goes on (or, when I get to working on them).

The game is free and open source, currently under the MIT license. I'm not entirely sure whether that's the correctly license to go with; I'd like people to be able to use code from the project freely, without adding a license file (something you're supposed to do with MIT), while still protecting the project as a whole. It might be "correct" to license the engine parts of the game under something lighter (wtfpl? zlib?) and the game components under something more restrictive (LGPL?), while the art and other non-source goes under a third license, probably a Creative Commons one? I'll probably never run into problems, and I'll likely spin off some of the more useful code into stb-style libraries anyway, but I think it's worth thinking about. In the end though: almost all of the code in the game will be visible and usable by others.

As the source code for the game is available, it's easy to build it yourself. The latest source comes with the required libraries on Windows, so all you have to do is double click on the make.bat file (if you have Visual Studio 2015 installed.) There's a makefile that works on Linux (and on macOS if you add -framework opengl to the compiler options) too. If it makes sense to, I'll create and upload a Windows build weekly, too.

If it wasn't clear from the second sentence, I stream the development of Rituals at my twitch channel. I'm not dedicated to writing all the code on stream (and I don't think twitch has saved any of the archived ones), but I largely save the "big things" for the stream, if possible. My schedule isn't very consistent (there are weeks when I'm not awake at my streaming time, which makes it difficult), but my goal is 2PM Pacific (9PM UTC), every day except Monday. Rituals isn't designed to be an educational project, but I try to write simple code and explain what I'm doing for the audience. At some point, I plan on doing a complete code review of the game, where I go through how everything works on video, doing demonstrations of (to the best of my memory) what it took to get to that point.

If you'd like to watch the development of Rituals live, please consider following the channel.

This project is supported through my Patreon (or, I just added a PayPal donation button). I have a couple goals listed: a YouTube channel and a dedicated website. It'd be really cool to make those, so if you like the project, please consider becoming a patron!

Thanks for reading!
--William Bundy