How to Optimize a Physics Engine for Mobile Games?
With over 5 years of experience in mobile game physics optimization and 50+ shipped titles, we guarantee optimal performance. For effective Android physics optimization, target devices like Snapdragon 665 and above. Unity mobile physics can be fine-tuned for better performance, and our certified engineers will ensure your game runs smoothly.
We often encounter this situation: a game with realistic physics in Unity drops to 15 FPS on a Snapdragon 680 a minute after launch. Full PhysX or Bullet simulation at 120 Hz is an unaffordable luxury for a mobile CPU. That's why our approach is to find a compromise between fidelity and performance for each genre. Contact us — we'll evaluate your project in 2 days and propose the optimal architecture.
Fixed Timestep and Its Cost
Unity updates physics in FixedUpdate with an interval of Time.fixedDeltaTime (default 50 Hz). On a mobile device running at 30 FPS, this means two physics steps per frame. If the game runs at 20 FPS due to thermal throttling, Unity executes 2-3 PhysX steps per rendered frame — CPU load grows non-linearly. According to Unity documentation, FixedUpdate is called at a fixed interval, but on weak devices this can cause drops.
The optimal strategy: reduce Fixed Timestep to 0.033 (30 Hz) for mobile builds and compensate with more precise colliders. For games where physics is not critical to gameplay (puzzles, hyper-casual), you can go down to 0.05 (20 Hz) and interpolate object positions visually via Rigidbody.interpolation = RigidbodyInterpolation.Interpolate. Over 5 years of mobile game dev experience — we've tried dozens of configs and achieved up to 40% CPU load reduction on physics.
When PhysX Is Overkill
For 2D games in Unity, the built-in Box2D physics (via Rigidbody2D, Physics2D) is significantly lighter than PhysX. But even Box2D with 200+ dynamic objects starts stressing the CPU. In Godot 4, similarly, RigidBody2D + GodotPhysics2D is more efficient than 3D physics for flat games.
For hyper-casual and arcade mechanics, it's often better to completely abandon the engine's physics system and write deterministic physics manually:
// Simplified jump physics without Rigidbody void Update() { if (isGrounded && Input.GetTouch(0).phase == TouchPhase.Began) velocity.y = jumpForce; velocity.y -= gravity * Time.deltaTime; transform.position += velocity * Time.deltaTime; if (transform.position.y <= groundLevel) { transform.position = new Vector3(transform.position.x, groundLevel, 0); velocity.y = 0; isGrounded = true; } } Deterministic physics is predictable, easy to debug, and works identically on any device. For multiplayer games, it also ensures state synchronization.
How to Write Deterministic Physics: Step-by-Step Guide
- Define necessary properties: gravity, velocity, acceleration.
- In each frame, update position via
transform.position += velocity * Time.deltaTime. - Handle collisions with simple checks (e.g., screen boundaries).
- For object interactions, use minimal calculations without the physics engine.
This approach achieves 60 FPS on budget devices even with hundreds of objects.
Why Custom Physics Is Sometimes Better
Object Interaction: Where It Usually Breaks
Stacking objects PhysX simulates stacks of 10+ dynamic objects poorly on mobile hardware — jitter occurs and objects clip through each other. Solution: reduce Rigidbody.maxDepenetrationVelocity to 1-3 m/s (instead of default 10), Physics.defaultSolverIterations to 4-6 (default 6), Physics.defaultSolverVelocityIterations to 1.
Thin colliders and tunneling Fast objects — bullets, projectiles — at low FPS can pass through a thin wall in one step. Rigidbody.collisionDetectionMode = CollisionDetectionMode.ContinuousDynamic solves this but doubles CPU cost. Alternative: for projectiles, use raycast instead of a physics body — Physics.SphereCast with the projectile's radius from previous to current position.
Performance on Different Devices
Real data from the profiler (Unity Profiler + Android Profiler) in a 3D arcade project (80 physics objects, Snapdragon 665):
| Configuration | Fixed Timestep | CPU on Physics | FPS |
|---|---|---|---|
| Default PhysX | 50 Hz | 4.2 ms/frame | 38 |
| Reduced iterations | 30 Hz | 2.1 ms/frame | 56 |
| Custom physics | N/A | 0.6 ms/frame | 60 |
Box2D is up to 3x more CPU efficient than PhysX in 2D scenes. Custom physics can be 4-7x faster than PhysX on budget mobile devices. These comparisons highlight the importance of choosing the right engine.
Custom physics is genre-specific, not a universal solution. But when the game mechanics allow it, the gain is clear. We've designed over 50 mobile games with different physics approaches — from arcades to simulators.
Comparison of popular engines:
| Engine | Platform | Performance | Determinism | Recommendation |
|---|---|---|---|---|
| Box2D | 2D | Medium | Yes | For 2D games up to 200 objects |
| PhysX | 3D | High | No | For 3D with powerful devices |
| Custom physics | Any | Maximum | Yes | For hyper-casual and multiplayer |
Snapdragon physics benchmarks show custom solutions outperform default engines by a wide margin.
Physics in React Native and Flutter Games
For React Native, games are either written in Godot with Web/Android export, or via a JavaScript engine (Phaser.js through WebView). Phaser uses Matter.js for 2D physics — lighter on memory than Box2D but less accurate. Matter.Runner.run() with fps: 30 is sufficient on most budget Android devices.
For Flutter + flame: forge2d (Box2D port to Dart) provides full 2D physics. World.stepDt is called in game.update(dt), update frequency is controlled by flame's game loop. Critical: forge2d works in meters, flame in pixels. The conversion factor (worldScale) must be set once and used consistently.
When to use custom physics
Custom physics is justified if: the game has unique mechanics (rubber objects, deformations), determinism is required for multiplayer, or standard engines don't achieve the target FPS on target devices. Otherwise, tuning the existing engine is enough.What's Included in the Work
- Analysis of mechanics and profiling of target devices
- Choice of physics engine or design of custom solution
- Development and tuning of physics interactions
- Optimization for low-performance devices (throttling, thermal protection)
- Integration with analytics and crash reports
- Documentation on configs and release support
Work Process
We start by profiling target devices — a budget Android and a top iPhone give different pictures. We choose the physics engine or custom implementation based on genre, object count, and target FPS. We write physics interactions, profile in real conditions (throttle mode, without charging), and iterate.
Basic optimization packages start from $500, while full custom physics solutions range from $2500 to $6000 depending on complexity. Contact us for a free quote.
Typical timelines: basic physics interactions — 1-2 weeks, complex systems (destructible objects, soft bodies, fluid simulation) — 3-6 weeks. Cost is calculated individually after analyzing mechanics. Get a consultation on your game physics architecture — contact us.







