［CEDEC 2008＃10］カプコンの最新フレームワークによるサウンド制作の提案

　カプコンは近年「ロスト プラネット エクストリーム コンディション」，「モンスターハンター」といったタイトルで，国内のみならず海外でもビッグヒットを飛ばしている数少ない「海外で戦える日本ゲームメーカー」の1社である。本セッションでは，そのカプコンのサウンド開発者3名が出席し，その開発環境を「赤裸々に（岸氏）」公開している。
　通常，メーカーの開発環境は極秘にされることが多いこの業界において，ご本人達も認めているとおりなかなか「異色の」セッションとなった。大手メーカーの自社開発ツールの公開自体，ゲーム開発者にとって非常に興味深いものであるが，同時に，現在の業界の方向性と，解決すべき問題も見えてくる結果となった。本稿では，セッションに参加したサウンドデザイナーでもある筆者の所感を交えたレポートをお届けする。なお，試聴はすべて5.1chシステムで行われている。

　

業界全体でサウンド開発能力の底上げを図りたい

　
　まず，セッションは「ロストプラネット」のサウンドディレクターであり，MT Frameworkの開発者の一人でもある岸　智也氏のイントロダクションから始まった。開発ツールの公開意図は「業界全体でサウンド開発の底上げを図りたい。それにはまず議論を進める土台となるものがなければ始まらない。だから自社の開発ツールを公開し，これをもとに業界内で話を進められれば」というものである。非常に意欲的な試みであり，会社としてこれを認めるに至ったカプコンの英断に驚かされる。
　また，カプコンのサウンド開発は現在クリエイタ，エンジニア，プログラマと三つの職種が中心になって行っており，それぞれ緊密に連携して制作を進めているとのこと。三つの職種に上下関係がなく，それぞれ独立しながら相互に連携していく点が同社の独自性であろうか。

マルチプラットフォーム対応統合開発環境「MT Framework」

　
　次に，本セッションの目玉ともいえる，カプコンの自社製開発ツール「MT Framework」のサウンド部分の紹介に移る。解説を行ったのはサウンドプログラマである小森繁伸氏。実際にWindows（XPではなくVista Ultimateで動作していたのが意外であった）上で動作するMT Frameworkのデモを交えながら，ツールの説明を行っていた。なお，グラフィックスなどですでに「MT Framework」という名前をご存じの人も多いだろうが，グラフィックスのみならず，さまざまな機能をサポートするのが，カプコンの最新ゲーム開発フレームワーク「MT Framework」である。以下では，そのサウンド部分を取り上げて，単に「MT Framework」と呼ぶのでご承知を。

　さて，読者全員が開発に関わる方であれば説明は不要なのだが，ここでサウンドの「開発ツール」について少し説明しておこう。ゲームは，その「リアルタイム性」がほかの映画やテレビといったエンターテインメントと大きく異なる点である。つまり，ほかのコンテンツと異なり，時間軸の支配は絶対的なものではない（＝指定した時間に必ずそのイベントが発生するというわけではない）。そして，コンピュータがすべてを管理する，という点も然り，である。したがって，コンピュータに開発者の意図を分からせる（人間の意図通りに動いてもらう）必要があり，コンピュータが時間をコントロールする必要もある。
　サウンドでいえば，必ずしも「この場所でこの音が鳴る」というものではなく，必要に応じて必要な場所で，必要な音が必要な処理を行ったうえで再生される。そして，これらの「必要な」制御はすべてプログラムで行う。したがって，本来時間芸術である音楽制作で一般的に使用されているMIDI/オーディオシーケンサのような，時間軸に沿って編集するシステムは，多くの場合ゲームサウンドの開発に適していない。
　かといって，筆者を含むほとんどのサウンド開発者はプログラムに精通していないため，プログラム言語で語られても「？」となってしまう。最適なツールの欠如と担当者のプログラム能力の欠如。伝統的（？）ともいえる二つの致命的な欠落点を補うために，ファミコン，アーケードゲームの時代から大手メーカーはサウンド開発ツールを用意してきた経緯がある。

　

