Switching between various screens of the same state type?

Question

I've been having an issue with the basic structure of a program that I'm working on. I'm a very inexperienced programmer trying to teach myself the basics of programs that use multiple states.

Right now, I have a very simple game-ish program with a game loop that redirects event, logic, and rendering to my StateManager class, which pushes and pops states onto a . The StateManager class then redirects the events, logic, and rendering to whatever state is on the back() of the vector. The idea is to have an assortment of different states for each phase of the program (in this case a simple game with splash screens, menus, gameplay, death screens, etc)...

However, I'm a VERY novice coder (trying my best to learn), and I've run into a fundamental issue with my program right from the very first state class...

The first class that I made is the SplashScreenState. And the basic concept was to have a state that essentially just shows a series of 'splash screen images' (lets say 3, for the sake of example), and each time the user presses a key, it switches to the next image, and finally (when it is out of splash screen images to cycle through) switches to the next state (menustate).

My problem is that I'm having a hard time figuring out how to structure this. Originally, I made the mistake of treating each different splash screen image as an instance of the SplashScreenState. However, I figured that do so was incorrect, as all 3 splash screens would technically be part of the same 'state'.

So now I have two main issues:

• The first issue is that I'm not sure how/where to store all the splashscreen images. If I want to cycle between 3 different screen images when the program starts up, should I make them all members of the SplashScreenState class? Or is it smarter to simply have one class member for the 'currentImage', and each time the user hits a key it runs a load() function to load the next image into the currentImage pointer? Is it better to make an array or vector of images and cycle through them? I'm just not sure...

• My second issue is with the eventhandling() of the SplashScreenState.. I know that I want the image on the screen to change like; *image1 -> image 2 -> image 3 -> changeState(menuState).. So that each time the user hits a key on their keyboard, it switches to the next splash screen, until the last splash screen, where it will then change state to the main menu. I'm not sure what the best way of doing this is either.. Should I create an enum for each splash screen and increment through them (until the final screen where it changes states)? I also think that, if I did store all my various screens in an array, then I could easily increment through them, but then would that be unoptimized because all the screens would have to be stored in memory at all times?

Anyway, I'm know this question might be very basic and noobish, but that's where I am right now unfortunately! I haven't had any formal education in programming and I've been teaching myself, so I really really appreciate all the help and expertise that's present on this site! ^^

Thanks!

Answer 1

You seem to be torn between an object-oriented vs a procedural paradigm for handling state transitions. The other answer suggesting a switch statement to handle enumerated state changes is a good procedural way to go about it. The drawbacks to that are that you might end up with a monolithic game class that contains all the code and all the superfluous state-specific data for handling your event/logic/rendering for all possible states. The object-oriented way to handle this is much cleaner, and encapsulates these into their own separate state objects where they can be used polymorphically through a shared interface. Then, instead of holding all the details for handling all the states in your game class, your game class needs only to store a state pointer and not worry about the implementation details of the concrete state object. This moves the responsibility of handling state transitions out of the game class and into the state class where it belongs. You should read up on the state/strategy pattern from a design patterns book. Handling the changing of a state should be the responsibility of the state object itself. Here is some reading:

http://www.codeproject.com/Articles/14325/Understanding-State-Pattern-in-C

http://sourcemaking.com/design_patterns/state

http://sourcemaking.com/design_patterns/state/cpp/1

http://codewrangler.home.comcast.net/~codewrangler/tech_info/patterns_code.html#State

http://en.wikipedia.org/wiki/State_pattern

http://www.codeproject.com/Articles/38962/State-Design-Pattern

Quoting from the Design Patterns and Pattern-Oriented Software Architecture books: The pattern-based approach uses code instead of data structures to specify state transitions, but does a good job of accommodating state transition actions. The state pattern doesn't specify where the state transitions must be defined. It can be done in the context object, or in each individual derived state class. It is generally more flexible and appropriate to let the state subclasses specify their successor state and when to make the transition.

You have the option of creating state objects ahead of time and never destroying them, which can be good when state changes occur rapidly and you want to avoid destroying states that might be needed again shortly. On the other hand, it can be inconvenient because the context must keep references to all states that might be entered.

When the states that will be entered are not known at run-time and contexts change state infrequently, it is preferable to create state objects as needed and destroy them thereafter. In determining which to use, you need to consider cost as well as transition frequency.

Answer 2

Excellent explanation of your problem, first of all.

The portion of your game managing the splash screen can work in two ways. You've examined the problem and it's really that simple:

Receive input; set next state.

So, examples:

 STATE_SPLASH1
 STATE_SPLASH2
 STATE_SPLASH3
 STATE_TITLE
 STATE_GAME_INIT
 STATE_GAME
 STATE_EXIT

pseudocode:

state = STATE_SPLASH1

while (state != STATE_EXIT) 
  ... receive input ...
  ... process events to responders ...
  ... update ...
  ... yadda yadda ...
  switch (state) {
    case STATE_SPLASH1:
      show_splash1()
    case STATE_SPLASH2:
      show_splash2()
    case ..:

    case STATE_TITLE:
      show_title()
    case STATE_GAME_INIT:
      show_loading()
      setup_level()
      setup_characters()
    case STATE_GAME:
      game_update()
    case STATE_EXIT:
      cleanup_and_quit()

Another way is to manage splash a 'game state' and then the state of the splash as an internal state. and when splash has no more logic to run, set the game state to the next one. When I was learning, I found the DOOM source to be a valuable resource and man, is it nothing but hundreds of state machines. :)