冲进畅销榜前列的休闲游戏，《弹壳特攻队》做对了什么？
9 月初，由海彼游戏研运的 Rogulike 休闲游戏，《弹壳特攻队》，正式全平台公测，随即就成为了业内焦点。该作不仅一度冲击畅销榜前 10，更是实现了月流水破亿的好成绩！
《弹壳特攻队》是一款画风简洁卡通，操作简单的 2D Roguelike 割草手游。玩家在大地图中，依靠升级各类武器和技能，来应对铺天盖地而来的、密密麻麻的怪物大军，再辅以伤害显示，给玩家带来了极具爽感的游戏体验。
首先，跟大家介绍一下《弹壳特攻队》的团队和游戏创意来源吧。
《弹壳特攻队》的团队成员都是在游戏行业打拼多年的“老兵”，不过长时间从事游戏行业并没有磨灭大家对游戏的热情，相反让大家对于游戏可玩性有了更为苛刻的要求，可以说是一群对游戏有着极端热爱的“偏执狂”，如果一个玩法在团队内没有得到所有人的认可，是不可能进入到测试环节的，甚至老板可能都不会见到。
研发团队合影
《弹壳特攻队》的创意来源其实有很多，项目初期我们曾经做过类似“现代热兵器”弓箭传说的玩法，希望通过重新设计武器/技能，调整视角关卡来给玩家截然不同的体验。在尝试过多个版本后，我们逐渐摸索出来了现代热兵器战斗和奇幻战斗的区别。对于热兵器来说，战况更激烈、爽快、火爆，而且对热兵器的打击感要求很高，比如子弹命中金属单位火花，大量的爆炸。整个战斗场景里应该有大量弹幕、敌军单位。像早期的《血腥大地》（Crimsonland ）和《孤胆枪手》（Alien Shooter），那种大量怪物不断出现一直给与玩家压力感的体验是我们 Demo 后期尝试的方向，不过直到 steam 平台的《吸血鬼幸存者》出现才使我们方案最终定版。Roguelike 玩法一直是我们团队所擅长的领域，而《吸血鬼幸存者》验证了“Roguelike+生存”这种模式是可以得到玩家和市场认可的，所以方案确定下来后我们很快就做出了玩法原型。
我们的游戏主要是面向移动端，在经过 Demo 原型的分析和体验后，我们对玩法进行了大量的迭代调整：
我们把单局的时长控制在了 15 分钟，而且加入了战斗自动存档，使游戏更契合移动端用户的使用习惯。同时，整体时间的调整也会引起其他的调整，时长缩短后在战斗节奏也更加紧凑、刺激，让玩家的注意力更加集中。
我们保留了《弓箭传说》的竖屏视角和可以单手操控的特性。为了让体验更好，我们加了很多预警，提示等一些小细节。这样让玩家能够对即将到来的挑战有一些预期，不会措手不及。
除了玩法优化，原型 Demo 最大的挑战是性能，我们希望尽可能保证同屏怪物的数量，让玩家能够体验到“爽快割草”、“极限求生”。为此我们的技术尝试了很多方向。最终我们选择了 ECS 架构。在整个团队的努力下，最终，原型在性能上达到了我们的预期。
《弹壳特攻队》游戏场景中有大量的 object，请问团队是如何做管理的呢？同时我们了解到，该游戏使用了 Unity 的 DOTS 架构，可以具体介绍一下团队是如何使用此架构的吗？
海量怪物围过来的体验非常棒，但是性能却成为了我们不得不考虑的一个难题。所以，当我们定下来这个游戏模式的时候，就着手准备了。在早期版本中，我们尝试过用之前写的底层来做 demo，但是当怪物数量到一个量级的时候性能下降的很严重。后来我们技术讨论的时候想起了之前 Unity 技术专家来我们公司做技术分享的时候提到的 DOTS 技术，在移动端实现了大量单位同屏。所以决定转用 DOTS 相关的技术来进行 demo 的开发。
最开始我们是非常忐忑的，从 OOP 的思想转换到 DOP 思想，对于我们技术人员来说是一个新挑战，再加上当时我们找到 DOTS 相关的资料也不多，所以只能一步一步尝试。我们当时找到的比较完善的 DOTS 版本是 0.17，按照最初的想法摸索搭建了一个非常小的 demo。没想到 DOTS 给了我们一个惊喜，新demo做性能测试时，我们把数量参数调整到几千只，都很顺畅得跑下来了。为了验证我们还特意尝试了一些 15-16 年的老机型，虽然开始有轻微掉帧的表现，但是也没压力跑完了。虽然 demo 的逻辑没正式版本那么复杂，但是实现了远超需求数量的怪物在低端机型上顺利体验，这是我们意想不到的。
其实，我们首次上线测试开始的时候，才赶上最新的 0.50 的发布，但是需要做的东西太多，已经来不及升级了，索性就一直在用 0.17。关于自动更新方面，我们项目暂时还没加入。是有后续的打算。现在还没有具体的确定方案。
我们的核心需求是实现大量目标在同一场景出现。在设计上我们把游戏内需要展示出的内容拆分为 4 部分：单位实体（如玩家和怪物）；子弹实体；特效；文字。
Entities + HybridRenderer
这两个组合各有利弊，最开始的时候我们想用纯 Entities 实现全部内容，但是后来发现，有很多游戏内较复杂的逻辑用 OOP 的思路开发和维护起来更容易，再加上时间仓促，渲染方面想转 URP 有点来不及。所以我们最后把这两个方向结合了起来，一部分逻辑内容依然放在依然使用原有的 GameObject+Monobehaviour。另一部分耗性能高的运算逻辑则放在 DOTS 层，充分利用 Entities 的多线程。这种设计方式加上我们 TA 的渲染优化，就实现了现在的游戏逻辑。现在来看，已经有了不错的性能表现，但是其实我们仍然不觉得满意，后续我们仍然会保持对游戏性能的进一步优化。
伤害飘字部分主要基于两个方面来考虑， 一是以后可能需要图片+文字或者其他多变的艺术化文字来丰富和迎合整个游戏的卡通化风格，所以需要一定的美术扩展性。二是希望能很少批次就能渲染所有文字，因为伤害飘字的特征是单个文字顶点少，但量特别大。综合考虑我们确定了图片+ GPUInstance 的方案，这样不仅满足性能和效果的需求，还更方便我们当时项目结构的管理。
首先还是先要赞一下 DOTS 架构的巧妙设计和便捷，这套架构极大的降低了使用成本。由于 C# 作为高级编程语言封装得太好，所以大多开发者对 unsafe 并不是特别熟悉，想要写出高效且安全的指针内存操作无疑增加了很大的难度。DOTS 架构上手简单，而且在学习 DOTS 框架的同时也会对内存、指针、寻址、数据存储方式等提供更深的理解，有利于对计算机基础的学习。
如果说还有需要提升的方向，可能想到的是对 ECS 部分的优化。因为传统 GameObject 使用的是面向对象编程的方式，而 ECS 使用的是面向数据编程方式，从而增加了上手难度。同时 ECS 本身存在很多独有的写法和命令，比如 WithoutBurst+Run 操作等，这些也会在学习初期造成一定的困扰。所以我个人觉得如果能够使用面向对象编程的思维来写面向数据的逻辑，才真真是极好的。
比如在 MonoBehaviour 中开放一个类似于 SystemBase 的功能，虽然没有可以移除和添加的功能和便捷的扩展性，但是也可以满足一部分的开发需求，并且可以更好的引导开发者将 ECS 和 GameObject 系统看做一个整体而不是两个独立的架构，从而引导学习和了解的兴趣。
对于后续版本发布，惊喜肯定是有的，不过相应的制作难度也非常大，可能还需要玩家们耐心地等待一段时间。可以稍微透露一下，未来的版本中我们会加入实时组队的相关玩法，并且会强调团队配合和策略性。
长按关注
第一时间了解Unity引擎动向，学习最新开发技巧
每一个“在看”，都是我们前进的动力