Впізнаваний рендер та баги, що кочують з однієї гри в іншу. Чи справді Unreal Engine робить проєкти вторинними

Студії, які десятиліттями розробляли ігри на кастомних рушіях, дедалі частіше диверсифікують технологічний стек або повністю переходять на популярні рішення. Здебільшого, їхнім вибором стає саме Unreal Engine.

Epic Games позиціонує свій рушій як plug and play рішення, однак на практиці робота з ним є значно складнішою. Тож ми вирішили обговорити з програмістами та девелоперами з Ubisoft, 4A Games, Pingle Studio та інших компаній низку поширених тез, що або викривають вразливі місця роботи з UE, або перекладають відповідальність з неоптимізованих пайплайнів на сам рушій.

Теза #1: Монополізація ринку рушіїв та відмова компаній від пропрієтарних рішень — це стратегічна загроза для розробників

Андрій Бурцев — Development Director, 4A Games

На жаль, монополізація вже відбулася. Розробників ігор фактично поділили між собою Unreal Engine та Unity. Мобільні та невеликі проєкти відійшли Unity, а більші (класу AA та AAA) — Epic Games.

Власні рушії може дозволити собі підтримувати і розвивати лише низка великих компаній на кшталт EA чи Ubisoft. У перспективі декількох років геймдев може зайти у глухий кут, а у сфері інновацій — вже не відбуватиметься нічого нового. Для комерційних рушіїв головним пріоритетом стане підтримання стабільності всіх компонентів, і саме це вимагатиме левової частки ресурсів команди. При цьому, хоч як це не дивно, ліцензування рушія — не такий прибутковий бізнес, як вважають.

Основна частина доходів Epic Games надходить від Fortnite, тому постає велике питання: що буде, якщо доходи від цієї гри в якийсь момент почнуть спадати? Чи зможе Epic Games продовжувати виділяти кошти на підтримку та розвиток UE?

Тарас Прокопенко — Senior Lead Programmer, Ubisoft

Розробка, а особливо підтримка і розвиток своїх рушіїв, це дуже дорого і важко. Тож, певно, це вірний вибір, коли менші компанії переходять на Unreal Engine (чи будь-який інший популярний рушій), оскільки гравці грають не в технології, а в ігри. UE може значно зменшити бюджет і час на розробку. Також на ринку багато розробників з необхідним досвідом роботи, що не є поширеним кейсом в контексті власних рушіїв.

А з власного досвіду онбордингу нових спеціалістів можу сказати, що шлях програміста (і не тільки) до 100% продуктивності на пропрієтарному рушії може зайняти до 6 місяців.

Євген Карпенко — Render Developer/Graphics Programmer, Pingle Studio

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

Також набагато простіше знайти умовних 100 спеціалістів зі знанням Unreal Engine, ніж навчати їх роботі з внутрішнім інструментарієм студії, який може бути погано задокументованим.

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

Тому я вважаю, що відмова від пропрієтарного рушія на користь Unreal Engine та інших не внутрішніх продуктів — це виключно позитивне рішення.

Остап Леонов — Lead Unreal Engine Developer, NDA

Не дуже згоден з тезою про те, що монополізація в цьому випадку — це погано. Консолідуючись навколо нової технології, компанії мають доступ до великого ринку кадрів, що значно зменшує витрати на L&D (Learning & Development) та дає гарантію, що спеціалісти для створення нових продуктів будуть завжди.

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

Щодо гравців, то в цьому випадку вони отримають хоча б якусь передбачуваність та великий обсяг елементів для модингу, бо, знову ж таки, технологія використовується багато де.

Теза #2: Unreal Engine приватизував фотореалізм, чим допоміг оптимізувати витрати та пайплайни. Однак, ця універсальність стала головною перешкодою для якісної оптимізації ігор

Андрій Бурцев — Development Director, 4A Games

По-перше, коли мова заходить про фотореалізм, виникає багато суперечок щодо того, який це саме стиль і на який «реалізм» має бути схожа картинка. UE має дуже специфічний рендер: він добре впізнаваний в іграх, виглядає ефектно для гравця, але це не та картинка, яку ми бачимо, дивлячись у вікно. Для досягнення максимальної реалістичності рендер має бути підлаштований саме під конкретний візуальний стиль. Ми у своїх іграх витрачаємо значні зусилля саме на це.

