掌握游戏(译)

版权所有：carvenson 原作　　

作者Drew Sikora在美国一大型游戏公司任职，从事顾问工作2年之久，先后为数百名制作人员答疑解惑，具体情况不详。
这篇文章主要阐述如何将一个创意转化到实际的开发工作。全文共四章，今天贴第一章，后续大概一两天贴一章。中英对照稿请写信来索取。

/////////////////////////////////////////////////////////////////////
掌握游戏
Drew Sikora著 Carvenson译
/////////////////////////////////////////////////////////////////////
第一章 创意
介绍
现在有很多人都把游戏创意简单的看做他们所认为的那样：想法而已。（注意原文中创意与想法都是用的Idea,这里为方便大家理解，特别用不同的词语区分，啊，这就是汉语的魅力所在）我的意思是说，创意就真的只是想法吗？那就没必要了。这篇文章将分成四个章节，它将告诉你怎样来产生并且捕获一个创意，然后多方面的考察它，仔细考虑它并且让它成长而不是迅速的让它死掉。
最初，这篇文章只是想指导你如何写一个好的游戏设计文档。而在写作过程中，我意识到我正在说的只是整个游戏设计过程的中间部分，而我又不想离题万里然后草草结尾，所以我选择了改写成现在的样子。
那么现在，我们开始讨论你的创意，以及怎样在你的脑海中把它浇铸成你的游戏的最好的影象。
灵感
你是否读过R.Dahl的《Big Friendly Giant》，它讲述了这样一个故事：有一个名叫Big Friendly Giant的精灵，它用一张网到处捕捉梦境，然后把它们储存在瓶子里。它能够把梦境进行混合和搭配，创造出各种你能想到的梦境。然后他将在深夜里出发，透过卧室的窗户，用一个长长的吹风管，把梦境带给熟睡中的孩子。有些梦是快乐的梦境，而有些则是可怕的噩梦。
游戏创意其实和上面关于梦的描述没有太多差别，就象书中的梦一样，游戏创意在你的周围漂浮，也象梦一样，有些成为非常精彩的景象，而有些变成了噩梦（仔细读，那你将避免噩梦）要抓住它们，只要用你的想象力之网延伸出去，然后抓住它。在哪里抓？创意几乎可以存在于所有的事物上，象杂志、电影、电视、书、你生活中所发生的事、你想做的某件事情等等。
产生创意的最佳途径并不是一直考虑它。保持一个清醒的头脑去散步，看看东西，想想事情，千万不要想：“恩，这样这样的话可以做一个好游戏吗？”这样会只利用了你的分析能力，而不是你的想象力。在你还没有真真的梦到它之前就对一个创意进行分析将导致很高的创意死亡率。（这绝不是什么好事）相反的，当你发现了什么你觉得可以做一个好游戏的时候，你的脑袋将会叫出来：“哎呀，这个可以做一个很酷的游戏！”如果这个动作是无意识的发生的话，那就是一个好现象。马上伸出你的网并且把这个想法捕获下来，并且放好，现在你已经把它以素材形式存放起来了，你应该继续去尝试寻找新的想法，如果找不到，那么进行下一步。
熟虑
那么现在呢？你有了创意对吧？让我们一头冲回家然后开始写下来对吧？错！你如果这样做，你马上就会把自己带入到分析步骤，也就是说，你就无法再对这个创意是否可行是否可以容忍做考虑了。在获得了最初的创意之后，你将必须把它在你的脑袋中细化，考虑所有的可能性，产生大量的特征，即便它们看起来是不可能的，如果你需要，可以在纸上做一个列表。但是当把一个创意简略的记录下来以后，马上走开，再不要想它。这将让你可以分开你的想法，并且产生更多变的结果。
这个熟虑的阶段将花费好几天，甚至几个星期，如果你不是在逃命的话！经过这个之后，你要花点时间来把这个游戏在你的脑袋中形象化。再次提醒，不要在纸上写或者画或者是拟订任何东西。如果你这样做，你会很快固化你脑中的想法而导致将来改变起来异常困难。（这里并不是说你用你的分析能力，那个你之前应该已经听够了）
在上一段中，几天或几星期（这并没有时间限制）后如果你有了一个基本的印象，你将在几天内把它细化到看起来在你的脑袋中比较成型，不然就要花更长的时间。并且，凭感觉决定一个创意已经成长到足够可以写下来是很困难的。我喜欢考虑它直至在我的头脑中可以毫不费力的形象化出来的。我不是说一两个画面，而是指整个游戏：图看起来是怎样，菜单的操作怎样，角色怎样，表现手段，关卡，声音，音乐等等。很明确的，它看起来有很多的东西要考虑，但这就是为什么要花几个星期的时间。
那么现在我们有了整套的创意，是时候把它半官方化了。
简略的记录
时间到了。注意，你还不能写设计文档，那是第三章的事情。相反的，你应该做一个特征列表，有一些梗概。然后呢？你应该去想更多的东西。
特征列表是一个非常漂亮的易懂的东西，现在你已经把你的创意在你的头脑中固化下来，你可以很安全的把它们写到纸上。再次说明，我之前不准你这样做是你可能要在你的意识中更改一些东西，重要的是如果你想象了什么，比如说一条脊背上长满了尖刺的龙，然后画了下来，那么长了尖刺的龙就已经固化在你的意识中了，当你想把它变成没有尖刺而有一个钝脑袋的时候，你就会发现那真的很难想象。或者不难，但就是不对。这种感觉将导致你一直粘在旧的创意上而下不来，这个不是非常严重的问题，我承认，但是还是会发生。
不管怎样，是时候把你的记忆清除并且把它全部倒在纸上了，一个特征列表可以长到你能够做到的为止。包括所有你曾经有过的关于这个游戏的想法，一个接一个，它们不一定要有联系，或者可以用某种局部顺序。反正就是写下来。在次说明，你要有很情形的头脑，而且不要再对它们多加考虑。如果你计划做这件事情，我保证会有更多的想法冒出来。马上中断掉，以后再考虑，如果你觉得怕把这些新想法忘记掉的话，可以写个简单描述）
你完成了特征列表之后，把它放到一边，然后花更多的时间来考虑一些新的创意，以后再加上去。当完成这个以后，下一步就是时间测试了。（令人恐惧）
时间测试（原文为Test of Time不晓得这里译对了没有）
现在是时间来看看你的创意是否有足够的品质进行下一轮工作了。什么是时间测试？很简单，别担心，但是你需要一点自控能力和时间，做好准备。过程是这样的：
拿好所有的图、素描、笔记、图表，以及你的特征列表，然后把它们藏好到一个你几个星期内不会去碰的阴暗干燥的角落里。
把你所有有关你的游戏的想法全部清除，否认它，干掉它，让它从你的记忆中逐渐淡出。
好了，到底为什么你要这么做呢？理由是当你在创建这个精彩的新的游戏创意的时候，我让你对它如此关注，考虑到它将是下一个最好的东西。你将意识到它将是多么令人讨厌。什么？你可能会说，我花费了所有的时间在这个令人讨厌的游戏的创意上？没关系，我不是说它将令人讨厌，我只是说它可能会。
作为一个创意的最终测试，你正确的处理是非常重要的。最困难的事情不是考虑一个游戏而是把它搁置4-6星期。最好是，如果你是一个全职的游戏设计师，可以把时间花在考虑一个新的游戏创意上。考虑一个新的游戏创意4-6星期并不一定足够，它是帮组你忘记掉老的那个创意。然后，当你的新创意已经可以进入时间测试的时候，你可以把老的那个拿出来，打扫干净，然后再把那个新的丢进无人的角落。一个漂亮的循环。
现在，把那个老的创意从架子上拿下来，如果你对它一点印象都没有的话，那就好了。事实上，那简直是太好了！别担心你会忘记掉那些素材，如果你之前的工作有做对的话，你已经把你所有的想法都写下来了。现在用一个新的眼光一页页的翻过去看。如果记忆开始涌出的话，把它们压回去，把所有的事情都当做是全新的。不要让你过去对这个游戏的感觉挡住你做新的判断的路。
那么最后裁决是什么呢？那就是你的工作了。如果你逐页看过去的时候，说：“这真的是我想的吗？”那就到碎纸机前面去吧。祝贺你，你终于成功的把自己过去认为那么伟大的游戏创意干掉了。这是一件很困难的事情。，但是这样做你将会知道你能够抛弃糟糕的游戏创意并且是有根有据的处理它（而且还没有浪费钱去开发它）如果你翻完了一后说：“对对，非常好。”那么很明确的，你可以继续了。
结论
祝贺你，你已经创建出了一个游戏创意的雏形，它是不是很可爱？我是说，看起来不错。那么下一步是什么？开始把你的游戏创意肢解成一片片的。（当然是象征性的）在本文的下一个章节，设计，我将带领你经历整个试图干掉你的创意的过程。我们将从每个角度来考察它，蹂躏它，敲打它，吹毛求疵等等。经过这些尝试之后，它将象一颗宝石一样璀璨。到那时？
问题？批注？写信吧。
Gaiiden@hotmail.com


