Before simulation
The earliest game physics were scripted. An enemy who was shot played a death animation from a fixed set: a falling animation, a crumpling animation, a spinning animation. The animation was the same each time regardless of the direction of the shot, the position of the character, or the game environment's specific geometry. The "physics" were not simulation but lookup: a trigger event (death) played a pre-determined response (animation). Players understood this as convention — the game's representation of death — without expecting that the representation should be physically accurate.
Quake (1996) moved enemy death responses closer to simulation with its gibs system: enemies who took sufficient damage were destroyed, producing distributed body fragments that were small enough to behave as simple physics objects with velocity determined by the direction and magnitude of the attack. The gib system was crude by later standards — the fragments were simple objects with simple collision — but it was an early example of procedural physics response rather than scripted animation: the outcome depended on the specific attack conditions rather than on a predetermined animation. Players who shot enemies from different directions produced different fragment distributions, which was a form of physical realism that scripted animation couldn't achieve.
Ragdoll and Havok
Ragdoll physics — simulating a character's body as a set of linked rigid bodies with joint constraints, rather than playing a predetermined death animation — appeared in commercial games around 1998 with Burial at Sea and became standard in PC games by the early 2000s. A ragdoll character who died fell in a way determined by the physics simulation at the moment of death: the character's velocity, the direction of the killing blow, the geometry of the environment where the body fell. No two ragdoll deaths were identical, and the physical plausibility of the result — bodies that folded at joints in anatomically reasonable ways, that fell against surfaces with appropriate weight — created a visual realism that scripted animations couldn't match.
The Havok physics engine, developed by Irish company Havok Ltd and first commercially available in 2000, became the industry-standard middleware for rigid body simulation in games. Havok provided the collision detection, constraint solving, and rigid body simulation that game developers needed to implement ragdoll physics, destructible environments, and physics-based puzzles without writing the simulation code themselves. By 2005, Havok was licensed to studios including Valve, Bungie, and Electronic Arts, and was used in games across multiple genres and platforms. The middleware approach — paying for access to simulation code rather than writing it internally — was the physics equivalent of the engine licensing that had changed game development economics in the previous decade.
Half-Life 2 and physics as design
Half-Life 2 (2004) was the game that demonstrated that physics simulation could be a design tool rather than a visual enhancement. The Gravity Gun — a weapon that picked up, held, and launched physics objects with the player's aim — was the clearest statement of this: a weapon whose entire functionality was the physics simulation, that would have been meaningless without the physical properties of the objects it manipulated. Levels designed around the Gravity Gun required players to understand and exploit the physics system: using a concrete block to shield from gunfire, launching a circular saw blade to clear a path through enemies, manipulating objects to reach otherwise inaccessible areas. The physics was the puzzle mechanic, not the visual feature.
The engine that Half-Life 2 ran on — Source, Valve's successor to GoldSrc — was licensed to other developers and became the foundation for games that used its physics in similar design-central ways. Portal (2007), running on the Source engine, built its entire design around the physical implications of the portal mechanic: the persistence of momentum through portals, the visual paradox of seeing through space, the puzzle logic that emerged from combining portals with the game's physics simulation. Portal's critical reception — one of the most uniformly praised games of its era — was partly a reception of the puzzle design and partly a reception of the realisation that physics simulation, applied with design intent, could produce an entirely new category of spatial reasoning puzzle.
Physics as expectation
By 2010, players expected physical plausibility from games in ways that would have been unrealistic expectations in 2000. Destructible environments — buildings that collapsed under fire, walls that broke when vehicles crashed into them — were marketed features in games including Red Faction: Guerrilla (2009) and the Battlefield series. Water simulation, cloth simulation, and fire propagation became visual markers of production quality. The absence of physical simulation in areas where players expected it — characters who walked through objects rather than colliding with them, bodies that disappeared immediately rather than remaining in the environment — was noticed as a quality deficit rather than as a convention.
The establishment of physics as an expectation created a specific design problem: simulation that was accurate but not fun. A physically accurate simulation of a human body falling down stairs would produce a result that was graphically unpleasant and mechanically frustrating if it affected gameplay. The games that handled physics design best were those that calibrated their simulation to produce physically plausible results within the range of player expectations — plausible enough to feel real, artificial enough to remain enjoyable — and that designed their play around the simulation's actual behaviour rather than around what the simulation was supposed to do. The ongoing design challenge of physics games is the tension between simulation fidelity and playability, which are not always aligned, and which requires the same calibration that every game mechanic requires: not accuracy to the real world but accuracy to the player's expectations of the game's world.