Upload
colt-cleavenger
View
217
Download
0
Embed Size (px)
Citation preview
What is BREW?
Binary Runtime Environment for Wireless
Tied to CDMA (in practice, if not theory)Strongly supported by Verizon, AlltelKorean 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 blittingCan’t assume any audio supportNo floating point mathNo JNI or AWT
What We Can Rely OnHigh-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 sessionsoffline as well as online components—simove, deck
construction
Network Still Unreliable
Irrelevant for soloplay
If connection is intermittent, game needs need to sense network failureIf connection continuous, handle drops gracefully
Dealing with the 50k Limit
Keep text short
Use (& reuse) small number of graphicsUse a code obfuscator
Minimize the number of inner classesCollapse the class hierarchyMaximize use of pre-installed classesConsider 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, RPGsSelect an actor, select a destination—simple strategy gamesSelect-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