手机游戏创业团队技术选型大PK

手机游戏引擎之Cocos2D

Cocos2D的稳定性、可商用型和流行程度已无需证明。目前App Store中国区付费总榜前三十名约有50%是基于Cocos2D开发的，几个月来长期如此。因此：

• 只要你是做2D游戏就应该用Cocos2D引擎；
• 根据发布目标平台和团队擅长的编程语言选择不同Cocos2D分支，开源社区尊重每位程序员自己的喜好和口味；
• 不用担心法律和授权费用的问题，Cocos2D及其集成的第三方库都是非GPL/LGPL的；

Cocos2D家族包含了一系列不同语言、不同渲染方案的多个分支，目前稳定成熟、有商业游戏发布的主要有三个：

• Cocos2D-iPhone，用优雅的Objective-C语言进行游戏开发，最近出了JavaScript绑定，游戏只能运行于iOS设备上；
• Cocos2D-X，用经典的C++进行游戏开发，加以Lua绑定和JavaScript绑定，游戏可运行于iOS、Android、 Windows Phone 8、Windows 8 Metro、BlackBerry 10、bada、MeeGo、Linux、Mac OS X等手机和桌面系统上；
• Cocos2D-XNA，用C#进行游戏开发，可运行于Windows Phone 7&8之上。

还有一个分支，虽然目前尚无大型商用游戏，但未来相当看好：

• Cocos2D-HTML5，基于HTML5规范集开发，采用JavaScript语言，游戏可运行在Chrome、FireFox、IE10、Opera等支持HTML5的浏览器内。

表1 Cocosd系列引擎对不同平台和开发语言的支持

Cocos2D系列引擎对不同平台和开发语言的支持如表1所示，注意：虽然有不同分支，但只要是在同一个大版本号1.x或2.x下面，API接口是完全一样的。

采用与开发平台自身相同的编程语言是个不错的选择；但按照目前的趋势，跨平台已经成为一个基本考虑点之一，因此选择具有跨平台能力的开发语言，会让游戏开发和运营更轻松愉快。所以开发语言的选择上，大致可以这么考虑：

• 系统原生语言：例如在iOS上选择Objective-C，在Windows Phone上选择C#，开发时能很方便地集成SDK上的各种功能—原生UI框架以及ShareKit、ASIHttpRequest之类的第三方库，且易 于调试。但游戏无法跨平台，因此现阶段不是太推荐；
• C++：保持高性能的同时可以跨不同平台，调试方便，但开发进度偏慢，集成部分第三方库需要一次语言转换，适合技术功底比较强的小型创业团队，在开发中小型游戏上有优势；
• Lua、JavaScript等跨平台脚本：可以在运行性能和开发速度上取得一个折中，缺点是调试和集成第三方库不易，适合有一两个技术 高手能驾驭语言转换层（需要二次转换，如Java>C++>Lua），然后招聘脚本程序员大量堆逻辑的中型创业团队，而且团队里程序员越多， 使用脚本带来的增益越明显。此方案在开发大型游戏上有进度优势。在工具方面，Cocos2D和多数开源社区一样是个集市，没有建造大教堂思路下集中控制的 一站式解决方案，因此你需要从不同软件提供商手里购买针对不同使用目的的工具，基本覆盖了游戏开发过程的方方面面，比较流行的有：

• CocosBuilder是目前最好的UI编辑器和动作编辑器，拥有开源免费MIT许可。在2.1版本之后加入了大家翘盼已久的时间轴动 作编辑功能。其作者Viktor Lidholt已被Zynga的Cocos2D团队收编，因此CocosBuilder很显然会是整个社区最重要的编辑器之一；
• 71squared的Particle Designer，必不可少的粒子编辑器，8美元一套，还不到买一份肯德基全家桶的钱；
• mapeditor.org的Tilemap Editor，这个是开源免费的；
• Texture Atlas打包工具如Texture Packer、Zwoptex；
• SpriteHelper、LevelHelper系列。

