Dungeon design journal #4: making a monster


If you are using Inform ATTACK, how much code does it take to create a monster? Six words.
The boar is a hostile person.
I have spent a considerable time coding up three monsters for my dungeon crawling game. The third one took me about 1600 words, which is a little more than 6. Where does the discrepancy come from?

One of the main design goals of almost any tactical combat game should be to make the enemies as diverse as possible. This is not necessarily easy. Desktop Dungeons, which features only a handful of monsters, has only few good ones. Mostly it is just the "raise one stat, lower another" approach: a monster with a lot of health but little damage, a monster with little health but a lot of damage, a monster with high magic resistance but low health. Dungeon Crawl Stone Soup has many awesome monsters, like hydras and ugly things, but also (certainly on the earlier levels) a lot of monsters that feel more or less identical. And I for one wasn't impressed by the diversity to be found in Dragon Age: Origins.

There is of course such a thing as cosmetic diversity: different sprites or models or descriptions, even if they have no effect on the gameplay, can enhance the game. This is not unimportant. But we want more. We want monsters that force the player to rethink their tactics and their strategy. This means that the monster must interact in an interesting way with one or more tactically important aspects of the game: the items, the skills, the spells, the terrain, the basic combat actions, or whatever else you have. So thinking up a good monster generally starts with thinking about your tactical system.

Let us observe something about the basic ATTACK system of attacking, dodging, parrying and concentrating. In general, dodging and parrying are pretty much no-brainers: if you are attacked, you do whichever of them seems to be the most useful against the current attack. (Parrying a bullet is not going to work.) You could concentrate instead, if you are feeling very brave, but the AI is good enough at deciding when attacking is useful that this is rarely a good idea.

No, the basic tactical decision in ATTACK is that between attacking and concentrating. It might seem that this is a decision between investing in a better future attack (concentrate) or doing some damage now (attack). In general, however, that is not really what you are worrying about. What you are worrying about is your opponent's concentration level, your ability to destroy his investment and his ability to destroy yours: when you deal damage to someone, that person loses his concentration. So suppose your concentration level is 1, and your opponent has just raised his level to 2. If you attack, you might very well miss. If you miss, he can raise his level to the maximum of 3, and you, with no concentration left, will have a hard time disrupting him -- which means that he can unleash a very deadly attack. If instead of attacking him now you concentrate to 2, and he concentrates to 3, you'll have a much better chance to hit him and disrupt his concentration before he can attack you. So concentrating might seem like a good idea.

On the other hand, what if you raise your concentration to 2 and he does not raise his concentration to 3, but attacks you instead? If he hits you, you will lose two turns' worth of investment. That is very bad. So maybe it would after all be preferable to hit him right now and try to disrupt that concentration before it gets any higher. If you hit, you might very well win initiative, and then you'll be the one ahead in the concentration race.

Now there might well be an optimal strategy for ATTACK, but the math is complicated and highly dependent on little changes in the stats and the health the combatants have left. So it does feel like a tactical gambling / bluffing game more than like a math problem to be solved.

Why bring this up? Because an understanding of the basic tactical decisions allows us to think of ways to turn these decisions on their heads, so to speak. In the basic system, a person is most vulnerable when he is maximally concentrated: concentration gives no defence bonus, and if you get hit you lose a big investment. So, for a radically different tactical situation, what about a monster that is least vulnerable when it is maximally concentrated?

Enter the chain golem

The chain golem is a lumbering mass of metal chains that attacks by lashing out at its opponents with some of those chains. When it concentrates, it starts spinning around, whirling its chains through the room. As it concentrates more, it starts spinning faster and faster -- and obviously becomes very unsafe to approach.

In game terms, what happens is this: anyone who tries to attack a concentrated chain golem must first avoid the spinning chains. This becomes more difficult as the spinning increases. Failure leads to a painful collision with the chains, damage, and loss of concentration. So the most likely thing that will happen when you attack a concentration 3 chain golem is this:
The chain golem spins even faster, audibly slashing the air with its whip-like metal appendages.

Act> attack golem
The chain golem lashes out with a heavy iron chain, trying to stop the attack.

You attempt to duck under the whirling chains. You roll 5 + 5 (dexterity score) = 10 against a target number of 12, failing the dexterity check. One of the chains catches you with a loud smack, dealing 6 damage and breaking your concentration.

Rolling 2 - 2 (defender parrying) + 4 (tension) = 4, you do not overcome the chain golem's defence rating of 8.

Several of the wildly spinning chains lash out at you.

