解析各种糟糕的设计文件类型以及解决方法

Admin

本篇文章是摘自Richard Rouse III的著作《游戏设计：原理与实践》的修订版。这本书覆盖了所有游戏设计的相关内容，包括想出一个可靠的理念，执行游戏玩法，以及测试最终版本的游戏。在设计师真正开始进行游戏编码前，他们必须先将游戏设计呈现在设计文件上。而就像Rouse在书中所提到的，并非所有设计文件的创造都是相同的。

　　“省略不必要的内容。确保表达的简洁。句子中不应该包含任何没有意义的单词，而段落中也不该包含任何没有意义的句子，就像绘画中不应该包含没有意义的线条而机器中不应该包含没有意义的组件一样。但是这并不是说作者们应该尽可能确保句子的简短或者不能阐述所有细节，而是说他们最好尽可能直接简洁地传达所要传达的内容便可。”

Design Documents(From Gscept.com)

——《The Elements of Style》William Strunk

　　就像我之前提到的，如果我们能够获得一些较专业的游戏设计文件，我们便能够更好地明确游戏产业所要求的规格。然而你也必须谨慎地处理这一过程，因为有可能你所获得的设计文件并不能为你带来多大的帮助。很多有经验的专业人士所撰写的并且是用于一些已发行游戏上的设计文件其实都非常糟糕。而为了教会你们如何避免这些糟糕的文件，我将在此列举出一些不同类型的糟糕设计文件，并阐述它们为何会遭遇这样的失败。

　　极薄或充满省略符号的特殊文件

　　有一些不超过30页的设计文件却因为充斥着各种没有意义的内容而让经验丰富的游戏设计师感到无语。这些设计文件总是使用一些如“游戏玩法非常有趣”或者“反应非常强烈”如此乏味的内容进行描述。并且这些文件中的比较也总是平平淡淡，如“这玩起来就像《超级马里奥64》”或者“游戏的控制机制类似于《Quake》。”尽管有时候看来这种比较也会带来一些帮助，但是撰写出这些极薄设计文件的作者却未能详细解释《超级马里奥64》或《Quake》中的控制机制，使得读者对于这些游戏中的机制还是充满疑惑。

　　通常情况下这些文件总是会以较大的篇幅（也许是半页内容）去阐述背景故事。但是往往地这些背景故事对于游戏的开发其实没有多大的帮助。这种极薄的文件也总是会花大量时间在解释菜单的使用。并且这并不是指游戏内部的菜单而是系统菜单——也就是用户可以在此选择他们想要玩的游戏内容，并做出选择等等。虽然这些文件也设置了许多模型和选择，但是它们却未能详细描写这些选择对于游戏发展的影响。当设计师明确了哪些选择更重要或者玩家将选择哪些不同的游戏玩法时，他们就需要明确游戏中的菜单系统；但是这既不是游戏中最复杂的一步也不是设计师需要最先敲定的最重要系统。

　　这种极薄的文件一般都是出自于管理人员之手——他们总是认为自己就是游戏设计师。而这类型文件之所以也被称为充满省略符号的特殊文件是因为文件中总是布满各种省略符号。例如，全世界玩家在游戏中的遭遇都将被描写为：“丛林世界是一个炎热潮湿的地方，Garguflax猴将在此四处游动并纠缠玩家……”这应该是任何文件在向全世界玩家阐述内容的共同表达方式吧，即以省略号结尾，就好像在说“在这里插入游戏设计”似的。如此我们并不清楚这些文件的作者是否会在之后还会回到文件中填补这些省略，或者他们只是认为没有必要花时间解释游戏的具体运行吧。也许他们只是以此假设别人会来填充这些省略并创造出更棒的内容。

　　另外一个关于省略符号文件的例子是：“玩家将能从一些很厉害的武器中做出选择。例如比起玩家的其它武器‘Gargantuan Kaboom’拥有双倍的破坏力以及特殊的影响力。而‘Barboon Harpoon’则带有很好的摄像机效果让玩家能够在远处杀死敌人。而其它武器也都拥有各种有趣且强大的功能……”这一省略符号文件的作者未能详细描写游戏每个关卡所出现的武器，并且也只罗列出两种武器，从而让读者不得不自行想象其它武器。虽然文件告知了玩家其它武器也是“非常有趣且强大”，但是省略符号文件的作者却错误地认为开发一款游戏并不需要完整的描述。

　　极薄或充满省略符号的特殊文件的唯一优点便是它能帮助设计师快速有效地接管整个开发项目并将其变成自己的项目。我之所以说这是优点是因为管理者涵括在极薄文件中的内容通常都是荒谬的，或者不可能帮助设计师创造出真正可行的游戏玩法。但是我们还是必须对这种文件报以警觉。特别是当六个月后管理者开始抱怨“这与我所写的内容完全不一样”时，问题就严重了。

　　背景故事册

　　与撰写省略符号文件的作者不同的是，撰写背景故事册的作者会花大量的时间于文件编写中。这些书册（说是文件也不合适）经常会延伸至上百页——就像300，400或500页都不成问题。而关于这种大篇幅文件也存在着许多问题。

　　这类型文件所存在的第一个问题便是所有内容都以一种糟糕的表格形式呈现出来，且未提供任何明确的索引。在文件设计中，如果你的信息排列井然有序或者游戏设置非常合理，那不用设置索引也没关系了。但是如果同时忽视了这两点，你便会遇上大麻烦。而如果你的设计文件像《战争与和平》那样长篇大幅时，问题就会变得更加复杂。游戏设计文件的存在价值是让团队成员能够快速找到他们所面对的游戏内容的相关信息。就像如果程序员想要知道一个特殊敌人的AI是如何运行的，他便需要在此快速找到相关信息。而如果程序员不能在此找到这些信息，他便可能会将事情搞的一团糟。同样地，当美工人员想要明确游戏中特定领域需要何种纹理时，他便希望自己能够快速找到关于该领域的相关描述。设计文件并不是小说，没有人会老老实实从头看到尾。从根本上来看，设计文件更应该说是一种参考资料，而如果团队成员不能在此找到自己所需要的内容，他们便会放弃这些文件。

