Inside Interactive Fiction: An Interview with Emily Short

All too often, video games are completely boiled down to glitzy graphics and body counts. If you look at many of the best-selling games of today, you can condense their story lines into one quick sentence, if they have a story at all. That's what makes Interactive Fiction so interesting.

Recently, Gamasutra sat down and spoke with Interactive Fiction writer and game designer Emily Short about pacing, design and what comes next for game writing.

GS: One of the things I immediately liked about Savoir-Faire was that the goal was laid out plainly as "an interactive search for loot." This proves to be slightly misleading since as the story progresses the history of the characters becomes more and more prominent, but I admired how it ramped up to this. A lot of games seem to expect you to want to figure out what you're supposed to do, so I liked the initial straightforward goal. How did this structure come about?

Emily Short: Savoir-Faire sets out to emulate games by Infocom and early amateur IF authors. It's a little subversive in a few places, and it applies more recent standards of fairness, parser flexibility, and internal consistency. But it's not a parody; it's a good-faith attempt to make a game that's fun in the same way that many of the old classics were fun.

Many of those games are essentially just big treasure hunts in a deserted area, so I made that the nominal goal of S-F as well; then I wrote in a plot arc that would explain how the player got these unusual abilities and why he's in this fix in the first place.

GS: What do you think about "pacing" interactive fiction?

ES: The game should stay fun for as long as it takes to play; no aspect should take more of the player's attention than it deserves.

What that means in practical terms will vary a lot from one work to the next. In Savoir-Faire I mostly thought in terms of puzzles and their rewards.

The first issue was providing enough fun. Every puzzle should have some reward, and a complicated or multi-stage puzzle should provide some minor rewards for partial solutions. So once I had the puzzle structure in mind (more about that later), I could see which puzzles were going to open a lot of new game-play and which were only going to bring the player up against another puzzle -- the structural equivalent of getting through one locked door to find that there's another beyond it. Everywhere there was a puzzle without much game-play reward, I added plot material for the player to discover instead -- ideally, a hint that raised more questions than it answered, something that would both reward him for getting part-way through the puzzle sequence and keep him interested in what would turn up next.

The other point had to do with managing player attention. The more time a player spends in the presence of an unsolvable puzzle (say, a door he can see from the first room but that stays locked until half-way through the game), the more importance he tends to attach to that problem. It's a huge let-down to walk through that door and find that it leads to a broom closet with one cheap treasure in it. So the big puzzles, the puzzles the player has been taught to care about, should pay off in multiple ways at once: both major new game-play and major plot information.

This is standard game design stuff, but not all IF works the same way. A narrative piece might be structured around scenes rather than puzzles, and it might be easy enough that the player never really gets stuck. In that case, you have more conventional-fiction concerns instead: making it clear what the important conflicts are, foreshadowing major scenes, letting the player spend enough time around characters to care about them, and so on.

Then you spend more time asking questions like "What is the minimum number of turns the player could spend on this scene? What's the maximum? If the shortest play-through is too short to be emotionally effective, what other interaction can we add to the scene to keep it lively? If it's possible to play a scene so slowly that it loses its punch, how do we hurry the player up? And what about the overall structure? If the total buildup to a crisis scene is too short, where do we add material (or whole scenes) to prepare the player better for what's coming?" And so on.

GS: The writing is gorgeous and historically grounded but not at all stiff -- it flies in fantastical loops right out of the gate.

ES: Thanks!

GS: Did you develop your craft in short stories and novels?

I haven't published any of them, but yes -- like many people interested in creative writing, I've written a number of short stories and one novel. I've also belonged to a couple of fiction workshops.

I think my nonfiction writing has had a larger effect on my prose style, though. One of my other hobbies is writing travel narrative, which is good practice when it comes time to compose dozens of location descriptions.

GS: I've been playing your game in the morning, on the Gargoyle interpreter on a small part of my screen. I don't know if it's Gargoyle's nice typography, the puzzley nature of your game, or its historical nature, but the experience reminds me strongly of someone doing a crossword puzzle. Specifically, in their solarium on a folded up newspaper. Which is strange because I'm not a fan of crossword puzzles, but interactive fiction seems to fit that niche for me.

You're an active interactive fiction player yourself, what niche does it fit for you?

ES:That's hard to answer. I tend to regard it as its own thing, not quite like reading a book or doing a puzzle. If anything, playing IF is most like writing IF: there's a reason the community has so many members who do both.

