Niezbędnik autora gier, część 3 

O ile pracując dla kogoś trzeba znać się na robocie i dogadywać się ze współpracownikami, o tyle pracując dla siebie trzeba znać się na robocie, dogadywać się ze współpracownikami, kierować pracami, organizować zasoby i dbać o wizję. Ten obszerny temat dzieli się z grubsza na zagadnienia produkcyjne i projektanckie. W dzisiejszym odcinku omówimy pierwsze z nich.

Przerywnik anegdotyczny: różnica między robić a zrobić Jestem projektantem gier komputerowych. Do tej pory robiłem siedem własnych gier. Zrobiłem cztery.

Ta, którą lubię najbardziej, zajęła mi już pół roku i jeszcze nie jest gotowa. Zabrałem się za nią z myślą o pewnym konkursie, w którym ostatecznie nie wziąłem udziału. Robię ją tak jak trzeba: ostrożnie, ambitnie i eksperymentalnie. Minęło pół roku, a ja mam tylko wstępny prototyp.

Gra, którą ukończyłem najszybciej, a która przy okazji była najlepszą i najbardziej rozbudowaną z moich produkcji, zajęła mi trzy dni w przedostatnim tygodniu piątego semestru studiów. Prowadzący laboratorium narzucił temat: każdy student miał zbudować klon istniejącej gry. Mój program udawał ośmiobitowy przebój pt. „Defender”, a tak naprawdę miał dowodzić mojej wprawy w obsłudze wątków w pewnym języku programowania. W ciągu trzech dni nauczyłem się języka od podstaw, po czym zmontowałem trzy rodzaje przeciwników o różnych zachowaniach, tabelę najlepszych wyników, a nawet wektorowy font własnego projektu.

Wszystkie cztery gry, które zrobiłem, powstały przy okazji czegoś innego. Żadnej z nich już nie mam, ponieważ nie byłem z nich zadowolony. Pozostałe trzy stanowiły cel sam w sobie. Jedną gdzieś posiałem nie ukończywszy, a dwie wciąż robię.

Morał:

• Jeżeli pasjonuje Cię robienie gier, to możesz pozwolić sobie na sztukę dla Sztuki - ale z dużym prawdopodobieństwem Twoja gra nigdy nie powstanie
• Jeżeli jednak zależy Ci na tym, żeby mieć coś zrobione, buduj grę w jakimś konkretnym, mierzalnym celu, na przykład obiecaj ją komuś w prezencie urodzinowym, albo uczyń ją swoim głównym źródłem dochodu

Zdecydowanie warto budować gry ostrożnie, ambitnie i eksperymentalnie. Jednak w ostrożności, ambicji i eksperymentach łatwo się zagubić, gdy brakuje bodźca zachęcającego do ukończenia prac w określonym terminie.

Wizja, czyli cel plus konsekwencja Zdecydowana większość niekomercyjnych gier nie została nigdy ukończona, ponieważ autorom zabrakło poczucia, że ich wysiłek czemuś służy.

Potocznie nazywa się to zjawisko „słomianym zapałem”, a jako źródło wskazuje się lenistwo. Tak naprawdę ludzie przede wszystkim nie lubią działać bez powodu. Wizję tworzy się po to, by zaistniał związek między odległym celem (zróbmy grę o żyrafach!) a bieżącymi zadaniami (narysuj mi żyrafę!).

Wizja to jedyne zadanie, którego, jako autor, nie możesz oddelegować. Co prawda jedną z najrozsądniejszych decyzji, jakie możesz podjąć, jest zasięgnięcie rady współpracowników. Tylko idiota łudzi się, że wie wszystko najlepiej, a odmawia głosu osobom, od których oczekuje, że poświęcą jego grze swój czas i wysiłek. Z drugiej strony, im mniej osób podejmuje ostateczne decyzje na temat wizji, tym lepiej dla niej, ponieważ jej głównym atrybutem jest spójność.

Według najczęściej stosowanej definicji wizja to dogłębne, intuicyjne zrozumienie, o co tak naprawdę chodzi w danym utworze. Masz wizję wtedy, gdy dowolna osoba może obudzić Cię w środku nocy i przedstawić dowolny pomysł, a Ty umiesz od ręki powiedzieć, czy ów pasuje do Twojej gry, czy też nie.

