GDD: Unterschied zwischen den Versionen
Aus Das Sopra Wiki
| (7 dazwischenliegende Versionen von 3 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. | |||
Falls in der finalen [[Abgabe]] des [[GDD]]s Features nach Absprache geändert oder entfernt worden sind, sollten diese Änderungen am Anfang des [[GDD]]s in einem eigenen Abschnitt kurz beschrieben sein. | |||
=== Spielkonzept === | === Spielkonzept === | ||
| Zeile 40: | 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 ==== | ||
| Zeile 95: | 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 127: | Zeile 123: | ||
* 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. | ||
| Zeile 136: | Zeile 132: | ||
Im Softwarepraktikum bedeutet das konkret: | Im Softwarepraktikum bedeutet das konkret: | ||
* Anhand der | * 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. | * 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 | 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. | Sollten Sie nach Rücksprache Änderungen oder Entfernungen vornehmen, dokumentieren Sie diese in dem Abschnitt [[GDD#(Optional) Änderungsliste|Änderungsliste]] am Anfang des [[GDD]]s. | ||
