ゲームサウンドQAは難しい。CRI ADXプロファイラー活用による、サウンドQAの自動化・可視化を目的とした取り組みとは

先々月8月23日～25日にかけてパシフィコ横浜にてCEDEC2023が開催された。本稿では「CRI ADXプロファイラー活用によるサウンドQAの自動化・可視化に関する取り組みの紹介」セッションの内容をお届けする。本セッションには、株式会社セガ開発技術部より竹原涼氏、第二事業部サウンド開発部より瀬津丸勝氏。「株式会社CRI・ミドルウェア」開発本部第1開発部より宮下滉洋氏が参加している。

ゲームサウンドのQA（品質管理、あるいは品質保証）とは

ゲームにおけるサウンドというと、主にBGM、SEといったものが挙げられる。いずれもゲームへの没入感を高めるのに必要不可欠であり、その重要性の高さはゲーマーであれば言わずと知れたことではないだろうか。

そうしたBGMやSEが、ゲームプレイ中に意図したとおりに再生されているのかどうかを確認し、必要に応じて修正・改善を行っていく作業がQAだ。サウンド版のデバッグのようなものと考えるとわかりやすいだろう。

サウンドQAの現在と自動化・可視化に取り組むに至った経緯

株式会社セガ開発技術部の竹原氏は、QE（クオリティエンジニア）として『PSO2 ニュージェネシス』（以下、NGS）のサウンドチームの作業フロー効率化に携わるなか、サウンドQAの効率化があまり進んでいないことを知ったという。『NGS』に限らず作業フローの効率化についてはさまざまな取り組みが行われている（例：CRI Atom Craftロボットによる効率化）ほか、サウンド専用ではない取り組みは存在しているものの、サウンドQAにフォーカスした効率化についてはCEDECやGDCにおいてもまだ事例が少ないそうだ。その後同氏は『NGS』チームと協力し、CRI Atom Profilerを活用したサウンドQAにおけるプロファイルに関する自動化および可視化に取り組むことになった。

ゲームサウンドQAの課題

サウンドQAには特有の難しさがいくつかあるという。なかでも「問題に気付きづらい」という点が大きく、データや設定のミスにより、「意図した音が鳴っていない」「そもそも音が鳴っていない」といった問題の多くは、アセットを作成した担当者以外がミスに気づくことが非常に困難とのこと。さらに「広大なマップがある」「サウンドの数が多い」といった特徴をもつゲームになると、さらに気付くのが難しくなる。

また、サウンドは「リアルタイム性が高い」という特性をもっている。映像などと異なり、音の一部を切り出しても正しいかどうかを判断することが難しいのだ。とくに状況に応じてシームレスに音楽が変化していく「インタラクティブミュージック」や「激しいアクションゲーム」はその特性がより顕著になるそうだ。

そのほか、「状況を正確に伝えることが難しい」という点も挙げられる。扱っているものが「音」であるため言葉で正確に状況を伝えることが難しく、プログラム担当へのバグ報告の難易度が高い。

そして「確認のコストが高い」という点。スクリーンショットのように切り抜くことができないため、確認時に何度も聴きなおす必要があるほか、環境やハードウェアにより聞こえかたが異なるため再現が難しい。

そもそもとして、音の品質に関する基準は人の主観によって異なるため前提の共有が困難であり、総じてサウンドQAは難易度が高いと言えるのではないだろうか。

サウンドQA効率化に向けたアプローチ―自動化の課題

サウンドQAの効率化はなぜあまり進んでいないのだろうか。その理由のひとつとして、自動化との相性の悪さがあるようだ。竹原氏はサウンドQA効率化に向け、まず自動化を検討した。しかし、ゲーム内の音声のほとんどは複数の音が重なっているため、音の成否を自動で判定するのは困難だった。また、プロファイラーはコマンドライン（CUI）での制御ができないこと、実行結果が専用のツールでしか読めないといった点により、自動化との相性が悪く、さまざまな自動化ツール（検証版）が作成・運用されたものの、それぞれ問題点が浮き彫りになり正式採用には至らなかったという。

そこで代替案としてプロファイラーを用いた問題点の可視化を考案。細かいログの出力のほか、独自GUIツールにより可視化・分析を可能とした。プロファイル結果を自動でレポーティングし、レポートで気になったところをサウンド担当者が詳細を確認するというワークフローを構築することによって、問題の早期発見とバグ報告の難易度低下を目指すことにしたのである。

自動化に使用するプロファイラーとしては、CRI Atom Profilerを採用。社内でCRI ADXを採用しているプロジェクトが多く、なおかつプロファイラー結果をCSVとして出力できるというのが大きな採用理由であったとのことだ。

CRI Atom Profilerの具体的な機能と、コンソール版CRI Atom Profilerについて

CRI Atom Profilerは、ADXの再生情報を取得および可視化するGUIアプリだ。Atom Craftの内部機能として標準搭載されており、ADXまたはAtom Craftのツールパッケージを所持していれば利用が可能。プロファイラーで取得できる情報としては、再生・停止情報、CPU負荷、発音数、ラウドネス・ピーク・RMS、3Dポジション情報のほか、起こったエラーの情報など、多岐にわたる。

「可視化」にあたる機能としては、音がそもそも鳴っていないのか、音の再生がリクエストされていないのかを切り分けるため、どのように音が出ているかをタイムライン上可視化・確認することが可能な機能が存在。また、再生されるはずの音が停止されてしまった場合であっても、プロファイラー上でなぜ音が停止されてしまったのかを表示する機能（例：発音リミットによる停止命令）により判別可能。これらケースはサウンドのデバッグにおいて確認の頻度が高く、重宝する機能だという。

