Розробка складної мобільної гри (Hardcore)
Складні мобільні ігри — найбільш технічно вимогливий сегмент мобільного гейминга. Ваша аудиторія розуміється на затримці вводу, вимагає чесних hitbox'ів та помічає, коли анімація атаки розтягується на 2 фрейми довше за потрібне. Розробка для такої аудиторії — постійний компроміс між консольною якістю та обмеженнями мобільного залізо.
Головний ворог складного геймплею: затримка вводу
На мобільних пристроях між торканням екрана та реакцією персонажа проходить мінімум 1–2 фрейма через стек обробки touch-подій ОС. При 60fps це 16–33ms лише на рівні ОС. Додаємо час рендерингу — вже 50–70ms. Для action-ігор з parry-механікою або combo-системами це критично важливо.
У Unity рішення — Input System Package з InputAction.performed замість застарілого Input.GetKeyDown. Важливо: підписання на performed у фіксованому Update (FixedUpdate) дає стабільність фізики, але збільшує затримку. Для action-ігор краще обробляти ввід у Update з буферизацією команд на 3–5 фреймів (Input Buffering). Це стандартна техніка з файтингів: команда «стрибок» залишається валідною, якщо натиснута за 3 фрейма до того, як стрибок технічно можливий.
На Android є додаткова проблема — GameActivity vs NativeActivity. Використання GameActivity з Android Game Development Kit зменшує overhead обробки дотику через JNI. Різниця на Snapdragon 8 Gen 2 — близько 2ms, але в складному геймплеї це помітно.
Фізика та колізії: деталі, які руйнують відчуття геймплею
Для складних ігор з point-precise геймплеєм (платформери, soulslikes, roguelites з парируванням) стандартна Unity Physics на базі PhysX не завжди підходить. PhysX використовує дискретне обнаруження колізій за замовчуванням — при високих швидкостях тонкі об'єкти проходять крізь один одного (tunneling). Вам потрібно Continuous Collision Detection (CCD) на Rigidbody, або перехід на Unity Physics (DOTS) з детермінованими результатами.
Hitbox'и — окремна тема. У складних іграх hitbox атаки повинен активуватися та деактиватися на строго визначених фреймах анімації. Стандартний підхід використовує Animation Events у AnimationClip. Проблема: події спрацьовують у LateUpdate, після фізичного кроку. Якщо у вас користувацький Animator Controller з AvatarMask та кількома шарами, подія може зміститися на один фрейм. Надійніше: користувацький Frame Data у ScriptableObject: [AttackStart: frame 4, AttackEnd: frame 11] та ручна перевірка animatorStateInfo.normalizedTime у FixedUpdate.
Рендеринг та продуктивність: 60fps на середньому Android
Цільова платформа для складних ігор: середній Android (Snapdragon 7s Gen 2, Dimensity 7020) та iPhone 13+. Бюджет кадру при 60fps — 16.6ms. Типовий розподіл:
| Система | Бюджет |
|---|---|
| CPU ігрової логіки | 3–4ms |
| Анімації (Animator + IK) | 2–3ms |
| Рендеринг (draw calls, culling) | 5–6ms |
| UI (Canvas rebuild) | 1–2ms |
| Резерв / GC | 2ms |
Щоб залишатися в бюджеті: URP (Universal Render Pipeline) замість Built-in, GPU Instancing для повторюваних mesh'ів, Occlusion Culling для складних рівнів, Object Pooling для всього, що спавниться — снаряди, ефекти, враги. GC-паузи від Instantiate/Destroy у бою — найчастіша причина мікрофризів на середньому Android.
Для VFX: VFX Graph (працює на GPU) замість Particle System (CPU). Різниця на сценах з 500+ частинками — суттєва. VFX Graph вимагає підтримки Compute Shader, яка доступна на всіх пристроях з Vulkan/Metal підтримкою (Android 7+, iOS 12+).
Серверна валідація у PvP
Складна гра + PvP вимагає обов'язкової серверної авторитетності, інакше чити неминучі. Архітектура: Server Authoritative з клієнтським прогнозуванням (Client-Side Prediction) та серверною корекцією (Server Reconciliation). Для реалізації: Photon Fusion у режимі Shared Mode для невеликих лоббі (2–8 гравців) або Fish-Net для більшого контролю серверної логіки.
Серверна частина на C# (Photon Cloud) або окремий game server на Go/Rust для мінімальної затримки. Детермінована фізика — обов'язкова умова для відтворюваності матчів та захисту від desync.
Графік
Проект складної гри з нуля: від 8 до 18 місяців. Прототип кор-механіки: 4–8 тижнів. Це перша річ, яку потрібно зробити та протестувати: якщо core loop не «цепляє» на рівні відчуттів у прототипі — ніякий контент не спасе кінцевий продукт.
Вартість розраховується індивідуально після аналізу механік, обсягу контенту та вимог до мультиплеєра.