Chcą zabrać twórcom gier jedno z najważniejszych narzędzi. To może zaboleć bardziej niż AI [WYWIAD]

Nowoczesny silnik do tworzenia gier wideo nie jest magią. Nie wystarczy włączyć przełącznika, żeby gra wyglądała i działała lepiej. Czasem źle użyta technologia nie pomaga, a jedynie przeszkadza. Czasem funkcja pokazana na prezentacji wymaga decyzji technicznych i projektowych podjętych bardzo wcześnie, bo inaczej zamiast pomagać, zaczyna szkodzić wyglądowi albo wydajności. Czasem problemem nie jest samo narzędzie pokroju Unreal Engine, tylko sposób, w jaki zespół z niego korzysta. O tym właśnie rozmawiałem z Grzegorzem Wątrobą, programistą specjalizującym się w portowaniu i optymalizacji, który aktualnie rozwija swoją własną grę Foxy Dumplings.

Przez 16 lat przepracowałem kilkanaście firm, ponad 20 projektów i to na Unity, na Unrealu, na wewnętrznych silnikach, również na produktach Epica. Od Unreala 3 w górę przejechałem większość konsol od 2005 roku i głównie zajmuję się portowaniem oraz optymalizacją – mówi Grzegorz Wątroba.

Portowanie łatwo wyobrazić sobie jako techniczne “przeniesienie gry” z jednej platformy na drugą. W praktyce bardzo często jest to moment, w którym wcześniejsze decyzje techniczne przestają być teorią, a zaczynają boleć. Jeśli logika gry jest źle rozłożona, jeśli projekt nie korzysta sensownie z wielu wątków, jeśli na scenie działa zbyt wiele niepotrzebnych elementów, jeśli zespół użył nowych funkcji silnika bez zrozumienia ich kosztu, to konsola szybko przypomni, że nie jest wcale takim wydajnym sprzętem, jakbyśmy tego chcieli.

Czytaj też: Unreal Engine 6 zniszczy najlepszą zaletę silnika. Teraz ciekawi mnie jedno – co uratuje devów?

Wątroba mówi, że przy okazji portowania doradza też zespołom wcześniej, zanim pojawi się konieczność gaszenia pożarów.

Doradzam, jeżeli chodzi o systemy produkcyjne, jak zorganizować pracę i architekturę kodu, tak żebym był niepotrzebny na końcu, gdzie trzeba gasić pożary.

Unreal Engine nie jest zestawem magicznych przełączników

Jednym z powtarzalnych błędów, które Wątroba widzi w projektach na Unrealu, jest traktowanie zaawansowanych funkcji silnika jak gotowych rozwiązań działających po kliknięciu jednej opcji. Najlepszym przykładem jest Nanite. Sama technologia nie jest problemem. Problemem jest za to przekonanie, że jej włączenie automatycznie oznacza lepszy projekt.

Są wspólne błędy, niezależnie od rozmiaru firmy. W Unrealu bywa włączonych zbyt dużo elementów, które są absolutnie niepotrzebne na scenie, a bardzo dojeżdżają wydajność.

Potem pada przykład nowych funkcji silnika.

Są źle skonfigurowane nowe zabawki z Unreala typu Nanite, gdzie ktoś myśli, że przy tych zaawansowanych feature’ach wystarczy jeden przełącznik. Absolutnie tak nie jest. Trzeba często przygotowywać wiele elementów silnika, żeby dobrze wykorzystać jakąś funkcjonalność.

To akurat bardzo dobrze tłumaczy komplikację w rozmowach o silnikach gier. Z zewnątrz widzimy demo, obietnicę i efekt skrojony idealnie pod konkretne prezentacje. Od środka jednak każda funkcja jest częścią większego systemu. Można jej użyć dobrze, można użyć źle, a można też użyć jej dlatego, że jest modna. W tym ostatnim przypadku silnik nie tyle pomaga, ile dokłada kolejny poziom komplikacji.

Później wychodzi, że włączenie chociażby Nanite’a przynosi więcej szkody niż pożytku.

Z takich doświadczeń Wątroba zbudował publiczny zbiór notatek, który nazywa “biblią optymalizacyjną”. Nie jest to skrypt, który magicznie analizuje projekt. Jest to praktyczna baza wiedzy, czyli coś, czego często brakuje między oficjalną dokumentacją a prawdziwą produkcją.

