Branch and Bottleneck Scenario Structure
A branch and bottleneck scenario structure keeps the complexity of branching scenarios manageable while allowing a deeper progression over time.
One of the challenges of branching scenarios is that you can generate so many options and paths that it quickly becomes unwieldy. A branch and bottleneck scenario structure is one strategy for keeping the complexity manageable.
Branch and Bottleneck
In a branch and bottleneck structure, you branch into different options for a while, but then all paths return to a single bottleneck. The bottleneck is an event or choice that happens the same in every path. In the example above, there are 39 screens. Most paths have 6 decisions (plus two bottlenecks), although a few shorter paths end in failure.
I learned the terminology “branch and bottleneck” from Sam Kobo Ashwell in his post on Standard Patterns in Choice-Based Games. Although he’s writing about structures for games and interactive fiction, his concepts also apply to branching scenarios for training.
The branch-and-bottleneck structure is most often used to reflect the growth of the player-character: it allows the player to construct a somewhat-distinctive story and/or personality, while still allowing for a manageable plot.Sam Kabo Ashwell
Ashwell notes that this structure often relies on states to maintain continuity in the narrative. You might track an overall score or adjust another part of the consequences or intrinsic feedback based on earlier choices.
Branch and bottleneck is a good structure if you have two options that could be done in either order (where you then backtrack to the other branch after completing one). It’s also good if certain key events will drive the plot forward regardless of prior decisions.
Traditional Branching (Time Cave)
Contrast the branch and bottleneck structure with what Ashwell calls the time cave. This is the traditional structure for branching. Each choice leads to more choices, with no rejoining or reusing choices. This leads to numerous endings.
In the example above, players make 3 total decisions, but it’s already 40 screens (1+3+9+27). The number of screens in a time cave increases exponentially. To add a fourth decision in the path, you need to add 81 more screens. By necessity, a time cave is generally limited to a maximum of 3 decisions in each path. It’s broad, giving you lots of alternative endings, but it’s not very deep. It doesn’t do well for showing a longer process or change in a character.
Example Branch and Bottleneck
In practice, the branch and bottleneck doesn’t usually look as “clean” as my first graphic. I usually reuse some choices. That gives players a chance to correct their mistakes without continuing down the wrong path indefinitely. It doesn’t immediately force them back to the right path or to restart; it lets them learn from the feedback and adjust.
In my client screening branching scenario, I have one major bottleneck near the end, highlighted in yellow (“Tell me about what changed…”). Several other paths are failures that cause a restart. Mostly, the paths cross and converge multiple times as players have the opportunity to correct mistakes and get back to the ideal path.
The ideal path is 4 decisions deep. The complete scenario ended up as 20 slides in Storyline, 1/6 of the number of slides it would have taken to use a full time cave structure.
Branching scenarios don’t have to mean letting the options grow indefinitely. Including a bottleneck or two can drastically reduce the number of slides required while still allowing you to create a longer, deeper scenario narrative. You may also use this with other strategies to manage the complexity of branching scenarios.
How do you handle branching scenarios to keep them from getting too large to comfortably manage? What strategies have you found helpful?
11 thoughts on “Branch and Bottleneck Scenario Structure”
Thank you, Christy. This was so useful.
Excellent, I’m glad it was helpful!
This is a very useful summary of a very useful structure.
In procedure training, it’s important to allow the learner to make a catastrophic error, and figure out what went wrong and why (which requires that they have a good working mental model of the system being operated). Then, they can restart and proceed correctly.
Even better if the system allows them to identify a potentially-catastrophic error state before it becomes actually catastrophic, and correct it.
The challenge with many programming tools is that they don’t make the branching structure explicit.
–Corrie Bergeron, M.Ed.
Use variables to track early choices, then collapse back to a linear path. The variables cause branching later in the story. You can also compute a score using the variables. Maybe encourage people to try again, to increase their score.
The idea of trying again to improve your score is especially helpful for training, where repeated practice is often needed to develop skills.