Descent — Opus 5 shipped a cel-shaded downhill BMX racer from one prompt
Reported by the author — we did not run this. What that means
Output

The prompt that built Descent
Build me a cel-shaded downhill BMX racing game in Three.js — four riders tearing down a mountain, point to point, at a level of craft above what a AAA studio would ship. Not a demo, not a prototype. A finished game that looks like a piece of published anime-styled game art in every single frame. The bar for this project is not "good for a browser game." The bar is that someone watching a clip of it cannot tell it was made in a browser, and someone playing it forgets to ask. Non-negotiable constraints Stack: Vite + Three.js (latest r1xx), TypeScript, ES modules. I run npm install, then npm run dev, and I'm playing. Nothing else to configure. Zero external assets. No downloaded models, textures, HDRIs, fonts, or audio. Every mesh is built in code, every texture generated in-code (canvas 2D or noise in a shader), every sound synthesized with the Web Audio API. If your own code didn't generate it, it doesn't ship. Target hardware: MacBook M5 Pro, Chrome. A locked 60fps at retina resolution, no exceptions, no frame spikes on jumps or crashes. Use instancing, a terrain clipmap, frustum culling, and adaptive pixel ratio. A beautiful game that hitches is a failed game. Art direction — NPR, and I want it pushed further than anyone pushes it in a browser The whole game is non-photorealistic rendering, anime cel-shaded. Guilty Gear Xrd's ink discipline, Lonely Mountains' terrain readability, the color energy of a Studio Ghibli mountainside. Zero PBR realism. If any surface in the final build reads as physically based, the art direction has failed. Build a real, unified NPR pipeline — not a shader stuck on a few meshes: Ramp / step lighting as the foundation. Custom ShaderMaterial with 3–4 band gradient ramps, NearestFilter, no interpolation. Per-material control over band thresholds and band colors, so rock, dirt, foliage, skin, and metal each get their own tuned response instead of one global look. Tune by eye against captured frames. Two cooperating line systems. Inverted-hull outlines on riders, bikes, rocks, and trees — vertices pushed along smoothed normals, BackSide, width scaled with view distance so screen-space thickness stays constant. Plus a screen-space Sobel edge detect over an MRT normal+depth prepass for interior lines the hull can't produce. Tune them so they never double up into muddy black. Variable line weight. Modulate outline thickness by surface curvature and by distance so lines taper and thicken like a hand-drawn stroke. This one detail is the difference between "toon shader" and "drawn." Stylized shadow interior. In shadow bands, blend in a screen-aligned hatch or halftone pattern at low opacity rather than flat darkness — the way a cel background painter fills a shadow. Subtle. It should read as texture, not as a filter. Fresnel rim light on riders and bikes so silhouettes cut cleanly against terrain at every camera angle. Banded specular with hard-edged highlight shapes on frames, helmets, and wet rock. Fake reflections with a matcap or ramp — never a cubemap probe. Quantized atmospheric depth. Distance fog stepped into discrete bands so far ridges read as flat paper layers stacking into the haze — the classic anime mountain composition. This is what will make your wide shots look painted. Sky and light: gradient sky dome shader, hard-edged cel clouds drifting at two parallax depths, geometric sun shafts through the tree line, a hard-threshold bloom that stays graphic rather than photographic. Generate a color-grading LUT in code and apply it as a final pass. Pick one committed palette — dawn-gold, or overcast-teal, or high-noon alpine — and drive every material through it. Speed and impact — the anime layer A racing game lives or dies on whether speed feels like speed. Build these as real systems: Radial speed lines that ramp in with velocity, drawn as a screen-space post effect, anime-style — subtle at pace, aggressive on boost. Motion smear on the rider and wheels at high speed, and on limbs during trick rotations. Cel-shaded dust and dirt — hard-edged puff shapes kicked up by tires, not soft particle sprites. Puffs on skids, sprays on landings, a trailing plume through scree. Impact frames. On a hard landing or crash, hold for one or two frames with a high-contrast flash — the anime impact convention. Used sparingly it will make hits feel enormous. Camera language: spring-damped chase cam that whips through corners, FOV kick with speed, screenshake scaled to landing force, an automatic swing-around during big air, and a brief slow-mo on the biggest jumps. Terrain — its own AAA-sized problem Give the mountain a dedicated sub-agent and more iterations than anything else. It's most of every frame. Procedural mountain built from layered noise, then run a hydraulic erosion simulation over the heightmap so ridgelines, gullies, and alluvial fans form naturally. Raw noise reads as lumpy and fake; eroded terrain reads as a real mountain. Do the erosion. Altitude and slope banding into material zones — grass and wildflowers low, dirt and exposed rock mid, scree and snow at the peak — with hard cel transitions between zones, not blends. Instanced foliage: toon-shaded trees with billboard-cross canopies, rocks, bushes, grass tufts. Dense enough to feel alive, LOD'd and culled hard enough to hold 60fps. No popping — fade or scale transitions only. Terrain clipmap LOD so the view down the valley runs for kilometers with no seam and no visible tiling. The track A point-to-point downhill run from the summit to the valley floor — not a lap circuit. Design an actual great course, with pacing: A tight technical start on exposed rock, then a fast open scree section to build speed. Bermed switchbacks through the tree line, tight enough to reward braking discipline. A rock garden that punishes bad line choice. Two big jumps — one tabletop, one gap over a ravine — with clear takeoff read. A narrow ridge sprint with real exposure on both sides. A drop into a stream bed, then a final sprint to the finish gate. Built on a CatmullRomCurve3 spline conformed to terrain, rendered as a dirt ribbon with hard-edged cel banding at the trail edges and worn tire-line detail. Checkpoints, split times, wrong-way detection, and a corner-preview indicator. A saved ghost of my best run to race against. Bike physics — arcade, but with real weight Raycast-vehicle style, two wheels, real suspension travel with visible fork and shock compression. Lean and counter-steer, grip curves that differ per surface (rock, dirt, grass, scree), brake slides that scrub speed and throw dirt. Rider input that matters: Preload and pump — crouch to compress, release at the lip for extra air. Timing should be learnable and feel great. Bunny hop and manual. Air control with real rotation authority, and landing angle matching: nail the slope angle and keep your speed, land flat and wash out, land badly and crash. Crash and recovery — a proper physical tumble, not a respawn fade. Tricks with a scoring system feeding a boost meter: tabletop, x-up, superman, tailwhip, 360, backflip, frontflip. Trick input during air, landing cleanly to bank the score. The rider — this is where the AAA claim gets tested The rider animation is the single highest-visibility piece of craft in this game, and it's what everyone gets wrong. Build a procedurally animated rig with proper IK: Hands stay locked to the bars through every movement. Feet stay on the pedals. No sliding, no detaching, ever. Spine bends into lean, head turns to look into corners and toward landings. Arms and legs absorb landings with real compression timing, sequenced — wheels, then fork, then legs, then spine, then head. Pedaling cadence tied to speed; standing versus seated posture depending on terrain and effort. Distinct, readable trick poses — the silhouette alone should identify the trick. Crash animations with limbs reacting to the impact direction. If a critic sub-agent looks at a frame and sees a rigid mannequin bolted to a bike, that subsystem is not done, regardless of how far along the rest of the game is. The race Me plus 3 AI riders. Spline-following with lookahead steering and terrain awareness, jump timing they can actually get wrong, per-rider personality (one aggressive and crash-prone, one clean and fast, one erratic), collision and avoidance between riders, and mild rubber-banding so the race stays close to the finish. They should make mistakes — beating them has to feel earned. Countdown start, live position and gap display, results screen with times, placement, trick score, and an automatic replay of my biggest air of the run from a cinematic camera. HUD in the same cel style — speed, position, checkpoint splits, boost meter, trick score popups, a route profile showing my progress down the mountain. Hand-designed, not default HTML. Audio, all synthesized: chain and freewheel clicks, tire tone shifting by surface, wind rising with speed, suspension compression, impacts, a start horn. How I want you to work Fan out sub-agents. One owns terrain generation and erosion. One owns the NPR pipeline and line work. One owns bike physics and feel. One owns rider rig and animation. One owns AI and race logic. One owns camera, speed FX, and impact language. One owns HUD and audio. One owns performance. Define the shared architecture first, then run them in parallel. Build the capture harness before anything else. Playwright, headless, able to load the game, drive it to a specific moment, and capture retina frames from multiple angles — and capture frame sequences and short video clips. Stills are not enough for this project: animation and speed feel can only be judged in motion, so the harness must produce motion for the critics to review. Run two separate critic sub-agents. A stills critic judging composition, line work, banding, palette, and silhouette. A motion critic judging animation quality, weight, camera feel, and whether speed reads as speed. Both must be harsh and specific — naming defects like "outline breaks on the rider's shoulder at three-quarter view," "landing compression resolves too fast to read as weight," "distant ridges blend instead of banding." They report defects. They do not approve work to be agreeable. /loop every subsystem against its critic until the critic runs out of specific defects to name. Working is the floor, not the goal. Milestones, each one playable: (1) eroded terrain + camera, (2) bike physics and feel on raw terrain, (3) full NPR pipeline applied to everything, (4) track, checkpoints, race flow, (5) rider rig and animation, (6) tricks, speed FX, and impact language, (7) AI riders, (8) HUD, audio, replay, (9) performance and final polish pass. Give me something runnable at every one. Report your quality bar honestly. If the rider rig is at 60% or the erosion pass is producing mush, tell me and tell me why. I would much rather hear it from you than find it myself. Deliverable A repo with a README, clean architecture, readable and commented shader code, and a working npm install && npm run dev. When I run it, I want the first ten seconds of the descent to look like a frame from a film, and I want to hit restart the moment I cross the finish line. Ultracode.
Runs
| Model | Harness | Status | Cost | Duration | Output | Trust | Artifact |
|---|---|---|---|---|---|---|---|
| Opus 5claude-opus-5 | claude-code | Completed | $863.4 | 23h 28m | 5400k | Reported | open |
What this is, and what it proves
One prompt, published in full by its author — his second run of the same gauntlet-style brief that built Ink Tide: a cel-shaded downhill BMX racing game in Three.js, four riders point-to-point from summit to valley floor, zero external assets, the mountain generated from layered noise plus a hydraulic erosion simulation. The working method is spelled out again — fan out sub-agents per subsystem, build a Playwright capture harness first, and loop every subsystem against two critic agents, one for stills and one for motion, until they run out of defects to name. Claude Code with Opus 5 built Descent: procedurally rigged rider with IK, tricks and a boost meter, three AI opponents, synthesized audio, playable in the browser. The author posted the run's own cost readout: $863.35, 5.4 million output tokens, 1.2 billion tokens read from cache, 23 and a half hours of API time.
The prompt behind "Descent — Opus 5 shipped a cel-shaded downhill BMX racer from one prompt" is published in full, and was run by 1 model: Opus 5. 1 of 1 finished, on figures reported by the author.
- Models
- 1
- Completed
- 1 of 1
- Cheapest completed run
- Opus 5 — $863.4
Figures reported by Vyom. Not independently verified.
Reported, not measured
Posted by the author on 1 August 2026; the clip here is the first eight seconds of his own capture. The prompt is published verbatim in a reply on that thread and is reproduced here in full; in another reply the author says he copied @mattshumer_'s 'gauntlet' prompt and had Claude adapt it to the game he wanted, with no skills and no MCP servers involved. The build is a single run, not a comparison: nothing on this page was measured here. The figures come from the cost readout the author posted as a screenshot — $863.35 total, 138.5k input / 5.4m output / 1.2b cache read / 18.1m cache write tokens, 41,985 lines added and 4,834 removed. The duration shown is the readout's API time (23h 28m 22s); its wall-clock line reads 1d 5h 37m. The model is read off the same readout ('claude-opus-5') and the repository's commit trailers ('Co-Authored-By: Claude Opus 5 (1M context)'); the harness off the prompt's closing 'Ultracode.' keyword, which is Claude Code's multi-agent mode. The commits all land on 1 August 2026. The game is playable at bmx-racer.vercel.app; the repo carries no license.