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.
Wednesday, 25 June 2014
Saturday, 14 June 2014
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.).
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.).
Wednesday, 11 June 2014
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).
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).
Saturday, 7 June 2014
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.
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.
Saturday, 31 May 2014
Bug hunting
Kaduria has 7 known bugs. It's not much, but some bugs can be annoying. This time I was fixing a bug that crashed when you threw more than one item on top of another. At first I thought it was a bug in stacking routine. Stacking sets a number to item's data, making it appear as "7 apples" etc. The good thing about this style is that items take less space, since 120 arrows is just one item.
Of course, the bug was not in that routine. I started to doubt it when the crash happened in the dynamic light map routine. It's checking items with light value, then displaying the light. Dynamic map makes it possible to throw a torch and see the light area in real time.
When the item is added to level there is a check for stacking. If suitable item is found, the original item is destroyed. As you can already guess, the original item handle was still in the item map, from where dynamic lighting is finding the handle... why it was there? I've found out that it's easier to actually change the item map when the item is flying, rather than use "a sprite" to represent the flying item. But the original map has to be restored after the item and the most important part is what happens when the item lands. Fixing the bug required two lines of code: set the item location to landing and update the item map.
The way stacking is done may be wrong, because each item has condition (physical, very exact). So any small damage to the item makes it incompatible with other, similar items. It may be possible that I have to reprogram stacking completely and use individual items which then are only displayed as a stack in the inventory and elsewhere.
Of course, the bug was not in that routine. I started to doubt it when the crash happened in the dynamic light map routine. It's checking items with light value, then displaying the light. Dynamic map makes it possible to throw a torch and see the light area in real time.
When the item is added to level there is a check for stacking. If suitable item is found, the original item is destroyed. As you can already guess, the original item handle was still in the item map, from where dynamic lighting is finding the handle... why it was there? I've found out that it's easier to actually change the item map when the item is flying, rather than use "a sprite" to represent the flying item. But the original map has to be restored after the item and the most important part is what happens when the item lands. Fixing the bug required two lines of code: set the item location to landing and update the item map.
The way stacking is done may be wrong, because each item has condition (physical, very exact). So any small damage to the item makes it incompatible with other, similar items. It may be possible that I have to reprogram stacking completely and use individual items which then are only displayed as a stack in the inventory and elsewhere.
Thursday, 29 May 2014
Does editor font have to be monospace?
The answer is no. And as usual I learned this after 20 years of programming. Although in the first years most editors were text based so the only font type was monospace font. I've changed my editor font to Franklin Gothic Demi Cond and just look at it:
It's much better than monospace font. Monospace may be required in some languages but in C++ it doesn't matter, because tab spacing has no real meaning. Besides as you can see tabs wont disappear.
I think (and many others also do) monospace fonts are less readable than regular (proportional) fonts. Selecting more readable font is important, because it also increases the readablity of the source code.
I think (and many others also do) monospace fonts are less readable than regular (proportional) fonts. Selecting more readable font is important, because it also increases the readablity of the source code.
Sunday, 25 May 2014
Lights out
I wish I had more exciting news, but today I'm planning to remove light items from tools, because it's possible to put light items in tool and light slots, "double use" them. Usable items will also have a dedicated use command to use the item in the tool slot. It could be also nice to have a key for light slot to put off light fast if you need to hide in darkness. More direct keyboard commands is merrier.
There's been more than month's break in development of Kaduria. Not unheard of, but it reflects the problems I have in my so called real life. It's bad enough to have a poor quality of life, but it's even worse to be aware of it. That awareness sucks the most I guess. So what to do? I have plans... but if they work as well as the plan of Kaduria, we might have to wait for some time before anything happens.
There's been more than month's break in development of Kaduria. Not unheard of, but it reflects the problems I have in my so called real life. It's bad enough to have a poor quality of life, but it's even worse to be aware of it. That awareness sucks the most I guess. So what to do? I have plans... but if they work as well as the plan of Kaduria, we might have to wait for some time before anything happens.
Subscribe to:
Posts (Atom)