コンテンツの引渡し: Microsoft DirectMusic ファイルの管理上のヒント

[アーティクル]
11/11/2008

Scott Selfon
Audio Content Consultant, Xbox Advanced Technology Group

November 2001

要約: 本ドキュメントは、Microsoft DirectMusic 用のコンテンツ作成ツールである Microsoft DirectMusic Producer のさまざまな側面を扱った一連の記事のうちの一編です。この記事では、コンテンツファイルを管理し、アプリケーションとともに配信するためのテクニックについて説明します。

はじめに

MicrosoftR DirectMusicR Producer を使って、ゲームの最初のレベル(面)のためのコンテンツを作成していたあなたは、ようやくそのコンテンツを開発者に引き渡す準備ができました。しかし、実際には何を渡せばよいのでしょうか? また、コンテンツを後で簡単にアップデートできるようにするには、ファイルをどのようにまとめればよいのでしょうか? このドキュメントでは、各種のファイルタイプの互いの依存関係、コンテナを使ってコンテンツの引渡しを簡単にする方法、そしてコンテンツ管理のための一般的なトリックとヒントについて説明します。

この記事では以下のトピックを扱っています。

ステップ 1: 事前の計画
ステップ 2: オーサリング
ステップ 3: コンテンツのパッケージング
ステップ 4: ランタイムファイルの保存
ステップ 5: 渡す内容の決定
関連情報

ステップ 1: 事前の計画

優れたコンテンツ管理計画では、プロジェクトの開始時に、作曲者およびサウンドデザイナ全員と、このコンテンツをゲームに組み込む開発者たちが顔を合わせて会議を開きます。この会議では、コンテンツの以下の側面に関して何らかの決定を行うか、少なくとも検討を始める必要があります。

**サウンドデザインの基本計画
**.wav ファイルを使用するのか、ウェーブトラックを含んだセグメントを使用するのか、それともダウンローダブルサウンド (DLS) コレクションの再生を含んだセグメントを使用するのか。アプリケーションは DirectMusic ライブラリのみから構築されるのか (開発者の「プログラム」)、それともMicrosoft DirectXR オーディオスクリプティングを使用するのか (作曲者／サウンドデザイナの「プログラム」)。
**ファイル名の規約
**ファイル名は 8.3 形式に制限されていないので、あるていどわかりやすい名前をつけることができます。混乱を防ぐために、複数のセグメントに同一の名前を持たせるのは避けるべきです。ただし、コンテンツが複数の異なる状況で再生される場合には、ファイル名にあまり細かい規則を付けるのはやめた方がいいでしょう。
**フットプリント
**そのプロジェクトは、オーディオのためにハードディスクとメモリ上にどれほどのスペースを割り当てるのでしょうか? そのスペースに最大限のサウンドを詰め込むために、アクティブなフットプリントを最適化する方法は? (ストリーミング、圧縮、DLS コレクション管理など)。

ステップ 2: オーサリング

これでファイルのオーサリングを開始する準備ができました。作成するセグメントの名前は開発者から指定されますが、同時にいくつかの補助ファイルも管理しなくてはなりません。セグメントのバンドトラック、スタイルトラック、およびコードマップトラックは、それぞれ1つまたは複数のDLSコレクション (.dlp/.dls )、スタイル (.stp/.sty)、またはコードマップ (.cdp/.cdm)を参照できます。これらの補助ファイルには、どのセグメントから参照されているかがわかるような名前を付けます。次のような表を作成してもいいでしょう。

セグメント	セグメントが参照するファイル
SpookyAmbience.sgt	WindWhistle.wav
	WolfHowls.dls
	WolfHowls.sty
SpookyScore.sgt	Orchestra.dls
	Whispers.wav
	Choral.dls

以下に、オーサリングの際に役立つヒントを示します。

