Sunday, 28 December 2014

20 years of development

Kaduria was started somewhere around 1995. The first date in source code is from 1996, but that was after I started to record the original date when the source file was first created. This means that next year Kaduria will turn 20. Some people even doubt if this project is real. The sad thing is that it is an actual game project. Then again Kaduria is relatively young roguelike project, ten years younger than let's say Nethack which I guess is still heading for the next official version.

The development of Kaduria can be split into two distinctive phases, from 1995 to 2005 and from that to this day. In 2005 I switched from procedural C to object-oriented C++. Looking back I should have started the project from scratch and not try to refactor the old C code, but back then I had so little knowledge about C++ (OOP) that I don't know if it would have been any better solution.

Since I'm not a programmer Kaduria was somewhat difficult learning process from C to C++. I didn't make lot of mistakes, but there were some. Even I'm not a very good programmer the biggest problem was (and is) the content and handling vast amounts of data rather than programming itself. I think C++ was a good choice for me, because I can work better with the concepts of OOP and create better source code with it by strictly following some of the rules of object-oriented paradigm.

What I find funny about this whole story is that even after 20 years I've not seen any games like Kaduria. It tells how difficult it is to create new kind of major roguelike games. Even creating an old style roguelike game has proven to be hard, because there are only handful of them created after Nethack and Angband which both represent the two archetypes of roguelikes.

The development of Kaduria has now become much more about managing the project than programming, but there are still some algorithms to write as well. How long it will take depends on many things, including how early I want to release the first version which no doubt will not be the final one.

Thursday, 18 December 2014

Walk routine

When implementing walking in Kaduria I've had my share of difficulties. The way I've broken it into parts is that you need to know when the player is in a corridor (or open area), where to turn in corridor when there are only one way to go and when to stop walking.

First two are kind of easy, although I did spend some time to write a routine to check when the player is in a corridor. What you need is first check if there are two walls on east-west or north-south sides. If not, you may still be in a corridor. To find out it you need to check 2x2 areas four times in the 3x3 box around the player and see if one of the areas is all floors. Then you are not in a corridor.

Turning in corridor is easy to determine, but when to stop is harder. I wanted the player to stop when either entering a corridor or leaving it. I still have to figure it out, but I think the key is in the way you take the first step. It should not be a part of the walking routine evaluation process at all, only the tiles after the first step

When to stop depends on many things, including what the player will detect (monsters, traps, dangerous terrain etc.). It's also silly to die in starvation when walking if you don't stop it. These signals increase the complexity of the routine which no doubt will require some work to complete.

I'm sure Kaduria will not have auto-explore feature. It's too much, it takes away the exploration. I think you should be able to navigate with pathfinding only between two places you already know.

Friday, 5 December 2014

Start small with data

I've tried to force myself to work at least an hour at a time when developing Kaduria and it seems to get things done (slowly but surely), rather than those times when you start the IDE, look at the code for few minutes and then exit.

Returning to case of professions it's kind of silly business, because professions are built on top of skills (mainly), but the thing is I don't even know what skills there should be in total and how they actually work. You can always throw in some generic stuff, but it can become something you don't need later. It happened with some professions which there is no need since I removed hobbits from the game.

As always you should start small with data (or design if you want a fine name for it). My inability to build a solid RPG structure has certainly given me more problems than I actually need. But I guess the situation is not hopeless. The development process in this area is progressing slowly from fuzzy ideas to something more tangible.