From Evernote:

阐述如何制作一流的游戏设计文件 | GamerBoom.com 游戏邦 Clipped from: http://gamerboom.com/archives/38176

成功的设计文件十个要点

1、除了形体，还要描述灵魂。 如果游戏开发只是自动输入/输出的问题（就像编写代码和预测过程）——那么你只需要一份干巴巴、描述性的文件就行了。但事实是，开发是人做的， 这些人是有创意的人、有独立想法的人、想在所有自己做的工作上盖个戳的人。

再继续说你想要的那匹马的故事：你把说明书交给美工，然后和他们讨论要做什么。之后你给程序师看了下说明书。两边都对你所说的话点头称是。

当天晚上，大约凌晨2点，正当C++的群星闪烁在西天，处于中年危机的程序师开始胡思乱想："什么，我的下半辈子就是一个程序呆子？我妈对我的指望就这样？为什么，我也可以像其他人一样设计游戏！"然后继续埋头输代码。

大约与此同时，美工等着他那台陷入死机的电脑完成复杂的3D渲染，等着等着就睡着了，这会儿刚醒过来。他不确定也不关心他是不是在做梦，或者从这些工作中取得报酬，只是沉浸在艺术天才的狂想世界里，在不可思议的幻想和现实的融合作用下，神兽诞生了——当然不是你文件所描述的那匹马。

第二天一大早，你的马，当然没来，来的是长着两个驼峰的独角兽。对于这些创意星人，光给指示行不通，启发才是硬道理。

在你的设计文件中，别满足于对各个物品和细微差别的细节性描述。花时间形容一下游戏应该有的感觉、各个元素潜在的目的、玩家应该有的体验和你可以想到的、能够形容的游戏灵魂的方方面面。

例如，你在设计一款射击游戏。你的目标是通过游戏训练玩家如何应对现实中遇到的某些挑战，所以一开始设定的难度不高。你得向团队的所有成员解释你的用意，这样他们才会理解为什么某些东西要放在这，为什么要这样做。即使你的团队不太认真地对待或胡乱删改你的创意，你仍然可以抱着希望，即结果达到或接近整体效果。或者可能还更好。

2、易读性。给团队成员一份每页标明10个要点、无衬线字体印刷、80个字符一行的文本，并且要求每个人都要阅读。你可能得在每件份文件里准备一捆止痛药了——这是为那些确实要忍痛遵守指令的人准备的。

以下是我遵循的页面布局原则：

大片空白

文本主体以衬线字体（游戏邦注：指西文中有衬线的字体，与汉字字体中的黑体相对应）印刷

粗体字标题

段与段之间有空隙

文本句子简短

引导视线直指重点内容

分层次，大纲视图

用表格、图表、图片等说明例子。把图表、表格、图片等制作得醒目一些。

3、区分优先次序。既然你意识到你是和头脑清楚、有自我的人一起工作，就有必要让这些人意识到某些加标记的游戏元素的神圣性。我确实不敢打包票，但如果你能好好利用标记，你想强调的地方大概还是能得到一点尊重吧。这还没完，既然打了标记，当然还要区分不同的标记含义——有些是你计划要做的，有些是时间、预算和技术允许就做的。

然后垃圾来了——那些听起来很棒，实际上完全有理由当成垃圾的东西。你需要明确地指出来并解释需对其警惕的原因。如果你不这么做，我敢说这些垃圾还是会再跑出来。以下是标记列表：

不可缺少

重要

如果可能

否绝

你可能希望用上一些视觉符号来代替标记。但不要依赖颜色，因为文件不一定总是彩色印刷。

4、深入细节。没有细节的文件毫无用处。大家可以随意地理解大纲。"Thou Shalt Not Kill"（不可杀生） 这句话对摩西来说是一个意思，对西班牙征服者来说是另一个意思。详细地说明哪些角色不能杀、为什么不能杀、还有什么用途。设计文件也是一样：一旦你描述了一些实用的细节并给出相应的例子，你的想法就具体化了——不会被轻易地晒在一边。

例如，不要只说："铜鸟是无敌的。"明确地描述这家伙被攻击时会发生什么情况及之后如何恢复。确实，如果动画师有脾气又有艺术家的尊严，你可以肯定他不会听从你的指示。但至少他会另想出一个更清楚的、又不违背你的主意，且他的修改不会严重地改变相关的部分。

别只说："此时，用户会按下带箭头的跳跃键爬上墙。"而是详尽描述如果玩家不那么做会发生什么情况。解释为什么你认为用户能够想到你所提供的操作组合。解释环境暗示玩家爬墙的可能性。

另外，美工也会冒出其他想法，可能比你最初的设想更适合。如果是那样，那就真是太好了，因为成品可能甚至比你的纸上描述更接近你最初的灵感。但除非你一开始就清楚地描述了你的概念，不然这种事不可能发生。

别只说："Bongo Man 比Bongo Boy更强大，但Bongo Boy的反应更快。"请用表格来表现角色的动作速度值、角色可拥有的攻击点数、角色的攻击伤害点数、发动攻击需要的能量等等。这种表格在Q/A和制作阶段是非常有价值的。

别只说："大多数人会在几天内想通整个游戏。"制作表格，用于预测不同用户持有的产品的寿命；表明你希望各种功能特征被发现的时间点。之后的用户测试会为下一款游戏的设计提供有价值的反馈。

