← Dev Log
Six months building a game with AI, after never finishing one before

Six months building a game with AI, after never finishing one before

building with AIAI-assisted developmentbrowser strategy gamesolo game developmentgame development retrospective

TL;DR: In February I started this as a break from work and a test of a new way of working: coding on my phone, on the provider’s cloud, while I was on holiday. I’d been coding with AI for over a year but had never finished a game, though I’d started plenty. Six months and around a thousand players later, it’s a deep multiplayer game and it’s live. I was never really unsure the AI could do the coding. The experiment was whether I could, working this way, and what I’d pick up doing it.

Why a game

I’ve written software for thirty years, most of it in web development. I went that way for the speed. You can build something in the morning and have people using it by the afternoon. Games are the opposite. They pull you back into slower, traditional software work, and they take a patience I’d never quite had for them. I’d started plenty over the years and finished none. A browser game sits in between, quicker to ship than a native one but still slow to smooth out.

What I wanted was something that was mine. No dependencies on other people, no consensus decisions with business partners, and a hundred small things to do, which made it fun in a way work sometimes isn’t. The trigger was the workflow. After a year of AI coding, from ChatGPT copy-paste to Copilot to Claude and Codex, there’s a constant low hum of fatigue to it, something new every few days. People were talking about coding from their phones on the provider’s cloud, so on holiday I opened the Claude Code mobile app and started building to see if that setup could produce something real. I was fairly sure the AI could code a game. I wasn’t sure about doing it from a phone, on someone else’s cloud, away from my desk.

How I knew it was working

I release things a little rough on purpose. Bug-free, but not polished. If I ship something and hear nothing, it means one of three things: nobody’s interested, nobody’s found it, or I got it right first time. The data sorts those out. What I watch for is a player messaging me. If something’s rough and they still want it, not need it, want it, they write. Even negative feedback feels good, because they spent the time. Alongside that I measure the plain things: time in the game, islands taken, how often people log in.

Inselnova showed early activity, and some of that was luck. I built it on the bones of an existing game, so the odds of finding players were better than starting cold. People turned up, stayed, and talked to me, so I kept going. If it had stayed silent, I’d have moved on.

The loop I ended up with

The method that fell out of it is a loop. I hit a problem with the AI, work out how to get it to do the thing properly, and write that down as part of my setup. Next time something similar comes up, on this project or another, I start further ahead. I can’t recall every mistake it made and how I fixed it, but the shape of those fixes sits in the back of my head and points me in a better direction the next time.

The AI was better than I expected at the raw work. It made the usual messes, single files that grow to four thousand lines, that kind of thing, but those are quick to break down once you’ve done it a few times.

Where AI still can’t help

The parts I’m still working on are the limits, and here they’re mostly design. Getting the UI to line up, I think I’ll solve with a method I’m building where I sketch each screen and sign it off before anything gets built. UX is harder and I haven’t cracked it. There’s usually a new UX problem none of my rules cover yet, and I don’t expect the AI to feel the game the way a player does. I tried Playwright to let it improve its own designs and gave up, it misses the point. I use it for one job now, checking that a player can register, get in, and finish the first tutorials. The rest I test myself.

There are two more limits. The tests catch things I’d never spot, which matters when the AI writes most of the code and I’m not reading all of it, but they only check the rules I gave them, not whether those rules are any good. And the AI can’t design the game. Ask it for ideas and it hands back the classics, the things it already knows. That part has to come from me.

I’m doing all of it end to end too: the game, the planning, the marketing, the graphics. That’s part of why it works as a break from normal work. It’s entirely mine.

Build things, throw them away

The advice I always gave web developers was to just build things. Lots of them. Prototype, throw them away, try again, rack up failed projects, move on. Building with AI is no different. Make something, throw it away, make it again. You get better by doing it more.