Version vom 9. November 2011, 10:46 Uhr

Verwendung eines Stacks

Bitte auch auf die Verwendung eines Stacks eingehen. Wenn man z.B. aus dem Spiel heraus in die Optionen geht, wird der "Optionen"-Zustand oben auf den Stack gelegt. Verlässt man das Optionsmenü wieder, wird der Zustand vom Stack entfernt und der Zustand, der darunter war, wieder aktiviert (das Spiel). --David Scherfgen 12:30, 4. Nov. 2011 (CET)

Sehr gute Idee! Ich hatte den Ansatz, es jedem State selbst entscheiden zu lassen. Dann würde ich einen Punkt für Konzepte des Zustandswechsels schreiben, der diesen Ansatz beschreibt. --Trommlbomml 10:57, 7. Nov. 2011

Man braucht dann noch zusätzliche Methoden OnGetFocus und OnLoseFocus, die aufgerufen werden, wenn der aktuelle Zustand durch einen neuen Zustand auf dem Stack "verdeckt" bzw. er wieder den Fokus bekommt, weil der Zustand oben auf dem Stack entfernt wird. --David Scherfgen 11:18, 7. Nov. 2011 (CET)

Frage ist, ob man das als Erweiterung oder Implementierungsalternative darstellt. Erweiterung würde mir persönlich besser gefallen - technische Umsetzung wird natürlich umfangreicher - Vorschläge? --Trommlbomml 12:06, 7. Nov. 2011

Ich fände es gut, wenn der Stack fester Bestandteil der hier gezeigten Implementierung ist. Die Lösung mit getNextState finde ich nicht gut, weil man doch gar nicht immer sagen kann, was der Folgezustand eines Zustands ist. Bei meinen Spielen ist es immer so, dass der Zustand einfach setState (nimmt alle Zustände vom Stack und setzt dann den neuen), pushState (legt einen Zustand auf den Stack) oder popState (nimmt den aktuellen Zustand vom Stack weg) vom StateManager aufruft.

Beispiel: das Spiel startet im Hauptmenü. Dann ist auf dem Stack der Zustand "Hauptmenü". Aus dem Hauptmenü heraus starte ich das Spiel, dieser Zustand wird oben auf den Stack gelegt. Aus dem Spiel heraus gehe ich in den Optionsbildschirm, auch der wird oben auf den Stack gelegt. Nun hat der Stack 3 Einträge. Ich verstelle etwas in den Optionen und gehe zurück ins Spiel: der Options-Zustand ruft popState auf. Der darunter liegende Zustand (das Spiel) wird wieder aktiv. Will der Spieler auch das Spiel beenden, so wird erneut popState aufgerufen, und nur noch das Hauptmenü bleibt da und wird aktiviert.

Das finde ich viel flexibler als den hier gezeigten Ansatz. Und besonders schwer zu implementieren ist es auch nicht.

--David Scherfgen 14:26, 7. Nov. 2011 (CET)

Was ich noch vergessen hatte: man kann bei setState, pushState und popState auch jeweils noch eine "Message" übergeben, die der danach aktive Zustand erhält. Wenn das Spiel den Optionsbildschirm aufruft, möchte es nachher vielleicht wissen, ob ich dort etwas geändert habe. --David Scherfgen 14:28, 7. Nov. 2011 (CET)

Und noch eine Erweiterung: jeder Zustand kann angeben, ob er beim Zeichnen "transparent" ist. Wenn das Optionsmenü beispielsweise angibt transparent zu sein, dann wird auch noch der darunter liegende Zustand gezeichnet und danach das Optionsmenü (es wird so tief in den Stack gegangen, bis ein nicht transparenter Zustand gefunden wird, und dort wird angefangen zu rendern). --David Scherfgen 14:34, 7. Nov. 2011 (CET)

