Updates to the Game Class

You remember that the Game class is composed of three main methods controlled by a state machine: GAME_INIT, GAME_MAIN, and GAME_SHUTDOWN. These states are also mapped to methods of the same name. The fundamental strategy at this point is to make the Game class capable of organizing the full-screen and image components discussed so far in this chapter as well as link Actor classes to the actual display. Let’s look at the updates for each method in turn.

 On the CD   The code samples referenced here are contained in the SimpleGame example in the provided source code. SimpleGame extends from the FullScreen3 class used earlier in this chapter.

public SimpleGame(String title, DisplayMode mode) throws  HeadlessException     {         super(title,mode);         am = new ActorManager();         setState(GAME_INIT);     }

The constructor is updated so that it instantiates the ActorManager and immediately sets the gamestate to GAME_INIT.

public void gameInit() {   URL imageURL = getClass().getResource(imageResourceName);   if(imageURL==null){    System.out.println("Unable to locate resource      return;     } loadBufferedImage(imageURL); loadImage5(imageURL); initToScreen(2); // start the rendering thread startRenderThread(); am.createEntity("Player",1);   //add some input to update the player position on screen. addKeyListener( new PlayerAdapter((Player)am.actorList.getFirst())); setState(GAME_MAIN); }

First, the gameInit method loads the images and prepares them to be rendered. The second step is to create the buffers used for the rendering, and subsequently to begin the renderThread. At this point, the game attempts to draw information to the screen. The ActorManager uses the factory method createEntity to create a single instance of the Player class. Then, using the newly created PlayerAdapter, the Player class is linked up to take input from the keyboard. Finally, the gamestate is set to move on to GAME_MAIN.

public void gameMain() {           while(gamestate == GAME_MAIN)       {        //Perform game logic here.                }       setState(GAME_SHUTDOWN); }

Not much new information is added to gameMain at this point. At the correct time, all the game logic will be performed inside the code. Because the rendering for the game is being handled in a separate thread, the rendering call isn’t made inside each gameMain call. As code is added to the gameMain method, the frame rate begins to drop a bit as the application time slices the processing power.

public void gameShutdown() {       System.out.println("The game is shutting down.");   am.clearEntities();   System.exit(0);  } 

The gameShutdown() method has the added responsibility of cleaning up the entity list before exiting. Because of its parent classes, SimpleGame has Listener classes designed to handle exiting methods. This method must still be defined for internal state changes to the game that do not include exiting the game.

Finally, let’s look at the changes to the render method. The render method is structured to be overloaded as needed. In this case, it displays the Actor classes in turn, based on their internal positions.

public boolean render(Graphics g)  {     super.render(g);     Player a;         if(image!=null)     {       for (int i = 0; i<am.actorList.size(); i++)          {               a = (Player)am.actorList.get(i);              g.drawImage(image,a.getX(),a.getY(),this);            }     }     return true; }

The render method now traverses the actorList, requesting the coordinates of the actors and displaying them using the loaded Image from the gameInit() method.

When the SimpleGame example is compiled, it should look like the image featured in Figure 3.12.

Figure 3.12: Looking good with managed images.