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.

12 thoughts on “Visualizing conversation

  1. I’ve only been loosely following Alabaster since the brunt of it happened at an awkward time for me, but I believe tools for the construction of interactive NPC conversation are the most fertile area for I-F development. Or video game development, for that matter. I’m eagerly anticipating what new Inform 7 extensions come from you as a result. While I can’t yet parse Alabaster’s graph (partly because the one pic of it I saw was too small to be read), I am quite familiar with Processing. I’ve been using it off & on for a little over a year, mostly for generating celtic knotwork — some of which I used for the IFDB style sheet — as well as prototyping some video game ideas which are both 3D and interactive….

  2. Ron, try using zoom in Adobe Reader and you should be able to get in close enough to start reading it.

    – I would also agree with your comment on npc conversation tools. Sounds interesting and I look forward to seeing what comes from this as a result.

  3. I’ll bet you a samosa that this kind of interactive browsing UI would be equally valuable for rulebooks and action sequences. Like conversation plans, they are a branchy, ad-hoc programming model where you can’t reasonably enforce any upper limit on complexity — there will always be one more special case. So you need high-level (clumped) views with the ability to drill down. But also ways to spot oddly non-local features (branches way across the diagram, unexpected exit points, …)

    Switching from the grandiose to the pragmatic: the most trivial way to improve readability of your diagram would be to line-break the phrases, so that the nodes were more circular.

  4. I’ll bet you a samosa that this kind of interactive browsing UI would be equally valuable for rulebooks and action sequences.

    That is possibly true; I hadn’t thought of it. I’m not quite sure what it should look like, either. But… well, hm. Hm.

    Switching from the grandiose to the pragmatic: the most trivial way to improve readability of your diagram would be to line-break the phrases, so that the nodes were more circular.

    Possibly. I am not sure how to make the .dot file introduce such line-breaks, though.

  5. I agree with zarf, the ability to have a zoomable interface to this kind of graph would be wonderful, because then you’d be halfway there to being able to author/edit a story by modifying the graph — which, as much as I love text editors, I think is a more intuitive approach to a tangly structure.

    I’ve never seen Graphviz before; any recommended tutorials on using it?

  6. Now that Alabaster is in beta, I went back made some updates to the graph generator:

    — introduced line-breaking within nodes. It does make the thing more readable (thanks, zarf and Erik!)

    — recolored restrictive quips and made brighter-red the ones that are restrictive and have no follow-ups. Unless such quips end the game, they are probably bugs that will get the player permanently stuck, so we want to draw the author’s attention to them. (There was one such bug in release 21 despite my looking at the chart to debug; my eye just passed over it because it could *sometimes* trigger an NPC followup, and the visual didn’t do a good enough job of distinguishing that situation from the quip having at least one legitimate reply.)

    — colored the arrows to NPC quips similarly: grey lead to things that the NPC *might* say later on, pink to things he definitely *will* say.

    — graded the coloring of ordinary quips depending on whether they’re listed or unlisted. yes/no answers when those are the only options are darkest grey, because even though there’s no “You can say yes or no” sort of message, the player is going to be forced to pick one, and typing TOPICS or trying to change the subject will get a reminder that yes or no is required here. Ordinary listed quips are medium grey, as before. Unlisted quips are light grey. These are usually either things that the player is going to have to figure out (as see the large number of light grey quips leading off the riddle quip) or things that just aren’t at all important to the story and are only there to flesh out the interaction (so there are a bunch of light grey quips that don’t tie into any conversation strand but just let you make small talk about physical objects).

    This combination makes it a little easier (though still not as easy as I’d like) to glance at the chart and see plot-important structures within it. An area with a lot of pink is going to contain a lot of restrictive quips and (possibly) mandatory NPC comments: these are going to be the most linear, scripted parts of the game, where there is something coherent that the player is supposed to get done in that passage. (The interaction with Happy is the best example in Alabaster).

    One failed attempt: I’d like to be able cluster subgraphs by scene and/or person speaking. That would introduce a lot more structure into the existing graph, by for instance isolating all the quips that are spoken to Happy or to the post-exorcism Snow White. In theory that should be doable in graphviz, and I tried to put it in, but as far as I can tell OmniGraffle is not trying to interpret my subgraph instructions at all. So that isn’t very helpful. Or maybe I’m just doing something wrong. May need to revisit this.

    There is still a lot more information I’d like to be able to extract from the graph, too, so I’ve been thinking more about my ideal Processing-based visualizer for this material. Some things I’ve been thinking:

    — It would be good to chart (on a different chart!) the quip/subject relations. I tried making a .dot graph of that too, but it comes out completely illegible because OmniGraffle is not very clever about how to clean up a graph where certain objects have such a large number of connections. A nice thing about Processing is that it’s great at handling information priority (e.g. by making one bit of text very large and another very small or by modulating line thicknesses between linked items).

    Dynamic presentation would mean the user could click to zoom in on the small bits if those were what he wanted to see. I think I’d want to be able to click on a quip or fact and have the screen zoom in on it while arranging its dependent quips neatly underneath; then I could click on one of those quips to move down the chart or (alternatively) click elsewhere to return to the overview mode. That way it would be possible to “walk” a conversation strand systematically if I wanted to.

    — It would be nice to be able to emphasize/deemphasize either the facts or the quips in a given graph. Reducing facts to dots would focus the player on which quips lead to which others; reducing quips and emphasizing facts would give more of an impression of information patterns in the game (though some games probably won’t use facts very much, so this will vary in usefulness depending on the product).

    And finally:

    — I’d like, if I can figure out how to do it sensibly, to use the same .dot format as input for Processing, even if I wind up stripping out a lot of color information and replacing it with more nuanced interactive display rules. It seems easier than building in two separate kinds of diagnostic output generators. But this may not be the wisest option; I still have a lot to learn about managing data files in Processing, and maybe it will turn out that using some kind of XML format would make the job too much easier to ignore.

  7. Re the issue with clusters in dot:

    Subgraphs in GraphViz/dot can definitely be a bit finicky. I’d be happy to look at one of your .dot files to see if I can spot any problems; just shoot me an email.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s