how to write portable java games
DESCRIPTION
A presentation that I've made in JavaOne 2003 about making portable JavaGames.... http://blog.landspurg.netTRANSCRIPT
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– [email protected]