Modeling conversation flow: NPC repeating information

[This is part of a series of discussions on the craft of modeling conversation. For previous installments, see my original Homer in Silicon article which lays out the basic elements of the model, and previous blog posts on NPC initiative, subject changes, transitions in player speech, and interruptions.]

One of the standard objections to early versions of ASK-TELL IF conversation was that NPCs would go on repeating themselves verbatim every time you asked the same question. On the other hand, having the NPC refuse to answer a question more than once meant that the player might lose access to game-important information that he might not have noticed or understood the first time he read it. This point has been hashed over a lot and solved in various ways over the years, and I discuss some of the most-used solutions in my longer article on conversation approaches in IF in general. An increasingly common solution in modern IF is to have the protagonist refuse to re-answer the question but simply remember what was said last time if he tries, so

>ASK WHEELER ABOUT SNOW

might result in

Weatherman Wheeler already told you that he expects eight inches of snowfall in the next two days.

That neatly preserves the player’s knowledge while avoiding the conversational problems.

In the Alabaster conversation model, the player is allowed to THINK to review the facts he’s already learned, which is another way to approach retention of knowledge once a one-use quip has been used up. It would be possible to arrange things so that the Alabaster model produced the same results as in the first example, too. The attractiveness of that approach would probably depend a lot on whether there were many quips per subject, as there are in Alabaster [in which case the player would often be invited to disambiguate among some quips that he’d already asked as well as the ones currently available], or very few, as there might be in a more exploratory game.

But the other thing that Alabaster does is let the player repeatedly request information about certain common topics, and the NPC’s response is generated from several random elements to piece together a reply that will not be the same each time, but will always contain roughly the same set of facts if there’s anything important there. In fact, Alabaster glues together various clauses semi-randomly so that the cadence of the generated text will also vary from time to time. (The code is here.) If the player has asked the same question many times, the NPC will notice and remark on the repetition, as one might expect. (Indeed, allowing the player to annoy the NPC is probably the main reason to implement repeated questioning at all, rather than relying solely on a knowledge system to remind the player of questions already asked.)

Alabaster’s system isn’t terribly sophisticated because, in fact, most of this information is local color, not hugely important, and because in testing players spent relatively little of their time asking these generic questions when there were more specific, conversation-advancing things to say.

In a different game, it might be better to handle the problem using facts.

A fact is a part of the conversation model by default: a fact can be known or unknown by each of the characters (including the player). The player can learn facts from conversation, but also from the surrounding world (say by reading a letter or seeing a clue): any time text is printed to the screen that contains a fact-name as a tag (like [bob-killed-harry]), the player is marked as knowing that fact. NPCs also know facts that are conveyed in the text of conversations that they were present to hear, even if they are not participants in said conversation.

So most of the time, the implementation is that the author writes the text in whatever form he likes and then marks up that text to indicate what factual data it contains. This sounds daunting, but in practice the number of facts worth modeling is usually much much lower than the number of quips; you only model the information that’s going to affect gameplay.

But I can imagine an alternate way of writing a repeatable quip would be to give that quip a property containing a list of facts to be conveyed. Each fact would have several phrases that this particular NPC might use to convey such information; and then the system would stitch together the phrases into a paragraph in the same way that Alabaster does.

One advantage to this is that it would be possible to have the NPC automatically filter the list so as not to repeat facts that were just recently stated in conversation, or indeed only to repeat the facts that were already known. Thus the summary response to “TELL ME ABOUT BOB” would get longer as more and more information about Bob was introduced elsewhere in the dialogue, but this summary quip would never give away information that was meant to be broached first elsewhere.