Bevor ein Videospiel programmiert, gezeichnet oder vertont wird, muss es geplant werden. Und diese Planung findet in einem Dokument statt, das in der Branche als Game Design Document bekannt ist, kurz GDD. Es ist die Blaupause des Spiels, der Masterplan, die zentrale Referenz für alle Beteiligten. Ohne ein GDD wäre die Entwicklung eines Videospiels wie der Bau eines Hauses ohne Architekturplan: chaotisch, ineffizient und zum Scheitern verurteilt.
Das Game Design Document beschreibt, was das Spiel sein soll. Nicht wie es technisch umgesetzt wird, das ist Aufgabe anderer Dokumente, sondern was der Spieler erleben soll. Welche Mechaniken gibt es? Wie funktioniert die Steuerung? Welche Geschichte wird erzählt? Wie sieht die Welt aus? Welche Charaktere bevölkern sie? All diese Fragen und hunderte mehr werden im GDD beantwortet, sodass jedes Teammitglied genau weiß, woran es arbeitet und warum.
Wozu braucht man ein Game Design Document?
Man könnte meinen, dass ein kleines Team, das eng zusammenarbeitet, kein formelles Dokument braucht. Die Leute reden doch miteinander, oder? In der Praxis zeigt sich jedoch schnell, warum ein GDD unverzichtbar ist, selbst für kleine Teams.
Das offensichtlichste Problem ohne GDD ist Inkonsistenz. Wenn der Programmierer eine andere Vorstellung vom Kampfsystem hat als der Designer, der eine andere Vorstellung hat als der Künstler, dann entstehen Konflikte. Arbeit muss verworfen werden, Zeit geht verloren, Frustration baut sich auf. Ein GDD schafft eine gemeinsame Grundlage, auf die sich alle beziehen können. Es ist die einzige Wahrheit, die Single Source of Truth.
Ein weiterer Vorteil ist die Dokumentation von Entscheidungen. In der Hitze der Entwicklung werden unzählige Entscheidungen getroffen. Warum haben wir uns für dieses Kampfsystem entschieden? Warum hat der Held drei Leben und nicht fünf? Warum gibt es keine Sprungfunktion? Ohne schriftliche Dokumentation gehen die Gründe für solche Entscheidungen verloren. Das GDD bewahrt sie für die Zukunft auf und verhindert, dass dieselben Diskussionen immer wieder geführt werden.
Für größere Teams und vor allem für die Kommunikation mit Publishern und Investoren ist ein GDD ohnehin unverzichtbar. Wer Geld für ein Spiel geben soll, will wissen, was er dafür bekommt. Ein professionelles GDD zeigt, dass das Team einen klaren Plan hat und weiß, was es tut. Es ist ein Vertrauensbeweis und oft die Grundlage für Finanzierungsentscheidungen.
Was steht in einem Game Design Document?
Es gibt keine universelle Vorlage für ein GDD. Jedes Studio hat seine eigenen Standards, und jedes Projekt stellt andere Anforderungen. Ein kleines Puzzle-Spiel braucht weniger Dokumentation als ein weitläufiges Rollenspiel. Dennoch gibt es typische Bestandteile, die in den meisten GDDs vorkommen.
Die Vision und das Konzept
Am Anfang steht die große Idee. Was für ein Spiel soll es werden? Welches Erlebnis soll der Spieler haben? Dieser Abschnitt beschreibt die Vision in klaren, prägnanten Worten. Oft findet sich hier auch der Elevator Pitch, also eine Zusammenfassung des Spiels in ein bis zwei Sätzen, die man einem Fremden im Aufzug erklären könnte.
Vergleiche mit anderen Spielen sind hier üblich und hilfreich. „Dark Souls trifft auf Zelda“ vermittelt in vier Worten mehr als Seiten von Beschreibungen. Natürlich muss das GDD später ins Detail gehen, aber ein starker Einstieg schafft sofort ein gemeinsames Verständnis.
Spielmechaniken
Das Herzstück des GDD sind die Spielmechaniken. Hier wird beschrieben, wie das Spiel tatsächlich funktioniert. Was kann der Spieler tun? Wie interagiert er mit der Welt? Welche Systeme greifen ineinander?
Die Beschreibung der Kernmechanik ist besonders wichtig. Was ist das Zentrale, das das Spiel ausmacht? Bei einem Plattformer ist es das Springen. Bei einem Shooter das Schießen. Bei einem Rätselspiel das Lösen von Puzzles. Diese Kernmechanik muss sich gut anfühlen, denn der Spieler wird sie tausende Male ausführen. Das GDD beschreibt, wie sie funktionieren soll und welches Gefühl sie vermitteln soll.
Darüber hinaus werden alle weiteren Systeme dokumentiert: Kampf, Bewegung, Inventar, Crafting, Handel, Dialoge, Fortschritt, Belohnungen und so weiter. Je komplexer das Spiel, desto umfangreicher dieser Abschnitt. Für ein Rollenspiel können allein die Kampfmechaniken dutzende Seiten füllen.
Steuerung und Interface
Wie steuert der Spieler das Spiel? Welche Taste macht was? Wie sieht das Menü aus? Wo werden Informationen angezeigt? Die Steuerung ist entscheidend für das Spielgefühl und verdient daher einen eigenen Abschnitt im GDD.
Oft werden hier Diagramme und Mockups verwendet. Ein Bild der Controller-Belegung, ein Entwurf des Hauptmenüs, ein Wireframe des HUD. Visuelle Darstellungen vermitteln diese Informationen oft besser als Text allein.
Welt und Setting
In welcher Welt spielt das Spiel? Dieser Abschnitt beschreibt das Setting: die Zeit, den Ort, die Atmosphäre. Ist es eine mittelalterliche Fantasywelt? Eine dystopische Zukunft? Ein buntes Cartoon-Universum? Das Setting beeinflusst jeden anderen Aspekt des Spiels, von der Grafik über die Musik bis zu den Spielmechaniken.
Bei Open-World-Spielen wird hier oft auch die Struktur der Welt beschrieben. Welche Regionen gibt es? Wie hängen sie zusammen? Welche Orte sind besonders wichtig? Karten und Diagramme ergänzen die textuelle Beschreibung.
Geschichte und Charaktere
Wenn das Spiel eine Geschichte erzählt, wird sie im GDD zusammengefasst. Nicht in allen Details, dafür gibt es oft ein separates Story-Dokument, aber in den Grundzügen. Was ist der zentrale Konflikt? Wer ist der Protagonist? Wer sind die Antagonisten? Welche wichtigen Wendepunkte gibt es?
Die Hauptcharaktere werden vorgestellt: ihre Hintergründe, ihre Motivationen, ihre Persönlichkeiten. Auch wichtige Nebencharaktere finden hier Erwähnung. Concept Art ergänzt die Beschreibungen und gibt dem Team eine visuelle Vorstellung von den Figuren.
Progression und Balance
Wie entwickelt sich der Spieler im Verlauf des Spiels? Dieser Abschnitt beschreibt das Fortschrittssystem: Erfahrungspunkte, Level, Fähigkeitsbäume, Ausrüstung, oder was auch immer das Spiel verwendet. Die Lernkurve wird skizziert: Was lernt der Spieler wann? Wie steigt die Schwierigkeit?
Balance ist ein Thema, das sich durch das gesamte GDD zieht, aber hier explizit angesprochen wird. Wie stark sollen Gegner sein? Wie viel Schaden macht eine Waffe? Wie teuer sind Items? Diese Zahlen sind zu Beginn der Entwicklung nur Schätzungen und werden später intensiv getestet und angepasst, aber das GDD bietet einen Ausgangspunkt.
Technische Anforderungen
Obwohl das GDD primär das Design beschreibt, enthält es oft auch technische Informationen. Auf welchen Plattformen soll das Spiel erscheinen? Welche Engine wird verwendet? Welche besonderen technischen Features sind geplant? Diese Informationen helfen dem technischen Team bei der Planung.
Audio und Musik
Der Abschnitt über Audio beschreibt die akustische Identität des Spiels. Welchen Stil soll die Musik haben? Orchestral, elektronisch, minimalistisch? Wie wird adaptive Musik eingesetzt? Welche wichtigen Soundeffekte braucht das Spiel? Gibt es Sprachausgabe, und wenn ja, in welchem Umfang?
Monetarisierung
Bei kommerziellen Spielen darf dieser Abschnitt nicht fehlen. Wie verdient das Spiel Geld? Ist es ein Vollpreisspiel? Early Access? Free-to-Play mit Mikrotransaktionen? Gibt es DLCs oder einen Season Pass? Die Monetarisierungsstrategie beeinflusst viele Designentscheidungen und muss früh festgelegt werden.
Wer schreibt das Game Design Document?
Die Hauptverantwortung für das GDD liegt beim Game Designer oder Lead Designer. Diese Person entwickelt die Vision des Spiels und dokumentiert sie im GDD. In kleinen Teams kann das eine einzelne Person sein, in großen Studios ein ganzes Team von Designern, jeder zuständig für einen bestimmten Bereich.
Aber das GDD ist kein Einzelwerk. Es entsteht in Zusammenarbeit mit dem gesamten Team. Programmierer geben Feedback zur technischen Machbarkeit. Künstler kommentieren die visuellen Beschreibungen. Produzenten achten auf Umfang und Zeitplanung. Das GDD ist ein lebendiges Dokument, das sich durch diese Zusammenarbeit entwickelt und verfeinert.
Auch nach Beginn der Produktion bleibt das GDD nicht statisch. Wenn neue Ideen entstehen oder sich bestehende Pläne als unpraktikabel erweisen, wird das GDD aktualisiert. Versionskontrolle ist dabei wichtig: Jeder muss wissen, welche Version die aktuelle ist, und Änderungen sollten dokumentiert werden.
Wie lang ist ein Game Design Document?
Die Länge eines GDD variiert enorm. Ein simples Mobile-Spiel kommt vielleicht mit zehn bis zwanzig Seiten aus. Ein komplexes Rollenspiel kann ein GDD von mehreren hundert Seiten haben. Das berühmte GDD von Diablo, das online kursiert, umfasst etwa 80 Seiten, und das für ein Spiel, das nach heutigen Maßstäben überschaubar ist.
Wichtiger als die Länge ist die Klarheit. Ein kurzes, präzises GDD ist besser als ein langes, verworrenes. Das Dokument soll kommunizieren, nicht beeindrucken. Jeder Satz, der nicht zum Verständnis beiträgt, ist überflüssig. Bilder, Diagramme und Tabellen können oft mehr vermitteln als Textabsätze und sollten großzügig eingesetzt werden.
Manche Studios bevorzugen modulare GDDs, die aus mehreren separaten Dokumenten bestehen: eines für die Kernmechaniken, eines für die Geschichte, eines für die Level, und so weiter. Dieser Ansatz macht es einfacher, einzelne Bereiche zu aktualisieren, ohne das gesamte Dokument anfassen zu müssen.
GDD vs. Pitch Document vs. One-Pager
Das GDD ist nicht das einzige Dokument in der Spieleentwicklung. Es existiert neben anderen Dokumenten, die unterschiedliche Zwecke erfüllen.
Der One-Pager ist, wie der Name sagt, eine einseitige Zusammenfassung des Spiels. Er enthält das Wichtigste auf einen Blick: Konzept, Genre, Plattformen, Zielgruppe, Alleinstellungsmerkmale. Der One-Pager ist oft das erste Dokument, das erstellt wird, und dient dazu, die Grundidee schnell zu kommunizieren.
Das Pitch Document ist eine Erweiterung des One-Pagers, gedacht für Präsentationen bei Publishern oder Investoren. Es ist visuell ansprechend, enthält Concept Art und Screenshots (oder Mockups), und betont die Verkaufsargumente des Spiels. Während das GDD intern orientiert ist, richtet sich das Pitch Document nach außen.
Das GDD selbst ist das umfassendste Dokument und richtet sich primär an das Entwicklerteam. Es ist weniger auf Überzeugung ausgelegt als auf Information. Jedes Detail, das für die Produktion relevant ist, findet hier seinen Platz.
Die Grenzen des GDD
So wichtig das GDD ist, es hat auch Grenzen. Ein häufiger Fehler ist, zu früh zu viel zu dokumentieren. In der frühen Konzeptphase sind viele Details noch unklar und werden sich ändern. Ein zu detailliertes GDD zu diesem Zeitpunkt ist Zeitverschwendung und kann sogar hinderlich sein, wenn das Team sich zu sehr an veraltete Pläne klammert.
Ein gutes GDD findet die Balance zwischen Planung und Flexibilität. Es legt die Vision und die Grundprinzipien fest, lässt aber Raum für Entdeckungen während der Entwicklung. Manche der besten Features entstehen spontan, durch Experimente und glückliche Zufälle. Ein zu rigides GDD kann solche Entdeckungen verhindern.
Es gibt sogar Stimmen in der Branche, die das klassische GDD für veraltet halten. Agile Entwicklungsmethoden setzen auf iterative Prozesse und enge Zusammenarbeit statt auf umfangreiche Vorabplanung. In solchen Umgebungen werden oft schlankere Dokumentationsformen bevorzugt, etwa Wiki-Systeme oder Kanban-Boards. Dennoch bleibt das Grundprinzip bestehen: Irgendwo muss dokumentiert sein, was das Spiel sein soll.
Fazit
Das Game Design Document ist ein Werkzeug, kein Selbstzweck. Es dient dazu, eine Vision zu kommunizieren, ein Team zu koordinieren und Entscheidungen zu dokumentieren. Sein Wert liegt nicht in seiner Länge oder seiner Perfektion, sondern darin, ob es seinen Zweck erfüllt: allen Beteiligten zu sagen, woran sie arbeiten und warum.
Für angehende Game Designer ist das Schreiben eines GDD eine wertvolle Übung, selbst wenn das beschriebene Spiel nie produziert wird. Es zwingt dazu, Ideen zu durchdenken, Systeme zu Ende zu denken und Visionen in konkrete Pläne zu verwandeln. Die Fähigkeit, ein Spiel klar und vollständig zu beschreiben, ist eine der wichtigsten Kompetenzen eines Game Designers.
Und für Spieler, die sich fragen, wie ihre Lieblingsspiele entstehen: Das GDD ist der Ort, an dem alles beginnt. Bevor der erste Pixel gezeichnet und die erste Zeile Code geschrieben wird, steht irgendwo ein Dokument, das beschreibt, was dieses Spiel werden soll. Das Game Design Document ist die Brücke zwischen der Idee und der Realität.
Häufig gestellte Fragen (FAQ)
Was ist der Unterschied zwischen GDD und TDD?
Das GDD (Game Design Document) beschreibt, was das Spiel sein soll: Mechaniken, Geschichte, Welt. Das TDD (Technical Design Document) beschreibt, wie es technisch umgesetzt wird: Architektur, Systeme, Tools. Beide Dokumente ergänzen sich und werden oft parallel erstellt.
Braucht jedes Spiel ein GDD?
Theoretisch nicht, praktisch ja. Selbst Solo-Entwickler profitieren davon, ihre Ideen aufzuschreiben, um Klarheit zu gewinnen und Entscheidungen festzuhalten. Die Form kann variieren, von einem formellen Dokument bis zu einem Notizbuch, aber irgendeine Art von Dokumentation ist fast immer hilfreich.
Wie aktuell muss ein GDD sein?
Das GDD sollte immer den aktuellen Plan widerspiegeln. Veraltete Informationen können zu Verwirrung und Fehlern führen. In der Praxis ist es eine Herausforderung, das GDD aktuell zu halten, besonders bei schnellen Änderungen. Viele Teams nutzen daher Wiki-Systeme, die einfacher zu aktualisieren sind als klassische Dokumente.
Kann man GDD-Beispiele finden?
Ja, einige GDDs sind öffentlich verfügbar. Das ursprüngliche GDD von Diablo ist online zu finden und bietet interessante Einblicke. Auch manche Indie-Entwickler teilen ihre GDDs. Diese Beispiele sind wertvoll, sollten aber nicht als Vorlagen missverstanden werden, da jedes Projekt andere Anforderungen hat.
Wer hat Zugriff auf das GDD?
In der Regel das gesamte Entwicklerteam. Das GDD ist ein internes Dokument und enthält oft vertrauliche Informationen über unveröffentlichte Projekte. Es wird normalerweise nicht öffentlich geteilt, zumindest nicht bis lange nach der Veröffentlichung des Spiels.
Ersetzt ein GDD die Kommunikation im Team?
Auf keinen Fall. Das GDD ist ein Kommunikationswerkzeug, kein Ersatz für Gespräche. Es dokumentiert Entscheidungen und schafft eine gemeinsame Grundlage, aber die eigentliche Arbeit geschieht im Austausch zwischen den Teammitgliedern. Ein GDD, das niemand liest, ist wertlos.
