7. Other Characters

Talking about characters presents some special challenges. For one thing, some characters are referred to by a proper name, but others are not: so the story might want to talk about "Jack" but also about "the drunk pedestrian". In the absence of other information, Inform attempts to divine our intentions based on the words with which we defined a new character: but we can always override its guess with an explicit statement, such as

Belfry ★ demonstrates further how titles are set at the start of play.

The relation between the player and the other characters is not always static, however. Sometimes we want the player to learn a character's name part-way through play, and start referring to "the drunk pedestrian" as "Fernando". Similarly, the status of another character may change due to some twist of the plot. Gopher-wood ★★ shows how to change the name of a character mid-story, and Peers ★★ handles changing the character's rank.

Alternatively, of course, the player character may already know some of the other characters when the story begins, even if the player does not. In that case, we may want to add a tag-line or so of identification to a character's name when he first appears in the story. A Humble Wayside Flower ★★★ shows one way of doing this.

Another occasional challenge is dealing with such commands as EXAMINE DR. THISBY. The problem here is that Inform by default will understand the full stop after "Dr" to be the end of one command and the beginning of another, and will try to interpret "Thisby" as a verb. If we do have a story populated by such formally-addressed characters, we may turn to Punctuation Removal, which provides a phrase to remove the full stops in standard titles before attempting to interpret the command.

Other characters have physical characteristics as well as names, of course, and Meet Market ★ demonstrates one way of implementing people with notable features.

Finally, in some IF, the roles of characters may change from playing to playing. If we are writing a replayable murder mystery, we might want to select a new culprit each time the story starts; for this, see Clueless ★.

A character who sits still in a chair and does nothing is much less convincingly alive than one who seems to be pursuing some sort of personal agenda. There are all sorts of ways to achieve this, but the least challenging is by introducing some random change to descriptions, and by giving a character some very simple routine behavior to carry out.

For instance, we'll often want the characters in a room to be described doing different things every time we look at them. Camp Bethel ★★ shows how this may be done.

Every turn rules lend some sprightliness to otherwise-silent characters, as well:

We might expand on this by providing a whole table of things for Mrs MacG. to cycle through, or a text variation effect that gives her different activities every turn, as in

This is no great innovation in characterization by itself, but it does at least remind the player that the character is alive and moving about, even when he isn't paying attention to her.

Annoyotron Jr ★ demonstrates a character who actively tries to get our attention, and whose routine of behavior changes just slightly if we show signs of having reacted to him.

Lean and Hungry ★★★ implements a classic thief, a character who doesn't interact with the player much except to pick up valuable objects he finds left around the map. Later we will see rather more advanced ways to make characters act on their own goals and plans, but this kind of simple behavior is easily rigged as part of an every turn rule.

Finally, Text Foosball ★★★★ extends the every-turn-rule idea to create an opponent who joins us in a randomized game of table soccer.

With animal characters, this kind of repetitive, semi-random behavior is often adequate: we don't expect animals to talk, or pursue steady goals, or to take an interest in what we do in their presence (unless it involves a food they like to eat).

For people, we are likely to need an assortment of additional techniques.

As we observe characters, so they observe us. Those who seem to have no awareness of what the player is doing often come across more like waxworks than like people. Zodiac ★ demonstrates a scenario where the watchful presence of a dangerous criminal keeps the player from doing what he otherwise might, while Police State ★ expands on this idea with a policeman who reacts to entire types of behavior in his presence, regardless of whether the culprit is the player or a third party. Noisemaking ★★★ has a crow who will fly away in response to any loud noises the player makes.

And, of course, we definitely want to have characters react to being looked at or otherwise interfered with. Search and Seizure ★★★ implements a smuggler who reacts when we try to confiscate his possessions. Pine ★ gives us a sleeping princess who can be woken by a variety of methods.

We wrap up this section with two complete puzzle scenarios that demonstrate what can be achieved by giving characters reactions to the player's behavior. A Day For Fresh Sushi ★★★★ has a fish who watches the player's actions and comments on them, while the live furnishings in Revenge of the Fussy Table ★★★★ instead comment every turn on the current state of the world, until the player has successfully sorted out all their complaints.

By default, Inform characters are a bit grudging about giving and sharing objects: they react with disinterest when they're shown things and refuse everything they're offered.

If we'd like to change this, we can simply remove the default "block giving" rule, as in

If we do this, giving items to characters will have the result of moving our possessions to the other person's inventory. Of course, without more customization, the player may not ever be able to persuade the other character to return his possessions. Bribery ★★ demonstrates a scenario in which a character will accept gifts if they are interesting to him, and respond with a changed attitude to the player.

