IF Design: In Theory

Author's note: This is an updated version of a chapter from the TADS 2 Author's Manual. The updates reflect changes in my own thinking about some of these matters, as well as changes in fashion and audience expectations over the years. When I wrote the original chapter, IF was very much defined by the Infocom games; the format has changed somewhat in the intervening years, so I've tried to reflect some of those changes in this advice.

This chapter is about the creative side of writing IF, about what qualities define a good piece of IF. As with any writing, technical polish is important, but it's not enough by itself to make a work succeed. This section explores the fiction part of Interactive Fiction, and tries to offer advice about how to create a work of IF that succeeds as both a piece of software and a work of fiction.

Technical polish counts

Much of the advice in this article might seem squishy and subjective, but we can at least start out with something fairly sharp-edged.

I just finished saying that technical polish isn't the whole story, but don't take that as a license to ignore it: technical polish is a basic requirement. If you don't get the technical parts right, your audience is likely to dismiss your work as amateurish so quickly that they might not even notice any of your work's other qualities.

In static fiction, the "technical" aspects are spelling, punctuation, grammar, basic stylistic elements like parallel structure and avoiding word repetition, and correct usage of devices like metaphor and simile.

In IF, you have to get right all of those basics from static fiction, plus you have to write a working computer program. You have to make sure your program doesn't crash, burn, or otherwise malfunction. The program has to produce a sensible reply to each command the user enters. The game has to keep its world model in a consistent state throughout play, with no objects mysteriously vanishing, reappearing, moving, or otherwise defying the laws of physics that you define within your game world.

If you don't consider yourself skilled at the technical aspects of regular English writing, there are lots of tools that can help. Keep a dictionary handy if you're not a strong speller, or run your game through a spell-checker frequently. If grammar's your weak point, find a self-help grammar book for writers. There's a huge selection of books available designed specifically to help aspiring writers improve their technical skills.

Aside from working on your personal skill-set, the best way to improve your game's writing is by having someone proofread it for you. Find a friend or two who are good spellers and grammarians, and enlist them to play through your game and point out the writing errors they catch.

Testing is doubly important because it's virtually the only way to catch programming errors. You should spend as much time as you can doing your own testing - playing through the game, trying as many combinations of things as you can think of. Try to think like a player, as though you don't know the winning solution already - try the things a player would think to do, not only the things you know are correct. But you'll never think of everything a player will - in fact, no one player will think of everything another player will. So after you've fixed all the problems you can find, ask a couple of friends to test it.

Testing is inevitably a humbling experience. No one enjoys having their mistakes pointed out. It's extremely important, for your own sanity and for the health of your friendships with your testers, that you understand this going in. You have to accept that your testers are going to find errors - lots of errors, egregious, stupid errors that make you look like a complete moron. It's easy to become a little resentful, even outright angry, when a tester points out yet another stupid error. You have to force yourself to remember that the tester is just the messenger - you were the one who made the error, not the tester, and the tester is just doing you a favor by pointing it out. A favor? you ask with a bitter laugh. A favor?! Yes, a favor: the tester is saving you the embarrassment of letting the whole world see the error. Thanks to them, you're going to get to fix the error before anyone else sees your game.

So be grateful to your testers. If you should feel that twinge of annoyance or resentment or anger at a bug report, overcome it with your deeper understanding that the bug report is a good thing, that it's going to make you look better in the long run. When you get a bug report, thank the tester for it.

One more thing about testing: keep in mind that you don't have accept every bit of advice a tester gives you. Sometimes testers make mistakes, too, and sometimes they just have different opinions from yours. Sometimes a tester will report a bug that isn't really a bug, because they misunderstood something; sometimes they'll report a typo that you put in intentionally for one reason or another. When you get this kind of report, whatever you do, don't complain to the tester about it or accuse them or giving you bad bug reports - they gave you the report in good faith, and the last thing you want to do is discourage them from being frank with you as they continue testing. They told it like they saw it, and you want them to continue doing just that. Thank them for the bug report as always, and if you're sure it's really not a problem, just consider the case closed.

When you do get a faulty bug report that's due to a tester's misunderstanding, you really should give it a little thought before you dismiss it. You should at least try to figure out why the tester misunderstood the situation, because it might reveal a larger problem that you need to address. If the tester didn't understand that a "typo" was actually a phonetic rendering of a character's Texas drawl, for example, you might have failed to properly introduce the character or to establish the stylized spelling. If the tester reports a bug that a door apparently closed by itself, but you know that the door is supposed to close by itself because it's spring-loaded, maybe you need to make this clearer in the description, or point out the resistance when the door is opened. If you outright don't understand why the player thought something was a bug, feel free to ask them to explain - you shouldn't argue with them about whether something is a bug or not, but you definitely should ask for more information when you don't understand exactly what they reported or why.

