The Game Producer's Handbook（游戏制作人手册）-第1章 ...

行文

在你购买了这本书以后，你可能很急切想直接看看游戏制作人到底是做什么的，因为这对很多人（包括视频游戏行业内外）来说是一件很神秘的事。
那到底视频游戏制作人是做什么的呢？正如Dave Perry在2004年的GDC上做的演说那样，视频游戏制作人是

• 他的主要精力放在如何把视频游戏作为一个成品项目交付；
  
• 他清楚团队里每个人的名字；
  
• 他会和团队一起工作到很晚，只要需要的话，他能不分昼夜地随时提供必需的指引；
  
• 他能清晰地和每一个能正面或负面地影响到游戏的人交流，因为游戏制作人的职责是让每个人都投入到游戏制作的怀抱中；
  
• 他会防范那些能影响到游戏或者是牵制产品开发的人；
  
• 他对自己自信满满，相信自己能跨过任何的障碍，迎面任何的挑战；
  
• 他会竭尽所能地协助团队交付游戏。
  

制作人职业的简短历史

在传统的媒体和娱乐行业里，制作人会负责整合一场演出，把艺术家的才能带到工作室里，或者是组织一次公开的传播事件。制作人是一个包罗万丈的角色。换句话说，他会对一次事件、项目，或者节目承担其完成结果的主要责任。特别地，电影或者电视制作人还包括挑选演员、雇用导演、寻找剧本、处理合同、分发最终成品、资金运作、计划安排、场地管理、宣传推销、市场和公关。类似地，唱片制作人是唱片机兴起后诞生的职业，它包括寻找歌手、聘请录音工作室、从唱片发行商那里获取分发渠道和资金运转、推销和公关各种事件，还要为歌手、填词家和作曲家签订合同和法律协约。
到了21世纪，制作人的角色随着这种最具交互式的娱乐媒体的诞生而进一步演变了。如今视频游戏制作人的角色可能包含了电视、电影和唱片制作人的所有职责，并且还加入了更多其他的职责。事实上，交互式娱乐包含了很多因素和挑战是传统的电影、电视和唱片制作人都不需要面对的，例如游戏制作人要想方设法来为特定的产品类型加入新的渲染技术，或者寻找一套最理想的游戏开发工具；又或者要想办法让最核心最吸引人的玩法清晰地从设计团队传达到游戏开发部门中的各处；又或者要确保设计文档能勾勒出一种能让人高度成瘾且吸引人的娱乐体验。
视频游戏制作人的各种职责

假如你的目标是要做一名出色的视频游戏制作人，那你就要有经历各种挑战的心理准备。接下来这部分会谈到视频游戏制作人有可能会遇到的各种不同的挑战，这同时也是所有媒体的制作人都共有的职责。它们是以字母顺序来排的，不是按重要性来排。当读完这份清单以后，你应该对制作人面对的挑战以及他们日常的工作有了基本的了解了。正如你所看到的，制作人需要有很广的技能、经验和学识来应对他们日常面对的各种挑战。尽管不是每一个制作人的位置都是一样的，也不是每一个制作人都会面对所有的挑战，但很可能当你处在制作人的职业生涯时，你会发现这里提到的每一种情况、技能和特征都是很有价值的。
积极贡献
制作人会为完成游戏而向团队贡献他的精力和想法。这意味着制作人不单单每天坐在办公室里用Microsoft Project来编排计划，而且会积极参与各种团队会议、设计会议、问题解决过程以及设计创意，在需要时做出决策。制作人的贡献应该无缝地融入到团队里，为团队顺畅地运作提供润滑油的作用。
运用出色的决策制定技能
明显决策制定是游戏制作过程中至关重要的方面。毕竟没有谁会希望做出糟糕的决策。问题在于不到决策定好以后，你都无法真正知道一项决策到底是好是坏，因此会有“后见之明总是完美的”这种说法。出色的决策制定更多说的是决策制定的过程，而不是决策本身。事实上往往有很多时候更好的办法是先做出一个哪怕是错的决策，这也比无尽地拖延或者在决策制定后不断地反复来得棒。
特别地，出色的决策制定过程会获取到所有相关的信息、会从其他股东那里寻求意见和建议，对决策制定的时间设置期限，然后做出决定，并把决定以及其背后的原因都宣告给所有相关的人听。即使一个决定是错的，这个过程能确保团队在游戏开发过程中有着足够清晰的方向，从而逐步产生对制作人的信任。除此之外，如果决策背后的原因是很有说服力的，那这个决定在绝大多数情况下都是对的。当然，没有任何人是一个完美的决策制定者，但倘若不遵循清晰的决策制定流程，那只会加大有着错误的理由的坏决策产生的几率，并且更糟糕的情况是这个决策还拖延了很长时间才做出来。
参加预算会议
在预算会议上，制作人必须解释预算的当前情况，考虑到项目已经投入了多少钱，以及接下来还要投入多少钱才能让游戏如期完成。这往往还包括一份对项目（或者品牌）的盈亏账目分析表。
超前思考
超前思考意味着你要超前地展望和推理，提前一天、一周，乃至一个月地思考，这样问题才不会突如其来地出现在你面前构成阻止游戏完成的障碍。这包括了在这些问题影响到游戏开发前对它们进行调查和寻找解决方案。获得游戏开发工具以及第三方软件的授权正是制作人所需的超前思考的例子。
游戏开发里其他的基础决策还包括游戏的最小系统说明书、游戏要支持的显卡，又或者是游戏要发布的平台数目。制作人必需考虑到有可能影响游戏开发的所有问题，并且以超前思考的习惯去看待它们。
建立统一意见
尽可能去寻求建立统一意见的方法是确保团队内关系融洽的最好的方法。你可以在形成决策的过程中询问团队的意见，以此来建立团队的信任，这是建立统一意见的其中一种方法。建立统一意见，实质上正是要让其他人觉得你的想法也是他们自己的想法那样。
有时候一项决定没有得到所有人的同意，这是做出决定是很艰难的。但在出现这种情况前，尽你所能去建立统一意见并采用其他人的建议。要让大家都达成一致往往是一项棘手的挑战。
提交动画
虽然视频游戏基本上是和玩法相关的，但视频游戏制作人往往要为游戏提交一些特殊的动画来帮助传达故事，为市场营销策略提供推销内容。这需要制作人同时提交游戏玩法和演示动画，这是需要他对项目有着极大热情的。制作人要为市场宣传去做一个特殊渲染的游戏宣传片，这是他必须和其他工作相互平衡的。无论这段动画是为市场而作、为游戏而作，还是同时为这两者而作，制作人都必须和美术总监以及动画师紧密合作，确保动画能按时完成，合适整个游戏，并且运用常见的电影技巧来展现故事和游戏玩法的结合。
制定前期制作计划
制作人必须去制定前期制作（Pre-Production）计划，这是游戏的整体开发所依赖的基础。在前期制作计划里，制作人会和团队主管一起去确立完成产品的最关键的路径，决定达成各种目标的行动方针。
前期制作是在游戏开发团队准备制作游戏以及为制作该游戏的目标打下根基的时期。理想来说，当团队开始制作时，项目里应该界定好所有的目标，设定好达成这些目标的各个过程。
前期制作往往会用来测试和改良美术的输出流水线，以及用来筹备游戏设计文档，与此同时还会为游戏确立美术资源清单。这个过程还包括为游戏细化出美术、设计和功能上的需求，然后把它们囊括到计划里。

