Most games should use the physics engine that ships with their engine. This article is about the minority that genuinely should not — and how to tell which group you are in before spending months finding out.
Use the default until it blocks you
Stock physics represents years of engineering you get free. Replacing it costs real time and introduces bugs in a system that currently works. The honest default is: do not.
But there are four situations where it genuinely blocks a product, and in those cases fighting the solver costs more than replacing it.
The four legitimate reasons
1. You need determinism
Unity's physics is not deterministic across platforms, and is not guaranteed identical between runs. If you need lockstep multiplayer, compact replays, or reproducible bug reports, no amount of configuration will get you there.
This is the most common genuinely valid reason, and it is binary — you either need it or you do not.
2. Your signature mechanic fights the solver
If your game's identity depends on a specific movement feel — precise platforming, a particular ricochet behaviour, momentum that behaves unlike rigid-body physics — you will spend the project working around solver behaviour you cannot change.
Many acclaimed platformers do not use rigid-body physics for the player at all. They implement custom movement with hand-tuned collision, because "realistic" is not the goal; "feels right" is.
3. Frame budget on low-end devices
General engines pay for generality. If physics is consuming milliseconds you need elsewhere on a budget Android phone, a purpose-built solver handling only your actual shapes and interactions can be several times cheaper.
4. Simulation-grade accuracy
Game physics prioritises stability and speed over physical correctness. For training simulators, engineering visualisation or educational tools where numbers must be defensible, that trade-off is the wrong way round.
Reasons that are not good enough: "the default feels floaty" (usually tuning, not the solver), "physics is buggy" (usually your integration, not the engine), "I want more control" (control has a cost — name the specific behaviour you need). Exhaust tuning before concluding the engine is the problem.
Custom does not mean all-or-nothing
The most common successful approach is partial replacement:
| Approach | Effort | Good for |
|---|---|---|
| Custom character controller only | Low | Platformers; player feel is the issue |
| Custom solver for one interaction | Low–medium | One mechanic that must behave specifically |
| Full 2D engine, native plugin | Medium | Determinism, or 2D performance |
| Full 3D rigid-body engine | High | Simulation-grade or deterministic 3D |
Most teams who think they need a custom physics engine actually need a custom character controller. That is a fraction of the work and solves the feel problem directly.
What you take on
Being straight about the cost, because it is routinely underestimated:
- Broadphase — spatial partitioning so you are not testing every pair.
- Narrowphase — SAT for simple shapes, GJK/EPA for general convex in 3D.
- Contact manifold generation — turning intersections into stable contact points. This is where naive engines produce jitter.
- Constraint solver — sequential impulse or similar, with enough iterations for stability.
- Continuous collision — so fast objects do not tunnel through thin geometry.
- Sleeping — deactivating settled bodies, or you burn CPU on a static pile.
- Integration with the engine — transform sync, editor tooling, debug visualisation.
Stacking stability in 3D is the item that surprises people. Getting boxes to rest in a pile without slowly sinking or jittering is genuinely hard, and it is exactly what stock engines have spent years refining.
Scope-narrowing that makes this tractable: do you need arbitrary convex shapes, or would circles, capsules and boxes cover your game? Do you need joints? Do you need stacking at all? A solver supporting three shape types with no joints is a manageable project; a general engine is not.
A decision test
- Write down the specific behaviour you cannot achieve. If you cannot state it precisely, you have a tuning problem.
- Try to achieve it with the default — custom controller, tweaked solver iterations, manual collision response for the one case.
- If determinism is the requirement, stop — you need custom, and no tuning changes that.
- Profile before claiming performance. Confirm physics is genuinely your bottleneck.
- Narrow the scope hard before starting, then prototype the core solver in isolation.
Considering replacing your physics, and want an honest read on whether you should? Describe the behaviour you need — we will say so if tuning is the real answer. See our physics engine service and the determinism guide.