　　但是通常情况下当我们开始在这些背景故事册中找寻内容时，我们会发现很难在这里找到有关游戏玩法的相关信息。洋洋洒洒的500大页都是关于背景故事，而不是能够用于电子游戏中的内容（游戏邦注：即详细描写了游戏中的所有角色的背景，这些角色的好友，以及这些角色的亲戚和兄弟姐妹等！）尽管这些内容看起来非常有趣，但是读者在阅读了全部内容后会发现他们根本不可能在此找到有关于游戏如何运行的信息。通常情况下，这些文件的作者都是一些挫败的小说家或者是来自于非互动媒体的作家，他们根本就不了解游戏的开发。许多游戏都将故事阐述作为游戏的核心内容，而故事在游戏创作中也是非常重要的元素。所以在这种情况下，在设计文件包含游戏故事是言之有理的。但是不管怎么说，在设计文件中包含游戏设计比涵括故事更加重要。所以任何作者在撰写设计文件时都需要考虑的一个问题是“玩家能够在此做些什么？”尽管这些书册拥有一定的重量，并且也具有相当的风险，但是程序员在设计游戏过程中需要始终参考着这些文件，将其作为自己前进的向导。

　　过度的文件

　　有些设计师认为他们能够在设计文件中描写游戏的每个方面。当然了，就像我们之前所说的充满省略符号的特殊文件那样，许多设计文件都缺少了一些有用的细节内容，但是相反地也有许多设计文件阐述了过多的内容，这不仅是浪费设计师的时间，同时也会迫使读者们不得不仔细浏览这些多余的信息（从而找到真正对自己有帮助的内容）。此外，过度的文件也会让设计师陷入一个错觉中，即以为自己创造了一份完整周密的文件，但是孰不知他们只是过度强调某些对象的细节而忽视了其它该侧重的领域。

　　举个例子来说吧，假设一款游戏中设有若干角色，并且他们将在游戏世界中执行一定的行动。也就是游戏世界中住着一些市民，他们可以在此四处走动，坐下，站起来，与别人交谈或睡觉。所以设计文件应该基于AI描写这些行为。较为周密的文件会将这些内容分解为几个动画：起身，坐下，懒洋洋地坐着，懒洋洋地站着，行走，摆动着肢体语言等。因为一般情况下优秀的动画师和美工人员都比设计师擅于分解这些内容，所以在设计文件中描述这些内容通常都是多余的。但是就是有些设计师愿意浪费时间去一个个罗列出这些动画框架。太可笑了！在编写设计文件阶段我们根本不可能知道一个特定的动画中需要多少动画帧，因为这些内容也只有在游戏制作过程中才能逐渐明朗化。更不用说在设计文件中列出动画框架将会对动画师造成伤害了——他们会因为这种束缚的微观管理而倍感泄气。此外，设计文件还应该始终重视对于游戏玩法的描述，不应该轻易转向图像或其它图像文件领域。

　　另外一个例子便是我所说的“平衡数据”。这是一些关于游戏中的武器，道具和角色的真实统计。而设计文件则应该罗列出武器和角色所拥有的不同属性，例如一种武器拥有准确的射击率和极快的发射速度。除此之外设计文件也有可能会描写一种特定武器的特性，如“Double Barreled Shotgun虽然射程较短且不够精确，但是在较大范围内它却能够造成巨大的破坏力。”但是事实上，罗列出武器的这些属性对于设计文件来说并没有多大用处。就像是“Shotgun的精确度为2”这一描述并不存在任何特殊目的，因为在这里数字“2”并没有任何可供参考的环境，所以不具备任何意义。只有在游戏真正开始运转，也就是设计师能够根据玩家使用武器的情况平衡武器，并通过在不同设置中进行实验而达到预期效果时，这些价值标准才会真正实现。所以在我们真正能够测试信息之前创造大量的信息便只能说是一种浪费时间的表现。将内容以表格的形式表达出来虽然能够帮助设计师更好地阐述一些未经加工的想法，但是这种表格却只能呈现出最初形式，在游戏真正发行之前设计师还需要对此做出多次调整。

　　与动画细节和精确的平衡数据一样，资源代码也不适合出现在设计文件中。如果设计师甚至开始在自己的设计文件上编写代码，那就太夸张了！（游戏邦注：但是如果设计师也是游戏的程序员，那就无所谓了）设计文件不应该包含任何代码，甚至是伪代码。在设计文件中添加代码只能是增加文件的负担，或者将导致设计师忽略了那些本该阐述的内容。在这里，如果使用简单的如果则否则类的逻辑解释将会非常有帮助。因为这种解释能够在设计师撰写代码时告知他们所有的意外事件，以此帮助设计师在撰写文件时尽可能考虑到任何与游戏相关的情况和结果。但是如果你开始在文件中编写像C++语言这样的代码，那就只能说你做得太过火了。

　　如果说过度文件中也存在一些真正有用的信息，那也只能说设计师将这些信息隐藏在大量无意义的数据中并导致团队成员不敢去寻找它们。作者们总是认为自己能够预先规划好一切，并且自己也比团队中的其他成员更优秀。

　　尽管过度关注细节内容总比作者连自己在做些什么都不懂来得好，但是过度的设计文件却终究只会激怒那些依赖于文件的开发成员们。