A Classic Game Meets New Tech
Half Life 2 is famous for its story, characters, and especially its physics. Throwing objects around with the gravity gun or watching things topple over in realistic ways was mind blowing when the game launched. But even legendary games have strange bugs hiding under the surface, and sometimes they only show up years later.
Former Valve developer Tom Forsyth recently shared a great story about one of these bugs while talking about an old virtual reality experiment. Back in 2013, Valve was playing with the idea of putting Half Life 2 into VR. Out of all its old games, Half Life 2 was actually one of the easiest to bring over, at least on paper. It was modern enough, and unlike Portal it did not rely on weird camera tricks that would feel awful in a headset.
But right near the start of the game, the VR version completely broke. Not a crash, not a funny glitch, but a hard stop. You could not continue the story at all.
In the opening train station scene, a metro cop is supposed to guide you through a door. Anyone who has played Half Life 2 remembers this quiet but tense intro. In the VR build though, the door simply refused to open. The cop would stand there, the script would hang, and the player was stuck forever waiting for something that never happened.
The weird part was that this did not just happen in VR. When Forsyth and the team tested the same build without VR, it still broke the game. The original Half Life 2 code had not been touched in any relevant way. Yet now one of the first story moments in the game no longer worked. No one could immediately explain why.
When One Guard’s Toe Breaks the Game
After some digging, the team finally found the immediate cause. Behind that stubborn door, a guard NPC was standing just a little too close. Not obviously clipping through or anything dramatic. Instead, the edge of his invisible collision box was just barely in the way of the door’s path.
Here is what the physics engine thought was happening:
- The door starts to open like normal.
- It nudges into the guard’s foot. That tiny overlap counts as a collision.
- The door reacts to the collision and bounces back.
- When it bounces back, the script causes the door to automatically lock.
The result: the story event never fully triggers. The door never opens. The player is trapped.
In theory this is an easy fix. The team moved the NPC a little farther away and the door started working again. So that should be the end of it, right? Not quite.
They wanted to know why this bug had suddenly appeared after all these years. The old released version of Half Life 2 never had this problem. So they tried recompiling the original game code with their current tools to see what changed. Strangely, the bug appeared there too. It was like the glitch had traveled back in time and infected the past version as well.
Nothing in the game logic had changed. The level scripting was the same. The door and guard data were the same. So why did the guard’s toe suddenly become fatal to the script?
The Power of Tiny Numbers
The answer came down to something most players never think about: floating point math. Under the hood, game physics is just a massive pile of equations being solved many times every second. Those calculations use floating point numbers, which are how computers store decimal values like 0.1 or 3.14159.
Here is where it gets tricky. Different generations of processors and compilers handle those decimals in slightly different ways. When Half Life 2 originally shipped, it used the x87 instruction set. That system has odd and inconsistent rules for precision. Years later, when Forsyth recompiled the game, the compiler defaulted to a newer set of instructions called SSE. SSE is more modern and consistent, but it handles those tiny decimal details a bit differently.
Normally, those microscopic differences do not matter. But physics engines are chaotic. A tiny change in one number can have a visible impact several frames later.
Forsyth broke it down like this:
- On both versions, when the door hits the guard, it pushes on him a little.
- That push gives the guard a tiny rotational nudge. He starts to rotate a fraction of a degree.
- The floor has friction, which tries to stop that motion. The guard also has mass, which affects how he moves.
In the original x87 build, this tiny rotation is just enough to move the guard’s toe barely out of the door’s path. The collision is resolved, the door keeps swinging, and the player walks through like normal.
In the recompiled SSE build, the same calculations come out ever so slightly different. The guard still rotates, but just a little less. That means, on the next frame of the simulation, the toe is still touching the door’s path. The physics engine will not let the door pass through a solid object, so it chooses the other valid option: it bounces the door back and locks it.
The bug was not a simple scripting error. It was the result of tiny numerical differences deep inside the CPU’s math instructions, cascading into a completely different player experience.
It is a perfect example of how fragile game systems can be behind the scenes. Changing hardware, compilers, or even small optimizations can wake up bugs that were always there waiting, just never quite triggered.
So the next time you solve a seesaw puzzle, struggle with a moving platform, or laugh at a ragdoll flying across the map, remember stories like this one. Underneath your game, a swarm of invisible numbers is fighting to agree on where every toe, door, and crate belongs. Sometimes, all it takes to break a classic is one guard standing a little too close to a door.
Original article and image: https://www.pcgamer.com/games/fps/a-former-valve-dev-revealed-how-while-a-vr-version-of-half-life-2-was-being-made-a-single-metro-cops-toe-created-a-time-travelling-bug-that-softlocked-all-versions-of-the-game/
