12
\$\begingroup\$

I wonder what are the best ways to organize different screens in a game?

I am thinking of it like this:

Inheriting a base State class, and overriding update and render methods, to handle the current screen. Then, under certain events a StateManager is able to activate another Screen State, and the game screen changes as only the current State is rendered.

On the activation of a new screen, effects like fading could be added, and also the same goes for its deactivation. This way a flow of screen could be made. By saying when A ends, B starts, allowing for complex animations etc.

Toughts?

\$\endgroup\$
1

2 Answers 2

Reset to default
10
\$\begingroup\$

I would also consider allowing a stack of states. That way when the state on top leaves, the state under activates. this is really nice for menu states. When one menu leads to another, it simply puts the next state on top. If the user wants to go back, you simply deactivate the current state and the previous state activates. Very easy for menu navigation.

Also, I would advise implementing some way to have states on top of other states while the states below the top one still draw. This could be useful for pause states, but it's up to you in the end.

Also take a look at this sample: XNA Game State Management Sample I know it's in C#, but it's a pretty decent implementation of the concept.

\$\endgroup\$
2
  • \$\begingroup\$ +1 for stack of states. Every time I see it not implemented, it becomes a pain in the ass. \$\endgroup\$
    – Nevermind
    Commented Feb 12, 2011 at 6:56
  • 1
    \$\begingroup\$ +1 for stack of states, it's the core of our framework too. It does cause some trouble when a non-top mode wants to finish (especially when upper modes need to save to a savegame, for example) but it's a very powerful idea in general. \$\endgroup\$
    – ggambetta
    Commented Feb 12, 2011 at 12:26
2
\$\begingroup\$

How to handle this really depends on what you mean by a 'screen'. Often the presentation of the game at a certain point is tied into the input system for that stage, and this is grouped together as some sort of game state object. I tend to dislike this approach because too often these states become dumping grounds for all sorts of unrelated data and functions, filling your code with de facto globals. Having a stack of states instead of a single state can facilitate some things (eg. having a menu render over the top of the game while it's paused) but complicate others (eg. needing to have a dummy state for the same menu to render correctly when the game isn't in progress).

Therefore I prefer to keep much of this information in separate objects, whether for input, world rendering, the GUI, etc. Fading one screen into another tends to just become a function of the GUI. A menu rendered over the game becomes just another GUI window paired up with the pause functionality. And so on. Complex animations don't require a game state system to work, and in fact should really be decoupled from any overall game state - you don't want to have to implement a separate state any time you want interesting interface animations, after all. You should be able to have that during normal gameplay if you choose.

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged .