1. 项目设立
一个项目能够上线的可能原因有很多，可能是公司拿到了好IP，可能是几个负责人有了一个好点子，也可能是老板的梦想是开发一款某类型的游戏，这些我们就不详细讨论了。立项流程应该包括市场调研和产品定位，要分析现在的市场，预测未来的市场趋势，同时也要知道产品的目标受众，以及这些受众的特点和消费习惯。
2. 早期发展阶段
2.1 核心玩法
这里的核心玩法多指核心战斗，一些没有战斗的游戏不在讨论范围内。对于策划来说，开发前期最重要的就是确立核心玩法。确立了核心玩法之后，才能进行核心价值观、核心系统周期等后续工作。前期确立核心玩法的时候，一定要花足够的时间和精力去推敲，因为如果核心玩法出了问题，就意味着你盲目开展的后续工作，除了美术之外，都可能需要面临大调整或者重做。
2.2 核心玩法是什么？
在我看来，所谓核心玩法是一款游戏最本质的内容，是用户花大量时间沉浸于你的游戏的原因。它是你游戏整个战斗UI界面中的所有内容，包括血条、蓝条、生命、攻击键等，甚至战斗界面上看不到的技能、属性。总体来说，核心玩法应该是一句话就能概括的游戏规则。比如《QQ飞车手游》的核心玩法是赛车，谁先驾驶不同特性、不同维度的赛车到达终点，谁就能获胜；而《王者荣耀》和《英雄联盟》的核心玩法应该是控制不同技能的角色摧毁敌方水晶。
2.3 如何建立核心玩法
核心玩法往往是根据项目的游戏方向、IP、题材等因素进行分析，然后由策划经过多轮的讨论-推翻-再讨论后进行总结提炼。核心玩法会根据团队内部实力、经验等因素有所偏向；2D还是3D、写实还是Q版，都会有讲究。就拿我们之前做的自定义IP游戏来说，拿到这个IP之后，我们需要根据这个IP适合改编的游戏类型来确立。当我们决定做ARPG的时候，我们需要分析市面上的ARPG，决定我们的ARPG是横版/竖版、操作机甲/资质、追求像真三国无双或者火影忍者那样的连招风格、通关等等，并确立战斗界面出现的元素。记住，任何出现在你界面上的元素都要有价值，否则就意味着它可能会被其他部门、老板或者玩家删除。删除就意味着这部分的工作全部完成了。
2.4 其他工作
当策划们在内部或者讨论中讨论通过方案后，会把前后端程序员和主美一起叫来讨论方案。开会的时候记得控制人数，人太多容易导致难以收场。所以个人认为项目组在前期招募的时候就应该尽早落实策划团队，编程和美术有核心成员就可以了。
2.5演示
确定核心玩法之后，就应该尽快完成Demo，只要Demo包含了最核心的玩法或者最核心的游戏体验，不需要过多的制作方式和制作规范限制，也不需要华丽的画面或者完美的数值。0Demo的作用在于验证策划前期讨论过的核心战斗是否可行：比如一款ARPG有多少个技能，终极技能释放是减法还是积怒，横向3D还是45°倾斜等，或者回合制游戏增加主动手控、瞄准、滑动操作等。这些都是策划讨论过但还没有验证是否可行的想法。核心玩法的验证应该在Demo阶段完成，团队应该讨论确定这个方向是否可行，如果不可行就重做并验证直到可行或者推翻重来。
3. 版本规划
在Demo完成，且团队多数成员认同Demo的方向之后，PM就应该根据项目现状及外界因素，规划整个项目的开发周期和各阶段的初期开发时间，以及下一阶段（即原型阶段的详细开发周期及优先级）的规划。一般来说，实际的项目开发应该有3到4个阶段：原型阶段-核心阶段-迭代阶段-调整阶段（这还不包括删减测试及后续的一系列测试），然后再根据游戏框架和核心开发内容细分阶段。
4. 发展
4.1 世界观与主题
这部分指的是包含世界观的游戏。一款好的游戏应该包含一个比较完整、逻辑性强的世界观。完整的世界观可以帮助策划更好的完成设计。知道设计应该是什么样的。不存在的设计，例如：三国世界观中出现了机甲，冷兵器时代的故事背景中出现了手枪。世界观应该包括：故事背景、人物设定、经济&能力等级等。可以理解为一个小小说框架。
4.2 游戏框架
核心玩法确立后，策划要建立初步的游戏框架，包括系统框架、数值框架（主要是核心玩法数值）、主要玩法设计等一系列大纲。完整的游戏框架应该包括明确的设计目的、重要性、阶段目标，方便版本规划。这里的游戏框架只是雏形，我们计划做一个XX系统，这个系统的定位是什么，目的是什么，程序制作相关的初步完成方式（实时还是离线，帧同步还是状态同步等），不要包含更详细的系统设定，以便尽快推进到下一个阶段。
4.3 程序
该计划需要在规划的游戏框架基础上提取技术难点，并根据团队现有的实力，选择相应的开发语言和编程工具，搭建开发环境和底层框架。
4.4 艺术风格与制作标准
美术部门需要根据策划提供的世界观和初版需求文档来确定美术风格和制作标准，制作标准需要由程序员、策划、美术三方共同讨论，在制作时需要考虑性能、性价比、感官接受度等因素，通常重要部分或者付费系统会采用精度或完成度较高的美术表达，不太重要的部分则采用简洁精致的美术表达。
4.5 开发准备
通常程序员会协助项目其他成员完成开发所用客户端/服务器的搭建以及SVN服务器地址的设定，还需要决定项目所用的版本管理工具（包括任务和Bug等）。主管级职位还需要配合制作人从头明确项目开发流程，包括模型、动作、UI等美术资源的提交流程，预制体的制作规范，任务和Bug的流程，美术资源和策划资源在项目中的存放规范，美术资源和策划配置表的命名规范等。还是那句话：流程可以精简，但一定不能省略！
4.6版本预定更新
现在我们有了游戏的框架，也知道了游戏需要的大致开发内容，我们应该能够列出一个比最初毫无根据的版本计划更完整的版本计划。这应该包括每个初始阶段应该完成的核心内容和次要内容，以及可能预估的项目延迟和缓冲时间。只是因为现阶段游戏核心开发内容的不确定性，我们只能为每个阶段设定一个大致的目标和开发周期。
5. 核心阶段
5.1 发展重点
在确定了核心玩法之后，策划人员应该能够从这个核心玩法中提炼出若干个关键词，这些关键词就是下一个游戏开发周期的核心工作内容。这些关键词会决定游戏开发的重点和人员的分配。一般来说这些关键词对应的是：基础战斗（核心玩法）、玩法深度、核心系统周期和核心价值观。这些关键词会决定游戏开发的重点和人员的分配。一般来说这些关键词对应的是：基础战斗（核心玩法）、玩法深度、核心系统周期和核心价值观。每个关键词里面又会包含很多的工作项。确定开发重点可以让PM更好地安排周期和人员分配重点。
5.2 基础战斗
常见游戏都有战斗场景，但重要性和复杂程度不一。动作游戏中的基础战斗极其重要，往往需要花费很大力气去调试，且步骤环环相扣。如果前面的环节没有调整好，往往会导致后面环节的工作混乱，很难找到问题所在。动作游戏往往强调打击感，就像在IMAX影院看电影一样，在视觉和听觉上都有不一样的沉浸感。以ARPG游戏为例，ARPG游戏的基础战斗往往需要先从动作和镜头上进行调试：
（1）运动是否需要增加惯性？需要多大的惯性？相机是否跟随运动？
（2）当镜头移动到最后时，摄影机还会继续跟随场景吗？当镜头转动时，摄影机还会移动吗？
（3）这些方案可以在纸面上提出，但要做好，需要在场景中一步步调试。
将基础动作和摄像头调试到相对舒服的体验后，添加普通攻击、攻击转向等。调试完成后，继续添加动作拆分、动作取消、skill01_end 到 skillO2（或 skillO2_start）动作连接等功能。比如多个动作连接时，需要调整前一个动作的闭合，保证动作看起来足够自然，保证玩家触感和视角的一致性，也就是按键会有反应。后期再添加更多高级操作和表现，增强真实感和表现力，比如命中表现、特效、音效等。
5.3 核心玩法
基础战斗是核心玩法的基础。相比于基础战斗的实际调试，核心玩法更多的是设计项。如果说《英雄联盟》的核心玩法是控制不同技能的英雄摧毁敌方水晶，那么控制角色摧毁水晶就是基础战斗，而核心玩法设计则是不同技能英雄的设计。如何设计丰富、有趣、互动性强、奖励丰厚的技能，让玩家在长期反复的比赛中保持乐趣是重中之重。当然，还会有召唤师峡谷攻略、装备、符文等一系列系统来填补维持乐趣的目的，但这些都是玩法深度中的内容。
5.4 游戏深度
游戏的发展往往需要玩法满足玩家对策略、技巧、时机、深度等的追求。例如：格斗游戏中常见的爆发满足了玩家对时机的追求，漂移和双喷，《QQ飞车手游》中的WCW喷、断位漂移满足了玩家对技巧的追求，《英雄联盟》中的符文满足了玩家对策略的追求。一款好的游戏必须给玩家足够的思考或追求空间。玩家在游戏中的时间越长，积累的经验和技巧就越多，就越容易帮助玩家获胜，从而让玩家不断留在游戏中。游戏深度是从核心玩法延伸出来的针对性玩法设计，以满足玩家对某一方面的长期追求。
5.5 核心系统循环
养成系统的存在通常可以满足玩家对于上述玩法深度的各种要求，增加用户粘性。同时，阶段性成长不仅可以为玩家带来阶段性的目标、成就/惊喜/新鲜感，也是延长游戏生命周期、增加收入/活动投放的重要一环。所有系统开发的目的都应该是回归核心战斗，但不一定回归核心价值，因为也有可能有些开发只是单纯为了回归战斗表现。核心系统周期通常与核心玩法、玩法深度息息相关，因为只有在游戏最重要的部分加入开发和付费，才能吸引更多玩家投入，无论是时间还是金钱。玩法[产出]→开发[消耗]→玩法[验证实力/产出]构建的闭环，让玩家可以不断追寻游戏设计的内容。系统的设定通常多种多样，不同时期玩家对游戏的理解程度不同，学习成本也不同。你设计的目的就是好的系统。
5.6 核心价值观
核心数值分为战斗值和经济值，数值服务于系统和玩法，根据系统和玩法的需要提供相应的游戏体验。战斗值往往根据战斗经验、领悟成本、数值可控性等因素确定。经济值除了游戏内部因素外，还需要根据游戏的生命周期进行换算。1人民币=X战斗刀=时间，即同值-河道值-战斗力。
6. 是时候更新版本计划了
现在有了游戏框架，知道了开发重点，在进入正式迭代之前，就应该制定详细的版本计划。
6.1 总体规划
根据项目整体情况和各种外界因素确定游戏上线截止日期。根据截止日期规划最终开发截止日期、核心目标、每个版本的次要目标。不要对自己和团队太过自信。在制定整体周期时，给每个版本留出适当的缓冲时间游戏开发，防止意外情况发生，这是必然的。
6.2 周期规划
制定详细的工作事项，包含各部门成员需要完成的工作事项、任务优先顺序、事项负责人、以及事项通过时间安排产生的流程。增加缓冲时间与延长记录，方便安排进入下一版本，同时也可以重新评估某一成员的能力。
7. 开发规范
开发过程中很多任务经常是并行进行的，在开发初期就定义好开发规范，可以省去开发过程中很多不必要的返工和混乱。还是要说，这些都是我的经验总结，有些经验不一定适用于不同的项目，也一定会有更先进的开发经验，仅供参考。
7.1 任务&BUG流程
任务首先由制片人（或总策划）创建，然后分配给相应的负责人撰写策划书，策划书验收后，创建编程、美术两个分支，分别分配给相应的总程序员和总美术师，由总程序员和总美术师决定是否拆分分配，并附上验收时间，由相应的执行人负责完成任务。
（1）任务创建者
之所以任务由责任人创建，一是为了节省主程序员、主设计人员的时间，更重要的是任务完成后，责任人需要了解清楚，并接受，这样就省去了中间的一些步骤。
（2）优先权
任务和Bug的创建除了基本元素外，还会包含优先级，这样可以让问题解决者更好的安排工作，也可以让PM更清楚的了解版本节点的任务量。
（3）解决方案版本/验收时间
增加版本/验收的最终时间，可以让测试人员清楚的知道这个版本需要验收的内容，也可以让PM在版本节点更清楚的了解版本扩展的内容以及下一个版本需要额外做的工作。
（4）注释
备注可以让其他人员在执行人不在场的情况下也能了解大概情况，不需要联系执行人。
7.2 程序字
项目中最好有个表来管理一些只是描述，没有实际用处的程序字。如果你的项目要出多语言版本，你也需要一个程序字表。最好在项目开始的时候就把所有的程序字都提取出来。以后再做，不但工作量很大，而且很容易遗漏。
7.3 美术资源存储规范
这种规范一般由程序主导，除了最基本的同类型文件存储规范外，一般Ul资源会把动态加载的资源和静态资源分开存放。在优化iOS性能开销的同时，因为动态加载的资源往往是批量替换的，分开存放更方便管理。在开发过程中，UI可能会替换好几个版本的资源，如果美术资源存储规范的话，在替换过程中可以节省很多时间，减少很多没用的美术素材，当需要淘汰没用的素材时也会比较容易找到。在做海外版本的时候，也会涉及到资源替换（内嵌多语言涉及到资源存储），也需要进行大量的资源替换，好的规范可以节省时间。
7.4 预制车身生产
预制件还需要一个表格来管理和检查每一个预制件。预制件的制作规范也极其重要，这将使你的界面在整洁度和统一性方面看起来大不相同。在制作界面时，美术风格确定下来后，策划和UI要共同制定一套界面字规范，包括几类标题、正文、说明、强调文。使用的色值、大小等等，在组装界面包括程序字时都要严格遵循。要制作好的界面，从UI效果图到界面拼接都要严格遵循统一性原则，甚至界面拼接也要通过复制来实现。在制作时，要尽可能考虑界面的可复用性，将一些界面进行泛化，提取成单独的预制件通过调用来实现。
7.5 配置表及模块编号
配置表本身有一定的规范限制，在配置表名后增加中文注释，可以方便别人找到需要的配置表。同时，在制作功能模块配置表时，应该为每个模块定义唯一的模块号，并用独立的模块表进行维护，用于模块间索引，便于管理且与程序定义一致。同时配置表应该增加索引表，用于注释配置表间、系统与配置表间的关联。在定义配置表字段时，应该严格定义字段使用者，一味贪图方便而使用cs，会给后期的识别增加不少麻烦。
7.6 命名约定
好的命名规范可以在开发过程中节省不必要的时间。美术资源、模块、配置表的命名乃至配置表中字段的命名都要尽量具有辨识度。如果周期允许，模块的英文命名尽量在前期就做好，保持开发语言的统一。试想，地图命名一种方案是按照生产顺序依次将地图从map001到map100命名，另一种方案是map_city_001，显然第二种方案可以区分地图是城市还是乡村等等。这只是简单的例子，根据项目不同会有不同的考虑。比如配置表命名增加模块编号方便分类查找，增加中文注释方便理解； 场景图添加样式编号、模块编号等。一般来说，策划要做好命名规范，美术或者程序内部命名可以简化命名节省时间，但最终提交到项目时，需要保证命名符合规范。另外，统一、执行的命名规范也会给开发者的查找带来很大的便利。
8.交付阶段
如果项目顺利度过了前面几个阶段，有了制作标准、开发规范、明确的方向和制作方式，那么是时候将上述内容变成一个完整的游戏了。
8.1 快速迭代
在前期明确了制作标准、游戏方向之后，迭代阶段往往是一个快速的制作过程，如果能将前期定义的规范落实到位，应该能为这个阶段节省很多的工作和沟通成本。
8.2 总结
每个版本完成后，我们都会花一些时间总结本阶段遇到的问题，并及时讨论解决。同时，我们也会看现在的产品，看看它们存在哪些问题和不足。然后安排在下一个周期改进流程和产品，动态调整每个阶段的目标。
8.3 先规划
其实规划应该贯穿整个项目开发的整个阶段，但在迭代阶段更为重要。规划工作应该保证在每个阶段至少提前一周做好。这样不仅可以让规划人员有规划意识，还可以保证任务提前完成时其他部门能有一部分预支，也可以防止突发变化导致某些功能没法开发，这样就无事可做了。
8.4 交付原则
因为游戏中并不是每一个系统都是独立存在的，所以合理安排迭代顺序可以节省一些“临时开发”的时间，同时也使得整个开发更加合理和规范。
8.5 基础第一，核心第一
大模块遵循基础优先、核心优先的原则，基础功能完成后才能添加功能，核心功能的开发往往贯穿整个开发的前中期，需要长期的思考和沉淀。
8.6 相关系统
相关系统可以规划成同时做，或者按照游戏流程的顺序做，这样某个功能完成后，可能测试还没完成或者循环还没形成，后面再回头看的时候可能已经忘记了部分结构。
8.7 通用模块开发
在开发过程中，系统涉及的很多弹窗或者提示往往在其他模块也需要，需要协调，避免重复开发或者混乱使用；当然也可以把公用模块作为一个小的开发项安排到版本中。当然版本计划会有很多的不确定性和针对性，以上只是基本的安排思路，其实还是需要根据项目本身做适当的调度。
9.调整阶段
当项目完成迭代阶段，基本上所有功能都开发完毕，游戏也有了完整的生态周期。如果运气好的话，项目上线前还会有时间进行测试调整，主要针对包大小的资源精简；游戏性能优化以及对BUG的深度测试，比如规则漏洞导致的刷分，程序通讯漏洞导致的刷奖励等。最常见的就是截取数据包后重复发包、修改数据包大小等欺骗服务器的方式，从而获得倍数甚至更高的奖励。游戏本身的调整优化贯穿整个游戏开发周期，临近上线阶段会进行大规模调整。
10.测试阶段
如果测试顺利的话，会分为多轮测试游戏开发，每轮测试的数据会用来调整资源分配和关卡难度，调整新手引导难度节奏，调整玩家每日在线时长和各项功能占比。上线前还有很多细微的事情需要处理，比如版本号审核、游戏名称及图标、游戏信息等，需要提供给运营方进行准备。可能还需要增加一些运营活动，以保证游戏上线前期收益最大化。