掌握游戏( You Got Game )第三章 文档

　版权所有：carvenson 原作　　　提交时间：2001-07-21 16:22:59


昨天和原作者就转载问题讨论了一下，他说只要不要大删大改，可以自由转载，所以我的译稿也不限制转载，。（说笑说笑，给点面子，大家缺垃圾塞的话就尽量转吧）
此外原作者说不太想收到中文信（因为他看不懂！）


第三章 文档
回顾
在上一章节，我们就怎样在Bug长出大牙开始咬人之前就排除它进行了广阔范围的讨论。我们充满希望的把它们拔除掉了。而实际上，我们的工作还远未结束,我们只是尝试了一下而已。但这些时间没有浪费掉，因为战胜BUG就象战胜癌症--你必须在早期进行处理。幸运的是，许多显而易见的和重要的Bug已经被覆盖到并且很有可能已被连根拔除掉了。当然，到了开发阶段，新的东西往往从你最讨厌的地方冒出来，但是我们先把这些令人沮丧的想法保留到第四章好吗？
在这个章节，我们将讨论设计说明书和 Pitch 。要让事情向前推动，这两项都是不可或缺的。设计说明书是一个很长的，详细的技术性文档，你用它在整个游戏开发过程中指导你。而 Pitch（我喜欢这么叫）则是设计说明书的一个很短的版本，（非常短，只是给那些可怜的接收方的管理人士看的）用来交给发行商和其它机构的开发者。因为我没有办法给你一个范例，我们将创建一个简单的模板并且设置引导路线以开始工作。
好吗？
为什么需要设计说明书？
这是一个好问题，很早很早以前，大概三个人就可以做一个游戏：美术，策划，程序。通常虽然是三个人，但是经常被卷成一个人。
由于游戏是蛮简单的而且没有什么深度，而且策划基本上不用担心别人除了他自己。在设计上浪费时间，也就只是浪费时间而已。
而现在不同了，一人开发团队已经相当程度的成长了。现在基本上都有好几打人在一起工作。这就意味着策划如果想让游戏长成他想要的样子的话，就必须找出一个方法来与团队中的其他人沟通。设计说明书将会是一个受欢迎的办法。除非你这个策划在耳朵里放一只7x24的值班电话以便回答所有的问题，或者是每天开会来解释下一步要做什么，怎么做，那你就可以不要设计说明书。没有第二条路。没有一本好的设计说明书，团队成员将不会明白要做什么，然后他们就会浪费开发时间来做一件事情：
四处围猎你，然后抓住你问：你想把这个特征如何实现？你想这个东西看上去怎样？你想让这个特征摆在哪里？为什么我们要抛弃这个想法呢？告诉我，这烦不烦？当然烦！
更糟糕的是，程序，美术，其他什么乱七八糟的，都可能会说“随它去了”，然后就在缝隙里填上他们所想象的东西，而你，却有不同的想法。当要验收这个游戏的时候，你会发现那些特征冲突得一塌糊涂。时间就浪费在检查和清除混乱上了。
所以记住两件事情：第一，你要写一份设计说明书，第二是你要写一份好的设计说明书。首先我们就制作说明书讨论，接下来我们就如何做好的说明书进行讨论。加油！
Pitch
这是你的设计阶段中的第一个产品。头号任务是做一个漂亮而华丽的说明来向你预期的客户展示。因为你是一个策划，而这些客户可能是一个开发发行者或者干脆就是个发行者，不管怎样，他们都期望有一个很好的演示来确认你想做的游戏会是最棒的东西。你的工作就是给他们这个东西。
Pitch是一个设计说明书的很简短很简短的版本。其中心是把能够让这个游戏在预期市场中显得非同寻常的特征集中聚焦起来，如果你在担心我说的预期市场的话，你还没有仔细的读懂我的话。回到第二章再看看。如果你了解了，那么你会明白一个发行商将不会对产品发布时已经过时的东西产生兴趣。Pitch不要涉及技术细节，但要扫过其表面，记住你在对付的是谁--是那些不用劳动的经理和董事们！如果你开始提供给他们对他们而言完全无用或者不关心甚至不懂的信息的话，你的说明的价值将很快从他们眼中消失。
Pitch 是你开始使用有趣的色彩丰富的图表与图片的地方，有必要的话，你可以用PowerPoint来做。你必须在非常短的时间里，传达你的信息，因为有很多人不喜欢坐在那里开会一直听到他们厌倦得从椅子上摔下来。你可以在开始的时候用一个会吸引他们注意力的小窗口，如果你不设法用这个窗口来吸引他们的兴趣，在说明继续的过程中，事情会越来越难办。这没什么，但普遍的事实是很多人尽力尝试，也没能获得一个长时间的关注。
填充页面
发行商已经同意资助你的项目。那么现在是时候开始。。。（先庆祝一下）写设计说明书！当然，可能这个东西早就完成了，那么你可以马上跳到第四章，但是我们在这里的假设是还没有，我们必须开始写它了。要快。所以我们马上开始基础工作。
你并不需要什么特殊的东西来写一份设计说明书，一个简单的字处理程序就可以了。现在，第一步是把你曾经写，画下来等等的所有信息收集起来。你周围的那一堆乱七八糟的纸将会魔术般的变成整整齐齐的一叠，我们管那一叠叫设计说明书。我们现在可以真的开始了。请注意这里讨论的主题是我的个人看法。这是我自己创建设计说明书的方法，如果你不喜欢按我的例子来的话，希望这些也可以给你一点点参考意见。
最首要最首要的事情 标题页
一点都不复杂，所有你所需要的只是一些在标题页上的东西来作为开始而已。
游戏名称
公司名称
首席设计师：你的名字
时间
版权信息或者是其它一些标明公司所有权的信息
版本号
不要让这个页面上的信息散乱。区分先后次序。游戏的名字当然要用好看的大黑体放在中间，安排好空间使它看起来比较专业。
内容表
开个会进行头脑风暴，开始的时候先过一遍你的全部想法，特征，以及其他，然后开始判别每个想法分别是属于哪个范围的，做一个很广阔的节点划分，象玩法，控制，图形，网络等等，把它们分别整理到这些目录中去。然后再分别划分更多更多的个别的特征和想法，比如在控制目录下面将会有游戏柄，键盘等，一直继续下去直到你把所有的东西都分类好。
接下来你需要一个方法来在翻阅说明书的时候把所有相关的部分标识起来。最普遍的方法（也是我采用的方法）是用一个数字系统以周期的方式标记每个描述。这里是一个范例
1，主要主题
与主要主题相关的子主题
另外一个与主要主题相关的子主题
上一子主题的一个子主题
2，一个全新的主题
掌握了要点吗？我相信你们中的很多人之前有用过这样的的东西，而且因为我的结实是如此苍白，所以我提供一个范例出来，这是从一个叫做Traction Control的游戏中抽出来的
2. 玩法....................................................8
2.1 赛制/路径...............................................8
2.2 点和计分................................................9
2.3 汽车....................................................9
2.4 驾驶员.................................................11
2.4.1 技能和特性.......................................11
2.4.2 自治精神.........................................12
2.5 武器和特殊物件.........................................12
2.6 物理..................................................13
2.7 游戏模式...............................................14
2.7.1 漫游............................................14
2.7.1.1 目标/队伍..................................14
2.7.1.2 钱/得分....................................15
2.7.1.3 升级/伤害..................................15
2.7.2 集会............................................16
2.7.2.1 点........................................17
2.7.2.2 地点.......................................17
2.7.2.3 破坏.......................................17
2.7.2.4 时间......................................17
2.7.3 多人游戏.........................................18
2.7.4 难点设定.........................................18