IF's inherent weaknesses

IF has some inherent weaknesses. If you're writing IF, it's useful to understand these weaknesses, because then you can at least work to minimize their negative effects on your work.

Ask IF enthusiasts what they like about IF, what differentiates it from other types of computer gaming, and you'll get a couple of types of replies.

Type 1 is the "homebrew" factor: IF is a medium in which an amateur working alone in her spare time can actually hope to create a complete, original work. This is practically unique among modern computer games; a commercial game today is, with rare exceptions, the product of a cast of hundreds and a budget of millions. What's more, the lack of any commercial interest in IF ensures that people who work in the medium do so for their own reasons. The rest of the gaming industry is subject to the same economic forces that drive blandness, repetition, and imitation in the television and movie industries, but IF is immune to all that.

The Type 1 replies are entirely valid, but they're primarily reasons that people like to write IF. They're not so much reasons people play IF.

The Type 2 answers are the reasons to play, and they largely boil down to this: IF has an "unlimited" feeling that no other type of computer game can approach. In IF, you can type any command that you can think of; in other games, you're limited to a menu, or a joystick, or some other enumerated set of potential inputs.

That "unlimited" feel of IF is at once its greatest strength and its greatest weakness.

The strengths of the "unlimited" feel are clear enough. A command line gives players the freedom to try anything. It gives authors an obvious tool for creating inductive-reasoning puzzles, puzzles with "lateral thinking," where the solution requires analyzing a situation and realizing something that's implied but never stated. The player's very ability to try anything makes it possible to create puzzles where trying just the right something is rewarded.

The weakness of the "unlimited" command line is that it's only quote unlimited unquote. Yes, the player can type anything. But if they don't type the right thing, all they get is an error message. If you've ever watched a novice player grappling with the "unlimited" command line and its promise that you can type "whatever you want" in "ordinary English," you know that the actual odds of a novice player typing a valid command are distressingly low - low enough to send most newcomers fleeing.

The point is that the command line isn't unlimited. It only gives the illusion of being unlimited. In fact, it has limits just as real and just as unbending as the UI limits of a game with a joystick. The difference is that the joystick game's UI boundaries are plainly visible, while the command-line hides its limits. The limits are there, but they're a big secret. The only way to find out if a command works is to try it. Does this work? No? How about this? No?

Strategies to mitigate the "unlimited" problems

The problems with the "unlimited" command line come in three main varieties.

The first variety is at the "syntax" level. Specifically, the parser's ability to recognize words and phrases. This problem is on the surface straightforward enough to fix - you just add more words and phrases until the game understands everything! Sadly, that's harder than it seems - a lot harder; the problem of understanding natural language input has stymied the best efforts of the best computer scientists for fifty years at least.

The second variety is at the "simulation" level. This problem occurs when the player enters a command that would work in a real-world version situation that the game claims to describe, but nonetheless doesn't work in the game. We're not talking about parser failures here - we're talking about commands that the parser recognizes, but which aren't handled in the simulation:

You are carrying a book.

>tear page out of book
You can't tear the book.

The third variety is the "detail level" problem. Players sometimes misconstrue the nature of the command-line interface, thinking it's meant to be an actual human conversation. This is especially true of novice players, especially if you've fed them all the marketing misinformation about how they can talk to the game in ordinary English. Players who make this mistake will formulate their commands in goal-oriented terms: REPAIR THE NUCLEAR REACTOR or INTERVIEW THE SUSPECT. If the player doesn't understand the conventions of the IF world model, they won't realize that their inputs are really confined to a very narrow level of detail in manipulating the game's objects.

Now let's look at some strategies for reducing these problems, or at least reducing your audience's awareness of these problems.

Know your audience

Most people writing IF today write for the established IF community, whose center of gravity is the rec.arts.int-fiction newsgroup.

If you're writing for the IF community, you can count on your audience having a degree of familiarity with the basic rules of IF. They understand the core world model - the map consists of a graph of locations, geometry is modeled by hierarchical containment, and so on. They understand that proximity is not modeled, and that locations are not generally connected except for travel. They understand that certain verbs are implemented in general (LOOK, EXAMINE, INVENTORY, TAKE, DROP, OPEN, CLOSE, PUSH, PULL, NORTH, STAND, SIT, LIE) and that most others are only usable in "unique" situations as puzzle solutions. They understand certain replies to be guidance away from boundaries: "That's not important" and "You don't need to do that" and so on. They understand that if a part of something has the same EXAMINE description as the thing it's a part of, it's not modeled separately from the main thing.

