文章发表在《大众软件》23期，主要是blog上《游戏成功学》这个系列的一个整理。
　
　　在此感谢大软的汪铁兄弟，对本文的修正和配图（有兴趣的读者可以看看那些配图，非常有意思）
　
　　由于是发在大软上的文章，所以如果要转载的话，请一定注明文章来源于《大众软件》缺陷与出路——一个游戏开发者的反思作者：blacksteps 来源：《大众软件》编者按：这篇文章脱胎于一个叫《游戏人成功学》的系列文章，它是作者长期身处游戏开发行业、亲历游戏行业痼疾后不吐不快的随笔。世界上的任何事情都是这样，当一个人对某个事物了解越多，他也就越能清晰地看到这个事物的缺陷。编者报道游戏行业也有数年时间，觉得作者这篇文章虽然有过于“专业”的嫌疑，但比起那些行文浅显、美化游戏行业、特意以“玩家”为对象谈论游戏行业本象的文章来说，这篇文章对我们的读者和游戏玩家也更有意义。从刊物的角度说，尽最大可能展现、记录这个行业的方方面面，本来也是媒体份内的责任。以上就是我们选登这篇文章为本期专题的原因。
　
　　由于原文涉及到的专业术语很多，我们对之进行了幅度较大的修改，以期能使读者更好地理解本文。
　
　　“游戏开发成功论”？
　
　　我曾写过几篇类似《给进入游戏行业新人的八个忠告》的文章，被个别朋友吹捧了几下之后，自己颇有点传道育人的成就感。但后来仔细琢磨，发现应该被教育的恰恰不是新人，而正是如我一般或比我高大睿智的所谓的老人、前辈、制作人和领导。新人终究有超过一半的机会通过试用期，但勤奋刻苦的中国游戏制作人们所领导的上百家开发公司，穷多年之力，到今天为止，真正成功的产品仍寥寥无几，其中世界级的产品，数量等于零。对比可见，老人、前辈、领导和伪高手们比新人更需要教育。有了被教育的觉悟，首先做的是反省和自我教育，本文即是一个从业有些年头的冒牌高手——我的几点零碎感悟，希望能以点博面，给读者少许启发。
　
　　是为序。
　
　　一、从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喜欢拿到提案书就开始督促手下人干，事实上，如果给大家几个月的时间实现一个规范的工业设计，就能避免以后无数的问题，节省大量返工的成本。
　
　　前面说到的是游戏开发这个项目的初步设计问题，接下来我想谈一下我对于游戏设计过程具体管理的看法。
　
　　游戏工业的理想状态，应该是流水线生产、精益生产、个体创造的结合，在策划阶段、游戏架构阶段、试生产阶段、测试阶段需要采取不同的策略，从而最大程度降低风险、降低成本及控制开发时程。注意“面向过程的管理”这个精益生产的实质，正是游戏开发未来所必须追求的目标，也是实施游戏工业设计规范所不可缺的部分。长久以来，游戏业内的管理是“面向人的管理”或“面向目标的管理”，甚至有的连目标管理都没有，而不用说进行真正的过程管理。
　
　　肯定有读者会说：谁说中国游戏开发没有过程管理？没有月表么？没有开发计划么？没有工作日志么？我要说的是，并不是表述了过程就可自认为进行了过程管理，也不是每天跑去问程序进度如何就是做了过程控制。“面向过程的管理”包括非常多的技巧和细节，这需要管理者去研究、规划和控制。
　
　　二、项目开发中的混沌和秩序我们可能都听说过这些说法：“你不可能不劳而获”“覆水难收”或“天网恢恢，疏而不漏”。如果这些谚语对你说来不算陌生，而且在日常生活中你也反复有过这样的亲身体验，那么你就懂得了热力学第一定律和第二定律。
　
　　——《熵：一种新的世界观》在游戏开发过程中，很多人应该有过这样的经历：整个项目的细节越来越多，但没人知道整体是个什么样子；自己做的工作越多，越感到没有信心和无助；不断修改、修正和返工。其实，这就是热力学第二定律所表述的，整个项目的无序性在增加，如果不加以控制，那么最后的结果就是进入最无序的状态，也就是整个系统的平衡态，即完全裹足不前的状态。事实上，无论游戏制作人意识到与否，游戏能否正常开发完成、能否达到立案之初的目标，很大程度上取决于游戏团队对抗热力学第二定律的能力。
　
　　之所以熵增原理对游戏开发影响如此之大，是由游戏开发本身的特殊性所决定的。以制造业为对比，制造业发展到现在非常成熟，其整个工程的无序性和不确定性并不随着规模的增长而质变，原因在于：1）产品各部件的质量定义非常清晰（目标清晰，需求明确）；2）每道工序对于最终产品的作用易于进行量化评估；3）成熟的流程管理或过程管理机制；4）专业化的团队；5）最重要的，足够的理论指导和经验积累；以上是使传统制造业免于熵增原理荼毒的几个关键因素，而游戏开发业显然不具备这些因素。结果就是，制造业常规状况下都能完成产品的量产和销售；但只有不足一半的游戏正常开发完成，而达到立案目标的可能不足2成（仅仅从国内的状况而言可能更少）。
　
　　大型的游戏项目从立案到策划案，到程序架构设计、底层开发、工具开发、上层逻辑编写，到美术资源制作、到整合、到测试，经历了一个单向资源流动的过程，这个过程类似一条河流在流动过程中不断吸纳支流，最终汇流入海。在资源传递的过程中，由于传递的层次很多，在语言和文字的表述无法绝对精确的状况下，多次的传递不仅容易产生错误、遗漏，还会不可避免地出现误解。每个层次资源传递中出现一点的偏差，汇总到最后可能出现若干巨大的错误，这就是“差之毫厘，谬之千里”。
　
　　在缺乏成熟管理机制的游戏开发业，使得热力学第二定律在这方面有了很大的发挥空间。某些策划懒得写必要的文档，依靠口头说明办事；部分团队没有工作总结；很多策划不知道能通过非语言手段（图片、拓扑等）表述信息；更多公司从来不写会议纪要和讨论纪要；绝大多数制作人都没有项目关键词定义的概念。
　
　　因此，要首先重视定义，才能制定有效的沟通机制。
　
　　在论坛里或朋友之间，我们经常能听到某个朋友说：“如果XX游戏这样设计就好了”，或抱怨说：“XX游戏为什么没有继承前一代的某种优点？”在游戏开发中，我们用“功能模块”来表示玩家所提到的这种乐趣点。一个功能模块往往代表了玩法的一个方面，当足够多的模块被整合之后，玩家所看到的就是我们希望展示的游戏世界。很多设计者试图堆砌足够多“好玩”的独立系统来形成一个“足够好玩”的游戏。“好玩”的独立系统随着新游戏的推出在不断增加，因此形成一个“足够好玩”的游戏需要的部件越来越多了。由于每个游戏模块都会通过某些接口来操作游戏属性/游戏进程，从而发生作用，这些操作与其他模块的操作可能产生相似/互斥的结果，甚至可能改变其他模块的开关状态。因此理论上，每个新模块被整合进入系统时，制作者都必须检查所有与此模块具备公共操作区域的原有模块，甚至必须检查所有操作可能带来的属性变更对依赖属性的原有模块的影响，这在系统足够大的时候是不可能完成的工作。
　
　　这带来了另外一个熵增的根源，项目的复杂度随着模块数量的代数递增作几何递增。即制作人对项目的控制力和把握会随着项目规模的加大而迅速降低，当复杂度到达一个临界点时，制作者追加任何模块，其整合成本对团队都是无力承担的。在这种状态下，依靠堆砌的制作人会在一个阶段之后突然发现，大量问题突然的、集约的出现。
　
　　相对稳妥的做法是：确认核心需求，并围绕核心设计必要的外围需求，从底层构架一个层次分明的需求，避免堆砌大而全的四不象，突出重点。
　
　　熵增原理作用的一个重要来源是缺乏计划性。由于缺乏经验和理论指导，加之相对漫长的开发过程导致市场的快速变化，在开发过程中，游戏制作者经常主动或被迫频繁地调整策划细节，这种藐视计划性的做法直接导致软件开发目的的不确定性递增。而不确定性反过来作用于游戏团队本身，使开发人员泄气和疲惫，降低工作效率和主动性，最终没人会相信工作计划，也没人会尽力做好自己的工作，因为这个工作随时会扔进马桶（被新的需求取代）。一种极端的状况是，有些团队连基本的工作计划和里程碑都没有，每周的工作完全是项目经理来临时安排；另一种状况是，一个既定的计划不会被尊重，开发计划几乎每星期都会推倒修改。很显然，这两种状况下开发已完全失控，其无序性远远超出了正常范围，开发团队必须付出几倍的预算和时间才能获得一线生机。
　
　　所以，像对待承诺一样信守你的计划——千万别轻于承诺，但承诺了就要做到。
　
　　以上说的是3个常见的现象，本章我们讨论的热力学第二定律，其实代表了项目开发中混沌和秩序的对决，而对抗热力学第二定律的实质是，追求设计规范所带来的秩序和控制力，减少无序性和不确定性。
　
　　三、游戏设计的量化问题我们谈过了游戏开发过程中面临的诸多问题，但这里还有一个基本问题是——是不是所有开发工作都能被量化？
　
　　很多游戏从业者都对此问题持否定的态度。游戏产业是一个创意产业，创意和艺术创作怎么能被量化？所以就有很多号称牛人所写的文章、接受的采访，大谈游戏开发管理的难度，主要根据是，设计工作/艺术创作无法被量化。
　
　　真是这样么？
　
　　在长度度量衡没有被发明之前，我们可以猜想，人类只能使用简单的表述来说明距离或长度，例如“高”“很高”“远”“很远”“非常长”等，在现代人看来，这种表述“十分不量化”，但在当时的人类认知中，长度应该是无法量化的，因为缺乏一种单位标准，可以使得不同的人能对长度进行同样精确、相同认知的表述。这里，我们可以看出，至少在数学概念的量化上，需要“单位标准”的确定作为前提。
　
　　在上面的例子中，一旦加减法被发明出来，度量衡就会出现，人们会定义长度的单位和换算方式，此时长度就变为可量化单位了（看到这里，会不会觉得《文明》系列中的科技缺了不少？）。
　
　　所以，认为游戏开发工作不能被量化的游戏开发牛人们，要么是对游戏开发工作根本不懂；要么就是对其他行业的研究成果视而不见，坐井观天；有更多的混子们觉得“不能量化”是糊弄投资商和Boss最好的挡箭牌。

[1] [2] 下一页

【责编:Luzi】