|
 Resource
Guide
Creating
Games using J2ME
With
the advent of Java 2 Micro Edition (J2ME) on mobile phones, it is
now possible to create mobile games that aren't all that crappy!
Now, don't get me wrong. Some
creative folks have devised truly interesting games using the
Wireless Application Protocol (WAP). But that's sort of like building
a skyscraper out of Popsicle sticks-in the end the simple text-pushing
protocol just won't cut muster if you want responsive, graphically
rich games. Gladiator, one of the most popular WAP games, is really
nothing more than a rock-paper-scissors clone!
For several years now, phone manufacturers have had native hardware
capable of supporting decent games. Nokia's
Snake game is probably the most notable example. But mobile
phone developer's kits are often proprietary. And downloading, installing,
sharing, and porting these games is an all-but impossible task.
J2ME Overview
The Java 2 Micro Edition (J2ME) is a true-to-its-word subset of the
standard Java libraries. J2ME consists of:
-
The
Kilobyte Virtual Machine (KVM). This resides on the handheld device
and actually runs the bytecode you write.
-
Configurations.
These are the core classes that must be implemented for a particular
type of device. For example, the Connected, Limited Device Configuration
(CLDC) is meant for any device that has limited memory, screen size,
and input abilities, but that is connected to a network. This includes
most mobile phones. Companies like Sun, 3Com, Bull, Ericsson, Matsushita,
Mitsubishi, Motorola, Nokia, NTT DoCoMo, and Siemens helped hammer
out this standard.
- Profiles.
These are Java libraries for specific brands of devices. All the user
interface, programming and event models, networking, and error handling
is implemented in one of these. For example, the Mobile Information
Device Profile (MIDP) was developed using Sun's Community Process by
companies such as AOL, Palm, Nokia, Sony, NEC, Motorola, Alcatel, Ericcson,
NTT, DoCoMo, Psion, and Siemens. There are different profiles for different
device families, with one currently being spec'ed out for the Palm.
While
various J2ME profiles can run on anything from advanced
set-top boxes to tiny chips on smart credit cards,
for the sake of this article we will focus MIDlets-applets
in the CLDC configuration written to the MIDP profile.
Note that you can run MIDlets on your Palm as well.
Check
out this page, which has full instructions on
converting MIDlet packages and deploying them on
the Palm.
Games on Phones?
Mobile phones are a bold new platform for gaming.
Today, there are more than 600 million mobile-phone
users worldwide. Mobile phone users generally tend
to be affluent, educated, and they often have lots
of time on their hands. In the United States, for
example, people spend 50-percent more time commuting
than any other country (Yankee Group). This is the
perfect time to pull out a mobile phone and play
some quick games.
In the near future, we will likely see micro devices
become even smaller and specialized. Phones the
size of earplugs, voice-activated assistants on
wristwatches, and smart chips on credit cards are
all becoming a reality.
Unsurprisingly, games are keeping up and even helping
to lead this paradigm. While it may seem silly to
try to achieve a rich, meaningful immersion on a
tiny 100x100 pixel screen, there's one thing mobile
phone games give you that even the best consoles
can't provide: They're always with you, and can
be played anywhere you go. This not only means that
games can now be more convenient, but wholly new
types of games can be designed that take advantage
of new lifestyles.
The Joy of Java
Most every major mobile phone and handheld device
manufacturer immediately realized the potential
of J2ME: If Java were to be placed on the gadget,
then hundreds of thousands of developers would immediately
be able to create applications and add value. Furthermore,
because it's Java, a program written for one device
would be able to run on another device with little
or no modifications. That certainly makes more sense
that trying to force developers to learn a native
language and API in order to create programs for
your phone.
And so, most every major mobile phone manufacturer
joined with Sun to create something called the CLDC:
The Connected, Limited Device Configuration, along
with the MIDP: The Mobile Information Device Profile.
Mobile phone manufacturers have definitely embraced
Java in a way that not even PC manufacturers and
browser makers have. Java is clearly the future
platform of choice for mobile devices, and an ideal
platform for mobile games.
The Bad News
Programming games for handheld devices is a total
pain. The screen is miniscule—160 by 160 on
the Palm, and much less on mobile phones. The memory
is limited—the Palm only gives you 2 to 8 Meg,
depending on the model. You have little dynamic
memory to play around with—most mobile phones
only give you 32K, the Palm has a 96K heap limit.
There's limited network connectivity, with a teeny,
tiny 9.6 kilobit per second bandwidth. And the processor
itself is often hundreds of times slower than your
average desktop.
Programming in a language like Java only adds a
layer onto this hard-to-digest cake. Sun's Kilobyte
Virtual Machine (KVM) gets its name because it takes
up a few kilobytes of space. But even those few
bytes are wasteful. The KVM also usurps a fair bit
of memory. A native application is the size and
power it is, asking for nothing more. In addition,
Java classes have the added overhead of a slow startup.
While startup is going on, the KVM is going through
the class, allocating heap space and verifying the
bytecode.
Additionally, a Java programmer is restricted to
the capabilities of the virtual machine. Because
Java must work on a wide variety of devices, it
is written for the lowest common denominator.
For example, here are some big stumbling blocks:
-
No
transparent images. Without transparency, overlapping
sprites look really prickly. Any image that may
overlap another image, or a background element
will need to be rectangular in order to look good!
-
You
cannot grab, copy, or edit the pixels of RGB images
on the fly. This means that ultra-cool graphic
effects like fading in, explosions, and dynamic
shadows are impossible.
-
There
is no fill-polygon or fill-triangle method, which
makes rendering 3D images quite difficult.
-
You
cannot copy raw pixel data to the screen (blit).
This makes is pretty much unfeasible to do any
texture-mapping or particle effects, etc.
-
There
is no audio at all. I'll say that again: There
is no freakin' audio at all!
-
There
is no floating-point math. This makes some 3D
and physics pretty difficult.
- There
is no native support or Java Native Interface (JNI). That means you
can't dial the phone, work with any of the ringtones, work with any
native user interface widgets, etc.
Additionally,
the Anfyteam
in Italy has put together a detailed list of gaming and graphics-related
stuff that MIDP is missing.
Due to all the restrictions on a small device, there is no way of fitting
in a just-in-time compiler (JIT). This means code will run quite slowly.
In fact, while playing around with some casual tests, a Java 2 Micro Edition
(J2ME) application runs about three to eight times slower than a native
Palm application written in a compiled language such as C.
If you want to get some idea of the graphics speed of J2ME, the Anfyteam
has created a great benchmark called Amark.
So is J2ME like war—good for absolutely nothing?
________________________________________________________
 The
Good News
|
|
|
|
|
