One Release a Month is a relaxed jam me and a few friends are doing in which the only goal is to release something each month. I'm working on quite a few different things at the moment - my HTML5 2D game library Hestia, an electron editor Hekate and my Unity ARPG Seekers - none of which are really suitable for a monthly release. So I've been spending around one weekend of each of the last two months dabbling with a voxel fort generator for 1RAM. It's more of a toy than a game, but I've enjoyed working on it and hopefully it's fun to mess around with.

Play Vorld: Fort Generator.

I started by re-using the code for meshing and rendering voxels from my Voxel Terrain Experiment, and then wrote a new generator which works by determining a footprint of a fort based on configured parameters and then builds it up level by level. I settled on an approach that's sometimes reminiscent of shader programming, where I specify a volume to iterate over and use predicate to choose what block type to put in. I like that with multiple passes you can first create the generate structure and then write another function which punches windows and doors into what you already put down.

Reusing my existing meshing code and voxel shaders really showed up the artifacts due to the mipmapping of the atlas, which causing tiles to bleed into each other, so I updated my renderer to use webgl2 and made use of texture arrays instead of an atlas. This treats each block texture as a separate texture when generating mipmaps and eliminated the bleeding issue. Unfortuantely I'm still having to use a quad per block face as the shader variation whichs uses world space to pick UVs gives the appearance of seams at the borders of the quads, which I'm not seeing when using the clamp property on textures using actual UVs, I'll need to look into this further if I want to start using a greedy meshing techique, but for now I think performance is acceptable.

Whilst May entry was the basics of the fort generator itself for June I exposed parameters to control lighting of the scene and also added fog to the shader. I never actually got around to implementing a lightning system for Fury which was my second attempt at a WebGL renderer, but the approach I took where my basic renderer was a wrapper for WebGL with some helpers and my scene manager was relatively straight forward meant that it was very easy to put in without really doing anything too hacky. Although it's certainly not optimal, as you set a flag on a material to make it as dirty and then the scene manager will rebind the uniforms for that shader, but it fill rebind all of them not just those that have changed.

To expose colours for tweaking I used HTML5 color input type, which I'd not used before, I like that because it's built into the browser it'll present a different interface on mobile devices compared to desktop but I'm not hugely fond of the desktop implementation. You have to close the popup color picker window to set the input to the value you've selected rather than having the option of confirm or cancel, which I think is quite a poor UX choice. Alternatively, if you're going to stuck with your changes with no way to revert, it would be nice to have the option for the input change event to be triggered as you change the value in the picker and not just on confirm. So I'm a little tempted to write my own color picker control, although I might better off using the WASM port of dear IMGUI in WebGL instead.

There's quite a few extensions to this experiment that I'd like to have a go at: usable touch controls, custom footprints for your fort, adapting the generation to cope with a height map for the ground (rather than a plane), creating presets for lighting, more block types for increased detail. The list goes on, so I may well continue to iterate on this for my 1RAM entries and whilst spending most of my personal dev time on my other projects.