Jak napisać Game Design Document


#1

English version: How to write Game Design Document

„Do czego potrzebny nam ten cały game design document?”, spyta młody, aspirujący twórca gier, lider zespołu. „Mamy pomysły w głowach, artyści rysują, kod rośnie… Na co ta biurokracja?”
I w ten sposób zaprasza do swojego procesu twórczego chaos, gościa, który może być tolerowany, jeśli wpadnie na chwilę i przewietrzy pomieszczenie, napełniając głowy nowymi, pozytywnie zakręconymi pomysłami. Jeśli jednak przybysz ten się rozgości… Lepiej zapobiec zawczasu jego wizycie za pomocą mądrych sposobów. I tak jak wielkie bale i imprezy posiadały listy gości, tak game development tworzy specjalny spis porządkujący rzeczywistość:

GAME DESIGN DOCUMENT

Game design document (w skrócie GDD) to plan gry, usystematyzowany zbiór wszystkich twórczych założeń i elementów gry w formie żywego (a więc wciąż edytowanego i rozwijanego) dokumentu. Wbrew pozorom nie należy tylko do działu – nomen omen – game designu. Zawiera opisy, wykresy, listy z definicjami, ilustracje itd. – wszystko powiązane z projektem. GDD wymienia elementy fabuły, rozgrywki, mechaniki, wizji graficznej oraz kodu i organizuje je, pokazując, jak mają ze sobą współpracować w celu uzyskania oczekiwanych przez zespół efektów. Ukazuje sedno całego projektu, umiejscawia go w odpowiednim kontekście i nadaje mu spójność dzięki ujednoliconej i czytelnej strukturze.

A jednak wielu game designerów nie zamierza prowadzić podobnej dokumentacji, co zazwyczaj kończy się zagubieniem w odmętach procesu developmentu. Oto klasyczny błąd przy zarządzaniu procesem tworzenia gry – zaniechanie zarządzania, czynione często z uśmiechem na twarzy…
„Robimy grę, kto ma czas na bzdury?”

Nie ma sensu walczyć z tymi przekonaniami za pomocą rozległych traktatów…

Oto dziewięć zwięzłych argumentów przemawiających za stworzeniem GDD:

1. Pamiętasz wszystkie błyskotliwe elementy projektu oraz to, co sprawiło, że pomysł przeszedł do realizacji. Nie gubisz w codziennym mozole niczego, a zwłaszcza tych elementów gry, które sprawią, że to właśnie wasz projekt zmieni porządek świata.
A skoro o tym mowa…
2. Zachowujesz porządek w dokumentach. Wszystko jest w jednym miejscu. Spis treści w GDD sprawia, że masz pod ręką rozpiskę wszystkich elementów, które mają się znaleźć w grze.
Spis treści ma też kolejną zaletę…
3. Masz pod ręką listę, na której możesz odhaczać kolejne punkty do zrobienia. Wiesz, jakie zadania są do wykonania i przez kogo. Wszyscy są na bieżąco, pracują równolegle i odznaczają kolejne etapy, przez co lepiej panujesz nad całym procesem.
Dzięki temu…
4. Dysponujesz wyznacznikiem objętości i „ambicjometrem”. Orientujesz się, jakimi siłami władacie i jakie wyzwanie stoi przed wami. O wiele łatwiej jesteś w stanie przyznać, że projekt może was przerosnąć.
A kiedy tak będzie…
5. Widzisz, z czego będzie trzeba zrezygnować. Tak, konkrety przydają się także przy smutnej konieczności cięcia projektu na kawałki i usuwania rzeczy zbędnych lub utrudniających proces tworzenia, pozostawiając listę najważniejszych elementów, wyeksponowanych w swych słabościach.
Przez to…
6. Uświadamiasz sobie wszystko, co zostało przeoczone i co należy dodać, by wzbogacić grę. A to ułatwi stworzenie kompletnego, udanego dzieła.
A jeśli dzieło dąży ku sukcesowi…
7. Masz dokument, który pozwala zaprezentować projekt jako całość. Możesz go ukazać potencjalnym (współ)pracownikom nawet wtedy, gdy gra nie jest jeszcze gotowa. Możesz z jego pomocą wprowadzić w projekt nowicjuszy. Możesz zwabić nim inwestorów. Orientujesz się dzięki niemu, co gra może zaoferować.
A w konsekwencji…
8. Wiesz, czego oczekiwać od osób, które mogą pomóc przy projekcie. Znasz wymagania, jakie powinni spełnić pracownicy, wiesz, ile rzeczywiście wymagać od inwestorów. Rzeczywistość zresztą bywa okrutna.
Zatem dobrze, że…
9. Dysponujesz pośrednikiem między wizją a rzeczywistością. Widzisz, czy osiągnąłeś to, czego chciałeś, wiedząc jednocześnie, czy świat jest gotowy to przyjąć.

