Cyfrowe Arcydzieła: Quake oferował kapitalny świat 3D bez akceleratora GPU. Jak ID Software to zrobiło?
Quake to strzelanka pierwszoosobowa stworzona przez id Software i udostępniona na PC 22 czerwca 1996 roku. Gracz kierował bezimiennym wówczas żołnierzem, którego późniejsze gry nazwały Rangerem. Ruszał przez teleporty Slipgate, żeby zatrzymać armię istoty określanej kryptonimem Quake. Kampanię podzielono na cztery epizody prowadzące przez skażone bazy wojskowe, średniowieczne fortece, zalane podziemia i miejsca, w których inspiracji prozą H.P. Lovecrafta nawet nie próbowano specjalnie ukrywać. Na końcu czekała przecież sama Shub-Niggurath. Poczytajcie, dlaczego Quake to techniczne arcydzieło.
Pod względem podstawowych zasad było to rozwinięcie pomysłów z Dooma. Nadal szukaliśmy kluczy, odkrywaliśmy sekrety, zbieraliśmy amunicję i strzelaliśmy do wszystkiego, co próbowało urwać nam głowę. Różnica tkwiła w konstrukcji świata. Pomieszczenia, mosty, schody, przeciwnicy, pociski i przedmioty naprawdę istniały w trzech wymiarach. Można było spojrzeć w górę, zanurkować, spaść z wysokiej platformy i znaleźć się w sali położonej bezpośrednio pod innym pomieszczeniem. Dzisiaj brzmi to banalnie, wręcz zwyczajnie. Ale w 1996 roku oznaczało przebudowanie niemal całej technologii wykorzystywanej przez id Software.
Co ważne, Quake nie był pierwszą pełnoprawną grą 3D. Wcześniej ukazały się między innymi „Descent”, „System Shock” i „The Terminator: Future Shock”, a poszczególne elementy tej rewolucji pojawiały się jeszcze wcześniej. Produkcja id Software połączyła jednak swobodną, trójwymiarową przestrzeń z szybkością Dooma, wielopoziomowymi mapami, przeciwnikami złożonymi z wielu wielokątów, precyzyjnym oświetleniem, fizyką działającą w trzech osiach, deathmatchem w modelu klient-serwer oraz konstrukcją otwartą na modyfikacje. Najbardziej absurdalne pozostaje to, że premierowa wersja wykonywała cały rendering programowo. Karta graficzna wyświetlała gotowe piksele, ale ich widoczność, położenie, tekstury i oświetlenie obliczał procesor.
Największym problemem było to, czego nie należało renderować
Żeby zrozumieć skalę przeskoku, musimy najpierw odwołać się do Dooma, wydanego 10 grudnia 1993 roku. Jego mapy były w istocie dwuwymiarowymi planami, na których poszczególnym sektorom przypisywano wysokość podłogi oraz sufitu. Ściany pozostawały pionowe, geometria nie pozwalała umieścić dwóch niezależnych pomieszczeń dokładnie jedno nad drugim, a przeciwników przedstawiano za pomocą płaskich obrazków obracanych w stronę gracza. Twórcy potrafili znakomicie maskować te ograniczenia, ale silnik nadal opisywał poziom przede wszystkim jako płaski układ linii i sektorów, któremu dopiero nadawano pozory przestrzenności.
John Carmack uznał tę konstrukcję za technologiczną ślepą uliczkę. Kolejny silnik id Software nie miał już udawać trzech wymiarów, lecz rzeczywiście opisywać położenie punktów, powierzchni i obiektów na osiach X, Y oraz Z. Nie chodziło więc wyłącznie o możliwość pochylenia ściany albo ustawienia jednego pokoju nad drugim. Pełne 3D zmieniało podstawowe reguły budowania świata: projektanci mogli tworzyć wielopoziomowe pomieszczenia, mosty, skosy i głębokie przepaście, gracz swobodnie patrzył w górę oraz w dół, a przeciwnicy stawali się trójwymiarowymi modelami, które można było obejść i oglądać z każdej strony.
Quake nie był pierwszą grą wykorzystującą pełną grafikę 3D. Wcześniej podobną swobodę oferowały między innymi „Descent”, „System Shock” oraz „The Terminator: Future Shock”. Wyjątkowe było coś innego: id Software połączyło trójwymiarową geometrię poziomów i postaci z tempem Dooma, rozbudowanym oświetleniem, fizyką pocisków, sieciowym deathmatchem oraz silnikiem otwartym na modyfikacje. Co więcej, premierowa wersja wykonywała wszystkie obliczenia graficzne na procesorze komputera, bez akceleratora 3D. Pełne 3D stało się fundamentem szybkiej strzelanki.
W stworzeniu takiego silnika Johnowi Carmackowi pomagał Michael Abrash (na zdjęciu wyżej), który dołączył do id Software w marcu 1995 roku. Był jednym z najbardziej cenionych specjalistów od optymalizacji kodu, asemblera i programowego renderowania grafiki na komputerach PC. Pracował wcześniej między innymi w Microsoft, pisał książki oraz artykuły techniczne, na których uczyli się młodsi programiści - wśród nich sam Carmack. W id Software pomagał rozwijać algorytmy renderera, przepisywał jego najważniejsze fragmenty w asemblerze i szukał sposobów na wykorzystanie niemal każdego cyklu procesora. Przytaczam w niniejszym tekście kilkukrotnie jego wypowiedzi, ponieważ pochodzą od człowieka bezpośrednio odpowiedzialnego za wydajność technologii Quake’a.
Abrash wyliczał, że duży poziom Quake'a zawierał około 10 tysięcy wielokątów, czyli jakoś trzy razy więcej niż porównywalna plansza w Doomie. Sama liczba powierzchni nie była jednak największym problemem. Gdyby program rysował wszystko po kolei, niektóre piksele mógłby obliczać dziesięć razy albo jeszcze częściej: najpierw dla odległej ściany, później dla stojącego przed nią filaru, następnie dla drzwi, a na końcu dla potwora zasłaniającego całą resztę. Procesor wykonywałby ogrom pracy tylko po to, aby większość gotowego obrazu natychmiast przykryć.
Rozwiązaniem nie było zmuszenie procesora, aby szybciej rysował wszystkie 10 tysięcy wielokątów. Carmack i Abrash sprawili, że podczas rozgrywki większość z nich w ogóle nie trafiała do renderera. Wiele kosztownych obliczeń wykonywano wcześniej, jeszcze na komputerze projektanta poziomu. Plik zapisany w edytorze nie był bowiem gotową planszą, lecz jej surowym projektem - czymś w rodzaju instrukcji opisującej, z jakich elementów należy zbudować świat. To było kluczem do uzyskania wysokiej wydajności na domowym PC.
Żeby ten pomysł zadziałał, id Software musiało zbudować nie tylko silnik uruchamiany na komputerze gracza, lecz także cały zestaw narzędzi służących do wcześniejszego przygotowywania poziomów. Mapa przechodziła proces przypominający kompilowanie programu: projektant określał jej kształt, rozmieszczenie pomieszczeń oraz źródeł światła, a osobne aplikacje przekształcały ten surowy projekt w dane możliwe do szybkiego wykorzystania podczas rozgrywki. Część pracy, którą procesor musiałby wykonywać od nowa przy każdej klatce obrazu, przeprowadzano więc tylko raz - podczas tworzenia mapy. Właśnie do tego służyły trzy najważniejsze narzędzia: QBSP, VIS oraz LIGHT. Na początku tego procesu projektanci poziomów tworzyli ściany, podłogi, schody i filary z prostych, pełnych brył nazywanych brushami. Następnie uruchamiali program QBSP, który przekształcał te klocki w powierzchnie możliwe do narysowania przez silnik, usuwał niewidoczne fragmenty ukryte wewnątrz konstrukcji i dzielił całą przestrzeń na mniejsze obszary.
Efektem była struktura BSP pozwalająca szybko ustalić, w którym miejscu planszy znajduje się gracz. Dopiero tak przygotowaną mapą zajmował się program VIS. Sprawdzał, które obszary mogą być widoczne z pozostałych części poziomu. Jeżeli z jednego korytarza nie dało się zobaczyć pomieszczenia znajdującego się za kilkoma ścianami, VIS zapisywał, że jego geometria nie musi być w tym miejscu nawet rozpatrywana.
Osobne narzędzie o nazwie LIGHT obliczało statyczne oświetlenie, między innymi jasność ścian oraz cienie rzucane przez elementy otoczenia, a następnie zapisywało wyniki w niewielkich lightmapach. Wszystkie te operacje mogły trwać od kilku minut do wielu godzin, ale wykonywano je tylko podczas przygotowywania poziomu. Gracz otrzymywał gotowy plik .bsp, zawierający geometrię, podział przestrzeni, informacje o widoczności i wcześniej wyliczone światło. Podczas zabawy jego komputer nie musiał więc analizować całej planszy od początku. Wystarczyło sprawdzić, gdzie znajduje się kamera, odczytać listę potencjalnie widocznych obszarów i natychmiast odrzucić wszystko, co pozostawało za ścianami. Zamiast rysować ogromny świat i później zakrywać większość wykonanej pracy, Quake najpierw ustalał, które jego fragmenty w ogóle warto wysłać na ekran.
Dobra, ale wyjaśnijmy teraz wszystkie te pojęcia. BSP oznacza Binary Space Partitioning, czyli binarny podział przestrzeni. Najłatwiej wyobrazić go sobie jako wielokrotne przecinanie całej planszy niewidzialnymi płaszczyznami. Pierwsza dzieliła świat na dwie części, każda z nich była później dzielona na kolejne dwie i tak dalej. Zapis tych podziałów przypominał drzewo genealogiczne: na jego początku znajdowała się cała mapa, z każdego rozgałęzienia wychodziły dwie mniejsze części, a na samych końcach umieszczano obszary, których program nie dzielił już dalej. Właśnie te końcowe fragmenty nazywano liśćmi, ponieważ w informatycznym „drzewie” liść oznacza element, z którego nie wychodzą żadne następne gałęzie.
Liść nie był jednak pomieszczeniem, korytarzem ani obiektem widocznym dla gracza. Był niewielkim, niewidzialnym obszarem przestrzeni opisanym przez silnik. Jeden duży pokój mógł zostać podzielony na kilka liści, podobnie jak długi korytarz albo sala z filarami. Każdy z nich miał wypukły kształt, czyli nie posiadał żadnych wnęk ani załamań skierowanych do środka. Pudełko jest wypukłe, ale korytarz w kształcie litery „L” już nie, dlatego trzeba byłoby rozdzielić go na co najmniej dwa prostsze fragmenty. Część liści opisywała pustą przestrzeń, po której mógł poruszać się gracz, a pozostałe znajdowały się wewnątrz ścian i innych pełnych brył.
Takie drzewo pozwalało silnikowi bardzo szybko ustalić położenie kamery. Program zaczynał od pierwszego podziału i sprawdzał, po której stronie płaszczyzny znajduje się gracz. Następnie wybierał właściwą gałąź, przechodził do kolejnego podziału i powtarzał operację, aż docierał do konkretnego liścia. Zamiast porównywać położenie kamery z tysiącami wielokątów, musiał odpowiedzieć na serię prostych pytań: lewa czy prawa strona, przód czy tył, jedna gałąź czy druga. W ten sposób błyskawicznie dowiadywał się, w którym niewielkim fragmencie świata znajduje się gracz.
Pozostawał jednak drugi problem. Informacja o aktualnym liściu nie mówiła jeszcze, jaką część reszty poziomu można z niego zobaczyć. Rozwiązanie pojawiło się około 3:30 nad ranem, kiedy John Carmack leżał już w łóżku, ale nadal zastanawiał się nad systemem portali. Portale nie oznaczały tutaj teleportów. Były niewidzialnymi przejściami łączącymi sąsiednie liście - czymś w rodzaju umownych okien, przez które jeden fragment przestrzeni mógł „zajrzeć” do kolejnego. Program VIS analizował takie połączenia i sprawdzał, przez jakie ciągi portali może przebiegać linia widzenia.
Dla każdego liścia powstawał w ten sposób PVS, czyli Potentially Visible Set - zestaw innych liści, które potencjalnie można było z niego zobaczyć. Załóżmy, że gracz stoi w korytarzu prowadzącym do sali, a za jej ścianą znajdują się jeszcze magazyn i podziemia. Sala mogła trafić do zestawu widoczności korytarza, ponieważ dało się ją zobaczyć przez otwarte przejście. Magazyn również mógł zostać uwzględniony, jeżeli odpowiednio ustawiona kamera pozwalała dostrzec choćby jego niewielki fragment przez kolejne drzwi. Podziemia całkowicie odcięte podłogą nie trafiały jednak na listę, ponieważ z korytarza nie istniała żadna możliwa linia widzenia prowadząca do tej części mapy.
Słowo „potencjalnie” było tutaj kluczowe. PVS nie sprawdzał, w którą stronę gracz patrzy ani czy fragment pomieszczenia zasłania mu w danej chwili przeciwnik, drzwi lub filar. Działał zachowawczo: pozostawiał wszystko, co w określonych warunkach mogło pojawić się na ekranie, ale natychmiast odrzucał obszary, których z danego liścia na pewno nie dało się zobaczyć. Podczas rozgrywki silnik ustalał więc aktualny liść kamery, odczytywał przypisany do niego PVS i jednym ruchem wyrzucał z dalszych obliczeń całe pokoje, korytarze oraz kondygnacje. Dopiero pozostałe powierzchnie trafiały do właściwego renderera.
Pierwsza wersja tabel widoczności zajmowała kilka megabajtów, co na komputerze wyposażonym w 8 MB RAM-u było nie do przyjęcia. Twórcy zrezygnowali więc z przechowywania długich list obszarów. Dla każdego liścia drzewa BSP przygotowali zamiast tego mapę bitową, w której każdy pozostały liść otrzymywał tylko jeden bit: 1, jeśli mógł być widoczny, albo 0, jeżeli na pewno pozostawał zasłonięty. Następnie program VIS kompresował długie ciągi zer, a staranniejszy podział przestrzeni i obowiązek szczelnego zamykania poziomów pozwalały jeszcze bardziej ograniczyć rozmiar danych. Według Michaela Abrasha, w sporej planszy cały PVS zajmował ostatecznie około 20 KB. Podczas rozgrywki silnik ustalał, w którym liściu znajduje się kamera, odczytywał przypisany do niego zestaw widoczności i natychmiast odrzucał z dalszych obliczeń wszystkie fragmenty świata, których gracz nie miał szans zobaczyć.
Pozostałe powierzchnie trafiały do systemu krawędzi i poziomych odcinków ekranu, czyli tzw. spanów. Statyczny świat był rozstrzygany bez pełnego testowania bufora Z dla każdego piksela i zasadniczo bez wielokrotnego zamalowywania tych samych miejsc. Jednocześnie silnik zapisywał dla gotowych pikseli wartość 1/z, opisującą ich głębokość. Przy 320 x 200 taki bufor zajmował 128 KB. Sam zapis głębokości świata kosztował około 10% wydajności, natomiast późniejsze rysowanie ruchomych modeli, sprite’ów i cząsteczek z pełnym odczytem oraz porównaniem bufora było według Abrasha droższe o mniej więcej 20% dla tych obiektów. W zamian potwór znikający za murem naprawdę znikał za murem, a program nie musiał wymyślać osobnej sztuczki dla każdego potwora i wybuchu.
Drugim filarem obrazu były lightmapy, czyli osobne, pozbawione koloru mapy określające jasność poszczególnych powierzchni. Narzędzie LIGHT sprawdzało, jak światło lamp dociera do ścian, podłóg oraz sufitów, a następnie zapisywało próbki jasności w odstępach wynoszących 16 tekseli w pionie i poziomie. W skali świata Quake’a odpowiadało to mniej więcej 61 centymetrom. Podczas gry silnik uzupełniał przestrzeń między punktami na podstawie czterech najbliższych próbek i łączył wynik z właściwą teksturą. Pozwalało to uzyskać stabilne cienie oraz płynne przejścia między światłem, a mrokiem bez dzielenia każdej ściany na setki dodatkowych wielokątów. Quake nie był pierwszą grą korzystającą z wcześniej obliczonego oświetlenia, ale jest powszechnie uznawany za pierwszą komercyjną produkcję wykorzystującą lightmapy w takiej postaci: jako niezależną od geometrii siatkę jasności łączoną następnie z teksturą.
Dynamiczne światło wystrzałów oraz eksplozji początkowo w ogóle nie było w planach programistów. Podczas jednej z konferencji Billy Zelsnack pokazał Carmackowi i Abrashowi własny silnik z efektownym oświetleniem poruszającym się po otoczeniu. Abrash spędził później kilka dni na optymalizowaniu procedury budującej oświetlone powierzchnie, sprowadzając jej koszt do około 2,25 cyklu procesora na teksel. Kilka tygodni później Carmack założył się, że w ciągu godziny dopisze kod potrzebny do obsługi dynamicznych źródeł światła. Dokonał tego w godzinę i dziewięć minut. Nie stworzył jednak w tym czasie kompletnego systemu od podstaw. Napisał warstwę, która rzutowała na otoczenie umowną kulę światła, obliczała jej wpływ na pobliskie powierzchnie i nakazywała silnikowi zbudować je ponownie. Rozwiązanie było matematycznie niedokładne: nie uwzględniało właściwego kąta padania światła, fizycznego spadku jego natężenia ani dynamicznych cieni. Podczas eksplozji trwającej ułamek sekundy nikt nie miał jednak czasu tego analizować.
Migotanie lamp rozwiązano jeszcze mniejszym kosztem. Poszczególnym literom alfabetu przypisano poziomy jasności: „a” oznaczało całkowitą ciemność, „m” normalne natężenie światła, a „z” wartość maksymalną, odpowiadającą mniej więcej dwukrotności poziomu „m”. Sekwencja mmnmmommommnonmmonqnmmo tworzyła nieregularne drżenie uszkodzonej lampy bez symulowania płomienia, instalacji elektrycznej czy wahań napięcia. Gotowe połączenie tekstury i oświetlenia trafiało do pamięci podręcznej, gdzie pozostawało do chwili, gdy dynamiczny rozbłysk wymuszał przebudowanie powierzchni. Każda tekstura występowała ponadto na czterech poziomach szczegółowości: obok wersji podstawowej przechowywano trzy mipmapy zawierające jedną czwartą, jedną szesnastą oraz jedną sześćdziesiątą czwartą jej tekseli. Odległy mur korzystał więc z mniejszej kopii, ponieważ i tak zajmował na ekranie niewiele pikseli. W połączeniu z systemem spanów ograniczającym wielokrotne rysowanie tych samych punktów pozwalało to swobodnie zmieścić te pliki w pamięci podręcznej (ważyły około 600 KB przy rozdzielczości 320 x 200p oraz w niewiele ponad 1 MB przy 640 x 480p).
Cztery bajty na wierzchołek i potwory złożone z oszustw
Model 3D można wyobrazić sobie jako figurę złożoną z połączonych trójkątów. Punkty, w których spotykają się ich krawędzie, nazywamy wierzchołkami. W formacie modeli Quake’a położenie każdego wierzchołka w pojedynczej klatce animacji zajmowało zaledwie trzy bajty - po jednym dla osi X, Y oraz Z. Czwarty bajt zawierał numer jednego ze 162 wcześniej przygotowanych kierunków, wykorzystywanych później podczas obliczania oświetlenia (o tym niżej). Technicznie był to indeks wektora normalnego wierzchołka. Najłatwiej wyobrazić go sobie jako niewidzialną strzałkę wskazującą, w którą stronę zwrócony jest otaczający wierzchołek fragment modelu. Nie opisywała ona kierunku padania światła. Silnik porównywał kierunek tej strzałki z położeniem umownego źródła światła i na tej podstawie ustalał, jak mocno rozjaśnić albo przyciemnić dany fragment potwora.
Każdy taki kierunek można byłoby zapisać za pomocą trzech dodatkowych wartości, po jednej dla osi X, Y i Z. Twórcy Quake’a znaleźli jednak tańsze rozwiązanie: przygotowali w silniku tabelę 162 gotowych kierunków, a model przechowywał tylko jednobajtowy numer najlepiej pasującego z nich. Podczas rysowania program porównywał wybrany kierunek powierzchni z kierunkiem umownego światła i na tej podstawie ustalał jasność wierzchołka. Statyczne oświetlenie pomieszczenia decydowało o ogólnej jasności całego modelu, a wystrzały i eksplozje mogły ją chwilowo zwiększyć. Sposób rozłożenia światła na ciele potwora pozostawał jednak potężnym uproszczeniem. W opublikowanym kodzie źródłowym kierunek światła dla ruchomych modeli otrzymał stałą wartość {-1, 0, 0}, obok której programiści zostawili komentarz: FIXME: remove and do real lighting, czyli „usunąć i zrobić prawdziwe oświetlenie”. Trudno o uczciwsze przyznanie, że najważniejsze było tempo działania, a nie matematyczna wierność.
Animacji także nie wyliczano za pomocą szkieletu i połączonych z nim kości. Każda klatka zawierała kompletny, skompresowany zestaw położeń wszystkich wierzchołków modelu. Kiedy potwór przechodził do następnej pozy, punkty tworzące jego ciało po prostu przeskakiwały w nowe miejsca - silnik nie obliczał płynnych stanów pośrednich. W połączeniu z zapisem każdej współrzędnej za pomocą tylko jednego bajtu powodowało to charakterystyczne drżenie i „pływanie” modeli, szczególnie widoczne dzisiaj w wysokich rozdzielczościach. Dla niewielkich trójkątów zastosowano jeszcze jeden skrót. Jeżeli któryś z ich boków obejmował więcej niż jeden piksel, program dzielił go w połowie, wyznaczał nowy punkt i powtarzał tę czynność dla dwóch powstałych trójkątów. Metoda nie odwzorowywała kształtu oraz tekstury równie dokładnie jak klasyczny rasteryzator, ale przy figurach zajmujących zaledwie kilka pikseli różnicy praktycznie nie dało się zauważyć. W całym procesie rysowania modeli zapewniała około 20% przewagi. Michael Abrash przeliczył to na znacznie bardziej zrozumiałą jednostkę: dwanaście potworów na ekranie zamiast dziesięciu. Abrash szczegółowo opisał ten mechanizm w rozdziale poświęconym modelom Quake’a.
Przejdźmy natomiast do samej optymalizacji gry, bo to ma kluczowe znaczenie. Różne fragmenty gry renderowane były w formie cykli na teksel. Czym to dokładnie jest? Postanowiłem opisać to zagadnienie w ramce niżej.
Najbardziej obciążone fragmenty programowego renderera zapisano ręcznie w asemblerze, dzięki czemu programiści mogli dokładnie ustalić, jakie instrukcje oraz w jakiej kolejności wykona Pentium. README do opublikowanych później źródeł ostrzegało, że wersje korzystające wyłącznie z kodu C traciły niemal połowę wydajności. Przewaga nie wynikała przy tym z jednej cudownej sztuczki, lecz z bardzo starannego organizowania pracy procesora. Prawidłowe ułożenie tekstury w perspektywie wymagało kosztownego dzielenia, ale silnik nie wykonywał go osobno dla każdego piksela. Obliczał dokładne wartości na granicach kolejnych fragmentów o długości 16 pikseli, a przestrzeń pomiędzy nimi wypełniał znacznie tańszą interpolacją.
Najsprytniejsze było ukrycie czasu oczekiwania na wynik. Kiedy jednostka zmiennoprzecinkowa Pentium obliczała parametry następnego fragmentu, pozostała część procesora wykonywała instrukcje całkowitoliczbowe i rysowała poprzednie 16 pikseli. Zamiast bezczynnie czekać na zakończenie kosztownego dzielenia, komputer zajmował się w tym samym czasie użyteczną pracą. Właśnie tak udało się osiągnąć opisane w ramce wyniki 2,25 cyklu na oświetlony teksel oraz 7,5 cyklu na piksel ekranu.
Na koniec warto rozprawić się z popularną legendą. Słynny fragment kodu obliczający „szybki odwrotny pierwiastek”, regularnie przypisywany pierwszemu Quake’owi, znaleziono dopiero w opublikowanych źródłach Quake III Arena. Nie był więc sekretem stojącym za wydajnością gry z 1996 roku. Pierwszy Quake miał wystarczająco dużo prawdziwych sztuczek, żeby nie dopisywać mu jeszcze jednej.
Quake nie był grą od samego początku tylko... prezentacją techniczną
Przez znaczną część produkcji Quake nie miał jeszcze ustalonej tożsamości. Sama nazwa była zresztą starsza od Dooma: już w 1990 roku, w zapowiedzi umieszczonej w Commander Keen, id Software wspominało o planowanej grze The Fight for Justice, której bohaterem miał zostać Quake. Postać pochodziła z prywatnej kampanii Dungeons & Dragons prowadzonej przez Johna Carmacka. Quake uosabiał siłę, walczył młotem zdolnym niszczyć budynki i korzystał z unoszącego się artefaktu Hellgate Cube, rażącego przeciwników błyskawicami. Gdy po latach studio wróciło do tego pomysłu, planowało średniowieczną grę akcji z elementami RPG, walką wręcz, rzucanymi broniami, obszarowymi uderzeniami młota oraz sześcianem karmionym duszami pokonanych wrogów. Na przedpremierowych materiałach pokazano nawet smoka, chociaż - jak przyznał później Romero - model nie został naprawdę uruchomiony i na potrzeby zrzutu ekranu po prostu umieszczono go nieruchomo na niebie. Technologia powstawała jednak tak długo, że projektanci przez wiele miesięcy nie mogli budować właściwej gry. W listopadzie 1995 roku zespół zdecydował więc, że wykorzysta nowy silnik do stworzenia szybkiej strzelanki. Ocalały gotyckie zamki, runiczne świątynie, demoniczne wrota i lovecraftowskie potwory, do których dołączono wojskowe bazy, strzelby oraz wyrzutnie rakiet. Niespójność świata nie była od początku wielkim planem artystycznym. Powstała z resztek kilku różnych pomysłów, a mimo to została jednym z najbardziej rozpoznawalnych elementów całej gry.
Poszczególne fragmenty tej układanki połączyła oprawa dźwiękowa przygotowana przez Trenta Reznora oraz Chrisa Vrennę z Nine Inch Nails. Był to zestaw industrialnych szumów, metalicznych uderzeń, dronów i niepokojących pejzaży dźwiękowych, które bardziej budowały napięcie, niż towarzyszyły strzelaniu. Reznor uczestniczył również w nagrywaniu efektów - jego głos można usłyszeć między innymi w sapnięciach oraz odgłosach bólu Rangera. Dziesięć utworów zapisano na płycie Quake’a jako zwykłe ścieżki audio CD, natomiast pierwszą ścieżkę zajmowały dane gry. Krążek można więc było włożyć do domowego odtwarzacza i słuchać muzyki bez uruchamiania komputera. Rozwiązanie miało również cenę: po wyjęciu płyty Quake nadal działał, lecz milkła cała ścieżka dźwiękowa, a niektóre późniejsze wydania cyfrowe początkowo sprzedawano bez właściwego audio. Logo NIN umieszczone na pudełkach z gwoździami do Nailguna nie było natomiast przypadkową ozdobą, lecz ukłonem w stronę autorów oprawy. To prawdopodobnie jeden z nielicznych przypadków lokowania nazwy zespołu, które idealnie do niego pasowało.
24 lutego 1996 roku id Software udostępniło QTest - niedokończony test technologii oraz sieciowego deathmatchu zawierający trzy mapy, ale pozbawiony kampanii dla jednego gracza. QTest przypominał paczkę wypuszczoną dla ludzi, którzy potrafili uruchomić program z odpowiednimi parametrami i sami chcieli zajrzeć mu pod maskę. Gracze natychmiast zaczęli analizować strukturę plików, podmieniać skórki i modele, a nawet tworzyć mody umieszczające przeciwników na pustych planszach wieloosobowych. Do premiery pozostawały niemal cztery miesiące, a społeczność zachowywała się już tak, jakby dostała zestaw konstrukcyjny, nie reklamową próbkę. W tym samym czasie John Romero, American McGee, Sandy Petersen i Tim Willits kończyli poziomy, natomiast Adrian Carmack, Kevin Cloud oraz Paul Steed przygotowywali modele i tekstury. Zespół był wyczerpany wielomiesięcznym chaosem, ale QTest ujawnił coś, czego id Software nie musiało już projektować: gracze sami zaczęli zmieniać Quake’a jeszcze przed ukończeniem jego podstawowej wersji. Gra nie zdążyła jeszcze trafić do sklepów, a jej drugie życie już się rozpoczęło.
Gra się kiedyś kończyła, ale jej technologia budowała nowe fundamenty
Jedną z najważniejszych decyzji Carmacka było oddzielenie silnika od zasad zabawy. Renderer, pliki, dźwięk, sieć i podstawowe wykrywanie kolizji działały w głównym programie. Broń, zachowania przeciwników, wyzwalacze, reguły oraz część logiki ruchu zapisano w stworzonym specjalnie języku QuakeC. Kompilator tłumaczył źródła do bajtkodu w pliku progs.dat, wykonywanego później przez maszynę wirtualną wewnątrz gry. Modder nie musiał wiedzieć, jak silnik wyznacza spany albo rozpakowuje PVS, aby stworzyć nowy karabin czy zmienić zasady deathmatchu. Źródła logiki oryginalnej gry opublikowano 25 lipca 1996 roku, zaledwie 33 dni po premierze.
Już 24 sierpnia ukazała się pierwsza wersja „Team Fortress”, oferująca pięć klas: Scouta, Snipera, Soldiera, Demolitions Mana i Medica. Później pojawiły się między innymi Threewave Capture the Flag, totalne konwersje i tysiące map. Gracze zamienili odrzut rakiety w środek transportu, popularyzując rocket jumping, a niedoskonałości przyspieszenia w powietrzu wykorzystali do bunny hoppingu. Nie każda z tych technik narodziła się wyłącznie w Quake’u, lecz właśnie tutaj połączyły się z sieciową rywalizacją, nagrywaniem dem i kulturą modyfikacji. Gra przestała być zamkniętym produktem. Stała się językiem, którym społeczność zaczęła projektować własne strzelanki.
System dem nie zapisywał gotowych klatek filmu. Rejestrował wiadomości przesyłane z serwera do klienta oraz trzy kąty ustawienia kamery, dzięki czemu pliki były małe i silnik mógł później odtworzyć przebieg wydarzeń. Standardowe demo zachowywało jednak konkretny punkt widzenia - nie dawało automatycznie swobodnej kamery ani wyboru dowolnej perspektywy. Twórcy „Diary of a Camper” przygotowali własne narzędzia do przestawiania kamery, łączenia fragmentów oraz umieszczania tekstu. Opublikowany 26 października 1996 roku film grupy The Rangers trwał minutę i 36 sekund i jest powszechnie uznawany za pierwszy przykład narracyjnej machinimy. Silnik FPS-a stał się kamerą filmową, zanim ktokolwiek ustalił, jak nazwać takie zjawisko.
Podstawowy Quake od początku korzystał z architektury klient-serwer. Serwer był sędzią: rozstrzygał położenie postaci, trafienia i stan mapy, a klienci otrzymywali wyniki. W sieci lokalnej działało to znakomicie. Przez modem polecenie ruchu musiało jednak dotrzeć do serwera, zostać przetworzone i wrócić, zanim gracz zobaczył reakcję własnej postaci. Carmack przyznał później, że projektując system, nie rozumiał jeszcze, jak źle zachowuje się gra przy opóźnieniach przekraczających 200 ms. Sam miał w domu łącze T1, podczas gdy zwykły użytkownik łączył się przez modem i przeciążonego dostawcę, często oglądając ping ponad 300 ms. Przy takich opóźnieniach Ranger poruszał się tak, jakby przed każdym krokiem wysyłał do centrali formularz z prośbą o zgodę na wykonanie kroku.
W sierpniu 1996 roku Carmack ogłosił przebudowę sieci, a w grudniu udostępniono pierwsze publiczne wersje QuakeWorld. Klient wykonywał ruch natychmiast, przewidując wynik lokalnie, natomiast serwer nadal zachowywał ostateczny autorytet i w razie rozbieżności korygował stan gracza. QuakeWorld nie wynalazł przewidywania po stronie klienta - wcześniej stosował je choćby „Duke Nukem 3D” - ale pokazał, jak wykorzystać je w niezwykle szybkim internetowym FPS-ie i połączyć z autorytatywnym serwerem. Rozwiązanie stało się jednym z fundamentów późniejszych gier sieciowych.
Sprzętowa akceleracja także miała etap, o którym łatwo zapomnieć. Jeszcze pod koniec 1996 roku powstał VQuake przeznaczony dla kart z układem Rendition Vérité, ale był związany z własnym API jednego producenta. Carmack nie chciał powtarzać tej pracy dla każdej kolejnej karty. 22 stycznia 1997 roku ukazała się pierwsza beta GLQuake korzystająca z OpenGL. Właściciele 3dfx Voodoo dostali wyższe rozdzielczości, filtrowanie tekstur i wydajność nieosiągalną dla programowego renderera. Quake stał się jednym z najmocniejszych argumentów za zakupem akceleratora 3D, a publiczne teksty Carmacka porównujące OpenGL z ówczesnym Direct3D zmusiły całą branżę do dyskusji o tym, jak powinien wyglądać standard grafiki na PC.
21 grudnia 1999 roku id Software opublikowało kod silnika na licencji GPL. Carmack zgodził się nawet na jego komercyjne wykorzystanie, pod warunkiem udostępniania kodu zmodyfikowanej wersji; osobno chronione pozostały dane gry, czyli mapy, grafika i dźwięki. Na znacznie zmienionej technologii licencjonowanej wcześniej od id Software Valve zbudowało silnik „Half-Life’a”, nazwany później GoldSrc. Z kolei otwarcie źródeł dało początek dziesiątkom source portów i pozwoliło uruchamiać klasyka na telefonach, zegarkach, w przeglądarkach oraz na sprzętach, których Carmack w najbardziej wykręconych snach nie mógłby wówczas przewidzieć.
Produkcja wypaliła klasyczny skład id Software i pogłębiła spory, po których odeszli między innymi Romero, Abrash i Petersen. Nie znaczy to, że jeden program komputerowy samodzielnie „rozbił” firmę, lecz technologiczna ambicja, wielomiesięczny crunch i brak wspólnej wizji miały bardzo realną cenę. Sam Quake przetrwał natomiast swoich twórców, sprzęt i pierwotny model sprzedaży. Dosłownie tydzień temu, 6 sierpnia 2026 roku, nieco ponad trzydzieści lat po niej, gra otrzymała remaster na konsolach PS5/XSX oraz darmowy dodatek „Dawn of the Machine” przygotowany przez MachineGames. Dostaliśmy aż 19 nowych poziomów, warianty broni oraz galerię zawierającą również niedokończone, grywalne mapy z okresu produkcji. Najlepszym podsumowaniem Quake’a nie jest więc liczba wielokątów ani klatek na sekundę. id Software stworzyło technologię, która w 1996 roku nauczyła komputer, czego nie warto wyświetlać, a ludzi, że ukończona gra może być dopiero początkiem.
Przeczytaj również
Komentarze (3)
SORTUJ OD: Najnowszych / Najstarszych / Popularnych