Na GitHubie zamieściłem tak zwaną biblię optymalizacyjną, w której opisuję swoje notatki. 16 lat z Unity i Unreal w jednym miejscu. Często to są rzeczy, których nie znajduje się w oficjalnej dokumentacji, a które ja znajdowałem po prostu grzebiąc w silniku.

Ten kontekst jest ważny, bo rozmowa o przyszłości Unreala bardzo łatwo zamienia się w walkę dwóch obozów. Jedni widzą w Blueprintach źródło bałaganu i słabej wydajności. Drudzy widzą w nich narzędzie, które przez lata pozwalało designerom szybko prototypować mechaniki. Wątroba nie mieści się wygodnie w żadnym z tych obozów. Mówi jednocześnie dwie rzeczy – Blueprinty potrafią być problemem w finalnej grze, ale ich porzucenie może być wyzwaniem dla samej produkcji.

Blueprinty pomagają znaleźć grę. Potem potrafią ją spowolnić

Gdy rozmowa schodzi na wydajność i wielowątkowość, Wątroba podaje przykład problemu, który potrafi szczególnie mocno zaboleć na konsolach. Tutaj nie chodzi już o ładniejszą grafikę, tylko o samą mechanikę gry.

Pierwsza i najważniejsza rzecz, w której są duże braki, to brak użycia wielowątkowości w sensowny sposób. Gra na konsoli była prawie niemożliwa, bo wykorzystywano tylko jeden rdzeń do samej mechaniki gry.

Pojawiają się Blueprinty. Wątroba nie twierdzi, że zawsze są winne, ale wskazuje, że mogą być częścią problemu.

Blueprinty też mogą działać wielowątkowo pod pewnymi względami, ale tak, to może być jeden z efektów.

Po chwili mówi rzecz, która na pierwszy rzut oka wygląda jak prosta krytyka wizualnego skryptowania.

Moim zdaniem Blueprinty nadają się tylko i wyłącznie do prototypowania i tak wszystko powinno być przepisane na kod.

Gdyby zatrzymać się w tym miejscu, łatwo byłoby napisać tekst o tym, że Wątroba chce końca Blueprintów. Tyle że byłby to dokładnie zły wniosek. Pytam więc, czy cieszy się z kierunku, w którym Epic chce prowadzić Unreal Engine 6, czyli większego nacisku na Verse i stopniowego odchodzenia od Blueprintów. Odpowiedź jest jednoznaczna.

Nie. Absolutnie nie. Porzucenie Blueprintów to jest wyrugowanie szybkiego prototypowania gier.

W tym paradoksie kryje się najciekawsza część całej sprawy. Narzędzie może być złe jako finalna forma implementacji, ale bardzo dobre jako narzędzie szukania gry. Produkcja nie zaczyna się od idealnego kodu. Zaczyna się od pomysłu, który trzeba sprawdzić. Czy mechanika ma sens? Czy gracz rozumie interakcję? Czy system ma potencjał? Czy warto inwestować w niego czas programistów?

Blueprinty przez lata pomagały odpowiadać na te pytania szybko.

Dzięki Blueprintom, dzięki wizualnemu skryptowaniu, można bardzo szybko przejść z idei do realizacji bez użycia programisty. Tym samym dosłownie można wyklikać grę.

Według Wątroby to ogromna wartość na etapie prototypowania.

To jest bardzo cenne, żeby szybko zweryfikować jakiś pomysł, zanim zaangażuje się cały zespół produkcyjnie. Szybkie prototypowanie to jedna z największych zalet Blueprintów. Potem, kiedy już wiadomo, jakie systemy działają, można dać to programistom, żeby przepisali je na kod, żeby były wydajne.

W tym miejscu temat przestaje dotyczyć wyłącznie jednego narzędzia. Zaczyna dotyczyć struktury pracy w zespołach. Jeśli designer traci narzędzie, które pozwala mu szybko sprawdzić mechanikę bez angażowania programisty, to z automatu zmienia się cały rytm produkcji. Ryzyko jest ogromne, bo ileż to pomysłów umrze wcześniej, bo droga od idei do prototypu stanie się bardziej wymagająca na wielu różnych frontach?

