# Choosing a Conversation System

Perhaps the most vexing problem of all in creating lifelike NPCs is conversation. This is the part of Interactive Fiction where the immensity of the gap between modern software technology and human-level intelligence becomes most apparent. This is also the problem that has made Artificial Intelligence research appear so hopeless to so many people: despite decades of effort by top scientists, not only has no one ever passed the deceptively simple Turing Test, no one even truly knows where to begin. A significant, if unexpected, result from AI research has certainly been that the workings of the human mind are vastly more subtle than they at first appear.

So what's a pragmatic IF author to do? Clearly it's beyond our reach to create characters that can engage the player in actual conversations; the best we can hope to do is create the impression of conversations - not the illusion, but the impression. What do I mean by this? I mean that we don't try to actually fool the player into thinking our characters are real people, but rather concentrate on giving the player the feeling of having a conversation even though the player knows it's not real.

Interactive Fiction authors have been grappling with this problem since the format was invented. Given that it's been somewhere around thirty years (at the time of this writing) since the first adventure games were created, and given that the conversation problem is far from solved, it might seem that progress has been ridiculously slow. I don't think that's evidence of a lack of creativity or effort on the part of the IF community, though; I think it just goes to show how hard a problem this is.

We won't get into the actual programming details of implementing conversations until the next part of the article. In this part, we look at conversation systems at the design level. We'll start with a survey of the main types of systems that have been tried, with an eye to their strengths and weaknesses. After that, I have some recommendations for authors thinking about what kind of conversation system to use in their own games.

## Survey of IF conversation systems

We start by looking at some of the conversation systems that have been used in past works of Interactive Fiction. This list certainly isn't exhaustive, but it covers most of the systems that have been widely used.

IF occupies a wide, blurry band on the spectrum between completely static fiction and full-blown "virtual reality" experiences, and it's certainly not the case that every game aims for exactly the same kind of effect. In assessing the different conversation systems, I'm obviously making certain assumptions about the kinds of effects the game is trying to achieve. A system that's terrible for one game might be perfect for another. So, you'll have to adjust my remarks about what's good and bad about the different systems according to the specific effects you're trying to achieve.

### Cheap AI

A few games (notably Douglas Adams' Starship Titanic) have tried various "cheap AI" approaches. That is, they try to create the illusion that NPCs understand natural language input by disguising a much simpler technique that's within the reach of modern software. One such approach is "keyword" matching: tell the player to type actual English sentences, then scan the input for certain meaningful words, simply ignoring the sentence structure and any words that we don't know. A similar but slightly more sophisticated technique is "regular expression" matching, along the lines of the classic "Eliza" program (a simulated psychoanalyst that used textual templates to recognize a number of basic sentence structures, then parroted back the user's input, usually with some grammatical rearrangement based on the templates).

In practice, this type of interface hasn't been very successful, mostly because none of the known "cheap AI" techniques stands up to even modest scrutiny. Despite the naive appeal of keyword matching, it suffers mightily from its lack of context sensitivity (minor changes, like inserting the word "not" or rearranging a couple of words, can completely change the meaning of a sentence), and also fails to cope with simple problems like homonyms (more precisely, homographs: words that are spelled the same way but have different meanings). Eliza-style regular expression matching is a poor fit to the actual tree-like, highly recursive internal structure of natural languages, so it fails when presented with anything beyond the structures specifically enumerated by the programmer.

The main problem with the cheap AI approaches is that players quickly see through them. Technically sophisticated players realize at once what's really going on, and adjust their playing styles accordingly; many Starship Titanic players report that they started just entering individual keywords once they saw what the parser was doing, because the parser became confused too easily when a single input contained multiple keywords. Technically unsophisticated players might not be able to infer the internal behavior; what they will do is decide that the program is buggy because its responses are so obviously incongruous with their input. Neither kind of player is fooled into thinking the program understands what they're saying. To my mind, if you can't successfully fool the player, it's better not to try, because you're expending your effort making the wrong thing good. It's like hiring an architect who usually builds airports to design your house: if she spends a bunch of time making sure the baggage claim in the living room is easy to use, it's a waste of effort, since you're never actually going to claim baggage in your living room. It's much better to just tell the player up front how the program really works, and then spend your effort making that experience good.

