はじめに
私がオーディオのゲームエンジニアとして仕事を始めたのは2015年でしたが、当時のアートディレクターがWwiseについて教えてくれました。それまで、私のキャリア目標はゲーム音楽をつくることでした。インタラクティブミュージックや、ミュージックジェネレーション、そしてアルゴリズムに基づいた作曲などに、しばらく関心がありました。実は子供のころから親しんできたゲームに、すでにそれが存在していたとは、思ってもいませんでした。
興味本位で、ゲームのインタラクティブミュージックの作曲方法の可能性を研究しながら、GoogleやYouTubeを頼りに独学の旅を始めました。この時に大いに影響を受けたのが、KejeroのYouTubeチャンネル『Music By Kejero』。最初のころ、本当に励みになりました。この動画チャンネルは音楽のデザイン方法としてVertical（縦型）テクニックやHorizontal（横型）テクニック、スティンガー、トランジションセグメント、ハイブリッド型など様々な方式を、系統立てて説明してくれます。これらの技法の説明を聞くうちに、私はデザイン方式と音楽実装の関係について考えるようになりました。それから数年は、YouTubeでゲームのインタラクティブミュージックに関する動画を片っ端から見ました。ほかにもAudiokineticのブログや、DesigningMusicNow、Melodriveのブログなど様々な情報源から出た、このトピックについての記事をほとんど読みました。おかげでゲーム音楽の発展の歴史を、ブザーやチップチューンから、アダプティブオーケストラ、ハードウェアFMシンセサイザー、そしてアルゴリズムで生成する打楽器に至るまで、学ぶことができました（インテリジェント・ミュージックシステム）。このとき初めて、Lucas Artsの天才的なエンジンiMuseを知りましたが、すでに1991年からハイブリッドテクニックやプロシージャルオーディオが実装されていたのです。また、音楽デザインにオーディオとMIDI技術を組み合わせた大胆で独創的な方法にも出会いました（例えばGet Even）。
教材として
学ぶことは、常に楽しいです。ただ、いざ知識を実践に移そうとしたときに、私は次のことに気づきました。
- ゲームのインタラクティブミュージックに関する教材の多くは、主にゲームエンジンが駆動するミュージックデザインを扱っています。一方、オーディオエンジンがゲームエンジンに駆動されない状況については、ほとんど言及されていません。
- ゲーム内のオーディオデザインには様々な手法を組み合わせて使っているので、よく「ハイブリッド」と呼ばれています。ところが、同じ単語でもKejeroとオリビエ・ドリヴィエール氏（Olivier Derivière）では、そのとらえ方が全く違うこともあります。
- また、同じ処理方式でも、呼び名が違うことがあります。例えば「Vertical（縦型）テクニック」のことを「Vertical Remixing（縦型のリミキシング）」と呼んだり、「レイヤリング」と呼んだりします。人によっては、「マルチトラック」を業界用語として用いて、このような手法を指したりします。
- インタラクティブミュージックの制作方法として、まだミキシング技術に充分な注目が集まっていません。これこそ、オリビエ・ドリヴィエール氏の言う「ハイブリッド」（オーディオ+MIDI）の大事なポイントです。これをベースに、もっと複雑なミュージックデザインが実現できるはずです。
（ハイブリッド型インタラクティブミュージックについては、オリビエ・ドリヴィエール氏自身が書いた記事 Part 1 、 Part 2 が詳しいです。）
私の解決方法
マイケル・スウィート（Michael Sweet）氏は、 多くのゲームが複数のアダプティブミュージック技術を同時に利用しているという事実を否定できない、と言っています。ただ、私たちはコンポーザーとしてゲームミュージックをより上手に作曲するために、各技法の一般的なガイドラインを整理する価値がある、とも言っています。
芸術的な制作に可能なアプローチの数は、無限にあります。とはいえ、私たちがショートカットやプロジェクトのひな形を日々の仕事に取り入れているのと同様に、デザイン方式の概要をまとめておけば、混乱を事前に回避でき、ワークフローを最適化できるはずです。このことは、試行錯誤の過程で発生しがちな無駄を減らし、ゲームに一番適した確実な音楽のデザイン方式を素早く見定めるために重要です。浮いた時間は、複雑で洗練された実装のために回せます。そこで、私は処理方式を分類できるように、いくつかの基準を作ってみました。自分が音楽をデザインする上での指針とすることが目的でしたが、読者の皆さんのご参考になるかもしれません。
User-Driven方式と、Game Driven方式
まずポジションとAuxiliary sendsに基づいて、音楽の実装がゲームエンジンに左右されるかによって、コンセプトがWwiseに送信されます。ここで、私は可能な処理方式としてUser-Driven（ユーザー主導）とGame Driven（ゲーム主導）の2つの分類を設定しました。こうすれば、ゲームエンジンとは独立して動く動的なミュージックシステムも、その重要性に見合ったとらえ方ができます。つまり、もっと注目され、それだけ発展する可能性がある、ということです。
静的な方式と、動的な方式
次に、実装結果が期待通りに実行されるかどうかで、さらにStatic（静的）とDynamic（動的）の2つの設計方式に分けました。音楽のデザインがリニア（線形）なのか、非リニア（非線形）なのかを、正しく区別できます。状況に適した処理方式が、選びやすくなるはずです。
注：ほとんどの場合、ゲームのプレイヤーの動きなどは予測が不可能です。そこでGame Driven（ゲーム主導）方式を使ったゲーム音楽を、すべてDynamicな音楽ととらえることもできますが、例えばリアルタイムのカットシーンを同時に使い、それに従って様々なミュージックセグメントをリニアに再生させるということも、可能です。このとき、音楽をオーディオファイルとしてレンダリングしていなくても、このGame Driven方式自体をStaticとみなすことも、ありえます（つまりGame DrivenかつStaticの方式が存在するということです）。このような方式はすべてGame Drivenであるのに違いはなく、処理がリニアに行われるかどうか、というのがポイントになります。よってStaticやDynamicを示していません（下の図のとおり）。
ミキシングと、トランジション
マイケル・スウィート氏は、DesigningMusicNowに掲載の記事で、主流のデザイン方式6種を、「Vertical Remixing（縦型のリミキシング） (Layering) 」と、「Horizontal Re-Sequencing（横型のリシーケンス）」の2つの主要カテゴリーに分けています。ゲームのインタラクティブミュージックを話題にするときに、私たちがよく思い浮かべる最もポピュラーな用語です。
Vertical Remixing (Layering) 方式はその名や性質が示す通り、どれだけ複雑な手法を取り入れたとしても、結局は常にミキシングに関係します。
Horizontal Re-Sequencing方式は、要はミュージックセグメントの切り替え方と、切り替え時のトランジションの仕方のことです。そこで私は、処理する対象に着目し、処理方法を「ミキシング」と「トランジション」の仕方によって、さらに分別しました。
概要
さて、上記のような分類方法に従うと、次の8種類の処理方式が成立します。
- User-Driven Static Transition（ユーザー主導の静的なトランジション） — Music Segmentの処理に使い、結果は予測でき、ゲームの状況に影響されない。
- User-Driven Static Remixing（ユーザー主導の静的なリミキシング） — 音楽のミキシング処理に使い、結果は予測でき、ゲームの状況に影響されない。
- User-Driven Dynamic Transition（ユーザー主導の動的なトランジション） — Music Segmentの処理に使い、結果は予測できず、ゲームの状況に影響されない。
- User-Driven Dynamic Remixing（ユーザー主導の動的なリミキシング） — 音楽のミキシング処理に使い、結果は予測できず、ゲームの状況に影響されない。
- Game-Driven (Static) Transition（ゲーム主導の静的なトランジション） — Music Segmentの処理に使い、結果が予測でき、ゲームの状況に影響される。
- Game-Driven (Static) Remixing（ゲーム主導の静的なリミキシング） — 音楽のミキシング処理に使い、結果は予測でき、ゲームの状況に影響される。
- Game-Driven (Dynamic) Transition（ゲーム主導の動的なトランジション） — Music Segmentの処理に使い、結果は予測できず、ゲームの状況に影響される。
- Game-Driven (Dynamic) Remixing（ゲーム主導の動的なリミキシング） — 音楽のミキシング処理に使い、結果は予測できず、ゲームの状況に影響される。
注：最後の4つはすべてGame Driven（ゲーム主導）方式で、唯一の違いは、その処理がリニアかどうかです。よってStaticやDynamicを示していません（下の図のとおり）。
Interactive Music Hierarchyの構成要素
新しい分類基準を確立できたところで、それをミュージックデザインの実践に役立てたいと思いますが、ここで使うツールがWwiseです。始める前に、このツールを新たな視点で見る必要があります。
私が理解するところのWwiseのインタラクティブミュージックのシステム構成を共有したいので、マインドマップをお見せします。
このPNGファイルは、 https://share.weiyun.com/5XNv7gf にあります。
この図で、私はミュージックデザインを構成する各要素の役割に応じて、色分けしています。
赤ボックスはUser-Driven方式を適用できるもの、青ボックスはGame Driven方式を適用できるもの、紫ボックスはUser-DrivenとGame Drivenのどちらの方式も適用できるものを示しています。黄ボックスはTransition Manager（つまりProperty EditorのTransitionsタブ）を示しています。こちらは、User-DrivenとGame Drivenのどちらの方式を使うかに関わらず、様々なミュージックデザインの仕方に取り入れることができるので、分けて示しています。緑ボックスは、2019.1.0から導入されたMusic Event機能を示しています。こちらも別に示してあるのは、音楽デザインの可能性を大幅に増やしてくれるからです。詳しくは後述します。
注：色分けをする前に、私は各構成要素のコアの機能に配慮して、使う技法を限定しました。複雑になり過ぎないようにするためです（一般的に、ミキシング関連の複雑性）。Mixingと書かれた小さい紫色のボックスがあります。これらを展開すると、Interactive Music Hierarchyのコア機能以外の機能（State、RTPC、ポジショニング、HDRなど）に関して実装可能な処理方式を見ることができます。
マクロのレベル
Music Switch Container
まず最初に、Music Switch Containerがあります。Music Switch Container Association Editorは、Music Switch Containerを編集するための専用ウィンドウです。個別または組み合わせたGame Sync（SwitchやState）と、その再生の対象との関係を、設定できます。そして、起こりうるトランジションとためにどのように実装するのかを、Transition Managerで設定します。このため、Music Switch Containerは、Game Driven Transitionで扱いやすい構成要素です。
注：Music Switch ContainerのAvailable Game Syncs（利用できるゲームシンク）に、StateとSwitchがあります。どちらもトランジションを実行するために使えます（機能がコアか、非コアかに関わらず）。ただしSwitchはStateと異なり、Game Parameterで動かすことができます。このため、違うインタラクション（やり取り）のモードを使えます。
Music Playlist Container
次にMusic Playlist Containerを見てください。Music Playlist Containerは、PlaylistにあるMusic Segmentの再生順を制御します。再生方法としてRandom（ランダム順）とSequence（並び順）のどちらにも対応できます。よってMusic Playlist Containerは、User-Driven (Static) Transitionや、User-Driven (Dynamic) Transitionのときに、扱いやすい構成要素となります。
注: Sequence ContinuousやSequence Stepの設定はリニア型であるUser-Driven Static Transitionに使い、Random ContinuousやRandom Stepの設定は非リニア型のUser-Driven Dynamic Transitionに使います。
概要
この2つの構成要素は、Wwiseでインタラクティブミュージックを実現するシステムにおいて、どちらもトランジション関連です。Music Switch ContainerやMusic Playlist Containerという要素を使えば、User-Driven (StaticまたはDynamic) Transition方式も、Game Driven (StaticまたはDynamic) Transition方式も、効率的に実装できます。なお、これらはインタラクティブミュージックのシステムで、最も大きい構成要素です。つまり、最上位にある要素です。Remixing方式にそのまま使うには、ふさわしくありません。ときには、1つのEventを使って、このような構成要素を複数、同時に再生する必要がでてきます。このブログ連載の中編（Part 2）では、ここで紹介した方式を使って、Wwiseでテリー・ライリーの作品『In C』を生成する方法を説明したいと思います。
ミクロのレベル
次に、ミクロの視点で考えてみます。こちらの構成要素（Music Segment、Music Track、Clip）は紫のボックスで表示されています。User-Driven（ユーザー主導）とGame Driven（ゲーム主導）のどちらの方式でも使える要素で、前述のMusic Switch ContainerやMusic Playlist Containerとは違い、赤や青のボックスで書かれた方式は、Transition関連ではなく、Remixing関連です。音楽デザイン方式の選択肢が、上位レベルではなく詳細の設定にあります。そして、すべてミキシング関連の選択肢となります。
Music Segment
まず最初に、Music SegmentではTransition Managerが水色になっていて「Transition Manager: No」となっているのに気づきます。理由は、Music Segmentをクリックして選択したときに、Property EditorにTransitionsタブが表示されないからです。
Music Segmentは、Wwiseのインタラクティブミュージックのシステムの中でも最も特別な構成要素で、まずMusic Segmentにはシンクポイント（Entry Cue、Exit Cue）があります。これを使って、子の構成要素と親の構成要素が連携します。確実にTransitionがうまく動作するようにします。
次にMusic SegmentアイコンやMusic Trackアイコンを通して、Music Segmentに複数のMusic Trackがあるかもしれないことが分かります。そのすぐ下にある要素が、Music Trackです。Music Trackには、セグメント間のトランジションがありません。そこでUser-Driven RemixingやGame Driven Remixingを扱うときの構成要素としては、Music Segmentが向いています。
注：いわゆる従来型の縦型方式（Game Driven Remixing）が、Music Segmentに最も適しています。
また、Entry CueやExit Cueは、Music Segmentに設定します。プログレッシブロックに似たリズムチェンジを達成するには、Bars/Beats設定やEntry Cue/Exit Cue設定が異なる、複数のMusic Segmentを使います。
Music Track
それでは、Music Trackを見てみます。Music Trackは、Music Segmentに似ています。User-Driven Remixing方式と、Game Driven Remixing方式の、どちらを実装するのにも使えます。違うのは、Music Trackで再生するコンテンツを変えることでミキシングにバリエーションが生まれることです。User-Driven (Dynamic) Remixing方式には、Random StepやSequence Stepに設定したTrackを使います。Game Driven Remixing方式は、Switchを設定したTrackを使って実装します。インタラクティブミュージックのシステムにおいて、Music Trackを「ボイス」としてとらえると分かりやすくなります。Music TrackをTransition Managerと組み合わせることで、Discrete（離散的）なリミキシングを実装できます（逆にボリュームをRTPCで制御するとContinuous（連続的）なリミキシングとなります）。
注：Sequence Step設定のMusic Trackで、Static Remixing方式を実装することはできません。Sequence Step設定のMusic Trackは、再生するたびに、再生するコンテンツが次のSub-Trackへと切り替わるからです。この方式では、すべてを制御することができません。設定できるのは、切り替える（Switchする）順番だけです。
注：Switchを設定したMusic Trackで利用できるGame Syncは、表示されているように、StateとSwitchです。どちらもトランジションを実行するために使えます（機能がコアか、非コアかに関わらず）。ただしSwitchはStateと異なり、Game Parameterで動かすことができます。このため、違うインタラクション（やり取り）のモードを使えます。
Clip
次はClipです。Audio Clipを使って実行できるのはUser-Driven Static Remixing方式だけです。言い換えれば、単純で自動化されたボリュームやLPFやHPFの編集以外は、できません。一方、MIDIクリップを使えば、多数の方式を実装できます。ただし、そのほとんどがUser-Driven RemixingまたはGame Driven Remixingとなります。MIDI自体は、音を出しません。Actor-Mixer Hierarchyにあるオーディオオブジェクトをトリガーする必要があります。オブジェクトとは、ソースプラグインや、サンプルが入っている構成要素のことです。MIDIファイルのCC情報をGame Parameterとして使い、Switch ContainerやBlend Containerを制御して、まるでUser-Driven（ユーザー主導）のような、Game Driven Remixingを実現できます。ただ、2019.1.0から導入されたMusic Event機能のおかげで、User-Driven方式とGame Driven方式の間の変換が、より簡単になりました。コンポーザーにとって、使えるUser-Driven方式の種類が、格段に増えました。
注：MIDIによってトリガーされたソースや、サンプルや、Containerオブジェクトをミキシングすることは、Interactive Music Hierarchyにある構成要素によっては実現できません。それは、Actor-Mixer HierarchyまたはMaster-Mixer Hierarchyで実装する必要があります。
MIDIの長所
Music Event機能がもたらす新たな可能性を活かすには、従来のMIDI技術にもっと目を向ける必要があります。初期の頃のゲーム音楽の発展は、MIDIと切り離して語ることはできません。MIDIが1980年代に発表されると、コンピュータ音楽を開発するための一般的な情報交換プロトコルとして、すぐに様々なプラットフォームで採用されました。LucasArts開発のiMUSEエンジンも、当初はMIDIベースでした（後にMIDIモジュールは削除されました）。ところがCD音源が登場すると、MIDIの人気は衰えました。その主な原因は、プレイヤーの機器で再生されるMIDI音楽の実際の実装方法を、コンポーザーが確実に事前に把握することができず、また、MIDI技術の方がミキシングの観点でオーディオベース方式と比べて利便性が劣ったからでした。
それが、2014年にWwiseのMIDI音楽機能が導入されると（MIDIはオーディオベースの枠組みの中に組み込まれています）、以下のようなMIDIの優位性が、再び明白になったのです。
1. MIDIは、データフットプリントが小さいです。オーディオファイルと違い、MIDIファイルは電子楽器の楽譜のようなものです。このため、MIDIアセットで音楽バリエーションを増やした方が、オーディオアセットで同じことを行うより、負荷がかなり低いです。MIDIを通して実装する音楽コンテンツが増えれば増えるほど、MIDIの優位性が見えてきます。Wwise Tour 2018で、Remedyのオーディオチームが『Control』のミュージックデザインについて発表しました。Pythonを使ってバッチ生成した、異なるリズムパターンの多数のMIDIアセットを見せてくれました。こうして、データ量全体への影響を最小限に抑えつつ、無制限に広がる変化に富んだ音のディテールを確保しているのです。自動生成や自動投入により、音楽のビートを非常に簡単に切り替えることができます。リズムのバリエーションを生み出すこの方式は、ピッチのあるアセットにも応用できます。
2. 音楽や芸術という観点で、様々な音の目的に合わせてオーディオトーンを変化させるのに、MIDIアセットを活用できます。また、特定の状況で、聴覚的な役割（モチベーションなど）同士の内部的な接続を維持するために、MIDIアセットを利用できます。
3. モジュラーシンセシスの観点から、MIDIノートをエンベロープのトリガーとしてWwiseで使えば、リアルタイムのシンセシスを導くことができます。そうすれば、オーディオだけよりも有機的なバリエーションを、より多く入手できます。さらに、MIDIノートのベロシティが異なる、大量のMIDIトラックを、クロックシグナルとして使い、音楽をリアルタイムで、異なるテンポで合成することもできます（Audiokineticブログの、オリビエ・ドリヴィエール氏の 連載 が参考になります ）。また、静的な自動化のためにも、MIDI CCは貴重な情報源です。ユーザーはMIDIデータのCC情報を使い、リアルタイムでシンセシスのパラメータを動かすことができます。また、この情報を使って自分のゲームの芸術的な表現をレンダリングすることも可能です。
Music Event
MIDIの強みを理解したところで、今度は2019.1.0から導入されたMusic Event機能について考えます。この話題を最後にもってきたのは、Music EventがMIDIノートよりも強力だからです（MIDIノートはClipとしてしか使えません）。Music Eventは、Clip内にあるのではなく、独立して存在します。オーディオオブジェクトを再生する以外にも使えます。Eventとほぼ同じことができます。Music Eventで、音の再生やミキシングやサウンドエンジンを、様々な方法で制御でき、これでアニメーションを動かすことも可能です。「PDX」の名でも知られるピーター・ドレッシャー氏（Peter “PDX” Drescher）は、最近のブログ記事でMusic Eventとアニメーションシーケンスのやり取りについて書いています。
上図は、Music Eventの下に各種Actionを置き、音楽デザインの観点から簡単に分類したものです。これまではゲームコールをゲームエンジンから送信し、Eventをトリガーする必要がありました。ミュージックデザイナーは、Music CallbackやCustom Cueを使って同じことを達成することもできましたが、それでも、ほかのタスクは依然Wwise外で行う必要がありました。つまり、プログラマーの助けが必要でした。今は、そのようなタスクをすべて、自分でWwise上で完了できます。おかげでかなり効率的になったばかりでなく、クリエイティブな可能性がだいぶ広がりました。
例えば、Music Switch Containerであれば、ミキシングをコントロールするRTPCやStateを取り入れることで、上図に示された通り、Music Eventを使えばEvent ActionでSet Game ParameterやSet Stateを選択できます。こうしてミュージックデザイナーは、ミキシングのバリエーションをつくり出すのにMusic Eventを使い、User-Driven Static Remixing方式を実践できます（また、Sample & HoldをMusic Eventでコントロールして、User-Driven Static Remixing方式も実践できます）。
もう一度、Clipのレベルに戻ります。Music Eventがあれば、Switch ContainerやBlend Containerを正確に制御できます。ミュージックデザイナーは、Kontakt楽器を、DAWで使うのと同じようにゲーム内で自由に使えます。（KeySwitchやSample Morphingをゲームに取り込むのを、想像してみて！）
このブログの中編（Part 2）では、今回紹介した8つの処理方式のメリットやデメリットを探り、さらに、Wwiseでモーツアルトの『サイコロ遊び』と、テリー・ライリーの『In C』を再構築してみます。また、後編（Part 3）では、ゲーム音楽を作曲するときの、コンピュータ支援作曲ツールの使い方を紹介したいと思います。お楽しみに！
コメント