Andrew Wilson (EA), Phil Spencer (Microsoft) i Hiroki Totoki (Sony), mówią jednym głosem: „Musimy tworzyć gry szybciej i taniej”. Niezależnie jednak od skali projektu i doświadczenia zespołu, wszyscy w branży mamy z tym problem… Dlaczego? – wyjaśnia Grzegorz Wątroba

Pomijając anomalie w rodzaju tworzonego od jedenastu lat Star Citizena, czy kosztującego ponoć dwa miliardy dolarów GTA VI, z reguły:

• Gry AAA powstają przez ponad pięć lat, a ich budżety idą w setki milionów dolarów.
• Gry AA powstają ok. trzech-czterech lat, a ich budżety idą w dziesiątki milionów dolarów.
• Gry indie powstają przez rok lub dwa, a ich budżety idą w miliony dolarów.

Każdy dodatkowy miesiąc pracy kosztuje, czemu szefostwo próbuje zaradzić na, niekiedy, krótkowzroczne sposoby, np. zwalniając ludzi albo kasując gorzej rokujące projekty… Ale może nie tędy droga?

Podstawy

Koledzy i koleżanki z gamedevu mogą sobie poniższe akapity odpuścić, reszcie natomiast wytłumaczmy, że tworzenie gry zaczyna się od IDEACJI: burzy mózgów, pomysły z której przelewamy na papier. W bardzo wąskim gronie powstaje na ich bazie Game Design Document lub Game Design Overview. To filar opisujący podstawowe założenia, referencje, grupę docelową, zarys technologiczny… Słowem: wszystko to, co składa się na wizję gry. Dodajmy, że ideacja powinna być w miarę krótka (w przypadku zespołu indie – trwać ok. miesiąc).

Na etapie PREPRODUKCJI nieco większy zespół tworzy na podstawie dokumentacji prototyp. W krótkich cyklach projektujemy zręby mechanik, budujemy bazę technologiczną, nadajemy kierunek artystyczny i np. przygotowujemy szkice poziomów. No i iterujemy: sprawdzamy, co działa, a co nie, testujemy nowe rozwiązania, a te nietrafione poprawiamy lub odrzucamy. Pierwszym efektem powinien być tzw. proof of concept, dowód, że nasza wizja sprawdza się w praktyce. Kolejnym: vertical slice, „wycinek” prezentujący przekrój mechanik. Gdzieś po drodze może powstać beauty corner, dopieszczony graficznie, drobny fragment builda, który ma reprezentować docelową oprawę.

W ramach PRODUKCJI prototypy muszą zmienić się w finalne mechaniki, a build – przejść podstawowe optymalizacje. Plany produkcyjne powinny być ustalone, zaś ewentualne modyfikacje obejmować jedynie wycinanie zawartości. Z prozaicznej zresztą przyczyny: w tym momencie zespół działa już pełną parą (i w pełnym składzie), co sprawia, że produkcja jest absolutnie najdroższym stadium tworzenia gier. Kończy się ona wersją alpha oraz beta, które mogą trafić na Steama w ramach early accesssu.

Ostatnie tygodnie lub miesiące przeznaczamy na FINALIZACJĘ. Gra osiąga status code & content freeze – nic do niej nie dodajemy, zamiast tego testując i poprawiając błędy. Jeśli jest ona dystrybuowana na fizycznych nośnikach – wysyłamy płytę do tłoczni, skupiając siły na day one patchu. Po wydaniu mniejsza część zespołu zajmuje się POSTPRODUKCJĄ, czyli pracą nad aktualizacjami, DLC albo eventami, większa rusza natomiast do nowego projektu.

Teoretycznie tak właśnie tworzy się gry… W praktyce: nic bardziej mylnego!

Przyczyny

Najczęstszą przyczyną wydłużania się prac jest niewłaściwe podejście do pierwszych etapów produkcji. W swojej karierze napotkałem na gry, w których ideacja była dziełem jednej osoby (ta zazwyczaj nie tylko swoich pomysłów nie kontrowała, ale nawet z nikim nie konsultowała!). Albo na takie, których design doc okazywał się niekompletny, a preprodukcja była na tyle krótka, że w jej toku nie udało się nawet określić wszystkich założeń projektu!

Chaos sprawia, że poszczególne elementy gry nie współgrają ze sobą, o czym zespół dowiaduje się za późno, nierzadko wracając wówczas do deski kreślarskiej. By załatać luki, stawia się na tzw. dynamiczny design, a więc nagłą zmianę wizji, ewentualnie dodawanie do builda coraz to nowych elementów. Każda taka korekta wpływa na pozostałe elementy układanki, które trzeba do niej dostosować; przypomina to próbę naprawy silnika samochodu w trakcie jazdy.

Na marginesie: nie zawsze jest to wina developera. Czasem wydawca wykazuje się iście ułańską fantazją, przez co w studiu zdecydowanie przybywa siwych włosów i opakowań po energetykach.

