Emily Short: Conversation Methodologies

Yes i agree its necessary to have realistic communication styles in games but thier complexity diverts the attention from it and in most of cases it lags.Infact it is in mind from few months so hoping that in future it will get rid off.

I was a bit let down by that article, because Emily basically repeated what she criticized in the intro, just one level lower than the surface. First, she mentiones that the “interface” basically can be adapted rather flexible as long as the underlaying structure is flexible enough, and she explicitely mentions the relevance if metadata (read: machine-understandable) is associated to messages.

Then, she goes one level below the surface, and ignores her previous arguments, by describing “dumb” (dumb as in “the machine doesnt understand it”) datastructures with almost no metadata.

Sure, the interface is important. Sure, how you design the conversation control-flow is important. But both are trivial compared to the question, how the actual decision logic of the AI is supposed to work…. but wait: There is none in her examples, because the AI is simply crawling hardcoded paths without understanding why it chooses a given direction at a crossing.

hehe.

I think conversations need to be at least partially pre-written to be interesting (at least until AI advances a whole lot). I liked the approach of final fantasy 2j and some of the ultima games, where you learned keywords which you could ask people about, and they’d have specific text in response to specific keyword questions. It’s at least somewhat realistic (in real life people do answer questions with some type of stock response that’ve used in the past whenever someone asked them about something), and it’s easy enough to code and write for, and it’s underused and interesting in the games that have used it. As you go through the game you learn more keywords which you can then go back to older NPCs and ask them about the new words.

“Then, she goes one level below the surface, and ignores her previous arguments, by describing “dumb” (dumb as in “the machine doesnt understand it”) datastructures with almost no metadata.

Sure, the interface is important. Sure, how you design the conversation control-flow is important. But both are trivial compared to the question, how the actual decision logic of the AI is supposed to work…. but wait: There is none in her examples, because the AI is simply crawling hardcoded paths without understanding why it chooses a given direction at a crossing.”

Fair enough — there is a lot more that I could have said, but did not have room to get into (the column was already pretty long for this format anyway). But to summarize a few brief answers to your comments:

1. You can’t do much AI until you have a control structure that gets away from the pre-written conversation tree. So this is a pre-requisite.

2. Once you’ve done that, there are several respects in which AI becomes relevant. One is in choosing what sorts of things the player is allowed to say next. For this purpose, even the small amount of metadata I describe is adequate to do some interesting things. (I do hint at this in the article, I think, but perhaps don’t hit it hard enough to make it clear why this is important.) My system chooses new options to offer to the player on a context-sensitive basis: if we’ve run out of things to say and are changing the subject, the player might get allowed to pick any new quip that is marked as a conversation starter (ie, doesn’t follow on an existing quip). If on the other hand we’re still in the midst of a thread, he might be recommended only quips that follow from the previous couple of comments. (That means that there’s some flexibility to go “back” to an idea that was raised earlier, while preserving a fair amount of context.) And sometimes if there are too many conversation starters to offer all at once, the game recommends the ones that have some subject-matter overlap with the current quip.

3. How much and what kind of AI you want to drive NPC behavior depends *hugely* on what kind of game it is. Even the minimal metadata I describe — knowing what quips lead to which other quips, and what subject matter is associated with what quip — allows for some pathfinding for when the NPC is allowed to change the subject. For instance, the NPC is given a target quip, something he wants to say, but isn’t allowed to say it until he has mentioned whatever prerequisites there are, having found a route through other quips to that point. It would also be possible to use mood metadata (how will this make the PC feel?) to tag quips, and have the NPC turn the conversation based on the desired emotional effect.

4. Elements such as how much the NPC interrupts are managed (at least in my system) at a different level from the conversation data structure. I’m using Inform 7, which is rule-based, and there is a set of rules that the game follows each time the player selects new conversation.

Ordinarily these rules follow this order:

1. print the player’s part of the quip; (1a) notice if the player has changed the subject significantly

2. print the NPC’s part of the quip

3. if the PC is out of things to say that follow on this but the NPC does have a quip to discuss, add a beat (some intervening text such as a gesture, atmospheric grounding in the location, etc), then print the NPC’s new quip.

But the rules can be replaced, or new rules inserted in the sequence.

This means that in addition to having the data that represents “normal” behavior in quips (what is the default way for the NPC to answer this remark?), I can do things like

