Development covered 27 Jul 2026 to 3 Aug 2026 (commit dates).
I spent this stretch doing something tedious and overdue: opening every panel in the game, pressing every control on it, and asking one question each time. What changed. Not does it error, not does it look right. What is different afterwards.
The answer, dozens of times, was nothing at all. The button highlighted, the panel responded, sometimes a message appeared, and the game state was untouched. I want to write down the shapes these took, because they are more alike than I expected.
Five ways to be dead
The inert toggle. A switch that turns on and off and is read nowhere. Ours was a remote-shopping option that a player could flip freely and which changed no price. Later, when the other half was built, it started applying a surcharge without ever having explained itself.
The promise with no implementation. A skill node describing an effect, priced, purchasable, and connected to nothing. A third of one tree was in this state. The description is the feature as far as a player is concerned, so this one takes money for a lie.
The counter nothing increments. Two achievements tracked a list, and no code anywhere added to that list. Perfectly implemented unlock conditions on a value fixed at zero forever.
The panel showing numbers the game does not use. A screen displaying attributes that no mechanic reads. Everything on it is real, computed, updated, and it describes a system that does not exist.
The refresh that refreshes nothing. A board with a refresh button whose data cannot change between presses. It does not fail. It succeeds at doing nothing, quietly, and the player concludes their luck is bad.
Why these survive every review
None of it is carelessness, which is what makes it interesting.
Every one of these was built as one half of a pair. The toggle was written while the pricing rule was still being designed. The skill node's description was authored during content work, with the effects to be wired in a later pass. The achievement was written against a tracking list that got dropped in a rewrite. In each case the missing half was on somebody's list, and the half that shipped renders perfectly, so nothing ever asks about the other one.
They survive review because reviews look at changes, and a dead feature is not a change. It is an absence sitting next to a presence. They survive tests because tests assert what the code does, and this code does exactly what it says: it sets a value nothing reads. They survive play because the game does not break. The player just quietly comes away with a worse model of how any of it works.
The rule that catches most of them
The one I am adopting: a control is not finished until something downstream reads it, and the commit that adds the control adds the read or the control does not go in.
That sounds obvious and it directly contradicts how it feels to work. Building the visible half first is satisfying, demos well, and makes the remaining work look small. It is also how you accumulate a screen full of things that respond and do not act.
Where the halves genuinely have to land separately, the fix is not discipline, it is visibility. An unwired control should be absent, not present and inert. Hiding it costs a line and it means a player never learns something false about the game.
Tooltips are a contract, and mine were lying by a factor of a hundred
A related family, worth separating out. Several node descriptions were not merely unimplemented, they were wrong: one understated its effect a hundredfold because the number was written as a percentage in one place and a fraction in the other.
A player reads that description and makes a decision with it. If the description says one thing and the mechanic does another, the mechanic may be perfectly balanced and the game still plays badly, because the player is optimising against the text. Description and effect should be derived from one value, always, and where that is impractical something should compare them automatically.
The version of that I have seen bite hardest is percentages, every time. Any number that can be written as either three or nought point nought three will eventually be written as both.
The most useful question I asked all week
Not what is broken. What did this change.
It is a slower way to go through an interface and it finds a category of problem that no error, no crash and no failing test will ever show you, because at every level below the player everything is working exactly as written.
Playable today: Idle Cultivation RPG.
Top comments (0)