【CEDEC 2011】メモリ管理、デバッグ、サウンド再生…地道に積み重ねられた工夫の数々。「内製サウンドドライバの戦闘記録」

さまざまな要求に応えるためにサウンドドライバを内製

はじめに笠原氏から、サウンドドライバの概要とその仕組みについて説明がなされた。

笠原氏は、サウンドチームで「ファイナルファンタジー」シリーズや 「タクティクスオウガ 運命の輪」、「The 3rd Birthday」などのタイトルに参加。

笠原氏のプレゼンテーションは、「愛のサウンドドライバ劇場」なる一人アテレコ芝居で、場を程よく温めつつ（？）進行された。これは2011年10月発売予定のPSPソフト「ファイナルファンタジー零式」のキャンペーン「アテレコCM甲子園」になぞらえたもの。

サウンドドライバを社内で作成することで、サウンドチームのさまざまなリクエスト、たとえば独自機能の追加や従来のノウハウの効率的使用といった要望に、適宜応えていくことが可能になる。サウンドドライバの作成にあたっては、とかく多忙な開発チームが扱い方の習得に時間をかけずにすむよう、できるだけシンプルなサウンドAPIとすることが重視された。

サウンドドライバの内部は、プラットフォーム層、ドライバ層と3Dレイアウト層、システム層の4つから構成されている。このうち、ユーザーが実際に利用するのはシステム層で、ここにはシステム初期化やサウンド生成などのサウンドドライバAPIを実装。ドライバ層はサウンドデータや発音制御などの機能、3Dレイアウト層は3D音源配置や遮蔽といった機能、そしてプラットフォーム層は各プラットフォームのAPIを使用した、オーディオ処理やボイス、リバーブなどの固有処理を担当している。

メモリの効率的な使用のために

データ作成はつねにメモリ不足との戦いになる。そこでチームでは、各ハードの固有メモリやVRAMなど、使えるものは何でも使おうという姿勢でドライバ制作に臨んだ（VRAMについては後述）。同時に、メモリの断片化対策も考慮。メモリ管理を怠ったため、開発がある程度進んだ段階でプログラムを作り直すハメになったという苦い経験を元に、サウンドドライバの初期化時に必要なメモリをすべて確保してしまい、残りの部分を使用しないという方法をまず導入した。

この方法はシンプルだが、その分、さまざまなクラスの動的な使い分けなどには不向きでもある。そこでもう一つの方法として、もっともサイズが大きいクラスの配列を確保したうえでメモリを初期化し、適宜使用、回収することにした。最大サイズのクラスに合わせる分、それ以外のクラスでは使用しない部分が出てくるので、効率面でやや難はあるが、こちらも実装しやすいのがメリットである。

サウンドの「可視化」でデバッグを容易に

サウンドは目で見ることができない。そのため、キャラクターの操作中に実際は発音していないダミーの無音がたくさん鳴っていることに気付かず、処理負担がぐんぐん増えてしまうというバグが発生したこともあったそうだ。こうしたバグの調査はプログラマーにとってはキツイ作業であり、その調査には膨大な時間を取られてしまう。そこでこの問題の緩和策として、サウンドをさまざまな方法で視覚化するという新たなアプローチが考えられた。以下が実際に講じられたアプローチの数々である。

1）各種デバッグツール

データ内の情報をチェックするためのサウンドデータビューワを作成。バイナリデータを見るだけで、設定の間違いやコマンドの出力ミスなどが見つかることも意外に多い。

サウンドプレイヤーは、実機上でサウンドデータを読み込んで再生できるツール。これで実際の発音チェックを行うことができる。

加えて、サウンドデバッガを作成することで、実機で再生中のサウンドや3Dレイアウト、ログをリアルタイムで確認できるようになった。

2）ゲーム上でも表示

ゲーム画面上でもサウンドのID情報、パラメータや状態、音量などのサウンドデータをテキストで可視化するとバグが見つけやすくなる。音が鳴らない、音が切れるなどの問題が起きたときにも、原因の切り分けが容易になるので便利だ。ゲーム中に描画を行うため、スクリプトで状態が変わり続けるような状態のトレースには向いていないが、それでもサウンドの視覚化は、調査時間やコストの大幅な節約につながるという。

3）インスタンス編集

