In Profundis Progress 8/29: The map!

We have maps now!

This is a large image; the above is just a thumbnail.  It's not the complete map; it's one part of it, roughly two-thirds the whole thing I think.  This should give you some idea of the scale of the game.  It's so large that I'm actually starting to think that maybe multiple worlds in a single game is overkill; there is a lot of room in this map to hide things, and it wouldn't feel arbitrarily limited to not go on to a new planet after searching an area this large.  In fact, it might grow tedious if, in a single game, players had to explore many maps this big.  By this way of thinking, each game would be a single world, with a single map.

This isn't giving away any secrets because, of course, the world is randomly generated each play.  Note there are no liquids in the above map because they currently aren't being generated in world generation; putting those in is on the list of the next things to do.  Still lots of work to do of course, but figured I'd give you guys an idea of how things were progressing.

This also shows the different types of stone in the game, which serve the important functions of giving players another thing to learn about and giving different regions of the map their own visual identity.  Not pictured here is the updated character art, which I'm much happier with; it's kind of a mix between the previous art and the silhouette I used for Mayflight.

In Profundis Progress 8/21

I think I'm finally coming out of the woods regarding world generation.

DragonCon is in a week and a half.  What I would like is to make another prototype available to play around with before then.  It'll be difficult, but just barely possible I think.  We'll see anyway.  More before long I hope....

In Profundis Progress 8/17

Been a few days since the last post.  This stuff isn't really very interesting, but just to fill you in....

Still working on world generation.  The key now is setting up the materials, and the "personality" of each region, and getting the materials to generate properly in each region, and giving the materials their own properties that can affect the player and each other.  This is taking a long time; I seem to have a mental block concerning the algorithms necessary for the kind of random generation of properties needed here.  I'm making lists of substances, and lists of properties, and tying the properties to the substances, and lists of regions, and lists of substances in those regions, and deciding which substances should go in which region by depth and difficulty... and it's not something I can easily hold all in my head at once.  In other words, I'm having organizational problems.  I think it's time to sit down and just plot this part out, then implement that from off the paper.

In Profundis Progress 8/11

Gah.  World generation work continues, although haltingly.  I had a couple more annoying bugs.  I seem to remember programming being easier than this.  I continue to forge ahead.

The feature I just added, and took me so long, is world regions.  That is to say, each world won't be a homogenous area of similar terrain, but will be "themed."  This allows the game to tweak area creation by contiguous areas of the map in an intelligent way.

Man, when I see Tarn Adams chugging away, adding new features daily, I get intensely jealous.

In Profundis Progress 8/7

It's still rolling along.  Here I'm going to detail some of the finer steps in the world creation algorithm I'm working on.

The steps (partly restated from last time):

1. Define random material properties.
2. Make an array of sectors (each representing a 12x12 area of world tiles).
3. Build a maze in that array, with each element holding which adjacent elements it's connected with in bitfields.
4. Perform processing on that maze (this is what this post is actually about -- see below).
5. Take maze, indexed into heightmap influence templates, and apply that to an array matching the size of the world.  (This is what I talked about last time.)
6. Turn heightmap into wall cells in game world array.  Along the way, apply any special codes in the templates that produce special features - <i>ignoring liquids</i>.  (This part is new.  I'll have more to say about it later.)
7. Perform "flow experiments" to find good liquid flow paths through the world and create "wormholes" (actually, grates) that moves liquids from lower to higher points.  I'm handling this process by putting in some simulated liquid into the world and running some turns to see what it does, then cleaning up the liquid afterwards.
8. Apply the liquids skipped back in step 5.
9. Later processing, tile smoothing, sediment laying, etc.

Mazes are intrinsically interesting structures to explore, but have some problems, especially related to their use in random world generation.  A proper maze has only one way to get to any location in the maze, meaning if there is a difficulty in getting through a section, it makes it correspondingly more difficult to get to any location beyond that section.  By putting in more ways to get to a place, the gameplay experience is made more robust.  At the same time it actually simplifies navigation, due to the existence of tricks like the "left/right hand rule," a.k.a. the wall follower trick.  (More on maze solving algorithms at <a href="http://en.wikipedia.org/wiki/Maze_solving_algorithm">the Wikipedia page</a>.)

My idea is to put loops in the maze that allow the player to find ways around trouble spots.  (It's possible that the other ways have troublespots as well, but we're not trying to hand them the victory here.  They will have to sweat sometimes.)  I used a system like this in Mayflight, but I didn't care much about where the loops went.  This often meant the loops were trivial, like connecting two already-connected rooms.

I had already come up with a way to solve this problem many years ago however in an old Commodore program.  The solution is to make an intermediate pass and record each spots' minimum distance, traveling through the maze, from a random starting point.  Then look through the maze and find the adjacent spots with the greatest difference in distances from that point, and connect them.  To make additional loops it's then best to refigure distances, taking the new path into account, from a new random point.  The result (if memory serves) is a more satisfying maze to explore, with longer paths and more work to do to find alternate access routes.

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.