In part 1 of this short series about adventure game dialogue, I used one of the first conversations in The Secret of Monkey Island as an example of the complexities involved in creating dynamic and believable dialogue in an adventure game.

In it, I mentioned that I might have accidentally become distracted by building my own dialogue editor. (If you’ve been following along with my journey into adventure games, you may be noticing a theme.)

The Alternatives

I did have a look into other dialogue editors and came across a few apps that do a similar thing. Both Chatmapper and Articy:draft 3 offer a high level of functionality and have advanced features such as Unity support, audio support, and script export. Unfortunately, both are expensive, subscription-based, Windows only, and seem to be targeting big game studios rather than small indie shops with tight (or no) budgets.

Then there’s an excellent open source app called Yarn which is much simpler than the other two. It uses a syntax that is based on an older version of Twine, itself a candidate. Both of these are free, easy to use, and Mac compatible.

While Twine is very feature rich, its aim is to create complete games that you can easily publish online. Using it as a dialogue editor is possible, but the format it outputs would require some serious parsing.

Yarn takes a lot of the node-based usefulness from Twine and makes it a lot more focused around game dialogue writing. It also offers outputs in more useful formats, but it lacks support for many features that I’m keen on seeing in a dialogue editor for adventure games.

I do like the visual clarity of its node-based system and it’s a lot less technical and cluttered than the commercial offerings. It would be relatively straightforward to just use Yarn and then simply write a parser for the JSON it outputs.

This is what I should be doing.

I am not doing this.

What I Want From a Dialogue Editor

Based on my observations in part 1, these are the things that I would ideally like to see in a dialogue editor tailored towards adventure games:

Support for triggers: I plan on using special triggers within the dialogue that, when discovered, pauses the running dialogue and causes the dialogue system to call back to the game engine to inform it about a state change (e.g. moving a character to a new location or running a specific animation). This separates the concerns and avoids inlining complex code blocks within the dialogue itself.

Built-In Testing: I’d like to be able to have a way to quickly test dialogue within the editor itself (in the short term, with animated avatars, but in the long term with support for the actual animated character sprites or models that might be used in the final game). The hope is that this will give a feel for the flow of the conversation without having to create a new build of the game.

Support for variables: Ideally, the editor should have some basic variable management to make adding and checking variable states easy and less prone to typos.

Repetition Management: Having automatic support for showing one line the first time through a dialogue tree and a second on subsequent times (“Nice to meet you!” vs “Nice to see you again!”)—a common feature in adventure game dialogue—would save cluttering up the text with lots of variables.

iPad Support: I like writing on an iPad.

With all that in mind, things will get technical in part 3 when I start developing my new format.