Metlivi Blog

How to Teach Players What NPC Conversations Can Do in a Game’s First Chapter

For a narrative game designer, the first chapter has a specific job: help players understand what they can ask an NPC, what an answer can change, and what happens when the character lacks enough information. Teach those rules through one optional, low-stakes conversation that players can try and inspect. Keep it separate from the opening controls tutorial: the goal here is to establish the boundaries of conversation, not explain movement, menus, or combat.

September 27, 20269 min readReading, Arts & CultureBy Metlivi Editorial Team

Open Products Back to blog

Section 1

What should the first chapter teach about AI conversations?

Teach a small, accurate set of expectations rather than promising that players can ask anything. A player should be able to tell:

These are promises about this game’s conversation system, so make them match its actual implementation. If only certain subjects or actions are supported, show that limit before inviting free-form input. Avoid a character claiming that every question has a meaningful answer if the system cannot deliver one.

**What kind of input is accepted:** for example, choose a suggested topic or type a short question.

**What the NPC can discuss:** such as a person, place, or event the character has encountered.

**Which responses affect the game:** distinguish information or flavor dialogue from an action that changes a tracked state.

**What the character does not know:** unanswered questions should receive a clear, in-character boundary rather than an invented fact.

**How to experiment safely:** show one sample question whose result is easy to understand and does not commit the player to a major choice.

Section 2

A short playable sequence for the first chapter

Use a moment the player can reach during ordinary play, after the controls are available and the story has introduced a character with a reason to talk. The following sequence is a design example; adapt the names and state labels to the game.

This sequence teaches through a concrete interaction: a supported information question, a visible action boundary, an optional state-changing choice, and an exit. The state labels here are an illustrative design device, not a claim about a particular game engine or implementation.

**Offer an optional conversation.** A courier named Iven is waiting beside a sealed gate. A visible interaction prompt says, “Ask Iven about the north road.” The player can walk past and continue the chapter. No required objective depends on opening the dialogue.

**Show the boundary in context.** When the player interacts, Iven says: “I can tell you what I saw on the north road. I can’t open the gate or know what happened after I left.” A compact interface cue marks two possible topics: “Road conditions” and “The gate.” A small label or icon distinguishes “conversation” from “world action.”

**Let the player try one safe sample question.** Offer a suggested question: “Was the north road blocked?” Iven answers with a known detail: “A fallen cart slowed people down this morning, but I passed before noon.” The response is useful, bounded, and not itself a world-state change. If the player asks the same thing in their own words, the system can demonstrate that supported questions need not use one exact phrase.

**Show a real state change separately.** The player can then ask, “Can you move the cart?” If Iven can do so, the game should present a clear action choice such as “Ask Iven to move it.” After confirmation, the game records the relevant state—perhaps `cart_moved = true`—and shows the consequence in the world or conversation. If no action is available yet, say what condition is missing.

**Close without forcing completion.** The player can leave at any point. The chapter continues whether they asked one question, explored several topics, or skipped the conversation.

Section 3

How to make state changes legible

Separate three outcomes in both writing and interface design:

Information: “The cart was blocking the north road this morning.” — The NPC shared information; no world action is implied.

Acknowledgment or flavor: “I’ll remember you asked.” — Unless the game tracks a consequence, this is dialogue only. Do not imply a hidden effect.

State-changing action: “I’ll move the cart.” — An action is available, and the game will update a named or observable condition.

Section 4

Show the consequence of an action

A useful rule is to attach action language to an explicit choice and follow through with visible evidence: a changed object, updated journal entry, new route, or clear confirmation. If an action requires a key, prior clue, relationship flag, or chapter milestone, make the requirement understandable when it blocks the action. Do not tell the player that an action happened when the relevant state did not change.

Section 5

Map supported NPC interactions before writing

For a small first-chapter encounter, a designer can map each supported interaction before writing the dialogue:

This simple map makes it easier to keep dialogue consistent with the game state and to catch accidental promises in the prose.

**Topic:** What is the player asking about?

**Knowledge source:** Why would this character know the answer?

**Precondition:** What facts or state must be true for the response to be available?

**Outcome:** Does the reply only provide information, or does it change something?

**Fallback:** What should the character say if the question is outside the supported scope or the required information is missing?

Section 6

What should an NPC say when it does not know?

An NPC should be able to distinguish **not knowing**, **not being able to act**, and **not understanding the question**. These are different player-facing outcomes and need different responses.

The fallback should not invent a clue merely to keep the conversation flowing. It also should not punish the player for testing the interface. Keep the tone consistent with the character, but make the practical result plain: the answer is unknown, the action is unavailable, or the wording needs clarification.

**Knowledge limit:** “I haven’t been past the eastern bridge.” This states the character’s perspective and avoids guessing.

**Missing game information:** “I don’t know who took the key. I haven’t seen it since yesterday.” Use this when the game has not established the fact or the character has no basis for it.

**Action unavailable:** “I can’t move the cart while the gate crew is using it.” If there is a condition that can later change, name it where helpful.

**Unclear or unsupported request:** “I can answer questions about the road and the gate. What would you like to know?” Offer a supported direction rather than a vague error.

**Repeated or irrelevant question:** Give a brief response that preserves the boundary, then let the player try another topic or leave.

Section 7

Keep the conversation optional and lightweight

Make the invitation easy to notice, but allow players to ignore it, leave early, or stop after the sample. If the information is needed to complete the chapter, provide another route to it or make the conversation a clear, intentional requirement; do not disguise a mandatory gate as optional. Avoid requiring players to exhaust every topic just to discover which ones matter.

A brief visual cue can help distinguish input types: suggested topics, a free-text field, and action choices should not look interchangeable if they have different consequences. Keep instructions close to the relevant interaction. The paper [“Less Text, More Visuals”](https://aclanthology.org/2022.games-1.3/) reports a qualitative study with 12 players of linguistic and language-learning games; participants expected visuals and found too much onboarding text overwhelming, while also identifying problems with linguistic context and feedback. That is a narrow study of a GWAP for NLP, not proof that every game needs less text or that the same approach will work across genres. Treat it as a reason to test, not a universal rule: make the cue clear, then check whether players understand it in your own game.

Research on dialogue grounding offers a related but distinct lesson. In [“A Framework for Exploring Player Perceptions of LLM-Generated Dialogue in Commercial Video Games”](https://aclanthology.org/2023.findings-emnlp.151/), 28 players recruited from a *Disco Elysium* subreddit evaluated dialogue in a recreated RPG conversation interface. The authors report that the original designers’ prose was significantly preferred to GPT-4 generations, with participants citing logical flow and grounding in game state. This was an evaluation of dialogue, not a first-chapter onboarding test. It supports paying attention to coherent, state-aware conversation, but it does not establish how to teach conversation rules to all players.

Section 8

Check whether players learned the right rules

After building the sequence, observe whether a new player can answer four practical questions without a long explanation:

Look for mismatches between what players infer and what the system actually does. If they assume every answer changes the world, strengthen the information-versus-action distinction. If they think a refusal is a bug, make the boundary or available topics clearer. If they believe the sample question was mandatory, revise the prompt and ensure the chapter can proceed without it.

The first chapter does not need to explain every possible dialogue path. It needs to let players try one representative, low-stakes interaction, understand its outcome, and see how the NPC handles a limit. Once those rules are clear, players can explore further conversations with a more accurate sense of what their questions can do.

What can this character discuss?

Which choice, if any, changed the game state?

What does the character do when they do not know an answer?

Can the player leave or skip the conversation?