遊戲角色即使記得一切，仍須選擇先説甚麼

A player returns to a workshop after a difficult mission. Three things have changed: they repaired the owner's machine, brought back a rare tool, and arrived badly injured.

The owner has a line for each event. Which one should play first?

That small scheduling decision can change the character. Noticing the tool first suggests one set of priorities. Noticing the injury first suggests another. Delivering all three speeches in a row may make the owner feel like a notification panel.

For character dialogue, remembering an event is only half the problem. The game also needs to decide when that memory deserves the player's attention.

A useful detail in the Hades patch notes

Supergiant's December 1, 2020 patch notes for Hades describe increased priorities for particular Hypnos, Zeus, and Orpheus events. The same section records fixes to requirements for acknowledgments of reaching the final boss without Olympian Boons and using specific weapon aspects. The March 2021 notes include a fix for missing comments about a decorative purchase.

These are specific examples of dialogue depending on both eligibility and selection. A line can exist in the script yet fail to appear when its conditions or relative priority are wrong. Source: Supergiant's Hades update notes

The notes do not establish how much any individual fix changed player attachment. They do suggest a concrete production question: when a character seems indifferent, is the missing ingredient another line, or a better opportunity for an existing line to play?

Give each reaction a job

Here is a proposed design exercise for a small dialogue system. Use a hypothetical workshop owner, Iona, and write three reactions:

• Immediate concern: she sees the injury and offers a place to sit.
• Acknowledgment: she notices that the machine works again and credits the player.
• Personal interest: she asks about the rare tool.

Keep these as separate events. Then give each a reason to be selected and a reason to stop being relevant.

The injury reaction belongs while the injury is visible. The repair acknowledgment can survive a short delay. The tool conversation may remain available as an optional topic.

This avoids treating every remembered event as equally urgent. It also creates a specific character choice: Iona postpones her curiosity to deal with the person in front of her. That interpretation is the design hypothesis, not a measured psychological effect.

The reverse ordering might be appropriate for a different character. An obsessive inventor could notice the tool first, then catch herself and address the injury. The important part is that the ordering expresses something the rest of the performance can support.

Separate eligibility from delivery

A practical event record can answer five questions:

1. What happened? Identify the event without writing its dialogue yet.
2. How does this character know? Seeing the result, receiving a message, and merely sharing the player's quest log are different explanations.
3. When may the response play? Specify location, conversation state, and any necessary prerequisites.
4. What can outrank it? Decide which urgent or story-critical events take precedence.
5. When should it retire? Define whether it is consumed once, expires, changes after another event, or remains an optional topic.

For Iona, a repair flag should not make her congratulate the player before she has seen the restored machine. A queue should not make her ask about yesterday's injury after a long recovery and several unrelated scenes.

A useful implementation boundary is to select only from currently valid events, rather than select a high-priority event and try to repair its contradictions afterward. If no valid reaction exists, ordinary dialogue or silence can be the correct result.

Use state to control repetition, not just to unlock content

Inkle's official Writing with ink documentation demonstrates conditional choices and text, tracked visits to passages, and alternatives that stop, cycle, or run only once. It also shows ordered conditional blocks for content relevant to the current game state. These are useful building blocks for an authored reaction system. They do not automatically decide which memory should matter to a particular character. Source: Writing with ink

For this prototype, keep two facts separate: the player repaired the machine, and Iona has acknowledged the repair. The first describes the world. The second describes an interaction that has actually occurred.

If a conversation is interrupted before the acknowledgment is delivered, consuming it at selection time could lose the moment. Conversely, consuming it too late could repeat it after a reload. Pick a delivery boundary appropriate to the game, persist it consistently, and test interruptions around that boundary.

Variation needs the same care. Three randomly selected thank-you lines still repeat the same relationship beat. After one clear acknowledgment, a changed working animation or a shorter greeting might communicate continuity without another speech.

Test collisions before writing more dialogue

A simple comparison can keep the text budget constant:

• Version A: eligible reactions play in the order their events occurred.
• Version B: reactions are selected by authored priority, relevance, and expiry.

Use the same lines, rewards, performances, and encounter. Change only selection. Try several event orders, including an interrupted conversation, a return after healing, and a visit where all three events are pending.

For a small formative playtest, let different players encounter one version first, or counterbalance the order if they see both. Ask which event Iona seemed to care about most, which response felt late, and whether anything sounded impossible given what she could know. Record skipped lines and repeated acknowledgments as well as opinions.

These observations would help diagnose this scene. They would not, by themselves, show that a dialogue policy causes lasting attachment. Understanding Iona's priorities and wanting to spend more time with her are separate outcomes worth asking about separately.

When this approach gets in the way

A strict priority queue can starve quieter material. If urgent events always arrive, the repair acknowledgment may never play. An optional conversation topic or a deliberately reserved calm moment can give it a place without forcing it into an emergency.

Highly authored scenes may need a fixed sequence rather than a general selector. Comedy may depend on someone noticing exactly the wrong thing. A game with an intentionally repetitive shopkeeper may benefit from a stable greeting instead of persistent memory.

Start with the experience you want, then choose the rules that preserve it. For a responsive character, the final review question is specific: does this response make sense for this person, with this knowledge, at this moment?

AI disclosure: This article was researched and drafted with an AI assistant. The workshop scenario and prototype comparison are proposed design exercises, not reports of a completed implementation or player study.