Keeping Branching Diagrams Under Control: Node IDs, Entries, Exits, and Conditions
A branching diagram ready for production is a routing map shared by the team, rather than a story poster. Every node must have a stable ID, clear entry conditions, verifiable state changes, and explicit exits. The diagram answers “where do we go?”; the script answers “what do we perform?” Cramming entire pages of dialogue into a flowchart only makes both impossible to maintain.
Introduction
A branching diagram ready for production is a routing map shared by the team, rather than a story poster. Every node must have a stable ID, clear entry conditions, verifiable state changes, and explicit exits. The diagram answers “where do we go?”; the script answers “what do we perform?” Cramming entire pages of dialogue into a flowchart only makes both impossible to maintain.
Define the Smallest Unit of a Node First
A node should be a piece of content that can be entered, played, and exited independently. It usually has one primary narrative objective, continuous time and space, and a defined set of exits. A shot change does not require a new node; splitting is necessary when entry conditions, available options, or state updates differ.
In 《零点回拨》, “the protagonist receives a call in the archive room” can be assigned C03_S02_N010: chapter three, scene two, node ten. If answering and declining the call play different videos, their exits lead to N020A and N020B respectively. Do not use plot titles as IDs, because titles change; stable numbering lets scripts, assets, code, and test reports refer to the same object.
Include Only Necessary Fields on a Node Card
Each node card should include: node ID, short title, entry conditions, media assets, state on entry, player interaction, state updates on exit, exit IDs, exception handling, owner, and version. Entry conditions describe who can enter, exits describe where to go, and state updates describe what happened.
For example:
ID: C03_S02_N010
Entry: caller_known = true
Asset: C03_S02_N010_v05.mp4
Interaction: Answer / Listen while muted / Hang up
Update: call_action = answer|listen|hangup
Exits: N020A / N020B / N020C
Exception: If there is no input, enter N020C
Do not leave “if the relationship is good, perhaps she will say something else” in a note. Either make it an entry or variant condition, or remove it; vague conditions inevitably lead to missing footage or programmers having to guess.
Distinguish Four Types of Connections on the Diagram
Use different line styles or labels for ordinary transitions, conditional transitions, failure or timeout routes, and chapter jumps. Color should only supplement other information, never serve as the sole indicator, because printing, color vision, and export formats can make colors ineffective. Write the condition name directly on every conditional connection; do not use “yes/no” detached from the question it answers.
Use connector nodes for connections across pages, and show both the source and destination. Do not draw a line across the entire canvas; the more the diagram resembles spaghetti, the harder it is for reviewers to spot dead ends.
Entries and Exits Must Be Accounted For
Every node except the opening must have at least one valid entry; every node except an ending must have at least one exit. Run an automated or manual inspection: nodes without entries are islands, nodes without exits are dead ends, and links to nonexistent IDs are dangling references. Optional content also needs a way out, so players can return to the main storyline after examining a clue.
For every choice, also define where to go when there is no input, a resource is missing, or an old save causes an error. The default route is part of narrative design, rather than a fallback improvised by the programmer.
Separate Narrative, Production, and Testing Diagrams
The narrative diagram shows player paths and emotional pacing; the production diagram expands shared locations, actors, and asset variants; the testing diagram marks condition combinations and coverage status. These three views can read the same node data, but do not need to be squeezed into one diagram. Directors care about how to shoot scenes in the same location, testers care about how to reach them, and readers should not be overwhelmed by every field at once.
Maintain one authoritative node table first, then generate different views. If the diagram and table are updated separately by hand, they will eventually diverge. Small teams should at least establish this rule: the table governs node routing, and the visual diagram is for discussion only; export it again after each script lock.
Protect Collaboration with Versions and Change Logs
Do not reuse a node ID once it has entered filming. After deleting N030, retain a record of its retirement and assign a new number to new content to avoid mistaking old files for current ones. For every change, record “who, when, why, and which entries, exits, and assets are affected.” Once the shooting version is locked, any branch change must be communicated to the writers, production team, programmers, and testers at the same time.
Add status labels to high-risk nodes: draft, narrative locked, ready to shoot, filmed, integrated, and verified. Status is permission for the next role to begin work, rather than a decorative progress indicator.
Walk Through Paths During Review, Not Just Individual Nodes
Correct individual nodes do not guarantee that an entire route works. Walk through at least four paths: the fastest main storyline, the most clues, the lowest relationship level, and timeouts throughout. For each pass, record visited nodes, state changes, and the ending, and confirm that every important promise has a payoff. Then work backward from each ending to check its prerequisites and find combinations players can never satisfy.
Next step: choose one chapter and build an authoritative node table, assign stable IDs to all nodes, and fill in entries, state updates, exits, and no-input routes. Once it is complete, ask someone who did not participate in the writing to traverse all four paths using only this table.
