Inside Infinite 7月号 全訳①
訳者まえがき
今月号は来週末にでも行われる Halo Infinite のβテスト（Inside Infinite では flight と呼ばれる）の詳細について書いてあり、またそれ以外にも開発チームがβテストで何を意識しているのか、どういったことを知りたがっているのかなど、非常におもしろいコンテンツばかりだったので訳した。
特に普段からこういった翻訳活動などしているわけではないので、間違ってる部分もあると思います。興味が出たら原文である Inside Infinite - July 2021 を参照してもらえれば。また、訳のミスなど教えていただければ適宜修正しますのでよろしくお願いします。
本編
Inside Infinite 最新号へようこそ。このブログシリーズでは毎月 Halo Infinite の開発状況を詳しく解説しています。今月は "flighting" とも呼ばれているマルチプレイヤーのテクニカルプレビュー（βテスト）について、その目標やプロセス、ベータテスターの皆様に期待してほしいことなどを紹介します。また、今回のテクニカルプレビューで重視する Bot と Weapon Drills という2つの新機能についても、これらがどのような機能なのか、どのような体験ができるのか詳しく紹介します。
今年はすでに多くの Inside Infinite のバックナンバーがあります。Halo Infiinte の開発状況についてもっと知りたい方はぜひご覧ください。
HALO INSIDER
登録方法
・ゲーマータグを Halo Insider に登録する
・Halo Insider のプロフィールに記載したメールアドレスの確認を行う
・“I would like information, tips, and offers about the Halo franchise.” にチェックを入れる
このチェックと前ステップのメールアドレスの確認を行わないと、flighting に関するメールを送信することができません
・参加したいプラットフォームを選んで flighting に参加する
PC で flighting に参加したい場合、DxDiag のアップロードと Steam アカウントの連携が必要です
Halo Insider に登録しても、テクニカルプレビューやプレリリースハンズオン（flights、たぶん Stable 版ぐらいの立ち位置）への参加が確約されるわけではありませんのでご注意ください。テストに参加できるテストプレイヤーの数や選出基準は、テストで確認したい範囲や目的によって異なります。テクニカルプレビューではテストの全体目的と深く関わる同時接続数の目標(?; concurrency targets)があり、それに従って招待すべきテスターの数が決まります。その数の範囲内で、まず各プラットフォームのプレイヤーを幅広く参加できるようにすることを優先し、次に Insider program への参加期間が長いプレイヤーを優先するなどして、すべての枠を使い切るまで招待を行います。
私たちはコミュニティ全体のサポートと関心の高まりに興奮しています。また、Halo Insider のデータベース（たぶん登録者数）が大幅に増加したことは、サービスとシステムをさらに強化するための素晴らしいきっかけです。ですが、それでもすべてのプレイヤーに Halo Insider の招待状が届くわけではありません。特に初期のテスト段階では急ぎでテストを進めるのではなく、慎重に進めるアプローチを取っています。私たちはリリースまでのテストの回数を増やし、コンテンツやテスト参加者の範囲を拡大することを目標にしています。今回、招待状が来なかった方も、次回以降の参加の機会まで楽しみに待っていてください。
それでは、ここからは Halo Infinite の flight の開発やサポート、運用に何が必要なのか、その奥深くを見ていきましょう。
COME FLY AWAY WITH US
ゲーム開発に着手する前、私たちのチームはゲームとプレイヤーのニーズを特定すること、そのニーズを満たしているか確認できる目標とマイルストーンを設定すること、そして実際に設定した目標を達成できているか確認する最善の方法を考えることに時間を費やしています。ゲームを作る前に、このような観点で徹底的に考え抜き開発計画を立てています。
ここ数年、Halo:TMCC のアップデートや PC への移植を行った際も、このプロセスは非常に重要な役割を果たしました。このプロセスと Halo Insiders （テストプレイヤー）とのパートナーシップは、MCC の継続的なシーズンごとのアップデートの基礎となっています。このパートナーシップとプロセスがなければ、MCC でできた素晴らしい出来事は実現しなかったと言っても過言ではありません。
さて、今このプロセスを Halo Infinite に適用してみると、Halo Infinite のゲームとコアサービスを大規模にテストし、ゲームの発売前にプレイヤーからフィードバックを得るのが目標になりました。次に、これらの目標に対する進捗をどのように測るかを検討しました。例えば「マッチメイキングの成功率を100%にしたい」という仮の目標を立ててみます。これは素晴らしい目標ですが、この目標を達成しているかどうかを正確に測定するシステムを構築する必要があります。詳しく言うと、ゲーム自体や、オンラインサービスにマッチが成功したかどうか判定・監視する機能を付け足し、失敗したときには報告する機能を足すことを意味します。
私たちの設定した大きな目標は、プレイヤーが実際にゲームをプレイしたときに何が起きるかに関わっているため、Halo Insiders によるテクニカルプレビューの実施が最適だと考えました。Halo Insiders と一緒に非常に大規模な flight を実施することで、オンラインシステム（マッチメイキングやチャレンジ(?)など）が意図したとおりに機能しているかどうか判断するための、大量のゲームのプレイデータを得ることができます。また、世界中のあらゆる種類のプレイヤーからのフィードバックを集め、それらを検討する機会にもなります。
ここまでは、Halo Insiders と”なぜ”テクニカルプレビュー（flights）を実施するかについて話してきました。ここからは「テクニカルプレビュー」の本当の意味と、チームの具体的な目標について見ていきます。
TECHNICAL PREVIEWS, FLIGHTS, AND BETAS
各名前にどんな意味があるのでしょうか？ ゲーム業界では様々なゲームが発売前に体験版をリリースしたり、テストを行ったりしていますが、その際に様々なラベルがつけられています。”アルファ”や”ベータ”というラベルには、ゲームの完成度や安定性、マーケティングに関わる項目をテストしたいといった意味があります。私たちは現状、アルファよりは進んでいますが、ベータに期待されるような完成度には達していません。
私たちはこの状態を特に「テクニカルプレビュー」と呼んでいます。この呼名は、私たちの目標や、開発途中の今のゲームの状態、そして Insiders が体験するであろうことを最もよく表していると感じています。以下に紹介するように、私たちの原動力と目標はまさに技術的なものです。年末にゲームが発売されたときの爆発的なアクセスに備えて可能な限りの準備を整えるため、これまで私たちが開発してきたものを超える大規模なシステムやサービスを開発したいと考えています。フィードバックやその他の知見は確かに貴重ですが、何よりもまずいちばんに Halo Infinite の技術面についてのテストや負荷の確認を行っています。
また、今回のゲームのバージョンにはいくつかのバグや作りが粗い部分があることを、率直に伝えておきたいと思います。私たちは、設定した目標を達成するためのテスト版の開発とテストプレイヤーたちの楽しい体験を確保するために懸命に取り組んできました。しかし、それでもこれはまだ未完成の状態であり、テクニカルプレビューの期間中、程度の差はあれ、いくつかの障害が発生することが予想されます。なお、今回のテクニカルプレビューは、リリースまでに行う必要があるすべてのステップやプロセスの時間を考慮すると、メインのゲーム開発より2ヶ月ほど遅れています。
私たちが把握している主な問題はすべてリストアップされ公開されるので、参加者は何を期待し何に注意すべきかテストに参加する際把握できます。もちろん、それ以外の新たな問題についてバグレポートなどを集めることも、この規模の flight では非常に有効です。私たちが全力を尽くしても、実際に大量のプレイヤーが参加してくれる大規模なテストに代わるものはありません。
最後に、このブログでも何度か紹介していますが、flighting という言葉は多くの業界ではまだ知られていません。私たちは flighting を単に発売に向けて Work-In-Progress 版を体験可能な状態でリリースすることとしています。flight は発売時に最高の体験をユーザに提供するという最終目的のため、リリース前の開発中に、特定の目標の達成を目指し、データと結果を検討し、反復して繰り返すプロセスのことです。
それではここからは 343i が Halo Infinite のテクニカルプレビューで設定した主な目標を見ていきましょう。
TEST THE GAME AND OUR CORE SERVICES AT SCALE
私たちが確認したいのは、ゲームとそれを支えるすべてのサービスが期待通りに動作していることです。特に、テクニカルプレビューという非常に沢山のプレイヤーが参加し、負荷が高い状態で確認したいと思っています。Halo Insiders に体験版を提供することで、プレイヤーがオンラインサービスに不具合を発見したり、ゲーム内に新たなバグを発見することを見ることができます。このプロセスのすばらしいところは、発売前の数ヶ月前に問題の大小を問わず発見することが意図的にできることです。発売前に問題に対処しておくために、今のうちから問題を発見しておきたいのです。
今回のテクニカルプレビューではどのようなどのような点に我々が注目しているのか、次に説明します。
GAME & SERVICES PERFORMANCE FOCUS AREAS
・安定性：様々なスペックのハードウエアやプラットフォームごとのゲームの安定性。特定の時間帯や特定のハードウエアでゲームがクラッシュしたりフリーズすることはないか。実際のハードウエアのプロファイル（実際に使われているハードウエアの種類やそれ上でのゲームの動作状況など）を収集することは、このような大規模な flight でしか達成できないことであり、初めて PC でゲームを発売する我々にとって非常に重要な課題です。
・オンラインサービス：複雑に連携しているすべてのオンラインサービスが、非常に多くのプレイヤーがいる状態でうまく機能するか。これは完璧な連携が求められる非常に多くのサービスを扱う、私たちの最大の確認事項です。具体的には、マッチメイキング、サーバのスケーリング、適切なコンテンツを提供するプレイリスト、チャレンジ、ゲーム後のスタッツ、バトルパスの進行とストア機能、アーマーのカスタマイズ機能、友達とのパーティ機能が動作するかを確認します。
・Halo Insider / Waypoint vNext：Halo Insider のコミュニケーションツールや filght 配布ツールはスケールするか。Waypoint vNext アプリ（iOS / Android）と Waypoint のブラウザ上での体験は、ゲームの延長としてどのように機能し、どのような体験を与えるか。
MEASURING GAME PERFORMANCE
私たちのチームは、ゲームのクラッシュやマッチメイキングの失敗など、考えられるほぼすべてのシナリオを想定し、それらに関わる情報を収集するためのツールを開発してきました。大規模テストは、私たちが開発中に集めたデータと、実際にゲームが様々なプレイヤーにプレイされたときのデータを比較する唯一無二の機会です。また、非常に多くのプレイヤーが参加した状態で、ゲームの安定性とパフォーマンスの測定することはゲーム発売前に必要不可欠です。
次に、チームメンバーがこれからのテクニカルプレビューで何をどのように見ているかについて説明します。
WHAT ARE YOU/YOUR TEAM MONITORING DURING FLIGHTS?
Sam Hanshaw：ライブチームのプロデューサー。マッチメイキングの成功率とサーバ稼働率を常にチェックしています。なぜなら、マッチできないとそもそもユーザがゲームをプレイできないからです。また、どれだけのマッチが最後までプレイされたのかや、プレイ中にクラッシュする人数についてもチェックしています。
Brian Dunn と Brian Hughes：前者はマルチプレイヤーのテストリーダー、後者はライブテストリーダー。テストチームは多くの項目をチェックしています。まず、全体的なクラッシュや安定性です。これらはプラットフォームごとに分析し、もっとも頻発するクラッシュを特定し、既知の原因と新たな現任に区別します。全体的な安定性を定量化する指標として「MTTF；Mean Time to Fail」や「ゲームプレイ1000時間あたりのクラッシュ数」などを使っています。
次に、マッチメイキングに関わる項目として、信頼性、ロード時間、スキルマッチングについても見ています。さらに、デディケーテッドサーバのパフォーマンス、ゲーム自体のパフォーマンス（特にスペックの異なる PC ごとパフォーマンス）、ネットコードの品質なども精査しています。Halo Infinite ではスパルタンのカスタマイズを重視しているため、バトルパスの進行度合いやチャレンジの消化具合など、どのカスタマイズがアンロックされ使用されているかなどにも注目しています。
最後に、サポートチームと協力し、バグレポートを確認し、テレメトリと比較してプレイヤーが実際に直面する問題や影響範囲を把握しています。また、Halo Waypoint のフォーラムや Reddit、Twitch などの SNS にも潜み、噂話や報告にも目を光らせています。
Nate Jones：サービス・ライフサイクルチームの開発リーダー。もし filght のすべてがうまくいっていれば、私は監視モニターやログに張り付くことはありません。一緒に flight に参加することさえできるでしょう。flight の間はロビーに関する以下の情報、バックエンドサービスのパフォーマンスや状態、デディケーテッドサーバの使用率、プレイヤー接続数、マッチメイキングの接続数などを確認しています。たまに、テスト中の中間調査やログの調査を行うこともあるでしょう。ただ、私と私たちのチームのメインの監視作業のほとんどは flight 終了後に行われます。flight 後の計画では、ロビーやスキルサービスのログにエラーや警告、その他想定外のものが含まれないかを徹底的に調べます。これに加え、flight 中に実施していたいくつかの実験についても精査します。
Jeff Guy：PCチームのプロデューサー。Brian Dunn を監視するつもりです。私は彼と対戦するたびにボコボコにされますから。冗談ですｗ
Halo Infinite はプレイヤーの環境に合わせて様々な項目が設定できるようにしています。たとえばハードウエアやデバイスなどに関わる項目です（フレームレートの値とか、解像度、入力デバイスなど）。PCチームはこのようなプレイヤーの異なる環境ごとに、ゲームがどのような状態にあるかを監視します。例えば、フレームレートの低下や、特定のハードウエアの組み合わせで発生するクラッシュなどです。さらに、これらの情報をウルトラワイドの設定をしている人数、4Kや8Kの解像度を使っている人数、フレームレートを144に固定してプレイしている人とアンロックしてプレイしている人、プレイヤーはどのようなカスタムキーバインドを選択しているのか、といった情報と組み合わせていきます。PCプレイヤーが Halo Infinite を思い通りにプレイできるようにすることが私たちのすべてであり、それに関わる問題が発生しないかどうか注意深く見守っています。
HOW DO YOU/YOUR TEAM MEASURE THAT INFORMATION?
Sam Hanshaw：サービスのヘルスダッシュボード（サービスの稼働状況を一覧で示すページ）にはマッチメイキングのエラーや、クラッシュの情報が表示されます。また、サーバログにはたくさんの情報が蓄積されており、チームは調査の際に何がいつ起こったのかを調べられます。また、サポートチームが受け取ったバグレポートなどを flight 終了後に精査し、プレイヤーの体験の全体像を把握します。これらのレポートは問題の追跡に役立つだけでなく、どんな問題がどのくらいの人々を悩ませているのか、またそれがどのぐらいの頻度で起こっているかを知る上で非常に重要な役割を持ちます。
Brian Dunn & Brian Hughes：私たちは重要な情報をチームにフィードバックし、リアルタイムに、また事後に監視するためのツールとシステムを用意しています。プレイヤーがゲームのクラッシュに会うと、Watson と呼ばれるシステムが詳細なレポートを社内のクラッシュレポートサイト「Ticket Track」にアップロードします。Nate やサービスチームと同様 Kusto （後述）も使用しています。Kusto は受信したデータを解析し、レポート作成に役立つ情報に変換してくれます。レポートといえば、可視化が必要なデータには Power BI reports を利用し、バグ追跡のために Azure DevOps database にフィードしています。私たちのチームはこれらすべてのソースからのデータを利用し、flight の品質を把握し、実施中の flight や次の filght のために必要な改善を行っています。
Nate Jones：私たちは Kusto（Azure Data Explorer）をアドホックなデータ解析のために利用しています。私は、サービス、デディケーテッドサーバ、クライアントのテレメトリイベントを結合するクエリの作成に多くの時間を費やしました。私たちは Geneva と呼ばれる Microsoft の内製システムをりようしたグラフやダッシュボードも利用しています。また、いくつかの内部ツール（オーダーメイドのウェブサイト）も用意しています。これは Halo のためのミニ検索エンジンのようなもので、プレイヤーのパーティやマッチを追跡し、そのセッションと、マッチメイキングプロセスや最終的なゲームセッションに関与した他のプレイヤーやパーティとの関連付けを行うことができます。
Jeff Guy：私たちは、規模が大きくなっても多くのデータを取得できるよう、多くのツールやテレメトリをすでに設定しています。例えば、誰かがクラッシュした場合、ゲームは自動的にクラッシュレポートをアップロードします。私たちのチームは、個々のクラッシュの詳細を確認したり、その情報からさらに大きな問題を示すパターンを見つけたりすることができます。プレイヤーの設定に関しては、プレイヤーがキーバインドやビデオの設定を保存したときにデータを取得できます。これらの情報の大部分はオンラインサービスに保存されているからです。また、セッション中にプレイヤーのフレームレートが低下していないかどうかを確認することもできます。このように、さまざまな設定や変数の全体像を把握することで、調査対象を素早く絞り込み、問題を迅速に解決することができます。
WHAT DO YOU/YOUR TEAM CONSIDER A SUCCESS?
Sam Hanshaw：私たちは、プレイヤーが Halo Infinite の試合を安定してプレイできるようにしたいと考えています。より多くの試合ができるようになれば、それだけ多くの問題が発見され、私たちが対処できるようになります。私たちが見つけられなかった新たな問題をプレイヤーが見つけてくれれば、私にとってはそれが成功です。flight 中に発見されたものは、発売前に発見され、結果的に発売時には皆さんにとってよりよいゲームになります。
問題点の話ばかりになってしまいましたが、全体としては、プレイヤーのみなさんが楽しくゲームをプレイしている姿を見ることができれば、flight は成功だと考えています。スタジオでは、皆さんと一緒に flight に参加します。発売時に最高のゲームにするために集めなければならない情報がたくさんありますが、皆さんと一緒にプレイして、発売までの道のりについてコミュニケーションできることを楽しみにしています。今後のフライトに参加してくださる皆さんには、このゲームをより良いものにするために協力してくれて本当にお礼を言いたいです。
Brian Dunn & Brian Hughes：私たちにとっての成功とは、目標を達成し、それを上回ることができ、かつ大きなサプライズがないことです。多くの人が私のゲームを初めてプレイするときには、私は常に何か新しいことを学びますが、それとは別に全くの予想外のことが起きないことを願っています。
具体的には、マッチメイキングの品質に関する現実の結果と目標値との比較や、クラッシュ数と頻度の実績と予想値との比較などを見る予定です。また、プレイヤーからのフィードバックやデータが、プロジェクトの現段階での全体的な品質に対する私たちの期待に沿うものであることを期待しています。
Nate Jones：勝手な言い分ですが、私のチームのオンコール・プロセスを起動して、サポートのためにチームの誰かに電話する必要がないことが成功の1つの特徴です😊。
高いレベルでの成功とは、flight から有用なデータを得ることです。いいニュースもいいですが、悪いニュースも大切です。私たちは常に CPU/メモリ/帯域幅、マッチメイキングの速度と品質などを調べ、また一般的な品質/性能目標を設定していますが、それとは別にどの flight でも特定の実験を行っています。例えば、4月の社内 flight では、サーバプールでマシンが足りなくなった場合に、セカンダリプールにフォールバック・フェイルオーバーする方法について、いくつかテストを行いました。4月のテストは厳密には失敗だったのですが（セカンダリーサーバープールを利用するプレイヤーがいなかった）、その問題を外部チームのシステムのバグに絞り込み、flight のデータから問題を発見・修正することができました。
Jeff Guy：一流のPCゲームを作るには、プレイヤーのアイデンティティと、それに伴う多様性を受け入れることが重要です。PCプレイヤーは、自分がプレイしたい方法を反映させるために環境を構築しますが、Halo Infinite でもそれを尊重しています。もちろん、このような多様なハードウェアとソフトウェアをサポートすることは、多くの問題を引き起こす可能性があるということです。
私たちのチームは、ゲームを早くリリースしなければ気づかなかった問題を発見できた場合、flight は成功したと考えています。これは、私たちが設定した最小スペックのPCプレイヤーに、初日から素晴らしい体験をしてもらうために重要なことです。また、プレイヤーがどのようなカスタムキーバインドを使用しているのかを見てみたいです。特に、多くの人が設定するだろうと考えて作ったデフォルトキーバインドが、ちゃんとそのとおり多く使用されているか見たいです。
今日は、開発チームの洞察力と専門知識をコミュニティで共有するために時間を割いていただき、ありがとうございました。テストプレイヤーが flight 中に遭遇する可能性のある問題は、たいてい開発チームがすでに発見しているということを知っているのは心強いですし、開発チームが情報収集を行うためのツールを構築してくれたので「343はこのバグを知っているのか!?」と疑問に思う必要はほとんどありません。
では、テクニカルプレビューの準備に戻りましょう。
この記事が気に入ったらサポートをしてみませんか？