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.

Gameplay

A growing number of features I'm now programming are more of content than engine. It does feel a bit strange after years of trying to get the engine in some kind of condition. Trying to come up with clever solutions to how content is created is even harder than programming the engine, although in roguelikes those two are depending on each other.

In following days, weeks and months I try to concentrate on big picture which mostly means open issues in level generation. How to create level themes that actually have a theme, but still offer enough variations and surprises?

Crash

I was playtesting Kaduria and suddenly it crashed. It's so rare these days that I wanted to report it here. It happened during a call to strlen function:

I think it might have been in the call stack directly, but I don't even need it to find this bug, because strlen is used only six times in the source code and two times in message routines (other four are debug functions) so it in the message class, possibly quite easy to find.

More is more

And bigger is better. Noticed by an accident that big fonts are cool. The XP computer @ job couldn't anti-alias small fonts so I had to try with size 16 or bigger. Actually I like the way you can see only small fraction of the source code compared to small fonts. It's somehow better.

This setting has Monofur 18pt font. Couple of other monospace fonts also look great in bigger size. I think it's easier to read code when there is less information on screen at a time.

Even with 18pt font the editor character size is 97x26 which is amazingly close to old school 80x25 characters of a console or EGA screen.

Stylish

There is now a style for walls etc. for each builders that went to Kaduria and constructed their own parts of the dungeon. Then I realized I also need some kind of style for each main or basic level theme, starting from the type of bedrock for a level and anything that can be stored into the main theme. Main theme will take away some data from the actual level theme, but as I said earlier it will introduce another class to maintain. However I think breaking data into smaller, possibly more manageable pieces is better in a complex roguelike.

Meanwhile I think I'm over some kind of depressing feeling which disallowed me to program Kaduria efficiently. When I think the reasons to do this in the first place they are still there.

Data-over-driven

There is a lot of data-driven stuff in Kaduria. However even such a good idea can be ruined with poor design. I wouldn't call it a failure in this case, but there is data that doesn't have a clear structure. Recently I got an idea to create styles for terrain tiles so each type of wall could be a part of some style (dwarven, ancient, elven, etc.). The style is a great target for a data-driven type, because then you could retrieve all sorts of objects that mostly belong to that style.

The problem is that style class would override other data already set up for level themes. It's a layer of data on top of existing data. Another problem is to determine how much and where each class or system is used. The style can't be same as level theme, in fact there could be several styles in one level.

I've had similar problems with main type of object data classes. It reduces the amount of data, but then you have two classes to maintain, with kind of dialog between classes that can be difficult to create.

I think styles is something that is required after all, which is yet another example of undefined design that should have been there.