JP2006252558A - 拡張コンテンツビルドパイプラインのためのシステムおよび方法 - Google Patents

Abstract

【課題】拡張コンテンツビルドパイプラインのためのシステムおよび方法を提供する。
【解決手段】例示的なコンテンツビルドパイプラインは、様々なゲームコンテンツエディタおよびツールを使用して生成されるゲームコンテンツへの参照を含む標準ＸＩＦファイルファーマットを使用するコードビルド処理に基づいている。この標準ファイルフォーマットは、コンテンツビルドが必要とする情報をメタデータとして含むことができ、それにより、標準コンテンツビルドパイプラインが可能になる。これは、複数のゲーム専用フォーマットに基づき、したがってエクスポータを使用する必要のあるのものとは異なる。ただし、ゲームエンジン開発者は、その後、ＸＩＦファイルを、それらの特定のゲームエンジンフォーマットに最適化することができる。
【選択図】図３

Description

本発明は一般に、ソフトウェア開発に関し、より詳細には、コンピュータゲームなどの対話式マルチメディアソフトウェア向けコンテンツの開発、統合、および編集に関する。

コンピュータゲームの推進力は、ゲームコンテンツそれ自体、すなわち、レベル設計、３Ｄモデル、サウンド、アニメーション、映画、テクスチャ、ゲーム脚本（ゲームがどのように振舞うか）などに向かっている。ゲームコンテンツはまた、より巨大化し複雑化し続けている。これは、どんな対話式マルチメディアアプリケーションに対しても当てはまる。ゲームが成功するには、一流のコンテンツを提供する必要があり、それを提供する最も良い方法は、アーティストおよび設計者が新しい資産を可能な限り容易かつ迅速に作成し、プレビューし、追加し、手直しすることができるように、コンテンツパイプラインを最適化することである。

コンテンツパイプラインとは、構想から始まってゲームに投入できるようになるまでにすべてのゲーム資産がたどる経路である。ゲーム資産（またはコンテンツ）には、コード以外のすべてのもの、すなわち、モデル、テクスチャ、マテリアル、サウンド、アニメーション、映画、脚本などが含まれる。パイプラインを通る過程で、資産は、変換され、最適化され、粉々に切り刻まれ、あるいは組み合わされたりする可能性がある。最終的に、その資産は、ゲームの最終バージョンとして出荷される形になる。

コンテンツパイプラインを定義する際に考慮すべき第１の問題は、その効率性である。アーティストおよび設計者の大編成チームがゲームコンテンツを絶えず作成し手直しするにあたり、コンテンツパイプラインがクリティカルパスとなる。プロジェクトの過程で、パイプライン内でわずかに効率が下がっても、会社にはすぐに数千時間もの無駄な工数のコストがかかる。あるいは、コンテンツ作成者が自分たちの仕事を頻繁にプレビューしないと、ゲームの品質全体が悪影響を受ける。

考慮すべき他の主要な点は、強靭性（robustness）である。コンテンツパイプラインが破断した場合、すぐにプロジェクト全体が危うくなり得る。パイプラインが修繕されるのを待って３０人の人員を遊ばせておくことも、あるいはそれに対処し、その結果、作業の半分を無駄にすることもできない。何が起ころうと、パイプラインは常に正しく働かなければならない。

コンテンツビルドパイプラインがどのように見えるかは、しばしばプロジェクトによって異なる。極端な場合、一部のプロジェクトでは、パイプラインは最小限で非公式なものである。すなわち、資産はツールからエクスポートされ、直接ゲームにロードされる。単純なゲームの場合はそれで十分なことがあるが、通常大きなプロジェクトにおいては、それではうまくいかない。次のようないくつかの事項を考慮する必要がある。例えば、多数の人員が作業できるようにするためにファイルをどこに格納するか、複数プラットフォーム用の資産をどのように扱うか、リソースのフォーマットをどのようにすれば簡単に変更することができるか、追加処理をリソースにどのように適用することができるか、についてである。

他方では、パイプラインは、非常に奥深く手の込んだものであり得る。ゲーム向けの現在のコンテンツビルドシステムを形にするのに伴う大きな問題は、そのシステムが通常、いくつかのゲーム専用ファイルフォーマットに基づいていることである。ゲームエンジンが専用ファイルフォーマットを必要とするので、ゲームでは、そのコンテンツビルドシステム全体を、この専用ファイルフォーマットを使用するように適合させている。ゲームファイルフォーマットに対してどんな変更があっても、パイプライン内に大きな混乱が起こり、それによってターンアラウンドタイムが大きな影響を受けてしまう。

この点に関連して、より効率的で、強靭で、拡張可能で、標準化されたコンテンツビルド処理を提供するシステムおよび方法が求められている。

当技術分野の上記の欠点に鑑みて、本発明では、拡張コンテンツビルドパイプライン（extensive content build pipeline）用のシステムおよび方法を提供する。対話式マルチメディアソフトウェアアプリケーションのコンテンツ用のソフトウェアビルドを可能にする方法が提供される。この方法は、標準化ファイルフォーマットに従って、前記コンテンツに関する情報を含む少なくとも１つのファイルを作成することを含む。前記情報は、同じ前記コンテンツを使用する、異なる複数の対話式マルチメディアソフトウェアアプリケーションに対して、前記コンテンツのソフトウェアビルドを実施するために必要なものである。また、対話式マルチメディアソフトウェアアプリケーションのコンテンツ用のビルドでは、コンテンツを、複数の対話式マルチメディアソフトウェアアプリケーションのそれぞれが受け入れることのできるように、複数の対話式マルチメディアソフトウェアアプリケーションのそれぞれに専用のフォーマットに変換する。さらに、コンテンツを、前記コンテンツに関する標準化ファイルフォーマットの前記情報を使用して、複数の対話式マルチメディアソフトウェアアプリケーションのうちの少なくとも１つに最適化された少なくとも１つのフォーマットに変換することもできる。本発明のその他の利点および特徴については、以下に説明する。

本発明の様々な実施形態の完全な理解が得られるように、特定のいくつかの詳細について、以下の説明および図面に記述する。コンピューティングおよびソフトウェア技術にしばしば関連する、周知のいくつかの詳細については、本発明の様々な諸実施形態を不必要にわかりにくくするのを避けるために、以下の開示では記述しない。さらに、以下に述べる詳細の１つまたは複数がなくても、本発明の他の諸実施形態を実施できることが、当業者には理解されよう。最後に、以下の開示におけるステップおよび順序を参照して様々な方法を説明するが、そのような説明は、本発明の諸実施形態を明確に実装するためのものであり、これらのステップおよびステップの順序は、この発明を実施するのに必要なものと見なすべきではない。

（概要）
拡張コンテンツビルドパイプラインのためのシステムおよび方法が提供される。例示的なコンテンツビルドパイプラインは、様々なゲームコンテンツエディタおよびツールを使用して作成されたゲームコンテンツに関連し、かつ、それを参照するメタデータを含む標準ＸＩＦファイルフォーマットを使用するコードビルド処理に基づいている。メタデータは、たとえば、様々なバイナリコンテンツファイル用の、ルーティング、コンテキスト、および適切な読取り機構を含むことができる。したがって、標準ＸＩＦファイルは、バイナリコンテンツデータ自体を含む必要がない。この標準化ファイルフォーマットは、コンテンツビルドで必要とされる情報を含むことができるので、このフォーマットによって標準コンテンツビルドパイプラインが可能になる。これは、複数のゲーム専用フォーマットに基づくのとは異なる。しかし、ゲームエンジン開発者はその後、ＸＩＦファイルをその特定のゲームエンジンフォーマットに合わせて最適化することができる。

