The Core Loop of Interactive Film Games: Connecting Watching, Judging, Choosing, and Feedback
The core loop of an interactive film game is not “play video—display buttons—resume playback,” but “receive information—form a judgment—take action—see feedback—update the next judgment.” Buttons are just an input method. If information, judgment, or feedback is missing, players will feel they are clicking through pages for a video.
Introduction
The core loop of an interactive film game is not “play video—display buttons—resume playback,” but “receive information—form a judgment—take action—see feedback—update the next judgment.” Buttons are just an input method. If information, judgment, or feedback is missing, players will feel they are clicking through pages for a video.
When designing the core loop, first use a three-minute prototype to validate one complete cycle of change, without rushing to add more branches. Whether players can explain what they based their decision on and what changed afterward matters more than how many times buttons appear.
Step One: Give Players Information They Can Use to Make Judgments
Information can come from dialogue, performances, settings, props, system records, or earlier choices. The key is that players can encounter it before deciding, rather than learning after the ending that “the correct answer required a clue that never appeared.”
The first round of information in Midnight Callback could be this: a call from the future accurately predicts a power outage ten seconds before it happens, but the caller refuses to reveal their identity. Players therefore have one piece of evidence supporting trust and one anomaly supporting suspicion.
Do not mistake background details for decision-relevant information. A company’s founding year or a character’s birthday may enrich the world, but they do not necessarily help players decide whether to open the server room.
Step Two: Make Judgments Genuinely Uncertain
If one option is obviously kind and the other obviously foolish, players are not making judgments; they are guessing what the designer wants them to click. Meaningful uncertainty comes from conflicting values, conflicting evidence, or insufficient resources.
For example, players can call the police immediately, but doing so will alert whoever is monitoring internal calls. They can also verify the caller’s claim first, but risk missing the chance to save someone. Both approaches have reasons and costs; only then does a choice reveal players’ priorities.
Uncertainty does not mean hiding the rules. Players may not know every consequence, but they should understand the kind of risk they are taking.
Step Three: Choices Must Be Written to Trackable State
State does not have to be numerical. It can also be a tag, known information, or an irreversible event. Choosing to trust a colleague can record “access permissions shared”; copying logs can increase evidence completeness; delaying a police call can reduce the time remaining.
Every key choice should answer at least three questions: what state is written, who will read it, and when feedback will appear at the latest. If a state is never read, it is merely a record, not a system.
Step Four: Feedback Should Tell Players the World Remembers Them
Immediate feedback can take the form of a character’s reaction, an interface change, a new clue, or a lost resource. Delayed feedback can appear in later scenes or endings. Ideally, combine the two: use small feedback first to confirm that the input took effect, then larger feedback to show the long-term consequences.
For example, after players give Chen Mo access permissions, he immediately changes his tone of voice: this is confirmation. Fifteen minutes later, he can enter the server room to save someone: this is a long-term consequence. Using only the latter makes feedback arrive too late; using only the former makes the choice feel weightless.
Step Five: Feedback Becomes Information for the Next Round
The core loop is a loop because its results change the next judgment. Chen Mo’s willingness to take risks may make him more trustworthy, or suggest an ulterior motive; deleted evidence reduces the available routes; less time remaining changes players’ tolerance for risk.
If all information and options return to their original state after every choice, the game is merely a series of independent questions and answers. Make at least one of the following change persistently: characters, resources, knowledge, or paths.
Check the Prototype with a Loop Table
| Node | What players see | What they need to judge | Available actions | State written | Immediate feedback | Later use of state |
|---|---|---|---|---|---|---|
| Call 1 | The power outage prediction comes true | Whether the caller is credible | Trust / Hang up | Trust in the caller | New dialogue | Whether a second prediction is received |
| Access control | Two people accuse each other | Who should receive access permissions | Chen Mo / Zhou Lan | Ally identity | The recipient’s response | Server room route |
Any blank in the table deserves scrutiny. In particular, an empty “Later use of state” field usually indicates a sham state; an empty “What players see” field usually indicates a blind choice.
How to Run the First Test
Do not ask testers, “Is it fun?” Have them explain their reasoning as they play. Record where they lack information, how they interpret the options, and whether they recognize the feedback as related to their own actions when it appears.
After the test, ask three questions: What were you mainly trying to judge? Which piece of information most influenced your choice? Which consequence did you cause? If the answers differ from the design table, adjust the information, options, and feedback first. Do not explain the entire system through explanatory text.
During testing, also save a log of the actual path taken: which nodes were entered, what information was seen, what choices were made, and which variables were changed. When players say, “I didn’t see any feedback,” compare their account with the log to determine whether the feedback failed to trigger, appeared too late, or was communicated unclearly. Without logs, teams can easily mistake programming problems for narrative problems, or vice versa.
The minimum standard for a loop to pass is this: most testers can identify what they were judging, cite at least one piece of information from the work, point to a change after their choice, and that change affects the next round. If any of these four conditions is missing, fix the loop before adding new nodes.
Once you have a stable loop, the next article will address how frequently interactions should occur. Frequency should serve judgment and feedback; it should not interrupt every performance segment just to make the experience “feel more like a game.”
