«Як не дивно, було досить легко». Досвід переходу N-iX розробника від Unity до роботи з Unreal Engine

Всім привіт! Мене звати Дмитро Дяченко, і я хочу поділитись своїм досвідом того, як після 7-ми років роботи з Unity я вирішив перейти на Unreal Engine та ААА проєкти. Спойлер: було не так важко і вже два роки потому я маю можливість працювати над топовими Unreal Engine проєктами в N-iX Game & VR Studio, зокрема над новою грою від Supermassive Games.

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

Мій шлях у геймдев та знайомство з Unity

Як кажуть в нашій сім’ї — бабуся була першим програмістом, у свій час вона працювала з перфокартами. Насправді я маю старшого брата, який мене й зацікавив програмуванням. Під час того, як він навчався в Рівненській філії комп’ютерної академії «ШАГ», я мав змогу бачити результати його навчання та практичні роботи по завершенню якоїсь теми.

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

Після школи, я також почав своє навчання в Рівненській комп’ютерній академії «ШАГ», а вже по закінченню, у 2013 році, почався мій професійний шлях в геймдеві. Тоді я якраз обирав собі ігровий двигун для роботи. Спочатку працював над іграми жанру Hidden Object використовуючи ігровий рушій HGE на C++, але згодом розумів, що це досить застарілий двигун, тому почав шукати щось більш сучасне. Мій вибір впав саме на безплатний ігровий рушій Unity.

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

Пропрацювавши 7 років використовуючи Unity, я вирішив, що потрібно рухатись далі. Через його кросплатформеність, Unity використовують переважно для мобільних ігор та сторонніх, не гейм додатків (хоча є то й же Xamarin, який, на мою думку, більш підходить для такого роду додатків). На жаль, досягти якості ігор класу AAA на ньому буде важко, хоч і можливо. Я знав, що Unreal Engine має досить багато вбудованих можливостей для розробки саме ігор. В N-iX Game & VR Studio з’явилась можливість переходу досвідчених Unity розробників на Unreal, тому гріх було не скористатись цією нагодою.

Як було переходити з Unity на Unreal. Челенджі та відкриття під час роботи

Як не дивно, мені було досить легко перейти з Unity на Unreal. Я одразу почав працювати на проєкті, де використовувався Unreal. Кілька днів дивився на новий рушій з «відразою». Editor виглядав наче більш-менш схожим, але вікно усіх об’єктів на сцені за замовчуванням знаходиться з правої сторони. Більшість Unreal розробників там її й залишають, але я перемістив її вліво на лад Unity. Колеги не знайомі з Unity дивуються навіщо я це зробив. Але це діло звички, оскільки (спойлер) через рік досвіду з Unreal я повернувся до Unity і вгадайте що? Я теж почав плюватись, бо вже тепер там все було незвичним і не зручним.

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

А де GameObject?

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

В Unity GameObject — це універсальний об’єкт-контейнер, де ми можемо будувати свою ієрархію з вкладених гейм-обджектів, прикріпляти скрипти, зв’язувати їх між собою простим перетягуванням одного об’єкта в інший та створювати prefab зі збереженням всієї структури та всіх референсів для подальшого багаторазового використання. В Unreal інший підхід, адже всі компоненти інкапсульовані в AActor та не можуть жити окремо.

Зазвичай при створенні власного актора в C++ описуються компоненти, які в ньому мають бути (StaticMesh, Collision, свій власний компонент тощо). Потім на основі цього класу створюється blueprint, де ми можемо бачити всі наші компоненти та можемо налаштувати їхню позицію відносно рута актора. Налаштувати параметри колізій, додати меш асет до статік мешу і тд. Blueprint-ти підтримують наслідування — тобто в дочірньому блупринті ми можемо змінити параметри компонентів.

Блупринти — сила

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

Шейдери без знання HLSL

Блупринти широко використовуються у багатьох аспектах розробки в Unreal. HLSL практично не використовується так, як ми звикли це робити в Unity (так, я пам’ятаю про шейдер граф у Unity, чесно кажучи не використовував, але чув декілька нарікань). Зазвичай все налаштовується через нодову систему, яка далі конвертується в HLSL під конкретну платформу.

Animation

Є анімаційний блупринт, де ми можемо не тільки налаштовувати стейт машину за вхідними параметрами, а й створювати та оперувати цими параметрами. Наприклад, ми можемо визначити чи персонаж зараз у повітрі, чи ні, та змінювати відповідно стан, який підхопить стейт машина, щоб програти відповідну анімацію. Звісно, це все також можна робити в C++ представленні анімаційного класу. Зазвичай в анімаційному блупринті можуть налаштовуватись унікальні характеристики для одного з персонажів. Наприклад, один персонаж може зупиняти анімацію атаки при отриманні шкоди, а інший ні. Щоб не робити якусь унікальну логіку в C++ лише для одного з персонажів, яка більш ніде не буде використовуватись, ми можемо легко це додати тільки до конкретного анімаційного блупринта.

Вбудована система AI

На відміну від Unity, в Unreal вже є вбудована система для АІ. Працює вона на основі BehaviorTree, тобто в залежності від налаштувань виконується та чи інша гілка поведінки. Саму поведінку також можна налаштувати використовуючи блупрінти або С++.

Replication/networking

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

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

Я все більше відкривав нового, та почав використовувати те, що пропонує Unreal, а не писати свої «костилі». Епіки все-таки приділили більше часу для написання якогось функціонала, ніж я своєму костилю. Хоча мої рішення працювали добре!)

Мої враження

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

Єдине, що наразі мене засмучує — це слабка активність ком’юніті Unreal розробників. В Unity все значно жвавіше. Документація теж могла б бути кращою, але оскільки Unreal — це рушій з відкритим кодом, то ми можемо самі дізнатися, як працює та чи інша функція та навіть змінити її під свої потреби. Наприклад, якщо не знаєш/забув як потрібно користуватись тією чи іншою C++ конструкцією, ти завжди можеш пошукати як це робиться в коді рушія.

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

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

👍ПодобаєтьсяСподобалось7
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Ооо, знаю цього чувака, норм спеціаліст!

Але те що в футболці Орди це конешно крінж, краще за Альянс :)

З теперішніми реаліями взагалі варто перестати грати у WoW чи щось від блізардів.. twitter.com/...​&t=P-AQxo0Rfz_H4NQWJgfYZg

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

Ось відкрите онлайн-стажування з C++ та Unreal Engine 5:
dou.ua/calendar/44709

бачу тільки блупрінти у программі

N-iX отримав грант, кошти підуть на навчання нових спеціалістів — gamedev.dou.ua/...​inkedin&utm_medium=social

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

з досвідом взагалі нема проблем почати десь працювати

Далеко не кожна компанія може собі дозволити навчати анріалу, навіть якщо є знання с++

то для молодих талановитих студентів судячи з опису, і там тільки планують відкрити

Дякую за поширення досвідом! Чи було важко стрибати на С++ в порівнянні з C#? Мені C# зайшов сходу, але от С++ якось...не по-домашнему там все. І ще цікаво: над якими іграми працював на юніті і після переходу на анріал? Як до цього ставилися роботодавці, що ти світчер 😆?

На мою особисту думку в анріалі с++ так само «багато» як й в юніті с# (звісно якщо ви не працюєте з власними розширеннями двигуна наприклад), тобто юніті не дозволяє використовувати весь потенціал с# так само, як і с++ в анріалі (хоча якщо працюєте з власним/чистими с++ класами — це можливо). Стрибати було не важко, поставив «*» чи «&» та й пішов :) Звісно для кращого розуміння потрібно знати, як воно всередині працює. В анріалі є багато своїх власних напрацювань, наприклад, там є свої власні смарт пойнтери чи мув семантика.

В юніті здебільшого працював з мобільними мережевими кросплатформеними іграми/додатками. В анріалі довелось працювати з VR тренінгами, потім ігри ААА класу.

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

Підписатись на коментарі