Summary:  If you are planning to develop commercial mobile applications software, there are a number of variables that you need to consider. This blog summarizes some of these factors.

 

Introduction

For mobile developers, one of the most important choices to make at the beginning of the development process is on which mobile software platforms this game should run. Although developers have constantly 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. Most developers focus on the relatively constrained Java 2 Platform, Micro Edition (J2ME) and Binary Runtime Environment for Wireless (BREW) platforms. The reason is simple: Those are the two platforms with the highest 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 main attraction is that the platform integrates very well with the operator’s services and enjoys automatic support for content downloading and billing. BREW is very popular among CDMA network operators in the 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 CDMA network subscribers is only one-fifth of GSM network subscribers worldwide. In addition, the C++ programming language is difficult for many developers to master. For hobbyist developers, the tight integration between BREW and the operator makes it difficult to distribute free or personal BREW games over third-party Web sites.

J2ME J2ME is by far the most popular application development platform for mobile devices. It is primarily available 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 and Motorola’s Windows Mobile devices. The J2ME handset manufacturers have a combined market share of more than 80 percent, and J2ME is available on more than 700 million handsets. By the end of the year 2008, more than 150 wireless operators worldwide had deployed Java programming support. With automatic memory management and a rich set of easy-to-use APIs, J2ME is designed to boost developer productivity. On the other hand, the large market share and diverse device support for J2ME also present the biggest technical challenge for J2ME developers — the problem of porting an application to a variety of devices.

Android

Android is a software platform and operating system for mobile devices, based on the Linux kernel, developed by Google  and later the Open Handset Alliance. It allows developers to write managed code in the Java language, controlling the device via Google-developed Java libraries. Applications written in C and other languages can be compiled to ARM native code and run, but this development path isn’t officially supported by Google.

The unveiling of the Android platform on 5 November 2007 was announced with the founding of the Open Handset Alliance, a consortium of 48 hardware, software, and telecom companies devoted to advancing open standards for mobile devices. Google released most of the Android code under the Apache free-software and open source license.

iPhone

iPhone is a very popular handsets with developers and users alike.  With millions of users, iPhone is a popular 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. Its minimal 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 visual voicemail), a portable media player (equivalent to an iPod), and an Internet client (with email, web browsing, and local Wi-Fi connectivity). The first-generation phone hardware was quad-band GSM with EDGE; 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 based on a variant of the same basic Mach kernel that is found in Mac OS X. iPhone OS includes the software component “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 than half a GB of the device’s total storage (4, 8, or 16 GB). It is capable of supporting bundled and future applications from Apple, as well as from third-party developers. Software applications cannot be copied directly 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 heavy use of the device’s specialized input devices, particularly the scroll wheel (1999–2006) or more recently the 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 and calendar, as well as with Lotus Domino’s e-mail. The current OS 4 provides a subset of MIDP 2.0, and allows complete wireless activation and synchronization with Exchange’s e-mail, calendar, tasks, notes and 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 any application that makes use of certain restricted functionality must be digitally signed so that it can be associated to a developer account at RIM. This signing procedure guarantees the authorship of an application, 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 mobile devices based on the Microsoft Win32 API. Devices that run Windows Mobile include Pocket PCs, Smartphones, Portable Media Centers, and on-board computers for certain automobiles. It is designed to 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 Pocket PC 2000 operating system, Windows Mobile has been updated several times, with the current version being 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 11 million to 20 million units, but it missed its initial goal in only selling 18 million licenses citing the delayed launch of certain smartphones.[citation needed] Windows Mobile’s market share as an operating system for smartphones worldwide has fallen from 23% in 2004 down to 12% in 2008.[1] Windows Mobile now has a worldwide smartphone market share of 14%.[2] Microsoft licenses Windows Mobile to four out of the world’s five largest mobile phone manufacturers, with Nokia being the other.[3] Some current estimates suggest that 80% of the 50 million Windows Mobile devices made have been built by one contract manufacturing group, HTC, which makes handsets as for several major companies under their brands, as well as under its own brand.[4] However, in February 2009 Microsoft signed a deal with the third largest mobile phone maker, LG Electronics, to license Windows Mobile on 50 upcoming LG smartphone models.[5]

