Because this is a long one, here are some quick links in case you came here for a specific tool:
Twine     Inform     TADS     Quest     ADRIFT

Twine (Mac, Windows, Linux)

Twine is the simplest way to create a text adventure, and therefore the easiest to use. Twine writers produce stories using a graphical interface. Each piece of text is represented within a box, and lines link each box, showing the routes the player might take through the story.

The work is compiled in HTML format, and works on any browser that supports javascript (and has it turned on. That’s practically everyone, by the way).

The graphical interface makes it immediately obvious what is going on. Editing is done by double-clicking a box and typing in the resulting form. Creating a new box is as simple as double-clicking in an empty space.

Links within the text are defined by surrounding the word(s) in double square brackets [[like this]], and choices outside of the main text are the same, only with a * character in front. And that is seriously all you need to get going.

Twine uses a graphical interface to show its simple text and links concept.

For more information, there is a video tutorial series that explains everything you need to know and will definitely help you decide if this is your software for writing Interactive Fiction.

If you want to “go deep” with Twine, you can add your own HTML and stylesheets. If you don’t know what I’m talking about, then you probably want to leave those features alone (you are basically editing web pages at that stage).

Some people may find Trine too simple for their purposes but it depends what kind of story you want to create. On the surface, it seems more geared towards Choose Your Own Adventure style stories than text adventures but there is the accompanying Twee syntax for stories that are more involved (thanks for the hint from Horace Torys in the comments).

Twee has the concept of variables and expressions, and there are tutorials for doing things like creating an inventory, or tracking the number of bullets left in a gun for example. It remains basic and abstract – it doesn’t know what a “door” is and what it can do, nor an object or player-character for that matter. But it still serves as a good entry into the more complicated aspects of interactive storytelling.

Inform 7 (Mac, Windows, Linux)

Inform takes a writerly approach. In the same way Interactive Fiction uses a verb-based system to make it easy to play/read, Inform has tried to make its source code like writing English. You describe what the player sees.

The interface is split into two panes, each of which can show a variety of helpful tools and resources (or your story of course).

Inform’s coding style is an intriguing concept. Rather than write code, you can do a lot by writing a natural-English paragraph. Inform will then interpret what you’ve written and sort the various objects into types, which automagically have certain properties and available actions. Take this example from the documentation:

East of the Garden is the Gazebo. Above is the Treehouse. A billiards table is in the Gazebo. On it is a trophy cup. A starting pistol is in the cup.

There are three rooms here and three objects, each of a different type. The language is very powerful, allowing for all sorts of interaction. And it’s extensible, so if there is something you need, you might find a plugin that includes it (or write your own).

There is a caveat. Just like Interactive Fiction disengenuously promises the world with its blinking cursor, writing Interactive Fiction with Inform is not as freeform as it appears. It is still code, and beginners will run into problems because they haven’t written things in the “right” order, or they have omitted punctuation that seemed unnecessary. If you’re not used to that, I can see what was intended as a useability feature becoming frustrating.

However, once written it’s incredibly easy to understand and so learn from the work of others.

Inform has a powerful and surprisingly complete suite of tools

The documentation is excellent; full of examples, sensibly organised, and viewable alongside your source code, thanks to the two panes of the interface. It is also well-written – concise, thorough and informative. It is not often I enjoy reading a manual!

Other tools include a Skein (a visual representation of a reader’s journey through the story) a full transcript of any given playthrough, and an automatically generated map of your world. All powerful stuff, if a little intimidating to the beginner.

Inform is my favourite. Not only does it tick all of my joy buttons by combining writing and coding, but it’s impressively complete, and takes a professional stance on useability that is missing from the others. The Mac version especially, is a joy to use.

If you’re familiar with Scrivener (and you should be), consider this the Scrivener of Interactive Fiction.

TADS (Mac, Windows, Linux)

N.B. The TADS site recommends using frobTABS if you’re on Mac/Linux. Below I’ve looked at the TADS 3 Author’s Kit for Windows. See the download page for more info.

TADS stands for Text Adventure Development System, and is as techy as that sounds. This is Interactive Fiction software for programmers.

It is written in a text editor (TADS Workbench is a specially designed text editor for this purpose), and each room, object, interaction, description is defined in a strict syntax. The TADS 3 format that’s produced can be played on any interpreter.

Here is an example of the code (with comments removed), just for the sake of comparison:

entryway: Room ‘Entryway’
“This large, formal entryway is slightly intimidating:
the walls are lined with somber portraits of gray-haired
men from decades past; a medieval suit of armor<<describeAxe>>
towers over a single straight-backed wooden chair. The
front door leads back outside to the south. A hallway leads
north. ”

describeAxe
{
if (axe.isIn(suitOfArmor))
“, posed with a battle axe at the ready,”;
}

north = hallway

south = frontDoor

out = frontDoor
;

+ frontDoor: Door ‘front door’ ‘front door’
“It’s a heavy wooden door, currently closed. ”

initiallyOpen = nil

dobjFor(Open)
{
action() { “You’d rather stay in the house for now. “; }
}
;

If you can understand what’s going on here, you should be fine. If the sight of it sends you into waves of panic, TADS is probably not for you.

The manual is large, but I found it tended to waffle a bit. I recommend starting a new project on the “easiest” setting and opening the .t file within. This contains basic structure for your story that you can edit. Most importantly, it is heavily commented. It’s a great place to start and very instructive.

You are not restricted to one file of code. In fact you can have as many as you want, allowing you to organise your project how you like. The manual recommends splitting your project up one file per room, for example.