W praktyce nie wystarcza, że ma się wizję w głowie, bo trzeba ją jeszcze zakomunikować współpracownikom i odbiorcom. Pomaga w tym udzielenie odpowiedzi na kilka ustandaryzowanych pytań. Poniższa lista jest subiektywna - nie istnieje obowiązujący kanon.

1. Jaki jest Twój elevator pitch? Elevator pitch to opis całego utworu skompresowany do krótkiego zdania - pięć do dziesięciu słów. Wygłaszasz go za każdym razem, gdy ktoś pyta, o czym będzie Twoja gra. W idealnym przypadku budzi zainteresowanie: „ach tak? to ciekawe, powiedz mi więcej”.
2. Kim jest najbardziej typowy odbiorca? Gra nie może być dla każdego: emerytowane nauczycielki rosyjskiego prawdopodobnie mają nieco inne upodobania niż uczniowie technikum samochodowego. Kogoś trzeba sobie wybrać. Szczególny przypadek to odpowiedź „robię grę, w którą chcę zagrać”. Jest całkiem dobra, jeśli nie przeszkadza Ci, że kierujesz grę do ludzi dokładnie takich samych jak Ty i nikogo poza tym. W każdym razie, podejmując później konkretne decyzje, zawsze pamiętaj, że efekt końcowy ma się podobać Twojemu typowemu odbiorcy.
3. Co zyskasz na stworzeniu tej gry? Grę można robić z różnych pobudek: dla pieniędzy, dla sławy, dla szczytnego celu i tak dalej. Wszystkie są jednakowo skuteczne, pod warunkiem że się jest szczerym z samym sobą i ze współpracownikami. Najważniejsze jest to, że w ogóle wiesz, czego chcesz i że Cię to ekscytuje.
4. Co gracze będą z tego mieli? Inaczej mówiąc: jakie wrażenia zamierzasz im zaproponować? Podobnie jak w poprzednim pytaniu, Twój wybór jest arbitralny. Gorzkie wzruszenia są równie dobre co radocha z rozpierduchy, intelektualny namysł, czy też satysfakcja z przezwyciężenia trudności. Co najwyżej niektóre z tych rzeczy są bardziej niszowe niż inne. Najważniejsze jest to, żeby zdecydować się na coś konkretnego: Twoja gra może być jakakolwiek, ale musi być jakaś.
5. Jaki jest „klimat” gry? Klimat to coś w rodzaju konstytucji: kieruje tworzeniem pozostałych reguł. Na przykład w pewnej grze, przy której kiedyś pracowałem, nadrzędną zasadą była „zajebista rozpierducha”. Właśnie taka: nie duża, nie fajna, nie imponująca, tylko „zajebista”. Mieliśmy w tej grze broń, która do niczego się specjalnie nie przydawała poza tym, że roztaczała aurę „zajebistości” - a więc pasowała. Na ogół klimat składa się z trzech do pięciu zasad tego rodzaju.

Analiza wymagań, wersja uproszczona Gdy wiesz, jaką grę chcesz stworzyć, masz dobre podstawy do ustalenia, kto i co będzie Ci potrzebne. W skrajnym przypadku budujesz od zera i taki właśnie będzie nasz punkt wyjścia. Zaczniemy od sporządzenia listy umiejętności potrzebnych do wykonania danej gry, po czym omówimy podstawowe sposoby na zaoszczędzenie wysiłku.

W miarę kompletną listę najczęściej spotykanych zawodów zamieściłem we wcześniejszym odcinku. Minimalny zestaw liczy trzy pozycje:

• Projektant wyzwań, inaczej level designer, wymyśla rozgrywkę, opierając się na już istniejących regułach (na przykład opracowuje problemy szachowe)
• Programista „gejmplejowiec” przekłada reguły gry na program komputerowy
• Tester sprawdza, czy rezultaty zgadzają się z zamierzeniami

