文/蓝鹤东
——本文只是自己从业以来对自己工作的经验总结，有些方式方法可能不一定先进，但代表了我这几年的经验，之后也会不定期改进。
1. 立项
一个项目立项的原因可能性非常多，有可能是公司拿到一个好的IP，也有可能是几个负责人有个很棒的idea，亦或是老板的梦想是做一个XX类型的游戏，这边不做过多的讨论。
立项过程中应该包含市场调查和产品定位，需要分析当前市场并且预测未来市场趋势，同时还要知道产品面对的对象以及这些对象应该有的特征、消费习惯等等。
2. 开发初期
2.1 核心玩法
——此处核心玩法多指核心战斗，部分不存在战斗的游戏未在讨论之内。
对策划来说，开发初期最重要的是核心玩法的确立，只有确立了核心玩法，后续的工作比如核心数值以及核心系统循环才能展开。
在初期确立核心玩法时，一定需要足够长的时间和精力去推敲，因为如果核心玩法存在问题，意味着你盲目展开的后续工作除了美术之外都可能需要面临很大的调整或者重做。
2.1.1 核心玩法是什么
在我看来，所谓核心玩法，即是一个游戏最本质的内容，是用户花费大量时间去钻研的玩法系统。
它是你的游戏整个战斗UI界面的所有东西，包括血条、蓝条、生命、攻击键等，甚至还包括战斗界面上看不到的技能、属性等。
整体上核心玩法应该是可以用一句话来概括的游戏规则，譬如《QQ飞车手游》的核心玩法就是竞速，驾驶不同特性、维度的赛车先到达终点的玩家获胜；而《王者荣耀》，《英雄联盟》的核心玩法应该是控制不同技能的角色摧毁敌方水晶。
2.1.2 如何确立核心玩法
核心玩法往往是基于立项所要做的游戏方向、IP、题材等因素分析该类型的游戏核心点后归纳、提炼后再由策划内部多轮讨论——推翻——再讨论后得出的。
核心玩法往往会根据团队内部实力、经验等因素方向也会有所偏向；2D或3D，写实或Q版都会有所讲究。
拿我们之前做的定制IP的游戏来说来说，在拿到这个IP的时候我们是需要根据IP适合改编的游戏类型去建立的，在决定做ARPG的时候我们就需要根据市面上的ARPG分析，去决定我们的ARPG是横版/竖版、操作机甲/适格者、追求像真三割草式或者是火影忍者那样连击式、通关条件的等等各方面在战斗界面出现元素的建立。
记住，任何出现在你界面上的元素都是应该有存在价值的，否则就意味着它有可能被删掉，被别的部门、老板或是玩家，删掉意味着这部分的工作全部=0。
2.1.3 其余工作
在策划内部讨论通过之后或者在讨论之时就会叫上前后端主程和主美一起讨论。切记控制会议人数，人数太多很容易导致结论难产。
所以私以为项目组在前期招聘时应尽快落实策划团队，而程序美术有核心成员就足够了。
2.2 Demo
在确定核心玩法之后应该尽快完成Demo，Demo只要包含最核心的玩法或者是最核心的游戏体验，不需要过多的制作方式和制作规范限制，不需要华丽的画面或者完善的数值。
Demo的作用是验证策划前期讨论的核心战斗是否可行：例如ARPG有几个技能、大招释放是减少蓝量还是攒怒释放、横版3D还是斜45°等等问题，亦或是在回合制游戏增加主动手操、瞄准滑动等操作，这些都是策划讨论出来未经验证是否可行的想法。
在Demo阶段应完成对核心玩法的验证，团队内部应该讨论确定这个方向可行或者不可行，不可行—重做—验证直到可行或者推翻重头来过。
3. 版本计划
在Demo完成占大多数团队成员认可这个Demo方向之后，此时作为PM应根据项目现有情况以及外部因素等多种情况规划好整个项目的开发周期以及各阶段的初步开发时间，以及下一阶段（即原型阶段的详细开发周期以及优先级）。
大体上真正的项目开发应该会有3~4个阶段：原型阶段——核心阶段——迭代阶段——调整阶段（这里并不包括删档测试以及之后的系列测试），后期再根据游戏框架以及核心开发内容细分阶段。
4. 开发
4.1 原型阶段
4.1.1 世界观&题材
——此部分指的是包含世界观的游戏。
好的游戏应该包含相对完整符合逻辑的世界观，一个完整的世界观可以帮助策划更好的完成设计，知道什么样的设计应该有什么样的设计不应该存在，譬如：三国的世界观出现机甲或者冷兵器时代的故事背景出现手枪。
世界观应包含：故事背景、人物设定、经济&能力水平等等，可以理解为是一个小型的小说框架。
4.1.2 游戏框架
在核心玩法建立后，策划内部应该对建立初步的游戏框架，包括系统框架、数值框架（主要为核心玩法数值）、主要玩法设计等一系列大纲。
完整的游戏框架应该包含明确的设计目的以及重要程度和阶段目标以便于安排版本计划。
此处的游戏框架只是一个雏形，打算做一个XX系统，这个系统的定位是什么，目的是什么以及与程序制作相关的初步的完成方式（实时or离线、帧同步or状态同步等），为了尽快推进到下一阶段而不应该包括比较详细的系统设定。
4.1.3 程序
程序需要根据策划的游戏框架提取技术难点并且根据团队的现有实力选择对应开发语言以及所用的程序编写工具，搭建开发环境和底层框架。
4.1.4 美术风格&制作标准
而美术则需要根据策划提供的世界观以及第一版的需求文档确定美术风格以及制作标准。
制作标准需要程序、策划和美术的共同讨论得出，在制作上需要兼顾性能、性价比以及感观接受度等方面的因素，通常会采用重要的部分或者付费系统采用精度或者完成度较高的美术表现，而比较不重要的部分则会采用简单精致的美术表现。
4.1.5 开发准备
通常程序会协助项目其他成员完成开发所用的客户端/服务器搭建以及SVN服务器地址的搭建，也需要决定项目采用的版本管理工具（包括任务以及BUG等）。
主管级别的岗位也需要配合制作人在开始就明确项目的开发流程，包括模型、动作、UI等美术资源的提交流程，预制体的制作规范，任务、BUG的流程，美术资源、策划资源在工程的存放规范，美术资源、策划配置表命名规范等问题。
如果你的项目还打算在海外发布，则还需要考虑海外版本的转化，海外资源的存放路径及规范问题。
还是那一句话：流程可以精简，但绝对不能省略！
4.2 版本计划该更新了
游戏框架有了，知道了游戏大概需要的开发内容，相比初期毫无根据的版本计划，此时应该能够列出一套较为完整的版本计划，应该包括初步的每个阶段应该完成的核心内容以及次级内容，，以及可能预估到的项目延期及缓冲时间。
只是因为此阶段游戏的核心开发内容的不确定性，所以只能给每个阶段定一个大致目标和开发周期。
4.3 核心阶段
4.3.1 开发重点
核心玩法确定后，策划应该可以从这个核心玩法中提取几个关键词，而这几个关键词就是接下来游戏开发周期的核心工作内容。
这几个关键词将决定游戏开发的重心偏向以及人力分配，一般来说这几个关键词分别对应：基础战斗（核心玩法）、玩法深度、核心系统循环以及核心数值。
每个关键词都会包含很多工作项内容，确定开发重点可以让PM更好的进行周期安排和人员重点分配。
4.3.2 基础战斗
常见的游戏都会有战斗场景，只是重要性和复杂程度的不同。
动作类的游戏基础战斗显得极为重要，往往要在基础战斗中下很大的功夫去调试，而且步骤环环相扣，如果前面的环节没有调整好，往往会导致后面环节的工作混乱，找不出问题所在。
动作类游戏往往十分强调打击感，这就跟看电影喜欢去电影院看IMAX因为从视觉、听觉上来说都会有不一样的沉浸感。
以 ARPG游戏为例，ARPG游戏的基础战斗往往要先从移动、镜头开始调试：
移动是否需要增加惯性？惯性需要多大？
移动时镜头是否跟随？
移动到场景末端时镜头是否继续跟随移动？
转向时镜头是否移动？
这些可以在纸上形成方案，但是要想做得好都是需要在场景中一步步调试出来的。
在基础的移动、镜头等调试到一个相对舒服的体验之后再加入普通攻击、攻击转向等等，调试完毕后再不断加入譬如：动作拆分、动作取消、skill01_end接skill02（或者skill02_start）动作衔接等功能。
例如多个动作斜接就需要调整前置动作的收招，既保证动作看起来足够自然，又要保证玩家触觉与视角的一致性，即按键即响应。
再往后再加入更加高阶的操作和表现来提升真实感和表现力，譬如受击表现、特效、音效等。
4.3.3 核心玩法
基础战斗是核心玩法的基础，相对于基础战斗实打实的调试，核心玩法更多是设计项的内容。
如果说《英雄联盟》的核心玩法控制不同技能的英雄摧毁敌方水晶，那么控制角色摧毁水晶是基础战斗，核心玩法设计即是不同技能的英雄设计。怎么样设计丰富、有趣、互动性强、成就感鲜明的技能来让玩家在长期的重复竞技中保持乐趣就是重中之重，当然还会有召唤师峡谷的策略，装备，符文等一系列的系统来充盈保持乐趣的目的，但这些都属于玩法深度的内容了。
4.3.4 玩法深度
一个游戏往往需要玩法来满足玩家对于策略、技巧、时机、深度等多方面的追求。例如：格斗游戏常见的爆气是满足对于时机的追求，《QQ飞车手游》漂移以及双喷、WCW喷、断位漂移等则是满足玩家对于技巧的追求，而《英雄联盟》的符文则是满足了玩家对于策略的追求。
一个好的游戏一定要给玩家足够多的思考或者追求空间，玩家在游戏中的时长越长，积累的经验技巧越多，越容易帮助玩家获得胜利，这样玩家才会持续留在游戏。
游戏深度是从核心玩法中延伸出的某个针对性的玩法设计用以满足玩家对于某方面的长线追求。
4.3.5 核心系统循环
养成系统的存在通常可以满足之前所说玩家对于玩法深度的多种要求、增加用户粘性，同时阶段性的成长不仅可以给玩家带来阶段性的目标、成就/惊喜/新鲜感，同时也是拉长游戏生命周期、增加营收/活动投放的重要部分。
所有系统养成的目的都应该回执于核心战斗，但不一定是回执于核心数值，因为也有可能部分养成只是单纯的回执于战斗表现。
核心系统循环通常与核心玩法、玩法深度息息相关，因为只有在游戏最重要的地方增加养成和付费，才会获得更多玩家的投入，不管是时间还是金钱。
通过玩法【产出】→养成【消耗】→玩法【验证实力/产出】构建的闭环，可以让玩家不断追求游戏所设计的内容。
而系统的设定通常多种多样，不同时期玩家对游戏的理解水平不同，学习成本也不相同，最终设计的系统满足你的设计目的就是一个好的系统。
4.3.6 核心数值
核心数值分为战斗数值和经济数值，数值服务于系统和玩法，根据系统和玩法的需求提供对应的游戏体验。
战斗数值往往是根据战斗体验、理解成本和数值可控性等多方面决定的。
而经济数值除了根据游戏内部因素外还需要根据游戏的生命周期进行时间与定价的转换，花1RMB=X 战斗力= 时间，即时间——价值——战斗力。
4.4 版本计划该更新了
有了游戏框架，知道了开发重点，在进入正式迭代前应该制定好详细的版本计划。
此时的版本计划应该分为两部分：
4.4.1 整体计划
根据此时项目的整体情况以及各种外来因素确定游戏上线的最终期限。
根据最终期限计划好每个版本的最终开发期限、核心目标以及次级目标。
不要对自己和团队过于自信，制定整体周期的时候给每个版本增加适当的缓冲时间以防止意外情况发生，而且是一定会发生意外情况。
4.4.2 周期计划
制定详细的工作条目，包括各部门成员需要完成的工作条目，任务优先级，该条目负责人，以及通过时间安排来体现条目的制作流程。
增加缓冲时间以及延期记录，便于安排进下个版本，同时也可以重新评估某个成员的能力。
4.5 开发规范
开发过程中很多工作往往是并行的，在开发初期定义开发规范可以节省在开发过程中很多不必要的返工和混乱。
还是要说一句，这些是我的经验总结，项目不同有些经验也不适用，而且 肯定也会有更先进的开发经验，仅供参考。
4.5.1 任务&BUG流程
任务首先由制作人（或主策）创建，之后由主策分配给对应的负责人编写策划文档，在策划文档验收通过后创建程序、美术两个分支分别指派给对应主程、主美，由主程、主美决定是否要拆分并分配下去并附上验收时间，由对应的执行人负责完成任务。
任务创建人
之所以由负责人创建任务一是节省主程、主美时间，更重要的是任务完成后需要负责人了解清楚并且验收，中间省去一些步骤。
优先级
任务和BUG的创建除了基本的元素之外，包含优先级会让解决人更好的安排工作，也可以在版本节点让PM更清晰的明白任务量。
解决版本/验收时间
解决版本/验收最后时间的加入可以让测试明确知道该版本需要验收的内容，同样也可以在版本节点让PM更清晰的明白该版本延期内容以及下版本需要额外增加的工作内容。
备注
备注可以让执行人即使不在也可能不需要联系执行人其他人员也能了解大概情况。
4.5.2 程序字
工程中最好有一张表用于管理一些只是说明并没有实际用途的程序字。
如果你的项目打算做多语言版本，同样也需要一张程序字表，在项目开始的时候就把所有的程序字提取出来是最好的办法，后期再做一来工作量大，二来容易遗漏。
4.5.3 美术资源存放规范
这一块规范一般会以程序作为主导，除了最基本的同类型文件存放规范外，一般UI资源会将动态加载资源与静态资源分开存放，优化IOS性能开销的同时因为动态加载资源会经常批量替换，单独存放比较好管理。
在开发过程中UI可能会替换好几版资源，如果美术资源存放规范可以在替换的过程中节省很多时间并且减少很多没用的美术素材，在需要剔除无用素材时也会更便于查找。
在做海外版本时也会涉及到资源替换（内嵌式多语言则涉及资源存放）也会需要大量的资源替换，好的规范可以节省时间。
4.5.4 预制体制作
预制体同样需要一张表格来管理和查阅各预制体。
预制体的制作规范也是极其重要，这会让你的界面从工整和统一性方面看出很明显的差别。
在制作界面时，在美术风格定版后，策划和UI应该共同制定一套界面用字规范，包含几种类型的标题、正文、说明文字、强调文字所用色值和大小等规范，在拼界面时应该严格执行规范，包括程序字也同样需要遵守。
要做好界面，在从UI出效果图到界面拼接都应该严格遵守统一性的原则，甚至要求界面拼接通过临摹的方式实现。
在制作的同时应该尽量考虑到界面的复用性，将一些界面通用化并提取成单独的预制体采用调用的方式实现。
4.5.5 配置表&模块编号
配置表本身有一定的规范限制，在配置表命名之后增加中文注释可以让别人更容易找到需要的配置表。
同时在制作功能模块配置表时应给每个模块定义一个唯一的模块编号，用一张独立的模块表维护，用于做模块之间的索引，同时便于管理并且与程序定义统一性。
同时配置表应该增加一条索引表，用于注释配置表之间以及系统与配置表之间的关联性。
定义配置表字段时应严格定义字段使用者，一味的贪图方便都使用cs会给后期辨别增加很大麻烦。
4.5.6 命名规范
好的命名规范可以节省开发过程中不必要的时间浪费，美术资源命名、模块命名、配置表命名甚至是配置表中的字段命名都应该做到尽量强的辨识度。
如果周期允许，应该在前期尽量做好模块的英文命名，保持开发的统一性语言。
设想一下，地图命名一种方案是根据制作顺序从map001~map100依次命名，另一种方案则是map_city_001，很明显第二种方案能够区别出地图是城市还是农村等等，这边只是一个简单的例子，会根据项目不同有不同的讲究。
比如配置表命名增加模块编号便于分类查找，增加中文注释便于理解；场景地图增加风格编号、模块编号等等。
一般来说策划应该做好命名规范，而美术或者程序内部可以简化命名节省时间，但是到最后提交到项目工程的时候需要保证命名与规范是一致的。
另外有一个统一并且执行下去的命名规范，对于开发人员查找也会带来极大的便利。
4.6 迭代阶段
如果项目顺利过渡了前面的阶段，现在有了制作标准，有了开发规范，还有了明确的方向和制作方法，该把以上的内容变成一个完整的游戏了。
4.6.1 快速迭代
在初期定义好制作标准和游戏方向后，在迭代阶段往往是快速的生产过程。如果初期定义好的规范有执行下去，对于这个阶段应该会省掉很多的工作量和沟通解决成本。
4.6.2 总结
在每个版本结束后留一段时间，用于总结一下在这个阶段碰到的问题并及时讨论解决，同时看看目前的产品，存在什么问题，有什么不足的地方。然后在下个周期安排改进流程和产品，动态的调整每个阶段的目标。
4.6.3 策划先行
其实策划先行应该是贯穿项目开发的整个阶段的，但是在迭代阶段显得犹为重要，每个阶段保证策划工作至少提前一周，这样既可以让策划内部有规划意识，也可以保证其他部门在任务量提前做完的时候可以有一部分提前量，同样也可以防止突发变化导致某部分功能不开发的时候不至于无事可做。
4.6.4 迭代原则
因为游戏不是每个系统都是独立的存在，合理安排好迭代顺序也可以节省一部分“暂代开发”的时间，同时也会让整个开发更合理、规范。
基础优先，核心优先
大模块遵循基础优先，核心优先，基础功能做好才能往上叠加功能，而核心功能的开发往往是贯穿整个开发前中期的，需要长期的思考和沉淀。
关联系统
关联系统可以安排在同期做或者按玩游戏流程的先后顺序做，这样不至于导致一个功能完成后可能都不能完成测试亦或是无法构成循环，而再之后返回来有可能部分结构已经遗忘了。
通用模块开发
开发中有很多系统涉及到的弹窗或者提示往往在其他模块也需要用到，需要协调好避免重复开发或者混乱使用；当然也可以将通用模块单独作为一个小开发项排进版本。
当然版本计划会有很多不确定性和针对性，以上只是基本安排思路，实际还是需要根据项目本身去做合适的排期。
4.7 调整阶段
当项目过渡完迭代阶段时基本上所有的功能开发完毕游戏有一个完整的生态循环，如果运气好在项目上线测试前还会有时间进行测试调整，主要针对包体大小的资源精简；游戏的性能优化以及对BUG的深度测试，譬如规则漏洞导致的刷分，以及程序通信漏洞导致的刷奖励。最常见的通过截包后重复发包、修改包大小等方式重复发包欺骗服务器获得多次或者更高额的奖励。
而对于游戏本身的调整和优化则是贯穿整个游戏开发周期的，在临近上线阶段再做大规模的调整。
4.8 测试阶段
测试如果顺利会分为多轮测试，通过每轮测试的数据针对性的调整资源投放以及关卡难度，调整新手引导难度节奏，调整玩家每日在线时长以及各功能占比。
而上线前准备同样还有很多细微的事情需要处理，例如版号过审、游戏名称以及ICON、游戏资料等需要提供给运营游戏相关资料以做准备。同样也有可能需要增加部分运营活动在游戏上线初期保证最大化的营收。
4.9 尾声
因为工作的关系，前后花了不少时间去写这一份总结，所以断断续续的，有些地方可能接不上或者不够严谨，本来是打算离职后专心去写的。
很多说法不一定对或者不够先进，但是代表自己对开发的理解，之后也会抽空给自己多点时间去改进总结。
对于怎么做的总结也许偏少，可能以后会单独总结。
- 本文固定链接: https://freemanapp.com/zh/?p=415
- 转载请注明: freeman 于 FreemanApp 发表
