Jak Guerrilla ujarzmiła PlayStation 3 za sprawą Killzone 2

Kiedy Sony pokazywało światu Killzone 2, ludzie z Guerrilla siedzieli przed ekranem w Amsterdamie i patrzyli, jak ich prerenderowany film zaczyna być przedstawiany niczym prawdziwa gra. Problem polegał na tym, że studio dopiero otrzymało jeden z pierwszych zestawów deweloperskich PlayStation 3. Nie istniał jeszcze silnik zdolny wygenerować taką bitwę, nie było gotowej rozgrywki, a twórcy dopiero uczyli się architektury konsoli. W ciągu kilku minut efektowna wizja przyszłości zamieniła się w jeden z największych długów technologicznych w historii branży.

Był maj 2005 roku. Nad ogarniętym wojną miastem przelatywał transportowiec, pociski smugowe przecinały zadymione niebo, żołnierze wyskakiwali w sam środek ostrzału, a Helghaści reagowali na trafienia z płynnością, której nie oferowała wtedy żadna istniejąca strzelanka. Kamera drżała od eksplozji, kurz wypełniał powietrze, a całe pole bitwy wyglądało jak scena z wysokobudżetowego filmu wojennego. Tyle że ktoś umieścił pośrodku celownik i zasugerował, że za chwilę będziemy mogli w to zagrać. Nie mogliśmy. Film był tak zwanym target renderem - przygotowaną wcześniej wizualizacją tego, jak Guerrilla chciałaby, aby wyglądała finalna gra. Takie materiały nie są w produkcji niczym niezwykłym. Pomagają określić kierunek artystyczny, tempo akcji, sposób pracy kamery oraz jakość, do której powinien dążyć zespół. Niezwykłe było to, że Sony pokazało tę wizję milionom ludzi podczas prezentacji nowej konsoli i komunikowało ją w sposób pozwalający uwierzyć, że całość działa już na PlayStation 3.

CYFROWE ARCYDZIEŁA Killzone 2: 6 technologii, które wyprzedzały swoją epokę Guerrilla Games  •  PlayStation 3  •  Premiera: 2009 rok

01 Deferred shading z wygładzaniem krawędzi W 2007 roku z odroczonego renderowania korzystało jeszcze niewiele wydanych gier, a połączenie tej techniki z MSAA sprawiało ogromne problemy. Guerrilla zmieściła cały G-buffer w czterech 32-bitowych warstwach RGBA oraz buforze głębokości. Przy obrazie 720p z Quincunx zajmowało to około 36 MB, ale pozwalało wyświetlać wiele dynamicznych świateł bez całkowitej rezygnacji z wygładzania krawędzi. 02 Światło „Frankenstein” przy każdym strzale Błysk wystrzału łączył punktowe źródło światła ze stożkowym reflektorem. Rozjaśniał broń, dłonie żołnierza i pobliskie ściany, a przed lufą potrafił nawet rzucać dynamiczne cienie. RSX sprawdzał przy tym, czy światło jest widoczne, i pomijał całą pracę, jeżeli rozbłysk znajdował się za ścianą. W konsolowej strzelance z 2009 roku podobna reakcja otoczenia na każdy pocisk była wyjątkowo ambitna. 03 Cell jako fabryka tysięcy zadań Guerrilla przygotowała 44 rodzaje zadań wykonywanych przez SPE: od animacji i fizyki, przez SI oraz cząsteczki, aż po dźwięk i przygotowywanie poleceń dla RSX. Jedna klatka mogła zostać rozbita na około tysiąc niewielkich operacji, a normalna rozgrywka wykorzystywała moc odpowiadającą czterem lub pięciu SPE. Cell nie zastępował układu graficznego – pilnował, aby ten przez cały czas otrzymywał gotowe dane. 04 2500 sond sklejających postacie ze światem Każdy poziom zawierał około 2500 zapisanych próbek oświetlenia. Dla poruszającej się postaci silnik wybierał cztery najbliższe, mieszał ich wartości i tworzył mapę światła 8 × 8 pikseli. W jednej klatce przetwarzano około 600 sond, wykorzystując jedynie 13 procent czasu pojedynczego SPE. Dzięki temu żołnierze i ruchome obiekty przejmowali kolor otoczenia, zamiast wyglądać jak modele doklejone do nieruchomej planszy. 05 Trafienia składane z animacji i fizyki AnimationBlender mieszał motion capture, reakcje przypisane do poszczególnych stawów oraz impulsy fizyczne. Humanoidalna postać mogła wykorzystać jednocześnie od 2 do 50 składników animacji, a silnik płynnie zwiększał udział ragdolla. Przeciwnik cofał trafiony bark, tracił równowagę, zsuwał się ze schodów i nadal reagował po śmierci. System służył nawet rozgrywce – strzał w głowę ciężkiego Helghasta obracał go i odsłaniał słaby punkt na plecach. 06 Boty dowodzone jak prawdziwa armia SI multiplayera miała trzy poziomy. Dowódca frakcji wybierał cele, punkty odrodzenia i sposób podziału sił. Liderzy oddziałów korzystali z planera HTN, rozbijając rozkaz na zebranie drużyny, atak oraz obronę, a pojedyncze boty wykonywały przydzielone zadania. Mapy widoczności pomagały im oceniać osłony i linie strzału. Zamiast samotnie biec do gracza, komputerowi żołnierze próbowali wygrać cały mecz jako drużyna. Killzone 2 nie wymyśliło wszystkich opisanych technik. Wyjątkowe było ich połączenie, skala wykorzystania oraz uruchomienie całego zestawu jednocześnie na PlayStation 3 wyposażonym w dwie oddzielne pule po 256 MB pamięci.