GDD zwyczajowo sporządza się w uniwersalnym języku – po angielsku.
Przede wszystkim dlatego, że ułatwia to pracę na kodzie i oprogramowaniu oraz współpracę z międzynarodowym zespołem. Skoro zatem sporządzenie GDD jawi się już mniej jako mnożenie niepotrzebnej biurokracji, a bardziej jako zabieg właściwie niezbędny, warto wiedzieć, jak to zrobić, ale, hola! Jest jeszcze jedna ważna kwestia, którą trzeba poruszyć:

Kto właściwie powinien tworzyć GDD?
Zakładamy optymistyczny scenariusz: game designer wie, że GDD musi powstać. Ale nagle zrzuca to brzemię na inną osobę!
Dokument, tak? Skoro to tekst, niech zajmie się nim writer! Gra jest interaktywnym „przeżyciem” opartym w dużym stopniu na chłonięciu grafiki podczas poszukiwania ukrytych obiektów? Graficy spiszą GDD, oczywiście! Gra wymaga mnóstwo kodowania i jest programistycznym cudeńkiem? Niech GDD zrobi programista!
O ile ostatni przykład jest dość absurdalny, o tyle pierwszy (o czym niżej podpisany zaświadcza) zdarza się nader często. I jest to błąd, podobnie jak odwrotne założenie: „mamy tu grupę specjalistów, każdy zna się na swojej części, więc będą wiedzieć, co wrzucić do dokumentacji”. Może i tak będzie, ale dopiero po wprowadzeniu osób odpowiedzialnych za poszczególne elementy na właściwą drogę za pomocą jasnego i czytelnego szkieletu GDD będącego do ich dyspozycji. Jeśli kilka(naście) osób będzie pracowało równocześnie nad jednym GDD, rezultat będzie chaotyczny i niebezpieczny dla rosnącego projektu.
I choć sporządzenie takiego dokumentu jest wspólną odpowiedzialnością całego zespołu, GDD zaczyna się i kończy pod palcami (lead) game designera i to on jest najlepszym kandydatem na „strażnika GDD”. Oczywiście przedstawiciele innych działów są w stanie sporządzić taki dokument, ale zapewne zrobią to niedostatecznie dobrze i odwróci to ich uwagę od podstawowych obowiązków. Ich obowiązkiem powinno więc pozostać dokładanie własnych wyspecjalizowanych cegiełek do dokumentacji poprzez przekazywanie fragmentów w ręce strażnika. Game designer jest tym strażnikiem. Możliwość edycji GDD mogą jeszcze ewentualnie posiadać liderzy działów, reszta zespołu zaś – jedynie prawo wglądu i komentowania.
Strażnik GDD dźwiga na swych barkach sporą odpowiedzialność – musi dopilnować, by dokument był spójny, jasny i czytelny w odbiorze, pozbawiony przekłamań czy błędów. Mało istotne elementy trafią dzięki jego staraniom do głębiej osadzonych podpunktów, podczas gdy sprawy kluczowe będą rzucać się w oczy każdemu, kto do dokumentu zajrzy. Strażnik GDD czuwa nad realizacją poszczególnych elementów i zauważa niedostatki.
Ostatnią ważną kwestią, której strażnik powinien dopilnować, jest sprawa czysto ludzka: przyswajalność. Spójny język, czytelna szata graficzna oraz dopasowane ilustracje to mus, jeśli dokument ma służyć całemu zespołowi, a nie wybranym osobom. Legenda objaśniająca użyte kolory czy symbole – musi być. Wygodny w użyciu spis treści przenoszący po kliknięciu do wybranego miejsca – również.
Na deser, mała uwaga od writera, prosto z serca: długie fragmenty tekstu warto powierzyć korekcie komuś, kto jest za pan brat z regułami języka. Niech tylko jego trafia szlag na widok językowych potworków.

