Kaduria

Day off

2012-01-29T00:20:00.000-08:00

The other day I was trying to do something, but instead spent the whole day on internet trolling forums. If you want to get anything done it's not going to work like that, so I have decided to stay away from internet every other day. In my day off from internet I actually had to think how to spend my time, because it wasn't wasted on trolling. Fixed eight bugs in Kaduria which is phenomenal. But it's not just programming, you have more time to practice guitar playing or do some other real life stuff.

Java button

2012-01-12T09:52:00.000-08:00

Sidetracked for two days with a small programming project (I call them "java button" projects) and somehow lost interest to programming. It will pass and I have already been checking out what to do next in Kaduria. It doesn't look very promising. Most things to do are between hard and difficult. I'm getting back to the issues that need serious thinking and game design instead of simple programming to make stuff work. One strategy I have been thinking is work the way from player's point of view to downward in the structure. In other words make the player's actions top priority and monkey them down to other actors of the game.

It's a trap

2012-01-06T07:17:00.000-08:00

Item class has only 12 functions left to complete. Some items can be trapped and for a long time traps gave me constant headache in the way I was trying to implement them. The confusion was caused by the type of traps. Some of them are actual objects hidden on ground, while others are a part of another object. Also, I had difficulties to understand how to implement the effects of traps. If I can handle traps then the entire object system is much closer to be complete, because traps are one of the unfinished parts that affect several object types.

Testing

2012-01-02T01:46:00.000-08:00

Testing the game while creating it may be a good idea in most of cases. However I now think that there is a place and time for testing, too. Kaduria has seen a lot of refactoring and testing that was done then was a huge waste of time after all. The funny thing is that I never questioned my style of programming until now. I also have a habit to compile maybe too often. It's another way to waste time, since in most of cases compile happens without errors. It would be obvious even after longer sessions of writing code.

These two, testing and compiling, are things that I try to cut down to stop wasting time for no reason. Testing in this state of development should be done actually when the gameplay is more or less ready.

Here is the new gameview I was talking about earlier:

Two sections of right side area still missing. I'm thinking of leaving the "mini"-map (it's a debug version routine), but without object list (or show only monsters).

Year 2011

2011-12-31T07:16:00.000-08:00

I was looking at my dev diary from summer to this point and there is surely an interesting trend for increasing amount of development. It's also showing in the new LOC chart (starting from summer):

LOC has increased "only" 2000 lines, but it's quality code! Most of the source code is already in place and only involves some adjusting. Not to mention removed code, there has been some of it also.

This December was actually the best month in development point of view. I was able to complete or almost complete several major classes and the work is now more and more focused on narrow set of classes which have the most difficult problems to solve (AI, item routines, advanced level generation, etc.).

Rebuilding gameview

2011-12-26T05:54:00.000-08:00

Areas of the gameview are starting to update properly again. While refactoring I ran into something quite unexpected. The main stats were updated inside the stat class and signaled to GUI, but of course it was done for all creatures, not just the player. So, had to backtrack and create wrapper routines in creature class to adjust stats and check if the creature is the player, and only then signal GUI. It was easier than I thought so I made it in one run.

It looks like other parts are fine, although I have to add parts that weren't there in the first place: two explanation text slots and quick item slots that can be used with keys 1-7. Then I have to clean up some manual updates, especially check out calls to Redraw in the dungeon class.

GUI class ready

2011-12-25T07:48:00.000-08:00

Another part of the source code is now as ready as it can be. I think the GUI class is looking pretty good now. I don't even hope for good looking graphics at this point, I'm happy that basic drawing functions are done. The gameview still can't update itself so it looks a mess and even messages aren't shown and need to check out n+1 things related to drawing functions, but I'm still happy that something was done and finished finally. It may not sound very exciting, but for me it surely is, having spent so much time on this project.

Next I'm going to concentrate on that gameview drawing. The gameview now has clearly set areas so it should be easy to check out them one by one.

GUI development

2011-12-20T03:54:00.000-08:00

I was right about text updates, most of them work without update inside the Text class. GUI class is actually almost ready and it's doing the job properly for most of parts. The biggest problem is how to draw and update parts from different sources. They also probably need notification instead of direct update which would lead to multiple drawing operations per turn. The good thing is that a roguelike doesn't have that much GUI stuff.

Back about three or four weeks I injured my elbow. The doctor said, judging from x-ray images, that it's some kind of calcification resulted from a long period of inflammation. I guess it's probably right, because I've had tennis elbow for a long time now. The injure came in weight training of course and I think it was a disaster waiting to happen. So, it looks like my training days are over, at least until this is healed completely. I don't want to reach the point where I can't move my fingers anymore. That would suck.

The bright side is that I have more energy to spend on something else like roguelike development. It's going to be a positive thing for this project and I already feel I'm getting more results in shorter time.

Update on update

2011-12-17T09:17:00.000-08:00

Rewriting GUI for update rectangles is going to be worse than I thought. There are manual updates in some wrong places, namely in text output routines and keyboard routines. It was quick and dirty way to implement some linked updates, but they were in wrong place. Things like that should be there, but they belong to GUI. Text update is silly, because text is usually printed on some self-updating surface like window or gui background graphics. That's why there are double updates in most text routines.

It's more complete rewrite than I thought, but essential for that consistent flow of drawing and updating.

Update rectangles

2011-12-17T06:18:00.000-08:00

Gameview is also being re-designed for consistent behavior in drawing and updating. The gameview is divided into rectangles which are updated only once during a turn when a flag is set for that area. It removes multiple updates and makes things both faster and also aware of what should be updated. Update rectangles are needed, because Kaduria is using only software output without any hardware acceleration. It's easier and more portable in the end, and I feel that a roguelike has no need for hardware routines.

I have also finished the structure of the gameview. It's going to have quick item icons for using items with keys 1-7, and status icons. Both of them will have explanation text when hovering over with mouse cursor. One thing I'm not sure about is the debug radar which is a small level map. I guess it could be visible in non-debug mode also, but it should be re-written to display only what the player has discovered.

Load and save game

2011-12-16T11:24:00.000-08:00

Most of the classes know how to save and load, but the main routines are still under development. It's looking quite good actually and only some things need to be tweaked to make sure that there are empty versions of instances for loading saved data. Load/save can be difficult to program, but I'm now much more prepared for that task than I was before.

Debug routines... ready?

2011-12-10T02:34:00.001-08:00

Yes. It appears so. I've finished debug routine module, it's as ready as it can be. Of course there could be some new routines needed, but it's only when I can figure out what they are.

It took only 15 years. And this is not a joke, it's a real number.

Hero coder

2011-12-09T06:23:00.001-08:00

People keep calling me a hero coder (literal translation from finnish language). I guess it's some kind of joke, because sometimes I write comments about social media games like Minecraft and Angry Birds. Even writers of popular Pelit-magazine (biggest gaming magazine in Finland) make regular references to me. It's cute and flattering, but I don't care about that kind of thing a lot. You know, being a celebrity.

I think there has been misunderstandigs about my comments on social media games. I don't hate them or lucky developers who get zillions by taking advantage of the social media. They are game developers just like myself. Except that they own ridiculous amount of money and some of them wear a hat which attracts women.

The biggest misconception is that people think in their own terms like being jealous about money and girls. I don't get that. Game development is my hobby and I'm pretty devoted to it. It means I'm interested in game development itself, not money or girls. Being a roguelike developer means you are in the forefront of game developers. We don't just make games as products but in the next generation roguelike genre we make something new. It's a way no one has explored earlier. And that exactly is the reason I'm making games.

