The Door That Lied to You

You kick open a door in a shooter. It swings hard, bounces off the wall, settles with a satisfying thud. Then you walk into an RPG dungeon and shove a door that barely reacts, sliding open on an invisible rail like a PowerPoint transition. Both games, same release window, both with massive budgets. Why does one door feel like physics and the other feel like theatre?

Because the engine made a deliberate trade.

Almost every door in almost every game is lying to you about what's actually being calculated.

The Budget You Can't See

Every frame of a game is a race against a clock. At 60 frames per second, the engine has roughly 16 milliseconds to simulate the world, run AI, stream assets, and push pixels to your screen. Physics is expensive. A single fully-simulated rigid body, an object with real mass, inertia tensors, angular momentum, and collision response, can cost several times more CPU time than a scripted animation.

So engines use a tiered system. Call it the physics budget. Objects get assigned to different tiers based on how much they'll contribute to the player's experience versus how much they'll drain the frame.

A door the player opens once and never sees again sits at the bottom. A door that swings into enemies, blocks gunfire, and can be blown off its hinges sits near the top.

Three Tiers, One Hinged Plank

Most engines work across three rough categories, even if they don't label them this way.

Scripted animation. The door is a prop. It plays a pre-baked animation when triggered, ignores all forces, and teleports between states. Half the doors in open-world games are this. Cheap, predictable, zero simulation cost. The downside: throw a grenade next to one and it won't react. It just plays its "open" clip.

Constrained rigid body. This is the middle tier and the most interesting one. The door exists as a real physics object but is attached to the world by a hinge constraint, a mathematical rule that says "this object can only rotate around this axis." Engines like Unreal and Unity have shipped this as a default door setup for years. The door has real mass and responds to forces, but the constraint limits the degrees of freedom from six to one. Computationally, that's the difference between solving a six-variable equation and solving one with a single unknown. Far cheaper.

Full simulation. Reserved for moments the game is built around. A door in a physics puzzle game. The vault door in a heist sequence. An object the player will spend real time manipulating. Here the engine simulates the full rigid body, often with continuous collision detection (which checks for tunneling, where a fast-moving object passes through geometry without registering a hit) and sometimes with soft-body deformation layered on top. This can eat two to four milliseconds of your frame budget on its own.

How the Engine Actually Decides

The decision isn't always made by the physics engine. It's made by the game designer, the level of detail system, and sometimes the engine's own sleep system working together.

Here's a concrete scenario. A level designer places 40 doors in a dungeon. Twenty are decorative, lining corridors the player sprints through. Fifteen are interactive but sit in rooms where enemies don't patrol. Five are in the boss arena, where the design calls for doors to be blown off walls and used as cover.

The designer tags those five as dynamic physics objects and the rest as animated props. The LOD system then adds another layer: even the constrained rigid bodies get put to sleep when the player is more than 30 meters away. A sleeping physics object costs almost nothing to maintain. When the player gets close, the engine wakes it up, re-registers its collision mesh, and starts simulating again. This is why you sometimes see a door in the distance that doesn't react to an explosion, then suddenly starts swinging when you walk toward it.

Id Software's work on Doom Eternal is a useful case study. The game uses a tiered approach to geometry interaction: props close to the player get full physics attention, while background destruction uses pre-authored animations triggered by proximity or damage events. The player rarely notices because the high-fidelity simulation is always happening right where their eyes are.

What People Consistently Misread

The common assumption is that better-looking games have better physics. Not true, and it's worth being direct about that. Visual fidelity and physics fidelity are almost entirely separate budgets. A photorealistic environment can be stuffed with scripted-animation doors because the GPU budget went to rendering and the CPU budget went to AI.

Meanwhile, a stylised indie game built around physics puzzles can have the most accurate door simulation on the platform, because that's the entire point of the thing.

People also assume ragdoll bodies and cloth simulation are harder than door physics. Usually the opposite. Ragdolls are constrained rigid body chains, often with forgiving collision requirements because they're flying through the air and nobody is scrutinising them closely. A door that the player presses against, opens slowly while crouching, and holds ajar to peek through has to be accurate under sustained, deliberate interaction. That's a harder problem. It's like the difference between a stunt performer falling off a building and a surgeon making a precise incision: the fall looks more dramatic, but the knife requires the steadier hand.

Almost nobody realises the hinge constraint itself is doing the heavy lifting. Without it, a door would need to be a fully free rigid body, and keeping it attached to the wall would require the engine to resolve constraint forces every frame to stop it drifting. The constraint bakes that resolution in mathematically. It's the reason your door doesn't slowly detach from its frame over the course of a session.

The Sleep Problem and Why Doors Sometimes Freak Out

You've seen this. A door is sitting closed. You walk into a room, and it suddenly vibrates, swings open slightly, then snaps back.

That's a wake-up glitch.

When the physics engine puts an object to sleep, it freezes its state: position, rotation, velocity all zeroed out. When it wakes the object, it re-initialises those values from stored data. If the world has shifted slightly since the object went to sleep, maybe another object is now overlapping it by a fraction of a millimetre, the engine detects a collision on the first frame of wakeup and applies a corrective impulse. The door twitches.

The fix is usually a combination of a larger sleep threshold and a penetration tolerance (overlaps below a certain size get ignored). Valve's Source engine used explicit penetration tolerance values that level designers could tune per-object. Get the tolerance wrong on a door and you'd ship a vibrating door bug.

Ask yourself: how often have you assumed that was a glitch in the art, not the physics? It's almost always the physics.

This is also why physics engines are notoriously hard to make deterministic. Two players in the same session, on different machines, can have the same door wake up at microscopically different times and produce divergent states. Multiplayer games typically solve this by running door physics only on the server and syncing results, or by using scripted animations exclusively for doors in networked environments.

The Honest Takeaway

Every time a door feels good in a game, someone made a deliberate, constrained choice about how much reality to fake. The door that felt real probably wasn't fully simulated. It was a constrained rigid body with a tuned hinge, a hand-picked mass value, and an angular damping coefficient that a physics programmer tweaked until it stopped feeling like a barn gate in zero gravity.

The craft isn't in simulating more. It's in knowing exactly how little simulation you can get away with before the player's brain stops buying it. That's not a shortcut. That's the whole skill.