MMORPG开发之七日创世说（五）

    创世第四日    星辰——游戏中的各种系统

 

    经过之前的几篇文章的讨论，现在我们已经能够用几句精炼的语言来描述一个新游戏了，包括模式、2d/3d、故事背景、美术风格、角色设定等。通过这些，游戏研发团队对新项目形成直观的印象，并依此制定出明确的研发计划和目标。

    之后我们所需要做的就是对这样一个庞大的项目进行分解，将其拆分成为一个个单独系统模块，这对于之后制定开发的计划和版本控制有着非常重要的意义。下图就是游戏架构范例图：

 

 

    这是一个非常简单的系统分支图，实际项目开发中，根据实际情况会有更多不同的方面，划分的更细，系统内容也更多。

 

    我认为在这些不同的游戏系统中，可以划分为三个不同层面的问题进行思考：

    首先第一个层面我称为游戏内的常规系统，包括聊天系统、背包系统、道具系统、任务系统等。常规系统在任何mmorpg游戏中都是必须的，它们的作用就是满足玩家在游戏中最基本的“衣食住行”需求，而且各个游戏所采用的设计方式都大同小异，因此在这些系统上不必做过多创新设计，开发中也不允许在这些系统上花过多时间，所以我们需尽量借鉴利用已有的设计案例。总的来说，常规系统在所有产品中都非常常见，但由于涉及面广、复杂度参差不齐，系统间还有着紧密的联系，因此在设计制作常规系统的时候，必须做好充分的理论和技术准备、理清主次关系和开发顺序。

    第二个层面我称之为游戏的核心系统，说是核心其实很简单，归结为四个字就是战斗系统。可以这样说，MMORPG经过了十几年的发展，其核心乐趣仍然来自于游戏中的战斗体验。虽然曾经有很多游戏尝试着突破，提供不同的系统让核心乐趣多元化，甚至创造一种全新的游戏体验，但是在中国的网游市场都无一例外的失败了。如今有公司提出的game2.0模式中，玩家将能够自主的创造世界，但是我坚定的认为这只适合于概念的炒作，而作为游戏的主要系统，提高了游戏的入门难度，也无法持续产生高度的游戏黏着度；从另一方面来说技术和性能消耗也将成为这种模式的一个瓶颈。作为玩家来说，进入一个mmorpg游戏后，习惯上做的第一件事就是了解如何去战斗；回顾MMORPG产品的发展历史，能够长期占据主要市场的产品，其战斗系统的体验都是非常出色的。因此，至少在现阶段，我们不要试图去改变玩家的使用习惯，而是尽量将产品做的更符合用户的需求。举一个例子，《卓越之剑》的战斗系统，是一个玩家需要同时操纵三个角色进行战斗，灵感来源于《魔兽争霸III》中的三英雄模式，非常有新意；但是由于该系统增加了操作复杂度，其战斗体验并不出色，这款产品也并没能取得特别好的成绩。

    第三个层面我们可以称为游戏的特色系统。大家都知道，现在野鸡大学非常流行，各种学历造假的事件层出不穷，而网游界也同样如是，什么国内第一款3d回合制游戏阿、第一款最Q的XX游戏、第一玄幻XX游戏等等，只要找到合适前缀什么游戏都能称为第一，就好比猪八戒说俺是高老庄里最帅的猪一样，毫无任何意义。其实网游老玩家都知道，MMORPG游戏的特色系统无非就是这么些个，只是在一些细节上会做一些小的突破、修改或者组合，翻翻花样后出来一个所谓的世界首创。这些都是虚的，只是给市场宣传抢眼球用的，我们来谈一些实际的。

    首先我们要正视特色系统的定位，市场现有的MMORPG产品非常多，已经很难出现一种大家都没有独此一家，而且又是用户求之若渴的特色系统了。因此对于新开发一款新的产品，首先应大量继承现有产品的系统设计，然后再着重地、谨慎地对某几个系统进行适度的改造和发挥，在原有的基础上做出一定的区别。而且这些特色系统一定要与核心战斗系统紧密联系，系统之间也能够互相支援，使游戏的核心系统与特色系统有机地、紧密地结合在一起，这样既能够做出一定的特点，同时也能使风险处于可控范围内。

    另一方面，为了适应玩家习惯的发展，新推出的MMORPG游戏也出现了一种趋势，就是练级时间逐渐缩短，而在满级后提供给玩家更为丰富的游戏内容。玩家当然希望少花时间在枯燥的练级过程中，而能够多接触一些全新的游戏体验。但是这种游戏模式却对开发团队提出了相当高的要求。而通过特色系统与核心系统的有机结合，我们能够在一定程度上环节这种压力：多种特色系统能够提供玩家丰富的发展方向和物品奖励，大幅度增加游戏整体的深度、广度和厚度，以延续一个版本内容的游戏时间，为研发团队争取更多的时间来开发后续的内容，并建立一个良性的循环。

 

    以上这些系统仅仅只是玩家所能够接触到，而在游戏开发过程中，开发团队还需要面对更多的系统需求。我这里引用一段《人月神话》中的文字：

    在时间进度中，顺序限制所造成的影响，没有哪个部分比单元调试和系统测试所受到的牵涉更彻底。而且，要求的时间依赖于所遇到的错误、缺陷数量以及捕捉它们的程度。理论上，缺陷的数量应该为零。但是，由于我们的乐观主义，通常实际出现的缺陷数量比预料的要多得多。因此，系统测试进度的安排常常是编程中最不合理的部分。
    对于软件任务的进度安排，以下是我使用了很多年的经验法则：
    1/3 计划；1/6 编码；1/4 构件测试和早期系统测试；1/4 系统测试，所有的构件已完成。
    在许多重要的方面，它与传统的进度安排方法不同：
    1. 分配给计划的时间比寻常的多。即便如此，仍不足以产生详细和稳定的计划规格说明，也不足以容纳对全新技术的研究和摸索。
    2. 对所完成代码的调试和测试，投入近一半的时间，比平常的安排多很多。
    3. 容易估计的部分，即编码，仅仅分配了六分之一的时间。
    通过对传统项目进度安排的研究，我发现很少项目允许为测试分配一半的时间，但大多数项目的测试实际上是花费了进度中一半的时间。它们中的许多项目，在系统测试之前还能保持进度。或者说，除了系统测试，进度基本能保证 。
    特别需要指出的是，不为系统测试安排足够的时间简直就是一场灾难。因为延迟发生在项目快完成的时候。直到项目的发布日期，才有人发现进度上的问题。因此，坏消息没有任何预兆，很晚才出现在客户和项目经理面前。
    另外，此时此刻的延迟具有不寻常的、严重的财务和心理上的反应。在此之前，项目已经配置了充足的人员，每天的人力成本也已经达到了最大的限度。更重要的是，当软件用来支持其他的商业活动（计算机硬件到货，新设备、服务上线等等）时，这些活动延误出现即将发布前，那么将付出相当高的商业代价。
    实际上，上述的二次成本远远高于其他开销。因此，在早期进度策划时，允许充分的系统测试时间是非常重要的。

 

    这段文字说明，编码只是开发过程中所占据最短时间的一个过程。工欲善其事，必先利其器。在正式编码之前，我们需要对所开发的系统做好充分的技术验证和需求设计，才能够高效的完成编码的工作，并控制bug的数量和严重程度。而很多团队则喜欢在还未进行充分分析的情况下，就急于编码工作，边测试边修改，那么最终交付的系统功能也一定会存在诸多的问题，导致一段时间后不得不重写系统，这样的情况很可能会经常出现。有兴趣的读者可以稍微研究一下敏捷开发模式，这是当今软件开发行业内非常流行的一种模式，效果相当不错。游戏开发本身就是一种特殊的软件工程，我们可以将这种模式拓展到游戏开发的各个方面，包括策划、美术和技术部门，以提高整个团队的开发效率。    

    游戏中的系统分类就暂且聊到这里，我将在之后的文章中会尝试分析一些具体的系统设计方案，希望能与大家分享讨论这些系统设计的经验。