Міфи про Unity. Спростовує Олексій Петруненко, Senior Unity Developer у w7g

Unity — рушій, навколо якого накопичилось чимало суперечливих суджень. Одні вважають його ідеальним для швидкого старту, інші — непридатним для серйозних проєктів. Олексій Петруненко, Unity Developer у w7g, розбирає поширені міфи про Unity: чому гра може зависнути від одного обʼєкта в Update, а Unity роками не фіксять баги, чи можна обійти проблеми з Garbage Collector, а також чому не кожна архітектурна революція в Unity заслуговує на прод.

Раніше Unity справді позиціонували як платформу для невеликих команд: безкоштовний доступ, оплата — тільки після отримання доходу. Але сьогодні Unity є рушієм для багатьох великих і комерційно успішних тайтлів, зокрема Genshin Impact, Pokémon GO, Call of Duty: Mobile, Hearthstone від Blizzard, Pillars of Eternity тощо. 

Ще одна частина міфу — ніби цей рушій не підходить для створення графіки високої якості. Unity підтримує HDRP (High Definition Render Pipeline) — потужний інструмент для побудови складної графіки. У ньому доступні Ray Tracing, тесселяція, анізотропна фільтрація, прозорість, Subsurface Scattering, кастомні шейдери, постобробка — усе, що потрібно для створення візуально потужних сцен. Вони забезпечують реалістичне освітлення, деталізовану геометрію поверхонь, якість текстур та ефект напівпрозорості. І якщо у розробника є технічна компетентність — обмежень практично немає.

Unity має повноцінну підтримку 3D, і вже згадані ігри — тому приклад. Крім того, платформа давно вийшла за межі ігрової індустрії. Із початком буму віртуальної та доповненої реальності Unity швидко адаптувався до нових потреб і досі залишається одним із основних інструментів для розробки VR/AR-проєктів. На рушії створюють медичні застосунки, архітектурні візуалізації, тренажери водіння та багато іншого. 

Цей міф — правдивий лиш наполовину. Unity надає чимало свободи розробнику, і не кожен може вміло скористатися нею. Так, якщо створювати об’єкти прямо в Update, не контролювати алокації памʼяті, не оптимізувати логіку, — отримаєте зависання, спайки, просідання продуктивності. Але проблема тут не в самому рушії, а в тому, як з ним працюють.

Водночас в Unity є обʼєктивні технічні обмеження. Одне з головних — Garbage Collector. 

Рушій працює на базі C#, який багато чого вміє, зокрема його GC працює швидко і коректно. Проте Unity — кросплатформенний рушій, який підтримує безліч версій — десктоп, веб, консолі, Android, iOS тощо. Вони мають забезпечити однакову поведінку на всіх девайсах, тому обрали найпростішу реалізацію Garbage Collector, який працює за принципом «stop-the-world»: виконання гри повністю зупиняється, доки GC не пройде всі обʼєкти в памʼяті й не видалить ті, на які більше немає посилань. Саме ці паузи й викликають мікрофризи — короткі зависання, помітні навіть на потужних пристроях. До цього додається ще одна проблема — в Unity немає механізму дефрагментації: навіть якщо вільної памʼяті достатньо, вона може бути розбита на дрібні фрагменти. У результаті алокація може не відбутись через відсутність достатнього неперервного блоку памʼяті. Або ж це може спровокувати GC-колекцію, що призводить до фризів.

Ці обмеження можна мінімізувати. У Unity є Profiler, Memory Profiler, Frame Debugger, Physics Profiler — ці інструменти дозволяють знаходити вузькі місця, оптимізувати логіку й памʼять. Якщо дотримуватись певних практик в архітектурі (наприклад, використовувати Object Pooling замість постійного Instantiate/Destroy у геймплейному циклі) можна суттєво зменшити навантаження на GC. Об’єкти створюються один раз і використовуються повторно, без додаткових алокацій та участі Garbage Collector.

Наприклад, у грі є зброя, яка стріляє кулями. Замість того, щоб створювати кулю щоразу при пострілі, можна взяти її, активувати, а після використання — повернути назад. Обʼєкт не створюється заново і не зникає, тому не генерує сміття в памʼяті й не провокує виклики GC. 

