Tile class - part 4

Dungeon (World) class is now cleared from game object maps. Yes, they were there, because object maps are just 'temp' pointers to the object, which are owned by the Level class in a linked list container. The map could also own these objects, but it would need dramatic changes in the way true object handles (vs. generic base class handle) are stored.

At that point I was able to run the game, but it wasn't very pretty to look at. Terrain tiles were missing, because Level::Show is now in Tile_Map class and terrain isn't there yet. The game also crashed a lot which is funny, because the usual code is rock solid. I believe it will sort out itself when everything is moved to their proper locations.

Terrain and masks are the big refactoring thing I'm now programming. It's more tedious than difficult, but some constructions are very different than before. Yet as I thought functions of Tile are shorter and easier to read as source code, because they don't require external gets from different map layers.

Tile class - part 3

The easy stuff like FOV and automap are now in Tile_Map class. There is a class hierarchy confusion with Tile and Tile_Map, because in Tile_Map class sometimes there are simple getters that return Tile information from (x, y) location. It's not always pretty as it happens to be with getters, but I now know better not to spend time trying to create a perfect class hierarchy.

I think the tricky part will be lighting routines, because I'm planning to rewrite them. What I need is a nice line-of-sight routine for lights and a math implementation to light areas. Both can be difficult, at least for a programmer like me. I think I'm not going to use the main FOV routine for lights, but who knows, it may be easy to change it to work with lights. I've been thinking about the wall problem. It's a "bug" where a light source can lit wall from the other side (as if coming through the wall), because walls are usually 1 tile wide. I have some kind of idea how to fix it, but it's too early to tell if it works.

The biggest part will be terrain map routines. I'm trying to avoid Tile_Map becoming a kind of Level class itself and put only low level creation routines in it (things like shape primitives, rooms, etc.).

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

Tile class

Today I was thinking about possibility to create a Tile class. The way it's now done is separate map instances for things like terrain, masks and game objects. When I started Kaduria it was a solution like anything else, but it has been difficult to manage maps since then. A combined Tile class would take lot of source code from Level class and place it in a smaller, more manageable class.

The bad thing about this is not a surprise: it's a big refactoring task. Is it really needed or should I just go with the current system? Maybe I should try to estimate the amount of work needed. It's maybe possible if you look at the calls to map handles, how and where they are used.