— using the hook at 1a: have the NPC react with some additional dialogue if the PC’s choice of quip abruptly changes the subject

— by inserting a rule between (1) and (2): arrange it so that the NPC will refuse to give his half of this quip until the PC fulfills a condition. (This might be a one-off rule for a specific quip, or I could tag a whole bunch of quips with “confidentiality” metadata that puts them off limits until the NPC trusts the PC.)

— by adding a rule before (3): set it up so the NPC will use further goal-seeking to determine whether there is anything else he ought to have queued up to say

— by changing the rule at (3): arrange things so that the NPC will aggressively change the subject every turn to what he wants to talk about if the PC isn’t cooperating, regardless of whether the PC is done exploring his conversation thread; or, again, the NPC will be listless and make no attempt to advance the conversation

…and there are various other possibilities that I haven’t had occasion to experiment with yet. Conditions within the quip data also make it possible to change responses based on exactly what the previous quip was; this allows for more smoothly written transitions.

This is all a way of managing complexity; similar complexity could be achieved, as you suggest, with a stack of processes to follow, but “getting out of control” is a genuine concern, not just at runtime but in terms of making sure we understand the possible behavior of the system at design time.

Finally: I’m really interested in storytelling, and this means I tend to be a bit cautious about how much and what kind of NPC AI I pack in. It’s possible to create an NPC that acts in interesting ways but doesn’t advance the narrative at all. So most of my recent work has focused on how we get the NPC to pick up slack in the game play, keep the pace moving forward, make sure that a given scene hits the points we want to hit, and so on. That does not at all mean that the scene will be uninteractive or without agency for the player — the player may have quite a bit of influence over how things wind up.

Other people may have other design goals and want to go in other directions with such systems.

Hi Emily,

thanks for taking the time for the detailed answer. To be honest, after i wrote that post i thought that perhaps i looked at the article a bit too much from my POV and therefore took a few things for granted. To me, the interface and the control flow are quite “straight forward” topics, which dont require that much explanation besides of a quick summary of some popular models. To others however, it may be that this topic isn’t that obvious and therefore the article would be useful to those people.

Just a quick comment on your Point #1, before i get to the meat of my reply: I may be missing something, but at least in the design phase (so, before the implementation), it may very well happen the opposite way around – i.e. one’s own requirements regarding the AI, may drive what kind of control flow features onerequires. Sure, in the implementation, you can of course not do anything before you programmed the control flow, true.

Now, to adress the rest of your reply: You mentioned that what kind of game one wants to program, what kind of interactivity one wants to allow, strongly influences what kind of AI is needed.

I think that this is an understatement :-) What kind of game and interactivity one wants to create really changes everything about all aspects: Interface, Control-Flow, Datastructures, AI-Style.

For example, most game developers are interested in the well understood concept of “linear plot games”. With linear i here do not necessarily mean only one path – in this case, what i mean is more like an approach to gamedesign in general. An approach in which most aspects of the game are quite static and predefined. This also applies to most IFs: They set up a carefully designed plot, and then only allow a low amount of strictly controlled variety. The game plot is “engineered”.

Most games also do not require very deep interaction. There may be a handful of topics per NPC, with each of those not being very deep. This is sufficient for most nowadays games.

However, both does not apply, when what one seeks to create is more similiar to Galatea (as is the case with me). I dont know for certain details about your development process of it, but my estimation from the infobits which i could get, is that as galatea became more and more complex, all the bookkeeping about topics, all the crossreferences – and especially doing this in a language which wasnt really designed for something like this – was probably a nightmare to you, or not?

If yes, then i guess you maybe understand that to a person who wants to create deep and complex character interaction, the conventional approach of static tree-structures, and fixed decision logics is – to put it carefully – inefficient.

Such people probably weren’t the target audience of your article. I understand that. I just wanted to explain to you why on first sight i was underwhelmed by the article – not necessarily because it was an uninteresting article to most people, but because it was less interesting to people who are mainly interested in “going further”.

– Lyx

You’re right, of course, that this isn’t the only possible conversation flow model, and that others would be better for other kinds of AI approach. (One thing I point out at the end is that the idea that every PC quip should have a corresponding NPC quip is itself a *huge* assumption — one that wouldn’t work at all for something like Façade.)

