Am Anfang eines Projekts steht immer eine Idee. Bevor du anfängst ein Spiel zu entwickeln, musst du es, wenn es ein komplexes Projekt ist, genau planen. Dabei ist es hilfreich, ein Gamedesigndokument anzufertigen. Wichtige Punkte bei einem Gamedesigndokument (im folgenden: GDD) sind:

1. Die Welt - In welcher Zeit soll das Spiel spielen? Offene Welt oder lineare Abschnitte?

2. Die Story - Was für eine Person ist der Hauptcharakter? (gemeint ist nicht der Name, sondern seine Eigenschaften) Was passiert in dem Spiel? (grob skizziert)

3. Das Gameplay - Was an deinem Spiel soll Spass machen? (Kernfeatures) Wie stellst du dir die Kernelemente vor? ("man soll da schießen können" ist keine Beschreibung Erwähne auch wieviele Gegner man beseitigen wird. (falls das ein Element des Spiels ist) Welche Gewichtung das jeweilige Element hat,) Wie wird das Spiel gesteuert?

4. Team - Möchtest du in einem Team arbeiten? Dann solltest du hier die Aufgaben aufteilen. Wenn nicht erübrigt sich das. Möchtest du ein Team, hast aber noch keins? Stelle dein Projekt in Foren vor und werbe Mitglieder an. Am besten geht das wenn man dich im jeweiligen Forum kennt. Es ist außerdem förderlich vor einem großen Projekt schon ein, zwei kleine vorgestellt zu haben, das überzeugt mehr Programmierer und Grafiker.

Nun ist es für dich an der Zeit dir schon einige programmiertechnische Dinge aufzuschreiben, keinen Code, sondern theoretische Dinge wie die Ideen implementiert werden sollen. (Mathematik usw.)

Ein wichtiger Punkt ist noch, was willst du nutzen, was selbst machen? Engines, Editoren usw. bieten sich an.

Viel Spass beim planen und programmieren!

Inhaltsverzeichnis 1 Grundkonzept 1.1 Genre 1.2 Darstellungsart 2 Das Game Design Document 2.1 Charakterebeschreibungen 2.1.1 Spiele ohne Charaktere 2.1.2 Spiele mit Charakteren 2.2 Die Spielwelt 2.2.1 Nebensächliche Spielwelt 2.2.2 Relevante Spielwelt 2.3 Die Geschichte 2.3.1 Die Hintergrundgeschichte(n) 2.3.2 Die Erzählweise 2.3.3 (Zu) Häufig verwendete Elemente 3 Entwurf (Implementierung) 3.1 Fremdentwicklungen 3.2 Die Klassenstruktur (UML-Klassen-Diagramme) 3.3 Die Datenstruktur 3.4 Die Verzeichnisstruktur 4 Teamarbeit

Grundkonzept

Das wichtigste an einem Spiel sind die grundlegenden Dinge, wie Genre des Spiels oder Darstellungsart (Perspektive, 2D oder 3D). Dabei ist aber zu beachten: ein 3D Spiel ist nicht gleich ein 3D Spiel. Jedes 2D Spiel kann ebenso mit 3 dimensionaler Darstellung umgesetzt werden, ohne dass sich der Spieler in allen 3 Dimensionen bewegen kann. Bevor man sich detailierte Gedanken zu dem Spiel macht und beispielsweise eine Story ausarbeitet, sollten diese Dinge bereits feststehen.

Genre

Nachfolgend eine Auflistung einiger Genres, die man für sein Spiel verwenden kann. Zu Beachten ist, dass verschiedene Genres sich nicht gegenseitig ausschließen und deshalb verschiedene Genres oder Elemente verschiedener Genres gemischt verwendet werden können.

Genre	Einteilung durch	Beispiele
Shooter	Perspektive	Ego-Perspektive
		Top-Down
		Sidescroller
Rollenspiel	Kampfsystem	Echtzeit
		Rundenbasiert
	kultureller Einfluss	östliche/Konsolen-Rollenspiele
		westliche/Computer-Rollenspiele
Strategiespiel	Kampfsystem	Echtzeit
		Rundenbasiert
Rennspiel	Realismus	Rennsimulator
		Funracer
Adventure	Interaktionen	Action-Adventure
		Text-Adventure

