Розробка системи зіткнень (Collision System) мобільної гри

Розробка системи столкновень (Collision System) мобільної гри

Collision detection у мобільній грі—не той компонент, який «просто працює». Стандартні collider'и Unity та Godot добре працюють на десктопі, але на мобільних з непостійним FPS та дросселюванням CPU система колізій дає збої саме в найпроблемніші моменти.

Головні проблеми штатних collider'ів на мобілі

Туннелювання—об'єкт на високій швидкості проходить крізь інший між двома фізичними кроками. CollisionDetectionMode.Continuous в Unity вирішує, але коштує приблизно вдвічі дорожче на CPU, ніж Discrete. На бюджетних Android-пристроях це помітно.

Помилкові спрацьовування на стиках. PolygonCollider2D з кількома вершинами на стику двох тайлів часто генерує «фантомну» колізію—персонаж спотикається на рівній поверхні. Це класичний баг тайлових ігор. В Unity вирішується через Composite Collider 2D, який об'єднує collider'и сусідніх тайлів в одну полігональну форму.

Дорогі MeshCollider'и. MeshCollider з Convex = false не бере участі в dynamic-to-dynamic колізіях—тільки static. Для довільних форм на динамічних об'єктах апроксимуйте примітивами: кілька BoxCollider/CapsuleCollider замість одного MeshCollider. Ручна робота, але скорочує навантаження broadphase в рази.

Матриця колізій за шарами

Перше, що налаштовуємо на будь-якому проекті—матриця шарів (Physics > Layer Collision Matrix). Типова помилка новачків—залишити всі шари взаємодіючими. З 5 типами об'єктів це 25 пар перевірок замість 6–8 реально потрібних.

Для мобільного це прямо впливає на broadphase (перша фаза виявлення колізій, де Unity відсіює непідходящі пари за AABB). Менше активних пар—менше роботи на кожний фізичний крок.

Кастомний collision detection для специфічних механік

Деякі жанри не потребують фізики рушія. Приклад: раннер, де потрібна тільки колізія персонажа з землею та перешкодами. Замість Rigidbody + Collider—використовуйте raycast-систему:

void CheckGround() {
    RaycastHit2D hit = Physics2D.Raycast(
        transform.position,
        Vector2.down,
        groundCheckDistance,
        groundLayer
    );
    isGrounded = hit.collider != null;
    if (isGrounded) groundNormal = hit.normal;
}

void CheckObstacles() {
    // BoxCast вперед по напрямку руху
    RaycastHit2D hit = Physics2D.BoxCast(
        transform.position,
        colliderSize,
        0f,
        Vector2.right,
        obstacleCheckDistance,
        obstacleLayer
    );
    if (hit.collider != null) OnObstacleHit(hit);
}

Легше, повністю детерміністична, дає прямий контроль над поведінкою. Без випадкових дзеркальних ефектів від solver-ітерацій.

Trigger vs Collision: коли що використовувати

OnTriggerEnter / OnCollisionEnter—фундаментальне розрізнення. Колізія—фізичне столкнення з імпульсом, trigger—логічне перекриття без фізики. Типова помилка: використовувати Collision там, де потрібен Trigger, додаючи зайвий Rigidbody та навантажуючи solver.

На Godot 4 аналогія: Area2D для trigger'ів та зон, CharacterBody2D.move_and_collide() / move_and_slide() для фізичних взаємодій. move_and_slide() автоматично ковзає по похилих поверхнях—те, що в Unity потребує ручної реалізації через нормаль поверхні.

Оптимізація на реальних пристроях

Профілювання в Unity Profiler (Deep Profile) на цільових пристроях обов'язково. Стежити за Physics.Processing та Physics2D.Processing в timeline. Типові винуватці просідання FPS:

• занадто малий Fixed Timestep (створює додаткові кроки на повільних кадрах)
• Rigidbody.interpolation = Interpolate на десятках об'єктів
• динамічні CompositeCollider2D з частими перебудовами геометрії

Тривалість розробки collision system: прості механіки—3–5 днів, складні (багатошарова геометрія, кастомний детектор, оптимізація під слабкі пристрої)—1–3 тижні. Вартість розраховується індивідуально.