作者：Tzvi Freeman

我必须做出一个游戏。就在不知失措、头昏眼花之时，我一头撞在了电脑显示屏上。接着，古铜色的灯里轻烟似地冒出了个灯神，许诺我三个愿望。我不假思索地说：“我想要……

*一支有才能、有技巧、有献身精神的程序师和美工组成的团队（包括非常善解人意的老婆一枚）且个个擅长人际交往。

*足够的时间和资金允许搞砸一两次。

*一流的设计文件。

很久以前，编写一款游戏只需要一名程序师（和一名美工）加上接了就做的预算和宽松的开发期限，所以大家对文件编制没必要太上心。你知道想要什么就去做什么。因此，如果在这过程中发生了个把重大变故，你只能责怪你自己。现在，一份周全易读的设计文件意味着什么呢？就是迅速地坠入一文不值的地狱和平稳地飞升到富丽堂皇的天堂之间的差别。

如何展开工作？

大多数游戏的开发从概念到制作完成需要经历三个阶段，即“产生灵感”、“纸上计划”和“身体力行”。

在第一阶段，概念文件不仅是一封写给自己的信——提醒你不要忘记它们；还是一个应对投资商和营销商的销售工具。有时候，还要在这个阶段制作一个微型原型，这样你就可以用它做实验并修改自己的创意。

第二阶段是和一大堆美工、动画师、音乐师和编程人员讨论——实验想法，然后找出组织办法，最后敲定主意。

在最后阶段，管理制作过程的工作通常交给一些擅长处理流程和冲突的行家负责。原创意的设计师可能只允当团队的主要成员，但在许多情况下——特别是在大公司，这位设计师往往变成旁观的顾问。

毫无疑问，如果说设计文件是项目的父母，那么它对项目的成长影响当然最大。即使作为设计师的你兼任项目经理，你也不能欺骗自己：你确实不能全盘兼顾。复杂的项目需要许多有才能的人共同完成。有技术的程序师和美工往往有自己的一套心思。当你打算做一匹马，美工画出的可能是只独角兽，而程序师想到则是吃苦耐劳的骆驼。好的设计文件可以确保大伙想法一致、感觉一致。这好比一支大乐队的爵士乐总乐谱，尽管仍然有大量即兴表演的余地，但在总乐谱统领作用下，大家的心思都被放在一处。

设计文件是想法与现实之间的桥梁。它能确保承载想法的野马不会脱缰跑出现实所能驾驭的范围，同时又保证最后抵达的终点正是最初创意的指向。

最后，记住这句久经玩家证实的格言：“伟大的艺术来自细节”。光彩夺目的细节自然而然地从游戏中流露出来，就好像它们当初从第一道灵感中闪现光芒一样。但是，一旦你进入实际的执行阶段，细节的火花往往容易熄灭。

挑战

给项目制做局部原型当然是个好主意——尽可能画出所有草图。但此外，那些细节才是最重要的。你的想象能承载的细节越多，你的作品就会越出色。

根据文件工作也有消极面。刺激的游戏的开发过程本身就必须刺激。例如，有许多项目的闪光点往往是到了令人恐慌的截止期时才被发现。诚然，时间和成本预算的压力不允许概念的不断重复，但你只是不希望做出一款干巴巴、没惊喜的游戏。制作设计文件的挑战在于，能够忍受你的项目发生意料之外的调整，但又不迷失原创意的整体方向和视野。

成功的设计文件十个要点

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9、应提供必要的参照和指示内容。我曾见过有些人的文件甚至连页码都没有，结果却抱怨成员没有遵循文件指示。优秀的文字处理器会自动计算页数并且印刷每一页的日期和页眉或页角。有些甚至允许你在新章节里改变页眉。用黑体字印刷重要的内容。你可以随意在不同的部分重申你自己的想法，前提是你把重申的部分相互参照了，这样你就可以一次性更新所有内容。制作一个周全的内容表格。

你可能希望用HTML写下你的文件和运用超链接。有些高级的文字处理器不需HTML也能使用超链接。但记着，人们往往更喜欢看着死复印件文本（因为有了实实在在的文件在手，那么在系统崩溃后重新启动的一个小时内，就还有点东西可以读）。

