访“魔道”团队：Flash MMORPG 开发中的“五个基本原则”

本文是针对游戏开发领域系列采访中的第四篇，我们会采访到目前游戏开发比较热门的技术和公司来对问题进行解答，问题主要涉及游戏简介、开发中 5 件对的事情、5 件可以改进的事情、美工设计以及开发经验分享等。话题主要涵盖开发、发布、平台、开发工具和创新工具等展开。本文是针对 SGF Games，魔道六宗游戏制作人谈熠的采访。

采访主要从一款 Flash MMORPG 游戏出发，分别阐述了“魔道”开发团队在选择代码库、提升用户体验、进行测试覆盖和快速迭代上的思考，以及在团队协作、自动化测试和开源代码库选择上所遇到的挑战。以下是采访的具体内容：

魔道：开发一款游戏的过程无疑是一个充斥着大量细节和复杂矛盾的系统工程。 而我们的团队情况比较特殊，没有显赫的从业背景，大家都是从玩家转型而来的开发者，凭着对游戏的热爱，用心投入地来做这个产品。

我始终记得在“魔道”立项之初，一位备受尊敬的业界前辈就曾告诫过我们：网游的本质是人与人的交互，打磨一款游戏产品需要沉淀大量的心法（know-how）。因此为了避免项目走得太远而迷失，我们在研发过程中定义了一些规则。至于这些规则是对或错，还有待玩家和时间的检验。不过我们的团队已经从中收益良多。借这个机会，我很高兴能和大家一起分享一下我们所得的经验和教训。也希望能够通过 InfoQ 平台得到同行们的建议和指点，我的联系邮箱是 tanyi@smartgf.com。

规则一：一个代码库

开发魔道的客户端时，工具链的选择曾一度让我们伤透了脑筋。因为作为一个开发团队，我们的时间和精力十分有限。我们要确保自己有能力快速的根据玩家和运营的需求对产品做出调整。所以我们很害怕工具选择的不慎使我们陷入到无穷尽的开发折腾里去。

为了避免出现这样的情况，我们对当时市场上流行的各类开发工具和环境都做了一些调研，不过结果都不尽人意。

具体的来说吧，HTML5 环境下的渲染性能和 API 成熟度远远无法满足 MMO 产品的开发需求；UNITY 3D 技术在移动市场上相对比较成熟，并且提供整合的开发环境，但是在浏览器市场上的渗透率过低，此外所提供的联机环境下的开发能力十分有限。Cocos2d-X 在 iOS 平台上有很多成功案例，而且基于 C++ 的移植有广泛的代码库支持。可惜基于 JavaScript 的移植无法满足浏览器中的 MMO 开发需求，而且作为一个开源产品，在 Android 的移植上，对系统的依赖度很高，我们非常担心如果采用 Cocos2d-X 作为开发基础的话，最后将不得不陷入多个平台版本多个代码库的痛苦分裂。

总结下来，我想我们所需要的工具链至少需要具备三个基本特性。

首先必须是一个成熟的虚拟机环境，能够有效的将不同平台系统中的差异进行抽象，而不是把这些折腾成本转嫁给开发者。然后必须能够使我们充分利用到物理设备上的 CPU 和 GPU 资源，特别是在移动设备上，MMO 游戏中的大量图形渲染需求需要充分地利用 GPU 的并行计算能力。最后必须提供完整的底层接口，使我们能够针对不同的设备系统进行差异化的扩展，而不影响主代码库中的实现。

2011 年末，在 Adobe 的 Peter 和 7yue 的邀请下，我们有幸加入了当时正在研制阶段的 AIR SDK 的专家预览小组。熟悉了 AIR 技术之后，我们在选择工具平台上的纠结一下子都释然了。虽然 AIR 技术在跨平台开发工具市场中成熟得相对比较晚，但是无论在深度还是广度上，AIR 都给出了近乎完美的解决方案。当我们的开发需要触及底层渲染时，通过 Adobe 的 AGAL 语言可以能够直接对抽象后的显卡设备编写汇编指令。而同时兼容 Stage3D（GPU 渲染）和显示列表（CPU 渲染）的 AIR 技术，给我们的开发提供了极大灵活度，大幅缩短了 UI 移植和终端适配的时间成本。

