Klassen Designfrage



  • Hallo,

    ich versuche ien 2d Stategiespiel zu Proggen.
    Nun habe ich eine Designfrage:

    Es gibt Einheiten (Panzer etc.) und Gebäude.
    Würdet ihr eine gemeinsame Obeklasse wähle

    z.B class Struktur und Gebäude erbt von Struktur und Einheiten erben von Struktur.

    Oder ist es besser Gebäude und Einheiten ganz zu trennen, weil die ja nich so viel gemeinsam haben.

    Gebäude:
    *Statisch (können sich nicht bewegen)
    *Produzieren andere Einheiten.
    *Kämpfen nicht

    Einheiten:
    *Bewgen sich (Wegfindungaalgorithmus nötig)
    *Kämpfen (müssen entfernung zu anderen einheiten wissen)
    *Sammeln Rohstoffe

    Gemeinsamkeiten:
    *Können Schaden erleiden.
    *Müssen "dargestellt werden"

    Ich habe noch weiteg gedacht: Wenn alle von einem Erben, kann ich eine Klasse Verwaltung machen und dort in einem (z.B Vector) dynamisch alle Instanzen speichern. z.B Gebäude und Einheiten.
    Der Nachteil ist, das sich sehr viel in dieser einen verwaltung "knubbelt"

    Mache ich 2 Verwaltungen: Eine für Gebäude und eine für Einheiten ist alles nen bischen getrennter, dafür muss ich mich dann um die kompliziertere Kommunikation zwischen den Klassen kümmern.

    Was ist besser trennen oder nicht trennen?



  • Trennen, dann kannste schön designen und musst nicht krampfhaft Gemeinsamkeiten finden. Z.B. ne abstrakte Basisklasse für alle Einheiten mit Geschwindigkeit, Bewegungsrichtung usw und für Gebäude ne abstrakte Klasse mit Methoden wie produziereEinheit usw.



  • Hallo,

    Oder ist es besser Gebäude und Einheiten ganz zu trennen...

    das wuerde ich in der Tat tuen. Denn eine Einheit ist kein Gebaeude und
    umgekehrt.

    Wenn alle von einem Erben, kann ich eine Klasse Verwaltung machen und dort in einem (z.B Vector) dynamisch alle Instanzen speichern. z.B Gebäude und Einheiten.

    Das wuerde ich so nicht machen. Wenn du z. B. alle Einheiten einen Zug machen
    lassen willst, dann koenntest du den einen Vector fuer die Einheiten haben und
    machst dann sowas in der Art:

    for(size_t i = 0; i < einheiten.size(); ++i)
         einheiten[i].step();
    

    Ist nur ein kleines Beispiel, deswegen bitte nicht daran aufhalten.

    Mache ich 2 Verwaltungen: Eine für Gebäude und eine für Einheiten ist alles nen bischen getrennter, dafür muss ich mich dann um die kompliziertere Kommunikation zwischen den Klassen kümmern.

    Welche Art von Kommunikation?

    mfg
    v R



  • Was hindert Dich denn daran, sowas in der Art zu machen:

    class StructElement;
    class MovableElement : StructElement;
    class FixedElement : StructElement;
    class Building : FixedElement;
    class Tank : MovableElement;
    

    Dann kannst Du immer noch gemäß VRs Vorschlag z.B. alle beweglichen Einheiten irgendwo verwalten, aber es sollte auf jeden Fall eine gemeinsame Basisklasse geben, in der alle auf einem Feld positionierbaren Elemente zusammen gefasst werden.

    Sonst kannst Du nämlich keine Aktionen mehr ausführen, die alle Objekte auf dem Feld betreffen... und mußt bei jedem Feldelement eine Prüfung der Form "if movable" durchführen. Sehr unschön.



  • Marc++us schrieb:

    Was hindert Dich denn daran, sowas in der Art zu machen:

    class StructElement;
    class MovableElement : StructElement;
    class FixedElement : StructElement;
    class Building : FixedElement;
    class Tank : MovableElement;
    

    Dann kannst Du immer noch gemäß VRs Vorschlag z.B. alle beweglichen Einheiten irgendwo verwalten, aber es sollte auf jeden Fall eine gemeinsame Basisklasse geben, in der alle auf einem Feld positionierbaren Elemente zusammen gefasst werden.

    Sonst kannst Du nämlich keine Aktionen mehr ausführen, die alle Objekte auf dem Feld betreffen... und mußt bei jedem Feldelement eine Prüfung der Form "if movable" durchführen. Sehr unschön.

    Muss er doch bei dir auch. Jetzt befinden sich auf dem Spielfeld lauter Instanzen von StructElement, aber nur die Klasse MovableElement bietet Methoden zur Bewegung. Wenn ich jetzt über all die Instanzen laufe und alle bewegbaren Einheiten um 1 Feld nach vorne bewegen will, muss ich doch dennoch prüfen, ob die aktuelle Instanz ein MovableElement ist, oder?



  • Ich ging von VRs Vorschlag aus, alle Movables noch mal getrennt irgendwo zu verlinken.

    Also gibt's das Spielfeld mit Zeigern auf alles, und dann sowas wie "Armee-Vektoren", wo nur die jeweiligen Movables der Partei vorhanden sind.



  • Denn eine Einheit ist kein Gebaeude und
    umgekehrt.

    Das wollte hier auch niemand außer dir so machen. Es ging nur darum: Eine Einheit ist eine Struktur und ein Gebäude ist eine Struktur.

    Gebäude:
    *Statisch (können sich nicht bewegen)
    *Produzieren andere Einheiten.
    *Kämpfen nicht

    Einheiten:
    *Bewgen sich (Wegfindungaalgorithmus nötig)
    *Kämpfen (müssen entfernung zu anderen einheiten wissen)
    *Sammeln Rohstoffe

    Was ist mit Dingen, wie Verteidigungstürmen?
    *Statisch (können sich nicht bewegen)
    *Kämpfen (müssen entfernung zu anderen einheiten wissen)

    Passt zu keinem deiner beiden Punkte.

    Muss er doch bei dir auch. Jetzt befinden sich auf dem Spielfeld lauter Instanzen von StructElement,

    Nein, ganz sicher nicht. "StructElement" ist vermutlich abstrakt und kann garnicht instanziert werden, weshalb auch garantiert keine Instanzen da sind.

    Nur weil ich eine gemeinsame Basis habe, zwingt mich niemand diese immer und überall zu verwenden. Egal, ob Einheiten und gebäude eine gemeinsame Basis haben, ich kann sie genau so getrennt speichern, wie ohne diese Basis. Das tolle ist, das ich aber auf einmal zusätzlich die Möglichkeit habe Funktionen zu schreiben, die mit beidem umgehen können.



  • Helium schrieb:

    Muss er doch bei dir auch. Jetzt befinden sich auf dem Spielfeld lauter Instanzen von StructElement,

    Nein, ganz sicher nicht. "StructElement" ist vermutlich abstrakt und kann garnicht instanziert werden, weshalb auch garantiert keine Instanzen da sind.

    Ist schon klar. Ich habe mich falsch ausgedrückt und meinte sowas:
    std::list<StructElement*> spielfeld;



  • Helium schrieb:

    Denn eine Einheit ist kein Gebaeude und
    umgekehrt.

    Das wollte hier auch niemand außer dir so machen. Es ging nur darum: Eine Einheit ist eine Struktur und ein Gebäude ist eine Struktur.

    Ja, da habe ich nicht richtig gelesen, sry.

    mfg
    v R


Anmelden zum Antworten