How to write portable Java Games
Upcoming SlideShare
Loading in...5
×
 

How to write portable Java Games

on

  • 8,891 views

A presentation that I've made in JavaOne 2003 about making portable JavaGames.... http://blog.landspurg.net

A presentation that I've made in JavaOne 2003 about making portable JavaGames.... http://blog.landspurg.net

Statistics

Views

Total Views
8,891
Views on SlideShare
8,860
Embed Views
31

Actions

Likes
2
Downloads
105
Comments
1

1 Embed 31

http://www.slideshare.net 31

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • no, nyet, nahi....which part of no don't you understand?
    I'm not interetsed in helpin' yuh
    I'm not yor daddy..got that?
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    How to write portable Java Games How to write portable Java Games Presentation Transcript

    • 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
    • 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_address]
    •