GDD

Das Game Design Document (GDD) soll einen Eindruck vom zu erstellenden Spiel vermitteln, noch bevor die Arbeit daran beginnt. Es ist das Äquivalent zum Lastenheft bei "regulären" Softwareprojekten und stellt somit auch einen Featurekatalog und eine Zusammenfassung der Funktionalität dar.

Bestandteile des GDDs

Deckblatt

Das Deckblatt sollte folgende Informationen beinhalten: Name des Spiels, Namen der Gruppenmitglieder, Name des Tutors, Gruppennummer, Datum der Erstellung.

Spielkonzept

Zusammenfassung des Spiels

Hier ist ein kurzer einleitender Text evtl. in Verbindung mit einem Bild gefragt. Ziel ist es, das zu erstellende Spiel in kurzen Sätzen zu erklären und die Grundidee zu erläutern. Für die Zusammenfassung kann man sich an den "Klappentexten" auf der Rückseite von Spieleverpackungen orientieren. Der Text darf als einziger im GDD auch reißerisch und dramatisch sein (abgesehen vom Screenplay).

Alleinstellungsmerkmal

Was hebt dieses Spiel von der Masse ab? Wodurch versucht man, den Spieler (und den Kunden) zu begeistern? Das Alleinstellungsmerkmal ist das Merkmal des Spiels, welches es einzigartig macht. Ein Alleinstellungsmerkmal kann sowohl ein Feature, als auch ein gesamtes Konzept des Spiels sein.

Benutzeroberfläche

Hier wird erklärt, mit welchen Eingaben und über welche Steuerelemente der Spieler mit dem Spiel interagiert.

Spieler-Interface

Dieser Abschnitt beinhaltet eine Beschreibung des Spielbildschirms, also dessen, was für den Spieler sichtbar ist. Dies beinhaltet die Art der Darstellung (2D oder 3D), die Kamerasicht, usw. Wichtig ist, dass alle sichtbaren Elemente, wie Minimap, Menüleiste, etc. erklärt werden. Durch ein Bild eines typischen Vertreters dieser Spielart oder durch eine Konzeptzeichnung des Interfaces kann die Beschreibung noch verbessert werden.

Außerdem wird in diesem Abschnitt erklärt, wie der Spieler das Spiel steuert (mit der Maus, mit Maus und Tastatur, Joystick, Gamepad usw.). Alle Aktionen, die der Spieler durchführen kann, müssen erklärt werden. Auch mögliche Shortcuts und/oder Tastenkombinationen sollten hier erwähnt werden.

Menü-Struktur

Bei der Beschreibung der Menü-Struktur wird erklärt, wie das Hauptmenü und alle Ingame-Menüs zueinander in Beziehung stehen. Hilfreich dazu kann ein Diagramm in Form eines Graphen oder Baums sein. Wichtig ist, dass ersichtlich wird, welche Aktion im Menü welche Reaktion des Interfaces verursacht. Beispiel: "Wenn man im Einstellungsmenü auf 'Zurück' klickt, gelangt man zurück ins Hauptmenü." Ebenso wichtig ist die Vollständigkeit der Beschreibung. Jedes Menü und jedes Untermenü sollten erklärt werden.

Technische Merkmale

Die technischen Merkmale beinhalten eine Übersicht über die unterschiedlichen Technologien, welche im Spiel verwendet werden.

Verwendete Technologien

In diesem Abschnitt sollten alle verwendeten Technologien, die zur Erstellung des Spiels wichtig sind, stichpunktartig erwähnt werden. Das beinhaltet XNA ebenso wie eventuell verwendete externe Bibliotheken. Auch die Programme, die verwendet werden, um Modelle, Grafiken und Sounds zu erstellen werden hier erwähnt. Wenn zusätzliche Programme, wie zum Beispiel Physik Engines, vom Spiel vorausgesetzt werden, wird dies hier ebenso erwähnt.

Hardwarevoraussetzungen

Dieser Abschnitt ist von der Form her vergleichbar mit den Hardwarevoraussetzungen, die auf Spieleverpackungen gedruckt sind. Er beinhaltet die minimale Hardware, die notwendig ist, um das Spiel flüssig spielen zu können. Um die Hardwarevoraussetzungen zu ermitteln, gibt es unterschiedliche Möglichkeiten:

• Die Hardwarespezifikationen des schlechtesten PCs eines Gruppenmitglieds, auf dem das Spiel noch ohne Probleme läuft
• Die Ausstattung der Pool-Rechner (falls kein Gruppenmitglied einen PC hat, auf dem das Spiel lauffähig ist)

