Skip to content

AI game master design

When an AI RPG Fails, Is the Prompt Really the Problem?

Troubleshoot AI RPG turns across prompts, API settings, and saved state, using GPT-6 Astra and Claude Opus 5.5 as examples before rewriting the prompt.

By Playworlds · Elser.AI ·

Golden routes converge across a game master's open map toward a glowing gateway, surrounded by miniature adventurers and dice.

Start with the turn that actually failed

A better prompt will not repair every broken AI roleplaying turn. Imagine this illustrative scene: your ranger tries to cross a rotten bridge, the game asks for a check, and the visible die shows 9 plus 3 against a target of 15. The total is 12, yet the next paragraph says the ranger crossed safely. Before adding a louder instruction, identify where the disagreement entered the turn. This is a diagnostic example, not a recorded Playworlds failure.

Write down the player's action, the check requested, the recorded roll, the expected consequence, the narrated consequence, and the state shown after a reload. Those observations make the problem reproducible. A player can compare the scene with the visible dice result and character sheet, then describe a contradiction plainly if it affects the next choice.

Separate task wording from missing context

The wording layer asks whether the model received a clear job. Did the request ask it to narrate an already resolved failure, or to decide whether the crossing succeeded? Did it say where to stop and what to leave to the player? If those boundaries were ambiguous, state the job, required output, and facts that must be respected.

The context layer asks what facts were supplied. A narrator that never received the 12 total, target of 15, or bridge condition cannot faithfully account for them. Check the actual request payload or trace. It should include the location, relevant ability, resolved check, and established consequences. If the input is stale, correct its assembly before judging the prose.

Check settings and the API path

A model upgrade can change supported controls and tool behavior while the prompt stays identical. Check the model, endpoint, reasoning setting, output limit, schema, and tools against current documentation. OpenAI's GPT-6 guide, for example, says Astra tool calling requires the Responses API. Copying a Chat Completions tool workflow into that setup is an integration problem. This does not announce Astra as a Playworlds game-master option.

Look for an error, truncated response, incomplete tool call, or parser rejection before editing instructions. Test a minimal supported request with the same model and endpoint. If that succeeds and the full turn fails, compare payloads. If it also fails, fix compatibility or configuration first.

Follow execution before blaming the narrator

A roleplaying turn can involve a requested roll, a tool result, narration, and a save. Ask which of those steps actually completed. Did the roll produce a result, and was that result delivered to the narrator? Did the narration arrive before the roll was resolved? Was a failed save later mistaken for a completed turn? A fluent sentence is evidence that text was generated; it is not proof that the game recorded the intended state.

This distinction also applies to unattended agents. Anthropic's Opus 5.5 guide warns that a text-only end of turn can be a progress report rather than proof that a multi-step task is complete. Define RPG turn completion through application events: a resolved check, an accepted consequence, and a durable save. Do not infer all three from the model's closing words.

Inspect state and verify the result

Suppose the first response says the ranger slips and catches a cable, but reloading places the ranger across the bridge. That points toward a state or save problem. Compare the accepted dice result and permitted state change with the persisted adventure, then reopen from a clean session. If the saved state is right but the prose is wrong, inspect narration. If the prose is right but the save is wrong, inspect the commit path.

Verification should use an observable condition. In this example, success means the displayed 12 remains a failed check under the chosen rule, the narration describes a playable consequence without inventing success, and reopening the adventure preserves the same location and outcome. A single good-looking response is insufficient if a retry or refresh changes the result. Run the same small scenario after a change, and record both the expected and observed states.

A six-layer checklist for the next mismatch

Use this order when a game-master response seems wrong: (1) task wording—was the narrator asked to describe a resolved outcome or decide one? (2) context—did it receive the relevant roll and scene facts? (3) settings—were model controls and limits supported? (4) API—did the endpoint and tool protocol match the model? (5) execution and state—did each step finish and save? (6) verification—does the result survive a reload and repeatable check? Stop at the first demonstrated failure, repair it, and retest the turn.

Revise the prompt when the task or desired response remains unclear after those checks. Playworlds brings dice, character information, and ongoing adventures into one browser game; those visible pieces give players facts to compare when narration feels off. Practice writing a clear action with our guide, then choose a world to explore.