Takie umiejętności wystarczają do stworzenia podróbki już istniejącej gry, o ile nie zamierzasz wyposażać jej w oryginalną grafikę, dźwięk lub fabułę. Wbrew pozorom jest to możliwe bez naruszania praw autorskich. Taka gra będzie mało ambitna, ale za to łatwa do ogarnięcia.

W planie minimum potrzebne są tylko podstawowe umiejętności w każdym z zawodów, więc możesz osobiście podjąć się wszystkich trzech ról. To bardzo dobra opcja na samym początku, gdy gra jeszcze nie istnieje i trudno przekonać innych, by Ci pomogli. Gdy dzieło nabiera kształtów, warto oddelegować co najmniej zadania testera, ponieważ autor gry, czyli Ty, popełnia błędy tak samo jak każdy. Wytknięcie ich leży w Twoim interesie.

Choć plan minimum znakomicie nadaje się do nauki, ignorowanie kwestii twórczych jest bardzo złym nawykiem, którego później trudno się pozbyć. W ramach rozsądnego kompromisu proponuję, by Twoja pierwsza gra była podróbką czegoś prostego, co bardzo lubisz i dobrze znasz, ale zawierała jedną, znaczącą zmianę reguł. Na przykład mogłyby to być szachy z nową figurą, Tetris z klockami o odmiennych kształtach, albo platformówka, w której nie ma przeszkadzajek raniących bohatera za dotknięciem.

Jeżeli zdecydujesz się na wykorzystanie własnych zasad, trzeba do listy dopisać czwartą rolę: projektanta reguł, czyli game designera.

Gra z własną grafiką potrzebuje co najmniej rysownika koncepcyjnego. W przypadku gier 2D staje się on rysownikiem bez przymiotnika, tworzącym wystrój gry. Przy grach trójwymiarowych jest więcej pracy i większa specjalizacja: potrzebujesz modelarzy, teksturzystów i tak dalej. Jeśli w grze mają występować obiekty animowane, to znaczy wykonujące bardziej skomplikowane ruchy niż przesunięcie, skalowanie lub obrót, dodaj do listy animatora 2D lub 3D.

Podobne rozumowanie dotyczy dźwięku, muzyki i fabuły. Zwróć uwagę, że dialogi mogą być wyświetlane na ekranie bądź wygłaszane przez lektorów.

Każda gra opiera się na technologii: trzeba wyświetlić obraz, odtworzyć dźwięki, pobrać od gracza sterowanie, podjąć decyzje w imieniu przeciwników i tak dalej. Zajmują się tym przede wszystkim programiści odpowiednich specjalności.

W ten sposób można szybko uzyskać bardzo długą listę. Warto poważnie się zastanowić, czy wszystkie rzeczy, które chcesz mieć grze, są w niej naprawdę potrzebne. Czy przedsięwzięcie straci sens, jeśli zastąpisz trzy wymiary dwoma? Czy ktoś się obrazi za brak muzyki?

Najwięcej okazji do oszczędności dają zwykle reguły rozgrywki. Warto myśleć w małej skali, na przykład wymyślić grę albo o strzelaniu, albo o jeździe samochodem, albo o dylematach moralnych - ale nie o każdej z tych rzeczy na raz. Internet to cmentarzysko nieukończonych, amatorskich gier MMO i Symulatorów Wszystkiego Jak Leci.

Każda rzecz, z której rezygnujesz na tym etapie, zwiększa Twoje szanse na sukces. Zostaw tylko to, co absolutnie niezbędne.

Engine Wykorzystanie cudzego dorobku nie przynosi uszczerbku na honorze, dopóki nie naruszasz praw autorskich.

Zapomnij o budowaniu gry od zera. Pół biedy, że to jest trudne - być może jesteś programistą i umiesz robić takie rzeczy. To jest przede wszystkim zbędne. Umówiliśmy się, że chcesz zbudować grę, a nie technologię.

Engine to część programu wspólna dla wielu gier, nawet bardzo odmiennych. Na przykład każda gra musi zniżyć się do przyziemnej czynności wyświetlania swoich treści na ekranie. Musi też odczytywać sygnały z jakiegoś urządzenia wejściowego, takiego jak klawiatura, mysz lub gamepad. Gdyby nie engine'y, w każdym zespole budującym grę musiałby być programista „techowiec” odpowiedzialny za tego typu zadania. Gotowe pakiety pozwalają skorzystać z pracy, którą ktoś już kiedyś wykonał.

