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

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
34 Jens Pfau · Stephan Mehlhase