项目推进（偏重程序）

    写这个文章的时候，主要是想总结一下这么多年开发当中对于如何立项、推进、迭代、收尾等等方面的一个看法和经验。

    1、立项

        一个项目立项需要考虑的因素是非常多的，有可能是拿到了一个好的IP，也有可能是几个项目负责人有了一个很棒的idea，又或者是老板想要做一个什么类型的游戏，还有的就是看到市场上某个游戏非常赚钱，想要介入等等，具体就不做过多的考虑。

        立项当中包含市场调查、产品定位、需求分析、当前市场以及预测未来市场的趋势和时间，同时还要直到产品面对的对象以及研究该对象的特征、消费、习惯等等。

    2、开发阶段

        如果项目已经成功立项，那么接下来就是开发过程了。个人认为有两种开发模式，第一种是丢弃式开发模式；第二种是迭代式开发模式。先解释一下我认为的这两种开发模式。

        2.1、丢弃式开发模式

            什么意思呢，就是前期的demo版本只是为了体验核心玩法，只为了辅助项目快速立项以及体现项目世界观和主体循环流程，后期迭代开发或者说正式开发的时候完全抛弃demo版本，重新开始制作的一种开发模式。

        2.2、迭代式开发模式

            这个就很好理解了，demo版本和后续版本是连续的，所有版本都是在之前的版本进行叠加的一种开发模式。

        2.3、模式对比

            为什么会有这么两种开发模式。如同他们的意思一样，丢弃式能快速的说服公司高层进行项目立项和资金审批或者是别的投资等，后续项目立项之后再重新评估制作以及版本时间，而迭代式却比较注重项目的可扩展性，在前期demo版本当中需要考量后续开发的便利以及一些边界规范等等，因为项目后续就是基于demo版本进行制作的，如果前面的这些规范没有做好，那么后续还不如重新做一份。

        2.4、核心玩法

            核心玩法就是你游戏项目当中让用户花最长时间去玩的一个闭环内容。

            对于策划来讲，开发初期最重要的就是核心玩法的确立，只有确立了核心玩法，后续的周边工作才能顺利展开，而对于程序来讲，只有核心玩法确立了，才能审踱出框架的边界，以便后续的一些功能开发便捷性和可扩展性。

            在初期确立核心玩法的时候，一定要有足够长的时间和精力去推敲打磨，如果后期发现核心玩法都出问题了，那么你后面所有做的工作都有可能面临着很大的调整，严重的可能需要全部推翻重新制作。

            核心玩法的重要性是可想而知的，那么我们怎么样确认核心玩法呢。核心玩法往往是基于立项所要的游戏方向、IP、题材等因素分析该类型的游戏核心点，然后归纳、提炼后经过多轮讨论，接着推翻，讨论循环最后得出一套核心玩法。核心玩法也要根据团队内部实力、经验等因素等有所偏差。记住，任何在你界面上的元素都应该有存在的价值，否则他就不应该出现在你的项目当中，如果这个元素被别的部门、人员删掉，那么意味着这部分的工作等于零。

        2.5、其他工作   

            当核心玩法确认后，策划部门应该和前后主程、主美，甚至是QA部门一起讨论，但是要记住，会议人员不要太多，人员多了容易导致结论的难产。所以说项目立项的时候就应该尽快落实策划的团队，而其他部门可能只需要核心人员到位就可以了。

        2.6、demo

            如果使用丢弃式开发模式，那么这个时候根据核心玩法快速出demo版本，程序部门只需要实现功能，美术部门提供能使用的资源即可，不必要考虑太多以后的问题。

            如果使用迭代式开发模式，那么对于demo版本的开发就相较往后一点，因为要预留给程序部门内部讨论框架的设定以及边界的确认，也要给美术部门进行风格确认和相互确认资源的制作规范等等各种以后可能会出现的问题进行系统性的讨论和形成文档结案来指导后续的开发。

            不管是哪一种开发模式，demo版本主要是验证策划前期讨论的核心玩法是否可行，比如ARPG有几个技能，技能消耗，视角是怎么样等等问题，demo完成对核心玩法的验证，团队内部讨论确认是否可行，不可行就得回到2.4过程当中。

            最后因为demo版本产生出来的各种规范文档将要贯穿整个项目过程。

    3、版本计划

        如果前面demo版本验证可行，而且其他条件也都确认的情况下，那么我们就要正式的推进项目了。这个时候，策划部门应该尽快的确认世界观和题材。世界观当中应该包含相对完整的逻辑，一个完整的世界观可以帮助策划更好的完成设计，知道什么样的设计是合理的，什么样的设计是不能存在的。比如，三国时期的世界观中，不能出现机甲，冷兵器时代的故事背景当中不能出现手枪之类的等等。世界观应该包含故事背景、人物设定、能力水平等一系列的描述内容，甚至可以理解为一步微小型小说的框架。

        在世界观和核心玩法的边界基础上，程序部门会根据这些内容整理出相较完善的底层框架，比如确定同步方式、场景制作、预制制作、资源管理、ui层级，美术部门也会进行风格确定和制作标准的确定，这个部分确定了之后，后续所有的设计都要遵循这个边界，不能无端地进行越界设计，不然有可能导致之前的工作重做或者说进行补丁的介入而导致之前的功能重新QA等等。

        这里要重点说一下的就是同步方式和资源管理，同步方式在一定程度上确定了同屏和准确性的问题，比如使用帧同步，那么同屏人数就不会太多而且趋向于固定人数，而事件同步就不一样了，资源管理主要是根据项目需求进行的资源打包、更新、加载这些内容，体现的是资源池以及后续项目更新的时候用的的内容。如果说这两个都没有确定下来，尤其是资源管理这块，非常容易就导致后期项目推翻重新制作的这个窘境，造成骑虎难下的局面。因为资源加载的方式不一样，直接导致使用资源的功能变动，说白了，功能都是在使用资源的基础上的，资源都变了，功能不修改就使用不了了。

        3.1、深度扩展

            深度扩展是对核心玩法的进一步完善和修改，这个尽量出现在靠前的版本当中，因为对于深度的扩展会对之前的一些功能进行修改，还有的就是边界的修改，会影响前面后面的所有设计内容以及风格，所以尽可能的在早些版本上就行修改和完善，以保证后续工作平缓进展。

        3.2、广度扩展

            这部分内容应该是demo版本之后陆陆续续添加的内容，也是我们常说的核心玩法周边玩法的制作等。他主要是让玩家在核心玩法当中玩累了过来消磨一下时间或者说通过周边玩法来增强核心玩法消耗的一个获得途径。比如核心玩法当中涉及一个装备升级的，除核心玩法可以获得消耗外，周边玩法也能进行消耗补充的一些玩法。

        对于版本时间计划上，不要太相信团队，制定周期的时候尽可能的给缓冲时间来防止意外情况的发生，实际上是一定有意外情况的。

        3.3、周期计划

            计划当中应该包含工作条目，包括各个部门成员需要完成的工作条目、条目的优先级、条目的负责人、时间规划来体现条目的制作流程。适当的增加缓冲时间以及延期记录，方便安排下一个版本的制作计划，同时也可以通过这些条目来衡定相关人员的工作能力。

    4、开发流程

        开发流程，主要是规范任务的建立到任务验收完成的这么一个过程。

        开发过程当中，任务一定是主策或者是制作人发起，首先分配给策划部门进行详细文档的编写，然后在策划部门内部进行消化分解验收通过了之后分配给程序和美术，一般都是分配给主程主美，由主程和主美再对任务进行细分并且分配到对应的人员手上，确定完成时间等。

        任务完成后，要提交测试用例反馈到QA部门进行全方位的测试。

        之所以任务需要主策或者制作人发起，一部分是节省了主程主美的时间，更重要的是任务需要项目负责人清楚并且在完成之后进行验收，如果说任务在项目负责人都不知道的情况下就进行了，到后面审核不通过，那么这部分工作就等于零，甚至会产生副作用，因为任务有可能破坏了原有的框架，让主策或者制作人发起，中间也省去了好一些步骤。

        任务也存在优先级，哪怕是同一个版本当中的任务。

    5、结束项目

        一般来说，当项目不再维护了，才算是项目结束了。