终点，也是起点
随着《BOOOM 赏玩会特别节目》 这期推出，今年的 Booom 暴造活动算是正式落下帷幕。对于我来说，这次，也是第一次参加 Booom 的经历给我留下了很深刻的印象。在这趟旅程的结尾，我想在此衷心感谢所有玩家的时间、机核的各位老师给出的评价以及我们团队的另外两名成员所付出的努力！
因此，我想通过本文来复盘我们的项目 《The Revolver》 从零至一的开发过程，从走过的弯路到踩过的坑，以及我们从中所学到的最重要、最宝贵的经验与收获。
《The Revolver》 是一款不那么一样的第三人称射击游戏。在游戏中，玩家需要磨练自己换弹的熟练度，配合自己的瞄准能力，最终通过所有关卡。
Link： The Revolver | 机核 GCORES
概念阶段 | Concept Phase
今年 Booom 的主题相较于往年更简约——前缀“RE” 。在得知活动的主题后，我们便进行了头脑风暴。由于线上协作的需求，我们选择使用 MIRO 作为我们这次项目的主要协作工具。选择 MIRO 主要有两个原因：一方面基于小型团队规模，我们不想使用过于重型和繁琐的项目协同工具；另一方面，MIRO 在我的工作中也被大量使用到，它的灵活性以及易用性留给我很深的印象。
本次项目中团队的 Miro Board
我们的团队包括我在内由 3 名成员组成，都是入行不久的游戏人。游戏自我们的学生时代起便在我们的生活中占据了重要的部分，而作为一个十分喜欢射击游戏类型的我，在毕业后也十分幸运，能够进入一家知名的公司，并且做自己喜欢的第一人称射击项目。
因此，在看到 “RE” 这个主题后，我的脑海中第一个出现的词就是 “Reload” ，换弹。在经历了若干轮讨论后，我们觉得基于这个想法，可以衍生出一个比较有趣，并且完整的玩法；同时，我们也突然发现，左轮手枪， Revolver，恰巧也是以 RE 作为 Prefix，进而联想到西部牛仔对决的画面。
在大多数射击游戏中，换弹一直是一个简化的过程，往往玩家只需要在键盘或者手柄上按下一个按键便可完成。而从拟真的角度考虑，游戏中的换弹显然少了那么一点意思。这就要说到一个另我印象很深刻的设计，来源于游戏《逃离塔科夫》：不同于传统的射击游戏，玩家在游戏中除了需要考虑射击的目标之外，还需时刻主意自己的弹药管理，若是出现需要填充空弹夹的情况，甚至需要等待子弹一发发 Reload 的过程于时间。
Brain Storm
在想法确定后，我们则快速进入了项目管理和规划的阶段。在游戏的开发管线中（特别是欧美的游戏开发管线），通常会具有几个阶段：Concept，Pre-production，Production，and Release。各个阶段有各自的交付目标，基于此便可以设置对应的里程碑（Milestone），配合 Sprint 开发模式进行开发。
针对这一套开发模式，可以参考：
- 网站： How We Make Games | Ubisoft
- 书籍：《Game Design Workshop》（书籍，《游戏开发梦工厂》）
Project Management
预制作阶段 | Pre-production Phase
在预制作阶段，我们密切配合去制作各种 Mockup（小样）来验证我们的想法，确定游戏最核心的交互与 3C。下方的图片展现了我们从最开始的草图，到 Editor 内使用粗糙模型做的 Placeholder，再到最终游戏内的效果图的过程。
Pre-production Process
预制作阶段最重要的目标就是确定游戏核心，而最有效的便是交付垂直切片（Vertical Slice）。垂直切片就像是蛋糕中的一小块，虽然内容量不大，但是却包含了蛋糕的每一层；换言之，我们通过垂直切片来表现游戏最核心的玩法流程。
制作阶段 | Production Phase
进入制作阶段后，核心玩法流程已经确定。在这个阶段，我们基本上以扩展关卡的数量，提升素材的质量以及打磨整体的游戏品质为主。 随着关卡制作的推进，整个游戏变得越来越完整和清晰，然而随之而来的还有大量的 Bug 以及问题。
Production Process
制作游戏看上去很美好，但是...
开发游戏过程中，只有 5% 的时间你会感到顺利，而剩下的 95% 的时间你会感到 “IT SUCKS” ，—— 往往那 5% 发生在项目的最开始，而后者却是常态。
我曾经看到过这样一句话，已经忘记是在何处看到，而这句话却深刻的记在我的脑海里挥之不去。每一个新项目的开始，往往总是兴奋的，仿佛有无数的创意从脑海里迸发而出，而随着项目的开发，创意的验证，很多问题会不断暴露出来，以至于让我们怀疑自己，甚至放弃。
其中一个压力源，来自于项目本身。例如我作为游戏设计师，在设计过程中往往会面临无数的设计决策（Design Decisions）需要被确定。例如，我们是否需要将游戏做成实时战斗？是否要做成自动瞄准？要给予玩家多少的子弹？每一发子弹的伤害应该如何确定？等等。随着项目的深入以及系统的数量，这些设计问题会越来越多。
另一个压力源在于预期与结果的对比。在我们的开发中，由于一些客观情况，如工作压力，线上协作以及日常的突发事件等等，很大程度上都在打乱我们的开发规划。若对比我们每个阶段的最终交付日期和当初计划的日期，它是这样的：
项目管理管线最大的敌人就是开发规划与实际的开发能力偏离，最终造成项目的拖延，甚至失败；而显然，我们的项目管理离优秀还差很大的一段距离。为了赶上项目提交的最后日期，我们只能砍内容，我相信这也是很多团队遇到过的经历。
设计与开发的反思
- 尽早，并合理地确定项目范围 核心系统宜少不宜多
- 项目范围（Project Scope）确定了项目的大小，需要考虑到项目目标，自身能力，客观条件限制等情况。在我们这次的项目开发中，一个 “3D 射击游戏” 对比我们的开发带宽来说，其体量过于庞大，以至于在项目后期我们感到开发十分乏力——系统很多，但是来不及优化和打磨
- 尽早进行 Playtest 验证核心玩法，绝大部分时间留给打磨
- Playtest 能够收集更多的反馈与数据，并及时进行设计方向上的调整。结合第一点，能够尽早地做出可玩版本并给玩家进行测试。
- 在开发的过程中，最大部分的时间应该留给 Production 阶段。而在这次开发中，我们留给 Production 的时间反而是最短的。而由于项目范围过于庞大，这就导致了我们后期对于打磨的内容量难以掌控。
- 不要以自身去预设玩家的体验
- 从我自身来说，丰富的射击游戏经验在设计上带来了难度认知偏差，即：将自己的体验预设为玩家的体验。因此，尽早的测试十分重要，而测试玩家的类型也需要做特定的筛选和分类。
- 以记录的形式追踪每一个任务，Bug 和反馈
- 由于我们这次设计的系统数量并不少，因此在开发的过程中探索一套合理且规范的项目管理体系，去追踪这些任务显得尤为重要。然而，我们号称自身追求敏捷和快速，却忽略了项目追踪的重要性。项目敏捷度不单单是减少某些工作，而应该是追求一种更合理和更有效的开发管线 —— 我想这也只能在一次次踩坑中总结别迭代吧。
- 创建中文游戏标题
- 参加国内的 Game Jam 活动，一个中文的游戏标题非常重要。下图是一个很明显的例子，英文标题在众多游戏中会严重增加玩家的理解难度：
风雨过后才见彩虹
正是有了开发地狱（Development Hell），才能凸显出看到成果后的宝贵。我想，每一个完成的作品背后，都是经历过风雨的开发者。而在他们背后，总会有一道彩虹指向目标的远方。
最后，无论各自的彼岸何在，一起加油吧。