Core Architecture Using State Controls

Earlier in this chapter we used a Game class to organize the relevant parts of the games core functions. As the complexity of a given game increases, so should its underlying architecture. Creating a state-driven Game class is a way that allows for much better control within the application and allows the relatively seamless integration of additional possibilities, such as pausing the game or displaying a menu system.

The concept of a state machine is used first to identify the discrete components of a particular system or machine. Each state has some change applied to it to cause a state change. For example, ice has heat applied to it to cause a change from a frozen state to a liquid state. Each state in a system is linked by a series of valid causes for transition from one state to another. Consider the ice example again; if the ice has no additional heat applied, it remains in the current frozen state. The change to a liquid form can occur only when heat is applied. If too much heat is applied to the liquid form, it continues its transition into a gaseous state until the gas becomes cool again and returns to a liquid state.

You can use this same structure and apply it to the Game class that will handle the overall execution of the game. For the sake of this example, we will identify four major states: Game Init, Game Main, Game Menu, and Game Shutdown. Each of these states is completely separate from the others in its functions. Figure 2.3 shows the current state system:

image from book
Figure 2.3: A basic game state machine.

For the most part, transitions in the game are driven by player input. When the player starts the game, he is sent to the main system menu. From there he makes selections and is forwarded to the relevant components of the game. At this point it becomes important to note that these functions themselves define the game that is ultimately playable. The actual definitions of these functions are defined in the remaining components of this book and vary greatly based on how the game is developed. For now we are just laying the blueprint of what is yet to come. The state-driven model is completely flexible and can be adapted to much more complicated models, as needed. Let’s look at a state-driven Game class.

The first thing that must be done is to identify the key states that will be available.

static final int GAME_INIT          = 1; static final int GAME_MAIN          = 2; static final int GAME_SHUTDOWN      = 3; static final int GAME_MENU          = 4;

We have decided on four possible states for now. At any given time, the current game state is held by a member integer in the class. When this class is created, the state initially is set to GAME_MENU by the constructor. The two major functions of importance in this class are the setState() method and the update() method. Let’s look at those now.

public void setState(int state) {   gamestate = state;  update(); } 

This method automatically adjusts the state with one of the existing classes and then calls the update method to process .

/*This function will process the current game state and call the *underlying functions until the execution is terminated by input or *breaking the game state. */ public void update() {   switch(gamestate)   {     case GAME_INIT:         gameInit();       break;      case GAME_MAIN:        gameMain();        break;      case GAME_SHUTDOWN:        gameShutdown();        break;      case GAME_MENU:        displayGameMenu();        break;      default:        System.out.println("Could not ID Gamestate");    } }

The local definitions for each function are defined as needed. At the completion of each one, a decision is made about the next state. When the gameMain() method returns, it immediately sets the state to GAME_MENU and presents the player with choices to continue with his game, to start over, or to stay at the menu. Although no graphics are on the screen, this method is one way to control the execution of the core game structure.

Note that this example is a simple implementation of this idea. Many additional possibilities exist, including maintaining specialized listener classes that focus on discussion between the running game and the infrastructure. This implementation is designed only to display this concept at work and should be a good starting point for making a game application.



Practical Java Game Programming
Practical Java Game Programming (Charles River Media Game Development)
ISBN: 1584503262
EAN: 2147483647
Year: 2003
Pages: 171

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net