Designing Branching Narrative

In the past I have talked about technologies such as Inkle, Undum, Twine, and there are others I haven’t really mentioned: ChoiceScript, StoryNexus, and Varytale, which all use branching narrative with some world state variables as their form of interactive storytelling. Now, if you’ve read Chris Crawford on Interactive Storytelling, you know what he thinks of branching narrative (AKA Choose-Your-Own-Adventure); and he’s right. Branching narrative is a bit too simplistic to be the holy grail of interactive storytelling, but it is the most common form of interactive storytelling today because of its accessibility. In this post, I will attempt to break down the process of designing and writing a branching narrative, and point out some ways to write more complex branching structures. I will also link to other blog posts or articles that I have found useful when researching this topic.

The Branching Narrative

The simplest nonlinear stories use a branching structure; you start at the beginning, are given several options, and those options lead to new choices, which each lead to new choices…this can go on forever, but there is a point where all of these branches become too expensive. If you are writing a branching narrative, similar to one of the old Choose-Your-Own-Adventure books, your story structure might look something like this:


This is called a branching tree, and as you might imagine, with each choice, the amount you have to write increases exponentially. If you were going to write a story with ten choices, two options at each choice, you would have to write 2^10 (which is 1024) branches. That’s a lot of writing. Add one more choice to the game, and you have to write double that: 2048.

To combat this complexity, you can create a foldback structure, where the player has choices, but these branches eventually all lead to the same place. This keeps the number of branches you have to write to a manageable number, but it cheats the player out of making meaningful decisions. What is the point of choosing one path over another, if they both eventually lead to the same conclusion?


So, how do we get the expressiveness of a fully branching narrative and the compactness of a foldback structure? One method that many systems use today is World State.

World State

Tracking a world state allows the writer to create more advanced branching narratives, without writing thousands of nodes. A choice can set a variable (such as true/false, or increase by a factor of 1, etc.). Then, later on, when text is being printed by the computer, it can check that variable and print different text based on the value of that variable. This can limit the choices available to a player, or simply change whether the player character is described as a “he” or “she.”

For example, let’s say you have a story where a certain character can either die or be rescued in one scene near the beginning. This can be set as a variable: Bob_Dead = true. Later on down the road, you write a scene where some of the main characters are sitting around a campfire talking about their tough times. If Bob_Dead is true, then one character might say, “I really miss Bob.” If Bob_Dead is false, then Bob might say something, and nobody will lament his death, because he’s not dead.

You can imagine it like this:


As you can see, earlier decisions affect later decisions because of variables. If the variable is a number that can be increased and decreased, then output can be varied even further. For some interesting results, you can use a number as a chance variable; the higher the variable, the higher your chance of succeeding. Be careful with using random chance, however; you can get some unintended and frustrating results.

Most branching narrative systems today allow variable tracking and conditionals, such as Undum, InkleWriter, ChoiceScript, and Twine.


Choosing Variables

Choosing the proper world state variables is a large part of creating a state-based branching narrative. If you use too many variables, they will get jumbled up into a big mathy mess that is confusing and difficult to work with. It is best to choose a small amount of variables where each variable has a known and defined use inside the branching narrative.

Some variable types:

  • Skills
  • Personality
  • Morality
  • Status
  • Resources
  • World state
  • NPC variables

There are many other types of variables that can be used, but before you blindly start coding variables into your branching narrative, make sure that you know what they are going to be used for and how they are going to be used. Some variables can be simple boolean values, but some should be numbers or strings.

It is very easy to write too many variables into your story on the first draft, especially if you are making it up as you go. However, the more variables you write, the more you will have to remember, and if you have variables that are similar to each other, then they may conflict at some points in the story. For example, if you have a Strength variable, and a Number_of_times_pumped_iron variable, you can probably imagine how these variables overlap. A simpler solution would be to just replace Number_of_times_pumped_iron with Strength, and increase that variable each time the character pumps iron. Otherwise you might run into a situation where there is a strength check, and although the character has a high Number_of_times_pumped_iron score, if their Strength score is low, they will fail the test.

A good resource to read on this topic would be the chapter on Personality Models in Chris Crawford on Interactive Storytelling, especially the second edition. He talks about creating variables with little overlap, while retaining the highest amount of utility. This is called orthogonality, so remember that when you’re googling.