Debugging tools are available that will be familiar to programmers. Break points stop running code at a specific line so you can check the status of watched variables. For simple text adventures, this won’t be necessary, but when it comes to testing complicated logic, they can be invaluable.

Although Inform’s text approach is easier to read, you do have to read it. If you’re a programmer you’ll understand how TADS layout may make a room easier to understand “at a glance”. Plus, its strict syntax could make it easier to debug (I haven’t spent enough time with both to know for sure, but this is going from my knowledge as a programmer).

Quest (any browser, or there’s a Windows app too)

Thanks to mistermole for pointing out Quest in the comments.

Quest is a browser-based, form-driven editor. The game maker can be loaded in Internet Explorer (or Firefox, Chrome etc.), and the finished games can also be played straight in the browser.

Because of this, it’s very easy to get started – there is nothing to download and signing up can be done using your Facebook or Google account.

Once inside, click to start a game and you’re presented with an intuitive interface. Your project tree is down the left hand side of the screen and contains all of your rooms, characters and objects.

Each element of your game is created by filling out a form. In the screenshot below, you can see that I’ve added one room, which I’ve called “Cave”, a direction the player can look, and some rocks as an object.

If I were to continue, I could make the rocks a container, and have the player be able to “open” them (I would describe this as moving them) to reveal a handy-dandy rope in a hidey-hole beneath. I could even include images for each of the things in my text adventure game. Simples.

Because it’s in a browser, there is a tiny wait time between forms. It’s not much at all, but it adds up, and is simply not as responsive and slick as a desktop application.

However, it does mean that anyone can play your game without having to download anything. As an alternative, the system even allows you to export your game as a mobile app, which is a nice touch.

ADRIFT (Windows)

Thanks to Sondar from the comments for pointing out ADRIFT

Adrift is another form-based editor with a few graphical flourishes for ease of use.

Here the object types are arranged in columns that go the width of the screen. Coming straight off of experimenting with Quest this threw me at first (largely due to the technical-looking tree down the left hand side, which I suspect you never have to touch).

A quick glance at the tutorial however and it all fell into place. Actually I prefer this layout, as it’s easier to see everything in your game at a glance.

Objects are added by right-clicking on the appropriate list, and once in the object editor, you can assign various properties, or add related objects.

There is also a map in the top area of the screen. You can even add rooms and connections by clicking on the map, which is a handy shortcut for mapping out your game quickly.

I have had limited time with them, but Adrift certainly seems more thorough than Quest – there seemed more options for your objects and they were immediately intuitive. While I supsect similar things can be achieved with both systems, Quest might require a bit more creativity to bend it to your will.

The downside to Adrift appears to be limited distribution. The editor itself only works on Windows, and whereas the ADRFIT Runner (the program that plays the games) can be installed on any system, it is required to play ADRFIT games. As I understand it, you can’t play them on a variety of already well-established IF players (like Inform or TADs stories), nor can they be played in a browser like Quest games.

In Conclusion

The choice comes down to what you’re comfortable with. If you’re starting out and want a testing bed, I’d suggest Twine. Quest and ADRIFT are also good places for beginners, but be prepared to at least open the manuals for these.

If the depth of interaction in your story outgrows them, take a look at Inform or TADS and go with the one that complements how you picture an IF story.

As an added bonus, here are some more resources for you to take a look at if you want to create a text adventure:

Over to you:
As always, I’d like to hear your thoughts on the systems described above. And if I’ve missed one that you like using, please let me know. The comments section is below.

Since the heady days of the text adventure (the eighties) became but a memory, writing interactive fiction has been almost exclusively a “hobbyist” affair. Authors give away the results of their blood, sweat and tears to the niche (but enthusiastic) community of readers for free. No one had dared take the next, perilous step into full-time IF writing, and many would have said it was impossible – until now!

The man himself

Now he’s decided he wants to make this his full-time job. The trick here is to ask for the money first, before the product is ready. If you have people pledging cash in advance, you can tell whether your venture will be successful or not. So, Andrew set up a project on Kickstarter, in advance of his new piece of interactive fiction, Hadean Lands.

But this has got to be a hard sell, right? Andrew Plotkin may be one of the most famous IF writers in the world, but we’ve been getting this stuff free for ages. Turns out people are pretty generous.

Andrew beat his target by the end of the first day. At the time of writing, 580 people have pledged $26,242, with ten days still to go! Two such pledges are for $1000 apiece, for the opportunity to meet with the man himself.

It really is heartwarming, and a boon for IF authors (and indeed any authors thinking of self-publishing). This can be done, and done extremely successfully.

