「FFVIIリメイク」こだわりのサウンドの数々、その制作は泥沼…！？制作現場を実例と共に紹介！【CEDEC2020】

スクウェア・エニックスの谷山 輝氏、伊勢 誠氏、河盛 慶次氏が登壇した本セッション。「ファイナルファンタジーVII リメイク」（以下、「FFVIIリメイク」） でのサウンド制作におけるテーマ、そのコアとなる技術や「FFVIIリメイク」での改良の紹介とともに、制作面での反省や工夫が語られた。

一部は完全にサウンド制作専門の内容だが、「FFVIIリメイク」での実例と共にどのようなシーンでどのような効果をもたらしたかも語られているので、「FFVIIリメイク」を遊んだファンもこだわりのサウンド制作について、ぜひ一通り読んでみてほしい。

まず伊勢氏は「FFVIIリメイクのサウンドデザインの主題は、オリジナルのFFVIIをリスペクトしつつ、プレイしたことがない人でも楽しめる、懐かしさと新しさを融合させた表現の追求」とした。

最新型のグラフィックスと、シームレスに展開するコマンド主体型アクションRPGが魅力である「FFVIIリメイク」。オリジナル版ではバトル突入時に場面転換があったが、本作ではカットシーンからバトルシーンへシームレスに移行するようになっていたり、バトル以外でも多くのシーンがシームレスで繋がっている。

そのため、内製のサウンドドライバ「SEAD」の最新機能をフル活用し、サウンドのインタラクティブ性にこだわったのが「FFVIIリメイク」だった。

SEADとは、長年スクウェア・エニックスがサウンド部で開発している、マルチプラットフォーム対応のサウンドドライバー。製作効率のための取り組みなどが開発の主題で、インタラクティブなサウンド表現のための機能を色々実装している。

「MAGI」はシームレスな動的音楽遷移のためのAPIであり、古くは「ファイナルファンタジーXIV」から始まり、現在の形となった。音楽構造を加味した、適応的な遷移をデザインすることが可能となっている。

従来だと楽曲はクロスフェード方式で切り替えていたが、MAGIでは複数の楽曲の互いのテンポを加味して、リアルタイムに同期を待ち、自然に切り替えることが出来る“セクション遷移”と、あらかじめ音楽的に同期して切り替え時に各トラックのボリュームをクロスフェードする“モード遷移”により、様々なデータでシームレスな楽曲の切り替えを行っている。

リアルタイムモーション解析によるキャラクタ動作音自動トリガーシステムである「MASTS」は、「ファイナルファンタジーXIII-2」から使用されており、キャラクタの骨の座標や設置状態、それによる動作状態の推定、動作音などをあらかじめセットしておけば、トリガーを張らずに音を鳴らすことが出来るようになる。

そして動的なサウンド変化のためのFloatの仲介パラメータ「ZeroOne」は、「FFVIIリメイク」では重要な機能となっている。

シーケンスごとにZeroOne値と音声パラメータの変換カーブを作成可能で、複数のシーケンスと複数のトラックを並べることができる構造になっており、音声パラメータに変化して渡せるようになっている。サウンドごとに複数設定が可能で、複雑な変化にも対応できる。ZeroOneの設定のみで、デザイナー側で動的な音が作れるという。

ここで「FFVIIリメイク」で実際に使われたシンプルな例として、闘技場でのガヤのデータが公開された。

闘技場の盛り上がりは、バトルの状況にあわせてダイナミックにコントロールされており、盛り上がり度の異なる4つのLoopガヤ波形を準備して、各シーケンスにセット。実際には動画で、盛り上がり度のZeroOneを0.0fから徐々に1.0fへ変更して、ガヤの声援が自然と大きくなっていく様子を聞くことが出来た。

河盛氏はオリジナル版「FFVII」の音楽の特徴として、ほとんどの場面でBGMが鳴っており、環境音なども限定的だったことを挙げ、「FFVIIリメイク」の制作開始時には本作におけるBGMの立ち位置を考えるところから始めたそうだ。

そして実際に八番街のデータを使用しながら様々なテストを繰り返した結果、楽曲をシームレスに切り替え、オリジナル版「FFVII」同様にほぼ音楽を鳴らし続けることに決めたという。

実際に「FFVIIリメイク」のチャプター2となる八番街のプレイデータでインタラクティブミュージックの実例が公開されたが、ここは画像にておおよそのイメージを掴んでほしい。この場面で使用されているのはオリジナルサウンドトラックに収録されている「闘う者達 －強行突破－」なので、楽曲を流しながらスライドを見てみるとイメージがしやすいだろう。

この方針で進めていくことに決めたものの、シームレスに切り替えるためには緻密な事前設計が必要で、特にイメージの共有は絶対に必要だと感じたそう。

