阐述从Flash移植到iOS的框架和平台差异性

作者：Amos Laber

我在上篇文章中阐述了跨平台移植游戏的挑战，在这篇文章中，我将呈现具体游戏项目移植的蓝图。这是款典型的2D游戏，有着卷轴式背景、动画角色和触碰（游戏邦注：在web上使用鼠标）控制方式。以此为例，应当足以概述如何以Flash为主要平台且以iOS为次要平台来计划和构建游戏，这样的游戏可能随后还能移植到Android上。

选择Flash作为主要平台，这样经验丰富的Flash开发者便可以利用使之快速从设计师转变为开发者的工具，比如Adobe Flash Builder和Flash CS，很容易便可以在框架上编写出游戏可玩性代码，迅速创建游戏原型，而无需耗费大量资源将游戏移植到手机平台。

尽管这只是我的主观选择，但如果要缩减开发周期，最好是像一般iOS开发者那样选择桌面开发环境。

从Flash移植到手机上还有些许其他工具可供选择，比如Adobe AIR手机版。将游戏移植到AIR上只需要略微改动代码，而且AIR广泛适用于各种手机平台。AIR有自己的优势，或许它会成为某些项目的最佳选择，但不在这篇文章的讨论范围之类。本文关注的是如何使用本地代码来制作手机版本。

Flash-iOS-Cocos2D

框架和平台差异

今年来，诸多现代游戏框架浮现，而且获得了游戏开发者的认可。多数框架是免费和开源的，它们从web、桌面和手机平台处借鉴各种方法，包含诸多令人印象深刻的优秀功能。

此类框架包括适用于iOS的Cocos2d和Sparrow，以及适用于Flash的Starling和ND2D。事实上，Starling是Sparrow的移植版本，使用的类名称几乎相同，ND2D在风格上同Cocos2d较为相近。

就内容而言，所有框架在图片和动画方面使用的都是相同的资产类型，这使得游戏内容可以在框架间的切换时移植，包括精灵层、动画数据文件和颗粒效应数据（游戏邦注：格式为json和xml）。

顺便提下，Starling和ND2D能够使用Flash 11中可用的硬件加速GPU渲染（游戏邦注：也就是Stage3D）。在某些情况下，开发者会选择软件渲染器以满足更大用户群体的需要，也会使用他们的自定义框架或诸如Flixel、FlashPunk和PushButton等其他游戏框架。

应当选择你熟悉的语言和框架，这会提高工作效率，缩短开发时间。美术工具的选择也是如此。

platform-framework-language(from gamasutra)

以上所列举的目标平台并非唯一可供选择的平台，但是因为我偏爱在类型严格和面向对象的环境中编写代码（游戏邦注：排除Javascript和LUA），这些平台便是基于这个条件而挑选的。

获得适用平台的游戏框架和一系列工具后，我们就可以进行技术设计。

架构和代码结构

正如情况所示，清晰和结构化的代码比混乱且过于复杂的代码更容易实现平台间的移植。编写代码的首要原则是保持其清晰且有规则。

实现平台间便利移植的关键是构建正确的架构。可以运用所有合适的OOD方法。首先，我们需要创建独立的框架（游戏邦注：即引擎）和游戏逻辑。双层结构便由此形成，独立性从高层次降到低层次。

game assets(from gamasutra)

在每层中，我们细分了平台独立代码和平台专用代码。这两者间的界线或许并不会很清晰。这样做的目标是分离平台专用代码，使其达到最小化。在某些情况下，我们需要在该模块上创建抽象层，但这种抽象层通常已经包含在框架中。

内容工具

正如上文所提到的那样，所述框架使用的都是相同类型的资产，所以在所有平台和框架中可以使用相同的工具。所有的图像资产都以位图为基础，最普遍用于质感、精灵层和动画数据。

设计精灵层和颗粒效果的实用工具有：TexturePacker；Zwoptex；Particle Designer (Mac)；Particle Editor (Windows)。

游戏实体

设计“游戏实体”类的方法也是个重要层面。创意便源生于此，尤其当呈现对象类成为关注点时。

更具体地说，避免基于呈现类（游戏邦注：如AS3中的Sprite或MovieClip以及Cocos2d中的CCSprite）来构建游戏实体类，尽管教程和范例游戏制作中用的是这种方法。在现实的游戏开发中，游戏实体需要保持中立，带有呈现对象的标识。所以游戏实体不是呈现类，而是含有呈现类。

如果处理恰当，框架代码应当能够管理两个独立的列表：一个针对游戏对象，另一个对应它们的呈现对象。应当注意的是，场景图像的处理是在框架内部完成的，与游戏对象无关。

游戏循环如下所示：

1、处理用户输入和游戏状态

2、更新所有游戏对象

3、绘制/渲染呈现列表

移植

游戏能够在主要平台上运行后，就可以准备用Cocos2d从web（游戏邦注：包括Flash和AS3）移植到iOS手机平台上。

移植过程可以总结为下列步骤：

1、转换框架

2、移植游戏代码

3、移植内容（游戏资产）

4、转换成触碰控制

5、调整屏幕大小和语言限制，并针对平台进行优化

在实际操作中，我们需要在目标平台上创建新项目。在本文的例子中，应当是用Cocos2d创建的XCode项目。接下来，开始着手处理游戏代码。

因为游戏内容和逻辑现在完全是中立的，所以将其移植到新项目中应当较为简单，当然语言和句法转换是必要的工作。虽然这是个繁杂的工作，需要逐类完成，但确实是可行的方案。

AS3到Objective-C

将类和代码转换至Cocos2d需要掌握一定的Objective-C知识。为使叙述更加简单，我将省略对语言移植的细节化描述，只是想提下，尽管这两种语言存在差异，但在处理类和OOD的方法是相同的。

编译和调整呈现代码是较为困难的部分。用户控制也是个问题，根据设备所使用的控制类型，游戏的控制应当转化为触碰控制。可以是简单的触碰和拖拽，或者使用更为复杂的虚拟操纵杆和屏幕按键。

呈现细节

每种框架都有自己的呈现对象术语，更换标识可能需要一定量的工作，但是因为呈现代码就位于框架中而且多数都与游戏实体绑定，所以这应当也不会过于困难。

下表呈现的是主要呈现类的转换：

main display classes(from gamasutra)

Flash和Cocos2D所使用的坐标系统有所不同。Flash将屏幕左上角设为坐标原点，Y轴向下延伸，而Cocos2D使用的是OpenGL坐标系统，原点位于屏幕中心，Y轴向上延伸。如果你使用的是Nd2D，则坐标无需转换。

Android移植

将游戏移植到Android上的步骤与上述相同，使用libGDX作为游戏框架。使用ActionScript项目作为来源同时使用iOS项目作为参考或许会更加容易，因为Java从本质上来说更接近于ActionScript而不是Objective-C。

移植到Android上还需要处理许多具体的问题，在这里我不展开。主要想法是，多数游戏代码和内容资产无需修改便可以运行，项目可以利用已经在iOS移植中做过的工作，无需重新编写任何组件。

结论

现在，小型独立工作室也开始计划开发多平台游戏。借鉴了桌面和主机领域的经验，Cocos2D等现代框架可使开发者将单个平台上获得的知识和经验运用到其他平台上。