这里我用了monospaced的字体来让数字可以在右边对齐，因为我不会用WORD的TOCs功能。注意我分辨每个子节点和新主题的方法。主要主题用黑体而每个子主题在普通和斜体字间切换，在目前的实体中，我用各种列表类型来帮助指出特定的子节点。
2. 玩法
2.7 游戏模式
2.7.1 漫游
2.7.1.1 目标/队伍
当然你可以自由的采用各种方法，这只是我的方法而已。
填空
现在是比较困难的部分，而这个部分你又必须完成。我之前说过，你的设计说明书要很棒。而在这一部分，棒就意味详细。一个详细的设计说明书是我们要采取的唯一途径。如果你写的不够详细，在我前面提到的若干种惨状中，你将会遭遇到不只一种。那都会造成开发时间延长。我实在没有办法就怎样才能够最详细的写出设计说明书来对你做什么建议。最重要的 事情是你在写的每一个独立的章节（象你在目录中所列出的那样）都应该具备开放性。然后依次的回顾检查，确认你所写的东西和你之前所设定的东西都吻合。否则那将会混乱你的团队，并且让他们排队站在你的家门口问你问题。
确认你所想到的所有的事情都会传达到你的团队成员脑中。这是在对编码，美术等工作的控制之上的一个加权。如果你把足够的信息都详细列表出来的话，程序员，美术等就至少可以比较有保障的了解到什么你想要的，那么你就走在一个正确的道路上了。
设计师笔记
是不是又有人要踢我了？举个例子：你设定一种用银子而不用金子来建造的特殊单位。这个单位要花金子到铁匠铺去打造他的兵器。于是你把这个单位作为不需要金子就可以建造的单位和其它同级别单位一起在列表中列出来。之后，当你再检查这个单位的开发状况时，有个程序员问你：为什么这个单位不要消耗金子而其它同级别却要呢，这是不是逻辑错误？你可能已经不记得为什么这个单位不耗金子。于是你便同意修改为也要耗金子，几个月后，在测试的时候，发现这个单位根本没人用！你问测试员为什么不用那个单位？他们回答你说那个单位太贵了。于是你开始犯糊涂，为什么它会那么贵呢？然后你一拍脑袋，噢，原来这个单位还要到铁匠铺打兵器！所以这种单位的价格就翻倍了。
这种情况要怎样防止其发生呢？好记性显然很有用，但是我们通常都不是很擅长这一点。这时设计师笔记就登上了舞台。设计说明书必须详细列表，但却没有必要告诉程序员为什么这样设计，而对其它人员也是一样没必要。他们不需要对为什么游戏策划要把这些东西写进来提出疑问，而应该就怎样最好的实现它提出疑问。这就是设计说明书的目的所在。它告诉开发团队怎样来实现单元和特征。而设计师笔记，则是设计说明书的一个补遗。你的设计师笔记不需要很整齐，也不用去整理，可以直接由你的想法记录，草图以及其它一切可以解释为什么这个东西是这样的东西组成。把这些东西都好好的放在一起，如果你遇到团队中的别人提出为什么要或者是为什么不的问题，你就可以翻一翻笔记以后作答。
结论
好的，现在除了重复介绍我或者其它人的工作以外我没有别的东西可以介绍给你了。我尝试给你一个关于你需要什么东西的基本概念，但我没有办法很详细的讲。因为我也是这么学的。后面是一个链接表，我建议你再去更深入的看看那里的关于设计说明书的主题文章。在第四章我们将讨论开发的方式以及在这个过程中如何使用设计说明书。
问题？批注？写信吧。
Gaiiden@hotmail.com

