How to write portable J2ME games Thomas Landspurg CTO In-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

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)

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

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

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

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

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…

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

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

More complex to handle

Deployment platform does not always handle this

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)

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

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

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

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?

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

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

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?

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

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

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?

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

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.

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)

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…

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

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

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 …

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

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

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 [email_address]

In-Fusion: The mobile game connection

http://www.in-fusio.com

Tel : +33 (0)556 799 200

Thomas LANDSPURG - CTO

[email_address]