Jak powstało Gears of War: Ultimate Edition

Pamiętam dzień, w którym się dowiedziałem. Wezwano mnie do biura Mike'a Raynera i gdy opadło już podekscytowanie i zaskoczenie, zaczęliśmy rozmowę na temat potencjalnych rozwiązań, sprowadzających się na dobrą sprawę do trzech opcji: rozpoczęcie od oryginału, start na najnowszej wersji UE3 lub przejście na UE4.

Nasza filozofia polegała na tym, by przez cały czas trwania prac można było włączać i testować grę, więc uznaliśmy, że do osiągnięcia naszych celów i upewnienia się, że możemy jak najczęściej grać, najlepiej nadaje się bazowanie na oryginalnym kodzie. Z perspektywy zawartości oznaczało to, że całość działała już od pierwszego dnia. Nasz zespół miał duże doświadczenie w pracy na technologii Unreal Engine, ale tylko ograniczoną wiedzę na temat samego kodu Gears. Omawialiśmy nasze podejście i wyzwania wiążące się z pracą na dziesięcioletnich narzędziach - wewnątrz zespołu, a także podczas wizyty w Epic. Ostatecznie zgodziliśmy się, że to najlepsze rozwiązanie. Tak zaczęła się nasza podróż, bazująca na oryginalnym kodzie gry.

Kluczowym wyzwaniem w przypadku pozostałych opcji był fakt, że gra przez dłuższy czas nie nadawałaby się do włączenia i testów, a dane na temat poziomów ciężko byłoby przenieść. Zmieniłyby się pracujące w tle systemy, więc nie moglibyśmy zagwarantować takich samych funkcjonalności. Jedyną opcją byłoby wyrzucenie wszystkiego i napisanie skryptów poziomów od podstaw. Czuliśmy, że przy takim podejściu zbyt duże były szanse na pominięcie czegoś ważnego w rozgrywce.

Po podjęciu decyzji nasz zespół odpowiedzialny za silnik natychmiast przystąpił do pracy nad uruchomieniem gry na Xbox One, a deweloperzy zajmujący się rozgrywką udali się „Uniwersytetu Rozgrywki Gears of War”, by rozłożyć na czynniki pierwsze wszystkie elementy składowe. Takie połączenie pozwoliło nam oceniać ewentualne dodatki do rozgrywki, poprzez sprawdzanie ich w grze, już na Xbox One, w 60 klatkach na sekundę, na wcześniejszym etapie prac.

Byliśmy zadowoleni z takiej decyzji, ale nie doceniliśmy rozmiaru części wyzwań związanych z pracą na tak starym edytorze. Unreal Engine 3 doczekał się wielu zmian oraz usprawnień i mogliśmy poprawić wydajność, decydując się na wprowadzenie większej ich liczby we wcześniejszej fazie produkcji. Korzyścią wynikająca z bazowania na oryginalnych skryptach rozgrywki był fakt, że nasza wersja pozostawała wierna oryginałowi i nie musieliśmy od podstaw budować czegoś, co tylko przypominało rozgrywkę Gears 1.

Zaczęliśmy od oryginalnego kodu i wprowadzaliśmy poprawki i aktualizacje, bazując na rekomendacjach od zespołu odpowiedzialnego za renderowanie. The Coalition i Microsoft są aktywnymi współpracownikami przy Unreal Engine i dobrze rozumieją, jak różne techniki renderowania sprawdzają się na Xbox One. Ta wiedza pozwoliła nam rozpocząć od oryginału włączonego na Xbox One, by potem przenieść część nowości z UE3, a także kilka z UE4. Większość opcji edytora przeniesiono z UE3, czego przykładem jest Lightmass (moduł oświetlenia Unreal Engine), nad którym spędziliśmy kilka miesięcy, by dotrzeć mniej więcej do poziomu opcji z 2011 roku. Inne funkcje pochodzą z UE4 lub z naszej własnej pracy nad cieniowaniem bazującym na fizyce w stylu UE4, a także z wielu autorskich rozwiązań związanych z Xbox One, jak zarządzanie pamięcią ESRAM. Eksperymentowaliśmy także z możliwościami asynchronous compute dla optymalizacji, co nie było możliwe w czasach UE3.

Decyzję o postawienie na 30 FPS w kampanii i 60 FPS w trybie sieciowym podjęliśmy bardzo wcześnie w fazie projektowej i nie ze względu na ograniczenia techniczne. Oryginał prezentował możliwości konsoli Xbox 360 i chcieliśmy kontynuować podobne podejście na Xbox One, znacząco zwiększając jakość oprawy, ale przy zachowaniu bardziej stabilnego 30 FPS niż w oryginale. Włączenie kampanii w 60 FPS było możliwe, ale nie wyglądało równie dobrze, co przy 30 klatkach na sekundę.

