Bridge algorithm in action

The bridge searching algorithm is good when the river width is one tile. This happens when the river is wide:



Not clever. I have to improve the algorithm, but it can be difficult to determine where bridges should cross the river. One good indicator could be the corridor mask, because sometimes corridors cross the river. That's a good place to build a bridge.

The map madness is almost over. Search for terrain_map references results only 140 hits, with most being already inside Level class so I think it's really possible to make the terrain_map an internal part of Level rather than a global instance.

Dungeon generation: data-driven or linear?

I'm back in developing some content to Kaduria, namely dungeon generation. Kaduria is quite heavily data-driven, but I think it has two downsides: 1. it's harder to create an engine to process the data and 2. it's more vulnerable to changes. There can be sudden special cases that can require a change in the engine which then is reflected to the entire game world creation. This actually happened to me when I changed the ground objects to become "real" objects of the game object class hierarchy.

In Teemu I'm using "linear" dungeon generation in which level themes are created with separate functions like Create_Island(); and those functions are modular so changing one will not be reflected to other functions and there are only few data-driven functions (such as creating random creatures and items). The downside of linear approach is that you need more source code to generate different level themes, depending on the complexity of the level. It's more work and maintaining to produce the game content.

I think special cases are not bad if you can control them. It's not always good thing to add functionality of the special case in the engine just because you want to make a "perfect" engine. It can be a waste of time and also a potential hazard to the engine itself.

Refactoring Score class

While looking at the old source code of Score class I was wondering what made the change? About two years ago I really didn't have a clear idea in programming. I was doing something, but it was slow and like walking in the dark. Now I know how to proceed and it's just the matter of spending time to make it. I still don't know what made the change possible, but I guess it has something to do with the spare time I had in work.

I was programming Stile then, but it's not what I would call good OOP source code. Maybe I was getting there while programming it. The bad thing is that I really lost years, but maybe that was the time I needed to become a better programmer, because I learned slow. Sometimes things don't happen fast and we all have limited resources and intelligence which we have to fight against.

Gameview bugs

Maps other than terrain_map are now members of Level. When I finally re-compiled and started the game it didn't work. I could see my character and ground objects (stairs and a sign) but nothing else. Automap isn't working either. I guess it's just a matter of small changes. Level.cpp is now over 2000 lines and it's the biggest file in the project.

Mask map access

There are two mask maps used in creation stage of the level. Regular mask map and room mask id, which stores the room id for each tile. They are accessed through various creation routines such as corridor and cavern classes, which are not part of the Level. I think I can still make it somewhat clean if I just make a routine for Level to write mask maps, like current_level->Put_Mask_Map(x, y, value). Terrain map access is going to be similar, while at the moment terrain can be changed everywhere.

In theory things like corridor, cavern and even room creation could be inside Level class as regular routines, but I think that would make the Level class quite big and overloaded with function names. I'm somewhat worried with current_level-> which is going to have more references, but on the other hand I can really concentrate on Level routines and possibly even reduce the amount of functions, which actually has happened already. In large project like this it's even possible to write a function which makes something very similar than another function. This has been the case in Kaduria, mostly because of the missing structure of the class hierarchy.

Maps in Level

Maps are not yet member of Level, but they will be. They were exposed to global visibility and that may give me a whole lot of errors, although I guess terrain_map is less of a problem, because it's already accessed mainly in member functions of Level. There is a global pointer to current level, called current_level. I think I'm going to keep that, because making it a member of World (or Dungeon class in this case) would cause more pain than needed. It's fairly safe to use global pointer for Level class, because there is only one current level at a time.

I first planned to fuse all Level class files together, but that's actually not neccessary and would create one huge cpp file. The current Level main file (level.cpp) already takes a couple of seconds to compile. I think it's slow to compile mainly because of three or four game object class templates. Templates are something I'd like to avoid in C++, but sometimes it's not possible.

New Automap

38 or something errors left, but it's going to go up again once I move maps inside Level class. Automap class is now only a gui type class with location and size, automap tiles, drawing them and update. Level class has now 1400+ lines of code but it's going to grow a lot. Teemu's Level class has 1800+ lines, but I think mainly because it's pretty linear programming. Kaduria has much more low level systems and engine-style code reducing the amount of code in high level classes such as Level.

I really hope this is the last time I'm rewriting the code. It should be, because the result of modular programming is just rock solid. I haven't heard of any bugs in Teemu and haven't found one when playing it. Creating good base classes that simply don't fail is the key to producing that kind of code.

Gameview cleaned

Gameview class is now almost cleaned. It left 184 errors to fix, mainly because access to maps. I had to remove the old line-of-sight code, planning to replace that with new one. Gameview is now holding the dynamic light map and it's going to contain the los map, too. Gameview is just one example of the gui system that should be detached from the actual data of levels.

Map madness

Restarted Kaduria's blog to keep Rogue Hut clean from this poop. Re-writing maps is becoming more difficult, because of the relationship between Gameview (the routine showing the game world's view) and Level (class that contains maps). Some copying is probably needed, but it's making drawing slower. I don't know if this careful approach is premature optimization, but feels like something I must do.

Gameview is a problem, because I'm having difficulties to visualize the small "window" to the map. It maybe sounds funny, but that's how it is. Previously I nailed this problem just by declaring all maps the same size and then doing final drawing from the level size map to 17x17 tile size view. Maybe the reason for this problem is that it involves coordination transformations. I hate them really and I hate math in all forms.