More Variables Do Not Mean More Professional Design: How to Separate Relationship, Evidence, Resource, and World States

The value of a variable lies not in how many there are, but in whether it can explain player behavior, change subsequent content, and be reliably maintained by the team. An interactive film game with manageable production usually needs only four layers of state: relationships, evidence, resources, and world facts. Every variable should have a single meaning, clearly defined write points, visible feedback, and an eventual payoff; variables that cannot meet these requirements should be merged or deleted.

Relationship state answers “How does each person regard the protagonist?” It can use discrete stages, such as distant, cooperative, and trusting, or a small numerical range. Evidence state answers “What has the player obtained and understood?” and is well suited to booleans or sets. Resource state answers “What can the player still spend?” including time, money, remaining uses, and key items. World state answers “What has objectively happened?” such as whether an alarm has been triggered or a character has left.

These four layers should not substitute for one another. Obtaining a recording is evidence; it does not mean the partner trusts the protagonist more. Using up one anonymous phone call opportunity changes a resource; it does not mean an alarm has already been raised in the world. With separate layers, writers can explain causality, and programmers can avoid having one all-purpose score control the entire story.

A relationship value from 0 to 100 looks precise, but often creates thresholds that cannot be explained. Players do not know the difference between 59 and 60, and writers struggle to give each point meaning. For filmed content, three to five relationship stages are usually enough: hostile, wary, cooperative, and trusting. Continuous values are worth having only when many small actions need to accumulate and the interface or feedback can let players perceive the trend.

In Midnight Callback, the relationship with the reporter can use three levels of reporter_trust; the key recording can use the boolean evidence_recording; anonymous sending opportunities can use the integer burner_uses; and whether the police station is locked down can use the world state station_locked. Names directly convey their meaning, rather than using flag7 or scoreB.

The variable table should have at least six columns: name, type, default value, who can modify it, which nodes read it, and how the player perceives it. Add a “retirement condition” column to prevent it from being misused after it has served its purpose.

For example, station_locked defaults to false and can only be set to true by the alarm in 4A or the pursuit in 5C; it is read in 6A and 6B. Players perceive it through the rolling shutter coming down and the map being locked down. If all routes enter lockdown once the final chapter begins, normalize the state at the chapter entrance so old branches no longer repeat the check.

If a variable is written in ten places but only produces one irrelevant line of dialogue in one place, its maintenance cost exceeds its value. Conversely, a key fact written only once that changes the route, character reactions, and ending explanation is very cost-effective. During review, count each variable’s writes, reads, and instances of visible feedback: a variable with zero reads is a dead variable, one with zero feedback is a ghost variable, and one with too many writes may have muddled responsibilities.

Do not turn every click into a narrative variable just for analytics tracking. Analytics can record events separately; only content that needs to affect the subsequent story should enter the saved state.

When a node’s entry condition reads “trust above 63 and A or B, but not C, or a second playthrough,” no one can safely modify it. Break complex conditions into named derived checks, such as can_confront_director, and explain in the design document which underlying states they are derived from. Do not save derived checks separately, lest they contradict the underlying values after those values change.

Keep only one authoritative source for the same fact. If “whether the character knows about the recording” is already managed by a knowledge matrix, do not also create three synonymous variables: heard_recording, knows_audio, and audio_seen.

You do not need to display every numerical value, but players should be able to understand changes through performances, the interface, or new opportunities. Improved relationships can change forms of address and eye contact; acquired evidence can appear on the clue board; resource consumption needs a counter or an item disappearing; world state changes should be confirmed through shots of the environment. The later the feedback arrives, the more necessary it is to remind players of the trigger when the payoff occurs.

Avoid pop-ups saying “Affinity +1” that break the realistic atmosphere, but also avoid complete silence. A character’s pause, a changed phone avatar, or an unsolicited call in the next scene can convey the same information. Style determines the expression; the system must remain readable.

The four state layers create a growing number of combinations, so each chapter should retain only variables that truly affect it. Create a “node × variable” matrix marking reads, writes, and irrelevance. When one row reads more than five or six states, consider consolidating states at the chapter entrance. When one column spans the whole story but rarely takes effect, consider deleting it.

Save migration also needs advance consideration: after a variable is renamed, its type changes, or its default value is adjusted, how should old saves be interpreted? After the official launch, you cannot assume every player will start from the beginning. Add a version number to the state table and retain conversion rules from old values to new ones.

Next step: classify every existing variable into the four layers of relationships, evidence, resources, and world state, and complete its state contract. Any variable that cannot be classified or has no node that reads it should first become a candidate for deletion, rather than continuing into the script.