Ein Anfänger der Spieleentwicklung scheitert meist an wachsenden Komplexität eines Projektes die schneller wächst als die Übersicht über das Projekt. Daher will ich hier ein paar Gedanken teilen die einem helfen von vorne herein sinnvolle Architektur zu schaffen. Angemerkt sei noch, dass ich hauptsächlich Erfahrung mit 2D Spielen in Java habe und sich die Tipps daher aus einem derartigen Szenario ableiten.

Zuerst einmal ein paar Worte zum Prozess der Entwicklung. Wie und wo sollte man am besten Anfangen? Hier gibt es natürlich keine Standard-Antwort. Es gibt zwei Ansätze bei der Entwicklung von Software: Top-Down sowie Buttom-Up. Der Unterschied zwischen den beiden Ansätzen ist simpel. Entweder man beginnt mit den Details (Attribute…) oder man Skizziert grob die Klassen und deren Beziehungen. Meist ergibt sich eine Mischung aus beiden Wegen.

Ein erster Schritt in der Entwicklung eines Computerspieles kann daher sein eine Skizze (z.B. auf Papier) der Vorstellungen des fertigen Spieles zu machen. Während des Skizzieren wird einem die Komplexität immer bewusster die das fertige Spiel haben wird (wenn es je fertig wird ). Je vollständiger man das Resultat so früh wie möglich vor sich hat desto wahrscheinlicher und einfacher ist die Fertigstellung des Spieles. Fügt man während der Entwicklung immer neue Elemente hinzu verwurstelt man sich gerade als Anfänger sehr schnell und verliert irgendwann die Lust an der Entwicklung.

Hat man einen guten Überblick über alles kann man langsam damit beginnen alles auszuarbeiten. Dies kann natürlich auch schon parallel zum Skizzieren passieren. Zum einen sollte man an diesem Punkt damit beginnen Objekt orientiert zu denken. Ein Objekt hat Eigenschaften und Verhalten was wir meist unter den Begriffen Attribute und Methoden kennen. Schreibt euch auf welche Eigenschaften für einzelne Elemente relevant sind (für eine Spielfigur z.B. die Position, Energie,  welche Kleidung, die aktuelle Geschwindigkeit usw.). Dies kann in der Form eine Mindmap passieren. Stoßt ihr dabei auf komplexere Eigenschaften muss die Überlegung angestellt werden ob diese nicht besser in ein weiteres Objekt ausgelagert werden sollten. Findet möglichst genau heraus welche Elemente in dem Spiel letztendlich auftauchen sollen und wie diese Gruppiert werden könnten (z.B. Spielfiguren, Gebäude, Effekte usw.). In einem weiteren Schritt überlegt ihr euch welche Methoden notwendig sind um das Verhalten der einzelnen Elemente zu realisieren.

Sehr hilfreich ist es auch alles was euch einfällt aufzuschreiben. Beschreibt jedes Element und Feature so detailliert wie möglich (wo taucht es auf, auf was hat es Einfluss, wie verhält es sich usw.). Mit der Zeit merkt man hierbei recht schnell wo Lücken in der Logik auftauchen und was einen langen Rattenschwanz an weiteren Notwendigkeiten nach sich zieht da euch während dieses Prozesses immer neue Dinge einfallen werden.

Anhand der gesammelten Informationen werden euch dann auch Gemeinsamkeiten zwischen verschiedenen Elementen klarer was beim Designen der Objekte und deren Beziehungen hilfreich ist.

Im nächsten Abschnitt werde ich verschiedene Elemente auflisten die eigentlich immer wieder in einem Spiel auftauchen. Daher könnte man die Packages entsprechend organisieren. Wie schon geschrieben ist das keine feste Vorgabe, sonder nur eine Inspiration.

Entity(s): Alles was letztendlich in der Spielwelt auftaucht (Items, Bäume, Monster, Schalter, Auslöser usw.). In diese Kategorie gehören eigentlich alle Elemente die etwas beschreiben was in der Welt die wir Simulieren wollen relevant ist.

Manager: Ein Manager ist eigentlich nichts anderes als eine Datenstruktur die speziell auf einen bestimmten Typ von Elementen zugeschnitten ist (z.B. Felder der Map oder Entitys). Hier werden alle existierenden Entities verwaltet und der Zugriff auf diese ermöglicht (z.B. Methoden wie getAlleVerletzenEinheiten()). Ein Manager kann auch mit Fabriken ausgestattet sein die es ermöglichen nach bestimmten Regeln neue Objekte zu erzeugen die dann direkt verwaltet werden.

Util(s): Hier befinden sich alle Hilfsklassen die meist als static und final deklariert sind. Geht es um irgendwelche Umrechnungen in Raum und Zeit ist es hier recht gut aufgehoben. Auch allgemeine Objekte die Dinge wie eine Position oder einen Zeitraum beschreiben könnte man hier ablegen.

