Im większa staje się gra, tym bardziej proces jej tworzenia zaczyna przypominać fabrykę, w której każda linia produkcyjna zależy od kilku innych. Kod trzeba skompilować, przygotować przeznaczone dla danej platformy wersje shaderów, przetworzyć zasoby i spakować wszystkie dane w gotowy build gry. Wiele zmian można wcześniej sprawdzić w edytorze, ale dopiero gotowy build pozwala przetestować całą grę w warunkach zbliżonych do tych, z którymi zetknie się później gracz. Właśnie dlatego najciekawsza informacja z technologicznego zaplecza 11 bit studios dotyczy czasu.
Studio pochwaliło się, że po wdrożeniu maszyn z procesorami AMD Ryzen Threadripper buildy zaczęły powstawać szybciej, ale nie podało przy tym żadnych konkretnych wyników. Dlatego postanowiłem pogrzebać głębiej i spytać bezpośrednio u źródła, co dokładnie kryje się za tą oficjalną laurką dla sprzętu AMD. Dopiero z odpowiedzi Bartosza Lipińskiego dowiedziałem się, że w niektórych zadaniach mowa o dwu-, a nawet trzykrotnym skróceniu czasu pracy.
11 bit studios zyskało coś arcyważnego – krótsze oczekiwanie
Bartosz Lipiński, Head of Technology w 11 bit studios, wyjaśnia, że dokładny zysk zależy od tego, gdzie w danym projekcie znajduje się największe obciążenie. Czasami jest nim kompilacja kodu gry albo samego silnika. Innym razem przygotowywanie shaderów, kompresowanie zasobów lub tak zwany “cook”, czyli przetwarzanie zawartości projektu do postaci, którą można umieścić w gotowym buildzie.
Czytaj też: Wielkie plany CD Projekt RED. Kiedy nowy Wiedźmin i Cyberpunk?
Nie ma więc jednej odpowiedzi w rodzaju “pełna wersja gry powstaje teraz o 47 minut szybciej”. Cały pipeline produkcyjny nie jest bowiem pojedynczym benchmarkiem, w którym zawsze wykonuje się identyczną operację. Według Lipińskiego czasy kompilowania kodu oraz shaderów spadły dzięki sprzętowi AMD przeciętnie dwu- lub trzykrotnie. Podobne przyspieszenie odnotowano podczas cookowania danych, głównie dlatego, że studio mogło efektywniej korzystać z wieloprocesowego cooka.
To przeważnie zależy od tego, w którym elemencie leżał największy “payload” podczas robienia pełnego builda gry: czy w kompilacji silnika/gry, czy w kompilacji shaderów, czy na przykład w kompresowaniu assetów gry. Czasy kompilacji gry i shaderów spadły średnio dwu, trzykrotnie, czasy samego “cooka” także, bo lepiej mogliśmy zutylizować multi process cook. – Bartosz Lipiński, Head of Technology w 11 bit studios.
To akurat dobrze pasuje do sposobu działania Unreal Engine 5. Funkcja Multi-Process Cook wykorzystuje dostępne rdzenie CPU oraz pamięć operacyjną do równoległego przygotowywania zawartości. Epic Games zastrzega wprawdzie, że w małych projektach narzut związany z uruchamianiem dodatkowych procesów może przewyższyć korzyści, ale przy dużych produkcjach i rozbudowanych zbiorach zasobów równoległość zaczyna mieć znacznie więcej sensu.
Właśnie tutaj najłatwiej nie docenić skali zmiany. Dwukrotnie krótsze oczekiwanie nie oznacza tylko, że jeden pracownik wypije mniej kawy podczas kompilacji. Oznacza, że cały zespół może szybciej dostać kolejną wersję gry, testerzy wcześniej rozpoczną pracę, a wykryta przez nich usterka szybciej wróci do programisty. Innymi słowy, jeden skrócony etap zaczyna przyspieszać wszystkie następne.
Kilkanaście buildów dziennie, kiedy każda poprawka może coś zepsuć
Podczas normalnego etapu produkcji 11 bit studios przygotowuje zazwyczaj jeden automatyczny build dziennie dla każdej platformy docelowej. Proces rusza nad ranem, aby około godziny 7:00 lub 8:00 gotowa wersja czekała już na zespół rozpoczynający pracę. Jest to klasyczny “daily build”, czyli codzienny punkt odniesienia pokazujący, czy aktualna wersja projektu nadal działa jako całość. W praktyce bowiem dopiero pełna wersja gry ujawnia, że pozornie niewinna zmiana popsuła animację, wydłużyła ładowanie poziomu albo spowodowała problem na jednej z konsol.
Podczas regularnego developmentu jest to na ogół jeden build na każdą docelową platformę, określany mianem “daily builda”. Powstaje automatycznie, nad ranem, żeby około siódmej, ósmej rano każdego dnia był gotowy do pracy. Im jednak jesteśmy bliżej releasu gry, tym buildów powstaje więcej – ze szczególnym peakiem w okresach wspomnianego “delivery” czyli w okolicach stabilizacji. – Bartosz Lipiński, Head of Technology w 11 bit studios.
Spokojny rytm znika w okresie określanym przez studio jako “delivery”. To moment intensywnego dostarczania poprawek i stabilizowania projektu, zwykle bezpośrednio przed wydaniem gry, aktualizacji lub większego dodatku. Wtedy 11 bit studios potrafi produkować nawet kilkanaście różnych buildów jednego dnia. W takim środowisku każda godzina zaczyna mieć znaczenie. Poprawka przygotowana rano musi zostać skompilowana, umieszczona w buildzie, przekazana testerom, sprawdzona i ewentualnie poprawiona ponownie jeszcze tego samego dnia. Jeśli przygotowanie wersji trwa za długo, to cały cykl przesuwa się na kolejny dzień. Gdy powstaje szybciej, zespół może wykonać kolejną pełną iterację, zamiast kończyć pracę na przypuszczeniu, że “teraz powinno już działać”.
Najlepszym przykładem jest okres tak zwanego “delivery” czyli wtedy, kiedy zachodzi sporo zmian i różnej maści poprawek, które muszą zostać przetestowane na przygotowanych bardzo szybko buildach gry. W trakcie takiego procesu, często jesteśmy w stanie wyprodukować kilkanaście różnych buildów gry dziennie. Tak więc możliwość szybkiego iterowania w tego typu momentach ma dla nas kluczowe znaczenie. – Bartosz Lipiński, Head of Technology w 11 bit studios.
Tego typu problem pojawia się w opowieściach o rzekomo leniwych twórcach gier. Jak opisywałem przy okazji rozmowy o jednym z największych kłamstw na temat gamedevu, gracze widzą ostateczną usterkę, ale nie widzą zależności, certyfikacji, kompilacji, kolejnych buildów ani liczby prób, które trzeba zmieścić w ograniczonym czasie. Wydajniejszy sprzęt nie sprawi oczywiście, że każdy programista nagle zacznie pisać bezbłędny kod. Może jednak dać mu jeszcze jedną lub dwie szanse na sprawdzenie poprawki przed końcem dnia.
Czytaj też: Rozmawiałem z twórcą pierwszego Wiedźmina. Teraz wiem, jak wielkim wyzwaniem jest Witcher 1 Remake [WYWIAD]
The Alters jest też dobrym przykładem gry, w której szybkie przygotowywanie kolejnych wersji może mieć znaczenie nie tylko techniczne. Wiele nakładających się systemów sprawia, że zmiana jednego elementu może wywołać konsekwencje w kilku innych miejscach, więc zespół musi częściej sprawdzać projekt jako całość. Zmiana jednego elementu może bowiem wpływać na kilka pozostałych, dlatego możliwość szybkiego budowania i testowania kolejnych wersji ma tutaj szczególne znaczenie.
Unreal Engine 5 potrafi wykorzystać rdzenie, ale potrzebuje również ogromnej ilości pamięci
Według 11 bit studios procesory AMD Threadripper robią największą różnicę w kompilowaniu kodu gry i silnika oraz przygotowywaniu shaderów. Nie jest to zaskoczenie, bo są to zadania, które można rozdzielać między wiele procesów i rdzeni. Unreal Engine podczas kompilacji shaderów uruchamia osobne procesy ShaderCompileWorker, które otrzymują kolejne zadania i zwracają gotowe wyniki. Silnik może dzięki temu rozdzielać pracę między wiele rdzeni, choć liczbę procesów roboczych ograniczają również konfiguracja projektu i dostępna pamięć.
Sam silnik ma nawet zmienną pozwalającą uruchomić tylu wspomnianych “workerów”, ile dostępnych jest rdzeni CPU. W teorii więc im więcej potężnych rdzeni otrzyma taka maszyna, tym więcej pracy może wykonywać jednocześnie, choć rzeczywista skalowalność nadal zależy od projektu, pamięci oraz pozostałych elementów pipeline’u.
Największy zysk to oczywiście kompilacja kodu gry/silnika oraz kompilacja shaderów. – Bartosz Lipiński, Head of Technology w 11 bit studios
Sama liczba rdzeni nie rozwiązuje jednak wszystkiego. Lipiński wskazuje, że podczas produkowania buildów gier na Unreal Engine 5 dwa najważniejsze zasoby to CPU oraz RAM. Procesor odpowiada za szybkość wykonywania kolejnych etapów cooka. Pamięć wpływa natomiast na to, jak często system musi uruchamiać mechanizmy zwalniające zajęte zasoby. Lipiński porównuje ten proces do ratraka, który wjeżdża na trasę i porządkuje śnieg, ale jednocześnie na chwilę zakłóca normalny ruch. Im częściej garbage collector musi sprzątać pamięć, tym więcej czasu traci cały proces przygotowywania buildu. Duża pula RAM-u pozwala więc nie tylko przechowywać większą liczbę danych, ale też ograniczać przestoje wynikające z ciągłej walki o pamięć przez aplikacje.
Dwoma najważniejszymi zasobami, które wykorzystujemy podczas produkcji buildów gry, która stworzona jest w Unreal Engine 5, są CPU oraz RAM. Od pierwszego zależy “szybkość” wykonywania poszczególnych etapów tzw. “cooka”. Od drugiego, jak często podczas procesu “cooka” musi rozpoczynać swoją pracę “garbage collector” – to taki ratrak, który zwalnia pamięć, a który znacząco wpływa na czasy produkcji buildów. – Bartosz Lipiński, Head of Technology w 11 bit studios.
Dlatego właśnie Threadrippery nie są zwykłymi “Ryzenami z większą liczbą rdzeni”. Platforma stacji roboczych obsługuje rozbudowane konfiguracje pamięci, wiele szybkich nośników i dużą liczbę linii PCI Express. W produkcji gry znaczenie ma bowiem cały przepływ danych, a nie tylko wydajny procesor. Nawet najszybszy układ będzie częściowo marnował możliwości, jeśli będzie nieustannie czekał na pamięć, dysk lub pliki przesyłane przez sieć.
To nie są komputery stojące pod biurkami programistów
Materiały promocyjne mogą sugerować, że każdy deweloper w 11 bit studios dostał swoją monstrualną stację roboczą z Threadripperem. W praktyce wygląda to inaczej. Lipiński potwierdził, że procesory te pracują przede wszystkim jako część infrastruktury buildowej oraz CI, czyli systemu automatycznie integrującego zmiany wprowadzane przez zespół.
U nas w 11 bit studios są głównie częścią infrastruktury buildowej/CI. – Bartosz Lipiński, Head of Technology w 11 bit studios.
Ma to znacznie więcej sensu niż wkładanie ekstremalnie drogiego procesora do każdego komputera. Programista podczas zwykłego pisania kodu nie wykorzystuje przez cały dzień kilkudziesięciu rdzeni. Artysta pracujący nad modelem również nie potrzebuje nieustannie maszyny klasy serwerowej. Potężny węzeł buildowy może natomiast obsługiwać wspólne zadania całego zespołu, przygotowywać wersje gry, kompilować silnik i dostarczać aktualne pliki binarne edytora.
Najmocniej eksploatujemy maszyny 96 i 128-rdzeniowe – właśnie podczas produkcji buildów oraz podczas błyskawicznego kompilowania oraz dostarczania plików binarnych edytora, niezbędnych do pracy dla designerów, artystów, animatorów. – Bartosz Lipiński, Head of Technology w 11 bit studios.
Najmocniej eksploatowane mają być maszyny określane przez studio jako 96- oraz 128-rdzeniowe. Nie oznacza to jednak, że 11 bit studios korzysta ze 128-rdzeniowego Threadrippera, bo najwydajniejsze modele Ryzen Threadripper PRO 7995WX oraz 9995WX oferują po 96 rdzeni i 192 wątki. Lipiński mówił jednak ogólnie o “maszynach”, a nie wyłącznie o komputerach z Threadripperami. Bez dokładnej specyfikacji infrastruktury nie da się więc ustalić, jaki procesor lub układ procesorów odpowiada za podaną liczbę 128 rdzeni.
Czytaj też: Najbardziej szalona decyzja w Wiedźminie 2 nawet po latach dręczy jego twórcę [WYWIAD]
Najważniejsze jest to, że wspomniane maszyny wykorzystywane są podczas produkcji buildów, a także szybkiego kompilowania i rozsyłania plików edytora niezbędnych designerom, animatorom i artystom. Właśnie ten ostatni element uważam za najciekawszy. Programista zmienia fragment silnika albo narzędzia, ale z rezultatu muszą następnie skorzystać osoby, które nie pracują bezpośrednio w kodzie. Jeśli dostarczenie nowej wersji edytora trwa długo, designer albo animator może utknąć na starym wydaniu, czekać na poprawkę lub wykonywać pracę, którą później trzeba będzie powtórzyć.
Odblokowywanie praktycznie równoległej pracy programistów i content creators (artystów, animatorów) podczas pracy w edytorze Unreal Engine 5. – Bartosz Lipiński, Head of Technology w 11 bit studios.
Mocniejsza infrastruktura odblokowuje więc bardziej równoległą pracę programistów oraz osób tworzących zawartość w grze. Nie sprawia tym samym tylko tego, że kod kompiluje się szybciej. Ogranicza sytuacje, w których jeden dział czeka, aż drugi przygotuje mu odpowiednie narzędzia. Przy dużych produkcjach to może być ważniejsze od oszczędności na pojedynczym buildzie. Dziesięć minut straconych przez jedną osobę pozostaje drobną niedogodnością. Dziesięć minut straconych jednocześnie przez kilkudziesięciu specjalistów zaczyna być już realnym problemem produkcyjnym.
Szybszy komputer nie zaprojektuje lepszej gry, ale może dać czas na jej poprawienie
11 bit studios współpracuje z AMD nie tylko przy zakupie lub konfigurowaniu infrastruktury. Według Lipińskiego inżynierowie obu firm pomagali również optymalizować The Alters pod nowszy sprzęt AMD oraz rozwiązywać problemy wynikające z dostosowywania gry do aktualnych architektur. Nie znamy jednak konkretnych przykładów usterek, wyników wydajności ani zmian w kodzie, więc nie ma sensu dopisywać do tego historii o cudownej optymalizacji. Wiemy jednak, że współpraca wykraczała poza dostarczenie procesorów i obejmowała konsultacje techniczne. Taki dostęp do inżynierów producenta sprzętu pozwala czasem ustalić, czy problem leży po stronie gry, silnika, sterownika lub samej platformy.
Z AMD współpracujemy od dawna, a dzięki tej współpracy mogliśmy m.in. lepiej zoptymalizować grę Alters dla najnowszego sprzętu AMD. Ponadto byliśmy w stanie dzięki temu rozwiązywać problemy, które występowały na etapie powstawania gry i dostosowania jej do aktualnych architektur. – Bartosz Lipiński, Head of Technology w 11 bit studios.
Naturalnie lepszy sprzęt nie sprawi z automatu, że gra będzie lepsza. Może za to skrócić drogę między pytaniem a odpowiedzią. Czy nowa mechanika działa? Czy poprawka nie popsuła wersji konsolowej? Czy zmieniony shader kompiluje się na wszystkich platformach? Czy build po nocnej integracji nadal daje się uruchomić? Czy artysta może już korzystać z nowej wersji narzędzia? Im szybciej zespół otrzyma odpowiedzi na tego typu regularne pytania, to tym szybciej może podjąć kolejną decyzję co do rozwoju projektu.
W trybie pracy w mniejszych studiach często wraca problem “polityki złotych strzałów”, czyli sytuacji, w której pierwsze rozwiązanie musi pozostać w projekcie, bo na przygotowanie drugiego brakuje czasu. Pisałem o tym szerzej przy okazji rozmowy z programistą pracującym przy dużych polskich RPG-ach. W dużych studiach naturalnie czas również jest ograniczony, a potężna infrastruktura może i nie usuwa ograniczeń budżetu czy harmonogramu, ale może sprawić, że zespół dostanie właśnie ten jeden dodatkowy strzał w danej mechanice, który finalnie zaowocuje lepszym produktem.
Właśnie dlatego historia 11 bit studios pokazuje coś, o czym jeszcze kilkanaście lat temu mówiło się głównie przy największych studiach, centrach danych i produkcji filmowej. Dziś polska firma tworząca gry korzysta z potężnego sprzętu od AMD po to, aby niemal na bieżąco składać kolejne wersje całych wirtualnych światów. Przyszłość gamedevu nie musi więc wyglądać jak sztuczna inteligencja generująca grę po wpisaniu jednego polecenia. Może jednak być znacznie mniej widowiskowa, ale bardziej realna, bo jest to przyszłość, w której pomiędzy pomysłem a jego sprawdzeniem znika coraz więcej oczekiwania. W takim układzie maszyny nie zastępują twórców. Po prostu coraz rzadziej każą im czekać na samych siebie.
