The article where I found this image also has other good aspects for a beginner, and perhaps even someone with fair knowledge, to peruse; if you haven't seen it yet, please take a few minutes to look at it here. (In fact, the whole gamedevelopment.tutsplus.com site is replete with a few interesting tutorials and thought-provoking articles; it may be good to follow the site in general.
The Point?
In my case I had originally put all the states as equal sibling Java classes, all descended from the same abstract class; but in reorganizing my work, I found a few interesting facts about the use of states in general, and things in specific I should have realized about classic rpgs when playing them, had I been more analytical. It's these few new facts that will be the basis of additional refactorings of the source code.
- First, a few states are specifically for application-level notifications and meta-game states: an "engine beginning/initialization" state for when things start up; an "exception-handling" state for capturing and displaying crash states, if possible; and even the "title screen" that shows when the player can select whether to load a game, start a new game, or just exit altogether.
- Second, a few more states for game specials, such as cut-scenes and interstitial scenes. A cutscene state could be either a playing animation, a "text-roll" or info-dump at the beginning of a game, or a video that gets played. The interstitial scenes, I'm sure you have seen them, are the transitions between "stages" or "chapters" of a game (at least, how I imagine them to be). Another few game special states might be for handling of "game over" events - essentially displaying a background graphic and some ending text, and optionally for asking whether the player would like to continue, resume, or quit.
- Third, the primary "in-game" states such as map handlers, battle handlers, and such, anything not a menu or system.
- Fourth, the menus and systems that the game engine will handle, as a part of a supplemental expansion of the "core" play of a game. I say it like this because, it's entirely possible a game could be made for only map-based movement, with no menus, no controllable "systems" such as crafting or item management; yet the game is supplemented with the proper use of such.
- Fifth, some additional states that may be used while a game is in development, not of use to the intended player. The use of "developer-only" game states may provide some inherent debugging functionality from within the game itself, via displaying the values of some variables, and possibly, through a menu-based selection screen, being able to test-play battle of selected party members versus opponents.
And perhaps more ways to break it down than that. With obvious compartmentalization like this, menus and systems are only relevant to an in-game playthrough, so they would only be accessible from within an active game. Also, the primary in-game states are only relevant to an active game as well, so they won't be accessible until a game is either loaded or started anew. With a little more introspection, game states can be tweaked somewhat by common functionality and application...
Hi,
Just a simple suggestion, since "been there done that", regarding state and menu handling, and many of the problems / use-cases you mentioned can be solved by a bit more complex state handling constructions!
Check out:
Concurrent State Machines
Hierarchical State Machines
And most importantly, which I believe to be the most useful and flexible for game state management is:
Pushdown Automata
I use the last construct for state handling. Short version:
You have a stack of states, so multiple states concurrently, you usually implement and use the simple case, where the top-most state in the stack is the "Current" or "Active" state. You simply push and pop states, and to simulate the simple state-machine behavior you can add a changeTop function too...
The nice part, that comes with this is that you can preserve the last state(s), so you can easily implement jumping back to previous states (like sub-menus within menus or a cut-scene at some point in the "game-play" state). Also you can specialize the automata for game-state management with some nice tricks, like adding the possibility of update-ing/draw-ing multiple states in the stack by going downwards from the top of the state-stack, and "asking" the states themselves whether to update and/or draw underlying states.
This way it is a simple job to add a "popup" like state for pausing the game-state but still drawing it, like in case of dialog message-boxes or pause and inventory menus which do not cover the full screen.
For more details check this:
http://gameprogrammingpatterns.com/state.html
It is a well put together source for other patterns too, useful for game-dev.
Br.
P.S:
Haven't read through every point of the article until now.
Sry for the long comment, essentially it suggested something really similar I did.