Optimizing Deep Rock Galactic Survivor for mobile

将一款复杂的PC游戏移植到移动需要哪些条件？Funday Games 的深岩银河：幸存者将《弹幕天堂》循环玩法与《深岩银河》中的矮人、职业、武器和挖掘机制相结合。移植公司 Piktiv 面临的挑战是，如何在GPU、 CPU和内存预算有限的硬件上，管理数千个同时模拟的敌人和环境组件，同时保持稳定的帧速率。

在移动上实现这种体验需要重新设计系统，而这些系统的成本会随着敌人数量的增加而增加：寻路、物理查询、敌人渲染、伤害数值和环境渲染。该团队还必须将游戏装入 3 GB 的 iPad 中，支持从当前旗舰机型到多年前的安卓硬件的各种设备，并保持与仍在积极开发的PC分支的单向合并。

我们与工程经理 Marcus Ekelund 和首席工程师 Fredrik Åkerblom 讨论了移植事宜。深岩银河：幸存者针对移动，他们提供了定制解决方案，并探讨了他们如何在碎片化的设备环境中优化性能。

在开发移动版时，你们最重要的技术目标是什么？

弗雷德里克·阿克布洛姆：我们最初设定的许多技术目标都很简单：我们能否make在移动上运行？如果可以，它能支持多大范围的设备？如果你看看Apple产品，你会发现实际可以发货的细分范围其实并不大。首先是最新颖的产品，然后是一个范围稍广的类别，其中包含许多目前可用的产品，最后就是其他所有产品。你至少要达到中间那个级别。

我们遇到的一个反复出现的问题是，所有这些设备都配备了 4 GB 的 RAM，只有一台 iPad 配备了 3 GB 的 RAM。因此，这成为了一个核心技术目标：我们make它在这款 iPad 上运行而不崩溃吗？我们大约有 1850 MB 的空间可以使用，如果超过这个限制，那就彻底完了。早期的大部分工作都集中在配置内存上，之后我们才能更多地关注游戏在各种平台上的实际性能。另一方面， 安卓目前拥有大约 9000 种不同的设备，因此确保所有设备都能正常运行本身就是一门科学。

从PC迁移到移动硬件时，遇到的最大性能瓶颈是什么？你是如何克服这些瓶颈的？

FÅ：有几个核心系统非常突出，它们都拥有成千上万个活跃对象：伤害数值、投射物、游戏世界本身以及动画3D敌人。

例如，伤害文本最初是使用TextMesh Pro 的游戏对象 。但是，当屏幕上有上千个敌人，你向他们抛出一颗手榴弹时，所有敌人都需要显示伤害数值。瓶颈在于生成文本网格：让字体将你的string转换成视觉效果。

最后，我们使用了一个普通的Unity粒子系统，以及一个包含数字 0 到 9 的精灵图。

我：另一个例子是所有敌人的寻路，它使用了PC上的内置导航网格系统。我们还有来自Unity的一个工程师团队为我们提供支持，其中一位工程师开始着手研究一种使用流场导航的解决方案。另一位工程师构建了一个 KD 树解决方案，以优化消除大量的物理查询。

FÅ：在敌人渲染方面，屏幕上同时会出现大约一千个蒙皮网格渲染器，但这实际上行不通。事实证明，几乎所有这些敌人都只有一个动画，所以我们实际上不需要支持多个动画。

相反，它使用了一种将动画的每个关键帧烘焙到纹理中的系统。我们像这样逐帧处理，然后通过GPU上的Shader对每一帧进行vertex动画，因此几乎没有CPU开销。

将其烘焙成单个静态网格和纹理是一个很大的改进，而且它还可以让你进行诸如GPU 实例化之类的操作，因为它们在技术上都是具有相同材质的同一个网格。

流场和 KD 树的底层工作原理是什么？它们取代了什么？

FÅ：流场是路径查找成本所在位置的反转。通常情况下，当有 20 或 30 个智能体在一个环境中进行路径规划时，你会构建一个该环境的网格，每个智能体负责自己的路径规划。当代理数量达到数千个时，就会成为一个相当大的瓶颈，因为成本往往会随着代理数量的缩放而增加。

在整个关卡中创建一个网格，然后从目标点开始，目标点周围的所有图块都会画出一个指向目标的箭头。向前走一步，再次将箭头指向最近的、已经有箭头指向的物体，继续前进，直到覆盖整个场地。因此，它不是按代理数量收费，而是基于你想要进行路径查找的区域的大小。