That said, I’ve found that the model I outline there has been the most robust, of the things I’ve tried, and amenable to having a variety of other logic added on. I’ve used it, or some slight variation, in a number of different projects with different requirements, and it has proved able to handle a number of different effects, ranging from the very plot-centric to the very open-ended.

The model I described here is the great-great grandchild of Galatea’s: similar in some of the things it’s trying to achieve, such as a move away from the static tree conversation and towards more conversational flow, but significantly easier to program and more sophisticated in what it can do. If you see it as a “static tree structure”, then perhaps you haven’t understood — or I haven’t explained well enough! What I describe is a way to record and track the relationship of data needed for conversation flow, while still allowing the player a great deal of freedom (especially if this system is hooked up to a text parser like Galatea’s where the player can choose topic keywords).

Galatea’s model did have some primitive ability to queue things for Galatea to say, but didn’t handle them very systematically, and usually it was set up so that she would only speak her queued dialogue if the player was silent for a turn; thus many players never encounter these alternative directions.

The model in Galatea also did not separate topics (things the player could ask about) from quips (specific exchanges about the topic), which meant that it got kind of messy coding alternate answers if the player asked multiple times about the same thing. Many pieces of Galatea’s logic are just a tangled mass of if-statements and flags attached to each conversation topic.

So while the model I used then was (barely) manageable for a game of that size and ambition, it would not have worked for anything bigger; it also makes Galatea a pain to maintain and would be completely unsuitable for any kind of collaborative work. So I wouldn’t quite say that it was a nightmare, but I would say that that process revealed the inadequacy of the Galatea model.

If you’re interested in what this kind of structure has produced, my most recent project is the collaborative game (ie, jointly written with other authors) Alabaster; it’s not in official release yet, largely because it needs an accelerated interpreter to run acceptably fast on a Mac; such an interpreter will I think be available soon, at which point I’ll give the game an official release push. But otherwise it’s essentially done, and you can download a copy here:

http://emshort.home.mindspring.com/Alabaster/

The source text linked from that page is not the absolutely most recent version, but it’s close enough that you can also see how the source is structured and how the rules are written.

The metadata does get more complex than the article outlines — for instance, quips also determine their availability based on whether the player knows certain facts, and facts can be set by multiple quips or even when the player makes observations about the external world.

Anyway, you’re right that I was writing this article for people who were probably not familiar with Galatea, and from the perspective of trying to convince a reader that the proposed structure would be useful in a traditional PC or console game that used dialogue menus and had some kind of narrative agenda in mind.

But what I’m outlining is exactly the kind of code I would use if I were building another Galatea-like work.

“Yes, the article gave me the (wrong) impression, that the outlined structure is not just a means to keep track of conversations, but rather a fixed “script” from which the player can not break out, unless he follows the defined “paths”. Thanks for pointing out that this is not the case.”

It isn’t, but I should also point out that the amount of apparent freedom one gets from this system will depend a lot on the UI chosen.

A menu-based UI will force the player to select from a choice of options. This will still be more dynamic than a script, because the menu is being chosen from all the quips that are currently appropriate, so you get something more fluid than the tree script.

A parsed UI may also allow the player (as Galatea and Alabaster do) to choose a completely different topic to bring up. (Or wait, saying nothing; or do something in the gameworld that has significance to the conversation…)

“Lets say the flow of the game plot is majorily influenced by mood and similiar things – so far that it is more important than the event-prerequisites… how would one deal with this? Creating seperate quips for each possible “state”? ”

Well, that depends a lot on what you have in mind for how the conversation should be influenced.

If you want the player and NPC to say roughly the same things but with different intonations depending on mood, that is a complexity that I would put into the quip itself. (Alabaster does this, in fact — there’s a sort of markup that lets it select alternate phrasings depending on the mood of the major NPC.)

If you want completely different flow depending on mood, then yes, I would use different quips, and I would make some quips have a mood prerequisite: we can only get into the “date” thread of conversation if the NPC is feeling romantic, say.

That said, in my experience it is very rare to write a conversation where no quip in the conversation refers to or depends on something said earlier. As soon as you have that situation, you need some mechanism to express the dependence — either by saying “quip Y comes after quip X”, or, more abstractly, by saying “quip X reveals fact F; quip Y depends on fact X”. The latter structure may appeal to you more because it comes closer to procedurally representing what is “really” going on in the conversation. In practice, though, I find that most of the time it’s enough to do the dependencies at the quip level and only represent as abstract facts a smaller group of things that will come up over and over in conversation.