第１に、様々なコンテンツ開発エディタおよびゲーム開発ツール、ならびにそれらの相互関係および様々なゲームエンジンとの関係を説明し、併せて、現在、コンテンツビルドが一般に複数のゲーム専用フォーマットに基づき「エクスポート」処理を使用してどのように実施されるかを説明する。これについては、以下のセクション「ゲームコンテンツおよび典型的なビルドパイプライン」に示す。第２に、様々なゲームエンジン用の標準コンテンツビルドパイプラインを可能にするための、拡張コンテンツビルドパイプラインおよびそこで使用する標準化ファイルフォーマットに関する説明および例を、セクション「拡張コンテンツビルドパイプラインおよび標準化ファイルフォーマット」に示す。第３に、２つの代替実施形態を、セクション「代替実施形態」に記載する。そのセクションでは、特定の必要性のためにある種のトランスフォーマを再使用または省略する特定のパイプラインを提供するために、標準コンテンツパイプラインがパイプラインの開始点で分岐している。最後に、本明細書に記載するシステムおよび方法と共に使用するのに一般に適していると認められるコンピューティングおよびネットワーク環境に関して説明する。例示的なコンピューティングおよびネットワーク化された環境に関連する図面のマテリアルは一般に例示のためのものであるので、対応する説明は、この明細書の最後の「例示的なコンピューティングおよびネットワーク環境」と題するセクションに委ねる。

（ゲームコンテンツおよび典型的なビルドパイプライン）
まず図１を参照すると、様々なコンテンツ開発エディタおよびゲーム開発ツール、ならびにそれらの相互関係および様々なゲームエンジンとの関係を一例として示すブロック図が示してある。

例示の目的で「ゲーム」および「ゲームコンテンツ」について言及しているが、本明細書に記載するコンテンツおよびビルド処理は、従来のビデオゲームアプリケーションに限定される必要はなく、どんな対話式マルチメディアプログラムまたはアプリケーションにも適用可能である。したがって、「ゲーム」を、コンピューティング環境における任意の対話式マルチメディアプログラムまたはアプリケーションとして定義する。

様々なゲームエンジン２を表すブロック、およびゲーム用のコンテンツ作成ツール、エディタ、およびビルドツールを表す様々なブロックが示してある。これらは、アニメーションコンテンツツール３、３Ｄエディタ４、コンバータ６、メッシュ／マテリアルコンテンツ８、映画コンテンツツール１０、ゲーム資産変換ツール１２、ユーザインターフェース（ＵＩ）作成／メニューツール１４、オーディオコンテンツツール１６、リアルタイムレンダラ１８、ワールド／レベルエディタ１９およびシミュレーションテクノロジーツール２０、マルチプレーヤテクノロジーツール２２、およびビルド処理ツール２４を含んでいる。ゲームエンジン２、たとえばＶａｌｖｅ Ｈａｌｆ Ｌｉｆｅ ２（登録商標）またはＥｐｉｃ Ｕｎｒｅａｌ（登録商標）は、入力として、様々なエディタおよびツールから出力されるコンテンツおよび資産を受け取る。しかし、コンテンツビルド処理がこのコンテンツを受け取る任を負い、それをゲームエンジン２で実行することが可能なフォーマットに変換する。一部のコンテンツは、追加のツールまたはエディタによって処理してから、コンテンツビルド処理を介してゲームエンジンで受け取ることができる。たとえば、Ａｌｉａｓ Ｍａｙａ（登録商標）またはＤｉｓｃｒｅｅｔ ３Ｄ Ｓｔｕｄｉｏ Ｍａｘ（登録商標）などの３Ｄエディタ４からのコンテンツを、メッシュ／マテリアルコンテンツ８、たとえばＰｉｘｏｌｏｇｉｃ Ｚ−Ｂｒｕｓｈ（登録商標）に入力して細部を追加し、その後、Ａｄｏｂｅ Ｐｈｏｔｏｓｈｏｐ（登録商標）で作成されたテクスチャを適用することができる。また、３Ｄエディタ４からのコンテンツを、ゲーム資産変換ステップ１２を通過させてから、ビルド処理を施し、ゲームエンジン２で実行することもできる。同様に、映画コンテンツでは、Ｋａｙｄｒａ ＭｏｔｉｏｎＢｕｉｌｄｅｒ（登録商標）、またはＯＣ３ Ｉｍｐｅｒｓｏｎａｔｏｒ（登録商標）からのアニメーションコンテンツ３を、ＡＶＩＤ Ｘｐｒｅｓｓ（登録商標）またはＰｉｘａｒ ＰＲＭａｎ（登録商標）などの映画コンテンツツールを介して渡すことができる。その後、これをたとえばＢＩＮＫ（登録商標）を使用して映画に圧縮する。この場合、ビデオカード（ＡＴＩ（登録商標）またはＮＶｉｄｉａ（登録商標））またはＰｉｘｏｍａｔｉｃ（登録商標）を使用してゲームエンジン２用の映画をレンダリングする。

次に図２を参照すると、ゲーム専用の中間ファイルフォーマットおよびカスタムエクスポータを必要とする、図１に記載したコンテンツのビルドが可能な、コンテンツビルドパイプラインを示すブロック図が示してある。一例として、コンテンツ作成者を示す。モデル作成者２６、アニメーション作成者２８、およびオーディオコンテンツ作成者３０はそれぞれ、おそらくいくつかの様々なコンテンツ作成ツールおよびエディタを用いて、コンテンツを作成する。たとえば、モデル作成者はＤｉｓｃｒｅｅｔ ３Ｄ Ｓｔｕｄｉｏ Ｍａｘ（登録商標）を使用し、アニメーション作成者もＤｉｓｃｒｅｅｔ ３Ｄ Ｓｔｕｄｉｏ Ｍａｘ（登録商標）を使用することがあり、オーディオコンテンツ作成者はＳｏｎｉｃ Ｆｏｕｎｄｒｙ ＳｏｕｎｄＦｏｒｇｅ（登録商標）を使用することがある。各コンテンツ作成ツールは、独自の専用ネイティブファイルフォーマットを生成する。たとえば、Ｄｉｓｃｒｅｅｔ ３Ｄ Ｓｔｕｄｉｏ Ｍａｘ（登録商標）は、．ｍａｘフォーマット３８、４０でファイルを生成する。また、オーディオコーデック３６は、そのネイティブフォーマットでファイルを生成し、そのファイルは、Ｓｏｎｉｃ Ｆｏｕｎｄｒｙ ＳｏｕｎｄＦｏｒｇｅ（登録商標）などのオーディオコーデックを使用する任意の様々なツールを使用して生成することができる。ビルドパイプライン４４は、様々なフォーマット３８、４０、４２でこのコンテンツを受け取り、たとえばＭｉｃｒｏｓｏｆｔ Ｘｂｏｘ（登録商標）４７またはＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステム４８を実行するＰＣなど特定のゲームプラットフォーム上で実行する、特定のゲームエンジン４６で実行することが可能なフォーマットに変換する任を負う。

