By Over two decades later, we are still discovering new and intriguing aspects of the iconic Valve FPS, Half-Life 2. Today, we’re hearing a tale from former Valve designer Tom Forsyth regarding a game-altering glitch unearthed in 2013 that seemingly time-traveled and afflicted the original iteration of the game.
I realize that’s a lot to absorb, so let’s break down this genuinely captivating case of technical serendipity. As thoroughly elaborated on Forsyth’s Mastodon, Forsyth and Valve programmer Joe Ludwig were engaged in porting Half-Life 2 to the Oculus Rift VR headset, during which Forsyth stumbled upon a bug quite early in the game that barred him from entering a room, thus diverting him from the essential path. There was no way to progress, which was strange enough, but what rendered it odder was that no one could recall experiencing the bug in the original game. Forsyth even viewed videos of the introductory scene where he encountered the glitch, and it wasn’t present.
Clearly, the foremost priority at that moment was merely resolving the glitch before the game was set to launch on Oculus Rift, but compounding the chaos was the fact that Valve appeared to be grappling with a time-traveling error. It hadn’t existed before, yet now it did. “How could this possibly be? At this juncture people are panicking – this isn’t a typical bug – it seems to have traveled back in time and infected the original!” remarked Forsyth.
Ultimately, the developers managed to pinpoint the origin of the bug: a guard who was in the now-inaccessible room was positioned too close to the door, and his toe was colliding with the door as it opened, forcing it to swing back into a closed state. Now that the problem had been identified, the resolution was “simple” even if it “required considerable effort to uncover because people had to refresh old recollections of how the debugging tools functioned, etc.”
Yet, the enigma persisted. How in the world did this glitch from 2013 manage to infiltrate then-nine-year-old code? Furthermore, why was the soldier’s toe not obstructing the door from opening in 2004? Or in any subsequent years until the bug was uncovered?
“But why did this EVER function? The guard’s toe was obstructing the way in the original version as well. As I mentioned, we revisited the past and compiled the original shipped source code – and the bug occurred there too. It has always existed. Why didn’t the door shut again? How did this ever get released in the first place?”
Fortunately, there’s a resolution to this enthralling mystery: “good old floating point,” according to Forsyth. I’ll allow an actual game designer to elucidate this segment, but effectively, it wasn’t the game code that was flawed; it was the hardware dictating the precision of the game’s physics. By sheer coincidence, that precision allowed the door to open on hardware it was initially designed for, but not on the 2013 setup Valve utilized to test the game.
“Half-Life 2 was initially released in 2004, and while the SSE instruction set was available, it wasn’t yet widespread, so most of HL2 was compiled to utilize the older 8087 or x87 mathematics instruction set,” noted Forsyth. “That has a bizarre assortment of precisions – some elements are 32-bit, some are 64-bit, some are 80-bit, and exactly which precision you receive in which pieces of code is rather arcane.
“However, ten years later in 2013, SSE had been standard in all x86 CPUs for some time – the OS relied on it being present, so you could count on it. So naturally, by default, compilers utilize it – in fact, you must take extra steps to make them emit the old (somewhat slower) x87 code. SSE employs a far better-defined precision of either 32 or 64 bit per what the code specifies – it’s significantly more predictable.”
Well, what that 32 or 64-bit precision was requesting, apparently, was a guard’s foot that wouldn’t yield to a door impacting it. In the original x87 code, there was just the right amount of friction incorporated into the guard’s boot to allow it to pivot precisely enough for the door to pass by and open appropriately, but the newer SSE featured “a whole bunch of tiny precisions” that were “very slightly different, and a combination of the friction on the ground and the mass of the objects meant the guard still rotated from the collision, but now he rotates marginally less far.
“So on the next frame of simulation, his toe remains in the path of the door,” explained Forsyth. “The door can’t just move through his toe, so it resorts to the only other option – it rebounds.”