Es kann ebenso sein, dass ein Spiel mit einem Intro beginnen soll (Logo vom Hersteller etc.), bevor es ins Hauptmenü geht. Genauso soll vielleicht nach dem Beenden noch Werbung für andere Spiele oder Erweiterungen gezeigt werden. Nach einer Weile der Inaktivität soll vielleicht vom Hauptmenü in einen Demo-State übergegangen werden, in dem Spielausschnitte gezeigt werden, von denen aus wieder das Hauptmenü aufgerufen wird. Die Beispiele dürften ausreichend gut verdeutlichen, dass ein State nicht genau einen Nachfolger hat. Die Optionen sollen meist sowohl aus dem Hauptmenü heraus, als auch aus dem Spiel heraus erreichbar sein. Der darauf folgende State hängt dann davon ab, welcher der vorherige war. Auch ich denke, dass ein Stack angebracht ist. --Sacaldur 14:39, 7. Nov. 2011 (CET)

Die Funktion GetNextState() ist doch flexibel. Der State kann doch unterschiedliche Folgezustände liefern - in Abhängigkeit von Update kann eine string-variable auf den Folgezustand gesetzt und bei GetNextState() geliefert werden. Trotzdem finde ich deine Lösung und Erweiterungen pragmatisch.

Warum hält man es denn nicht erst mal einfach und erweitert es dann Schritt für Schritt. Ist ja im Menü sogar so vorgesehen, dass hinterher Erweiterungen gezeigt werden. So würde ich vorschlagen, zuerst eine Version ohne Stack zu zeigen. Auch muss der Folgestate ja nicht im State selbst gesetzt sein. Man kann doch den aktuellen State selbst entscheiden lassen. Zum Beispiel könnte ein Intro-State dann Abfragen ob eine Taste gedrückt wird und in dem Fall zum Menü weiterleiten. Falls nach 5 Sekunden nichts passiert, könnte der Intro-State zu einer Demo weiterleiten. Falls hier etwas gedrückt wird gehts weiter zum Menü, ansonsten nach einer Zeit wieder zum Intro. Jeder State überlegt für sich wie er wann weiterleitet. Ein einfaches Statepattern also. Als Erweiterung kann man dann auf die Variante mit dem Stack eingehen. Klar ist dies nicht viel komplizierter, aber diejenigen die von Stacks noch nichts gehört haben schreckt es vielleicht erst einmal ab. Außerdem gibt es mit Sicherheit genug Spiele, die diese Funktionalität überhaupt nicht brauchen. So würde die die Variante mit Stack dann als Erweiterung ansehen, die dann durch die Version mit Transparenz noch weiter erweitert werden könnte. Lieber alles Schritt für Schritt erklären. --Schorsch

Das Problem ohne Stack ist, dass du dir ggf. irgendwie merken musst, woher du gekommen bist. Außerdem: Mal angenommen du gehst vom Spiel in die Optionen - dann wäre es nicht toll, wenn das Spiel "OnLeave" erhalten würde, denn eigentlich wird es ja gar nicht verlassen, sondern nur von den Optionen verdeckt. Kommst du dann wieder zurück ins Spiel, wird dort "OnEnter" aufgerufen und das Spiel wird wieder von vorne anfangen. Nicht wirklich das, was man will. Und wer nicht weiß, was ein Stack ist, oder nicht bereit dazu ist sich dieses einfache Konzept anzueignen, für den ist ein Artikel wie dieser sowieso nicht geeignet. --David Scherfgen 15:16, 8. Nov. 2011 (CET)

Alles Schritt für Schritt zu erklären, ist schon die richtige herangehensweise. Nur sollten wir uns einig werden, welche Schritte in welcher Reihenfolge beschrieben werden sollen. David hat damit recht, dass ein Stack eigentlich ein einfaches Prinzip darstellt. Allerdings kann ich Schorsch auch in der Hinsicht verstehen, dass es eventuell ein wenig abschreckend für jemanden ist, der damit nichts anfangen kann. Dem kann man nur entgegen wirken, indem man diesen so einfach wie möglich erklärt. Allerdings halte ich es deswegen nicht für notwendig, den Stack erst später als Erweiterung einzubauen. Ich halte es aber auch nicht für vollkommen sinnlos. --Sacaldur 15:28, 8. Nov. 2011 (CET)

