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.