Szablon dokumentu projektowego gry: jedna strona, która żyje

Szablon dokumentu projektowego gry powinien mieścić się na jednej stronie i rosnąć dopiero wtedy, gdy gra na to zasłuży. Zacznij od siedmiu bloków: pitch, pętla rozgrywki, czasowniki gracza, świat, systemy, zakres i otwarte pytania. Wypełnisz je w jeden wieczór. Wytnij wszystko, czego nie da się sprawdzić w prototypie w tym miesiącu. Reszta tego wpisu to właśnie szablon i te części, które pomijają prawie wszystkie poradniki.

Dlaczego większość dokumentów projektowych gier umiera w drugim tygodniu

Wyobraź sobie GDD na czterdzieści stron. Piękna okładka, spis treści, rozdział o lore, którego nikt nie zamawiał. Po tygodniu drugim prototyp odjechał, a dokument stał się skamieliną.

Prawdziwa porażka nie polega na brakujących sekcjach. Polega na pliku, który przestaje być prawdziwy. GDD to narzędzie robocze, bliżej dziennika zmian niż biblii. Gdy dokument i build się rozjeżdżają, przegrywa dokument, a ludzie przestają go otwierać. Nikt nie czyta mapy, która kłamie.

Warto to powiedzieć wprost, bo wiele osób zaczyna pracę nad grą od pustego dokumentu z gotowym spisem treści. Spis treści wygląda jak postęp, ale nim nie jest. Prawdziwym postępem jest to, że coś da się zagrać i sprawdzić.

Dlatego pytanie nie brzmi: „Co powinien zawierać dokument projektowy gry?". Brzmi: „Jaki jest najmniejszy dokument, który uczciwie utrzymam?".

Szablon na jedną stronę

Skopiuj ten zarys. Każdy blok dostaje od dwóch do pięciu linijek, a przy pierwszym przejściu nie więcej.

1. Pitch. Jedno zdanie, które obcy człowiek mógłby powtórzyć. „Kooperacyjne miasteczko portowe, w którym przypływ przepisuje mapę każdej nocy."

2. Pętla rozgrywki. To, co gracz robi w kółko, w mniej niż minutę. Narysuj ją jako okrąg czasowników.

3. Czasowniki gracza. Pięć do ośmiu działań. Nie funkcje, tylko czasowniki: wspinaj się, handluj, ukrywaj się, rozwidlaj, naprawiaj.

4. Świat. Miejsce, nastrój i trzy zasady, które są zawsze prawdziwe. Pogoda też jest zasadą.

5. Systemy. Dwa albo trzy mechanizmy, które sprawiają, że czasowniki są ciekawe. Ekonomia, skradanie, crafting, cokolwiek niesie pętlę.

6. Zakres. Co wchodzi do wydania, co wycinasz, co jest celem rozciągniętym. Przy każdej pozycji postaw datę.

7. Otwarte pytania. Uczciwa lista rzeczy, których jeszcze nie wiesz. To najcenniejszy blok na całej stronie.

Zauważ, czego tu brakuje: monetyzacji, planu marketingowego, rozdziału z biografią postaci. Te rzeczy należą do osobnych plików, pisanych wtedy, gdy prototyp udowodni pętlę. Większość gotowych szablonów zaczyna właśnie od nich, i dlatego te dokumenty nigdy nie zostają skończone.

Jeśli zespół potrzebuje dłuższej struktury do akceptacji, przewodnik GitBook o pisaniu GDD opisuje klasyczną listę rozdziałów. Jego rada, żeby zacząć od wersji jednostronicowej i dopisywać szczegóły wraz z prototypami, to dobry instynkt.

Co powinna mówić sekcja pętli

Pomiń przymiotniki. Zapisz pętlę jako zdanie z zegarem.

Zbieraj złom przez 40 sekund -> zanieś złom na pomost -> wymień go na ulepszenie -> przypływ zmienia mapę -> powtórz

Przeczytaj to na głos. Jeśli jeden krok brzmi martwo, właśnie znalazłeś pierwsze zadanie prototypowe. Jeśli każdy krok brzmi dobrze, ale nie umiesz powiedzieć, dlaczego gracz wraca, pętli brakuje powodu. Dopisz to jako otwarte pytanie zamiast chować je w akapicie.

Mój test jest prosty: zdanie o pętli musi zmieścić się w jednym wierszu tekstu. Jeśli potrzebuje akapitu, to są dwie pętle, a Ty projektujesz dwie gry.

Które sekcje można wyciąć bez żalu?

Bądź bezwzględny. Projekt solo albo dwuosobowy zwykle może od pierwszego dnia odpuścić:

• Pełne biografie postaci. Zostaw imię, pragnienie i wadę. Resztę dopiszesz, gdy postać pojawi się w buildzie.

• Szczegółowe opisy poziomów. Opisz zasady poziomów, a nie pomieszczenia.

• Rozdziały o platformach i monetyzacji. Odłóż je, dopóki pętla nie działa.

• Biblia artystyczna. Trzy obrazy referencyjne i paleta barw. To wszystko.

Jedna praktyczna rada: nie kasuj wyciętych sekcji, tylko przenoś je do osobnego pliku z tytułem „później". Dzięki temu nie czujesz winy, a dokument główny zostaje krótki. Kiedy prototyp przejdzie test, wiesz, skąd wyjąć resztę.

Pomiń to wszystko, jeśli robisz grę na game jam w siedemdziesiąt dwie godziny: pitch, pętla i czasowniki to cały Twój dokument. Pełną listę warto zachować, jeśli masz wydawcę, ścieżkę certyfikacji na konsole albo współpracowników, którzy nie mogą zadzwonić do Ciebie o północy z pytaniem.

Szablon GDD od Unity w formie PDF dobrze pokazuje, jak mechaniki i zachowania obiektów zapisuje się, gdy w projekcie pracuje zespół. Czytaj go jako katalog, a nie jako checklistę.

Gdzie trzymać dokument i jak silnik zmienia zapisy

Trzymaj go tam, gdzie będziesz go edytować codziennie. Brzmi to oczywiście, dopóki nie zobaczysz, ile GDD żyje w PDF-ie, którego nikt nie da się porównać.

Wybierz narzędzie, które daje nagłówki, bazę zadań i historię wersji. Aplikacja z notatkami opartą na bazie danych sprawdza się dobrze, bo otwarte pytania i lista zakresu stają się śledzonymi zadaniami, a nie punktami, które po cichu gniją.

Zwykły Markdown w repozytorium to drugie dobre wyjście. Leży obok kodu, czysto się porównuje w diffach i nikt nie zapomni go zaktualizować przy pull requeście. Minusem jest to, że koledzy spoza techniki się do niego nie dotkną.

Ważne jest też to, kto może edytować dokument. Jeśli zmienia go tylko jedna osoba, prędzej czy później przestanie być aktualny, bo ta osoba będzie zajęta buildem. Ustal prosty zwyczaj: każdy, kto zmienia mechanikę, dopisuje wpis do otwartych pytań albo poprawia zakres.

Cokolwiek wybierzesz, połóż jednostronicową wersję na górze i linkuj do głębszych plików. Strona jest mapą. Pliki to terytorium.

Silnik też trochę zmienia to, co zapisujesz. Decyduje, które czasowniki są tanie, a które drogie, więc sekcje systemów i zakresu powinny to powiedzieć wprost.

Jeśli pracujesz w pełnym silniku 3D z dużym potokiem assetów, zakres potrzebuje wiersza dla każdej kategorii zasobów, bo to właśnie treść jest miejscem, gdzie harmonogramy giną.

Jeśli wolisz silnik open source bez liczenia tantiem, sekcja zakresu staje się prostsza: nie ma linii o licencjach, ale musi być konkretna notatka o tym, które funkcje zbudujesz sam.

A jeśli gra jest dwuwymiarowa, z ciasną mechaniką, sekcja pętli niesie prawie wszystko. Małe, czytelne dokumenty pasują do małych, czytelnych gier.

Nie chodzi o wskazanie zwycięzcy. Chodzi o to, że linia o narzędziach nie jest przypadkowa. Powinna wymieniać, co silnik ułatwia, co utrudnia i czego nie zamierzasz budować.

Jak napisać GDD dla świata, który generuje się sam?

To luka prawie w każdym szablonie. Zakładają, że każde drzewo stawiasz ręcznie.

Gdy świat powstaje z promptu, dokument zmienia kształt. Nie specyfikujesz już pomieszczeń. Specyfikujesz ograniczenia: co musi być prawdą w każdym świecie, który silnik może wygenerować, i co wolno mu zmieniać.

Dopisz do jednostronicowego szablonu dwa bloki:

• Ograniczenia świata. Reguły, których nie wolno złamać. „Każda osada ma wodę w zasięgu dwóch minut spaceru." „Żadnych ślepych zaułków z misjami."

• Ziarna promptów. Dokładne prompty, których użyłeś, zapisane jako część dokumentu.

Tak wygląda takie ziarno w praktyce:

mglista nadmorska wioska przy odpływie, jedna latarnia, wąskie schody, drewniane mostki między dachami, na razie nikogo