I don’t think the post was really intended to be a book on conversation systems covering all aspects of them, so I think it’s unwarranted to be upset it doesn’t cover some things and focuses on interfaces.

And I agree that the early IF system where you use ASK and TELL also is a good example of what I meant. I agree that you can’t really produce “scenes” out of that, in the sense of story progression, but conversations are not really “scenes” — a conversation is often just a conversation, not a plot point. Most of our conversations in real life don’t progress the story. I think if you want to model scenes, you need a scene-modeling system rather than a conversation-modeling system.

Okay, i guess i should give a more practical example what i’m talking about.

Let’s say, the NPC gets a behavioristic model, in the form of 4 variables. Those variables are not to be treated as seperate from each other, but instead form a 4-dimensional space. Think of it as an emotion-space, except of that it also contains aspects like creativty, analytical intensity, etc.

Each event/quip sends an impulse in that 4 dimensional space to the NPC. The NPC has a short and longterm memory of impulses received.

The relevant feature now is this: When deciding how to react, the NPC can take past quips/events, the just send impulse, short term memory impulses and longterm memory impulses into account (not necessarily all of them, but if he wants to, he can).

In other words: The NPC not just keeps track of events, but also keeps track of his emotional experience with the player. That experience includes mental abilities, “mindsets”, character, etc – all via that 4D map.

Now, some background: Conventionally, most IFs make AI-decisions dependend on past events. As i mentioned, an AI doesn’t really understand an event – the Author has to tell the AI everytime. With every new event which you add to the game, you need to ask yourself “how does that affect the other quips already in the game? Do i need to add more exceptions?”.

Of course, we cannot completely get around about that problem. But my experience so far is, that if your game mainly deals with relationships, it often is not/less the case, that past events really are important, but rather the mental relationship which the NPC and the player have. So, in such a case one gets the luxury that quips can become “autonomous” in that as long as the AI can do maths with past mental impulses, you often can add new events/quips without worrying about the already existing ones. The code-complexity doesn’t increase in such a case.

As for the scope of difference which the mental state can make: It’s practically unlimited, and it of course depends on the severity. Just saying something “sweet” or “serious” may only make a difference in phrasing (though, not necessarily), while kissing the NPC or attacking him may make a strong difference. However, from a code-aesthetics POV, it isn’t really elegant to partially put them in the same quip and partially put them in seperate quips.

Thank you AmnEn. This is one of the rare moments where i feel understood ;-)

Emily, just to clarify: I never wanted to imply that event-tracking is unnecessary, but that if relationships are central to the plot, much less event-checks are necessary. Since with event-tracking, we’re potentially talking about exponential growth in complexity, that IMO is quite valuable.

Anyways, yes, i’d be happy to inform you once that project has reached a phase where a preview makes sense. This may however take a few years, because it is a sideproject on which i only work when i’m “idle”. I’m only seconarily involved in designing games. My primary projects deal with philosophy (then again, considering the the “theme” of the described “game”, one could as well call it philosophy, or a game? or a chatbot? Or interactive introspection? Sounds familiar? ;)

Thank you for the interesting info, Emily.

*off for today*
– Lyx

I think there is now more content in this comment page than the actual article.

Looks like the tree of the information examples got flattened. You probably get the idea (not that it was worth much when represented properly).

My opinion is that if you need anything more than a dialogue tree, you aren’t thinking like a storyteller or a player – you are thinking like a programmer. That’s great. I like programmers. But even with the most complex conversation system in the world, but the end result will reduce down logically to a dialogue tree. It’s like fractions. You can work real hard to get to 4/8ths or get 1/2 with less work, which you’ll end up with anyway.

“I’ve heard people say this a couple times, yet from all the interaction I’ve had with gamers, it’s clear to me that people generally prefer more advanced AI. Have you gotten a different impression?”

My impression is that people generally want their AI to behave in ways that appear plausible within the given setting (to the player observing), while still secretly orchestrating things to make sure the player has a good time.

Understandable response Emily, thanks. Conversations do often have beginnings middles and ends, and sometimes have a topic. I don’t think those alone will make conversations more interesting though — it may just reach an uncanny valley where the player feels like the conversation makes less sense and feels more awkward because it’s closer to how people normally talk but not yet there.

