Vibe Coding 3D Games With Three.js and React

Games were supposed to be the domain where AI coding fell apart — too much math, too much feel, too much “you just have to try it.” Then I shipped Dolphin Beyond, a physics arcade game where you ride a dolphin from the ocean to space, to the browser and the App Store. Solo. Mostly vibe coded.

So: half of the scepticism is wrong, and the other half is more right than the sceptics know. Here’s the split.

The stack

Same foundation as everything else I build, plus the 3D layer:

• React Three Fiber (R3F) — Three.js as React components. This matters for vibe coding: the AI already thinks in React, so scenes, props and hooks come out idiomatic instead of as 400 lines of imperative soup.
• Rapier for physics — rigid bodies, colliders, impulses.
• Zustand for game state that changes 60 times a second, far away from React’s render cycle.
• Capacitor to wrap the same code for iOS.

My in-progress games — Ragnaroll (a 3D dice roguelite) and TinyTrack (a portrait drift racer) — run the identical stack. One set of conventions, compounding guardrails.

What AI generates brilliantly

Scene structure and boilerplate. Cameras, lights, loaders, responsive canvases, the entire ceremony of getting pixels on screen — near-perfect, first try.

Physics setup. “A dolphin-shaped rigid body with water buoyancy below y=0, gravity above, and torque control from touch input” — that prompt shape gets you a working prototype the same afternoon. Getting the same result from documentation used to be a week of my life.

Systems around the game. Score tracking, upgrade logic, save state, leaderboards, menus — this is ordinary app code wearing a game costume, and AI eats it. In Quiz Fight-style projects, content generation too: 500,000+ questions didn’t write themselves, but they also weren’t written by me.

Debugging the weird stuff. “The dolphin jitters when re-entering water at high velocity” is exactly the kind of question where an AI that has read every physics-engine forum thread earns its keep.

What AI cannot do

Game feel. The gap between “the dolphin jumps” and “the dolphin feels heavy and joyful when it leaves the water” is hundreds of micro-decisions — gravity multipliers, camera lag, easing curves, screen shake amplitude, the two frames of anticipation before a launch. AI will generate any value you ask for. It has no opinion about which one feels alive. That’s you, playtesting, at 23:41, adjusting a damping constant by 0.05 and honestly feeling the difference.

Performance judgment. It knows the techniques — instancing, texture atlases, draw-call budgets — but not which tradeoff your game needs on a three-year-old Android phone. You have to profile, then direct.

Scope. AI makes adding features so cheap that games bloat by default. The discipline of “this game is one dolphin, one run, one button” is product taste, and nobody generates that for you.

The workflow, adapted for games

The normal loop holds, with one change: the taste pass becomes a play pass. Code review tells you nothing about whether a jump feels good. So: generate a mechanic, play it within minutes, adjust by feel, repeat. Vibe coding shrinks the loop from idea to playable to minutes — which means you playtest fifty variations where you used to test five.

That, honestly, is the whole cheat code: AI doesn’t make your game good. It gives you fifty tries at making it good in the time one used to cost. The judgment about which try is the good one never stops being yours.