【摘】常规游戏项目开发流程

【摘】新手必读：常规游戏项目开发流程

---

常规游戏指一般的具备网络服务器端的客户端游戏、页游、手游。

开发这类游戏，一般会分以下四个阶段：
筹备阶段：筹建团队，确定项目的基本方向。
原型阶段：实现一个游戏原型，发布Alpha测试版，以验证和调整预定的方向。
发布阶段：发布游戏的Beta测试版本，供内部封闭测试，做上线前最后的准备。
迭代阶段：完成对Beta测试版的修改，上线后按迭代周期，持续开发和调优产品。

在这些阶段中，我们都必须注意开发流程中的一些重要因数：
角色：定义一些角色，规定其工作权力和责任，避免过度讨论或盲进。
交付物件标准：每个角色都必须按照一定标准来交付工作成果，避免在长长的工作链条中出现很多误差。
工作方法细节：由于游戏开发是一个涉及多个专业的复杂过程，所以这个过程中有一些工作方法，是必须要遵守的，否则将会严重降低开发效率。

作为一个完整的游戏开发团队（不包含运营团队），整体的结构应该大致如下：

筹备阶段

角色定义

• 投资人：根据市场状况和投资预期，提出商业目标和项目邀约，和制作人讨论并审核确定《产品方向》，制作《投资计划》，按计划安排资金投放，并承担投资后果。
• 制作人：根据投资人的商业目标，整理和组织市场调查数据和《竞品资料》，制订《产品方向》，根据《投资计划》组建核心团队。在某些项目里，投资人和制作人是同一个人。
• 核心团队：一般由制作人和主程，主策，主美组成，有些时候还包括项目经理。在某项项目里，制作人可能由核心团队里的任何一个人兼任。
• 项目经理：负责制订工作计划，监督进度，安排各种资源，初期可能会有很多秘书工作需要担任。在某些项目里，项目经理可能由核心团队中任何一个人兼任。

交付物件

• 《投资计划》：由时间、金额、项目进度检查标准，这三列组成的一个表格。需要附带上修改日志和完成记录。
• 《产品方向》：一个具体的文档，记录了产品概念所依据的市场状况（数据）、竞品情况（数据）；也记录了项目产品的基本情况：游戏的题材、游戏的玩法、游戏收费方法的基本概念，以及市场推广、运营的基本思路。
• 《竞品资料》：罗列所有主要竞争对手产品的情况，包括市场数据，开发方案（如能搜集到），评测资料，用户反馈等。需要由制作人持续更新关注，随时整理添加。

重点注意

产品概念讨论方法

• 针对用户特性：游戏产品形态非常丰富，细节也很多，所以在讨论任何设计的时候，都必须按照既定的用户画像来做标准判断，避免大而全或者钻牛角尖。在各种“调查报告”无效的情况下，邀请几个目标用户作直接沟通，往往能获得最真实、最有效的情报，不用过于担心“代表性”不够，因为共性往往是比较明确的部分。
• 针对竞品：在用户、市场情报不够充分的时候，竞争对手能提供最直接的产品信息。通过分析竞争对手的产品，特别是跟踪竞争产品的变化，就能猜出用户和市场的反馈。就算本产品的竞争对手不多，方向相似度不高，只要是目标用户群体接近，也可以通过竞争产品的用户感受来了解用户心理。切记闭门造车，不接触市场风潮。
• 不应该深入的部分：在筹备阶段，容易陷入头脑风暴，所以我们不应该深入讨论产品的开发过程、开发工具、开发人员。对于产品的细节，也不宜过细，但应该找出一些简单明确的概念来代替，如“经过XX修改的竞品A”这样就很好。

团队缺人对策

