作者：Amos Laber

对于在休闲、社交或手机领域里从事游戏项目制作的独立开发商而言，最先需要确定的是目标平台。多数情况下这都不是个问题，因为团队或工作室会根据已经拥有的游戏开发经验来决定目标平台，但团队向其他平台扩张时总是会面临诸多问题。

手机还是网页，抑或两者兼顾？

在选择休闲2D游戏的主要目标平台时，通常会纠结于手机和网页这两个选择，更具体地说，就是选择Facebook还是iOS。两个平台都有数亿用户，支持微交易和社交功能，所以潜在市场都很大。

从传统上说，两个平台上的成功游戏的题材有所差别，但是现在这种差别正在迅速减少，主要的差别多数在于技术层面。

手机平台之间也是如此。iOS是目前最大的市场，Android和Windows Phone市场也有发展潜力。在同时考虑多个手机平台时，总要选择一个侧重平台，其他平台作为辅助。

有些游戏实现了在手机和网页间相互渗透，比如《植物大战僵尸》（游戏邦注：先从C++转变为Flash，随后被移植到iOS平台上）和《愤怒的小鸟》，后者从iOS移植到几乎所有的手机平台上，现在也有Flash版本，该游戏不久还将在Facebook发布。

植物大战僵尸(from gamasutra)

但是，这些游戏都取得了很大的成功，所以开发商才有更多的资源将其移植到各个平台上，而多数独立开发商无法做到这一点。

移植产生的问题

将现有游戏从一个平台移植到另一个平台上，这是个乏味且漫长的任务。在AAA游戏领域中，往往可以使用跨平台引擎以单个代码为基础构建多个平台的版本。但是对休闲和手机游戏而言，移植往往意味着需要完全重新编写游戏代码。

移植会增加项目制作资金和游戏项目的开发时间，这迫使独立开发商不得不将游戏限制在单个平台上，这样他们才能有足够的精力来不断提升游戏质量。

开发商当然希望往更好或更大的市场发展，但是通常在游戏发布之时，并没有足够的资源用来将其移植到其他平台上。我们会看到手机开发商将他们的游戏限制在单个平台上，这便是缘由。

最好的情况是，如果游戏获得成功并流行起来，在6个月到1年的时间内该游戏会在另一个平台上发布，但是多数情况下不会出现本轻利厚的现象。

我是个程序员，所以更加专注于技术层面。

预先考虑移植问题

有个可行的方法，就是在计划新游戏的代码构建时，设计便于移植的代码和资产。从理论上说，这应当不是个问题，优秀的框架不会依赖于平台的特别功能，模块化设计可以用来减弱主游戏模块同平台特别组件间的联系。

但是，在实际操作中这会面临诸多挑战。硬件（游戏邦注：手机设备间存在差异，网页和手机之间也存在差异）、操作系统处理能力、工具和编程语言都存在不同之处，每个平台都需要用不同的语言来编写本地应用。

在这些差异化中，某些差异可以通过精心的计划和使用交叉编译器来弥补。Unity3D或Corona等工具都可以在不同的平台上编译，但这样做需要付出代价：开发商被局限于工具能够支持的功能上，失去了本地代码的灵活性。对于某些游戏，这种方法确实很合适，但是我觉得能够这样做的游戏极其有限。

简单地说，使用这种方法依然有一定的风险，这样的产品可能无法针对特定平台进行最优化设计。

从单个平台开始

理想情况下，我们可以针对每个平台使用其本地工具和库来编写代码，这样我们才会有更高的灵活性。重点在于，选择你或团队熟悉且符合代码风格和框架的工具。

虽然技术选择是主观行为，我认为需要以某些关键要求为基础，这些要求是：

1、使用普通资产类型（游戏邦注：比如位图和精灵层次等）

2、提供强大工具用于美术和设计

3、提供带有漏洞修补工具的面向对象语言

4、以已证实有效的框架为基础，可以提供可靠的核心功能

这样看来，适合Facebook的是Flash和AS3，适合iOS的是Cocos2D和Objective-C。要先选择其中之一作为主要平台，然后根据次要平台来调整代码。我们可以利用AS3和Objective-C间的相似性，这样两个平台间的移植就会变得更加容易。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

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

Amos Laber

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:

Use common asset types (i.e. bitmaps, sprite sheets, etc)

Provide strong tooling for art and design

Strongly typed object-oriented language with decent debugging tools

Proven framework as a foundation, that can provide solid core features

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. (Source: Gamasutra)