November 24, 2004
Developer case study:
The story behind ARES II from Brownbear.
High-performance action with MIDP 2.0

[Back]

Brownbear Mobile Games in Singapore was one of the winners of the Sony Ericsson Game Developers Challenge 2004. The immediate impression made from ARES II is the action and number of moving objects. How did Brownbear succeed in implementing all that in the relatively small environment (compared to game consoles and computers) that a mobile phone represents? We asked them to tell the story behind ARES, including tips based on their own development experience.

The idea and inspiration
There are lots of shoot'em'up games on the market, even for mobile phones, but Brownbear feels that most of them are pretty predictable. You can tell when enemy ships appear and when they'll fire one or two bullets at you. In ARES, there are more than 10 different kinds of enemy ships firing with various weapons. For each kind of ship, there are three to five different types of formations. You have to play the game in order to experience the implications of this. At the end of each level, you have to combat the Boss, which is not a single monolith as you find in many shoot'em'up games. The Boss in ARES is actually made up of at least three components, the main body, the left arm and the right arm (there are even more components at higher levels). The player can focus on eliminating the main body or the smaller side arms. The game is designed to be unpredictable by adding a twist here and there while the game is running.

Getting from MIDP 1.0 to 2.0
The initial version of ARES was developed in MIDP 1.0, but Brownbear faced problems with this version, particularly in two areas:

1. Processing speed; most MIDP 1.0 devices are too slow for the game's higher levels (there are up to 100 simultaneous enemies).

2. Audio; the sound playback was not smooth.

With MIDP 2.0, GameCanvas and sprites could be used that eliminated much of the previous, low-level code for game graphics and manipulations. The porting to MIDP 2.0 was actually done quickly. The K700 hardware platform (one of the target phones in the Sony Ericsson Game Developers Challenge 2004) is very efficient in handling all the graphics and audio files that the game pushes on it.

The initial design philosophy of ARES II was to have one single build for all J2ME MIDP 2.0 phones. During the design and coding phase, extra effort was put into making the code intelligent enough to automatically:

1. Detect and resize to the current device's screen size (like vector graphics).

2. Calibrate according to the hardware platform's processing speed.

Both these targets where reached and the game self-adjusts to all screen resolutions on the market today. However, point 2 of calibrating to speed, was not implemented in the commercial game, but was taken out because of usability concerns. The self-calibration for processing speed took two to three minutes, something that initially gave the mobile user a bad impression.

Optimizing code
One of the main challenges was to squeeze the functionality into a smaller .jar file. The first version of ARES had a high-score screen, an entry keyboard for player names and a fancy introduction which took up a lot of space. Those functions were sacrificed, but core functionality like help, options and language selections were kept. Here are some general guidelines and tips for optimizing code:

1. Avoid generating too many class files, since it inflates the size of the jar considerably. It's against the best design rules of OOD (Object Oriented Design), but in doing so you can save a lot of memory usage during runtime.

2. Optimize functions to be re-used. For instance, ARES has one dialog-box method that is used in almost 90% of the game.

3. Graphics should also be designed for re-usability. Try to use tiles and sprites optimized to have less than 255 colors.

4. Avoid using drawString to the canvas as it consumes too much CPU. Instead, create an image and draw the string into the image during initialization, for example, by using scoreText textlabel in your constructor method:

stringImage = Image.createImage( font.stringWidth( scoreText ), font.getBaselinePosition() );
imageScore = stringImage.getGraphics();
imageScore.setFont( font );
imageScore.setColor( COLOR_FG );
imageScore.drawString(scoreText, 0, 0, Anchor );

5. Avoid using synchronized methods since object lock needs to be obtained and they're the slowest. Use final static methods where possible, they're the fastest.

Game throttle control
Just imagine how a Pacman game designed to run on an old Intel486 would behave on a Pentium 4. It would simply be too fast for a decent play. Game throttle control is easily overlooked during design and programming of mobile games. Below, you'll find a basic code snippet shared by Brownbear. It's from the core of ARES II and illustrates how this can be overcome. The player can be allowed to set ThreadSpeed from settings and then game speed is easily managed in the main thread loop as shown here:

  public void run() {
    long PointOfTime  = 0L;
    do {
      try {
        Thread.yield();
        if ( (System.currentTimeMillis() - PointOfTime  >= (long) ThreadSpeed)) {
           PointOfTime  = System.currentTimeMillis();

           . . .
          gameEvent();
          // j2me2 :
          scanKeyEvents();
          DrawGraphic();
          // j2me2 :
          flushGraphics();

        }
      } //endif
      catch (Exception exception1) {
        . . .
        return;
      }

    }
    while (true);
  }

Tools & Sources
"Sun Java Studio Mobility" and "Eclipse" were used by Brownbear as the primary IDE's. They were selected because of the good support for J2ME toolkits and because they run on Linux. A basic version control tool like CVS was used to streamline the code management.

Tan Wei Wei, Business Development Manager of Brownbear, says:
"The Sony Ericsson Developer World forums were a very good source for developers like us to discuss and share our experience during the Sony Ericsson Game Developers Challenge 2004 and the development phase of our MIDP 2.0 game. The site has constantly provided good examples of code snippets and very useful advice. A good example is the Language support code. Without it, we would have spent several extra days in coding and testing. Another nice feature found on the Sony Ericsson Developer World site is the on-device debugging tools. They really give the developer insight in code behavior on the actual device and helps in troubleshooting and optimization work."

Below you can see images of the ARES II game on a number of Sony Ericsson phones, using the device emulators in the Sony Ericsson J2ME SDK.

Brownbear Mobile Games is located in Singapore where the number of game development companies is small but growing. Thanks to Brownbear's location, there are a number of Chinese versions of their games and this is also true for ARES II. The game has been ported to Simplified Chinese and Traditional Chinese (some example shots are provided in the image below). Brownbear also has the capability of creating games with a Japanese or Korean language interface if required.

For more information: 

• Brownbear Mobile Games's website>> 
• Winner profile: Brownbear>>
• The Sony Ericsson Game Developers Challenge 2004>> 
• Sony Ericsson discussion forums>> 
• Java Tips, Tricks & Code>> 
• Java Docs & Tools>>