游戏设计的艺术：一本透镜的书——第二十四章 团队往往通过文档交流

这是一本游戏设计方面的好书

转自天之虹的博客：http://blog.sina.com.cn/jackiechueng

感谢天之虹的无私奉献

Word版可到本人的资源中下载

第二十四章团队往往通过文档交流

游戏设计文档的神话

很多新手游戏设计师和其他爱做梦的人都会对游戏设计运作的过程抱有各种有趣的想法。在不熟悉“循环的法则”的情况下，他们以为游戏设计过程是靠一个天才游戏设计师坐在键盘前敲出一份壮丽完美的游戏设计文档的。当这篇伟大的著作完成以后，剩下只需把它交到一个有着程序员和美术人员的有能力的团队那里，等待他们把这个耀眼的构思转变为事实就行了。于是这些轻蔑而自诩的设计师会想：“只要我能找到一份游戏设计文档的合理格式，那我也能成为一名专业的游戏设计师了！我充满了创意，但缺少了这份魔法般的模板，我是无法设计出游戏的。”

我觉得澄清以下这点是极为重要的，因此我将要用一种非常大的字体。请靠近听清楚：

这种魔法般的模板是不存在的！
它从没存在过，也永远不可能存在。那这意味着文档不是游戏设计的一部分吗？不——文档是游戏设计中非常重要的一部分。但文档对每个游戏是不同的，对每个团队来说也不同。为了理解适用于你的游戏的文档结构，你必须先了解文档的目的。

文档的目的

游戏文档严格来说有两大目的：记忆和交流。

记忆

人类的记忆是很可怕的。游戏设计师会以数不清的重要决策去界定出游戏的运作方式和运作理由，但你会有很大机会无法全部记住所有这些决策。当这些耀眼的创意在你头脑里一闪而过时，你很可能感觉它们是不可能忘记的。然而经过两周以后，当你做了两百个游戏决策以后，即使是最精巧的解决方案也很容易会忘掉。假如你习惯了记录你的各种设计决策，那它会为你节省下一遍又一遍去解决同一个问题的麻烦。

交流

即使你天生有着完美记忆，但游戏中的各种决策还是必须交流给团队里的其他人的，而文档是达成这点的一种很有效的方式。并且正如我们在第23章里谈到的，这种交流不会是单向的。它会是一次对话，只要当一个决策落实到纸上后，肯定有人能从中找出问题或者是提出某种方法来让它变得更好。文档能把更多人的思维集合到设计上，让大家能更快地找出并修正好游戏设计中的缺陷。

游戏文档的类型

由于文档的目的在于记忆和交流，因此你需要的文档类型是取决于你所需要记忆和交流的内容的。很少有游戏是一个文档能满足所有需要的目的的——通常情况是制作出多种不同类型的文档。项目里有六个主要的群体需要记忆和交流不同的内容，他们中的每一个群体都会产生出自己特别的一类文档。

上图展示了一个游戏设计团队中可能发生的记忆和交流的途径。毎一个箭头都会产生一个或者多个文档。接下来让我们看看这六个群体中每一个会制作出哪些文档。

设计

1.
游戏设计概述（Game Design Overview）。这份高层面的文档可能只有短短数页。它通常是为管理层写的，让他们能足以理解游戏大概是怎么样的以及它定位在哪些人群上，而无需深入太多的细节里面。这份概述文档对整个团队来说也是很有用的，它能让团队了解到整个游戏的大图景。

2.
详细设计文挡（Detailed Design Document）。这份文档会以极大量的细节描述出所有的游戏机制和游戏界面，它通常满足两个目的：一是让设计师能记住他们提出和遇到的所有详细的想法，二是用于把这些想法传达给负责编码的程序人员和负责做出好看的外观的美术人员。因为这类文档是极少落入“外行人”眼里的，所以它通常会牵涉了能激起讨论和避免忘掉重要的想法的足够的细节。它们往往是所有文档中最厚的，也很少会一直保持更新。当到了项目一半的时候通常会完全废弃——因为到了这个程度时，游戏本身已经包含了这些重要细节中的绝大部分，那些没有放到游戏里的细节往往是通过非正式的渠道（例如通过Email或者短短几页的注解）调换了。

