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.
Supporting multiple devices in Flash Lite and J2ME
The biggest advantage Flash Lite has over J2ME is that a single compiled swf
file can be supported on multiple devices. In theory that is true, but it is
important to note that in real-world examples, the content may need to be
redesigned to fit the mobile device. User experience can be affected if
content that was designed for larger screens is scaled to display on a phone.
The S60 mobile devices come with different screen sizes. The list below
shows the most common dimensions:
176 X 208
240 X 320
352 X 416
320 X 240
A common practice in game development is to start building on a base
device, usually using a screen resolution of 176px x 208px. Once the content
is completely ready, (after the testing phase and bug fixes are completed),
the game content is sent to the porting team to port it for multiple devices.
The process of porting in J2ME is different from the porting for Flash Lite. In
J2ME games, developers often hard code every value. The values for moving
a sprite, for placing a sprite on a canvas, for setting up a tiled background and
for setting up fonts on the canvas during run-time are usually all hard coded.
That means that in order to port a J2ME game to a bigger screen size, the
hard coded values must be updated. Also, since the graphics in J2ME games
are bitmaps, the graphics will need to be redesigned at a larger size and
enhanced for a higher resolution screen size (see Figure 5).
Figure 5. Bitmap game graphics ported to a larger screen size must be re-
created to display correctly
As a game developer ports a J2ME game, they must also change the API. In
these situations, the code itself must also be changed.
It is much easier to port a Flash Lite game across multiple devices, because
you have complete control over the UI and the inside game elements. You
can manipulate graphics and fonts during author-time. Additionally, since
the graphics are already vectors, the elements only require resizing and do
not need to be recreated to display on different screen sizes (see Figure 6).
Figure 6. Vector graphics have an advantage because they can be resized to
fit various screen sizes
Flash runs uniformly on all platforms, because it does not depend upon the
platform API. This is definitely a huge time saver because it is not necessary
to change your code unless you have hard coded the game values when
developing.
Similarities in Porting Flash Lite 2.0 and MIDP 2.0
Flash Lite and J2ME are similar in many areas, and it is these similarities that
make the process of porting between the two platforms much easier. Here is a
list of the characteristics both platforms have in common:
Both the technologies are based on the Symbian OS. This means a J2ME game and a Flash Lite game both run on top of the device UI layer. Just as J2ME has external APIs to access the device functionalities, Flash Lite has its FSCommand functions to communicate with the device.
Most Series 60 devices have a screen size of 176 X 208. J2ME and Flash Lite can maintain this screen size for their game during the port. The screen size issues usually occur only if the game that is being ported has a higher resolution in J2ME compared to Flash Lite.
The user interface of every Series 60 device has two soft keys, a five-way rocker, and a numeric keypad. This makes it much easier to map the keys in Flash Lite from J2ME to initiate game actions.
Both J2ME and Flash Lite support menus, although in J2ME, a menu structure can be altered, (which is not true in Flash Lite). Pressing the left-hand softkey, (usually named Options), activates a menu on any S60 device.
Both technologies use the numeric keypad to enter data in text fields and to navigate through applications. On Series 60 devices, one-hand operation is the key rule. The user is able to do almost all tasks with one hand, by pressing the keys with the thumb. Characters are entered with multiple key presses in both cases.
The preferred final compiled file sizes of the game (the .jar and .swf files) of both these technologies should be between 250-300K. A developer can build games that are up to 500K. However, be aware that the game could potentially lose revenue if the end user opts not to wait for the large game to download.
The preferred sound implementation on both these technologies is the MIDI format. Flash Lite developers could also use MP3 and WAV sound formats, but MIDI is the sound format of choice because the goal is to decrease file size whenever possible. If the game's file size allows for extra room for improvement, developers tend to use this as an opportunity to add more graphics or code.
A J2ME file requires JVM (Java Virtual Machine), also known as a KVM (Kilobyte Virtual Machine) for mobile devices. KVM is a platform optimized for small footprint consumer devices, to execute .jar files. A Flash Lite file requires a Flash Lite Player, a desktop Flash Player profile (based on the Flash 7 engine), installed on the phone to play back the .swf files.
Differences in Porting Flash Lite 2.0 and MIDP 2.0
When porting a game from J2ME to Flash Lite, you may also encounter
differences between the two technologies, which can add some complications
to the process. The differences and issues you may encounter are outlined
below.
Vector verses raster
The biggest difference between the two platforms is the format of graphics
supported by both these technologies. While J2ME supports only raster
graphics, Flash Lite supports a combination of vectors and rasters. It is
recommended that developers recreate the graphics for use in the Flash Lite
game before porting. Only raster images from the J2ME version of the game
can be used, and although they can look acceptable, the graphics will look
clearer if they are recreated as vectors.
To illustrate this point, I've included screen shots from two versions of the
same game. The J2ME game uses raster graphics, which are legible but look
faded and blurry (see Figure 7).
Figure 7. A screen shot from a J2ME game
Figure 8. A screen shot from a Flash Lite game
The Flash Lite version is definitely enhanced when compared to the J2ME
version, because the vector graphics look crisp and bright (see Figure 8).
Garbage collection and heap memory
All Series 60 devices come with a default heap memory of 1.5MB for
applications to run smoothly. A Java or Flash developer has to optimize the
code to make it device friendly, while keeping this heap memory in mind.
One characteristic that makes J2ME a programmer-friendly language is the
use of automatic memory allocation and de-allocation. When the
programmer instantiates a variable, the JVM finds and allocates the memory
without the programmer calling a malloc () or new (). Likewise, the JVM de-
allocates that memory when the variable is no longer used, or goes out of
scope. The process of reclaiming memory is called garbage collection.
In J2ME, a developer can try flushing the memory by using the System.gc ()
method, but this will only slow down the application performance.
Ultimately, it is best for a game developer to let the application handle its
own garbage collection.
When developing games using Flash Lite, there currently isn't a method
which a developer can use to guess how much of the heap memory is being
used. Optimizations are done based on experience and assumptions.
However, like Java, Flash also has its own garbage collection. According to
the Flash Lite documentation, the garbage collection in Flash runs
automatically every 60 seconds (or when the memory exceeds 200% of the
current memory usage). That all sounds great, but sometimes a Flash
application will crash anyway—causing the developer to wonder why.
Playback via the Flash Lite Player compared to the JVM
A Series 60 device comes embedded with the JVM, (also known as KVM) for
smaller footprint devices. When a J2ME game is run on a device, it launches
in the JVM and uses its underlying APIs to perform.
Conversely, the Flash Lite Player must be installed on the device to play a
Flash game. Most of the older Nokia Series 60 Second Edition phones don't
support Flash Lite 2.0 (they only support Flash Lite 1.1). The newer Nokia
Series 60 Third Edition phones come with the Flash Lite 1.1 player
preinstalled, however the latest version of Flash Lite still needs to be
installed if it is required.
Comparing vectors on the stage to drawing graphics on the canvas
When developing in J2ME, the game developer has to deal with drawing
sprites or images on a canvas. In the code example below, the screen appears
to clear by drawing a rectangle the size of the screen and setting its color to
white. Then, two more objects are drawn on screen, (a line and a rectangle):
import javax.microedition.lcdui.*;
class DrawingDemoCanvas extends Canvas {
public void paint (Graphics g) {
g.setGrayScale (255);
g.fillRect (0, 0, getWidth (), getHeight ());
g.setGrayScale (0);
g.drawLine (0, 0, 100, 200);
g.fillRect (20, 30, 30, 20);
}
}
Now pretend you are developing the same game in Flash. If you need simple
graphics like those used in the code above, you can use the drawing tools in
Flash to achieve the same effect during authoring. Using Flash Lite 2.0, you
can choose to write code using the Drawing API to achieve this as well.
Personally, I feel it is much faster and easier to use the drawing tools, rather
than add more lines of code to my script. The drawing tools are a definite
advantage to developing games in Flash (see Figure 9).
Figure 9. Simple game graphics can be created using the drawing tools in
Flash Lite 2.0. When developing in J2ME, the same graphics must be
generated programmatically
Working with fonts
When developing with Flash Lite, it is easy to work with fonts because you
have complete control over the design of your content. Text Boxes can be
drawn on the stage using the Text tool, and text properties are controlled
using the Properties Inspector (see Figure 10).
Figure 10. Using Flash Lite, you can control where you place the text and
how the text will be displayed
It is a common misconception that developers should avoid embedding
multiple fonts in a game, in order to keep a small file size. In my experience,
when your content can have a file size of 300K, it is feasible to use several
good pixel fonts for your content.
In contrast to the above, the text in J2ME games must be drawn using the
drawstring () method. This method requires you to define four parameters:
The character string, the x and y coordinates, and an integer determining the
horizontal and vertical alignment of the text.
If you are using a canvas based application you can create the necessary
graphics using your own customized fonts, then save the text as an image file
along with your other graphics images. You could then theoretically use the
customized fonts wherever desired in your game. But it is not quite that
simple. If you use customized graphics for your text, you will need to know
the coordinates of every character of the image file.
In the next example, a customized font image is displayed on the left side.
The right side shows how the characters are displayed on the device (see
Figure 11).
Figure 11. The custom font image appears on the left while the right side
shows how the device displays the text
Here's how this works. The top-left and bottom-right coordinates of every
character from the image are fed into the game program. During run-time the
game program reads the string, picks the character from the image and then
draws it on the canvas. As you can imagine, this is a very tedious process.
These days when I think of using custom fonts, I cannot help but smile and be
thankful that I'm using Flash Lite as a mobile development tool.
Where to go from here
In this article I've covered some techniques and considerations for porting
J2ME games to the Flash Lite platform. In my personal experience, porting
projects always begins by thoroughly reading the Game Design Document.
Once I have a complete understanding of the game logic from the previous
J2ME development team, I start collecting the useful code snippets (such as
conditions, the game AI, etc.), and begin translating the game into
ActionScript (using the Flash syntax).
A Flash Lite developer porting a game from J2ME to Flash Lite has some
advantages that will make their job easier. The first advantage is that the
game assets are already available. Additionally, a Flash Lite developer does
not have to spend too much time working on the game logic or designing
compelling game visuals. When it comes to porting an existing game, the
entire content has already been created. It is a simple matter to reproduce
and test the ported game before distributing it.
Expand your knowledge about S60 development by reading the detailed
information on the
Nokia S60 documentation forum. Also, in-depth articles
and tutorials about using Flash Lite are available at the
Adobe Mobile & Devices Developer Center. I hope this article has sparked your interest in
porting game content. Although porting is easier than developing a brand
new game, you'll find the process will be easiest if you invest time in learning
about the original development, recreate the game graphics as needed, and
define your porting strategies ahead of time—especially if you are porting
across different technologies.
Adobe still working out solution for j2me jar application to be import in flex
3.0. anybody wants to share their ideas regarding flex, They are welcome.
