How Video Game Physics Engines Work: Simulating Motion

Every box that tumbles down a staircase, every ball that bounces off a wall, and every character that ragdolls across a battlefield is governed by the same piece of software: a physics engine. In a single frame running at 60 frames per second, a physics engine executes thousands of calculations to move objects, resolve collisions, and keep the simulation physically plausible. Yet it does so without simulating actual physics — instead, it uses mathematical shortcuts that feel correct while running fast enough to maintain real-time performance. Understanding how physics engines work reveals both the elegance of their design and the surprising reasons behind common physics bugs like objects tunneling through walls or characters jittering against surfaces.

What physics engines actually simulate

Physics engine — software that calculates object motion, detects collisions, and applies forces to create the illusion of physical realism without full accuracy.

At their core, game physics engines solve a single problem: given the current state of the world (where objects are, how fast they're moving, what forces act on them), what will the world look like in the next frame? In a 60 fps game, "the next frame" is 16.67 milliseconds away. In 120 fps, it's 8.33 milliseconds. The engine has this tiny window to compute all collisions and motion before the next frame must render.

To accomplish this in such a tight timeframe, engines use Newton's second law as their foundation: F = ma, or force equals mass times acceleration. From this, they derive velocity (acceleration integrated over time) and position (velocity integrated over time). A physics engine is fundamentally a machine for performing these integrations thousands of times per second across hundreds of objects.

But it does not solve the full laws of physics. Actual physics would require solving differential equations with extraordinary precision, accounting for air resistance, friction at molecular scales, and countless other variables. Instead, game physics engines make deliberate simplifications — treating objects as rigid, ignoring friction coefficients that vary with temperature, using fast-but-inaccurate integration methods. The goal is not accuracy; it's plausibility at speed.

Rigid body dynamics: treating objects as inflexible solids

Rigid body — an object that cannot deform; it maintains its shape and internal distances between all points no matter what forces act on it.

The vast majority of game physics is rigid body dynamics — the simulation of solid, non-deforming objects like boxes, barrels, vehicles, and characters. Each rigid body has a few key properties:

• Mass: How much the object resists acceleration. A heavier object requires more force to move.
• Position: Where in 3D space the object is located (usually at its center of mass).
• Linear velocity: How fast the object is moving in space (meters per second).
• Orientation: The object's rotation (stored as a quaternion or rotation matrix).
• Angular velocity: How fast the object is spinning (radians per second).
• Shape: A simplified collision shape — often a box, sphere, or convex hull, not the detailed visual mesh.

At each physics frame, the engine updates velocity and position using the current forces. If a bullet impacts a box, the physics engine applies an impulse (a sudden change in velocity) based on the bullet's momentum. If gravity acts downward, the engine adds a constant downward acceleration to all bodies. Over many frames, these incremental changes accumulate into visible motion.

The key insight: the engine does not solve equations analytically. Instead, it uses numerical integration — a method that approximates solutions by taking small discrete steps. This discretization (breaking continuous time into tiny chunks) is the root of many physics quirks.

Collision detection: the two-phase bottleneck

Collision detection is arguably the most expensive and technically complex part of a physics engine. Without it, objects pass through each other. With naive collision testing, every object checks against every other object every frame — O(n²) complexity that becomes prohibitively slow with hundreds of bodies.

To solve this, collision detection happens in two phases:

Broad phase: This is the optimization step. The engine quickly eliminates pairs of objects that are too far apart to collide. Common approaches include:

• Bounding box checks: Wrap each object in a simple shape (axis-aligned bounding box, or AABB). Only pairs with overlapping bounding boxes advance to narrow phase. Fast but can miss collisions if bounding boxes overlap while shapes do not.
• Spatial partitioning: Divide the world into a grid, octree, or Bounding Volume Hierarchy (BVH). Objects are placed into cells based on their position. Only check collisions between objects in the same or adjacent cells. This reduces the number of candidate pairs from n² to roughly O(n log n).

Broad phase does not determine if a collision actually happened; it just narrows the search space.

Narrow phase: For candidate pairs that passed broad phase, the engine performs precise geometric tests. Is a sphere really overlapping a triangle mesh? At what exact point did they collide? From what direction?

Common narrow-phase algorithms include:

• Sphere-sphere collision: Calculate distance between centers; if less than the sum of radii, they collide.
• Sphere-plane collision: Distance from sphere center to plane; if negative and less than radius, intersection.
• General convex-convex (GJK algorithm): An iterative method that finds the closest points on two convex shapes. Elegant but slower than specialized tests.
• Mesh-mesh (SAT or other): For complex shapes, use the Separating Axis Theorem (SAT) — if a separating axis exists, the shapes do not collide.

Once the engine detects a collision, it computes the contact point (where they touch), contact normal (the direction perpendicular to the surface), and penetration depth (how far they overlap). These values are fed into constraint solving.

Source: Toptal (2025) — Comprehensive tutorial on rigid body dynamics and collision detection in game physics engines.

Integration methods: Euler versus Verlet

The simplest way to update position is the Euler method:

new_velocity = old_velocity + acceleration * deltaTime
new_position = old_position + new_velocity * deltaTime

This is fast and intuitive. Given the current velocity and a time step (deltaTime, typically 0.016 seconds at 60 fps), compute the new position. The problem: Euler is inaccurate. It assumes constant velocity over the time step, but velocity changes continuously as forces act. Over many frames, errors accumulate (called numerical drift), and simulations become unstable.

A better approach is semi-implicit Euler (also called symplectic Euler):

new_velocity = old_velocity + acceleration * deltaTime
new_position = old_position + new_velocity * deltaTime

The difference: update velocity first, then use the new velocity to update position. This small change dramatically improves stability without much computational overhead.

Verlet integration takes a different approach. Instead of storing velocity, it stores both the current position and the position from the previous frame:

new_position = 2 * current_position - old_position + acceleration * deltaTime²

Verlet is particularly elegant for soft body simulation (cloth, rope, hair) because the velocity is implicit — it's encoded in the difference between positions. This avoids floating-point precision loss from storing velocity separately. Many physics engines use semi-implicit Euler for rigid bodies and Verlet for soft bodies.

Source: Game Physics Toptal Tutorial (2025) — Detailed mathematical comparison of Euler and Verlet methods in real-time systems.

Constraint solving: making contacts stick

When two bodies collide, the physics engine must prevent them from interpenetrating (passing through each other). This is achieved through constraint solving — applying impulses or forces that correct the relative velocity at contact points.

The standard approach is Sequential Impulse solving, popularized by physics libraries like Box2D and Havok. The algorithm:

1. For each contact point, compute the relative velocity between the two bodies at that point.
2. If the velocity is moving toward interpenetration (contact normal is negative), compute an impulse that will bring the relative velocity to zero (or bounce, if the material is elastic).
3. Apply that impulse to both bodies, scaling by their inverse masses (lighter objects accelerate more than heavier ones).
4. Repeat over multiple iterations (typically 4-10) to refine the solution.

Why iterate? A single impulse to stop one contact might create a new contact elsewhere, or a contact between three objects might require multiple passes to resolve all constraints simultaneously. By iterating, the solver converges toward a physically consistent state. This is not a perfect solution — the engine might still allow small overlaps — but it's fast and stable.

For joints (hinges, ball-and-socket connections), the same approach applies: compute a constraint force that keeps the joint at the desired relative position and rotation.

The stability-accuracy tradeoff: why physics bugs exist

Here is the core tension in game physics: the smaller the timestep, the more accurate the simulation, but the more CPU time required. A game running at 60 fps has a fixed timestep of ~0.0167 seconds. This is relatively coarse — a lot can change in 16 milliseconds.

Tunneling: One of the most notorious physics bugs occurs when an object moves so fast it "tunnels" through a wall. Suppose a bullet travels at 1000 m/s, and the timestep is 0.0167 seconds. In one frame, the bullet moves 16.7 meters. If the wall is only 0.5 meters thick and is centered at 10 meters, the bullet starts at 5 meters, the next frame it is at 21.7 meters — it completely skips over the wall. Broad phase never detected a collision because no bounding box checked the interior of the wall.

Solutions include:

• Continuous collision detection: Instead of checking if a shape is colliding at discrete frames, trace a swept shape (the path of the object as it moves) and check if that swept volume intersects any obstacles.
• Clamping velocities: Artificially limit how fast objects can move per frame.
• Smaller timesteps: Reduce deltaTime, but this increases CPU cost.

Jitter: When an object rests on a surface, gravity pulls it down, but the contact constraint pushes it back up. If the simulation is not precise enough, the object might oscillate around the correct resting position — visible as jitter or vibration. This is often fixed by lowering contact thresholds or adding a restitution bias that gently slows bouncing.

Stacking instability: When many objects stack (boxes on boxes on boxes), small errors in each constraint propagate up the stack. A mis-calculated force on the bottom box leads to an error on the box above it, which leads to a larger error on the box above that. The stack topples over as errors compound. Solvers reduce this with warm-starting (reusing previous frame's impulses as an initial guess) and increasing iteration counts for stacked bodies.

Soft body simulation: beyond rigid bodies

Not all objects are rigid. Cloth, hair, ropes, and fluid need different models.

Soft body simulation often uses a particle-based approach: represent the object as a mesh of particles (vertices) connected by springs or constraints. Each particle has mass, position, and velocity. Constraints enforce maximum distances between connected particles (preventing the mesh from stretching infinitely) or bending angles (preventing cloth from folding unrealistically).

Verlet integration works beautifully here because it naturally handles collisions — particles near a surface are projected outward, and the implicit velocity from the Verlet equation gives believable bouncing.

Cloth simulation is a common example. A cloth mesh is a grid of particles, each connected to its neighbors by distance constraints. Wind is applied as an external force, gravity pulls downward, and collisions with the character push particles away. The result feels like fabric draping realistically. Games like The Witcher 3 and Red Dead Redemption 2 use sophisticated cloth solvers that sometimes take more time per frame than rigid body physics.

Fluid simulation is vastly more complex. A few approaches exist:

• Particle-based (SPH): Represent fluid as particles and calculate pressure and viscosity from neighboring particles. Used in games for splashes and small-scale effects.
• Grid-based (FLIP): Solve fluid equations on a 3D grid. More accurate but much more expensive.
• Surface-only: Simulate only the fluid surface as particles, with interior treated as a solid. Used for water in games like Horizon Zero Dawn.

Fluid simulation is rarely done in full real-time; most games use canned animations or heavily simplified approximations.

Ragdoll physics: skeletons with constraints

When a character in a game dies, it often "ragdolls" — the body goes limp and tumbles realistically. This is achieved by mapping the character's skeleton to a physics rig: each bone becomes a rigid body, and joints between bones become constraints (ball-and-socket for hips/shoulders, hinges for elbows).

When ragdoll is activated, the physics simulation takes over. The character's limbs interact with the environment, colliding with walls and falling down stairs. The skeleton deforms (within limits) as bodies settle under gravity.

The challenge: ragdoll must feel responsive but stable. If the constraint solves too weakly, limbs will bend unnaturally. If too stiffly, the ragdoll will vibrate. Most engines tune ragdoll parameters carefully and sometimes use damping (friction in joints) to settle the character smoothly.

Major physics engines: speed and accuracy tradeoffs

Several engines dominate the industry, each with different strengths:

Engine	Used In	Strengths	Tradeoff
NVIDIA PhysX	Unreal, Unity (legacy), many indie games	GPU acceleration, soft body support, good documentation	Proprietary; NVIDIA dependency
Havok Physics	Rockstar (GTA/RDR), Bethesda (Skyrim), many AAA games	Industry-standard stability and scale, excellent for large worlds	Expensive licensing; closed-source
Box2D	2D games (Dead Cells, Angry Birds), ubiquitous for 2D	Extremely fast, lightweight, open-source	2D only; less sophisticated collision shapes
Bullet Physics	Unreal, Unity (legacy), many tools	Open-source, widely compatible, decent documentation	Slower than PhysX; less GPU support
Jolt Physics	Starfield, emerging in Unreal Engine	Modern design, excellent multithreading, C++ performance	Newer; less real-world usage than Havok
Rapier (Rust)	Emerging engines, Veloren, Bevy ECS	High performance, strong modern architecture, GPU roadmap	Rust-only; less mature than industry standards

Source: Game Physics Engines Overview (2026) — Comparative analysis of modern physics engines and their adoption in AAA and indie titles.

Why physics bugs are deterministic (but still unpredictable)

A common misconception: physics bugs are random. They are not. Physics engines are deterministic — given the exact same starting conditions and the same sequence of inputs, a simulation will produce the exact same result every time.

But this is also the problem. A tiny difference in initial conditions (floating-point rounding error, a collision detected a frame earlier or later) cascades into wildly different outcomes. A character's jump might sometimes clip through a wall because of the order in which constraints resolved. A ragdoll might fall differently because of a minor difference in velocity.

This is why speedrunners can exploit physics. They find precise input sequences that trigger edge cases: a jump from a specific pixel position, a collision at a specific angle, which sends the character flying into the level geometry. The physics engine is not broken — it is working exactly as designed. It is just that the design, applied to an edge case, produces a surprising result.

Debugging physics: common misconceptions

"Physics is slow": Physics is actually one of the cheaper aspects of modern games. A physics frame might take 2-3 milliseconds out of a 16.67 ms (60 fps) budget. Rendering and AI typically consume much more.

"Physics engines are black boxes": Not true for open-source engines (Bullet, Box2D, Rapier). And even proprietary engines expose parameters (gravity, friction, restitution, iteration counts) that you can tune. Many physics bugs are fixable by adjusting these knobs rather than changing code.

"Faster physics always feels better": Counterintuitively, physics that is too fast or too loose can feel worse than slightly constrained physics. Players expect objects to interact predictably. Over-accurate physics can introduce unexpected behavior.

The takeaway

Physics engines work by breaking continuous motion into discrete timesteps, using simplified math to approximate Newtonian dynamics, and iteratively resolving collisions and constraints. The result is not physically accurate — no physics engine truly simulates reality — but it is fast and feels right. The tradeoffs are baked in: continuous collision detection costs CPU but prevents tunneling; higher iteration counts improve stability but slow the frame; soft body simulation adds realism but explodes in complexity. Modern engines like Jolt and Rapier push the boundaries with better algorithms and multithreading, but the fundamental approach — timestep integration, broad/narrow phase collision, impulse solving — remains unchanged since the early 2000s. Understanding this framework explains both the elegance of physics simulation and the quirky bugs that make speedrunning possible.

Frequently Asked Questions

Q: Why do objects jitter when resting on a surface?
A: Gravity pulls the object downward, and contact constraints push it upward. If the solver is not precise enough, the object oscillates around the true resting position, visible as jitter. This is fixed by lowering contact thresholds, increasing solver iterations, or adding damping to joints.

Q: Can I make a physics engine from scratch?
A: Yes, but it is not trivial. A minimal rigid body engine requires broad/narrow phase collision detection, an integration method, and constraint solving. For a learning project, Box2D's source code is an excellent reference. A production engine requires optimized spatial structures (BVH), GPU acceleration, and months of tuning.

Q: Why is cloth simulation so expensive?
A: Cloth requires simulating hundreds or thousands of particles connected by constraints. Each particle must check collisions with the environment and other particles. The constraint solver must iterate many times per frame to prevent stretching and tearing. A single cloth might take 1-2 milliseconds per frame at 60 fps, which is substantial.

Q: What is the difference between rigid body and soft body physics?
A: Rigid bodies maintain their shape; soft bodies deform. Rigid bodies are simpler and faster; a box requires only 6 numbers (position and rotation). A cloth requires position for every vertex and constraints between vertices. Soft body is always slower and more complex.

Q: Why do some games feel "floaty" and others "heavy"?
A: The "weight" of physics depends on damping, gravity, and how quickly objects respond to forces. A low gravity and high air resistance makes movement feel floaty (like Portal). High gravity and low damping feels heavy and snappy (like Dark Souls). These are tuning parameters, not engine differences.

Q: Can physics engines predict the future?
A: No. Physics engines are reactive — they respond to forces and collisions as they happen. Some advanced engines use predictive collision to detect future collisions and prevent tunneling, but this is limited to one or two frames ahead. True future prediction would require solving differential equations analytically, which is too expensive for real-time.

---

Read next:

• How Game Engines Work: Unity vs Unreal Explained
• How Graphics Cards Render 3D Games
• Speedrunning: The Science of How Glitches Work