Zapisz prompt, zapisz to, co wróciło, i zanotuj, co byś rozwidlił. Prompt jest jednocześnie specyfikacją i dziennikiem zmian. Rozwidl go, zmień jedną rzecz, zobacz, co się stanie, a potem wpisz różnicę do dokumentu. Ten nawyk zamienia wygenerowany świat w coś, o czym da się rozumować, i daje zespołowi konkret do krytyki zamiast odczucia, że „coś tu nie gra".

Ograniczenia świata często wychodzą z jednego pytania: co gracz musi zawsze móc zrobić, niezależnie od tego, co wygeneruje silnik? Jeśli odpowiedź brzmi „wszystko", to nie masz ograniczeń, tylko życzenie. Zapisz je konkretnie, z liczbami tam, gdzie się da, bo liczbę da się sprawdzić w prototypie.

Uwaga: jakość generowania mocno się różni między narzędziami, a niektóre funkcje są w całej branży wciąż w becie. Przy każdym ziarnie zapisz wersję narzędzia i datę, żeby wiedzieć, czy wynik da się powtórzyć, czy był tylko szczęśliwym rzutem.

Szybki test pętli, zanim napiszesz więcej

Tak wygląda mój wieczorny przepływ dla świeżego pomysłu.

1. Napisz jednostronicowy szablon w trzydzieści minut. Nie edytuj go potem.

2. Zamień pitch i trzy zasady świata w prompt i wygeneruj pierwszy szkic przestrzeni.

3. Przejdź pętlę w tej przestrzeni, ręcznie albo w szkicowym prototypie.

4. Zaznacz każdy krok, który wydał się martwy. Trafiają do otwartych pytań.

5. Wytnij jeden czasownik. Zawsze jeden.

Ten wieczór nie kończy się na dokumencie. Jeśli po przejściu pętli w szkicu okaże się, że gracz nie ma powodu wracać, wróć do pitchu. Często problem nie leży w mechanice, tylko w obietnicy, którą składasz w jednym zdaniu.

Wycięcie to część, którą ludzie pomijają. Dokument, który tylko rośnie, jest listą życzeń. Usunięcie czasownika zmusza pozostałe do dźwigania większego ciężaru i zwykle pokazuje, który system naprawdę pracował.

Jak utrzymać dokument przy życiu po drugim tygodniu?

Trzy nawyki, żaden z nich nie jest heroiczny.

Datuj każde otwarte pytanie. Jeśli pytanie ma więcej niż trzy tygodnie i wciąż jest otwarte, albo na nie odpowiedz, albo przyznaj, że go unikasz.

Aktualizuj dokument w tej samej sesji co build. Nie później. Później to moment, w którym tworzy się skamielina. Dwuliniowa zmiana na koniec sesji kosztuje minutę.

Prowadź listę porzuconych pomysłów na dole dokumentu. Oszczędza Ci ponownego debatowania nad tą samą mechaniką co miesiąc, a zobaczenie, ile wysłałeś, mówiąc „nie", bywa zaskakująco motywujące.

Jeśli pracujesz sam, zrób z tego rytuał. Raz w tygodniu otwórz dokument, przeczytaj tylko otwarte pytania i odhacz te, na które już znasz odpowiedź. Zajmie to dziesięć minut, a da dokładny obraz tego, co Cię blokuje.

Kiedy do projektu dołącza ktoś nowy, daj mu najpierw wersję jednostronicową i obserwuj, gdzie się gubi. Każde pytanie wynikające z zagubienia to brakująca linijka w dokumencie.

Czego sami byśmy używali?

Jeśli działasz sam albo w duecie, jednostronicowy szablon z siedmioma blokami i lista ziaren promptów wystarczą na pierwszy miesiąc. Jeśli masz zespół, zostaw jednostronicówkę jako wejście do całości, a dla systemów i treści dodawaj osobne pliki dopiero wtedy, gdy prototyp je uzasadni. Jeśli masz wydawcę, daj mu długą wersję, ale ufaj tej jednostronicowej najbardziej.

Nie chodzi o gotową funkcję, którą kiedyś zobaczysz w produkcie. To sposób pracy, który sprawdza się przy grach nawet bez generowania światów. Generowanie tylko wyostrza problem, bo zmusza do mówienia wprost o zasadach.

Otwórz dziś pustą stronę i napisz pitch. Jedno zdanie. Potem pętlę, z zegarem. Jeśli nie zdołasz tego skończyć w pół godziny, pomysł nadal jest marzeniem, i dobrze wiedzieć to, zanim wydasz na niego miesiąc.