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.

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.

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.

Corridors

Yeah those corridors. Those bastards are hard to get right. In Agduria I have invented something that works better than in Kaduria, but then again Kaduria has different style of room creation. With pathfinding I can nail it for quite sure, because the problem is mainly in finding the proper entry location for corridors. I'm also using the closest room -routine to determine which rooms should be connected, but that's also creating a set of disconnected rooms. I have solve that one for Kaduria, too.

I wouldn't want to change room creation something like Agduria has, because I try very hard to avoid large scale re-factoring. It's better go with what you created and try to make it work than re-write large parts of the source code.

New game objects

Programming some missing stuff left from the change where lots of terrain tiles were transformed to game objects. I really hope it is the last big refactoring to be done. I want to get a detailed game world with lots of interaction with game objects. I think game world and exploration is more important to me than combat and improving the character, in other words the tactical area of a roguelike. Kaduria is going to be a "sandbox" style game, where you can do other things than just whack creatures.

I think a game where killing is optional could be nice. Usually you kill creatures to get experience and then become able to kill bigger monsters, but Kaduria doesn't have experience points...

Fixing bugs part 2

When fixing a bug that didn't draw walls when partially on cavern area (that dark mask on picture) a new bug appeared. As you can see corridors (green mask) don't really behave that well when trying to find a way in a round room. The reason is diagonal "corner" mask (white) which corridor routine avoids when it tries to find a straight wall (colored ones). This bug could be fixed with pathfinding I guess.

It's not unusual that fixing something creates new bugs, because of the complex relationship between different parts of the dungeon generator.

Fixing bugs

Fixed some bugs today and added new ones in the bug list. I should probably make a better list of bugs, because they aren't going away. I think I have been too condifent that re-factoring the source code is going to remove bugs like that. In fact removing bugs is re-factoring and it's maybe the best kind of re-factoring, because you create solutions that just works and not a perfect source code that is supposed to work (that rarely happens).

It's been really windy all this day. It's not usual in this part of world. Like what the heck is going on? To make it more annoying our rooftop is loose and it's banging against the roof all the fucking time.

This day sucked at work, too. I was given a job as an officer to EU election (some lucky bastards get elected to EU parliament and get like shitload of salary). EU is shit, it's going to fall down in couple of years. So, there I'm sitting on a chair for FOUR hours and waiting for people to come and vote for those bastards. The pre-election lasts a week and I have four days, each having 4 painfully long hours left.

If that is not enough my prostate is killing me. It's been bad since last christmas and this is no joke. When it's going chronic you just have to take it like a man. I should go to doctor, but I'm not sure they can do anything.

Fuck that wind. Fuck you, wind!

Kaduria 0.4.6

0.4.6 was the last released version. I remember it now, because I found all release versions from old computer. I was amazed how playable that version was. Everything seemed to be fine, but I remember how stuck I was at that moment. The dungeon generator was hard coded for one level theme, which basically had almost all features mixed together.

It was somewhat painful to notice that it had more playable content than the current version.

Level class refactoring

I'm browsing through the Level class and trying to clean it, plus programming some missing things at the same time. It's quite an overwhelming task, because Level is a huge class. When I separated ground objects from terrain tiles (they became actual objects) the change was bigger than I first thought so that's basically what needs to be refactored in Level.

Action

I need some planning with actions. First I have to think how actions are broken down to atomic pieces for both player and monsters and what data actions need. The AI for actions is going to be really tough stuff. I don't have experience with sophisticated AI and it's first time I'm trying to do that. I have a vague idea how it's going to work, because I have thought AI issues a lot during the development.

The new Avatar

I'm refactoring the player class and also U_Npc, the base class for monsters and the player. It's now getting slightly interesting, because I'm restoring the actions which the player (and monsters) have in the game world. They caused some serious problems before, because I wasn't really good at figuring out where actions should take place. Even I knew monsters share some actions I didn't (for some strange reason) place them in the base class.

Writing the code for actions is I think the hardest part in roguelike project. You know, those innocent looking commands like eat, look and search. They rely so much on the engine core, that if the engine is broken then the commands can't work, or they require constant refactoring to match the changes in the engine. Of course, writing modular code is a good way to prevent such problems, but I really didn't know how to do that until now.

Equipment re-design

Previously I had items in inventory list and they had in_use -variable to show in what use the item had. This included wearing and wielding items, but I really didn't think I would have to re-design it later. In fact I didn't think at all when I designed the first system, it just felt nice to have inventory with items tagged as equipment.

The problem was that when you check for items you have to go through the list and check in_use every time and with monsters doing the same it's going to be slow. So, I changed the equipment to an array of items each in equipment slot. The real problem was that I had to re-write everything related to in_use and I'm still re-writing it, because in_use was in pretty heavy use, so to speak.

When this is done I still have to re-design in_use, because it's going to be used in other kind of uses like when you put on a lamp, to indicate that the lamp is on.

I think this was one of the last really annoying re-writes. From now on I try to work with the current style of the source code and accept the fact that it's not going to be perfect OOP.

Tweaking GUI

Made good progress today with GUI improvements. GUI design has always been difficult for me, but now I have a better picture of how it should be done.

Moving objects

There was a bug that was funny for a moment. One of the object types is a movable or mob (moveable object). These are barrels, chests and other big objects you can push, but not pick up. Somehow all of them were moving randomly around. That was a bit hilarious and I was just chasing them for a while. Everything seemed to work well, you could push them like always, they didn't just want to stay in one place. The reason was that when the movable is on water it's floating and moving randomly, but in this case the moving routine was called every turn no matter where the objects were.

This bug could be made a spell, some kind of chaos spell that animates objects to move around and cause confusion among mundanes.

Game object base class forming

It's getting better when I go through the functions and try to figure out them. There are two main areas where improvement is needed. First and most important one are the functions that are interacting with the game world (terrain). Second one is everything related to strings (object names). Then there are some problems with virtual functions. It's a good invention, but can cause all kinds of bad side effects when the class hierarchy is poor.

I'm actually pretty satisfied with the development I made today. There is still time left today to make more adjustments to object base class. It's important to get that working, then I can concentrate to specific game object types.

Room interiors revisited

Back some time I wanted to detach room interiors from Room class, because I thought Room class was becoming too big. I was afraid of big classes, but now I have to fix that by merging interior creation back to Room class. I also had an idea to create room interiors in large multi-room houses, but now I realize I could just create multiple rooms with each having their room interior and connect those rooms to create houses.

I'm actually fixing terrain_map references, but this is a part of it, because room interiors (and rooms) use lots of creation stuff. This time I'm avoiding direct calls to Level's creation routines and use a member for Room which then calls Level's routine. It's one way to emphasize modularity and make future modifications to the source code easier.