It's free to join Gamasutra!|Have a question? Want to know who runs this site? Here you go.|Targeting the game development market with your product or service? Get info on advertising here.||For altering your contact information or changing email subscription preferences.
Registered members can log in here.Back to the home page.

Search articles, jobs, buyers guide, and more.


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


join | contact us | advertise | write | my profile
news | features | companies | jobs | resumes | education | product guide | projects | store



Copyright © 2003 CMP Media LLC

privacy policy
| terms of service