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

Мене звати Костянтин Допіра, я один зі співзасновників AtomTeam та один з творців світу Atom RPG. Загалом у компанії я програміст, але коли ти інді, твоя роль може бути будь-якою, залежно від поточних проблем. Однак зараз не про це. На мою думку, немає нічого більш провокативного, ніж статті про розробку власних рушіїв, власну реалізацію «стандартних» бібліотек тощо, бо завжди простіше купити готовий інструмент. Але мені захотілося трішки штурхонути спільноту статтею про те, як ми в AtomTeam запровадили власну систему «візуальних скриптів» для ігор Atom RPG та Atom RPG: Trudograd.

Що це за ігри

Atom RPG та Atom RPG: Trudograd — це рольові ігри, події в яких відбуваються в альтернативній реальності у світі після ядерної війни на території СРСР.

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

Для нас також важливо сказати про те, що прямо зараз ми працюємо з компанією «Шлякбитраф» над українським перекладом.

Чому та навіщо

Для початку я хотів би вказати на те, що в іграх серії Atom RPG дуже багато тексту: майже кожний NPC має свій діалог. До того ж у світі гри багато «неживих» інтерактивних об’єктів, з якими також є «діалогова» взаємодія. Якщо говорити мовою цифр, то це близько мільйона слів для Atom RPG та близько 500 000 слів для Trudograd. Ба більше, діалоги — це не тільки текст, а ще й логіка переходів з однієї фрази до іншої через умовні та безумовні переходи. Іншими словами, це деревоподібна структура, де переходи по гілках відбуваються через вибір користувача, перевірками на якісь значення змінних тощо.

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

Доволі логічною видається ідея про те, що треба придумати інструмент, який би міг зрозуміти та з яким би міг працювати будь-хто. На жаль, в Unity «з коробки» чогось схожого немає, тож один з наших програмістів вирішив власноруч розробити систему візуальних нод на стандартних GUI-елементах Unity. А за ідеями далеко ходити не треба, адже всі ці «блюпрінти», «віжуал скриптинг» тощо використовують у розробці роками. Тут ще ми не знали, як сильно змінить нашу розробку ця система...

Наша версія редактора

Діалоги бувають різними

Що далі

А далі з’явилася ідея використовувати цю систему не тільки для діалогів. Спочатку здавалося, що то не дуже вдала думка, бо написати, а що важливіше, налагоджувати код C# та шукати помилки в Visual Studio зручніше, але ми спробували. У результаті маємо дві гри, вся ігрова логіка яких написана на візуальних нодах.

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

• Система гнучка, дуже легко додавати нові функціональні ноди.
• Система проста та візуальна, наприклад, людина без знання Unity та програмування через декілька тижнів почала писати перші скрипти, а через півтора місяця вже працювала в команді.
• Система ідеальна для розробників модів для гри (у нас є офіційний modkid і візуальні скрипти — це просто подарунок для спільноти).
• Запуск сцени в Unity займає значно менше часу, не треба перезбирати C# файли, особливо це помітно коли проєкт розрісся до десятків гігабайтів.
• Розділивши логіку рушія та ігрову логіку, ми отримали кращий та чистіший код на C#.

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

• Скрипти всіх об’єктів запускаються (відпрацьовується нода Start) лише на старті або під час завантаження сцени, зміни дня чи ночі, а також при «прокрутці» часу. Також можна перезапустити скрипт або всі скрипти сцени із самого скрипту.
• З попереднього пункту випливає, що скрипт може перерватися та перезапуститися у будь-який момент: save/load, зміна день/ніч тощо. Це не повинно позначатися на персонажі: якщо він йшов кудись, то має продовжувати йти, якщо сидів — має продовжувати сидіти. Ми часто застосовуємо підхід «стейтів», розбиваючи логіку персонажа на фази.
• У кожної ноди є свій час життя, якщо в скрипті запустити декілька разів ноду (не тільки в циклі, а й просто через розгалуження Dummy), буде створено декілька її інстансів, хороший підхід для генераторів.
• Скрипти можуть перезапускати себе окремим інстансом на тому ж об’єкті, породжуючи таким чином щось на зразок багатопотоковості, якщо комусь такий підхід подобається.

Висновки

У нашому випадку філософське питання «писати своє чи шукати готове» пройшло через чітке усвідомлення потреби в дуже спеціалізованому інструменті, який пізніше перетворився на більш потужний та універсальний інструмент. Звичайно ж, шукали й щось готове, що можна було взяти за основу. Потім шукали окремі приклади для реалізації графічних елементів на Unity IMGUI тощо. Тобто витратили на цю систему доволі багато часу. Чесно скажу, краще і простіше купити готове. І якби ми знайшли готове, скористалися б цим. Це моя думка та порада всім, особливо маленьким студіям. Адже основне завдання ігрової студії — це писати саме гру. А найбільша проблема під час розробки — це брак часу, тож його треба витрачати розумно.

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

Хай щастить!

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