Kerkerkruip design journal #7: progress and plans

Thinking up cool things and then implementing them is of course a mode of programming that is a lot of fun. In interactive fiction, it is also generally unproductive: you have a story to tell, and "cool things" are often mere side attractions that decrease the time you have to develop the core game. Luckily, for Kerkerkruip this is not the case. The core game is simple, and adding cool things to it is exactly what I should be doing.

Of course, some thought needs to go into the kind of cool thing one develops: having several hundred weapons with different cool stuff isn't much good if the player can only fight an identical goblin over and over. (Be assured: Kerkerkruip does not have a goblin. It does not have a giant rat or an orc either, and the skeleton is a temporary standard monsters slated for removal.) And although I believe it is important and cool to have "special" situations that only occur in a small percentage of the games, it would be unwise to spend most of your coding time on such rare situations and neglect the more common ones.

In the last few days, I have made a heat system and a rust system. The former developed from the thought that it would be cool to be able to heat up weapons, having them do more damage to enemies, but at the price of weakening them -- a heated weapon has a small chance of being destroyed whenever it is used in combat. But if you can heat up weapons -- by holding them into a forge, say -- you must also think about what happens to other items when you heat them up -- some might be immediately destroyed, others might melt, others might burn... thus was born my simulation-heavy heat system. Objects can be heated, and hurt the people who carry or wear them; objects can heat up other obects in their vicinity; and so on. A huge amount of applications suggests itself; and the system ties in nicely with the materials system I had already developed in order to make the difference between iron and silver weapons. The forge that turns an iron weapon into a deadly if somewhat weakened blade will immediately melt the silver weapon.

If there is one system I truly hate seeing in an RPG, it is equipment degrading through use. Training up my "repair" skill in order to repair my weapons and armour is not my idea of fun. But equipment degrading for a specific reason, that is something different, and this is where the rust spores come in. Once the spores of this obnoxious fungus enter a room, they start rusting everything in the room that is made of iron. Worse, rust spores spread through the dungeon: every turn, there is a small chance of them spreading to any adjacent rooms. I am planning on three sources for rust spores:

• With a very small chance, one of the rooms of the dungeon may start out containing rust spores.
• With a small chance, an unconnected room full of rust spores is generated somewhere in the dungeon. If the player digs into this room using the magical spade (or another means of creating new tunnels) the rust spores are out. (Other unconnected rooms that are sometimes placed in the dungeon are the Hidden Treasury, which it would be good to find, and the Eternal Prison, which it would be not so good to find.)
• With a very small chance, a closed container in the dungeon may contain rust spores. Opening the container sets them free.

