Status: playable personal build. Monster Trux World is a browser driving game on a curved miniature planet that physically grows as you collect coins. It runs on Three.js and TypeScript and is served from Cloudflare Workers, and it is written up here as an engineering project rather than a game pitch: the interesting parts are the terrain solver, the render budget, the asset pipeline, and the verify gate that decides whether a build is allowed to leave the machine.
It sits at a public URL for one practical reason — mobile WebGL performance work cannot be done in a desktop emulator, so I deploy the build and open it on real phones. It is not a product. It is not promoted anywhere, it has no accounts, no payments, no analytics, no marketing and no player base, and nothing on this page should be read as a launch.
Why it exists
My son wanted a video game. We are strict about how much tablet time he gets and stricter about what he is allowed to play, so the usual path is to go looking for something to approve. Building one instead answers both questions at once: I decide exactly what is in it, and the screen time becomes something we do together rather than something he does alone.
He is not the audience for it; he is where it comes from. The trucks, the stunts, what should be on the planet, what should happen when you land a jump — those are his. My part was working out which of his ideas could be derived from a height field on a sphere and which could not, and telling him plainly which was which.
The timing was the other reason. AI coding tools had just become good enough at game code to be worth a real test, and I wanted a first-hand read on them rather than an opinion assembled from demos. A portfolio that argues about practical AI implementation should be able to say where the line actually falls, and the only way to find that line is to push a build far enough that it starts pushing back.
The read was specific. The generative part is fast and genuinely good: a curved world, a truck, a camera, controls, and a loop you can drive around, in a fraction of the time it would take to write by hand. Then the curve flattens, and everything on this page that took real work sits past that point.
The hydrology solver exists because the first rivers were a hand-authored array with no relationship to the height field, so water climbed ridges — you do not get that from a better prompt, you get it from studying the terrain and deciding it is wrong. The frame-pacing controller exists because "it runs fine" is not a measurement and a mid-range phone is not my laptop. The 36-script verify gate and the versioned save migrations exist because a prototype that works once and a build you can still change next month are different objects. Judgement about what counts as broken, measurement of what is actually happening, and the patience to iterate against both are not things a prompt produces. That is the transferable part: the generative step is now the cheap step, and the value has moved to knowing what to check.
Why a toy planet
The brief was deliberately unlike the rest of this portfolio: real-time 3D, physically motivated simulation, and performance work for mobile WebGL — a domain where "it looks right in one screenshot" is not evidence. A tiny spherical world makes every system visible at once (terrain, water, biomes, stunt lanes, arenas) and forces the hard constraint that nothing can be hand-placed on a globe that keeps changing radius. The planet begins at a radius of 30 units, matures to 64, and opens into a deep-world radius of 128 as the world stage climbs, so every feature has to be derived from a field, not authored on a map.
Terrain and hydrology
The ground is a pure, deterministic height field evaluated on an icosphere. There is no Math.random in the simulation or terrain modules: the height field is a closed-form sum of layered ridge, mountain-range, cliff-band, and gorge terms over the surface normal, an FNV-style string hash seeds the terrain-surveyed features (stunt lines, boost lanes, dirt lips) that sit on it, and biome fields blend across latitude bands and eight longitude sectors into seven regions — grassland, forest, wetlands, desert, badlands, alpine, and tundra — each with its own silhouettes, surface feedback, and named subzones. Because the field is a function of a surface normal plus a world-stage context, the same seed produces the same planet at every radius, which is what lets rebuilds, saves, and regression fixtures agree with each other.
Water was the part worth solving properly. An earlier version stored rivers as a hand-authored array of latitude/longitude polylines with no relationship to the height field, so rivers could climb ridges and lakes could sit on mountaintops, and no threshold tuning could fix that structurally. The replacement is a small drainage-network solver that runs once at module load:
- Build a fine lattice independent of the render mesh: a recursive quad-split icosphere at level 5 — 20,480 faces and 10,242 unique vertices — and sample the exact displacement function the renderer uses.
- Find genuine local minima and grow bounded drainage basins outward from them. Basins are capped primarily by cell count (about 40 of the 10,242 lattice cells) rather than depth alone, because a gently sloping valley can accumulate many cells while barely rising, and a depth-only cap let neighbouring lakes balloon into one merged ocean. Tiny basins below five cells are discarded as numerical noise, and a farthest-point spacing filter keeps lake seeds spread across the globe instead of clustered in the noisiest mountain range.
- Trace steepest-descent flow-accumulation paths into those basins and emit them as rivers, creeks, and springs, capped at sixteen systems so each one still earns its own render pass (ribbon, confluence fans, and a terminal lake fan) without blowing the water-coverage ceilings that were calibrated for the original five routes.
- Emit the result in the same route shape the scene and simulation code already consumed, so nothing downstream had to change — the water sampling helpers had only ever assumed polylines, never that they were hand-drawn.
The solver is honest about its approximation: topology is solved once against a mature reference context, and the commentary in the source records that height ordering is not perfectly invariant across world stages (measured pairwise flips of a few percent, with height correlating around 0.95–0.97), which is why the width and radius scaling downstream still reads the live context. Terrain contracts in the verify gate check the biome, water, and stunt-line fields across world stages from the starter world to the deep-world finale.
Rendering and performance
The renderer runs under an adaptive frame-pacing controller. It samples frame durations in a rolling four-second window, computes p50, p95, and a slow-frame ratio, and moves through explicit states — warming, monitoring, cooldown, suspended, and floor. Three consecutive unhealthy windows (median above roughly 21.5 ms or more than 18% of frames above 34 ms) step the renderer down one pixel-ratio profile — native, balanced, performance — with a cooldown before the next evaluation and a floor at a 0.8 pixel-ratio cap. The controller has its own unit-style check script, and the decision is exposed on the canvas dataset so a fixture can assert what happened rather than eyeball it. Capturing the deployed origin through a software renderer at DPR 1, the controller downshifted to the performance floor within seconds and reported the reason as sustained frame pacing, which is exactly the behaviour it is there to provide on weak devices.
Trucks come from a Blender pipeline: a headless Python script builds 25 parametric truck bodies, then a glTF-Transform pass applies meshopt compression with 16-bit position and normal precision, under a compressed-byte budget that also checks hierarchy, material metadata, and triangle counts are preserved. The 25 models total about 18 MB and are served as immutable, content-versioned URLs; hashed Vite assets and /models/* carry a one-year immutable cache policy while HTML stays no-cache, and the Workers asset config uses a real 404 page so a missing model can never be masked as an HTML response.
Verification
npm run verify is the release gate, and the production deploy script runs it before anything is published. It chains 34 steps that invoke 36 check scripts: TypeScript, coin readability and scale contracts, camera-frame invariants, the frame-pacing controller, driven Big Air, arena-circuit, and seven-land rally fixtures, controller mapping, GLB validation through the production meshopt loader, terrain, hydrology, and biome contracts, save-progression and reward-cadence checks, an authoritative story-gate check, a continuous first-ten-minute journey, and a versioned save-migration test that replays legacy payloads. The browser fixture script drives headless Chrome over the DevTools protocol against a fresh Vite server, runs 43 fixtures across desktop, mobile, and mobile-landscape viewports — 94 screenshots per full run — and asserts on canvas diagnostics (world composition budgets, water overlay counts, biome and surface feedback, focus state) instead of pixel diffs.
Two habits from the playtest log shaped the harness. First, "classification cannot be the gate": anything that draws independent visible marks on the globe — weather, ambience, route help, terrain detail — must pass through the same composition budget as props, because a layer name is not a visual argument. Second, allowed layers still need explicit diagnostics with a count, budget, and label so QA can tell deliberate scenery from accidental clutter. After a deploy, a production smoke script opens the deployed HTTPS origin in an isolated Chrome profile and asserts boot state, the truck asset source, model response headers, and the absence of runtime errors.
Accessibility and input
The accessibility contract is part of the fixture set, not a checklist: native buttons with visible focus and 44-pixel minimum targets; modals that trap focus and mark background controls inert; reduced-motion preferences that freeze or soften water, portal, sky, camera, and feedback motion while keeping gameplay information; forced-colour styles that retain focus, selection, and control boundaries; and pinch zoom left available outside the driving controls. Input parity covers keyboard, standard gamepads with light haptic feedback, and touch controls that appear automatically on coarse-pointer screens, with a dedicated gamepad-mapping check in the gate. Autosave uses a versioned schema — the working tree is on version 18 — with legacy-payload migration and rejection of corrupt or hostile backups before anything is restored.
How it was built
The authorship, stated plainly: this was a directed AI-agent build. Every commit in the repository is authored by a coding agent; my role was director, designer, and QA: owning the brief and the readiness backlog that scoped each pass, deciding what the world should feel like, playtesting builds and deciding what counted as a failure, and insisting that each pass land with a verifiable contract rather than a description. The verify gate exists because that is the only honest way to direct an agent at this scale — the test suite, the browser fixtures, and the playtest log are the specification, and a change that could not be asserted did not ship. If you want to know what I personally wrote versus reviewed, the answer is the direction, the acceptance criteria, and the judgement calls; the agent wrote the code against them.
Status and boundaries
This is a personal build, not a product. The deployed origin exists as a device lab: it is the only honest way to measure frame pacing, touch controls, and asset delivery on the phones people actually own, so the build gets pushed to Cloudflare Workers static assets and opened on hardware. There is no store page, no promotion, no accounts, no payments, no analytics, no player base and no revenue, and there is no plan to add any of that — the URL exists because the testing needs it.
The working tree continues past the deployed build: some feature names in the current README (Region Rallies, Stadium Shows, Crew Missions, Scenic Drive) describe loops that exist on the deployed origin under earlier names or are still in the working tree, so this page describes only what can be confirmed on the deployed build — the procedural globe with hydrology, seven biomes, stunt lines, three stadium events, timed rallies, the Chrome Rush and Glint Line challenges, the garage, gamepad, touch, and keyboard input, frame pacing, and the meshopt truck pipeline — and marks the rest as in progress. Three of the gallery captures come from the working-tree fixture run; the fourth is the deployed origin. The source repository is private for now.
Related
See graysond.xyz platform for how this site's own generator and verify ladder work, Interactive labs for smaller browser-native builds, Technical operations for the reliability side of the portfolio, and the Ventures hub for the rest of the roster.