• Tweet

• Tweet

I wanted to finish off my series of Interactive Fiction posts with some hints and tips for the new IF writer. Unfortunately, I’m new to this myself, and therefore not really qualified to give advice on such a unique form. So, instead, I asked some well-known IF authors to do it for me! This week, I am very proud to present insight from Emily Short and Stephen Granade.

Yes, you read that right IF fans! I sent some carefully considered questions out to accomplished and established authors, and was delighted when I received some positive responses. Not only that, but the answers given were so complete that I realised I could not limit this to just one post. Emails are still going out, so this is currently a series of undetermined length, but I can promise you at least three posts of useful IF tips and insight. What follows is a brief bio of each of the contributors for this week, followed by the questions and answers themselves. I would like to extend my sincerest gratitude to both Emily Short and Stephen Granade for being so generous with their time.

Emily short

Emily has written a slew of works of interactive fiction, has won numerous XYZZY Awards, and the Interactive Fiction Competition (IF Comp) as well. Not only is she a prolific author, she has been an enthusiastic contributor to the IF community and also to the study of IF, writing numerous articles (available on her website), and being interviewed on the subject (including this article, originally printed in Edge magazine). She is also a contributor to Inform, having written almost all of the examples, and the (extensive) recipe book that is included with the manual.

Stephen Granade

Stephen is a physicist who has authored many interactive fiction stories. He has been a winner in the XYZZY Awards, and has been a finalist numerous times, and is the current maintainer of IF Comp. He also appeared in the documentary GET LAMP. He can be found online in a variety of places, including Twitter, his Brass Lantern site, and his family site, Live Granades.

1. How do you decide that a piece of fiction should be interactive, rather than a traditional story?
   

   Emily: I write much more IF than I do traditional fiction, so usually I’m coming in with the assumption that what I create is going to be interactive, rather than the reverse. But I’d say that you shouldn’t write an interactive story unless you have something specific in mind for the player to do. That might be “explore this world in a self-directed way” or “choose a direction for the plot” or something else entirely.

   Stephen: It needs to be a story that depends on or is greatly enhanced by interactivity. I like to start by thinking of what kind of interactions the player will have with the game and then write the story to emphasize them. I find it much harder to start with a pure story and then try to graft interaction on top of that.

2. What software do you use to write your IF, and why?
   

   Emily: I use Inform 7, and used Inform 6 before that. I got started with Inform simply because it was the first IF language I found out about; I didn’t know TADS existed until later. And then I was fairly extensively involved with the development of Inform 7, so I’m very comfortable with it at this point.

   Stephen: I started off using TADS 2, but these days I use Inform 7. I’ve found that I really do well building up the game world using I7’s rules-based approach. The rules provides a remarkable amount of flexibility and a powerful way of building up a game world. For example, in my most recent game, Fragile Shells, I included a chain with two ends. You could tie one end to an object and then carry the other end into another room. This is one of those classic things that’s hard to get right in IF, but in about two hours I had it coded up and working nearly perfectly. A lot of that is thanks to I7’s rules-based structure.

3. What’s the first thing you do when starting a new piece of IF?
   

   Emily: A new piece usually spends a bit of time as vague ideas floating around in my head, and sketches on paper.

   Once I’m ready to start building, I usually start by coding the part of it that I think is going to be the most difficult. That means I can find out quickly whether the idea is one I can execute, and I don’t put a lot of time into doing the easy parts of a project and then run out of steam when I get to the harder parts.

   Stephen: I decide what the game is about, what its central elements are, and then I make sure that I design the game to emphasize those elements. What’s my concept, and why is it cool? Whatever makes it cool is what I need to highlight. What kind of interactions do I want the player to have? I’d better make sure the game is chock-full of those interactions.

   Let me use two of my games as an example. Fragile Shells is about being trapped on a damaged spacestation and needing to escape. I was riffing off of classic “Escape the Room” flash games, so I wrote down every clichéd escape-the-room puzzle and trope I could think of and then figured out how to twist each one so it had a logical and sciencey solution. Child’s Play is about being a baby, so I coded up some quick tests of baby-like behavior and tried to figure out how to make most of your interactions be things that emphasized those behaviors, like knocking things off of tables or pulling up on furniture.

4. How much time do you spend planning your stories versus writing them?
   

   Emily: It’s an iterative process: I do some planning, implement some, see how the process is going, revise… So I couldn’t really say how much is planning and how much is building.

   Stephen: I spend anywhere from a week to a month to several months planning before I get started coding. There’s always the temptation to jump in and start coding immediately, but I always run out of steam if I take that approach. One thing that’s greatly helped me is to write a transcript of the full game before I start coding. It lets me think more like a player, and I end up making notes to myself in the transcript along the lines of, “[REMEMBER TO HINT THAT YOU CAN OPEN THE DOOR LATER]”.

5. IF takes the practically unique second person perspective. With the reader essentially playing a character, do you expect your readers to roleplay, or do you prefer to give them as blank a canvas as possible?
   

   Emily: That depends entirely on what kind of work it is. Sometimes it’s about letting the player project himself onto the role as fully as possible and enjoy the fantasy of living in this environment and solving these problems. Sometimes it’s about getting the player to empathize with a specific individual.

   Stephen: Roleplay, definitely. There are games where having a blank-slate character works, but I find it easier to tell the stories I’m interested in if there’s a real character in the game, one with a history and reactions and all.

