4. Objektverwaltung in Spielen

Objektverwaltung in Spielen

  • A

    Ich arbeite gerade an einem Mittelgrossen Spielprojekt und stecke peinlicherweise seit längerem in der Engine fest.
    viele Grundlegende Dinge wie Texture Managament, Rendering und sonstiges sind bereits fertig, doch ich habe Probleme mit der Objektverwaltung.
    Bis jetzt sieht es so aus:
    Ich habe
    ein Basisobjekt, das nie wirklich erstellt wird mit einer Methode handle()
    Diese wird mehrfach bei Vererbungen überladen.
    In einer Klasse Level befindet sich eine Liste mit allen Basisobjekten bzw. allen Objekten im Spiel, deren handle-Funktionen einzeln in einer Schleife ausgeführt werden.
    Die Spielobjekte habe ich in Worldobjects und Entityobjects aufgeteilt
    WO's stellen die Welt an sich dar (Wasser, Boden, Steine usw) und Entitys die meist kleineren Objekte, die sich auch bewegen (Gegener, Items, Spieler)
    Nun bin ich mir aber unschlüssig wie ich Beispielsweise die Kollisionsabfrage gestalte schliesslich soll der Spieler auf Lavva,Wasser oder festen Boden anders reagieren.
    Und ich gehe davon aus, dass sich im weiteren Verlauf ähnliche Probleme auftun werden, wenn bsp. gewisse gegner imun gegen gewisse attacken sein sollen.
    Ich hatte folgende Ideen:

    Ein Event System

    bsp:
    Player.collide(int type); //Lava,Wasser,Solid
    Enemy.getdamge(); //Arrow Sword
    Sodass sie durch überladung indivduel reagiern können, ich aber niocht für jede Klasse eine eigene Reaktion schreiben muss
    Nachteil
    Es lässt keine weiteren Informationen zu (Wer hat den Pfeil geschossen? Wie tief bin ich im Wasser)

    Viele Objektlisten für verschiedene Klassen

    bsp
    Player.collide(Waterobject e);
    Player.collide(Lava Object r);

    so kann ich extrem flexibel auf alle möglichen Events reagieren

    Nachteil:
    Viele Listen für jede Klasse
    Viele Schleifen für jede Klasse

    Hat jemand eine Idee, wie ich das am besten angehen kann oder ein paar Links zu dem Thema?

    0
  • K

    Es war einmal ... also damals ... Meine Klassen hatten alle eine feste ID (rtti fuer Arme). Die Kollisionsabfrage hat Events a la "Objekt A kollidiert mit Objekt B" (Paar von Zeigern) generiert und in einer Queue abgelegt. Diese wurde dann durchlaufen und anhand der Klassen-ID der Objekte die Kollisionsbehandlung an registrierte Handler delegiert. Dabei gab es keine Unterschiede zwischen Welt- und Entityobjekten.

    Wer hat den Pfeil geschossen?

    Das sollte vielleicht der Pfeil wissen.

    Wie tief bin ich im Wasser

    Sowas wuerde erst im speziellen Handler geprueft. Auch wuerde erst im Handler der detailierte Kollisionstest erfolgen.

    0
  • A

    ok, aber wie komm ich wieder an das Pfeil Objekt?

    0
  • ?

    per Pointer, den du als Parameter übergibst.

    0
  • A

    ok, also dann funktioneiert das also so:

    int send event(int eventtype,void * pointer_auf_das_objekt){

    }

    oder habe ich falsch verstanden?

    0
  • A

    Ich hab noch eine Frage: ist es eigentlich klug, einfach einen Haufen Vectoren oder Listen zu in denen jeweils die Pointer der der verschiedenen Typen gespeichert sind?
    also etwa eine für alle Basisobjekte(also alle Objekte), alle Gegner , alle Items, usw zu erstellen?

    oder verstösst das wieder gegen so ein heiliges Programmiergesetz?
    Ich stell mir das auch ziemlich aufwendig vor soviele zu erstellen und dann auch nich die jewelgen add() funktionen zu schreiben.

    Es ist halt mein erstes grösseres Spielprojekt, und da will ich alles richtig machen.

    0
  • ?

    Wie willst du Objekte sonst verwalten, wenn nicht über Listen von Referenzen bzw. Pointern?

    Wenn du ein Objekt von Liste A nach Liste B kopieren willst, dann geht das mit Pointern wesentlich schneller, weil sich nur der Pointereintrag in den Listen ändert. Würdest du das Obejekt selbst in der Liste A speichern, dann müßtest du das ganze Objekt nach Liste B kopieren.

    0
  • N

    alterbro schrieb:

    Ich hab noch eine Frage: ist es eigentlich klug, einfach einen Haufen Vectoren oder Listen zu in denen jeweils die Pointer der der verschiedenen Typen gespeichert sind?
    also etwa eine für alle Basisobjekte(also alle Objekte), alle Gegner , alle Items, usw zu erstellen?

    oder verstösst das wieder gegen so ein heiliges Programmiergesetz?

    Klassischer Anwendungsfall für std::shared_ptr und std::weak_ptr. Eine Mainliste allokiert das Objekt, alle anderen Listen haben einen Verweis darauf.

    Es ist halt mein erstes grösseres Spielprojekt, und da will ich alles richtig machen.

    Herzlichen Glückwunsch, du bist eine Ausnahme!
    Andererseits ist der Lerneffekt größer wenn man sich ewig mit Segmentation Faults beschäftigt.

    0
  • A

    @Pointer = schnell
    ok, war mir irgendwie schon kolar, aber nur so aus sicherheit, und es schien mir halt ein bisschen unkosmetisch, eine Klasse mit einem Haufen List-Membern vollzustopfen und fragte mich ob man das nicht auch anders lösen könnte.
    Dann also danke, es wird so geamcht.

    @ Nathan
    danke, schlag ich gleich noach

    0
  • ?

    Interessanter Artikel zum Problem (jedenfalls so ungefähr):
    http://www.gamedev.net/page/resources/_/technical/game-programming/evolve-your-hierarchy-refactoring-game-entities-with-components-r3025

    0
  • A

    Danke, hab ich lang gegoogelt, hab aber nichts gefunden,leses mal durch, danke

    0
Anmelden zum Antworten