プロローグ
はじめに
ミュージックシステムの概要
コンテンツ
    NPCと音楽の同期
        《一剪梅》詞を歌うランダムな歌声
        《望海潮》一時停止中や音楽と同期した、シーン音楽のメロディに合わせたハミング
    3Dの詩的音楽と2DのBGMの同期
    BGMとNPCの3D読経の同期
    シーン音楽をリアルタイムに展開させる
    リージョンのシーン音楽が頻繁に変わる時、気にならないように切り替えるトランジション設計
        シーン音楽と無音時間の管理
技術的な詳細
    Wwiseプロジェクトの構成
    楽団の音楽
    戦闘音楽
    コンダクターたちをワールドに繋げる
エピローグ

 

プロローグ

「ゲームの没入感や臨場感を深めるには、BGMだけに頼らず、それを超えて何かできないだろうか？」プロジェクトのミュージックスーパーバイザー兼リードミュージックコンポーザーである私にとって、このような初期の自問自答が探求の原動力になりました。

 

はじめに

『Condor Heroes（射雕）』は宋の時代（960－1279）が舞台の中華スタイルのオープンワールドMMOゲームであり、金庸の武侠小説『射鵰英雄伝』がストーリーの背景にあります。中国史において宋の時代は商業経済と文化の繁栄が特徴の豊かな時代であり、音楽の多様性が発展し、中でも「勾栏瓦舍」と呼ばれる庶民の芸術施設で披露される伝統的な民族楽団による演奏が高い人気を誇りました。

また研究によると、古代中国の詩と比べこの時代の词牌（リズムと音韻を規定する決まった構造と韻律を守る）は、音楽化への対応と表現がより優れているということです。当時はこれが文化推進の方法として広く活用され、当時の政治状況、文化的な信念、社会的な感情などが歌詞によく描写されました。

ゲームに登場する中国の民族音楽の楽隊

そこで伝統的な楽隊を3D音楽で再現し、いくつかの専用舞台をゲーム内に配置して、ゲームの時代やストーリーに関係した新たな楽曲を词牌に基づいて作曲してみようと考えました。昔の庶民生活が再現され、プレイヤーもゲーム内のキャラクターも共に過去を追体験する没入感を味わうことができるでしょう。

最終的に決まった中国の伝統楽器のアレンジは（上図の左から右へ）：筚篥、箫、小镲（小さなシンバル）、古琴、琵琶、缶、大鼓、碗琴、双子の拨浪鼓（でんでん太鼓）と小笛、双子の碰铃と古筝、尺八、方响、笙、檀板、さらに箜篌と三弦が加わることもあります。

Wwiseの自然を模した減衰カーブを使い、これらは3Dで再生されます。プレイヤーが運悪く迷ってしまった時は音を頼りに道を探すゲームプレイに繋がるかもしれませんし、たまたま発見したプレイヤーにとってイースターエッグとして機能するかもしれません。

楽団のイメージが定まってきたところで、次に最も気になるのは詩的な指標となる音楽の表現方法と、ゲームの再生ロジックの全体的な枠組み計画です。読者はいくつかの疑問点を感じるかもしれません。例えば：

•  詩的な3D楽曲と2DのBGM再生ロジックは干渉しないのか？
• プレイヤーが楽団に近づいた時、BGMはどうなるのか？
• その他

音楽の観点で言うと、私はゲーム開発の初期段階よりグローバルミュージックシステムの作業を開始しており、従来の中国風ゲーミング音楽によくある作曲方法、再生ルール、表現形式などから離れることを決めていました。

はじめに前述の3D詩的音楽テーマについて見てゆきます。今回のインタラクティブミュージックシステムの設計や、オーディオプログラマーから受けた技術的なサポートに焦点をあて、以下テーマの機能を中心に詳しく説明してゆきます。