Цей міф почався з того, що самі Unity активно просували Scriptable Objects як зручний інструмент не лише для зберігання даних, а й для побудови логіки всієї архітектури гри. Відомим став виступ Раяна Хіпла на Unite Austin 2017, де спікер демонстрував, як можна вибудовувати всю взаємодію між компонентами проєкту через Scriptable Objects. Тоді це справило сильне враження, але на практиці такий підхід виявився повністю непридатним для продакшену. Використання Scriptable Objects як центрального архітектурного патерну призводить до хаосу: складно відстежувати звʼязки, неможливо дебажити, виникають проблеми з підтримкою. 

Хоча Раян Хіпл був технічним директором у студії Schell Games, його доповідь отримала офіційне визнання та поширення від Unity Technologies. Зокрема, Unity опублікувала статтю Three ways to architect your game with Scriptable Objects, у якій також рекомендувала використовувати це рішення для побудови архітектури. Це виглядало так, ніби всередині Unity не до кінця розуміють, як краще використовувати власні інструменти. Scriptable Objects добре працюють як конфігураційні обʼєкти, але не як runtime-менеджери або обʼєкти з mutable-станом.

Поширене уявлення — ніби розробники масово залишили Unity через технічну недосконалість, — перебільшене. Те, що баги фіксяться повільно або взагалі не фіксяться, — відомий факт. Це вже сприймається як частина реальності: розробники просто навчилися з цим жити.

Насправді більший удар по довірі стався 2023 року, коли Unity оголосили про введення Runtime Fee — плати за кожне встановлення гри після досягнення певного рівня доходу. Це викликало резонанс: спільнота обурилась, студії почали шукати альтернативи. Але практичний досвід швидко показав: проблем з іншими рушіями не менше. Unity згодом відкотила це рішення, CEO Джон Річітелло пішов у відставку, і компанія публічно намагалася «закрити» тему. 

У підсумку комʼюніті Unity не змінилося суттєво скоріше через відсутність реальних альтернатив. Наприклад, 

Unreal Engine — один з основних конкурентів. Краще підходить для ПК та консолей, але погано масштабується під мобільну розробку та кросплатформу. До того ж модель монетизації там ще суворіша.

Godot вважається перспективною альтернативою, і було чимало гучних заяв про перехід на цей рушій. Проте масових успішних релізів продуктів на ньому немає. Наприклад, у моїй Steam-бібліотеці з понад 200 ігор лише одна зроблена на Godot, тоді як на Unity — десятки. Крім того, Godot має власну мову програмування — GDScript, яка не використовується за межами рушія. Це створює додаткові ризики для розробників: знання не універсальні, і застосувати їх у випадку переходу в іншу галузь складно. 

У певний момент Unity активно просували ECS (Entity Component System) як наступний етап розвитку рушія — не лише для Unity, а нібито для всього геймдеву загалом. Це дійсно інший підхід до архітектури: дані організовуються не навколо об’єктів, а навколо ентіті, компонентів і систем. Розробники обіцяли високу продуктивність, завдяки оптимізованому розміщенню даних у памʼяті. 

Проте невдовзі людина, яка очолювала ECS-напрям у Unity, залишила компанію. Після цього команда швидко випустила ECS 1.0, але відтоді Unity фактично перестала публічно згадувати цей підхід — виглядає так, ніби компанія хоче про це просто забути. У результаті ECS залишився експериментом, який складно інтегрувати в реальні продакшен-проєкти. Для певних підсистем із високим навантаженням він справді може бути корисним, але зробити всю гру на ECS — архітектурно складно, дорого у підтримці та проблематично для команд, які не мають великого досвіду з data-oriented дизайном. 

У Unity-спільноті зустрічається упередження: якщо ти не використовуєш Zenject, не перейшов на URP/HDRP і не впровадив Addressables, значить, щось робиш не так. Ці інструменти справді активно просуваються як частина сучасного Unity-стеку, але на практиці їхня доцільність дуже залежить від типу проєкту, його розміру, стадії життя та платформи.

