Java ME Vs. Flash Lite: a Comparison of Mobile Phone Game Development

Java ME vs. Flash Lite: A Comparison of Mobile Phone Game Development

Submitted in partial fulﬁlment 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 development 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 Proﬁle ...... 15

2.3.2 Successful Mobile Game Genres ...... 16

2.3.3 The Future of Mobile Game Development ...... 17

2.4 JavaME...... 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 Conﬁguration . . . . 38

4.2.1 Available Software Packages ...... 38

4.2.2 Requirements, Installation and Conﬁguration ...... 39

4.2.3 Compilation and Emulation ...... 40

4.3 Implementation ...... 40

4.3.1 Diﬀerences 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 proﬁle 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 world’s 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 platform and development environment, or a combination thereof. Portability across platforms will ensure the maximum target audience is reached. This is speciﬁcally important for mobile game development.

The mobile game industry has firmly asserted itself as a significant 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 affect 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 development 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 comparing 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 speciﬁcally, 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 world’s population has created a substantial market for mobile applications, and the mobile games industry makes up a signiﬁcant 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 speciﬁcally 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 diﬀerent mobile devices available, which operate on diﬀerent platforms and have support for various

11 2.2. MOBILE ENVIRONMENTS 12 application environments. There is signiﬁcant 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 oﬀer tight integration with Microsoft products such as Microsoft Oﬃce 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 speciﬁc environment, which runs on top of the mobile device’s 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 2.2. MOBILE ENVIRONMENTS 13

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 speciﬁc 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. 2.2. MOBILE ENVIRONMENTS 14 19.9% 54.3% 88.2% 29.3% 29.7% -22.5% 946.2% Growth Q4’06/Q4’05 8.0% 4.6% 9.2% 0.6% 54.3% 24.3% 100.0% % share 777,580 108,710 9,268,410 1,185,340 1,563,680 4,150,210 17,053,930 Q4 2005 shipments 8.3% 6.6% 5.5% 5.1% 50.2% 24.3% 100.0% % share Table 2.1: Worldwide Smart Phone Market [8] 1,829,260 1,463,090 1,211,930 1,137,360 5,368,130 11,114,630 22,124,400 Q4 2006 shipments RIM Palm Total Nokia Others Vendor Motorola Sony Ericsson 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 offers 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 differently on different 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 Proﬁle

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, speciﬁcally 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 deﬁnitely looks bright. According to Gartner [13] the worldwide 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 conﬁdent 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 speciﬁcations that are designed for diﬀerent 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 proﬁles and conﬁgurations 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 configurations available: Connected Limited Device Configuration (CLDC) and Connected Device Configuration (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 fits 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 profile is the Mobile Information Device Profile (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 Profile are called MIDlets. 2.4. JAVA ME 19

2.4.1 Java ME APIs

MIDP 1.0 oﬀers the following APIs:

• javax.microedition.io Contains Java ME-speciﬁc classes used for I/O.

• javax.mocroedition.lcdui Contains Java ME-speciﬁc 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 offer greater functionality at the cost of being more device- specific. The ability to utilise these optional packages is where the maturity of Java ME is noticeable, with many APIs designed specifically 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) file containing all the class files and resources. A JAR file is used to contain compiled Java classes, associated meta-data and resources pertaining to a certain application. Within the JAR file is the Manifest file which contains the meta-data for the application. A Java Application Descriptor (JAD) file usually accompanies the JAR file. The contents of the JAD file is essentially the same as the Manifest file. The JAD file allows the user to view the details of a MIDlet without having to download the whole file.

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 device’s built in web browser, if it has one, as shown in ﬁgure 2.

2.4.3 Future of Java ME

According to Java Speciﬁcation Request 271 [22], MIDP 3.0 plans to build upon the success of MIDP 2.0 by enhancing certain aspects of the proﬁle 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 speciﬁcally developed for mobile devices. 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] 2.5. ADOBE FLASH LITE 22

• ActionScript Extensions Allow access to device speciﬁc features, such as battery level and signal strength. It also oﬀers 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 oﬀers 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 Oﬀers the ability to store and retrieve relevant, application-speciﬁc information locally. This provides a more robust development environment. User preferences, high scores, etc. can be stored. 2.5. ADOBE FLASH LITE 23

