# Automapping, Walking

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

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.

### How it Works

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.

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.

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.

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.

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

### The second part: UI, Savegame, and more!

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.

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.

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

"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.

"." means "passable".

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++.

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.

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.

### Gameplay Control

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.

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.

### Problems

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

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