Some people measure success in money (or amout of girls) which means Minecraft is a great game. But if you were a game developer and look at Minecraft from developer's point of view, then it would not be that interesting. Still, as I stated before, I'm happy about the unexpected success of social media games or more like products. They just don't have a lot to do with hardcore game development which is a small sector of game genres living and surviving under the pressure of this commercial world.

Basics

2011-12-06T12:31:00.001-08:00

Sometimes I feel really dumb, because I realize I'm programming some basics that should have been there way back. I'm still working on container code which is moving items from objects like barrel to inventory or somewhere else. It's a kind of feature you would suppose to be implemented in early stage, but somehow isn't.

I guess this is the case with some other features as well. Maybe there is no proper order to complete features. Then again I have spent a lot of time creating this simple turn-based RPG with random content and I'm still wondering how hard this could be? What is the problem with roguelikes anyway?

Secret idea

2011-11-21T02:21:00.001-08:00

I got my ass kicked by the first temple's boss in Zelda Skyward Sword. And I had one revitalizing potion (restores four hearts). So they finally decided to make Zelda harder. Well, one of the strange things is that I don't know how to use the shield. Would it help in that battle anyway? Maybe I'm going to cry for two days and then look for Youtube videos about how to beat that son of a bitch.

While playing Zelda I got an idea. It must remain a secret however, because it's going to change one of the main areas of a roguelike. And what is a better project to use that idea than next gen roguelike.

Bug hunting

2011-11-13T02:42:00.001-08:00

Today I fixed a special bug that made the program crash in Long Corridor level theme. It was a special one because there are no other known bugs that crash the program. The bug was relatively easy to find. In fact I was using VC debugger to find it. Usually I don't even need a debugger to find the bug, but in this case it was needed.

The number of open bugs is 12 which isn't that bad. I try to limit it under 10 to keep the game playable and as solid as possible. Some bugs are caused by parts of the code that are going to be refactored and usually the bug will be fixed at the same time. The current speed of development is quite fast and I believe it will produce an increasing number of bugs, but it's obvious that the release version will have zero known bugs.

Theme randomness

2011-11-11T00:05:00.001-08:00

I'm having trouble trying to determine the stuff that will be generated in level themes. With lots of stuff it becomes more difficult to figure out how to select that stuff. There is a list of stuff to create for each level theme, but I know it's too restricted and predictable. Creating a list is easy, because you don't have to program a logic that "thinks" what could belong to that particular level theme. And that is exactly what I have to do next.

It's not an easy task. There must be a new type of classification of objects just for level creation. Then the level theme could ask an object from different kind of classes to generate in specific terrain area or climate condition or whatever the reason will be.

Level class

2011-11-02T08:09:00.000-07:00

Returned to Level class. I have switched between big classes and browsed through them, fixing everything in sight. Level class is possibly the worst of them, because the dungeon generator still has some problems. It can't generate all level themes yet, but I'm working on it.

In some parts I have made a decision to settle for less great stuff to speed up development. Maybe I'm really looking forward to create a playable version, no matter what features it could be missing. Still, I'm pretty sure that the first playable version is not going to be a release version.

Item class part two

2011-10-22T13:58:00.000-07:00

My tennis elbow got better really fast, it was just some kind of episode. It's still there, but not painful. Item class is almost ready for the parts that are already there. Something tells me there is going to be more code for items, but it looks surprisingly good now. I have lost my obsession to create "perfect" code (or engine) and just try to get stuff work. Well it isn't a surprise that things start to happen. However I'm as puzzled as ever when I think when or how this project is going to become a real game.

Item review

2011-10-12T02:34:00.000-07:00

Giving Item class the same kind of check than Level and some others it was quickly obvious that it needs serious fixing. Many problems come from the unfinished role-playing system. It's really slowing down everything, because you can't write a routine if you don't know what it requires. But like with previous classes I have learned to look at the source code more closely and make better decisions.

Level class refactoring

2011-09-28T06:54:00.000-07:00

Last three days have been quite productive. I have searched through Level class which is 3500+ lines of code. Many routines need either fixing or test how they actually work in the gameplay. I think the worst example was a routine searching for free places (when game objects are spawned). It doesn't work like it should, but when I change it data-driven it should fix most of the problems. I've also learned that everything should be check only once, because you will have extra rules and if that another routine doesn't check them it fails. There must be something like that because sometimes there are plants created on walls. It's bit of a mess, but it's going to get better soon.

Solutions

2011-09-24T04:17:00.000-07:00

Going through Level class and closing functions when they look like they're ready. I think this is pretty good way to proceed especially when you get lost in the jungle of source code. The basic idea is find problems and try to find a solution for them even faster. When you program longer you start to understand what are the things that slow down development. I think there are only two things: 1) you did not find a solution for a problem and left the function/class unfinished and 2) bugs.

If it only were easy to fix all problems when you see them. But usually they are related to something else that needs to be done before you can continue. This is the difficulty in roguelike programming. With regular games you pretty much know what you need to add to make the game work like it should. With roguelikes you run into huge problems like artificial intelligence and the myriad of ways to interact with the game world. I hope my new style of programming brings some quick solutions.

Fighting style

2011-09-06T06:08:00.000-07:00

There are some things missing in the process of constructing/creating a monster. Artificial intelligence type or AI type was quite easy to add. It was determined from the monster family and/or type of the monster. It's later used to make decisions about how the creature will act in certain situations.

Skills and default items are still missing. Some skills can be determined from the profession, but default item set is a problem. You could determine them from the profession and type of the monster, but instead of that I was thinking to add a new AI module fighting style. That way let's say a human fighter could have several styles with weapons and armour selected for that particular style. Not only items, but you can then determine combat strategy and also some additional starting skills from the style. Besides you need less fighting styles than there are professions and monster types.

Fighting styles need random variation in weapons and armour to prevent static item sets. It's going to be a complex system which is only telling how even one small area of roguelike is incredibly difficult to program. There is no easy way to do this, you need to create a number of styles with proper items, but still maintain random variation.

Monster review part two

2011-09-01T06:29:00.000-07:00