3.
故事概述（Story Overview）。很多游戏都会需要专业的作家来为游戏创作对话和剧情。这些作家通常都是签约的，很多时候会远离团队工作。游戏设计师往往发现在让他们执行写作之前建立一份简短的文档是很必要的，这份文档会描述了各种重要的设定、角色，以及在游戏中发生的各种行为。因为往往一个有着各种有趣的新创意的作家会依据自己的创意改变整份的游戏设计。

程序

4.
技术设计文档（Technical Design Document）。通常一个理解游戏有着众多与游戏机制无关的复杂系统，这些系统只是和屏幕上的显示机制、网络传输数据，以及其他棘手的技术上的任务相关。往往程序团队之外的人都不太关心这些细节，但一旦程序团队是由多于一个人组成时，这些细节通常要记录到一个文档里，这样才能看上加入到团队里的其他人能理解到整个整体是将要如何运作的。这就像详细设计文档那样，它们很少会在项目过了一半以后还持续更新，但书写这些文档往往比系统架构和编码要更重要和更本质。

5.
流水线概述（Pipeline Overview）。为一个视频游戏编程的大部分的挑战性工作都来源于把美术资源合理地整合到游戏里。这个过程中往往有着很多特殊的操作准则是美术人员必须遵循才能让美术在游戏里合理地呈现的。这份简短的文档通常是程序员为美术团队特地编写的，因此它是越简单越好的。

6.
系统限制（System Limitations）。设计师和美术人员往往完全不知道他们的设计中哪些是系统许可的（即使他们会假装知道）。对一些游戏来说程序员会觉得建立一份文档清楚明确下各种不可逾越的限制是很有用的，例如同屏的多边形数量，每秒钟发送的更新消息的数量，屏幕上同时发生的爆炸效果数量等等。通常这些信息也不是已成定局的，但确立了这种限制（并把它写下来）会在以后节省很多时间——并且这也有助于促成大家讨论，一起去想出创造性的解决方案来越过这些限制。

美术

7.
美术圣经（Art Bible）。假如多名美术人员是在同一款产品上工作，一起创造出一个统一一致的外观和感觉的游戏，那他们必须有着一些指引来帮助维持过程中的一致性。“美术圣经”正是提供了这些指引的一份文档。它包括了角色卡（Character Sheets）、场景环境实例、用色实例、界面实例，以及其他界定了游戏中所有元素的外观的因素。

8.
概念设定概述（Concept Art Overview）。在游戏制作出来前，团队里有很多人都需要了解整个游戏的外观将会是怎么样的。这正是概念设定的工作。不过通常单靠设定是不能说明说明的，它通常是在一部分设计文档中才能产生最大的意义，因此概念设定团队往往都会和设计团队一起工作，一起提出一组图画来展现出游戏设计将来成型时的外观和感受。这些早期的设定图会在很多地方里用上——例如游戏设计概述和详细设计文档，有时候甚至还会用在技术文档中，借以用来说明技术上希望达到的外观是怎么样的。

管理

9.
游戏预算（Game Budget）。尽管我们都希望“一直做到游戏完成为止”，但游戏行业的经济效益的事实使得很少能允许这种情况的发生。往往团队在完全了解到自己将要做出什么游戏之前就必须提出开发这个游戏的具体成本是多少。这个成本通常会通过一个文档来确定，一般是一份展开清单，里面试图列出游戏里所有需要完成的工作，然后通过开发时间估算来转化成金钱成本。单靠制作人或者项目经理来提出这些数字是不可能的，他们通常会和团队中的每部分紧密了解来尽可能精确地估算出这些数字。这份文档往往是第一批建立的文档，因为它是用来确保项目所需的资金的。一个好的项目经理会在整个项目过程中不断更新这份文档，以此来确保项目不会超出所分配的预算。