Achtung: Jedes Spiel muss auf den Pool-Rechnern spielbar sein.

Spiellogik

In diesem Abschnitt wird die gesamte Spielmechanik und alle im Spiel vorkommenden Spielobjekte erklärt. Sinn dieses Abschnittes ist es, eine Übersicht über alle Interaktionen des Spielers mit der Spielwelt und den Spielobjekten zu erhalten.

Optionen & Aktionen

Dieser Abschnitt beinhaltet die Aktionen, die der Spieler vornehmen kann, um den Zustand des Spiels zu verändern. Zum Beispiel, das Bauen von Einheiten oder das Abbauen von Ressourcen. Je klarer diese Aktionen formuliert sind, desto leichter fällt einem die Umsetzung der Aktionen bei der Programmierung des Spiels. Wichtig sind auch die Einstellungen, die der Spieler am Spiel vornehmen kann, um das Spielverhalten zu verändern (zum Beispiel: Schwierigkeitsgrad ändern). Das Ziel des Spiels sollte schließlich anhand der beschriebenen Aktionen erklärt werden.

Spielobjekte

Hier sind alle Spielobjekte aufgelistet, die es im Spiel gibt. Dies können zum Beispiel Einheiten, Gebäude, Hindernisse usw. sein. Hilfreich zum Verständnis und zur Identifizierung der einzelnen Objekte können Bilder sein. Wichtig sind hier alle Eigenschaften und Fähigkeiten der unterschiedlichen Objekte. Sind sie zum Beispiel einfach zu zerstören, kosten sie viele Ressourcen, usw. Spielobjekte können hier auch schon mit konkreten Werten versehen werden. Wichtig sind dabei nicht die exakten Werte der unterschiedlichen Objekte, wie zum Beispiel die Lebenspunkte einer Einheit, sondern lediglich die Verhältnisse, also zum Beispiel: Welche Einheit ist stärker als eine andere? Dass sich konkrete Werte noch verändern können, ist selbstverständlich, und eine Frage des Balancings gegen Ende des Projekts.

Spielstruktur

Dieser Abschnitt erklärt den Ablauf des Spiels. Das heißt, hier wird beschreiben, was geschieht, sobald der Spieler ein neues Spiel beginnt und wie sich das Spiel von dort aus entwickelt, bis es gewonnen oder verloren ist. Eine Beschreibung der unterschiedlichen Spielphasen ist hier essenziell. Eine mögliche Einteilung der Spielphasen von Schach ist zum Beispiel: Early-Game (Eröffnung), Mid-Game (strategische Positionen festigen), Late-Game (wenn nur noch wenige Figuren auf dem Brett sind).

Eine weitere wichtige Information in diesem Abschnitt ist, welche Modi das Spiel hat (zum Beispiel Missionen und wie sie sich unterscheiden vs. Endlosmodus und wie dieser während des Spiels verändert wird). Weiterhin ist wichtig, wie die Dynamik des Spiels ist (Beispiel: statisch vs. actionreich und dynamisch). Auch mögliche Taktiken und Strategien im Spiel können hier beschrieben werden.

Statistiken

Statistiken erlauben es einem Spieler, sich mit anderen Spielern zu messen und zu entscheiden, wer besser ist und sind heutzutage ein wichtiger Bestandteil von nahezu jedem Spiel. In diesem Abschnitt wird erklärt, welche unterschiedlichen Statistiken während des Spiels gesammelt werden, wie sie Einfluss auf das Spielgeschehen geben und wodurch die unterschiedlichen Werte während des Spiels geändert werden. Das einfachste Beispiel für Statistiken sind Highscore-Listen, in denen die größte erreichte Punktzahl eines Spieldurchlaufs pro Spieler aufgelistet ist.

Spiele müssen nicht unbedingt Statistiken enthalten, sie sind jedoch ein einfaches Mittel, die Langzeitmotivation zu erhöhen.

Aufwandsabschätzung

Dieser Abschnitt enthält eine tabellarische Auflistung jedes Elements des Spiels mit der abgeschätzten Zeit, die es benötigen wird, das Element zu verwirklichen. Insbesondere sollten hier alle notwendigen Anforderungen an das Spiel enthalten sein, sowie alle Optionen und Aktionen.

Rechnen Sie hierbei mit einem Richtwert für die Gesamtarbeitszeit von ca. 140h pro Person über den Verlauf des Semesters hinweg. Diese Zahl ergibt sich aus dem Gesamtaufwand von 180h pro Person für das Softwarepraktikum abzüglich der Stundenaufwendung für Präsentationen, Vorlesungen und Gruppentreffen.

