Tidepool

I'd started and abandoned three game projects before this, always because I designed something too big and lost interest around the point where it stopped being new. This time I deliberately picked something small and well-understood — a tile-matching puzzle with one mechanic — so that finishing was actually possible. The goal was never to make a good game; it was to go through a full cycle including the parts I always skip, like menus, saving, and export. It took about five months of weekends.

Honestly, it doesn't solve a problem for anyone but me. It's a puzzle game with sixty hand-designed levels and one twist on the usual matching mechanic — tiles have a flow direction, so clearing a group shifts neighbours sideways rather than just down. It's for people who like a quiet puzzle on a phone, which as far as I can tell is about two hundred people, most of whom are friends and their families. I put it out free with no ads because taking money for it would create an obligation I don't want.

Everything except the music, which a friend wrote. Game logic, the level editor I built for myself, all sixty levels, the art, menus, save system, and the Android export. The level editor was the best decision — building levels in a text file was fine for the first ten and unbearable by the twentieth, and the two weekends I spent on the editor bought back far more than that. The art is simple flat shapes, which is a style choice made downstream of the fact that I can't draw.

I decided early that the game would ship with no progression systems, no energy timers and no accounts — you open it, you play a level, it saves. This ruled out most of what makes puzzle games profitable, which was fine since I wasn't selling it, and it removed roughly half the scope. I chose Godot over Unity mostly because I wanted to learn something in the open-source ecosystem, and its scene system matched how I think about UI from mobile work. I also made every level solvable without randomness — no random tile spawns — so a level is a fixed puzzle rather than a slot machine. That made design much harder and made the game something you can actually be good at.

Difficulty curve. I designed the levels in the order I thought of them, and when I finally gave it to five people to play, three of them quit around level twelve because it spiked. I couldn't see it because I'd played every level a hundred times while building it. I ended up recording where each tester stopped, reordering all sixty levels by observed difficulty rather than intended difficulty, and designing eight new easy ones to fill the gap in the first third. That reordering was more valuable than any single level I made.

I finished it, which was the actual goal and which I'd failed at three times. It has a few hundred downloads and a handful of reviews, one of which is a complaint about level 34 that is completely fair. I learned enough Godot to be dangerous and enough about playtesting to know I can't evaluate my own difficulty curve. My next game project is on attempt one of what will probably be several.

A friend who makes music wrote the four tracks and the sound effects in exchange for nothing, and they carry more of the mood than my art does. Five people playtested, and the three who quit at level twelve taught me more by quitting than the two who finished did by finishing. My girlfriend played every level as I built it and stopped me shipping two that were unfair rather than hard, which is a distinction I couldn't see any more.