The First Version Should Only Be Three Minutes: How to Complete a Minimal Closed Loop for an Interactive Film Game
The first playable version of an interactive film game should not be a half-finished first chapter, but a complete closed loop of about three minutes: enter a video, understand one choice, see the difference, have one convergence or ending occur, and be able to restart. It must simultaneously expose problems in narrative, shooting, editing, playback, input, state, and testing.
Introduction
The first playable version of an interactive film game should not be a half-finished first chapter, but a complete closed loop of about three minutes: enter a video, understand one choice, see the difference, have one convergence or ending occur, and be able to restart. It must simultaneously expose problems in narrative, shooting, editing, playback, input, state, and testing.
A prototype must answer risks, not display scale
Before writing a prototype, list the three most dangerous assumptions: Can the video switch without a black screen? Can players understand the options? Can actors perform differences in state? Then have the three-minute sample focus on verifying them. Do not first build login, a store, a polished homepage, or twenty empty chapters; these cannot prove that the core experience holds up.
The prototype of Zero Point Callback can have only one room, one actor, two incoming-call videos, and one binary choice. The player first discovers a tampered timestamp, chooses to answer or record, the two short branches produce different clues, and then both enter the same ending of knocking outside the door. It already includes observation, decision, feedback, state, and recovery.
The minimal closed loop needs seven components
First, a clear opening goal; second, a playable main video; third, interaction that appears at a reasonable time; fourth, at least two real outcomes; fifth, one saved state; sixth, subsequent feedback that can confirm the state; seventh, an entry point to restart or replay. If any one is missing, key problems may be postponed until formal production.
Materials do not need to reach final image quality, but the pacing must be real. Shooting with a phone is acceptable, but static text cannot be used to pretend a video is loading; temporary actors are acceptable, but the performance continuity before and after the options cannot be omitted. The prototype must be cheap, but it cannot bypass the risks that need to be verified.
Choose a scene with high information density
Do not default to excerpting the beginning of the story. Openings often carry world introduction, and their interaction is the weakest. Choosing a mid-story scene that includes performance, branching, state recovery, and media switching better verifies the production line. To keep testers from failing to understand the background, use a short context card to provide the necessary information.
Three minutes is not a hard limit, but a way to force the team to shorten the feedback loop. Testers should be able to complete two different routes within ten minutes, so the team can quickly observe and compare.
Technically, first connect the vertical slice
The prototype starts with real file naming and node data: node ID, video path, options, conditions, writes, and exits. The player needs to preload the next candidate clip, the input layer handles mouse, touchscreen, or gamepad, the state layer saves at least one variable, and the log records entering nodes, displaying options, choices, and exits.
Cloud saves, multilingual packs, and complex encryption can be left out for now, but the interfaces must leave room for them. Writing all logic into button scripts will increase the maintenance cost of later expansion and state checking; even at the prototype stage, clear node and variable definitions must be retained.
Testing observes four types of evidence
Comprehension: Can players restate the goal and the two differences? Pacing: Where do they lose focus, and do they have time to finish reading? Technical: Are there black screens, stutters, volume jumps, or input failures? Emotion: After choosing, do they anticipate the result, and are they willing to immediately try the other option?
During testing, observe first and do not explain. Afterward ask, "What did you think the button would do?" and "What changes did you notice?" Do not end by asking "Was it fun?" Record actual behavior and original words, and distinguish individual preferences from recurring problems.
Use an interview record sheet to turn observations into revisions
First have the player complete one choice, then ask: "What information did you know at the time?" "What did you think this button would bring?" "After the result appeared, what changes did you notice?" Separating expectations before action from understanding after action is the only way to judge whether the problem lies in the options, the feedback, or the story causality.
Before starting, explain only the character and the current task, and state that they can pause at any time. Do not explain the design intent in advance, and do not ask players to prove they understood. After the first route ends, then ask whether they are willing to explore the other choice, and record whether this was raised on their own initiative or after an invitation.
The following is a fictional filled-in example; both the behavior and the original words are used to demonstrate the recording method, not real player feedback.
| Record item | Filled-in example |
|---|---|
| Build and task | Sample build A; determine whether to answer the abnormal call |
| Behavioral observation | Read both options, looked back at the timestamp, chose to record |
| Player's original words | "I thought recording could keep evidence, but the result only said the call was hung up." |
| Author's inference | The benefit of recording may not have been sufficiently fed back |
| Explanation to verify | Did the player misread the option, or was recording information missing later? |
| Revision action | Show that the recording has been saved, and read it during later verification |
| Review task | Check whether new players can point out what the recording changed |
Do not write inferences as observations. A pause may come from careful judgment, or it may come from unclear copy; first record what happened, then distinguish the cause through questions. Preserve a single player's preference in their original words, and do not directly generalize it into a need of all people.
When sorting out problems, handle inability to complete a path, inability to understand the core choice, and personal aesthetic preference separately. For each revision, write the owner, the corresponding node, and the review task; return to the same situation to check the change, rather than only asking "Is the new version better?"
Set clear thresholds for passing
For example, among five target players, at least four can clearly state the intention of the choice; the first playback has no perceptible black frames; both routes can reach the ending; the state is correctly saved before restart; at least three actively want to see the other result. The thresholds do not have to be copied exactly, but they must be written down before testing, to prevent the team from accommodating the results afterward.
If it does not pass, fix the closed loop first before expanding. If the options in three minutes cannot be understood, writing fifty thousand words will not automatically solve it; if switching between two video clips is unstable, shooting one hundred clips will only amplify rework.
Deliverables when the prototype is complete
Keep the runnable build, source materials, node table, variable table, test script, issue record, and decision conclusions. Clarify which are temporary solutions and which will enter the formal pipeline. A prototype is not a promotional video to be discarded after viewing, but the first verified production specification.
Do not use satisfaction to cover up technical failure
Acquaintance testers may like the subject matter and actors, yet still experience black screens, mistaps, or incomprehensible options. Count "liking the story" and "the closed loop is reliable" separately; any technical problem that blocks completion should take priority over average ratings. Also do not explain the product on the tester's behalf during the test; successful explanation does not equal a successful interface.
After the sample passes, do one more test on unfamiliar devices: cold start, first download, low disk space, headphone switching, and locking the screen midway. If the three-minute closed loop can only run on the development computer, what it verifies is the demo environment, not the production solution.
Set a clear exit condition
It is easy to keep polishing during the prototype stage. Specify in advance: once the core thresholds pass for two consecutive rounds, there are no blocking issues, and the pipeline cost can be estimated, end the prototype and enter pre-production. Visual flaws and extra features go into the backlog and are not extended indefinitely in the sample. Conversely, as long as the most dangerous assumptions remain unverified, you cannot skip past them with "it will be better in formal production."
Next step: write acceptance questions for one scene, one choice, and two kinds of feedback, prepare the same playtest task and interview record sheet, and then invite target players to experience it. The player counts and passing thresholds above are only project examples, not universal statistical standards; small-scale observation is used to discover problems and cannot be used to infer market size or probability of success.