Porting, Porting, Porting …

Although the J2ME API is relatively easy to learn, it is misleading to suggest that mobile Java language game development is somehow simpler than developing console or PC games. In fact, in terms of the percentage share of the total revenue, the development and engineering cost for mobile games could be much larger than those for console or PC games. Most of the speakers at the Austin conference agreed that the biggest (and most expensive) challenge in mobile game development is the support of these many different devices in a fragmented market.

The J2ME platform makes the Java programming language and a standard set of APIs available across all the Java-compatible devices from multiple vendors. Ideally, a J2ME application developed for one Java handset 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 the device 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. For example, enterprise users, consumers, messaging teenagers, price-conscious users, and hardcore gamers all get different phones with different combinations of functions and UI styles.

• Mobile phone manufacturers need to differentiate their product offerings. Different manufacturers adopt different CPUs, memory sizes, base operation systems, and UI features. They also provide proprietary Java extension APIs.
• Operators need to differentiate their service offerings, such as by customizing the device hardware and 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 their network.
• Mobile phones are evolving faster than Moore’s law, with hundreds of new device models on the market every year. Those devices support different versions of the J2ME standard and different sets of the optional API packages. Right now, the low-end MIDP 1 devices have the largest installed base. But many new MIDP 2 smart phones, including advanced devices that support the J2ME 3D, Bluetooth, and Web 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 the critical mass for commercial success. A Java application needs to be ported, optimized, and tested for each target device it is intended to run on, which is a complicated challenge. For example, even among Nokia products, Series 60 and Series 40 devices have very different screen sizes, memory sizes, and CPU speeds. Furthermore, the quality control of the Java Runtime Environment (JRE) on devices has been weak. Different devices could have different bugs, particularly in their thread or memory management implementations. You have to work around those problems one device at a time. This can be extremely expensive 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 application developers and specialized porting houses. The original application developer typically develops a generic version of the J2ME game for a representative mass market device (or one version each for the high-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 of computational and API constraints. Those devices allow the developer to focus on the correct API usage and game design instead of advanced CPU and memory optimizations. A Nokia Series 60 MIDP 2 device would be a good device to start with. Then, as you gain experience as a developer, it’s a good idea to move toward more restrictive mass market devices. For example, most Nokia Series 40 devices only support 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 the game play. This step is absolutely essential, though, for the commercial success of the game. As discussed here, the great strength of mobile games lies in the large volume it occupies in the mass market. The low-end devices have by far the largest volume in the mass market. For instance, the Nokia Series 40 devices — the most widely adopted Java phone ever — have sold 10 times more units than Series 60 devices. The skill to understand the low-end devices and optimize applications for them is what separates novice developers from seasoned ones.

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

We get a lot of questions about game porting process. So let us clarify the methodologies here.

Porting PC Games 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 way to do it?

Do you need to re-code the engine and the game for each platform? or is there an easier and more efficient way? Everyone knows that the process is complicated since different phones have different graphic/ processor/ memory/etc.

 Overview of Mobile Game Porting Process

There are several ways of attacking mobile game porting. First of all, until very recently it was mostly BREW and J2ME. The iPhone, Android and BlackBerry are changing this landscape and making the impossible task of mobile game porting even more impossible.  The author worked in 3rd party mobile game development for many years until recently. In the last few years, we have seen less focus on BREW and saw publishers completely focus on J2ME as the cost of porting is strangling the industry. There are estimates to its cost, both time and money, and it seems to bell curve around 50-60% of the total development cost for each game is just porting.

At our company, we handled porting by having two engines that paralleled each other, one in BREW, one in J2ME. Most developers never requested Symbian port as Symbian development does not make any money. It is mainly for high-end tech demos that might be on one or two devices, nothing that could reach the mass market. Plus, most Symbian phones support J2ME.

We are required by publishers to provide anywhere from 7-23 reference builds of the game, targeting many different devices, in both BREW and J2ME. Just before moving on, publishers were also starting to require 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 be at that time. The reference versions would then be passed on to a porting house to translate the different references to the thousands of other required SKUs.

Companies like Gameloft still brute force their way through porting. That’s why Gameloft’s games are constantly at a higher quality than the rest of the industry. However, it is just not possible for smaller companies to attack the problem this way due to costs. Not everyone can afford an office in Beijing with 5000 developers.

There are many companies out there developing engines to cut porting costs. Mobile-Distillery is one I was in contact with quite a lot, but we ended up never using it. So, I can’t vouch for them. The problem here is that you will be at the mercy of other companies’ engines. Performance could be problematic due to the fact that it is being built to target thousands of SKUs. Plus, you really have little control over the low level implementation of your game in this instance. The end result seems to be a game that targets the lowest common denominator of phones.

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

What I have used for multiplatform development is to implement a hardware abstraction layer. The engine is coded in C++ but using a plain C interface to implement the system calls. This allows you to use full-fledged C++ for your game and engine and link with the system abstraction written in whatever language your platform needs. Symbian doesn’t support 100% of the features of C++, and still has a few bugs, and IPhone API uses Objective C. C is compatible which most of the platforms you mention (well, not Java) and linking C is easier than C++, as there are less problems (ABIs and all that stuff).

Implementing a additional interface in C is a little slower, but will help you a lot when porting it to other platforms. Also, it allows you to have a Win32/ Linux/ Mac build besides the Symbian, BREW, etc. one. I have worked, mainly, with Symbian and N-Gage, and the debugging capabilities of those platforms are significantly behind Visual Studio or GDB.  Iphone, on the other side, has a lot of cool tools to debug and profile your app.

The platforms you are considering are not compatible, most of then allow you to run C/C++ code so in theory you could port the engine to some Standard, such as ANSI, or C99 and it would compile in most of the platforms PC, BREW however this does not take in account the libraries your engine might need. For example if your engine uses OpenGL then it would work in the PC, and some consoles but on Symbiam devices you need OpenGL-ES which is not exactly the same, so you need an abstraction for all libraries you use.

About J2ME and Android they are Java platforms, so no C/C++ can be run there without any special VM lib at least. In this case you need to port the C/C++ code to Java which can be overkiling.

So my answer to this is while you can make an abstraction to your libs and code using standards you might be able to use the same engine in several platforms as long you can use the same compiler for them.

Take a look for example to this engine CubicVR it allows you to compile the same engine for PC/Linux/MAC/iPhone (maybe)/Sony PlayStation Portable

As others have pointed out, if your engine is built on top of some ‘platform independent’ framework such as Java, then it’s supposedly easier than if it’s written in a lower level language. However, neither Java nor Flash is, for example, supported on the iPhone/ iPod touch, and it’ll probably take a while until they are. On the other hand, if I recall correctly, the only SDK available for those platforms is Objective-C, which, guessing wildly, you didn’t use to implement your engine.

In general, it depends on the application/game engine you’ve written. Most likely you’ll have to change something, 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 depends on how portable your code is, i.e. how well did you separate out the parts that potentially need changing.

There are 3 types of Ports (that I consider):

a)Standard platform -> Mobile
-PC -> J2ME Phone

