Building a Boss Fight

Spoilers for Chapter 1, Route A

One of the most challenging, yet rewarding, things to come out of Chapter 1’s development is the Route A boss fight. I have always intended Wayfarer to have a robust combat system—it’s necessary to be true to the setting and to the main character’s journey. A Wayfarer is a warrior, first and foremost, and navigating dangerous, life-or-death situations is part of how they make their livelihood.

But implementing one in a text adventure is tricky. In a text adventure, combat obviously can’t rely on the player’s physical skill and responsiveness, as in most real-time combat game. I have seen some IF games implement a text version of turn-based combat, but of the ones I’ve played, I found that the pace and flow of the story crawled to a halt while you flipped through passage upon passage that read “Character A took 10 points of damage! They have 40 points left. How do you attack?”.

Personally, I do not find that engaging.

Creating Combat: An Overview

Wayfarer’s skill check and injury system is the result of many months of testing different gameplay elements to find a balance that works for the game’s needs.

The ability to either pass or fail your skill checks came out of a desire to play with risk vs. reward elements. Because the protagonist lives a dangerous life, I wanted the player to feel that innately. No matter how well-trained they are, there is still the possibility that everything can go wrong. I wanted to capture a feeling similar to D&D where you hope everything goes according to plan, but one bad dice roll can put you in a sticky situation. By combining the player’s skill level with a randomized number, they are walking a fine line between success and failure.

When the game was in early, early development (back in the days when it was a Dragon Age fan game), I quickly discovered that writing multiple options for weapon choice ended up exponentially increasing my workload. Back then, I was dealing with four potential weapon types (sword, daggers, bow and magic) in combination with passing or failing skill checks, which meant that there were at least 8 outcomes for each checkpoint within a combat sequence. It was far too much.

Instead of giving the player options in terms of what weapon they can use, I chose to focus on player skills. They will always use a sword to attack (which makes writing combat scenes a lot easier since I can combine passages where appropriate), but the way in which they approach combat changes.

Combat sequences rely primarily on Strength and Agility checks. This way I am still able to give the player choice in how they approach the scene. Occasionally Perception is used, if the sequence ends up in a place where the player character needs to consider their surroundings and a straight-up attack is less than ideal.

When developing the Chapter 1 Route A Boss fight, items came into play. When I originally designed the skill checks, I thought that most players would choose to focus primarily on one combat skill (strength or agility) and one exploration skill (perception or persuasion). I failed to account for players interested in roleplaying a more non-combative character, someone who relies on their words first and only fights when necessary or when they’re backed into a corner (or players who went in blind and ended up with their skills all over the place).

To account for that, I added items. I’d been playing with the idea of adding consumables—any kind of item that the player can store in their inventory and use when prompted or save for later. Coding the consumables was very tricky. Because I wanted the consumable list to show how many the player had left versus the maximum they are allowed to carry, I couldn’t use the inventory macro I am using for all other inventory items with the coding getting gnarly (the inventory macro is from Chapel’s Custom Macros, highly recommend checking it out if you’re using SugarCube to build your game). I came up with my own system for handling consumables. The downside is that the consumable list will always appear in the player’s inventory—it was too much work to configure items to disappear from the list if they weren’t in the player’s inventory, so the consumable list is static across the game.

Items can be used in combat sequences, but only when the narrative syncs up to an appropriate moment. For example, the player character may get a grappling hook from Thelkar, but since it was an additional variation I didn’t want to write, they can’t use the grappling hook as an impromptu weapon in the fight. And so, the thunderspheres were added specifically to be an item used in combat.

Thunderspheres are Wayfarer’s version of hand grenades. I didn’t want to call them bombs or grenades since it felt too contemporary (despite both words being used to describe explosives for centuries, connotations in English are weird like that). Thunderspheres are very loosely named after the early hand grenades developed in 12th and 13th century China, called “heaven-shaking thunder bombs” or “thunder crash bombs”.

