7 posts tagged with "verification"

Deep in Tiberian Sun's executable there is a helper that converts a floating-point number to an integer. Every game does this thousands of times a second. This one begins by loading a specific x87 control word — the register that tells the floating-point unit how to round — and then it never puts the old one back.

That is not a bug you would ever notice. The control word it loads says round toward zero, and a function whose entire job is truncation wants exactly that. The helper works perfectly. It just leaves the machine in that state afterwards, forever, for every other calculation the game does.

We spent two sessions finding out how much that costs.

Somewhere in Tiberian Sun's executable there is a function that does exactly what you'd want it to do if you were trying to find out whether the Firestorm expansion is installed. It checks for one of Firestorm's files, and it hands back yes or no. It has the shape of an answer.

Nothing in an unmodified game ever calls it.

That turned out to be the shape of practically everything this week. A campaign's win screen quietly picks between three endings depending on the order two flags get checked, not the order you'd guess. A weather event's own settings ship almost entirely switched off in the retail data — present, but functionally dormant. Code built for one purpose gets recompiled, unrenamed, into a completely different one. A tracking script we wrote ourselves was quietly hiding more than half of our own finished work from the backlog it reported. That Firestorm-detection question really does have an answer — just not the one the perfectly-named function seemed to promise. A wall we'd already reverse-engineered down to a tidy, four-function port contract turned out to have a second, undocumented way of killing you. A tool we were about to build, to read the game's sealed data archives, had already been finished months ago and forgotten. And a burrowing-unit mechanic that everyone including us assumed was Tiberian Sun's alone is sitting fully alive in both sequels, which simply never shipped a unit that uses it.

One thread runs under all of it: the plausible-looking thing — a name, a flag, a summary, a task description, our own inventory of our own work — is not always the thing actually running, and the only way to tell is to read the raw instructions instead of the label.

A lot of what a twenty-five-year-old game "does" lives in community memory as much as in the executable — house rules, remembered quirks, features everyone is sure were mods. Spend a day reading the binary of that game and a pattern emerges: the engine already knew. The rule you half-remember is there, usually more precise and stranger than the memory of it. Today was seven passes over the selection, command, alliance, AI, spectator, and campaign-scripting layers, and the throughline was the same each time — the machinery was already present, and our job was to state exactly what it does rather than what we assumed.

Every real-time strategy game is secretly a metronome. Thirty times a second the engine reads your inputs, advances the world one tick, and draws what happened. This week we finished dissecting that heartbeat across all three games we track — Tiberian Sun, Red Alert 2, and Yuri's Revenge — and then went one level deeper, into the bodies of the subsystems the tick calls, all the way down to the layer where the computer players decide what to build. Along the way the engine handed us a genuinely strange discovery: one virtual call that takes its arguments two different ways depending on which game you're playing.

Last time, the original engine gave us a second opinion: we ran small pieces of its actual code in a sandboxed emulator and compared answers. That was the engine as a witness. Today it became something more — a car we can drive. Code of ours now runs inside the live game, steps its simulation forward frame by frame on command, reads its state between steps, and hands us ground truth no amount of careful reading can match. It promptly caught two real mistakes that every static check had blessed.

For months, every number in this project has been checked the same way: a person reads the original engine's instructions, works out by hand what they must produce, and writes that value into a test. It's rigorous — but it's one person's arithmetic standing in for the CPU. The weak point was always the derivation: a subtle misreading can hide in a test for a long time, because the test and the reading share the same author and the same blind spot. Today the project got three ways to have that reading checked by something that doesn't share the author.

The first end-to-end piece of reTS was not a menu or a moving unit. It was a number: the exact amount of health removed when one object hits another.

That sounds modest. It turned out to be the right foundation for the whole project, because the original engine does not calculate damage in one neat formula. It passes the value through a sequence of rules, and the integer result can change if even two apparently equivalent stages are swapped.