Gamasutra: The Art & Business of Making Gamesspacer
arrowPress Releases
April 18, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM TechWeb sites:


Analysis: Conversation Design In Games
Analysis: Conversation Design In Games
May 14, 2009 | By Emily Short

May 14, 2009 | By Emily Short
Comments
    4 comments
More: Console/PC



[In this column, writer and interactive fiction designer Emily Short looks at conversation design in support of narratively compelling, well-paced scenes.]

Last year, Brent Ellison published a Gamasutra article on dialogue systems in games. A little while later, Jonathan Blow posted on his blog an open-ended query about designing conversation in games. Then, this February, Krystian Majewski posted about dialogue choices in Emerald City Confidential, speculating about the challenges of presenting decision-filled conversation to casual players.

These three posts -- all interesting -- and the followup comments suggested that there's relatively little public discussion of core methodologies for conversation design.

In particular, much of the existing analysis conflates user interface (how are dialogue options presented? when do they appear on the screen? is the player offered full text of the next sentence, or a truncated version of what his character will say?) with the underlying model (how does the game decide which options are available when? how are the player's options restricted or made open? what controls when and whether the NPC speaks on his own?).

User interface is the more visible and thus the better understood of the two. It's easy to play a game and see how the dialogue choices are being presented, but much harder to guess what code lies beneath.

Yet the underlying model does matter a great deal.

In practice there is already an assortment of conversation models at work in commercial and indie games. The world of gaming dialogue is not quite divided into "Facade" and "everything else", and sometimes games that seem inexplicably more effective are so because they are relying on logic that has not received much public analysis.

If we're to understand how those things work, we need to start talking about conversation at a level beyond "what kind of menu does the player see?" -- because, as important as that question is, it only touches the surface.

There's a huge amount to look into here: how is conversation information stored? Is it merely dialogue text, or are abstract values associated with conversation content -- for instance, to indicate that one statement is more offensive than another? What is the relationship between what the PC says and the NPC's response? Does saying the same thing always garner the same reply? How is the idea of context handled in the code? What about repetition of dialogue?

What follows is a description of one model that I have found particularly useful and extensible. It has been refined in the course of writing for about a dozen conversation-centric projects since 2000, and also thanks to the influence of other conversation theorists, especially in the interactive fiction community.

It's absolutely not the only way I can imagine attacking the problem, but of the things I've tried, it is the most versatile.




Conversation Structure

Ellison identifies two fairly common kinds of dialogue design which he labels "Branching" and "Hub-and-Spokes". He writes:

"Though ultimately a variation of [Branching], Hub-and-Spokes Dialogue creates a very different conversation flow compared to basic Branching Dialogue. The player listens to the NPC's lines and then chooses their response from the main "hub" of the conversation... After hearing the NPC's response, the player either returns to the main hub, from which they can ask the same question again or inquire about another topic, or enters a deeper hub with more options to choose from."

As Ellison points out, this kind of conversation dynamic allows for a lot of player freedom to explore different topics, but can lead to repetition and give the impression of an implausibly patient NPC.

Both of these designs arise from a fundamentally tree-structured model of conversation. Let's call the lines of dialogue the player is allowed to speak, and their attached NPC responses, quips. We might picture a hub-and-spokes conversation that looks a bit like this:


Hub
Quip about origin of werewolves
-> automatic return to Hub
Quip about wolfsbane
-> automatic return to Hub
Quip about Lord Fangclaw
Quip about Fangclaw's bride
Quip about making cake for the wedding
-> automatic return to Hub
Quip about bridal registry
-> automatic return to Hub
Return to Hub
Quip about Fangclaw's castle
Quip agreeing to storm the castle with pitchforks
-> automatic return to Hub
Quip refusing to storm the castle with pitchforks
-> automatic return to Hub
Return to Hub


Each quip in this dialogue has a place in the hierarchy. When we reach the end of a productive branch, we automatically go back to the hub. Perhaps some of the quips are only conditionally available -- we might not be able to ask about Fangclaw's bride until after we've seen the wedding invitations, for instance. Sometimes, too, we're forced to stick to a conversation thread until we've made a choice (as in the case where we either agree or refuse to storm the castle).

The advantage of a tree-based structure is that it's (relatively) easy to code, understand, and debug. The disadvantage is that it tends to a certain kind of design rigidity, and conversation flow is (as Ellison notes) seldom very realistic.

A range of other options open up if, instead, we regard quips not as branches of a tree but as atomic entities whose behavior is governed by prerequisite rules, and each of which is associated with one or more subjects. These prerequisites might be based on conversation state, the mood of the NPC, or details from the surrounding world model.

For instance:


Quip about origin of werewolves:
subjects: Fangclaw
prerequisite: none


Quip about wolfsbane:
subjects: Fangclaw
prerequisite: NPC trusts the player


Quip about Fangclaw's bride:
subjects: marriage, Fangclaw
prerequisite: player has seen the wedding invitation


Quip about making cake:
subjects: marriage, Fangclaw
prerequisite: immediately follows the quip about Fangclaw's bride


Quip about bridal registry:
subjects: marriage, Fangclaw
prerequisite: follows the quip about Fangclaw's bride, not necessarily immediately


Now we offer the player whichever quips are both relevant to the most recent subject(s) of conversation and currently available (according to their prerequisite rules). Saying a quip whose subjects are "marriage, fangclaw" might lead to other quips about marriage and other quips about Fangclaw.

Conversation can now flow naturally from one idea to other related ideas, just as it does in real life.




Restricting Choices in the Atomic Model

There will of course be times when the dialogue needs to be restricted a bit, as when we are going to ask the player to commit to one of a finite set of options (storm the castle or not?). It is still possible to enforce strict tree-like branching if we want it, by making a prerequisite that the quip immediately follows some other specific quip, and by placing special restrictions on what can follow the initial question quip:


Quip about Fangclaw's castle:
subjects: Fangclaw
prerequisite: none
followups: only quips that immediately follow this one

Quip agreeing to storm the castle with pitchforks:
subjects: Fangclaw
prerequisite: immediately follows quip about Fangclaw's castle

Quip refusing to storm the castle with pitchforks:
subjects: Fangclaw
prerequisite: immediately follows quip about Fangclaw's castle


When the player asks about Fangclaw's castle, he will be forced to choose one of the two answers before again getting unrestricted access to other quips.

This still leaves the question of what the player will see when he first starts a conversation with a given NPC, or when he has exhausted all the conversation on a given subject so that no natural transitions remain.

There are several possible approaches to this. One is simply to show all the currently available quips; another is to have select quips marked as conversation-openers, so the player can choose from those; a third might be to invite the player to start by choosing a general subject of conversation and narrow his quip options that way.

The best design will depend very much on how many quips there are in total for a given NPC. A sparse design with few quips can afford to show the player most of his options at once, while a dense one will have to prune heavily.




Managing Knowledge and Repetition

Compared with hub-and-spoke dialogue, the use of atomic quips means that the structure of the dialogue becomes less repetitive -- once the player has made the quip about the bridal registry available, for instance, he doesn't necessarily have to re-ask the questions that led him to that conversation option the first time.

But we are still left with a choice of how to handle quips once the player has used them once:

- remove them from play so that they're never seen again (fine if they're decisions to make; not so good if they contain vital information the player might need to review, unless that information is getting recorded in a game journal)

