September 15, 2019
Hot Topics:

Developing Java-Based Mobile Games

  • May 5, 2005
  • By Mugdha Vairagade
  • Send Email »
  • More Articles »
Editor's Note: To understand this article, some Java programming experience is necessary. GUI development experience with AWT and SWING will be helpful though not mandatory.

In recent times, mobile games have gained popularity for providing personal entertainment on the go. This popularity has mobile gaming playing a pivotal role in revenue generation for the cellular carriers, game publishers, and handset makers, while generating numerous opportunities for game developers and associated professionals. With the number of mobile gamers around the world expected to reach 220 million by 2009, the mobile gaming business is projected to expand to higher levels and constitute a bigger portion of the profit pie for the cellular carriers and handset makers.

Mobile games can be classified into three broad categories:

  • Embedded games: Games that are hardcoded into the mobile handset's system and shipped with it. Soon to be outdated/obsolete. Example: Snake, shipped with all Nokia phones.
  • SMS games: Games played by sending text messages—for example, SMS to game server—that process them and sends back the result through SMS. Often in the form of live contests and polls. Not very popular because the cost of gaming increases with each SMS sent to the game server.
  • Browser games: These games are played using mobile phone's built-in microbrowser (net browser for mobile devices), either in online or offline mode. Players can play such games online through their cellular carrier's or a third-party game provider's game Web site, or download them for offline gaming. This category includes a wide range of games, such as solo or multiplayer games, network games, offline games, arcade games, and so forth

Among these three categories, browser games are today's most popular type of mobile games for their innovative and multimedia-rich content, appealing presentation, and lower cost of gaming compared to SMS games. This article discusses the development of browsing games and henceforth, the term "mobile games" will refer to "browser games" in this article.

Note: This article concentrates on 2D games. Because a large number of mobile phones in circulation today have very limited resources (small screen, limited memory and graphics support, cumbersome key input), the most suitable as well as commercially feasible games for these devices are 2D games. But, as capabilities of mobile phones are bound to increase over time, 3D games will become commonplace in the near future.

Mobile games can be developed using C++, Java (Java 2 Micro Edition, to be precise), and the Binary Runtime Environment for Wireless (BREW) platform from Qualcomm.

Why Choose Java for Mobile Game Development?

Although C++ has the advantage of being compiled into native code with direct access to system resources, and with BREW the platform provides end-to-end solutions to mobile game developers while allowing them to work with any desired language (including C++, Java, XML, and Flash), Java is the most popular choice for game development. Java, or the Java 2 Micro Edition (J2ME) platform to be precise, is identified as the most convenient for developing mobile games. (For more specifics on J2ME, see "What is Java 2 Micro Edition?") The driving forces behind J2ME's popularity are:

  • J2ME enjoys the status of an industry standard backed by all major handset makers, with most of the present day mobile phones being Java-enabled.
  • J2ME is a free and open platform. This helps keep the development costs low and provides the necessary flexibility with ample support freely available for developers using it.
  • Its highly portable nature ("Write once run anywhere") ensures that a game application written for one brand/type of handset will work with all other brands/types of Java-enabled handsets.
  • It is especially optimized for small devices, is lightweight, and is highly secure because applications written on it cannot access or affect other applications running on the phone/device.
  • J2ME consists of the Mobile Information Device Profile (MIDP) API that is designed specifically for developing applications for mobile devices including mobile phones, keeping in mind their limitations and constraints. Furthermore, the latest MIDP version 2.0 itself dedicates a whole API to game development, making game development simpler and quicker.

Now, you will explore MIDP 2.0 the in context of mobile gaming.

The Role of MIDP 2.0 in Game Development

MIDP 2.0 API is a set of feature-loaded APIs used for developing secure, rich-content multimedia applications, including games, for mobile devices. MIDP 2.0 builds upon its predecessor MIDP 1.0 to provide a better development platform for building efficient and fast mobile applications. For more information on MIDP 2.0, see the Resources section at the end of this article.

MIDP 2.0 further refines the features and functionalities provided by MIDP 1.0. For information on the new features, see What's New in MIDP 2.0. One of the important additions made to MIDP is the Game API, or the javax.microedition.lcdui.game API package to be precise. Through the Game API, MIDP 2.0 provides game developers with the readymade building blocks that were to be developed from scratch in the case of MIDP 1.0. These building blocks are classes for creating and controlling various game elements such as game canvas, sprites, layers, and so forth (these are explained in the next section). Thus, MIDP 2.0 significantly reduces the time involved in game development.