Щодо оптимізації, то слабким місцем UE є багатопоточність. Фактично, архітектура рушія не змінювалася з початку 2000-х і наразі є найбільшою проблемою для консолей. А з урахуванням того, що подальший розвиток процесорів буде спрямований саме на збільшення кількості ядер, а не тактової частоти, то без виправлення цієї проблеми ігри на UE матимуть серйозні обмеження щодо продуктивності.

Саме тому ми чуємо заяви Тіма Свіні, що в 6-й версії головний фокус буде на багатопоточності. Натомість у 4A Engine ми завжди приділяли цьому багато уваги і саме завдяки цьому можемо максимально ефективно використовувати апаратні ресурси на всіх платформах.

Тарас Прокопенко — Senior Lead Programmer, Ubisoft

Я не асоціюю фотореалізм з оптимізацією для себе. Проблеми з оптимізацією можуть виникати на різних проєктах без прив’язки до якості зображення.

Як на мене, найбільш критичним є відсутність ефективної роботи над оптимізацією та відкладання її на останні етапи.

Євген Карпенко — Render Developer/Graphics Programmer, Pingle Studio

На мій погляд, у проєктах, які «страждають», є одна велика проблема — погано розроблений пайплайн створення контенту та ресурсів. Оскільки сам рушій максимально оптимізований, проблема виникає тоді, коли контент і ресурси не оптимально налаштовані.

Не один раз зустрічав, як для того ж Nanite та Lumen створюють контент і ресурси за абсолютно неправильним пайплайном.

Остап Леонов — Lead Unreal Engine Developer, NDA

Тут знову не погоджуся. Будь-де пайплайн розробки ставатиме тільки складнішим. У цьому випадку розробники просто можуть не морочитися оптимізацією на ранніх етапах і концентруватися на розробці самої гри.

Стосовно оптимізації кінцевого продукту — кастомні рушії тут не панацея. Кейс того ж самого RED Engine (Cyberpunk 2077, The Witcher 3) на старті це підтверджує. Потрібно розуміти, що ігри все одно розробляти складно.

Оптимізація — це великий шмат роботи, тому в часи, коли геймдев є максимально комерціалізованим, деякі компанії обирають (або змушені) відкласти це на післярелізну підтримку або взагалі не робити. Проєкти на UE — не єдині з цією проблемою: просто через кількість проєктів на цьому рушії, та явну брендову прив’язку до нього, може виникати певний «посмак».

Теза #3: Відчуття вторинності в іграх на UE стосується не лише специфічної обробки візуалу, а й багів, які мігрують з однієї гри в іншу

Тарас Прокопенко — Senior Lead Programmer, Ubisoft

Цей пункт мені не зовсім відгукується. З погляду гравця, я не асоціюю гру на UE з вторинністю: таку ж гру можна зробити на іншому рушії і вона буде настільки ж вторинною. UE знизив поріг входу для тих, хто хоче робити ігри, і це чудово.

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

Денис Мехед — Lead Editor Programmer, 4A Games

Однозначно з Unreal від проєкту до проєкту мігрує і велика кількість багів. Багато з них давно «запали в око» юзерам, тож певні речі вже сприймаються як норма: легкий clipping моделей, LOD pop-ins, дрібні фізичні артефакти. Ці речі вже нікого не дивують і загалом сприймаються за стандарт, тож користувачі і не очікують, що може бути якось інакше.

Втім, не треба забувати і про велику кількість багів, які у фінальному продукті може побачити лише девелопер. Кінцевий гравець часто не усвідомлює проблем, спричинених обмеженнями розмірів nav mesh у відкритому світі або багатокроковим підвантаженням світла та мешів при стримінгу великих сцен. Такі проблеми можуть сприйматися гравцями як неякісний контент і помилки окремо взятого продукту, тому вони є найбільш болючими для розробника.

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

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

Євген Карпенко — Render Developer/Graphics Programmer, Pingle Studio

Я не вважаю, що в Unreal Engine є проблеми, що проєкти на ньому демонструють вторинність чи щось подібне. Рушій справді оптимізований як з погляду ігрового циклу, так і з рендерної/графічної сторони.

Render Dependency Graph в UE5 — це гнучкий інструмент, який дає змогу на дуже низькому рівні маніпулювати рендерингом. Також рушій має дуже потужні інструменти профілювання, за допомогою яких можна зрозуміти, де в грі є проблеми з «вузькими» місцями продуктивності.

Остап Леонов — Lead Unreal Engine Developer, NDA

Стосовно візуалу — це загальна проблема. Багато розробників вибирають вектор розвитку в бік найбільшого фотореалізму, забуваючи, що саме стилізація і є тим, що робить проєкти унікальними та закарбовує гру в пам’яті геймерів. На мою думку, фотореалізм — це нудно. Але в часи, коли індустрія ніби вимагає його, комбінувати фотореалізм зі стилізацією стає все складніше.