6. There can be an overwhelming amount of choice for the reader. What do you do to signpost important objects or interactions for them? When you restrict their choices instead, how do you make sure it is done in a realistic way?
   

   Emily: IF has conventions for signposting objects that matter a lot: they’re often given their own paragraph in a room description.

   Similarly, if the player is supposed to try any action that’s at all unusual, it’s a good idea to give him the verb in the text somewhere first, show an NPC doing the same thing, or provide a tool that suggests that action. If you hand the player a screwdriver, he’s much more likely to try unscrewing things. If you show an opera singer going around singing arias, he’s more likely to try singing himself.

   But you’re always going to be restricting the player as well. These are two sides of the same coin. The player can only do what you’ve implemented to be possible, and there’s no way to implement “everything” (whatever that would even mean). A lot of the time, making those restrictions palatable is about making it very clear what the player *can* do, so that he doesn’t waste time experimenting with many many actions that are never going to result in anything.

   Still, you also get cases where the player wants to do something that is within the range of what you’ve implemented, but is a bad idea in this specific case. For instance, say I have a magic system that lets you burn things in order to invoke a flame spirit to do your bidding, and now the player wants to burn up a cedar box he’s found… only I know that he’s going to need that box later in the story, so if he burns it now, he’ll make the story impossible to finish.

   At that point, you can do a couple of things. You can redesign the puzzles so that the player isn’t being tempted to do something foolish. You can make the player character unwilling to do the action — maybe it’s a valuable box and the character is too greedy to be willing to burn it. Or you can add some kind of warning to the player directly, like “That seems dangerous — would you like to save your place first?”

   Stephen: That’s tough. You can play tricks with descriptions, putting important things early on in room paragraphs or giving them their own paragraph. You can model interactions by having NPCs do the kinds of tasks that you expect the player to do later. You can train the player by having easy puzzles early on that guide them into the interaction you’re looking for.

7. There is potential for a tangled web of intersecting paths through a story. How do you keep track of everything?
   

   Emily: I make charts. There’s an example of this online for my game Bronze. This pretty much documents how the puzzles and paths evolved, and the diagrams show how I kept track of it all.

   Stephen: Trim ruthlessly. Keep sections of your game inaccessible (for good in-game reasons!) until the player has finished some tasks. When your game is done, have it tested by a lot of people and have them send you transcripts so you can see how they went through your game.

   Speaking of which…

8. How do you go about testing your work?
   

   Emily: I usually build a prototype of the gameplay that demonstrates its concept. That contains a draft form of the most challenging code, such as a conversation system or code to simulate the story’s form of magic, so that we can see how the thing would work in practice.

   I share that with someone. We decide whether it seems like an idea that’s going to be fun to play, and we also talk about what’s going to be necessary to make this concept work.

   Then I build out the rest of the story, using a fair amount of automated testing: Inform provides tools to write tests that you can run through automatically to make sure that the story is performing as desired, and I create special test cases. I also play through a lot myself.

   When I’m done with that phase, I show the story to a group of beta-testers, who do their best to break the system. How many we need really depends on how big the story is to start with.

   Stephen: I play through it a lot myself, trying to forget what I know about how the game works and how it’s been written. Then I turn it over to a handful of people to test. I ask them to save transcripts of every playthrough so I can see exactly what they were doing and look for problems they might notice. A tester might not tell me that the opening scene took too long, but reading their transcript will show me.

9. What’s the most valuable mistake you have made writing Interactive fiction?
   

   Emily: My first attempted work was a game that was going to let the player wander around a fully-implemented town in Oregon. I was going to have everything that is most difficult to implement in there: fire, water, people who talk and wander around and pursue their own complicated goals in the world.

   There were going to be cameras you could take Polaroid pictures with, lights with different light levels, a weather system, glass you could break, shards you could cut things with, ropes you could tie to objects… *everything* I could think of.

   I got a lot of interesting code out of working on that project, but what I didn’t get was a game. The premise “the world will have everything!” is not a story concept. It’s a recipe for disaster. It’s much better to go in with one specific thing you want to achieve, and execute that really well. If that happens to include building out a liquid system or weather that changes over the course of the story, that’s fine. But you need to have a reason for everything you put in, or it will just get out of hand.

   Stephen: While I’ve learned from my mistakes, I don’t know that any one of them proved to be the most valuable.

   No, wait, I lie. It was entering the first IF Competition with a poorly-implemented game. The competition left me with bad reviews, a low score, and a burning desire to do much better.

10. If there was only one single tip you could give a new IF writer, what would it be?
    

    Emily: Play other IF and read the reviews. It will help you understand what works and why. A lot of IF authorship is about being able to look at your own story in progress, identify what isn’t yet working, and come up with strategies to fix it.

    Stephen: Decide what makes your game cool, and then maximize that cool thing. Don’t apologize for the game or its coolness.

Further Reading