游戏开发之版本与里程碑

目录

游戏开发之版本与里程碑... 1

一、         基础... 2

(一)       游戏版本和里程碑计划概念... 2

(二)       如何定制里程碑计划... 3

二、         现状... 4

问题与解决... 4

一、      基础

(一) 游戏版本和里程碑计划概念

所谓的开发阶段的游戏版本，就是指游戏开发到一定阶段所构建（BUILD）的可体验的内容集合。与游戏推出到市场上的收费版本相比，这个阶段的版本主要以验证功能点为主，所以很多版本中出现的内容都不是最终的样子，但它又是必须的，因为只有验证了很多功能点，才可以保障持续开发的方向。

里程碑是指根据游戏版本内容定制的计划及其对应的时间，包含了版本中将有哪些功能点、完成多少资源以及确定分别由哪些人牵头跟进每个功能模块。里程碑计划和版本内容一般是合并在一起提及的，在有条不紊的开发过程中，一个大版本的完成时间通常就是这个版本的里程碑时间。

特别需要补充的是，优秀的游戏版本不仅仅是个内容集合，还可以是个完整的游戏体验点。这取决于这个版本的计划（即里程碑计划）制定得好不好。在笔者经历的《QQ仙侠传》与《斗神传》两个项目中可以体会到：好的版本可以使开发团队在过程中就预见到产品完成时将呈现的样子，这对于调动团队热情有十分重要的意义。

一个网游产品从创意到推入市场将经历很多这样的版本，如下表：

    上表提及的版本都是指针对游戏产品完成度的阶段性大版本，每个版本都有很重要的目标，版本对应的里程碑持续时间需要根据版本内容单独定制。优秀的项目经理会切分好版本的内容并控制好时间，并采取任何方法鼓舞团队在有限的时间里更高效和卓越地完成这个计划（包括但不限于采用物质鼓励）。

    在不同的开发团队中，游戏版本不一定要严格按照上述表格的版本进行，有的产品因为核心功能过多，在FP版本（FIRST PRODUCTION，初级产品版本）后会补充这个验证工作持续到GR版本（gate review，关键点版本）中。但是，能够更早地完成游戏核心功能并在版本中验证它们，在这之后的每个版本都会有很强的鼓舞士气的作用，团队成员会更早地参与到游戏的版本建设中（而不是仅仅作为一个“螺丝钉”）。

(二) 如何定制里程碑计划

具体的定制方法根本上是从版本目标出发的，如目标是立项，那么计划就要以满足立项材料的基础上完成一个初具规模的版本。这段文字是一些分享，就是结合一些重要的版本目标谈每个版本大致需要完成的内容以便更好地制定里程碑计划。

1、 版本目标：立项

过去产品立项是需要DEMO的，这个DEMO就是吸引投资时做的一个小型的版本，包含了产品吸引人的特点和一些美术表现效果，后来因为许多团队为了吸引投资在DEMO中临时掺了太多水分（就是假象），一般的立项也就不仅仅是要看到一个小型的版本，还需要准备充分的立项材料，如立项报告（一般是PPT）、技术可行性分析、产品美术风格、策划框架设计（也叫策划总纲）等等，此外就是有一个团队能够支持这些工作。

通常拥有了以上内容，在参与制作这些内容的团队中就形成了最初的规划，立项就是验证这些规划是否合理的步骤。以笔者在腾讯两次产品立项的经验来看，当拥有足够的市场调研结论和前瞻性分析后，立项材料通常都是能够满足立项需求的。

2、 版本目标：核心验证

既然是产品就有它的核心，网游产品的核心与体验直接挂钩，可以是玩法、技术或者是内容，也可以是这些东西的表达方式或者包装方式。无论核心是什么，在产品研发的过程中，总是需要把这个核心加入到产品中的。

在笔者所经历的网游产品中，产品核心通常会在FP版本（即开发前期）就定义好，并在版本中验证。如《斗战神》产品的核心内容是PVE战斗体验，在FP版本中实现了基础的交互功能外，重点把战斗部分的设计，包括技能、打击感、怪物AI、基础数值都加入到了版本中以此来作为里程碑计划内容。FP版本完成后，产品体验模式基本完成了，几乎所有的团队成员都参与到了后续的版本中，并热烈地畅谈对游戏战斗部分的理想（有的放矢）。

3、 版本目标：功能完善与体验丰富 

当一个产品的核心功能已经完成了，接下来的时间就是不断地完善这个核心功能并根据游戏产品的体验点补充其他内容来丰富产品。这个阶段也就是正式的开发期。开发期最难的在于坚持，很多人都要在很长的时间里坚持和同一个人同一类事不断地跟进和努力，反复地验证，最后得到了一个很小的成果。这期间，里程碑的计划会把完善功能切分成几个阶段，用张弛有道的方法控制开发的节奏，并在必要的时间里投入大量的人力和时间突击难点。

优秀的项目经理在这时已经掌握住了开发团队的情况并分配好了开发计划，他成为了产品进度是否延迟的关键（有时候延迟是为了产品做的更好，那就是另一回事）。

