作者：Amos Laber

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

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

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

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

框架和平台差异

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

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

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

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

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

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

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

架构和代码结构

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

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

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

内容工具

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

设计精灵层和颗粒效果的实用工具有：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的方法是相同的。

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

呈现细节

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

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

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

Android移植

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

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

结论

现在，小型独立工作室也开始计划开发多平台游戏。借鉴了桌面和主机领域的经验，Cocos2D等现代框架可使开发者将单个平台上获得的知识和经验运用到其他平台上。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Jumping from web to mobile: Planning and building a Flash to iOS game

Amos Laber

This is a continuation of my previous post Jumping from Web to Mobile, Part 1 about planning a multi-platform game.

Here I will present a blueprint for an actual port of a specific game project. This is a typical 2D game that feature scrolling backgrounds, animated characters, and touch (or mouse) controls. This should give an overview to the practical aspects of planning and building a game on Flash as the primary platform and iOS as the secondary, with possible porting to Android later on.

Choosing Flash as the primary platform enables experienced Flash developers to take advantage of the quick designer-to-developer tooling available, namely Adobe Flash Builder and Flash CS, to easily setup gameplay code over a framework, and create a quick prototype of the game before spending more resources on porting to mobile.

Although this is a subjective choice I made, it makes more sense to start developing on a desktop environment, as iOS developers often do, to achieve shorter development cycles.

There are few different options for going mobile from Flash, the first is Adobe AIR mobile. Adapting a game to AIR requires very little code changes and it deploys to a wide range of mobile platforms. AIR has its advantages, and while it may be the right choice for some projects, it is not in the scope of this article – the focus here is on using native code for mobile.

Frameworks and platform differences

In recent years, a new breed of modern game frameworks has emerged and is gaining popularity among game developers. Most of them free and open source, they borrowed practices from web, desktop, and mobile platforms and include an impressive array or out of the box features.

Such frameworks are Cocos2d and Sparrow for iOS, and Starling and ND2D for Flash. Starling is actually a port of Sparrow, using almost identical class names, while ND2D is closer to Cocos2d in style.

Regarding content, all of them use the same asset types for images and animation, which make the game content portable when switching between one framework to another. This includes sprite sheets, animation data files and particle effect data (in json and xml).

As a side note, both Starling and ND2D use the hardware accelerated GPU rendering (Stage3D) available in Flash 11. In some cases, developers opt for the software renderer to target wider range of users – and use their own custom framework that supports blitting, or alternative game frameworks like Flixel, FlashPunk and PushButton.

Whatever choice is made, being comfortable with the language and framework you use translates directly to efficiency and shorter timelines. The same goes for art tooling.

The above list of target platforms is by no means the only choice for the the platform, but it’s a choice based on my own preference to code in a strict typed, object-oriented environment (sorry, Javascript and LUA).

Armed with a game framework for the platform and a set of tools we are ready to move on to technical design.

Architecture and code structure

As it turns out, clean and structured code is much easier to port than messy, over complicated one. Rule #1 is keep it clean.

The key for easy porting between platforms is building the right architecture. All the proper OOD methodologies apply, and most of all encapsulation and minimizing dependencies. First we need to create a separation between framework (engine) and game logic. These form the two tier architecture where dependencies goes from higher level to lower level modules.

Within each tier, we make a subdivision between platform independent code and platform specific code. This may not be clear cut. The goal is to isolate the platform specific code and keep it to minimum. In some cases we need to create an abstraction layer over that module, but usually this abstraction is already in place in the framework.

The content tools

As already mentioned, the said frameworks all use the same type of assets, so the same tools can be used across platforms and frameworks. All graphical assets are bitmap based and the most common use is for textures, sprite sheets and animation data.

Here are a few good tools for packing sprite sheets and designing particle effects: TexturePacker; Zwoptex; Particle Designer (Mac); Particle Editor (Windows).

The game entity

Another important aspect is the way we design a ‘game entity’ class. Composition is preferred to inheritance here, specially when display object classes are concerned.

To be more specific: avoid basing your game entity class on a display class (like Sprite or MovieClip in AS3 and CCSprite in Cocos2d), as its commonly being done in tutorials and sample demos. In real life games, the game entity need to remain neutral and hold a reference to its display object. So instead of the game entity ‘is -a’ display class, it would be a ‘has-a’ relationship.

When done properly, the framework code should manage two separate lists: one for game objects and one for their corresponding display objects, which would be the display list, or scene graph. Note that processing the scene graph (i.e. draw code) is done internally by the framework and never by the game objects.

The game loop would look like that:

process user input and game state

update all game objects

draw/render the display list

Making the move

Once the game is up and running on the primary platform, it is ready to be ported from web (Flash / AS3) to the first mobile platform: iOS with Cocos2d.

The process of porting can be summarized in the following steps:

Switching the Framework

Porting the Game code

Porting the contents (game assets)

Converting to touch controls

Adjusting to screen size, language constrains and specific platform optimization

Practically we need to create a new project on the target platform and start with the Framework. In this case it would be an XCode project with Cocos2d. The game code comes next.

Since the game contents and logic are now completely neutral, and porting it into the new project should be straight forward – of course language and syntax conversion should be made. While this can be a tedious job going class by class, it is very much doable.

AS3 to Objective-C

Converting classes and code to Cocos2d requires some knowledge in Objective-C. For simplicity, I’ll skip the detailed description of language porting, and just state that while there are a few differences, both languages are close in the way they handle classes and OOD. For those interested in this topic I recommend this excellent tutorial by Rogers Engelbert.

The hard part is getting it to compile, and adjusting the display code. Another issue is user controls: depending on the type of controls used, they should be converted to touch controls. These can be simple touch and drag, or more complex, like a virtual joy-pad and on screen buttons.

Display specifics

As each framework uses its own terminology of display objects, it may require some amount of work in replacing references, but since the display code is well contained in the framework and mostly referenced by the game entity, that should not be too difficult.

Following is a simple conversion of the main display classes in pure AS3 and ND2D and their equivalents in Cocos2d:

Coordinate systems are different between Flash and Cocos2D. Flash uses the top left corner as origin with Y-down, while cocos2d uses the OpenGL coordinate system, where the origin is at the center and Y-up. If you used Nd2D, there is no need for conversion of coordinates.

More mobile: Android

The same process applies for Android, using libGDX as the game framework. It may be easier to use the ActionScript project as the source and use the iOS project as a reference, since Java is closer in nature to ActionScript that to Objective-C.

There are plenty of Android specific issues to address, but I will not discuss them here. The main idea is that most of the game code and content (assets) will work almost without change and the project can leverage the work that was already done in the iOS port without having to rewrite any of the components.

Conclusion

Planning a game to be deployed on multiple platform is now within reach for small, indie studios. With borrowed practices from the desktop and console space, modern frameworks such as Cocos2D allow a team of developers to leverage knowledge and expertise gained in one platform to be applied on other platforms. (Source: Gamasutra)