Category: Conversation modeling

Alabaster feedback

As Alabaster is in large part an experiment with the underlying conversation system, I would very much welcome feedback about how the system behaves so that I can refine it for future use.

As background: how much the system prompts the player is already an adjustable feature (up to turning off quip prompts entirely, for a standard unprompted ASK/TELL experience). Likewise, it will be possible in the final version of the library, though not demonstrated here, to use a numeric menu to offer the player options.

So what I’m particularly interested in at the moment is how to improve the player experience when the game is using the same library settings as Alabaster. Some things that have come up already:

A common misapprehension seems to be that it’s necessary to retype an entire quip name verbatim, whereas in fact the game parses quip names in the same way that it parses object names: the first few words of the quip, or any unique word, will do. The system does not, perhaps, do a good enough job of teaching new players this fact, especially when the tutorial mode is turned off; so perhaps there should be a mechanism to notice if the player is typing in very long commands and mention (once) that these can be shortened. (Also, perhaps, to point out that the whole ASK INTERLOCUTOR ABOUT structure can be shortened to A.)

I’ve also had a request for tolerance of spare question marks (which some players find themselves typing even after an indirect question such as ASK ABOUT WHETHER SHE IS COLD).

Another point is that Alabaster doesn’t give good feedback when the input is

>SNOW WHITE, [valid quip name here]

In general, I’m not sure I want to encourage players to approach things that way because it encourages them to think there’s actual natural language processing happening — which there isn’t. But there could be better error messages in response.

Anyway, comments are welcome; it would also be useful to have transcripts that demonstrate interaction with the game, since these would provide also some idea of how often commands are failing, and what kinds of commands. If you have one you’d like to send in, I’d appreciate it: emshort@mindspring.com.

Conversation Methodologies

My latest Homer in Silicon column is a bit of a departure from the norm: instead of offering a critique of a game or set of games, I discuss conversation modeling methods, in an attempt to share some interactive fiction theory with a wider audience and to encourage more discussion about conversation modeling in general.

ETA: there is some further discussion of the ideas at TIGSource.

Information Flow and Gradual Characterization

Ran across an interesting post from Krystian Majewski on design problems with multiple choice dialogue, which, among other things, draws on some play-testing reports on Emerald City Confidential:

[Playfirst] did a user test of the indie point-and-click adventure Emerald City Confidential and they described how casual gamers reacted when they first encountered a multiple choice dialogue. You might think that point-and-click adventures are a good match for “casual players”. Well, when faced with their first multiple choice dialogue, most players simply froze in panic. They assumed that one of the answer as “correct” while others would lead to failure. From the kind if information they received, they couldn’t really anticipate what would happen. Even worse, after they decided, they didn’t receive a clear feedback on what effect their choice had. They were used to the transparent feedback schemes of most casual games and weren’t able to cope with the uncertainty.

I found this really interesting, because I would have assumed, in general, that a simple multiple-choice presentation would be more accessible to casual players than some other mode of interaction.

Majewski goes on to argue in favor of consistent verbs representing standard strategies usable at every dialogue point. At any given time (for instance) the player might have the option to respond intellectually, sensually, or in a religious way — a strategy that reminded me a little of the dialogue system in Forever Always.

I’m not sure how much application this has from an IF perspective. Certainly the core IF audience tends to have different expectations about how dialogue will work, so is probably not completely frozen by a menu. Moreover, it’s possible to write menu dialogue in such a way that it gives more of a hint about the likely effects; the writing and cluing of the player determines, to a large degree, how much agency it feels like one has. At the same time, I generally agree that menu dialogue feels more distancing (to me) than parser-based dialogue, even if the latter is heavily clued with hints about what the player can say.

One of Majewski’s commenters adds:

Real dialogue flow should be such that no specific choice matters too much, but the sum of the choices does. But as you’ve mentioned this is just a nightmare from a design perspective.

I’m not sure it has to be so bad a nightmare as all that, and it’s been done. To pick the obvious example, in Blue Lacuna… (very mild spoilers, and discussion of a WIP of my own, follow the cut)

Continue reading “Information Flow and Gradual Characterization”

Visualizing conversation

When I was first working on Inform 7, one of the things I was a bit skeptical about was the map index. Yeah, it was cute, but did I need it? As a real IF designer, wasn’t I perfectly capable of keeping my own notes and maps? And wouldn’t it perhaps exert an undue influence on designers to use a square-grid map, just because that’s what indexes best?

