DEV Community

IdleCultivation
IdleCultivation

Posted on

Retiring a gate: when a breakthrough stopped being a checklist

Development covered 7 Jul 2026 to 10 Jul 2026 (commit dates).

The largest moment in a cultivation game is the breakthrough: the step from one great realm to the next, which in this genre is where people die. It is the single most important pacing beat the game has, and for months it was designed as a checklist. This stretch I threw that out.

What was wrong with a list of prerequisites

The earlier gate asked for several things at once. A specific consumable, held. A stat above a line. A second stat above another line. Meet all of them and the door opens.

Every one of those requirements is defensible on its own and the sum of them is paperwork. A player standing at the door reads a list of red items and goes shopping. There is no decision in it, only errands, and the moment they have been run the outcome is already known. The most dramatic beat in the genre had become the least interesting screen in the game.

There is also a quieter problem with threshold gates in an idle game, which is that they turn a smooth curve into a wall with nothing on either side of it. Below the line, extra progress buys nothing. Above the line, extra progress buys nothing. Players optimise toward the wall and stop, which is the opposite of what a game about relentless accumulation wants them doing.

One charge instead of four conditions

What replaced it is a single accumulating quantity, called Heritage in the fiction, which represents everything you have built up short of the leap itself. Reaching the top of your current realm opens the attempt. Heritage decides how safe it is.

Two properties matter. It is continuous, so every bit of it counts and there is no wall to stand at. And it is spendable in the sense that an attempt consumes it, so the player is always choosing between going now with what they have and staying to build more. That is a real decision with a real cost on both sides, which is what the checklist never managed.

Consumables did not vanish; they became one way of charging it rather than a mandatory ticket. That preserves the alchemy loop's reason to exist while removing its power to block. A pill should be an advantage, never a toll booth.

The other thing I like about it is that it explains itself. A player who fails an attempt at a low charge learns the mechanic from the failure. A player who fails a threshold gate learns only that they misread a list.

Forty copies of the same six lines

The rest of this stretch was unglamorous and I think more valuable: a long pass through both halves of the project deleting duplication.

The count surprised me. The same wallet read opened seven separate transactions. The same byte-size formatter existed four times, and three of the four agreed. One item-name lookup was written three times and the copies had drifted in both directions, so each was right about something the others got wrong. Sixteen places inlined the same increment on a count map, and one of them could produce a nonsense number. A seeded random generator existed six times across the project.

None of that came from carelessness exactly. Each copy was made at a moment when the shared version would have needed one more parameter than it had, and copying was two seconds while generalising was twenty minutes. What is invisible at the moment of copying is that a duplicate is a silent decision to maintain two things forever, and the interest on it is paid by whoever fixes the bug in only one of them.

My working rule after this pass: the second copy is where you pay attention, not the third. By the third the drift has already happened.

Before touching the two big untestable files

Two files in the game are monsters. The world scene and the map editor are both several thousand lines, both hold state in closures, and neither had any test coverage at all, which is exactly the condition where a cleanup turns into a week of chasing ghosts.

The approach that worked was writing characterisation tests first: not tests of what the code should do, but tests that pin down what it currently does, including behaviour I suspected was wrong. With that net in place, lifting a subsystem out becomes a mechanical operation with an alarm attached. Six pieces came out that way.

The net also earned its keep immediately by catching two genuine faults in the undo history that had been sitting there unnoticed. That is the usual reward for writing tests against old code: the first thing they tell you is that your memory of how it behaves was optimistic.

More devlogs and the game: Incremental RPG.

Top comments (1)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.