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.

New level themes

Creating good old content. I have had a plan for the dungeon structure for a long time and now it's time to bash in the data and create a game world that can be navigated. I made five new themes or places and all of them fits in the plan. I'm very careful not to add stuff just because something must exist. I made that mistake already and learned from it.

The way connections are made is still open, but I had good exercise when I was programming similar kind of system for Agduria, which is probably already an abandoned project...

Object type

I made a new class that handles the "low level" static object data. I guess it's easy to add in the current object base class which previously had this data. The reason for this change is that I can use the basic data without creating an object and also restrict the low level data behind an abstract public interface.

You know, this was an idea that I just invented, after several years of programming. It's game object's object type as a type and holds some generic information about objects. It may sound like overdoing, but I don't think so. I think this will make the object system easier to use in future, if I need to add some properties to objects or create new game object types.

I'm just not sure what to do with inherited object's special data. Functions in the base class or retrieving the data from object type's data?

Message repeat bug fixed

This was one of the bugs that was around for a long time, because the lack of consistent thinking. But I have become better in that too, so I hope it's now fixed. The same bug is also present in Teemu, but it's not a crashing one. The routine just doesn't show repeating messages properly.

The thing with difficult bugs and features is that you have to fix them some day and it's really that hard to fix stuff that increases the time spent on a game project. If only everything was easy!

LOS solved

Starting from Teemu's LOS routine I tried to transform it to Kaduria's block-sized output window. For some reason it didn't work. First I noticed artifacts in line drawing and there was a bug (<= should have been < in line length), but fixing that didn't solve the symmetry problem.

Then I discovered that in order to get symmetric result you have to draw lines in symmetric order from corners to center (previously tried to draw them with one sweep from one corner to another). So, you need eight line drawing sequences for each octet.

Using line drawing for LOS causes also the shallow slope problem which means the routine can't reveal everything, but always stops at wall. This can be solved with los fix -routine that scans for walls and other obstacles, checks if they are next to visible tile and pointing towards the player, then reveal them also if they are in darkness.

I believe the result is very fast LOS, because the tiles are visited roughly twice with line drawing and once with los fix. I'm also using an update map for tile drawing to prevent drawing black LOS tiles if there is already one in that place, so it reduces the amount of tiles output almost always when there is something in darkness.

Descriptions

New class Description loads and parses description texts which previously were in C++ files. It takes some files away from the project and speeds up the compile time, but now I can also edit descriptions at work as they are plain text files.

There certainly is some writing to be done. Lots of item descriptions are missing and while they don't really add anything significant to the gameplay I like the idea of verbose descriptions, because you can make the game world deeper with added details.