A thread is a path taken by a program during execution. By executing through several paths, an application is quicker, flexible, and non-blockable. If a program can be split into separate tasks, it is often easier to program the algorithm as a separate task or thread. Such programs deal with multiple independent tasks. The popularity of threading increased when graphical interfaces became the standard for all devices, from desktop computers to small intelligent devices. The reason for threading's success is the user's perception of better program performance—and performance is extremely important in games!

When developing threads for games, the following questions arise:

The answer to the first question is that at least three threads are required. One thread is used for drawing the graphic scene, one for reading input events (for example, keyboard, pen, and so on), and one for manipulating the sprites. Fortunately for the game developers, the first two threads are already automatically implemented, and developers don't need to implement additional threads. The easiest way to implement the third thread is by using the Canvas class that represents the game graphics area where the game is happening. Additional threads can be used for artificial intelligence to make the game more attractive.

If a developer wants to attract a gaming audience, a lot of work must be done in the area of the graphics. Usually today's games make a lot of effort to convince players by making magnificent introductory animations. But Java-enabled mobile devices are too limited in resources to offer the same effects. Mobile developers need to focus more on the games themselves. Providing animated action is possible with implementation of the animation thread. Such a thread is used to offer animated scenes with a fixed frame-rate.

Animation adds a great deal to the user interface, but unfortunately the devices currently available on the market are not fast enough, so higher animation frame-rates are not possible. There are many ways to implement animation, which can differ in speed from device to device. This book will show you the simplest solution: taking the lowest common denominator. The lowest acceptable frame-rate is ten frames per second. This means that a thread must execute the loop every 100 milliseconds.

The thread can have multiple methods to manipulate its data, but it should have these two required methods:

Within the Java virtual machine, a java.lang.Thread object encapsulates the details of how a particular system approaches the multithreading.

The following methods are important for the Thread class:

Listing 12.1 illustrates how to implement a thread using the Thread class.

public class GameCanvas
{
  private final int DELAY = 100;

  private GameThread thread;
  private boolean running;

  public GameCanvas()
  {
  }

  public void start()
  {
    running = true;
    thread = new GameThread();
    thread.start();
  }

  public void stop()
  {
    running = false;
  }

  public class GameThread extends Thread
  {
    public void run()
    {
      while (running)
      {
        // Move sprites
        // Check collisions
        // Repaint
        try
        {
          Thread.sleep(DELAY);
        }  catch (Exception ex) { }
      }
    }
  }
}

A special flag called running is used to notify the thread whether it can continue. When the flag is set to false by a stop() method, the thread finishes. The constant DELAY defines the sleep time for each loop. The developer should be aware that sleep time alone doesn't provide the animation frame-rate because execution time also contains times needed for moving sprites, collision detection, and calling the paint() method, which is executed in a separate thread. In reality, the speed is much lower, depending on the CPU speed of the mobile device.

Another way to create a thread is to implement the java.lang.Runnable interface. This interface is designed to provide a common protocol for objects that want to execute code while they are active. For example, Runnable is implemented by the Thread class. Being active simply means that a thread has been started and has not yet been stopped. In addition, Runnable provides the means for a class to be active while not subclassing Thread. The class is free to extend some other class, in this case Canvas. A class that implements Runnable can run without subclassing Thread by instantiating a Thread instance and passing itself in as the target. In most cases, the Runnable interface should be used if you are only planning to override the run() method and no other Thread methods.

Runnable has only one method:

Listing 12.2 shows how to implement a thread using the Runnable interface.

public class GameCanvas implements Runnable
{
  private final int DELAY = 100;

  private Thread thread;
  private boolean running;

  public GameCanvas()
  {
  }

  public void start()
  {
    running = true;
    thread = new Thread(this);
    thread.start();
  }

  public void stop()
  {
    running = false;
  }

  public void run()
  {
    while (running)
    {
      // Move sprites
      // Check collisions
      // Repaint
      try
      {
        Thread.sleep(DELAY);
      }  catch (Exception ex) { }
    }
  }
}

As with the extended Thread object, a special flag called running is also used to notify the thread whether it can continue. When the flag is set to false by a stop() method, the thread finishes. The developer should be aware that, as in the Thread class, sleep time alone doesn't provide the animation frame-rate. If developer wants to have a fixed frame-rate, thus freezing the execution of every frame at one tenth of a second, the easiest approach is to use the Timer class, which will be discussed later in this chapter. Timers may not be connected to the hardware clock itself, which can fire the timer events on time.

Each thread can have its own thread priority. By looking closer at the multithreading mechanism implemented in the Java virtual machine, you see that only one thread is ever executed at a given time (on single-processor machines). It is the system's responsibility to slice the time and execute the specific thread within one time slice. How often the thread appears in a specific time is indicated by the priority. A higher priority means more frequent execution, and such threads also run faster. The following constants define priorities:

The priority can be any integer number between MIN_PRIORITY and MAX_PRIORITY. If it is out of this range, java.lang.IllegalArgumentException is thrown.

Depending on what the thread is doing, it can have different thread states. Each thread can have one of four states:

By using the isAlive() method, the developer can find out if the thread is still alive. A thread is alive if it is starting, running, or blocked. Dead threads are not alive, and the call to the method returns false in this case.