规则二：体验至上

我们刚开始制作魔道的时候，正值国内网页游戏的市场的如火如荼的高峰。而今移动平台在一个极短的时间内走完了 PC 平台多年的积累，迅速崛起。现在市面上流行的网页游戏都同时运营网页和手机版本。

我们着手开发手机游戏版的最初想法是将网页游戏进行简单的移植。为了验证这个想法的可行性，我们花费了数百个小时玩了各类流行的手机端 MMO 游戏。然后发现一个令人失望的现实——手机和平板电脑的人机交互属性和 PC 有很大的差异，简单的移植只会让玩家体验大打折扣。

就拿客户端断线重连功能来举例。PC 设备上的大量用户处于稳定的网络连接情况，并且键盘和鼠标给玩家提供了高效率的输入途径。但是手机用户往往处于不稳定的网络环境下，而且游戏进程被切换到后台进而中断的情况十分常见。当然我们可以简单移植网页游戏的处理方法，每次断线之后让玩家重新输入用户名和密码进行登录。但在手机上进行文字和符号的输入，对很多玩家而言无疑是一个痛苦的障碍。 所幸 FLASH/AIR 中 TCP 连接的 Socket 抽象对象提供了十分细腻的 API，从而使得我们能够在手机游戏中实现自动的断线重新连接功能。

图一：兼容显示列表的 FLASH/AIR 技术大幅降低 UI 重构成本

再举一个例子，通过统计数据，我们发现大量手机版玩家临睡前上线。因此我们把手机版的界面尽量设计为单手方便操作。然而网页游戏中，玩家都是直视电脑，主要的输入操作通过键盘和鼠标完成。 因此网页游戏和手机游戏采用了两套不同的 UI 实现。为了能够快速完成两套 UI 的实现，我们采用 Starling UI 框架。Starling 在 GPU 模式下还原了 FLASH 的显示列表结构。从而让 UI 的移植和修改都简单很多。

规则三：保持简单

图二：交互设计上尽量保持简单

移动设备在我们的理解中和 PC 设备有着本质性的区别。终端用户在移动设备上的交互体验集中在娱乐和消费上，而在 PC 上进行更多的生产型工作。因此设计手机版本的交互操作时，我们秉承保持简单的原则，尽可能的做减法。在魔道的手机版中，我们抛弃了强制性的步骤引导，而改用根据玩家在游戏中的发展而逐步开启玩法模块的设计。同时我们也将 PC 上的拖拽操作改为触屏操作。

规则四：没有测试覆盖绝不能发布

在整个开发过程中，随着项目复杂的增加，我们越来越发现测试覆盖的重要性。在魔道运营之初，由于测试覆盖的不完整，当数万个玩家涌入时，服务器发生一系列的异常。我们不得不进行的反复维护而使玩家的游戏体验大打折扣。

经历了这次挫折之后，我们决定整体重构游戏服务器。即时战斗的 MMO 游戏的服务器端程序是一个高并发处理程序结构。在这样的结构下，对系统资源调度的不谨慎将必然使程序陷入竞争危害。所以服务器的重构采取开放和细分的模块化设计，然后针对每个模块进行测试覆盖。

但是即便对每个模块进行了完整的测试覆盖之后，系统整合时我们依旧遇到很多异常。这主要是因为游戏服务器本身是一个大量的异步请求的过程性操作。为了尽可能模拟终端玩家的环境，我们采用 Node.js 编写了一系列的用例测试来检查系统整合的功能。通过这两个测试环节的控制，魔道的服务器变得非常稳定，在生产运营中，除了版本迭代外，没有再发生额外的异常维护。

规则五：保持快速迭代

计划总是赶不上变化。在开发魔道的过程中，我们已经习惯了在测试和运营后返工修改预期的功能设计。为了能够让魔道在调整中不断的快速进化，我们将产品版本的迭代周期严格的控制在 3 周以内。我想我们能够尽量缩短迭代周期，主要还是归功于 AIR 技术所提供的成熟的工具链和我们质保小组实现的大量的用例测试。