An experimental system called Façade, by Michael Mateas and Andrew Stern, uses a combination of AI techniques and emotion-state modeling to create a sort of electronic improvisational theater. Façade has receive a lot of attention both among IFers and in the broader game development community, and many consider it groundbreaking. The system's approach isn't exactly "cheap" AI; it's more like mid-priced AI, in that it sticks to the well-known conventional techniques of natural language parsing (keyword matching, templates, grammatical parsing), but throws a ton development effort at the problem: it seems to have a huge database of keywords, templates, and grammar patterns that it tries to match. Most people have been favorably impressed by the results, although the system still won't truly fool anyone (i.e., it won't pass any Turing tests). If you hold out hope for an AI approach, you might or might not take comfort from Façade; on the one hand, it seems to show that conventional NLP techniques can yield incrementally better results with incrementally more work, so it's not completely pointless to try; on the other hand, it took a lot of work to get the results they did, and they still aren't fooling anyone, so you might conclude you're better off putting your effort into something with a higher return on investment.

### ASK/TELL

The earliest IF conversation interface was probably the ASK/TELL system, and this still seems to be the most widely used style. With the ASK/TELL system, the player converses with characters using commands like ASK MAN ABOUT BACCARAT.

A big advantage of the ASK/TELL system is that it integrates smoothly with the rest of the user interface, in that conversational commands have exactly the same format as any other command (VERB-DOBJ-PREP-IOBJ).

ASK/TELL is "open-ended," which is both good and bad, in varying degrees to different people. It's open-ended in the sense that there are no apparent limits to what you can ask about; you can type anything you like after the word ABOUT, after all. This is good, since it creates a feeling of boundless freedom for the player; but it's bad, in that that freedom is an illusion. The reality is that only a limited number of pre-programmed topics actually have interesting responses. For many players, the illusion of boundless freedom is quickly destroyed when ten topics in a row all return "I don't know about that." To some people, the invisibility of the limits is good, separately from any illusion of freedom, in that it maintains an "inductive" challenge rather than the purely deductive one that would result from enumerating the valid inputs; to other people, the same thing is bad in that it fosters "guess the noun" puzzles that are as annoying as "guess the verb" puzzles are in normal play.

Another property of the ASK/TELL system is that it usually makes for "stateless" conversations. Each ASK/TELL command is essentially a little self-contained interaction; we ask a question, the character answers, and that's it. Sometimes there's a small amount of context: asking about the same topic repeatedly might elicit different responses, for example. However, this isn't usually true conversation state, in that you could probably get the same results by asking, doing something else, asking again, doing something else again, and so on: all that matters is the number of times you asked, not that you asked several times in a row. This statelessness is mostly a disadvantage, I think; with no continuity from one ASK to the next, there's no sense of a conversation, just these weird, unnatural, isolated fragments of conversation. There's also this strange sort of static familiarity: when we walk up to a character for the first time, never having met the character before, and ASK ABOUT something, the character just answers, as though they've known us for years and as though we've been chatting for half an hour already. By the same token, talk with a character for half an hour, ask an umpteenth question, and it's like we're meeting the character for the first time. There's an almost dream-like surrealism to it, as though you're always waking up into a conversation that's been going on forever and will keep going on forever. The only good thing about the stateless quality is that it avoids the "menu maze" effect that can sometimes occur in menu-based systems.

Another substantial drawback of ASK/TELL is that it's difficult to create the illusion of a natural conversation with such a limited range of expression. There's no way to agree or disagree with something an NPC says; no way to greet, chastise, comfort, ridicule, sympathize with, flatter, insult, thank, or apologize to a character; no way to lie or be frank; no way even to express exactly what you want to ASK or TELL someone about a given topic. Some games have experimented with adding verbs for some or all of these things: THANK, INSULT, APOLOGIZE, COMFORT, JOKE, SMILE, FROWN, and on and on; but in practice this ends up being almost like adding adverbs, in that it does nothing but add an exploding number of new commands that hardly ever do anything interesting. And if guess-the-noun is a game that's no fun, guess-the-noun-adverb-combo is positively hideous.

### Menus

Graphical adventures introduced menu-based UIs for conversations many years ago, and text games have been experimenting with this approach for a while now as well. In most formulations, the player initiates a conversation via some sort of TALK TO command (which, in graphical games, might just be a matter of clicking on the NPC), and is then presented with a list of options; the player selects an option, the NPC responds, and a new list of options is displayed. This proceeds until the player chooses to end the conversation or runs out of things to say. The nature of the options varies; in some games, it's a list of literal things for the player character to say, and in others it's a list of topics. In some text formulations (notably some of Emily Short's work), the player has the additional axis of control of switching to a different topic at any time, using a free-form command akin to ASK.

Menus gives authors two key elements of control lacking in ASK/TELL systems. First, a menu strictly limits the range of input; rather than having to handle any possible ASK topic, at any given prompt we only have to handle the set of three or four options that we specifically enumerate at that prompt. Second, because we're enumerating the options, we're free to make the choices as detailed and expressive as we want - we could offer options to ask the same question in either understanding or accusing tones, for example. We could in principle do the same thing with ASK/TELL using adverbs or something, but doing so would increase the already huge search space to the point where we could never expect players to find the few options we actually implement; with menus, this isn't a problem, since the options are openly laid out for the player to choose from.

A major benefit of menu-based conversations is that it's relatively easy to make menus stateful. In most menu systems, after we select an option from our current menu, we don't simply return to the current menu - we go to an entirely new menu. This allows the author to create the effect of a thread of conversation, which is almost always much more natural than the staccato fragments of ASK/TELL. The reason it's fairly easy to create threaded menu conversations, but hard to create threaded ASK/TELL conversations, boils down to the limited range of options at each point. With ASK/TELL, it's simply impractical to be able to thread to any topic from any other topic; this would require anticipating (topics queries) possible threadings, where topics is the number of possible topics (i.e., indirect objects of ASK ABOUT), and queries is the number of ASK commands in an entire conversation. Menu authors are faced with the exact same arithmetic, but topics is replaced by menu options, which can easily be kept at three or four without arousing any discomfort from the player; this would be impractical for ASK/TELL, because limiting the player to three or four valid ASK topics at a time would create an unacceptable "guess the noun" game. In practice, the expanse of the menu tree is further reduced - vastly so - by looping (where a branch leads back to a prior node) and converging (where several branches lead to the same node).

A disadvantage of the statefulness advantage is that it can create a "menu maze" effect for players. That is, players will sense that the conversation menus form a graph of nodes, and they'll naturally desire to exhaustively visit every node in the graph, but they won't have a clear idea of how to navigate the graph because it's so hidden. My own experience as a player suggests that the best way to avoid this problem is simply to avoid using menu-based conversations as puzzles; in other words, don't hide anything important in branches of a menu tree, but always put the vital information in "trunk" nodes that all conversation paths eventually converge upon. This approach might seem to eliminate any challenge and make conversations useless, but again, drawing from my own experience, I think it can improve the feeling of interactivity by giving the player an enjoyable experience threading through a conversation menu, but at the same time freeing the player of any incentive to go back through the menu to exhaustively map out the tree. I personally find these sorts of things a lot more satisfying if I'm not forced to treat them as puzzle boxes to be disassembled. Conversations can serve more important purposes than just hiding puzzle solutions; they can flesh out characters and develop the plot.

Menus obviously constrain the player's options; this is both good and bad. It's good in that it eliminates any chance of a guess-the-noun puzzle; players will never feel like they're hunting around in the dark for the right keyword. It's bad in that it brings the mechanism so obviously to the foreground that players almost can't help but approach it mechanistically. It also makes the boundaries of the game plain; many people find this undesirable because it removes the illusion of boundless possibilities. (A free-form "topic switching" capability can mitigate the feeling of being constrained to a few options, but it can't eliminate it entirely; even if "or anything else" is always an option, the fact that options "A" and "B" and "C" are enumerated can't help but call attention to the existence of boundaries.) I personally think that the supposed "boundless" quality of text IF is overrated; I think a big part of the reason that most people don't like text IF is the stark contrast between the promise of "boundlessness" and the reality of "I don't know that word." I think most people approach a text game with that wonderful promise of endless choices in their minds, and after the fiftieth "you can't do that here" or "I don't know that word" or "I don't know anything about that" they give up and go play something with graphics and a sane UI. Even so, a lot of people who do like text IF say that the illusion of boundlessness is a key reason why, so it's worth keeping this in mind when designing a game.

For all their good features, menus are a poor fit to the conventional text IF user interface. To me, this is a bigger drawback than the illusory reduction in range of action. The fundamental problem is that menus are a multiple-choice test, and the rest of the interface is an essay contest. To me, the charm of the free-form command UI isn't its supposed boundlessness (see rant above); it's the subtle UI transparency, the illusion that you're not operating a computer program at all but are just carrying on a conversation with the story's narrator. As I emphasized earlier, it's not important that we actually fool the player into thinking she's in a conversation with a human narrator; what's important is to do nothing to jar the player out of her willing suspension of disbelief. Every menu UI I've seen in a text game involves some sort of obvious break from the standard narrative output and command input; the break calls attention to the UI and thereby degrades the conversation-with-narrator experience. Here's a summary of the menu UIs that authors have tried:

- The most common approach is to show a numbered list of choices, with one choice per line for readability. You get a special prompt at which you type the number of your selection. This is bad on two counts: the list of options is not prose rendered in the narrator's voice, so it doesn't fit in with the rest of the transcript, and the input of a numbered choice doesn't fit with the usual command input format. The special prompt is bad on the general UI design grounds that modal interfaces are bad except under specific conditions that do not apply in this case.
- Recognizing the incongruity of the numbered list, some authors render the list in a separate window on interpreters that can support such UI tricks. This helps a little, by taking the list out of the transcript. It doesn't solve the input problem, and it doesn't truly address the main problem, which is that there's a special UI at all. It is arguably a better special UI than the in-line numbered list, but it's still a special UI.
- Some games use a standard command input prompt rather than a special prompt. Entering a number at the prompt selects a menu; anything else is treated as a normal command. This eliminates the modality problem, but doesn't address the exceptional input format or the unsightly numbered list.
- Kathleen M. Fischer's Redemption introduced an interesting variation. Rather than using a numbered list, the game shows a brief list of options, in paragraph form - something like "...ask about Malcolm, agree, disagree, or tell him to leave." At the prompt, the player enters one of the keywords from the desired option - so to choose "tell him to leave" we might type "leave." Although there's still a list of options displayed, it almost fits in with the surrounding narrative text; at a glance, it certainly doesn't stand out the way a numbered list or a separate window does. In addition, by using keywords as the player input, there's superfically a feeling of entering an ordinary command rather than a number from a multiple-choice list. It's almost as though the list of options is a little gentle guidance from the narrator, as though we could type anything else we wanted, but we choose not to. The one failing of the system as implemented in Redemption is that the input prompt at these menus is modal. With a modeless prompt (so that we could either choose a menu keyword or enter any ordinary command), the system might well address most of the UI drawbacks I see in menu systems.

### Hyperlinked replies

A variation on the menu system is to show options as keywords, using some distinctive visual style, embedded within an NPC's responses. So, you ask the villager about the cave, and the villager replies "Don't go in that cave! There are all sorts of monsters there! But also legends of a great treasure!" The keywords are topics for subsequent ASK commands. A number of RPGs have used this technique (RPG = Role-Playing Game, which is actually a much narrower niche than you'd think from the name; in industry parlance, RPG almost always means something with D&D-derived rules and a particular kind of UI). The usual UI involves essentially hyperlinks: some of the words in the NPC's response to a query will be highlighted visually, and clicking on one of the highlighted words asks the NPC about that word, which elicits another response with more highlighted keywords, etc.

This style is almost exactly like menu-based conversations; the only real difference is in how the UI is presented. (Interestingly, I don't think I've seen it used in a text game, even though it's been used in numerous RPGs.) Apart from the practical problem that some interpreter platforms might be unable to show a special visual appearance for the keywords, this approach would seem to have the same sort of problems as other menu-based UIs. In particular, the special highlighted appearance of the keywords would be an obvious intrusion of the UI into the narrative text. It also suffers from one of the big problems with ASK/TELL: it's impossible to express any thought beyond "WHAT IS (X)?"

### Menu-less TALK TO

Back in the old days of MS-DOS software, product managers spent a lot of time worrying about how difficult the installation process tended to be. The buzzword of the time, and the sort of holy grail of product managers, was the "one-button install" - an installation process so simple that the user just had to click on the button that said "install." It always seemed to me that if you could get the install down to one button, then they ought to just push it at the factory and give the user a zero-button install.

Some authors have taken a similar sort of tack with conversation systems. The idea is to take the key feature of menus - limiting input options to an enumerated set - to its logical extreme, which is to reduce each menu to a single option. Once a menu has only one option, we can dispense with the menu entirely, since there's no need to solicit player input when there's no choice to be made. This eliminates the user interface problems of menu systems, while retaining some of the main benefits: the player doesn't play guess-the-noun, the author has control over the range of options, and the options (well, option, singular) can be arbitrarily detailed and expressive.

Several games have taken this route, notably Ian Finley's Kaged and Stephen Granade's Common Ground. In concrete terms, conversations look something like this:

      >talk to bob
      "I was out at the lighthouse today," you start.

      Bob looks extremely flustered.  "What are you talking about?"
      he asks.  "They tore that place down years ago, after the...
      troubles."

In other words, the player initiates a conversation, but has no control over what the player character says. A single TALK TO command typically invokes a single exchange; to continue the conversation, the player would enter a new TALK TO command. As with menu systems, this approach constrains the problem space to an extent that allows for a great deal of awareness of context - the player character can say specific things that are appropriate to the plot and character development, and conversations can follow a subject thread.

This approach has received a mixed reception from reviewers. Obviously, it trades off a lot of interactivity for the increased authorial control, which some people hate and others don't mind so much. It doesn't completely remove the player's control, since the player can choose to talk or not, and can continue with a conversation or not; but even so, the reduction in control is so drastic that players cannot help but notice. My own experience with games using this sort of system is that it can make for natural, realistic conversations, just as menus can, but that there's something too distancing about it. It's perhaps too similar to finding a diary in the game and reading it: it can give us interesting background material, but it's more like reading about a conversation than participating in it.

### Other Approaches

There are a few other approaches worth mentioning. These are less widely used or less generally applicable than the systems we've already talked about, but merit at least a passing mention.

A game without NPCs solves the conversation problem by bypassing it entirely. As such, "no conversation system" isn't exactly a type of conversation system, but it could be considered a solution of sorts to the problem if only because it's one that a lot of authors have used.

A few authors have tried interactions based on emotions rather than topic-like information. Rather than verbs like ASK, TELL, GIVE, and SHOW, we might have verbs such as HAPPY, SAD, POUT, FLATTER; or we might have adverbial variations of conversational gestures, such as GREET WARMLY or GREET SUSPICIOUSLY. Characters are modeled as emotion state machines, and the game is in pushing the characters through their emotional mazes to some desired goal. There has yet to be a truly successful example of this approach. The closest, and most ambitious, is probably Chris Crawford's Erasmatron. Many IFers who've looked at Erasmatron consider it a failure that proves that this approach won't work (the main sample game produces results that are so bizarre and incoherent that it became a running joke in the IF newgroups for a while); Crawford's supporters counter that the engine has potential that hasn't been properly tapped in example work yet. Adam Cadre's Varicella uses a sort of hybrid of emotions and conventional ASK/TELL, allowing the player to choose a tone of voice for each question. But the range of tones is quite limited (to three possibilities), and the effect seems mostly superficial; in fact, if the range of tones weren't so limited or the effect were anything other than superficial, the exploding number of possibilities would probably make the game impossibly difficult (both for the author to write and for the player to play).

ASK/TELL systems sometimes make me feel like I'm in a foreign land where I don't speak the language, and my only way to communicate is to point at things - a crippingly limited mode of expression. Sometimes, though, a story actually is set in a foreign land, or it's set on an alien planet, or the player character is autistic, or there's some other good story-rooted reason that the player character can't communicate straightforwardly with the story's other characters. In these cases, the limitations of IF conversational systems can actually work to the game's advantage. Lucian P. Smith's Edifice uses this to good effect. Obviously, though, this technique has limited applicability.

Andrew Plotkin's Spider and Web uses a possibly unique approach that essentially inverts the typical ASK/TELL style: rather than the PC peppering NPCs with questions, an NPC asks the questions and the PC answers. The trick is that the questions are all of the YES/NO variety, so the range of player input that the parser has to understand is neatly limited. This could certainly be extended to multiple-choice answers ("Which one do you like better, the blue one or the green one?"), but even so, it's hardly a general-purpose conversation system; it requires a degree of contrivance in the game structure that severely limits its reusability.

## Recommendations

As you might have noticed, I have some opinions about what works and what doesn't in the various conversation systems. In a moment, I'll distill these down into some recommendations. First, though, I want to emphasize that these are only suggestions. Conversation systems are very much a matter of taste, and there are plenty of people who like the exact opposite of what I do. Also, the conversation system that's best for a given game depends a lot on the nature of the game, so my one-size-fits-all advice has to be adjusted accordingly. And most importantly, no one's actually figured out how to build a perfect conversation system yet, so the last thing I'd want to do is stop people from trying new ideas - some of my suggestions borrow from pretty recent games, so I don't think we've come near to exhausting the possibilities yet. If you have a scheme of your own that don't fit any of the established patterns, and you think it has advantages over the existing systems, then by all means ignore my recommendations and show us a better way.

So, on to my recommendations.

Much as I like the way menus can create the sense of a real conversation, I'd recommend against using the sort of menus that graphical games use. An enumeration of options is just not a good fit to the look or the feel of a text game. The text IF user interface demands something that can be rendered in the narrator's voice, and something that at least feels more open-ended. The menu-less TALK TO is really a degenerate case of menus, so I'd recommend against it as well. I'd also stay well away from "cheap AI" systems, since they don't fool anyone, and don't have much to recommend them apart from the false promise of fooling players.

What this leaves us with is ASK/TELL. Despite the drawbacks, ASK/TELL is what I'd recommend - but with a few differences from the conventional system.

### Use full exchanges

First, I recommend rendering each ASK/TELL as a full exchange, with both the player character's question and the NPC's answer explicitly stated. The traditional ASK/TELL system looks like this:

      >ask bob about antenna
      "I climbed it once.  It's pretty scary up there."

Instead, I'd render the exchange like this:

      >ask bob about antenna
      "Have you been to the antenna?" you ask.

      "I climbed it once," Bob says.  "It's pretty scary up there.
      Great view of the city, though."

It's a subtle difference, but an important one. The traditional style elides the player character's actual words, showing only the NPC's response. This is in keeping with the traditional view that the player character is literally the player, in which case the player character's actual words have to be left unsaid, since we can't pretend to know the exact words the player means to say. In the more modern view, the player character is distinct from the player and should have a well-defined personality. Conversation is a great opportunity to flesh out this characterization. What's more, with a player character who's distinct from the player, it's incongruous not to show the character's half of the conversation, since that implies that the character's words are literally "ask bob about antenna," or perhaps just "Antenna?"

### Use hellos and goodbyes

I would consider giving some conversations a beginning and an end. This doesn't mean that you have to create a complex protocol that players have to follow; instead, it means that your NPCs treat "conversing with player" as a separate state, and add appropriate remarks when switching to and from this conversation state. Here's the effect I have in mind:

      >ask bob about antenna
      "Excuse me..."

      Bob looks up from his ledger and takes off his glasses.  "Yes?"

      "Have you been to the antenna?" you ask.

      "I climbed it once," Bob says.  "It's pretty scary up there.
      Great view of the city, though."

      >ask about view
      "What could you see from the antenna?"

      "Well," Bob says, "I remember being able to see all the way out
      to the lighthouse."

      >east
      Bob turns his attention back to his ledger.

      Main Street
      The street is deserted, as usual for these days. [...]

### Use "threading"

Even with ASK/TELL, we could provide some simple "threading" in certain cases - that is, we can recognize obvious follow-up questions, such as the ASK ABOUT VIEW in the example above. It's impractical to do this to the extent you would in a menu system, but it's still possible to do some of the time. The trick is to recognize cases where a subject thread is so strong that the player will just naturally follow it. Remember: the player is talking to the NPC because they want some specific information, which you've set them up to want in the first place through the goals you created for the player. An NPC response to one question can raise a new question in such a way that the player will naturally want to ask it: "I don't know about the idol, but I heard an interesting rumor about your friend Dr. Philips"; or, "the idol is in the Chamber of Dung Beetles," and then "They say you need the Scroll of Tuht-Ro to get into the Chamber." You don't need bright blue hyperlinked text to guess what to ASK ABOUT next in responses like these.

A warning about threaded conversations is in order, though: don't overuse them, and don't use these conversation "branches" to hide critical information. The "menu maze" effect is highly undesirable - and a maze of free-form ASK/TELLs would be far worse than a maze of multiple-choice menu entries. Conversations are best used, I think, for characterization and plot development; they're not a great place to put puzzles, because they're too prone to becoming guess-the-noun puzzles. Adding puzzles that depend on correct navigation of branching conversations would exponentially compound this problem by creating guess-the-series-of-nouns puzzles; this would be almost unthinkably awful.

### Use a "topic inventory"

If guess-the-noun and guess-the-series-of-nouns puzzles are bad, how do we avoid them without dropping the whole ASK/TELL approach? One simple way is to avoid using conversation as a source of puzzles; this way, if players miss a few topics or a few thread paths, it won't prevent them from advancing in the game. Another approach is to provide some guidance. Menus are one way to provide guidance, but I've explained why I don't think they're quite right for text games. As an alternative to menus, I suggest something I call "topic inventory."

The topic inventory is essentially a list of suggested topics for ASK or TELL commands. It's not an exhaustive list of possible topics; it's just a list of topics that the player character is interested in knowing about. Some might object that this is presumptuous: how would the game know what the player is curious about? But that's not it at all: if the player character is distinct from the player, then it's the player character to whom we're attributing the curiosity.

In concrete terms, the topic inventory might be presented like this:

      >talk to bob
      "Excuse me..."

      Bob looks up from his ledger and takes off his glasses.  "Yes?"

      (You could ask about the antenna, or tell him about the lighthouse
      or the giant rat.)

      >tell about lighthouse
      "I was in the lighthouse earlier today," you start.

      Bob becomes quite flustered.  "What are you talking about?  That
      thing was torn down years ago, after the... troubles."

      >topics
      (You could ask about the antenna, or the troubles, or tell him
      about the giant rat.)

This is the least tested of my suggested extensions to the traditional ASK/TELL system, and you might have some reservations about it. I'll try to address a few of the potential drawbacks.

Wouldn't a topic inventory eliminate the challenge, like menus? Maybe, but probably not. Unlike menus, the topic inventory doesn't promise to be complete; it only lists suggested topics, not every possible topic. The author gets to decide what to suggest, so if a suggestion is too leading, the author can leave it out. Further, the library won't show the topics automatically on every turn the way menus are; the topic inventory will be displayed only when the game's author decides to show it for some reason, or the user explicitly asks for it.

In addition, there's a deeper game-design reason why a topic inventory shouldn't harm the challenge: guessing the magic topic shouldn't have been a source of challenge in the first place. Guess-the-topic puzzles are just as bad as guess-the-verb puzzles. In this sense, the topic inventory is a useful design tool: if you resist revealing a topic in the inventory because it would give away too much, you have to ask yourself if it was such a good idea to put such a big revelation into the topic in the first place. In these cases, maybe you can find a way to add more conversation topics that eventually lead the player to the big revelation topic; this way the player still has to dig a bit to find the magic topic, but there's a way to find it other than pure guesswork.

From the author's perspective, I think the reduction in topic obscurity will be more beneficial than harmful. Any dilution of puzzle difficulty could be more than offset by an increase in conversational range. With a conventional ASK/TELL system, authors have to be careful not to put too much information in conversations, lest players become frustrated by guess-the-noun puzzles. With a topic inventory, authors would be free to include topics that are much more subtle, knowing that players will be able to find them.

From the player's perspective, the topic inventory could be viewed almost as mild hints. For the most part, the game won't suggest topics except when asked to, so a hard-core puzzle solver could always bypass the topic suggestions.

Won't players just type TOPICS at every turn? Again, maybe but probably not. First, if there are a few things in one topic inventory list, players will probably at least try each of those before asking again. Second, topics usually won't come and go at every juncture; even in the densest menu system, the majority of branches will be dead ends, since this is the only way that the otherwise exponential growth of the tree can be contained. Players who do start typing TOPICS at every prompt will usually find this behavior unrewarded, and they'll quickly stop bothering. Third, even when one topic does lead to another that leads to another, if the game is decently written, the chain of questions will be implied in the responses anyway. Typing TOPICS again when another topic is clearly implied in the response is wasted effort that players will naturally bypass.

It remains to be seen until we get more experience with this scheme, but I expect that players will only ask for TOPICS once in a while, when they're stuck. As long as they're making progress, they won't feel the need to ask for a topic list, and the overhead (however small) of typing the extra command will serve as a natural barrier to overuse.

There's one important game design implication to keep in mind, though. If the player ever discovers that typing TOPICS at one crucial moment would have solved a puzzle, but failing to do so resulted in a missed opportunity, then the player will become very annoyed and will start typing TOPICS at every prompt. This is a matter of trust. The TOPICS command can't be used a substitute for proper hinting, and it can't be the sole way for the player to learn about a topic. Every time a player looks at a topic inventory list, the player should recognize everything on the list - the reaction should always be "oh, of course," never "where the heck did that come from?"

If you're creating a conversation where there are special things the player can say in the context of certain points in the conversation, the game should flat out tell the player about these special things. Here's an example:

      >ask about troubles
      "What 'troubles' are you talking about?"

      Bob turns his back on you and pretends to go back to his sweeping,
      obviously very agitated.

      (You could ask about the troubles again, or tell him about the
      newspaper article.)

      >tell about article
      You lower your voice.  "I found a newspaper article from 1967 about
      the murder trial.  I saw you in the photo of the jury."

This works toward developing the trust we need from the player. If the player comes to expect us to offer a topic list at these special junctures, they'll trust us not to sneak in special junctures without the listings.

### Let NPCs drive once in a while

One of the many strange things about ASK/TELL conversations is the almost invariably passive role of the NPC. Seemingly their only role is to sit there and wait for the player to ask them something. Using actor states and hello/goodbye protocols can help reduce this effect, but even with these enhancements, ASK/TELL conversations are still too obviously one-sided interrogations. So, why not let the NPC drive once in a while?

The biggest obstacle to letting the NPC take charge is that the player's expressive range is so limited. But it's not completely empty: we can answer yes-or-no questions, and we can TELL ABOUT topics. We can also GIVE and SHOW things to the NPC.

Beyond these standard options, we could use the topic inventory to provide non-standard options for individual interactions. So, you could occasionally add special, one-time-only commands (AGREE, DISAGREE, LAUGH, APOLOGIZE, or anything else you want), and let the player know when these are available via a topic inventory. The important thing to realize is that these would not be new commands that the player could use at any time; they'd essentially just be menu choices, each one working only at its proper moment. They wouldn't be guesswork for the player, since we'd show the topic inventory to let the player know about the special options.

As with any conversational threading, letting the NPC ask questions requires a certain delicacy. In particular, you have to be sure that it's very clear to the player that they're meant to respond. Make sure it's clear that the NPC's question isn't rhetorical. Offering a topic inventory is a good way to make this more obvious.

### Provide good default responses

When it comes to responding to ASK topics, the more your NPCs can handle, the better. But you'll never be able to think of everything, no matter how hard you try or how many beta-testers you have. This is an area where the vast creativity and power of the human mind work against you - the problem being the vast creativity and power of your players' minds. The fact is that players are going to think of things to ASK and TELL about - lots and lots of things - that would never have occurred to you. And even if you put in responses to all of those things, other players will think of even more things.

When a player enters an ASK or TELL command about a topic you haven't anticipated, they're going to get what's known as a "default response." That's the fall-back, general-purpose response your character uses when you haven't programmed anything specific for the topic. There are two important facts about default messages:

- The player is going to see them many times.
- The player is going to see them in response to topics that seem perfectly logical to the player.

A lot of people think that that first item can be changed by sufficient application of virtuous effort. It usually can't. Virtuous effort can reduce the number of times a player will see default messages, but in a game of any real size, it's darn near impossible to reduce it below "many." The problem is that, at some point in almost any game, the player will get stuck, and one of the ways they'll try to get unstuck is to ask each NPC about everything they can think of.

The second item is a bit more subtle. There's a corollary to the virtuous effort postulate: if you've covered all of the reasonable questions, then clearly, any questions you haven't covered are unreasonable. But covering all of the reasonable questions isn't a practical possibility, in my view, so there will inevitably be topics that seem perfectly reasonable to the player but that aren't covered.

These two facts imply two properties that default messages should have.

First, the defaults should have some variety. If the player is going to see default messages repeatedly, then at least you can make them a little less boring, and a little less obviously mechanical, by providing more than one. This is especially important for those times when the player is hammering away at an NPC trying to find the magic ASK ABOUT phrase that turns up some interesting information, because the player will likely see the default response several times in a row at these times. A simple but effective trick is to define three or four responses (or even more, for an important NPC), and select one randomly each time a response is needed.

Second, the defaults shouldn't suggest that the NPC doesn't know about the topic. The problem with saying "I don't know about that" is that it's likely to obvious nonsense. For example, players might ask about something completely off the wall in terms of the game but completely logical in terms of real people; they might ASK ABOUT HIS MOTHER or ASK ABOUT HIGH SCHOOL or something else that's irrelevant to the game but is perfectly relevant to the NPC in a broader cultural context. "I don't know about that" just doesn't make any sense in these cases.

There's a third important property for default responses: the messages shouldn't mislead the player into thinking that the absence of a useful reply is itself a puzzle. This property isn't a consequence of the frequency of use of these responses, but rather is a matter of good game design. Players are prone to interpreting any obstacle in the game as a puzzle, so you have to be careful not to make the NPC's response look like an obstacle. Using a "topic inventory" as described earlier can be a great help here - by giving the player a few topics for which the NPC does respond, you'll show the player immediately that the NPC isn't completely unresponsive, which will guide the player away from thinking that the NPC's help depends on solving a puzzle.

It's hard to provide a good response in general that conveys "I am not programmed to respond in that area" without sounding like "I am not programmed to respond in that area," and without sounding stupid in cases like ASK ABOUT HIS MOTHER. That's why the library uses the rather bland "There's no response." Depending on the character, you could use a slightly more informative response like "I don't have anything interesting to tell you about that" or "I'd rather not talk about that," but these responses run almost the same risk of sounding ridiculous as "I don't know about that" for some topics.

My recommendation is to use unresponsiveness rather than cluelessness, and to use something that's appropriate to the character. If the character is preoccupied with something, say that the character is too lost in thought or too busy fiddling with something to respond. If the character is hostile, have it just glare, or hurl an insult, or refuse to answer out of sheer orneriness. Used this way, default responses can be a good opportunity to flesh out a character, so at least they're not a complete waste for the player.

TADS 3 Technical Manual
Table of Contents | TADS 3 In Depth > Creating Dynamic Characters > Choosing a Conversation System
Prev: Creating Dynamic Characters Next: Programming Conversations with NPCs