Twórca Dawnwalkera odpowiada: kiedy kopniemy kompilację w shadera i skąd sukces Unreal Engine

Ekipa renegatów z CD Projekt RED przebojem weszła do pierwszej ligi polskich twórców gier. Ich The Blood of Dawnwalker znalazło milion nabywców w dwa dni od premiery. Produkcja ze średnią na poziomie 83% w serwisie Metacritic otrzymała od nas w pełni zasłużone 8+, imponując odważną mechaniką upływu czasu. No i możliwość wcielenia się w wampira zawsze ma w sobie to coś.

Teraz, gdy premierowy kurz opada, usiadłem do rozmowy z Tomaszem Wójcikiem, CTO w studio Rebel Wolves. Mając po drugiej stronie fachowca z prawdziwego zdarzenia, porozmawialiśmy o kwestiach nurtujących wielu graczy: o co chodzi z tą cholerną kompilacją shaderów, ile klatek na sekundę jest w sam raz, czy upscalery oraz generatory fps mają sens, a także w czym tkwi fenomen Unreal Engine.

Szymon Radzewicz, Spider’s Web: Ależ jestem ciekaw twojej perspektywy na temat upscalerów i generatorów klatek. Odbiór ze strony graczy jest dwojaki. Z jednej strony optymalizują płynność, z drugiej słychać mnóstwo krytyki na opóźnienia i „puste” klatki

Tomek Wójcik, CTO Rebel Wolves: Przede wszystkim mocno rozgraniczyłbym obie rzeczy. Upscaling i generatory klatek to coś zupełnie innego. Zacząłbym od upscalingu, bo to pomysł, który pojawił się znacznie wcześniej.

Należy zdać sobie sprawę z tego, jaka jest dokładna różnica pomiędzy rozdzielczością Full HD a 4K. 4K to rozdzielczość oferująca dwa razy więcej pikseli w poziomie i dwa razy więcej pikseli w pionie, co ostatecznie przekłada się na cztery razy więcej pikseli do wyrenderowania niż w Full HD. Upraszczając: karta graficzna musi wykonać cztery razy więcej pracy, żeby wygenerować obraz w 4K. Percepcyjnie, dla gracza, niekoniecznie przekłada się to jednak na aż czterokrotnie lepszą jakość. Owszem, obraz w 4K jest ładniejszy i przyjemniejszy, ale ta różnica nie jest na tyle drastyczna, by warto było płacić za to czterokrotnie większym obciążeniem sprzętu.

Cały pomysł z upscalerami polega na tym, by w tej najwyższej, natywnej rozdzielczości renderować tylko te elementy, które absolutnie tego wymagają – na przykład dwuwymiarowy interfejs użytkownika (UI) albo teksty. Wiadomo, jak przeskalujemy tekst, nie wygląda to dobrze. Natomiast samą "ciężką" scenę 3D renderujemy w nieco niższej rozdzielczości, następnie stosujemy upscaling (podbicie rozdzielczości), a na to nakładamy wyrenderowane natywnie UI. Zaoszczędzoną w ten sposób "moc" karty graficznej możemy przeznaczyć na przykład na poprawę jakości tej sceny trójwymiarowej: lepsze oświetlenie, wyższą jakość cieni i tym podobne.

Dlatego warto się zastanowić: chcemy płacić mocą sprzętową za wyższą rozdzielczość natywną, która wcale nie daje aż tak zauważalnego efektu, czy lepiej skorzystać z upscalingu i stworzyć ładniejszą scenę 3D? Moim zdaniem to bardzo przydatna technologia, pozwalająca graczom osiągać świetne efekty bez przymusu wydawania fortuny na sprzęt, który by to natywnie obsłużył. Nawet biorąc konsolę, taką jak PlayStation 5 podłączoną do telewizora 4K – gdyby konsola nie używała żadnego upscalingu, scena musiałaby być znacznie uboższa, aby karta podołała rozdzielczości.

Sz.R.: A kwestia samych generatorów klatek? Często padają argumenty, że są to klatki tworzone sztucznie, bez zależności od działań gracza. Jak to oceniacie jako deweloperzy?

T.W.: Z generatorami klatek jest nieco inaczej. Faktycznie pozwalają one na dodanie relatywnie małym kosztem dodatkowych fps-ów. Koszt "zgadnięcia", jak powinna wyglądać kolejna klatka, jest dużo niższy niż jej faktyczne wyrenderowanie od podstaw.