Jak zabrać się za pisanie GDD?

High Concept a GDD
Zapisanie formalnego high conceptu to początek ustabilizowanego procesu tworzenia gry. Pomysł pojawił się po raz pierwszy, a uzależnione od kawy serce zaczęło bić szybciej. Okazało się, że nikt wcześniej nie wpadł na to, by połączyć pewne dwa popularne koncepty w jedną całość. To będzie rewolucja! Następnego dnia rano gorączka ambicji traci trochę temperatury, podobnie jak znajdująca się na dnie kubka resztka późnowieczornej kawy. Chaotycznie zapisane pomysły lądują w pliku .txt i, bez marnowania czasu, rusza proces tworzenia! I już wkrótce wszystko zaczyna być co raz bardziej pogmatwane, wizje rozjeżdżają się, a ludzie nierzadko tracą do siebie szacunek. Level designer i grafik 2D zaczynają na siebie krzyczeć, programista rozdziela ich i uspokaja, a Ty, game designerze, nie potrafisz sobie przy tym wszystkim przypomnieć owej piątej specjalnej zdolności, jaką będzie miał bohater, bo krzyki w tle są za głośne! Niesamowite pomysły, świetne ilustracje wzorcowe, urywki dialogów postaci czy rozwiązania mechaniki kładące na łopatki to, co zrobiono dotąd – pewnie gdzieś to wszystko zostało zapisane. Gdzie? Pewnie w Twoim laptopie, w katalogu „Projekt X” na dysku D:. A nie powinno być tam, tylko w miejscu dostępnym dla każdego członka zespołu. I powinno żyć – być tworzone stopniowo.
Dlatego wielu profesjonalistów sugeruje użycie trzech zasadniczych etapów w tworzeniu dokumentacji, opierających się, po kolei, na błyskawicznej prezencji, dokładnym zapisie i ciężkiej orce. Są to:
1. Zapis koncepcji: główny pomysł oraz opisanie jego wartości rynkowej, targetu, kosztów, kluczowych cech i wszystkich innych elementów pozwalających mniej lub bardziej dosłownie sprzedać ideę gry.
2. Dokument projektowy: spis wszystkich elementów produkcji wspierający i upewniający każdą zaangażowaną osobę, że projekt dąży ku jasno określonemu celowi – czyli nasze GDD.
3. Dokumenty produkcyjne: połączenie powyższego dokumentu z twardą rzeczywistością: zestawieniem kosztów, listami zadań, specyfikacjami technicznymi i rezultatami testów.

Dostępność
By spełniać wcześniej wspomniane dwa warunki, GDD powinno trafić do dokumentów w chmurze (np. Google Drive), do systemu zarządzania wiedzą (np. Confluence) lub, ostatecznie, do systemu kontroli wersji (np. GitHub). Możliwość dostępu do dokumentu oraz jego edycji na bieżąco w dowolnej chwili i komentowania przez kilka osób równocześnie w czasie rzeczywistym pozwala tworzyć go płynnie i bez wstrzymywania prac.
Poważną nadgorliwością jest drukowanie GDD, szczególnie przy projektach relatywnie niewielkich i na etapie pre-produkcji. Kiedy pozostaje dostępny z każdego punktu w naszej firmie czy dla komputera każdego z członków projektu, tworzenie makulatury, która po dwóch dniach będzie nieaktualna, jest niczym innym jak marnotrawieniem czasu i papieru. Niech papiernię obciążają póki co notatki z burz mózgów.
A już po pierwszej takiej burzy możemy i powinniśmy rozpoczynać pracę nad GDD. Zatem do dzieła!

