Розробка мобільної мідкорної гри

Розробка мобільної мідкорної гри

Мідкор — це зона максимального інженерного напруження в мобільному гейминзі. З одного боку клієнт очікує мета-слій: прокачку, гільдії, сезонний пропуск, PvP-ліги. З іншого — це все має працювати на Unity 2022 LTS на Snapdragon 680 без просадок FPS та з холодним стартом до 4 секунд. Казуальні рішення не масштабуються, AAA-архітектура надлишкова. Потрібно проектувати систему, що растує разом з монетизацією, не ломаючись при додаванні нового контенту.

Де мідкор-проекти ломаються частіше за все

Найчастіша точка сбою — система прогресії, спроектована як Excel-таблиця, а не як код. Баланс записаний у ScriptableObject або локальний JSON, гра запускається — через три місяці з'ясовується, що додати новий тип юнита неможливо без переписування чотирьох систем. Бачили проекти, де UnitConfig містив 47 boolean-флагів та вся логіка вистраювалася через if (isElite && hasBuff && !isFrozen). Це не працює при 200 типах юнітів.

Другий болевий узел — сітьовий шар у PvP та кооперативі. Використання простого HTTP REST для боєвих дій у реальному часі приводить до того, що на затримці 150ms клієнт та сервер розходяться на 3-4 кроки. Клієнтський prediction без серверної валідації — чити. Серверна валідація без rollback — дёрганне. Потрібен або Photon Fusion з його state synchronization, або власна реалізація на Mirror з детермінованою фізикою (Deterministic Lockstep), де обидва клієнти відтворюють одні й ті ж команди в одному й тому ж порядку.

Третя проблема — пам'ять. Unity Addressables з неправильно налаштованими групами приводить до того, що при завантаженні нового чаптера вся попередня сцена залишається в пам'яті. На iPhone 12 це ще терпимо. На Android low-end з 2GB RAM — OOM та вилет. Потрібно явне управління lifecycle через Addressables.ReleaseInstance та правильна розбивка на bundle: UI-атласи окремо, персонажи окремо, окружение окремо.

Як строїться архітектура мідкор-гри

Для мідкор-проектів використовуємо Entity Component System (ECS) через Unity DOTS або Arch для ігрової симуляції та окремий шар MonoBehaviour для UI та візуального представлення. Ігрова логіка (статы, баффи, АІ, фізика снарядів) працює в ECS — це дає детермінізм та продуктивність на job threads. Все що стосується Canvas, Animator, VFX — залишається в Mono.

Мета-шар (інвентар, прокачка, соціалка) строїться як окремий домен з чіткими межами. Типова структура:

GameCore/
  ECS/          -- боєва симуляція (DOTS)
  Systems/      -- GameplayLoop, SpawnSystem, CombatSystem
  Data/         -- ScriptableObject конфіги + remote config через Firebase
Meta/
  Inventory/
  Progression/  -- XP, рівні, розблокування
  Social/       -- гільдії, лідерборди (Google Play Games SDK / GameKit)
Network/
  Photon/       -- реалтайм PvP
  REST/         -- мета-операції (покупки, збереження)

Remote Config через Firebase — обов'язковий компонент для балансу. Всі числові параметри: урон, стоимість апгрейду, ймовірності дропа — мають лежати в Remote Config, а не в білді. Це дозволяє патчити баланс без оновлення в стор.

Монетизація: Unity IAP для внутрішніх покупок + ironSource або AppLovin MAX для реклами з медіацією. Важливо: на iOS потрібно обробляти SKPaymentTransactionObserver правильно — pending transactions при перериваному інтернеті мають відновлюватися при наступному запуску, інакше Apple може відклонити застосунок за гайдлайном 3.1.1.

Кейс: бій з 50v50 та перегрів рендерера

На одному з проектів — мідкор-стратегія з боями 50v50 — на бюджетних Android-пристроях CPU перегрівався через 8 хвилин безперервного бою. Profiler показав: 6ms за кадр уходило на SkinnedMeshRenderer.Update для 100 юнітів одночасно. Рішення — GPU Instancing для статичних мешей + заміна Skinned Mesh на GPU skinning через Compute Shader для дальніх юнітів (дистанція > 15 одиниць). Близькі юніти — нормальний скінд меш. Далекі — billboard або упрощена анімація через vertex shader. В результаті CPU час рендеру упав з 6ms до 1.8ms, температура стабілізувалася.

Терміни та процес

Мідкор-гра з нуля — це проект на 6–14 місяців залежно від обсягу мета-систем та контенту.

Оцінка вартості — після аналізу ГДД та технічних вимог. Особливо важливо зрозуміти обсяг мультиплеєра: PvP у реальному часі або асинхронний — різниця в трудоємності істотна.

Типові помилки, які дорого обходяться

• Зберігання через PlayerPrefs для критичних даних прогресії. PlayerPrefs не атомарний — при крешу між записами можна втратити стан. Потрібен або Cloud Save (Play Games SDK, Game Center), або власний сервер з idempotent-операціями.
• Відсутність аналітики з першого дня. Firebase Analytics або GameAnalytics потрібно підключати до soft launch, інакше нема baseline для D1/D7/D30 retention.
• Хардкод локалізації. Якщо тексти вшиті в код, додати новий язик — біль. Використовуйте Unity Localization Package з LocalizedString та таблицями.
• Одна сборка під всі платформи. У iOS та Android розні вимоги до текстурного стиснення (ASTC vs ETC2), розні обмеження по пам'яті та розні стор-гайдлайни. Scripting Define Symbols та Platform-specific Asset Variants — не опція, а обов'язковість.