It's free to join Gamasutra!|Have a question? Want to know who runs this site? Here you go.|Targeting the game development market with your product or service? Get info on advertising here.||For altering your contact information or changing email subscription preferences.
Registered members can log in here.Back to the home page.    

Search articles, jobs, buyers guide, and more.

by Marcus Matthews
Gamasutra
[Author's Bio]
November 25, 2002

The Market

Mobile Development

Display Speed

Printer Friendly Version

[Back To] Mobile Games Resource Guide

Sponsored by:

 

 


Resource Guide

Developing Action-based Mobile Games

Mobile Development

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.

Incompatible Operating Environments

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


    join | contact us | advertise | write | my profile
    news | features | companies | jobs | resumes | education | product guide | projects | store



    Copyright © 2002 CMP Media LLC

    privacy policy
    | terms of service