Pausing and Resuming

Even with the most exciting game, there comes a time when the user wants to pause it (and resume later).

One largely discredited coding approach is to use Thread.suspend( ) and resume( ). These methods are deprecated for a similar reason to Thread.stop( );suspend( ) can cause an applet/application to suspend at any point in its execution. This can easily lead to deadlock if the thread is holding a resource since it will not be released until the thread resumes.

Instead, the Java documentation for the Thread class recommends using wait( ) and notify( ) to implement pause and resume functionality. The idea is to suspend the animation thread, but the event dispatcher thread will still respond to GUI activity. To implement this approach, I introduce an isPaused Boolean, which is set to TRue via pauseGame( ):

     // global variable     private volatile boolean isPaused = false;     public void pauseGame( )     { isPaused = true;   }     public void run( )     // Repeatedly (possibly pause) update, render, sleep     // This is not a good approach, and is shown for illustration only.     { ...       running = true;       while(running) {         try {           if (isPaused) {             synchronized(this) {               while (isPaused && running)                 wait( );             }           }         } // of try block         catch (InterruptedException e){}         gameUpdate( );   // game state is updated         gameRender( );   // render to a buffer         paintScreen( );  // paint with the buffer             // sleep a bit       }       System.exit(0);     } // end of run( )

The isPaused flag is detected in run( ) and triggers a wait( ) call to suspend the animation thread. The flag must be volatile so run( ) is sure to see the change made by pauseGame( ) (otherwise the variable may be cached locally).

The thread is resumed by resumeGame( ) or stopGame( ), both of which call notify( ). These methods must be synchronized so the animation thread doesn't miss the notification and remain suspended indefinitely:

     public synchronized void resumeGame( )     {  isPaused = false;   // I do not do this        notify( );     }     public synchronized void stopGame( )     {  running = false;    // I do not do this        notify( );     }

This coding style can be criticized for combining two notions: game pausing/resuming and program pausing/resuming. This is the main reason why I do not use it.

Though the elements of the game seen by the user can pause, it is often useful for the other parts to continue executing. For example, in a network game, it may be necessary to monitor sockets for messages coming from other players.

The drawback of keeping the application running is the cost of executing the animation thread when the user is not playing.

My approach uses an isPaused Boolean, which is set with pauseGame( ):

     // this is my approach     private volatile boolean isPaused = false;     public void pauseGame( )     { isPaused = true;   }

However, isPaused is not monitored in run( ) since the animation thread doesn't suspend. isPaused is used to switch off testPress( ) and gameUpdate( ):

     private void testPress(int x, int y)     // is (x,y) important to the game?     {       if (!isPaused && !gameOver) {         // do something       }     }         private void gameUpdate( )     { if (!isPaused && !gameOver)         // update game state ...     }

Key presses are still handled by the KeyListener method since it must be possible to quit even in the paused state.

     isPaused is set to false with resumeGame( ):     public void resumeGame( )     {  isPaused = false;  }

The animation loop isn't suspended when isPaused is set true, so rendering will continue. This is important if the game screen is iconified and expanded or is momentarily obscured by another window. The game will only be redrawn if the animation loop is still operating. By contrast, a game loop using paint( ) or paintComponent( ) can be suspended since the JVM will automatically call these methods when the game window is redisplayed.

When to Pause

The situations that trigger pausing and resuming vary between the different types of Java programs.

In an applet, the animation should pause when the applet is stopped and should resume when the applet is restarted by the browser. A stop occurs when the user leaves the page, for example, to go to another page. When the user returns to the page, the applet starts again. The same sequence should be triggered when the user minimizes the applet's page and reopens it later.

In an application, pausing should be initiated when the window is minimized or deactivated, and execution should resume when the window is enlarged or activated. A window is deactivated when it is obscured and activated when brought back to the front.

In a full-screen application, pausing and resumption will be controlled by buttons on the canvas since the user interface lacks a title bar and the OS taskbar is hidden.

Examples of these approaches can be found in Chapters 3 and 4.