前段时间关于Unity是否适合国内手游/网游创业团队的讨论非常火爆，本文从《蒸汽之城》的开发历程谈起，对于国内网游团队是否应该选择Unity引擎，以及如何解决使用Unity开发网游时遇到的各种主要问题进行讨论。

1

《蒸汽之城》是厦门梦加网络的第一款作品，使用Unity引擎制作的蒸汽朋克风3D实时战斗MMORPG页游。游戏拥有幻想工业时代恢弘苍凉的场景;丰富的种族、职业和技能系统;和端游比也毫不逊色的优质画面和特效;各式各样的副本挑战和PvP活动;最后，所有这一切用户都能直接在浏览器中以极短的下载时间享受到。《蒸汽之城》被包括福布斯、Massively、ZAM等知名媒体列为2013年最值得期待的MMORPG游戏之一，目前已经签约了多家海外发行商，范围覆盖所有英语国家、东欧、土耳其和中东。土耳其版本已经于3月1日(北京时间)正式开始公开测试。

中文官网已经正式开放：www.mengjiagames.com

梦加团队当初选择Unity引擎的原因和大部分团队类似，快速出原型、大量现成的内置功能和中间件、支持在浏览器里展示高素质的3D游戏画面。在几年的开发过程中团队才慢慢认识到用Unity开发MMO页游需要克服太多问题和陷阱。幸运的是我们最终克服了绝大部分问题，《蒸汽之城》也即将开始海外公测。下面我们会深入探讨要完成一个高素质的Unity页游MMO，应该解决哪些技术问题和怎样建设团队。