建议
通常我会推荐在前期制作里完成一个原型或者小游戏，以此来把它确立成你真正要做的游戏的一个测试实例。这个原型除了耗费的成本比最终产品少以外，它还能让团队成员在进入到一个更大的项目开发前，能极大程度了解到开发的过程，并且在需要时对人员和流程的各方面进行调整。

制定制作计划
正如前面说到制作人必须制定一份前期制作计划那样，他也必须制定一份制作计划，这是组成游戏开发的计划的实际文档。虽然计划往往是用于消除各种不确定性，但事实上制作计划正是最合适于评估游戏将会以何种方式完成。制作计划包含了各种较小的计划，这些计划里描述了游戏中的所有元素以及这些元素的完成方式。这包含了参与游戏制作的每个团队（包括设计师、美术人员和程序员）所递交的计划。这份制作计划会把这些不同的文档都放在一起，让感兴趣的群体能查阅整个项目，了解它的各种风险、所需的预算、功能清单、计划，以及美术资源。
特别地，一份制作计划会包含以下文档：

• 基本陈述或执行摘要。简单来说，这份文档会勾勒出为什么游戏是有趣的原因。
  
• 创作设计文档。这份文档会列出游戏在创意和艺术表现上的构思。
  
• 技术设计文档。这份文档会基于创作设计文档来列出游戏所需的各种功能。
  
• 风险管理计划。这份文档会列出项目有哪些风险，以及如何把这些风险减到最小。
  
• 开发计划。这既可以是一份详细的计划，也可以只是一份月度里程碑计划。
  
• 预算和资金需求。这份文档会列出每个月的成本分配、资金支出等情况。
  