• 3Dの詩的音楽とNPCの3Dランダムハミングの同期。
• 3Dの詩的音楽と2DのBGMの同期。
• BGMとNPCの3D読経の同期。
• リアルタイムに同期するダイナミックなシーン音楽の展開。
• リージョンのシーン音楽が頻繁に変わる時、気にならないように切り替えるトランジション設計。

 

ミュージックシステムの概要

初期検討の結果、今回は以下のようなニーズがあり、グローバルなステートやスイッチで1つのミュージックイベントを制御するという典型的なWwiseのアプローチでは、柔軟性が不足することがわかりました：

• ダイジェティック音楽と非ダイジェティック音楽は明確に区別しません。前者が後者になることもあれば、その逆もあります。さらにテーマ内の要素を見ても、ダイスジェティックなものもあればそうでないものもあります。それぞれの要素がレベルのマークアップ、ゲームプレイのコード、あるいは場合によってシネマティックスの展開により、動的に現れたり消えたりします。
• このゲームにはキャラクター、場所、出会いの機会が満ちあふれ、広くて細かい世界があります。その優先順位をミュージックシステムが状況に応じて動的に変え、無音の時間をスケジュールし、中断中の出来事を管理します。
• このゲームは小説に基づいており、ストーリーテリングがとても重要です。音楽との同期が必要で、線形のシーケンスやシネマティックスが多数あり、時にはビート単位で合わせる必要があります。

明らかに複数の3Dミュージックエミッター、コールバック、プライオリティシステムなどが最低限必要で、さらに大量の編集ツールにも対応しなければなりません。私たちはすべてを以下3つのコアコンポーネントから成るコンダクター（指揮）システムと呼ぶもので実装しました：

1. ワールドコンダクターはデータテーブルで定義したルールセットに従い、ゲーム全体にわたり音楽テーマ再生のキュー設定、プライオリティ付け、スケジューリングなどを担います。例えば、「シーン音楽」テーマは通常ほかのテーマよりも優先度が低く、戦闘中は中断されます。ワールドコンダクターはゲームプレイの同期のために、ミュージックコールバックをミュージックシステム外に送信することもできます（カットシーン中など）。
2. ミュージックコンダクターは音楽テーマの制御フローを管理し、同時に再生される1つまたは複数のミュージックソースを調整します。必要に応じて内部ステートを維持することもできます。例えば、ある音楽テーマの最後の再生位置を保存し、その再生を後から再開することができます（より優先順位の高いテーマの再生リクエストがあった場合など）。
3. ミュージックソースはそれをつかさどるミュージックコンダクターのコマンドを実行し、それらをWwise APIコールにマッピングします。これらのミュージックソースは、ゲームワールド内の任意の場所に配置できます。コンダクターの最初のミュージックソースは常に「ガイドトラック」とみなされ、コールバックの収集に使われ、必要に応じてほかのソースをこのミュージックソースに同期します。

下のエンティティが上のエンティティの内容を全く把握していない、単純な階層構造です。これに加え、ミュージックコンダクターやミュージックソースにそれぞれのブループリントのインターフェースを実装する必要がありました。最初の設定が困難でしたが、一方でワールドコンダクターのプライオリティ付けやスケジューリング方式に統合されたまま、音楽の再生ロジックを完全にオーバーライドすることができました。例えば、ある時点で私たちはプレイヤーが操作できる仮想楽器を追加し、再生中の音楽テーマと調和したメロディを再生させたいと考えました。そこで私たちは特別なミュージックソースを作成し、それ自体に音楽を再生させるわけではなく、そのミュージックソースが所属する音楽テーマの現在のコードを認識させるだけで、現在のハーモニーに従ったランダムな音符をトリガーする単純なヒューリスティックを設定しました。

