Document transcript

There has been big growth in the mobile applications in the last few years. But, beforeyou begin on the path to develop mobile applications, there are a few factors that you must consider tominimize the development costs.

We have been doing mobile development for over 20 years, and thishas taught us a number of things. The first and most important factor is that a mobile development isquite unlike development on a PC. Based on our internal experience and technology expertise

of over20 yearsat Rapidsoft Systems, we discuss some of the

factors

that can help you plan your strategy formobile applications including game development for rapidly emerging mobile market.

This is a

rather

technical paper, but anyone can gain by reading it.

Introduction

For mobile

developers, one of the most important choices to make at the beginning of the developmentprocess is on which mobile software platforms this game should run. Although developers haveconstantly complained about the limitations of the mobile phone hardware and software environment,it is somewhat surprising to see that few of them actually choose the more powerful mobile platforms,such as Symbian C++, Visual C++, and .Net Compact Framework, to develop their games. Mostdevelopers focus on the relatively constrained Java 2 Platform, Micro Edition (J2ME) and Binary RuntimeEnvironment for Wireless (BREW) platforms. The reason is simple: Those are the two platforms with thehighest volumes and, therefore, the best support from operators.

Choosing the right platform

BREW

BREW is a C++-based smart client platform for handsets based on Qualcomm's CDMA chips. Its mainattraction is that the platform integrates very well with the operator's services and enjoys automaticsupport for content downloading and billing. BREW is very popular among CDMA network operators inthe United States. For commercial mobile developers who lack the experience working with wireless

operators, BREW is a good platform to start on, although its reach is limited. The number of CDMAnetwork subscribers is only one-fifth of GSM network subscribers worldwide. In addition, the C++programming language is difficult for many developers to master. For hobbyistdevelopers, the tightintegration between BREW and the operator makes it difficult to distribute free or personal BREWgames over third-party Web sites.

J2ME

J2ME is by far the most popular application development platform for mobile devices. It is primarilyavailable on GSM handsets and is supported by all major GSM manufacturers, including Nokia,Motorola, Samsung, and Sony-Ericsson. In fact, J2ME is even supported on Nokia's CDMA devices andMotorola's Windows Mobile devices. The J2ME handset manufacturers have a combined market shareof more than 80 percent, and J2ME is available on more than 700 million handsets. By the end of theyear 2008, more than 150

wireless operators worldwide had deployed Java programming support. Withautomatic memory management and a rich set of easy-to-use APIs, J2ME is designed to boost developerproductivity. On the other hand, the large market share and diverse device support for J2ME alsopresent the biggest technical challenge for J2ME developers--

and run, but this development path isn'tofficially supported by Google.

The unveiling of the Android platform on 5 November 2007 was announced with the founding of theOpen Handset Alliance, a consortium of 48hardware,software, andtelecom

companiesdevoted toadvancingopen standards

for mobile devices.Google released most of the Android code under theApache

free-software

andopen source license.

iPhone

iPhone is a very popular handsets with developers and users alike.

With millions of users, iPhone is apopular device for mobile development. At Rapidsoft, we have a separate development team for this.The iPhone is an internet-connected multimedia smartphone designed and marketed by Apple Inc. Itsminimal hardware interface lacks a physical keyboard, so a virtual keyboard is rendered on the multi-touch screen instead. The iPhone functions as a camera phone (including text messaging and visualvoicemail), a portable media player (equivalent to an iPod), and an Internet client (with email, webbrowsing, and local Wi-Fi connectivity). The first-generation phone hardware was quad-band GSM withEDGE; the second generation added UMTS with HSDPA.

iPhone OS is the operating system that runs on the iPhone (both models) and the iPod Touch. It is basedon a variant of the same basic Mach kernel that is found in Mac OS X. iPhone OS includes the softwarecomponent "Core Animation" from Mac OS X v10.5 which, together with the PowerVR MBX 3D

hardware, is responsible for the interface's smooth animations. The operating system takes up less thanhalf a GB of the device'stotal storage (4, 8, or 16 GB).

It is capable of supporting bundled and futureapplications from Apple, as well as from third-party developers. Software applications cannot be copieddirectly from Mac

OS X but must be written and compiled specifically for iPhone OS.

Blackberry

RIM provides a proprietary multi-tasking operating system (OS) for the BlackBerry, which makes heavyuse of the device's specialized input devices, particularly the scroll wheel (1999–2006) or more recentlythe trackball (September 12 2006–Present). The OS provides support for Java MIDP 1.0 and WAP 1.2.Previous versions allowed wireless synchronization with Microsoft Exchange Server's e-mail andcalendar, as well as with LotusDomino's e-mail. The current OS 4 provides a subset of MIDP 2.0, andallows complete wireless activation and synchronization with Exchange's e-mail, calendar, tasks, notesand contacts, and adds support for Novell GroupWise and Lotus Notes.

