Разработка мобильной хардкорной игры
Хардкорные мобильные игры — это самый технически требовательный сегмент мобильного гейминга. Аудитория знает, что такое input lag, требует честного хитбокса и замечает, когда анимация атаки на 2 фрейма длиннее, чем должна быть. Разработка под такую аудиторию — это постоянный компромисс между консольным качеством и ограничениями мобильного железа.
Главный враг хардкора — задержка ввода
На мобильных устройствах между касанием экрана и реакцией персонажа проходит минимум 1–2 фрейма из-за стека обработки тач-событий в OS. Если игра работает на 60fps, это 16–33ms только на уровне ОС. Добавляем время рендера — и уже 50–70ms. Для action-игр с parry-механикой или combo-системой это критично.
В Unity решение — Input System Package с InputAction.performed вместо устаревшего Input.GetKeyDown. Важно: подписка на performed в фиксированном Update (FixedUpdate) даёт стабильность физики, но увеличивает задержку. Для action-игр лучше обрабатывать ввод в Update с буферизацией команд на 3–5 фреймов (Input Buffering). Это стандартная техника из файтингов: команда «прыжок» остаётся валидной, если нажата за 3 фрейма до момента, когда прыжок технически возможен.
На Android дополнительная проблема — GameActivity vs NativeActivity. Использование GameActivity из Android Game Development Kit снижает overhead обработки тача через JNI. Разница на Snapdragon 8 Gen 2 — около 2ms, но в хардкоре это ощутимо.
Физика и коллизии — детали, которые ломают фил геймплея
Для хардкорных игр с point-precise геймплеем (платформеры, soulslike, roguelite с парированием) стандартный Unity Physics на основе PhysX не всегда подходит. PhysX использует discrete collision detection по умолчанию — при высоких скоростях тонкие объекты проходят сквозь друг друга (tunneling). Нужен Continuous Collision Detection (CCD) на Rigidbody, или переход на Unity Physics (DOTS) с детерминированными результатами.
Хитбоксы — отдельная тема. В хардкор-играх хитбокс атаки должен активироваться и деактивироваться в строго определённые фреймы анимации. Стандартный подход — Animation Events в AnimationClip. Проблема: события срабатывают в LateUpdate, после физического шага. Если у вас кастомный Animator Controller с AvatarMask и несколькими слоями, событие может сдвинуться на фрейм. Надёжнее — кастомный Frame Data в ScriptableObject: [AttackStart: frame 4, AttackEnd: frame 11] и ручная проверка animatorStateInfo.normalizedTime в FixedUpdate.
Рендер и производительность: 60fps на среднем Android
Целевая платформа для хардкора — mid-range Android (Snapdragon 7s Gen 2, Dimensity 7020) и iPhone 13+. Бюджет кадра на 60fps — 16.6ms. Типичное распределение:
| Система | Бюджет |
|---|---|
| CPU игровой логики | 3–4ms |
| Анимации (Animator + IK) | 2–3ms |
| Рендер (draw calls, culling) | 5–6ms |
| UI (Canvas rebuild) | 1–2ms |
| Запас / GC | 2ms |
Чтобы держаться в бюджете: URP (Universal Render Pipeline) вместо Built-in, GPU Instancing для повторяющихся мешей, Occlusion Culling для сложных уровней, Object Pooling для всего что спавнится — снаряды, эффекты, враги. GC-паузы от Instantiate/Destroy в бою — самая частая причина микрофризов на средних Android.
Для VFX — VFX Graph (работает на GPU) вместо Particle System (CPU). Разница на сцене с 500+ частицами — принципиальная. VFX Graph требует поддержки Compute Shader, что есть на всех устройствах с Vulkan/Metal поддержкой (Android 7+, iOS 12+).
Серверная валидация в PvP
Хардкор + PvP — обязательно серверная авторитарность, иначе читы неизбежны. Архитектура: Server Authoritative с клиентским предсказанием (Client-Side Prediction) и серверной коррекцией (Server Reconciliation). Для реализации: Photon Fusion в режиме Shared Mode для небольших лобби (2–8 игроков) или Fish-Net для большего контроля над серверной логикой.
Серверная часть на C# (Photon Cloud) или отдельный game server на Go/Rust для минимального latency. Детерминированная физика — обязательное условие для воспроизводимости матчей и защиты от desync.
Сроки
Хардкор-проект с нуля — от 8 до 18 месяцев. Прототип кор-механики — 4–8 недель. Это первое, что нужно сделать и протестировать: если core loop не «цепляет» на уровне ощущений на прототипе — финальный продукт не спасёт никакое количество контента.
Стоимость рассчитывается индивидуально после анализа механик, объёма контента и требований к мультиплееру.