Victor Gijsber’s Kerkerkruip is a remarkable undertaking, combining two well-established and highly dissimilar forms to deliver the interacting systems and randomness (not to mention the addictive quality) of a roguelike in an immersive IF environment. If you haven’t played it, you should get around to doing that.
If you have, then you have been impressed by its depth, and you have probably wondered how such a game is possible. I did too. So I interviewed the author:
I am required by International Interview Law to start out by asking: What inspired you to make a roguelike in text?
Many people in the Interactive Fiction community – though the percentage is becoming smaller – started out playing the old commercial interactive fiction games. My own background in computer gaming is very different, with role playing games and strategy games always having made up the majority of what I play. So even though I came to IF mostly from an interest in interactive storytelling, as The Baron and Fate testify, I guess it was only natural that I wanted to experiment with tactical RPG mechanics as well. This led me to write ATTACK as a basis on which tactical combat IF could be built.
I started writing an ATTACK-based RPG several times, but I never got very far. It not only takes a lot of time to write a story-heavy role playing game, but you also need to alpha test the game much more than a typical work of IF, because you need to balance the combat system. And the problem is that playing the same identical fragment of game over and over again is not a lot of fun.
The idea of writing a short roguelike game almost came to me as a revelation. You don’t need insane amounts of content to have a complete game, so it seemed feasible for a single developer to write in a relatively short time; and because of the random generation, it is actually fun to test even for the author. And indeed, writing Kerkerkruip turned out to be very enjoyable, and something I managed to do in about six months. (Although ATTACK was already finished when I began.)
What are your favorite roguelikes? Which ones informed the development of Kerkerkruip?
I have played only two of the major roguelikes, Nethack and Dungeon Crawl Stone Soup. I found Nethack far too wilfully opaque, but I have really fallen in love with DCSS. Their design philosophy is very sensible, and the game is just plain fun. With an online graphical version now available (tiles.crawl.develz.org/) it is also about as accessible as a major roguelike is likely to get.
The game that was most instrumental in getting me to write Kerkerkruip was Desktop Dungeons. Not because of any particular mechanic, but because it too is a very short roguelike, and it made me realise that this was a possible genre. So it didn’t inform the development so much as set it in motion.
What inspiration did you draw from other IF?
In terms of specific mechanics, I don’t think I took a lot from earlier IF. IF gameplay often centres on some combination of meticulous exploration, puzzle-solving, developing story through conversation, and making choices with narrative impact. None of these play an important role in Kerkerkruip. You don’t want a game where you need to type “look under rug” every time you enter the room with the rug, for instance, and you certainly don’t want the same puzzles and conversations coming up again and again. So while my use of the medium has of course been informed by playing many pieces of IF, the mechanics of Kerkerkruip owe little to that tradition.
How long did this project take? Was everything as difficult to code as it looks?
Kerkerkruip took me about 6 months, perhaps 4 months of which could be designated as active development. As I said, ATTACK was already finished before I started; while only a small part of the total amount of code, it was the most fundamental and difficult code. (ATTACK messes with the turn sequence in several big ways. There’s nothing like it in the Inform 7 Recipe Book, you can be sure.)
In general, the coding was not very difficult. Most of it is just pretty straightforward Inform 7 code, with heavy use of rulebooks. Some of it was more difficult, but I got help several times: the scroll identification code and the automatic saving mechanism, for instance, were mostly written by other people.
Of course, Kerkerkruip is mechanically much more complicated than a standard piece of IF. Relative to other games of mine, such as Fate and The Baron, it was certainly harder to write. (Though The Art of Fugue wasn’t easy either.) When you write a game like this you need to be very methodical. You must resist the temptation to write special cases – something we normally do all the time when programming IF – and take the time to write general code for whatever behaviour you would like to see in your game. If you don’t do that, the game will die in a horrible mess of bugs.
What was the philosophy of combat-in-text that led to the design of your ATTACK extension? How did you hit upon the act/react system?
Much of the tactics in role playing games, including roguelikes, is intimately connected with representations of space. The distinction between melee and ranged combat is an obvious example, and so are the different ranges and areas of effect of spells. Running away, charging, doing as much damage as you can before the enemy has reached you – those are all essential elements of most combat games.
When I started thinking about combat in IF, one of the first things I realised is that our medium is really bad at representing space. But, being turn-based, it is really good at representing time. If you want tactical combat in IF, you’ll have to give up all the forms of tactics that are based on space, and you’d better introduced some that are based on time and turns. That is where the concentration mechanic comes from, with which I’m rather pleased; and I think you’ll be able to see this thinking in some of the other parts of the design as well.
Another thing that was very important to me was to make sure that you never get into boring, repetitive situations where damage dealt per turn is so low on average that the fight just goes on, and on, and on. Here I suspect I took my cue from the indie pen and paper RPGs that I used to play a lot: if things threaten to get boring, escalate! The tension mechanic is an automatic escalation that raises both the stakes and the probability of resolution.
I’m not sure what I thought when I implement the act-react system – though it must have been something profound, since it was one of the hardest parts of ATTACK to write – but I suspect I just thought it would feel more intense and interesting. It’s like the gamemaster saying: “He runs towards you with a huge axe raised… what do you do NOW?” And you can stand your ground or run away. It doesn’t work quite like that in ATTACK, but close enough.
Fun fact: ATTACK has full support for one action provoking reactions from multiple people (“he casts a fireball at all of you… what do you do now?”), but this has never been used.
In a roguelike, the idea is that you die over and over again, but over many playthroughs you improve with practice. I can see this posing an issue during testing, with testers trying to master the game while you’re trying to tweak the difficulty. How did you handle the tester/difficulty interaction, and how did you know when the game was hard enough (or too hard)?
Matt Weiner, my first tester, likes to tell people that when he first played Kerkerkruip, it was really hard – nothing like the easy time you have today! It’s true: the enemies were tougher, the loot was worse, there were several instant death situations. During testing, I decreased the difficulty a lot because I saw again and again that the game was just too hard.
How do you see that, even though the testers may just not be good enough to beat the game yet? Well, I myself have some idea of what the right tactics and decisions would be. So if I see a tester losing the game, I check what he was doing with what I believe to be the optimal tactics. If he is just making mistakes – attacking with inappropriate weapons, killing monsters in the wrong order, forgetting to use items he found – everything is fine. But if he is playing really well and still losing, than the game is probably too hard.
I don’t think I’ve seen so many grenades in any other roguelike. Where did those come from?
I’m not sure about that specifically, but my aim has been to avoid some of the most common roguelike items. So while there are scrolls, at least there are no potions. Grenades are uncommon in roguelikes, but common in other games – I suppose I thought they would be intuitive yet distinctive.
In the game’s help menu you mention several things that you’d like to add to the game. Are there any features that you considered and rejected?
Vast amounts, probably, but most of them will have disappeared from my memory. One idea I played with was adding an automatic puzzle generating mechanism: e.g., you find a locked door, and the game will have put a key somewhere in an accessible place. I might still do that, but it isn’t clear to me yet how that would have to be designed in order to make it interesting.
I once started to code up enemies that regenerated their health, until I realised that this would break one of my core design ideas – it would make for really boring, drawn out fights.
Oh, and for the competition, I commented out a chunk of code that handled objects heating up each other and damaging whoever was carrying or wearing them. My beta testers would pick up the flaming scythe and put it in their inventory; immediately, all their scrolls were set on fire, after a few turns their armour would melt, and then they would die horribly and looking at a screen covered with “The X catches fire!” messages. This idea may return in one way or another, but not in exactly that way.
What about features that you wanted to include but couldn’t?
Nothing really comes to mind. Well, if I had had more time, I would have included more stuff, of course. All kinds of stuff. And I hope to do so in future releases. But there was nothing I couldn’t include for technical reasons.
A roguelike usually isn’t about worldbuilding, but unlike Nethack’s patchwork of geeky in-jokes, Kerkerkruip is composed (as far as I can tell) of original elements. How much backstory is there to the people, nations, and gods of Kerkerkruip’s world? [If Malygris is the Wizard of Kerkerkruip, then what exactly is Kerkerkruip? The dungeon?]
There is just enough world building for me to write the somewhat coherent descriptions in the game. This was very much a post facto thing I did after some of my beta testers complained about a lack of coherence. Obviously, I had tried to populate my game with enemies that were as far removed as possible from stereotypical fantasy / RPG types, but the result felt a bit too much like just a random collection of things. So I quickly thought up a world to tie it all together.
That is certainly something I want to change in a future release. Not, by the way, through better world building. The idea that a good fantasy book needs a coherent world with twenty nations, fifteen centuries of history, a map and an appendix full of genealogical tables is horrifying to me – I like to call it Tolkien’s disease. If someone tells me that a game has good “lore”, I groan.
What I’ll probably do is throw out all the current world building, and add a sad story about how Malygris came to be the way he is. I think I have some neat ideas, but we’ll have to see.
And yes, Kerkerkruip is the name of the dungeon.
For the benefit of players who might never defeat Malygris, could you share perhaps a partial “list of amusing things to try”?
Anyone can defeat Malygris, if they continue playing. If you feel like you’re not progressing any more, you might have failed to understand the way that souls are absorbed. Make sure you know why killing two level 1 creatures in a row is the worst thing you could do.
But I can suggest some amusing things, of course. Try digging around when you have found a digging tool – you may discover weird things. Fill the dungeon with rust spores once you’ve found a non-iron weapon. Kill the mindslug without killing his slaves. Search that pile of body parts on the quartering room. Try to win the game after you’ve been turned undead and have summoned an abyss of the soul. And for a very special victory: try to win the game after you have unleased a nameless horror on the world.
How should we be pronouncing “Kerkerkruip”?
The only hard part is the “ui” vowel. Apparently, phonetically it should be written “œy”, but that doesn’t really help. Here someone pronounces “ui”: forvo.com/word/ui/ – be sure to click on the Dutch link, not the Finnish one!
Thanks to Victor for giving the interview and making this great game.