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.

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.

The journey of item data extraction

The item data is now extracted from the external data file to a text file that has matching enums for data, kind of automatic binary to source conversion. The reason I chose to use external data was not that bright, but I was much younger then. In the end I finally came to a conclusion that external binary data was causing too much problems in form of synchronization. It's not like impossible task to maintain two sets of data and keep them synchronized (I'm talking about the source codes of editor and Kaduria), but I think it's better this way.

I also try to minimize the manual data and see if it's possible to calculate the rest of data from basic blocks. Like estimating the weight of item by size and material. It's probably going to work good enough, but I don't know yet.

I'm now starting to think that even scripting is better idea than binary data, while I'm still convinced that it's possible to write a role-playing game without scripting.

Progress report

After creating some extra datatypes the amount of source files is increased. The count is now 205 source files including headers. I'm estimating the release version is going to have about 250 files, probably not more than that.

I have programmed Kaduria 42 times in this month. I think it's some kind of record. Refactoring has been much easier now, because the way new component classes work. Replacing old code has been easier than I thought and it has improved the data-driven style of the source code.

Data models

I'm back in refactoring. This time it's the way data is arranged. Back in while I thought it would be great to create a centralized database for object data, but I think it was not a bright idea, because it's kind of polluting global namespace, and besides when you need some data in some other place there is extra stuff included, which is not good for compile time.

So I'm in a process of making data more modular. An example would be profession, now a class of its own and including all data that is needed to know, like graphics frames for profession of certain type of race, or modifiers that professions have. Anything related to profession is stuffed to one module, and then that data is retrieved from creature class.

The role of centralized database could still remain, but different, like a base class for data.

The way I'm rewriting classes for data is quite flexible I think. It's easier to add stuff and reduce the amount of problems when something new is introduced. I think in general I'm also programming things in the proper order, starting from "abstract" data that has small number of connections that could break.

Spell design

Browsing through spell list I noticed there is a spell detect alignment. The problem is that Kaduria doesn't have alignment system like D&D has, so what was I thinking with that spell? I guess nothing. In fact the whole idea of spells is just something to have, because all role-playing games have spells. But when you think of it, spells begin to look like another way to patch gameplay balance in high fantasy. You need spells to defeat epic monsters and dangers.

I don't yet know what to do with spells. Maybe I should just not have magic, just remove anything magical. It's very much possible. Still, I think something like magic should exist. Maybe alchemy (in role-playing context) and stuff like that.