Blueprints проти C++: аналізуємо досвід розробки Expedition 33 з Unreal-девелоперами

Виступ розробників Clair Obscur: Expedition 33 на конференції GDC викликав жваве обговорення в спільноті. Те, що в грі 95% логіки тримається на блупринтах, стало приводом для дискусій: від захоплення доступністю інструментів Unreal Engine до скепсису щодо продуктивності та підтримки такого коду в довгостроковій розробці.

Ми обговорили цей кейс разом з Unreal-девелоперами та технічними дизайнерами, щоб зрозуміти актуальний статус візуального скриптування. Чи є такий підхід ознакою еволюції програмування, що дозволяє створювати ігри невеликими командами, чи це ризикована стратегія, яка неминуче призводить до технічного боргу та «нічних кошмарів» під час дебагу? Аналізуємо, чи зможуть великі студії піти шляхом Sandfall Interactive і чи не стане візуальний код «пасткою» для масштабних проєктів.

95% на Blueprints: революція в розробці чи винятковий кейс

«Чи буде така гра цікавою для більшості? Сумніваюся»

Микита Лужанський — Unreal Developer, Pingle Studio

Я грав у Clair Obscur: Expedition 33: у ній прекрасна музика та цікавий сюжет, але геймплей мені не зайшов. Тому, на мою думку, гра отримала таку кількість нагород незаслужено (окрім саундтреку). Але зараз цікавіше розібрати не саму гру, а технічний аспект її розробки.

Чи можна створити гру повністю на блупринтах? Так, цілком. В інтернеті можна знайти безліч туторіалів з Unreal Engine 5, де ви з нуля розроблятимете «три в ряд», перегони чи навіть базовий шутер. Чи буде така гра цікавою для більшості? Сумніваюся. Чи можна взагалі не використовувати блупринти? Скоріше ні, бо навіщо викидати такий потужний інструмент на смітник.

«Unity та Godot намагаються наздогнати та впроваджують аналогічні рішення у свої продукти»

Артем Метельов — Technical Game Designer

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

Unity та Godot намагаються наздогнати та впроваджують аналогічні рішення у свої продукти.

«Жанр цієї гри загалом не потребує важких обчислень на CPU, тому для них це спрацювало»

Олексій Карамбович — Unreal Engine C++ Developer, Pushka Studios

95% не дорівнює 100%. Хоча більша частина геймплею була створена на блупринтах, існують і критичні частини коду — bottlenecks, які розробникам довелося замінити відповідним C++ кодом. Clair Obscur: Expedition 33 є доволі примітивною — покрокова бойова система, single-player. Жанр цієї гри загалом не потребує важких обчислень на CPU, тому для них це спрацювало.

Також не варто забувати, що команда Clair Obscur загалом складалася з одного розробника. На останніх ітераціях над грою працювали четверо розробників із Sandfall та четверо — з боку видавництва. Такий невеликий розмір команди дозволив нівелювати один з основних недоліків блупринтів — ексклюзивний доступ до ассетів (file locking).

Підсумовуючи: за допомогою blueprints (за винятком деяких моментів) можна створювати ігри, але треба чітко усвідомлювати їхні обмеження.

Blueprints vs C++: де закінчується гнучкість і виникає потреба в «чистому» коді

«Зазвичай у командах із чітким розподілом обов’язків програмісти рідко звертаються до блупринтів для створення нової логіки»

Микита Лужанський — Unreal Developer, Pingle Studio

Розпочнімо з того, що ж таке blueprints? По суті, це скриптова мова програмування в Unreal Engine. Вона має вигляд графа, що складається з нодів та з’єднань між ними.

Це доволі зручний інструмент для прототипування фіч, яким найчастіше користуються геймдизайнери. Зазвичай у командах із чітким розподілом обов’язків програмісти рідко лізуть у блюпринти для створення нових фіч. Це зумовлено тим, що далеко не весь функціонал рушія винесено в систему візуальних скриптів — існує великий набір інструментів, доступних виключно через C++.

Розгляньмо на прикладі, де саме використовується C++, а де — blueprints. У моєму поточному проєкті (деталі під NDA) я працюю над системою наративного дизайну. Простіше кажучи, відповідаю за все, що пов’язане з діалогами. Це включає:

• відтворення діалогів — коли гравець підходить до NPC, а той щось йому каже;
• вибір реплік — варіанти відповідей на запитання персонажа;
• автогенерацію анімацій обличчя на базі озвучених текстів;
• субтитри під час діалогів;
• діалоги під час кат-сцен тощо.

