Падіння проекту на iPhone 11 після 10 секунд геймплею — знайома проблема. Завантаження текстур під 800 MB — не рідкість, а тепловий тротлінг перетворює перший рівень на слайд-шоу. Ми пропонуємо розробку мобільних ігор під ключ з фокусом на продуктивність. Більше 5 років у геймдеві, сертифікація Unity та Unreal Engine, сотня оптимізованих проектів. Вибір ігрового движка — Unity або Unreal — визначає подальшу оптимізацію. Оптимізація мобільної гри під різні платформи — ключове завдання. Гарантуємо стабільні 60 FPS на пристроях від бюджетних до флагманських. Зв'яжіться з нами для оцінки вашого проекту.
Чому мобільні ігри розвалюються технічно?
Тепловий тротлінг — невидима стіна
Snapdragon 778G тримає стабільні 60 FPS перші 10 хвилин. Потім CPU/GPU перегріваються, система знижує частоту до 50–60% від піку. Користувач не розуміє причину і видаляє гру. Тест на тротлінг — обов'язкова частина QA: 30 хвилин геймплею з моніторингом через Android GPU Inspector або Snapdragon Profiler. Якщо температура перевищує 45°C — гра перегріває пристрій. На Samsung Galaxy A52 після 15 хвилин температура піднімається до 47°C — ми економимо батарею автоматичним зниженням деталізації. Рішення: обмеження цільового FPS (Application.targetFrameRate = 30), Adaptive Performance (підтримується Samsung), агресивний батчинг. Використання Adaptive Performance знижує кількість тротлінгових подій у 2 рази порівняно зі звичайною реалізацією.
Memory management на iOS
На iOS немає свопу. Коли додаток перевищує бюджет (від 1.2 ГБ на старих iPhone до 4+ ГБ на Pro), система вбиває його без попередження. Кожна iOS гра повинна проходити тестування в Xcode Instruments. Підписуємося на Application.lowMemory і негайно вивантажуємо некритичні асети. Addressables.Release() для всього, що не потрібно прямо зараз. Профілювання — тільки через Xcode Instruments (Memory Graph).
Специфіка фрагментації Android
4000+ моделей Android в обігу. Мінімальний набір тестових пристроїв: Samsung mid-range (Android 12+), застарілий Xiaomi (Android 10, Mali), сучасний Pixel, бюджетник з 2 ГБ RAM. Vulkan доступний з Android 7.0+, але реалізації різняться.
Як мобільний game loop адаптований під короткі сесії?
Сесія 3–7 хвилин — дизайн-патерн. Гра повинна завершуватися за одну сесію або коректно зберігати прогрес. OnApplicationPause(true) — точка збереження. Автозбереження кожні N секунд через coroutine з yield. Не використовуйте синхронний save в OnApplicationPause.
Що входить в роботу по розробці гри?
Ми надаємо повний цикл: аналітика → проектування → прототип → реалізація → QA → публікація. Включаємо навчання вашої команди, документацію, доступи до репозиторію та післярелізну підтримку. Оптимізація може скоротити витрати на інфраструктуру на 20–40%. Замовте консультацію — ми підготуємо оцінку. Отримайте безкоштовний аудит продуктивності вашої гри — ми покажемо, які вузькі місця можна усунути.
Touch controls
Unity Input System з Touchscreen device. Для свайпів — GestureDetector на InputSystem з threshold. Розміри touch targets: мінімум 48×48 dp (Google guidelines), оптимум 56×56 dp. Multi-touch: явно вказуємо максимальну кількість дотиків. Обробка жестів — через InputSystem.onEvent.
Оптимізація асетів
Текстури: ASTC 6×6 для iOS (Metal), ETC2 для Android. Атласи через Sprite Atlas. Меші більше 65k вершин — розбиваємо (Unity використовує 16-bit index buffer за замовчуванням на мобайлі, можна ввімкнути 32-bit). Аудіо: PCM → MP3 (Android) або AAC (iOS). Частота 22050 Гц достатня для більшості sound effects. Додаємо MIP maps для всіх 3D-текстур — інакше драйвер генерує найближчу, знижуючи якість. Використання Addressables замість прямих посилань знижує пікове споживання пам'яті на 30%.
Як ми досягаємо стабільних 60 FPS: покроковий процес
- Профілювання: Frame Debugger, Unity Profiler, Instruments, Android GPU Inspector.
- Оптимізація: SRP batcher, static batching, LOD, occlusion culling.
- Тест на тротлінг: 30 хвилин на 3+ пристроях.
- Зниження draw calls до 100–150 на кадр.
- Перевірка пам'яті: виключаємо витоки через Memory Profiler.
| Платформа |
Особливості оптимізації |
| iOS |
Memory budget, Metal, ASTC, Touch ID, Game Center |
| Android |
Vulkan/GLES, фрагментація, Adaptive Performance, 4000+ моделей |
Стек мобільного проекту
Бекенд: PlayFab (рекомендуємо) або Firebase. Аналітика: Firebase Analytics + AppsFlyer для attribution. Монетизація: Unity IAP + IronSource/AppLovin MAX (медіація підвищує eCPM на 20–40%). Push: Firebase Cloud Messaging. CI/CD: Unity Cloud Build + fastlane (iOS) + GitHub Actions (Android).
Реліз та після релізу
Soft launch (обмежений регіон) обов'язковий. Метрики для go/no-go: D1 retention >40%, D7 >20%, D30 >10%. Вартість розраховується індивідуально після аналізу механік. Замовте консультацію — ми підготуємо оцінку.
| Тип гри |
Орієнтовні терміни |
| Гіпер-казуальна |
4–8 тижнів |
| Казуальна з прогресією |
2–4 місяці |
| Мідкор (мета + PvP) |
4–8 місяців |
| Мідкор з guild/clan |
6–12 місяців |
Типові помилки при завантаженні асетів
- Завантаження всіх текстур одразу (потрібні Addressables з чанками).
- Невикористання MIP map (драйвер генерує найближчу, знижуючи якість).
- Відсутність асинхронного завантаження для UI.
- Синхронне завантаження на головному потоці викликає stutter.
Проектування механік: з чого починається чуйне керування
Перш ніж говорити про геймдизайн, зафіксуємо розмежування: геймдизайн — це не «придумати ідею». Придумати може будь-хто. Завдання — спроектувати систему правил, яка виробляє конкретний емоційний та поведінковий результат. Це інженерна дисципліна, тільки замість компілятора — людський мозок.
Перший біль: вам здається, що керування «дубове», а чому — незрозуміло. Найчастіше проблема не в коді, а у відсутності coyote time та jump buffering. Наприклад, у платформерах без coyote time гравець програє 20% спроб через відчуття «нечесної» смерті. Або в лінійному прискоренні, яке не дає відчуття ваги — замінюємо на криву початкового ривка з подальшим загасанням. Ми це виправляємо на етапі прототипу, скорочуючи подальші правки на 40%.
Окрема категорія — економіка. Без попередньої математичної моделі розвал настає через місяць після релізу. Тому ми починаємо з прогресії: лінійна, експоненціальна або поліноміальна. Наприклад, для RPG використовуємо поліном a * n^b з b=2.0, перевіряючи, скільки годин гравець витратить на кожен рівень. Це дає прогнозований час гри і дозволяє уникнути дисбалансу монетизації.
Які послуги з геймдизайну ми пропонуємо?
Повний цикл: від концепту до вивіреного білду. Під ключ — ви отримуєте геймдизайн-документ (GDD), таблиці балансу, прототип ключових механік на Unity/Unreal, і супровід аж до релізу. Гарантія якості — покрокове узгодження на етапі прототипу, щоб уникнути переробок.
Що входить в роботу (deliverables):
- Документація: GDD, специфікації механік, наративні дерева, API для розробників
- Таблиці балансу: прогресія, економіка, DPS-калькулятори
- Прототипи: інтерактивні сцени з core loop (рух, бій, інвентар)
- Конфігурація в рушії: ScriptableObject, DataTable, анімаційні події
- Проведення плейтестів та ітерацій за метриками (утримання, монетизація, retention)
Оцініть ваш проект — зв'яжіться для розрахунку термінів. Підхід заснований на методології MDA та досвіді 50+ реалізованих проектів, більше 10 років на ринку. Наші замовники економлять від 2 до 3 тижнів на ітераціях завдяки чіткому процесу.
Як спроектувати бойову систему без помилок?
Бойова система — найдорожча помилка: на перший погляд проста, на ділі — пекло з edge cases. Розберемо melee combat.
Вибір методу hit detection
Hitbox — колайдери на зброї. Просто, але при швидких атаках виникає tunneling: зброя пролітає крізь противника за кадр. Рішення — Physics.CCD (Continuous Collision Detection), але це дорого. Raycast/spherecast — кастуємо промені вздовж траєкторії зброї. Точніше, менше залежить від fps. Ми віддаємо перевагу spherecast для action-ігор. Докладніше про методи — у статті про виявлення зіткнень.
Налаштування вікон атаки
Кожна атака — три фази: Startup, Active, Recovery. Довгий startup створює «важкі» удари. Короткий recovery дає агресивний стиль. В Unity аніматор кидає подію через AnimationEvent, код вмикає/вимикає hitbox. Типові таймінги для рукопашного бою: startup 200–400 мс, active 100–150 мс, recovery 300–500 мс. Зміна startup з 400 на 250 мс змінює відчуття з «важкий» на «середній» — це фіксується в метриках.
Побудова state machine
Персонаж — скінченний автомат. Базові стани: Idle, Moving, Jumping, Attacking, Hurt, Dead. Бізнес-логіку виносимо в C#-код, аніматор відповідає лише за переходи анімацій. Ієрархічні state machine (через Override Animator Controller) дозволяють вкладені підстани, не дублюючи переходи.
Чому математична модель економіки критична?
Економіку «на око» не роблять — виходить розвал через місяць після релізу. Базова прогресія: лінійна (нудно), експоненціальна (XP(n) = base * multiplier^n, multiplier 1.5–2.0), поліноміальна (a * n^b, b 1.5–2.5). Ми будуємо таблиці в Google Sheets за 2–3 дні, перевіряючи, скільки годин гравець витратить на кожен рівень.
Потоки валют
Принцип: кожна валюта — явне джерело (tap) і стік (sink). Приклад двовалютної системи:
|
М'яка валюта (золото) |
Тверда валюта (кристали) |
| Джерело |
Квести, вороги, щоденні нагороди |
Покупка, рідкісні досягнення |
| Стік |
Витратні матеріали, покращення, будівлі |
Пропуск часу, рідкісні предмети |
| Конвертація |
→ кристали: ні |
→ золото: так (однонаправлено) |
Однонаправлена конвертація захищає монетизацію. Дисбаланс легко виявити за DPS і TTK: якщо TTK зброї вдвічі нижче за інші — воно стає meta. Ми виявляємо це на етапі прототипу, скорочуючи наступні правки на 40%.
Наратив та левел-дизайн: як навчати без тексту?
Environmental storytelling — розташування об'єктів, звуків, слідів — часто ефективніше за діалоги. Для діалогів використовуємо Ink (інтеграція з Unity). Ink-скрипти читає наративний дизайнер без програміста. Кожен рівень перевіряємо за принципом: гравець повинен зрозуміти механіку дією, а не за підказкою.
Інструменти в процесі
| Завдання |
Інструмент |
| GDD |
Notion, Confluence |
| Баланс |
Google Sheets (формули, зведені) |
| Прототипи |
Unity 2022 LTS, Godot 4 |
| State machine |
Miro, draw.io |
| Наратив |
Ink, Twine |
| Конфіги |
ScriptableObject (Unity) |
| Аналітика |
Firebase, GameAnalytics |
Ітерація та плейтестинг: 2-тижневий цикл
Перший прототип завжди незручний — це норма. Наш цикл: плейтест кожні 2 тижні. Після — список змін з числами: «startup 400 мс → 250 мс». Думки без чисел не приймаються. Фіксуємо відчуття, змінюємо числа, повторюємо. Завдяки цьому середня економія бюджету на етапі ітерацій становить 15–20%.
Зв'яжіться для консультації — ми оцінимо терміни та бюджет вашого проекту. Отримайте прототип core loop за 3 тижні. Сертифіковані фахівці Unity/Unreal гарантують дотримання термінів.
