spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Da hat sich jemand richtig Zeit genommen für die Beschreibung / Planung. Finde ich gut

Was mir nicht ganz klar ist, wofür steht GDD genau? Ist doch das Gleiche wie TCG oder?

Hi webconqueror!

Ich habe gerade nicht viel Zeit und das GDD nur grob ueberflogen. Generell finde ich das Dokument ziemlich gelungen, sehr detailliert! Was mir aufgefallen ist:

- Ich wuerde keine 'Timetable' machen. Das kann man vor beginn des Projekts quasi gar nicht einschaetzen. Selbst fuer einen erfahrenen Entwickler ist dies nahezu unmoeglich. Statt dessen wuerde ich dir empfehlen etwas ueber Agile Development zu lesen um ein Gefuehl dafuer zu bekommen wie Software heutzutage meist entwickelt wird.
- Worueber du dir auch noch etwas extra Gedanken machen koenntest ist das UI design. z.B. Mockups wie verschiedene Interaktionen und Seiten genau aussehen sollen

Wirago: GDD = 'Game Design Document' denke ich mal

Zitat von »xardias«

Wirago: GDD = 'Game Design Document' denke ich mal

Verdammt, im falschen Kontext gedacht... danke

Moin moin,

hier mal meine Gedanken dazu. Ich bin kein Profi und lerne das Zeug alles selbst erst, deshalb nimm meine Tipps "with a grain of salt" und einfach als meine Perspektive auf das GDD.
Ich weiß auch, dass das ein erster Versuch ist. Ich schreib die Kritik aber dennoch so, als hättest du das jetzt quasi "final abgegeben", das lässt dieses ganze "wenn" und "sobald" Gerede weg. Nimms dir also nicht so sehr zu Herzen, wenn da Kritik drinsteht, an der du bereits arbeitest oder die dir bewusst war!

Grundsätzlich:
Hast du schonmal daran gedacht, ein Wiki zu erstellen, statt eines starren Dokuments? Mir ist beim Lesen nämlich genau das Problem aufgefallen: Navigation nicht möglich, keine Cross-Links obwohl inhaltlich referenziert wird, Formatierung teilweise unglücklich.
Kein schöner Lesefluss, was nicht unbedingt an dir liegt, sondern an dem "Medium". Dazu fällt es schwer, das "Große Ganze" zu sehen, wenn man nur den reinen Text liest. Generell sind waschechte GDDs wohl eher was für Bewerbungen und Prüfungsmethode, aber ich würde mal behaupten, dass ein Wiki im realen Prozess wesentlich einfacher zu pflegen sind. GDDs sind ja auch lebende Dokumente, die nicht nur da sind, dass man sie einmal liest und weglegt.

Für den Einstieg fehlen mir so ein paar übergreifende Statements und einfach eine tatsächliche Einleitung ins Spiel. Du gehst schon relativ stark ins Detail, obwohl du nichtmal ganz klar gemacht hast, was dieses Spiel ausmachen soll. Man soll sammeln können, wie in jedem Kartenspiel. Und Komplexität soll taktische Fähigkeiten fördern. Aber wie?

Du verwendest außerdem einige Sachen, die du als Ersteller des Dokuments schon kennst, ich als Leser aber nicht. Dieses Dokument ist zwar auch eine Sammlung an Sachen, die du dir so ausdenkst, gleichzeitig ja aber auch ein Dokument für jemanden, der bspw an dem Spiel arbeiten soll, und sofort verstehen soll, was du da meinst. Du darfst also nicht vage sein. Sonst gibst du Interpretationsspielraum und dann beginnen die Diskussionen und der Sinn des Dokuments ist futsch. Was macht es aus, dass es ein Kartenspiel ist? Warum ist der Kampf 50%, und das Sammeln nur 40%? Und Warum macht die Planung so viel aus? Ist sie überhaupt nötig? Was verstehst du unter einem "Space Game"? Was ist Ziel des Spieles? Warum sollte jemand dieses Spiel spielen? Warum nicht einfach Yu-Gi-Oh?

Versuch am Anfang so wenig mit Hilfe bereits erdachter, dem Leser unbekannten, Fakten zum Spiel zu erklären und halte es auf einem allgemeinem Level. Du kannst gerne darauf eingehen, wie dein Spiel etwas umsetzen soll, aber beachte dabei dass du diese Sachen entweder vollständig erklären musst oder deine Erklärungen für sich selbst stehen können müssen. Für den Einstieg ist das letzte die bessere Wahl in meinen Augen. Ins Detail gehen kannst du später immernoch.

Aber später solltest du alles bis ins kleinste Detail erklären. Du fängst den Coding Part damit an "Java or C++" - warum? Ich meine ich verstehe, dass du dem Programmierer die Wahl lassen willst. Aber statt 2 Optionen hinzuschreiben, schreib doch einfach, welche Zielplattform du anstrebst. Welche technische Voraussetzung an das Spiel gerichtet werden.