Angie Smets, późniejsza szefowa Guerrilla, wspominała po latach, że pracownicy oglądający konferencję w Amsterdamie byli przekonani, że każdy natychmiast rozpozna prerenderowany charakter filmu. Kiedy przedstawiciele Sony zaczęli sugerować, że pokazywane materiały prezentują możliwości konsoli w czasie rzeczywistym, atmosfera musiała zrobić się znacznie mniej zabawna. Twórcy wiedzieli przecież najlepiej, jak daleko właściwa gra znajdowała się od sceny, którą właśnie zachwycał się cały internet. A zachwycał się potężnie. W 2005 roku podobnej oprawy nie potrafiły wygenerować ani konsole, ani najmocniejsze komputery osobiste. Dyskusja o Killzone 2 szybko przestała więc dotyczyć samej gry. Zaczęła dotyczyć wiarygodności Sony, rzeczywistej mocy PlayStation 3 i pytania, czy nowa generacja naprawdę może dostarczyć taką oprawę. Każdy kolejny pokaz Guerrilli zatrzymywano klatka po klatce, porównując oświetlenie, animacje trafień, ilość dymu, zniszczenia otoczenia oraz liczbę obiektów znajdujących się na ekranie.

Od tego momentu Guerrilla nie mogła już po prostu stworzyć bardzo dobrej strzelanki. Musiała dogonić film, który powstał bez ograniczeń pamięci, wydajności procesora i czasu potrzebnego na wygenerowanie pojedynczej klatki. Prerenderowany zwiastun stał się nieoficjalną specyfikacją całej produkcji. Killzone 2 miało udowodnić, że marketingowa fantazja Sony była przynajmniej rozsądną prognozą przyszłości. Aby tego dokonać, Guerrilla musiała najpierw nauczyć PlayStation 3 rzeczy, do których ta konsola zdecydowanie nie została stworzona w prosty sposób. O tym właśnie będzie niniejszy materiał. Opowiem Wam, jak firma zdołała okiełznać PlayStation 3, bo źródeł, materiałów i ciekawych anegdot jest na ten temat mnóstwo. 

Kosmiczne sztuczki, brudna oprawa i mrugające światło 