So this is a feature meant to come up only in about, say, 5% of the games. Rust spores degrade weapons, but there are several things the player can do to stop this from happening -- turning them into silver, for instance, or heating them up. (At a later point, I'll probably add a way to close of passages, giving the player the ability to contain the rust spores.) And rust spores can be a boon as well as a bane: iron weapons used by monsters rust just as easily as those used by the player, and monsters made of iron... well, they won't be too happy.

I have drawn up a preliminary plan for the development of Kerkerkruip:

• Now - first week of august: go on implementing whatever sounds cool.
• Second week of august - last week of august: implement whatever the game needs most in order to give a complete and rounded experience.
• September: testing.
• September 30: upload Kerkerkruip to the IF Competition.

That's right, I'm planning to enter the IF Comp, for the first time. I find it hard to predict how the IF crowd will react to an IF/rogue-like hybrid, but, well, one doesn't need to win to make it worthwhile.

If you would like to see an alpha version of the game and perhaps give me some feedback on it, let me know at victor-lilith-cc (only those who can guess where the @ and the . go, i.e. humans, need apply!). But be warned that the game is in alpha state: there will not just be bugs but also unfinished features, no attempt at balance has as yet been made, and so on.

On inventory limits

I doubt Kerkerkruip will have an inventory limit. Given that almost all games which feature inventory also feature an inventory limit (the big exception being modern IF), it may be interesting to look at the phenomenon in a bit more detail.

Inventory limits come in several forms.

1. You can have a straight-up maximum amount of items which the player can have in his inventory. Common in early IF, but pretty unusual in graphical games and even non-graphical rogue-likes, which generally go for the second option, or a combined second/third option. It is used for weapon possession in some shooters, like Borderlands, Left 4 Dead, Crysis 2 and Duke Nukem Forever. (Some of these claims based on reading reviews.)
2. You have a limited amount of types of items you can carry, but can stack multiple tokens of the same type in one inventory slot. There may be a maximum amount of tokens such a slot can hold, and you may or may not be allowed to dedicate multiple slots to a single type of item. Examples are most rogue-likes and the classic Black Isle RPGs (Baldur's Gate, Planescape: Torment).
3. You have a maximum amount of X you can carry, and different items (or item stacks) come with a different amount of X. This X is commonly either weight (many rogue-likes, The Witcher 2) or space (Diablo 2). This allows the designer to make some items easier to keep in your possession than others, which can be used for interesting tactical design. Most often, however, such a system seems to be designed for 'realism': as far as I can see there are no deep game design reasons why a suit of armour takes up more X than a ring in Diablo 2 and Dungeon Crawl. It just does because that is 'realistic'. (In case it wasn't clear, I have a deep disdain for any design argument that invokes realism. When I see someone complain that it isn't realistic if you can just shoot a bow without having to buy or find more arrows all the time, I want to punch that person.)
4. Finally, there is a system where you can carry just a few kinds of items, and each kind has a specific maximum. This is almost universally used for ammunition in shooters, where you might be able to carry (say) up to 200 pistol bullets, 50 shotgun shell, 12 rockets, and 4 grenades. You cannot take more grenades by taking less shells.

Given that many games have inventory limits, what good do they do? Let's look at some of the bad reasons first. (I don't want to categorically claim that these reasons could never be good for any game, but it would have to be a rather special game.)

1. Inventory limit puzzles! Right up there with mazes, everyone hates the kind of old IF puzzle where you can take only 3 items with you through the portal, and you get stuck if you take the wrong ones. Or if you can return through the portal, it just adds tedium as you move back and forth to get new items. You'd have to think of a brilliant puzzle to make this kind of thing work again.
2. Realism. See above.
3. Giving the player decisions, and then punishing unwise decisions through boredom. If the player can stash her loot away, can go get it when she needs it, and the only (or major) associated cost is player boredom -- you have done something wrong as a designer. To a certain extent, a game like Dungeon Crawl suffers from this: you can't escape to get to your stash at every point, and there is an objective cost (hunger), but in general dropping stuff in a stash and retrieving it when you need it works. And is boring.
4. Making the optimal strategy really boring. In almost every game with shops that buy items, the optimal strategy is to pick up absolutely everything until your inventory is full, then returning to the shop and selling all items. Generally, this would mean that you are spending half the game travelling between the action and the shop. Nobody does this, instead only picking up the most valuable items; but the game does in fact reward you for doing the really boring thing. Not a good design idea.
5. Getting people to buy another copy of your game. You can artificially increase your inventory limit when you play Diablo 2 on Battle.net if you own a second copy of the game -- it allows you to log in as two players at once and swap items between characters. Really. Try getting a full set of set items without this trick.

 Now for some good reasons for having inventory limits.

1. Adding interesting tactical/strategic decisions. Do you take the scroll of teleportation for an easy escape, or the axe of fire for when you meet a hydra? Is that ring of poison resistance really more important than the boots of stealthiness? And so on. In order for there to be real choice, it is essential that items you do not take become unavailable: they either disappear or the in-game cost of retrieving them becomes too great. (If this fails, you get option 3 above.) It is also essential that you have enough non-hierarchically related items to make the decisions interesting: if one item is always clearly better than another, there is no decision.
2. Saving the player from becoming overwhelmed by choice. While having options is fun, having 328 options is not fun. If my inventory in Borderlands contains more than ten weapons, I'm starting to lose sight of what they all do, and I'll just stop using them -- there's no way I could go through all of them and choose the right one during combat. So thank god for an inventory limit that at least forces me to get rid of my weapons when I hit the 20 weapon mark. Otherwise, I would at some point face the daunting prospect of having to look through 1000 weapons and finding the best one...
3. Making the player use items. In general, if you are not risking permanent death, it is strategically best to save your best items for later. So the player who is implementing the best strategy might be saving up all the cool stuff, never using any of it. But if she hits an inventory limit, using it suddenly becomes the best choice -- and this often adds to the fun of the game. For instance, the best 'normal' weapon in Half-life 2 is the Overwatch machine gun. This gun has a ridiculously low ammo limit of 90 bullets. This means that once you hit 90 bullets, and you see some Overwatch guys (who will drop ammo for it), you ought to use this highly satisfying gun. If there were no inventory limit, you might try to do everything with your pistol, stockpiling thousands of machine gun bullets for who knows what bad-ass enemies the rest of the game might bring.

All of these good reasons, especially the latter two, are more applicable to long games than to very short games. In Desktop Dungeons or Kerkerkruip, there is no temptation to save your items for a later threat, because the final threat is right there, in your face. There is no possibility of being overwhelmed by choice, because you'll never have more than ten items. And given the small world of the game, it is not easy to see how you could implement a system where items become permanently unavailable if you don't pick them up. All right, I can think of some systems. But they wouldn't be very natural, and you'd only want to implement them if you were certain they would result in good tactical choices. In a game with few items, it is doubtful whether further restricting the amount of items you can use is the best source of more tactical decisions.

It should also be obvious that none of the three reasons applies to either puzzle-based or puzzleless modern IF. They only apply to games with repeatable actions and underlying game mechanisms. So it is clear why modern IF has moved away from the inventory limit.

On the design of Half-life 2

Yesterday, I finished Half-life 2. Not for the first time; I'm certain I played it when the Orange Box came out in 2007, and I might have played it before that as well. I remember I really loved it.

I loved it a lot less this time around, and in fact have major complaints against the design of the game. This is odd, because I'm pretty sure that the things I loved 4 years ago were the same things I disliked now. Let me try to explain, and I'd love to hear what you think.

Story and characterisation

The story is simply bad. There's a lot of SF nonsense about humans being oppressed by aliens from another dimension, and there's a being out of time who manipulates Freeman for purposes unknown. All very "mysterious", but the kind of mystery where you feel that the guys at Valve are not giving you a coherent story because they don't have a coherent story to give you. This feeling was certainly borne out by the two episodes that followed, which did little to clarify the situation.

Most mysterious is the design decision to give Freeman no voice. I'm not talking about voice acting, but about any means of communications at all. People are continually saying things to you, you do not utter a single syllable, and nobody thinks this is strange. What are we to make of this? Do they all know that you are a mindless automaton? No, they seem to treat you as a human being with emotions. So why are you not talking, and why are they not noticing? Freeman's silence makes it impossible to take anything in the game at face value; but then the game doesn't provide another value for you to take things at. We only have bewilderment.

I really don't understand this design decision. There have been other games with a they-talk-and-you-do-not approach, like Diablo 2. But that was different. (1) Since you trade with these guys, you are apparently communicating, even if the game doesn't show this. (2) You were still selecting options from a menu, even if they were as impersonal as "trade" and "turn in quest". (3) Since the game was less cinematic and the conversations were less about personal feelings, reactions of the protagonist were less important and less expected.

Freeman really freaks me out. I don't believe he is supposed to, but man... his silence is his only personality trait!

Gameplay

Many of the original reviews agreed with me that Half-life 2 didn't have a great story. So let's put that to the side, and look at the gameplay. Surely that is brilliant? It has everything: not just fast FPS action, but also vehicles and jumping and shooting down huge robots and summoning ant lions and getting the upgraded gravity gun and whatnot. A truly fast-paced game with lots and lots of variety.

And it's true. Half-life 2 does give us a lot of variety. A lot of creativity went into it. But, and this seems to me the game's central problem, all of it is the creativity of the designers. Nothing is the creativity of the player.

It starts with the extreme linearity of the game. There is exactly one path, and it is impossible to deviate from it for more than a few meters. Even where there was absolutely no reason to choose such a design, Valve insists on linearity. For instance, near the end of the game you are turning off generators in some kind of public building. It's a big building, you need to get to all generators, there's no story reason to do them in a particular order. But Valve blocks off all corridors except one with force fields, and then slowly turns off the force fields one by one as you shut down the generators. Why? Apparently just so the player doesn't get overwhelmed by having... a choice.

The linearity of the game is so ridiculous that you cannot help but wonder -- again and again and again -- why the Combine is sending soldiers at you when all they would have to do to stop you is lock a single wooden door, or put a single 70 cm high obstacle in a corridor somewhere. In fact, if they just did nothing, Freeman would get stuck in one of the many areas where you can only proceed once your enemies have blown up a wall.

Linearity wouldn't be so bad if Valve allowed us to decide how to take on the enemies. To a certain extent, of course, we can: we can choose to throw a grenade, or use our crossbow, or shoot with our machine gun. But in fact, this extent is quite limited. We are continually placed in situations where there is exactly one way to proceed, and all we have to do is pick up the designers' hints and act on them. Combine soldiers behind shields? You'll be given a bunch of grenades just before you arrive there. Lots of zombies coming through a narrow corridor? Three circular saws are lying on the ground at your feet. In fact, if you come across a cache of rockets, you know that you will have to fight an airship or a strider. This is true every single time. You don't see a strider and decide which weapon to use against it: only rockets will work. You don't see a strider and think of a way to get rockets: there will always be a cache of rockets nearby, and there will be no other way to get rockets. The designers have decided that it is time for a rocket-vs-strider battle, and therefore you are given a strider and rockets and the battle commences.

This design philosophy informs every aspect of the game. The designers at Valve have decided what you are going to do at each point of the game, and any significant deviation is impossible. You never duck into a small tunnel because it allows you to circumvent the guards; you duck into a small tunnel because it is the only way forward. You are never moving crates and floating barrels because you have had an interesting idea, you are moving them because you have come to see that the level has been designed in such a way that you must positions the barrels and crates in position X in order to proceed. If you find placable turrets, you know that you'll have to defend the area against lots of enemies. There are no exceptions. Perhaps worst of all, there is Ravenholm with its awesome anti-zombie traps: gas-and-fire traps, falling cars, rotating knives, truly brilliant. But every trap has been designed and placed by Valve. The player just pushes the on-button. You don't even have to lure your enemies towards it, because if there is a trap, Valve will of course have provided you with a couple of enemies who are walking towards it.

As I played, the feeling that I was just acting out a script given to me grew stronger and stronger, and I came to resent it more and more. Why don't these guys just leave me alone? I don't want to be fed the set-pieces you have thought up in advance; just give me a level in which I can move and do things and be smart. And if it's a pure arcade game in which I don't have to be smart, but just have to show my skill at shooting in the right direction, that would be fine too -- but do not force me to act out the smart ideas you have had.

Seriously, if you think that crushing zombies under a falling car is cool, design a game in which I can raise cars, lure zombies, and crush them. Don't design a game with a suspended car, some zombies wandering towards it, and a button which I can push to drop the car. Because that is me acting out a scenario you have thought up and imposed on me.

Let me put it another way. The Half-life 2 designers are like a bad kind of Game Master: the kind of guy who has thought up in advance with what tactic the monster should be defeated, who gives you the tools to do it, and who rules that anything else you try will not work. "Nope, your spell does nothing. But remember that wand you just found in the previous room?" To which the natural player reaction is: "Yeah, I remember it, but I refuse to be manipulated. You are trying to usurp my fun, and then you want me to congratulate you on your well thought-out scenario. Go away." That seems to be exactly what the Half-life 2 designers have done: usurp my fun, and then expect me to applaud them for their brilliant "design". I'm not applauding. I just feel manipulated.

Kerkerkruip design journal #6: silver weapons

Monsters and the undead

In Kerkerkruip, regular monsters are not only the main obstacles, but also the main opportunities: you gain powers by killing them, and absorbing their souls is the only way of healing. (If you kill a regular monster, you immediately regain all your health.)

This means that having more low-level monsters in the dungeon actually makes the game easier, because you can retreat from a difficult boss fight in order to kill a lowly monster and regain your health. But in general we want additional monsters to make the game harder, especially if they are generated because the player tried something risky, like opening that sarcophagus that may or may not contain treasure... and may or may not contain a monster. Therefore, we have soulless monsters which grant neither powers nor healing; and the most important class of those are the undead.

Undead not having souls makes sense and is easy to remember, and it is also easy for the player to recognise new monsters as undead, even though they might vary as wildly as vampires, mummies and liches. (None of whom are in the game right now, by the way. I only have one lonely stock skeleton in order to test things.)

Silver weapons - resistances and vulnerabilities

Having made undead, the urge to make a kind of weapon that is especially good against undead came to me immediately, and I coded up the silver property. Silver weapons deal less damage to non-undead, but significantly more damage to undead. Diversifying loot -- great idea! Right?

Wrong. As Ascii Dreams has told us long ago, there is something deeply wrong with the common system of resistances and vulnerabilities, where some monsters take more or less damage from weapons or spell of a certain type. It mostly devolves into finding out once what the best type of weapon/spell is to use against enemy X, and then using that type in the future. It gives us a one time 'puzzle', not a recurring strategic or tactical decision. Undead? Use silver. Boring.

Now I guess there is some value in simply diversifying loot, since it gives the player more things to look forward to, and more moments to relish. But resistances are about the worst way to accomplish this, as they finally boil down to a simple question of luck: if you do find a silver weapon, undead will be easier than in the average game; if you do not, they will be harder. There is nothing interesting about it.

Alchemy to the rescue

But what if you never give the player a silver weapon, but you do give him a means to turn a normal weapon into a silver weapon, permanently? In effect, this means ruining a weapon for normal combat, while making it better for combat against the undead. Is there a weapon you want to sacrifice for this purpose? If so, which weapon?

In the right circumstances, these can be interesting choices. They are not interesting if you carry around fifty almost identical weapons, because in that case, you are not sacrificing anything when you turn one of them into a dedicated anti-undead weapon. But in Kerkerkruip, an average playthrough should yield maybe three or four weapons, each with their own distinctive advantaged and disadvantages, useful against different foes and in different circumstances. Deciding to turn one of them into a silver weapon, less useful in normal combat, should be a relatively tough decision. And tough decisions is what we are looking for.

Thus was born the unguentum argenti, which I hope is Latin for "salve of silver", which can turn iron weapons into silver weapons. For this to be tactically interesting, all of the following conditions must be met:

• At any time, a player will have relatively few weapons, all of which might be useful in the future. (Or if a weapon will not be useful in the future, it will not be useful against the undead either.)
• The player does not find silver weapons, but must actively sacrifice a normal weapon.
• Turning a weapon into silver must be permanent and non-reversible, otherwise the decision becomes a no-brainer.

If at any time one of these conditions will cease to be true, I'll have to rethink the mechanic.

Towards generality

Thereis always the temptation to write code for the special case, rather than to write code for the general case, which might become useful later on. In Kerkerkruip I try to resist this temptation as often as possible, but in the case of silver weapons I succumbed to it. I just made a silver property which only weapons can have, and made a standard message for using the unguentum on anything that was not a weapon.

And then I though: but what if the player tries to apply the salve to an iron monster, of which I already have two in the game? Wouldn't it be lame if this did nothing? Wouldn't it be cool if by this (incredibly risky) action you could actually weaken those iron monsters? Asking the questions was answering them, so I started anew, and coded a more general materials system.

Now to think up some more good uses for it...

Kerkerkruip design journal #5: regeneration

Kerkerkruip is the new name of my roguelike IF. It is a literal Dutch translation of "dungeon crawl", except that "kruip" translates the verb "crawl" but not the noun "crawl". With all those k's, I think the word looks suitably evil and fantastic for my purposes, and it will be easy to find on Google. (Right now, searching for "kerkerkruip" gives only a handful of results, some of which are machine translations of the English dungeon crawl, and some of which are forum posts by me... I have been known to coin this word before.)

I have been quiet for some time, which may have suggested that I was busy with other things. That was indeed the case. But the past two weeks have seen a lot of development on Kerkerkruip again, bringing new monsters, new items, new 'systems', and in general bringing us a lot closer to an playable alpha. Most of the things I could post about would be just me being joyous about implementing new things -- there is a joy in the act of creation, and especially in the act of writing code which actually works when you play the game -- but I doubt my audience would enjoy such posts. On this blog, I want to take a step back and talk about design from a point of view that is a little more detached.


So today I'm going to write about a game system that I implemented yesterday, and which I am going to remove from the game as soon as I finish this post. Not because I tested it and it didn't work, but because I suddenly realised it cannot possibly be compatible with my design goals. Today's lesson, then, is to always keep your design goals in mind.

The system I'm going to remove is a simple regeneration system: depending on your regeneration rate (which is normally 0), you will regain health during every round of combat. With regeneration 1 you regain 1 health every round, and so on. Some monsters would have a regeneration (as the trolls in D&D had), and the player would be able to gain regeneration by using certain items or defeating certain monsters. Pretty simply and pretty standard. You can do fun things with it, though; I was already thinking about items which give you regeneration but lower your total health.

But what are some design goals of Kerkerkruip?

• The optimal strategy should be a fun, fast and risky strategy, not a slow, safe and boring strategy. (Players should not be rewarded for doing boring things. None of that old D&D crap where the optimal strategy was to search for traps in every room and passage, and sleep after every encounter.)
• Combat should be fast and exciting. No protracted, seemingly interminable battles.
• Games should be quite short. (These goals are obviously closely related.)

These design goals are not well served by a regeneration system. For if the player regenerates, the optimal strategy is shifted towards dragging the combat out: in a longer combat, one regenerates more health, and thus increase one's advantage over the monster. On the other hand, if the monster regenerates, combat will become more tedious. It might start to resemble those ridiculous boss fights where the developers could think of no better way to increase the difficulty than by giving the boss 10.000 hit points. And if both regenerate, we might get into the situation where the average damage dealt each round is less than the average amount of health regenerated... which is the worst possible case, as it would make the fight literally interminable.

Given all these disadvantages, it is probably best to just kick out the system.


(I am experimenting with monsters that can heal other monsters, but that is a slightly different case. Suppose a group of monsters consists of -- using MMORPG terminology -- a tank, a fragile DPS, and a healer. If the healer is good enough to significantly slow your killing of the DPS, you should take out the healer first. Thus, the optimal strategy avoids dragging out the fight too much, and this strategy is always open to the player. By the way, "DPS" in the meaning of "a character with high DPS" is the worst noun ever.)


P.S.
It's not as if I'm throwing away a lot of work. This is the entire regeneration system:

A person has a number called the regeneration. The regeneration of a person is usually 0.

Every turn (this is the regeneration rule):
    if hate is present:
        if the regeneration of the main actor is greater than 0:
            heal the main actor for the regeneration of the main actor health.

But I was making a general point. :)