gameplay-validation · git:20260912.b630c49 · 2026-09-12 · sha256 696ca9090c507791
gameplay-validation git:20260912.b630c49A
Immutable. This exact content never changes and is served at /api/v1/blob/696ca9090c507791.
---
name: gameplay-validation
description: >
From feature tests to real playability. Use when systems work in isolation
but nobody has proven a new player can start, fight, reward, retry, and
finish. Layered tests do not replace a full playthrough. Ask the mode first.
---
# Gameplay validation
## Trigger
The build has verbs, enemies, menus. Someone says it "works". You must say what that word proved.
## Mode (ask one)
| Column | What it may prove | What it may not prove |
|---|---|---|
| logic-regression | formulas, flags, save schema | a human can finish |
| scripted-scene | one arena / one boss phase with cheats | a natural unlock path |
| real-input | pad/kb/touch/mouse on a real device | tomorrow's hardware |
| new-player-watch | first-hour confusion | endgame balance |
Teleport, wipe enemies, force boss phase, or unlock flags = scripted-scene.
Call it that in the log. Never file it as new-player-watch.
## Required inputs
Before a session starts, write:
```
build / commit
difficulty column
starting gear / recipes
device + input (kb-mouse / pad / touch)
cheats on? (teleport, god, unlock, skip)
browser / app session notes
```
Missing a line makes the session a demo, not evidence.
## Procedure
Walk the chain. Skip a box only if you mark it untested.
```
boot → teach first verb → first fight → reward → next goal
→ fail and retry → (optional) ending
```
Each box records: pass / fail / blocked / not-run, plus who was driving (human / auto).
## Attribute separately
Do not fold these into "the game is too hard":
| Bucket | Examples |
|---|---|
| game defect | wrong hitbox, lock-on flips target, music stacks |
| player strategy | they never blocked |
| setup failure | stale save, wrong language, low spec |
| harness failure | auto-pilot stuck, path blocked by a test wall, browser tab died |
Auto-play that loses lock-on, pathfinds into geometry, or drops the session is harness failure until reproduced with real input.
## Capture vs evidence
A recording that used unlock flags or difficulty overrides is a **challenge clip with adjusted unlocks**. It is not proof of a natural clear.
See gameplay-capture.
## Outputs
- Coverage matrix: chain boxes × modes
- Repro: steps, seed/save, input device
- Evidence pointer: clip / log / screenshot
- Untested range: named, not implied
## Accept
You can answer in one sentence: what was validated, by which mode, with which cheats off.
A green scripted-scene does not get written as "the game is completable".
## Cases
Optional project notes live in `docs/cases/`. Names, coords, and one-scene CPU numbers stay there. They do not become iron laws.