除此之外，还有一些比较新潮但用户不多的工具，例如CatHide.com，让你在一个代码编辑器里完成基于Cocos2D-X的多平台开发调试部 署；还有蛋疼到碎的iTileMaps，让用户在iPad里面编辑tilemap地图，你可以买一套送给美工同学，然后享受他想杀死你的眼神。

社区支持一直是Cocos2D引以为傲的事情。只要你礼貌地在Cocos2D-iPhone或Cocos2D-X论坛里询问，总能得到来自世界某个 角落里热心开发者的解答。除了官方论坛，国内还有39个Cocos2D QQ群，百度文库里4534篇Cocos2D相关文档，SlideShare上196份相关PPT，CSDN下载区701份相关资源，以及海量的技术博 客，都会是你进入Cocos2D开源世界很好的学习资源。

总结Cocos2D开源引擎适合于这样的创业团队：

• 希望和Zynga、Glu、TinyCo、4399等使用Cocos2D的顶尖游戏公司站在同样的技术起跑线上；
• 希望掌握产品的每个细节，且团队中有靠谱的程序员；
• 希望能天马行空作出自己游戏独一无二的效果，不喜欢被闭源产品束缚作出同质化产品；
• 希望针对中国市场特殊性，能不费力地搞定千元智能机上的性能问题。

手机游戏引擎之Unreal

提到虚幻引擎（Unreal），在国内开发者中可能有这样一种认识，它太重、太复杂，不是非常适合初创团队的需求。但实际上，虚幻引擎有不少特性是能够很好地帮助创业团队的，使用虚幻引擎获得成功的创业团队也不少。

例如开发《无尽之剑》的ChAIR团队，他们从创业伊始就一直在使用虚幻引擎。开发《无尽之剑》之前，ChAIR曾做过两款成功的横版射击类游戏 《Undertow》和《Shadow Complex》，每款都有数百万美元的收入。成功的作品也让ChAIR受到了Epic Games的青睐，最终被Epic所收购。即使在开发《无尽之剑》系列期间，ChAIR依然保持着非常小，只有13个人的团队规模。《无尽之剑》系列的游 戏在iOS平台上的收入早已超过3000万美元，推出时被认为重新定义了移动游戏在画面品质上的最高标准，而其第一代产品正是由这13人的团队在非常紧张 的5个月时间里完成的。虚幻引擎之上的高品质表现和极高的开发效率也是至关重要的成功秘诀。

对一个希望以品质取胜的游戏来说，最终的画面效 果能不能充分表现必要的意境和情感，最终的玩法能不能带给玩家最佳的反馈和体验，都可能影响游戏的最终成败。但游戏设计时的预期和最终呈现的效果在开发过 程中往往会有不小的差异，需要美术、程序和策划人员反复的沟通和修正。但无论是当面的交谈还是文档，都没有能力准确表达游戏设计者（美术或者策划）的意 图。这种不准确的沟通形式会导致开发过程中的大量返工，增加迭代次数，从而引发项目延期、成本上升等让人头疼的问题。我们认为为每个参与游戏设计的人提供 可以自己动手实现自己的需求，是解决这个问题的一个有效手段，也是虚幻引擎的一个主要的设计思想。虚幻引擎的开发团队投入了非常大的精力来开发便捷易用的 工具。也正是在虚幻引擎完善的，真正的、所见即所得的可视化工具的协助下，《无尽之剑》开发团队仅用了3周时间就完成了核心玩法的设计，用了4周时间就确 立了美术风格和开发技术标准。而且后期的开发中，也没有因为核心玩法和美术标准方面的因素导致返工或拖延。