そこで従来のBGM制作とはがらりと変え、「FFVIIリメイク」ではひとつのチャプター丸ごとゲームプレイをキャプチャーし、ディレクターである鳥山求氏の要望に従い、その動画に仮BGMを高い精度で充て（フェードなど、本当に実機で鳴っているレベルのクオリティで作成）、実プレイと同じ感覚で動画を再生しながら、チャプター全体の楽曲のイメージを固めていった。

この作業を行うことで、結果的にコンポーザーたちとBGMのイメージを共有するのにも役立ち、リテイクもとても少なかったそうだ。

楽曲を主に切り替えているポイントは、マップの場所（屋内外、街、進行度）、街で特定の会話以降にメロディーを残してバックのアレンジを変更、フィールド～バトル～フィールド（同じ構成でシームレスに切り替え）、フィールド～カットシーン～フィールド、バトル～カットシーン、ボスバトルフェーズなどが挙げられる。

シームレスに曲を切り替える上で気を付けたポイントとしては、オリジナルの「FFVII」でBGMを作成した、植松伸夫氏の楽曲が持つ特徴的なメロディを大事にすること。シームレスに切り替えることでその魅力をなくさないことだけは、特に重要だった。

細かいところでは、曲を切り替える際のBPM（テンポ）や楽器構成はもちろんのこと、カットシーンでは専用の曲が鳴るのではなく、その前のユーザーの操作時からシームレスに曲を繋げることを意識したという。場所によってはシーンに合わせて4～5回ほど曲が切り替わることもあるので、盛り上がるポイントもあらかじめ決めておいた。

次の実例動画は、チャプター8でのエアリスの家に到着したシーン。この場面でかかっている曲は「エアリスのテーマ －ただいま－」なので、こちらもオリジナルサウンドトラックを流しながら画像を見てほしい。

河盛氏によると、「FFVIIリメイク」の楽曲はシームレス音楽の積み重ねであり、インタラクティブミュージックの使い方として特別なものはないという。また、オリジナル版「FFVII」の音楽が23年間愛されてきた土台があってこそアレンジのバリエーションが作成可能で、新規タイトルではこれだけのバリエーションを作るとせっかくの楽曲の印象が薄くなってしまうのでは、とも述べた。

「FFVIIリメイク」で大幅な進化を遂げたMASTSについて、伊勢氏は「MASTSは機能的に難しくて、使いこなし切れていなく、もったいないと思っていた」と語る。そのため、「FFVIIリメイク」を機にMASTSを改良をし、フィールドからバトル全編をMASTSで動かすことを考えた。

まずMASTSが抱えていた問題点として、「動作検出判定式の調整がプログラマのタスクであること」を挙げた。本来ならばデザイナーのタスクのはずがプログラマのタスクになっていたのは、動作の検出判定が調整が難しかったからで、デザイナーが一発で理解できず、パラメータを出してもらうにあたって説明を受けてもやはり理解できず、デザイナーにとってもプログラマーにとっても、双方良くない状態に陥っていた。

さらにMASTSは従来リアルタイムのモーションがターゲットで、カットシーンモーションはサポート範囲の対象外であった。そこでデザイナ主導型MASTSへと改良をし、デザイナ目線でわかりやすいようにアルゴリズムを工夫。動作判定パラメータ設定をアセット化することを可能にし、キャラクター毎やシーン毎のオーバーライドに対応した。

MASTSの設定とデータ構成は、動作種類を大幅に増加。これまでは肩と膝下のみだったのに対し、首、腕、大腿部、上体曲げ、上体ひねり、屈伸を追加。足は従来からあった歩き、走り、ジャンプ、着地以外に、擦りの音を新たに組み込んだ。擦りは、カットシーンで振り向く時の表現などにも一役買ってくれたそうだ。

そして各サウンドへのZeroOne設定により、カットシーンでの自動発音を実現することが可能になった。伊勢氏によれば、「ZeroOneは動的サウンドに欠かせない機能」という。

ここで実際にゲーム内で各キャラクターがMASTSによる自動発音だけで動いている動画が公開された。

非常に細かいパラメータ設定はもちろんのこと、骨の速度などをZeroOneと接続することによって、音を可変させ強弱を表現したりしている。これにより、モーションブレンド、プロシージャルモーション等、鳴らすタイミングがモーションで決められないシステムに対応した。

今回は特にカットシーンへの対応に主軸を置いて、システムの見直しと改修を行っているという。パーツの細分化とデザイナー主体のパラメータ調整にしたことで、微妙な動作の発音や抑揚あるサウンドを実現している。

これにより、会話シーンなどの激しいアクションがないシーンではほぼMASTSのみで完結でき、制作時間が短縮。大幅なコスト削減につながったほか、モーションデータの影響を受けないため作業的にも精神的にも楽になったこと、カメラの変更や絵尺変更でも影響を受けにくいことなど、さまざまな貢献があったという。

