Всяко "Пътешествие на героя" достига до онзи повратен момент, в който трябва да оставиш познатото Графство зад гърба си и да пристъпиш в необятната, непозната пустош. Повече от осем години Unity беше мой верен спътник. Заедно пресякохме долини на отчаянието, издадохме комерсиални заглавия и изградихме устойчиво инди студио. Но след като последният ми голям проект, Fabled Lands, най-накрая достигна своя "край" (не, не се притеснявайте! не е затворена страница, но стигна до някакъв логичен завършек за момента), се озовах на кръстопът.
Когато управляваш напълно независимо инди студио, анализирането на възвръщаемостта на инвестициите (ROI) и техническото бреме (technical debt) е въпрос на оцеляване. Скорошните, добре документирани промени в екосистемата на Unity не се усещаха просто като поредната драма в индустрията; те нанесоха огромен удар върху доверието ми, засягайки пряко прехраната ми и дългосрочната устойчивост на работата ми. Освен това, между постоянното спиране на поддръжката за стари функции (deprecation), недовършените посоки на развитие и все по-тежката работа на самия редактор, старият ми спътник просто не се усещаше по същия начин.
Имах нужда да си върна контрола върху инструментите си. И тук на сцената излиза Godot 4. Фактът, че Godot е напълно безплатен софтуер с отворен код (FOSS) е абсолютно невероятно за нивото, което предлага. Няма лицензионни такси, няма внезапни промени в условията за ползване (Terms of Service) и няма корпоративни шефове, пред които да отговаряш. Ако нещо се счупи, буквално мога да прегледам изходния код на енджина. За соло инди разработчик, управляващ бизнес, това ниво на свобода и сигурност е безценно.
Днес, докато разработвам следващата си наративна RPG игра, Кървав меч (Blood Sword), мога уверено да кажа, че този енджин ми върна радостта от разработването на игри. Той искрено ме мотивира да отварям редактора всяка сутрин и просто да работя.
Но не се хвърлих просто на сляпо. Ето един дълбок поглед в това как опипвах почвата, как структурирах новия си технологичен стек и как в крайна сметка изградих увереността да посветя многогодишна работа на този енджин.
Преди да посветя следващите си 4-5 години в разработване на своята RPG игра на нов енджин, трябваше да разбера дали Godot наистина може да се справи с реалния работен процес на един инди разработчик. Така че, вместо прост прототип, се захванах с три отделни по-малки проекта, за да подложа енджина на тест.
MVP (Минимално жизнеспособен продукт): Джобно RPG
Първият ми опит беше просто, но сложно помощно приложение (companion app) за книга-игра. По същество това беше джобна ролева игра, пълен набор от статистики на героя, рангове, дървета на уменията, екипировка, лимити на инвентара, магии и автоматизирана текстова битка. Перфектен пясъчник за един програмист да си поиграе и да види как енджинът се справя със създаването на свежи RPG механики от нулата!
Пренаписванията: Съновидение и Битката за Мрак
След това пренаписах два от миналите си проекти из основи: мобилното ми приложение от 2017 г. Съновидение (Transomnie) и пълно пренаписване на по-малката ми 2D десктоп игра, Битката за Мрак (Battle for Murk).
За Съновидение ми бяха нужни само 2500 реда код, за да се справя с потребителския интерфейс (UI), XML парсването, системите за вход (input) и версиите за масово разпространение. Междувременно Битката за Мрак ми позволи да тествам поточните линии за десктоп и Steam. И докато Мрак успешно доказа, че процесът по публикуване и разпространение работи, на практика липсващите в момента играчи на тази отдавна остаряла игра, означава, че все още не съм успял да проверя как Godot се справя с хиляди напълно различни компютърни хардуерни конфигурации (повече за това по-късно).
Но от чисто гледна точка на разработката, и при трите проекта резултатите бяха повече от показателни:
Godot просто не ти се пречка. Редакторът е забележително лек; върви прекрасно дори на моя MacBook Pro от 2015 г., заедно с напълно функционален дебъгер.
Работейки години наред с уеб технологии, Java и C#, старата UI система на Unity често се усеща като архаичен Java бехемот от ерата на Netbeans. Откъм производителност те ужасява всеки път, когато Garbage Collector-ът се задейства или целият Canvas се "замърси". UI-ят на Godot, за сметка на това, се усещаше превъзходно. Използваш много повече обекти (Nodes) за един проблем, отколкото би в Unity, но цената им като ресурс е относително ниска и вършат работа чудесно. Както казват младите, енджинът просто има "rizz" - има чар, който ти позволява да се съсредоточиш върху правенето на играта.
Първоначално имах резерви относно преминаването към динамично типизиран език като GDScript, липсваха ми интерфейсите и generics. Но идеологията на Godot за програмиране на повече от един език (cross-scripting) е брилянтна. Подходът ми към кода е прост: Дълбока, управлявана от данни композиция (Deep data-driven composition).
Докато Unity e всеизвестен с това, че базира архитектурата си на компоненти на ниво Сцена (прикачайки MonoBehaviours към GameObjects), правенето на същото нещо чисто на ниво данни (чрез ScriptableObjects) може бързо да стане тромаво. И затова, вместо да правя всичко на един език в Godot, ги смесвам, за да взема най-доброто от двата свята:
Преодоляване на различията: Прагматичен marshalling
За да държа C# и GDScript напълно отделени, използвам събитийно-ориентирана архитектура (Event-Driven Architecture) с глобален EventDispatcher Autoload.
Но прехвърлянето на сложни обекти между езиците може да създаде сериозни места за потенциални проблеми. Идвайки от корпоративен софтуер, може би по подразбиране бихте търсили стриктна типизация навсякъде, но инди разработката изисква прагматични компромиси. За да свържа езиците, използвам вградените в Godot Variant Dictionaries. Това жертва строгото типизиране, но радикално ускорява соло разработката и напълно заобикаля разходите по маршалирането (marshalling overhead).
Също така следя отблизо напредъка на общността. В момента има активен PR за внедряване на система от характеристики (traits) в GDScript. Въпреки че все още не е предвиден за предстоящ релийз, изглежда невероятно яко и показва, че енджинът непрекъснато се развива към по-чист, по-модулен код.
Интерактивното разказване на истории е в основата на Prime Games. Използвам open-source езика на Inkle #ink от 2017 г. насам, а Кървав меч е мащабна игра - 10 пъти по-голяма от стандартните benchmark проекти.
Godot има две страхотни Ink интеграции: една на чист GDScript (inkgd) и C# решение (godot-ink). Въпреки това, за големи истории, официалните бенчмаркове на inkgd отбелязват, че портът на чист GDScript може да бъде до 50 пъти по-бавен при алокацията на голям брой обекти.
Поради начина, по който Godot с лекота ти позволява да смесваш езици, решението беше просто. Интегрирах високопроизводителното C# godot-ink решение, за да поеме тежката работа по генерирането на историята. Но не просто включих интеграцията – изградих персонализиран C# парсер на текст върху нея.
Тъй като RPG-тата изискват сложни мутации на състоянието на играта (gamestate), моят парсер прихваща вътрешните ми персонализирани Ink тагове (като >>>STATS, >>>ENDURANCE или >>>COMBAT) директно от ръкописа. C# слоят действа като мозък, превеждайки тези наративни реплики в логика, докато безпроблемно предава финалните визуализации към моя GDScript UI слой. За играча това е като мигновена магия. Проблемът решен, нулеви спадове в производителността и невероятно мащабируема поточна линия за текст с избори.
За съжаление, не всичко е цветя и рози. Най-страшната част от изучаването на нов енджин не е кодът - това е стабилността му "в дивото".
Този юни ще пусна първото публично демо на Кървав меч. Това ще бъде върховното кръщение в битка. Това, което трябва да разбера е колко точно стабилна е една игра, направена на Godot, когато е изложена на хиляди играчи. Ще се сблъскам ли с неочаквани крашове? Как енджинът ще се справи със съвместимостта на фона на разнообразното море от хардуерни конфигурации на геймърите?
Но след като успешно портнах и пуснах онези по-малки проекти през последната година, се чувствам подготвен да се справя с каквото и да ми поднесе Дивият Запад. Вместо плашещо неизвестно, това предстоящо демо е едно огромно и вълнуващо уравнение, чакащо да бъде решено от новия ми технологичен стек. Единственото ми оставащо притеснение е как един соло програмист ще се справи с поддръжката за Nintendo Switch, но знам, че това вече е много по-лесно достъпно в екосистемата.
Графството е зад гърба ни. Пустошта ни очаква! Очаквайте демото на Кървав меч този юни!
English
Коментари