Which is not an enviable position to be in. Indeed, you will have to rethink the way you approach this particular creature. Stopping it before it can get up to full speed is essential. If it does get up to full speed, it might be smarter to let it attack you then to try to break its concentration. Best of all would be to get an ability that allows you to damage someone (and thus break that person's concentration) without actually attacking that person -- and one of the other monsters I have made does grant you such an ability, although it is never guaranteed to work. So killing that (level 1) monster before attacking the (level 2) chain golem could be a good idea. Only, you'll lose any level 1 ability when you kill a level 2 monster and gain the corresponding level 2 ability, but not the other way around... so perhaps you might want to wait with killing that level 1 monsters. Decisions, decisions.

Overall, the tactics needed to defeat the chain golem are probably less interesting than those needed to defeat a basic monster: that is, it would be more fun to play in a world with only standard ATTACK monsters than to play in a world with only chain golems. But of course, that is not the point: the point is tactical diversity. And I think the chain golem certainly provides that.

Making things interesting

That is all very well, but we want our monsters to be even more interesting, and combat even more intense. So I have given the chain golem a special ability: once in a while, it will attempt to wrap one of its chains around your weapon, yank it out of your hand and send it flying across the room. While not necessarily leading to new tactics -- unless you have another good weapon, you should probably try to retrieve it -- it does spice things up a bit, and increases the unpredictability of the combat. Furthermore, it allows us to have the chain golem interact with its environment in interesting ways: at some later point in time, I intend to write a "when something is randomly thrown through a room" rulebook that could be invoked by the chain golem's disarm ability as well as other events in the dungeon; and that will allow the current location to intervene and have an effect on what happens. If the chain golem protects the narrow bridge over the lake of lava, you might want to consider fighting it without using your favourite weapon!

Another good future addition would be a probability for the randomly thrown weapon to hit and damage a third person in the location. Even if it only came up once in every several hundred games, the chain golem accidentally killing its own ally would be great.

In order to have such 'emergent' events, you need to write relatively general rulebooks that can be called by different events. If the chain golem is the only thing that can send an object flying, writing an entire rulebook for this eventuality is probably not worth it. But if it can happen more often -- well, then it obviously is. (The player throwing objects at an enemy? Certainly a possible action to be considered.)

Rewarding the player

Once the player has defeated a monster, he absorbs its soul. This gives a general stats increase, but also grants the player a passive or active power. In the case of the power of the chains, the player gets the ability to "lash". This is to attack the enemy as a reaction: i.e., to attempt to disrupt the enemy's attack by counterattacking, something that is usually not possible in ATTACK, and which everyone will love to be able to do.

Writing all of that, with the required prose, takes about 1600 words. Not too bad, actually, since I'm thankfully experiencing that everything I try to do fits into ATTACK very neatly (perhaps because I think like myself, but let's assume for my sake that it is because ATTACK is well-designed). The entire carry out rules for lashing are:
Carry out lashing:
    choose a blank row in the Table of Stored Combat actions;
    now the Combat Speed entry is a random number between 8 and 14;
    now the Combat Action entry is the action of the actor attacking the provoker of the actor;
    say "You will attempt to strike swiftly, before you are hit.".
In basic ATTACK that Table of Stored Combat actions only ever contains one action, and the fact that actions have a combat speed never makes a difference. But I put it in in case people wanted to write something like the lash action (or even more complicated things, involving more people and/or actions). Thank you, former me!

(In case you wonder: actions with a lower combat speed get carried out earlier; attacking has a standard speed of 10; so lashing has a 2.5 / 7 = 36% chance of happening before the attack.)

Additional things

Three monsters, two rooms, a couple of items: its not exactly going quickly, but we're getting there. I might put out an early alpha release when I have seven monsters and enough rooms to put them in, for those who are curious.

There was some talk in the previous thread about whether I should just disable saving or include my Permadeath extension. I'm certainly willing to do the latter if people prefer that. (Erik, I don't think your idea of autosave and autorestore will work, because you cannot force someone to overwrite their old save when they die, and I don't think the game can save without help from the user? Permadeath solves the problem in a somewhat more complicated manner.)

I'm finding that writing this game, and thinking about it, is both pretty exhausting and pretty fun.


  1. I like the Chain Golem--fun stuff! Thanks also for the tactical discussion; it's thought-provoking, as was your critique of D&D from a similar perspective a while back.

    One thing I don't much like as a player, though, is seeing all of the stats mixed in with the game's descriptive text, e.g. "You roll 5 + 5 (dexterity score) = 10 against a target number of 12, failing the dexterity check." Any chance of moving these mechanistic bits to a separate window or otherwise separating them from the description?

    Regarding the save game thing: My suggestion was to bypass the standard save/restore commands completely, which means that you can also bypass the control they give the player. The game can then silently create, write to--or destroy--save files at any time, pretty much exactly as Nethack does. (A file is destroyed using the glk_fileref_delete_file call.)

    Specifically, you could save the game automatically, whenever needed (after character creation, after winning a battle, only on quit, or even every turn--whatever's wanted). When the game file is opened or restarted, you silently restore the last save and then delete or overwrite the saved file.

    This wouldn't prevent the player from cheating, of course, since the save file could be copied by a savvy player. You could add another layer of protection by writing a unique key to your tracking file at each of the save intervals. If the key in the file doesn't match the key in the save file, then we know that the save file is a cheat and can be deleted. (This approach is analogous to the approach in your Permadeath extension, I think--that is, using a separate file to track saved game viability.)


Post a Comment

Popular posts from this blog

Keeping the narrative pressure on

Thoughts on a Trollbabe session