1. J2ME & BREW Game Design Code running on the handset (at last) Greg Costikyan www.ungames.com www.costik.com costik@costik.com costik@costik.com

2. 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

3. 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)

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

5. 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

6. 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.

7. 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.

8. 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

9. 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

10. 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

11. 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

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

13. 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

14. 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

15. 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

16. 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

17. Jamdat Bowling www.jamdatgames.com

18. Diamond Mine www.jamdatgames.com

19. Micro Nitro www.morpheme.co.uk

20. Froggy www.perimind.com

21. URLs Obfuscators: www.alphaworks.ibm.com/tech/JAX/ retrologic.com J2ME Wireless Toolkit: java.sun.com/products/j2mewtoolkit/ Useful Articles: wireless.java.sun.com/midp/articles/ www.gamasutra.com/resource_guide/20010917/fox_01.htm