QA Testing for Collision and Physics Edge Cases

Physics makes games feel alive and is the first thing to betray you under stress. At normal speeds your collision holds, objects rest where they should, and characters move predictably. Push the system, high velocities, tight gaps, towers of stacked crates, an explosion flinging a ragdoll, and the cracks appear: a fast projectile passes clean through a wall, a crate vibrates against the floor forever, a character wedges into a corner and judders. These edge cases come from the approximations every physics engine makes, and they are testable. This post covers reproducing collision and physics edge cases deliberately and keeping movement stable when players push hard.

Tunneling at high speed

Tunneling is the classic physics bug: a fast-moving object passes entirely through a wall or floor because, between two simulation frames, it moved from one side to the other without ever overlapping the surface on a frame the engine checked. Bullets, fast projectiles, a player at maximum speed, and objects launched by explosions are the usual victims. The faster the object and the thinner the obstacle, the higher the risk. Test specifically at your highest achievable speeds against your thinnest colliders, because that combination is exactly where discrete collision detection fails.

The standard remedy is continuous collision detection, which sweeps the object's path between frames and catches the crossing, but it is more expensive so it is often enabled only on select bodies. Test that it is actually on for everything that moves fast enough to tunnel, projectiles, the player, key dynamic objects, and that thin walls on the critical path are thick enough or backed by continuous detection. Verify behavior at low frame rates too, since a stutter that lengthens a frame gives a fast object more distance to skip, turning an occasional tunnel into a reliable one on slower hardware.

Stuck objects and penetration

Objects getting stuck come from the solver pushing bodies into each other faster than it can separate them, or from a resting configuration the engine cannot resolve. A character walks into a corner and cannot move, a crate spawns half-inside the floor and stays there, two physics objects interpenetrate and lock together. These often appear where geometry is complex or where dynamic objects pile into tight spaces. Test by deliberately forcing objects together, walking into corners, dropping props into gaps, and stacking bodies until the solver strains, then watch for anything that ends up lodged in solid space.

Penetration is the root of much stuck behavior, and how your engine recovers from it matters. A good setup applies gentle separation forces that ease overlapping bodies apart over a few frames; a bad one either ignores the overlap, leaving things stuck, or ejects them violently, launching a crate across the room. Test the recovery by intentionally creating overlaps, spawning an object inside another, ramming bodies together, and confirming they separate smoothly without launching or sticking. A character that gets wedged should be able to move out under normal input rather than needing a reload, so verify that escape is always possible.

Jitter and instability

Jitter is the visible vibration of a body that should be at rest, a crate trembling on the floor, a ragdoll twitching against a wall, a stack of objects buzzing instead of settling. It comes from the solver and the integrator fighting over a configuration they cannot quite resolve, often near contacts or constraints, and it is made worse by overlapping colliders, conflicting constraints, or a timestep mismatched to the simulation. Test resting states explicitly: drop objects and watch whether they settle and stay still, or vibrate indefinitely, and stack several bodies to see if the tower trembles or holds.

Stability erodes fastest under accumulation and extremes. A single object may rest fine while a stack of ten oscillates as small errors compound through the contacts. Test stacking, pinning a body between two others, and chaining constraints like a hinged or roped assembly. Sleeping, where the engine deactivates bodies that have come to rest, is both a cure and a hazard: it kills jitter but can leave an object frozen mid-air if it sleeps before settling, or fail to wake when something should disturb it. Test that bodies sleep only when truly at rest and wake reliably on contact.

Determinism and frame rate dependence

A subtle but serious class of physics bugs is behavior that changes with frame rate. If your simulation steps with the variable render frame time instead of a fixed timestep, the same action produces different results on a fast machine versus a slow one, a jump reaches a different height, a projectile a different range, tunneling appears only below some frame rate. Test the same scenarios at high and low frame rates and on a frame-limited build, and watch for outcomes that should be identical but are not. The fix is almost always a fixed timestep accumulator decoupled from rendering.

Determinism matters even more if your game has replays, networked physics, or speedrun-sensitive movement, where the same inputs must yield the same outcome every run. Test by recording an input sequence and replaying it, confirming the physics resolves identically each time and across machines. Non-determinism here breaks replays, desyncs multiplayer, and makes bugs maddening to reproduce because they seem to happen at random. Establishing a fixed timestep and consistent ordering early saves enormous pain, and testing for frame-rate independence should be a standing check, not an afterthought discovered when a player on a fast PC reports impossible behavior.

Setting it up with Bugnet

Physics edge cases are some of the hardest bugs to reproduce because they depend on exact speed, position, frame rate, and hardware, details a player never includes in see, it went through the wall. Bugnet's in-game report button captures game state and platform context automatically, so a tunneling or stuck report arrives with the location, the platform, and ideally the frame rate or hardware tier if you record it as a custom field. A hard physics crash, an assertion or a NaN explosion in the solver, captured with a stack trace, points you straight at the offending code path rather than a vague glitch description.

Because a given physics flaw, a thin wall that tunnels, a corner that traps, fires identically for everyone who hits it, the reports cluster. Bugnet folds duplicate occurrences into one issue with a count, so a single tunneling spot or a frame-rate-dependent jump exploit surfaces as one prioritized item showing how widespread it is. Filter by a hardware or frame-rate custom field to confirm whether a bug is frame-rate dependent, exactly the signal that distinguishes a timestep issue from a geometry one, then verify your fix on the configurations that reported it. Captured context makes the unreproducible reproducible.

Stress the simulation as routine

Physics stability is not a one-time check because every new mechanic, faster movement ability, heavier object, new constraint, can destabilize what was solid. Build a physics stress scene full of stacks, fast projectiles, tight corners, moving platforms, and explosive forces, and run it whenever the simulation or relevant content changes. Add a debug overlay showing the timestep, active body count, and continuous-detection status so testers can see what the engine is doing. Run the same scenarios at low frame rates to surface tunneling and determinism issues that hide on a fast development machine.

Treat the engine's approximations as a known surface to test against rather than a black box to trust. Enable continuous detection where speed demands it, keep a fixed timestep, give the solver sane iteration counts, and make penetration recovery gentle. Probe high speeds, tight spaces, big stacks, and extreme forces deliberately, and let position-and-hardware-rich reports flag the cases you miss. A game whose physics stays stable when players push it hard feels trustworthy and solid, and that solidity is what separates a polished release from one that becomes a clip reel of glitches.

Physics breaks under stress, not at rest. Push top speeds, force overlaps, and compare across frame rates, then back the fixes with continuous detection and a fixed timestep.