top of page

Branching Narratives

Two of my biggest passions are storytelling and game design. Those familiar with me might know I've experience of simple storytelling in video games (check out Alien Swarm Reactive Drop on Steam), but I've always wanted to try my hand at telling a complex narrative using video games as a medium. So, a while ago, I decided to make a Choose Your Own Adventure, text-driven game using Twine. I'm calling it, The Broken Aurora.


Enter Twine


Twine is a brilliant little bit of software. You start with a blank page and build your story or game in the form of a flow diagram. Arrows between different passages show direct links, and multiple passages can be linked together to present choices to the player. This is a bit like visual scripting in traditional video game design.

Imagine sticking post-it notes on a noticeboard, each one representing a passage in your story. Then you connect them with string to show how the passages relate to each other. You can quickly develop simple stories, letting the player choose the path they take from A to B.


But there's much more functionality available than that. The fun really starts when you begin adding variables, IF statements, and other bits of coding magic.


Setting Variables


I won't delve into all of the potential uses for variables (we ain't got time for that), but I'll cover the two simplest ones and how they work.

Before that, though, here's a quick guide to what a variable is and how you make one.


A variable in Twine (and in many video game coding languages) represents a choice made by the player. Let's say I wanted to let the player choose what kind of weapon they want to wield. To do that, I might create a variable called $PlayerWeapon.


At any point in making my story, I create this variable by sticking a $-sign in front of PlayerWeapon and telling Twine what I want the variable to be. This is called "setting" a variable. So, if I present the player with a choice between a sword and an axe, and they choose the sword, I set the variable with code that looks like this:


(Set: $PlayerWeapon to "sword")


Think of variables as boxes that store player choices. I name the box $PlayerWeapon and I place the "sword" inside it. Later on, we can recall the information stored in the box. More on that in a minute.


A few passages later, the player might choose to discard their sword in favour of the axe. To do that, we simply give the variable a new value:


(Set $PlayerWeapon to "axe")


Calling Variables


Now, it's all very well that I've given the player a weapon, but I want that weapon to feature in the story. So, how do I do that? It's ludicrously simple. Just type $PlayerWeapon wherever you want the name of their weapon to appear. In the following example, let's assume the player chose "sword".


If I type:

You raise your $PlayerWeapon high in the air and bring its blade down across the goblin's chest.


The player sees:

You raise your sword high in the air and bring its blade down across the goblin's chest.


Another player might have chosen to wield an axe, or a spear, or a halberd. $PlayerWeapon will remember that selection and substitute the variable for the correct word.


Cool, ain't it?


If Statements and Player Choice


You can take things a step further using IF Statements. Sticking with the $PlayerWeapon example, let's imagine the player is asked early in the story to take either a sword or a crossbow. As the game designer, I want that choice to have an impact further down the line.


I want this for three reasons: I want the player to feel like their choices have consequences, I want the game to have replay value, and I want different players to have different experiences they can talk about around the water cooler (or whatever the working from home equivalent is...)

So, the player, having made their weapon choice, continues with the story. A few passages later, goblins attack, and - OH NO - there's one about to kill a villager 50 feet away. If the player chose the crossbow, they can stop it. If the player chose the sword... well... MEAT'S BACK ON THE MENU, BOYS!


These are two very different outcomes, requiring different descriptions and consequences, and I need to get Twine to display the appropriate text and choices to each player depending on the weapon they chose earlier.


I could do things the hard way, duplicating every single passage that comes after the weapon choice, one set for players with swords and the other set for players with crossbows. Or, I could do things the smart way and use IF statements.


Creating an IF Statement


For the above scenario, I'd write a single passage that uses two IF statements (there are other, potentially better ways to do it, but they require more complex techniques that I won't get into here. Maybe another time.) I'll make it so that if the player chose "sword", text A will appear, and if they chose "crossbow", text B will appear. Written out in Twine's pseudo-code, it looks like this:


(If: $PlayerWeapon is "sword")[You sprint towards the goblin and the villager, but they're too far away. You've covered less than half the distance when the goblin's sword pierces the villager's back. You reach them as the villager falls, and slay the goblin with a single swipe of your sword. The villager takes his last breaths in your arms.]


(If: $PlayerWeapon is "crossbow")[You raise your crossbow and loose bolt at the goblin. It flies straight and true, catching the goblin through the neck. The villager looks back at you as the goblin falls, and nods the briefest of thanks before fleeing down the hill.]


I write both of these statements into the same passage in Twine, and Twine will determine which one the player actually sees depending on the variable stored in $PlayerWeapon.


Here's another simplified example. In the screenshot below, the player is stood on the wall surrounding a city under attack. If you have a sword, the game says "Your sword is useless here" and prompts you to "Head for the gate". If you have a bow, the game says "You draw your bow" and prompts you to "Fire on the attacking wisps".


More Complexity Still


The IF statements I wrote in the previous paragraph work fine, but if there were ten weapons to choose from it would be a pain to write out ten possible outcomes. This is where ELSE statements come in, and where OR, AND, and EITHER become useful. I might cover those another time, but if you're interested in learning more or trying out Twine for yourself, click the yellow link.


Keep an eye out for The Broken Aurora popping up on the website shortly, or, sign up for my newsletter if you want to help play test it in a few weeks.

Comments


bottom of page