ゲームエンジン４６が専用ファイルフォーマットを必要とするので、ゲームでは、そのコンテンツビルドシステム全体を、この専用フォーマットを使用できるように適合させる。ゲームファイルフォーマットに対してどんな変更があっても、ビルドパイプライン４４に大きな混乱が起こる。コンテンツ作成者２６、２８、３０は、当然ながらその仕事にとって最良のツールを使用するつもりである。これらのツールにはその独自の専用ファイルフォーマットがあるので、現在ゲームスタジオでは、コンテンツ作成ツールから情報を取り出し、その情報を自分独自のゲーム専用フォーマットにエクスポートする「エクスポート」処理４９を作成する必要がある。これらのエクスポート処理の例が、Ｄｉｓｃｒｅｅｔ ３Ｄ Ｓｔｕｄｉｏ Ｍａｘ（登録商標）エクスポータ５０、５２およびオーディオコーデックエクスポータ５４として図２に示してある。

ゲーム専用中間ファイルフォーマットが確立された後、ゲームコンテンツビルドシステムでは、実際にビルドを実施できるようにパイプライン６２を構築する。ここでは、様々なコンテンツ（または資産）タイプに対して個々に、たとえばテクスチャ圧縮トランスフォーマ５６、詳細レベル（ＬＯＤ）トランスフォーマ５８、およびサウンドトランスフォーマ６０など、各ゲーム専用フォーマット用のトランスフォーマを使用して、エクスポータ５０、５２、５４から生成されたゲーム専用中間ファイルフォーマットを操作する。トランスフォーマは基本的に、ゲーム用に作成されるようにゲームデータを操作する１本のコードである。トランスフォーマの数およびタイプは非常に様々であり、ビルドパイプライン４４には任意の数のトランスフォーマがあってよい。その後、ゲームエンジンＢＬＯＢクリエータトランスフォーマ６６が、そのコンテンツを、専用ゲームエンジン４６が受け入れることになる最終入力フォーマットに変換する。ゲームエンジン４６は、専用入力フォーマットで動作し、このフォーマットは、ツール３２、３４、３６に送り返される。現在、これらのビルドシステムはゲームごとに開発される傾向にあり、通常は小さなユーティリティと組み合わされ、コードビルドの機能のいくつか（たとえば、ロギング、プロファイル作成、およびデバッグ）が欠落している。

（拡張コンテンツビルドパイプラインおよび標準化ファイルフォーマット）
次に図３を参照すると、本発明による、図１に記載したコンテンツのビルドが可能な、標準化され拡張可能なコンテンツビルドパイプラインを示すブロック図を示してある。図３に示すように、コンテンツビルド６８は、コードビルドと同様に扱われ、現システムにおけるぜい弱性の一部を解消する。

この解決方法に対して、２つの主要部分が存在する。第１に、コンテンツビルドに関するファイルフォーマットが標準化される。これは、コンテンツビルド６８が必要とする情報を含むことが可能であり、標準コンテンツビルドパイプライン６８を作成できるようにするファイルフォーマットである。たとえば、様々なフォーマットのうちでもとりわけ、このファイルは、ゲームコンテンツの主要部分を記述することが可能なゲーム専用スキーマを有する埋込み拡張可能マークアップ言語（ＸＭＬ）を用いたＸＮＡ中間フォーマット（ＸＩＦ）のファイルとすることができる。重要なことに、標準化ファイルは、必ずしも標準化ファイル内にコンテンツデータを含む必要はなく、バイナリコンテンツデータを参照するメタデータを含むことができる。メタデータは、たとえば、様々なバイナリコンテンツファイル用のルーティング、コンテキスト、および適切な読取り機構を含むことができる。この場合、バイナリデータファイルの作成者が、訂正処理の識別を可能にする標準化ファイル「読取り」サービスを提供することができる。この標準ファイルフォーマットにより、ゲームエンジン開発者は、コンテンツビルド中間フォーマットを作成する必要なく、ゲーム専用バイナリファイルの作成を最適化することができる。ゲームエンジン開発者は、バイナリフォーマットの最適化に集中することができる。ただし、これは、ツール３２、３４、３６によって生成されたネイティブファイルフォーマット３８、４０、４２を置き換えるものではないことに留意されたい。

次に図４を参照すると、本発明による、図３のコンテンツビルドパイプラインに関連する標準化ファイルフォーマットのアーキテクチャを示す図が示してある。一例として、Ｌｅｖｅｌ．ｘｉｆ ８６という名前の標準化ＸＩＦファイルが示してある。ただし、本明細書に記載するＸＩＦファイルと同様に使用することが可能な同様の特性を有する、ＸＩＦ以外の他の標準化フォーマットを使用することもできる。Ｌｅｖｅｌ．ｘｉｆ ８６には、ゲームコンテンツの主要部分を記述することができる、ゲーム専用スキーマを定義するＸＭＬ（または他の宣言型プログラミング言語）を埋め込むことができる。これらのスキーマはたとえば、グラフィックス、オーディオなど周知のゲーム資産（コンテンツ）タイプに使用することができ、ゲーム開発者により全面的に拡張可能である。

また、ＸＩＦファイルは、ゲームコンテンツの他の部分を含むか、または参照する、他のＸＩＦファイルを参照することができ、バイナリコンテンツデータ自体を実際に含む必要はない。図示した例では、Ｌｅｖｅｌ．ｘｉｆ ８６は、Ｍｕｓｈｒｏｏｍ．ｘｉｆ ８８、Ｇｕｎ．ｘｉｆ ９０、およびＣｈａｒａｃｔｅｒ．ｘｉｆ ９２を参照する。これらは、他のＸＩＦファイルを参照することもできる。たとえば、Ｃｈａｒａｃｔｅｒ．ｘｉｆ ９２は、ＣｈａｒａｃｔｅｒＭｅｓｈ．ｘｉｆ ９４、ＣｈａｒａｃｔｅｒＳｏｕｎｄ．ｘｉｆ ９６、ＣｈａｒａｃｔｅｒＴｅｘｔｕｒｅｓ．ｘｉｆ ９８、およびＣｈａｒａｃｔｅｒＡｎｉｍａｔｉｏｎｓ．ｘｉｆ １００を参照する。また、Ｌｅｖｅｌ．ｘｉｆ ８６などのＸＩＦファイルは、埋込みバイナリファイルを有すること、および／または他のバイナリファイルを参照することもできる。このように他のＸＩＦおよびバイナリファイルを参照することにより、コンポーネント化、再使用、および依存性のチェックが可能になる。

図４に示すような標準化ＸＩＦファイルにより、ゲームスタジオが専用エクスポータを作成せずに済むようにすることが可能になる。ゲームスタジオが必要とするようなデータのすべてが、ＸＩＦフォーマットおよび関連バイナリに格納される。これらのバイナリは、ＸＭＬファイル中のテキストに変換しても意味がない、単なるビットマップであるテクスチャ、またはサウンドＷＡＶＥファイルのようなゲームコンテンツでよい。また、標準化ファイルフォーマットにより、ビルドシステムが、コンテンツの「オーバーライド」を参照できるようになる。これは、複数のプラットフォームに対して１本のコンテンツの１つのバージョンが存在することはできるが、ある特定のプラットフォームはそのプラットフォーム向けに個別化された専用バージョンを必要とすることを意味している。個別化バージョンは、一般バージョンを「オーバーライド」する。これは、標準化ファイルメタデータで表現される。

