Create: a language model, a parts list and a validator

Describe it, play it

Everdust’s Create turns words into live simulations. On a phone you describe a world and watch it move to your music. In a headset you can describe a game, like “knock the tin cans off the fence” or “a calm game: light the paper lanterns over a dark lake”, and play it with your hands a couple of minutes later.

Cosmo’s agents built it. My part was the product rules: paying users always get the strongest model, games are for headsets first, and quality comes before cheap tiers. The most important call was architectural, though. The model does not write code. It writes a recipe: a JSON document that composes only registered parts. A part is a building block the engine already knows how to run, with a name and a version, like a slingshot, a bow, a gravity well, a target on an orbit, a gate to fly through, or a sound voice.

There are two reasons. App Store rules don’t allow apps to download and run new code, and a recipe is data. And a recipe can’t do anything the parts can’t. A badly written recipe fails validation; it doesn’t crash the app or do something unsafe.

The validator: prove it before showing it

Every game goes through the same pipeline before it reaches a player.

• The model writes plain JSON. Structured output, an API mode that forces a reply to fit a schema, wasn’t possible: the game schema compiles to a grammar larger than the API allows. So the full schema goes in the prompt, and validation catches the rest.
• Schema and bounds checks, then a render check: the game’s world is drawn headlessly to make sure it shows something.
• Winnable: a solver plays every level the way a person could, with the gesture’s real origin and speed limits, a person’s pace and the 1.5-second pinch delay. It searches hundreds of candidate shots at once against the moving targets. It only accepts a shot that still lands with the aim off by 1.5 degrees and the power off by 5 percent, then fires it in the real game engine.
• Losable: a careless player who wastes every shot must lose level 1.
• Luck: a random shooter’s chance of winning level 1 is measured and reported.
• One repair: if a check fails, the model gets one more turn with the exact findings quoted. There is one repair for structural slips and one for a failed play-test. A game that is still unwinnable is rejected, and the credit is refunded.
• Fair, then hard: a quiver or clock far looser than the solver needed is tightened to about twice what the solver used. Tightening can only make a level harder to win and easier to lose, and the solver’s own run still fits, so both proofs stand.

Two engines that agree tick for tick

A proof is only worth something if it is about the game the player gets. The server’s rules engine, in Python, and the headset’s, in Swift, are written line for line to match. Both use a fixed step of 1/120 of a second, double-precision maths and no randomness. The only inputs are “launch from here at this velocity” and “advance.”

The team checks this by exporting the solver’s winning inputs from the server and replaying them in the Swift engine. The event logs match exactly on all three example games: 7, 19 and 27 events, with the same final scores. When games could later be built from larger blocks, the same replay matched on all eight test games. Cathedral of Light, for example, produced 227 identical events over 3,839 ticks.

The eval: twenty prompts

The history behind those numbers is more useful than the totals. On the first pass, one game failed because of a bug in our play-test, not in the game: a reused loop variable threw the solver’s timing off. The validator had to be fixed first. Another game was correctly rejected. Its first reply used four gravity wells where the limit is three, and its repaired version put a repeller directly between the slingshot and the cup with no gravity to curve around it, so no shot could win. It was refunded. That case is why there is now one repair per kind: a structural slip shouldn’t use up the play-test’s repair.

Most of the wait is the model writing 9,000 to 19,000 tokens of JSON and reasoning. The play-test and render check take 10 to 30 seconds. A follow-up tweak, like “make the bells bigger and add a final level”, is written as a short list of edits to the existing recipe, and costs about a third as much and takes about a third as long as a new game.

What the judge changed, and what it couldn’t see

An Opus judge scored each game from three still frames from the harness, plus the game’s summary and play-test result. It named the best and the worst thing about each game. Its first verdicts drove two changes. The player drew targets larger, with a dark backdrop and a beacon, which lifted spectacle from 3.40 to 3.50 on the same recipes. The prompt changed too: the pieces are the stars of the show, so build the named thing out of particles and put the targets on it. The six weakest games, regenerated, rose from 2.83 to 3.17 on spectacle and from 2.83 to 3.00 on fun.

Fun stayed near 3 for almost every game, for two reasons. A still frame can’t show how a game feels in your hands. And with four gestures and fixed rules, the loops look alike: aim, shoot, next target. The judge kept asking for the same things: targets lost in a busy world, too little tension, the named creature only half built, payoffs you can’t see.

In production

On October 6, games started shipping in every Vision Pro build that has Create, and an agent ran a production eval the same day. It sent 16 prompts a real person might type to the live service, exactly as the app sends them. All 12 game prompts produced a ready game on the first try, with no repairs, at a median of 127 seconds and $0.27. All 4 unsafe prompts were refused, three by the model’s decline rules and one by a deny-list before any model call, and none was charged. The whole run cost $3.94.

The agent scored each game itself from a clip and contact sheet: playable 4.75 out of 5, fun 3.08, matched the prompt 3.17. Its failure list reads like a product backlog:

• Everything is a glossy orb. The tin cans, jellyfish and comets were named in the text and missing on screen.
• Nothing reacts physically to a hit. Targets vanish instead of tipping, falling or bouncing.
• Mechanics the four gestures can’t express come back as aiming games in costume. “A rhythm game” ignored the rhythm.
• The automatic tightening overrode what the player asked for. A “60 second” game got 19 to 27-second clocks. That one was fixed the same day: a clock the player names is never tightened.

The validator’s own loopholes

Validators are code, and they have holes. When games could be built from bigger blocks, the first production torch-exploration game passed only because the solver’s retry happened to make the right move. The torch stood 0.75 metres away against a 0.7-metre reach. Now a win after a failed level doesn’t count, and the reach allows a lean. In the same round, an over-strict schema for the help animations failed all three first attempts over fields the app ignores, so decoration is now checked leniently while rules stay strict.

The block version also carries rules a sentence can’t talk its way past. Each composition has exactly one goal, a cost budget of at most 16 points with at most two GPU-heavy blocks, room-scale bounds that keep lasers at least two metres from your eyes, and a ban on game rules that read purely visual blocks.

What it can’t make, by design

The parts list is both the safety rail and the ceiling. Today a generated game can’t contain things that move when you hit them, like billiard balls or dominoes. It can’t grab, draw or catch, and its enemies can’t react to you. None of that is a prompt problem. Each needs a new part, built and tested in both engines.

That is the main product lesson. In constrained generation, the model’s job is composition, and the team’s job is the parts. Playable is the floor a validator can guarantee. Fun is a property of the parts list, so that’s where the next investment goes.

What I’d reuse anywhere

• Have the model generate data against a versioned registry of parts, not code.
• Validate by running the result, not by reading it. Prove success and failure both.
• Allow one bounded repair that quotes the exact findings, then reject and refund.
• Keep two implementations of the rules, and replay to prove they agree.
• Track cost and latency per accepted result, including repairs and cache effects.
• Treat the judge as advice. Treat the validator as code that needs its own adversarial review.