Разработка мобильной мидкорной игры

Разработка мобильной мидкорной игры

Мидкор — это зона максимального инженерного напряжения в мобильном гейминге. С одной стороны клиент ждёт мета-слой: прокачку, гильдии, сезонный пропуск, 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 — на бюджетных 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 — не опция, а обязательность.