Розробка мобільної аркадної гри
Аркади живуть за рахунок перших 30 секунд. Якщо в цей проміжок не виникає відчуття «ще раз» — гравець іде і не повертається. Ми вирішуємо це завдання технічно: миттєвий respawn, жодного loading screen перед першою сесією, чуйний ввід без затримок. Кожна мілісекунда затримки знижує retention на 5–10%. Ми проєктуємо геймплей так, щоб після першого дотику гравець не встигав ні про що думати — тільки реакція. Використовуємо Input System Package для усунення затримок на Android та iOS. На старті аналізуємо типові сценарії гри та виявляємо вузькі місця — від GC Allocs до перевантаження GPU. Тільки після цього приступаємо до прототипування. Особливу увагу приділяємо першим двом рівням — вони навчають механікам і формують звичку. Наш досвід — 5 років у mobile game dev, 50+ випущених проєктів із загальною кількістю встановлень понад 2 мільйони.
Як забезпечити 60fps на бюджетних пристроях?
Аркадний геймплей вимагає стабільних 60fps. Просадка до 45fps на двох фреймах сприймається як баг, а не як норма. У Unity це означає:
- Object Pooling для всього динамічного (снаряди, монети, вороги, ефекти) — пул заздалегідь створює 20–50 об'єктів і перевикористовує їх, уникаючи GC Alloc. Object Pooling скорочує час кадру вдвічі порівняно з динамічним створенням.
- Static Batching для нерухомих елементів рівня. Якщо рівень процедурно генерується — об'єднуємо статику під час завантаження сцени.
- Single Canvas для ігрового HUD з
Canvas.renderMode = RenderMode.ScreenSpaceOverlay. Перестворення Canvas при кожній зміні UI вбиває продуктивність через dirty rebuild.
Для тач-керування — Input System Package з EnhancedTouch.Enable() та Touch.activeTouches замість старого Input.touches. Це прибирає overhead одного додаткового marshaling'а через JNI на Android. В одному проєкті ми зіткнулися з просадками на Samsung Galaxy A50: споживання CPU підскочило на 12% через Input.touches. Після переходу на Input System проблема зникла, а час кадру знизився з 18ms до 14ms. Як згадується в офіційній документації Unity, Input System — рекомендований спосіб обробки вводу.
Типові проблеми та рішення
| Проблема | Симптом | Рішення |
|---|---|---|
| GC Spike при спавні ворогів | Фриз на 100–200мс | Object Pooling + ручна деалокація через DestroyImmediate |
| Перевантаження GPU на сценах з ефектами | FPS падає до 20 | Particle System з MaxParticles 200, вимкнути Collision |
| Затримка вводу на Android | Відгук не миттєвий | Input System + EnhancedTouch, відмова від EventSystem update |
Як інтегрувати рекламу без втрати користувачів?
Реклама — основне джерело доходу в аркадах, але недоречний показ вбиває retention. Rewarded ads (винагорода за перегляд) працюють у 3–4 рази краще interstitials, якщо показувати їх у момент програшу. Interstitials — тільки між рівнями, з таймером не менше 30 секунд. Використовуємо AppLovin MAX для mediation — він автоматично обирає сітку з найбільшим eCPM. Налаштування A/B-тестів за часом показу обов'язкове: на одному з проєктів перенесення rewarded ads з початку рівня на екран смерті збільшив CTR з 12% до 38%.
| Тип реклами | Місце показу | CTR (типовий) |
|---|---|---|
| Rewarded | Після смерті | 35–50% |
| Interstitial | Між рівнями | 10–15% |
Чому leaderboards недостатньо для утримання?
Leaderboards — це база, але віральність будується на deep link на конкретний рахунок. Коли гравець публікує рекорд у соцмережу, посилання має відкривати гру одразу на екрані «побий мій рекорд». Firebase Dynamic Links генерує коротке посилання з OG-прев'ю (рахунок, аватар). На iOS — Universal Links, на Android — App Links. Без цього ваш leaderboard — просто список чисел, а не інструмент залучення.
Як ми це робимо: процес роботи
- Аналітика та прототип — 2–3 тижні, створюємо мінімальну аркаду з однією механікою. Тестуємо на 10 користувачах, перевіряємо retention Day1.
- Проєктування — дизайн рівнів, звуків, таблиці leaderboard. Інтегруємо Google Play Games Services та Game Center.
- Реалізація — повний цикл механік, оптимальний рендеринг, налаштування Input System, Object Pooling.
- Монетизація — Rewarded ads через AppLovin MAX та In-app purchases (StoreKit 2 / Billing 6). Rewarded ads показуємо тільки після програшу — CTR 35–50% проти 10–15% у меню.
- Тестування — на 20+ реальних пристроях, перевірка fps, витрати батареї, крашів.
- Деплой та підтримка — публікація в App Store та Google Play, моніторинг crash reports.
Що входить у роботу
Ми передаємо:
- Вихідні коди Unity з коментарями (C#)
- Налаштовані пайплайни збірки (iOS/Android)
- Документацію з конфігурації реклами та leaderboard
- Доступи до Google Play Console та App Store Connect
- Навчання команди замовника (1–3 години)
- Гарантію 30 днів на виправлення критичних багів
Приклад налаштування Object Pooling
```csharp public class ObjectPool : MonoBehaviour { [SerializeField] private GameObject prefab; private Queuepublic GameObject Get() { if (pool.Count == 0) return Instantiate(prefab); var obj = pool.Dequeue(); obj.SetActive(true); return obj; } public void Return(GameObject obj) { obj.SetActive(false); pool.Enqueue(obj); } }
</details>
## Строки та вартість
Прототип — 2–3 тижні, повноцінна аркада з 5–7 механіками, leaderboards, монетизацією — 2–4 місяці. Вартість розраховується індивідуально після оцінки обсягу — зв'яжіться, щоб отримати точне комерційне пропозиція. Отримайте консультацію по вашому проєкту вже сьогодні.
Ми гарантуємо стабільні 60fps на пристроях середнього сегменту та дотримання App Store Review Guidelines (Section 4.2/5.1). Замовте розробку аркади під ключ — оцінимо проєкт за 2 дні.