Barter Barter ★★★ expands further on this by allowing other characters to trade things with one another.

Not all characters are friendly, and there are times when we may want to include a fight sequence. There are a number of ways to approach this, depending on whether we want to offer the player a random outcome, a predetermined one, or a combat sequence that depends partly on strategy or on having the proper equipment.

Lanista ★ demonstrates randomized combat in the style of a role-playing game. The player has a partially random chance of doing any given amount of damage; both the player and his opponent have hit points, and whichever one runs out first dies. Lanista 2 ★★ continues this idea, but includes weapons that affect the amount of of damage done. Red Cross ★ by itself implements a command that we might use to find out how strong characters are at the moment.

A word of warning about designing such sequences: a player who gets a roll he doesn't like always has the option of UNDOing a turn and re-rolling. This means that he can always win a random battle sooner or later; bad luck only means that it takes him longer (so he gets more bored and irritated as he plays through). It is possible to turn off UNDO implementation with

…but there is a good chance that this will irritate players in itself. Role-playing-style combat scenarios need careful design, lest they actively make a story less fun.

In a slightly more realistic setting, combat leaves physical remains behind, unless we're wielding some kind of futuristic weapon that evaporates our opponents entirely: Puff of Orange Smoke ★★ demonstrates characters who leave corpses behind when they die, while Technological Terror ★★★ more tamely explodes robots into numerous component parts.

Finally, we can imagine some scenarios in which, instead of allowing characters to strike at each other for random damage, we want to introduce an element of strategy. Don Pedro's Revenge ★★★ shows the rudiments of a system in which the characters can make different kinds of attack depending on where they are in a room filled with perches, barrels, and other swashbuckler props.

Traditionally, conversation is one of the most difficult things to program in interactive fiction, because of the number of factors affecting the outcome of everything the player does. While it's acceptable for >EXAMINE POT to produce the same response 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. Later in this chapter we will look at ways to model character knowledge and mood.

Then, too, we have the problem of how the player communicates his conversational intentions to the story. Technology has not yet advanced to the point where a player can simply type in remarks in full natural English and have the character detect the significance, emotional tone, and subtext, if any: so we can't have RACHEL, THIS DESSERT TASTES LIKE FEET or WILL, LOOK! OUR SINISTER METAL FOES ARE APPROACHING! or BOSS, I WOULD BE DELIGHTED TO FILE ANOTHER TPB REPORT.

The challenge is to create an interface that is both easy for the player to use and expressive enough to be interesting. We will look at some of the common solutions in "Saying Complicated Things".

The examples in the following sections point out ways to approach common conversation problems. None of them will offer an adequate system if we want to write a very conversationally rich story, however. This is partly because a thorough conversation system requires quite a lot of code in its own right. It's also partly because there is no one right solution to the problem of conversation design. Different games will have quite different requirements. When making decisions about a new story we have planned, it may be useful to glance through the conversation extensions available for Inform: there are quite a few, offering a range of different interfaces. Even if none is exactly suited for our needs, they may suggest ways to solve particular implementation challenges.

At the other end of the scale, though, there are times when Inform's default implementation is too complicated for what we want to do: so we will start with ways to simplify conversation, before moving to all the exotic complexities.

Before we get into these details, though, we have a couple of examples that are literally about getting started with a conversation: Mimicry ★★★ introduces the feature that we must greet other characters before beginning to speak to them; The Gorge at George ★ corrects the player's attempts to use a TALK TO command where a different mode of interaction is appropriate instead.

There are times when even the commands ASK and TELL are overkill: sometimes the player doesn't have much information to offer, so TELL is never useful, for instance. If we don't want to make any distinction between modes of conversation, we can conflate the actions so that ASK LUCIUS ABOUT OLLIVANDER, TELL LUCIUS ABOUT OLLIVANDER and LUCIUS, OLLIVANDER all do the same thing: see Sybil ★.

If we are frequently permitting the player to say things like LUCIUS, OLLIVANDER as shorthand for "talk to Lucius about Ollivander", then we may also want to allow LUCIUS, OLLIVANDER? This makes the player character seem a bit slow (or at least Laconic), but it is an effective interface in some cases. The trick is that the question mark at the end of the command may prevent Inform from recognizing the keyword; should that problem arise, we may want to use Punctuation Removal to erase question marks from the player's command before attempting to interpret it.

Along the same lines, there are situations in conversation where similar commands do not correspond to the same actions within Inform; if we're careless about this, we may force the player to guess which vocabulary we want him to use, which is always vexing. Some cases to look out for:

