The State of Play

So here you are; you've covered all the foundation areas of J2ME technology, and you've even made a little game. However, a professional J2ME game today needs to be a lot slicker than yet another Frogger clone. So in Part 3, you'll learn how to cover more ground than the wombat in RoadRun.

J2ME game development is an exciting area right now, and I don't see that changing anytime soon. Every week there seems to be yet another high-powered, full-color, big-screen, Java-enabled phone released by manufacturers. I'm not going to bore you with the stats just visit your local mobile phone shop and browse through the selection. Anything mid-range and up is a J2ME-ready machine just waiting for your game to bring it to life. The size of the market for your games today is already large; the size of tomorrow's market is downright scary.

Thankfully, we're a little beyond the micro-caveman days of SMS, WAP, and monochrome J2ME games. Today, it's well designed, high-quality games with crisp color graphics and addictive game play. Modern J2ME games are just as much fun to make as they are to play.

Platform Issues

J2ME is a new platform with its own idiosyncrasies, so a game that works well on the bigger systems is often impractical on J2ME. You need to take into account smaller, dimmer screens, limited input, slow CPUs, and some pretty severe resource limitations to design a micro game that is practical, usable, and above all, fun.

In the next few sections you'll look at the practicalities of micro gaming and, more importantly, how these should affect the design of your J2ME game.

Screen Limitations

MID screens are small LCD-based displays typically in the range of 100200 square pixels. This makes screen real estate a scarce commodity. When developing a game, you need to consider the size of graphics.

The average MID's LCD also lacks brightness and color depth, so those beautifully rendered graphics that look great on a PC can appear dim and washed out when you see them on an actual device screen. In addition, the reduction to the average 12-bit (or lower) color depth will have quite an impact on presentation quality. Keep in mind that PC emulators won't emulate this feature, so you should try your graphics out on a real phone in a bad lighting situation.

Low-end LCDs also have issues with the speed at which pixels can change color. This slowness can create a noticeable blurring or ghosting of images, especially if those images are moving quickly across the screen. In cases where graphics change quickly, such as action games, you might need to slow things down so the player can keep track of the graphics. Don't underestimate the effect blurring can have on game play. If you're planning an action game, you need to keep your implementation flexible enough to slow things down if necessary.

Control Freaks

If you've played games on your phone, I'm sure you'd agree the input isn't the greatest. It's easy to appreciate the placement, size, and tactile response of a typical PC keyboard far more after you poke away at a phone keypad for any length of time. The typical size and keypad placement makes it difficult to pull off what you would consider simple on a keyboard or game pad, and you need to keep this in mind when you design the input for your game.

The placement of keys isn't the only issue. Most MIDs don't support simultaneous key presses. You won't truly appreciate how restrictive this can be until you rely on this feature in an action game. Imagine a side-scrolling shooting game in which you can't move down and fire at the same time! Typical MIDs also have a high latency on key presses, so your game might frustrate a player if you rely too much on instant responses.

These control limitations can cause some major issues, so if you're planning to create an action game, you need to consider these restrictions carefully and do your best to work around them. One effective method is to automate some control aspects, such as an optional auto-fire or auto-thrust.

A good game also uses keypad-friendly controls or repeat functions so the player doesn't have to press another key. For example, if you have multiple pop-up windows in your game, such as an inventory, map, and character info screens, you should consider displaying them all sequentially using the same key, instead of assigning different keys to each option.

Processor Power

Due to size and power consumption constraints, MIDs typically have low-end CPUs. The slow performance is accentuated by the lack of floating-point hardware because you need to spend extra time doing that work as well. When you are programming the game, you must constantly keep in mind the CPU performance of the real device (not the emulator).

From a design perspective, there's nothing in particular you need to avoid. In fact, I encourage you to go ahead and develop anything you want. There are plenty of methods to reduce the CPU requirements for code. Just keep things flexible and leave yourself twice as much time to optimize as it took you to develop something in the first place.

Storage Limits

One day you'll be happily coding away, the game will be going great, half the features will be done and then boom … java.lang.OutOfMemory! It'll be quite a shock, and development will suddenly come to a grinding halt. At this point the memory constraints of MIDs will finally hit home. If you're only halfway through all the features of the game, how on earth can you add anything more if you can't create variables or instantiate classes?

Memory, or more accurately the size of the application heap, is usually the first MID limitation you'll encounter. (JAR file size and CPU limits don't usually show up on emulators.) Modern gaming MIDs can have quite a range of memory capabilitiesanything between 100 KB and 500 KB is common. This might not sound too bad until you consider that all those pretty game graphics take up heap memory as well (in their much larger decompressed states). A game with reasonable-quality graphics can find itself with less than 100 KB to play with. Instantiate a few objects and a reasonably-sized level, and you're out of space.

There is another type of storage you should also keep in mindthe non-volatile RAM used by the RMS. Unlike PC hardware, you won't have virtually unlimited space in which to store saved games or other state information. Thankfully, though, you normally have enough space to meet the needs of a standard game; just don't plan to have a history of 50 saved games.