My son has wanted to make a game with me for years. You’d think having a dad who spent a good part of his career at PlayStation would help, but that wasn’t the kind of programming I did there.
I worked in ecommerce. I helped people buy games. I didn’t build them. Game programming was a whole domain I’d never touched, and every time he asked, I’d kind of shrug and say maybe later, because I genuinely didn’t know where to begin.
Claude Code is what changed it. At some point this year it started to feel like something I could actually attempt, even without the domain knowledge. So one weekend we gave it a try.
Figuring out what to build
We went back and forth on a few ideas before settling on a space game. Something that felt like Asteroids meets Angry Birds.
The core mechanic: you fling a spaceship along a trajectory at a speed you control. Pull the slingshot back further, the ship goes faster. Once you release, it’s at the mercy of gravity. Stars, planets, and black holes all pulling on it as it flies. Your goal is to land in a designated zone without coming in too hot.
We wanted scoring that rewarded precision over brute force. So we gave the rocket (which looks very much like the classic Asteroids triangle) a limited fuel supply for course corrections mid-flight. Here’s the catch though: every burn costs you points. You start each level with 1,000 points, and every thruster fire ticks that down, bottoming out at 100. The ideal run is one where you nail the launch angle and speed so perfectly that you barely need to touch the thrusters.
To keep it from feeling too punishing, fuel regenerates slowly when you’re not thrusting. So in theory you could play a level indefinitely, drifting through gravitational fields, waiting for fuel to trickle back, nudging yourself closer to the target. But your score would be in the gutter by then. That tension between “I could correct this” and “but it’ll cost me” is what makes it fun.
We had the concept. We had no clue how to build it.
Our design doc amounted to a few paragraphs and some hand-waving about gravity. That was the whole plan.
So we handed the whole concept to Claude Code and let it run. The first build that came back already had a ship responding to gravity, a starfield behind it, and a launch pad you could actually aim from. Not a wireframe. Not a stub. A thing you could launch and watch fly. That’s not where I expected to start.
From there it was a loop. We’d play for a bit, find something that felt off or missing, and ask Claude to adjust. Then play again. The radar minimap is a good example: the first version didn’t have one, and we kept losing the ship when it slung past the edge of the screen. We asked for a radar, got a radar, kept playing. That was the whole weekend. Play, notice a thing, ask, play again.
That loop is the part I want to dwell on for a second. Neither of us was reading the source. We were behaving like playtesters, not programmers, and the game kept getting better anyway. I’ve never had a side project feel like that before.
What we ended up with was a real game. Smooth physics, a proper aiming mechanic, visual polish, a HUD, that radar minimap, background music, five progressively harder levels. You can play it at gravity.westonsgames.com. Here’s what Claude built under the hood.
The stack
The whole thing runs on Phaser 3, a WebGL game framework that handles rendering, input, scene management, and audio. It’s the only runtime dependency. Source is TypeScript, bundled with Vite, about 1,900 lines total. No sprawling dependency tree, no asset pipeline, no game-engine-within-a-game-engine. Just Phaser, TypeScript, and a dev server.
Rolling its own physics
I was completely out of my depth here. Everything in this section is stuff I learned after the fact, poking at the code and asking Claude to explain what it had done and why.
Claude didn’t reach for a physics library. It wrote a custom gravity simulation from scratch.
The engine uses Runge-Kutta 4th order integration (RK4), a numerical method that’s significantly more accurate than the simpler Euler approach most hobby projects use. For a game about orbital mechanics, that precision matters. If the physics are even slightly off, trajectories feel wrong and the puzzle aspect falls apart. RK4 evaluates gravitational acceleration at four points per timestep and weights them to produce a much more faithful simulation.
The simulation runs on a fixed timestep at 120Hz, decoupled from rendering. An accumulator pattern collects elapsed time and steps the physics in consistent increments, then interpolates between states for smooth visuals. This means the game behaves identically at 30fps or 144fps. The physics are deterministic.
Gravity follows Newton’s law. For every celestial body in the level, the engine computes the pull on the ship from mass and distance, with a clamp at the body’s radius to avoid division-by-zero singularities. It supports N-body interactions, so levels with multiple stars and planets create genuinely complex fields.
Managing the artwork
There are almost no art assets in the project. One background music track, and that’s it. Everything visual is drawn in code: the parallax starfield, the procedurally generated nebulas and spiral galaxies, the glow rings around stars, the accretion disks around black holes, the rotated triangle that is the ship with its dual-layer flame flickering when you thrust.
When I first heard “no sprites” I assumed it would look like a programmer art demo. It doesn’t. It’s circles, lines, and alpha blending, and it looks surprisingly good. I think that’s the part that updated my priors the most. I had a category in my head for “real game art” and a category for “stuff a backend engineer can make in an afternoon,” and it turns out the gap between them is smaller than I thought, at least for a game like this.
How the levels work
Each level is a JSON file defining the world size, gravitational constant, celestial body positions and masses, the launch pad, the landing zone, and the scoring thresholds. Five levels ship with the game and they ramp up nicely:
- A single star. Learn the basic mechanic.
- A binary star system. Deal with competing pulls.
- A black hole and a star. Extreme gravity warping your path.
- A trinary system. Three bodies creating chaotic fields.
- A gravity slingshot puzzle. Use orbital mechanics to whip around stars with tight fuel constraints.
Adding a new level is just writing a new JSON file. No code changes.
The decisions I didn’t have to make
The thing I keep noticing, as I poke around the code, is how many small architectural calls Claude made that I’d have had to learn the hard way. Three Phaser scenes running in parallel with the game scene emitting events and the UI scene listening. Physics steps that produce a new state object instead of mutating the old one, which kills a whole category of half-updated-state rendering bugs. Levels defined entirely as JSON, no hardcoded logic, so adding a sixth level is writing a file, not editing the engine.
None of these are exotic. They’re the kind of decisions an experienced game developer makes without thinking about it, and an inexperienced one (me) discovers two weeks in after stepping on the rake. Getting them for free is a big part of why the weekend project ended up feeling like a real thing.
What sticks with me
I’ve been building software professionally for a long time and I’ve never built a game. My son and I went from a napkin sketch to a playable, genuinely fun five-level game, and I still haven’t needed to read the source to enjoy it. Claude made every technical decision, from the physics integrator to the rendering approach to the architecture, and they’re all decisions I’d be comfortable defending in a code review.
That’s the part that gets me. It’s not that AI wrote code for me. It’s that it made good decisions, the kind that come from experience I don’t have in this domain, and produced something my kid and I actually want to play.
And the thing I keep coming back to: I’m a programmer, and I needed this to get over the hump. My son isn’t a programmer. He’s a kid with ideas. The gap between “I want to make a game about X” and actually having that game in front of you is about to get really small for people like him. I don’t think I’ve fully wrapped my head around what that’s going to unlock, but I’m pretty excited to find out, especially sitting next to him while he does it.