- leave them in place to be revisited (stiff and unrealistic)

- provide alternate "repetition" versions of the dialogue so that on subsequent occasions when the player tries this quip, the NPC shows he knows he's repeating himself (doubles [or worse] the amount of writing and voice acting required)

- remove them, but offer a general consolidated quip on this subject, so that the player can say something like "remind me of what you told me about Fangclaw's wedding" and get a summary of the already-spoken quips on this topic (requires dynamic generation of the summary dialogue; may not be suitable for voice recording at all)

Again, the selection of the best approach will depend a great deal on what kind of work the game is and how the NPCs are intended to function. Easy recall of past conversation is most important in games where NPCs are primarily dispensers of information and quests; unrepetitive and realistic dialogue is most important where relationships and emotional states are the center of gameplay.




Modeling NPC Initiative

Part of what makes NPCs feel shallow and non-human is their lack of initiative.

Games partially overcome that by providing them with goal-seeking behavior, the ability to traverse a map intelligently, and cut-scenes in which they start new action.

Conversations, however, too often remain purely reactive, with the player asking questions and the NPC responding. Occasionally, to shake things up, an NPC interrogates the player character -- an improvement, perhaps, but one that simply reverses the dominance of the conversation.

Either way, a 1:1 ratio of comment and response makes for an exchange that feels a bit mechanical and lacks the dynamic richness of real conversation.

In real dialogue, people convey a great deal not only by what they say but by their use of conversational pragmatics. Do they insist on getting in the last word? Interrupt constantly? Come back over and over to the same tired topics? Avoid answering questions?

Well-observed characters in books and movies have these characteristics, but game conversation systems are rarely equipped to provide this type of characterization.

One way to enliven NPC behavior and supply better guidance to conversation scenes is to have the NPCs recognize when a given line of conversation has reached an end and suggest a new subject themselves. Perhaps the player has just spoken the last available quip on the topic of Lord Fangclaw's wedding. The NPC might answer, but then (before the player has a chance to select another option) change the subject to the castle. Occasionally, as a special effect, the NPC might even refuse to answer one question and deflect it with another.