The latter point may be a fair complaint (though at the same time I am kind of in favor of comprehensible map layouts). But I was totally wrong about the first point. When I wrote the early speed-IF version of Bronze, I was able to put it together quickly only because I could add rooms, refer to the map, see where the holes still were, add, recompile…

Primitive as it is, the graphing ability of Alabaster is proving reasonably useful too. The graph isn’t especially pretty — I don’t know whether I’d get something better out of Graphviz than I can get out of OmniGraffle and a .dot file — but it conveys a lot of useful information. In particular, it’s possible to glance at the graph and find bugs that might take hours of testing to detect in the game. Colored nodes show where conversation dead-ends. Lines that go to the wrong places show where some connection has been screwed up in the system.

The main problem is that this image is (a) insufficiently eye-candy-ish and (b) too big. With Alabaster we’re approaching 300 conversation quips, and I suspect we’ll exceed that number before it’s done. Which isn’t really surprising — that’s about on a scale with Galatea, and though Alabaster has fewer avenues of conversation, each individual one can be pursued in more depth, so the balance comes out similar. I think this will turn out to be a fairly normal, not-at-all-extraordinary size for a conversation game. So clearly the fact that the graph is getting ugly is a problem.

I’ve been thinking on and off about what I want to do about that. I’m eager enough to finish primary coding on the game that I haven’t gone off to investigate new graphing options — the current graph provides enough diagnostics to do what I need it for — but I’ve been thinking on and off about what I think it a conversation-visualizer should look like and do in an ideal world. The fact that Processing 1.0 was just released has also been affecting my thinking. Wouldn’t it be neat to be able to view a conversation tree as a dynamic structure, something you could zoom into or away from; or to be able to pull one piece of the conversation tree away by itself to view it in more detail; or to switch visualization modes and instead see a chart of which facts and subjects were most important, or which quips functioned as gate-keepers by providing access to large portions of the rest of the conversation tree? In fact, mightn’t such a tool actually be useful for optimization problems too (since it would make it easier to discover where the conversation tree could profitably be broken into chunks for the purpose of limiting the search range)?

But I’m focusing on finishing the primary coding, oh yes.

The beat issue

Conventional writing advice encourages using beats — descriptions of character action and reaction — to provide variety from an endless stream of “he said” and “she said” tags. This is great advice, but it can be kind of annoying to implement in IF, because any time you describe a character interacting with the environment, you have to make sure that

— the description fits the current world state; the character isn’t adjusting a pair of spectacles he’s no longer wearing, or looking at an item that the player already put into a locked safe in the other room.

— the description correctly modifies the current world state: if the character moves, dons, doffs, or breaks something, that is reflected properly in what we see thereafter.

— the description fits the character’s mood and personality; not every character should draw from the same pool of gestures, and an individual character shouldn’t repeat himself too often. Every character needs his own gestural vocabulary.

— the description reminds the player/reader of the environment, and physically grounds him in the location. In lots of IF, it’s hard to get away from location — interacting with it is all there is. But in very chatty IF, it’s possible to lose all sense of place and start to think of the characters as two floating heads speaking in a vacuum.

— the description contributes to any ongoing action that is supposed to be happening in the scene (if, for instance, the character is supposed to be in the process of performing some task or other); since IF dialogue can happen in various orders, we have to decouple the dialogue from whatever other thing the character is doing.

— (subtler) the description is not too distracting from the dialogue. Sometimes we have descriptions of characters taking independent action which would be fine on their own (if that’s the only thing that character is doing this turn) but which are too detailed or long-winded to fold into the flow of other dialogue.

There’s no one-size-fits all solution to these problems. In Best of Three, I was most concerned about grounding the player in environment and in communicating the NPC’s mood to the player, so I gave the NPC a series of postures. A change in mood would trigger him to change his posture, and the change from one posture to another was a source of beats.

In other contexts, it can be useful to be arrange beat elements in a linear way rather than as a state machine: e.g., with a table or list of beats representing each stage of the action the NPC needs to be performing during dialogue. In I7, it’s sometimes useful to use small scenes to represent the stages of NPC behavior — since multiple scenes can be running at a time, the NPC’s actions can be tracked separately from any scenes that have to do with dialogue.

Whatever approach I take, though, I almost always find that it’s good to have some special model whose job is to provide the content of the beats, and for the conversation quips to refer to that model most of the time. There are of course always exceptions — sometimes a piece of dialogue just has to be paired with a specific gesture or expression, and that deserves to be hard-coded — but the more flexible model allows for livelier dialogue overall, and a more complete sense of place.

Edited to add: see also Talking Head Avoidance Device.