Develop state-of-the-art mobile games

Trends in mobile games and a survey of related J2ME APIs

1 2 3 Page 2
Page 2 of 3
  • The Screen class is the basis for the high-level UI widgets such as Alert, List, Form, and TextBox. The MIDP runtime controls how to display those high-level UI classes and how to assign action keys based on the specific device's UI convention. The MIDP high-level UI widgets are best for textual controls. Among the high-level UI classes, the Form class is the most flexible. You can specify the layout of a Form screen and add items such as StringItem, TextField, DateField, ChoiceGroup, and Gauge.

    The MIDP v2 specification brings two important innovations to the high-level UI: First, it allows mixed text and image display on the same Form by introducing the Spacer and ImageItem items; second, it provides a mechanism for developers to design and implement their own item-level widgets through the CustomItem class. The developers have ultimate control over the CustomItem objects including pixel-level painting and internal event handling.

  • The Canvas class is the basis for the low-level MIDP UI. It provides access to pixel-level painting over the entire screen and custom mapping for all hardware keys. You can just create a subclass of Canvas and override the paint() method for the display logic; the keyPressed(), keyRepeated(), and keyReleased() methods for key events; and the pointerPressed(), pointerDragged(), and pointerReleased() methods for pointer and touch screen pen events.
  • The GameCanvas class inherits from the Canvas class. It is part of the MIDP v2 game API and provides convenience mechanisms for game development. For example, in GameCanvas subclasses, you do not need to override the paint() method to draw the entire screen every time you make a change. You can get the Graphics object directly from the getGraphics() method and draw on it. When you need to update the display, you can call the flushGraphics() method. You can only update part of the screen using the flushGraphics() method. Compared with the Canvas class's single paint() method approach, the GameCanvas enables us to easily maintain the graphic state and quickly update the animated part of the screen. Similarly, the GameCanvas class also provides a convenience method to poll key states through the getKeyStates() method as opposed to the callback methods in the Canvas class. That allows much more flexible execution flows in complex game screen classes.

Figure 3 displays the MIDP UI structure.

Figure 3. The MIDP UI structure. Click on thumbnail to view full-size image.

The MIDP v2 specification defines an entire API for gaming applications in the javax.microedition.lcdui.game package. Besides the GameCanvas class, it provides the Layer class that supports tiled or animated game background images. The game API also provides the Sprite class that handles animated figures as well as collisions. They are essential components in 2D graphic games. On the 3D front, Java Specification Request (JSR) 184 tries to standardize the Java 3D API on mobile phones. It has made excellent progress. J2ME 3D tools for developers and artists are already available from SuperScape (see Resources). Large device manufacturers are moving quickly to support this new API on their high-end smart phone devices.

Figure 4 illustrates some of SuperScape's Java 3D games.

Figure 4. Java 3D games available from SuperScape

In addition to the standard MIDP UI and game APIs, several other MIDP UI toolkits exist. They either provide functionalities specific to a device or aim to support a better high-level UI to ease game development:

  • The Nokia UI package provides controls for sound, light, and vibration components on Nokia mobile phones. The Nokia UI also supports true full-screen mode for more professional-looking games.
  • The Motorola Lightweight Widget Toolkit (LWT) is an independent windowing toolkit for Motorola phones.
  • The Nextel Open Windowing Toolkit (OWT) is an open source toolkit developed jointly by Motorola and Nextel. It sports a container model to control layouts and other UI components, which is familiar to desktop UI developers. The OWT is based on the Canvas class and runs on all MIDP phones. However, if you use the OWT library, you must include it in your distribution MIDlet suite.
  • The Synclast UI project develops an open source UI package that supports the container model. Based on the MIDP v1 Canvas class, it supports many MIDP v2 widgets. As a result, it can allow MIDP v2 applications to run on today's MIDP v1 devices with little modification. As with the OWT, you must bundle the Synclast library in the distribution application.

Overall, the MIDP platform offers various choices for rich UI games.

Network and backend integration

As I previously mentioned, the future of mobile gaming is networked multiplayer games. Networking in J2ME is supported through the Generic Connection Framework (GCF). At the core of GCF is a factory class javax.microedition.io.Connector. You can pass a protocol and address string to the static method Connector.open() to obtain a connection object to a remote host:

  • The HTTP protocol support is mandatory in MIDP. If you pass a http://hostname:port connection string to the Connector.open() method, a HttpConnection object will be returned. You can open input/output (I/O) data streams directly on the connection and write/receive data to/from the remote host.
  • The Unix sockets, User Datagram Protocol (UDP) connections, or direct TCP/IP connections are also supported in some implementations. However, you should note that mobile networks are fundamentally different from the wired Internet. Some networks simulate socket connections on top of the HTTP layer. So, the direct sockets do not necessarily yield in performance gains. I recommend HTTP for most occasions.
  • The J2ME Wireless Messaging API (WMA) supports SMS messaging between mobile handsets in the GCF. You can send SMS messages to another handset using a MessageConnection object obtained by the sms://phone_number:port connection string. You can also open a "server" connection that listens for incoming SMS messages using the sms://port string. Incoming SMS messages can be handled synchronously or asynchronously.
  • In MIDP v2, the "server" SMS connection can be registered with the push registry managed by the J2ME runtime. It allows the developer to invoke a message-processing MIDlet upon the arrival of a certain message.

