【转】缺陷与出路—一个游戏开发者的反思 一、从D&D看游戏的底层设计

        把一个所谓的游戏意义上的伟大创意在游戏产品上付诸于实现的前提，是所有的设计应该符合游戏工业设计规范。

         ——龙云峰《EEE&Lumines: Design for Business》

这是我第一次看到有人这么明确且重视地提出 游戏工业设计规范。在中国游戏发展这么多年的情况下，到2006年才由一个入行不久的“准老人”提出，对于所有在职的“老人”和“大师”们，都是一种绝妙 的讽刺。 可能很多玩家都奇怪，为什么一个国产游戏会拖期再拖期呢？为什么拖期之后出来的却是个Bug不断的半成品呢？为什么一款网络游戏开发到后期，连画面风格 都要做出调整呢？游戏开发目前几乎所有项目的症结，归根结底都与游戏设计的架构和流程有关。其实玩家们不知道，在国内游戏项目的进程中，下面这些糟糕的状 况经常会出现：

         1）项目中期发现，如果编辑器支持一个特殊功能将能节省美术1/3的工作量；

         2）做到第25个月发现所有美术风格相比某游戏已完全落伍，不得不重做；

         3）你和所有的人都知道游戏有什么功能，但没有人能说出游戏为什么好玩；

         4）一个程序的离职导致全部渲染底层需要重写；

         5）你的MMO内测中，发现玩家只要1星期就能练到100级，而这是游戏的最高级别；

         6）游戏最终版本与提案书对比， 只有不到30%的功能得以实现。

        这些只是几个我曾经听到的例子，而很多更加荒诞的情况都在不断上演、不断重复。我曾经跟一个在做项目管理的朋友说过，我们一直在重复你们过去曾经犯下的错 误。似乎所有团队都必然要交这样或那样的学费，可悲的是更多的人交了学费仍不反省，仍然采取侥幸态度忽视游戏初期设计的作用。也因此，我们今天看到的国产 游戏成功者仍然寥寥无几。

要避免后期开发中的混乱局面，在游戏设计的初期，就需要首先建立软件工程规范化的概念。

什么叫软件工程？它是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。

         1.目标：生产具有正确性、可用性及开销合宜的产品。

         2.过程：生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。

         3.原则：是指围绕工程设计、工程支持及工程管理在软件开发过程中必须遵循的原则。

        游戏软件的开发与其他软件开发相同，都要符合软件工程的规律。游戏的最根本本质是一个软件，文化产品只是软件完成后的附加属性——很显然的，OpenGL 不仅能用于开发主视角射击游戏，也能开发工业CAD软件甚至远程医疗软件。商业软件的系统分析是针对用户实际的特点，来决定用户的现实需求如何能在软件开 发中实现，而游戏软件的开发也是同样的道理。一款游戏是否能顺利开发完成，取决于它的结构是否符合软件工程规范，这是降低游戏开发难度和项目复杂度的前 提。因此，我将游戏设计符合软件工程的要求，定义为游戏工业设计规范的一个基本条件。

        而这对现在的中国游戏人而言，无疑是一个非常苛刻的要求，或许更有人会说这在目前的国内游戏行业也是个空想。但我们不妨仔细研究一下D&D这种老 牌的桌面游戏规则吧！它至少符合一个严格的软件工程所需要具备的基本特征。仔细研究D&D，你会发现，所有的对象，通过基本属性、天赋、适用规则 等（内涵构件）进行定义；通过规则操作，如魔法攻击（接口）进行相互作用；通过模板、种族、职业（类关系）进行衍生和统一。由于设计者将本来错综的游戏世 界高度概括成数字化的规则（生物/人造/自然物件的基本属性和基本属性作用规则），因此在面对整个游戏世界这个巨大的复杂系统时，D&D具备几乎 无限的扩展能力，可以适应不同科学发展度，不同文化的背景设计。

理论上，构建一个虚拟的世界，它的基本要素越是高度概括和定义的，那么 底层设计工作的重用性就越高，扩展性也越大，同时，由于每次依靠本层次控件和规则构成往上一个层次时都可能与最初的设想有极小的偏差，因此最终层次的表象 控制就越难。如果我们把当前的宇宙视为一个游戏项目，那么，上帝至少在设计之初将“夸克”视作最底层的材料，而我们看到的整个世界都是由几种基本的“夸 克”构成的（看来上帝的美术工程师很省工）。由于层次非常多，这个世界最后的面貌很可能与上帝的提案书差距非常大。当然，上帝可以在最高层直接添加规则来 更改这个差距。

D&D代表了目前游戏设计能够高度概括到的极限（或许《进化》能打破这个纪录，还没有看到游戏，不知道具体情 况）。我们做游戏设计，没有必要做到这个层次，只需要抽象到玩家看到的具体控件的下面一层就可以。例如MMO中有设计纸娃娃的需求，里面有衬肩，那么，我 们只要比常用的做法更进一步，将衬肩再向下一个层次，分为贴图风格、形状、特效种类、特效颜色4个基本控件，那么，只要每个控件做少量几种就能组合成很多 种类的衬肩，这样规划可大量减少美术的工作量。而常规做法只能是一个个衬肩去建模和绘制。

概括和定义底层是游戏设计对商业需求分析后最 简单的一个步骤。在分析商业需求过程中，我们可针对各个方面抽象出类似的关键问题：

        1）NPC、怪物、Boss和玩家角色是否属于共同的类？如果是，这个类如何定义？其子类如何定义和区分，基本属性、骨骼、模型、纸娃娃、动作是否通用？ 各子类是否有必要定义各自的子类？这些所有定义对于美术和程序工作的影响何在？

        2）职业、种族作为通用模板如何对上述的类中的对象进行作用，其作用是否与子类的定义相关？

        3）作为场景设计的需求，有多少建筑对象以构件组合方式可以作出变化？如是，组合需要支援多少种风格？有必要单独设计的建筑有多少？

        4）有无可能以一种统一的升级规则操作基本属性来控制所有的平衡？

        这种问题还有很多，根据游戏类型的不同，进行设计时的需求也有很大变化。

        游戏设计符合软件工程的要求，需要项目负责人有基本的软件工程知识，并有相应领域的专家加以配合。很多Boss和Leader喜欢拿到提案书就开始督促手 下人干，事实上，如果给大家几个月的时间实现一个规范的工业设计，就能避免以后无数的问题，节省大量返工的成本。

         前面说到的是游戏开发这个项目的初步设计问题，接下来我想谈一下我对于游戏设计过程具体管理的看法。

        游戏工业的理想状态，应该是流水线生产、精益生产、个体创造的结合，在策划阶段、游戏架构阶段、试生产阶段、测试阶段需要采取不同的策略，从而最大程度降 低风险、降低成本及控制开发时程。注意“面向过程的管理”这个精益生产的实质，正是游戏开发未来所必须追求的目标，也是实施游戏工业设计规范所不可缺的部 分。长久以来，游戏业内的管理是“面向人的管理”或“面向目标的管理”，甚至有的连目标管理都没有，而不用说进行真正的过程管理。

        肯定有读者会说：谁说中国游戏开发没有过程管理？没有月表么？没有开发计划么？没有工作日志么？我要说的是，并不是表述了过程就可自认为进行了过程管理， 也不是每天跑去问程序进度如何就是做了过程控制。“面向过程的管理”包括非常多的技巧和细节，这需要管理者去研究、规划和控制。