This audience pre-education is a big benefit, but it comes with the burden of high expectations.

First, they'll expect that your parser will recognize most or all nouns (and associated adjectives) that you use in your descriptive text. It is acceptable for all of the vocabulary for a thing and its parts to "point to" the thing itself, rather than implementing all the parts as separate object:

You are carrying a jewel-encrusted egg.

>examine egg
The egg is made of a thin, glassy shell, and is exquisitely
decorated with diamonds, emeralds, and rubies.

>x diamonds
The egg is made of a thin, glassy shell, and is exquisitely
decorated with diamonds, emeralds, and rubies.

>x emeralds
The egg is made of a thin, glassy shell, and is exquisitely
decorated with diamonds, emeralds, and rubies.

Second, they'll expect that you'll provide non-default descriptions of all objects. No object should "look like an ordinary" thing.

Third, they'll expect meaningful, non-default responses for verbs that naturally apply to an object. They will expect that a button can be pushed, a lever pulled, a dial turned, a box opened and closed, a table lamp turned on and off. It's acceptable for these commands to have no real effect, but you must at least reply with a good reason why not, within the context of the game world.

Fourth, they'll expect all reasonable phrasings of an important command to work. An important command is one that's necessary to solve a puzzle or otherwise advance the story. These commands must accept any common way of saying the same thing. You can't make a puzzle solvable with TWIST KNOB but fail to accept TURN KNOB and ROTATE KNOB.

If you're writing for a different audience - outside of the established IF community - you'll naturally face different player expectations.

Educate your audience

Writing for novice users might seem easier than living up to the expectations of the experienced IFer. But I think it's actually more difficult. The novice player's expectations are in fact far more rigorous: the novice will expect your game to behave like reality. Not only that, but the novice player won't come pre-loaded with an understanding of IF's somewhat stylized world-model conventions.

Novice players are likely to project a "real world" interpretation on what they read, and to try things that would make sense in reality in the situation described. They'll infer the presence of objects you never mentioned just because such objects would often be around in similar real-world situations; they'll assume that proximity matters, that it constrains their actions and can be exploited in their solutions; they'll assume that all of the real-world physical properties associated with a typical instance of a described object - size, shape, mass, temperature, material, flexibility, hardness, sharpness, chemistry, friction - can be exploited; they'll swing wildly between levels of detail, attempting on one turn to HOLD BOTTLE OVER GLASS in preparation for pouring themselves some whiskey, and on the next turn to REPAIR THE NUCLEAR REACTOR. They won't know the "usual" set of verbs, so they'll try all sorts of weird words you never expected, and they'll spend hours running around in circles trying every possible manipulation of the doorknob, the hinges, the keyhole, the doorframe, and the wall because they never thought to just OPEN THE DOOR.

If you're writing for novices, my first suggestion is to spend a lot of time testing - using novices as playtesters. This will at least help you recognize some of the misconceptions that novice users will bring to the game. This effort can only go so far, though, because the big challenge isn't that novices will misapprehend the world model, but rather that they'll all misapprehend the model in different ways.

The other thing you can do is to educate your audience as much as possible. An instruction manual will help some people, but experience shows that most people refuse to read the manuals for their "work" software, like spreadsheets and word processors; it seems preposterous to expect them to study a manual before playing a game.

A better bet is a sample transcript, showing a walkthrough of a short game that's similar to your own - not a real game, just something you make up as an example. Show the sorts of commands they'll need to use, and show the solutions to a couple of puzzles in the imaginary game.

Alternatively, and perhaps better, you could provide a partial walkthrough for your own game. This works with most players' natural inclination to play first, ask questions later. As we said, few people will study a manual; most people will dive in, play for a while, get horribly stuck and frustrated, and only then start thinking about looking for instructions. This is where the walkthrough comes in. It will show the player exactly how to solve the first few puzzles. Since the player has just spent a frustrating hour or so grappling with those very puzzles, she'll be all primed to receive information specifically about them - there will be numerous moments of recognition, of "ah, so that's what you do with that." With luck, the player will directly connect the way she was thinking with the way she should be thinking, and will then have a good mental model to apply to the rest of the game.

