Welches Gefühl soll das Spiel vermitteln?

Wir versuchen während des Spielens herauszufinden, was wir fühlen und welche Kern Elemente dafür verantwortlich sein könnten. Aus diesen Kern Elementen wollen wir zusätzlich noch die Vision rekonstruieren, aus der das Spiel entstanden ist.

Ein Bild sagt mehr als tausend Worte. Wenn dir die Vision des Spiels klar ist, dann zeichne ein Bild, das für diese Vision steht. Ein solches Concept Art ist in der Spieleentwicklung der erste Wegweiser, welches Gefühl das fertige Spiel vermitteln soll. Welche Elemente deiner Concept Art vermitteln eine Botschaft? Passt sie zum analysierten Spiel?

Indem wir diesen Weg rückwärts gehen, fällt es uns leichter unsere eigene Vision zu konkretisieren und den Weg für unser eigenes Spiel vorwärts zu gehen. Zum Einstimmen auf die Arbeit am Projekt hilft es, ein schönes ausgearbeitetes Bild vor Augen zu haben. Je genauer das Concept Art die Gefühle vermittelt, die ich auch im Spiel vermitteln will, desto besser.

Üben wir solche bildlichen Stimmung Zusammenfassungen für verschiedene Spiele!

Wenn Game Designer ein Spiel planen, dann halten sie die Ergebnisse im Idealfall in einem Game Design Document (GDD) fest. Es gibt sie in verschiedensten Ausprägungen, die auch mit dem Projektmanagement Modell zusammenhängen. Wir sehen uns kurz die Vor- und Nachteile der beiden gegensätzlichsten Herangehensweisen an, bevor wir überlegen wie uns das hilft Spiele zu analysieren.

Professionelle Software Entwickler setzten lange Zeit auf das Wasserfallmodell, in dem das gesamte Projekt im Vorhinein bis ins kleinste Detail geplant und aufgeschrieben wurde, bevor auch nur die erste Zeile Code entsteht.

Vorteile:

• Planbarkeit: Das Ausmaß des Projektes ist gut bekannt, was die Schätzung des benötigten Budgets (Arbeitszeit, Tools, zugekaufte Assets…) und Milestone Planung erleichtert.
• Das Projekt hat einen strikt eingehaltenen roten Faden. Das Große Ganze der vorgesehenen Vision des Projekts wird in der Planungsphase im Auge behalten.
• Im Game Design Document steht die genaue Anleitung für die Entwicklung von Features.

Nachteile:

• Vergessenes bleibt lange Zeit verborgen und sprengt leicht den strikten Zeitplan.
• Denkfehler kommen erst in der Testphase ans Tageslicht. Dadurch werden oft Features implementiert, die sich in der Theorie gut anhören, aber in der Praxis nicht zum Projekt passen. Zu diesem Zeitpunkt ist das Budget für die Entwicklungsphase bereits aufgebraucht und ein Folgeprojekt für die Schadensbegrenzung hat meist Auswirkungen auf abhängige Teilbereiche. Das macht viel Arbeit zunichte und schafft noch mehr neue Arbeit.
• Riesiges Game Design Document, das niemand im Ganzen lesen kann oder will. Eignet sich nicht, um kurz das Gedächtnis aufzufrischen oder Änderungen zügig reinzuschreiben.

Ein moderner Ansatz der Projektplanung ist Scrum. Hier wird anfangs das absolute Minimum herausgearbeitet, das der Kunde auf jeden Fall braucht. In kurzen „Sprints“ (z.B. eine Woche) werden klar definierte Ziele entwickelt, getestet und dem Kunden vorgestellt. Mit dessen Feedback wird der nächste Sprint geplant.

Vorteile:

• Test Feedback wird sehr früh eingeholt und zeitnah eingearbeitet. Dadurch passt jedes Feature zum Rest des Produkts.
• Übersehene notwendige Features werden schnell entdeckt und können dadurch fast ohne Zusatzaufwand entwickelt werden.
• Kurzes knackiges Game Design Dokument mit dem Kern des Spiels, das sehr schnell einen Überblick über das Minimum bietet, auf dem das Große Ganze aufbaut.

Nachteile:

• Das Projekt ist fertig, wenn es fertig ist. Es ist fast unmöglich, einhaltbare Deadlines über das Sprint Ende hinaus zu planen. Das Budget ist ein Überraschungsei.
• Das Große Ganze ist leicht aus den Augen zu verlieren. Features passen zwar zueinander, aber eventuell nicht zur vorgesehenen Vision des Programms. Diese Vision kann und darf sich natürlich verändern, sollte aber einen durchgehenden roten Faden haben.
• Besprochene Features und Änderungen werden bestenfalls in Gesprächsnotizen festgehalten, finden aber selten den Weg in die Doku.

Dicke Game Design Dokumente verlieren sich also schnell in Details, die im Nachhinein schwer zu balancen sind. Schlanke Game Design Dokumente geben einen schnellen Überblick und lassen viel Freiheit für balancing, bieten dadurch aber keine (oder veraltete) Details zur konkreten Ausarbeitung.

Wir wollen lernen, wie wir Spiele entwickeln können. Wir wollen unsere ersten Versuche so klein wie möglich halten und kopieren dazu oft zuerst existierende Spiele, die wir nicht veröffentlichen wollen. Diese brauchen wir keinem Publisher vorstellen und es ist zu erwarten, dass sich das Projekt im Lernprozess stark verändert.

Das bedeutet, dass sich für uns der Scrum Ansatz sehr gut eignet. Die Spiel Idee wird auf das Minimum Viable Product heruntergebrochen, um die Chancen zu erhöhen, dass wir das Projekt tatsächlich spielbar bekommen und so schnell wie möglich so viel wie möglich lernen.

Dazu können wir für das Game Design Dokument ein Ein-Seiten-Template von Tim Ruswick (Game Dev Underground) verwenden, das er hier erklärt.

Mir fällt es leicht, das erste Drittel dieses GDD Templates mit dem groben Überblick und der Kernidee zu füllen. Im zweiten Drittel von Features bis Art Style werde ich schon sehr vage und der erste Kontakt mit der Wirklichkeit verändert die vorgesehenen Features massiv, also bietet mir das Game Design Dokument hier schon keinen Mehrwert für die Entwicklung mehr. Beim dritten Drittel mit Musik/Sound und grober Zeitplanung und Zwischenzielen bin ich meist komplett ratlos.

Wie kann ich das üben?

Ein Game Design Dokument kann ich nicht nur für eigene Spiel Ideen schreiben, sondern auch für existierende Spiele. Indem wir Spiele analysieren und sozusagen rückwirkend ein GDD entwerfen, üben wir, Ideen in dieser Form zu strukturieren. Wenn es ein kleines Spiel war, das wir kopieren möchten, können wir das entstandene Dokument benutzen um unsere eigene Version des Spiels zu entwickeln und dadurch festzustellen, welche Infos im Dokument hilfreich waren oder gefehlt haben.

Wir machen eine Kopie des Ein-Seiten-Template von Game Dev Underground. Das ist die Vorlage für unser Analyse Game Design Dokument.

Nun versuchen wir, das Spiel so gut wie möglich zusammenzufassen. Können wir den Kern des Spiels in einem Satz zusammenfassen? Welches Gefühl habe ich beim Spielen? Welches Genre passt zu diesem Spiel und welche Elemente hat es davon? Was macht das Spiel einzigartig? Was macht der Spieler? Wie beschreibe ich den Stil des Spiels? Welche Wirkung haben Musik und Sound Effekte? Wie lange hat es vermutlich gedauert, das alles zu entwickeln? Welche Zwischenziele würde ich setzen?

Solche Analysen sollen uns helfen zu lernen, ein kurzes knackiges Game Design Dokument zu schreiben. Der erste Schritt zum eigenen Spiel kann ein solches GDD sein.

Im agilen Scrum Ansatz kann leicht der rote Faden des Großen Ganzen verloren gehen. Diesen halten wir im Game Design Dokument fest, sodass wir das Gedächtnis leicht auffrischen können. Außerdem bietet es Platz, um den Sinn neu erdachter Features oder deren Änderungen strukturiert festzuhalten. Die Details stehen im Code, doch das GDD beantwortet die Frage: „Warum wollen wir das überhaupt so machen?“

Skizzen sind erlaubt! Sie fassen das „Was“ oft schneller zusammen als Worte, sodass mehr Platz für das „Warum“ bleibt.