Dragons & Colours
How I built a puzzle game in five weeks: an artifact prototype, Claude Code for the build, Gemini for the art and a second opinion, and a small team of agents that each earned their place.
My partner loves puzzle games. Every evening there’s one on her phone, and for years she’s asked me the same thing: “You build stuff all day. Why don’t you make me one?”
And for years, I didn’t. There was always a reason. Work was busy. A game is a big project. I’d do it properly when I had the time, which meant never.
Then one day we were sitting around, she was halfway through a puzzle, and it got me thinking. The tools I use every day have changed. Could I actually build one now?
So I did. It’s called Dragons & Colours, it’s for her, and it started as a single HTML file.
The rules fit in one sentence: place one dragon in every row, every column and every colour region of the grid, and no two dragons can touch, not even diagonally. That’s it. The rest is logic.
Five weeks later it’s an Android app in internal testing on Google Play. It has six chapters, 260 levels, a daily challenge, achievements and leaderboards. That’s ten releases since the first upload on 7 September.
Home
A board
A win
This is how I went about it, what I used, and which bits I’d do again.
Research: a prototype in an artifact
It started in claude.ai, the same research phase I wrote about in Research, build, learn. I riffed on the idea until it was a playable single-file HTML game: five levels, lives, hints, confetti. It even saved progress through the artifact’s own storage.
Once it was fun, I asked for a spec. Not code, a document: the rules, the scoring, the hint logic, how the puzzles get generated, and how to port the prototype into a proper project and package it for Android.
The prototype proves it’s fun. The spec is what the build agents actually work from.
Build: Claude Code in WSL2
The spec went into a repo, and Claude Code in WSL2 took it from there. Vanilla HTML, CSS and JavaScript, wrapped for Android with Capacitor. No framework. About ten thousand lines of game code now, and a couple of dozen test files, including one that fails the build if an update would lose a player’s progress.
The first commit and the first upload to Play internal testing happened on the same day.
One rule changed everything
Most puzzles like this let you tap a cell, try something, and undo it if it doesn’t work. Trial and error is free.
I didn’t want that. In Dragons & Colours a correct dragon locks in, and there’s no undo. A wrong one costs a life, and you only get three. So you can’t test a hunch with a dragon without paying for it.
That one decision turned out to drive almost everything else. If guessing costs you, then every level has to be solvable by straight deduction. No “assume this, see what breaks, back up”. Otherwise the game is just unfair.
So the levels aren’t hand-made. A Python generator builds each one, checks it has exactly one solution, and then runs a step solver that has to complete the whole board by deduction alone. If the solver gets stuck, the level doesn’t ship. Two early levels were made before that check existed. Both stalled after one dragon, and both got retired.
If the rules say guessing costs you, the levels have to promise you never need to guess.
The art: Gemini paints, scripts finish
Claude Code can draw, but it doesn’t paint well, not compared to Gemini. So every bit of painted artwork comes from Gemini.
It started with style references. I asked Gemini for sheets of expressions for the two characters, a dragon and a knight, just to find the look:
Dragon expressions
Knight expressions
Those were far too loud for a calm puzzle game. The final look is warmer: painted wooden tiles and a sticker book, muted dusty colours, a heavy ink outline, nothing pure white or pure black.
The production art comes from the Antigravity CLI, which runs a Gemini agent headless from the shell. Claude Code calls it directly, always on Gemini 3.8 Flash at high effort, and asks for one image at a time. Every prompt is one line naming the thing, then the same style block, word for word, so a sticker painted in week five matches one from week one.
A few things I learned the hard way:
- Describe the mascot every time. Leave it out and Gemini invents a paler dragon with black eyes. Same for the knight.
- Ask for a flat cream background, no shadow. That’s what lets a script cut the sticker out cleanly. A vignette comes back as a grey halo.
- Say “no white border”. Otherwise some come back as die-cut stickers and some don’t.
- Edit, don’t repaint. The dragon over the Play button blinks. That’s Gemini’s image-editing mode, given the same picture and asked to close only the eyes. A script then keeps just the eye area, so nothing else can jump.
Everything after the painting is a script. One cuts out backgrounds. One traces the dragon mark into a single SVG path, so the board can turn it green or red. One draws the achievement badges around the stickers. Even the sounds are made by a script, from wood-knock and marimba models, so there’s no recorded audio to licence.
The Gemini advisor
Gemini has a second job: it’s a fresh pair of eyes.
Claude Code can hand it a rendered screen, an icon or a diff and ask what it sees, in under 80 words. It doesn’t know the history or the rules, and that’s the point. The working notes say to treat its answer as “a colleague’s opinion, not a verdict”. Claude weighs it against the rules, and anything that turns out to matter gets written down.
The market researcher agent uses it the same way. When a verdict on a feature is close, it asks Gemini once for the strongest case against, and reports whether that changed its mind.
The agents
I’m not chatting with one agent all day. The repo has a small team, each with one job:
Level designer
Who: GeneratorStep solver
Generates, picks and checks levels, a whole chapter of fifty at a time. It owns the difficulty ramp, so each chapter opens a notch above the last.
Device QA
Who: EmulatorHeadless Chromium
Runs the game, taps through it, reads the logs, and regenerates the store screenshots you can see above.
Android lead
Who: CapacitorPlayPlay Games
Owns the native side: the build, signing, releases, achievements and leaderboards.
Performance
Who: Android UXAnimation doctor
Two of them. One is consulted before a screen is built, the other diagnoses jank after. They apply the easy fixes themselves.
Backlog curator
Who: GitHub issues
Turns tester feedback into issues, finds duplicates, and ranks what to do next. It never touches code.
Market researcher
Who: WebGemini
Researches a feature before it’s built: who else has it, what their players say, and whether it’s worth doing.
Alongside them are skills for the repeatable jobs: generate levels, preview a screen, verify a change, run a Play release, diagnose a slow animation.
Yes, I know I just wrote Burst pressure. But none of these started on day one. Each one showed up when I kept giving the same context for the same job. The level designer came first, because levels were the thing I kept redoing by hand.
Testers are better at this than me
The game used to give you points for every square you never marked with a ✕. It sounded clever. Testers worked out how to game it pretty quickly, and they found it pointless anyway. So it’s gone: marks are free notes now, and the “perfect” achievement means winning without the Checker hint.
I would never have spotted that on my own. I knew how the game was meant to be played, and they didn’t.
Write the rules down
The most useful file in the repo isn’t code. It’s the working notes, the file every agent reads first. It says why there’s no undo, why every level has to pass the solver, how to call Gemini, and what each prompt has to include.
Without that, every agent would happily “improve” the game by adding an undo button. With it, they defend the rules for me.
Final thought
The lesson is the same one as everywhere else: prototype until it’s fun, decide what’s fair, write it down, and give each tool the one job it’s best at.
But that’s not really why I built it. She asked for years, and the excuse was always time. It turned out the time was never the problem. I just hadn’t started.
She plays it every evening now. She’s also my harshest tester.
When it’s out of testing, I’ll put the link here.