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

Weitere Magazine

Empfehlungen

Info

40 V. Bestehende Systeme Taxonomie Objektstruktur Daten Modellierung Dynamische Zustände Definition Verhalten Modellierung extern Definition Typen Modellierung Klassen Definition Vererbung Konzept Mehrfach Gegenstand Daten Objektordnung Dynamik zur Laufzeit Kommunikation Initiative Polling Änderungsübermittlung Kompression Semantik-unabhängig Quality of Service 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. 40 Jens Pfau · Stephan Mehlhase
V. Bestehende Systeme 41 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. 5.4.1 Systembeschreibung 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. Jens Pfau · Stephan Mehlhase 41
Seite 1 und 2: Technische Universität Darmstadt F
Seite 3 und 4: Zusammenfassung Jedes Computerspiel
Seite 5 und 6: Inhaltsverzeichnis 1 Einleitung 1 2
Seite 7 und 8: Abbildungsverzeichnis 3.1 Baumansic
Seite 9 und 10: Kapitel 1 Einleitung Eine lange Rei
Seite 11 und 12: Kapitel 2 Motivation Man muß das U
Seite 13 und 14: Kapitel 3 Taxonomie Das letzte Ziel
Seite 15 und 16: III. Taxonomie 7 Spielobjekte ein.
Seite 17 und 18: III. Taxonomie 9 • Das System ist
Seite 19 und 20: III. Taxonomie 11 Nachteile: • Da
Seite 21 und 22: III. Taxonomie 13 Nachteile: • We
Seite 23 und 24: III. Taxonomie 15 Nachteile: • Da
Seite 25 und 26: III. Taxonomie 17 einzulesen, und e
Seite 27 und 28: III. Taxonomie 19 Nachteile: • En
Seite 29 und 30: III. Taxonomie 21 Gegenstand der Ve
Seite 31 und 32: III. Taxonomie 23 3.3 Kommunikation
Seite 33 und 34: III. Taxonomie 25 der Modellierung
Seite 35 und 36: III. Taxonomie 27 Objektstruktur Da
Seite 37 und 38: Kapitel 4 Anforderungen Das Problem
Seite 39 und 40: IV. Anforderungen 31 4.5 Erweiterba
Seite 41 und 42: V. Bestehende Systeme 33 oder einer
Seite 43 und 44: V. Bestehende Systeme 35 Taxonomie
Seite 45 und 46: V. Bestehende Systeme 37 Abbildung
Seite 47: V. Bestehende Systeme 39 Ein Spielo
Seite 51 und 52: V. Bestehende Systeme 43 Das Formob
Seite 53 und 54: V. Bestehende Systeme 45 Es ergibt
Seite 55 und 56: VI. Design und Implementierung 47 6
Seite 57 und 58: VI. Design und Implementierung 49 s
Seite 61 und 62: VI. Design und Implementierung 53 e
Seite 63 und 64: VI. Design und Implementierung 55 T
Seite 65 und 66: VI. Design und Implementierung 57 J
Seite 69 und 70: VI. Design und Implementierung 61 D
Seite 71 und 72: VI. Design und Implementierung 63 a
Seite 73 und 74: VI. Design und Implementierung 65 T
Seite 75 und 76: VII. Integration 67 sehr viel höhe
Seite 77 und 78: VII. Integration 69 7.2 Filter Wie
Seite 79 und 80: VII. Integration 71 werden, ob ein
Seite 81 und 82: VII. Integration 73 Listing 7.4 zei
Seite 83 und 84: VIII. Zusammenfassung und Ausblick
Seite 85 und 86: Literaturverzeichnis Bilas 2002 Bil

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

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?