10、好文件也要好包装。最后，你需要做的就是使文件便于阅读和使用。没有愿意阅读一叠纸——因为看起来也不重要。只有带硬封面的东西看起来才重要。

制作一份应持有复印件人员的名册并进行保存。打印出所有东西，且每一页都要带眉头和日期。接着在每一页上打洞做成活页。最后在每一份活页本的书脊和封面上贴标签。更新时，人手一份校订页。有时，你可能需要提拱新活页本，丢掉旧活页本。

总结

电影制作人使用步骤原稿。建筑师使用蓝图。音乐家使用乐谱。根据古代的传说，甚至是宇宙造物主也制作了设计文件，在最初的文明之光普照大地之前，他让一小撮先知瞄了一眼——所以有了这个古代传说。既然神都是这么做的，那么游戏开发者就以之为榜样吧。

游戏邦注：原文发表于1997年9月22日，所涉数据及事件均以此为准。（本文为游戏邦/gamerboom.com编译，如需转载请联系：游戏邦）

Creating A Great Design Document

by Tzvi Freeman

I’ve got to get product out. In the panic and dizziness, my head smashes against the CRT and next thing I know this genie whiffs up out of a virtual bronze-texture-mapped lamp and offers me three wishes. Without missing a beat, I answer, “I need…

A great team of talented, skilled, and dedicated engineers and artists (including a very understanding wife) with strong interpersonal skills.

Enough time and money to allow for a mess-up or two.

A first class design document.

Once upon a time, when coding a game involved one programmer (and maybe an artist) with a take-it-as-you-go budget and a loose deadline, documentation didn’t need to be taken so seriously. You knew what you wanted to make and you made it. If there were a few major changes along the way, the only one to complain was you. Nowadays, a thorough and readable document can mean the difference between a swift descent to budgetless Hell and a smooth ride to shrinked-wrapped Nirvana.

How the System Works

Most games go through three development stages, from concept to design to production. Think of them as “flash,” “paper,” and “grind.”

In the first stage, the concept paper acts both as a letter to yourself – setting out your goals clearly so you won’t lose sight of them – and as a sales tool for whomever takes the product to market down the road. Sometimes, this stage involves a working mini-prototype as well, which gives you a chance to experiment and revise your ideas.

The intermediate stage of design involves a lot of discussions with artists, animators, musicians, and engineers – trying things out, and finding ways to organize and set down your ideas.

In the final stage, production management is often left up to some expert in moving trains and tracks without major collisions. The original designer may be an integral part of the team, but in many cases – especially in large companies – the designer ends up as a kind of outside consultant.

Without question, the design document is where the original parent of the project exercises the most influence on how this little baby is going to grow up. Even if you, the designer, have decided to double as project manager, don’t delude yourself into thinking that you hold all the reins. A complex project involves many talented people. Skilled programmers and artists tend to have minds of their own. While you intend to create a horse, the artist may be envisioning a unicorn and the programmer a highly efficient camel. A good document ensures that you are all planning to make the same thing. A great document ensures you all have the same feel for the inner soul of this thing. Think of it as a big band jazz score – it puts everybody’s mind in the same place, even when there’s still plenty of room for the stars to improvise.

Your document is a sort of intermediary between your mind and the real world. It ensures that what you have in mind is something that the real world is able to handle, and that what you end up with will be what you originally had in mind.

Finally, remember the adage to which any salty gamer will attest: “Great art is in the details.” Brilliant details flow naturally from the general gestalt as though they were present in that first flash of inspiration. But once you get into the hands-on implementation, it’s easy to lose that spark.

The Challenge

Prototyping parts of the project yourself is definitely a good idea – make whatever rough sketches you can. But again, it’s those details that count. The more details your imagination can hold, the greater a masterpiece your work will be.

Working from a document has a flip side, as well. Developing an exciting game has to be exciting. Some of the best parts of many projects were discovered in the heat of last-minute deadline panic. True, the pressures of time and cost budgeting don’t allow for perpetual reiteration of concept, but you simply cannot expect a killer game to come out of dry, predictable work. The challenge is to create a design document that will allow your project to tolerate surprise adaptations without losing the integrity of its original direction and scope.