This makes a much more natural transition than forcing the player to choose to go back to a conversation hub. It allows the conversation system to model different kinds of characteristic behavior. A pushy NPC might obsess or nag about a single topic. A flighty one might change the subject frequently. A reticent one might volunteer less information than others.

If we allow NPCs to volunteer information and change the subject, we must also decide how the model will choose new directions of discussion.

Some of my games have used very explicit queuing -- e.g., if the player talks about Lord Fangclaw's bride, the NPC will as soon as possible ask about the bridal registry. In others, the NPC has a list of topics he wants to hit before the end of the scene, and will choose the next unexplored one each time the conversation seems about to grind to a halt. In still others, the NPC's motives and interests develop over the course of a scene, depending on mood or narrative developments.

In fact, these methods can be combined to provide both macroscopic and microscopic control over conversation flow.

It may seem dangerously open-ended to step away from a rigorously pre-programmed tree of options. In practice, though, it reclaims a great deal of control for the author. The player has the freedom to drive the conversation and doesn't experience an NPC's script as quite so mechanical as in a tree system -- but the author is free to manage the pacing by minimizing dull re-navigation of the conversation tree, adjusting how proactive the NPC is, and offering longer or shorter sequences of related quips.

Once some of these pacing issues are solved, the resulting conversation feels much more like a coherent scene -- and the NPC feels less like a machine.




Modality

Discussions of Facade's conversation system often look at the interface (parsing of typed commands) and at the underlying drama management, but pay less attention to the game's lack of a separate conversation mode. Speech mingles freely with the other kinds of action available to the player, such as movement towards or away from other characters, embraces, and object manipulation.

This makes a subtle but critical difference in the way the game feels and the way the non-player characters inhabit their space. When all conversation takes place in its own interaction mode and is separate from the other action of the game (which stops for the duration), the NPCs come to seem as though they primarily inhabit some other plane of existence from the player character. Non-modal conversation, on the other hand -- however it is handled -- allows characters to react to all the player's behavior as though it in some way contributes to the dialogue.

This kind of interpenetration between game world and dialogue world is not always possible. Regular game play may simply be too different from the interface used for conversation. Making NPCs aware of what the player is doing to the surrounding environment may also require extra content-generation, and sometimes that burden may be too great.

When it works, though, this method does a great deal to elevate NPCs from the status of objects to the status of fellow-participants in the game world.




Not all of these suggestions will be appropriate for every game, and I've really only scratched the surface of the possibilities in conversation modeling.

Notice, for instance, the immense assumption I started with, that a quip is an atomic unit made up of PC speech and NPC response. It doesn't have to be so at all -- as Facade demonstrates -- but working with a model where the input and output are not strongly coupled introduces a lot of additional complexity, and the narrative and game-play advantages are not as immediately obvious.

Still -- these are things we should be talking about. The craft of dialogue writing for games is only partly about choosing the right words. It's also about choosing the right procedures.

[Emily Short is an interactive fiction author and part of the team behind Inform 7, a language for IF creation. She also maintains a blog on interactive fiction and related topics. She can be reached at emshort AT mindspring DOT com.]


Related Jobs

Fun Bits Interactive
Fun Bits Interactive — SEATTLE, Washington, United States
[04.18.14]

Senior Engine Programmer
2K
2K — Novato, California, United States
[04.18.14]

DevOps Engineer – Core Tech
2K
2K — Novato, California, United States
[04.18.14]

Senior Graphics Engineer - Core Tech Team
2K Australia
2K Australia — Canberra, Australian Capital Territory, Australia
[04.18.14]

Senior Engine/Graphics Coder – Canberra, Australia










Comments


Bart Stewart
profile image
Excellent presentation!



Three comments:



1. The idea of replacing a relatively well-defined tree structure of quips with a looser collection of quips that broaden an NPC's conversational breadth sounds very much like the difference between procedural/imperative programming languages and declarative (http://en.wikipedia.org/wiki/Declarative_programming) languages.



In particular, I'm reminded of the declarative programming language OPS5. This language allowed the developer to define a collection of "production rules." With each tick of the clock, every currently valid production rule would fire. Depending on the results, some production rules would then go out of scope, while other rules would become valid, firing themselves at the next clock tick. This process would normally continue until a "halt" statement was encountered or no valid rules remained.



The literature on OPS5 (and declarative languages generally) might offer some useful notes on the opportunities and potential gotchas of an "atomic" model of NPC quips.



(Side note: One of the cool things about OPS5 was that it could actually create new production rules itself -- how interesting would a game conversation system be that allowed quips to build new quips?)