Creating a Great Design Document, Tvzi Freeman

Design Document Tips, Usenet compilation

Tom Sloper's Format for Game Design Specs, Tom Sloper


掌握游戏( You Got Game )第四章 开发（上）

carvenson 原作　　

第四章 开发
回顾
在上一章节，我们讨论了怎样写一份设计文档，然后我们可以把它作为一个开发工具来使用。我举出了很多理由来说明为什么要有设计文档并给了你一些关于怎样做这个文档以让它能圆满完成任务的建议。上一篇文章所讨论的在这篇中有用的不多，除了一个观念：“我们将主要在排除那些在第二章经过讨论而收集来的将会阻碍我们的开发工作的因素”
现在我们开始，你得记得我在设计那一章节中告诉你的事情。当你在开发东西的时候，非常多已经讨论过的问题将会再次冒出来。所以你要保持你的才智，你才能在他们变成Bug之前排除它们。在这篇文章里，我将只讨论与开发有关的东西，但是有些会牵涉到第二章讨论的东西。
现在，由于整个的过一遍开发过程会让这篇文章过于冗长，本文只讨论这个过程的一些特定部分。而你读完整篇以后，应该不会太困难就可以把剩下的部分填出来然后历尽千辛万苦做出一个优秀的游戏来。
说得够多的了，让我们开始吧。
团队
在开始之前，我建议你停下来花一些时间考虑你组织起来的这个要完成任务的团队。肯定的，我们可能会有Bug,有特征蔓延，有糖衣炮弹，有糟糕的管理，但是没有任何东西会比一个糟糕的团队成员更能带来痛苦了。最糟糕的事情是他们中的有些人不到后期不会变成烂苹果。更有甚者，有些人会从头至尾的破坏项目，而管理层或者是你根本没有意识到这点。
你要怎样阻止这一切发生呢？从专业上讲这并非你的工作。但是，你希望看到你的创意边成现实。所以当保姆是你在空余时间里可做的一件事情，这样，团队成员的问题就不会出现了。通常我们的团队由互相熟悉的老朋友构成。而另外一些团队则可能完全由不熟悉的人构成。
简单的说，你必须一直提防羊群中的狼。即便你是在和一个非常有经验的的团队一起工作，著名的“破碎时期”可能会发生并且带来破坏性的后果。当然，你也许有一个非常棒的设计文档来防止项目拖延时间。
团队的角色及其分配
现在我们知道要一直保持目光敏锐，接下来我们可以把团队组成一个工作的模式。现在的团队都很大，而且由不同类型的人们组成，而以前就是1-3个人来分担策划，程序和美术的角色。而现代游戏产业正在缓慢但明确的走向类似于好莱坞的产品时期的状态。这不是坏事，这是正在发生的事实。
我组合了一张关于角色与分工的列表提供给你。这是我关于团队组织结构的看法，如果你不同意，没关系，你可以把这个作为一个你组织你认为的可以为你的项目工作得最好的团队的一个基本参考。我知道这并非一个详细完整的列表，但是这个东西应该还是有给你很多信息。这张表涉及了分工以及工作的头衔等。在每个头衔下是他应对谁负责，他应该和谁讨论他的工作。让你的团队漂亮的构造起来，以让信息传递管道畅通无阻是再好不过了。如果你做到了，每个人必须知道的事情都会被知道，并且不会把东西忘记掉。
管理分支
软件经理
对何人负责：项目经理
与何人讨论：游戏策划师，首席构造师
软件经理的一项工作是完整彻底的阅读设计说明书（所有的首席人员和管理者均需要）并且和游戏策划师和首席构造师一起讨论之。软件经理的职责是了解设计说明书，并把它转化为一组的技术需求。这些需求将引导游戏引擎、图形引擎、脚本引擎等的规划。软件经理必须把这些多变的技术方面管理起来，并且预测完成每个技术需求所需要花费的时间。
首席构造师
对何人负责：项目经理，游戏策划师
与何人讨论：首席程序设计师，软件经理，品保经理
首席构造师的工作是构造整个游戏的基本模型，他要和首席程序设计师一起工作。首席程序设计师将把构造出来的模型划分为功能块，并且分配给不同的程序员。首席构造师还要检查首席程序设计师发过来的全部代码，以确认它们正确的实现了技术要求。首席构造师与品保经理讨论怎样来游戏中是否有障碍，然后把结果反馈给首席程序设计师。
项目经理
管辖：首席程序设计师，首席美术设计师，首席音乐师
与何人讨论：软件经理，首席构造师
他就是第一老板。为了防止项目经理看起来比其他管理者要有权力得多，他不能直接管任何一个程序员，美术或者是音乐。相对的，他应该通过他们的头来给部门下指令，并且部门的领导者在根据他的经验认为某个指令会对开发无益甚至有害的情况下，有权力推翻这个指令（看他是否愿意）。而项目经理也可以依据软件经理和首席构造师的评估和技术规划来调整项目日程表。
游戏策划师
对何人负责：
与何人讨论：
游戏策划师是该项目的设计文档的作者，他是唯一有权利调整设计文档的结构的人。游戏策划师有规律的与其它各分支的领导者进行讨论，确认工作的产出和文档中的设定相符合，并通过这个，检查开发过程中的所有方面。
程序分支
首席程序设计师
对何人负责：项目经理，游戏策划师，首席构造师
与何人讨论：项目经理，软件经理
首席程序设计师是程序开发团队中最富有技术能力的人。他知道得最多，有最多的经验。一个很大规模的项目中，首席程序设计师需要做更多的管理工作而非开发工作。首席程序设计师的工作是定期与项目经理讨论来确认他的程序员的工作是按日程进行的。他要和软件经理讨论所有可能突然出现的问题以及他们是否必须重做或者抛弃某个东西。
在很小规模的项目中，只有几个程序员在他的管理之下，首席程序设计师可以花差不多的时间在开发和管理上。
程序员
对何人负责：首席程序设计师
与何人讨论：首席程序设计师，其他程序员
程序员基本上生活在他自己的世界中，他的项目范围并不比首席程序设计师走得更远。程序员的职责是听从上面的命令，这包括了遵循技术设定，规范等等。一个在大规模的项目中通常被分配在一个特定的领域中工作，而在小规模的项目中，程序员可能要覆盖好几个领域的工作。
当一个程序员的任务和另一程序员间发生关联的时候，必须立刻与其进行对话（比方说一个图形按纽点下去会出声音）这要求他们把代码写得很干净并且在所有的地方都有注释。程序员可能要了解所有的事情（包括阅读设计文档）或者只了解必须了解的事情，这取决于首席程序设计师的工作方式。
美术分支
首席美术设计师
对何人负责：项目经理
与何人讨论：游戏策划师，首席程序师
和其他的团队角色不同，首席美术设计师可以同时做另外一个项目。特别是美术人员缺乏的时候尤其是这样。由于美术上的品质等级和是否详细判断起来要比代码来得容易得多，所以首席美术设计师可以同时管理好几个项目。同时，由于美术工作层次划分的容易性，首席美术设计师可以花更多的时间来画图。他要与首席程序设计师讨论所有美术人员画的图是遵循他从首席构造师那里拿到的技术规范。他要与游戏策划师讨论来确认他们的画面和策划想象的东西相同。
美术人员
对何人负责：首席美术设计师
与何人讨论：首席美术设计师，其他美术人员
和程序员一样，美术人员和整个项目开发是分开的，他们只根据首席美术设计师的安排来工作。也和程序员一样，在他们的工作发生关联的时候，美术人员必须和其他美术人员讨论他们的美术设计（比如某人画的房子和另一人画的别的东西是否协调）。象首席美术师一样，他们也可以同时做几个项目。
音乐分支
首席音乐设计师
对何人负责：项目经理
与何人讨论：游戏策划师，首席程序设计师，首席美术设计师
首席音乐设计师是团队中最有音乐天赋的人。他创作乐谱并把它分发给音乐师变成音乐。首席音乐设计师还要确定在游戏过程中需要哪些音效，并把它们分发给他的音效师。首席音乐设计师并不直接把自己的乐谱变成音乐。相反的，他要一边注意他的音乐师和音效师在做什么，一边创作新的曲子。他要和游戏策划师讨论来确定乐曲的长度和情绪，和首席程序设计师讨论确定音乐的技术规范（包括格式，采样率等等），他还要偶尔和首席美术设计师讨论他是否有一些可看的东西（比如图片什么的)以获得对乐曲的情绪，行为和设置的感觉。
首席音乐设计师可能要被要求创作有交互式性音乐，能随着地点，设置，情绪的改变而改变。这就要求程序部门和音乐部门要有良好的互动。
音乐师
对何人负责：首席音乐师
与何人讨论：首席音乐师，其他音乐师
象其他等级较低的人员一样，音乐师只有必要和首席音乐设计师交谈。音乐师的工作是把首席音乐设计师的写的乐谱合成以后变成乐曲。如果需要用到乐队什么的，音乐师可能要自己想办法。
音效师
对何人负责：首席音乐设计师
与何人讨论：首席音乐设计师
音效师有一份很有趣的工作，他要决定怎样做出在游戏过程中会被听到的音效。这包括枪声，爆炸声，背景噪音，环境噪音，脚步声等等。很多音效是早就做好并存在可以买到的音效库里。由于音效工作花不了多少心思，所以他可以同时在别的项目中工作。
支持和品质保障分支
品保经理
对何人负责：项目经理，游戏策划师
与何人讨论：项目经理
品保经理是负责管理和安排测试的人员。他编写测试计划并分发给测试员执行以试图找出Bug。然后向项目经理报告实验的结果。项目经理就可以向相应的项目成员发出警报。
测试员
对何人负责：品保经理
与何人讨论：品保经理，其他测试员
只在品保经理的领导下工作，他们是把游戏一遍一遍再一遍的玩过去，直到他们的眼睛都睁不开为止的人。测试员反复从品保经理手中拿到测试表格然后开始测试，在表格上填写测试报告。测试员通常不相互讨论，除非他们发现了一个影响到了好几个区域的测试的BUG。测试员还有责任在一开始的时候帮助程序员测试代码以确认它们是稳定的。
支持人员
对何人负责：项目经理
支持人员可以有很多名字，随着工业的发展，这些人员可能被请来做动作捕捉之类的工作。支持人员也可以是负责管理和维护公司的网络和数据库的人员。


