Розробка мобільної гри на Unity
Unity — найпоширеніша платформа для мобільних ігор. Не тому що найшвидша або найдешевша у розробці, а тому що Asset Store, величезна екосистема плагінів і C# — мова, яку знає більшість розробників. Це знижує порог входу та час на прототип. Але мобільний Unity у продакшні — це постійна боротьба з пам'яттю, батареєю та перегріванням пристрою.
Архітектура проекту
Для мобільних ігор середної складності використовуємо MVVM + Services без повноцінного ECS. Unity DOTS (Entity Component System) дає максимальну продуктивність, але потребує досвіду роботи з Burst Compiler, Jobs System та NativeArray — overkill для більшості мобільних проектів до аркадного жанру включно.
Управління станом через Zenject (DI-контейнер) або VContainer (більш легкий аналог). Це дає тестовану архітектуру: кожен сервіс (AudioService, ScoreService, InventoryService) інжектується через конструктор, а не FindObjectOfType.
ScriptableObjects для конфігурації ігрових даних — рівні, характеристики ворогів, параметри прогресії. Змінення балансу без пересборки APK/IPA через Addressables + remote config (Firebase Remote Config або Unity Remote Config).
Продуктивність — головний виклик на мобільних
Draw calls та батчинг. На мобільних GPU бюджет draw calls жорсткий: 100–200 залежно від пристрою. Статична геометрія — Static Batching. Однакові матеріали — GPU Instancing. Динамічні об'єкти — Dynamic Batching (працює для меш-об'єктів < 900 вершин). Перевіряємо через Frame Debugger в Unity Editor.
Текстури та пам'ять. ASTC — формат стиснення для iOS та Mali/Adreno на Android. Ніяких PNG 2048×2048 для UI-іконок розміром 64×64. Atlases через Sprite Atlas (Unity 2D) або ручну упаковку. Моніторинг пам'яті — Memory Profiler (пакет com.unity.memoryprofiler). Типова проблема на iOS: Texture2D не виконується з пам'яті після Destroy() без явного Resources.UnloadUnusedAssets().
Object Pooling. Instantiate/Destroy на гарячому шляху — враг продуктивності. UnityEngine.Pool.ObjectPool<T> (Unity 2021.1+) — вбудований пул. Пулі, враги, частинки — все через пул.
IL2CPP та AOT. Мобільні білди завжди IL2CPP, не Mono. Рефлексія ломає strip level: якщо ReflectionProbe або кастомний сериалізатор використовує рефлексію — додаємо link.xml з явними preserve-директивами. Інакше MissingMethodException у релізному білді, якого не було в Debug.
Інтеграції для мобільного продакшену
Ads. Google AdMob через com.google.ads.mobile — банери, інтерстиці, rewarded video. Unity Ads як альтернатива. Mediation через IronSource або AppLovin MAX для максимізації eCPM.
In-App Purchases. Unity IAP (пакет com.unity.purchasing) — єдиний API для App Store та Google Play. StoreKit на iOS, Google Play Billing на Android. Валідація чеків на сервері обов'язкова — клієнтська валідація обходиться Jailbreak/Root.
Analytics. Firebase Analytics (com.google.firebase.analytics) — стандарт. Ключові події: level_start, level_end, level_fail, ad_impression, iap_purchase. Unity Analytics як вбудована альтернатива.
Crashlytics. Firebase Crashlytics — звіти про краші в реальному часі. Інтегрується через com.google.firebase.crashlytics. Кастомні ключі для контексту: Crashlytics.SetCustomKey("level", currentLevel).
CI/CD та публікація
Fastlane для автоматизації: gym для iOS-білда, supply для завантаження в Google Play, deliver для App Store. Unity Build Automation (Cloud Build) як альтернатива для команд без налаштованого CI.
GitHub Actions + game-ci/unity-builder — безплатна CI для Unity з кешуванням Library-папки (економить 10–30 хвилин на кожен білд).
App size. APK split за ABI — окремі файли для arm64-v8a, armeabi-v7a, x86_64. На iOS — App Thinning автоматично через Xcode. Asset Bundle Compression — LZ4 для швидкої завантаження, LZMA для мінімального розміру.
Етапи розробки
Прототип (core gameplay loop) → вертикальний срез (один рівень з повним контентом) → alpha (всі механіки, без полірування) → beta (тестування на пристроях, оптимізація) → релиз.
Між alpha та beta — обов'язковий профайлінг на реальному залізі: старий Android (Snapdragon 660, Mali G72) та iPhone SE 2nd gen. Якщо на цих пристроях стабільні 30 FPS — продукт готовий до широкої аудиторії.
Терміни
| Тип гри | Команда | Орієнтир |
|---|---|---|
| Гіперказуальна / казуальна | 2–3 людини | 2–4 місяці |
| Мідкор (RPG, стратегія) | 4–6 людей | 6–12 місяців |
| Зі складними механіками, сітьовим мультиплеєром | 6+ людей | 12+ місяців |
Вартість розраховується після аналізу GDD (Game Design Document) та технічних вимог до платформ.