请注意，这里我们不会讨论使用Unity制作单机游戏，因为Unity单机或者有社交功能的手游都有太多成功的巨无霸例子，很多开发者也通过自身经验表明小团队使用Unity制作轻量级的单机或社交游戏并无太大障碍(游戏列表可以查看官网：http://unity3d.com/gallery/made-with-unity/game-list)，下面我们还是以多人在线，需要后台和大量数据处理的MMORPG为例来讨论。虽然梦加到目前为止都一直在开发浏览器版本的游戏，但其中很多技术话题对于多人手游项目也同样适用。

从传统页游到次世代技术

虽然Unity已经有了7年多的历史，这款引擎从诞生之初就一直保持了比较先进的设计理念，包括其一直以来的首要卖点：为开发者提供基于浏览器的高素质3D游戏解决方案。Unity的特色既包括面向独立开发者的快速原型、低成本跨平台发布，也在近年来整合了更多高端商用的中间件和次世代的渲染技术。使用Unity现在已经可以开发素质几乎达到用Unreal Engine、CryEngine这些次世代引擎开发的游戏，Unity也被越来越多的AAA工作室选用来开发跨平台的主机游戏。

这意味着Unity很好很强大，没错，但不代表团队选择Unity就是理所当然的。商用引擎的一大特点是兼容并包，要适合各种不同的项目和团队需要，而作为次世代引擎，其中又包括了大量图像、动画和资源管理的先进技术。对于初创团队来说，选择Unity虽然得到了一大堆可以快速见效的功能，但面对这些功能时如何取舍，以及对引擎技术的理解和挖掘程度，都会对项目的命运造成决定性的影响。

Unity虽然一直以易上手、原型快速、中间件丰富整合快速著称，但随着项目规模和复杂程度的上升，很快开发团队就会进入一块网上各种单机游戏教程无法涵盖的真空地带，而国内网游技术分享的环境又相对比较薄弱，这时在一些关键的技术难题上，初创团队就会遇到很大的麻烦。从快速原型到攻克大规模项目的技术难题之间，通常是让很多团队无法正确估计成本的危险过渡地带。这也是很多使用Unity的项目结果反而不如使用自主开发的引擎或相对老旧引擎的原因。自主引擎任何功能都要自己开发，相对老旧的引擎功能较为局限，所以在内容和功能规模方面的计划一般不会太过狂放;而Unity这样的引擎包括从官方和社区的宣传上都给人一种到处都是随手可得的免费午餐的感觉，反而会让团队的计划更加激进，对困难认识不足。

下文中我们会对这些危险和解决方案进行逐一的分析，希望能给经验不足的团队提供警示和提前准备好解决问题的思路。

内容规模和版本控制

开发者在不同类型和规模项目的经验，很大程度上造成了对”Unity是否适合手游/页游创业团队“这一讨论两极分化的看法。对于以Temple Run、亡灵杀手等游戏为榜样的单机游戏开发者，以及CSR Racing这样有多人对战模式的单机游戏，即使团队很小使用Unity开发都不会遇到什么太大的问题。这些单机游戏非常适合发挥Unity游戏性成型快的优势，而内购、社交等功能都可以用现成的中间件来快速实现。

当使用Unity制作有海量内容的网游时，团队遇到的第一个问题，就是无法把游戏的全部内容放进一个Unity项目中。一方面资源文件数量达到一定程度后，每次开启项目的导入过程就够你泡壶茶;另外几十人的团队共用一个项目，在版本控制和数据安全性方面也会有很大的危险，任何人的操作失误都可能导致整个项目瘫痪;最后不同分工的开发者需要面对的项目数据和工作流程差别很大，共用同一个项目会在很大程度上降低生产效率。

《蒸汽之城》使用了很多个Unity项目来为各个不同的部门和小组提供定制的数据范围，工具和流程。3D角色美术的项目里只使用角色数据(FBX->Prefab)和相关的预览和打包工具;场景美术使用不同的项目来管理不同的场景;客户端程序员使用的是主要的客户端项目，他们的代码运行后可以读取其他开发者上传到服务器上的数据，从而让游戏跑起来。而大部分开发者可以使用编译成可执行文件的客户端来测试自己随时向测试服务器上上传的资源和设计数据，从而既保证了每个人能最高效在自己的领域里工作，又保证了自己生产的内容能够随时在游戏版本中测试。

如此多的项目要怎样实现版本控制呢?我们的解决方案是用Gitlab作为统一的管理平台，每个项目作为一个单独的Git Repository(仓库)。使用Git的最大优势在于客户端项目的版本管理，客户端项目随时都有多名程序员在提交代码，使用Git就能让他们把测试代码和稳定代码通过不同分支(Branch)来管理。我们使用master分支作为稳定的版本，来合并每个程序员提交并测试通过的个人测试分支;整个团队使用的可执行客户端用master分支来编译创建，就保证了新功能开发的速度和主版本的稳定性。

另一个优势在于Submodule的使用，通过Git的submodule功能我们可以在不同项目中共享一份核心的底层代码和部分工具代码，这样就不用为每个项目分别进行游戏引擎和工具更新。Git作为目前最先进的分布式版本控制系统，在掌握难度上是非常高的。国内网游团队即使是程序部门使用Git作为版本控制系统的情况也不是太多，而梦加做到整个团队都用Git作为日常的版本控制系统，付出的努力虽高，但回报绝对物有所值。

数据处理和工具开发

近期的讨论中很多人认为Unity的短板之一在于偏重代码驱动的引擎没有办法处理大批量的数据，这种印象可能跟官方和社区对于那个运行超级方便、什么工作都能往里放的MonoBehavior类的大力宣传和依赖有关。实际上Unity里除了MonoBehavior还有使用.NET标准的自定义类，有用法非常灵活的统一数据类型ScriptableObject，还有各种各样只有你想不到没有你做不到的编辑器脚本和数据处理接口。只不过除了MonoBehavior，其他一切数据处理手段都需要开发者去Unity的官方论坛和StackOverflow这样的泛编程问答站点深入挖据。官方论坛上通过搜索，其实是能找到很多使用Unity做大数据量网游的同行讨论的，只不过这样的引擎在国内还没有形成很大规模的知识分享社区，一些做的比较久的中文Unity论坛也缺乏网游项目的讨论，所以给人的印象就是Unity不擅长做这个。

事实上，Unity处理各种数据类型(XML，Json，SQL)都有现成的接口(用户提供和分享的开源代码)，而《蒸汽之城》策划团队日常使用Excel格式的数据配置，也可以很容易的转化成XML后通过编辑器脚本导入Unity。最后客户端只要读取和处理导入后的ScriptableObject就可以了，一些改动频繁的数据还可以直接使用XML格式在运行时读取，减少客户端需要更新的频率。

说到数据处理使用的编辑器脚本，这里就必须要探讨工具链开发的问题。对于任何大型项目，开发配套工具都是至关重要的，Unity的特色在于编辑器本身有着非常优秀的可扩展性，所以我们使用的工具链包括编辑器脚本和外部工具两部分，分别用来处理客户端和服务器端需要的数据。比如任务逻辑和对话的编辑器是直接编辑数据库的，所以我们使用VC制作的外部编辑工具。而包括关卡、资源导入、贴图合并、NPC角色打包等等要处理Unity使用的资源数据的工具，都是使用Unity脚本制作，开发者通过菜单命令就可以快速完成资源管线操作和编辑。

一款数据量很大的网游在工具开发和维护方面需要投入的力量是很大的，《蒸汽之城》在增加了工具开发的人手后，其他开发和资源生产部门的工作效率都得到了显著的提升。此外通过不断改善工具的可用性，加入大量对用户操作的预先检定，可以有效的减少操作失误造成的数据错误，提高了游戏版本的稳定性。