図３に関して上述したように、データはその後、アプリケーションにとって理想的なフォーマットに変換される。この作業は、図２のエクスポート段階４９とは異なり、変換段階６８で行われる。必要とされるデータのすべてが、そのゲーム用のＸＩＦフォーマット中にあるからである。このため、変換作業がエクスポートの一部ではなくなるので、専用アートパッケージおよびエクスポータに対する依存性が断たれ、開発者がこれらバイナリをより容易に完全に変更することができるようになる。

第２に、実証済みのコードビルド技術を使用して、コンテンツビルド用の基礎基盤が提供される。たとえば、図３を再び参照すると、図３のコンテンツビルド用の基礎基盤を提供する適切なコードビルド技術は、Ｍｉｃｒｏｓｏｆｔ ＭＳＢｕｉｌｄ（登録商標）エンジンを含むＭｉｃｒｏｓｏｆｔ Ｖｉｓｕａｌ Ｓｔｕｄｉｏ（登録商標）統合開発環境（ＩＤＥ）とすることができる。ＭＳＢｕｉｌｄ（登録商標）は、公開されているＸＭＬスキーマ定義によってうまく文書化され支援されたファイルフォーマットを提供し、その結果、ＭＳＢｕｉｌｄ（登録商標）エンジンは、．ＮＥＴ Ｆｒａｍｅｗｏｒｋ再配付可能（redistributable）の不可欠な部分となっている。これにより、開発者は、ビルド処理をカスタマイズし、または強化し、または完全に再定義することができ、Ｍｉｃｒｏｓｏｆｔ Ｖｉｓｕａｌ Ｓｔｕｄｉｏ（登録商標）ＩＤＥとのシームレスな統合が提供される。

ＭＳＢｕｉｌｄ（登録商標）は、理解が簡単で拡張が容易なＸＭＬベースのファイルフォーマットを有している。ＭＳＢｕｉｌｄ（登録商標）ファイルフォーマットにより、開発者は、どんな人工物（artifacts）を作成する必要があるか、また異なる構成の下でどのようにビルドする必要があるかについて完全に記述することができる。さらに、このファイルフォーマットにより、開発者は、製品に含まれる様々なプロジェクトにまたがってビルドを一貫して行えるように、個々のファイルに盛り込むことのできる再使用可能ルールを記述することができる。ＭＳＢｕｉｌｄ（登録商標）は、．ＮＥＴ Ｆｒａｍｅｗｏｒｋ再配付可能の中核部分である。これにより開発者は、ＩＤＥの存在およびライセンスの問題とは無関係に、ＭＳＢｕｉｌｄ（登録商標）基盤を利用することができる。さらに、ＭＳＢｕｉｌｄ（登録商標）クラスライブラリを．ＮＥＴ Ｆｒａｍｅｗｏｒｋの中核部分として提供することにより、開発者は、自分の選択した使い慣れた言語を使用して、カスタマイズされたＭＳＢｕｉｌｄ（登録商標）処理のコンポーネントを作成しデバッグすることが可能となる。第３に、ＭＳＢｕｉｌｄ（登録商標）は、ソフトウェアをどのように処理し構築するかに関して、完全に透過的である。すべてのビルドステップは、手で記述されたにせよ、それともＭｉｃｒｏｓｏｆｔ Ｖｉｓｕａｌ Ｓｔｕｄｉｏ（登録商標）ＩＤＥで自動生成されたにせよ、ＸＭＬプロジェクトファイル中で明示的に表現される。これはまた、ユーザが、ビルド処理の任意の部分を、理解し、複製し、編集し、除去し、または強化することができることも意味する。最後に、ＭＳＢｕｉｌｄ（登録商標）は、Ｍｉｃｒｏｓｏｆｔ Ｖｉｓｕａｌ Ｓｔｕｄｉｏ（登録商標）ＩＤＥに完全に統合されている。この緊密な統合により、開発者は、Ｍｉｃｒｏｓｏｆｔ Ｖｉｓｕａｌ Ｓｔｕｄｉｏ（登録商標）の提供する、組み込まれたすべての生産性向上機能を利用することができ、それと同時に開発者は、ビルドシステムをスケーリングし、カスタマイズし、自分の独自の基盤ニーズに適合させることができるようになる。ＭＳＢｕｉｌｄ（登録商標）エンジンを備えるＭｉｃｒｏｓｏｆｔ Ｖｉｓｕａｌ Ｓｔｕｄｉｏ（登録商標）ＩＤＥを、図３のコンテンツビルド用の基礎基盤を提供するのに適したコードビルド技術を用いるＩＤＥの一例として示したが、類似の機能を用いる他のＩＤＥを使用することもできる。

図３に示した例では、Ｄｉｓｃｒｅｅｔ ３Ｄ Ｓｔｕｄｉｏ Ｍａｘ（登録商標）コンテンツに対応するＸＩＦファイル７０、７２、およびＳｏｎｉｃ Ｆｏｕｎｄｒｙ ＳｏｕｎｄＦｏｒｇｅ（登録商標）コンテンツに対応するＸＩＦファイル７４はどちらも、ゲームコンテンツの主要部分を記述することが可能なゲーム専用スキーマを含んでおり、単一の標準パイプライン６８に直接入力される。図２で必要とされたエクスポート層４９が存在しないことに留意されたい。上述したような標準ファイルフォーマットがあるということは、ゲームスタジオが、使用するコンテンツ作成ツールごとに専用のエクスポータを作成する必要がなくなることを意味する。重要なことに、ゲームスタジオは、自分のビルドパイプラインに影響を与えずに、コンテンツ作成ツールのバージョン間を移動することができる。

単一パイプライン６８は、マージトランスフォーマ７６、サウンドトランスフォーマ７８、テクスチャ圧縮トランスフォーマ８０、ＬＯＤトランスフォーマ８２、および最後にＸＩＦ／ゲームエンジントランスフォーマ８４など、様々なトランスフォーマを含むことができる。これらのトランスフォーマ７６、７８、８０、８２は、標準化ＸＩＦファイル７０、７２、７４を介して処理を行う。単一パイプライン６８では、トランスフォーマ７６、７８、８０、８２は、処理しないファイルを単に通過させる。他の様々なトランスフォーマをこのパイプラインに含めることができ、それらを作成し、再使用するのも簡単である。

標準化ファイルフォーマットは、コンテンツ作成ツール３２、３４、３６およびゲームエンジン４６を抽象化したものであるので、たとえばＭＳｂｕｉｌｄ（登録商標）エンジンを含むＭｉｃｒｏｓｏｆｔ Ｖｉｓｕａｌ Ｓｔｕｄｉｏ（登録商標）ＩＤＥなど、コンテンツ用の基礎ビルド基盤を提供する既存のコードビルド処理を再使用することができる。ゲームコンテンツを構築するためにコードビルドシステムを使用できるということは、ロギング、デバッグ、プロファイル作成など、より良い基本サービスを自動的に受けられることを意味する。

また、プログラマは、コンテンツビルドに手を加えることもできる。現在、各ゲームでは互いに異なるビルドシステムを使用している。その結果、そのシステムがコードビルドとは異なる技術を使用しているので、ゲームプログラマはコンテンツビルドをほとんど変更することができず、あるいは変更したいと望んでいない。コンテンツビルドをコードビルドに基づくようにすれば、この問題は解消される。また、コードビルドシステムに基づいた図３のコンテンツビルドパイプライン６８により、トランスフォーマの開発が容易になる。コードビルドシステムは、一般にプラグ可能（pluggable）なように構築される。コードビルドシステムを使用するということは、新規のトランスフォーマを迅速に記述し、それをコンテンツビルドシステムに迅速かつ容易にプラグできることを意味する。基本ビルド処理によって一般的な基盤が提供されるので、異なるパイプライン（たとえば、ゲームビルドとプレビュービルド）および異なるゲームにまたがってトランスフォーマを用い、それらを再使用するのは簡単である。