After some research I found out that only 40 of 134 functions in Monster class are ok (possibly don't need refactoring). The rest is in less good condition. I have hidden ok functions with VC's gui so it's easier to get work done in unfinished functions. I can only guess that it's a difficult task, but this situation with unfinished code and gameplay content has been going on for too long. Something has to be done and I got a good start by fixing some functions. The following days will tell more about how fast or slow I'm able to fix things.

Review of monsters

2011-08-31T09:54:00.000-07:00

Today I was looking at the Monster class. It's 2971 lines of code which in Kaduria is one of the biggest source files. Most of it is ok, but it's missing AI code and role-playing system parts. It has been difficult to create the rpg system itself, because I suck at it. However I feel that if I can nail this one it's going to be much easier to complete the game. This is the important part, how to make monsters tick so to speak.

Another difficult thing is the relationship between Monster and Player classes. I now realize that there should be a clear derived-type construct which should not be broken (which I have done). It's another issue which is going to take some time to fix. But even with all these difficulties I'm optimistic. I have learned my lessons.

Snow fox

2011-08-27T02:05:00.000-07:00

I may have been too careful not to add too much content (like new creatures, items, etc.) during the process of programming the engine, but I guess it's time to forget the engine for a while and just add anything that is needed.

Level themes are quite strongly themed with specific monsters and other stuff, but I try to avoid making them too predictable by trying to break the rules randomly. I have thought that it could be possible to entirely replace a part of dungeon area with another theme, but that's something to consider later.

The problem with adding stuff is that it can be later tiresome to edit all that data if/when something changes, but then again I haven't spent all this time for nothing: the engine is flexible enough to introduce new stuff without too much extra programming.

So, again I'm at the snow top, wondering what kind of creatures live here...

New member

2011-08-26T07:01:00.000-07:00

I was bored so I decided to refactor some code. Key_Handler was changed to modular class with minor changes and it went into classes directory which contains all modular classes of the project. They are classes that need least amount of maintaining. Whenever I get something in classes directory it's like those lines of code are removed from the usual maintaining horror this kind of project has.

Even two or three weeks off the project seems to make it possible to look at the code from a distance and possibly create better decisions in how to proceed.

Shops

2011-07-30T12:02:00.000-07:00

After returning to Kaduria I was fixing some stuff and noticed there was no support for shops in rooms so I started to refactor that. The source code was there already, I just had to add a sub type in Room class for shops. Everything seemed to went well, because the shop creation code was also ready. But then... to my surprise it didn't work at all. Everything went wrong: there was only one table in the shop, the shopkeeper was in wrong place and all shop items were null items (this happens when the item creation fails and it's a safe way to detect problems, because null items actually work, they are just not real items).

I guess it should be easy to fix those problems, because the code to create shop and items is really just about 20-30 lines of code.

Environment actions

2011-07-21T01:40:00.000-07:00

I think the objects need to have a memory of where they were before. I think it's the only way to do stuff like pushing things into water. If the object doesn't remember where it was you would get multiple messages of the object falling in water when it's pushed to the next water tile. The funny thing is that I previously had that kind of data, but for some reason I removed it. I need to look at action data again, because creatures do have current task they are doing, like swimming. But I think that can't be used with other type of objects, because things like barrels don't go swimming, they just fall into water and float in there.

I'm thinking of breaking the big poop into micro actions. Like "fall into water", "float in water", "get out of water" etc. Well maybe I don't need the previous action to determine things, just current action.

I've also tried to clean up some of the mess in Message class. It's scary, that's all I can say about that.

An idea about stairs

2011-07-18T23:31:00.000-07:00

Playing JADE gave me an idea about stairs. I noticed it's super annoying trying to find stairs to the next level in those quite large levels (especially maze types). So, why not make it easier and place the stairs somewhere near the entry stairs? It would make navigating much nicer when you have explored that level and just want to pass through it. Someone would argue that it makes too easy to advance, but that's not correct. The level difficulty should be determining that. In other words you can't just rush into places without getting killed by powerful monsters.

JADE is a nice game, because it shows how not to do things. It's constantly reminding what is bad game design.

Digging - object specials

2011-07-06T03:41:00.000-07:00

It was premature to say that digging objects was going to be easy. Sure, most cases can be handled with Damage that simply causes blunt force damage to the object, but there are plenty of special cases that need plain old source code in each object type's Dig virtual function. Let's take an example: when digging a pit there can be a tree in that tile. You can't dig a pit there and you can't cut the tree. I've made a special case that tells the roots of the tree prevents digging. Other option would be cause damage to tree until it falls, possibly damaging the player if he gets hit by it.

There are surprisingly big number of special cases related to digging, so it's somewhat slow progress when programming that stuff in virtual functions. Nice thing is that I have those special cases in the old switch-case function for digging, so I can extract messages and such from them. But in many cases I have to re-write stuff, because game objects work different way than old terrain based object tiles.

Digging into digging

2011-06-26T03:54:00.000-07:00

Digging routine is probably the most complicated of actions. There are actions for variety of floor and wall types, but also for all game objects. However it's now quite easy to handle game objects, because Damage can be used to generate simple "pick-axe" damage to objects, much like kicking does. Floors and walls (terrain) can produce different results, because there isn't just one floor type (like in Nethack for example). You can do all sorts of special stuff like digging on ice and fall through in icy water.

With terrain tiles I had to create a test function that generates all terrain tiles and then just went on checking what happens when you dig each tile. That way I could clear the confusion caused by rather complicated data-driven approach... but I guess that's the best way to do things anyway: test everything you possibly can figure out.

LOC chart 2

2011-06-24T03:14:00.000-07:00

When you start to add content it shows in LOC. Although the chart can look deceiving since there is only about 500 lines of code added. It could be more, because I'm in the process of moving old kicking and digging functionality into new data-driven code and then removing old commented out code. Both kicking and especially digging are full of content, because a lot of things can happen in those actions. The functionality shift from old code to new isn't easy, but I've managed to create a good flow with the current engine. The new code is already much better, because it's data-driven and if something is missing it's quite easy to fix later.

Damage challenge

2011-06-22T02:59:00.000-07:00

It looks pretty good with Damage and Kick, which is using Damage. The only exception will be combat, because it has to be handled with higher detail. Kicking objects makes them break! Although there is some minor adjusting left in the amount of damage, because you can break anything with one kick. The amount of damage is too much, which in return brings a question about the HP or condition value of a object. What should I do with that? Maybe linking that value to the size of the object is a good choice, because it's obvious that bigger objects can take more damage before breaking. But how about monsters?

Kicking ass

2011-06-20T03:30:00.000-07:00

Sometimes virtual functions can reveal their bad side which is repeating code. After all virtual functions are a lot like switch-case in traditional C. I noticed that when re-factoring kicking for objects. Each object type has virtual Kick function, but it's starting to look like the data-driven style is kicking back with generic code that looks like it could be placed in one function. Good thing is that such function already exists, I just never thought it could be more generic. It's of course Damage, a routine that has caused a lot of pain to program.

Sometimes I wonder why it took so long to "return" to this stage, where stuff begins to work like it should (for example kicking objects). Did I really spend six years refactoring the game engine?

Constructing constructs

2011-06-17T02:32:00.000-07:00

Constructs are one of the object type that are man-made. They too are still in early stage. However I was able to write light routines for lamps pretty fast. I even made a video in Youtube where I'm testing a lamp:

http://www.youtube.com/watch?v=g8Rdyw4Yp04

Meanwhile Visual Studio and Opera started to act strange. There seems to be some trouble with menus which are aligned to left in the main level of menus:

I don't know what's the problem, but I think it came with Windows 7 SP1, I guess. Or maybe some setting has been changed somewhere. It's not a big deal, but these modern operating systems, you know.. They are so complicated that can't even keep setting like this.

I try to continue with constructs. Some graphic tiles need to be made and start to look at different actions like what happens if you kick 'em.

Messages

2011-06-05T12:36:00.000-07:00

Some good progress today. I managed to tweak a routine for messages that places messages in a list and displays them later. It might look like an obvious solution, but it wasn't that back then. However I was pretty glad that it didn't take too much refactoring, in fact both styles work at the same time. I guess it's going to take some testing to check out everything, but that's what the players are for;)

I've been adding missing features and today I was able to program the container creation for item containers (bag, backpack, etc.) and also container routines for them, but that was pretty easy, because I copied the code from movable container. It has virtual functions and in places like this virtuals are cool. No need to re-factor anything, just add virtual routines for the class and that's it.

