Designfrage

CStoll

Da wäre es evnetuell eine bessere Lösung, dein "aktives Grafik-Objekt" hinter einem Spiel-Objekt (Cursor) zu verpacken, der sich auch um die Darstellung kümmert.

(btw, wie realisierst du eigentlich die Animationen der Spielobjekte, wenn die dargestellten Grafiken nicht getimert werden (Soldaten laufen über den Bildschirm, eine Radar-Schüssel rotiert, etc)?

Reth

CStoll schrieb:

Da wäre es evnetuell eine bessere Lösung, dein "aktives Grafik-Objekt" hinter einem Spiel-Objekt (Cursor) zu verpacken, der sich auch um die Darstellung kümmert.

Hm nur hab ich leider keinerlei Attribute oder Methoden, die ich diesem Spielobjekt Cursor verpassen könnte! Ist alles schon im graphischen Objekt beinhaltet (s. dazu auch Beantwortung unten!).

(btw, wie realisierst du eigentlich die Animationen der Spielobjekte, wenn die dargestellten Grafiken nicht getimert werden (Soldaten laufen über den Bildschirm, eine Radar-Schüssel rotiert, etc)?

Derzeit sind solche Animationen, die eine zeitliche Steuerung benötigen noch gar nicht/wenig vorhanden und geplant (aufgrund von Performance etc.).
Aber jetzt wo Du es erwähnst fällt mir ein, dass ich einen Fall habe, der auch eine zeitliche Steuerung graphischer Objekte erfordert (und zwar zusätzlich zur zustandsgetriggerten Steuerung)! Hatte ich fast vergessen!
Daher ist wohl eher der Ansatz mit der gemeinsamen abstrakten Basisklasse von Vorteil!

Meine graphischen Objekte sind ziemlich kompliziert aufgebaut, weil ich mir Felxibilität gönnen wollte. Durch das eben erwähnte ist mir aber aufgefallen, dass ich nun ggf. ein Problem bekomme, wenn ein und dasselbe graphische Objekt über Zustände und später zeitlich gesteuert werden soll. Dann muss es intern wissen, wann welche Steuerung passieren muss.

Hier mal kurz der Aufbau und die gedachte Verwendung der graphischen Objekte:

zuunterst FrameObjekte, jedes stellt eine Grafik (BitMap) mit den benötigten Attributen dar
darüber Animationen, die aus einer Reihe von Frames bestehen, die entweder in einer bestimmten Reihenfolge oder zufällig abgespielt werden können (bin mir gerad nicht sicher, ob in diesen Objekte schon die Intervalle zw. den Frames definiert werden, wenn eine Animation ein Signal bekommt sich zu aktualisieren, glaub aber schon - kann gerad nicht auf den Source zugreifen)
zuoberst Animationsobjekte enthalten mehrere Animationen zu einem "Thema" (z.B. zu einem Gebäude), zwischen denen je nach Bedarf gewechselt werden kann

Sinn dahinter soll der sein, dass z.B. ein Gebäudeanimationsobjekt alle für eine Gebäude notwendigen Animationen (z.B. für die Entstehung, Normalzustand, Beschädigung, zerstörter Zustand) beinhalten soll und das Gebäude je nach seinem Zustand die Animation in dem ihm zugewiesenen Animationsobjekt umschaltet.
Zusätzlich muss aber eine Gebäudeanimationsobjekt auch zeitlich gesteuert werden, da ja innerhalb einer Animation nach einem bestimmten Intervall ein neuer Frame dargestellt werden muss (auch wenn das Gebäude seinen Zustand nicht wechselt).

Heh! Gut dass wir darüber sprechen, nun seh ich das Ganze schon etwas klarer!

Ciao

CStoll

Reth schrieb:

CStoll schrieb:

Da wäre es evnetuell eine bessere Lösung, dein "aktives Grafik-Objekt" hinter einem Spiel-Objekt (Cursor) zu verpacken, der sich auch um die Darstellung kümmert.

Hm nur hab ich leider keinerlei Attribute oder Methoden, die ich diesem Spielobjekt Cursor verpassen könnte! Ist alles schon im graphischen Objekt beinhaltet (s. dazu auch Beantwortung unten!).

Da sind die Grafik-Objekte wohl etwas zu mächtig geworden

Hmm, wenn ich mir das so ansehe, würde ich Grafik und Speilgeschehen weitgehend unabhängig voneinander verwalten (inklusive eigener Zeitschleifen für beides).

Auf Spiel-Ebene hast du Spiel-Objekte, die auf verschiedene Ereignisse (ausgewählt, Angriff, Zeit-Trigger etc) reagieren können und so die Spiel-Logik beeinflussen
Auf Grafik-Ebene hast du die Animationen, die jeweils eine Serie von Einzelbildern haben und periodisch anzeigen - in einem festen Zeittakt werden alle Animationen zum Gesamtbild zusammengesetzt.
Jedes Spiel-Objekt hat einen Zeiger zu "seiner" aktiven Animation und kann diese je nach Aktionen auch beeinflussen (z.B. wird die komplette Bildsequenz ausgetauscht, wenn die Gebäude-Hitpoints unter einen bestimmten Wert fallen).

Reth

CStoll schrieb:

Reth schrieb:

Hm nur hab ich leider keinerlei Attribute oder Methoden, die ich diesem Spielobjekt Cursor verpassen könnte! Ist alles schon im graphischen Objekt beinhaltet (s. dazu auch Beantwortung unten!).

Da sind die Grafik-Objekte wohl etwas zu mächtig geworden

Naja zumindest nach meinem Plan und der beschriebenen Architektur nicht.
Der Cursor kann unterschiedliche Zustände haben (aus, Aktion1, Aktion2, ...). Diese können direkt durch Animationen und das Animationsobjekt dargestellt werden (ausschalten, Animation1, Animation2, ...). Daher gibt es (noch) kein Cursorobjekt.

Hmm, wenn ich mir das so ansehe, würde ich Grafik und Speilgeschehen weitgehend unabhängig voneinander verwalten (inklusive eigener Zeitschleifen für beides).

Auf Spiel-Ebene hast du Spiel-Objekte, die auf verschiedene Ereignisse (ausgewählt, Angriff, Zeit-Trigger etc) reagieren können und so die Spiel-Logik beeinflussen

Sind ja so schon vorhanden.

Auf Grafik-Ebene hast du die Animationen, die jeweils eine Serie von Einzelbildern haben und periodisch anzeigen - in einem festen Zeittakt werden alle Animationen zum Gesamtbild zusammengesetzt.

Animationen sind vorhanden, werden aber wahrscheinlich nicht alle auf einmal pro Zeittakt aktualisiert (jede entscheidet selbst, ob sie einen neuen Frame blitten muss oder nicht).

Jedes Spiel-Objekt hat einen Zeiger zu "seiner" aktiven Animation und kann diese je nach Aktionen auch beeinflussen (z.B. wird die komplette Bildsequenz ausgetauscht, wenn die Gebäude-Hitpoints unter einen bestimmten Wert fallen).

Ist so ähnlich gelöst: Spielobjekte haben nen Zeiger zu ihren Animationsobjekten, diese enthalten (als Zeiger bzw. Referenz bzw. Objekt) wiederum alle für das Spielobjekt (z.B. Gebäude) notwendigen Animationen. Das Spielobjekt aktiviert die für seinen Zustand notwendige Animation selbst.

Ciao

Reth

Bleibt aber noch die Frage: Wie sage ich meinem grafischen Objekt, ob es auf zeitliche Ereignisse reagieren soll, oder nicht (dieser Eigenschaft kann sich zur Laufzeit ändern)?

CStoll

Geh einfach davon aus, daß jedes grafische Objekt auf Zeitereignisse reagieren soll (nicht-animierte Objekte haben nur einen Frame, den sie anzeigen können - und damit etwas weniger zu tun).

Reth

Hm, die Frameanzahl liegt hinter den Animationsobjekten (die "mittlere" Schicht).
Die eigentlichen graphischen Objekte können mehrere dieser Animationsobjekte haben und daher immer unterschiedliche Frameanzahlen.

Hab aber gestern gesehen, dass ich den graphischen Objekten doch keine Zeitereignisse zukommen lassen kann und zwar aus einem anderen "Designgrund":

Alle graphischen Objekte werden in einer Managerklasse erzeugt, sich in dieser gemerkt (mit Position und z-Ebene), und bei deren "Zerstörung" auch wieder freigegeben.

Diese Managerklasse hat auch die Methode zum Neuzeichnen der graphischen Objekte. In dieser wird auf Überdeckung geprüft, der Clipbereich berechnet und die Damagelist erstellt.
Die Methode erhält das graphische Objekt, das sich gerade neu zeichnen will.

Wenn ich den graphischen Objekten nun zeitgesteuert erlauben will sich neu zu zeichnen, müssten diese ja wiederum auch auf ihre Managerklasse zugreifen können (quasi ne Art doppelte Verkettung), um die entsprechende Methode aufzurufen!
Das gefällt mir nicht so sehr, so dass ich denke, für die graphischen Objekte eine Klasse zu machen, die ne Liste dieser Objekte enthält, die alle zeitgesteuert werden wollen und ebenso nen Verweis auf die Managerklasse zum Aufruf des Neuzeichnens.

Nun muss ich aber immer noch dafür sorgen, dass sich die graphischen Objekte zur Laufzeit "umentscheiden" können, ob sie zeitlich gesteuert aktiviert werden wollen oder nicht (die einzelnen Animationen wissen es, werden ja aber nach Thema in einem AnimationsObjekt [z.B. Gebäude]zusammengefasst).

Vielleicht wäre das dann ein Ansatzpunkt für das von Dir (CStoll) beschriebene Verfahren:
Alle Animationsobjekte bekommen die Möglichkeit der zeitlichen Steuerung und "fragen" ihre aktive Animation, ob diese zeitlich oder über andere Ereignisse gesteuert werden will!

Ciao

CStoll

Wenn da jemand zeitgesteuert arbeitet, sollte das wohl der Grafik-Manager sein.

Ansonsten: Nur um einen gemeinsamen Nenner zu haben

Frame: ein einzelnes Bild (aus den einzelnen Frames wird das gesamte Bild zusammengepuzzelt)
Animation: eine Folge von Frames, die zyklisch dargestellt werden sollen (z.B. die einzelnen Bewegungsschritte der Radarschüssel)
Grafisches Objekt: eine Sammlung von Animationen, von denen je nach Situation eine aktiv sein kann (z.B. Baustelle, intaktes Gebäude, leicht beschädigtes Gebäude...)
Spielobjekt: das Gebäude oder eine Einheit aus spiellogischer Sicht (kann produzieren, laufen/fahren, angreifen etc je nach Typ)

Kommt das so ungefähr hin?

Reth

CStoll schrieb:

Wenn da jemand zeitgesteuert arbeitet, sollte das wohl der Grafik-Manager sein.

Ansonsten: Nur um einen gemeinsamen Nenner zu haben

Frame: ein einzelnes Bild (aus den einzelnen Frames wird das gesamte Bild zusammengepuzzelt)

Animation: eine Folge von Frames, die zyklisch dargestellt werden sollen (z.B. die einzelnen Bewegungsschritte der Radarschüssel)

Grafisches Objekt: eine Sammlung von Animationen, von denen je nach Situation eine aktiv sein kann (z.B. Baustelle, intaktes Gebäude, leicht beschädigtes Gebäude...)

Spielobjekt: das Gebäude oder eine Einheit aus spiellogischer Sicht (kann produzieren, laufen/fahren, angreifen etc je nach Typ)

Kommt das so ungefähr hin?

Völlig korrekt!

Aber wie soll denn der Manager zeitgesteuert arbeiten. Ich seh ihn so, dass es ihm egal sein kann, was die graphischen Objekte anstellen. Er erzeugt sie, verwaltet sie und auf Anweisung zeichnet er sie neu (mit Rücksicht auf Überdeckung etc.).

Hm...

CStoll

Reth schrieb:

Aber wie soll denn der Manager zeitgesteuert arbeiten. Ich seh ihn so, dass es ihm egal sein kann, was die graphischen Objekte anstellen. Er erzeugt sie, verwaltet sie und auf Anweisung zeichnet er sie neu (mit Rücksicht auf Überdeckung etc.).

Wenn du eine halbwegs flüssige Grafik haben willst, sollte er die Anweisung zum Neuzeichnen schon in rechten kurzen Zeittakten erhalten (so ca. 25..50 mal pro Sekunde). Und dabei kann er dann von den Animationen auch das jeweils nächste Frame anfordern.

Reth

CStoll schrieb:

Wenn du eine halbwegs flüssige Grafik haben willst, sollte er die Anweisung zum Neuzeichnen schon in rechten kurzen Zeittakten erhalten (so ca. 25..50 mal pro Sekunde). Und dabei kann er dann von den Animationen auch das jeweils nächste Frame anfordern.

Ich weiß. Wenn ich dem Manager aber zeitlich gesteuert sage: Neuzeichnen, muss er alle AnimationsObjekte abgrasen, fragen, ob ein neuer Frame ansteht und wenn ja dieses Objekt zum Neuzeichnen aufnehmen.

Da die Animationen selbst wissen, wann sie ein neues Frame zeichnen wollen (z.B. da gewisse Zeit abgelaufen ist oder sich ein Zustand geändert hat) wollte ich ein neuzeichnen nur für die Objekte veranlassen, die das gerade brauchen und die entsprechende Methode dann gezielt aufrufen.

Die Animationen haben wenn sie zeitgesteuert laufen sollen einen internen Timer, der wenn man die Animation oft genug fragt (25..50 Mal pro Sekunde) feststellt, ob seit dem letzten Neuzeichnen genug Zeit verstrichen ist und nun ein neuer Frame an die Reihe kommt.
So kann ich gewährleisten, dass unterschiedliche Animationen unterschiedliche Frameabstände (zeitlich gesprochen) haben können und damit unterschiedlich schnell ablaufen.

Daher müsste ich beim derzeitigen Stand in der Klasse, welche die zeitlich gesteuerten AnimationsObjekte bekommt alle abgrasen, sie fragen, ob sie sich neu zeichnen möchten und wenn ja die Managerklasse mit der entsprechenden Methofe aufrufen.
Da aber alle Animationsobjekte eine zeitliche Steuerung bekommen, kann ich das entsprechende Interface (abstrakte Basisklasse) für die zeitliche Steuerung auch in der Managerklasse implementieren! Haste Recht! (und wieder ne Klasse gespart!)

Ciao