Szablon dokumentu projektowego gry, który ktoś otworzy

Dobry szablon dokumentu projektowego gry powinien najpierw mieścić się na jednej stronie i rosnąć dopiero wtedy, gdy gra na to zasłuży. Zacznij od pięciu bloków: pitch, filary projektu, główna pętla, lista systemów i otwarte pytania. Wszystko inne, od lore po notatki do poziomów, dodajesz dopiero wtedy, gdy sesja testowa pokaże, że mechanika naprawdę działa. Poniżej opisuję szablon, którego używamy przy projektach tabletopowych i niezależnych gier wideo, oraz miejsca, w których każda sekcja zwykle zaczyna się psuć.

Dlaczego większość dokumentów projektowych umiera do trzeciego tygodnia?

Najczęstszy problem to ambicja. Ktoś otwiera pusty plik, wkleja z forum dwudziestopunktowy spis treści i spędza weekend na wypełnianiu rubryk dla mechanik, których nikt jeszcze nie przetestował. Po trzech tygodniach gra się zmieniła, a dokument nie. Nikt go nie otwiera i nikt tego nie przyznaje.

Przewodnik Game Dev Beginner o GDD mówi to wprost: duże, przesadnie szczegółowe dokumenty wymagają ogromnej pracy na starcie, szybko się dezaktualizują i krępują, gdy projekt wciąż się zmienia. Rozwiązaniem jest etapowanie. Najpierw jedna strona, potem wersja na dziesięć stron, gdy gra nabiera kształtu, a pełny dokument dopiero wtedy, gdy powstaje treść.

To ma większe znaczenie dla projektantów gier tabletopowych niż dla zespołów wideo. Autor kampanii RPG bywa jednocześnie pisarzem, szefem systemu i testerem. Nie czeka na niego inżynier z specyfikacją. Dokument ma dokładnie jedno zadanie: przypilnować, żebyś nie zaprzeczył sobie między sesją czwartą a czterdziestą.

Pomiń czterdziestostronicowy szablon, jeśli pracujesz sam. I tak go nie utrzymasz. Nawet standardowa definicja nazywa GDD dokumentem żywym, a to znaczy, że nikt nie oczekuje, iż będzie gotowy pierwszego dnia. Jest też powód społeczny. Dokument, którego nikt nie czyta, uczy zespół, że dokumentacja jest rytuałem, a nie narzędziem. Lepiej mieć jedną stronę, którą wszyscy znają na pamięć, niż czterdzieści, których nikt nie pamięta.

Co powinno znaleźć się w szablonie dokumentu projektowego gry, który ludzie faktycznie otwierają?

Pięć bloków pokrywa pierwszy miesiąc prawie każdego projektu. Każdy powinien być na tyle krótki, żebyś całą stronę przeczytał w dwie minuty.

1. Pitch. Dwa zdania. Kto w to gra, co robi i czym różni się od najbliższej gry, którą ta osoba już ma.

2. Filary projektu. Trzy lub cztery stwierdzenia, na których sprawdza się każda kolejna decyzja. „Każda walka kosztuje coś trwałego” to filar. „Zabawne i wciągające” nim nie jest.

3. Główna pętla. To, co gracz powtarza. W dungeon crawlu może to być: eksploruj, wybierz, zaryzykuj, wydaj. W kampanii politycznej: intryga, dźwignia, konsekwencja, skutek uboczny.

4. Lista systemów. Same nazwy, z jedną linijką przy każdej. Liczb jeszcze nie wpisuj.

5. Otwarte pytania. Najbardziej przydatna sekcja na stronie i ta, której brakuje w większości szablonów. Zapisuj, czego nie wiesz, i datuj to.

Dlaczego akurat pięć? Pitch odpowiada na pytanie, po co w ogóle istnieje ta gra. Filary mówią, czego nie zrobisz. Pętla pokazuje, co gracz robi najczęściej. Lista systemów wyznacza zakres, a otwarte pytania pokazują granice twojej wiedzy. Jeśli te pięć rzeczy jest jasnych, reszta to już kwestia wykonania.

Na dole dopisz dziennik zmian, nawet jeśli to tylko jedna linijka tygodniowo. Gdy sesja testowa zabije pomysł, zapisz zabicie i powód. Bez tego przyszły ty spróbuje tego samego znowu.

Jak pisać filary projektu, żeby mogły przegrać spór?

