Transcript J2ME & BREW Game Design

J2ME & BREW Game Design
Code running on the handset (at last)
Greg Costikyan
www.ungames.com
www.costik.com
[email protected]
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 J2MEenabled 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
www.jamdatgames.com
Diamond Mine
www.jamdatgames.com
Micro Nitro
www.morpheme.co.uk
Froggy
www.perimind.com
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