In Profundis Progress 8/3

Still working on the world builder.  Here, I'll lay out the scheme I'm planning for the maps produced by the game, and what I'm aiming for concerning the overall metagame.  I am open to comments and suggestions here; I have a strong view of what the game should be about, but the specifics I'm still thinking about.

1. To start with, the game divides the world into <i>sectors</i>, which are 12x12 tile units.
2. Then the world runs a maze generation algorithm on those units to create a "true" maze, that is, one with no dead-ends.
3. It's not implemented yet, but eventually some more high-level processing will be done on this maze, to create loops providing alternate access to some areas, and also divide it into <i>regions</i>, each of which will have different generation properties, such as large block obstructions, seas with a specific type of fluid, narrow tunnels, etc.  Right now, I'm defining the <i>templates</i> for each type of region.
4. Once regions have been set, we change the sectors contained within each region to that region's template. Most of the templates are laid out in lists according to a 16-unit scheme, indexed by the bits connecting from that sector or'd together.  (Up=1, right=2, down=4, left=8.  Embarrassingly, confusion between two different bit schemes I was using in two different places caused a mysterious world creation bug it cost me a day in tracking down.)  Since each region type has the same kinds of templates laid out in the same order, it's a simple matter to drop them in as replacements.
5. Additionally, any sectors left out of a region can be randomly "tweaked," just changed to one of the possible templates matching its connections.
6. Once all of the templates are set and decided on, it's time to <i>render</i> them out to the game map.  Each space in each template has an integer value and (optionally) a code.  A random number in the range [-8,8] is generated for each space in each template, matching its location on the gamemap that added to that template.  The integer amount is added to each of the cells surrounding its corresponding location on a matrix <i>heightmap</i>, of the same size as the gamemap.  The result is, places that templates say should have walls spread out "wall influence" from their locations, and places that should have empty space spread out "space influence."  Wall influence is represented by positive numbers, and space influence by negative numbers.
I realize this is hard to picture.  I wrote a column on this algorithm for GameSetWatch some time back (scroll down to "room building").  As that column notes, the result looks like what happens if you apply a blur filter to a field of noise in a paint program.  Each random pixel is "spread out" across adjoining pixels.  The spreading-out actually introduces some order into the random field.
7. Finally, we go through each cell of the heightmap.  Cells that are 0 or less produce spaces in the corresponding cells of the game map, and cells that are positive produce walls.  That is, unless the template had a special code for that space; those codes can override the heightmap and produce "hard" spaces or walls, or other special tile types, or instead they can work with the heightmap and produce fluids or gases if the space is ordinarily empty.

One advantage offered by the gameplay (eventually) is that, since the player has equipment that can dig through stone, it isn't strictly necessary to ensure every sector of the maze turns out to be accessible through space, although neither is it particularly friendly if large sections of the maze are commonly locked off requiring a pick to access.