Technical design może oberwać rykoszetem

Wątroba mówi wprost, że odejście od Blueprintów może uderzyć w technical design. Czyli w tę przestrzeń między czystym projektowaniem a klasycznym programowaniem.

Porzucenie zupełnie Blueprintów mi bardzo nie pasuje, bo przez to coś takiego jak technical design może zostać trochę wyrugowane z branży. Designerzy musieliby się nauczyć języka skryptowania, czyli Verse’a. On ma też swoje ograniczenia.

Technical Designer to osoba, która potrafi z idei na papierze zrealizować ją w Visual Scriptingu. Jest w stanie zaimplementować całą mechanikę bez wiedzy o programowaniu.

Wątroba rozdziela jednak pojęcia. Praca w Blueprintach może być formą rozwiązywania problemów, ale nie powinna automatycznie oznaczać, że ktoś jest programistą w klasycznym sensie.

Programowanie to nie jest stricte pisanie kodu, tylko rozwiązywanie problemów w uregulowany sposób za pomocą algorytmów i struktur danych. Do pewnego stopnia Blueprinty to programowanie. Ja to nazywam wizualnym skryptowaniem, żeby odpowiednio to rozdzielić.

Najważniejsze jest jednak nie nazewnictwo, ale praktyka. Blueprinty pozwalały szybciej iterować. Verse może uporządkować część procesu twórczego, ale będzie wymagać innego rodzaju kompetencji.

Zysk po przepisaniu na kod potrafi być ogromny

Wątroba nie broni Blueprintów. Nie udaje, że powinny zostać wszędzie. Gdy pytam, ile można zyskać po przepisaniu logiki z Blueprintów na kod, odpowiada krótko:

Kilkunastokrotnie.

Potem tłumaczy to na przykładzie pętli, wielowątkowości i budżetu klatki.

Blueprinty bardzo źle sobie radzą z pętlami. Kiedy mamy PlayStation, które ma 8 rdzeni i 16 wątków na Unrealu będzie 8 do 10. Kiedy dobrze rozpiszemy strukturę i elementy są niezależne, jesteśmy w stanie zrobić foreach wielowątkowego [pętlę która wykonuje się nie na jednym, a na wielu wątkach – dop. red.].

Przy 60 klatkach na sekundę gra ma około 16 milisekund na jedną klatkę, więc każda mechanika wykonywana zbyt długo zaczyna być problemem.

Przy 60 FPS-ach mamy 16,7 milisekund na klatkę. Kiedy dobrze to zrównoleglimy i przepiszemy na kod bez narzutu blueprintowego, możemy mieć mechanikę, która zajmuje jedną dziesiątą milisekundy.

Ten fragment dobrze tłumaczy, dlaczego można jednocześnie bronić Blueprintów i uważać, że nie powinny zostawać w newralgicznych miejscach finalnej gry. Wydajność nie ma sentymentu. Jeśli prototypowa logika zostaje w produkcie tam, gdzie powinna pojawić się wydajna implementacja, to z automatu zamienia się w dług technologiczny.

Verse, AI i przyszłość, której Epic nie sprzeda jako problemu

Oficjalnie Epic chce, aby Unreal Engine 6 połączył klasycznego Unreala z Unreal Editor for Fortnite i przeniósł model tworzenia gameplayu w stronę Verse oraz Scene Graph. Blueprinty i aktorzy mają pozostać we wczesnych wersjach UE6, ale docelowo mają zostać oznaczone jako przestarzały kierunek rozwoju, gdy nowy framework dojrzeje. W praktyce oznacza to nie nagłe wyłączenie narzędzia, lecz wieloletnią migrację.

Wątroba widzi w tym także wątek związany ze sztuczną inteligencją. Zaznacza, że Epic oficjalnie nie mówi o porzucaniu Blueprintów ze względu na AI, ale jego zdaniem tekstowy Verse jest dla narzędzi sztucznej inteligencji znacznie bardziej naturalny.

Blueprinty są zapisywane i serializowane w sposób binarny, którego AI ma problem rozkodować i rozczytać. W momencie, kiedy przechodzimy na Verse, który jest strukturą tekstową, po pierwsze ładnie się to synchronizuje w systemie kontroli wersji, po drugie AI jest w stanie to lepiej przeanalizować.

