Voxel Streams と World Snapshots: 高パフォーマンスな User Generated Content Backend アーキテクチャのエンジニアリング

プレイヤーが Voxel RPG で 40 時間かけて空中大聖堂を建設しました。そして今、それを 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 アーキテクチャの技術的負債に対処しなければならないことを意味します。

Voxel に大きく依存する Enshrouded のようなゲームにとって、課題は二重です。Voxel は無限の創造性と完全な破壊を可能にしますが、膨大な量のデータを生成します。非常に詳細なベース 1 つで、生の Voxel データが 50MB を簡単に超えることがあります。それを 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 (圧縮): Payload を削減するために LZ4 や Zstandard などのアルゴリズムを適用する。

これを正しく処理しないと、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 を数キロバイトに削減できます。

Backend パイプラインのエンジニアリング

クライアントが圧縮された Snapshot または Delta を生成すると、Backend が引き継ぎます。堅牢な User Generated Content Backend アーキテクチャは、Ingestion Layer (受信レイヤー)、Storage Layer (ストレージレイヤー)、Discovery Layer (検索・発見レイヤー) の 3 つの主要な層で構成されます。

1. Ingestion Layer (バリデーションとウイルススキャン)

クライアントを決して信用しないでください。悪意のあるユーザーが、実際にはゼロで埋め尽くされた 2GB のファイル (Zip Bomb) や、Voxel デシリアライザーの脆弱性を突くように設計された Payload である「Snapshot」をアップロードする可能性があります。受信サーバーは以下のことを行う必要があります：

• ストリーム全体を受け入れる前に、ファイルヘッダーとサイズを検証する。
• Payload をサンドボックス内のデシリアライザーで実行し、サーバーがクラッシュしないことを確認する。
• 重複アップロードを防ぐために、一意の Content Hash (SHA-256 など) を生成する。

2. Storage Layer (Blobs vs. Metadata)

バイナリデータ (Voxel Blob) と検索可能なデータ (プレイヤー名、冒険タグ、評価) を分離します。

• Blobs: S3 互換のオブジェクトストレージを使用します。トラフィックの多いゲームでは、Content Delivery Network (CDN) を使用して、これらの Blob をエッジでキャッシュします。
• Metadata: インデックス作成には PostgreSQL などのリレーショナルデータベースを使用します。これにより、プレイヤーは「ハイファンタジー」や「レベル 10-20」の冒険をミリ秒未満のレイテンシで検索できるようになります。

3. Discovery Layer (リアルタイム更新)

新しい冒険が公開されたとき、他のプレイヤーにすぐに見てもらいたいものです。クライアントに 30 秒ごとに API をポーリング (Polling) させるのではなく、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: メタデータテーブルが数百万行に達したときのため。
• CDN Invalidations: プレイヤーが冒険を更新したときに、古いバージョンがキャッシュから提供されないようにするため。

これを自前で構築するには、通常、専任のシニアエンジニアが 2〜3 か月かかります。ここで horizOn が大きな価値を提供します。バイナリ Blob ストレージやメタデータインデックスのための「配管」を構築する代わりに、horizOn は設計済みの UGC モジュールを提供します。Metadata Schema を定義するだけで、horizOn がグローバル配信、ファイル検証、スケーリングを自動的に処理します。これにより、S3 バケットポリシーを心配するのではなく、「Adventure」のゲームプレイを楽しくすることに集中できます。

UGC Backend アーキテクチャの 5 つのベストプラクティス

1. コンテンツ・アドレッサブル・ストレージ (CAS) の実装: Voxel データのハッシュをファイル名として使用します。2 人のプレイヤーが同一のベースを共有する場合、物理ファイルは 1 回だけ保存されるため、膨大なストレージ容量を節約できます。
2. 非同期インジェクションの使用: Backend がファイルを処理する間、プレイヤーを待たせないでください。すぐに「202 Accepted」を返し、バックグラウンドワーカーを使用してバリデーションとサムネイル生成を処理します。
3. 階層化ストレージ戦略 (Tiered Storage): 最も人気のある上位 100 の冒険を「Hot」キャッシュ (Redis/CDN) に保持し、プレイされていない古い冒険を「Cold」ストレージ (S3 Glacier) に移動してコストを抑えます。
4. スキーマのバージョン管理: ゲームを更新するにつれて、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