GS: Currently, I'm stuck in the game. But I find myself wandering around the grand old empty house, examining things I never thought to examine and discovering a real generosity in detail. I'm trapped but not frustrated -- which make me think that if you're going to design an oubliette, make it a beautiful one. You have other games which are more experiential, not meant to be "solved" or "beaten." What's the player reaction like for puzzley games vs. more experiential?

Both styles have their fans. Puzzle games often produce more discussion, in the form of people asking one another for hints, and that can be fun for the author to watch. But, judging from the email I get, the experiential work affects players more emotionally.

GS: What do you like about writing each?

ES: Constructing a puzzle game is itself a kind of puzzle, and I enjoy it on that level. With Savoir-Faire, I wanted to teach the player the magic system gradually until he felt as competent as the player character. I also wanted to re-visit a lot of old puzzle chestnuts, such as dealing with a key that's on the wrong side of the door, but use a solution that had never been done before. And I had a bunch of ideas about the kinds of things the magic system in S-F would let the player do. So the challenge was to figure out how those magical abilities could be turned into novel solutions for the puzzles I had in mind, and how to structure the whole thing so that the puzzles used more complex applications of the magic (without necessarily getting a lot *harder*) as the game went on.

Making the big puzzle-structure chart is one of my favorite things in IF creation: sitting down with a pencil and paper (or, these days, OmniGraffle) and moving lines and boxes around until I'm satisfied that the whole thing works. The process for Savoir-Faire was cleaner than it is for most of my games -- a lot of the time I wind up revising the puzzle design a lot, whereas with S-F what got implemented is pretty close to what I originally wrote down.

Incidentally, though it doesn't refer to Savoir-Faire, this gives a pretty detailed description of how I plan a game like this, including a bunch of puzzle design diagrams.

My more experiential work uses interaction to get people to engage with fiction in a new way: to tell a story where a moral choice falls to the readers rather than to the author, say, or to allow readers to forge their own relationships with a character. There the fun part is more like the fun part of writing conventional fiction. With my most recent game, Floatpoint, I did a lot of the exercises you might find suggested in a writing workshop: inventing a detailed setting with a map and history; coming up with personal histories for the characters; writing up important background scenes, even if they weren't going to appear in the game anywhere.

That material was very useful when it came time to write the most demanding passages of the game, namely the correspondence the player receives from other characters and the cut scenes that occur as endings. I do a bit of world- and character-building for puzzle-centric games too, but it tends to be lighter and less important to the final product.

GS: One of my favourite experiences so far was in playing with the "link" power in the game -- you can link similar objects magically. I was just playing around and linked the cuckoo clock with the snuff box, and then wandered off. Couple of turns later I was told the snuff box had opened -- and then closed. That seemed random. Then a few turns later, it happened again, and I realized that it was because the clock was opening to strike the hour.

Most of the puzzles in the game are related to the attributes of the objects you come across (openable? breakable? edible?) and this allows for multiple solutions and a greater feeling of immersion -- I expect you never "scripted" that particular moment. Smart objects that have their own built-in physics are also what make games like Half-Life 2 great, and really are less of a technological advance and more of a object oriented programming approach. When did you start to implement this approach and what impact does it have on your game making?

ES: I've been interested in this approach since I first started writing IF. One of my earliest games (Metamorphoses) is even more systematically about object properties than Savoir-Faire.

I enjoy writing the kind of game where the player becomes increasingly skilled at applying the rules of the game-world, rather than facing off against a bunch of unrelated single puzzles; it's easier to do that if you start with a consistent world model that supports most of your puzzle interactions. Having such a world model in place tends to provide a bunch of "toy" functionality as well -- fun secondary effects that the player can fiddle with when he's bored or not making progress.

GS: What kind of editing/playtesting process do you have and how does it differ from your IF making peers?

ES: Usually I draft the world model and the opening scenes -- enough to demonstrate the kind of interaction that's going to make the game work. For Savoir-Faire, for instance, that meant building the magic system, then implementing a few puzzles and enough rooms to give a sense of the setting.

Then I show the prototype to someone. Occasionally my alpha-tester finds the premise unpromising, so it gets scrapped. More often, we decide that I'm going to need to add features to improve the player's experience -- things like a recap verb for a conversation-heavy game, to let the player review what's already been said without taking notes. It's much easier to write such features into the game from the beginning than it is to patch them in later in response to beta feedback.

After we've vetted the prototype, I design a structure for the rest of the game and implement it. As I write, I play through it myself a lot. I try to forget what I've implemented and just type what comes naturally to me as a player; I turn up a lot of under-implemented bits that way. I also do most of my prose editing as I play. This is
also the stage at which I write test scripts and commands to verify any aspects of the game that can be automatically tested. In the case of Savoir-Faire, I had a link-checking command that would go through all the objects and test to determine which combinations were considered valid for linking. This exposed a lot of ridiculous implausibilities, so it was better to look for them explicitly than to hope that beta-testers just happened to find them all.