Config: Hier werden einfach Werte als Konstante abgelegt. Das könnten die Eigenschaften von verschiedenen Monster sein, Bilder als Ressourcen, in welche Auflösung das Spiel läuft oder Texte für einen Dialog. Dieses Package sollte sich auf die reine Datenhaltung beschränkt sein. Hier können auch Einstellungen des aktuellen Spielers verwaltet werden.

Gui: Die Benutzeroberfläche ist in einem eigenen Package sehr gut aufgehoben und sollte sehr strikt vom restlichen Spiel getrennt sein. Lediglich klar definierte Methoden die das auslesen von Informationen aus der Gui oder das auslösen eines Eventes dienen sollten nach außen hin sichtbar sein.

Network: Hier befindet sich alles, wie der Name schon sagt, das dem Austausch von Daten in einem Netzwerk dient. Hier gilt eigentlich das selbe wie für die Gui: Bis auf eine klare Schnittstelle sollte es ein in sich geschlossenes System sein. Wenn man ein Netzwerkfähiges Spiel entwickelt ist eine klare Aufteilung von Client und Server eventuell in einem eigenen Projekt mit eigenen Packages ratsam. Wie eine Netzwerkarchitektur aussehen kann werde ich eventuell an RMI und KryoNet in einem bald folgenden Blogeintrag darstellen.

Event(s)/Action(s): Dieses Package könnte an verschiedenen Stellen existieren. Hier werden kleine Prozesse in einzelnen Klassen beschrieben. Beispiele könnten sein: Was passiert wenn der Spieler auf Beenden Klickt ?, Der Spieler erreicht einen Checkpoint. usw. . Diese Trennung der Prozesse hilft dabei diese klar außerhalb eines Kontextes zu beschreiben. So muss man sich genau überlegen welche Informationen für das Event/die Aktion notwendig und kann ohne sich Kopferzerbrechen über deren Beschaffung eine Funktionalität umsetzen.

Map/World: Die Spielwelt ist meist ein in sich geschlossenes System das in einer speziellen Datenstruktur (Eine Collection mit Objekten die Felder repräsentieren …) beschrieben ist. Diese Datenstruktur verwaltet welche Spielfelder welche Eigenschaften aufweisen. Hier sollte man ähnlich vorgehen wie bei Gui und Network. Von außerhalb ist nicht nur der Zugriff auf die einzelnen Felder bzw. derren Eigenschaften relevant. Es kann natürlich auch Funktionalität geben wie: Berechne mir den Weg von A nach B.

Main: Wie man dieses Package auch nennen mag. Hier läuft alles zusammen und die Grundlegende Gamelogik wird realisiert (Init, Update, Render). Hier muss man eine sehr Architektur kritische Fragen beantworten. Wie erhalten die verschiedenen Module, Elemente des Spieles Zugriff auf die notwendigen Ressourcen. Am einfachsten geht das indem man irgentwo einen static deklarierten Ansatzpunkt definiert indem Module wie die Gui, die Map, die Manager usw. instanziert werden. Dies kann ja z.B. auch in einem kleinen Manager passieren. Des weiteren macht es nicht immer Sinn auf eine Zentrale Quelle zuzugreifen. Daher muss man manche Objekte entsprechend füttern. Schlagworte hierzu sind z.B. Dependency Injection oder Inversion of Control wobei man entsprechende Referenzen über den Konstruktor oder Setter-Methoden übergibt.

Zuletzt noch ein paar Tipps die euch helfen können ordentlich und effektiv zu arbeiten.

Wenn eine Methode mit externen Ressourcen arbeitet die per Parameter übergeben werden dann kann eine Validierung der Parameter bzw. das werfen einer entsprechen Exception (in Java IllegalArgumentException, IllegalStateException usw.) nicht schaden. Das selbe gilt für Tests. Gerade Methoden die kritische Funktionen des Spieles abdecken sollten unbedingt mit einem (Unit-)Test abgedeckt sein.

Ihr tut euch deutlich einfacher wenn ihr euch wie Anfangs bereits erwähnt gut vorbereitet. Das gilt auch auf die Verwendung von Assets. Hat man z.B. noch keinen kompletten Satz Grafiken für ein Spiel während der Entwicklung parat lenkt die Beschaffung oder Erstellung dieser von der Entwicklung ab. Daher ist es Ratsam schon vor der Entwicklung die Assets zu besorgen. Dies können natürlich auch ersteinmal Platzhalter Grafiken sein. Dadurch kommt man schneller voran und erzielt natürlich auch schneller Ergebnisse welche für den weiteren Fortgang der Entwicklung motivieren.

Ich hoffe die aufgeführten Punkte helfen irgend jemand bei der Entwicklung eines Spieles.