Spielzustand-Automaten
Aus Spieleprogrammierer-Wiki
(Unterschied zwischen Versionen)
| [unmarkierte Version] | [gesichtete Version] |
(→Grundidee und Architektur) |
|||
| (17 dazwischenliegende Versionen von 4 Benutzern werden nicht angezeigt) | |||
| Zeile 2: | Zeile 2: | ||
[[Kategorie:C++]] | [[Kategorie:C++]] | ||
[[Kategorie:C-Sharp]] | [[Kategorie:C-Sharp]] | ||
| − | [[Kategorie: | + | [[Kategorie:Java]] |
| + | [[Kategorie:Spiellogik]] | ||
[[Kategorie:Für Fortgeschrittene]] | [[Kategorie:Für Fortgeschrittene]] | ||
Jeder Spieleentwickler beschäftigt sich früher oder später mit der Frage, wie man am besten mit den verschiedenen Phasen eines Spiels umgeht. Allein wenn man beim Planen schon voraus denkt, fällt einem eine logische Aufteilung auf: Hauptmenü, Charaktererstellung, Hauptspiel, Optionsmenü, Multiplayer-Einstellungen, usw. Zwischen diesen verschiedenen Teilen des Spiels soll natürlich auch problemlos gewechselt werden – und das auch in verschiedenen Kombinationen. Für dieses Problem gibt es eine gute Lösung, welche das Problem der Aufteilung mit Übergangen abstrahiert und abbildet: Spielzustand-Automaten. | Jeder Spieleentwickler beschäftigt sich früher oder später mit der Frage, wie man am besten mit den verschiedenen Phasen eines Spiels umgeht. Allein wenn man beim Planen schon voraus denkt, fällt einem eine logische Aufteilung auf: Hauptmenü, Charaktererstellung, Hauptspiel, Optionsmenü, Multiplayer-Einstellungen, usw. Zwischen diesen verschiedenen Teilen des Spiels soll natürlich auch problemlos gewechselt werden – und das auch in verschiedenen Kombinationen. Für dieses Problem gibt es eine gute Lösung, welche das Problem der Aufteilung mit Übergangen abstrahiert und abbildet: Spielzustand-Automaten. | ||
| Zeile 8: | Zeile 9: | ||
== Grundidee und Architektur == | == Grundidee und Architektur == | ||
| − | + | Die Grundidee eines Spielzustand-Automaten ist es, das Spiel in einzelne Spielzustände einzuteilen - einen <tt>State</tt>. Jeder <tt>State</tt> behandelt seinen eigenen Kontext an Daten, Aktualisierungen und Visualisierungen. Diese Zustände werden von einem so genannten Zustands-Manager <tt>StateManager</tt> verwaltet. Diesem wird jeder Spielzustand registriert, so dass er verwendet werden kann. Der Zustands-Manager bietet eine Funktion zum Wechsel eines Zustandes zu einem anderen an. Bei diesem Zustandswechsel können Informationen vom Quell- zum Zielzustand übergeben werden. | |
| + | |||
| + | === Funktionsweise und Einsatz von Spielzustand-Automaten === | ||
| − | + | Beim Start des Programms wird Der Zustands-Manager erstellt und alle Zustände, die der Automat einnehmen kann, registriert. Danach wird ein Zustand als aktueller festgelegt. Während des Programmablaufs wird der aktuelle Zustand kontinuierlich ausgeführt, wie Logik aktualisieren und Darstellung. | |
| + | Während des Programmablaufs kann der Zustand selbst entscheiden, ob und in welchen Zustand der Zustands-Manager wechseln und welche Informationen übergeben werden sollen. Dazu ein einfaches Beispielszenario: | ||
| − | === Stapelverarbeitung von Zuständen === | + | Dem Zustands-Manager wurden die Zustände ''Hauptmenü'', ''Level wählen'' und ''Hauptspiel'' registriert. Als aktueller Zustand wird ''Hauptmenü'' gesetzt. |
| + | Während des Programmablaufes wird im Zustand ''Hauptmenü'' die Eingaben abgefragt und das Menu im Fenster dargestellt. | ||
| + | Der Zustand erhält die Eingabe, dass ein neues Spiel gestartet werden soll und notifiziert dem Zustands-Manager, dass in den Zustand ''Level wählen'' gewechselt werden soll. Nach dem Wechsel durch den Zustands-Manager wird der Zustand ''Level wählen'' aktualisiert und durch die Wahl eines Levels und Schwierigkeitsgrad wird in den Zustand ''Hauptspiel'' gewechselt. | ||
| + | Beim Wechsel werden vom Quellzustand die Informationen, welches Level und Schwierigkeitsgrad gewählt worden sind, zum Zielzustand weitergereicht. Dieser Empfängt diese Informationen und kann das Spiel beginnen. Am Ende des Spiels wird wieder in den Zustand Hauptmenü gewechselt. | ||
| + | |||
| + | === Variante: Stapelverarbeitung von Zuständen === | ||
Neben dem simplen Setzen von Zuständen ist die Abfolge von Zustandswechsel ein interessantes Thema. Es bietet sich hier die Benutzung eines Stapels (''Stack'') an. Der <tt>StateManager</tt> besitzt einen Stapel, der eine Menge an Zuständen referenziert. Dabei gilt das [http://de.wikipedia.org/wiki/Last_In_–_First_Out LIFO-Prinzip] (''Last In – First Out''). Mit Hilfe der Methoden <tt>PushState</tt> lässt sich ein neuer Zustand auf den Stapel packen, der auch gleichzeitig der Aktive ist. Das Gegenstück lautet <tt>PopState</tt> und nimmt den zuletzt eingefügten Zustand vom Stapel. Durch dieses Prinzip gestalten sich Zustandsübergänge durch eine Kombination aus <tt>PushState</tt> und <tt>PopState</tt> ziemlich einfach. Hier ein einfaches Beispiel: | Neben dem simplen Setzen von Zuständen ist die Abfolge von Zustandswechsel ein interessantes Thema. Es bietet sich hier die Benutzung eines Stapels (''Stack'') an. Der <tt>StateManager</tt> besitzt einen Stapel, der eine Menge an Zuständen referenziert. Dabei gilt das [http://de.wikipedia.org/wiki/Last_In_–_First_Out LIFO-Prinzip] (''Last In – First Out''). Mit Hilfe der Methoden <tt>PushState</tt> lässt sich ein neuer Zustand auf den Stapel packen, der auch gleichzeitig der Aktive ist. Das Gegenstück lautet <tt>PopState</tt> und nimmt den zuletzt eingefügten Zustand vom Stapel. Durch dieses Prinzip gestalten sich Zustandsübergänge durch eine Kombination aus <tt>PushState</tt> und <tt>PopState</tt> ziemlich einfach. Hier ein einfaches Beispiel: | ||
| Zeile 22: | Zeile 31: | ||
==== Transparente Zustände ==== | ==== Transparente Zustände ==== | ||
| − | Der Stapel an | + | Es gibt Situationen, in denen mehrere Zustände im Stapel sichtbar sein sollen, einige sozusagen ''transparent'' sind. So könnte beispielsweise das Optionsmenü im Hintergrund noch den darunter liegenden Zustand (Hauptmenü oder das Spiel) durchscheinen lassen. Dies kann gelöst werden, indem jeder Zustand angeben kann, ob er transparent ist. Der Stapel wird dazu von oben nach unten durchlaufen, bis entweder das untere Ende erreicht ist oder ein Zustand gefunden wurde, der nicht transparent ist. Dann werden die Zustände von dieser Stelle an von unten nach oben übereinander gezeichnet, der oberste Zustand also zuletzt. |
| + | === Technische Umsetzung === | ||
| − | + | Um Spielzustand-Automaten umzusetzen, ist es hilfreich, sich stichpunktartig zu überlegen, was alles benötigt wird: | |
| − | + | # Zustands-Manager muss vorhanden sein | |
| + | # Spielzustände erstellen | ||
| + | # Spielzustände dem Zustands-Manager registrieren | ||
| + | # aktuellen Zustand setzen | ||
| + | # Zustände ausführen | ||
| + | # Zustand wechseln mit optionaler Informationsübergabe | ||
| − | + | ==== Zustands-Manager muss vorhanden sein ==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | Bei einer objektorientierten Umsetzung bilden sich eine Klasse und eine Schnittstelle heraus: Die Klasse <tt>StateManager</tt> und die Schnittstelle <tt>State</tt>. Durch diese beiden Elemente sind Punkt 1 und 2 erledigt. Jetzt müssen diese beiden Elemente noch mit Feldern und Methoden bestückt werden, um alle Anforderungen zu erfüllen. | |
| − | + | ==== Spielzustände dem Zustands-Manager registrieren ==== | |
| − | + | Das lässt sich mit Hilfe einer öffentlichen Methode der Klasse <tt>StateManager</tt> realisieren. Die könnte <tt>RegisterState</tt> heißen und erhält als Parameter eine Instanz auf ein Objekt, welches die Schnittstelle <tt>State</tt> implementiert und eine Zeichenkette als Name des registrierten Zustandes. Über diesen Namen lässt sich der Zustand im Spiel identifizieren. | |
| − | == | + | ==== Aktuellen Zustand setzen ==== |
| − | + | Auch dafür bietet sich eine öffentliche Methode an, die <tt>SetCurrentState</tt> heißen könnte. Diese erhält eine Zeichenkette mit dem Namen eines registrierten Zustandes. Der Zustands-Manager sucht dann nach einem Zustand mit diesem Namen und setzt ihn als aktuellen Zustand. Das merken lässt sich durch anlegen eines privaten Feldes der Klasse <tt>StateManager</tt> realisieren. Das Feld könnte <tt>currentState</tt> heißen. | |
| − | + | ==== Zustände ausführen ==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | Der aktuelle Zustand muss natürlich aktualisiert und gerendert werden. Üblicherweise legt man dafür auch getrennte öffentliche Methoden an, die zum Beispiel <tt>UpdateState</tt> und <tt>RenderState</tt> heißen könnten. Abhängig von verwendeten Bibliotheken werden hier eventuell noch Parameter benötigt. | |
| − | < | + | |
| − | + | ||
| − | < | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | </ | + | |
| − | + | ||
| − | + | Zusätzlich muss das <tt>State</tt>-Interface | |
| − | < | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | </ | + | |
| − | + | ||
| − | + | [[Datei:uml_states.png|miniatur|UML-Klassendiagramm eines Spielzustand-Automaten]] | |
| − | + | == Beispielimplementierung == | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | TODO: erst, wenn die Theorie festgehalten ist. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
== Vor- und Nachteile == | == Vor- und Nachteile == | ||
| + | Ein Vorteil des Zustandsautomats ist, dass einzelne Zustände an mehreren Stellen des Spiels verwendet werden können. Dies könnten die Zustände für Menüs sein, wie ein Optionsmenü oder die Menüs für das Speichern und Laden des Spielstands. Mittels des Zustandsautomaten kann auf einfache Art eine Trennung der einzelnen Spielzustände vorgenommen werden, wie beispielsweise dem Hauptmenü, dem Spiel selbst, einzelnen Menüs oder Unterzustände des Spielgeschehens, wie einem Pausenmenü. Durch diese Trennung ist es einfacher möglich, die Übergänge zwischen den Zuständen sauberer zu implementieren. | ||
== Erweiterungsmöglichkeiten == | == Erweiterungsmöglichkeiten == | ||
Aktuelle Version vom 19. Juli 2013, 12:30 Uhr
Klicke hier, um diese Version anzusehen.