You want the player to discover this starting walkthrough after playing for a little while. A simple way to do this is to offer it as part of a HELP command. Players will often try to make do for a while on their own, and type HELP only after they feel they've gotten stuck. If you offer the walkthrough as part of an external README file or the like, players might just use it from the start, so they wouldn't have the benefit of having at least tried to think about the early puzzles on their own first.

You might be reluctant to write a spoilery walkthrough for your game's opening. If you plan for it from the start, though, you could insert a few throw-away puzzles specifically for the sake of giving them away. Since these are throw-aways, you can even feel free to use hackneyed puzzles here - experienced players will zip right past them, and you won't mind giving away the answers for the sake of helping novices get started.

Another form of eduction is "pro-active" hinting in the game. I'm not talking about a hint system that tries to tell if the player is stuck and starts offering hints, although that can be a good idea, too. Here, I'm talking about something simpler. During testing, you'll probably find users attempting high-level "goal" commands, like REPAIR NUCLEAR REACTOR. When you find these, add handlers for them that let the player know they're on the right track but need to think in terms of the details:

>repair nuclear reactor
You think back to your class in nuclear reactor maintenance,
trying to remember the steps.  Maybe if you could find the
operator's manual, it would refresh your memory.  It ought
to be around here somewhere.

Full disclosure

Earlier, we explained how the big problem with the command line is that it only pretends to let you type anything, but in fact has hidden limits that you can only probe by trial and error.

One way around this is to simply not hide the limits. There is, after all, nothing that actually prevents you from giving players a full list of verbs that the game accepts. Now, a modern IF game accepts so many verbs that a complete list would be a bit overwhelming, so in practice you wouldn't usually provide a list of all accepted verbs. Instead, you'd provide a list of necessary verbs - in other words, you'd omit verbs that are simple synonyms of others on the list, and you'd omit verbs that are accepted but which never do anything meaningful in the game. You might or might not include verbs that are meaningful but not necessary - that is, verbs that effect some kind of change in the game, but which aren't needed to solve all the puzzles or complete the story.

In some kinds of games, this approach won't work. If you have a puzzle that depends on the player having a flash of insight that leads to a particular action that isn't directly suggested anywhere, you'd obviously want to keep that verb a secret, since revealing it in a list might well ruin the puzzle. If you do have such a puzzle, I'd recommend thinking carefully about whether it's actually a good puzzle; many puzzles that involve non-obvious actions or verbs are poor puzzles because they rely on the player simply having to read your mind. There's a sub-type of "guess the action" puzzles that's particularly enticing to authors, and particularly difficult for authors to recognize as flawed: this is the type where the solution makes perfect sense, but only in retrospect. That is, once you know the solution, it makes perfect sense, but there's nothing in the game to suggest the solution before you know it. This type of puzzle is particularly hard for authors to recognize because the author necessarily knows the solution from the start. So think about it: if you've created a puzzle where the player has to read the author's mind, or where the solution only makes sense once you know it, you probably have a bad puzzle on your hands rather than a valid justification for keeping a verb secret. On the other hand, if you've designed a puzzle that a player can solve with a flash of insight based on synthesizing information available before they've solved the puzzle, you might have a valid reason to keep a verb secret.

If you do decide on full disclosure, here's my recommendation for how to go about it. First, add a section to your HELP information (or your INSTRUCTIONS information, if you include a set of "beginner" instructions) that lists all of the important verbs. Just before the list, tell the player that the list contains every verb they'll need to complete the game. Second, add a very brief note, either in the introductory text or in your ABOUT information, that mentions that the full verb list is available, and where to find it.

Implied disclosure: prompting

If you don't want to provide a full list of verbs for the player, you can still give the player subtle guidance about unusual verbs as the need arises. The way to do this is fairly straightforward: you use the exact verb phrasing that's accepted in player input when describing the object to which the special verb applies.

>examine spigot
The spigot has a tapered, slightly barbed end, designed
so that you can attach a rubber tube to it.

Here, we've prompted the player that the command for connecting a tube to the spigot is ATTACH TUBE TO SPIGOT. Without this prompting, it might have taken the player a little while to guess at the right syntax.

This sort of verb prompting will be instantly recognized by experience players, because it's become a standard technique. However, novice players might not be as quick to pick up on the idea, so keep in mind that this technique will be of most value when you're writing for the established IF community. If you're writing for novice players, you might want to actually present the advice as advice, rather than as part of the narrative:

>examine spigot
The spigot has a tapered, slightly barbed end.

[To attach something to it, type ATTACH (Thing) TO SPIGOT.]

