下载掌阅APP，畅读海量书库
立即打开
目前国内大部分开发团队以手机游戏开发为主，少部分开发团队会进行PC、主机、独立游戏开发，从事3A游戏项目的开发团队更是寥寥无几。部分读者可能会有疑问，国内游戏开发这么多年，技术早已有了积累，就手游的开发实力来说远超3A大厂，为什么在研3A游戏项目寥寥无几？关于这个问题，我们首先需要明白什么是3A游戏。3A游戏是指高成本、高体量、高品质的游戏。下面笔者会根据“三高”特性进行粗略解释。
（1）开发成本高，利润率低。这里的成本不但指资金成本，还指时间成本与人力成本。目前国内市场的手游利润率远高于3A游戏利润率，在3A游戏上线市场未知的情况下，3A游戏开发需要大量资源、动辄三五年起步的开发周期、大量的顶级开发人才，国内没有几家公司敢于付出如此高的成本来进行这样的挑战。
（2）市场范围覆盖规模小。大多数公司会选择让项目尽可能多地扩展用户群体。根据第52次《中国互联网络发展状况统计报告》的数据，截至2023年6月，我国网民规模为10.79亿人，其中使用手机上网的比例高达99.8%，使用台式计算机、笔记本电脑、电视和平板上网的比例分别为34.4%、32.4%、26.8%和28.6%。由此可见，手机用户数远高于PC（包括台式计算机、笔记本电脑）及主机用户数。实际上支持3A游戏的PC平台更是不到50%。这说明国内手机游戏的市场远大于3A游戏的市场。
（3）缺少相应的流程与规范。流程与规范一直是国内游戏公司比较缺失的地方，哪怕是头部的几家公司，在这一领域做得也不尽如人意。即使是老牌游戏大厂网易，早期也经历了跟着国内3A外包公司学习游戏资源制作、开发流程的阶段。对于游戏的每个阶段，需要完成哪些内容，做好哪些准备，目前国内大部分游戏公司及游戏开发者虽然对游戏流程都较为了解，但是却因为团队观念、项目进度、团队能力等各式各样的困难而难以落地。所以这些内容也是本书重点解释的一部分。
以上就是国内3A游戏项目数量稀少的主要原因，下面再来说说常见的几个国内游戏开发失败现象。
首先，最常见的是为了项目进度而忽视流程与规范，管理层向下层层施压，进行版本突击，让项目早点上线回收成本。这间接导致行业内出现了加班严重的情况。各个岗位对游戏开发各阶段的概念模糊不清，对项目开发流程一知半解，容易分不清主次，出于流程的存在而展开对应流程，从而导致人力等资源的浪费。
其次，在项目对精品化的要求越来越高的当下，游戏开发还讲究团队能力。我们在各个公开平台看到的成功项目的演讲人，他们代表的是团队的共同努力。过去一些大型公司经常重金挖取某些3A大厂的管理人员到他们公司就职，但是这些人却很少再取得什么大成绩。原因之一是水土不服，原因之二是缺少了背后整体团队的支撑，创造力自然明显下滑。我们需要深刻理解团队的重要性。在一个优秀的团队中，我们只是环节中的一小部分，不论缺了谁，都会有其他人补上，最多不过是换一个侧重方向。但是团队的整体实力也是由员工的能力聚合而成的，优秀的团队意味着拥有大量优秀人才。
前面说完了国内的开发团队背景，下面就来正式聊一聊比较常见的开发流程框架，每家公司略有不同，但核心内容基本相同。项目开发大体上分为三个流程阶段，分别为预研、量产、上线，它们的简要结构如下页图所示。
在规模较大的游戏开发公司，项目的成立往往是由制作人或者某成功项目的主策划提出立项思路或者想法，通过层层审核最后立项；或者是一些工作室老板直接下令进行某个游戏项目的开发。这样，便完成了项目开发最开始的流程——立项。
完成立项后，通常要进行Demo的前期准备与制作（Pre-demo），用来验证核心技术与游戏方向，之后进入Demo阶段，进行正式的Demo制作。目前国内的一些公司领导急于求成，未经技术验证与玩法验证，反而直接进行Demo制作，无形之中增加了大量的成本与失败的概率。在Demo阶段，开发团队将对各个功能进行相应实现，完成之后便可进入下一阶段。
在量产阶段，开发团队主要进行美术铺量效果优化、性能优化、核心玩法完善、主支线任务确定及打磨等工作。在量产到一定程度的情况下，会有几个大的事件，比如进行Alpha测试及Beta测试。部分项目还会进行更多测试，或在早期进行一些更小规模的封闭测试。每一次测试之前都会进行相应的封版，不再增加新内容，只专心于修复Bug。
经过两次以上的测试后进入上线阶段，最终将进行封版，准备上线。此时，国内流程与国际3A流程有所不同，对于国内流程，不同的项目组会视自身完成情况进行测试，而国际3A流程会在量产阶段基本完成后再进行游戏测试。
之后项目便进入了上线运营期，在这个项目越来越精品化的时代，上线运营期已经由早期的一年半载发展到现在的长期运营阶段。本章主要为读者讲解开发阶段的各个流程细节，运营阶段的内容不再进一步深入。
目前行业中并没有十分标准的统一流程，各个公司皆有所差异，因此本书仅把必要流程提取出来进行讲解。下面针对三大阶段，从岗位人力布置到大体工作内容进行逐一讲解。由于国内的版号机制，本书将把精力集中在整体的开发流程上，因此会屏蔽所有政策相关的影响，后者的相关内容不在本书讨论范围之内。
下面两张图为某3A项目大体上的人数变化趋势。
1.预研阶段
预研阶段可以细分为三个小阶段：立项、Pre-demo（又称Demo准备阶段，国内叫法并不统一，甚至很多公司并不存在这一阶段）、Demo阶段。
在 立项阶段 ，需要确定以下几个方面的事情。
（1）定义游戏品类。可以使用前文提到的以元素划分的方法对游戏品类进行比较详细的定义，如多人魂类大世界动作冒险游戏、卡通大世界模拟经营游戏等。
（2）游戏玩法及设定，即明确游戏的核心玩法与基础设定。举个简单的例子，在《超级马力欧兄弟》（早年翻译为“超级马里奥”）中，开发团队有意突出“跳跃”这一核心玩法，后续所有功能都是围绕着该核心玩法扩展的。
（3）用户市场的需求分析。这是为了事先明确目标用户市场及其所能承载的用户规模、未来市场对该项目的可能的需求。
这便是立项阶段的核心三大点。有审核机制的大型游戏开发公司会对产品进行立项评估，根据市场情况提出相应问题与要求，并评估整体的开发实力，判断该产品提出方是否有能力完成此产品。对于没有审核机制的中小型游戏开发公司，高管可以直接决定是否进入下一阶段，有些高管并不在意整套游戏的开发流程，因此每个阶段可能都处于一个混乱的状态。
在 Demo准备阶段 ，需要确定的事情较多，可以从以下五个方面进行详细描述。
（1）确定游戏整体方向。立项阶段对游戏品类、游戏玩法及设定进行了大体框架的设计，Demo准备阶段便需要确定游戏整体方向，以及进一步敲定相关细节。仍以《超级马力欧兄弟》为例，开发团队确定核心玩法是“跳跃”之后，设计了一系列有关跳跃的玩法框架：如何使用跳跃击杀敌人，如何使用跳跃获取道具，如何使用跳跃通过关卡等。这一系列细化的玩法框架设计便是本阶段需要进行的工作。
（2）细化游戏背景设定，包含世界观、游戏故事、原画及风格设计。在确定了游戏整体方向后，需要细化游戏背景设定。部分游戏的核心玩法可能与世界观紧密相关，因此游戏背景设定应该在确定了游戏整体方向之后。由于开发团队、项目的受重视程度不同，对游戏背景设定的细化程度也有很大区别。对于人手高度紧缺的开发团队，细化游戏背景设定是一项负载很大的工作，投入过多会影响整体项目的开发进度。对于这类情况，建议此时只保留最低限度的游戏背景设定，只需要满足功能开发即可，切勿强求。对于人力充沛的重点开发团队，可以根据情况在游戏背景设定、故事编排、原画参考等方面加大投入，为后续开发提供更完善且相对准确的参考依据。
（3）确认游戏可游玩周期。对于单机游戏来说，这一点代表着开发团队要确定开发量以使玩家安排游戏规划。这里面会涉及相关开发量的思考，即需要多少内容才能保证玩家足够的游戏时长。有的游戏把不同结局设计到了多周目内，这种方法相对省力且能大幅度增加游戏可游玩周期，虽然笔者本人并不喜欢这种方法，但不可否认它确实是个偷懒的好方法。除了前面所说的内容，对于网络游戏来说，必然希望将玩家的游戏可游玩周期无限拉长。在Demo准备阶段，开发者不仅需要对当前版本内容进行规划，还需要对这个项目的后续内容进行相应的简单设计与铺垫。此外，一些多人对抗类游戏，如《英雄联盟》《守望先锋》等，游戏可游玩周期更多代表的是一局游戏总时长的规划。开发者可以通过总体的游戏可游玩周期结合游戏玩法大体规划出需要多少内容，并根据相应内容判断初步的工作量。
（4）核心技术点预研测试及其他技术点评估规划。在确认玩法与内容之后，还需要对使用到的核心技术点及系统进行相应的预研，这将直接决定项目开发周期。那么什么才可以称为核心技术点呢？简单来说，核心技术点就是会影响到游戏的核心玩法及产品能否最终制作完成的有技术难度的技术点，如潜行游戏中的潜行功能，大世界游戏中的程序化生产等。其他的诸如画面表现、特殊效果等都不属于核心技术点。与此同时，还需要对项目将要使用的比较重要的系统进行开发周期的评估，并进行相应的排期规划。
（5）整个项目周期的里程碑规划。项目的重要里程碑即Demo版本完成时间、Alpha测试版本时间、Beta版本测试时间等。各个项目可以根据自身项目情况设定更详细的里程碑。有的团队还会使用scrum系统做里程碑规划，scrum系统是敏捷开发中常用的工具。例如，三个星期做一个sprint（冲刺），三个sprint为一个里程碑，三个里程碑为一个大阶段，每个大阶段结束前的三个星期进行封版以保证项目质量稳定。当然这只是一个简单例子，读者可以在自己研究完项目管理后进行更详细的规划调整。需要补充一点，项目周期管理一定要切合自身团队的能力，切不可急功近利，超出团队能力，否则将导致项目周期大量延期重排，这在影响团队士气的同时，也会动摇团队凝聚力。
在完成上述五个方面的工作后，有严格审核机制的公司还会对Demo准备阶段进行一次审核。在审核通过后才允许进入Demo阶段，进行正式的Demo开发。
Demo阶段又称为第一个可玩的项目的演示（First Playable Demo）阶段。在Demo阶段，需要重点完成以下六项工作。
（1）确定游戏美术风格。通过前面的内容可知，Demo准备阶段已经完成了游戏背景设定的细化，Demo阶段则需要确定具体的游戏美术风格。游戏美术风格是游戏体验的一部分，玩家进入游戏的第一体验便是画面带来的直观感受。从开发角度看，游戏美术风格直接决定了后续使用的开发流程与资源开发规范，因此，确定游戏美术风格是一件不可马虎的事情。如果在游戏生产阶段要对整体的游戏美术风格进行修改，那么之前制作的内容将被大幅度抛弃，产生巨大的成本浪费。所以一旦确定了游戏美术风格，应尽量避免大幅度的修改。
例如，假设现在要做一个迪士尼风格的项目，经过了一年的开发，该项目成功走过预研阶段进入量产阶段。但是此时首席游戏图形设计师（又称主美）离职，新加入的主美认为原有的迪士尼风格没有市场，要换成卡通风格。这时候整个项目就需要进行大换血，之前的大部分资源需要重新制作。为了减少这类事情的发生，确定游戏美术风格时，需要牢记立项时确定的市场需求分析中的美术部分，在后续目标风格动摇时提供有力依据。
（2）确定标杆，即确定游戏美术风格之后，需要完成角色、场景、特效、UI动作等的制作，在引擎中确认最终效果。角色的整体制作流程一般会经过下面几个步骤：原画设计、角色中低模制作、角色高模雕刻、拓扑、贴图制作、蒙皮绑定、动作制作、进入引擎。根据游戏美术风格的不同，流程会有一些细微的调整，有些风格类型的游戏不需要高模，如Lowplay类型的游戏。2D游戏甚至不需要模型，只需要绘制角色的各类状态序列图。场景的整体制作流程大为不同，大体上包括原画风格设计、Layout、Blockout、模型资产制作、效果优化几个大流程。如果要更加细化，可以将灯光着色流程也加到角色和场景的生产流程之中，其他的流程此处不做展开。
这项工作的目的一是确定风格能在引擎中复现，二是为后续的资源生产提供规范模板。如果标杆未达到预期效果，需要考虑是否进行风格调整或者继续攻坚，以避免后期因为标杆效果不达标导致产品缺少市场竞争力。
（3）实现主要功能代码。实现游戏玩法等主要功能是开发团队在Demo阶段需要完成的另一件大事，其中包括核心游戏逻辑、基础UI功能、基础音效、基础联网功能等。这项工作与前两个美术类的工作往往同步进行。基础功能逻辑可使用临时资源进行替代验证，整体流程也就是常说的Blockout，会在后面的内容中进行详细介绍。
对于不同规模级别的项目，这项工作对整套代码架构的设计要求不同。项目规模越大，对整套代码框架的设计要求也就越高。代码的可读性、封装性、可扩展性都会对后期开发产生深远影响，除非这是个用完即弃的Demo。这里补充一个容易被忽略的点，就是对整套着色器代码进行的框架设计。与逻辑代码相比，着色器代码的规模较小，而且语法又比较独立，很容易让人误以为整套着色器代码不需要进行框架设计，但是这样的话往往会给项目后期埋下隐患。
（4）核心技术点合入Demo中并进行调整。在实现主要功能代码的过程中，需要同时将上一阶段实现的核心技术点进行合入验证，对于Demo来说这是十分重要的一点。但是此时往往会出现几种情况。第一种，核心技术点已经被顺利攻克，并且合入Demo中进行相应测试并通过。这种情况是最顺利也是最理想的状态，当然发生概率较小。第二种，核心技术点已经被攻克，但是合入Demo中进行验证时出现了Bug。这种情况下需要安排相关人员进行对应Bug的修复，属于比较常见的情况。第三种，核心技术点已经被攻克，但是在合入Demo中进行验证时出现了无法接近的Bug或者不适用的状况，此时项目组需要做比较重要的决定，考虑是否有其他技术方案，是否可以解决，否则需要考虑对游戏玩法进行修改。这也是为什么核心技术点需要在Demo准备阶段就被攻克，越早对核心技术点进行实现验证，项目点容错率就越高。第四种，如果未攻克核心技术点，需要准备备用的游戏玩法和技术方案，并评估是否有继续研究、攻克的必要。
（5）实现核心游戏体验。核心游戏体验大体上分为两个方面：游戏的玩法乐趣、游戏整体的画面氛围。两者看似关系不大，实际上却密不可分。一个关卡的实现流程大体上可以分为Layout、Blockout、脚本功能实现、场景美术细化几个阶段。对于核心游戏体验的验证玩法主要集中在Blockout阶段，在后续章节中会进行详细讲解。游戏整体的画面氛围则由Blockout与场景美术细化两大阶段决定。Blockout在决定核心游戏体验的同时还决定了游戏整体的画面的剪影构成，场景美术细化则决定了最终的整体氛围。
（6）规划生产阶段。在完成以上工作之后，项目组需要根据规划的整体游戏开发内容量进行美术资源及系统工作的排期。根据Demo的整体完成进度及周期进行相应里程碑的调整。如果Demo制作周期大幅度超过之前计划的Demo里程碑，那么后续整体开发计划都需要进行相应风险的评估。如果Demo制作周期大幅度缩短，则说明之前的评估有优化的空间，同时项目方需要修订出更加详细的资源生产与系统开发排期。
上面六项工作从总的方面说明了Demo阶段需要做什么，那么现在换一个角度，从各个岗位大组的角度来说明Demo阶段需要做什么。前面两个阶段涉及的岗位太少，这里不再补充。
（1）核心组。核心组由制作人、主美、主程、主策等核心成员组成，它的工作有：评估技术点及工作量、规划总体资源制作工作量、预研期结束完成内容清单、人力调动、评估是否结束预研、完成预研阶段后进行生产阶段各节点规划。
（2）技术组。技术组是由主程主导的技术团队，包含前端程序、后端程序、技术美术，有的公司会把技术美术归到美术组，各公司会根据自身情况稍做调整。技术组的工作有：对核心技术点进行研究并将其合入Demo、完成主要功能代码、搭建基础服务器代码、实现相关渲染效果、开发资源管线工具、搭建基础工作环境、Demo阶段性能消耗控制等。
（3）美术组。美术组是由主美带领的美术团队，包含原画设计、角色设计、场景设计、特效、动作设计等各个美术环节的美术岗位。其在Demo阶段的工作有：定制美术标杆（角色、场景、特效、UI等）、定制各流程美术生产规范、提出所需的技术支持点。
（4）策划组。策划组是以主策为首的策划团队，包含数值、关卡、系统等各类策划岗位。它的主要工作有：核心体验设计成型、设计主线任务标杆、编写任务文本、提出体验功能需求等。
（5）测试组。Demo阶段的测试成员比较少，很多中小项目组在此阶段甚至不存在测试相关岗位，而是由各组成员交叉或自行测试相应内容并验收。测试组主要测试与核心功能相关的游戏玩法体验，同时对技术组、美术组实现的功能场景进行体验验证。
其他岗位如负责产品风险、周期、品质把控的项目经理（Project Manager, PM）团队，提供各类音效制作的音效团队等，此处不再展开详细描述。
2.量产阶段
量产阶段又称为生产阶段，顾名思义，就是在Demo阶段完成各类标杆及核心玩法体验后进行资源量产的阶段。目前行业内对该阶段没有统一的细分标准，但是它大体上分为三个阶段，这里解释几种大型公司（如3A大厂）的细分标准。 第一种为Pre-alpha、Alpha、Beta， 划分依据是Alpha测试版本和Beta测试版本。 第二种为玩法锁定阶段、生产阶段一、生产阶段二。 这种细分标准依据完成进度来划分，根据发行计划进行A、B测试的规划，倒推出各生产阶段，当然实际情况可能产生很大误差。 第三种为量产准备阶段、量产阶段一、量产阶段二。 这种细分标准的划分依据与前者类似。在项目开发过程中，总会有人在各个阶段产生一些想法并想在各个阶段将它们实现，而不考虑会对项目整体的开发规划和资产产生影响，特别是在生产阶段。应该尽可能地避免这类事情的发生，如果一定要添加一些东西，需要谨慎考虑其对所有相关环节的影响。下面笔者以第一种细分标准为例讲解各阶段工作内容的细节。
Pre-alpha 为进入生产环境后的第一个阶段。在此阶段初期，因为刚完成Demo阶段，有小部分厂商会趁着阶段交替的间隙开启一个超小范围的玩家测试以得到一部分玩家反馈，用于后续迭代。此阶段大体包括如下工作。
（1）调整核心玩法。经过Demo阶段充分的核心玩法测试后，核心玩法可能会暴露一些之前未能预料的问题，需要在此阶段进行调整。此阶段是能对核心玩法进行修改的最后一个阶段，后续阶段只能对核心玩法进行小修补。在Demo阶段进行的Blockout测试主要就是通过充分测试来验证核心玩法，保证核心玩法在后续阶段中不会被修改。如果后续阶段确实需要修改核心玩法，那么说明此前进行的Blockout测试工作并未到位，且核心玩法的改动会产生巨大的成本浪费，无论哪种情况都需要尽量避免在后续流程修改核心玩法。
（2）大体剧情故事线成型。Demo阶段的重点在于验证游戏的核心玩法与体验。进入Pre-alpha阶段后，其中一项重要的工作就是将游戏剧情融入游戏玩法体验之中，并将Demo准备阶段准备的游戏世界观在剧情中慢慢展开。游戏中常见的过场动画与非玩家角色（Non-Player Character, NPC）的对话，都是此阶段需要大致完成的内容。但是像一些轻剧情，甚至无剧情的游戏类型，如对抗类的MOBA游戏，则可省略该工作。
（3）确定主线任务流程，锁定支线任务数量，确认整体游戏内容。结合剧情确定主线任务的整体流程，确定任务难度，同时锁定支线任务数目，作为整体项目工作量评估的依据。无剧情则继续跳过剧情部分。以MOBA游戏为例，主线任务为摧毁对方玩家的基地，支线任务为夺取场景中存在的各类资源，都是本工作的内容。至于游戏战斗场景之外的任务，如玩家等级任务、每日任务等，则被归纳为游戏运营类任务，项目组可在后续阶段增加，不需要在本阶段完成。
（4）实现次要玩法及功能。这项工作主要是为了丰富游戏玩法，增加游戏细节与提升游戏趣味度。例如，实现不重要的NPC的AI、一些小游戏、一些额外的特殊渲染效果等，如《勇者斗恶龙》中到处乱跑的小动物、随处移动的NPC，以及各类辅助开发的工具。
（5）确定美术工作量。项目组可以根据主线剧情及支线剧情的数量来确定整体的美术工作量。根据涉及的场景个数，结合场景细化需要的资源量和场景实现全流程的周期评估出整体的美术工作量，并详细列出。对于角色，除了评估人物建模的工作量，还需要评估角色的动作、技能特效，以及过场动画、额外展示内容等的工作量。
（6）Pre-alpha阶段美术资产制作规划。根据整体任务及剧情优先度安排对应的场景和角色进行相应的美术资产排期与制作。
接着对前面提到的五个岗位大组做一次梳理。
（1）核心组。根据宣发节点进行项目整体节点的规划及调整，根据各组人力紧缺程度进行人力调度。如果有Demo外部测试，则根据反馈结果判断是否进行相应调整等。
（2）技术组。调整引擎功能、渲染、调整相应工具、优化基础性能、完善基础服务器代码，进行新技术点的开发与测试、相关文档的梳理与补充。
（3）美术组。对总体资源制作进行分工，制作人物、场景等Demo准备阶段相关的美术内容，对引擎功能与技术点提出使用反馈。
（4）策划组。打磨核心体验、确定主线任务流程、规划支线任务、开发次要玩法、编写任务文本、提供相关工具使用反馈。
（5）测试组。工作内容与Demo阶段差别不大，工作量依然较小。
进入 Alpha阶段 意味着正式开始大规模量产。此阶段的主要工作如下。
（1）打磨核心玩法、次要玩法。此时已经不再允许对核心玩法进行更改，但是需要调整细节，继续优化核心玩法带给玩家的游戏体验，如数值平衡、操作难度等。次要玩法是为了丰富主体游戏性的，同样需要持续打磨。
（2）优化与调整主线任务，确认支线任务流程内容。此时的主线任务大体完成，需要进行相关流程内容的优化与调整，确认支线任务流程内容，开始制作，并且根据任务线对剧情进行小幅度调整。
（3）Alpha阶段美术资源制作。需要注意的是，上个阶段中规划与制作的场景内容只是完成大体的Blockout测试，在Alpha阶段需要细化，以及继续开发后续场景内容。其他角色、UI特效等部分会在此阶段继续细化。
（4）各类玩法及功能细化打磨。Alpha阶段需要对各类玩法及功能进行细节打磨，提升游戏体验。Alpha阶段需要加大测试岗位的投入，大幅度增加各类体验测试，增加每日测试内容规划。
（5）确定最终上线日期。之前的步骤中往往只是对整体上线进行一个大概范围的估算与预测。Alpha阶段需要结合现在的进度决定最终上线日期，并考虑是否对各个节点进行调整。
Alpha阶段各个岗位大组的具体工作如下。
（1）核心组。评估当前进度，进行项目整体节点的规划及调整。根据实际工作情况调度各组人力。如果有外部测试计划，则根据反馈结果判断是否进行相应调整等。决定上线日期，规划上线内容工作量。
（2）技术组。根据测试及其他组成员的反馈调整引擎功能、渲染，调整相应工具，完善基础服务器代码，开发资产制作加速工具。
（3）美术组。对资源制作进行分工，制作人物、场景、灯光等Alpha阶段相关的美术内容，对引擎功能与技术点提出使用反馈。
（4）策划组。根据反馈调整游戏细节，打磨主线任务、支线任务、游戏体验及其他功能。
（5）测试组。进行主线/支线内容测试，进行核心玩法、次要玩法测试，进行开发相关技术功能点测试。
在 Beta阶段 ，游戏玩法及主线/支线内容测试已基本完成，主要进行美术及体验优化。
（1）锁定核心玩法，也不再允许修改细节。
（2）任务微调。此阶段只允许对任务进行小幅度的微调，不再允许大改动。
（3）完成美术打磨。此阶段需要完成所有美术优化调整内容，为封版做准备。
（4）锁定地形编辑，不再允许修改路线等，只允许对美术资源进行优化、替换。
（5）项目性能优化。此为本阶段的一项重要工作，需要对整体性能进行大量优化，进行性能分级。保证在目标机型上流畅运行，且发热可控。
Beta阶段各个岗位大组的具体工作如下。
（1）核心组。评估当前进度，进行项目整体节点的规划及调整。根据实际工作情况调度各组人力。根据外部测试反馈结果判断是否进行相应调整等，进行封版内容校对。
（2）技术组。重点修复各类Bug，进行项目性能优化，不再进行新功能开发。
（3）美术组。进行角色、场景、灯光等美术内容的制作及效果优化。
（4）策划组。根据测试反馈调整整体游戏数值、打磨游戏AI战斗细节等。
（5）测试组。进行全游戏内容流程测试，反馈各类Bug，进行项目性能测试，提供性能报告。
3.上线阶段
此阶段为冲刺阶段，也可以称为收尾阶段，以项目优化为主。大体上可以细分为封版、提审、上线三个阶段。但是如果不是版本进度过于匆忙，基本上完成封版之后，在提审阶段与上线阶段，都没有太多的开发部门要关注的点，此时主要是发行部门在工作，所以这里主要讲解封版阶段的内容。封版是指不进行新内容制作，包括美术资源。
（1）修复美术、技术Bug。
（2）性能优化。对性能不达标的部分进行技术点和美术资源的优化。
（3）规划上线后的更新内容。规划上线后第一个更新版本的内容，并且抽调部分人力在Bug修复完成后进行相应内容制作。
（4）规划收尾阶段优先级。评估哪些Bug及问题需要被列为高优先级，进行优先级排序。对于影响全项目组工作的Bug，需要当天解决，有的项目组还会对责任人进行问责。
上线阶段的各个岗位大组的具体工作如下。
（1）核心组。对需要修改的内容进行审核，把握项目上线前风险，并评估修改的性价比。规划后续更新内容及调度相应人力。
（2）技术组。专注于修复各类Bug，优化项目性能，不再进行新功能开发。
（3）美术组。修复各类美术相关Bug，并且进行后续更新的前置生产。
（4）策划组。根据测试反馈调整整体游戏数值，打磨游戏战斗、AI等。
（5）测试组。进行全流程测试，反馈Bug，提供测试性能数据。
以上便是封版阶段要进行的相关工作，一般在提交最终审核版本时，往往存在众多的Bug，这是常见现象。只要不是致命性Bug，提交最终审核版本的计划依然不能被打乱，否则会影响最终上线时间。提交最终审核版本后，往往会继续修复Bug，在上线后的热更新中发布修复内容。
至此，讲完了游戏从立项到上线的整个开发流程，场景部分的细节会在后续章节中进行详细讲解。读完本部分内容，想必读者对游戏的整个开发流程有了自己的理解，希望读者在工作中可以结合本书的后续内容进行思考与扩展，并将知识与技能应用到自己的项目中，规范项目整体的开发流程。