Профессиональная разработка на Unity: оптимизация, мультиплеер, ECS

Разработка игр на Unity

Мы — команда инженеров с 8-летним опытом в геймдеве, выполнили более 20 проектов на Unity. Проект уже на середине пути, а сцены не собираются в билд без ошибок компилятора, AssetBundle-кэш разбух до 4 ГБ, а на целевом Android-устройстве URP рендерит 8 FPS вместо 30. Знакомая картина. Мы знаем, как решить эти проблемы. Наша задача — превратить хаос в стабильную архитектуру, оптимизировать производительность и довести проект до запуска. Свяжитесь с нами для оценки вашего проекта.

Почему разработка игр на Unity требует опыта?

Самая частая проблема — неправильное управление жизненным циклом объектов. MonoBehaviour.Update() на 400 активных объектах, каждый из которых дёргает GetComponent<Rigidbody>() каждый кадр, — это не архитектура, это катастрофа. На PC это незаметно. На iOS A14 это 12 мс оверхеда только на рефлексию.

Второй классический грабль — AddressableAssets без стратегии выгрузки. Проект подгружает локации через Addressables.LoadAssetAsync, но забывает вызвать Addressables.Release(). Через час игровой сессии RSS процесса вырастает с 800 МБ до 2.4 ГБ, и iOS убивает приложение. Это не баг Unity — это баг архитектуры.

Третья боль — смешение логики в сцене и в ScriptableObject. Команда начинает с MonoBehaviour-синглтонов, потом переходит на ScriptableObject-based EventSystem, но в итоге система событий живёт в трёх местах одновременно. Каждый новый разработчик добавляет слой поверх, и через полгода никто не знает, откуда прилетает OnPlayerDied.

Менее очевидная, но регулярная проблема: Physics.Raycast в Update() без LayerMask. Каждый вызов проверяет все коллайдеры сцены. При 50 агентах и сложной геометрии это 1-2 мс на кадр только на физику.

Как мы строим проекты на Unity?

Архитектура и стек

