Професійна розробка на 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: ми гарантуємо якість кожного проекту та надаємо підтримку після запуску. Замовте консультацію щодо вашого проекту.