 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 134: JavaTM Game Profile
Reason: The Spec Lead has chosen to withdraw this JSR. It was determined that the needs of games developers were best served by moving to a pure open source model for game client technologies. This changes in strategy will allow the broadest participation by the game development community, and will focus the energies of the community on timely solutions that address a rapidly changing technology landscape. The Spec Lead wishes to thank the Java Community and the Game Developers who supported and showed interest in this effort. JCP version in use: 2.1 Java Specification Participation Agreement version in use: 1.0 Description: Defines a Java 2 Micro Edition Profile for the purposes of game development targeting high-end consumer game devices and desktops. Please direct comments on this JSR to the Spec Lead(s) Team
This JSR has been Withdrawn
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Sun Microsystems, Inc. Name of Contact Person: Bartley Calder E-Mail Address: bartley.calder@sun.com Telephone Number: 408 276 6733 Fax Number: 408 276 3243 Specification Lead: Bartley Calder E-Mail Address: bartley.calder@sun.com Telephone Number: 408 276 6733 Fax Number: 408 276 3243 Initial Expert Group Membership:
Section 2: Request
2.1 Please describe the proposed Specification:
1. 3D Modeling and Rendering for Games
These nine areas above provide the core facilities of a game platform. To build that platform, the expert group intends to leverage existing APIs whenever possible. In the event that no existing APIs cover the required functionality (e.g. Physics Modeling for Games), the expert group will define new APIs or spin off new JSRs to define new APIs that the Games Profile will include by reference. In some cases modifications to existing APIs might be desirable to meet the unique requirements of a game platform. In this case one of two approaches will be taken: 1. A proposal describing requirements and suggested changes to an API will be made to the expert group responsible for the pertinent API. If the changes can be agreed to and can be adopted in a maintenance release in a timely fashion, the Games Profile expert group will work closely with the other expert group to produce the change. The Games Profile would then incorporate the maintenance revision of the existing API by reference. 2. If suitable modification to the existing API isn't feasible then the Game Profile expert group will create suitable new APIs within its own name space. Game developers are extremely concerned about performance and as such look for ways to determine the capabilities of a particular platform This expert group will also investigate metrics that are relevant to games and look for ways to use those metrics in characterizing implementations. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)A goal of the Games Profile is scalability across a range of devices. This profile is targeted at high-end consumer game devices (based on the CDC and Foundation Profile) and desktops (J2SE). However the expert group intends to focus on J2ME platforms with a likely reference implementation on the CDC. 2.3 What need of the Java community will be addressed by the proposed specification?There is growing interest in targeting the Java platform for game development. Java technology has much to offer game developers, from improvements in reliability and time-to-market of game development efforts, to device independence and platform scalability. To date, however, there has not been a focus on optimizing Java technology for development and play of sophisticated games. Most game development shops are small companies that cannot afford to focus efforts on more than one or two of today's proprietary platforms. The resulting games are tied to specific devices, and are relatively fragile. Overall, game development and maintenance costs are skyrocketing. By defining a Java Games Profile we will create a standard through which game developers can better leverage their development investment, prevent lock-in, and broaden their target market. 2.4 Why isn't this need met by existing specifications?In order to program cutting-edge games for the Java platform the developer needs access to APIs representing functionality that is not supported by existing profiles and editions. The needs of game developers are radically different from those of the markets Java technologies have addressed to date. The Java 2 Platform, Standard Edition, defines API and functionality that are not necessary in a game programming environment (e.g. CORBA support, etc.). Conversely, many functions that are considered ancillary extensions to a desktop use are required for game development (i.e. audio codecs, streaming video, hardware assisted 3D graphics, etc.). Existing J2ME profiles forgo many unnecessary APIs, but further reduce functionality (e.g. 2D support) to reduce footprint. 2.5 Please give a short description of the underlying technology or technologies:This Profile will be based on the Connected Device Configuration (CDC) and probably the Foundation Profile. In addition it will likely reference Java 3D and Java Media Framework APIs. Additional APIs will probably be added to provide missing functionality such as physics modeling, animation , and game marshalling. 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)Where new game-specific APIs must be defined, the proposed package name is javax.games.*. Should additional APIs be required that are anticipated to be reusable in other contexts (other profiles) they will be defined in non-game-specific packages in javax.*. 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. 2.9 Are there any internationalization or localization issues?None. 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 above, if minor extensions to an existing specification would permit the games profile to use the existing specification in its entirety, the games profile expert group will explore the possibility of extending the existing specification with the expert group of that specification. 2.11 Please describe the anticipated schedule for the development of this specification.We intend to have a publicly reviewable draft in Summer 2001. Within a year of that a reference implementation and TCK should be available with a final specification. 2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.Details of the functionality identified for this JSR have purposefully been left indistinct to allow the expert group to design the best solutions for the needs of their industry. That work has already begun with the discussions held at the first Java Gaming Platform summit meeting, on Dec 6 & 7, 2000 at the Sun Santa Clara campus and will continue by means of a closed email list and further virtual or face to face meetings as required. It is anticipated that portions of the APIs might be identified as useful more generally than in the context of the Games Profile. We anticipate that such APIs could be spun off into independent JSRs, with their own expert groups potentially drawing members from outside the community of game developers. Such JSRs would then be incorporated into the Games Profile by reference. 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.The Java Media Framework 2.1 API Docs (http://java.sun.com/products/java-media/jmf/2.1/specdownload.html) The Java 3D 1.2 API (http://java.sun.com/products/java-media/3D/index.html) The Java New IO API (http://java.sun.com/aboutJava/communityprocess/jsr/jsr_051_ioapis.html) The Karma Simulation Toolkit from MathEngine (http://www.mathengine.com/_mathengine_corp/_products/overview.html) The GameSpy APIs for Java (http://www.gamespy.com/software; this is a general discussion of GameSpy's offerings. Their APIs require registration to view.) 3.2 Explanation of how these items might be used as a starting point for the work.We see the Java Games Profile as potentially using existing technologies in the following areas: 1. General Programming Functionality We see the general programming environment as a JVM with support for access to memory outside of the Java heap. The new IO package addresses two key areas: efficient I/O for loading game data into memory quickly and access to the memory space outside the Java heap from within Java. This is a critical facility for some kinds of game coding.2. 2D Graphics Support is desirable for video buffer management and page flipping, hardware accelerated BLT, line draw, and rectangular fill where provided by host hardware. Java2D's new VolatileImage and updated Graphics2D classes, combined with AWT's new fullscreen mode and BufferStrategy classes already provide a well-defined interface to such functionality.3. 3D Graphics Full support for advanced hardware-assisted 3D rendering with a high degree of flexibility and control over the render process is desirable, as is access to render primitives to build fancy effects (i.e. reflection mapping, stencil buffer based shadow volumes). Java3D has much of this already.4. Controller Input Discovery of and access to game controllers such as joysticks and steering wheels is necessary. Java3D provides basic controller access. While it may be desirable to put a simpler, non-3D oriented interface on game controllers, we suspect that this can be done through a small amount of glue- ode that wraps the existing Java3D input functionality.5. Advanced Audio MP3 and Midi playback, streaming audio, and voice codec for low-bandwidth transmission across the net are required. Much of this is provided by JMF2.0. Java3D supports 3D spatial sound positioning. There are still some open questions about how this interfaces to JMF 2.0 but we expect to work those issues, if any, out in the expert group.6. Streaming Video High quality video playback is required for 'cut scenes'. This is provided in JMF 2.0.7. Game Marshalling We expect to be able to use components of the GameSpy Java APIs as the core functionality of a reference implementation of a general game marshalling API. All that would need writing is the glue code to convert the visible proprietary GameSpy API to the agreed-upon standard API.8. Physics Engine Math Engine already has a highly respected physics modeler in C/C++ and has expressed interest in working on the reference implementation of a Java physics modeling API.Other possible contributions include resources from the following companies: *Plazmic has developed a media engine for the DoCoMo iMODE phones and are experts in writing Java code for resource-constrained clients.In all of the above preexisting APIs it is possible there may be considerable additional functionality not needed for the Games Profile. In order to handle the memory constraints of consumer devices, some of these features may be excluded from the Games Profile APIs. |
||||||||||||||||||||||||||||||||||||||||||||||
