Weapon research

The RPG system of Kaduria is more physically based. It means there is more research to do with weapons and armours. I like doing research, but I don't want to dig too deep into that stuff. However it's interesting to realize how little we modern people know about medieval type weapons. Why they were like that and how they were used. In fact I think even actual scientists don't know everything yet, because the practical knowledge was lost when firearms were invented.

The techniques that were used had been developed during thousands of years. Imagine all that fighting and the history of weapon development to become better at killing. It's so revealing and tells a lot about us humans.

When I read about medieval weapons there is always something I didn't know or realize. Let's take an example of arrows. I knew they have a pointy end, but I didn't realize there were so many types of heads. Each of them had specific use. What I'm going to do is take essential head types and model them in Kaduria. It's something else compared to just having a regular arrow.

Item class design

Item class hierarchy is divided into three layers: main class, item datatype and subtype datatypes. The main class is almost ready actually, only trap handling is undecided. Item datatype is the main class for data-driven section of the whole system. But the interesting stuff happens in subtype classes which now are under heavy development. Data-driven approach is something that is not only modular, but it also creates a kind of order in programming which I find helpful.

Some subtypes are already there, but I think most of the subtypes need a dedicated class. In fact many parts of the item system is still unfinished, but subtype classes are very similar to each other and it's quite easy to create them from technical point of view. The difficult thing is the game design in them. What properties items have? How you can use them? Things like that.

Decisions in game design

One of the big problems in development for me is the game design. I have a habit to leave some things later and then realize it has been two or three years since I tried to solve some design problem. In roguelikes there are lots of problems related to RPG system and how to create interactions between objects. I think we all would like to create complex interactions, but it requires more generic and able engine. Limited actions are much easier to do, but it's including a decision to create a limited gameplay rule. I know that I have to make those decisions or this game will never be released.

45K

The room interior development is increasing LOC fast, it's now over 45 000 lines. Room interiors are interesting and fun to create, because there are lots of options to add in any room type and you can really start to think where all those game objects you invented earlier can be used. I have the basic creation tools ready so it's also quite easy to work with rooms. There is a lot of source code needed for special rooms like shops and other more complex types. However I don't want to limit my imagination here but create all the room types no matter how many is required.

Blueprint

Another piece of tech taken from Teemu is Blueprint class. It's plotting pre-defined (non-random) shapes of structures in the level or mostly inside rooms. Kaduria's version of Blueprint will be more random including various game objects such as lamps, doors, plants etc. But it's practically the same simple routine. Sometimes it's better just use static structures and admit that generating them with some sophisticated routine is too hard or would require more work than you actually need to make it convincing. It's also possible to use several static shapes and randomly select one of them.

I haven't yet solved how to connect pre-created important rooms to the rest of level but I would imagine it's not that hard. Also I noticed that my complex corridor finding routine is smashing through room walls so it's another problem to solve.

Special theme rooms

Some level themes have important rooms which has to be created. I was thinking of returning a room type from the order of rooms made, but it failed. The reason is the way I'm creating corridors first, then rooms in the center of corridor nodes. Sometimes nodes are too close each other and one (or both) of the rooms is not made. This kind of creation makes it impossible to make sure that the first room theme is created.

So it's back to planning. I do have special rooms which are created after other room types. I had planned it for shops and rooms like that. But it can't be used in this case, because important rooms must come first and everything else created around them. In best case scenario I'm able to use old special room routine, just place it first before other rooms are created. All that and more will be revealed in the next episode of Kaduria - The Blog.

Annual LOC report

This LOC chart is recorded from random points of the last year. It shows some kind of progress in lines of code, but is not equivalent to real progress (which is slower). The problem areas in the source code are now kind of distilled to a number of difficult puzzles I have to solve one at a time. It's slow, slower than any regular game development. If there is one thing I'm happy about it's the extremely low number of bugs, thanks to my ridiculously strict and ultraprofessional programming style. Unlike many developers I don't have to waste my time fixing bugs, but I do have more problems with algorithms and larger program flows than any regular math-aware programmer. In the next exciting blog text I'm hopefully going to tell good news about level themes.