NOTE: This extension depends upon the extension Conversation Framework by Eric Eve. The latest version should be available for download from the Inform website.

Chapter 1: What's new in Version 8

Rewrote documentation explaining weakly-phrased quips to emphasize they are only for use with queued quips

Chapter 2: What's new in Version 5

The only change authors should need to make for their old games to be compatible with this version is to replace all instances of the word "response" with "reply". I apologize, but 6L02 introduced a lot of new syntax, and 'responses' are a new central feature of the language. Otherwise:

Compatibility with I7 6L02 (and 6L38)
Responses made adaptive
Cleaned up extensions, main code

Chapter 3: Introduction to Conversation in Interactive Fiction

Section 3.1: The challenge of context

Traditionally, conversation is one of the more difficult things to program in interactive fiction: while it's acceptable for >EXAMINE POT to produce the same reply every time the player types it, it's a bit less acceptable for >ASK JOE ABOUT HIS ADULTERY to make Joe react the same way every time. Conversation implementations often need to keep track of a lot of information: what else is going on in the model world, what the character knows, what plot phase we've reached, what mood the character is in, what else we've recently been talking about, whether we've said the same thing before (and how many times); and so on.

Threaded Conversation provides ways to keep track of conversation context: the person we're talking to, what he knows, what we've said to him most recently, what we've said to him in the more distant past.

TC also makes some abstract calculations -- based on the structure of the conversation we've designed -- about whether a new comment or question relates to the things we were already talking about, or whether they constitute a change of subject.

This contextual information means that TC can have the parser sensibly guess which of several things the player wants to say, based on the current state of the conversation; let the player review what he already knows and which things he's already said during the course of the game; and give the player clues about what he might want to say next.

It also gives us the means to implement some special effects easily:

- vary the exact text of conversation, depending on the mood that the character is in
- block off certain topics of conversation until a certain point in the plot
- have a character get distracted and refuse to answer questions some of the time
- have characters ask questions that the player must answer before moving on
- give a character things to say when the player stops moving the conversation forward
- have a character react when the player changes the subject
- allow a character to draw conclusions from the facts that have come up in conversation

Section 3.2: Types of interface; ASK/TELL, menus, and hybrid systems

Another challenge of conversation design is creating an interface that is both easy for the player to use and expressive enough to be interesting. Two common approaches are ASK/TELL conversation, where the player can ask or tell characters about keywords, as in

>ask Jill about Jack
>tell farmer about chicken coop

and menu-based conversation, where the player is offered a list of things to say and must pick one (often by number), as in

1) Ask Jill where Jack went.
2) Tell Jill that the chicken coop was robbed.

or, sometimes,

1) "Jill, have you seen your no-good layabout brother Jack anywhere?"
2) "Look, Farmer Jill, I think a fox got into the chickens."

The problem with ASK/TELL conversation is that it can feel undirected -- if the player doesn't know which keywords to ask or tell about next, he gets stuck. It also doesn't always provide much sense of ongoing context or conversational flow, since the player can ask lots of unrelated questions and jump around a lot. What's more, sometimes the thing the player character asks isn't quite the question the player had in mind. If we type

>ask Jill about Jack

Jill could wind up answering any of a number of questions -- where Jack is, how old Jack is, whether Jack committed the recent murder, and so on. The player doesn't have much fine control over the conversation.

Menu-based conversation solves most of these problems, but introduces another: it doesn't allow for very many surprises. The player can see all the conversation the game has to offer by working methodically through all the menu branches. (This problem is sometimes referred to as the "lawnmower effect", since the process of seeing all the conversation is like the process of running a lawnmower over every inch of the lawn.)

Since about 2001, more and more IF has used a sort of compromise method: the player is allowed to ask or tell about keywords, but he's sometimes given prompts about things to say that follow naturally on the conversation he was just having, as in

You could ask where Jack is.

Moreover, when he asks about a topic where many comments are possible, he'll be allowed to clarify, as in

>ask Jill about Jack
Do you want to ask where Jack is, how old Jack is, or whether Jack committed the recent murder?

There are quite a few minor variations in how these options are presented; for instance, sometimes the player is given a menu of options after selecting his keyword, rather than a disambiguation question as shown. Nonetheless, the basic structure remains the same: there are keywords to talk about, but there are multiple things to say about each keyword (for greater expressiveness) and the player is guided (but not forced) into a conversation structure that flows naturally.

Threaded Conversation supports this kind of conversation interface, though there are also ways to alter its output to produce something closer to bare ASK/TELL or a menu system.

Section 3.3: Writing a conversation with Threaded Conversation

We start writing a conversation with Threaded Conversation by writing a number of quip objects. A quip is a thing which represents both halves of an exchange with a character: what the player says, and what the other character says back. For example, a rudimentary quip might look something like

whether the moon is made of green cheese is a questioning quip.
The comment is "'Do you think the moon is really made of cheese?' you ask.".
The reply is "'Of course!' exclaims [the current interlocutor].".

This isn't quite complete, though, because we need to tell Inform what keywords to associate this quip with. For this, we use the "mentions" relation:

whether the moon's made of green cheese is a questioning quip.
It mentions the moon, cheese.
The comment is "'Do you think the moon is really made of cheese?' you ask.".
The reply is "'Of course!' exclaims [the current interlocutor].".

Now we've established that the quip has to do with the moon and cheese objects elsewhere in the game. If the moon and the cheese are not represented physically in the game at all, we can make them abstract subjects, as in

The moon is a subject.

Now if the player types

>ASK ABOUT THE MOON