Table 1. The three stages of documentation.

Contents    Purpose

1. Concept Paper    Genre; target audience; description; most compelling features; market information; cost and time to develop.    It defines the concept, scope, worthiness and feasibility; sells the idea to your client, publisher, employer, and venture capitalist.

2. Design Document    Description of the body and soul of the entire project, with all the details, and the method by which each element will be implemented.    It ensures that what is produced is what you want to produce.

3. Production Documents    Time-management charts (Gantt, PERT, and so on); task database; budget spreadsheet; technical specifications; Q/A database.    It implements the design document on time and within budget.

Ten Points for a Successful Design Document

1. DESCRIBE NOT JUST THE BODY, BUT THE SOUL. If game development was just an automated input/output issue – something like writing code and being able to predict how it’s going to work – you could get by with a dry, descriptive document. The reality is that development is done by people, many of them creative people, who have their own minds; most will want to leave a stamp of that mind on everything they do.

It works like this: You provide specs to the artists and discuss with them what to do. You then visit the programmers and go over their specs. Both groups nod to everything you say.

That night, around 2AM, just as the constellation of C++ is rising in the west, the programmer reaches a mid-life crisis and begins to think, “What, a geek programmer the rest of my life? Is this what my mother expected from me? Why, I can design a game just as well as anybody else!” And the hands keep typing code.

Around the same time, the artist has just woken up before his machine, having fallen into a deep stupor while waiting for a complex 3D rendering to finish. Unsure and not really caring whether he’s dreaming or is actually getting paid for all this, immersed in that wild world of artistic genius where fantasy and reality blend as one, the phosphors come together in ways previously unimagined – certainly not by you.

By the next morning, your horse has become a unicorn with two humps. With creative people, instructing is not good enough. You need to inspire.

In your design document, don’t satisfy yourself with a detailed description of every article and nuance. Take time to describe the feel that the game should have, the purpose behind each element, the experience each user will have, and any other aspects of the game’s soul you can envision and describe.

For example, say you’re designing a shooter. You want to train your players to deal with certain challenges before they actually meet them, so you place less lethal mini-challenges a few steps in advance. You’re going to have to explain that to everybody on the development team, so they’ll understand why certain things are where they are and why they work the way they do. That way, even if (read: when) your team toys with and mangles your ideas as they exist on paper, you can still harbor hopes that the outcome will have the same or similar overall effect. Or maybe even better.

2. MAKE IT READABLE. Go ahead, provide your people with full pages of 10-point, sans serif, 80-characters-per-line text, and demand that they read it. You may want to bundle Advil in the package – for those who actually take the pains to obey orders.

I try to follow at least some of the guidelines of good page layout.

Plenty of white space

Serif font for body text

Bold headers

Spaces between paragraphs

Short lines of text

Direct the eye towards important material

Use a hierarchical, “2D” format (see what I wrote about outliners in the “Design Documentation Tools” sidebar)

Many instances call for a table, spreadsheet, or chart. Use them and make them sensibly attractive.

3. PRIORITIZE. Now that you realize that you’re working with other conscious egos, you’ll appreciate the urgency of tagging certain game elements as sacred. True, there are no guarantees, but if you use the tag sparsely enough, it may get some respect. But don’t stop there. As long as you’re tagging ideas, you’ll also want to distinguish between things that you intend to do and things that you’d like to do if time, budget, skill sets, and technicalities permit.

Then there’s the trash bin – things that sounded great, but were trashed for good reason. Refer to them explicitly and explain the reason that they were trashed. If you don’t, I can almost guarantee that they will be resurrected. Here’s your list of tags:

Indispensable

Important

If Possible

Rejected

You may wish to use visual symbols to represent these. Don’t rely on color, since documents aren’t always printed in color.

4. GET INTO THE DETAILS. A document without details is useless. Generalities can be interpreted by anybody in any way that they like. “Thou Shalt Not Kill” meant one thing to Moses and another to a Spanish conquistador. Detailing whom you shouldn’t kill and under which circumstances would have been more helpful. The same holds true for your document: Once you’ve described some practical details and given some examples, your idea becomes more concrete – and harder to shove around.