魔道：在我看来，产品开发不是一个单纯的项目，而更象一个始终“在路上”的旅程。在体验了魔道旅程的甜酸苦辣之后，我们学到了许多宝贵的经验，同时也留下不少的遗憾和教训。单就开发过程而言，简单总结如下。

首先我觉得团队协作是一门很大的学问，特别是对于搞技术的同事而言，因为大多比较腼腆沉静。有的时候团队中的几个人都在考虑解决同一个问题，但是所采用的思路和方法很可能截然不同。在这种情况下，如果无法互相沟通好的话，就不能力往一处使了。更何况在这种时候，沟通也是件很累人的事情。于是，慢慢的我们发现，在做开发实现的过程中，设定一套被大家都能接受的代码规范往往能起到事半功倍的效果。这就好比一家人有了共同的方言，这样凑在一起唠嗑才会开心。我们在一个小组中做了这样的尝试，发现效果很好，正在不断的改进和推广这个方法。

然后我觉得人工测试远不如机器的自动化测试有效。魔道的测试最初是采用完全的人工进行。可能是因为测试的同事对魔道都已经太熟悉的缘故，测试行为中的差异化就消失了，所以查不出意料以外的问题。后来我们编写了大量的测试脚本，用自动化流程来进行覆盖，使得产品质量大幅改善。但是由于魔道的客户端主要基于 ActionScript 这个编译语言而开发，编写异步测试的工作变得复杂很多。相比之下，我们在服务器端采用 Node.js 来撰写测试则变得无比的灵活和轻盈。在这点上，虽然 ActionScript 语言提供了单元测试框架（比如 ASUnit，FlexUnit），但是如果 Adobe 不在 AS 虚拟机层面提供更加灵活的支持的话，恐怕“测试驱动开发”对于 ActionScript 开发者来说还将是一种奢望，当然更不用提“行为驱动的开发”了。

第三，和第三方开源代码库的对接。网上有很多 ActionScript 的开源项目，象珍珠一样散落在互联网的各个角落。找到和学会使用一个靠谱的第三方 AS 代码库是一件费时费神的事情。ActionScript 严重缺乏一个统一的中央的第三方模块管理和发布系统（参考 Node.js 的 npm、RubyGems、Python eggs 等）。正因为这样的系统的缺失，全世界 AS 开发者之间的工作难以有效的分享和复用。不过，这未必是一个技术性问题，在我看来，可能和 Adobe 之前一贯的基于工具产品销售的商业模式不无关系。Flex Builder 4.8 版本开始将由 Apache 基金会托管，同时 Adobe Game 开发工具的商业模式也将从基于工具产品收费，而转变为基于许可证书收费。相信这样的转变将会给 ActionScript 的生态环境带来许多新的气氛。

魔道：说到规划，我觉得互联网为大家开启了一个非常神奇的时代。

以前，我曾在国外的一个大型公司工作过几年。当时的软件行业中，项目管理和瀑布模型的软件工程还很吃香。一个软件开发项目做上一年半载十分正常。再加上各种必然发生的需求变更，“产品交付”总让人感觉是一个距离遥远的目标。为了能够顺利达到这个目标，我的团队每周都要检查和调整月规划，季度规划，年度规划……在那样的环境下，开发本身很容易被形式化，而使开发者很快忘记了软件的本质是为了满足用户不断改变的使用需求。

现在，我们把产品的交付周期缩短到三周之内。每天，我们的策划都通过和游戏玩家的交流来调整和修订产品的功能设计。所以在我看来“未来的规划”已经不再是一个常量，而是变数了。不过，即便如此，我想有一些东西是不会变的。比如，无论玩家是在网页中进行游戏，还是在手机上玩，终端用户的总量正在急速膨胀。换句话说，玩家在魔道游戏中的总时间输入是一个持续加速累积的资源。而我们所想要做的就是服务好玩家在游戏中所投入的时间。尽我们所能完善游戏的玩法，让玩家在游戏中享受到更好的体验。