你还可以进一步限制它。我们根据敌人的位置进行计算，因此我们创建一个包含所有敌人和玩家的边界框，并且我们只更新该边界框内的空间。

对于空间查询，我们使用了 KD 树。如果你有一个大房间，并在房间中央画一条线，你就把它分成了两个空间。您可以创建一个可以轻松查询的树状结构：给定一个点和一个半径，求出该点处的坐标。

这可以取代很多更复杂的物理查询，例如手榴弹在这里爆炸，我需要找到这个圆圈内的所有敌人。我不确定最终是否完美契合，因为 KD 技能树需要经常重新生成——敌人不断移动，所以 KD 技能树需要频繁重建。

您是如何进行移动设备测试和调优的？

FÅ：我们早期做的一件事是确定一款我们认为游戏应该能够在其上运行的设备——一款相当低端的设备，我们希望至少能达到 30 fps。

我们构建了一个自动性能测量系统，可以在其中设置一系列场景。我们总共运行了六种场景。深岩银河：幸存者。我们可以专门按照这种测量模式来编译版本游戏，一旦游戏在设备上启动，它就会进入一个生物群落并运行这六个场景。

一种方法是让玩家保持静止，然后生成一千个敌人向你移动；或者生成500 个敌人，并让你装备所有这些武器，然后自动向各个方向开火。这样我们就能位了解系统运行情况，我们会测量CPU、 GPU、内存——基本上所有能测量的东西都会测量。我们对所有生物群系进行测试，以便查看是否有任何生物群系存在指定的性能问题。

Unity Profiler是我们进行CPU 性能审核的主要工具之一，尤其是在早期我们寻找容易实现的改进和最大收益的时候。

Addressables如何帮助管理移动的内容和内存占用？

FÅ：Addressables是 iPad 达到 3 GB 内存限制的重要组成部分。总的来说，我们先把那些看起来比较简单的事情处理完了。例如，不同的生物群落，你永远不会同时身处多个生物群落中，因此你可以使用所有这些图形资源和设置。

Addressables将异步行为引入到以前完全同步的系统中，而将整个系统重建为异步系统可能是一个相当大的架构挑战，这取决于你的游戏。但在这种情况下，这对我们来说正合适。

为了衡量移动版的成功，你们追踪了哪些性能指标？

FÅ：我们的大部分目标都与绩效相关：我们希望这些机型能达到 30 fps，而这些旗舰机型我们希望达到 60 fps。

在深岩银河：幸存者每当你杀死一只虫子时，就会弹出一堆闪闪发光的蓝色方块，你可以捡起它们来关卡。我们的一个自动测量场景在 10 秒内产生了大约 4,000 个这样的测量值，这在早期造成了严重的性能损失。完成初步优化后，效果就无法再衡量了。

优化敌人的移动和物理特性也显著提高了最低帧率。这变成了流场，以及一长串的Burst作业——每条作业有 10 或 15 个依赖项——负责移动所有敌人，所有这些都在常规物理系统之外。

这款游戏采用程序生成关卡，因此底层和所有墙壁都是由单个物体构建的。由于我们始终以相同的角度进行俯视，因此我们可以轻松计算出可以看到物体的框，收集所有这些物体，并通过我们自己的批次绘制命令将它们发送到渲染器。这对GPU和CPU来说都是很大的改进，因为单独发送所有这些绘制调用会消耗大量的CPU资源。

对于想要将PC游戏移植到移动的开发者，你有什么最重要的建议？

我：关键不在于找到一个万能的解决方案，而在于不同系统之间的协作。

FÅ：当你每帧都要处理数千个实体时，在各种组件之间来回传输数据的成本就会迅速累积起来。如果你能以这样的方式管理你的数据：将所有数据都放在原生容器中，并在整个过程中使用相同的原生容器，你就能从中获得很多收益。

我：从这个项目中我们还获得了另一个重要启示：假设你开发了一款游戏，完成后你意识到你可能应该使用Unity的ECS或任何面向数据的技术栈 (DOTS)系统来构建它。你不需要对整个游戏进行完全转化和重写。我们只使用了Burst编译器和许多原生数据类型。

深岩银河：幸存者可在Steam、 Xbox 、 App Store和Google Play上获取。在Unity博客和Resource中心Check更多Unity开发者的故事。