When I have the game to where it can be finished, I start beta-testing. I have worked with a number of beta-testers, and I pick a crew to work on a new project depending on their skills and interests; some are more interested in testing puzzle games than others. And I try for a balance of people who will approach the game as players (trying to experience what any other player would experience) and people who will approach it as testers (deliberately pushing the boundaries of the system). The second group identify more bugs, but the first group give the best feedback on structural and thematic issues. I encourage all my testers to send me their transcripts of play as well as comments, and I often follow up with some live conversation about how best to resolve flaws in the game-play.

This is similar to the process most IF authors use, with maybe a couple of exceptions. I'm not sure everyone does an alpha-test before committing to write a full game; picking an alpha-tester is harder than picking a beta-tester. You want someone who is perceptive and articulate about game design and who has enough IF experience to spot cliches and stumbling blocks; someone who will be tactful, but honest enough to advise you against finishing the project if they think it's not worth following through on. This is hugely valuable and not easy to find.

I also make heavier use of automated testing these days. The traditional attitude is that you should get a bunch of beta-testers to hammer on your game until it seems to be in good shape, then release it. You might keep one script around to play through your
game and automatically make sure the winning end is reachable and produces a consistent transcript, but that's about all. This is changing -- recent development systems are designed more with debugging in mind, and lately there's more mention in the community of version control and regression testing. We haven't reached a point
where there's any real sense of best practice about this kind of thing, but we're making progress on it, and the tools are improving.

GS: Speaking of your peers, does the interactive fiction community influence your game making?

ES: Yes, hugely. I draw a lot of inspiration from other people's work and from the feedback I receive on my games.

GS: How does this online community differ from any other communities you might participate in?

ES: It's small, for one thing. Most of the other online communities I belong to are considerably larger. There are good and bad effects from that: each active participant has a big effect on your experience of the group and relationships tend to be more charged. I have closer friends in the IF community than in any other online community; I've also run into more personal frictions here. On the whole, though, the balance comes out positive.

The other point is that IF tends to attract people with broad intellectual interests. To be a good IF author, you have to be part writer and part programmer, and that makes for an interesting group.

GS: You were commissioned to make City of Secrets by a band called Secret-Secret. Was it collaborative?

ES: Somewhat. The band gave me a narrative outline and some sketches of the setting and characters they were envisioning. The outline had a lot of detail at the beginning and end, and very little in the middle; most of the plot twists and mid-game ideas were mine, but the beginning and endgames were largely theirs, and some of the dialogue
in critical scenes was based on their lyrics. I sent them updates of the game as I wrote it and they sent back feedback, as well, so there are a few areas where we worked out the design together.

GS: Was there a backlash in the IF community, whose participants almost never get paid for their games?

ES: If anyone resented this, they were too kind to tell me so. But then, the amount of money involved wasn't large.

GS: You have recently contributed heavily to Inform 7, an interactive fiction creating application that makes it even easier for non-programmers to make interaction fiction. So far, have you noticed any fruits for this labour -- ie., new games from non-programmers?

ES: Yes -- not many, yet, but the second place winner of IF Comp 2006 was written in Inform 7 by a new author who said that he had not been able to get into IF authorship before.

I like to think this isn't a fluke. We've gotten a lot of email from people who have started writing IF for the first time because they find I7 easier to get into, or who have resumed work on old projects that they found too frustrating to complete in previous languages. I7 is also being used with some success in new media courses where college students create their own small IF projects. So it's early yet -- Inform 7 has been out less than a year -- but I think the initial indications are encouraging.

GS: Personally, as someone who made a game in an older version of Inform, it makes me feel like I can focus on the experiences and environment of the game without being tripped up by a missing semicolon or something -- however, I've yet to use it. Have other people who have worked in earlier versions of Inform been aided or affected by Inform 7?

ES: Reactions have been split. Some authors used to previous versions of Inform find the new format challenging to get into, because they like a more program-like style or because they're familiar with the Inform 6 library and don't want the bother of learning to do the same things in a different way. That's fine -- Inform 6 is still supported, and
people who want to go on using it are welcome to do so.

On the other hand, some have embraced the new version enthusiastically. While it's intended to be accessible to non-programmers, Inform 7 shouldn't be regarded as a beginners' language: it includes some powerful features that were never in I6. I personally find it faster to write in, more flexible in many respects, and considerably more fun. And I'm not the only former I6 author to feel this way.