（代替実施形態）
次に図５を参照すると、本発明の一代替実施形態による、異なるゲームプラットフォームごとにパイプラインの開始点で分岐する、標準化され拡張可能なコンテンツビルドパイプラインを示すブロック図が示してある。この分岐は、ネイティブファイルフォーマットのゲームコンテンツおよび標準化ＸＩＦファイル１０４が作成された後に行われる。そのＸＩＦファイルから、異なるゲームプラットフォーム４７、４８に基づくゲームエンジン４６ごとに、１つまたは複数のコピー１０２が作成される。ＸＩＦファイルの各コピーは、特定のゲームエンジン４６に対応する別個の標準パイプライン６８を通って進む。２つのコピーおよびパイプラインしか図５に示していないが、多数の異なるタイプのゲームエンジンおよびフォーマットに対応した多数のコピーおよびパイプラインを作成することもできる。

次に図６を参照すると、本発明の一代替実施形態による、別個のプレビューパイプラインおよびゲームパイプラインを作成するためにパイプラインの開始点で分岐する、標準化され拡張可能なコンテンツビルドパイプラインを示すブロック図が示してある。図５の場合と同様に、ネイティブファイルフォーマットのゲームコンテンツおよび標準化ＸＩＦファイル１０４が作成された後に分岐が行われる。この場合は、そのＸＩＦファイルから、プレビューパイプライン用のコピーが作成される。このプレビューパイプラインは、通常のコンテンツビルドのコンテンツのすべてを含んではいない限定ビルドでよい。

図６に示した例では、プレビューの場合、開発者がおそらくゲームのビデオコンテンツをプレビューできさえすればよいか、またはそれを望むだけであるので、プレビュービルドはオーディオ部分を含んでいない。ただし、プレビューの目的では、オーディオの代わりにまたはオーディオに加えて、ゲームコンテンツの他の諸側面を除外することもできる。次いで、ＸＩＦ／エンジントランスフォーマは、そのコンテンツを、特定のゲームエンジンが受け取る最終入力フォーマットに変換する。標準化され拡張可能なビルド処理によって、一般的な基盤が提供されので、トランスフォーマを用い、図６のプレビューパイプラインおよび図５の個別のゲームパイプラインの場合のように、異なるパイプラインにまたがってそれらを再使用するのは簡単である。

（例示的なコンピューティングおよびネットワーク環境）
図７を参照すると、本発明の様々な諸態様と共に使用するのに適した、１つの例示的なコンピューティング装置を表すブロック図が示してある。たとえば、上述の標準化され拡張可能なビルド処理を行うための処理および方法を実施するコンピュータ実行可能命令を、図７に示すようなコンピューティング環境に常駐させ、かつ／または実行することができる。コンピューティングシステム環境２２０は、適切なコンピューティング環境の単なる一例に過ぎず、本発明の使用または機能の範囲に関してどんな制限を示唆するものでもない。コンピューティングシステム環境２２０は、例示的な動作環境２２０に示されている構成要素の任意の１つまたはその組合せに関して、どんな依存性も必要性も有するものと解釈されるべきではない。

本発明の諸態様は、他の多数の汎用または専用コンピューティングシステム環境または構成で動作する。本発明で使用するのに適し得る周知のコンピューティングシステム、環境、および／または構成の例には、それだけには限らないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な民生電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、任意の上述のシステムまたは装置を含む分散コンピューティング環境などが含まれる。

本発明の諸態様は、コンピュータで実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈において実施することができる。一般に、プログラムモジュールには、特定のタスクを実行し、または特定の抽象データタイプを実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。また、本発明の諸態様は、通信ネットワークを介してリンクされたリモートの処理装置でタスクが実行される分散コンピューティング環境において実施することもできる。分散コンピューティング環境では、プログラムモジュールは、記憶装置を含む、ローカルの記憶媒体にもリモートのコンピュータ記憶媒体にも配置することができる。

本発明の諸態様を実装するための１つの例示的なシステムは、コンピュータ２４１の形の汎用コンピューティング装置を含む。コンピュータ２４１の構成要素には、それだけには限らないが、処理装置２５９、システムメモリ２２２、およびシステムメモリを含めた様々なシステム構成要素を処理装置２５９に結合するシステムバス２２１が含まれる。システムバス２２１は、メモリバスまたはメモリコントローラ、周辺バス、および様々なバスアーキテクチャのどれかを使用するローカルバスを含む、いくつかのタイプのバス構造のうちのどれでもよい。例を挙げると、それだけには限らないが、そのようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、ＭｅｚｚａｎｉｎｅバスおよびＰＣＩ Ｅｘｐｒｅｓｓとも呼ばれるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスが含まれる。

コンピュータ２４１は通常、様々なコンピュータ読取り可能記憶媒体を含んでいる。コンピュータ読取り可能記憶媒体は、コンピュータ２４１がアクセスできるどんな利用可能な媒体でもよく、それには揮発性媒体および不揮発性媒体、取外し可能な媒体および取外し不可能な媒体が含まれる。例を挙げると、それだけには限らないが、コンピュータ読取り可能記憶媒体には、コンピュータ記憶媒体および通信媒体が含まれる。コンピュータ記憶媒体には、コンピュータ読取り可能命令、データ構造、プログラムモジュール、その他のデータなどの情報を記憶するための任意の方法または技術で実装される、揮発性および不揮発性の、取外し可能および取外し不可能な媒体が含まれる。コンピュータ記憶媒体には、それだけには限らないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ）またはＢｌｕ−ｒａｙ、ＨＤ ＤＶＤ、およびその他の青色レーザフォーマットの光媒体を含む、その他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶装置、あるいは所望の情報を記憶するために使用でき、コンピュータ２４１がアクセスできる任意のその他の媒体が含まれる。通信媒体は通常、コンピュータ読取り可能命令、データ構造、プログラムモジュール、またはその他のデータを、搬送波やその他の搬送機構などの被変調データ信号として実施し、それには任意の情報送達媒体が含まれる。用語「被変調データ信号」とは、信号の１組の特性のうちの１つまたは複数の特性を有する信号、あるいは信号中の情報を符号化するように変更された信号を意味する。例を挙げると、それだけには限らないが、通信媒体には、有線ネットワークや直接配線接続などの有線媒体、ならびに音響、ＲＦ、赤外、およびその他の無線媒体などの無線媒体が含まれる。上記の任意の組合せも、コンピュータ読取り可能記憶媒体の範囲内に含まれるものとする。

システムメモリ２２２には、読取り専用メモリ（ＲＯＭ）２２３やランダムアクセスメモリ（ＲＡＭ）２６０などの揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体が含まれる。起動時などに、コンピュータ２４１内の要素間で情報を転送するのを助ける基本ルーチンを含む基本入出力システム２２４（ＢＩＯＳ）は、一般にＲＯＭ２２３に記憶されている。ＲＡＭ ２６０は通常、即座にアクセス可能な、かつ／または現在、処理装置２５９により操作されているデータおよび／またはプログラムモジュールを含む。限定ではなく例として、図７には、オペレーティングシステム２２５、アプリケーションプログラム２２６、その他のプログラムモジュール２２７、およびプログラムデータ２２８を示す。

