4. State Management

State Management

  • W

    Hallo,
    wenn ich in meinem Spiel oder auch in sonstiger Anwendung State Management verwende, aber verschiedene Zustände habe, die auf dieselben Daten zugreifen müssen (z.B. ein State_Ingame und ein State_Inventory), wäre es dann besser, wenn ich diese Daten so lokalisiere, dass jeder Zustand Zugriff auf sie hat, oder wäre es besser, wenn ich die Daten irgendwie als Parameter an den neuen Zustand übergebe?

    0

  • Was wäre genau der Unterschied? Bzw. was meinst du mit wenn ich diese Daten so lokalisiere, dass jeder Zustand Zugriff auf sie hat?

    1. Global machen
    2. Singletons
    3. Im gemeinsamen Parent-State einer hierarchischen State-Machine definieren

    (1) & (2) halte ich für schlecht. Dann lieber nen Zeiger auf eine Klasse die gemeinsame Daten hält an die diversen States übergeben.

    Und (3) passt nicht wirklich zu dem von dir verlinkten Artikel - von einer State-Hierarchie ist da nichts zu sehen. Davon abgesehen ist gegen (3) nichts zu sagen, ist eine gute Sache.

    0
  • W

    Ich hab den Artikel nur verlinkt, weil ich keinen besseren gefunden habe 🙂
    Wie das Prinzip funktioniert, wusste ich schon vorher.

    Ich habe so darüber gedacht:
    Ich habe eine Klasse, die die Zustände irgendwie verwaltet. Die hat daneben auch noch ein Struct als Member, in dem eben alle spielrelevanten Daten gespeichert sind. Und die einzelnen Zustände können dann entweder über die Manager-Klasse oder direkt per Referenz/Pointer auf das Struct zugreifen.

    0
  • C

    Wenn ich den Artikel richtig verstehe, bekommen die einzelnen Stati sowieso einen Verweis auf den Manager übergeben - da würde ich persönlich auch die spielrelevanten Informationen unterbringen.

    0
  • W

    Die Frage ist jetzt, was man machen soll, wenn mehrere Instanzen desselben Zustands gleichzeitg möglich sind. Ist in meinem Projekt nicht so, aber mich würde interessieren, wie man das lösen sollte.

    0
  • C

    Wieso sollte denn eine GameEngine (als Verwaltungsstruktur für das Spielgeschehen) mehrere Stati gleichzeitig haben? (oder habe ich deine Frage falsch verstanden?)

    0
  • W

    Nein, nicht mehrere aktive Zustände gleichzeitig, aber mehrere Zustände desselben Typs in der Zustand-Liste.

    Mir fällt jetzt kein praktisch sinnvolles Beispiel ein, aber mal angenommen die Zustands-Kette sieht so aus:

    State_Ingame (aktiv)
    State_SubMenu
    State_GameMenu
    State_Ingame

    Wenn man jetzt im aktiven Zustand etwas an den Daten ändert, ändert sich das auch für den angehaltenen, obwohl das ja nicht geschehen soll.
    Verständlich ausgedrückt?

    0
  • C

    Nein, nicht wirklich.

    Ich fasse mal zusammen, wie ich das System verstanden habe:
    Es gibt nur einen Zustand "InGame" und dieser kann als Reaktion auf bestimmte Ereignisse dem Manager mitteilen, daß ab sofort ein anderer Zustand gilt (z.B. "GameOver" oder "PauseMenu"). Diese Zustände verhalten sich anders und können eventuell etwas an der Welt ändern*, aber irgendwann geben sie die Verantwortung wieder an den InGame-Zustand zurück. Aber alle Zustände operieren letztendlich auf den selben Spiel-Daten.

    Wenn du mehrere unabhängige Daten benötigst, kannst du eventuell zwei GameEngine's anlegen, die jede ihre eigenen Daten und aktuellen Stati verwalten - und dann natürlich nichts von den Änderungen "nebenan" mitbekommen.

    * z.B. kommst du von GameOver zum MainMenu, das vor der Rückkehr ins Spiel alle Daten zurücksetzt, oder vom PauseMenu ins CheatMenu, wo du das Spielgeschehen außerhalb der normalen Regeln ändern kannst.

    0
  • W

    Hast es schon richtig verstanden.

    Und jetzt nochmal zum Beispiel aus dem letzten Beitrag:
    Man kann aus irgendeinem Grund von State_SubMenu zu einem neuen State_Ingame kommen, als Minispiel oder was weiß ich.
    Dieser soll aber in sich abgeschlossen sein und nichts am richtigen State_Ingame ändern.

    Wenn State_Ingame aber so geschrieben ist, dass er auf die Variablen im Manager zugreift, verwenden beide Instanzen dieselben Daten. Das widerspricht aber dem Ziel des in sich abgeschlossenen zweiten State_Ingames.

    Einen zweiten Manager während der Laufzeit zu erstellen würde glaub ich sehr schnell unübersichtlich.

    0
  • C

    Wurstinator schrieb:

    Und jetzt nochmal zum Beispiel aus dem letzten Beitrag:
    Man kann aus irgendeinem Grund von State_SubMenu zu einem neuen State_Ingame kommen, als Minispiel oder was weiß ich.
    Dieser soll aber in sich abgeschlossen sein und nichts am richtigen State_Ingame ändern.

    Das Minispiel dürfte sich dann aber anders verhalten als das "normale" Spiel - also benötigst du da sowieso einen eigenen Status dafür, der dann weiß welche Daten für ihn relevant sind. Andernfalls könnte es durchaus Sinn machen, wenn der SubMenu-Status einen eigenen Manager für das intern laufende Minispiel anlegt.

    PS: Natürlich kann es auch sein, daß du dich gerade an den Grenzen dessen bewegst, was man mit so einer State-Maschine abbilden kann 😉

    0
  • W

    Wie gesagt, ist wohl ein selten auftretender Fall, weswegen mir auch kein richtiges Beispiel einfällt. Aber es wäre ja durchaus möglich.

    Ich denke, ich machs einfach mit der Variable im Manager. Für meine Zwecke reicht das ja aus und sollte ich irgendwann mal mehr brauchen... naja, da kümmer ich mich drum wenns soweit ist 😃

    Danke für die Antworten.

    0
Anmelden zum Antworten