海量怪物、单局15分钟，《弹壳特攻队》开发技术分享

秋刀录 2022-10-11 发布于北京

展开全文

本文首发“Unity官方平台”公众号

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 部分：单位实体（如玩家和怪物）；子弹实体；特效；文字。

在开发的时候我们也询问了很多同行朋友的建议，所以根据以上 4 部分的设计思路我们当时尝试了两个方向：

Burst Job 自带渲染管线

Entities HybridRenderer

这两个组合各有利弊，最开始的时候我们想用纯 Entities 实现全部内容，但是后来发现，有很多游戏内较复杂的逻辑用 OOP 的思路开发和维护起来更容易，再加上时间仓促，渲染方面想转 URP 有点来不及。所以我们最后把这两个方向结合了起来，一部分逻辑内容依然放在依然使用原有的 GameObject Monobehaviour。另一部分耗性能高的运算逻辑则放在 DOTS 层，充分利用 Entities 的多线程。这种设计方式加上我们 TA 的渲染优化，就实现了现在的游戏逻辑。现在来看，已经有了不错的性能表现，但是其实我们仍然不觉得满意，后续我们仍然会保持对游戏性能的进一步优化。

伤害飘字部分主要基于两个方面来考虑，一是以后可能需要图片文字或者其他多变的艺术化文字来丰富和迎合整个游戏的卡通化风格，所以需要一定的美术扩展性。二是希望能很少批次就能渲染所有文字，因为伤害飘字的特征是单个文字顶点少，但量特别大。综合考虑我们确定了图片 GPUInstance 的方案，这样不仅满足性能和效果的需求，还更方便我们当时项目结构的管理。

DOTS 架构上，你们目前还有什么想要提升的方向吗？在《弹壳特攻队》后续的发布上有什么新的惊喜给到玩家吗？

首先还是先要赞一下 DOTS 架构的巧妙设计和便捷，这套架构极大的降低了使用成本。由于 C# 作为高级编程语言封装得太好，所以大多开发者对 unsafe 并不是特别熟悉，想要写出高效且安全的指针内存操作无疑增加了很大的难度。DOTS 架构上手简单，而且在学习 DOTS 框架的同时也会对内存、指针、寻址、数据存储方式等提供更深的理解，有利于对计算机基础的学习。

如果说还有需要提升的方向，可能想到的是对 ECS 部分的优化。因为传统 GameObject 使用的是面向对象编程的方式，而 ECS 使用的是面向数据编程方式，从而增加了上手难度。同时 ECS 本身存在很多独有的写法和命令，比如 WithoutBurst Run 操作等，这些也会在学习初期造成一定的困扰。所以我个人觉得如果能够使用面向对象编程的思维来写面向数据的逻辑，才真真是极好的。