На цьому проєкті використовується стороння програма для написання діалогів — Articy Draft X. В ній сценаристи прописують репліки, які потім мають звучати в грі в правильній послідовності і від правильних персонажів.

Джерело

Коли сценарист завершує роботу або вносить зміни, він заливає їх у систему контролю версій. Далі запускається процес експорту з Articy в UE5 — він відбувається на віддаленому сервері. Під час цього процесу генеруються аудіофайли та оновлюється внутрішня база даних UE, у якій зберігаються всі діалоги гри.

Команда Articy надає плагін для UE, який дозволяє отримувати ці дані в рантаймі. Але він написаний доволі дивно, тому ми майже повністю його переписали. Для дизайнерів ми створили простий та зрозумілий інтерфейс (API) для запуску діалогів, який фактично складається з однієї ноди. Зараз уся система — це понад 20 тисяч рядків коду, які виконуються при старті будь-якого діалогу. Вона:

• знаходить діалог у базі даних;
• визначає граф проходження;
• розуміє, де зупинитися для вибору гравця;
• запускає потрібний аудіофайл;
• обробляє умови (наприклад, чи вдарив гравець NPC, чи просто привітався);

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

Чи можна було написати це все на блупринтах без коду? Абсолютно, беззаперечно, стовідсотково — ні. Такі складні core-системи і є основним об’єктом роботи розробників.

«Це загальна практика — віддавати „важкі“ та громіздкі скрипти програмістам для переписування на C++ чи C#»

Артем Метельов — Technical Game Designer

Революції тут немає. Я вже вісім років використовую виключно blueprints для створення різнопланових скриптів і вже не уявляю, як це — повернутися до написання коду, як я це робив у школі та університеті. :)

Водночас програмування нікуди не зникне. Це загальна практика — віддавати «важкі» та громіздкі скрипти програмістам для переписування на C++ чи C#. Також не варто забувати про можливості, які відкриває програмування ігрового рушія та інтегрування додаткових систем.

Я б порівняв blueprints із FPV-дронами, а програмування — з танком. Без першого вже важко уявити сучасну роботу, але без другого не обійтися у складних проєктах.

«Я не чув, щоб їх масово використовували у великих проєктах — зазвичай це вибір інді-команд»

Олексій Карамбович — Unreal Engine C++ Developer, Pushka Studios

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

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

Ціна доступності: переваги, обмеження та «нічні кошмари» розробки на Blueprints

«Програміст бере складний низькорівневий інженерний процес і „пакує“ його у зрозумілий візуальний блок»

Микита Лужанський — Unreal Developer, Pingle Studio

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

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

«Набагато дешевше та зручніше використовувати стандартний рушій»

Артем Метельов — Technical Game Designer

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

Утримувати власну команду розробників рушія, постійно його оновлювати та перенавчати під нього спеціалістів — це фактично «дірка» в бюджеті. Набагато дешевше та зручніше використовувати стандартний рушій: це дозволяє спрямувати всі ресурси безпосередньо на розробку гри та скоротити час адаптації нових співробітників. До того ж Epic Games не бере комісії за використання Unreal Engine, доки чистий прибуток від гри не сягне $1 млн.

«У тих, хто часто працює з подібним, певно, бувають нічні кошмари»

Олексій Карамбович — Unreal Engine C++ Developer, Pushka Studios

Мінусів та обмежень дуже багато, але почнемо з небагатьох плюсів:

1. Низький поріг входу. Це справді так: blueprints є набагато простішим інструментом, ніж C++. Це дає новачкам ідеальну можливість ознайомитися з рушієм і почати створювати ігри, позбавивши себе потреби вивчати складний синтаксис і боротися з помилками компілятора.

Я б на цьому й завершив, але пан Том Лооман (один із найвідоміших інструкторів з Unreal Engine, колишній розробник в Epic Games) наводить ще кілька переваг, які, як на мене, є доволі суперечливими:

1. «Безпечність» blueprints. Коли щось іде не так (зазвичай це доступ до nullptr), замість крашу гра продовжує працювати й після завершення сесії просто видає помилку. Я не зовсім розумію, що заважає робити перевірки у C++ коді. Можна забути про це кілька разів, але це швидко формує корисну звичку робити багато перевірок/assert.
2. Blueprints мають гарний autocomplete. Це, звісно, добре, але Visual Studio 2022 вже має непогане автозаповнення, також існують плагіни Visual Assist або Rider.

