Making the Game I Gave Up on Ten Years Ago
Post 1 of 6 about building Rainbow Tile Slide, a puzzle game I shipped to the App Store in September. I'm a product manager, not an engineer. Claude wrote every line of the code. I made the decisions, played it on real hardware, and filed the bugs.
About ten years ago, I took an online introduction to programming. Python. I finished it, I'm glad I did it, and I hated nearly every hour of it. My brain does not work that way. For whatever reason, I decided that course had qualified me to build a mobile game. I was delusional.
I was into tile games at the time, and I wanted to make one that ran on color, with a unicorn turning up now and then. I got a few hours in before I shut the whole thing down. Not because the idea was bad, not completely. Because I couldn't do it. Not the skills, not the patience, not any of it.
This summer I was sitting with my two children and it occurred to me that I could make something the three of us could play together. Easy enough to teach. Easy enough to put down, with no tantrums when it was time to turn it off. And I remembered the rainbow game idea. I wanted to know if I could do it. Could I build a simple game on my own, and get it all the way into the App Store? A week or so later I sketched out a plan. Five weeks after that, it was live.
How it came together
Thirty working sessions between July 28 and September 1, on nights and weekends around a full-time job. Not every night, but I found a way to log the hours needed to pull it off, and none of them came out of time with my kids.
I was approved for Apple's Kids Category, which carries a set of rules on top of the ones every app has to meet. It's free, no ads, and works with no connection. My kids love it.
What I did
The code was the fastest part of this project and the least of my problems.
I wrote down a first version of a plan of how to build, and separately wrote down what I wanted to be true about the game. I read one against the other and found the questions the plan hadn't answered. I made every decision. Board sizes, scoring, what the modes were for, what the art should feel like, whether to be in Apple's Kids Category and which age band. Some things I got wrong and found out by playing.
Oh, and I played it a lot. Not just "checked that it looked right," but sat with it on my own phone and my own iPad, and on simulated screens for sizes I don't own, and wrote up what broke.
And it goes without saying but I wrote the prompts, which matters more than it sounds like it should. What I asked for, how precisely I described a problem, whether I sent a screenshot or a sentence, all of it changed what came back. Most of the time, getting a useful answer was a question of asking a better question.
I used Claude to write the code and to track my progress and decisions. Every day or so I'd ask it to write up what we'd done and why, so that six weeks later I could still find out what past-me had been thinking. I used Gemini for parts of the submission process and some marketing copy, then brought most of that back to Claude to check, so I had two tools against each other rather than one.
My beta testers were my kids, giggling over the game's little surprises while eating snacks and passing the iPad back and forth.
I decided to publish under a game studio rather than my own name, and set up an LLC to do it. Partly to learn how that works, since there is no way to learn it except by doing it once. Partly because I wanted some distance between the person and the developer. The last post in this series is about that decision, and the week it cost me.
The tool is fast, fluent and confident, and it was wrong often enough that taking its word for things would have shipped a worse game. I wrote a whole post about the times it told me I was imagining something and I wasn't.
What changed, and what didn't
Ten years ago I stopped after a few hours because I couldn't write the code, and I was never going to learn to enjoy trying. This time I didn't have to. I wanted to make something colorful and cute. The heart of the game is the same - a little tile game built around the colors of the rainbow. What DID change is me.
Ten years of product work has given me a dedication to user experience. I made choices in this game, and spent real time on things, that would not have occurred to me then. I decided that a game you can only play by swiping is a game some people can't play at all. I sat with a screen reader running and wrote down what didn't make sense.
The end result is still a colorful game. It's not perfect, but it's mine to improve. I made a game that my family can play and share.
The next five posts go into the parts worth explaining. Getting what mattered into the plan. Accessibility as a Priority. The time the tool told me I was seeing things. The bugs that took the longest. And everything that happened after the game itself was finished.
Rainbow Tile Slide is free on the App Store, with no ads: https://apps.apple.com/us/app/rainbow-tile-slide/id6805617800
This is post 1 of 6 about building it. The rest of the series is here.