Tuesday, October 28, 2014

On branching dialog editors and narrative design tools


I was prototyping a game concept with branching dialogs for conversations and/or CYOA story events, so I started looking at various solutions on the Unity Asset Store. Dialoguer looked the most decent, but generally all of them just made too many assumptions or enforced bad workflows, and seemed to ignore what made Twine so accessible.

So I've decided to make "Bramble", my own editor plug-in and system for Unity! Here are some factors in its design:
  • No node types = more flexibility. Almost all the systems on the asset store enforce a menu of "node types" that determine functionality. I think this is ignoring one of Twine's main strengths, where a passage is just a passage, and there's no special button to create a "branching passage" or a "logic passage." If you want a passage to do something, you just tell it to do that, you don't need to switch types or whatever.
  • Use node references to link nodes, instead of node titles. I think this is one of Twine's bigger weaknesses -- that you have to title a passage before you even know what it's about, so ideally you'll change the title a few times as you write and revise -- and yet that passage title is the key to linking to it, so renaming it breaks all links to it! This type of text-based link punishes you for renaming or reorganizing your work, a holdover from Twine's heritage as a hacked wiki system.
  • Resizable nodes. This is another one of my peeves with the Twine interface... double-clicking on a passage to read and edit one word is annoying. I understand they wanted to limit the busyness on the screen, but sometimes I want to be able to see a node's entire contents at a glance. Some nodes will be more important than others!
  • Simple mode and complex mode. Dialoguer has an "advanced" flag for a node that shows or hides additional options... I want to expand on that idea for an entire interface. Sometimes I will want to do a "stub pass" at narrative structure, rapidly creating nodes and connecting them and putting in placeholder text. A "simple mode" would hide variables, hide logic, hide anything unrelated to creating and connecting nodes and filling them with text. For some users, this will be all they want.
  • Take the node's position in the graph into account. If we are organizing these nodes spatially, then why are we ignoring how important that space is? I'm thinking of a "connect to nearby nodes" button that will automatically create links for every neighboring node within a certain radius, or a "relax" button that automatically re-organizes your nodes as a force-directed graph. These space-dependent tools need to make better use of space.
  • Use procedurality beyond if/else statements. Again, I'm a big fan of Elan Ruskin's GDC talk on Left 4 Dead 2's procedural conversation system, especially how he defined a metric of "specificity" as a node that requires the most states and conditions. So, a node that requires 3 variables to all be equal to TRUE would be more "specific" than a node that only required 2 variables to be TRUE. The result is a very simple AI that changes the narrative based on the world state, with graceful fallbacks if specific conditions aren't met.
  • Incorporate testing tools. We are creating a graph structure, why don't we actually do stuff with that? Inform 7 has a tool called "the skein" that constructs a sort of temporal web of player actions as you test your design, and you can rewind or fast-forward through it. I understand it a little bit as a sort of pseudo unit test, given interactive fiction's MIT roots. What if there were automated tools to see if the player could "path" from one node to another, or run 100 random trials and give you the most common end result? Why don't we think of narrative design as a structure that we can test and engineer?

I think narrative design in AAA has suffered greatly from a lack of cross-pollination and intersectionality. Instead, it seems more like a culture of assimilation, of well-meaning but misguided workshops about teaching novelists or screenwriters or playwrights "how to write for games." I imagine the technical instruction in these workshops usually consists of the words "use Excel" and some quote from Sid Meier. They can't imagine writers having roles other than "auteur director with near-complete creative control" or "low level script grunt who has to write 20 different ways for ex-military mercenary NPC to tell the player he has low health", and it seems like there is very little in-between (or at least, very little they are willing to discuss)

So a lot of my thinking on this comes from skilled practitioners who share their workflow openly -- specifically, Emily Short's excellent reflection on writing her IF "Bronze" has been super instructive and helpful for me. If we want to design better narrative design tools, we should actually look at how skilled practitioners are doing narrative design and study their workflow. Notice how Short re-arranges events and geography constantly? A robust narrative design tool should support this type of flexibility and iteration.

At the same time, "the answer" is not going to be found in one creative community alone. I think a contemporary approach to narrative design should look at parser IF, choice-based IF, hypertext editors, multiplayer first person shooters, wikis, detective novels, word processors, screenwriting writing software, music... If we want games to be intersectional and reflect several different communities at once, then maybe we also need to apply that methodology to game development tools as well.

Telling writers to "use Excel" is the useless rhetoric of self-proclaimed programmer-kings who see narrative as interchangeable text strings instead of worlds or systems unto themselves. Let's do a little bit better than a spreadsheet, shall we?