I also still think ease of coding is an important factor, especially for an indie game developer. If a game only has one programmer, there’s only so many lines of code they can write per day, and if the conversation system alone takes tens of thousands of lines and achieves not much greater of an effect than the ASK/TELL system would, it might just be wasted effort. It’s good to do for experimentation to expand the medium and all that, but I’m not sure anything more complex than the ASK/TELL system is practical for most indie developers right now (unless conversation is whole point of the game and not just something you do with npcs occasionally). You probably know this already though, but just putting my thoughts about it into words.

@Unhelpful Stranger, Squidi: This seems pretty obvious to me, but there’s a *huge* gap in complexity between the usual conversation with an NPC, and any tiny sample taken from this single thread of comments :) Could you think of a way to model conversation flow that even resembles this? BTW, Squidi, extreme reductionism is a mental trap that often results in you dismissing a whole subject, please don’t do it :P

I remember once seeing a “dev interview” showcasing a “breakthrough” in AI, and basically the enemies saw the player through a window and went around a “complicated set of corridors” to catch him. They showed the waypoints that were placed by the level designer. I was like “WTF?!”.

@Paul Eres

“I liked the approach of final fantasy 2j and some of the ultima games, where you learned keywords which you could ask people about, and they’d have specific text in response to specific keyword questions.”

While it’s a good way to pass information about well-defined topics, I often found myself sleeping as a clicked past dialogues in Ultima. Simply adding options for what you will actually say (and the way you say something) makes it a bit more interesting… but yes, I guess in 1990 having 20 topics to ask a character was great. :D

I think the real question is why people are hell bent on wanting games to be like real life. Sometimes just sitting down and playing a game is great – not sitting down and playing a cold, re-created version of what you were just doing before you sat down.

Also, conversation relies a ton on what’s not said too. Good luck programming that.

[quote]I’ve never heard of developers toning down AI because it was too good in genres where it’s highly relevant, such as strategy or complex action games.[/quote]

You’ve never heard of, say, skill settings in a chess game?

[quote]Also, you can’t speak in terms of mere “appearence” with respect to AI; it affects the actual game state.[/quote]

That’s the point. The main purpose of the AI is to keep the game state interesting to the player by any means necessary. The secondary purpose is creating the appearance of acting like autonomous people (to whatever degree is appropriate for your chosen level of disbelief-suspension).

@Anthony Flack:

“You’ve never heard of, say, skill settings in a chess game?”

That’s the *player* dumbing down the AI, with the developer giving the *option*. And for the near-entirety of strategy and action games, that option is unnecessary, as the best AI that can be practically implemented at this time is still pretty daft. Maybe in another 5 years or so we’ll have reason to start worrying about AI that’s too smart for .

“That’s the point. The main purpose of the AI is to keep the game state interesting to the player by any means necessary.”

The most direct means, and the one that allows a coherent world, is for the AI to be as smart as practical. I don’t dispute the first part of that purpose, but I’d formulate it as “to vastly expand the state-space”, such that the player has a more interesting world to interact with. In a game where failure is present, and the player is repeatedly failing, I believe the game should let them do so. If the player does not learn from the failure and therefore cannot correct it, then either the mechanics or the player’s mind are to be indicted. It’s not AI’s failure for refusing to ease off.

In general, I don’t like anything I’d call “abitrary” or “whimsical” in games, and AI that treats the player as a patron is one of those things.

@Anthony Flack:

“You might want to make the game as challenging for the player as possible, and you might want to make the AI as cunning and strategic as you can in order to do so. But it IS entirely for the player’s benefit.”

That’s very close to my point: good AI which acts completely in its own interest generally provides the most interesting and intellectually stimulating set of challenges, within games where interaction with AIs is relevant. Enemy AI should try to “win” (whatever that constitutes) against the player because it’s for the player’s benefit. The alternatives, as far as I can think of them, lead to dull challenges, incoherent worlds with poor causality, or an overabundance of exploitable weakness within the AI.

“You wouldn’t, for example, want to make a FPS game where all the enemies on the level huddled together at the start, formulated a strategy, and decided the best thing to do would be to wait in ambush and then all rush the player at once.”

Right, that would be an instance of the AI being too clever for its domain. Perhaps if it was a non-linear FPS the same intelligence would be appropriate.