Die Main Features sind wichtig, allerdings frage ich mich ob der Punkt "Fight For Your Race" wirklich hier hingehört. Hast du daraus eine Spielmechanik gemacht?
Dazu kommt, dass du den eigentlichen Kampf an sich nicht als Main Feature erwähnst. Warum? Und gibt es nicht innerhalb der genannten Punkt noch Sachen, die du als Feature aufzählen könntest? Ich lese im Dokument etwas von Stock-Market usw. Was ist denn damit? Was ist mit dem League System?

Die dann folgenden Beschreibungen sind wichtig und schon ganz gut. Aber an einigen Stellen mit fehlendem Detailgrad. Du zählst zwei Modi auf, erklärst ihren Ablauf aber nicht. Du beschreibst das Spielfeld und die einzelnen Phasen, aber hast nur das Layout fürs Spielfeld, nicht aber für irgendein anderes Fenster. Ein Programmierer hätte keine Ahnung, wie er jetzt die einzelnen Screens umzusetzen hätte.

Generell vermischt sich hier das Programming/Game Design ein wenig. Du erklärst wie das Spiel funktioniert, obwohl der Programmierer eigentlich jetzt eine Anleitung haben möchte, was er da in seinen Code hackt(Die Seiten "Before the Battle", "Battle") usw.. An anderer Stelle erklärst du dem Programmierer, wie er etwas zu programmieren hat, obwohl du diese Spielmechanik noch gar nicht richtig erörtert hast(bspw. "Card Actions"). Hier fehlt einfach ein wenig grundlegende Struktur.

Ich glaube, eine Struktur wie etwa folgende wäre ganz sinnvoll:

1) Screen
1.1) Layout des Screens
1.2) Alle Aktionen des Screens auf einem Schlag
1.2.1.1) Aktion A Layout(falls nötig)
1.2.1.2) Aktion A: Verwendete Sounds, Animationen und weitere Assets
1.2.1.3) Aktion A Schritt für Schritt erklärt, sodass ein Programmierer sie sofort implementieren könnte
1.2.2.1) Aktion B Layout(falls nötig)
(...)
1.3) Sonstige Anmerkungen zum Screen
(Du sollst die jetzt nicht so 1:1 übernehmen, diese Form macht z.B. in einem Wiki nicht Sinn. Ich möchte nur darauf hinaus, wie granular du damit sein sollst)

Themen wie Formeln verdienen hierbei ihre eigene Abteilung, mit jeweiligen Cross-Referenzen bei den Aktionen. Beispielsweise kann die Schadensformel beim "Angreifen"-Button referenziert werden, sodass du beim Angreifen Button nicht erklären musst, wie der Schaden funktioniert. Das funktioniert wie gesagt bei einem Wiki besonders gut.

Auch solltest du getrennt in einem eigenen Abschnitt auf das tatsächliche Game Design angehen. Aktionen mit Sinn und Zweck und größtmöglichem Detailgrad erklären, und vor allem Karten und deren Sinn erklären. Du hast in einem GDD für ein Kartenspiel nicht eine Karte beschrieben, obwohl diese das wichtigste an deinem Spiel ausmachen sollten. Ich habe, nachdem ich das Dokument gelesen habe, noch immer nicht wirklich Ahnung, wie sich das Spiel spielen würde.

Man merkt auch, dass es in den Bereichen außerhalb von Programmierung und Game Design fehlt. Sound Design wird in einer Seite abgefrühstückt und Art wird außerhalb von einigen Layouts eigentlich auch nicht beschrieben. Eine Liste mit voraussichtlichen Assets sollte auf jeden Fall drin sein. Du weißt jetzt vielleicht noch nicht, wie die aussehen, aber dass du auf jeden Fall UI-Knöpfe & Layouts, Hintergründe, Kartenbilder, Kartenbeschreibungen, Animationen, Effekte und entsprechende Sounds brauchst, das kannst du dennoch aufschreiben. Du möchtest keinen Sound Designer anheuern - wie steht es denn mit Lizenzsounds? Soll das Spiel komplett stumm bleiben? Diese Sachen sollten auch aufgelistet werden!

Dein Englisch ist ok, aber ausbaufähig. Dieses GDD ist natürlich eine prima Übung! Ich würde ja auch gerne Fehlerkorrektur machen, aber dafür habe ich leider keine Zeit. Ein Rechtschreibprogramm könnte hier auf jeden Fall helfen!

------

Der ganze Post ist jetzt doch etwas länger geworden, als er eigentlich geplant war. Ich hoffe, dass das nicht falsch rüberkommt. Für einen ersten Versuch ist es schon ziemlich gut und man erkennt auf jeden Fall, dass du dich mit dem Thema näher beschäftigt hast. Und das ist schonmal wesentlich mehr, als viele andere sagen können.

Wie gesagt, ich bin selber am Lernen. Und ich habe diese ganzen Fehler, die ich dir da aufgeschrieben habe, auch selbst schon gemacht. Darum erst nenne ich sie ja!

EDIT:

Wenn du Interesse hast, könnte ich dir mal das Wiki geben für ein Projekt, an dem ich vor einiger Zeit mitgearbeitet habe. Ist kein mustergültiges Beispiel, aber könnte dir helfen.

Damit solltest sogar du klar kommen
Ein bisschen HTML und/oder und gut ist. Vor allem dann, wenn es wirklich nur ein kleiner Webauftritt sein soll.