Level class

Returned to Level class. I have switched between big classes and browsed through them, fixing everything in sight. Level class is possibly the worst of them, because the dungeon generator still has some problems. It can't generate all level themes yet, but I'm working on it.

In some parts I have made a decision to settle for less great stuff to speed up development. Maybe I'm really looking forward to create a playable version, no matter what features it could be missing. Still, I'm pretty sure that the first playable version is not going to be a release version.

Item class part two

My tennis elbow got better really fast, it was just some kind of episode. It's still there, but not painful. Item class is almost ready for the parts that are already there. Something tells me there is going to be more code for items, but it looks surprisingly good now. I have lost my obsession to create "perfect" code (or engine) and just try to get stuff work. Well it isn't a surprise that things start to happen. However I'm as puzzled as ever when I think when or how this project is going to become a real game.

Item review

Giving Item class the same kind of check than Level and some others it was quickly obvious that it needs serious fixing. Many problems come from the unfinished role-playing system. It's really slowing down everything, because you can't write a routine if you don't know what it requires. But like with previous classes I have learned to look at the source code more closely and make better decisions.

Level class refactoring

Last three days have been quite productive. I have searched through Level class which is 3500+ lines of code. Many routines need either fixing or test how they actually work in the gameplay. I think the worst example was a routine searching for free places (when game objects are spawned). It doesn't work like it should, but when I change it data-driven it should fix most of the problems. I've also learned that everything should be check only once, because you will have extra rules and if that another routine doesn't check them it fails. There must be something like that because sometimes there are plants created on walls. It's bit of a mess, but it's going to get better soon.

Solutions

Going through Level class and closing functions when they look like they're ready. I think this is pretty good way to proceed especially when you get lost in the jungle of source code. The basic idea is find problems and try to find a solution for them even faster. When you program longer you start to understand what are the things that slow down development. I think there are only two things: 1) you did not find a solution for a problem and left the function/class unfinished and 2) bugs.

If it only were easy to fix all problems when you see them. But usually they are related to something else that needs to be done before you can continue. This is the difficulty in roguelike programming. With regular games you pretty much know what you need to add to make the game work like it should. With roguelikes you run into huge problems like artificial intelligence and the myriad of ways to interact with the game world. I hope my new style of programming brings some quick solutions.

Fighting style

There are some things missing in the process of constructing/creating a monster. Artificial intelligence type or AI type was quite easy to add. It was determined from the monster family and/or type of the monster. It's later used to make decisions about how the creature will act in certain situations.

Skills and default items are still missing. Some skills can be determined from the profession, but default item set is a problem. You could determine them from the profession and type of the monster, but instead of that I was thinking to add a new AI module fighting style. That way let's say a human fighter could have several styles with weapons and armour selected for that particular style. Not only items, but you can then determine combat strategy and also some additional starting skills from the style. Besides you need less fighting styles than there are professions and monster types.

Fighting styles need random variation in weapons and armour to prevent static item sets. It's going to be a complex system which is only telling how even one small area of roguelike is incredibly difficult to program. There is no easy way to do this, you need to create a number of styles with proper items, but still maintain random variation.

Monster review part two

After some research I found out that only 40 of 134 functions in Monster class are ok (possibly don't need refactoring). The rest is in less good condition. I have hidden ok functions with VC's gui so it's easier to get work done in unfinished functions. I can only guess that it's a difficult task, but this situation with unfinished code and gameplay content has been going on for too long. Something has to be done and I got a good start by fixing some functions. The following days will tell more about how fast or slow I'm able to fix things.