Entwicklung eines flexiblen Objektmodells für ein ... - Jens Pfau

Technische Universität Darmstadt 

Fachbereich Informatik 

Entwicklung eines flexiblen 

Objektmodells für ein 

Gaming-Framework 

Bachelorarbeit von 

Jens Pfau, Stephan Mehlhase 

Betreuer: Dipl.-Inform. Patric Kabus 

Eingereicht bei: Prof. Alejandro P. Buchmann, Ph. D. 

Fachgebiet Datenbanken und Verteilte Systeme 

Fachbereich Informatik 

TU Darmstadt 

31. August 2006

Ehrenwörtliche Erklärung 

Hiermit versicheren wir, die vorliegende Arbeit ohne Hilfe Dritter und nur mit den angegebenen 

Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus den Quellen entnommen 

wurden, sind als solche kenntlich gemacht worden. Diese Arbeit hat in gleicher oder ähnlicher 

Form noch keiner Prüfungsbehörde vorgelegen. 

Darmstadt, den 31. August 2006

Zusammenfassung 

Jedes Computerspiel basiert auf einer Vielzahl von virtuellen Objekten, die unter anderem als 

Repräsentation visuell dargestellter Gegenstände, Charaktere und Gebäude fungieren. Deren 

Modellierung und Verwaltung ist daher eminent für die Funktionalität eines Spielesystems. 

Ein solches als Objektmodell bezeichnetes Subsystem wird üblicherweise für jede Spieleproduktion 

und deren spezifische Anforderungen erneut entworfen. Das bedarf den wiederholten 

Einsatz von Ressourcen zur Lösung des gleichen Problems. 

Diese Arbeit beschäftigt sich daher mit der Frage, welche Aspekte bei der Modellierung eines solchen 

Systems von Belang sind und welche Ansätze zur Umsetzung derselben existieren. Darauf 

aufbauend wird eine Architektur entwickelt, die als vorrangige Anforderungen die Erweiterbarkeit 

und Wiederverwendbarkeit erfüllen soll, um flexibel an unterschiedliche Einsatzszenarien 

anpassbar zu sein. Dadurch sollen Kosten und Entwicklungszeit in der Spieleproduktion gesenkt 

werden.

Danksagung 

Wir möchten uns an dieser Stelle ganz herzlich bei Patric Kabus bedanken, der es uns ermöglicht 

hat, einen tiefgreifenden Einblick in ein interessantes Themengebiet zu erhalten, das uns auch 

in der Freizeit begeistert. Seine Reaktionsgeschwindigkeit bei Anfragen war vor allem in der 

Endphase der Arbeit hilfreich. 

Ebenfalls Dank gebührt Silvia Graumann, Markus Günther und Paul Bächer, die wiederholt 

dieses Dokument korrekturgelesen und uns auf Unzulänglichkeiten und mögliche Erweiterungen 

hingewiesen haben. 

Abschließend möchten wir uns bei unseren Eltern für die sicher nicht selbstverständliche finanzielle 

Rückendeckung sowie bei Stephans Freundin Sabrina Jäger für ihre Geduld und Standhaftigkeit 

im Angesicht eines dauerhaft gestressten Partners bedanken.

Inhaltsverzeichnis 

1 Einleitung 1 

2 Motivation 3 

3 Taxonomie 5 

3.1 Objektstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

3.1.1 Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

3.1.1.1 Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

3.1.1.2 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

3.1.2 Verhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

3.1.2.1 Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

3.1.2.2 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

3.1.3 Typen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

3.1.3.1 Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

3.1.3.2 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 

3.1.3.3 Vererbung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 

3.1.4 Objektordnung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 

3.2 Dynamik zur Laufzeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

3.3 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

3.3.1 Initiative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 

3.3.1.1 Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 

3.3.1.2 Publish/Subscribe . . . . . . . . . . . . . . . . . . . . . . . . . . 23 

3.3.2 Änderungsübermittlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

3.3.2.1 Delta Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

3.3.2.2 Aktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

3.3.3 Kompression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

3.3.3.1 Semantik-abhängig . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

3.3.3.2 Semantik-unabhängig . . . . . . . . . . . . . . . . . . . . . . . . 25 

