Physics Engines
Simulating the real world
Physics engines became a separable component of games between Trespasser's muscle-driven dinosaurs in 1997 and the physics-card pitch of 2005, with MathEngine and Havok licensing the first realtime engines at the end of the 1990s and racing games as the first customers.
A physics engine is the part of a game that works out how objects move, collide and come to rest. Games always had some of this — a ball bouncing off a bat is physics — but the term arrived when the simulation became a separable component: first a showpiece written for one game, then, from the end of the 1990s, a licensed library that any studio could buy. The period sources held here run from Trespasser’s ambition in 1997 to the physics-card pitch of 2005.
Fast facts
- The showpiece: Trespasser: Jurassic Park (DreamWorks Interactive, 1998), whose dinosaurs were skeletons and “artificial muscle connections” driven by “authentic physical principles” — and whose engine “screws up gameplay” in CGW’s review.
- The vendors: MathEngine and Havok, which “launched their realtime physics engines at the end of the 1990s”; by 2005 also Criterion (RenderWare Physics, built on MathEngine’s Karma), Novodex/Ageia, Meqon, Oxford Dynamics, and the free ODE, Newton and Tokamak.
- The first customers: racing games, because “the vehicle dynamics are a core part of the gameplay”.
- The recurring promise: “2005 is going to be the year of physics. Of course, they have said this every year since… the end of the 1990s.”
Trespasser
Computer Gaming World’s March 1997 cover story introduced Trespasser as Spielberg’s “digital sequel to The Lost World”, built by Seamus Blackley’s team at DreamWorks Interactive. The dinosaurs were not animated in the usual way: Blackley “developed skeletal models for each of the dinosaurs… Then, he connected the skeletons with artificial muscle connections. Each portion of the skeleton and musculature is assigned weight, strength, durability, etc.” Everything in the world was to be an object that “acts and can be used realistically”.
The game shipped in late 1998, and CGW’s January 1999 review found “a technically promising engine that screws up gameplay”. The physics “is commendable in creating an environment full of objects to be pushed and picked up (but not destroyed)”, but the puzzles were box-stacking and “boxes fall every time you breathe on them”; the engine “is also slow”, tanking the frame rate on a Pentium II 300; and “collision detection is a joke, letting your character get snagged on walls and in bridges, and letting dinosaurs get tangled in fences until they die.” The same issue of Edge carried Scott Miller’s verdict: “realistic physics do not always mean better gameplay. Trespasser is a perfect example of this.”
The 1999 survey
Edge 67 went through the genres asking the programmers. Richard Ogden’s car model for TOCA 2 was “in its third iteration” after TOCA and Colin McRae Rally, and “accurate as far as it goes but… actually very simple when compared to the kind of calculations that would be done by, say, engineers”. He expected graphics chips to take over transform and lighting and leave “more CPU resources free to handle the physics” — tyres “deforming and wearing out, temperature changing”.
Mark Cale of System 3 described motion capture as “pre-stored physics, not true real-world physics”, and thought good physics “represents the future in every genre of realtime 3D games”. Jez San of Argonaut explained why platform games wanted an engine: they “have had to have special case code written to handle each possible interaction that the player may want to have with each object in the game world”. Phil Drinkwater of Silicon Dreams was blunter about sport: “the physics aspect of sports games is in its infancy”, and driving players by “the forces applied to muscles and gravity on the joints” was “too complicated at the moment”, so studios would use inverse kinematics instead. Edge itself expected “the next great leap forwards in game programming being made in this area soon”.
The middleware
That leap came as licensed code rather than in-house heroics. Edge’s 2003 assessment was that physics middleware “made its initial impact not by providing developers with a set of new features but because it offered existing features cheaper and faster”, and that its first customers were “realistic genres such as vehicle-based racers”, where the dynamics were already the game. Havok’s Steve Collins admitted the first attempt at any engine tends to be “too processor expensive”. Havok and MathEngine’s Karma were the two names of that first wave; Karma passed to Criterion in 2003 and became RenderWare Physics, and Karma’s designer Russell Smith went on to write the open-source ODE.
By GDC 2005 Edge could print a vendor panel of eight, and the story had moved from engines to hardware. Ageia, which had bought the Swiss firm Novodex in 2003, was pitching the PhysX chip: “The limit of physically modelled bodies for current games is anything from 30 to 100. With PhysX, we can do over 30,000.” Epic’s Mark Rein had “600 boulders” rolling down a hill in an Unreal Engine 3 demo and wanted thousands. The catch, as Edge noted, was that early games could not assume the chip existed, so it was “limited to… cosmetic physics: cloth, fluid or hair simulations that don’t affect how a game plays”. Meanwhile Half-Life 2 had shown physics as a gameplay mechanic without any special hardware at all — see ragdoll physics for the character side of the story.