Тепер до основних мінусів:

1. Дуже погана продуктивність коду. Блупринти компілюються у байт-код, який виконується віртуальною машиною, а не безпосередньо CPU, що суттєво знижує продуктивність.
2. Бінарність файлів. Blueprints не зберігаються у текстовому вигляді (на відміну від C++), що спричиняє серйозні проблеми. Наприклад, це унеможливлює одночасну роботу над одним файлом (ассетом) кількох людей, бо виникає merge conflict, який неможливо вирішити автоматично (як це робиться у разі текстового формату). Також відстежити історію змін у такому файлі значно складніше, ніж у текстовому.
3. Неможливість повноцінного дебагу (у деяких випадках). Якщо розробка ведеться, наприклад, під консолі й виникає проблема в логіці блупринтів, то залишається молитися, що її вдасться відтворити на desktop-версії, оскільки інакше (без дебагера) розв’язання проблеми може зайняти набагато більше часу.
4. Погана ергономічність. Ноди займають забагато місця на екрані, що уповільнює роботу з ними. Думаю, всі бачили жахливі картинки зі «spagetti-блупринт кодом». У тих, хто часто працює з подібним, певно, бувають нічні кошмари.

Чому успіх Expedition 33 може бути винятком, а не правилом для ринку

«Саме для цього й існує Unreal Engine та екосистема плагінів, які можна підключати за потреби»

Микита Лужанський — Unreal Developer, Pingle Studio

Чому ж в Експедиції вся гра на блупринтах і без коду? Думаю, тому що в її архітектурі немає нічого критично складного. Основний геймплей — це натискання кнопок у правильний момент і побудова білда: за перше відповідає Enhanced Input, а за друге — Ability System.

Іронічно, що кожна з цих систем містить тисячі рядків C++ коду та просто дає зручний API для блупринтів. Тож відповідь проста: все це вже написали програмісти з Epic Games, а команда Sandfall Interactive використала готові рішення.

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

«З мінусів — неможливість миттєво створити щось абсолютно унікальне»

Артем Метельов — Technical Game Designer

Я б не називав це обмеженням чи мінусом. Навпаки, такий підхід обирають через зручність, швидкість та відсутність потреби в написанні шаблонного коду. Використовуючи систему нодів, ви лише «кажете» комп’ютеру, що саме хочете зробити — вам не потрібно детально пояснювати, як це реалізувати. Ці інструкції вже інкапсульовані в самих нодах, які розробник розміщує у просторі та з’єднує між собою.

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

«Успіх Clair Obscur: Expedition 33 може надихнути інді-студії»

Олексій Карамбович — Unreal Engine C++ Developer, Pushka Studios

Я не бачу жодної мотивації для AA/AAA-студій переходити на розробку на blueprints, якщо вони вже мають кваліфікованих C++ програмістів. Оскільки такий підхід нічим не кращий за «традиційний» спосіб, рекомендований Epic Games.

Водночас успіх Clair Obscur: Expedition 33 може надихнути інді-студії.

Яке місце посядуть Blueprints у довгостроковій перспективі

«Дедалі більше геймплейних механік уже написані за нас іншими фахівцями»

Микита Лужанський — Unreal Developer, Pingle Studio

То про що ж свідчить кейс Sandfall Interactive?

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

«Зараз у Minecraft Education можна вивчати візуальне програмування та бачити результати своїх дій безпосередньо у грі»

Артем Метельов — Technical Game Designer

Блупринти вже посунули і розбили на ніші інструменти. Якщо ви прагнете програмувати складні системи, змінювати ігрові рушії під власні потреби або створити свій — програмування саме для вас. Якщо ж ви хочете створювати локації, аудіодизайн, квести, ігрові механіки та «оживляти» роботи художників — blueprints та інші мови візуального програмування стануть для вас ідеальним рішенням.

До того ж можливостей стає дедалі більше, і вони стають доступнішими: від самонавчання на YouTube до репетиторства на базі Minecraft. Саме так: зараз у Minecraft Education можна вивчати візуальне програмування та бачити результати своїх дій безпосередньо у грі.

«Візуальне програмування залишиться інструментом для швидкого прототипування або засобом для навчання дітей та початківців»

Олексій Карамбович — Unreal Engine C++ Developer, Pushka Studios

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

Також зараз набирає обертів так званий vibe coding. Нейронним мережам простіше працювати з текстовим кодом, тому такий формат створює зайві проблеми і нейронці буде простіше і дешевше генерувати C++ код.

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

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