Розробка фізичного рушія взаємодій мобільної гри

Розробка фізичного рушія взаємодій мобільної гри

На мобільних пристроях фізика—найдорожче в бюджеті CPU. Повна симуляція PhysX або Bullet при 120 Гц на Snapdragon 680 закінчується дросселюванням на третій хвилині сесії. Мобільна ігрова фізика—це завжди компроміс між точністю та продуктивністю, і пошук правильного балансу для конкретного жанру—нетривіальне завдання.

Архітектура фізики під мобільний бюджет

Фіксований timestep та його вартість

Unity оновлює фізику в FixedUpdate з інтервалом Time.fixedDeltaTime (за замовчуванням 50 Гц). На мобільному пристрої, що працює при 30 FPS, це означає два фізичні кроки на кадр. Якщо гра впадає до 20 FPS через тепловий дросель, Unity виконує 2–3 кроки PhysX за один відрендерений кадр—навантаження на CPU зростає нелінійно.

Оптимальна стратегія: зменшити Fixed Timestep до 0.033 (30 Гц) для мобільних білдів та компенсувати більш точними collider'ами. Для ігор, де фізика не критична для геймплею (паззли, hyper-casual), опустити до 0.05 (20 Гц) та компенсувати візуально через Rigidbody.interpolation = RigidbodyInterpolation.Interpolate.

Коли PhysX надлишковий

Для 2D-ігор в Unity вбудована Box2D фізика (Rigidbody2D, Physics2D) значно легша, ніж PhysX. Але навіть Box2D борсться зі 100+ динамічними об'єктами на CPU. В Godot 4, RigidBody2D + GodotPhysics2D більш ефективна, ніж 3D-фізика для плоских ігор.

Для hyper-casual та аркадних механік часто вигідно повністю відмовитися від фізики рушія та написати детерміновану фізику вручну:

// Спрощена фізика стрибка без 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;
    }
}

Детерміністична фізика, написана вручну, передбачувана, дебажиться одним кліком та працює однаково на будь-якому пристрої. Для багатокористувацьких ігор це гарантія синхронізації станів.

Взаємодія об'єктів: де зазвичай все ломається

Стекування об'єктів

PhysX погано симулює стопки з 10+ динамічних об'єктів на мобільному залізі—починається дзеркалення та об'єкти «проваліються» один крізь одного. Рішення: знизити Rigidbody.maxDepenetrationVelocity до 1–3 м/с (за замовчуванням 10), Physics.defaultSolverIterations до 4–6 (за замовчуванням 6), Physics.defaultSolverVelocityIterations до 1.

Тонкі collider'и та туннелювання

Швидкі об'єкти—кулі, снаряди—при низькому FPS можуть пролетіти крізь тонку стіну за один фізичний крок. Rigidbody.collisionDetectionMode = CollisionDetectionMode.ContinuousDynamic вирішує, але коштує вдвічі дорожче на CPU. Альтернатива: для снарядів використовуйте raycast замість фізики—Physics.SphereCast з радіусом снаряда від попередньої позиції до поточної.

Продуктивність на різних пристроях

Реальні дані профайлера (Unity Profiler + Android Profiler) з проекту з 3D-аркадою (80 фізичних об'єктів, Snapdragon 665):

Кастомна фізика—жанр-специфічна, не універсальна. Але коли механіка гри це дозволяє, виграш очевидний.

Фізика в React Native іграх (Flame/Godot export)

Для React Native-ігор пишіть на Godot з Web/Android export або через рушій JavaScript (Phaser.js через WebView). Phaser використовує Matter.js для 2D-фізики—легше, ніж Box2D за пам'яттю, але менш точна. Matter.Runner.run() з fps: 30 на більшості Android-бюджетників достатньо.

Для Flutter + flame: forge2d (Dart-порт Box2D) дає повну 2D-фізику. World.stepDt запускається в game.update(dt), частота оновлень контролюється ігровим циклом flame. Критично: forge2d працює в метрах, flame—в пікселях. Коефіцієнт масштабу (worldScale) повинен бути встановлений один раз та дотриманий послідовно.

Процес розробки

Почніть з профілювання цільових пристроїв—бюджетний Android та флагман iPhone дають різну картину. Виберіть фізичний рушій або кастомну реалізацію на основі жанру, кількості об'єктів та цільового FPS. Реалізуйте фізичні взаємодії, профілюйте в реальних умовах (throttle mode, без зарядки), ітеруйте.

Типові тривалості: базові фізичні взаємодії—1–2 тижні, складні системи (зруйновані об'єкти, м'які тіла, fluid simulation)—3–6 тижнів. Вартість розраховується індивідуально після аналізу механік.