Which Player Decisions Should Game Characters Remember?

Choose decisions by their later payoff

A decision earns a place in a character’s memory when recalling it changes the present scene. Before saving a choice, ask: What can this character do, say, reveal, refuse, or offer differently because of it? If the answer is “nothing,” the information may belong in a quest log or world-state record, or may not need to persist at all.

A practical test is to write the later beat first. For example: “At the checkpoint, the guard trusts the player with the sealed ledger because they returned his badge earlier.” If the beat depends on a remembered decision, save the relevant fact. If the guard behaves the same either way, the memory may be decorative rather than dramatic.

Useful memories often fall into three overlapping groups:

**Commitments and costs:** the player promised, refused, sacrificed, returned, or protected something, and the result can matter later.

**Revealed priorities:** in a constrained choice, what the player chose to protect or risk helps shape how a character interprets a later offer. Treat this as evidence from a specific choice, not a permanent diagnosis of the player.

**Unresolved consequences:** a choice left a person, object, or obligation in a changed condition. The memory matters when a character later encounters that condition or decides what to do about it.

These are design heuristics, not claims that every game needs persistent character memory. Their value depends on whether the later scene gives the remembered event a legible consequence.

Separate memory from world state and rumor

A reliable narrative system distinguishes the event from each character’s knowledge of it. A player might secretly hide a key (world state); a companion might see the hiding (character memory); a shopkeeper might hear an inaccurate account (rumor). Collapsing these into one flag can make characters seem omniscient or make hearsay feel like proof.

For each consequential event, record enough provenance to answer four questions:

**Event:** What happened in the world?. The player returned the brass key.

**Observer:** Who directly saw or heard it?. Mara watched the handoff.

**Channel:** How did anyone else learn it?. The ferryman heard it from Mara.

**Confidence:** How certain is the information?. Witnessed; reported; disputed.

A compact design record might look like: `returned_key = true`; `Mara.knows_returned_key = witnessed`; `Ferryman.knows_returned_key = reported_by_Mara`. These are illustrative fields, not a prescribed technical format. The important distinction is that the world fact does not automatically become every character’s knowledge.

This separation gives the writer better scene options. Mara can refer to the handoff as something she saw. The ferryman can repeat it with uncertainty, ask whether it is true, or act on a mistaken version. If the player hid the key and nobody observed the act or discovered the hiding place, a character should need a plausible route to know it.

Build a choice that can pay off later

Consider a fictional scene in which the player finds a damaged signal lantern and a courier named Iven waiting behind the bars of a locked gate. The player has three choices:

**Give Iven the only working oil flask.** The signal stays dark, while Iven escapes and can later carry a message.

**Use the oil to light the signal.** A patrol sees the warning, but Iven remains behind the gate until help arrives.

**Keep the oil and leave.** The player preserves the resource; Iven’s immediate fate depends on the scene’s established rules, and the player’s absence should not be rewritten as a witnessed action.

Now decide who knows what. If Iven sees the flask given away, he remembers receiving help. If he sees the signal lit instead, he may remember the player’s choice to summon aid, while also remembering that he was left waiting. If the player leaves without being seen, Iven cannot truthfully recall the player turning away; another character might later report an empty lantern or a missing flask, but those clues do not prove who took what.

A later scene can express these differences through action rather than a recap. Iven might entrust a message to the player after receiving the oil, request an explanation after waiting for help, or respond without attributing the missing oil to the player when he did not see them leave. Those are possible payoffs for this example, not universal emotional reactions. The scene must establish why Iven responds that way, and other events may complicate his response.

Keep the memory specific: “Iven witnessed the player give him the oil flask” is more useful than “Iven trusts the player.” The first records an event and its source; the second turns one event into a broad relationship conclusion. If trust is a game variable, show the rule that updates it and the later behavior it can affect. A remembered event can inform a relationship without mechanically dictating it.

Give memories a lifespan and a correction path

Not every remembered detail should remain equally vivid forever. Set retention according to dramatic use: keep a memory while it gates a planned scene, resolves an obligation, or supports a later callback; let low-consequence details fall out when they no longer affect play. “Expiry” need not mean that a character forgets a life-changing event on a timer. It can mean the game stops carrying a minor fact into dialogue after its one intended use.

Correction matters when a memory came through rumor, incomplete observation, or a misleading first impression. A character who heard that the player took the lantern oil can learn that the player handed it to Iven. Decide what follows: does the rumor flag become corrected, does the character retain both the original report and the correction, or does the character remain unconvinced? The answer depends on the story, but the correction should not silently rewrite what the character previously heard.

A useful memory entry can include a status such as `current`, `disputed`, or `corrected`, plus the source of the update. This helps prevent a later line from repeating a disproved rumor as fact. If two witnesses disagree, preserve the disagreement where it matters instead of forcing a single omniscient truth into every character’s dialogue.

Turn memory into actionable narrative state

A character memory should connect to a possible response. Define the conditions for that response and the effect it produces: what must have happened, who must know it, and what changes in the later scene? That structure makes memory testable and prevents a choice from being saved without ever affecting the game.

This is consistent with a limited, relevant idea in [STORY2GAME](https://arxiv.org/abs/2505.03547): the paper describes generating interactive-fiction actions with preconditions and effects that guide which parts of game state need tracking and how actions change that state. Its focus is action and game-state generation, and its evaluation concerns whether generated action code supports playing through generated stories. It is not a study proving that remembered choices improve authored narrative or player experience. For writers, the useful application is narrower: specify the condition under which a remembered event matters and the concrete effect when it does.

The [StratMem-Bench paper in the ACL Anthology](https://aclanthology.org/2026.acl-long.1491/) evaluates how virtual characters use memories in character-centered conversation. Its benchmark includes required, supportive, and irrelevant memories, and reports that models handled required versus irrelevant memories better than cases where supportive memories complicated the decision. This is a virtual-character conversation benchmark, not a narrative-game outcome study. It does not establish which choices game writers should store; it does offer a useful reminder to consider whether a memory is necessary, merely helpful, or irrelevant to the current scene.

QA the remembered consequences

Test the choice at the moment it is made and again at each planned payoff. A compact QA pass can catch most continuity errors:

**Witness check:** For every line that refers to a decision, confirm the speaker observed it or can name a plausible information source.

**Branch check:** Play each choice path and confirm it sets the intended event and knowledge records. Check that mutually exclusive outcomes do not both remain active.

**Payoff check:** Confirm each stored memory changes an available line, relationship response, scene condition, or action. If it changes nothing, reconsider whether it needs to persist.

**Rumor check:** Verify that secondhand information is presented with the right uncertainty and that a correction updates later scenes consistently.

**Expiry check:** Revisit the scene after the memory’s intended use. Confirm low-priority information can stop surfacing and essential unresolved consequences remain available.

**Absence check:** Test what the character does when the event was unseen, never reported, or deliberately concealed. Do not let a missing flag default to knowledge.

The final design question is simple: does remembering this choice give the character a reason to behave differently now, and can the player understand why? When the answer is clear, a small number of well-sourced memories can carry more dramatic weight than a transcript of every interaction.

Keep exploring this topic