At GDC I picked up a copy of the latest Game Developer magazine, and then forgot about it until a couple of days ago someone mentioned that that very issue contained an article by Brent Friedman on conversation coding that mentions Inform 7 and TADS 3, as well as outlining his own system. HELLO. So I did a little luggage archaeology and had a look.
Friedman outlines (and provides code samples of) Conscript, a language he’s developed for scripting conversations.
First of all, for those curious about the IF coverage, what Friedman says is fairly brief, and potentially misleading. For both TADS 3 and Inform, he describes a way conversation might be implemented in that language, while implying that it’s the sole way possible — footnoting, for instance, just one of the numerous I7 code examples on the topic.
All the same, I was happy to see IF mentioned as a place where this work is being done, and also happy that Friedman didn’t feel the need to explain in detail what IF is. (But then, I got the impression from GDC that modern IF is a bit better known among professional developers than I would have expected.)
Second, as to Conscript itself, I had mixed feelings.
It looks to me like a sensibly-motivated attempt to step away from the explicit dialogue tree structure (and Friedman talks a bit about the dialogue scripting systems at both Bethesda and BioWare, which was a bit of behind-the-scenes information I enjoyed reading). Given that this is more or less what I was arguing for in my GDC talk, it’s nice to see someone else working on this project.
A lot of the features of Conscript are things I recognize from my own and other people’s IF experiments. The data object that Friedman calls a topic (but I would call a quip) can have lines for the NPC to say, the ability to set flags for future reference, the ability to make itself invisible after being said once (a basic ‘don’t repeat this’ feature), and conditions governing whether it is available. The flags look to be largely global and special-cased, though; I think I would miss the ability simply to tag a piece of dialogue as “used”, or track abstract factual knowledge in a more systematic way.
Conscript also has the beginning of another feature I think is important, namely the ability to move the conversation on with NPC speech once the PC has tried all the viable options. But in Conscript, this is hard-coded in a way that is hard to generalize or to use for complex situations: each quip can end in the instruction to goto another quip, which then fires only if its conditions are satisfied.
This works fine as long as one is sticking to a fairly tight structure of branching and reconnecting trees, where the player’s only freedom concerns the order in which he asks the questions available at the current moment. While there are ways to make a topic that functions as a switch to introduce further subconversations, this is also all hard-coded, and in fairly opaque terms. (At least, I think I would find it frustrating to deal with large amounts of dialogue coded as
condition pc["current quest"]
= "MQ_01"
goto conversation "Quest1"
= "MQ_02"
goto conversation "Quest2"
…and so on.)
So I prefer a system that abstracts some of these ideas: a dynamic way of figuring out whether the player has used up available quips and is ready to have the NPC move on, together with a function that determines what subject change the NPC wants to initiate next. This would have the added advantage of stripping out a lot of gotos and control elements from Conscript, making the system less fiddly to write for.
Bottom line: Conscript is sort of reinventing a wheel that IF has already invented multiple times — but in a mainstream context, so that’s a good thing. The language so far looks fragile, confusing, and underpowered, but first attempts are often like that.
Emily Short's Interactive Storytelling 
Thanks for this article. I’ve done some of my own research comparing conversation systems (primarily because I’ve been playfully working on my own CYOA/Visual Novel system recently).
I was wondering if you have had a look at ChoiceScript, yet? It’s intended for CYOA games, of course, but it’s another example to add to your collection of examples out in the wild. A cursory glance at Conscript seems to reveal to me some surprising correspondences.
Once I’ve got it better documented, I’d love to hear your thoughts on my own little hobbyist project (“KeyLimePie”). Mine has been a project of constraints (there’s a cliche somewhere along the line of “creativity is often enhanced given enough constraints” or something, at that’s been part of the reasoning in the project), so it may not be that interesting to you. I’ve been having fun with it, though. It’s also more inclined towards the CYOA/Visual Novel spectrum than the IF one, which has been one of my constraints.
@Max, if you have time, I’d love to see a blog post comparing/contrasting KeyLimePie with other visual novel systems like ChoiceScript and Ren’Py.
I hear that Emily’s GDC talk was not kind to “dialog trees.” Emily, do your remarks apply equally to CYOAs and visual novels?
(It seems to me that there’s a lot of unexplored space in this format—but then, I would, wouldn’t I?)
I wasn’t really addressing CYOAs, but to clarify what I was hard on in my talk: I don’t think conversation flow or plausibility are well-served by simple branching (and rejoining) structures. It’s not the UI of offering a player specific choices that is necessarily the problem; it’s the lack of a sophisticated underlying model to determine which choices *should* be presented.
Certainly, Dan. Here’s a start for the comparison conversation:
http://blog.worldmaker.net/2010/mar/24/first-slice-keylimepie-part-2-script-breakdown-and/
I am using Choicescript right now for my game project and love how easy it is to use and how I feel like I can do just about anything with it. http://www.choiceofgames.com/blog/choicescript-intro/
Emily, I wish I had seen your talk. The game I’m working on addresses exactly your last comment. It uses a CYOA style UI but the underlying model is based on presenting choices determined by the player character’s personality traits.
Is your talk available online, by any chance?
It’s in the GDC vault, which isn’t likely to be very helpful unless you happen to have an All Access pass to this GDC. However, the slides (minus the exposition that goes with them) are linked from here:
http://aigamedev.com/open/coverage/gdc10-slides-highlights/
Slide 8 makes the case against dialog trees, unfairly IMO.
You only get “lawnmower” conversations or NPCs who repeat themselves when you allow the player to climb back down the tree: to go back to an earlier topic, to repeat their questions, or to change topics freely.
So don’t allow that. Once you reach the leaves of the tree, the conversation stops.
True dialog trees, like CYOAs, notoriously give the author too MUCH control. As an author, I think that’s a much better problem to have. :-)
I agree with Dan, the “lawnmower” effect is not necessarily a “required” product of branching conversation design. Repetition can be pruned in the writing and design processes, regardless of whether branching is the underlying conversation model. Additionally, I think adding consequences to conversation choices helps discourage players from playing that way (regardless of conversation format, ultimately).
If you have a simple linear or a very short branching plot within a CYOA, yeah, it’s probably true that you can make every conversation end at the leaf nodes with no possibility of reentry.
However, that’s not a very useful model for a game that handles its narrative elements more dynamically, especially if the player is free to re-enter conversations with characters, or work on quests that might require him to revisit information from previous discussions. That describes many of the commercial games that include interactive conversation. It didn’t seem apropos to talk about CYOA or visual novels at all in this context, really, and I only had 20 minutes.
As a separate point, a strictly branching, no-repeats CYOA presentation is not modeling conversation any more than it’s doing world modeling. It’s modeling *narrative flow* — and in a pretty limiting way. I’m not saying that nothing useful can be done in that format, but I personally prefer more procedural approaches to the same problems, in the interests of creating more complex output, more granular player interaction, and more scalable designs.