游戏也是软件的一种，所以简单来说，游戏开发跟传统软件开发流程是相似的，也都是遵循：设计→编码→测试→运营，之后进入更新维护阶段，重复上述流程。但展开来说，还是有很多细节内容值得介绍的。

游戏相比普通软件，商业利润要高出很多，所以竞争激烈，不可避免地就会越做越复杂。而且游戏一旦失败了，想要回收一点成本都十分困难。所以游戏产品在确定开发之前，一定要先有一个严格的立项审查过程，一般做这么几件事情：

前景规划。这个一般由游戏制作人发起，提出一个游戏类型和玩法方向。然后要能够将想法中的要素清晰化，主要逻辑打通，表达要具有说服力，这样的立项提案才有可能被采纳。

市场调研。当一个立项提案被采纳之后，或多或少地都会先根据当前市面上已有的游戏进行比对，有能力的甚至还会调查其他公司正在开发中的游戏。要考察是否有相同类型，相似玩法的游戏，如果没有，就要分析这是一篇蓝海，还没有人做，还是这是一片死海，这条路根本行不通。如果有，就要与最好的几款游戏进行对比，思考自己的游戏如果做出来，是否具备竞争力。是直面碰撞，用更高的游戏品质碾压对手，还是避开冲突，利用热点IP或细分领域占据剩余市场，再实现反超。

Demo预演。当你的产品方向确定了，市场调研也预估过了，那么接下来就是先小成本的做一个Demo出来进行尝试，看看核心玩法实现过程中是否有什么阻碍性的问题，实际做出来之后是否真的可玩好玩。如果这一关也通过了，那么基本上就可以确定这个产品可以准备进行开发制作了。

当产品立项通过以后，开发团队的人员到位需要一定的时间和准备。在这个过程中还有更重要的事情要做，就是将如何制作的前提条件和版本计划梳理清楚。

框架玩法。前面也说到了，立项的时候，游戏的核心玩法已经确定了，Demo预演也证明了玩法的可行性。但游戏最重要的是好玩，好玩是一个体验过程，所以任何核心玩法都是需要进一步丰富和包装的，并且围绕核心玩法搭建起来一系列的行为模块。比如角色要如何成长，引导和支撑玩家行为的内容有哪些，游戏产出什么消耗什么等等都是需要考虑。这些内容一般都是由游戏策划来完成，而设计这些功能内容的策划，一般称之为系统策划。

风格规范。这里的风格规范主要包括的内容有游戏故事背景的设定，这决定着游戏的题材使用的是玄幻、魔幻、武侠、科幻，美术风格是用写实、Q版、3D还是2D，然后进一步决定着游戏世界里的角色构成，背景架构，故事脉络等等。光这些还不算完，涉及到具体实现的话，美术还需要进一步确定场景、角色、界面、音乐音效这些资源的表现方式，以及制作尺寸。比如场景和角色要限制在多少面数以内，界面主要用多大等等，这些还需要程序参与进来，结合使用的技术方案和引擎框架一起进行评估，甚至在这个过程中就需要开始进行一些测试来验证结论了。

版本计划。当上述细节内容确定的七七八八了，还需要再做一件事情。因为游戏开发一般都耗时较长，好的游戏是需要以年为单位进行的，短的也要3个月，所以不可能一蹴而就。那么上面列出的那么多开发、制作的内容就需要根据重要程度，以及团队当前的状态安排好优先级，分阶段来完成。每个阶段大概需要多少人力，多少时间，因为完成的越晚，市场上就越可能出现竞争者，产品预期的用户也可能发生转移。所以要确定好一个时间尽可能短，体验尽可能良好，还没有完全做完的产品推向市场，版本计划的目标就是确定几个不同的可以上线的完成目标。一方面约束团队，集中力量将当前目标尽快完成，另一方面可以根据市场情况，随时做好上线准备。

接下来就进入到游戏开发中最核心最关键的地方了，那就是真枪实弹、一点一滴地将产品做出来。

