Mobile game development using J2ME is not all it's chalked up to be. In theory, J2ME offers a compile once, run everywhere environment. In practice, however, the platform is very fragmented. From game developer's point of view, this platform consists of hardware, software, and back-end technology that is very often unique or proprietary to the mobile phone hardware or service provider.

Finland-based Sumea is an award-winning publisher and developer for downloadable mobile games. Our current portfolio contains 17 games, but we have developed over 40 J2ME titles in total. Our games are played in more than 40 countries through over 55 distribution partners in Europe, the United States and Asia. As the Chief Technology Officer at Sumea, I have developed coding techniques that deal with these disparities-by carefully structuring our code and separating the segments that need to change depending on the device and service provider.

This fragmentation not only makes it difficult for individual developers to create games that work on multiple mobile phones and with multiple service providers, it also hurts the mobile game market as a whole. At Sumea, we've felt the strain from this fragmentation. I remember the excitement I felt in 2000 when the first version of the J2ME Wireless Toolkit from Sun was released, and the high hopes I had for the first handset based on it. Sumea started developing J2ME games in the summer of 2001, when that handset, the Siemens SL45i, was released. I recall the thrill of getting our first MIDlet running on it.

When we started mobile game development, we couldn't find references to proven techniques nor ideas -- therefore we had to come up with the ideas described here on our own. This doesn't mean all these ideas have originated from us: The mobile game development community is strong, and we talk with each other a lot--sharing new ideas, daily pains, and so on. Thanks to all of you.

In this article I'll provide insight into the J2ME platform from the perspective of a developer who's kept an eye on this moving target. Let's see where the market stands today, examine how we got here, and try to get a sense of what direction J2ME is going.

Until things shake out and we see some de facto standards emerge, we're in for a wild ride, but I hope the techniques I present below will help you to get a grasp on the situation, better plan upcoming mobile game projects, and enjoy the ride.

J2ME Fragmentation Today

It's amazing to look back a few years and see how much mobile devices have changed. Today there are over 30 different J2ME-enabled handsets, many with color screens, support for polyphonic sounds, and interesting keyboard configurations.

But of course, the growth hasn't been painless. With this rapid evolution has come an assortment of capabilities, yet no real standards for many of the features. For instance, screen resolutions range from 101×80 pixels up to 640×320-with a dozen sizes in between. The range of processing power in these devices is also vast, with the high-end handsets having up to 90 times the processing power of the feeblest ones. The amount of heap memory ranges from 200K to over 1MB. In addition, application file size limitations are different: In the early days the limitation ranged from 30K to 50K, whereas today it ranges from 60K to about 200K.

Underlying software layers have proliferated, too. The basis of Java mobile game development lies with the Connected Limited Device Configuration (CLDC) 1.0 and Mobile Information Device Profile (MIDP) 1.0 APIs. On top of these there are usually manufacturer-specific APIs, which give game developers access to sounds, vibration, backlight, and in some cases other functionality (such as game-specific APIs). These APIs are proprietary and must be provided because there is currently no standard way to access this functionality. Some handsets provide other standardized APIs as well, such as the Mobile Media API (with which one can play MIDI sounds) and Wireless Messaging API (to send SMS messages).

Furthermore, the base API implementations are different. For example, MIDP 1.0 does not strictly define program flow and phone event handling. In practice this means that the behavior can be different in the case of an incoming call, calendar event, and incoming SMS. This means that a game developed for one MIDP version might not work the same way in another-or it might not work at all.

One of the hot topics at the moment are so-called communal and network features, which enable features such as centralized high scores and event-based billing. This lets a player send his best score to a server, or buy additional features for the game. Yet because the means to implement these features are provided by, for
example, the mobile game provisioners, we again face the problem of disparate APIs. To support these features, one has to either implement the network communication interface or embed a third-party API into the game. At the moment, Sumea supports six different high score APIs.

J2ME Fragmentation Tomorrow

While today the base platform consists of MIDP 1.0 and manufacturer-specific extensions, the next step will be MIDP 2.0. There are already some MIDP 2.0 devices available on the market, and there will be more of them next year. The most important aspect of MIDP 2.0 is that it assumes the functionality of most manufacturers' proprietary APIs. MIDP 2.0 provides standard access to vibration, sounds, and game-specific APIs. Additionally, MIDP 2.0 contains other useful features, including an optional API for socket-based communication. This means that devices don't have to poll for updates from a server using HTTP-the server can push data to the device instead. There are other interesting features that help make the application work more seamlessly in the device: it is possible to launch a browser from within a MIDlet using a URL, or to launch a MIDlet by sending an SMS targeted at the application, for example. Yet while MIDP 2.0 is great in all of these respects, it does introduce one rather significant problem: for the time being, game developers have to support MIDP 1.0 and MIDP 2.0.

The future of handsets looks bright: The processing power will improve, the screens are getting larger, they have better refresh rates, and the amount of memory is increasing. One interesting topic is the various combinations of screen sizes, processing power, amount of heap memory, and file sizes. Large resolution screens look good, but on the other hand, large graphics require lots of run-time memory and processing power and they increase the application file size. Exactly how tomorrow's mobile phones will deal with these issues remains to be seen, but we developers will be the ones who will have to live with the eventual outcome.

Whatever happens, one thing is certain: The capabilities of the high-end hardware will improve faster than the low end can follow. From game developer's point of view, this means more devices to support with more disparity between their capabilities. Yet there are two important reasons to support as many platforms as possible: to reach the widest possible audience, and because content providers (like mobile game publishers) spend more money marketing games which support many devices.