3.3.4 Quality of Service (QoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

3.3.4.1 Semantik-abhängig . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

3.3.4.2 Semantik-unabhängig . . . . . . . . . . . . . . . . . . . . . . . . 25 

3.4 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

4 Anforderungen 28 

4.1 Darstellung der Objektstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 

4.2 Unabhängigkeit des Systems vom Spieldesign . . . . . . . . . . . . . . . . . . . . 29 

4.3 Persistenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

IV Inhaltsverzeichnis 

4.4 Performanz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 

4.5 Erweiterbarkeit und Wiederverwendbarkeit . . . . . . . . . . . . . . . . . . . . . 30 

4.6 Abgrenzung und Einschränkung der Aufgabe . . . . . . . . . . . . . . . . . . . . 30 

5 Bestehende Systeme 31 

5.1 Dungeon Siege . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 

5.1.1 Systembeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 

5.1.2 Einordnung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 

5.1.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 

5.2 Thief und Deus Ex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 


5.2.2 Einordnung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 

5.2.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 

5.3 Worldforge Atlas Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 


5.3.2 Einordnung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

5.3.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

5.4 Britt L. Hannahs Vorschlag für ein Objektmodell . . . . . . . . . . . . . . . . . . 40 


5.4.2 Einordnung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 

5.4.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 

6 Design und Implementierung 45 

6.1 Spielobjekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 

6.1.1 Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 

6.1.2 Verhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 

6.1.3 Typisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 

6.1.4 Anordnung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 

6.2 Dynamik zur Laufzeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 

6.3 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 

6.3.1 Initiative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 

6.3.2 Änderungsübermittlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 

6.3.3 Kompression und Quality of Service . . . . . . . . . . . . . . . . . . . . . 60 

6.4 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 

7 Integration 65 

7.1 Objekthierachien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 

7.2 Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 

7.3 Aktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 

8 Zusammenfassung und Ausblick 73 

8.1 Kritikpunkte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 

8.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 

IV Jens Pfau · Stephan Mehlhase

Abbildungsverzeichnis 

3.1 Baumansicht der Taxonomie (Objektstruktur) . . . . . . . . . . . . . . . . . . . . 26 

3.2 Baumansicht der Taxonomie (Dynamik) . . . . . . . . . . . . . . . . . . . . . . . 27 

3.3 Baumansicht der Taxonomie (Kommunikation) . . . . . . . . . . . . . . . . . . . 27 

5.1 Skizze des Dungeon Siege Objektmodells . . . . . . . . . . . . . . . . . . . . . . . 32 

5.2 Einordnung des von Dungeon Siege verwendeten Systems in die Taxonomie . . . 34 

5.3 Einordnung des von Thief und Deus Ex verwendeten Systems in die Taxonomie . 36 

5.4 Einordnung des in Atlas verwendeten Systems in die Taxonomie . . . . . . . . . 39 

5.5 UML Diagramm der von Britt L. Hannah vorgeschlagenen Architektur . . . . . . 41 

5.6 Einordnung des von Britt L. Hannah vorgeschlagenen Systems in die Taxonomie 44 

6.1 UML Diagramm der Zustände . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 

6.2 UML Diagramm der Aktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 

6.3 UML Diagramm der Typen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 

6.4 UML Diagramm der Anordnung von Objekten . . . . . . . . . . . . . . . . . . . 53 

6.5 UML Diagramm des TreeManager . . . . . . . . . . . . . . . . . . . . . . . . . . 54 

6.6 UML Diagramm des Observermechanismus . . . . . . . . . . . . . . . . . . . . . 57 

6.7 UML Diagramm der Deltaobjekte . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 

6.8 UML Diagramm der Property Objekte . . . . . . . . . . . . . . . . . . . . . . . 61 

6.9 Überblick über die entwickelte Architektur . . . . . . . . . . . . . . . . . . . . . . 63 

6.10 Einordnung des von uns entwickelten Systems in die Taxonomie . . . . . . . . . . 64

Listings 

7.1 ROT13 Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 

7.2 Die IncreaseHP Aktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 

7.3 Methode zum Beenden einer Aktion . . . . . . . . . . . . . . . . . . . . . . . . . 71 

7.4 Ausführung einer in Lua geschriebenen Aktion . . . . . . . . . . . . . . . . . . . 72

Kapitel 1 

Einleitung 

Eine lange Reise beginnt mit dem 

ersten Schritt. 

Chinesisches Sprichwort 

Die Computerspielebranche hat in den letzten Jahren immer eindrucksvollere Produkte auf den 

Markt geworfen. Mit der Entwicklung vom einfachen Tetris zur komplexen Spielewelt hat sich 

vordergründig vor allem die visuelle Darstellung verändert, aber auch die Technologie, die ein 

Spiel mit seiner Logik und seinen Regeln erst zum Leben erweckt, musste Adaptionen erfahren, 

um den wachsenden Anforderungen gerecht zu werden. 

Seit etwa einem Jahrzehnt bietet sich den Spielern die Möglichkeit, ihre Fähigkeiten auf vielfältige 

Weise untereinander im Internet zu messen. Dabei sind die Möglichkeiten nur von der 

eigenen Fantasie begrenzt. Spieler tragen virtuelle Schlachten aus oder kreieren Charaktere, die 

zu tausenden mit eigener Geschichte und eigenem Beruf Teil persistenter Spielewelten sind, die 

nicht nur durch deren Betreiber, sondern auch durch die Teilnehmer selber beeinflusst werden. 

Dies bedeutet natürlich einen enormen Aufwand sowohl administrativer als auch technischer 

Natur, denn schließlich wollen zahlende Spieler „ihre“ Welt zu möglichst jedem Zeitpunkt in 

konsistentem Zustand vorfinden. Um diesen Ansprüchen gerecht zu werden, betreiben die Spieleentwickler 

eigene Rechenzentren, in denen die Technologie untergebracht ist, die zur Aufrechterhaltung 

der virtuellen Welt nötig ist. 

Ein dezentraler Ansatz, bei dem die Ressourcen, die die Spieler in Form ihres eigenen Computers 

in das System einbringen, zur Unterstützung der gesamten Anwendung verwendet werden, 

könnte hier Abhilfe schaffen. Das Abtreten von Verwantwortung seitens der Spielbetreiber birgt 

allerdings auch Probleme. Wenn Spiellogik nicht mehr nur auf einer überschaubaren Anzahl 

von Computern stattfindet, ist die Gefahr gegeben, dass Spieler dies zu ihrem Vorteil ausnutzen. 

Zur Untersuchung dieser Probleme wird ein Framework für Onlinespiele nach dem oben 

vorgestellten, als Peer-to-Peer bezeichneten Ansatz erstellt. 

Das Ziel der vorliegenden Arbeit ist, ein Objektmodell zu entwickeln, welches sich in dieses 

Framework einfügt. Als Objektmodell wird der Teil eines Spiels bezeichnet, welcher für die 

Verwaltung der Spielobjekte, nämlich der Elemente der Spielwelt wie Charaktere, Gegenstände, 

Gebäude und Fahrzeuge, verantwortlich zeichnet. Die Anforderungen an ein solches Subsystem 

sind vor allem bei Onlinespielen vielfältig, denn die Spielwelt muss zu jedem Zeitpunkt über

2 I. Einleitung 

alle Teilnehmer konsistent sein. 

Zu diesem Thema existiert vor allem Literatur aus der Praxis, die für bestimmte Spiele spezifische 

Ansätze vorstellt. Jeder Spielehersteller entwirft naheliegenderweise ein Objektmodell, 

das auf seine Anforderungen maßgeschneidert ist. Im Folgenden wird deshalb, nachdem zunächst 

die Motivation für diese Arbeit dargelegt (Kapitel 2) wurde, eine Taxonomie (Kapitel 3) 

erarbeitet, um einen Überblick über die Möglichkeiten und Ideen zur Implementierung eines 

solchen Systems zu erlangen. Darauf aufbauend werden die Anforderungen an das Objektmodell, 

welches im Laufe dieser Arbeit entstehen soll, identifiziert (Kapitel 4). Nachfolgend werden 

verschiedene Ansätze und Spieleentwicklungen nach der Taxonomie eingeordnet und gegen die 

Anforderungen geprüft (Kapitel 5). Daraus folgend wird ein Architekturvorschlag gegeben und 

eine Referenzimplementierung erstellt (Kapitel 6). Schließlich wird die Verwendung der Implementierung 

beschrieben (Kapitel 7) sowie die Ergebnisse der Arbeit zusammengefasst und ein 

Ausblick für Erweiterungen und weitergehende Untersuchungen geboten (Kapitel 8). 

2 Jens Pfau · Stephan Mehlhase

Kapitel 2 

Motivation 

Man muß das Unmögliche versuchen, 

um das Mögliche zu erreichen. 

Hermann Hesse 

Die Softwareentwicklung hat seit ihrem Beginn viele Entwicklungsschritte durchwandert. Die 

prägnantesten waren wohl die, die den Wechsel von einem Programmierparadigma zum nächsten 

einläuteten. Mit wachsenden Anforderungen entstanden zunächst die prozedurale und dann die 

objektorientierte Programmierung, deren Vorteile in der Erweiterbarkeit und Wiederverwendbarkeit 

bestehender Komponenten liegen. Doch erst mit der Erforschung der sich neu bietenden 

Möglichkeiten und dem Entwurf von allgemeingültigen Entwicklungsmethoden konnten diese in 

Zeit- und Kostenersparnisse umgemünzt werden. Die derzeitige Krönung dieser Evolution sind 

Frameworks, die den Entwicklern von Softwaresystemen wiederkehrende Aufgaben abnehmen, 

indem sie Komponenten und deren Schnittstellen vordefinieren. 

Die Spieleentwicklung hingegen, deren Produkte ebenfalls Softwaresysteme sind, hat noch nicht 

vollständig den Übergang zur objektorientierten Programmierung gemeistert. Doch die Anforderungen, 

die die Kunden und Vertreiber an die Entwickler stellen, wachsen stetig. Vor allem 

werden kurze Entwicklungszeiten gefordert, damit ein Produkt zum Zeitpunkt seiner Veröffentlichung 

möglichst auf dem aktuellen Stand der Technik ist. Deshalb bedarf es in dieser immer 

bedeutender werdenden Sparte der Softwareentwicklung der Erforschung allgemein anwendbarer 

Methoden, um den Entwurf von Spielen zu optimieren, das heißt, den Aufwand an Zeit und 

damit auch Kosten zu senken. Erste wissenschaftliche Arbeiten und Frameworkentwicklungen 

stoßen in diese Richtung vor. 

Zentral für ein Spiel sind offensichtlich die Objekte, mit denen der Benutzer über Ein- und 

Ausgabe interagiert. Deren virtuelle Repräsentation und Wechselbeziehungen sind jedoch komplexer, 

als es auf den ersten Blick erscheint. Um den unterschiedlichen Subsystemen eines Spiels 

diese Entitäten in geeigneter Weise zur Verfügung zu stellen, braucht es einer durchdachten 

Verwaltung derselben. 

Das Ziel dieser Arbeit ist, ein solches Objektmodell als eigenständige Komponente eines Frameworks 

zu entwickeln, das die Entwicklung von Multiplayerspielen unterschiedlichster Architektur 

unterstützen soll. Eben diese Flexibilität des Einsatzes ist ein bedeutendes Charakteristikum 

von Frameworks. Natürlich muss auch das Objektmodell diesen Punkt berücksichtigen. 

Darüberhinaus soll mit einer leichten Erweiter- und Wiederverwendbarkeit auch unabhängig 

von dem genannten Framework gezeigt werden, dass die wiederholte Entwicklung einer solchen

4 II. Motivation 

Komponente für jedes neue Projekt nicht unbedingt notwendig ist und damit durch die Wiederverwendung 

eines flexiblen bestehenden Objektmodells Ressourcen gespart werden können. 

An einem Spieleprojekt arbeiten heute nicht mehr nur Programmierer sondern auch Grafiker, 

Musiker und Angehörige vieler weiterer Berufsgruppen. Damit der Inhalt eines Spiels nicht erst 

entwickelt werden kann, nachdem die Programmierer ihre Aufgabe erfüllt haben, bedarf es der 

Entkopplung von Quelltext und Spielinhalt. Dadurch lässt sich zum einen die Produktionszeit 

weiter deutlich kürzen, indem beide Teile parallel entworfen werden. Zum anderen erlaubt dies 

den Austausch von Spielinhalt sowohl zur Entwicklungs- als auch Laufzeit unabhängig von 

dem darunter liegenden Softwaresystem. Das erleichtert sowohl das Testen des entwickelten 

Spielinhalts als auch das Anpassen desselben während des Spielverlaufs, was vor allem bei 

Onlinespielen von Interesse sein kann, bei denen Wartungsarbeiten mit Unannehmlichkeiten 

für den Kunden verbunden sind. Deshalb sollte das Objektmodell, welches eben genau den 

genannten Spielinhalt repräsentiert, dieses in flexibler Weise unterstützen. 


Kapitel 3 

Taxonomie 

Das letzte Ziel aller 

wissenschaftlichen Erkenntnis besteht 

darin, das größtmögliche 

Tatsachengebiet aus der 

kleinstmöglichen Anzahl von 

Axiomen und Hypothesen zu erhellen. 

Albert Einstein 

In diesem Kapitel soll zunächst versucht werden, eine Kategorisierung von Objektmodellen im 

Allgemeinen und letztlich vor allem für Spiele im Speziellen aufzustellen. Eine solche Taxonomie 

kann zum einen hilfreich sein, Systeme nach definierten Aspekten einzuordnen, zum anderen 

soll sie dem Leser vor allem einen Überblick über die Vielfalt der Problemstellung und ein 

klares Bild von dem Begriff „Objektmodell“ bieten sowie die unterschiedlichen Möglichkeiten 

der Implementierung eines solchen aufzeigen. Dabei soll vor allem von der eindimensionalen 

Differenzierung derartiger Systeme nach ihrem Grad der Komponenten- oder Objektorientierung 

Abstand genommen werden [Doherty, 2003] und eine breitere Betrachtung durchgeführt werden. 

Die hierfür benötigten Erkenntnisse ergehen aus der spärlichen Literatur zu diesem Thema sowie 

den Architekturen von Opensource Spieleprojekten. Exemplare beider Gruppen erfahren dann 

im späteren Verlauf ihre Einordnung anhand der aufgestellten Klassifizierung. 

Die zu erarbeitende Kategorisierung wird uns im weiteren Verlauf der Arbeit begleiten und 

vor allem Alternativen für grundlegende Architekturentscheidungen aufzeigen. Zum jetzigen 

Zeitpunkt ist uns keine vergleichbare Untersuchung bekannt. 

Wir beschränken uns hierbei nicht nur auf die Repräsentation der Spielobjekte an sich, sondern 

wollen auch die peripheren Gesichtspunkte einbeziehen, deren Funktionalität, Implementierung 

und Effizienz von eben jenem Kern abhängig sind. Dazu zählen wir zum einen die Kommunikation 

zum Datenabgleich zweier teilnehmender Netzwerkknoten sowie zum anderen die Frage, 

inwiefern ein System zur Laufzeit dynamische Eigenschaften aufweist. Letzteres bestimmt vor 

allem den Grad der Flexibilität und die Einsatzmöglichkeiten desselben.

6 III. Taxonomie 

3.1 Objektstruktur 

Zentral für ein Objektmodell ist selbstverständlich die Art der Repräsentation der Spielobjekte 

sowie ihrer Daten in der Implementation. Nicht erst seit der objektorientierten Programmierung 

gesellen sich hierzu die Typisierung der Objekte sowie die auf diesen auszuführenden Operationen. 

Diese drei Faktoren und die Möglichkeiten zur Anordnung der Objekte in Relation 

zueinander werden im Folgenden beleuchtet. 

Offensichtlich bietet es sich heutzutage an, die objektorientierte Entwicklung heranzuziehen, 

um eine Abbildung der genannten Aspekte auf äquivalente Elemente der Programmiersprache 

vornehmen zu können. Es sei jedoch angemerkt, dass dies kein notwendiger Schritt ist. Eine 

Modellierung der Vorstellung, die wir von Objekten haben, ist auch auf andere Weise möglich, 

wie im Verlauf dieses Kapitels noch deutlich werden wird. Dennoch liegt der Fokus eben auf jener 

Ausprägung der Programmierung, da deren Möglichkeiten die Modellierung eines auf Objekten 

und deren Beziehungen basierenden Systems zum jetzigen Zeitpunkt am besten unterstützen. 

Dafür spricht die breite Akzeptanz dieses Paradigmas in der Softwareentwicklung allgemein, 

aber auch in der Spieleentwicklung im Speziellen. 

Folgende Aspekte werden deshalb betrachtet: 

• Die Modellierung der Daten von Spielobjekten 

• Die Modellierung des Verhaltens von Spielobjekten 

• Die Modellierung der Typisierung oder Klassifizierung von Spielobjekten 

• Die Anordnung der Spielobjekte in Relation zueinander 

3.1.1 Daten 

Die Basis jedes Objekts sowohl in seiner physikalischen oder virtuellen Form als auch seiner 

Repräsentation in einer Programmiersprache sind zweifelsohne die ihm eigenen Daten, seine 

Eigenschaften. Hierbei interessieren vorrangig folgende Fragen: 

• Wie werden die Daten der Spielobjekte im Quelltext modelliert? 

• Wo werden die Daten der Spielobjekte definiert? 

In beide Punkte spielt die Idee des data-driven Design herein. Deshalb soll hier kurz eine Definition 

und Motivation der Methode sowie deren Vorteile gegenüber traditionellen Vorgehensweisen 

gegeben werden. 

Computerspiele unterliegen während ihrer Entwicklung und zumeist auch darüber hinaus stetigen 

Änderungen. Diese beschränken sich üblicherweise nicht auf Anpassungen der visuellen 

Elemente, sondern beziehen auch Arbeiten an der Logik des Spiels und Eigenschaften einzelner 


III. Taxonomie 7 

Spielobjekte ein. Dabei werden solche Anpassungen von Personen durchgeführt, die nicht notwendigerweise 

auch Programmierer sind und dementsprechend nur beschränkte Möglichkeiten 

haben, Arbeiten am Quelltext eines Spiels vorzunehmen. 

Um diese Adaptionen zu vereinfachen, stützt sich die Spieleindustrie daher auf die Idee, dass 

Daten über das Verhalten der Spiele von diesen aus externen Datenquellen eingelesen und zur 

Anwendung gebracht werden [Bilas, 2002; Church, 2002; Doherty, 2003; Duran, 2003; Rabin, 

2000; Riley, 2003], anstatt dass jede spielmechanische Information in einem Teil des Quelltextes 

festgehalten ist. Das bietet folgende Vorteile [Riley, 2003]: 

• Spieldesigner können ohne Programmierkenntnisse Spielinhalt beeinflussen. 

• Jede Änderung am Spielinhalt kann sofort ohne Neukompilierung des Systems evaluiert 

werden. 

• Es braucht weniger Quelltext, was wiederum das Risiko von Fehlern minimiert und die 

Wartung erleichtert. 

• Die Spielentwicklung wird beschleunigt, da der Inhalt eines Spiels bereits unabhängig vom 

eigentlichen Quelltext entworfen werden kann. 

• Es können externe Applikationen genutzt werden, die die Kreation von Spielinhalt von 

der Repräsentation der manipulierten Daten abstrahieren und somit vereinfachen. 

• Die Wiederverwendbarkeit des Systems wird unterstützt, da die eigentliche Logik des 

Spiels nicht im Quelltext kodiert ist. 

• Es bietet sich damit an, Kunden oder Anwendern die Möglichkeit zu geben, das Spiel nach 

ihren Vorstellungen zu verändern (Modding). 

Die Nachteile dieses Konzepts werden in Abhängigkeit der genauen Implementierung in den 

nächsten Abschnitten erläutert. Die traditionelle Herangehensweise, bei der Daten der Spielobjekte 

im Quelltext definiert werden, wird ebenfalls betrachtet. Wie wir sehen werden, hat diese 

Methode ebenso ihre Vorteile. 

3.1.1.1 Modellierung 

In den folgenden Abschnitten werden Methoden vorgestellt, wie die zu einem Spielobjekt gehörenden 

Daten mit demselben verknüpft werden können. Die Möglichkeiten reichen von einer 

streng objektorientierten Modellierung mit Hilfe von Konstrukten der eingesetzten Programmiersprache 

bis hin zu einem System, welches sich nicht mehr auf dieses Paradigma stützt, 

sondern dieses emuliert. 

Jens Pfau · Stephan Mehlhase 7


Objekte als Sprachkonstrukte 

In der objektorientierten Programmierung werden die potentiellen Eigenschaften von Objekten 

über ihre Klassen definiert. Dadurch sind diese Teil des Quelltextes. Mit Hilfe dieser naheliegenden 

Methode können natürlich auch Spielobjekte in der Form modelliert werden, dass für 

jeden Typ von Spielobjekt eine Klasse definiert wird, von der dann wiederum Instanzen kreiert 

werden können, die sich schließlich in den Werten ihrer Eigenschaften unterscheiden. 

Vorteile [Riley, 2003; Duran, 2003]: 

• Es wird weniger Speicher benötigt, da gemeinsame Attribute von Spielobjekten auf die 

Klassenebene verlagert werden können. 

• Typüberprüfungen für die Belegungen der Eigenschaften können auf der Sprachebene in 

effizienter Form durchgeführt werden. 

• Typen von Objekten können durch ihre Klasse identifiziert werden. 

• Die Modellierung erfolgt nach einem gutverstandenen Prinzip. 

Nachteile: 

• Es entsteht eine große Menge Quelltext und somit ein höheres Fehlerrisiko sowie eine 

komplexere Wartung des Systems. 

• Es ist schwierig, nur Teile des Spiels zu laden, da alles fest kompiliert ist. 

• Für jede kleine Änderung muss der Quelltext neu kompiliert werden. 

• Folglich ist es kompliziert, das Spiel zur Laufzeit zu ändern. 

• Typen von Objekten können nur durch ihre Klasse identifiziert werden. 

• Der übersetzte Quelltext ist nicht unbedingt von Menschen lesbar. 

Dynamische Attribute 

Bei dieser Architektur existiert nur eine Klasse, die als einzige Variable eine leere Hashtable 

definiert [Riley, 2003]. Die Instanzen dieser Klasse füllen dann jeweils diese Hashtable mit Zuordnungen 

von Schlüsselwörtern zu Werten, wobei die Werte nicht typisiert sind und die Typen 

folglich zur Laufzeit bestimmt werden müssen. Jede Eigenschaft eines Objekts kann somit über 

das entsprechende Schlüsselwort abgefragt werden. 

Vorteile: 

• Es wird nur eine einzige Klasse benötigt. 



• Das System ist sehr flexibel, da jede Instanz unterschiedlich sein kann. 

• Die Eigenschaften jeder einzelnen Instanz können zur Laufzeit geändert werden. 

Nachteile: 

• Es wird mehr Speicher als bei anderen Verfahren benötigt, da alle Daten auf der Instanzebene 

und keine auf der Klassenebene gehalten werden. 

• Es entstehen zusätzliche Laufzeitkosten dadurch, dass die Typen der Attribute zur Laufzeit 

bestimmt und festgelegt werden müssen. 

• Es kann schwierig sein, den wirklichen Typ eines Objektes herauszufinden. 

• Das System ist durch die fehlende Typisierung fehleranfälliger. 

Dynamische Zustände 

Der Name dieses Modells ist von uns in Anlehnung an obiges System und [Hannah, 2004] 

gewählt worden. Tatsächlich unterscheidet sich dieses nur in einem Detail von den dynamischen 

Attributen: Die Eigenschaften sind nun typisiert. Die Vorteile bleiben unverändert, die Nachteile 

hingegen reduzieren sich damit auf folgende: 

• Es wird mehr Speicher als bei anderen Verfahren benötigt, da alle Daten auf der Instanzebene 

und keine auf der Klassenebene gehalten werden. 

• Es kann schwierig sein, den wirklichen Typ eines Objektes herauszufinden. 

Komponentenmodell 

In den Spielen Thief und Deus Ex des ehemaligen Entwicklers Ion Storm 1 kommt ein alternatives 

System zum Einsatz, welches sich nicht mehr auf die Konstrukte der objektorientierten 

Entwicklung stützt [Church, 2002; Duran, 2003]. Stattdessen basiert dieses auf sogenannten 

Komponenten, die lediglich Container für Paare aus Objekt-IDs und Eigenschaftswerten sind. 

Um zum Beispiel die Farbe eines Objektes zu bestimmen, wird die für die Farb-Eigenschaft 

zuständige Komponente nach der Farbe für die ID des relevanten Objektes befragt. 

Vorteile [Doherty, 2003; Church, 2002; Duran, 2003]: 

• Jede Komponente kann ihre Daten in einer Struktur halten, deren Mechanismen für die 

zugreifenden Subsysteme des Spiels effizient sind. Die für die Physikengine interessanten 

Daten könnten zum Beispiel in einem Container gehalten werden, über dessen Elemente 

effizient iteriert werden kann. 

1 http://de.wikipedia.org/wiki/Ion_Storm 



• Das System verleiht dem data-driven Design Nachdruck. Objekte sind nichts anderes als 

Daten und ihr Verhalten muss daher in Form von Daten definiert sein. 

• Die Struktur der Komponenten als Vektoren von Daten unterstützt den Einsatz von relationalen 

Datenbanken für die Persistenz. 

Nachteile 

• Es ist aufwendig, Objekte aus dem Modell zu entfernen, da in jeder Komponente ein 

entsprechender Eintrag für das relevante Objekt gesucht und dann gelöscht werden muss. 

• Die Elemente der objektorientierten Programmierung können nicht direkt umgesetzt werden, 

da Komponenten orthogonal zu dem Prinzip der Objekte umgesetzt sind. Das heißt, 

dass das Implementieren von Typisierung, Vererbung, etc. in einer objektorientierten Programmiersprache 

weiteren Aufwands bedarf. 

• Zudem bedingt dies eine steilere Lernkurve für Mitarbeiter, die mit diesem Verfahren noch 

nicht vertraut sind. 

• Das gesamte Modell basiert auf dem System der Komponenten. Änderungen an diesem 

beeinflussen große Teile des Quelltextes. 

3.1.1.2 Definition 

Offensichtlich müssen die Daten, die zusammen mit dem Verhalten die Spielobjekte ausmachen, 

an einem Punkt definiert werden. Die zentrale Frage, die im Folgenden behandelt wird, ist, wo 

dies geschieht. Der Ansatz des data-driven Design zeigt hier Möglichkeiten auf, die über die 

traditionelle Methode der sogenannten Hartkodierung der Eigenschaften der Spielobjekte im 

Quelltext hinausgehen. Wir werden hier jedoch zunächst den althergebrachten Weg betrachten, 

um danach auf die Vorteile unterschiedlicher Ausprägungen des data-driven Design einzugehen. 

Dabei hat die Entscheidung über die Art der Modellierung der Daten Einfluss auf die 

Implementierung dieses Aspekts. 

Definition im Quelltext 

Sollen die Eigenschaften von Objekten im Quelltext definiert werden, geschieht dies entweder 

über das Definieren von Klassenvariablen oder über ein entsprechendes Setzen der Variablen 

einer Instanz zum Beispiel über den Konstruktor. Wir gehen davon aus, dass auch die Werte 

der Daten fest im Quelltext stehen. 

Dann ergeben sich folgende Vorteile: 

• Diese Methode ist effizient, da alles hartkodiert ist und keine weiteren Verwaltungsarbeiten 

zum Bestimmen und Setzen der Werte der Variablen anfallen. 

• Es kann zur Laufzeit absolute Typsicherheit für die Eigenschaften beziehungsweise Variablen 

garantiert werden. 



Nachteile: 

• Das System ist sehr unflexibel und kaum wartbar. 

• Jede Datenänderung bedingt ein komplettes Neukompilieren. 

• Das System ist schlecht wiederverwendbar, da alle spielspezifischen Elemente im Quelltext 

verankert sind. 

Definition in Textdateien 

Dies ist die erste einer Reihe von Methoden, die auf dem Ansatz des data-driven Design basieren. 

Die Daten für die Spielobjekte werden vom Spiel aus einfachen Textdateien eingelesen. 

Vorteile [Riley, 2003]: 

• Textdateien sind von Menschen lesbar und daher einfach zu manipulieren. 

• Es entsteht kaum Overhead, da die Daten nur weniger Steuerzeichen bedürfen. 

Nachteile: 

• Das Verwalten von vielen Textdateien kann sehr mühsam sein 

• Textdateien an sich können nicht die Integrität ihrer Daten garantieren. Dies muss alleine 

vom Programm bewerkstelligt werden. 

Definition in Binärdateien 

In Binärdateien sind Daten nicht im Klartext abgelegt, sondern in einem dem jeweiligen Programm 

eigenen binären Format. 

Vorteile: 

• Es entsteht kaum Overhead, da die Daten nur weniger Steuerzeichen bedürfen. 

Nachteile: 

• Die Dateien sind nicht direkt von Menschen lesbar und daher schlecht zu manipulieren. 

• Die Integrität der Daten kann lediglich durch das Programm selber sichergestellt werden. 



Definition in XML Dateien 

XML soll als Standard für das Ablegen strukturierter Daten dienen. Da es mittlerweile in vielen 

Bereichen Anwendung findet, gibt es eine Vielzahl an Werkzeugen und Bibliotheken für die 

gängigen Programmiersprachen zur Manipulation von XML Dateien. 


• Zur Manipulation von XML Dateien stehen ausgereifte Werkzeuge zur Verfügung. 

• XML als Technologie ist direkt abgestimmt auf die Ablage strukturierter Daten. 

• Die Struktur der XML Dateien kann sehr flexibel gestaltet werden. 

• XML bietet inhärent die Unterstützung zur Sicherstellung der Integrität der Daten. 

Nachteile: 

• XML Dateien haben einen hohen Bedarf an Speicherplatz für Verwaltungsdaten. 

[Riley, 2003] spricht von einer schlechten Werkzeugunterstützung für XML, wohingegen wir 

jedoch anderer Meinung sind. Dies lässt sich aber auch darauf zurückführen, dass der Artikel 

bereits drei Jahre alt ist und die Situation sich seitdem geändert hat. Mittlerweile sind zum 

Beispiel sogar zwei Bibliotheken zur Manipulation von XML Dateien im Java Development 

Kit 2 unabhängig voneinander integriert. 

Definition in einer Skriptsprache 

Die Option, die Daten der Spielobjekte in einer Skriptsprache zu definieren, ist sicherlich interessant 

für die Systeme, deren Verhalten ebenfalls in einer Skriptsprache beschrieben ist. Auf 

diesem Weg lassen sich zwei Probleme über die selbe Schnittstelle lösen. Bekannte Skriptsprachen 

für Spiele sind Python 3 , Tcl 4 und insbesondere Lua 5 . 


• Die Methode lässt sich gut in das System integrieren, wenn das Verhalten auch in derselben 

Skriptsprache modelliert wird. 

• Es muss kein eigener Parser geschrieben werden. 

• Skriptsprachen sind sehr dazu geeignet, komplexe Daten zu beschreiben. 

• Die Daten können auch von der Skriptsprache selber sehr einfach manipuliert werden. 

2 http://java.sun.com 

3 http://www.python.org 

4 http://www.tcl.tk 

5 http://www.lua.org 



Nachteile: 

• Wenn keine Werkzeuge für die Spieldesigner bereitgestellt werden, bedarf es deren Einarbeitung 

in die Skriptsprache. 

Definition in einer Relationalen Datenbank 

Relationale Datenbanken stellen trotz des Siegeszuges der Objektorientierung in der Programmierung 

immer noch den bedeutendsten Anteil an Persistenzsystemen für große Datenmengen. 


• Relationale Datenbanken haben weithin unterstützte Standardschnittstellen. 

• Sie bieten ausgezeichnete Fähigkeiten zur Handhabung von konkurrierenden Zugriffen. 

• Sie bieten von Haus aus gute Möglichkeiten für Backups. 

• Sie können problemlos mit sehr großen Datenmengen umgehen. 

• Sie bieten standardisierte und potente Möglichkeiten zur Datenabfrage und -manipulation 

(SQL). 

• Es existieren mächtige Werkzeuge zur Administration und Wartung von Datenbanken 

sowie zur Datenmanipulation. 

Nachteile: 

• Relationale Datenbanken können sehr wartungsintensiv sein. 

• Es werden möglicherweise produktspezifische Bibliotheken, Werkzeuge und Lizenzen gebraucht. 

• Die Daten, die in relationalen Datenbanken gespeichert werden können, unterliegen produktspezifischen 

Einschränkungen. Dies kann die Austauschbarkeit der Datenbank in einem 

System unterbinden, das gegen eine bestimmte Spezifikation entwickelt wurde. 

• Die objektorientierten Daten eines Objektmodells sind nicht unbedingt einfach auf ein 

relationales Schema abzubilden. 

• Auf lokalen Clients oder in Singleplayer-Spielen bedeuten Datenbanken, wenn hauptsächlich 

statischer Inhalt ausgeliefert wird, wohlmöglich einen unnötig großen Aufwand an 

Ressourcen. 



Definition in einer objektorientierten Datenbank 

Objektorientierte Datenbanken haben sich kaum durchgesetzt. Sie seien hier jedoch der Vollständigkeit 

halber erwähnt. Dabei bringen sie in diesem Kontext die gleichen oben genannten 

Vor- und Nachteile mit sich wie die relationalen Datenbanken, mit der Ausnahme, dass es leichter 

fällt, die Daten objektorientierter Systeme auf Schemata dieser Datenbanken abzubilden. 

3.1.2 Verhalten 

Erst ihre Aktivität und Reaktivität erweckt die Spielobjekte zum Leben. Die Modellierung dieses 

Aspektes ist abhängig von der Wahl der Objektrepräsentation, wie sie in dem vorigen Abschnitt 

vorgestellt wurde. Im Folgenden soll aufgezeigt werden, welche Möglichkeiten sich bieten, die 

Beziehung zwischen Spielobjekten und ihrem Verhalten herzustellen. Es interessieren wiederum 

folgende Fragen: 

• Wie wird das Verhalten der Spielobjekte im Quelltext modelliert? 

• Wo wird das Verhalten der Spielobjekte definiert? 


Es soll hier um die Frage gehen, in welcher Form das Verhalten programmiertechnisch mit den 

Spielobjekten in Verbindung gebracht wird. Erst in dem nächsten Abschnitt interessiert, wo das 

Verhalten an sich definiert wird. Drei Ansätze konnten ausgemacht werden, die im Folgenden 

vorgestellt werden. 

als Methoden 

Ein zentrales Prinzip der objektorientierten Entwicklung ist, Daten und das zugehörige Verhalten 

an einem Punkt zusammenzubringen. So können für eine Klasse und damit auch für deren 

Instanzen Methoden definiert werden, die dann mit den objekteigenen Daten arbeiten. Auf diese 

Weise die Logik eines Spiels an die Spielobjekte zu knüpfen, liegt dann nahe, wenn letztere als 

Instanzen von Klassen einer objektorientierten Programmiersprache modelliert sind. 

Vorteile: 

• Dies ist eine naheliegende und somit gut verständliche Umsetzung nach dem Paradigma 

der verwendeten Programmiersprache, sofern objektorientiert. 

• Das Verfahren ist effizient, da das Verhalten direkt an die Daten geknüpft ist, die es nutzt 

und manipuliert. 



Nachteile: 

• Das Verhalten ist fest verknüpft mit den Spielobjekten. Dieses kann während der Entwicklungszeit 

und nach der Auslieferung des Produktes nur schlecht ausgetauscht werden. 

als Komponenten 

Spiele befinden sich in ständiger Veränderung. Auch das Verhalten von Spielobjekten wird zumindest 

während der Entwicklungsphase eines Spiels häufig umdefiniert. Diesem Umstand trägt 

das Komponentenmodell Rechnung [Bilas, 2002]. Spielobjekte bestehen nicht nur aus Daten, sondern 

auch aus sogenannten Komponenten, die ein in sich abgeschlossenes Verhalten definieren, 

zum Beispiel in Form von weiteren Objekten, welche sowohl einen Zustand als auch Methoden 

anbieten können. Jedem Spielobjekt kann eine beliebige Menge an Komponenten zugeordnet 

werden, die natürlich auch noch zur Laufzeit geändert werden kann. Das Modell kann vor allem 

in der Granularität der Komponenten variiert werden [Duran, 2003]. Vorstellbar sind sowohl 

umfassende Komponenten, hinter denen möglicherweise mehrere Objekte stehen oder kleingewichtige, 

die nur eine einzelne ausführbare Aktion repräsentieren [Hannah, 2004]. Dieses System 

steht nicht in Zusammenhang mit dem in Kapitel 3.1.1.1 vorgestellten Komponentenmodell. 

Vorteile: 

• Jedes Spielobjekt kann jedes beliebige Verhalten annehmen, indem ihm die entsprechende 

Komponente zugeordnet wird. 

• Das data-driven Design wird unterstützt. Spieldesigner können mit Hilfe externer Werkzeuge 

Verhalten bestimmten Spielobjekten zuordnen. 

• Weitere Spiellogik kann hinzugefügt werden, ohne dass bestehender Quelltext neu übersetzt 

werden muss. 

Nachteile: 

extern 

• Das Auflösen von Abhängigkeiten zwischen Komponenten kann sich als schwierig herausstellen. 

• Dies ist keine direkte Modellierung mit Hilfe der Elemente der Programmiersprache und 

bedarf daher zusätzlichen Aufwands sowohl in der Entwicklung als auch zur Laufzeit. 

Als letzten Weg haben wir die Option identifiziert, das Verhalten komplett von den zugehörigen 

Objekten abzukoppeln. Dies kann zum Beispiel durch das Anlegen einer Bibliothek von Funktionen 

geschehen, die Spielobjekte als Argumente entgegennehmen, oder durch das Entwurfsmuster 

Command, wodurch der objektorientierten Entwicklung Genüge geleistet wäre [Gamma, 1997]. 



Vorteile: 

• Jedes Spielobjekt kann jedes beliebiges Verhalten annehmen, indem es an die Verhaltenslogik 

übergeben wird. 

• Weitere Spiellogik kann hinzugefügt werden, ohne dass bestehender Quelltext neu übersetzt 

werden muss. 

Nachteile: 

• Dies ist keine direkte Modellierung mit Hilfe der Elemente der Programmiersprache und 

bedarf daher zusätzlichen Aufwands sowohl in der Entwicklung als auch zur Laufzeit. 

• Es bedarf weiterer Logik, um festzulegen, welches Spielobjekt welches Verhalten besitzt. 


Nachdem die Möglichkeiten aufgezeigt wurden, Verhalten mit Daten in Verbindung zu bringen, 

soll untersucht werden, wie ersteres definiert werden kann. 

Quelltext 

Die konventionelle Methode, Verhalten festzulegen, ist, dieses im Quelltext zu beschreiben, zum 

Beispiel in Form von Methoden- oder Funktionskörpern. 

Vorteile: 

• Der Quelltext wird kompiliert, was die Effizienz zur Laufzeit steigert. 

• Ein gewisses Maß an Sicherheit durch die von der Programmiersprache bereitgestellten 

Überprüfungen, zum Beispiel Typüberprüfungen, ist gegeben. 

Nachteile: 

• Die Methode ist unflexibel, da jede Neudefinition von Verhalten eine erneute Kompilierung 

erfordert. 

• Es entsteht mehr Quelltext, also auch mehr Fehlermöglichkeiten. 

Skriptsprache 

Viele moderne Spiele bieten die Möglichkeit, Verhalten von Spielobjekten in Skriptsprachen 

zu definieren [Rabin, 2000]. Das heißt, dass das Spiel in der Lage sein muss, Skriptdateien 



einzulesen, und ein entsprechender Compiler oder Interpreter bereitgestellt werden muss. Als 

Skriptsprachen kommen zum Beispiel Python, Tcl oder Lua zum Einsatz, aber ebenso ist der 

Einsatz von höheren Sprachen wie Java denkbar [Rabin, 2000]. 

Vorteile: 

• Spiellogik muss nicht mehr von den Programmierern bestimmt werden, sondern kann auch 

von den Spieldesignern definiert werden. 

• Dies ist sinnvoll, wenn auch die Daten in der gleichen Skriptsprache abgelegt werden, denn 

dann kann beides über eine einzige Schnittstelle definiert werden. 

• Verhalten kann auch noch zur Laufzeit nachgeladen werden, ohne dass das Projekt neu 

kompiliert werden muss. 

Nachteile: 

• Für den Fall, dass das Verhalten nicht kompiliert, sondern zur Laufzeit interpretiert wird, 

ist dies weniger effizient. 

• Es ist verführerisch, auch komplizierte Spiellogik in Skripte auszulagern. Dies führt jedoch 

zu erhöhten Anforderungen an die Skriptsprache, die wiederum durch deren Compiler oder 

Interpreter sowie weiteren Werkzeugen wie Debuggern unterstützt werden muss. 

• Spieldesigner müssen in der Handhabung der Skriptsprache geschult werden. 

3.1.3 Typen 

Sollen die Spielobjekte nach ihrem Verhalten und ihren Daten in Relation zueinander gestellt 

werden, kommt die Typisierung ins Spiel, die sich in objektorientierten Sprachen in Form von 

Klassen manifestiert. Diese seien im Folgenden als Typen bezeichnet und ihre Instanzen als 

Objekte. Wir betrachten hier folgende drei Aspekte: 

• Wie werden die Typen der Spielobjekte im Quelltext modelliert? 

• Wo werden die Typen der Spielobjekte definiert? 

• In welcher Form lassen sich Typen hierarchisch strukturieren, das heißt das Prinzip der 

Vererbung anwenden? 


Zur Zeit sind zwei unterschiedliche Methoden zur Modellierung von Typen für Spielobjekte in 

Verwendung. Diese sollen hier vorgestellt werden. Ihre Implementierung hängt wiederum von 

den Entscheidungen ab, die zur Modellierung der Daten und des Verhaltens getroffen wurden. 



Typen als Klassen 

Die objektorientierte Programmierung bietet an, Typen als Sprachkonstrukte zu realisieren, 

nämlich als sogenannte Klassen, die für ihre Instanzen sowohl eine gemeinsame Datenbasis als 

auch das Verhalten vordefinieren. Es bleibt offen, wie detailliert die Typen spezifiziert werden. 

Gibt es nur eine einzige Klasse, wie bei der Modellierung der Daten mit Hilfe von dynamischen 

Attributen oder gibt es für jeden denkbaren Typ von Spielobjekt eine korrespondierende Klasse 

mit spezifischen Daten und Verhalten? Es ist auch vorstellbar, jeweils für Kategorien von Spielobjekten 

eine Klasse anzulegen, die konkreten Typen und deren Instanzen jedoch weiterhin 

mit dynamischen Attributen oder Eigenschaften und eigenem Verhalten zu individualisieren. 

Letzteres findet als Kategorieobjekte Erwähnung in der Literatur [Riley, 2003]. 

Vorteile: 

• Da Elemente der Programmiersprache genutzt werden, ist das Verfahren effizienter als 

andere. 

• Diese Methode kann sehr flexibel eingesetzt werden. Der Grad der Typisierung kann für 

verschiedene Spielobjektkategorien unterschiedlich gehalten werden. 

Nachteile: 

• Werden die Typen der Spielobjekte zu genau vorgegeben, wird das System im Fall von 

Änderungen schwerfällig. Dann muss möglicherweise eine ganze Klassenhierarchie aufgebrochen 

werden, um neuen Anforderungen gerecht zu werden. 

• Auch kleinere Änderungen erfordern möglicherweise eine Neukompilierung der gesamten 

Klassenhierarchie. 

Typen als Muster 

Basiert ein System auf Methoden des data-driven Design, ist es nicht unüblich, Typen von 

Spielobjekten als Muster zu definieren [Bilas, 2002]. Diese bestehen dann aus Eigenschaften 

und Verhalten, die in den Formen modelliert sind, wie sie in den vorigen Abschnitten vorgestellt 

wurden. Jedes Spielobjekt wird als Kopie eines solchen Prototyps angelegt oder hält 

einen Verweis auf sein Muster und erbt somit dessen Daten und Verhalten. Dabei ist nicht 

ausgeschlossen, dass eine Instanz die Eigenschaften ihres Musters überschreibt. 

Vorteile: 

• Das System unterstützt das data-driven Design. Typen können von Spieldesignern in externen 

Werkzeugen angelegt werden. 

• Das System ist sehr flexibel. Typen können sehr unterschiedlich sein und Instanzen können 

in jeder Eigenschaft verschieden von ihren Typen sein. 



Nachteile: 

• Enthalten die Spielobjekte Verweise auf ihre Muster, entsteht Overhead, wenn Eigenschaften 

der Objekte abgefragt werden sollen, da in dem Fall eventuell auch die Muster befragt 

werden müssen. 

• Werden die Spielobjekte aus ihren Mustern kopiert, ist es später schwierig, für eine ganze 

Klasse von Objekten Eigenschaften zu ändern, denn diese haben nach ihrer Erstellung 

keine Verbindung mehr zu ihren Mustern. 

• Dieses System umgeht ein zentrales Prinzip der objektorientierten Programmierung, nämlich 

das der Klassen. Dies führt zu höherem Aufwand bei der Entwicklung und zur Laufzeit. 


Typen können auf zweierlei Wegen definiert werden. Zusammen mit der Art der Modellierung 

ergeben sich vier verschiedene Modelle, von denen hier drei in der Praxis gebräuchliche erwähnt 

werden sollen. 

Definition im Quelltext 

Wenn Typen als Klassen modelliert werden, liegt es nahe, diese direkt im Quelltext zu definieren. 

Vorteile: 

• Dies ist effizient, da die Definition hartkodiert und somit kompiliert ist. 

• Es entsteht keine Indirektion bei der Erstellung der Klassen und somit weniger potentielle 

Probleme. 

Nachteile: 

• Jede Typänderung bedingt eine Neukompilierung, wodurch die Methode unflexibel wird. 

Definition mit Hilfe des data-driven Design 

Wenn die Typen data-driven definiert und im Quelltext als Klassen modelliert werden, muss 

ein Werkzeug existieren, das den Quelltext für die Klassen aus ihrer Definition generiert [Riley, 

2003]. Die andere Option ist, Typen als Muster zu modellieren und data-driven zu definieren 

[Bilas, 2002]. Folgende Datenquellen, die bereits in Kapitel 3.1.1.2 vorgestellt wurden, bieten 

sich primär an: 

• Textdateien 



• Binärdateien 

• XML Dateien 

Vorteile: 

• Typen können mit externen Werkzeugen durch Spieldesigner erstellt werden. 

• Typen können zur Laufzeit geändert und nachgeladen werden, ohne dass das gesamte 

System neu kompiliert werden muss. 

Nachteile: 

• Jedes Laden eines Typs erfordert das Lesen von Daten aus externen Quellen wie Dateien 

oder Datenbanken. Dies benötigt Ressourcen wie Speicher und Rechenzeit. 

3.1.3.3 Vererbung 

Die Typisierung von Spielobjekten ist der erste Schritt; die Vererbung von Typen zu erlauben 

und damit Hierarchien derselben zu ermöglichen, ist der zweite. Sind Typen als Klassen modelliert, 

werden alle Aspekte bereits von der Programmiersprache bereitgestellt. Wenn Typen 

hingegen als Muster modelliert sind, bedarf es einer proprietären Nachbildung dieses Prinzips. 

Im Folgenden wird untersucht, welche Konzepte der Vererbung sich anbieten und welche Komponenten 

der Typen für die Vererbung geeignet sind. 

Konzept der Vererbung 

In allen objektorientierten Programmiersprachen ist die Einfachvererbung umgesetzt, bei der 

jede Klasse maximal eine Vaterklasse hat. In C++ zum Beispiel wird auch Mehrfachvererbung 

unterstützt. Dies führt allerdings zu dem Problem von Mehrdeutigkeiten, wenn zwei Vaterklassen 

einer Klasse die gleiche Variable oder Methode definieren [Stroustrup, 2000]. Es ist 

abzuwiegen, ob der Entwicklungs- und Verwaltungsaufwand zur Laufzeit eine Umsetzung der 

Mehrfachvererbung in einem Objektmodell rechtfertigen. 

Durch die Einfachvererbung entsteht in der üblichen Umsetzung, bei der jeder Typ mindestens 

von einem durch das System vorgegebenen Ausgangstyp erbt, ein gewurzelter Baum. In diesem 

repräsentiert jeder Knoten einen Typ und jede Kante einen Vererbungsschritt. Die Mehrfachvererbung 

führt zu einem gerichteten Graphen, der mehrere „Wurzeln“ hat und bei dem jeder 

Knoten mehrere Väter haben kann. Für beide Strukturen lassen sich allerdings Blätter identifizieren, 

die dann die Enden ihrer Vererbungslinie kennzeichnen. 



Gegenstand der Vererbung 

Da wir bisher Spielobjekte als Komposition von Daten und Verhalten betrachtet haben, bieten 

sich diese als Gegenstände der Vererbung an; das heißt, ein Typ, der von einem anderen 

erbt, übernimmt dessen Daten und/oder Verhalten. Eine Instanz dieses Typs ist dann auch 

gleichzeitig eine Instanz des Vatertyps. 

Im Fall der Typen als Muster ist zu entscheiden, ob nur die Typen an den Blättern der Hierarchie 

instanziierbar sein sollen. Damit wären zur Laufzeit die inneren Knoten des Baumes nicht mehr 

interessant und es wäre denkbar und sinnvoll, dann a priori von der Wurzel des Baumes an 

die Eigenschaften der Typen in deren Kinder zu kopieren, so dass diese bereits direkt Daten 

und Verhalten all ihrer Vorfahren enthielten. Die Typen, die keine Blätter der Hierarchie sind, 

könnten für den weiteren Verlauf verworfen werden, da von ihnen nach Annahme keine Instanzen 

erstellt werden könnten. 

Das verhindert, dass bei Zugriffen auf Eigenschaften der Objekte möglicherweise der Typ dieses 

Objekts sowie alle seine Vorfahren nach dieser Eigenschaft befragt werden müssten, um diese 

ausfindig zu machen. Zudem erspart dies Speicherplatz, da die inneren Knoten der Hierarchie 

nicht vorgehalten werden müssen; es verhindert aber auch, dass während der Laufzeit Eigenschaften 

der Typen an den inneren Knoten so geändert werden können, dass sich auch ihre 

Kinder und damit deren Instanzen ändern [Bilas, 2002]. Letzteres ist vor allem zur Entwicklung 

interessant, wenn Typen zu Testzwecken verändert werden sollen, ohne dass das Projekt neu 

kompiliert werden muss. 

3.1.4 Objektordnung 

Sind die Spielobjekte erst einmal erstellt, muss ihre Anordnung zueinander bestimmt werden. 

Hier beziehen wir uns ausschließlich auf die Komposition als Beziehung zwischen Objekten. Andere 

Arten von Relationen wie die Assoziation als Modellierung der Verwendung eines Objektes 

durch ein anderes sind zu dynamisch und situationsabhängig, als dass aus ihnen eine Struktur 

gewonnen werden könnte. 

Jedes Subsystem eines Spiels bringt seine eigenen Anforderungen an den Container der Spielobjekte 

mit. Ein Physikmodul zum Beispiel wird nur Wert darauf legen, dass es schnell über 

alle aktuell im Szenegraph relevanten Objekte iterieren kann, während andere Teile der Spiellogik 

darauf angewiesen sein könnten, effizient die Spielobjekte bestimmen zu können, die einem 

anderen in irgendeiner logischen Relation zugeordnet sind. Diesen Ansprüchen muss das Objektsystem 

gerecht werden. Wir konnten drei mögliche Modellierungen ausfindig machen: 

• keine Anordnung der Objekte zueinander 

• hierarchische Anordnung der Objekte zueinander 

• Gruppierung von Objekten 



Ersteres beschreibt ein Modell, in dem zwischen zwei Spielobjekten keine direkte Kompositionsbeziehung 

vorhanden ist. 

Zweiteres repräsentiert ein System, in dem Spielobjekte wiederum andere Spielobjekte enthalten 

können. Es entsteht eine Baumstruktur [Hannah, 2004] oder ein Graph. Letztere Option konnten 

wir wahrscheinlich wegen der einhergehenden Komplexität nicht ausfindig machen. Ersteres 

hingegen bietet den Vorteil einer zusätzlichen logischen Strukturierung, die es erlaubt, effizient 

für eine Operation relevante Teilmengen ausfindig zu machen und auf diesen zu arbeiten. Dabei 

ist es einfach modellierbar, dass Operationen, die auf ein Spielobjekt angewendet werden, auch 

für dessen Kinder gültig sind. Eine strukturierte Anordnung der Objekte bringt allerdings auch 

immer einen Verwaltungsaufwand und einen bestimmten Zugriffsmechanismus mit sich, denn 

auf eine Baumstruktur wird anders zugegriffen als zum Beispiel auf eine Liste. 

Mit Hilfe der Gruppierung können Teilmengen der Spielobjekte in Hinblick auf bestimmte Aufgaben 

zusammengefasst werden. So ist es denkbar, jeweils die zur Zeit für den Szenegraphen 

relevanten Objekte in einer Gruppe zu halten oder solche Objekte zu gruppieren, die hinsichtlich 

der Kommunikation mit anderen Teilnehmern betreffend gleiche Eigenschaften aufweisen 

[Griwodz, 2002]. 

3.2 Dynamik zur Laufzeit 

Eine der zentralen Fragen an ein Objektmodell ist, wie wandlungsfähig es zur Laufzeit ist. Dadurch 

kann sich entscheiden, ob ein System für einen bestimmten Einsatzzweck geeignet ist oder 

nicht. Gerade Betreiber von Onlinespielen können es sich nur in größeren Zeitabständen leisten, 

ihre Server für Wartungsarbeiten herunterzufahren. In Hinblick auf die vorigen Untersuchungen 

interessieren folgende Fragen: 

• Kann das System zur Laufzeit Spielobjekte nachladen? 

• Kann das System zur Laufzeit Verhalten nachladen? 

• Kann das System zur Laufzeit Typen nachladen? 

• Können Typen zur Laufzeit geändert werden, so dass dies Auswirkungen auf bereits geladene 

Spielobjekte hat? 

Jedes denkbare komplexere Spiel ist auf die erste dieser Anforderungen angewiesen, es sei denn, 

ein komplettes Spiel wird ab seinem Start im Speicher gehalten. Das ist aber für die wenigsten 

Spiele vertretbar. 

Gerade die drei letzten Fragen betreffen die Zeit der Entwicklung eines Spiels, in der oft Spielelemente 

zum Test ausgetauscht werden müssen, sowie eben jene Onlinespiele, die auch im 

Produktionsbetrieb die Möglichkeiten für Veränderungen offen halten müssen. Wie wir bisher 

gesehen haben, wird Flexibilität jedoch stets mit Kosten an Speicherplatz oder Rechenzeit erkauft. 

Es gilt also für jedes Produkt abzuwiegen, welche Anforderungen wirklich nötig sind. 



3.3 Kommunikation 

Zunächst einmal erscheint dieser Gesichtspunkt nicht relevant für die Ausarbeitung eines Objektmodells, 

allerdings kann letzteres im Falle des Einsatzes in einem Multiplayerspiel durch 

eine geeignete Implementierung das Design einer performanten Netzwerkschnittstelle fördern. 

Und genau dies ist eine der zentralen Anforderungen an jedes Onlinespiel. Um die Notwendigkeit 

der Betrachtung dieses Punktes zu veranschaulichen, werden wir die für diese Arbeit wichtigen 

Aspekte und ihre Auswirkungen erörtern. Diese sind im Einzelnen: 

• Die Frage des Startpunktes jeder Kommunikation zur Initiierung eines Datenabgleichs 

• Die Frage, in welcher Form Änderungen übertragen werden 

• Kompression des Datenverkehrs 

• Unterstützung der Effizienz des Datenverkehrs durch Quality of Service Dienste 

3.3.1 Initiative 

Wenn zwei Partner miteinander kommunizieren wollen, bedarf es einer Methode zur Iniitierung 

des Austauschs neuer Informationen. In der Entwicklung verteilter Systeme existieren zu diesem 

Zweck prinzipiell zwei Wege [Tanenbaum u. van Steen, 2002]. 

3.3.1.1 Polling 

Beim Polling fragt ein an bestimmten Informationen interessierter Client regelmäßig bei seinem 

Kommunikationspartner an, ob Neuigkeiten vorliegen. Dies passiert zum Beispiel in jedem das 

POP-Protokoll 6 unterstützenden E-Mail Client, der den Server erst nach neuen E-Mails befragen 

muss, um Kenntnis von diesen zu erlangen. 

Der Nachteil ist offensichtlich: Es entsteht auch Kommunikationsverkehr, wenn gar keine neuen 

Informationen ausgetauscht werden müssen. Der Vorteil ist, dass kein Verwaltungsaufwand anfällt, 

um zu bestimmen, welche Informationen für welchen Kommunikationspartner interessant 

sind, da diese explizit nach bestimmten Änderungen fragen können. 

3.3.1.2 Publish/Subscribe 

Dieses Prinzip basiert darauf, dass Teilnehmer ihre Entitäten, die Änderungen unterliegen, 

bekannt geben und interessierte Kommunikationsteilnehmer diese abonnieren, um neue Informationen 

direkt zu erhalten. 

6 http://de.wikipedia.org/wiki/Post_Office_Protocol 



Zwar reduziert das den Kommunikationsverkehr, da nur Informationen versendet werden, wenn 

neue vorliegen, aber es benötigt einen gewissen Aufwand zur Verwaltung der Abonnenten. 

3.3.2 Änderungsübermittlung 

Eine entscheidene Rolle spielt die Frage, welche Informationen zwischen Kommunikationspartnern 

übertragen werden. Für die Änderungen am Objektmodell existieren dafür zwei verschiedene 

Möglichkeiten. 

3.3.2.1 Delta Updates 

Bei den sogenannten Delta Updates werden nur die bloßen Änderungen des Spielzustandes seit 

dem letzten Abgleich übertragen. In Bezug auf die Objektstruktur können das nur die Spielobjekte 

sein, die sich geändert haben, in Bezug auf Spielobjekte sind dies nur die Felder des 

Objektes, die sich tatsächlich verändert haben. Bei dieser Methode werden weniger Informationen 

übertragen als dies bei einer Übermittlung des gesamten Objektbestandes respektive 

kompletter Objekte der Fall wäre. Auf der anderen Seite benötigt ein solcher Mechanismus Rechenzeit, 

um zu evaluieren, welche Felder geändert wurden, sowie für die Logik zum Erstellen 

und Anwenden der Updates [Ludwig, 2005]. 

3.3.2.2 Aktionen 

Eine andere Möglichkeit ist, die Aktionen, die die Objektstruktur verändern, zu übertragen. 

Dies verringert die zu übertragende Menge von Daten noch weiter. Ein zusätzlicher Verwaltungsaufwand 

entfällt bei dieser Methode, einzig die Serialisierung der ausgeführten Aktionen 

fällt an. Diese wird bei geeigneter Implementierung aber nicht weiter ins Gewicht fallen. Der 

Nachteil dieses Verfahrens ist, dass divergierende Spielzustände entstehen können, wenn keine 

weiteren regelmäßigen Zustandssynchronisierungen stattfinden. Zudem basiert diese Vorgehensweise 

auf der einschränkenden Annahme, dass nur Aktionen, die auch versendbar sind, Einfluss 

auf die Objekte nehmen. 

3.3.3 Kompression 

Um den Netzwerkverkehr zu verringern, können Daten komprimiert werden. Hier bieten sich 

zwei verschiedene Möglichkeiten, die sich nicht zwangsweise gegenseitig ausschließen. 

3.3.3.1 Semantik-abhängig 

Die erste Möglichkeit ist eine Kompression, die unwichtige Daten, die nicht zwingend übertragen 

werden müssen, herausfiltert. Das ist in dem Sinne semantik-äbhängig, als dass es von 



der Modellierung abhängt und das Spielsystem selbst zu entscheiden hat, welche Daten einer 

Übermittlung bedürfen und welche nicht. Vorteilhaft ist die Reduzierung des Netzwerkverkehrs 

auf das wirklich Notwendige. Nachteilig wirkt sich aus, dass eine weitere Logik zur Filterung 

benötigt wird. Dies geht zu Lasten der Rechenzeit. 

3.3.3.2 Semantik-unabhängig 

Die andere Möglichkeit, Daten zu komprimieren, ist, auf bereits existierende, allgemeingültige 

Verfahren wie GZIP 7 oder BZIP2 8 zurückzugreifen, die nicht vom Inhalt der Informationen 

abhängen. Der Vorteil ist, dass keine zusätzliche Logik anfällt und die Implementierungen der 

meisten Kompressionsbibliotheken ausgiebig getestet sind. Unvorteilhaft ist, dass bei kleinen 

Datenmengen der Rechenaufwand für eine Kompression zu hoch sein kann. Dieses kann aber 

durch die Konkatenation mehrerer Daten kompensiert werden. 

3.3.4 Quality of Service (QoS) 

Ein weiterer wichtiger Faktor bei der Kommunikation ist die Steuerung des anfallenden Netzwerkverkehrs, 

so dass gewisse Qualitätsmerkmale für die Teilnehmer erreicht werden. Die Möglichkeiten 

lassen sich auch hier in zwei Kategorien einteilen. 

3.3.4.1 Semantik-abhängig 

Die erste Methode ergibt sich aus der Modellierung der Objekte. Das Spielsystem selbst verwaltet 

die Priorität einzelner Nachrichten oder Teilnehmer. Beispielsweise kann das Abfeuern 

einer Waffe als wichtiger eingestuft werden als die zeitgleiche Chatnachricht. Dementsprechend 

kann das System die zu versendenen Daten in einer nach ihrer Priorität sortierten Liste halten 

und abarbeiten. Diese Implementierung basiert darauf, dass die Entwickler bewusst bestimmte 

Informationen priorisieren können. Allerdings bedeutet dies natürlich einen weiteren Verwaltungsaufwand. 

3.3.4.2 Semantik-unabhängig 

Die andere Möglichkeit, Netzwerkverkehr zu steuern, kann über die verschiedenen, in Netzwerkprotokollen 

verankerten QoS Mechanismen geschehen. Vorteil ist hierbei, dass der Rechenaufwand 

entfällt. Der Nachteil hingegen ist ganz klar, dass die Netzwerkprotokolle QoS zwar 

theoretisch unterstützen, in der Praxis dies aber von der Umsetzung durch die Netzbetreiber 

abhängig ist [Tanenbaum, 2002; Mühlhäuser, 2005]. 

7 http://www.gzip.org 

8 http://www.bzip.org 



3.4 Übersicht 

Die erarbeitete Taxonomie wird der Übersicht halber noch einmal in einer Baumstruktur dargestellt. 



Objektstruktur 

Daten 

Modellierung 

Objekte als Sprachkonstrukte 

Dynamische Attribute 



Definition 

Quelltext 

Textdateien 

Binärdateien 

XML Dateien 

Skriptsprache 

Datenbanken 

Verhalten 

Modellierung 

Methoden 

Komponenten 

extern 

Definition 

Quelltext 

Skriptsprache 

Typen 

Modellierung 

Klassen 

Muster 

Definition 

Quelltext 

data-driven 

Vererbung 

Konzept 

Einfach 

Mehrfach 

Gegenstand 

Daten 

Verhalten 

Objektordnung 

Keine 

Hierarchische Ordnung 

Logische Gruppierung 

Abbildung 3.1: Baumansicht der Taxonomie (Objektstruktur) 



Dynamik zur Laufzeit 

Typen nachladbar 

Objekte nachladbar 

Verhalten nachladbar 

Typen veränderbar 

Kommunikation 

Initiative 

Polling 

Publish/Subscribe 

Änderungsübermittlung 

Delta Updates 

Aktionen 

Kompression 

Semantik-abhängig 

Semantik-unabhängig 

Quality of Service 

Semantik-abhängig 


Abbildung 3.2: Baumansicht der Taxonomie (Dynamik) 

Abbildung 3.3: Baumansicht der Taxonomie (Kommunikation) 


Kapitel 4 

Anforderungen 

Das Problem kennen ist wichtiger, als 

die Lösung zu finden, denn die genaue 

Darstellung des Problems führt 

automatisch zur richtigen Lösung. 

Albert Einstein 

Im Folgenden sollen die funktionalen und nicht-funktionalen Vorraussetzungen des zu entwickelnden 

Objektmodells dargelegt werden. Diese ergehen zum einen aus der Aufgabenstellung 

und zum anderen aus den praktischen Anforderungen der Spieleentwickler. Dabei wird vor allem 

Rücksicht darauf genommen, dass der endgültige Einsatzzweck des Systems offen gehalten und 

das Framework, von dem ein Subsystem das zu entwickelnde Objektmodell sein wird, in unterschiedlichen 

Projekten einsetzbar sein soll. Dass die geplante Verwendung jedoch hauptsächlich 

im Bereich der Multiplayer-Spiele angesiedelt ist, schafft natürlich erweiterte Bedingungen. Darüber 

hinaus unterliegen alle modernen Softwaresysteme, zu denen sich sicher auch Spiele zählen 

lassen, einer gewissen Grundmenge an Anforderungen, die ebenfalls genannt werden sollen. 

4.1 Darstellung der Objektstruktur 

Die zentrale Aufgabe eines Objektmodells ist eben die Verwaltung der Spielobjekte. Dazu müssen 

diese selber sowie ihre Beziehungen in geeigneter Weise modelliert sein. Die Möglichkeiten dazu 

wurden in Kapitel 3 dargestellt. 

Dieses System soll möglichst flexibel sein, um unterschiedlichsten Anforderungen gerecht werden 

zu können und dennoch einen effizienten Zugriff auf einzelne Objekte oder abgeschlossene 

Teilmengen zu ermöglichen. Von Interesse sind hierbei Einfüge- sowie Lösch- und Änderungsoperationen 

auf der Objektstruktur. Natürlich müssen diese auch über Netzwerkgrenzen hinweg 

eindeutig sein. 

Letztlich erfüllen Spielobjekte ihre Daseinsberechtigung erst dann, wenn auf ihnen Operationen 

ausgeführt werden können. Dies muss von dem System in leicht zu konfigurierbarer Art und 

Weise angeboten werden.

30 IV. Anforderungen 

4.2 Unabhängigkeit des Systems vom Spieldesign 

Bei der Spieleentwicklung kommt es auf das schnelle Umsetzen von Inhalt durch Projektmitglieder, 

die keine oder kaum Erfahrungen mit Programmiersprachen haben, an. Deren Arbeit 

aber unterliegt während des Projektes einer andauernden Entwicklung und häufigen Tests. Eine 

stetige Neukompilierung der gesamten Codebasis ist aber nicht akzeptabel. 

Deswegen geschieht die Spezifikation von Entitäten über externe Datencontainer. Ein solcher 

als data-driven bezeichneter Ansatz, wie er in Kapitel 3.1 eingeführt wurde, erlaubt den Einsatz 

unabhängiger Werkzeuge zur Gestaltung des Spielinhalts und die mühelose Anpassung des 

Spielverhaltens. 

4.3 Persistenz 

Jedes Spiel benötigt eine Möglichkeit, seinen aktuellen Zustand persistent zu machen. Dies 

kann zum Beispiel durch eine Datenbank, aber auch einfach mit Hilfe von Dateien realisiert 

werden. Um die Austauschbarkeit dieser Wege zu ermöglichen, braucht es einer einheitlichen 

Schnittstelle, deren Realisierungen an spezifische Anforderungen angepasst sind. 

4.4 Performanz 

Immer noch ist die Netzwerkschnittstelle einer der engsten Flaschenhälse beim Einsatz von 

Multiplayer-Spielen. Dies betrifft sowohl die Latenz bei der Kommunikation zwischen zwei 

Netzwerkknoten als auch die genutzte Bandbreite. Während ersteres heute zwar das größere 

Problem darstellt, aber vornehmlich durch die Netzwerkarchitektur des Spiels bestimmt und 

letztlich durch physikalische Gesetze begrenzt ist, lässt sich zweiteres hingegen in begrenztem 

Maß auch von anderen Subsystemen beeinflussen. Zur Unterstützung von Nutzern mit geringerer 

Bandbreite ist das Bereitstellen der Objekte oder Teilen derselben zur Versendung über das 

Netzwerk also kritisch, denn liefert dies doch die Basis für jede weitere Optimierung beziehungsweise 

Reduzierung des Datenstroms. Geeignete Mechanismen wie die mögliche Priorisierung 

einzelner Nachrichten sollen hier Abhilfe schaffen. Schließlich bleibt es jedoch anderen Arbeiten 

vorbehalten, den Netzwerkstrom zu steuern. Gleichwohl soll eine Schnittstelle zwischen Datenstruktur 

und Netzwerkschicht angeboten werden, die in flexibler Weise an unterschiedliche 

Einsatzszenarios angepasst werden kann. 

Ebenso bedingt die mögliche Verwendung in Echtzeit-Spielen eine gewisse Leistungsfähigkeit in 

Hinblick auf die Reaktivität. Spieler werden keine erkennbare Verzögerung zwischen Eingabe 

und Ausführung einer Aktion dulden. Dies wird nicht nur durch die Netzwerkschicht bestimmt, 

sondern auch durch weitere Teile des Systems. 


IV. Anforderungen 31 

4.5 Erweiterbarkeit und Wiederverwendbarkeit 

Um das Produkt für Erweiterungen offen zu halten und damit die Anpassung an geänderte 

Anforderungen zu vereinfachen, soll auf einen modularen Aufbau geachtet werden. Jedes Subsystem 

soll eine hohe Kohäsion aufweisen, das Gesamtsystem hingegen durch lose Kopplung 

den Austausch von Komponenten vereinfachen. Eine ausführliche Dokumentation und einfache 

Struktur soll zudem die Erlernbarkeit des Systems verbessern. 

4.6 Abgrenzung und Einschränkung der Aufgabe 

Diese Arbeit ist Teil einer akademischen Studie. Ihr primäres Ziel ist nicht, ein Produktivsystem 

zu entwickeln, sondern Möglichkeiten auszuloten und eine Referenzimplementierung zu liefern, 

die als Ausgangspunkt für weitere Untersuchungen dienen kann. Es wird zwar auf eine angemessene 

Leistungsfähigkeit geachtet, diese aber nicht auf Kosten des leichten Verständnisses und 

der Erweiterbarkeit des Systems umgesetzt. Auch kann in der beschränkten Zeit nicht auf das 

Problem der Sicherheit eingegangen werden, welches bei Spielsystemen vor allem in Hinsicht auf 

das Cheaten von Belang ist. Für Schnittstellen an der Peripherie zu anderen Subsystemen einer 

Spielearchitektur werden nicht unbedingt Implementierungen geliefert, da dies den Rahmen 

sprengen würde. 


Kapitel 5 

Bestehende Systeme 

The important thing in science is not 

so much to obtain new facts as to 

discover new ways of thinking about 

them. 

Sir William Bragg 

Nachdem eine Taxonomie aufgestellt und die Anforderungen identifiziert wurden, sollen im Folgenden 

bestehende Systeme nach ersterer kategorisiert und gegen zweitere geprüft werden. Dies 

dient dazu, eine Bestandsaufnahme der Marktsituation anzudeuten. Da eine Vielzahl sehr spezifischer 

Ansätze existiert, kann hier nur auf eine möglichst repräsentative Teilmenge derselben 

eingegangen werden. Dazu zählen zum einen Opensource Spiele Frameworks, aber auch Architekturbeschreibungen 

kommerzieller Produkte. Gerade letztere erarbeiten allgemeingültigere 

Konzepte aus ihren spezifischen Lösungen heraus, mangeln aber an Detail und begleitendem 

Quelltext. Denselben bieten Opensource Projekte, die aber häufig kaum Dokumentation zur 

Verfügung stellen und lediglich proprietäre Ansätze implementieren, die nur in dem gegebenen 

Umfeld brauchbar sind. 

5.1 Dungeon Siege 

Das folgende, von Scott Bilas entworfene Objektmodell ist Teil des im Jahre 2002 veröffentlichten 

Spiels Dungeon Siege [Bilas, 2002]. Dies ist ein Fantasy-Rollenspiel mit Action-Elementen, 

welches sowohl einen Singleplayer- als auch einen Multiplayer-Modus unterstützt. Mit Hilfe eines 

Editors lässt sich das Spiel nach den eigenen Wünschen anpassen, was die Entwicklung 

zahlreicher Modifikationen ermöglicht hat. 

5.1.1 Systembeschreibung 

Dieses Modell basiert auf sogenannten Komponenten, die für sich jeweils ein eigenes, abgeschlossenes 

Verhalten definieren (Abbildung 5.1). Komponenten werden nach dem Baukastenprinzip 

zu Spielobjekten zusammengesetzt, die weiter keine eigenen Daten oder Verhalten umfassen. Jede 

Komponente ist entweder in der in diesem Produkt verwendeten Programmiersprache C++

V. Bestehende Systeme 33 

oder einer eigens für das Spiel entwickelten Skriptsprache implementiert. Beispielhaft seien 

die C++-Komponenten Actor, Conversation, Inventory, Physics sowie die Skriptkomponenten 

spell_fire, water_effects und cmd_camera_move genannt. Ein Spielobjekt, das die 

Physics-Komponente enthält, würde damit das entsprechende Verhalten annehmen, um von 

der Physikengine angesteuert zu werden. 

wirdersteltmitHilfevon 

Komponente «interface» SkriptKomponente 

C+Komponente 

Spielobjekt Muster 

0.*korespondieren Datenkomponente 

spezifiziert 0.* 

Tabelenspezifikation basiertauf 

enthältInstanzenvon 0.* FeldNameTypStandardwert 

Abbildung 5.1: Skizze des Dungeon Siege Objektmodells 

0.* 

Über Spezifikationsdateien respektive Metainformationen definieren C++- sowie Skriptkomponenten 

ihre Abhängigkeit von anderen Komponenten sowie ihre Datenfelder und deren Typen. 

Ein solches Datenschema wird Tabellenspezifikation genannt. 

Jedes Spielobjekt ist eine Instanz eines Musters, aus dem es durch Kopie gewonnen wird. Die 

Muster stehen in einer Hierarchie der Einfachvererbung und enthalten jeweils sogenannte Datenkomponenten. 

Diese definieren Daten gemäß einer Tabellenspezifikation für die korrespondierende 

Komponente. Dabei kann ein Muster Informationen der Datenkomponenten seines Vatermusters 

überschreiben, indem es nur seine Änderungen vorhält, sowie neue Datenkomponenten 

hinzufügen. Wenn ein Spielobjekt instanziiert werden soll, werden die von ihm und seinem 

Muster spezifizierten Komponenten erstellt und durch die Datenkomponenten des Musters mit 


34 V. Bestehende Systeme 

Informationen gefüllt, wobei Daten der Instanzdefinition die der Musterdefinition überschreiben. 

5.1.2 Einordnung 

Bei der Einordnung in die Taxonomie ist festzustellen, dass Spielobjekte keine eigenen Daten 

enthalten, sondern lediglich die Komponenten, mit deren Hilfe das Verhalten modelliert ist, 

einen Zustand besitzen. Sowohl die Komponentendefinition als auch die Definition der Typen 

als Muster und der Spielobjekte an sich geschieht data-driven in Textdateien nach einem proprietären 

Format. 

Es wird zwar keine explizite Aussage darüber getätigt, aber theoretisch ließen sich mit diesem 

System Objekte zur Laufzeit aus weiteren Definitionsdateien nachladen. Ebenso können 

zur Laufzeit bestehende Skripte geändert sowie neue hinzugefügt werden, die dann von weiteren, 

nachzuladenden Objekten als Komponenten enthalten werden können. Da die gesamte 

Typhierarchie vorgehalten wird und jeder Typ nur die Änderungen gegenüber seinem Vorgänger 

speichert, können zur Laufzeit Typen geändert und weitere geladen werden. Sofern die Spielobjekte 

Referenzen auf ihren Typ halten und ebenfalls nur die Differenzen ihrer Daten zu denen 

ihres Typs speichern, würde sich damit die Änderung eines Typs auch auf dessen Instanzen 

auswirken. 

Zu der Kommunikation oder die Anordnung der Objekte zueinander betreffenden Fragen wird 

keine Aussage gemacht. 

Eine Übersicht über die Einordnung in die Taxonomie erkennt man auf Abbildung 5.2 

5.1.3 Evaluation 

Dieses Modell zieht seine Vorteile insbesondere daraus, dass alle Elemente data-driven definiert 

werden können. Verhalten wird unter anderem in Skriptdateien abgelegt, Muster und ihre Instanzen 

in Textdateien. Dadurch, dass die Definition von Objekttypen nicht durch eine statische 

Vererbungshierarchie erfolgt, sondern durch das Kombinieren von unabhängigen Komponenten, 

lassen sich beliebig unterschiedliche Spielobjekte anlegen. Leistungskritische Komponenten können 

in der verwendeten Programmiersprache entwickelt werden, solche, die häufigen Änderungen 

während der Entwicklung unterliegen, in der Skriptsprache. 

Vor allem zur Entwicklung ist es von Vorteil, dass Typen, Spielobjekte und Verhalten, abgesehen 

von den C++-Komponenten, zur Laufzeit ohne Neukompilierung des Systems ausgetauscht 

werden könnten. Im Fall der Typen hat dies aber den Nachteil einer größeren Speicherbelegung, 

weil die inneren Knoten der Hierarchie nicht verworfen werden können. Zudem bedarf es einer 

längeren Zeit, für ein Objekt ein Datum festzustellen, wenn dazu der Typ des Objekts und 

dessen Vorfahren in der Hierarchie befragt werden müssen. 

Mit Hilfe entsprechender Entwicklungswerkzeuge, die auf Grund des Baukastenprinzips des 

Systems einfach zu entwerfen sind, können somit sowohl Spieldesigner als auch Endanwender 

äußerst flexibel Spielinhalt nach ihren Wünschen formen. All dies fördert die Erweiterbarkeit 



Taxonomie 


Daten 

Modellierung 


Definition 

Textdateien 

Verhalten 

Modellierung 


Definition 

Quelltext 

Skriptsprache 

Typen 

Modellierung 

Muster 

Definition 

data-driven 

Vererbung 

Konzept 

Einfach 

Gegenstand 

Verhalten 

Objektordnung 


Kommunikation 

Abbildung 5.2: Einordnung des von Dungeon Siege verwendeten Systems in die Taxonomie 

des Systems. Es ist sogar vorstellbar, dass Komponenten, die unabhängig von der Logik des 

spezifischen Spiels entworfen wurden, in anderen Produkten gleicher Kategorie wiederverwendet 

werden können. Dies betrifft zum Beispiel die Grafikroutinen oder die Physikengine und 

Künstliche Intelligenz. Abgesehen davon ist das System an sich auf jeden Fall wiederverwendbar 

in anderen Projekten, da alle Spiellogik nur in den Komponenten und nicht dem Kernsystem 

definiert ist. 

Gemessen an den im vorigen Kapitel gegebenen Anforderungen liegen die Nachteile vor allem 

darin, dass sowohl eine eigene Skriptsprache als auch ein eigenes Format zur Definition der 

Muster und Instanzen verwendet wird. Letzteres bedingt die Implementierung von Formatüberprüfungen 

im Quelltext, was beim Einsatz von XML bereits durch vorhandene Bibliotheken 

durchgeführt werden könnte. 

In der gegebenen Implementierung ist ein Austauschen der Skriptsprache nicht möglich, da das 

System beim Erstellen der Tabellenspezifikationen für die Skriptkomponenten auf entsprechende 

Metainformationen aus den Skripten angewiesen ist. Bei einer eigenen Umsetzung des Ansatzes 

würde diese Einschränkung aber schon durch das Auslagern der Metainformationen in externe 

Dateien aufgehoben werden können. 

Der größte Mangel in diesem Kontext sind jedoch die fehlenden Aussagen über die Verwaltung 



und Anordnung der Spielobjekte sowie Möglichkeiten, den Zustand des Systems persistent zu 

machen. Auch die Kommunikation der Objekte mit weiteren Komponenten des Systems sowie 

der Synchronisierung mit anderen Teilnehmern bedarf eines eigenen Entwurfs. 

5.2 Thief und Deus Ex 

In den Spielen Thief und Deus Ex [Church, 2002; Duran, 2003; Doherty, 2003] werden die 

Spielobjekte mit Hilfe von Komponenten emuliert, wie in Kapitel 3.1.1.1 bereits vorgestellt. 

Deshalb soll hier keine erneute Beschreibung der Datenmodellierung gegeben werden. Es ist 

wichtig, dass der Begriff „Komponenten“ hier anders gebraucht wird als in der Beschreibung 

von Dungeon Siege (Kapitel 5.1). 


Ebenso wie die Daten der Spielobjekte wird deren Verhalten als Komponenten beschrieben. Die 

IDs der Objekte, die ein bestimmtes Verhalten zeigen können, werden in der entsprechenden 

Komponente, die dieses Verhalten implementiert, hinterlegt. Solche Komponenten können dann 

zum Beispiel Skriptobjekte, aber auch Objekte der Programmiersprache sein. 

Objekttypen werden in der gleichen Struktur gehalten; eine spezifische Instanz oder ein weiterer 

Typ erbt die Eigenschaften, sowohl Daten als auch Verhalten, ihres Vaters. Das erfordert, dass 

in einer weiteren Datenstruktur die Vererbungslinien der Typen und Objekte hinterlegt sind. 

Sowohl die Beschreibungen der Daten und Spielobjekte als auch die der Typen werden datadriven 

abgelegt. Dies wird vor allem dadurch untersützt, dass Spielobjekte nichts weiteres als 

zusammengesteckte Eigenschaften sind. 

Spielobjekte können indirekt dadurch gruppiert werden, dass sie mit anderen den Eintrag in 

bestimmten Komponenten gemeinsam haben. Dies lässt, wie bereits erwähnt, andere Subsysteme 

des Spiels nur auf den für sie bedeutenden Informationen arbeiten. 

Spielobjekte und Typen, die genauso wie Spielobjekte modelliert werden, können zur Laufzeit 

nachgeladen werden. Das gleiche trifft für die Verhaltenskomponenten zu, die in einer Skriptsprache 

definiert sind. Ob in diesem Modell Typen zur Laufzeit änderbar sind, so dass sich auch 

deren Kinder und Instanzen ändern, ist aus den Quellen nicht erkennbar. Das hängt zum einen 

davon ab, ob vererbte Eigenschaften in dem Kindobjekt gehalten oder weiterhin aus der Vaterklasse 

angefordert werden. Zum anderen ist dies in zweitem Fall davon abhängig, ob erfolgreiche 

Zugriffe auf Eigenschaften in einem Cache gehalten werden. 


Aus den oben gegebenen Informationen und der Beobachtung, dass in den Quellen keine die 

Kommunikation betreffenden Themen behandelt werden, ergibt sich für dieses Modell die in 



Abbildung 5.3 dargestellte Einordnung in die Taxonomie. 

Taxonomie 


Daten 

Modellierung 


Definition 

Verhalten 

Modellierung 

extern 

Definition 

Quelltext 

Skriptsprache 

Typen 

Modellierung 

Muster 

Definition 

data-driven 

Vererbung 

Konzept 

Einfach 

Gegenstand 

Daten 

Verhalten 

Objektordnung 






Kommunikation 

Abbildung 5.3: Einordnung des von Thief und Deus Ex verwendeten Systems in die Taxonomie 


Durch die Unterstützung des data-driven Designs mit Hilfe des komponentenbasierten Ansatzes 

lässt sich durch die Bereitstellung geeigneter Werkzeuge erreichen, dass Spielinhalt komplett 

unabhängig von dem Quelltext des Systems entworfen werden kann. In diesem Fall trifft dies 

auf alle Elemente der Objektstruktur zu: Spielobjekte, Typen und Verhalten lassen sich in 

externen Quellen definieren. 

Komponenten können für ihre spezifischen Anforderungen optimiert werden. Subsysteme, die 

eben nur auf eine Teilmenge der Daten der aktuell relevanten Spielobjekte zugreifen müssen, 

werden sich auf Komponenten stützen, die ihnen eben genau diese und nicht mehr und nicht 

weniger bereitstellen. Das hat positive Auswirkungen auf die Leistungsfähigkeit des Systems. 



Spielobjekte lassen sich in beliebiger Form aus Daten und Verhalten zusammensetzen. Der 

Ansatz erlaubt große Flexibilität und damit den Einsatz in weiteren Projekten. Wegen des Verzichts 

auf die objektorientierte Modellierung wird sich eine Erweiterung des Systems allerdings 

als schwierig herausstellen. Änderungen am Quelltext für die Komponentenmodellierung würden 

sich auch auf andere Programmteile auswirken. Zum Beispiel wäre die Frage zu klären, wie 

Abhängigkeiten zwischen den Eigenschaften der Spielobjekte implementiert werden könnten. 

Hier liegt gerade das Manko dieses Ansatzes. Die Aufgabe der objektorientierten Modellierung 

bedeutet die Abkehr von einem wohlverstandenen Prinzip, das gerade für die modulare Entwicklung 

einsteht. Das wirkt sich auch darin aus, dass keine Objektstruktur im eigentlichen Sinne 

existiert, zu der zum Beispiel über eine einheitliche Schnittstelle neue Objekte hinzugefügt oder 

bestehende gelöscht werden können. 

Weder über das Erreichen von Persistenz noch die Übermittlung der Daten werden in den Quellen 

Aussagen getätigt. Ersteres wird allerdings dadurch gefördert, dass Komponenten nichts 

anderes als Vektoren von Werten sind, die folglich direkt mit einer Datenbankrelation korrelieren. 

5.3 Worldforge Atlas Middleware 

Hinter dem Namen Worldforge verbirgt sich ein vielschichtiges Opensource Projekt, das sich 

zum Ziel gesetzt hat, Entwicklern freier Spiele Werkzeuge an die Hand zu geben. Atlas, als 

Teil dieses Projekts, ist ein Kommunikationsprotokoll für Prozesse, die auch auf lokal verteilten 

Rechnern laufen können. Im Folgenden beziehen wir uns auf die C++-Referenzimplementierung, 

die zusätzlich ein Objektmodell definiert. Die Dokumentation jedoch ist sehr dürftig und die 

exakte Verwendung des Systems geht aus dem Quelltext nicht unmittelbar hervor. 


Atlas für sich alleine definiert lediglich das Format für den Austausch von Objekten zwischen 

Prozessen. Die Referenzimplementierung hingegen bietet einiges mehr. Sie gibt vor, wie Spielobjekte, 

Typen und Operationen implementiert sein müssen, um mit Hilfe einer gegebenen 

Netzwerkschicht versendet werden zu können. 

Den Kern des Systems bilden fünf elementare Datentypen, die sowohl von Spielobjekten verwendet 

werden als auch selber versendbar sind: 

Integer: Eine ganze Zahl. 

Float: Eine Gleitzahl. 

String: Eine Zeichenkette. 

List: Eine geordnete Liste anderer Objekte. 

Map: Eine ungeordnete Abbildung von Schlüsseln auf andere Objekte. 



Ein Spielobjekt ist nicht mehr als eine Map der oben genannten Elemente, die zwei notwendige 

Einträge enthält: Die ID des Objekts sowie eine Liste seiner Väter. Ersteres dient zur eindeutigen 

Identifikation eines Spielobjekts, zweiteres kann zu Vererbungszwecken genutzt werden. Typen 

sind ebenfalls Objekte nach dem beschriebenen Prinzip, haben aber einen Eintrag in der Map, 

der sie als Typen markiert. 

Operationen sind ebenfalls als solche Objekte modelliert. Zusätzlich referenzieren sie in ihrer 

Map das Objekt, welches die Operation veranlasst hat, das Objekt, auf das sie angewendet werden 

sollen, sowie eine Liste von Parametern. In dieser Form werden sie auch zwischen Prozessen 

ausgetauscht. Da keine Möglichkeit existiert, einen Rückgabewert durch einen solchen Methodenaufruf 

zu erhalten, sind diese Operationen dem Prinzip nach Remote Procedure Calls 1 . Weder 

Atlas noch die Referenzimplementierung definieren jedoch, wie die eigentlichen Methoden 

definiert und nach dem Empfang auf ihr Zielobjekt angewendet werden. 

Es wäre möglich, alle diese genannten Objekte mit Hilfe einer einzigen Klasse zu implementieren, 

die eben lediglich die Map zum Halten der Attribute definiert. Die Implementierung bietet 

darüber hinaus aber weitere Klassen, welche von der oben genannten erben und zum Beispiel 

spezielle Entitäten oder Operationen darstellen. Diese geben dann einige Einträge der Map vor 

und bieten weitergehende direkte Methoden zum Setzen der zusätzlichen Attribute. 

Die Referenzimplementierung definiert Schnittstellen zum Serialisieren der zu versendenden 

Objekte sowie eine Anzahl von Filtern, welche die Daten für die Netzwerkschicht aufbereiten 

beziehungsweise diese beim Empfang aus dem Netzwerkstrom zurückgewinnen. Letztere bieten 

zum Beispiel die Möglichkeit der Verschlüsselung oder den Einsatz von Prüfsummen und lassen 

sich für komplexere Aufgaben aneinanderketten. 


Die Anordnung der Objekte sowie die Definition der Daten, des Verhaltens und der Typen sind 

nicht Teil von Atlas-C++. Nach dem Prinzip der Remote Procedure Calls versendet Atlas zur 

Änderungsübermittlung Operationen, auf die der Empfänger reagiert. Auf diesem Weg kann 

sich auch ein Teilnehmer über Änderungen bei anderen Teilnehmern informieren. 

Damit ergibt sich die in Abbildung 5.4 ersichtliche Einordnung in die Taxonomie. 


Sowohl Spielobjekte als auch Typen und Aktionen werden lediglich über Daten definiert. Das 

erlaubt die flexible Gestaltung eines Spiels und bietet die Möglichkeit, genannte Entitäten 

aus externen Quellen mit Hilfe des Ansatzes des data-driven Designs zu erschaffen. Damit 

ist das System in anderen Projekten wiederverwendbar. Der Quelltext – zumindest der des 

Atlas-Frameworks – ist unabhängig von dem Spielinhalt. Die objektorientierte Entwicklung erlaubt 

es, das Modell um zusätzliche Funktionalität zu erweitern. Gerade die Idee der Filter zur 

1 http://de.wikipedia.org/wiki/Remote_Procedure_Call 



Taxonomie 


Daten 

Modellierung 


Definition 

Verhalten 

Modellierung 

extern 

Definition 

Typen 

Modellierung 

Klassen 

Definition 

Vererbung 

Konzept 

Mehrfach 

Gegenstand 

Daten 

Objektordnung 


Kommunikation 

Initiative 

Polling 


Kompression 



Abbildung 5.4: Einordnung des in Atlas verwendeten Systems in die Taxonomie 

Beeinflussung des Kommunikationsverkehrs bietet die Anpassung des Systems an individuelle 

Bedürfnisse. 

Mit Atlas wird ein Protokoll zum Abgleich von Daten implementiert, das zumindest innerhalb 

des Worldforge Projekts standardisiert und getestet ist. 

Atlas-C++ bietet kein vollständiges Objektmodell sondern hauptsächlich eine Kommunikationsschnittstelle. 

Es bedarf eines weiteren Entwurfs zur Anordnung der Objekte, der Anbindung 

des Verhaltens an die Objekte und der Erstellung von Objekten. 

Zwischen Spielobjekten, Verhalten und Typen besteht kein Unterschied im Quelltext. Das erfordert 

weitere Überprüfungen zur Laufzeit, die ansonsten zur Kompilierzeit hätten durchgeführt 

werden können. 

Mechanismen zur Persistenz werden nicht angeboten, sollten sich aber leicht in das System 

integrieren lassen, da alle Entitäten nur aus Daten bestehen. 



5.4 Britt L. Hannahs Vorschlag für ein Objektmodell 

In diesem Abschnitt soll ein Vorschlag für ein Objektmodell behandelt werden, der vor allem 

auf Wiederverwendbarkeit und damit den Einsatz als universelles Framework abzielt [Hannah, 

2004]. Eine Beispielimplementierung ist vorhanden, es mangelt aber noch an einer kompletten 

Umsetzung der Idee. 


Das System basiert auf der Beobachtung, dass fünf grundlegende Entitäten in jedem Spiel zu 

finden sind. Diese manifestieren sich deshalb wiederum als Objekte im Modell und sollen hier 

als erstes eingeführt werden. Die genaue Wirkungsweise derselben wird im weiteren Verlauf 

deutlich werden. 

1. Game Entity Object: Das Entitätsobjekt repräsentiert ein Spielobjekt, welches alles 

von einem Gegenstand bis zu einem Spielercharakter darstellen kann. 

2. Game Action Object: Dieses Objekt modelliert die Logik des Spiels und damit das 

Verhalten der Spielobjekte. Dabei repräsentiert es Ereignisse wie Springen, Schießen, etc. 

Aktionen werden von anderen Aktionen oder durch Eingaben des Benutzers aufgerufen. 

3. Game Form Object: Im Gegensatz zu dem Entitätsobjekt stellt dieses Element die 

virtuelle Erscheinung eines Spielobjekts dar. Dies ist üblicherweise ein 3D-Modell. Im 

Folgenden bezeichnen wir dieses als Formobjekt. 

4. Game State Object: Zustandsobjekte stellen als Teil von Entitäts- und Formobjekten 

deren Zustand zu einem bestimmten Zeitpunkt dar. Jedes Zustandsobjekt repräsentiert 

dabei eine Zustandsvariable. 

5. Game Space Object: Ein Raumobjekt ist eine Menge von anderen Objekten des Systems. 

Die Motivation für ein solches Objekt ist Optimierung, denn auf diesem Weg können 

Spielobjekte für bestimmte Zwecke und zur Bearbeitung durch andere Subsysteme des 

Spiels gruppiert werden. 

Diese Objekte stehen in zahlreichen Beziehungen zueinander, wie aus Abbildung 5.5 ergeht. 

Um diese nachvollziehen zu können, sollen jetzt, nachdem ein Überblick gegeben wurde, alle 

Elemente des Modells im Detail betrachtet werden. 

Das Raumobjekt 

Ein Raumobjekt enthält Entitäts- und/oder Formobjekte, die in einer dem aktuellen Kontext 

entsprechenden Beziehung zueinander stehen. Natürlich ist dies dynamisch und wird sich während 

der Laufzeit ständig ändern. 



0.* 

Space 

target,source 0.* Form Entity Action 

0.* 

0.* 

liestundändert State0.*0.* 

Abbildung 5.5: UML Diagramm der von Britt L. Hannah vorgeschlagenen Architektur 

Die übliche Verwendung der Raumobjekte ist zum Beispiel die Unterteilung der Menge der 

Spielobjekte in einen virtuellen und einen logischen Raum. Während ersterer die Formobjekte 

hält, die in der aktuellen Spielsituation visuell dargestellt werden sollen, umfasst zweiterer die 

Entitätsobjekte, die die Logik des Spiels bestimmen. 

Das Zustandsobjekt 

Zustandsobjekte sind Teil von Entitäts- und Formobjekten und sind, wie in Kapitel 3.1.1.1 vorgestellt, 

als dynamische Zustände implementiert. Dabei definieren sie den Zustand, in dem sich 

ein solches Objekt zu einem bestimmten Zeitpunkt befindet. Dies ist zunächst nicht ungewöhnlich, 

wird aber bei der Betrachtung der Aktionsobjekte interessant, denn ob eine bestimmte 

Aktion auf ein Objekt anwendbar ist, bestimmt sich durch die Zustandsvariablen desselben. 

Eine Aktion zum Ändern der Lebenspunkte eines Objekts könnte nur auf solche Spielobjekte 

angewendet werden, die eben genau die Zustandsvariable für die Lebenspunkte enthalten. Aktionen 

ändern bei ihrer Anwendung die Werte der Zustandsobjekte von Objekten und damit 

also indirekt auch das Verhalten derselben. 



Das Formobjekt 

Formobjekte sind die Objekte des Systems, die visuell dargestellt werden. Der Nutzer wird dabei 

davon ausgehen, dass das, was er sieht, das Spielobjekt ist. Das ist allerdings falsch, denn dieses 

wird systemintern von einem Entitätsobjekt repräsentiert. Lediglich die Informationen in Form 

von Zustandsobjekten, die für die Anzeige nötig sind, werden im Formobjekt gehalten. 

Der Vorteil dieser Auslagerung der visuellen Eigenschaften ist, dass die Anzeige der Spielobjekte 

von denselben entkoppelt und somit leicht austauschbar ist und die Formobjekte unabhängig von 

den eigentlichen Spielobjekten in für die Grafikengine vorteilhaften Datenstrukturen gehalten 

werden können. 

Um die Anzeige zu steuern, enthält ein Formobjekt Zustandsobjekte. Diese bestimmen zum 

Beispiel seine Position und Ausrichtung im Raum. Gleichzeitig wirken sich diese aber auch auf 

die Aktionen aus, die auf einem Entitäts- und seinem Formobjekt ausgeführt werden. Denn die 

Aktionen können natürlich auch von den oben genannten Parametern abhängen. 

Dadurch, dass Formobjekte Raumobjekte enthalten können, können sie transitiv auch andere 

Entitätsobjekte beinhalten. Das hat vor allem eine Bedeutung in Hinblick auf die Aktionsobjekte, 

die in Raumobjekten auf Mengen von Objekten arbeiten. Eine Aktion könnte zum Beispiel 

aus dem 3D-Modell eines Formobjekts Beschränkungen für die in diesem enthaltenen Objekte 

herleiten. Ein Raum in einem Haus wäre zum Beispiel durch ein Formobjekt repräsentiert. 

Für die in seinen Raumobjekten enthaltenen Entitätsobjekte würde die Einschränkung gelten, 

dass diese sich nicht durch die Wand des Raumes, also über die Abmessungen des Formobjekts 

hinaus, bewegen könnten. 

Das Aktionsobjekt 

Entitätsobjekte werden zum einen durch die enthaltenen Zustandsobjekte als auch durch ihre 

Aktionen beschrieben. Letztere beschreiben das Verhalten, welches ein Spielobjekt mitbringt. 

Aktionen verändern den Zustand von Spielobjekten dadurch, dass sie die Zustandsobjekte der 

Entitäts- und Formobjekte modifizieren. Gleichzeitig hängt ihre Logik aber auch von diesen 

Zustandsvariablen ab. 

Aktionsobjekte halten zum einen eine Referenz auf das Entitätsobjekt, von dem sie ausgehen, 

sowie ein Zielobjekt oder eine Menge von Zielobjekten. Bei der Ausführung hängt diese Aktion 

nur von deren Zustandsobjekten ab und ändert eben auch nur dieselben. 

Die Idee ist, dass Aktionen wiederum neue Aktionen hervorrufen und so das Spiel lebendig 

wird. Das Beispiel wäre eine Aktion Schießen, die auf einem Spielobjekt wirkt und dessen Lebenspunkte 

modifiziert. Zunächst stellt die Aktion fest, ob ihr Ziel das Zustandsobjekt für die 

Lebenspunkte überhaupt besitzt. Ist das der Fall, wird die Aktion ihre Arbeit machen und danach 

überprüfen, ob die Lebenspunkte des Zielobjekts noch größer Null sind. Sollte das nicht 

zutreffen, könnte sie auf jenem Objekt zum Beispiel eine Sterben-Aktion aufrufen. 

Aktionen sollen über entsprechende Schnittstellen direkt die audiovisuelle Ausgabe ansteuern 



beziehungsweise den entsprechenden Subsystemen Aufgaben zuweisen. Es ist wichtig, dass Aktionen 

über einen Zeitraum und nicht nur zu einem Zeitpunkt existieren. Dies wird im Folgenden 

deutlich. 

Das Entitätsobjekt 

Die Entitätsobjekte sind die Schaltstelle des Systems, wie aus Abbildung 5.5 zu entnehmen ist. 

Sie haben Beziehungen zu allen anderen Objekttypen. 

Die Visualisierung eines Entitätsobjekts wird durch das assoziierte Formobjekt bestimmt. Dieses 

ist austauschbar, so dass ein Entitätsobjekt leicht unterschiedliche Erscheinungen annehmen 

kann. 

Während der Zustand eines Entitätsobjekts durch seine Zustandsobjekte definiert ist, wird sein 

Verhalten durch die ihm zugeordneten Aktionen festgelegt. Diese werden in zwei unterschiedlichen 

Datenstrukturen innerhalb des Entitätsobjektes gehalten. Zunächst befinden sich die 

Aktionen in der Menge der für dieses Objekt gültigen Aktionen. Wird eine Aktion aufgerufen, 

wird sie in eine Warteschlange für auszuführende Aktionen verschoben. So kann später das Entitätsobjekt 

aufgefordert werden, nacheinander die Aktionen dieser Warteschlange auszuführen. 

Gleichzeitig wird verhindert, dass eine Aktion zwei Mal ausgeführt wird. Die entsprechende 

Aktion kann nun mehrere Iterationen in dieser Warteschlange verharren und wird in jedem 

Durchlauf ihre Arbeit verrichten. Sobald die Aktion diese abgeschlossen hat, wird sie sich selber 

aus der Warteschlange entfernen und zurück in die Menge der verfügbaren Aktionen des 

entsprechenden Entitätsobjekts befördern. 

Dadurch, dass ein Entitätsobjekt indirekt über sein Formobjekt eine Referenz auf ein Raumobjekt 

hält, kann es jedes andere Objekt, welches im aktuellen Kontext gültig ist, erreichen. Dies 

ist vor allem für die Aktionen wichtig, die damit ihre Zielobjekte bestimmen. 


Es wird keine Aussage über die Definition von Daten und Verhalten gemacht, beides wäre jedoch 

data-driven umsetzbar, da zum einen die Daten auf dynamischen Attributen basieren und 

die Aktionen entkoppelt von den Spielobjekten sind und somit als Skriptobjekte zu implementieren 

wären. Selbiges trifft auf die Typisierung zu. Die Spielobjekte sind zum einen dadurch 

hierarchisch geordnet, dass Entitätsobjekte mit Formobjekten assoziiert sind, diese wiederum 

Raumobjekte halten, die schließlich wieder Entitätsobjekte enthalten können. Zum anderen lassen 

sich Spielobjekte mit Hilfe der Raumobjekte gruppieren. 

Über die Dynamik zur Laufzeit kann wegen der fehlenden Beschreibung der Art der Objektdefinition 

keine Aussage gemacht werden. Bei einer entsprechenden Umsetzung nach dem datadriven 

Design sollte es möglich sein, in diesem Punkt eine größtmögliche Flexibilität zu erreichen. 

Die Unterstützung der Kommunikation wird in der Quelle bewusst nicht behandelt, denn das 

Modell soll durch seine Modularität inhärent offen gegenüber derartigen neuen Anforderungen 

sein. 



Es ergibt sich damit die in Abbildung 5.6 sichtbare Einordnung in die Taxonomie. 

Taxonomie 


Daten 

Modellierung 


Definition 

Verhalten 

Modellierung 


Definition 

Typen 

Objektordnung 




Kommunikation 

Abbildung 5.6: Einordnung des von Britt L. Hannah vorgeschlagenen Systems in die Taxonomie 


Das vorgestellte System basiert vor allem auf der Austauschbarkeit seiner Bestandteile. Nicht 

nur kann die visuelle Erscheinung der Spielobjekte leicht ausgetauscht werden, sondern auch 

das Verhalten, welches in den Aktionen – leichtgewichtigen Komponenten – gekapselt ist. Spielobjekte 

können in beliebiger Form aus Zustandsvariablen zusammengesteckt werden, wodurch 

gleichzeitig ihr Verhalten gesteuert werden kann. 

Dies fördert nicht nur die Wiederverwendbarkeit sondern auch die Erweiterbarkeit des Systems. 

Wie beschrieben ist es leicht vorstellbar, das System data-driven zu gestalten und damit die 

Unabhängigkeit des Spieldesigns vom Quelltext zu erreichen. 

Durch die Gruppierung der Entitäts- und Formobjekte in Raumobjekte lassen sich für andere 

Subsysteme des Spiels Sichten auf das Objektmodell definieren, die einen effizienten Zugriff für 

die jeweilige Aufgabe erlauben. 

Nachteilig in Hinblick auf die gegebenen Anforderungen ist, dass sich die Quelle weder mit 

Persistenz noch mit Kommunikation beschäftigt. Es bedarf weiterer Untersuchungen, wie das 

Modell diese beiden Subsysteme in ausreichender Weise unterstützen könnte. 

Das System definiert keine einzelne Schnittstelle auf die entstehende Objektstruktur. Anstattdessen 

existieren parallel unterschiedliche Typen von Objekten in komplexen Beziehungen und 

mit sehr unterschiedlichen Aufgaben, was die Implementierung erschwert und einen einheitlichen 

Zugriff auf die Struktur verhindert. 


Kapitel 6 

Design und Implementierung 

Die Schöpfung ist niemals vollendet. 

Sie hat zwar einmal angefangen, aber 

sie wird niemals aufhören. 

Immanuel Kant 

Das Ziel dieser Arbeit ist die Erstellung eines flexiblen Objektmodells für Spiele. Eine Bestandsaufnahme 

der Marktsituation wurde durchgeführt und eine Taxonomie aufgestellt, die 

die Problemstellung charakterisiert und kategorisiert. Die Anforderungen an die Arbeit wurden 

identifiziert und dargelegt. Diese seien hier zur Erinnerung noch einmal gegeben: 

• Flexible Objektstruktur 

• Auf den Spielobjekten ausführbare Aktionen 

• Unterstützung des data-driven Designs 

• Möglichkeit zur Herstellung der Persistenz des Spielzustands 

• Ausreichende Performanz 

• Erweiterbarkeit und Wiederverwendbarkeit 

Aufbauend auf den gewonnenen Erkenntnissen soll im Folgenden ein Objektmodell entworfen 

werden, das den genannten Anforderungen genügt. Die Taxonomie umfasst die für ein solches 

Projekt zu bedenkenden Aspekte und deren Implementierungsmöglichkeiten. Es liegt daher 

nahe, das System anhand dieser zu entwickeln. Wir werden also schrittweise die einzelnen Abschnitte 

der Taxonomie betrachten und damit sukzessive ein Softwaresystem entwickeln, das in 

jedem Schritt um weitere Elemente wie Klassen und Methoden ergänzt wird. Die Implementierung 

wird in Java vorgenommen, weil damit die Kompatibilität mit dem zu entwickelnden 

Framework erhöht wird, dessen Entwicklung in der gleichen Programmiersprache erfolgt. Daher 

hat sich auch die Modellierung auf die von Java bereitgestellten Konstrukte zu beschränken. 

Zum Beispiel wird die Mehrfachvererbung nicht unterstützt. 

Abschließend wird das Gesamtsystem dargestellt und kurz gegen die Anforderungen geprüft. 

Im nachfolgenden Kapitel wird dann beschrieben, wie das Objektmodell in einem Spieleprojekt 

zu nutzen ist.

VI. Design und Implementierung 47 

6.1 Spielobjekte 

Zunächst wird die Struktur der Spielobjekte definiert. Dabei sind die Daten, das Verhalten, die 

Typisierung und die Anordnung der Objekte untereinander zu bestimmen. Jeder dieser Aspekte 

wird nun einzeln betrachtet, modelliert und die jeweiligen Entscheidungen begründet. 

6.1.1 Daten 

In Kapitel 3.1.1.1 wurden die Möglichkeiten zur Modellierung der Daten der Spielobjekte vorgestellt. 

Die Implementierung als Sprachkonstrukte bedingt eine feste Kodierung der Objektdefinitionen 

im Quelltext, was einen flexiblen Einsatz und ständige Änderungen zur Laufzeit 

unterbindet oder zumindest stark erschwert. Das Komponentenmodell unterstützt das datadriven 

Design, induziert aber eine steile Lernkurve bei den Mitarbeitern und verzichtet auf 

eine direkte Modellierung mit Hilfe der objektorientierten Entwicklung und damit die leichte 

Erweiterbarkeit und Wiederverwendbarkeit. Die Modellierung als dynamische Attribute bietet 

eine größtmögliche Flexibilität, mangelt aber an einer Typisierung der Attribute, wodurch teure 

Typüberprüfungen zur Laufzeit nötig werden. 

Es liegt daher nahe, die Daten mit Hilfe dynamischer Zustände zu modellieren, die zum einen 

nicht dem Problem der fehlenden Typisierung unterliegen und zum anderen durch die Kombinationen 

der Zustände beliebige Spielobjekte erlauben, die auch zur Laufzeit problemlos geändert 

werden können. Der zusätzliche Speicherbedarf, der dadurch entsteht, dass alle Daten auf 

Instanzebene und nicht auf Klassenebene gehalten werden, kann durch eine eigene Implementierung 

von Spielobjekttypen verringert werden. Auf diesem Weg ist es auch möglich, direkt 

den Typ eines Objekts zu bestimmen. Dies wird im späteren Verlauf behandelt. Die zusätzlichen 

Laufzeitkosten werden gemäß den Anforderungen zu Gunsten einer guten Erweiterbarkeit, 

Wiederverwendbarkeit und Erlernbarkeit vernachlässigt. 

Die Zustände sollen in unterschiedlichen Typen vorliegen, die wir auf folgende festgelegt haben: 

Double: eine Gleitkommazahl 

Integer: eine ganze Zahl 

Boolean: ein Bool’scher Wert 

String: eine Zeichenkette 

Map: eine Zuordnung von Zeichenketten auf Zustände 

Set: eine ungeordnete Menge von Zuständen 

List: eine geordnete Liste von Zuständen 

Damit die Instanzen dieser Zustandstypen innerhalb der Spielobjekte in einer einzigen Datenstruktur 

gehalten werden können, bedarf es einer gemeinsamen Oberklasse, die im Folgenden 


48 VI. Design und Implementierung 

+setName(name:String) +getName():String State 

+getAsInt():int +setAsDouble(double:double) +getAsDouble():double +setAsInt(int:int) 0.* GameObject states:Map +getState(key:String):State +adState(state:State) +removeState(key:String) +hasState(key:String):bol 

etali 

Abbildung 6.1: UML Diagramm der Zustände 

als State bezeichnet wird und ein Paar von Zugriffsfunktionen (Getter und Setter) für jeden der 

oben genannten Typen definiert. Diese Methoden werfen in ihrem Standardverhalten zunächst 

noch Ausnahmen. Die konkreten Zustandsklassen überschreiben dann genau die Methoden für 

den Typ, den sie repräsentieren. So ist sichergestellt, dass auf einem konkreten State nur typsichere 

Operationen ausgeführt werden können. 

Ein Spielobjekt enthält eine Menge von Zuordnungen von Schlüsseln auf State Objekte. 

Das ermöglicht es, ein Objekt gezielt nach einem bestimmten Zustand zu befragen. Dafür 

werden die Zugriffsmethoden hasState(String), getState(String), addState(State) und 

removeState(String) angeboten. Mit dem Klassennamen GameObject für das Spielobjekt ergibt 

sich dann zunächst die in Abbildung 6.1 dargestellte Modellierung. 

value:int +setAsInt(int:int) +getAsInt():int IntState DoubleState +setAsDouble(double:double) +getAsDouble():double d:double 

Die Definition der Daten basiert lediglich auf den Zustandsklassen und ist damit unabhängig 

von der Klasse GameObject. Somit können die Informationen extern nach dem Prinzip des 

data-driven Design beschrieben werden. Einsetzbar sind alle in Kapitel 3.1.1.2 vorgestellten 

Datenquellen. Von dem System wird kein bestimmter Weg vorgeschrieben, wie später noch 

deutlich werden wird. 

6.1.2 Verhalten 

Da den Spielobjekten flexibel Verhalten zugewiesen werden können soll, ist es nicht sinnvoll, 

dieses fest in Form von Methoden an die Klasse GameObject zu binden. Abgesehen davon ist 

die Anzahl der Aktionen in einem ausgewachsenen Spiel sehr groß, was eine aufgeblähte Klas- 



sendefinition nach sich ziehen würde, von der jede Instanz letztlich nur einen geringen Teil der 

Methoden gebrauchen würde. Nun bleibt noch, das Verhalten extern oder als Komponenten zu 

modellieren. Ersteres bedarf aufwendiger Logik, um festzusetzen, welches Verhalten ein Spielobjekt 

annehmen kann. Letzteres hingegen bietet Flexibilität, unterliegt aber in seiner ursprünglichen 

Fassung dem Problem, dass das Spezifizieren von Abhängigkeiten zwischen Komponenten 

kompliziert ist. 

[Hannah, 2004] schafft dem Abhilfe, wie in Kapitel 5.4 vorgestellt. Aktionen sind als Command-Objekte 

[Gamma, 1997] und damit als Komponenten modelliert und ihr Wechselspiel 

untereinander basiert in erster Linie auf den Zuständen der Spielobjekte sowie auf der Möglichkeit, 

dass Aktionen wiederum andere Aktionen induzieren können. Insbesondere ist das Modell 

unabhängig von den eigentlichen Spielobjekten, Verhalten bestimmt sich nur auf Grund der 

Zustände von Spielobjekten. Die dadurch entstehende lose Kopplung der Komponenten Spielobjekte 

und Verhalten erlaubt die leichte Austauschbarkeit und damit Wiederverwendbarkeit 

derselben. Wir werden die Modellierung der Aktionen auf dem gleichen Weg umsetzen. Diese 

referenzieren zum einen ein Spielobjekt, von dem sie ausgehen (source) und zum anderen ein 

einzelnes Zielobjekt (target) oder eine Menge von Zielobjekten (targetSet). Ist kein target 

Objekt gegeben, wird angenommen, dass das source Objekt ebenfalls diese Rolle übernimmt. 

Wird die Methode doAction() auf einer solchen Aktion aufgerufen, führt sie ihre Arbeit basierend 

auf den Zuständen ihres Quellobjekts und ihrer Zielobjekte aus. Üblicherweise ändert sie 

als Ergebnis die Zustände und damit das Verhalten derselben. 

Die Klasse GameObject erhält eine Menge möglicher Aktionen (possibleActions), die über 

ihren Namen referenziert werden, sowie eine Warteschlange von gerade ausgeführten Aktionen 

(currentActions). Mit Hilfe der Methode activateAction(), die als Parameter den Namen 

einer Aktion sowie ein Zielobjekt oder eine Menge von Zielobjekten erwartet, kann nun eine 

Aktion auf einem Spielobjekt, die sich in den possibleActions befindet, initialisiert und aktiviert 

werden. Diese wird dann in die currentActions verschoben und in jeder Spieliteration 

durch doAction() aufgefordert, ihre Aufgabe zu erfüllen, bis eine externe Komponente oder sie 

sich selber mit Hilfe der Methode deactivateAction() für beendet erklärt und das Spielobjekt 

auffordert, sie zurück in die possibleActions zu verschieben. So wird zum einen das Ausführen 

von Aktionen ermöglicht, die länger als eine Spieliteration dauern, zum anderen wird verhindert, 

dass eine Aktion gleichzeitig mehrmals von dem gleichen Spielobjekt ausgeführt wird. 

Ein Spielobjekt kann über die Methode doActions() aufgefordert werden, die Aktionen seiner 

currentActions auszuführen. Dies sollte üblicherweise einmal in jeder Iteration der Spielschleife 

geschehen. Mit Hilfe der Methoden sleep() und unsleep() kann erreicht werden, dass ein 

Spielobjekt über einen bestimmten Zeitraum keine Aktionen ausführt. Diese Methoden werden 

später sukzessive mit weiterer Funktionalität versehen, um Spielobjekte komplett in einen 

passiven Zustand zu überführen. 

Aktionen mit einem konkreten Verhalten erben von der abstrakten Klasse Action, die die oben 

genannte Basisfunktionalität bietet. Das Verhalten kann dann sowohl im Quelltext innerhalb 

der doAction() Methode als auch extern in einer Skriptsprache definiert sein, denn eine Aktion 

kann natürlich in dieser Methode auch ein Skriptobjekt aufrufen und diesem Zugriff auf 

das Quellobjekt und die Zielobjekte und damit deren Zustände bieten. Dies bietet den Vorteil, 

dass Verhalten ohne Neukompilierung des Projekts eingebracht werden kann, was wiederum 

das data-driven Design unterstützt. Drei solcher Aktionsklassen sind beispielhaft implemen- 



tiert. Eine davon führt Lua Skriptcode aus (LuaScriptAction), eine andere Tcl Skriptcode 

(TclScriptAction) und eine dritte definiert ihr Verhalten im Quelltext (IncreaseHPAction). 

Jede von Action abgeleitete Klasse korrespondiert mit einer konkreten Implementierung von 

ActionFactory. Durch diese wird sie erstellt, da das Instanziieren einer Aktion möglicherweise 

einen größeren Aufwand bedeutet. Bei der Erstellung erhält die Action von ihrer ActionFactory 

den Namen zugewiesen, über den sie in den Spielobjekten angesprochen wird und der für jede 

Art von Aktion eindeutig ist. Insbesondere kann über diesen Namen mit Hilfe der Methode 

hasAction() festgestellt werden, ob ein Spielobjekt eine bestimmte Aktion ausführen kann. 

Das Prinzip der ActionFactory wird im weiteren Verlauf in Bezug auf die Typisierung von 

Spielobjekten interessant. Gleichzeitig bietet es aber auch die Möglichkeit, zur Laufzeit neue 

Aktionsinstanzen zu kreieren. Das nun um die oben genannten Klassen und Methoden ergänzte 

System ist in Abbildung 6.2 dargestellt. 

©posibleActions:Map ©curentActions:List +doActions() +activateAction(name:String,target:GameObject) GameObject 

+hasAction(name:String):bolean +slep()+unslep() State +deactivateAction(name:String) 0.* 

+source +target liestundändert 

©source:GameObject ©target:GameObject ©targetSet:Set +doAction() Action ActionFactory +getName():String 0.* +instantiate(source:GameObject):Action 

Abbildung 6.2: UML Diagramm der Aktionen 

+doAction() IncreaseHPActionFactory +instantiate(source:GameObject):IncreaseHPAction +getName():String IncreaseHPAction 

LuaScriptActionFactory +getName():String LuaScriptAction +doAction() +instantiate(source:GameObject):LuaScriptAction erstelt 

erstelt 



6.1.3 Typisierung 

Um das Speicheraufkommen zu verringern, sollen Spielobjekte typisiert sein und Eigenschaften 

nicht komplett auf der Instanz- sondern auch auf der Typebene gehalten werden. Da sowohl 

Daten als auch Aktionen entkoppelt von den Spielobjekten modelliert sind, bietet es sich an, 

jedem Spielobjektstyp ebenfalls eine Menge dieser Entitäten zuzuweisen, die dann von den 

konkreten Instanzen geerbt und möglicherweise überschrieben wird. Damit können Typen als 

Muster modelliert werden, was sowohl das data-driven Design und damit die Flexibilität des 

Systems unterstützt als auch die Änderung von Typen zur Laufzeit ohne Neukompilierung 

des Projekts erlaubt. Ersteres wird bei der Modellierung der Typen als Klassen nur bedingt 

ermöglicht, zweiteres hingegen gar nicht unterstützt. 

Die Klasse GameObjectType erhält somit analog zu GameObject eine Menge von State Objekten 

sowie eine Menge von ActionFactory Objekten, die jeweils über ihren Namen referenziert 

werden. An diesem Punkt ist die Beobachtung wichtig, dass GameObject direkt Action Objekte 

enthält, GameObjectType hingegen ActionFactory Objekte. Das ist dadurch bedingt, dass Aktionen, 

die in dem Typ eines Spielobjekts vorliegen, erst dann erstellt werden, wenn das entsprechende 

Spielobjekt über activateAction() aufgefordert wird, diese zu aktivieren. Eine Aktion 

erhält ihren Urheber als source, so dass die Instanzen eines bestimmten GameObjectType unterschiedliche 

Instanzen einer Aktion erhalten müssen. Deshalb wird diese bei Bedarf erstellt. 

In Bezug auf die Behandlung der State Objekte ist ebenfalls eine Anpassung nötig, denn die 

Bereitstellung derselben durch ein Spielobjekt geschieht nun sowohl durch dieses selber als auch 

möglicherweise seinen Typ, wenn das Zustandsobjekt nicht direkt im Spielobjekt enthalten ist. 

In letzterem Fall ist sicherzustellen, dass bei einer Änderung des Zustandsobjekts dessen neuer 

Wert nicht in das Zustandsobjekt des Typs sondern in eines des Spielobjekts geschrieben wird, 

denn ansonsten würden damit alle Instanzen dieses Typs geändert werden. Dieses Problem wird 

folgendermaßen gelöst. Kann eine Anfrage nach einem State nicht innerhalb eines Spielobjekts 

aber durch dessen Typ beantwortet werden, wird mit Hilfe der Methode pack der Klasse State 

ein neues Zustandsobjekt erstellt, welches eine Kopie des durch den Typ zurückgelieferten ist 

und einen Verweis auf dieses erhält (internalState). Das neue Objekt wird in die Liste der 

Zustände des Spielobjekts eingetragen. Solange nur Lesend auf dieses zugegriffen wird, liefert es 

den Wert von internalState. Bei der ersten Modifzierung wird der Verweis auf den internen 

Zustand gelöscht, so dass das State Objekt eigenständig wird. 

Um diese Funktionalität bereitstellen zu können, erhält die Klasse GameObjectType eine Methode 

getStateForGameObject, die ein solches gepacktes Zustandsobjekt zurückliefert. 

GameObject referenziert seinen Typ und reicht jede Anfrage an State oder Action Objekte, 

die es nicht selber auflösen kann, an diesen weiter. Um das System noch effizienter zu gestalten, 

können GameObjectType Objekte eine Referenz auf ein weiteres GameObjectType Objekt halten, 

um so eine Vererbungshierarchie aufzubauen. Andersherum erhält jedes dieser Objekte einen 

Verweis auf die von ihm erbenden Typen. Letzteres wird später bei der Verwaltung der Hierarchie 

benötigt. Die eben genannten Anfragen an den Typ eines Spielobjekts werden die Hierarchie 

hochpropagiert, bis sie erfüllt werden können oder am Wurzelknoten die Unerfüllbarkeit derselben 

festgestellt wird. Die Ergebnisse dieser Anfragen werden nicht zwischengespeichert, sondern 

im Falle der State Objekte mit der oben beschriebenen Methode der gepackten Zustandsobjekte 

gelöst. Dadurch wirken sich auch noch zur Laufzeit Änderungen der Typen auf deren Instanzen 



aus. Insbesondere können zur Laufzeit die Typhierarchie modifiziert und die Typen einzelner 

Spielobjekte ausgetauscht werden. Um das zu ermöglichen, wird auch bei der Anfrage nach einem 

Zustandsobjekt an einen Typ das Ergebnis gepackt und in der Liste der Zustandsobjekte 

des befragten Typs abgelegt. 

Natürlich ist dennoch die Möglichkeit gegeben, nur eine einstufige Hierarchie zu erstellen, die 

die nötigen zusätzlichen Laufzeitkosten, die durch das erwähnte Propagieren der Anfragen entstehen, 

eliminiert. 

Da die Mehrfachvererbung einen größeren Verwaltungsaufwand mit sich bringt, wird in diesem 

System nur die Einfachvererbung umgesetzt. 

Ebenso wie Spielobjekte lassen sich Typen mit Hilfe des data-driven Design in externen Datenquellen 

auf sehr ähnliche Weise definieren, denn Typen sind kaum etwas anderes als Spielobjekte. 

Die aus dieser Entwicklung entstehenden Klassen ergehen aus Abbildung 6.3. +parent 

6.1.4 Anordnung 

parent:GameObjectType children:List +setParent(type:GameObjectType) +getParent():GameObjectType GameObjectType 

+removeChild(child:GameObjectType) +getState(name:String):State +getStateForGameObject(name:String):State +adChild(child:GameObjectType) 

+type 

type:GameObjectType +setType(type:GameObjectType) GameObject +getType():GameObjectType 

ActionFactory 0.* 

+pack():State internalState:State State 

Abbildung 6.3: UML Diagramm der Typen 

0.*0.*+internalState 

Unter den in Kapitel 3.1.4 vorgestellten Methoden zur Anordnung der Spielobjekte ist die der 

hierarchischen Ordnung die flexibelste, denn mit Hilfe dieser ließe sich auch eine logische Gruppierung 

umsetzen und natürlich auch eine nichtgeordnete Menge von Spielobjekten simulieren. 

Deswegen sollen in diesem System die Objekte in einer Baumstruktur angeordnet werden, die 



eine hierarchische Ordnung definiert. Der Verwaltungsaufwand für einen Graphen, gerade was 

das Behandeln von Zyklen betrifft, ist hoch. Daher wurde diese Option nicht weiter betrachtet. 

Zunächst wird die Klasse GameObject, deren Instanzen also wiederum mehrere Objekte des 

gleichen Typs enthalten können sollen, mit Methoden ausgestattet, die das Anlegen einer solchen 

Baumstruktur erlauben. Dies sind die folgenden: 

• addChild(GameObject) 

• addChild(GameObject, Integer) 

• removeChild(GameObject) 

• setParent(GameObject) 

• getParent(GameObject) 

addChild kann neben dem hinzuzufügenden Spielobjekt einen weiteren Integer-Parameter 

entgegennehmen, der bestimmt, an welcher Stelle in der Liste der Kinder des Vaterobjekts 

dieses Spielobjekt eingefügt werden soll, falls die Reihenfolge von Belang ist. Die 

setParent(GameObject) Methode führt keine Überprüfung nach Inkonsistenzen wie entstehende 

Zyklen durch, so dass diese Aufgabe aussenstehenden Entitäten zufällt. 

Damit ein eindeutiger Zugriff auf Spielobjekte möglich ist, erhält GameObject eine ID sowie 

die zugehörige Zugriffsmethode getId(). Die ID kann entweder bei der Konstruktion eines Objekts 

gesetzt werden oder wird automatisch mit Hilfe der statischen Methode getUniqueId() 

bestimmt. Letztere gewährt den Zugriff auf einen fortlaufenden Zähler für die Objekte, die 

ohne vom Entwickler vorgegebene ID instanziiert wurden. Die ebenfalls statische Methode 

setUniqueId(long) setzt den Zähler auf das Maximum des übergebenen Parameters und des 

aktuellen Zählerwerts. 

Diese Methode könnte von einer Komponente genutzt werden, die den Zähler über mehrere 

Objektbäume hinweg synchronisiert und somit die systemweite Eindeutigkeit der IDs gewährleistet. 

Dabei könnte diese zum Beispiel auf Multicastalgorithmen zurückgreifen, die eben dieses 

für die IDs zu versendender Nachrichten in einem Netzwerk sicherstellen [Mühlhäuser, 2005]. 

Ebenso wird jedem Spielobjekttyp bei der Konstruktion ein eindeutiger Bezeichner zugewiesen, 

GameObjectType implementiert daher die gleichen Methoden und Mechanismen. 

Daraus folgend ergibt sich die in Abbildung 6.4 gezeigte Modellierung. 

Der Baum der Spielobjekte und die Hierarchie der Typen sollen über eine gemeinsame Schnittstelle 

verwaltet werden. Diese wird durch das Interface TreeManager definiert. Zunächst bietet 

dieses die Methoden get() und getType(), um Zugriff auf das durch die ID referenzierte 

Spielobjekt oder den Typ zu erhalten. Desweiteren deklariert das Interface Methoden 

zum Einfügen (insert(String, GameObject) und insertType(String, GameObjectType)) 

und Löschen (remove(String) und removeType(String)) von Entitäten sowie zum Ersetzen 

(replace(String, GameObject)) eines Teilbaums der Spielobjektstruktur. 

Das Spielobjekt wird informiert, wenn es aus dem Baum entfernt wird. Dies erlaubt es, zu diesem 

Zeitpunkt eine mit Hilfe der Methode setDeleteAction() definierte Aktion auszuführen. Das 



id:String uniqueId:long+getId():String +setUniqueId(uniqueId:long) +getUniqueId():long GameObjectType 

id:String +parent type 

GameObject 

Abbildung 6.4: UML Diagramm der Anordnung von Objekten 

parent:GameObject children:List type:GameObjectType +getId():String +setUniqueId(uniqueId:long) uniqueId:long 

+adChild(child:GameObject) +adChild(child:GameObject,position:int) +removeChild(child:GameObject) +setParent(parent:GameObject) +getParent():GameObject +getUniqueId():long 

ermöglicht dem Spieldesigner, auf das Entfernen eines Objektes zu reagieren. Diese Aktion wird 

allerdings nur einmal angestoßen und existiert nicht über mehrere Spieliterationen hinweg. 

Zur Verbesserung der Leistung der genannten Mechanismen – denn das Suchen nach einem 

Objekt kann hohe Laufzeitkosten bedeuten – wird eine Schnittstelle für einen Zwischenspeicher 

(TreeCache) für Spielobjekte definiert, dessen konkrete Implementierungen von Realisierungen 

des TreeManager Interfaces genutzt werden können. Dieses definiert Methoden, um Spielobjekte 

in den Cache zu legen (put(GameObject)), solche zu entfernen (remove(String)) und auf 

diese zuzugreifen (get(String) und has(String)). Diese Komponente bietet die Möglichkeit, 

auf häufig frequentierte Spielobjekte schneller zuzugreifen, da das Durchsuchen des gesamten 

Baums teilweise erspart bleibt. 

Beispielimplementierungen dieser Interfaces werden in Kapitel 7.1 vorgestellt. Die nächste Stufe 

der Modellierung lässt sich aus Abbildung 6.5 entnehmen. 

Dadurch, dass sowohl die Baumverwaltung als auch der Cache als Interfaces definiert sind, lassen 

diese sich beliebig austauschen und das System somit flexibel erweitern. 

6.2 Dynamik zur Laufzeit 

Wie wir in den vorherigen Sektionen gesehen haben, können Spielobjekte, Aktionen und Typen 

data-driven definiert sein. Somit lassen sich diese zur Laufzeit nachladen, indem einfach 

Instanzen der entsprechenden Klassen erstellt werden. Für diese Funktionalität bedarf es keiner 

weiteren Implementierung. 



TreManager +get(id:String):GameObject +getType(id:String):GameObjectType «interface» 

+insert(parent:String,obj:GameObject) 

TreCache +get(id:String):GameObject +put(obj:GameObject) verwendet «interface» 

+remove(id:String) +has(id:String):bolean +insert(parent:String,obj:GameObject,position:int) +insertType(parent:String,type:GameObjectType) +remove(id:String) +removeType(id:String) +replace(what:String,with:GameObject) 

0.* 0.* GameObjectType +setDeleteAction(action:Action) GameObject 

Abbildung 6.5: UML Diagramm des TreeManager 0.* 

In der vorgestellten Modellierung werden Abfragen in der Vererbungshierarchie der Typen nicht 

zwischengespeichert. Das heißt, Typen von Spielobjekten lassen sich zur Laufzeit austauschen 

sowie ändern, so dass sich damit auch die Eigenschaften der Spielobjekte für diese Typen ändern. 

Nach der Taxonomie bietet das System in diesem Punkt also die größtmögliche Flexibilität. 

6.3 Kommunikation 

In den folgenden Sektionen wird zum einen die Möglichkeit entwickelt, mehrere Instanzen des 

Systems, die in unterschiedlichen Prozessen laufen, zu synchronisieren, zum anderen werden 

weiteren Subsystemen eines Spiels Schnittstellen zur Kommunikation mit dem Objektmodell 

angeboten. 

6.3.1 Initiative 

In Kapitel 3.3.1 wurden zwei Wege eingeführt, mit denen modelliert werden kann, bei welchem 

Kommunikationsteilnehmer die Initiative zum Austausch von Änderungen liegt. Zum einen ist 

dies das Prinzip des Polling, zum anderen die Publish/Subscribe Methode. Letztere reduziert 

den Nachrichtenverkehr auf das Nötige und bietet somit vor allem in Hinblick auf die aufgestellten 

Anforderungen zur Netzwerkkommunikation, die eine geringe Auslastung der Bandbreite 

fordern, die geeignetere Umsetzung. 

Die Träger von Informationen, die für andere Subsysteme oder Netzwerkteilnehmer von Interesse 

erscheinen, sind in diesem System zum einen natürlich die Spielobjekte, zum anderen deren 



Typen. Dabei können grundsätzlich jeweils drei unterschiedliche Nachrichten für jede Hierarchie 

auftreten: Das Hinzufügen, Löschen sowie Modifizieren eines Objekts. Weiterhin könnten 

Komponenten an der Ausführung von Aktionen interessiert sein. Es können also genau diese 

Nachrichten empfangen werden. Hierzu wird die Schnittstelle GameObserver festgelegt, welche 

von Interessenten implementiert werden muss und die genannten Methoden definiert, die jeweils 

als Parameter die betroffenen Objekte entgegennehmen: 

• onAdd(GameObject) 

• onChange(GameObject) 

• onDelete(GameObject) 

• onAdd(GameObjectType) 

• onChange(GameObjectType) 

• onDelete(GameObjectType) 

• onActionApplied(GameObject, Action) 

Die Frage, die zu klären bleibt, ist, wie die Objekte der Klassen, die GameObserver implementieren, 

ihr Interesse an Änderungen anmelden und wann und wie solche Änderungen propagiert 

werden. 

Sowohl innerhalb der Objekte des GameObject als auch des GameObjectType werden an Änderungen 

des spezifischen Objekts interessierte Entitäten in einer Liste gehalten, die mit Hilfe 

der Methoden addObserver(GameObserver) und removeObserver(GameObserver) manipuliert 

werden kann. 

Für die Spielobjekte gilt, dass erstere den übergebenen GameObserver nicht nur in die Liste des 

aufgerufenen Spielobjekts sondern auch die seiner Kinder einfügt. Analog entfernt zweitere den 

Beobachter aus der eigenen Liste und denen der Kinder. Wenn explizit nur die Liste des angesprochenen 

Objekts angepasst werden soll, können die Methoden addObserverOnlyThisNode() 

und removeObserverOnlyThisNode() genutzt werden. 

In der Klasse GameObject werden folgende Elemente auf Änderungen überwacht: 

• Die Liste der Kinder 

• Die Liste der ausführbaren Aktionen 

• Die Liste der zur Zeit ausgeführten Aktionen 

• Die Liste Zustandsobjekte und deren Werte 

• Der Verweis auf den Vaterknoten 

• Der Verweis auf den Typ 



Jede Modifikation der genannten Entitäten hat einen oder mehrere Aufrufe der internen Methoden 

objectAdded(), objectDeleted(), objectChanged() und actionApplied() zur Folge. 

Letztere wird ausgeführt, wenn eine Aktion aus der Liste der ausführbaren in die Liste der ausgeführten 

Aktionen verschoben wird. 

Diese Methoden wiederum rufen ihren Gegenpart in dem GameObserver Interface ihrer Beobachter 

auf. Das Element, welches geändert wurde, wird mit Hilfe eines sogenannten Dirty Flags 

markiert. 

Über die Änderungen an den Werten seiner Zustandsobjekte wiederum wird ein Spielobjekt mit 

Hilfe des Java-eigenen Observer-Mechanismus informiert. Dazu implementiert GameObject das 

Interface Observer und State erbt von der abstrakten Klasse Observable. 

Mit Hilfe der in Kapitel 6.1.2 vorgestellten Methode sleep() kann verhindert werden, dass ein 

Spielobjekt Nachrichten an seine Beobachter sendet. Dieser Zustand wird durch einen Aufruf 

von unsleep() wieder aufgehoben. 

Analog dazu in Bezug auf die Verwaltung der Beobachter verhält sich GameObjectType, das 

hingegen nur folgende seiner Elemente auf Modifikationen zu beobachten hat: 

• Den Verweis auf den Vaterknoten in der Vererbungshierarchie 


• Die Liste der Zustandsobjekte und deren Werte 


Basierend auf den Annahmen, dass Typen nur selten geändert werden und ein Beobachter nur 

an der gesamten Typhierarchie interessiert ist, wird gegenüber der Beobachtung des Spielobjektbaums 

eine Vereinfachung vorgenommen. Bei der Änderung eines Typs wird dies intern bis zum 

Wurzelknoten hochpropagiert, wobei der geänderte Typ mitgereicht wird. So braucht ein interessierter 

Beobachter lediglich den Wurzelknoten zu beobachten und die Verwaltung der Beobachter 

in dieser Hierarchie ist weniger aufwändig. Eine Unterscheidung zwischen der bloßen Beobachtung 

eines Einzelknotens und der Beobachtung eines Knotens und seiner Kinder, wie sie für die 

Spielobjekthierarchie umgesetzt ist, wird hier überflüssig. Damit enfällt für GameObjectType 

die Unterscheidung zwischen dem Hinzufügen eines Beobachters zu einem einzelnen Knoten 

der Hierarchie oder einem ganzen Teilbaum. Aufrufe von addObserver(GameObserver) oder 

removeObserver(GameObserver) werden bis zum Wurzelknoten durchgereicht und greifen nur 

auf dessen Beobachterliste zu. 

Obwohl die Klassen GameObject und GameObjectType damit eine scheinbar nahezu identische 

Funktionalität implementieren, wird auf die Auslagerung in eine gemeinsame Oberklasse verzichtet, 

denn das Verhalten der Methoden zum Hinzufügen und Entfernen von Objekten zu den 

Beobachterlisten zwischen den beiden Klassen ist zu unterschiedlich, als dass eine gemeinsame 

Basis gefunden werden könnte. 

Zudem hätte die Auslagerung dieser Funktionalität in eine Oberklasse die Folge, dass die Methoden 

des Interfaces GameObserver nicht mehr Objekte der exakten Laufzeitklasse empfangen 

könnten, sondern nur Objekte des Typs dieser Oberklasse. Damit würden zur Laufzeit teure 



Typüberprüfungen nötig werden. Eine Möglichkeit, dies zu umgehen, wäre der Einsatz des Visitor 

Entwurfmusters [Gamma, 1997], so dass eine Implementierung des GameObserver zunächst 

nur die Typen der Oberklasse entgegennimmt, dann aber die gegebenen Objekte besucht und 

somit die Laufzeitklasse derselben erfährt. Auch diese Umsetzung wird nicht verfolgt, weil damit 

GameObserver konkretes Verhalten implementieren müsste und nicht mehr als Interface sondern 

nur noch als abstrakte Klasse definiert werden könnte, was die Integration in bestehende Projekte 

erschwert. Auch hier bestünde weiterhin das Problem einer fehlenden Schnittmenge gleichen 

gemeinsamen Verhaltens der beiden Klassen. Infolgedessen wird auch auf eine Implementierung 

mit Hilfe des Java-eigenen Observer-Mechanimus verzichtet. 

Damit ergibt sich die in Abbildung 6.6 dargestellte Modellierung des Observermechanismus. 

«interface» 

GameObserver +onAd(obj:GameObject) +onChange(obj:GameObject) +onDelete(obj:GameObject) +onAd(type:GameObjectType) +onChange(type:GameObjectType) +onDelete(type:GameObjectType) +onActionAplied(obj:GameObject,action:Action) 

0.* benachrichtigt 0.* 0.* +update(o:Observable,obj:Object) «interface»Observer 

Observable 

observers:List +removeObserver(o:GameObserver) +adObserverOnlyThisNode(o:GameObserver) GameObject 

+removeObserverOnlyThisNode(o:GameObserver) +adObserver(o:GameObserver) 

GameObjectType +removeObserver(o:GameObserver) observers:List +adObserver(o:Observer) +removeObserver(o:Observer) benachrichtigt 

+adObserver(o:GameObserver) benachrichtigt 

benachrichtigt State 

Abbildung 6.6: UML Diagramm des Observermechanismus 



6.3.2 Änderungsübermittlung 

Um den flexiblen Einsatz des Systems zu gewährleisten, soll dieses beide der in Kapitel 3.3.2 

vorgestellten Methoden zur Übermittlung von Änderungen implementieren. Die Grundlage hierfür 

wurde bereits in der vorherigen Sektion gelegt. Das Interface GameObserver beschreibt eine 

Komponente, die zum einen Nachrichten über die Änderung von Spielobjekten und deren Typen 

sowie über die Ausführung von Aktionen empfängt. Der nächste Schritt ist, diese für den Versand 

zu anderen Prozessen aufzubereiten. Dazu sollen zunächst nur die Daten herausgefiltert werden, 

die einer Synchronisierung bedürfen, um Ressourcen wie vor allem die Netzwerkbrandbreite zu 

schonen. 

Basierend auf den vorgestellten Dirty Flags definieren die beiden Klassen GameObject und 

GameObjectType die Methoden isDirty() und getDelta(). Während erstere überprüft, ob innerhalb 

eines Objekts Änderungen vorliegen, gibt zweitere eine Instanz der Klasse DeltaObject 

beziehungsweise DeltaType zurück, die genau diese Änderungen beinhaltet. Nachdem ein solches 

Objekt, das die Differenz zweier Zustände eines Spielobjekts oder Typs beschreibt, extrahiert 

wurde, können die Dirty Flags des Ausgangsobjekts mit Hilfe der Methode makeClean() 

zurückgesetzt werden. DeltaObject enthält die folgenden Felder: 

• Die ID des Objekts 

• Die zur Zeit größte für Spielobjekte automatisch vergebene ID 



• Die Liste der zur Zeit ausgeführten Aktionen 

• Die Liste der Zustandsobjekte 

• Den Verweis auf den Typ des Objekts 

• Den Verweis auf den Vaterknoten in der Spielobjekthierarchie 

DeltaObjectType enthält die folgenden Felder: 

• Die ID des Typs 

• Die zur Zeit größte für Typen automatisch vergebene ID 

• Den Verweis auf den Vaterknoten in der Vererbungshierarchie 

• Die Liste der Kinder in der Vererbungshierarchie 

• Die Liste der Zustandsobjekte 




+isDirty():bolean +getDelta():DeltaObject GameObject 

GameObjectType +getDelta():DeltaType +makeClean() +isDirty():bolean 

erstelt erstelt parentparent +makeClean() parent type 

children:List actions:List DeltaType id:String DeltaObject uniqueId:long 

+setId(id:String) +getUniqueId():long states:List id:String uniqueId:long children:List posibleActions:List curentActions:List states:List parent:GameObject type:GameObjectType +getId():String +setId(id:String) parent:GameObjectType +getId():String 

+setUniqueId(uniqueId:long) +getUniqueId():long +setUniqueId(uniqueId:long) etali etali 

Abbildung 6.7: UML Diagramm der Deltaobjekte 

Damit ergibt sich die in Abbildung 6.7 gezeigte Klassenmodellierung. 

Bevor Instanzen der Klassen GameObject, GameObjectType, DeltaObject und DeltaType sowie 

Aktionen mit anderen Subsystemen oder sogar Prozessen ausgetauscht werden können, bedarf 

es der Überführung in eine geeignete Repräsentation und der Rückgewinnung der Daten aus 

derselben. Während der Versand über das Netzwerk auf einen Bytestrom angewiesen ist, wird 

eine Datenbank üblicherweise mit SQL-Befehlen angesprochen. Oft ist eine direkte Umsetzung 

von der objektorientierten Darstellung in eine andere nicht möglich und es benötigt mehrerer 

Zwischenschritte für diese Aufgabe. Der in Kapitel 5.3 angedeutete Ansatz der Filter soll von 

dem System in einer flexibleren Form umgesetzt werden. Dazu wird eine Reihe von Schnittstellen 

definiert, die sich in die Kategorien Filter und Transformatoren unterteilen lassen. Erstere 

markieren Klassen, die Daten in einer bestimmten Repräsentation entgegennehmen, zweitere 

Klassen, die Daten in eine bestimmte Repräsentation überführen. Zum Beispiel wird ein 

StringFilter definiert, der eine Methode filter(String) anbietet, sowie ein Transformator 

StringTransformator, der die Methode set(StringFilter) deklariert. Während ersterer also 

eine Zeichenkette entgegennimmt, wird zweiter eine Zeichenkette liefern und an einen weiteren 

passenden Filter übergeben. Weitere vorgegebene Filter und Transformatoren sind zum Beispiel: 

ByteFilter: Übernimmt einen Bytestrom. 



DeltaFilter: Übernimmt DeltaOject und DeltaType Objekte in add(), change() und 

delete() Methoden sowie Aktionen. Durch die Unterscheidung der Methoden lässt sich 

die Art der Nachricht in der neuen Repräsentation konservieren. 

GameObjectFilter: Übernimmt GameObject und GameObjectType Objekte. 

ByteTransformator: Liefert einen Bytestrom und damit den Eingang für einen ByteFilter. 

DeltaTransformator: Liefert den Eingang für einen DeltaFilter. 

GameObjectTransformator: Liefert den Eingang für einen GameObjectFilter. 

Dabei ist auch explizit vorgesehen, dass eine konkrete Implementierung sowohl einen Filter 

als auch einen Transformator implementieren kann. Somit ließen sich Ketten bilden, die aus 

der objektorientierten Repräsentation der Daten eine andere gewinnen und umgekehrt. Durch 

das Definieren der Schnittstellen lassen sich Filter und Transformatoren beliebig miteinander 

verketten, so dass deren leichte Austauschbarkeit und die Erweiterbarkeit bestehender Filterund 

Transformatorketten gewährleistet ist. Soll das System hingegen auf die beste Leistung 

ausgelegt sein, ließen sich solche Ketten natürlich auch auf ein einziges Glied reduzieren. 

Die Verwendung der Filter für unterschiedliche Zwecke wie die Netzwerkkommunikation oder 

Persistenz wird in Kapitel 7.2 dargestellt. 

6.3.3 Kompression und Quality of Service 

Da die beiden hier zu behandelnden Aspekte nicht direkt Teil eines Objektmodells sind, lassen 

sie sich nur indirekt unterstützen. Eine Implementierung derselben kann nicht gegeben werden. 

Dennoch liefern beide hilfreiche Ansätze zur Steuerung des Netzwerkverkehrs zu Gunsten der 

Bandbreite. Das System soll deshalb dem Entwickler die Möglichkeit bieten, zum einen Daten, 

die versendet werden sollen, mit für die Kommunikation wichtigen Informationen zu versehen, 

und zum anderen, diese Informationen an geeigneter Stelle auszuwerten und zum Beispiel für 

die Priorisierung oder Komprimierung von Nachrichten zu verwenden. 

Die in der vorigen Sektion dargestellten Filter und Transformatoren bezeichnen unter anderem 

die Schnittstelle zwischen Objektmodell und Netzwerkschicht. Dort kann entschieden werden, 

wann oder wie der Versand von Daten stattfindet. 

Die Steuerung dieser Entscheidungen soll über Eigenschaften erfolgen, die den zu versendenden 

Instanzen der Klassen GameObject, GameObjectType, State und Action gegeben werden. 

Es wird daher ähnlich zu der Klasse State eine abstrakte Klasse Property implementiert, 

die Paare von Zugriffsmethoden für unterschiedliche Datentypen definiert, die standardmäßig 

Ausnahmen werfen und deren Instanzen von dem Container Properties beinhaltet werden. 

Konkrete Implementierungen von Property überschreiben die Methoden, die mit dem von ihnen 

realisierten Datentyp korrespondieren. 

Die Klassen GameObject, GameObjectType und Action erben von der Klasse Properties, um 

deren Funktionalität anzunehmen. State enthält eine Instanz dieser Klasse, da es bereits von 

Observable erbt. 

Ebenso wie die Zustandsobjekte lassen sich die Eigenschaften data-driven definieren aber auch 

zur Laufzeit modifizieren. Folgende Datentypen werden unterstützt: 



Integer: ein ganzzahliger Wert 

Double: eine Gleitkommazahl 

Boolean: ein Bool’scher Wert 

String: eine Zeichenkette 

Es ist explizit vorgesehen, dass diese Eigenschaften nur lokal existieren und nicht wie die State 

Objekte über Prozesse hinweg synchronisiert werden. So kann jeder Teilnehmer seine eigene 

Netzwerksteuerung implementieren. Zum Beispiel könnten Aktionen mit einer Integer-Property 

versehen werden, die deren Priorität bei der Versendung über das Netzwerk bestimmt. Ein 

entsprechender Filter könnte dann dafür Sorge tragen, dass zunächst dringliche Aktionen zum 

Beispiel vor Chatnachrichten versendet werden. Damit ergibt sich die in Abbildung 6.8 gezeigte 

Modellierung. Properties 0.* Property 

6.4 Überblick 

values:Map 

+setAsInt(value:int) +setAsDouble(value:double)etali +setProperty(name:String,p:Property) +getProperty(name:String):Property +getAsInt():int +getAsDouble():double 

Action GameObject GameObjectType 

+setProperty(name:String,p:Property) +getProperty(name:String):Property props:Properties State 

IntProperty 

+props 

value:int+getAsInt():int 

value:double +setAsInt(value:int) 

+getAsDouble():double DoubleProperty 

Abbildung 6.8: UML Diagramm der Property Objekte +setAsDouble(value:double) 

In diesem Kapitel wurde ein Objektmodell entworfen, das auf einer Baumstruktur der Spielobjekte 

basiert. Diese lässt sich über eine einzelne Schnittstelle verwalten. Spielobjekte können 

typisiert sein und durch als Komponenten modellierte Aktionen mit Verhalten versehen werden. 

Diese drei Entitäten sind komplett in externen Datenquellen definierbar, so dass Spieldesigner 

unabhängig von den Programmierern arbeiten können. 

Mit Hilfe der Filter und Transformatoren kann sowohl eine Persistenzschnittstelle implementiert 



als auch eine Brücke zu der Netzwerkschicht geschlagen werden. Es ist vorstellbar, dass mit Hilfe 

dieses Prinzips auch weitere Subsysteme eines Spiels mit dem Objektmodell kommunizieren. 

Änderungen des Systems werden durch das Observer Entwurfsmuster propagiert, welches nur 

die nötigen Nachrichten verschickt und damit den Overhead reduziert. 

Zur Steigerung der Leistung werden unterschiedliche Mechanismen angeboten. Hier seien beispielhaft 

noch einmal der TreeCache und die Properties zur Steuerung des Netzwerkverkehrs 

genannt. 

Durch das Implementieren gegen Schnittstellen lassen sich weite Teile des Systems austauschen. 

Damit wird die Erweiterbarkeit und Wiederverwendbarkeit desselben unterstützt. 

Abbildung 6.9 liefert einen Überblick des Gesamtsystems, aus Abbildung 6.10 ergeht die Einordnung 

in die Taxonomie. 



TreCache TreManager 

State liestundändert 

Action erbtvon GameObjectType GameObject 

erstelt erstelt benachrichtigen wirdeingepflegtin wirdeingepflegtin 

DeltaType DeltaObject GameObserver 

Abbildung 6.9: Überblick über die entwickelte Architektur 

werdeneingespeistin erstelt 

*Transformator *Filter 



Taxonomie 


Daten 

Modellierung 


Definition 

Quelltext 

Textdateien 

Binärdateien 

XML Dateien 

Skriptsprache 

Datenbanken 

Verhalten 

Modellierung 


Definition 

Quelltext 

Skriptsprache 

Typen 

Modellierung 

Muster 

Definition 

Quelltext 

data-driven 

Vererbung 

Konzept 

Einfach 

Gegenstand 

Daten 

Verhalten 

Objektordnung 






Typen veränderbar 

Kommunikation 

Initiative 

Publish/Subscribe 


Delta Updates 

Aktionen 

Kompression 


Abbildung 6.10: Einordnung des von uns entwickelten Systems in die Taxonomie 


Kapitel 7 

Integration 

I just invent, then wait until man 

comes around to needing what I’ve 

invented. 

R. Buckminster Fuller 

Im letzten Kapitel wurde das Design sowie die Implementierung beschrieben. In diesem soll 

nun die Frage geklärt werden, wie das entwickelte Objektmodell in ein bestehendes Projekt zu 

integrieren ist. 

Um das zu erreichen, sollte zunächst evaluiert werden, ob die gegebenen Referenzimplementierungen 

der Baumverwaltungsklassen ausreichend sind oder ob diese an abweichende Anforderungen 

angepasst werden sollten. Wie die dazugehörigen Schnittstellen derzeit implementiert 

sind und was zu beachten gilt, ist im Abschnitt 7.1 beschrieben. Dort wird ebenfalls erläutert, 

wie die Komponente, die für die Visualisierung der einzelnen Spielobjekte zuständig ist, mit 

dem System interagieren kann. 

Nachfolgend wird dargelegt, wie mehrere Instanzen des Objektmodells miteinander kommunizieren 

können und welche Möglichkeiten sich bieten, den aktuellen Zustand des Systems persistent 

zu speichern sowie mit Hilfe externer Quellen die Daten des Systems zu instanziieren. Wie dies 

mit Hilfe der Filter zu realisieren ist, wird im Abschnitt 7.2 geklärt. 

Abschließend wird dann die Implementierung der Spiellogik – also das Verhalten der Spielobjekte 

– beschrieben. Diese arbeitet, wie im vorigen Kapitel beschrieben, nur mit Aktionen, um 

Spielobjekte zu verändern. Wie das im Detail geschieht, wird im Abschnitt 7.3 gezeigt. 

7.1 Objekthierachien 

Wie kann eine Implementierung des TreeManager Interfaces aussehen? 

Eine Referenzimplementierung dieser Schnittstelle ist die Klasse DefaultTreeManager. Diese 

beinhaltet den Wurzelknoten der Objekt- als auch den der Typhierarchie sowie einen Cache, 

der die Schnittstelle TreeCache implementiert. In der Annahme, dass die Spielobjekte einer

VII. Integration 67 

sehr viel höheren Dynamik unterliegen als die Typen, werden in diesem nur erstere gehalten. 

Die DefaultTreeManager Klasse unterstützt lediglich eine Objekt- sowie eine Typhierarchie pro 

TreeManager Instanz. 

Die Methode zum Erhalten von Spielobjekten prüft zunächst, ob das angefragte Objekt im 

Cache enthalten ist. Trifft dies nicht zu, wird es mit Hilfe einer Breitensuche gesucht. Nachdem 

das gewünschte Objekt gefunden wurde, wird es dem Cache hinzugefügt. Die Knoten der Objekthierarchie, 

die bei der Breitensuche besucht werden, aber nicht dem gesuchten entsprechen, 

werden nicht hinzugefügt; dies kann bei der Implementierung des Caches von Bedeutung sein. 

Für Spielobjekttypen funktioniert dies analog, mit der Einschränkung, dass kein Cache genutzt 

wird und somit auch keine Anfrage an einen solche erfolgen muss. 

Beim Hinzufügen zu dem Baum muss, unabhängig davon, ob es sich um die Objekt- oder 

Typhierarchie handelt, sichergestellt werden, dass der einzufügende Knoten nicht schon darin 

existiert. Wäre dies der Fall, würde das abermalige Hinzufügen zu Inkonsistenzen führen, da 

dieser dann zeitgleich in den Listen der Kinder zweier unterschiedlicher Knoten stehen würde. 

Deswegen wird, bevor der Knoten eingefügt wird, kontrolliert, ob dieser oder eines seiner 

Kinder bereits vorhanden ist. Diese Überprüfung läuft rekursiv, so dass alle Knoten des hinzuzufügenden 

Teilbaums untersucht werden. Da diese Implementierung mit Hilfe von get(String) 

ein Ergebnis sucht, zeigt sich, dass eine effiziente Implementierung dieser Methode auch die 

Geschwindigkeit der Einfügeoperationen signifikant verbessern kann. 

Beim Löschen eines Knotens muss sichergestellt werden, dass nicht nur dieser entfernt wird, 

sondern auch dessen Kinder. Wenn ein Knoten entfernt wird, wird auf dessen Elternknoten die 

removeChild(GameObject) Methode ausgeführt. Durch diesen Aufruf werden die Nachrichten 

für die Observer generiert sowie die Verbindung zwischen Vater- und Kindknoten vollständig 

aufgelöst. Dieser Aufruf wird rekursiv durch den gesamten Teilbaum propagiert und löst alle 

Referenzen zwischen den Knoten zueinander. 

Wie kann eine Implementierung des TreeCache Interface aussehen? 

Eine Referenzimplementierung dieser Schnittstelle ist die Klasse DefaultTreeCache. Sie setzt 

den Zwischenspeicher mit Hilfe der Java-eigenen HashMap um. Alle Objekte, die mit Hilfe 

der Einfügeoperation put(GameObject) zum TreeManager hinzugefügt werden, werden auch 

in dieser Datenstruktur abgelegt. Eine Suche mittels get(String) sowie das Löschen mittels 

remove(String) lassen sich dann an die Methoden der HashMap delegieren. Diese ist sehr effizient 

implementiert, wovon auch der Zwischenspeicher profitiert. 

Problematisch wird es allerdings beim Speicherbedarf. Da ein Spiel aus sehr vielen Spielobjekten 

bestehen kann, ist dieser ein nicht zu vernachlässigender Punkt. Eine Möglichkeit, hier 

Abhilfe zu schaffen und dabei trotzdem die Effizienz der HashMap zu erhalten, wäre, nur die am 

häufigsten abgefragten Objekte zu speichern. 


68 VII. Integration 

Wie kann der Lebenszyklus eines Objekts modelliert werden? 

Wichtig für den Lebenszyklus sind in der Praxis zumeist drei Fragestellungen: 

• Wie kann eine Aktion direkt nach der Erstellung eines Objekts ausgeführt werden? 

• Wie kann eine Aktion direkt vor der Löschung eines Objekts ausgeführt werden? 

• Wie kann ein Objekt schlafen gelegt werden, so dass keine Aktionen mehr ausgeführt 

werden? 

Die erste Anforderung kann dadurch erfüllt werden, dass eine Aktion vor der Einfügung des 

Spielobjekts in den Baum zu currentActions hinzufügt wird. Dadurch wird diese nach dem 

Hinzufügen durch einen Aufruf von doActions auf dem Spielobjekt ausgeführt, was üblicherweise 

in der ersten nachfolgenden Iteration des Spiels geschehen würde. 

Die zweite Problemstellung wird von GameObject direkt unterstützt. Die mit der Methode 

setDeleteAction(Action) gesetzte Aktion wird beim Entfernen des Objekts aus dem Baum 

ausgeführt. Diese wird allerdings nur noch genau einmal angestoßen. 

Auch das letzte Problem wird direkt durch die sleep() Funktion unterstützt. Sobald das Objekt 

in den Schlaf versetzt wurde, werden weder Aktionen ausgeführt noch irgendwelche Observernachrichten 

verschickt. Um das Objekt wieder zu aktivieren, wird unsleep() angeboten. 

Wie kann ein Spielobjekt direkt mit der Anzeigekomponente kommunizieren? 

Die Spielobjekte enthalten nur Daten und prinzipiell keinerlei Informationen darüber, ob und 

wie sie dargestellt werden sollen. Um ein Objekt mit einer Anzeigekomponente zu verbinden, 

existiert die Schnittstelle Form, die das Interface GameObserver erweitert und keine weiteren 

zusätzlichen Methoden definiert. Es handelt sich also zunächst um ein reines Marker Interface 1 . 

Das GameObject bietet zwei Zugriffsmethoden, um so ein Form-Objekt mit einem Spielobjekt 

zu assoziieren oder aus dem Spielobjekt zu erhalten. Beim Hinzufügen wird das Form Objekt 

ebenfalls als Beobachter des Spielobjekts eingetragen, um angemessen auf etwaige Änderungen 

dessen Zustandes reagieren zu können. 

Die Funktionalität der Darstellung ist stark abhängig von dem Projekt, weswegen die Schnittstelle 

zunächst leer ist. Wenn das Objektmodell verwendet wird, sollte dieses Interface mit 

weiteren Methoden gefüllt werden. Beispielsweise könnte eine Methode render() hinzugefügt 

werden, die in jeder Iteration der Spielschleife auf den Form-Objekten, die aus den in der Nähe 

des Spielers befindlichen Spielobjekten gewonnen wurden, aufgerufen wird, um diese darzustellen. 

1 http://en.wikipedia.org/wiki/Marker_interface_pattern 



7.2 Filter 

Wie kann ein Filter/Transformator implementiert werden? 

Ein Filter muss eine der Filterschnittstellen implementieren. Je nach Typ hat das Interface 

eine oder mehrere Funktionen, die Objekte des entsprechenden Typs entgegennehmen. Sollen 

die Daten, die übergeben werden, an andere Filter weitergegeben werden, sollte zusätzlich ein 

Transformator Interface implementiert werden. Über dieses kann ein Filter erhalten werden, an 

den die Daten weitergereicht werden, nachdem sie bearbeitet wurden. 

Wie so etwas implementiert werden könnte, zeigt Listing 7.1, in dem ein Filter implementiert ist, 

der eine Zeichenkette mit ROT13 2 kodiert und an den in der Variable nextFilter gespeicherten 

Filter weiterreicht. 

1 public class ROT13Filter implements StringFilter , 

StringTransformer { 

2 private StringFilter nextFilter ; 

3 

4 public void filter ( String s) { 

5 StringBuffer buf = new StringBuffer (s. length ()); 

6 for (char c : s. toCharArray ()) { 

7 buf.append (((c + 13) % 256)); 

8 } 

9 if ( nextFilter != null) { 

10 nextFilter . filter (buf.toString ()); 

11 } 

12 } 

13 

14 public void set( StringFilter sf) { 

15 nextFilter = sf; 

16 } 

17 } 

Listing 7.1: ROT13 Filter 

Wie können mehrere Filter zu einer Filterkette verbunden werden? 

Wie im vorigen Abschnitt beschrieben, kann dies über die Transformatoren und deren Methode 

set() geschehen. Wird diese mit einem Filter als Parameter aufgerufen, wird dieser intern 

gespeichert. Nachdem die eigene Filteraktion durchgeführt wurde, werden die Daten an diesen 

weitergegeben. Den Startpunkt der Filterkette bildet ein Filter, der nur die Transformatorschnittstelle 

implementiert. Den Endpunkt hingegen bildet ein Filter, der die Transformatorschnittstelle 

eben genau nicht implementiert. 

Beispielsweise müsste ein Objekt, das die über das Netzwerk empfangenen Daten eines anderen 

2 http://de.wikipedia.org/wiki/ROT13 



Netzwerkteilnehmers an einen Filter übergibt, nur den Transformator implementieren. Von dort 

aus werden die Daten durch die Filterkette gereicht, bis sie am Ende der Kette eine Komponente 

erreichen, die die Daten in den Objektbaum einpflegen könnte. Diese bräuchte nur ein 

Filterinterface zu implementieren. 

Wie kann eine Filterkette zur persistenten Speicherung, 

Netzwerkkommunikation und zum Laden von Spielobjekten genutzt werden? 

Das Beispiel im vorigen Abschnitt deutet dies bereits an. Zur Netzwerkkommunikation werden 

zwei Filterketten definiert, eine für eingehende und eine für ausgehende Verbindungen. Bei 

ersterer bildet ein Empfänger den Startpunkt der Transformatorkette. Der gelesene Bytestrom 

wird durch die Transformatoren nach und nach erst in Strings und dann in Objekte transformiert. 

Diese gelangen dann zum Ende der Kette, an dem sie ein Filter in die Objekthierarchien 

einpflegt. 

In die andere Richtung sieht es ganz ähnlich aus. Eine Änderung an der Hierarchie oder an 

bestimmten Teilen davon erfährt ein GameObserver, der gleichzeitig einen Filter beinhaltet. An 

diesen übergibt er die Delta Updates aus dem Baum, die nun durch mehrere Transformationen 

in einen Bytestrom umgewandelt werden. Das Ende der Kette bildet eine Komponente, 

die in das Netzwerk sendet. Die im einzelnen dazwischen eingesetzten Filter sind dabei stark 

vom jeweiligen Projekt abhängig. Beispiele wären Filter, die den Bytestrom mit Hilfe von GZIP 

oder BZIP2 komprimieren, weitere, die die Daten verschlüsseln, und wieder andere, welche die 

Objekte in eine XML Form oder eine beliebige anderen Definitionssprache transformieren. 

Es ist denkbar, eine Filterkette zu implementieren, die nicht Delta Updates sondern komplette 

Spielobjekte entgegennimmt, diese serialisiert und als Bytestrom auf einen persistenten Speicher 

schreibt. Hier könnten weitere Ideen entstehen; basiert die persistente Speicherung beispielsweise 

auf einem Datenbanksystem, muss der Bytestrom gar nicht erstellt werden. Es könnte ein SQL 

Befehl in einem StringFilter erstellt werden, welcher direkt an die Datenbank übergeben 

werden könnte. Mit einer umgekehrten Filterkette, die die Daten aus dem persistenten Speicher 

holt und in Spielobjekte umwandelt, ergibt sich automatisch ein Mechanismus, der das initiale 

Laden der Spielobjekte zu Spielbeginn erlaubt. 

7.3 Aktionen 

Wie können Aktionen ein Spielobjekt verändern? 

Ein Spielobjekt wird unter anderem dadurch modifiziert, dass seine Zustände geändert werden. 

Die Klasse GameObject enthält eine Möglichkeit, um zu überprüfen, ob ein State Objekt in 

einem Spielobjekt existent ist, sowie Methoden, dieses Zustandsobjekt zu ändern, zu entfernen 

oder ein neues hinzuzufügen. Eine Aktion beispielsweise, die die Lebenspunkte eines Charakters 

um 25 erhöht, inkrementiert – genauer ausgedrückt – einen Zustand, der einen Integer Wert enthält, 

um 25. Wenn dieser in unserem kleinen Beispiel „hitpoints“ hieße, müsste zunächst geprüft 



werden, ob ein State Objekt mit diesem Namen in dem Spielobjekt vorhanden ist. Falls dies 

gegeben ist, wird dieser aus dem Spielobjekt angefordert und sein Wert angepasst. Dazu wird 

dieser mit Hilfe der passenden Zugriffsmethode extrahiert, verändert und wieder gespeichert. 

Da auf Objekte in Java über Referenzen verwiesen und somit direkt auf das Zustandsobjekt des 

Spielobjekts zugegriffen wird, ist ein erneutes explizites Setzen des Zustands nicht nötig. Das 

Objekt wird über den in Kapitel 6.1.1 beschriebenen Mechanismus über die Änderung seines 

Zustands informiert. Wie eine Methode in einer Aktion zum Ändern eines Zustands aussehen 

könnte, zeigt Listing 7.2. Diese Methode wird aus doAction() aufgerufen und erhält ein Zielobjekt 

als Parameter. Sollte das Ziel eine Menge von Objekten sein, wird diese Methode auf jedes 

Objekt einzeln angewandt. 

1 public void doAction () { 

2 GameObject s = getTarget (); 

3 if (s == null) { 

4 for ( GameObject t : getTargetSet ()) { 

5 increase (t); 

6 } 

7 } else { 

8 increase (s); 

9 } 

10 GameObject d = getSource (); 

11 d. deactivateAction (this.getName ()); 

12 } 

13 

14 private void increase ( GameObject s) { 

15 if (s != null) { 

16 if (s. hasState (" hitpoints ")) { 

17 try { 

18 int hp = s. getState (" hitpoints "). getAsInt (); 

19 hp += 25; 

20 s. getState (" hitpoints "). setInt (hp); 

21 } catch ( StateTypeException e) { 

22 return ; 

23 } catch ( OutOfBoundException e) { 

24 return ; 

25 } 

26 } 

27 } 

28 } 

Listing 7.2: Die IncreaseHP Aktion 



Welche Möglichkeiten existieren, um Aktionen zu implementieren, die mehrere 

Ticks dauern? 

Ein Tick ist eine Iteration der Hauptschleife des Spiels. Eine Aktion kann mehrere dieser Ticks 

in der currentActions eines Spielobjekts verbleiben. Während jedes Schleifendurchlaufs wird 

doAction() aufgerufen. Die Aktion könnte jedesmal dasselbe tun, oder, ähnlich einem Zustandsautomat, 

mehrere interne Zustände durchlaufen und dabei die Aktionslogik ändern. Für 

das im vorigen Abschnitt gegebene Beispiel würde das erste Verfahren dazu führen, dass mit 

jedem Tick der Zustand um 25 erhöht würde. Genausogut könnte die Methode aber auch so 

implementiert werden, dass in den ersten Aufrufen 25 Lebenspunkte hinzugefügt und danach 

langsam die Menge der hinzugefügten Lebenspunkte mit jeder weiteren Iteration dekrementiert 

würde, was ein Beispiel für das zweite Verfahren wäre. 

Wie kann eine Aktion eine andere starten oder beenden? 

Zum Aktivieren einer Aktion muss auf dem Spielobjekt, auf dem sie ausgeführt werden soll, die 

Methode activateAction() aufgerufen werden, die den Namen der Aktion sowie die Zielobjekte 

als Parameter erhält. Um a priori zu überprüfen, ob eine Aktion auf einem Spielobjekt 

ausführbar ist, kann hasAction(String) verwendet werden. Das Beenden verläuft analog mit 

der Methode deactivateAction(String). Damit sich eine Aktion selber beendet, muss sie sich 

auf dem Quellobjekt deaktivieren. Listing 7.3 zeigt, wie das realisierbar ist. 

1 protected void removeFromCurrentActionQueue () { 

2 GameObject g = getSource (); 

3 g. deactivateAction (this.getName ()); 

4 } 

Listing 7.3: Methode zum Beenden einer Aktion 

Wie kann eine Skriptsprache zur Definition der Aktionslogik verwendet werden? 

Eine Aktion kann beliebige Logik enthalten, demzufolge könnte dort auch ein Interpreter für 

eine Skriptsprache geladen werden. Eine Beispielimplementierung existiert für Lua und Tcl. Die 

LuaScriptAction baut auf das luajava 3 Paket, die Tcl-Variante wurde mit Hilfe des Tcl/Java 4 

Projekts umgesetzt. 

Der Einfachheit halber existiert eine abstrakte Klasse ScriptAction, die von Action erbt und 

zusätzlich weitere Methoden zur Verfügung stellt. Da Spieldesigner, die das Verhalten von Aktionen 

in der Skriptsprache definieren, nicht umfassende Kenntnisse im Programmieren haben 

müssen, sind in diesen Methoden häufig genutzte Arbeitsschritte ausgelagert, die dann aus den 

Skriptobjekten heraus aufgerufen werden könnten. Die im letzten Abschnitt vorgestellte Methode 

zum Beenden der Aktion ist dort beispielsweise definiert. 

3 http://www.keplerproject.org/luajava/ 

4 http://tcljava.sourceforge.net/ 



Listing 7.4 zeigt, wie die doAction() Methode der Klasse LuaScriptAction implementiert 

ist. Vor dem Aufruf des eigentlichen Lua Skripts werden einige Objekte auf den Stack des 

Lua-Interpreters gelegt. Die Variable luaCode enthält den auszuführenden Quelltext, der im 

Konstruktor von der LuaActionFactory gesetzt wird. Die übrige Logik der Aktion wird in Lua 

ausgeführt. 

1 public void doAction () { 

2 LuaState luaState = LuaStateFactory . newLuaState 

(); 

3 luaState . openBasicLibraries (); 

4 

5 try { 

6 // Add this action to the Lua script so that 

methods can be 

7 // accessed . 

8 luaState . pushString (" thisAction "); 

9 luaState . pushObjectValue (this); 

10 

11 // Add the source of this action . 

12 luaState . pushString (" sourceObject "); 

13 luaState . pushObjectValue ( getSource ()); 

14 

15 // Add the target of this action . 

16 luaState . pushString (" target "); 

17 luaState . pushObjectValue ( getTarget ()); 

18 

19 // Add the targetSet of this action . 

20 luaState . pushString (" targetSet "); 

21 luaState . pushObjectValue ( getTargetSet ()); 

22 } catch ( LuaException e) { 

23 luaState . close (); 

24 return ; 

25 } 

26 

27 luaState . doString ( luaCode ); 

28 luaState . close (); 

29 } 

Listing 7.4: Ausführung einer in Lua geschriebenen Aktion 


Kapitel 8 

Zusammenfassung und Ausblick 

Vollkommenheit entsteht 

offensichtlich nicht dann, wenn man 

nichts mehr hinzuzufügen hat, 

sondern wenn man nichts mehr 

wegnehmen kann. 

Antoine de Saint-Exupéry 

Das Ziel dieser Arbeit war, ein Objektmodell für Spiele zu entwickeln, das sich flexibel in 

unterschiedlichen Umgebungen einsetzen lässt. Als primäre Anforderungen wurden daher die 

Erweiter- und Wiederverwendbarkeit identifiziert. Besondere Rücksicht wurde auch darauf genommen, 

dass die Integration in ein Framework für Multiplayerspiele geplant ist. 

Um die relevanten Aspekte und deren Implementierungsmöglichkeiten zu bestimmen, wurde auf 

Basis bestehender Systeme und mit Hilfe von Literatur, die sich mit diesem Thema beschäftigt, 

eine Taxonomie erarbeitet. Diese erfasst das Themengebiet mehrdimensional und kann somit 

auch verwandten Arbeiten dienlich sein. 

Die Taxonomie sowie die aufgestellten Anforderungen bildeten die Basis zur Entwicklung der 

Architektur des Systems. Dieses zeichnet sich vor allem durch die leichte Austauschbarkeit seiner 

Komponenten aus, wodurch zum Beispiel die Kommunikation des Objektmodells mit anderen 

Subsystemen oder anderen Instanzen desselben flexibel an verschiedene Umgebungen anpassbar 

ist. Die Elemente, die den Spielinhalt bilden, lassen sich über vorgestellte Methoden in externen 

Datenquellen definieren, so dass die Entwicklung derselben unabhängig von dem Quelltext des 

Projekts erfolgen kann. Dies erleichtert zum einen den Spieldesignern ihre Arbeit und ermöglicht 

zum anderen die parallele Umsetzung des Systems und des Spielinhalts. Dadurch lassen 

sich sowohl Zeit als auch Kosten sparen. 

Es sollte weiterhin deutlich geworden sein, dass bei der Verwendung eines flexibel einsetzbaren 

Objektmodells die wiederholte Neuentwicklung eines solchen für verschiedene Projekte nicht 

nötig ist. 

8.1 Kritikpunkte 

Die größten Probleme dieser Arbeit ergaben sich dadurch, dass immer wieder zwischen der 

Anforderung nach ausreichender Performanz auf der einen Seite und ordentlichem objektorien-

VIII. Zusammenfassung und Ausblick 75 

tierten Design auf der anderen abgewogen werden musste. Zwar wurde in den Anforderungen 

das Augenmerk vor allem auf zweiteres gelegt, eine Ignoranz des ersteren hätte aber wohl die 

Praxistauglichkeit des Systems zunichte gemacht. Diese Problematik spiegelt sich deutlich in 

einigen Komponenten wieder. 

Zum einen wurden GameObject sowie GameObjectType nicht gegen Schnittstellen implementiert, 

was deren Austauschbarkeit erschwert, aber teure Typüberprüfungen zur Laufzeit bei 

dem Übergang zu angrenzenden Systemen wie den Filtern unnötig macht. Das gleiche trifft auf 

die Klassen DeltaObject und DeltaType zu, welche zudem noch eine starke Kopplung gegenüber 

ihren Äquivalenten in den Objekthierarchien aufweisen. 

Zum anderen wurde an vielen Stellen auf das Werfen von Ausnahmen verzichtet, welche in der 

heutigen Softwareentwicklung ein wichtiges Werkzeug zur Fehlerbehandlung darstellen. Denn 

ein solcher Prozess geht auch immer mit einer Objekterstellung einher, die zusätzliche Kosten 

zur Laufzeit verursacht. Dieser Kompromiss wurde vor allem an voraussichtlich häufig frequentierten 

Stellen wie der Methode zur Löschung eines Spielobjekts aus der Baumhierarchie eingegangen. 

Sollte hier zum Beispiel das zu löschende Objekt gar nicht vorhanden sein, wird keine 

Ausnahme zur Signalisierung dieses Zustands geworfen. 

Bei Veränderungen der Baumstruktur sowie dem Anwenden von Aktionen auf ihr Quellobjekt 

und die Zielobjekte werden innerhalb des Systems möglicherweise sehr viele Nachrichten an 

die Beobachter dieser Objekte versendet, da das Modell ohne Kenntnis der Semantik keine 

Möglichkeit hat, zu entscheiden, welche dieser Nachrichten tatsächlich redundant sind. Diese 

Aufgabe fällt damit vorrangig den Filtern zu. 

Diesen bleibt es ebenfalls überlassen, bei der Synchronisierung der Listen der Aktionen und 

Zustandsobjekte – zum Beispiel innerhalb der GameObject Objekte – zu entscheiden, wie das 

Löschen von Einträgen in diesen Datencontainern auf einem Netzwerkknoten mit weiteren abgeglichen 

wird. Das System bietet keinen Mechanismus, solche aus einer Liste entfernten Objekte 

solange als gelöscht markiert vorzuhalten, bis alle interessierten Teilnehmer einen entsprechenden 

Abgleich durchgeführt haben. Dies soll auf Grund der Komplexität dieser Aufgabe eben 

mit Hilfe der Filter gelöst werden. 

8.2 Ausblick 

Im Anschluss an diese Arbeit ist von Interesse, ob das System tatsächlich den gestellten Anforderungen 

standhält und praktikabel einzusetzen ist. Das kann jedoch nur durch dessen Verwendung 

in einem Spieleprojekt festgestellt werden, durch welche möglicherweise weitere Anpassungen 

nötig werden. Allerdings sollte die Fokussierung auf Erweiter- und Wiederverwendbarkeit 

bei der Entwicklung des Systems Adaptionen in vernünftiger Art und Weise unterstützen. Im 

Folgenden werden einige Anregungen für solche Handgriffe gegeben. 

• Es ist zu untersuchen, ob die Liste der aktuell ausgeführten Aktionen in der Klasse 

GameObject nicht in einem Singleton[Gamma, 1997] oder einer statischen Variable gehalten 

werden könnte, damit ein Aufrufen aller Aktionen nicht das Iterieren über den 


76 VIII. Zusammenfassung und Ausblick 

gesamten Spielobjektbaum erfordert, in dem viele Objekte möglicherweise gerade gar keine 

Aktionen auszuführen haben. 

• Zur Verbesserung der Leistung des Systems könnte die Vererbungshierarchie der Typen 

auf ihre Blätter reduziert werden, indem die Eigenschaften der Typen von der Wurzel an in 

die Kinder kopiert werden. Dies könnte für den Einsatz zur Laufzeit interessant sein, wenn 

ein dynamisches Austauschen der Typen nicht mehr von Interesse ist. Dadurch würden 

Anfragen nach Eigenschaften von Spielobjekten direkt von deren Typ behandelt werden 

können und müssten nicht durch die gesamte Vererbungshierarchie geprüft werden. 

• Möglicherweise wären weitere State Klassen von Interesse, zum Beispiel solche, die Konstanten 

repräsentieren, deren Wert sich nach der Initialisierung nicht mehr ändern. 

• Es ist nötig, die Anforderungen der Grafikengine an das Form Interface zu evaluieren, um 

dieses mit entsprechenden Methoden zu füllen. 

• Um die Eindeutigkeit der von dem System vergebenen IDs zu gewährleisten, bedarf es eines 

geeigneten Mechanismus, der zum Beispiel auf Prinzipien beruht, die auch ihre Verwendung 

in Algorithmen für Multicasts 1 finden und es mehreren Netzwerkknoten erlauben, 

sich auf eine eindeutige ID für jede zu verschickende Nachricht zu einigen. 

• Zur Definition der Objekte in dem System könnte ein XML Schema und ein passender 

Parser entworfen werden, der mit Hilfe korrespondierender Filter die Objekthierarchien 

mit Leben füllt. Ebenso könnte eine Datenbank als Quelle genutzt werden. 

• Werden zur Laufzeit Typen, von denen bereits Instanzen mit überschreibenden State 

Objekten bestehen, aus der Hierarchie entfernt, kann es zu undefinierbarem Verhalten 

kommen. Das ist genauer zu untersuchen und möglicherweise mit geeigneten Methoden 

zu verhindern. 

• Es könnte ein Netzwerkprotokoll entwickelt werden, welches zwischen zwei Netzwerkknoten 

vermittelt, welche Filter eingesetzt werden, oder welches den Filtern erlaubt, bei Bedarf 

selber Objekte nachzufordern. 

Über diese Arbeit hinaus bedarf die Spieleentwicklung weiterer Erforschung von Methoden und 

der Entwicklung von Handwerkszeug, zu dem auch ein solches Objektmodell gehören sollte. Die 

Schwierigkeit besteht natürlich in der Interdisziplinarität des Themengebiets, in dem eben nicht 

nur Informatiker beschäftigt sind. So müssen unterschiedliche Anforderungen, Begrifflichkeiten 

und Vorkenntnisse der Mitwirkenden zusammengebracht werden. Gerade an den Schnittstellen 

zwischen Fachgebieten lassen sich Optimierungen vornehmen, wie wir am Beispiel des datadriven 

Designs gesehen haben. Darüber hinaus ist es wünschenswert, dass Methoden der Softwareentwicklung, 

die schon länger ihre Tauglichkeit bewiesen haben, ihren Weg in die Spieleindustrie 

finden und Prozesse somit standardisiert werden können. All dies fördert nicht nur 

Kosten- und Zeitersparnis sondern in erster Linie auch die Kommunikation innerhalb der Entwicklerteams. 

1 http://de.wikipedia.org/wiki/Multicast 


Literaturverzeichnis 

Bilas 2002 

Bilas, Scott: A Data-Driven Game Object System. In: Game Developers Conference 

Proceedings GDC, Game Developers Conference, 2002 

Church 2002 

Church, Doug: Object Systems: Methods for Attaching Data to Objects and Connecting 

Behaviour. In: Game Developers Conference Proceedings GDC, Game Developers Conference, 

2002 

Doherty 2003 

Doherty, Michael: A Software Architecture for Games. In: University of the Pacific 

Department of Computer Science Research and Project Journal (RAPJ) 1 (2003), Nr. 1 

Duran 2003 

Duran, Alex: Building Object-Systems: Features, Tradeoffs, and Pitfalls. In: Game Developers 

Conference Proceedings GDC, Game Developers Conference, 2003 

Gamma 1997 

Gamma, Erich: Design Patterns. Elements of Reusable Object-Oriented Software. Addison- 

Wesley Professional, 1997. – ISBN 0201633612 

Griwodz 2002 

Griwodz, Carsten: State replication for multiplayer games. In: Proceedings of NetGames 

2002, 2002, S. 29–35 

Hannah 2004 

Hannah, Britt L.: Object-Oriented Game Design. A modular and logical method of designing 

games. (2004), August. http://www.devmaster.net/articles/oo-game-design/ 

Ludwig 2005 

Ludwig, Joe: Real-World MMO Object Sharing. (2005), S. 209 – 221. ISBN 1584503904 

Mühlhäuser 2005 

Mühlhäuser, Max: Lecture Notes on TK1: Distributed Systems. 2005 

Rabin 2000 

Rabin, Steve: The Magic of Data-Driven Design. (2000), S. 3–7. ISBN 1584500492 

Riley 2003 

Riley, Sean: Data-Driven Systems for MMP Games. (2003), S. 385–396. ISBN 1584502436

II Literaturverzeichnis 

Stroustrup 2000 

Kapitel 15. In: Stroustrup, Bjarne: Die C++ Programmiersprache. 4. Addison-Wesley, 

2000. – ISBN 382731660, S. 417–418 

Tanenbaum 2002 

Tanenbaum, Andrew S.: Computer Networks. 4. Prentice Hall PTR, 2002. – ISBN 

0130661023 

Tanenbaum u. van Steen 2002 

Tanenbaum, Andrew S. ; Steen, Maarten van: Distributed Systems: Principles and Paradigms. 

1. Prentice Hall, 2002. – ISBN 0130888931 

II Jens Pfau · Stephan Mehlhase

Entwicklung eines flexiblen Objektmodells für ein ... - Jens Pfau

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?