Develop state-of-the-art mobile games

Throughout the IT industry’s history, computer games have been one of the drivers behind technology innovations. Computer gamers are hungry for more hardware computing power; they are eager to push the limits of various software—from compelling graphics to artificial intelligence (AI) to network security. Game developers and players are often the earliest adopters of leading-edge computer technologies. Due to their innovative nature, games are not in danger of becoming technology commodities controlled by big outsourcing corporations—there is always plenty of room for talented individual innovators in this space.

The market for games will continue to grow as the technology enhances the playing experience. As the enterprise IT revolution improves our work life by saving time and money, we spend more time and money on games to improve the general quality of life. Even in today’s difficult economic times, gaming remains a fast growing and profitable industry sector. Java developers should not overlook the tremendous opportunities here.

As in the rest of the IT industry, the latest buzz in the game industry is mobility. Mobile games have brought together many unlikely players from traditional enterprise companies (e.g., Sun Microsystems’ new game division), equipment manufactures (e.g., Nokia’s N-Gage and Qualcomm’s Brew devices), and network operators (e.g., Vodafone’s content services).

As Java developers, we are well suited to enter this profitable new industry sector because the Java 2 Platform, Micro Edition (J2ME) is emerging as one of the most widely supported mobile gaming platforms. In this article, I discuss the opportunities and challenges of mobile gaming from a Java developer’s perspective. I also survey state-of-the-art mobile Java technology through important J2ME specifications.

Mobile game characteristics

Mobile games’ financial appeal comes from their wide reach. Mobile phones have become tightly integrated into the modern lifestyle. They are second only to keys and wallets as the most commonly carried personal items. Unlike traditional console games that target geeks and teenagers, mobile games are accessible to anyone—anywhere, anytime. Although each mobile game is inexpensive, the projected large volume (e.g., a new game per week per person) will make this market immense and profitable. However, for developers, mobile games present a big paradigm shift from console games due to the vastly different target audience, lifestyle, and distribution models. Let’s start with mobile games’ requirements.

Requirements

A successful mobile game will likely have one of the following characteristics:

• Easy to learn: Since mobile games target general consumers not computer-savvy techies, they cannot have steep learning curves. Consumers will not spend hours studying an operation manual of a game. The game must be playable the moment it is downloaded. It is essential to keep the game simple.
• Interruptible: Multitasking is a basic characteristic of the mobile lifestyle. A mobile user often has small chunks of free time available between tasks (e.g., while waiting for an email or a taxi to arrive). The same device is used for games, calendar management, messaging, and work data access. A good mobile game should provide entertainment value for short time periods and allow users to switch smoothly between game and work modes.
• Subscription based: Mobile games’ financial success depends on their large volume. It is expensive to design and develop each game from scratch. For a mobile game developer to make money, it is important to offer multiple titles from the same game engine along similar basic storylines. Subscription-based games are the best way to generate sustained revenue.
• Rich social interactions: No matter how good a game design is, it quickly becomes boring when the player figures out the underlying pattern or has exhausted all the play routes. For subscription-based games, it is important to incorporate other human players to increase the intelligence and randomness of the game play. Games with rich social interactions have proven successful in many of today’s massively multiplayer games.
• Take advantage of mobile innovations: A huge amount of mobile technology research dollars have been spent on improving the usability and reliability of devices and networks. As a result, the mobile device hardware and network protocols are very different from the desktop/console world (e.g., Global Positioning System (GPS) extensions, barcode scanner, and Short Message Service (SMS)/Multimedia Message Service (MMS) messaging). Good mobile games should take advantage of those innovative device features and network infrastructures.
• Nonexplicit content: Since all age/gender groups play mobile games and often in public/work settings, you should avoid explicit violent or sexual content.

Types of mobile games

Based on the above criteria, the most successful future mobile games are casual games that provide entertainment value to a broad range of players in all social settings. In particular, the following types of games are emerging as tomorrow’s killer games:

• Multiplayer games: Those games could provide mobile access to established online game communities. Or, they could create completely different social structures taking advantage of mobile-specific features such as the multimedia messaging and location-based services. Good game design and management are crucial to this type of game’s success.
• Content-based games: Those games deliver copyrighted multimedia entertainment content, such as celebrity photos, video clips, voice ringtones, and personalized sports games to music/movie/sports fans. The key to success is to provide a flow of high-quality content that justifies the subscription cost.
• High-impact visual games: PC and console games have evolved from 2D to 3D. Mobile games will follow this trend too. There are already several mobile 3D toolkits and handsets available. However, 3D games are very resource intensive. They require expertise from both developers and graphic designers. Professional shops will most likely develop these games.

During mobile games’ early days, most developers were enthusiasts who wanted to play with their devices, learn new skills, and make a quick buck. However, as more developers enter this space, mobile games have evolved into major productions that involve professional designers, architects, developers, business dealers, lawyers, and artists. This is an inevitable trend as the industry matures. For developers, this change poses both challenges and opportunities. While it is harder to develop and sell simple games in one’s spare time, more pro shops will offer better employment opportunities for many people.