• 招聘渠道：首选熟人朋友圈，其次毕业生和培训机构，最后是网上投递简历。由于现在的培训机构一般都需要签就业协议，所以对于创业团队，小型公司来说可以作为一个比较稳定的人员来源。大型公司最好就是各种高校的招聘会了。猎头也可以考虑，但是对候选人需要仔细甄别。
• 选择简单的工作方法：缺人的情况下，往往是缺牛人。所以一定要选择简单的工作方法，各种高大上的流程，一定要在有IT技术保障下实施，不要直接推行而不顾实际情况，这些可能有问题的方法包括：定期汇报制度、全自动化项目管理、没有足够储备的技术开发方案等等。
• 培训准备：根据初期可能到职的人员，进行基础能力的培训，比如SVN的使用，BUG跟踪系统的使用，基础的开发技术、美术、策划文档标准。这些培训都是需要多次进行，所以应该先准备好培训资料，避免新成员入职措手不及。
• 会议时间控制：筹备阶段大概有一半的时间是在做沟通，因此会议时间需要特别控制。要严格遵守议题议程。如果有遗留问题，应该有专人搜集整理并且跟进，而不是在会上去解决。因为会上提的方案，往往没有自己在认真思考的环境更完善。另外就是避免“挨个报告”那种没有明确议题的会议。这种沟通了解放到其他时间，少部分人沟通会更清楚。
• 招聘期限：根据经验，核心团队具备的情况下，要组建到项目正式启动的团队，基本需要3个月左右。假如接近3个月都没有什么进展，应该和投资人反映，并研究解决方法。一般最简单的就是提高工资和雇佣猎头。

原型(Alpha)阶段

角色定义

• 主策：提出产品原型的概念，交付《项目总体设计》，并协助原型开发，突出产品特点。
• 主程：选择技术方案，定义美术、策划资源的技术标准。搭建开发环境，编写产品原型。在客户端开发方面，和美术同事合作，调整原型效果以达到测试的目的。
• 主美：选择美术风格，在策划和技术的共同讨论下，确定各美术组件的基本技术标准，如大小、尺寸、容量，并且确定美术资源的格式。
• 项目经理：有些团队由制作人、或者主策兼任。此阶段在明确游戏原型后，产品、技术、美术人员都会需要各自开发一些内容，然后再整合到一起。因此项目经理应该负责组织大家共享这些信息，一起讨论和评审各阶段产品，确保各环节不脱节。

交付物件

• 《项目总体设计》：规定了游戏的题材、玩法、收费模式。确定游戏的重点乐趣和表现特点。列出游戏的长期开发计划所需要的系统、关卡、内容纲要。作为后续策划工作的总需求列表。
• 《美术风格指导》：以实例原画图来规定整体美术风格。
• 《美术资源格式标准》：对游戏原型的美术资源格式，做出标准规定，包括美术文件的格式、尺寸、精度标准、命名、SVN路径规则等。
• 开发环境：SVN服务器地址、BUG跟踪系统地址、IDE选择产品和版本、开发和测试的内网服务器、演示用外网服务器。
• 《技术方案选型方案》：开发游戏所用的客户端和服务器端引擎、框架版本；程序的基本模块代码结构；项目文件目录规范；测试和CI方案；技术难点的预设解决方案。
• 可运行的原型产品（DEMO）：突出表现游戏核心玩法和美术风格的一个程序，可以是一个单独的游戏关卡。

重点注意

原型开发阶段，主要目的是验证产品的基本面问题：题材和玩法的融合是否合适，美术风格和技术实现是否能达到策划的初始目标，有没有一些难以解决的基本障碍。需要特别注意的，开发原型所需要耗费的资源制作和逻辑编写时间，因为这反应了后期游戏持续更新所需要消耗的成本。
另外，由于游戏原型的制作，也带出了个制作环节的沟通问题，所以必须注意从一开始就积累和订立各工序的交付标准，如策划案应该包含图量表、测试方案；需要预先沟通美术草图并签名；美术资源格式需要确定；游戏原型的测试环境设置。这些标准和接口往往会变动，但是需要预先明确这些接口流程。

