Weiterentwicklung einer 2D-Game-Engine für rundenbasierte Strategiespiele

Inhaltsverzeichnis

1. Einleitung
1.1 Allgemeine Motivation
1.2 Rundenbasierte Strategiespiele
1.3 Plattform Google Android
1.4 AndEngine - Übersicht
1.5 Das Ziel dieser Arbeit und mein weiteres Vorgehen

2. Analyse
2.1 Die Wahl derzu vergleichenden Spiele
2.1.1 Heroes of Might and Maigc IV - Kurzbeschreibung
2.1.2 Battle for Wesnoth - Kurzbeschreibung
2.1.3 Civilization IV - Kurzbeschreibung
2.2 Komponentenanalyse und Konzepte
2.2.1 Game Design Muster
2.2.1.1 Muster für Spielelemente
2.2.1.2 Musterfür Ressourcen und Ressourcenmanagement
2.2.1.3 Musterfür Information, Kommunikation und Präsentation
2.2.1.4 Muster für Spielsessions
2.2.2 Menüs
2.2.2.1 Menü für die Kartenwahl
2.2.2.2 Menüs für die Spielvorbereitung

3. Implementierung
3.1 Das für die Implementierung verwendete Vorgehensmodell
3.2 Wahl der Software-Design-Patterns und ihre Anwendung
3.3 Die wichtigsten Komponenten des Frameworks
3.3.1 Das Client-Server Modell
3.3.2 Die Activity-Stubs
3.3.3 Das Unit-Modell
3.3.4 Das Karten-Modell
3.3.5 Das Match-Modell
3.4 Übersicht über die Pakete
3.5 Beispielimplementierung zweier Activity Stubs
3.5.1 Implementierung der Kartenwahl
3.5.2 Implementierung der Spielvorbereitung
3.6 Stickmen Resurrection - Eine Beispielimplementierung
3.6.1 Erweiterungen gegenüber der Standardimplementierung
3.6.2 Tests

4. Fazit
4.1 Das Ergebnis
4.2 Aussicht

Abbildung

Abbildung 1: Aufbau einer Runde

Abbildung 2: Grafik über die Android API Fragmentierung vom 05.07.2011

Abbildung 3: Entwicklung von AndEngine überTBS-Engine hin zum Spiel

Abbildung 4: Screenshot Heroes ofMight and Magic IV

Abbildung 5: Screenshot Battle for Wesnoth

Abbildung 6: Civilization IV Screenshot

Abbildung 7: Die vier Schichten einer Karte

Abbildung 8: Heroes of Might and Magic IV Schicht 1 (unterschiedliche Sandarten) Schicht2 (Bäume und Fels), Schicht 3 (Spielelementewie Helden und Artefakte)

Abbildung 9: Battle forWesnoth Schicht 1 (Sand und Grünflächen) Schicht 2 (Bäume) Schicht 3 (Spielelemente wie Dörfer und Einheiten)

Abbildung 10: Civilization IV Schicht 1 (Wasser, Graslandschaft) Schicht 3 (Stadt, Ressourcenquellen wie Kühe oder Reben) Schicht 4 (Einflussregion der Stadt)

Abbildung 11: Die fünf Ebenen einer TBS-Engine Map

Abbildung 12: Civilization IV - Buttons für die Aktivierung aktiver Fähigkeiten des ausgewählten Unit

Abbildung 13: Heroes of Might and Magic - Interaktiv eingeblendetes Symbol für das Angreifen der in der Nähe befindlichen Einheit

Abbildung 14: Battle for Wesnoth - Kontextmenü für die Auswahl des Angrifftyps nach einem Klick auf eine gegnerische Einheit

Abbildung 15: Civilization IV - Lokale Ressourcen einerStadt (Lebensmittel pro Runde, besetzbare Felder etc.)

Abbildung 16: Heroes of Might and Magic IV - Lokale Ressourcen eines Helden (Zauberpunkte, Schritte pro Runde, Lebenspunkte etc)

Abbildung 17: Battle for Wesnoth - Lokale Ressourcen einer Einheit (Lebenspunkte, Erfahrungspunkte, Bewegungspunkte etc.)

Abbildung 18: Battle for Wesnoth - Anzeige für globale Ressourcen, die dem Spieler überall auf der Karte gleichermaßen zur Verfügung stehen

Abbildung 19: Battle for Wesnoth Mini-Map

Abbildung 20: Heroes of Might and Magic IV Mini-Map

Abbildung 21: Civilization IV Mini-Map

Abbildung 22: Battle for Wesnoth Fog of War

Abbildung 23: Civilization IV Fog ofWar

Abbildung 24: Heroes of Might and Magic IV Fog of War

