シードがどのようにワールドをレンダリングするか、プレイヤーは決して建設を停止ない

プレイヤーが何をビルドするか予測することはできません。SEEDに、それが全てであり、核となるレンダリングの課題があるのです。

SEED は、Unityで構築されたKlang Gamesの永続化されたMMOサンドボックスです。それは、プレイヤーがシードリングと呼ばれる自律的なキャラクターを管理し、家やビジネスをビルドし、プレイヤー主導のEconomyで取引を行い、独自の役割と法律を持つ社会を組織する遠い惑星を舞台にしています。プレイヤーがログアウトオフた後もワールドは動き続け、絶えず成長しています。新しい家、店、樹木、苗木はすべて、ハイエンドPCからスマートフォンまでのハードウェアにわたってUnityのレンダリングパフォーマンスにより多くの負荷をかけています。

シミュレーション自体はKlang Gamesのサーバーで実行されます。Unityクライアントの仕事は、サーバーがストリーミングするステートをレンダリングすることなので、そのワークロードはチームが計画したものではなく、プレイヤーが構築したことに依存します。

「SEED は完全にサーバーが権限を持つゲームであるため、クライアントは主にステートを読み取りレンダリングし、クリックやカメラの移動などのプレイヤーの操作を転送します」と、Klang GamesのグラフィックスエンジニアであるArtem Dyadichkinは述べています。

私たちは、シニアゲームエンジニアのDyadichkinとNikita Fetisovに、Universal Render Pipeline (URP)を使用してプレイヤーが構築した社会をレンダリングする方法、数千の小さなオブジェクトを安価に保つ方法、そしてPCとモバイルで実際のプレイヤーデータを使用してボトルネックを見つける方法について話しました。

小さなピースから構築されたワールド

SEEDのアートスタイルは、コードが実行される前に多くのスケーリング作業を行っています。そのゲームは様式化されローポリゴンであり、テクスチャに頼るのではなく、サーフェスデータのほとんどをジオメトリに保存しています。

「私たちの色のデータの大半は、実際には頂点データの中に保存されています」とディヤディチキンは言います。頂点データは、それがどの色であるか、どのマテリアル定義を持っているか（Metalか、滑らかななど）を知っています。それらのすべてはメッシュ自体に組み込まれています。

それはシェーディングとメモリ帯域幅を節約するので、モバイルでは最も重要です。

建物は極端なアプローチをとる。SEED は、各構造体を単一の大きなメッシュとして扱うのではなく、1メートルグリッド上の壁、床、屋根の端、角といった多くの小さなレンガのようなモジュールから建物を構築します。プレイヤーは粗い建築ブロック（ボクセル）を配置し、ゲームはその一つを約15個のモジュールに展開します。そのうち約半分は建物の外装を形成し、残りの半分はプレイヤーが内部を覗き込んだときにのみ生成される内部となります。SEEDの最も賑わう島の一つにある最大の社会は、約12,500のボクセル、または190,000のモジュールからなる172の建物を持っています。

「我々はBatchRendererGroupを利用してそれらをレンダリングし、まとめてバッチ処理し、そのバッチをジョブ経由で実行します」とDyadichkinは言います。レンダリングする必要のあるモジュールは非常に多いにもかかわらず、建物自体は純粋なレンダリングパフォーマンスのボトルネックになったことはありません。

それらのジョブはC# Job System上で実行され、チームはBurst compilerでそれらをコンパイルします。ダイアディチキンは、SEED’のクライアントコードではほぼ常にセットで発生すると言っています。

URPでデフォルトのパスを維持する

SEED は URP を使用して PC とモバイルでスケールし、Klang Games は意図的に Unity のデフォルト設定に忠実に従っています。

「Unityのデフォルトのソリューションに固執するようにしているため、次の更新が来たときには必ず対応できると確信できる」とDyadichkinは述べている。

それは重要です。なぜなら、チームはUnityを年に1回か2回アップグレードするからです。SEEDは現在Unity 6.3で動作しており、プロジェクトの成長とともに新しいレンダリング機能を取り込んでいます。ゲームにカスタムが必要な箇所では、チームはそれを置き換えるのではなく、URPを拡張し、ゲーム固有のエフェクトやインタラクションのためにカスタムレンダラー機能を使用しています。

