Branch rough cuts in an interactive film workflow: Prove every path before finishing
Before finishing a branching rough cut, establish that options reach the right segments, consequences stay on their routes and shared scenes use no unearned knowledge. A route skeleton records connection evidence and return conditions.
Introduction
Before handing a branching rough cut to finishing, deliver a usable route skeleton: the recipient starts at the common entry, chooses, sees the matching consequence and reaches a valid merge. A route diagram explains the planned connections; a navigable rough cut and route-by-route records show what the current version actually connects. This interactive film workflow handoff gives editing and finishing responsibility for the same connections.
1. Handoff inputs: gather route agreements and asset evidence first
Rainy-Night Archive Room is a fictional mystery-short teaching example, not a real user case, tested result or product feature. Its connections, problems and changes are illustrative.
Shen Yao discovers that a file has been switched and can “Listen to the duty recording” or “Check the borrowing register.” The recording reveals that someone moved a metal cabinet before the blackout. The register reveals that an administrator borrowed the missing file. Both routes return to the stairs, hear dragging upstairs and decide to investigate further.
Before assembly, editing needs three inputs: current choice copy and destinations, available assets and versions, and facts that must hold at each route’s exit. Here, establish that recording listeners do not know the borrower’s name, while register readers do not know the cabinet moved. Without this knowledge boundary, the merge may reveal another route’s information too early.
If the writing and directing team supplies only a branching diagram, ask what state each exit leaves. Confirm position, known clues and prop possession. The complete art or sound plan need not be ready, but editors cannot invent the mystery’s solution.
2. Route skeleton: every row has a traceable entry and exit
Give shared segments, branch-specific segments and merge points separate IDs. Keep identity stable and record versions separately when changing them. Copy this skeleton and replace its example contents with project materials.
| Level and ID | Entry condition | Current segment and exit state | Next destination | Acceptance evidence |
|---|---|---|---|---|
| Shared A | From the opening | Opening v1; only the file swap is known | Choice A | Information before both choices is the same |
| Branch B | Listen to recording chosen | Recording v2; cabinet movement known | Merge D | Corresponding clue is actually heard |
| Branch C | Check register chosen | Register v1; borrower known | Merge D | Name legible and character has inspected it |
| Merge D | B or C finished | Stairs v1; dragging heard | Upstairs entry | Both knowledge states support entry |
At the top, add the rough-cut package ID, starting location, navigation method and asset location. For each row, add actual arrival, evidence location, issue, change owner and review status. Planned destination and actual arrival need separate columns, or correct answers in the table can conceal wrong connections.
The full routes are “A—listen—B—D—upstairs” and “A—check register—C—D—upstairs.” List both rather than “branches merge afterward.” If the shared segment changes version, this list identifies complete routes that need rewatching.
3. Assemble a navigable version where choices determine the next segment
Build the common opening, add both branch segments, then connect each exit to the same stairs segment. Temporary sound, ungraded pictures and rough cut points are acceptable now, but key clues must be recognizable. Incomplete music can be a finishing item; an inaudible recording clue still blocks route acceptance.
Navigation can use a simple prototype with jumps or a clearly labelled segment directory where recipients open the corresponding file for each option. The latter establishes organization under manual navigation only, not correct final-player connections. State the method and what the conclusion covers on the handoff sheet.
Placeholders may remain if labelled with what they replace and which evidence is missing. A card saying “The borrower’s name will appear here” checks structure, not whether filmed footage conveys the name. Mark “connection checkable; content pending,” rather than passing the whole row.
Recipients should choose from the entry themselves, rather than watch the editor drag a timeline. Record each choice, actual segment version reached and endpoint. If finding the next segment requires oral explanation, handoff materials remain incomplete.
4. Three review layers: shared reuse, distinct consequences and valid merges
First check shared segments. Both routes enter through the same opening, which must not reveal a branch-only clue before the choice. Starting the other route again must not retain the previous choice state. Sharing a file does not automatically make viewing conditions identical.
Second, check branch segments: option meaning, actual footage and exit facts. “Check borrowing register” opening the recording is a destination error. Correct register footage with an unreadable name lacks consequence evidence. Return the first to connection configuration; inspect available assets and cut points for the second. Do not leave both to finishing.
Third, check merges. Suppose the stairs originally says, “The administrator moved the metal cabinet.” That joins two clues into common knowledge even though neither route supplies the full basis. Both buttons reaching it does not establish narrative continuity.
A proposed revision reacts to the new sound instead: “Someone is still upstairs.” Existing performance and sound must support it, and later content must not yet depend on the removed judgment. Watch B into D and C into D separately to check the reason for going upstairs, then check whether the next segment reuses an unreceived clue. These are checks to perform, not passed results.
5. Return or release: resolve structure before finishing
If the original line cannot be removed, keep two short stairs entries, each using only its route’s knowledge, then join the common action. This adds an entry pair to maintain. Alternatively, add missing clues before the merge, but that changes the choice’s information gap and needs writing/directing approval. Do not quietly weaken a choice to reuse footage.
A useful record is: “Register route, C v1 into D v1; stairs dialogue references unreceived cabinet clue; return to writing/directing to confirm merge wording; after editing submits D v2, rewatch both entries and the first upstairs segment.” It locates next steps better than “rough transition” and prevents fixing the register route while breaking the recording route.
Send finishing the skeleton, navigable rough cut, route records and unresolved items. Mark structural review passed only within the range with clear entries, correct destinations, legible branch facts and valid merge premises. Record pacing, performance and visual completion separately.
This list suits the example’s limited-branch short. Loops, hidden conditions and cross-play memory require state-based reachable paths beyond two-route coverage. Rough-cut release establishes traceable route organization within the agreed scope, not final acceptance in the playback environment.