Większość mocy obliczeniowych jest ustalana i utrzymywana przez monitorowanie rzeczywistego działania produkcji. Podczas prac pozwalało to nam wiedzieć, gdzie stoimy pod względem wydajności na oryginalnych materiałach, a także monitorować i aktualizować sytuację wraz z odtwarzaniem kolejnych map. Codziennie prowadziliśmy zautomatyzowane i „ręczne” testy każdej z lokacji. W przypadku GPU celowaliśmy w generowanie klatki w przedziale 8-12 ms na mapie w trybie sieciowym z jedną postacią na ekranie, by znalazło się miejsce na zmiany tego poziomu w scenach akcji, przy rzucaniu granatami i tak dalej.

Podczas prac natknęliśmy się na wiele problemów związanych z renderowaniem, ale częściej przenosiliśmy informacje z procesora do GPU, ze względu na liczbę dodanych obiektów. Musieliśmy przygotować narzędzia do łączenia geometrii, a także do przekazywania dodatkowych obowiązków renderowania na więcej rdzeni. Wiele wysiłku włożyliśmy w przygotowanie solidnej wydajności układu graficznego, co wymagało przepisania niemal wszystkich efektów post-processingu w grze, zmaksymalizowania przepustowości pamięci z pomocą ESRAM i wielu innych optymalizacji.

To dobre pytanie, które przekazuję do naszego głównego dewelopera, który zajmował się tym elementem.

Początkowo do ESRAM przekazaliśmy tylko bufory koloru/głębi, ponieważ nasz silnik stawia na forward-rendering [do GPU najpierw ładowane są po kolei elementy geometrii, otrzymujące kolory, tekstury i inne właściwości - dop. red.]. Główne bufory (kolor/głębia) [zawierające dane na temat tych właściwości, przekazywane na poszczególne piksele - dop. red.] pasowały zgrabnie do pamięci ESRAM w 1080p, co przełożyło się na duży wzrost wydajności. W późniejszej fazie prac przyjrzeliśmy się wykorzystaniu ESRAM raz jeszcze, poszukując dalszej optymalizacji. Z analiz wynikało, że tylko niektóre funkcje i zasoby zyskują na przeniesieniu do ESRAM, ponieważ w wielu przypadkach nie mieliśmy problemów z ograniczeniami jednostek renderujących.

Dodaliśmy nowy alokator ESRAM, korzystający z pamięci wirtualnej do mapowania fragmentów o rozmiarze 64k w ESRAM/DRAM. Wprowadziliśmy też zarządzanie zasobami przekazywanymi do ESRAM, by po ich fizycznym wygenerowaniu dostępne miejsce było zwalniane na inne zasoby. Właściwości głębi i kolorów mogą być kompresowane na Xbox One i zauważaliśmy, że w niektórych przypadkach sprawdza się także podział obowiązków na DRAM/ESRAM, ponieważ zwalnia pamięć ESRAM na inne, ważniejsze zasoby.

Nowy alokator świetnie się sprawdził. Zwłaszcza podczas cieniowania, gdzie mogliśmy zapisać i wczytać wszystkie informacje na temat głębi cieni tylko wewnątrz ESRAM. Naiwne podejście polegające na wrzuceniu „wszystkiego” w ESRAM szybko przełoży się na dotarcie do limitu 32 MB, zwłaszcza w renderowaniu typu deferred [alternatywa dla forward-renderingu. Tutaj właściwości pikseli nadawane są dopiero po wczytaniu całej geometrii, z cieniowaniem na samym końcu - dop. red.]. W naszym przypadku nie było to problemem i nadal mieliśmy opcję korzystania z silników DMA do przenoszenia danych z i do ESRAM, jeśli potrzebowaliśmy więcej miejsca.

Korzystamy z procesorów audio na Xbox One i dobra wiadomość jest taka, że po stronie dźwięków nigdy nie natknęliśmy się na żadne problemy i całość po prostu działała. Przejście na system 7.1 oznacza ogromny wzrost liczby dźwięków do przetworzenia i sprzętowa kompresja bardzo przydaje się do poradzenia sobie z tym zadaniem.

Jasne. Nasze oświetlenie korzysta z Lightmass i zaczęliśmy od wersji z 2006 roku. Przeszliśmy przez dwie większe integracje, jedna podnosząca system do standardów z okolic 2009 roku, a druga - 2011 roku. Taka praca często musi być stopniowa i odbywać się etapami, by upewnić się, że wszystkie elementy działają poprawnie. Pierwsza integracja dała nam globalną iluminację, co samo w sobie jest dużym krokiem do przodu. Później wprowadziliśmy wsparcie dla dominant directional lights [dominujące światła kierunkowe - dop. red.] i kolejnych technik cieniowania. To poprawiało odbicia i pozwoliło na dynamiczne rzucanie cieni, które poprawnie współgrały ze środowiskiem. Nasz moduł physically-based rendering bazuje na rozwiązaniu z UE4.

