Check: validator, solver, critical path, heat, health, coverage

The Check tab runs the validator and the solver after every save and lays out what they found, with the world map, the puzzle graph, the content lint, the playtests and the storyboard coverage, each the same text an MCP tool returns.

What you get

A game you know can be finished from New Game (or from a checkpoint), and the list of what blocks it when it cannot: validation errors, dead ends, items never used, rooms never reached, rules nothing can trigger.

Context and versions

The local Studio, in the engine repository or a created project. True from 4.2.1. The demo Studio runs Validate and Solve in the page; the screenshot and the playtests need the dev server. The same checks on the command line: Checking your game.

Prerequisites

• The Studio running (overview).
• For Screenshot only: Playwright and its Chromium (doctor).

Where to run the commands

In the browser, on the Check tab. Each panel names the command that gives the same result in the engine repository or the created project.

Steps

1. Let it run. The validator and the solver run after every save; the tab's badge shows the result. Run again runs them by hand. Solve from picks the start: New game, or a checkpoint (an unknown checkpoint is a 400).

2. Read the solver. The validator's errors and warnings first, then the solver: finished or not, the path it found, the rooms reached, what was unlocked, the items never used and never obtained, and the dead ends (room, inventory, and the path that leads there).

3. Ask the puzzle graph (below) what hangs on a puzzle before you change it.

4. Screenshot renders a room at a checkpoint, the editor's overlays hidden, into .cache/studio/<game>-<room>[-<checkpoint>].png.

The panels

The puzzle graph

Every rule, topic, script and listener, with what it needs (grey arrows, dotted when it is read inside its commands) and what it produces (green) or consumes (red). Tap an item, flag, prop, place or event for its card: acquired by, used by, requires first, unlocks, downstream, and why the solver keeps it (critical, world, visible or dead, with the chain to the end), the same text the puzzle_graph tool returns.

Two toggles above the graph:

• Critical path fades everything that does not lead to the end, a goal or an invariant.
• Heat colours each rule, topic, listener, script and room by how many times the solver went through it. Its selector can colour the nodes by the players' sessions (the playtests) instead of the solver's runs.

Reading it before you change a puzzle. The card of the pantry key in the demo reads: acquired by give bouquet + seller; used by use key + pantry and the finale's goal; requires first bouquet, flowers_done, bouquet_given; unlocks the pantry and the end. Remove the bouquet trade and the card tells you what breaks before the solver does. The overview lists three smells:

• a thing read but never produced (a flag nobody sets);
• a thing produced but never used (a flag or item that leads nowhere);
• a flag set only by actions that already need it: it can never become true (the validator warns too).

How to design puzzles with it: Puzzle design.

Expected result, and how to check it

The tab's badge is green; the solver says it finished, with no dead end; the lint has no error. On the command line, in the engine repository:

# in the engine repository (or a created project: npm run verify)
npm run validate && npm run solve

Common errors

Files or data changed

None in the game. Screenshots go to .cache/studio/.

References

• src/studio/check.ts; the engine's tools in src/engine/tools/.
• Checking your game, Solver options, MCP tools.