2019-03-06【午夜游乐园玩法】

午夜游乐园（2018.9-2019.1）

需求及环境

需要制作一个类似黎明杀机、第五人格的非对称对抗类玩法。

开发组成员有策划一人，程序局内四人，局外三人，美术UI一人，特效一人，动作一人+外包，模型五人+外包，测试四人。

整体开发周期约五个月。

规划

首先，以之前H5对局总结出的问题未出发点，确认此次敏捷开发需要注意的关键思路：

• 明确提测范围（敏捷反馈流程）
• 强化沟通方式
• 制定规范，保障项目按计划执行
• 加强文档记录，确保各类需求的执行和验收

 

 

在明确了主体思路后，便是对整个开发的时间顺序进行规划。这里计划的是用两个月开发出DEMO用以验证基本的交互玩法，后续陆续填充相关美术资源，打磨整体效果。

Demo

Demo具体目的：

1. 验证对局玩法主流程的合理性、可玩性，根据反馈及时做出修改。
2. 验证角色透视、小地图提示的设计是否能够达到降低用户学习成本的目的。
3. 实现对局场景内阴森、惊悚的环境氛围，敲定场景整体的美术风格。
4. 调整场景大小至合适的范围，确定场景内主干道、道具点、障碍点、交互元素、处决元素的位置。
5. 关注并体验场景中的可进入建筑的实际效果和性能问题，确定场景中可进入建筑的数量。

Backlog

在制定好大致的阶段安排后，下一步是填充每个阶段的工作内容。在这里我们引入了Scrum框架中Backlog的概念，目的是拆分需求，为后续的需求分析、功能开发、功能验收验证提供直观细致的参考。

首先策划需要用脑图形式将整个需求分解成数个主体大型模块，如交互主体（两个对抗阵营）、场景、音乐音效、UI界面显示、通用规则等。

然后在此基础上，进行需求的进一步拆解，直到有具体可执行或验收的功能点。

最后将这些需求以表格形式整理体现，通过和开发组讨论将每个功能点分配到对应的阶段当中。

表格中任务一栏为具体的功能点，后面附上该功能点的详细描述以及对应的实现阶段。

Sprint

Sprint同为Scrum框架中的概念，直译为【冲刺】，可以理解成阶段的意思。

因为我们的开发体系有固定的验收日期，所以需要在开发前就规划好整体的时间安排以安排资源以及评估各类风险。对于留给优化的时间，难以有具体的把握，只能是前期尽量压缩开发时间。这一点和理想的敏捷开发，即无限制的反馈优化有一定差距。

因此，前期也较难完全确定整体Sprint的划分，只能排出开发阶段（1~4），后续优化（5~收尾）是通过几个关键的时间点酌情安排。

Sprint1~4是以三周为一个周期，每个周期末进行一次体验反馈。整体的DEMO在Sprint3结束时成型，开发周期三个月。

Sprint5~收尾是以【玩家CE】和【1月版本上线】进行划分。这个阶段陆续出现了一些比较严重的问题，好在尚有解决的时间。

对于遗留的反馈和Bug，我们采取的方案是留出两天的Buffer处理，具体由程序进行安排，处理不完的会挪到下一个Sprint。这一点确实比较难以在时间和质量中进行权衡，同时这样的方案也在后面出现了问题，即问题的积压造成压力。

执行

反馈

总反馈量：600h

S5~S6期间老大反馈、CE反馈、项目测试反馈、策划组内体验反馈：140h——占总反馈量约四分之一

 

问题搜集

规划

 

执行

 

程序

 

美术

 

测试

 

个人复盘

策划

之前的公司里也采用过敏捷开发，思路基本一致，同样都倾向于把一个功能先实现基础层面，再实现进阶的效果。但更多的还是功能和系统的设计，这还是第一次接触到玩法类的敏捷开发。实际经历后，发现整体思路都是相同的。

个人思路总结：将设计根据重要程度和关联性拆分成多个模块，根据模块的基础和体验时间点需求做出合理的规划。

大部分组内人员对敏捷开发理解仍然停留在流程的层面，并没有实际参与进去，缺少主观的积极能动性，体现在站会上的反馈不积极，全程只是参与听讲，没有提出自身的建议和看法。

在敏捷开发中，策划往往承担的是规划流程，跟进开发，验证需求，提出优化这四个大方面的工作。

规划流程：根据设计提前将功能、玩法拆分，并与PM、程序共同协商出合理的规划。

跟进开发：过程中随时保持与程序、美术的沟通交流，确保设计的实现无偏差。

在这次敏捷开发前期，做的不够到位，导致部分模块的实现与需求有一定偏差，出现返工的情况。

验证需求：验证最终实现的功能效果，针对功能效果与最初的设计做对比，同时深度思考效果是否能达到设计目的。

提出优化：可能发生在各个迭代周期，针对功能、玩法提出优化方案，保证效果的提高。

在敏捷开发中，通常会碰到很多实现难题。通常是一些比较细的设计点，程序实现较为困难。

例如，想要A表现效果，但是程序实现效果较次，追求效果必须要美术实现，但是会大幅增加美术的工作量。此时就需要判断该效果给用户体验造成的影响，值不值得耗费工作量去实现。

例如，A功能模块实现起来较为困难，或者需要底层支援，这个时候就需要重新回顾设计，检验设计逻辑是否存在问题，同时需要再次明确自己的设计目标。与程序协商沟通是否可以从逻辑上采取另外一种方式来达到最终效果。

整体思路就是抓大放小（同时还得尽最大努力去弥补放小后带来的影响）。

程序