生成游戏设计文档
制作人必须和设计团队紧密协作，澄清游戏设计文档，确保它很容易推向制作，且该文档内部统一。游戏设计师都很容易会做出过于精巧、复杂和不连贯的设计，这种特质可能需要一段开发时间才能调整过来。但在此之前他们往往会这样做，而制作人的职责正是把他们引导回来，让他们做出可行且依然有趣的设计。
应对硬件生产商
制作人是面对硬件生产商的关键联系人，例如像Intel、NVidia、ATI、创新、微软，以及像索尼、任天堂和微软Xbox那样的平台制造商。制作人在其中的角色是和这些硬件生产商的代理建立并维持良好的关系，确保游戏开发团队能拿到最新的硬件、驱动、技术支持，以及把这些硬件发挥到最大潜力的技术知识。这包括了拿到这些显卡和声卡的评估版或者预发售版，乃至其开发版本，然后确保游戏能兼容于为数最广的硬件产品、周边和平台附加件（例如方向盘、跳舞毯、乐器（例如《欢乐森巴》的打击乐器）等等）。
处理法律和协约问题
制作人往往需要具备协约和商务官司相关的法律知识。尽管你肯定会听取律师和其他专家的建议，但你还是需要理解各种基本的原理，例如契约法、民众诉讼、知识产权所有权，以及和协约相关的基础法律原理，例如独家和非独家授权。即使你作为制作人的第一个项目不需要用到这些知识，只要你当制作人的时间越长，你就越可能发现这些知识是很重要的。
处理授权和品牌问题
授权是指建立并管理起授权持有者和产品开发过程中牵涉到授权的部分间的关系。品牌是指一个产品的整体印象（既包括一个授权的品牌，也包括原创品牌），这样产品能和品牌的印象一致，进一步支撑品牌的主要优势，并有利于品牌的发展。品牌在软件行业市场销售中是很重要的，因为它包含了一个独特的名字，这个名字让整个产品和制造商都在环境中独树一帜。制作人在管理一个视频游戏的开发过程中，他必须抓住授权和品牌背后的印象和概念，利用这两者来开发产品。
处理中间件的问题
中间件（Middelware）的问题是指游戏开发团队在使用中间件工具时面临的问题和挑战，例如Criterion Software和Gamebryo提供的中间件。这些中间件工具能让游戏开发者得到一套标准的工具，并且这些工具的功能是受限在有限的游戏类型里的。当游戏的设计里需要一套特殊功能，或者所需的实现机制是超出现有的中间件能支持的范围时，制作人必须了解和解决这些中间件的问题。他可以联系中间件的提供商，让提供商给予更多的支持；也可以寻求别的第三方工具的授权来为游戏设计师和关卡设计师提供所需的功能。很多时候也没能这么容易地解决，这时就需要制作人想出各种替代性解决方案，并协助挑选出最适合游戏的方案了。
应对平台过渡
平台过渡是指视频游戏行业中独有的时期，它是当已有家用机平台在现今市场上盘踞着并表现良好，同时新平台也准备进行商业发布的期间。在这段期间里，平台的游戏开发是极具挑战的，因为新的家用机平台的硬件往往是还没确定下来的，视频游戏开发者也还没得到开发包（为该新平台准备的专门的电脑硬件）。平台过渡期间需要在制作人层面上进行超前思考，以加强游戏设计的灵活性，并且还需要对开发计划进行谨慎考虑。
处理公关问题
公关包括与新闻界会面，为演示和评估展现游戏的前期发布版本。这需要花时间与媒体见面，需要出色的演讲能力、精心准备的讲稿，以及对项目满腔的热情。公关是制作人一直需要承担的责任，他必须提供各种采访、截图和相关材料去确保引起公众对游戏开发的兴趣。当和公关部门的代表合作时，也需要制作人具备出色的人际交往能力。
应对质量保证
很多制作人、联合制作人和助理制作人都要负责监管游戏的质量保证和测试工作。在某些情况里，他们要直接插手到游戏开发团队中的测试员或者是QA部门，联系测试主管或者QA部门经理。和QA部门一起工作是很有压力且极具挑战的，但当游戏开发团队不断修正Bug并把产品不断引向成品时，这个过程也是很有回报的。QA管理往往需要合理地输入和跟踪Bug。
协助推销
制作人会尽一切所能去协助推销视频游戏。这包括和销售部门、买家、市场部门以及公关部门开会。卖得最好的产品都需要制作人最大的支持，这样每一个参与产品的市场销售的人都能清楚了解游戏背后的构想，了解到它的吸引力所在和让人兴奋的原因。把信息清晰地传达给销售渠道、整个行业，以及消费者，这是一个游戏成功的极大组成部分。
招聘/面试
制作人很大的责任是为游戏开发团队招聘新成员。当然也有例外情况，但总的来说制作人要为候选人审查的事情负责，确保招来的人能和团队里其余人很好地协作。寻找一个有才能的人或者一个会在团队里发光的新成员是每个制作人需要培养的能力，只有这样他才能获得长期的成功。招聘和面试的过程往往包含了程序员的测试、设计师的问答、亲自面试以及电话评估。一些制作人还会负责薪资谈判部分，但所有制作人都有责任确保他们招聘的人是在适合的团队里做着适合的职位的适合的人，团队里的每个人都必须保证和新成员很好地协作。
影响上层管理者（高管）
制作人往往有机会和上层管理者直接洽谈，以此影响他们的决定。不断锻炼这种技巧是很重要的，因为它会影响到每一个和你一起工作的人，从而最终影响到你作为制作人的事业生涯。这里的关键在于理解高管评估机遇、管理风险，以及行动决策的方式和理由。
了解游戏
制作人必须是视频游戏领域里一名最好的权威人士。这意味着制作人必须把他对游戏的了解以及他对游戏趣味性的了解运用到当前的项目上。他要能和设计团队讨论各种设计原理，要能清楚地表达出一个竞争对手产品的美术表现，还能和程序员讨论整个市场上特定一个程序特性的优劣，制作人对视频游戏的这些了解都是极其有用的。
学习
制作人需要一直寻求新方法去提升效率，改善最优方法，同时扩展自己以及团队成员的学习机会。只诉诸于之前的经验和知识来作为自己的全部资产，这会限制了制作人的效力。在技术和开发流程都日新月异的时代，制作人应该不断寻求各种方法来扩展自己的学习能力和学习机会。
管理资源（Assets）
资源管理是对成千上万的资源进行管理的流程和方法，只有通过管理这些资源，把它们聚合在一起才能完成一个视频游戏。这包括美术资源，例如模型、贴图、界面元素、菜单屏幕、动画序列，以及特效渲染。在设计上，它包括场景编辑工具、多人游戏设计、功能说明书、用例、故事、剧本、核心玩法，以及坚持游戏的基本陈述。在程序上，它包括工具、功能点、输出流水线和文档。最后（但肯定不限于这点），资源管理还包括管理外部内容的交付，例如录音、音效、音乐（环境音和线性音）、本土化（包括所有声音和文本资源的多语言制作），以及游戏为市场和公关准备的各种材料的制作和交付。
管理大团队
管理大团队是一项极大的挑战，它有着自己独有的难点，例如协调输出流水线、整合功能点、资源跟踪等等。事实上，一旦团队由60～100人组成后，光是和团队沟通协调已经比起30～40人的团队困难得多了。这里的技巧在于把你的大团队分解为多个较小的团队，然后把管理这些小团队的责任委派到其他制作人身上。更重要的是寻找合适的人，让他们去负责这些小团队里最关键的部分。这些人会在效率和效能上为其他人设立出各种范例的。
管理国外本土化工作
国外本土化工作是指用一种语言来做出一个游戏，然后把它的内容进行本土化，让它能投放到更广泛的国际市场上。例如大多数游戏都是用英语来开发的，然后再本土化成德文、意大利文和法文版本。通常来说，这意味着你要管理成千上万个单独文件，这些文件是用别的语言制作而成的语音、美术资源、菜单界面，通过管理这些文件，最后把它在游戏里整合，再发布到零售商店里。要为国际市场开发本土化版本需要方方面面都做得很好的产品。本体化的过程往往是复杂且耗时的，而且各种细节的本土化以及声音的本土化管理工作也是让人极为头痛的。
管理人力资源（Resources）
人力资源管理是指决定各种资源在何时何地进行分配。显然，不是所有任务都能同时进行的，于是各种任务需要划分优先级，然后在不同任务上指派足够的资源来完成该项任务。这种资源分配的过程往往需要对各项任务进行不断地评估和调整，这样才能确保资源在整个项目开发过程中能合理分配，因为整个开发过程是牵涉了数十人以及横跨数年的时间的。
管理美术流程
制作人必须管理游戏中美术资源产出的流程。这包括在美术资源完成后跟踪这些资源，同时也要能鉴别出那些没完成和不完整的美术资源。通常美术开发上的人力资源需要经常重新分配，这样才能确保美术计划是一直满载着顺利前行的。制作人的职责是和美术团队一起去管理这个流程，并且对各种风险有所计划。
管理声音流程
这个标题本身就能衍生出一个职位了。开发声音的过程包括管理项目的声音外包商（他们负责提供录制的语音，负责声音编辑，提供音效和音乐），同时还要在需要时提供工作室混音和录音所需的条件。具备制作声音的能力，同时能理解声音和音乐对视觉的影响，这本身就是一门完整的艺术了。
管理厂商关系
管理厂商（Vendor）关系往往是被忽视或者轻视的，但制作人总是要和外部公司签订协议，让它们提供最关键的服务来用于游戏开发。外部厂商提供的产品和服务包括3D建模所需的软件支持（例如3DsMax、Maya、Lightwave）、声音库，以及第三方软件工具（例如Xoreax Software提供的Incredibuild）。甚至是像Alienware那样的电脑开发商也对我们开发的游戏提供了开发所需的硬件。所以厂商关系中的每一个厂商都是很重要的。
通常来说，当制作人和厂商以及外包商建立起良好的合作关系后，他们会继续在多个产品上合作。当彼此关系一直维持得很好时，这些厂商和外包商也会很容易协助下一个项目，这样能让你省去了寻找厂商的过程，并且这些厂商是经过验证的。
管理你的时间
时间管理或许是当一名制作人所需要具备的最基础的因素了。事实上，时间管理也是影响一个游戏是否会被撤销的最大因素。为什么这样说呢？因为游戏开发里其中一项有限的元素是时间。我们是不可能让时间重来的，但往往能在游戏上投入更多资金，或者是牺牲游戏的品质。时间管理是对项目资源进行分配的过程和手段，以此来确保这些资源在项目允许的时间范围内给项目带来最有效和最充足的效力。
推销
推销是指把想法或者概念推销出去的能力，这种概念特别指游戏概念和开发计划。当制作人在推销一个游戏时，无论面前的听众是高层、发行商，还是公众媒体，他都必须成为这些人的销售员。一次成功的推销需要制作人对他的产品充满激情和热情，并且能把这种兴奋和热情传达给其他人，让其他人认同并购买产品。一个游戏在没有很好的推销前是无法成功走向市场的。
具备行业经验
行业经验是很重要的，因为它为制作人提供了一个精准的参考框架。需要注意的是，虽然视频游戏行业里的经验和传统娱乐行业的经验有一定的相似点，但总的来说它们是不一样的。在视频游戏行业里没有那两天是活得一样的，有经验的制作人在这个行业中更有可能要高效地应对软件项目中日常面临的各种常见和不常见的挑战。当制作人经历的年限越长，特别是当应对过几个处于不同硬件平台上的项目后，制作人也显得价值越高。在不同规模大小的项目上的经验也是很有价值的，因为大型项目的问题和小型项目是完全不同的。
提供清晰的指引和焦点重心
清晰的指引和焦点重心是指制作人对游戏的理解以及游戏提供给用户的最吸引人的体验。当各种各样让人望而生畏的任务堆积在游戏通往成功的道路上时，提供清晰的指引和焦点重心是至关重要的。让团队首先聚焦于最重要和最高风险的任务上。当情况变得变得棘手时，程序、美术和设计需求明显存在分歧时，制作人需要对项目的最终目标提供清晰的指引，让大家把焦点重心放在其上，这样能最终挽救整个游戏。
提供市场支持
对市场部门提供支持即使对最棒的制作人也是一项很有挑战的任务。各种市场资料的需求（例如截图、视频、包装盒上的描述、杂志附赠碟）只是市场部门对游戏开发团队需求的很小一部分材料。对制作人来说，他的挑战在于寻找交付这些材料的最佳方式，在不影响到团队且不转嫁他们的开发精力的情况下把这些资源和信息交给市场部门。
制定计划
计划过程需要把前面提到的“时间管理”和“人力资源管理”的技能都结合在一起，把这两种因素都放到计划里，让它能呈现给别人且容易理解。往往制作人职责中很大一部分在于计划的不断更新。要管理好这些计划，精通Microsoft的Excel、Project，乃至Access会是很重要的一部分。
制定并颁布纪律
EA（Electronic Arts，艺电）是如今视频游戏行业的一大领头。为什么能做到这样呢？因为EA把纪律性的方法运用到软件开发里，并把它推广到它业务中的方方面面。事实上一家企业成功的至关重要的因素在于它运用到业务和开发方式上的纪律。正面且积极的纪律是企业中最重要的组成，因为它能确保业务上长期的成功。
对制作人来说，你应该通过以下的方式去散布纪律的种子：