• 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 speciﬁcally 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 diﬀerent 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 files. As of Flash Lite 2.0, compressed SWF files may be used. The SWF file can be transferred to the mobile device using Over- The-Air, Bluetooth, or any other means of transferring data to the device. The SWF file is then launched from the Flash Lite player on the device. This is different to Java deployment in so much that Java ME applications consist of a JAD file which describes the application, and contains the location of the application JAR file. While this offers the ability for users to screen Java ME applications easily without downloading them, it is more complex than the single SWF file 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 eﬀort.” The ease- of-use, short development time, and high return on investment are key factors that set it 2.5. ADOBE FLASH LITE 24 Figure 2.3: Flash Lite 2.0 Architecture [5] 2.6. COMPARISON MATRICES 25 apart from other development platforms, speciﬁcally 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 environments, 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 developer’s experience developing on the given platform. However, the tools available, and the development work-ﬂow used eﬀect the development time. Suomela found, as a general rule of thumb, development is quicker on Flash Lite than Java ME, especially for non-programmers. Table 4 shows Suomela’s comparison of available development tools.

A closer comparison of the development environments can be done, contrasting the development 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 Flash Lite Decompilers Windows, Mac $700 (free 30-day trial) Adobe Flash CS3 Professional Flash/CS3 Device Central Emulator Free Java ME Windows Obfuscation SDK/Emulators, On-Device-Debugging Table 2.4: Comparison of Development Tools. Adapted from [24] JDK, IDE (Eclipse + Carbide.j or NetBeans), platform SDK etc. started Getting Tool cost platforms Developer Debugging and testing Optimisations, 2.7. CHAPTER SUMMARY 27

• Lines of code The total number of lines will be indicative of the amount of coding eﬀort 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 signiﬁcant aﬀects 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 diﬃcult to use, understand, play, or navigate, this immediately has a negative eﬀect on the user’s 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 ramiﬁcations on the overall experience oﬀered to the user by the game.

2.7 Chapter Summary

In this chapter, we discussed mobile environments – the platforms and application environments – 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, speciﬁcally 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 2.7. CHAPTER SUMMARY 28 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 specifics of both Java ME and Flash Lite were discussed. Details of the APIs available in each development environment were listed. Methods of deploying applications, and future developments of both environments were also considered. The game development- specific 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 specifically for game development.

Methods for comparing mobile game development on Java ME and Flash Lite were investigated. 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 environment consisting of enchanting sounds and enthralling graphics, the player controls the

29 3.2. GAME REQUIREMENTS 30 protagonist of the game’s background story aimed at captivating the player’s 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 player’s 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 character. 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 oﬀers 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 controls 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 eﬀect promptly.

Another aspect that can aﬀect 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 platform’s 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 (figure 3.2), power-ups and effects. This gave us the chance to test how effectively 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 eﬀects 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 player’s game, including the player’s 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 Lite’s 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 characters 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 3.4. CHAPTER SUMMARY 35

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 tile’s 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 diﬀerent looking environment can be constructed without diﬃculty 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 (flipped, rotated, scaled, translated, etc.) to achieve desired effects 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 figure 3.6.

3.4 Chapter Summary

After deciding that an arcade-style, top-down shooter game would be suitable for comparing 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 3.4. CHAPTER SUMMARY 36 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 signiﬁcant 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 conﬁguration of the development 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 signiﬁcantly for game development, how eﬀectively 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 diﬀerent 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 Conﬁguration

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 proﬁles keep Flash CS3 aligned with current mobile devices. These device proﬁles 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 development, 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 offers all the required functionality for creating new projects, configuring MIDlets, compiling, testing and emulating Java ME applications under varying conditions, as well as utilities for method profiling, obfuscation, memory and network monitoring, and a multitude of other useful utilities for MIDlet testing, emulation and distribution.

4.2.2 Requirements, Installation and Conﬁguration

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 connection 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 file with a .jad file containing meta-data description the application, while the Flash Lite compiler creates a .swf file. These files 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 diﬀerent 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 Diﬀerences between Developing in Java ME and Flash Lite