Threaded Conversation looks at its available quips that have to do with the moon, or have "moon" in their name, and picks the most relevant one (or asks the player which he'd like to use).

>ASK ABOUT CHEESE

would turn up this same quip, but probably not any other quips that we might have written about the moon. The player can also be more specific; in this case, he could type

>ASK WHETHER THE MOON'S MADE OF GREEN CHEESE

and make sure he gets this question rather than any other.

When we have some quips written, we add a bunch of rules about which quips the player may say under which circumstances. For instance, we may very often want to restrict quips to conditions such as

- the player is talking to a specific person
- the player has recently said another quip, and is now following up on it
- the player has learned a particular fact
- the player has never said this quip before
- a particular scene is in progress

... and so on. Threaded Conversation provides shortcuts for writing many of the most common restrictions we might want to put into a conversation, but it also allows us to write our own, arbitrarily complex rules about when the player can say what.

This may be a good time to play with the first example below, labeled "Very Simple", which shows some quips in action and demonstrates what the default output of Threaded Conversation looks like.

Section 3.4: Using this extension efficiently

One of the essential features of detailed character conversation is that one has to generate quite a large amount of text to arrive at remotely interesting or convincing results. To that end, the extension Conversation Builder provides some auto-code-generation facilities, producing source that compiles alongside the material provided in this extension.

A reasonable way to learn Threaded Conversation would be to read through the Basic Structure and Concepts chapter, looking at the recommended examples along the way; then to try building on these with Conversation Builder; and only coming back to study the advanced features once familiar with the basic mechanisms.

Section 3.5: Related extensions

It may be fruitful to include Mood Variations by Emily Short: Mood Variations allows us to tag text alternatives so that the correct alternative will be chosen depending on the mood of the current interlocutor; it also has a "[set mood]" token that can be used to mark up quips to reflect the mood of the listener. The same things can be achieved in other ways more laboriously, but this shortcut may prove handy.

Chapter 4: Basic Structure and Concepts

Section 4.1: Quips

As we saw above, most important components of a conversation system built with TC are quips. Quips come in three kinds, the informative, the questioning, and the performative, depending on whether they are associated with TELL commands, with ASK commands, or stand on their own. A plausible quip of each kind:

Lily looks well is an informative quip.
The comment is "'You look very well, Lily,' you say, winking.".
The reply is "'Why, thank you!' Lily replies.".

whether it will rain is a questioning quip.
The comment is "'What do you think of the weather?' you ask. 'Will it rain?'"
The reply is "'I really don't know,' says [the current interlocutor]."

curse the fates is a performative quip.
The comment is "Drawing on your prodigious knowledge of ancient norse profanities, you express your feelings about the whole cast of the universe that brought your life to this point."
The reply is "The turtle does not reply."

Notice that quips should always be proper named, without an article preceding. Declaring "A silly digression is an informative quip" (for example) will result in the quip's name being improperly displayed during play.

Note also that the name of the quip should be something that could sensibly follow "say" (for an informative quip) or "ask" (for a questioning quip), or, in the case of the performative quip, stand on its own as a unique command:

>say lily looks well
>ask whether it will rain
>curse the fates

If we want to ASK LILY ABOUT WEATHER, though, we'll also need the mentioning relation.

Section 4.2: The mentioning relation; subjects

Threaded Conversation defines a "mentioning" relation:

mentioning relates various quips to various things.

A quip can mention one or more characters, props, or abstract subjects of conversation. Though it's not absolutely required, it is usually most convenient to explicitly make such abstract subjects belong to the "subject" kind, as in

The weather is a subject. Understand "rain" or "sun" or "sunshine" or "clouds" or "cloudy" or "storms" as the weather.

Then, we could write

whether it will rain is a questioning quip.
It mentions the weather.
The comment is "'What do you make of the weather?' you ask. 'Will it rain?'"
The reply is "'I really don't know,' says [the current interlocutor].'"

And now (assuming that the quip is otherwise an appropriate thing to say at this juncture) the player can invoke this quip with any of

>ask fred about the weather
>ask fred about rain
>ask fred about storms
>ask whether it will rain
>a clouds

Making quips mention the objects they refer to means that all the alternative names of those objects will be recognized as ways to invoke the quip -- so we don't have to write lots of extra Understand rules for every quip we write about the weather.

Ensuring quips are well-stocked with all the appropriate nouns is also a courtesy to the player. It can provide redundancy in synonyms, helping prevent gaps in defining quips themeselves. Mentioning topics also allows players to reference quips by various topics they only tangentially reference: with appropriate subjects defined, for example, the quip "which artist might recieve royal favor" could be invoked (besides with any of the words constituting the name) by the player asking about 'the Queen', 'patronage', or 'art'.

Section 4.3: Directly-following and indirectly-following; restrictive quips and nags; the immediately condition

Quite frequently, the player will fall into a chain of conversation where each quip naturally follows on from the one previous; there may be opportunities for the conversation to split a bit, or for the player to go back and pick up a topic from earlier in this same thread of conversation.

TC defines two kinds of threading relations for controlling which quips are available to the player at any given moment. A quip may be defined to directly-follow another quip, meaning it is available and suggested to the player *only* immediately after that quip; or to indirectly-follow another quip, which means that it becomes available for discussion at *any* time after the quip it follows. Note that a quip may follow or be followed by -- directly or indirectly -- any number of quips.

We generally want to use "indirectly-follows" when one quip pursues a line of thought introduced in another. We are more likely to want "directly-follows" if, for example, one quip answers a question asked in another, so that the follow-up would make no sense unless spoken in reply, immediately after the first, with no conversation intervening.

Often, when writing an indirectly-following quip, we want to vary the text depending on whether this quip has been chosen as soon as it was made available, or after some other topics of conversation have intervened. This is when the condition "immediately" proves useful: it is true when the current quip indirectly-follows the most recently discussed quip. For example:

how to find the castle is a questioning quip. It indirectly-follows where she hath come from.
     The comment is "'[if immediately]How can I find it[otherwise]And how might I locate your castle[end if]?'"

If a character has nothing to say, the game will try the "expressing ignorance by" activity with that character. Thus, we could write

Rule for expressing ignorance by Joe:
     say "'Uh,' says Joe, scratching his head."

By default, this rule doesn't describe any behavior at all for the other character; instead, it says that the player can't come up with any appropriate comment. This allows the conversation to go on as though nothing has happened.

There are times when we want to narrow the player's choice so that he can *only* say one of a handful of things in reply to a question asked in the previous turn. If we declare a quip to be "restrictive", that means that the player's next comment in that conversation must be a quip that directly-follows it. (It would also be possible for the player simply to walk away or ignore the character at this point; if we want to prevent that as well, we must add additional rules barring movement or doing other things while the current quip is restrictive.)

A related feature of quips is the "nag". This is some text printed on a turn when the player has not said anything to the interlocutor. Since a nag usually implies that the character is insistent on hearing some kind of reply from the player, it is most often defined for restrictive quips. Only the nag of the most recent quip will be printed on any given turn.

request-help is a restrictive quip.
     The reply is "'Wilt thou accept this quest, hero?'".
     The nag is "'Thou must!'"

yes to the quest is an informative quip.
     The comment is "'Yes.'".
     The reply is "'Truly, thou art brave!'".
     It directly-follows request-help and no to the quest.

no to the quest is an informative quip.
     The comment is "'No.'".
     The reply is "'But thou must!'"
     The nag is "'Thou must!'"
     It directly-follows request-help and no to the quest.

This basic framework of linking quips using the directly- and indirectly-following relations, combined with the ability to define quips as one-time/repeatable and restrictive/unrestrictive, can provide a structure robust enough for the conversational needs of many works.

Section 4.4: Quips for one person and quips for many people; quip-supplying relation

By default, there are no limits determining to whom we may say a given quip. If we want to go all around town asking everyone we meet about a topic, we might write a quip like

how to get to Carnegie Hall is a questioning quip.
The comment is "'Do you know how to get to Carnegie Hall?' you ask [the current interlocutor]."
The reply is "[one of]'No,'[or]'Practice!'[or]'Leave me alone, weirdo,'[or]'Walk north about three blocks,'[as decreasingly likely outcomes] says [the current interlocutor]."

The use of text variations means that the reply will vary a bit from person to person as we go around asking, and sooner or later someone is likely to give us the useful advice. Obviously, we could also just have every single person who answers reply in exactly the same words, but that's likely to become dull.

More often, though, we want to write a lot of dialogue just for a single person. For this scenario, TC defines the "quip-supplying" relation -- a quip is said to quip-supply a given person if it provides that person with something to say.

Lily looks well is an informative quip.
The comment is "'You look very well, Lily,' you say, winking.".
The reply is "'Why, thank you!' Lily replies.".
It quip-supplies Lily.

Or, if we want to be able to say the same quip to several specific people in the game:

Lily looks well is an informative quip.
The comment is "'Lily is looking pretty good these days, isn't she?' you say.".
The reply is "'[if the current interlocutor admires Lily]Yeah, she's turned into a real babe[otherwise]I guess[end if],' says [the current interlocutor].".
It quip-supplies Lucas, Peter, and Fred.

This might be a good time to look at the second example, "Slightly Less Simple".

Section 4.5: Recollecting; repeatable and one-time quips

TC defines a recollecting relation. When the player says a quip to another character, that character thereafter recollects that quip; so we could write conditions such as

if Lisa recollects whether it will rain,...
if someone recollects curse the fates,...

and so on.

By default, quips are defined to be "one-time", meaning that the player can only say them once to any given character. (He might say the same quip to *different* characters, if the quip is not defined to apply to a single character only; but the same exchange of words would only happen once with each person to whom it was said.)

If we'd like to be able to say the same quip many times to the same character, we must instead make the quip "repeatable". If we do this, we may also want to take advantage of text variations to print something new the second and subsequent times he says the quip:

where the treasure lies is a repeatable questioning quip.
It mentions the Incan gold.
The comment is "'Do you know where the treasure lies, Long John?' you ask [one of]brightly[or]again[or]yet again[stopping]."
The reply is "[one of]'[or]'Ye make an 'orrible pirate. I told you already. [or]Long John merely sighs. '[stopping]It be buried under the crossed palms,' he replies."

The most common use for repeatable quips is when the player has a chance to ask a character for some really vital piece of information -- something that he might forget and need to ask again in order to solve the game. We don't want to force him to take notes while he plays, so we don't want to lock that information away after the first time he asks. On the other hand, if we want to prevent characters sounding mechanical, it's good to vary their replies when they're asked more than once (as shown above), or else have repeated replies provide a summary form, like

where the treasure lies is a repeatable questioning quip.
It mentions the Incan gold.
The comment is "'Do you know where the treasure lies, Long John?' you ask [one of]brightly[or]again[or]yet again[stopping]."
The reply is "[one of]'Aye, it be buried under the crossed palms,' he replies[or]Long John reminds you, a little impatiently, that the treasure is buried under the crossed palms[stopping]."

(For another variation on this, see the "King of Everything" example below; or to simply get a look at the behavior of repeatable quips, see "Not So Simple".)

"Recollecting" would also allow us to write actions which let the player review what he's already talked about. For instance, suppose we wanted to add a "remember" action, so that remembering any conversation topic would list the quips that we've used that apply to that subject, and with whom we've discussed them. (This might come in handy in, say, a mystery game, in which we need to make sure that we ask all the suspects certain basic questions.)

We might implement such a system like this:

Understand "remember [any subject]" or "remember [something]" as remembering. Remembering is an action applying to one visible thing.

Check remembering:
     if the number of quips which are recollected by someone is 0, say "You have not yet had any conversations to remember." instead.

Carry out remembering:
     let N be 0;
     repeat with item running through quips which mention the noun:
         if someone recollects the item:
             say "You have discussed '[the item]' with [the list of other people who recollect the item].";
             increment N;
     if N is 0, say "You haven't discussed [the noun] with anyone yet."

Definition: a person is other if he is not the player.

With only those features that have been presented so far, we could already write a game in which the player can ask various characters about a wide range of topics, follow up with further quips, and review important questions that he's already asked. But there is much more that we can do by keeping track of the context of the conversation.

Chapter 5: Advanced Features for Customizing Conversation Flow

Section 5.1: Facts

Facts are used to track abstract information that might be conveyed by one or more quips. Unlike subjects and quips, facts are not things; they're values, defined by the grandiosely-titled Table of All Known Facts. To add our own facts, we might write

Table of All Known Facts (continued)

fact	summary
footprints-found	"Size 12 footprints were found outside the library."
bob-shoe-size	"Bob's shoe size is 8."
...

Every character in the game is able to know or not know every fact. To start characters out with a base of knowledge, we might write

The player knows bob-shoe-size.

or similarly

Bob knows bob-shoe-size.

Moreover, facts don't have to be tied to quips. Characters might also find things out by seeing an event unfold in front of them:

After opening the secret door:
     now every person who can see the player knows secret-door-in-shelves;
     continue the action.

But quite often, facts will be communicated in the flow of conversation. If we want to indicate that a given quip communicates a given fact, we simply include the fact in brackets in the quip text, like so:

The reply is "Bob holds up his shoe for you to see. [bob-shoe-size]'Eight, like I told you, inspector,' he says grumpily."

Whenever someone says a quip with an embedded fact, everyone who is listening -- that is, the player, the current interlocutor, and any other characters in scope -- overhear the fact and come to know it as well. Conversely, "[forget bob-shoe-size]" will make everyone in scope stop knowing the fact any longer. (This is useful at those moments when some piece of popularly-believed information turns out to be false.)

See the example 'Conferences' for a demonstration of how other characters might respond to facts revealed during play.

TC provides a rule that will list off whatever the player knows at the moment; it is up to us to decide when and how to invoke that rule. If we wanted to let the player retrieve all his facts by thinking, we might write

Instead of thinking, follow the recap of known facts rule.

Note that there is no enforced requirement in TC that someone know a fact before they say a quip with that fact embedded in it; if we wish, it's up to us to add such availability rules closing off certain quips as needed. This is because, in practice, many games will not involve large transfers of factual information between characters; it is not worth burdening all other authors with the added complexity.

This brings us to the idea of the availability rules, which allow us to place arbitrarily complex restrictions on which quips are available under which conditions.

Section 5.2: The availability rules

The availability rules are an object-based-rulebook, consulted any time we want to decide whether something can possibly be said, no matter how likely. It has two possible outcomes: "it is available" and "it is off-limits". (If rulebooks and outcomes are unfamiliar, see the Rulebooks chapter of the Inform documentation.)

In fact, all the restrictions detailed so far in this documentation are enforced by the availability rulebook. The default set of availability rules includes these:

don't talk to no one rule
generic-quip
restriction of quips to scenes rule
player can't say NPC-directed quips rule
prevention of off-topic answers for restrictive quips rule
restriction of quips to special people rule
restriction of one-time quips rule
restriction by indirect-following rule
restriction of quips to appropriate previous quips rule
generic availability rule

The don't talk to no one rule protects against bugs (though it ideally shouldn't arise anyway) by forbidding any quips at all when there is no current interlocutor defined.