ミュージックシステムの動作設定は、Unrealのデータアセットやデータテーブルを通して行います。ゲームプレイのコードの実装詳細をワールドコンダクターが隔ててくれるため、シネマティックシステムやダイアログシステムとの統合、デバッグUIの実装、レベルのマークアップアクタの追加などが簡単でした。音楽制御のリクエストがどこで発行されても、ワールドコンダクターのステート処理がすべてのトランジションにダイナミックに対応してくれます。この上に私たちが構築したのが「コンダクターシーケンス」と呼ぶ、面白いシステムです。要はワールドコンダクターに送るコマンドの順序をトラッカー機能のように並べるシステムで、音楽を厳密な制御フローに従わせる、スクリプトシーケンスのある短い場面などで活躍しています。

 

コンテンツ

NPCと音楽の同期

《一剪梅》詞を歌うランダムな歌声

こちらの歌詞は場面の描写を通して、さまざまな感情を引き起こします。哀れみのある感動的で素朴なシーンを描きます。以下はいくつかの主な設計ポイントです：

• 簡単に歌え、すぐに覚えられるもの（庶民用）。
• 子どもNPCが歌って差支えないもの。
• 中国の楽器の繊細なタッチを避け、単純明快さを重視。

プレイヤーやNPCキャラクターのハミングはランダムにトリガーされ、詞の歌と同期されます。声優たちに歌をお願いしました。

以下のゲームキャプチャーでは各所に配置されている楽器や歌声が聞こえ、この庭園を囲む世帯の人たちがよく集い、音楽を奏でて歌を歌う様子が伝わってきます（スクリーンショット参照）。子どもたち（NPC）も凧あげをしながらハミングします。世代から世代へ受け継がれる音楽の文化的な価値も表現する、素朴な美しさが感じられます。

各モデルが近距離にあり、プレイヤーがどこに移動しても、さまざまな方向から同期された音楽ステムが聞こえてきます。

《望海潮》一時停止中や音楽と同期した、シーン音楽のメロディに合わせたハミング

多くの場合、プレイヤーに付き従うNPCとのやり取りがあるのは戦闘の時だけです。しかし私の設計哲学として、プレイヤーに伴うNPCは終始子どもであり、時としてハミングしイタズラもするので、私は彼に「心」を吹き込むことにしました（現実味を少し出すため）。

以下のゲームキャプチャーでは、弟分が時折ランダムに詞の断片をハミングするのが聞こえますが、その時も正確なビートと完璧に同期しています。

3Dの詩的音楽と2DのBGMの同期

街中に入ると、楽隊がそのエリアのBGMに同期した曲（例えば《无题》）を演奏することがあります。BGMと干渉するのではという懸念がここで発生します。

このような場合、私は以下の設計原則に従いました：

• 詞の楽団の再生時間を制限。
• BGMと同期された同時代の詞の歌を再生。
• BGMは詞の音楽に基づくテンポや楽器編成で作曲し、両者がシームレスに融合され、絡み合えるようにする。
• 距離に基づきBGMのボリュームを調整。

総括すると、プレイヤーがこの3Dオブジェクトに近づくたびにBGMの音量が徐々に小さくなり、3Dオブジェクトにフォーカスが移る結果となります。また2つの曲の速さ、キー、コード進行が全く同じであるため、プレイヤーは音楽が「突然切り替わった」と感じることはなく、まるで2つの曲がシームレスに融合したように聞こえますが、プレイヤーが去った後も独立して存在し続けます。意識していないと聞き逃してしまうほど滑らかにトランジションが起き、ダイジェティック音楽と非ダイジェティック音楽の境界も曖昧に聞こえます。

ゲームのほかの箇所でも同様の同期ルールが多数つくり込まれています。

NPCの3D読経とBGMを同期させる

中国の霊泉寺は歴史的なお寺のひとつで、ゲーム内においても重要な位置を占めています。その神聖さゆえに、ほかと同じくテーマ音楽のBGMだけで静謐な荘厳さを演出するのではなく、新しい要素も取り入れたいと思いました。音については寺院で僧侶が打つ木魚や鐘など一般的な音のほかに、何か特別な要素はないかを考えました。

