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.