Moving objects

There was a bug that was funny for a moment. One of the object types is a movable or mob (moveable object). These are barrels, chests and other big objects you can push, but not pick up. Somehow all of them were moving randomly around. That was a bit hilarious and I was just chasing them for a while. Everything seemed to work well, you could push them like always, they didn't just want to stay in one place. The reason was that when the movable is on water it's floating and moving randomly, but in this case the moving routine was called every turn no matter where the objects were.

This bug could be made a spell, some kind of chaos spell that animates objects to move around and cause confusion among mundanes.

Game object base class forming

It's getting better when I go through the functions and try to figure out them. There are two main areas where improvement is needed. First and most important one are the functions that are interacting with the game world (terrain). Second one is everything related to strings (object names). Then there are some problems with virtual functions. It's a good invention, but can cause all kinds of bad side effects when the class hierarchy is poor.

I'm actually pretty satisfied with the development I made today. There is still time left today to make more adjustments to object base class. It's important to get that working, then I can concentrate to specific game object types.

Room interiors revisited

Back some time I wanted to detach room interiors from Room class, because I thought Room class was becoming too big. I was afraid of big classes, but now I have to fix that by merging interior creation back to Room class. I also had an idea to create room interiors in large multi-room houses, but now I realize I could just create multiple rooms with each having their room interior and connect those rooms to create houses.

I'm actually fixing terrain_map references, but this is a part of it, because room interiors (and rooms) use lots of creation stuff. This time I'm avoiding direct calls to Level's creation routines and use a member for Room which then calls Level's routine. It's one way to emphasize modularity and make future modifications to the source code easier.

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.