The availability rule for the generic-quip means that the (single, boring) quip defined by this extension is never available. It is useful to define this quip so that the extension will compile even when the author has not yet written any quips; but then we don't want the generic-quip to appear in any actual games.

The restriction of quips to scenes rule prevents a quip from appearing outside of the scene defined as its "proper scene". By default, this is the 'entire game'.

The player can't say NPC-directed quips rule prevents the player from accessing quips that we have defined as "NPC-directed": that is, they exist purely for other characters to bring up in conversation, not the player.

The prevention of off-topic answers... rule checks that, if the current quip is restrictive, the player is using one of the answers that directly follows it.

The restriction of quips to special people rule enforces the quip-supplying relation.

The restriction of one-time quips rule checks whether the current interlocutor recollects the quip, and if so, forbids using the quip unless it is marked as repeatable.

The restriction by indirect-following rule enforces indirect-following; the restriction of quips to appropriate previous quips enforces direct-following.

Finally, the generic availability rule is the last rule in the rulebook, and simply returns "it is available".

There are, as usual with rulebooks, numerous ways to tamper with all this. We may write our own availability rules applying only to a single quip or group of quips. For example, to offer a quip only when the player holds a vital item,

An availability rule for accuse Lily:
     if the incriminating letter is not held, it is off-limits.

