网友买安 眠药后收到注销驾驶证短信  鞠婧祎被实名举报偷税漏税  广东7月起未经同意快递不得放驿站  

Gamasutra网站刊登了独立游戏程序员Amos Labe撰写的一篇博客文章，文中展示了对于网络/手机项目开发的思考和深度分析。

对于参与休闲、社交或移动领域游戏开发的独立开发者，最早作出的决策之一是确立目标平台。通常团队或工作室会为新项目选择已取得丰富经验的平台，不需过多考虑。但一旦游戏产品走向更多平台，却难免会出现问题。

手机、网络，或两者兼顾？

为休闲2D游戏确定首要目标平台，选择手机还是网络，更具体一点说：Facebook还是IOS，是常见的两难选择。这两个平台都拥有与微交易和社交功能紧密联系的亿万用户，市场潜力巨大。

一直以来，各平台上获得成功的游戏分属不同的类型，但游戏类型之间的差别已越来越小，技术的差异才是根本。

这同样适用于其它移动平台。目前iOS的市场占有率最大，Android和Windows Phone则潜力可观。当考虑多移动平台时，应先确定一个主平台，其它平台可以参考或者类推。

平台移植的著名实例，有《植物大战僵尸》在手机和网络平台之间的移植（从C++转到Flash，再到iOS），还有《愤怒的小鸟》从iOS延伸到几乎所有其它移动平台，而且有了Flash版本，还将在Facebook上发布。

这两款游戏都先在主平台上取得了出色的成绩，足以为开发者筹集到平台移植所需资金。但大多数独立开发者无法拥有这样的机会。

移植中的问题

将一款游戏从现有平台移植到另一个平台会是一项繁琐和冗长的任务。AAA级游戏使用跨平台引擎，单一的代码库可适配多个平台。但休闲游戏和手机游戏则相反，平台移植往往意味着几乎需要重写全部代码。

为平台移植不得不追加的项目预算和时间表，往往让独立开发者感到头疼。他们只好将游戏限制到单一平台上，宁愿用同样的花费来提高游戏的内容品质。

商业化需要市场更大更强。通常游戏发布的时候，跨平台的资源还未能到位。这就是我们看到移动开发商将游戏限制在单一平台上的原因。

理想情况下，如果游戏在主平台上表现出色，开发商随后需要花费6个月到一年时间将其发布到另一个新平台上。但大多数时候，成本是个问题。

作为一个程序员，我想把重点放在技术层面。通过精心设计和计划，我们可以利用一个平台的技术成本来实现两个或两个以上平台的技术移植。虽然无法毫厘不差，但可以将超出成本的部分控制到最少。

是否可以“一刀切”？

当为新游戏规划代码库时，可以提前考虑代码和资源是否易于移植的问题。理论上是可行的，因为良好的架构不依赖于特定的平台功能，模块设计可以帮助主要游戏模块与平台的组成部分分离开。

然而，实际操作中出现了许多问题。不同层面的差异一一出现：在移动设备的硬件方面，网络和移动平台间的硬件方面，操作系统能力以及工具和编程语言上。编程语言的差异则源于每个平台都有编写本地应用的专属程序语言。

其中一些差异性可通过代码规划或交叉编译器来融合。像Unity3D或Corona这样的工具有适用于不同平台的版本，但 代价是开发者受限于仅这些工具能支持的代码，无法达到本地代码的灵活性。某些情况下，这是一个不错的选择，但此类工具的要求非常严格。

俗话说：没有一个尺寸适合所有人。总之，风险仍然存在，我们也许只能得到享有各平台交叉特征的产品，未能为任何平台做专门的优化。

从某一个平台开始

理想的情况下，为享有灵活性，我们希望使用平台的原始工具和代码库为其编写代码。为你（或你的团队）选择熟悉且适合我们编码风格和架构的工具非常重要。

技术的选择虽然是主观性的，但也基于一套对开发推进至关重要的因素。它们是：

· 使用常见的资源类别（如位图，sprite sheet等）

· 为美术和设计提供强大的工具支持

· 带调试工具的强大的面向对象的语言

· 以可以提供稳定核心功能的行之有效的框架为基础

在这种情况下，Facebook – Flash/ AS3，IOS – Cocos2D / Objective-C，其中之一可作为主平台，另一个可作为移植的平台。从一开始，我们就利用AS3和Objective-C相似的优势，移植会更容易。

接下来的第2部分中，我将制定出关于代码框架的计划，旨在为网络和移动平台的可移植性问题提供解决方案。