spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Jap sorry, ich hätte die relevanten vielleicht einzeln posten sollen.

@Joshflux: für dich relevant sind somit nur "Game" und "State", wobei State deine Screens wären, während Game diese managed.
Je nach Spiel bietet sich aber ein nicht ganz so allgemeiner Aufbau an. Die Verkettung von Zuständen finde ich auch recht praktisch, wenn man nicht unbedingt beliebig dazwischen springen kann.

Also z.B.: Intro -> Menü -> Spiel -> Menü -> Spiel -> ...

Damit kennt das Intro das Menü, das Menü das Spiel und das Spiel das Menü.

Zyklische Abhängigkeiten... nicht ganz so cool und auch nicht ganz logisch, oder?

Abhängig von der größe des Projekts geht das schon in Ordnung.
Einerseits sollte man es als Anfänger gleich "richtig" lernen, andererseits will man ja nicht gleich überfordern. Es ist außerdem gut selbst auf solche Probleme zu stoßen
Für ein großes Projekt (kein Anfängerprojekt) solltest du (Joshflux) natürlich zyklischen Abhängigkeiten vermeiden (also Klasse A hängt von Klasse B ab).

A hängt von B ab ist generell OK. Aber wenn B auch von A abhängt wird's fies. Wahlweise wenn A->B->C->A gilt.

Frei nach dem Motto "Composition over Inheritance" könnte man den StateManager auch weglassen. Stattdessen könnte es eine Datenstruktur geben, die das UI beschreibt. (Diese Bereiche mit dieser Positionierung gibt es, in denen diese Elemente liegen, die wiederum auf jene Art angeordnet werden. Der Button hier löst diesen Effekt aus und der andere hier jenen Effekt. ...) Es wird nur gespeichert, welche UI-Elemente gerade vorhanden sind und es können andere aktiviert und deaktiviert bzw. geladen und entladen werden.
Wenn man also ein Objekt hat, welches sich um alle UI-Elemente kümmert (Prüfung der Benutzerinteraktionen mit dem UI, ausführen der Event-Listener, ...), könnte man mit der gleichen Schnittstelle (Update, Render) auch ein Objekt besitzen, welches alle Ingame-Objekte handhabt. Letzteres würde wissen, ob es gerade "aktiv" ist (das Spiel läuft) und alle Ingame-Objekte aktualisieren muss oder ob es "inaktiv" ist (Hauptmenü) und somit rumidlet.

Will man darauf aufbauend für das UI States implementieren, dann würden alle States instanzen der gleichen Klasse sein, da alle lediglich die anzuzeigenden UI-Elemente besitzen.

Will man möglichst "Data Driven" arbeiten, würde man für die UI-Elemente nicht den auszuführenden Code (also den jeweiligen Callback) definieren, sondern daus aufzurufende Menü bzw. die Information "Spiel starten", "Spiel beenden" etc.

Das darfst du gerne machen. Es ist in gewissem Maße gut, unterschiedliche Herangehensweisen mal probiert zu haben. Ich habe auch schon Dinge implementiert, die nicht gerade die sauberste Variante darstellten.

Bedenken muss man nur immer, dass einem Nachteile bestimmter Vorgehensweisen nicht immer direkt auffallen. Singletons findet man bspw. meist gut, bis man dann doch etwas mehr Austauschbarkeit oder automatisierte Tests haben möchte. Wenn man aber nicht probiert, seinen Code automatisiert zu testen, sieht man das Problem aber auch nicht.
Und häufig sind die Ursachen von Problem nicht direkt ersichtlich, weil man die Ursachen nicht als Ursachen in Betracht zieht. Wenn man in sein System keine automatisierten Tests einbauen kann (ohne vorher großartig Erfahrung damit gesammelt zu haben), denkt man sich meist eher, dass automatisierte Tests blöd sind, weil sie zu schwer zu integrieren sind. Dass aber gerade das Software Design an sich und wahrscheinlich das Fehlen von "Inversion of Cotnrol" Schuld daran sind, wird oft genug übersehen.

Solange du immer einen leicht kritischen Blick behältst, kannst du im Grunde alles auch mal probiert haben, um daran lernen zu können.