... to use a quip only if the player knows a specific fact,

An availability rule for what was cost of building ark:
     if the player does not know flood-imminent, it is off-limits.

... to make a whole thread of quips -- everything following from a significant remark -- off-limits *after* the player has learned some other fact,

An availability rule for a quip which indirectly-follows how he healed Lily:
     if the player knows prince-gave-blood, it is off-limits.

... and so on. We might also selectively disable or entirely remove rules from the availability rulebook if we wish to alter the normal behavior of Threaded Conversation; see the section of the Inform documentation on listing rules explicitly.

A quip is defined to be "available" if it passes the availability rules, so we can use "an available quip" to assemble these quips in brief. This is used in the parsing rules of Threaded Conversation, which defines many of its commands in a structure such as

Understand "discuss [any available quip] with [someone]" as discussing it with.

Section 5.3: The plausibility rules

In addition to knowing which quips *can* be said at any given time, TC also keeps track of which quips are *likely* to be said at any given time. The plausibility rules are used for hinting to the player and for resolving parser ambiguities.

For instance, the player is allowed to change the subject and ask about something new that isn't part of the current thread of discussion, but at any given time, he will only be encouraged to talk about plausible quips; all his other options will not be suggested. Similarly, if the player makes an ambiguous command that could be resolved either as a quip in this thread of conversation or as something totally unrelated, the in-thread quip will be chosen.

