Thesis PDF

Java ME vs.
Flash Lite:
A Comparison of Mobile Phone Game
Development
Submitted in partial fullment
of the requirements of the degree of
Bachelor of Science (Honours)
of Rhodes University
Alex Koller
Grahamstown, South Africa
November 2007
Abstract
The main goal of this project is to compare mobile game development on the Java Plat-
form Micro Edition (Java ME), and the Adobe Flash Lite platform. This has been done
by investigating which APIs are available on each platform, and how well suited they
are to game development. Developing an arcade-style game in Java ME and Flash Lite
concurrently allows us to gather a complete understanding of the mobile game develop-
ment using both platforms. Both versions of the completed game are almost identical,
which allows us to directly compare the runtime of both the Java ME and Flash Lite
environments.
Acknowledgements
I would like to thank my supervisors, Prof. Greg Foster and Mrs. Madelein Wright, for
their invaluable assistance throughout the duration of my research. Your advice, patience
and positive attitudes have been a tremendous help in keeping me motivated and inspired
throughout the year. Thank you for allowing me to work at my own pace and trusting
that I would complete my work. I am forever grateful for your help.
I would like to thank to Department of Computer Science for providing me with an
outstanding working environment in which to complete my research.
Finally I would like to thank my family and friends for the support they have shown
through all my years of study. I would not be where I am today without their guidance,
support and humour.
I acknowledge the nancial and technical support of this project of Telkom SA, Business
Connexion, Comverse SA, Verso Technologies, Stortech, Tellabs, Amatole, Mars Tech-
nologies, Bright Ideas Projects 39 and THRIP through the Telkom Centre of Excellence
at Rhodes University.
Contents
1 Introduction 8
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Research Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Document Structure and Outline . . . . . . . . . . . . . . . . . . . . . . . 9
2 Related Work 11
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Mobile Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Mobile Platforms and Application Environments . . . . . . . . . . . 12
2.2.2 Market Shares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.3 Game Development on Mobile Devices . . . . . . . . . . . . . . . . 13
2.3 Mobile Gaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Mobile Gamer Prole . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2 Successful Mobile Game Genres . . . . . . . . . . . . . . . . . . . . 16
2.3.3 The Future of Mobile Game Development . . . . . . . . . . . . . . 17
2.4 Java ME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1
CONTENTS 2
2.4.1 Java ME APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.2 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.3 Future of Java ME . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5 Adobe Flash Lite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5.1 Flash Lite APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5.2 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.3 Future of Flash Lite . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6 Comparison Matrices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6.1 Comparing Development . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6.2 Comparing the Final Product . . . . . . . . . . . . . . . . . . . . . 25
2.7 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3 Game Requirements and Design 29
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Game Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.1 The Game Story and User Interfaces . . . . . . . . . . . . . . . . . 30
3.2.2 Control Response and Frame Rate . . . . . . . . . . . . . . . . . . 30
3.2.3 Graphics and Sound . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.4 High Scores and Statistics . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 Game Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.1 Tile-Based Game Engine . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.2 Sprites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
CONTENTS 3
4 Game Development with Java ME and Flash Lite 37
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 Software Installation and Development Environment Conguration . . . . 38
4.2.1 Available Software Packages . . . . . . . . . . . . . . . . . . . . . . 38
4.2.2 Requirements, Installation and Conguration . . . . . . . . . . . . 39
4.2.3 Compilation and Emulation . . . . . . . . . . . . . . . . . . . . . . 40
4.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.1 Dierences between Developing in Java ME and Flash Lite . . . . . 40
4.3.2 Background Story and Characters . . . . . . . . . . . . . . . . . . . 41
4.3.3 User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.4 Graphics and Sound . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.5 Persistent Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4 Implementation of the Game Engine . . . . . . . . . . . . . . . . . . . . . 44
4.4.1 Tile-Based . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.2 Sprites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4.3 Handling User Input . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4.4 Collision Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.5 Overall Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.6 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.7 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
CONTENTS 4
5 Benchmarking Java ME Against Flash Lite 54
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.2 Comparison Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.2.1 Development Time . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2.2 Number of Lines of Code . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2.3 Final File Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2.4 Memory Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2.5 Frame Rate and General Performance . . . . . . . . . . . . . . . . . 56
5.3 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.4 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6 Conclusion 61
6.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.2 Assessment of Research Aims . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.3 Future of Mobile Game Development . . . . . . . . . . . . . . . . . . . . . 64
Bibliography 65
A Black Sky Background Story 68
B Comparison of Java ME and Flash Lite Code 69
List of Figures
2.1 Java ME Architecture [12] . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Over-The-Air Deployment [16] . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Flash Lite 2.0 Architecture [5] . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1 The title image creates part of the splash screen . . . . . . . . . . . . . . . 31
3.2 The tile-set that from which the landscape is generated . . . . . . . . . . . 31
3.3 Top-down perspective. A) Player controllable ship, B) Enemy ship, C)
Shield power-up, D) Explosion, E) Display bar showing health, score, etc. . 33
3.4 Tile-set consisting of 4 sections . . . . . . . . . . . . . . . . . . . . . . . . 34
3.5 Example grid of tiles from the tile-set . . . . . . . . . . . . . . . . . . . . . 34
3.6 Ship sprite constructed from multiple frames illustrating increasing levels
of damage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1 Options menu created in Java ME using the Form class . . . . . . . . . . . 42
4.2 Class diagram for the Java ME implementation of Black Sky . . . . . . . . 49
4.3 The Java ME and Flash Lite implementations of Black Sky emulated side-
by-side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.1 Java ME memory usage during game execution . . . . . . . . . . . . . . . 57
5.2 Flash Lite memory usage during game execution . . . . . . . . . . . . . . . 57
5.3 Java ME method prole showing CPU cycle usage . . . . . . . . . . . . . . 59
5
List of Tables
2.1 Worldwide Smart Phone Market [8] . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Worldwide Smart Phone OS Market [27] . . . . . . . . . . . . . . . . . . . 15
2.3 Penetration Rate per Game Type [26] . . . . . . . . . . . . . . . . . . . . . 16
2.4 Comparison of Development Tools. Adapted from [24] . . . . . . . . . . . . 26
4.1 Comparison of Development Environments . . . . . . . . . . . . . . . . . . 39
6
List of Code Listings
1 Main game loop performing actions depending on the current game state . 45
7
Chapter 1
Introduction
1.1 Background
Recent years have seen the rise of mobile users with PDAs, laptops and particularly mobile
phones. Worldwide there are over 2 billion mobile phone users [21] roughly one third
of the worlds population. In South Africa alone there are 30 million mobile phone users
[21] out of a population of 47 million. The pervasiveness of mobile devices has created a
substantial market for mobile applications and games that continues to grow extremely
rapidly.
With so many mobile devices, it is crucial for a developer to target the right mobile plat-
form and development environment, or a combination thereof. Portability across plat-
forms will ensure the maximum target audience is reached. This is specically important
for mobile game development.
The mobile game industry has rmly asserted itself as a signicant industry with major
development houses such as EA Mobile driving it forward. As such, it is possible to make
some observations about the mobile game industry. Primarily, we analysed which games
have succeeded and which have failed, and determine why this is so. In addition to the
nature of the game, user input and hardware limitations also aect the success of a mobile
game.
A concise investigation of two of the main environments for mobile game development is
conducted. The two environments under discussion are Java ME and Flash Lite. The
APIs and features of these two development environments are explored in detail. Methods
of deploying applications, as well as the future of Java ME and Flash Lite are discussed.
8
1.2. PROBLEM STATEMENT 9
1.2 Problem Statement
The problem which we are addressing in this project is to determine which mobile devel-
opment platform Java ME or Flash Lite is better suited to mobile game development
in the current mobile game industry. This research is required because Flash Lite is an
emerging technology that may be able to dethrone Java ME as the leader in mobile game
development. Side-by-side development of the same game on both platforms makes it
possible to accurately compare the development phase, and the nal applications yield
many opportunities to compare Java ME and Flash Lite as mobile runtime environments.
1.3 Research Goals
Our goal was to investigate the current mobile game market to learn which types of games
have been successful, and what made those games successful. With these success factors,
we aimed to develop a game similar to the most successful mobile games in the industry.
With a complete game developed in both Java ME and Flash Lite, we were able to realise
our goal of directly comparing both the development phase and the nal product of mobile
game development on these two platforms.
1.4 Document Structure and Outline
This dissertation begins, in chapter 2, with an investigation into the current mobile devices
and platforms, such as Symbian and Java ME. We compare the market penetration of
these platforms, and take a closer look at mobile game development on these platforms.
Next, mobile development is discussed by analysing who plays mobile games, which games
are most successful and why, followed by a brief look into the future of mobile game
development.
Java ME and Flash Lite are investigated, examining the APIs available to each platform,
as well as the deployment methods and future of the two platforms. Means of compar-
ing the development phase and nal products created in Java ME and Flash Lite are
considered towards the end of chapter 2.
In chapter 3 we discuss the requirements of an arcade-style game, which was found to be
the most successful mobile game genre. Arcade-style games are also well suited for testing
1.4. DOCUMENT STRUCTURE AND OUTLINE 10
both platforms. Requirements in the eld of, among others, user interfaces, frame rates,
graphics and sound. The design of an arcade-style game is explored, particularly the use
of a tile-based game engine and the use of sprites to represent objects in the game world.
Chapter 4 forms the majority of this paper. This chapter compares the development of our
test game Black Sky from the selection and installation of development environments
and the emulators of each environment, through the implementation phase of the general
game, and specically, the game engine. The implementation phase was compared in
terms of user interfaces, graphics sound, and persistent storage. The implementation of
the game engine explored how Java ME and Flash Lite are able to create a tile-based game
engine that uses sprites to represent various objects in the game, as well as handling user
input (button presses) and collision detection methods. It is discussed how each of the
two platforms implemented the overall structure of the game, followed by a comparison
of the documentation for Java ME and Flash Lite.
Java ME and Flash Lite are benchmarked against each other in chapter 5. This is accom-
plished by measuring and comparing a number of important features of the two platforms
for arcade-style mobile game development. These include comparing the development
time and number of lines of code, nal le size, memory usage and game performance.
A short comparison of how Java ME and Flash Lite handle deployment concludes the
chapter.
Chapter 2
Related Work
2.1 Introduction
The quick rise of mobile phone users in the last few years to over a third of the worlds
population has created a substantial market for mobile applications, and the mobile games
industry makes up a signicant portion of that market [21, 7].
The large range of mobile devices means it is crucial for a developer to target the right
mobile platform and use the most appropriate development environment. These options
are explored and evaluated. An exploration into the growth of the mobile game industry
is conducted, looking specically at which games have been successful, and why.
A brief, yet concise, discussion of Java ME and Flash Lite is conducted, detailing the APIs
and features of these two development environments. Methods of deploying applications,
as well as the future of Java ME and Flash Lite are discussed.
Finally, means of comparing quantitatively and qualitatively the development of mobile
games on Flash Lite and Java ME is discussed. This section looks at both the development
phase, and the nal game product of each environment.
2.2 Mobile Environments
With over 2 billion mobile phone users worldwide [21], there is a plethora of dierent
mobile devices available, which operate on dierent platforms and have support for various
11
2.2. MOBILE ENVIRONMENTS 12
application environments. There is signicant variety among mobile devices both in terms
of hardware capabilities and software support.
According to Canalys [8], 64 million smart phones were shipped worldwide in 2006 a
30% increase from 2005. This suggests the smart phone, or high-end device, market is
growing rapidly and as a result the availability of high-end devices is increasing
2.2.1 Mobile Platforms and Application Environments
On high-end devices, such as smart phones, there are various platforms or operating
systems.
Common Smart Phone Platforms
Symbian OS has been shipped to over 80 million smart phones so far and has an overall
67% smart phone OS market share [27]. Morales and Nelson [20] state applications for
this platform can be developed in C/C++ to be run natively on the phone.
Microsoft Windows Mobile is an operating system developed by Microsoft, which oer
tight integration with Microsoft products such as Microsoft Oce and Windows Media
Player. However, Windows Mobile has a low market penetration, according to Canalys
[8].
Palm OS is developed by Palm for smart phones and PDAs. Like Windows Mobile, it is
licensed to several other manufacturers, according to Crooks [9].
Applications can be developed natively for these platforms. However, to achieve greater
portability, many applications are developed for a specic environment, which runs on top
of the mobile devices native platform. Morales and Nelson [20] support this and suggest
that portability is of great concern to mobile game developers in order to reach a larger
target audience.
Available Environments
Java Platform, Micro Edition (Java ME), previously known as J2ME, was developed by
Sun Microsystems. It is a subset of the Java platform aimed at mobile devices. Java
ME is covered at length in section 4. Flash Lite was originally developed by Macromedia
as a lightweight version of their Flash Player for mobile devices. Adobe acquisitioned
Macromedia in 2005, and now continue to develop Flash Lite. Flash Lite is covered
extensively in section 5 of this paper.
In 2005 Nokia released PyS60, which is a Python interpreter for Symbian S60 devices.
PyS60 includes many of the modules from regular Python implementations, as well as
additional modules for interacting with the Symbian operating system. Python is often
used in conjunction with other environments, such as Flash Lite or Java Me, to achieve a
greater level of interaction with the underlying operating system.
.NET Compact Framework is a compact version of the Microsoft .NET Framework that
is designed to run on mobile devices. The .NET Compact Framework includes some
of the class libraries from the full framework. Applications can be created in Microsoft
Visual Studio, and written in C# or Visual Basic .NET. These applications are run on a
mobile-device specic just-in-time compiler.
2.2.2 Market Shares
As table 1 shows, Nokia holds the largest share in the smart mobile device market with
over 11.1 million shipments in Q4 of 2006. Sony Ericsson has the largest growth at 946.2%.
Both Nokia and Sony Ericsson are shareholders of Symbian, ltd. [25].
Table 2 shows the distribution of operating systems among smart phones. Symbian has
almost 70% market share with 12.7 million smart phones being shipped with Symbian
OS. According to Symbian [25], cumulative sales of smart phones will pass 1 billion units
by 2011, and that by 2010 Symbian will still be leading the market with a 65% share.
2.2.3 Game Development on Mobile Devices
Symbian OS is by far the most pervasive platform for smart phones (table 2). However,
this excludes low-end mobile phones. Crooks [9] suggests that, unlike desktop game
developers, mobile game developers should not concentrate on a single platform or device,
but rather target several in order to maximise their potential marketplace. In order to
reach the largest possible audience, most mobile games have been developed for Java ME
as it has the highest market penetration among mobile devices, according to Morales and
Nelson [20], and Java ME can run on most platforms, including Symbian OS.
V
e
n
d
o
r
Q
4
2
0
0
6
s
h
i
p
m
e
n
t
s
%
s
h
a
r
e
Q
4
2
0
0
5
s
h
i
p
m
e
n
t
s
%
s
h
a
r
e
G
r
o
w
t
h
Q
4
0
6
/
Q
4
0
5
N
o
k
i
a
1
1
,
1
1
4
,
6
3
0
5
0
.
2
%
9
,
2
6
8
,
4
1
0
5
4
.
3
%
1
9
.
9
%
R
I
M
1
,
8
2
9
,
2
6
0
8
.
3
%
1
,
1
8
5
,
3
4
0
8
.
0
%
5
4
.
3
%
M
o
t
o
r
o
l
a
1
,
4
6
3
,
0
9
0
6
.
6
%
7
7
7
,
5
8
0
4
.
6
%
8
8
.
2
%
P
a
l
m
1
,
2
1
1
,
9
3
0
5
.
5
%
1
,
5
6
3
,
6
8
0
9
.
2
%
-
2
2
.
5
%
S
o
n
y
E
r
i
c
s
s
o
n
1
,
1
3
7
,
3
6
0
5
.
1
%
1
0
8
,
7
1
0
0
.
6
%
9
4
6
.
2
%
O
t
h
e
r
s
5
,
3
6
8
,
1
3
0
2
4
.
3
%
4
,
1
5
0
,
2
1
0
2
4
.
3
%
2
9
.
3
%
T
o
t
a
l
2
2
,
1
2
4
,
4
0
0
1
0
0
.
0
%
1
7
,
0
5
3
,
9
3
0
1
0
0
.
0
%
2
9
.
7
%
T
a
b
l
e
2
.
1
:
W
o
r
l
d
w
i
d
e
S
m
a
r
t
P
h
o
n
e
M
a
r
k
e
t
[
8
]
2.3. MOBILE GAMING 15
OS vendor Q2 2005 % share Q2 2006 % share Growth Q2 05/Q2 06
Symbian 7,648,920 75.19% 12,720,920 69.70% 66.31%
Linux 1,448,320 14.24% 3,541,870 19.41% 144.55%
PalmSource 496,310 4.88% 562,960 3.08% 13.43%
Microsoft 355,650 3.50% 898,440 4.92% 152.62%
RIM 134,540 1.32% 475,860 2.61% 253.69%
Others 89,490 0.88% 51,360 0.28% -42.61%
Total 10,173,230 100.00% 18,251,410 100.00% 79.41%
Table 2.2: Worldwide Smart Phone OS Market [27]
Rhodes [23] claims Flash Lite oers the ability to create games that are cross-platform
compatible. Flash Lite 2.1 players are available for Symbian OS, BREW 2.x/3.x and
Microsoft Windows Mobile 5 [4]. However, Suomela [24] has encountered problems where
Flash Lite applications behave very dierently on dierent devices.
Mobile games are developed in C/C++ for Symbian OS. These games are not as portable
however, and thus there is not as large a market for them. By far the most prominent
environments for mobile gaming are Java ME, and now potentially Flash Lite.
2.3 Mobile Gaming
Mobile gaming started with Snake in 1997 on the monochrome display of a Nokia 6110
[14]. Since then, improvements in hardware and game development have altered the user
experience dramatically. An understanding of who currently plays and purchases mobile
games is vital when designing and developing mobile games.
2.3.1 Mobile Gamer Prole
According to de Boer et al. [10], mobile gamers can be divided into two groups; hardcore
gamers and casual gamers, stating that on mobile devices, casual gamers make up the
vast majority of the total gamers. Graft [14] agrees with this distinction, but notes that
there is a dedicated mobile game fan base within the estimated 2 billion cell phone users
worldwide. A survey conducted by the Interactive Digital Software Association [7] states
that 87% of the people asked said the played games for fun, and 74% said they wanted to
be challenged.
2.3. MOBILE GAMING 16
Game Type Penetration Rate
1. Puzzle/Strategy 61%
2. Retro/Arcade 45%
3. Action/Adventure 42%
4. Card/Casino 39%
5. Trivia/Word 32%
6. Sports/Racing 30%
Table 2.3: Penetration Rate per Game Type [26]
Jacobs [15] writes on casual gaming: I think mobile games have come of age, Bruce
Gibson, Research Director at Juniper Research, said. The casual games sector is go-
ing to be the market driver, even though it may not be at the leading edge of mobile
games technology. Casual games make most use of the inherent advantages of the mobile
platform...
2.3.2 Successful Mobile Game Genres
This categorising of mobile gamers is useful in determining what types of games are
successful on mobile devices.
Games can be divided into genres, and certain genres are better suited to mobile devices
than others. De Boer et al. [10] categorise games into various genres and describe their
suitability for mobile devices, specically with Flash Lite in mind.
De Boer et al. [10] found that strategy and logic games, such as Minesweeper, work well
on mobile devices, as well as role-playing, sport strategy and management games. Games
that fall into the rst-person shooter genre, were found to be almost impossible to create
in Flash Lite [10]. Action games and 2D racing games were said to be technically possible
with Flash Lite, but the processing power required to achieve the desired speed was the
limiting factor in these types of games.
Telephia [26] published the following table, showing the penetration rate of various game
types among mobile game players in the U.K. These penetration rates of the various
game genres support what De Boer et al. stated in terms of strategy and logic games
being successful. However, arcade style games have been more successful, while sports
and racing games have been less successful.
Telephia also found that the mobile games that generated the most revenue in 2006 were
Tetris, PacMan, Ms. PacMan, and Bejeweled. Morales and Nelson [20] point out that
2.4. JAVA ME 17
these games existed prior to being ported to mobile devices, and as such you could assume
the mechanics of the game had proven themselves already. Morales and Nelson [20] also
point out that people who like playing these games enjoy the mechanics of the game
regardless of the platform the game was being played on. These games all have simple
user interfaces and controls, which are easily performed on cell phones.
2.3.3 The Future of Mobile Game Development
The future of mobile gaming denitely looks bright. According to Gartner [13] the world-
wide mobile gaming revenue will grow from $2.9 billion in 2006 to $9.6 billion in 2011,
and is on target to reach $4.3 billion in 2007, a 49.9 percent increase from 2006. Gartner
accredit this increase mainly to the pervasiveness of mobile phones in many markets and
the ease of game play on mobile phones.
All sources are in agreement that the future of mobile gaming is spectacularly bright, and
will continue to grow. However, the mobile game development community is divided on
whether devices will become more powerful, and as Graft [14] suggests, be able to play
more complex and demanding 3D games with hardware acceleration, or, as Crooks [9]
suggests, whether other limiting factors, such as user input, will see games that rely on
captivating game play and user interfaces suitable for cell phones. Morales and Nelson
[20] write that most successful mobile games in recent years have been 2D games with
simple user controls, but are condent that 3D games will become the predominant type
of game on mobile platforms.
2.4 Java ME
Java Platform, Micro Edition (Java ME) was developed by Sun Microsystems and is a
collection of technologies and specications that are designed for dierent parts of the
small device market. [18]. It is essentially a subset of Java APIs for development of
applications on mobile devices with limited resources, such as cell phones.
Java ME has a particularly high market penetration; according to Morales and Nelson
[20], approximately 68% of mobile phones are Java ME-capable, which equates to more
than 350 million Java ME-capable mobile devices worldwide. Until now Java ME has
been considered the de facto for mobile application development due to this high market
penetration and relative maturity of the platform.
2.4. JAVA ME 18
Figure 2.1: Java ME Architecture [12]
Java ME was designed to use proles and congurations to enable devices of varying
ability to be able to run Java ME applications on the Kilobyte Virtual Machine (KVM),
which is the micro version of the Java Virtual Machine (JVM).
There are currently two congurations available: Connected Limited Device Conguration
(CLDC) and Connected Device Conguration (CDC). Figure 1 illustrates how the CDC
and the CLDC together make Java ME. The diagram also shows the Java ME architecture,
and how it ts in the overall Java model.
The CLDC targets devices with very limited resources, such as cell phones, while the
CDC is designed to target devices with slightly more resources, such as set-top boxes. The
minimum requirements for the CLDC 1.1 are a 16 bit CPU, 160 KB memory available to
the virtual machine, and a limited network connection.
The most common prole is the Mobile Information Device Prole (MIDP), which is
aimed at mobile devises such as cell phones. Currently MIDP 1.0 and MIDP 2.0 are
available, while MIDP 3.0 is being developed. Java ME applications developed for an
MID Prole are called MIDlets.
2.4. JAVA ME 19
2.4.1 Java ME APIs
MIDP 1.0 oers the following APIs:
javax.microedition.io
Contains Java ME-specic classes used for I/O.
javax.mocroedition.lcdui
Contains Java ME-specic classes used for the GUI.
javax.microedition.rms
Provides a form of persistent storage for Java ME.
javax.microedition.midlet
Contains the base classes for Java ME applications.
MIDP 2.0 adds to following APIs:
javax.microedition.media
Contains classes used for multimedia playback.
javax.microedition.lcdui.game
A gaming API aimed at 2D sprite based game development. This API adds support
for sprites, layers, and a tiled game canvas. These classes are used in most types of
games.
javax.microedition.pki
Contains classes for authentication for secure connections.
javax.microedition.messaging
Wireless messaging API for sending SMS and MMS messages.
javax.microedition.pim
Personal information management API for accessing the address book.
javax.microedition.io.le
Provides access to the local le system.
Optional packages, such as Java APIs for Bluetooth, Mobile 3D Graphic, and JBDC
can be added to MIDlets to oer greater functionality at the cost of being more device-
specic. The ability to utilise these optional packages is where the maturity of Java ME
is noticeable, with many APIs designed specically for game development.
2.4. JAVA ME 20
Figure 2.2: Over-The-Air Deployment [16]
2.4.2 Deployment
A MIDlet is typically deployed as a single Java Archive (JAR) le containing all the
class les and resources. A JAR le is used to contain compiled Java classes, associated
meta-data and resources pertaining to a certain application. Within the JAR le is
the Manifest le which contains the meta-data for the application. A Java Application
Descriptor (JAD) le usually accompanies the JAR le. The contents of the JAD le is
essentially the same as the Manifest le. The JAD le allows the user to view the details
of a MIDlet without having to download the whole le.
The Over-The-Air distribution model allows MIDlets to be served from existing web
servers, which can be accessed directly from cell phones though the devices built in web
browser, if it has one, as shown in gure 2.
2.4.3 Future of Java ME
According to Java Specication Request 271 [22], MIDP 3.0 plans to build upon the
success of MIDP 2.0 by enhancing certain aspects of the prole and adding new features.
Some of these enhancements include:
2.5. ADOBE FLASH LITE 21
Better support for devices with larger displays.
Enable MIDlets to draw to secondary display(s).
Enable richer and higher performance games.
IPv6.
Multiple network interfaces per device.
Enable shared libraries for MIDlets.
Enable background MIDlets (e.g. UI-less).
Enable auto-launched MIDlets (e.g. started at platform boot time).
Enable inter-MIDlet communications.
With these enhancements and continued interest and support for Java ME, it is likely
that Java ME will continue to be one of the main mobile game environments.
2.5 Adobe Flash Lite
Flash Lite is a lightweight version of Flash Player specically developed for mobile de-
vices. Flash has been an extremely successful technology for online games, which can be
embedded in HTML web pages.
Flash Lite was originally developed by Macromedia before it was acquisitioned by Adobe
in 2005. At that time Flash Lite had been available in Japan and Europe [29] as either
Flash Lite 1.0 or Flash Lite 1.1. Later in 2005 Flash Lite 2.0 was released. Flash Lite 2.1
has been released, and version 3.0 is currently being developed.
2.5.1 Flash Lite APIs
Flash Lite 1.1 is based on a hybrid of Flash 4 and Flash 5, and supports Flash 4 Action-
Script, which is a pre-ActionScript 1.0 version [3]. Flash Lite 2.1 is based on Flash 7 and
has support for ActionScript 2.0. The main features of Flash Lite 2.1 are: [4]
ActionScript Extensions
Allow access to device specic features, such as battery level and signal strength. It
also oers the ability to send SMS messages and dial numbers.
Network Access and Connectivity This allows resources to be loaded via HTTP(S)
requests, and email to be sent. It is also possible to load SWFs from web servers,
allowing seamless updating of Flash Lite content.
Additional Audio Support
Support for MP3, PCM, and ADPCM audio. Hardware support for these formats
is utilised when available.
Scalable Rendering Engine
The core rendering engine of Flash Lite is well suited for rich interactive content as
it supports vectors, gradients, bitmaps, user input, audio, and scripting.
Static, Dynamic Text and User Input
Flash Lite supports static and dynamic text elds. Dynamic text can be updated
during runtime. User input is also supported during runtime.
Navigation and Key Events
Within an interactive movie, navigation can be achieved with the Up, Down, and
Select buttons. The keys 0 to 9, * and # are also supported.
Fonts and Text
Flash Lite has support for both embedded fonts and device fonts. Embedded fonts
allow for more control over the content, but increase the size of the nal SWF le.
Multi-Platform Support
Flash Lite 2.1 oers support across various platforms, including: Symbian S60
v2/v3, Qualcomm BREW 2.x/3.x and Microsoft Windows Mobile 5.
Dynamic XML Data
Support for loading and parsing of external XML data.
Persistent Data
Oers the ability to store and retrieve relevant, application-specic information
locally. This provides a more robust development environment. User preferences,
high scores, etc. can be stored.
Shape Drawing ActionScript API
Enables developers to easily create sophisticated vector graphics and animated
shapes, at runtime, using ActionScript 2.0.
Compressed SWFs
Flash Lite 2.0 supports the rendering of SWFs that have been compressed by the
Flash authoring tool. Flash Lite decompresses the SWF before it starts processing
it.
Unlike Java ME, none of these APIs are designed specically for game development.
Notable APIs that are missing include support for camera operation, Bluetooth commu-
nication, and 3D graphics.
Figure 3 shows the architecture of Flash Lite 2.1, and how the dierent components
communicate with each other, as well as with the underlying operating system.
2.5.2 Deployment
Flash Lite applications are deployed as single SWF les. As of Flash Lite 2.0, compressed
SWF les may be used. The SWF le can be transferred to the mobile device using Over-
The-Air, Bluetooth, or any other means of transferring data to the device. The SWF
le is then launched from the Flash Lite player on the device. This is dierent to Java
deployment in so much that Java ME applications consist of a JAD le which describes
the application, and contains the location of the application JAR le. While this oers
the ability for users to screen Java ME applications easily without downloading them, it
is more complex than the single SWF le for Flash Lite applications.
2.5.3 Future of Flash Lite
According to Adobe [2], Flash Lite 3.0 is currently under development and is expected to
be available in the rst half of 2007. Adobe announced that support for video will be
integrated into the next generation of Flash Lite.
Nokia Forum [11], refers to Flash Lite as an emerging as a global phenomenon, enabling
developers to deliver rich multimedia content to Nokia devices with less eort. The ease-
of-use, short development time, and high return on investment are key factors that set it
F
i
g
u
r
e
2
.
3
:
F
l
a
s
h
L
i
t
e
2
.
0
A
r
c
h
i
t
e
c
t
u
r
e
[
5
]
2.6. COMPARISON MATRICES 25
apart from other development platforms, specically Java ME. According to Adobe [6],
there are over 1 million Flash Lite developers, and the community is growing rapidly.
This indicates a large scale and quick uptake of Flash Lite as a development platform for
mobile devices.
2.6 Comparison Matrices
Quantitative and qualitative comparisons must be made between both the development
phase, and the nal product on both platforms.
2.6.1 Comparing Development
During the development phase comparisons should concentrate on the development en-
vironments, emulators, and development time. While comparing various runtimes on
Symbian S60 devices, Suomela [24] compared the tools available and the development
time for each runtime. Development time is dependent on many factors such as the de-
velopers experience developing on the given platform. However, the tools available, and
the development work-ow used eect the development time. Suomela found, as a gen-
eral rule of thumb, development is quicker on Flash Lite than Java ME, especially for
non-programmers. Table 4 shows Suomelas comparison of available development tools.
A closer comparison of the development environments can be done, contrasting the devel-
opment work-ows used, documentation available, and integration with other tools such
as compilers and emulators.
2.6.2 Comparing the Final Product
Comparing the performance of the nal products can be done in a range of ways. Depend-
ing on the type of game, the frame rate may be an important factor [17]. To benchmark
the performance of each platform, an application that solves the same problem using the
same general algorithm should be developed for each platform, according to Marne [17].
Using these two applications, it is possible to test the performance in a number of ways,
including:
2.6. COMPARISON MATRICES 26
J
a
v
a
M
E
F
l
a
s
h
L
i
t
e
D
e
v
e
l
o
p
e
r
p
l
a
t
f
o
r
m
s
W
i
n
d
o
w
s
W
i
n
d
o
w
s
,
M
a
c
T
o
o
l
c
o
s
t
F
r
e
e
$
7
0
0
(
f
r
e
e
3
0
-
d
a
y
t
r
i
a
l
)
G
e
t
t
i
n
g
s
t
a
r
t
e
d
J
D
K
,
I
D
E
(
E
c
l
i
p
s
e
+
C
a
r
b
i
d
e
.
j
o
r
N
e
t
B
e
a
n
s
)
,
p
l
a
t
f
o
r
m
S
D
K
A
d
o
b
e
F
l
a
s
h
C
S
3
P
r
o
f
e
s
s
i
o
n
a
l
D
e
b
u
g
g
i
n
g
a
n
d
t
e
s
t
i
n
g
S
D
K
/
E
m
u
l
a
t
o
r
s
,
O
n
-
D
e
v
i
c
e
-
D
e
b
u
g
g
i
n
g
F
l
a
s
h
/
C
S
3
D
e
v
i
c
e
C
e
n
t
r
a
l
E
m
u
l
a
t
o
r
O
p
t
i
m
i
s
a
t
i
o
n
s
,
e
t
c
.
O
b
f
u
s
c
a
t
i
o
n
D
e
c
o
m
p
i
l
e
r
s
T
a
b
l
e
2
.
4
:
C
o
m
p
a
r
i
s
o
n
o
f
D
e
v
e
l
o
p
m
e
n
t
T
o
o
l
s
.
A
d
a
p
t
e
d
f
r
o
m
[
2
4
]
2.7. CHAPTER SUMMARY 27
Lines of code
The total number of lines will be indicative of the amount of coding eort that was
required to develop the project.
Speed
Measured in frames per second. For applications that require fast rendering, such as
3D games, this will give a good indication of how well the platform draw frames. A
low frame rate makes games jerky, or even unplayable. A high frame rate creates
a smooth game play experience for the user.
Controls
Which controls are available to the user will determine how easy it is to navigate or
control a game. This will have signicant aects on the overall game play experience.
The control set can be limited by the platform, such as Flash Lite only allowing two
soft buttons to be used, or by the device itself.
Ease of use
If a game is dicult to use, understand, play, or navigate, this immediately has a
negative eect on the users experience. Ease of use also applies to the development
environment and process.
These tests should be conducted on the same mobile device, and under as similar as
possible conditions. This will result in the most useful quantitative comparison data.
Comparisons of the controls and ease of use will result in qualitative comparison data,
which can have major ramications on the overall experience oered to the user by the
game.
2.7 Chapter Summary
In this chapter, we discussed mobile environments the platforms and application envi-
ronments and how, for mobile game development, portability is the key to reaching the
largest possible market. Java ME and Flash Lite are both well suited to mobile game
development as they are both portable, and both environments are supported on many
platforms, specically Symbian OS.
It was found that certain game genres have achieved more success than others in mobile
gaming. This can be attributed mainly to the limited resources available on mobile
devices, as well limited user input through the small keys on mobile phones. Games that
have achieved success have been easily controllable and relatively slow in nature, e.g.
puzzle and strategy games.
The specics of both Java ME and Flash Lite were discussed. Details of the APIs avail-
able in each development environment were listed. Methods of deploying applications, and
future developments of both environments were also considered. The game development-
specic optional packages available to Java ME demonstrate the maturity of the platform,
as well as the large community support base for Java ME game development, while Flash
Lite only has APIs for general and media application development, with no APIs speci-
cally for game development.
Methods for comparing mobile game development on Java ME and Flash Lite were in-
vestigated. Means of comparing the development phase and the nal products both
quantitatively and qualitatively were determined. This will enable us to give a mean-
ingful comparison of mobile game development on Java ME and Flash Lite.
Chapter 3
Game Requirements and Design
3.1 Introduction
In order to adequately compare the implementation phase of game development on Java
ME and Flash Lite, the creation of a game was necessary. The game created was required
to satisfactorily explore the limits of each platform.
In the previous chapter we discussed the suitability of various game genres and types for
mobile phones due to limited user input. It was thus decided a fast-paced, arcade-style
game was most appropriate. Another factor to take into account was the lack of resources,
such as processing power and a reduced screen size, found on mobile devices. We decided
on a tile-based approach for the game engine, with sprites representing various characters
and objects as this is a common methodology in mobile games.
In addition to this, we could not forget the basics of game development, including the
creation of detailed graphics, stimulating sounds, and a captivating background story and
characters to immerse the player in a virtual world of excitement and intrigue.
3.2 Game Requirements
Many features typical to arcade games are excellent criteria for comparing the Java ME
and Flash Light platforms. Arcade-style games have many common traits: In an envi-
ronment consisting of enchanting sounds and enthralling graphics, the player controls the
29
3.2. GAME REQUIREMENTS 30
protagonist of the games background story aimed at captivating the players attention.
Fast paced action and responsive controls are central to arcade-style games. We drew
on these features of the game created to compare the use of Java ME and Flash Lite for
mobile game development.
3.2.1 The Game Story and User Interfaces
All games, regardless of genre, must have a story that captivates the player. A common
approach game designers employ is to create a hero character, which is controlled by
the player. Through the hero character, the player makes progress through the game by
achieving goals, destroying enemies, solving puzzles, or by means of time-based progres-
sion. The game story is thus presented to the player mainly though the hero character
that they control, and usually other characters. This method of telling the game story
through characters holds the players interest and gives the player a reason to return to
the game, which increases the possibility of a successful game.
Most arcade games revolve around a single hero character, often pitted against multiple
enemies. A typical example of this is Pac-Man. The player controls the Pac-Man char-
acter. The objective of the game is to collect objects representing points, while trying to
evade numerous enemy characters.
Our game takes a similar approach. The player controls the hero ship. The objective
is to achieve as high as score as possible through multiple time-based levels. Each level
contains multiple enemies and power-ups. Points are awarded for power-ups, destroying
enemies and completing levels.
The player will interpret this story through text screens, dialogue boxes, statistic screens
and menus. This oers us the chance to test how well Java ME and Flash Lite are able
to implement graphical user interfaces, render fonts and convey a story through various
on-screen displays.
3.2.2 Control Response and Frame Rate
For any quick-paced game responsive controls are vital for making the player feel immersed
in the game, and thus creating an enjoyable game experience. Slow or unresponsive con-
trols cause the player to grow frustrated, and can ruin an otherwise good game experience.
3.2. GAME REQUIREMENTS 31
Consequently it is imperative that both Java ME and Flash Lite are capable of quickly
and accurately capturing user input and causing the desired eect promptly.
Another aspect that can aect perceived responsiveness is a slow frame rate. The frame
rate is a measure of how many frames are rendered each second. If the frame rate drops
too low, the game becomes jittery, resulting in a poor game experience. As both variants
of the game are tested on the same mobile phone, the processing power available to Java
ME and Flash Lite is the same. Thus the frame rate is an excellent means of testing each
platforms ability to harness the power of the underlying processor.
3.2.3 Graphics and Sound
A common technique adopted by game developers is to create a splash screen, depicted
in gure 3.1, which is an image depicting the atmosphere of the game, usually containing
the game title. This screen is shown when the game is initially started, and is frequently
used as a means of stimulating the player while loading the game.
Figure 3.1: The title image creates part of the splash screen
Graphics were required for the characters of the game (hero and enemies), as well as
all the scenery (gure 3.2), power-ups and eects. This gave us the chance to test how
eectively each platform renders images, as well as which formats are supported by Java
ME and Flash Lite respectively.
Figure 3.2: The tile-set that from which the landscape is generated
3.3. GAME DESIGN 32
Background music and sound eects both enhance the overall game experience, which is
critical for a successful game. However, limited memory requires the audio component of
mobile games to be relatively small. This is usually achieved by using heavily compressed
formats as well as MIDI music. We have witnessed that attempting to play audio is a
common cause for many crashes in mobile applications [personal observation]. As such,
the sound engine was a key area of comparison between Java ME and Flash Lite.
3.2.4 High Scores and Statistics
When the game is over a statistics screen is shown, which shows statistical information
concerning the players game, including the players score. If the player has achieved a
new high score, the player may enter their name in the High Score Hall of Fame.
The high scores are stored locally on the phone, which gave us the chance to compare
Java ME and Flash Lites ability to handle persistent storage. The high score feature
allowed us to test the platforms aptitude for text input and displaying a variety of fonts.
3.3 Game Design
We created an arcade-style game titled Black Sky, with a background story and charac-
ters described in appendix A. The basic game structure of Black Sky resembles that of a
tile-based, top-down shooter. A top-down shooter is a game genre in which the player is
viewed from above (gure 3.3).
3.3. GAME DESIGN 33
Figure 3.3: Top-down perspective. A) Player controllable ship, B) Enemy ship, C) Shield
power-up, D) Explosion, E) Display bar showing health, score, etc.
This is a common perspective for games, thus it is intuitive to most gamers and lends
itself to rst-rate controllability with limited input. Games with a top-down perspective
can be realised with ease using a tile-based game engine.
3.3.1 Tile-Based Game Engine
A tile-based game is a type of game where the playing area consists of a grid of small
graphic images (usually in the shape of a square or rectangle). These images are referred
to as tiles. The complete set of tiles available for use in a playing area is called a tile-set.
From the given tile-set in gure 3.4, it is possible to create a much larger composite image
as shown in gure 3.5.
3.3. GAME DESIGN 34
Figure 3.4: Tile-set consisting of 4 sections
Figure 3.5: Example grid of tiles from the tile-set
Figure 3.6: Ship sprite constructed from multiple frames illustrating increasing levels of
damage
The concept of tile-based games has been around for many years, and was used extensively
in the days when computer resources were scarce as on mobile phones. Large playable
areas or maps can be created easily using a small tile-set. In Black Sky, with a tile-set of
only 4 tiles, simple maps can be created easily in the form of two dimensional arrays.
Each tile can have multiple properties set, which control the way the player interacts with
that tile. For example, if a tiles walkable property is set to false, the ship will not be
able to y over that tile, and will incur damage.
This ability to create large, interactive maps easily, coupled with the ability to change the
tile-set completely, makes this game engine extremely extensible. A completely dierent
looking environment can be constructed without diculty from a new tile-set and a simple
array.
3.3.2 Sprites
A sprite is a two-dimensional graphic that is integrated into a larger scene. This graphic
usually represents an item or object in the game world, such as an enemy ship, power-
up or explosion. Sprites can be manipulated and transformed (ipped, rotated, scaled,
translated, etc.) to achieve desired eects in the game with little computation required.
The use of bitmap images instead of scalable vector graphics results in faster rendering
[23]. A sprite can be constructed from multiple frames. This method of creating sprites
is illustrated in gure 3.6.
3.4 Chapter Summary
After deciding that an arcade-style, top-down shooter game would be suitable for com-
paring mobile game development on Java ME and Flash Lite, we decided what the core
features of arcade games were, and how they could be used to compare the capability of
Java ME and Flash Lite as game development platforms for mobile phones. With a solid
goal in mind, we began designing the general gaming aspects of Black Sky; the background
story and user interfaces, graphics and sounds, which permitted us to compare various
aspects of the platforms in question. This also included deciding how the user would
interact with the game. An intuitive control of movement and ring was implemented
which enabled us to gauge the responsiveness of each platform to button presses.
We then required a suitable game engine that would perform well taking into account the
limited resources available on mobile phones. For reasons of simplicity, proven reliability
in the technology, and extensibility, a tile-based game engine was implemented, which uses
sprites to display characters and objects in the game world. This frequently implemented
game engine allowed us to scale the game in order to compare the performance of Java
ME and Flash Lite under various conditions.
Chapter 4
Game Development with Java ME and
Flash Lite
4.1 Introduction
In this chapter we look at the signicant tasks involved in mobile game development, and
how Java ME and Flash Lite can complete those tasks in a way most appropriate for
mobile game development.
The rst concern examined is the selection, installation and conguration of the devel-
opment environments that enabled us to get the most out of both platforms, followed by
a short description of how each platform handles compilation and emulation. We began
the discussion of the implementation phase by comparing the general programming dif-
ferences between Java ME and Flash Lite. This was followed by a detailed description
of how, through the available APIs on both platforms, we implemented frequently used
parts of mobile games, such as user interfaces, graphics, sound, and persistent storage.
The tile-based game engine created for Black Sky was adequate for an arcade-style game,
and also tested many APIs of both platforms through the utilisation of sprites, how button
presses and other user input is handled, and perhaps most signicantly for game devel-
opment, how eectively Java ME and Flash Lite implement collision detection between
objects in the game.
The overall structure of Black Sky was explored, detailing how each of the platforms
implements this structure using dierent combinations of object oriented, procedural and
37
4.2. SOFTWARE INSTALLATION AND DEVELOPMENT ENVIRONMENT
CONFIGURATION 38
time-line based programming. This is followed by a discussion of the documentation
available for Java ME and Flash Lite.
4.2 Software Installation and Development Environment
Conguration
The development environment used in any project can help or hinder the success of that
project. Thus the selection of the development environment that contained the necessary
tools for mobile game development and allowed for the most productivity.
In order to begin developing Flash Lite content, Flash CS3 Professional and Adobe Device
Central CS3 were required. This is the only option for authoring Flash Lite content. Both
are components of Adobe Creative Suite. Device proles keep Flash CS3 aligned with
current mobile devices. These device proles are updated occasionally and are available
for download.
On the other hand there exists a wide selection of propriety, open source and free authoring
software, tools and IDEs available to assist in the creation of Java ME content.
4.2.1 Available Software Packages
As Flash CS3 Professional is the only authoring software available for Flash Lite develop-
ment, it must be purchased from Adobe. As of October 25, 2007 Flash CS3 Professional
retails for US $699.
The Sun Java Wireless Toolkit for CLDC is a toolkit available from Sun Microsystems
as a free downloadable product. The toolkit includes build tools, various utilities, and a
device emulator for creating Java ME applications that run on mobile devices compliant
with the CLDC. The toolkit can be used as a standalone development environment, or in
conjunction with an IDE.
For Java ME development, the following IDEs were considered: Eclipse, NetBeans with
NetBeans Mobility Pack 5.5 and IntelliJ IDEA. After experimenting with all three IDEs
functionality, we decided to use the Java Wireless Toolkit, in combination with a simple
text editor, as a standalone development environment. The central reasons for abandoning
4.2. SOFTWARE INSTALLATION AND DEVELOPMENT ENVIRONMENT
CONFIGURATION 39
Development Environment Start-Up Time Standard Deviation Memory Usage (MB)
NetBeans 25.6 20.92 121
Eclipse 13.2 4.97 67
IntelliJ IDEA 24.6 12.54 140
Java Wireless Toolkit 3.4 2.07 33
Flash CS3 Professional 20.4 15.47 89
Table 4.1: Comparison of Development Environments
the IDEs in favour of the wireless toolkit were tediously slow start-up times and excessive
memory usage. Table 4.1 shows the mean and standard deviation of start-up times taken
over ve attempts for each development environment to initialise and become operational,
as well as the amount of memory allocated immediately after start-up. The initial start-up
time for NetBeans was frequently over a minute, with IntelliJ IDEA nearly as slow.
The Java Wireless Toolkit oers all the required functionality for creating new projects,
conguring MIDlets, compiling, testing and emulating Java ME applications under vary-
ing conditions, as well as utilities for method proling, obfuscation, memory and network
monitoring, and a multitude of other useful utilities for MIDlet testing, emulation and
distribution.
4.2.2 Requirements, Installation and Conguration
Flash CS3 Professional is available for Windows and Macintosh based systems, while the
Sun Java Wireless Toolkit is available for Windows and Linux based systems.
On a Windows based system Flash CS3 Professional requires a Pentium 4 or higher,
Microsoft Windows XP with Service Pack 2 or Windows Vista, 512MB of RAM (1GB
recommended), and 2.5GB of available hard-disk space (additional free space required
during installation). Installation is simple, but somewhat slow. A working Internet con-
nection is required for activation.
In comparison, The Sun Java Wireless Toolkit only requires an 800 MHz Pentium III CPU,
100 MB hard-disk space, and 128 MB of RAM. Installation is quick and simple. Java
2 Platform, Standard Edition (Java SE SDK), version 1.5.0 is required for development,
and Java 2, Standard Edition Runtime Environment (JRE), version 1.5.0 is required to
run the applications.
4.3. IMPLEMENTATION 40
4.2.3 Compilation and Emulation
Java ME and Flash Lite both compile applications programmed in Java and ActionScript
2 respectfully, to a format to be read by an interpreter on mobile phones. The Java ME
compiler creates a .jar le with a .jad le containing meta-data description the application,
while the Flash Lite compiler creates a .swf le. These les need to be transferred to a
mobile phone. After installing the Java ME application, the two programmes can be run
on the mobile phone.
An emulator imitates a mobile phone on a desktop PC. Emulators are used to avoid the
lengthy overhead mentioned above, and to test an application on many dierent devices.
The Sun Wireless Toolkit contains an emulator capable of imitating various generic mobile
devices. Adobe Device Central CS3 can emulate over 220 mobile devices with memory,
network and performance monitoring. Updates are available for Device Central CS3
online.
4.3 Implementation
Due to Java ME being a well established mobile game development environment, we
decided to rst implement our test game, Black Sky, in Java ME. Once complete, we
ported Black Sky to Flash Lite and attempted to replicate the Java ME implementation
as directly as possible. This was done to create a game that was as similar as possible on
each platform, allowing us to compare Java ME and Flash Lite as directly as possible.
4.3.1 Dierences between Developing in Java ME and Flash Lite
Java ME applications are coded in Java, which is an object oriented programming lan-
guage. Extensive use was made of the concept of inheritance, which is realised in Java
ME through a hierarchical structure of classes. Custom classes can extend pre-existing
classes and inherit their methods and attributes.
In contrast, Flash Lite development is based on a time-line, which consists of multiple
frames contained within multiple layers. The programming language behind Flash Lite is
ActionScript 2.0, which while capable of object orientated programming, in the context
of a time-line the realisation of an object orientated system is not as natural as the
hierarchical class structure used by Java ME.
Flash CS3 Professional allows the developer to drag and drop components onto a visual
representation of the application, while the Sun Wireless Toolkit requires everything to
be done programmatically.
4.3.2 Background Story and Characters
The rst stage of implementation involved developing a background story and characters
for the game. A simple futuristic setting was decided upon, and is detailed in appendix
A. Four main characters were then created two alternative aircrafts to control during
game play, and two dierent enemies. The same background story and characters were
used in both implementations of the game.
4.3.3 User Interfaces
When the game is started, a splash screen with the game title and atmospheric artwork
is displayed. This technique is used to focus the players attention on the game, and to
load data in the background. The splash screen is removed after a set time, and when
all the data has been loaded. Thereafter the user is presented with a menu for changing
various options and selecting one of the two available ships to begin the game with.
In Java ME a splash screen is easily implemented using the Canvas class. We were able
to simply paint images, shapes and text directly onto the full screen canvas. Java MEs
Command and CommandListener classes allowed us to create a simple but eective, device
independent menu. The ability for users to change settings and options is frequently used
in games of all types. Figure 4.2 illustrates the result of using a Form class to create an
options menu.
The graphical user interface created with Java ME is device independent as commands
are grouped suitably and assigned to appropriate buttons for each device that implements
the MIDP being used.
This is one of the areas where Flash Lite outperformed Java ME. The time-line based
structure of Flash Lite development lends itself to developing user interfaces where the
ability to switch between dierent screens is desired. Each screen can be represented as
a single frame on the time-line, and the gotoAndStop() function can be used to switch
between them.
Figure 4.1: Options menu created in Java ME using the Form class
All graphical components such as buttons and input text boxes had to be added and
congured manually. This allowed more control over the look and feel of the user interface,
but also required more work and eort.
Flash CS3 Professional allows for the uncomplicated creation of complex and unique
menus. While Java ME is capable of achieving similar results, it would require signicantly
more work. Java ME is designed for creating simple, functional menus.
4.3.4 Graphics and Sound
A signicant importance is placed on graphics in games. Although this applies more to
desktop PC and console games, it holds true for mobile games as well. Small, detailed
bitmap images are used extensively in mobile games because bitmap images can be ren-
dered extremely quickly [23]. As such, it is vital for Java ME and Flash Lite to support
the necessary image types.
For all images we decided to use Portable Network Graphics (PNG) as it is a bitmapped
image format that uses lossless compression. As mentioned in chapter 2, Java ME supports
PNG, and Flash Lite supports PNG while authoring and converts it to another bitmap
le format. Neither platform had any trouble displaying images.
Sound eects and music play a critical role in setting the mood of the game experience.
Unless compressed, audio les are too large to be stored on mobile devices with little
memory. For this reason we compressed the sound eects using a low bit rate MP3
format, and used MIDI les for the music. MIDI is an eective format for game music as
it does not transmit an audio signal or media, but simply transmits digital data "event
messages" such as the pitch and intensity of musical notes [28].
In Java ME all sounds are played by creating a Player object, loading the required sound
and playing it through the appropriate methods of the Player class. This was a simple
process, and worked as expected on the device as well as the emulator. Java ME experi-
enced no problems playing the MIDI background music when multiple sound eects were
playing concurrently.
Flash Lite lists MP3 and MIDI as supported. Although the process of creating a new
sound object and playing it is simple enough in ActionScript 2, the results were less than
desirable. We were unable to get Flash Lite to play two sounds simultaneously, which
meant each time a new sound needed to be played and the current sound (including
background music) would stop. Flash Lite is also not capable of looping sounds, which is
required for the game music.
Even though Flash Lite supports MIDI, the development environment Flash CS Profes-
sional does not natively support MIDI, meaning MIDI les cannot be imported into the
library. There is a workaround using the Flash Lite Bundler, but this requires completing
a laborious 10 step guide as detailed at the Adobe Developer Center [1].
As expected, Java ME and Flash Lite are both capable of displaying the necessary image
formats. Sound support is excellent in Java ME, but Flash Lite does not oer particularly
good sound APIs with no support for looping or multiple-sound simultaneous playback.
This resulted in a Flash Lite version with a less engrossing game experience than the Java
ME version.
4.3.5 Persistent Storage
To facilitate the storage of high score sand game options, a means of persistent storage
was required. Persistent storage refers to the storage of data which continues to exist after
the execution of the application that created it, and can be retrieved by the application
on a subsequent execution.
Java ME contains a RecordStore API specically designed for persistently storing data
such as high scores. A best eort is made to ensure integrity of the data throughout
4.4. IMPLEMENTATION OF THE GAME ENGINE 44
the normal use of the platform, including reboots, battery changes, etc. [19]. The
RecordStore API is easy to use and works eectively.
Persistent storage in Flash Lite is handled by the SharedObject class. Once a SharedObject
object has been instantiated, its data members can be accessed in a manner similar to
local variables.
Java ME and Flash Lite can both store data persistently, making it possible to store
settings and high scores a frequently used task in many games.
4.4 Implementation of the Game Engine
The game engine is responsible for all the vital components of the game. This includes
updating and rendering the display, detecting and validating user input via key presses,
and updating the game state. This is done continuously in a loop while the game is in
the correct state (listing 4.1).
The GameCanvas class in the Java ME game API provides game-specic capabilities such
as an o-screen graphics buer, and the ability to query the status of key presses. The
GameCanvas class was used extensively in the development of Black Sky, and is an in-
valuable resource for mobile game development. Flash Lite did not oer an APIs aimed
specically at game development, nor did it contain any classes with the functionality
required for a tile-based game engine.
4.4.1 Tile-Based
Java MEs game API contains a TiledLayer class specically designed for developing
tile-based games. In essence, it works by dividing the layer (which may be larger than
the viewable area) into a two-dimensional grid of cells. These cells can then be assigned
a tile, preventing the need for one large image. The LayerManager class manages various
layers. The illusion of the players ship moving forward in space is created by moving the
LayerManagers view window.
Flash 8 introduced the BitmapData object, which is similar to Java MEs TiledLayer
object. Regrettably Flash Lite is based on Flash 7, and consequently does not oer
Listing 1 Main game loop performing actions depending on the current game state
while ( ! gameOver ) { // main game l oop
i f ( gameState == 1) {
// Game i s runni ng
veri f yGameState ( ) ; // v e r i f y game s t a t e
checkUserInput ( ) ; // check user s i nput
updateGameScreen ( getGraphi cs ( ) ) ; // updat e screen
sl eepTi me = 30; // s l e e p f or 30 mi l i s econds
i f (DEBUG > 0)
cal cul ateFPS ( ) ; // c a l c u l a t e FPS
} el se i f ( gameState == 0) {
// Game i s paused
di s pl ayPaus e ( getGraphi cs ( ) ) ;
sl eepTi me = 500;
} el se i f ( gameState == 2 | | gameState == 3) {
// Game over or l e v e l passed , l e av e game l oop
break ;
} el se i f ( gameState == 1) {
// Pregame s t a t e
updateGameScreen ( getGraphi cs ( ) ) ; // updat e screen
gameState = 1; // s t a r t game
sl eepTi me = 300; // i n 0. 3 seconds
}
try {
Thread . currentThread ( ) . s l e e p ( sl eepTi me ) ;
} catch( Excepti on e ) {
debugMessage ( " Error s l e e pi ng i n main l oop : " + e , 1 ) ;
}
}
this feature. As tile-based games are so common and popular on mobile phones, it was
imperative that we had a scrolling, tile-based game engine operational on both platforms.
We created a game engine by using a tile symbol with each of its frames representing
one tile in the tile set. As with Java ME, we used a two-dimensional array of integers to
represent the tiles from the tile set in a specic sequence in order to create the desired
game world. If all the tiles for a particular level were loaded at once it would be too slow
and use too much memory, so we had to dynamically load and unload tiles according to
their visibility on the screen. To create the illusion of forward motion in Flash Lite, we
shifted the background tiles downwards.
In Java ME the implementation of a scrollable, tile-based game engine was the instan-
tiation of a few well-designed classes from the game API. This resulted in an extensible
game engine that performed well. Flash Lite on the other hand did not oer any support
for developing a game engine. Every aspect of the game engine had to be designed and
implemented from the ground up. The result of this was a tile-based game engine that
catered for the specic requirements of our game, but did not perform as well as the
optimized game-specic Java ME classes.
4.4.2 Sprites
Most two-dimensional, arcade-style games depict the objects and character within the
game as sprites. A sprite is a graphical representation of an object or character. In our
game we had sprites that represented: the players ship, two enemies, and four power-ups.
Java ME contains a Sprite class, which can be managed with the LayerManager in a
similar fashion to the TiledLayer representing the landscape. These Sprites can be
single-framed or animated as described in the previous chapter. The Sprite class can
also apply various transformations to themselves, such as rotating and mirroring. Sprites
were created in Flash Lite as symbols. We attached them to a blank movie clip, and then
attached those to other movie clips that resembled dierent layers. Flash Lites movie
clips can be scaled, rotated, and a variety of other transformations.
Although it was possible to create, versatile sprites as movie clips in Flash Lite, the ability
to precisely transform and animate sprites makes the Java ME Sprite class a desirable
tool for mobile game developers.
4.4.3 Handling User Input
The user interacts with the game by pressing buttons on the mobile phone to achieve
the desired response, such as moving the ship or ring the primary weapon. In an action
arcade-style game responsive controls are necessary in achieving a sense of uid game
play.
The GameCanvas class in the Java ME game API has a method that gets the states of
the physical game keys. With this method it is possible to detect if the key is currently
down or has been pressed at least once since the last time this method was called. This
has been designed using a latching behaviour, which ensures that a rapid key press and
release will always be caught by the game loop, regardless of how slowly the loop runs
[19].
Flash Lite makes use of a key listener object. This listener object is added as a listener
to the Key object, and can then detect when a key is pressed. Although this method
appeared to be slightly less immediate than detecting key presses in Java ME, the key
listener object was capable of detecting key presses and key releases, making it adequate
for mobile game development.
Java MEs game buttons are device independent, and are mapped to the most appropri-
ate device buttons for playing games. This is a big advantage over Flash Lite, which is
only capable of mapping events to specic buttons, eectively rendering Flash Lites key
detection as device dependent.
4.4.4 Collision Detection
Collision detection is the act of detecting when two sprites have collided, and is imple-
mented in almost all games with moving objects. The accuracy and required processing
time of the collision detection method are both vital. The accuracy determines how real-
istic the collision detection is, playing a role in the overall game play experience. Collision
detection is tested on every frame, thus the processing time required is of great signicance
and must be kept to an absolute minimum.
The Java ME Sprite class has a collidesWith() method that can take a Layer, TiledLayer,
Image, or another Sprite as parameters. This method also takes a parameter to enable
pixel-level detection, which takes transparency into account when detecting collisions.
4.5. OVERALL STRUCTURE 48
The collision detection in Java ME proved to be extremely accurate, reliable and quick
as will be discussed in the next chapter.
Flash Lite movie clips (which we eectively used as sprites) contain a method call hitTest()
which takes another movie clip, hit area or x and y coordinates as a parameter. Although
it would have been possible to create a hit area shape for each object in the game to
achieve pixel-level collision detection, this would have required extensively more work
and an increase in nal le size. Instead we opted to implement collision detection using
the default bounding rectangles of each object. This resulted in a less accurate collision
detection algorithm.
4.5 Overall Structure
Java is an object oriented programming language, and when creating Black Sky in Java
ME we took full advantage of this. However, developing for mobile devices with minimal
resources required a relaxation of object oriented programming principles, such as public
attributes that can be accessed directly from other classes. Figure 4.9 illustrates the
overall class structure of Black Sky.
In essence the game consists of a main class, BlackSky, which is responsible for creating
and displaying the various menus and screens, initialising and launching the game, as well
as controlling the overall operation of the application.
The Game class runs on a separate thread to the main application, and is the main game
engine and is responsible for all in-game proceedings such as collision detection and con-
tains the main game loop discussed above. The Game class uses two monitor classes to
control the enemies and power-ups, in addition to the Ship class, which represents the
players ship. The Game class also utilises the Clock class, which is a simple timer.
The EnemyMonitor and PowerUpMonitor classes control the enemies and power-ups, re-
spectfully. This involves creating, movement, collision detection and the destruction of
enemies and power-ups. Both of these classes run on their own threads, making Black
Sky a multi-threaded game.
Flash Lite, through ActionScript 2, is capable of object oriented programming, but due
to being time-line based it does not lend itself to a completely object oriented design.
Instead, we decided on a hybrid implementation involving aspects of sequential, object
oriented and time-line based programming.
4.5. OVERALL STRUCTURE 49
Figure 4.2: Class diagram for the Java ME implementation of Black Sky
4.6. DOCUMENTATION 50
Simple ActionScript classes were created for the enemy object and the power-up object,
while the menus and screens were implemented using frames in the time-line. The main
game loop and game logic were implemented in a single frame in a procedural manner.
Although we implemented the Java ME and Flash Lite versions of Black Sky using dier-
ent programming techniques, the resulting games were almost identical in operation and
appearance, which proved that both platforms are capable of high quality mobile game
development. Figure 4.13 illustrates this point by presenting Black Sky executed on a
Java ME emulator and a Flash Lite emulator.
4.6 Documentation
Clear, concise documentation can assist a developer in achieving his goals, and is a vital
element of any development environment.
Java ME has Javadoc generated HTML documentation available online as is the case with
all Java documentation. The layout is well structured and navigation is straightforward,
with eective search functionality. The information contained within the documentation
is concise and oers several examples. We used the Java ME documentation extensively
during the development of Black Sky.
Flash CS3 Professional contains a help system which includes documentation for Flash
Lite. This documentation contains many examples and tutorials for creating simple ap-
plications. The documentation also includes all APIs available in Flash Lite. We found
the help system to be a valuable tool while developing in Flash CS3 Professional.
4.7 Chapter Summary
The choice of development environment for use with Java ME was a simple decision.
The Sun Wireless Toolkit was quicker and used less memory than Eclipse, NetBeans
5.5 and IntelliJ IDEA. The Wireless Toolkit also oered many useful utilities such as
memory usage monitoring and method proling, as well as a capable emulator. Flash
CS3 Professional was the only development environment available for Flash Lite. Flash
CS3 is well suited to the type of development done with Flash Lite graphically intense,
Figure 4.3: The Java ME and Flash Lite implementations of Black Sky emulated side-by-
side
time-based programming, and Device Central CS3 can emulate over 220 mobile devices
with memory, network and performance monitoring.
There was a noticeable dierence in developing Java ME content and Flash Lite content
as Java is object oriented, while Flash is time-line based. Flash Lite was more adept
than Java ME when creating menus and user interfaces, although Java ME could create
functional menus quickly and with little eort. Both platforms were able to display all
the necessary image formats for the graphics of the game. Flash Lite showed a severe lack
of functionality when unable to play more than one sound simultaneously. An arduous
workaround was required to play MIDI les, while Java ME had no trouble playing mul-
tiple sounds and MIDI music simultaneously. Neither platform struggled with persistent
storage, although Java MEs RecordStore class is designed to maintain the integrity of
the data at all times.
The tile-based game engine was implemented with the use of the TiledLayer Java ME
class. This class was designed for creating tile-based games and oers all the APIs needed
to create a tile-based game engine. Flash Lite APIs did not oer much assistance for
developing a tile-based game engine, but we used movie clips as tiles, and dynamically
loaded and unloaded the tiles as required to reduce memory consumption. Movie clips
were used again for sprites, which represent objects and items in the game. Java ME once
again had a class designed specically for this purpose.
Both platforms are capable of handling button presses and other user input. Java MEs
GameCanvas class has been optimised to detect button presses irrespective of how briey-
/frequently they were pressed, while Flash Lite implements a key listener object that
detects button presses.
Collision detection is an important aspect of game development and is handled well by
Java ME. Each Sprite can test with pixel-level accuracy if it has collided with another
Sprite or Layer. Flash Lites hitTest() method tests if two movie clips have collided.
By default this method uses a bounding rectangle around the movie clip. It would have
been possible to create accurate hit areas for each object, but this would have required
too much time.
The documentation was found to be helpful and extensive for both Java ME and Flash
Lite.
The overall structure of Black Sky was very similar in Java ME and Flash Lite, but
was implemented in dierent ways. The Java ME version was largely object oriented,
while Flash Lite blended a combination of object oriented, procedural and time-line based
programming techniques to produce an almost identical version of Black Sky. The multi-
threaded nature of the Java ME implementation was a major advantage over the Flash
Lite version.
These near-identical versions of Black Sky developed in Java ME and Flash Lite made
it possible to directly test and compare numerous aspects of these two platforms. In the
next chapter comparisons are made between development time, frame rate, and memory
usage, in addition to other indicators of a successful arcade-style mobile game.
Chapter 5
Benchmarking Java ME Against Flash
Lite
5.1 Introduction
Having created two identical versions of our test game, Black Sky a Java ME version,
and a Flash Lite version it was possible to directly compare the performance of each
platform through multiple criteria. The results accumulated in this chapter give us a basis
for deciding whether, at this point in time, Java ME or Flash Lite is a better platform for
mobile game development. Deployment of the nal product is another important topic
considered in this chapter.
5.2 Comparison Tests
Many tests varying in nature could have been conducted, but it was vital to perform
tests between the two versions that would compare Java ME and Flash Lites prociency
for mobile game development. To accomplish this, it was necessary to determine the
requirements of an arcade-style mobile game. Among the most important requirements
that can be compared relatively easily are: a short development time, nal le size,
memory usage, and a high frame rate.
54
5.2. COMPARISON TESTS 55
5.2.1 Development Time
Unlike PC and console games, mobile games generally do not have a large budget. Instead
mobile games are usually developed by small teams with a small budget, and are completed
in a short time. This allows for a quick return on investment for the investors.
We spent approximately three weeks developing the Java ME version, and another three
weeks developing the Flash Lite version. Following the initial development stages, a
further week was spent xing bugs and making the two versions as similar as possible.
All development in Java ME was done programmatically, while a fair amount of what
you see is what you get (WYSIWYG) development was done on the Flash Lite imple-
mentation. Most of the graphical interfaces created were simple and it was quicker to
create them programmatically in Java ME than it was to create and congure them in
Flash Lite.
This, along with the Flash CS3 Professional crashing frequently, caused the development
of the Flash Lite version to fall slightly behind that of the Java ME version. In the time
permitted, slightly more was achieved using Java ME than Flash Lite
5.2.2 Number of Lines of Code
The number of lines of code created during the creation of a project is usually indicative
of the development time and eort put in. However, due to the slightly dierent nature
of the two platforms this may not be accurate.
The Java ME implementation consisted of approximately 3000 lines of code split over
11 class les. The Flash Lite implementation consisted of only 1000 lines of code. This
may appear like a drastic dierence at rst, but if the time-line nature and WYSIWYG
development mode of Flash are considered, one realises total eort put in is not represented
by the number of lines of code as it is with the Java ME implementation.
5.2.3 Final File Size
The size of the nal le intended for distribution is critical. Mobile games are usually
sent over-the-air or downloaded from the Internet. In order to accommodate this, the le
size should be as small as possible, generally less than 200kb. Some mobile phones have
a very limited amount of memory and cannot store large les.
The obfuscated Java ME version of Black Sky, with all images, sounds and other resources,
was 81.5 KB. The Flash Lite version, with all resources except the MIDI music (12.5 KB),
was 59.3 KB.
Taking into consideration the missing MIDI les, the dierence between the two ver-
sions was 9.7 KB. Both Java ME and Flash Lite performed well when compressing and
packaging all the resources along with the games.
5.2.4 Memory Usage
Another resource in scarce supply on mobile phones is memory. The operating memory
size for both Java ME and Flash Lite is 2048 KB.
Figure 5.14 shows the memory usage of the Java ME version of Black Sky for the du-
ration of two one minute levels. The initial (and largest) peak of 516 KB was from the
initialisation of the MIDlet. The peak-valley eect noticeable on this graph was caused by
the garbage collector being called at regular intervals to force the reallocation of memory,
which kept the maximum memory usage at a minimum. The average memory usage was
approximately 180 KB.
The memory usage of the Flash Lite implementation is detailed in Figure 5.15. The rst
step in the graph was caused by the initialisation of the splash screen and menus. The
second step was from the initialisation of the game engine. At this stage the memory
usage was approximately 1000 KB. The memory usage gradually increased until reaching
a ceiling of 1032 KB.
The Java ME implementation used signicantly less memory than the Flash Lite imple-
mentation. The peak usage was half of the peak usage of the Flash Lite version, while
the average memory usage by Java ME was over 5 times less than Flash Lite.
5.2.5 Frame Rate and General Performance
Arcade-style games have an element of action, which frequently requires fast-paced game
play. A high frame rate is required for this. The frame rate of a game is the number of
Figure 5.1: Java ME memory usage during game execution
Figure 5.2: Flash Lite memory usage during game execution
5.3. DEPLOYMENT 58
frames rendered by the application every second, and is measured in frames per second
(fps). Mobile devices have minimal processing power compared to desktop PCs, which
makes it more dicult to achieve high frame rates.
We measured the frame rate at regular intervals over the course of 30 seconds of game play.
The Java ME implementation achieved a mean frame rate of 22.92 fps with a standard
deviation of 0.76. The Flash Lite implementation attained a mean frame rate of 19.76
fps with a standard deviation of 1.68. Java ME outperformed Flash Lite by 3.16 fps. At
a frame rate around 20 fps, a change of 3 fps was noticeable, and impacted negatively on
the overall game play experience.
The general performance of Black Sky was smoother in the Java ME implementation.
Figure 5.16 lists the CPU cycles used by each method of this version. From this infor-
mation, we can see that 83.57% of all processing power was used in the main game loop,
while 7.85% for playing sounds and 3.84% was used by the EnemyMonitor class. In the
main game loop almost all execution time was spent updating the graphics.
Similar information for Flash Lite was not available as no method proling software could
be found for Flash Lite.
5.3 Deployment
Deployment is a key factor to the success of a mobile game. If the game does not reach its
intended audience, it cannot be successful. Mobile games can be distributed in a number
of ways, including downloading them from a WAP site, sent in an MMS message, or
transferred via Bluetooth.
To execute Flash Lite content, the .swf le must be downloaded to a mobile phone with
the Flash Lite player installed. Then the application can be executed on that mobile
phone. Java ME content must be downloaded to a mobile phone with the KVM installed,
then the application can be installed and nally executed.
The .jad le associated with a Java ME application is a useful le containing meta-data,
but is not necessary for the execution of the application. One of the valuable attributes
saved in the .jad le is the size of the associated .jar le. This allows the user to view
details of a Java ME application before downloading it.
5.3. DEPLOYMENT 59
Figure 5.3: Java ME method prole showing CPU cycle usage
5.4 Chapter Summary
In this chapter we used our near-identical versions of Black Sky to compare and contrast
the performance of Java ME and Flash Lite. The comparison criteria were selected based
on their impact on mobile games.
Development time was found to be slightly better for Java ME. This was most likely
biased by the content created. Flash Lite was better suited to development of slow-paced,
graphical content. This resulted in the Java ME development ending slightly ahead. Due
to the WYSIWYG nature of the Flash Lite development environment, the number of lines
was determined not to be a reliable measure of development time.
The nal le size of both versions diered by less than 10 KB, and both were well below 100
KB. Java ME and Flash Lite both compressed and packed the game and all its resources
in a concise way. This allowed for easy distribution of Black Sky in both formats.
With the limited amount of memory and processing power available on mobile phones,
minimal memory use and maximum utilisation of the processor are vitally important for
an arcade-style mobile game. The peak memory usage of Flash Lite was twice as much
as that of Java ME, and average memory usage was over 5 times greater. Java ME also
outperformed Flash Lite with a mean frame rate of 22.92 fps, more than 3 fps faster than
Flash Lite.
The last two tests were where Java ME showed its maturity as a mobile game development
platform by performing well where it mattered most on mobile phones speed and memory
utilisation.
We briey discussed the available means of deploying mobile games. Due to the similar
le sizes, it was deemed immaterial how the content was delivered to the mobile phone
as they were both les that could be transferred. However, Java ME had the advantage
of having a .jad le containing meta-data, such as the size of the associated .jar le and
a description of the application.
In most scenarios related to mobile game development, especially arcade-style game de-
velopment, Java ME outperformed Flash Lite.
Chapter 6
Conclusion
At the outset of this paper we decided to create an arcade-style mobile game using both
Java ME and Flash Lite as development platforms. By comparing the development of
this game, and making comparisons of the platforms using the game created, we were
able to achieve our goal of accurately comparing Java ME and Flash Lite for mobile game
development.
6.1 Summary
In the introductory chapter we established the idea of creating a mobile game in Java ME
and Flash Lite in order to compare development in the two platforms. Once completed,
the game served as an excellent way of comparing the runtime environments of Java ME
and Flash Lite.
Chapter 2 began with an investigation into current mobile devices and platforms, such as
Symbian and Java ME, and the market penetration of these platforms. It was found that
certain game genres have achieved more success than others in mobile gaming. Games
that have achieved success have been easily controllable and relatively slow, or arcade-
style games, such as Pac-Man. Details of the APIs available in Java ME and Flash Lite
were investigated. The game development-specic APIs available to Java ME demonstrate
the maturity of the platform, as well as the large community support base for Java ME
game development, while Flash Lite only has APIs for general and media application
development, with no APIs specically for game development.
61
6.1. SUMMARY 62
In Chapter 3 we discussed the requirements of an arcade-style, top-down shooter game,
which was found to be the most successful mobile game genre and capable of testing both
platforms. The core features of such a game were decided upon, which included a tile-
based game engine which utilised sprites, and a requirement for user interfaces, graphics
and sound all common features in arcade-style games.
Chapter 4 constituted the majority of this thesis. The chapter began with a comparison
of various development environments. Flash Lite content can only be authored in Flash
CS3 Professional, a costly and eective propriety development environment. There was
a greater selection of development environments available for Java ME authoring, from
which we selected the Sun Wireless Toolkit due to its quick start-up time, low memory
usage and extensive set of utilities for performance testing and emulating.
The Java ME implementation of Black Sky was written in Java, which is an object oriented
programming language. The Flash Lite version was implemented using a time-line based
methodology interspersed with procedural and object oriented programming techniques.
This introduced a signicant dierence in how the two versions were created. Flash Lite
was more procient than Java ME in creating menus and user interfaces, although with
Java ME it was possible to create functional menus quickly with little eort. Graphic
support was adequate on both platforms, however, Flash Lite showed a severe lack of
sound functionality when unable to play more than one sound simultaneously. This,
coupled with a lack of MIDI support was a major shortcoming. Java ME was capable of
playing several sounds and MIDI music simultaneously. Persistent storage was handled
well by both platforms.
Java ME oered many APIs that simplied to process of creating a tile-based game engine.
With specic classes for bitmap tiling and sprites, there was ample functionality available
from the Java ME game APIs. On the other hand, Flash Lite APIs did not oer much
support for the development of a tile-based game engine. With much eort it was possible
to create a decent game engine using movie clips to represent tiles and sprites. The game
engine was also responsible for collision detection and the handling of user input such as
button presses. Java MEs implementation of collision detection is superior to Flash Lites
due to its ability to perform pixel-level detection that takes transparency into account.
Java ME also handled user input validation slightly better due to the optimised methods
available in the game API. The documentation for both platforms was helpful during
development.
The overall structure of Black Sky was implemented in dierent ways by Java ME and
Flash Lite. Flash Lite used a mixture of object oriented, procedural and time-line based
6.2. ASSESSMENT OF RESEARCH AIMS 63
programming to produce a version of Black Sky that was almost identical to the Java ME
implementation, which was created using primarily using object oriented programming
techniques. The Java ME version made use of Java MEs threading capabilities to create
a multi-threaded game, which was a major advantage over the Flash Lite version.
In Chapter 5 we benchmarked various aspects of the near-identical versions of Black Sky
developed in Java ME and Flash Lite. Development time was slightly shorter for Java
ME. Due to the WYSIWYG nature of the Flash CS3 Professional, the number of lines
could not be used as a reliable measure of development time. The nal le size of both
versions was less than 100 KB and diered by less than 10 KB, which allowed for easy
distribution of Black Sky in both formats.
On mobile devices with limited processing power and memory capacity, it was critical to
achieve minimal memory use and maximum utilisation of the processor. Java ME showed
its maturity as a mobile game development platform by achieving signicantly better
memory utilisation, and a noticeably faster frame rate. During deployment, Java ME had
the advantage of having a .jad le containing meta-data allowing the user to view details
of the application before downloading it
6.2 Assessment of Research Aims
Our original goal was to develop, in Java ME and Flash Lite, an arcade-style game
similar to the most successful mobile games in the industry. Then, with a complete
game developed, we aimed at directly comparing the capabilities of each platform during
development and runtime.
We achieved this goal through the development of Black Sky, an arcade-style game that
utilised a tile-based game engine. After comparing the development phase, we were able
to use the versions of Black Sky created using Java ME and Flash Lite to compare the
runtime environment of both platforms. From the comparative tests run on Java ME and
Flash Lite, we arrived at the conclusion that, currently, Java ME is superior to Flash Lite
for arcade-style mobile game development.
6.3. FUTURE OF MOBILE GAME DEVELOPMENT 64
6.3 Future of Mobile Game Development
The mobile game industry is growing rapidly, which suggests that the future of mobile
game development is extremely bright. Java ME is a solid mobile game development
platform, specically due to the gaming APIs available for it.
Flash Lite 3.0 was recently released, but this release focused more on video and multimedia
support than game development. This version is based on Flash 8, which contains the
BitmapData object, which is extremely useful for game development, but was left out of
Flash Lite 3.0.
With over one million developers currently using Java ME and constant development
being made on the Java ME framework, it is unlikely that Flash Lite will dethrone Java
ME as the leading mobile game development platform in the near future.
Bibliography
[1] Adobe. Using sounds with ash lite 1.1. Online:http://www.adobe.com/devnet/
devices/articles/flashlite_sound_04.html, Accessed: 2007-11-04.
[2] Adobe. Adobe ash lite to support video for mobile handsets. Online:http://www.
adobe.com/aboutadobe/pressroom/pressreleases/200702/021207FlashVideo.
html, Accessed: 2007-11-04, February 2007.
[3] Adobe. Flash lite 1.1 features. Online:http://www.adobe.com/products/
flashlite/productinfo/features/flashlite_1_1.html, Accessed: 2007-11-04,
2007.
[4] Adobe. Flash lite 2.x features. Online:http://www.adobe.com/products/
flashlite/productinfo/features/, Accessed: 2007-05-02, 2007.
[5] Adobe. Flash lite: Architecture diagram. Online:http://www.adobe.com/products/
flashlite/images/fig01_lg.html, Accessed: 2007-11-04, 2007.
[6] Adobe. Online faq. Online:http://www.adobe.com/products/flashlite/
productinfo/faq/, Accessed: 2007-11-04, 2007.
[7] Entertainment Software Association. Essential facts about the computer and video
game industry. Technical report, Entertainment Software Association, 2006.
[8] Canalys. 64 million smart phones shipped worldwide in 2006. Online:http://www.
canalys.com/pr/2007/r2007024.htm, Accessed: 2007-05-02, 2006.
[9] II Clayton E. Crooks. Mobile Device Game Development (GAME DEVELOPMENT
SERIES). Charles River Media, Inc., Rockland, MA, USA, 2004.
[10] Weyert de Boer, Scott Janousek, and Richard Leggett. Foundation Flash Applications
for Mobile Devices (Foundation). friends of ED, December 2006.
65
BIBLIOGRAPHY 66
[11] Nokia Forum. Flash lite for s60 - an emerging global ecosystem. Technical report,
Nokia Forum, May 2006.
[12] Eclipse Foundation. Mobile tools for the java platform. Online:http://www.
eclipse.org/dsdp/mtj/, Accessed: 2007-11-04, 2007.
[13] Gartner. Gartner says worldwide mobile gaming revenue to grow 50 percent in 2007.
Online:http://www.gartner.com/it/page.jsp?id=507467, Accessed: 2007-11-04,
June 2007.
[14] Kris Graft. Analysis: History of cell-phone gaming. Online:http:
//www.businessweek.com/innovate/content/jan2006/id20060122_077129.htm,
Accessed: 2007-11-04, January 2006.
[15] Daniel Jacobs. Causal and female gamers to drive mobile gam-
ing industry. Online:http://www.ibtimes.com/articles/20061005/
mobile-gaming-casual-female.htm, Accessed: 2007-11-04, October 2006.
[16] Qusay H. Mahmoud. Deploying wireless java applications. Online:http://
developers.sun.com/mobility/midp/articles/deploy/, Accessed: 2007-11-04,
October 2002.
[17] Jacob Marne. Evaluating java for game development. Masters thesis, University of
Copenhagen, Denmark, 2002.
[18] Sun Microsystems. Introduction to mobility java technology. Online:http://
developers.sun.com/mobility/getstart/, Accessed: 2007-11-04, 2007.
[19] Sun Mircosystems. Overview (mid prole). Online:http://java.sun.com/javame/
reference/apis/jsr118/, Accessed: 2007-11-04.
[20] Carlos Morales and David Nelson. Mobile 3D Game Development: From Start to
Market. Charles River Media, Inc., Rockland, MA, USA, 2007.
[21] Cellular Online. Latest global, handset, base station, & regional cellular
statistics. Online:http://www.cellular.co.za/stats/stats-main.htm, Accessed:
2007-11-04.
[22] Dr. James E. Van Peursem. Jsr 271: Mobile information device prole 3. Technical
report, Java Community Process, 2007.
[23] Glen Rhodes. Macromedia Flash Professional 8 Game Development. Charles River
Media, Inc., Rockland, MA, USA, 2006.
BIBLIOGRAPHY 67
[24] Hartti Suomela. Runtime environments on s60 platform. Technical report, Forum
Nokia, May 2007.
[25] Symbian. Fast facts. Online:http://www.symbian.com/about/fastfacts/
fastfacts.html, Accessed: 2007-05-02.
[26] Telephia. Puzzle/strategy and retro/arcade mobile games are the most popu-
lar among u.k. 3g subscribers. Online:http://www.telephia.com/html/insights_
071206.html, Accessed: 2007-11-04, July 2006.
[27] C. Wei. Mobile 2.0. Online:http://www.coachwei.com/blog/_archives/2006/11/
4/2474357.html, Accessed: 2007-05-02, November 2006.
[28] Wikipedia. Musical instrument digital interface. Online:http://en.wikipedia.org/
wiki/Midi, Accessed: 2007-11-04.
[29] Wikipedia. Flash lite. Online:http://en.wikipedia.org/wiki/Flash_Lite, Ac-
cessed: 2007-11-04, July 2007.
Appendix A
Black Sky Background Story
The title of the game is Black Sky, and the setting is as follows:
In the near future experiments in black market stem-cell research produce a
hybrid being part phone, part egg. This seemingly harmless combination,
with the eggs ability to hatch another egg and mobile phones tendency to
improve rapidly in technology, soon controlled everything!
Our hero, Ship myShip = new Ship(), is manufactured in the year 30118 in
a post apocalyptic world and is the rst successful reincarnation of free will
since the extinction of mankind many eons prior. With this free will, and an
undesired eect caused by a bug guilt, myShip decided to right the wrongs
of its forefathers, with vengeance!
One class. One class instance. One chance.
68
Appendix B
Comparison of Java ME and Flash Lite
Code
The following code listings are of the Java ME and Flash Lite Enemy class les, respect-
fully:
package BlackSky ;
import j ava . u t i l . Random;
import j avax . mi c r oe di t i on . l c dui . Image ;
import j avax . mi c r oe di t i on . l c dui . Graphi cs ;
import j avax . mi c r oe di t i on . l c dui . game . Spr i t e ;
/
The Enemy c l a s s . 
 