そこで私は毎日僧侶たちが唱えるお経を取り入れたいと思ました。

レコーディングエンジニアにお願いし、中国のお寺でお坊さんのお経を録音してサンプルを集めてもらいました。私はこの録音を受け取り、以下を行いました：

• お経のトーンを音楽に同期させる。
• お経のテンポを音楽に同期させる。
• 再生中の音楽のダウンビートでお経をランダムにトリガーさせる。

シーン音楽をリアルタイムに展開させる

プレーヤーによっては朝から昼までプレイしたり、昼過ぎから夕方までプレイする人が出てくるでしょう（つまり連続プレイしているうちに、1日の異なる時間帯に遭遇するでしょう）。ゲーム内の時間はプレイヤーの現地時刻と同期されるため、このようなゲームで一般的なのは時間帯に合わせて異なる音楽を流すアプローチです。一方、私たちは音楽の目立った切り替えを避けたいと考えました。そこで私はシーン音楽のテーマが全体的にダイナミックに展開するよう、同じトラック内において時間帯に合った入れ替えや変化を導入しました。

• 朝、昼、晩の3回、音楽が変わる時間帯を設定する。
• すべての音楽変化のステムを、同じトラック内に入れる。
• ダイナミックなステムを維持するため、継続性とバリエーションの両方を確保する。
• ある時間帯に再生される音楽は、それが完全版となるようにする。

同様にプレイヤーは「ミュージックスイッチ」の痕跡を聴き取ることなく、なんとなく「このシーンの音楽は午後になると豊かになるかも」、「あのシーンの音楽は夕方になると音が小さくなるのかな」などと感じるかもしれません。

  

頻繁で耳障りな切り替えなく、エリアのシーン音楽をトランジションさせる

以上はプレイヤーが同じシーン内または固定された条件下で行動した時の、音楽のインタラクティブな変化に関する説明でした。これ以外にもストーリーの進行上、あるいはプレイヤーの気ままな探索により、ある場所から別の場所へ徒歩やテレポートで移動することがありますが、その具体的な設計を音楽のロジックに実装しました。

簡単に言うと、プレイヤーが新しいエリアに入るたびに音楽がすぐ切り変わるような経験をさせたくなかったのです。これが度重なるとプレイヤーは退屈してしまい、いずれ疲れてしまう上、プレイヤーによっては誤って別エリアに入り、すぐに出ることがよくあるため、これを考慮して認識タイミングにバッファーを持たせて「空白のインターバル」なるものを取り入れることがベストだと思いました。以下に例を挙げます。

通常のシーンでは：

• プレーヤーが一定の時間、新たなエリアに滞在したことをシステムが認識した場合、現在のミュージックアクションを起動させる。
• 静かなインターバル時間が一定の秒数続いた時は、新しいミュージックアクションを起動させる。

一部の特別シーンでは：

• 現在の音楽の楽器を少しずつ減らしてゆき、切り替えずに再生を続ける。
• プレイヤーが新しいエリアに入った場合、専用の短い音楽スティンガーをトリガーさせる。

『Condor Heroes（射雕）』のようなオープンワールドゲームのプレイヤーは、常に音楽を聴いていたいとは限りません。音楽中に30%～40%の無音の時間を設けることで、「聞き疲れ」を緩和することができます。

シーン音楽と無音時間の管理

レベルマークアップで音楽ボリュームを定義することにより、このエリアで再生されるべき音楽についてワールドコンダクターに伝えることができます。慣例に従い私たちはループさせず、しばらく後に音楽が再開するまでの間、プレイヤーが多少の静けさを味わえるようにしました。音楽システムはゲームに対し、このような小休止の期間にこれまで再生されていた音楽のメロディーやモチーフをハミングしたり口笛で吹いたりする、特別なボイスイベントをキャラクターが再生できることを知らせます。