To decide these things, TC uses the plausibility rules, another object-based-rulebook, though this time with three possible outcomes: it is plausible, it is dubious, and it is implausible. By default, the plausibility rules are

implausible to repeat yourself rule
mid-thread plausibility rule
avoid topic-change where possible rule
generic plausibility rule

The implausible to repeat yourself rule says that, even if a quip happens to be repeatable, the player is unlikely to ask the same person the same question over again.

The mid-thread plausibility rule checks whether a quip falls outside the current thread, and, if so, marks it implausible. The criteria it follows are somewhat complex, but in brief:

If the most recently discussed quip indirectly-follows other quips, we're construed to be in the middle of a thread. If not, anything goes, so we skip the rest of the criteria. But if so:

Any quip that belongs to the same thread -- that indirectly-follows one of the things we've just been talking about -- is not a change of subject. Such a quip is said to be "quippishly-relevant".

Any quip that doesn't indirectly-follow any other quips (defined as "shallowly-buried") is considered the start of its own new thread, so that's not necessarily marked as implausible, either.

But we do mark as implausible a quip that indirectly-follows other quips -- in other words, it is deep in its own thread -- but that is not part of the thread we're currently on.

The avoid topic-change where possible rule checks to see whether we're in the middle of a thread (as defined above) and whether there is more to be said following on from the current quip. If so, then "shallowly-buried" quips (quips that start their own threads) are considered to be "dubious". The idea is that we should not clue the player about how to change the subject while he's in the middle of a thread. If he does come to the end of what can be said about (for example) the weather, then it becomes reasonable to remind him of other conversation threads he might pursue.

Finally, the generic plausibility rule returns "it is plausible" for any quips that have made it this far.

The plausibility rules, like the availability rules, give us a lot of room for refinement and special casing. For example, say we have a puzzle where the player has to draw some inferences in order to ask a specific question. We want to let him ask this as soon as he thinks of it, but we don't want to suggest it to him before that point. We might then write

A plausibility rule for whether Mr Hannigan eats people:
     it is implausible.

As a result, this quip will never be suggested to the player in any "You could..." statement.

A quip is defined to be "plausible" if it passes both the availability rulebook and the plausibility rulebook, in that order. Nothing can be plausible to say that cannot be said at all; moreover, the plausibility rules are the more computation intensive of the two, since they at some points involve tracing paths through the indirectly-follows relation. It is best to perform such checks only when we must, in the interests of optimizing run-time speed.

Chapter 6: Customizing the Player Interface

As we've seen, by default, Threaded Conversation uses a conversation interface in which the player may ASK or TELL about topics of interest, but if there is more than one thing to be said on that topic, he will be asked to clarify which of several remarks he would like to make. He will also receive cues every turn about what conversation quips are particularly appropriate at this juncture. This is not our only option, however; if we wish, we can implement other forms of interaction.

Section 6.1: Switching to other forms of ask/tell or menu-based interface

This behavior can be adjusted. If we want to achieve something more like an old-style ASK/TELL interface -- that is to say, one in which there are no cues, and the player is left to pick conversation clues out of the character's speech -- we can simply turn off the rule that supplies the cues. To do this, we would write

The offer hint quips rule is not listed in any rulebook.

We could also substitute in its place a rule that offers hints only under specific conditions, or only suggests certain types of hints.

More ambitiously, we could allow the player to determine for himself which play style he prefers, as a setting of the game. If we choose to do this, we must be sure to play-test all the options carefully. Performative quip commands, in particular, are not at all likely to be obvious to players unless we offer some other way of hinting at the special phrasing required.

Section 6.2: Modifying the "you could..." line; changing the subject

On a smaller scale, we can modify the output of the offer hint quips rule on a case by case basis. TC defines the activities

listing matched quips
listing plausible quips
listing peripheral quips

Listing matched quips constructs the question Inform asks when disambiguating between several quips the player might have wanted to say.

Listing plausible quips constructs the "You could..." suggestion paragraph.

Listing peripheral quips is a rarer item that responds to the command >CHANGE THE SUBJECT, and lists those quips that start new conversation threads, if the player wants to know.

