08-16-2017, 10:35 PM
[attachment=2434]
IMPLEMENTING MULTI-DEVICE COMPATIBLE
J2ME BASED MOBILE GAME
By
DEEPAK.K.A &
ARUN.C
1. Introduction
Modem mobile phones are small computers, with limited processing power by desktop standards, but power enough to run a small game. If you have a recent phone, you have more processing power in your pocket than ran the Lunar Lander.
Today's phones are also by their very nature networked computers, efficiently sending and receiving digital data. Primarily geared for voice data, they can send and receive other kinds of data as well. This inherent ability to share information offers a unique opportunity to design games wherein players interact with other players, perhaps even on the other side of the world. In terms of processing power and capabilities, the current generation of Java -enabled phones is close to the second generation of arcade machines, early 1990s home computers, and early handheld game machines. RAM is generally limited typically 128 KB to 500 KB although some smartphones, like Nokia 3650, have as much as 4 MB of memory. They also have, by comparison to PCs, limited input and display capabilities: small screens (many still black and white), keypads optimized for phone dialing rather than text entry, and limited sound handling.
1.1 Gaming on Mobile Phones
Today, PC and console games are big business an important branch of the entertainment industry and almost impossible to develop without a substantial investment of time, money, and other resources. That is what
makes the new sector of mobile and wireless games so exciting. There is considerable room for innovative designers and programmers to make their mark and build valuable businesses with surprisingly limited resources. The mobile device is not simply a small, portable game machine of the old type, but something new and different, with different opportunities, exciting potential, and, at least at the present, significant development limitations.
1,2 Platform Opportunities
Mobile Gaming is in its infancy. It offers exciting opportunities for both business and creative persons alike. The potential audiences of mobile games are enormous - the best selling game console (Play station and Game boy) have sold only one million consoles compared to the more than one billion mobile phones that are sold world wide. Moreover mobile games are much cheaper to develop than conventional PC based games; a PC game development will cost around 2.5 million dollars or more compared to a thousand dollar or less in the mobile market.
Huge Potential Audience
More than a billion mobile phones are in use today, and the number is growing. In every developed country except the United States, a higher proportion of the population owns a mobile phone than owns a computer. While only a small portion of those phones are Java-enabled, and an even smaller number run an OS, the numbers are increasing rapidly, and within a few years, Java phones will be the norm. Your potential audience is larger than the potential market for any other platform Play station and Game Boy included.
Portability
There's a reason that Game Boy has sold more units than any other game console ever manufactured: portability is prized. People like being able to play whenever and wherever they choose. A phone may not be a great
game
device
by comparison to modern consoles or computers, but people have their phones with them almost all the time.
Networked
Because mobile phones are networked devices, multiplayer games are feasible even given their other limitations.
1.3 Game Business
Mobile gaming markets are really becoming large. Most analysts say that in 2001 the mobile game industry generated around $400 million. Virtually all analysts say that Asia (primarily Japan & S.Korea) contributed for the 80-90% of the market and revenues from Europe responsible for the remainder. Projections for revenue growth range from the enormous high $17.5 billions to pessimistically low $1.5 billion. It is to be noted that markets outside Asia (Japan & S.Korea) are relatively small and investment in mobile games should be considered as an investment in future growth and a tremendous opportunity to establish early market leadership.
The business models in use today vary with enabling technology and the most commonly seen are listed as follows, SMS games, Browser games, Interpreted Language games and Native OS games. The typical value chain currently in practice is Consumer -> Operator -> Aggregator -> Developer. The consumer pays an air - time or data transfer charge. For Interpreted -Language games (based on Java/ BREW) it is a one-time application fee.
The operator passes on a portion of this fee to an aggregator, may be a mobile game publisher or wireless game portal, a handset manufacturer or some other intermediary. The portion of revenue passed to the aggregator varies from 5% to 89%. The aggregator typically passes about 15-50% to the developer.
1.4 Game Categories
Currently, common mobile games categories include Arcade, Puzzle, Action, Sport, and Traditional. Arcade games are either based on classic arcade titles such as Asteroids, Pac Man, and Space Invaders, or are original titles with the same kind of game play. Since early arcade machines were quite limited in their media display capabilities and processing power, the style is an obvious one to translate to mobile devices. Puzzle games are solo play games that engage puzzle-solving skills, sometimes with continuous motion as in Tetris, sometimes more turn-based, in the manner of Bejeweled or Snood (popular PC puzzle games). These games tend to appeal more to casual gamers, rather than hardcore, which means that the potential market is enormous, but doesn't generally support high prices and often distributed free. The term "Action game" is somewhat nebulous. Generally, it refers to a game in which a player controls a single character that moves through space, often engaging in combat with opponents. Player skill, rather than resource management or another type of challenge, is the focus of the game. Examples include Tomb Raider, Spyro the Dragon, and Sonic the Hedgehog. Sports games are based on real-world (or sometimes imaginary) sports, and they constitute a large portion of the console and PC market, with titles like John Madden Football and FIFA Soccer. Given the small screen real-estate and limited control of mobile devices, it is hard to recreate team sports, but many early console sports titles faced similar issues, which were resolved by,
for instance, offering hockey games with four team members per side. This approach will work for mobile games as well. Sports like golf and bowling are also easy to translate to mobile devices. Successful sports games are often based on licenses from sports personalities or sport associations. Traditional games include board or card games such as Othello (also known as Reversi), Noughts and Crosses (Tic-tac-toe), Patience (Klondike Solitaire).
1.5 Mobile Phone - The Asian Scenario
Though mobile gaming is in its infancy in Asia baring Japan, many
devices have started to crop up including the Nokia NGage which features 3d
chipset and multi megabyte storage capabilities. Samsung is also on the
verge of launching one that has 26 Mb of RAM, 100 Mb of storage space and
so on.
Motorola has also launched similar phones. As always game
developers tend to push the hardware to its limits and this has resulted in
launch of this high tech gizmos. However the market for such phones in India
or Asian Region is not that bright as the prices of these models start from
Rs. 18000 to Rs.50000. The bulk of the users (more than 90%) in these
regions possess entry level mobile phones that start at the Rs.3000/-(Rupees
Three thousand) that features a 128*128 pixel displays, 200 Kb of RAM, an
application size limit of 64 Kb.
2. Mobile Game Development
2.1 Platform Challenges
Mobile game developers face considerable challenges a very small display area, limited storage capacity for applications and data, and limited text entry capabilities. Another related issue is standardization is far from complete. A mobile phone presents a different design environment compared to a PC or even to a PDA. Development teams usually have to produce different versions of the same game taking account of difference like memory capacity and display configuration
Text input is slow and difficult on phones, so designers may need to
offer simple phrase selections (if not handled well, this can make a game
seem dull), allow for contractions, or avoid text input. And because phones
are often used in noisy environments, subtle tones and noises may be
completely missed.
Although battery life is improving greatly, it is yet another factor that must be considered. Impressive figures of 400 or 500 hours standby time can change dramatically if a game makes heavy use of graphics changes, flashing lights, buzzers, and other noises. Additionally, many mobile devices use ARC technology processors, which scale down power use when the processor is not in maximum use, but games typically push processor to their limits, meaning they run down the battery quite quickly.
Portability is an issue of "write once, run anywhere" across different mobile devices. This involve questions like whether the game logic runs
correctly on various devices or the game uses standard APIs or vendor specific APIs and such.
Limited Screen Size
Mobile phones are of small factor. Even though resolution is increasing and colour screens are becoming the norm, the screen sizes are likely to remain small as users don't like to use clunky phones.
Limited Color and Sound Support
Most phones in consumers' hands are still black and white, although most Java-enabled phones on the market today support color. Twelve-bit color is fairly common among such phones. Phones allow the use of some sounds, and MIDI support is increasingly standard. Generally, only one voice and one channel are possible.
Limited Application Size
Most Java-enabled phones have a limited amount of memory available for MIDIets (Sun's word for J2ME applications). Additionally, there's always a limitation on the size permitted for a MIDIet. The actual limit depends on the handset and (sometimes) the carrier's policies.
Interruptibility
When a user receives a voice call, that call will interrupt a game in progress. The application must be able to pause and recover without crashing, causing play problems (e.g., the monsters keep moving and killing the player even while s/he's chatting on the phone, returning to a lost game),
or
causing
memory
leaks.
Evolving Technologies
The technologies used to develop mobile games were not designed with games in mind, and there are often specific and awkward limitations as a result. As one example, the J2ME specification does not require support for transparency, which makes sprites look ugly over anything other than a blank background.
2.2 Mobile Game Development versus Conventional Game Development
Mobile Game development differs from Conventional Game Development in number of ways. Conventional PC and console games are developed by teams that require 12 to 30 people. However mobile games are typically developed by teams of 3 to 4 persons.
Conventional games have budgets in the range of $1.5 million to $3 Million and takes two to three years to develop. Mobile games are developed in the period of 2 to 3 months and have a budget which is under $10000 (professionally managed company) to virtually zero in the case of lone programmer.
Console requirement require authorization and support from console manufactures, which makes one to pay high royalties to them. In mobile game development one is free to develop whatever sorts of game without paying anybody as the technology is Open as in PCs.
2.3 Game Development Process
Typically a game development process starts with the inception of
Game Design Specification which is created by the lead designer. It specifies
the fundamental User Interfaces, fundamental game play algorithms and what
media assets are needed for creating the game. Unlike conventional software
specs, game specifications are revised frequently during the implementation
stages. Then tech specification is created by the lead programmer. It
mentions the technologies to be used in developed during the game, object
and method nomenclature, software architecture and high level model. Then
the budget and schedule created specifies the financial, technical and human
resources. Then a test plan is implemented where the game is tested in
variety of devices.
2.4 Game Implementation Techniques
A number of different technologies, listed below, are used for games on mobile phones.
Embedded Games
Some games are programmed to run natively on a phone's chipset, installed on the phone at the factory, and shipped with it. Snake, available on many Nokia phones for more than four years, is the most famous example. New embedded games cannot be installed by the consumer, and they are
becoming
less
prevalent.
SMS Games
Short Message Service (SMS) is used to deliver short text messages from one phone to another. Users typically pay about 10 cents per message. SMS games are played by sending a message to a phone number that corresponds to the game provider's server, which receives the messages, performs some processing, and returns a message to the player with the results. SMS is not a particularly good technology for games, because it is dependent on text entry by the user, and thus is, in essence, a command-line environment. It is also expensive for a game of any depth, since a mere 10 exchanges with the server will cost a user $1 or more. Although the deployment of Multimedia Message Service (MMS) technology makes message-based games more appealing, this is still not a great game play environment.
Browsing Games
Every mobile phone shipped since 1999 includes a Wireless Application Protocol (some entry level model doesn't have this feature). WAP in essence is a simplified form of the web much optimized for small displays and low bandwidth of mobile phones. WAP games are played by going to the game provider's URL (usually through a page link on the carrier's portal), downloading and viewing one or more pages, making a menu selection or entering text, submitting that data to the server and then viewing more pages.
8th-Semester Branch: CSE Project Title: Implementing a Multi- Device Compatible J2ME
based Mobile Game
J2ME and Other Interpreted Languages
Java 2 Micro Edition (J2ME) is a form of the Java language that is optimized for small devices such as mobile phones and PDAs. Nokia (and most other phone manufacturers) have made a strong commitment to Java phone deployment. Tens of millions of Java-enabled phones are already in consumer's hands.
J2ME is limited by comparison to desktop Java, but it vastly improves the ability of mobile phones to support games. It allows far better control over the interface than either SMS or WAP, allows sprite animation, and can connect over the air network to a remote server. Because of its capabilities and the widespread and growing deployment of Java-enabled phones, it J2ME is not the only interpreted language deployed on phones, but it is an industry standard backed by many manufacturers and therefore offers a large and growing installed base. Some proprietary interpreted languages have significant regional presence, including Qualcomm's Binary Runtime Environment for Wireless (BREW) in North American and a standard called GVM supported by some Korean carriers. Games initially developed for the large J2ME installed base can be recoded in these proprietary languages if a sound business case presents itself.
C++ Applications
Mobile games can also be developed in C++, a language that compiles to native machine code. Compiled languages in general offer better control over the Ul, direct access to the phone's hardware, and greater speed for the same processing power when compared to an interpreted language. Development in C++ enables rich, high-performance games. However a
phone supporting this technique is at a premium compared to Java/WAP enabled phones
2.5 Software Development Kits / Platforms
The list of platforms that target the game developer is increasing daily. However they can be grouped into nearly two classes, one base on Java and the other non-Java based. The Development platform is chosen on the basis of the device support, and more importantly which devices are popular among users and sometimes the target specific region.
2.5.1 Java Based Development Platforms
J2ME
The "Java 2 Micro Edition" is usually considered what Java was originally supposed to be: a cross-platform language capable of working in devices with highly reduced capabilities. With that in consideration, it doesn't come as a surprise the similarities between J2SE and J2ME. As a matter of fact, J2ME is often considered a Standard Edition stripped to the essential.
Since it wasn't initially planned for games, its potential is quite reduced
when compared with the other platforms created specifically for that purpose.
Although MIDP 2.0 already comes with a GameAPI, the current version
(MIDP 1.0) only has a few rudiments of what would be required to produce
technically advanced games. For example, there's no support for resizing
images, perform simple 2D rotations or even include sound. However, due to
the fact that it appeared first and managed to acquire a good amount of
supporters. J2ME became almost a market standard and it's the platform that
carries more games in more devices.
J2ME's development costs are extremely reduced. The SDK is freely
available and there are no licensing expenses, which means that anyone can
create a game and market it.
Regarding J2ME's future, generally speaking you could say it's
excellent. Not only does it have an extensive list of manufacturers supporting
it (making
SREE NARAYANA GURUKULAM COLLEGE
kadayirippu
it almost a standard), but it also managed to overcome the problems of JVMs that did not follow the specifications (which occurred due to the manufacturers' "rush" in releasing devices supporting this technology).
Samsung
351 Oi T720 S
3300
5100
! 6650
6100
7210
7650
Table 2: Vendors and their models supporting J2ME Platform
ExEn
Execution Engine" (also known as ExEn) was developed by In-Fusio to "fight" the limitations imposed by J2ME in game development. It's also interesting to notice that In-Fusio tried to overcome those limitations working together with Sun by presenting the proposal of a GameAPI for MIDP 2.0.
ExEn was the first mass market downloadable game engine to be made available in Europe. This was an important first step that allowed ExEn to achieve the current position of leader in this continent, making it the most used game engine (which also means that it's the one with a wider range of games).
In early November 2002, there were 18 models which supported ExEn. In
a European view, this means around one million available cell phones.
Although it's a somewhat reduced number when compared with the five
million devices which have J2ME technology, it's an impressive amount for a
"small" proprietary technology.
Both in graphical and processing speed terms, ExEn is far from the lead.
However, by supplying additional important game development functions
(sprite zooming, parallax scrolling, ray casting, rotations), it easily overcomes
J2ME. Adding to this a virtual machine that, despite not being the fastest, can
be around 30 times faster than a generic VM and only leaves a 5% footprint
on the device's memory, it's easy to see why this is the most widely chosen
game engine.
Another important reason that leads several developers to choose ExEn is In-Fusio's business model. This is divided in 2 levels: standard and premium. In the standard level (free subscription), In-Fusio offers the SDK, an emulator, on-line technical support and the possibility of, later on, upgrading to the premium package. The developers that achieve the premium level have their games marketed by In-Fusio, which promotes them in the operators who have devices supporting this engine.
WGE
The "Wireless Graphics Engine" is TTPCom's solution. Although it began
being considered the main candidate for domination of the game engines'
market, the lack of support by game developers ended up decreasing the
initial appeal.
From a technical point of view, It is slower than Mophun, but the
several API modules make 2D and 3D programming easier (including tile
management and
collision detection functionalities), allow a simple access to networking functions and grant sound support, among other capabilities.
The SDK download is free and TTPCom has a business model aimed at attracting the game development teams. To the usual revenue sharing from the games sold on a download basis, there's the addition of a "minimum income" resulting from selling the games directly to the device's manufacturers.
2.5.2 Non Java Based
Mophun
Mophun is described by its creators (Synergenix) as a "software-based videogame console". Although its development began in late 1999, its market implantation only achieved a serious level in November of 2002.
Technically Mophun is much superior. In tests conducted by
Independent organizations that in devices where Mophun reaches 60 Million
Instruction per Second (MIPS), J2ME reaches around 400 Thousand
Instruction per Second (KIPS).
Synergenix also adds that, in certain devices, part of the VM code is directly translated into native code, meaning that it's possible to achieve 90% of the device's maximum capability (for instance, reaching 90 MIPS in a device that reaches 100 MIPS when running native programs). The remaining characteristics are similar to ExEn's.
Like ExEn and J2ME, Mophun is also freely available. In some aspects, Synergenix's business model resembles In-Fusio: after the game is developed, Synergenix handles certification, distribution and marketing. However, since its current network isn't much extended, it doesn't seem to be as appealing as ExEn's, which made some developers choose the theoretically weaker system.
.Net Compact Framework
.Net is the high profile technical platform developed by Microsoft. It is one of the most powerful and easy to develop out of all the platforms. It is also easy for the programmer to get use to it as it comes with a very good IDE (Integrated Development Environment) to build applications with. Also it is one of the easiest platforms to program due to the support of languages like Visual Basic, C#, Visual C++. However other than Motorola, not many device manufactures have devised devices with .Net Platform.
BREW
Qualcomm introduced Binary Run-time Environment for Wireless (BREW) technology in early 2001. A C/C++ programming API for a specific kind of hardware platform, BREW is also a certification and distribution model for getting mobile phone applications out to your audience.
Qualcomm invented the CDMA standard, widely used in the United
States for digital mobile phone communications. Qualcomm once
manufactured CDMA handsets for various carriers, and the internal
programming API used to develop software for these phones lives on in the
form of BREW.
BREW is more than just a programming API, it also includes a distribution system whereby Qualcomm offers your application to all participating BREW carriers and manages billing services to collect subscription and purchase fees. Once your application goes through the compatibility-testing process with NSTL (an independent testing lab), it's then priced by the developer and made available to BREW carriers, who, having agreed on the pricing and accepted the application, then make it available for
users
to
download.
Based purely on API features, BREW has more options, and the low-level C/C++ access to the phone's features is a more familiar environment to the seasoned game programmer. Additionally, Qualcomm continues to update BREW with new SDK and tool releases at a faster pace than J2ME spec revisions. As a development environment, J2ME is far easier to get started with and much simpler to implement than BREW, but J2ME has been around far longer than BREW.
3. The Project
The project 'Street Racer' is to develop a compelling graphic rich game for the entry level mobile phones for the Asian Region. As stated before the bulk of the mobiles sold in this region belong to the entry-level category. The main development platform in this region is J2ME and BREW.
As more and more carriers and vendors support J2ME in this region,
the project is constrained to be developed in J2ME platform though much
better platforms exist. This can also be attributed to various other reasons like
the J2ME handsets are outnumbering BREW handsets, the popularity of Java
among developers, SUN's technical tie-up with mobile phone manufactures
and so on.
Developing a game in J2ME is quite a challenge as SUN developed
the J2ME platform with applications in mind rather than gaming. As the
specification was devised with variety of devices in mind, it is written for the
lowest common denominator.
The Stumbling Block in J2ME game development
No support for transparent images
No support for pixel level manipulations
No support for shading, explosion and dynamic shadows
No support for polygon or rectangular filling
No texture mapping or particle effects
The MIDP 2.0 launched by SUN has all new gaming API, that address most of the above mentioned stumble block. Yet at this time of writing, many device manufacturers have not yet launched an entry level phone with this profile. They launched their own device specific API, implementation using these API's a developer can push the games to the extreme. However this lead to hampering the portability and long development cycle, as the game has to be specifically mapped to different devices.
This project's goal is to develop a graphic rich game , that is portable and yet do not have long development cycle. The development team plans to implement by separating the game logic and then mapping the game's graphics the device's corresponding API functions at run-time. We also will try to cover various other techniques to make the game portable. Implementation of animation library is also part of the objective, as the J2ME specification does not provide an inbuilt support for it. The following are the main objectives of the project:
Implementing sprite graphic classes.
Implementing wrapper class that maps to device specific API's.
Implementing game logic and media assets.
Testing the game for various devices.
4.lntroduction to J2ME Platform
Sun Microsystems has defined three Java platforms, each of which addresses the needs of different computing environments:
Java 2 Standard Edition (J2SE)
Java 2 Enterprise Edition (J2EE)
Java 2 Micro Edition (J2ME)
The inception of the J2ME platform arose from the need to define a computing platform that could accommodate consumer electronics and embedded devices. These devices are sometimes referred to collectively as pervasive devices.
The creators of the J2ME platform delineated pervasive devices into two distinct categories:
Personal, mobile information devices that are capable of intermittent networked communications mobile phones, two-way pagers, personal digital assistants (PDAs), and organizers
Shared-connection information devices connected by fixed, uninterrupted network connection set-top boxes, Internet TVs, Internet-enabled screen phones, high-end communicators, and car entertainment/navigation systems
The first category describes devices that have a special purpose or are limited in function they are not general-purpose computing machines. The second category describes devices that generally have greater capability for user interface (Ul) facilities. Of course, devices with superior Ul (User Interface) facilities typically have more computing power. Practically speaking, computing power is the primary attribute that distinguishes these two categories of devices.
Like computing power, connectivity the availability of media such as wireless networks also affects the kinds of functionality and services that pervasive devices can support. The challenge and the primary goal for J2ME is to specify a platform that can support a reasonable set of services for a broad spectrum of devices that have a wide range of different capabilities. The creators of J2ME identify modular design as the key mechanism that enables support for multiple types of devices. The J2ME designers use configurations and profiles to make J2ME modular.
4.1 Defining a Java Platform for Pervasive Devices
Configurations and profiles are the main elements that comprise J2ME's modular design. These two elements enable support for the plethora of devices that J2ME supports.
A J2ME configuration defines a minimum Java platform for a family of devices Members of a given family all have similar requirements for memory and processing power. A configuration is really a specification that identifies the system level facilities available, such as a set of Java language features, the characteristics and features of the virtual machine present, and the minimum Java libraries that are supported. Software developers can expect a certain level of system support to be available for a family of devices that uses a particular configuration.
8lh-Semester Branch: CSE Project Title: Implementing a Multi- Device Compatible J2ME
1 based Mobile Game
A configuration also specifies a minimum set of features for a category of devices. Device manufacturers implement profiles to provide a real platform for a family of devices that have the capabilities that a given configuration specifies.
The other J2ME building block, the profile specifies the application-level interface for a particular class of devices. A profile implementation consists of a set of Java class libraries that provide this application-level interface. Thus, a profile theoretically could specify all kinds of functionality and services.
For example, a profile might support a network communication facility for the popular Short Message Service (SMS) standard widely used by mobile phones. Because the SMS standard is a ubiquitous feature of mobile telephony, it makes sense to define this service in a profile that targets mobile phones, rather than to build it into a configuration.
A profile is implemented on top of a configuration, one step closer to the implementation of real-world applications. Typically, a profile includes libraries that are more specific to the characteristics of the category of devices they represent than are the libraries that comprise configurations. Applications are then built on top of the configuration and profile; they can use only the class libraries provided by these two lower-level specifications. Profiles can be built on top of one another. AJ2ME platform implementation, however, can contain only one configuration. Figure shown shows the conceptual layers that comprise the J2ME platform.
4.2 Configurations and Profiles
A configuration specifies three basic elements: a set of Java programming language features
a set of Java virtual machine features
a set of supported Java libraries and application programming interfaces (APIs)
Java application
Profile
Configuration:
Libraries
JVM
Host operating system
Device hardware
Table 3: The J2ME
platform
The creators of J2ME have defined only two configurations to avoid a fragmented landscape of incompatible platforms. These two are:
personal, intermittently connected mobile devices supported by the Connected, Limited Device Configuration (CLDC)
constantly connected network devices supported by the Connected Device Configuration (CDC)
Configuration specifications require that all Java classes adapted from J2SE be the same as or a proper subset of the original J2SE class. That is, a class cannot add methods not found in the J2SE version. Configurations can
include additional classes in their specifications, however; configurations themselves are not necessarily proper subsets of J2SE. Both configurations that have been defined to date add classes not present in J2SE in order to address device attributes and constraints.
The Connected Device Configuration (CDC)
The Connected Device Configuration (CDC) intends to capture just the essential capabilities of each kind of device in the category of devices it targets, namely, devices with 2 MB or more of total memory, including both RAM and ROM.
A configuration specifies both the set of Java VM features that are supported and a set of class libraries. The CDC specifies the use of the full Java 2 platform VM, which, in this context, is called the Compact Virtual Machine (CVM).
Connected, Limited Device Configuration (CLDC)
The second of the two J2ME configurations, the Connected, Limited Device Configuration (CLDC), supports personal, mobile devices, which constitute a significantly less powerful class of devices than the one that the CDC supports. The CLDC specification identifies devices in this category as having the following characteristics:
160 to 512 KB total memory available for the Java platform
16-bit or 32-bit processor
low power consumption, often battery powered
intermittent network connectivity (often wireless) with potentially limited
bandwidth
The goal of the CLDC is to define a standard Java platform for these devices. Because of the wide variety of system software on various personal devices, the CLDC makes minimum assumptions about the environment in which it exists. For example, one OS might support multiple concurrent processes; another might or might not support a file system, and so forth.
The CLDC is different from, yet also a subset of the CDC. The two configurations are independent of each other, however, so they should not be used together to define a platform.
4.3 Java Language Support.
The CLDC specification omits support for the following features of the
Java language:
floating point calculations object finalization
the Java.lang.Error class hierarchy in its entirety
The lack of floating point support is the main language-level difference between a Java virtual machine that supports CLDC and a standard J2SE VM that is visible to programmers. This means that programs intended to run on the CLDC cannot use floating point literals, types, or values. The float built-in type, and the Java. Lang. Float class has been removed from CLDC libraries. This feature is not present because of the lack of floating-point hardware or software on most mobile devices.
The Java.lang.Error exception hierarchy has also been removed from the CLDC libraries and is therefore not available to applications. The primary reason that error handling is absent is memory constraints on mobile devices. This typically doesn't create any disadvantages for applications development; after all applications are not supposed to recover from error conditions. And the resource cost of implementing error handling is expensive, beyond the capabilities of today's mobile devices. Moreover, error recovery is device-specific on embedded devices like mobile phones. This mechanism may well be outside the scope of an embedded VM.
Java Virtual Machine and Library Support.
The CLDC specifies requirements for a Java virtual machine. It defines a VM that is highly portable and designed for resource-constrained small devices. Support for several features that exist in a standard J2SE VM have been omitted from the CLDC specification.
The VM that comes with the CLDC reference implementation is called the Kilobyte Virtual Machine (KVM), so named because it uses only a few KB of runtime memory. It is a reference implementation that adheres to the CLDC specification's description of a compliant VM. The KVM is not a full-featured
J2SE VM.
CLDC Package Name
]ava,xo
Java,lang java.util
j avax. microedi tion. i .:
- t,:u KII id Java lO classes and packages; subset of the I2SK pa.kage
VM da*..-: and interfaces; subset of the J2SE package Standard utility classes and interfaces; subset of the I2S1
' A.l x_ generic connection framework classes and
interface;.-
Figure 1: CLDC Packages
4.4 Mobile Information Device Profile.
Because the category served by the CLDC encompasses so many different types of personal devices, potentially many different profiles are' necessary to support them all. The most popular and well known of these is the Mobile Information Device Profile (MIDP), sometimes called the MID Profile. The MIDP layers atop the CLDC and defines a set of user interface (Ul) APIs designed for contemporary wireless devices.
Following in the tradition of Java parlance, MIDP applications are called MIDIets A MIDIet is a Java application that uses the MIDP profile and the CLDC configuration .
The MIDP specification, like the CDC's Foundation Profile, was produced by an expert group, in this case, the Mobile Information Device Profile Expert Group, which is an international forum that includes representatives from several companies in the mobile device arena. The MIDP targets mobile information devices (MIDs), such as mobile phones, two-way pagers, and so forth, which have roughly the following characteristics: screen size of approximately (at least) 96x54 pixels display depth of 1 bit
one- or two-handed keyboard, touch screen input device
128 KB nonvolatile memory for MIDP components
8 KB nonvolatile memory for application-persistent data
32 KB volatile runtime memory for Java heap
two-way wireless connectivity
Because the range of MID capabilities is so broad, the MIDP established a goal to address the least common denominator of device capabilities. The MIDP, therefore, specifies the following APIs:
application (MIDP application semantics and control)
user interface
persistent storage
networking
timers
MIDP Package Name
Description
Ul classes and interfaces
Record management system <RMS1 supporting persistent device storage
MIDP application definition support class types
MIDP generic connection framework classes and interfaces
Standard Java iOclasses and interfaces VM classes and interfaces
j.vr-a util
Standard utility classes and interfaces
Figure 2: MIDP packages
A MIDP implementation must consist of the packages and classes specified in the MIDP specification. Additionally, it can have implementation-dependent classes for accessing native system software and hardware. There is nothing inherent in either the CDC or CLDC that prohibits a manufacturer from porting either platform to a given family of devices. Nevertheless, the platform stacks specifically, the configuration and profile features have been specified to address practical limitations of the different families of hardware devices.
4.5 Device Application Management Systems
Starting, stopping, and managing the execution of J2ME applications is controlled by application management software (AMS) that resides on the device. In fact, the AMS controls the entire application lifecycle, from installation, upgrade and version management, to removal of application software. The device manufacturer typically provides the AMS software. This is the most logical scenario because AMS software must work in conjunction with the device's native system software, which, presumably, the manufacturer knows best. Nevertheless, third parties can also develop AMS systems for specific devices. AMS software could be written, for example, in Java or in some native language such as C.
4.6 J2ME Development Cycle
Broadly, the development cycle for a MIDP application proceeds as follows:
Write the Java code.
Compile.
Obfuscate(optional).
Obfuscation removes extraneous class information, such as local variable names. Classes, methods, interfaces, and such are renamed so as to make them ambiguous. An obfuscated package protects the class files from decompilation and reverse engineering. In addition to protecting the source code, the obfuscation process reduces the size of the class files resulting in smaller JAR files The reduced size is advantageous because of the limited memory available on MIDP devices.
Pre-verify
The class verifier in J2SE takes a minimum of 50 kilobytes, not including heap space requirements and processing time. To reduce the overhead for J2ME, class file verification has been broken into two phases. Pre-verification before deployment augments the class files with additional attributes to speed up runtime verification. The device itself performs a lightweight runtime verification process using the additional
attributes generated during pre-verification.
Create the JAR[Java Application Resource ] file.
Create the JAD [Java Application Descriptor ] file.
Execute in a suitable emulator.
Deploy to the mobile device.
8lh-Semester Branch: CSE Project Title: Implementing a Multi- Device Compatible J2ME
based Mobile Game
5.J2ME IDE Comparisons
An integrated development environment (IDE) aims to improve developer productivity by providing a cohesive set of developer tools through a graphical user interface (GUI).The canonical Java IDE is expected to contain an editing tool, a project management tool, a compilation environment, and a debugger. However, as the Java IDE market has matured, the leading vendors have introduced innovative new features to' differentiate their products from the competition. Initially, Java IDEs were targeted at J2SE. However, as J2EE gained acceptance, vendors implemented support for developing enterprise applications using J2EE into their IDEs. The most recent addition to the Java family is J2ME. With many experts predicting enormous growth in the J2ME applications development market, many vendors have implemented extensions to their existing IDE products to support J2ME. In addition, specialist vendors have implemented standalone J2ME IDEs.
A J2ME IDE is expected to provide the following facilities:
Project management. Managing the source files and MIDIets attributes.
Editor. Editing of source code and resources.
Build. Compilation, obfuscation and pre-verification of source code.
Package. Packaging of MIDIets into JAR and JAD files.
Emulation. Execution of MIDIets within an emulator.
Debugger. Debugging of MIDIets.
5.1 Sun J2ME Wireless Toolkit 2.2
The J2ME Wireless Toolkit (WTK) is a J2ME Java Development Kit (JDK) that provides application developers with the emulation environment, tools, documentation and examples needed to develop MIDP applications. The WTK is not a complete IDE, as it omits editing and debugging features that are considered mandatory for an IDE. However, KToolBar, included with the WTK is a minimal development environment with a GUI for compiling, packaging, and executing MIDP applications.
The previous version of the WTK, 2.1, offered the option of integration with Sun ONE Studio 3.0 (formerly Forte for Java 3.0). However, this option has been dropped from WTK 2.2. Instead, Sun has integrated J2ME support into Sun ONE Studio 4.0 Mobile Edition (which is currently only available via the Sun Early Access Program).
The WTK 2.2 release also includes an enhanced emulator with new simulation, monitoring and debugging features. In addition, a new mechanism has been added to KToolBar's build process to enable the seamless integration and execution of a Java byte code obfuscator when packaging a MIDIet suite.
The emulator uses Sun's MIDP/CLDC reference implementation. Therefore, look-and-feel of the screen Ul is based on the reference implementation and not on a specific manufacturers device.
In addition, a sample implementation of an application manager is provided, which supports the installation, maintenance, and removal of applications on a device. However, this sample implementation does not emulate any application manager in particular, as the behaviour of application managers varies from device to device.
The following devices are supported:
DefaultColorPhone. Generic telephone with a colour display.
DefaultGrayPhone. Generic telephone with a grey-scale display.
MinimumPhone. Generic telephone with minimum display capabilities.
RIMJavaHandheld. RIM device from Research In Motion Ltd.
Motorola_i85s. Motorola i85s telephone from Motorola, Inc.
PalmOS_Device. Palm OS personal digital assistant from Palm. Inc. (The emulation uses the Palm OS Emulator from Palm, Inc.)
The WTK provides a competent basic environment for developing MIDIets. Clearly, with its lack of integrated editor and debugger facilities, it cannot (and indeed does not aim to) compete with the commercial IDEs available.
5.2 J Builder X Mobile Edition
as that for normal Java development, with the exception of additional tabs and options in existing dialog boxes, and two new wizards: the MIDIet wizard and the MIDP Displayable wizard. Also, in JBuilder Professional and Enterprise Edition, the Archive Builder can now create a MIDIet suite and its corresponding manifest and JAD files. Mobile Edition also installs WTK 1.0.3 which is utilized as the emulation environment. However, instructions are provided for integrating Mobile Edition with other J2ME JDKs, such as the Nokia Developer's Suite for J2ME and Siemens Mobility Toolkit (SMTK).
In addition to the core JBuilder features, Mobile Edition adds:
Code completion for CLDC/MIDP classes
Class/package browser for CLDC/MIDP classes
JDK switching
MIDP wizards
Visual designer for MIDP Ul elements
Debugging of MIDIets
JAD and JAR file packaging
Over The Air (OTA) provisioning
*i HelloWorld j *> HelloWorMDisplayable !H package hellosiute;
irtjjort javax.microedition.iidlet. *; urvort javax.ssiCEoedition. Icdui, * ;
public class HelloWorld extends MIDIet ' static HeiieWorld instance;
HelloWorldDisplaysble displayaMe = new HeiloWorldDisplayable (}, For* focal;
/** Constructor */ public HelloWorld() {
instance this;
tty {
jblnit();
>
catchiException e) ( e.printStackTrace();
HelloWorld iava
14 10
Modified
if
Insert
Source Design Bean Doc j History
Figure 4: BORLAND JBuilder X Editor Window
The main features the source editor supports are:
Brace matching Keyboard shortcuts Syntax highlighting Customisable editor key mappings
Codelnsight (code completion, parameter lists, and tool tip expression evaluation) Code templates
Multiple file editing via a tabbed interface Re-factoring
8lh-Semester' Branch: CSE Project Title: Implementing a Multi- Device Compatible J2ME
based Mobile Game
The Mobile Edition (Enterprise) also provide a whole host of non-J2ME specific such as UML code visualization, re-factoring, integrated unit testing and team development. A full review of these features is outside the scope of this document, but in a large commercial project these features can be expected to increase both individual developer and team productivity. The Enterprise Edition provides J2EE development facilities, thus allowing development of enterprise-wide J2ME solutions.
JBuilder has been through several releases over the past few years and is one of the most popular commercial Java IDEs available. The Enterprise Edition, in particular, has enjoyed wide acceptance by many blue-chip companies for development of their Java enterprise wide solutions. The addition of Mobile Edition integrates J2ME effectively into the existing JBuilder environment.
5.3 Sun ONE Studio 4.0 EA Mobile Edition
Sun ONE Studio 4.0 EA Mobile Edition is a specially customized version of the Sun ONE Studio IDE to support and facilitate the development of MIDP applications. It combines the technologies of the WTK (Sun ONE Studio ME installs WTK 1.0.3) with the Sun ONE Studio programming environment to provide the following:
Integrated compilation, pre-verification, and execution of MIDIets and MIDIet suites
Automatic generation of JAD and JAR files
Integrated source-level debugging of MIDIets
Code completion against J2ME APIs
The ability to preset default compiler/pre-verifier settings on a per project basis
Integration with third party emulators/JDKs through the Unified Emulator Interface
Templates for creating MIDIets and MIDIet suites
An integrated default emulator
A target emulator that can be switched via the emulator registry for each MIDIet suite
An Auto Update tool that enables modules to be added and ensures existing features of the IDE are kept up to date.
To provide the simplest yet most comprehensive environment possible, Sun has removed some core modules of the Sun ONE Studio IDE. These features are unsupported by the J2ME platform, or are unnecessary for creating mobile device applications.
Sun ONE Studio ME is a good first attempt at a J2ME IDE. All the J2ME features integrate appropriately into the existing Sun ONE Studio programming environment. Developers who have a basic understanding of MIDP application programming and previous experience of the Sun ONE Studio programming environment should be able use Sun ONE Studio ME effectively within hours. However, Sun ONE Studio ME lacks extra J2ME-specific features to differentiate it from competitor's IDEs. Most of the features provided are simply leveraging features from the existing Sun ONE Studio programming environment and targeting them at the J2ME developer.
ft
SREE NARAYANA GURUKULAM COLLEGE
Page Number: 45
kadayirippu
if Source Editor [HelloW<irlri
* HelloWorld. Java
' ere:*.*! c-t: May t
iriiort iavax.microedition.midlet.*; ini>ort iavax.microedition. ledui.';
* JlK exa&ple ffiDlet with sixple "Hello" text ani r:-zk&i*i.
* Refer to the startApp, pauseApp. artd destroys.;-;
- sethods so see hew each handles the revues l+j *::
* Sauthor s.ynt * inversion
public class HelloWorld extends MIDIet inclements CoumandListener
private Command exitCommand; ." i'h* e>;i . : iL: private Eisplay display; 1/ I<hi ;
public HelloWorld () {
display = Display.getDis^lay(this) ;
exitCommand = new Coitmand("Exit", Command. SCREEN, 2.):
)
Figure 5: Sun ONE studio ME source editor
8lh-Semester Branch: CSE Project Title: Implementing a Multi- Device Compatible J2ME
based Mobile Game
6-Project Specificaiton
Project: Implementing Multi-Device Compatible J2ME based Mobile Game.
Project Objectives: Build a graphic rich multi-device compatible game for entry level colour mobile phones that support Java platform.
Target Device: MIDP/CLDC 1.0 or more supported handsets.
Target Device Constraints: Resolution : 128 * 128 pixels Maximum Application Size: 50-64 Kb Memory (Heap):200 Kb
Development Platform: Java 2 Micro Edition 2.0 /MIDP 1.0 / Vendor specific API's(Nokia/Siemens/Motorola)
Device Specific API: Mapped to the API during runtime
Development Requirements: Java 2 Standard Edition v 1.4.1
Java 2 Micro Edition Wireless Tool Kit( J2WTK) 2.0
Nokia Developer's Suite for J2ME ,v 2.0 (Windows)
Integrated
Development
Environment: JBuilder X Mobile Edition Trial Version
Workstation Requirements: X86 class processor with more than 800 MHz
Processing Power
384 MB Ram
2 GB Hard disk Space
Windows 2000(Service Pack 4) / Windows XP (Service Pack 1)/ Linux (Redhat 8.0 or above)
Time Frame: 3 Months
7.Game design specification
7.1 Game Overview
Street Racer is an arcade scrolling car racing game The objective of the game is to gain as much points by driving the car as long as possible. The player is faced by many obstacles including traffic, he is provided with three lives, the player will lose lives, if he runs out of fuel(fuel can reloaded by driving over the fuel bank which is randomly placed) or collide with the traffic or when the police car hits.
7.2 Theme: Graphics and sound
The game is played on a background which is an image of the road. The background is scrolled down to create a perception of an endless road. Though the MIDP profile by itself does not support sound the device API's are used to create simple sound when the cars collide with objects and notification sound is also used when the player car is drawn over the fuel object. The entire images are to be in the PNG format.
7.3 Characters and Descriptions
The player controls the race-car, which is little different from all other cars on the screen. The player can move the car left/right/accelerate/brake. The traffic cars, that moves on the road with predetermined velocity at different portions on the background.
The fuel object floats on the road, the player can get the fuel by driving the car over it which increases the fuel of the car.
The police car object, which chase the race-car and tries to hit it. It traces the exact movement of the race-car. This can be used by the player to make the police car collide with the oncoming traffic and get away.
7.4 User Interface
The user interface diagram shown below shows the flow of the game. The events are described in the sequential order as follows:
1. This is the introduction screen of the game. This screen lasts for 3000 milisecond. Pressing the skip soft key leads to the next screen.
2. This is the Menu screen. Each highlighted item leads to corresponding event screen. Pressing the select soft key opens the game screen.
3. High Score screen displays current game score. The view and clear submenu items are used to view and edit high score list.
4. The next is the game screen which directly leads to the game. The pause soft key is used to pause the game Pressing the exit soft key exits the game.
8lh-Semester Branch: CSE -
Project Title: Implementing a Multi- Device Compatible J2ME based Mobile Game
7.5 Media Assets Specification
To implement a graphic rich game one has to rely on a lot of images. As most of the entry level colour phones support displaying bitmapped .PNG images. These images are compressed very extensively and is usually composed of 4 bits per pixel (bpp), to reduce size compared to 24 bpp in true colour. The size varies from 915 bytes to 1.5 kilo-bytes.
The various images used in the game are listed as follows. To create an animation, some of the images are being used as frames
Figure 7: Sprites for ongoing traffic
Figure 8: Sprites for upcoming traffic
b) car_down.PNG(The image presented here is 100% magnified).
This frame of images is used to introduce downward moving cars.
a)car_up.PNG (The image presented here is 100% magnified). This frame of images is used to introduce upward moving cars .
A
Figure 9: Sprites for Police.
c) car_police.PNG(The image presented here is 100% magnified). This frame of image is used to introduce chasing police cars.
Figure 10: Sprite for fuel bank
d) Fuel.PNG(The image presented here is 100% magnified).
This frame of image is used for presenting fuel during the game play.
Figure 11: Sprites for player car.
d) Race_car.PNG(The image presented here is 100% magnified).
This frame of image is used to introduce moving racer car. Player controls the movement of this image
Figure 12: Sprite for Background
d)Background.PNG
This image is used to create scrolling background. This background was rescaled to fit in to screen of size 128X128pixels
All these images mentioned here except Background.PNG have been rescaled to the size of 13x30 pixels using the common image editing tools like MS-paint and the conversion tool IrfanView.
The total size of all the images combined together accounts to about 40% of the total application size(15 bytes).
7.6 Sound and Vibration
Sounds an vibrations are not supported by the MIDP configuration. However to create a complete game with lot of effects, sounds are necessary. Our game tries to use the device specific API's to play sound.
An important criteria that must be considered while designing sound for the game is the sound file should not consume much memory space. All the
Sounds are hard-coded rather than being saved as .MIDI or .RTF(Ring Tone Format)to save size.
a) Beep Sound : This sound is played when the player drives the car over the fuel. The following code snippet denotes the frequency specification.
(byte)0x02, (byte)0x4A, (byte)0x3A, (byte)0x80, (byte)0x40, (byte)OxOO, (byte)0xF3, (byte)0x48, (byte)0x22, (byte)0xC3, (byte)0x4C, (byte)0x35,
(byte)0x02, (byte)OxAC, (byte)0x22, (byte)0xC0,(byte)0x00
b) Car Crash Sound : This sound is played when the player car collides with any other object other than fuel bank.
(byte)0x02, (byte)0x4A, (byte)0x3A, (byte)0x80, (byte)0x40, (byte)OxOO, (byte)0xD2, (byte)0xC8, (byte)0x31, (byte)0x03, (byte)0x90, (byte)0x23,
8.Design Issues
8.1 Portability and Look and Feel
Portability issue mainly concerns with running game in a functionally correct manner on a variety of MIDP devices. This also determines whether the game MIDIet is able to run on standard MIDP devices by using the vendor-specific APIs (such as the Samsung Ul API).
Look-and-feel is mainly an issue of whether the game feels good to a human player on a variety of MIDP devices. This determines whether game's user interface look reasonably good and respond well on a wide variety of standard MIDP devices (whose physical characteristics such as screen size, color depth support, keypad, etc., are different) and whether game can be tailored or customized to "look" especially good" for some specific device or device category (i.e., for a specific display size, orientation, color depth, etc.).
8.2 Screen Characteristics
The most basic screen characteristics of a MIDP Canvas (a low level display API which MIDP device use to draw images are its height, width, color depth, and orientation. (Orientation means that a canvas may be noticeably wider than it is long, longer than it is wide, or square.) These characteristics vary in different MIDP devices.
8.3 Using PNG Bitmap Images
MIDP supports use of PNG images. These can be used to create tiled backgrounds, bitmaps for game sprites, etc. Each PNG image has a certain fixed pixel height and width. The J2ME framework does not support for methods for image translations to different sizes.
8.4 Keypad
The standard MIDP class Canvas supports keyPressed and keyReleased events. The keyPressed event is called when a key is pressed once. The keyReleased event is called when a pressed key is released The keyRepeated event may not be supported on all devices. The MIDP 1.0 specification does not specify whether MIDP device keypads should support multiple simultaneous key presses or not. The MIDP API can't be used to query a device about whether it supports simultaneous key presses or not.
ft
SREE NARAYANA GURUKULAM COLLEGE
Page Number: 55
kadayirippu
8th-Semester Branch: CSE Project Title: Implementing a Multi- Device Compatible J2ME
based Mobile Game
8.5 MIDIet Portability and Use of device specific API'S
The game screen must be made portable across classes FullCanvas/Game Canvas, for use on both Nokia/Siemens/Samsung and standard MIDP devices. FullCanvas is a subclass of the standard MIDP class Canvas. FullCanvas provides a full screen painting area.
8.6 Pausing and Resuming a Game
Implementing the functionality of Pausing or interrupting a game for the incoming call and resuming the game again plays an important part in the game design. The game must be designed in such a way that the gameplay doesn't interrupts the incoming calls and vice-versa.
The functionality of pausing and resuming a game can implement using the following ways:
Using MIDIet methods pauseApp and startApp
The MIDP specification defines the MIDIet method pauseApp to indicate that a MIDIet has entered a paused state. It defines the MIDIet method startApp to indicate that the MIDIet has entered the active state.
Using methods Canvas.hideNotify, Canvas.showNotify and Displayable.isShown:
Some MIDP implementations may never invoke methods pauseApp and resumeApp. For certain types of events, a MIDP device may instead continue to run the MIDIet's threads, and raise a system screen that hides the MIDIet display.
The following figure shows one possible example. The white boxes represent activities or events that are visible to the MIDIet's application code. The MIDIet does not know what particular type of system screen has been raised (e.g., incoming phone call, battery charging message, etc.).
Set current display with canvas showNoti fy () +
Canvas is
shown
System screen appears and hides display
uanvas is not shown +
' hideNotify()
Prompt user to resume after pause ends Pause game + canvas animation
System screen disappears
showNoti fy () +
Canvas is shown
User explicitly onfirms resume of game
Canvas animation thread resumes game
Figure 13: Flowchart showing pausing and resuming of a MIDIet
Pausing the game for a system screen that hides the display
Any MIDIet screen use the method Displayable.isShown to determine whether it is visible or not, and might pause certain activities (if needed) when not visible.
In addition, canvases use the methods Canvas.hideNotify (the canvas has been removed from the display) and Canvas.showNotify (the canvas has been made visible on the display) to determine whether or not they are visible. A canvas pause certain game activities (e.g., animation, game ticks, etc.) when hideNotify is called. When a subsequent showNotify is called, the canvas possibly resumes those activities.
User-initiated game pauses
The MIDIet must provide the functionality of pausing the game itself if the player wishes to stop playing temporarily. If the game canvas is based on FullCanvas, the MIDIet must pause when the player presses a soft-key command. If game canvas is based on Canvas, the MIDIet must pause when the player presses a labeled command like Back. For both cases, MIDIet could change the Ul screen state to an appropriate menu or command list, preferably with a Continue item highlighted.
Game Settings
The device specific Ul API classes provides sound support, the ability
to use game vibration, back light, or flashing lights in a game. If a midlet uses
these features, it should provide a Settings or Options menu to enable/disable
use of those features. In many cases, a volume level setting editor should
also be provided when sound is used.
8.6 Resolving Portability Issues
The "write once, run anywhere" principle of the Java technology is not that true in J2ME unless we use the base J2ME specification. The games designed using these specifications seldom looks good. Hence developing games requires extensive use of device-specific API's, which has become a threat to portability. The main methods to resolve the issue of portability are stated as follows
8.6.1 Java Tiny Grfx Library (JTGL)
JTGL NOKIA
JTGL- * SIEMENS App
Mr Mf MS lib
JTGL
; *\'
TGI MIDP 2 0
SUA MIDP 1 0
"4 MIDP 1.0
Figure 14: JTGL deployment diagram
JTGL is an open-source project to enhance portability. Here the developer builds the MIDIet using the JTGL library and compile it along with NOKIA-JTGL or similar to map it to a Nokia device and so on. JTGL is a full fledged gaming API, by which games can be programmed very easily. Thus
developers are shielded from the complexity of porting to different device specific API's . However JTGL being very new does not support much handsets. Currently it offers libraries for Nokia and Siemens only and documentation is very scarce.
8.6.2 Proposed Interpreter based solution
Here we propose a interpreter based tool, where developer programs the application using a language similar to Java and the interpreter based on the device - configuration which the developer provides maps it to corresponding device functions The advantage of this tool is that the MIDIet can be mapped to any particular device.
8.6.3 Methodology used in the project
The methodology we have decided is to use a manager class that check whether the current functions like (full screen, sound vibration) are supported in these devices by try calling various device specific API's .If it is available the API's are used, or else the standard MIDIet is used, without effects.
9.Designing and Implementing StreetRacer
MIDIet
8m-Semester Branch: CSE Project Title: Implementing a Multi- Device Compatible J2ME based Mobile Game
9.1 StreetRacergame MIDIet Class
The StreetRacergame MIDIet handles the MIDIet state model callbacks, leaving the User Interface to its various screen classes. The MIDIet also provides a central "state model" for the screens, so that screens call back the MIDIet, and the MIDIet displays the appropriate next screen, rather than each screen handling its transitions directly.
Class StreetRacergameMIDIet is responsible for updating the display with