Jednakże problem w tym, że w ten sposób nie zmieniamy tzw. input laga (opóźnienia reakcji na polecenia gracza). Jeśli gra wyrenderuje jedną, natywną klatkę (na bazie reakcji gracza), a trzy kolejne wygeneruje tylko za pomocą przybliżenia i algorytmów, no to mamy do czynienia z klatkami sztucznymi. Czyli takimi bazującymi na założeniach, a gra "nie czyta" w tym czasie naszych kliknięć klawiatury. Input lag zostaje na takim poziomie, jaki był przed wygenerowaniem klatek. Jeśli graliśmy w 30 fps-ach i włączymy generator, obraz będzie wyglądał płynniej, ale reakcja na przyciski wciąż będzie działała tak, jak w 30 fps-ach.

Zatem rodzi się pytanie – czy to faktycznie poprawia przyjemność z rozgrywki? Zwiększa to płynność wizualną - super - ale input lag zostaje bez zmian. Oczywiście ma to sens z perspektywy graczy, jeśli zależy im głównie na gładkim obrazie. My jednak, jako deweloperzy, dużo bardziej chwalimy upscalery, bo dzięki nim możemy dać ludziom przepięknie wyglądającą grę na słabszym sprzęcie.

Czy w 2026 roku da się stworzyć grę w pełni natywną? Taką, w której nic nie jest "oszukiwane" pod względem renderowania rozdzielczości. A może gry wymagają tylu zasobów, że bez tych narzędzi ani rusz?

Oczywiście, że się da. Tylko trzeba sobie zadać pytanie o koszty – i to te dosłowne. Trzeba zbudować sobie najsilniejszy komputer na świecie, a mimo to rezultat nie będzie satysfakcjonujący. Jeżeli postawimy obok siebie dwa ekrany – jeden z grą w pełni natywną i słabszą grafiką, a drugi z nowoczesnym systemem oświetlenia wykorzystującym mądrze upscaling – ten z upscalerem będzie prezentował się ładniej i po prostu działał lepiej. Oczywiście można całkowicie wyłączyć upscaling w opcjach, jeśli ktoś jest takim purystą.

Pytanie, czy warto? Na konsolach takich dylematów raczej już nie ma – układy bywają po prostu niewystarczające, żeby odpalać najnowsze, wielkie hity w natywnym, bezkompromisowym 4K.

To ile klatek na sekundę jest "grywalnym minimum"? Przez lata mówiło się o 30 klatkach, ale dzisiaj zejście poniżej konsolowych 60 fps uchodzi za porażkę. Gdzie leży sweet spot?

To kwestia bardzo indywidualna. Sam na przykład jestem z pokolenia, które skakało z radości, jeśli miało 20 klatek w grze. W związku z tym absolutnie mogę uznać 30 klatek na sekundę za wartość komfortową. W pełni rozumiem jednak graczy, którzy do płynnego grania wymagają tych "żelaznych" 60 fps. Zwłaszcza, że jeśli raz spróbuje zagrać w wyższym klatkażu, powrót do 30 klatek bywa naprawdę bolesny.

Naszym celem od zawsze było, by grę optymalizować na tyle szeroko, by każdy mógł bawić się tak, jak lubi. Stąd na konsolach mamy w Dawnwalkerze tryby nastawione na płynność z 60 klatkami. Wydaje mi się, że te 60 fps-ów to optymalny wynik do osiągnięcia, bo odpowiada standardowemu odświeżaniu większości telewizorów i monitorów.

Skoro mam pod ręką eksperta, muszę zapytać: kompilacja shaderów (shader compilation stutter). Czy to cholerstwo odejdzie kiedyś do lamusa w grach na PC?

Z chęcią to wyjaśnię. Skąd w ogóle pomysł, by kompilować kod dla shadera? Shader to krótki program uruchamiany na karcie graficznej. Kart jest jednak na PC mnóstwo i każda działa odrobinę inaczej. Z kolei układ, który zleca to zadanie, to procesor komputera. Gdy gracz idzie do nowej, niespodziewanej strefy na mapie, a karta nie ma skompilowanego shadera, procesor sprzętowy musi na chwilę zatrzymać resztę operacji – a ma ich sporo, bo zajmuje się m.in. symulacją i logiką samej gry. Wywołanie kompilacji kodu zabiera jego moc w 100%, przez co gra gubi klatki i w efekcie zacina.

Skąd to się wzięło na pecetach i dlaczego kompilacja shaderów właściwie nie istnieje na konsolach? Problem wynika z niejednorodności sprzętu na platformie PC. Na konsolach (np. PlayStation 5 czy Xbox) mamy sztywno określoną specyfikację i architekturę. Możemy tam skompilować te same shadery u nas w studiu deweloperskim i zaserwować je graczom w gotowej paczce, przed pobraniem gry. Na komputerach architektur CPU i GPU są tysiące, dlatego kod na PC w większości przypadków musi się fizycznie skompilować na maszynie docelowego gracza, by wiedział, z jakim sprzętem pracuje.

