Developing Action-Based Mobile Games

Tips

• Use C++ (or another object oriented language) in BREW, which makes it easier to support J2ME since it’s an objected orientated language.

• Lead with J2ME and port BREW. In general, anything written in Java can be done faster and better in C++.

• Keep all device output code (sound, display, input) abstracted from your game logic. Structure game logic so it’s portable between J2ME and BREW.

Display Speed

The biggest problem in mobile game development is the lack of respect for display speed. While the carriers have done a good job selecting powerful processors and bright color displays, they’ve ignored an important area for gaming.

If you look at the various implementations of blits, manufacturers have over a 3x difference in display speed, even with similar speed processors. Different chips can explain some of that, but most is from poor implementation. The max frame rate on the current generation of phones is around 10 frames per second, severely limiting the response rate compared to 30-60 fps of Gameboy or console games.

The phones are using a variety of draw routines, with some supporting double buffering, while some are not. In some cases, it may be easier to draw straight to the screen. Drawing directly to screen is sometimes faster than double buffering. However, drawing larger images on screens with low refresh rates may cause flicker.

You should test a couple of draw routines using various size draw functions and bitmap images. This provides an indication of how fast the phone draws to the screen and where potential optimizations lie.

Tips

• Profile the phone draw speeds using bitmap blits and using built in draw routines like rectangle fills.

• Try double buffering and try drawing straight to the screen.

• Determine an efficient graphics pipeline.

• Find the bottlenecks in that particular phone’s implementation of the API or VM. You may find simple problems like how often you call the blit function affects the frame rate more the amount of total data moved.

Masked Blits

This is something we take for granted on gaming platforms -- creating sprites with a transparent color. This is not a rehash of the fundamentals of 2D graphics, so some assumptions of your basic knowledge have been made. This is, however, a discussion on how masking can be done when the environment doesn’t support it. If your platform doesn’t support masked blits, then you have two options, ignore transparency and draw rectangular sprites or create a rough approximation.

In some games, you can get away with no transparency, in cases where the sprites are small and the background is a flat shaded color. While that severely limits the variety of games, your games can look slick and polished.

On the other hand, you can approximate transparent blits by sub-dividing your image into smaller rectangular sections and composite the rectangles into a sprite on screen. This does not work for complicated sprites with a lot of curves and angles. Also, if the sprite consists of too many rectangles, the game’s frame rate could slow down significantly, because of the processor overhead for each blit to the screen.

Tips

• See if you can modify your design to support sprites without a transparent background.

• Sub-divide your sprites into smaller rectangles and composite the sprite in real-time. You may need to redesign your sprites to minimize the number of rectangles.

• If your API supports masked blits, use it.

Different Screen Sizes

Graphics is a key aspect of gaming, making draw speed an important programming function. Unlike console and PC gaming, mobile devices do not have standard screen sizes or aspect ratios, causing great compatibility concerns. By writing very flexible background and foreground drawing routines, developers can remedy this problem. The key is creating a structure that allows for quickly expanding or shrinking the game viewport without distorting the images or creating awkward on-screen proportions

Naturally, you have many ways to handle this. Worst case, you could redo the art to fit each phone’s display dimensions. Or, you could also dynamically adjust your game’s background and other graphics. Either way, there’s no way around customization for polished, action games on cell phones.

Tips

• 1. Create as many scalable graphics as possible using built in draw functions like DrawRectangle and DrawCircle.

• 2. Design the game so bitmap graphics can be stretched or reduced 15-20 percent without any impact on gameplay.

• 3. On scrollable game, expand or contract the playable area as needed.

Input Issues

Input can make or break a gaming experience. Gamers expect fast, responsive feedback. If not, your game will feel a bit sluggish. In the past, cell phones did not need buttons that responded in hundredths of seconds. Dialing a number isn’t that demanding.

Today, there are a few issues. First, if your key response rate is slow, your game feedback will be slow, and, unfortunately, there’s no workaround to speed it up. Second, and less obvious, is your frame rate, which was also an issue during the introduction of the Playstation One and Sega Saturn, where the 15-20 fps of some 3D games made the controls feel sluggish. In a single threaded environment like BREW, the time spent processing to draw to the screen, play the sounds, and calculate the physics is less time available to read and process key presses. Also, most phones don’t support simultaneous key presses, a staple of fighting and shooting games.

