4 posts tagged with "campaign"

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.

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.

Reverse engineering has a failure mode that looks nothing like a bug: code that reads exactly right and is quietly wrong. A plausible paraphrase of an instruction and the instruction itself can look identical at a glance, so the safest-looking line is often the one that never actually matched the binary. That pattern surfaced three times over today — in a harvester's movement logic, in a single audio clamp, and in the switch at the heart of the campaign scripting engine — and each time the fix was the same discipline: trust the binary over the story you'd expect it to tell.