Moduł oświetlenia zamieniliśmy na physically-based rendering z UE4. Mówimy o modelu Lamberta dla rozproszeń, z przybliżeniem Schlicka i cieniowaniem GGX na teksturach. Mapowanie detali na teksturach może być opcjonalnie przetwarzane metodą Toksviga, co pomaga w wygładzaniu krawędzi. Zachowanie modelu z UE4 było intuicyjne dla naszych artystów, przyzwyczajonych do takiej pracy.

Całe oświetlenie jest teraz w liniowej przestrzeni HDR. Cała faza nakładania efektów post-processingu została napisana od nowa, by proces odbywał się w liniowym HDR i wykonywał dynamiczne korekty ekspozycji, bloomu, efektu brudnej soczewki, głębi ostrości, rozmycia w ruchu, winietowania, filmowego mapowania tonu; korekty gamma, kolorów i wygładzania FXAA. Tryb sieciowy omija rozmycie obiektów i głębię ostrości, przez co jest o 1,1 ms szybszy. Dla ambient occlusion zastosowano SSAO.

Używamy 32-bitowego formatu RGB101111 zamiast FP16x4. FP16x4 nie dało nam zauważalnego wzrostu jakości, więc pozostaliśmy przy pełnym, 32-bitowym formacie, co pomogło także w zarządzaniu ESRAM.

Odpowiem z technicznego punktu widzenia, jakie funkcje wprowadziliśmy, by ulepszyć wrażenia. Bert powie nieco więcej z punktu widzenia projektanta. Z technicznej perspektywy chcieliśmy zapewnić dedykowane serwery, szybkie sterowanie (sprawne odświeżanie obrazu, wykrywanie obrażeń po stronie gracza, a nie serwera) i stałą liczba klatek na sekundę.

Chcieliśmy też upewnić się, że tworzenie rozgrywek i zabawa w sieci są zaktualizowane i solidne. Oznacza to dodanie wsparcia dla drużyn, playlist czy możliwość interakcji wewnątrz społeczności. Ultimate Edition w dużo większym stopniu polega także na zewnętrznych usługach. Jeśli mowa o tworzeniu rozgrywek, to gracze mają dostawać się na serwer tak szybko, jak to tylko możliwe, w możliwie najlepszym meczu. Dodaliśmy także poziomy doświadczenia podobne do Gears 3 i ogólnie blisko współpracowaliśmy z ludźmi odpowiedzialnymi za platformę, by zapewnić jak najlepsze wrażenia. Pomogły w tym liczne testy, zarówno wewnątrz studia, jak i poza nim.

Wprowadziliśmy kilka zmian w bazowej technologii, by dołączanie do trwających meczów działało lepiej, ale najbardziej rzucająca się w oczy kwestia to kadrowanie na podzielonym ekranie dla lepszych kątów widzenia i wszystkie zmiany w trybie rywalizacji, przeniesione także do co-opa.

Krótka wersja jest taka, że zaczęliśmy od oryginału i upewniliśmy się, że zastępujemy wszystko poza rozmieszczeniem obiektów, a następnie rozbudowujemy za pomocą oświetlenia, efektów graficznych czy lepszych modeli postaci. Poza rozmieszczeniem obiektów wszystko powstało od podstaw.

Ze strony technicznej mieliśmy kilka elementów wspierających ten proces. Najpierw zbudowaliśmy wielką bazę danych ze wszystkimi materiałami z Gears, wraz z korespondującym etapem. To pomogło grafikom w planowaniu. Twórcy narzędzi zajęli się dalszą analizą geometrii obiektów, by sprawdzić, które z nich są tylko skalowane i w jakim stopniu. Wiedzieliśmy dzięki temu, ile dodatkowych obiektów musimy przygotować, żeby zachować równy poziom detali w całej grze. Deweloperzy z Epic byli bardzo kreatywni i efektywni jeśli chodzi o korzystanie z tych samych modeli w różnych miejscach, ale stawiano na pewne uproszczenia, które w naszej opinii były nie do zaakceptowania w 2015 roku.

Postaraliśmy się wcześnie, by wszystkie obiekty były rozmieszczone i zablokowane w określonych miejscach, by czegoś przez przypadek nie przesunąć, co modyfikuje całe wykrywanie kolizji. Często łatwo jest kliknąć coś przez przypadek, więc warto zablokować wszystko w miejscu. Główna część prac to kooperacja grafików i grafików technicznych w każdej fazie poprawiania jakości oprawy, by wszystkie potrzebne na danym poziomie opcje działały, a wydajność była odpowiednia. Przez 18 miesięcy prac dodawaliśmy nowe funkcje i optymalizowaliśmy grę, co często może być problemem dla grafików. The Coalition i Splash Damage dysponują jednak mocnymi zespołami, co pomogło w poradzeniu sobie z wszelkimi kłopotami.

