| name | playtest-iteration |
| description | Turn level playtest observation into prioritized spatial, encounter, signposting, pacing, and balance changes without designing by anecdote. |
Level Playtest Iteration
Use when a playable level has reached the point where external player behavior should drive iteration.
Procedure
- Define the playtest questions and player cohort before testing so observation targets real uncertainties.
- Use a stable build or blockout revision and record player context, prior knowledge, route taken, deaths or failures, completion time, and material interventions.
- Observe behavior before asking opinions: hesitation, missed routes, exploit strategies, repeated failures, unused options, camera problems, and resource patterns.
- Ask follow-up questions after the relevant moment to understand player intent without coaching them during play.
- Separate one-player preference from repeated behavioral evidence and from hard defects such as softlocks or unreadable objectives.
- Prioritize changes by impact on the level's goals, frequency, severity, and cost or risk of the fix.
- Change the smallest spatial or systemic cause that explains the problem and avoid simultaneously rewriting unrelated sections.
- Re-test the changed section with fresh players when possible and compare against the original behavior.
Decision rules
- Observed behavior usually carries more diagnostic value than general post-test preference.
- Do not fix every player failure; some are the intended challenge.
- Repeated designer intervention is evidence the level is not communicating independently.
- Keep build or revision context so conflicting playtest results can be explained.
Quality gate
Iteration is complete when findings trace to observed behavior, changes target prioritized causes rather than anecdotes, the revised level is re-tested, and unresolved risks or intentionally accepted player failures are explicit.
