 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 178: Mobile Game API
Reason: This JSR was not approved by the ME Executive Committee in the JSR Reconsideration Ballot. JCP version in use: 2.1 Java Specification Participation Agreement version in use: 1.0 Description: Defines an optional package that will facilitate the emergence of the market for the development of compelling games on mobile phones. The API shall work with MIDP1.0. Please direct comments on this JSR to the Spec Lead(s) Team
This JSR has been Rejected
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: In-Fusio Name of Contact Person: Frederic Condolo E-Mail Address: frederic.condolo@in-fusio.com Telephone Number: +33 557 773 800 Fax Number: +33 556 400 548 Specification Lead: Thomas Landspurg E-Mail Address: thomas.landspurg@in-fusio.com Telephone Number: +33 557 773 808 Fax Number: +33 556 400 548 Initial Expert Group Membership: A broad base of key actors in the mobile gaming eco-system? have proposed their support or active participation to ensure we determine a widely accepted API-set responding to the needs of all actor types.
Mobile Operators: Supporting this JSR: Mobile Operators: Section 2: Request
2.1 Please describe the proposed Specification:The Mobile Game API provides a consistent Java framework for the mobile industry. It defines an optional package made of a set of Java classes designed to address the problem of creating a wide range of games on mobile devices, with limited resources.
1.Sprite manipulation (including rescale and rotation) Some of these functions are available using a combination of other general J2ME APIs, but the objective of this package is to provide highly optimised games oriented functions as execution speed is one of the key factor for games and the sheer size of the gaming market warrants it (see 2.3 below). The work will be an extension of the Gaming API defined in MIDP2.0. It is expected that this extension could run also on top of MIDP1.0. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)constrained MIDP based device, typically mass market. Expected footprint for the total API is to be less than 100kb. 2.3 What need of the Java community will be addressed by the proposed specification?Downloadable Java games are proving the most attractive application both on mass market mobile networks in Europe and even on business oriented networks (eg Nextel) in the US. The belief shared by those supporting this JSR is that this is likely to remain the case for the foreseeable future. Many manufacturers have recognised this and given the level of market demands for Wireless Java Games, they have defined their own proprietary Game API and contributed to generate fragmentation. This JSR will avoid such fragmentation and ensure a faster development of the Java market: (a) by providing a suitable deployment environment for Game developers for whom the basic need is to write fast and appealing games on such limited devices, by providing suitable high level API to developers. These need will be first covered by providing native API implementation, but also by using some of the future accelerations (like 3D hardware acceleration). (b) by providing leading mobile operators the ability to ensure that they are able to offer and market under their own brand cross-platform game services. 2.4 Why isn't this need met by existing specifications?Games have significant performance and memory requirements. These requirements are met by desktops or high-end PDAs. Mobile phones have cost & capacity constraints. MIDP 1.0 profile does not cover specifically games, but provide general purpose graphic API. Though sufficient for many applications, they prove insufficient for games that require both specific and fast functions. Indeed, proof of this is found in the fact that most available J2ME compatible handsets contain some form of proprietary Game API JSR 118 (MIDP-2.0) starts to address the problem of Games on mobile phones. But the complete MIDP-2.0 profile implementation will only be available in high-end devices due to memory constraints. An option could have been to develop the game API further within this group. However it is a general purpose profile, making more complex the evolution of a dedicated Game API inside the group with the additional risk that further re-work would have led to missed market opportunities, once again opening the door for proprietary extensions or systems. JSR 134 addresses the problem of games on high end devices. There are currently more constraints in low-end devices and a huge demand in such market. Trying to address both mobile phone market and CDC market would result in a lowest common denominator. The group will work closely with JSR134, however, to make sure that if possible, same API or subset of Game API are used in both groups, or at least same concepts in order to facilitate migration from one platform to the other (2 members of the Expert Group are from JSR 134). We expect that some of the API defined here will be used by non game applications. The justification for their inclusion in the current JSR lies on the fact that games will be the main users of these features. The last issue concerns 3D. Our view is that the large majority of 3D applications on mobile phones for the coming 2 to 4 years will be related to games & game related markets such as character depiction. Games being one of the most complex applications for 3D, any API defined for games would probably meet most market requirements exactly as DirectX, developed for PC games, has enabled the development of 3D applications even beyond gaming. If there is a generic 3D JSR, then game related 3D specifications would take place within the generic 3D JSR. 2.5 Please give a short description of the underlying technology or technologies:Technology will use knowledge of both gaming and embedded environments. The first implementation will be native. 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.microedition.lcdui.game 2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?None 2.8 Are there any security issues that cannot be addressed by the current security model?None Known 2.9 Are there any internationalization or localization issues?Not specifically. 2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?None. As stated before, objective is to work closely with others working group to prevent divergence, and especially JSR134,135 and 118. 2.11 Please describe the anticipated schedule for the development of this specification.We intend to have a public available draft for Q4 2002, reference implementations and TCK for Q1/Q2 2003. 2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.A kick-off meeting will be planned four weeks after the JSR acceptance with the group members. Work will be based on regular meeting and mailing discussions. As we expect strong community interest around this JSR, we will open the group for further participants who want to be involved in the creation of these APIs. They will have a status of spec reviewer, and be able to participate to the face to face meeting where a number of reserved seats will be made available on a first come/first served basis. Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available. InFusio bring experience in downloadable game engine for mobile phone,
Exen ( http://www.in-fusio.com )
3.2 Explanation of how these items might be used as a starting point for the work.The gaming API part of the JSR118 will be used as a starting point. If similar concept are founds with JSR134 and 135, then the objective of the group is to be inline with those concepts, and ideally use the defined API. |
|||||||||||||||||||||||||||||||||||||
