An Interactive Film Game from 0 to 1: A Complete Map of the Workflow, Roles, and Deliverables
The real challenge of making an interactive film game is not “shooting a video and adding two buttons,” but keeping the story, choices, assets, code, and testing aligned around the same project. The safest approach is to divide production into ten stages with clear deliverables: project initiation, core experience, story, branching system, prototype, production planning, filming, post-production integration, testing, and release review. Each stage’s output must be directly usable by the next.
Introduction
The real challenge of making an interactive film game is not “shooting a video and adding two buttons,” but keeping the story, choices, assets, code, and testing aligned around the same project. The safest approach is to divide production into ten stages with clear deliverables: project initiation, core experience, story, branching system, prototype, production planning, filming, post-production integration, testing, and release review. Each stage’s output must be directly usable by the next.
This article is for screenwriters, directors, independent developers, and small-team leads taking responsibility for an interactive film game for the first time. After reading it, you should be able to map out your own production process, identify who owns each step and what they deliver, and know when you cannot move forward.
DramaFork is a platform for creating and publishing interactive content. This article uses the project proposal “零点回拨” on the platform as an example, but the process itself does not depend on any particular tool.
The First Stage Is About Proving the Project Is Viable, Not Writing the Full Script
Project initiation must answer four questions: Who will play? Why do they want to play now? What does the player do in the story? Can the team handle this scope? The deliverable is a one-page project positioning card containing, at a minimum, the target player, release platform, estimated duration, core player verbs, and limits on characters and locations.
In “零点回拨,” for example, the story hook is “a night-shift customer service agent receives a call from twenty-four hours in the future.” But the promise of gameplay is not that sentence. It is this: within a limited time, the player must judge whether callers are trustworthy, choose allies, and change what happens after midnight. Only the latter can guide choice design and prototype validation.
The acceptance criterion for project initiation is also simple: Can the team explain in one sentence the action the player repeatedly performs, and clearly state what the first version will exclude? If the answer is still “experience an immersive story,” the scope has yet to become concrete.
Moving from Story to System Takes Four Translations
The first is translating the theme into conflict. “Trust,” for example, cannot appear only in character dialogue; it must become a decision whose consequences the player has to bear.
The second is translating conflict into choices. Every choice needs information provided beforehand, understandable options, a change in state, and visible feedback. Options that do not change state can remain as a means of character expression, but they must not pretend to change the main storyline.
The third is translating choices into data. The team needs consistent node IDs, jump targets, appearance conditions, variable assignments, required videos, and possible endings. The screenwriter’s “second argument scene,” the programmer’s scene_02, and the post-production filename must all correspond to one another.
The fourth is translating data into production tasks. The node table must be expanded into a location matrix, actor-days, props, hair and makeup, costumes, shots, sound, subtitles, and test cases. Only at this point does the idea first become a project whose costs can be estimated.
What Each of the Ten Stages Delivers
| Stage | Required Deliverables | Conditions for Moving Forward |
|---|---|---|
| Project initiation | Positioning card, scope boundaries | Players, platform, duration, and core actions are clear |
| Core experience | Core loop, interaction density table | One complete feedback cycle can occur within three minutes |
| Story and characters | Beat sheet, character information-gap matrix | Player actions can change the central conflict |
| Branching system | Node table, variable dictionary, ending matrix | All jumps are traceable, with no unassigned nodes |
| Prototype | Playable three-minute version | At least one path leads from the beginning to an ending |
| Production planning | Location matrix, budget, schedule | The volume of distinct assets fits within the budget |
| Filming | Numbered video and audio assets | Assets can be checked individually against the node table |
| Post-production integration | Release-ready videos, subtitles, interface, and save system | Choice transitions are stable and state is saved correctly |
| Testing | Path coverage and device reports | No blocking issues remain, and key endings are reachable |
| Release review | Store page, Build, data dashboard | Promotional promises match the actual version |
Steam’s release process also requires separate checks and reviews for the store page and the product Build, so “finishing the game before thinking about release” usually leads to rework. The official Steamworks Getting Started guide recommends preparing the store presentation while developing the Build.
Small Teams Can Combine Roles, but They Cannot Remove Handoffs
In a three-person team, the screenwriter may also handle narrative design, the director may also serve as producer, and the programmer may also be responsible for testing tools. That is fine. The real danger is skipping the deliverables between two jobs because the same person does both.
For example, a screenwriter who also programs still needs a node table, because three weeks later they cannot rely on memory alone to determine where a variable is assigned. A director who also edits still needs script supervisor notes and asset IDs; otherwise, reshot footage cannot correctly replace footage in existing branches. Roles can be combined, but the interfaces between them cannot disappear.
The Most Common Mistake Is Validating Too Late
Many projects finish a script of a hundred thousand Chinese characters, or even shoot all the footage, before letting players interact for the first time. If they then discover that “choices lack information,” “options are hard to understand,” or “video transitions disrupt the pacing,” changes already require rewriting, reshooting, and re-editing.
A better sequence is to start with a three-minute prototype: five nodes, two choices, and three endings, using either placeholder text or low-cost video. The prototype should validate whether players know what they are deciding, whether they can feel a change after making a choice, and whether the team can track state—not the visual quality.
What to Do Now
Create a one-page project positioning card and fill in only the target player, usage context, core player verbs, platform, duration, character limit, location limit, and a list of what the first version will exclude. Hold off on writing the full story.
The next article will begin by distinguishing interactive films, FMV games, interactive short dramas, and visual novels. Choosing the wrong product format can put the subsequent script, filming, and technical plans into fundamental conflict.
