# 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ę.

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

[Pobierz szablon (.zip)](https://nodary.ai/downloads/szablon-dokumentu-projektowego-gry.zip)

## 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.

- Dokument projektowy gry: Strona, którą wszyscy czytają najpierw: pitch, filary, grupa docelowa, zakres i link do każdej części.
- Rozgrywka: Co gracz robi z minuty na minutę i dlaczego chce robić to dalej.
- Systemy i ekonomia: Każdy system, zasady, którym podlega, zasoby, które przesuwa, i liczby, które za nim stoją.
- Świat, fabuła i postacie: Realia świata i jego zasady, historia, którą przeżywa gracz, i ludzie, którzy w niej występują.
- Poziomy i zawartość: Każde miejsce, do którego trafia gracz, pierwsza godzina gry i ile zawartości potrzebuje wydanie.
- Kierunek artystyczny i dźwiękowy: Jak gra wygląda i brzmi, na tyle precyzyjnie, by prace dwóch artystów pracujących osobno do siebie pasowały.
- Interfejs i dostępność: Ekrany, HUD i sterowanie oraz to, jak gra dostosowuje się do każdego gracza.
- Projekt techniczny: Silnik, cele wydajności, architektura i pipeline oraz ograniczenia, jakie narzucają projektowi.
- Plan produkcji: Kamienie milowe, zespół, ryzyka i dziennik każdej decyzji, która zmieniła projekt.

### 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

| Pole | Twoja 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._

| Gra | Co bierzemy | Czego 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ł._

- [Rozgrywka](https://nodary.ai/pl/templates/game-design-document#gdd-gameplay): pętla rozgrywki, mechaniki, sterowanie i progresja
- [Systemy i ekonomia](https://nodary.ai/pl/templates/game-design-document#gdd-systems): każdy system, jego zasady i jego liczby
- [Świat, fabuła i postacie](https://nodary.ai/pl/templates/game-design-document#gdd-world): realia świata, fabuła i ludzie, którzy w niej występują
- [Poziomy i zawartość](https://nodary.ai/pl/templates/game-design-document#gdd-levels): każde miejsce, pierwsza godzina gry i budżet zawartości
- [Kierunek artystyczny i dźwiękowy](https://nodary.ai/pl/templates/game-design-document#gdd-art): jak gra wygląda i brzmi
- [Interfejs i dostępność](https://nodary.ai/pl/templates/game-design-document#gdd-interface): ekrany, HUD, sterowanie i dostępność
- [Projekt techniczny](https://nodary.ai/pl/templates/game-design-document#gdd-technical): silnik, cele wydajności, architektura i pipeline
- [Plan produkcji](https://nodary.ai/pl/templates/game-design-document#gdd-production): kamienie milowe, zespół, ryzyka i dziennik decyzji

_Ten szablon możesz za darmo używać, zmieniać i udostępniać. Pochodzi z_ [Nodary](https://nodary.ai/pl)_, gdzie te pliki importują się jako mapa połączonych dokumentów._

### Rozgrywka

**Właściciel:** [imię i nazwisko] · **Status:** szkic · **Ostatni przegląd:** [data]

_Co gracz robi z minuty na minutę i dlaczego chce robić to dalej. Zacznij od pętli: cała reszta tego dokumentu się na niej opiera._

#### Pętla rozgrywki

_Pętla, którą gracz powtarza najczęściej, w czterech do sześciu czasownikach. Jeśli zespół nie potrafi jej narysować, to znaczy, że nie jest jeszcze ustalona._

```mermaid
flowchart LR
  n0["Planuj"]
  n1["Eksploruj"]
  n2["Zbieraj"]
  n3["Wytwarzaj"]
  n4["Ulepszaj"]
  n0 --> n1
  n1 --> n2
  n2 --> n3
  n3 --> n4
  n4 --> n0
```
_Pętla rozgrywki, około [n] minut na cykl_

| Etap | Typowy czas | Pytanie gracza |
| --- | --- | --- |
| [Planuj] | [2 min] | [Jaki cel tym razem i co zabieram?] |
| [Eksploruj] | [...] | [...] |
| [Zbieraj] | [...] | [...] |

_Przykład (Saltmarrow, przykładowa gra): Zbiór czy nurkowanie, od 8 do 14 minut: grabić bezpieczną sól czy nurkować po kryształy, które mogą być warte więcej? Każdy etap powinien stawiać graczowi pytanie. Etap bez pytania to pańszczyzna._

#### Mechaniki

_Jeden wiersz na mechanikę. Kolumna filarów trzyma każdą z nich w ryzach: mechanika, która nie służy żadnemu filarowi, trafia na listę do wycięcia._

| Mechanika | Co robi gracz | Któremu filarowi służy | Status |
| --- | --- | --- | --- |
| [Mechanika] | [...] | [...] | [pomysł, prototyp, zamknięta] |
| [Mechanika] | [...] | [...] | [...] |

#### Sterowanie

_Czasowniki gracza i to, jak każdy z nich ma się odczuwać. Mapowanie przycisków dla każdego urządzenia jest w dokumencie_ [Interfejs i dostępność](https://nodary.ai/pl/templates/game-design-document#gdd-interface).

- [Czasownik]: [jak się go wykonuje i jak ma się odczuwać]
- [Czasownik]: [...]

#### Progresja

_Co rośnie w trakcie sesji i przez całą grę oraz jak gracz widzi ten wzrost. Nazwij cel długoterminowy._

- W trakcie sesji: [...]
- Między sesjami: [...]
- Cel długoterminowy: [...]

#### Wyzwanie i porażka

_Jak rośnie trudność, ile kosztuje porażka i jak gracz wraca do gry. Porażka, która kosztuje tylko czas, uczy mniej niż taka, która kosztuje wybór._

- Trudność rośnie dzięki: [...]
- Porażka kosztuje: [...]
- Powrót do gry: [...]

_Przykład (Saltmarrow, przykładowa gra): Nurek, który wciąż jest w archiwum, gdy zabrzmi róg, traci kryształy z torby i wynurza się przy najbliższej wieży, ale zachowuje sól._

#### Otwarte pytania

- [ ] [Pytanie], [kto odpowiada], [do kiedy]

Zobacz też: [Dokument projektowy gry](https://nodary.ai/pl/templates/game-design-document#gdd-overview) · [Systemy i ekonomia](https://nodary.ai/pl/templates/game-design-document#gdd-systems) · [Poziomy i zawartość](https://nodary.ai/pl/templates/game-design-document#gdd-levels)

### Systemy i ekonomia

**Właściciel:** [imię i nazwisko] · **Status:** szkic · **Ostatni przegląd:** [data]

_Każdy system w grze, zasady, którym podlega, i liczby, które za nim stoją. Liczby zmieniają się co tydzień: trzymaj je w tabelach lub arkuszach, a tutaj zapisuj uzasadnienie._

#### Systemy

_Jeden wiersz na system. System, który niczego nie zasila, jest dekoracją. System, który zasilają wszystkie pozostałe, jest kręgosłupem gry i zasługuje na własny dokument._

| System | Co robi | Pobiera z | Zasila | Właściciel |
| --- | --- | --- | --- | --- |
| [Wytwarzanie] | [...] | [Ekwipunek] | [Ulepszenia] | [imię i nazwisko] |
| [System] | [...] | [...] | [...] | [...] |

_Przykład (Saltmarrow, przykładowa gra): Każdy system odczytuje pływ: plony zbiorów, szanse na sztorm, ceny we wsi, a nawet to, jak długo postać ma ochotę rozmawiać._

#### Zasoby i waluty

_Dla każdego zasobu: skąd pochodzi (źródła) i dokąd odpływa (ujścia). Ekonomia, która ma więcej źródeł niż ujść, popada w inflację: wypełnij obie kolumny, zanim zaczniesz cokolwiek balansować._

| Zasób | Źródła | Ujścia | Limit |
| --- | --- | --- | --- |
| [Złoto] | [...] | [...] | [brak lub liczba] |
| [Zasób] | [...] | [...] | [...] |

#### Nagrody i szanse na drop

_Tabele łupów, szanse na nagrody i ewentualna gwarancja (pity). Napisz, czego gracz powinien się spodziewać: po ilu próbach przedmiot ma połowa graczy, a po ilu dziewięciu na dziesięciu. Darmowy_ [kalkulator szans na drop](https://nodary.ai/pl/tools/drop-rate-calculator) _wylicza to z tabeli wag._

| Nagroda | Waga | Szansa na próbę | Gwarancja |
| --- | --- | --- | --- |
| [Przedmiot] | [...] | [...] | [brak lub w próbie n] |
| [Przedmiot] | [...] | [...] | [...] |

#### Pokrętła balansu

_Kilka wartości, które projektant zmienia, żeby gra była łatwiejsza, szybsza lub hojniejsza, z obecną wartością i już przetestowanym zakresem. Gdy któraś się zmienia, zapisz powód w dzienniku decyzji w_ [planie produkcji](https://nodary.ai/pl/templates/game-design-document#gdd-production).

| Pokrętło | Obecna wartość | Testowany zakres | Na co wpływa |
| --- | --- | --- | --- |
| [...] | [...] | [...] | [...] |

#### Otwarte pytania

- [ ] [Pytanie], [kto odpowiada], [do kiedy]

Zobacz też: [Rozgrywka](https://nodary.ai/pl/templates/game-design-document#gdd-gameplay) · [Poziomy i zawartość](https://nodary.ai/pl/templates/game-design-document#gdd-levels) · [Plan produkcji](https://nodary.ai/pl/templates/game-design-document#gdd-production)

### Świat, fabuła i postacie

**Właściciel:** [imię i nazwisko] · **Status:** szkic · **Ostatni przegląd:** [data]

_Zasady świata, historia, którą przeżywa gracz, i ludzie, którzy w niej występują. Wiedza o świecie (lore), która nigdy nie dociera do gracza, należy do osobnych dokumentów, podlinkowanych stąd._

#### Realia

_Gdzie i kiedy, w trzech zdaniach, oraz ta jedna zasada tego świata, którą gracz odczuwa w rozgrywce._

_Przykład (Saltmarrow, przykładowa gra): Miasto-biblioteka, które próbowało przetrwać morze, hodując sól. Udało się: sól ocaliła książki i utopiła czytelników. Dwa razy dziennie odpływ je odsłania._

[Twoje realia]

#### Ton

_Trzy słowa, każde z grą, filmem lub książką, które wyznaczają poprzeczkę. Potem to, czym ton nie jest: to rozstrzyga więcej sporów niż to, czym jest._

- Ton: [...]
- Odniesienia: [...]
- Nigdy: [...]

#### Zarys fabuły

_Fabuła tak, jak przeżywa ją gracz, moment po momencie, a nie historia tła. Zapisz, jak każdy moment dociera do gracza: przerywnik filmowy, kwestia dialogowa, znaleziony przedmiot, sam poziom._

| Moment | Co się dzieje | Jak gracz się o tym dowiaduje |
| --- | --- | --- |
| [Otwarcie] | [...] | [...] |
| [Punkt zwrotny] | [...] | [...] |
| [Zakończenie] | [...] | [...] |

#### Postacie

| Postać | Rola w rozgrywce | Czego chce | Jej głos w jednym zdaniu |
| --- | --- | --- | --- |
| [Imię] | [przewodnik, kupiec, rywal] | [...] | [...] |
| [Imię] | [...] | [...] | [...] |

_Gdy postać ma więcej niż kilka kwestii, daj jej własny dokument (profil, referencje, przykładowe dialogi) i podlinkuj go z tej tabeli._

#### Zasady pisania

_Konwencje, których trzyma się każdy autor: imiona i ich pisownia, słowa, których ten świat nigdy nie używa, najdłuższa kwestia, która mieści się na ekranie. Spisane wcześnie, oszczędzają zespołowi lokalizacji tygodnie pracy._

- [Zasada]
- [Zasada]

#### Otwarte pytania

- [ ] [Pytanie], [kto odpowiada], [do kiedy]

Zobacz też: [Dokument projektowy gry](https://nodary.ai/pl/templates/game-design-document#gdd-overview) · [Poziomy i zawartość](https://nodary.ai/pl/templates/game-design-document#gdd-levels) · [Kierunek artystyczny i dźwiękowy](https://nodary.ai/pl/templates/game-design-document#gdd-art)

### Poziomy i zawartość

**Właściciel:** [imię i nazwisko] · **Status:** szkic · **Ostatni przegląd:** [data]

_Każde miejsce, do którego trafia gracz, i każdy element zawartości, którego potrzebuje gra, razem z liczbą sztuk. Ta lista stanie się backlogiem produkcji, więc podawaj uczciwe liczby._

#### Miejsca i poziomy

| Miejsce lub poziom | Rola w grze | Główne mechaniki | Długość | Status |
| --- | --- | --- | --- | --- |
| [Strefa samouczka] | [nauka poruszania się i pętli rozgrywki] | [...] | [10 min] | [blockout, art pass, wersja finalna] |
| [Miejsce] | [...] | [...] | [...] | [...] |

#### Zasady level designu

_Zasady obowiązujące na każdym poziomie: jak gracz jest prowadzony, jak daleko od siebie są punkty kontrolne, jak sygnalizuje się sekrety. Zapisz je raz tutaj, a nie przy każdym poziomie._

- [Zasada]
- [Zasada]

#### Pierwsza godzina

_Pierwsza godzina gracza krok po kroku: co robi, czego się uczy i pierwszy moment, o którym opowiedziałby znajomemu. Większość graczy, którzy rezygnują, rezygnuje właśnie tutaj._

| Minuty | Co robi gracz | Czego się uczy |
| --- | --- | --- |
| od 0 do 5 | [...] | [...] |
| od 5 do 15 | [...] | [...] |
| od 15 do 60 | [...] | [...] |

#### Budżet zawartości

_Ile zawartości każdego rodzaju potrzebuje pierwsze wydanie i kto ją wykona. Porównaj to z_ [planem produkcji](https://nodary.ai/pl/templates/game-design-document#gdd-production)_, zanim ktokolwiek zacznie budować._

| Zawartość | Liczba | Wykonuje | Uwagi |
| --- | --- | --- | --- |
| [Poziomy lub obszary] | [...] | [...] | [...] |
| [Postacie i stwory] | [...] | [...] | [...] |
| [Przedmioty] | [...] | [...] | [...] |
| [Kwestie dialogowe] | [...] | [...] | [...] |
| [Utwory muzyczne] | [...] | [...] | [...] |

#### Otwarte pytania

- [ ] [Pytanie], [kto odpowiada], [do kiedy]

Zobacz też: [Rozgrywka](https://nodary.ai/pl/templates/game-design-document#gdd-gameplay) · [Świat, fabuła i postacie](https://nodary.ai/pl/templates/game-design-document#gdd-world) · [Plan produkcji](https://nodary.ai/pl/templates/game-design-document#gdd-production)

### Kierunek artystyczny i dźwiękowy

**Właściciel:** [imię i nazwisko] · **Status:** szkic · **Ostatni przegląd:** [data]

_Jak gra wygląda i brzmi, opisane na tyle precyzyjnie, żeby dwóch artystów pracujących osobno stworzyło rzeczy, które do siebie pasują._

#### Zasady wizualne

_Trzy do pięciu zasad dotyczących kształtu, koloru, światła i detalu. „Stylizowane” to nie zasada; „każda sylwetka jest czytelna z trzydziestu metrów” to zasada._

- [Zasada]
- [Zasada]
- [Zasada]

#### Referencje

_Dodaj obrazy referencyjne pod każdą zasadą i napisz, co wziąć z każdego z nich: paletę, światło, kształty. Nigdy „wszystko”._

| Referencja | Co bierzemy | Czego unikamy |
| --- | --- | --- |
| [Obraz lub gra] | [...] | [...] |
| [Obraz lub gra] | [...] | [...] |

#### Paleta

| Zastosowanie | Kolor | Uwagi |
| --- | --- | --- |
| [Tło] | [#hex] | [...] |
| [Zagrożenie] | [#hex] | [nigdy jedyny sygnał zagrożenia] |

#### Rodziny assetów

_Co łączy każdą rodzinę assetów, jaki ma budżet (polygony, rozmiar tekstur, klatki) i kto ją zatwierdza._

| Rodzina | Uwagi o stylu | Budżet | Zatwierdza |
| --- | --- | --- | --- |
| [Postacie] | [...] | [...] | [...] |
| [Otoczenie] | [...] | [...] | [...] |
| [Rekwizyty] | [...] | [...] | [...] |
| [Efekty] | [...] | [...] | [...] |

#### Dźwięk

_Nastrój muzyki, efekty dźwiękowe i głosy oraz informacje o grze, które niesie dźwięk: ostrzeżenia, nagrody, upływ czasu._

- Muzyka: [...]
- Efekty dźwiękowe: [...]
- Głosy: [języki i liczba kwestii albo brak]
- Informacje niesione przez dźwięk: [...]

_Przykład (Saltmarrow, przykładowa gra): Dwie minuty przed zmianą pływu nad solniskami rozlega się róg. Pływ widać na ekranie, słychać w miksie i czuć w padzie._

#### Zatwierdzanie

_Kto zatwierdza grafikę i dźwięk, i kiedy. Trzymaj uwagi na samym obrazie, przypięte w miejscu, którego dotyczą: oszczędza to rundę pytań „który, ten po lewej?”_

- Grafikę zatwierdza: [...]
- Dźwięk zatwierdza: [...]

#### Otwarte pytania

- [ ] [Pytanie], [kto odpowiada], [do kiedy]

Zobacz też: [Świat, fabuła i postacie](https://nodary.ai/pl/templates/game-design-document#gdd-world) · [Interfejs i dostępność](https://nodary.ai/pl/templates/game-design-document#gdd-interface)

### Interfejs i dostępność

**Właściciel:** [imię i nazwisko] · **Status:** szkic · **Ostatni przegląd:** [data]

_Wszystko, co gracz czyta, naciska i przegląda, oraz to, jak gra dostosowuje się do graczy, którzy inaczej widzą, słyszą lub się poruszają._

#### Ekrany i przepływ

_Każdy ekran i to, jak gracz przechodzi między nimi od uruchomienia gry do wyjścia. Diagram znajduje ślepe zaułki, zanim ktoś je zbuduje._

```mermaid
flowchart LR
  n0["Ekran tytułowy"]
  n1["Menu główne"]
  n2["Graj"]
  n3["Ustawienia"]
  n4["Pauza"]
  n0 --> n1
  n1 --> n2
  n1 --> n3
  n2 --> n4
  n4 --> n2
  n4 --> n1
```
_Przepływ ekranów_

#### HUD

_Co zostaje na ekranie podczas gry i dlaczego każdy element zasługuje na swoje miejsce. Wszystko, na co gracz zerka rzadziej niż raz na minutę, może trafić do menu._

| Element | Pokazuje | Kiedy jest widoczny | Priorytet |
| --- | --- | --- | --- |
| [Zdrowie] | [...] | [zawsze, w walce, na żądanie] | [wysoki, średni, niski] |
| [Element] | [...] | [...] | [...] |

#### Mapowanie przycisków

| Akcja | Klawiatura i mysz | Pad | Ekran dotykowy |
| --- | --- | --- | --- |
| [Ruch] | [WASD] | [Lewa gałka] | [...] |
| [Interakcja] | [E] | [A / Krzyżyk] | [...] |
| [Pauza] | [Esc] | [Start / Options] | [...] |

#### Dostępność

_Zaznacz każdy punkt albo napisz, dlaczego nie ma zastosowania. Ustalone wcześnie, w większości kosztują niewiele; dodane późno, kosztują dużo._

- [ ] Każdy przycisk można przypisać na nowo
- [ ] Akcje z przytrzymaniem przycisku można zamienić na przełączane
- [ ] Napisy pokazują, kto mówi, a ich rozmiar można zmienić
- [ ] Ważne dźwięki mają też sygnał wizualny
- [ ] Żadna informacja nie jest przekazywana wyłącznie kolorem
- [ ] Tekst można powiększyć
- [ ] Liczniki czasu można spowolnić lub wyłączyć
- [ ] Wstrząsy kamery i błyski można ograniczyć

#### Teksty i języki

_Języki na premierę i zasady, które pozwalają grę przetłumaczyć: żadnego tekstu wtopionego w obrazy, miejsce na tekst nawet o jedną trzecią dłuższy niż angielski, fonty obsługujące każdy system pisma, w którym wydajesz grę._

- Języki na premierę: [...]
- Języki później: [...]
- Fonty: [...]

#### Otwarte pytania

- [ ] [Pytanie], [kto odpowiada], [do kiedy]

Zobacz też: [Rozgrywka](https://nodary.ai/pl/templates/game-design-document#gdd-gameplay) · [Kierunek artystyczny i dźwiękowy](https://nodary.ai/pl/templates/game-design-document#gdd-art) · [Projekt techniczny](https://nodary.ai/pl/templates/game-design-document#gdd-technical)

### Projekt techniczny

**Właściciel:** [imię i nazwisko] · **Status:** szkic · **Ostatni przegląd:** [data]

_Wybory techniczne, które kształtują projekt, i ograniczenia, których projekt musi przestrzegać. Szczegółowa architektura może żyć w dokumentach inżynieryjnych podlinkowanych stąd._

#### Silnik i narzędzia

| Wybór | Decyzja | Dlaczego |
| --- | --- | --- |
| Silnik | [Silnik i wersja] | [...] |
| Języki programowania | [...] | [...] |
| Kontrola wersji | [...] | [...] |
| Buildy i dystrybucja | [...] | [...] |

#### Cele i budżety

_Liczby, według których buduje każdy dział. Bez nich problemy z wydajnością wychodzą na jaw dopiero na końcu._

| Platforma | Klatki na sekundę | Rozdzielczość | Pamięć | Czas ładowania | Rozmiar instalacji |
| --- | --- | --- | --- | --- | --- |
| [PC, wymagania minimalne] | [...] | [...] | [...] | [...] | [...] |
| [Konsola] | [...] | [...] | [...] | [...] | [...] |

#### Architektura

_Główne części kodu gry i to, jak się ze sobą komunikują. Diagram z pięcioma prostokątami jest wart więcej niż pięć stron prozy._

```mermaid
flowchart TD
  n0["Obsługa wejścia"]
  n1["Stan gry"]
  n2["Renderowanie"]
  n3["Audio"]
  n4["Zapis gry"]
  n0 --> n1
  n1 --> n2
  n1 --> n3
  n1 --> n4
```
_Główne systemy_

#### Zapis gry i tryb online

- Zapis gry: [co jest zapisywane, kiedy i gdzie]
- Online: [brak, peer-to-peer, serwery dedykowane]
- Dane graczy: [co jest zbierane i gdzie jest przechowywane]

#### Pipeline

_Jak asset albo linijka tekstu przechodzi od autora do grywalnego buildu i ile to trwa. Wolny pipeline po cichu zmniejsza liczbę iteracji, na które stać zespół._

[Twój pipeline]

#### Ryzyka techniczne

| Ryzyko | Wpływ | Co z tym robimy | Właściciel |
| --- | --- | --- | --- |
| [...] | [...] | [...] | [...] |

#### Otwarte pytania

- [ ] [Pytanie], [kto odpowiada], [do kiedy]

Zobacz też: [Interfejs i dostępność](https://nodary.ai/pl/templates/game-design-document#gdd-interface) · [Plan produkcji](https://nodary.ai/pl/templates/game-design-document#gdd-production)

### Plan produkcji

**Właściciel:** [imię i nazwisko] · **Status:** szkic · **Ostatni przegląd:** [data]

_Kiedy gra wychodzi, kto ją robi, co może ją zatrzymać i każda decyzja podjęta po drodze._

#### Kamienie milowe

| Kamień milowy | Data | Cel | Gotowe, gdy |
| --- | --- | --- | --- |
| [Prototyp] | [...] | [pętla rozgrywki daje frajdę] | [...] |
| [Vertical slice] | [...] | [jeden poziom w finalnej jakości] | [...] |
| [Alpha] | [...] | [wszystkie funkcje w grze, choćby wstępnie] | [...] |
| [Beta] | [...] | [cała zawartość w grze, już tylko poprawki] | [...] |
| [Premiera] | [...] | [...] | [...] |

_„Gotowe, gdy” to kolumna, którą ludzie pomijają. Bez niej kamień milowy jest tylko datą._

#### Zespół

| Rola | Osoba | Odpowiada za dokumenty |
| --- | --- | --- |
| [Dyrektor kreatywny] | [imię i nazwisko] | [Dokument projektowy gry, Rozgrywka] |
| [Rola] | [imię i nazwisko] | [...] |

#### Ryzyka

| Ryzyko | Prawdopodobieństwo | Wpływ | Co z tym robimy | Właściciel |
| --- | --- | --- | --- | --- |
| [...] | [niskie, średnie, wysokie] | [niski, średni, wysoki] | [...] | [...] |

#### Dziennik decyzji

_Każda decyzja, która zmienia projekt: co postanowiono, kto, dlaczego i który dokument się zmienił. Pół roku później, gdy ktoś zapyta, dlaczego coś działa w ten sposób, odpowie ta tabela._

| Data | Decyzja | Kto zdecydował | Dlaczego | Zmieniony dokument |
| --- | --- | --- | --- | --- |
| [data] | [...] | [...] | [...] | [...] |

_Przykład (Saltmarrow, przykładowa gra): 12 września: bez walki, zagrożenie przychodzi tylko od pływu i sztormów. Zdecydowali dyrektor kreatywny i projektant systemów, żeby gra pozostała spokojna, a wyścig z czasem napięty. Zmieniony dokument: filary projektu._

#### Otwarte pytania

- [ ] [Pytanie], [kto odpowiada], [do kiedy]

Zobacz też: [Dokument projektowy gry](https://nodary.ai/pl/templates/game-design-document#gdd-overview) · [Poziomy i zawartość](https://nodary.ai/pl/templates/game-design-document#gdd-levels) · [Projekt techniczny](https://nodary.ai/pl/templates/game-design-document#gdd-technical)

## Jak z niego korzystać

### 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.

### 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.

### 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.

### 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 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.

Strona: https://nodary.ai/pl/templates/game-design-document