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"]
goto conversation "Quest1"
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.