June 2025

This month started off strong with something else than graphics for once, which is nice since you feel the actual game aspect is progressing.

To make debugging a bit easier, I dusted off some old line drawer code I had laying around. It was fairly straightforward with the exception of a mix-up in the viewport dimensions which was a bit painful to debug.

Then I went straight into the rabbit hole of physics. I setup colliders for my voxels (badly illustrated above), and even started implementing dynamics with a solver and all. However, despite the fun in implementing a full physics engine I hit the breaks knowing I might not even need it. So I just implemented some simple shape casts against the terrain so that I can implement character controllers and such.

This of course came with its own set of off-by-1 (2?) bugs.

With the colliders in place it wasn’t that difficult to implement a raycaster either. I found a fun bug during this, my screen was offset by a few pixels thanks to a missed swapchain resize. Ironically this code section was marked with a TODO so I took some time fixing some other TODOs as well.

Now we have to tools to actually implement some interaction with terrain. Just coloring existing voxels was simple enough.

Digging (removing voxels) as well.

Building was a bit tricker, not only because I’m a terrible artist… But as I’ve opted for storing my voxels in a tree, I had to deal with dynamically expanding the tree as we add more voxels. This far I’ve adopted a 64-tree (4x4x4 children per node), and it has served me well. Editing isn’t that bad for just adding a few voxels here and there, but I have some logic for generating only voxels you actually see that got a too complicated for my liking.

This lead me back to the sky of mistakes again. I started investigating other approaches for storing and rendering voxels. Another popular approach for storing voxels is a brickmap, which would simplify editing. On paper brickmaps consumes more memory though so I started experimenting to see what the trade-offs actually are. I’m happy to lose a bit of my memory budget if it means I can simplify editing. On the topic I also found this great reading with accompanying benchmarks which further motivated me to actually re-think my structure.

I’m still experimenting and there’s a lot of back and forth between memory consumption, rendering performance, and code complexity. For now I’m still not sure what my game is supposed to be so I aim to keep code simple, allowing some flexibility in the future. Hopefully we get back to pretty pictures next month!