Above the protocol level, J2ME supports several ways to pass structured application data:

  • The MIDP DataInputStream and DataOutputStream classes support Java's convenience I/O methods (e.g., writeInt(), writeUTF(), writeFully(), etc. and the corresponding readXXX() methods) to (de)serialize common data values and objects. Using paired writeXXX() and readXXX() methods on both sides of the communication channel can greatly simplify the developers' work and increase the robustness of end-to-end applications.
  • The MIDP platform supports several XML parsers if you need more structured data exchange. The XML parsers support the Simple API for XML (SAX), XmlPull, and lightweight Document Object Model (DOM) parsing paradigms. JSR 172 (J2ME Web Services Specification) is developing a standardized XML parser API for J2ME.
  • Simple Object Access Protocol (SOAP)-based Web services is the end-to-end integration scheme of the future. The J2ME platform is well positioned to support SOAP message exchanges through third-party toolkits such as kSOAP (see Resources) as well as standardized APIs such as JSR 172.

Data management

On-device data management is a core feature in smart client games. J2ME has strong support in this area:

  • The standard data persistence facility on MIDP is the Recordstore Management System (RMS). The RMS stores binary data (byte arrays) in linear records. It does not allow random access and does not support any hierarchical data structure. But it offers limited functionalities to search the storage and order the search results. The RMS is mandatory in all MIDP devices. It is sufficient for most purposes. However, the MIDP itself does not provide an API to synchronize RMS data with backend applications. JSR 230 (Data Sync API) has just started to develop such a synchronization API.
  • JSR 75 (PDA Optional Packages for J2ME) provides access to the device's native Personal Information Management (PIM) applications (e.g., calendar, address book, email, and to-do list) and filesystem. The PIM data and files can be synchronized to desktop computers through the device's native synchronization suite.
  • For more complex data, you can use mobile databases. Several commercial MIDP databases (both relational and object oriented) and synchronization engines are available on the MIDP platform (see "High-Availability Mobile Applications" (JavaWorld, June 2003)).

Multimedia

Multimedia playback functionalities are crucial in content-driven mobile entertainment applications. The J2ME Multimedia API (JSR 135) is J2ME's standard framework for playing multimedia content. Through the Player interface, it plays multiple audio and video formats from a variety of data sources. The Multipurpose Internet Mail Extensions (MIME) types passed to the player at runtime specify the content format. Each device implementation of the Multimedia API supports a different set of MIME types depending on the hardware and native player capabilities. Currently, almost all Multimedia API-compatible devices support simple ringtone playbacks. Support for more sophisticated formats such as MP3 audio and 3GPP video or even MPEG4 video are just around the corner.

Security

Mobile games involve downloadable code, copyrighted content, and financial transactions. Security is crucial to protect the interests of the users, developers, publishers, and carriers. Security is especially important in multiplayer games where some users try to beat the system by exploiting security holes. J2ME offers excellent support for both application and communication security:

  • The MIDP v2 specification supports application signing using the developer or distributor's digital certificates. Based on the signer's identity (security domain), the runtime security manager can grant API-level access permissions to the application. For example, an application that comes from a less trusted source might not be allowed to make network connections or send SMS messages.
  • The MIDP v2 specification also mandates the support for HTTPS on all handsets. That provides the basis for secure information exchange over the Internet.
  • If the connection-based HTTPS is still not flexible enough for some applications, many third-party cryptography packages are available on the MIDP platform (see "Data Security in Mobile Java Applications" (JavaWorld, December 2002)). They allow the encryption or signing of arbitrary pieces of information.
  • JSR 177 (Security and Trust API for J2ME) is an effort to standardize access to hardware security elements (e.g., the Subscriber Identity Module (SIM) card) embedded in the device. For example, it could allow J2ME developers to retrieve the digital certificate stored on the SIM card or use hardware-accelerated encryption algorithms.

Provisioning and selling

Mobile game delivery to consumers is a complex process that involves many parties. The MIDP specification includes a section about over-the-air (OTA) provisioning. It describes how to download an MIDP game over the Wireless Application Protocol (WAP) network, and how the Java Application Management Software (AMS) should install the application and then make it available to the user. The OTA process provides a feedback mechanism for the client device to report the installation status back to a server. It offers the technical basis for the more complex commercial deployment process. In the commercial world, you should consider several important additional processes:

  • The application must be certified free of viruses and put into a carrier-supported catalog.
  • A different client device might be provided with a different jar file that makes maximum use of the device capability (graphics and installed optional packages).
  • Billing of the customer and payments to the developer must be seamlessly handled. The one-click payment system directly from the phone is critically important.

Several commercial provisioning solutions are already available for carriers and publishers. JSR 124 (Java 2 Platform, Enterprise Edition (J2EE) Client Provisioning Specification) tries to standardize those solutions by defining a generic J2EE framework for client deployment. Plug-ins for different OTA specifications, customer tracking schemes, and billing services can be developed and designed to work together in the framework. Such efforts are crucial to J2ME games' commercial success.

Figure 5 shows the J2EE Client Provisioning Specification architecture.

Figure 5. The J2EE Client Provisioning Specification architecture. Click on thumbnail to view full-size image.

Get gaming

In this article, I explained why multiplayer mobile games with casual contents are the future of the gaming industry. Mobile device manufacturers have seen this tremendous opportunity and have already pushed out devices specifically designed for mobile gaming (e.g., Nokia N-Gage). J2ME/MIDP has emerged as one of the most important technology platforms for those mobile gaming devices and smart phones. After reading this article, you should understand J2ME's strengths and weaknesses in mobile gaming. I also introduced you to the key game-related innovations in MIDP v2 and its optional packages.

Michael Yuan is the author of Enterprise J2ME. He writes and speaks frequently on the topics of J2ME, J2EE, and mobile enterprise applications. Currently, he leads an effort to build a series of blueprint applications for the Nokia Developer Platforms.
1 2 3 Page 2
Page 2 of 3