Clean-up (x2)

The level generation is working again mostly. Some new bugs, but nothing major. Both FOV and light map routines are off for now until I have the energy to concentrate on them. Maybe it's best this way, I can directly see the topology of the level when creating level themes.

There are more important things to do anyway. Next task is mainly go through level themes and add more things, starting from basic topology and then moving on game object distribution. There is a "trick" involved in the process, an idea I had while working on the new version of Teemu. It's of course a secret.

I guess it's these warm days, but I was upset when I noticed that save game routines for each game object type has to be refactored. Most of them were easy to convert, but couple of them needs more work. When I get upset it sometimes makes me clean up places. It's a woman-like way to react, but who cares.

Tile class - part 6

It took almost two months to refactor multiple maps to a single one. But it's not over yet...

It's annoying that I made mistakes even I should have known better. The bounds check is less reliable now, because it's not built-in like it was before. I don't know what was I thinking. I guess it can be fixed for at least those getters that return a class type, because returning -1 is dumb. It could be possible to create a type for a tile outside level borders that acts like any regular type, but the way that you can't reach or use.

FOV is not working properly. There was a coordinate translation change so it maybe has something to do with that.

The next task is a clean-up to fix bugs.

Tile class - part 5

Mask maps are now mostly included in the Tile class. While refactoring terrain map I realized that Gameview class has to be refactored. It's a class that draws the final 17x17 tiles on screen. Previously it had both static and dynamic light maps copied into a special 35x35 buffer which includes nearby light sources still visible from that 17x17 view.

However I found out that there is no need to copy the light information to the gameview, or anything else, because Tile class can include them. Even dynamic light values can be stored in Tile and recalculated on a specific area around the player to show only light sources that can be visible to the player.

The original Gameview was a result of copying FOV data and then determining how tiles and light would be displayed, but FOV was moved away from Gameview even before I started this refactoring and I didn't figure out how much there was unneccessary copying until now. Another great thing is that the new code will completely remove difficult coordinate transformations. Also, tile graphics are now stored in Gameview which is a wrong place, because they belong to GUI class. Gameview wont become completely useless, because it still has the update map which speeds up displaying of tiles by remembering empty tiles from previous turn and not drawing them at all.

Even now the gameview routine is fast, but it's going to be really fast after this refactoring. Well, I'm going to need that speed to include lights that have FOV routine in them. At the moment lights are just simple spots that don't know anything about walls or other obstacles.

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.