コンピュータ２４１はまた、その他の取外し可能／取外し不可能な、揮発性／不揮発性コンピュータ記憶媒体も含むことができる。単に例として、図７には、取外し不可能な不揮発性磁気媒体を読み書きするハードディスクドライブ２３８、取外し可能な不揮発性磁気ディスク２５４を読み書きする磁気ディスクドライブ２３９、およびＣＤ−ＲＯＭやその他の光媒体などの取外し可能な不揮発性光ディスク２５３を読み書きする光ディスクドライブ２４０を示す。例示の動作環境で使用できるその他の取外し可能／取外し不可能な揮発性／不揮発性コンピュータ記憶媒体には、それだけには限らないが、磁気テープカセット、フラッシュメモリカード、ＤＶＤ、デジタルビデオテープ、固体ＲＡＭ、固体ＲＯＭなどが含まれる。ハードディスクドライブ２３８は一般に、インターフェース２３４などの取外し不可能な記憶装置インターフェースを介してシステムバス２２１に接続され、磁気ディスクドライブ２３９および光ディスクドライブ２４０は一般に、インターフェース２３５などの取外し可能な記憶装置インターフェースによってシステムバス２２１に接続される。

上述し図７に示したドライブおよびそれに関連するコンピュータ記憶媒体は、コンピュータ読取り可能命令、データ構造、プログラムモジュール、およびコンピュータ２４１用のその他のデータを記憶する。たとえば図７では、ハードディスクドライブ２３８は、オペレーティングシステム２５８、アプリケーションプログラム２５７、その他のプログラムモジュール２５６、およびプログラムデータ２５５を記憶するものとして示してある。これらの構成要素は、オペレーティングシステム２２５、アプリケーションプログラム２２６、その他のプログラムモジュール２２７、およびプログラムデータ２２８と同じでも、異なっていてもよいことに留意されたい。オペレーティングシステム２５８、アプリケーションプログラム２５７、その他のプログラムモジュール２５６、およびプログラムデータ２５５には、少なくともそれらが異なるコピーであることを示すために、ここでは異なる番号を付与している。ユーザは、キーボード２５１およびマウス、トラックボール、またはタッチパッドと一般に呼ばれるポインティング装置２５２などの入力装置を介して、コマンドおよび情報をコンピュータ２４１に入力することができる。その他の入力装置（図示せず）には、マイクロホン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなどが含まれ得る。以上その他の入力装置は、しばしばシステムバスに結合されているユーザ入力インターフェース２３６を介して処理装置２５９に接続されるが、パラレルポート、ゲームポート、またはＵＳＢ（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）など他のインターフェースおよびバス構造で接続されてもよい。また、モニタ２４２またはその他のタイプの表示装置も、ビデオインターフェース２３２などのインターフェースを介してシステムバス２２１に接続することができる。モニタに加えて、コンピュータは、スピーカ２４４やプリンタ２４３など他の周辺出力装置を含むこともでき、それらは出力周辺インターフェース２３３を介して接続することができる。

コンピュータ２４１は、たとえばリモートコンピュータ２４６など１台または複数台のリモートコンピュータへの論理接続を使用して、ネットワーク環境において動作することができる。リモートコンピュータ２４６は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、またはその他の一般的なネットワークノードでよく、一般にコンピュータ２４１に関して上記で述べた要素の多くまたはすべてを含んでいるが、図７には記憶装置２４７だけが示してある。図７に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）２４５および広域ネットワーク（ＷＡＮ）２４９を含んでいるが、他のネットワークを含むこともできる。そのようなネットワーク環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、およびインターネットでは一般的である。

ＬＡＮネットワーク環境において使用する場合、コンピュータ２４１は、ネットワークインターフェースまたはアダプタ２３７を介してＬＡＮ２４５に接続される。ＷＡＮネットワーク環境において使用する場合、コンピュータ２４１は一般に、インターネットなどのＷＡＮ２４９上で通信を確立するために、モデム２５０またはその他の手段を含む。モデム２５０は、内蔵でも外付けでもよいが、ユーザ入力インターフェース２３６、またはその他の適切な機構を介して、システムバス２２１に接続することができる。ネットワーク環境では、コンピュータ２４１に関して示したプログラムモジュール、またはその一部分を、リモート記憶装置に記憶することができる。限定ではなく例として、図７では、リモートアプリケーションプログラム２４８を記憶装置２４７に常駐するものとして示す。図示したネットワーク接続は例であり、コンピュータ間で通信リンクを確立する他の手段を使用することもできることが理解されよう。

ハードウェアまたはソフトウェアで、あるいは適切な場合は両者の組合せで、本明細書に記載した様々な技術を実施できることを理解されたい。したがって、本発明の方法および装置、あるいはいくつかの態様またはその一部分は、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ，ハードドライブ、または任意のその他の機械読取り可能記憶媒体など、有形の媒体で実施されるプログラムコード（たとえば命令）の形をとることができ、その場合、プログラムコードをコンピュータなどのマシンにロードし、そこで実行する場合、そのマシンが本発明を実施するための装置となる。プログラム可能なコンピュータ上でプログラムコードを実行する場合、コンピューティング装置は一般に、プロセッサ、プロセッサによって読取り可能な記憶媒体（揮発性および不揮発性メモリおよび／または記憶装置要素を含む）、少なくとも１台の入力装置、および少なくとも１台の出力装置を含む。１つまたは複数のプログラムは、たとえばＡＰＩ、再使用可能コントロールなどを利用して、本発明に関して述べた処理を実装または使用することができる。そのようなプログラムは、好ましくは、コンピュータシステムと通信するために、手続き形のまたはオブジェクト指向の高級プログラミング言語で実装する。しかし、プログラムは、望むであれば、アセンブリ言語または機械語で実装することもできる。いずれにせよ、言語はコンパイル式またはインタプリタ式言語でよく、ハードウェア実装と組み合わせてもよい。

例示的な諸実施形態は、１台または複数台のスタンドアロンコンピュータシステムのコンテキストにおいて、本発明の諸態様を利用することに関するものであるが、本発明はそれだけには限定されず、ネットワークまたは分散コンピューティング環境など任意のコンピューティング環境と共に実装することもできる。さらに、本発明の諸態様は、複数の処理チップまたは装置において、あるいはそれらにまたがって実施することができ、記憶装置も同様に、複数の装置にまたがって実施することができる。そのような装置には、パーソナルコンピュータ、ネットワークサーバ、ハンドヘルド装置、スーパーコンピュータ、または自動車や飛行機など他のシステムに統合されたコンピュータが含まれ得る。

１つの例示的なネットワークコンピューティング環境が、図８に示してある。ネットワークは、任意のコンピュータまたはその他のクライアントもしくはサーバ装置を接続することができ、あるいは分散コンピューティング環境において接続を行うことができることが、当業者には理解できよう。この点に関連して、任意の数の処理装置、メモリ装置、または記憶装置、ならびに同時に実行される任意の数のアプリケーションおよびプロセスを有するどんなコンピュータシステムまたは環境も、図示したシステムおよび方法と共に使用するのに適しているものと見なされる。

分散コンピューティングでは、コンピューティング装置およびシステム間でのやりとりによって、コンピュータ資源およびサービスが共用される。これらの資源およびサービスには、情報の交換、キャッシュ記憶装置、およびファイル用のディスク記憶装置が含まれる。分散コンピューティングでは、ネットワーク接続を利用するので、クライアントに、その集合的な力を活用させ、全社的に利益が得られるようにすることができる。この点において、様々な装置が、本明細書に記載した処理に関与し得るアプリケーション、オブジェクト、または資源を有することができる。

図８は、１つの例示的なネットワークコンピューティング環境または分散コンピューティング環境の概略図を示す。この環境は、コンピューティング装置２７１、２７２、２７６、および２７７と、オブジェクト２７３、２７４、および２７５と、データベース２７８とを含んでいる。これらのエンティティ２７１、２７２、２７３、２７４、２７５、２７６、２７７、および２７８はそれぞれ、プログラム、メソッド、データ記憶装置、プログラマブルロジックなどを含むか、または使用することができる。エンティティ２７１、２７２、２７３、２７４、２７５、２７６、２７７、および２７８は、ＰＤＡ、オーディオ／ビデオ装置、ＭＰ３プレーヤ、パーソナルコンピュータなど、同じまたは異なる装置の複数部分にまたがってよい。各エンティティ２７１、２７２、２７３、２７４、２７５、２７６、２７７、および２７８は、通信ネットワーク２７０を介して他のエンティティ２７１、２７２、２７３、２７４、２７５、２７６、２７７、および２７８と通信することができる。なお、どのエンティティが、データベース２７８またはその他の記憶装置要素の維持および更新の任を負ってもよい。

このネットワーク２７０は、それ自体、図８のシステムにサービスを提供する他のコンピューティングエンティティを含むことができ、またそれ自体、複数の相互接続ネットワークを表すことができる。本発明の一態様によれば、各エンティティ２７１、２７２、２７３、２７４、２７５、２７６、２７７、および２７８は、ＡＰＩまたはその他のオブジェクト、ソフトウェア、ファームウェア、および／またはハードウェアを使用して、他のエンティティ２７１、２７２、２７３、２７４、２７５、２７６、２７７、および２７８のうちの１つまたは複数のエンティティのサービスを要求することのできる、別個の機能プログラムモジュールを含むことができる。

２７５などのオブジェクトは、別のコンピューティング装置２７６上でホストできることも理解できよう。したがって、図示した物理環境では接続されている装置をコンピュータとして示していようが、そうした図は単なる例示であり、代わりに物理環境を、ＰＤＡ、テレビ、ＭＰ３プレーヤなどの様々なデジタル機器、およびインターフェース、ＣＯＭオブジェクトなどのソフトウェアオブジェクトを含むものとして示し、または記述することもできる。

分散コンピューティング環境をサポートする様々なシステム、構成要素、およびネットワーク構成が存在する。たとえば、コンピューティングシステムは、有線または無線システムによって、ローカルネットワークまたは広域分散ネットワークによって互いに接続することができる。現在、多くのネットワークがインターネットに接続されており、インターネットは、広く分散されたコンピューティング用の基盤を提供し、異なる多くのネットワークを含んでいる。そのようないかなる基盤も、インターネットに結合されているにせよ、いないにせよ、図示したシステムおよび方法と共に使用することができる。

ネットワーク基盤は、クライアント／サーバ、ピアツーピア、または混成（hybrid）アーキテクチャなど多数のネットワークトポロジを可能にし得る。「クライアント」とは、関係のない別のクラスまたはグループのサービスを使用する、あるクラスまたはグループのメンバーである。コンピューティングにおいて、クライアントは、他のプログラムが提供するサービスを要求するプロセス、すなわち大まかに言って、１組の命令またはタスクである。クライアントプロセスは、他のプログラムまたはサービス自体についての実際の詳細を「知る」必要なしに、要求したサービスを使用する。クライアント／サーバアーキテクチャ、特にネットワークシステムでは、クライアントは通常、別のコンピュータ、たとえばサーバが提供する共有ネットワークリソースにアクセスするコンピュータである。図８の例では、状況に応じて、どのエンティティ２７１、２７２、２７３、２７４、２７５、２７６、２７７、および２７８も、クライアント、サーバ、またはその両方と見なすことができる。

サーバは、必ずしもそうとは限らないが、一般にインターネットなどのリモートまたはローカルネットワークを介してアクセス可能な、リモートコンピュータシステムである。クライアントプロセスを第１のコンピュータシステムでアクティブにし、サーバプロセスを第２のコンピュータシステムでアクティブにし、通信媒体を介して互いに通信し、それにより、分散機能を提供し、複数のクライアントがサーバの情報収集能力を利用できるようにすることができる。任意のソフトウェアオブジェクトを、複数のコンピューティング装置またはオブジェクトにまたがって分散させることができる。

クライアントおよびサーバは、プロトコル層（１つまたは複数）が提供する機能を利用して、互いに通信する。たとえば、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）は、ワールドワイドウェブ（ＷＷＷ）、すなわちウェブと共に使用する一般的なプロトコルである。一般に、インターネットプロトコル（ＩＰ）アドレスなどのコンピュータネットワークアドレス、またはＵＲＬ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）などの他の参照を使用して、サーバコンピュータまたはクライアントコンピュータを互いに識別することができる。ネットワークアドレスは、ＵＲＬアドレスと呼ばれるともある。通信は、通信媒体を介して提供することができ、たとえばクライアントおよびサーバを、大容量通信用のＴＣＰ／ＩＰ接続を介して互いに結合することができる。

図７に示した一般的なフレームワークに従って構築できる様々なコンピューティング環境、ならびに図８のようなネットワーク環境におけるコンピューティングの際に生じ得るさらなる多様性に鑑みて、本明細書で示すシステムおよび方法は、特定のコンピューティングアーキテクチャに限定されるものと解釈してはならない。代わりに、本発明は、どんな一実施形態にも限定されず、添付の特許請求の範囲による幅および範囲で解釈されるものとする。

様々なコンテンツ開発エディタおよびゲーム開発ツールならびにそれらの相互関係および様々なゲームエンジンとの関係を一例として示すブロック図である。 ゲーム専用の中間ファイルフォーマットおよびカスタムエクスポータを必要とする、図１に記載したコンテンツのビルドが可能な、コンテンツビルドパイプラインを示すブロック図である。 本発明による、図１に記載したコンテンツのビルドが可能な、標準化され拡張可能なコンテンツビルドパイプラインを示すブロック図である。 本発明による、図３のコンテンツビルドパイプラインと関連した標準化ファイルフォーマットのアーキテクチャを示す図である。 本発明の一代替実施形態による、異なるゲームプラットフォームごとにパイプラインの開始点で分岐する、標準化され拡張可能なコンテンツビルドパイプラインを示すブロック図である。 本発明の一代替実施形態による、個別のプレビューパイプラインおよびゲームパイプラインを作成するためにパイプラインの開始点で分岐する、標準化され拡張可能なコンテンツビルドパイプラインを示すブロック図である。 本発明の様々な諸態様と共に使用するのに適した、１つの例示的なコンピューティング装置を表すブロック図である。 本発明の様々な諸態様のものも含む、多くのコンピュータ化された処理を実装することのできる、１つの例示的なネットワーク化されたコンピューティング環境を示す図である。

Claims (20)

