The checks, L0 to L5
A game is not done because its files look right. Gamewright checks every game on a ladder of six rungs, from its documents to the game playing in a browser. Each rung is a command with a report and an exit code, and a rung runs only when every rung below it is green. The Director reads these reports and can never mark its own work as passed: only the checks can.
What each rung proves
| Rung | What it does | What it proves |
|---|---|---|
| L0 spec | Reads every document: its file name, strict JSON, its schema, then the game as a whole (references, kits, events, brains, screens, builders, sounds, expressions) and what can be reached in it: every item can be got, every state of every brain can happen. In the core, in about a second. | The game is complete and well formed: nothing it names is missing. |
| L1 boot | Boots the game in the engine with no window, twice, for 600 ticks (ten seconds of play) with nobody at the keys. Both runs must end on the same state hash, with a clean log and no broken engine rule. | It starts, and it replays: the same game and the same input always give the same play. |
| L2 play | Plays every Playtest: the game's own path through it, the monkey (a bot that presses everything at random, on several seeds), the template's bot that plays like a newcomer, with a person's reaction time and fumbles, and an explorer that searches for states. Asserts and metrics are checked on every run, and the engine's rules on every tick. | It can be played and won, nothing crashes or gets stuck, and what worked before still works. |
| L3 frames | Draws shots at named moments in the real player and checks each picture: not blank, changed after input, the subject in view and readable against the ground around it, every text whole and big enough to read. Then again as a phone held upright shows it, beside its touch controls. | A person can see what they need to see, on a monitor and on a phone. |
| L4 judge | Asks a vision model questions about L3's pictures that the engine can check: where is the player, where are the threats and the goal, what is the player to do. Finding the player gates; the rest is advice. | Someone new to the game would know where they are and what to do. |
| L5 web | Plays every Playtest's tour in a headless Chromium, on the game's web build, and needs each to end on the same state hash as the desktop. | The game plays the same in a browser as on a desktop. |
After the ladder comes you: no check replaces playing the game yourself.
The ladder catches real bugs at the rung where they show. Thirteen bugs planted on purpose, from a win that needs an item nothing gives to a threat the colour of the ground and a line of text cut off on a phone, are each caught at their rung and not before (how it was built).
Run the checks
In the Studio, Game ▸ Check the documents is L0 and Playtest (F6) runs L0 to L2. Their results are in the console under the game: Checks has a line for each rung, green when it passed and red when it did not, then the headline; Problems lists each problem found, and a click opens its document at the field; Playtests shows each playtest with how it last went, and runs one alone.
From a terminal, with the gamewright command line that came with the Studio
(installing says where it is):
gamewright validate ~/Documents/Gamewright/Tideline # L0
gamewright verify ~/Documents/Gamewright/Tideline # L0 to L2
verify --level runs every rung up to the one it names. L4 runs only when it is named, because it
costs money: it calls Anthropic's API with ANTHROPIC_API_KEY, or else your own Claude Code, and
stops at --judge-budget (one US dollar unless you say otherwise). --json prints the whole
report.
L3 draws real frames and L5 plays the game's web build in a headless Chromium. For now both are
run from a checkout of Gamewright's source, by its contributors: there, node core/src/cli/main.ts verify --level L3 <game> runs L0 to L3, and --level L5 runs L0 to L5 without L4.
tools/doctor.sh says if Xvfb and Mesa (for L3 on Linux) or Chromium are missing, and
tools/heavy.sh tools/export.sh web makes the web build; when the build is missing or out of
date, L5 says so and how to make it.
When a check is red
The report says where. A red L0 names the file, the line and column, the JSON pointer inside the document, what is wrong and, where it can, a fix:
recipes/campfire.recipe.json
17:15 error /inputs/0/item no Item has the id "item.driftwod" [ref.unknown]
hint: did you mean "item.driftwood"?
A red L1 or L2 says which Playtest failed and why: an assert, a broken engine rule and its tick,
a goal the bot could not meet. --json has every run in full, with its seed. Every run replays
exactly from its seed and its input, so a failure seen once can be watched again.
On every change
Every change the Director proposes is checked before you see it. When it touches anything the game runs, L0 to L2 run on the game as it would be and on the game as it is, so a Playtest that was green and turns red is named at the top of the proposal. A change only to how the game looks or sounds (its style, models, sounds, music, screens) must end every Playtest on exactly the same state as before, or it is red: a new look may never change play.
So each time a feature works, keep it working: ask the Director for a Playtest that proves it. Every later change runs it again.