Limit your verbs

One way to avoid the problems of how and whether to disclose verbs is to use fewer of them in the first place. There's a core base set that you'll virtually always have: LOOK, EXAMINE, TAKE, DROP, PUT IN, OPEN, CLOSE, NORTH, SIT, STAND, and a few others. These verbs are the ones that relate to what's truly modeled in the standard IF world model: description, travel, and containment. Beyond this set, you get into the "special-case" verbs that are handled by exceptions to the basic model - verbs that activate custom code that applies uniquely to a particular object or group of objects.

Some special-case verbs are the natural verbs to use with particular objects: LIGHT MATCH, TURN ON FLASHLIGHT, EAT APPLE, READ BOOK, DIG IN (something) WITH SHOVEL, CUT (something) WITH KNIFE, HIT (something) WITH HAMMER. These are "natural" verbs because they're practically implicit in the object. I sometimes call them the "USE" verbs, because they're the verbs that you'd assume if someone substituted USE: USE MATCH, USE FLASHLIGHT, USE APPLE, USE BOOK, USE SHOVEL ON (something), USE KNIFE ON (something), USE HAMMER ON (something). That's the test - if you can ask several people what USE means with a particular object, and they all give the same reply, you have a USE verb; otherwise, you don't.

It's when you go beyond the core verbs and the USE verbs that you're likely to run into problems. You can reasonably expect any player to know the core verbs, either because they know them from other games or because they've read your instructions. (Whatever your feelings on verb disclosure, you can at least tell people about the core verbs, since knowing them couldn't possibly spoil a puzzle. If it did, the puzzle would be pre-spoiled for anyone who'd ever played an adventure game before.) You can also reasonably expect people to figure out every USE verb - that expectation is what makes them USE verbs, after all. But beyond these, it's not reasonable to expect people to think of things to try.

For instance, if you have a piece of paper in your game, you can't reasonably expect people to figure out on their own that they should FOLD it. Yes, folding is one thing you can do with paper, but it's only one of many equally likely things: you could write on it, tear it, cut it, shred it, burn it, crumple it, twist it, roll it, poke a hole in it, rub it, scratch it, and on and on. This is why it's not reasonable to expect a player to come up with FOLD PAPER out of the blue.

So, the design discipline we're suggesting here is to use only the core set and bona fide USE verbs as the "required" set of verbs. This doesn't mean that you shouldn't accept any other verbs; it just means that the player should be able to solve all puzzles and/or complete the story entirely with the core and USE verbs.

This design rule isn't suitable for every game, so we're not saying that your game will be a failure if you don't use it. But if you do take this approach, you might find that it has some beneficial side effects. In particular, it tends to improve puzzle logic by preventing you from relying on obscure properties of objects or obscure relationships among objects; it encourages you to work harder to "hide in plain sight," which is a big part of creating that satisfying feeling for players of having things click into focus when they get the trick.

Implement what's important, gloss over what's not

Players spend their time on things that give them feedback. This is particularly true of experienced players, who have learned to recognize the conventional cues that something is just for decoration, but even novice players will latch onto feedback when they get it.

You can use this aspect of player psychology to help guide the player to the things you want them to spend their time on. If you want the player to focus on something, implement it thoroughly: give it unique responses to many verbs, and give it meaningful responses - results that actually change something in the game setting - to as many verbs as possible. In contrast, if you want the player to ignore something, make its responses uninteresting and unvaried.

Be consistent

The basic problems with the hidden limits of the command-line format are horribly compounded by the key feature that differentiates adventure games from other kinds of games: adventure games are characterized by unique, scripted responses to particular actions.

An IF game is based on a simulation model, but that model is an inch deep - X is in Y, Y is a container, Y is open, Room 1 is north of Room 2, etc. The model is too simple to be interesting. The interesting parts of adventure games are always in the unique behavior of particular commands. For example, PUSH BUTTON activates playback of a videotape from a hidden projector. There's no physics model in the game of the videotape or the information recorded on it or of the wheels or magnetic heads of the video player; there's just a paragraph of canned text programmed programmed to display when the player types PUSH BUTTON. There's not even a physics model of the button; there's no model of a piece of plastic being displaced when the pressure from the player character's finger exceeds the counteracting force of the spring. Again, there's just a scripted event on the command PUSH BUTTON; in the simulation model itself, PUSH BUTTON has no effect whatsoever.