The mobile world is struggling with these issues. Currently, you must design around it. You can’t have games that require instantaneous responses to play well. You need to focus on momentum-based games where the character is moving and has some sort of inertia. For example, if the character is moving, design the game without an immediate turn left or right, but one that requires a gradual turn. Or better yet, create a skating or skiing game where immediate stops or turns are impossible. Stay away from fighting games or ones with similar gameplay mechanics, where characters are not moving a lot and require instant button feedback.

Tips

• Use momentum based controls to minimize slow response rates.

• Design around simultaneous button presses.

• Improve the frame rate. It will improve responsiveness.

File Size and Memory

Like the GBC, the mobile phone has severe memory constraints compared to consoles and the PC, making compelling game development tricky. At a high level, you have two issues – application download size and application RAM. The Sprint network, for example, restricts the application download size to 64KB, which constrains everything, including code size, graphics files, and game data. Techniques useful on the PC and console are rendered ineffective.

For application download sizes, you have two options. One, you can make your game fit within the download restrictions, making the game design and development effort much more difficult. Or you can design the game modularly, where the gamer must download new levels, providing tremendous flexibility for the developer, but adding the burdens of potential airtime fees for downloading new content and of disrupting the game immersion by inserting significant download delays, which can be very frustrating.

Getting the application file the on the phone is the start of the memory challenges. On top of that, the phones have major RAM limitations. Techniques like full screen double buffering may not be feasible on some phones.

Tips

• Reduce application download size by reducing game and code data. Try calculating arrays using loops instead of storing them in your code and drawing some graphics instead of storing them as images in your resource file.

• Both PNG and Bitmaps have overhead. To conserve space, try to collapse as many images into one super image. While that may take some extra coding, you can create significant space savings, especially with small images.

• Cannot use true OO. Each object class creates a significant code size overhead in Java. Not an issue with BREW and other platforms. However, if you want make your game portable, you should use the same structure across all platforms.

• Make use of smaller data types instead of always using 4 byte integers, especially for large game data arrays.

Tools, Tools, Tools…

Tools are a part of every developer’s repertoire. Despite the size and newness of the cell phones, developers must create tools to ease the process. As with the Gameboy Color, tools are needed for sprite management, tile creation, and level layout. While the upfront investment is significant, you will make up for it on the back end.

Art management is a unique issue. It’s good to have control over resource structure and allocation. Supporting multiple phones require numerous tweaks to the artwork and tools are essential for efficient management. Once you’ve made your 12th version of a sprite, you’ll appreciate having solid tools. You will need tools that can store graphics in your preferred format and then export them to the file formats necessary for the platform.

Until there’s a standard platform (if ever), you cannot optimize to one phone. Since your tools must support multiple devices, not only must they manipulate data, they must have inherent support for finetuning attributes, as needed for a particular phone. For example, if a phone X has 16 by 16 tile viewport, but phone Y has one 15 percent bigger, the tile editor needs a window display that shows the new viewport and can scale or shrink tiles as needed, giving the designer flexibility before submitting the design to the team.

Tools are needed for level layout and design. As with graphic files, abstract your level data from the phone and make it platform independent. If Java reads a file differently than BREW, structure your data independent of both platforms, and create one standard format that is easily transferable.

The Future

Most of these issues will resolve themselves over the next few years. However, the consumer expectations are high, having been spoiled by great games and graphics on 2D platforms like the Gameboy Color and Sega Genesis. As we saw with WAP, if the customers are disappointed, they will not buy into the service. It’s that simple and developers must do their part.

Some of the burden lies with carriers and publishers. The service must be reliable, easy to access, and priced right. The platform holders must work with handset makers to provide a robust, game friendly environment, including durable buttons, masked blits, and fast displays.

With the high level of interest in gaming, the carriers recognize the problem and are working fast to resolve those problems. I’m not sure what the solution will be or how long it will take for an efficient solution to appear. In the meantime, developers must improvise and be creative.