Version vom 7. November 2011, 14:28 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)

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)