A while after the comp started this past year, I started thinking about writing this essay. Like last year and the year before that, there were too many games where it was obvious from the first few turns that they weren't going to be great, and it seemed like it was time to address the issue. I'm not sure if the situation arises because authors are purposely setting their sights low (looking at you, Mr. Hill); because they think they're writing something great and just aren't; or because they want to write something great and don't know how. This writeup is for people in the other two categories, who want to increase the quality of the games they're writing. I talk about what specifically makes a game great, and give advice on what to do and what to avoid doing.
We start with the premise that any idea can be turned into a great game. There are three kinds of problems that might keep this from happening — failures of construction (that is, in the design of the world), failures of interaction (that is, in how the player's experience with the world is managed), and failures of concept (that is, what world is created and what the underlying premise of the game is). Before I get into the specifics, I should probably present my credentials. I don't have any, but if you won't take the advice of someone who's never entered the annual comp and never won any major IF awards, well, I don't know what to say.
Failures of construction tend to show up when the basic components of the game aren't right: there are too many rooms or not enough, they're arranged in the wrong way, the puzzles are badly designed, the writing has grammatical errors, and so on. The result of this kind of failure is to make the game anywhere from amateurish-seeming to actively unplayable, since construction produces the structure that is the basis for the rest of the game.
The main thing to keep in mind about construction is that an IF game is played on two maps. One map is the world map: it consists of locations, which are connected by exits and contain puzzles made up of combinations of objects. The other map is the story map: it consists of scenes, which are connected by transitions and contain plot events made up of combinations of sentences. Every game has both these maps, though the emphasis on each varies wildly (puzzle games, for instance, tend to have an extremely basic story map with a start scene, an end scene, and a very large middle scene in which the player performs a lot of actions which don't advance the plot). Each of these pieces needs to be carefully constructed by the author to fit the needs of the game, and then the pieces need to be joined. Failures can occur at any point along the way, although some places are more likely than others to have problems.
Usually, the first place an author begins construction is with the locations. It's important to have the right number of locations in the game; locations with no gameplay purpose should be deleted, and those with too many purposes should be split. "Because it exists in the world being modelled" is never sufficient reason to keep a room — ruthless pruning of locations will almost always make the world map tighter and better. This isn't to say every room needs to have a puzzle: it's perfectly valid to keep a location because it helps space out the player's movement, or makes an area feel bigger, or otherwise contributes to the concept of the game. But the default must be that locations have to justify their existence, and a location that exists solely because it exists in the world being modelled is not justified unless modelling the world perfectly is in fact the concept of the game.
Exits connect the locations to form the map skeleton. There are a number of different world-shapes this can form, but in general the map ends up as a series of clusters, each of which are strongly connected within themselves, and have a few connections to other clusters. Controlled variety is necessary: having all the clusters be the same size is boring, but having one cluster be much larger than all the others often makes the game feel unbalanced. Similarly, clusters that are extremely small usually don't have enough to do in them, while clusters that are too large become confusing for the player to navigate. In fact, the act of clustering is itself a navigational aid — the player remembers that the back yard area is north of the house area is north of the street area, and so is able to work out roughly how to get from the street to the back yard without having to remember an exact path. A link to another cluster may be handed out as a reward as the game goes on: either this exposes a new area, or it makes an older area easier to reach (The Mulldoon Legacy is an excellent example of this latter technique). The reward of a connection to a new area is especially enjoyable to the player if they've been able to see the new area without being able to reach it before finally being granted access.
Puzzles have two complementary relationships with locations. Locations serve as containers to hold puzzles, but at the same time movement between locations is often gated by their puzzles. This ends up providing a nice variety of rewards for the player — sometimes the benefit of solving a puzzle is access to a new location, and other times the benefit of reaching a new location is access to new puzzles. Naturally, many puzzles are spread across locations, requiring a combination of components. The full process of designing puzzles has been discussed extensively elsewhere, and I don't have much to add. Great puzzles require strong clueing of nearly-right actions, complexity, and a leap of intuition. They minimize tedious actions and let the player get quickly to a solution once it's discovered.
Finally, the base element in the world map is the object. Like locations, it's important to get the number and arrangement of the objects right. Scenery objects are generally exempt from this — they can usually be considered more details of the location than objects in themselves — but mobile objects should have a purpose. Or several purposes: really well-crafted objects can be rewarding to interact with just for the pleasure of doing so. I don't only mean "well-crafted" in the sense of having a lot of verb responses implemented, but also in the sense of being an implementation of an object it would be nice to possess or interact with in real life: the wooden box in So Far is one of the quiet pleasures of the game, and The Moonlit Tower is almost entirely made up of beautiful objects.
Most of the observations for locations can also be applied to scenes on the story map. Scenes should only be put into the game if they're important and interesting; the player shouldn't have to play out the boring stuff in the story. And even if they are interesting, there shouldn't be too many scenes. Players (and the author!) get lost in overly-complicated storylines just like on complicated world maps, and generally they won't be mapping the plot. This doesn't mean that the story itself needs to be small-scale, but that the story map needs to be simple enough for players to hold it in their head. Clusters can help simplify things here, as does the fact that transitions between clusters on the story map tend to be one-way, but, again, the main technique has to be to decide on what the story is and then mercilessly strip away any scene which isn't relevant.
There hasn't been a lot of discussion about plot advancement in IF theory but most insights from static fiction writing apply: give the plot in digestible chunk sizes, remember the aphorism about Chekhov's gun, people are more interesting than things, and so on. IF authors do have one sizable advantage over static fiction authors that nobody talks about much, so I may as well state it explicitly: any story gets more interesting when you make the player act it out. After all, there's nothing like having a personal interest. Photopia pioneered another way to grab the player's interest with temporal cutting: an easy way to spice up a weak plot is to give it to the player in tantalizing bits and make them do some work to assemble it — again, making it personal. This isn't to say this sort of thing is a bad trick, just that it is a trick, and a trick on its own doesn't make a plot great. Luckily, a few tricks are enough to make a plot adequate, and if the focus of the game is elsewhere, that's good enough.
I haven't talked about constructing characters much yet, but in general the same techniques apply as for other objects in the game. Characters that are just there for puzzles exist purely in the world map; other characters exist only in the story map (which is not to say there's no interaction with them); and significant characters, like most significant objects, appear on both maps simultaneously. None of this is to say that character design is easy, but that the same techniques apply as with other objects (and here again, static fiction provides plenty of insight on developing characters in the story).
On the world map perspective, characters are noteworthy for being objects that, like computers, ropes, and liquids, can be interacted with in complicated ways. There are different ways to deal with this problem: some authors minimize all direct interaction with NPCs, or only permit a very limited set of interactions (Andrew Plotkin's games are usually pretty good at this); some authors put a lot of effort into a sophisticated conversation model (Galatea, City of Secrets, The Edifice); and most authors just don't worry about it too much, and players generally agree not to gripe too much about the limits of NPC conversation if it seems like the author tried.
Out of all the possible problems with a game, basic failures in construction tend to be the easiest to identify. They're also easy to make: just like it's all too simple to write a sentence with a comma splice, or include unnecessary adjectives in a description, it's easy to produce confusingly-arranged rooms or an ungainly plot. But by editing their game with the goals of proper construction in mind, the author can create a lean and strong framework for the rest of the game to build off.
There are a number of good articles out there on different aspects of construction. Stephen Granade has an excellent discussion of writing descriptions on Brass Lantern; Emily Short has a very comprehensive discussion of laying out the world map; and XYZZYnews has many relevant pieces, including a puzzle roundtable and a great article by Gareth Rees specifically about construction which has some nice side-notes on NPC development and covers many of the same points that this section raises (only he got there nine years earlier, sigh).
Once the map is built and the pieces are out, it's time to play. Failures of interaction occur when the player tries to manipulate the pieces of the game in a way the author didn't anticipate, or when the player isn't sure where to go or what to do next. These kind of failures tend to lead to frustration; a game can be obviously made of high-quality components, but if the interaction with the game is bad, the quality of the parts just makes playing all the more maddening (Fine Tuned is a notorious example).
The first step, though, is just making sure the player wants to play the game at all. The first things a player sees about a game are its author, its title, and (usually) its blurb. The best way to hook a player is to be able to put "by Adam Cadre" in the author field. Assuming this is out of the question, the other two fields are where it's at. Being Andrew Plotkin is the canonical example of a brilliant title, but Stupid Kittens and Lazy Gods of Earth are also both demonstrations of what a great title should do: suggest a genre and type of game while offering a little twist to show they're not going to be quite what the player expects. The same applies to the blurb, where the point is not so much to describe what the game is about ("The dragon Firetail menaces the village and you, a bold knight, must stop it!") as to pick out the interesting bits and let the player know what play will be like ("Hurry, sir knight! You've got a dragon to rescue and a princess to slay — or is it the other way around? Ever since that bump on the head things have been a little confused ...").
The next barb of the hook is the introductory text. Some authors make the mistake of thinking this is where they give the player important information about the game. No no. The player, at this point, is only half-reading because they're only half-interested. The main purpose of the introduction is to make them the rest of the way interested. So, again, the idea is to tease and to lure. Do not under any circumstances overwhelm the player with information in the intro — show the player a little about what's ahead, set the mood, and that's all. If they don't type >QUIT as their first move, things are going well. It's often a good idea to give the player a short task at the beginning of the game; it doesn't matter too much what it is as long as it gives the player a push to get them started in the right direction.
Assuming the player's made it through the intro, it's time to worry about keeping them in the game. The player should know what they want to do, or be willing to explore, so the main issue becomes making them feel like they want to keep interacting with the game. The important job is to not make interaction feel like a burden, which means that when the player types something, it has to be understood, especially at the beginning of the game when the player isn't hooked much on the story. The most trivial instance of this is in making sure that every vocab word mentioned in a room description is defined in the game as an object (this is called a "first-level object"), and every vocab word mentioned in the description of another object is also defined in the game, either as an object in its own right (a second-level object, third-level object, etc) or as a synonym for an already-existing object. This level of depth is the minimum requirement for modern IF games; the lack of it in older IF works (from Infocom and the like, and even some 80s/early-90s games) is extremely noticeable when playing them these days. The modern standard seems to be that second-level objects are optional but nice, and that players generally won't expect third-level objects unless they're on the trail of a puzzle. The Light: Shelby's Addendum is one of the earliest modern games I can think of to use this technique for a puzzle; Metamorphoses, a more recent game, breaks this rule by having many-levels-deep objects throughout the entire game — but it's part of the theme of the piece, and it works.
Beyond that we get into what differentiates a good game from a great game: the anticipation not just of nouns, but of verbs and full command phrasings. The only rule I know is the trivial one that if a verb phrasing is given in a description ("The bandages are the kind for wrapping around a swollen ankle.") then that exact syntax should be supported, in addition to any more conventional forms the author wants (>WRAP BANDAGE AROUND SWOLLEN ANKLE). The reverse is also true: if a complicated phrasing is required, it should be given in advance of it being required.
There are no good discussions that I know of out there about how to do this kind of understanding of player intent really well, although the issue has been talked about for a long time ("guess the verb" being the term for the most grievous failures to understand). Even studying games that do command-anticipation well is difficult because this is something which has its success measured by the degree of its inobtrusiveness (but Andrew Plotkin is the acknowledged master of interaction design, so it's worth it to spend some time trying to work out what he's doing in games like Shade and Hunter, in Darkness). Really, though, synonyms are one of the few parts of the game where the majority of the work has to come during beta-testing: there's no real way to tell for sure what players will type without just making them type.
There is nothing particularly interesting to be said about beta-testing except that it simply must be done — the author can fix bugs in the game on their own, but only a beta-tester can demonstrate what the play experience is like for people who aren't the author. Of course, it also differs for different players. One player might take the north exit first while another takes the south exit first; or one player might see random message X and another see random message Y — the gameplay must not be allowed to break in any case, so both exits had better be ok choices, and both random messages ought to give information if it's important for the player to see. Even one tester helps, but three or four are better; if it's a large game or many changes have been made to it during testing, it's nice to have a second or third shift of beta-testers who can come in for a fresh look later in the process.
Authors should ask for at least a transcript and a rough playtime estimate after the tester's finished (or possibly incremental transcripts as they work through it). It's useful to get comments within the transcript as well as after play is over, so it's a good idea to include some sort of "note" verb to signal that the rest of the line is a beta-testing comment. This allows the game to ignore the comment line and the author to search for it (for some reason beginning the line with "[" is a popular convention for this sort of comment). Having beta-test releases of the game automatically start transcription helps to ensure both that beta-testers remember to keep a transcript and that beta-test/debug releases are not released as the final version.
Another important part of guiding the play experience is via the basic game-information commands. At a minimum, games need to support >ABOUT, >HELP, >HINT, >CREDITS, and >VERSION, although these may be aliased to one another. >ABOUT and >HELP should be short, a paragraph or two at most. Their point is to convey the least amount of information the player absolutely needs to get started with the game. Ideally, most information is explained as part of the play of the game, but there are some things (whether the game can be made unwinnable, author contact info, if some standard command works in an unexpected way (eg, in the conversation system)) that can't be done that way. If the author wants to include extensive information about the backstory or about writing the game, >HELP should trigger a menu, or it should mention a command to type for more information. Authors who put too much information in the initial help command risk the player failing to remember any of it.
>HINT should be provided as a command even if there are no hints. In that case it would print "Sorry, this game has no hints." or similar — authors should be careful about the phrasing there, as there are few things more enraging to a frustrated player stuck on a puzzle than "This game is too easy to require any hints". If >HELP isn't an alias for >HINT, it should mention the >HINT command to make clear that it exists. Walkthroughs are another reasonable option for games; they tend to be substantially less work than writing hints (and have the feature that if they're in a separate file, then if the player wants to skip to the end of the game they can generally load the walkthrough into the interpreter directly — whether this is a good feature is up to you). As with hints, walkthroughs should be written in the order the player will be using them. This means that the walkthrough should include commands to explain the purpose of actions before they're done (examine the desk before pushing the special carving).
The final interaction-related issue that all games have to deal with is the proper way to set player expectations. Part of playing any IF game is learning how to play that IF game; the game tells the player "I'm a puzzle game" or "I'm a conversation game" or "I'm a mystery game" and the player learns to respond appropriately. This is fine, but trouble arises when the game is inconsistent. If the game has been saying "I'm a game where you don't need to examine objects closely", then players are likely to get stuck on a puzzle that requires >LOOK UNDER DESK. Once the player has been burned by this kind of expectation mismatch a few times on a particular game they're likely to just stay with the walkthrough, or drop the game entirely.
To avoid frustrating the player, it is vital that the author think carefully about the experience they're creating. Puzzles may be fun in themselves but not fit with the kind of play the rest of the game promotes: they should be cut out. A scene may be funny but rely on a command used nowhere else in the game: it should be dropped, or the command should be used earlier to prepare the player. A transition may be triggered by the player staying in a particular room for a certain number of turns, but there's no other reason provided for the player to stay there that long: the transition should be altered to something the player will actually do. These are all easy errors to fall into as an author, who knows everything about how the game should play and tends to forget how the game actually does play (I know I got flack from reviewers for putting in a super-hard puzzle midway through Max Blaster and Doris de Lightning Against the Parrot Creatures of Venus; it was fun to code but I should have left it out).
By focusing on and repairing the failures of interaction in a game, the author brings out the game as it has been conceived. Some people have said that a great user interface is invisible. That may be true, but that doesn't mean it's ineffectual: like a great tour guide, it leads the user to the best parts of the game and then stands back to let them appreciate the view.
The easy and common interaction issues have mostly been identified and discussed already. In copious detail, in fact, and the main reason discussion on basic interaction errors still continues is because authors keep making the same mistakes, not because there are exciting new developments in the field of beta-testing. The good news is this means there are plenty of detailed essays on the subject. Stephen Granade has the classic piece on user expectations, The Player Will Get It Wrong, and XYZZYnews is again a great source for advice on this topic, including several on beta-testing, a short one on hints, and a nice analysis of a puzzle from the perspective of interaction.
The concept of a game is like the cover of a book: it provides a catchy display to spark the player's interest, has information about the game, and its spine holds the entire story together. Concepts are very hard to analyze in a systematic way: while there are some rules for what shouldn't be done, it's much harder than for issues of construction or interaction to see what should be.
Having said that, one of the major rules for writing a great game is "develop the concept until it's interesting". This is not to say that there's anything wrong with starting with a concept like "it's, uh, a game where the player is on a quest, and they have to solve some puzzles and get a magic thingy, and then at the end there's this dragon or evil wizard or something." This shows up in Generic Fantasy Adventure #17, sure, but it's also the premise for Enchanter. The difference is that GFA#17 stops developing its concept right there, and Enchanter continues "...but the cool bit is, the player has these spells that do different things, and more spells can be found as the game goes along, and almost all the puzzles can be solved by using them cleverly". Now we're getting somewhere.
In fact, any concept which doesn't contain the phrase "the cool bit is" is probably a bad concept and needs to be reworked. Nor is it sufficient to stick the cool concept in there and forget about it; if the author is serious about this being the cool bit then the whole game ought to be about showing just how cool it is. Enchanter is a great example of unflinching dedication to concept. So are Rameses and Common Ground, even though their concepts are quite different. The obvious rejoiner here is "well, what if nobody else thinks the concept is cool?" Sure, this is going to happen. I didn't care much for Rameses even though many other people loved it, whereas I'm in sparse company in thinking Death To My Enemies was great. But given the choice between a concept that you think is great and one you think is lousy, it's almost always a better bet to go with the great one and hope other people agree, since the alternative is to write around a lousy concept and hope people disagree with you.
When developing the concept, you don't have to just be guessing about what the audience will like or think is cliched, either. There are plenty of games out there, and going through something like the IF Scoreboard's top 20 or Emily Short's IF Literacy page will give you a firm grounding in the field. It quickly becomes obvious that games where the hero turns out to be the bad guy isn't going to fly as a concept on its own, nor is one where the character needs food to avoid starvation, or where the story is told in a non-linear fashion. This doesn't mean that games with those as part of their concept can't be great — Savoir Faire has a hunger puzzle, a darkness puzzle, plus numerous locked-door puzzles — but it does mean that most people are not going to agree that this part of the idea is the cool bit. On the other hand, Anchorhead and Sting of the Wasp have pretty simple concepts, but because they're not cliches (in the IF world, anyway), they're plenty good enough to get by, and solid construction and interaction make the two games great.
Finally, the last thing to consider about the game's concept is whether it's strong enough to sustain the entire game on its own. No matter if the idea is "You're all alone in an abandoned research station, trying to figure out what happened" or "You're in your house getting ready to go on vacation", there is only so much that can be done with it. That's when the author should deploy a sinker — something that takes the game so far and pulls it somewhere deeper.
One of the best case studies for sinkers in action is Spider & Web. The first part of the game is rife with sinkers; I count at least five all crammed in. The density of sinkers first draws people in, and then brings the action to a climax. By comparison, the second part of the game is substantially less captivating, despite being a higher-adrenaline sequence. Enchanter is another interesting example: each new spell you get is a mini-sinker that changes how you think about the items in the game — a previously useless door is now a possible target for >REZROV. Spider & Web and Enchanter are also noteworthy for how they time their sinkers. Just like it's important not to have too few cool things at the beginning of the game, it's important to have few enough that the player has the chance to appreciate each one, and to toss in a new sinker just before the player gets tired of the existing ones. It's even ok if the player anticipates one or two of the sinkers the author puts in — they'll feel smart for guessing right — as long as most of them come as surprises.
Failures of concept are the least harmful to a game, in a way. With a so-so concept a game can still be perfectly good: people might remember it for its clever puzzles or stylish writing. But it takes a great concept to make a great game. Not that concept is sufficient to make a game great — Guard Duty is notorious as a game with a brilliant concept but so badly constructed it fell apart within a turn of starting up — but it is absolutely necessary.
Most of the advice I've found about developing the game's concept has been scattered amongst advice about construction or interaction. The most promising links have been in advice about setting design: Emily Short's article on developing a setting for fantasy IF is pretty good in this regard. Another good place to look for concept-design advice is interviews with authors. SPAG has had wonderful interviews with the comp winners for a number of years, some of which give very interesting insights into the way different people design. Finally, Sean Barrett pointed out that scriptwriting sites often have advice for developing an idea into a good concept.
So that's how to write a great game. Which, by the way, isn't a guarantee of audience appreciation. This is an art, not a science, and even if you do everything right there'll be people who hate your game, and even if you don't there'll be people who love it. But one of the nice things about the small size of the IF community is that very few things fall through the cracks entirely; write a great game and it will get recognition.
Not much that I've written here is easy — it's one thing to say "the puzzles need to be good", and quite another to actually write a good puzzle. But if you aren't at least trying to make good puzzles you're only going to produce them by accident. Making a great game means aiming high.