彼らのShader Graphの使用も同じ原則に従っています。自然アセットはデフォルトのLit shaderを使用し、キャラクターやオブジェクトはカスタムライティングパスを持つUnlitシェーダーを使用します。いずれにしても、チームはURPのパフォーマンス機能を壊す心配はありません。

「Shader Graphを作成すれば、SRP（Scriptable レンダーパイプラインのバッチ処理処理を壊さず、GPU Resident ドロワーも壊さないと確信できます」とDyadichkinは言います。「すべてのURPコア機能が引き続きサポートされていることを確信しつつ、シェーダーで好きなものをカスタマイズするスペースがあるというのは、非常に強力です。」

プレイヤーではなくデザイナーがクライアントにどれだけ描画させるかを決めるワールドでは、そのセーフティネットが重要です。

何千ものオブジェクトとやり取りする

プレイヤーがより密になるほど、社会をレンダリングし、そのどの部分をクリックさせるかが難しくなる。

プレイヤーがズームインしているとき、SEED はピクセルパーフェクトな選択を使用します。カスタムレンダラーの機能は、オブジェクトを別のレンダーターゲット、つまりGPUが画面ではなく描画するオフスクリーンテクスチャに描画します。各オブジェクトは、CPUとGPUの両方が読み取ることができる一意のIDで符号化されています。クライアントは、カーソル下のピクセルを読み取り、プレイヤーがどのオブジェクトの上にカーソルを合わせているかを正確に特定します。

モバイルでは、指先はカーソルよりもはるかに精度が低いため、クライアントは各タップの周囲のピクセルもチェックします。近くに複数のオブジェクトを検出した場合、プレイヤーに選択肢のリストを表示し、密集したエリアでより小さなオブジェクトを選択しやすくします。

プレイヤーがズームアウトすると、GPU選択は広い視野でスケールするのが難しいため、クライアントは物理演算レイキャストに戻ります。

それらのレイキャストの背後には膨大な数のコライダーが存在します。SEED は、シミュレーションのためではなく、それらを素早くブートストラップし、クエリするために Unity Physics を使用します。

「すべての樹木にはコライダーがあり、すべてのオブジェクトや、おそらくすべてのレンガにもコライダーがあり、キャラクターや苗木も同様です」とDyadichkinは言います。「この膨大な数のコライダーを非常に速くブートストラップし、その後、プレースメントチェックやその他の相互作用のためにそれらに対してクエリを実行できます。」

プレイヤーが建物を開くと、内部が表示され、プレイヤーがフロア間を移動したり個々の部屋を検査したりする際に追跡すべきものが増えます。継続的に実行されるジョブが、各オブジェクトが建物の内部にあるか外部にあるか、またどの部屋と階を占めているかを判断します。

「それによって、GameObjectsオブジェクトの使用不可効化や有効化、またはライティングの状況をコントロールするための適切なレンダリングレイヤーの設定など、あらゆる種類のことが可能になります」とDyadichkinは説明しています。

ワールドのプレイヤーが実際に構築したものをプロファイリングする

プレイヤーが構築したワールドの最適化で最も難しいのは、現実的なデータを取得することです。Klang Gamesはライブゲームからそれを得る。

チームは災害回復のためにサーバーのスナップショットを保持しており、プレイヤーが十分に大きな社会を築くと、それらのスナップショットショットはテストケースになります。

「プレイヤーが実際に構築したものを復元し、それをパフォーマンス テストや大スケールな機能テストに使用できる」とフェティソフ氏は述べている。「ゼロから始めるか、データを自前でシミュレーションを行うしようとする代わりに、これらの構築された社会を利用することができます。」

大都市のスナップショットをローカルでロードしたところ、PCで予期せぬCPUレンダリングのボトルネックが発生しました。

「私たちのゲームはほとんどの場合、GPUボトルネックではなく、CPUボトルネックです」とダイアディチキンは言います。「それは、テクスチャがほとんどない、非常に様式化されたローポリゲームです。」

Unity Profilerを使用して、ダイアディチキンはレンダリングスレッドが予想以上に描画コールを送信していることに気づいた。チームはGPU Resident Drawerを使用しているため、Dyadichkinはそのオブジェクトをインスタンス化することを期待していた。フレームデバッガーは異なることを示した。

「我々はハイブリッドバッチ処理ではなく、依然としてSRPバッチ処理に頼っていた」とDyadichkinは述べている。「GPU Resident ドロワーがこれらのオブジェクトをすべてキャプチャしていなかったのは、ほとんどのプリファブにLODグループがあるためだと判明しました。」

SEEDのスケールでは違いが重要です。SRP Batcherは各ドローコールのセットアップにかかるCPUコストを削減しますが、オブジェクトごとに1つ送信します。GPU Resident ドロワーは、メッシュとマテリアルを共有するオブジェクトをインスタンス化されたドローにグループ化し、フレームデバッガーがハイブリッドバッチとしてラベル付けする、さらに高度な機能を提供します。何千もの小さなオブジェクトがある場合、それが多くの軽量な描画コールと少数の大きな描画コールの違いです。

見逃されたオブジェクトの犯人は、アニメーション化されたLODクロスフェードでした。エフェクトは良くなったが、オブジェクトをGPUレジデントドロワーオフ外したままにした。

アニメーション部分は無効にしました。「クロスフェードはまだありますが、今度は手動で設定したトランジションです」と彼は言います。「これで描画コールはインスタンシングされ、CPUレンダリングするスレッドのロードが軽減されました。」

モバイルメモリ内での成熟した社会のレンダリング

モバイルでは、SEEDのレンダリングが異なるコンストレイントにヒットしました。「モバイル側では、CPU 依存ではなく、メモリ依存です」とフェティソフは言います。それが我々のプロジェクトの主な障害です。

成熟した社会は、膨大な数の建物、屋外オブジェクト、キャラクター、メッシュを含むことができます。クライアントがレンダリングするすべてのメッシュとマテリアルは、まずメモリに収まる必要があります。Klang Gamesは、そのメモリがどこへ行くかを追跡するために、Memory Profilerとmemory snapshot comparisonsに大きく依存しています。チームは、破損したリファレンス、同じマテリアルを重複させたAddressables依存関係、そして必要以上に大きすぎるC#のコレクションのために、テクスチャが3回保存されているのを発見しました。

「デスクトップでは問題なく、人々もあまり気づかなかった箇所が、モバイルでは大きな問題になった」とフェティソフは言います。「私たちはUnity Memory Profilerにかなり頼っていました、特に[メモリ]スナップショットの差分を。」

テクスチャがなくても、ジオメトリは積み重なります。

「メッシュの中にはかなりゴツゴツしているものがあり、特に木々がそうでした」とフェティソフは言います。すべてのLODをロードすると、単一の樹木がメガバイトのメモリを消費し、多くの樹木のバリエーションがあります。

チームがAddressablesをプラットフォームごとにビルドするため、ゲームコードを変更することなくモバイルに簡素化されたツリーを送信できます。「デスクトップで椅子を読み込むのと同じコードが、モバイルでも椅子を読み込みます」とフェティソフは説明する。「しかし、Addressables自体はモバイル向けに最適化されたアセットになり得ます。」

より大きなシフトは、モバイルでのLODグループの完全な置き換えでした。クラシックなLODは、オブジェクトタイプごとに複数のメッシュをメモリに保存することを意味していました。これは、フェティソフが木について説明しているのと同じコストです。Unity 6.2で導入されたMesh LODは、各レベルの詳細を単一のメッシュ内に格納し、SEEDのモバイルバリアントは現在これを排他的に使用しています。また、クラン・ゲームズの小規模なアートチームの作業負荷も軽減しました。

「LODからメッシュLODへの切り替えは、ゲームワールドをモバイルデバイスでレンダリング可能にするための重要なステップでした」とフェティソフは述べています。

プレイヤーが次にビルドするものを想定した設計

SEEDのコアレンダリングの課題は消えない：プレイヤーはクライアントに何を描画かを決め、彼らは構築を停止ません。「これは、プレイヤーが作成するワールドに対して私たちが思い描く視覚的忠実度性と、低終了デバイスでの安定したフレームレートとの定数間ないバランスなのです」とダイアディチキンは言います。

Klang Gamesはプレイヤーが次に何をビルドするかを予測することはできませんが、すでにビルドしたものに対してテストすることはできます。

「初日からターゲットのスケールに合わせて設計、ビルド、テストを行うべきだ」とフェティソフは述べている。「早い段階で現実的な負荷に対するプロファイリングを行い、それを継続してください。」

シード は早期アクセスで利用可能です。Unity開発者による他のストーリーは、Unity BlogやResource Hubをご覧ください。