ワールドコンダクターは現在のゲーム内の時間も把握しており、朝、日中、夜と再生するテーマのバージョンを変えてスケジューリングすることができます。さらにシーン音楽を入れない、「静かな時間」の詳細設定も可能です。

プレイヤーが特定の場所に近づいた時、除外ゾーンを定義してエリアの音楽をスムーズにフェードアウトさせ、発生した事象やこれから発生する事象の重要性を強調したり、間合いをつくったりすることができます。

通常はエリア音楽の優先順位が最も低いため、戦闘やその他の遭遇のため中断されることがあります。この場合、ワールドコンダクターは再生中のテーマを一時停止させ、優先順位の高いテーマが明示的に停止されてから、再び再生をはじめます。ちなみに一時停止されたイベントはオートダッキングに影響するため、Wwiseはそのままアクティブボイスとみなします。 

ワールドコンダクターはこれ以外にもWwiseと似た複雑なトランジションを行うこともでき、音楽小節との基本的な同期や、トランジションを隠すためのスティンガーの再生などが可能です。このようなトランジションはデータテーブルを使い設定します。

 

技術的な詳細

Wwiseプロジェクトの構成

ゲームのために作曲された音楽テーマは、それぞれほかのテーマから独立した独自の階層となっています。Work Unitは戦闘、シーン、リニアシーケンスなど、音楽の目的別に分けられています。それぞれの種類のバスに送ることでミキシングを容易にし、必要に応じてオートダッキングを選択的に適用します。

それぞれの音楽テーマがほかのテーマから分離されているため、ゲームエンジン側の実装は複雑になり、ゲームエンジン側でトランジション、スティンガー、フェードイン・フェードアウト、無音、同期などを管理する必要がありました。最後の2つは特別な要件があり、後述の通り1つのPlayingIDで管理する音楽でこれらを管理することは難しいため、私たちは特に重視しました。

基本的に複雑な部分の多くをWwiseプロジェクトから取り除き、それらをコードに取り込みました。音楽タイプによって音楽の実装方法が異なり、例えば典型的なスイッチコンテナの構成に基づくテーマもあれば、ループさせるためにコードに頼るテーマもあり、場合によって大きく異なりました。音楽システムの観点で言うと、それぞれが異なるコンダクター（指揮者）クラスを実装しおり、これからその一部について説明します。

楽団の音楽

これはダイジェティックな音楽であり、バーチャル楽団がゲーム内で指定された時に演奏します。プレイヤーがリスニングモードに入ると、カメラがキャラクターまわりをパンし出します。ここで詳しい要件を説明します：

• どの楽器や声も、シーンに個別に配置可能。
• 音楽テーマはループしない。
• シングルプレイヤーゲームであるが、プレイヤーは設定された時間に楽団の演奏を聴くものとし、プレイヤーが演奏途中にゲームに参加した場合も含め、誰もがほぼ同じ内容を聞くようにする。

ワールド内の複数の場所で完璧に同期したダイジェティック音楽を実装する方法として、私は2通り思いつきました。3D AUXバスセンドのプールを管理する方法と、各楽器を別々のイベントとして再生する方法です。私たちは後者を選びました。理由はよく覚えていません。同じ長さの複数イベントを、AK::SoundEngine::RenderAudioを呼び出す前にポストした場合、そのイベントグループは永遠に同期して再生されることを観察しました。ただし前提条件としてこれらのイベントで全く同じストリーミング、仮想化、シークテーブルの設定が必要であり、私たちは一部WAAPIを活用しながらプロジェクト全体を対応させました。

さらにWwiseのSeekOnEventアクションは制約が多く、私たちは楽団の再生位置を同期させるためにこれが必要でした。ループイベントをシークできないという最も重要な点については、楽団の楽器はすべて同じ長さのワンショットとし、必要に応じてそれを「指揮者」がループできるようにしています。

