# Game-Design-Dokument-Vorlage

Neun verknüpfte Dokumente, die ein Spiel vom Pitch bis zum Entscheidungslog abdecken, jedes mit Hinweisen, was hineingehört, und einem kurzen Beispiel. Laden Sie sie als Markdown-Dateien herunter: Jeder Editor öffnet sie, GitHub und Obsidian zeigen ihre Diagramme, und Nodary importiert sie als Karte.

Kostenlos, ohne Konto und ohne E-Mail-Adresse. Nutzen, ändern und teilen Sie sie, wie Sie möchten.

[Vorlage herunterladen (.zip)](https://nodary.ai/downloads/game-design-dokument-vorlage.zip)

## Lesen Sie jede Seite vor dem Download

Die Übersicht passt auf einen Bildschirm und verweist auf acht Teile, einen pro Disziplin: So hat jeder Teil eine verantwortliche Person, und eine Änderung bleibt klein. Kursive Zeilen sagen, was hineingehört; die Beispiele stammen aus Saltmarrow, dem Beispielspiel, das diese Website überall zeigt.

- Game-Design-Dokument: Die Seite, die alle zuerst lesen: Pitch, Säulen, Zielgruppe, Umfang und ein Link zu jedem Teil.
- Gameplay: Was der Spieler von Minute zu Minute tut und warum er weitermacht.
- Systeme und Ökonomie: Jedes System, seine Regeln, die Ressourcen, die es bewegt, und die Zahlen dahinter.
- Welt, Geschichte und Charaktere: Das Setting und seine Regeln, die Geschichte, die der Spieler erlebt, und die Figuren darin.
- Level und Inhalte: Jeder Ort, den der Spieler besucht, die erste Stunde und wie viele Inhalte das Release braucht.
- Art Direction und Audio: Wie das Spiel aussieht und klingt, so genau, dass zwei Artists, die getrennt arbeiten, trotzdem zusammenpassen.
- Interface und Barrierefreiheit: Screens, HUD und Eingabe, und wie sich das Spiel an jeden Spieler anpasst.
- Technisches Design: Engine, Zielwerte, Architektur und Pipeline, und die Grenzen, die sie dem Design setzen.
- Produktionsplan: Meilensteine, Team, Risiken und das Log jeder Entscheidung, die das Design verändert hat.

### Game-Design-Dokument

_So verwenden Sie diese Vorlage: Kursive Zeilen sind Hinweise. Ersetzen Sie sie durch Ihre eigenen Worte und löschen Sie sie dann. Werte in eckigen Klammern füllen Sie selbst aus. Halten Sie diese Seite bei etwa einem Bildschirm: Alle lesen sie zuerst, und jeder andere Teil des Designs ist nur einen Link entfernt._

#### Auf einen Blick

| Feld | Ihr Spiel |
| --- | --- |
| Arbeitstitel | [Titel] |
| Logline | [Ein Satz, den ein Fremder weitererzählen könnte] |
| Genre | [Genre und Subgenre] |
| Spieler | [Singleplayer, Koop für 2 bis 4, kompetitiv] |
| Plattformen | [PC, Konsolen, Mobile] |
| Sessionlänge | [Eine typische Session, in Minuten] |
| Engine | [Engine und Version] |
| Team | [Größe heute und in der Spitze] |
| Geschäftsmodell | [Preis, Free-to-Play, Abo] |
| Nächster Meilenstein | [Name und Datum] |

#### Pitch

_Zwei oder drei Sätze: Wer spielt, was tut man, und was macht das Spiel anders? Schreiben Sie ihn so, dass er auch auf einer Store-Seite funktionieren würde._

_Beispiel (Saltmarrow, ein Beispielspiel): Salz rechen, nach Erinnerungen tauchen, vor der Flut zurück sein. Ein Koop-Spiel über Erkundung und Crafting für bis zu vier Spieler, angesiedelt auf Salzebenen im Watt, wo zweimal am Tag eine versunkene Archivstadt auftaucht._

[Ihr Pitch]

#### Design-Säulen

_Drei bis fünf Regeln, denen jedes Feature dienen muss. Eine Säule, die jedes beliebige Spiel beschreiben könnte, etwa „spaßige Kämpfe“, ist keine Säule. Ein Feature, das keiner Säule dient, fliegt raus; ein Feature, das eine Säule bricht, wird neu entworfen._

1. **[Erste Säule]**: [was sie bedeutet, in einem Satz]
2. **[Zweite Säule]**: [was sie bedeutet, in einem Satz]
3. **[Dritte Säule]**: [was sie bedeutet, in einem Satz]

_Beispiel (Saltmarrow, ein Beispielspiel): Die Gezeiten sind die Uhr. Zeit ist die einzige Ressource, die nie mehr wird: Jedes System liest die Gezeiten, und nichts hält sie an._

#### Zielgruppe

_Für wen das Spiel ist, was diese Spieler heute spielen und wann sie aufhören. Nennen Sie echte Spiele und echte Gewohnheiten, nicht nur eine Altersgruppe._

- Kernspieler: [wer sie sind und wie sie spielen]
- Was sie heute spielen: [drei oder vier Spiele]
- Wann sie aufhören: [...]
- Weitere Spieler: [...]

#### Vergleichbare Spiele

_Drei oder vier Spiele, die Ihr Team und Ihre Spieler schon kennen. Sagen Sie, was Sie von jedem übernehmen und, genauso nützlich, was Sie weglassen._

| Spiel | Was wir übernehmen | Was wir weglassen |
| --- | --- | --- |
| [Spiel] | [...] | [...] |
| [Spiel] | [...] | [...] |
| [Spiel] | [...] | [...] |

#### Umfang

_Was das erste Release enthält und was ausdrücklich nicht. Die zweite Liste ist die, die verhindert, dass der Umfang still und leise wächst._

- Im ersten Release: [...]
- Nicht im ersten Release: [...]
- Später zu entscheiden: [...]

#### Der Rest des Designs

_Jeder Teil ist ein eigenes Dokument. Verlinken Sie ihn, statt daraus zu kopieren: So steht jeder Fakt an einer Stelle und ändert sich an einer Stelle._

- [Gameplay](https://nodary.ai/de/templates/game-design-document#gdd-gameplay): Core Loop, Mechaniken, Steuerung und Progression
- [Systeme und Ökonomie](https://nodary.ai/de/templates/game-design-document#gdd-systems): jedes System, seine Regeln und seine Zahlen
- [Welt, Geschichte und Charaktere](https://nodary.ai/de/templates/game-design-document#gdd-world): das Setting, die Geschichte und die Figuren darin
- [Level und Inhalte](https://nodary.ai/de/templates/game-design-document#gdd-levels): jeder Ort, die erste Stunde und das Content-Budget
- [Art Direction und Audio](https://nodary.ai/de/templates/game-design-document#gdd-art): wie das Spiel aussieht und klingt
- [Interface und Barrierefreiheit](https://nodary.ai/de/templates/game-design-document#gdd-interface): Screens, HUD, Eingabe und Barrierefreiheit
- [Technisches Design](https://nodary.ai/de/templates/game-design-document#gdd-technical): Engine, Zielwerte, Architektur und Pipeline
- [Produktionsplan](https://nodary.ai/de/templates/game-design-document#gdd-production): Meilensteine, Team, Risiken und das Entscheidungslog

_Diese Vorlage dürfen Sie kostenlos nutzen, ändern und weitergeben. Entstanden ist sie bei_ [Nodary](https://nodary.ai/de)_, wo sich diese Dateien als Karte verknüpfter Dokumente importieren lassen._

### Gameplay

**Verantwortlich:** [Name] · **Status:** Entwurf · **Zuletzt geprüft:** [Datum]

_Was der Spieler von Minute zu Minute tut und warum er weitermacht. Beginnen Sie mit dem Loop: Alles andere in diesem Dokument hängt daran._

#### Core Loop

_Der Loop, den der Spieler am häufigsten wiederholt, in vier bis sechs Verben. Kann das Team ihn nicht aufzeichnen, steht er noch nicht fest._

```mermaid
flowchart LR
  n0["Planen"]
  n1["Erkunden"]
  n2["Sammeln"]
  n3["Craften"]
  n4["Verbessern"]
  n0 --> n1
  n1 --> n2
  n2 --> n3
  n3 --> n4
  n4 --> n0
```
_Der Core Loop, etwa [n] Minuten pro Durchlauf_

| Phase | Typische Dauer | Die Frage des Spielers |
| --- | --- | --- |
| [Planen] | [2 Min.] | [Welches Ziel diesmal, und was nehme ich mit?] |
| [Erkunden] | [...] | [...] |
| [Sammeln] | [...] | [...] |

_Beispiel (Saltmarrow, ein Beispielspiel): Ernten oder tauchen, 8 bis 14 Minuten: sicheres Salz rechen oder nach Kristallen tauchen, die vielleicht mehr wert sind? Jede Phase sollte dem Spieler eine Frage stellen. Eine Phase ohne Frage ist bloße Fleißarbeit._

#### Mechaniken

_Eine Zeile pro Mechanik. Die Säulen-Spalte hält jede ehrlich: Eine Mechanik, die keiner Säule dient, landet auf der Streichliste._

| Mechanik | Was der Spieler tut | Dient der Säule | Status |
| --- | --- | --- | --- |
| [Mechanik] | [...] | [...] | [Idee, Prototyp, festgelegt] |
| [Mechanik] | [...] | [...] | [...] |

#### Steuerung

_Die Verben des Spielers und wie sich jedes anfühlen soll. Die Tastenbelegung für jedes Gerät steht in_ [Interface und Barrierefreiheit](https://nodary.ai/de/templates/game-design-document#gdd-interface).

- [Verb]: [wie es ausgeführt wird und wie es sich anfühlen soll]
- [Verb]: [...]

#### Progression

_Was innerhalb einer Session und über das ganze Spiel wächst, und wie der Spieler dieses Wachstum sieht. Nennen Sie das Langzeitziel._

- Innerhalb einer Session: [...]
- Über mehrere Sessions: [...]
- Langzeitziel: [...]

#### Herausforderung und Scheitern

_Wie die Schwierigkeit steigt, was Scheitern kostet und wie der Spieler wieder einsteigt. Ein Scheitern, das nur Zeit kostet, lehrt weniger als eines, das eine Entscheidung kostet._

- Die Schwierigkeit steigt durch: [...]
- Scheitern kostet: [...]
- Wiedereinstieg: [...]

_Beispiel (Saltmarrow, ein Beispielspiel): Wer beim Ertönen des Horns noch im Archiv ist, verliert die Kristalle in seiner Tasche und taucht am nächsten Turm wieder auf; sein Salz behält er._

#### Offene Fragen

- [ ] [Frage], [wer sie beantwortet], [bis wann]

Siehe auch: [Game-Design-Dokument](https://nodary.ai/de/templates/game-design-document#gdd-overview) · [Systeme und Ökonomie](https://nodary.ai/de/templates/game-design-document#gdd-systems) · [Level und Inhalte](https://nodary.ai/de/templates/game-design-document#gdd-levels)

### Systeme und Ökonomie

**Verantwortlich:** [Name] · **Status:** Entwurf · **Zuletzt geprüft:** [Datum]

_Jedes System im Spiel, seine Regeln und die Zahlen dahinter. Zahlen ändern sich jede Woche: Führen Sie sie in Tabellen oder Tabellenkalkulationen, und halten Sie die Begründung hier fest._

#### Systeme

_Eine Zeile pro System. Ein System, das nirgendwohin einfließt, ist Dekoration. Ein System, in das alles einfließt, ist das Rückgrat Ihres Spiels und verdient ein eigenes Dokument._

| System | Was es tut | Liest aus | Fließt in | Verantwortlich |
| --- | --- | --- | --- | --- |
| [Crafting] | [...] | [Inventar] | [Upgrades] | [Name] |
| [System] | [...] | [...] | [...] | [...] |

_Beispiel (Saltmarrow, ein Beispielspiel): Jedes System liest die Gezeiten: Ernteerträge, Sturmwahrscheinlichkeit, Preise im Dorf, sogar wie lange eine Figur gesprächsbereit ist._

#### Ressourcen und Währungen

_Für jede Ressource: woher sie kommt (Quellen) und wohin sie geht (Senken). Eine Ökonomie mit mehr Quellen als Senken gerät in die Inflation: Füllen Sie beide Spalten aus, bevor Sie irgendetwas am Balancing drehen._

| Ressource | Quellen | Senken | Obergrenze |
| --- | --- | --- | --- |
| [Gold] | [...] | [...] | [keine, oder eine Zahl] |
| [Ressource] | [...] | [...] | [...] |

#### Belohnungen und Drop-Rates

_Loot-Tabellen, Belohnungschancen und eine etwaige Pity-Regel. Sagen Sie, was ein Spieler erwarten kann: wie viele Versuche, bis die Hälfte der Spieler einen Gegenstand hat, und bis neun von zehn ihn haben. Der kostenlose_ [Drop-Rate-Rechner](https://nodary.ai/de/tools/drop-rate-calculator) _rechnet das aus einer Tabelle mit Gewichten aus._

| Belohnung | Gewicht | Chance pro Versuch | Garantiert bei |
| --- | --- | --- | --- |
| [Gegenstand] | [...] | [...] | [keine, oder Versuch n] |
| [Gegenstand] | [...] | [...] | [...] |

#### Stellschrauben

_Die wenigen Werte, die ein Designer ändert, um das Spiel leichter, schneller oder großzügiger zu machen, mit dem aktuellen Wert und dem bereits getesteten Bereich. Ändert sich einer, notieren Sie den Grund im Entscheidungslog des_ [Produktionsplans](https://nodary.ai/de/templates/game-design-document#gdd-production).

| Stellschraube | Aktueller Wert | Getesteter Bereich | Wirkt auf |
| --- | --- | --- | --- |
| [...] | [...] | [...] | [...] |

#### Offene Fragen

- [ ] [Frage], [wer sie beantwortet], [bis wann]

Siehe auch: [Gameplay](https://nodary.ai/de/templates/game-design-document#gdd-gameplay) · [Level und Inhalte](https://nodary.ai/de/templates/game-design-document#gdd-levels) · [Produktionsplan](https://nodary.ai/de/templates/game-design-document#gdd-production)

### Welt, Geschichte und Charaktere

**Verantwortlich:** [Name] · **Status:** Entwurf · **Zuletzt geprüft:** [Datum]

_Die Regeln der Welt, die Geschichte, die der Spieler erlebt, und die Figuren darin. Lore, die den Spieler nie erreicht, gehört in eigene Dokumente, die von hier aus verlinkt sind._

#### Setting

_Wo und wann, in drei Sätzen, und die eine Regel dieser Welt, die der Spieler beim Spielen spürt._

_Beispiel (Saltmarrow, ein Beispielspiel): Eine Bibliotheksstadt, die das Meer überdauern wollte, indem sie Salz wachsen ließ. Es funktionierte: Das Salz bewahrte die Bücher und ertränkte die Leser. Zweimal am Tag legt die Ebbe sie frei._

[Ihr Setting]

#### Tonalität

_Drei Wörter, jedes mit einem Spiel, Film oder Buch, das die Messlatte setzt. Dann, was die Tonalität nicht ist: Das entscheidet mehr Diskussionen als das, was sie ist._

- Tonalität: [...]
- Referenzen: [...]
- Niemals: [...]

#### Handlung im Überblick

_Die Geschichte, wie der Spieler sie erlebt, Station für Station, nicht die Vorgeschichte. Notieren Sie, wie jede Station beim Spieler ankommt: als Cutscene, als Dialogzeile, als gefundener Gegenstand, durch das Level selbst._

| Station | Was passiert | Wie der Spieler es erfährt |
| --- | --- | --- |
| [Auftakt] | [...] | [...] |
| [Wendepunkt] | [...] | [...] |
| [Ende] | [...] | [...] |

#### Charaktere

| Charakter | Rolle im Spiel | Ziel | Stimme in einer Zeile |
| --- | --- | --- | --- |
| [Name] | [Mentor, Händler, Rivale] | [...] | [...] |
| [Name] | [...] | [...] | [...] |

_Sobald ein Charakter mehr als ein paar Zeilen hat, bekommt er ein eigenes Dokument (Profil, Referenzen, Beispieldialoge), das aus dieser Tabelle verlinkt wird._

#### Schreibregeln

_Die Konventionen, an die sich alle halten, die schreiben: Namen und Schreibweisen, Wörter, die diese Welt nie benutzt, die längste Zeile, die auf den Bildschirm passt. Früh festgelegt, sparen sie dem Lokalisierungsteam Wochen._

- [Regel]
- [Regel]

#### Offene Fragen

- [ ] [Frage], [wer sie beantwortet], [bis wann]

Siehe auch: [Game-Design-Dokument](https://nodary.ai/de/templates/game-design-document#gdd-overview) · [Level und Inhalte](https://nodary.ai/de/templates/game-design-document#gdd-levels) · [Art Direction und Audio](https://nodary.ai/de/templates/game-design-document#gdd-art)

### Level und Inhalte

**Verantwortlich:** [Name] · **Status:** Entwurf · **Zuletzt geprüft:** [Datum]

_Jeder Ort, den der Spieler besucht, und jeder Inhalt, den das Spiel braucht, jeweils mit Stückzahl. Diese Liste wird zum Produktions-Backlog, also bleiben Sie bei den Zahlen ehrlich._

#### Orte und Level

| Ort oder Level | Zweck im Spiel | Hauptmechaniken | Dauer | Status |
| --- | --- | --- | --- | --- |
| [Tutorial-Bereich] | [Bewegung und Core Loop beibringen] | [...] | [10 Min.] | [Blockout, Art-Pass, final] |
| [Ort] | [...] | [...] | [...] | [...] |

#### Level-Design-Regeln

_Regeln, die in jedem Level gelten: wie der Spieler geführt wird, wie weit Checkpoints auseinanderliegen, wie Geheimnisse angezeigt werden. Schreiben Sie sie einmal hier statt in jedes Level._

- [Regel]
- [Regel]

#### Die erste Stunde

_Die erste Stunde des Spielers, Schritt für Schritt: was er tut, was er lernt und der erste Moment, von dem er Freunden erzählen würde. Die meisten, die aufhören, hören hier auf._

| Minuten | Was der Spieler tut | Was er lernt |
| --- | --- | --- |
| 0 bis 5 | [...] | [...] |
| 5 bis 15 | [...] | [...] |
| 15 bis 60 | [...] | [...] |

#### Content-Budget

_Wie viel von jeder Art Inhalt das erste Release braucht und wer ihn erstellt. Gleichen Sie es mit dem_ [Produktionsplan](https://nodary.ai/de/templates/game-design-document#gdd-production) _ab, bevor jemand mit dem Bauen beginnt._

| Inhalt | Anzahl | Erstellt von | Notizen |
| --- | --- | --- | --- |
| [Level oder Gebiete] | [...] | [...] | [...] |
| [Charaktere und Kreaturen] | [...] | [...] | [...] |
| [Gegenstände] | [...] | [...] | [...] |
| [Dialogzeilen] | [...] | [...] | [...] |
| [Musikstücke] | [...] | [...] | [...] |

#### Offene Fragen

- [ ] [Frage], [wer sie beantwortet], [bis wann]

Siehe auch: [Gameplay](https://nodary.ai/de/templates/game-design-document#gdd-gameplay) · [Welt, Geschichte und Charaktere](https://nodary.ai/de/templates/game-design-document#gdd-world) · [Produktionsplan](https://nodary.ai/de/templates/game-design-document#gdd-production)

### Art Direction und Audio

**Verantwortlich:** [Name] · **Status:** Entwurf · **Zuletzt geprüft:** [Datum]

_Wie das Spiel aussieht und klingt, so genau beschrieben, dass zwei Artists, die getrennt arbeiten, Arbeiten liefern, die zusammenpassen._

#### Visuelle Regeln

_Drei bis fünf Regeln zu Form, Farbe, Licht und Detail. „Stilisiert“ ist keine Regel; „jede Silhouette ist auf dreißig Meter lesbar“ schon._

- [Regel]
- [Regel]
- [Regel]

#### Referenzen

_Fügen Sie unter jeder Regel Referenzbilder ein und sagen Sie, was man von jedem übernimmt: die Palette, das Licht, die Formen. Niemals „alles“._

| Referenz | Was wir übernehmen | Was wir vermeiden |
| --- | --- | --- |
| [Bild oder Spiel] | [...] | [...] |
| [Bild oder Spiel] | [...] | [...] |

#### Palette

| Verwendung | Farbe | Notizen |
| --- | --- | --- |
| [Hintergrund] | [#hex] | [...] |
| [Gefahr] | [#hex] | [nie das einzige Zeichen für Gefahr] |

#### Asset-Familien

_Was jede Asset-Familie gemeinsam hat, ihr Budget (Polygone, Texturgröße, Frames) und wer sie abnimmt._

| Familie | Stilnotizen | Budget | Abgenommen von |
| --- | --- | --- | --- |
| [Charaktere] | [...] | [...] | [...] |
| [Umgebungen] | [...] | [...] | [...] |
| [Props] | [...] | [...] | [...] |
| [Effekte] | [...] | [...] | [...] |

#### Audio

_Die Stimmung von Musik, Soundeffekten und Stimmen, und die Spielinformationen, die der Sound transportiert: Warnungen, Belohnungen, das Vergehen der Zeit._

- Musik: [...]
- Soundeffekte: [...]
- Sprachausgabe: [Sprachen und Anzahl der Zeilen, oder keine]
- Informationen über Sound: [...]

_Beispiel (Saltmarrow, ein Beispielspiel): Zwei Minuten vor dem Gezeitenwechsel hallt ein Horn über die Salzebenen. Die Gezeiten sieht man auf dem Bildschirm, hört sie im Mix und spürt sie im Controller._

#### Abnahmen

_Wer Art und Audio abnimmt, und wann. Halten Sie Feedback direkt auf dem Bild fest, an der Stelle, um die es geht: Das spart eine Runde „Welches, das links?“_

- Art wird abgenommen von: [...]
- Audio wird abgenommen von: [...]

#### Offene Fragen

- [ ] [Frage], [wer sie beantwortet], [bis wann]

Siehe auch: [Welt, Geschichte und Charaktere](https://nodary.ai/de/templates/game-design-document#gdd-world) · [Interface und Barrierefreiheit](https://nodary.ai/de/templates/game-design-document#gdd-interface)

### Interface und Barrierefreiheit

**Verantwortlich:** [Name] · **Status:** Entwurf · **Zuletzt geprüft:** [Datum]

_Alles, was der Spieler liest, drückt und ansteuert, und wie sich das Spiel an Spieler anpasst, die anders sehen, hören oder sich anders bewegen._

#### Screens und Ablauf

_Jeder Screen und wie der Spieler vom Start bis zum Beenden zwischen ihnen wechselt. Ein Diagramm findet die Sackgassen, bevor sie gebaut werden._

```mermaid
flowchart LR
  n0["Titelbildschirm"]
  n1["Hauptmenü"]
  n2["Spielen"]
  n3["Einstellungen"]
  n4["Pause"]
  n0 --> n1
  n1 --> n2
  n1 --> n3
  n2 --> n4
  n4 --> n2
  n4 --> n1
```
_Ablauf der Screens_

#### HUD

_Was während des Spielens auf dem Bildschirm bleibt, und warum jedes Element seinen Platz verdient. Was der Spieler seltener als einmal pro Minute prüft, kann in ein Menü wandern._

| Element | Zeigt | Wann sichtbar | Priorität |
| --- | --- | --- | --- |
| [Lebenspunkte] | [...] | [immer, im Kampf, auf Abruf] | [hoch, mittel, niedrig] |
| [Element] | [...] | [...] | [...] |

#### Eingabe

| Aktion | Tastatur und Maus | Controller | Touch |
| --- | --- | --- | --- |
| [Bewegen] | [WASD] | [Linker Stick] | [...] |
| [Interagieren] | [E] | [A / Kreuz] | [...] |
| [Pause] | [Esc] | [Start / Options] | [...] |

#### Barrierefreiheit

_Haken Sie jeden Punkt ab oder schreiben Sie, warum er nicht zutrifft. Früh entschieden, kosten die meisten wenig; spät nachgerüstet, kosten sie viel._

- [ ] Jede Eingabe lässt sich neu belegen
- [ ] Halte-Aktionen lassen sich auf Umschalten umstellen
- [ ] Untertitel zeigen, wer spricht, und ihre Größe ist einstellbar
- [ ] Wichtige Sounds haben auch ein visuelles Signal
- [ ] Keine Information wird allein über Farbe vermittelt
- [ ] Text lässt sich vergrößern
- [ ] Timer lassen sich verlangsamen oder abschalten
- [ ] Kamerawackeln und Blitzeffekte lassen sich reduzieren

#### Text und Sprachen

_Die Sprachen zum Launch und die Regeln, die Übersetzung möglich halten: kein Text in Bildern, Platz für Texte, die bis zu einem Drittel länger sind als im Englischen, Schriften, die jedes ausgelieferte Schriftsystem abdecken._

- Sprachen zum Launch: [...]
- Spätere Sprachen: [...]
- Schriften: [...]

#### Offene Fragen

- [ ] [Frage], [wer sie beantwortet], [bis wann]

Siehe auch: [Gameplay](https://nodary.ai/de/templates/game-design-document#gdd-gameplay) · [Art Direction und Audio](https://nodary.ai/de/templates/game-design-document#gdd-art) · [Technisches Design](https://nodary.ai/de/templates/game-design-document#gdd-technical)

### Technisches Design

**Verantwortlich:** [Name] · **Status:** Entwurf · **Zuletzt geprüft:** [Datum]

_Die technischen Entscheidungen, die das Design prägen, und die Grenzen, die das Design einhalten muss. Die detaillierte Architektur kann in Engineering-Dokumenten stehen, die von hier aus verlinkt sind._

#### Engine und Tools

| Bereich | Entscheidung | Warum |
| --- | --- | --- |
| Engine | [Engine und Version] | [...] |
| Programmiersprachen | [...] | [...] |
| Versionskontrolle | [...] | [...] |
| Builds und Distribution | [...] | [...] |

#### Zielwerte und Budgets

_Die Zahlen, auf die jede Abteilung hinarbeitet. Ohne sie fallen Performance-Probleme erst am Ende auf._

| Plattform | Framerate | Auflösung | Speicher | Ladezeit | Installationsgröße |
| --- | --- | --- | --- | --- | --- |
| [PC, Mindestanforderungen] | [...] | [...] | [...] | [...] | [...] |
| [Konsole] | [...] | [...] | [...] | [...] | [...] |

#### Architektur

_Die Hauptbestandteile des Spielcodes und wie sie miteinander kommunizieren. Ein Diagramm mit fünf Kästen schlägt fünf Seiten Fließtext._

```mermaid
flowchart TD
  n0["Eingabe"]
  n1["Spielzustand"]
  n2["Rendering"]
  n3["Audio"]
  n4["Speicherstände"]
  n0 --> n1
  n1 --> n2
  n1 --> n3
  n1 --> n4
```
_Hauptsysteme_

#### Speichern und Online

- Speicherstände: [was gespeichert wird, wann und wo]
- Online: [keins, Peer-to-Peer, dedizierte Server]
- Spielerdaten: [was erhoben wird und wo es liegt]

#### Pipeline

_Wie ein Asset oder eine Textzeile von der Person, die es erstellt, in einen spielbaren Build gelangt, und wie lange das dauert. Eine langsame Pipeline kürzt still und leise die Zahl der Iterationen, die ein Team bekommt._

[Ihre Pipeline]

#### Technische Risiken

| Risiko | Auswirkung | Was wir dagegen tun | Verantwortlich |
| --- | --- | --- | --- |
| [...] | [...] | [...] | [...] |

#### Offene Fragen

- [ ] [Frage], [wer sie beantwortet], [bis wann]

Siehe auch: [Interface und Barrierefreiheit](https://nodary.ai/de/templates/game-design-document#gdd-interface) · [Produktionsplan](https://nodary.ai/de/templates/game-design-document#gdd-production)

### Produktionsplan

**Verantwortlich:** [Name] · **Status:** Entwurf · **Zuletzt geprüft:** [Datum]

_Wann das Spiel erscheint, wer es macht, was es aufhalten könnte, und jede Entscheidung, die unterwegs getroffen wurde._

#### Meilensteine

| Meilenstein | Datum | Ziel | Erreicht, wenn |
| --- | --- | --- | --- |
| [Prototyp] | [...] | [der Core Loop macht Spaß] | [...] |
| [Vertical Slice] | [...] | [ein Level in finaler Qualität] | [...] |
| [Alpha] | [...] | [alle Features drin, grob] | [...] |
| [Beta] | [...] | [alle Inhalte drin, nur noch Bugfixing] | [...] |
| [Release] | [...] | [...] | [...] |

_„Erreicht, wenn“ ist die Spalte, die gern übersprungen wird. Ohne sie ist ein Meilenstein nur ein Datum._

#### Team

| Rolle | Person | Verantwortet diese Dokumente |
| --- | --- | --- |
| [Creative Director] | [Name] | [Game-Design-Dokument, Gameplay] |
| [Rolle] | [Name] | [...] |

#### Risiken

| Risiko | Wahrscheinlichkeit | Auswirkung | Was wir dagegen tun | Verantwortlich |
| --- | --- | --- | --- | --- |
| [...] | [niedrig, mittel, hoch] | [niedrig, mittel, hoch] | [...] | [...] |

#### Entscheidungslog

_Jede Entscheidung, die das Design verändert: was entschieden wurde, von wem, warum und welches Dokument sich geändert hat. Wenn in sechs Monaten jemand fragt, warum es so funktioniert, beantwortet diese Tabelle die Frage._

| Datum | Entscheidung | Entschieden von | Warum | Geändertes Dokument |
| --- | --- | --- | --- | --- |
| [Datum] | [...] | [...] | [...] | [...] |

_Beispiel (Saltmarrow, ein Beispielspiel): 12. September: kein Kampf, die Bedrohung kommt nur von Gezeiten und Stürmen. Entschieden von Creative Director und Systems Designer, damit das Spiel ruhig und der Zeitplan straff bleibt. Geändertes Dokument: die Design-Säulen._

#### Offene Fragen

- [ ] [Frage], [wer sie beantwortet], [bis wann]

Siehe auch: [Game-Design-Dokument](https://nodary.ai/de/templates/game-design-document#gdd-overview) · [Level und Inhalte](https://nodary.ai/de/templates/game-design-document#gdd-levels) · [Technisches Design](https://nodary.ai/de/templates/game-design-document#gdd-technical)

## So verwenden Sie die Vorlage

### Schreiben Sie die Übersicht in einem Zug

Füllen Sie zuerst die Tabelle, den Pitch und die Säulen aus, in etwa einer Stunde und gemeinsam mit den Leuten, die das Spiel bauen. Jede andere Seite wird daran gemessen.

### Füllen Sie die Teile, sobald Entscheidungen fallen

Lassen Sie einen Abschnitt lieber leer, als etwas zu erfinden. Ein leerer Abschnitt ist eine ehrliche offene Frage; ein erfundener wird gebaut.

### Halten Sie jede Entscheidung fest

Ändert eine Entscheidung das Design, fügen Sie dem Entscheidungslog im Produktionsplan eine Zeile hinzu und aktualisieren Sie die betroffene Seite. Das Log sagt, warum; die Seite sagt, was jetzt gilt.

### Geben Sie jeder Seite eine verantwortliche Person

Jeder Teil nennt, wer ihn verantwortet und wann er zuletzt geprüft wurde. Eine Seite, für die niemand zuständig ist, veraltet als erste.

## In Nodary als Karte importieren

Nodary ist ein Arbeitsbereich für Spieleteams, in dem Dokumente wie Sterne auf einer Karte verknüpft sind. Importieren Sie das .zip, und die Übersicht kommt mit ihren acht Teilen darunter an, die Verknüpfungen zwischen den Seiten bleiben erhalten und die Diagramme werden gezeichnet. Ihr Team kommentiert dann Passagen, fordert Prüfungen an und sieht, was sich seit dem letzten Besuch geändert hat, und über MCP verbundene KI-Agenten lesen das Design, bevor sie darin schreiben.

1. Öffnen Sie die Karte eines Projekts und wählen Sie „Importieren“.
2. Wählen Sie den Tab „Ordner oder ZIP“ und dann „ZIP wählen“.
3. Wählen Sie die heruntergeladene Datei, prüfen Sie die Baumstruktur und importieren Sie.

Der kostenlose Tarif umfasst zehn Dokumente pro Arbeitsbereich, die Seite des Projekts selbst eingerechnet: Die neun Dokumente der Vorlage passen in einen neuen Arbeitsbereich und füllen ihn. Bezahlte Tarife bieten Platz für mehr.

## Ein GDD schreiben, das wirklich gelesen wird

Ein Game-Design-Dokument scheitert auf eine von zwei Arten: Niemand liest es, oder alle lesen eine veraltete Fassung. Diese Gewohnheiten verhindern beides.

### Eine Seite pro Teil

Eine Datei mit sechzig Seiten wird einmal gelesen, am Anfang. Kurze, verknüpfte Seiten werden gelesen, wenn es darauf ankommt, und eine Änderung betrifft eine Seite statt fünf.

### Entscheidungen schreiben, keine Wünsche

„Der Kampf soll sich gut anfühlen“ entscheidet nichts. „Ein Treffer landet innerhalb von 100 Millisekunden nach dem Tastendruck“ lässt sich bauen und testen.

### Sagen, was noch offen ist

Markieren Sie unbeantwortete Fragen als offen, mit der Person, die sie beantwortet, und einem Termin. Eine Vermutung, die als Tatsache dasteht, ist der Grund, warum zwei Abteilungen am Ende zwei verschiedene Spiele bauen.

### Verlinken statt kopieren

Braucht die Seite zur Ökonomie den Gezeitenkalender, verlinkt sie ihn. Ein Fakt, der an zwei Stellen steht, sagt bald zwei verschiedene Dinge.

### Das Warum bewahren

Das Entscheidungslog hält fest, warum die Dinge so sind, wie sie sind, damit ein neues Teammitglied keine Entscheidung rückgängig macht, für die das Team schon bezahlt hat.

### Streichen, was niemand liest

Wurde ein Abschnitt seit dem Schreiben nie wieder geöffnet, führen Sie ihn mit einem anderen zusammen oder löschen Sie ihn. Ein kurzes Dokument, das stimmt, schlägt ein langes, das einmal gestimmt hat.

## Fragen zum Game-Design-Dokument

### Was ist ein Game-Design-Dokument?

Ein Game-Design-Dokument, kurz GDD, beschreibt das Spiel, das ein Team entwickelt: Pitch, Säulen, Mechaniken, Systeme, Welt, Level, Look und Sound sowie den Plan, es zu bauen. Design, Art, Programmierung, Produktion und zunehmend auch KI-Agenten lesen es, also muss es aktuell bleiben, während sich das Spiel verändert.

### Was gehört in ein Game-Design-Dokument?

Mindestens eine einseitige Übersicht mit Pitch, Säulen, Zielgruppe und Umfang; das Gameplay und der Core Loop; die Systeme und ihre Zahlen; Welt und Geschichte; Level und Inhalte; Art Direction und Audio; Interface und Barrierefreiheit; die technischen Rahmenbedingungen; und ein Produktionsplan mit Entscheidungslog. Diese Vorlage hat für jeden Punkt ein eigenes Dokument.

### Wie lang sollte ein GDD sein?

So kurz wie möglich, solange es die Fragen des Teams beantwortet. Die Übersicht sollte auf einen Bildschirm passen. Jeder Teil wächst mit den getroffenen Entscheidungen, nicht mit den Hoffnungen: Eine Seite mit festen Regeln schlägt zehn Seiten voller Möglichkeiten.

### Brauchen Indie- und agile Teams überhaupt noch ein GDD?

Solche Teams brauchen schriftlich festgehaltene Entscheidungen, keine Bibel, die vorab geschrieben wird. Wer schnell iteriert, nutzt das GDD als Stand dessen, was das Spiel heute ist: kurze Seiten, aktualisiert, wenn ein Playtest etwas ändert, und die Gründe im Entscheidungslog.

### In welchem Format ist die Vorlage?

Markdown: reine Textdateien, die jeder Editor öffnet. Verweise zwischen Dokumenten sind relative Links, Tabellen sind Markdown-Tabellen, und Diagramme sind in Mermaid geschrieben, das GitHub, Obsidian und Nodary zeichnen. Nichts hängt von einem bestimmten Tool ab.

### Kann ich die Vorlage in Obsidian, auf GitHub oder in einem anderen Editor nutzen?

Ja. Obsidian öffnet den entpackten Ordner als Vault, in dem jeder Link funktioniert, und GitHub zeigt die Dateien mit ihren Links und Diagrammen. Tools, die Markdown Datei für Datei importieren, übernehmen Text und Tabellen; prüfen Sie, wie sie mit Links zwischen Dateien umgehen.

### Wie importiere ich die Vorlage in Nodary?

Öffnen Sie die Karte eines Projekts, wählen Sie „Importieren“, dann den Tab „Ordner oder ZIP“, und wählen Sie das heruntergeladene .zip. Nodary zeigt zuerst die Baumstruktur, legt dann die neun Dokumente mit der Übersicht als übergeordnetem Dokument an, behält die Links zwischen ihnen und zeichnet die Diagramme. Jeder Ordner und jedes .zip mit bis zu 200 Markdown-Dateien wird genauso importiert.

### Darf ich die Vorlage für ein kommerzielles Spiel nutzen?

Ja. Nutzen, ändern und teilen Sie sie für jedes Spiel, kommerziell oder nicht, mit oder ohne Nodary-Konto. Eine Erwähnung freut uns, ist aber nie Pflicht.

Die Seite: https://nodary.ai/de/templates/game-design-document