I've got two fairly-big programmerly issues ahead of me. One is automapping and the other is to clean up the walking code.

@p I think I would be smarter to tackle just one of the two for the next update. Since walking isn't as critical (although annoying) I will tackle the automapping.

I've got it fairly clearly figured out now. The automapping system will be of course area-based. It's not enough to just show what areas the player has been on, we also need to show some detail in those areas, for the player to recognize.

@p We will use a fill algorithm to determine the shape of the area the player has explored. Basically, what this means is that when the player has stepped on a square that is not yet automapped, we will try to fill it in similar to a floodfill tool in a paint program.

@p To generate the fill, we could do pathfinding; in theory this might seem OK, but I've a hunch that in practice it will produce maps that are too detailed. So instead we will use a simplified algorithm based on the player's altitude and the wall height.

@p When we fill, we just look for squares that aren't too high/low verus the "base altitude" (in this case, ground level). If they are above a certain altitude we'll stop filling.

@p This approach should produce fairly nice-looking automaps, which are representative of what the player has seen.

We need to integrate automap with the rest of the game (read: lua). In particular, automaps need to be stored to savegames and they need to be displayed.

@p To bridge this gap, we will represent automap data as a string of "?", "X" and "."; at least initially. The savegame will store the automap data for each area, and we can fairly easily introspect this data to determine when we might need to automap.

@p "?" means "unknown". If the player steps on an unknown square, we initiate an automap fill to add detail to the automap.

@p "X" means "wall". In the process of automapping, if the neighbour of a filled square is impassable, we mark it "X" so the player knows he/she can't pass through.

@p "." means "passable".

@p This data can be introspected relatively easily from a simple lua class we will make. This class might do the automap-filling itself but I think more likely this algorithm will be written in C++.

@p The data can also be passed to a user interface object that we'll generate as needed. This UI object will take such a string and produce a custom texture that it will use to render each block.

@p Of course, on the automap we aren't going to just show the 50x50 area the user is on; we'll show a few neighbouring areas, too.

The automap will be controlled via the player's watch, a starting inventory item. I realized that this was a nice natural fit; GPS-watches aren't exactly the most common thing (A vehicle GPS unit would make more sense) but there are GPS watches and such that runners use. It's not hard to imagine a modern day cowboy might have such a watch to use for trekking across the range, or something.

@p This will provide a simple interface for the user to turn the automap on or off (in case they don't want it onscreen) and maybe other features.

The biggest problem is that it's a fairly major system to implement. =) But, for an exploration game it just makes sense.

@p The second problem is how to handle areas like the castle where there is a main floor, and a top floor. For now, I'll not worry about it and only automap the main floor. It shouldn't be too hard to manually tag areas that need multi-level automaps and then switch between them as necessary, once the main system is in place.

2009-10-02

◀ Back