Write a “Not-to-Do List” Before Starting: How to Keep Your First Project Under Control
The most common failure in a first interactive film game is not a lack of creativity, but putting every good idea into the first version. Characters, scenes, branches, mechanics, and platforms keep multiplying until nothing gets finished. The solution is to establish a “not-to-do list” before writing the full script and define a trigger for each limit.
Introduction
The most common failure in a first interactive film game is not a lack of creativity, but putting every good idea into the first version. Characters, scenes, branches, mechanics, and platforms keep multiplying until nothing gets finished. The solution is to establish a “not-to-do list” before writing the full script and define a trigger for each limit.
A not-to-do list is not about cutting things out for its own sake. It protects the project's most important promise to players, focusing a limited budget on what actually needs to be validated.
Set Six Hard Limits First
The first is finished footage duration. Record the total amount of distinct video footage, not just the length a player sees in one playthrough. A fifteen-minute playthrough with three completely independent routes may require more than forty minutes of footage.
The second is major characters. Each additional character may add actor coordination, costumes and makeup, dialogue combinations, subtitles, localization, and states to test.
The third is scenes. Scenes include not just locations, but also production variations at the same location under different times, set arrangements, or states of damage.
The fourth is key choices and endings. The number of choices does not equal quality. The first version should prioritize a small number of choices that provide information, carry costs, and deliver feedback.
The fifth is systems. Relationships, evidence, resources, QTEs, clue searching, free-form input, and AI dialogue cannot all be core systems at once. Choose one primary system and add at most one supporting system.
The sixth is platforms. PC, Web, and mobile differ in input, video formats, performance, storage, and distribution. The first version should ideally have one primary platform.
“Do It Later” Needs a Clear Destination
Do not simply say a feature is postponed, because it will soon return under another name. Create three lists: must have in the first version, do after successful validation, and explicitly will not do.
The “do after successful validation” list also needs triggers. For example: add a second type of clue only when at least four testers can understand the evidence system in the three-minute prototype; add higher resolution only when video transitions are stable on low-spec devices; add hidden endings only when the entire main storyline is reachable.
To-do items without triggers turn into emotionally driven additions to requirements.
Use the Promise to Players to Decide What to Cut
The promise of 《零点回拨》 is to let players judge the credibility of calls from the future and character testimony, and change what happens after midnight. The first version therefore needs verifiable predictions, at least two characters with different positions, one bounded time variable, and multiple outcomes jointly determined by trust and evidence.
It does not need a freely navigable 3D customer service center, arbitrary questions entered by players, or a simulation of the company's entire business. These features may be interesting, but they do not directly demonstrate the core promise.
When the team debates a feature, ask three questions: If we remove it, can players still perform the core verbs? If we remove it, can the endings still reflect player behavior? If we remove it, can the three-minute prototype still validate the biggest risk? If all three answers are “yes,” it should not enter the first version.
Turn Scope into Countable Metrics
“Keep the scale manageable” is not actionable. Use a scope table:
| Scope Item | First-Version Limit | Current Count | Action When Exceeded |
|---|---|---|---|
| Minutes of distinct video footage | 20 | Reconverge branches or replace with text nodes | |
| Major characters | 4 | Merge characters with similar functions | |
| Main scenes | 3 | Rewrite as different states of the same scene | |
| Key choices | 8 | Remove options without consequences | |
| Full endings | 4 | Merge endings that differ by only one line | |
| Core variables | 5 | Replace with tags or remove | |
| Primary platforms | 1 | Move other platforms to the post-validation list |
The numbers can be adjusted for the project, but whenever a limit is exceeded, the budget, dates, or other scope must be adjusted at the same time. Do not assume the team will absorb it through overtime.
The Four Most Dangerous “Small Additions”
The first is a new branch that adds content without adding understanding. Players see different dialogue but gain no new information, relationships, or abilities.
The second is adding a mechanic for promotion that cannot run throughout the work. A single clue-searching sequence at the opening does not justify marketing the work as an investigation game.
The third is reluctance to delete assets because they have already been produced. Sunk costs do not prove that content has value.
The fourth is treating technical possibilities as product needs. A model's ability to generate arbitrary dialogue does not mean the story should allow arbitrary dialogue.
Audit Scope Once a Week
The audit examines only four things: what was added, why it was added, what it replaces, and who takes on the additional testing. Any new requirement without a corresponding removal, budget change, or schedule change stays out of production for now.
Scope audits must also check for “hidden growth.” A character may not be new, but if that character needs completely different performances and videos in four states, production volume has already increased. Likewise, if the same office changes from daytime to three states—power outage, fire alarm, and damage—it cannot be counted as just one scene. Record the amount of distinct assets in the table so that identical names do not conceal real costs.
When a project truly needs to exceed a limit, make an explicit scope trade. For example, add an ending and remove an independent side storyline, or postpone a platform version. Record who approved it, why it is worthwhile, and the new acceptance date. This means the team is making product choices instead of quietly accepting a loss of control.
Once the not-to-do list is complete, put it on the project homepage instead of in personal notes. When choosing landscape or portrait orientation, or PC or Web, as the next step, use this list to judge which release format best fits the first version's capabilities.
