Clips & Keys A Wizard

Descriptive combat writes out the scene in full, utilizing all of prose’s techniques to communicate what is happening to the player character, their emotional state, the actions they take, and what exactly happens after the player makes a choice. This is comparable, perhaps, to narrative video games that use quick time events to keep the player engaged while they go through a combat scene (just usually without the time limit). The scene starts, the player is given a choice: do this or do that, and depending on which choice they make, the story reshapes itself around that.

Descriptive combat can be enhanced by other mechanics like stat checks, dice rolls, and weapon proficiency, but it all impacts the choices the player can make. The outcome is still, always, described in full, as would be in a novel.

Automated combat, on the other hand, strips down the prose aspect of IF to focus on mechanics and outcomes, usually with some kind of repeated action to create a gameplay loop. The player will still have choices to make, but with each choice there is code that runs behind the scenes to factor in all of the different mechanics and gameplay, and prints different outcomes based on how the code ran.

Automated combat is seen in IF games looks a little like this:

::Passage 1

You’re ambushed by a bandit! What do you do?

1. Attack.

2. Defend.

3. Run away.

::Passage 2

<<run code and print the following outcome based on skill checks/health points/attack damage, etc.>>

You attack the bandit for 10 points of damage! The bandit has 25 health points left.

The bandit attacks for 5 points of damage. You have 10 health points left. What do you do?

1. Attack.

2. Defend.

3. Run away.

It’s less about describing what happens after the player makes a choice, and more the game system and its end result (which can then affect the story from there). This is a much more “gamey” approach than descriptive combat. It’s not about the story, it’s about the game mechanics.

Since you asked about turn-based combat, I think turn-based would definitely fall into this category. I think it’s possible to do it with descriptive combat, but if you’re slowing things down to have the player choose how not only the player character acts, but how their party members act, it inherently becomes a more gamified system. There’s a lot of questions you would have to ask to figure out your system (How many turns? Are there hit points involved? What determines the order in which characters act? What abilities do they use?).

Automated combat systems can make your combat events a lot less work in the long run because you set everything up in the beginning. The player clicks on a choice, the code is run, and the code prints an automated outcome based on what conditions were met.

Deciding how you’re going to display combat is the most important choice will be the most important decision you make. Just like how combat visuals and presentation are important in mainstream gaming, how you write combat is important for keeping your players engaged.

II. Combat Mechanics

The core mechanic of all IF gamebooks is player choice. The simplest way of executing combat is to apply choice to your sequence, the same way you would a dialogue tree. With a combat tree, you can create a series of events that result in different outcomes based on what the player chooses to do.

Depending on how unforgiving you want to make your game, there can either be “correct” ways of navigating the tree and “wrong” ways of navigating the tree, with the player rewarded for selecting the right options (i.e. they win the combat sequence) or punished for selecting the wrong ones (i.e. they lose and they are injured, die, or lose something significant). Or you can make it so that there aren’t any true correct/wrong choices, and the outcomes are more about giving the player an array of roleplay options for the event.

Combat trees can be expanded on with additional mechanics. Your combat event is now not only about what choices the player makes, but which ones they make in conjunction with other elements.

For example, my own game uses a stat check and dice roll system. Most of the choices the player makes in combat events are based on either the Strength or Agility skill. Because of the dice roll, there is always a chance they will pass those checks, but there is also a chance they will fail. The player needs to consider which one they use based on their skill layout while considering their current circumstances. Is it better to go with a skill they’re proficient in, even if it doesn’t feel like the right choice, or to take a risk and use a skill they’re less proficient in because it’s the right one?

One combat popular combat mechanic is weapon choice or weapon proficiency. Weapon choice can be an important roleplaying option for a lot of players. If you combine it with a proficiency or skill-based system, then you can control what options the player has available in combat events. For example, say the player can choose between using longswords, daggers, bows, and magic. Depending on which one they select, the combat system changes to reflect their selected weapon. It could even be that the player is locked out of using certain weapons if they aren’t proficient enough at using them.

If you’re using descriptive combat, weapon choice can create an immense amount of work, especially if you’re combining it with other elements. This is the reason the player character only ever uses a sword in Wayfarer. Because of my other systems (skill check + dice roll), my combat events are extremely long and detailed. Every skill-based choice has two outcomes (a pass and a fail). If I give the player 2 choices, then I end up writing 4 outcomes; if I give them 3 choices, then I have to write 6 outcomes. It grows exponentially very quickly. To add weapon choice on top of that would mean I would have to write all of those outcomes multiple times for each weapon, which is, frankly, so much work it’s not worth it.

Skill checks are also popular for combat events. There are two ways to go about this: either you can lock a player off from a particular choice if their skill isn’t high enough, or you can leave the option open. If you leave the option open, you should make the result tangibly different from the result where their skill is high enough (otherwise why have the skill check in the first place?).

