One of their former developers shared an interesting anecdote about Valve’s game!
One of the coolest features of Half-Life 2 is its physics engine. However, even the best technology is prone to strange behavior. Valve’s legendary narrative shooter was no exception, as former Valve developer Tom Forsyth shared on Mastodon. Forsyth reported a bug he encountered while developing the VR version of Half-Life 2 in 2013, when Valve was deciding how to proceed with the technology. Half-Life 2 was one of the easiest games in Valve’s previous catalog to port to VR because it had been released relatively recently. However, tricks related to Portal‘s perspective naturally caused nauseating disasters. The new VR version caused players to softlock within the first few minutes of gameplay.
In the opening scene, a subway cop is supposed to escort the player through a door. For some unknown reason, the door wouldn’t open in the VR version, so the player got stuck waiting for a necessary story event that never happened. Forsyth said they couldn’t release it like that. He asked others, including some who had originally worked on Half-Life 2, but it still didn’t work, even when they weren’t in VR. No one knew why. The team soon discovered that the guard standing behind the door was standing too close—the corner of his bounding box intersected with the direction the door opened. When the door opened, it nudged the guard’s toe, bounced back, closed, and automatically locked.
They moved the NPC and fixed the bug, but it took much longer to figure out why it happened in the first place. The VR version didn’t move the NPC, and the team recompiled the original version to see if the bug was present there as well. The compiler used for testing defaulted to the newer SSE instruction set instead of the original x87 instruction set, which was the default for CPUs at the time and had highly variable precision values. Although it was old code, the new compiler caused the game to calculate physics differently, albeit extremely subtly.
In both versions, the door gains just enough momentum to turn the guard slightly. The guard’s friction with the floor is insufficient to prevent this; he turns a tiny degree. In the x87 version, this slight turn moves his toes out of the way. The collision is resolved, and the door continues to open. Everything is fine. In the SSE version, however, several tiny details are slightly different. The friction with the floor and the combined mass of the objects cause the guard to continue turning slightly after the collision. In the next frame of the simulation, his toe is still in the way of the door. The door cannot pass over his toe, so it bounces back, and we are stuck.
It’s a strange, clever bug, and a great reminder that these things are rarely as easy to solve as you might expect.
Leave a Reply