【译介】完成一份优秀的设计文档
原文为Tzvi Freeman 1997年的一篇文章Tzvi Freeman.
本文内容为我在机翻的基础上润色得出,难免错漏,也会在拿不准的地方给出原文。文中括号内的内容是我的补充和想法。
润色的有些潦草,但是其内容确实挺给我启发的。
以下为正文。
我得做出游戏!在恐慌和眩晕中,我的头撞在了CRT上,接下来我看到灯神从一支虚拟的青铜纹理的油灯中呼啸而出,并给了我三个愿望。我毫不犹豫地答道:“我要……
- 一个由有才华、有技术、有奉献精神的工程师和艺术家组成的伟大团队(包括一位非常善解人意的妻子)
- 足够的时间和金钱,有搞砸一两次的冗余
- 一流的设计文档
很久很久以前,当一个程序员(也许还要一位美术)用随用随取的预算和宽松的截止日期来制作游戏时,的确不需要如此重视文档。你知道想做什么,那就去做。如果过程中有一些重大改变,也不过是麻烦自己罢了。而在今天,一份彻底的、可读的文档可能意味着迅速堕入超预算的地狱和顺利进入打包压盘的涅槃之间的区别。
系统如何工作
大多数游戏都会经历三个发展阶段,从概念到设计再到制作。可以把它们看作是“灵感”、“文件”和“打磨”。
在第一阶段,概念文档是写给自己的信——清楚地列出目标,以防遗忘——也是给以后将产品推向市场的人提供的销售工具。有时,这个阶段也会制作一个小型原型,给你机会实验和修改你的想法。
中间阶段涉及到与艺术家、动画师、音乐家和工程师的大量讨论——尝试各类东西,找到组织、实现你想法的方法。
在最后阶段,管理的工作往往交给一些专业人员,原先的设计者可能是团队的一个部分,但许多情况下——特别是在大公司中——设计师最终成为了外部顾问。
毫无疑问,设计文档是项目的亲生父母对这个小婴儿如何成长施加最大影响的地方。即使你,设计师,决定兼任项目经理,也别自欺欺人认为掌握了所有情况。一个复杂的项目往往涉及了许多有才华的人,熟练的程序员和艺术家往往有他们自己的想法。当你打算创造一匹马的时候,艺术家可能在设想一个独角兽,而程序员可能在设想一个高效的骆驼。一份好的文档可以确保你们都在计划制作同样的东西。一个优秀的文档可以确保你们都对这个东西的内在灵魂有相同的感觉。把它想成是一个爵士乐队的总谱——既使每个人的思想统一,又还有很多空间让明星们去即兴演奏。
你的文档是你的思想和现实之间的一种中介。它确保你所想的是可行的,而且你最终得到的将是你最初所想的。
最后,请记住这句格言,任何资深游戏玩家都会证明:”伟大的艺术在于细节”。天才般的细节自然地从总体构架中流露出来,就像它们存在于最初的灵感闪光中一样。但是,一旦你进入实践的执行阶段,这种火花很容易就会熄灭。
挑战
对项目的部分进行原型设计很好——做任何能绘出的草图。但同样,这些细节才是最重要的。你的想象力能承载的细节越多,你的作品就越可能成为一个伟大的杰作。
根据文档工作也有坏处。开发一个令人兴奋的游戏本身必须是令人兴奋的。许多项目中最好的部分是在最后一刻的手忙脚乱中发现的。诚然,时间和成本预算的压力不允许永远重复概念,但你根本不能指望一个杀疯了的游戏能从枯燥的、可预测的工作中产生。挑战在于创建一个设计文档,使你的项目能够容忍意外的调整,又不失去其最初的方向和范围的完整性。
表1,文档的三个阶段。
| | 内容 | 目标 |
| —- | —- |—- |
| 1.概念文档 | 体裁;目标受众;描述;最引人注目的特点;市场信息;开发成本和时间。 |它定义了概念、范围、价值和可行性;向你的客户、出版商、雇主和风投推销这个想法。 |
| 2.设计文档 | 描述整个项目的主体和灵魂,包括所有细节,以及每个元素的实施方法。 |它确保所制作的东西是你想要做出的东西。|
| 3.制作文档 | 时间管理图(甘特图、PERT图等);任务数据库;预算电子表格;技术规格;Q/A数据库。|在预算范围内按时实施设计文件|
成功设计文档的十个要点
- 不仅描述肉体,还要描述灵魂。
如果游戏开发只是一个自动化的输入/输出问题——类似于写代码并能够预测它如何工作——你可以用一个简单的、描述性的文件来解决。但实际中开发是由人完成的,其中许多是有创造力的人,他们有自己的思想;大多数人会希望在他们所做的事物中留下自己的印记。
事情会变成这样:你向美术提出需求,并与他们讨论要做什么。然后你去拜访程序,仔细讨论需求。两个小组都对你说的一切称是。
那天晚上,在凌晨2点左右,就在C++星座在西方升起的时候,这个程序员遇到了中年危机,开始思考:”什么,我余生都会是一个程序?这是我母亲对我的期望吗?为什么,我可以像其他人一样设计一个游戏!” 而手却不停地敲打着代码。
大约在同一时间,美术刚刚在他的电脑前醒来,在等待一个复杂的三维渲染完成时陷入了深深的睡眠。他不确定也不关心自己是在做梦还是真的在为这一切得到报酬,而沉浸在艺术天才的狂野世界里,幻想和现实融为一体,晓星以从前无法想象的方式混合在一起——当然不是因为你的需求。
到了第二天早上,你的马已经变成了一只有两个驼峰的独角兽。对于有创造力的人,光是命令是行不通的,你需要激发他们的热情。
在你的设计文档中,不要止步于对每一个条款和细微差别的详细描述。花点时间来描述游戏应该有的感觉,每个元素背后的目的,每个用户将有的体验,以及你能设想和描述的游戏灵魂的任何其他方面。
例如,你正在设计一个射击游戏。你想在玩家真正遇到挑战之前训练他们应对这些挑战,所以你提前几步放置了不太致命的小挑战。你必须向开发团队的每个人解释这一点,这样他们就会明白为什么某些东西会在那里,为什么它们会以这样的方式工作。这样,即使(读作:当)你的团队玩弄和篡改你的想法,因为这些解释存在于纸上,你仍然可以希望结果将有相同或相似的整体效果,甚至更好。
- 使之易于阅读
来吧,为你的同伴提供整页的10个重点、无衬线字体、每行80个字符的文本,并要求他们阅读。你可能需要在包装中附带布洛芬——缓解那些真正费尽心思阅读的人的头痛。
可以遵循以下的准则保证良好的页面布局:
- 大量空白
- 文本主体使用衬线字体(对于字母,衬线体在大段文字时带来更佳的可读性)
- 粗体标题
- 保持段间距
- 文本句子简短
- 突出重点内容
- 分层次
- 用表格、图表、图片进行说明。将其制作得醒目一些。
- 优先级
现在你意识到你是在和其他有意识的自我一起工作了,你会体会到把某些游戏元素标记为神圣的紧迫性。诚然,我不敢打包票,但如果你足够谨慎地使用标签,它可能会得到一些尊重。但不要止步于此,不仅要你给想法打上标签,还要区分你打算做的事情和你想做的事情,如果时间、预算、技能组和技术条件允许的话。
然后是垃圾桶——那些听起来不错,但却因为更好的理由而被废弃的东西。明确地提到它们,并解释它们被放弃的原因。如果你不这样做,我几乎可以保证它们会被复活。以下是你的标签清单:
- 不可或缺的
- 重要的
- 如果可以的
- 放弃的
你可能希望使用视觉符号来表示这些。但不要依赖颜色,因为文件并不总是以彩色印刷。
- 深入细节
没有细节的文档是无用的。任何人都可以用他们喜欢的任何方式来解释笼统的内容。”不可杀人 “对摩西来说是一回事,对西班牙征服者来说就是另一回事了。详细说明你不应该杀谁,在什么情况下,会更有帮助。对你的文件来说也是如此。一旦你描述了一些实际的细节,并给出了一些例子,你的想法就会变得更具体——也更难被改动。
例如,不要只是说:”青铜鸟是无敌的”。准确地描述这个生物在被击中的每个可能的情况下会发生什么,以及它之后是如何恢复的。诚然,如果动画师有任何勇气和艺术尊严,你可以放心他不会遵循你的规定。但至少他对你想要实现的目标有一个清晰的概念,而且他的修改不会严重改变游戏的相关部分。
不要只是说,”在这一点上,用户将必须按下跳跃键与方向键来爬墙”。描述一下如果玩家尝试其他方法会发生什么。解释为什么你认为用户能够找出你所提供的组合。解释一下环境中的什么东西表明有可能爬上这面墙。
同样,你的艺术家会想出别的办法,也许比你最初的构想更合适。这就是真正的成功,最终结果甚至比你在纸上描述的更接近你最初的灵感概念。除非你首先清晰地描述你的概念,否则这不会发生。
不要只是说:”Bongo Man比Bongo Boy更强,但Bongo Boy的反应速度更快。” 使用表格、电子表格和图表,为角色的移动速度、角色能承受多少次攻击、角色的攻击造成多少伤害、一次攻击动画需要多少帧等等,赋予真实的数值。这种电子表格在Q/A和调整阶段非常重要。
不要只是说:”大多数人在几天内就能搞清楚整个游戏。” 做一张不同玩家的产品寿命预测图,说明你期望在哪个时间点上提供哪种功能。用户测试以后将为你设计下一个游戏提供宝贵的反馈。
- 有些事情必须得到证明
有时几张粗略的草图就足够了,但如果这个想法对你的项目概念真的很重要,你可能想自己制作一个粗略的动画。当元素的行为变得过于复杂和模糊而无法在纸上描述时,你会想做一个原型。原型的一个好处是往往会带来一个更简单、更优雅的解决方案。
即使你制作了动画和原型,也要用文字把概念表达出来。诚然,一个动画抵得上一个千兆字节的文字,但文字能以动画所不能的方式进行沟通。文字还可以清楚地说明在观看动画时可能会错过的重要细微差别。
- 不仅是“做什么”,更是“怎么做”
在现实世界中,“怎么做”决定了“做什么”。例如,你选择了粘土动画。制订了捕捉图像的过程,并记录一切。背景应该是什么材料和什么颜色?应该使用什么相机,为什么?处理所拍摄画面的步骤是什么?等等,不一而足。如果你尝试过,你会知道这些因素中的任何一个都会对最终结果产生严重影响。
或者假设你正在开发一款摩托车赛车游戏。你说,摩托车必须按其不同的优点和缺点进行平衡。你甚至提供了一个图表,显示它们的平衡程度。然后你说调整是必要的。说明你打算如何调整——过程是什么?假设你游戏中的主角是歌剧魅影。描述一下玩家的键盘是如何被映射到管风琴的,提供包含每个键的图片,说明有多少通道的声音可以使用。和你的程序员一起讨论,找出每个细节的方法。然后把它记录下来。两个不同的“怎么做”可能意味着两个非常不同的结果。
- 提供备用方案
项目经理花了很多时间在他们的各种表格上T上。就个人而言,我不能确保这些东西对游戏开发是高效的——主要是因为有太多的不可知因素。你的游戏技术越是激进和先锋,开发流程的可预测性就越低。为了确保你的团队如期达到你的里程碑,你能做的最好的事情就是提供不止一种做事的方式。
让我们回到用键盘弹奏管风琴的例子。你的程序向你描述了一个终极方法,它可以为用户提供巨大的能力和深度,获得令人敬畏的、花哨的结果——实施成本约为50个工时。就像我们讨论过的其他事情一样,你把整个事情记录下来。
你不能止步于此。你必须问:”如果我们只是想要一个经过简化的八通道管风琴,那么要做什么?我们需要什么来实现最低限度的要求?如果我们只是让一些实习生来做这件事呢?” 然后,你也要把这些都记录下来。当死线到来之时,你就可以用一句简单的 “好吧,做C计划 “来拯救你的项目肤。
我在产品设计中犯的最大错误之一是问程序:”能不能做?” 除非你问的是一个一流的程序员,否则这个问题是没有用的。更具体地说,回答可以分为三类之一。
(糟糕的程序员)”当然,这没有问题。”
(平庸的程序员) “不。不能做。”
(一流的程序员) “我可以这样做,需要两个星期。或者我可以像这样稍作修改,这将只需要五个小时。”
始终要求提供一个以上的选择,并估计每个选择需要多长时间。然后表明你的偏好——如果我们有时间就做这个,如果没有时间就做那个。
- 赋予其生命力
我已经警告过你不要扼杀灵感和自发的创造力,这些灵感和创造力来自于看到想法在你手中成为活生生的物体的兴奋和乐趣。你必须容忍你文档的变化——由你或由(希望是聪明的)其他人进行。
我第一次学到这个教训是在不列颠哥伦比亚大学主修音乐创作时。经过一番努力,我写了一首新文艺复兴时期的铜管五重奏,我对此感到非常自豪。我的教授也喜欢它。然而,当我们把它拿给学院的明星铜管五重奏排练时,我在十秒钟内经历了惊恐、难以置信、愤慨和临床抑郁的几个阶段。五重奏开始演奏,然后在大号手的示意下停止。那个家伙拿出铅笔,开始改了几个音,然后大家继续演奏。这种情况不止一次发生。
我的教授注意到我几近昏厥,转身对我说:”别担心,他们对莫扎特也是这样。而且他们通常是对的。”
事实是,无论什么东西在纸上看起来有多好,当它进入客观认知的具体世界时,最伟大的专家仍然会修改东西。尽管如此,你并不希望目睹你的设计和梦想被无情地蹂躏。相反,你希望有一种有机的增长——想法从你种下的种子中自然生长,而不需要外来的肢体嫁接到它们身上。
这里有一些创建文档的技巧,它可以容忍变化而不破坏最初的想法或破坏开发过程:
- 一定要把那些对游戏概念非常重要、不能改变的方面说清楚。
- 要确保每个人都明白游戏应该有的感觉,以及每个细节的目的。
- 如果信息是重复的,必须相互参照。否则,如果有变化,你就会出现相互矛盾的指示。
这里有一些关于实际执行阶段的提示:
- 当有人建议进行改变时,在你的设计文件中回头看看它是否与你游戏的“灵魂”相一致。
- 检查这是否只是一个孤立的变化,还是对全局生态有重大影响。如果是后者,就把它留到你的下一个项目中。
- 更新设计文件,并包括改变的原因。或者,如果你没有做这个改变,就说出来,并解释为什么它被拒绝。
- 更改、删除和被拒绝的想法应该保留在主文件中,以避免对同一件事讨论两次。
- 每个人都必须从同一个版本开始工作。过去的版本应该被销毁。
- 关键的、重要的和紧急的:设计文件必须只在一个人的监督下维护。
- 没有人可以说:“我这样做是因为我在文件中找不到任何关于它的参考。”
我见过的文件甚至连页数都没有。然后他们就抱怨人们没有按照指示去做。每一个好的文字处理器都会自动为页面编号,并在每一页的页眉或页脚打印日期和标题。有些甚至会允许你在新的章节改变页眉。使用粗体字来引导对重要材料的注意。使用交叉引用,就能在文件的不同部分随心所欲地重复自己的内容,这样你可以一起更新所有内容。做一个完整的目录。
你可能希望使用HTML编写你的文件并提供超链接。一些先进的文字处理程序提超链接接功能,而不需要HTML。但请记住,更多的时候,人们更喜欢用硬拷贝(即打印出来)来工作。(这样,在每小时的系统崩溃后重新启动时就有东西可读了)
(但是在2023年的今天,我推荐用树形结构的云文档组织策划案。)
- 以良好的状态交付
在所有这些之后,你需要尽你所能,促进每个人真正阅读和使用这个东西。一堆纸是不会被阅读的——它看起来不够重要。只有有着精装封面的东西才看起来重要。
建立一份应该拥有副本的每个人的名单。保留该名单。把整个清单打印出来,在每页的页眉处注明日期。打孔并装入活页夹。在每个夹子的书脊和封面上贴上标签。当有更新时,向每个人提供修改后的页面。在某些时候,你可能需要提供新的文档,扔掉旧的。
总结检查…
电影制作人使用移动脚本,建筑师使用蓝图,音乐家使用乐谱,根据远古的传说,甚至宇宙的创造者也创造了一份设计文档——他后来让几个先知偷看了一下——写在最前面的是“要有光!”。因此,游戏开发者遵循他们的超凡榜样,当然也可以这样做。做对了,剩下的路就会一帆风顺。
本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!