states: design considerations

 - the application (client or server) likely has
   multiple different states it can be in

 - will often need the ability to either transition
   to another state or back up to the preceding state
   (which in turn may need to back up eventually)

 - the states will often need to persist throughout
   much of the run of the application, so if you return
   to a state it 'remembers' what it was doing when
   you were last there

 - there may be considerable global application information
   that needs to be shared amongst states

 - there are likely to be many operations that each state 
   has in common

potential solution, using a game as an example

 (1) have an abstract base class, 'gameState', defining
     fields and virtual methods to be used throughout
     the other states the game can be in
        - the constructor, for bare bones initialization
        - init() to set up the key core elements
        - enter() run when you enter the state
        - process() the core working routine, repeated
             over and over while in the state
        - leave() run when you exit the state

 (2) each real game state inherits from this base class,
       adding whatever specialization it needs

 (3) have a class that manages and coordinates all the
     states and shared data, the key thing invoked by main
        - its initialization routine creates one instance
          of each of the game states, keeping them in an
          array (e.g. indexed by an enumerated StateType)
        - it maintains a stack of current game states
        - its 'run' routine is the main processing loop
          for the game/application: it repeats endlessly
              - capture/queue any events that have happened
              - call the current game state's process() routine
                (which will go through the event queue,
                 and process events as appropriate for that
                 state)
              - if that state completes/ends then go back to
                the previous state by popping it off the top  
                of the stack and making it the current state
              - if the active state requests a transition to
                a new state, push the active state on top of
                the stack and switch to the new state

 (4) the main routine would declare one instance of the manager
     class, invoke it's initialization routine, and then invoke
     its run routine

Example:

   A game state class heirarchy might look something like this

           gameState
          /     |   \
         /      |    \
  setting     single  multiplayer
   options    player        |    \
             /     |        |     \
            /      |      LAN     Server
       tutorial  skirmish

   Transitions could go forward or back along the lines
   indicated, but there would also likely be transitions
   from any of the states to 'setting options' and back,
   with the assumption going 'back' needs to remember
   the sequence you followed to get there