Das Genre beeinflusst nicht direkt die Schwierigkeit des Projekts. In einigen Genres sind bestimmte, komplexere Spielelemente verbreiteter, wie das Levelsystem in vielen Rollenspielen. Andere Genres sind deswegen nicht als leichter einzustufen, da dort auch komplexe Elemente denkbar sind, wie ein Tuningsystem für Rennspiele. Wenn bestimmte Genres als leichter eingestuft werden, dann weil sie auf entsprechende Spielelemente meist verzichten.

Darstellungsart

Es muss von Anfang an feststehen, ob das Spiel eine 3 dimensionale oder eine 2 dimensionale Darstellung haben soll. Das ist wichtig, da für 3D Spiele andere Ressourcen benötigt werden, als für 2D Spiele.

Der grafische Stil wäre weiterhin für die Darstellungsart relevant, ist allerdings für die anfängliche Planungszeit weniger relevant. Während bei 2D Spielen dies größtenteils durch die Verwendung der richtigen Grafiken erreicht wird, kann es sein, dass bei 3D Spielen die Szene auf eine andere Art gerendert werden soll.

Das Game Design Document

Nachdem die grundlegensten Grundsteine für das Spiel gelegt sind, kann man sich mit weiteren Details befassen. Es ist möglich, diese in einem sogenannten Game Design Document festzuhalten. Für ein solches Dokument gibt es keine Normierungen, weshalb nicht festgelegt ist, was in einem solchen Dokument stehen muss und wie ausführlich diese Punkte gehalten werden müssen. Der Inhalt des Dokuments oder dessen Ausführlichkeit ist nicht festgelegt. Zu den Inhalten eines solchen Dokuments gehören in der Regel die Punkte Hintergrundgeschichte, Spielwelt, die wiederum Characktere und Leveldesign umfasst, Aufgaben des Spielers, musikalische Gestaltung, grafische Stil und Art der Steuerung (Maus und Tastatur/Gamepad) oder eine Teilmenge dieser Punkte. Auch die Form ist nicht festgelegt. Ein Game Design Document kann aus Text, Diagrammen, Skizzen, multimedialen oder interaktiven Inhalten bestehen.

Charakterebeschreibungen

Je nach Genre kann es sein, dass es keine Charaktere im eigentlichen Sinne gibt. Im Folgenden soll alles, was im Spiel vorkommt und die Rolle von aktiven oder passiven, spielbaren oder computergesteuerten Figuren übernimmt als Charakter bezeichnet werden.

Spiele ohne Charaktere

Es kann Spiele geben, in denen es keine Charaktere oder mit Charakteren gleichzusetzende Objekte gibt. Dies trifft beispielsweise bei Karten-, Brett- und teilweise bei Rennspielen zu, wobei letzetres vom jeweiligen Spiel abhängt. Bei solchen Spielen ist eine Beschreibung von Charakteren irrelevant, da es keine Charaktere gibt.

Spiele mit Charakteren

Auch Steine können Charaktere sein, sofern sie im Spiel eine entsprechende Rolle einnehmen. Je nach Genre ist es empfehlenswert, für jeden Charakter eine Beschreibung anzufertigen. Diese beinhaltet Gewohnheiten, Charakterzüge wie Stärken und Schwächen, die Beziehung zu anderen Charakteren oder Details aus der Vergangenheit. Die Beschreibung der Charaktere kann mehr Informationen enthalten, als für das Spielgeschehen selbst erforderlich, da diese in der Regel für das Schreiben der Dialoge hilfreich sein können. Anhand solcher Informationen kann man besser einschätzen, was der Charakter in einer bestimmten Situation sagen würde. Eine ausführliche Beschreibung ist nur dann erforderlich, wenn der Charakter im Spiel besondere Interaktionen durchführen kann, wie Dialoge führen. Das Gegenbeispiel für ein Spiel mit Charakteren, die keine größere Bedeutung haben, wären Rennspiele oder Sportspiele ohne Story. Dort wiederum können sich aus der Vergangenheit besondere Eigenheiten von Charakteren ableiten. Bei einem Fußballer könnte eine alte Verletzung am Bein hinderlich sein, wodurch er etwas langsamer als seine Mitspieler ist.

Die Spielwelt

Je nach Genre ist die Welt, in der das Spiel spielt ein sehr wesentliches Element. Im folgenden soll die gesamte dem Spieler zugängliche oder die dem Spieler beschriebene Umgebung gemeint sein.