Of these, listing plausible quips is the one that most obviously lends itself to frequent use, whenever we want to direct the flow of conversation unusually.

For instance, suppose that in one unusual circumstance we actually want to discourage the player from pursuing the thread he's on -- though he can if he wants to. We might write:

Rule for listing plausible quips when lily looks well is the current quip and it was horrible finding Lily poisoned is plausible:
     say "It's on the tip of your tongue to tell her: it was horrible finding her poisoned. But you needn't. You could turn the conversation: ";
     prepare a list of peripheral quips which are not it was horrible finding Lily poisoned;
     say "[prepared list delimited in disjunctive style]. Something along those lines."

Less particularly, we might make an "unhinted" attribute identifying all the quips that we don't want to follow with conversation cues, and then write

Rule for listing plausible quips when the current quip is unhinted:
     do nothing instead.

If we just want to change the words "You could " into something else (for example, in order to change the person, tense, or narrative language of the game), we can modify the text variable quip-suggestion-phrase, like so:

When play begins:
     now the quip-suggestion-phrase is "I could ".

Chapter 7: Character Initiative and Action Queuing

Section 7.1: Overview of character actions under Threaded Conversation

So far we've talked entirely about a framework in which the player speaks and a character replies. This is not a bad system for the most part, but there are times when we want characters to be a bit more proactive.

The way the exchange of conversation currently works is as follows:

1) When the player asks a question, the player's comment is printed immediately as part of the "discussing" action, but nothing is printed for the current interlocutor.

2) Instead, we add this same quip to a list of things that the current interlocutor wants to talk about. It is queued "immediately" -- that is, it has priority over everything else in that character's queue -- so if the character was also waiting to say something, he will first reply to the player.

3) The player's discussing action finishes; then an every turn rule fires (the "active conversation rule"), triggering the conversation-reply rules. The conversation-reply rulebook has four entries by default:

the everyone speaks if queued rule
the character pursues own ideas rule
the characters remind you if you are ignoring them rule
the free to speak again rule

The everyone speaks if queued rule simply discusses the next queued topic for every character in the game. In a turn during which the player has spoken, the result is typically that the current interlocutor now discusses the current quip, completing the exchange. In a turn where the player has *not* spoken, but the character has something more in his queue to say, he will go ahead and do this.

The character pursues own ideas rule now considers whether the current interlocutor has something *more* to say and whether the thread we were on has come to a halt. If we are indeed at the end of a thread -- the current quip is "dead-ended", with nothing following it -- then the current interlocutor gets another turn: we run the avoiding talking heads activity, then perform the *next* queued conversation for the current interlocutor.

The avoiding talking heads activity is meant to be used to print out some sort of interstitial text -- whatever the author would like, really -- to indicate a pause between the current interlocutor's reply to the player's quip and the new thing that the current interlocutor says on his own.

The characters remind you if you are ignoring them rule is used to print the "nag" text of the current quip on any turn when the player has not said anything.

Finally, the free to speak again rule simply marks everyone as no longer speaking, to prepare for the next turn.

This structure means that most of the time the current interlocutor will not change the subject of conversation on his own, but he can do so if the current conversation is pretty much tapped out. Experiment suggests that this is about the level of initiative that players like in a character: if a character talks too often and directs the conversation too much, the player may feel that he's not really in control, but is merely watching a pre-programmed narrative unfold. If the character *never* takes the initiative, though, he starts to seem implausibly passive.

But if this mechanic doesn't work for a specific game, it can easily be changed by modifications to the conversation-reply rules.

Very often, in the course of the conversation, we will want to add new items to a character's queue, to make him follow up a turn or two later on something the player has said. This helps give him a sense of agency and self-direction. To accomplish this, we can write

queue (some quip)

for the character to say it at the next opportunity (equivalently, the quip may be queued "as immediate obligatory");

queue (some quip) as immediate optional

to say it as soon as possible, but only if the player does not respond with another quip -- so it is a fleeting, off-hand remark;

queue (some quip) as postponed obligatory

to say it after all the other things that may already be in the queue; or

queue (some quip) as postponed optional

to say it after all the other things that may already be in the queue, but discard it if the player changes the subject; it is an unimportant add-on.

Often, in the middle of a thread, we want to have the current interlocutor make a brief comment in reply to player speech, but only if certain conditions are met:

the current quip is not restrictive,
the character has not already discussed the quip under consideration, and
the quip under consideration quip-supplies the character.

As a shortcut, then, we may write

casually queue (some quip)

to queue it as immediate optional, or

follow-up queue (some quip)