それ以外にも、音量情報（ラウドネスの超過）を取得し、指定した音量を超えてしまった場合、どこの部分が超えてしまったのかをハイライト表示する機能や、とにかく内容を網羅したい際に役立つテキストログ機能が利用可能。取得したすべてのログが表示され、時刻ソートのほか、ログの種類ごとに色分けして管理できる。さらに前述のとおりCSV出力することが可能だ。

その後さらなる利便性の追求のため、竹原氏からの要望によりCRIによってCRI Atom Profilerのコンソール版が開発されることになる。新たな機能として、出力ログファイル名の指定・標準入出力での停止、CSVで書き出すログのフィルタ機能、CSVの再出力機能が実装。スタンドアローン版プロファイラーであり、Atom Craftが必須でなくなったため、Atom Craftの導入を避けたいユーザーでも利用しやすくなった。なお、コンソール版については次回SDKからの提供を予定。将来的にはログの自動保存機能・ログの再生機能を開発予定とのことだ。

何を自動化・可視化すべきか

CRI Atom Profilerを活用するにあたって、何を自動化・可視化すべきなのか。真っ先に思いつくのはデバッグの難しい箇所だろう。しかし、自動化・可視化の効果を実感してもらい、前向きな文化を作っていきたいという竹原氏の考えから、結果の安定しない箇所への適用を避け、まずはシンプルな箇所から適用していったという。具体的には数値やログとして明確にわかるもの、たとえばCPU負荷/ラウドネスの数値、エラー出力、不正なデータ、設定などが挙げられる。そのうえで、実際にデータを確認するサウンド担当者と、CRIが公開している「CRI Atom Profilerで取得可能なログ」を参照しながら何を自動化・可視化したいのかを検討していったそうだ。

需要のリサーチとプロトタイプ作成・運用、フィードバックから再度検討会を繰り返し、新たにCPU負荷、ラウドネス、ストリーミングボイス数、ストリーミングの合計Mbpsのしきい値を設定して超えたものを検出する機能、キューの再生開始・終了機能、キューリミットの上限シーケンス数を超えたときの再生停止・再生キャンセルの可視化を実装。さらにゲーム中の特定の場面の検証用に起動中のアプリケーションへアタッチしてのプロファイリング、および検出したプロファイリング結果とその周辺の録画映像を作成してツールからバグトラッキングシステムに投稿することが可能となった。

本運用版自動化ツールCRI Profile Controller開発。運用中のプロジェクトに対してCRI Profile Controllerを導入する際に気を付けるべきこと

その後竹原氏は、本運用版自動化ツールとして、CRI Profile Controllerを開発。導入のわずらわしさを解消するため、ローカルで動作完結するように調整。さらにGUI化により利用者の心理的ハードルを下げる狙いがあったそうだ。また、プロファイリングと同時に録画を行い、プロファイリング結果と録画映像の再生を紐づけることにした。これによりCRI Profile Controllerで確認を行い、それでもわからなかった場合はCRI Atom Profilerでさらに詳細を確認するというワークフローを構築することが可能になった。

これらの検出した結果をサーバーに保存することにより、テスターが結果を共有し、サウンド担当が確認するといったワークフローを構築することも可能に。Atom Craft採用のすべてのプロジェクトで利用可能であり、特定のプロジェクト専用にならない汎用的な設計を心掛けたそうだ。

『NGS』を例に、運用中のプロジェクトに対してCRI Profile Controllerを導入する際に気を付けたということについては以下の通りだ。第一に、アプリの実装に影響を与えないようにするということ。運用中のアプリ実装に手を加えるのは、さまざまな調停や調整が必要になり、プロジェクトチームにも影響が出てしまうことが懸念される。CRI Atom Profilerは、インゲームプレビューが有効であればアプリ実装に手を入れずにプロファイルすることが可能であり、幸い『NGS』はインゲームプレビューが有効だったため、導入は容易だったそうだ。

また、ワークフローに影響を与えない形で運用可能な形が理想だとしている。『NGS』には自動ビルドや自動テストといった自動化の仕組みがすでに構築されていたため、そこにCRI Profile Controllerを持ち込むと複雑化してしまう。そのため、ローカルで独立して動作完結するツールにすることで、ワークフローへの影響を避けたとのこと。

サポートでプロジェクトチームの手をわずらわせないことも重要なポイントだと語る。この問題については、サウンドチームと直接やり取りをすることで対処したそうだ。しかし、協力は絶対に必要になるため、理念を共有したうえで協力関係を構築していくのが重要であるとしていた。

導入事例

株式会社セガ第二事業部サウンド開発部であり『NGS』のSE制作に携わる瀬津丸勝氏より、CRI Profile Controllerの実際の導入事例が紹介された。なかでも強調されていたのが、「同時発音数オーバー」のチェックに対する有用性である。『PSO2』は長く作り続けているプロジェクトであり、データのテンプレート化などにより作業の効率化を図っているほか、システム部分の基礎ができあがっており、致命的な不具合が出ることは少なくなっているとのこと。しかし不具合がなくなるということはなく、むしろ大量に出てくるのだそうだ。『PSO2』シリーズはマルチプレイを前提とした作品であるため、予期しないSEの鳴り方が多く、「飛び道具の音」や「弾などが空中を移動する音」といったSEが、プレイヤーキャラや敵キャラクターの数が増えることによって発音数オーバーが発生しやすくなってしまう。ツールで検出した問題の箇所を0.5秒ほどさかのぼって録画・再生する機能により、今まで人力で行っていた工程を大幅に削減することができたという。