二、      现状

谈完了一些关于里程碑计划和版本的基本认识，这段文字就要开始谈一下问题了。由于产品立项匆忙以及前期规划不当，我们项目在整体计划方面存在很多需要解决的问题。下述问题有的已经呈现，有的正在好转，有的还在潜伏，需要我们在能够扭转的时候及时发现并予以解决，以保证产品最终的质量。

问题与解决

1.         里程碑和版本不应该脱节 

目前我们的里程碑计划只是按照时间平均切分的计划，没有在里程碑结束的同时构建一个符合这个里程碑开发工作的版本。这就使得整个里程碑单纯变成了工作量的计划，比如我们每个里程碑都会去制定策划、美术到技术分别需要做什么东西，甚至有些内容会精确到哪一天的下午几点完成，但为什么在这个里程碑要完成这些，到哪里可以看到自己完成的工作实际是游戏里的哪部分内容，这些问题一直困扰着团队。

2.         对定制优秀的版本计划要有更强的意识 

表面上看，构建版本和里程碑计划（合称版本计划）只是项目开发进度上的一个环节，实际上这不仅仅是一次版本，在长时间开发的过程中团队最容易被磨损的就是耐心，一个能够反应当前开发状况和预见到未来产品样子的版本很容易在开发过程中营造一个兴奋点，结合里程碑计划去构建这个版本就会使团队有信心相信所有的事情都在计划中进行着，特别是当团队成员了解并信赖里程碑计划后，他会付出很大的努力来完成计划而不需要有人监督，因为完成之后他就可以轻松一些并有时间去体验新版本了。

3.         整合版本需要更强的统筹力

    目前产品开发时间进入中后期，也第一次整合了版本来验证功能功能。作为开发中的版本，功能验证为主无可厚非，但我们需要制定一个更强的版本。这个版本应该结合最终产品的目标，拆分成每个阶段要整合的内容，并在整合的过程中尽量使用正式而非临时的办法，铁木真有一个战术叫砍大树，每次砍一些，整个树什么时候砍好就指日可待了。

4.         团队开发为什么低效

    并不是我们缺少激励，也不是因为工作强度大，而是因为越来越迷惘了。开发进入这个阶段，正是产品即将完成，团队摩拳擦掌最后冲刺的时候，但是士气却没有那么高，大家经常提的话题就是不知道产品到底怎么样，换句话说就是产品的完成情况掌握在几个人心里，而不是实际地体现在产品里。游戏开发团队都是为了产品而努力，如果不知道努力的目标和距离，就容易懈怠甚至产生厌倦。

5.         游戏设计定位过大或不清晰，版本计划难以定制

    这需要从游戏设计出发，产品的定位比较高，这并不坏，但是产品包含的内容却过多了（复杂庞大的世界观剧情、多职业格局、战斗体验和社区体验并存等等），不是内容多了就不好，而是要考虑到在合适的时间内做出一个完整的且符合预期的产品。内容多必然带来大量的人力物力的投入，在时间计划上也无法做出有效的定义（一个大作其实靠的也不是设计了足够多的内容，而是依靠游戏性的可重复体验，比如俄罗斯方块）。我们需要重新审视游戏设计，并找准一个重点，做好它，再去找下一个重点。这些重点就是版本中最需要体现出来的东西。

6.         为什么说进度缓慢

    这时说进度缓慢有点不合适，但如果结合产品开发步骤来看，不得不产生这样的担忧。目前产品仍然在制作功能，对于游戏产品来说，做功能是必须的，但功能完成了的网游是不够的，还需要不断地优化它，这些工作积累到完成所有功能之后进行，就可能浪费了不少工作量（优化过程中会为了突出产品特性砍掉很多关联性小或者有负面影响的内容）。所以在网游开发中采用了西方网游开发的一些方法来保证进度和质量同步前进，如FP版本完成游戏核心体验雏形，FULL版本完善核心功能，beta版本完善其他内容等等。结合这个来看，我们目前推出的版本已经慢于时间表了（看下图），可以初步判断我们需要延长2个月时间来弥补这个延迟。

    对于完成工作量，我们的确进展了很大一部分，甚至超过了一半，但是那真的不够，这不是生产积木似的完成了每个零件就算完了，这是用积木搭建房屋，只有零件，还要有一个稳定的房屋结构和花时间搭出好看的样子，这些时间忽略不得。

    7.         解决问题的办法就是坚持有目的性地构建版本 

    是的，解决问题的办法就是要回顾产品到BETA版本时的内容，并重新定义好哪些内容要优先完成，把这些内容切分出重点，在版本计划中逐一加入。坚持制定和公布版本计划，坚持构建可以体验的版本并反复验收，有计划性地尽量使用正式资源和正式的内容，版本完成的部分要用产品级的标准要求和看待，让每个版本的完成都要离BETA版本更近一些，这样就可以保持一个有效的开发力度持续工作。

当这些计划都做好了，剩下的挑战就真的只是“坚持”两个字了。