The other two MIDP 2.0 API packages essential for game development, also explored by this article, are javax.microedition.midlet and javax.microedition.lcdui.

The javax.microedition.midlet API package provides a base for developing all mobile applications. It contains the javax.microedition.midlet.MIDlet class, which is the base class of all J2ME-based mobile applications (also known as midlets) and must be extended by the main classes of all mobile applications. Quite similar to the java.applet.Applet class, the MIDlet class provides resources necessary to create midlets.

The javax.microedition.lcdui API package is necessary to develop a user interface (UI) for all types of mobile applications. This API provides classes to create and control UI components (such as screen, form, text box, radio buttons, and so on) and processing input for mobile applications, including games. Developers who have GUI development experience with AWT and SWING will find that the elements of the javax.microedition.lcdui package are similar to elements from these APIs.

I'll discuss the elements of these APIs relevant to game development as upi encounter them during the development of the example game app.

Building the Example Game

To understand the APIs and their respective classes better, you'll start developing a simple mobile game. This will be a solo player offline game, a car moving through an obstacle course. The player uses the left and right handset keys to "steer" the running car to the left or right to keep it from colliding into an obstacle. The game is over when a collision happens and the score is displayed. I'll call it HardDrive.

Note: The example game is developed using the J2ME Wireless Toolkit 2.1_01 and J2SE 1.4.2_07 SDK on a Windows 2000 platform. Other versions of both the Wireless Toolkit and J2SE SDK that are compatible with various platforms are also available.

Begin building the game app by putting together the source code; call it HardDrive. From what you've explored in the previous section, the first thing you need develop is the HardDriveMIDlet (HardDriveMIDlet.java) that extends the javax.microedition.midlet.MIDlet class.

HardDriveMIDlet.java (Download)

Listing 1.1: Code snippet from HardDriveMIDlet.java

import javax.microedition.midlet.MIDlet;
import javax.microedition.lcdui.*;

public class HardDriveMIDlet extends MIDlet implements CommandListener {
... ... ... ... ... ... ... ...

HardDriveMIDlet also implements the javax.microedition.lcdui.CommandListener Interface to receive command events generated during application execution and process them. The command events occur when commands such as EXIT, CANCEL, BACK, OK, STOP, and the like are issued by using soft buttons (special buttons near the mobile phone's screen, other than arrow keys) and are handled by the commandAction( ) method of the HardDriveMIDlet. To be effective, a command should be added to a canvas.

HardDriveMIDlet serves as a container for all canvases, which are objects representing surface available for drawing on mobile device screen. Here, the midlet contains HardDriveCanvas, which extends the javax.microedition.lcdui.game.GameCanvas class. The GameCanvas is a special canvas meant for drawing efficient animated graphics for the game app, and is also capable of querying key status off-screen graphics buffering for smooth animation.

Another canvas that HardDriveMIDlet contains is GameOverCanvas, which extends the javax.microedition.lcdui.Canvas class. Canvas is a simple canvas meant for drawing text, lines, and simple shapes. The canvas is extended when simple drawing on the screen is required, instead of heavy graphics; for example, to display splash screens, game over screens, and game instructions. A game app's midlet may contain any number of canvases, but only one canvas is displayed at a time by using the setCurrent() method of the javax.microedition.lcdui.Display class.

HardDriveMIDlet also contains three other important methods, also called lifecycle methods. They are startApp(), pauseApp(), and destroyApp( ), corresponding to the Active, Paused, and Destroyed states of the midlet. In the startApp( ) method of HardDriveMIDlet, HardDriveCanvas is instantiated and the EXIT command is added to it by using the addCommand( ) method of HardDriveCanvas.

HardDriveCanvas.java (Download)

HardDriveCanvas implements a java.lang.Runnable interface to enable itself to run in its own thread, which is necessary to independently execute the game loop. The game loop is executed continuously to run the game until conditions necessary to stop the game become true (in this example, when the car collides with an obstacle or when the player exits the game anytime by using the Exit button).

Listing 1.2: Game loop of HardDriveCanvas.java

public void start()
      gameRunning = true;
      Thread gameThread = new Thread(this);
... ... ... ...
... ... ... ...
public void run() 
      Graphics g = getGraphics();
      //... ... ...some code
      while (gameRunning)    //The game loop

         //... ... ...some code

            Thread.sleep(timeStep );
            //... ... ... ...some code 
            catch (InterruptedException ie) { stop(); }


Page 1 of 2

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date