GDD: Unterschied zwischen den Versionen
Aus Das Sopra Wiki
| (29 dazwischenliegende Versionen von 4 Benutzern werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
{{TOCRight}} | |||
Das [[GDD|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. | Das [[GDD|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. | ||
| Zeile 5: | Zeile 7: | ||
=== Deckblatt === | === Deckblatt === | ||
Das Deckblatt sollte folgende Informationen beinhalten: Name des Spiels, Namen der Gruppenmitglieder, Name des Tutors, Gruppennummer, Datum der Erstellung. | 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 [[GDD]]s Features nach Absprache mit den Dozente geändert oder entfernt worden sind, sollten diese Änderungen am Anfang des [[GDD]]s in einem eigenen Abschnitt kurz beschrieben sein. Falls es keine Änderungen in relation zum GDD gibt, entfällt dieser Abschnitt. | |||
=== Spielkonzept === | === Spielkonzept === | ||
| Zeile 11: | Zeile 15: | ||
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|Screenplay]]). | 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|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 === | === Benutzeroberfläche === | ||
| Zeile 33: | Zeile 38: | ||
==== Mindestvoraussetzungen ==== | ==== 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, | 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 schlechtesten PCs eines Gruppenmitglieds, auf dem das Spiel noch ohne Probleme läuft | * Die Hardwarespezifikationen des Tutors. | ||
* Die | * Die Hardwarespezifikationen der Dozenten. | ||
=== [[Game Mechanic|Spiellogik]] === | === [[Game Mechanic|Spiellogik]] === | ||
In diesem Abschnitt wird die gesamte Spielmechanik und alle im Spiel vorkommenden | 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 ==== | ==== Optionen & Aktionen ==== | ||
Dieser Abschnitt beinhaltet die Aktionen, die | 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 [http://de.wikipedia.org/wiki/Use_case Use Cases] angelehnt. | Die Auflistung der Optionen und Aktionen erfolgt tabellarisch und ist in Form und Inhalt an [http://de.wikipedia.org/wiki/Use_case Use Cases] angelehnt. | ||
| Zeile 72: | Zeile 75: | ||
die Spielfiguren befinden an einem begehbaren Punkt in der Welt, der möglichst nah am Ziekpunkt liegt. | die Spielfiguren befinden an einem begehbaren Punkt in der Welt, der möglichst nah am Ziekpunkt liegt. | ||
|- | |- | ||
| ID02: ... | | ID02: Gegner automatisch angreifen | ||
|| Spieler oder KI | |||
|| | |||
# Die eigene Einheit bewegt sich auf die gegnerische Einheit zu, bis sie in Kampfreichweite ist. | |||
# 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: ... | |||
| ... | | ... | ||
| ... | | ... | ||
| Zeile 80: | Zeile 91: | ||
|} | |} | ||
==== | ==== Spielobjekte ==== | ||
Hier sind alle | 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 ==== | ==== Spielstruktur ==== | ||
| Zeile 94: | Zeile 105: | ||
==== Achievements ==== | ==== 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. Achievements können verschiedene Schwierigkeitsstufen besitzen, um sie zu erreichen. Achievements mit unterschiedlichen Schwierigkeitsstufen | Ä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 === | === Screenplay === | ||
| Zeile 100: | Zeile 111: | ||
==== Konzeptzeichnungen & Storyboards ==== | ==== Konzeptzeichnungen & Storyboards ==== | ||
Bilder sind wichtig für den ersten Eindruck. Vor allem im GDD | 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 == | == 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. | 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 [[Formalien#Benotung|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 [[GDD]]s, die auch bei anderen schriftlichen Arbeiten im Studium Verwendung finden: | Um euch Verbesserungsarbeit zu sparen, die auf euch zukommen könnte, beachtet bitte die folgenden Punkte beim Schreiben eures [[GDD]]s, 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 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." | * 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 sie einzuordnen ist. | * 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. | * 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. | * 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 | * 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. | * 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 [[GDD]]s der letzten Jahre in unserer [[HallOfFame|Hall of Fame]] anschauen. | Um einige Beispiele zu sehen, könnt ihr euch die [[GDD]]s der letzten Jahre in unserer [[HallOfFame|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 [[GDD]]s 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 [[GDD]]s ü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 [[GDD]]s 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 [[GDD#(Optional) Änderungsliste|Änderungsliste]] am Anfang des [[GDD]]s. | |||
== Externe Quellen == | == Externe Quellen == | ||
* [http://www.gamasutra.com/features/19991019/ryan_01.htm Gamasutra] | * [http://www.gamasutra.com/features/19991019/ryan_01.htm Gamasutra] | ||
* [http://www.eng.auburn.edu/~sealscd/COMP7970/ Introduction to Computer Game Design & Development] | * [http://www.eng.auburn.edu/~sealscd/COMP7970/ Introduction to Computer Game Design & Development] | ||
* [https://www.gamedevs.org/uploads/grand-theft-auto.pdf] orginal Grand Theft Auto GDD | |||
* [https://www.videogameworkshop.com/game-design/Core-Game-Mechanics.html] Zentrale Spielmechanik und Core Game Loop | |||
[[Kategorie:Begriffe]] | [[Kategorie:Begriffe]] | ||
[[Kategorie:Entwurf]] | [[Kategorie:Entwurf]] | ||
[[Kategorie:Artefakte]] | [[Kategorie:Artefakte]] | ||