Now that I have a youtube account (Kricex) I'm planning to create a video demo of Kaduria as soon as the gameplay looks like there is something playable there.

LOC chart

2011-05-03T10:28:00.000-07:00

What can happen in ten days of coding? Well, not much. But this chart clearly shows a refactoring event. The number of lines start to decrease, but once the refactoring is over you can see that last two days increase LOC. This means that there is need for new code and the project is not yet ready. How things will continue from here? How much the LOC will increase when the exciting data from next ten days is recorded? Stay tuned!

Doorplace search

2011-05-02T10:27:00.000-07:00

This one is really giving me a constant headache. How to make sure that rooms are connected?

Rectangular rooms are quite ok, but round rooms are the worst. There is a small section, often one tile per facing, where the door can be made. If the corridor and doorplace don't cross it fails. Now, this is where I might try a routine that extends the corridors to find and clear the last couple of tiles. There might be couple of ways to do that, but I think starting from the first tile next to doorplace and then searching with a pathfinder. You can't possibly go wrong with that. Well, unless the room is completely surrounded by other rooms. That's when you need to crash through the room walls to another room.

Bridge generation

2011-04-30T05:27:00.000-07:00

Finished automap tile data refactoring for all objects that had automap tiles. Some new tiles are required for new objects.

Now when I can see ground objects from the automap I noticed that bridges need more logic in the creation. In that screenshot most bridges lead to "nowhere" in small area of the level and some are generated right next to each other. This one should be quite easy to fix, just check out the sides of the bridge and also what's in the direction of the bridge. Those green spots by the way are the old bush tiles. I found out that there already was 50 automap tiles for ground objects. I did remember them, but they were in a separate tileset that was not loaded until now.

Cave generation

2011-04-29T10:27:00.000-07:00

With the current version of cave generation I'm letting rooms connect to walls of another room. I'm hoping that by allowing this it's possible to create almost town-like dungeons just by creating lots of rooms in a small space.

This is a section of a cave theme level view in automap. Those green spots are bushes... it's a start of more generic plant generation, no other than bushes are generated at the moment, but it will be a jungle when there are more plants. It's all getting back slowly. Rooms, corridors, stuff like that.

Room creation returns

2011-04-29T03:56:00.000-07:00

I had the room creation switched off for a while, because I was re-inventing the wheel in how the rooms should be placed.

The first thing I noticed was this. It's what we professionals call "island creation". Two systems are created separately and don't connect to each other. In this case caverns and dwarf-made rooms. Well, I guess this could be quite easy to fix, maybe check out if connection was made and if not, use a connecting corridor from one of the rooms or corridor tiles. I think a corridor will usually cross a cavern area, but things like this will happen sometimes.

By the way, I still have to figure out how to prevent corridors meeting a room at sharp corners, creating impossible situation for entrance/door creation. Yes, I know, this is something that I have worked on for a while...

History of Kaduria

2011-04-20T07:52:00.000-07:00

During the creation process I have started to form a history for Kaduria. It's loose and I don't know the exact details myself, but I'd like to tell something about it.

As everyone knows Kaduria was constructed by dwarves, like Moria too. But that's only half true. In fact there was an older dungeon built by ancients. (You got to have ancients, because they are cool.) From this process there are still places and items left that are clearly something different than what dwarves made later. Then, who were the ancients? Were they elves or maybe dwarves that were more advanced in metal handling? Or could they have been humans? I like to keep that an open question.

There were also two other ancients. First of them is well known and there are still people left from the tribe that once inhabitated a part of Kaduria. Then there were also a third kind of ancients, who possibly were the oldest of them all. They were the ones who built the twilight gate.

So there is lots of ancient crap to be discovered. Powerful weapons and treasures. Dwarves were not interested in searching the dungeon when they took over. For them Kaduria was a place of mining operations. They couldn't care less about the ancients or the junk that was hidden somewhere. But dwarves were concerned about the twilight gate and it was hidden by them.

Lines

2011-04-19T05:39:00.000-07:00

I think it could be interesting to start tracking the LOC count from each day I'm programming Kaduria. The current LOC is 40 609 which includes everything like comment lines. When I get ten days of data I'm going to make a graphical summary and post it as a blog entry. It will blow minds.

In the latest ADOM blog entry Thomas Biskup wrote that ADOM has 150 000 lines of code. That's crazy! It's over three times bigger than Kaduria. And not just that, I seriously doubt that Kaduria will ever be much over 50 000 LOC. But then again, Kaduria will be a simple farming simulator and not a real roguelike game anyway.

Brick Atelier development

2011-03-27T09:14:00.000-07:00

Well, now it's time to continue Brick Atelier (former Stile), a sprite editor made for Kaduria. The thing is that I'm using it to draw all tiles and it's missing a key feature: import. I need that for some tiles. I haven't touched BA since last year so time is really flying fast. I had a new idea how to refactor the user interface. It's a needed feature for the release of new version. I don't mind about GUI elements getting in weird places but it's better to fix that for actual release. BA has 10490 lines of code so it's actually quite large project. The main reason for the large size is the custom GUI I made myself. Only the Windows file dialog is not a part of the custom GUI.

Feature days

2011-03-26T02:30:00.000-07:00

I try to fix one feature or bug per day. It's a lot for the recent development speed. Oh, Duke Nukem Forever is delayed which is "good" news since I "promised" one level demo (or something) released at the same time when Duke gets out. But I somehow know it's not going to happen. I mean the release of Kaduria's demo.

Things look better now though. It feels like everything I do now is solid, something that doesn't need refactoring later. It feels almost sad to say that after 453 years of development.

The pit problem

2011-03-14T03:10:00.000-07:00

A pit in two-dimensional game can produce unwanted logic problems. It's lower than ground level so there should be support for third dimension. But sometimes there isn't and that's the problem in Kaduria. Let's say you push a boulder in the pit. That's easy. What happens if there is something in the pit already, like another boulder or a monster? They don't fit in the same pit, but there is no way to put the boulder on top of anything, because there isn't support for third dimension.

I guess it's time to add that support. I really tried to go with only two dimensions, but it's impossible with the level of complexity Kaduria has.

Notes

2011-02-23T03:05:00.000-08:00

Been fixing some difficult parts in the source code marked with note: comment. The overall development is also getting faster all the time. It looks like I have passed the obstacle of not knowing what to do. I have concentrated on dungeon generation to get it ready. The main idea of the generation is first create simple structure and then decorate it with automatic stuff like plant growth and decay. I'm quite happy with the current speed of development, it really feels like something is happening and I just have to fit some pieces in the right places to get this game ready for first 0.0.1 alpha.

Journey onward

2011-02-09T02:23:00.000-08:00

About a week ago I got a second flu. This one was easier and I'm getting better, but I have been sick for month and a half! Today I tried to continue Kaduria, but it seems to get more difficult all the time. The source is full of problems that need to be fixed, but many of them are scattered and need fixes in many places and I'm always confused about how to fix problems that are like that. Then there are "impossible" features like sleeping. For some reason I wanted to show a graphical camping scene when sleeping, but it's just impossible, because monsters are moving and when they move the gameview is updated... maybe if there was a possibility to check the sleeping in one place before updating anything then it would be possible. But I think I'm going to settle for easier solution and show only the gameview when the player is sleeping.

Terrain refactor

2011-01-23T02:44:00.000-08:00

