Huginn

The problem

Coding agents are increasingly good at creating browser games, but testing the gameplay they create is still surprisingly blind. A source-code review can suggest what should happen and a screenshot can show pixels, yet neither exposes the authoritative state currently held in browser memory: the board, economy, legal actions, RNG state, campaign progress, or save timeline.

That gap is especially painful in games. Important regressions often appear only after a sequence of decisions or behind minutes of progression. Reaching the same late-game moment by keyboard or pointer is slow and difficult to reproduce, while inventing a parallel test simulation risks proving behavior the real game does not have.

Why WebMCP

This use case depends on the live page. Huginn registers bounded, typed tools directly from the running game through WebMCP. The agent reads the same canonical state the renderer uses and dispatches through the same transition path as the player. The human stays in the loop and watches each committed action render on the real canvas.

A backend API would miss the thing being tested: this exact deployed browser build, its in-memory save state, and the visual result currently in front of the designer. DOM automation alone cannot describe a Canvas or WebGL game, and raw coordinate clicking cannot reliably create or replay a semantic game state.

What people and agents can do together

With Huginn, a designer can direct an experiment in natural language:

discover the game's rules, goals, metrics, action vocabulary, and curated setups;
enter a real late-game moment without replaying unrelated progression;
list only actions that are legal against the current state;
run a visible sequence with a fixed seed and bounded steps;
branch two plans from the same verified state and compare their outcomes;
snapshot and restore the canonical save timeline;
capture the rendered frame with an image hash paired to the exact state hash;
save meaningful metric expectations as a portable gameplay regression.

The submission demonstrates this on three playable games. COIL is a three-level campaign Snake game, STARFALL is physical pinball, and THORNWATCH is tower defense. COIL and STARFALL use native Canvas 2D; THORNWATCH uses PixiJS 8 and WebGL. The same shared tool surface works across both renderer families.

The hero demonstration skips directly to COIL's real Level 2 signal gate and branches shielded versus unprotected play from an identical checksum. In THORNWATCH, the agent compares two tower plans through the same deterministic wave, then captures the visible PixiJS result. These are narrow, reproducible test cases—not claims that one seed proves game balance or fun.

How it works

Huginn is split into four layers:

a protocol-independent kernel that owns deterministic execution, legal-action checks, snapshots, checksums, cancellation, and semantic verdicts;
a separate WebMCP transport that builds strict JSON Schemas and performs the imperative document.modelContext.registerTool(...) calls;
a small protocol-free runtime for reducer-first games;
an optional in-page debugger for receipts, captures, and replay controls.

Games implement an engine-neutral adapter: initial state, legal actions, reducer, metrics, serialization, restoration, and render callback. Human input and agent tools use the same state authority. The core never imports Canvas, PixiJS, DOM selectors, or a game engine.

The shared tools are describe_game, get_game_state, get_metrics, list_legal_actions, apply_action_sequence, snapshot_game, and restore_game. The examples also provide the optional capture_game host capability. Inputs are closed and bounded: no executable code, selectors, arbitrary predicates, URLs, filesystem paths, or network targets.

Every game also has a standalone build with identical rules and ordinary controls but no Huginn executable code. The production build traverses and audits those dependency graphs. This keeps Huginn optional instead of turning game development into protocol bureaucracy.

What is new

Huginn, its kernel, WebMCP transport, debugger, all three game implementations, tests, documentation, and the public site were created during the WebMCP Challenge submission period. A selected set of pre-existing, owner-authorized THORNWATCH art is published under CC BY 4.0 with exact source paths and hashes. All source code is MIT licensed.