Im lepszy engine, tym bardziej przezroczysty, to znaczy: fakt, że go używasz, nie ogranicza Twojej swobody twórczej. W praktyce każdy pakiet do jednych gier nadaje się lepiej niż do innych. Na szczęście żyjemy w pięknych czasach, w których istnieją legalne i darmowe (lub bardzo tanie) wersje profesjonalnych (i amatorskich) narzędzi. Masz wybór.

Jeszcze bardziej „oszczędnościową” opcją jest zaniechanie autorstwa całej gry na rzecz stworzenia modyfikacji lub misji do już istniejącego przeboju. Dla wielu gier na peceta istnieją ogólnodostępne i stosunkowo łatwe w obsłudze edytory. Wielu zawodowców (w tym ja) zaczynało od zabawy takimi narzędziami.

Zamienniki i gotowce Tak jak engine dostarcza technologię, odciążając programistów, tak zamienniki i gotowce pozwalają okiełznać prezentację przy mniejszym wysiłku artystów.

Byłoby to nikczemnym nadużyciem, gdybym zasugerował, że grafika, dźwięk lub fabuła są nieważne. Jednak budowa gry wymaga od autora wyzwolenia się od podejścia, do którego przyzwyczaił się jako odbiorca. Grając mamy skłonność do podziwiania w pierwszej kolejności prezentacji. Dopiero potem odkrywamy, czy się dobrze bawimy, a na samym końcu - o ile w ogóle - przyglądamy się regułom gry. Autor rozumuje w przeciwnym kierunku: najpierw sprawia, że gra działa, potem usprawnia ją tak, by była satysfakcjonująca, a dopiero na końcu - o ile w ogóle - zwraca uwagę na dekoracje (goście od Minecrafta nie zwrócili). Praktyka często nie pozwala na taki porządek pracy, ale nie warto unikać takiego porządku myślenia.

Powiedzmy, że chcemy zrobić grę o żyrafach. Tworząc reguły opisujące poruszanie się żyraf i interakcje z nimi potrzebujemy czegoś, co będzie je reprezentowało. Dla naszych roboczych potrzeb to coś nie musi wcale przypominać zwierzęcia. Wystarczy prosty znak mówiący: „tu kiedyś wstawimy żyrafę”.

To są właśnie tak zwane placeholdery, czyli zamienniki. Dobry zamiennik to taki, który wymaga minimalnego wysiłku i nie angażuje fachowca. Prostopadłościan z napisem „żyrafa” jest w sam raz.

Z produkcyjnego punktu widzenia znaczenie zamienników polega na tym, że choć kiedyś faktycznie będzie trzeba tę żyrafę zamówić u prawdziwego grafika, to dzisiaj obywamy się bez niej, czyli po prostu nie musimy na nią czekać - być może nawet kilka tygodni. Dzięki temu wstępne prace idą znacznie szybciej. Co więcej, jeśli zmienimy zdanie i postanowimy zrobić grę o pingwinach, to taka decyzja nic nas nie kosztuje, bo żyrafa jeszcze nie została zamówiona.

Dla początkującego autora ważne jest także to, że jeśli przedstawisz artyście działającą, ale brzydką grę, to za jednym zamachem udowodnisz, na co Cię stać i pokażesz, w jaki sposób pomoc fachowca ulepszy Twoje dzieło. To ułatwi Ci negocjacje.

Stworzywszy działający prototyp z zamiennikami możesz sporządzić listę potrzebnych rysunków, modeli 3D, dźwięków i tak dalej, a następnie całkiem dosłownie udać się na zakupy. W Sieci jest mnóstwo gotowców - ktoś już przed Tobą narysował i żyrafę, i pingwina, i czołg, i tak dalej. Niektóre z nich są na sprzedaż. Większości nie możesz wykorzystać, ale przydadzą się jako tak zwane (żargonowo) referencje, czyli wskazówki dla artystów: „chcę, żeby nasza żyrafa wyglądała i brzmiała podobnie jak na tym filmie”.

