Related Topics: Apache Web Server Journal, Java Developer Magazine

Apache Web Server: Article

Programming Games in J2ME

Programming Games in J2ME

J2ME's Mobile Information Device Profile (MIDP) promises to become one of the most widespread computing platforms over the next few years as an increasing number of mobile phones include a Java Virtual Machine.

Given the popularity of preinstalled games on mobiles, Java games are likely to captivate a large audience. The first commercial download services for MIDP applications or "MIDlets" have already been launched and the market is set to grow at an explosive rate. Nokia alone expects to sell more than 50 million of these devices by the end of 2002, so the opportunities associated with writing good games for Java-enabled devices are staggering

However, while learning the basics of MIDP is simple enough for most developers, understanding the constraints of the platform and the tricks to get around them is crucial for efficient development. Creating compelling content, especially the type that uses the mobile network, involves a lot of trial and error. This article is a collection of lessons I've learned from coding games for the first generation of J2ME devices.

The key factor to consider when designing a MIDP game is your target audience and hence the set of target devices. If your MIDlet needs to run across devices with varying perfor- mance and graphical abilities, you need to take this into account in the design of your code. This is especially important when it comes to the use of libraries proprietary to a handset manufacturer, the use of graphics, and CPU-intensive AI calculations. If the aim is to capture the mass market, the game needs to be playable on the lowest common denominator device - currently a 64x95 pixel 1-bit screen, a slow, low-end CPU, and less than 100KB of heap memory. Modifying the code to cater to high-end devices should then ideally be a matter of modifying only a clearly defined portion of the application. It pays to spend some additional time on design. For example, a game written using the full Siemens game API for the 101x80 pixel screen of the SL45i will be very difficult to port to the Nokia 6310i if portability has not been designed into the code from day one.

One of the most notable shortcomings of game development in MIDP 1.0 is its lack of advanced graphical features. The Graphics class does not provide any form of transparency, whether you're using an image mask or defining a transparent color. There's also no way to read or write to individual pixels, which prevents even basic image manipulations, such as fading an image to black.

These limitations may not seem too serious at first, as the obvious way around them would be to read in local image files directly using the "javax" package and write decoders of JPEG or GIF or other image file formats. You could then map out the bytes of the image manually and overcome the above limitations. While this would result in full control over the image pixels, it's prohibitively slow. MIDP does not provide a fast pixel plotting function and there's no quick way of getting the resulting image buffer painted onto the screen. In fact, the only option is to draw lines 1 pixel in length with the drawLine() function. Filling a 100x100 screen with 10,000 drawLine() calls on a mobile device is just not feasible with near future device perfor- mance!

Most device manufacturers have responded to the limitations of the native graphics in J2ME by adding additional classes in their own proprietary API. However, it's dangerous to rely on these, as it breaks the portability of the code and is likely to result in lengthy and frustrating modifications to the code for different manufacturers' handsets. Generating an abstraction layer is, of course, an option, but with a maximum JAR file size of 30KB for typical low-end handsets, this type of layer must be extremely light. MIDP NG (Next Generation), scheduled for public review in the JCP in the near future, will fix some of these problems. Similarly, the Open Mobile Architecture initiative driven by Nokia promises much, but it remains to be seen whether it will be enough to make handset manufacturers converge on APIs.

When programming fast-moving games, there are a few additional points to keep in mind. Anyone who has done game programming knows that double buffering is an important tool to achieving smooth and "tear-free" animations. The implementation of the Graphics class is double-buffered on many devices, as can be seen by a quick call to the Canvas.isDoubleBuffer() method.

This means that any graphics drawing functions are buffered off-screen before they're displayed on-screen. However, as double buffering usually refers to switching between one back-screen buffer and one front-screen buffer, not buffers for individual Graphics calls, this has been the source of some confusion. Since all the screen paintings are done within the paint (Graphics g) method, it's not hard to imagine what happens when there are many Graphics drawing calls and each drawing call is displayed onto the screen one by one.

It's not difficult to write a double-buffering system. First set up an off-screen buffer in the form of a "javax.microedition.lcdui.Image", then do every drawing operation using the Graphics obtained from this buffer instead of from the actual screen. After you're done with the drawing, emulate the "flipping" of the buffers by drawing the whole offscreen buffer onto the actual screen in one go with one drawImage() call (see Listing 1).

Another issue to take into account is CPU speed and speed throttling. Since speed can vary markedly between devices, speed throttling should be applied to any games with animations. Some people calculate their own timed delays in their animation thread, while others prefer simply using the "java.util.Timer" to schedule a "java.util .TimerTask" for all the animation duties. Depending on the type of game, you may want to try scheduling the Timer to go off with a 50-100ms delay (10-20 fps).

