Ignition — Danny Paton

01 / CONTEXT

The problem behind the interface.

Ignition explores how a sports fan experience can become something people actively play. It combines the immediate feel of an arcade racer with a connected product: choose a driver, build a career, meet other racers and return for another circuit.

02 / MY CONTRIBUTION

What I worked on.

Built a Three.js racing experience with 14 authored circuits, a 40-driver garage, solo opponents, drafting, boost, drifting, cameras and keyboard and touch controls.
Developed a walkable multiplayer paddock, scheduled departures, private race codes, ready checks and authoritative four-player races.
Implemented persistent driver progression, race history, rankings, earned credits and owned equipment, with signed server results and duplicate-award protection.
Moved live presence and simulation from frequent database calls into a dedicated Node WebSocket service, while keeping durable account and race records in Convex.

03 / ENGINEERING DECISIONS

The details that matter.

Driving needs immediate feedback. Race results need an authoritative source. I separated the fast simulation from durable account records so each could do its own job.

From a steering input to a saved result.SIMPLIFIED IMPLEMENTATION FLOW

Browser
Keyboard or touch input, local prediction and Three.js rendering.
Race service
Node and WebSockets own the live race and send snapshots for reconciliation.
Account records
Signed results pass through a durable retry queue into Convex progression.

The tradeoff: Prediction makes controls responsive, but the browser must reconcile with the server. The current service owns rooms in one process; scaling live rooms across processes remains further work.
What it enables: A connected arcade game with solo racing, four-player grids and persistent progression. Result settlement is idempotent: retrying a completed result does not award the same credits twice.

The car has to feel like a car.

Steering changes the car’s heading in world space; releasing the controls does not auto-follow the track. Track projection measures progress, while braking, contact, drafting and recovery shape the driving experience. A shared model keeps local and authoritative race rules aligned.

Keep the fast loop out of the database.

Live movement and simulation run in a dedicated WebSocket process. The browser predicts between snapshots and reconciles to the server. Convex handles accounts, equipment and completed results, so every physics tick does not become a database operation.

A finish should be recorded once.

The server registers the starting roster, validates driving inputs and signs results. Completed results go through a durable retry queue; the account backend applies each result once. An interrupted race does not invent a finish or award credits.

Make the whole experience playable.

The work includes a responsive garage, searchable circuit selection, touch steering and a compact mobile race HUD. Progression, car customization and return-to-paddock flows make it a product beyond the rendering demo.

04 / EVIDENCE & SCOPE

A clear account of the work.

Reviewed Danny-authored implementation history, game and realtime-service source, and documented local and browser validation. The public game page and circuit inventory were checked for this portfolio.

An arcade engineering experiment inspired by NASCAR, not a claim of an official commissioned game or surveyed simulator accuracy. The current multiplayer service has one room-owning process; horizontal scaling and uninterrupted recovery across process failures would require further work.

Reviewed September 2026. Screens captured from the running application. Proprietary code and internal source records are not published.