Abbildung 25: Battle for Wesnoth - Ressourcenanzeige

Abbildung 26: Civilization IV - Ressourcenanzeige

Abbildung 27: Heroes of Might and Magic IV - Ressourcenanzeige

Abbildung 28: Civilization IV Kartenwahl Menü

Abbildung 29: Battle for Wesnoth Kartenwahl Menü

Abbildung 30: Heroes of Might and Magic IV Kartenwahl Menü

Abbildung 31: Heroes of Might and Magic IV Spielvorbereitung

Abbildung 32: Battle for Wesnoth Spielvorbereitung

Abbildung 33: Klassen-Diagramm für den Gebrauch von Generics + Template--Method Pattern

Abbildung 34: Beschreibung der Kommunikation zwischen Client Activities und dem GameServer

Abbildung 35: Ablauf Applikationsstart bis zur Spielsession

Abbildung 36: Vereinfachtes UML-Diagramm der Klassen Unit, UnitFactory, UnitType und UnitTypeStage

Abbildung 37: Aktivitätsdiagramm für das Erzeugen neuer Einheiten

Abbildung 38: UML-Diagramm der Fähigkeitsklassen und AbilityFactory

Abbildung 39: Aktivitätsdiagramm für die Erzeugung von Fähigkeiten

Abbildung 40: UML-Diagramm über den Aufbau der Klasse AbsMatch

Abbildung 41: Die gesamte TBS-Engine besteht aus 14 Hauptpaketen, die insgesamt wiederum noch einmal 14 Subpakete besitzen

Abbildung 42: Screenshot des Kartenwahlmenüs der Beispielimplementierung "Stickmen Resurrection"

Abbildung 43: Screenshot des Spielvorbereitungsmenüs aus der Beispielimplementierung "Stickmen Resurrection"

Abbildung 44: Stickmen Resurrection Programmablaufplan

Abbildung 45: TileSet-Grafik Beispiel

Abbildung 46: Karte TesertValley (Testmap Desert Valley) gebaut mit der o.g. TileSet-Grafik

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Glossar

Tile - Eine Texturkachel, die durch ihre Mehrfachverwendung Speicher spart.

