ICE Team. Ludzie, którzy nauczyli studia Sony programować na PlayStation 3
PlayStation 3 nie miało problemu z brakiem mocy. Problem polegał na tym, że Sony zaprojektowało konsolę, której potencjału nie dało się wykorzystać metodami znanymi z pecetów czy pierwszego Xboksa. Cell wymagał dzielenia obliczeń pomiędzy główny rdzeń i niewielkie jednostki SPE, ręcznego przesyłania danych oraz pilnowania dwóch oddzielnych obszarów pamięci. Wystarczyło źle rozłożyć zadania, aby potężny na papierze procesor zwyczajnie czekał na kolejną porcję danych. PS3 nie potrzebowało więc wyłącznie dobrych programistów. Potrzebowało ludzi, którzy najpierw ustalą, jak w ogóle należy w tym środowisku programować.
Kilka lat później efekty tej nauki były widoczne gołym okiem. Uncharted 2 zachwycało grafiką i skalą wydarzeń, God of War III pozwalało walczyć na ciele poruszającego się Tytana, Killzone 2 imponowało oświetleniem, a The Last of Us wyglądało jak produkcja stworzona dla sprzętu o generację nowszego. Każda z tych gier powstawała w innym studiu i korzystała z własnej technologii, ale wszystkie pokazywały ten sam proces: PlayStation 3 z roku na rok przestawało być dla twórców zagadką. Za tą przemianą nie stały wyłącznie coraz większe budżety i doświadczenie poszczególnych ekip. Wewnątrz Naughty Dog działał niewielki zespół, którego zadaniem było rozwiązywanie najtrudniejszych problemów technicznych całej platformy, a następnie przekazywanie gotowych rozwiązań pozostałym studiom. Nazywał się ICE Team, czyli Initiative for a Common Engine, choć nigdy nie stworzył jednego wspólnego silnika używanego we wszystkich grach Sony.
ICE Team przygotowywał biblioteki, fragmenty kodu, systemy animacji, narzędzia do obróbki geometrii oraz programy pozwalające dokładnie sprawdzić, gdzie konsola traci wydajność. Jego członkowie jeździli również do innych studiów, pracowali na ich prawdziwych modelach i animacjach, prowadzili szkolenia oraz pomagali wdrażać nowe rozwiązania bezpośrednio do powstających gier. Nazwy ICE Team nie widzieliśmy na pudełkach, ale rezultaty jego pracy oglądaliśmy niemal za każdym razem, gdy kolejna produkcja pokazywała, że granice możliwości PlayStation 3 znowu przesunięto.
Konsola, której nie projektowano dla gier
Historia ICE Team zaczęła się jeszcze przed premierą PlayStation 3. Około 2003 roku Shuhei Yoshida, wówczas odpowiedzialny za amerykańską część Sony Computer Entertainment, widział, że koszty produkcji rosną, zespoły puchną, a należące do firmy studia w pojedynkę rozwiązują podobne problemy. Każdy budował własne technologie, każdy popełniał własne błędy i każdy płacił za nie osobno. Przy kolejnej generacji taki model groził katastrofą.
Mark Cerny zaproponował więc utworzenie centralnej grupy technologicznej ulokowanej przy Naughty Dog. Jason Rubin i Andy Gavin zgodzili się wydzielić zespół ludzi pracujących wcześniej nad technologią wykorzystywaną przy serii Jak and Daxter. Tak narodziło się ICE, czyli Initiative for a Common Engine - inicjatywa wspólnego silnika. Nazwa okazała się nieco myląca. ICE nie zamierzało rozdawać studiom jednego ogromnego silnika i zmuszać wszystkich do tworzenia gier według identycznego schematu. Guerrilla potrzebowała innych rozwiązań niż Polyphony Digital, a zespół God of War III miał inne problemy niż twórcy SingStara. Zamiast technologicznego kombajnu powstał więc zestaw wyspecjalizowanych elementów, które można było przejąć, zmodyfikować albo wykorzystać wyłącznie jako wzorzec.
Było to tym ważniejsze, że architektura PlayStation 3 łamała przyzwyczajenia wyniesione z pecetów i wcześniejszych konsol. Cell Broadband Engine składał się z głównego rdzenia PPE oraz ośmiu jednostek SPE przeznaczonych do szybkich obliczeń wektorowych. Jedną wyłączano ze względu na uzysk produkcyjny, kolejną rezerwował system, dlatego gry mogły korzystać z sześciu. Każda dysponowała zaledwie 256 KB pamięci lokalnej, a dane trzeba było dostarczać do niej ręcznie poprzez operacje DMA. Do tego dochodził podział pamięci na 256 MB szybkiego XDR dla procesora i 256 MB GDDR3 dla układu RSX. Na papierze konsola miała pół gigabajta. W praktyce były to dwa osobne baseny, a przeniesienie danych w niewłaściwym kierunku potrafiło kreować wiele różnych problemów. Cell był szybki, lecz wymagał rozbijania pracy na małe zadania, pilnowania transferów i myślenia kilka kroków naprzód. Trochę jak zatrudnienie sześciu genialnych pracowników, którzy nie mają biurek, telefonów ani dostępu do magazynu.
Według anonimowych źródeł związanych z Naughty Dog, wczesna koncepcja PS3 miała nawet obyć się bez klasycznego GPU, a testy ICE Team miały wykazać, że renderowanie oparte głównie na jednostkach SPE nie zapewni oczekiwanych rezultatów. Sony nigdy oficjalnie tej wersji nie potwierdziło, dlatego nie należy przedstawiać jej jako pewnika. Sama opowieść dobrze pokazuje jednak, jak wcześnie ICE znajdowało się w całym procesie projektowania sprzętu. Przedstawiciele zespołu współpracowali z ekipą sprzętową w Tokio, testowali założenia i próbowali zbudować pomost między możliwościami CPU, a rzeczywistością produkcji gier. Most był potrzebny, bo Sony zaprojektowało prawdopodobnie najpotężniejszą łamigłówkę swojej epoki.
Skoro ICE Team powstało w 2003 roku, dlaczego pierwsze gry na PS3 były tak fatalne technicznie?
Skoro ICE Team działał już od 2003 roku, dlaczego początek generacji PS3 był tak trudny? Przede wszystkim zespół nie otrzymał ukończonej konsoli i kilku lat na spokojne przygotowanie narzędzi. Jego programiści poznawali Cella równolegle z konstruktorami sprzętu, korzystając ze zmieniających się zestawów deweloperskich oraz bardzo niedojrzałego środowiska. Mark Cerny porównywał później pracę z tym procesorem do układania kostki Rubika i przyznawał, że produkcja gier zajmowała więcej czasu niż na wcześniejszych platformach Sony. Wiele problemów ujawniało się dopiero podczas tworzenia prawdziwych gier. Trzeba było sprawdzić, które zadania warto przenieść na jednostki SPE, jak dostarczać im dane i jak podzielić obciążenie, aby Cell nie tracił czasu na czekanie. Dopiero później takie rozwiązanie można było uporządkować, przetestować i przekazać innym zespołom. ICE Team powstał więc wcześnie, ale wiedzę o PS3 należało dopiero wypracować.
Skalę tego opóźnienia najlepiej pokazuje kalendarz. PlayStation 3 trafiło do sprzedaży w listopadzie 2006 roku, natomiast PlayStation Edge - najważniejszy pakiet technologii opracowanych z udziałem ICE - zaprezentowano dopiero podczas GDC w marcu 2007 roku. Gry startowe tworzono więc pod presją premiery, korzystając z wcześniejszych wersji bibliotek i narzędzi. Sony budowało samolot, szkoliło pilotów i pisało instrukcję obsługi niemal w tym samym czasie. Trudno się dziwić, że pierwsze loty nie zawsze przebiegały gładko. Największe problemy miały silniki projektowane przede wszystkim z myślą o pececie i Xboksie 360. Tam większość logiki wykonywał klasyczny procesor, a renderowaniem zajmował się układ graficzny. Próba przeniesienia podobnego schematu na PS3 szybko zapychała niezbyt wydajny rdzeń PPE, pozostawiała część jednostek SPE bez pracy i rozbijała się o dwie oddzielne pule pamięci po 256 MB. Aby wykorzystać możliwości Cella, należało przebudować system zadań, streaming, animację, kompresję danych, a często również narzędzia używane przez artystów. Tego nie dało się załatwić poprawką wrzuconą miesiąc przed premierą.
Dlatego problem najmocniej dotykał gier wieloplatformowych. Ich twórcy rzadko mogli sobie pozwolić na napisanie znacznej części silnika specjalnie dla jednej konsoli, więc wybierali działający port, nawet jeśli oznaczało to niższą rozdzielczość, gorszą płynność albo dłuższe doczytywanie. Nie wszystkie wczesne produkcje na PS3 działały fatalnie - Resistance: Fall of Man i MotorStorm pokazywały, że bezpośrednie wsparcie Sony przynosiło efekty już w okolicach premiery. Różnica polegała na tym, że ich twórcy budowali technologię pod konkretny sprzęt, zamiast wciskać PS3 do schematu przygotowanego dla konkurencyjnej platformy.
Silnik, który przestał być silnikiem
PlayStation Edge było praktycznym rezultatem kilku lat podobnych eksperymentów. Pakiet powstał wspólnie z europejskim Advanced Technology Group oraz amerykańskim Tools and Technology, dlatego nie należy przypisywać całego przedsięwzięcia wyłącznie ICE Team. Jego twórcy zebrali sprawdzone rozwiązania dotyczące animacji, geometrii, kompresji i analizy wydajności, a następnie udostępnili je wraz z kodem źródłowym wszystkim licencjonowanym producentom gier na PS3. Studio mogło wykorzystać wybrane elementy i dopasować je do własnej technologii, zamiast czekać, aż Sony stworzy jeden silnik odpowiedni dla każdego rodzaju gry.
Edge Animation zajmował się przetwarzaniem ruchów postaci, które wraz ze wzrostem jakości modeli pochłaniały coraz więcej pamięci i mocy procesora. System potrafił płynnie łączyć kilka animacji: nogi bohatera mogły odpowiadać za bieg, tułów obracać się w stronę celu, a ręce reagować na odrzut broni. Programista określał przy tym, na które części ciała i z jaką siłą ma wpływać dany ruch, dzięki czemu oddanie strzału nie przerywało animacji biegu. Wszystkie te dane dodatkowo kompresowano, aby zajmowały mniej miejsca w ograniczonej pamięci PS3. Dzięki temu postać mogła jednocześnie biec, celować, obracać tułów i reagować na podłoże bez przechowywania dziesiątek gotowych wariantów każdego ruchu. System ograniczał zużycie pamięci i przenosił część obliczeń z głównego procesora na SPE. Jeszcze większe znaczenie miał Edge Geometry. Jednostki SPE rozpakowywały dane wierzchołków i indeksów, wykonywały skinning postaci, obsługiwały blend shapes oraz odrzucały niewidoczne trójkąty, zanim te zdążyły obciążyć układ RSX. W demonstracyjnym scenariuszu pojedynczy SPU przetwarzał ponad 800 tysięcy trójkątów na klatkę przy 60 kl./s, usuwając około 60% z nich przed rozpoczęciem właściwego renderowania.
Wyniki zależały od rodzaju sceny i przygotowanych danych, ale dobrze pokazywały, ile można było zyskać jeszcze przed rozpoczęciem właściwego renderowania. Indeksy, czyli krótkie listy określające, z których punktów modelu należy zbudować kolejne trójkąty, udawało się kompresować nawet o 85%. W demonstracyjnym scenariuszu pozwalało to zmieścić w tym samym limicie danych około 6,5 raza więcej trójkątów. Dodatkowe 10-20% wydajności przynosił culling, a więc odrzucanie fragmentów geometrii niewidocznych z perspektywy gracza. RSX nie tracił czasu na obrabianie całego modelu, skoro duża jego część znajdowała się poza ekranem albo za innymi obiektami.
Edge pomagał również w dostarczaniu danych z płyty Blu-ray. Wykorzystywał do tego zlib - popularną bibliotekę bezstratnej kompresji opartą na algorytmie DEFLATE, stosowanym również między innymi w plikach PNG oraz archiwach gzip. Program wyszukuje w danych powtarzające się fragmenty i zastępuje je krótszymi odwołaniami. Po rozpakowaniu otrzymujemy dokładnie tę samą zawartość, bez utraty choćby jednego bajta. W przypadku gry mogły to być dane geometrii, animacje, skrypty albo inne elementy przygotowane wcześniej przez twórców.
Na PS3 problemem nie było jednak samo zmniejszenie plików, lecz ich wystarczająco szybkie rozpakowanie podczas rozgrywki. Napęd Blu-ray odczytywał dane z prędkością około 9 MB/s, dlatego przechowywanie ich w skompresowanej postaci zwiększało ilość informacji, którą konsola mogła pobrać w tym samym czasie. Moduł Edge rozpakowywał strumień zlib z prędkością około 40 MB/s, wykorzystując przy tym mniej więcej jedną czwartą mocy pojedynczego SPU. Dekompresja nie stawała się więc kolejnym wąskim gardłem. Konsola mogła na bieżąco pobierać mniejsze paczki z płyty, rozpakowywać je w tle i przekazywać silnikowi, zanim gracz dotarł do kolejnej części poziomu. W praktyce oznaczało to sprawniejszy streaming świata, mniejsze zużycie pamięci i mniej ekranów ładowania.
Jednym z najciekawszych rozwiązań Edge było przetwarzanie geometrii „just in time”. Bez niego konsola mogła przechowywać dwa kompletne bufory: z jednego RSX odczytywał gotowe modele bieżącej klatki, podczas gdy w drugim jednostki SPE przygotowywały dane dla następnej ramki. Było to bezpieczne, ale zajmowało dużo cennej pamięci i wydłużało cały proces renderowania. Edge pozwalał skrócić tę kolejkę. Główny procesor zostawiał w buforze poleceń puste miejsca, a SPE wypełniały je przetworzoną geometrią oraz instrukcjami rysowania chwilę przed tym, zanim RSX miał je wykonać. Dane nie musiały więc czekać na następną klatkę ani leżeć w drugim ogromnym buforze.
Technologia sprawdziła się w praktyce. DICE wykorzystało Edge Geometry w systemie zniszczeń silnika Frostbite 2, który napędzał między innymi Battlefield 3. Na PS3 jednostki SPE sprawdzały, które trójkąty obiektu znajdowały się wewnątrz obszaru zniszczenia, a następnie rozdzielały geometrię na dwa zestawy: fragmenty wymagające pokazania uszkodzeń oraz całą resztę modelu. RSX otrzymywał już przygotowane listy i nie musiał wykonywać kosztownych warunków dla każdego trójkąta. Według prezentacji DICE, właśnie to rozwiązanie dawało na PS3 najlepszą wydajność GPU spośród testowanych metod rysowania maski zniszczeń. Było trudniejsze do włączenia do wieloplatformowego silnika, ale przynosiło realny efekt tam, gdzie standardowy sposób obciążał RSX zbyt mocno.
Drugim filarem pakietu był GCM Replay, czyli narzędzie pozwalające dokładnie odtworzyć pracę układu graficznego. Deweloper mógł zatrzymać interesującą go klatkę i przechwycić bufor poleceń, tekstury, modele, shadery oraz zawartość pamięci wykorzystywaną przez RSX. Następnie całą klatkę odtwarzano na zestawie deweloperskim i analizowano od ogólnego przebiegu renderowania aż po pojedyncze polecenie renderowania, wierzchołek czy piksel. Zamiast zgadywać, dlaczego konkretna scena nagle traciła wydajność, programista widział, ile kosztował każdy etap i które zasoby niepotrzebnie obciążały konsolę. Podczas prezentacji technologii wykorzystanej w Uncharted: Drake’s Fortune, Christophe Balestra i Pål-Kristian Engstad wymienili GCM Replay jako stały element zestawu używanego przez programistów Naughty Dog. Nie był to więc profiler pokazany na GDC i odłożony na półkę, lecz część normalnego procesu tworzenia pierwszego Uncharted. Przy grze, która bez przerwy przesyłała z dysku poziomy, postacie, tekstury, dźwięki i muzykę, możliwość zatrzymania dowolnej klatki oraz sprawdzenia pracy RSX miała OGROMNE znaczenie.
Ludzie, których pracy nie było widać
Najlepiej zrozumieć działalność ICE Team nie przez listę bibliotek, lecz przez historię Keitha Brunsa. W latach 2003-2006 był technicznym artystą zespołu i pełnił rolę łącznika między programistami budującymi technologię, a ludźmi, którzy mieli później zrobić z niej prawdziwą grę. Według jego wspomnień początkowo współpracował z około 13-16 studiami. Nie ograniczał się jednak do wysłania dokumentacji i życzenia powodzenia. Jeździł do zespołów, brał ich modele, animacje i materiały, a następnie sprawdzał, jak technologie ICE zachowują się na rzeczywistych zasobach produkcyjnych. Prowadził szkolenia, pomagał tworzyć potoki pracy i tłumaczył artystom, jak przygotowywać dane, aby egzotyczna architektura PS3 nie dławiła się nimi kilka miesięcy przed premierą.
Jednym z modeli używanych przez Brunsa podczas takich prac był „George: The Treebeast” - fantastyczne stworzenie przypominające żywe drzewo. Można powiedzieć, że było to takie ruchome laboratorium stworzone z myślą o szkoleniach i eksperymentach. Jego gałęzie oraz włosy uginały się pod wpływem fizyki, ciało deformował system symulujący pracę mięśni, a progresywna siatka pozwalała stopniowo zmniejszać liczbę wielokątów wraz z oddalaniem postaci od kamery. Bruns przygotował model w ZBrushu, który dopiero zdobywał popularność w branży, a później wykorzystywał go do uczenia artystów, jak przenosić bardzo szczegółowe rzeźby do świata ograniczonej pamięci i czasu procesora. George nie trafił do pudełka z żadną grą, ale rozwiązane przy nim problemy mogły już trafić wszędzie.
Widać to szczególnie dobrze na przykładzie współpracy z Insomniac Games. Podczas produkcji Resistance: Fall of Man ICE pomagało przy riggowaniu i animowaniu przeciwników, którzy zachowywali humanoidalną sylwetkę, lecz mieli inne proporcje, budowę i sposób poruszania się niż zwykły człowiek. Nie wystarczyło więc założyć na Chimerę standardowego szkieletu wykorzystywanego przez żołnierzy. Poszczególne elementy systemu trzeba było dostosować do konkretnych typów stworzeń, ich dodatkowych kończyn oraz nienaturalnych póz. Co ważniejsze, wypracowana w ten sposób technologia nie skończyła życia razem z Resistance. Część rozwiązań przeniknęła później do Ratchet & Clank. Właśnie tutaj najlepiej widać sens istnienia ICE: raz wykonana praca nie należała już wyłącznie do jednej gry.
Podobny mechanizm działał przy Lair i Warhawku. Obie produkcje pokazywały rozległe przestrzenie oglądane zarówno z bliska, jak i z dużej wysokości. Model budynku albo fragment terenu musiał wyglądać przyzwoicie, gdy gracz niemal ocierał się o niego kamerą, ale nie mógł zachowywać całej szczegółowości, kiedy zmieniał się w plamkę kilkaset metrów dalej. Bruns pomagał zespołom korzystać z progresywnych siatek, które płynnie upraszczały geometrię wraz ze wzrostem odległości, oraz przygotowywać materiały i tekstury tak, aby przejścia między poziomami szczegółowości nie rzucały się w oczy. Dla gracza oznaczało to większą przestrzeń i mniej wyskakujących nagle obiektów. Dla konsoli - tysiące trójkątów, których nie trzeba było bezsensownie przetwarzać.
ICE pojawiało się również tam, gdzie spektakularne technologie znacznie trudniej zauważyć. Przy MLB 07 i NBA 07 Bruns pracował nad przechwytywaniem ruchu, oświetleniem, materiałami, animacją postaci oraz tak zwanym ruchem drugorzędnym - wszystkim, co porusza się nie dlatego, że animator ręcznie ustawił każdą klatkę, lecz w reakcji na ruch ciała. Dotyczyło to między innymi ubrań zawodników. Pełna symulacja każdego zagięcia tkaniny byłaby zbyt kosztowna, dlatego stosowano sprytniejsze oszustwo. Model koszulki pozostawał stosunkowo prosty, ale podczas ruchu zmieniał się sposób jej oświetlenia, tworząc wrażenie pojawiających się i znikających fałd. Zawodnik biegł, obracał tułów, a materiał wyglądał, jakby pracował razem z jego ciałem, choć konsola nie musiała obliczać zachowania każdego zagięcia. Gracz nie widział technologicznej sztuczki - widział po prostu bardziej naturalnie poruszającą się postać.
Najszerszy zakres współpracy Bruns przypisuje pierwszemu Uncharted. ICE wspierało Naughty Dog w animacji, shaderach, oświetleniu, renderingu, efektach oraz optymalizacji. Trudno wskazać jeden kadr i powiedzieć: „to zrobił ICE Team”, ponieważ ich technologia była wszyta w fundamenty całej produkcji. Drake płynnie przechodził między biegiem, wspinaczką, strzelaniem i reakcjami na otoczenie, dżungla była pełna dynamicznie ruszających się liści oraz efektów, a konsola potrafiła przesyłać kolejne fragmenty świata bez rozbijania przygody ekranami ładowania. Uncharted nie rozwiązało wszystkich problemów PlayStation 3, ale po raz pierwszy pokazało szerokiej publiczności, że trudna architektura nie musi być dla gry wyrokiem. Ciekawe jest również to, co stało się z Brunsem później. Po odejściu z ICE został dyrektorem technicznym postaci przy pierwszym inFamous. Przygotowywał między innymi próbniki oświetlenia HDR używane w świecie gry oraz ponad dwieście animacji kamer wykorzystywanych w scenach, rozpoczęciach misji i krótkich sekwencjach fabularnych. To nie była już działalność centralnego zespołu technologicznego, ale właśnie na tym polegał długofalowy efekt ICE. Ludzie, którzy wcześniej uczyli kilka studiów rozwiązywać problemy PS3, przechodzili później bezpośrednio do produkcji i zabierali tę wiedzę ze sobą.
Bruns był przy tym tylko jedną z osób tworzących ICE. Technicznymi liderami zespołu byli między innymi David Simpson i Swaminathan Narayanan, a przy bibliotekach Edge pracowali programiści tacy jak Jon Olick, Cort Stratton czy Andrew Cove. Olick wraz z Markiem Cernym i Vincem Diesim prezentował PlayStation Edge podczas GDC w 2007 roku, pokazując publicznie, jak Sony zamierza przenieść część animacji oraz przetwarzania geometrii na jednostki SPU. Nie była to więc wyłącznie wewnętrzna technologia Naughty Dog. Miała stać się wspólnym punktem odniesienia dla całego ekosystemu PlayStation 3.
Szczególnie interesująca jest kariera Corta Strattona. Przez jedenaście lat pisał dla Sony kod graficzny działający na poziomie całej platformy. Przy PS3 współtworzył Edge Geometry, wykorzystywane później w dziesiątkach produkcji, natomiast przy PlayStation 4 pracował nad oficjalnym interfejsem renderowania konsoli. Następnie trafił do Google, gdzie pomagał deweloperom korzystać z Vulkan API i uczestniczył w pracach grupy rozwijającej ten standard, a później przez blisko osiem lat zajmował się w Unity technologią DOTS oraz systemem Entities. Ostatecznie wrócił do Sony, ponownie pracując nad podstawowymi technologiami PlayStation. Jego kariera dobrze pokazuje, że ICE nie było doraźną grupą ratunkową powołaną wyłącznie po to, aby poskładać PS3. Była to kuźnia specjalistów, którzy później współtworzyli fundamenty następnych generacji sprzętu i silników.
Jeszcze szerszy ślad pozostawił Morten Mikkelsen, wymieniany wśród członków ICE w napisach Uncharted 2, Killzone 2 i God of War III. To autor MikkTSpace - standardu, który rozwiązał jeden z wyjątkowo uporczywych problemów grafiki 3D. Twórcy potrafią sprawić, że stosunkowo prosty model wygląda jak pokryty drobnymi wgłębieniami, rysami i załamaniami, odpowiednio sterując sposobem odbijania się od niego światła. Nie trzeba dzięki temu modelować każdej zmarszczki na skórze, rysy na metalu czy szczeliny między cegłami.
Problem pojawiał się wtedy, gdy program używany przez grafika i silnik gry obliczały zachowanie powierzchni w nieco inny sposób. Model wyglądający idealnie podczas tworzenia po przeniesieniu do gry potrafił nagle ujawnić wyraźne szwy, dziwne załamania światła albo detale sprawiające wrażenie wklęsłych zamiast wypukłych. MikkTSpace ujednolicił te obliczenia, dzięki czemu ten sam obiekt może wyglądać zgodnie z zamierzeniem artysty na każdym etapie produkcji. Rozwiązanie jest dziś obsługiwane między innymi przez Blendera, Unity oraz narzędzia Adobe Substance i stało się jednym ze standardów współczesnej grafiki 3D. Nie było oficjalnym modułem PlayStation Edge, ale doskonale pokazuje kaliber ludzi tworzących ICE: ich pomysły potrafiły wyjść daleko poza jedną konsolę.
Najbardziej widowiskowym dowodem skuteczności całego modelu pozostaje God of War III. Santa Monica Studio korzystało z Edge Geometry, ale biblioteka była tylko częścią znacznie większej przebudowy silnika. Na jednostki SPU przeniesiono między innymi symulację, przeglądanie sceny i część zadań renderera, dzięki czemu wiele systemów mogło działać równolegle. W tej samej produkcji Tytani zostali potraktowani jak „żyjące poziomy”: ogromne, animowane środowiska, po których poruszał się Kratos, podczas gdy kamera, przeciwnicy, kolizje i efekty nadal działały jak w zwykłej walce. Nie da się uczciwie powiedzieć, że Kronosa stworzyło samo Edge Geometry. Można jednak powiedzieć, że bez całej kultury dzielenia pracy między procesory, rozwijanej i popularyzowanej przez ICE, podobna scena byłaby znacznie trudniejsza do zrealizowania.
ICE Team okazał się zbawienny
Dopiero z tej perspektywy lista gier przypisywanych ICE Team zaczyna robić właściwe wrażenie. Nazwiska członków zespołu pojawiają się w napisach Resistance, MotorStorma, Heavenly Sword, Warhawka, Formula One Championship Edition, Killzone 2, inFamous, Heavy Rain, MAG, Gran Turismo 6 oraz kolejnych produkcji Naughty Dog. Nie oznacza to oczywiście, że wszystkie te tytuły korzystały z identycznego zestawu bibliotek ani że ICE wykonywało w nich tę samą pracę. Czasami chodziło o gotowy moduł Edge, innym razem o konsultacje, szkolenie artystów, analizę wąskiego gardła albo rozwiązanie przygotowane specjalnie dla konkretnego silnika.
Sama obecność tych ludzi w tylu projektach mówi jednak coś ważnego. ICE nie było zespołem przypisanym do jednej serii ani nawet jednego studia. Praca tego studia przecinała niemal cały katalog Sony: od strzelanin i wyścigów, przez gry sportowe, aż po filmowe przygody i techniczne popisy Polyphony Digital. Problem rozwiązany przy modelach przeciwników w Resistance mógł pomóc przy Ratchet & Clank. Technologia upraszczania geometrii sprawdzona przy rozległych przestrzeniach Warhawka mogła później posłużyć jako punkt wyjścia dla zupełnie innej produkcji. Koniec projektu nie zamykał poszerzania wiedzy.
Właśnie tutaj kryje się największy paradoks PlayStation 3. Sony zaprojektowało konsolę jako egzotyczną maszynę, która miała technologicznie wyprzedzić konkurencję. Cell miał być jej przewagą, ale przez pierwsze lata stał się przede wszystkim źródłem bólu głowy. Ostatecznie najcenniejszym skutkiem tej architektury nie okazał się sam procesor, lecz kultura współpracy, którą jego trudność wymusiła. Skoro pojedyncze studio nie mogło samodzielnie odkrywać wszystkich sekretów konsoli, Sony musiało nauczyć swoje zespoły wspólnie rozwiązywać problemy, dzielić się kodem i przekazywać doświadczenia dalej. Brak jakiejkolwiek wygody programowania wymusił więc bardzo dobry obieg wiedzy. Brzmi jak próba znalezienia zalet w kosztownej pomyłce, ale jej skutki wykraczały daleko poza jedną generację. ICE Team przetrwał konsolę, którą początkowo miał pomóc okiełznać. W kolejnych latach Naughty Dog nadal przedstawiało go jako centralną grupę technologiczną rozwijającą podstawowe rozwiązania graficzne, biblioteki renderowania, narzędzia, profilery oraz systemy debugowania wykorzystywane przez studia PlayStation. Ogłoszenia rekrutacyjne wiązały jego działalność już nie tylko z grami, lecz także z projektowaniem technologii dla PS4 i PS5 - od niskopoziomowych interfejsów graficznych po elementy związane z obsługą systemu pamięci masowej.
Najlepszym dowodem tej zmiany jest sama konstrukcja PlayStation 4. Sony nie próbowało już budować konsoli wokół procesora, który miał zachwycić inżynierów i dopiero później zostać objaśniony twórcom gier. Mark Cerny jako główny architekt PS4 od początku konsultował projekt z deweloperami. Zamiast kolejnego Cella wybrano znacznie bardziej znajomą architekturę x86-64. Zamiast dwóch oddzielnych pul pamięci - 256 MB dla procesora i 256 MB dla układu graficznego - zastosowano 8 GB zunifikowanej pamięci GDDR5, z której mogły korzystać oba podzespoły. Programista nie musiał już poświęcać połowy energii na walkę z maszyną, zanim w ogóle zaczął optymalizować grę.
Nie był to przypadek ani nagłe olśnienie. Sony wyciągnęło z PS3 brutalnie prostą lekcję: specyfikacja konsoli jest tylko początkiem. Równie ważne pozostają dokumentacja, kompilatory, profilery, biblioteki, narzędzia dla artystów i możliwość szybkiego skonsultowania problemu z kimś, kto już wcześniej go rozwiązał. Potężny sprzęt bez całego tego zaplecza przypomina znakomity samochód sprzedawany bez kierownicy. Teoretycznie wszystko się zgadza, ale daleko się nim nie zajedzie. Czy ICE Team uratował PlayStation 3? To kusząca legenda, lecz zdecydowanie zbyt prosta. Konsoli pomogły obniżki ceny, nowe modele, dojrzewające narzędzia, rosnąca baza użytkowników i lata ciężkiej pracy setek programistów. Nie bez znaczenia było również to, że studia z czasem po prostu nauczyły się projektować gry pod Cella, zamiast traktować PS3 jak niewygodną wersję Xboksa 360. ICE nie naprawiło wszystkich błędów Sony i nie napisało potajemnie każdej udanej produkcji na tę platformę.
Zrobiło jednak coś, bez czego późniejsze sukcesy przychodziłyby znacznie wolniej. Pomogło zamienić możliwości istniejące głównie w prezentacjach technologicznych w powtarzalne rozwiązania, które można było zastosować w prawdziwej grze. Nie chodziło już o pojedynczego geniusza, który znał jedną sprytną sztuczkę z jednostkami SPU. Chodziło o bibliotekę, dokumentację, przykład i narzędzie pozwalające wdrożyć tę sztuczkę w kolejnym studiu, a następnie wykorzystać ją jeszcze raz bez rozpoczynania wszystkiego od zera. W historii gier najłatwiej zapamiętać ludzi odpowiedzialnych za rezultat widoczny na ekranie: reżysera, projektanta, aktora, kompozytora albo głównego grafika. Dziedzictwo ICE Team składa się z rzeczy znacznie mniej efektownych. Z animacji, która po kompresji zmieściła się w pamięci. Modelu uproszczonego bez zauważalnej utraty jakości. Milisekundy odzyskanej z renderowania. Narzędzia, dzięki któremu przyczynę spadku płynności znaleziono w godzinę, a nie po tygodniu zgadywania. Wreszcie z wiedzy, którą jeden inżynier zawiózł do studia, aby później wróciła do całej organizacji w postaci gotowego rozwiązania.
PlayStation 3 nie było konsolą, którą wystarczyło po prostu dobrze zaprogramować. Najpierw trzeba było odkryć, jak w ogóle powinno się ją programować. ICE Team pomógł stworzyć ten język, nauczył go kolejne zespoły, a zdobyte przy tym doświadczenie wpłynęło na sposób, w jaki Sony zaprojektowało następną generację. Studio pozostawiło dziesiątki gier, które bez jego pracy mogłyby wyglądać i działać zupełnie inaczej. Trudno o bardziej cyfrowe arcydzieło niż technologia, której gracz nigdy nie zobaczył, choć przez lata oglądał wszystko, co dzięki niej stało się możliwe.
Przeczytaj również
Komentarze (6)
SORTUJ OD: Najnowszych / Najstarszych / Popularnych