b)Mobile Standard -> Mobile Standard
-J2ME <-> Brew

c)Mobile Phone -> Different Mobile Phone
-Between phones.

The 2.5k is a number that’s between b and c. C is usualy cheap, B is a bit more time consuming and expensive, but A is the most expensive. A involves the creation of a new product from a brand/design which is more then just 2.5k, but for 12.5mil I expect that to be a “minor” fee.

The numbers are inflated. I highly suggest making a feature of the “ports” to support multiple languages in the app, necessitating only the price of translations per port.

20x 50x 2500=2,500,000

This number can be reduced a bit even more by developing apps that automatically adjust to the phone they are put on, (A multi-port will usually involve phones w/ similar speeds, and screen size)

So if the 50 populare phones are compressed down to 10 ports or less (5 phones appeice on AVG is very possible, although there will be ports for “speacial” phones (1-3 phones), and some with 14+ phones)

20x10x2500=500,000

Ok, now for the downside, these numbers don’t include the inital port cost of moving the “game” to that specific platform. Also, developing for these spectrum of devices is not an easy task, and a serious task force is reguired just to learn the details of each device (through extensive internal testing, and documentation)

I can’t really give a recomendation about how to handle this. If your group doesn’t do Mobile game development already, I suggest finding an expeicerd contractor(s) / group to do the iniatal port with specifications that it should support multiple languages, and automatically adjust to a ceratin inital multi-port. Then either use that same company to do the porting to other phones, or find a cheaper company to do the rest of the porting.

If you already do Mobile gaming in the field that your doing porting, then it comes down to how much internal investment you want to commit. There’s a speed/money issue with doing the research in house, but conversly, relying on a outside source may also be problematic.

Game Test and Validation Requirements

1) User Interface test
2) Installation test
3) Game play/usability test
4) Interruption test
5) Over loading test

These are the basic test topics which any software should undergo before deployment.

1) User Interface test
2) Installation test
3) Game play/usability test
4) Interruption test
5) Over loading test

Porting J2ME apps to BREW.

Ther are several API’s being used in J2ME and there is no corresponding library available in BREW. SO how to handle these situations ?

Eg: There s an API called Sound, Player and Volume Control in J2ME, whereas there are no libraries available for the same in C/C++ …

To celebrate the completion of the Linux port of Candy Cruncher, I thought I’d put down some thoughts about porting games and writing portable software in general. This is a sort of tip-of-the-iceberg, random HOWTO on the subject.

Why port software? Especially in the game industry, is there much to gain by catering to minorities? MacOS is sitting on 5 percent of the world’s desktops, and while that’s a significant number of users, the other 95 percent is almost all win32 boxes, which means you can get most of the users from writing for one target, and think nothing of the Linux and BeOS users of the world. So what’s the point?

Here are my reasons:

• Choice. I like my Linux command lines, others like MacOS X’s Aqua, others like WinXP. Making a portable game lets your users work and play in the environment they like best. The consumer wins.
• Code quality: porting to a new platform exposes bugs you never knew existed in the first place. It forces you to remove assumptions from the program. It can make it easier to maintain. It can make it easier to license your code to others, or contract out work on that code. Having a game that runs cleanly across several platforms can actually lower the cost of maintanance if you do it right. It also helps maintain the programmers’ sanity when problems like buffer overruns become obvious through different memory managers.
• Consoles: You want a Playstation 2 port of a game? Your first stop should be Linux. The migration path is easier than going to the console directly, it’s cheaper to develop for, and yes, Linux and the PSX2 use the same compiler.
• Financial reasons: If a program is done right from the start, the cost to move it to new platforms is small, but the potential for extra sales increases. Mac and Linux users do tell their friends about software they like, and they tend to be very vocal in their praise of the companies that are willing to support their platforms. Games for Linux tend to have an infinite shelflife, whereas their Win32 counterparts tend to land in the bargain bin in a month or so.
• Warm fuzzies: I like supporting the underdog operating systems. It makes me feel good. Pyrogon’s stated intention is to make quality games that don’t cost millions of dollars to make. Having players enjoy their games is priority one, so it makes sense to get them into the hands of people that generally appreciate the games more than the twitchy overclockers that are giving Windows gaming a bad name.

I am speaking of games, but these statements are generally true for any kind of software.

So now that we know why, let’s explore how.

To start, I have to express the Tao of porting: no code is portable until it gets ported. Sure, we all write wonderful code, and choirs of angels sing while we type, but there will always be unexpected problems that won’t be seen until the source is pushed through a strange compiler on a strange operating system running on a strange processor. The trick is to minimize the amount of nonportability right from the start. This takes diligence and a little bit of know-how on the part of the coder. Knowing what you’re doing can literally reduce the porting time by weeks. This knowledge is best gathered through experience, but these guidelines can be a push down the road of that first experience. If any of this seems like common sense, then it just means you’ve been down that road before.

Rule #1: Think before you code.

Sounds simple, doesn’t it? Unfortunately, even in the video game industry (ESPECIALLY in the video game industry!), it seems that many developers jump right in and start coding. This is wrong, wrong, wrong. It doesn’t take long for a project to become an unwieldy, hardcoded mass of spaghetti, which leads to the usual set of problems; however, if even maintaining (or, heaven forbid, enhancing) the codebase is difficult, it will be twice as hard to make it portable. What you need is a blueprint. Sketch it out, write it down, babble incessantly about your plan to everyone around. Have an attitude that lets people tell you honestly if a plan is stupid, and prepare to revise details or whole subsystems. Better to do this now than find yourself reworking the program during crunch time.

Rule #2: Make abstractions.
If you’re writing a Windows game, sooner or later, you are going to have to call a Windows-specific function. Things that can be done portably (like using stdio instead of the win32 API) should be done, but other things, like blitting to the screen, are system-specific. What you should do is take a few minutes and wrap things like DirectDraw in a simple class, and expose their functionality in general ways. Do NOT expose DirectDraw data types, to prevent the urge to bypass the abstraction. If something can’t be done through the abstraction layer, then the abstraction layer should expand. Candy Cruncher does this very thing for audio, video, the “registry”, input, etc. For example, you’ve got a “DisplayDevice2D” class. This class is subclassed into a DirectDraw version, a GDI version, an SDL version (for Unix), and a Carbon version (for MacOS). There are some immediate benefits here, even in single-platform development. Note that two of those subclasses are for Windows; this gives Pyrogon the ability to choose the best balance of performance and stability at runtime for any given run of the game. Theoretically, they could add an OpenGL-based subclass of DisplayDevice2D that renders the sprites as textured quads to increase the framerate more, at their users’ discretion. This would be added to the framework, without changing the actual game’s code, and would benefit the next game they do, too. Good abstraction makes good design, and the benefits are quick ports to other architectures, more flexibility for the power users, and better support for various hardware on the primary platform. It’s a huge win.

Rule #3: Be data driven.
Spend as little time in your program as possible. Branch gaming logic out into scripting languages as quickly as possible. This isn’t an argument to write your whole game in Perl (unless you want to, I guess); instead, get the stuff that must run fast in C/C++ code (which is almost always the blitters in a 2D game, reference Rule #2) and get the game logic itself out to something you don’t need to compile every time you tweak it. I say this not just because it’s a good idea, but porting a script interpreter is frequently easier than looking for subtle problems in game logic in C. But what scripting language is best? It depends on what you need. If you need something basic, roll it yourself, but it’s better to embed an existing scripting language; there are many that are portable, debugged, and supported to choose from. Perl, Python, and Scheme are just some options. The Pyrogon framework has Lua, which seems to be popular for scripting game logic.

Rule #4: Be sensitive to byte ordering and packing.
If I ever see another game that sends “sizeof (myStructure)” bytes over a network connection, I’m going to scream. I should scream right now, because I will no doubt see this again. Candy Cruncher is not a networked game, but it does run on both Intel (Windows and Linux) and PowerPC (MacOS X) systems, which means that it has to be careful about reading from and writing to files. Between processor types, operating systems, and even compilers, sizes of data types change. I’m talking about something more subtle than the classic C problem of an-int-is-not-always-the-same-size-everywhere, although that’s important, too. Structures get packed differently (and not every compiler can understand #pragma pack), data has to be aligned differently, and data gets stored backwards on different processors. If you have to read or write structures to disk, a network socket, or anywhere that a different system may see it, you should send it, one scalar at a time, in an agreed upon format (bigendian or littleendian), and rebuild the structure on the other side of the connection. Do not send floating point numbers ever, if you can help it, since different CPUs have different precisions, and you can only correct for this so far (I can think of at least four ports I’ve worked on that got bitten by the floating point thing. Be wary.) If you do not do this now, it is nearly impossible to fix it later in a program of any size.

Rule #5: Write what you have to, steal the rest.
I’ve just told you to write a scripting language and be very careful about how data gets manipulated. Right now you’re probably wondering how any of this is supposed to make your job easier. Hey, I said this takes diligence! However, the secret is really in the open source community. Why should you write image decoders, and audio format decoders, and scripting languages, when they are freely available for the taking? Candy Cruncher takes advantage of several cross-platform libraries: Lua, zlib, and Ogg Vorbis, to name a few. The Linux and Mac Classic ports use SDL, SDL_ttf, and SDL_mixer, not to mention Loki Setup for the installer. This is literally years of development time that can just be dropped into place, and more importantly, all of these libraries are cross-platform to start with, so you don’t have to wonder how you’ll get that .OGG file to play on BeOS; it just will.

Rule #6: Don’t use assembly language.
Just don’t. If you must, you better write a C version and optimize based from that, so that there is a working fallback. But don’t write assembly in the first place. 99.5% of the time you think you need it, you don’t. Just say no; Candy Cruncher did.

Rule #7: Listen to your beta testers.
Sooner or later, your port will be ready for external testing (you are going to do a beta test, right?) and you will be unleashing your baby into an unfamiliar world. If this isn’t your primary development platform, chances are it isn’t a platform you know all the ins and outs of. Even Linux users will find that different distributions do things very differently, and every Linux user has her own routines and traditions. Listen to what they ask you for, and give them what you can. One of the beta testers for Candy Cruncher noted that the game’s response was a bit jerky on his box, and wondered if we could make it use the X11 cursor instead of drawing a sprite. We added that. Another wanted to have his Unix login name be the default when entering his high score. It was a good idea that never crossed my mind: added. People with keyboard layouts I’ve never heard of showed up: fixed. People with exotic display targets poked their heads up: tweaked. Odd sound problems on certain distros: debugged. These requests are to be expected, and are relatively trivial to implement, but they lead to happy customers and, again, a more flexible codebase. You do not want thousands of demo downloads from users that would have bought the game if only the mouse was a little more responsive. You could not have predicted it until someone came along and ran their X-server at an odd color depth. Anticipate possible differences in platforms, but be ready for anything.

Rule #8: Embrace Murphy.
Not every idea is a good one. If something isn’t working, chuck it. If a subsystem isn’t portable, make it so. If you are modular, and abstract, this makes the code easier to drop into a future product. Like I said, nothing is portable until it’s ported, and all the planning in the world doesn’t beat Murphy’s Law. In such cases, don’t be afraid to throw something out and replace it with something that works better. Struggling only makes it worse.

Conclusions

Mobile game development has become a lucrative industry with a manifold increase in mobile subscriptions and the number of avid mobile gamers around the world. However, success depends on reducing the cost of development and porting and timely execution of the development and application porting.

Use of external porting can cut down the cost and time to market applications. While it is possible to create an internal porting capabilities for most companies that option will be quite expensive since it requires significant man power efforts that are cyclical in nature. This means using a trusted partner like Rapidsoft Systems to develop and port your applications can be the best solution for you.