The tap was on time: input buffering in a one-button minigame

Development covered 4 Jul 2026 to 8 Jul 2026 (commit dates).

Cultivation in this game is mostly waiting, on purpose, so the one place a player gets to be quick with their hands has to feel exact. A meter sweeps, you tap when the marker crosses the good zone, and the session speeds up a little. Small feature, two afternoons, and the first version felt broken in a way nobody could describe beyond calling it laggy.

The tap was on time and the game disagreed

The first version asked the obvious question at the obvious moment: where is the marker right now, and is right now inside the zone. That is exactly the rule a player would state if you asked them, and it produces a game that feels like it is arguing with you.

The reason is that a tap is not an instant. It is a small span of intention that starts before your finger moves and ends after the screen has already changed. A marker crossing a narrow band at speed can be inside it for a couple of frames, so a player who was reading the screen correctly, and who committed at the right time, is judged on where things stood after their decision was already made. They do not experience that as a miss. They experience it as the game being slow.

The cure is to judge a window instead of a moment. Hold the intent for a short span and ask whether the marker was in the zone at any point inside it. Nothing about the difficulty changes on paper. Everything about the feel changes, because the game now agrees with the player about what happened. This is old knowledge in fighting games and rhythm games and I still had to learn it again by hand, which is the usual way.

The general lesson I keep relearning: when a player says lag, they are describing a disagreement about time, not a measurement of it.

When the same word means two things

The larger job this stretch was finishing a rename that touched about sixteen hundred references across the project. Every object in the world had already been given one canonical name; the remaining work was making the code say that name everywhere, mechanically, without a human reading each line.

An automated rename is easy right up to the moment a word is doing two jobs. Ours were doing several. The short label for a cultivation stage was spelled the same as the pill that helps you reach it. The word for the trading district was also the name of a screen, a tab, and an unlock flag. A blind rename turns all of those into the same thing, and the failure is silent, because the code still runs and simply means something else.

Five passes to get it right, and each pass was less about the tool and more about drawing a boundary: which words name a thing in the world, and which words name a state of the software. Those two vocabularies had grown into each other over months, and separating them was the actual work. The rename was the excuse.

If I had to state the rule I now believe: never let a name that appears in fiction double as a name that appears in a switch statement. One of them is going to change for reasons the other does not care about.

A skill tree drawn by physics looks like a bramble

The other visible feature was a rebuild of the skill tree, and the layout went through three shapes before it read as a tree at all.

The first was a spring relaxation: place the nodes roughly, then let repulsion push them apart until nothing overlaps. It works, in the narrow sense that no two circles sit on top of each other, and it produces a picture nobody can navigate. The arms bend. Lines cross. Two nodes that are conceptually siblings end up on opposite sides because a third node shoved them there. The layout is correct and it is not legible, which for an interface is the same as being wrong.

The second attempt used the branch depth for distance from the centre and the tier for angle, which sounds principled and scattered every tier across the whole disc.

What finally worked was giving up on the algorithm and giving each branch an axis. Four directions, one family of skills down each, openers on the axis line and their children fanning symmetrically around it. Distance from the middle means progress. Direction means which path you have chosen. Nothing crosses because nothing is allowed to.

The general shape of that mistake is worth naming, because I make it often. A relaxation algorithm optimises for the constraint you can express, which was overlap. What a player needs from a skill tree is a constant answer to where am I and what is near me, and that is not a constraint you can write down as a force. Sometimes the honest move is to stop computing the layout and just decide it.

Free to start, no install: Cultivation Game.