But let’s take a moment to look at the lessons behind this. This is not the result of one night’s effort – this success represents years and years of work, and the gradual accumulation of superfans. The man himself says (in update #8 of his Kicksarter project):

“And I’ll warn you (again) that it’s not a recipe. There is no recipe; it’s what you’ve done with your life and who you know.”

With that in mind, below is a short, sharp list of what I think needs to be achieved to get similar results. This is the “long-term list”, as I would assume many of the people reading this blog are in a similar position to me, and nowhere near to being able to charge for their work yet. Andrew touches on some of these things, but also talks more specifically about how he ran his Kickstarter campaign in the aforementioned update, so you should also check that out.

1. Be excellent

   Andrew Plotkin writes great IF stories that have won him many awards, great acclaim and raving fans. This does not happen overnight, but is the result of much writing and much practice. Let’s face it, no one’s going to give you any money unless they know you can deliver, so you’d better show that first.

2. Be active in a community

   I’ve mentioned some of his contributions to the IF community above. But it’s about more than putting stuff out there – he does interviews, responds to tweets and comments, and all that good stuff.

3. Be patient

   From that update again, “First, spend fifteen years working hard on projects with no reward but community good-will”. Fifteen years, people! Settle in.

4. Be generous

   There are 16 stories available in the IFDB by Andrew Plotkin. And they are all for free. This allows him to get his work out there easily, and thus to grow a fanbase, but more than that, it generates a tremendous amount of goodwill. People like to see authors working hard on great things, and sharing them, and they will respond.

5. Contribute more than your writing

   And generosity extends beyond the writing as well. He has written interpreters, and the Glulx virtual machine – both long-term commitments. It’s true that he loves this stuff (hence wanting to make it his full-time job), but you can’t argue with the fact that the man has been incredibly generous with his time. He is part of IF history because of it.

For those of us who are in this for the long haul (and you really ought to be) this success story is both a wonderful affirmation and a reminder that there is a long way to go! I encourage all to go and checkout the Kickstarter page and read someonf the updates, especially if you’re an IF fan.

Pledging for the Hadean Lands project ends on December 6th, so if you want to be a part of this, here’s that Kickstarter page again. This is especially true if you want the Mac, Linux or Windows versions of Hadean Lands as they will only be available through the preorder process (once completed the story will be available on iPhone (and maybe other mobile platforms) only).

In other links, Andrew Plotkin’s IF site can be found here, and there is a great interview about this over at rockpapershotgun.com.

This post includes answers from Emily Short, Stephen Granade and Jacqueline A. Lott. Follow the links for their answers to the other interview questions.

More tips for the new IF author

1. How much information do you generally give the reader at the start of the story, and how do you decide how much is appropriate?

   Emily: The introduction needs to be pretty short, because people tend to want to start playing; they don’t want to read pages of text before beginning. So I try to give the most condensed version I can that will tell the player where his character is and what his goal is. In IF, even more than in conventional fiction, you have to communicate the goal immediately, because the player has to have something to work towards. That goal might change over the course of the piece as things happen in the story, but there has to be something clear to start from.

   Then I work a lot of the other background information into the opening scene, so the player will pick up more about his character and setting as he plays.

   Stephen:One of my narrative kinks is having the player start with little information and asking them to piece the story together as it goes. I’ve over-used that trope, in fact, though I can’t say I’ll never use it again.
   Jacqueline: It depends on the experience I want them to have and how long the game will ultimately be. If it’s something short and I need to give the player a bit of background, I’ll do that. But it’s better for the player to experience things as they go, learn as they go, much like we prefer doing in the real world. It’s more natural, and feels more realistic.

2. There are so many items, rooms, and interactions that an author could put in the story and so many descriptions that could go with them. Where do you draw the line?

   Emily: My rule of thumb is: no rooms that don’t have at least two or three interesting things in them; no items that do nothing; no interactions that are irrelevant to gameplay.

   To break that out a little: it’s tempting at first to make a big sprawly map with lots of rooms, but that becomes overwhelming for players. So it’s a good idea to condense the map and combine rooms that might serve related purposes. Get rid of your hallways, staircases, porches, antechambers, vestibules, and so on, unless there’s something actually interesting that’s going to happen there.

   Items are worth implementing if they do something interesting (a key, a letter you can show to another character), if they give important information about the world (a painting of your character’s ancestors), if they set atmosphere (a dying flower in a vase), or if they give the player hints about how to interact (an instruction sheet, say). If the object doesn’t accomplish any of those functions, I tend to leave it out.

   This is an aesthetic choice — some people are much more rigorous about modelling every detail that would be present in real life, down to the towel rods in the bathroom and the handles on the doors. To my mind, those features are distracting to the player, though: he might expect them to do something, and if they don’t, they’re just annoying.

   And “no interactions that are irrelevant to gameplay” means something similar: I don’t implement a detailed weather system or a microwave that you can really cook things in if those don’t matter at all to the story and aren’t part of getting to the ending or solving any puzzles. Otherwise, the player will just wind up tinkering endlessly with something that looks important (why did the author lovingly implement this if it doesn’t matter?).

   So overall, I’d say that I look at this as a process a bit like dressing a set for a play. It’s better to be a little bit impressionistic but provide the player with a few memorable, interesting props that are fun to interact with.

   Stephen: Kurt Vonnegut Jr. famously said that every sentence should do one of two things – reveal character or advance the action. I’m not that extreme, but your items, rooms and interactions should have a definite reason for being there. Don’t feel like you have to implement everything, because you can’t. Instead, implement what matters.
   Jacqueline: Heh. Well, I don’t, which is part of why people both love and hate having me as a tester, and why I don’t have more large-scale works out there (though that will change in the future). My personal belief, which I did fairly well in The Fire Tower, is that you shouldn’t have a noun in a description that doesn’t itself have its own description. This is what garnered me a Xyzzy for Best Setting. Player should be able to explore, and explore freely, and in fact have to work a bit to find something unimplemented. Unimplemented things are jarring, avoid them. Repetitive descriptions for three things in the same room is jarring, avoid doing that. If you don’t want to go to that fine a level, then don’t write yourself nouns you’re not willing to code. Instead of writing, “The leaves of the plant have an intricate system of veins, and there are several small discolorations where insects have had their way,” you should instead write, “The leaves of the plant have been gnawed on by insects.” This latter approach isn’t as pretty, but it also doesn’t force you to then code a description for the “intricate system of veins” or those “small discolorations.”

Broader IF questions

1. What first attracted you to Interactive Fiction?

   Emily: I played Infocom and some Scott Adams games in the 1980s, and enjoyed them hugely. Then I thought they had gone forever, until a friend of mine in college told me about the amateur IF scene.
   Jacqueline: I started on a diet of Choose Your Own Adventure books, and then Zork I, II, and III. It’s how I learned to type, it’s how I learned the word phosphorescent, it’s how I got out into the wilderness when I lived in a city and was too small to venture out alone.

2. Out of your own stories, do you have a favourite, and why (or why not)?

   Emily: Not really. I usually get to a stage of passionately hating whatever I’m working on shortly before I finish it, and then it takes me a little while to forgive it for being such a pain to complete. Likewise, my favorite of the moment is whatever project I’m working on that I’m still feeling enthusiastic about.
   Jacqueline: Well, The Fire Tower is the best of what I’ve publicly written to date, though it’s really showing its age in many respects and responding to your interview has helped me realize that! But I have other favorites that are more personal. I enjoyed the challenge of using only one noun to write Things, or the challenge of having a few objects combine in different ways to represent multiple objects in Within a Wreath of Dewdrops, both of which I wrote with my husband, Sam Kabo Ashwell. I still think The Invisible Argonaut is hilarious, even if you can play it in ten minutes and it’s unwinnable and thus frustrates the hell out of people because they expect there to be something more. I guess we all have our public favorites and our private favorites.

3. What piece of IF have you read that you feel best demonstrates the form’s unique potential (as opposed to traditional fiction)?

   Emily: I couldn’t really point to just one, because the form has potential of quite a few different kinds. There’s a whole chunk of my website about this ( http://emshort.wordpress.com/how-to-play/reading-if/ ).
   Jacqueline: Blue Lacuna, hands down.

Further Reading

Jacqueline A Lott

Jacqueline's The Fire Tower goes to great lengths to provide an award winning sense of place

Jacqueline is an interactive fiction author and prolific tester. Her story The Fire Tower, won the 2004 Xyzzy award for best setting. These days she tests interactive fiction more than she writes, so has a great deal of experience in judging what works and what doesn’t. She has also been running IntroComp since 2003. Her official website is allthingsjacq, on which she has an interactive fiction section.

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

   Jacqueline: Do I have but one linear plot thread in mind? How interesting is the world in which the story is set? How much do I think others would enjoy exploring the issues, experiences, or thoughts of the protagonist? Is this just a story or event that I feel needs to be told, or would it be better explored? I think interactive fiction lends itself, first and foremost, as an excellent venue for world-building and exploration of cause and effect. Personally speaking, there’s also an element of ‘how difficult would this be to code’ or ‘how fun would this be to code’ in there as well, but I’m finding that these days I’m fixing the first of those by collaborating with coders far stronger than myself.

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

   Jacqueline: I use the Inform 7. I first began writing in Inform 6, and was among the private beta group who got to test Inform 7 when it first came out, so I guess I feel a certain affection for the language. I’m also one of those people who’s closer to the writer end of the spectrum than the coder end. Inform 7 is still a coding language, there’s a distinct order to how you can say things, but I do find it easier to grasp mentally because of the natural language aspect of the code. The other day I took a look at something a friend and I started in I6; we’re thinking about resurrecting it, and we both agree that the first necessary thing will be to port it to I7. Reading I6 makes my vision blur a bit these days.

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

   Jacqueline: Laying out the map, and creating locations and their descriptions. I like having a world I can walk around as I lay out parts of the story, and setting the scene is (for me) the easiest and most enjoyable part of the whole affair. I also get a great deal of joy out of research, probably more than is good for me and my actual productivity.

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

   Jacqueline: I think I almost always spend more time writing than planning. That said, one of my current works in progress has been much heavier on planning thus far, but I suspect that eventually the writing will overtake that.

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?

   Jacqueline: Honestly, unless I have a super firm idea of who the player character is, I like letting the player pretend that they’re actually in the game. In The Fire Tower, the player character was modeled after myself, so I took the easy route when I was writing and made the player role play (hopefully they enjoyed pretending to be me!). I’m usually fond of making games more accessible, though, by allowing people to more comfortably fit in the player character’s skin, but that, too, is an easy route. While I haven’t done this myself, I do very much value works which force the player to step outside themselves and experience challenges that they wouldn’t otherwise have to face. That’s part of what makes the experience worthwhile.

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?

   Jacqueline: Well, I do believe in very exhaustive world-crafting, which often means that there are a lot of objects you can explore. Generally, though, if an object is there merely for setting (the thing that I believe IF does better than anything else), then I find some way to reasonably lock that object down. I give the player a plausible reason, not merely a “Sorry, can’t do that” response. Those responses are like a wet towel tossed over the player’s head. No fun.

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

   Jacqueline: Well, you can make things linear, which is fairly boring and frowned on these days. You can make things branch in a somewhat linear way–that is to say, the game itself isn’t linear, but each critical decision puts you on a separate linear path, so what you end up with are a series of individual linear games nested within one larger work. There are ways to make it more complicated, of course. One of the things I’m working on right now allows for lots of exploration and full reign, but each decision you make has a value to it, and the game silently keeps track of your actions, ultimately affecting the outcome; this is accomplished by a value chart that, perhaps unfairly, the player never sees, but the player does know full well whether his/her actions are selfish or not, cruel or not, etc. Whichever route you chose as an author, there’s one common thread for them all: solid testing. You’ll never be able to predict the multitude of ways in which the paths you think you’ve delineated so well will actually cross until you let other human beings navigate those paths for themselves and report back to you about the journeys on which they’ve been.

8. How do you go about testing your work?

   Jacqueline: There’s a lot of self testing before things go out. I’m actually more accomplished in the IF community as a tester than as an author, and that serves me well. Then I open it to a very small group (say, 1-3 people) and work through their suggestions before releasing it to a larger testing pool.

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

   Jacqueline: Releasing something before it was ready. I love IntroComp. I love it so much that I took on the role of running it, which I’ve done now for eight years, and which I hope I’ll do well into the future. But I look back on the first thing I released (as part of the first IntroComp in 2002) and see that it really wasn’t ready, and really wasn’t thought out well enough. When the full version of that game comes out (which it will, eventually) it will be a very different thing indeed, a much better creation, which it never would have been had I not fallen flat way back then and gotten some of my newbie blunders out of the way. Shame it had to be public, but it probably wouldn’t have been as valuable a lesson otherwise.

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

    Jacqueline: Use beta testers extensively, not just any ol’ people you can find, but people who you respect, and listen to them. It’s hard to get past the fascination of playing your first game, seeing it run, thinking to yourself, “I created this world oh my goodness isn’t this amazing,” but you need to get past it. Fascinating as that world you created may be, it’s imperfect. You do it a disservice by not polishing it where other eyes see smears or streaks.

Further Reading

Sarah Morayati

Sarah has written several pieces of IF, including Broken Legs, which came second in the 2009 IF Comp. She also collaborated on Alabaster, which won the awards for best writing, and best individual NPC at the XYZZY Awards the same year. She has also contributed an extension to Inform 7. Her official website can be found here.

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

   Sarah: I use the Windows IDE for Inform 7. It’s really quite simple — I prefer Inform to TADS, and assembling an Inform 6 game is, well, its own thing. I’m sure the technology has advanced since I last used it (well, advanced in a way other than Inform 7), but here’s my old I6 coding process: load up a Notepad file with my source code, open a DOS window, code a bit, switch windows, type in the compiling command, switch windows, fix the inevitable bugs, switch windows, repeat until there are no more bugs, repeat everything else. It’s kind of retro-cool using DOS these days, and it’s undeniably cool to see the file containing your story spring up, but all that coolness wears off fast.

   Besides, the I7 IDE has a lot of excellent features — color-coded source text, quick options to compile, replay and release, a manual built in, lists of verbs, etc. I should also mention the skein — I don’t use it much personally, but a lot of people really love it.

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

   Sarah: Apologies for the wonkery, but I copy-and-paste some code. I’m not being flip. There are a few sentences (again, I’m talking Inform 7) that you’ll want to at least consider at the start, before you forget:

   – “Use no scoring.” IF is trending toward works that don’t keep score. Personally, I don’t have much use for scoring, and I’d venture to say that a lot of people interested in the literary potential of IF don’t have much use for it either. But if you don’t explicitly turn scoring off, readers can still call up their non-score with >FULL or >SCORE. It’s irrelevant, and it will confuse them. Best to leave it out.

   – “Use full-length room descriptions.” This requires some explanation. There are three “story modes” in Inform: verbose, which always prints a full description for every room; brief, which prints a full description the first time and only the room name on subsequent visits; and superbrief, which only prints a full description if you explicitly type >LOOK. I prefer verbose mode. Descriptions help me get my bearings, and more importantly, a well-written description evokes all sorts of moods and images that a room name alone cannot. Room descriptions can also change, producing an effect far more striking if you’re familiar with the original text. This piece of code sets the story mode to verbose by default, and I never leave it out.

   – “Rule for deciding whether all includes scenery: it does not.” and “Rule for deciding whether all includes people: it does not.” This is to make >GET ALL less jarring. Normally, this command will try to take literally everything in the room, including anything you’ve defined as scenery (read: lots of unimportant things), not to mention your NPCs. Some people disable GET ALL entirely, but I don’t think you need to go quite that far. These statements are good enough.

   – “The describe what’s on scenery supporters in room descriptions rule is not listed in any rulebook.” This one can be a lifesaver. If you have a supporter (an object that can hold something, such as a shelf or a chair) described as scenery, the story will write another paragraph to say what’s on that object — a paragraph that’s almost always useless from a writing standpoint. You don’t need it. Even the Inform 7 documentation suggests that you add this code. They know.

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

   Sarah: A couple things, mostly skill. Some things are just difficult to code. Conversations, for instance, or complex simulations (the classic examples are ropes, fire and water.) Many of these, mind you, are highly rewarding once you crack the code, and readers find them very impressive. But some just aren’t worth the effort and are better treated in static fiction. The key question to ask is: does writing this as IF add anything to the story? If not, it doesn’t mean you can’t try it, but it likely means you should find a way to make writing your story as IF worthwhile.

   I’d be remiss, too, not to mention audience. Right now, a work of IF is primarily going to reach a niche audience, likely one with a less traditionally literary background. This is changing, and it’s changing fast, but it’s still true right now. I don’t say this as a warning; it’s just something to keep in mind.

4. 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?

   Sarah: I never much liked “blank canvas” stories. If we assume the PC is a character, would you make any other character a blank slate? Not if you want the reader to care.

   There’s a lot of discussion on this subject, but the stance I take is that IF makes you a tourist in someone else’s mind. Any text you read will be from that character, whether directly or through free indirect discourse. Done right, this can be fantastic — see Stephen Bond’s Rameses, for instance. Second-person is a barrier, yes, but it isn’t insurmountable. It isn’t even insurmountable in static fiction — the canonical example is Bright Lights, Big City by Jay Mcinerney, but there are others. And true, some of these novels and stories and IF works are utter failures. Some aren’t. Yours could be the latter.

   You don’t even have to use second person anyway. It’s a convention, not a rule. There are ways to change tense, and they’re all much easier than slogging through a story written the way you don’t want it.

5. There are so many items, rooms, and interactions that an author could put in the story and so many descriptions that could go with them. Where do you draw the line?

   Sarah: In general, over-implementation — what some call making stories “juicy,” is better than under-implementation. The surest sign of an amateur isn’t too much writing, it’s too little — important scenery objects going unimplemented, or items getting one lousy sentence of non-description. Don’t despair, though — this usually doesn’t happen when the author’s trying. It happens when the author isn’t.

   There is a line, though, and it’s sometimes hard to spot at first. A piece of advice floating around from Adam Cadre that should help shed some light on this: any text your story displays is essentially a reward for the player typing in a command, so every piece of text has to be worth reading. Your responses can be funny, they could give clues, they could further characterization. What they cannot do is be cursory. When you get to the point, then, where you’re just writing stuff down because you have to, rewrite or rethink. If you’re bored by your writing, everyone else will be bored too.

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

   Sarah: This is what people call the ““combinatorial explosion” problem: the more things you’ve got bouncing around at once, the more likely it is that they’ll crash into each other and explode. So corral them if you can. For Broken Legs, I cheated a bit. (Mild spoilers ahead, but nothing catastrophic.) Every turning-point in the story is binary. Alexandra either fails or passes her audition, so at each juncture, there are only two possibilities. Well, OK, that’s not entirely true — at a certain point in the late game, there are about three — but two and three are still very different numbers than 20 and 30. Perhaps real auditions are more nuanced and actually do require 20 to 30 factors, but I wasn’t about to simulate all of that in a year. I cheated in other ways: the puzzles are sequential, so you shouldn’t run into a situation where Alexandra passed but Rosanna failed, and more importantly, I wouldn’t need to write and code that scenario.

   I’ve called this cheating, but I’d like to call it strategy too. Simpler is usually better. In general, simplify as much as you can while still achieving the effect you want. As long as there’s a plausible story-related reason for your simplification — characterization, perhaps, or plot — and you’re not just chopping off paths arbitrarily, you’ll be fine. After all, you don’t have to release your source code, and even if you do, vanishingly few people — few readers, at least, will judge you on it. What readers judge you on is the story you write. Simplicity is still impressive.

7. How do you go about testing your work?

   Sarah: Thankfully, there are no shortage of testers in the IF community. As you write and test more stories, you’ll build up a group of testers you can trust. Before that, though, you can get started by posting on intfiction.org or gametesting.org. If that doesn’t give you enough responses, you can try asking (politely!) people you know in the community. The more testers, the better; you’ll find that some people agree to test your story but quickly vanish from the face of the earth.

   Don’t think, either, that one round of testing is enough. For Broken Legs, I did about four, and other stories have had even more. Even the best testers won’t catch everything the first time around, and more pertinently, sometimes what you thought fixed things in fact completely broke them. One of my intermediate releases was unwinnable (that is, literally unwinnable, not “this is too hard” unwinnable) because of something I changed. Again, keep deadlines in mind, but the more the better.

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

   Sarah: Writing a horrible first story. There’s no better way to learn a language, whether it’s Inform, TADS or anything else, than by diving in, but you’re going to end up wasting a few weeks or months on something terrible and unreleasable. Mine was a museum crawl that turned into a cave crawl and then back into a museum crawl somehow, with a bloodless conspiracy backstory thrown in because I thought it would add depth. It never saw the light of day. But that’s all right. The effort I poured into learning the code is effort I could then put toward crafting a better story. As cliched as it sounds, it was a learning experience.

   Now that I’ve said all that, forget it all. Delve into code the first time thinking you’re going to turn out something great. You won’t learn if you don’t think, at least at first, that your concept is the greatest story ever. And who knows? Maybe it will be.

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

   Sarah: Read. Read everything. This goes for interactive fiction as well as traditional fiction, nonfiction, etc. And don’t just stop at reading. Watch good movies, listen to good music, fill your brain with ideas and let them bounce and clatter against each other. You’ll be a better writer for it, not to mention a better person.

Further Reading

Aaron Reed

Aaron Reed is the author of Whom the Telling Changed, and Blue Lacuna, a full length Interactive Fiction novel. His work has won him Spring Thing awards, and numerous XYZZY Awards. Back in 2006, he was interviewed for the documentary Get Lamp, which was recently released. His book Creating Interactive Fiction With Inform 7 has just been published. In it he guides the reader, chapter by chapter, through the making of the example work Sand Dancer.

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

   Aaron: This is definitely an important question to be asked, although finding the correct answer is trickier. One thematic element which works well in an interactive story is moments of revelation– where a character realizes something profound about herself, her world, or the people around her. In IF you can make this character the player, and let them come to that realization on their own, which has the potential to be more moving and memorable than a static character coming to that moment before or after the reader does.

   IF is also at its best with stories about exploration and investigation, with settings that curious interactors can delve into as deeply as they like (and the author was prepared for). Emily Short’s Floatpoint is a great example of cultural sci-fi where you can learn the ways of a strange people by actually walking around their city and watching their interactions, rather than having to get this information in a block of exposition– it makes you feel more like an anthropologist than a historian, which is kind of wonderful.

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

   Aaron: I use Inform 7, because I believe it’s the most expressive language for creating interactive stories around these days. I7 was created specifically for writers, not programmers, and while this rubs a lot of programmers the wrong way, I find that its idiosyncrasies mesh well with my own. (Full disclosure: I just published a book called Creating Interactive Fiction with Inform 7, so my opinion may be just a little biased.)

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

   Aaron: With both interactive and non-interactive stories, my writing process tends to be very similar: nearly all writing, very little planning. I am definitely not one of those people who plans a whole story out and then simply fills in the words: I seem to have to write iteratively, going through multiple drafts that don’t work at all, conceptually or otherwise, before finally honing in on the final product. This is, unfortunately, a rather time-consuming way of going about things, but it seems to be the only one I can deal with.

4. 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?

   Aaron: I think it’s nearly impossible not to roleplay while directing the actions of a fictional being in minute detail. If that fictional being is very generic and easy to slip into, on the one hand, you’re essentially playing yourself, or a version of yourself who happens to be in an extraordinary situation. Some IF paints the player-character much more specifically (Stephen Bond’s Rameses is a classic example) and creates characterization out of the tension between what you yourself would do in a situation versus what the character is willing to do. Sometimes, this can be a lot like playing a role in a stage play: the joy comes from performing your character like a virtuoso. My stories have experimented with both ends of this spectrum, but I think leaving the player-character at least somewhat nebulous makes it easier for readers to slip into and have fun with.

5. There are so many items, rooms, and interactions that an author could put in the story and so many descriptions that could go with them. Where do you draw the line?

   Aaron: This makes me think of the difference between a great film director and an only so-so one. The Kubricks and Hitchcocks of cinema stand above their imitators because of their meticulous attention to detail in setting up their scenes. Every shot in their films is crafted to help tell the story: in its composition, in the elements carefully selected to be in frame, in the details on the soundtrack and in the actors’ blocking. Everything is there for a reason.

   Likewise, in a good IF every object and room should be there for a reason. You should never make a new item in your story without a clear sense of what purpose it serves in advancing your narrative or further immersing the reader in your story world. Likewise, possible actions should be carefully curated from the vast possibility space of all the things a character might conceivably do, selecting instead only the most dramatically interesting or character building possibilities. Andrew Plotkin’s Hoist Sail for the Heliopause and Home is a recent IF story that does a superb job at building an epic story using a very restrained and carefully selected set of actions, items, and locations: nothing is there that isn’t relevant.

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

   Aaron: Read IF. As with every medium maturing out of infancy, the field is awash with hundreds of experiments, failures, and moments of genius. Getting familiar with the best of what’s come before will not only prevent you remaking a lot of the same mistakes, but will also put you at the forefront of the conversation, where you’re best able to contribute novel ideas. One of the magical things about the IF movement is that it’s an art form still very much in flux and amidst the process of being defined, and it’s exciting to be a part of that process.

   Okay, two tips: use extensions. There are a slew of user-written extensions to Inform 7 and other major IF languages that can save you a lot of time, and give your stories much slicker presentation, functionality, and accessibility. Stand on the shoulders of those who’ve done the grunt work!

Further Reading

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

Galatea, one of Emily's more well-known stories

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, as he appeared in the documentary, GET LAMP

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

Welcome to part three of my interactive fiction series. So far, we’ve described interactive fiction and it’s history; looked at how you can get into reading it, and how you can get into writing it. There may be some of you still wondering what the big deal is, and that’s fine. You don’t have to like it. But I’d like to have one last go at persuading you. To that end, here are four reasons to try your hand at writing IF.

1. Interaction

Clue’s in the title, folks. This aspect might appeal to you as a reader, and so, why wouldn’t you want to emulate it.

But above and beyond that, it requires a different way of thinking about a story, and a different way of writing. The sheer experience of creating something so different might get you interested; you may carry something back from this experience into your other writing; or you might just consider it another string to your bow.

Certainly, anyone considering writing for video games would do well to have interactive fiction on their cv. It will demonstrate that you understand some of the demands that non-linear, interactive writing has.

2. A unique perspective

Image courtesy of Dar Sevier on Flickr

So what, you might think. Well, I’m not an experienced IF writer, but there are some obvious advantages to this perspective.

The one that is perhaps most obvious is humour. Anyone who has played a text adventure will be familiar with the snarky comments you get back when you do something stupid. As an author of IF you get to make lighthearted fun of the reader (if they try to take a tree, for example).

You can also put your reader completely in the dark. This is not a bad technique for story telling anyway, but here it really comes into its own, as the reader fumbles around, trying to figure out the situation.

Take Emily Short’s Glass for example. When the story starts, you have no idea what your role in the narrative is or what you are capable of. As you try different things it appears that you’re not capable of much at all, and the conversation you’re witnessing seems to carry on without you anyway. Persevere though, and your function becomes clear, and then you can really start experimenting. It’s very satisfying.

One other opportunity, that is perhaps the most difficult to pull off, is to say something about the reader themselves. By giving the reader choices, and using the second person to point the finger, there is potential to hold up something of an interactive mirror to the reader.

3. A unique challenge

We know writing is difficult, but we do it anyway. Maybe we’re masochists, maybe we just relish a challenge. So picture a story with multiple paths through it, maybe multiple endings; conversations that could cover many topics; items that could be put to any use; rooms where everything should be described in detail. These are all very real possibilities in IF, and if you’re chomping at the bit to get writing at the thought of it, maybe you do like a challenge! Just remember, you have been warned!

4. Tiny, bite-sized chunks

Having said that, in some ways IF is suited to those who don’t have a lot of time to squeeze some writing in. Beyond the copious planning and some complicated logic (if required), interactive fiction is made up of tiny little bits. If you’re pressed for time, you can write a couple of item or room descriptions in ten minutes, and still feel like you’ve made some progress.

And there you have it. As always with these lists, there are bound to be more reasons, so hit the comments! I’d be especially interested to hear from experienced IF authors on why they enjoy writing interactive fiction.

Further Reading

This blog post also coincides, kinda sorta, with the release of GET LAMP, a brand new documentary about text adventures. The release date was 2nd August. You can order GET LAMP here.

What’s this interactive fiction lark anyway?

Direction in IF is often referenced with compass points. Image courtesy of ocean.flynn

Interactive Fiction is played on a computer. Instead of simply reading the text, “players” are given brief descriptions of their surroundings and what items are available to them. They then control the action by deciding where to go, what to look at, what to pick up, and what to do with those items. This is done by typing in commands, such as “examine door”, “move rug”, “get lamp”. There is normally some puzzle solving involved, and IF has gained something of a reputation for being difficult (although, I should stress that given the variety of games/stories now available, this needn’t be the case at all – there are plenty of stories that don’t require puzzle solving at all if you want them).

The result is a form that will suck you right in one minute, and chuck you right back out again the next. The immersion comes from the written word. By utilising the reader’s imagination in the same way that a regular piece of fiction would, it is very easy for a player to become involved. Because of its roots as a gaming form, much comparison is made between the blockbuster gaming titles of today and interactive fiction. Today though, the difference between the forms is so great that there is little to be gained from such comparisons. Try comparing darts with football for similar results.

The other side of this coin is that IF will frequently shatter your suspension of disbelief at a few key strokes. Although the blinking cursor gives you the impression that you can type anything, the reality is that these games can only take a limited number of commands. Type anything else and you’ll be presented with, “I don’t understand that” or similar. Jarring. This false promise is something IF has not yet been able to solve, but it’s not a huge problem. Think of it as the price to entry. Besides, typing something obscure can occasionally surprise you with an amusing line or a useful piece of interaction.

A bit of history

A screen grab of Zork I running on Zoom

Interactive fiction started out in the gaming arena. The first “text adventure game” was Colossal Cave Adventure, or simply Adventure in 1976. It’s a simple treasure hunt in a network of caves, and formed the basis from which others would create their text adventures. Infocom are the company most well known for producing these games, most famous among them being the Zork trilogy. Other notable examples include Hitchhiker’s Guide to the Galaxy and The Hobbit, both based on novels, of course.

Sadly, as graphical technology began producing more whizz-bang results, the popularity of the form waned and soon became unviable for business. After all, it’s far easier to sell the latest graphics on your television ad or the back of the box than it is to sell text. That hasn’t stopped people producing their own interactive fiction for free though, and there is now an ever-increasing number of IF authors and readers finding a home on the internet. The Interactive Fiction Database has over 3600 games available to download, including all the classics mentioned above.

With such a community, it is not surprising that the variety of the work has also increased. it’s not just about hunting in caves for treasure any more. Take a look at the short list of stories below for a clue as to what’s out there. Many of these stories are prize winners. In the interests of full disclosure, many of them are mentioned in this excellent video introduction to interactive fiction, which I suggest you check out (only ten minutes of your time).

• Bad Machine. You are a robot. You are broken.
• Glass. By Emily Short (a great contributor to IF). Takes place around a single, and familiar conversation, from a unique perspective.
• Lost Pig. You are an ork, chasing a pig on your farm. Hilarity ensues!
• Violet. You’re tasked with avoiding distraction and doing your dissertation.

So, how can I play these games?

I’m glad you asked! Games can either be played on applications that you download and install on your computer, or they can be played in a web browser. Look for the “play online” button on game pages at the IFDB.
As far as applications go, try the following:

• Zoom, for Macs
• Gargoyle, or Frotz for Windows computers
• Zoom is also available for Linux
• Frotz for iPhone! Also available on the app store for free.

And as a special treat for Linux and Mac users, did you know that you might have a text adventure on your computer already? Open the command prompt (Terminal program on Macs) and type the following:

emacs -batch -l dunnet

This gives you a text adventure game called dunnet, written in Emacs. Cool, huh?

So that should be enough for you to get going if you’ve not come across the modern IF scene before. I know that there is quite a hardcore following out there, so if there is anything I should have included, or any false information, please let me know in the comments or on Twitter.

Next week, I’ll be showing you tools you can use to write your own interactive fiction (this is a writing site after all)!

Update

I have just finished playing Lost Pig on my iPod Touch. It’s a great story and kept me thoroughly entertained (although I missed out on one lousy point! Grr!) But the point is that I played it using Frotz for iphone (mentioned above). It’s true that paying IF on your iPhone or iPod Touch is a little fiddly. I often typed things wrongly. But there are features that mitigate this problem somewhat – you can double tap on a word in the text to put it on the command line, and you can double tap on the command line to bring up your command history. There is also autocomplete on commands, though not on object names (presumably because it could unintentionally provide clues).

Overall, a great app that I heartily recommend!

Further Reading