戦闘音楽

このゲームには2種類の戦闘音楽があります。ボス戦とミニ遭遇戦です。

前者を「指揮」するコンダクターは、スイッチコンテナやトランジションを用いた典型的なWwise実装であるため、先に説明します。ボス戦では指定されたパートを必ず一方通行ですすみます。例えばイントロ → ステージ1 → ステージ2 → 勝利または敗北といった流れです。汎用的なMusic_Partスイッチを実装させ、数字部分の意味を決める規則を用意しました。

一方、ミニ遭遇戦はボス戦の逆であり、ステージの段取りがなく、音楽は無限にループするようになっています。曲の構成としては音楽が固まりに分割してあり、それぞれ特徴があり、短いトランジションによって繋がっています。音楽はフェードインではじまりフェードアウトで終わり、コンダクターが再生位置を追跡しているため、一時停止された場合は同じ位置から音楽が再開されます...と言いたいところですが、人生そんなに甘くないのです。今回の場合、音楽が停止した位置を追うマーカーの場所から音楽を再開するようにしています。マーカーはちょうど音楽の固まりのはじまりに設定されています。このようなトランジション位置に音楽をフェードイン付きで開始することにより、その出会いが些細で繰り返さている感覚を強めます。

こちらの音楽はシークが必要となるため、コンダクターがループ再生を管理します。

フェードインと言えば、WwiseはコードからフェードインをコントロールするAPIを提供していません。対応策として次のシーケンスを追うことで回避できます。イベントをポストする → すぐにそれを一時停止する → 1フレーム分、RenderAudioが呼び出されるまで待つ → 指定したトランジション長さで再開する。1フレーム分待たないとWwiseが結果的にコマンドシーケンスをたたんでしまい、イベントは再生するべきだが再開するべきではないとWwiseが思い込んでしまいます。理由は忘れてしまいましたが、結果的にこの対応策をリファクタリングし、何らかの理由でフェード用に時間を補完するRTPCを使うことになりました。

コンダクターたちをワールドに繋げる

ここまで内部でさまざまな種類の音楽テーマがどのように機能しているのかを見てきました。最後に、私たちのシステムで音楽とほかのゲームシステムがどのように細かく相互作用しているのかを例で示します：

1. あるレベルの寺院の祭壇は、Wwiseのコールバックに反応してかすかな音をトリガーさせます。 
2. プレイヤーが外を移動しながらある小さな村に入ると、再生中のBGMと完璧に同期して歌うキャラクターに出会えます。
3. 太鼓の演奏がプレイヤーの注意をある地点に向けます。プレイヤーがそこに到着するとカットシーンがはじまり、格闘が映し出されます。このダイジェティックなドラムループはその後、非ダイジェティックなシネマティックス音楽に変わり、最後にドラ（銅鑼）が鳴り響き終了します。ドラの音が試合終了を意味するため、ドラを鳴らす瞬間にビジュアルがぴったり合うことが重要でした。そこでワールドコンダクター（ワールド全体の指揮者）からレベルのシーケンスプレイヤーにコールバックを送り、それを受け取ると次のシネマティックカットに飛ぶ実装としました。Wwiseのミュージックキューに特別な名前を付け、コールバックを発生させました。

すべての例の機能はConductor APIを使って実装しており、ゲームコードはWwiseについて何も知る必要がありません。

 

エピローグ

この記事は私たちのインタラクティブミュージックシステムのコンダクターの概要を比較的体系的に紹介したものであり、プレイヤーの没入感や感情的なインタラクション、そしてゲームエクスペリエンス全体を向上させる上で、中心的な役割を担ったことを説明しました。どの種類のBGMも文脈的に印象が合っているだけでなく、理にかなっていると思われるよう懸命に取り組みましたが、開発する私たちが感じたのと同じくらい、読むみなさんにも面白いと思ってもらえることを願っています。