Przejdź do treści
Nodary
Zacznij za darmo

Szablon dokumentu projektowego gry (GDD)

Dziewięć połączonych dokumentów, które opisują grę od pitchu po dziennik decyzji, każdy ze wskazówkami, co w nim napisać, i krótkim przykładem. Pobierz je jako pliki Markdown: otworzysz je w dowolnym edytorze, ich diagramy wyświetlą się na GitHubie i w Obsidianie, a do Nodary zaimportujesz je jako mapę.

Pobierz szablonOtwórz demo

9 plików Markdown w archiwum .zip, 15 kB

Za darmo, bez konta, bez e-maila. Używaj, zmieniaj, udostępniaj.

Dokument projektowy gryRozgrywkaSystemy i ekonomiaPlan produkcjiProjekt technicznyInterfejs i dostępnośćKierunek artystyczny i dźwiękowyŚwiat, fabuła i postaciePoziomy i zawartość

Przeczytaj każdą stronę przed pobraniem

Dokument główny mieści się na jednym ekranie i prowadzi do ośmiu części, po jednej na każdy dział, więc każda część ma właściciela, a zmiana pozostaje mała. Wiersze kursywą mówią, co napisać; przykłady pochodzą z Saltmarrow, przykładowej gry, którą ta strona pokazuje wszędzie.

Dokumenty

Plik Szablon dokumentu projektowego gry/Dokument projektowy gry.md

Dokument projektowy gry

Jak korzystać z tego szablonu: wiersze kursywą to wskazówki. Zastąp je własnymi słowami, a potem usuń. Wartości w nawiasach kwadratowych są do uzupełnienia. Niech ta strona zajmuje mniej więcej jeden ekran: to strona, którą wszyscy czytają najpierw, a każda inna część projektu jest o jeden link stąd.

W skrócie

PoleTwoja gra
Tytuł roboczy[Tytuł]
Logline[Jedno zdanie, które ktoś obcy mógłby powtórzyć]
Gatunek[Gatunek i podgatunek]
Gracze[Dla jednego gracza, co-op od 2 do 4 graczy, rywalizacja]
Platformy[PC, konsole, urządzenia mobilne]
Długość sesji[Typowa sesja, w minutach]
Silnik[Silnik i wersja]
Zespół[Wielkość dziś i w szczycie]
Model biznesowy[Cena, free-to-play, subskrypcja]
Następny kamień milowy[Nazwa i data]

Pitch

Dwa lub trzy zdania: kim jest gracz, co robi i czym gra się wyróżnia. Napisz go tak, żeby sprawdził się też na stronie sklepu.

Przykład (Saltmarrow, przykładowa gra): Grab sól, nurkuj po wspomnienia, wróć do domu przed przypływem. Kooperacyjna gra o eksploracji i craftingu dla maksymalnie czterech graczy, osadzona na pływowych solniskach, gdzie zatopione miasto-archiwum wynurza się dwa razy dziennie.

[Twój pitch]

Filary projektu

Trzy do pięciu zasad, którym musi służyć każda funkcja. Filar, który mógłby opisywać dowolną grę, na przykład „fajna walka”, nie jest filarem. Funkcję, która nie służy żadnemu filarowi, wycinamy; funkcję, która łamie któryś z nich, projektujemy od nowa.

  1. [Filar pierwszy]: [co oznacza, w jednym zdaniu]
  2. [Filar drugi]: [co oznacza, w jednym zdaniu]
  3. [Filar trzeci]: [co oznacza, w jednym zdaniu]

Przykład (Saltmarrow, przykładowa gra): Pływ to zegar. Czas jest jedynym zasobem, którego nigdy nie przybywa: każdy system odczytuje pływ i nic go nie wstrzymuje.

Grupa docelowa

Dla kogo jest gra, w co ci gracze grają dziś i kiedy przestają grać. Podaj prawdziwe gry i prawdziwe nawyki, nie tylko przedział wiekowy.

  • Główni gracze: [kim są i jak grają]
  • W co grają dziś: [trzy lub cztery gry]
  • Przestają grać, gdy: [...]
  • Druga grupa graczy: [...]

Podobne gry

Trzy lub cztery gry, które Twój zespół i Twoi gracze już znają. Napisz, co bierzesz z każdej i, co równie przydatne, czego nie bierzesz.