Konsekwencje

Brak refleksji nad rozplanowaniem projektu sprawia, że tracimy czas, a tym samym marnujemy pieniądze. Tymczasem inwestor może stwierdzić, że nie ma środków na wydłużenie prac, a wydawca obwarować umowę karami finansowymi za przekroczenie milestone’ów. Bywa, że okazuję się one gwoździem do trumny bądź dla projektu, bądź nawet dla studia.

By tego uniknąć, crunchujemy, jednak pracując po kilkanaście godzin dziennie łatwo o błędy, przeoczenia i frustrację. Nawet, jeśli taki projekt uda się „dowieźć”, jego premiera może zaowocować wypaleniem pracowników, a w konsekwencji ich odejściem z firmy (lub nawet z branży!). Oczywiście zapieprz znajduje także odzwierciedlenie w stanie technicznym builda.

Na domiar złego gry mają często sztywne budżety, stąd część pieniędzy, które planowaliśmy przeznaczyć na marketing, ostatecznie przekierowujemy na wydłużenie produkcji. A to błąd, bo na rynku zrobiło się tłoczniej niż kiedykolwiek, zaś mit o tym, że „dobra gra sama się obroni” można włożyć między bajki. Możemy więc skończyć z niedopracowanym, niespójnym tytułem, o którym nikt nie słyszał i który nie spełnia danych graczom obietnic (na co część z nich zareaguje hejtem i personalnymi wycieczkami, dobijając psychicznie wyczerpany zespół).

Trzeba mieć też na uwadze, że im większe studio, tym więcej czasu spędza ono na komunikacji. Rozsądne firmy delegują odpowiedzialność za nią na liderów działów, producentów i kadrę zarządzającą, by reszta pracowników nie musiała myśleć o „szerokim horyzoncie” projektu, zamiast tego skupiając się na realizacji jasno określonych zadań. Na rynku jest wiele publikacji o tym, jak powiększać studio, nie tracąc produktywności, a jedną z najciekawszych stanowi artykuł Łukasza Hacury (Anshar Studios) „Decade of game dev studio evolution — lessons learned”. Polecam po niego sięgnąć (jest dostępny pod tym adresem).

Iteracje?

Odpowiednie planowanie oraz prowadzenie dokumentacji stanowią klucz do sukcesu. Ideacja, w której od razu zweryfikujemy część pomysłów, a całość sformalizujemy w koherentną formę, daje właściwy fundament do dalszego tworzenia.

Zapoznając się z materiałami od japońskich developerów, zauważam pewną prawidłowość: wszyscy oni wskazują na potrzebę długiej preprodukcji. Przykładowo autorzy gier z Mario radzą, by trwała ona aż kilkanaście miesięcy (!), za to w małym, kompetentnym zespole. Trudno się z tym nie zgodzić. Przez spędzone w branży lata złapałem kontakt z wieloma polskimi i zagranicznymi teamami i widzę, że te, które poświęcą chwilę na domknięcie wizji, której następnie konsekwentnie się jej trzymają – przygotowują swoje gry szybciej i taniej.

A już na pewno szybciej i taniej, niż gdyby cały zespół miał na bieżąco „docierać” jej wizję lub (o, zgrozo!) zmieniać ją w trakcie pracy. Twierdzenie, że przecież „cała produkcja jest iteracyjna” to błąd. Na pewnym etapie należy zaakceptować, że czas na nowe pomysły minął. Liderzy projektu muszą za to poświęcić czas na rzetelne dokumentowanie postępów oraz komunikację: i tę we własnym gronie, i tę z szeregowymi pracownikami.

Wnioski

Musimy zmienić nasze myślenie o zarządzaniu czasem. Szefostwo twierdzi niekiedy, że szkoda czasu na kompleksową dokumentację, spotkania 1 na 1, retrospektywy, rozmowy mające dotrzeć wizję projektu… Za naturalne przyjmują natomiast długie godziny, jakie projektant, artysta czy programista spędzają później na callach, podczas których ustalają szczegóły, które już dawno powinny być dograne. Świadom jestem natomiast, że długa preprodukcja wydłuża okres w którym gra jest, delikatnie mówiąc, nieatrakcyjna. Może być to barierą nie do przejścia dla inwestora, który nie zna się na tworzeniu branży, a oczekuje szybkich wyników.

Tworzenie gier jest trudne, rynek bywa kapryśny, a zaufanie odbiorców łatwo stracić. Nie znaczy to, że nie możemy zrobić nic, by ten proces usprawnić, mało tego: większość opisywanych powyżej zmian to przecież kwestia odrobiny dobrej woli. Naprawdę da się robić gry szybciej i taniej, nie poświęcając ich jakości. Życzyłbym sobie – i jako developer, i jako gracz – by tak właśnie było.