Inform has actions for "saying yes" and "saying no". Sometimes this is useful, but sometimes we want YES and SAY YES TO FRED to do the same thing. Sybil 2 ★★ shows how to roll these responses into one; Proposal ★★ expands on the idea to show more ways in which a player could reasonably answer a question put by another character.

Again, if we want ASK SYBIL ABOUT CAKE to do the same thing as SHOW CAKE TO SYBIL, we might use the technique in Nameless ★★ to make objects into valid topics of conversation, and to make ASK and SHOW behave the same way.

Finally, if we want to be able to ASK and TELL an inanimate object -- say, a computer -- about something, we may use the extension Inanimate Listeners to add this capability.

As we saw in the overview, there are challenges in choosing the commands with which the player will communicate to the story. Two common approaches are ASK/TELL conversation, where the player can ask or tell characters about keywords, as in ASK JILL ABOUT JACK or 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

or, sometimes,

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. Nonetheless, this is sometimes just what we want: Farewell ★★ implements a moderately sophisticated system along these lines, which keeps track of what the player has already said and allows him to review past conversation.

Menu-based conversation solves most of these problems: a branching tree of conversation choices maintains a consistent flow of discussion, it's hard for the player to run out of things to say, and the player always knows what his character is about to say. But there are compensating flaws. For one thing, a menu doesn't allow for many surprises. The player can see all the conversation the story 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. It becomes a chore rather than an entertainment.) Menu systems can be long-winded to set up and therefore none are exemplified here, but several have been released as extensions for Inform.

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

Moreover, when he asks about a topic where many comments are possible, he'll be allowed to clarify, either using a menu or through a disambiguation question such as

Sweeney ★★ implements one such hybrid type of conversation.

A third option is to take away almost all the player's expressiveness and give him just one command, TALK TO. The player can TALK TO characters whenever he wants, and the story will pick the most appropriate thing for him to talk about. This works best in works with few or simple puzzles and a fast-moving, constrained plot, where the player will keep having new things to talk about. Cheese-makers ★★★ demonstrates this.

Finally, a few extreme games try to fake natural language understanding by looking for keywords in the player's input, rather than an exact grammar. This is perilous, because it is all too easy for the story to completely misunderstand what the player meant to type. Nonetheless, for the sake of example, see Complimentary Peanuts ★★★, in which the incomprehension is partly excused by the fact that the player is talking to someone a bit hard of hearing.

All this discussion of conversation commands and ways to model dialogue doesn't address the higher-level design issue: how do we approach writing this material so that it has a rhythm and flow? How do we know when we've created enough conversation? How can we avoid sounding hopelessly stilted when the nature of IF implementation requires us to break our text into small snippets?

While most authors develop their own approaches, there is some general advice that may help, especially for works that have a strong narrative progression.

It helps to have the plot of the story, with all its component scenes, planned in advance. That doesn't mean there can't be any changes later, but having a list of the different scenes can help us remember the different contexts in which information can appear. If we're using Inform's scenes feature, we may even want to restrict some dialogue to be available only during a given scene.

The next step is to go through scene by scene and create the "spine" of the scene. What must be said during this section? Is there anything the player can't leave without knowing? If the player isn't moving the scene forward fast enough, will the other character or characters volunteer information in order to keep the pace going?

It often helps to draft a transcript showing what we imagine as the ideal playthrough of the scene - writing straight through can create a natural flow of dialogue - before dividing the dialogue into pieces for implementation.

Once the scene is complete enough for the player to get through from beginning to end, we can start filling it out. At this point, it sometimes helps to play through the scene a number of times and add new dialogue elements as we think of things that our character might reasonably want to say. Sometimes these additions will turn out to be short tangents from the main flow of a very directed scene; sometimes they might be important branches that lead the scene to an entirely alternate outcome. The main thing is to make sure that, if the scene needs to hit certain points before ending, none of our branches keep the player from returning to the subject at hand.

In a complex story, characters may evolve strong feelings about the player. Often we want to hint at the character's feelings through gesture and tone of voice - little things woven into dialogue and action sequences that might otherwise be unchanged. Ferragamo Again ★★ demonstrates creating phrases to give all our characters different ways to express their irritation at the player.

Then again, sometimes a discussion might produce quite spectacular results if a character is in the wrong mood. Being Peter ★ shows the bare bones of an implementation in which a character's attitude rulebook is consulted to determine what her response will be - allowing for arbitrarily complicated outcomes.

A character may be endowed with knowledge and even reasoning skills. Relations form quite a good way of keeping track of such problems: for instance, we can allow characters to be acquainted with one another with a relation such as