GraCo bierzemyCzego nie bierzemy
[Gra][...][...]
[Gra][...][...]
[Gra][...][...]

Zakres

Co zawiera pierwsze wydanie, a czego wyraźnie nie zawiera. To właśnie druga lista chroni zakres przed cichym rozrastaniem się.

  • W pierwszym wydaniu: [...]
  • Poza pierwszym wydaniem: [...]
  • Do decyzji później: [...]

Reszta projektu

Każda część to osobny dokument. Linkuj do niej, zamiast z niej kopiować, żeby każdy fakt żył w jednym miejscu i w jednym miejscu się zmieniał.

Ten szablon możesz za darmo używać, zmieniać i udostępniać. Pochodzi z Nodary, gdzie te pliki importują się jako mapa połączonych dokumentów.

Pobierz szablon9 plików Markdown w archiwum .zip, 15 kB

Jak z niego korzystać

  1. Napisz dokument główny za jednym podejściem

    Najpierw wypełnij tabelę, pitch i filary, w mniej więcej godzinę, razem z ludźmi, którzy będą robić grę. Każdą inną stronę ocenia się właśnie względem nich.

  2. Wypełniaj części, gdy zapadają decyzje

    Lepiej zostawić sekcję pustą, niż ją wymyślić. Pusta sekcja to uczciwe, otwarte pytanie; wymyśloną ktoś w końcu zbuduje.

  3. Zapisuj każdą decyzję

    Gdy decyzja zmienia projekt, dodaj wiersz do dziennika decyzji w planie produkcji i zaktualizuj stronę, której dotyczy. Dziennik mówi dlaczego; strona mówi, co obowiązuje teraz.

  4. Daj każdej stronie właściciela

    Każda część podaje swojego właściciela i datę ostatniego przeglądu. Strona, za którą nikt nie odpowiada, pierwsza traci aktualność.

Zaimportuj go do Nodary jako mapę

Nodary to przestrzeń robocza dla zespołów tworzących gry, w której dokumenty są połączone jak gwiazdy na mapie. Zaimportuj plik .zip, a dokument główny pojawi się z ośmioma częściami ułożonymi pod nim, z zachowanymi linkami między stronami i narysowanymi diagramami. Potem Twój zespół komentuje fragmenty, prosi o recenzje i widzi, co się zmieniło od ostatniej wizyty, a agenci AI podłączeni przez MCP czytają projekt, zanim zaczną w nim pisać.

  1. Otwórz mapę projektu i wybierz „Importuj”.
  2. Wybierz kartę „Folder lub ZIP”, a potem „Wybierz plik ZIP”.
  3. Wskaż pobrany plik, sprawdź drzewo i zaimportuj.

Plan Free mieści dziesięć dokumentów na przestrzeń roboczą, wliczając stronę samego projektu: dziewięć dokumentów szablonu zmieści się w nowej przestrzeni roboczej i ją wypełni. Płatne plany mają miejsce na więcej.

Jak Nodary obsługuje dokumenty projektowe gry
Okno importu w Nodary z wybranym plikiem .zip szablonu: dziewięć dokumentów w drzewie, dokument główny z ośmioma częściami pod nim i wiersz informujący, że import utworzy 9 dokumentów z 9, na które plan jeszcze pozwala.

Jak napisać GDD, który ludzie naprawdę czytają

Dokument projektowy gry zawodzi na jeden z dwóch sposobów: nikt go nie czyta albo wszyscy czytają starą wersję. Te nawyki zapobiegają obu.

Jedna strona na część

Plik na sześćdziesiąt stron czyta się raz, na początku. Krótkie połączone strony czyta się wtedy, gdy są potrzebne, a zmiana dotyka jednej strony zamiast pięciu.

Zapisuj decyzje, nie życzenia

„Walka ma dawać frajdę” niczego nie rozstrzyga. „Trafienie następuje w ciągu 100 milisekund od wciśnięcia przycisku” da się zbudować i przetestować.

Zaznacz, co jest wciąż otwarte

Oznacz pytania bez odpowiedzi jako otwarte, z tym, kto na nie odpowie i do kiedy. Domysł zapisany jak fakt to prosta droga do tego, że dwa działy zbudują dwie różne gry.

