A physics engine is the software component that simulates physical behavior in a game: gravity, velocity, collisions, friction, joints and sometimes cloth, fluids or destruction. Within game engines, it runs alongside the rendering pipeline and gameplay code, advancing the simulated world in small time steps so objects fall, bounce, slide and stack in a way players accept as plausible.
Game physics aims for believable and stable results at interactive speed, not scientific accuracy. A simulation that is slightly wrong but never explodes or jitters is preferable to one that is precise but unpredictable, because players notice instability far more readily than small errors in momentum.
How a physics engine runs each step
A physics engine advances the world in a repeating simulation step, usually at a fixed rate such as 50 or 60 steps per second and independent of the rendering frame rate. Each step follows the same broad pipeline, and the order matters for stability.
| Stage | What happens | Main cost driver |
|---|---|---|
| Force integration | Applies gravity and forces to update velocities | Number of moving bodies |
| Broad phase | Finds pairs of objects that might touch | Object count and spatial layout |
| Narrow phase | Computes exact contacts between candidate pairs | Shape complexity |
| Constraint solving | Resolves contacts, friction and joints | Contacts, joints and iterations |
| Position integration | Moves bodies to their new positions | Number of moving bodies |
| Sleeping and events | Deactivates resting bodies, reports collisions | Gameplay callbacks |
The broad phase uses spatial structures such as bounding volume hierarchies or sweep and prune to avoid testing every object against every other object. The narrow phase relies on algorithms such as GJK and the separating axis test for convex shapes. Most engines then use an iterative constraint solver that refines contact forces over a limited number of passes, trading precision for predictable cost.
Bodies, shapes and constraints
The simulated world is built from bodies with collision shapes. Choosing the right body type and shape for each object is the most important performance decision a developer makes.
| Body type | Behavior | Typical use |
|---|---|---|
| Static body | Never moves, has infinite mass | Floors, walls, terrain |
| Dynamic body | Moves under forces and collisions | Crates, barrels, debris |
| Kinematic body | Moved by code, pushes dynamic bodies | Moving platforms, doors, elevators |
| Trigger volume | Detects overlap without a physical response | Checkpoints, damage zones |
| Character controller | Specialized capsule with custom movement | Player and NPC movement |
Collision shapes range from spheres, capsules and boxes, which are cheapest, to convex hulls and triangle meshes, which are expensive. Visual meshes are rarely used directly: a detailed statue may render with thousands of triangles but collide as a few simple primitives. Constraints such as hinges, sliders and ball joints connect bodies to build doors, vehicles and ragdolls.
Common physics engines and their integration
Most developers use the physics system that ships with their engine rather than writing their own. The table lists widely used options as they relate to the major game engines.
| Physics engine | Typical home | Notes |
|---|---|---|
| Chaos Physics | Unreal Engine | Rigid bodies, destruction, cloth and vehicles |
| PhysX | Unity 3D physics and many proprietary engines | Mature rigid body engine, open source |
| Havok Physics | Licensed by many large studios | Commercial, known for stability at scale |
| Jolt Physics | Several engines including Godot options | Open source, multithreaded design |
| Box2D | 2D games and Unity 2D physics | Lightweight engine for two-dimensional worlds |
| Bullet | Tools, research and some games | Open source, also used outside games |
Integration matters as much as the library. The engine must synchronize physics with the game loop, interpolate rendered positions between physics steps and expose collision events to gameplay code. In an entity component system, physics data is usually stored in components processed in large batches for better cache efficiency.
Time steps, stability and determinism
A fixed time step is the standard practice because simulation behavior depends on the step size. If the step varied with frame rate, a jump might reach different heights on fast and slow computers. The engine runs as many fixed steps as needed to catch up with real time and interpolates rendered positions for smooth visuals.
- Tunneling happens when a fast object passes through a thin wall between two steps; continuous collision detection prevents it at extra cost.
- Jitter in stacks results from too few solver iterations or very different masses touching each other.
- Spiral of death occurs when physics takes longer than real time, so the engine falls further behind each frame; a cap on steps per frame avoids it.
- Non-determinism across machines arises from floating-point differences and thread ordering, which complicates lockstep multiplayer and replays.
For networked games, physics is usually simulated authoritatively on the server, with clients predicting locally and correcting when server results arrive. Fully deterministic physics is possible but requires careful control of math libraries and execution order.
Physics beyond rigid bodies
Rigid bodies cover most needs, but games increasingly simulate deformable and fluid materials. These systems are often separate from the main solver and frequently run on the GPU.
- Cloth simulation moves capes, flags and clothing using particles linked by constraints.
- Destruction fractures meshes into pieces that become new dynamic bodies.
- Ragdolls replace animation with jointed bodies when a character falls or is hit.
- Vehicle physics models suspension, tire friction and drivetrain, often with specialized solvers.
- Fluids and particles add water, smoke and debris, frequently as visual effects only.
Many of these effects are cosmetic: they affect only visuals and are not synchronized in multiplayer. Gameplay-relevant physics is kept simple and authoritative, while expensive visual physics can be scaled down on weaker hardware without changing the game’s rules.
Understanding it simply
A physics engine is the part of a game that knows how things should move. It makes a ball fall, a door swing and a pile of boxes topple when a car hits it.
Many times every second it asks the same questions. Where is each object going? Has anything collided? What happens next? It does not need perfect science. It only needs to look right and stay stable, so players believe the world on screen.
Applied in practice
A small team building a warehouse level for an action game notices that the frame rate drops sharply when the player knocks over a stack of about three hundred crates. Profiling shows that narrow-phase collision tests dominate, because each crate uses its detailed visual mesh as a collision shape.
The team replaces the meshes with simple box colliders, enables sleeping so resting crates stop being simulated, and keeps the physics step at a fixed 60 Hz. They also turn on continuous collision detection only for thrown objects, which had been passing through thin shelves.
Physics time per frame falls from a level that caused visible stutter to a small fraction of the frame budget. The outcome is that the same scene runs smoothly and the crates still tumble convincingly when the player crashes through them.