Są różne pomysły na to, jak to obejść. Część deweloperów po prostu każe graczowi czekać przy uruchomieniu gry, tak długo, aż te wszystkie programy na karcie zostaną odpowiednio wczytane i skompilowane. Staramy się ładować je też podczas cutscenek. Niestety, czasem te sztuczki okazują się niewystarczające, bo architektura PC ogranicza pewne procesy pod względem optymalizacji komunikacji między podzespołami.

Dawnwalker to dla was wejście do pierwszej ligi polskich twórców gier. Mając taką pozycję, jak wygląda bezpośrednia współpraca z producentami podzespołów, np. AMD czy Nvidia? Czy macie do dyspozycji "czerwony telefon", żeby w razie kryzysu, kiedy sprzęt gryzie się z waszym kodem, zadzwonić i zapytać „słuchajcie chłopaki, co z tym zrobić"?

Zdecydowanie tak! Relacje z tymi potężnymi korporacjami mamy doskonałe. Producenci - w tym AMD, z którym teraz świetnie nam się pracuje - wykazują wręcz niesamowite zainteresowanie. Często wychodzą z propozycjami. Nie wygląda to tak formalnie, że dzwonimy do prezesa przez "czerwony telefon". Mamy raczej prywatne, błyskawiczne kanały komunikacji z inżynierami, na których często pomagają nam nawet w środku nocy.

Firmy takie jak AMD odblokowują nam też dostęp do kodu źródłowego własnych bibliotek i dostarczają specjalny sprzęt, jeśli zauważymy usterkę powiązaną tylko i wyłącznie z jakąś konkretną linią hardware'ową u graczy. To bezcenne wsparcie z którego bezwstydnie korzystamy. Jestem programistą i to, na czym mi najbardziej zależy podczas pracy, to szybkość kompilacji kodu. A kod kompiluje się tym szybciej, im więcej rdzeni ma procesor, po prostu. Akurat Threadrippery od AMD z potężną ilością rdzeni radzą sobie z tym naprawdę super, więc dla mnie takie wsparcie to win-win.

Przechodząc na temat samego oprogramowania i silników. Korzystacie w Dawnwalkerze z Unreal Engine. Słyszałem od ludzi z branży, że Unreal bywa ciężki dla produkcji tego kalibru, jest trochę jak "czarna skrzynka" do której nie ma się wglądu. Dlaczego wybraliście Unreala?

Dlaczego Unreal? Przede wszystkim potężne wsparcie dla budowy wspaniałej oprawy wizualnej bez konieczności angażowania ogromnych pieniędzy i budżetów w zespół potrafiący pisać narzędzia renderujące od podstaw. Mogliśmy skupić się na art-designie i oświetleniu, wiedząc, że zaplecze technologiczne to udźwignie.

Druga sprawa to ogromne ułatwienie dla deweloperów przy powiększaniu załogi. Branża zna Unreala. Odpada wielomiesięczny proces uczenia nowej osoby niestandardowego, wewnętrznego edytora stworzonego tylko na potrzeby naszego studia. Proces prototypowania za pomocą tzw. "blueprintów" również znacząco skrócił procesy decyzyjne i poszukiwania fajnego gameplayu.

Unreal Engine oferuje wiele możliwości, ale w przypadku rozległych, otwartych światów pojawiają się również określone wyzwania związane z optymalizacją i wydajnością. Do samego końca, na etapie "polerowania" gier, twórcy zmuszeni są ciąć ogromne kawałki treści, mechanik bitewnych czy modeli przeciwników, by sprostać zadaniu płynności. My zdecydowaliśmy, że dowieziemy wszystko dokładnie tak, jak to wymyśliliśmy na początku i zrezygnowaliśmy z tego "cięcia". Chcieliśmy wypuścić produkt w pełni grywalny na wielu konfiguracjach, na takim systemie zarządzania assetami, na jaki pozwala nam Unreal, bez wyrzucania do kosza pomysłów artystycznych i mechanik.

Ten wyznaczony cel się udał, z czego po latach ciężkiej pracy bardzo się cieszymy. Niestety, im gry stają się bogatsze, z wieloma systemami i lepszą technologią oświetlenia, koszty optymalizacji i czas potrzebny na jej doprowadzenie do ideału drastycznie rosną, dlatego tak mało gier działa bezbłędnie już w dniu premiery.

Dziękuję za rozmowę!

Więcej technologicznych wywiadów na Spider's Web: