Play it now at nt-race.vercel.app.
NEON CIRCUIT is a 90s-style arcade racing game set in the Neo Tokyo universe with ten city districts, dodging traffic, outrunning cops, and a synthwave radio playing the whole time. It’s inspired by the arcade classic Cruis’n USA, it was built completely from scratch, and it runs right in your browser.
The whole game came together in a few working sessions spread across two weeks, built with an AI coding assistant (Claude Code). This post is about how that actually went, what worked, what didn’t, and what I’d tell anyone trying to build something real with AI.
It started with a failure
This wasn’t my first attempt. My original version used a popular web framework and a more “modern” approach to 3D, and it just never felt right. I was fighting my tools more than building the game. So I deleted everything and started over with a comprehensive plan before writing any code.
Write the plan before the code
Before a single line of code existed, I had three documents. They turned out to be the biggest reason this worked.
A “how the original worked” doc. The company behind Cruis’n USA released the original arcade game’s source code publicly years ago. I studied it, not to copy anything, but to understand why the game felt the way it did and wrote those findings down in my own words. Then I had Claude investigate the repo and extract all the physics, environment, and gameplay rules. Traffic secretly spawns more often when you’re winning and less when you’re losing to keep every race close. The camera follows the direction your car is sliding, not the direction it’s pointing, which is why drifting around corners looks so dramatic. Track construction, traffic and racer car stats, environmental objects. Everything was rebuilt fresh from that writeup, no code, art, or names were taken from the original.
A spec written for the AI. My requirements doc literally opens by addressing the AI directly: “This is your primary spec.” It lays out exactly what tools to use, how to organize the project, and most importantly breaks the work into numbered milestones, each with a checklist of what “done” means. Some checklist items are automatic tests the AI has to pass. For example, one test actually measures that traffic shows up twice as often when you’re in first place as when you’re in last, because that rubber-band effect is core to the feel.
A decisions journal. The spec told the AI: when something’s unclear, make a sensible call and write down what you chose and why. That journal grew to over 500 lines of “here’s what we decided and here’s the reasoning.” When you’re producing thousands of lines of code a day, you can’t manually check it all so you need a virtual memory.
The payoff: by the end of day one, I had a complete playable game with driving physics, ten computer-controlled rivals, traffic, engine sounds, menus, saved progress, and even touch controls for phones.
The technical choices, in plain terms
Fake 3D, on purpose. Real racing games track cars anywhere in a 3D world. Mine tracks just three things per car: how far along the road it is, how far left or right, and how high off the ground. That’s the trick 90s arcade racers used, and it makes everything simpler. The car doesn’t move along the track, the track moves past the car. Figuring out who’s in what place is just comparing one number. The spec explicitly forbids upgrading to real 3D movement. The limitation is what creates the feel.
Almost nothing borrowed. The game uses exactly one outside library (for drawing graphics). The physics, the menus, the AI drivers are all custom, and surprisingly small. I didn’t want to use any modern libraries because it might affect the 90s feel. This is why analyzing and extracting the rules from the old code up front was so important.
No sound files at all. Every sound is generated live, in code. The engine note is a tone that rises with the RPM and sputters when you redline. Gravel, grass, and sand each get their own texture of noise. Even the music is composed on the fly with each district having its own synthwave loop, played note by note by the game itself. Later I added the optional Neo Tokyo FM youtube station.
The art (and its war stories)
I was very specific about the art direction in that I wanted it to remain somewhat true to the original Cruis’n USA look and feel. The original game art came from photographing physical car models from many angles and turning the photos into game sprites. I wanted that same look, but neon-soaked Neo Tokyo.
Two AI image services did the heavy lifting. One (PixelLab) is great at drawing the same car from many angles consistently which is what I thought would look great as the objects passed the car on screen. The other (fal.ai) generated the scenery as somewhat more realistic images of buildings and signs, backgrounds automatically removed, then shrunk down to game size. This was the same technique as the original game, just with an AI instead of a camera. Total spend: about ten dollars in credits to use the more advanced offerings of those APIs.
AI art needs cleanup, though. At first every car in the game hovered slightly above the road for a day, because the AI-generated images each had a slightly different amount of empty space at the bottom. The fix was to tell Claude to generate a small script that lines them all up automatically.
The biggest change of direction came late. The sprite cars never looked quite right when you passed them because the angles were always a little off, and days of regenerating the art didn’t fix it. So I flipped the approach and had the AI generate a picture of each car, then feed that picture to another AI that turns pictures into actual 3D models. It worked almost immediately, and within a day every vehicle in the game was real 3D. The tracks and racing feel remained the 2D/3D hybrid as described before.
Shipping it
Launching was actually the easy part. I pushed the code to github and had Vercel, the hosting service, build and publish it automatically. Since I was specific about the infrastructure being built on a very common tech stack, it was able to build and deploy without issue.
What I’d tell you
- Provide Context Have AI research existing code, documentation, wikis, and other sources of information first.
- Plan first Writing the spec before the code is what made a few days of AI-built work coherent instead of chaos.
- Give the AI a checklist it can’t argue with Tests that pass or fail beat me checking everything manually.
- Write decisions down Future you won’t remember why anything is the way it is.
- AI art is half the job The cleanup pipeline around it is the other half.
- Know when to change course I spent much too long polishing sprites before admitting the answer was 3D models.
Seventy-one commits, sixty-eight automated tests, roughly ten thousand lines of code, ten dollars in AI credits, and a playable game launched in two weeks.
Take a lap for yourself at nt-race.vercel.app.