Nebensächliche Spielwelt

Je nach Genre kann die Spielwelt eine mäßige Rolle spielen. Bei Rennspielen würde diese alle Rennstrecken und, sofern vorhanden, weitere besondere Plätze, wie die Garage oder eine Werkstatt, umfassen, sofern die Fortbewegung im Spiel, außerhalb der Rennen über Menüs statt findet. Es kann ebenfalls Rennspiele geben, bei denen der Besuch in der Werkstatt erfordert, dass man sich mit seinem Fahrzeug zu dieser bewegt, wodurch die Spielwelt wieder eine größere Bedeutung erlangen würde.

Es gibt auch Spiele, bei denen die Bennenung einer Spielwelt irrelevant ist, wie Brett-, Karten- oder einige Denkspiele. Bei diesen stellt die Spielwelt meist ein Detail dar.

Relevante Spielwelt

In einigen Genres ist eine gute Spielwelt enorm wichtig. Zu diesen gehören in der Regel Rollenspiele und Strategiespiele.

Um die Umgebung besser beschreiben zu können, kann diese in bestimmte Teile unterteilt werden. Diese Unterteiling kann im Spiel ebenfalls verwendet werden, muss sie aber nicht. Für die einzelnen Teile sollten treffende Bezeichnungen gewählt werden. Entweder sollten diese der Name der Umgebung oder eine Umschreibung sein, wie "das Gebirge im Norden"

Die Geschichte

Auch die Geschichte stellt einen Punkt dar, der abhängig vom Genre beschrieben oder nicht beschrieben werden muss. Während Spiele wie Rollenspiele, Ego-Shooter und einige Strategiespiele noch eine Geschichte während des Gesamten Spielverlaufs erzählen, ist dies bei Rennspielen und Geschicklichkeitsspielen eher seltener der Fall. Es ist auch möglich, dass ein Spiel nicht nur eine Geschichte erzählt, sondern dass es verschiedene Abläufe geben kann. Diese könnten dann je nach Entscheidungen des Spielers verschiedene Wege einschlagen.

Die Hintergrundgeschichte(n)

Zu jedem Charakter kann es eine eigene Hintergrundgeschichte geben. Diese können für den Spielverlauf relevant sein oder aber Zusatzinformationen für den Spieler darstellen. In letzterem Fall sollten dem Spieler diese Informationen nicht aufgedrängt werden, da diese nicht jeden interessieren. Hinweise auf die Hintergrundgeschichte eines Charakters, eines Volkes oder eines Ortes der Welt können entweder an einer Stelle platziert sein, an der man diese Vermuten könnte, wie in einer Bibliothek oder erst durch bestimmte Aktionen freigespielt werden, wie eine Reihe von Aufgaben, die erfüllt werden müssen, bevor man von einem Charakter dessen Geschichte erzählt bekommt.

Die Erzählweise

Die Möglichkeiten mit denen man Geschichten wiedergeben kann sind, wie auch in der Literatur, nahezu grenzenlos. Es ist beispielsweise denkbar die Story auf kleine, jedoch sich stätig selbst vervollständigende Fragmente aufzuteilen. Dies regt den Spieler, sofern er Interesse finden kann, zum Nachdenken an. Er könnte versuchen sich kommende Geschehnisse welche auf der Geschichte basieren zu erahnen. Des Weiteren wird so vermieden, dass der Spielfluss ins Stocken gerät, durch etwa zulange Erzählungen, welche meistens nicht gelesen werden, da die Lust nach gewisser Zeit verloren geht.

Bezieht man sich jedoch rein auf den Aspekt des Mitteilen der Geschichte und nicht auf die Häufigkeit und Dauer eben dieser, so hätte man die Möglichkeit, einen Erzähler zu verwenden, welcher wie aus einem Buch narrative Inhalte vorliest. Dieser kann, muss allerdings nicht preis gegeben werden. Andererseits könnte, sofern vorhanden, der Protagonist in Gesprächen mit sich oder anderen, Informationen aussprechen. Hierbei empfiehlt es sich den Konjunktiv zu nutzen, also die Möglichkeitsform. Es macht das gesamte Geschehen stimmiger und lässt es nicht so wirken, als hätte der Hauptcharakter bereits alles gewusst.

(Zu) Häufig verwendete Elemente