Java ME applications are coded in Java, which is an object oriented programming language. 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. 4.3. IMPLEMENTATION 41

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 diﬀerent 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 player’s 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 ME’s Command and CommandListener classes allowed us to create a simple but eﬀective, 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 diﬀerent ‘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. 4.3. IMPLEMENTATION 42

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 conﬁgured manually. This allowed more control over the look and feel of the user interface, but also required more work and eﬀort.

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 signiﬁcantly more work. Java ME is designed for creating simple, functional menus.

4.3.4 Graphics and Sound

A signiﬁcant 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 rendered 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 effects and music play a critical role in setting the mood of the game experience. Unless compressed, audio files are too large to be stored on mobile devices with little 4.3. IMPLEMENTATION 43 memory. For this reason we compressed the sound effects using a low bit rate MP3 format, and used MIDI files for the music. MIDI is an effective 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 eﬀects 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 oﬀer 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 specifically designed for persistently storing data such as high scores. A best effort 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 effectively.

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-specific capabilities such as an off-screen graphics buffer, 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 invaluable resource for mobile game development. Flash Lite did not offer an APIs aimed specifically 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 ME’s game API contains a TiledLayer class speciﬁcally 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 player’s ship moving forward in space is created by moving the LayerManager’s view window.

Flash 8 introduced the BitmapData object, which is similar to Java ME’s TiledLayer object. Regrettably Flash Lite is based on Flash 7, and consequently does not oﬀer 4.4. IMPLEMENTATION OF THE GAME ENGINE 45