What we're getting at is that there's no inherent consistency in an IF game, so there's no possible way for the user to learn the world's rules. There's no basis for extrapolation or interpolation, deduction or induction. All things considered, the player is engaging in a game of random guesswork. For all we know, the programmer could have decided that the only way to win the game is to type LJFYGLKJ on the second turn.

Since the "rules" of IF don't enforce any degree of consistency, it's up to you as the author to impose consistency on your own game world. The more you can do this, the better your game will be.

Here are some specific types of consistency to aim for.

1. Special behaviors should be consistently special. For example, suppose the player has to break down a particular wooden door with an axe to solve a puzzle. To be consistent, (a) the axe should be able to break down every wooden door of similar build, and (b) it should be possible to break down the door with anything that's as heavy and strong as the axe.

If you tell the player "Violence isn't the answer to this one" every other time they try to use the axe to break down a door, what possible reason could the player have for thinking that the puzzle-solving door is different? If you tell the player "You can't break down a door with that!" if they try to break down the puzzle door with the crowbar or the bolt cutters, what possible reason could they have to think the axe will be different?

Note that we're not appealing to your sense of what's realistic here. The point is that the special behavior of that axe when used on that door constitutes a bad puzzle if the special behavior only exists in that one combination.

2. If you use unusual verbs, do so early and often. We talked above about the "core verbs" and the "USE verbs"; for our purposes here, anything else is an "unusual" verb. If you're going to use unusual verbs at all in your game, it's a good idea to use them very early on, in a couple of really simple puzzles. This will set the player's expectations that they need to be prepared to think expansively in terms of verbs.

If you let the player go through the first third or so of the game without needing anything but core verbs and USE verbs, they're likely to subconsciously decide that that's all they'll need for the whole game; when they encounter the FOLD PAPER puzzle later on, they'll be stuck forever, and then they'll feel cheated when they look up the solution in a walkthrough. You can bet that they'll skim through the rest of the game with walkthrough in hand.

So if you're going to use weird verbs at all, hit the player with a couple of them right at the beginning, and then keep using them from time to time, to keep the player primed to think about what other verbs might apply to each object.

3. Keep the level of object detail fairly uniform. Players will subconsciously infer the level of detail in your simulation after playing for a while. If you usually implement just plain objects, with no subcomponents, players will come to expect that most objects behave this way:

You are carrying a jewel-encrusted egg.

>examine egg
The egg is made of a thin, glassy shell, and is exquisitely
decorated with diamonds, emeralds, and rubies.

>examine emeralds
The egg is made of a thin, glassy shell, and is exquisitely
decorated with diamonds, emeralds, and rubies.

If you implement most objects so that they have actual subcomponents implemented, but you don't generally implement sub-sub-components, players will come to expect that:

>examine emeralds
A dozen green gems, some large, some tiny.

>examine large emeralds
A dozen green gems, some large, some tiny.

It's sometimes tempting to authors to bury important clues under two or three or four levels of subcomponents. But if you do this in one place without implementing such detail routinely, players will miss it - and they'll feel no shame in missing it; they'll blame you for unfairly hiding it. What makes it unfair is not that you buried the detail in such depth, but rather that you buried it in such inconsistency.

Plot and agency

The naive definition of plot in static fiction is basically that it's the stuff that happens. It's really a little more complicated than that; plot in static fiction is more properly the chain of cause and effect that drives the events of the story.

Novice IF authors often make the mistake of conceiving their game's plot as a series of events. They have a story in mind: Captain Owen arrives on a strange planet, finds an alien city, explores the city, is captured by a lizard creature, gets rescued by General Lustrous and her Amazon Resistance Fighters, joins the ARF in their big battle against the lizard creatures, gets a medal, marries General Lustrous, and gets back to his spaceship and flies home with bride in tow.

This isn't a great way to approach plot in IF, and we're not just talking about our cheesy storyline.

The first problem with plotting IF this way is that it relies upon the player doing what you - the author - wanted to happen at each step. This is particularly bad when you make this sort of plot progression into a puzzle: in other words, when you stop the action until the player guesses the right action to make the story progress according to your plan. The problem is that the player doesn't know what happens next - they have to have already read your story to know! Even if your storyline makes perfect sense to you, you have to keep in mind that there could be dozens of other directions that the story could have gone at each point - and from the player's perspective, some of those directions might make more sense than the one you chose.

You can reduce this problem by making sure that the player knows what they're supposed to do next. If you're going to force the player to follow a script you created in advance, then at least don't make them guess at what's in the script. One way to help is just to tell them outright what to do next. You don't have to tell them the exact next command to type, of course. Rather, you can narrate the next objective: "Now you know you must join General Lustrous in preparing for battle." A slightly less heavy-handed approach is to have another character pass along the information; Earth Mission Control could radio in the player's next instructions, for example.

