From a Tweet to a Racing Game: 8 Weeks of AI-Assisted Solo Dev
# From a Tweet to a Racing Game: 8 Weeks of AI-Assisted Solo Dev
How I built Shed Racer, a browser-based WebXR racing game with VR, AR, hand tracking, networked multiplayer and a custom track editor as a solo indie developer using Cursor, Claude Code and Antigravity over eight weeks of part-time work.
A tweet, a fork and a lock-in
In late March 2026, mrdoob, the creator of Three.js, posted a tweet that was, on its surface, about a small experiment. He'd taken Kenney's free CC0 racing starter kit and asked Claude to port it to Three.js (I'll leave out the more dramatic aspects of the story out of this post). The game shown in the tweet was already a solid prototype: cars driving on a track, arcade physics using crashcat, a track editor with auto-connecting, mobile touch controls, URL-based track sharing. But the tweet itself was really a "look what AI can do" moment (even with a little trolling intent).
Loading the embed shares your IP with X Corp. and may set third-party cookies.
The tweet was seen by many. A wave of developers forked it and piled features on, posting their riffs back at each other.
Loading the embed shares your IP with X Corp. and may set third-party cookies.
Loading the embed shares your IP with X Corp. and may set third-party cookies.
I also forked it on March 24 to add my own spin to it. The next morning I shipped WebXR support (both in VR and AR).
Loading the embed shares your IP with X Corp. and may set third-party cookies.
The pitch was simple: scale the entire track down to RC-car size and place it in passthrough AR on your coffee table. The Quest's plane detection picks up a real table and the track snaps onto it. That WebXR fork picked up its own round of attention and the moment I sat down in passthrough and watched a tiny Kenney-styled car loop around my actual living room, I realized this wasn't going to stay a weekend project.
This post is about what happened in the eight weeks after, what AI-assisted development actually enabled and where it fell short in a real WebXR game project.
What was in the box
What mrdoob's port already had was substantial:
- Core driving mechanics
- A track editor with the ability to share custom tracks via URL parameters
- Basic motor sounds based on vehicle speed
- Effects: smoke effect
- Mobile touch controls
It was a great starting point, I already had an interesting prototype to build on top of.
Day 2: WebXR changes the framing
The WebXR commit landed at 11:40 the next morning. By that evening:
- Plane detection so the track snapped onto any real table the headset could see
- AR mode with passthrough and decorations stripped for a cleaner look
- Haptic feedback on collisions and acceleration
- Simple controls: right trigger gas, left trigger reverse, joystick steering
What surprised me playing it for the first time was how natural the RC-car framing felt in passthrough. A flat-ground racing demo in VR is fine. A miniature racing on your coffee table is something else, you can lean over the track and look around the corner you keep missing.
The next day I migrated the project from raw HTML + JavaScript to Vue + Vite, because I knew I was going to be living in this codebase for a while and needed other NPM packages to survive. The open-source version of the pre-lock-in fork is on GitHub in case there is interest. The version after that is closed source, that's became the Shed Racer you can play on dmnshd.gg today.
What AI made tractable in WebXR game development
Eight weeks of part-time AI-assisted development, here's the rough chronology of the WebXR features that landed and how each one went.
Local split-screen, then real multiplayer (Apr 1–7)
Local split-screen is usually a feature solo developers (especially on the web) easily skip because it isn't quite a "real feature" but isn't quite trivial either. You need a modular input management system that can route a keyboard and any number of gamepads. AI knocked that out in an afternoon.
Networked multiplayer was easier than it had any right to be, for a specific reason: I'd already built a P2P host-client architecture (with a live peer-server using self hosted coturn) on top of peer.js for my previous (unreleased) game, Mr. Boom. I fed the networking code of Mr. Boom to the AI as a template. Essentially: "do the same thing here, but for cars". This got me a working prototype on the first prompt. The iterations after that were edge cases like: what happens when the host drops mid-race, how the lobby reacts when someone joins late, what post-race voting looks like.
From this experience I learned: AI is dramatically better when you hand it a working example to imitate.
"Build me a multiplayer system for my racing game with peer.js" gets you fine but generic decisions. "Use this attached networking code from my previous project, integrate it into this current project with the following list of requirements..." gets you something that fits the way you already think.
The audio overhaul, one day (Apr 8)
Converted the current audio system to a Howler.js-based system. Engine sounds that pitch with throttle. 3D audio that pans correctly as cars drive past you in VR. Haptics and collision sounds that fire on impact with improved collision logic. Screen shake tuned to feel right. It took one day for the whole pass to improve the game feel, as the iteration speed on each change felt like a breeze.
The hand-tracking system (Apr 10–11)
Someone on twitter had improved the mobile controls to use only one virtual joystick to move and I thought that was ingenius. mrdoob integrated it into the main repo and I copied that idea into Shed Racer, as it felt the best out of the many input methods out there.And when it came to designing the input method for hand tracking, it also felt like the best way to interact with the experience. A 3D pinch joystick that floats in the air and snaps back when released. Additionally, for first person mode, a double-pinch gesture toggling between first-person and top-down mode felt like a good addition. A grabable steering wheel is great in pinch with both hands, but it did bring some challenges with it. With only one input (pinch), how do you brake, accelerate and steer at the same time? This was one of the few times I realized that the tooling was still a bit short of being perfect for WebXR development, as it kept running into silly bugs with the wrong handedness being used for the hands and. After manual testing and prompting the issues into the LLM, we were done with hand tracking support. Thanks to the Immersive Web Emulator for making testing so much easier.
Rendering optimization, three days (Apr 14–16)
After showing the game to some friends, I realized the performance issues had to be addressed. On the headset, which is the primary market for dmnshd.gg, I was getting significant frame drops (OK I did aim for 90 FPS) and on low end mobile phones, you could clearly see the performance lagging. An advantage that the Kenney assets had were that they all shared one palette Texture. So I did couple of things: Four differently-colored cars rendering in a single draw call via per-instance shader palettes. Later: Decals batched per quadrant atlas. GPU teardown that doesn't leak textures between races. I never thought about these issues previously when I used Wonderland Engine, as a lot of optimizations were automatically done there, but with Three.js a lot of the optimizations are left up to the user (many of them on the asset optimization level). With LLMs, this becomes a learning experience as well, as you can just talk about the status, analyze the GLB files in tandem and come up with solutions that work for your project.
I got the LLM to build deeper debugging tools for the game as well that helped me find memory issues that might be problematic on some platforms with strict memory limits.
The amount of draw calls went down from ~54 to ~14 (Texture count increased though, but that's not an issue)
Career mode, garage, infinite mode, leaderboards (mid-April through May)
We added coin rewards from racing to unlocks new vehicles. Leaderboard support on dmnshd.gg with an around-me query (yay dogfooding). A garage to customize your vehicle with hats and decals. Additional track pieces for the map. A pause menu. Infinite survival mode. A tutorial overlay. A custom-levels hub with server-side thumbnails. A career mode. A bunch of work on making sure the menus worked well across all three supported modalities. Adding music, audio and haptic feedback to every state and interaction. Co-located VR multiplayer where two people in the same room share the same virtual space.
Each of these used to be a multi-week side quest. With AI, each was a one-prompt prototype followed by a day or two of iteration.
I could go into every individual design decision that went into these systems, but I'll leave it out to keep this post shorter.
Dogfooding for dmnshd.gg
The most useful thing about building Shed Racer in parallel with the dmnshd.gg platform is that the game became the forcing function for mainly two pieces of important platform features that didn't exist when I started:
The UGC system. mrdoob's port already had URL-based track sharing. It encodes a track into the URL parameter and you can send it to a friend. That worked for one-off shares pretty well, but it didn't work for a platform as well. I wanted tracks to have more permanence and increased sharability. Users should be able to browse, like and comment on tracks. So it became ideal for Shed Racer to become the design partner for the dmnshd.gg's UGC pipeline: server-side upload, thumbnail generation, a browsable hub of community tracks, likes and per-track pages. The whole pipeline got designed against a real, functional game and not in the abstract.
Multiplayer matchmaking. The peer.js host-client system inside the game handles the actual networking, but matchmaking and the listing of per game rooms are platform concerns that every multiplayer game on dmnshd.gg will eventually need. Shed Racer was the first game to utilize them, so the matchmaking APIs got designed around its requirements first. Future multiplayer games on the platform will inherit it and perhaps refine it.
Dogfooding sounds like a buzzword, but the practical effect is that the platform doesn't have any speculative features. Every system that exists exists because a real game needed it and broke without it. This approach is not totally future-proof, especially for the UGC system, as this will need much more refinement for future titles with more advanced UGC requirements. But with AI, smaller teams now can also get there.
What AI couldn't do for me
This is the part I want to be honest about, because the "AI ships entire games" framing is mostly hype.
AI defaults are design decisions. When your prompt is vague, what you get back is whatever the model considers the median answer. The quality of this approach does improve over time, but I wouldn't consider that a valuable approach. For utility systems this approach is fine: the median pause menu is a pause menu. But for design-heavy systems, the median answer is frankly a bit boring. The first pass of my career mode produced levels that were all roughly the same shape: very circular, a few corners and a ramp here and there. Some were unplayable, as the AI did not understand the dynamics of the design at all in some instances. They were semi-correct, unmemorable and did not evoke any type of real progression throughout the levels. To get tracks that felt like something, I had to prompt the specifics: adding corner sequences, where to put the boost pads and also manually redesign parts. An advantage here was that the level layouts are basic JSON structures.
AI will confidently implement the wrong solution. The example I keep coming back to is the decal system. I had no idea how to apply paint decals to a curved car body. My first instinct was axis-aligned planar projection: project the decal from one direction onto the geometry in a custom shader. I described this approach to Claude, it agreed it was a good idea and we built it. Once I saw it in the game I realized what was obvious in retrospect: a planar projection from one axis stretches the decal weirdly on every other axis. The decal looked fine on the side of the car, but stretched weirdly from the top. After prompting about it back and forward, I realized we had to scrap the specific approach. After looking at alternatives using projection, the AI helped me come up with a much more fitting solution, but only after I communicated specifically why the first approach was not working. The model is excellent at writing code. It is not your second opinion on whether the approach is good, unless you dig.
Game feel is still a human thing. Steering response, drift transitions with skid mark generation, the exact way the acceleration works or how long the screen shake lasts. These are some of the examples of things that are subjective and where the decisions you make will create the experience that you want. These are the decisions you make by playing the game and adjusting numbers until they feel right.
Visual polish is still a human thing. Color choices, the weight of a shadow, how a particle effect reads from across the room, whether a UI panel looks deliberate or accidental. AI can generate the shader, but it can't tell you the game looks cheap.
End-to-end testing is still a manual job. For Shed Racer, multiplayer is the most obvious case. You can't unit-test "what happens when player 3 joins during the countdown" without actually doing it across devices. We can now ship a multiplayer system in a day, but verifying it actually works as intended (especially in the wild) still means testing across headsets, browsers and different network conditions.
The numbers
- 8 weeks (March 24 to May 19, 2026)
- 2–4 hours per day on average, evenings and weekends
- One developer. Me.
- Tools: Antigravity + Cursor + Claude Code, primarily Opus 4.6/4.7 and Sonnet 4.6/4.7
- Cost: $60/month Cursor Pro subscription, $20/month Google AI Pro subscription
- Built on top of: Kenney's CC0 art, mrdoob's Three.js port,
crashcatphysics, Howler.js audio,peer.jsnetworking,@pmndrs/uikitfor spatial UI
I'm not claiming the game is as good or feature rich as Mario Kart. I'm claiming that the scope of what a solo developer can ship has changed (and is changing) in a way I didn't expect.
What this actually means for solo developers and small indie teams
The frame I want to leave you with isn't "AI creates the game, so you don't have to." It's that AI eliminates the task-switching tax that kills solo game development projects.
A solo developer pre-AI has to context-switch into being a graphics programmer for a week to do batched rendering, a netcode person for a month to do multiplayer, an audio engineer for a few days to do spatialization properly, a UX designer for a week to do menus, a tools engineer for two weeks to create an editor. Most of those weeks are spent re-learning a domain you don't actually have expertise in. That's where solo projects used to die for me. Not from the work itself but from the cost of switching. This is especially true for WebXR development, as the cost of on-device testing adds a significant burden to the creation due to device ergonomics. As emulators can't cover 100% of the feature set of devices nor the real experience of playing in them, there will always be the requirement of on-headset testing. Especially for niche features like shared-spaces, which hasn't been thoroughly battle-tested (as it is hidden behind a flag in the browser and only supported in the Meta Quest Browser), implementation becomes taxing.
With AI, you can stay in the design seat for longer sessions. The graphics work, the netcode, the audio system, the menus, the editor, they can become design conversations instead of long code sessions. Ideally, you are still making every decision in much faster iteration cycles.
What's next for Shed Racer
The core systems are in place. The harder work starts now and it's the work AI is least useful for.
The next phase is iterating on the game based on real player feedback. Which control schemes feel best on each platform, especially hand tracking vs. controllers in VR. Whether the UX flow can be improved upon, whether co-located VR sessions land the way I think they do (or are even useful). What kinds of unlocks feel fair or where the experience breaks down for the users.
Past that, the game needs more content and more polish. Specifically:
- Visual polish. The art reads as functional more than memorable. Tracks need a stronger sense of place and more variations. The garage and menus need improvement. AI helped me ship the systems, but making them look and feel like something interesting is going to come from a human eye and a lot of small adjustments.
- Game feel. Things like steering, drift, boost duration and collision response need to feel tighter. Numbers that need to be tuned by playing, getting feedback and iterating, not by prompting.
- More content. More tracks pieces, more vehicles (and more hats?) or more game modes. In short: more reasons to come back. Career mode needs better hand-designed standout levels, not procedurally-shaped filler.
- Marketability. The game needs a stronger identity to break out of the "another kart racer" bucket. And as we all know, marketing is every game developer's favorite domain.
You can play Shed Racer free in your browser right now, no download, no install. It runs on desktop, mobile, Meta Quest, Apple Vision Pro and any other device with a modern WebXR-capable browser. While you're there, check out the rest of our free WebXR games on dmnshd.gg and read more about the studio behind it. If you have feedback or want to chat about WebXR game development, the dmnshd Discord is the fastest way to reach me.
Thank you for reading!
Florian