Szkielet
Zaczynamy od ogólników. Bardzo rozbudowane punkty pojawią się później, ale już zasadnicze powinny opisywać kluczowe elementy świata, mechaniki, stylu i wszelkich innych podstawowych komponentów gry. Opisywanie wszystkiego naraz już na początku może okazać się poważnym błędem – tak jak dodawanie zbyt wielkiej liczby elementów do wizji gry, znane pod bolesnym terminem „przerost ambicji”. Z czasem, gdy po implementacji i próbach ich funkcja zarysuje się wyraźniej, można je rozwinąć… oraz usunąć te, które okazały się zbędne. Nawet w połowie procesu developmentu nadal jest miejsce na poważne zwroty, duże cięcia oraz szalone eksperymenty, byleby były w miarę spójne z całościową wizją gry.
Ważne jednak jest, by uczynić już z pierwszego szkicu GDD rodzaj mapy drogowej, która pokaże wszystkie punkty, od których wykończenia zależeć będzie skończenie projektu – elementy kluczowe, konieczne i niezbywalne. Reszta podlega szlifowaniu i łataniu. W następnych etapach developmentu rozbudowany już, ale wciąż elastyczny GDD powinien powoli przeistaczać się w sztywne założenia projektu. Będą one wciąż wyznaczać realistyczne cele i przypominać o zaległych zadaniach. Pod koniec jest już w pełni „utwardzonym” tekstem niemal nie do ruszenia.

Nadawanie priorytetów i wytyczanie realnych celów
Zaletą GDD jest możliwość graficznego przedstawienia priorytetów – wyznaczenie głównych punktów i sugestywne wskazanie kwestii kluczowych, choćby za pomocą akapitów i wcięć. Najważniejsze aspekty i najistotniejsze pojęcia zawsze powinny rzucać się w oczy jako pierwsze. Kod kolorów jest dobrym rozwiązaniem, choć warto pamiętać o czarno-białych drukarkach – czasem coś będzie trzeba wydrukować. Ważność poszczególnych elementów gry warto oznaczyć. Najefektowniejsza jest skala trzystopniowa, w której dzielimy je na „NIEZBĘDNE”, „WAŻNE” i „MOŻNA POŚWIĘCIĆ”. Warto z rozsądkiem szafować tymi rangami, inaczej cały proces jest stratą czasu. Tylko faktycznie niezastąpione i kluczowe elementy gry warto zaznaczać jako te „niezbędne”. Gdy dostąpią tego zaszczytu, muszą pozostać nietykalne. Wszystko inne zaś może być przedmiotem dyskusji, modyfikacji lub eliminacji.
GDD pozwala również kontrolować realność obranej ścieżki, a z czasem przeistacza się w narzędzie wyznaczania realistycznych celów. To, co w założeniu wygląda niesamowicie i jest pewną ścieżką ku sukcesowi, może okazać się zbyt trudne do przełknięcia w rzeczywistości. Na bieżąco „szlifowany” GDD pozwala godzić się z cięciami i trzymać ambicję na wodzy… także dlatego, że wciąż pokazuje inne, niesamowite pomysły czekające na realizację. Pomimo, że GDD fizycznie tworzy jedna osoba, jest on dziełem całego zespołu. Nie należy więc zamykać się na dyskusje i zabijać wiele potencjalnych świetnych pomysłów. Powoływanie się na GGD jako nienaruszalny monolit, który „mówi, że…” ma sens wtedy, gdy dyskusja dotyczy NIEZBĘDNYCH elementów.

