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.