GDD

Aus Das Sopra Wiki

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.

Änderungsliste

Falls in der finalen Abgabe des GDDs Features nach Absprache mit den Dozente geändert oder entfernt worden sind, sollten diese Änderungen am Anfang des GDDs in einem eigenen Abschnitt kurz beschrieben sein. Falls es keine Änderungen in relation zum GDD gibt, entfällt dieser Abschnitt.

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

Zentrale Spielmechanik

Dieser Abschnitt beschreibt die zentrale Mechanik des Spiels, d.h., welcher Teil des gesamten Spielablaufs der wichtigste für das Spiel und den Spieler ist. Üblicherweise verbringt der Spieler die meiste Zeit in ihrem Spiel mit diesem Ablauf und dieser Teil sollte entsprechend viel Aufmerksamkeit bei der Entwicklung bekommen. Die Beschreibung der zentralen Spielmechanik sollte so kompakt wie möglich gehalten werden und dabei die Rolle des Spielers, sein Ziel und die grundsätzlich dafür notwendigen Aktionen beschreiben.

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. In der finalen Version des GDDs können auch Screenshots des eigenen Spiels verwendet 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.

Mindestvoraussetzungen

Dieser Abschnitt ist von der Form her vergleichbar mit den Mindestvoraussetzungen, die auf Spieleverpackungen gedruckt sind. Er beinhaltet die minimale Hardware, die notwendig ist, um das Spiel flüssig spielen zu können, sowie die benötigte Software und Bibliotheken. Um die Hardwarevoraussetzungen zu ermitteln, sollte man sich an der Zielgruppe und den Entwicklern orientieren, d.h. typischerweise das Schlechtere aus den folgenden Mengen:

  • Die Hardwarespezifikationen des schlechtesten PCs eines Gruppenmitglieds, auf dem das Spiel noch ohne Probleme läuft.
  • Die Hardwarespezifikationen des Tutors.
  • Die Hardwarespezifikationen der Dozenten.

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 Spieler oder KI vornehmen können, 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.

Die Auflistung der Optionen und Aktionen erfolgt tabellarisch und ist in Form und Inhalt an Use Cases angelehnt.

Beispiel für tabellarische Auflistung von Aktionen
ID/Name Akteure Ereignisfluss Anfangsbedingungen Abschlussbedingungen
ID01: Figur durch Klick bewegen Spieler
  1. Der Spieler klickt mit der Rechten Maustaste auf einen Punkt in der Welt.
  2. Die Spielfiguren bewegen sich ausgehend von ihrer aktuellen Position auf den ausgewählten Punkt in der Welt zu.
  3. Verhalten in der Bewegung:
    • Ist der Zielpunkt nicht erreichbar, versuchen die Spielfiguren den Punkt zu erreichen, der noch begehbar ist und die kürzeste Entfernung zum Zielpunkt aufweist.
    • Die Spielfiguren gelangen immer auf dem kürzesten Weg zum Ziel.
    • Die Spielfiguren umlaufen Hindernisse rechtzeitig.
  4. Die Spielfiguren erreichen den Zielpunkt.
 Der Spieler muss eine oder mehr kontrollierbare, auswählbare Spielfiguren ausgewählt haben. Die Spielfiguren befinden sich am Zielpunkt,

ODER

die Spielfiguren befinden an einem begehbaren Punkt in der Welt, der möglichst nah am Ziekpunkt liegt.

ID02: Gegner automatisch angreifen Spieler oder KI
  1. Die eigene Einheit bewegt sich auf die gegnerische Einheit zu, bis sie in Kampfreichweite ist.
  2. Aktion 07: Kämpfen wird initiiert.
 Eine Einheit mit Fähigkeit "Kämpfen" muss vorhanden sein. Eine gegnerische Einheit befindet sich im Sichtradius der kämpfenden Einheit. Die Einheit kämpft gegen die gegnerische Einheit.
ID03: ... ... ... ... ...

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. Insbesondere erklärt dieser Abschnitt 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. Wenn noch keine konkreten Werte vorliegen (z.B. wie viele Lebenspunkte eine bestimmte Einheit hat), sollten zumindest die Verhältnisse der Werte von unterschiedlichen Spieleobjekten aufgelistet werden, 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). Außerdem soll die Dynamik des Spiels beschrieben werden (Beispiel: statisch, d.h. wenig Veränderungen an der Spielwelt und den Mechaniken 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 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.

Achievements

Ähnlich wie auch das Sammeln von Statistiken erhöht die Möglichkeit, Achievements, also besondere Erfolge und Heldentaten, zu erreichen, die Langzeitmotivation des Spielers. In diesem Abschnitt werden daher die unterschiedlichen Achievements und die Bedingungen, wie diese erreicht werden können, aufgelistet. Achievements können verschiedene Schwierigkeitsstufen besitzen, um sie zu erreichen. Achievements mit unterschiedlichen Schwierigkeitsstufen sind z.B.: "Zerstöre 2000 gegnerische Einheiten" vs. "Schaffe das gesamte Spiel, ohne einen Schuss abzufeuern".

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 sind Konzeptzeichnungen und Skizzen gut aufgehoben. 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. Außerdem muss man sich darüber im Klaren sein, dass einmal im GDD versprochene Features bindend sind und bei der Benotung und Bewertung des Spiels berücksichtigt werden.

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." Alles, was zum Erklären einer Sache notwendig ist, muss vorher erklärt sein.
  • 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 und wie sie im Text 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 begrü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.

Relevanz für die Benotung

Das GDD ist nicht nur die Zusammenfassung der Funktionalität für die Entwickler, sondern auch die Schnittstelle zu den Kunden. Das bedeutet, dass die Kunden zum einen anhand des GDDs die Erfüllung der Anforderungen überprüfen, zum anderen die im GDD beschriebenen Features im Endprodukt sehen möchten.

Im Softwarepraktikum bedeutet das konkret:

  • Anhand der Abgabe des GDDs überprüfen die Dozenten, ob das hier beschriebene Spiel geeignet ist, die Anforderungen zu erfüllen und ob die Implementierung zu umfangreich für den Zeitrahmen ist. Die Dozenten geben dazu Feedback in Form von Reviews und/oder persönlichen Treffen.
  • Anhand der Final-Abgabe des GDDs und den Anforderungen wird die Benotung des Endproduktes vorgenommen, d.h. es wird geprüft, ob alle Anforderungen erfüllt und alle im finalen GDD beschriebenen Features vorhanden sind.

Daraus ergibt sich auch zwingend, dass die im GDD versprochenen Features nicht ohne Rücksprache geändert oder entfernt werden dürfen. Nur das Konkretisieren und das Hinzufügen von Features ist erlaubt. Sollten Sie nach Rücksprache Änderungen oder Entfernungen vornehmen, dokumentieren Sie diese in dem Abschnitt Änderungsliste am Anfang des GDDs.

Externe Quellen

Abgerufen von „https://sopranium.de/index.php?title=GDD&oldid=10985“