Jeśli chodzi o lokacje, nasze budżety dotyczyły modyfikacji oprawy, obejmując krzywe modeli i tekstury. W tym pierwszym przypadku nasze założenia były dość skromne, ponieważ nasi graficy odkryli, że mogą odbudować modele i znacznie je poprawić przy liczbie polygonów większej o 10-30 procent. Mamy za to dwa razy więcej tekstur, w wyższej rozdzielczości, zwiększając zużycie pamięci nawet szesnastokrotnie w niektórych przypadkach. Największe zmiany dotyczą wymiany obiektów z przygotowanym z góry oświetleniem i faz poprawek, w których dodawaliśmy coś ponad to, co było w oryginale. Na koniec jest jeszcze optymalizacja, która zamieniała grupy obiektów na złożone w całość modele o podobnym wyglądzie, dla szybszego renderowania. Niektóre postacie - jak Corpser - podwoiły liczbę krzywych i tekstur.

Bazowe dane dla animacji postaci zostały takie same, by zachować zgodność z pierwowzorem. Usprawniono szkielety postaci, a także animacje drugorzędne. Dla przykładu, pancerz został odpowiednio dociążony na skórze, by nie rozciągał się tak jak w oryginale. Również pasy bohaterów doczekały się animacji w kampanii. „Dociążanie” rozszerzono także, by umożliwić podłączenie maksymalnie ośmiu kości do punktu zgięcia, a nie czterech, jak w oryginale.

W fazie konceptowej przyglądaliśmy się, jak wyglądałoby wprowadzenie opcji pełnego przełączania pomiędzy wersjami graficznymi, jak w Halo: Combat Evolved Anniversary. Nie chcieliśmy jednak rozważać, na jakie kompromisy pójść, by zmieścić cały ładunek pamięci dla wersji X360. Zmieniłyby się również czasy ładowania, więc z pomysłu zrezygnowano przed przejściem do właściwych prac. To doprowadziło do dyskusji na temat filtrów koloru lub też przybliżonego odwzorowania wyglądu oryginału, w niższej rozdzielczości. Ostatecznie uznaliśmy, że lepiej skupić wszystkie wysiłki na przygotowaniu jak najładniejszej produkcji.

Projektanci poziomów i graficy mogli przygotować oświetlenie według własnego uznania, o ile poziom wydajności poszczególnych poziomów pozostawał na określonym poziomie. To umożliwiło poprawki, jak te, o których wspomniałeś, a także wprowadzenie nowych opcji kolorowego oświetlania tekstur w obszarach z ogniem.

To praktycznie ten sam kod. Zespół deweloperów z działu Xbox konwertuje pliki wykonywalne do natywnych wersji x64, łączy je z oryginalnymi obiektami i emulatorem jako gry Xbox One, po czym publikuje całość.

Nadal pracujemy nad optymalizacją. DirectX 12 pozwala na dużo lepsze zarządzanie procesorem, mocno redukując obciążenie sterownikami. Część tych odblokowanych mocy obliczeniowych przeniesiono na poziom gry, dając twórcom pełną kontrolę. Naszym głównym celem jest przygotowanie systemu obliczeń równoległych, by wykorzystać więcej rdzeni CPU, czego ważnym elementem są listy poleceń i renderowania. Gdzie tylko się da korzystamy także z optymalizacji poczynionej już dla UE4, jak ładowanie obiektów do pamięci cache. Po stronie GPU konwertujemy SSAO, by korzystało z async compute i przyglądamy się też innymi opcjom, jak MSAA.

Wkładamy sporo wysiłków w przygotowanie wersji Windows 10 jako graficznej uczty w 4K. Geometria i tekstury zostały przygotowane z myślą o tej rozdzielczości, więc jakość obrazu będzie skalowała się z myślą o mocniejszych konfiguracjach. Zamierzamy odblokować wartość FPS i dodać specjalny tryb do testów GPU. W kwestii wygładzania krawędzi planujemy wsparcie dla MSAA i FXAA.

Nie określiliśmy jeszcze minimalnych wymagań sprzętowych, ale ważne jest dla nas zapewnienie dobrej wydajności (co najmniej 30 klatek na sekundę) na różnych konfiguracjach. Zamierzamy wspierać szeroki zakres rozdzielczości, a także różnorodne opcje graficzne, by móc dostosować grę do możliwości sprzętu.