Author: emshortif

[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 the issue.]

The convention that characters should greet one another before launching into other discussion is now pretty well established in realistically conversational IF; for Inform, Eric Eve’s Conversation Framework extension provides this functionality and I’m planning to use something compatible with his work.

There’s no reason, however, why the player should always get to dictate when a conversation begins and ends. Alabaster is not a very good demonstration of conversation beginnings and endings because there are relatively few transitions, but consider, say, Blue Lacuna: other characters move around, begin and end conversations, and generally behave as full partners in talky scenes.

In Inform 7, I rely a lot on the scene mechanism to manage conversations, because they allow me to write natural lead-ins and lead-outs, to set up lists of planned conversation in rules like “when heist planning begins”, and to set complicated conditions for when a scene should end. The conversation system also has a feature that allows quips to be set only to occur within a specific scene, which is a good way to protect against accidentally out-of-context remarks.

Continue reading “Modeling conversation flow: beginnings and endings using scenes”

[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 the issue.]

If we have an NPC with a long list of things to say, and the player types WAIT or LISTEN rather than selecting any of the possible responses, we might want the character to comment:

“Next, you’ll need to approach the farmhouse from the northwest under cover of darkness. Wolf-cub should already have cut the telephone wires and the electricity, but you’ll still need to be stealthy: they may be armed.”

You could ask whether the enemy will have snipers.

>LISTEN
You listen.

“Then… [stuff]”

>LISTEN
You continue to attend to The Fang’s briefing.

“Next you’ll… [more stuff]”

>Z
The Fang seems to be done.

“You catch all that, Snakemouth? You know I don’t like it when operatives have no questions. It worries me.”

>SMILE
You smile serenely. The Fang mutters something rude under his breath, but it looks like he’s going to let you break for lunch at last.

One simple approach is to keep a counter that resets every time the player speaks, and increments every time the NPC does; thus if the counter hits (say) four, that means the NPC has talked for four turns without any reply, and we can use that information to plan an immediate optional question about why the protagonist is being silent.

[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 the issue.]

Giving and showing.

In addition to ASK and TELL, many IF games retain the convention that the player can give or show objects to other characters. Though these are not strictly conversational actions — that is, you can give or show an object without opening your mouth — they involve communication, and therefore we may want to have the NPC’s reactions be affected by the other conversational context that’s going on. Besides, we may often want ASK BOB ABOUT DAGGER to gain the same response to SHOW DAGGER TO BOB, if the point is to get Bob to reveal some specific bit of information about the object.

My preferred way to do this is to have quips to represent what Bob says about the dagger, and then redirect SHOW DAGGER TO BOB to an available quip that mentions the dagger. That means that we can write follow-up questions about the object, cue follow-up comments for Bob, and otherwise track the exchange just as though it were part of the standard conversational structure.

Continue reading “Modeling conversation flow: actions in conversational context”

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