For example, don’t just say, “Bronze bird is invincible.” Describe exactly what happens to this creature in each possible instance of its being hit, and how it recovers afterward. True, if the animator has any spunk and artistic dignity, you can rest assured that he won’t follow your specifications. But at least he’ll have a clear idea of what you want to achieve, and his modifications won’t seriously alter the related portions of the game.

Don’t just say, “At this point, users will have to press the jump key with the arrow key to climb the wall.” Describe what will happen if a player tries anything else. Explain why you think users will be able to figure out the combination that you’ve provided. Explain what about the environment suggests that it’s possible to climb this wall.

Again, your artist will come up with something else, perhaps something even more suitable than what you originally conceived. That’s real success: When your developers’ results come out even closer to your original flash of conception than what you were able to describe on paper. But this won’t happen unless you first lucidly describe your concept.

Don’t just say, “Bongo Man is stronger than Bongo Boy, but Boy has faster reflexes.” Use tables, spreadsheets, and charts to assign real values to the character’s speed of movement, how many hits the character can take, how much damage the character’s hits do, how many cels it takes to animate a hit, and so on. This sort of spreadsheet is invaluable in the Q/A and tweaking stages of production.

Don’t just say, “Most people will figure out the whole game in a few days.” Make a chart of predicted product life in different households, indicating at which points in time you expect various features to be discovered. User testing will later provide valuable feedback for designing your next game.

5. SOME THINGS MUST BE DEMONSTRATED. Sometimes a few rough sketches are enough, but if the idea is truly important to your concept of the project, you may want to make a rough animation yourself. When behaviors of elements become too complex and ambiguous to describe on paper, you’ll want to make a prototype. A side benefit of prototyping is that this practice often leads to a simpler, more elegant solution.

Even when you provide animations and prototypes, put the concept in words as well. True, an animation is worth a gigabyte of words, but words can communicate in ways that animations can’t. Words also clearly spell out the vital nuances that may be missed when watching the animation.

6. NOT JUST “WHAT” BUT “HOW.” In the real world, the “how” determines the “what.” For example, suppose you’ve opted for claymation. Work out the process of how the images will be captured and document everything. What material and what color should the backdrop be? What camera should be used and why? What are the steps for processing the captured frames? And on and on. If you’ve tried it, you’ll know that any one of these factors can have a serious impact on the end result.

Or suppose you’re working on a motorcycle racing game. You state that the motorbikes must be balanced by their differing pros and cons. You even provide a chart that shows how balanced they are. Then you state that tweaking will be necessary. State how you plan to tweak – what is the process? Suppose the main character in your game is the Phantom of the Opera. Describe how the player’s keyboard is mapped as a pipe organ. Provide a map of each key. Specify how many channels of sound will be available. Talk it over with your programmer and work out every detail of how. Then document it. Two different “hows” can mean two very different results.

7. PROVIDE ALTERNATIVES. Project managers spend a lot of time with their Gantts and PERTs. Personally, I can’t really say that this stuff is effective for game development – principally because there are just so many unknowables. The more radical and pioneering your game technology, the less predictable the development stream is going to be. The best thing you can do to ensure that your team reaches your milestones on schedule is to provide more than one way of doing things.

Lets go back to the keyboard as pipe organ example. Your engineer describes to you the ultimate method of getting awesome and funky results with tremendous power and depth to the user – at a cost of about 50 person-hours to implement. As with everything else we’ve discussed, you document the whole thing.

You can’t stop there. You’ve got to ask, “What would it take if we just wanted a trimmed-down, eight-channel pipe-organ? And what will we need to achieve the bare minimum? And what if we just had some assistant doing this?” And then you document all that as well. When the FedEx truck is on its way over for the final daily pickup, you’ll be able to save your skin with a simple, “OK, do Plan C.”

One of the biggest mistakes I’ve made in product design is asking engineers, “Can it be done?” Unless you’re asking a first-class programmer, the question is useless. More specifically, responses fall into one of three categories:

(Lousy programmer) “Sure, that’s no problem.”

(Mediocre programmer) “Nope. Can’t be done.”

(First-class programmer) “I could do it like this and it’ll take two weeks. Or I could make a slight modification like this and it’ll take five hours.”

