Physics Engine vs Hand-Rolled Physics

What Hand-Rolled Physics Looks Like

Hand-rolled physics means writing your own movement and collision code without a library. At its simplest, this is velocity plus gravity applied each frame: position.y += velocity.y; velocity.y += gravity * deltaTime. Collision is an if statement: if the player's bottom edge is below the floor, snap to the floor and zero out the vertical velocity. Horizontal movement is direct: position.x += speed * direction * deltaTime, with a wall check that prevents moving past solid tiles.

This approach works because many games do not need the features a physics engine provides. A classic platformer does not need realistic mass, restitution, or friction. The player moves at a fixed speed, jumps with a fixed impulse, and collides with rectangular tiles. The "physics" is really just position updates and boundary checks. Writing this by hand gives you total control over movement feel, which is exactly what platformer players are sensitive to.

Tile-based collision is a common hand-rolled technique. You represent the level as a 2D grid of solid and empty tiles. To check if the player collides with the environment, you compute which tiles the player's bounding box overlaps and check if any of those tiles are solid. If so, push the player out along the axis of least penetration. This runs in constant time regardless of level size because you only check the tiles the player touches, not every tile in the level.

For top-down games, hand-rolled circle-vs-circle collision detection is one distance comparison. If the distance between two centers is less than the sum of their radii, they collide. Push them apart along the line between their centers. This handles projectile hits, enemy overlap, and pickup collection with no library needed.

What a Physics Engine Adds

A physics engine handles problems that become intractable by hand once you move past simple cases. Stacking is the classic example. If you drop 10 boxes on top of each other, a physics engine's constraint solver ensures they settle into a stable pile. By hand, you would need to detect every box-to-box contact, compute the exact penetration and normal for each, resolve them in an order that does not create new overlaps, and iterate until the pile stabilizes. This is the core of what a physics engine does, and reproducing it correctly is a multi-month engineering effort.

Multi-body collision response is another pain point. When three objects collide simultaneously, the response depends on all three bodies' masses, velocities, and contact normals. A physics engine handles this with an iterative solver (sequential impulses or projected Gauss-Seidel) that converges on a physically correct solution. By hand, you would likely process pairs independently, which produces jittering and objects passing through each other when more than two bodies interact at once.

Constraints are effectively impossible to replicate by hand at quality. A hinge joint requires maintaining a shared pivot point between two bodies while allowing rotation around exactly one axis, enforced through impulses computed from the constraint equations. Building this from scratch requires solid understanding of Lagrangian mechanics and iterative solvers. Physics engines provide these as ready-made building blocks.

Continuous collision detection (CCD) prevents fast objects from tunneling through thin walls. Implementing CCD correctly involves swept volume tests and time-of-impact calculations that are mathematically involved and tricky to get right. Physics engines have debugged implementations with years of edge-case fixes.

When Hand-Rolled Physics Is the Better Choice

Choose hand-rolled physics when your game has simple, predictable interactions and you need tight control over movement feel. Specifically:

Tile-based platformers where the player interacts with a static grid and does not push or stack objects. The movement feel in platformers comes from carefully tuned acceleration curves, coyote time, jump buffering, and variable jump height. A physics engine's realistic gravity and mass model can fight against these tuning parameters instead of helping them.

Top-down games where characters move on a flat plane and collide with walls and each other using simple shapes. Circle-vs-rectangle and circle-vs-circle checks are fast and simple to write. Adding a physics engine for this adds dependency weight and complexity without gameplay benefit.

Games with very few moving objects (under 5) where each object's behavior is scripted rather than emergent. A single bouncing ball, a paddle, and bricks (Breakout) do not need a physics engine. The ball reflects off surfaces at predictable angles. The code is 20 lines of vector math.

Performance-critical mobile games where every kilobyte and millisecond matters. A physics engine adds bundle size (Rapier's WASM is around 500 KB, Cannon-es is around 100 KB minified) and per-frame computation. If you only need basic collision, the overhead is wasted.

Games where you explicitly want non-physical behavior. Some games intentionally violate physics for fun: instant direction changes, hovering, wall jumping, dashing through enemies. Fighting against a physics engine's realistic model to achieve deliberately unrealistic movement creates more work than writing the movement code directly.

When a Physics Engine Is the Better Choice

Choose a physics engine when your game depends on emergent physical behavior, meaning interactions that you cannot predict or script in advance.

Any game with stacking, piling, or avalanche behavior. Crates that tumble when the bottom one is destroyed. Blocks that settle into stable piles. Sand or debris that spreads when disturbed. These require proper contact solving.

Games with ragdoll characters. Death animations, knockout effects, and limp bodies dragged across terrain all need a constraint solver with proper joint limits.

Games with vehicles, ropes, chains, or destructible structures. These are constraint systems that are impractical to write from scratch.

Games with more than a few dozen dynamic objects interacting. Once you have 20 or more moving bodies that can collide with each other, the broadphase optimization and solver stability of a physics engine pay for themselves many times over.

3D games with complex collision environments. Checking a capsule against arbitrary 3D geometry for a character controller involves GJK, swept tests, and contact generation that are difficult and error-prone to implement from scratch.

The Hybrid Approach

Many successful games use a hybrid approach. The player character uses hand-rolled movement code for precise, responsive controls, while environment objects (crates, debris, ragdolls) use the physics engine. The player's body is kinematic in the physics world, meaning it is moved by your custom code and pushes other objects but is not affected by them. Dynamic objects in the environment respond to the physics engine normally.

This gives you the best of both worlds: tight, hand-tuned player controls and realistic physical behavior for everything else. The player feels responsive and predictable, while the world feels alive and reactive. Many AAA games use this exact pattern, and it works equally well in browser games.

Another hybrid pattern is using a physics engine only for specific systems. You might use Rapier exclusively for the ragdoll system and write all other movement and collision by hand. Or you might use Cannon-es only for vehicle physics and handle character movement with custom code. Physics engines do not require you to put every object in the simulation.

Decision Checklist

Ask yourself these questions about your game. If you answer yes to two or more, a physics engine is likely worth the overhead.

Do objects stack on top of each other? Do more than 10 dynamic objects interact simultaneously? Do you need constraints like joints, ropes, or springs? Do you need ragdoll characters? Is the collision geometry complex (slopes, curves, 3D meshes)? Do objects have different masses that should affect collision response? Do you need vehicles with suspension or wheel physics?

If you answered no to all of them, hand-rolled physics will be simpler, lighter, and give you more control. Start without an engine and add one later if you find yourself reimplementing features that an engine already provides.