Because the player has to purposefully purchase items in advance, using an item is a guaranteed pass and not attached to a skill check. This can help players who have low Strength and Agility stats make it through some extended fights, provided they reach a point where they can use their item.

Whenever I think about game mechanics, I am also considering how they are reflected in the narrative. I am always thinking about the characters, how they embody the space and how they react to the circumstances they’re in. Introducing the thunderspheres and writing the outcome of throwing a bomb and causing a devastating explosion made me realize that using an item isn’t always going to be an easy way out—some companion characters may have feelings about the player character’s choices and actions. That reaction and the associated approval loss or gain becomes another element.

The final element of combat is timed choices. This feature isn’t specific to combat. Instead, it is used whenever I want to heighten the tension of a choice and make the player feel the same kind of rapid decision-making that their character must go through. I tend to put these in places where the text is pushing the action and everything is happening very, very fast. I want to be careful with timed choices and not overuse them (otherwise they start to feel gimmicky). Having a unique option for abstaining or running out of time also adds an additional outcome for me to write, which can be a bit of a problem (I will discuss this further later on).

Structuring a Boss Fight

At this point, I have a list of major gameplay mechanics to consider when structuring the combat scene. These are:

• Successful skill checks
• Failed skill checks
• Items (in this case, just the thundersphere)
• Timed choices

Other gameplay elements I need to consider as I proceed forwards are:

• Companion approval loss and gain
• Injuries
• Unique Origin and/or Ancestry options
• Items that go in and out of the inventory due to narrative reasons (such as having your weapons/gear taken away)

Structuring combat is a tricky balance of narrative pacing, player choice, and exponentially growing outcomes. In addition to the mechanics, I need to decide how many checks I am going to have in a sequence. Too many and I am going to get overwhelmed with the exponentially-growing outcomes; too few and the player will either feel like they don’t have control over the combat or feel like the sequence ends too soon.

However, with Wayfarer’s skill check system, a single option results in two possible outcomes. In cases where the player is given a Strength check and an Agility check, from the player’s point of view, it feels like there are only two choices when, in reality, there are four outcomes. To clamp down on rapidly growing outcomes, I tend to stick to just Strength and Agility, though I sometimes add in an alternative 3rd (or, if we’re talking outcomes, 5th) option that isn’t attached to a skill check.

Before I start writing, I need a roadmap. Compartmentalization is extremely important in non-linear, choice-based narratives. You need to block off each branch and consider them one at a time, otherwise it becomes overwhelming. I like to keep a checklist of all outcomes, broken down by section, so I can keep track of which outcomes I have covered and which ones I have not.

Every time I hit a major branching choice, I write out the outcome of each decision and label it with the section it connects to. In more complex sequences, like the Route A boss fight, I add colour coding as well to help me keep things separate in my Word document.

(At least my notes make sense to me)

While I do some work with flowcharts early on, I find it too time consuming and it’s easier for me to map everything in my head or through checklists. When it comes to coding, Twine’s visual map helps me double-check the flow of the entire sequence and make sure I didn’t miss any variations. I think if I were working with a co-writer, a full flow-chart for a sequence like this would be absolutely necessary, but I know my own mind pretty well so my checklist system works.

When working on a sequence that sprawls into multiple variations, I have a few different ways I compartmentalize the content. These aren’t official terms in any capacity, just what I’ve started to call them for the sake of my own organization:

• Section. Sections are the container for everything else. In a way, they are a little like scene breaks. A section is complete when all blocks connect into the same bottleneck or send the player to a different section.
• Blocks. Blocks refer to the large-scale scope of a single, major choice that contains all the various branches within it. In large sequences, there are usually 2-3 blocks. The Chapter 1 Route A boss fight has 4 unique blocks.
• Branches. Branches are the individual strands/outcomes of a choice. Most branches will result in multiple, compounding branches.
• Bottlenecks. Bottlenecks are points where the various branches or entire blocks converge back together. Bottlenecks are crucial to keep the story and pace on track and moving forwards.
• Variations. Different versions of the same scene, with slightly different flavour text or something else that sets it apart. I will often copy/paste the text of one variation into another and then edit in changes. If the flavour text is simple, I can handle the variations all within the same passage by using <<if>><<else>> statements, but for more complicated things (or if I need the visual on Twine’s map) I will create a separate passage.

