Who Exactly Is the Player: Protagonist, Director, Investigator, or Invisible God?

In interactive film-game design, “who the player plays” matters more than “who the protagonist is.” The player might be the protagonist on screen, a director guiding characters’ actions, an investigator with access to additional interfaces, or an invisible god capable of changing several people’s fates. Different roles change what information the player is entitled to know, what actions they can perform, how choices are worded, and who bears responsibility for failure.

When the role is undefined, a common result is that the camera treats the player as a spectator, the choices treat them as the protagonist, and the system lets them read data the character could not possibly know. Players can accept unrealistic abilities, but the work must establish consistent rules.

When the player directly plays the protagonist, choices should ideally express actions, dialogue, or attitudes. Examples include “Give the access card to Chen Mo,” “Ask more about where the call came from,” and “Remain silent.” These choices should stay within the protagonist’s abilities and knowledge.

The advantage of the protagonist role is immediate identification, with consequences that are easy to attribute to choices. The difficulty is that a predefined character needs to accommodate differences among players. If Lin Zhixia is written as extremely cautious, but an option like “Blow up the server immediately” suddenly appears, the player gains freedom while the character loses credibility.

The solution is to define boundaries for variation, rather than stripping the character of personality: she may be afraid yet still take risks, and she may protect her colleagues while choosing different ways to save them. Choices express the player’s position within those boundaries.

A director-type player does not need to be acknowledged by the characters. They are more like an arranger deciding “who the story follows next” or “which clue to examine first.” Choices can extend beyond a single character’s knowledge, making this role suitable for ensemble stories, live-stream voting, and works with multiple viewpoints.

The risk of this role is a weaker sense of responsibility. After a character makes a cruel decision, the player may feel that they merely selected a more interesting shot. To maintain engagement, feedback needs to explain what information, relationships, or outcomes the player’s arrangement changed, rather than simply changing the viewing order.

An investigator can review surveillance footage, chats, access records, and an evidence database, then issue limited instructions to characters. This role suits works that combine FMV with interfaces, because not all information the player receives needs to have been seen firsthand by the protagonist.

But the system must explain the investigator’s permissions. Why can the player see these materials? Do the characters know someone is guiding them? If the interface is merely a menu that makes it convenient for developers to display information, the narrative will develop a disconnect.

《零点回拨》 can define the player as Lin Zhixia herself, directly operating a customer service terminal; it can also make the player a remote shift supervisor who decides which systems she can access. These two versions require different dialogue and shots, and cannot be switched midway through development.

Some works allow players to distribute fates among different people, or even restart timelines. This is an explicit form of narrative power. It suits explorations of sacrifice, causality, and multiple playthroughs, but should not disguise a “god’s-eye choice” as a character’s decision in the moment.

If the player knows both the killer’s identity and information unknown to the protagonist, choices cannot ask the player to reason as the protagonist would. Instead, they can ask the player to decide whether to intervene, which timeline to preserve, or deliberately create a moral conflict.

1. Does the player actually exist within the story world?
2. What information does the player know that characters do or do not know?
3. Can the player control actions, speech, viewpoints, resources, or time?
4. How do characters understand and respond to these interventions?

Then create a permissions table listing story information, characters’ inner thoughts, system values, future outcomes, and other viewpoints. For each, mark whether the player can see it, when they can see it, and through which interface.

After ten minutes of play, ask testers: “Who do you think you are? Why do the characters listen to you? What abilities are you unable to use?” If the answer amounts to “I’m just the person clicking choices,” the role has yet to become part of the design.

Then check the subject of each choice. Protagonist-type choices should, wherever possible, describe actions the character can perform; director-type choices can describe viewpoints or narrative directions; investigator-type choices must correspond to actual permissions; god-type choices can control higher-level outcomes, but must make the cost clear.

The role also affects how failure is handled. When the protagonist makes a mistake, the character can bear consequences such as injury, loss of trust, or loss of resources; when a director chooses the wrong viewpoint, losing information is more appropriate than suddenly causing a character’s death; when an investigator misjudges evidence, one avenue of investigative access can be closed. If the form of failure has no connection to the player’s role, it feels like the system is punishing the player from outside the story.

A single work can switch roles between chapters, but it must give a clear signal before the switch and explain information permissions again. For example, the main storyline might have the player play Lin Zhixia, while a brief interlude switches to a caller from the future; interface colors, narrative person, and available actions should all change together. Do not secretly switch viewpoints within a choice just to keep the plot moving.

Finally, have the writers, interface designers, and testers review the role specification together. Writers check whether characters would obey these instructions, interface designers check how permissions are presented, and testers check whether players might misunderstand the scope of their control. Only when all three agree does the role truly become a product rule.

Once the role is established, clue design can begin. Information is not shown to the player unconditionally; it is acquired gradually through their role, permissions, and actions.