方案设计。也就是明确需求，这种需求可不能停留在“我要一个XXX”这样的描述水平上。一定要对XXX的构成，使用方式，规则流程有着明确详细的说明才行。比如这个XXX是做什么用的，包含哪几个功能模块，使用流程图是怎样的；然后进一步细化每个模块是做什么用的，是否还有细分模块，流程是怎样的，依次往下。有经验的策划，还会站在玩家用户的角度上，模拟玩家是怎样操作的，页面是怎样跳转的，这个也就是Page-Flow。当然，也可以有更专职做界面设计的策划同学负责设计Page-Flow，同时给出页面大小、布局还有素材要求，这样给到界面需求，美术同学就能更方便地制作出来了。美术资源的需求除了界面，可能还包括有场景、角色，还有一些图标icon、音乐等，也都是在策划设计阶段制定出来，如果策划同学自己比较难理清楚，也可以找相关的制作同学帮忙一起设计。

在这个阶段，测试已经可以开始开展相关的工作内容了，也就是参与到“需求评审”中来。这个一般由策划同学发起，程序、美术、测试甚至运营参与，以小组会议的方式开展。目标是审查设计逻辑，评估工作量，制定具体的开发计划。

程序编码，美术绘图。当需求确认了，开发计划也排好了，就要动手开始制作了。这里最主要负责的就是程序和美术同学了，编码和绘图这两个过程一般是同时进行的，所以放在一起说。先说程序，除了单机游戏，目前几乎所有的游戏都是要联网的，也就是程序开发至少要分为客户端、服务端两大模块，俗称前端和后端。前端主要负责表现，后端主要负责计算。当然，也有一些游戏也会放在前端进行计算，后端会收到计算过程和结果进行复验。如果你的游戏只有前端计算，那么很容易被破解，被外挂利用刷奖励等，极大影响了游戏寿命。点击介绍游戏制作的构成。美术制作过程也比较漫长，尤其是3D资源，要先画原画，再建模，这就需要至少两个美术同学。所以美术资源也会大量外包，包括音乐、动画、图标等这些内容。外包的时候一定要注意，除了说明美术需求以外，还要明确制作和验收标准，甚至还要有一些商业保密协议，不然对方交付后不满意，来回的沟通扯皮，这功夫还不如自己画呢。

在这个时候，测试也要同时开始自己的工作准备了，分析文档，写测试用例，具体的做法请参考如何写测试用例。当程序开发完成后，可以先开始验收测试（一般也称之为单服测试）。目标是验收程序开发的完成度，确保需求的实现。单服测试可以有很多种，可以程序同学自测，也可以叫策划或测试同学进行验收*。大部分情况下，验收程序开发的时候，美术资源还没完成，这个时候最好有一些临时资源进行替代，而不是要等到美术资源到位了才去验收。因为单服验收后，程序代码必然会有调整，甚至要进行二次开发。测试同学在单服验收的时候，也可以与自己写的测试用例进行对照，根据程序的实现方式，修改测试用例中不一致的地方。

配置联调。当程序编码已经完善了，美术资源也制作好了，策划的需求都基本得以实现了，这个时候还不能称之为完成，因为还没有将这些素材良好地组织起来。这就需要策划同学以配置表或配置文件的方式，将美术资源在游戏中安排好，比如什么场景里要放置什么NPC和怪物，还要填充大量的文本对话、说明文字和数值公式等。当策划完成所有的配置后，这个功能才算有了一个基础完整的可玩性了，然后就会通知到测试同学。功能测试中最重要也是工作量最大的工作内容要展开了：集成测试。

首先测试同学要跟策划和程序确认好要进行测试的内容所处于版本环境，然后对照着之前写好的测试用例，一条条地进行执行，记录过程和结果，并提交发现的问题，具体做法可以查看测试的工作流程。目标是全面验证功能逻辑的正确性，检查细节实现，以及与其他系统功能之间的影响性。发现问题后，要描述清楚，提交给相关的策划和程序同学进行修复，修复后再进行回归测试。点击查看如何记录和提交bug。

