Greater than 20 years later, we’re nonetheless studying new and engaging particulars in regards to the legendary Valve FPS, Half-Life 2. Right this moment, we’re listening to a narrative kind former Valve designer Tom Forsyth a couple of game-breaking bug found in 2013 that seemingly time-traveled and contaminated the unique model of the sport.
I perceive that is rather a lot to soak up, so let’s unpack this genuinely entrancing case of technological happenstance. As extensively detailed on Forsyth’s Mastodon, Forsyth and Valve programmer Joe Ludwig have been engaged on porting Half-Life 2 to the Oculus Rift VR headset, and Forsyth encountered a bug very early within the sport that locked him out of a room and thus away from the essential path. There was no strategy to go ahead, which was bizarre sufficient, however what made it weirder was the truth that nobody might bear in mind encountering the bug within the authentic sport. Forsyth even watched movies of the opening scene the place he was encountering the bug, and it wasn’t there.
Clearly, essentially the most pressing concern on the time was simply getting the bug mounted earlier than the sport was to be shipped on Oculus Rift, however including to the frenzy was the truth that Valve gave the impression to be coping with a time-traveling glitch. It did not exist earlier than, and now it did. “How can this probably be? At this level individuals are freaking out – this is not a standard bug – it seems to have traveled backwards in time and contaminated the unique!” mentioned Forsyth.
Ultimately, the builders have been capable of establish the supply of the bug: a guard who was within the now inaccessible room was standing too near the door, and his toe was colliding with the door because it swung open and inflicting it to swing again right into a closed state. Now that the difficulty had been found, the repair was “straightforward” even when it “took quite a lot of work to search out as a result of folks needed to mud off outdated recollections of how the debugging instruments labored, and so forth.”
Nonetheless, the thriller lingered. How within the title of Gabe Newell did this bug from 2013 handle to search out its approach in then-nine-year-old code? And moreover, why was the soldier’s toe not stopping the door from opening in 2004? Or in any of the following years till the bug was found?
“However why did this EVER work? The guard’s toe was in the best way within the authentic model as effectively. As I say, we went again in time and compiled the unique as-shipped supply code – and the bug occurred there as effectively. It is at all times been there. Why did not the door slam closed once more? How did this ever ship within the first place?”
Effectively, fortunately, there’s a solution to this riveting thriller: “good outdated floating level,” per Forsyth. I’ll let an precise sport designer do the speaking for this half, however basically, it is not the sport code that was the issue, it was the {hardware} that was instructing the precision of the sport’s physics, and on account of pure coincidence, that precision allowed the door to swing open on {hardware} it was initially constructed for, however not on the 2013 package Valve was utilizing to check the sport.
“Half Life 2 was initially shipped in 2004, and though the SSE instruction set existed, it wasn’t but ubiquitous, so most of HL2 was compiled to make use of the older 8087 or x87 maths instruction set,” mentioned Forsyth. “That has a wacky grab-bag of precisions – some issues are 32-bit, some are 64-bit, some are 80-bit, and precisely which precision you get by which bits of code is considerably arcane.
“However ten years later in 2013, SSE had been commonplace in all x86 CPUs for some time – the OS relied on it being there, so you can depend on it. So after all by default the compilers use it – in truth it’s important to exit of your strategy to make them emit the outdated (barely slower) x87 code. SSE makes use of a way more well-defined precision of both 32 or 64 bit in keeping with what the code asks for – it is far more predictable.”
Effectively, what that 32 or 64-bit precision was asking for, apparently, was a guard’s foot that would not give strategy to a door colliding with it. Within the authentic x87 code, there was simply the correct quantity of friction constructed into the guard’s boot to permit it to pivot precisely sufficient for the door to swing previous it and open correctly, however the newer SSE had “a complete bunch of tiny precisions” that have been “very barely totally different, and a mix of the friction on the ground and the mass of the objects means the guard nonetheless rotates from the collision, however now he rotates very barely much less far.
“So on the subsequent body of simulation, his toe continues to be in the best way of the door,” mentioned Forsyth. “The door is not allowed to only move by his toe, so it does the one different possibility – it bounces again. I believe by default it is set to take action fully elastically, so the door bounces again with precisely the pace it got here in at, slams shut, and locks once more. And also you’re caught.”
Which means, amazingly, the bug had existed within the sport your entire time. The guard was at all times standing too near the door, however as a result of the compiler within the authentic construct defaulted to an older floating-point precision, the sport’s physics have been ever-so-slightly totally different to what you’d see on a more moderen compiler, and that tiny little bit of discrepancy meant the distinction between a game-crucial door opening and never opening.
“And there you could have it,” Forsyth concluded. “The 2 largest bug-farms in gamedev – doorways and floating level – contrived to make a easy NPC placement bug into fairly the time-travelling palaver.”
