Ares 対話するがクライアントのアップデートを待たずにライブオペレーションをどのように実行しているか
Adam Axler - Unity
Senior Content Marketing Manager
このウェブページは、お客様の便宜のために機械翻訳されたものです。翻訳されたコンテンツの正確性や信頼性は保証いたしかねます。翻訳されたコンテンツの正確性について疑問をお持ちの場合は、ウェブページの公式な英語版をご覧ください。
ライブゲームを運営することは、定数間ない変化に対応して構築することを意味します。チームは、パフォーマンスと安定性を維持しつつ、新しいイベント、バランス調整、オファー、コンテンツでプレイヤーのエンゲージメントを維持する必要があります。
アレス・対話するは、非常に異なる2つのライブゲームを運営しています。ベースボールヒット26、その7th Inningチームによって開発され、The ウォーキングデッド：Aftermathは、そのSwift Gamesスタジオによって開発されました。Baseball Hits 26 は現実の野球カレンダーに密接に結びついています。ウォーキングデッド:Aftermath は、コアなループを中断することなく拡張できるローグライトの基盤をライブサービスとして構築しています。
私たちは、7th Inningのスタジオ責任者であるアンドレ・タウベ氏と、Swift Games Germanyのマネージングディレクターであるカルステン・グラニグ氏と話しました。彼らは、ライブサービスシステムをどのように構造体し、リモートコンテンツと設定を管理し、イテレーションサイクルを短縮し、両方のゲームが進化し続ける中でモバイルリリースを安定させるかについて私たちに説明しました。
クライアントリリースではなくデータを中心にライブオペレーションを構築する
Baseball Hits 26 は、いつでもどこでも、短い時間でも長い戦略的なプレイでも、野球ファンやゲーマーに本質的な野球体験を提供するように作られています。その親しみやすさは、現実の野球の決定、進捗、ライブイベント、ソーシャルクラブ、コミュニケーション機能と並んでいます。それらのシステムを最新の状態に保つということは、ゲームを単にリリースされたものとして扱うのではなく、常に変化するものとして扱うことを意味します。
例えばプレイヤープレイヤー以下のプレイプレイヤー
「そのレベルの関連性は、当社の機敏でデータ駆動型のサーバーアップデートと、ライブオペレーションチームが適切なマッチアップを迅速にスロットに組み込む能力によって可能になっています」とタウブは述べています。
チームは、クライアントのリリースやサーバーのデプロイを待たずにイベントの変更、販売の保存、オファー、ゲーム内報酬、マッチメイキングの調整を行えるように、独自のバックエンドとライブオペレーションパイプラインを構築しました。
基盤には、プレイヤー、イベント、ストアアイテム、報酬ボックス、バトルパス、その他のシステムを網羅する50以上の設定ドメインを持つカスタムコンテンツ配信およびリモート設定システムがあります。チームは管理パネルを通じて変更を管理します。システムは変更を受け入れる前に検証し、サーバーは再起動なしで数秒以内にそれらを適用します。
すべてバージョン管理され、記録されています。チームは任意の以前のステートをレビューまたはロールバックでき、本番環境に昇格する前に内部テストアカウントに対して変更をステージングできます。
イベントのスケジュール設定も同じ基盤の上に成り立っています。イベント、トーナメント、期間限定セールには開始と終了の期間が定められています。セグメンテーションエンジンはターゲティングを処理し、A/Bテストを強化するため、チームはより広範な展開の前に、オーディエンスの一部で新しいオファーやイベント形式を試すことができます。
実際には、それによってチームはプライムクラブやタワークラブイベントなど、それぞれ独自のボーナスプレイヤーと関連付けられた特集オファーを持つ最大4つのイベントを1週間に開催できます。
「スタック全体を所有していることは、イベントの途中で何か問題が発生したときに最も報われる」とタウブは言います。チームは、問題を診断し、設定を修正し、影響を受けたプレイヤーに補償を行い、すべてを数分以内に、すべて一箇所から[設定]の更新をクライアントにプッシュできます。
コンテンツ配信とモバイルリリースを予測可能に保つ
チームはスタジアムバンドルにAddressablesを使用しています。デフォルトのスタジアムがアプリに1つ含まれているため、初めてプレイするプレイヤーは余分なダウンロードをする必要がありません。チームは、他のすべてのスタジアムをバンドルとしてパッケージ化し、チームのサーバーにアップロードし、プレイヤーが選択したときにオンデマンドでダウンロードします。
チームは、各スタジアムバンドルを最も低終了のデバイスでストレステストし、厳しいなサイズとメモリの予算内に収まっていることを確認しています。共有共通バンドルはスタジアム間で再利用されるアセットを保持するため、同じデータがすべてのダウンロードで重複しません。
予測可能性への同じ強調は、iOSとAndroidのリリースにも当てはまります。チームはプラットフォーム固有のコードを最小限に抑え、両プラットフォームはマイルストーンと提出期限を共有しています。チームは毎日AndroidとiOSのビルドを作成し、テストします。
ほとんどのコンテンツがデータ駆動型であるため、ライブカレンダーはアプリストアのレビュー時期に厳密に依存する必要はありません。
クライアントは、すべてのサーバーコールが失敗する可能性があるという前提に基づいて設計されています。
「ライブゲームに関しては、すべてのサーバーコールをデフォルトで信頼できないものとして扱うべきだ」とタウベ氏は述べている。「クライアントを構造体し、遅い、ドロップする、または応答しないサーバーがプレイヤー体験を損なわないようにする。」
その原則はデバイスのサポートにも適用されます。チームは、サポートする全画面サイズと解像度の範囲でUIカバレッジを確認するためにDevice Simulatorを使用しています。Unity Profilerは、ゲームプレイ中のパフォーマンスの途切れを見つけるためによく使用されます。チームはまた、Wi-Fiの有無にかかわらず、幅広い物理的なAndroidおよびiOSデバイスでパフォーマンスの回帰テストも行っています。
Taubeにとって、モバイルチームはデバイス戦略を早期に決定すべきです。
デバイスサポートのための強固なアーキテクチャ計画に早期に投資してください。特にAndroidでは、ハードウェアとOSバージョンの断片化が真のリスクだからです。
ウォーキングデッドの構築:後始末により、ライブシステムが独立して進化できるようにする
Baseball Hits 26 は現実のスポーツカレンダーを反映するように構築されています。ウォーキングデッド:Aftermathは、その根底にあるローグライト体験を妨げることなく、新しい遊び方を追加するという、異なるライブサービス上の課題を抱えています。
アクションRPGローグライトは、プレイヤーをウォーキングデッドの世界にといざないます。彼らはリック・グライムズ、ダリル・ディクソン、ミショーンを含むサバイバーのチームをビルドし、リアルタイム戦闘でウォーカーや他の敵の群れと戦います。プレイの間、プレイヤーはサバイバーとギアをアンロックし、レベルアップさせ、スキルをアンロックし、基地をビルドします。
「根底にあるのは、The Walking Deadの持つ絶え間ない危険と厳しい選択を描き出しつつ、ローグライトに期待されるリプレイ性と進行性を提供することです」とグラニグは語ります。
ライブサービスは、その基盤の上にチャレンジや制約、さらにアライアンス、協力イベント、Leaderboardsのようなソーシャルシステムを構築しています。
開発の観点から、私たちはそれらのシステムが独立して進化できるようにゲームを構築しました。これにより、コアなローグライトのループを妨げることなく、ライブ体験を拡大し続ける柔軟性が得られます。
10番目のライブ特徴を最初のものと同じくらい安く出荷すること
Swift Gamesはライブサービス基盤をゼロからリビルドしなかった。それは以前のライブタイトルであるHeroes vs Hordesから始まりました。ストア、Economy、Authentication、Analytics、リモート設定、およびクラウドセーブシステムは実績のある技術として見受けられましたが、新しいローグライクのコアは個別にプロトタイプ化された後、その基盤に統合されました。
毎週変更されることが予想されていたものは、クライアントのリリースなしで変更されるように設計されていました。デザイナーはコンテンツを作成し、スプレッドシートでバランスを取り、各バンドルにサポートするクライアントバージョンがスタンプされたリモートバンドルとして公開します。
データはマイグレーションチェーンでバージョン管理されているため、ライブアップ更新で長年のプレイヤーが置き去りにされることはありません。時間はこのデバイスではなくサーバーから来るため、イベントや時間限定のオファーはそのサーバーに依存します。
トレードオフは、ライブ機能はオンにするだけでなく、安全にオフにするように設計する必要があるということです。
「それが、10番目のライブ特徴が最初のものと同じくらい安く出荷できる理由です」とグラニグは言います。
このゲームは主にGameObjectsとNVIDIA PhysXを使用しています。EntitiesとBurstは、敵を動かすA*経路検索システムのために予約されています。
ライブ開発においてより重要なのはスコープ付きDIです。ゲームには、ルート、セーブデータ、メイン画面、ゲームプレイの4つのネストされたコンテキストがあります。各コンテキストは、作成したものとそのクリーンアップに責任を負います。
それは、ライブイベントがインストーラーと、コンテキストに接続された設定ファイルとして構成できることを意味します。そのコンテキストが閉じると、そのアセットとサブスクリプションも一緒に閉じます。
チームはUIとロジックを分離もしています。ショップやオファーは、エンジンを起動することなくテストできるプレーンなC#クラスとして存在でき、デザイナーは設定アセットを直接扱うことができます。
ライブデータとゲームアセットの明確な線引き
ウォーキングデッド:Aftermathは、リモートコンテンツ配信ではなく、メモリ管理とロードを処理します。29のグループが個々の機能に対応しており、それらはゲームのコンテキストとほぼ同じ方法でロードおよびアンロードされます。
ライブコンテンツは、Addressablesではなく、AssetBundles API上に直接構築された別のパイプラインに従います。バンドルはプラットフォームごとにビルドされ、アップロードされ、ゲームがランタイムで取得します。それぞれにハッシュ、チェックサム、および最も古い互換性のあるクライアントバージョンが含まれています。
チームのルールはシンプルです。デザイナーが毎週変更したいのであれば、それはバンドルに入れるべきです。それがアートであれコードであれ、ビルドに含めるべきだ。
その境界内では、チームはストアに戻ることなく、イベントの移動、ゲーム内報酬の再調整、オファーの再調整、機能や購入動作のオン/オフの切り替え、A/Bテストの実行を行うことができます。新しいアートと新しいコードにはビルドが必要です。
「私たちは意図的にその境界を設定しました。そうすることで、ライブのサーフェスが十分に小さく保たれ、何かが壊れたときに何が変わったのかを特定できるようになります」とグラニグは言います。
視覚的な多様性も同様に制御されたアプローチに従います。アリーナは継続的に生成されるのではなく、手作業で構築されています。チームは、既存のジオメトリの素材、ライティング、シェーダーを変更することで、環境を複製する代わりに外観を変更します。そのシステムは、約35のシェーダーグラフと10の手書きシェーダーで構成されています。
「アリーナは手作りなので、プレイヤーが見る可能性のあるすべてを考慮し、サンプリングして期待するのではなく、すべてを測定することができます。」
ウォーキングデッドAftermath | Swift Games studio | Ares 対話する
スプレッドシートからライブゲームへの経路を短縮する
チームのライブオペレーションのスピードの多くはツールから来ています。
デザイナーは設定を自分で編集します。内部インポーターはスプレッドシートから章、テキスト、報酬テーブルを直接取得し、スプレッドシートが真実のソースとなります。
結果：チームがライブ運用またはバランスの問題を発見した場合、完全なリリースプロセスを経る代わりに、約15分で修正をプッシュできます。
ビルドパイプラインはイテレーション時間を短縮するように設計されています。Deep profilingは専用ブランチというよりもビルドスイッチなので、開発者はリグレッションを疑う際に作業中の任意のもののプロファイリングビルドをリクエストできます。キャッシングとビルド時間の最適化は、チームが毎日生成する膨大な数のビルドを処理するのにも役立ちます。
UIの変更が毎週リリースされるため、チームは異なる画面形状におけるノッチとセーフエリアのチェックにデバイスシミュレーターに頼っています。物理デバイスのテストを置き換えるものではありませんが、レイアウトの問題をより早期に検出します。
最も困難な運用上の問題は、開発環境と本番環境を分離することから生じた。Firebaseの設定はビルドファイルに組み込まれており、Firebase、再生 Servicesキー、Facebookの設定、バンドルID、名前、アイコンはすべて一致させる必要があります。
チームは最終的にそれらの環境の責任を継続的インテグレーション（CI）に移行した。開発ビルドとライブビルドでは、同じデバイス上で共存できるように、異なるバンドルID、名前、アイコンを使用します。開発ビルドがライブサーバーに接続すると、ゲーム内の注意が表示されます。設定が欠けている場合に、サイレントに間違った環境をターゲットにするのではなく、アップロードが失敗します。
「責任を人に任せるのではなく、CIに移行させました」とグラニグは言います。
野球ヒット26 | 7回 | Ares 対話する
小さく始めて、早くテストする
両チームとも異なる方向から同じ教訓にたどり着いた。持続可能な生活開発は、何を変える必要があるのかを早期に決定し、何が安定しているべきものからそれを分離し、何かが最終的に間違ってしまうことを前提としたシステムを構築することにかかっている。
Baseball Hits 26の場合、それは、クライアントのリリース、デバイス、サーバーの障害がプレイを中断させないように、実際の野球シーズンに素早く反応できるデータ駆動型のバックエンドを意味します。
ウォーキングデッド:Aftermath、それはモジュラーライブシステム、厳密に制御された設定、そして意図的な境界を意味します。コンテンツはリモートで変更できますが、コードとアートはビルドに含まれます。
グラニグの、初めてのライブモバイルゲームに取り組むチームへのアドバイスは、ライブサービス機構を構築する前にコア体験を証明することです。
他のことを始める前に、1日から3日分のコンテンツをまとめてローンチしてください。それから、翌日何人の選手が戻ってくるか外観てください。「彼らが戻ってこなければ、どんなに終盤のコンテンツがあっても救えない」と彼は説明する。
それならもう一度やりなさい。コンテンツを追加し、3日目を外観て、繰り返します。小さく開始て、早くテストし、数字にゲームが機能しているかどうかを判断させましょう。難しいのは、コアとなるループが証明されるまで、作りたいことすべてに「ノー」と言うことです。
野球安打26とウォーキングデッド：Aftermath がアプリストアとGoogle Playで利用可能になりました。Unity開発者による他のストーリーをUnity BlogとResource Hubでご覧ください。