MT Frameworkのコンセプトは業界大手のトレンドに明快にマッチ

　
　そして，こういった独自性の高い自社ツールは，その会社の中でのみ使用されているので，他社と差別化を図る重要な要素を担っており，非公開が原則である。今でもPS2やPS3用の自社開発ミドルウェアやライブラリは非公開のはずだ。今回のように，ツールを見せるというのは非常に珍しいケースといえよう。
　MT Frameworkとは，一言でいうと「マルチプラットフォーム対応のサウンドドライバとそれを制御する開発ツール（ユーザーインタフェース），内蔵音響処理アルゴリズム，デバッガで構成されるマルチプラットフォーム対応サウンド統合開発環境」である。
　これによって，かつてはタイトルごとに開発していたサウンドドライバに汎用性を持たせ，プラットフォームに依存しない開発環境を作り上げ，しかもこれを使用して継続的に開発を行うことで，データやノウハウの蓄積も見込める。言い換えると「MT Frameworkのお陰で，タイトル，プラットフォーム，開発スタッフに依存することなく，開発に継続性を持たせることができる」ということである。

　お分かりの人もいると思うが，実はこういう開発環境を整えていくのはカプコンのサウンドに限らず，グラフィックス，プログラムを含めた現在の国内外業界大手全体のトレンドである。先日紹介したコナミのMGS4は典型的なプラットフォーム依存で，現存する最高のハードウェアを最大限活用し，ギリギリのところまでその能力を引っ張り出すことを目標としているのに対し，多くのタイトルは，能力が低いプラットフォームを考慮しつつマルチプラットフォーム展開することで，獲得ユーザーの取りこぼしを減らすリスクヘッジを行うのが一般的である。
　前者は当然ながら非常に尖った製品になることが多く，先進的で高い評価を得る可能性も高い。ただし，ハードウェアオリエンテッドな開発形態のため，ほかのプラットフォームへの展開は非常に難しく，そのプラットフォームで続編を作っていくしか以降の展開は見込めない。
　MGSシリーズほどの知名度と実績があればこの方法ももちろん可能だが，最近はこのような「尖った」作り方をすることを大手メーカーは非常に嫌うようになっている。よりビジネス的になったから，という厳しい意見もあるが，それより現実問題として，1作品にかかる開発費は10年前とは桁が違ってきており，リスクヘッジなしで開発を行うことが，あまりに無謀になりつつあるからであろう。下手をすれば1作品失敗すると，会社倒産，という事態にもなりかねないくらい，そのリスクは高まってきている（＝タイトルあたりの開発費が高騰している）のだ。タイトルやプラットフォームに依存したくない，というのはこれが理由である。
　一方，開発スタッフに依存したくない，というのはどういうことであろうか。
　昨今のゲーム開発費高騰のもっとも大きな理由は，開発費の中で人件費の占める割合が非常に高くなっているからである。これは（残念ながら）開発者の人件費単価が高騰しているわけではない。ビッグタイトルだと開発スタッフ全員で数十人から百人を超えることも珍しくなくなっており，外注スタッフまで含めるととんでもない人数が関わってくる。こうして，膨大な開発費の7割8割までを，人件費が占めるようになってしまったからだ。言い換えると「物理的にやらなければいけないことが多すぎて，かつてのように突出した能力を持つスーパー開発者が数人いればゲーム開発ができる時代ではなくなった」という理解ができる。このため，とくにスーパーな開発者ばかりでなくてもよく，とにかく頭数が必要（＝並列に仕事を進めることができるから）という発想でプロジェクトを運営していくことになる。
　しかし，現実には，開発者は人間なので，品質には当然ばらつきもある。さらに入社後の研修，業務開始後の継続的な教育も必要だ。しかもその結果，10人が10人，スーパー開発者になるわけがないのはご理解いただけると思う。だからといって教育しなくていいというわけにもいかない。結局，個々の開発者に求める水準ラインをどこに持ってくるかという話になり，このラインを高くすると，個々の能力は高まるが，絶対数は減るので取り替えが利かず，開発タイトルを増やすことが困難になる。一方，このラインを低くすると，個々の能力はそれほど向上しないので，組織としてサポートする部分が増えるものの，増員はたやすく，取り替えも利くようになる。
　夢のない不愉快な話に聞こえるかもしれないが，ゲーム開発が慈善事業や国家事業でない以上，これはいたしかたない部分でもあり，決してどちらかが良い，悪いというものでもない。双方にいい点と悪い点があり，現在，大手は後者の「個々の開発者に求める水準を下げ，代わりに包括的な開発環境を整える方向に投資することで，より容易に人員の増減・入れ替えを可能とするリスクヘッジの方向」に舵を切っているといえるだろう。背景は先述の通り，もはやタイトル1本の開発費が尋常ではなくなったからである。