It's funny how I have to fix the old school design yet to this day. I guess it was worse than I thought. I'm speaking of the terrain/object distinction. In the old model some terrain tiles were object-like and there were a lot of terrain tiles like that. In the new model objects and terrains are separated, leaving some basic terrain types. This doesn't sound too bad until you find out that every action routine must be rewritten, things like digging and kicking. I have found it hard to create a solid way to interact with the environment and limit the use of special case code.

This is where data-driven approach will help, but it doesn't happen by itself. Also, it can be possible that you start to refactor the data-driven implementation to achieve more detailed system. I think my plan with plants was too detailed and I need to stick to basic stuff to get something done in reasonable amount of time.

For a while I wasn't really sure what the hell I'm supposed to do next, but at least now I have this data-driven terrain system to create.

Searching

2010-12-25T06:09:00.000-08:00

In order to search you need to have something hidden. Traps and doors are obvious... wait, doors aren't obvious. I have problems trying to figure out how to hide the door. Will it look like a wall? How is this wall tile handled, is it a normal terrain map wall? What happens if X happens to that wall (which isn't a door). Stuff like that.

Then there is an issue with hidden items. At first they were in a special list in the level, but I realized that handling hidden items will be more logical when they are inside the object which is hiding them. So, in order to get hidden items feature I have to write (possibly) a virtual mechanism for them, adding another type of container for hidden items. It could be easy now when container ability is ready, but you never know.

I'm also planning a data type for the search routine. It will continue the style I've been using in data-driven types. I have developed a certain kind of routine in programming for them so the data type will be quite easy to do, but it's always a matter of how it will be used in the rest of the source code. Programming data types for stuff like that may sound strange, but I'm always trying to reduce switch-case programming, because modular data types are so much easier to extend when you need to add something new, and they are also modular, meaning that when you get that module ready you can pretty much forget it and focus on other parts of the source code.

Shamino kills the unexpected bug

2010-12-20T15:02:00.000-08:00

I'm glad the bug was not in the debug message routine. It was a mismatched data type in printf-based routine. The printf mismatch is one of the bug types that even VC's debugger doesn't catch that well, because it's inside the printf implementation and will corrupt memory, but the debugger was close enough.

Some time ago I was writing about "note:" comments. I've been slowly fixing them and the count is now 31. Those parts are actually quite important, because every unfinished feature or unfixed bug is delaying the project, especially when you don't know exactly how to handle them. It's not clever to leave them to be fixed later. I realize now that you need to attack the hard parts first and try to create some kind of solution, no matter how poor it may be at first.

The unexpected bug attacks Shamino

2010-12-19T13:19:00.000-08:00

I was refactoring combat, but it's hard because the debug message routine has a bug:

This really sucks... Let's hope it's something simple. Now when I'm looking at my old combat routines they have all sorts of funny mistakes and I guess it's going to be better soon. Getting the basic combat ready is going to make testing more interesting anyway.

I have to do something

2010-12-13T10:25:00.000-08:00

It looks like I have to... plan. Yes, I'm afraid things are that bad. The target of planning is the AI flow: how creatures make decisions. I want the AI to be fairly complex, but not too scientific which I don't know how to implement anyway. I believe it's quite easy to fake AI that makes creatures look like as if they were thinking what to do next. The key is random (or different) choices in strategic points to remove deterministic AI that makes everything predictable.

I have been programming tools to follow what kind of decisions creatures make, but the actual determining code could be planned with flow chart. I don't do flow charts that much, but I think it's time to try. I think the difficulty becomes from many different kind of AI units for each main type of monster. I don't want all monsters just chase the player, I want monsters with different kind of plans and even enemies other than the player.

Rooms again

2010-12-03T07:24:00.000-08:00

I left plants for a while and returned to room problems. Back in January 2009 I was writing about connecting the interior and room structure in the same class. Well, it was something like a mistake. Now I realized that it could be easier to start with basic shape of the room, then add wall and floor data (room data in general) and then create the interior when everything else is done. Without that there would have been room types for all shapes and interior types for no particular reason, creating a long list of data for all possible combinations.

I also have had problems to create and connect the rooms, but I think I have a plan for that finally. I will let rooms be created in any place possible other than overlapping the room floors with another room. Then work out connections either by creating holes on walls or using corridors. I have already planned how corridors would always work perfectly without ruining the room structure, but at the moment it's only a theory.

I have found room placement so hard to do that I actually made the dungeon levels work entirely without rooms, using natural caves as the base of dungeon generation. Rooms are actually something extra carved to natural caves and it even feels realistic.

Let's hope everything will work this time. I don't want to look back in 2012 and say I was wrong (still refactoring the room and corridor generation).

Fertility factor

2010-11-29T04:28:00.000-08:00

I made a simple routine to simulate ground plant growth. It's calculating the fertility factor for surrounding tiles and then growing a plant or if some type of growth exists it's growing it to the next stage. The result from such simple simulation is actually quite nice. Here is the situation after one iteration:

And this is the same place after ten iterations:

As you can see water gives better fertility factor in pretty much natural way. Now after this is done I can start to implement the plant object generation (these are just simple terrain tiles) on top of that. The great thing about this is that the routine can be run again and again. With large values everything will change to thick swamp, and with plant generation I'm already dreaming of forests that will be properly tuned for temperature conditions, creating jungle or cold/dry climate forest. All that without any kind of static or pre-determined routines. Just some rules for growth and iterations.

Bugs of Kaduria

2010-11-26T03:14:00.000-08:00

The current version 0.4.9 has three known open bugs:

16. When throwing item against a wall, it hits the player (z-location problem in collision detection)
13. Top area flickering when message shown
3. When in fullscreen SDL aligns all open windows to right side of screen (remove fullscreen option?)

Each of them are kind of hard to fix. Z-location problem is related to how the game sees the z-direction (depth) and it's an issue that needs either manual fixing or a big rewrite of engine to actually support third dimension (even the gameview will stay 2-dimensional). Bug #13 is annoying, but could be easy to fix. Bug #3 is SDL related and can't be fixed by me. I noticed that when I exit fullscreen every open window is moved to right side of the screen. I hope there will be new SDL version to fix that one.

The total bug count is 28 for 0.4.9. I try to fix bugs when I find them and keep the bug count low. The release version will hopefully contain zero known bugs, just as in Teemu. I think it's doable and the current situation looks quite good. The engine seems to be stable and there haven't been crashes for a long time actually.

Level connections

2010-11-05T00:14:00.000-07:00

The level connection routine is now ready. There was a confusion with connecting proper ids since stairs (or more like nodes) have their own special id unrelated to object id of stairs.

Each stairs have a sign that shows where you are now, but I think it could be useful to show where the stairs lead. Maybe even both in the same sign. There could be some variations like unclear signs or no sign at all with special stairs.

Guess what?

2010-10-30T02:05:00.000-07:00

Yes, I'm writing a spawner for Kaduria, too. This time I'll start from plant spawner, because it's really closely related to terrain types and possibly adding level temperature/humidity as filtering factors. Kaduria also has static lists for object creation and it's horrible, although I noticed the problem way back and never actually wrote a complete generator code for game objects. The spawner will make much easier to add things like plants and then see how the generator automatically picks them up in the level generation. The amount of work to achieve that is however much greater than in Teemu. This is going to be a hard weekend...

Weekend warrior

2010-10-16T08:33:00.000-07:00

