Validate level blockouts in play, not only in plan views

On this page

The principle

Judge a level blockout through the playable camera and controls before committing to expensive detail. Treat its drawing as a hypothesis, not proof that the space works.

Applies when

Building or substantially changing navigable levels, encounters, or traversal challenges.

Does not apply / Exceptions

A blockout cannot settle questions whose essential cues are missing. Include representative lighting, sound, or interaction feedback when those are part of the test. A visual concept study answers a different question.

Rationale

A plan communicates connections but cannot establish the experience of traversing them. Play reveals collision, timing, visibility, and scale problems that an editor flythrough can hide.

Implementation

Name the experience and one observable uncertainty.
Build a short playable route with working collision and movement.
Traverse it under player constraints; record failures before decorating.
Ask an unfamiliar tester to try it. Distinguish usability failures from misunderstanding caused by placeholders.
Change the relevant geometry or cues and repeat.

Disagreement

Early rough tests expose spatial problems cheaply; more representative presentation can be necessary for audience-facing tests. Choose fidelity to match the question, not a universal production order.

Notes

Confidence 3: source-checked practitioner guidance, not controlled evidence that one workflow fits every genre. This is the spatial application of PROTO-0003, with a specific acceptance test.