虚幻引擎另一个可以帮助开发者降 低开发成本的重要特性就是支持跨平台开发。目前虚幻引擎已经支持了包括Windows、Android、iOS、Flash、Mac OS等11个主流的游戏运行平台。开发者可以完全用一个项目的开发周期和成本，开发瞄准多个发布平台的游戏。美国有一个叫Trendy Entertainment的初创游戏公司用虚幻引擎开发了一款叫《Dungeon Defenders》的多人在线动作类游戏，这款游戏先后发行了PC、Xbox360、PS3、iOS、Android、Flash的版本，取得了相当不 错的成绩。最近，在使用虚幻引擎开发移动平台游戏的开发者中，有了一个新的趋势，就是同时发布iOS和Android的版本。例如Gameloft的 《Wild Blood》和Phospher的《HORN》。虚幻引擎在跨平台方面的便利性，也让这个有利于开发者的趋势变得越来越显著。

最后，再谈一下创业团队都很关心的学习成本和技术支持问题。坦率的讲，在易于上手方面，虚幻引擎并不是做得最好的。但大家一定都会有亲身体会，一个 相机自带 的修图软件通常是很容易上手的，但如果要达到商业级的图像处理效果，使用专业软件是不可避免的，而功能更全面也更强大的专业软件的学习成本一定也会更高。 不过这并不意味着我们不重视开发者的学习成本，在虚幻中有很多细节的考虑都是从易于开发者上手的角度出发的。例如我们的关卡编辑器有两套鼠标与快捷键操作 方式，一套与3ds MAX一致，一套与MAYA一致。因此无论关卡设计者熟悉的是MAX还是MAYA，都有适合他最快上手的选择。另外，我们在国内数十人的工程师队伍，也给 用户带来了培训和技术支持上的最大保障。

对于创业团队选择第三方技术，我觉得根本的原则还是要选适合自己的，适合自己的能力，也适合自己的项目。如果一个3D游戏项目是希望通过高品质取胜，又希望拥有非常高效的开发流程，那虚幻引擎可能会是一个合适的选择。

手机游戏引擎之Unity

刚结束的Unity开发者大会（Unite2012）上，Unity制作的移动平台游戏阵容达到了有史以来的最强点：畅销游戏数量正在步 步紧逼Cocos2D一系，而3D顶级大作的成色也不逊于UDK引擎的作品。这个阵容包括2D和3D的益智、平台、射击、战略、竞速等几乎所有的主流游戏 类型，引擎的成熟性和多样性已不需要更多证明。

不过对于创业团队 来说，Unity并不是必然的选择。开发者首先要面临的问题是可观的授权费 用，Unity虽然有免费的基本版，但想要在iOS或Android平台上发布则各需要400~500美元每人的授权费用。此外还有让人头疼的Unity Pro授权，包括减少App尺寸、自定义Logo画面和编译插件等诱人特性—但想要在iOS或Android上使用这些特性就要额外付出每人3000美元 每人。

第二个问题也同时是Unity最大的优点：Asset Store市场上种类众多的中间件和资源。如果你愿意为快速整合游戏内置购买功能而付出60美元的话，那么很多烦琐的功能整合都可以在很短的时间内实现。 此外还有可视化编程工 具，各种美轮美奂的材质、人物、动画。Unity的Asset Store对于有一定资金支持的团队来说是缩短开发流程，甚至节约成本（相对于外包需求）的重要方式。但反过来看，如果你的团队没有条件或者不喜欢使用第 三方工具和资源，那么很多功能和实现在Unity里就需要很多额外的工夫了。举例来说，和设备Native Code通信方面，Unity就会被Cocos2D完爆，Cocos2D开发者只要调用苹果官方库就能实现的功能，在Unity里却要兜几个圈子。

最后还有Debug方面的不足，Unity游戏在iOS上运行需要使用Mono的架构把游戏代码编译成汇编，然后才能在Xcode里使用。因此 Unity移 动平台游戏无法直接进行真机Debug，只能配合Log和经验来摸索。所以在遇到触屏操作问题和移动设备专用的服务问题时就会特别棘手。

尽管问题多多，很多团队还是把Unity作为了移动开发的首选，这和Unity公司重视技术和开发者群体的运营方式有很大关系。整个Unity社区 的活跃程 度和大量商业化带来的技术支持专业化在目前的市场上看都是独一无二的。加入Unity开发者的阵营不仅能得到一个强力游戏引擎，随之而来的还有大量技术知 识来源，配套的新技术服务，求职创业两不误的人脉群体。