Ich finde es auch Sinnvoller Schritt für Schritt vor zu gehen. Da einem Neuling (so wie ich) in der Thematik erstmal das Grundkonzept klar werden sollte. Später kann das ganze dann erweitert werden. So kann dann auch der Leser für sich entscheiden wie weit er in dieses Thema einsteigt denn er weiß (mit etwas Glück) am besten wieviel Wissen er brauch. --Koschi 15:59, 8. Nov. 2011 (CET)

Es wird doch Schritt für Schritt erklärt. Und eine Stack zu verstehen, sowie gleich damit zu Rande zu kommen habe ich diesen Artikel von Anfang an als für Fortgeschrittene eingestuft. Wer es einfacher haben will, würde ich bei Nachteilen schreiben: mit einem bool für zwei oder mit einem Switch für drei Zustände kommt man dann auch zu Rande. --TrommlBomml 08:00, 9. Nov. 2011 (CET)

Das ein Stack sicherlich Sinn macht ist denke ich klar. Aber das Problem welches ich dabei sehe, ist dass es Spiele gibt, für die eine einfachere Variante ausreicht, da sie den Stack nicht benötigen. Ich denke dabei an wirklich einfache Spiele, bestehend aus vielleicht einem Intro, einem Hauptmenü und dem Spiel. Wenn ich aus dem Spiel in das Hauptmenü gehe, ist das Spiel beendet. Das ist ein Verhalten, welches vielen wohl für den Anfang reichen wird. So würde ich so vorgehen, zuerst einfach das State-Pattern zu erklären, dann um den Zustandsmanager zu erweitern und damit zu zeigen, wie man den aktuellen State verwalten könnte, um dann die möglichen Erweiterungen durch zum Beispiel den Stack zu zeigen. Ein weiterer Vorteil wäre meiner Meinung nach, dass dadurch die Einfachheit von Zustandsautomaten gezeigt würde. Dadurch fällt es dem Leser leichter, dass gelernte auch auf andere Probleme zu übertragen. Und auch wenn ein Stack keine Hexerei ist, ist es für den ein oder anderen mit Sicherheit abschreckend und hat mit dem Thema Zustandsautomaten auch erst mal direkt nichts zu tun. --Schorsch 08:59, 9. Nov 2011 (CET)

Wie wäre es denn z.B. einen Artikel für Einsteiger zum Zustandsautomaten zu schreiben in dem beschrieben wird wie das ganze mit ner Switch variante gelöst wird, so hat der Leser erstmal den Einstieg und kann das Grundkonzept nachvollziehen. Die leute die sich gut auskennen (Fortgeschrittene) werden diese Variante eh kennen und dann gleich diesen Artikel hier lesen. Am Ende des Einsteiger Artikels wird dann auf diesen Artikel verwiesen der dann wirklich in die Tiefe geht und alle weiteren Konzepte beinhaltet. Auf diese Weise ist vielleicht jedem geholfen.--Koschi 10:09, 9. Nov. 2011 (CET)

Die Umsetzung des Automatens durch die Stateklasse macht ja schon Sinn und sollte auch für "Einsteiger" zu verstehen sein. Mir gehts ja hier nur um die Sache mit dem Stack. Das ist halt meiner Meinung nach eine Variante die man als Erweiterung ansehen sollte, da sie für spezielle Fälle gebraucht wird. Halt für den Fall, dass ich zum Beispiel mehrere States übereinander rendern möchte, oder von mir aus auch, dass ich zum letzten State zurück möchte, ohne neu zu initialisieren. Mir geht es halt um die Einfachheit der Variante ohne Stack, vor allem weil ich glaube, dass dies vielen erst mal reicht. Wer sich einen kleinen Snakeklon/oä schreibt braucht oft kein Ingame-Menü und besitzt eh nur 2-3 Zustände. Da ist der Stack dann nicht zu gebrauchen und Overhead. Deswegen ja mein Vorschlag, klein Anzufangen, im ersten Schritt auf das einfache State-Pattern der GoF einzugehen, zu zeigen wie es einem für Gamestates helfen kann und danach dann auf die Vorteile der Implementierung mit einem Stack als Erweiterung einzugehen. Ich selbst benötige für die meisten Projekte selbst keinen Stack und denke dass ich da nicht der einzige bin. Außerdem denke ich, je simpler desto einfacher ist es zu verstehen, und desto einfacher kann auch ein Anfänger das Prinzip an seine Bedürfnisse anpassen.