Looks like I'm aiming at weekends with Kaduria's development. I was supposed to do that terrain refactoring last weekend already. Anyway, I programmed from around 9:00 to 18:00 with some breaks. It was just as I planned, the environment action class was removed and data from that moved to terrain main type which now has more data also from the actual terrain type class. Since terrains have simple types their data could be concentrated on main type class. For instance one of the main types is Wall and it's the only terrain type that both blocks visibility and moving, so it's easier to move that data in main type containing only basic types of terrains. This is the style I'm using with monsters and items also. Otherwise you would need to write more data for individual monster or item type. If you can generalize data to basic types it's better and makes editing of data much easier.

With simple basic structures it's harder to get them wrong. Basic type data is like a solid foundation on which you can build more complex data and actions.

Environmental thinking

2010-10-09T10:47:00.000-07:00

Terrain data needs to be refactored, because there are duplicated stuff for it. I probably need only main type for terrains and data associated to different things related to terrain actions. Terrain part has been difficult in Kaduria, because terrains used to be a lot more complex. Now they are just piece of dirt or water etc. But you can't underestimate the complexity of terrain actions since they play such a big role in the gameplay.

If I ever make another roguelike of this magnitude I will certainly make terrain tiles objects that are derived from base class just like all other object types. That would have made things much easier from the beginning. The distinction between objects and terrains cause a lot of extra work.

I need to clear the confusion in terrain part of the source code once and for all. I think it's good to start from the main type data and see what can be included in that, then move to terrain type class. I think this is the task for this weekend.

The cheese hits Shamino

2010-10-03T02:16:00.000-07:00

That's the message I got when I threw a cheese while standing next to wall. So it's not yet there, but almost! I'm happy that I can now navigate through the dungeon, although the level saving doesn't work yet so the game is creating a new level every time. And rooms are taken off momentarily so it's only caverns and corridors.

May sound funny, but I'm excited when I get simple things done like entering a new level or throwing an item. Well, "done" in a way that you can see something happen. The final routines are always much more complex but I'm not thinking about that now. I want to get simple working versions. When I get most of basic functions like throwing, kicking and basic combat I want to make a Youtube video from Kaduria's gameplay. I think that will give people some idea and prepare them for not being too disappointed.

Level node connections

2010-09-25T10:34:00.000-07:00

I now have a registered VS 2010 Express and it's cool. I really like the real time error check which shows errors in red underline. You don't have to compile the file to see obvious errors.

I used same kind of level connection routine that I made for Teemu, but instead of connecting themes I used level nodes which I actually programmed earlier. I wasn't just sure how to do the connecting until now. It may sound odd, but this thing was bothering me for a long time and I was unable to navigate through the dungeon, but now it's quite close. I still have to write a complete save and load routines for Level class, because there is going to be only one level in memory. I made that kind of decision, because then I don't have to worry about the size of the dungeon which is going to be gigantic. Of course modern computers could in theory keep all levels in memory, but why stress the computer with that, when the game is going to use one level at a time anyway.

I'm really happy with the current situation. The source code is becoming cleaner and I know what to do. Just wait and see, it's going to be an end of damerelling me about this game.

Project recovered

2010-09-19T01:44:00.000-07:00

I think I found all files of Kaduria. There were of course more than just tiles, like fonts and misc. graphics. I remember that there was external data only for the precalculated light maps. The latest source files were recovered from a single source, that was exciting. The previous sources were stored month earlier. I don't know what I was doing, but now I'm going to make backups to everywhere I can. I think the latest source was really the latest and I don't have to do anything again, like I have to do with Stile where I was able to recover only the release version (0.82) sources while I had continued it later.

Now I have to wait what happens with VC++ registering which failed, because M$ registering message doesn't get through. They should fucking mail it as a real paper letter. I just need the registering code. Meanwhile I installed Code::Blocks but it's a temporary solution. It's a beta/alpha project and even years older DevC++ seems to be more stable. One of the great mysteries is why they didn't continue the development of DevC++? Just couple of tweaks (better search options like 'find by reference' and internal book keeping of source files) and it would be a great IDE. What the hell have the developers been doing all these years?

Tiles recovered

2010-09-12T22:33:00.000-07:00

I always make backups from the source code, but in case of Kaduria I didn't make frequent backups from tiles unless I changed them. Luckily I had just recently copied all tiles on my workplace's computer for some minor adjustments so the latest tile set was recoved from there. Also, I didn't make backups from static data, but that also remained unchanged and can be found from somewhere, I think...

A promise

2010-09-08T23:28:00.000-07:00

Some time ago I promised to wear a hat (possibly funny one) for a period of month if Duke Nukem Forever is released before the first playable demo of Kaduria. There is still time since DNF is planned to be released in 2011, but I can't imagine that a good playable demo of Kaduria could be possible. I would hate to release some tech demo just showing some stuff, but then again I don't have anything else ready! It wouldn't matter. Nothing matters.

Actually I think this "race" is good for development, because I'm now concentrating on actual features rather than tweaking some part of the engine.

Maybe there could be a special rule: if DNF sucks then I don't have to wear a hat.

Refactoring dungeon generator

2010-09-06T03:57:00.000-07:00

I have a new idea how to create good navigation options in the dungeon layout. Navigation logic is important when you create something more sophisticated than just random rooms. I'm also starting to have an idea how to combine all types of dungeon features seamlessly together. Not all features are needed in all level thems so it must be possible to remove a feature without confusing the level generator.

When I get that working it's time to add plants which are the next logical step in the dungeon generation. I already created a system for plants that are used both in creation and real time plant reproduction. The idea is let plants grow and take their place, possibly struggling with other plants. Light conditions and the type of soil would affect the plant growth. I'm interested to see if it actually works.

Load and save

2010-08-21T01:10:00.000-07:00

Now when Actor class is refactored out I can continue writing save and load routines. Most of object types already can save and load, but some of them still missing. I'm using my world famous Tar_Ball system (developed for Teemu) in save/load. It's not beautiful, but it gets the job done.

The big question remains whether to save per level or keep all levels in memory. Kaduria is going to be a graphical roguelike for modern computers which can handle the memory requirements, but then again it could be cool to keep memory use low. Levels are active one at a time so there would be no need to store all levels at once anyway. Saving a level for first time is revealing, it can be estimated there how much memory one level spends.

Game object rewrite

2010-08-07T03:41:00.000-07:00

Placing a wrapper class Actor between the base and derived classes was not that clever after all. I wanted to give Opener and Container ability to some object types through Actor, but as usual when something may seem like a good solution it turns out to have unexpected problems.

The problem with Actor was that it didn't know about derived classes. In actions like opening something there is more involved than just the component data of Opener class. Different openers act different ways. So the rewrite is about removing Actor and moving Opener and Container classes as components of derived objects. With that approach you can't avoid copying code of virtual functions. Good thing is that the code is short, because of functionality of component classes. And more importantly you get to write individual opening code for each object type, checking out things that belong to the derived class.

Like for instance there are doors and sewers, both openers. But sewer is really a different thing, because the lid can be missing! So, using virtual Open() for both door and sewer have same type of code for Opener section, but there are special things that only certain object types have. Also, when you have virtual Open() it's going to be easier to handle, because you can use the base class handle for opening action.

I think the cost of using virtual functions is not that bad when compared to difficulties that follow with extra class in middle of the class hierarchy. I believe the rewrite can be done during this weekend, so it's not going be that hard, even though it is kind of a big change to the game object system.

Abstract base class

2010-07-24T01:53:00.000-07:00

