Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

This question already has an answer here:

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.


share|improve this question

marked as duplicate by Seth Battin, Jari Komppa, Vaughan Hilts, Anko, Josh Petrie Apr 17 at 15:04

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

gamedev.stackexchange.com/questions/1783/game-state-stack Shameless self-question advertising, but you're likely to find great answers there. –  The Communist Duck Feb 12 '11 at 13:49

2 Answers 2

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.

share|improve this answer
+1 for stack of states. Every time I see it not implemented, it becomes a pain in the ass. –  Nevermind Feb 12 '11 at 6:56
+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. –  ggambett Feb 12 '11 at 12:26

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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.