Wewnętrzne cele produkcyjne dot. Killzone 2, Guerrilla zamknęła w czterech słowach: filmowe, gęste, realistyczne i intensywne. „Filmowe” oznaczało jakość animacji, oświetlenia i efektów kojarzoną wcześniej z prerenderowanymi scenami. „Gęste” - dużo postaci, cząsteczek, świateł i obiektów jednocześnie. Realizm nie polegał na kopiowaniu prawdziwego świata, lecz na jego wiarygodnych reakcjach: przeciwnik miał odpowiadać na trafienie, wybuch rozświetlać pobliskie ściany, a kurz i odłamki wypełniać przestrzeń. Intensywność była rezultatem działania wszystkich tych systemów naraz.

Skala produkcji szybko urosła do rozmiarów, jakich wcześniej w Guerrilla nie widziano. Studio liczyło średnio około 120 osób, w Amsterdamie zespół osiągał chwilami 140 pracowników, a kolejnych kilkudziesięciu specjalistów pomagało w innych oddziałach Sony. W szczytowym okresie przy kodzie pracowało około 27 programistów: siedmiu rozwijało technologię, sześciu sztuczną inteligencję, dziewięciu systemy rozgrywki, a pięciu tematy sieciowe. Prerenderowany zwiastun stworzył oczekiwania godne produkcji z przyszłości, więc trzeba było zbudować niemal całą technologię od nowa, żeby sprostać oczekiwaniom całego świata. 

Pierwszym poważnym przeciwnikiem nie byli jednak Helghaści, lecz architektura PlayStation 3. Konsola miała 256 MB bardzo szybkiej pamięci XDR wykorzystywanej przede wszystkim przez procesor Cell oraz oddzielne 256 MB GDDR3 podłączone do układu graficznego RSX. Oba podzespoły mogły w pewnym zakresie sięgać do sąsiedniej puli, ale nie równie szybko i swobodnie jak do własnej. Każdą teksturę, mapę cieni, model, animację i bufor obrazu należało więc nie tylko zmieścić, lecz także umieścić po właściwej stronie oraz dostarczyć dokładnie wtedy, gdy był potrzebny. Pół gigabajta pamięci brzmiało w reklamie rozsądnie. Dwie zamknięte szuflady po 256 MB były już znacznie mniej zabawne.

Jednym z największych wyzwań technicznych Killzone 2 okazało się oświetlenie, ponieważ Guerrilla nie traktowała go niczym nieruchomej dekoracji poziomu. Błysk wystrzału nie był wyłącznie jasną teksturą przyklejoną do lufy, bo na moment stawał się prawdziwym źródłem światła, rozjaśniał broń, dłonie żołnierza i pobliskie ściany, a nawet pozwalał rzucać cienie. Podczas większej potyczki na ten sam fragment otoczenia mogły jednocześnie oddziaływać słońce, reflektory, płomienie, eksplozje oraz serie z kilku karabinów. W klasycznym rendererze każde kolejne światło zwiększało liczbę obliczeń wykonywanych podczas rysowania obiektów, więc koszt takiej sceny błyskawicznie przekraczał możliwości układu RSX. Guerrilla potrzebowała rozwiązania, które pozwoliłoby najpierw narysować świat, a dopiero później oświetlić tylko te fragmenty obrazu, do których rzeczywiście docierał blask.

Rozwiązaniem stał się deferred shading, czyli metoda, w której silnik najpierw ustalał, co znajduje się przed kamerą, a dopiero później zajmował się światłem. Zamiast tworzyć gotowy obraz obiekt po obiekcie, Killzone 2 budowało najpierw szczegółową „kartę techniczną” każdego widocznego piksela. Cały proces można sprowadzić do czterech etapów:

1. Silnik rysował kształty. Sprawdzał, które ściany, postacie i przedmioty są widoczne, ale na tym etapie nie obliczał jeszcze pełnego oświetlenia.
2. Każdy piksel otrzymywał opis. Gra zapisywała jego podstawowy kolor, kierunek powierzchni, zdolność odbijania światła, odległość od kamery oraz informację o ruchu. Wiedziała więc, czy dany punkt należy do matowej ściany, błyszczącego metalu czy pancerza poruszającego się żołnierza.
3. Dopiero potem dodawano światła. Silnik brał kolejne lampy, eksplozje i błyski wystrzałów, sprawdzając, które piksele znajdują się w ich zasięgu. Światło z niewielkiego wybuchu nie musiało interesować się całym poziomem - obliczenia wykonywano tylko dla fragmentu obrazu, który rzeczywiście mogło rozjaśnić.
4. Na końcu składano gotową klatkę. Informacje o powierzchniach łączono z wynikami oświetlenia, tworząc obraz wyświetlany na ekranie.

Techniczny opis sceny przechowywano w G-bufferze, składającym się z czterech 32-bitowych warstw RGBA oraz osobnego bufora głębokości. Przy rozdzielczości 720p i wygładzaniu krawędzi Quincunx całość zajmowała około 36 MB - ponad 14% z 256 MB pamięci graficznej PlayStation 3, a przecież należało w niej zmieścić jeszcze tekstury, modele i pozostałe elementy obrazu.

Dlatego Guerrilla oszczędzała dosłownie na każdej informacji. Kierunek powierzchni opisują trzy wartości, ale silnik zapisywał tylko dwie, a trzecią obliczał podczas tworzenia klatki. Pełnego położenia każdego piksela również nie przechowywano - odtwarzano je później na podstawie jego miejsca na ekranie i odległości zapisanej w buforze głębokości. Konsola wykonywała przez to kilka dodatkowych działań matematycznych, ale były one znacznie tańsze niż utrzymywanie w pamięci kolejnych ogromnych warstw danych.

Deferred shading dawał Guerrilli dużą swobodę w ustawianiu świateł, ale miał jedną poważną słabość. G-buffer potrafił przechować opis tylko najbliższej, nieprzezroczystej powierzchni widocznej w danym pikselu. Dym, szkło i płomienie składały się natomiast z kilku nakładających się warstw, przez które nadal było widać otoczenie. Silnik musiał więc najpierw narysować oraz oświetlić budynki, postacie i pozostałe twarde elementy sceny, a dopiero później nałożyć na nie ogień, pył, iskry i kłęby dymu przy użyciu bardziej klasycznej metody. Najcięższe efekty powstawały przy tym w połowie albo nawet jednej czwartej właściwej rozdzielczości. Dym nie ma ostrych krawędzi, więc po powiększeniu, połączeniu z rozmyciem ruchu i przykryciu filmowym ziarnem trudno było zauważyć podstęp. RSX wykonywał za to znacznie mniej pracy, dzięki czemu ekran mógł wypełnić się cząsteczkami tworzącymi charakterystyczne dla Killzone 2 wrażenie totalnego chaosu.

Samo deferred shading nie było wynalazkiem Guerrilli, ale w połowie pierwszej dekady XXI wieku korzystało z niego zaledwie kilka wydanych gier, a połączenie tej metody z wygładzaniem krawędzi stanowiło spory problem techniczny. Killzone 2 zbudowano jednak właśnie wokół możliwości jednoczesnego wyświetlania wielu dynamicznych świateł. Każdą lampę zamykano w niewidzialnej bryle: zwykłe źródło światła otrzymywało kulę wyznaczającą zasięg blasku, natomiast reflektor - stożek odpowiadający jego wiązce. Testy głębokości i bufor pozwalały zaznaczyć wyłącznie piksele znajdujące się wewnątrz tej bryły. Jeżeli niewielka lampa oświetlała tylko róg pomieszczenia, kosztowne obliczenia wykonywano właśnie tam, a nie dla całego ekranu.

Najciekawszym przykładem był błysk wystrzału, dla którego programiści stworzyli specjalne światło nazwane „Frankensteinem”. Łączyło ono dwa różne rozwiązania: przed lufą działało jak stożkowy reflektor zdolny rzucać cienie, a poza tym obszarem zachowywało się jak krótki, punktowy rozbłysk. Dzięki temu pojedynczy strzał mógł jednocześnie rozświetlić dłonie żołnierza, broń, pobliską ścianę oraz sylwetkę przeciwnika, tworząc na moment nowe cienie. Dzisiaj podobne efekty łatwo uznać za oczywistość, ale w konsolowej strzelance z 2009 roku tak rozbudowana reakcja oświetlenia na każdy wystrzał była wyjątkowo ambitna. Tym bardziej, że przed wygenerowaniem cienia konsola musiała jeszcze narysować scenę z perspektywy danego światła. Guerrilla wykonywała więc szybki test widoczności: jeżeli rozbłysk znajdował się za ścianą i nie obejmował żadnego piksela widocznego dla gracza, RSX pomijał zarówno jego mapę cieni, jak i właściwe obliczenia światła. Odbywało się to bez odsyłania wyniku do procesora Cell, który tylko niepotrzebnie opóźniłby cały proces.

Równie dokładnie kontrolowano jakość widocznych świateł. Cienie małych albo odległych lamp nie znikały nagle, lecz stopniowo traciły intensywność, zanim silnik przełączał się na tańszy wariant obliczeń. Progi ustalano osobno dla poszczególnych źródeł, więc ważny reflektor mógł zachować cień z dużej odległości, podczas gdy krótki błysk eksplozji był upraszczany niemal natychmiast. Słońce potraktowano jeszcze inaczej, ponieważ obejmowało cały ekran i było najdroższym światłem w grze. Cienie nieruchomych budynków obliczano wcześniej i zapisywano w lightmapach, a silnik wykorzystywał je również do rozpoznawania fragmentów obrazu, których nie trzeba ponownie oświetlać. Postacie, pojazdy i inne ruchome obiekty otrzymywały natomiast cienie generowane w czasie rzeczywistym. Przestrzeń przed kamerą dzielono na kilka stref: najbliższa korzystała z najwyższej jakości oraz dokładnego wygładzania krawędzi, kolejne były stopniowo upraszczane, a najdalsza mogła całkowicie zrezygnować z dynamicznych cieni. Guerrilla opracowała również sposób stabilizowania tych stref, aby ich krawędzie nie migotały podczas poruszania i obracania kamery. W rezultacie gracz widział jednolicie oświetlone miasto, chociaż każda jego część była w rzeczywistości liczona z inną dokładnością. Żadna z tych sztuczek nie stanowiła osobnego cudu. Wyjątkowe było to, że Killzone 2 stosowało je wszystkie jednocześnie, na konsoli wyposażonej w zaledwie 256 MB pamięci graficznej.

Cell nie robił jednej wielkiej rzeczy. Robił tysiące małych

Procesor Cell obrósł legendą o „ukrytej mocy”, która miała objawiać się z każdym kolejnym rokiem życia PlayStation 3. Killzone 2 pokazuje jednak, że żadnej magii tam nie było. Obok głównego rdzenia PPE gry mogły korzystać z sześciu jednostek SPE, z których każda otrzymała zaledwie 256 KB własnej pamięci i nie miała klasycznej pamięci podręcznej. Nie nadawały się więc do swobodnego uruchamiania wielkich fragmentów kodu, ale potrafiły błyskawicznie obrabiać niewielkie, starannie przygotowane porcje danych. Guerrilla zbudowała wokół nich cały system pracy i przygotowała aż 44 rodzaje zadań, które mogły być rozdzielane pomiędzy SPE zależnie od aktualnej sytuacji w grze.

Lista obejmowała animacje, fizykę, wykrywanie kolizji, deformowanie skóry postaci, przewidywanie zagrożeń przez sztuczną inteligencję, omijanie przeszkód, sprawdzanie linii strzału, symulowanie cząsteczek, dekompresję dźwięku MP3, obsługę dynamicznej muzyki oraz przygotowywanie danych dla układu graficznego. Wszystko musiało zmieścić się w jednej klatce, czyli przy docelowych 30 FPS w czasie około 33 milisekund. Silnik potrafił wtedy przeliczyć mniej więcej 100 obiektów fizycznych, 200 animacji, 250 testów promieni, 250 aktywnych systemów cząsteczek, 600 próbek oświetlenia i około 2000 obiektów graficznych. Podczas jednej ze scen filmowych wszystkie operacje rozbito na około tysiąc drobnych zadań, chociaż ich łączny koszt odpowiadał obciążeniu zaledwie półtora SPE. W trakcie właściwej rozgrywki, gdy dochodziła sztuczna inteligencja, fizyka i reakcje na pociski, wykorzystywano przeciętnie moc odpowiadającą czterem lub pięciu jednostkom.

Szczególnie dużo pracy wymagały cząsteczki, bo to właśnie dym, pył, iskry i odłamki budowały charakterystyczną gęstość Killzone 2. W typowej klatce silnik aktualizował około 3000 cząsteczek należących do 250 systemów, z których mniej więcej 150 rzeczywiście trafiało na ekran. Około 200 dodatkowych testów sprawdzało ich zderzenia z otoczeniem, dzięki czemu iskra mogła odbić się od ściany, a trafienie pocisku uruchomić kolejny wybuch drobin. Pierwotny system powstał w zwykłym C++ i zupełnie nie pasował do architektury PlayStation 3, więc Guerrilla przez kilka miesięcy przenosiła go na SPE etapami: od generowania wierzchołków aż po zarządzanie całymi efektami. Po zakończeniu prac obciążenie głównego rdzenia spadło niemal do zera, a system działał wielokrotnie szybciej. Programiści wspominali przy tym, że każdą odzyskaną porcję mocy artyści natychmiast wykorzystywali do dodania kolejnych efektów. To dość dobrze wyjaśnia, dlaczego walki na Helghanie wyglądały tak, jakby ktoś nieustannie dorzucał grze jeszcze jeden worek z gruzem i pyłem.

SPE rozwiązywały także problem, którego gracz zwykle nie zauważa, dopóki coś nie zacznie wyglądać źle. Nieruchome budynki korzystały z oświetlenia zapisanego wcześniej w lightmapach, ale poruszającego się żołnierza nie dało się oświetlić raz na zawsze. Guerrilla rozmieszczała więc na każdym poziomie około 2500 sond, w których zapisywano kolor i kierunek światła padającego w danym miejscu. Dla dynamicznego obiektu silnik wybierał cztery najbliższe próbki, mieszał je i tworzył niewielką mapę światła o wymiarach 8x8 pikseli. W jednej klatce wykonywano około 600 takich operacji, co pochłaniało zaledwie 13% czasu pracy dla pojedynczego SPE. Dzięki temu Helghast wychodzący z ciemnego korytarza pod płonącą latarnię stopniowo przejmował barwę otoczenia, zamiast wyglądać jak jasno oświetlony model doklejony do gotowej planszy. Z systemu korzystały również ruchome i możliwe do zniszczenia elementy świata, więc statyczne oraz dynamiczne obiekty znacznie trudniej było od siebie odróżnić.

Cell pomagał także układowi RSX, ale nie poprzez samodzielne rysowanie grafiki. SPE przeszukiwały strukturę poziomu, odrzucały niewidoczne obiekty, przeliczały szkielety postaci, przygotowywały wierzchołki cząsteczek i budowały listy poleceń potrzebne do narysowania sceny oraz map cieni. Robiły to równolegle i możliwie późno, tuż przed momentem, w którym danych potrzebował układ graficzny. Guerrilla stworzyła nawet blokowy system pamięci: kiedy RSX kończył korzystać z określonej porcji poleceń, informował procesor, że zajmowane miejsce można ponownie wykorzystać. Pozwalało to uniknąć przechowywania dwóch pełnych zestawów danych dla kolejnych klatek, na co PlayStation 3 zwyczajnie nie miało pamięci. Cell pełnił więc rolę wyjątkowo sprawnej ekipy technicznej. Sortował pracę, przygotowywał materiały i pilnował, aby RSX ani przez chwilę nie czekał bezczynnie.

Ostatnią warstwę stanowił postprocessing, czyli zestaw efektów nakładanych już na niemal gotową klatkę. Killzone 2 wykorzystywało korekcję kolorów zależną od odległości, głębię ostrości, bloom, filmowe ziarno, odbicia wewnątrz obiektywu oraz motion blur oparty na zapisanych wcześniej wektorach ruchu. Nie rozmazywano więc bezmyślnie całego ekranu: silnik wiedział, które fragmenty obrazu poruszają się i w jakim kierunku. SPE generowały również tablice wykorzystywane do zmiany kolorystyki obrazu, dzięki czemu przejścia pomiędzy kolejnymi ustawieniami mogły zachodzić podczas działania gry. To właśnie te efekty ostatecznie spajały wszystkie techniczne elementy w charakterystyczny obraz Killzone 2 - brudny, przygaszony i wyglądający bardziej jak nagranie wykonane kamerą wojennego reportera niż sterylna demonstracja modeli 3D.

Równie istotne były narzędzia, bo zaawansowany silnik niewiele daje, jeżeli każda poprawka wymaga pół dnia czekania. Artyści, animatorzy i projektanci poziomów pracowali w jednym, potężnie zmodyfikowanym środowisku Maya. Guerrilla wyrzuciła nawet standardowy podgląd programu i zastąpiła go własnym rozwiązaniem, aby twórcy oglądali materiały w sposób możliwie zbliżony do tego, co później wyświetlało PlayStation 3. Studio stworzyło również Hyperiona do obliczania lightmap, AnimationBlendera do łączenia animacji, osobny edytor cząsteczek oraz ColorTweakera pozwalającego zmieniać kolorystykę bezpośrednio na działającej grze. Artysta mógł poprawić oświetlenie, uruchomić scenę na konsoli i szybko ocenić rezultat, zamiast za każdym razem przeprowadzać cały poziom przez długi proces eksportowania oraz konwersji. Technologiczną przewagą Killzone 2 nie był więc wyłącznie renderer. Była nią również szybkość, z jaką kilkudziesięciu artystów mogło bez końca poprawiać każdy jeden element.

Wojna musiała reagować na każdy pocisk

Największą przewagą filmu z 2005 roku była pełna kontrola nad wydarzeniami. Każdy pocisk trafiał dokładnie tam, gdzie zaplanowali animatorzy, żołnierz wykonywał przygotowany wcześniej ruch, a kamera zawsze znajdowała się w idealnym miejscu. W prawdziwej grze przeciwnik mógł oberwać w dowolną część ciała, z różnej broni, pod innym kątem i podczas biegu, przeładowania albo przeskakiwania przez przeszkodę. Guerrilla nie potrzebowała więc jednej efektownej animacji trafienia, lecz systemu potrafiącego tworzyć dziesiątki podobnych sytuacji na bieżąco.

Sercem rozwiązania był AnimationBlender, który łączył motion capture, ręcznie przygotowane ruchy oraz impulsy fizyczne. Poszczególne stawy i rodzaje trafień miały przypisane własne reakcje, a silnik decydował, jak mocno należy domieszać je do animacji wykonywanej właśnie przez postać. Pojedynczy humanoid mógł wykorzystać jednocześnie od dwóch do nawet pięćdziesięciu składników animacji. Pocisk uderzający w bark odrzucał więc górną część ciała, ale nogi nadal mogły próbować utrzymać równowagę. Wraz z kolejnymi trafieniami system stopniowo zwiększał udział fizyki, aż postać przechodziła w pełny ragdoll, spadała z podwyższenia albo zsuwała się po schodach. Nawet martwy przeciwnik reagował na następne strzały, ponieważ po śmierci jego ciało pozostawało obiektem fizycznym. Nie był to pierwszy ragdoll ani pierwsze wykorzystanie motion capture w strzelance. Wyjątkowe było płynne łączenie obu technik w system, który wpływał jednocześnie na wygląd, fizykę i samą rozgrywkę.

