Things to consider when porting J2ME games

Porting an existing game means you're already halfway there

The game development process always begins with a concept stage. Ideally, the pre-production stage for an immersive game should last at least one month. This includes defining the main concepts, debating with the development team on the possibilities of execution, analyzing market feedback on the feasibility of success and finally completing the game design document for the development team. But the process never ends there. Until the game is launched, debates continue and changes are always taking place.

However, when you think of porting a game, you are skipping the pre-production stage. You have a team who have "been there and done that"—as a game porter, your main job is define the steps needed and get into action.

Save yourself from graphic design limitations

Developing a new game often puts designers in an "Artist Block" mode. This is not uncommon in a creative field because creating compelling game visuals is not a simple task.

Additionally, designing for a mobile phone with J2ME has its own share of limitations. The graphic designers have to adhere to certain rules, such as:

1. Avoiding anti-alias, because creating the smooth effect uses too many colors.
2. Restricting the number of colors, since the main purpose of pixel art involves creating acceptable images with the least possible colors.
3. Using a limited tool set in an image editing program. This constrains an artist to tools like the pencil tool, bucket tool, selection tools and color replacement tools. Generally artists avoid using gradients, drop shadows and special brush effects in game design.
4. Creating graphics with vectors, rather than drawing freehand. Hand drawn images contain a lot of uneven lines and extra pixels. A pixel designer should strive to create very clean graphics, removing all unnecessary information (see Figure 1).

Figure 1. Graphics for games should be designed with a clean look to avoid unneeded pixels and color variations

As you port the game to Flash from J2ME, you can choose to either use the existing bitmap graphics (if they look clean) or recreate the graphics as vectors in Flash.

Fortunately, when graphics are recreated in Flash you are not restricted to using limited tools or limited colors. The only caveat is to be careful when dealing with curved edged vectors. This is especially true when designing small graphic elements—try to use as many straight lines as possible (see Figure 2).

Figure 2. Use as many straight lines as possible when designing small game graphics

Here's another example: We created a round cursor graphic that was 12px x 12px for our ported Flash game. Whenever we tested the game on the device, one side of the round cursor always looked a bit flat. To remedy this, we created a polygon of multiple sides instead of using a circle. When we tested the game again on the device, we had a perfect looking circle, when in reality it was a polygon!

Think of it this way: If the bitmap graphics of a J2ME game display clearly, you can use the existing bitmaps in your ported version; otherwise redesign the graphics in Flash as vectors.

Use classes to help simplify the porting process and separate the code

I think one of the most important considerations to ensure an easy port of a Java game to Flash Lite involves separating the game logic from the user interface code.

Ideally, a game developed in any language should have its own classes to handle the game logic, key controls and change in state of the game. Other game features, (such as interface design and persistent data), should be handled by their own classes.

The greatest advantage to adopting this method is that the J2ME developer can track the exact game engine code and variables, making the conversion task for the Flash Lite developer much easier. Also, since the J2ME and Flash Lite OOP basic syntax is similar, the conversion of the game logic does not require many corrections.

The sample code below was copied from one of our porting projects that involved porting a J2ME game to a Flash Lite game. The code explicitly shows how the game engine code for J2ME is similar to that of Flash Lite. The first example is a simple declaration of variables in J2ME (see Figure 3).

Figure 3. Declaring the variables in the J2ME game

The second code example shows a similar declaration of variables in our ported Flash Lite version of the game (see Figure 4).

Figure 4. Declaring the variables in the Flash Lite version of the game

If you compare the two code snippets above, you will notice that the variable declaration is very similar in J2ME and Flash Lite. In fact, the code in Flash has been altered and optimized to make it more adaptable for Flash on mobile devices. For instance, in the J2ME code example each game mode has been declared as a separate variable, (such as MODE_NORMAL, MODE_TIMED and MODE_SURVIVAL). In contrast, the Flash Lite code declares a single variable, (gMode) which dynamically stores a value, depending upon which mode the user chooses to play in at run-time.

Testing 1-2-3

Although the original game was tested thoroughly, your ported game requires a testing phase too. It is critical that game developers identify and eliminate bugs before distribution, in order to provide expected game play on all platforms.

Flash Lite porters have a huge advantage here, because they already have the bug list of the game from the J2ME development phase. As a Flash Developer responsible for porting the game, you simply need to run through your game file and check to see if you are repeating any errors from the bug list. This step is very important and highly recommended. Checking for repeated errors will considerably help reduce the bugs in your ported game.

Page 2 of 5

Previous Page

Next Page