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.
Sunday, 28 December 2014
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.
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.
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.
Saturday, 22 November 2014
Professions redesign
A while ago I decided to remove other races than human from playable characters, but it doesn't make a lot of sense. Also you can only play as male character. But now I have new plans to distribute professions to several humanoid type creatures and also for different genders. The idea is that you can't play let's say a female knight. It's silly and I hate games where gender is simply a choice for "equality" reasons.
Female professions will be exclusive for females and I think they are going to be more difficult if not even iron man (the irony...) style characters.
Well, the actual news is that I've finally started to complete the gameplay features. I have a "plan" for almost everything, but as in case of professions they have to be complete with all features. It's hard work to get that done (and I hate working).
Female professions will be exclusive for females and I think they are going to be more difficult if not even iron man (the irony...) style characters.
Well, the actual news is that I've finally started to complete the gameplay features. I have a "plan" for almost everything, but as in case of professions they have to be complete with all features. It's hard work to get that done (and I hate working).
Thursday, 30 October 2014
Regaining motivation
I took couple of weeks off from programming, partly because I was a bit depressed during the process when I knew I was becoming unemployed. But somehow programming is my "safe place", it makes me enter a state of mind, just like when I'm painting. So it's easy to return even I wouldn't care so much about other aspects of game development.
I have mainly tweaked the source code, trying to improve some technical things. I think it's important to maintain the source code in language level, because it then makes easier to create the actual game content. One thing I've noticed is that I don't use inheritance as much as would be possible. I realized it could be used relatively safely in type classes of game objects. They all share common functionality which could be put into a base class without breaking anything. The problem with inheritance is when it actually requires large scale changes. Then it may be a lot of work for no actual reason other than to improve OOP paradigm which in itself doesn't mean anything in context of game design. No one knows or cares what kind of paradigm was used to create the game.
I have mainly tweaked the source code, trying to improve some technical things. I think it's important to maintain the source code in language level, because it then makes easier to create the actual game content. One thing I've noticed is that I don't use inheritance as much as would be possible. I realized it could be used relatively safely in type classes of game objects. They all share common functionality which could be put into a base class without breaking anything. The problem with inheritance is when it actually requires large scale changes. Then it may be a lot of work for no actual reason other than to improve OOP paradigm which in itself doesn't mean anything in context of game design. No one knows or cares what kind of paradigm was used to create the game.
Friday, 10 October 2014
Mental note
The development of Kaduria has long been reduced to problem areas. There is a list of missing features and bugs, but also source code comments starting with note: as a reminder for later coding sessions. Which may come after a long, long time.
Fixing problem areas is often extremely tedious, but something you have to do. I spend way too much just looking at the problem and trying to think a solution when better approach is simply hack it as fast as possible. Things get worse if you have a mind of a perfectionist. Maybe the biggest philosophical lesson I've gained from roguelike development is trying to let it go and make something working. You can always improve it later when the basic stuff works.
Development is sure going to be "faster" in context of Kaduria now that I'm again unemployed. Maybe something will actually happen, because even I am getting a bit tired of this project.
Fixing problem areas is often extremely tedious, but something you have to do. I spend way too much just looking at the problem and trying to think a solution when better approach is simply hack it as fast as possible. Things get worse if you have a mind of a perfectionist. Maybe the biggest philosophical lesson I've gained from roguelike development is trying to let it go and make something working. You can always improve it later when the basic stuff works.
Development is sure going to be "faster" in context of Kaduria now that I'm again unemployed. Maybe something will actually happen, because even I am getting a bit tired of this project.
Wednesday, 1 October 2014
Procedural degeneration
I've degenerated back to procedural programming! Well, not entirely, but while I was reading stuff about functional programming it made me rethink some things in C++ and OOP. Classes are ok, but sometimes there are clumsy situations where you simply create a class without member variables (data) and use it as "empty" instance, then access functions to do something. It took some time for me to realize that these strange functions are actually... functions. Or "procedures" as in procedural paradigm.
Of course "pure" functions have been always lurking in C++ in form of the standard library (functions like printf etc.). But you can also write your own functions and use them in classes without breaking OOP principles. Functions that are good candidates are generic and algorithmic, they take in simple parameters and return simple values. It's possible to go further than that, but then it starts to be too much like traditional C with all problems it has.
In C++ context it's great to reduce some of burden from classes and also avoid copying source code in member functions when you could use external pure function in all similar places. If those functions are generic enough they can also be reused in other projects really easily, because they don't have any dependencies to the current project. So I've started to create a small function library for Kaduria (rather than creating any game content..) and already removed one of those clumsy empty classes. C++ has the neat feature of closing stuff in a namespace. I've named it "Function" so functions are called as Function::do_something(); which is not only clearly showing that the function library is used, but also protects from name clashes.
I think the function library will stay rather small, because OOP doesn't easily become functional, because member functions work closely with class data and if you try to make it generic function style it probably wont look nice.
Of course "pure" functions have been always lurking in C++ in form of the standard library (functions like printf etc.). But you can also write your own functions and use them in classes without breaking OOP principles. Functions that are good candidates are generic and algorithmic, they take in simple parameters and return simple values. It's possible to go further than that, but then it starts to be too much like traditional C with all problems it has.
In C++ context it's great to reduce some of burden from classes and also avoid copying source code in member functions when you could use external pure function in all similar places. If those functions are generic enough they can also be reused in other projects really easily, because they don't have any dependencies to the current project. So I've started to create a small function library for Kaduria (rather than creating any game content..) and already removed one of those clumsy empty classes. C++ has the neat feature of closing stuff in a namespace. I've named it "Function" so functions are called as Function::do_something(); which is not only clearly showing that the function library is used, but also protects from name clashes.
I think the function library will stay rather small, because OOP doesn't easily become functional, because member functions work closely with class data and if you try to make it generic function style it probably wont look nice.
Subscribe to:
Posts (Atom)