Namensgebung von Klassen und Methoden

Warum hast du die Methode OnInit in Initialize umbenannt? Kam bisher noch nicht vor, weil der Code fehlt, aber ich habe die Methode bewusst OnInit genannt, weil sie vom StateManager aufgerufen wird, wenn das erste Mal in den Zustand gewechselt wird und noch nicht initialisiert wurde - finde das so semantisch korrekter! --TrommlBomml 12:16, 7. Nov. 2011 (CET)

"On" klingt für mich immer nach Event, und Initialisierung ist für mich kein Event, sondern eher ein Befehl "initialisier dich!". Hat sich ja jetzt eh erledigt. --David Scherfgen 14:26, 7. Nov. 2011 (CET)

Wofür OnInit/Initialize?

Wofür gibt es die Methode OnInit bzw. jetzt Initialize? Welchen Code sollte sie ausführen, der nicht im Konstruktor ausgeführt werden kann? Und warum sollte sie erst kurz vor dem ersten Aufruf eines States aufgerufen werden und nicht nach dem Erzeugen des State-Objekts? --Sacaldur 13:29, 7. Nov. 2011 (CET)

Wenn du in den Zustand Hauptmenü bist, soll da schon dein ganzes Hauptspiel geladen werden? Das ist auch abhängig von eventuell gewählten Karten/Level, Spielfiguren... Aus diesem Grund wird erst beim ersten Wechsel geladen - quasi eine Art LazyLoading. --TrommlBomml 13:33, 7. Nov. 2011 (CET)

Ich finde auch, dass es besser wäre, wenn der Zustand selber entscheiden könnte, wann er was lädt. Also könnte er das beim ersten OnEnter machen. Initialize wäre damit überflüssig. Das ist ja sowieso fehleranfällig, weil man vergessen kann, IsInitialized auf true zu setzen. --David Scherfgen 14:18, 7. Nov. 2011 (CET)

Damit bin ich auch einverstanden. Ist schon angepasst. --TrommlBomml 14:22, 7. Nov. 2011 (CET)

Fehler in der Implementierung von StateManager

Ich habe eben für Java eine Implementierung des StateManagers hinzugefügt. Dabei ist mir aufgefallen, dass sowohl die C++, als auch die C# Implementierungen fehlerhaft sind: in beiden werden Methoden aufgerufen, die eigentlich anders heißen, wie Render statt OnRender. Ich bitte darum, dass jemand anderes, der entsprechende Mittel (Syntaxprüfung) zur Hand hat, das zu verbessern. --Sacaldur 13:51, 7. Nov. 2011 (CET)

Erst einig über Design werden, dann in allen Sprachen implementieren!

Es macht keinen Sinn, die ganze Sache direkt in 3 oder 4 Sprachen zu implementieren, wenn wir uns noch gar nicht einig darüber sind, welches Design das beste ist. Das führt ja nur dazu, dass man nachher umso mehr anpassen muss. Generell könnte man erst auch mal auf Pseudocode setzen. --David Scherfgen 14:19, 7. Nov. 2011 (CET)

Verdammt irgendwas ging da gerade schief also nochmal

Warum nimmt man für den State einen String und nicht eine Enum Variable ? Soweit ich den Code überblicke sollte es ja mit ner Enum Variable auch gehen oder ? Bei Enums sehe ich den Vorteil das man als übergabe parameter nur Vordefinierte States nehmen kann. Die States sind schnell erweiterbar falls nötig. Bei strings kann ich auch nicht state spezifisch strings übergeben, diese werden erst während der Laufzeit auf Gültigkeit überprüft. Enums werden quasi schon vom Compiler, überprüft auf Gültigkeit, falls dieser Stat nicht Existiert.

--Koschi 14:55, 7. Nov. 2011 (CET)