Always ask for more than one alternative and an estimate of how long each will take. Then indicate your preference – do this is if we have time, or this if we don’t.

8. GIVE IT A LIFE. I’ve already warned you against strangling the inspiration and spontaneous creativity that comes with the excitement and fun of seeing ideas become living objects in your hands. You’ve got to allow your document to tolerate change – by you or by (hopefully intelligent) others.

I first learned this lesson as a music composition major at the University of British Columbia. With much toil, I had written a neo-renaissance brass quintet of which I was quite proud. My professor liked it, too. When we brought it to the college’s star brass quintet for rehearsal, however, I passed through several stages of horror, disbelief, indignation, and clinical depression within ten seconds. The quintet began to play, then stopped on signal from the tuba player. The fellow took out his pencil and began to change a few notes, and then everyone continued. It happened more than once.

My professor, noting my sudden faint state of health, turned to me and commented, “Don’t worry, they did that to Mozart as well. And they’re usually right.”

The fact is, no matter how good something looks on paper, the greatest expert still modifies things when it enters the concrete world of objective perception. Nevertheless, you don’t want to witness the ruthless rape of your design and dreams. Rather, you’re hoping for a kind of organic growth – ideas growing naturally out of the seeds you’ve planted without needing foreign limbs and bodies grafted onto them.

Here are some tips for creating a document that can tolerate change without corrupting the original idea or sabotaging the development process:

Make certain to engrave in stone those aspects that are so essential to the game concept that they must not be changed.

Make certain everybody understands the feel that the game is supposed to have and the purpose of each of its details.

If information is repeated, it must be cross-referenced. Otherwise, if there are changes, you can end up with contradictory instructions.

And here are some tips for the actual implementation stage:

When a change is suggested, check back in your design document and see if it is in concordance with the “soul” of your game.

Check whether this is just an isolated change, or it’s of major global ecological impact (see “The Ecology of Improvement”). If it’s the latter, save it for your next project.

Update the design document and include the reasons for the change. Or if you didn’t make the change, say so and explain why it was rejected.

Changes, deletions, and rejected ideas should be retained in a master document to avoid discussing the same thing twice.

Everyone must be working from the same version. Past versions should be destroyed.

Crucial, Vital, and Urgent: The design document must be maintained under one person’s supervision only.

9. NOBODY SHOULD BE ABLE TO SAY, “I DID IT THAT WAY BECAUSE I COULDN’T FIND ANY REFERENCE TO IT IN THE DOCUMENT.” I’ve seen documents that didn’t even have the pages numbered. And then they complain that people didn’t follow instructions. Every good word processor will auto-number pages and print the date and title in the header or footer of every page. Some will even allow you to change the header at new chapters. Use bold text to direct attention to important material. Repeat yourself in different parts of the document as much as you like, as long as you cross-reference so you can update everything together as well. Make a thorough Table of Contents.

You may wish to write your document using HTML and provide hot links. Some progressive word processors provide hot link capabilities without HTML. But remember that more often than not, people prefer to work from a hard copy. (That way there’s something to read while rebooting after the hourly system crash.)

10. DELIVER IT IN GOOD CONDITION. After all this, you need to do whatever you can to facilitate everyone actually reading and using the thing. A pile of papers doesn’t get read – it doesn’t look important enough. Only things with hard covers look important.

Create a list of everyone who is supposed to have a copy. Keep the list. Print out the whole thing with the date in the header of each page. Have holes made and put it in binders. Label the spine and cover of each binder. When there are updates, provide everyone with the revised pages. At some points, you may need to provide new books and throw out the old ones.

In Sum Check…

Movie makers use move scripts. Architects use blueprints. Musicians use a score. According to ancient hearsay evidence, even the Cosmic Creator created a design document – which He later let a few prophets take a peek at – before the primal “Let there be light!” So game developers, following their Supernal Role Model, can certainly do the same. Do it right and it’s smooth sailing the rest of the way.

Tzvi Freeman teaches Game Design and Documentation at Digipen School of Computer Gaming in Vancouver, British Columbia, Canada. He has designed several commercial games and has acted as a consultant on many others. He can be reached at TzviF@aol.com. （source:gamasutra）