To nie jest oficjalna deklaracja Epica, tylko wniosek developera patrzącego na dwa równoległe trendy – przejście na Verse i coraz mocniejsze wykorzystanie AI w narzędziach produkcyjnych.

To, że będą mocno wykorzystywać AI i będzie to zaszyte jako domyślny element silnika, już zostało powiedziane. To jest logiczny skutek tych dwóch rzeczy. Jeden i jeden dało dwa.

Verse też nie jest jednak cudownym rozwiązaniem. Wątroba miał okazję pracować z nim w kontekście Unreal Editor for Fortnite i podchodzi do tej technologii ostrożnie.

To jest pewnego rodzaju uproszczenie pracy. Nie trzeba o wielu rzeczach myśleć, ale każda automatyzacja, każde uproszczenie jest równoległe ze stratą wydajności. Dlatego C++ dalej zostanie najbardziej wydajną formą pisania kodu.

Największą obietnicą Verse’a ma być łatwiejsze zarządzanie pamięcią, stanem i współbieżnością. Wątroba streszcza to tak:

Będziemy mieć transakcyjne zarządzanie pamięcią i wątkami, czyli twórcy nie będą musieli myśleć o synchronizacji wątków, tylko wszystkie działania będą potencjalnie wielowątkowe.

Po chwili dodaje jednak własny sceptycyzm.

Znając programowanie wielowątkowe, na razie tego nie widzę. Jestem bardzo ciekaw, jak uda im się zrobić, żeby pamięć nie pofragmentowała się skrajnie, przez co ostatecznie będzie to miało negatywny efekt dla wydajności.

W tym miejscu futurystyczna obietnica zderza się z doświadczeniem ludzi pracujących przy realnych produkcjach. Łatwo powiedzieć, że silnik sam rozwiąże współbieżność, pamięć i synchronizację. Trudniej zrobić to w taki sposób, żeby nie powstała kolejna warstwa abstrakcji, która wygląda dobrze w teorii, ale w praktyce zabiera kontrolę tam, gdzie developerzy najbardziej jej potrzebują.

Wątroba nie twierdzi, że UE6 będzie porażką. Mówi raczej, że nie wierzy w bezbolesną magię pierwszych wersji i trudno się temu dziwić.

Patrząc na to, jak Epic implementuje swoje funkcjonalności i że większość rzeczy w piątce dalej nie jest dobrze zrobionych, nie wierzę, że pierwsze wersje Unreala 6 będą działały z sensem.

Miałem okazję pracować w Unrealu 3, 4 i 5. Po trzecim Unrealu znajdowałem komentarze w kodzie, gdzie było podpisane: do naprawy natychmiast. Ten sam komentarz widziałem w piątce, w jakimś starym module. Jak oni przez 20 lat niektórych rzeczy nie poprawiają, to nie wierzę, że nagle odmieni im to wszystko i naprawi wszystkie problemy z silnikiem.

Blueprinty są więc dobrym symbolem tej zmiany, bo pokazują cały paradoks współczesnego gamedevu. Z jednej strony wszyscy chcą wydajniejszych, bardziej uporządkowanych i lepiej skalujących się gier. Z drugiej jednak gry powstają przez szybkie sprawdzanie pomysłów, prototypowanie, pomyłki i iteracje. Jeśli wyrzucimy z tego procesu narzędzia, które pozwalały designerom szybko przechodzić od idei do działającej mechaniki, to możemy zyskać czystszy technicznie model, ale stracić coś po drodze.

Czytaj też: Programista w czasach sztucznej inteligencji. Spytałem w IBM, kim musi być dziś junior

Dlatego pytanie o koniec Blueprintów nie jest tylko pytaniem o jeden system w Unreal Engine. Jest pytaniem o to, kto będzie mógł robić gry, jak szybko będzie mógł sprawdzać pomysły i ile kontroli oddamy narzędziom, które obiecują uproszczenie pracy, a finalnie mogą ją zmienić nie do poznania. UE6 może więc być przyszłością. Tyle że w gamedevie przyszłość rzadko zaczyna się od jednego przełącznika. Częściej zaczyna się od kosztów, kompromisów i błędów, które ktoś musi potem zoptymalizować.