　カプコンのMT Frameworkは，この目的に的確に合致する。決して開発者達は「いつでも人材の入れ替えができるから」などとは思っていないだろうが，現実問題として高いスキルを持つ人材の確保は常に困難なこと。にも関わらずタイトルごとの作業量はどんどん増えていることを考慮すると，非常に合理的な判断だといえる。

　

MT Frameworkのリアルタイム性

　話を小森氏の技術解説に戻そう。MT FrameworkのドライバはUIから呼び出し，リアルタイムに開発者が制御可能だ。筆者もサウンドデザイナーの端くれなので，このようなツール（カプコンではない某社製）を見たり使ったりしたことはあるが，3次元的な座標軸がGUIとして用意されており，音源をドラッグして制御できるというツールは初めて見た。また，GUI以外にも，オンメモリのサウンドデータやストリーム用サウンドデータを制御するリクエストテーブル，サウンドデータ単位の調整（実際には音量・定位など各パラメータの初期値や上限・下限値を設定できるものと思われる）を行うテーブルも用意されている。


　さらに細かく各サウンドデータを制御するランダムテーブル，ボリュームカーブ，指向性カーブ，スピーカーセットといったテーブルも用意されており，これによって，各音源のサラウンドを含めた配置位置，移動時の音色変化，指向性までサウンド開発者から設定が可能だ。実際のゲーム内でもCPUがこれらの設定を参照しながらサウンドデータを再生していくので，開発者の意図した音色変化をプログラマの手を煩わせることなく実現できる。
　音響処理用アルゴリズムは，もちろんコンソールによって使用できる最大数は変わってくるだろうが，MT Framework上ではEQとリバーブをそれぞれ最大4系統使用できる。サウンドデザイナーとして興味深かったのは，残響を擬似的に付加するリバーブアルゴリズムで処理を行う直前に，EQがリバーブのプリEQとして用意されている点。筆者は制作の際，ポストリバーブ（リバーブの後にEQ処理を行う）を使用することが多々あるので，プリEQのみサポートというのは意外であった。個人的にはプリ/ポストで切替ができればもっと便利かなという印象だ。そのほか，音響処理用には独自アルゴリズムでドップラー，インテリアパン，センタースピーカーボリュームも用意されているとのことだ。
　もちろんデバッグ用監視ツールも用意されているが，もう一つ，面白かったのはアプリケーションツールと呼ばれるツール類だ。


