One of the coolest things about Half-Life 2 is its physics engine, but as anyone who has played a physics-based game will know, even the best-in-class tech is prone to quirks here and there. Valve’s legendary narrative shooter was no exception, as former Valve developer Tom Forsyth shared in a thread on Mastodon.
In the thread, Forsyth discusses a bug he encountered while working on a VR version of Half-Life 2, back in 2013 when Valve was considering where it wanted to go with the technology. HL2 was one of the easiest translations to VR in Valve’s back catalog—it was a relatively recent release, and the “tricks with perspective” in Portal “were of course a nauseating disaster.” The problem was, this new VR build softlocked the player mere minutes into the game.
In the opening scene, when a metro cop is meant to usher the player through a door, the door wouldn’t open in the VR build for reasons that weren’t clear, freezing the player in place to wait for a necessary story event that never comes. “Oh dear,” Tom Forsyth recalled in his thread. “We can’t ship this. I get some other folks, including some folks who worked on HL2 originally, and yep—it’s broken. And it’s broken when you’re not in VR either—so it’s not something Joe and I broke. But nobody knows why—none of the relevant code has changed.”
The team soon discovered a guard behind the door was standing “very slightly too close—the very corner of his bounding box intersects the door’s path as it opens. So what’s happening is the door starts to open, slightly nudges into the guard’s toe, bounces back, closes, and then automatically locks.” They moved the NPC and fixed the bug, but it took a much lengthier investigation to figure out why this happened in the first place; the VR build didn’t move the NPC, and the team even recompiled the original build to discover that the bug had “traveled through time” and existed in that one, too.
The thread continues with the answer: “Good old floating point.” The compiler used for these tests defaulted to the newer SSE instruction set rather than the set the original would have defaulted to for the era’s CPUs: x87, which has “a wacky grab-bag of precisions.” Even though it was old code, the new compiler meant the game was calculating physics differently, albeit to an extremely subtle extent.
Forsyth explained, “On both versions, the door has just enough momentum to rotate the guard very slightly. The guard’s friction on the floor is not quite enough to oppose this, and he rotates a tiny fraction of a degree. On the x87 version, this tiny rotation is enough to move his toe out of the way, the collision is resolved, and the door continues to swing open. All is well.
But on the SSE version, a whole bunch of tiny precisions are very slightly different, and a combination of the friction on the floor and the mass of the objects means the guard still rotates from the collision, but now he rotates very slightly less far. So on the next frame of simulation, his toe is still in the way of the door. The door isn’t allowed to just pass through his toe, so it does the only other option—it bounces back … and you’re stuck.”
It’s a bizarre head trip of a bug, and a great reminder that these things are rarely as easy to resolve as you might expect. The next time you gripe about a seesaw puzzle, just think about everything that could have gone wrong getting it to work.
Read the full article here