局外开发任务实际与局内不同步，造成局外开发完后，无法及时验证联调，只能是局内完成一个功能局外看一个功能，造成局外人员以及在开发其它功能时一直要回头去盯着这个，特别影响开发效率和开发质量。这种情况我们局外可以考虑分成前期和后期两大块来做，局外前期工作做完就先停下来，局内整体进度到一定阶段，局外再接入，期间局外问题可以先收集起来。

资源问题，项目比较复杂，零散的功能很多，一些资源做好后程序不知道或者没时间去检验合完的效果，到最后体验才发现问题。如：音效、引导特效框、结算表现等

qa又多又碎，一个文档中有多个条目，都是比较小的功能还好，如果里面有长有短，程序开发容易漏掉

美术

做第一版场景内对局设计的时候没有提前跟策划沟通好，用了很多血腥恐怖的元素，血滴呀，学掌印呀之类比较恐怖的元素，好在跟策划及时沟通，去掉了这些可能犯禁的元素，改从氛围上进行烘托，运用了蛛丝网，蝙蝠，烟雾等等元素，既不血腥又能很好地展现氛围

制作的过程有些该突出的地方没有突出，一个是没有从玩家角度去考虑理解，在一个就是自己本身对这种玩法理解不是很透彻，平时接触这类风格的游戏比较少，所以在后期产生了一系列问题都是反映玩家看不到注意不到，需要重新进行加强的，这个只能自己平时多积累一下这方面的经验，了解一下我们游戏玩家的不同之处，多与策划沟通协调，在最初设计的时候就注意这方面的问题就可以避开这个雷区

UI的制作场景一直延后，导致很多效果是在临时效果图上制作的，跟真正的场景无法匹配，这是个真坑，但也无法避免，只能是先尽量做得适合一点，等到正式资源出来以后再做匹配。总结以上还是需要多思考多沟通，多多接触一下不同的游戏，才不至于设计的时候抓瞎，不过敏捷开发的方式已经是大大的降低了修改的成本，每次做完一个版本都会进行修订，比全做完再修改要节省不少精力，挫败感也会大大降低。

测试

关于测试人力（虽然已经预计到了，但是实际上前期的投入测试内容还是多了一些，还可以做的更好）：敏捷开发对应要求我们要进行敏捷测试，但是实际功能提测节奏和测试产出上来看，前期不宜投入过多的人力，参与测试，但不能过度测试，需要测试周期间迭代。以午夜游乐园功能举例：S1-S3阶段，只测试主流程和反馈优化建议，不对功能进行细致的测试。敏捷开发现在就意味着不断的优化，不断调整，对于测试来说，一轮测试就够了，后期在其他阶段对原有功能进行迭代测试。但是存在一个问题，敏捷开发的大型功能，基本上线都是在重点月份，例如周年庆版本，寒假版本，其他功能会很多，所以后期人力需求较大，但实际可调配的人力较少，所以在前期，中前期，中期，中后期，后期人员投入1:1:2:5:3比较合理（具体功能内容还要进行调整）。

关于时间（前提预料到了，但是没有很好的办法，导致后期回归测试时间被占用）：严格控制完成时间，前期排期，分Sprint时沟通好，这个时间最好不要有太大变化，每个Sprint都dalay几个工作日，到完整的时间来看就可能要dealy1个月的时间，后期一定预留出回归测试时间；调整优化集中在中期比较合适，不要积攒到中后期甚至后期；

关于评审会（会前的准备参与度不够，可以优化）：准备需要充分一些，汇总整理当前完成阶段的内容，以及遗留的内容，由各个执行部分分别发言。提测日，版本日不建议开评审会，后1天或两天比较好，测试这边跑完主流程，录制视频大家可以看下实际的效果

关于站会（在开发中调整，但是还有提升空间）：时间上现在有所好转，但是总体还是较长，可以调整内容顺序，没有必要都参与的内容，只留部分人进行沟通。后期有所改善，但是我们还可以做的更好

关于敏捷（这个我们要难为一下策划了）：敏捷最大的特点是高度迭代，有周期性，但是现在周期有了，迭代感觉不够明显，更多的更像是分批提测。同时，敏捷是不断的修正质量指标，确认有效需求的修改，而不是盲目的尝试性开发

关于反馈（参与人员不少，但是积极参与讨论的只是那么几个人，如何去调动所有人都参与进来，这是个问题）：在开发过程中反馈，而不是初始计划各个阶段完成后集中反馈，现在看，后期的反馈及QA和前期相比，不是一个曲线，而是一个悬崖，集中爆发，开发和测试压力都很大。同时，从结果上来看，只有测试和策划的反馈，但是实际上并不是，部分美术和程序的反馈是单独发给了策划，这个之后需要调整，大家提出条目，提出条目的人来体验，而不是统一策划去汇总，发挥大家主观能动性，更有参与感，也能够促进及时的修改

整体上讲，午夜游乐园虽然“很坑”，但是实现的效果基本上比之其他功能还是更优的，敏捷开发就是为了更加快捷的调优，不断的调优，而对于测试来讲，需要更加注重是从玩家的角度就考虑，而不再强调传统测试过程中的测试阶段，把测试阶段化为阶段性测试，单元测试。针对开发最终时间阶段的压缩，需要尽可能的去进行回归测试保证正确性和稳定性，就个人观点，敏捷测试更加适用于软件测试而不是游戏测试，因为游戏测试需要圆满，也就是内容的完整性，所以还是需要对BUG的解决上进行推动，发现问题快速解决问题也是敏捷测试的一部分。敏捷测试时，模块提交较快，测试时应该有压迫感，但是我在测试时的整体感受是前期轻松，后期压力极大，之后可以通过时间的调整，把压力均匀的分布的各个阶段内。敏捷测试对于其他功能来讲，工作任务划分要清晰了很多，工作效率也是比较高的，这是敏捷的优势，我们可以有更多的时间去调整，去优化。