Managing the Complexity of Branching Scenarios

What are some strategies for managing the complexity of branching scenarios? One of the issues with branching scenarios is that you can get exponential growth. If each choice has 3 options, you end up with 9 slides after just 2 choices, and 27 after 3 choices. This results in 40 slides total with only 3 decisions per path, in a structure called a time cave. For most projects, that’s more complexity than you want or need. This post was originally prompted by a discussion on reddit about tips for creating branching scenarios without letting them grow out of control.

Use Twine

One way to make this branching easier to manage is by creating your scenarios in Twine. Twine makes it very easy to draft scenarios and check how all the connections flow together. No matter how complex your scenario is, Twine makes it easier to create it. For example, I built a chat simulation with 50 passages in only 2 hours.

You can use Twine as your initial prototype, or you can use it as your final product. I often Twine as my initial draft and prototype, then export everything to Word as a storyboard for developers to build the final version in Storyline.

Plan the scenario

Before I sit down to write a scenario, I always know my objectives. What are you teaching or assessing?

I usually have an idea of how long the ideal or perfect path will be. If you have a multi-step process, that’s your ideal path. If there’s going to be 4 decision points on the shortest path, I know what those are before I start writing.

I also know at least some (ideally most) of the decision points based on errors or mistakes I need to address.

Sometimes you reach a limit to how much you can plan before you just start writing it out though. Once I have a rough outline and clear goals, I find it’s easier to just open up Twine and figure it out within that system.

Allow opportunities to fix mistakes

One trick for managing the potentially exponential growth is by giving learners a chance to get back on the right path if they make a minor error. If they make 2 or 3 errors in a row, they get to an ending and have to restart the whole thing.

For example, maybe you’re teaching a communication skill where they should start with an open-ended question before launching into a sales pitch.

• A is the open-ended question (the best choice).
• B is a closed question (an OK choice).
• C is jumping right into the sales pitch without asking (bad choice).

After the customer response for choice B, I’d give them an opportunity to use the open-ended question (A) as their follow up. Reusing some choices helps keep it from growing out of control. In this image, reusing choices cuts the total number of pages from 40 to 20.

Make some paths shorter

Not every path needs to be the same length. In the above image, one branch from choice C is shorter. It ends after 2 choices instead of 3. You might make a short path if people make several major errors in a row. Past a certain point, it makes sense to  ask people to reset the scenario from the beginning or backtrack to a previous decision.

Create good, OK, and bad choices

In branching scenarios, not everything is as black and white as a clear-cut right or wrong answer. You can have good, OK, and bad choices and endings.

In the example above, the passages are color coded.

• Blue = Decision point (Bottlenecks in the structure)
• Green = Good choice
• Yellow = OK choice
• Red = Bad choice
• Purple = Additional information (This scenario included some places where learners could ask for additional help.)

More on branching structures

If you’d like to read more about branching structures and managing the complexity of branching scenarios, check out these posts.

• Streamlining Branching Scenario Planning and Design
• How Long Should We Let Learners Go Down the Wrong Path?
• Don’t Restart Scenario-Based Learning, Go Back
• Branch and Bottleneck Scenario Structure

Originally published 7/18/2017. Updated 6/22/2021.