• 为各人设定目标，并鼓励他们去达成目标。写下这些目标，并在达成这些目标后提供各种奖励，这样能激发你的雇员去做得更好。
  
• 从团队的每个成员中得到达成这些目标的承诺。获取承诺能确保每个人都理解你对他们的期望，并答应去满足这些期望。
  
• 当工作向前进行时，评判两个承担类似职责的组别的进度和成绩。时刻留意到团队及其成员的进度，在工作可以变得更有效时鉴别出来。
  
• 让其他人对自己的行动和承诺负责，尤其是当他们任务艰难推进却从不寻求帮助时。当然，各种外部的影响、外部因素、难题和挑战都会影响人们完成工作的能力，但总有着很多手段能帮助他们克服这些挑战并达成目标。
  

SMART目标 SMART目标是对以下目标的缩写： - 具体的（Specific）。当你确立目标时要尽可能具体。在这点上，清楚阐明是其中的王道。当目标不具体时是很难鼓动别人去达成的，并且要评判其结果也是很难的。 - 可评判（Measurable）。可评判的结果是很重要的。在周五完成项目报告，或者是在本月末完成游戏设计的功能说明书，这两个都是可评判且具体的例子。 - 可承受的（Acceptable）。设定你自己的目标。没有任何人比你自己更清楚你的能力了。你要用自己的标准去确定出可承受的目标，然后履行它或者超越它。 - 现实的（Realistic）。如果你知道只有一部分目标是真正能完成的，那就不要设立一大堆要达成的计划。把精力投入到一些较大的目标上，而不是集中在一大堆小目标上。 - 时间限制（Time bound）。确定下这些目标要在什么时候达成，同时你会在什么时候有时间去做这些事情。一旦你马上写下这两点，那会让目标更容易达成。

主人翁意识
当制作人具备主人翁意识时，这意味着他会对自己的工作以及团队的工作产生自豪感和成就感。主人翁意识不是指在工作完成后沾光，而是对自己设立目标，移除通往目标的各种障碍，以此让工作顺利达成。那些不对自己领域或者职责具备完全的主人翁意识的制作人通常来说都不是很高效的。对项目、游戏和团队的主人公意识必须和游戏开发的进度、目标以及市场条件的客观评判相平衡。制作人是不能在无视影响游戏的外部因素的情况下独占着项目的。
教授他人
教授他人的能力是制作人另一项必需的技能。由于沟通是制作人职责中的主要部分，所以他必须能把自己的学识、教训和经验都传达给团队中的其他人。通常来说，只要能解释当前情况和情形，回答团队成员提出的各种问题，这样就能确保团队中的问题在对团队生产效率造成明显影响前解决它们。只要能清楚准确地向团队解释出决策背后的理由，那这项决策就不会显得武断随意。除此之外，制作人还需要让新的团队成员融入到项目里，教授他新的流程、方法和最优方法，让他能更有效地投入工作。这些不同的情形都需要制作人能分享他的学识，教授那些愿意去学习的人。
了解视频制作
视频制作包括故事板编写、动画制作和实时渲染（或者是对游戏里的视频序列进行影片化）。这些视频把故事和游戏玩法关联在一起，让用户更容易理解。要在这个领域上获得成功，你必须在电影上有一定的知识背景，例如场景合成、光照技术、剧本、游戏玩法展现，以及声音和音乐的录制。
了解开发系统
开发系统是指游戏开发者为相应平台（例如Xbox、PS2和NGC）开发所需要的专门系统。往往这些硬件系统是很难获取的，制作人的职责是确保这些系统能交付到团队手上。只有极少量的游戏的开发是在没有这种开发系统去拟真最终硬件的情况下设计和开发出来的。
与程序团队协作
制作人必须和程序团队一起工作，在开发过程的早期确立下他们的关键目标，然后确保程序员达成目标所需的所有工具。在开发过程中，制作人的职责是跟踪进度，了解工作量和功能点之间的依赖关系，定下关键的里程碑，同时协助程序员解决（非技术）问题。
软件开发方法

所有的游戏都是不一样的，所以用来制作出这些游戏的方法也不一样。事实上有很多种方法可以开发出一个视频游戏。这部分我们会看看几种常见的软件开发方法能如何运用到游戏开发上。我们会顺着这个思路来看看视频游戏是如何制作出来的，整个开发流程是如何达成的。在这本书后面的章节里，我会详细谈谈游戏中每个部分的细节，看看当你作为制作人时，可以用哪些工具来保持项目处于轨道上，并且能如何运用这些工具。
Code-Like-Hell, Fix-Like-Hell