Istnieje prężny, profesjonalny rynek tanich motywów muzycznych i dźwięków, które możesz wykorzystać w swojej grze, jeżeli nie jest Ci potrzebna wyłączność na nie.

Niestety nawet po okrojeniu listy koniecznych umiejętności wciąż może znajdować się na niej kilka rzeczy, których nie umiesz zrobić. To dobry moment na rozejrzenie się za współpracownikami.

Przerywnik anegdotyczny: „Fallout 2” PL Dziesięć lat temu polskie wersje językowe nie były standardem i często do niczego się nie nadawały. „Fallout 2”, jedna z moich ulubionych gier z tamtego okresu, nie miała oficjalnego przekładu.

Wśród wielu ciekawych ludzi, których spotkałem w Sieci, byli tacy, którym ów brak przeszkadzał. Jeden z nich podjął się zorganizowania amatorskiego zespołu tłumaczy. Zgłosiło się do niego około pięćdziesięciu osób, w tym ja.

Kilka rzeczy zrobiliśmy dobrze. Mieliśmy jasny cel, a organizator od początku pilnie śledził podział zadań. Kiedy prosiło się go o tekst do przetłumaczenia, od ręki dostawało się materiały. Nie pamiętam, żeby kiedykolwiek różne osoby dostały do zrobienia tę samą rzecz.

Mieliśmy własną listę dyskusyjną, na której debatowaliśmy nad terminologią. Organizator nie próbował mikrozarządzać. Sam posługiwał się angielskim nie tak dobrze jak rosyjskim, ale w grupie szybko ujawnili się godni zaufania znawcy języka. Uniknęliśmy „walki o władzę”, ponieważ organizator był sympatycznym, ale asertywnym człowiekiem i dbał o przyjazną, ale rzeczową atmosferę. Mimo to czasami na liście dyskusyjnej panował straszny harmider - było nas za dużo.

Popełniliśmy też kilka błędów. Po pierwsze: spośród owych 50 osób tylko 5-6 znało angielski wystarczająco dobrze, by tłumaczyć na przyzwoitym poziomie. Teksty pozostałych trzeba było przełożyć od nowa. Po drugie: nie śledziliśmy naszych postępów, nie wiedzieliśmy, ile nam jeszcze zostało do zrobienia i nie wyznaczaliśmy sobie celów pośrednich. Dość szybko zespół skurczył się do czterech osób, ponieważ pozostałym zabrakło zapału. Po trzecie: zignorowaliśmy trudność techniczną, na którą natknęliśmy się na samym początku. Gra nie dysponowała polskimi literami, a my, zamiast znaleźć sposób na uzupełnienie jej, pomijaliśmy ogonki w przetłumaczonych tekstach. Później udało nam się nawiązać kontakt z entuzjastami z Czech, którzy robili rzecz podobną do naszej i napisali odpowiedni program. Podzielili się nim - ale my mieliśmy już przetłumaczone kilkaset stron tekstu bez ogonków, które teraz trzeba było uważnie przeczytać i skorygować. Wiele literówek przegapiliśmy.

Udało nam się doprowadzić do wydania oficjalnej polskiej wersji językowej. Nasze częściowe rezultaty, obejmujące około połowy gry, zostały włączone do przekładu. Dokonanie tego zajęło nam ponad dwa lata. Profesjonalny zespół na naszym miejscu wyrobiłby się z całą grą w trzy-cztery miesiące.

Współpracownicy to skarb Nie da się w jednym, pobieżnym poradniku streścić całego zagadnienia pod tytułem „jak pozyskać i nie stracić współpracowników”. Niemniej warto znać pewną liczbę prostych zasad. Przytoczona przed chwilą anegdota ilustruje większość z nich:

• Twój zespół pracuje z Tobą dlatego, że chce, a nie dlatego, że powinien. Różnica polega na tym, że zawsze można przestać chcieć.
• Pieniądze nie motywują. Pieniądze jedynie uwalniają od konieczności zdobycia ich skądinąd.
• Szukaj ludzi, którym możesz zaoferować coś, co ich ekscytuje. Nie każdego ekscytuje to samo.
• Nie pytaj ludzi, czy są świetni. Zapytaj siebie, czy dany człowiek świetnie przyda Ci się do czegoś konkretnego. Brak zadań deprymuje szybciej niż nadmiar.
• Pracuj z ludźmi, z którymi się dogadujesz. Dogaduj się z ludźmi, z którymi pracujesz. Nie ma udanej, twórczej pracy zespołowej bez dogadywania się.
• Im większy zespół, tym większe trudności komunikacyjne. Rosną one szybciej niż ilość pracy, którą może wykonać zespół dzięki przyjmowaniu nowych członków. Szukaj ludzi, którzy będą dobrze pasować, tak żeby było z nimi mało trudności.
• Gdy jakość lub wydajność czyjejś pracy spada, zawsze istnieje ku temu ważny powód. Prawie nigdy nie jest nim zła wola.
• Jeżeli ktoś wykonuje swoje zadania inaczej niż tego oczekujesz, to znaczy, że źle formułujesz swoje oczekiwania.
• Ignorowanie problemów jest jak zaciąganie długów na wysoki procent. Rozwiązywanie ich z opóźnieniem kosztuje znacznie więcej niż jeśli zrobisz to od razu.
• Skoro nie masz dość czasu lub umiejętności, by wykonać zadanie samodzielnie, to nie masz dość czasu lub umiejętności, by stać nad głową współpracownika i dyrygować. Pozwól ludziom działać po swojemu.
• To Ty odpowiadasz za to, żeby współpracownicy mieli jasno postawiony cel i zadania, żeby wiedzieli, jak im idzie i żeby znali Twoją wizję.

Skąd wziąć współpracowników Poszukać w Sieci. Budowanie gier to takie samo hobby jak każde inne. Są strony i fora o tym. Poguglaj. Znajdź fajną społeczność. Daj się poznać z dobrej strony. Pomóż innym zrobić ich gry.

Biegła, czynna znajomość angielskiego bardzo pomaga.

Powierzanie ważnych zadań komuś obcemu jest rosyjską ruletką. Ponadto we współpracy amatorskiej lub na odległość zwykle trzeba się liczyć z dużymi opóźnieniami. Dlatego krytyczne zadania, to znaczy takie, które mogą zatrzymać całe przedsięwzięcie, lepiej albo wykonać samodzielnie, albo powierzyć komuś, kogo dobrze znasz - a najlepiej komuś, z kim mieszkasz, uczysz się, bądź pracujesz.

W praktyce najpilniejsze są zadania z początku przedsięwzięcia, czyli to, jak gra działa i to, czy daje satysfakcję. Innymi słowy: zadania programistyczne i projektanckie. Jeżeli czujesz się na siłach, by własnoręcznie zaprojektować i/lub zaprogramować swoją grę, Twoje szanse na sukces rosną drastycznie.

Twórczość kontra rzeczywistość Stanem pożądanym jest sytuacja, w której każda pozycja na Twojej liście potrzebnych umiejętności zalicza się do którejś z następujących kategorii:

• Rzeczy, które zrobisz samodzielnie
• Rzeczy, których na razie nie musisz robić
• Rzeczy, które możesz uczciwie nabyć
• Rzeczy, które zrobi za Ciebie konkretna osoba

Jeśli tak jest, to możesz zabierać się do pracy. Jeżeli jednak choć jednej umiejętności na liście potrzebujesz od zaraz, a nie masz skąd jej wziąć, to niestety Twoje plany są zbyt ambitne i wymagają okrojenia. Przyjrzyj się wizji i usuń z niej te elementy, które narzucają nadmiarowe wymagania.

W następnym odcinku zajmiemy się wyzwaniami związanymi z projektowaniem gry i uczeniem się tego zawodu na własną rękę.

Jacek Wesołowski

Przeczytaj też:

• Pierwsza część poradnika
• Druga część poradnika

Tekst oryginalnie pojawił się na blogu Inżynieria Wszechświetności. Republikacja za zgodą autora.