Eine Geschichte kann dadurch ruiniert werden, dass keine neuen Ideen eingebracht werden und statt dessen Dinge verwendet werden, die bereits sehr oft verwendet wurden. So wurde eine stupide Einteilung in Gut und Böse, bei der die Bösen aus nicht beschriebenen Gründen die Welt beherrschen, zerstören oder den Helden zur Strecke bringen wollen, absurd wirken und sorgt nicht für eine Verbesserung der Geschichte. Dem Spieler sollte im Spielverlauf erklärt werden, warum die Antagonisten Handlungen ausführen, die ihm potentiell schaden.

Entwurf (Implementierung)

Nachdem festgelegt wurde, was umzusetzen ist, kann bestimmt werden, wie dies gemacht wird. Hierfür gibt es verschiedene Arten von Diagrammen und Dokumenten, die zu diesem Zweck verwendet werden können. Diese haben den Zweck, vor der Implementierung zu beschreiben, was genau implementiert werden muss, damit nach diesem Entwurf (theoretischerweise) keine weiteren Überlegungen mehr notwendig sind.

Fremdentwicklungen

Kein Spiel lässt sich noch vollkommen ohne Fremdentwicklungen realisieren, da dies einen enormen Aufwand bedeuten würde. Damit sind Bibliotheken, wie Grafik-Engines, Sound-Engines, Physik-Engines oder Bibliotheken für mathematische Berechnungen, Spiel-Engines oder ähnliches gemeint. Es sollte deshalb festgehalten werden, welche vom Spiel verwendet werden sollen. Dabei muss immer berücksichtigt werden, dass dadurch diverse Einschränkungen oder Verpflichtungen entstehen bzw. Gebühren anfallen können.

Die Klassenstruktur (UML-Klassen-Diagramme)

Da in den meisten Fällen für die Spieleentwicklung Objektorientierung zum Einsatz kommen soll, muss man sich Gedanken darüber machen, welche Klassenstruktur man für sein Projekt verwenden möchte.

Die Datenstruktur

Neben der Klassenstruktur, die die Beziehungen der Objekte zur Laufzeit untereinander darstellt, ist auch eine Datenstruktur für die Daten notwendig, die vom Spiel verwendet werden sollen. Das heißt die Formate, die man für das Spiel selbst entwickelt hat, wie die Formate für Level/Spielabschnitte/Strecken/... und für Spielstände - siehe dazu Spielstände speichern und laden - müssen beschrieben werden. Wenn sich diese während der geschlossenen Entwicklung ändern, stellt dies kein größeres Problem dar. Sollte sich aber eines der Formate von einer Version zur anderen ändern, dann muss das Spiel sowohl mit dem alten Dateiformat, als auch mit dem neuen Dateiformat umgehen können, sofern Dateien in diesem Format auch dynamisch vom Spiel erstellt werden können. Dies trifft beispielsweise auf Spielstände zu und nur dann auf Level, wenn diese vom Spieler über einen eingebauten Editor angelegt oder bearbeitet werden können.

Die Verzeichnisstruktur

Sowohl für das Projekt selbst, als auch für das Spiel muss eine Verzeichnisstruktur definiert werden. Für das Projekt selbst ist in der Regel durch die Entwicklungsumgebung eine Struktur vorgegeben. Für das Spiel muss diese erst definiert werden. So kann es sein, dass die Bibliotheken mit ausführbarem Programmcode in den Unterordner "lib" gelegt werden sollen, die Grafiken in den Ordner "gfx", Audiodateien in "sfx" und so weiter. Diese Verzeichnisse stellen nur ein Beispiel für die Organisation der Dateien dar. Ebenfalls ist es möglich, alle Dateien, die ausführbaren Code enthalten (die Anwendung selbst und die Bibliotheken) in das Hauptverzeichnis zu legen oder die Ressourcen in ein gemeinsames Unterverzeichnis zu legen.

Teamarbeit

Grundsätzlich werden an einem Projekt mehrere Leute beschäftigt sein. Dies erfordert eine Koordinierung der Arbeiten der Mitarbeiter und somit gegebenenfalls Mittel für diese. Es muss eine Kommunikation möglich und Festlegungen und Dateien zentral abrufbar sein. Die Aufgaben der Mitarbeiter sollten nach Möglichkeit zentral verwaltet werden, damit jeder den aktuellen Fortschritt einsehen kann.