5、演示某些东西。有时候，几张草稿就够了，但如果这个创意对你的概念和项目确实重要，你可能得亲自制作粗略的动画。当元素的活动太过复杂和模糊，难以用文字表达，你就得制做原型。原型的好处之一是，通过实践往往可以催生更简单更高明的解决方案。

除了提供动画和原型，你还是需要提供概念的文字描述。动画确实比十亿字节的文字更有价值，可是文字也有动画无法达到的交流效果。看动画时可能会遗忘了某些重要的差别，而文字可以清晰地描述出细微之处。

6、别只说"什么"而不说"如何"。在现实世界，"如何"决定了"什么"。例如，假设你已经选择了粘土动画，那么就要制定出捕捉画面的方法，然后在文件中描述这个过程。背景应该用什么材料和什么颜色？应该用什么摄像技术和为什么用这种摄相技术？塑造框架的步骤是什么？等等等。如果你尝试过，你会知道这些因素中的任意一个对结果都有重大影响。

或假设你在制作一款摩托车竞赛游戏。你表示摩托车必须在优势和弱点之间达到平衡，所以你要在文件中提供实现平衡的表格，并注明调整是必要的，还要说明你打算如何实现调整——过程是什么？假设游戏的主要角色是歌剧幽灵。描述玩家的键盘如何映射管风琴键。提供一张各个键的映射图。列举发声的可用渠道的数量。和你的程序师讨论一下怎么实现各个细节，再用文件记录下来。两个不同的"如何"可能会产生非常不同的结果。

7、提供替代性选择。项目经理耗费大把时间在制作甘特图和PERT项目评估上。个人认为，我真的不敢说这种东西对游戏开发是有效的——很大程度上是因为未知的东西太多了。你的游戏技术越激进越新，开发过程中可预测的情况就越少。要保证你的团队达到日程表上的阶段时间点，你能做的不过就是提供另一条通路。（游戏邦注：甘特图：美国工商业管理专家甘特设计的，是一种用平行线表示一定时间内生产的计划数字和实际完成数字的图表；PERT项目评估：在一个给定的项目中对潜在任务进行分析的一种方法。）

我们返回键盘映射管风琴键这个例子。你的程序师向你描述实现最佳效果的最终方法，此法需要50人/小时来执行。因为我们已经讨论过其他事了，所以你已经记下所有东西。

你不能止步于此。你得问："如果我们只需要一个切边、8槽的管风琴，要费多少人力时间？如果是绝对最小值呢？如是要我们只有几个助理能做这个怎么办？"然后你照旧记下一切。当最后面临抉择之时，你只需要脱口而出："好吧，计划C。"

在文件设计方面，我犯下的最大的错误就是问程序师："这办得到吗？"除非你问的是一流的程序师，否则这个问题根本就是白问。更具体地说，回答可以分成以下三种：

（差劲的程序师）："当然，没问题。"

（一般的程序师）："不，不能。"

（一流的程序师）："我这样做要花两周的时间。或者我可以小调整一下，只要五小时。"

总是不忘问另种方法和所需时间。然后表明你的倾向——如果有时间就这样做，否则就做罢。

8、允许修改。灵感和创意往往与兴奋和乐趣同在，我已经警告你要防止闷死这种灵感和自然的创意。你得允许设计文件被你自己或其他人（但愿是有才能的人）修改。

我在British Columbia大学主修音乐作曲时第一次吸取了这个教训。千辛万苦，我终于写好了一个新文艺复兴的铜管五重奏，我真是相当自豪。我的导师也很喜欢。当我们把乐曲拿给学院的铜管乐队演练，然而，在十秒钟的时间内，我的情绪就经历了几个阶段的起伏：惊骇、怀疑、愤怒和沮丧。乐队开始演奏了，一个大号手停下来向其他乐手示意，接着他取出笔开始修改几个音节，然后所有人又继续演奏。这种情况发生了不止一次。

我的导师，注意到我的脸色突然苍白了，转过身来对我说："别担心，他们对莫扎特的曲子也这样。他们通常是对的。"

真相是，无论在纸上看起来有多好的东西，被置于现实世界的客观解读之下，最棒的专家仍然会修改它。虽然如此，你不想目睹自己的设计和梦想被无情地篡改。你希望自己的灵感以一种自然的姿态成长——永远是那颗你播下的种子，它的成长不经过外来根枝的嫁接。

以下技巧可以帮助你制作出一份可接受修改，又不会中断原始想法或扼杀开发进程的文件：

如果某方面是游戏概念的重点，确保大家牢记于心。

确保所有人领会游戏的灵魂及各个细节的用意。

如果有信息重复，必须互相参照。否则，如有改变，就会产生矛盾指示。

以下是实际执行阶段的技巧：

当有人提出改变时，回头检查你的设计文件，看看它是否和游戏的"灵魂"一致。

检查这是否是独立的改变，或它是否产生系统性影响（牵一发而动全身）。如果是后者，就在下一份计划中拯救它吧。

及时更正设计文件，包括修改的原因。或如果你不想修改，明确指出并解释原因。

修改、删除和否绝想法应该保留在主控文件中，以免重复讨论相同的事。

所有人都必须以相同的版本作为工作对象。过去的版本应该销毁。

重要的、关键的和紧急的一点：设计文件必须置于一人且仅有一人的监管之下。