Code-Like-Hell, Fix-Like-Hell（Code and Fix，编码再修Bug的莽撞式编程方法）的游戏软件开发方法如下图1.1所示，它可能是最常见且最古老的模型了。在这种方法里会进行一定的提前规划，但这些规划极少在后面遵循、更新和引用到。程序员会按他们心中所想的设计去尽可能快地编码实现，然后再去测试和校正。这种模型往往导致失败，因为在开发过程中会出现各种紧急情况。程序员是无法在一直忙乱的节奏下工作的，设计师和测试人员也同样如此。结果是这个过程会随着时间被进一步拆分。开发中留下了很多问题，而这些问题在有人发现之前是一直得不到修正的，但到了想修正的时候，代码已经写到很难把这些问题和bug修正的地步了。这种模型通常只适合于有着简单需求的小型项目，因为一旦面对更长的周期（6个月以上），代码就很难维护了。这个方法在《极限游戏开发方法》（extreme game development method 或者 XP method）中如图1.1所示。



图1.1 code-like-hell, fix-like-hell的开发方式

增量完成法（Increments to Completion）

增量完成法是让软件以相对紧凑和有限的增量方式去开发的软件开发方法。在开发冒险游戏或者第一人称射击游戏（FPS）时用这种方法是很管用的，因为一旦引擎和编辑器都到位后，游戏里每一部分都只是对原始核心的一块增量而已。当各部分从团队中的各个组别里开发出来后，它们会用高层设计文档（high-level documentation）去校验一次。这份高层设计文档会勾勒出游戏中的设计和各个关键需求点的详细说明，而低层设计文档（low-level documentation）会在功能点实现前后完成，通常是在设计师和程序员就一个功能点的可行性以及实现方式达成一致时完成。
增量完成模型如下图1.2所示，使用这种模型的优点在于游戏中各个功能点可以并行开发，并且能独立于游戏的其余部分。这在理论上往往显得很好，但如果没有高程度的协调和容易调整的代码结构，那在实现起来是有很大挑战的。尽管这种模型的好处总是没超过其隐患，但制作人还是该考虑用这种模型，让团队在开发过程早期做出一个可玩的游戏，然后不断加入不同的系统、功能和美术资源，整合到游戏里。通常来说在前几次（例如原型开发阶段）增量开发中学到的教训在后续长期的开发里会显得帮助很大。



图1.2 增量完成法

瀑布（Cascade）模型法

瀑布模型（Cascade）是指在游戏的一部分完成后，整个团队把重心都放到下一部分上（如图1.3所示）。在这种方法里，游戏的各部分会相对较快地整合在一起，在功能制作和实现间留给测试的时间很少。对游戏来说，通常前面开发的部分都是需要重新考虑和重新修改的，因为当越来越多内容添加到游戏时，其功能、外观以及特定功能原有的用途都会发生改变。但当用了这个模型后就很难去改游戏中的主要系统了，它需要一切内容从一开始就正确且直接地走到最后。基于这个原因，这种方法不推荐在游戏开发中使用。



图1.3 瀑布模型法

迭代直到交付

迭代直到交付（iterate-until-you-drop）的方法可能是软件开发方法中最灵活的，它的全部目的是帮助你（制作人）界定游戏中的关键领域，开始开发这些领域，并在开发过程中段完成游戏的设计。它的好处在于当游戏开发者不确定成品中会引入哪些功能点时，还能同时完成计划。它让游戏开发团队能及时响应不断改变的市场运作和市场需求，提供了足够的灵活性去快速地实现程序代码，让开发团队、发行商以及游戏设计师能对游戏中的乐趣成分进行不断迭代（也就是说，随着游戏玩得越来越多，在每一次迭代里加入越来越多的玩法改良，游戏也随之变得越来越有趣）。这个模型如图1.4所示。总的来说，迭代式开发是一种很有用的流程，是不容轻视的。尤其是当你觉得软件开发历史中发布过的众多游戏都毫无趣味时。
当制作人有着合适的工具且理解面向对象编程以及软件开发背后的方法论时，这种方法是很有用的，并且推荐使用。但假如不能有效管理，那最大的优势也会变成最大的缺陷。例如大多数游戏的设计都没有完全敲定出组成游戏乐趣成分的元素清单。很多时候直到游戏整合出预发售版本才意识到游戏里最有趣的部分。所以这种迭代直到交付的方法是永远没有尽头的，是一直可以改良的软件开发方法。这种方法的最大好处是能适应不断变化的需求。制作人的职责在于确保这种方法不会失去控制，也不会成为预算和开发时间不断增长的正当理由。
当采用这种方法时，切记运用合适的工具和战术手段，这样才能保证不用超出预算或者在同一个游戏里投入太多年才完成项目。



图1.4 迭代直到交付方法

敏捷项目管理

在《敏捷项目管理》（Agile Project Management，Pearson Publishing，2004）一书里，作者Jim Highsmith提出了一种很棒的方法，这种方法把迭代直到交付的方法中最棒的原理以及每个制作人都应该考虑的一些关键原理结合在一起。我在这里把Highsmith的想法的要点列出来，因为敏捷项目管理的原理一直贯穿在这本书的每个章节里。
敏捷项目管理是组织和操练团队的很棒的方法，它的重心放在软件开发中以下的关键阶段：

• 构想
  
• 推测
  
• 探索
  
• 适应
  
• 结束
  

备注
流程中每个阶段的名字都引自该阶段的行为和想要得到的结果。Highsmith避免用诸如发起、计划和指挥等词汇，因为这些词汇不够精确，虽然它们也对应着视频游戏软件开发项目中相应的过程。