发布(Beta)阶段

角色定义

• 技术开发团队：
  • 客户端开发：开发和优化客户端代码和单元测试用例、文档，完善客户端程序打包、发布的CI流程。
  • 服务器端开发：开发服务器端代码和单元测试用例、文档，维护项目数据库，安装部署测试环境。
  • 测试开发：维护和管理CI系统，监督运行单元测试用例，开发专项测试如性能测试、自动化冒烟测试。

交付物件

• 《策划需求文档》：重点说明要达到的产品目标，使用的主要设计手段
• 《策划案》：产品使用流程图，GUI草图，须配置的游戏数据项目，美术图量表以及风格参考
• 《草图》：美术风格参考，UI构图
• 《技术设计方案》：代码模块命名以及职责，代码结构模式及关系，重点技术问题解决方法
• 《美术资源格式》：文件名和路径规则、文件格式、精度、尺寸或其他更细节内容
• 《游戏数据格式》：库名、表名、字段解析、字段内容结构
• 《Bug报告单》：策划案ID、重现步骤、现象

重点注意

此阶段是建立稳定完整的版本开发流程最重要的阶段，关键点是各交付件标准的严格遵守和流程监控。
项目经理须组织对于流程、标准的讨论和确定，并且监督这些规定的执行。由于每个游戏都不一样，所以这些流程和标准都会有所差异，项目经理要随时应对不同的策划案，即时组织大家建立流程标准。另外需要准备发布的工作，包括宣传资料，测试环境，运维工具等工作，也需要花时间准备。
在发布前至少安排一周时间来做发布前的准备，和运营、运维、客服人员做好沟通和交接准备。

迭代阶段

角色定义

• 开发团队：依照迭代标准开发迭代所需内容。
• 运维团队：
  • 运营人员：负责推广、发行工作，提供技术资料给运维人员做产品部署，关注产品数据和运营情况。反馈意见给开发团队。
  • 客服人员：辅助游戏推广，提供玩家咨询、故障报告、投诉处理、事故安抚等工作，需要运营人员和开发团队进行持续的信息共享。
  • 运维人员：提供游戏的部署和监控工作，开发管理运维部署工具。准备硬件资源和运行环境。有些运维工作由开发团队中的服务器端程序员一起分担。
  • 运营开发人员：开发“GM系统”给客服人员使用；开发“数据统计报表”和“活动系统”、“官网”等系统给运营人员使用；某些游戏团队由服务器端程序员兼任。

交付物件

• 《版本发布计划》：每个版本开始开发前，都需要编写此计划，列明本版本内需要开发的内容，预计时间，以及开发设计人员名单。此计划需要提交给运营人员，提早准备《运营计划》中的推广活动和安排推广资源。
• 《版本发布说明》：每个版本进入内测后，由开发团队编写后，提供给运营人员，包含本版本的所有在产品上的变更细节。以及这些版本内容的开发成员。供运营人员培训客服掌握，以及运营人员自己做测试，用以作为《运营计划》的材料。
• 《运营计划》：根据每个版本，运营人员提交此文档，包括运营活动内容和所需的推广资源和资金支持。以及需要包括此次运营预计要达到的商业效果和衡量手段。
• 《产品部署、升级方案》：由开发人员提供给运维人员的技术部署方案。包括如何部署安装进程，设置CDN或DNS，运行SQL或者修改配置文件。某些团队会开发自己的产品部署工具，如Chef这类软件，用以自动化处理运维工作。
• 《产品统计需求》：由运营人员提交给运营开发人员，定义统计报表的格式和统计周期，描述每个表头的含义。运营开发人员根据此需求文档，开发统计程序，自动定期反馈数据报表给运营人员。

重点注意

一般游戏的持续更新，需要遵循一个版本列车的设定：

由于开发的内容有长有短，所以开发过程中的代码必定要维护多套版本分支，这需要在SVN上做严格的定义：