Note: This is going to be less fun than playing the Twine game, so I suggest playing that first and then reading this if you want some context.
Click Here to Play the I’m Not Here Twine Game
A little background: Twine is “an open-source tool for telling interactive, nonlinear stories,” which is to say that it’s a program that allows users to quickly build the digital equivalent of branching choose-your-own-adventure stories. These games vary wildly in their sophistication, but Twine is simple enough that you could teach yourself to use it in an hour. The Choosatron is a “deluxe adventure matrix,” i.e., adorable toy, that lets users play Twine games. Rather than displaying your game on a monitor, the Choosatron prints your game on a scroll of paper as you play, creating a physical artifact of your experience and the choices you made.
Several months ago, Matt Williamson asked me and several other writers if we would like to write Twine games to promote Unstuck at AWP 2014. They were going to set up a Choosatron at the table. Visitors to the table would be invited to play one of the games. I had been meaning to make something with Twine for most of the previous year; I’d already tried once and failed due to frustration with bugs in the Mac version of the program. So I was happy to have a reason to try it again, and of course I love Unstuck, which also hosts a recurring column I’m writing on repeating themes, mechanics, and ideas in games.
I failed to make three games over the course of the next several months, then wrote the one that finally worked in the course of one night. I’ll talk about the failures first.
One thing that helps me when I’m trying to learn a new form is to work on the basis of formal limitations. In Twine, the usual format is that the game describes an environment like a room or a cave and then gives you some options. “You are in a dark cave. There is a candle on the table. You have a match. Do you want to light the candle? Or would you rather, I don’t know, eat it?” (One thing interactive fiction developers often struggle with is creating multiple plausible paths; there’s usually one best or most logical option.) You make your choice, then the game tells you how the environment changes as a result. “You successfully light the candle. The cave is now less dark. Good job.” I decided to invert this relationship: the player would determine broad facts about the environment, and then the game would tell the player how the main character behaved as a result. In other words, there was an early moment in the game where the player was asked to decide whether it was winter or summer. The character would then behave differently throughout the rest of the game based on that choice.
This turned out to be over-ambitious for my first Twine game. (It also wasn’t technically feasible with the Choosatron, for reasons I’ll address later, but I didn’t know that at the time.) The biggest problem was that even a small number of decisions about the game’s environment had a huge number of potential ramifications. Just accounting for four or five variables of this kind was maddeningly complex. Also, the story I was trying to tell (that of a woman who sees or does not see a car accident and finds or has brought to her by her dog a resulting severed hand) was kind of stupid and aimless. So I gave up on that idea and waited for a little while.
My second attempt took a similar approach. The protagonist was a man alone in a cabin. There were very few objects in the cabin and there was nobody outside the cabin. Then someone knocked on the cabin’s door. The player’s choices mainly had to do with explaining why the protagonist was alone and who it was outside the door; again, rather than having the player make decisions for the protagonist, I emphasized the player’s decisions about that character’s environment and context. I thought that the limited environment (the cabin) and the very small cast (at most, three living participants) would make this manageable, but I was dead wrong. Also, the tone felt completely off. Most Twine games, like their choose-your-own-adventure predecessors, are hopelessly goofy. The rest are painfully self-serious. What I made fell into the latter category. It was awful. So again I hit the reset button.
At this point Matt Williamson emailed me to let me know that I was running out of time. I spent the next two weeks working on a story about two maids cleaning a potentially dangerous billionaire’s surreal house. There were six weird rooms in the house. The maids were supposed to clean six of the rooms. In fact the player would only be allowed to clean three. The real goal of the story was determined without the player’s knowledge in an early exchange between the maids. At the end of the story, depending on certain decisions, the player would either succeed or fail, and would in either case be rewarded with a depressing ending. So at this point, I had dropped my formal conceit (letting the player make decisions about the environment rather than the character) and was focusing on making something that felt more like a game with failure states, win states, and content that would remain relatively fresh through several playthroughs. This was a terrible design given the purpose of the game (to promote Unstuck at AWP, where the player’s time would be severely limited) but it seemed like my best idea at the time.
I was on the verge of finishing the game when it occurred to me that I should check the Choosatron’s documentation to make sure all of the Twine features I had used were supported by the platform.
They were not.
The major advantage of Twine over a choose-your-own-adventure book is that Twine can track variables and do basic operations on them. So rather than dealing with the hassle of building ridiculously elaborate trees in order to account for all of the combinations of choices a player might make, I used variables to track some of the player’s key decisions in the game. For instance, there was a variable that tracked how many rooms the maids had cleaned. When the variable was equal to the number 3, the game would change its rules and lead the player to the ending. It would be possible to do this kind of thing with a tree, but it would also be a truly miserable hassle.
Unfortunately, it turns out that the Choosatron doesn’t support variables.
Speaking as an amateur programmer, this decision on the part of the Choosatron’s creator truly mystifies me. The storage and manipulation of variables are not advanced computer functions — they are the basis of every interesting computer behavior. When you describe a room in Twine, you’re essentially defining a variable and storing it for later use. If the Choosatron is capable of running Twine, it really should support variables. It had never occurred to me that it might not.
None of the games I had attempted to write for Unstuck would work without variables. I wrote an irate email to Matt apologizing for the fact that I had wasted so much time and still failed.
I told my wife how angry I was about the Choosatron. I played Spelunky as a way of working off some steam. Spelunky is not really the kind of game that should be played in anger. I did badly.
My wife went to bed.
I couldn’t let go. I had failed for literally months at one simple task. I had wasted a stupid amount of time on work that wouldn’t pay and in fact would not likely be seen by more than a handful of people. I felt ridiculous.
So I wrote a fourth and final Twine game.
The absence of variables turned out to be useful as a formal limitation — not one that the player would see, but one that kept my ambitions in check. Whatever I made would have to be a pure decision tree. Because that night was my deadline, and I had work the next morning, and it was already late, whatever I made would have to be completed within the next two or three hours. This implied a small game with few words and limited choices. Another thing on my mind was the fact of death. I had been struggling for sleep for weeks because of my increasing anxiety about the fact that I would someday die, and so would my wife. I would be writing my game in the hours that I usually set aside for freaking out about death. So I knew that the game should be about death, since I was going to be thinking about it anyway.
The rest came very easily. Though it may initially appear to have many more decisions, each game of “I’m not here.” contains two decisions that actually affect the course of the story. The rest don’t really matter: the player can click any one of several links and get the same result as if he clicked any of the others. This was partly due to the small supply of time I had to work with, but it also related to one of the central problems of Twine games as they are typically written: the proliferation of choices often lowers the stakes for a story and dilutes the player’s sense of agency.
To see what I mean, let’s think again about the dark cave and the candle. If you’re offered a choice between lighting a candle and eating it, both options actually end up looking stupid; if your character is the sort of person who might plausibly eat the candle rather than light it, then why should we care if he lights the candle? Obviously every choice he makes is arbitrary and unimportant. This is an extreme example, but the fundamental problem is one you’ll see in most interactive fiction. Either the choices you’re given are so contradictory that they effectively cancel each other out, or you don’t feel that you were given any meaningful choices at all.
In “I’m not here.”, I tried to address that problem by constructing most of the choices such that they were all equally true for the protagonist. These are clearly all thoughts that the same character could have and is having. The player chooses between them to express agency and emphasize one aspect of the character over others, but ultimately the character is a combination of the player’s choices and those options the player did not choose. This seemed especially appropriate on the Choosatron, which always gives the player his or her options by printing them out on the scroll — in other words, by making them part of the text. Since every option would ultimately be a part of the story’s physical form, I decided to write as if each option was canonical — as if each potential action of the player was equally canonical. My solution wasn’t perfect, but I do think it was a little bit interesting.
As far as I know, only one person played my game in person. (I assume there were more, but I don’t know it for a fact.) So I’m quite glad to share it with you.