In structuring this fight sequence, I wanted there to be multiple ways it could go depending on how the player reacts. There are 4 main blocks which cover the major different iterations of the fight. I intentionally made some blocks easier to access than others; this is partially for narrative reasons but also because I find it more interesting to have uneven choices—when you stumble across a unique scene that is difficult to trigger, it feels more special.

Block 1: Fighting the Basilisk On Land
This is the easiest block to trigger and the closest thing to a “canon” version of the scene. It is accessed through multiple choices and both successful and failed checks. Depending on the player’s choices, the Count will either summon the basilisk or the player will end up in the water and the basilisk will track them. Block 1 and Block 3 result in the same bottleneck at the end of the sequence.

Block 2: Fight the Basilisk in the Water
This block is the most difficult to access as it is Ancestry-locked. It starts similarly to Block 1; however, to trigger it, the player must end up in the water (either by choice or falling through the trapdoor). The player can be kicked out of this Block and onto Block 1 if they fail their skill checks and are unable to fight the basilisk underwater. If they pass, they will kill it underwater, resurface and an impressed Count will let them and Aeran go. This is the shortest Block and is the only one that guarantees the Count and Rhodarth’s survival at the same time.

This block was not part of the original plan; it came about because I realized that Melusine player characters should have an advantage fighting underwater. I wanted to stay true to the capabilities of their Ancestry and it’s a unique surprise for Melusine players.

Block 3: Courtyard Melee
This block is intended to trigger almost as often as Block 1, but not quite—it will depend on whether or not the player ends up in the water and how they choose to handle Rhodarth (whether they are successful or not at asking him to stand down). Rhodarth can be executed in this block, which is not possible in the other blocks. It connects to the same bottleneck as Block 1, but there are a few alternative variations depending on the player’s actions in regards to Rhodarth.

Block 4: Duel the Count
This block is also difficult access as it requires the player to ignore Aeran entirely (something I feel many players will not do; my current player data agrees with this) and a successful Persuasion check. The duel is also one of the most difficult blocks to get through successfully as the skill checks are more ruthless. I wanted to capture the feeling that the Count is a dangerous, difficult enemy and there are several pitfalls in this block to trip players up, including ineffective strength checks and automatic fails.

SECTION 1: Confronting the Count: Opening

Section 1 covers all the establishing details I need to get through before the fight sequence can start. In this case, I needed to:

· Set up the player character’s promise to Aeran. Trust is an important part of their dynamic and a common theme that will be returned to multiple times. I flagged this choice with a true/false variable so I could take it into account later.

· Establish a setting description of the Count’s villa and courtyard. The fight scene is taking place here, players needs to have an idea of the environment they inhabit.

· Establish the Count as an intimidating figure and make it clear that how the player chooses to interact with him will determine how the fight will go.

This leads into the first set of branching choices. The player can:

• 1. Follow Aeran’s lead, as he asked.
• 2. [PERSUASION] Convince the Count killing you will serve no purpose. (PASS).
• 2. [PERSUASION] Convince the Count killing you will serve no purpose. (FAIL)
• 3. [AGILITY] Break free from your bonds. (PASS)
• 3. [AGILITY] Break free from your bonds. (FAIL)

For all versions of Options 2 or 3, to link up with the promise variable, this choice sets another variable that tracks whether or not you broke your promise to Aeran by taking this choice. Breaking your promise nets negative approval on the next passage.

BRANCH: Follow Aeran’s lead.

This branch leads into a set of timed dialogue choices where the player confronts the Count directly. Depending on what dialogue or actions the player chooses to take (or if they abstain or time runs out), these branches can send the player to different blocks.

