Using Twine for Games Research (Part II)

This preliminary discussion introduced my thoughts on using Twine as a tool for creating prototypes for games research. I'll start with documenting my first case study: a hack-and-slash RPG-like setting where the player character has a record of attributes ("stats") that evolve through actions that turn certain resources (money, health, items) into others. I've selected this hack-and-slash example because it falls outside the canonical "branching story" domain thought to be Twine's primary use case, but it is not too much trickier to implement. It relies crucially on the management of state in ways that simple branching stories would not, but it does so in a fairly straightforward way.

If all goes well, this post may also serve as a tutorial on the "basics" of Twine (links + variables + expressions). In particular, I'll be using Twine 2/Harlowe, and I haven't seen many tutorials for this new version published yet.

To me, the main "research questions" to ask about this kind of game are:
- What are the feedback loops? When I can do certain groups of actions over and over again, what is their cumulative effect?
- Does play ever stagnate -- i.e. is there a fixed point? Or, what does it mean for a game to stagnate even when I can always increase some stat? ("Click this button to increment a counter" is not very fun if that's all there is to it.)
- Where are the interesting strategic tensions? That is, at which points in the game does the player need to make a difficult decision? What makes it difficult?

All of these questions can be stated in terms of (though not necessarily answered by) a Twine prototype, even if the overall vision for the game involves much more complex rendering and controls. This is the same principle that leads to paper prototyping, but with computational support, which makes things like analysis and playtesting a lot less human-labor-intensive.

Twine Overview

Twine is a programming language for making browser-based link-clicky programs. But isn't that just, like, a webpage?, you ask. Yes! You could make all of the things you can make in Twine with HTML, CSS and JavaScript, and you sometimes need to know a little of all those languages anyway to get it to work and look the way you want. However, what Twine does is a small enough subset of webpages-in-general that it can give you just a few lightweight tools to create interestingly-playful experiences -- or at least, that's the idealized version of Twine that I'm going to try to target. :)

The main concepts in Twine are:

• Passages. These are units of text that get rendered as HTML, and they can also contain code. Passages can have links to other passages, and Twine's editor will render your game as a graph where passages are nodes and links between them are edges. While playing the game, there is a "current passage" whose contents are displayed (executed + rendered), and clicking a link changes the current passage and displays it.
• Links, via markdown syntax. A passage named "foo" containing the text "[[bar]]" will create a link from foo to bar that the player can follow. "[[Go to bar->bar]]" creates a link to the "bar" passage with the text "Go to bar."
• State, via assignable variables. The code that a passage can contain includes ways of setting a variable to a particular value and conditionally displaying text based on variables' current values. State is manipulated with macros such as (set: $foo to 4) and (if: $foo > 3)[...]. ($foo is a variable; all variables must start with "$".)

With this prelude, you should be able to follow along with the following steps. If you like, open up the story editor and try to reproduce the results.

Step 1: Create a Skeleton 

The architecture of this Twine game (and most of my examples in this series) will be as follows:

- An init passage to set up the game's initial state;
- A main passage to control the top-level game loop;
- Several appendage passage-subgraphs branching off of main to control the subsidiary components of the game.

So what I did first is:

Create a new story (I named mine "rpg").

Double-click the "Untitled Passage" and change its name to "init." Add a link "[[main]]" in the body of the passage.

Click the "x" to close the passage editor and notice that the editor has created a "main" passage for us with an arrow indicating the link from init to main.

Let's edit main to include three main game actions: resting, adventuring, and shopping. Double-click on "main" and add the following text:

You've been adventuring for $days days. You have $coins coins and your health is $hp. 

[[rest]] 

[[adventure]] 

[[shop]]

Edit the text of the newly-created rest, adventure, and shop passages to contain a link back to [[main]]. Now we have a skeletal structure that looks something like this:

At this point, you can test out what you made! Designate init as the starting point of the game, by hovering over the passage and clicking on the rocket ship, like so:

and then click the bug-shaped "test" button in the lower right hand corner of the screen. You should get a new browser tab to open, rendering the init passage with a link to main, which, when clicked, takes you to a main screen that looks like this:

Step 2: Initialize Variables

Ok, so we snuck some variables into our main passage (a naked variable "$foo" within text is actually shorthand for the macro "(print: $foo)"). But we never initialized them! It turns out that this means they get set to 0 by default, which is why your main passage has those 0s. But let's use our init passage to set them up right. Edit its text (before the [[main]] link) to:

(set: $hp to 10) 

(set: $coins to 10) 

(set: $days to 0)

Great! Now try testing the game again to see it print the new values of $hp and $coins.

Also, let's do one more thing before we continue: replace the [[main]] link with the text (display: "main"). This (display: ...) notation is a macro that displays (executes code + renders text) the passage whose name is given (in quotes!) after the colon. It simply removes the indirection created by the link. Testing the game now should plop you right into the main passage.

Step 3: Create the Adventure branch

Edit the adventure passage to contain the following text:

A monster appears! (set: $monster_hp to 3) 

[[fight]] 

[[flee->main]]

Now edit the fight passage. This one will be our most complex so far -- which makes sense, because we need to resolve an interaction between the player character and the monster. We will do so with a bit of randomness, introduced through the (either:) macro, which chooses uniformly at random between a comma-separated list of values given after the colon. At a first pass, we'll just simulate a 50-50 coin flip:

(if: (either: 0, 1) is 0)[ The monster bites you! ]
(else:)[ You hit the monster! ]

Between each of those pairs of [brackets], we'll need to write the logic for determining if the player or the monster survives and what to do in each case. In the first branch:

(if: (either: 0, 1) is 0)[  

  The monster bites you! 

  (set: $hp to $hp - (either: 1,2,3))  

  (if: $hp < 1)[ You are [[dead]]! ]  

  (else:)[ Your health is $hp. 

    [[fight]] 

    [[flee|main]] ]  

]

And in the second branch:

(else:)[ You hit the monster!  

  (set:$monster_hp = $monster_hp - 1)  

  (if: $monster_hp < 1)[ The [[monster is dead]]! ]  

  (else:)[    

    Its health is $monster_hp.
    [[fight]] 

    [[flee|main]] ]  

]

Finally, let's flesh out the new passages we made, the player death and monster death. Player death can just be a dead end:

You are dead! [[restart?|init]]

Monster death should drop some coins (let's say, a random number from 3 to 10) for our player to collect:

(set: $drop to (random: 3,10)) 

(set: $coins to $coins + $drop) 

You collect $drop coins from the monster carcass! You have $coins coins and your health is $hp. 

[[continue|adventure]] 

[[go home|main]]

Playtest this a couple of times and see if the constants -- the player character's health, the monster's health, and the weapon damage -- create an appropriate level of tension. You probably have some ideas for how to make this little combat loop more interesting, including different sizes of monster (with varying health and damage). Feel free to play around with those ideas.

At this point, we still have to implement the rest action and the shop action, but before we do that, let's think about how those actions should interact with adventuring. Adventuring can wear down your health, so resting should be an action that restores your health. Adventuring also yields coins, and shopping should put those coins to use.

Ok, let's think about resting first. Resting should refresh the player's health and increment the number of days. Change the "rest" passage's text to:

(set: $hp to 10) (set: $days to $days + 1) 

You feel refreshed. 

(display: "main")

However, if a player can simply rest to restore full health, then there's no incentive for them to do anything other than flee to rest after each monster kill. To create some kind of interesting decision tension, let's create a risk and corresponding reward for taking higher risk: on any single adventure, the adventurer carries her "spoils" from monster drops so far. If she abandons the adventure, all spoils are lost, but if she keeps pressing on, the drops get bigger.

First, let's change "[[adventure]]" in our main passage to "[[adventure->start adventure]]", then edit the newly-created "start adventure" passage to give some initial state for each adventure and display the main adventure passage:

(set: $spoils to 0) (set: $streak to 0) 

(display: "adventure")

Now change the "monster is dead" passage text to:

(set: $streak to $streak + 1) 

(set: $drop to (random: 3,10) * $streak) 

(set: $spoils to $spoils + $drop) 

You collect $drop coins from the monster carcass!  Your spoils are currently $spoils coins and your health is $hp. You've killed $streak monster(if: not($streak is 1))[s] on this adventure.

[[continue|adventure]] 

[[go home|collect spoils]]

And edit the newly-created "collect spoils" passage to update our primary pool of coins:

(set: $coins to $coins + $spoils) 

(display: "main")

Playtest a few times to try it out, tweaking numbers (and perhaps the drop formula) as needed.

Let's step back just a bit (by literally zooming to the "just passage titles" zoom level) and look at the structure we've created so far:

A few edges are missing due to the use of "(display:)"s rather than [[links]], but otherwise this gives us a pretty clear picture of the control flow in our game! It's not quite all we need to reason about resource feedback loops, since those happen in variable changes "behind the scenes" of the link clicks -- but this view at least lets us approximate which game states are reachable from others.

We haven't implemented the shop action yet, but I'd like to save it for a later post so that I can gab about datatypes for representing "items" (like weapons) and the difference between what I'd consider ideal, and what Twine 2 offers us currently -- without making this post too egregiously long.