Стосовно багів — так, багато проєктів можуть містити як спільні баги рушія, так і спільні баги middleware. До прикладу, зараз дуже багато скарг на те ж саме освітлення у Lumen в UE. У software-режимі Lumen є багато проєктів, де трапляється спільна проблема — шиммеринг (мерехтіння) на деяких поверхнях, light leaking тощо. Хоча це й не зовсім баг, а більше особливість, та все одно це дає певне відчуття вторинності.

На жаль, знову ж таки, коли індустрія настільки комерціалізована, як у нас, не завжди можна довести менеджменту, що фікс таких проблем може бути корисним. Що особливо сумно, зважаючи, що Unreal — це по суті open-source рушій. Тобто, якби всі розробники виправляли такі баги один за одним, ці фікси були б доступні усім.

Теза #4: Доступність рушія створила покоління інженерів із поверхневими знаннями архітектури та графіки, чиє мислення лімітоване екосистемою UE

Тарас Прокопенко — Senior Lead Programmer, Ubisoft

Це органічна еволюція, що постійно відбувається: assembly -> C -> C# — про це також можна сказати, що кожне наступне покоління менше орієнтується в архітектурі заліза, роботі з пам’яттю тощо.

Unity зробило так само: велика кількість розробників, та менша кількість гарних розробників. І це не провина технологій. UI/Gameplay/Online програмісти здебільшого також мають не дуже глибокі знання в графіці й архітектурі рушіїв, оскільки вони виконують свою роботу на іншому рівні і є чудовими спеціалістами у своєму напрямку. Тут більше питання до композиції команди та зон відповідальності.

Денис Мехед — Lead Editor Programmer, 4A Games

Монополізація ринку сформувала ситуацію, за якої індустрія наповнилась розробниками, які ставлять знак рівності між розробкою ігор і розробкою ігор на Unreal Engine. Це не робить їх поганими спеціалістами: в межах своїх екосистем вони безумовно розуміють, що роблять, і роблять це добре. Водночас підходи до розробки та парадигми, які вони перейняли, працюючи з Unreal, часто заважають їм повноцінно інтегруватися в розробку пропрієтарного рушія.

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

У межах екосистеми Unreal, такий підхід, звичайно, має місце, однак при розробці пропрієтарного рушія він стає шкідливим. У наших умовах кожен рядок коду можна і варто ставити під сумнів, намагаючись витиснути з кожного модуля максимум тут і зараз.

Євген Карпенко — Render Developer/Graphics Programmer, Pingle Studio

Unreal Engine — це просто інструмент, який треба вміти використовувати. А все вищезазначене є наслідком зменшення «порогу входу». Рушій, як продукт, надає дуже прості інструменти для того, щоб почати, тоді як advanced та optimization техніки для багатьох користувачів залишаються недоступними, а багато хто навіть і не намагається розвиватися в цьому напрямку.

На UE5 вийшло вже багато ігор і ми можемо бачити ситуацію, де на багатьох проєктах, де правильно налаштовані пайплайни та висока експертність у рушії, немає взагалі жодних проблем: Fortnite, Arc Riders, Tekken, The Finals та багато інших.

Остап Леонов — Lead Unreal Engine Developer, NDA

Найбільш близькою аналогією буде ситуація у веб-розробці. Наприклад, коли наймають фронтенд-розробника, його беруть з урахуванням того, що він буде працювати з одним із фреймворків (наприклад, React, Vue, Angular). Так само й тут, і навіть більше: якщо беруть розробника, то краще, щоб фокус у нього був саме на технологію, а не на barebones-речі.

Знову ж, найбільший плюс Unreal Engine у тому, що є великий ринок спеціалістів, які знають, як із цієї технології «вичавити всі соки». Специфічні напрямки, такі як рендеринг, звісно, закривають спеціалістами, які саме знають свою сферу (в цьому випадку комп’ютерну графіку), а не конкретну технологію. Водночас геймплейщики чи тулзовики можуть бути більш корисними, коли вони в курсі тієї технології, з якою працюють.

Тут треба зазначити, що ідеальних спеціалістів зі знанням усіх теорій, з досвідом у 10+ років насправді не так багато. І вони не з’являться на рівному місці. Тому, на мою думку, потрібен баланс тих, хто краще знає технологію, і тих, хто краще знає принципи, адже таким чином вони себе еквалізують.

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини