HologryphがSANDを構築した経緯:ソフィーのレイダーは、持続可能なライブオペのケイデンスのために

Hologryph の場合、SAND の開発は、ソフィーのレイダースは、交互履歴1910年の砂漠の荒れ地を、打ち上げ後ずっと成長し続けることができる抽出ゲームに変えることを意味していました。プレイヤークルーとパイロットのトランプラー ― ― 基地、戦利品保管庫、武器を同時に兼ね備えた巨大な歩行マシン ― ― は、救助を検索て継続的にに生成されたオープンワールドを渡り、互いに乗り合わせていく。

そのエクスペリエンスを提供するには、厳しいオーソリテイティブなサーバーとクライアントの分割、両方で同じように動作するプロシージャルなワールド生成、1つのTramperを構成する数百のEntitiesの同期、そして1台に乗っている感覚を売りにできる滑らかなワールドストリーミングが必要でした。チームはまた、パフォーマンスを不安定にすることなく、新しいコンパートメント、武器、エフェクト、季節の環境を定期的に出荷するのに十分な速さのコンテンツパイプラインを必要としていました。

HologryphのCTO兼ゲームディレクターであるSerhiy Grinets氏に、ゲームを長期的に構築し、コンテンツパイプラインを動かし続けること、そしてこの技術的に野心的なゲームでライブオペレーションを実行するために必要なことを聞いた。

Live opsモデルの外観と、一般的な更新の内容

Serhiy Grinets：SANDのライブオペレーションモデルは、情熱的なコミュニティと共にゲームの進化を維持することに重点を置いています。私たちの優先事項は、新しいコンテンツ、ゲームプレイの改善、バランス調整、バグ修正、および生活品質の変更を組み合わせたアップデートを定期的に行うことです。私たちの最終的な目標は、タイトルを長期的にサポートする持続可能なライブオペレーションモデルをビルドすることです。

コアとなる技術目標は何でしたか？また、それがどのように長期に渡って生き続け、進化するように設計されたゲームを構築するアプローチを形作ったのでしょうか？

大きな目標は3つありました。

• 権威あるサーバーとクライアントの間で厳しいに分割され、プロシージャルなワールドの生成は双方で同一に実行されます。
• 膨大な数のEntitiesを同期する–1つのTramperは数百のエンティティでできている。
• 滑らかななワールドストリーミング – ワールドは本当に大きく、トランプラーに乗る感覚を売るには、どこかで乗る場所が必要です。

トランプラーはゲームのアイデンティティの中心となる存在です。新しいパーツ、化粧品、バリアントを継続的なライブオペレーションコンテンツとして出荷できるように、カスタマイズシステムをどのようにビルドしたのですか。

システム全体がコンパートメントを中心に構築されています。コンパートメントはトランプラーのセクションです。デッキ、キャビン、サポートフレーム、機器室などがあり、すべてのコンパートメントが他のコンパートメントと調和するようにデザインされています。

プレイヤーは以下のブロックからトランプラーを組み立てます。彼らはレイアウトを選び、デッキを積み重ね、装備を配置し、最終的に彼らの基地、保管庫、そして武器という、まさに彼らだけのマシンを終了させます。

開発者である私たちにとっては、これはコンテンツのパイプラインでもあります。新しいコンパートメントを追加するには、モデリングしてコードで設定します。他のブロックと同様に建築システムに接続され、プレイヤーはすぐに自分のデザインに使用することができます。プログラマーは、部品が新しいメカニックを必要としたときにのみ介入し、その場合でも、小さな孤立した作業です。

コンパートメントが完璧なライブオペレーションコンテンツになる理由:新しいものを作るたびにTramlerビルドの可能な数を掛け合わせ、それらは私たちが生産するための安価なものです。

コンパートメントシステムの外観の下のアーキテクチャはどのようなものですか。また、それによって新しいメカのプロトタイプを迅速に作成できるのですか。

プロトタイプを高速に反復するモジュール方式を採用しています。ボンネットの下には、新しい機能をプラグインするためのコントロールコンテナのカスタム反転があり、当社のエンティティコンポーネントシステム(ECS)に非常によく適合しています。さらに、カスタムネットワークエンジンにより、新しいメカニクスを構築する際に、ネットワーキングについてほとんど考える必要がありません。複製はゲームプレイコードの下のレイヤーで処理されます。

UnityのC#Job SystemとBurstコンパイラーは、どのようにパフォーマンスに余裕を与え、退行することなくLive opsコンテンツを追加し続けることができたのでしょうか。

シミュレーションはUnityEntitiesではなく、オープンソースのECSフレームワークであるEntitasの独自の修正バージョンで実行されますが、C# Job SystemとBurstコンパイラーはホットパスにとって非常に重要です。ハイトマップマップとバイオームサンプリングジョブ、トランプラー移動計算、および当社のカスタムオクルージョンカリングを含むプロシージャルなTerrain (地形)生成は、すべてBurstコンパイルされたジョブチェーンとして実行されます。その作品はメインスレッドからオフになるので、より密度の高いワールドはフレームを犠牲にしません。

ライブイベント、季節の瞬間、または達成のマイルストーンのエフェクトをチームですばやく反復させるために、VFX Graphはどのような役割を果たしましたか?

砂塵、煙、盾、武器のエフェクトなど、すべてのエフェクトはVFX Graph上に構築されていますが、キーは使い方です。その上に、マズルフラッシュや弾丸の衝撃のような、サイズ、色、タイミング、破片、煙など、公開されたパラメータの大規模なセットを持つ1つの柔軟なグラフとして存在する設定可能なエフェクトシステムをビルドします。