Skill checks should be considered with care. Because the core gameplay mechanic in IF gamebooks is choice, the last thing a player wants to see is a set of choices that they are locked off from because they don’t have the skill to unlock them.

1. Attack with your longsword.

2. You don’t have enough skill to use the bow.

3. You don’t have enough skill to use the daggers.

4. You don’t have enough skill to cast magic.

If you can only select one choice, is it really a choice? This is why I like adding dice rolls to stat checks; it keeps the player’s options open, but with the caveat that they could fail. Is it better to try and fail than to be prevented from trying at all?

III. Determining Failure

Combat events can be stripped down to one element: does the player win or do they lose? This is the core of most mainstream gaming—in most games, you need to win the combat event in order to progress with the game/story. If you lose, you die, and the timeline resets itself to before the player character lost and you try again until you win.

Some games poke fun at this, of course. Dying and trying again is a literal mechanic of Soulsborne games. Fire Emblem: Three Houses let’s you rewind time up to a certain amount of times if you lose your protagonist. Nier: Automata has a whole gameplay loop where the androids “die” when you lose, wake up their base with their minds transplanted into a new body, and then have to go retrieve their weapons from their old one.

But elsewhere, in terms of storytelling at least, it’s an assumption that anytime the player loses (and “dies”) is not a canonical part of the story. In Dragon Age: Inquisition, if your Inquisitor falls down that horrendously placed ravine in the Hinterlands and their party is wiped out by an upper-level Fade rift, the Inquisitor doesn’t die in the story. Their death is non-canonical. Their failure is non-canonical.

Because IF gamebooks are much more storytelling-focused than mainstream gaming, there’s an interesting opportunity here to reconsider what failure means in gaming. For one, if we try to apply the way combat failure works in mainstream gaming to IF gamebooks, it doesn’t quite… work. Failing a combat sequence and reloading your last save is negligible to modern day gamers; it can even be fun, especially if you know exactly how you messed up and you enjoy the combat system. Because mainstream gaming is visual and tactile, you still feel like you’re playing a game when you redo a combat event you failed.

IF gamebooks are prose. To re-read passages you already read in an IF is not the same thing as physically replaying a fight in a video game. It’s not fun to re-read the exact same thing over and over and over again, with very little variation, until you get it right. The “win to proceed with the game” element breaks down in IFs, making it a chore for the player to get through. IFs are primarily about the story. If the player can’t proceed with the story, then what’s the point? You are preventing the player from proceeding with the one thing the game is about. You are halting their progression without giving them a satisfying, narrative conclusion.

Related to this is the topic of false endings and early deaths. I think, in most cases, these are a waste of the player’s time and should be implemented with extreme care. If you end the game early with the player’s death, was that story satisfying, as it played out? Was it a complete story? A full experience? Player death can be extremely impactful in IF, but only if the player has experienced a satisfying story before their character dies. If you led the player down that path to make some point about them not playing your game right or to show how dangerous the world is, there are other ways to do that without stopping their gameplay. You may want to reconsider the false end, particularly if you are then asking the player to restart from the beginning and your game doesn’t offer much variation on a replay.

So, with all that in mind, IF game developers should think carefully before they incorporate the player character’s death into their combat system. Starting a combat event over in an IF means something completely different than in a video game. But this isn’t to say that the player character shouldn’t ever lose. Failure can bring much-needed character growth that is otherwise overlooked in the player character; it can also open up new opportunities for different conversations with NPCs and companion characters. Failure can reshape the player character’s journey and story as much as success. And I think IFs can execute failure and what it means to mess up far better than traditional video games, whose protagonists often feel infallible and untouchable.

Your combat system should have some kind of consequence for failure. Combat is based on a win/lose system (or, in some cases, win/lose/draw). If the player character loses, maybe they are injured and that injury affects their gameplay and the player’s choices further down the road. Maybe they lose money, maybe they lose a skill point. Whatever it is, it should bring something new and interesting to the table, furthering the player character’s development or story in some way.

IV. Final Thoughts

Ultimately, combat mechanics are a crucial part of player experience. It’s a balance between interesting choices, interesting consequences, roleplaying, and gameplay. A good IF gamebook combat system should be engaging for the player to read, and also give them flexibility in terms of making roleplaying choices. It should make them think about their actions, let them play in the grey space between “what is the best choice in this circumstance?” and “what is the choice my character would make based on their personality, even if it’s the wrong one?”

If you’re going for a mechanics-heavy system with hit points and skill checks, think about how you intend to merge that with your game’s story and characters. How can you use mechanics to enhance the player’s ability to roleplay? How can you use them to shape how the player navigates your story?