J2ME & BREW Game Design Code running on the handset (at last) Greg Costikyan

What is BREW? Binary Runtime Environment for Wireless Tied to CDMA (in practice, if not theory) Strongly supported by Verizon, Alltel Korean carriers, KDDI in Japan, Bell Mobility in Canada Like Java, runs in a virtual machine (on the hardware) Qualcomm is the Gatekeeper Write apps in C, C++, or Java

What is J2ME? Java 2 Micro Edition (for small device CLDC: Connected Limited Device Configuration MIDP: Mobile Information Device Profile Runs on a virtual machine (KVM, <80k) Java-enabled phones available in Japan, Korea, Europe, through Nextel; major commitment by Sprint, support from all major manufacturers Carriers are the Gatekeepers (but Motorola for Nextel)

Which Should You Use? Little difference in technical capability Largely a business decision Likely to be a larger installed base of J2ME- enabled handsets

Why Develop J2ME/BREW Games? Run apps on the handset (not all logic has to be on the server side) Much better control over UI Small User Base at Present (but likely to grow fast) An area of carrier focus

How it Used to Work a. Download applet to your PC over the Internet. b. Hotsynch your phone to install applet. c. Can’t install applications over the air network. d. In Asia, applets can’t communicate over the network—soloplay only.

How it Now Works a. User makes a network connection, browses carrier’s list of midlets, chooses one. b. HTTP request goes out over air network, is routed to remote server on the Internet. c. Server sends midlet to handset, where it is installed. d. Network sockets are exposed to J2ME on the handset, so midlets can send and receive data with remote servers.

Technical Limitations Midlets must be <50k (or so) No simultaneous key presses No support for image transparency Cannot edit bitmaps on the fly, no blitting Can’t assume any audio support No floating point math No JNI or AWT

What We Can Rely On High-Level UI Features: PNGs & bitmaps Text Entry Select lists (radio buttons) & Multiple select lists (check boxes) Bar graphs Support for standard phone keys (0-9, *, #, arrows) Abstracted game controls Low-Level UI Features: Canvas Graphics HTTP

Latency > WAP? With WAP, latency = air network + Internet latency With J2ME, add HTTP handshaking UDP is supported but not mandatory but exists on Motorola/iDen handsets (Nextel) An area of carrier focus

Keep Network Access Sessions Short People pay by the minute— but YOU get nada 5-10 minute sessions offline as well as online components—simove, deck construction

Network Still Unreliable Irrelevant for soloplay If connection is intermittent, game needs need to sense network failure If connection continuous, handle drops gracefully

Dealing with the 50k Limit Keep text short Use (& reuse) small number of graphics Use a code obfuscator Minimize the number of inner classes Collapse the class hierarchy Maximize use of pre-installed classes Consider using multiple midlets

Making the Most of Graphics No inherent support for layers Tiled Backgrounds (or images at discrete locations on blank background) Limit number of sprites & behaviors

Thinking About UI Handset is similar to a console controller Motion for a single actor: arcade-style, RPGs Select an actor, select a destination— simple strategy games Select-lists = menus 11 buttons: NetHack-style UI

What Kinds of Games Can We Do? Primitive skill-and-action games (retro arcade) Classic board & card Console-like games with simple controls (gold, driving) Levelware Networking is STILL where mobile phones have an advantage

Jamdat Bowling

Diamond Mine

Micro Nitro

Froggy

URLs Obfuscators: retrologic.com J2ME Wireless Toolkit: java.sun.com/products/j2mewtoolkit/ Useful Articles: wireless.java.sun.com/midp/articles/