　とくにモーションSEという機能はユニークだった。例えば，クリーチャーが歩く都度，足音はもちろん，関節が鳴る音などもモーションに合わせて再生できる，というもので，シーケンサライクなGUI上でリアルタイムに発音タイミングの調整ができる。通常，この辺はタイトルごと，プログラマが実装していくものだが，それすらMT Frameworkで実現しているため，タイトルごとの負担も減り，開発効率も向上することが見込まれ，大変よいアイデアだと感じた。
　このアプリケーションツールは，ほかにもリバーブやEQの切り替え，効果音再生，効果音の自動再生，ストリームの切替など非常に多岐にわたりゲーム中のサウンドをサポートするとのことだ。
　説明のあとには実際にプレゼンテーターが関わった「ロストプラネット」を使用したデモが行われ，これらの機能の実演を交えた説明がなされた。正直会場では多少効果がわかりにくいものもあったが，MT Frameworkで完結できる作業が非常に多いことは理解できた。


　

ダイナミックレンジに関する取り組み

　
　ここからはエンジニアとして多くのタイトルに関わっている瀧本和也氏にバトンタッチ。ポスプロエンジニアとして，そのキャリアをスタートさせた氏のプロオーディオ畑のノウハウを活かしたダイナミックレンジに関する取り組みが印象的であった。話を詳細に書いても大半の読者は「？」となりそうなので，筆者が大胆に要約すると，「大半のゲームタイトルはダイナミックレンジを圧縮して平均音圧レベルを上げているが，もはや飽和レベルに達しており，音響的観点から見ると明らかによくない。個人のレベル向上に期待を抱くだけでなく，リファレンスレベルを設定し，すべてのサウンド開発者がこれを守りながら制作を行う（＝サウンドデータ素材を用意する）ことで，最終的に適切なダイナミックレンジでサウンド再生が可能となる」ということになる。


　瀧本氏も述べていたが，これは昨日レポートしたコナミ戸嶋氏のセッションで述べられていた内容とまったく同じものであり，現在ほぼすべてのゲームタイトルが抱える問題でもある。とくにビッグタイトルに見受けられるが，ビジュアルが非常にリッチになり，微細な表現が可能になったため，これに必要と思われる音を当てていくと，時間軸ごと一度に再生されるサウンドデータ数が膨大になる。これで素材自体のダイナミックレンジを，従来のようにガチガチに圧縮すると，素材をミックスした最終出力時に平坦になってしまい，シーンごとの抑揚がつかない。また，聞こえてほしい音が聞こえない。意図する結果を実現する（コナミ戸嶋氏はこれを「Finishing」と呼んでいた）ためにかかる所要時間が膨大になってしまう，といった問題が現場で生じている。
　これを特定タイトルだけでなく，前述の通り複数プラットフォーム，全タイトル，全開発者にわたり，継続的に解決するため，カプコンでは，瀧本氏が主導して現在開発者が開発の際聴くモニターの出力レベルを統一している。リファレンスレベルは開発用コンソール（-10dB）と業務用出力（+4dB）のProToolsも同じに設定されており，要するに，どの開発者も，どの開発機材を使用するときでも，基本同じ音量でモニターしているということになる。
　実際には，瀧本氏の映画制作などの経験と最新ハリウッド映画のノウハウを取り入れて，MT Framework並びにProToolsのリファレンス信号をピンクノイズ-18dB RMS（平均音圧レベル）で再生した際，SPL=75dBになるように設定（キャリブレーション）されている。要は，この音量でモニターして各開発者はサウンド素材を作成し，OK/NGの判断を下すわけだ。こうすることで，開発者間で生じる音圧差をある程度吸収することができる。リファレンスシグナルのレベルは低めだが，そのため最終的なミックスの際ヘッドルームの確保が容易になり，音圧レベルの調整がしやすいとのことだ。筆者が補足しておくと，前回コナミレポートで書いた「トランジェント（鋭く大きなアタックを有する音）」をあまり失わないような音量でモニターするため，最終ミックス時に個々のサウンドデータのトランジェントは維持され，それが全体としてのダイナミクスにつながる，という理屈であろう。