Filar zasługuje na miejsce, bo coś odrzuca. Jeśli nie potrafisz wskazać funkcji, którą filar by odrzucił, to ozdoba.

Sprawdź każdy filar listą cięć. Weź trzy funkcje, do których jesteś najbardziej przywiązany, i zapytaj, któremu filarowi każda z nich służy. Funkcja, która nie służy żadnemu, trafia na półkę „może później”, a ta półka może być długa. To najtrudniejsza godzina całego procesu i warta więcej niż jakakolwiek sekcja szablonu.

Oto przykład z kampanii, w której w centrum stoi plaga. Filar pierwszy: niedobór jest widoczny, więc każdy zasób leczniczy jest zapisany na stole. Filar drugi: frakcje chcą różnych lekarstw, więc żadne pojedyncze leczenie nie rozwiązuje wszystkiego. Filar trzeci: mapa się kurczy, więc podróż drożeje wraz z postępem fabuły. Teraz wpływa propozycja zaklęcia wskrzeszenia. Filar pierwszy je odrzuca. Decyzja zajmuje dziesięć sekund zamiast czterdziestominutowej dyskusji.

Warto wiedzieć: filary nie są hasłami marketingowymi. Są wewnętrzne i bezpośrednie, a czasem brzmią trochę nieprzyjemnie. To w porządku.

Gdzie w GDD umieścić lore, a gdzie przeszkadza?

Lore to sekcja, która rośnie najszybciej i jest czytana najrzadziej. Większość dokumentów chowa ją pod nagłówkiem „Historia” na samym dole albo pozwala, by zalała cały plik. Nie działa ani jedno, ani drugie.

Rozdziel materiał według tego, co robi. Lore, które zmienia grę, jak uraza frakcji odblokowująca zadanie albo klątwa kształtująca klasę, żyje wewnątrz systemów, na które wpływa. Lore, które tylko buduje nastrój, trafia na osobną stronę Codex, którą nikt nie musi otwierać, żeby podjąć decyzję projektową. Test jest prosty: jeśli usunięcie akapitu nie zmieni mechaniki, rzutu ani wyboru gracza, należy do Codexu.

Ten podział chroni też kanon. Gdy fakt żyje w dwóch miejscach, oba zapisy zaczynają się rozjeżdżać. Wybierz jedno miejsce dla każdego faktu i linkuj do niego z reszty. Kanon to obietnica, a każda niespójność ją łamie.

Przy długiej kampanii RPG dobrze działa też prosta zasada: każdy nowy fakt dostaje jedno z trzech oznaczeń. Czy wpływa na mechanikę, czy tylko na nastrój, czy jest sekretem znanym wyłącznie mistrzowi gry. Oznaczenie zajmuje sekundę, a później oszczędza długie przeszukiwanie notatek przed sesją.

Autorzy gier z mocną narracją często dodają krótką oś czasu i tabelę „kto co wie”. Oba elementy są tanie, a oszczędzają całe sesje przeróbek, gdy późne odkrycie musi zadziałać jak należy.

Które narzędzie ma przechowywać szablon: Notion, Obsidian czy zwykły dokument?

Narzędzie ma mniejsze znaczenie niż to, czy dokument zostaje w miejscu, w którym już pracujesz. Dokument w zakładce, której nigdy nie otwierasz, jest martwy.

Notion to domyślny wybór małych zespołów. Strony łączą się ze sobą, bazy danych trzymają przedmioty i frakcje, a współpracownicy nie potrzebują żadnej konfiguracji. Gotowe rozwiązania też istnieją, w tym szablon GDD w Notion z sekcjami na sterowanie, pętlę gry, projekt poziomów i zasady. Haczyk to uzależnienie od platformy i pokusa, by budować bazy danych tam, gdzie wystarczyłaby zwykła lista.

Obsidian pasuje samotnemu projektantowi, który chce zwykłych plików Markdown na dysku. Linki zwrotne robią tu prawdziwą robotę: połącz frakcję ze wszystkimi scenami, w których się pojawia, a dostaniesz kontrolę spójności za darmo. Przetrwa też zniknięcie dostawcy, co ma znaczenie, jeśli projekt potrwa lata.

GitBook sprawdza się, gdy dokument ma być publiczny albo półpubliczny, na przykład dla grupy playtestowej albo strony backerów z crowdfundingu. Zwykły dokument Google wystarczy na game jam. Unikaj rozbudowanego modelu uprawnień, chyba że wydawca o niego poprosi.

