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.

Body parts

Today I started to design the body part system. Until now I had only body part enums, but no other code or plan for them. I'm using same kind of modular class/type for body parts as for many other game object sub-systems. The problem with body parts is the fact that not all creature types have same kind of parts, but I believe with careful planning it's possible to create a flexible system which doesn't need a lot of special-case code spread everywhere.

I plan to restrict the use of body parts mainly in situations where a certain type of damage is subjected to a body part. I think usually body part system is too detailed, but in this case it somehow seems to match the armour system where each body part can be worn. Later it could be possible to direct the attacks of creatures by the size or other special ability of the creature.

I really like to work with restricted type-style classes. It's possible to do game design in that level also and you don't have to worry so much about interactions with other types of data.

Task structure

Figuring out how to do npc and player tasks can be difficult, at least without very good plan. Data-driven approach is good in this case too, but guess who didn't organize that earlier. It's important trying to do low level functions for tasks that both player and non-players can use without extensive use of special case coding (usually checking out if the creature is player).

The important layer of data that I still am missing is the task structure: the list of commands and which ones can be executed by non-players. It's not good if you go straight from keyboard Get() into a command subroutine. You can't do that in large scale game. There must be series of stages to go through before that.

I need some planning before looking at the source code. Need to list all commands and try to figure out what those commands have in common, then create the data structure.

Easy

The re-write of map code must have been the fastest one I've done. It's basically ready, only thing left is terrain map changes (only terrain map will have creation routines). The object map was really easy, I copied the source code from Teemu's object map and had to make only minor changes at the point of map drawing (get object's frame instead of static id). It's really cool to run the game and see objects that were missing when all maps didn't yet work. I think the main reason for easy re-write was OOP style source code. It's making changes so much easier to do. I have even noticed that I can make gradual changes and nothing really breaks. It's great.

Map issue

While the development is shifting from technical problems to content creation there is still plenty of things to do. One of them is maps, where in once again I notice I have been wrong. The current problem is that I have a map for objects that don't move (aka terrain objects). The map id is shared with all types of objects and it's basically duplicated data that has to be synchronized with current object lists. It's a problem, because I want to make it possible to add objects easily.

The current implementation has one base class for all maps, including routines that are needed in dungeon generation. Those routines are however not needed for objects like monsters or items, because they don't come in formations in general. What I now plan is three base classes for maps. The first one should remain a simple int-based map. It doesn't need any special routines for dungeon generation etc. The second one will be a map that has object pointers stored, so you could take the information directly from object type, such as retrieving the correct graphics frame, or even drawing it directly. The third map will be solely for terrain and dungeon generation, including all those complex generation routines.

I guess it's time for yet another refactoring moment. I'm not that worried, although it's going to be a big change for objects at least. It's also a big change in the way I used to think about maps. I wanted them to be just ints, but the experience with Teemu proved that object maps can be safe, if you don't try to do everything with them.