Creating branching story tools for an indie game

Our game A Dragon Named Coal revolves around branching storyline from player’s decisions. To create such a thing we needed a visual tool that turned story into game programming. AAA game companies like Bioware and Bethesda have many engineers to build such an application. Seeing as we have one developer at Clever Crow, this is too much to handle. We solved the issue using a game CMS known as Articy: Draft.

A simple demo of our chat system and how it branches with dialogue.

A simple demo of our chat system and how it branches with dialogue

Pre-built game CMS

We quickly found when working with Articy: Draft that it demystifies branching storylines. Everything is grouped into nodes that can be modified like a flow chart. As it comes prepackaged with node templates to get you started.

How we created our story mechanics

For A Dragon Named Coal we built our storyline with several major nodes (dialogue, instruction, condition). We then broke these into sub-sections (bookmark, inventory, quest). Currently there are over 15 different kinds of nodes (and growing) we use. Here is a quick breakdown of the important ones and how we used them.

branching story flowchart

One of the first quests for A Dragon Named Coal. Each color represents a special node type


Used to display character text and images for conversations. Creating dialogue with these nodes is far easier than doing it in your code (which creates a massive mess). And much better than doing it with an Excel Spreadsheet.


These indicate a choice is available for a player. Think of them as the options in Skyrim or Mass Effect. Recording choices from hubs can give you lots of data to tweak your story’s progression.


Think of instructions as programming nodes to do repetitive tasks. We use them to manage inventories, activate special scenarios, save particular data, set conversations the next time you talk to a character, and many more things.


If you’re a programmer you’ll notice that these are just if / else statements in disguise. For those of you who aren’t a programmer they evaluate data in the CMS, such as if you have a certain item. Depending upon whether the answer comes out to true or false the story can move in a different direction.

How we organized our game’s assets


We also use Articy: Draft to organize our in-game assets. These range from collectibles, to characters, and even inventory item images. Since everything is given a unique ID through Articy, we use those in our game to display titles, manage properties, and execute behaviors.

Important notes on Articy: Draft

While Articy: Draft is an amazing game CMS (and the only thing out there like it). You should keep a few things in mind.

  • It writes data, not code (you have to do that yourself)
  • It may prevent you from releasing a level creator with your game
  • It doesn’t make waffles in the morning
  • Only works on PC, no Mac version at the moment
  • Learning curve of about 5 – 15 hours
  • It only exports .docs, .xlsx, and .xml

Speaking of the last point about exporting. That was a huge issue for our HTML5 game. Because we needed JSON serialization.

Converting exported XML to JSON

Articy exports XML and we needed JSON for our app. To overcome this I built custom middleware called ADNC Tools. It allows you to write XPath to get XML. We then export the results into nicely pre-built JSON files.

adnc tools

Custom XML parsing app to generate our game’s JSON

The app uses a combination of node profiles, file names, and pre-built functions to parse everything into JSON. Its fast, efficient, and easy to tweak for our needs. You can definitely build such a middleware in significantly less time than it would take to recreate Articy: Draft for your game. I think it ended up taking about 50 hours to create.

How it was built

ADNC tools is built on Rails with MongoId and Nokogiri primarily. Although you could build something similar with any language. Just needs to have good XML and XPath support.

Programming our branching story

All packaged JSON is loaded into our game at run time. We then lookup everything we need by unique ids when we need it. For each node from Articy draft we process them a bit differently from the inventory items. We lookup the node type and template properties. This data is how we know to process our different nodes.

Conclusion: Anybody can do this

With awesome game CMS tools just about anybody can add branching storyline to their game. Even with HTML5’s limitations we’ve added it. If you have any questions about how I programmed this please ask in the comments below and I’ll happily respond.

No comments yet.

Leave a Reply