10.
项目计划（Project Schedule）。在一个良好运作的项目里，这份文档是最经常更新的。我们都知道游戏设计和开发的过程是充满着意外和各种意料不到的改变的。但尽管如此，一定程度的规划是必需的，理想来说，计划应该至少每周更新一次。一个好的项目计划文档会列出所有需要完成的任务、每一个任务需要花多长时间、每一个任务必须在什么时候完成，以及该任务是谁负责的。如果条件允许的话，这份文档可以放进软件里。对一个中型或者大型游戏来说保持这份文档的更新完全能变成一份全职工作。

写作

11.
故事圣经（Story Bible）。尽管有人可能会觉得游戏的故事是完全由项目里的作家（如果有的话）决定的，但往往情况是项目里的每个人都会对故事带来有意义的改变。引擎程序员可能会发现某些故事元素会带来技术上的挑战，于是提议对故事进行改变；美术人员可能对故事中一个全新的部分有着作家从来没想象到的视觉创意，游戏设计师可能对游戏玩法设定有着一些想法，需要故事也跟着做一些改变。故事圣经在故事许可和不许可的方面设立下权威，让团队里的每个人更容易对故事贡献各种创意，最终让整个故事和美术、技术和游戏玩法更好的整合在一起，从而让故事变得更强大。

12.
剧本（Script）。如果游戏里的NPC是会说话的，那他们的对话必定要来自于某些地方！这些对话往往是编写在一个剧本文档里的，它会从详细设计文档中分离出来，作为其附录。这里关键的在于游戏设计师都要复审所有的对话，因为很容易会发生某行对话和游戏玩法的规则不一致的情况。

13.
游戏教程和手册（Game Tutorial and Manual）。视频游戏是很复杂的，玩家必须有某种方式能学会怎样去玩。在游戏内部的教程里、网页上，以及印制的手册里都是录入这些指南的地方。在这些地方里所写的文字是很重要的——如果玩家不能理解你的游戏，他们怎么会喜欢它呢？你游戏设计中的细节很可能直到开发完成前的最后一分钟还在不断改变，因此重要的是确保有人不断地校正这些文字，保证它们一直和游戏的实现是准确对应的。

玩家

14.
游戏攻略（Game Walkthrough）。开发者并不是唯一写出跟游戏相关的文档的人！假如玩家喜欢一个游戏，他们往往会写出自己的文档并把它发到网上。详细研究玩家对你游戏所写下的内容，这样能很好地找出玩家具体喜欢和不喜欢你游戏里的哪些部分，能了解到他们觉得哪些部分太难或太简单。当然，当一份游戏攻略写了出来以后，想调整游戏往往也显得太晚了——但至少你能知道下一次该怎么做！

最后我再说一次，这些文档并不是一份魔法模板——世界上并不存在魔法模板！每个游戏都是不同的，它们在记忆和交流上的需求也是不同的，你必须自己去找出合用的文档方式。

那我该从哪里开始呢？

你只要像你最初开始设计你的游戏那样去开始就可以了。开始的文档里粗略地列出你希望在游戏里包含的各种创意。随着这份列表慢慢增长，在你脑海里也会衍生出各种设计上的问题——这些问题是至关重要的！务必把它们写下来，这样你才不会忘记！“着手设计”通常意味着不断去回答这些问题，因此你不应该遗漏掉任何一个问题。每当你满意地回答了一个问题后，记下你的决定以及你采取这样的决定的原因。渐渐地你会列出了各种想法、规划和问题，答案也会慢慢清晰起来，并自然地转变成各个章节。坚持不断记下你需要记住的东西以及你需要交流的东西，这样你不知不觉就会有了一份设计文档——这份文档不是基于一份魔法般的模板的，而是基于你那独一无二的游戏中那独一无二的设计有组织地成长起来的。

透镜#90：文档的透镜

为了确保你能编写出你所需的文档，并略过所有你不需要的，问一下自己以下的问题：

l 在制作这个游戏的过程中需要记住哪些东西？

l 在制作这个游戏的过程中需要交流哪些东西？