This c l a s s c r e at e s a new Enemy o b j e c t f or t he Bl ack Sky
game. 
Enemies can be of d i f f e r e n t s i z e s , and shown by a
s p e c i f i c
image . They can al s o have a uni que s i z e .
/
public cl ass Enemy extends Spr i t e {
private i nt [ ] speedX ;
private i nt [ ] speedY ;
69
70
private i nt speedIndex = 0;
private i nt type ;
/
Enemy cons t r uct or 
 
Creat es a new Enemy obj ect , wi t h s p e c i f i c v al ue s .
/
public Enemy( Image image , i nt frameWidth , i nt f rameHei ght , i nt
type ) {
super ( image , frameWidth , f rameHei ght ) ;
thi s . type = type ;
i f ( type != 1) {
speedX = new i nt [ ] {2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2};
speedY = new i nt [ ] {1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 1 , 1 , 1 ,
1 , 1 , 1 , 1 , 1 , 1 , 1};
} el se {
speedX = new i nt [ ] {0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 1 , 1 , 2 , 2 ,
1 , 1 , 0 , 0 , 0}; speedY = new i nt
[ ] {2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 1 , 1 , 1 , 1 , 1 , 2 ,
2};
}
}
public void moveAI ( ) {
speedIndex++;
i f ( speedIndex == speedX . l engt h )
speedIndex = 0;
i f ( speedIndex % 10 == 0)
thi s . nextFrame ( ) ;
71
thi s . move( speedX [ speedIndex ] , speedY [ speedIndex ] ) ;
}
public void fi reWeapon ( Graphi cs g ) {
g . s et Col or (0 x0000f f ) ;
g . drawStri ng ( " l i t t l e enemybang" , 130 , 200 , 0) ;
}
}
72
/
Enemy c l a s s
aut hor : Al ex Kol l er
ver s i on : 0. 8
modi f i ed : 08/21/2005
/
cl ass Enemy {
// pr i v at e i ns t ance v a r i a b l e s
private var __type : Number ;
private var __password : St r i ng ;
public var speedX : Array ;
public var speedY : Array ;
// cons t r uc t or st at ement
public f unc t i on Enemy( type : Number) {
thi s . __type = type ;
i f ( __type == 1) {
speedX = new Array ( 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 1 , 1 , 2 , 2 ,
1 , 1 , 0 , 0 , 0) ;
speedY = new Array ( 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 1 , 1 ,
1 , 1 , 1 , 2 , 2) ;
} el se {
speedX = new Array ( 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2)
;
speedY = new Array ( 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 1 , 1 , 1 ,
1 , 1 , 1 , 1 , 1 , 1 , 1) ;
}
}
}

Thesis PDF

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Thesis PDF

Transféré par

Droits d'auteur :

Formats disponibles

Java ME vs.

Vous aimerez peut-être aussi