For anyone who has considered or is working on RPG engines, at some point we come across the source image that I found in a tutsplus.com article, that refers to a generalized "architecture" for the modules of an rpg engine. This is a good starting point when developing a state-based system, where each state represents a current activity that does not run in parallel to another state. For example, each of the game menus could be states, the game maps could be controlled by one map-controller state, and the beginning and ending(s) could be more states. I've taken this approach before having seen this graphic, but oh boy am I glad I'm on the right track...

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...