随着开发者在家工作或在小型工作室工作，游戏资产，包括极其巨大的资产，需要能够随时提供给世界各地的人使用。
译自 How Epic Games Revs up Unreal Engine ‘Cook Time’ for Devs，作者 Cynthia Dunlop 写软件开发和测试的文章时间比她愿意承认的要长得多。她目前是ScyllaDB的高级内容战略总监。
从运行《堡垒之夜》到为《星际迷航：发现号》构建遥远的世界，Epic Games的虚幻引擎大胆地将实时三维图形带到了从未有过的地方。虚幻引擎是一个庞大的多功能开发环境，用于创建游戏和其他实时三维内容。对于创作者来说，可能性几乎是无限的。但支持这个庞大的、高度分布式的创作者社区的技术复杂性也是如此。
Epic Games的高级工具程序员Joakim Lindqvist最近在ScyllaDB峰会上分享了支持该公司社区中快速增长的开发者行列所涉及的内容。他从引擎盖下的游戏开发的角度，以及Epic Games如何架构一个系统，为快速、高效的缓存加速全球大规模游戏资产分发，以加速虚幻引擎的全球分发。
注意：ScyllaDB峰会24的注册刚刚开放！它是免费的，虚拟的和高度互动的，重点关注数据库扩展性能。加入我们，聆听迪士尼/Hulu、Expedia、Oxide Computer (Bryan Cantrill)等的演讲。技术演讲涵盖行业趋势、架构深度解析、经验报告、工程见解和基础设施创新。免费注册。
Lindqvist首先解释说，我们已经熟悉并喜爱的游戏中的所有逼真三维图形实际上可以归结为两个核心要素。首先是游戏本身和围绕它的工具框架中使用的源代码(如虚拟编辑器运行时)。然后，还有各种“游戏素材”：网状3D模型，描述物体表面的纹理，声音，音乐，专用粒子系统等等。这些资产的大小差异很大，从千字节到千兆字节不等。
一个游戏拥有超过500人产出资产并不罕见。在2020年之前，这些人通常集中在各个工作室中，各个工作室都有支持其团队的本地基础设施。然而，COVID-19大流行带来了开发人员主要从家里或世界各地的小工作室远程工作的快速转变。因此，用于单个游戏的所有游戏资产，包括一些非常大的资产，都需要全世界随时可以访问。不仅要确保每个开发者在每天登录时可以访问最新的资产，每当合作者在一天当中添加或更改一些东西时，相关的资产也需要立即在团队中传播。
要了解这里所涉及的内容，请看看如何使用虚幻编辑器构建一个简单的三维场景的图片：
看似简单的柠檬实际上由多个资产组成。有柠檬网格，多个纹理，着色器等。这些只是场景的一小部分。考虑到创造身临其境的虚拟世界所需的所有细节，您可以想象这些游戏资产的数量和范围会快速失控。
增加复杂性的是，这些资产最初以尽可能高的质量格式保存，不幸的是，这种格式不允许它们在编辑器或游戏中呈现。在可以使用之前，这些资产需要经历一个称为“烹饪”的数据转换过程。
Lindqvist解释说，“这些游戏资产通常以通用格式提交到源代码控制中，并需要通过文件格式转换、压缩、编译等方式转换为特定平台(Xbox、PlayStation等)的格式。”这个烹饪过程事先并不真正了解需要哪些资产(当处理父资产时会发现依赖项)。烹饪需要快速的响应时间和高吞吐量访问所有所需的文件。
于是就有了缓存。缓存用于加速游戏烹饪时间。就像您可能会缓存代码编译一样，Epic Games经常依赖这些转换的缓存，即所谓的DDC(派生数据缓存)。
“用户有一个本地DDC，其中包含他们过去转换的资产副本(与一些清理规则)，也有共享缓存，”Lindqvist继续说道。“从历史上看，这些共享缓存依赖于本地网络文件系统在用户之间共享内容。随着团队转移到多个位置，这一直是一个难题。然而，随着团队成员在家远程工作，它变得不可用，因为此系统可以获取大量数据，通过VPN进行操作速度非常慢。”
即使有了这种缓存，跨现在分散的团队进行烹饪最多需要24小时，这对快节奏的开发和协作来说几乎是不可想象的。
为进一步加速烹饪过程，Epic Games在其缓存系统中添加了另一层：一个位于云中的DDC层(故名为虚幻云DDC)。这使得Epic Games能够快速扩展到新的位置，并在世界各地更接近其用户所在的地点部署大量节点。
Lindqvist带我们深入虚幻云DDC的架构。
虚幻云DDC的体系结构图;右侧的框显示了复制
- 该 API 运行在全球多个 Kubernetes 集群中。
- 每个节点都有一个 7TB 的 NVMe 本地驱动器，用于频繁访问的有效载荷的本地缓存。这使其能够快速提供“热”大型有效载荷。但它的容量还不足以存储全部数据集。
- S3 用于存储大多数有效载荷(每个区域约 50 TB，用于两个月的游戏构建)，因为将内容保存在那里的成本非常低。如果请求的有效负载不在本地 NVMe 缓存中，则会从 S3 获取。
- ScyllaDB NoSQL 主要用作元数据的二进制缓存，位于本地 NVMe 和 S3 blob 存储前端。存储在 ScyllaDB 上的内容哈希用于引用保存的 blob。
当上传游戏资产对象时，其元数据作为缓存键进入 ScyllaDB。如果记录小于 64 KB(很多记录都是如此)，则有效负载本身存储在 ScyllaDB 中。大型有效负载进入 S3 存储。
当请求一个对象时，该请求通过 API 发送到 ScyllaDB，ScyllaDB 使用亚毫秒响应时间提供元数据。ScyllaDB 的响应详细说明完成该请求所需的不同文件。下一步是确定相关的有效负载是否可以从本地 NVMe 提供，或者是否需要从 S3 检索。
DDC 中缓存的对象使用一种称为紧凑二进制的自描述二进制格式(概念上类似于 JSON 或 BSON，但具有许多自定义功能)。下面是一个示例:
{
"name": "largeFile",
"size" : 2480,
"attachment": "9fffabc5e0a...1f084f8c5e"
}一个关键的定制功能是attachments，它允许团队将大型资产及其元数据存储在单个对象中，然后控制是否以及何时下载所附资产。单个大型缓存对象可以按需流式传输一些附加资产，而其他资产则从一开始就下载。
Lindqvist如下解释了物流情况：“这些附件是由哈希引用的。我们使用内容寻址方案(这意味着有效负载的哈希用作资产的名称)，这允许我们快速重复使用可能具有描述它们的不同对象的大型附件。我们还支持从一个键到一个对象(输入对象到所产生的结果输出)的任意映射，这在缓存中很常见。”
例如，如果他们发现两个缓存记录都引用了相同的纹理，它们将具有相同的资产哈希，并被视为重复。
“我们不需要复制它，我们不需要存储它两次”，Lindqvist继续说道。“没有必要让客户端下载已经存在的东西，如果缓存已经引用了它，也没有必要上传它。这带来了一些不错的性能提升。”
Epic允许ScyllaDB跨区域执行其复制，但该团队主动选择退出S3的内部复制。它更喜欢如下管理S3存储桶中大型资产的自主复制：“每当我们上传新内容时，我们会将日志写入ScyllaDB，然后我们可以在其他区域中遵循日志来复制对象”，Lindqvist说。
“我们这样做有几个原因：部分是为了控制哪些二进制大对象实际上被复制。(目前我们复制所有内容，但我们有未来的用例将需要部分复制。)此外，当我们自己执行此操作时，我们通常比S3复制得更快。另外，它允许我们执行选择性复制，这将在未来的用例中起到关键作用。”
Epic Games如何为这个新的缓存层选择ScyllaDB？该团队最初在原型中使用DynamoDB，但很快开始寻找更快、更高效的替代方案。DynamoDB易于采用，但他们需要更实用的东西来实现长期目标。在查看ScyllaDB时，他们发现更低的延迟更适合他们的性能敏感工作负载，而且成本也要低得多。此外，实施他们的部分路线图还需要一个可以跨不同云提供商以及本地部署的数据库。
Lindqvist总结道：“这个工作负载非常敏感，所以从我们的数据库快速响应非常关键。这种方法为我们省去了大量麻烦，并且表现非常好。我们已经在Epic内部部署此系统超过一年，并且正在与许可用户合作在他们那里部署此系统。它一直在发挥良好的作用，允许人们的工作效率大大提高。随着资产继续变得更大，[即使]人们仍然可以在家工作。”
有关他们从哈希到在S3中复制大型资产的所有实现的更深入的探讨，请在此查看完整的演讲:
额外福利：如果你渴望了解更多Epic Games的工作，可以去它的GitHub网站看看。也许你自己也会成为游戏开发者。