Основа — разделение на три слоя: GameplayCore (чистая C# логика без зависимостей от Unity API), UnityGlue (MonoBehaviour-обёртки), и Infrastructure (сервисы: сохранения, аналитика, сеть). Это позволяет тестировать геймплей без запуска редактора через NUnit + Unity Test Framework.

Рендер-пайплайн выбираем под платформу:

Шейдеры пишем через ShaderGraph там, где нужна визуальная итерация с художником. Производительные низкоуровневые эффекты — вручную на HLSL с Custom Function Node. Amplify Shader Editor используем только если проект уже на нём.

Как снизить количество draw calls?

На мобильных проектах стандартная цель — не более 100-150 draw calls на кадр. Достигается через:

• GPU Instancing на повторяющейся геометрии (деревья, пропсы). MaterialPropertyBlock для per-instance данных без разрыва батча.
• SRP Batcher — работает автоматически с URP, но требует, чтобы все шейдеры были SRP-совместимы. Один non-compatible материал рвёт весь батч. Согласно документации Unity, правильная настройка снижает draw calls до 80%.
• Sprite Atlas для UI — критично. UI Canvas с Overlay режимом и 60+ отдельными спрайтами даёт 60+ draw calls только на интерфейс.
• Occlusion Culling для 3D сцен — запекаем через Window → Rendering → Occlusion Culling. На уровнях с непрозрачной геометрией снижает draw calls на 40-60%.

Профилируем через Unity Profiler + Frame Debugger + RenderDoc (для детального анализа GPU). На Android дополнительно — Android GPU Inspector для Mali/Adreno.

Многопоточность и ECS

Для проектов с большим количеством агентов или симуляций рассматриваем DOTS (Unity ECS + Burst Compiler + Jobs System). Burst компилирует C# до нативного SIMD-кода — на задачах вроде pathfinding для 1000 агентов это разница между 16 мс и 0.8 мс на основном потоке. Это экономит до 40% времени на оптимизацию.

Для обычных проектов без DOTS — UniTask вместо корутин. Корутины работают на MainThread и не отменяются корректно при уничтожении объекта. UniTask с CancellationToken решает оба вопроса.

Мультиплеер

Для реального времени: Photon Fusion 2 (server-authoritative, rollback netcode) или Mirror (self-hosted, открытый исходник). Выбор зависит от требований к latency и бюджету на инфраструктуру. Для пошаговых и асинхронных взаимодействий — PlayFab CloudScript + Azure Functions.

Сохранения и облачная синхронизация — Firebase Realtime Database для простых случаев, PlayFab для полноценного game backend (лидерборды, матчмейкинг, экономика).

Как гарантировать качество Unity-проекта?

Процесс работы

Пре-продакшн (1-2 недели). Разбираем ТЗ, определяем целевые платформы и технические ограничения. Создаём вертикальный срез — минимально работающую механику в изоляции. Это важнее полного дизайн-документа: лучше потратить неделю на прототип, чем три месяца на разработку механики, которая не работает на целевом железе. Правильная архитектура экономит до 30% бюджета на разработку.

Продакшн. Спринты по 1-2 недели. Каждый спринт заканчивается рабочим билдом. Используем Git с LFS для ассетов, Jira или Linear для задач. Code review обязателен — особенно на системах, которые затронут несколько сцен.

Тестирование. Unit-тесты на геймплейную логику (Unity Test Framework, Play Mode). Интеграционные тесты через Playwright для WebGL. Ручное тестирование на реальных устройствах — симулятор iOS не воспроизводит реальное потребление памяти.

Запуск. Автоматические билды через Unity Cloud Build или GitHub Actions с fastlane для iOS. Android — Google Play Internal Testing, iOS — TestFlight.

Что входит в работу

• Анализ текущего проекта и постановка задач
• Архитектурное проектирование и написание benchmark-тестов
• Разработка геймплея и систем (UI, сеть, аналитика)
• Code-review и оптимизация производительности
• Документация кода и архитектуры
• Поддержка в течение месяца после релиза

Сроки по типу проекта

Стоимость рассчитывается индивидуально после анализа технического задания и целевых платформ. Свяжитесь с нами для оценки вашего проекта.

Какие типичные ошибки допускают при запуске Unity-проекта?

• Игнорировать Profiler до полировки. «Сначала сделаем, потом оптимизируем» работает до тех пор, пока не выясняется, что архитектурное решение, принятое в первый месяц, не поддаётся оптимизации без переписывания половины игры.
• Хранить все ассеты в Resources/. Папка Resources загружается в память при старте приложения целиком. 500 МБ текстур в Resources — это 500 МБ RAM до запуска первой сцены. Addressables решают это, но требуют планирования с самого начала.
• Один огромный Canvas для всего UI. Unity перерисовывает весь Canvas при изменении любого дочернего элемента. Разбивайте UI на статичные и динамические Canvas-компоненты.
• Физика на триггерах вместо расчётов. OnTriggerEnter надёжен при низких скоростях. Пуля, летящая 200 единиц/сек, проходит сквозь тонкие коллайдеры между кадрами. Для таких случаев нужен Physics.SphereCast или Rigidbody с Continuous Collision Detection.

Проверяем метрики E-A-T: мы гарантируем качество каждого проекта и предоставляем поддержку после запуска. Закажите консультацию по вашему проекту.

Проектирование механик: с чего начинается отзывчивое управление

Прежде чем говорить о геймдизайне, зафиксируем разграничение: геймдизайн — это не «придумать идею». Придумать может любой. Задача — спроектировать систему правил, которая производит конкретный эмоциональный и поведенческий результат. Это инженерная дисциплина, только вместо компилятора — человеческий мозг.

Первая боль: вам кажется, что управление «дубовое», а почему — непонятно. Чаще всего проблема не в коде, а в отсутствии coyote time и jump buffering. Или в линейном ускорении, которое не даёт ощущения веса. Мы это чиним на этапе прототипа.

Какие услуги геймдизайна мы предлагаем

Полный цикл: от концепта до выверенного билда. Под ключ — вы получаете геймдизайн-документ (GDD), таблицы баланса, прототип ключевых механик на Unity/Unreal, и сопровождение вплоть до релиза.

Что входит в работу:

• Документация: GDD, спецификации механик, нарративные деревья, API для разработчиков
• Таблицы баланса: прогрессия, экономика, DPS-калькуляторы
• Прототипы: интерактивные сцены с core loop (движение, бой, инвентарь)
• Конфигурация в движке: ScriptableObject, DataTable, анимационные событий
• Проведение плейтестов и итераций по метрикам (удержание, монетизация, retention)

Оцените ваш проект — свяжитесь для расчёта сроков. Подход основан на методологии MDA и опыте 50+ реализованных проектов с 2012 года.

Как проектировать боевую систему: глубокий разбор

Боевая система — самая дорогая ошибка: на первый взгляд простая, на деле — ад из edge cases. Разберём melee combat.

1. Выбор метода hit detection

Hitbox — коллайдеры на оружии. Просто, но при быстрых атаках возникает tunneling: оружие пролетает сквозь противника за кадр. Решение — Physics.CCD (Continuous Collision Detection), но это дорого. Raycast/spherecast — кастуем лучи вдоль траектории оружия. Точнее, меньше зависит от fps. Мы предпочитаем spherecast для action-игр. Подробнее о методах — в Wikipedia.

2. Настройка окон атаки

Каждая атака — три фазы: Startup, Active, Recovery. Длинный startup создаёт «тяжёлые» удары. Короткий recovery даёт агрессивный стиль. В Unity аниматор кидает событие через AnimationEvent, код включает/выключает hitbox. Типичные тайминги для рукопашного боя: startup 200–400 мс, active 100–150 мс, recovery 300–500 мс.

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

Инструменты в процессе

Итерация и плейтестинг: 2-недельный цикл

Первый прототип всегда неудобен — это норма. Наш цикл: плейтест каждые 2 недели. После — список изменений с числами: «startup 400 мс → 250 мс». Мнения без цифр не принимаются. Фиксируем ощущения, меняем цифры, повторяем.

Свяжитесь для консультации — мы оценим сроки и бюджет вашего проекта. Наши заказчики экономят от 2 до 3 недель на итерациях за счёт чёткого процесса.