Twenty cars, sixteen corners, working DRS zones and a pit lane — under a live broadcast overlay. No engine, no build step, and not one binary asset. Click and you're on the grid.
Type
Racing simulationEngine
Three.js / WebGL — no game engineAssets
None shipped. All generatedStatus
Live and playableNot a car on a ribbon of road —
a field, a circuit, and a car that has to be driven.
Racing games are the hardest thing to fake. A shooter can be carried by art direction; a racing car is judged by how it behaves in your hands within about four corners. Apex Grand Prix set out to see whether a browser tab could hold the whole thing — a twenty-car field, a five-kilometre permanent road course with sixteen named corners, three DRS zones, a pit lane that works, tyres that heat and wear — and still be something you can send someone as a link.
The constraint was the appeal. Everything an engine normally supplies — the render pipeline, the vehicle model, the tyre curves, the camera director, the timing tower — is written directly against WebGL through Three.js, in vanilla ES modules on an import map. No bundler, no build step, nothing to compile. The whole build is readable, and every system in it is one file you can open.
The rule that shaped everything: not one binary asset. No image files, no audio files, no models. Every texture on the circuit — asphalt, kerbs, grass, crowd, livery, tyre wall — is drawn procedurally with Canvas2D and noise the moment the page loads, and every sound is synthesised in WebAudio. That is what keeps a full race weekend down to a few megabytes that start in seconds, and it is also why the whole look can be re-tuned by changing a number rather than re-exporting a texture.
The handling was developed the way a real car is: by driving it and complaining. Rounds of play-testing produced specific, physical complaints — the car spins under a keyboard, the sharp turn will not close — and each one was chased to a measured cause rather than a guess. The game is live, free, and linked from this page. The production brief behind it is in the prompt shop, and the build is in the template gallery.
Every system hand-rolled —
because there is no engine underneath.
The circuit
A permanent road course with named corners, elevation, kerbs, run-off, barriers and three DRS zones, generated from a centreline rather than modelled by hand. Grandstands, crowd, marshal posts and trackside furniture are placed procedurally along it.
The car
Fixed 240 Hz physics behind an accumulator, so the handling is identical whatever your frame rate. Per-wheel load transfer, a real tyre curve with heat and wear, aerodynamic downforce, engine and gearbox, ABS, traction and stability control you can switch off one at a time.
The field
The AI drives the same physics you do — no rails, no rubber-banding cheat. Each driver has a skill profile that shapes braking points, apex speed and willingness to defend, and the whole field is capable of clearing every corner of the circuit cleanly.
Zero assets
No image files, no audio files, no models. Textures are drawn at boot with Canvas2D and noise; the engine, tyres and wind are synthesised in WebAudio. The build ships as code, which is why it is a few megabytes instead of a few hundred.
Broadcast layer
Position, lap, sector timing, delta to your best, tyre temperatures, battery, DRS state and a minimap — all read from the model rather than approximated, and asserted against it by a QA suite that drives a full five-lap race and compares every field.
The gate
Nothing ships until a headless browser drives the whole game — physics, menus, flags, pit stops, contact, the driving line — and a visual gate compares eleven measured image metrics against a baseline. The screenshots on these pages come out of that same harness.
No store, no launcher, no download. A link in a chat message is the whole distribution — which is what makes a playable build usable as marketing rather than a project.
Readable modules instead of an engine's black box — and no build step between the source and what runs. For a studio selling engineering, the game is the portfolio piece and the code review at once.
Every handling complaint was chased to a measured cause, and several confident fixes were thrown out when the evidence refused them. What shipped is what survived a control arm.
Static files, no build. Updates deploy in seconds, there is nothing to patch, and the same pipeline that ships this studio's websites ships the game.
Captured by the QA harness —
the same frames, every run.
QUESTIONS WORTH ASKING
Yes — it is live right here on this site, free, in any modern desktop browser. WASD or the arrow keys drive it; a keyboard is all you need.
Because a playable moment out-engages any banner ever made, and a browser game removes the only real barrier — installation. A branded circuit that opens from a link works in a campaign, at an event booth, or as the reason people share your URL. This build is the proof it can also be a real simulation rather than a toy.
Engines win on tooling and raw fidelity; the browser wins on distribution and weight. An engine export to the web ships tens of megabytes of runtime before your first texture — and this build ships no textures at all, because it draws them. The result starts in seconds, and every system in it is code you can read.
A gate that has to pass before anything ships: thirty-five suites drive the real game in a headless browser — braking, traction, stability, contact, pit stops, flags, the timing tower — and a visual gate compares eleven measured image metrics against a baseline. One of those suites replays a real player's own recorded keystrokes at the hairpin, so a fix has to survive the thing that caused the complaint.
Yes — the exact production prompt behind the build, with the art direction, structure and engineering notes, is a one-time unlock in the prompt shop. The template page has the full breakdown of what's inside.
Games, interactive pieces, product demos — if it can run from a link, it can run in your campaign. Tell me what you're imagining.
