The Algorithm Was Right. The Question Was Wrong.

I'm building a Unity game by directing Claude. Most of the time it goes fine. For three weeks, on one specific problem, it didn't.

The setup: the game is a planet the player shapes by placing materials on its surface. The planet starts simple — twelve tiles — and gets finer as the player adds complexity. Each subdivision step replaces every tile with a small cluster of new ones. The constraint that broke us: when a tile gets subdivided, its children need to look like the same region of the planet. If the player has placed dirt on a tile, the cluster of children that replaces that tile should still read as "that piece of dirt," just at higher resolution.

This is called inheritance. I thought it would be easy — it's not.

We wrote seven algorithms. Every one failed in a similar-looking way — clusters that grew into lines instead of disks, single tiles that propagated into branching shapes, separated regions that quietly merged into one as the planet got finer. The fix wasn't an eighth algorithm. It was two questions, asked weeks apart, that I should have asked sooner.

First Question: Am I Working at the Wrong Layer?

The first six algorithms were variants of the same idea: figure out which old tile each new tile is closest to, and inherit from that one. Different ways of measuring "closest," different tiebreaking rules, different math. They all produced output that looked wrong in the same family of ways. After the sixth, I noticed something I should have noticed sooner: when many attempts converge on the same kind of wrong answer, the problem usually isn't with the attempts.

When many attempts converge on the same kind of wrong answer, the problem usually isn't with the attempts.

I asked Claude a different kind of question. Not "what algorithm should we try next?" but "why does this kind of algorithm produce this kind of output on this particular planet?"

The answer pointed at the planet itself. The library we'd been using built its hex tiles on top of a mesh whose underlying structure was triangular, not hexagonal. The tile centers weren't laid out the way a regular hex grid is — they were laid out on a pattern derived from triangle math, which meant the "neighbors" of any given tile weren't arranged in a circle around it. They were arranged more like a line. Every algorithm we'd written had been faithfully tracing that linear structure, which is why every result grew into a line.

I don't fully understand the geometry. I'm a designer, not a mathematician. But I understood the consequence — no algorithm we wrote on top of this library would ever work — and I understood what that meant for the project. We were patching a broken foundation. The fix was to replace the foundation, which sounds dramatic but is what you do when the layer underneath your work is the layer that's wrong.

We did. Claude built a custom hex sphere from scratch, designed for the kind of inheritance we needed. A few sessions of work. New foundation, real hexagonal neighbor structure, parent-child relationships built in.

Then we wrote the seventh algorithm, ran the tests, and watched it fail in a different way.

Second Question: Am I Solving the Wrong Problem?

The new failures were softer than the old ones — clusters were closer to right shapes, growth was closer to circular — but they were still wrong. A player-placed tile would shrink to a sliver. Two separated tiles would have their grown clusters merge into one connected blob.

This time I sat with the screenshots for a long time before asking anything.

What I noticed: every failed test mixed placed tiles (where the player had put something) with empty tiles (where they hadn't). The algorithm was trying to produce correct inheritance everywhere — for the placed tiles and for the empty tiles, treating both equally. And every test that broke was breaking on the empty tiles in ways that hurt the placed ones.

We were looking at how subdivision affected a tile and its children in relation to all the tiles on the sphere. A player only cares about the tiles they've placed.

That sentence was the second question, in answer form. I'd been asking how do we get inheritance right everywhere on the planet? The actual problem was much smaller: how do we get inheritance right on the small set of tiles the player chose to put something on? The empty tiles are disposable. The player will never look at them. Their inheritance can be wrong, weird, geometrically ugly — nobody cares. The only tiles that need clean, coherent, region-preserving inheritance are the ones the player placed.

A concrete proposal came with the insight. Enforce a minimum cluster size for player-placed tiles. Let them claim nearby empty tiles to give each one a guaranteed floor of children. Let the empty tiles take whatever geometric hit comes from being claimed. Same idea applied to gaps: if the player placed two tiles with empty space between them, that gap is meaningful — the player intended two distinct things — so the algorithm shouldn't let the grown clusters merge across it. Refuse the claim that would create the merge.

We named the new approach player-priority subdivision. The algorithm that came out of it was dramatically simpler than the seven that preceded it.

It worked.

What I'd Tell Someone Staring at Their Own Seventh Algorithm

The trap I fell into for three weeks: when an algorithm produces the wrong output, the instinct is to write a better algorithm. Try a different distance metric. Add a tiebreaker. Cache something. The instinct treats "the algorithm" as the problem.

The two questions that finally worked weren't smarter algorithms. They were the same move applied at different layers — step back, look at the work from outside, and ask whether you're doing the right thing at all. The first question challenged the layer I was working at: was I trying to fix something on top of a broken foundation? The second question challenged the goal of the work: was I solving a bigger problem than I needed to solve?

Most stuck problems are one of those two. Either you're working on the wrong thing, or you're working at the wrong level. Both questions feel terrible to ask, because they imply that some amount of recent work was wasted. They are also, in my experience, the only questions that move stuck projects.

Both of mine, in the end, were variations on the same one: what does the player actually care about here? It would have saved me six algorithms.