Developing a Collision System for Mobile Games
Collision detection in a mobile game isn't something that "just works." Standard colliders in Unity and Godot work well on desktop, but on mobile with inconsistent FPS and CPU throttling, the collision system fails precisely when it matters most.
Main Problems with Stock Colliders on Mobile
Tunneling—an object moving at high speed passes through another between two physics steps. CollisionDetectionMode.Continuous in Unity solves this but costs roughly twice as much CPU as Discrete. On budget Android devices this is noticeable.
False positives at seams. PolygonCollider2D with multiple vertices at the junction of two tiles often generates a "phantom" collision—the player stumbles on a flat surface. This is a classic tile game bug. In Unity, solved via Composite Collider 2D, which merges neighboring tile colliders into one polygonal shape.
Expensive MeshColliders. MeshCollider with Convex = false doesn't participate in dynamic-to-dynamic collisions—only static. For arbitrary shapes on dynamic objects, approximate with primitives: multiple BoxCollider/CapsuleCollider instead of one MeshCollider. Manual work, but reduces broadphase load by orders of magnitude.
Layered Collision Matrix
First thing to set up on any project—the layer matrix (Physics > Layer Collision Matrix). Common beginner mistake: leave all layers interacting. With 5 object types that's 25 pair checks instead of 6–8 actually needed.
For mobile this directly impacts broadphase (first collision detection phase where Unity discards unsuitable pairs by AABB). Fewer active pairs—less work per physics step.
Custom Collision Detection for Specific Mechanics
Some genres don't need engine physics. Example: a runner needing only character-ground and character-obstacle collisions. Instead of Rigidbody + Collider—use raycast-based system:
void CheckGround() {
RaycastHit2D hit = Physics2D.Raycast(
transform.position,
Vector2.down,
groundCheckDistance,
groundLayer
);
isGrounded = hit.collider != null;
if (isGrounded) groundNormal = hit.normal;
}
void CheckObstacles() {
// BoxCast forward along movement direction
RaycastHit2D hit = Physics2D.BoxCast(
transform.position,
colliderSize,
0f,
Vector2.right,
obstacleCheckDistance,
obstacleLayer
);
if (hit.collider != null) OnObstacleHit(hit);
}
Lighter, completely deterministic, gives direct control over behavior. No random jitter from solver iterations.
Trigger vs Collision: When to Use What
OnTriggerEnter / OnCollisionEnter—fundamental distinction. Collision is physical impact with impulse, trigger is logical overlap without physics. Common mistake: use Collision where Trigger suffices, adding extra Rigidbody and burdening the solver.
On Godot 4 analogy: Area2D for triggers and zones, CharacterBody2D.move_and_collide() / move_and_slide() for physics. move_and_slide() automatically slides along inclined surfaces—what Unity requires manual implementation via surface normal.
Optimization on Real Devices
Profiling in Unity Profiler (Deep Profile) on target devices is mandatory. Watch Physics.Processing and Physics2D.Processing in timeline. Typical culprits for frame drops:
- too small
Fixed Timestep(creates extra steps on slow frames) -
Rigidbody.interpolation = Interpolateon dozens of objects - dynamic
CompositeCollider2Dwith frequent geometry rebuilds
Timeline for collision system development: simple mechanics—3–5 days, complex (multi-layer geometry, custom detector, optimization for weak devices)—1–3 weeks. Cost calculated individually.