Listing 1 Main game loop performing actions depending on the current game state while (!gameOver) { // main game loop i f (gameState == 1) { // Game is running verifyGameState (); // verify game state checkUserInput (); // check user’s input updateGameScreen(getGraphics ()); // update screen sleepTime = 30; // sleep for 30 miliseconds i f (DEBUG > 0) calculateFPS (); // calculate FPS } else i f (gameState == 0) { // Game is paused displayPause(getGraphics ()); sleepTime = 500; } else i f (gameState == 2 || gameState == 3) { // Game over or level passed, leave game loop break ; } else i f (gameState == −1) { // Pre−game s t a t e updateGameScreen(getGraphics ()); // update screen gameState = 1; // start game sleepTime = 300; // in 0.3 seconds } try { Thread.currentThread (). sleep(sleepTime); } catch (Exception e) { debugMessage("Error␣sleeping␣in␣main␣loop:␣" + e, 1); } } 4.4. IMPLEMENTATION OF THE GAME ENGINE 46 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 speciﬁc 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 offer 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 specific requirements of our game, but did not perform as well as the optimized game-specific 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 player’s 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 diﬀerent layers. Flash Lite’s 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. IMPLEMENTATION OF THE GAME ENGINE 47

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 ME’s ‘game buttons’ are device independent, and are mapped to the most appropriate device buttons for playing games. This is a big advantage over Flash Lite, which is only capable of mapping events to speciﬁc buttons, eﬀectively rendering Flash Lite’s key detection as device dependent.

4.4.4 Collision Detection

Collision detection is the act of detecting when two sprites have collided, and is implemented 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 signiﬁcance 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 effectively 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 final file 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 contains 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 player’s 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, respectfully. 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 diﬀer- 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 eﬀective search functionality. The information contained within the documentation is concise and oﬀers 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 applications. 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 oﬀered many useful utilities such as memory usage monitoring and method proﬁling, 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, 4.7. CHAPTER SUMMARY 51

Figure 4.3: The Java ME and Flash Lite implementations of Black Sky emulated side-by- side 4.7. CHAPTER SUMMARY 52 time-based programming, and Device Central CS3 can emulate over 220 mobile devices with memory, network and performance monitoring.

There was a noticeable difference 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 effort. 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 files, while Java ME had no trouble playing multiple sounds and MIDI music simultaneously. Neither platform struggled with persistent storage, although Java ME’s 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 offers all the APIs needed to create a tile-based game engine. Flash Lite APIs did not offer 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 specifically for this purpose.

Both platforms are capable of handling button presses and other user input. Java ME’s GameCanvas class has been optimised to detect button presses irrespective of how brieﬂy- /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 Lite’s 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 diﬀerent ways. The Java ME version was largely object oriented, 4.7. CHAPTER SUMMARY 53 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 Lite’s proficiency 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, final file 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 implementation. 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 conﬁgure 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 eﬀort put in. However, due to the slightly diﬀerent 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 files. The Flash Lite implementation consisted of only 1000 lines of code. This may appear like a drastic difference at first, but if the time-line nature and WYSIWYG development mode of Flash are considered, one realises total effort 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 final file intended for distribution is critical. Mobile games are usually sent over-the-air or downloaded from the Internet. In order to accommodate this, the file 5.2. COMPARISON TESTS 56 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 files.

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 diﬀerence between the two versions 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 duration of two one minute levels. The initial (and largest) peak of 516 KB was from the initialisation of the MIDlet. The peak-valley eﬀect 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 signiﬁcantly less memory than the Flash Lite implementation. 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 5.2. COMPARISON TESTS 57

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 diﬃcult 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 information, 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 proﬁling 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 file associated with a Java ME application is a useful file containing meta-data, but is not necessary for the execution of the application. One of the valuable attributes saved in the .jad file is the size of the associated .jar file. 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 proﬁle showing CPU cycle usage 5.4. CHAPTER SUMMARY 60

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 final file size of both versions differed 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 briefly discussed the available means of deploying mobile games. Due to the similar file sizes, it was deemed immaterial how the content was delivered to the mobile phone as they were both files that could be transferred. However, Java ME had the advantage of having a .jad file containing meta-data, such as the size of the associated .jar file and a description of the application.

In most scenarios related to mobile game development, especially arcade-style game development, 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-speciﬁc 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 speciﬁcally 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 eﬀective 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 significant difference in how the two versions were created. Flash Lite was more proficient than Java ME in creating menus and user interfaces, although with Java ME it was possible to create functional menus quickly with little effort. 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 offered many APIs that simplified to process of creating a tile-based game engine. With specific 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 offer much support for the development of a tile-based game engine. With much effort 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 ME’s implementation of collision detection is superior to Flash Lite’s 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 diﬀerent 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 ME’s 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 final file size of both versions was less than 100 KB and differed 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 signiﬁcantly 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, speciﬁcally 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 gaming 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. Master’s 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 proﬁle). 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 proﬁle 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 popular 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 egg’s ability to hatch another egg and mobile phone’s 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 eﬀect 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, respectfully: package BlackSky ; import java. util .Random; import javax.microedition.lcdui.Image; import javax.microedition.lcdui.Graphics; import javax.microedition.lcdui.game.Sprite; /∗∗ ∗ The Enemy c l a s s .
∗
∗ This class creates a new Enemy object for the ’Black Sky ’ ∗ game.
∗ Enemies can be of different sizes, and shown by a s p e c i f i c ∗ image. They can also have a unique size. ∗ ∗/ public class Enemy extends S p r i t e { private int [ ] speedX ; private int [ ] speedY ;

69 70 private int speedIndex = 0; private int type ;

/∗∗ ∗ Enemy constructor
∗
∗ Creates a new Enemy object, with specific values. ∗ ∗/ public Enemy(Image image , int frameWidth , int frameHeight , int type ) { super (image, frameWidth, frameHeight); this .type = type; i f ( type != 1) { speedX = new int [] {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 int [] {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}; } else { speedX = new int [] {0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 2, 2, 1,1,0,0,0}; speedY= new int [] {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.length) speedIndex = 0;

i f (speedIndex % 10 == 0) this .nextFrame() ; 71

this .move(speedX[speedIndex] , speedY[speedIndex]) ; }

public void fireWeapon(Graphics g) { g.setColor(0x0000ff); g.drawString("little␣enemy␣bang", 130, 200, 0); } } 72

/∗∗ Enemy c l a s s author: Alex Koller version: 0.8 modified: 08/21/2005 ∗/ class Enemy { // private instance variables private var __type:Number; private var __password: String ; public var speedX:Array; public var speedY:Array;

// constructor statement public function Enemy(type:Number) { this .__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); } else { 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); } } }