to queue it as postponed optional -- but only if the above conditions hold. (The standard queue phrases do not check for any conditions before adding to a character's queue.)

All of these queue phrases can also be used within say tokens, as in

say "'The weather is fine,' says Captain Hook. [queue picnic-proposal]".

By default, the character's collection of optional quips to discuss is cleared when the player changes the subject, by moving to a new conversation thread that isn't quippishly-relevant. This behavior is controlled by the following rules:

Carry out someone discussing something which is not quippishly-relevant (this is the mark changes of subject rule):
     carry out the subject-changing activity.

Subject-changing is an activity.

Rule for subject-changing (this is the default changing of subject rule):
     delete purgeable conversation for the current interlocutor;
     now the grandparent quip is the noun.

(The grandparent quip is used to keep track of where the player entered a thread, if re-entering a thread somewhere other than at the thread's natural beginning.)

This default behavior keeps a character from stubbornly reverting to earlier topics once the conversation has definitely moved on; but there may be times when this is not desirable, so we may wish to turn off the mark changes of subject rule or to write our own subject-changing rules.

Section 7.2: Adding dramatic grounding beats

Reading a series of plain alternating quotations can quickly become dull. An effective way to break up such monotony is to insert a short description, to describe a minor action, or even to convey important non-verbal information, either between two parts of an exchange or in the middle of one character's monologue.

The beat-producing activity exists for exactly this purpose. It is called by the default rule in the avoiding talking heads rulebook; or we may call it explicitly, by using the "beat" text substitution, like so:

the reply is "'So it is true, then.' [beat] 'But it doesn't change how I feel.'"

By default, the beat-producing rulebook contains only a single rule, which merely prints "There's a brief pause." We may add as many and as complex rules as we like. For example:

rule for beat-producing when the current interlocutor is Hook:
     say "[one of]Hook gingerly scratches his nose[or]He twirls his moustache[at random]. [run paragraph on]"

Section 7.3: Interrupting between the comment and the reply

Because the current interlocutor's speech comes as a separate action after the player's speech, we have the opportunity to describe physical action between the question and the answer; to build special cases where a third party interrupts, if present; or to replace the standard reply under certain unusual circumstances.

If we want a character to respond atypically -- for instance, by ignoring all of the player's remarks and relentlessly pursuing his own line of thought -- we can intervene in the way that the replies are queued or in the way that they're carried out. One of many possibilities, for a scene where the character will talk about a specific thread but refuses to be gotten to talk about anything else:

The distracted reply rule is listed instead of the prepare a reply rule in the carry out discussing rulebook.

This is the distracted reply rule:
     if Shadows is happening:
         if the person asked is not the player, make no decision;
         if the noun is not quippishly-relevant,
             queue act-distracted as immediate obligatory;
         otherwise queue noun as immediate obligatory;
     otherwise:
         queue noun as immediate obligatory.

act-distracted is a weakly-phrased NPC-directed performative quip. To continue is a verb. To ignore is a verb. To show is a verb.
The reply is "[Regarding the person asked][They] [one of][continue] [possessive] own line of thought[or][ignore] your remark[or][are] looking somewhat past your head[or][don't] [show] signs of following what you just said[at random]. [run paragraph on][awkward segue]"

To say awkward segue:
     if any conversation is queued for the person asked,
         perform the next queued conversation for the person asked.

The possibilities are numerous, so we should check out the fuller examples to explore this further.

Section 7.4: Giving a character a whole script of things to discuss

We may particularly want to intervene and prevent subject-change from happening if we have a scene in which the character is meant to tell the player a certain number of things before moving on.

We can set such a scene up by queueing a whole list of character comments at once, as in

When Shadows begins:
     say "[pause]It is dangerous to give your frank opinion about a lady's fiancé, especially if you are yourself wildly in love with the lady in question. So you do not immediately speak.";
     queue Lily finds herself crying;
     queue prince acts creepy.

(Note that because the default quip precedence is immediate obligatory, these quips will be said in the reverse order of how they are added!)

If we do this -- and prevent the player from changing the subject away from this thread -- we'll have a scene in which the player can ask as many or as few on-topic questions as he wants, but the important information the character needs to convey should always reach him, sooner or later.

Section 7.5: Affecting the state of the world

For simplicity, TC exists as a standalone, verbal system, with little to tie any given conversation to the greater world model. Performative quips, for instance, are more often used for conversational effect rather than to induce some physical change. Any systematic link, so that conversation alters the state of things in the world model (or vice versa), would best be accomplished by crafting general-purpose rules governing this behavior, adding exceptions as necessary.

However, if there will be only a few of these events, an ad hoc approach may suffice:

for the idol is a questioning quip.
     It mentions the idol.
     The comment is "'Give me the idol!' you yell."
     The reply is "'Uh, no problem.' Eli hands it over, eyes wide."
     It quip-supplies Eli.

After Eli discussing for the idol:
     now the player carries the idol;
     continue the action.

We must continue the action there, to allow the report discussing rules to print Eli's reply as usual.

Or, if the player will be making many such item requests:

to buy Park Place is a questioning quip.
     It mentions Park Place.
     The comment is "'I'd like to buy Park Place.'"
     The reply is "'Here you go,' Eli says.[give the player Park Place]".
     It quip-supplies Eli.

to say give the player (item - a thing):
     if the current interlocutor has the item,
         now the player holds the item.

Note also that the system does not check to ensure that the characters remain present all throughout the conversation. If the player or the other person may be moving around somehow during a conversation, we might want to set up an every turn rule to check this condition, and reset the interlocutor if it does not hold.

Last every turn when the current interlocutor is a person and the current interlocutor is not in the location:
     reset the interlocutor.

Section 7.6: Advanced beat and formatting control

By default, when the conversational thread has been exhausted and the current interlocutor has something in her queue to say, the prevent talking heads activity will be called. This will print a grounding "[beat]" and a paragraph break before she discusses this new quip.

There are a few properties of quips we can define to control this behavior. By default, a quip is considered "strongly-phrased"; we may mark it "weakly-phrased" instead if its reply text is merely a transitional phrase or minor comment, before the character then moves on to her topic of interest, so that the reply text from both quips can be combined into a single paragraph. The weakly-phrased property generally works best if the reply itself is not written with a grounding beat of its own at the end. (Note that if a weakly-phrased, dead-ended quip is followed by a character's queued change of subject, the prevent talking heads activity will be bypassed entirely.) However, this means that weakly-phrased quips should only be used when the interlocutor has a queue stocked with quips (and probably NPC-directed ones) of her own that she is itching to get to.

Similarly, a quip may be defined as "beat-opened" rather than (the default) "speech-opened" when we want to craft a unique conversational beat at the start of this particular quip, rather than using the standard beat-producing rules. This property indicates that the quip's reply text begins with a grounding beat, rather than quoted speech. It is most useful for NPC-directed quips, as it does not affect text formatting unless the character has chosen the quip from her queue.

There is some random variation, but this system ensures that two instances of quoted speech will never be printed side by side without an intervening beat or a paragraph break. Of course, we can alter or expand this behavior by changing the prevent talking heads activity. Or, if we ignore both of these properties entirely, the system will still function well.

See the Blackened Blue example, below, for a demonstration of how the formatting of these types of quips may interact in printing NPC dialog.

Chapter 8: Trouble-shooting

Section 8.1: Debugging actions

QUEUE (someone)

will produce a list of the quips that person has queued, along with their quip-precedences. This is useful when an NPC seems not to be discussing the things planned for him to say.

Section 8.2: Built-in debugging functions

TC runs some checks at the beginning of any game compiled in debug mode.

First, it checks for quips that mention themselves. This happens most often when a quip is defined along the lines of...

where her stepmother went is a repeatable questioning quip.
     It mentions stepmother.

... when "stepmother" has not been previously defined as a subject. Quips that mention themselves cause the game to hang at runtime, so it is important to catch these; if TC finds such a cycle, it will list the violations and then quit without going further.

TC then checks for items that are probably subjects, but which are not declared to belong to the subject kind. It detects all items that are mentioned by quips but are not in a location (that is, not part of the game world at the start of play) and are not already of the subject kind. In the event that a character can talk about an object that starts the game out of play, TC may identify these falsely. All the same, it's good to catch things that are probably subjects, for two reasons:

1) this helps to identify cases in which Inform has accidentally duplicated an existing subject, through misspelling or other similar error, and the subjects should be consolidated into one;

2) it encourages the author to make any appropriate free-floating conversation objects into subjects and perhaps, in the process, to generate additional understand rules and vocabulary for them. TC does not absolutely depend on objects being declared as subjects, but add-on extensions may do so.

Section 8.3: Caching

TC fills out some relations and properties automatically when the game begins, to reduce the number of complex calculations that must be carried out every turn. However, in especially large projects, even this startup time may prove prohibitive. In that case, we need only add the line

Use hard cache.

to generate this hard-coded cache automatically, which can then be pasted back into the source. To rebuild the cache in the future, simply delete the old cache.

Rebuilding needs to happen every time we add new quips or change the way quips relate to one another, so it's kind of tedious to wait on during serious development; but once we approach release and the content becomes fairly stable, we're going to want the cache in place, even if we still have to regenerate it sometimes.

Chapter 9: Release Notes

Section 9.1: Version 8

Fix the recap of known facts rule, response (C), to make it labelled (C) properly
Explain weakly-phrased quips a bit better in the documentation

Section 9.2: Versions 6/7

Fixing a few parser error issues
(date 180807: corrected invalid extension ending line)

Section 9.3: Versions 4/5

Compatibility with I7 6L02 (and 6L38)
     'response' of quips renamed to 'reply', to avoid collision with the new I7 responses system
TC responses are now adaptive
Cleaned up extensions and main code

Section 9.4: Version 3

Minor comment cleanup and clarification throughout

Section 9.5: Version 2

Backdrops no longer trigger the "X is a subject." notification at startup
Corrected a syntax error in a rule name preventing compilation (oops!)

Section 9.6: Version 1

Implicit greeting finally fully functional
Documentation reworked
Smarter Parser no longer accommodated for or against; all necessary code absorbed (mainly for implicit greeting handling) or altered

Chapter 10: Pre-Release Notes

Section 10.1: New in Beta Versions 5/6

Discussing a quip with a non-interlocutor mistake message disabled when TC is used with Aaron Reed's Smarter Parser
Bug fix: discussing it with (with nouns reversed) understand code now working as intended
Reformatted, renumbered, and renamed many headings

Section 10.2: New in Beta Version 4

Bug fixes
Replaced the "context" error with one more appropriate when trying to discuss quips
Correcting spacing of distracted reply sample code
Change discussing action to handle only relevant quips, without using "[any]" token and provoking the "context" error
Subjectifying action implemented to catch and process discussions before an interlocutor has been greeted
"Obstinance" example replaced with "Blackened Blue" to demonstrate dialog queue and advanced quip formatting features

Chapter 11: Testers

Matt Weiner
Dannii Willis
Björn Paulsen
Melvin Rangasamy
Johan Paz
Hanon Ondricek
Jason Ermer
Susan Douglas
Joseph Limbaugh
David White
Justin de Vesine
Steve Robotnik
Konstantin Koss
John Large
Amy Lear
Matthew Stallter
Blecki

A	Example Very Simple A simple example to start with.

B	Example Slightly Less Simple The same inn as the previous example, but introducing a second character to talk to.

C	Example Not So Simple The inn example a third time, now with an example of a repeatable quip.

D	Example The King of Everything An example in which the player can re-ask all questions, but on the second and subsequent askings, the game replays the literal text of the first question.

E	Example Conferences An example in which eavesdropping third parties will react if they hear anything in the conversation that they find upsetting.

F	Example Blackened Blue An example that demonstrates conversation queueing, self-directed NPC conversation, and advanced quip formatting features.