AI game master design
Structured Outputs or Prose for an AI Game Master?
Learn where structured AI output helps an RPG, where prose still matters, and why the game engine must validate dice, permissions, and saved state.
Give structure and story different jobs
An AI game master needs to understand what a player attempted and tell a compelling story about what happened. Those are related jobs, but the same paragraph should not be the sole source of rules and saved state. Structured output can make a model's proposed decision easier for a program to inspect. Prose gives the player atmosphere, dialogue, and a clear next choice. Neither format makes a generated claim true on its own.
Picture an illustrative scene: a rogue reaches a sealed vault and says, 'I use a small mirror to inspect the glyphs before touching the lock.' The game might identify an investigation attempt, decide whether a roll is required, resolve any dice, and describe what the rogue learns. If a model writes 'You find the release mark and open the vault' before resolution, fiction has outrun mechanics. This is a design example, not a record of Playworlds production behavior.
Use a small schema for proposed decisions
A structured proposal could contain the attempted action, target object, possible check, relevant rule reference, and uncertainty requiring a decision. For the vault, it might identify inspection with a mirror as the attempted action and suggest a perception or investigation check. It should not assert a die value, grant an item, move the character, or mark the vault open.
OpenAI distinguishes function calling, which connects a model to application tools, from a structured response format, which shapes what the model returns. Its Structured Outputs guide says a supported strict schema enforces schema adherence, but also warns that structured results can still contain mistakes. For game design, that means a valid field such as 'check_required: false' is still a claim to review against rules and state. A parser passing is only the first gate.
Keep dice and state under game control
The engine should own the facts that determine an outcome: character abilities, inventory, available actions, dice, target values, and the accepted change to world state. In a proposed workflow, the model can request a check or describe why it might matter. The application verifies that request, performs or records the roll, and returns the resolved result. Only then does narration describe the consequence. A companion character can react to a completed check without creating another roll or rewriting it.
Suppose the accepted result is 11 on the die plus 2, below a target of 16. The narrator may say the marks blur in the mirror, the lock stays sealed, and the rogue can consult a sketch, ask a companion, or try another tool. It must not quietly turn 13 into success. If the rule allows a partial outcome, the engine should authorize it before prose presents it as fact.
Write prose after the result is known
Narrative output has a different acceptance test from the structured proposal. It should acknowledge the attempted method, respect the resolved result, preserve the NPCs' knowledge, and end at a useful decision point. It can describe the chill of brass near the rogue's hand without claiming that a new wound, condition, or item has been added unless the state update permits it. The scene can stay vivid while the engine remains the authority on mechanics.
This separation makes corrections easier. If the proposed check was wrong, change interpretation or rule mapping. If the check and state are right but the scene is dull, improve the narration brief. If prose contradicts the roll, inspect narration input and postprocessing. Compare outputs against the same saved scene.
Handle invalid and uncertain responses
A schema needs an explicit path for uncertainty. The model may be unable to tell whether the player is asking a rules question, taking an in-world action, or describing several actions at once. Let it return a bounded 'needs clarification' or 'no check proposed' result rather than forcing a confident rule choice. Validate referenced character IDs and scene objects against current state, and reject changes that exceed the allowed action. A schema cannot prove that an object actually exists in the adventure.
A refusal, incomplete response, unsupported schema, missing tool result, or stale scene version should not silently become an accepted story event. Record a safe reason and retry within defined limits; otherwise ask for a clearer action or show a recoverable error.
A practical acceptance checklist
Before accepting a generated turn, check: (1) Did the proposed action match the player's words? (2) Did each referenced character and object exist in the current scene? (3) Did the engine decide whether a roll was needed and record the result? (4) Were state changes validated and saved once? (5) Did the prose match those accepted facts and leave the next choice to the player? (6) Can a reload reproduce the same location, roll, and consequence? These checks are a design recipe, not a claim of measured Playworlds performance.
Players need to see what their character tried, what the rules resolved, and what choice remains. Playworlds presents worlds, character sheets, dice, and continuing adventures in one place. Try a small action, then compare the response with visible game state. Our action guide helps make that move specific.