Designing Networked J2ME Games
The prospect of providing multiplayer games for mobile phones is exciting. However, before you write your first line of code for your multiplayer first person shooter, keep in mind some important limitations. A good place to start is to look at the constraints of the network and what is possible using the J2ME communications library.

The oft-cited limitations in the bandwidth of current 2G and 2.5G networks are an important bottleneck for networked games. However, lesser-known but equally significant constraints are packet latency and variability in network performance. A limited bandwidth implies that communication over the network should be reduced to a minimum, while packet latency and variability mean that the code must run and be playable even in vastly variable network conditions. The problems are compounded by the implementation of network communication in MIDP 1.0.

All J2ME devices implement HTTP connections and some also offer a socket API. The package containing the communication classes is "", with the most important classes being Connector, Connection, and HttpConnection. The best way to communicate with a Web server is to use POST requests. Listing 2 shows an outline of an HTTP POST connection.

Alternatively, Listing 3 provides an outline of a sample socket connection.

The J2ME communication API has some notable limitations. It does not implement "" and neither does it support HTTP session functionality. If these features are required, there's no option but to re-implement them.

Figure 1 provides an overview of the elements in a networked J2ME game architecture using either GSM CSD or GPRS as a carrier. Relatively good performance can be achieved even on a GSM network, if the size of the message transmitted is kept to a minimum.

However, GPRS is the carrier of choice, as the user doesn't need to wait to connect and pays only for the data transmitted. While bandwidth is unlikely to be a problem, achieving an acceptable average latency over the network can pose a significant challenge. A round-trip time of 10 seconds over a CSD call on GSM and 4 seconds over GPRS can be considered average even with some optimizations. This limits games to the turn-based type that utilize only current network infrastructure. Real-time multiplayer games will be- come a reality only when 3G networks promising sub-100ms latencies are launched.

Despite the limitations, there are many things you can do with the network. Shared high scores or level downloads are a good example. Another is the possibility of playing against advanced game servers. Because of hardware limitations it's sometimes not feasible to develop a sufficiently powerful AI on mobile devices. Game servers have a vast advantage in computing power, which makes utilizing a server-side AI a compelling proposition. Take a scenario where the user plays locally and the AI uses a minimax alpha beta algorithm with a depth of two. On low-end devices this takes between 20 seconds and 2 minutes to calculate, and the game is hardly playable. Compare that to a scenario in which the user plays against a remote game server where the AI uses the same algorithm with a more powerful search depth of four. The server computes the move instantaneously, it takes 4-8 seconds to get the move from the server, and the game is much more playable.

The game server itself can be implemented as an HTTP server or a socket server. A socket server is faster than an HTTP server, as there's no HTTP overhead, but it can be used only for those devices that support sockets. In addition, using HTTP helps the long-term scalability of the service, as the number of active devices polling for moves and messages increases. As the client is written in Java, it's easy to connect to servlets and to implement the server in Java: the HTTP requests coming from J2ME devices are exactly the same as other HTTP requests. The standard Java Serialization API cannot be used in this case, but it's very easy to write your own. XML is a standard way to communicate with other types of Web servers like PHP or CGI, but it's obviously much less efficient.

Using a standard Web server like Apache/Tomcat or Jetty has the advantage of leveraging the scalability that has already been achieved for other Web/WAP applications. How- ever, due to the nature of the wireless client and the wireless network infrastructure, some modifications need to be made in order to optimize the data traffic, as Web server providers have yet to fully adapt to the wireless market. In the short term, the use of open source products may be a good solution.

An even better solution is to use a Java application server as a back end. EJB/JMS/J2ME integration is a very active topic at the moment and this is definitely the way forward to ensure speed, availability, fault tolerance, and quality of service for all networked wireless applications, including multiplayer games. This will also require some tweaking in these early days. For example, a combination of J2ME, Jetty, and JBoss is a good open source (nearly) 100% Java solution.

These are just a few technical issues to consider in the development of MIDP games. Many times an equally challenging task is handling the creative and business side of MIDP game development. With so many game ideas already exhausted and brands becoming increasingly important in the mobile marketplace, coding a clone of an '80s hit is no longer enough to convince an operator or download portal to resell your application.

A solid technology base and a good creative team is a must for a successful company in the MIDP games arena. But as in all things, it's on the business side where the battles for market share will eventually be won and lost.

More Stories By Sami Lababidi

Sami is a wireless technology enthusiast with a strong background in WAP, SMS and Java. Sami has focused on J2ME since its inception and has since been responsible for the development and deployment of J2ME products and services throughout Europe.

Comments (3)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.