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.
______________________________________________________
Page 1 of 3