Creatures

Lately been fixing artificial intelligence using data-driven building blocks. This is one of the areas that needs most work, because I had only basic moving for creatures in early versions. In fact I have disabled AI and creatures just sit there, waiting for the programmer to do something about them. I'm glad if I can fill all the missing information in about two weeks and then begin to write the executive AI routines that handle the vast archives of creature data.

Notes

I may have talked about this earlier, but I have special comments in the source code starting with word "note:". Those parts of source contain a problem I have left to solve later. There are now 74 notes. Most of them are hard to fix and today I pretty much fixed one of them, which involved adding stuff to Score class (which I was talking about in 2008 blog entry). Fixing "note:" problems is as important as anything else in the source code, but they have been difficult to handle, because of generic difficulty or that something is still missing, like serialization which I now can handle, thanks to important experience from Teemu's serialization.

Containers

It's almost month from last entry. I really feel I have now control over containers and there is not much to do with them anymore. Writing container code is hard, because of ownership issue which can be quite complicated in a large scale program. Well, actually it doesn't have to be complicated. I made the usual mistake with container class and tried to give it to too much responsibility. It's easy to think that giving class more functionality will make things easier, but it's not always the fact. It will work only if the class will  handle things that belong to it. Then it doesn't matter how simple or complex the class is.

The annual 7DRL madness is going on, but I have my own battle with Kaduria. They can lose the battle and retreat, but I have to push onward to victory.

Restoring the gameplay

I had a creativity boost when my internet connection was down couple of days. The development is shifting away from engine programming to gameplay programming. I'm restoring and re-inventing the basic gameplay functions like digging tunnels, eating food, harvesting crops and things like that. The engine is in good enough condition so I'm not that afraid to add functions that could be written in more generic way. I'm really tired of trying to create a perfect engine.

I guess it's fun to see that you can finally do things in the game and see what happens, and fix possible problems. There is still a lot of things to do in that area, but it feels like whatever I'm doing now really can be detected in the game as real playable content. In a way the development of Kaduria has just started. I would add a smiley here.

Class as type

Class as type was something I discovered only recently. It's a simple but effective thingy which is based on heavy use of public interface. The data is hidden under the public interface and the other good thing is that the code related to that type is made modular and data-driven. I guess this is not news for people, but then again C-style procedural programming is popular in roguelike scene. When I was programming in C I had no idea you could do things this way. It requires more source code and sometimes the public interface can grow to a jungle of getters, but in this case I don't think it's a problem. In type style class getters are something that belongs to the deal, because it's a decoration for acquiring data in simple form. There could be functions that take more complex objects and operate them using the data of the type, but I like to avoid that since it creates links to other source files and classes. When there is no links the type can be used anywhere, especially without the host class where it is used as a component.

 This example is one that has quite lot of getters, but it's manageable. I'm guessing this could be what real programmers call a pattern, but I don't know which one of them it is.

Gui troubles

One of the problems in Gui is how to prevent updates on certain part of the screen more than once during movement. This thing has given me more work than expected. Some games solve this by updating always everything, but I think in somewhat heavy graphical roguelike it's not a good option. I got great speed up results in gameview code when updating only those tiles that were changed.

When creating a class for stats I decided to move some Gui routines and data there. I'm getting a double update from one of the stats (food counter). The reason is in the logic of update. If a stat is changed it's updated, but since it can change in fractions (all stats are float values) every change is counted and redrawn. I have an idea how to fix that, but I really wish I could so something else than work with Gui. You would expect it to be ready by now.

Liquid model

Since alchemy is going to be an important thing in Kaduria's gameplay I decided to model liquids instead of having a list of potions. It's more sophisticated, because liquids can exist in various places like bigger containers (cauldron) and possible mixing could be handled easier when X amount of liquid exists in place/object Y.