**DLS コレクションマッピング
**複数の DLS コレクションを使用する場合には、個々の音色のパッチ情報が、他のコレクションの音色と衝突しないようにしてください。このような 2 つの音色が同時にダウンロードされた場合、目的の音色が使えない場合があります。128 x 128 x 128 個のパッチの組み合わせを使用することができるのですから、コレクション間に十分なスペースを開けるようにしてください。
**プロジェクト
**特に「レベルベース」のゲームでは、一般に個々のレベルを 1 つのプロジェクトとし、それぞれ独立に作業を行った方が、コンテンツの作成がはるかに簡単になります。

注

複数のプロジェクトを同時に開くことは可能ですが、あるプロジェクトのセグメントが別のプロジェクト内の補助コンテンツを参照することがないように注意してください。子の場合、そのセグメントを後に開いたとき、もう一方のプロジェクトが開かれていなければ、セグメントは補助ファイルを見つけることができず、参照を削除するように求められることがあります。
**DirectMusic Producer の外部でのファイルの複製
**可能な限り、オペレーティングシステムコマンドを使ったファイルのコピーは避けるようにします。個々のファイルには一意のキー、すなわち GUID が格納されています。そのファイルをDirectMusic Producer の外部でコピーすると、同じ GUID を持つファイルが 2 つ存在することになります。これらが DLS コレクションで、特定の GUID の DLS コレクションを要求するセグメントと同じディレクトリに格納された場合、間違ったコレクションが使用されてしまう可能性があります。DirectMusic Producer の中の [Copy]、[Paste]、およびプロジェクト複製コマンドは、個々のコピーごとに新しい GUID を生成することでこれを避けています。また、DirectMusic Producer は、既存ファイルの GUID と同じ GUID を持つファイルが開かれたときには、自動的に新しい GUID を生成します。

ステップ 3: コンテンツのパッケージング

コンテンツのオーサリングを終えた段階では、必ず複数のファイルが作成されています。.wav ファイルや DLS コレクションを使用する基本セグメントなどの場合には、これで十分であり、メディアが格納されているディレクトリ全体を開発者に渡して統合してもらうことになります。その後、開発者はセグメントがスタイル、コードマップ、別のセグメント、または何らかの別のコンポーネントを参照しているかどうか、またそれを発見できるかどうかを確認する必要があります。この情報は、上に示したような表を使って伝達することができるでしょう。しかし多くの場合は、すべてのコンテンツが含まれている1つのファイルを開発者に渡すことができれば、作業ははるかに簡単になります。DirectMusic では、コンテナと呼ばれるコンポーネントを使ってこれを実現できます。

簡単に述べると、コンテナはコンテンツの他の部分すべてを含んでいる (埋め込んでいる) ファイルです。また、外部ファイルを参照することで、コンテナにそれらを認識させることもできます。埋め込みと参照の違いについては、少し後で説明します。ここではまず、コンテナの 3 つの種類について説明します。

コンテナファイル
新規のコンテナファイルを作成するには、他の種類のファイルと同じように、[File] メニューの [New] をクリックします。

図 1. 新規のコンテナファイル
**スクリプト内のコンテナ
**スクリプトは、自分が使用するコンテンツを埋め込み、またセグメントやオーディオパスなどの参照先オブジェクトを利用できます。

次の図は、セグメントと 2 つのウェーブを埋め込み、いくつかのセグメントとスタイルを参照するスクリプトを示しています。参照先のファイルを、独立したランタイムファイルとして保存し、開発者に渡す必要があります。

図 2. スクリプト内のコンテナ
セグメント内のコンテナ
セグメントが使用するコンテンツは、そのセグメント内に埋め込むか、セグメント内で参照できます。セグメントコンテナを作成するには、プロジェクトツリーの中でセグメントを右クリックし、ショートカットメニューの [New] をクリックし、[Container] をクリックします。開発者はコンテナをわざわざ開いてコンテンツを取り出す必要がなく、セグメントファイルを再生するだけで済むので、セグメントは一般にスタンドアロンのコンテナファイルよりも便利です。

図 3. セグメント内のコンテナ

この 3 つのケースのいずれでも、2 つのフォルダのうちの 1 つにファイルをドラッグするか、コンテナのショートカットメニューの [Add/Remove Files] を選択することで、ファイルの追加と削除が可能です。

埋め込みと参照

