Jumping from web to mobile: Challenges of cross-platform game development

[In this reprinted #altdevblogaday in-depth piece, independent game programmer Amos Laber begins his series on the challenges of cross-platform development, looking at considerations one should take for web/mobile projects.] For an indie developer working on game projects in the casual/social or mobile space, one of the earliest decisions to make is what platform to target. In most cases it's a no-brainer, since the team or studio already gained experience developing a game for platform X, but then there is always the question of branching out to more platforms. Mobile, web, or both? In choosing the primary target platform for a casual 2D game, the typical dilemma is choosing between mobile and web – or to be more specific: Facebook or iOS . Both platforms offer access to hundreds of millions of users with solid support for micro transactions and social features, which in turn translate to a huge potential market. Traditionally there are differences in genres that are successful on each of the platforms, but they are quickly shrinking, and the differences become mostly technical. The same goes for other mobile platforms. iOS is currently the biggest market, with Android and Windows Phone (XNA) being just as good as potential targets. Whenever multiple mobile platforms are considered, one should always be the first, with the assumption that the rest of the mobile platforms will follow. Real life examples of games that jumped from/to mobile and web are Plants vs. Zombies (ported to Flash from C++ and later to iOS) and Angry Birds, which jumped from iOS to almost any other mobile platform, available now as a Flash game, and is soon to be released on Facebook. Both of these games, however, where successful enough to allow the developer fund the extra resources for porting – something that most indie developers don't have. The problem with porting Porting an existing game from one platform to another can be a tedious and lengthy task. As opposed to the AAA game space, where often cross platform engines are used that enable a single code base to build for multiple platforms, in casual and mobile games, porting often means a complete rewrite of the game. The prospect of stretching the budget and timeline of a game project in order to accommodate porting is forcing indie developers to limit the game to a single platform, since they rather spend that effort on making the game better. Business dictates going for the better or bigger market, and usually by the time the game ships, the resources for porting are simply not available. This is the reason we see mobile developers limiting their games to a single platform. In the best case, if the game gained success and popularity, it could take between six months to a year to release it on a different platform, but in most cases its simply not cost effective. Being a coder, I'd like to focus on the technical aspect. With careful design and mindful planning, it is possible to provide the ability to budget for two or more platforms for the cost of one. Well, OK, not really for the same cost but with minimal overhead. Can one size fit all? A possible approach when planning building a new game code, is to plan ahead for the code and assets to be easily portable. In theory, it should not be a problem – good architecture does not rely on platform specific features, and modular design can be used to decouple the main game modules from platform specific components. In practice, however, many challenges arise. There are differences in hardware (between different mobile devices and between web and mobile), in operating system capabilities, and finally in tools and programming languages – since every platform has a different language that is used to write native apps. Some of these differences can be bridged by careful planning and using cross compilers. Tools like Unity3D or Corona will compile for different platforms, but that comes with a price – the developer is limited to whatever the tool supports, and it does not offer the flexibility of native code. For some cases these are a good fit, but I find them to be very restrictive. As the saying goes: one-size-fits-all never fits. In short, the risk remains that we end up with lowest common denominator product that may not be fully optimized for any of the specific platforms. Start with just one Ideally we would want to be able to code for each platform using its native tools and libraries in order to give us flexibility. It is important to choose tools that you (or your team) are familiar with, and fits our coding style and architecture. The choice of technologies, although subjective, is based on a set of key requirements that I identified as important for smooth development. These are:

In this case: Facebook - Flash / AS3, iOS – Cocos2D / Objective-C. One would have to come first and serve as the primary platform, while the secondary will adjust later. Right from the start we take advantage of the similarities between AS3 and Objective-C, so jumping between them will be easier. Next time, on part 2, I will lay out a plan for a code framework that aims to offer a solution for the problem of portability across web and mobile platforms. [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]