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.

Stone wall time

As with Teemu, Kaduria has hit the stone wall where development is slow and somehow painful. In fact with Kaduria this happened in 2005 when I started the rewrite. This is something where good planning can rescue a lot, but you know, like, what plans? Never had one.

My day job is taking its toll. When you stare at computer monitor for 7 hours it's not that tempting to continue that same staring when you get home. It cuts the development time no matter what I want.

Kind of Magic

I had difficulties to decide what to do with magic. At some point I decided to remove magic, but there was problems with certain objects that were clearly magical. Today I suddenly realized what to do and I want to announce that there will be magic in Kaduria. However it's not going be like typical D&D magic system.

Not only it will be great fun in gameplay (let's hope so) it will also give me free hands to do anything I want with magic. The best thing is that I don't even have to create a complete magic system which tend to become like jack of all trades and largely dictate the gameplay, making magic an essential power to win the game. It will not be so in Kaduria.

Of course, and once again, I can't reveal the details.

Technical difficulties

Many problems in the source code are in a form of a logic problem. There is a bridge problem which is introducing facing when the engine has no support for that for game objects. You can cross the bridge when walking but how about when swimming and trying to move on a bridge? It should block moving, but there is no default way to prevent that since bridge has no blocking value. I was able to solve that by checking when the player is swimming and block moving when there is a big enough object in that space. I guess it's not a perfect solution and may cause some unwanted side effects.

Another example is the pit problem which has troubled me quite a lot and I have mentioned it earlier. You can push a movable in the pit, but you can't push anything on top of that movable or you shouldn't be able to walk across the pit without falling into it. Then again, you should not be able to be on same spot with a large movable object. It's somewhat difficult problem to solve without producing strange side effects.

Last two months

I noticed from done list that last item is from two months ago. Of course I've been programming Teemu for a while, but it's not cool to have too long pause from the development of any project. Since I went to work I have less time for programming, but I think the amount of time is not the issue. I think it's not the issue for anyone unless something really takes all your time.

As I mentioned in Teemu's blog it's mostly the attempt to create good source code which is taking time along with the design of role-playing system and some other aspects of the gameplay. If you don't know how the rpg system works it's impossible to program it. I have some kind of idea, but it's not making things ready. The worst thing is that you need to cut down the amount of stuff you think you were planning which can lead to a game that is no more than a typical roguelike. It's not that next generation game you were planning. It may even suck as a game.

At this point I don't even need to hurry up. I have all the time in the world. I just have difficulties to use that time to finish this project.

Size matters

Could not really follow my new development strategy. It was too harsh. I try to code as much as possible though and spend less time trolling on internet.

One of the difficult things in item data (and in generic level) is the size. I'm using relative abstract sizes for objects but even then editing data is hard: how to determine the size differences between items? For that purpose I made a visual debug routine which is simply showing items in different abstract size groups. That way I can visualize which items should belong to which group (instead of looking at the item data and get confused). Sizes are relative between object types so a big item is smaller than big monster.

What I hope to achieve from abstact sizes is still a good result to calculate stuff like weight without actually adding any static data for weight itself. The weight is calculated from material and size, plus maybe some other things like item type.

New development strategy

Back a while I tried to spend every other day programming which didn't work at all. So now I made a new rule that when I want to troll internet I first have to code something. Anything, even just refactor one function. I think it's actually working. I get stuff done and I can also troll internets. Even before I wrote this entry I refactored hidden item creation to check out if there are matching amount of places with intended amount of items.

Independent mask map

I'm using a mask map to mark generic tile types to mask values. The mask map is independent which means a mask value can be different than the usual value for that tile type. I think it's actually required, because rooms and caverns are different yet they of course share common tile types so there is no way to link masks to tile types itself. When I look at how room masks are determined it's a small miracle that it actually seems to work - in its own way. Room generation is still a task that needs work to be done, mostly in interior design but also in big complex room types.

Wall design

It's odd that I didn't think of this before, but I needed a design for walls that are used in level themes. It's a distinctive difference in the way I'm thinking game design now and then. So I wrote a design for walls which was a good idea, because now I finally know what types of walls I really need. Before this kind of thinking you just throw in some stuff without a clear plan how and where to use different types of walls. But now I have divided walls into 13 types which some are special walls like what nornokians made in Snow Top. They made stone walls from large, well-fitting granite stones. A remarkable skill that was lost with them.

Corridor end tunneler

Rather than trying to do anything sophisticated I decided to use a special routine to tunnel away the walls in those dead end corridor situations. It's actually working nicely, because dead ends are present only in about 50% of levels and even then in 1-4 of rooms. The room is then marked as "broken" so nothing special is generated in that room and it may actually get a special room type where it looks like someone broke the room (broken items etc.)

What happens next with rooms is something I want to keep as secret, but in theory everything gets more complicated. I'm also going through the rest of level generation in hope to get each component present and ready for testing. I want to get level generation in a state where I can start to add special features without breaking the level structure.

Dead end corridors

The first step to fix the dead end corridors was writing a routine that finds them. The rules are actually simple, you need a corridor, a room wall and no doors around a circular area to find a spot.

Also, the routine excludes walls with doors, but of course this doesn't work with round rooms, because the mask value for diagonal walls is different than the facing of main directions, because it has to be either one of main directions (walls on right and left are facing east and west, but they could also be facing north or south). Then again, the shape of room is also saved in the room data which can be detected and added to the algorithm. The spots are marked with lava tiles. Corridors running along with the wall get more than one hit, but they can be exluded by creating only one door or checking if the room is connected to that spot with good old flood fill check.

Testing connections

Fixed corridor corner fix, now it removes only the tile next to room wall. Then I started to test the level generator. Usually it works fine, but sometimes rooms and corridors have a bad alignment which makes impossible for them to connect.

Red circles show problem areas where connection has failed for various reasons. Sometimes there is another room blocking the way, sometimes corridors run at the round part of the round room. How to fix these? It's a good question. One possible way is check room connections, because rooms are objects and their data includes the number of connections (doors). So, a room with zero connections has obviously failed. Those rooms could then be connected with a special routine starting from a random room place and travelling from there with a special corridor routine (using path finder to find another corridor).

Corner fix failure

Fixed the flood fill which now correctly finds double doors to rooms by checking the connection with flood fill to make sure there is a connection per corridor and/or cavern. However the corner fix routine doesn't work that well.

I've painted red circles around the problem areas. The round room fix fails completely and that lower corridor is not connected at all. It just doesn't figure out how to create a clean entry through that wall. Also with that rectangular room the fix does work, but it's carving extra holes through corridor walls. A good way to approach bugs like this is use pen and paper to visualize the problem and create rules for the fix algorithm.

Flood fill failure

It's obvious that the flood fill search fails to detect nearby double doors.

As a debug measure I made the filler paint lava tiles where it did visit. The result was kind of interesting. Looks like it's quitting after couple of tiles. It's possible that the algorithm is confusing me, because for me even simple algorithms are hard to understand or visualize.

Corridor finder improvement

I think the bug in corridor corner fix was caused by a wrong call order of routines which made all corridor walls look like corners! Simply calling transform terrain first seems to correct most bugs in that area, as this new screenshot shows:

Still the problem is how to connect rooms to caverns (thick corridor here). It could be nice to avoid too many connections so it means checking cavern areas with flood fill to see if they are connected. Tiles not connected would be listed so you would need to go through them and check for room walls or nearby corridors to join them in the level structure from one (or more) points to avoid hacking away all room walls (if there are a lot of cavern areas around rooms).

Round room corners

The corner fix routine fails when trying to find a door place in round rooms:

One solution would be allowing entrances to round rooms only in four main directions, because there is a straight wall section on each side of the room. Another solution would add extra walls to room to fix broken walls. It might be even easier routine to do, because the areas to check are connected to doors so it would be simple to spot the areas by going through the door list and checking tiles (or double doors) around them.

Dungeon generator examples

Testing with three rooms it's already clear that there are problems.

Doors are not created when there is cavern outside it. It's easy to fix I guess, but might cause confusion if two separate caverns are next to the room. The possible solution to that is giving caverns also a unique mask id.

Here is another run with the same level theme. The long narrow corridor is actually a passage, which is a special kind of corridor. It seems to have problems to turn around without backing up and generating extra dead end blocks, but it should be easy to fix.

Return to the caves

I have changed my perspective from tweaking the source code to more practical development. It means I could now get stuff done. I've started from level creation which has lot of problems. The building blocks are there, but needs to be connected to create levels the way I want. I think the level generation has been difficult to me, because I was thinking in too complex way. Creating a good, consistent town level is still a complex task, but anything other than that is easier. At least I hope so.

Checking level code

Sometimes when looking at the source code everything seems a huge mess, but then there are moments of clear vision of how to proceed. I guess today was more of that clear minded side. I'm going through functions of Level class which is huge, possibly the biggest class in the project. Most of the problems come from the fact that stuff depends on other stuff. That's why I think it's essential to learn how to write modular code (as much as possible) because then different parts can be implemented without having to worry about how compatible they are or will be in the future (when some other part changes its shape).

It's not that hopeless. The source code is getting really solid actually and maybe some day everything will just fit together.

Rooms and houses

Working on level themes and needed a special type of room. When I looked at the room routines there was room for improvement. Rooms like many other parts of the source code have simpler data type classes like Room_Type and Room_Shape. Placing decisions (data) in small simple data type classes has been really good for the generic readability and keeping the source code clean.

The actual Room class is quite bad actually. It's a result of not planning the stuff clearly. However I think it will be useful when problems are fixed. It helps to think rooms as single units that can later possibly form houses. For now I have to think only how singular rooms are created and connected. There is plenty of things to solve and there are lots of room types with all different kind of creation methods.

Randomness

The requirement of randomness is one of the big questions in roguelike development. How random you can or should get? When you look at a classic like Nethack you'll notice that it's not that random after all. The structure of the game world is quite static with designed locations that don't often change.

I've struggled with the same requirements myself. It's difficult to produce random content and still create something that's themed. Like level themes for locations in the dungeon. It looks like the best you can do is offer some random changes in the typical theme content. But you simply can't get too random in the context of the theme. Dry sand levels can't be populated with winter wolves or some other cold environment creatures, if you try to stay in theme based content.

Then again, does it have to be that random? Well, mainly it does. There are good examples of static content that quickly becomes tedious if you replay often. Something like the main "village" in Angband/Moria or Terinyo in ADOM. Maybe there could be couple of different starting points to reduce that kind of dull, repeating experience. Something like several entrances to the dungeon, each leading to different part at first. Or maybe you could sometimes start from deeper levels with better equipment, like in middle of the story.

Space

Spring seems to be slow time for roguelike development. However professor Biskup is working on ADOM 2. I tried early versions and now waiting for some kind of final release with stuff. One thing I noticed is the size of levels and places. This is something I have thought, because many modern roguelikes have big levels which isn't a good thing per se.

Old roguelikes got it right, because the console had limited size, like 80x25 or 80x24 characters. The size of level has a big effect on the gameplay. Not only it makes navigating nicer (less keypresses required to move around) but it also makes tactical combat more focused, because things happen faster in smaller space.

Of course you can have the best of both worlds. Big levels can have their own purpose sometimes, but I'm planning to keep regular levels of Kaduria quite small. Tweaking the size of a particular level theme is a science of its own.

Game object design

After a brief moment with Brick Atelier I've returned. With some game objects it's the matter of creating content. Good old content, nothing beats that. How detailed that content is largely sets the release date. Currently I'm trying to design graves. Not only there are four races that bury their people, but also several professions that possibly should get buried with items that can be excavated. There are gravestone signs that reflect the race and profession. So it can be a lot of content if you go the detailed way, which I try to avoid the best I can. Projects like this really teach you to start small and stay small. Well, maybe there will be more detailed content later. Much later.

Day off

The other day I was trying to do something, but instead spent the whole day on internet trolling forums. If you want to get anything done it's not going to work like that, so I have decided to stay away from internet every other day. In my day off from internet I actually had to think how to spend my time, because it wasn't wasted on trolling. Fixed eight bugs in Kaduria which is phenomenal. But it's not just programming, you have more time to practice guitar playing or do some other real life stuff.

Java button

Sidetracked for two days with a small programming project (I call them "java button" projects) and somehow lost interest to programming. It will pass and I have already been checking out what to do next in Kaduria. It doesn't look very promising. Most things to do are between hard and difficult. I'm getting back to the issues that need serious thinking and game design instead of simple programming to make stuff work. One strategy I have been thinking is work the way from player's point of view to downward in the structure. In other words make the player's actions top priority and monkey them down to other actors of the game.

It's a trap

Item class has only 12 functions left to complete. Some items can be trapped and for a long time traps gave me constant headache in the way I was trying to implement them. The confusion was caused by the type of traps. Some of them are actual objects hidden on ground, while others are a part of another object. Also, I had difficulties to understand how to implement the effects of traps. If I can handle traps then the entire object system is much closer to be complete, because traps are one of the unfinished parts that affect several object types.

Testing

Testing the game while creating it may be a good idea in most of cases. However I now think that there is a place and time for testing, too. Kaduria has seen a lot of refactoring and testing that was done then was a huge waste of time after all. The funny thing is that I never questioned my style of programming until now. I also have a habit to compile maybe too often. It's another way to waste time, since in most of cases compile happens without errors. It would be obvious even after longer sessions of writing code.

These two, testing and compiling, are things that I try to cut down to stop wasting time for no reason. Testing in this state of development should be done actually when the gameplay is more or less ready.

Here is the new gameview I was talking about earlier:

Two sections of right side area still missing. I'm thinking of leaving the "mini"-map (it's a debug version routine), but without object list (or show only monsters).