Choosing the wrong dialogue or actions will send the player into the water and to the beginning of Block 1 or 2 (depending on their ancestry).

Choosing the right dialogue or actions will lead the player to the following choice:

• 1. Fight. Your weapons are in the cart. Go for them. This option routes the player to the start of Block 3, the Courtyard Melee.
• 2. Escape. Dive into the water and swim out to sea. This option routes the player to the start of Block 1 or 2, fighting the basilisk.
• 3. [PERSUASION] Bargain. Convince Rhodarth to stand down. (PASS). This option routes the player to Block 1, fighting the basilisk, but with the variation that cuts out falling into the water. There is also a second variation of this choice, depending on whether or not Aeran has managed to attack and nearly strangle the Count.
• 3. [PERSUASION] Bargain. Convince Rhodarth to stand down. (FAIL) This option routes the player to Block 3, the Courtyard Melee. There is also a second variation of this choice, depending on whether or not Aeran has managed to attack and nearly strangle the Count.
• 4. Abstain. Sends the player into the water and the start of Block 1 or 2.

BRANCH: Convince the Count killing you will serve no purpose.

A successful persuasion check will route the player to the start of Block 4, the duel with the Count.

A failed persuasion check will throw the player into the water and route them to the start of Block 1 or 2.

BRANCH: Break free from your bonds.

A successful agility check will route the player to the start of Block 3, the Courtyard Melee.

A failed agility check will throw the player into the water and route them to the start of Block 1 or 2.

SECTION 2: The Fight

Each block has its own complexities, flow, pace, and structure which would take too long to analyze in-depth here (I’ll save it for a walkthrough someday). There are multiple small variations throughout each block which change depending on the player’s actions—for example, some failed checks during the basilisk fight may lead to them losing their weapon, thus cutting them off from a choice that involve attacking with their sword. Aeran gets injured in some variations; in others, he doesn’t. This is tracked with a true/false variable and an absolute pain to deal with later continuity-wise; I likely won’t be implementing something like this in future fight sequences and companion characters with either get injured across all variations or not at all.

The most important variation is in Block 3. When the player defeats Rhodarth (or if he injures them at a specific point, but they are not knocked unconscious), the player has the choice to either:

• Execute him
• Order Aeran to execute him (only available if the player is injured)
• Spare him

Executing Rhodarth will net the player massive approval loss with Aeran and unique dialogue later in the chapter.

Each Block also handles the injury system.

In Blocks 1 (Basilisk Fight on land) and 3 (Courtyard Melee), if the player sustains two injuries during the fight, they will get knocked unconscious by their opponent (either the basilisk or Rhodarth, depending on the context) and route them to the Blackout bottleneck.

A failed check in Block 2 forces the player to surface with an injury and reroutes them to Block 1.

Because Block 4 is unique and the narrative pace of a duel is very different from that of a group monster fight or a two-people-versus-10 clash, Block 4 is treats injuries differently. Any failed check will cause the player to get knocked unconscious and route them to the Blackout bottleneck.

SECTION 3: Dealing with the Count

Section 3 is only applicable to Blocks 1 and 3. A successful duel in Block 4 ends with the player killing the Count and freely leaving the villa. A successful basilisk slaying in Block 2 ends with the player character surfacing and walking away free (albeit with an injured Aeran as he takes a bit of beating on land while the player character is gone).

If the player is not knocked unconscious during Blocks 1 and 3, they will be routed to the same bottleneck at the start of Section 3. They are approached by the Count, who makes some sly remarks, and then they must choose how to deal with him. The player’s options will depend on how Blocks 1 and 3 went:

• If Rhodarth is dead, the blood oath on his company breaks and Aeran, realizing that Rhodarth didn’t have much choice in how he dealt with them, attacks and kills the Count. This is an automatic result, the player has no say here. The player will then be routed to the post-fight bottleneck in the next section.
• If Rhodarth is alive, he attempts to strike the Count and his blood oath activates, preventing him from doing anything more. The player then must choose either to help Rhodarth and fight the Count, or leave Rhodarth to his fate and escape the villa.