掌握游戏第四章——开发（下）

carvenson 原作　

项目进度
如果可以的话，请允许我讲一个真实的Dilbert的笑话。Dilbert坐在他的老板面前，老板说：“你能解释一下为什么你的项目会延迟吗？”Dilbert说：“可以，日程表是在对未来无法了解的情况下做出的人工品。代替对未来的了解的是疯狂的想象。项目日期底线是根据商业演示而非根据事实。管理层削减了预算以至失败。我猜你喊我到这里来是想为你在这些事情中所做的道歉。”他的老板死盯着他，而他继续说：“你想知道预算是怎样产生的吗？”
我听到这故事的时候笑了出来。基本上Dilbert夸大了管理层对预算和进度的控制力。我想会有一些例子证明他并没有完全夸大，但是我们不要管那个。基本上，当一个项目的进度被确定的时候，它应该是现实的。程序员整夜整夜的加班来按时完成项目这一普遍印象是确实的，但却并非必要。应该在适当的地方塞一些空档以允许一些小的挫折。如果你的项目有一个平滑的结构并且你的设计和技术设定都按时完成且非常详尽，大的挫折应该不会发生。
Dilbert还指出了进度是怎样在缺乏对未来的了解的情况下制定的。这一点我们没有明确的方法。只有一个部分的进度绝不会让你的投资者开心，而做一个动态的进度表则可以让你在一个循环里转圈。你最好是了解会有挫折，并且会有改变，你必须对付这些。而做这些事情的最好时机，就是在一开始的时候。做一个既宽大有能取悦于投资者的进度表是一件艰苦的工作。但是绝对值回代价。
使用里程碑和检查点
如果没有一个好的日程表的话，你将不得不经常停下来检查状况。不要这样，放轻松点。里程碑和检查点可以让你保持在正轨上，但是却要小心使用。太多的里程碑会让你觉得你没有办法面面俱到，而太少的里程碑则可能让你遗漏了重要的事情而且还要等一两个月以后才有可能意识到那一点。对于检查点来说也是一样。如果每两天就设置一个检查点的话，程序员和美术师会觉得负担太重。而如果每两周一个检查点的话，大家可能早就完成了工作并开始整天在工作时间开玩笑。检查点和里程碑应该设置成可以令工作的完成状况有高效而有规范。而且你还可以在有时间的时候玩玩网络游戏。
里程碑
里程碑是比较大的检查点，你可以一个月或者两个月安排一个，里程碑的设定要做得很漂亮，就象一整套的程序一样。在每个里程碑上，你应该做以下三件事情。
回顾最近完成的项目，包括编码和美术设计等等，以寻找任何瑕疵。
把完成的部分加入到游戏的结构中去，然后运行它，以测试和之前已完成的部分是否存在有冲突。
开个庆祝会，并想你的投资者报告你正在前进。
基于以上的三点要求，我们应该把里程碑设置在一个游戏的模块或者段落完成的时间上，你应该在现有的状况下让游戏程序可以在特定模式下运行。里程碑的主要意义在于它是一个你用来向投资者证明游戏确实是在开发中的一个时间点。没有一个投资者会满意于只听到你又开发了一个新的程序出来。他们要很清晰的看到进程在进行中。这就是里程碑之所以重要的原因。
检查点
检查点一般只是为开发团队保留。可能有些发行商是喜欢指手划脚的那一类，但多数人还是会对里程碑感到满意的。而检查点和里程碑的设置相比非常有理由的要更加密集。相对于里程碑，检查点只是让你对已做工作做一个快速回顾，以确认所有的事情都象之前规划的一样按正轨进行。检查点应该设置在开发过程中的关键点上。一旦一个检查点被通过了，返工该检查点之前的工作将会随着开发进程越来越困难。因此，每个检查点都需要认真的检查是否有Bug并且在项目继续前进之前排除之。如果发现了一个有问题的检查点，应当把资源配置到解决这一问题上来并重新开始开发过程。这就需要临时性的调动一些程序员和一些美术人员等等到这个任务上来。
如果正确的使用，里程碑和检查点可以帮你在游戏做出来的时候解决很多问题。和第二章相联系，你应该把Bug表和特征蔓延表放在手边，在检查检查点和里程碑的时候检查是否有任何东西蔓延了而导致在未来的报复性破坏。
你有一份设计说明书，使用它
很普遍的，很多人都不喜欢读那些正确的告诉他们应该怎样做的冗长烦琐的文档。人们就喜欢开始做，做，做完。我还知道很多人即便读资料的时候想睡觉也非常讨厌抱怨出来。这种想法使得你的项目和你的设计说明书变得非常危险。
为了防止说明书的支离破碎，我们把它用章节和主题进行连接。最好的方式是要把它放在公司的内部网上，并且支持搜索和排序功能。你甚至可以进一步的把章节按部门和权限设置进行分配，使得有些并非所有人都有必要了解的内容不可见。这样可以让人们可以读到他们想知道的，而不需要让他们的脑袋被无关的信息塞满。
如果一个团队成员对他不能看到所有的信息表示恼怒的话，应当提醒他在项目中的角色。对于一个人来说，无用的信息了解得越多，要高效率的专注于他自己的工作就越加困难。
实时开发第一部分--处理表现
在游戏开发过程中会经常出现问题并需要我们去正确解决，这只是其中的一个很小的方面。在第一部分，我们将讨论表现的力量。如果你不记得什么是表现以及它是怎样影响游戏的话，请回到第二章阅读“规则与表现”的部分。
那么问题在哪里呢？表现真的能构成对你的阻碍吗？是的，表现具备停止开发进程的潜在能力，但这种事情比较罕见。表现是怎样构成障碍的呢？当一个新的游戏特征冒出来的时候，它将带来一个是否要保留它的决定。
有时候你没得选择，如果你拿掉一些特征，你可能使其它特征失效。如果你改变了一个规则，你可能影响了其它的特征并且造出了一些新特征。很讨厌对吧？
另外一些时候，会有对游戏并非太重要的特征，你可能可以毫无影响的抛弃它。这就好。然而，抛弃一个特征并不象说起来这么简单。如果你的项目没有一个可扩展性的结构。去掉一个特征可能还要花钱。这有很多的例子。这就是为什么有些游戏会有“BUG”的原因。
最后，策划师和项目经理面临着选择，如果一个新的特征很适合并且是有用的，它就应该被保留。如果对玩法产生了妨碍，那么它就应该抛弃或者是隐藏，而不要去考虑其代价。如果一个特征无关紧要，而且又很容易干掉，那就干掉它。你要处理的表现的总数直接和游戏设计的好坏有关系。
实时开发第二部分-特征蔓延并不意味着死亡
这里又再次牵涉到第二章的问题。特征蔓延可能是在做一个游戏的过程中最令人恼怒的事情了。很多人都非常渴望增加新的特征进来。我以前也是这样，我曾经想象一个拥有巨大的世界，漂亮的图，声音控制，完美的在线，象人一样的AI，各种各样的东西都有。当然，每个人都这样想，我相信我们有一天可以做到，但并不是今天。
在游戏的开发过程中，你可能会好几次的突然想到一个主意来提升游戏的趣味。你会说：“哎呀，这个要比我以前想到的要好的多！”听起来好象不错？实际上并非如此。如果你开始考虑这个问题，你就会失去宏观的把握。你要记得游戏是一个整体，每一个事物都是互相影响的。如果你很自然的去改变某样东西而没有花时间研究其可能的影响。整个项目将被完全破坏。这就是特征蔓延的最大危险。它在创意阶段令人厌烦，在设计阶段让人愤怒，在文档阶段潜藏起来，在开发阶段图谋不轨。
这要求项目经理要在游戏策划师为一个新想法而过于激动时控制一下游戏策划师。这是因为项目经理是管钱的人而游戏策划师不是。一个游戏策划师在觉得创意会让游戏更好的时候，可能不会想到研究一个设计改变的代价。项目经理却要意识到停止开发来决定改变一个特征将要花钱。一旦团队决定不改变任何事情，他要尝试去用任何方法阻止策划师。
关于特征蔓延需要谨记的是很难从它的全部形式中检测出来。不要忘记，要把它当做并非你的项目中的部分剔除。这是一种很傻的行为，但是没关系。特征蔓延总是会找到机会到你的项目里来偷鸡摸狗。
实时开发第三部分--增加和删除特征
这是关于所有的增减问题的核心问题。基本上，我们决定增加或删除一个特征的代价是很高昂的。真的。随着开发过程的进行，改变任何一件事情的代价在不断增加。这一点必须事先考虑。有很强的数据资料显示开发末期的一个改变要花费50倍于开发初期。这看起来是常识。但是你别吃惊有多少人根本不了解这一点。
删除特征无论在时间和配置上都是一个艰苦的过程。特征可能有很多理由抛弃，包括时间限制，经费紧张，没有效果等等。当删除特征的时候，你应该判断它会对游戏造成的冲击。如果你拿掉了游戏的主要特征，那么就要有相应的一个东西替代它。如果不可能，那么项目就应该取消以防止把钱浪费在财政黑洞上。
增加特征也很令厌烦，因为你必须了解增加特征要花钱，而且还可能导致特征蔓延。特征应当被整个的分析过，以验证当它被加入项目的时候他们将会对玩法产生的作用。如果特征对玩法没有作用，那么就不应该加入。决定要从整个团队中来，所以在蔓延并无希望时，每一个人都应该能把蔓延合理化的有希望起来。
当然，如果时间金钱允许，增加特征通常是个好事，加强图形，使用多种界面，多些NPC，这些都可以作为第二想法加上去，，但绝不是在产品制作时期。
发行完成的产品
当所有的事情都说到做到以后，我们就来到了决战战场。整个开发过程中的你的测试小组应该已经对每个递交给他们的版本进行了测试。有些人可能想在开发的后期再请测试小组以节约经费，但这并不能带来财务上的好处。一旦你有了一个可玩的游戏版本，就要交给测试人员。程序员当然可以测试自己做的东西，但是那将把他们编码新的段落和模型的时间减少。一个测试团队不仅仅是验证游戏的品质，更要帮助好程序员。
在你决定要交付一个游戏给发行商的时候，你应该确认游戏能够平滑的运行，交付的产品应该是快速而肮脏的。如果发现了一个问题，应该尽可能快的修正。产品交付时间的长短取决于项目的延迟情况。
你有时候会有几天时间或者是几星期时间来结束你的项目或者是对项目进行抛光。理想的情况下，项目应该结束并且你应该把你的时间花在对各种想得到的系统进行测试上。你可以用来进行产品交付的时间是基于你的项目构造，项目管理，项目进度的。所以你看，我们进入了一个完整的循环，你在每一个开始的时候决定的事情，当然的影响着结尾的每一件事情。
对补丁的错误使用
最后一个项目，实际上最近很多游戏都在走偏门，硬着陆。游戏有BUG，令人厌烦，没可玩性。当然开发者好象并不紧张，他们可以发布一些补丁来修正这些问题。先不讲漫骂的力量，补丁永远不是完成游戏的一个渠道，永远不是！
补丁可以帮助开发者增加新的特征并改变已存在的特征。这并非BUG的修正，因为原本是没有问题的。对产品的抛光可以在开发过程之后继续，就好象在测试过程中也可以增加一些以前没有见过的东西。但是补丁不能被当做是BUG杀手。排除BUG的唯一地点是在你的开发过程中在你的办公室里。
Blizzard是全世界唯一一个公开宣称不出达不到他们自己期望的游戏的公司。你也许会认为那是因为他们的成功，而其它的公司会跟随他们的领导。其实，在一个垃圾游戏背后，更多的是发行商而非开发商。甚至，有时候还不是发行商的错。如果你保持一个信条：“说到要做到”的话，你就有了一个更好的起点来与发行商进行沟通，并让他们也了解得更好。如果你不给他们关于游戏开发的信息，发行商不允许你延迟时间是非常合乎逻辑的。在一开始就要了解，然后他们才可以预期即便你的项目超过时间也依然存在的机会。
结论
我忘了什么东西吗？我一时也想不起来更多的了。一天之内写这么多东西也真的是没有办法。我非常希望这些东西可以更好的帮助你设计和生产你的游戏以让人们喜欢。整个文章中所说的都是我个人的观点，你并非一定要遵循我所说的东西。这些是我相信在做一个很好玩，有趣味，能够长期存在的游戏的过程中必须的东西。我把一些不可能的条件象非常好的日程安排，非常好的架构当作是一个目标，而并非必要的条件。祝你幸运！
问题？批注？写信吧。
Gaiiden@hotmail.com

Further reading:

Game Architecture and Design

Code Complete