次は「FFVIIリメイク」での空間表現について、谷山氏が語った。

まず特製のAudioVolumeだが、元々はUnreal Engine4についているものを社内でさらに拡張したものであり、空間内固有のアンビエントサウンドを張り付けることが可能。複数のバスエフェクト設定や、空間内で遮蔽されたサウンドへの遮蔽ボリューム値なども設定できる。遮蔽パラメータは、ドアの開閉による空間表現なども可能となっている。

以下のスライドはAudioVolumeを細かく空間にあわせて配置している図だが、これを置くのはかなり大変な作業だという。AudioVolumeは空間で重なることもあるのでグルーピングをするなどの対応をとるのだが、今回はそういった詳細は省くとのことで、今回は各エリアの特性を含めて配置されていることだけが説明された。

エフェクトバス構成は3期のバスで構成。ひとつは初期反射からリアルな空間表現のためのルーティングで、ふたつめは誇張。これらを重ね合わせて、環境変化による音の変化を実現させた。

ここではチャプター8の冒頭のエアリスと二人で教会を抜けたあとの、屋根伝いの道を進んでいくシーンなどを使用した実例動画が公開された。

屋根伝いの道へ出た直後は、地上からの高さを感じられるようなエフェクトプリセットを配置。クラウドが無事に地上に降りたところから地上用のプリセットに切り替わるが、まだエアリスが頭上にいるので、上下で異なるプリセットを配置することで、高低差を表現した。

「FFVIIリメイク」ではバトル、フィールド、カットシーンと、全てのSE、ボイスがこの配置エフェクトの影響を受けている。配置エフェクトとZeroOneとを組み合わせることで、様々な空間の表現、演出をリアルタイムに行っているのだ。

また、アニメーションと連動した遮蔽変化動画も公開された。こちらはチャプター2のラスト、七番街スラム行き最終列車の中のものとなる。

列車のドアの開閉にあわせて、遮蔽が変化。また、クラウドが車内に入ることで車内のAudioVolumeに入ったが、ドアが開いているため、遮蔽させていない。そしてドアが閉まるアニメーションと同時に、遮蔽。このようにアニメーションと連動させることで、空間の変化を表現した。

次はガードスコーピオンのSEの距離ZeroOneのカーブの実例と共に、近距離と遠距離の時のSEの変化の実例が挙げられた。発音点とリスナーまでの距離感を感じられるデザインにし、二つの出力のバランスを取ることで空間を表現した。

「動的変化の強化、飛躍的な表現自由度の向上、これでなんでもこい！」と締めくくられたかのようなセッションだったが、実際はこんなには上手くいかなかった。

自由度を上げる＝表現の幅を持たせる、ということだが、それはパラメータ如何で良いも悪いも表現できてしまったり、最終的な鳴りは外部にも依存したり、制作時点の確認だけだと足りなかったりと、様々な問題が起こってしまった。

特に印象的な失敗の例はバイクゲームのシーンで、バイクの操作性次第でエンジン音の鳴り方が違ってしまったという。

従来の開発では大きな変化を与えるような表現は必殺技で、あくまで数少ない限られたシーンで使う物だったが、それをゲーム全編に適用したことで制作後に様々なアセットに対して何度も確認して調整するという泥沼にはまってしまったそうだ。

インタラクティブサウンド開発で大事なことは、「後で調整することを前提に、制作時点で必ず可視化すること」。可視化を蔑ろにしていると、調整が必要になった時に時間的な猶予がなく、原因が解らない場合は最悪「解らないから外してしまう」ということにもなってしまう。可視化すればどこを直せばいいのかすぐに解るので、結果的にこだわりのサウンドが無駄にならないのだ。

その可視化にあたって、「ImGUI」の活用が挙げられた。ZeroOneのInput値の可視化に絶大な効力があり、直感的な記法で即UI化が可能。特にUnreal Engine4のデバッグ描画と組み合わせると更に便利になる。

また、リアルタイムサウンドデザバッガー「Fabre」の動作風景も公開。たくさんの情報が並んでいるが、実際には見る情報を絞って確認できる。

セッションの最後は「サウンドのインタラクティブな表現の価値が認められ、汎化・量産したのがFFVIIリメイクであり、文化的な需要、ドライバの動的変化のための技術整備、Unreal Engine4のイテレーティブな開発性能の発揮が出来た」としつつ、最後まで調整しきる泥沼的な開発に対してバックアップ体制や事前の準備が必要であることは重要で、今後インタラクティブサウンドの量産は基本になってゆき、オーサリングツールの改善、デバッグツールの改善、継続的にエラー検出できるような環境作りが大切だと、締めくくられた。

CEDEC2020記事まとめページ