how to write portable java games

How to write portable J2ME games

Thomas LandspurgCTOIn-Fusio

Objectives

• Describes some of the issue that needs to be addressed when trying to create a multiplatform J2ME game:

– Graphics

– Memory

– Speed

– Test

– Business Models

– Deployment

• And to share with you some of the ideas that have been used to solve these issues

About In-Fusio

• Provide Game Services to operators

• First provider in Europe of Downloadable mobile games– Several thousand of players

– More than 100 000 of download per month, 1M of interactions/month

– And got revenues from this!

• Member of JSR118 Game Expert Group

• Developed his own Downloadable game engine (ExEn)

The dream….

• Thanks to J2ME, my application (and more especially my Game) will run on all J2ME compatible devices….

Reality (sometime!)

• Yes, you write once, for one device….

Why….

Graphic diversity

• One of the biggest issue:– Screen size are different

• From 86x48 to 236x240

– Number of colors• 2 to 16 millions

– B&W, Grayscale, Colors

Few ideas and techniques

• Layout management

• Resource management

• Vector Graphic

• Others:– Centering– Rescaling

Game design

• Include layout management in game design:– Define what is variable, fixed to left,

proportional to screen size, etc…

Game design cont…

Other example:Use of tiled background

Two different phones use the same graphics, but the game display area is different.

Resource management

• Do specific version of some resources for different devices (mainly images)

• More complex to handle

• Deployment platform does not always handle this

JPIII image

JPIII_BW.jar

JPIII_ColorSmall.jar

JPIII_GrayScale.jar

Vector Graphic approach

• Instead of using bitmap, use vector gfx– Pro:

• easily scaleable graphics• Data space for graphics usually small

– Con:• not suitable for all games (except 3D ones)

Others techniques

• Centering or Rescaling– « cheap » but bad result

– Centering could be used for small screen size differences:

• Ex: go from 86x65 to 100x70 if games is not designed to be scaleable

– Rescaling:• Actually not possible as there is no API to do this,

but could is useable if multiplication factor is an integer:

– Ex: going from 100x64 to 200x128

– Nice way to provide Wireless game for PDA class devices

Graphics

• All of the technique could be mixed:– First find the best graphics that are available

for the platform (resource management)– Then compute the values for the layout– Finally, if there is still some difficulties, use

centering

Memory available

• Memory between devices differs: – one game running well on one device may crash on

another due to memory issues

• Garbage collection strategy may differ from different devices

• Usually games tends to use maximum of the device memory

• VM implementation may differ from phone to phone

Memory

• Tips and Tricks:– Find good balance between global memory use and

temporary memory use:• Ex: don’t put all image in a single file, but don’t make

an image object per sprite.

– Reduce number of colors used by images– Avoid creation of objects during game– Obfuscator to reduce code size– Avoid too much OO!

Speed

• Games needs to run as fast as possible!

• How to make the same game running on a Strong ARM and on a 16 bits proc?

Speed

• Solutions:– Two strategies:

• Speed should be maintained – use timer and reduce number of object displayed

• Speed is reduced if handset is slower (usual case)

– Impact of not having the game running at the same speed on several devices:

• Real time multiplayer game: faster device will be advantaged

• Contest (non real time): slower devices will be advantaged, because game will probably be easiest

More specific issues for J2ME games

• Keyboard:– Not suited for games, usually only one key

pressed at a time

• Backlight:– Not possible to force backlight on

Multiple APIs

• Proprietary API• Game oriented APIs:

– ExEn

– Siemens

– Nokia

– J-Phone

– NTT-Docomo

– Sprint?

• MIDP1.0 or 2.0?– Transparency or not?

– Game API?

Multiple API

• Not all the API provide the same level of functionalities:– Ex:

• Nokia provide low level pixel based API

• Siemens provides high level games API (Tiled Layer)

• Some fast phone (ex: Nextel Motorola phone) can simulate some of the native API

Business Model

• Different BM may change the Game himself:– Pay per download?

– Pay per play?

– Pay per time?

– Pay per interaction?

– Different carrier may have different billing needs, and they are not always transparent:

• Ex: SMS for billing

Testing

• Image that you have to deploy on all the J2ME devices: how to be 100% sure that the game will run perfectly?

• Correction for one devices: does this haves an impact on others?

• How manage unknown devices?

Testing

• Restrict the number of devices by creating families

• Do some common classes – test them on all devices (and all languages) and reuses them as must as possible – even if these add overhead memory

Tools

• Tools may help you to save time, by creating automatically specific version for specific handsets

• In-Fusio SDK:– Notion of criteria's:

• A resource (image, text, sound, even Java Code) can be depend of criteria's

• Example of criteria's:– Resolution, B&W, operator, language, handset,

etc….

• Then the server manage to get the right version for the right handset, according to criteria's defined by the developer.

Language management

• If you have to provide your Midlet in several languages, then:– Make sure that display is correct in every

language! (painful for testing)

Conditionnal compilation?

• Could be a way to solve some of the issues….

• Does not sounds very good from a design point of view (especially in Java), but life is life…

MIDP 2.0

• Future MIDP will help developer to solve some of these issues by:– Consistent behavior across manufacturers– Improved speed (native implementation)– Reduced code size

MIDP2.0

• Transparency mandatory

• Triangle filling

• Access to pixel level image

• 2D Graphics API:– Tiled Layer– Sprite

• Sound

• Key polling

Wireless Game profile proposal

• JSR178:– How to deploy games on a wide range of device– Avoid horizontal fragmentation (different handset

haves different APIs)– Vertical fragmentation (low end vs. high end)– Intend to address future Wireless Gaming issues:

• 3D APIs• Vector Graphic (Flash?)• Multiplayer oriented game features• …

Conclusion:

• The problematic of Multiplatform must be take in account since the beginning

• It can be solved with– Experience– Good tools

• Take times….

Slides available at

http://www.in-fusio.com/javaone/j2megames.ppt

Thanks you…

•In-Fusion: The mobile game connection– http://www.in-fusio.com– Tel : +33 (0)556 799 200

•Thomas LANDSPURG - CTO– thomas.landspurg@in-fusio.com