Category: Conversation modeling

[This is part of a series of discussions on the craft of modeling conversation, in particular using the conversation system I’m developing for Inform 7. 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, interruptions, and NPCs who repeat information.]

We’ve looked at the player asking the NPC questions, but that’s only part of the story: we’d also like the NPC to be able to ask the protagonist questions and remember the answers; pester the protagonist for an answer if one is not given; and refuse to move to new topics.

The basic set-up is straightforward: we give the NPC a quip posing a question. We represent the answer with quips that directly follow the question quip, which means that at most one of them can be used and that they will only be understood if the player hasn’t talked about something else instead.

The first thing we need to decide is whether the player will be allowed to change the subject without answering, or whether we want him to be forced to give one of the available responses before moving on to other topics.

Continue reading “Modeling conversation flow: NPC questions”

[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.

[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 and subject changes, and transitions in player speech.]

There’s a hacky moment in Alabaster to do with interruptions.

During one of the first moves of the game, you can ask Snow White about something while she’s waiting for an answer about whether you’re going to escort her to the forest. So, if you talk about something else instead, she gets angry and interrupts. In the first implementation, she waited for the subject-changing hook to object; but I didn’t like the effect of that, so I decided to have her actually interrupt the speech in progress. Whatever the player is saying, after the first few words, she’ll leap in: this is done by dumping the quip content to indexed text and running a regular expression to automatically detect a safe break-in point. This happens regardless of which question you’ve asked her (and there are dozens of possibilities). For instance:

“Why do you –”

She sets her jaw as she realizes you are changing the subject.

“–avoid the Queen’s mirror? Many of us have stood before it, and taken no harm.”

If you asked this under any other circumstance, this question would just print as “Why do you avoid the Queen’s mirror? …” without interference.

The strength of this is that it let me introduce this feature across dozens of possible quips the player might say here, without having to edit the quips themselves. As this sample demonstrates, though, the weakness is that the algorithm for producing break-in points is pretty basic. Here we have Snow White looking irritated before the gist of the player’s comment is really clear at all.

Still, sometimes it works a lot better, and I found that it was still more interesting than using the subject-changing hook to show her anger in this particular context, so I left it as it was.

Continue reading “Modeling conversation flow: interrupting the player”

[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 and subject changes.]

One of the issues that has already appeared several times in these posts is the idea of the transition: how do we produce smooth, plausible segues from one bit of speech to another?

In the present model, the NPC’s responses are generally written to go with the player comment that led into them, and we’ve already looked a little at the way the system creates transition text when the NPC wants to introduce a new topic of conversation.

The remaining area of concern is the transition from whatever the NPC last said to the player’s next comment, which appears at a turn break:

PC comments
NPC replies
> (player’s command)
PC comments again
NPC replies

Continue reading “Modeling conversation flow: transitions in player speech”

[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 my blog post on NPC initiative, which describes how NPCs might manage a list of things to say in the future.]

Alabaster has a threaded conversation system, which is my way of saying that it keeps track of which quips follow naturally from which others. That’s important because it allows the game to prompt the player with the quips that he’s most likely to want to use next (and, even if such hinting is turned off, to parse input more intelligently).

Responses to the player.

Thanks to its awareness of threads, the Alabaster system allows for a hook, the subject-changing activity, which comes between the PC’s comment and the NPC’s reply. For reference, the full sequence for handling a conversation action looks like this:

1. PC’s comment (which can be multiple paragraphs, but usually isn’t)
2a. NPC challenges a change of subject, if relevant (SUBJECT-CHANGING HOOK)
2b. NPC’s response (which can be multiple paragraphs, but usually isn’t)
3. (If step 4 is going to happen) A grounding beat is produced to mark a pause in the conversation, to pave the way for
4. (Optionally) If the current conversation thread is at an end, and if the NPC has something else planned to say, he now starts a new conversation thread by saying the next thing on his list.

In transcript, that might look like this:

>ASK LUCY ABOUT DIAMONDS
(1) “Are diamonds your favorite gem, Lucy?”

(2a) She looks surprised by this question. (2b) “Yes, ever since I was a child.”

(3) Overhead the seagulls wheel and cry.

(4) “I do wonder what my mother did with the family rubies. They were missing when she died,” Lucy says.

And for a non-conversation option:

1. PC’s action is handled however is appropriate.
2. (Optionally) If the NPC has something else planned to say, he now starts a new conversation thread by saying the next thing on his list.

which would produce a transcript like this:

>EXAMINE DIAMONDS
(1) They glitter at you malevolently.

(2) “I do wonder what my mother did with the family rubies. They were missing when she died,” Lucy says.

Continue reading “Modeling conversation flow: subject changes”

In Galatea, one of the things I wanted to do, but managed very badly, was to have Galatea continue the conversation herself if you stopped to listen to her rather than talking. But the number of such things she had to say was pretty sparse, so it wasn’t worth stopping to wait after every turn, and there wasn’t always any clear sign when she was likely to continue. Moreover, the mechanism for this was very hacky and didn’t allow her to have more than one thing planned to say at a time.

Alabaster does this much better. Instead of having the NPC’s speech be part of the player’s action, the NPC actually has a separate action in which he speaks, and he has a list of quips to say next. He will go on saying things from this list if the player is silent, or if the current conversation thread has come to an end and it’s time to change the subject to keep conversation flowing. (Galatea has no model of when conversation threads have ended, either.)

New quips added to the list have two kinds of priority. They can be marked either “obligatory” or “optional”, and either “immediate” or “postponed”. Obligatory quips are things the NPC definitely means to say sooner or later, even if the player interrupts with some other comments first; optional quips are things he might say, but is equally happy to skip if the conversation moves in another direction instead. Similarly, “immediate” means he’ll say this next even if there are other things on the list — it goes in at first position — while “postponed” means the quip should instead go at the end of the list.

Between them, these cover a number of different ways an NPC could want to go on with the conversation:

Continue reading “Modeling conversation flow: types of NPC Initiative”