spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich hab den in besagter Klasse drin, aktualisiert den Statestack.

MfG
Check

Ich habe eine Klasse, die kümmert sich um das Fenster und sogar um die Kommandozeilenparameter, die den Gameloop implementiert hat, der daraus besteht, die Events einzulesen, den Statestack zu aktualisieren und, wenn es angebracht ist, zu rendern.

MfG
Check

Du kannst so genannte State Stacks verwenden, um die nötige Trennung zu erreichen. Deine Applikationsklasse für das Framework zeichnet und aktualisiert Spielzustände (Hauptmenü, Spielszene, Optionsmenü, etc.). Die genaue Implementierung kennt deine Applikationsklasse nicht, es weiß nur, dass dein Spielzustand sowohl eine Zeichnen-, als auch eine Aktualisieren-Methode hat. Dadurch kannst du dann die Applikationsklasse immer benutzen und musst für jedes neue Spiel lediglich die Spielzustandsklassen neu implementieren (bzw. anpassen). Als erste Anlaufstelle könnte dir vllt. die Wikiseite helfen (auch wenn sie noch unvollständig ist):

Desweiteren: Das Buch SFML Game Development hat eine mögliche Implementierung für solche Spielzustände, neben ein paar anderen hilfreichen Themen.

Ich weiß nicht warum jeder seine Statemachine als Stack implementiert. Ich finde das sogar äußerst unpassend.

Zitat von »BlueCobold«

Ich weiß nicht warum jeder seine Statemachine als Stack implementiert. Ich finde das sogar äußerst unpassend.

Interessant, dass du das ansprichst. Ich habe jetzt öfters gehört, dass ein State Set sinnvoller wäre, allerdings frage ich mich inwiefern sich das genau unterscheiden würde. Es wirkt für mich erstmal wie ein versteckter Stack - oder ich habe noch keine richtige Implementierung davon gesehen.


@OP:
Ich benutze eine Framework Klasse und eine Game Klasse. Du denkst da meiner Meinung nach also durchaus richtig.

Ein Stack ist ein LIFO. Eine Statemachine ist das für gewöhnlich eigentlich nicht. Denn man geht in einem Spiel selten eine Leiter rauf und runter, was den Dialog/Zustandsfluss angeht. Man kann mit einem Stack natürlich auch immer nach vorn gehen und oben was neues drauf packen statt zurück zu wandern, aber wozu dann ein Stack?

In dem Fall wird das ja aber wie ein pushdown automat verwendet. Ich feuere den Spiel-State abl und lade den Pause-State drauf beim Escape drücken, beim erneuten Escape kill ich den Pause-State und lande wieder im Spiel-State.

Aber stimmt schon, ein PA ist keine FSM. Das liegt halt aber alles relativ nah beieinander.

Ich dachte du meintest den Unterschied zwischen "set of states" und "stack of states"; beim stack of states ist "spiel-state/pause-state" was anderes als "pause-state/spiel-state", bei set of states ist es beides das gleiche.

Die Diskussion zum Stack gab es unter dem Wikiartikel ja auch schon.
Logan was dein Problem angeht, das hat mit den Gamestates eigentlich erst mal nichts zu tun bzw kann davon unabhängig beantwortet werden. Deine Klasse implementiert einfach den Gameloop und bekommt die Implementierung einer Schnittstelle/einer abstrakten Klasse oder was auch immer du nimmst. In der Basisklasse definierst du die Methoden die im Gameloop aufgerufen werden sollen. Hier kannst du jetzt theoretisch Gamestates übergeben oder den Stack von States oder eine andere Verwaltungsklasse für deine Spielzustände, gehen tut das aber auch ohne.



Mal als Beispiel. In C++ sieht der Code halt leicht anders aus. Interfaces gibt es da ja in dem Sinne nicht, du kannst aber eine Abstrakte Klasse machen und die Methode nicht implementieren. Bei der Übergabe musst du dann natürlich einen Zeiger auf die Instanz übergeben da es sonst mit der Polymorphie nicht hin haut.