I turned the design-token spec into a playable coding arcade.

Design tokens are table stakes for any serious design system, but the W3C format is hard to internalize from the source material. The spec is precise by necessity: $value, $type, group inheritance, aliases, composite types. Precision makes for an excellent reference and a poor teacher. You finish reading and you have a vocabulary, not judgment.

A game changes the unit of learning from “I read about aliases” to “I used an alias to clear the wave.” Every rule becomes a sector you cannot pass until your code actually applies it. Uncleared sectors create stakes, a fixed sequence creates a path, and pass-or-fail diagnostics create feedback. You leave with the muscle memory of having written spec-correct tokens.

Token Adventure looks like a deep-space arcade cabinet. You select sectors from a star chart, clear waves, log intel to a pilot log, and rank up from Recruit to Ace. Under that presentation, every sector is a small coding exercise running on real infrastructure. Nothing is faked: the preview is your code running, and a pass means your tokens actually satisfy the spec, not that you picked the right multiple-choice answer.

This is the heart of the project. Grading a coding exercise means inspecting code that runs in an isolated context you deliberately cannot touch from the outside. The solution is a fully serializable assertion DSL: every check is a plain data object, so it crosses the postMessage boundary into the sandbox, runs there against the live DOM and parsed token tree, and returns a plain result.

That second family is what makes the game spec-accurate rather than spec-flavored. tokenAliasResolves doesn’t look for the string {color.brand.primary} in your file. It walks the reference chain the way a real translation tool would and asserts on the resolved value. The grader understands the spec’s semantics, so the lessons cannot be gamed by pattern-matching.

The sequence mirrors how the spec has to be learned: foundations first, then the relational and composite machinery, then the real-world build, theming, migration, and audit work. You can’t reason about aliases until you can name a single token, and you can’t audit a broken library until you understand the types it’s supposed to honor.

Most learn-to-code games stop at the happy path. Token Adventure treats accessibility as a first-class concern in both directions. It is built into the product: every motion effect collapses to a static state under prefers-reduced-motion, and the celebration interstitial is a real dialog with focus management, Escape and backdrop dismissal, and a scroll lock.

And it is taught by the product. Several sectors grade the player’s rendered output with axe, contrast, and keyboardReachable assertions, holding the player to the same WCAG AA ratios and axe-core rules the app holds itself to. You learn to ship tokens that produce accessible interfaces.

The arcade is built entirely from CSS and the Web Animations API, with no game loop and no canvas. The constraint was deliberate: keep the bundle small and the Core Web Vitals clean while still earning the word arcade. Difficulty is color-coded throughout, cyan for beginner, yellow for intermediate, magenta for expert, and the color encodes the arc rather than decorating it.

The app also eats its own cooking. A game about design tokens is itself built on a real three-tier token system with light, dark, and high-contrast modes, so it practices the architecture sector 9 teaches. A tool that taught token discipline while ignoring it would not be credible.

Because the refresh was motion-heavy, I built a precision feedback loop instead of eyeballing changes: a headless-Chrome screenshot harness captures every key screen at desktop and mobile for before-and-after diffing, and a ?nomotion escape hatch freezes the reveal animations so full-page captures show the settled layout. I also held the source to zero em-dashes and en-dashes anywhere, verified by grep, and shipped only after astro check and a clean build pass.