Niezależnie od wyboru ustal jedną zasadę: dokument aktualizujesz na końcu każdej sesji testowej, zanim ktokolwiek pójdzie do domu. Dziesięć minut, bez wyjątków.

Co dodać, gdy prototyp przetrwa sesje testowe?

Po trzech lub czterech sesjach z prawdziwymi graczami jednostronicowy dokument zasługuje na kolejną warstwę. Dodawaj sekcje w tej kolejności i tylko wtedy, gdy brak któregoś zacznie boleć.

Szczegóły systemów. Liczby, tabele, przypadki brzegowe. Pisz je w chwili, gdy zamykasz dany system, nie wcześniej. W RPG tu trafiają koszty akcji, zakresy obrażeń i koszty zasobów, razem z tekstem zasady w brzmieniu, w jakim obowiązuje przy stole. W grze wideo dodaj tabele danych, które przeczytają inżynierowie.

Listy treści. Przedmioty, wrogowie, frakcje, lokacje. Użyj tabeli z jednym wierszem na pozycję i kolumną z filarem, któremu każda służy. Wiersze, które nikomu nie służą, są kandydatami do wycięcia.

Interfejs i przepływ. Układ karty postaci w grach tabletopowych, przepływ ekranów w grach cyfrowych. Najpierw naszkicuj to ręcznie, dopiero potem opisz tekstem.

Notatki produkcyjne. Kamienie milowe, zakres, ryzyka, to, co wchodzi w pierwsze wydanie, a czego nie. Jeśli planujesz sprzedaż na DriveThruRPG albo Itch.io, tutaj zaczynają się też treść strony sprzedażowej i założenia cenowe. Warto zapisać, kto i kiedy zmienił decyzję. W kampanii, która trwa rok, pamięć zawodzi szybciej, niż wydaje się rozsądne.

Pitch i część marketingowa to osobny dokument dla innego czytelnika. Wydawcy i backerzy szukają kontekstu rynkowego i unikalnych cech. Twoi testerzy chcą zasad. Połączenie obu daje plik, który nie służy żadnemu z nich.

Czy AI może pomóc w pisaniu dokumentu projektowego gry i gdzie zawodzi?

Pomaga przy szkicach nudnych części, a zawodzi tam, gdzie chodzi o rzeczy najważniejsze. Poproś model o rozwinięcie listy systemów w tabelę przypadków brzegowych, a dostaniesz w minutę przyzwoity pierwszy szkic. Poproś o wybór filarów, a dostaniesz filary brzmiące jak w każdej innej grze. Generuje szybko, ale decyzje nadal wymagają ludzkiego przejrzenia.

Praktyczne zastosowanie to sprawdzanie spójności. Wrzuć Codex i listę systemów, a potem zapytaj, w których miejscach dwie strony sobie przeczą. Narzędzia zbudowane wokół długiej biblii świata, jak Novelcrafter, są stworzone do takiego krzyżowego sprawdzania. Traktuj wynik jak listę podejrzanych, nie wyrok, i sprawdź każdą flagę na własnych stronach.

Jedna twarda zasada: model nigdy nie pisze sekcji z otwartymi pytaniami. To uczciwa lista tego, czego nie wiesz, i oddanie jej komuś innemu niweczy sens całej tej strony.

Co pominąć, a co zachować?

Pomiń pełny szablon, dopóki mechanika nie przetrwa co najmniej trzech prawdziwych sesji. Pomiń esej o grupie docelowej, jeśli nie potrafisz wymienić pięciu prawdziwych osób, które by w to zagrały. Pomiń szczegółowe sekcje monetyzacji w grze, która nie znalazła jeszcze swojej pętli. Pomiń każdą sekcję, której nie wyobrażasz sobie, że czytasz na głos współpracownikowi.

Zachowaj filary, otwarte pytania i dziennik zmian. Te trzy elementy robią większość roboty. Dokument złożony tylko z nich, aktualizowany co tydzień, bije dopracowane trzydzieści stron, których nikt nie otwierał od marca.

Szablon jest obietnicą, którą składasz przyszłemu sobie: co postanowiłeś i dlaczego. Trzymaj go na tyle krótki, żebyś mógł tę obietnicę dotrzymać.