Storylets are basically little snippets of narrative that the player can see, depending on a world-state. For example, if each storylet were a chapter, chapter one would always be visible, and choices inside chapter one would set some qualities that cause other chapters to be visible. Then, when the player returns to the contents, they can choose from the available chapters. So each storylet is a separate narrative, but it influences which other storylets are available and what happens inside them.

A good example of a story using storylets is Bee, by Emily Short. I would definitely recommend reading/playing through it, then reading the two articles linked to at the end of this section.

Two main systems that use storylets are Varytale and StoryNexus. You can probably simulate storylets in InkleWriter, Undum, and Twine, but they aren’t set up explicitly for that.



What choices you make available to the player will largely define how they percieve your story. The choices have to be broad and interesting, but they also have to be manageable from the writer’s perspective. I have played a lot of branching narratives that have pathetic choices; if you’re only giving the player one choice at the end of each story node, then you should ask yourself if you really need a choice there at all.

Choices need to have some effect on the story, otherwise there’s no point for them. They could change some relationship variables, start a new branch of the story, or give your character some advantage that will come in handy later in the story.

The player should also have some idea of how the choice will affect the story. If the player clicks an option, and something completely random happens and changes the story, the player will get frustrated. This is a very common problem; even many high-budget games struggle with this issue. Mass Effect is notorious for this; you may choose an option that seems like a simple question, but then Shepard goes crazy and starts violently interrogating someone. After several playthroughs, I have a pretty good idea of what the writers were thinking, but my experience doesn’t help any first-time players.


Planning with Graphs

Before you open up your branching narrative editor of choice, you should do a little planning. Hopefully you already know about your world, your characters, and some of the possibilities that can happen to them, (if you don’t, read this earlier post) but now you need to start designing the actual branches of your narrative.

The idea behind this is similar to that of The Snowflake Method for writing a novel; you start with the broad strokes, and you add detail later.

Step one: create a high-level storyline that connects all of your main scenes (or storylets, if you’re going that route). Overall, this high-level storyline should be fairly linear; it doesn’t have to be, of course, but adding a lot of branches at this point will mean that you will be writing a lot of content that must be connected to nodes inside of other scenes, and this adds more variables to keep track of…in short, if you want to confuse yourself, go right on ahead. Branching narratives are not easy to create; however, if you plan carefully before you start writing, you may save some headaches later on down the road.

The purpose behind this step is to come up with the overall plot of your story. Yes, branching narratives have a plot, but it branches. Figure out how your story will begin, what things can happen in the middle, and how it ends.


Step two: zoom into each node of the previous graph, and start adding some branches within that node. These nodes can have as many branches as you want, but they should all end up at the same place. Don’t worry; since you have world and character state variables, you can change the text depending on their values. This means two players who end up in the same place may have very different experiences when they get there.

This is where you can really start to add some complexity to your story; figure out the main choices the player can make, and how they affect the world state and future decisions. Write down a list of variables you think you might need, and cross off any that you find you don’t.


As you can see, to get from one main storyline to the next, there are a lot of little options that can branch amongst themselves, but they have to all come back together to one or two main locations.

After this, you can sit down and start writing. You may need to rethink your outlines as you write, if you find problems or decide to add more detail, and there’s nothing wrong with that. As long as you have a roadmap and know where you’re (generally) going.



Whew, that’s been a long one. I hope this brief (yeah, right) overview has helped you somewhat. My intent was not to cover the topic exhaustively, because there is a lot involved in not only planning a branching narrative, but writing prose in general. That is why I added so many links; if there are any subjects you would like more information on, they should help.


More Interactive Storytelling Today

A while back I wrote about InkleWriter, which is a web-based editor for Choose-Your-Own-Adventure stories. Since then I have tried out some other software such as Undum, Twine, and some IF languages such as Inform 7. I would like to just give a brief overview of the different options for writers interested in interactive storytelling, taking into account the ease-of-use and feature set.


Undum is like the big brother of InkleWriter. It is a JavaScript library that helps the user write CYOAs that are similar to Inkle, but also more advanced since you have the power of JavaScript and any JS libraries you would like to use. I encourage you to visit the website and play through at least some of the tutorial game. It explains what exactly Undum is and some of what it can do.

My main dislike of Undum is the fact that it uses JavaScript. I understand that this allows Undum to run fully in the browser, and JavaScript was probably a great language back in 1995, but I’ve done enough programming to know that JavaScript has a terribly painful syntax. All those braces, parenthesis, and semicolons everywhere just cause suffering for the average programmer. I suppose you could use something like CoffeeScript, which I would highly recommend, but because of this I would have to say that Undum is not for the writer who wants to make interactive stories easily. For that, use InkleWriter; it has most of the useful features, and it’s a million times easier.

Now that I’ve scared off all the script kiddies, if you’re some tough-as-perl programmer who eats regexes for breakfast, then you’ll probably love Undum. It does give the user a lot of control over how their story is formatted and printed, and you can use JavaScript to customize anything you desire. The documentation isn’t great, and there aren’t any beginner tutorials, but the source code is out there for you to peruse.

A good example of what’s possible with Undum, a little creativity, and some JavaScript know-how, is The Matter of the Monster by Andrew Plotkin. Take a look at the source code, and I guarantee you’ll learn something about Undum and JavaScript in the process.


Now, for those of you who were offended by the rampant use of JavaScript in Undum, you’ll probably love Twine. It’s a great little program that allows you to graphically create CYOAs similar to Undum, but without all the coding. The final product is compiled into a single HTML file that can be uploaded to the web and played by anyone. It doesn’t give as much control as Undum, and by default it doesn’t look quite as good, but the editor is simple (and dare I say fun?) to use, and can be learned in less than 5 minutes. Don’t believe me? Skim this tutorial and tell me you don’t know everything about Twine. Besides using over 50 exclamation points, that tutorial covers most of the basic and advanced features of Twine.

There are quite a few games that have been made with Twine, so I encourage you to check them out.

Inform 7

Inform 7 is a programming language specifically for writing Interactive Fiction (IF, aka text adventures). But it isn’t like your daddy’s programming languages; Inform 7 uses natural language to define how your game works. It is almost ludicrous how easy it is to get started with Inform 7; however, mastering it is another matter. Inform 7 may be easy to start with, but using it for something even remotely complicated takes some willpower.

I have to say, in the time I’ve spent using Inform 7, most of it was spent just writing. Whenever you want Inform to do something, most of the time you can just write what you want it to do, and it works! Magic! But when it doesn’t work, it can be…frustrating to figure out why. The IDE that comes with Inform is pretty nice, but debugging is a thing of the past. If there’s an error in your source, Inform will inform you of where it is, but you still have to figure out how to fix it.

Despite the (few) downsides of Inform 7, it is currently the most popular IF programming language, and has been used by many authors to write many games. The documentation is very detailed, and there is no shortage of tutorials for getting started. There are also forums where you can ask any n00b questions.

Other IF Languages

If you’re interested in interactive fiction, but don’t fancy the natural language syntax of Inform 7, there are other options. Inform 6, for example, is an entirely different beast than Inform 7. 6 has syntax similar (or so they say) to C/C++, with all the fun brackets and semicolons. It gives you more control than I7, which can make debugging easier. Since it is older, you’ll have to do a little digging to find all the software you might need to develop in Inform 6. Start with the old Inform 6 website, then use Google if you need anything else.

TADS 3 and Hugo are other options. I’ve used Hugo a little bit, and from what I’ve seen, it’s incredibly easy to learn and it also has a pretty nice syntax. I haven’t used TADS 3 at all, so I will hold any comments, but I have heard that it’s nice too.

The Choice

To me, the advantage interactive fiction has over CYOAs is the simulation aspect. Interactive fiction games create a whole world model, which includes not only the location of objects, but how they interact with each other, and how the player can interact with the world. CYOAs have basically no world model; they are simply text. In this scenario, print this text; in this other scenario, print this different text. There are no characters, no rooms, no objects; just text and links between text. The advantage of CYOAs is that they are usually easier to write, and easier to play/read. The user just clicks on a link and the next part of the story appears, whereas with IF the player has to actually use their brain and type something. I think a lot of the decision between IF and CYOAs is the intended audience. If you want your story to be accessible to pretty much everyone, then a CYOA tech such as InkleWriter is probably a better choice than an IF system.

In the end, the decision is up to you. I wrote this in the hopes of exposing some systems that otherwise might have gone unnoticed. If you are really interested in creating some type of interactive story, then check out each of the programs I talked about and see which one strikes your fancy. You can always start with something simple like Twine, and move on to more complicated things later.

Interactive Art


A lot of people have argued that video games are not art, because they allow the player to change the story. This somehow changes the original author’s ability to make any kind of important point through the game. One reason I think this is funny is because so many games have linear stories, which the player cannot change no matter what they do. My other arguments against this view will take some explaining, so prepare yourself.

One quick point I would like to make is that games obviously include art, such as 3D models, textures, music, cinematography, voice acting…all of these are considered art on their own, but the fact that they are put into a game somehow negates the possibility that the whole is art. If we look back, film was the same way; it took people a while to consider film to be an art. Games are the same way, and eventually I think Interactive Storytelling will also have it’s issues with being accepted by the public.

I see art as the way that people (sometimes called artists) express what is inside of them in a way that people outside of them can understand. Think of it this way: a person has an idea inside their head, such as a story, and art is how they choose to express that story. They could use good ol’ prose to express themselves, or they could go with film, or graphic novel, or even video game.

That’s my definition of art. I understand that it is very broad; seen this way, pretty much anything could be considered art. But is that wrong? Should we limit what is allowed to be considered art? Some things are easy to place boundaries around, such as the Sciences, but art is not something that we can measure, such as a volume or mass. art is a part of humanity, and humanity is infinitely complex. Therefore art is infinitely complex.

I would be interested in hearing how you define art. Leave a comment, and let me know.


Oh no, it’s that word again. Did I ever actually promise that I wouldn’t use it anymore? whether I did or not, here it is. So what does premise have to do with art?

Premise could be one of those ideas that a person has in their head, which they want to express to the world. Maybe they’ve gone through some life-changing event and want to show the world that life’s short and we shouldn’t wast time hating people. Rather than writing some blog post about it that nobody’s going to read (can you detect the sarcasm?) they put it in a story about a person who’s perhaps gone through the same life-changing event, or they could do something more subtle, such as show the futility of hating people, and the benefit of loving people.

The use of premise in an interactive medium, such as video games or interactive storytelling, is no different from the non-interactive mediums. This is a topic I have already discussed at great length in another blog post, but it is worth repeating. The author of an interactive storyworld can express their premise through characters the player can interact with, or the world the player is in.

The World

A writer can say a lot about their worldview just in how they create the world of their story. Think of something like Star Trek; no matter what the characters chose to do, the world was always the same, and it expressed some very foundational truths (in Gene Roddenberry’s eyes) about life, the universe, and everything. Ideas such as humanity is important, people are basically good, there are aliens out there and they evolved from primordial goo; whether you believe any of this or not, it is obvious that the creators of Star Trek did, and they wanted to express that not only through the stories and the characters but through the world itself. A sci-fi universe with aliens and one without will both express very different views of how the universe works.

Games such as Mass Effect and Fallout do this as well; no matter what your character chooses throughout the game, you cannot change the basic worldview of the people who created the game. There will still be aliens in Mass Effect, and people will still be basically evil in Fallout 3.

The Characters

The premise can most definitely be expressed through different characters. Sometimes a single character embodies the main premise of a story. A story about an underdog that succeeds is going to be very different than a story about an underdog that fails.

Think of characters such as Frodo in The Lord of the Rings or Luke Skywalker in Star Wars. Both of these stories would be very different if Frodo was an adventurous mountain man or if Luke was an old oracle. The character of Frodo shows that even small (short?) people can save the world. Luke kind of shows the same thing, but a little different…I’ll leave that discussion up to you.

The point I want to make is that characters with different personalities can personify different premises, and they don’t even have to be part of a certian plot, but if put in the right setting, a character can make a huge difference.


I hope this post has cleared up some confusion about art that is interactive, such as video games and interactive storytelling. I’m sure some people will disagree with me, and if you do, leave a comment! I am curious to hear other people’s opinions on this somewhat controversial topic. Hopefully we can learn more about each other’s views through this interaction.

Book Review: Chris Crawford on Interactive Storytelling, Second Edition

Chris Crawford on Interactive Storytelling

I recently finished reading the second edition of Chris Crawford on Interactive Storytelling, by, well, Chris Crawford. It was very good, and I thought it made a lot of improvements over the first edition which was published way back in 2005. The second edition brings updates which discuss Storytron, the successor to Erasmatron. Chris also dedicates more page space to discussing other forms of interactive media, such as Interactive Fiction, Role-Playing games, and video games in general.

He talks a great deal about the different methods of interactive storytelling, but spends most of the time talking about the best methods in his “Arrogant Opinion.” His words, not mine. He talks about personality models, where he presents a model which is slimmed down from the one presented in the first edition.

This edition cleaned up a lot of the slower parts of the first edition, and organized the chapters in a more coherent manner. It is a good introduction to interactive storytelling for anyone who is interested, but doesn’t really know what it’s all about. I would highly recommend it if you’re interested in this sort of thing.

Chris Crawford is a fantastic writer. I love his cynical, grumpy old man style, which I think is a lot how he is in real life, although I’ve never met him…yet. Sometimes he can go off on a ranting tangent, but most of the time he has control of himself, or his editor made him tone it down a bit. He mentions this in the introduction. If you want the uncensored Chris Crawford experience, just check out his website:

He also tells a lot of entertaining stories which make the book more enjoyable, and he uses very helpful and informative examples. Mostly they are from movies such as The Lord of the Rings or Star Wars, but at least most readers would have seen one or both of these and understand the examples.

What I most liked about this book was that he simplified a lot of the ideas that were a little too complex in the first edition. And of course this edition is updated to include his most recent foray into interactive storytelling: Storytron. It doesn’t explain how it was a failure; for that, check out But it does explain how it was supposed to work, and he does that quite well.

He doesn’t spend nearly as much time talking about practical methods to pursue interactive storytelling; probably because there really are none. He encourages experimentation, although some could argue he doesn’t encourage it enough. Some times he will say that one way is the only way and all other ways are stupid, but then later he will say that he couldn’t get that way to work. It can be a little confusing, but my suggestion is to just ignore those comments and get what you can out of the book.

He also updated the section on existing Interactive Storytelling technologies, removing some of the older, dead projects, and including some newer active projects. He discusses Comme il Faut and Prom Week, and also mentions the IRIS project. He talks about how he thinks these projects succeed, but also how they fall short. He talks down about a lot of things, but he always has good reasons to back himself up. If he doesn’t, he apologizes for it, but beats it down anyway.

Because of the cleaner organization and the updated information, I would highly recommend this book to anyone who either bought the first book already and has read it, or hasn’t read it but is interested in interactive storytelling. Chris Crawford’s book is a great introduction to the subject, and it is a fun read as well.


Dwarf Fortress

 I think we can all agree on one thing: the more complex something is, the more time it will take to make, and the more likely it is to fail. In a previous post I quoted Chris Crawford when he said, “Storytelling is infinitely complex!” In this post I will talk about the necessity to simplify things, so we can actually get something accomplished.

By the way, that quote was in a talk he did at Mesa Community College. If you want, you can watch the video on YouTube. I highly recommend it, because it is a very good introduction to interactive storytelling, and it’s only one short hour. He even makes some jokes!

Why Simplify Things?

First I would like to explain why I think we must simplify interactive storytelling. There are two aspects of interactive storytelling that we could think about in relation to simplification: how the user interacts with the software, and how the software works under the hood. For now, simplifying both of these aspects is important because it will be easier to implement, and simplifying the interface will allow more people to use the software. I’m not saying that people are generally stupid–I don’t really need to, do I?–but people are more willing to try something out if it is easy to use. Also, if the software is difficult to use, then that breaks the immersion.

There are some people who enjoy really complicated things, but these people…I don’t understand them. The problem is, not everyone can really get into complicated, convoluted games, because they don’t want to spend the time. I try to understand that, so I want interactive storytelling to be simple because I want people to actually give it a chance. I don’t want it to be like programming or worse…math.