TMX Tiled Map - Eine Karte bestehend aus Tiles (http://www.mapeditor.orgi

God View - Eine Sicht auf eine Spielwelt, die auf einen Blick alle Informationen präsentiert.

Kriegsnebel - Ein halbtransparent Gebiete verschleiernder Nebel, der statische Kartenelemente erkennen lässt (erkundete Regionen), dynamische Veränderungen (Bewegung von Einheiten) aber verschleiert.

Tick - Ein Tick ist ein Wechsel von einem Spieler zum nächsten Spieler in einer Spielrunde.

1. Einleitung

1.1 Allgemeine Motivation

Smartphones werden ein immer wichtigeres Werk- und Spielzeug in unserer modernen Welt. Schon 2010 war jedes dritte in Europa verkaufte Mobiltelefon ein Smartphone¹. Von den Smartphonebesitzern in den USA und Europa nutzen knapp 50% bereits das mobile Internet². Neben typischen Büroanwendungen (Kalender, Mail etc.) sind vor allem Spiele sehr gefragt. Ungefähr 25% ihrer Zeit verbringen Smartphonebesitzer mit Spielen³. Es gibt bereits eine Unmenge an kurzweiligen Casual Games, doch an etwas komplexeren Strategie- und Denkspielen herrscht noch großer Mangel. Genau an dem Punkt möchte ich ansetzen und ein Framework schaffen, um den meiner Meinung nach sehr vielversprechenden Genretyp Turn-Based Strategy Games (TBSG) zu fördern und selbst in Zukunft mit weniger Aufwand TBS-Spiele produzieren zu können.

1.2 Rundenbasierte Strategiespiele

Bei einem TBS-Spiel befinden sich zwei oder mehr Spieler auf einer Spielkarte und versuchen sich gegenseitig durch die Ausweitung ihres eigenen Einflussbereiches militärisch oder wirtschaftlich zu bezwingen. TBS-Spiele laufen immer nach dem gleichen Muster ab.

Spieler verabreden sich in der realen oder virtuellen Welt und entscheiden, was für eine Karte gewählt wird, wer welche Fraktion vertritt und mit welchen optionalen Regeln (Match Settings) gespielt werden soll. Eine Spielsession (Match) ist in Runden (Rounds) unterteilt, in der jeder Spieler einmal an der Reihe ist (Turn). Ist ein Spieler an der Reihe, so kann er so viele Züge (Steps) spielen, wie ihm das Spielkonzept erlaubt. Alle Spielschritte sind von der Realzeit unabhängig. Es kann sein, dass ein Spieler für einen Zug mehrere Stunden benötigt. Es ist aber auch möglich, dass eine ganze Spielrunde desselben Matches nur wenige Minuten dauert. Die Unabhängigkeit von der Realzeit erlaubt es, ein Match in Etappen zu spielen, unabhängig von Zeit und Aufenthaltsort der Mitspieler. Der Spieler, der als nächster an der Reihe ist, muss allerdings darauf warten, dass der aktuelle Spieler seinen Turn beendet. Es ist aber egal wo sich beide Spieler aufhalten, solange ein Weg zur Übermittlung des letzten Turns gefunden wird. Dieser Datenaustausch kann asynchron ablaufen und zum Beispiel im Fall des TBS-Spiels Schach auch sogar per Brief stattfinden. Wichtig ist allerdings, dass dem folgenden Spieler der komplette letzte Spielstand übermittelt wird.

Smartphones haben den großen Vorteil, dass man sie überall hin mitnehmen kann. Selbst an den abgelegensten Orten kann man seinen Kalender prüfen, Mails schreiben und Spiele spielen, doch leider gibt es noch immer Lücken bei der Funknetzabdeckung und auch in Großstädten kann es häufiger zu Störungen der Internetverbindung kommen. Kurzum: Auf eine unterbrechungsfreie Internetverbindung ist kein Verlass, weshalb Echtzeit­Multiplayerspiele wie man sie von Konsolen oder dem PC her kennt, nicht trivial umsetzbar sind. TBS-Spiele hingegen können asynchron gespielt werden und haben kein Problem mit Verbindungsabbrüchen. Weiterhin verlangen sie auch nicht, dass sich alle Spieler zur gleichen Zeit mit dem Spiel beschäftigen. Das ist ein deutlicher Vorteil gegenüber in Echtzeit ablaufenden Multiplayerspielen, wenn man bedenkt, dass Spiele auf mobilen Geräten in erster Linie zum Überbrücken von Wartezeit genutzt werden, die für jeden Spieler zu anderen Zeitpunkten und in unterschiedlicher Länge anfallen.

Im Folgenden ein Beispiel für die Umsetzung des Spielflusses:

Beendet der aktuelle Spieler seinen Zug, wird dieser bei der nächsten Gelegenheit auf dem Server abgelegt. Da alle anderen Mitspieler auf den Spielzug des aktuellen Spielers warten müssen, ist es unwichtig ob der Spielzug sofort oder erst in ein paar Stunden übertragen wird. Nach dem Upload auf den Server, kann zusätzlich noch eine Plausibilitätsprüfung durchgeführt werden, um unerlaubte Spielzüge zu verhindern. Danach können alle anderen Mitspieler den neuen Spielzug asynchron vom Server herunterladen, für sie relevante (weil vielleicht in ihrem Sichtfeld liegende) Aktionen betrachten und dann ihren eigenen Zug beginnen oder auf den nächsten Zug warten.

1.3 Plattform Google Android

Im Gegensatz zu iOS und Windows Mobile 7 ist Android eine freie Plattform. Smartphonehersteller jeder Größe können Android als Betriebssystem auf ihren Endgeräten einsetzen ohne Lizenzgebühren an Google Ine. zu zahlen⁴. Das führt zu einer großen Anzahl unterschiedlicher Endgeräte⁵, auf denen mit kleineren Anpassungen und der Berüeksiehtigung einer Handvoll unterschiedlicher Displayformate und API Levels dieselbe Software benutzt werden kann. Googles offener Umgang mit Android und die große Anzahl unterschiedlich ausgestatteter Geräte, lässt den Konkurrenzdruck steigen, was sieh wiederum in günstigen Preis-Leistungs-Verhältnissen für den Kunden niederschlägt. Geräte mit annehmbarer Leistung sind bereits 2011 für rund 300€ erhältlich⁶.Dadurch erhöht sich die Nutzerbasis und die Anzahl potentieller Kunden. Schon Ende 2010 wurden rund 33 Millionen Android-Geräte verkauft. Zum Vergleich: Apple hat im selben Zeitraum 16 Millionen Einheiten abgesetzt⁷. Das außerdem gerne vorgebrachte Argument der Fragmentierung der weltweit im Einsatz befindlichen Android-Versionen lässt sich leicht entkräften, wenn man aktuelle Statistiken zurate zieht. Setzt man bei der Entwicklung einer neuen Applikation die sehr stabile Android-Version 2.1 ein, so erreicht man bereits 96,4% aller Android-Nutzer im Google Market. Ich bin überzeugt, dass Google-Android in Zukunft sowohl im Smartphone- als auch im Tablet-Markt eine sehr wichtige Rolle spielen wird und es sich deshalb lohnt, ein für diese Plattform zugeschnittenes Framework zu entwerfen.

Abbildung in dieser Leseprobe nicht enthalten⁸

1.4 AndEngine - Übersicht

Die 2D-Spieleengine AndEngine⁹, programmiert von Nicolas Grämlich (Frühling 2010 bis heute), bietet Basiskomponenten, um das Erstellen einer möglichst breiten Palette von Spielen zu ermöglichen. Sie besitzt unter anderem ein Partikelsystem, ein System für das Laden und Abspielen von animierten Sprites, Management von Texturen, Musik- und Soundeffekten und ein System für das Laden von TMX Tiled Maps¹⁰. Weiterhin implementiert sie das Konzept einer Kamera, die das Spielgeschehen aus einer God View¹¹ einfängt, sowie ein Szenenkonzept für mehrschichtige Spielszenen, um unter anderem das für 2D-Jump-n- Runs wichtige Konzept der Bewegungsparallaxe zu implementieren und viele kleinere Werkzeuge, um die Spielentwicklung zu vereinfachen. Des weiteren existiert eine Multiplayer Erweiterung¹², auf die ich meine Multiplayer Implementierung aufsetzen werde. Die AndEngine ist mit der Lesser General Public License (LGPL) lizenziert¹³ und erlaubt ausdrücklich die Verwendung für die Entwicklung kommerzieller Projekte, ohne den Quellcode des eigenen Spiels offenlegen zu müssen¹⁴.

1.5 Das Ziel dieser Arbeit und mein weiteres Vorgehen

Das Ziel dieser Arbeit ist den Zwischenschritt von der bereits existierenden Spieleengine AndEngine hin zu einer Turn Based Strategy Game Engine (TBS-Engine) so weit wie möglich zu entwickeln. Dabei wird es wichtig sein nicht zu wenig zu konkretisieren, damit der Zwischenschritt einen Mehrwert liefert, aber auch nicht zu viel zu spezialisieren, was wiederum bei der Entwicklung abweichender Spielkonzepte hinderlich sein könnte.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Entwicklung von AndEngine über TBS-Engine hin zum Spiel

Mein erster Schritt wird darin bestehen Spiele zu suchen, die mit der TBS-Engine umsetzbar sein sollen.

Im zweiten Schritt werde ich diese Spiele vergleichen, um möglichst viele Gemeinsamkeiten zu finden, für die es sich lohnt konkretere (aber weiterhin abstrakte) Klassen und Konzepte zu entwerfen. Unter jedes gefundene Element werde ich ein Konzept für die spätere Implementierung schreiben und die von mir gewählten Klassen- und Interfacenamen durch die Schreibweise und Schriftart Courier und fett kennzeichnen. Außerdem führe ich als Konvention ein, dass die Namen abstrakter Klassen, die vom Entwickler implementiert werden müssen, mit Abs beginnen und dass Interface-Namen mit I beginnen. Wenn ich auf bereits im AndEngine Framework existierende Klassen Bezug nehme, werde ich diese durch die Schreibweise und Schriftart Courier kursivund fett markieren.

Mein dritter Schritt wird darin bestehen, die Engine und parallel dazu eine Beispielimplementierung (das von mir konzipierte Mini-Spiel Stickmen Resurrection) zu programmieren. Im schriftlichen Teil dieses Schritts (siehe Kapitel 3. Implementierung) werde ich auf die von mir verwendeten Software Design-Patterns eingehen, sowie die wichtigsten Komponenten des Frameworks genauer beschreiben. Die detaillierten Beschreibungen der Methoden und Klassen finden sich als JavaDoc auf der beiliegenden CD.

Sowohl die TBS-Engine als auch die Beispielimplementierung ist LGPL lizenziert und ist auf Google Code öffentlich zugänglich.

Der Link zum Projekt lautet https://code.aooale.eom/p/tbsenaine/.

Hier nochmal stichpunktartia die Ziele, die ich mir für die Arbeit aesetzt habe:

- passende Softwareplattform für die Entwickluna des Frameworks und passende Spiele für die Analyse finden;
- Spiele veraleichen und möalichst viele Komponenten und Game Desianpatterns ermitteln, die eine Basisimplementieruna erlauben;
- möaliche Konzepte für die Implementieruna der zuvor ermittelten Komponenten entwerfen;
- Das Framework samt einer Beispielimplementieruna proarammieren, in der es möalich ist...

- ein Multiplayerspiel im Wireless Local Area Network (WLAN) zu erstellen indem die Spieler...
- einen Multiplayertyp auswählen,
- eine Karte wählen (Spielersteller) oder sich mit einem Server verbinden (beitretender Spieler),
- das Spiel vorbereiten, die Karteneinstellunaen bearbeiten, sowie Fraktionen, Teams und Spielerfarben wählen können,
- dabei mit den anderen potentiellen Spielern chatten können.
- Ein Multiplayerspiel beainnen, indem ...
- jeder Spieler nacheinander an der Reihe ist (Rundenkonzept implementiert),
- jeder Spieler mindestens eine animierte Einheit durch die Spielwelt beweaen kann.

2. Analyse

2.1 Die Wahl derzu vergleichenden Spiele

Meine Wahl fiel auf die drei Spiele Heroes of Might and Magic IV, Battle for Wesnoth und Civilization IV. Alle drei Spiele sind im Kern rundenbasierte Strategiespiele mit beachtlichem inhaltlichem Umfang und Komplexität. Sie präsentieren völlig unterschiedliche Szenarien und unterscheiden sich vor allem in ihrem Auftreten. Die zugrundeliegende Spielmechanik hingegen weist viele Parallelen auf, die es genauer zu untersuchen und je nach Menge der Übereinstimmungen in Komponenten und Konzepten zusammenzufassen gilt. Gleichzeitig gehören alle drei Spiele zu bekannten Marken oder sind in ihrem Bereich einzigartig und in der Spielerschaft allgemein bekannt. Alle drei Spiele lassen sich zudem leicht um neue Inhalte wie Karten, Kampagnen und Spielfiguren erweitern. Das ist wichtig, da Spieleentwickler für mobile Endgeräte in Zukunft ihre Spiele vor allem durch den Verkauf von Download-Content (DLC) monetarisieren werden müssen, denn das Preisniveau von Spielen im Android-Market und somit auch die Preiserwartung der Kunden liegt im niedrigen einstelligen Dollar-Bereich¹⁵.

2.1.1 Heroes of Might and Maigc IV - Kurzbeschreibung

Heroes of Might and Magic IV ist ein von Ubisoft produziertes TBS-Spiel, das in einer stark magielastigen Fantasiewelt spielt. Gespielt wird auf orthogonalen 2D-Karten mit quadratischer Topologie. Zu Beginn eines Spiels kann jeder Spieler zwischen folgenden magischen Ausrichtungen und somit auch Fraktionen (im Spiel „Städte“ genannt) wählen: Natur, Ordnung, Leben, Macht, Chaos, und Tod. Die Spieler beginnen mit einer Stadt, die es auszubauen gilt und einem Helden, der die Karte erkunden, Zauber sprechen, gegnerische Städte und sonstige auf dem Weg befindliche Einrichtungen einnehmen und somit die eigentliche Interaktion mit der Spielwelt durchführen kann. Ziel aller Spieler ist es, alle gegnerischen Städte einzunehmen und somit das Spiel zu gewinnen. Auf dem Weg dorthin bauen die Spieler ihre Städte aus, um mehr Ressourcen, bessere Verteidigung und bessere Kreaturen zu erhalten. Außerdem lassen sie ihre Helden Erfahrungspunkte sammeln, um sie in ihrem Level aufsteigen zu lassen und dadurch neue Fertigkeiten freizuschalten. Auf dem Weg zu gegnerischen Städten nehmen sie Bergwerke, Behausungen anderer Kreaturen, Portale und weitere Orte ein. Das Spiel lebt von seiner sehr detaillierten Spielwelt, die es erlaubt für viele Stunden am Stück in diese Fantasiewelt einzutauchen. Es bietet Mehrspielermodi für HotSeat¹⁶, LAN und Internet per GameSpy¹⁷.

Abbildung in dieser Leseprobe nicht enthalten

2.1.2 Battle for Wesnoth - Kurzbeschreibung

Battle for Wesnoth ist ein Open Source TBS-Spiel, das in einer Fantasiewelt spielt. Gespielt wird auf orthogonalen 2D-Karten mit Hexfeld-Topologie. Die Spieler können sich wahlweise auf die Seite der Loyalisten, der Rebellen, der Nordmannen, der Untoten, der Knalgan- Allianz, oder der Draken schlagen. Trotz der großen Anzahl an Fraktionen haben es die Entwickler geschafft, sehr unterschiedliche Kreaturen-Sets für jede Fraktion zu entwickeln. Jeder Spieler beginnt mit einem Anführer und bekommt den Auftrag mit diesem die gegnerischen Anführer zu bezwingen. Um dies Ziel zu erreichen, müssen die Spieler auf den Karten verteilte Produktionsstätten wie Forts und Burgen mit ihrem Helden besetzen und weitere Kreaturen gegen Geld erschaffen. Diese lassen sie dann über die Karte wandern, um Dörfer einzunehmen, strategische Punkte wie Brücken oder Bergpässe zu sichern und versuchen so strategische Vorteile zu erlangen. Das Spiel ist mehrspielerfähig und lässt sich mit einem PC per HotSeat, im LAN und über das Internet auf einem eigens dafür eingerichteten Gameserver spielen. Besonders erwähnenswert ist der Karteneditor samt eigener Auszeichnungssprache genannt Wesnoth Markup Language (WML)¹⁸, mit der sich Kreaturen, Karten, Kampagnen und Speicherstände beschreiben und manipulieren lassen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Screenshot Battle for Wesnoth

2.1.3 Civilization IV - Kurzbeschreibung

Civilization IV ist ein von Firaxis Games produziertes TBS-Spiel, in dem die Spieler die Aufgabe haben, ein Volk ihrer Wahl von der Jungsteinzeit bis in die Gegenwart und darüber hinaus zu führen. Gespielt wird auf orthogonalen 2D-Karten mit quadratischer Topologie. Das Spiel ist angereichert mit einer enormen Menge historischer Figuren und Ereignisse, die den Spielern nach und nach begegnen und ihnen das Gefühl vermitteln, die Geschichte aus Sicht des von ihnen gewählten Volkes neu zu schreiben. Ein typisches Civilization IV Match beginnt mit einem Pionier, den man an geeigneter Stelle die erste Siedlung errichten lässt. Nach und nach baut man diese Siedlung aus und gründet neue Siedlungen, um das eigene Reich auszudehnen. Ein starker Fokus liegt auf der Erforschung großer Technologiebäume und damit das Erlangen neuer Fähigkeiten, einem recht umfangreichen Diplomatiesystem und dem geschickten Ausbau der eigenen Städte, passend zu den umliegenden Landstrichen. Es ist möglich das Hauptspiel zu modifizieren, denn alle relevanten Daten sind in veränderbaren Extensible Markup Language (XML)-Dateien gespeichert. Außerdem wurde ein umfangreiches Software Development Kit (SDK) veröffentlicht, mit dem sich Modifikationen erstellen lassen. Das Spiel ist mehrspielerfähig und bietet die Möglichkeit mit einem PC per HotSeat, im LAN und über das Internet (GameSpy) und per E-Mail zu spielen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Civilization IV Screenshot

2.2 Komponentenanalyse und Konzepte

Für den Analyseschritt werde ich das Buch Patterns in Game Design¹⁹ verwenden, um Gamedesign-Elemente spielunabhängig und damit vergleichbarer zu machen. Außerdem erhoffe ich mir dadurch Hilfe für die Namensfindung für abstrakte Klassen und Interfaces. Ich werde mir die Designmuster heraussuchen, die zum einen Klassen und Funktionen repräsentieren können und zum anderen, in den unter 2.1 Die Wahl der zu vergleichenden Spiele genannten Spielen, möglichst viele Ähnlichkeiten in ihrer Umsetzung besitzen. Des weiteren werde ich Objekte, Elemente und Konzepte, die mir bei der Analyse dieser Spiele auffallen, bestimmten Musterkategorien zuordnen.

Neben den direkt für die Spiellogik relevanten Inhalten, werde ich auch Menüs und andere nicht direkt für die Spiellogik relevante Aspekte der Spiele betrachten, und wenn möglich abstrakte Datenverarbeitungs- und Delegationsmodelle in Form von abstrakten Klassen und Interfaces formulieren.

2.2.1 Game Design Muster

2.2.1.1 Musterfür Spielelemente

Game World (Levels)²⁰

Die Spielwelten oder Levels werden in allen drei Spielen durch Karten repräsentiert. Die Karten wiederum setzen sich aus Schichten zusammen. Die erste Schicht besteht aus unterschiedlichen Typen von Untergrund. Die zweite Schicht besteht aus Verzierungen, die selbst nicht aktiv interagieren. Die dritte Schicht beinhaltet die eigentlichen

Abbildung in dieser Leseprobe nicht enthalten

Spielelemente²¹. Alle drei Schichten haben Abbildung 7: Die vier Schichten einer Karte Einfluss auf die Begehbarkeit der Flächen, die sie bedecken, wobei die nächsthöhere Schicht die Eigenschaften der darunterliegenden Schicht überschreiben kann. Die vierte Schicht ist unterschiedlichen Typen von Regionen vorbehalten. Diese Regionen werden entweder von Map-Designern angelegt, um zum Beispiel gescriptete Ereignisse in ihnen stattfinden zu lassen, oder sie werden durch im Gamedesign festgelegte Funktionen generiert. Ein Beispiel für letztgenannte Schichten wäre Kriegsnebel oder Regionen, die den Macht- und Einflussbereich einer Stadt anzeigen.

Abbildung in dieser Leseprobe nicht enthalten

Konzept

Ich werde eine Klasse namens AbsMap implementieren. Als Map-Format werde ich das XML-Format des freien Tiled Map Editors²² *.tmx verwenden.

Als Konvention werde ich einführen, dass jede Map mindestens fünf Ebenen besitzt. Die ersten zwei Ebenen werden die Tiled Layer Underground und Decorations sein. Sie entsprechen den Schichten eins und zwei in der vorangegangenen Beschreibung. Die darauf folgenden drei Ebenen werden die Objektgruppen, Doodads, GameObjects und Areas sein. Im Bezug auf die vorangegangene Beschreibung teilen sich die beiden Ebenen Doodads und GameObjects die Schicht drei. Die dritte Ebene Doodads soll sehr simple meist statische Objekte enthalten, die keinen Besitzer und keine aktiven Fähigkeiten haben, aber möglicherweise Animationen und Bewegungspfade besitzen und deshalb nicht mehr wie Maptiles platziert werden können. Die vierte Ebene GameObjects soll alle restlichen Spielelemente, wie Einheiten und Gegenstände beinhalten. Diese haben aktive und passive Fähigkeiten, gehören einem bestimmten Spieler und besitzen mehrere Animationen und Soundeffekte. Die fünfte Ebene Areas entspricht der Schicht vier in der vorangegangenen Beschreibung. Sie soll Regionen beinhalten, die zum Beispiel zum Auslösen von Ereignissen verwendet werden.

Da Maps sehr komplexe Objekte sind, sollten sie so selten wie möglich geladen werden. Deshalb werde ich eine Klasse namens AbsMapOverview implementieren, die nur ein kleines Subset von Metainformationen einer vollständig Map beinhalten wird. Objekte dieser Klasse können zum Beispiel bei der Kartenwahl beim Erstellen einer neuen Spielrunde geladen werden.

Abbildung in dieser Leseprobe nicht enthalten

Player

Ein Spieler repräsentiert einen menschlichen oder computergesteuerten Mitspieler. Alle drei Spiele kennen das Konzept des Spielers.

Player Konzept

Um Spieler innerhalb der Engine zu repräsentieren, werde ich zwei Klassen implementieren. Die Basisklasse wird BasePlayer sein. Ein BasePlayer wird mindestens eine ID und optional einen Namen besitzen. AbaAlplayer wird eine Erweiterung der BasePlayer­Klasse sein und einen Ausgangspunkt bilden, um KI Spieler zu entwickeln.

Unit

Alle drei Spiele kennen Spielergegenstände in Form von mobilen Einheiten²³ und statischen Objekten, wie besondere Orte, von Spielern erschaffene Städte oder eingenommene Schlüsselpositionen. Mit ihnen kann ein Spieler mit der Spielwelt interagieren, an Macht und Einfluss gewinnen und somit seinem Spielziel näher kommen.

Unit Konzept

Einheiten sind die Summe ihrer Beschreibungen, Fähigkeiten und Attribute und gehören neben Karten zu den Spielbestandteilen, die von den Personen im Spieleentwicklerteam die keine Programmierer sind, am häufigsten geändert und erweitert werden. Deshalb habe ich mich entschieden, das Beschreiben von Einheitentypen nicht durch das Implementieren einer abstrakten Klasse zu ermöglichen, sondern sie über XML-Dateien zu laden. Ich werde ein XML-Format für das Beschreiben von Einheitentypen entwerfen, das später zum Beispiel in selbst geschriebenen Editoren leicht zu bearbeiten sein wird. Innerhalb der Engine werden dann über eine Klasse namens UnitFactory Einheiten erzeugt, indem man UnitFactory mitteilt, von welchem UnitType die neue Unit sein soll und wer der Besitzer sein wird.

Unit Ability

Der Begriff Fähigkeiten²⁴ beschreibt in diesem Abschnitt die aktiven und passiven Fähigkeiten von Units. In allen drei Spielen haben Units die Möglichkeit sich zu bewegen, zu kämpfen, etwas zu produzieren, durch ihre Anwesenheit passiv etwas zu beeinflussen und sich weiter zu entwickeln.

Aktive Fähigkeiten werden meist durch Buttons repräsentiert, die nach dem Anwählen einer Einheit oder eines Gebäudes im Benutzerinterface sichtbar werden. Die andere parallel in diesen Spielen eingesetzte Möglichkeit ist, interaktiv kleine Icons einzublenden, je nachdem worüber der Mauszeiger gerade schwebt. Letztgenannte Option ist besonders für mausgesteuerte Spiele sehr elegant, erspart sie doch einen extra Klick auf einen Aktionsknopf. Ist mehr als eine Option möglich, so wird nach dem ersten Klick ein kleiner Kontextdialog geöffnet, der alle weiteren Optionen zur Verfügung stellt oder weitere Subkontexte enthält. Die passiven Fähigkeiten werden durch Beschreibungstexte, Zahlen und Icons repräsentiert, die die Spieler zwar betrachten aber nicht direkt manipulieren können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 13: Heroes ofMight and Magic - Interaktiv eingeblendetes Symbol für das Angreifen der in der Nähe befindlichen Einheit

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 14: Battle forWesnoth - Kontextmenü für die Auswahl des Angrifftyps nach einem Klick auf eine gegnerische Einheit

Unit Ability Konzept

Ich werde einen Mittelweg zwischen bereits vorgefertigter Implementierung und dynamischer Anpassung über XML wählen. Zuallererst werde ich eine Klasse namens AbsAbility implementieren, die grundlegende Membervariablen und Funktionen beinhalten wird. Von dieser Klasse ausgehend, werde ich grundlegende Fähigkeitstypen wie AttackAbility, MovementAbility, UnitProductionAbility, ResourceProductionAbility oder SightAbility implementieren. Die drei zuerst genannten Ableitungen sind dabei Beispiele aktiver Fähigkeitsklassen und die zwei letztgenannten Beispiele für passive Fähigkeitsklassen. Für die weitere Spezialisierung dieser Fähigkeiten wird der Inhalt eines XML-Tags innerhalb der XML-Dateien zur Beschreibung von Einheiten zuständig sein. So können Entwickler zum Beispiel allen Nah- und Fernkampfeinheiten jeweils ihre eigenen Angriffsfähigkeiten zuordnen, die wiederum unterschiedliche Icons, grafische Effekte, Reichweiten und Schadenswirkungen haben und doch auf der gleichen Funktionalität beruhen.

[...]

---

¹ comScore 2010 Digital Review p. 20

² comScore 2010 Mobile Year in Review p. 5

³ comScore 2010 Mobile Year in Review p. 22

⁴ Android Licence http://source.android.com/source/licenses.html (22.03.2011)

⁵ Listof Android Phones - http://www.andro-phones.com/2010-android-phones.php (31.03.2011)

⁶ Amazon.de Preis für „Motorla Milestone“ am 31.03.2011

⁷ McCarthy, Canalys research 2011 p. 3

⁸ Grafik über Android API Fragmentierung Stand 05.07.2011. Quelle: http://developer.androld.com/resources/dashboard/platform-verslons.html (08.07.2011)

⁹ AndEngine (Autor: Nicolas Gramlich) - http://www.andengine.org (22.03.2011)

¹⁰ TMX Tiled Maps: Aus Tiles bestehende Karten. - http://www.mapeditor.org/

¹¹ God Views: Patterns in Game Design CD - /collection/Alphabetical_Patterns/GodViews.htm

¹² AndEngine Multiplayer Extension - https://code.google.com/p/andenginemultiplaverextension/

¹³ GNU Lesser General Public License - http://www.gnu.org/licenses/lgpl.html

¹⁴ AndEngine and the LGPL - clarification! http://www.andengine.org/blog/2010/11/andengine-and- the-lgpl-clarification/ - (28.03.2011)

¹⁵ Die drei erfolgreichsten Spiele im Android-Market (April 2011) liegen preislich zwischen 0,99$ und 2,99$. Distimo Publication May 2011 - p.18

¹⁶ HotSeat - zwei oder mehrere Spieler spielen vor demselben Bildschirm und wechseln sich nacheinander ab.

¹⁷ GameSpy - Ein Spielenetzwerk und eine Community http://www.gamespv.com/ (22.03.2011 )

¹⁸ Wesnoth Markup Language - http://wiki.wesnoth.org/ReferenceWML (22.03.2011 )

¹⁹ Patterns in Game Design - Staffan Bjork, Jussi Holopainen, 2005

²⁰ Levels: Patterns in Game Design - p. 60

²¹ Game Design Patterns for Game Elements: Patterns in Game Design - p. 55

²² Tiled Map Editor - http://www.mapeditor.org/

²³ Units: Patterns in Game Design - p. 79

²⁴ Action and Events Patterns: Patterns in Game Design - p.107 und Orthogonal Unit Differentiation: Patterns in Game Design CD -/collection/Alphabetical_Patterns/OrthogonalUnitDifferentiation.htm