Tile class - part 2

The refactoring from separate maps to a single map class with Tile class atomic has started. The bad news is that it can't be done quietly, so for a moment it's not possible to run the game. I'm not concerned about it however, because the refactoring "simply" consist of moving operations from maps to a map.

I've started from fov map and right away it was interesting to see how this refactoring is changing things. In the old system you get fov value from the fov map and then use it in the fov tracing routine. With Tile class you don't have to Get(x, y) from a map, instead the check is made in the Tile class itself which doesn't have location info. The tile doesn't know where it's located, but it of course knows everything on that tile, so fov check can be done simply by checking if the tile is blocking the fov (either by a terrain tile or some game objects). It makes some routines extremely simple compared to the old style.

Even better when Tile is the atomic of the map, it can hold any type of objects. Old maps were two types: int (or rather unsigned char) and game object type. I didn't want to write a template style map, that stuff is always so confusing. But now I can use type classes in the Tile for things like terrain tile. It's then easier to use verbose routines of type classes without first converting int map data to a specific type.

I think even now at the beginning of the refactoring it was a good idea to do this. As always this came a little too late, but I don't want to blame myself. It's possible to work with separate maps, but it starts to get complex when there are more than ten layers of maps. I also think that with Tile class it's easier to add new layers. It's the reason I started to think this refactoring, because I want to add at least two more layers (humidity and temperature maps).