You can play Sky Shift in your browser right now: Sky Shift on Playgama.

https://www.youtube.com/watch?v=KGID1fQxtxM

What does the stack look like?

Rendering is three.js over WebGL. three.js is a library rather than an engine with an editor: it draws the scene, and game state, input, UI and level logic are all code you (or your agent) write around it. Physics is Jolt compiled to JavaScript. We picked it because we wanted genuine collisions and a proper vehicle model, and Jolt ships suspension, tyre friction, differentials and a gearbox. Both libraries are bundled into the build instead of being requested from a CDN when the page loads, which the Playgama game checklist asks for in any case.

How do you get a drivable car model into three.js?

A drivable car needs its wheels as separate nodes, each pivoting on its axle, so code can rotate and steer them. Our models came out of Tripo's image-to-3D: a ChatGPT concept image goes in, a textured mesh comes out. For the web, three settings mattered: triangle topology at about 5,000 tris, GLB as the export format, and textures between 1K and 2K instead of the 4K the dialog was set to.

Segmentation is what produces separate wheels, and it has a price.

The segmented red car landed as 55 meshes, each carrying its own texture, and 42 of those textures were 128 px or smaller. In three.js, every mesh with its own material becomes its own draw call, so this one car cost 55 of them. The relevant checklist line reads "Budget draw calls, not polygons."

Attempt one baked all the little textures into a single map. Draw calls dropped and the car went blurry: a bake can only rearrange the pixels you feed it.

What shipped combines two exports of one model. The unsplit export contains identical triangles and a single 2048 × 2048 texture. A headless Blender script then:

1. reads the segmented GLB purely to label each triangle as wheel or body, gathering every wheel's loose fragments;
2. cuts the body and four wheels from the unsplit GLB, so all five meshes share that one sharp texture;
3. relocates each wheel's origin to its axle, so rotation happens in place;
4. scales the vehicle to real-world dimensions.

blender -b --python clean_car.py -- red-car-split.glb red.glb renders/ 4.4 --full red-car-full.glb

Outcome: 5 meshes and 1 texture where there had been 55 and 55. The yellow car had no unsplit export, since we segmented it first, so the script packed its 53 textures into one 4096 × 4096 atlas. That gave the same draw-call saving with a softer surface. Save the unsplit GLB before you segment.

Keeping the pipeline as a single command pays off when an agent is involved: every new car follows identical steps, and the agent can rerun them on request. The checklist phrase is "Script the asset pipeline into one command instead of optimizing by hand."

Static props (barriers, billboards, flags, ramps) and sound effects came from Kenney's CC0 Racing Kit and sound packs and needed nothing beyond loading.

Wiring the wheels in code

Because each wheel arrives as its own node with a correct pivot, the runtime side stays small. The code spins all four with the car's motion, turns the front pair with steering input, and lets each wheel ride its own suspension. None of that would be possible with the wheels fused into the body mesh, which is why the asset step above spends so much effort keeping them separate. It also explains the turned-wheels problem we hit early: the first concept image showed the front wheels angled, and an image-to-3D generator would have frozen that angle into the mesh. One more ChatGPT prompt asking for straight wheels fixed it before Tripo ever saw the picture.

Why is the track stored as data instead of geometry?

Nobody modelled the track in an editor. It lives in config as a list, one entry per section, and every entry has a length, a turn, a climb, a width and a type: walled canyon, jump, tube, or banked wall-ride. At load, the game generates geometry from that list.

Two things follow. Shuffle the entries and you have a new track. And the agent edits levels by editing lines, so "lengthen the canyon and add a jump before the tube" is a small diff rather than a modelling session. Harbour Run, Skybridge and Razor Coast, the three levels, are three such lists.

To steer the layout, we gave the agent fourteen reference screenshots of stunt maps. It asked four design questions before touching code, and our answers became a point-to-point sprint with a giant platform, a canyon, a tube and steep climbs, each zone with its own colour.

How does an AI agent test a 3D game it cannot see?

This is the part we would copy into any three.js project an agent maintains. The game exposes its runtime state on a global, window.__game. That lets the agent boot the build in a headless browser, drive it, read positions and frame rate, and grab screenshots, rather than infer behaviour from source files.

Source code tells the agent what ought to happen; the hooks report what did. The agent drew its own conclusion and recorded it in the project notes:

Numbers from window.__game settle it; screenshots agree with almost anything.

The hooks also give deterministic capture. Our recorder steps the simulation exactly once per frame, so the footage stays smooth no matter how slowly the machine renders:

node tools/capture-steps.mjs --url "localhost:5190/?record=1&autopilot=1" --w 2560 --h 1440 --seconds 100

How do you handle every screen size?

A browser game has to work from an upright phone to a wide desktop monitor. The agent runs the UI through a fixed matrix of viewport sizes and checks numerically whether elements collide. On one run it found three overlaps, patched them, then repeated the check across all fourteen sizes.

A later platform check caught a separate issue: the picture stretched on ultra-wide displays. The fix clamps the desktop aspect ratio to 2:1 and fills the rest with margins.

The rollover bug and the Jolt setting behind it

Once real cars were in, fast cornering fell apart. At full steering lock a car tipped onto two wheels, and some rolled over entirely. Here is the request we sent:

Some cars still flip over. Think, search the internet for how car control is done on the engine we use, and make it as good as you can.

The agent traced it to Jolt's vehicle documentation. By default, Jolt applies tyre forces at the contact point between tyre and road, which the docs note "makes the vehicle less stable." Switching to a fixed application point on the chassis changed the result at full lock and 245 km/h from a 75° roll to 4.5° of lean, all four wheels planted.

Two lessons for physics work alongside an agent. Measured values make it obvious whether a change helped. And sending the agent to the engine's own documentation got further than letting it tweak constants by trial.

Shipping the build

The final layer was the Playgama Bridge SDK, covering ads, saves, leaderboards and languages. Through Playgama MCP the agent loaded the SDK docs and the checklist, moved Bridge from 2.0.2 to 2.2.0, added eight languages, merged saves into one call, and replayed a recorded race to confirm gameplay was untouched. The QA tool then measured a 6 MB initial download and a load of about a second, with both engines bundled and each car down to five meshes.

A few implementation details from that layer that are useful in any browser game:

• Ad timing as rules, not scattered calls. An interstitial may fire only when the player leaves a results screen, never during a race's first 30 seconds, and with at least three minutes between two of them. The rewarded video, which doubles the coins from a win, grants the reward only after the video finishes.
• One save call. The first version wrote each setting separately; the agent collapsed them into a single write, and the QA tool confirmed saves load in one call.
• Language from the platform. The game picks among its eight languages based on the language the platform reports.
• Custom analytics events. Bridge 2.3.0 and later can send your own events. The rule in the docs: keep event names short and stable, and put values that change, such as the level or the section, into the event data. For Sky Shift that means one event per section reached and one when a player falls off, which the agent can read back through Playgama MCP to see where players stop.

The long-form version, including every prompt and the asset licences, is on our blog.

Sky Shift is live, on a computer or a phone: play it in your browser.