　ユニークだったのは現在の開発機材がMT Framework，ProToolsともに民生用のAVアンプに接続されており，民生用スピーカーでモニターしている点だ。音楽制作の際，ラジカセを用意してときどきラジカセでモニターしてエンドユーザーの再生環境を想定しながら作業を進めるのと似ている。さらに，サラウンド制作が必須だからとはいえ，同じフロアで全員がスピーカーを使用してモニターしているのはかなり特殊であろう。他社ではヘッドフォンを使用することが多いからだ。
　それにしてもダイナミックレンジの解決策としてモニターレベルの基準値を定めてしまうという発想は，カプコンは異議があるかもしれないが，先のMT Frameworkのようなフレームワークのコンセプトと同様だ。結局，開発ツールを提供するのと同じように，リファレンスレベルをトップダウンで決めてしまうことで，開発者間の品質差を吸収するだけでなく，必要以上に開発者のスキルを向上させる必要もない。つまり個々の開発者への投資ではなく，ノウハウやツールといった有形無形の会社資産への投資に資金を回せる。また，最終のミックス時の役割が大きくなり，ここでコントロールできる範囲が大きくなるため，実際の仕上がりも確かによくなるはずである。
　あらためてカプコンの名誉のために書いておくが，筆者がサウンドデザイナーのキャリアを開始した頃は，スーパープログラマがいて，一人でとんでもないゲームを作り，サウンドデザイナーも1タイトル一人＋αが一般的であった。こういう時代は，そもそも絶対人数が少ないため（当時筆者の在籍した会社では全職種の全開発者で200人程度だったと記憶している）個々の開発者への投資が容易であり，システム開発にあまり力を入れるとかえって不採算になりがちであった。逆に，サウンド開発者だけでおそらく数十人という現場も珍しくない現状，個々の開発者への大規模な投資は×人数分になり，会社の経営を圧迫してしまう。逆にシステムを整備していくほうが費用対効果の面で有益なのだ。
　1プロジェクト10人くらいで密に開発に携わってきた古い世代のデザイナーとしては少し寂しさも感じるが，これが現在のゲームタイトル，とくにビッグタイトルをリリースできる大手メーカーの方向性なのであろう。
　

ロストプラネットで実際にダイナミックレンジ調整前後のサウンドをデモ

　
　最後に，岸氏がダイナミックレンジ調整を行う前のロストプラネットと，調整後の同タイトルを比較デモしてくれた。筆者がよくなったと感じたのは，やはりメリハリがついた（抑揚が出てきた）という点と，トランジェントがよりはっきりと感じられるようになった，という点であった。


　膨大なサウンドデータを一度に再生するゲームにおいて，個々のサウンドデータのトランジェントとサウンドデータ全体から生まれるダイナミクスは非常に重要であり，正直，その重要性は音数が遙かに少ない映画やアニメの比ではない。そこをリファレンスレベルを決める，というノウハウにより，タイトルに依存せず汎用的に実現できたのはカプコンサウンド開発陣の日頃からの努力の賜物である。そのような日常をCEDECというセッションで垣間見ることができ，非常に有益な時間を過ごせたと感じている。
　今回のコナミとカプコンは同日のセッションにも関わらず，コンソールオリエンテッドな制作か，より汎用的なソリューションの開発・提供かという点で真逆の方向性ではあったが，一方で問題点とその解決策はかなり似通っており，これまた印象的であった。
　ただ，大手各社はリファレンスレベルの概念はとにかく，MT Frameworkと似て非なる，同コンセプトの自社開発ツールをそれぞれ有しているため，一朝一夕に大手間で開発環境の統合が起きるとは残念ながら思えない。むしろ，このような開発環境を作ることができない中小のゲームメーカーには非常に魅力的に映ったかも知れないので，まずはそこへの浸透を図ると，意外と早い時期に開発環境の汎用化が進むのかもしれない。あくまで楽観的な見通しだが。カプコン開発陣のご武運を祈りたい。