想要最大程度发挥Unity的优势，我建议开发者遵循一个“最速出原型>使用 现成工具补充功能性的不足>重构程序结构>完善完善再完善”的流程。Unity的原型制作流程是非常高效的，而且有着对于美术和设计人员非常 友善的开发环境（有时需要借助一些自定义的编辑器工具），但3D引擎架构的复杂程度决定了如果不及时更新工具或重构代码的话，接近成品时就会有日益臃肿直 至一团糟的可能。只有每隔一段时间整理一次游戏架构，才能保证游戏接近完成时能够随心所欲的完善，以及发售后更新需要的可扩展性。

总结：Unity移动游戏开发适合有一定资金支持的小型到中型团队，如果你重视工具链条的构建（或者购买）以及游戏架构的整理和积累，开发速度和游戏质量都会提升得很快。

手机游戏引擎之Flash AIR

相信大家应该对Flash比较了解，但对于Flash AIR可能就不是那么熟悉了，尤其前阵子Adobe宣布将移动版Flash Player停止维护及开发，就让大家误认为Adobe Flash将退出移动平台。

但实际情况又是如何的呢?

Flash 并不只有Flash Player、Flash IDE等一些大家耳熟能详的产品，实际上“Flash平台”是一个统一的称呼，它其实包括五个方面：运行时（Flash Player和AIR Runtime）、 语言（ActionScript 3和MXML）、框架（Flex、TLF、OSMF等）、开发工具（Flash Pro、Flash Builder等）、周边方案（Alchemy等）。而Flash AIR正是Adobe对于移动平台的定制的重头策略。

Flash AIR最开始是Flash对于桌面应用的支持，在移动开发火热之后，AIR开始转变策略，转而为Flash内容的移动App打包进行支持，因为 Android设备上允许安装AIR运行时，所以采用AIR打包为Android设备部署。Flash应用就变得顺理成章（虽然和桌面相比，内在运作机制 还是很不同的）。当iOS拒绝了Flash Player进入之后，AIR又担负起了将Flash应用部署到iOS设备的重任（因为iOS不允许安装运行时，AIR针对iOS的打包策略和 Android设备上又是完全不同的，需要直接编译出本地可执行代码，但为了统一平台起见，仍归属在AIR的范畴之内）。

现在，Flash AIR的核心策略显然已转变为移动开发，而今年Adobe对AIR的开发支持更是空前的强力。加上Adobe在HTML层面对PhoneGap的投资，可 以看出Adobe在移动策略上采用了Adobe AIR（for Flash）和PhoneGap（for HTML、JavaScript Developer）的双保险策略。

下面我就主要从开发时程、效能、跨平台性来说来说一下Flash AIR对于游戏开发的优缺点。

开发时程。Flash多年经验积累下来，为广大开发者准备了一套非常完备的开发流程，从图形动画制作工具Flash Pro到编码工具Flash Builder的每一点，无不体现出“可视化”、“便捷”等特点，让使用者可以最少编写代码来达到想要得到的效果，更加上不可替代的动画支持，让整个开发 过程锦上添花。而AIR同样享有这一切。随便写一个小特效的话，Flash可能只需要几行代码，而其他语言则可能需要几倍的代码量。

效能，对于Flash而言，效能一直是其非常褒贬不一的地方。事实上，Flash的效能完全取决于使用者的优化水平，因为Flash为使用者提供了 尽可能多的图 形图片处理方式，这就需要使用者有能力去衡量每一种方式的适用情况。更加上Flash Stage3D已经可以在移动平台调用GPU，Flash的效能就更加得以提高。在iOS平台上，如果优化得当的话，是可以接近Object-C的效能 的。

跨平台性来讲，Flash也是十分优秀的，PC、Android、IOS、BlackBerry、Windows Phone(未来支持)，全都可以用同一个SWF文件去发布，这意味着我做了一个应用就可以轻松发布到其他平台，也省去了移植的一些工作量。