Grundsätzlich hast du recht. An der Stelle ist es durchaus berechtigt, wenn man es in dem Spiel direkt drin hat. Der Grund ist eigentlich nur wenn du deinen StateManager in eine extra DLL auslagerst : möchtest du für jeden neuen Zustand, den du erfindest, deine DLL neu übersetzen? Oder eine Abhängigkeit der DLL zu einem Header des Spiels haben? Durch strings kannst du in diesem Fall für jedes Spiel einen einen string als statische öffentliche Konstante der konkreten State-Klassen anlegen und diese nur verwenden. Daher sind ja auch strenge Prüfungen mit Exceptions eingebaut, so dass es auch auffällt, wenn man diesen Fehler eingebaut hat. Wenn es in dem Kontext für euch schöner ist, dann soll es meinetwegen auf Enums geändert werden! --TrommlBomml 15:34, 7. Nov. 2011 (CET)

Ich wollte nur mal den Hintergrund Erfragen weil ich persönlich viel mit Enums arbeite. Und dein Argument mit der Dll ist natürich nicht von der Hand zu weisen. --Koschi 15:58, 7. Nov. 2011 (CET)

Zu PseudoCode: Ich persönlich finde Pseudocode ungünstig. Ich lese mir sowas nie durch sondern will direkt richtigen Code sehen. In der Informatik gibt es dafür meiner Meinung nach bessere Ausdrucksmittel, wie zum Beispiel Diagramme oder schematische Darstellungen, wie bei den Stapelverarbeitungen - die ist übrigens definitiv noch verbesserungswürdig! --TrommlBomml 07:56, 9. Nov. 2011 (CET)

Dem muss ich allerdings zustimmen. Für Pseudocode gibt es keinerlei Standardisierungen, wehshalb er im Extremfall auch einfach fehlverstanden werden kann. Sofern es notwendig ist, kann statt dessen auf Struktogramme oder notfalls Programmablaufpläne zurückgegriffen werden. Um den Aufbau von Klassen und deren Beziehungen zueinander darzustellen, können Klassendiagramme verwendet werden. Es reicht meiner Meinung nach, wenn der Quellcode am Ende des Artikels aufgeführt wird. --Sacaldur 10:41, 8. Nov. 2011 (CET)

Umstrukturierung

1. Es muss ohne Code erklärt werden, wie das Prinzip funktioniert.
2. Der Stapel muss gleich am Anfang mit erklärt werden, bevor die State-Schnittstelle erklärt wird. Sonst versteht man gar nicht, was die einzelnen Methoden bedeuten.
3. Code erst ganz am Ende, und auch erst dann schreiben, wenn der Artikel "stabil" ist!!!

--David Scherfgen 17:20, 7. Nov. 2011 (CET)

Das ist von der Reihenfolge besser, ich habe den Abschnitt nach vorn verschoben und die Einleitung zur Architektur etwas angepasst. Code habe ich erstmal gar nicht mehr angefasst und werde ich auch erstmal nicht - bis wir uns auf eine gute Lösung geeinigt haben. --TrommlBomml 08:05, 9. Nov. 2011 (CET)

Transparente Zustände

Bisher steht in dem Abschnitt zu transparenten Zuständen, dass nur über mehrere transparente Zustände in der Reihenfolge zur Stackspitze hin nacheinander gezeichnet wird. Meiner Meinung nach sollte das für Update situationsbedingt auch gelten. Wenn ich zum Beispiel an Multiplayerspiele denke: Man verliert sein Leben und es wird ein neuer transparenter Zustand auf den Stapel gepackt. Dieser zeigt an, ob man weiterspielen oder aufhören möchte. Der Zustand darunter wird aber auch aktualisiert - die anderen Spieler spielen ja noch. Macht aber auch nicht immer Sinn - wie zum Beispiel in einem Pausenmenü. --TrommlBomml 08:05, 9. Nov. 2011 (CET)

Einverstanden. Aber beim Update sollten dann alle Zustände auf dem Stack aktualisiert werden, weil Transparenz hier keine Rolle spielt. Die Zustände wurden ja vorher schon informiert, dass sie nicht mehr ganz oben sind (mittels OnLoseFocus) und können somit entscheiden, wie sie sich im Update verhalten. --David Scherfgen 08:37, 9. Nov. 2011 (CET)