RenderWare na PS2. Silnik, który zbudował całą generację. Od GTA III do Burnouta
GTA III, Burnout 3, Black i Persona 4 wymieniane w jednym szeregu są fantastycznymi grami na PlayStation 2. Pierwsza z nich potrzebowała całego żyjącego miasta, druga setek odłamków podczas kraksy, trzecia broni zachowującej się niesamowicie realistycznie i efektownie, a czwarta kalendarza obejmującego cały rok szkolny w sennej Inabie. Wszystkie korzystały jednak z RenderWare - technologii Criterion, która dla graczy była zwykle tylko krótkim logo na ekranie startowym, a dla branży stała się jednym z głównych filarów całej generacji.
Na początku XXI wieku taki wspólny fundament miał znacznie większą wartość niż dzisiaj. PlayStation 2 dysponowało ciekawymi rozwiązaniami technicznymi, lecz dwie jednostki wektorowe, transfery DMA, 32 MB pamięci głównej i zaledwie 4 MB eDRAM wymagały od programistów żelaznej dyscypliny. Criterion dostarczało gotową warstwę renderowania, narzędzia do obróbki zasobów oraz potoki dopasowane do konkretnych platform, dzięki czemu studia nie musiały rozpoczynać każdej produkcji od wielomiesięcznej walki ze sprzętem.
RenderWare już na starcie ułatwiał zadanie, chociaż nie był łatwy we współpracy. Oferował programistom bardzo fajny start, który mogli głęboko przebudować. Rockstar opracował własny system streamingu otwartego świata, Criterion stworzyło własny model jazdy i zniszczeń, a Atlus wykorzystał tą samą technologię do zbudowania rozbudowanego RPG. Właśnie ta swoboda sprawiła, że RenderWare obsłużyło niemal każdy gatunek obecny na PS2 i stało się technicznym zapleczem epoki - aż Electronic Arts przejęło Criterion, a następca przygotowywany na nową generację nie zdołał powtórzyć tego sukcesu.
Z laboratorium Canona prosto pod telewizor
Opowieść o historii silnika rozpoczynamy dość wcześnie, na długo przed premierą PlayStation 2. David Lau-Kee i Adam Billyard planowali powstanie Criterion jeszcze w 1992 roku, podobno przy kuchennym stole w Londynie. W 1993 roku, pod skrzydłami europejskiego działu badawczego Canona, powstały Criterion Software i RenderWare. Billyard po latach pokazał nawet zdjęcie technologii działającej na stacji roboczej Sun SPARCstation 2. Trudno o obrazek bardziej odległy od salonu, DualShocka 2 i płyty z San Andreas.
Pierwszy RenderWare nie był jeszcze silnikiem dla gier w dzisiejszym rozumieniu. Stanowił bibliotekę programistyczną napisaną dla języka C, która pozwalała aplikacji tworzyć sceny 3D, ustawiać kamerę, materiały i światła, a następnie wyświetlać obraz na różnych komputerach. Z dzisiejszej perspektywy brzmi to całkiem zwyczajnie. Na początku lat 90., przed upowszechnieniem konsumenckich akceleratorów 3D i wspólnych standardów, taki pomysł był niemal bezczelny. Criterion konkurowało wówczas między innymi z BRenderem firmy Argonaut oraz Reality Lab, przejętym później przez Microsoft i wykorzystanym przy tworzeniu Direct3D. Problem był na papierze prosty do rozwiązania - twórcy gier pisali mnóstwo kodu od zera, sprzęt zmieniał się jak w kalejdoskopie, a przeniesienie projektu na inną platformę potrafiło oznaczać ponowne zbudowanie znacznej części technologii. RenderWare przyspieszało znaczną część prac i oszczędzało czas programistów.
W 1996 roku powstał osobny dział Criterion Studios. Miał tworzyć gry i jednocześnie udowodnić, że firmowa technologia działa poza schludną prezentacją dla klientów. Tak narodziły się między innymi Redline Racer, futurystyczne TrickStyle i późniejsze AirBlade. Nie wszystkie były wielkimi sukcesami, ale spełniały jeszcze jedną funkcję: każdy problem napotkany przez zespół produkcyjny mógł wrócić do ludzi rozwijających RenderWare. Criterion nie musiało więc zgadywać, czego potrzebuje twórca gry. Miało takich twórców piętro obok. Równocześnie Sony szykowało grunt pod interesy, na których Criterion miało zarobić. We wrześniu 1999 roku, pół roku przed japońską premierą PS2, SCEI uruchomiło osobny program licencyjny dla producentów narzędzi i middleware'u. Firmy zewnętrzne miały otrzymywać środowisko oraz dokumentację techniczną na takich samych zasadach jak twórcy gier, a następnie swobodnie sprzedawać swoje rozwiązania studiom. Trudna w okiełznaniu konsola dostała więc oficjalnie pobłogosławiony silnik, zanim sprzęt trafił w ogóle do sklepów.
Momentem, w którym RenderWare przestało być zwykłą biblioteką graficzną, była premiera RenderWare 3 pod koniec 1999 roku. Nowa wersja obejmowała już znacznie większą część procesu produkcji: wspólną warstwę renderowania, eksportery zasobów oraz zestaw modułowych bibliotek, które studio mogło rozbudowywać pod potrzeby własnej gry. Criterion równolegle pracowało nad pierwszym Burnoutem, dlatego technologia była sprawdzana podczas rzeczywistej produkcji, a nie wyłącznie na pokazowych demach. Kilka miesięcy później zadebiutowało PlayStation 2 i szybko okazało się, jak dużą wartość ma gotowy fundament pozwalający ominąć przynajmniej część walki z nietypową architekturą konsoli. RenderWare rosło jednak w siłę jeszcze zanim GTA III zrobiło z niego jeden z symboli generacji. W marcu 2001 roku Criterion informowało, że od grudnia 1999 roku licencję wykupiło ponad 250 studiów, a przeszło sto wykorzystujących ją gier znajdowało się już w produkcji. Wśród klientów byli Activision, DMA Design, Interplay, Konami, THQ i Ubisoft. Rockstar nie zapoczątkował więc popularności RenderWare. Pokazał za to całej branży, jak wiele można zbudować na jego fundamencie.
PS2, jak pisałem już wcześniej, nie było zwykłym komputerem zamkniętym w czarnej obudowie. Emotion Engine łączył główny rdzeń MIPS z jednostkami VU0 i VU1, dane należało sprawnie przesyłać przez kontrolery DMA, a Graphics Synthesizer oferował zaledwie 4 MB bardzo szybkiej pamięci eDRAM. Cała konsola miała 32 MB pamięci głównej. Sprzęt potrafił przerzucać ogromne ilości geometrii i pikseli, lecz wymagał od programistów starannego dzielenia pracy, układania transferów oraz przygotowywania danych w formie, którą poszczególne układy mogły błyskawicznie połknąć. Teoretyczne możliwości były imponujące. Droga do nich przypominała natomiast instrukcję obsługi elektrowni napisaną przez studenta medycyny.
Znaczenie RenderWare najlepiej widać wtedy, gdy zestawimy ze sobą platformy, na których miało działać. PlayStation 2, Dreamcast, PC, Xbox i GameCube różniły się architekturą, sposobem zarządzania pamięcią oraz metodami przesyłania danych do układu graficznego. Criterion przygotowało dla każdej z nich osobną warstwę sprzętową, ale ponad nią zachowało wspólne API, formaty plików i narzędzia. Studio nadal musiało optymalizować grę pod konkretną konsolę, nie zaczynało jednak każdej wersji od pisania renderera, eksporterów i całego potoku obróbki zasobów od zera. W 2001 roku Criterion przekonywało, że wykorzystanie RenderWare może skrócić produkcję typowej gry nawet o sześć miesięcy. Była to deklaracja firmy sprzedającej własną technologię, więc należało ją wówczas traktować z odpowiednim dystansem. Dobrze pokazuje jednak, za co płacili klienci. Kupowali gotowy zestaw rozwiązań pozwalający szybciej rozpocząć właściwą pracę nad grą.
Ciekawy ślad tej wieloplatformowej konstrukcji zachował się w ewaluacyjnym wydaniu RenderWare SDK 3.5. W plikach kompilacyjnych wersję przeznaczoną dla PlayStation 2 oznaczano nazwą sky2. Projekt korzystał również z biblioteki rppds, zawierającej Pipeline Delivery System, czyli mechanizm pozwalający przypisywać obiektom odpowiednie potoki renderowania przygotowane dla sprzętu Sony. sky2 nie było żadną marketingową nazwą ani tajnym kryptonimem konsoli. Stanowiło wewnętrzne oznaczenie platformy, dzięki któremu narzędzia wiedziały, dla jakiego urządzenia mają przygotować kod oraz dane.
Niestety RenderWare nie robiło gry za twórców
W tym miejscu muszę dodać, że obecność logo RenderWare nie oznaczała, że wszystkie korzystające z niego gry powstawały w tym samym edytorze i z gotowych elementów. GTA III, Burnout 3, Bully oraz Persona 4 nie były różnymi wariantami jednego projektu. Łączyła je część technologicznego zaplecza, ale całą resztę - zasady rozgrywki, fizykę, sztuczną inteligencję, streaming, system misji czy zachowanie świata - poszczególne studia tworzyły samodzielnie.
RenderWare przez większość epoki PlayStation 2 pozostawało przede wszystkim middleware’em. Był to zestaw bibliotek, formatów danych, eksporterów i rozwiązań pozwalających przygotować oraz wyświetlić trójwymiarowy świat na różnych platformach. Studio otrzymywało działający renderer, sposób organizowania sceny oraz narzędzia do obróbki zasobów. Nie była to natomiast gotowa gry, którą wystarczyło wypełnić modelami i dialogami. Sercem całego pakietu było RenderWare Graphics. W 2001 roku Criterion włączyło je do szerszego RenderWare Platform, łączącego rozwiązania graficzne, dźwiękowe oraz wczesny zestaw modułów fizycznych. Dwa lata później firma przejęła od MathEngine własność intelektualną związaną z fizyką, w tym technologię Karma. Na jej podstawie przygotowano nowe RenderWare Physics, zaprezentowane w grudniu 2003 roku i obsługujące między innymi bryły sztywne oraz animację ragdoll.
Moduł fizyczny można było kupić osobno albo dołączyć do całego pakietu. Nie należy jednak wyciągać z tego wniosku, że wcześniejsze gry korzystające z RenderWare automatycznie dzieliły ten sam model fizyki. Burnout posiadał autorski system jazdy i zderzeń, natomiast Rockstar samodzielnie rozwijał ruch postaci, zachowanie pojazdów, skrypty misji oraz streaming świata. RenderWare zapewniało wspólną warstwę technologiczną, ale to studio decydowało, ile z niej wykorzysta i co zbuduje ponad nią. Sama scena była organizowana według jasno określonej hierarchii. RwCamera opisywała kamerę i miejsce, z którego oglądaliśmy świat. RpWorld przechowywał otoczenie podzielone na mniejsze sektory, dzięki czemu silnik nie musiał za każdym razem przetwarzać całej mapy. Z kolei RpClump pełnił funkcję kontenera grupującego elementy jednego obiektu - przykładowo model samochodu albo postaci.
Widoczne części takiego obiektu funkcjonowały jako RpAtomic. Każda z nich łączyła konkretną geometrię z informacją o jej położeniu w świecie i mogła zostać osobno przesunięta, ukryta albo wysłana do renderowania. Niżej znajdowały się materiały, tekstury, rastry oraz klatki transformacji. Brzmi to jak zestaw terminów przygotowanych specjalnie po to, żeby odstraszyć człowieka od dokumentacji, lecz zasada była prosta: duży świat rozbijano na mniejsze elementy, którymi silnik mógł sprawnie zarządzać. Nazwy również nie były przypadkowe. Prefiks Rw odnosił się zazwyczaj do podstawowych elementów rdzenia RenderWare, Rp oznaczał obiekty i moduły pracujące na wyższym poziomie, natomiast Rt prowadził do dodatkowych narzędzi. Dlatego w dokumentacji pojawiały się takie nazwy jak RwCamera, RpWorld czy RtAnim. Przy interfejsie rozwijanym przez wiele lat konsekwentne nazewnictwo pozwalało programistom szybciej zorientować się, z jaką częścią technologii mają do czynienia.
Podobną logikę zastosowano przy zapisywaniu danych. RenderWare dzieliło pliki na mniejsze bloki nazywane chunkami. Nagłówek każdego z nich zawierał typ danych, rozmiar bloku oraz wersję biblioteki, która go utworzyła. Silnik wiedział dzięki temu, ile informacji powinien odczytać, gdzie rozpoczyna się następny fragment i czy obsługuje zapisany format. Taka konstrukcja pozwalała również rozszerzać obiekty bez przebudowywania całego pliku. Do modelu można było dołączyć dane animacji, skinningu, kolizji albo efektów wybranego materiału, a starsza część formatu pozostawała nienaruszona. Z tego systemu wywodzą się pliki świetnie znane osobom modyfikującym klasyczne odsłony GTA: modele DFF, słowniki tekstur TXD oraz dane świata BSP. RenderWare przechowywało zasoby w sposób na tyle uporządkowany, że po latach modderzy mogli rozłożyć je na części i stosunkowo dokładnie odtworzyć ich budowę.
Ogromne znaczenie miała również droga, którą model pokonywał od komputera grafika do działającej gry. Criterion dostarczało eksportery dla 3ds Maxa i Mayi, wizualizatory, narzędzia do budowania danych oraz środowisko RenderWare Studio. Artysta mógł przygotować obiekt, wyeksportować go w odpowiednim formacie, sprawdzić materiały i animację, a następnie szybko zobaczyć rezultat na docelowej konsoli. Nie musiał po każdej zmianie prosić programisty o ręczne przetworzenie plików i przygotowanie nowej wersji gry.
Dzisiaj taka pętla pracy wydaje się czymś oczywistym. Na początku XXI wieku jej skrócenie potrafiło jednak zdecydować, czy ostatnie miesiące produkcji zostaną przeznaczone na poprawianie animacji i wyglądu poziomów, czy na walkę z narzędziami, które po raz kolejny odmówiły współpracy. Możliwości RenderWare Studio dobrze pokazała japońska prezentacja z 2004 roku. Komputer deweloperski połączono z PlayStation 2, a zmiany wykonywane w edytorze były niemal natychmiast widoczne na konsoli. Podczas demonstracji ustawiono na planszy rampę, przypisano jej kod obsługujący kolizję i zmieniono współczynnik tarcia. Rezultat można było od razu sprawdzić w działającej grze, bez wielogodzinnego przygotowywania kolejnego buildu.
Za taką wygodę trzeba było jednak sporo zapłacić. Japońska licencja RenderWare Studio przeznaczona dla jednego projektu kosztowała 28 mln jenów, czyli według ówczesnych kursów około 265 tys. dolarów lub nieco ponad milion złotych, a w pierwszym roku Criterion planowało sprzedać zaledwie dziesięć licencji, aby każdemu klientowi zapewnić odpowiednie wsparcie. Firma szacowała, że przy 16-miesięcznej produkcji z budżetem wynoszącym 200 mln jenów wykorzystanie pakietu mogło przynieść ponad 70 mln jenów oszczędności. Były to wyliczenia producenta, więc trudno traktować je jak uniwersalny wzór, ale dobrze pokazują skalę problemu. RenderWare miało być drogie, ponieważ samodzielne przygotowanie podobnego zestawu narzędzi potrafiło kosztować jeszcze więcej. Najbardziej techniczna część całego systemu uruchamiała się w chwili, gdy przygotowane obiekty należało wyświetlić na ekranie. RenderWare pozwalało przypisać im odpowiednie potoki renderowania, czyli zestawy kolejnych operacji wykonywanych na geometrii. Nie były to jeszcze shadery znane ze współczesnych silników. Potok określał raczej, jak przygotować model, przeprowadzić animację szkieletową, obliczyć oświetlenie i przekazać wynik do konkretnego układu graficznego.
Na PlayStation 2 część tych zadań mogły wykonywać jednostki wektorowe Emotion Engine. RenderWare przygotowywało geometrię, przekształcało położenie wierzchołków, nakładało animację postaci i obliczało potrzebne informacje o oświetleniu. Następnie dane pakowano w porcje przesyłane przez mechanizmy VIF oraz DMA, a interfejs GIF kierował gotowe polecenia do Graphics Synthesizera. Dopiero tam powstawały piksele trafiające do pamięci obrazu. Napisanie całej tej ścieżki od zera wymagało świetnej znajomości architektury PS2 oraz wielu miesięcy pracy. RenderWare dostarczało działający wariant początkowy, który pozwalał znacznie szybciej wyświetlić pierwszą scenę. Mniej doświadczone studio mogło pozostać przy gotowych rozwiązaniach Criterion. Najlepsi programiści wymieniali poszczególne elementy potoku, rozszerzali je i dostosowywali do potrzeb własnej gry. Właśnie dlatego dwa tytuły korzystające z RenderWare mogły wyglądać oraz działać zupełnie inaczej.
W dużym uproszczeniu pojedyncza klatka obrazu powstawała w kilku następujących po sobie etapach:
- RenderWare sprawdzało położenie kamery i ustalało, które sektory świata mogą znaleźć się w polu widzenia gracza.
- Obiekty pozostające poza kadrem były odrzucane, zanim konsola zmarnowała na nie czas. Pozostałe elementy grupowano według materiałów, tekstur i używanych efektów.
- Odpowiedni potok renderowania przygotowywał geometrię. Przeliczał położenie wierzchołków, animację szkieletową, oświetlenie oraz współrzędne tekstur.
- Na PlayStation 2 część tych operacji mogły przejmować jednostki wektorowe. Gotowe dane przesyłano następnie przez DMA, VIF i GIF do Graphics Synthesizera.
- Graphics Synthesizer rasteryzował obraz, korzystając ze swoich 4 MB szybkiej pamięci eDRAM. W tej niewielkiej przestrzeni trzeba było zmieścić bufory obrazu, bufor głębokości oraz zasoby potrzebne do narysowania danej sceny.
- W tym samym czasie pozostałe układy przygotowywały już następną porcję geometrii. Na PS2 największą sztuką nie było bowiem samo wykonywanie obliczeń, lecz takie ułożenie pracy, aby żaden element konsoli nie czekał bezczynnie na pozostałe.
Nie był to oczywiście jeden sztywny schemat obowiązujący we wszystkich grach. RenderWare zapewniało gotowy punkt wyjścia, ale zespoły mogły wymieniać poszczególne potoki, dopisywać własne rozwiązania i inaczej rozkładać obciążenie. Dlatego Rockstar wykorzystywał tę technologię do podtrzymywania otwartego miasta, a Criterion – do wyświetlania ruchliwej autostrady z prędkością 60 klatek na sekundę.
Criterion rozwijało ten fundament przez całą generację. Nie chodziło przy tym o jedną aktualizację, która nagle zmieniła wszystko, lecz o regularne usuwanie ograniczeń napotykanych przez kolejne studia. Każda wersja dodawała narzędzia pozwalające przygotować bardziej skomplikowaną scenę, szybciej przenieść ją na konsolę albo sprawniej wykorzystać jej podzespoły. RenderWare 3.3 rozszerzyło pakiet między innymi o system cząsteczek, narzędzia do tworzenia lightmap, edytor sektorów oraz obsługę PVS. Skrót ten oznaczał listę obszarów potencjalnie widocznych z określonego miejsca. Zamiast za każdym razem sprawdzać cały poziom, silnik mógł sięgnąć do wcześniej przygotowanych informacji i skupić się na tej części świata, którą gracz rzeczywiście miał szansę zobaczyć.
Wydanie 3.4 z 2002 roku przebudowało system eksporterów, rozwinęło narzędzia animacyjne i ułatwiło obsługę bardziej złożonych modeli szkieletowych. Ważną nowością był również Pipeline Delivery System, w ramach którego Criterion dostarczało potoki G3x przygotowane specjalnie dla PlayStation 2. Studio otrzymywało więc nie tylko wspólny interfejs RenderWare, lecz także działającą ścieżkę wykorzystującą specyficzne możliwości konsoli Sony. Dojrzała gałąź 3.7 rozwijała tę konstrukcję dalej. Usprawniono potoki VCL, asynchroniczne wczytywanie danych, zarządzanie zasobami, efekty materiałowe oraz narzędzia przeznaczone dla grafików. Dla gracza były to zwykle zmiany niewidoczne. Dla zespołu mogły oznaczać krótsze doczytywanie, sprawniejszy eksport modeli albo kilka dodatkowych milisekund, które dało się przeznaczyć na bogatszą scenę.
Szczególnie ważne pozostawało zarządzanie widocznością. Najbardziej bezużyteczny trójkąt to ten, którego gracz nigdy nie zobaczy, a który konsola mimo wszystko musi przeliczyć. RenderWare dzieliło więc świat na sektory, odrzucało obiekty znajdujące się poza polem widzenia kamery i pozwalało korzystać z mechanizmów PVS. Criterion rozwijało również dPVS - komercyjny system dynamicznego ustalania widoczności, przygotowany wspólnie z firmą Hybrid Graphics. W zamkniętym korytarzu można było pominąć pomieszczenia zasłonięte ścianami. Na miejskiej ulicy nie było sensu przetwarzać budynków znajdujących się daleko za kamerą. Każdy obiekt zatrzymany przed wysłaniem do renderowania zostawiał trochę mocy dla samochodów, przechodniów, cząsteczek, animacji albo większej eksplozji.
RenderWare nie usuwało jednak różnic pomiędzy platformami. PlayStation 2 opierało znaczną część swojej wydajności na jednostkach wektorowych i precyzyjnie zaplanowanych transferach danych. Xbox oferował bardziej klasyczną architekturę oraz programowalne shadery, natomiast GameCube posiadał własny układ graficzny i zupełnie inaczej zorganizowaną pamięć. Przenoszenie gry nadal wymagało więc pracy. RenderWare zapewniało wspólne formaty danych, API, eksportery i sposób organizowania projektu, ale pod tą warstwą działały osobne rozwiązania przygotowane dla każdego urządzenia. Model postaci mógł pochodzić z tego samego pliku, lecz droga prowadząca od tego pliku do gotowego obrazu wyglądała inaczej na PS2, Xboksie i GameCubie. Mniejsze lub mniej doświadczone studio mogło oprzeć się na gotowych potokach Criterion i dzięki temu szybciej uruchomić grę na kilku platformach. Najlepsze zespoły traktowały je jako punkt startu: analizowały, przebudowywały i stroiły pod potrzeby konkretnego projektu. RenderWare skracało drogę do działającej wersji, ale nie zwalniało programistów z optymalizacji.
Ambicje Criterion sięgały zresztą znacznie dalej niż cztery najważniejsze platformy stacjonarne. W 2004 roku firma zapowiedziała pełny zestaw narzędzi dla PSP, a jednocześnie zawarła długoterminową umowę z Nokią dotyczącą obsługi N-Gage’a. Akademicka wersja pakietu z 2005 roku wymieniała już PS2, Xboksa, GameCube’a, PC oraz właśnie telefon Nokii. Pomysł był prosty: zespół miał korzystać z podobnego procesu produkcji niezależnie od tego, czy przygotowywał grę na konsolę pod telewizorem, przenośne PSP, czy telefon z pionowym ekranem. Sprzęt nadal wymagał osobnych optymalizacji, lecz twórcy nie musieli za każdym razem zmieniać całego sposobu budowania projektu. Właśnie dlatego dwie gry korzystające z RenderWare mogły dzielić podstawowe struktury, formaty oraz narzędzia, a jednocześnie wyglądać tak, jakby dzieliła je cała generacja. Technologia określała punkt wyjścia. O tym, gdzie znajdowała się meta, decydowały już doświadczenie zespołu, czas produkcji i liczba rzeczy, które programiści byli gotowi napisać po swojemu.
GTA budowało miasto, a Burnout podpalał asfalt
Rockstar zrobił dla popularności RenderWare więcej niż wszystkie prezentacje Criterion razem wzięte. Kiedy w 2001 roku Grand Theft Auto III trafiło na PlayStation 2, logo brytyjskiej technologii przestało oznaczać kolejną bibliotekę graficzną. Nagle stało przed grą, która pozwalała wyjść na ulicę, ukraść samochód i pojechać w dowolnym kierunku, nie oglądając po drodze ani jednego ekranu ładowania. Nie znaczy to, że Criterion dostarczyło Rockstarowi gotowe Liberty City. RenderWare obsługiwało rysowanie świata, modele, materiały, tekstury i znaczną część komunikacji ze sprzętem, ale ruch uliczny, przechodnie, misje, skrypty oraz cała logika otwartego miasta powstawały już w DMA Design. Największym problemem nie było zresztą samo narysowanie miasta. Trzeba było jeszcze zmieścić je w konsoli mającej 32 MB pamięci.
Cała mapa nie miała najmniejszych szans znaleźć się w RAM-ie jednocześnie. Gra musiała więc przez cały czas utrzymywać wokół Claude’a niewielki, przesuwający się fragment Liberty City i zachowywać się tak, jakby za następnym skrzyżowaniem rzeczywiście czekała dalsza część metropolii. Budynki, tekstury, samochody, piesi, dźwięki, muzyka oraz skrypty pojawiały się w pamięci wtedy, gdy były potrzebne. Chwilę później znikały, robiąc miejsce kolejnym. Za ten system odpowiadał Adam Fowler. Obbe Vermeij, ówczesny dyrektor techniczny projektu, nazwał po latach streaming najtrudniejszym wyzwaniem całej produkcji. RenderWare zapewniało formaty zasobów i struktury, na których można było pracować, ale to Fowler napisał mechanizm nieustannie decydujący, co należy pobrać z płyty, co pozostawić w pamięci, a czego gracz przez najbliższe sekundy raczej nie zobaczy.
Samo zwolnienie miejsca nie wystarczało. Po setkach operacji ładowania i usuwania danych pamięć zaczynała przypominać podziurawiony ser: wolnej przestrzeni mogło być łącznie całkiem sporo, lecz pozostawała rozrzucona pomiędzy zajętymi blokami. Kolejny duży model nie miał się gdzie zmieścić, mimo że teoretycznie dostępnych bajtów było wystarczająco dużo. Kod Fowlera stale przesuwał więc przechowywane zasoby i scalał niewielkie szczeliny w większe obszary. Musiał przy tym uważać na modele, które w tej samej chwili mogły zostać wysłane do renderowania. Dzisiaj podobny problem najłatwiej przykryć kolejnymi gigabajtami pamięci. PlayStation 2 miało dokładnie tyle, ile wlutowano w płytę główną, więc defragmentację trzeba było wykonywać podczas działania gry i liczyć, że gracz niczego nie zauważy.
Czasami jednak zauważał. W pamięci mieściło się jednocześnie tylko około siedmiu spośród mniej więcej 80 modeli pojazdów. Na papierze powinno to wystarczyć do stworzenia przyzwoicie zróżnicowanego ruchu, ale część miejsc potrafiła zostać zarezerwowana z góry. Misja wymagała konkretnego samochodu, policja potrzebowała radiowozu, ranni przechodnie wymuszali załadowanie karetki, a wysoki poziom pościgu dorzucał samochód FBI, furgonetkę SWAT i śmigłowiec. Dla zwykłych mieszkańców Liberty City zostawały niekiedy dwa modele. Stąd sznury identycznych aut pojawiających się jedno za drugim. Nie był to błąd generatora ruchu, tylko widoczny ślad walki o każdy wolny fragment pamięci. Pod spodem trwał jeszcze drugi wyścig: gracz kontra napęd optyczny. Fowler rozmieszczał dane na płycie w taki sposób, aby modele stojące blisko siebie w mieście leżały również możliwie blisko siebie na nośniku. Eksperymentował nawet z powielaniem najczęściej używanych plików, ponieważ czasami bardziej opłacało się zapisać ten sam zasób ponownie, niż czekać, aż głowica napędu dotrze do jego jedynej kopii.
Nawet to nie zawsze wystarczało. Jeżeli Claude poruszał się zbyt szybko, szczegółowe modele budynków nie zdążyły się pojawić, a w skrajnych sytuacjach przed samochodem brakowało kawałka drogi. Skoro streamingu nie dało się już przyspieszyć, należało spowolnić gracza. W Portland przebudowano więc fragment układu ulic, aby przerwać długą prostą i zmusić kierowcę do wykonania objazdu. W innych problematycznych strefach zwiększano opór pojazdów o kilka procent. Zmiana była zbyt mała, by zwrócić uwagę gracza, ale dawała napędowi dodatkowy ułamek sekundy. Budynek stojący na końcu ulicy mógł zatem pełnić dwie funkcje: wyglądać jak część Liberty City i powstrzymywać gracza przed dojechaniem tam, gdzie miasta jeszcze nie zdążono wczytać.
Z tego samego powodu GTA III nie pozwalało swobodnie latać nad mapą. Samolot poruszałby się szybciej od samochodów, a jednocześnie odsłaniał znacznie większy obszar miasta. Dla systemu, który z trudem nadążał za pojazdem pędzącym przez Portland, sprawna maszyna latająca byłaby właściwie kodem na zepsucie streamingu. Pokraczne Dodo pozostawało wyjątkiem - teoretycznie wznosiło się w powietrze, ale zwykle większym osiągnięciem było utrzymanie go tam przez dłuższą chwilę. Przy Vice City Rockstar nie wymyślał wszystkiego ponownie. Zamiast tego przez kolejny rok poprawiał rozwiązania, które ledwo udało się doprowadzić do porządku w GTA III. Modele i tekstury otrzymały lepszą kompresję, a szczegółowe wersje budynków nie były ładowane w czasie lotu, gdy gracz oglądał miasto z większej wysokości i nie potrzebował każdego detalu elewacji. Dzięki temu pojawiły się helikoptery, samoloty i znacznie bardziej kolorowa mapa, choć sprzęt pozostał dokładnie ten sam.
San Andreas było już pokazem tego, ile można osiągnąć po kilku latach nieustannego poprawiania jednego systemu. Trzy miasta, pustynia, lasy, tereny wiejskie, samoloty, pociągi, wnętrza, zmienna pogoda, rozbudowane animacje CJ-a i mechanika wpływająca na jego sylwetkę nadal musiały zmieścić się w tych samych 32 MB. Przewaga Rockstara nie polegała już wyłącznie na dostępie do RenderWare. Studio znało tę technologię, jej ograniczenia i własne rozszerzenia na tyle dobrze, że mogło zwiększać skalę gry bez burzenia fundamentów przy każdej kolejnej części. W tym samym 2004 roku Criterion pokazało zupełnie inne wykorzystanie tej technologii. Rockstar miejscami spowalniał samochody, aby napęd zdążył doczytać miasto. Burnout 3: Takedown robił wszystko, aby gracz ani przez chwilę nie zdejmował nogi z gazu.
Tutaj nie trzeba było utrzymywać iluzji całej metropolii. Silnik miał wyświetlić fragment trasy, gęsty ruch, samochody rywali, odbicia na karoserii oraz efekty prędkości, a potem poprawnie rozliczyć kolizję następującą przy kilkuset kilometrach na godzinę. Nawet krótkie opóźnienie reakcji byłoby wyczuwalne, dlatego podczas wyścigów Criterion uparcie celowało w 60 klatek na sekundę. Jedna klatka trwała wówczas około 16,7 milisekundy. Kiedy dochodziło do rozbudowanej kraksy, gra przełączała się na 30 FPS, otrzymując dwukrotnie więcej czasu na przygotowanie obrazu. Dodatkowy budżet wykorzystywano na większą liczbę odłamków, cząsteczek i elementów rozbitego samochodu. Spadek płynności nie wyglądał przy tym jak techniczna zadyszka, ponieważ sekwencja zderzenia i tak przechodziła w zwolnione tempo. Gracz dostawał bardziej widowiskową katastrofę dokładnie w momencie, w którym niższa liczba klatek przeszkadzała najmniej.
Tryb Crash skrywał jeszcze lepszą sztuczkę. Model jazdy stale dociskał samochody do nawierzchni, aby przy ogromnej prędkości nie podskakiwały na każdej nierówności. Rozwiązanie świetnie sprawdzało się podczas wyścigu, ale kompletnie psuło rampy ustawione na skrzyżowaniach. Samochód zamiast przelecieć nad ruchem natychmiast nurkował w stronę asfaltu. Criterion nie przebudowało z tego powodu całego modelu jazdy. W chwili najazdu na rampę gra technicznie „zabijała” samochód i zamieniała go we wrak, którego nie obowiązywały już reguły utrzymujące pojazd na jezdni. Dopiero wtedy mógł swobodnie polecieć nad skrzyżowaniem i wpaść w rząd ciężarówek. W Burnoucie 3 samochód dostawał więc pozwolenie na lot dopiero wtedy, gdy z punktu widzenia kodu przestawał być samochodem. Usprawniony renderer miał działać - zależnie od sceny - od 50 do 100% szybciej niż rozwiązanie zastosowane w Burnoucie 2. Criterion przeznaczyło odzyskaną wydajność na bogatsze oświetlenie, lepsze mapowanie środowiskowe karoserii, gęstszy ruch oraz efekty wzmacniające poczucie prędkości. Gra miała pozostać czytelna wtedy, gdy pobocze zamieniało się w kolorową smugę, a przed maską właśnie wyrastała ciężarówka.
Dwa lata później Criterion przeniosło podobną filozofię do strzelanki Black. Tym razem technologia nie musiała obsługiwać rozległego miasta ani samochodów pędzących przez ruchliwe skrzyżowania. Poziomy były stosunkowo liniowe, więc większą część dostępnej mocy można było przeznaczyć na to, co gracz oglądał niemal bez przerwy: broń oraz skutki naciskania spustu. Każdy strzał składał się z błysku wylotowego, dymu, huku, wyrzuconej łuski, śladu po pocisku, chmury pyłu i reakcji trafionego obiektu. Podczas przeładowania, otoczenie rozmywało się, a broń pozostawała ostra, jakby operator kamery celowo przenosił na nią uwagę. W przypadku części karabinów Criterion umieściło nawet wyrzut łusek po niewłaściwej stronie modelu. Realna broń posyłałaby je poza ekran, tymczasem w Black miały przeciąć pole widzenia gracza, bo tak wyglądało to efektowniej.
Otoczenie nie rozpadało się według jednej, całkowicie dynamicznej symulacji. Zniszczenia były wybierane, przygotowywane i starannie ustawiane przez projektantów. W praktyce wystarczało umieścić przeciwnika przed kruchą osłoną, beczką, oknem albo fragmentem muru. Nawet niecelna seria wywoływała wtedy jakąś reakcję, a ekran szybko wypełniał się kurzem i odłamkami. Black nie symulowało całego świata. Reżyserowało każdą kulę tak, aby gracz uwierzył, że właśnie rozstrzeliwuje pół budynku. Później na tej samej konsoli pojawiła się jeszcze Persona 4. Bez pędzących samochodów, bez latających wraków i bez ścian zasypywanych pociskami. RenderWare spokojnie obsługiwało szkolne korytarze, niewielką Inabę, trójwymiarowe postacie oraz lochy, podczas gdy Atlus budował na tym wielomiesięczną opowieść o grupie nastolatków.
RenderWare zmieniło zasady gry
Na początku 2004 roku Criterion informowało, że RenderWare zasila ponad 500 wydanych lub powstających gier. Rok później tę samą liczbę powtarzało już wspólnie z Electronic Arts. Obejmowała różne platformy, wersje technologii oraz projekty znajdujące się dopiero w produkcji, więc nie należy traktować jej jak wyniku niezależnego audytu. Nawet po odjęciu marketingowej waty skala pozostaje jednak trudna do zignorowania. W szóstej generacji żadne inne komercyjne middleware nie było obecne w tylu studiach, gatunkach i seriach jednocześnie.
Właśnie wtedy, gdy RenderWare znajdowało się na szczycie, Electronic Arts postanowiło kupić jego twórców. Porozumienie z Canon Europe ogłoszono 28 lipca 2004 roku, a transakcję sfinalizowano 19 października. Z późniejszego sprawozdania EA wynika, że łączna cena zakupu, wraz z kosztami transakcyjnymi i przejętymi opcjami na akcje, wyniosła około 68 mln dolarów. Za tę kwotę wydawca otrzymał studio Criterion, markę Burnout, powstające Black oraz technologię wykorzystywaną przez setki zespołów – w tym firmy bezpośrednio konkurujące z Electronic Arts. Na papierze wyglądało to jak znakomity interes. EA nie kupiło jednego zespołu produkującego dobre gry wyścigowe. Przejęło kawałek zaplecza technologicznego całej branży. Firma zapewniała, że RenderWare nadal będzie dostępne dla zewnętrznych klientów. Tyle że przy wyborze silnika nikt nie płaci wyłącznie za paczkę bibliotek znajdującą się na dzisiejszej płycie instalacyjnej. Studio rozpoczynające kilkuletni projekt musi wierzyć, że za dwa lub trzy lata otrzyma aktualizacje, dokumentację, pomoc techniczną oraz obsługę nowych platform. Po przejęciu Criterion przyszłość tego wszystkiego zależała od jednego z największych wydawców na rynku.
Dla konkurencji oznaczało to spory problem. Miała budować swoją kolejną grę na technologii należącej do firmy, która w tym samym czasie mogła przygotowywać rywalizujący tytuł, ustalać własne priorytety i jako pierwsza skorzystać z pracy zespołu odpowiedzialnego za rozwój narzędzi. EA nie musiało nikomu odbierać licencji. Wystarczyło, że wcześniejsze poczucie neutralności zaczęło znikać. Jednocześnie nadchodziła generacja PlayStation 3 i Xboksa 360. RenderWare 4 miało połączyć rozwiązania Criterion z wewnętrznym zapleczem EA oraz zostać fundamentem produkcji przygotowywanych na nowe konsole. Nie było jednak kolejną, ostrożnie rozwijaną wersją dojrzałej gałęzi 3.7. Powstawał właściwie nowy system, który trzeba było uruchomić na nieukończonym sprzęcie, dopasować do zmieniających się bibliotek platformowych i równocześnie wdrażać w prawdziwych projektach.
Najlepiej przekonało się o tym Realtime Worlds podczas produkcji Crackdown. Studio korzystało wcześniej z RenderWare 3.7, lecz po przejściu projektu z pierwszego Xboksa na Xboksa 360 znalazło się w sytuacji, w której starsza wersja nie miała już otrzymać potrzebnego wsparcia. W styczniu 2005 roku zespół przeniósł więc grę na wczesne RenderWare 4. Producent Phil Wilson nazwał później tę decyzję „poważnym błędem”. Nowa wersja nie posiadała części funkcji, na których wcześniej polegali programiści. Dokumentacja bywała niepełna albo niezgodna z aktualnym kodem, kolejne wydania przynosiły nowe błędy, a aktualizacje wymagane przez zmieniające się oprogramowanie Xboksa 360 nie zachowywały kompatybilności ze starszymi kompilacjami. Zespół zamiast tworzyć grę coraz częściej sprawdzał, co tym razem przestało działać.
Osobnym problemem pozostawało RenderWare Studio. Wraz ze wzrostem projektu narzędzia uruchamiały się coraz dłużej, synchronizacja danych z kodem stawała się coraz bardziej ryzykowna, a przetestowanie pojedynczego poprawionego zasobu potrafiło zająć ponad godzinę. Artyści oraz projektanci zaczęli więc sprawdzać zmiany rzadziej, co odbijało się nie tylko na tempie pracy, lecz również na jakości gry. Po przejęciu Criterion przez EA wcześniejsze wsparcie świadczone bezpośrednio w studiu stopniowo osłabło, chociaż Wilson zaznaczał, że problemy z RenderWare zaczęły się jeszcze przed transakcją. Realtime Worlds ostatecznie przestało przyjmować kolejne aktualizacje, ustabilizowało posiadaną wersję i zaczęło przebudowywać ją na własną rękę. Middleware wybrane po to, aby ograniczyć ryzyko i skrócić produkcję, stało się jednym z największych problemów całego projektu.
Podobne wątpliwości pojawiały się w innych firmach. Square Enix rozważało RenderWare jako technologię dla powstających gier nowej generacji, ale po przejęciu Criterion zaczęło obawiać się o jego długoterminowe wsparcie. Japończycy skierowali uwagę na rozwiązanie firmy Epic i ostatecznie wykorzystali Unreal Engine 3 przy produkcji The Last Remnant. Rockstar nie zamierzał dłużej opierać swoich najważniejszych projektów na cudzej platformie i rozwijał własny silnik RAGE. Najmocniejszy sygnał nadszedł jednak z samego Electronic Arts. W sierpniu 2006 roku, niespełna dwa lata po zakupie Criterion, wydawca wykupił licencję na Unreal Engine 3 dla kilku przygotowywanych gier. Bing Gordon z EA przyznał później, że RenderWare nie otrzymało na czas elementów potrzebnych do produkcji nowej generacji. Firma nie doceniła tempa pracy Epic, przeceniła możliwości własnego zespołu i zbyt długo kazała części swoich studiów czekać na rozwiązania, które wciąż nie były gotowe.
RenderWare nie zniknęło natychmiast. Pozostawało w ukończonych projektach, rozwijanych seriach oraz wewnętrznych narzędziach EA. Straciło jednak pozycję oczywistego wyboru dla studia rozpoczynającego kilkuletnią produkcję. Na PS2 jego przewagami były dojrzałość, szerokie wsparcie platform i ogromna liczba zespołów znających technologię. Przy przejściu na PS3 oraz Xboksa 360 wszystkie trzy zaczęły znikać równocześnie. RenderWare nie było przy tym najbardziej zaawansowanym silnikiem, jaki kiedykolwiek uruchomiono na PlayStation 2. Autorskie technologie Naughty Dog, Polyphony Digital, Sony Santa Monica czy Guerrilla mogły zostać znacznie dokładniej dopasowane do konkretnej gry i jednego rodzaju sprzętu. Powstawały jednak w zespołach dysponujących świetnymi programistami, bezpośrednim wsparciem producenta konsoli oraz czasem potrzebnym do rozpracowania jej architektury niemal od podstaw.
Criterion dawało studiu działający renderer, formaty danych, eksportery, narzędzia oraz gotową obsługę kilku platform. Dzięki temu pierwsze miesiące produkcji nie musiały upływać wyłącznie na ustalaniu, w jaki sposób przesłać geometrię do jednostek wektorowych PS2 albo przenieść te same zasoby na Xboksa i GameCube’a. RenderWare nie gwarantowało świetnej gry, ale pozwalało znacznie szybciej rozpocząć jej właściwą produkcję. Właśnie dlatego jego znaczenie najlepiej widać nie w jednym efekcie graficznym, lecz na półce z grami. Obok siebie mogły stać GTA III, Burnout 3, Black, Bully, The Warriors, Mortal Kombat: Shaolin Monks oraz Persona 4. Jedne potrzebowały streamingu ogromnego miasta, inne 60 klatek na sekundę, rozbudowanych animacji walki albo setek cząsteczek wyrzucanych przez serię z karabinu. Łączyło je logo pojawiające się przez kilka sekund podczas uruchamiania - i niewiele więcej, co gracz mógłby rozpoznać na pierwszy rzut oka. RenderWare miało wykonać całą pracę techniczną, a potem zejść z drogi i pozwolić studiu zrobić własną grę. Na PlayStation 2 żadne inne middleware nie robiło tego równie często.
Przeczytaj również
Komentarze (1)
SORTUJ OD: Najnowszych / Najstarszych / Popularnych