Zenject — DI-контейнер для Unity, що дозволяє інʼєктувати залежності за інтерфейсами під час виконання. Архітектурно це виглядає красиво, але у багатьох випадках його використання є оверінжинірингом. До того ж, він важкий, збільшує час запуску на декілька секунд і не завжди виправданий, особливо на мобільних платформах. У складних проєктах варто звернути увагу на VContainer — AOT-дружню альтернативу з compile-time перевіркою графу. А якщо проєкт невеликий — достатньо й кастомного Service Locator без зовнішніх залежностей.

Unity давно рухається в бік Scriptable Render Pipeline (SRP), пропонуючи URP для кросплатформених проєктів і HDRP — для високоякісної графіки на ПК і консолях. Але HDRP взагалі не підтримується на мобільних пристроях, а URP — хоч і сучасніший, не завжди виправданий, особливо якщо немає потреби у складній постобробці або візуальних фічах URP. У нових проєктах URP можна використовувати від самого початку — це безкоштовно й добре інтегрується. Але впроваджувати його у старий проєкт — складно, дорого і не завжди має сенс. Тому багато команд просто залишаються на Built-in Render Pipeline, якщо він покриває їхні потреби.

Addressables дозволяють динамічно вивантажувати ресурси — критично важливо для мобільних ігор із великою кількістю графіки. Це дає змогу економити памʼять: наприклад, підвантажити важкий спрайт з диска або CDN, показати його й одразу звільнити RAM. Але впровадження Addressables у старий проєкт без системи менеджменту асетів — це серйозний інженерний виклик, який забере тижні або навіть місяці. А гравець цього ніколи не побачить.

Отже, впровадження цих технологій у вже працюючих продуктах має сенс лише тоді, коли їхня користь перевищує витрати. Інакше — це просто дорогий технічний борг без відчутного ефекту.

Перш ніж потрапити в геймдев, я сім років писав процедурною мовою C. У першому ж проєкті отримав завдання зробити гру з нуля з релізом за пів року. Строки були досить фантастичні як для першого проєкту з нуля (мова не про гіперкежуал), тиск — високий, і діяти треба було швидко, тож робив що міг і як звик. У результаті вийшов моноліт у процедурному стилі. Втім, він працював стабільно, гру опублікували. Вона непогано себе показала, мала рейтинг 4.5, і навіть досі живе на Google Play.

На той момент мені здавалося, того, що гра працює — достатньо. Але згодом стало ясно, що така архітектура — непідтримувана й закрита для змін. Як би стабільно не працював код, якщо в ньому складно розібратися, це не ок. 

Водночас є й інша крайність. Буває, щойно розробник відкриє для себе абстракції, він починає зловживати ними, створюючи абстракції в абстракції, ще зверху обгорнуті в  абстракцію. Це так само робить код важким і незрозумілим. Саме тому існує принцип YAGNI (You Aren’t Gonna Need It) — не робити нічого наперед, якщо воно не потрібно вже зараз. Отже, писати треба так, щоб це можна було зрозуміти, підтримати й розвивати — і саме це робить код по-справжньому хорошим.

В одній з версій рушія був дивний баг: застосунок на Android не завершував роботу, а залишався висіти у фоні. Unity нічого з цим не могла зробити. Мені довелося писати окремий плагін на Java, який би вимикав застосунок — це костиль космічних масштабів. Цим лайфхаком поділився один з користувачів на офіційному форумі, і Unity просто проігнорувала це: раз спільнота вигадала обхідний шлях — значить, все нормально.

Часом ми очікуємо, що Unity пофіксить численні проблеми, щоби не довелося звертатися до спірних third-party інструментів. Але в реальності — вони не виправляються роками. Один із хрестоматійних прикладів — відсутність підтримки серіалізованих словників. Усі їх потребують, постійно пишуть свої костилі або тягнуть сторонні бібліотеки, але Unity досі це не реалізувала.

Тому, Unity — гнучкий рушій, але відповідальність за стабільність, памʼять, оптимізацію й навіть базову функціональність лежить на розробнику.

Вакансії в команду w7g:

• Flutter developer (w7g)

• UI/UX Designer (w7g)

• Motion Designer (w7g)