Third-party developers can write software using these APIs, proprietary BlackBerry APIs as well, but anyapplication that makes use of certain restricted functionality must be digitally signed so that it can beassociated to a developer account at RIM. This signing procedure guarantees the authorship of anapplication, but does not guarantee the quality or security of the code.

Windows Mobile

Windows Mobile is a compact operating system combined with a suite of basic applications for mobiledevices based on the MicrosoftWin32 API. Devices that run Windows Mobile include Pocket PCs,Smartphones, Portable Media Centers, and on-board computers for certain automobiles. It is designedto be somewhat similar to desktop versions of Windows, feature-wise and aesthetically. Additionally,third-party software development is available for Windows Mobile. Originally appearing as the PocketPC 2000 operating system, Windows Mobile has been updated several times, with the current versionbeing Windows Mobile 6.1 and a future 6.5 release

planned for release toward the end of 2009.

Microsoft projected in 2008 that shipments of devices with Windows Mobile will increase from 11million to 20 million units, but it missed its initial goal in only selling 18 million licenses citing the delayedlaunch of certain smartphones. Windows Mobile's market share as an operating system forsmartphones worldwide has fallen from 23% in 2004 down to 12%in 2008.

Windows Mobile now has aworldwide smartphone market share of 14%.Microsoft licenses Windows Mobile to four out of theworld's five largest mobile phone manufacturers, with Nokia being the other.

Some current estimatessuggest that 80% of the 50 million Windows Mobile devices made have been built by one contractmanufacturing group, HTC, which makeshandsets as for several major companies under their brands, as

well as under its own brand.

However, in February 2009 Microsoft signed a deal with the third largestmobile phone maker, LG Electronics, to license Windows Mobile on 50 upcoming LG smartphonemodels.

Mobile ApplicationsPorting

Issues and Solutions

Although the J2ME API is relatively easy to learn, it is misleading to suggest that mobile Java languagegame development is somehow simpler than developing console or PC games. In fact, in terms

percentage share of the total revenue, the development and engineering cost for mobile games couldbe much larger than those for console or PC games. Most of theexperts agree

that the biggest (andmost expensive) challenge in mobile applications

development is the support of these many differentdevices in a fragmented market.

The J2ME platform makes the Java programming language and a standard set of APIs available across allthe Java-compatible devices from multiple vendors. Ideally, a J2ME application developed for one Javahandset should run without modification on all other handsets supporting the same APIs. However,Java's "Write Once, Run Anywhere" vision has yet to be realized, thanks to the fragmentation of thedevice market. Meanwhile, there are several reasons why there are so many phone models:

• Because mobile devices are highly personal, each one is designed for a very specific usage pattern. Forexample, enterprise users, consumers, messaging teenagers, price-conscious users, and hardcoregamers all get different phones with different combinations of functions and UI styles.

• Operators need to differentiate their service offerings, such as by customizing the device hardwareand software. They can also decide to enable or disable certain data service on the device. For example,NexTel would not permit a third-party J2ME application download to general consumer phones on theirnetwork.

• Mobile phones are evolving faster than Moore's law, with hundreds of new device models on themarket every year. Those devices support different versions of the J2ME standard and different sets ofthe optional API packages. Right now, the low-end MIDP 1 devices have the largest installed base. Butmany new MIDP 2 smart phones, including advanced devices that support the J2ME 3D, Bluetooth, andWeb services APIs, are starting to take over the high-end market.

Supporting all the popular devices on the market maximizes the J2ME game's chance of reaching thecritical mass for commercial success. A Java application needs to beported, optimized, and tested foreach target device it is intended to run on, which is a complicated challenge. For example, even amongNokia products, Series 60 and Series 40 devices have very different screen sizes, memory sizes, and CPUspeeds. Furthermore, the quality control of the Java Runtime Environment (JRE) on devices has beenweak. Different devices could have different bugs, particularly in their thread or memory managementimplementations. You have to work around those problems one device at a

time. This can be extremelyexpensive and requires extensive technical know-how to optimize for more than 70-80 devices in house.

According to J2ME game development expert, today's J2ME game industry has original applicationdevelopers and specialized porting houses. The original application developer typically develops ageneric version of the J2ME game for a representative mass market device (or one version each for thehigh-end and low-end devices). If the operator is interested in the game, the operator arranges for a

porting house to optimize and test the game for all Java handsets it carries.

For beginning developers, we suggest

