Physics engine interactions for mobile game

Developing a Physics Engine for Mobile Game Interactions

On mobile devices, physics is the most expensive item in the CPU budget. Full PhysX or Bullet simulation at 120 Hz on a Snapdragon 680 ends in throttling by the third minute of the session. Mobile game physics is always a compromise between accuracy and performance, and finding the right balance for a specific genre is non-trivial.

Physics Architecture for Mobile Budget

Fixed Timestep and Its Cost

Unity updates physics in FixedUpdate with interval Time.fixedDeltaTime (default 50 Hz). On a mobile device running at 30 FPS, that means two physics steps per frame. If the game drops to 20 FPS due to thermal throttling, Unity executes 2–3 PhysX steps for one rendered frame—CPU load grows non-linearly.

Optimal strategy: reduce Fixed Timestep to 0.033 (30 Hz) for mobile builds and compensate with more accurate colliders. For games where physics isn't critical to gameplay (puzzles, hyper-casual), drop to 0.05 (20 Hz) and compensate visually via Rigidbody.interpolation = RigidbodyInterpolation.Interpolate.

When PhysX is Overkill

For 2D games in Unity, the built-in Box2D physics (Rigidbody2D, Physics2D) is significantly lighter than PhysX. But even Box2D struggles with 200+ dynamic objects on CPU. In Godot 4, RigidBody2D + GodotPhysics2D is more efficient than 3D physics for flat games.

For hyper-casual and arcade mechanics, it's often worth abandoning the engine's physics entirely and writing deterministic physics by hand:

// 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;
    }
}

Hand-written deterministic physics is predictable, debuggable in one click, and works identically across devices. For multiplayer games it guarantees state synchronization.

Object Interaction: Where Things Usually Break

Object Stacking

PhysX poorly simulates stacks of 10+ dynamic objects on mobile—jitter and objects "falling through" each other start happening. Solution: reduce Rigidbody.maxDepenetrationVelocity to 1–3 m/s (default 10), Physics.defaultSolverIterations to 4–6 (default 6), Physics.defaultSolverVelocityIterations to 1.

Thin Colliders and Tunneling

Fast objects—bullets, projectiles—on low FPS can pass through thin walls in one physics step. Rigidbody.collisionDetectionMode = CollisionDetectionMode.ContinuousDynamic solves it but costs twice as much CPU. Alternative: use raycast instead of physics for projectiles—Physics.SphereCast with projectile radius from previous position to current.

Performance Across Devices

Real profiler data (Unity Profiler + Android Profiler) from a 3D arcade project (80 physics objects, Snapdragon 665):

Custom physics is genre-specific, not universal. But when game mechanics allow it, the gain is obvious.

Physics in React Native Games (Flame/Godot Export)

For React Native games, write using Godot with Web/Android export, or via JavaScript engines (Phaser.js through WebView). Phaser uses Matter.js for 2D physics—lighter than Box2D on memory but less accurate. Matter.Runner.run() with fps: 30 on most Android budget phones is sufficient.

For Flutter + flame: forge2d (Dart port of Box2D) provides full 2D physics. World.stepDt runs in game.update(dt), update frequency controlled by flame game loop. Critical: forge2d works in meters, flame in pixels. Scale factor (worldScale) must be set once and followed consistently.

Development Process

Start by profiling target devices—budget Android and flagship iPhone give different pictures. Choose physics engine or custom implementation based on genre, object count, and target FPS. Implement physics interactions, profile in real conditions (throttle mode, unplugged), iterate.

Typical timelines: basic physics interactions—1–2 weeks, complex systems (destructible objects, soft bodies, fluid simulation)—3–6 weeks. Cost calculated individually after analyzing mechanics.