Voxel Streams 与 World Snapshots: 设计高性能 User Generated Content Backend 架构

玩家刚刚花了 40 小时在你的 Voxel RPG 中建造了一座浮空大教堂，现在他们想将其分享给 10,000 名陌生人——你的 Backend 准备好支付 4TB 的 Egress 账单了吗？大多数开发者将 User-Generated Content (UGC) 视为简单的文件上传问题，但当你处理像 Enshrouded 这样的 Voxel 世界时，技术现实要复杂得多。你不仅是在托管一个文件；你是在构建一个分布式世界状态同步系统 (world-state synchronization)，它必须保持高性能、高性价比且安全。

独立游戏的“蟹化”：从游戏向平台的转变

Enshrouded 最近的“Forging the Path”更新引入了 Adventure Sharing 功能，允许玩家打包其世界状态并分享给社区。这一举措凸显了行业内一种被称为“Roblox 事件视界”的增长趋势。游戏不再是静态的体验；它们正在成为创作平台。这种游戏的“蟹化”意味着无论你的游戏类型如何，如果你想要长期的 Player Retention，你最终都必须处理 User Generated Content Backend 架构的技术债。

对于像 Enshrouded 这样高度依赖 Voxel 的游戏来说，挑战是双倍的。Voxel 允许无限的创造力和完全的可破坏性，但它们会产生海量数据。单个高度精细的基地很容易超过 50MB 的原始 Voxel 数据。乘以 100,000 名玩家，仅存储成本就能在游戏发布 1.0 版本之前让你的工作室破产。

Voxel 数据 Payload 问题

要了解如何为此设计 Backend 架构，我们首先需要看看实际分享的是什么。在 Voxel 引擎中，世界通常被划分为 Chunk（例如 16x16x16 或 32x32x32）。每个 Chunk 包含 Voxel ID、光照数据，通常还有箱子或制作台等实体的 Metadata。

当玩家“分享冒险”时，游戏必须执行“World Snapshot”。这不仅仅是复制粘贴存档文件夹。它需要：

1. Pruning（裁剪）： 删除不需要包含在分享版本中的瞬时数据（如掉落物品或活动的怪物 AI 状态）。
2. Serializing（序列化）： 将内存中的 Octree 或网格结构转换为 Flat Buffer。
3. Compression（压缩）： 应用 LZ4 或 Zstandard 等算法来减小 Payload。

如果你处理不当，就会遇到 The Unreal Engine Multiplayer Sync Bug Ruining Your World States And How To Fix It 中描述的问题，即客户端与共享快照之间的世界状态不匹配导致结构损坏或出现“幽灵”Voxel。

Delta Compression：只传输变化的部分

UGC 架构中的一个常见错误是每当玩家对其分享的“Adventure”进行微小更新时，就上传整个世界状态。相反，你应该实现 Delta Compression。通过将 Voxel Chunk 的当前状态与“Base World”（程序化种子）进行对比，你只需要存储修改部分（Delta）。

如果基础世界显示 Chunk (10, 5, 2) 是一座实心山，而玩家在其中挖了一条隧道，你的 Backend 只需要记录替换了“石头”Voxel 的“空气”Voxel。这可以将 10MB 的 Chunk 减小到几 KB。

工程化 Backend 流水线

一旦客户端生成了压缩的 Snapshot 或 Delta，Backend 就会接管。一个健壮的 User Generated Content Backend 架构由三个主要层组成：接入层 (Ingestion Layer)、存储层 (Storage Layer) 和发现层 (Discovery Layer)。

1. 接入层 (验证和病毒扫描)

永远不要信任客户端。恶意用户可能会上传一个实际上是填充了零的 2GB 文件（Zip Bomb）或旨在利用你的 Voxel 反序列化漏洞的 Payload。你的接入服务器必须：

• 在接受完整流之前验证文件头和大小。
• 通过沙盒反序列化器运行 Payload，以确保它不会导致服务器崩溃。
• 生成唯一的 Content Hash（如 SHA-256）以防止重复上传。

2. 存储层 (Blob vs. Metadata)

将二进制数据（Voxel Blob）与可搜索数据（玩家姓名、冒险标签、评分）分开。

• Blobs： 使用兼容 S3 的对象存储。对于高流量游戏，使用内容分发网络 (CDN) 在边缘缓存这些 Blob。
• Metadata： 使用 PostgreSQL 等关系型数据库进行索引。这允许玩家以亚毫秒级的延迟搜索“史诗奇幻”或“10-20 级”冒险。

3. 发现层 (实时更新)

当新的冒险发布时，你希望其他玩家立即看到它。与其让客户端每 30 秒轮询 (Polling) 一次 API，不如使用 WebSockets 推送新内容通知。要深入了解如何设置，请查看我们的指南：Ditch Http Polling An Unreal Engine Websockets Tutorial For Real Time Backends。