2. When several (perhaps many) of an NPC's quips in an atomic system are all valid, how should the system choose which one(s) to offer to the player/character?



3. When I play games with conversations (Deus Ex, Mass Effect, Fallout 3, etc.), I enjoy being able to explore every possible conversational path. I can do that because I can see each path -- I'll back up to a top-level node and cycle through every branch, restoring a savegame if necessary. This isn't so much to avoid missing out on collecting goodies as it is to enjoy all the dialogue written for a interesting character. I like exploring the personalities of characters, and being able to see every possible quip helps me do that.



So how would that work in an atomic system? It seems that when a production rule fires, it sets a value. Depending on that value, some conversation options are closed off while others are enabled... so how would a player backtrack through those in order to explore the possibilities? (This question is even more troublesome for console games without the PC's quicksave/quickload feature for restoring previous state.)



...



There is a larger question here of whether players who wish to do so should even be allowed to explore more than a single unidirectional path through a branching conversation, since this reduces the consequential effects of dialog choices as player character actions. But maybe that's fodder for another article. :)

Emily Short
profile image
1: My latest and best implementation of this system is built in Inform 7, which is a rule-based language with what sound like certain similarities to OPS5 (which I haven't encountered before now).



2: "When several (perhaps many) of an NPC's quips in an atomic system are all valid, how should the system choose which one(s) to offer to the player/character?"



You could mean two things here, and I'm not sure which, so I'll answer both.



If you mean, "how do we know what an NPC answers to a player's question?", the answer is that the atomic quip contains both the question and the answer. There is no process of choosing among several possible responses to a given utterance by the player. (This is not the only way to go about things, as the end of the article notes, but for many kinds of design it is less demanding than a system that selects freely from multiple NPC answers.)



If you mean, "when an NPC is allowed to change the subject, what determines what should be queued up next?", that's likely to change from game to game, and it gets into the AI driving the system. Sometimes I give an NPC a straight list of quips to work through during a given scene, but that's not the only approach.



In one of my games, I had an NPC who was trying to find out something particular, so the AI analyzed which facts the NPC knew so far and which he was most likely to want to learn next -- basically pathfinding through a network of facts. Then it selected a quip for the NPC that asked the question he wanted answered next.



We could also give quips metadata about what mood they're most suited for and then have the NPC choose whichever quip seems to best fit the current conversational tone, or... well, there are really quite a few possibilities.



3: "When I play games with conversations (Deus Ex, Mass Effect, Fallout 3, etc.), I enjoy being able to explore every possible conversational path."



One of the things that the atomic quip system can do is make it possible for the player to see more of the interesting content without having to approach it as a repetitive exercise. In a traditional tree menu, you have to traverse the content the same way every time. For instance if our structure is



quip A

quip B

quip D

quip C



Here A makes B and C available; quip B makes D available; and if you've chosen B, you can't go back and read C without cycling to the beginning again and saying A first.



The atomic system says that once C has become available, it can remain available (unless the author has some reason to take it away again); so after picking B, the player might have a choice of either C or D to say next.



There are contextual reasons to narrow the options (the NPC has just asked a question and a restricted range of answers is available; we've changed the subject; etc.), but in practice an atomic quip design can mean the player has access to a lot more of the content without having to get it in quite such a mechanical way.



This still doesn't guarantee that the player will see everything, of course, and you're right that sometimes the player might lose access to a given quip and not be able to retrieve it without reloading a save game. That's inevitable, though, if you want your conversation to have any sense of state.



It's also true that an atomic quip system doesn't lend itself to being completely understood by the player *as* a mechanism. From my point of view, that's actually a desirable outcome: I want the player to be able to see the parts of the game he wants to see, of course, and I want the conversation system to feel reasonably expressive; and I want the player to feel a sense of agency in that he feels his actions have an effect on the NPC. But I don't want the conversation to feel like a chore.

Reid Kimball
profile image
Good stuff Emily. I think of what you wrote as suggesting that NPC's also have their own conversation atoms and agenda's. A lot of conversation in games comes across as player-centric and not enough on the NPC's own conversation goals as if they were a real person to be given the same attention as the player.



The idea of emergent gameplay is a popular one, too bad we rarely talk about ways to make conversation more emergent. Have you seen your system create more emergent conversations? I think that can be a great way to further develop the idea that games can be a dialog between the "game" (designer) and player.

Robert Casey
profile image
Great article. This really hits home on the limitations that I see in current games (e.g. Mass Effect) and where I hope to see game interactions go in the future. Game play in single player RPGs and MMORPGs still feel very mechanical and scripted. Approaching more free forms of interaction with a world and its inhabitants, as well as allowing the player more freedom to have a long-lasting, persistent effect on the world, will be a significant step in the gaming experience.


none
 
Comment: