Читать книгу Krew, pot i piksele - Jason Schreier - Страница 4

Powiedzmy, że chcecie stworzyć grę wideo. Macie już zabójczy pomysł – dajmy na to, że miałaby traktować o wąsatym hydrauliku rzucającym się na ratunek swojej dziewczynie, księżniczce porwanej przez ogromnego, ziejącego ogniem żółwia – i nawet udało wam się naciągnąć inwestora na parę baniek, aby go zrealizować. I co dalej?

Cóż, musicie ustalić, na zatrudnienie ilu ludzi możecie sobie pozwolić, a potem podzwonić po rysownikach, designerach, programistach. Trzeba też mieć producenta czuwającego nad całym procesem, a także dział dźwiękowy, ponieważ wypada, żeby gra miała te, no, dźwięki. Nie zapomnijcie o wykwalifikowanych i sprawdzonych testerach, którzy wyłapią błędy. No i geniusza marketingowego, bo skąd ludzie będą wiedzieć, że szykujecie bestseller? Jak już uda się ich wszystkich zebrać, ustalcie dokładny grafik, który określi, ile czasu dana ekipa spędzi nad poszczególnymi częściami gry. Jeśli wszystko pójdzie dobrze, w pół roku uda się przygotować demo, akurat na E3, a przed końcem roku będziecie mieli „pełny produkt”.

Przez kilka miesięcy wszystko idzie całkiem nieźle. Rysownicy stworzyli już projekty paru fajowych przeciwników, z którymi będzie zmagał się wasz hydraulik: duchy, grzybki, tego typu postaci. Designerzy naszkicowali pomysłowe poziomy, prowadząc gracza przez bulgoczące wulkany i cuchnące bagniska. Programiści rozgryźli, jak wykorzystać sztuczki graficzne i dzięki bajeranckiemu renderowaniu podziemia wyglądają bardziej realistycznie niż wszystko, co do tej pory widzieliście. Nikomu nie brakuje motywacji, robicie postępy i rozdajecie opcje na zakup akcji firmy jak darmowe gazety na stacji metra.

Aż któregoś ranka dostajecie telefon od swojego producenta. Okazało się, że tamten trik z renderowaniem jest bezużyteczny, bo przez niego częstotliwość wyświetlania klatek spada do dziesięciu na sekundę[1]. Testerzy zacinają się na etapie z wulkanem, a koleś od marketingu nie przestaje gadać o tym, jak bardzo zaszkodzi to ocenie gry na Metacritic. Art director nalega na ściślejszą kontrolę nad pionem animacji, przez co tamci dostają szału. Demo na E3 ma być gotowe za dwa tygodnie, a wy wiecie, że nie ma szans skończyć go wcześniej niż za miesiąc. Nagle inwestorzy zaczynają się dopytywać, czy nie udałoby się zmniejszyć budżetu z dziesięciu do ośmiu milionów, co oznaczałoby, że musielibyście zwolnić wtedy parę osób.

Przed tygodniem fantazjowaliście o przemówieniu, które wygłosicie podczas gali Game Awards, po odebraniu nagrody za Grę Roku. A teraz zastanawiacie się, czy w ogóle uda się ją ukończyć.

Miałem kiedyś okazję napić się z developerem, który dopiero co wypuścił nową grę. Wyglądał na wykończonego. Razem ze swoją ekipą już zbliżali się do linii mety, kiedy dotarło do nich, że jedna z głównych atrakcji gry nie jest tak interesująca, jak myśleli. Parę następnych miesięcy spędzili na tak zwanym „crunchu”, pracując całe tygodnie po 80–100 godzin, aby rozłożyć wszystko na czynniki pierwsze i kompletnie przerobić wszystko, co do tej pory udało się domknąć. Niektórzy spali w biurze, żeby nie tracić czasu na codzienne dojazdy do pracy, bo każda godzina spędzona za kierownicą oznaczała godzinę mniej na łataniu niedociągnięć. Aż do dnia terminu złożenia całości wielu z nich wątpiło, czy w ogóle uda im się tę grę wypuścić.

– Cud, że ta gra powstała – powiedziałem.

– Jason – odparł – to cud, że jakakolwiek gra powstała.

Przez kolejne lata, kiedy zajmowałem się światem gier, często to słyszałem. Developerzy, bez względu na to, czy pracowali dla niedużego, niezależnego studia, czy obecnych na giełdzie korporacji, często mówili o tym, jak ciężko projektować i produkować gry. Podczas odbywającej się co roku Game Developers Conference (GDC) wystarczy wejść do jakiegokolwiek baru w San Francisco i nie ma szans nie natknąć się na zmęczonych designerów starających się przebić jeden drugiego opowieściami o ciągach koderskich i napędzanych kofeiną nocek. Nieobce są im wojenne metafory – „opowieści okopowe” to powszechne sformułowanie – i chóralne narzekania, których świat zewnętrzny nie potrafiłby zrozumieć. Żeby zirytować jeszcze bardziej takiego developera wystarczy zapytać go, jak to jest całymi dniami grać.

Ale nawet kiedy zrozumiemy, że również developer ma wymagającą pracę, nie jest łatwo nam pojąć dlaczego. Przecież ludzie robią gry od lat 70., co nie? Po dekadach rozmaitych doświadczeń i prób developerzy powinni być raczej wydajni, prawda? Może podobne myślenie sprawdziłoby się pod koniec lat 80., kiedy grami zajmowały się głównie nastolatki i dwudziestoparolatkowie odżywiający się wyłącznie pizzą i dietetyczną colą; kodowali nocami, przesypiali całe dnie. Ale po latach przemysł gier w samych Stanach Zjednoczonych wyceniano już na 30 miliardów[2]. Czemu jednak developerzy nadal opowiadają o przesiadywaniu w pracy do trzeciej nad ranem? Dlaczego nadal tak trudno robić gry?

Żeby znaleźć odpowiedzi na te pytania, zrobiłem to, co lubię najbardziej: nękałem ludzi o wiele mądrzejszych od siebie. Rozmawiałem z przeszło setką developerów i ludzi na stanowiskach kierowniczych, zarówno zarówno oficjalnie, jak i nieoficjalnie, zadając im niezliczony ciąg wścibskich pytań na temat ich życia i pracy, próbując dociec, czemu gotowi są tyle poświęcić dla tworzenia gier.

Niniejsza książka podzielona jest na dziesięć rozdziałów, a każdy opowiada historię powstania innej gry. W jednym z nich odwiedzam Irvine w Kalifornii, żeby przeanalizować, jak ufundowana przy pomocy zrzutki na Kickstarterze gra „Pillars of Eternity” pomogła Obsidian Entertainment przetrwać najmroczniejsze czasy. W innym jadę do Seattle w stanie Waszyngton, gdzie dwudziestoparoletni Eric Barone spędził niemal pięć lat, pracując samotnie nad wyciszoną grą farmerską, której nadał tytuł „Stardew Valley”. Pozostałe opowiadają między innymi o technicznych koszmarach prześladujących ekipę od „Dragon Age: Inkwizycji”, wycieńczającym crunchu przy „Uncharted 4” i tajemnicy otaczającej wyczekiwane „Star Wars 1313” od LucasArts.

Czytając, możecie odnieść wrażenie, że historie te to anomalie, że opisuję gry, których produkcję naznaczyły kłopoty związane z nagłymi zmianami technicznymi, wymianą kadry kierowniczej albo innymi nieprzewidywalnymi zdarzeniami losowymi, na które developerzy nie mieli wpływu. Podczas lektury można by pomyśleć, że wszystkie te gry powstawały w nienaturalnych jak na tę branżę okolicznościach, że twórcy mieli po prostu ogromnego pecha, że pewnie udałoby się im uporać z trudnościami, gdyby tylko stosowali się do obowiązujących standardów i omijali powszechnie znane przeszkody lub od samego początku podejmowali mądrzejsze decyzje.

Oto jednak alternatywna teoria: każdy tytuł powstaje w osobliwych okolicznościach. Gry z natury rozpięte są pomiędzy sztuką a techniką w sposób, który kilkadziesiąt lat temu był ledwie możliwy. Jeśli powiążemy dynamiczny rozwój sprzętu i oprogramowania z tym, że obecnie bawimy się zarówno przy dwuwymiarowej łamigłówce na iPhonie, jak i przy rozległym RPG z otwartym światem i niemalże realistyczną grafiką, nie powinno nas dziwić, że nie istnieją zuniformizowane standardy produkcji gier. Duża ich część może i wygląda podobnie, ale każda z nich została wykonana w zupełnie inny sposób, o czym przekonacie się, gdy będziecie czytać tę książkę.

Ale czemu tak trudno robi się gry? Jeśli tak jak ja nigdy nie próbowaliście swoich sił przy produkcji komercyjnego tytułu, być może poniższe teorie okażą się pomocne w zrozumieniu tego fenomenu.

1 Gry są interaktywne. Nie biegną w jednym wyznaczonym odgórnie kierunku. W przeciwieństwie do – dajmy na to – renderowanych na komputerze animacji Pixara grafika jest generowana w „czasie rzeczywistym” i nowe obrazy wyświetlane są przez komputer co milisekundę. Gry reagują na ruchy gracza. A film Toy Story nie. Kiedy gracie, PC lub konsola (albo telefon) na bieżąco renderuje postacie i sceny, zależnie od podejmowanych przez ciebie decyzji. Jeśli wejdziecie do pomieszczenia, program dogra meble. Gdy zdecydujecie się zapisać stan gry i wyjść, musi zachować wasze dane. A jak uznacie, że chcecie załatwić pomocnego do tej pory robota, gra przetworzy, (a) czy jest to możliwe, (b) czy jesteście dostatecznie silni, aby to zrobić i (c) jaki paskudny dźwięk wyda z siebie rzeczony robot, kiedy wyprujecie mu metalowe flaki. Gra może również zapamiętać, co zrobiliście i napotkane później postacie będą wiedziały, że jesteście bezdusznymi mordercami i przywitają się słowami „Ej, to ty jesteś tym bezdusznym mordercą!”.

2 Technika się zmienia. Komputery ewoluują (są lepsze z roku na rok), a co za tym idzie, zwiększają się możliwości przetwarzania grafiki. A kiedy zwiększają się możliwości przetwarzania grafiki, otrzymujemy ładniejsze gry. Jak powiedział mi Feargus Urquhart, CEO studia Obsidian: „Znajdujemy się na krańcu postępu technicznego i stale przesuwamy granicę”. Urquhart podzielił się ze mną uwagą, że tworzenie gier jest jak kręcenie filmów, o ile przy każdym kolejnym projekcie trzeba by budować zupełnie nową kamerę. Nie jest to niecodzienna analogia. Inna mówi o budowaniu kamienicy podczas trzęsienia ziemi. Albo sterowaniu pociągiem, podczas gdy ktoś biegnie przed lokomotywą i na bieżąco kładzie tory.

3 Narzędzia nigdy nie są takie same. Aby tworzyć gry, artyści i designerzy muszą pracować z rozmaitym oprogramowaniem, od popularnego software’u (jak Photoshop czy Maya) po własne aplikacje, które różnią się w każdym studiu. Tak jak sama technika, narzędzia te nieustannie ewoluują zależnie od developerskich potrzeb i ambicji. Jeśli działają zbyt wolno albo nafaszerowane są błędami lub brakuje im kluczowych funkcji, praca nad grą może okazać się istną katorgą. „Ludzie myślą zwykle, że do stworzenia gry wystarczą świetne pomysły, kiedy tak naprawdę chodzi o umiejętność przeniesienia ich z papieru na produkt – powiedział mi kiedyś pewien developer. – A do tego potrzebujesz dobrego silnika i odpowiedniego zestawu narzędzi”.

4 Planowanie jest niemożliwe. „Nieprzewidywalność komplikuje całą sprawę” – tłumaczył mi Chris Rippy, weteran branży gier, który pracował przy „Halo Wars”[3]. Rippy wyjaśniał, że w procesie produkcji tradycyjnego oprogramowania można ustalić realny grafik na bazie analizy zrealizowanych zadań i czasu potrzebnego do ich wykonania. „Ale przy grach – ciągnął – mówimy o zapewnieniu komuś rozrywki. A co jest jej źródłem? Jak długo należy nad tym ślęczeć? Czy udało się uzyskać upragniony efekt? Czy jest on wystarczający? Chodzi o, dosłownie, stworzenie dzieła sztuki przez artystę. Jak ocenić, że jest ukończone? Czy jeszcze jeden dzień spędzony nad grą mógłby radykalnie ją odmienić? Kiedy należy skończyć ją szlifować? To złożona kwestia. Do właściwego etapu produkcji przechodzi się, gdy uznamy, że gra jest atrakcyjna i że dobrze wygląda, wtedy robi się trochę klarowniej. Lecz do tej pory poruszamy się po omacku”. Co prowadzi nas do…

5 Nie sposób powiedzieć, czy gra jest „fajna”, póki się w nią nie zagra. Można oczywiście pokusić się o popartą doświadczeniem i dowodami opinię, lecz dopóki nie chwyci się kontrolera, nie ma możliwości stwierdzić, jakie to uczucie ruszać się, skakać i rozbić dwuręcznym młotem metalowy łeb kumpla-robota. „Nawet bardzo doświadczeni designerzy nadal czują strach na samą myśl o tym” – powiedziała mi Emilia Schatz, projektantka z Naughty Dog[4]: „Każdy z nas znalazł się w sytuacji, kiedy włożył w coś naprawdę dużo pracy, a grało się koszmarnie. Można sobie rozrysowywać w głowie misterne plany, wyobrażać, jak gra będzie pięknie działać, a w końcu, gdy przychodzi co do czego, wszystko okazuje się nie tak”.

Opowieści zawarte w tej książce mają ze sobą pewne wspólne elementy. Każda z nich przynajmniej raz napotkała na swojej drodze opóźnienia. Każdy developer musiał iść na niemałe kompromisy. Każda firma głowiła się, jakiego sprzętu i technologii użyć. Każde studio rozplanowywało pracę tak, aby zdążyć na duże targi jak E3, gdzie developerzy mogą liczyć na motywację (a nawet opinie i komentarze) rozentuzjazmowanego tłumu graczy. I – co budzi bodaj największe kontrowersje – każdy, kto pracował nad tymi grami, musiał przeżyć „crunch”, czyli poświęcić życie osobiste i rodzinne na pracę, która – jak się wydawało – nie miała końca.

A jednak ludzie, którzy produkują gry, z reguły powtarzają, że nie mogliby robić czegoś innego. I kiedy opisują uczucie towarzyszące pracy z najnowszymi zdobyczami techniki, zapewnianiu interaktywnej rozrywki, jakiej nie dostarcza żadne inne medium, działaniu jako grupa licząca dziesiątki, a nawet i setki członków, aby stworzyć coś, w co zagrają miliony, ma się to niezachwiane poczucie, że mimo zawirowań, mimo crunchów, mimo piętrzących się, bzdurnych trudności, przez które często muszą się przedzierać developerzy, gry są tego wszystkiego warte.

Pomówmy jednak o waszym projekcie, tym o hydrauliku („Superprzygoda hydraulika”). Istnieją rozwiązania wszystkich waszych problemów, mimo że mogą się wam one nie podobać. Przykładowo, da się przyciąć budżet przez zlecenie części roboty przy animacji studiu z New Jersey. Może gra nie będzie wyglądała tak bajecznie, jak zakładaliście, ale zapłacicie aż o połowę mniej. Da się uprosić projektantów poziomów, aby dorzucili kilka platform i nie dawali aż tak w kość graczom, a jeśli się nie zgodzą, przypomnijcie im, że nie każdy lubi „Dark Souls”. Da się też pogadać z art directorem, aby nie męczył programistów, bo ci muszą się skupić na swojej robocie i nie mają czasu na wysłuchiwanie jego opinii na temat światłocienia w grach wideo.

Trudno będzie zdążyć na E3, lecz może uda się poprosić pracowników, aby przez parę tygodni zostawali po godzinach? Rzecz jasna nie dłużej niż dwa. Aby ich ugłaskać, zaproście ich na obiad, a może nawet zaproponujcie premie, jeśli gra otrzyma notę 90 na Metacritic.

Będziecie pewnie musieli wyrzucić niektóre bajery. Tak, wiem, były super. Przepraszam. Ale to nie tak, że wasz hydraulik musi koniecznie zmieniać się w szopa pracza. Zostawcie to na sequel.