spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zustandsverwaltung lautet das Stichwort. Etwas formaler auch als State-Machine oder Automat bezeichnet.

Werf mal nen Blick auf das State-Pattern, zu deutsch Zustands-Entwurfsmuster.

Versuchs mal mit einer sogenannten Statemachine...
Damit kannst du z.B. deine Ablaufsmuster von einem Menu oder Intro oder dem Spiel selbst auseinander halten und verwalten.

Und für die Levelverwaltung würde ich dir Empfehlen irgendeinen Maploader o.Ä. zu bauen.

EDIT: Mist zu langsam...

übergänge wie fades o.Ä. kann man auch gut als objekte sehen, die man einfach in eine gui-objektliste packt. diese objekte werden pro frame mit einer update-funktion aufgerufen. ein fade ist dann ein objekt, das über allen anderen spielelementen aber evt. unter den menus usw. liegt. es ist einfach ein schwarzes rechteck in bildschirmgröße, das mit der zeit transparent wird. in der update funktion wird dann zeitabhängig die transparenz hochgesetzt und am ende wird das objekt als "dead" o.ä. markiert - so kann es dann beim nächsten update entfernt werden.

menu-animationen lassen sich ähnlich realisieren - evt. kannst du zusätzlich noch tween-objekte bauen, die innerhalb des updates eines objektes aufgerufen werden, um das objekt in einer bestimmten weise zu verändern...

den tween objekten oder anderen gui elementen wie das fade objekt, könnte man dann noch eine funktion mitgeben die als ereignisbehandler funktioniert. ist bspw. ein fade von transparent nach schwarz fertig, wird die funktion aufgerufen, um weiteres (z.B. anderes level laden) auszulösen...

edit: btw statemanager halte ich persönlich für spiele sozusagen für obligatorisch.

Um ergänzend zu thevoid zu wirken:

Eine Statemanager Klasse ist wohl das Sinnvollste. Allerdings reicht, um die funktionsweise der States(bzw. GameStates) zu verstehen, für den Anfang auch eine switch-case Abfrage(es sei denn du willst dich direkt mit der Statemanager Klasse beschäftigen )

Allerdings ist es mir neu, dass die States selber klassen sind. Normalerweise ist es doch so, dass es einen Statemanager gibt, der die Sache dann übernimmt. Schließlich macht der State ja eigentlich selber nichts, sondern er "ist". Und das was darin passiert, ist abhängig von dem Objekt, den das ganze betriff.

naja. beim state design pattern ist es schon so , dass die States eigene klassen von einer abstrakten Basis State klasse sind .

sonst für dein erstes kleines spiel würd ich auch einfach nur ein switch-case machen.
Und dann kannst anfangen dich mit eigenen State klassen herumzuspielen.

lg