In order to simplify a complicated process, you have to focus on your goal. Only amateur game developers say, “I want to make a zombie survival simulation game, where you have to eat a certain amount, and sleep, and drink water, and you get tired if you walk or run too much, and each zombie has their own hunger meter, and you can build shelters and cook all different kinds of foods and I want there to be five hundred different types of enemies and all the weapons known to man and I want the world to be like 100 miles square….”

Yeah, probably not going to happen. I’ve seen people post in forums about things like this…it’s kinda scary how many people do this.

If you want to make a zombie game, you can’t just throw in every zombie-related feature you can think of. Unless your goal is to purposely make it complicated, then don’t make it complicated. Keep It Simple, Stupid! (That’s the KISS principle. I didn’t make it up.) The user should not have to read a big long manual before they can use the software.

You must ask yourself what you want to accomplish with the software. Not necessarily what you want the user to do, or even what you want the software to do, but what you want to do with the software. If your goal is too general, e.g. “Be fun,” then you won’t be able to focus very much. You have to have something more specific. So if you are making a zombie game, you want to focus on the aspect of zombies you most want to portray; survival? Horror? The psychological effect of the zombie apocalypse and how people react to it? Once you have decided your goal, make sure that everything you allow the user to do is related to that goal. If it isn’t, cut it out. If you are focusing on the relationships of a group of survivors, don’t put too much combat into the game. It isn’t about the combat after all; it’s about the people.

I’m not saying that there can’t be any combat in the game, I’m just saying it’s not the most important part, so minimize it. While Frictional Games was designing Amnesia: The Dark Descent, they experimented with adding some combat to the game, but they found that it wasn’t having the right effect; it wasn’t scaring the player. It either bored them, or it frustrated them. Neither of these responses was the right one; they were supposed to be scared, and you’re not scared when your frustrated or bored.

Interactive storytelling won’t only be focused on the emotions it can elicit, but it will have another focus: proving a premise.

I know, I know, I promised to stop using that word so much. OK, theme, then? Tomatoes, tomatoes. Oh, this is text, so you can’t hear how I’m pronouncing…nevermind. To-MAH-toes. There.

Anyway, if you were writing a story, and you wanted to show that people could overcome their fear in the face of disaster (zombie apocalypse), then you wouldn’t spend a lot of time describing how they foraged for food and fought off some zombies, and had to keep collecting ammunition or they would run out, etc. You would have these in the story, but you wouldn’t spend a lot of time about them.

Or if you were writing a book about how obsessive revenge eventually leads to death, you wouldn’t spend pages and pages talking about whales, their body parts, and the history of whales in pop culture. Well, maybe you would. Who am I to judge? I just run this pathetic blog, hoping somebody reads it.

So yeah, simplify things or risk boring  or frustrating people.

Eliminating Duplicates

There are many methods of simplifying systems, which I won’t get into here. One way that I will discuss, though, is eliminating duplicates, or, to use one of Chris Crawford’s words, orthogonality. Basically this means to merge two features that are almost identical, or eliminate one of the duplicates. In other words, their should be only one way to get to a certain effect. Chris explains this quite well when he talks about personality models, but now I must say one thing that I don’t like about Chris Crawford’s view of interactive storytelling.

Chris has very strong opinions about what he thinks is important in storytelling. He believes that psychological factors are the most important, and other factors, such as physical attributes, are so unimportant as to be unnecessary. Now I agree that sometimes it’s not important what the character’s eye color is, or what their hair style is, or what they’re wearing, but that really depends on the story. Sometimes what someone is wearing is really important to the story, other times it is not.

A General System

Chris Crawford spent a lot of time, money, and effort creating a general system for interactive storytelling: Storytron. And I think we all know how that turned out. If you don’t, follow the link; Chris writes some interesting articles about the rise and fall of Storytron.

The moral of the story is this: I think we need to focus on specific interactive storyworlds and creating systems for them before we can create a general system for interactive storytelling. Each interactive storyworld is going to be different, and creating a general system to handle all the possibilities is infinitely complicated. I think we’d do better to create software similar to Facade; it focuses on one genre, one location, few characters. It’s a very specific type of storyworld; it would not work for anything else. However, we can take what we learn from these specific systems and apply them to more general systems someday.