In theory, any Thread can access any object within a Java program. To prevent the programming chaos that would result from multiple threads modifying the same object at the same time, Java uses the monitor mechanism wherein the synchronized keyword is used. The monitor mechanism is built into the Object class, thus insuring that all Java objects can use it.

The Java virtual machine has control over a lock variable attached to each object. This lock variable is used to implement a monitor mechanism that can control threads' access to the object. The monitor mechanism is used only when the synchronized keyword has been used to label a block of code. When a thread attempts to enter a synchronized block of code, the virtual machine checks whether the lock is available. If no other thread has the lock, the current thread locks the object. If the lock already exists, the current thread becomes blocked and can't proceed until the lock is released. When the thread leaves the synchronized block, the lock is automatically released, and the next blocked thread in a blocked list may proceed.

A deadlock occurs when two threads are trying to gain control of object and each one has a lock on a resource that the other needs to proceed. Unfortunately, Java has no mechanism to detect or control deadlock situations. It is a programmer's responsibility to plan objects and threads so that after the thread acquires the lock on the object, it will be able to complete the synchronized code, or at least call its wait() method.

If two threads require more cooperation in the use of an object that can't be obtained with a simple synchronized access, the wait() and notify() methods can be used.

The wait() method has three forms:

The notify() method wakes up a single thread that is waiting on the object's monitor. If any threads are waiting on the object, one of them is chosen to be awakened. The choice is arbitrary and occurs at the discretion of the implementation. The thread waits on an object's monitor by calling one of the wait methods. The awakened thread will not be able to proceed until the current thread relinquishes the lock on the object. The awakened thread will compete in the usual manner with any other threads that might be actively competing to synchronize on the object. The notifyAll() method wakes up all threads that are waiting on the object's monitor.

If you want to execute tasks that take different amounts of time during sprite movement and collision detection, the simplest way is to use the java.util.Timer class. The Timer class makes it easy for threads to schedule tasks for future execution in a background thread. Tasks may be scheduled for one-time execution, or for repeated execution at regular intervals. Timer tasks should complete quickly. If a timer task takes excessive time to complete, it “hogs” the timer's task execution thread. This can, in turn, delay the execution of subsequent tasks, which might bunch up and execute in rapid succession when the offending task finally completes. By default, the task execution thread does not run as a daemon thread, so it is capable of keeping an application from terminating. If a caller wants to terminate a timer's task execution thread rapidly, the caller should invoke the timer's cancel() method.

The following methods are part of the Timer class:

You need to implement your own TimerTask class and create a TimerTask object if you want to use the Timer class. The run() method needs to be implemented containing the thread functionality. Listing 12.3 contains an implementation of threading using the Timer class.

import java.util.*;

public class GameCanvas
{
  private final int DELAY = 100;

  private Timer timer;

  public GameCanvas()
  {
  }

  public void start()
  {
    GameTask task = new GameTask();
    timer = new Timer();
    timer.scheduleAtFixedRate(task, 0, DELAY);
  }

  public void stop()
  {
    running = false;
  }

  public class GameTask extends TimerTask
  {
    public void run()
    {
      // Move sprites
      // Check collisions
      // Repaint
    }
  }
}

This code is similar to the implementation of the Thread class, where the developer writes Thread's own inner class. Timer executes the task every 100 milliseconds. If the task takes more then 100 milliseconds, a new task will still be invoked on time. This means that at a specific time, there might be a bunch of threads running, which can slow down the device. Another approach would be to use the schedule() method, but the application would lose the fixed scheduling necessary during game execution.

The problem with timers is that they don't provide additional control methods for tasks like threads do. You can still use the Thread class instead by implementing a similar functionality as found in the Timer class, as seen in Listing 12.4.

public class GameCanvas
{
  private final int DELAY = 100;

  private GameThread thread;
  private boolean running;

  public GameCanvas()
  {
  }

  public void start()
  {
    running = true;
    thread = new GameThread();
    thread.start();
  }

  public void stop()
  {
    running = false;
  }

  public class GameThread extends Thread
  {
    public void run()
    {
      while (running)
      {
        long time = System.currentTimeMillis();
        // Move sprites
        // Check collisions
        // Repaint
        time = System.currentTimeMillis() - timer;
        try
        {
          if (time < DELAY)
              Thread.sleep(DELAY - (int)time);
        }
        catch (Exception ex) { }
      }
    }
  }
}

In the run() method, you measure the time of functionality execution by calling the System.currentTimeMillis() method. If the execution time is less then 100 milliseconds, the run method sleeps until it receives a reminder. Otherwise, it executes the next loop.

Through the use of multithreading, games become faster and manage different tasks at the same time—which was not easy to achieve in older systems. While the game waits on the player's keyboard, joystick, or touch-screen commands, it can paint on the screen, calculate new positions of the sprites, and manage its artifical intelligence. Multithreading can be done using threads or timers. Timers are much easier to use, because a game can execute the task in a fixed timeframe. However, because Java did not initially have the Timer class, a lot of ported games opt to use the Thread class instead. The next chapter will introduce high-level GUI components, and how to use them for game development.