Start Building

Game Physics Programming - From Basic Collision to Advanced Systems

Physics can make or break how a game feels. Get it wrong and movement feels floaty, hits feel weak, or objects clip through walls. Get it right and every jump and impact feels satisfying. You don't have to be a physicist to ship good game physics; you need a clear mental model of collision, response, and when to lean on your engine versus writing your own.

This guide walks you from basic collision detection (AABB, circles) through simple response and when to step up to rigid bodies, constraints, and advanced systems. The ideas apply across Unity, Unreal, Godot, and custom engines.

Why Game Physics Matters

Players notice physics in small moments: a character landing after a jump, a crate sliding to a stop, a projectile hitting a target. Inconsistent or buggy physics breaks immersion and trust. Consistent, predictable behavior makes the world feel real and responsive. Even stylized or arcade games benefit from clear rules: predictable collision and response help players learn and master the game.

Basic Collision Detection

Collision detection answers: "Do these two shapes overlap?" You don't need full rigid-body simulation to start; many games use simple shapes and custom logic.

AABB (Axis-Aligned Bounding Box)

An AABB is a box whose edges are aligned with the world axes (no rotation). You store a minimum and maximum point (or center + half-extents). Two AABBs overlap if they overlap on all three axes.

2D overlap check (concept):

  • Box A: minX1, maxX1, minY1, maxY1
  • Box B: minX2, maxX2, minY2, maxY2
  • Overlap if: minX1 < maxX2 && maxX1 > minX2 && minY1 < maxY2 && maxY1 > minY2

Pro tip: Use center + half-extents in code; it makes moving and resizing the box easier. Convert to min/max only when needed for the check.

Common mistake: Forgetting to update the AABB when the object moves or rotates. If the object rotates, the AABB must either be recomputed (still axis-aligned, so it grows) or you switch to a different shape (e.g. OBB or circle).

Circle vs Circle

Two circles overlap if the distance between their centers is less than the sum of their radii. No need for sqrt: compare squared distance to squared sum of radii to avoid a square root.

2D: (x1 - x2)² + (y1 - y2)² <= (r1 + r2)²

Circles are cheap and work well for characters, projectiles, and pickups. They don't match rectangular obstacles well, so many games use circle for the player and AABB or tiles for the world.

Point in Shape

For "did a point (e.g. mouse, bullet) hit this shape?" you need point-in-AABB, point-in-circle, or point-in-polygon. Point-in-AABB and point-in-circle are a few comparisons; point-in-polygon is more work but well-documented (ray casting or winding number).

From Detection to Response

Knowing two things overlap is only the first step. Response is "what do we do about it?" so objects don't stay stuck or pass through each other.

Separation (Push-Out)

The simplest response is to move one or both objects so they no longer overlap. For AABBs you compute the overlap on each axis and push along the axis with the smallest overlap (minimum penetration). That gives a believable "slide" along walls instead of getting stuck.

Pro tip: Resolve in a consistent order (e.g. player vs world first, then player vs enemies) and fix one axis at a time so movement stays stable.

Velocity Response (Bounce)

For moving objects you often want them to bounce. After resolving overlap, reflect the velocity (or the component along the collision normal) and optionally multiply by a restitution factor (0 = no bounce, 1 = full bounce). Same idea works for circles and AABBs once you have a collision normal and penetration depth.

Mass and Moving Objects

When both objects can move, you typically split the response by mass (or make one "static" with infinite mass). So a light crate moves more than a heavy character when they collide. The formula is a simple weighted average of the separation and velocity change based on inverse mass.

When to Use the Engine's Physics

Modern engines ship with robust physics (Unity PhysX, Unreal Chaos, Godot Physics). Use them when you need:

  • Rigid bodies (gravity, forces, torque)
  • Complex shapes (compound colliders, meshes)
  • Joints and constraints (ragdolls, vehicles, doors)
  • Raycasts and shape casts (line of sight, ground check, projectiles)
  • Consistent behavior across many objects

You still need to tune mass, drag, constraints, and layers so the result feels right. The engine handles the hard part; you handle the design.

When to Roll Your Own

Custom physics (or hybrid) can make sense when:

  • Performance is critical (hundreds of entities, mobile, or low-level control).
  • You need deterministic simulation (replay, networking) and the engine's solver is not deterministic.
  • The game is 2D and simple (platformer, top-down) and a full 3D rigid-body system is overkill.
  • You need very specific behavior (e.g. custom arcade feel, one-off collision rules) that is easier to code than to configure.

Start with the engine; go custom only when you hit real limits. Many successful games use engine physics with a thin layer of tuning and special cases.

Advanced Topics (Brief)

Once basics are solid, you can explore:

  • Swept collision / continuous detection so fast-moving objects don't tunnel through thin walls. Engines often expose this as "continuous" or "speculative" collision.
  • Spatial partitioning (grid, quadtree, BVH) so you don't check every pair of objects. Essential for large numbers of colliders.
  • Constraints and joints (distance, hinge, spring) for doors, ropes, and vehicles. Usually best left to the engine unless you're building one.
  • Integration (Euler, Verlet, RK4) if you write your own motion. Semi-implicit Euler is common for real-time; Verlet is handy for particles and cloth.

FAQ

Should I use 2D or 3D physics for a 2D game?
Use the engine's 2D physics (e.g. Unity 2D, Godot 2D) when available. It's simpler and faster than 3D for flat gameplay.

Why do my objects jitter or sink into the ground?
Usually fixed timestep, substepping, or collision resolution order. Run physics at a fixed delta (e.g. 1/60 s), allow multiple substeps per frame, and resolve in a stable order. Check the engine docs for "fixed timestep" and "physics iterations."

How do I make a character controller that doesn't use rigid bodies?
Use a capsule or box and move it yourself (velocity, input). Use raycasts or shape casts to detect ground and walls and push the character out of geometry. Many platformers do this for precise control.

When is custom collision worth it?
When you've profiled and the engine is the bottleneck, or when you need deterministic or very specific behavior that the engine doesn't give you. For most games, engine physics plus tuning is enough.

Next Steps

Get hands-on: implement a simple AABB vs AABB or circle vs circle in a small test scene, then add separation and a bounce. Once that feels right, try the same in your engine of choice with its colliders and rigid bodies. For deeper dives, see our Optimizing Game Performance guide and Unity or Godot physics docs.

Found this guide useful? Bookmark it and share it with your team. Solid physics fundamentals will help you ship games that feel right.