构想（Envision）
构想是指游戏设计师的想法或者游戏的基本陈述。在构想阶段还需要考虑的事情包括游戏内容范围、游戏社区支持，以及团队协作的方式。在这个阶段会定下游戏关键的卖点，也就是让游戏显得有趣的组成部分。这时候也会回答诸如“你在做的是什么游戏”以及“这个游戏是面向什么群体的人制作的”的一类问题。除此之外，这个阶段还会回答“你要用什么人去做出这个游戏”的问题。构想阶段是游戏设计师和制作人共同协作去为一个新的游戏开发项目散发热情的阶段，是展开项目管理的阶段，也是关键的团队成员构想接下来的协作方式的阶段。
推测（Speculate）
说起Speculation可能首先让你想起投机活动，呈现出一些不顾后果的行为，例如淘金或者玩弄股票市场的行动。但它在字典里的真正定义是：“就一个主题进行猜想；深思考虑”，另一个定义是“往往基于非决定性的迹象来采用推理的过程”。这个定义准确描述出游戏开发项目的开始阶段里，制作人、设计师、美术人员和程序员着手的工作。制作人在着手计划时应该意识到，计划的目标是在极不确定的过程里排除各种不确定性。当无法排除各种不确定因素时，制作人应该重新计划，尽管有时候这样做也徒劳无功。“推测”这个词描述的正是视频游戏软件开发中的现状，视频游戏都有着不稳定的市场。
推测阶段包括了：确定游戏的高层需求、列出完成游戏所需要做的工作，以及建立起开发计划（包括一份人力资源分配计划）、功能清单、风险管理计划和预算计划。
探索（Explore）
敏捷项目管理中的探索阶段指的是寻找和交付功能的过程。游戏设计中需求的功能点的交付是探索阶段的首要目标。你会利用高效的时间管理、人力资源分配以及风险管理策略去达成这部分的内容。其次团队也会建立起协作式的项目团体，有着一定的自我组织能力（只有这样，制作人才无需去操心诸如谁坐在哪里的问题）。制作人在这个过程中只是充当润滑剂的作用。最后，在探索阶段里，制作人必须管理好团队与管理层、市场部门、QA部门，以及其他股东（例如授权商）间的关系。
适应（Adapt）
适应这个词是指必不可少的调整，或者是为了让项目保持重心且计划如期完成所做的改变。适应还包括了把各种学到的教训总结归纳，并且把它们运用到项目中期（一般来说，随时响应改变比盲目地遵循计划要更重要）乃至项目整个生命周期里，也就是说，当团队在适应期掌握到一些新的信息后，即时是对构想阶段作出改变也并非不可能的。
在这个阶段，团队产生的各种技术上和创作上的结果往往都是可评判的，并且是可以接受公开批评的。制作人在这个阶段应该把项目状态和已发布的计划进行分析比较。往往这种分析会只关注在游戏的预算和财政影响上，把这些和完成游戏所需的功能点作比较。分析的结果会加入到适应和重计划阶段，为下一次迭代做准备。
结束（Finalize）
结束是指项目完成的过程，在这个过程里必须要做的是把项目中犯下的错误和学到的教训都写下来，用来为团队和制作人积累经验。往往一个游戏开发团队是不想经历项目的结束阶段的，因为游戏后期还需要不断发布补丁和更新包，但对大多数项目来说，只要能结束就值得庆贺了。
规划和计划

如今你对游戏制作的过程已经有了一定的基础了解了，接下来让我们看看规划和计划阶段。在计划一个项目时有两种基本方法：

• 自顶向下法
  
• 自底向上法
  

采用自顶向下法

自顶向下计划通常是由一个人或者一个小团队去提供项目计划的概貌。不幸的是这种规划往往会被当成真理，假如没有经过相当大的挫折和烦恼是基本不会重新构思的。自顶向下计划往往都不会牵涉其他人，不会召集一些人来让他们参与完成计划。因此自顶向下计划只能看成是一个目标或者一条指引。往好的说是一个猜想，往坏的说是完全错误的。这种抛开工具的做法能促成制作人对游戏内容范围和复杂性的更深的理解。但在制作自顶向下计划时需要注意的是，当游戏有了更多的信息，且团队提供了更多的输入源时，你应该放弃对这份计划的坚持，慎重考虑要不要重新构思。
自底向上计划

当制作人自底向上计划时，他会召集相关的团队成员去为游戏共同建立一份计划，大家对达成目标所需要的时间和人力资源达成统一意见。在这个过程里会列出所有的美术资源、游戏功能点以及其他的项目需求。这一般会在预制作计划做到相当程度后开始（本章后面会介绍预制作阶段）。
当计划是自底向上时，第一步是定义出短期目标和近期目标。你要通过一份清晰的计划去确立这些目标，然后在功能点清单和美术资源清单中登记各个项，然后再把相应任务在计划里指派到团队各部分中。通过经历这个过程，并且让游戏开发所需的各个领域的人都参与进来，你能在计划里分享这种主人翁意识。人们往往都喜欢被征询意见和寻求输入，对视频游戏的计划过程来说也不例外。进一步而言，这种做法能避免单个团队成员或者少部分团队成员在计划里拖后腿，因为在计划创建之初他们已经达成一致了。（当你看到人们都全力去保护计划来维护尊严时，你还会为这种额外效果大吃一惊。）反之而行的方法是我不建议的，它尤其会在后期发生团队成员和制作人抱怨的情况：“我早就跟你说过不能这样了”——因为计划在建立时完全没有得到他们的反馈。

注意
这种精细的自底向上的计划会带来同等效果的游戏设计。假如你看到你的游戏设计是不具体的、不清楚的，甚至是模糊矛盾的，那你就要极其小心了：很可能你所做的计划也是一样的。

对各种约束进行计划

当在决定要遵循哪类计划去开发你的游戏时，你要考虑两种不同的“计划－约束”模型：

• 时间约束模型
  
• 资源约束模型（包括财政资源）
  

这两种模型都会把每个团队建立的各个小计划合并成一份，包括设计师、美术人员和程序员做出来的计划。要建立起你的计划，你可以如下描述那样考虑采用这两种模型。
每个团队的主管（例如美术主管或者美术总监，又或者主程和主设计师）都会看看自己团队能不能达成，以及如何去达成项目的各种目标。当评估完成以后，他会做出自己负责的那一小部分领域的计划。主程会（在制作人的协助下）做出编码的计划。主设计师和主美会做出相应的设计计划和美术开发计划。然后制作人会把这些小计划合并成一份大的计划，再从中寻找依赖关系、关键路径和资源分配需求。
时间约束模型
评估时间约束计划模型是确定出一份合理的开发计划的第一步。当用时间约束模型制定计划时，建立计划的过程中不需要考虑任何资源上的需求，只要确定出各项任务、功能点、负责人，以及每项任务的依赖关系就可以了。然后你要对每项任务猜测其所需时长，再尝试把各项相互依赖的任务关联起来。你要对各种依赖关系进行分类，让最基础和风险最高的任务最早出现在计划里，然后再到风险较小的任务。这个过程的重点在于确定出特定规模和内容范围的项目是否能在制作人希望的时间范围内完成。
资源约束模型
当你为开发计划建立起一份时间约束模型后，你要把它转化成一份资源约束模型。你（和其他团队主管）要全力把各项任务合理地指派到具有相应技能的资源上。你需要确定出这些资源将会在何时何地能完成该项任务。当然，切记此时你还处于推测阶段。你还得确定出各项关键任务，这些关键任务是没有合适的资源可以指派的。这意味着你需要雇用有着相应技能的新团队成员，或者让已有团队成员去学习该项任务所需的技能。随后要清楚地区分开工作日、假期和周末，并且对病假、聚会和日常行政开支（为所有团队主管而设）提供预算。
这正是制定计划充满挑战的地方。接下来你的任务是在这份计划的每部分里加入各种为突发事故所预留的冗余时间，例如每周的周末假期以及一些提供灵动性的日子，把这些冗余时间平均分配到整份开发计划的各处。然后再设法把这份开发计划划分成几大部分，每部分称为一个里程碑（Milestone）。这能有助于跟踪团队的进度，为管理层提供清晰和可评判的方法去评估游戏的开发状况。

备注
制作人在游戏开发项目不断进行的过程中可能要对这份约束模型进行多次重建。而且你得意识到，你所做的这份开发计划实际上只是把多份小团队计划合并在一起，因此你要全力把各项任务分解成有限的且可评估的领域。