コンテンツを参照するよりも埋め込んだ方がいいのは、どのような場合なのでしょうか? 作成したコンテンツが1つのセグメントと、DLS コレクション、スタイル、およびコードマップなどの補助ファイルから構成されている場合には、ランタイムの埋め込みによって、再生可能な 1 つのファイルとして簡単に渡すことが可能になります。

しかし、場合によっては、一度に 1 つのセグメントしか再生されない場合でも、複数のファイルを渡した方がよいことがあります。最も多いのは、DLS コレクションが複数のセグメントから使用されるというシナリオです。このような場合には、すべてのセグメントに DLS コレクションを埋め込むと、余分な記憶域が必要となり、同じ音色データを無駄にダウンロードしなくてはなりません。複数の異なるセグメントや複数の異なるスクリプトから参照されているウェーブについても、同じことが言えます。このような場合には、DLS コレクションやウェーブを独立したファイルとして渡すか、コンテナに入れて渡すとよいでしょう。

ただし、スタイル、コードマップ、およびその他の一般にサイズが小さいファイルについては、話は別です。これらのファイルは、同じコンテンツを何度も使用するのでない限り、それらを使用するセグメントにパッケージングすることを勧めます。

Reference Runtime フォルダは、現実にはスクリプトのみに有効です。スクリプトは、埋め込まれていないコンテンツを使用する (たとえばセグメントを再生する) ことができますが、そのコンテンツへのポインタを必要とします。一方、セグメントファイルは、自分が使用するすべてのコンテンツを暗黙のうちに参照しているので、コンテンツをセグメントコンテナの Reference Runtime フォルダにドラッグする必要はありません (この点を強調するために、セグメント用の Reference Runtime は実際に使用不能となっていることに注意してください)。コンテナファイルの場合でも、一般に参照を使用する必要はありません。

埋め込みファイルに関する最後の注意として、フォルダの名前が "Embed Runtime" となっていることに注意してください。DirectMusic Producer では、デザイン時のファイルは実際に互いに埋め込まれているわけではありません。作曲者やサウンドデザイナがコンテンツの編集を続けられるように (またこれを複数のコンテナに埋め込むことができるように)、すべてのコンテンツがランタイム用に保存されるまでは埋め込みではなく参照を使用しています。これもまた、単に DirectMusic Producer のデザイン時ファイルを使用するのではなく、ランタイムコンテンツを渡すことが重要である理由の1つです。

ステップ 4: ランタイムファイルの保存

"p" で終わるファイル拡張子を持つすべてのファイルは DirectMusic Producer のデザイン時ファイルであり、コンテンツをゲーム用に最適化するためにはランタイムとして保存しなくてはならないことに注意してください。これを行った時点で、埋め込みコンテンツは初めて実際にコンテナへとパッケージングされます。

図 4. ランタイムファイルを保存するためのメニューコマンド

ステップ 5: 渡す内容の決定

セグメントまたはスクリプトが使用するすべてのコンテンツがそこに埋め込まれている場合、どのファイルを渡すのかという問題はきわめて簡単になります。ランタイムファイルには必要となるすべてのコンテンツが含まれているので、開発者には1つの自己完結的なファイル(.sgtまたは.sptファイル)を渡すことになります。

(コンテナのReference Runtimeフォルダで、または埋め込まれていないコンテンツを参照するセグメントを作成することによって)コンテンツを参照した場合には、そのコンテンツを別途渡す必要があります。上に示した表に、このための列を追加すると便利でしょう。追加する列は、どのコンテンツが実際に埋め込まれており、どのコンテンツを別途渡す必要があるのかを示します。

セグメント	セグメントが参照するファイル	埋め込みか?
SpookyAmbience.sgt	WindWhistle.wav	Yes
	WolfHowls.dls	No
	WolfHowls.sty	Yes
SpookyScore.sgt	Orchestra.dls	No
	Whispers.wav	No
	Choral.dls	Yes

すべてのコンテンツをコンテナに格納した場合には、そのコンテナを渡し、さらにコンテナ内のどのオブジェクトをいつ使用するか (ダウンロードや再生など) を指定する指示を与える必要があります。