[Therorie] Wie baut man am besten den Ablauf eines Spieles auf?

Hallo Communtity,

ich stehe gerade vor einer Frage, wo ich mir keinen schönen Weg denken kann: Wie bau ich den Ablauf meines Spieles (PursuitDrift) programmiertechnisch so auf, das er einfach editier- und veränderbar ist?

Zum Beispiel:1.Ladescreen 1.Spiellogo 1.Vorschau 1.Hauptmenü 1.Entsprechende Aktion für ausgewählten Menüpunkt 1.usw.

Das Spiel ist zwar unmanaged C++, sollte aber hoffentlich kein Problem sein das ich hier frage, es geht mir hauptsächlich ums Prinzip.

mfg.
markus111

Normalerweise arbeitet man mit verschiedenen States. Dazu kannst du ein enum verwenden. diese sates währen zB LoadContent, Intro, Gameplay, Menu.....

Dann weißt du bei jedem frame was gerendert und was geupdatet werden soll.

Gruß pdelvo

Hallo,

ja, soweit war ich auch schon 😁

Was mir hauptsächlich fehlt ist WIE der GameState abgefragt wird, also was wie lange zeichen etc?

[IDEE]
Jeder GameState bekommt eine Klasse zugeteilt, die das alles managed!
[/IDEE]

mfg.
markus111

Hab ich mich auch schon gefragt und denke es geht über einen Timer (so eine Art GameTicker halt), der dann alle xx ms "das Spiel am leben hält". Ich kann mir allerdings nicht vorstellen wie man so auf variable Framerates kommen kann.

gruss

Das Game wird in einer schleife immer neu gerendert. Das ist klar. Allerdings fragt er wie, wie er zB 10sec im state bleiben kann um dann umzuschallten.

@markus Dazu kannst du einfach hochzählen?, also jeden frame die zeit die seit des letzten vergangen ist zu einer variable zuzählen. wenn du dann die gewünschte zeit hast schalltest du den state um und ein anderer wird gerendert.

Gruß pdelvo

Jaja, wenn ich 5 Screens habe ist das auch kein Problem.
Wenn ich aber mehr habe, wird das eins^^.

Ich bin jetzt so weit, das ich mich frage wie ich die vernünftig angeordnet bekomme...

Ich habe eine Screen-Klasse (PRScreen), von der viele andere Screens erben (zB. PRScreenIntroLogo). Die Klassen könnten eine Art signal abgeben, das sie fertig sind, und bitte den nächsten Screen lassen oder einen nächsten Screen fordern (bestimmter screen).

Ist das möglich/performant gut/übersichtlich (ich glaub nicht).

mfg.
markus111

Bei sehr vielen Screens würde ich eine eigene ScreenManager-Klasse empfehlen, welche die Umschaltung bzw. evtl. sogar die Überlagerung von Screens vornimmt.
Die Screens sollten sich möglichst untereinander nicht direkt aufrufen, sondern nur über den ScreenManager (z.B. als Singleton realisiert) interagieren.

Ich selber habe dies auch schon für ein Spiel so umgesetzt (in C++) und dadurch große Flexibilität erreicht.

Um z.B. die ersten Screens im Debug-Modus zu überspringen einfach:

#ifndef DEBUG
ScreenManager.Open(typeof(InitScreen));
#endif

Intern sollte der ScreenManager einen Stack verwenden, damit man wieder zum vorherigen Screen wechseln kann (z.B. bei ScreenManager.CloseCurrentScreen()).

Am besten, du erstellst ersteinmal eine Schnittstelle für die ScreenManager-Klasse.
Die einzelnen Screens sollten dann wiederum von einer BaseScreen-Klasse abgeleitet werden, welche dann schon "Convenience"-Methoden zum Aufruf der ScreenManager-Klasse bereitstellt, z.B.

void BaseScreen::Close()
{
   ScreenManager.CloseCurrentScreen();
}

Falls noch Unklarheiten bestehen, einfach fragen...

Viel Spaß noch!

Hallo Th69,

Intern sollte der ScreenManager einen Stack verwenden, damit man wieder zum vorherigen Screen wechseln kann (z.B. bei ScreenManager.CloseCurrentScreen()).

Bei einem Stack wie der hier kann man aber immer nur ein Element drauf packen und in LIFO-Reihenfolge wieder abrufen. Bei den Startscreens ist das kein Problem, aber zB ein Menü kann der User öfter betreten, und das auch in unbekannter Reihenfolge.

mfg.
markus111

Hallo markus,

genau habe ich deinen Einwand jetzt nicht verstanden. Der Stack dient ja nur dazu, daß du automatisch wieder zurück zum vorherigen Screen kommst und beim Menüaufruf pushst du einfach den MenuScreen auf den Stack (der ScreenManager zeigt also immer den obersten Screen an). Und beim Schließen des MenuScreens wird halt wieder der vorherige Screen angezeigt (egal welcher Screen vorher zu sehen war).

Der Stack wird natürlich dynamisch aufgebaut (je nach Spieleraktion), nicht statisch im Programm hinterlegt!