What are you going to do though if you you want to bring up a menu (options, save, load game) while you are playing and the menu is transparent, so the game can be seen in the background? You would still need to render the previous state (top-most state on the stack being the menu, the one before the in-game state).
Let's say you also want some things to still move while you're in the pause menu (water keeps moving, birds continue flying their rounds), now you would also need to update the previous state in addition to the menu's state.

I don't know if that is a good approach because i haven't implemented it yet. Here it is (just a code snippet)



Thanks,
Kasya

Why should the player be enforced to bind an action trigger to a keyboard key? In a general approach every input device element that fulfils a requested behaviour can be used. As an example, a keyboard key has the same behaviour as a mouse button has the same behaviour as a joystick (fire-)button has ... All these input elements are equivalent in that they have 2 states (e.g. pressed and released) where 1 of them is stable. Hence all are equally good to trigger an action (the other aspect is the ease of reaching often used input elements, but that is the demand of the user for which we allow user configured input, don't we?)

I've already mentioned this, and ApochPiQ had pointed it out in detail. There are several kinds of logical input that can be distinguished (e.g. one-shot triggers, transient states, persistent states, up to axis positions; as said, USB HID is a nice document regarding these things). Then allow the user to bind (see ApochPiQ's "mapper") appropriate raw input to demanded logical inputs. Of course, some logical input would be nice to have (like a cross switch) but isn't available. For such cases emulations would be needed. These can already be implemented into the input system.


Coming back to states and stacks: Of course, if you think of a tree when imaging how states are arranged, then a stack seems to be a natural storage for a state history. However, there are some implications: Is a history always wanted? What is with sequentially or even circularly arranged states (e.g. of several settings screens)? What is with shortcuts, e.g. from each of 3 settings screens to come back to the gameplay immediately?

In fact, a general approach would allow to define states as well as the transitions between those states, what in summary makes a typical FSM. As s.kwee correctly stated, there is no problem in defining combined states if needed. One may encounter the situation where the "normal" state handling becomes impractical, simply because the amount of states grows too much. In such cases hierarchical state machines may be a solution.

That said, I'm not principally against using a stack. It is handy when a history is needed. But I think that planning with a stack as the dominant structure means that the state flow is a-priori restricted.

My state system is derived from the example at http://creators.xna.com/en-us/samples/gamestatemanagement (I don't use C# though). It demonstrates implementing loading screens and screen transitions as well.

Idea is more that each state is a "screen". For a menu for example you would have a background screen used for all menus and then a different screen for all the menus and submenus. Then you would just have to pop off the top screen and replace it with what you want. Rendering is therefore from the bottom of the stack upwards.

As events pass through the manager, it is able to dispatch them from the top of the stack downwards until they are consumed. As mentioned above modal dialogue boxes would just consume all events.

As for overlaying the gameplay screen with a menu, something I haven't yet got to, I guess you could give each screen/state a timer object and a Pause/Resume method. Eskapade's bird/grass example would be more of a challenge, I guess you would just separate the Ai and Physics somehow and pause them whilst retaining environmental animation.

[Edited by - android_808 on July 10, 2010 10:47:56 AM]