Wyznaczanie odpowiedzialności, naświetlanie możliwości
Dobrze sporządzony GDD pokazuje na bieżąco, jaki postęp został dokonany. Pozwala zachować ciągłość w procesie tworzenia gry, eliminować zbędne elementy i wskazać potrzebę stworzenia nowych. GDD jest również lustrem, w którym można przejrzeć wszystkie najważniejsze komponenty przez pryzmat możliwości ich realizacji przez zespół.
Osoby odpowiedzialne za przekuwanie konkretnych elementów GDD w konkrety (assety, grafiki, kod, poziomy itd.) warto wyznaczyć jako odpowiedzialnych także za nadzór danych fragmentów samego dokumentu. Można pokusić się o wyraźne ich wyznaczenie także w samym tekście GDD, co daje dodatkową korzyść prostego wskazania, kto jest odpowiedzialny za jaką rzecz.
Istotnym elementem procesu produkcyjnego jest wyznaczanie terminów. Bez niego, cały wysiłek rozmazuje się i zatraca. Osoby chcące posmakować swobodnego życia twórcy gier niestety często zakładają, że terminowość jest wyznacznikiem nudnego życia w korpo, którym gardzą z całego serca. Kamienie milowe, przynajmniej te bardzo ogólne, są jednak ważnym elementem każdej drogi, a drogą jest również każda twórcza praca, w tym game development. Nie należy patrzeć na terminy jako czynnik degradujący morale, lecz raczej je budujący – zakreślanie kolejnych etapów jako ukończonych daje ogromną satysfakcję. Dlatego GDD stanowi użyteczną ściągawkę wskazującą, czy kolejna okazja do świętowania nie nadchodzi przypadkiem wielkimi krokami.
Swoboda i otwarcie na alternatywy też pozwala budować zarówno morale, jak i sukces. Dziesiątki anegdot o zdolnych osobach krąży wokół wynajdowania prostszych rozwiązań w miejsce utartych, ale nudnych i czasochłonnych sposobów, czyniąc niekiedy cnotę z lenistwa wyluzowania. Zawsze warto dopuszczać alternatywne rozwiązania, bo proces tworzenia gier jest dynamiczny, pełen niespodzianek i najeżony pułapkami, z których bystre umysły są w stanie nie tylko wyjść bez szwanku, ale i zainspirowane oraz zmotywowane. Mogą przy tym zdrowo namieszać, ale jeśli GDD jest gotowy na taką ewentualność, nie stanie się nic złego.

Cięcie
Nie należy się łudzić, że koncepcja pozostanie bez zmian – cały niemalże proces tworzenia gry powinien pozostawiać miejsce na zmiany, nawet te poważne i drastyczne. Ważne, by usuwać z GDD wszystko, co nie jest już bezpośrednio powiązane z projektem i nie pokrywa się z finalną wizją gry. Nie oznacza to bynajmniej przymusu permanentnego usunięcia fragmentów opisu, bo umieszczenie ich w osobnym pliku czy adnotacji jest dużo bezpieczniejsze i bardzo proste. Także nowe, ale niemożliwe do przyjęcia pomysły powinny trafić do pliku, w którym łatwo będzie je później odnaleźć. Tak, czy inaczej, z zasadniczego dokumentu znikają wszelkie rozpraszające elementy i zostajemy z meritum.

Porządek musi być
Czytelność to podstawa dokumentu – GDD to formalny zapis, a nie praca domowa w szkole. Wyraźne nagłówki, zapisany czytelnym fontem tekst otoczony odpowiednio szerokimi marginesami, zdania zwarte i konkretne, szczególnie, gdy dotyczą kwestii technicznych – to wymóg porządnej dokumentacji.
Ład musi być zachowywany na bieżąco. Nie należy dopuścić do powstawania comiesięcznej „sesji łatania GDD”. Jeśli postać, jakiś element mechaniki czy świata zmieniły nazwę czy własności – natychmiast aktualizujemy to w całej dokumentacji, pilnując, by wszelkie łącza pozostały sprawne. Najgorsze, co może się przydarzyć, to błąd spowodowany przez osobę, która nie zrozumiała bądź nie odnalazła jakiegoś elementu dokumentacji, więc pracowała „w ciemno”.

Więcej niż czysty tekst, więcej niż proste opisy
Wykresy. Tabelki. Referencyjne ilustracje i już gotowe grafiki. Nie może tego zabraknąć w dobrym, rozwijającym się GDD. Zanurzenie się w oceanie liter i cyfr w sytuacji, gdy chcemy zaprezentować złożoną mechanikę, wygląd czy cechy postaci oraz opis miejsca to męcząca i niekoniecznie bezpieczna droga naokoło. Detale łatwiej ukazać za pomocą wykresów. Zestawienia same proszą się o tabelki ułatwiające porównanie poszczególnych parametrów.
Nie należy też upraszczać opisów do pojedynczych zdań, trzeba pytać „jak?”, a nie tylko „co?”. Jeśli od gracza oczekuje się konkretnego działania, warto rozważyć, co spowoduje próba innych czynności. Jeśli postać ma dysponować jakąś umiejętnością, samo jej nazwanie nie wystarczy – potrzebny jest gruntowny opis konsekwencji tej umiejętności i jej relacji ze wszystkimi elementami rozgrywki. Warto to podkreślić wykresami, tabelkami, wyliczeniami. Nawet wstępne założenia są wartościowe, można je później przekuć w potwierdzone statystyki.
Pewnych rzeczy zresztą nie da się przedstawić jako tekst. Proste rysunki często powiedzą więcej niż wielostronicowe opisy. Ale opisów nie mogą zastąpić – powinny je uzupełniać.

