| name | gap-checker |
| description | Validates that a generated game is actually playable — not just that it boots. Static analysis flags unreachable goals, oversized gaps, broken borders, and isolated regions in level data. Dynamic analysis fuzzes inputs in headless browser to detect stuck states, unreachable win conditions, and physics anomalies. Visual analysis captures screenshots for VLM (vision) review. Use after codesmith writes Game.js and playtester confirms the smoke scenarios pass. |
Gap Checker — Playability Validation
playtester checks "does it boot and respond to input." gap-checker checks "is the game actually playable" — can the player reach the goal, are there dead-end regions, do platformer jumps actually clear the gaps the architect drew?
Patterned after the OpenGame-Bench evaluation pipeline (Build Health + Visual Usability + Intent Alignment via headless execution + VLM judging). Static analysis covers Build Health for level structure; dynamic + visual cover Visual Usability and Intent Alignment.
When to use
After codesmith and playtester. Always before declaring a game complete. The orchestrator should treat gap-checker failures as ordinary refinement targets, just like playtester failures — feed them to level-fixer (for level/world issues) or refiner (for code issues), iterate up to 3 times.
Three layers
1. Static (scripts/static_check.mjs)
Pure JS, no browser. Walks levels.json + gdd.json:
| Check | What it catches |
|---|
| BFS reachability | Pickups / goals on tiles disconnected from the player's spawn region |
| Border integrity |