そのため、新しい武器が入ってきたときに、アーティストはそれらのパラメーターをチューニングするだけで一意のエフェクトを得ることができます。テクニカルアーティストが関与したり、ゼロから新しいグラフが構築されたりすることはありません。その武器のエフェクトをひとつひとつ手作りするのではなく、これらのシステムをより豊かにすることにテックアーティストの時間がかかっています。

それが、安定したコンテンツ頻度での制作に十分なスピードを保つ要因です。新しい武器やイベントは開発ではなく設定のコストで品質効果が得られます。

Live Opsコンテンツパイプラインがスケールアップする中、Unityプロファイラーは最適化ワークフローをどのように形状化しましたか?

クライアントとサーバーの両方で定期的にパフォーマンスを測定し、弱点を見つけて最適化します。Unityプロファイラーのシステムごとの内訳には、時刻がどこに向かっているかが正確に表示されるため、当社のECSのプロファイルは非常に便利です。

また、固定シナリオでパフォーマンスを測定する自動テストも備えており、毎日の傾向を把握して、変化に即座に対応できます。

Addressablesを使用して、ライブコンテンツ更新、ホットフィックス、および季節的なドロップをプッシュするために、クライアントの完全な更新を必要とせずにどのようにしていますか。

Addressablesはメモリ管理のバックボーンです。ワールドはストリーミングされます：プレイヤーが砂漠を走り抜けるとき、コンテンツのロードとアンロードが絶えず行われます。これらすべてはAddressablesを経由するため、プレイヤーがどれだけ遠くへ行ってもメモリは平らなままです。

2つ目の役割は、あまり明確ではないものの、メインのクライアントプロジェクトとサーバープロジェクトの2つの別々のプロジェクトがあり、一方から他方に資産を転送するカスタムソリューションを構築したことです。これにより、両方の環境の整合性が保たれます。サーバーはクライアントと同じデータを見て、同じパイプラインを通して構築されるので 、 「 クライアントで動作し、サーバーで壊れる」コンテンツのバグは、私たちがテストしなければならないものではなく、構造的に不可能です。

Live opsパイプラインの迅速なビルドやメンテナンスに役立つアセットストアツールはありましたか?

Unity Asset Storeからは、オープンワールドに不可欠な砂漠のスキャッターがすべてGPU Instancer Proでレンダリングされ、Amplify Impostorsは遠くのオブジェクトも処理します。Odin Inspectorは、データ駆動型コンテンツパイプラインのキーとなるデザイナー向けツールを強化し、PCとコンソール間の入力をRewiredが処理します。「Easy Save、DOTween、I2 Localizationはすべて、リアルタイムの節約になりました。

Cinemachineは、コンテンツ戦略の原動力となる、共有可能でハイライトに値する瞬間（メックバトル、ビッグプレイ）を捉えるために、どのように取り入れましたか？

Cinemachineの使い方は意図的にシンプルです。カメラを管理し、ゲームプレイカメラ、格納庫、観戦ビューを切り替えます。余分な演出や台本の撮影は、上には一切行わず、意識して選んでいます。砂：『Raiders of Sophie』は一人称視点の非常に競争の激しいゲームであり、カメラの仕事は芸術的ではなく、信頼できることである。

映画品質はゲームそのものから生まれる。2つの巨大な歩行要塞が大砲の砲弾を取引しているとき、あなたは銃を再装填するそれらの1つのデッキに立っています。シミュレーションの叙事詩は撮影です。Cinemachineはカメラが邪魔にならないようにします。

デュアルチャンネルのVivox設定を構築しました。クルーチャットと空間近接チャットです。その設計と実装には何が必要だったのでしょうか。

全てのプレイヤーは同時に2つのVivoxチャンネルにいることになります。通常のクルーチャンネルはクルーがいつも聞いている「ラジオ」で、3D近接音声による位置チャンネルはワールド内の他のクルーから近くのプレイヤーの声を聞くことができます。

位置チャンネルは、Vivox 3Dプロパティ（範囲、フォールオフ、フェードモデル）をコンフィグで調整して使用します。私たちのECSは、スピーカーとリスナーの位置を上限レートでVivoxにプッシュし、1秒間に約20回、プレイヤーが動いたときのみプッシュします。認証は独自のバックエンドトークンサービスを介して実行されます。

音声以外の分野でも、Vivoxはより広範なLive ops戦略にどのような要素を取り入れ、ソーシャルエンゲージメントとリテンションの促進にどのように役立ちましたか?

近接音声は、コミュニケーションだけでなく、私たちにとってのゲームプレイの特徴です。脱出ゲームは、砂漠で会合するクルーが会話したり、交渉したり、チームを組んだり、裏切ったりできる、創発的な社会的瞬間に生きており、近くにいる見知らぬ人の生の声を聞くと、スクリプト化されたシステムではできない緊張が生まれます。クルー無線は チームの連携を保つ

Live ops駆動型ゲームのビルドを検討している開発者へのトップヒントは何ですか？

Live opsゲームの開発はチャレンジングな道のりです。チームが最後までやり遂げる回復力を持ち、信頼できるパートナーやツールがそばにいることを確認してください。コミュニティに密着しましょう。プレイヤーの声にリッスンし、フィードバックから学び、時間の経過とともにゲームがどのように進化するかの形状のヘルプにしてください。

Made with Unityのプロジェクトについては、リソースページをご覧ください。