Mini RC Racers: Building a Browser Racing Simulation with Coding Agents

A Sunday-morning RC club race has more going on than cars chasing a finish line. There are heats and finals, changing conditions, collisions, and marshals stepping onto the track to put an overturned car back on its wheels. Mini RC Racers brings those details into a top-down, pixel-art browser game.

Built by Santiago and shared with the RaidGuild community, the project is also a practical account of agent-assisted software development: a playable game assembled feature by feature, with architectural rules that keep its growing systems apart.

A small game with several systems to coordinate

Mini RC Racers models 1/10-scale electric RC racing. AI drivers, race rules, weather, marshals, sound, and commentary all contribute to the experience. The challenge is making those systems work together without tying the outcome of a race to the browser’s rendering speed.

Santiago’s approach starts with a strict separation: the simulation decides what happens; the presentation shows and describes it. That distinction shapes both the player experience and the development workflow.

The race runs independently of the screen

Physics, AI drivers, rules, marshals, and weather live in plain TypeScript. The simulation advances in fixed steps of 1/120 of a second, using a seed and a stream of control inputs. It produces read-only world snapshots and typed events describing what happened.

Sprites, the interface, audio, and commentary consume those outputs. They cannot change the race. The simulation can therefore run outside the browser, making its behavior available to automated tests without drawing a single car.

Browser frames arrive at uneven intervals. A runner connects that variable rendering schedule to the fixed simulation ticks, carrying unused time forward between frames. The view interpolates between snapshots to keep movement smooth. A cap on catch-up steps prevents a stalled frame from triggering an escalating backlog of simulation work. The tradeoff is explicit: a long stall drops some race time instead of forcing the game to catch up indefinitely.

Use libraries where they solve the right problem

The vehicle handling model - grip, steering, motor, brakes, and weight transfer - is the game’s own. The planck physics library handles rigid bodies and collisions. It sits behind a narrow boundary: the car model supplies forces and torque, and receives ordinary position and velocity values. Library-specific types do not spread through the simulation.

Phaser handles presentation. Cars use 64 pre-drawn directions rather than runtime sprite rotation, preserving their pixel-art outlines. ZzFX supplies synthesized sound effects, while the motor sound is generated through WebAudio. Vite builds the site, Vitest exercises the simulation in Node, and Playwright drives browser checks through a development-only debug hook.

Give coding agents boundaries the tools can enforce

Santiago describes coding agents implementing the game feature by feature from a written specification. Keeping that process coherent across many sessions required more than asking each agent to respect the architecture.

TypeScript checks the simulation without browser DOM definitions. Linting rules block browser globals, wall-clock access, and unseeded randomness in the relevant layers. Other rules keep Phaser in the view and planck in the physics layer. Randomness comes from seeded, named streams, reducing the chance that a new random draw in one subsystem changes unrelated behavior.

The useful lesson is specific: architectural intentions become easier to preserve when a compiler or linter can reject violations. An agent can add a feature, but the build still checks whether it crossed a boundary it should not cross.

Reconstructing a real club track from one image

The home circuit is based on Cuenca RC, Santiago’s local club track. His starting material was a single, angled frame from a drone video. A Python pipeline corrected the perspective, checked proportions against repeating track markings, segmented the driving surface, and generated a route with lane-width information.

The process also records corrections for places where the photograph cannot reveal the lane edge. It is not presented as a perfect survey: Santiago documents failed detection approaches, later measurements, and a scale adjustment. The game deliberately exaggerates the cars relative to the circuit to make them readable on a small screen.

The limitation worth keeping in view

Fixed ticks and seeded inputs do not guarantee identical results across every browser. Santiago reports that the simulation agrees within the V8-based environments he compared, but small differences in trigonometric calculations cause Firefox and Safari races to diverge over time.

That matters if a server must reproduce a recorded lap from another browser. Supporting that kind of verification would require further work, including consistent mathematical functions. It is a useful boundary on the project’s determinism claim, rather than a reason to describe every replay as universally reproducible.

What this build demonstrates

Mini RC Racers combines a playable browser experience with a testable simulation, an image-to-track pipeline, and enforceable rules for agent-assisted development.

Play the game, then explore the walkthrough to see how its small racing world is put together.

Explore the project

Play Mini RC Racers

Watch Santiago’s builder demo