Nobody was killing the escape order

For about a week I have been looking for a killer. The getaway car gets an order to run, the order ends early, the car stops, and our telemetry prints that the order died. So I went hunting for whatever was cancelling it: a decorator (one of the conditions the game’s AI wraps around its behaviours), another system, some piece of the game’s own AI reaching in. I ruled out four suspects by measuring them and started writing the hook that would let me ask the engine directly which system had done it.

Then I dumped a whole session instead, six hundred and seven lines, and the question fell apart. The engine has seven different ways an order can end, and our log line printed all of them the same way. Across that session: four failures, four successes, two interruptions. Only the last two are anybody cancelling anything. The interesting ones are the successes, and nobody was looking at them, because a success does not sound like a bug.

They come in pairs, one or two seconds after the order is issued. An order to drive away that reports itself complete two seconds later can mean only one thing: the destination was practically where the car was already standing. The command lands, the engine ticks it off, and the car is left with no orders at all, so it stops. That is not a mystery any more. It is the symptom the player has been describing for a week: the car that will not accelerate.

The other half is why nothing gives him a new order. There is a refresh that is supposed to hand him a fresh destination every four seconds, and it only fires on a geometry condition: the player has to be in front of the car, inside a cone of about seventy degrees off the bonnet. Chasing someone means being behind them. Over five minutes of pursuit that refresh had roughly seventy-five chances to hand out a new order and used five, none of them after the car got stuck on a bridge. The player’s own workaround proves it from the other side: he drives around in front of the car, the angle crosses the threshold, and it takes off again.

The part I like least is that a comment in my own code predicted this exactly. It sits in the file as the risk of a change I had decided not to make: in a tail chase the player is behind, so this returns false and nothing gets refreshed, with no log and no symptom until somebody notices the car will not accelerate. I had filed a hazard as future work while it was already happening every night, on the path that runs almost all the time.

The cheap lesson is about naming. Our log said the order died, for a state that means it succeeded, and that one word sent a week of work after the wrong question. A log that names things has to name them accurately, or it is worse than no log at all: it is confidently wrong, and you believe it.

None of this gets fixed this week. The chase is frozen by decision: how the car behaves is a design call, and not one I get to make on my own while it is frozen. So what came out of the session is the measurement, written down, and the pursuit left exactly as it was.