Titanfall: Priorytetem jest płynność
Digital Foundry rozmawia z producentem gry.
Najważniejsza gra targów? Może nawet pierwszy tytuł nowej generacji, napędzający sprzedaż konsoli? Podczas targów Gamescom gracze mogli przetestować Titanfall - grę studia Respawn Entartainment. To strzelanka science-fiction od współtwórców Call of Duty - marki, która zdefiniowała obecną generację konsol. Mogliśmy wreszcie przyjrzeć się tej ciekawie zapowiadającej się grze. Pierwsze wrażenia są dość niesamowite.
Z perspektywy technicznej, widać jak na dłoni, że Respawn kładzie punkt ciężkości w innym miejscu niż konkurencja. Titanfall w ruchu powala, tyle że dla osiągnięcia tego efektu nie musi wspomagać się najnowocześniejszymi technikami graficznymi. Zapomnijcie o tak popularnym obecnie materiałowym fizycznym renderingu (ang. materials-based physical rendering), teselacji sub-D czy dynamicznej destrukcji otoczenia, tzw. „lewolucji”.
W Titanfall wykorzystano tradycyjne techniki renderowania, które w połączeniu z mocą konsol następnej generacji, wyjątkowym wyczuciem artyzmu, designem oraz akcją przynoszą na ekrany świeżą oraz ekscytującą rozgrywkę. Mechanika gry i technologia wykorzystana przy tworzeniu Titanfall służą realizacji najważniejszego celu, którym jest zapewnienie dobrej zabawy.
Debiutancki projekt Respawn tak bardzo nas urzekł, ponieważ wykorzystując moc nowej generacji konsol, sięga do motywów znanych z klasycznych FPS-ów, gdzie nieprawdopodobne założenia wdrażano z pogardą dla tak wszechobecnego we współczesnych strzelaninach realizmu.
Call of Duty: Ghosts i Battlefield 4 bez wątpienia okażą się klasą samą w sobie, ale Titanfall rozpaliło wyobraźnię core'owych graczy, łącząc najpopularniejsze gatunki i okraszając to wszystko magią, która niegdyś sprawiła, że w ogóle zainteresowaliśmy się grami; to prawdziwy balsam na duszę graczy znużonych sześcioma kolejnymi, wyczerpującymi formułę odsłonami Call of Duty i licznymi rywalami tej serii.
Fakt, że Titanfall kładzie nacisk na gameplay, przedkładając rozgrywkę nad technologiczne wodotryski, nie oznacza, że temat możemy ot tak zamknąć - to w końcu gra reklamowana jako kluczowy tytuł, przygotowywany wyłącznie na konsolę Xbox One. Wykorzystuje Azure - Microsoftową technologię chmury - i silnik Source, na którym powstał Portal 2. Podczas Gamescomu mieliśmy okazję porozmawiać z producentem Titanfall i uzyskać od niego odpowiedzi na (niemal) wszystkie nurtujące nas pytania.
Gdy założyliśmy firmę i zaczęliśmy się zastanawiać, jaką grę chcemy stworzyć, nie mieliśmy ani biura, ani komputerów. Zajęliśmy pięterko, które obecnie zajmujemy (wtedy jeszcze na dziko, dopiero później podpisaliśmy umowę), wtaszczyliśmy tam składane krzesła i siedliśmy w kręgu. Było nas jakieś 30-40 osób, wszyscy mocno zaangażowani w projekt; rozmawialiśmy o tym, jakie gry lubimy, które nas rozczarowały i dlaczego; jakie nie do końca wykorzystane pomysły albo elementy mechaniki fajnie byłoby zrealizować. Gdy już udało nam się założyć normalne biuro i podłączyliśmy się do Perforce, zabraliśmy się do roboty - tworzenia prototypów. Początkowo skupialiśmy się na mobilności w grach FPS. Gdzie się nie ruszyć, jakieś ograniczenia - cofnijmy się 15 lat wstecz, do Quake'a, Unreala, Dooma, Tribes, itp.
Nie ma rocket jumpów, zwariowanych combosów, nic... Jest nijako. FPS-y zrobiły się jednowymiarowe.
Tak. Counter-Strike i Rainbow Six debiutowały mniej więcej w tym samym czasie. Oba tytuły zyskały dużą popularność i okazały się przystępne dla zwykłych graczy. Już nie musiałeś być mega kozakiem z kosmicznym refleksem, też mogłeś zaliczyć sporadycznego headshota, a widząc AK-47 czy M9 gracze rozumieli, z czym mają do czynienia - i to właśnie zapoczątkowało modę na realizm czy też autentyzm w grach.
Taka formuła narzuca pewne ograniczenia i jednym z powodów, dla których wybraliśmy klimaty SF, był fakt, że skoro zdecydowaliśmy się na podwójne skoki, bieganie po ścianach i wielkie roboty, to siłą rzeczy musieliśmy też znaleźć usprawiedliwienie dla istnienia tej mechaniki w świecie gry. Takie zagrania są dzisiaj niewykonalne, a science-fiction otwiera drzwi do stworzenia uniwersum, w którym wszystkie nasze wymysły stają się rzeczywistością.
Masę szalonych pomysłów. W zasadzie to nie powinienem o nich za dużo mówić. Pewnie jeszcze wrócimy do nich w kolejnych grach. Staramy się nie koncentrować na czymś, co nie do końca spełnia nasze oczekiwania. Czasami trzeba z czegoś zrezygnować, chociaż nie jest to łatwe, ale można też odłożyć pomysł na później, gdy będziemy mieli więcej czasu, żeby go doprecyzować.
Przy tworzeniu FPS-a dzielisz swój czas i dostępne zasoby na stworzenie kampanii i trybu multi. Ponieważ mamy w zespole jakieś 70 osób, chcieliśmy ich wszystkich zaangażować w tworzenie jednego trybu. Niektórzy świetnie znają się na filmowej reżyserii trybów dla jednego gracza, inni na rozgrywce multiplayer - więc pojawił się pomysł, żeby połączyć jedno z drugim. Potyczki, w których weźmie udział gracz, będą pojawiać się w ustalonym porządku - rozgrywka nie będzie posklejana z przypadkowych poziomów, bo każdy ma opowiadać swoją historię. Zamiast liniowej, rozbitej na trzy akty opowieści, gracz dostanie elementy układanki, które pozwolą mu lepiej zrozumieć różne aspekty fabuły.
„Wybraliśmy Source, bo wielu naszych designerów chciało przygotować prototypy rozgrywki, a wraz z silnikiem zyskiwaliśmy dostęp do zabawek, które Valve implementowało w nim przez dobrą dekadę.”
Nie, poziomy kampanii będą pod tym względem przypominać etapy klasycznego singla. Każdy będzie miał przypisaną opowieść.
Teoretycznie moglibyśmy wykorzystać patche czy coś w tym stylu, żeby dodać jakieś elementy fabuły albo rozszerzyć uniwersum. Zależy nam na tym, żeby przedstawić wydarzenia w grze w określonym kontekście i lepiej opowiedzieć naszą historię.
Przyglądaliśmy się wielu różnym silnikom - tym najpopularniejszym i tym mniej znanym.
Tak, wybraliśmy Source, bo wielu naszych designerów chciało przygotować prototypy rozgrywki, a wraz z silnikiem zyskiwaliśmy dostęp do zabawek, które Valve implementowało w nim przez dobrą dekadę. Na zasadzie: „Acha, zrobili coś takiego w Team Fortress, zobaczmy, jak sprawdzi się to rozwiązanie” - i jeśli nam się spodobało, mogliśmy rozbudować dostępny model i przystosować go do naszych potrzeb.
Na tym etapie mam poważne opory, żeby nazwać ten silnik „Source”.
Tak, tyle rzeczy zmieniliśmy... Mamy zupełnie nowy renderer, nowy kod audio, nowy netcode, nowe instrukcje dla kontrolera. Niektóre elementy silnika usprawniliśmy, ale ogólnie rzecz biorąc wprowadziliśmy wielkie zmiany. Mamy własny edytor poziomów, system oświetlenia, kompilator map.
Pracę nad kodem zaczęliśmy właśnie od wersji silnika z Portala 2 - jednowątkowego i opartego na DX9. W Portalu wycisnęli z niego, co się dało. Nie mógł przeskoczyć pewnej granicy renderowania. Główny wątek nie był w stanie zrealizować wystarczającej liczby zadań, więc włożyliśmy wiele pracy w przebudowanie go. Gdy zdecydowaliśmy się na Source, zrobiliśmy to ze świadomością, że kolejne dwa lata poświęcimy na optymalizację kodu. Fakt, że gwarantował 60 klatek na sekundę, nie miał takiego znaczenia.
Prawdę mówiąc, to Source mocno traci na płynności, jeśli próbujesz koncentrować się na wizualnym przepychu. Te mapy, które stworzyliśmy, na starej wersji kodu chodziłyby w kilku klatkach na sekundę - o ile w ogóle udałoby się je odpalić. To wielkie wyzwanie dla naszego zespołu i dlatego właśnie przesunęliśmy ten etap na koniec, żeby projektanci mogli zająć się swoją działką - w przeciwnym razie nie mieliby nic do roboty, musieliby czekać, aż programiści stworzą swoje narzędzia. To zespół, składający się z dwunastu osób - niewiele, biorąc pod uwagę, jak wielkie zadanie wykonali.
„Source mocno traci na płynności, jeśli próbujesz koncentrować się na wizualnym przepychu.”
Jest całkowicie nowy. To jak przejście z architektury Xboksa 360 na PlayStation 3 - ale posunęliśmy się jeszcze dalej. Teraz wykorzystuje architekturę 64-bitową, DX11, przebudowaliśmy narzędzie do renderowania map świetlnych (ang. lightmaps) i zaimplementowaliśmy własny system źródeł światła. Nie jest to generowane w czasie rzeczywistym oświetlenie globalne - skroiliśmy coś pod nasze potrzeby. Nie dodajemy wodotrysków tylko dlatego, że mamy taką możliwość. Skupiamy się na designie, mechanice i dostarczeniu naszym artystom narzędzi, dzięki którym upiększą swoją wizję. Naszym głównym celem jest wydajność.
Tak, sam przeprowadzam masę takich testów.
[Śmiech] Nigdy nie wiadomo, kiedy coś się posypie. Problem może dotyczyć kodu, aplikacji albo danych, i animacja zaskoczy dopiero chwilę po wydaniu komendy przeładowania albo skoku. Chcemy wyeliminować wszelkie opóźnienia między wciśnięciem przycisku a akcją na ekranie.
To nieprawda.
John Shiring, nasz inżynier od spraw sieci, opublikował na naszej stronie świetny artykuł na ten temat, więc pewnie orientujesz się, o co w tym chodzi. W zależności od zapotrzebowania w danym regionie będziemy mogli uruchomić dodatkowe wirtualne maszyny, w dowolnej chwili zaktualizować paczkę danych i wdrożyć instrukcje.
Nie - nie są jeszcze gotowe. Teoretycznie rzecz biorąc, gdybyśmy bardzo się spięli, moglibyśmy sprawić, że logi binarne serwerach byłyby identyczne dla wszystkich platform. Nie wydaje mi się, żeby nam się udało, ale to bez znaczenia. Po prostu aktywujemy 100 tys. serwerów dla PC, 200 tys. dla Xbox One...
Nie, cała sztuczna inteligencja jest obliczana na serwerze, fizyka... Cóż, część obliczeń dotyczących fizyki wciąż jest przeprowadzana po stronie klienta.
Jak najbardziej. Nawet jeśli grasz na serwerze, który sam postawiłeś, i tak doświadczysz opóźnienia między serwerem a klientem i jeśli go nie skompensujemy, pojawia się dziwne wrażenie braku ciągłości. Narzędzia kompensacji zawsze będą obecne.
Oczywiście. Całe doświadczenie zyskuje na spójności. W grze, którą hostuje któryś z graczy zawsze będzie ta jedna osoba z zerowym lagiem. U pozostałych lag będzie uzależniony od odległości. Jeśli host mieszka w Dakocie Północnej, wszyscy muszą się tam przenieść.
„Cała sztuczna inteligencja jest obliczana na serwerze, fizyka... Cóż, część obliczeń dotyczących fizyki wciąż jest przeprowadzana po stronie klienta.”
Tak. Tak jest bardziej uczciwie. I szybciej. Mamy z głowy problemy z grupami i matchmakingiem, NAT-T i migracją hosta. Dzięki temu uwalniamy nieco czasu procesora. W grze hostowanej po stronie klienta każdy może postawić serwer i nie ma pewności, czy dysponuje odpowiednimi zasobami procesora i pamięci. Z myślą o takich sytuacjach rezerwujemy te 10-15% czasu procesora. W naszym przypadku wiemy, że nie będzie żadnych serwerów po stronie klienta, więc możemy swobodnie dysponować wszystkimi zasobami.
Zależy. Z tego, co pamiętam, to fizyka postaci jest liczona po stronie klienta, bo nie odbija się na rozgrywce. Jeśli to się zmieni, przerzucimy ją na stronę serwera. Jeśli nie - na przykład, gdy po trafieniu titana odpadają fragmenty opancerzenia - zostawimy ją po stronie klienta.
: Source jest od dekady wykorzystywany w grach, ale przez ten czas kod audio zdążył obrosnąć w wiele zbędnych elementów. Aż trudno w to uwierzyć - kod źródłowy przypomina talerz spaghetti. W pewnym momencie okazało się, że - z punktu widzenia naszych potrzeb - łatwiej będzie zbudować coś nowego. Nie celujemy w HDR (ang. High Dynamic Range).W sumie to zabawna sprawa, bardziej przypomina to LDR (ang. Low Dynamic Range), bo przecież ograniczamy spektrum słyszalnych dźwięków. Ale co tam - jest super. Mamy swoje terminy, a w ekipie dźwiękowca, który wcześniej pracował nad Battlefieldem i Medal of Honor, więc zna się na udźwiękowieniu w grach.
To świetna maszyna. Mamy całą masę devkitów i nieustannie doglądamy wersji konsolowej. Obecnie na obu sprzętach - PC i Xbox One - mamy zaimplementowane te same efekty. Nad wydajnością będziemy pracować do ostatniego dnia - architektura sprzętu nie jest jeszcze sfinalizowana, a nasza gra - gotowa. Będziemy mieć masę pracy przy optymalizacji.
Celujemy w wiosnę 2014 roku - nie jestem pewien, czy to się jeszcze liczy jako okno startowe. Do tego czasu pojawi się wiele gier, co, mam nadzieję, pozytywnie wpłynie na developing. Chcielibyśmy, żeby nasza gra towarzyszyła premierze konsoli, to powód do swoistej dumy. Niestety, terminy…
Tylko to, że pracuje nad nią osobny zespół.
Bez komentarza [Śmiech]. Mogę powiedzieć tylko tyle, że ekipa, której powierzyliśmy tę wersję gry zna się na rzeczy. Nie ingerujemy w ich pracę. Nie mówimy, co mają robić, ale spotykamy się, przyglądamy się ich dokonaniom, synchronizujemy Perforce'y... To nie będzie jakaś osobna gra z odmienną zawartością. Chcemy zapewnić identyczne wrażenia na każdej platformie.
Zobaczymy, co uda nam się zrobić. Priorytetem jest płynność.