Or we might keep track of more complicated attitudes between characters, as in Murder on the Orient Express ★★, in which some characters suspect others of the crime.

Alternatively, we might have a list of salient facts that are important in our story. We might declare these as values, and then characters could know, learn, and forget entries as appropriate:

Or again we might keep a whole database of information in a table: the characters in Questionable Revolutions ★★★ know dates, countries, and a short description for each of several rebellions and popular uprisings, while in Queen of Sheba ★★★, Solomon is able to answer who, what, where, when, and why questions about a range of topics. This kind of approach is most useful when the characters need to display a deep knowledge of a particular field. The facts stored in the Table of All Known Facts, above, are comparatively sparse, because there we are designing a story in which not all data about the world is equally valuable: Lucy doesn't know the shoe size of every person in the story, because for some reason it is only her own shoe size that matters. On the other hand, the Table of All Known Facts can store different kinds of information, whereas the revolutions table has no way of storing shoe sizes or sunset times. And Murder on the Orient Express ★★ works differently again, because it is storing knowledge that concerns people and things that already exist in the world model, rather than abstract ideas. Our way of modeling character knowledge, in other words, will depend quite a lot on what kind of knowledge it is.

The possibilities of character reasoning are similarly broad, but The Problem of Edith ★★★ introduces one kind: the character has a concept of how different conversation topics relate to one another, so that when she is asked about a new keyword, she picks a response that makes the question most relevant to the conversation already in progress.

We end with a longer scenario, in which we track what the character knows about the player and the conversational state: in Chronic Hinting Syndrome ★★★★, the main character guides conversation in the direction he intends it to go, with the player's sometimes-reluctant participation.

So far we've seen characters who will answer questions whenever the player feels like asking, and characters who will use some reasoning procedure to direct the conversation. There is a third option, often useful in IF with a fast-paced narrative: the character follows a conversational script, making sure to cover a series of points before the scene ends.

There are more and less tedious ways to implement this kind of scene. The worst case is one in which the player is not allowed to interrupt or ask any questions; he must merely wait until the character runs out of things to say. This can be useful and plausible in very small doses - say, two or three turns - but if the character has more information than that to impart, we may want to make the scene more interactive.

Pine 2 ★★★ partly addresses this challenge: the character has a line of conversation that she wants to follow to its conclusion; we may ask questions along the way, but if we're silent, she'll take up the slack, and the scene won't end until she's done with what she has to say.

Another kind of script is a series of actions for the character to perform. Robo ★ demonstrates a programmable robot that will observe what the player does, then try to emulate the actions later when switched into play-back mode. Robo 2 ★★★ extends this capacity to allow the robot to contain fifteen different scripts which the player can store, list, run, and erase.

Your Mother Doesn't Work Here ★ offers a character with a list of tasks but whose plans can be interrupted by more urgent demands. This verges on not being a simple script any more: if we carry the idea to its natural conclusion, we get characters capable of planning scripts for themselves to accomplish their aims. This is conventionally called "goal-seeking".

There are a number of ways we can make characters navigate our map. We might reasonably want them to approach and follow the player (as in Van Helsing ★★); or to allow the player to follow characters who have left the room (as in Actaeon ★★).

Characters who are less interested in the player will more likely follow their own courses around the available geography, however. A character may move randomly from room to room, as demonstrated in Mistress of Animals ★; he may follow a path that we have specifically written in advance, as Odyssey ★★ shows; or, most elegantly, he may use the "best route" calculation to find the best possible way to a given target room, as seen in Latris Theon ★★★.

This final method is arguably the neatest solution to character movement, allowing for characters to act in sophisticated ways; if we incorporate the Locksmith extension, other characters will even unlock and open doors that are in their way. The chief catch is that it should not be used too profligately with large numbers of characters, since on slow machines the processing power required to plan all their travel will make a noticeable difference to the running speed of the story.

All the same, the constraints are not so severe as to preclude having a moderate number of route-finding characters all wandering around at once. This does introduce a new problem, however: movement descriptions can become hard to follow if every turn produces long reams of reports such as

Patient Zero ★★★★ tackles this problem by calculating all of the character movement without printing any text; it then combines similar or related events into coherent paragraphs, as in

or

Other characters can perform all the same activities that the player can; this does not always mean that they're willing to obey the player's instructions. By default, characters will refuse to obey commands of the form JULIA, WEST or ANTONY, TAKE THE PINCUSHION. Their objections can be overridden, however, and The Hypnotist of Blois ★ implements a hypnotist who can make characters obedient at will.