If the player chooses to leave Rhodarth, they will be routed to the post-fight bottleneck in the next section. If they choose to help Rhodarth, the section continues with the player attacking the Count.

When attacking the Count, the player will be knocked unconscious and sent to the Blackout bottleneck if they are already injured. If they are not injured, they may get injured once but then they must pass their second skill check in order to win the fight. This context plays by different rules than the Count duel, but I wrote this section first and but considering how long the sequence was beforehand, I found it was too unforgiving to make the first fail an automatic fail in all circumstances.

If the player defeats the Count, they will be given the choice to execute him or spare him. If the player chooses to spare him, Aeran will supersede the player and shoot him anyway.

SECTION 4: Post-Fight

This section occurs if the player is not knocked unconscious. There are multiple loops the game will cycle through depending on what variables were flagged during the previous sequence. It is a continuity nightmare. In brief, here is a list of all the things the game checks (and different scenes and/or flavour text will trigger one after another depending on which variables are flagged):

• Whether the player is injured or not
• Whether Aeran is injured or not
• If the player is injured, what kind of medical kit they have available (checks whether they purchased the enhanced medical kit from Emari and makes it available, otherwise the player character will use their regular kit)
• Whether Rhodarth was executed or spared
• Whether the Count was executed or spared
• Which Block the player ended up on (whether you fought the Count in a duel, fought the basilisk underwater, fought the basilisk on land, or fought in the courtyard melee)
• Whether the player broke their promise to Aeran or not (triggers a unique dialogue scene if they broke their promise)

This section then leads into Malsara collecting the player character and Aeran and thus the fight sequence and its aftermath is concluded.

SECTION 5: The Blackout Bottleneck

Whenever the player gets knocked unconscious, it will route them through this bottleneck and they will wake up on the ship. The scene/memory that plays beforehand depend son their Wayfarer master and, afterwards, it will unlock the first of the Wayfarer tenets.

After this scene plays, the player is routed to a unique sequence on Zenaida’s ship. Many of the conversation points that occur in Section 4 can trigger here as well, depending on the player’s choices. The player also has a few unique interactions with Aeran that do not trigger elsewhere, namely the opportunity to ask him about his relationship with Rhodarth (which unlocks the Brightblade codex) and a near-kiss for those who took his romance flags.

Additional Thoughts

The full fight sequence, including every block, branch and variation is approximately 40,000 words (I remember it being over 50k before edits, but I was able to cut down a bunch of extra material that didn’t need to be there). This level of intense variation is something that I am interesting in playing with, but it will need to be contained. I learned quite a bit about branching structure from tackling the end of the chapter this way and there are a few things to keep in mind going forward:

• Keeping track of continuity is the most difficult part of writing IF. I tend to put a lot of texture and flavour into my action scenes; I’m always thinking about how characters move through the space, how they interact with their environment and each other. If, for example, a character gets injured and I want to commit to that, then I need to make sure that in every variation they are injured, they are injured the exact same way. This saves me time later on so I can describe them as wounded and not have to backtrack and add in a variable for different flavour texts dealing with this continuity.
• Fight sequences are going to grow organically as you write them, no matter how much you plan in advance. Plan small, and let it grow, rather than deciding on multiple large, sweeping elements ahead of time. The small plan will have enough variation on its own.
• Don’t be afraid to clamp down on variations. There is too much variation in this sequence; even with a robust Excel sheet, it’s difficult to keep track of and the continuity is an absolute pain in the butt.

Not every chapter is going to end in a massive sequence like this. 

(On a related note, not every chapter is going to be as large as Chapter 1—some chapters are much more linear and this chapter’s size has a lot to do with me testing all of my gameplay mechanics and making sure I have a solid foundation moving forwards). 

This is by far the most complicated section of the game so far, and it will likely stay the most complicated. I’ve learned a lot from writing and executing it this way, so in the future hopefully the system will become more refined.