Define what the NPC is actually doing for the player
A playable delegation should identify who makes the request, who acts, where the action travels, what change satisfies the request, and who can observe that change. “Send her to handle it” hides character will, scene resistance, and the outcome.
Use this two-column card to bound the request:
| Item | What this scene needs |
|---|---|
| Player request | One specific action with an observable result, such as bringing an actor back to the stage-left entrance |
| Executor | Why this NPC might accept and what concern belongs to them |
| Means | Skills, objects, relationships, or routes the NPC genuinely has now |
| Current place | Where the NPC begins, and where the target person and obstacle are located |
| Completion sign | A visible world change, a present witness, or an object carried back from the scene |
| Returned choice | The decision that comes back to the player after the outcome |
This is a creator worksheet. Select fields that serve the story. A single message can remain a single scene; it need not expand into a delegation system for the whole game.
Give the executor an aim, means, and place of their own
The NPC already occupies the world before receiving a request. They may be protecting a colleague, finishing a job, avoiding a risk, or keeping a boundary around what they will do. Their options also depend on tools at hand, current location, relationships, and information they actually witnessed.
Put three facts into one causal sentence: what they want to protect, what lets them act, and where they begin. An aligned request may still invite a condition. A request that demands a lie, abandons an existing duty, or assumes an ability the NPC lacks can receive a refusal. Those responses arise from this character and situation, without a universal loyalty score explaining every decision.
Location continues to matter after the NPC leaves the player’s view. They can return with words they heard, a repaired garment, or the requested person beside them. They cannot transmit a distant person’s decision directly into player knowledge through a wall.
Complete original example: ask the wardrobe lead to bring an actor back
The following scene from the fictional paper game *The Canvas Theatre* is original teaching material. No build was run and no playtest occurred. The player is the temporary stage manager. The second act is approaching. Lead actor Ke Chuan’s coat caught on an exposed wooden hook during his previous exit, and he remains in the north corridor rather than crossing that route again. A young wardrobe assistant, Hui Ya, is being blamed for carelessness.
Wardrobe lead Fang Qiao is currently at the costume table. She wants the performance to continue and also wants to stop Hui Ya from taking blame for a stage hazard. She witnessed the coat catch on the hook, has matching thread, backing cloth, and sewing tools, and knows Ke Chuan well enough to repair the coat and explain what she saw. She cannot declare the wing safe by herself, and persuasion cannot remove the hook from the world.
The player’s bounded request is: “Repair the coat and bring Ke Chuan to the stage-left entrance mark. I will decide whether to give the entrance cue after I see him return.” Completion has two scene facts: the coat is repaired, and Ke Chuan is physically present at the mark. Hearing Fang say “I’ll take care of it” records acceptance.
Make acceptance, refusal, partial work, and completion visibly different
*The Canvas Theatre* selects the following paths for this incident. These paths serve these characters and this obstacle. Other NPC requests can keep only the outcomes their situation supports.
| Path in this example | Facts the player receives now |
|---|---|
| Accepted | The player promises to deal with the hook and avoids asking Hui Ya to confess to a stage fault. Fang places thread, backing cloth, and needles in a basket, repeats that she will repair the coat and bring Ke to stage left, then leaves for the north corridor. Ke has not returned yet |
| Refused | The player asks Fang to tell Ke that “Hui Ya admitted ruining the coat” and bring him back. Fang remains at the costume table, refuses to lie, and says she witnessed the hook catch the coat. Character, garment, and entrance states remain unchanged |
| Partially completed | The player lets Fang tell the truth but has not dealt with the hook. Fang repairs the coat in the corridor and brings Ke within sight of stage left. He stops before the exposed hook. The player can see a repaired garment and a person who has not reached the mark, then address the remaining obstacle |
| Fully completed | The player first covers the hook with a cork guard from the prop box and checks it by hand, then sends Fang. She repairs the coat and returns beside Ke. He stands on the stage-left mark and signals that he is waiting for the cue. The request is complete; the player still decides when the second act begins |
Each path preserves Fang’s reason and identifies who moved where. Partial completion commits the repair and the return to the wing. It never rewrites “near the entrance” as “already on stage.”
Walk the complete path through the actual scene
The complete route begins with the player inspecting stage left. They find the exposed hook at the entrance, confirm with Hui Ya that the coat caught during the previous exit, and take a cork guard from the prop box to cover the hook. The player draws an old scrap of cloth along the route, and it passes without catching. Those actions establish a repaired route for this example. They do not repair Ke’s coat or choose for him.
The player returns to the costume table and tells Fang: “The hook is covered, and I walked the route with a cloth scrap. Tell Ke what you witnessed, repair the coat, and bring him to the stage-left mark.” Fang accepts because the request lets her protect Hui Ya and gives her a safety change she can inspect. She leaves with her sewing tools.
On the next scene update, the player hears footsteps in the north corridor before Fang and Ke appear around the corner. Ke wears the mended coat. He pauses beside the guard, touches it with the back of his hand, then steps onto the entrance mark. Fang returns the remaining thread to the costume table and tells Hui Ya, “We found the hook.” Arrival, garment, and guarded route carry the result. The distant corridor never broadcasts completion before someone returns.
This paper walkthrough checks whether the causality is complete. A real candidate still needs checks of movement, dialogue, entrance feedback, and branch state. This article contains no runtime evidence for them.
Return a decision to the player after completion
Delegation changes the current situation and creates a new decision the player can judge. When the request in *The Canvas Theatre* is complete, Ke stands at the entrance mark, the coat is repaired, and the route is guarded. Fang has not issued the stage cue on the stage manager’s behalf.
The player now hears the orchestra in the latter half of its transition and sees Hui Ya signal that the next cloak still needs its clasp. The player can cue Ke immediately and preserve the current musical handoff, or signal the orchestra to repeat the transition, let Hui Ya secure the cloak, and then cue the entrance. Both options read the achieved result and create different backstage pressure. These are author choices for this example, not a claim that every completion needs a binary choice.
Refusal and partial work also return actions. After Fang refuses to lie, the player can acknowledge the stage hazard and cover the hook, or use the understudy who is already present. When Ke reaches only the hook, the player can repair the route or change the entrance for this act. The NPC response brings the problem back into a playable scene, leaving the player as the next actor.
Repair common breaks in NPC delegation
| Break | Repair for this scene |
|---|---|
| “Leave it to me” instantly opens a completion notice | Treat acceptance as departure, then let people, space, and obstacles produce the outcome |
| The NPC has no reason of their own | Give them one thing they are protecting or completing, so conditions, refusal, and cooperation grow from character |
| A distant result enters the player’s mind | Bring back a witness, show the target person arriving, or let the player visit the changed place |
| Partial work is presented as full success | Name the change that occurred, where progress stopped, and what the player can do now |
| The NPC also makes the player’s next decision | Stop at the agreed result and leave the cue, disclosure, delivery, or continued inquiry to the player |
| Every delegation has the same outcomes | Keep only paths that this character and request can genuinely produce |
From the same starting point, walk one refusal, one obstructed path, and one completion. Compare location, possessions, witnessed information, and the player’s next action. This comparison can expose contradictions on paper. Natural dialogue and the felt weight of a choice still require observation in a real candidate.
FAQ
Can the game jump to the result after an NPC agrees?
You can omit travel with no decision value while preserving the people, space, and resistance that can change the outcome. The destination scene should identify who arrived, what changed, who witnessed it, and what the player decides next.
Does every delegation need refusal, partial, and full completion?
No. This example uses those paths to show meaningful differences. A linear story can keep one valid route when NPC will, relevant resistance, actual outcome, and the next action remain clear.
Do it with the skill
With SOURCE_BIBLE.md, a selected CONCEPT.md, and PRODUCT_BRIEF.md in place, use /game-world-design ($game-world-design in Codex) to design this NPC delegation scene. Define the player request, the NPC’s own aim and means, current place, relevant resistance, player-visible outcome, and returned choice. Deliver the scene causality inside GAME_DESIGN only; do not claim it has been built or playtested.
Read the method: Executor, route, witnesses, and return points for delegated actions · Player action, world change, readable feedback, and later opportunities · Game experience and world-design workflow