In For Demonstration Purposes ★★★, the character is only capable of a few actions at the outset, but can be taught new ones if the player performs them first.

Often we want characters' obedience to be more selective. Just as the viewpoint character may be characterized in terms of what he will and will not do, so may others: Generation X ★★ demonstrates a character who will do what she's told, but who will comment unfavorably when the player asks for a nonsensical or repeated action, and who may eventually get fed up and leave.

Characters can be given moral objections to certain commands, as well: Virtue ★ defines a few kinds of actions as bad, so that the character commanded will refuse to perform them.

Under Contract ★★★★, more subtly, has the character object if the player's commands implicitly require any behavior he considers inappropriate: for instance, if the player commands him to put his pants in a container, he will work out that this requires the removal of the pants as a preliminary. If we want to implement a similar character, we may want to simply copy his unsuccessful attempt rule and the table of his retorts, then replace his banter with lines of our choosing.

The little example Latin Lessons ★ allows us to make characters clever about vague commands: we can, for instance, write rules so that CLARK, EAT will have Clark sensibly pick something edible, rather than having the parser ask what we want Clark to eat.

Finally, Northstar ★★ demonstrates how we might make Inform understand commands of the form ASK JOSH TO TAKE INVENTORY or ORDER JOAN TO WEAR THE ARMOR.

Goal-seeking characters are the most advanced IF life-form: they want to achieve specific outcomes, and they are able to work out plans of approach in order to bring these things about. They walk to rooms, open containers to search for things, use keys and tools, and ask leading questions in conversation.

A really advanced implementation of goal-seeking behavior is beyond the scope of our examples (though extensions exist that treat the problem more thoroughly). We can accomplish a surprising amount without heavy customization, though, if we keep in mind three points of technique:

First: it helps to think abstractly and to create broadly-defined actions as a first step to more specific tasks. For instance, a character's goal might be to eat some dinner. He'd be equally satisfied with spaghetti carbonara or with braised lamb shanks, but he needs to figure out which is available. So we might have our every turn rule (or whatever we're using to activate the character) say something like

Dining would then be an action we've defined specially, which looks around Clark's environment for suitable food; if it finds food, it issues a

command; but if not, it sends Clark off to look for something likely. The Man of Steel ★★ demonstrates the use of this.

Second: though it doesn't actually contribute to the goal-seeking per se, lively reporting brings characters' generated behavior to life.

doesn't characterize Clark very much, even though the eating may be part of a subtle, intelligent plan to seduce Lois Lane. We'll do better if we replace a lot of the character reporting rules: to that end, see the example The Man of Steel Excuses Himself ★★.

Third: goal-seeking characters notice when something is in the way of the action they want to perform. When that happens, they form a plan about how to remove the obstacle. We've already seen this kind of implementation on the player's behalf: the player will pick up items before eating them, say. We can use Before rules to do similar things for other characters, as in

Here we've set things up so that if Clark tries to eat the wrapped candy, he'll be interrupted by this other command; and if his unwrapping-the-candy attempt fails, he won't go on and eat the thing. IQ Test ★ demonstrates a character who shows this kind of planning intelligence.

Because before-rules chain neatly, we can trigger whole plans of behavior if we have a sensible set, as in

We must exercise a little bit of care if it is possible for the chain of actions to produce an endless loop - e.g., the character trying to take a key that is inside the transparent, locked box that it opens might repeatedly try to open the box, first unlocking the box, first taking the key, first opening the box, … Boston Cream ★★★★ is a fully-worked scenario that deals with such a set of conundra.

Crowds of characters introduce new challenges, because we often want to show them interacting with one another, or to describe individuals in less detail when a whole group is present.

Strictly Ballroom ★★ gives us a set of characters who pair off each turn, making sure to mention each one once, and leaving one unfortunate person behind as a wallflower: this exemplifies how we might use a behavioral rule not to dictate the behavior of each individual separately but rather to model a whole group together. Happy Hour ★★ does calculate movements for characters individually, but then collates the descriptions, creating a single paragraph to describe whatever group is currently in the room.

Characters can also have complicated attitudes to one another, and it can be helpful to use relations to track these. Unthinkable Alliances ★ demonstrates the grouping of characters into alliance factions, while The Abolition of Love ★ provides a host of relations to track love affairs, marriages, memberships in families, and mere mutual respect.

Emma ★★ combines these two effects: its characters move between social groups depending on how they feel about the others in their particular talking circle, and descriptions change depending on who is where in the room.

Lugubrious Pete's Delicatessen ★ simulates a queue at a deli, in which the customers who most impress Pete get served first.