Jeszcze jedna rzecz: inspiracja
Dokument powinien nie tylko przekazywać suche dane, ale i w pewnym stopniu inspirować. Gdy bierzemy się za rozbudowanie GDD ze szkieletu w formę bardziej opisowego dokumentu, dobrze uczynić to w taki sposób, by nie składał się w całości z technikaliów wykładających pozbawione duszy założenia. Dlatego, pomimo starań o utrzymanie zwięzłości i skupienia, do GDD trzeba przemycić pasję, która jest zaraźliwa. Lektura tego dokumentu nie tylko objaśnia, co ma być zrobione, nie tylko tłumaczy, w jaki sposób, ale i zapowiada, co będzie, gdy wykonacie robotę. Jednym ze sposobów na osiągnięcie tego sposobu jest odpowiedni język, który pasuje do kultury panującej w środowisku zespołu. Jeśli w sprawach prywatnych jego członkowie komunikują się za pomocą memów i nawiązań do popkultury, dokumentacja zapisana w oschłym, formalnym tonie na pewno do nich nie przemówi – raczej zanudzi ich na śmierć. Oczywiście, nie trzeba nikomu mówić, że i memy użyte jako sposób ukazywania elementów gry to przesada. Wypracowanie odpowiedniej komunikacji to trudna sztuka wymagająca osobnych rozwiązań w każdym przypadku, ale wraz z czasem więzy w zespole zacieśnią się i stanie się prostsza. Jeśli uda się stworzyć dobrą komunikację i przenieść ją także do GDD, będzie on inspiracją dla każdego.
W pierwszej kolejności to zespół powinien dowiedzieć się, jakie wrażenie ma robić gotowa gra, jakie uczucia wzbudzać i jakimi sposobami mają tego dokonać. Każdy z jego członków będzie wtedy w stanie dorzucić coś od siebie w oparciu o osobiste doświadczenia. Gra jest produktem, gracze są klientami, ale są oni – tak, jak i twórcy – przede wszystkim indywidualnościami, których nie zdefiniujemy z pomocą ciągu liczb i spiętrzonych statystyk.

Podsumowanie

Jeśli proces developmentu jest drogą – a już zgodziliśmy się, że tak – game design document pełni w niej niezwykłą rolę najbardziej uniwersalnego z narzędzi podróżnika. Wyobraźmy sobie scyzoryk, który, oprócz wszystkich tych klasycznych funkcji, dysponuje jeszcze nawigacją satelitarną, nadmuchiwanym szałasem i nabitą śrutówką… tak na wszelki wypadek. Da narzędzia, poprowadzi, zapewni schronienie oraz ułatwi likwidację wszystkich przeszkód, które stoją nam na drodze lub chcą unieważnić naszą ciężką pracę.

W załączeniu umieszczony jest szablon GDD zawierający punkty niezbędne do sporządzenia GDD dla niewielkiego projektu. W połączeniu z niniejszym artykułem, łatwo można z niego wyłowić wszystko, o czym należy pamiętać.

Szablon game design document: https://github.com/gamedevpl/game-design-document/blob/master/GDD_TEMPLATE.md


Najkrócej o kółko i krzyżyk
Szukam osób do projektu stworzenia gry mobilnej
Mega klimatyczny FPS w starym stylu szukam pomocy-ekipy-porady
Mega klimatyczny FPS w starym stylu szukam pomocy-ekipy-porady
#2

Ciekawostka, GDD do Sims, obejmuje również kwestię implementacji: http://donhopkins.com/home/TheSimsDesignDocuments/


#3

To co przede wszystkim daje mi GDD to uświadamia jak mało wiem o projekcie który tworzę :wink: