An Interactive FMV Project from 0 to 1: A Complete Map of the Process, Roles, and Deliverables

The real difficulty in making an interactive FMV project is not “shooting a video and adding two buttons.” It is making sure the story, choices, assets, code, and testing always describe the same project. The most reliable method is to break production into ten stages with clear deliverables: project initiation, core experience, story, branching system, prototype, production planning, shooting, post-production integration, testing, and release review. The output of each stage must be directly usable by the next stage.

This article is for writers, directors, independent developers, and small-team leads who are taking responsibility for an interactive FMV project for the first time. After reading it, you should be able to map out your own production route, understand who is responsible for each step, what must be delivered, and when the project should not move forward.

DramaFork is a platform for creating and publishing interactive content. This article uses the project plan “Midnight Callback” from the platform as an example, but the process itself does not depend on any particular tool.

The project initiation stage must answer four questions: who will play it, why they would want to play it now, what the player does in the story, and whether the team can handle the scale. The deliverable is a one-page project positioning card that includes at least the target player, release platform, estimated duration, core player verbs, and limits on characters and locations.

Take “Midnight Callback” as an example. The story hook is “a night-shift customer service agent receives a call from twenty-four hours in the future.” But the playable promise is not that sentence. It is this: the player must judge whether the caller is trustworthy within a limited time, choose allies, and change what happens after midnight. Only the second sentence can guide choice design and prototype validation.

The acceptance criteria for project initiation are also simple: can the team explain, in one sentence, the action the player repeatedly performs, and clearly define what the first version will not include? If the answer is still “an immersive story experience,” the scope has not landed yet.

The first translation turns theme into conflict. For example, “trust” cannot only appear in character dialogue; it must become a decision whose consequences the player has to bear.

The second translation turns conflict into choices. Every choice needs entry information, understandable options, state changes, and visible feedback. Options with no state change can be kept as character expression, but they should not pretend to alter the main storyline.

The third translation turns choices into data. The team needs unified node IDs, jump targets, appearance conditions, variable writes, required videos, and possible endings. The writer’s “second argument,” the programmer’s scene_02, and the file names used in post-production must all correspond to one another.

The fourth translation turns data into production tasks. The node table needs to expand into a location matrix, actor days, props, makeup and styling, shots, sound, subtitles, and test cases. Only at this point does the creative idea first become a project that can be costed.

Stage Required deliverables Conditions for moving forward Project initiation Positioning card, scope guardrails Player, platform, duration, and core action are clear Core experience Core loop, interaction density table One complete feedback cycle appears within three minutes Story and characters Beat sheet, character information-asymmetry matrix The main conflict can be changed by player action Branching system Node table, variable dictionary, ending matrix All jumps are traceable, with no orphan nodes Prototype Playable three-minute version At least one path can reach an ending from the start Production planning Location matrix, budget, schedule Independent asset volume stays within budget Shooting Numbered video and audio assets Assets can be checked item by item against the node table Post-production integration Release videos, subtitles, interface, and saves Choice switching is stable and state saves correctly Testing Path coverage and device reports Blocking issues are cleared, 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 first and thinking about release later” usually creates rework. The official Steamworks getting started guide recommends preparing the store presentation while creating the build.

In a three-person team, the writer may also handle narrative design, the director may also take on production planning, 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 is doing both.

For example, a writer-programmer still needs a node table, because three weeks later even they will not be able to judge from memory where a variable is written. A director-editor still needs script notes and asset IDs, otherwise reshot material cannot correctly replace old branches. Roles can be merged, but interfaces cannot disappear.

Many projects finish a 100,000-word script, or even shoot all the material, before letting players operate anything for the first time. When they then discover that “the choices provide no information,” “the options are hard to understand,” or “video transitions break the pacing,” the cost of changes has already become rewriting, reshooting, and re-editing.

A better order is to build a three-minute prototype first: five nodes, two choices, and three endings, using temporary text or low-cost video if needed. The prototype should not validate image quality. It should validate whether players know what they are deciding, whether they can feel a change after choosing, and whether the team can track state.

Create a one-page project positioning card and fill in only the target player, usage scenario, core player verbs, platform, duration, character limit, location limit, and a list of what the first version will not do. Do not write the full story yet.

The next article will first distinguish interactive films, FMV games, interactive short dramas, and visual novels. Choosing the wrong product form will cause the script, shooting plan, and technical approach that follow to conflict at the root.