Професійна розробка на 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. Наприклад, у платформерах без coyote time гравець програє 20% спроб через відчуття «нечесної» смерті. Або в лінійному прискоренні, яке не дає відчуття ваги — замінюємо на криву початкового ривка з подальшим загасанням. Ми це виправляємо на етапі прототипу, скорочуючи подальші правки на 40%.

Окрема категорія — економіка. Без попередньої математичної моделі розвал настає через місяць після релізу. Тому ми починаємо з прогресії: лінійна, експоненціальна або поліноміальна. Наприклад, для RPG використовуємо поліном a * n^b з b=2.0, перевіряючи, скільки годин гравець витратить на кожен рівень. Це дає прогнозований час гри і дозволяє уникнути дисбалансу монетизації.

Які послуги з геймдизайну ми пропонуємо?

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

Що входить в роботу (deliverables):

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

Оцініть ваш проект — зв'яжіться для розрахунку термінів. Підхід заснований на методології MDA та досвіді 50+ реалізованих проектів, більше 10 років на ринку. Наші замовники економлять від 2 до 3 тижнів на ітераціях завдяки чіткому процесу.

Як спроектувати бойову систему без помилок?

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

Вибір методу hit detection

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

Налаштування вікон атаки

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

Побудова 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 мс». Думки без чисел не приймаються. Фіксуємо відчуття, змінюємо числа, повторюємо. Завдяки цьому середня економія бюджету на етапі ітерацій становить 15–20%.

Зв'яжіться для консультації — ми оцінимо терміни та бюджет вашого проекту. Отримайте прототип core loop за 3 тижні. Сертифіковані фахівці Unity/Unreal гарантують дотримання термінів.