The second problem with plotting IF like a book is that it tends to destroy any sense of player "agency" - that is, the player's feeling of decision-making power within the story. If the player feels like there's only one possible course of action at each step, they'll naturally feel railroaded. (That's why IFers say this sort of game is "on rails" - a disparaging remark that means that the game forces you down a particular path without giving you any chance to steer the story on your own.)

It tends to increase the feeling that a game is on rails if the limits on the player's choices are "motivational" - things like "You don't feel like breaking down the door just now" or "That's not very ladylike" or "You don't have time for that now." Motivational limits are useful to define the player character's character, but when they're used in service of the plot, players tend to find them grating. They're obvious, heavy-handed power grabs by the author, and they transparently take away the player's control over the story.

It tends to decrease the feeling that a game is on rails if the limits are physical barriers. Players automatically accept the physical reality of the game world - they can't very well not; it's essentially a condition of playing. Authors have exclusive control over the layout of the map and the initial placement of objects. This gives you considerable latitude in constraining the player's range of action by constraining where the player character can go. Considerable latitude, yes, but not unlimited: your map must not overly strain plausibility in its initial layout, and subsequent changes must be held to the even higher standard of being actually sensible. You can't just randomly have a new door appear halfway through the game because you want to close off an area that was previously open. You can't even close and lock an existing door for no apparent reason; you'd at least have to have a character in the game who'd be capable of closing the door and who has a reason to do so.

Because of the difficulties of plotting IF as though it were a static story, IF authors have developed a different approach to plot. In IF, the plot - and thus the story - is often discovered by the player character rather than enacted by the player character.

For example, many games revolve around uncovering a mystery from the past. The player character's actions involve looking around the scene of the events and discovering clues; gradually, as more clues come out, the mystery unfolds. The player's actions don't by themselves constitute an interesting story, but the unfolding mystery does; the story, and the plot, happened in the past, separately from anything the player does.

The same thing can work in the present. A story that involves other characters can be unfolding in the same time frame as the player's explorations. But the player character isn't the motivating force behind the story: some other character is driving the events. The player character might even be directly involved, but generally in a reactive capacity, rather than as the causative agent.

The benefit of this approach is that it gives the author full control over the plot, while still giving the player full control over how the story is discovered. You get full authorial control while creating maximum player agency - the best of both worlds. If the events are in the past, it won't even occur to the player that she should have been able to control them, so the player won't feel cheated out of agency. If the events are current but driven by another character, the author doesn't have to depend on the player to do certain things in a certain order, so has no need to railroad the player - the driving character will ensure that things happen as the author wants, no matter what the player does. Of course, the player character might try to stop the driving character from achieving his goals, but this is another area where you can assert authorial control without taking away player agency: you have to let the player try to stop the driving character, but you don't have to let her succeed. You just need to make the failures make sense in the story.

The real trick in this sort of arrangement is to intertwine the story's events with the player character's explorations and discoveries, to make the player feel a part of the overall story. Authors of conventional mystery fiction have perfected this technique; the usual climax is a confrontation between the detective and the killer at the exact moment when the detective figures out whodunit. IF can follow the same basic template: uncovering the full mystery reveals something that's dangerous to know, and the act of learning it triggers an end-game confrontation between the player character and the antagonist of the mystery.

Puzzles, whether and how

Modern IF can be divided into the categories of "puzzly" and "puzzleless."

The original adventure games were all about the puzzles. This was such an inseparable property of adventure games for so long that it came as quite a shock when puzzleless IF showed up in the early 1990s.

Puzzleless IF is hard to define exactly, because the question of whether a particular game element is a puzzle or not can only be answered subjectively. But roughly speaking, a puzzleless game is one that doesn't rely on anything non-obvious to advance the story anywhere in the game. These games tend to have relatively little "mechanical" interaction, and often focus instead on character interaction or scenery.

Whether to write puzzly or puzzleless IF is a matter of what you're trying to accomplish. A piece of puzzly IF is fundamentally a game; players will approach it as something to be solved. Puzzleless IF doesn't feel as much like a game, since there are no obvious obstacles, so players will approach it more as a story or an exploration.

If you do decide to go the puzzly route, I have some advice about how to design good puzzles.