上线发布。当版本中所有的功能都差不多完成了的时候，就可以上线跟玩家见面了。这里先慢着，还有一些事情没做完：首先，运营同学会体验下这个游戏，然后提出一些建议和运营活动的需求。其次，手机游戏上线是需要渠道App进行推广的，比如Appstore、应用宝、微信等，这就需要接入这些渠道的SDK，这样游戏内才能使用苹果账号、QQ、微信等进行登录、充值甚至加好友。如果你的游戏要所有渠道都发行的话，那么每个渠道的SDK都要接，这样最终打包出来的游戏App其实就是每个渠道至少1个（有些渠道还有细分领域，所以不止1个），这些我们统称为“渠道包”，渠道包彼此之间是不同的，因为接入的账号系统，充值流程都是不同的，甚至还有些要换图标icon，加渠道logo等等要求。而且即便上线之后，产品也很难免不出一点问题，有些问题玩家说明的很模糊，需要确认和在内网重现。这所有的一切，我们都先将其归结到“发布测试”当中来。

发布测试包含的内容不少，比如要做渠道包Checklist，要跟进外网问题，甚至还可以召集项目组里所有人，大家一起来体验游戏，查缺补漏，搞一次bug-rush比赛。目标是验证上线前修改的内容，最后整体快速地验证一遍游戏，并实时跟进线上问题，做好应对突发问题的准备。

上面大段的文字可能看着比较累，那么看下面这样图片也是可以的。每个测试阶段，还附加了一个小例子，来说明这个阶段能发现一些什么样类型的问题。

《奇迹破坏神》这款游戏，曾今想要做一个“代充”功能（给别人充值，相当于代付）。评审讨论的时候，就提出了设计本身比较多余，因为很多第三方支付平台，如微信、支付宝，本身就是有这个功能的，游戏里没有必要单独做。另外，游戏里的充值都会附加一些效果，例如月卡领奖之类的，代充就要处理这些可能存在冲突的地方，给原来的系统带来额外的工作量。还有最后，苹果的app上线标准里是不允许有这样帮他人购买的行为，这个功能在上线App Store的时候还需要屏蔽。这些问题在『需求评审』阶段就可以发现，如果评估讨论后，确认不做了的话，可以减少很多工作量和风险，节省开发时间。

《剑网3》曾今出过“邮件奖励重复领取”的问题。原因是已领取的邮件，在修改邮件状态时出错了，导致已领取的状态没有保存。角色重新登录后，又会重新加载邮件未领取的状态，于是就可以重新领取。这在进行『验收测试』时，只要确认下数据发生修改后正确存盘就能发现了。

《卧虎藏龙2》有个驯马功能，功能本身流程都是正确的，但“驯马过程中走到传送点的时候，会引起客户端闪退”。其实就是对一些正常流程之外的异常情况没有做处理，代码逻辑的健壮性不够。这样的测试点，是需要『集成测试』时去认真思考和探索才能发现的。

《剑荡八荒》在接入渠道的SDK后准备上线，上线前过Checklist，发现分享微博会引发客户端闪退。是因为程序在接入SDK接口时，调用微博的接口错误导致的。所以任何小的修改，上线前都要经过一轮『发布测试』，避免因为过度自信而给产品带来风险。

把流程模块列出来，除了想要让读者对细节有个了解以外，也是想将整个工作链条中重要的目标和内容说清楚。如果将来遇到了项目问题，产品没能成功上线，大家可以整体地去思考和分析究竟是哪个环节、哪些工作没有做好。如果是产品方向有问题，那是立项时没有严格审查？市场调研不足？如果是开发阶段有问题，那是具体的开发人员能力不足，还是做版本计划的时候，版本目标不清楚，工作量预估偏差过大？如果是线上问题多，是开发阶段的质量把控不到位？还是后期调整太随意？总之，事情做了，辛劳也付出了，如果没能收获果实，也没必要抱怨或者气馁。最好还是看清楚问题究竟在哪里，这对自己以后，无论是选择产品，还是选择团队或合作伙伴都有很大的帮助。