starting from a high-end device with the least amount ofcomputational and API constraints. Those devices allow the developer to focus on the correct API usageand game design instead of advanced CPU and memory optimizations. A Nokia Series 60 MIDP 2 devicewould be a good device to start with. Then, as you gain experience as a developer, it's a good idea tomove toward more restrictive mass market devices. For example, most Nokia Series 40 devices onlysupport 64 KB Java Archive (JAR) file size and 200 KB heap memory size limits. To port a graphic-intensive application from Series 60 to Series 40 requires reworking the graphics and even changing thegame play. This step is absolutely essential, though, for the commercial success of the game. Asdiscussed here, the great strength of mobile games lies in the large volume it occupies in the massmarket. The low-end devices have

by far the largest volume in the mass market. For instance, the NokiaSeries 40 devices--

the most widely adopted Java phone ever--

have

sold 10 times more units thanSeries 60 devices. The skill to understand the low-end devices and optimize applications for them iswhat separates novice developers from seasoned ones.

The Nokia Series 40 was the most frequently mentioned line of devices at the conference. Developerslove it for its huge market share, but hate it for the amount of optimization work needed to portapplications to it. For mobile game developers, it is important to master the skills to scale applicationsup from or down to Series 40 devices.

We get a lot of questions about game porting process. So let us clarify Rapidsoft Systems’s

methodologies here.

Porting PC Games

or Applications

to Mobile Platforms

Let say if you

have a simple 2D C++ game engine,

and have a PC

game based on that engine, and you

want to port it to different mobile platforms BREW, J2ME,

iPhone, Android, Symbian, etc.

Needless to say,

that you want to get that game quickly available to mobile users. What is the best wayto do it?

Do you

need to re-code the engine and the game for each platform?Or is there an easier and moreefficient way?Everyone knows thatthe processis complicated since different phones have differentgraphic/

processor/

memory/etc.

We often deal with customers and companies thathave a catalog of Flash or other games and would liketo port them to mobile platforms. Unfortunately, it is not that straight

forward sinceFlash is notsomething that is available on phones. Moreover, phones have limitations that are very different thendeveloping games or applications on PCs or MACs. Just because a game was simple

to develop

on Flashdoes not mean that it can be made available to mobile users with the same ease since developmenttechnologies on phones are very

different and require a very different set

of skills.

Besides, developingthe application logic and re-doing all its graphics elements and user interfaces–

onemust deal with theissues of

mobile

device porting–

inother words

making sure that an application or game runsflawlesslyon atarget

handset.

And, this must bepotentiallydone as many times as there are device and operatorcombination.

There are several ways of attacking mobile game porting. First of all, until very recently it was mostlyBREW andJ2ME. The iPhone, Android and BlackBerry are changing this landscape and making theimpossible task of mobile gameporting even more impossible. The authorworked in 3rd party mobilegame development for many years until recently.

In the last few years, we have seen less focus on

BREWand saw publishers completely focus on J2ME as the cost of porting is strangling the industry. There areestimates to its cost, both time and money, and it seems to bell curve around 50-60% of the totaldevelopment cost for each game is just porting.

At our company, we handle

porting by having two engines that paralleled each other, one in BREW, onein J2ME. Most developersneverrequestedSymbian

port

as Symbian development does not make anymoney. It is mainly for high-end tech demos that might be on one or two devices, nothing that couldreach the mass market. Plus, most Symbian phones

support

J2ME.

Wearerequired by publishers to provide anywhere from 7-23 reference builds of the game, targetingmany different devices, in

both BREW and J2ME. Just before moving on, publishers were also starting torequire a J2ME touch screen reference version, and an iPhone SKU was being left as "to be determined"based on the final product and how cost effective an iPhone version would beat that time. Thereference versions would then be passed on to a porting house to translate the different references tothe thousands of other required SKUs.

Many big companies

still

use

brute force their way through porting. That's why their

games areconstantly at a higher quality than the rest of the industry. However, it is just not possible for smallercompanies to attack the problem this way due to costs. Not everyone can afford an office in Beijing with5000 developers.

That’s where Rapidsoft Systems can help in finding a suitable solution.

There are many companies, such as Mobile Distillery,

out there developing engines to cut porting costs.It is hard to vouch for their efficiency without using it. So, we

can't vouch forsuch engines. The problemhere is that you will be at the mercy ofother companies’

engines. Performance could be problematicdue to the fact that it is being built to target thousands of SKUs. Plus, you really have little control overthe low level implementation of your game in this instance. The end result seems to be a game thattargets the lowest common denominator of phones.

Finally, a lot of developers are just abandoning the idea of supporting all mobile platforms. There is ahuge flood on games on the iPhone because 1) it requires only targeting one platform and 2) there is a70 percent profit share through the AppStore for developers. Through carrier releases, the percentage isnot even comparable.

Solving Multi-Platform Puzzle

The problem of developing an application that runs on multi-platform is not unique

to mobile softwaresince the problem existed in the server domain too

but to a lesser degree.

Mobileapplications simplymake it more complex. One well tested and time proven methodologies is developing hardwareabstraction layer.

At Rapidsoft Systems,what we

have used for multiplatform development is toimplement a hardware abstractionlayer. The engine iscoded inC++and provides an application level

full-fledged C++ for your game and engine and link with the system abstraction written in whateverlanguage your platform needs. Symbian doesn't support 100% of the features of C++,

and still has a fewbugs, andiPhone API uses Objective C. C is compatible which most of the platforms

that we deal inmobile space

(well, not Java).

Linking C is easier than C++, as there are less problems.

Implementing an

additional interface in C is a little slower, buthelps

you a lot when porting it to otherplatforms. Also, it allows you to have a Win32/

Linux/

Mac build besides the Symbian, BREW,etc.

Hands

on experiences

shows

thatthe

debugging capabilities ofSymbian

and N-Gage

platforms are signifficantly

behind Visual Studio or GDB.iPhone, on the other side, has a lot of cool tools to debug and profile yourapp.So, development times and porting times often relate to the debugging capabilities of underlyingphone.

The platforms you are considering are not compatible,

butmost ofthem

allow you to run C/C++ code.Hence,

in theory you could port the engine to some Standard, such as ANSI, or C-99 and it wouldcompile in most of the platforms PC, BREW however this does not take in account the libraries yourengine might need.

Game development has its owncomplexities

since games exploit audio/ videocapabilities of underlying system.

For example,

if your

game

engine uses OpenGL then it would work inthe PC, and some consoles,

but on Symbian

devices you need OpenGL-ES which is not exactly the same,so you need an abstraction for all libraries you use.

This is not as easy as it might first seem.

This adds tothe cost of development for multi-platform mobile games.

About J2ME and Android

-

they are Java platforms, so no C/C++ can be run there without any special VMlibrary

at least. In this case you need to port the C/C++ code

to Java which can be overkill and is acomplete re-write of your game.

So

an expert’s

answer to this is while you can make an abstraction to your libraries (libs)

and code usingstandards you might be able to use the same engine in several platforms as long you can use the samecompiler for them.

And maintaining this is not always easy.

Take a look for example to this engineCubicVR

it allows you to compile the same engine for PC/

Linux/

MAC/

iPhone (maybe)/

Sony PlayStation Portable

device.

If your engine is built on top of some 'platform independent' framework such as Java, then it'ssupposedly easier than if it's written in a lower level language. However, neither Java nor Flash is, forexample, supported on the iPhone/

iPod touch, and it'll probably take a while until they are. On theother

hand,

the only SDK available for those platforms is Objective-C, which, guessing wildly, you didn'tuse to implement your engine.

In general, it depends on the

application/game engine you've written. Most likely you'll have to changesomething, as very rarely are all features available on all platforms. J2ME graphics is a classic scenario of'platform independent'-dependence, or so I've heard. How much you'll have to change solely dependson how portable your code is, i.e. how well did you separate out the parts that potentially needchanging.

Here the task is to port a PC game and make it available to mobile phones. Of course, there aremany mobileplatforms;

we can choosePCtoJ2ME Phones porting. This is essentially a re-writeof applications in most cases.

Thiscan be

an expensive exercise

depending upon the level ofcomplexity of the game ormobileapplication.

B)

Mobile Standard-> Mobile Standard

(MobilePlatform Change)

Here the task is to port games written for one mobile platform to another mobile platform. Forexample games written for J2ME platform to be ported to Brew handsets. Again, because ofincompatibilities between the system, one has to write the application fromscratch.

Thiscan be

an expensive exercise

depending upon the level of complexity of the game ormobileapplication.

Within a device set, do you need a port to be tested on every device or only some of thedevices? For instance, do you need to test your blackberry port onevery variation ofBlackberry

8800, Blackberry 8900

etc., or you can test only on the new models.

3.

Do you need to support multi-platform like Blackberry, Android, iPhone, J2ME, Brew orWindows Mobile or you can wait

to see theresult of first making application ready on one ortwo platforms?

This is an important element in managing the cost. If your application does wellon one platform, therevenue

may befunneled

to do other platform ports.

Conclusions

Mobileapplication

distribution

has become a lucrative industry with a manifold increase in mobilesubscriptions and the number of avid mobile gamers around the world.However, success depends onreducing the cost of development and porting and timely execution of the development and applicationporting.

Use of external porting can cut down the cost and time to marketapplications. While it is possible tocreate an internal porting capabilities for most companies that option will be quite expensive since itrequires significant man power efforts that are cyclical in nature. This means using a trusted partner likeRapidsoft Systems todevelop andport your applications can be the best solution for you.