During the first phase of mobile gaming, traditional game developers sat on the sidelines. The mobile gaming era starting with WAP gaming, and the text only displays did not stir up interest. The environment was slow and awkward and WAP gaming development did not exploit the strengths of Game Boy and console developers. Now a new generation of phones is on the market, with the processors, memory, and color depth provide the ingredients for compelling game development. This article discusses some of the high level issues for developing Game Boy-style action games for the new set of phones, focusing on the phones and platforms supported by the major carriers.
Today, a new dawn has emerged in game development – the mobile phone era. For the past couple of years, the media has fawned over the potential of mobile gaming, with sky-high revenue projections by analysts and a proliferation of conferences and seminars. Everyone in the industry has talked about it, either turning a cold shoulder or showing some lukewarm interest, waiting for a sign that the market is there. Well, finally, reality has caught up with the hype. The new wave of color phones released by the US carriers provide a reasonable platform for traditional game development and the business models provide correct financial incentives for developers and publishers. In addition, traditional game companies like Sega and THQ have entered the space, providing much needed credibility.
During the first phase of mobile gaming, traditional game developers sat on the sidelines. The mobile gaming era starting with WAP gaming, a text based markup language similar to HTML with limited graphics. The text only displays did not stir up interest, causing consumers to avoid mobile games despite the penetration of millions of internet-enabled phones supporting WAP. The environment was slow and awkward and WAP gaming development did not exploit the strengths of Gameboy and console developers.
The US carriers quickly moved to resolve these problems, in part, by the success of I-mode in Japan, which has over 30 million subscribers and drives a significant portion of its revenue from downloaded entertainment like games. The carriers introduced or have announced support for the next generation of internet capable mobile phones. These phones, compared to the old black and white text phones, are faster and more powerful, with colorful screens and limited internet browsing capabilities, with connection speeds faster than most dial-up PC modems.
While the new phones are not the perfect gaming platform, it’s a solid start. The processors, memory, and color depth provide the ingredients for compelling game development. The capabilities have focused developers on pushing quality levels up to the standards gamers expect from other platforms. Problems still exist, however, but these problems will be fixed, as they were on the PC with the continuous improvements of DirectX.
Throughout the world, there are many implementations of application driven phones. In Europe, J2ME and Symbian are popular. In Asia and the US, J2ME and BREW have strong market penetration.
This article discusses some of the high level issues for developing Gameboy style action games for the new set of phones, focusing on the phones and platforms supported by the major carriers, like the Motorola i95cl from Nextel, the Samsung A500 from Sprint and the Sharp Z-800 from Verizon. Successful developers must support the widest selection of phones. Optimizing your game for one phone, or even for one carrier, is foolish when there are over 30 next generation phones. While highly optimized outcomes are nice, it is not a profitable effort.
While many efforts exist for standardizing game development, effective solutions are still years away for most phones. While phones exist with incredible processors and efficient gaming APIs, it is not easy to develop rich engaging games. In the interim, developers must deal with the current realities.
In some ways, the new generation of phones is similar to the old Gameboy Color (GBC), which is a great benchmark since most developers are familiar with it. The two share many common characteristics, like portability, limited memory, 2D graphics, and similar form factors. The wildly successful platform is the perfect model to emulate. The approach to game design with small screens allows for creative interface design and gameplay. While the Gameboy demographics and cell phone gaming market don’t overlap completely, having over 100 million units sold worldwide provides a familiar platform.
While the current phones are not gaming devices, they’re powerful machines nonetheless. The processors, memory, and color depth far exceed that of the original Gameboy. However, the cell phone’s weakness in display speeds/refresh rates, sound, and input more than make up for its strengths. The raw processor speed is not as important as the system architecture and the implementation of its APIs and operating systems.
In some ways, it is unfair to compare cell phones to Gameboys. Cell phones will never be highly specialized game devices. Like the PC, cell phones are multi-function devices, with generic processors and architecture to support time-consuming process like digital signal processing and modem emulation. Gameboys, on the other hand, are designed from the development environment to the hardware architecture to do one thing - provide a lighting fast graphics pipeline that allows for compelling games. That does not, however, absolve the phone manufacturers and carriers from improving the game experience.
Despite the advances, creating mobile games is much different than traditional game development. It’s very difficult to create compelling games. It’s more difficult than console or PC development because of the numerous devices with different memory, sound, and display capabilities. On top of that, you must manage different development environments like BREW and J2ME.
Mobile game development requires a different approach. The budgets in the mobile game space are small and timelines are short. The platform has a variety of hardware and software combinations, without a lot of common ground between the hardware manufacturers
First, spend more time planning. Developers have a tendency to cut corners. However, to create a world-class game, you must apply world-class development processes. Apply the same set of processes used for console, PC, or Gameboy projects. The key steps are design concept, pre-production, production, and QA/testing. Unfortunately, because of the diversity of devices and carriers, developers are forced to spend much more time upfront planning projects carefully. There’s a risk that a design that may work on one device could be impossible on another.
Second, like the PC, develop to the lowest common denominator of hardware, meaning your code base must not make any low-level assumptions on how the hardware interacts with the operating system and/or programming language.
Third, similar to the hardware issue, develop to the basic functionality between the two APIs. Compare the differences of the software development environments and design around their weaknesses. Developers must spend more time understanding both platforms, but the efficiency on the back end is well worth it.
The two leading mobile development environments are J2ME and BREW. J2ME is the leader in mobile application development with the support of most US carriers. However, Verizon, the largest carrier in North America, and Alltel both support the BREW API developed by Qualcomm, thus making BREW a necessary platform for the foreseeable future.
BREW is more of an OS and supports programming languages like C and C++, allowing for very tight and efficient code. J2ME is an interpreted language that runs on any OS (including BREW) that has a virtual machine, causing, in general, slower code and more challenges in optimizing code.
In both environments, developers are at the mercy of a manufacturer’s implementation. For example, if display speed is not a priority, manufacturers can support the basic version of J2ME and BREW – neither of which has a standard internal method of direct access to the screen, which could result in routines that cannot support fast full screen draws.
In the interim, the challenge is to easily create games for both environments. The BREW API handles things much differently than J2ME. Cross platform development is the only way. Obviously, the code base for C++ is different than JAVA, but the two platforms should share most everything else. This includes dataflow design, general interface model, art, level data, and sound resources. It causes some unfortunate compromises, but it can make your development process more efficient on the backend. No one should write two versions of their game. That’s a money losing and inefficient plan.
For example, BREW 1.0 supports masked blits, whereas J2ME MIDP 1.4 does not. Also, some J2ME phones do not have sound support. So your base code should not depend on masked blit support or sound support. For example, if you create custom bitmap fonts, you might think you need masking. However, you could create font bitmaps with the correct background color ahead of time. Both platforms make it possible to make palette changes while loading a file, allowing you the capability to adjust the font background colors dynamically, meaning, of course, the text must appear over a solid background. If a phone has masked blit support, use it. It’s much easier to scale up than to scale down.
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.
Read more about:
FeaturesYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