So, I finally made the base class of game objects abstract by making Get_Weight() and Get_Material() abstract. There was no problem in instance issues, because the class was already used like an abstract one. But I was surprised how many member functions of Get_Weight and Get_Material were missing from derived classes. Usually it's ok, because you just return some generic value for weight and material, but in this case the values were not good. You need the proper values from each object type. It was really good change, because at the same time I wrote missing data for some object types and now weight and material have correct (mostly) values for each object type.

The third essential value is size, but I have still problems to create a generic enough size table for objects. I decided to go with abstract sizes like small, huge, etc. instead of metric sizes. This was simply because it's incredibly time consuming and difficult to get (or imagine) proper metric sizes for objects. I can also use the size as least important factor in physics calculations, because I guess that's what it is in real life also.

I really need to compose myself and get the fundamental object data ready for action.

Convergence

2010-06-13T10:37:00.000-07:00

Sometimes I think about the creation of roguelikes and why it is so difficult to make major roguelikes. There are at least two different ways of development. The first one is most commonly used where you start to add gameplay content and features while just making them work. The development is fast, but later there can be a lot of problems when the game becomes larger. The second is more theoretic approach where a generic engine is thought to process data and produce the game. The problem is that not only you have to struggle with the engine you also need to create the gameplay content, no matter how sophisticated the engine is in handling of the content.

In my long journey of development I have finally come to a conclusion that combining these both is the proper way to do things. If you go too deep in theoretic engine programming, you'll never get any real gameplay done. It's possible to create a major roguelike with the first way, but it usually leads to a source code which is hard to manage and extend. Major roguelikes are the living proof of that, most notably Nethack which has not been updated in several years. If you look at the source code you can see why.

So in programming it's also good that you don't go in extremes. The goal where things meet should be the game itself always.

Level node connections

2010-06-05T04:17:00.000-07:00

I had planned the structure of the game world on paper (that was a while ago) and finally wrote the data for level node connections. It took about one hour. It's not that the game world of Kaduria is big, it's actually not, but there were some number of level themes to connect so it didn't happen fast. It's not over though for the connections. I still have to write the actual entrance creation code based on that data. It's not easy, because there are special entrance types that need to be there in the level theme. I'm not talking about the stairs itself, but the places stairs or other entrance types are sometimes hidden.

Save and load

2010-05-30T04:53:00.000-07:00

Implementing save and load routines for the level. I want to be able to move around in the dungeon and can't do that until the level can be saved and loaded, because there is only one level in memory at a time. Reason for that is probably just my old fashioned thinking, but then again one level of Kaduria takes surprisingly lot of memory. I want to keep the memory footprint small just in case.

Programming save and load for Kaduria is more difficult than in Teemu, but I'm actually using Tar_Ball technology I made for Teemu. It might be ugly, but it's working and I have it ready for action. Someone might argue that I should use "real" serialization, but I want to keep some kind of control in save/load so I know exactly what goes in and out, and when.

To keep things simple I really need that initialization in U_Actor's constructor I was talking about earlier. It's really easier to properly initialize the object so you can then load the values, rather than go too shallow end in the class hierarchy. U_Actor is going to keep me busy for couple of days, then there are derived classes like monster, item and the player's class.

Other than object data should be a lot easier to save and load. I'm really happy if I can make this all in let's say three days or something like that. Then I can navigate through the dungeon and see how it looks.

Creator

2010-05-22T09:37:00.000-07:00

Started to detach terrain generation from the Level class itself. It was about time, because Level was getting kind of large class and the creation can be detached from it, since it's no longer needed when it's done. The creation of objects however stays inside Level, it's easier that way. New class Creator only takes terrain map and level theme as pointers to know what and where to create.

The development of Kaduria in general is proceeding well I think. The problems are in the usual places: dungeon generation and game objects. You can keep tweaking them like forever.

Stuff

2010-05-15T01:37:00.000-07:00

After taking some distance to Kaduria and now returning to it I can see all kind of problems with the class hierarchy. There is stuff in wrong places. In general there is a lot of stuff in Kaduria and it has to be arranged.

Small rooms

2010-04-09T08:14:00.000-07:00

The problem with passages was that it had another bug that made the passage routine exit before it had reached the destination. Now it should work. Added more round rooms and small rooms. Now we're getting somewhere:

I think it's something I wanted, but it's going to have some stuff added before it's ready. The important thing now is fix the corridor routine between actual rooms. I have no clue how it works at the moment. It's supposed to connect closest rooms, but look at that long corridor made across the level. Not what was planned. Looks like the connecting logic is broken. Also looks like one of the room is left without connection.

The connection logic is more complicated than it appears, because you can't just connect all rooms from one to another. It will create a messy web of corridors. It's better try to connect closest rooms and then create additional connections which connect every room together in some way.

Passages

2010-04-08T11:16:00.000-07:00

The slowness of cavern creation was actually a bug in passage routine (a simple corridor). Also fixed small room bug that gave wrong locations for rooms, now they are created again. There is just one problem with passages:

A rogue passage not connected to main dungeon. You would think this kind of routine is easy to do, but it looks like you can fail in that. I mean how hard it is to draw corridors between caverns?

Then there is that issue with round rooms and corridors that can't find a proper wall. Guess I need that pathfinding for corridors after all.

Caverns revisited

2010-04-06T10:15:00.000-07:00

I'm refactoring cavern class to create more natural looking caverns. I tried to use Teemu's source code for that, but caverns in Kaduria are much bigger and needed other type of strategy. Then I noticed that I could use Area class to create caverns itself. It almost worked right away. The neat idea in flood filling was that I'm sometimes using 2x2 seeds to make the shape more irregular. Damn it's slow, but look at this:

The round things are actual rooms added after caverns. They don't have corridors yet. The passage routine between caverns is actually buggy, but I guess it could look ok after small rooms (to be added later), because small rooms attach themselves in free areas just like those loose corridor ends. I like the result, although those long straight corridors don't look that good. Maybe this theme needs more caverns after all.

Messages

2010-04-02T02:33:00.000-07:00

The dungeon generator of Kaduria is such an entity that it's hard to keep it in condition. When something is changed the generator can go bananas. This is what I got today:

It's trying to create a room in bad location, but it can recover from that and doesn't crash. I've made the map routines check out of bounds internal so it can't fail that way, but there can be areas that are disconnected. There is still some serious stuff to do with corridors and how they are connected. Corridors are always the problem.

Actors

2010-03-22T02:38:00.000-07:00

Solved the init problem with Actor class by using late initialization in derived classes. Actor is in a middle of class chain and has no information of derived objects until they are initialized. I don't know how bad that is, but I can't see any other solution for this. You have to know more than Actor knows to determine which object type is a container or opener. One other solution could be pass that information as constructor's parameter, but it's pretty much the same.

It's almost done now, the only thing missing is determine which monster types can carry items. It's already in monster data and for that I have to add one check to cover it.

Creatures

2010-03-17T10:07:00.000-07:00

Lately been fixing artificial intelligence using data-driven building blocks. This is one of the areas that needs most work, because I had only basic moving for creatures in early versions. In fact I have disabled AI and creatures just sit there, waiting for the programmer to do something about them. I'm glad if I can fill all the missing information in about two weeks and then begin to write the executive AI routines that handle the vast archives of creature data.

Notes

2010-03-09T07:35:00.000-08:00

