What Is a Game Physics Engine?

The Core Job of a Physics Engine

At its most basic level, a physics engine maintains a world containing bodies. Each body has a position, a velocity, a mass, and a collision shape. Every simulation step, the engine applies forces (gravity, player input, explosions), detects which bodies are overlapping or about to overlap, computes the correct response (bouncing, sliding, stopping), and updates every body's position and rotation. Your rendering code then reads those updated values and draws the frame.

This loop, called the physics step, runs at a fixed rate, typically 60 times per second. The fixed rate is critical because it makes the simulation deterministic. If the physics step depended on the actual frame rate, a game running at 30 fps would simulate differently from one running at 144 fps. Players on faster hardware would jump higher and fall faster. The fixed timestep prevents that.

A physics engine does not draw anything. It operates entirely in a mathematical space with no knowledge of pixels, textures, or shaders. This separation of concerns is what makes physics engines portable. The same Rapier world can drive visuals in Three.js, Babylon.js, PixiJS, or a raw Canvas2D context. Your code is the bridge, copying positions from the physics world to the rendering scene every frame.

What Problems Does It Solve?

Without a physics engine, you would need to write collision detection for every pair of object types in your game. A circle hitting a rectangle requires different math than two rectangles overlapping, which is different again from a convex polygon hitting a tilted surface. Once you detect the collision, you need to compute the correct response: how much each object bounces, in what direction, at what speed, accounting for mass differences, friction, and restitution. And you need to handle edge cases like objects that overlap for multiple frames, objects stacked on top of each other, objects sliding along surfaces, and fast objects that pass through thin walls between frames.

For a single bouncing ball, you could manage this by hand. For two bouncing balls, it is still manageable but tedious. For a scene with 50 crates, a ragdoll character, and a floor made of angled tiles, the complexity becomes unmanageable without a structured system. Physics engines provide that structure. They have been refined over decades to handle stacking stability, constraint solving, broadphase culling, and continuous collision detection in ways that would take months to replicate from scratch.

Physics engines also handle constraints, which are rules about how two bodies relate to each other. A hinge constraint forces two bodies to share a pivot point and rotate around a single axis, like a door on its frame. A distance constraint keeps two bodies at a fixed separation, like the links of a chain. A spring constraint applies a restorative force when two bodies drift apart, like a suspension system. Without constraints, building mechanisms like vehicles, ragdolls, and swinging ropes would require custom code for each type of connection.

Rigid Body vs Soft Body vs Particle Systems

Most game physics engines focus on rigid body dynamics, meaning every object is treated as a solid shape that does not deform. When two rigid bodies collide, they bounce or slide. They never bend, squish, or tear. This simplification is what makes real-time simulation feasible. Computing the deformation of a flexible object every frame at 60 fps is orders of magnitude more expensive than computing the motion of a rigid box.

Soft body physics simulates objects that can deform, like cloth, jelly, or rubber. Some engines support soft bodies (Ammo.js inherits Bullet's soft body solver, for example), but performance is limited. Web games rarely use soft body physics in gameplay-critical systems. When you see cloth or rope effects in browser games, they are usually simulated with simplified particle chains or procedural animation, not a full soft body solver.

Particle systems simulate large numbers of small, independent objects like rain, sparks, debris, or smoke. While particle systems involve some physics (gravity, wind, velocity), they typically do not use a physics engine. Each particle is too simple and too numerous for the overhead of full rigid body tracking. Instead, particles are updated with simple Euler integration in a custom loop, and collisions, if handled at all, use simple floor or boundary checks rather than full pair testing.

Body Types: Dynamic, Kinematic, and Static

Physics engines categorize bodies into three types based on how they move. Understanding these categories is fundamental to setting up any physics scene correctly.

Dynamic bodies are fully simulated. Gravity pulls them down. Other bodies push them. Forces and impulses from gameplay code accelerate them. A crate that falls from a shelf, a ball the player kicks, and a ragdoll that collapses on death are all dynamic bodies. They have mass, velocity, and respond to every interaction.

Static bodies never move. They represent immovable scenery: the ground, walls, platforms, and terrain. The engine does not apply gravity or forces to static bodies and does not compute their velocity. However, dynamic bodies can collide with them. A floor is a static body. A wall is a static body. Setting a body to static tells the engine to skip all force calculations for it, which improves performance significantly for large environments.

Kinematic bodies move, but only when your code tells them to. The engine does not apply gravity or collision forces to kinematic bodies. Instead, you set their position or velocity directly each frame. The critical difference from static bodies is that kinematic bodies do push dynamic bodies out of the way when they move. A moving platform, an elevator, and a sliding door are kinematic bodies. They follow scripted paths and shove anything in their way, but nothing can push them off course.

A common mistake is making everything dynamic. If a wall is dynamic instead of static, the engine wastes CPU time computing forces on an object that should never move, and a heavy enough collision could push the wall. If a moving platform is dynamic instead of kinematic, it will fall under gravity and get knocked aside by the player. Choosing the right body type for each object is one of the first steps in setting up a physics scene.

Collision Shapes Are Not Visual Meshes

Physics engines do not test collisions against your visual geometry. A character model might have 5,000 polygons, but testing 5,000 polygons against every other object every frame is far too expensive. Instead, you assign each body a collision shape, a simplified geometric primitive that approximates the visual shape.

Common collision shapes include spheres (the fastest to test, one distance check), boxes (fast axis-aligned checks), capsules (ideal for humanoid characters, essentially a cylinder with rounded ends), convex hulls (the tightest-fitting convex approximation of a mesh, more expensive), and triangle meshes (exact shape matching, only viable for static geometry because of the cost). Compound shapes combine multiple primitives, like a box for the torso and a sphere for the head, to approximate complex objects without the cost of a convex hull.

The gap between the collision shape and the visual mesh is normal and expected. Players rarely notice that their character's collision capsule clips through doorframe geometry by a few pixels, because the gameplay feel matters more than geometric precision. Tight, responsive collision shapes make games feel good even if they do not match the visual model exactly.

Physics Engines Available for the Web

The web has several mature physics engines. Rapier is written in Rust and compiled to WebAssembly, offering the best raw performance for both 2D and 3D simulation. Cannon-es is a pure JavaScript 3D engine with a clean API and strong Three.js integration. Havok is an industry-standard engine available as a free WASM module built into Babylon.js. Matter.js and Planck.js cover 2D physics for platformers and puzzle games. Ammo.js ports the Bullet engine to WASM for broad feature coverage at the cost of a complex API.

Choosing between them depends on your renderer, your performance requirements, and how many bodies you expect to simulate simultaneously. The best physics engine comparison breaks down these tradeoffs in detail, and the engine vs hand-rolled article helps you decide whether you need an engine at all.