《Unity网游开发生存指南—蒸汽之城》由会员分享，可在线阅读，更多相关《Unity网游开发生存指南—蒸汽之城（9页珍藏版）》请在金锄头文库上搜索。
1、Unity网游开发生存指南 蒸汽之城前段时间关于 Unity 是否适合国内手游/网游创业团队的讨论非常火爆，本文从蒸汽之城的开发历程谈起，对于国内网游团队是否应该选择 Unity 引擎，以及如何解决使用 Unity开发网游时遇到的各种主要问题进行讨论。厦门梦加的蒸汽之城蒸汽之城是厦门梦加网络的第一款作品，使用 Unity 引擎制作的蒸汽朋克风 3D 实时战斗 MMORPG 页游。游戏拥有幻想工业时代恢弘苍凉的场景;丰富的种族、职业和技能系统;和端游比也毫不逊色的优质画面和特效;各式各样的副本挑战和 PvP 活动;最后，所有这一切用户都能直接在浏览器中以极短的下载时间享受到。蒸汽之城被包括福布斯
2、、Massively、ZAM 等知名媒体列为 2013 年最值得期待的 MMORPG 游戏之一，目前已经签约了多家海外发行商，范围覆盖所有英语国家、东欧、土耳其和中东。土耳其版本已经于 3 月1 日(北京时间)正式开始公开测试。梦加团队当初选择 Unity 引擎的原因和大部分团队类似，快速出原型、大量现成的内置功能和中间件、支持在浏览器里展示高素质的 3D 游戏画面。在几年的开发过程中团队才慢慢认识到用 Unity 开发 MMO 页游需要克服太多问题和陷阱。幸运的是我们最终克服了绝大部分问题，蒸汽之城也即将开始海外公测。下面我们会深入探讨要完成一个高素质的 Unity 页游 MMO，应该解决哪
3、些技术问题和怎样建设团队。请注意，这里我们不会讨论使用 Unity 制作单机游戏，因为 Unity 单机或者有社交功能的手游都有太多成功的巨无霸例子，很多开发者也通过自身经验表明小团队使用 Unity制作轻量级的单机或社交游戏并无太大障碍(游戏列表可以查看官网：http:/ MMORPG 为例来讨论。虽然梦加到目前为止都一直在开发浏览器版本的游戏，但其中很多技术话题对于多人手游项目也同样适用。从传统页游到次世代技术虽然 Unity 已经有了 7 年多的历史，这款引擎从诞生之初就一直保持了比较先进的设计理念，包括其一直以来的首要卖点：为开发者提供基于浏览器的高素质 3D 游戏解决方案。Unity
4、 的特色既包括面向独立开发者的快速原型、低成本跨平台发布，也在近年来整合了更多高端商用的中间件和次世代的渲染技术。使用 Unity 现在已经可以开发素质几乎达到用 Unreal Engine、CryEngine 这些次世代引擎开发的游戏，Unity 也被越来越多的 AAA 工作室选用来开发跨平台的主机游戏。这意味着 Unity 很好很强大，没错，但不代表团队选择 Unity 就是理所当然的。商用引擎的一大特点是兼容并包，要适合各种不同的项目和团队需要，而作为次世代引擎，其中又包括了大量图像、动画和资源管理的先进技术。对于初创团队来说，选择 Unity 虽然得到了一大堆可以快速见效的功能，但面对
5、这些功能时如何取舍，以及对引擎技术的理解和挖掘程度，都会对项目的命运造成决定性的影响。Unity 虽然一直以易上手、原型快速、中间件丰富整合快速著称，但随着项目规模和复杂程度的上升，很快开发团队就会进入一块网上各种单机游戏教程无法涵盖的真空地带，而国内网游技术分享的环境又相对比较薄弱，这时在一些关键的技术难题上，初创团队就会遇到很大的麻烦。从快速原型到攻克大规模项目的技术难题之间，通常是让很多团队无法正确估计成本的危险过渡地带。这也是很多使用 Unity 的项目结果反而不如使用自主开发的引擎或相对老旧引擎的原因。自主引擎任何功能都要自己开发，相对老旧的引擎功能较为局限，所以在内容和功能规模方面
6、的计划一般不会太过狂放;而 Unity 这样的引擎包括从官方和社区的宣传上都给人一种到处都是随手可得的免费午餐的感觉，反而会让团队的计划更加激进，对困难认识不足。下文中我们会对这些危险和解决方案进行逐一的分析，希望能给经验不足的团队提供警示和提前准备好解决问题的思路。内容规模和版本控制开发者在不同类型和规模项目的经验，很大程度上造成了对”Unity 是否适合手游/页游创业团队“这一讨论两极分化的看法。对于以 Temple Run、亡灵杀手等游戏为榜样的单机游戏开发者，以及 CSR Racing 这样有多人对战模式的单机游戏，即使团队很小使用Unity 开发都不会遇到什么太大的问题。这些单机游戏
7、非常适合发挥 Unity 游戏性成型快的优势，而内购、社交等功能都可以用现成的中间件来快速实现。当使用 Unity 制作有海量内容的网游时，团队遇到的第一个问题，就是无法把游戏的全部内容放进一个 Unity 项目中。一方面资源文件数量达到一定程度后，每次开启项目的导入过程就够你泡壶茶;另外几十人的团队共用一个项目，在版本控制和数据安全性方面也会有很大的危险，任何人的操作失误都可能导致整个项目瘫痪;最后不同分工的开发者需要面对的项目数据和工作流程差别很大，共用同一个项目会在很大程度上降低生产效率。蒸汽之城使用了很多个 Unity 项目来为各个不同的部门和小组提供定制的数据范围，工具和流程。3D
8、角色美术的项目里只使用角色数据(FBX-Prefab)和相关的预览和打包工具;场景美术使用不同的项目来管理不同的场景;客户端程序员使用的是主要的客户端项目，他们的代码运行后可以读取其他开发者上传到服务器上的数据，从而让游戏跑起来。而大部分开发者可以使用编译成可执行文件的客户端来测试自己随时向测试服务器上上传的资源和设计数据，从而既保证了每个人能最高效在自己的领域里工作，又保证了自己生产的内容能够随时在游戏版本中测试。如此多的项目要怎样实现版本控制呢?我们的解决方案是用 Gitlab 作为统一的管理平台，每个项目作为一个单独的 Git Repository(仓库)。使用 Git 的最大优势在于客
9、户端项目的版本管理，客户端项目随时都有多名程序员在提交代码，使用 Git 就能让他们把测试代码和稳定代码通过不同分支(Branch)来管理。我们使用 master 分支作为稳定的版本，来合并每个程序员提交并测试通过的个人测试分支;整个团队使用的可执行客户端用 master分支来编译创建，就保证了新功能开发的速度和主版本的稳定性。另一个优势在于 Submodule 的使用，通过 Git 的 submodule 功能我们可以在不同项目中共享一份核心的底层代码和部分工具代码，这样就不用为每个项目分别进行游戏引擎和工具更新。Git 作为目前最先进的分布式版本控制系统，在掌握难度上是非常高的。国内网游团
10、队即使是程序部门使用 Git 作为版本控制系统的情况也不是太多，而梦加做到整个团队都用 Git 作为日常的版本控制系统，付出的努力虽高，但回报绝对物有所值。数据处理和工具开发近期的讨论中很多人认为 Unity 的短板之一在于偏重代码驱动的引擎没有办法处理大批量的数据，这种印象可能跟官方和社区对于那个运行超级方便、什么工作都能往里放的MonoBehavior 类的大力宣传和依赖有关。实际上 Unity 里除了 MonoBehavior 还有使用.NET 标准的自定义类，有用法非常灵活的统一数据类型 ScriptableObject，还有各种各样只有你想不到没有你做不到的编辑器脚本和数据处理接口。
11、只不过除了 MonoBehavior，其他一切数据处理手段都需要开发者去 Unity 的官方论坛和 StackOverflow 这样的泛编程问答站点深入挖据。官方论坛上通过搜索，其实是能找到很多使用 Unity 做大数据量网游的同行讨论的，只不过这样的引擎在国内还没有形成很大规模的知识分享社区，一些做的比较久的中文 Unity 论坛也缺乏网游项目的讨论，所以给人的印象就是 Unity 不擅长做这个。事实上，Unity 处理各种数据类型(XML，Json，SQL)都有现成的接口(用户提供和分享的开源代码)，而蒸汽之城策划团队日常使用 Excel 格式的数据配置，也可以很容易的转化成 XML 后通
12、过编辑器脚本导入 Unity。最后客户端只要读取和处理导入后的ScriptableObject 就可以了，一些改动频繁的数据还可以直接使用 XML 格式在运行时读取，减少客户端需要更新的频率。说到数据处理使用的编辑器脚本，这里就必须要探讨工具链开发的问题。对于任何大型项目，开发配套工具都是至关重要的，Unity 的特色在于编辑器本身有着非常优秀的可扩展性，所以我们使用的工具链包括编辑器脚本和外部工具两部分，分别用来处理客户端和服务器端需要的数据。比如任务逻辑和对话的编辑器是直接编辑数据库的，所以我们使用 VC 制作的外部编辑工具。而包括关卡、资源导入、贴图合并、NPC 角色打包等等要处理Uni
13、ty 使用的资源数据的工具，都是使用 Unity 脚本制作，开发者通过菜单命令就可以快速完成资源管线操作和编辑。一款数据量很大的网游在工具开发和维护方面需要投入的力量是很大的，蒸汽之城在增加了工具开发的人手后，其他开发和资源生产部门的工作效率都得到了显著的提升。此外通过不断改善工具的可用性，加入大量对用户操作的预先检定，可以有效的减少操作失误造成的数据错误，提高了游戏版本的稳定性。原型碎片和整合测试环境上面提到 Unity 里能驱动一切的 MonoBehavior 类为原型开发提供了很大的方便，但作为网游项目，任何功能和资源都需要在游戏实际联网运行环境下进行测试。如何在 Unity网游项目中平
14、衡原型开发和实际联网测试呢?项目早期基础功能的原型，包括动画系统、图像渲染、角色换装等等，都是可以直接建立单机原型的。用脚本实现基本功能后再加上编辑器脚本和 GUI 脚本来为测试加上配套工具，然后再交给资源生产部门来添加游戏中的资源。地下城、任务和战斗系统因为涉及到很多和服务器端的通讯部分，如果需要测试就必须使用一个支持最简单的客户端服务端架构的单元测试档案配置。这里所说的档案，就是定义了你全部测试内容数据(或者去哪里找这些数据)的 ScriptableObject。包括你用来测试的帐号、角色信息、测试场景、任务或技能配置等等。以主城和地下城为游戏内容载体的蒸汽之城里，我们也制作大量测试用的地
15、下城或主城场景作为任务和新功能生产的测试环境。测试环境由美术或策划来制作，然后交给程序部门来测试代码，最后再交给QA 测试刚完成的功能。Unity 的强大原型制作能力主要还是应该体现在项目初期。一旦客户端服务端架构形成，可以在稳定的服务器环境上运行游戏以后，开发团队就应该把更多的精力集中在如何能够在实际服务器上快速添加新内容并进行测试。蒸汽之城有过三组测试服务器，分别用来进行代码、资源和网页接口的测试;此外对于需要频繁更新调整数据的任务策划和关卡设计人员，他们会使用在个人电脑上架设的服务器，来避免数据更新对其他人测试带来的干扰。动态下载和读取对于网页游戏来说，如果不能做到快速启动和最小化下载等
16、待时间，相对于端游的优势就不存在了。蒸汽之城里所有美术资源都被拆分成了非常小的零件，这样用户只要下载一次，就可以在运行游戏时根据需要来动态组合，大量减少了资源的重复下载率。而地下城制作的时候会使用工具进行 Serilization，游戏时每个地下城只需要下载一份 XML表单，然后就会自动从用户已经下载的“资源零件”中寻找需要的部分并进行动态拼装。体验过蒸汽之城的用户可以发现任何地下城的读取都不会超过数秒。接下来说说 Unity 页游的一大招牌 Asset Bundle 的使用。Asset Bundle 是可以被用户 stream 下载的资源包，其中可以包含任何 Unity Project 中的文件。要做到动态下载，游戏中的绝大部分资源就都必须打包成 Asset Bundle 才能使用。在蒸汽之城的开发过程中，我们为大部分资源生产者制作了 Unit