I may have talked about this earlier, but I have special comments in the source code starting with word "note:". Those parts of source contain a problem I have left to solve later. There are now 74 notes. Most of them are hard to fix and today I pretty much fixed one of them, which involved adding stuff to Score class (which I was talking about in 2008 blog entry). Fixing "note:" problems is as important as anything else in the source code, but they have been difficult to handle, because of generic difficulty or that something is still missing, like serialization which I now can handle, thanks to important experience from Teemu's serialization.

Containers

2010-03-07T06:47:00.000-08:00

It's almost month from last entry. I really feel I have now control over containers and there is not much to do with them anymore. Writing container code is hard, because of ownership issue which can be quite complicated in a large scale program. Well, actually it doesn't have to be complicated. I made the usual mistake with container class and tried to give it to too much responsibility. It's easy to think that giving class more functionality will make things easier, but it's not always the fact. It will work only if the class will handle things that belong to it. Then it doesn't matter how simple or complex the class is.

The annual 7DRL madness is going on, but I have my own battle with Kaduria. They can lose the battle and retreat, but I have to push onward to victory.

All your base

2010-02-16T01:52:00.000-08:00

What I have found problematic is the relationship with base and derived classes. Deriving in general is something you need to learn to use properly. I think in many cases deriving is not needed at all, but with game object system of Kaduria I keep telling myself it's good. Well, if not for anything else then the complexity and size of source code, but some of that comes from deriving itself. You need to manage more source code to cover all derived types.

In Teemu I'm using one class for game objects with a type for monster and item. It's working surprisingly well, but then again the object system of Teemu is very simple. The way I'm using derived classes in Kaduria doesn't remove the need to check out what type the object is. It's happening anyway, but in some cases it's possible to avoid that.

The real difficulty with base - derived is to determine the amount of features shared for all object types. Trying to cover everything in base class is usually doomed, because items and monsters have more complex ways to interact with the game world, so you have to keep it simple in base class.

Anyway, the game object system of Kaduria has been one of the hardest parts of the project. I'm constantly refactoring it and trying to make some kind of order out of that chaos.

Looking better

2010-02-13T12:21:00.000-08:00

So it did took almost one day to fix looking routines. Nothing is simple in Kaduria, but it could be from now on. What I did was just hacked looking routines ready without thinking too much how good the source code will look. Well, to be honest it's not exactly ready, but I did solve the difficulty with three coordinate systems and visibility of things with four different kind of looking routines. Still need to fix the messages from objects, because some objects aren't detected at all by the looking routine and monsters return "object".

I decided to switch back to Kaduria for couple of days, because I managed to sort out things in Teemu and it's practically just adding the content, so I kind of got tired and wanted to fix something in Kaduria. I think I have to stop trying to write too perfect code for Kaduria and try to make some stuff ready, but maintain high standard coding when possible, to prevent possible re-factoring.

Expectations

2010-01-17T13:21:00.000-08:00

Now when Kaduria's development has skyrocketed to the next level I think it's good to talk about expectations related to this game. I guess there are people who think that the amount of time spent in development equals the complexity and awesomeness of the game. Well, it's not exactly like that. Some games that were developed a long time didn't turn out to be good, there are many examples of that.

I hope people don't expect too much from Kaduria. After all, it's going to be just a roguelike. I'm of course the only person who knows what to expect, but the problem is that even I don't know what to expect. There are many mysteries I don't know the answer yet, because what I'm doing has never been done before. There is no game like Kaduria.

The big question is what I'm going to do when I get the first playable version ready? I could release it, because it is the usual style with roguelike games. But then I could fine tune it until it's really good.

Restoring the gameplay

2010-01-06T11:26:00.000-08:00

I had a creativity boost when my internet connection was down couple of days. The development is shifting away from engine programming to gameplay programming. I'm restoring and re-inventing the basic gameplay functions like digging tunnels, eating food, harvesting crops and things like that. The engine is in good enough condition so I'm not that afraid to add functions that could be written in more generic way. I'm really tired of trying to create a perfect engine.

I guess it's fun to see that you can finally do things in the game and see what happens, and fix possible problems. There is still a lot of things to do in that area, but it feels like whatever I'm doing now really can be detected in the game as real playable content. In a way the development of Kaduria has just started. I would add a smiley here.

Class as type

2009-12-14T02:35:00.000-08:00

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

2009-12-12T04:15:00.000-08:00

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

2009-12-09T06:51:00.000-08:00

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

2009-12-05T09:35:00.000-08:00

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

2009-11-22T08:40:00.000-08:00

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

2009-11-03T11:52:00.000-08:00

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

2009-10-31T09:11:00.000-07:00

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

2009-10-22T10:24:00.001-07:00

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

2009-10-20T12:22:00.001-07:00

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.

Rendezvous at the Snow Top

2009-10-11T03:51:00.000-07:00

Iolo walked through a long narrow corridor. It felt like he was climbing stairs, because the corridor was leading him up, but where? First he realized the air was much colder in here and then he began to see faint light ahead. It was daylight.

At the end of corridor he saw incredibly large stairs. They were like giant's stairs that had fallen into the narrow corridor. They seemed to be out of place. Looking up he saw clear blue sky and at the distance there was a dense forest. The snow-covered stairs indicated that he was high at the mountain's top. Maybe this place could be reached only from this way.

Iolo began to feel cold. He had no proper clothes for this weather and he realized that better when he stepped on snow. His entire leg sunk into the snow and he almost fell flat on his face. This was not good. He returned on the large stairs, watching for any signs of life.

He didn't have to wait long. Suddenly there was movement in the forest and short after that Iolo heard roaring noise. He saw from the distance that these creatures were large, grey and pretty much irritated by his presence. They were much like trolls, only bigger. They were still quite far away, but one of them stopped and threw something. It was a snowball that flew nowhere near him.

Iolo was so surprised that he almost smiled. But this began to look like dangerous game, so he turned around and ran back inside. The long corridor seemed to be extra long this time, but he didn't hear anyone following him. Maybe those creatures were too large to fit in the corridor. At the other end of corridor he climbed steep narrow stairs and closed the hatch that had been hidden. Maybe it was hidden for a good reason.

Witches & Amazons

2009-10-10T12:50:00.000-07:00

The project can be compiled again after a short refactoring to some data structures. There were lots of changes, but the game didn't crash or anything like that. It's a promising sign... It's mainly the properties of creatures that were refactored. For instance it's now easier to add attributes, professions and anything like that.

You can't select the gender in current version, because all professions are male only. I don't believe in female knights or any of that crap. It's ridiculous. Females are weaker in Kaduria, just like they are in real life. I'm still planning to add female only professions and I have two in mind: witch and amazon. They fit perfectly in the mood of the gameplay and are less powerful than basically any of male character classes.

While I'm adding stuff (finally) I want to continue refactoring some parts. I want to do the same kind of refactoring to item class, because it's huge and will be easier to control with modular component type classes.

First snow

2009-10-04T02:18:00.000-07:00

Something cool about snow and winter. Pretty good snow storm for a first snow. There is always right feeling about snow.

I have almost finished the refactoring for monster class components which now are user defined types with lots of hidden data stored outside the class, but only processed by that class. The classes itself are very simple, having only few variables. The nice thing is that I have finally added some content. Yes. I'm actually developing the game content at the same time with this refactoring and it feels great after all these years of technical rewriting.

Data models

2009-09-19T09:45:00.000-07:00

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.