当你转入资源约束模型后，你可能会意识到因为各种时间和资源上的约束，原来设计的游戏可能无法在这些约束下制作出来。这就意味着你要寻求产能提升的方法，或者要着手去在游戏设计中砍去一些功能点和内容了。
关键路径计划

关键路径（Critical-Path）是组成项目开始到结束的多项任务或者事件（如下图1.5所示）。这一系列的任务在计划上是没有时间缓冲的。如果你想缩短项目周期，那你必须把重心放在关键路径的任务上。总的来说，一个游戏的全部任务中只有较少任务是处于关键路径上的（一般少于25%），但关键路径上的项一般都遵循着特定的顺序，按着一系列事件来发生。
关键路径是完成整个游戏的最短路径，因此为路径上的任务制定合理的计划是很重要的。关键路径的计划包括对这些事件的顺序的理解，确保所有潜在会影响到关键路径上的任务达成的问题和障碍在着手该项任务前都统统解决。



图1.5 项目的关键路径在于游戏世界和关卡的制作，而不在于故事板、工具开发和剧本

突发事故计划

即使是最完美的计划也会出错，这就是为什么在着手开发游戏前，在计划中考虑突发事故是如此重要的原因。按照以下的方法去对这些无法预期的事件进行计划，这样能为你的项目去掉很大一部分的破坏性因素。
计划加班时间
这已经是视频游戏行业中的行业标准了：大家都认为要让项目如期完成都必须经过很长的时间。由于大部分专业的雇员都会免除加班费，所以这对视频游戏的开发商或者发行商是没有多少财政影响的。
雇用更多员工
当你考虑通过增加人员来确保计划如期达成时需要多加小心。尽管第一眼会显得这是保证计划的一个很好的方法，但很多时候都会适得其反的。首先额外的人员需要额外的管理。其次，增加一名新团队成员不可避免要有一段融入期，让新雇员能通过项目的流程和目标去熟悉他的工作。在这段融入期里，新团队成员往往会让其他人效率降低，阻碍了其他人如期完成工作。最后，增加人员也会耗费更多成本，这不单单是工资上带来的成本，还包括配套设备上的成本。
节假日工作
尽管一些游戏公司和发行公司都有着自由政策，让员工可以自主安排时间而不是在别的时间里工作，而且要团队固定要在假日常规工作往往是一种很糟糕的方式。事实上我也不推荐要团队成员在节假日工作来作为突发事故计划的一部分。当经历了多次长时间高强度的工作以后，休息对雇员来说是至关重要的。虽然我偶尔会说服雇员在繁忙的阶段里在节假日工作，从而能换得将来一天的休假，但我还是建议你避开节假日来做计划。你要和团队一起去工作，亲身体验，确保假期是平衡分配的，让工作日和节假日的安排对雇员、团队和项目来说都是互助互利的。这在实际上不难做到，只是要花上一点时间、沟通和理解就好了。
利用一条公式
我会在本章后面谈到这条公式。
别对团队主管安排工作
别安排团队主管（也就是主程、主美和主设计师）去做太多和游戏实际开发相关的工作，让他们有时间去花费到自己团队上，协助管理进度，这样做能确保这些主管能在自己团队需要他去工作时投入到上面。不过通常这都是不太实际的，因为往往有很多任务是只有这些团队主管能胜任的。换句话说，只要制作人和每个主管都确立出一个架构，最小化他们的直接贡献，最大化他们的间接贡献，再克制住不要把任何一个主管安排到关键路径的任何一项任务上，这能确保项目有着足够的灵活性去响应各种因素、需求和条件的变化。

备注
不为这些团队主管安排工作的想法可能会让你很犹豫。毕竟这些团队主管之所以能成为团队领袖是首先在于他们有着出色的工作能力。倘若美术团队里的团队主管是你项目中建模最棒的人，那不是很应该让他负责建模吗？这么说对了一半。假如你把主美放到一个管理角色而不是一个开发角色，那能让他把他的技能传授给其他的团队成员。这种技能的交叉传播能帮助到整个项目。这时你喜欢的不仅仅是他的建模技术了，而是喜欢整个美术团队的技术了。你完全可以让他去教会别人，让主美去设立3D模型的标准，然后让他去监控所有的3D建模人员，协助这些人去达到同样的标准。

当任务完成时留下测试时间
作为制作人，你应该为每位程序员、设计师和美术人员在他们的日常计划中预留一定时间来测试自己以及其他人完成的工作。没什么比得上让团队成员最终要面对游戏里一大堆不完整的或者有问题的代码和美术资源来得糟糕和麻烦了，这些有问题的内容会破坏了整个游戏，让团队无法享受游戏，更别说它们会影响到团队执行计划的能力了。往往我会让同事之间互相查一下对方的资源再把资源签入到源码里供游戏引擎调用。
划分出一笔应急储备金
制作人应该建立起一笔应急储备金，当项目面临重大困难或者面临预算和时间的超出风险时，用这笔资金来随时应变。当你遇到棘手的问题，被问到“你凭什么来保证”的时候，你抛出一句“当然还有我的应急储备金”，这种感觉是很棒的。我往往会在我的预算申请里把应急储备金作为其中一项，并且在我着手游戏预算时就尽早着手这件事。
利用公式来计算计划
当制作人评估完成游戏所需的任务清单时，他提出的第一个问题应该是“完成这项任务理应花上多长时间呢？”回答这个问题的难度在于你往往很难通过计算来得出答案。最简单的方法是认为一个人是完全投入其中工作到任务结束的，但情况极少会这样，因为人员在工作时间内都会被分散精力，或者需要同时去做其他任务（例如协助其他人、填写报销单、参加会议、完成报告、书写电子邮件等等）。无论你是否这样想，公式存在的意义在于让你考虑周转时间，保证计划能应变各种无法避免的干扰所造成的突发情况。这条公式曾经用在其他行业里，但我基于我在游戏行业中的经验对它进行了一定修改，把它叫做“极其灵活的项目计划公式”。公式如下表所示：

任务名：	DirectX兼容性和渲染工作
最佳情况：	10天
最糟情况：	25天
最可能情况：	15天
公式：	（2*最佳情况+3*最糟情况+最可能情况）/6
结果：	（2×10+3×25+15）/6=110/6，或者是18.33天
实际应用：	18.33天对最可能情况的天数提供了3.33天的缓冲

尽管这个公式不是绝对可靠的，但它的确能提供足够的缓冲，借以应变到一些很困难的问题。最好的是制作人还能在任务进行到一半或者项目进行到一半时（正如前面讨论敏捷项目管理中提到的适应阶段）回到任务清单里进行调整，用这条公司去重新评估时间。你还可以调整这个公式去适应你团队中的具体情况。例如，该公式可能无法用在团队主管身上，因为他只有50%的时间可以从事实际的游戏开发工作，剩下的时间都得投入到行政管理上。因此你要修改公式来反映这一点，表现出团队主管只能在每周40小时的工作时间里贡献50%的时间到项目上。换言之，前面18.33天的工作要花上一位主管36.66天的时间才能完成（假设所有其他情况都是一样的）。
软件工厂式的效率

