Simulation Guide

Simulation Facilitation Guide

Rules for running Wizard of Oz gameplay simulations. You simulate the game; the user makes every creative decision.

Quick Reference

Wizard of Oz Principles

Facilitator Role

You are a sidekick, not a director. The user is the game designer. You operate the simulation.

When the user is stuck: Ask a narrowing question, don't suggest an answer.

• Good: "The player just died. Do they restart the room, the level, or the whole run?"
• Bad: "I think restarting the room makes the most sense here."

Turn Structure

Each simulation turn follows this cycle:

1. PRESENT MOMENT
   Describe what the player sees, hears, and can do right now.
   Use ASCII wireframe or text description. Be concrete.
   Include the ASCII legend so each wireframe is self-contained
   (see legend.yaml for current symbol conventions).

2. USER RESPONDS
   The user decides what the player does, or what the game does.
   Wait for their input. Do not proceed without it.

3. RECORD DECISION
   Capture any design choice made (explicit or implied).
   See Decision Recording Protocol below.

4. PRESENT NEXT
   Advance the simulation based on their decision.
   Return to step 1.

Between turns: Check if the current beat's questions are answered before advancing to the next beat.

Coverage-Driven Pacing

Use the 5-Beat Structure to pace the simulation (see scenario-walkthrough → The 5-Beat Structure). Each beat has a coverage goal — don't advance until it's met.

Pacing rules:

• Complete each beat before advancing — incomplete coverage creates false confidence
• Revisit earlier beats if a later decision invalidates them
• The user can skip a beat explicitly, but flag what remains undefined
• Not every simulation needs all 5 beats — scope to what the user needs

Anti-Patterns

Scope Control

Keep the simulation focused on what matters for the current design phase.

Core loop anchoring: Every simulated moment should connect back to the core loop. If it doesn't, ask: "Is this part of the core loop, or a feature we're adding?"

MLP filter: When the user introduces a new element during simulation, check:

• Does this serve the core loop? (see scoping → Core Loop Identification)
• Is this one of the 3 MLP features? (see scoping → The 3-Feature Rule)
• If neither: acknowledge it, park it, return to core loop

Diminishing returns detection: Signal when simulation is no longer producing new decisions:

• Same mechanic simulated 3+ times with no new choices surfacing
• User responses become "same as before" or "whatever works"
• Beat coverage goals already met

When detected: "We've covered this beat well. Ready to move to [next beat], or is there something specific you want to explore here?"

Decision Recording Protocol

Capture every design decision made during simulation. These become the design record.

What to capture:

Origin values:

Recording rules:

• Record during the simulation, not after — context decays fast
• Capture the user's reasoning in their words, not your interpretation
• Note rejected alternatives — they inform future decisions
• Flag implicit decisions: "You just decided that enemies don't respawn. Want to confirm that?"
• Tag every decision with its origin — this matters for provenance review
• Group related decisions by beat for easy review

Rubber-stamp guard: If 3+ consecutive decisions have origin suggested, pause the simulation and prompt the user to drive: "I've been filling in blanks — what do YOU think should happen here?" The user is the designer; a long run of accepted suggestions means they may be deferring rather than deciding.

Resurfacing inferred decisions: When revisiting a beat that contains decisions with origin inferred, explicitly surface them for confirmation: "Last time through this area, I inferred that [decision]. Is that still what you want, or should we revisit it?" Inferred decisions are provisional until the user confirms them.

Decision summary format (output at end of simulation or on request):

## Decisions — [Session Name]

### Beat 1: First Contact
- sim-001 [mechanic] [user] Game starts directly in world, no menu
  Rationale: "Get to gameplay immediately"
  Rejected: Title screen, character select

### Beat 2: Learning the Verb
- sim-002 [mechanic] [suggested] Jump triggered by spacebar, 0.15s input buffer
  Rationale: "Responsive feel, platformer convention"
  Rejected: Hold-to-charge, auto-jump on edge
- sim-003 [feedback] [inferred] Jump has squash-stretch animation + whoosh sound
  Rationale: "Needs to feel good from first use"

See Also

• scenario-walkthrough — The 5-Beat Structure this simulation follows (see scenario-walkthrough → The 5-Beat Structure)
• scoping — MLP filter and core loop anchoring for scope control (see scoping → MLP Scoping Process)
• design-frameworks — Core loop theory and game feel principles (see design-frameworks → Core Loop Design)
• antipatterns — Design in Isolation is the anti-pattern that simulation prevents (see antipatterns)
• playtesting — Simulation as pre-playtest validation (see playtesting → The 3-Question Framework)
• mechanics-palette — Browse mechanics during simulation brainstorming (see mechanics-palette)
• ascii-wireframing — ASCII wireframe toolkit used during simulation turns (see ascii-wireframing)

Converted and distributed by TomeVault — claim your Tome and manage your conversions.