Screenplay

Dieser Abschnitt beinhaltet die Hintergrundgeschichte (Story) des Spiels. Eine Story ist wichtig für ein Spiel, um zu erklären, warum bestimmte Aktionen durchgeführt werden können, oder nicht. Eine Story ist auch ein einfacher Weg, um eine Umgebung zu schaffen, mit der sich ein Spieler identifizieren kann und Spaß daran hat, die Umgebung zu erforschen und sich darin zu bewegen.

Konzeptzeichnungen & Storyboards

Bilder sind wichtig für den ersten Eindruck. Vor allem im GDD machen sich Konzeptzeichnungen und Skizzen gut. Auf diese Weise kann man nicht nur sich selbst schnell eine Vorstellung von den Ideen machen, sondern auch anderen vermitteln, worum es im Spiel geht und wie das Spiel und seine Geschichte aussieht.

Allgemeine Hinweise

Bilder sollten auf jeden Fall im GDD vorhanden sein. Sie vermitteln die beste Vorstellung davon wie das fertige Spiel einmal aussehen könnte und welche Richtung ihr euch dafür wünscht. Mit dem GDD versucht man, das eigene Spiel zu 'bewerben' und es sollte entsprechend gewissenhaft gestaltet sein. Auf der anderen Seite muss man sich darüber im Klaren sein, dass einmal im GDD versprochene Features bindend sind.

Um euch Verbesserungsarbeit zu sparen, die auf euch zukommen könnte, beachtet bitte die folgenden Punkte beim Schreiben eures GDDs, die auch bei anderen schriftlichen Arbeiten im Studium Verwendung finden:

• Keine leeren Referenzen benutzen: Im GDD nicht auf etwas verweisen, das nicht existiert. Zum Beispiel, nicht auf eine Minimap verweisen, wenn diese gar nicht im Spiel vorhanden ist. Außerdem nicht auf einen Teil des GDDs verweisen, der nicht existiert. Also zum Beispiel: "Der Spezialangriff des Panzers kann andere Einheiten sofort zerstören." obwohl der Panzer in eurer Einheitenbeschreibung überhaupt keinen Spezialangriff hat.
• Keine Vorwärtsreferenzen benutzen: Das bedeutet, im Text nicht auf eine Stelle des Textes verweisen, die erst später kommt. Beispiel: In Kapitel 2 schreiben, "Die Details werden in Kapitel 4 erklärt." Alle Sachverhalte, die zum Erklären einer Sache notwendig sind, vorher erklären und sich dann darauf beziehen.
• Abbildungen und Tabellen: Abbildungen und Tabellen benötigen immer einen Titel und müssen aus dem Text heraus referenziert und erklärt werden. Eine Abbildung oder eine Tabelle ohne Referenz ist nichts wert, da man nicht weiß, wo sie einzuordnen ist.
• Konsistenz: Gleiche Dinge müssen immer gleich benannt werden. Benutzt man eine andere Bezeichnung für eine Sache, die man vorher anders genannt hat, fehlt der Zusammenhang. Das ist auch schon der Fall, wenn man z.B. "Einheit" und "Objekt" als Synonym verwendet. In diesem Fall z.B. durchgängig "Einheit" verwenden.
• Keine mehrdeutigen Referenzen innerhalb von Sätzen: Sätze wie "Der Spieler hat die Möglichkeit, einen Panzer zu steuern. Dabei sieht er feindliche Einheiten." sind mehrdeutig. Das "er" im zweiten Satz könnte sich entweder auf den Spieler oder auf den Panzer beziehen. Wenn etwas beschrieben wird, muss klar sein, auf was man sich bezieht.
• Alles begünden: Achtet darauf, dass ihr bei Erklärungen begründet, warum die Dinge sind, wie sie sind. Beispiel: "Ein Panzer kann nur einmal existieren." An dieser Stelle fragt sich der Leser, wieso das der Fall ist. Besser wäre hier: "Ein Panzer kann nur einmal existieren, da der Spieler sonst einen zu großen Vorteil gegenüber seinem Gegner erlangen würde."
• Die hier verwendete Reihenfolge der Abschnitte ist u.U. nicht dazu geeignet, diese Hinweise umzusetzen. Ordnet daher die verschiedenen Abschnitte so, wie es für euer Spiel am Besten passt.

Um einige Beispiele zu sehen, könnt ihr euch die GDDs der letzten Jahre in unserer Hall of Fame anschauen.

Externe Quellen

• Gamasutra
• Gamedev
• Introduction to Computer Game Design & Development