对于以上的几点综合来看，我决定选择使用Flash AIR技术。而对于Object-C与Java而言，虽然性能出众，却没有很好的跨平台性支持，而HTML5则由于还是新技术，可能存在许多隐患，制作流程上也显得不够成熟。

事实证明，我的选择是对的，一个版本可以成功打包成很多平台的应用这让我欣喜若狂，而且对于游戏来讲，一般的2D游戏AIR运行起来也是没有压力的，效能也不用很担心。

下面说说关于优化方面需要注意的事情，前文说过，Flash AIR技术需要比较好的图形优化能力，其实就是对于图形图像算法的理解能力，精确运用滤、颜色叠加、动画、动画层次以及内存等元素可能是需要开发者注意 的。此外还有关于内存的处理，Flash技术把内存做了很智能的处理，不需要用户太关心内存回收，但是也因为如此，内存回收变成了一个不可控的元素，我们 需要积极地将用不到的对象的引用消除以保证能够尽快回收。

自从ActionScript出现以后，Flash便成为了小游戏的最佳选择，快 速的制作流程以及丰富的动画支持变成了Flash技术的利刃。这么多年下来，众多Flasher创造了不计其数的Flash小游戏，后来还有很多优秀的游 戏转移到了其他大型平台，并且销量非常好。这些年，Flash积累了无数的经验及产品，而这些所有的东西都会直接移植到AIR技术上，就让AIR制作游戏 更加如虎添翼。

选择何种技术很重要吗？

很多游戏制作者都喜欢关注游戏使用了哪些技术、用了什么框架等，但事实上玩家完全不会在乎哪一款游戏是用了什么引擎、框架、设计模式，甚至不是很在乎到底是谁制作了这款游戏。

作为游戏开发者，我们要把时间更多地投入在如何让游戏更受大家喜欢，如何让游戏更有内涵或者更耐玩，而对于收费游戏来讲，我们可能要考虑如何让大家很开心的付费。要知道，技术不怎么样但很卖座的游戏其实是不在少数的。

对于技术而言，不用非要追求最好，而是恰当就好，选择最适合的最利于目前开发的项目的技术是最佳选择。

千万不要小看市场

经常有人说：“《Angry Birds》很简单，我们也能做！”之后就几个人开始做一款山寨的小鸟、《Fruit Ninja》，又或是一些别的什么游戏。我个人对于这种尝试还是比较赞成的，因为一旦做了就会获得经验，这样对开发者个人而言是只有好处没有坏处的。

但我想说的是，千万不要小看市场，我们的市场很挑剔，每一个作品都追求精益求精，并不是随便哪个游戏都能够赚钱，不是随便凭借山寨一个什么产品就能 够成为 “高富帅”。这个圈子里的赚到钱的人都是在非常努力地做产品，当然不排除有些开发商采用一些投机的方法去谋利，但如果想要真正在市场站住脚的话，还是需要 一定的积累跟实力的。

事实上，有很多开发者连每年支付给苹果的开发者授权费都赚不回来，因此做游戏别太冲动，一切三思而后行。

精准把握玩家行为

我觉得我们需要花费精力去分析玩家行为，这样我们就能对玩家对于某些操作或游戏模式的反应做出正确的判断，也能帮助我们设计出更人性化的游戏，增加游戏的用户黏性，从而让更多的玩家不仅能够接受我们的游戏，还能够长期玩我们的游戏，这样自然也就带给我们想要的利润。

踏实做游戏

很多团队做游戏时就会想到以后会赚多少钱、如何发达等，但只要一旦这样想，就容易走入某些奇怪的误区里，我们还是需要冷静去面对游戏制作的每一个部分，这样才有更多的机会脱颖而出。

团队向心力

团队向心力是比较不好处理且经常出问题的环节，它可能包含了比较多的可能性，例如分配不均，或者内部分裂，又或是由于成员能力不足等原因带来的问题。可能任何一点小小的问题都会导致整个团队分崩离析。