|
|
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Games on the Run: BREW and J2MEGames on mobile phones are nothing new. With NTT DoCoMo's famous iMode service, Japan has gone mobile-game crazy, and even we Stone Age Americans and Europeans have been able to squeeze some entertainment out of primitive text WAP games on our handsets. A new generation of phones similar to those available in Japan is approaching Europe and the Americas, however, and two major platforms are vying for supremacy over these new handsets. Sun Microsystems' Java 2 Micro Edition (J2ME) and Qualcomm's Binary Runtime Environment for Wireless (BREW) emerged in the last half of 2001 as the leading development environments for mobile gaming.
The concept of Java on embedded and small devices has been around for some time. Sun's efforts to provide a slimmed-down Java have taken many forms over the years, including the Java Card API and PersonalJava, a predecessor of sorts to J2ME; the Japanese handsets used with iMode have a customized version of Java developed before Sun could finalize a J2ME standard. When we speak of J2ME for mobile phones, we really mean J2ME using the Connected Limited Device Configuration (CLDC) and the Mobile Information Device Profile (MIDP) running on top of the K Virtual Machine (KVM). Essentially, the CLDC and MIDP define a set of Java services and language features available for a family of related devices, in this case, mobile phones and other similar technologies. These Java features are implemented on top of a special virtual machine, KVM, designed to be compact and portable to many small devices. Applets developed for MIDP are called MIDlets. This article uses CLDC/MIDP as the platform to compare with Qualcomm's BREW. The development environment. Most Java IDE vendors have made J2ME/ MIDP support a prominent feature in their new Java development tools. However, Sun's free J2ME Toolkit, available at http://java.sun.com/j2me, has just about everything you need to begin developing a MIDlet.
Among the most useful tools in Sun's J2ME Toolkit is KToolbar, a simple project manager that allows you to load, compile, and run MIDP projects through a clean, elegant GUI. KToolbar also allows you to run your MIDlet in Sun's standard device emulator while seeing debug output and error messages in its main window. However, the emulator doesn't accurately represent how your code will behave on the real device. First, the emulator doesn't reflect the handset's performance; the emulator's speed depends entirely on your computer's CPU. Your applet will run much slower on actual hardware. Sun's emulator is also inaccurate in other ways. In the case of Motorola's i85 iDEN handset, simple operations such as the placement of "soft buttons" (tool tips for function buttons on the handset), the behavior and display of GUI components, and basic graphics operations vary wildly from emulator to handset. Even the screen resolution on the emulator is wrong (1113100 on the handset, 105378 on the emulator). In the end, there is no substitute for testing your MIDlet on an actual handset. So, how do you actually test your MIDlet on a real handset? This is not part of the J2ME Toolkit, but depends on tools provided by the handset manufacturer. In the case of Motorola, their Java Application Loader (JAL) can be found on the iDEN developers' web site, www.motorola.com/iden. This tool allows you to upload .JAR files containing your MIDlets to any of their iDEN handsets. It's worth mentioning that there is some effect that Java itself has when developing for such small hardware. Java's language conventions make it somewhat difficult to keep code size small. However, using Java also means you generally don't have to worry about strange memory errors and pointer math. Also, the phone OS handles a lot of housekeeping issues for you, such as suspending your applet when an incoming call is received. And MIDP includes handy collection classes such as vectors and hashtables. Overall, working with the J2ME development environment is a real pleasure. Whether you are using the included KToolbar application or the J2ME editions of any major Java IDE, the process of programming and running MIDlets on hardware is a snap. There are plenty of issues with emulation performance and accuracy, but given the scope of the average mobile game, they are relatively minor. With every release, Sun continues to improve their tools. Graphics features. The structure of J2ME's graphics system is similar to that of the Java 2 Standard Edition (J2SE). The familiar image and graphics classes are available, but with less functionality. J2ME's native file format is .PNG files, with devices commonly supporting 1- to 8-bit color. Palettes are hard-coded in most handsets, so colors are mapped to the closest match. Pixel transparency, often thought to be impossible with MIDP, is actually an optional part of the MIDP standard, but it's up to the handset manufacturer to support this option. The usage of the image class allows for off-screen images and, therefore, double buffering. Many handsets have double-buffered displays by default, requiring no additional programming. Although it's possible to create an image from an array of bytes as pixel data, it's impossible to do the opposite. This means pixel-level access to bitmaps is impossible, or at least extremely annoying. Aside from images, the graphics class supports the drawing of different geometric primitives such as boxes and lines as well as text. GUI. MIDP has done away with the Abstract Windowing Toolkit (AWT) package and replaced it with a package called LCDUI. This package has a set of GUI control classes that are suited for the display of a mobile device. MIDP's GUI components are grouped into two types: items and screens. Items are GUI controls in the traditional sense: components that can be added to a screen to build an interface. For instance, you can add a text field, a static text string, and a bitmap image to create a screen of several different GUI components. Or, you can use GUI controls that are screens themselves. For example, the list screen is a simple menu of selectable items. Since this takes up the entire screen, you can't combine the control with bitmap images or other custom graphics. The screen system can be rather inflexible, and both types don't allow you to explicitly position controls in pixel coordinates. Cost. Aside from the cost of a phone, you can begin J2ME development without spending a dime. The prices vary on the different commercial Java IDEs such as Metrowerks' CodeWarrior, Borland's JBuilder, IBM's VisualAge, and others. Sun's J2ME Toolkit also integrates with their own free Forte IDE. The real cost comes with getting your MIDlet tested with each carrier for distribution. These testing runs can often cost thousands of dollars. Considering the myriad of carriers who support or have announced support for J2ME, this can get expensive. Documentation. J2ME comes with extensive documentation in the form of HTML files. Sun's J2ME Toolkit comes with many sample programs which display features such as GUI controls, graphics, and network communication. There are also a few great books out on the market about J2ME. Support. There are several developer mailing lists and web boards for most J2ME handset manufacturers. With these resources, you will find company representatives and helpful developers answering questions and posting news on new tools, hardware, and events. Final comments. J2ME and MIDP are a relative breeze to get started and develop with. MIDP, while basic, gives enough functionality to develop games. However, the Java language makes writing compact code somewhat of a chore. J2ME handsets vary in performance. Motorola's iDEN hardware is impressive: with a reasonable blitting speed, it's possible to squeak out about 12 frames per second for a simple action game. Unimpressive perhaps, but I have seen competing J2ME handsets with frame rates in the single digits. Because J2ME is an open standard, each carrier and handset manufacturer is free to add its own custom packages to the default installation. However, porting code between different flavors of J2ME is relatively painless. Each carrier also has its own testing guidelines and billing standards, so you need to set up a billing relationship and get your applet tested by each carrier before being distributing on their network. ________________________________________________________ |
|||||||||||||||||||||||
|
|
J2ME
Resource
Guide 