The mobile value chain

To fully understand the mobile game landscape, you must understand how the money flows. This business’s value chain is considerably different from traditional games or enterprise applications:

• Developers: Software developers drive the value chain by creating great applications. However, most developers do not have the capacity to handle mass marketing. They also lack the distribution channels to reach consumers.
• Publishers: Game publishers aggregate titles from developers. They build a brand name, certify the game for technical correctness, promote the game, and build business relationships with wireless carriers. Publishers also handle billing on the developer’s behalf and typically share revenue with the developer.
• Wireless carriers: Wireless carriers are at the center of mobile game distribution channels. Carriers not only control the network but also own the customer information. It is up to them to decide what devices and services to support. Carriers take a big chunk of money out of the overall profit. Carriers can also bill the customers through existing service agreements.
• Wireless device manufacturers: Device manufacturers drive the technical innovation. They make new hardware and support development platforms. In fact, J2ME’s success is largely due to major device manufacturer adoption. Device manufacturers represent an independent force between carriers and consumers.
• Consumers: Consumers eventually pay for the costs and margins incurred for the providers along the chain. A consumer can purchase games from the publisher’s Website or through content provisioning systems provided by the carrier.

Figure 1 shows the value chain.

J2ME smart clients

The J2ME platform has emerged as the most prominent mobile gaming platform widely accepted by developers, device manufacturers, network carriers, and consumers. It has some very important features that benefit all parties.

Smart client characteristics

J2ME devices are smart. They can process information on their own. These are the most important characteristics differentiating J2ME smart phones from previous generations of mobile phones:

• For users, a smart mobile phone’s most appealing feature is that you can play games without always-on network connections. Offline mode is necessary in today’s 2-2.5G networks where the coverage is sporadic and data traffic is expensive. The ability to cache data and queue network operations into transactions also significantly reduces the wireless network and improves application reliability.
• Smart clients can integrate with backend game servers and peers (both wireless peers and Internet peers) using various protocols.
• Smart clients support rich user interface (UI) features crucial for visually appealing games.
• Smart clients can access mobile-specific network (e.g., SMS and MMS) or device extension (e.g., GPS) features. This makes it possible to develop games that take full advantage of the mobile lifestyle.
• Smart clients offer stronger and more flexible security through advanced encryption and digital signature algorithms. With smart clients, it is possible to transport sensitive user privacy data over the Internet and build effective online societies.

A portable platform

Compared with other smart client platforms, J2ME has a unique advantage: it is designed for mobility. J2ME applications run on various devices from numerous vendors. That is extremely important in the highly competitive mobile device business due to the large number of different devices. All major smart phone manufacturers have committed to support the J2ME platform. Code portability is crucial for developers who want to maintain a single codebase yet still reach the maximum number of consumers.

J2ME solves the “lowest common dominator” problem, which has plagued desktop Java before, by defining a multilayer architecture consisting of configurations, profiles, and optional packages. So far, in the mobile game industry, the most popular J2ME platform is Mobile Information Device Profile (MIDP) and the optional packages built on top of MIDP. In this article, I focus on the MIDP v2 platform.

Figure 2 shows the J2ME architecture.

Since J2ME applications are portable across various devices, they are often downloaded and executed over the network. Without proper precaution, that can open enormous security risks for both users and wireless carriers. Fortunately, Java is a secure language by design. All byte-code applications are verified before execution; the JVM monitors the applications for security and memory violations during the execution. The MIDP v2 runtime includes a fully featured, domain-based security manager that grants API-level permissions to applications based on the identity of their digital signer.

Thanks to J2ME’s wide adoption, mobile Java developer support has grown into a sizable market. Almost all popular Java development tools have been adapted to fit J2ME developer needs. J2ME libraries and components are readily available from third-party providers. Many of those libraries provide similar features to their Java 2 Platform, Standard Edition (J2SE) counterparts. For example, the IBM Service Management Framework (SMF) supports Java servlets on PDAs; the PointBase Micro Edition provides a Java Database Connectivity (JDBC)-like access method for mobile relational databases; and the IAIK JCE-ME supports a lightweight version of Java Cryptography Extension (JCE). Those tools and libraries make it easy for J2SE developers to migrate their skills to the mobile world. In turn, that creates a large developer base for J2ME vendors to leverage. The positive feedback cycles will help J2ME’s growth.

A survey of APIs and tools

In this next section, I survey J2ME game-related APIs and examine the capabilities they provide for developers.

User interfaces

The MIDP runtime provides fine-grained controls over the mobile device’s screens and hardware keys. All MIDP UI classes inherit from the javax.microedition.Displayable interface:

• 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.

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.

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.

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.