Najlepszym przykładem był ciężko opancerzony Helghast, którego słaby punkt znajdował się na plecach. Gracz mógł próbować go oskrzydlić, ale mógł też ostrzelać głowę przeciwnika. Odpowiednia reakcja na trafienie ogłuszała go i obracała, odsłaniając podatny na pociski fragment pancerza. System animacji nie służył więc wyłącznie do efektownego przewracania zwykłych żołnierzy, lecz stał się częścią mechaniki walki. Podobnie rozsądnie podzielono jakość pozostałych ruchów. Większość animacji rejestrowano za pomocą motion capture, ale przeładowania broni zawsze wykonywano ręcznie, ponieważ gracz oglądał je wielokrotnie z bardzo bliskiej odległości. W ostatnim roku produkcji studio korzystało także z przenośnego zestawu Xsens MVN. Animatorzy potrafili rano zarejestrować ruch we własnym biurze, a jeszcze tego samego dnia sprawdzić go w grze. Dopiero przygotowane w ten sposób sceny trafiały do właściwego studia, gdzie rejestrowano pełny ruch ciała, dłoni i twarzy.

Mimikę również skalowano zależnie od znaczenia sceny. Twarze zbudowano z blendshape’ów, czyli wymodelowanych wcześniej wyrazów twarzy, uzupełnionych kośćmi sterującymi szczęką oraz oczami. W kluczowych przerywnikach, takich jak przemówienie Visariego, ruch rejestrowano za pomocą markerów, a następnie poprawiali go animatorzy. Zwykłe okrzyki i rozmowy podczas walki powstawały znacznie taniej: do MotionBuildera wczytywano plik dźwiękowy, a program automatycznie generował podstawowy ruch ust. Gracz otrzymywał więc dopracowaną mimikę tam, gdzie kamera rzeczywiście mogła ją pokazać, bez marnowania miesięcy pracy na ręczne animowanie każdego „granat!” wykrzyczanego gdzieś za ścianą.

Reagować musiała również sztuczna inteligencja. Poziomy wypełniano tysiącami punktów nawigacyjnych, a z każdym wiązano przygotowaną wcześniej przestrzenną mapę widoczności. Dzięki niej przeciwnik mógł sprawdzić, czy z punktu A widać punkt B, którędy przebiec do osłony oraz czy wybrana trasa nie wystawi go pod ostrzał z innej pozycji. Kosztowne sprawdzanie linii strzału, przewidywanie zagrożeń i część operacji związanych z omijaniem przeszkód trafiały na SPE. Jeszcze ciekawiej wyglądały boty w multiplayerze. Każda frakcja otrzymywała nadrzędnego dowódcę, który wybierał cele, punkty odrodzenia i sposób podziału sił. Niżej działali dowódcy oddziałów korzystający z planera HTN, rozbijającego duże polecenie na kolejne etapy: zebranie drużyny, atak, zajęcie obszaru i obronę. Dopiero na samym dole pojedyncze boty zajmowały pozycje oraz prowadziły ogień. We wczesnym teście tej architektury osiem botów zmierzyło się z ośmioma pracownikami Guerrilli. Testerzy nadal nazywali zachowanie przeciwników nieco mechanicznym i przewidywalnym, ale koordynacja komputerowej drużyny była tak widoczna, że ludzie zaczynali przekrzykiwać się przez biuro i samodzielnie ustalać wspólną strategię.

Killzone 2 nie odtworzyło zwiastuna z 2005 roku klatka po klatce, bo prawdziwa gra miała znacznie trudniejsze zadanie. Musiała w ciągu około 33 milisekund rozstrzygnąć skutki każdego pocisku, ruch przeciwników, fizykę, animację, oświetlenie oraz setki efektów, a potem przygotować kolejną klatkę. Najlepszy epilog tej historii pojawił się już po premierze, gdy Guerrilla stworzyła interaktywną prezentację Behind the Bullet. Działała ona na silniku Killzone, pozwalała śledzić lot pocisku przez pole bitwy, zwalniać wydarzenia oraz oglądać warstwy obrazu składające się na gotową scenę. Na potrzeby demonstracji wczytano nawet filmowe modele liczące około 100 tysięcy polygonów i opracowano prototyp odbić w czasie rzeczywistym, których nie było jeszcze w podstawowej grze. Hermen Hulst nazwał cały projekt dowodem, że studio nie musi już korzystać z prerenderowanych materiałów, aby pokazywać swoją technologię. W 2005 roku Sony poprosiło graczy, żeby uwierzyli w film. Cztery lata później Guerrilla pozwoliła im zatrzymać własny silnik i zajrzeć do środka.