软件工厂（Software Factory）是利用一整套类似工厂那样的流程和方法的组织，它的每一套工具或者技术都是专门定制的，但也根据特定项目的需求，保留着一定的可交换性和可重用性。软件工厂的核心思想是某些功能点和游戏引擎系统的代码、工具和文档都是可重用的。基于这点，它们需要不断去更新，但也同时需要保持它们的可用性和独立性。

备注
软件工厂的概念在这里只是简单地总结一下，为的是让你能更容易引用和理解。在第11章里会谈到Andrew Rollings和Dave Morris写的《游戏架构与设计》一书，里面会谈到关于软件工厂的大量更完整的细节。

采用软件工厂的方式有着很多好处，包括：

• 当团队已经有了一套熟悉的工具时，单个项目的平均时长会缩短。
  
• 由于团队早已熟悉了常用的库在不同平台上的使用方法，跨平台发布也必定变得更容易。
  
• 由于工具使用的组件都是久经考验的，所以利用这些工具编写的代码也更稳定可靠。事实上虽然做到这点是很难的，但利用软件工厂方法能让代码在重用性、可维护性，以及可文档化这几点上做得更好。
  
• 软件工厂的方法能促成工厂中核心系统的信息传播开去。如此当某个团队成员离开时，项目不会因为离开的团队成员带走了贵重的信息而停止或者受到损害。
  
• 采用软件工厂方法的项目对制作人来说往往是更容易评估和跟踪它的进度的，因为他早已熟悉了类似的系统在之前的项目里运用类似的软件工厂方法是如何实现了。
  

但采用这种方法也有着一些缺点是不容忽视的。其中一个缺点是设立一个软件工厂相比于仅仅制作一个游戏是很昂贵且很耗时的。因为软件工厂需要各种各样的工具，例如代码库、世界编辑工具、声音配置工具、关卡编辑器、引擎架构、物件摆放和预览工具，以及关键的渲染库。
其余的缺点还包括：

• 第一个采用这种方法的项目往往要更长时间，因为整个工厂还处于设立期。各种封装库（团队用来确保在特定硬件平台上用到的硬件专用功能）必须要为每一种平台去开发，这样才能让代码和各种库能在多个平台上使用。
  
• 尽管软件工厂环境中的代码已经是更通用了，但要考虑并开发特定路径会用到的所有可能性和潜在应用是很难的。正因为这个原因，其代码在最初的阶段都要花更长的时间去开发。
  
• 一旦你往团队中加入新人员，他们在采用软件工厂方法和各种库时会面临一条学习曲线，因为这些元素都是很专精的。
  
• 总的来说，在建立软件工厂的过程中需要更多的执行工作和超前思考。
  

游戏开发阶段

如今你对游戏制作周边的各种问题都有了解了，现在让我们看看一个假想的游戏项目从开始到结束的过程，看看整个流程中各个主要的阶段。当然，每个发行商在制作游戏时都有着自己专门的步骤，但基本上所有流程都能归纳成以下各个阶段，我会尽可能简单地介绍它们。
概念阶段
概念阶段是游戏概念书写下来的阶段。在这个阶段里会进行头脑风暴，各种想法会在此时产生出来。
原型阶段
在原型阶段里，游戏原型会开发出来，用户能借此开始体验到概念文档中描述的乐趣。原型阶段一般会持续2～4个月，时长取决于团队用来制作原型的各种工具的可用性。
推销阶段
在这个阶段里，游戏开发商/开发者会把自己的游戏推销给高层，又或者假如开发商是不直接为某个游戏发行商工作时，他们会把游戏推销给发行商代表。推销阶段会解释为什么游戏有着很棒的概念，为什么它在时机和定位上都合适当今的视频游戏市场，解释这个游戏是否能制作出来，以及如何能开发出这个游戏。
许可阶段
这个阶段会在推销成功并许可制作时开始，此时会募集起一个团队去着手到游戏里。这个阶段往往牵涉到频繁的面试和接触各个视频游戏开发公司，以此为游戏募集起合适的团队。通常游戏在各种商务和法律问题还没解决前是不会进入到预制作阶段的，这些问题包括谁持有这些技术，包括各种创作的知识产权问题，例如主角和游戏故事的知识产权。
预制作阶段
预制作是游戏开发团队着手确定开发的流水线、敲定出他们开发游戏所需的各种需求和工具，并列出和充实游戏设计背后的各种细节的阶段。
制作阶段
制作阶段是真正开始游戏开发的阶段。此时会做出各种3D模型、建造出游戏世界、录制声音、制作纹理、编辑视频、编写游戏逻辑，以及把游戏方方面面的其他部分开发和整合在一起。这个阶段通常是一个漫长的过程，至少会在12个月，甚至往往在更长的时间。
QA阶段
QA（质量保证）或者测试阶段往往会放在开发的最后阶段里，大概会在游戏安排到工厂产出前的3～4个月内。在这个阶段中，游戏会经过QA部门的测试，测试出各种Bug、出错情况、不足和兼容性问题。
最终零售版阶段
最终零售版阶段是指烧录出零售版的光盘并送到工厂进行大批量拷贝的阶段。在平台游戏里还有着“提交到硬件厂商”的流程，这需要对很多细节关注，并且有可能为了满足他们的许可指南而做很多小修小改。每一个硬件制造商都有着自己严格的测试指南，每一款产品必须满足或者超出他们对功能和玩法独有的QA需求才行。
换到平台机或者PC上的在线游戏来说，团队即使到了最终零售版阶段还需要继续一起工作，不断去修正各种Bug，并且为了让游戏一直处于零售架上而不断对发布版本进行补丁修正。
视频游戏开发流程模型

对一个视频游戏的开发来说存在着两种基础模型。一种是标准模型，一种是提前负载风险管理模型（Forward  loading risk management model）。这两种模型的优点和缺点我们都会在第8章详细讨论。不过为了对这两个模型的运作原理和实际应用提供一定的知识背景，我在这里也稍微谈一下标准模型。
标准开发模型展现的是过去几年在视频游戏开发中采用的常见方法。通过遵循这个模型，制作人能一定程度降低项目的风险和成本。
由于这是一个常见的方法，所以这个模型也广泛被大家接受，并且出了很多种替代方案。不过Mark Cerny在2002年的DICE会议上提出了一个新模型。这种模型避开了标准模型的不足，把精力重点放在游戏的乐趣定义上。通过不断去管理风险，制作人能确保项目里的资金投入能得到有效管理。
总结

如今你已经有机会掀开制作人的面纱了，如今我们去到下一章来看看每一种角色的专精领域，看看他们在不同的公司、项目和专长领域里各有着什么不同。