Linkuj, nie kopiuj

Gdy strona ekonomii potrzebuje godzin pływów, podlinkuj je. Fakt zapisany w dwóch miejscach szybko zaczyna mówić dwie różne rzeczy.

Zapisuj, dlaczego

Dziennik decyzji przechowuje powody, dla których coś jest takie, jakie jest, żeby nowa osoba w zespole nie cofnęła wyboru, za który zespół już zapłacił.

Wytnij to, czego nikt nie czyta

Jeśli nikt nie otworzył sekcji od czasu jej napisania, połącz ją z inną albo usuń. Krótki dokument, który jest prawdziwy, wygrywa z długim, który kiedyś był.

Pytania o dokumenty projektowe gry

Czym jest dokument projektowy gry?

Dokument projektowy gry, czyli GDD (game design document), opisuje grę, którą tworzy zespół: jej pitch, filary, mechaniki, systemy, świat, poziomy, oprawę graficzną i dźwiękową oraz plan produkcji. Czytają go projektanci, graficy, programiści, producenci, a coraz częściej także agenci AI, więc musi pozostawać aktualny, gdy gra się zmienia.

Co powinien zawierać dokument projektowy gry?

Co najmniej jednostronicowy dokument główny z pitchem, filarami, grupą docelową i zakresem; gameplay i pętlę rozgrywki; systemy i ich liczby; świat i fabułę; poziomy i zawartość; kierunek artystyczny i dźwiękowy; interfejs i dostępność; ograniczenia techniczne; oraz plan produkcji z dziennikiem decyzji. Ten szablon ma osobny dokument na każdy z tych tematów.

Jak długi powinien być GDD?

Tak krótki, jak się da, byle odpowiadał na pytania zespołu. Dokument główny powinien mieścić się na jednym ekranie. Każda część rośnie razem z podjętymi decyzjami, a nie z nadziejami: strona ustalonych zasad jest więcej warta niż dziesięć stron możliwości.

Czy zespoły indie i pracujące zwinnie nadal potrzebują GDD?

Potrzebują spisanych decyzji, a nie biblii napisanej z góry. Zespoły, które szybko iterują, traktują GDD jako zapis tego, czym gra jest dzisiaj: krótkie strony, aktualizowane, gdy playtest coś zmienia, z powodami zachowanymi w dzienniku decyzji.

W jakim formacie jest szablon?

W Markdown: to zwykłe pliki tekstowe, które otworzy każdy edytor. Linki między dokumentami są linkami względnymi, tabele są tabelami Markdown, a diagramy są zapisane w Mermaid, który rysują GitHub, Obsidian i Nodary. Nic nie zależy od jednego konkretnego narzędzia.

Czy mogę go używać w Obsidianie, na GitHubie lub w innym edytorze?

Tak. Obsidian otwiera rozpakowany folder jako sejf (vault), w którym działają wszystkie linki, a GitHub pokazuje pliki z ich linkami i diagramami. Narzędzia, które importują Markdown plik po pliku, zachowują tekst i tabele; sprawdź, jak radzą sobie z linkami między plikami.

Jak zaimportować szablon do Nodary?

Otwórz mapę projektu, wybierz „Importuj”, potem kartę „Folder lub ZIP” i wskaż pobrany plik .zip. Nodary najpierw pokazuje drzewo, a potem tworzy dziewięć dokumentów z dokumentem głównym jako nadrzędnym, zachowuje linki między nimi i rysuje diagramy. Każdy folder lub .zip z maksymalnie 200 plikami Markdown importuje się tak samo.

Czy mogę użyć szablonu w grze komercyjnej?

Tak. Używaj go, zmieniaj i udostępniaj przy dowolnej grze, komercyjnej czy nie, z kontem Nodary lub bez niego. Wzmianka jest mile widziana, ale nigdy nie jest wymagana.

Czytaj dalej

Trzymaj projekt tam, gdzie pracuje zespół.

Zaimportuj szablon do Nodary, a GDD stanie się mapą, którą Twój zespół i Twoi agenci AI utrzymują w aktualności. Za darmo z dwoma członkami, jednym projektem i dziesięcioma dokumentami, bez karty.

Zacznij za darmoOtwórz demoPobierz szablon