做游戏首先是要选择一款引擎，重新发明轮子自己开发一个引擎不是一般小团队能搞得定的。就算有这个技术实力，未必有这个时间去开发；就算费时费力开发出来了，也难以保证在诸多手机平台的兼容性和稳定性；就算你的引擎很好很稳定，也还有人才培养的问题，因为你是招不到熟悉自研引擎的人的，只能自己培养，而又有多少工程师愿意去学习一个非主流的引擎呢？所以我们还是不考虑这个选项了。
现在国内做手机游戏比较主流的引擎就是cocos2dx和unity3d。选择哪个取决于要做的游戏类型和团队的特点。下面比较一下这两个引擎：
2D还是3D？
如果做2D游戏，选择cocos2dx和unity3d都可以，如果做3D游戏，那就只能选unity3d了。虽然cocos2dx3.0开始也支持3D，但和unity3d不是一个级别的，无论是设计理念，成熟度，便利性，三方工具支持都差很远，只能用做教学目的，如果要商用还需要大量开发工作。跨平台
两款引擎都支持主流的移动平台。cocos2dx由于是开源的，当遇到一些平台问题时可以通过自己修改源代码修复，unity3d就只能等官方更新。这是cocos2dx的优势，例如这次苹果要求2015年2月1日后提交的版本必须支持arm64，使用cocos2dx的开发团队通过少量修改重新编译就可以支持arm64，而unity则必须等官方的4.6或5。开发环境
cocos2dx主要使用c++开发，开发团队必须是精通c++的。在C++之上可以选择Lua,JS等脚本语言，在集成IOS平台的时候需要用到 objective-c，在集成Android平台是需要用到Java/JNI，发布的android版本还需要写make file。在开发过程中你会经常遇到编译错误，Link错误，莫名其妙奔溃。 所以cocos2dx的开发环境的搭建和配置是比较复杂的。 u3d的开发环境就是u3d自己的编辑器，语言可以使用C#、JS、Boo，编辑器可以用自带的MonoDevelop，或者VS。unity的程序发布比较方便，IOS发布会自动生成xcode工程，然后在xcode中编译打包；Android设置了Android SDK后直接可以打包APK。总体来说unity在环境配置上要简单很多，也省不少时间，对团队的工程技术要求也相对要低一些。不过做手游你总是会接触到IOS和Android的原生开发的，引擎不可能考虑到你所有的需求，而且后面需要接入统计，第三方平台等大量的SDK，这些SDK可能只有OC版或者Java版本。因此并不是说用unity做2D手游就可以降低团队要求。引擎控制
cocos2dx开源，可以根据游戏具体需要修改。u3d不开源，无法修改。这是cocos2dx最大的一个优势。但这个优点也是针对有能力的团队而言的，如果没有能力或者人力去修改维护，开源就意味着暴露了太多实现细节，升级维护困难。例如一个现有的工程，从u3d 4.5升级到4.6可能只要用新版本打开一下工程就自动完成了，如果是用cocos2dx的话就呵呵了，很多API可能都改了，你需要解决一堆编译错误。开源免费没有好的support是很正常的，国际惯例。免费给你用的你还想怎么样？工具集
cocos2dx的工具集比u3d弱很多。cocos2dx因为做2D游戏，本身需要的工具也不是很多，一般也就需要一个UI编辑器和一个骨骼动画编辑器，官方的cocostu@R_404_410@提供了这两个编辑器。我用下来的感觉是bug和限制多，不开源不好改，不是很喜欢，但是除非自己开发又没有什么好的选择。做2D骨骼动画有朋友用Spine，据说很好很强大。u3d的工具和插件那是太多了，而且很多都很好，使用方便，功能完善，可视化，可以在Unity Asset Store上买到，这些插件可以极大地提高开发效率，而且大部分是附带源代码的，你还能从中学到很多。付费的东西就是好啊。。。工欲善其事必先利其器，这些插件还是值得去买的。比如UI插件的NGUI，动画工具iTween,制作武器拖尾（刀光）效果的Pigeon Coop Better Trails，制作AI的行为树插件Behavior Designer，AI寻路插件Astar Pathfinding等。开发效率
由于u3d是可视化的集成开发环境，并且插件众多，主要使用C#/JS开发，因此开发效率上比cocos2dx要高。在整个游戏的开发过程中，写代码可能只占到了一半的时间，很多时候是在改bug和数值调整上。在bug修复方面，u3d至少有两个三个优势：1 .Net平台异常捕获机制比较完善，很多时候程序一跑错误就直接在控制台输出了，诸如空指针异常这种常见错误直接就避免了，不像用cocos2dx经常是crash，然后再找。2. Debug方便，u3d的MonoDevelop可以直接Attach到unity进程上然后设置断点debug。cocos2dx如果有win32的版本也可以在vs里面设置断点debug，但是如果使用了Lua或JS等脚本语言，就无法debug了。有人会说脚本需要debug吗？从我的经验看能debug找bug会方便很多。3. 场景树可视化，u3d运行时场景中所有的东西都可以在场景树中找到选中，然后在Inspector面板可以看到上面的变量和状态，游戏可以随时暂停，你可以慢慢找问题。这是cocos2dx无法提供的。自更新
一般的手游都需要通过自动更新来修复bug和做一些活动。这块cocos2dx+lua/js做的比较好。cocos2dx通过自带的AssetsManager可以做到从美术资源到脚本代码的增量更新。而u3d这块比较麻烦，u3d只能更新资源，而不能更新代码。所以要实现代码的自动更新，只能把代码也变成资源。通常有两种做法，一种是划分好模块，把经常要变的代码编到独立的dll中，通过C#反射来调用，dll作为资源来更新。另一种是使用.net版的Lua解析器，程序逻辑用Lua来写。但无论哪种方法都会牺牲u3d编辑器开发的便利性。代码保护 如何防止游戏被破解或者山寨是很多老板都关心的问题。cocos2dx因为是中国团队开发的，这块自然很接地气。如果是纯c++开发的游戏，代码的保护就不用考虑了。如果是用Lua开发的，可以选择编译成Lua字节码，或者直接对脚本加密。cocos2dx官方提供了xxtea加密，用起来很方便。u3d就没怎么好弄了，u3d生成的.net dll可以直接通过.Net Reflector反编译出源代码。一般对于.Net程序的保护是使用代码混淆，但是因为u3d脚本中Awake，Start等方法的名字是不可以改变的，所以不能混淆u3d的dll。当然办法还是有的，至少可以把变量名混淆了吧，哈哈哈，所以有人写了个叫Obfuscator的插件用来混淆变量名，CodeGuard好像连函数名也可以混淆。也有人把核心代码分到单独的库里面混淆，不过我觉得为了混淆代码而改变程序设计有点不值得。因为如果高手真的要看你代码，你以为混淆一下就有用了么？ 一款手游成功的因素有很多，玩法，美术，技术，上市时机，商业运作，发行商，运营能力等等，看过几行代码就可以复制了么？所以我觉得还是多想想怎么做好游戏吧。