The solution to a puzzle should be motivated: something in the game should trigger the player to think of the solution. It's unfair for puzzles to make sense only retrospectively - that's a catch-22 situation, because the player can't get the information needed to solve a puzzle until after solving the puzzle! It's considered bad form for a puzzle to solvable only with information gained through the death of the player character; this makes no sense within the context of the story world, because there's no way for a character who solved the puzzle to have known how to solve it, because that character couldn't have died. It's bad form to require specific knowledge external to the game, because it's unreasonable to expect every player to have the same background information. Of course, it's impossible not to rely on some common background knowledge, in that just knowing how to read English is a sort of background knowledge; what you want to avoid is anything that could be considered trivia.

A puzzle should be recognizable as a puzzle. The player should realize that a puzzle is an obstacle meant to be overcome, and not a fixed barrier; and the player should realize that a puzzle is there at all. An invisible door is a bad puzzle, because the player doesn't have any reason to think they should be looking for a door there. (Unless, of course, the player has an invisible door detector and has been told he needs to find an invisible door in a certain place. But then the player knows there's a puzzle to be solved, satisfying our rule.)

The player should understand her broad objectives at any given time. Metaphorically, a player should always be able to find a locked door before finding the key. The most frustrating feeling while playing an adventure is that you don't know what you're supposed to do next. If you find a locked door, you know that you have to find some way to open it; you know what to do, so the trick is to figure out how to do it.

One type of problem-solving is deduction, through experimentation and observation. You can invite the player to engage this form of problem-solving by offering objects that are implemented in great detail, and by making them behave consistently. Give useful feedback in response to verbs.

For example, you might design a machine, described as "a small metal box with a button, a short plastic hose on one side, and a large metal pipe on the other side." When the button is pushed, "a loud hissing comes from the plastic hose for a moment, then a large drop of clear liquid drops out of the pipe, which hits the floor and quickly evaporates into a white cloud of vapor." If the player puts the plastic hose in a glass of water and the button is pushed, "the water is sucked into the plastic tube, and few moments later a block of ice is dropped out of the pipe." This allows the player to learn by experimentation what the machine does, which is more fun for the player than if you had labeled the machine "a freezer" or some such.

Another type of puzzle that makes for good games is the kind that uses ordinary objects in an unusual but logical manner. For example, you could use a ladder to cross a chasm, or an incandescent bulb for its heat rather than its light. It's important that the use be logical; you don't want the player to have to guess a completely unmotivated use of an object. You want the player to think, "I need a heat source, but all I've got is this light bulb," and then realize that the light bulb is a heat source. It's also important that these special properties of an object be consistent; if the player tries to take the light bulb while it's lit, they should get burned. When a special propert is important in a puzzle, you must call as much attention to it as you can without giving away the solution.

Another common type of puzzle involves hidden objects. When objects are hidden, the player should be able to find them without resorting to looking behind and under everything in every room. For example, if you hide a crystal statuette under a seat cushion, someone sitting on the seat may hear a sound like breaking glass coming from under the cushion; looking under the cushion reveals a smashed statuette. (Providing a clue that doesn't result in a smashed statuette would be awfully nice, though, if the intact statuette is important to winning the game.)

Multi-purpose objects can add depth and realism, as well as providing a subtle type of puzzle. In many adventures, particularly of the old-school variety, the player can assume that each object has at most one use: once you figure out which puzzle the crowbar solves, you can toss it aside. You can take advantage of this expection to set up subtle yet logical puzzles simply by using an object for more than one of its properties. Players might assume that the obvious useful property of the object is the only one - especially after using it to successfully solve a puzzle - and they might not bother looking for other uses of the object.

Most players prefer games in which they can work on several puzzles at any given time. Which puzzles seem "easy" and "hard" will vary by player, so leaving several puzzles open at once gives each player the ability to work on whichever one seems most tractable to them. This fits into the most common overall IF structure: most games are structured into an introduction, a main body (or "mid-game"), and an end-game. The introduction and end-game tend to be fairly linear; that is, each event leads to the next in a fixed order. In the linear portions of the game, the player can only work on one puzzle at a time, and must solve it before moving on to the next. The body of the game, though, consists of several puzzles that can be attacked in any order. Some of these might have interdependencies, but for the most part it's up to the player which to attach when. You should try to keep the linear portions of the game as short as possible, to give the player maximum control by getting to the wide-open mid-game as soon as possible and spending most of the game there.

Designing games is a subtle and complex art. Just as most good authors are well-read, you will probably become a better adventure game author if you play a few good adventure games. And nothing is a substitute for experience - your games will improve with each new one you write. TADS 3 gives you a fine tool for creating games; the rest is up to you.