实现：C# UGC 管理器示例

下面是一个如何在基于 Unity 的游戏中构建 UGC 上传管理器的简化示例。此代码处理压缩和分片上传过程，以确保大型 Voxel 文件不会在慢速连接上超时。

using System;
using System.IO;
using System.IO.Compression;
using System.Threading.Tasks;
using UnityEngine;
using UnityEngine.Networking;

public class AdventureUploader : MonoBehaviour
{
    private const string API_URL = "https://api.yourgame.com/v1/ugc/upload";

    public async Task ShareAdventure(string adventureId, byte[] rawVoxelData, AdventureMetadata metadata)
    {
        // 1. 本地压缩数据以节省带宽
        byte[] compressedData = await CompressData(rawVoxelData);
        Debug.Log($"Compressed world state from {rawVoxelData.Length / 1024}KB to {compressedData.Length / 1024}KB");

        // 2. 创建多部分表单
        WWWForm form = new WWWForm();
        form.AddField("adventureId", adventureId);
        form.AddField("title", metadata.Title);
        form.AddBinaryData("worldBlob", compressedData, "world.vox", "application/octet-stream");

        // 3. 发送到 Backend
        using (UnityWebRequest www = UnityWebRequest.Post(API_URL, form))
        {
            var operation = www.SendWebRequest();
            while (!operation.isDone) await Task.Yield();

            if (www.result != UnityWebRequest.Result.Success)
            {
                Debug.LogError($"UGC Upload Failed: {www.error}");
            }
            else
            {
                Debug.Log("Adventure shared successfully!");
            }
        }
    }

    private async Task<byte[]> CompressData(byte[] data)
    {
        using (var outputStream = new MemoryStream())
        {
            using (var gZipStream = new GZipStream(outputStream, CompressionMode.Compress))
            {
                await gZipStream.WriteAsync(data, 0, data.Length);
            }
            return outputStream.ToArray();
        }
    }
}

[Serializable]
public class AdventureMetadata
{
    public string Title;
    public string Description;
    public string CreatorId;
}

自主研发的成本

手动构建此流水线是一项重大任务。你需要管理：

• Load Balancers： 处理知名主播分享冒险时产生的流量激增。
• Database Sharding： 当你的 Metadata 表达到数百万行时。
• CDN Invalidations： 确保玩家更新冒险时，旧版本不会从缓存中提供。

自主研发通常需要高级工程师投入 2-3 个月的时间。这就是 horizOn 的巨大价值所在。与其构建二进制 Blob 存储和 Metadata 索引的“基础设施”，horizOn 提供了一个预先架构好的 UGC 模块。你只需定义 Metadata Schema，horizOn 就会自动处理全球分发、文件验证和扩缩容。这让你能专注于让“Adventure”玩法变得有趣，而不是担心 S3 Bucket 策略。

UGC Backend 架构的 5 个最佳实践

1. 实现内容寻址存储 (CAS)： 使用 Voxel 数据的哈希作为文件名。如果两个玩家分享了相同的基地，你只需存储一次物理文件，从而节省海量存储空间。
2. 使用异步接入 (Asynchronous Ingestion)： 不要让玩家等待 Backend 处理文件。立即返回“202 Accepted”，并使用后台工作线程处理验证和缩略图生成。
3. 分层存储策略： 将前 100 个最热门的冒险保存在“热”缓存 (Redis/CDN) 中，并将较旧且无人游玩的冒险移动到“冷”存储 (S3 Glacier) 以降低成本。
4. Schema 版本控制： 随着游戏更新，你的 Voxel 格式会发生变化。Backend 必须在每次上传时存储一个 format_version 整数，以便旧的冒险可以平滑迁移或弃用。
5. 对一切进行速率限制 (Rate Limit)： UGC 是对游戏服务器进行 DDoS 的最简单方法。对单个 IP 或 PlayerID 上传或搜索内容的频率实施严格的速率限制。

结论：共享世界的未来

正如 Enshrouded 所展示的，独立游戏的技术门槛正在提高。玩家期望能够无缝分享他们的创作，“Adventure Sharing”正迅速成为一项标准功能而非奢华。通过在开发初期关注健壮的 User Generated Content Backend 架构，你可以避免当社区规模超过基础设施承载能力时带来的痛苦重构。

准备好在不增加服务器管理负担的情况下扩展你的多人游戏 Backend 了吗？免费试用 horizOn 或查看 API 文档，了解我们如何处理大规模 UGC 和世界状态持久化。

---

来源：Enshrouded approaches the Roblox event horizon with the addition of Adventure Sharing in its latest update