1. 対話式マルチメディアソフトウェアアプリケーションのコンテンツ用のソフトウェアビルドを可能にする方法であって、
   標準化ファイルフォーマットに従って、前記コンテンツに関するメタデータを含む少なくとも１つのファイルを作成することを含み、前記メタデータは、同じ前記コンテンツを使用する、複数の異なる対話式マルチメディアソフトウェアアプリケーションに対して、前記コンテンツのソフトウェアビルドを実施するために必要なメタデータであることを特徴とする方法。
2. 対話式マルチメディアソフトウェアアプリケーションのコンテンツ用の前記ビルドは、前記コンテンツを、前記複数の対話式マルチメディアソフトウェアアプリケーションのそれぞれが受け入れることのできるように、前記複数の対話式マルチメディアソフトウェアアプリケーションのそれぞれに専用のフォーマットに変換することを特徴とする請求項１に記載の方法。
3. 前記標準化ファイルフォーマットの前記コンテンツに関する前記メタデータを使用して、前記コンテンツを、前記複数の対話式マルチメディアソフトウェアアプリケーションのうちの少なくとも１つに最適化された少なくとも１つのフォーマットに変換することをさらに含むことを特徴とする請求項２に記載の方法。
4. 前記標準化ファイルフォーマットに従って、前記ファイルの少なくとも１つのコピーを作成することと、
   前記ファイルの各コピーに関する前記コンテンツを、別々のソフトウェアコンテンツビルドパイプラインで使用される、互いに異なるトランスフォーマを介して、異なる方法で変換することと
   をさらに含むことを特徴とする請求項３に記載の方法。
5. 前記メタデータは、追加の情報に基づいて１本の前記コンテンツのある特定のバージョンを使用するために、前記ソフトウェアビルドが、前記１本のコンテンツの一般的なバージョンを使用してオーバーライドすることを可能にする、前記追加の情報を含むことを特徴とする請求項１に記載の方法。
6. 前記標準化ファイルフォーマットに従って作成され、前記コンテンツに関するメタデータを含むことのできる前記ファイルは、前記ソフトウェアコンテンツビルドを実施するために、ファイルをコンテンツ作成ツールにネイティブなフォーマットで前記複数の対話式マルチメディアソフトウェアアプリケーションのそれぞれに専用のフォーマットにエクスポートするためのエクスポート処理を必要ないようにする、メタデータを含むことを特徴とする請求項１に記載の方法。
7. 前記標準化ファイルフォーマットに従って作成される前記ファイルは、バイナリコンテンツファイルを参照する前記メタデータを含むが、前記バイナリコンテンツファイルを直接含まないことを特徴とする請求項１に記載の方法。
8. 前記メタデータは、ＸＭＬフォーマットであることを特徴とする請求項７に記載の方法。
9. 対話式マルチメディアソフトウェアアプリケーションのコンテンツ用のソフトウェアビルドを可能にするコンピュータ読取り可能命令を記憶したコンピュータ読取り可能記憶媒体であって、前記コンピュータ読取り可能命令は、
   標準化ファイルフォーマットに従って、前記コンテンツに関するメタデータを含む少なくとも１つのファイルを作成する命令を含み、前記メタデータは、同じ前記コンテンツを使用する、複数の異なる対話式マルチメディアソフトウェアアプリケーションに対して、前記コンテンツのソフトウェアビルドを実施するために必要なメタデータであること
   を特徴とするコンピュータ読取り可能記憶媒体。
10. 対話式マルチメディアソフトウェアアプリケーションのコンテンツ用の前記ビルドは、前記コンテンツを、前記複数の対話式マルチメディアソフトウェアアプリケーションのそれぞれが受け入れることのできるように、前記複数の対話式マルチメディアソフトウェアアプリケーションのそれぞれに専用のフォーマットに変換することを特徴とする請求項９に記載のコンピュータ読取り可能記憶媒体。
11. 前記標準化ファイルフォーマットの前記コンテンツに関する前記メタデータを使用して、前記コンテンツを、前記複数の対話式マルチメディアソフトウェアアプリケーションのうちの少なくとも１つに最適化された少なくとも１つのフォーマットに変換するコンピュータ読取り可能命令をさらに含むことを特徴とする請求項９に記載のコンピュータ読取り可能記憶媒体。
12. 前記コンピュータ読取り可能命令は、
    前記標準化ファイルフォーマットに従って、前記ファイルの少なくとも１つのコピーを作成する命令と、
    前記ファイルの各コピーに関する前記コンテンツを、別々のソフトウェアコンテンツビルドパイプラインで使用される、互いに異なるトランスフォーマを介して、異なる方法で変換する命令と
    をさらに含むことを特徴とする請求項１０に記載のコンピュータ読取り可能記憶媒体。
13. 対話式マルチメディアソフトウェアアプリケーションのコンテンツ用のソフトウェアビルドを可能にするシステムであって、
    標準化ファイルフォーマットに従って、前記コンテンツに関するメタデータを含む少なくとも１つのファイルを作成する手段を含み、前記メタデータは、同じ前記コンテンツを使用する、複数の異なる対話式マルチメディアソフトウェアアプリケーションに対して、前記コンテンツのソフトウェアビルドを実施するために必要なメタデータであること
    を特徴とするシステム。
14. 対話式マルチメディアソフトウェアアプリケーションのコンテンツ用の前記ビルドは、前記コンテンツを、前記複数の対話式マルチメディアソフトウェアアプリケーションのそれぞれが受け入れることのできるように、前記複数の対話式マルチメディアソフトウェアアプリケーションのそれぞれに専用のフォーマットに変換することを特徴とする請求項１３に記載のシステム。
15. 前記標準化ファイルフォーマットの前記コンテンツに関する前記メタデータを使用して、前記コンテンツを、前記複数の対話式マルチメディアソフトウェアアプリケーションのうちの少なくとも１つに最適化された少なくとも１つのフォーマットに変換する手段をさらに含むことを特徴とする請求項１３に記載のシステム。
16. 前記標準化ファイルフォーマットに従って、前記ファイルの少なくとも１つのコピーを作成する手段と、
    前記ファイルの各コピーに関する前記コンテンツを、別々のソフトウェアコンテンツビルドパイプラインで使用される、互いに異なるトランスフォーマを介して、異なる方法で変換する手段と
    をさらに含むことを特徴とする請求項１５に記載のシステム。
17. 前記メタデータは、追加の情報に基づいて１本の前記コンテンツのある特定のバージョンを使用するために、前記ソフトウェアビルドが、前記１本のコンテンツの一般的なバージョンを使用してオーバーライドすることを可能にする、前記追加の情報を含むことを特徴とする請求項１３に記載のシステム。
18. 前記標準化ファイルフォーマットに従って作成され、前記コンテンツに関するメタデータを含むことのできる前記ファイルは、前記ソフトウェアコンテンツビルドを実施するために、ファイルをコンテンツ作成ツールにネイティブなフォーマットで前記複数の対話式マルチメディアソフトウェアアプリケーションのそれぞれに専用のフォーマットにエクスポートするためのエクスポート処理を必要ないようにする、メタデータを含むことを特徴とする請求項１３に記載のシステム。
19. 前記標準化ファイルフォーマットに従って作成される前記ファイルは、バイナリコンテンツファイルを参照する前記メタデータを含むが、前記バイナリコンテンツファイルを直接含まないことを特徴とする請求項１３に記載のシステム。
20. 前記メタデータは、ＸＭＬフォーマットであることを特徴とする請求項１９に記載のシステム。