ゲーム中になかなか呼び出されない機能を、その場ですぐチェックしたいといった要求に応えて作成されたのが、インスタンス編集だ。ゲーム中にデータやキャラクター、オブジェクト、サウンドといったインスタンスの一覧から調査したい対象をその場で呼び出し、調整したパラメータを即座に反映できるようにしたことで、開発の手間やコストの更なる低減が図られた。

限りあるサウンドリソースを使い回す

ゲーム内の音は、プラットフォームのサウンド用APIを使用して発音させているが、発音用資源（※本講演ではボイスリソースと表現）は有限であり、とくに携帯機器などでは最大発音数が限られている。また、処理が軽くて効果音に向いているコーデックや、高圧縮だが処理が重いためBGMに向いているコーデックなど、用途にも向き不向きがあるのだが、発音数の追加や音質向上のために、通常はBGMに使用するボイスリソースを効果音で使いたいというリクエストもあったそうだ。

余談だが、資料にタコが登場するのは、当開発プロジェクトのコードネームが「タコ」だったためとのこと。

試しに使用してみたところ、初期化が重くなったり、資源不足からSEが飛び飛びになるなど数々の問題が発生した。これはアプリケーションからサウンドドライバに再生リクエストが来た時点で、必要なボイスリソースをすべて確保し、足りない場合は他で鳴っているサウンドを停止させて回収、その後にサウンドを再生する、というプロセスで何とか解決したという。

アプリケーション側からの再生リクエストが来たら、すぐにサウンドのハンドルを返して再生中とし、 実際の発音はサウンドドライバ内で順次遅延実行させている。

この方法のメリットは、初期化が重くても処理が固まらず、また、完全なサウンド再生が維持できる点にある。構造や処理は複雑になり、また、1～数フレーム程度のサウンド発音遅延も避けられないが、問題になるほどの遅れになったことはないという。これらの仕組みはPSP版の「タクティクスオウガ 運命の輪」などで採用されているので、興味のある方は実際に確認してみるといいだろう。

使えるメモリはVRAMでも使う！

実例の紹介では、笠原氏に加えて南氏も登壇し、VRAMを使用したサウンドリソース管理についての紹介を行った。先に少し触れたように、有限のメモリを有効にやりくりするため、PS3版の「ファイナルファンタジーXIII」では、通常メインメモリに置くサウンドリソースをVRAMでキャッシュし、管理する仕組みが取られているのだそうだ。

南氏は「FINAL FANTASY XIII」、同「XIV」などの開発に参加。 紹介した実例のサンプルを会場で再生しながらのプレゼンテーションとなった。

VRAMに置いてあるリソースを直接再生することはできないため、再生時にはメインメモリを使用することになる。だが、そもそもメインメモリが足りないからこのような処理をしているので、単純にメインメモリに置き換えるだけでは問題の解決にはならない。そこで、すべてのサウンドリソースではなく、場面によって必要なリソースのみをVRAMから転送して再生する、という方法が取られることとなった。これによりPS3版の「XIII」では、サウンドリソース用のメインメモリがわずか6MBに抑えられたという。

効果的な演出のために曲調を変化させるには？

ゲーム演出として、たとえばフィールドでのBGMを通常時は静かな曲調に、敵の接近時は激しい曲調というように動的に変化させたいというリクエストがあり、このために「Dynamix」という仕組みが開発された。これは、曲を作る際に1曲を4チャンネルのデータとして作成し、2つの曲調を1、2チャンネル、および3、4チャンネルに振り分けて、曲調の切り替えが要求されたら、各チャンネルのボリュームをクロスフェードさせるというものだ。MP3のように2チャンネルまでしか対応していないフォーマットでは、4チャンネルのデータをそのまま変換することはできないため、MP3の「なんちゃって」マルチチャンネル化も同時に考案された。

データ作成時には、2つのバージョンの長さやポイントを揃える必要がある。

「Dynamix」については更なる要望として、切り替えの位置をある程度曲側で制御したいというものや、滑らかにではなく「ゴリッ」と切り替えたいというリクエストも出てきた。そこで、切り替えたい位置にマーカーを埋め込んでもらい、さらに5、6チャンネルに効果音を設定。切り替えと同時に効果音まで処理する方法がとられた。この仕組みは「Dynamix Plus」として「FINAL FANTASY XIV」で使用されているので、こちらもぜひ実際に確認してみてほしい。

赤い三角は切り替え用のマーカーが埋め込まれた時点を示す。

プログラム上は、曲の途中で曲調の切り替え要求があっても、 マーカー位置まで待ってから処理を行う形で実装されている。