2026-08-27 · 3 min read
Maze Lume: nineteen good milestones counted as failures
The game worked for weeks and the ledger said it was failing. The work was real: everything broke at the moment of writing it down, which is the worst possible place to break.
Maze Lume is the game about the mage trapped in the dark, collecting orbs of light with the mouse to open passages into ever darker levels, while shadows chase him.
In the database, its milestone ledger is startling: 19 failed, 1 succeeded, 1 to do.
Put like that it looks like a project in trouble. It's the opposite: a project that was working beautifully with a broken ledger.
The version number says otherwise
The game reached version 35. Thirty-five published versions do not come out of a project that fails nineteen times out of twenty-one.
The two figures didn't add up, and when two numbers don't add up, one of them is measuring the wrong thing.
The work was there, the receipt broke
The error message was this: "illegal transition: published → milestone done".
A game's state ledger is a state machine: from "in production" you can go to "published", from "proposed" to "approved", and so on. It exists to stop a game ending up in a state that makes no sense.
Except that once it reached "published", a game could no longer close a milestone. And Maze Lume had been published since 25 August.
So: the milestone would start, the work would be done in full, the game would genuinely change — and then, at the last step, the one where you write "done" in the ledger, the state machine said no and the whole milestone was marked as failed.
Nineteen times.
Closing a milestone isn't changing state
The real flaw is a confusion of concepts, not a wrong line.
A game has a state: where it is in its life. A milestone has an outcome: how it went. Closing a milestone is annotating something in the game's history, not moving the game somewhere else. A published game that completes a milestone stays published: it's simply a little better than yesterday.
The fix — a function that annotates instead of transitioning — was already written, with a comment explaining exactly this. It wasn't wired to the place that needed it.
It's the most irritating shape a flaw can take: whoever opens the code finds the solution, reads it, and concludes the problem is already handled.
The nineteen milestones weren't re-run
They're still there, marked as failures. In all likelihood they had succeeded: they did the work, the game got to version 35 because of them.
We didn't rewrite them. A ledger corrected after the fact on the basis of an assumption is worse than a wrong ledger whose flaw you know: the second one you can still read, the first one you no longer know what to believe about.
They stay, with this note beside them.
What we take away
- A consistency check placed in the wrong spot blocks good work just as effectively as it would block bad work.
- When two measurements of the same project contradict each other — version 35 and nineteen failures — the right question isn't which to believe, but what each is actually measuring.
- If a flaw only shows up at the last step of a long job, it burns the whole job every time. Those are the most expensive kind there is.
