Ich find ein starres Gamestate-System für die meisten Fälle ohnehin nicht sonderlich angebracht.
Letztlich ist es doch so, dass man viele Datenbestände über das ganze Spiel hinweg braucht. Zum Beispiel hat man doch permanent eine GUI. Oft lässt sich ein Spiel außerdem gar nicht mal so zerstückeln, dass man immer ganze Teile lädt und zerstört.
Ich arbeite mittlerweile lieber mit flexibleren, verteilteren Statusangaben.
Ein Gamestate-System wär in CuBrush zB. praktisch unmöglich gewesen, weil man ja immer die Spielwelt da hat - klar die Spielwelt hat nicht immer den Status "Spiel läuft" und ergo auch nicht immer Spieler. Aber deswegen entlad ich nich nicht das halbe Programm.
Außerdem sollte man sich mal überlegen in wie weit man in wirklich unabhängige Gamestates unterteilen kann. Meistens kommt dann raus Credits - Hauptmenu - Spiel, wobei Spiel vllt noch ein paar mal unterteilt ist. Letztlich braucht man überraschend viele Daten möglichst Griffbereit.
Unterteilungen kann man da machen, wo beispielsweise eine Spielwelt geladen wird.
So gibt es auch in der Architektur von Xrodon II keine Spielzustände. Das ganze Spiel ist von oben betrachtet eine Klasse die eine GUI-Klasse verwaltet die permanent besteht und eine Game Klasse die besteht, wenn ein Spiel läuft. Die Gameklasse selbst kümmert sich wieder um unterzustände die teilweise bestimmte Objekte (andere Klassen halt
) bedingen. Diese haben natürlich auch wieder verschiedenste Zustände - und die müssen dann nichtmal ein stures Enum sein.
Summa summarum ist das Game State Prinzip meiner Meinung nach ein Schema das sich in Reinform nur in sehr wenigen Fällen anweden lässt und einen oft viele Steine in den weg stellt. Hat man ein kleines Projekt lohnt sich eine Abrieglung oft gar nicht, weil man gleich direkt ins Spiel einsteigen will. Hat man ein großes Projekt verwehren einen die Abriegelungen den Zugriff auf wichtige durchgehende Resourcen (oke das gilt beim kleinen erst Recht
)