We wrote a robot to play our game perfectly, and it found a 55-minute hole

No. 01

A probe that plays the real simulation as a flawless player turned out to be the most useful thing in the repository, because it measures the one thing a developer cannot feel.

You cannot playtest your own game for pacing. You know where everything is, you know what to buy next, and you have played the first ten minutes four hundred times. Every instinct you have about whether the middle drags is contaminated.

So we stopped guessing and wrote a probe.

What it does

It is not a bot in the game. It imports the actual simulation — the same module the app runs, with no rendering, no input and no clock — and plays it as a perfect player. It never misses a collection, never hesitates over a purchase, never wanders off. It walks the whole run from the first dollar to the warehouse and prints what happened.

That last property is the important one. A perfect player is a floor. Every gap the probe reports is the shortest that gap can possibly be, because a real person is slower and never faster. If the robot is bored, everybody is bored.

What it found

The first run was not close.

 4.0m  printer #2     7.3m  printer #3    10.7m  printer #4
15.0m  printer #5    20.3m  printer #6    75.7m  WAREHOUSE
LONGEST DEAD STRETCH: 55.3 min

Six things to buy across seventy-six minutes, and then a fifty-five minute stretch with nothing to decide at all. Not idle time — the tray cap meant the player still had to tap roughly three hundred and forty times inside that stretch simply to stop the machines stalling. Work without decisions, which is the worst combination available.

The opening, meanwhile, was fine. A purchase every three to five minutes, gaps widening gently, a start with no money that teaches the whole loop in about thirty seconds without a tutorial. Nobody had touched that curve and nobody should.

So the problem was not tuning. Cutting the price of the warehouse would have shortened the hole without putting anything in it. It was a content gap wearing a pacing gap's clothes, and the two have completely different fixes.

What we did

Built the thing that belongs in the middle: a research spine and a set of workstations, so the stretch between the sixth printer and the warehouse has decisions in it rather than distance.

Then re-ran the same probe, because a fix nobody measured is a hope.

lane      warehouse   longest gap   purchases
chamber     100.0m        10.3m         31
freeAir      91.4m        10.8m         31

Six purchases became thirty-one. The longest stretch with nothing to buy went from fifty-five minutes to about ten. The run got longer and stopped being empty, which is the direction you want — a game is not improved by being shorter, it is improved by having something in it.

The part worth stealing

The probe is an instrument, not a test. It has no assertions of its own: it reports numbers, and a separate gate decides what they mean. That separation is the whole design. A pacing check that goes red on a threshold somebody invented is a threshold somebody invented, enforced forever — so the threshold lives outside the instrument, written down where it can be argued with.

The other half is a rule we keep relearning: a check that cannot come back negative is decorative. Before trusting any gate here we break the thing it protects and confirm it screams. That habit has caught a test suite that ran zero tests and exited zero, a quality gate that passed a deliberately blurred image, and a ramp check that sorted its input before testing whether it ascended — so it could never fail.

None of those were visible by reading the code. All of them were found by making something run and watching what it did.