(57)【要約】  データプロバイダＡＰＩ（application programming interface）が、ゲームコンテンツ編集アプリケーションと併用するために構成される。資産関係管理ファイルは、データプロバイダＡＰＩで生成され、参照関係および注釈のような情報を含み、デジタル資産が編集される時にデータプロバイダＡＰＩにより更新される。資産関係管理ファイルを次いでデータストアに記憶する。資産関係グラフは、データストア内の資産関係管理ファイルに基づいて生成される。資産関係グラフは、資産ファイル間の依存関係をマップする資産グラフノードを含む。グラフＡＰＩもまた説明する。グラフＡＰＩが、サーバプロセスをして関係グラフにアクセスするために構成され、依存関係および注釈を、アプリケーションのようなクライアントプロセスに公開する。従って、他の資産における、ある資産に対する変更の影響を容易に評価することができる。
2009525533.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツ開発環境内部の複数のデジタルゲームコンテンツファイルに関連付けられたデジタルゲームコンテンツ関係情報を管理して、前記デジタルゲームコンテンツファイル間の依存性を要求に応じてコンテンツ編集プロセスに公開することを可能とする方法であって、
（ａ）前記コンテンツ開発環境内のクライアントプロセスとサーバプロセスとの間で通信するためのデータプロバイダＡＰＩ（application programming interface）を提供するステップであって、前記データプロバイダＡＰＩは、ゲームコンテンツ編集アプリケーションと併用するために構成される、ステップと、
（ｂ）前記データプロバイダＡＰＩで資産関係管理ファイルを生成するステップであって、前記資産関係管理ファイルは、資産識別子、ならびに参照関係および注釈のうち少なくとも１つを含み、前記資産関係管理ファイルは、前記クライアントコンテンツ編集プロセスにより編集されているデジタル資産から前記データプロバイダＡＰＩにより書き出される、ステップと、
（ｃ）前記資産関係ファイルをデータストアに記憶するステップと、
（ｄ）少なくとも前記資産関係管理ファイルに基づいて資産関係グラフを生成するステップであって、前記資産関係グラフは、複数の資産グラフノードを備え、前記資産グラフノードは、複数のデジタルゲームコンテンツファイル間の依存関係をマップし、それぞれは特定の資産識別子により一意に識別され、前記デジタルゲームコンテンツ間の依存関係を要求に応じてコンテンツ編集プロセスに公開する、ステップと
を備えることを特徴とする方法。
【請求項２】
前記コンテンツ開発環境内のクライアントプロセスとサーバプロセスとの間で通信するためのグラフＡＰＩを提供するステップであって、前記グラフＡＰＩは、サーバプロセスを通して前記関係グラフにアクセスして資産関係データおよび注釈データを前記クライアントプロセスに公開するよう構成された、ステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項３】
（ａ）特定の資産に関連付けられた情報を要求するクライアントプロセスから前記グラフＡＰＩに対する呼び出しを受信するステップと、
（ｂ）前記呼び出しに応じて、前記グラフＡＰＩから資産情報要求を発行するステップと、
（ｃ）前記の特定の資産に関連付けられた前記情報に対して前記資産関係グラフを問い合わせるステップと、
（ｄ）前記グラフＡＰＩから前記呼び出しへの応答を前記クライアントプロセスに返すステップであって、前記応答は、前記特定の資産に関連付けられ、かつ前記問合せステップから生じる情報に基づく、ステップと
をさらに備えることを特徴とする請求項２に記載の方法。
【請求項４】
前記の特定の資産に関連付けられた前記情報に対して前記関係グラフを問い合わせるステップは、
（ａ）前記グラフＡＰＩを通して資産関係オブジェクトモデルにアクセスするステップであって、前記資産関係オブジェクトモデルは、前記資産関係グラフの前記複数の資産グラフノードをナビゲートするよう構成され、参照関係及び注釈を公開する、ステップと、
（ｂ）前記資産関係グラフ内で前記の特定の資産に関連付けられたそれぞれの参照関係を識別するステップと
を含むことを特徴とする請求項３に記載の方法。
【請求項５】
資産関係管理スキーマを提供するステップであって、前記資産関係管理スキーマは、注釈オブジェクトおよび関係参照オブジェクトのうち少なくとも１つを定義する、ステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項６】
前記資産関係管理ファイルは、ＸＭＬ文書で具現化した前記資産関係管理スキーマを備えることを特徴とする請求項５に記載の方法。
【請求項７】
前記注釈は、
（ａ）資産バージョンインジケータと、
（ｂ）資産承認インジケータと、
（ｃ）資産説明と、
（ｄ）色深度インジケータと、
（ｅ）前記資産に関連付けられた圧縮アルゴリズムデータと、
（ｆ）日付インジケータと、
（ｇ）資産タイプインジケータと、
（ｈ）前記資産に関連付けられたルールと、
（ｉ）前記資産に関連付けられた属性と
のうち少なくとも１つであることを特徴とする請求項１に記載の方法。
【請求項８】
前記関係グラフを生成するステップは、
（ａ）前記資産関係管理ファイルを関係管理エンジンに提供するステップであって、前記関係管理エンジンは、前記データストアと通信するために構成される、ステップと、
（ｂ）前記資産関係管理ファイルを構文解析してそれぞれの参照関係および注釈を識別するステップと、
（ｃ）前記資産関係グラフ内のノードツリーを生成するステップであって、前記ノードツリーは、前記資産関係管理ファイルに関連付けられ、前記構文解析ステップで識別された参照関係および注釈のうち少なくとも１つに関連付けられた前記資産関係グラフのそれぞれの資産ノードへマッピングする、ステップと
を含むことを特徴とする請求項１に記載の方法。
【請求項９】
（ａ）前記関係管理エンジンを構成して前記データストアを監視し、それぞれの新規資産管理ファイルを識別するステップと、
（ｂ）前記関係管理エンジンを起動して、識別されたそれぞれの新規資産管理ファイルを、資産ノードとして前記資産関係グラフ内部のインスタンス化にマップするステップと
をさらに備えることを特徴とする請求項８に記載の方法。
【請求項１０】
分散処理システム内のクライアントプロセスとサーバプロセスとの間で通信して、複数のデジタルコンテンツファイル間の関係情報を公開可能とするための機械可読命令を有する記憶媒体であって、コンピュータ実行可能命令はコンピューティング装置による実行時に、
（ａ）前記クライアントプロセスによって、資産識別子、データストア識別子、およびクライアント要求機能を含む複数の呼び出しパラメータを有するＡＲＭ＿ｇｒａｐｈ呼び出しを発行するステップと、
（ｂ）前記サーバプロセスによって、前記ＡＲＭ＿ｇｒａｐｈ呼び出しを受信し、前記ＡＲＭ＿ｇｒａｐｈ呼び出しを構文解析して前記複数の呼び出しパラメータを取り出すステップと、
（ｃ）前記サーバプロセスによって、前記ＡＲＭ＿ｇｒａｐｈ呼び出しに応じてＡＲＭグラフをロードし、前記デジタルコンテンツファイル間の関係情報を公開可能とするステップと
を含む複数の機能を実行させることを特徴とする記憶媒体。
【請求項１１】
前記機械可読命令は、実行時に、
（ａ）前記サーバプロセスによって、前記ＡＲＭ＿ｇｒａｐｈ呼び出しに応じて前記ＡＲＭグラフに問い合わせるステップと、
（ｂ）前記サーバプロセスによって、前記資産識別子、ならびに資産関係参照および注釈のうち少なくとも１つを備える複数の受理パラメータを有するＡＲＭ＿ｇｒａｐｈ受理を発行するステップと、
（ｃ）前記クライアントプロセスによって、前記ＡＲＭ＿ｇｒａｐｈ受理を受信するステップと
の機能をさらに実行させることを特徴とする請求項１０に記載の記憶媒体。
【請求項１２】
前記機械可読命令は、実行時に、
（ａ）前記ＡＲＭ＿ｇｒａｐｈ受理を構文解析して、前記複数の受理パラメータのうち少なくとも１つを取り出すステップと、
（ｂ）前記の取り出した少なくとも１つのパラメータをクライアントアプリケーションプロセスに提供して、前記デジタルコンテンツファイル間の関係情報を公開するステップと
の機能をさらに実行させることを特徴とする請求項１１に記載の記憶媒体。
【請求項１３】
ＡＲＭ＿ｇｒａｐｈデータ構造をその上に記憶し、
（ａ）第１の資産を表す第１のＡＲＭグラフノードであって、第１の資産識別子、ならびに参照関係および注釈のうち少なくとも１つを含む第１のＡＲＭグラフノードと、
（ｂ）第２の資産を表す第２の関係グラフノードであって、前記第２の資産は第２の資産識別子、ならびに少なくとも前記第１の関係グラフノードにマッピングする第２の参照関係および第２の注釈のうち少なくとも１つを含む第２の関係グラフノードと
を備えることを特徴とする請求項１１に記載の記憶媒体。
【請求項１４】
前記機械可読命令はアプリケーションプロセスと前記クライアントプロセスとの間の通信を提供し、実行時に、
（ａ）前記アプリケーションプロセスによって、資産識別子、クライアント要求機能、ならびに参照関係および注釈のうち少なくとも１つを備える複数の呼び出しパラメータを有するＡＲＭ＿ｄａｔａ＿ｐｒｏｖｉｄｅｒ呼び出しを発行するステップと、
（ｂ）前記クライアントプロセスによって、前記ＡＲＭ＿ｄａｔａ＿ｐｒｏｖｉｄｅｒ呼び出しを受信し、前記呼び出しを構文解析して前記パラメータを取り出し、前記クライアント要求機能を実行するステップと、
（ｃ）前記クライアントプロセスによって、前記の取り出したパラメータを備える前記ＡＲＭファイルを発行するステップと、
（ｄ）前記サーバプロセスによって、前記ＡＲＭファイルを受信して、前記ＡＲＭファイルをデータストアに記憶するステップと
の機能を実行することを特徴とする請求項１０に記載のコンピュータ可読媒体。
【請求項１５】
コンテンツ開発環境内部のデジタルコンテンツファイル間の相互関係の公開に使用可能なデジタルコンテンツ関係管理を可能とするシステムであって、
（ａ）デジタルコンテンツ関係の管理に使用するデータを記憶するデータストアと、
（ｂ）前記データストアと通信するサーバコンピュータであって、前記サーバコンピュータは、プロセッサ、および前記プロセッサと通信するメモリとを含み、前記メモリは、
（ｉ）前記データストア内に記憶した前記データと相互作用して、ＡＲＭ＿ｇｒａｐｈアプリケーションプログラミングインタフェースを可能とするために構成された関係オブジェクトモデル・モジュールと、
（ｉｉ）前記データストア内に記憶した前記データと相互作用してＡＲＭ＿ｄａｔａ＿ｐｒｏｖｉｄｅｒアプリケーションプログラミングインタフェースを可能とするために構成された関係エンジンモジュールであって、前記関係オブジェクトモデルおよび前記関係エンジンは、前記コンテンツ開発環境内部の前記デジタルコンテンツファイル間の相互関係の公開を可能とする、関係エンジンモジュールと
を含む実行可能ソフトウェアモジュールを記憶する、サーバコンピュータと
を備えることを特徴とするシステム。
【請求項１６】
前記サーバコンピュータと通信するクライアントコンピューティング装置をさらに備え、前記クライアントコンピューティング装置はプロセッサ、および前記コンピューティング装置の前記プロセッサと通信するメモリとを含み、前記メモリは、
（ａ）アプリケーションと、
（ｂ）ＡＲＭ＿ｇｒａｐｈアプリケーションプログラミングインタフェースと
を含む実行可能ソフトウェアモジュールを記憶することを特徴とする請求項１５に記載のシステム。
【請求項１７】
前記ＡＲＭ＿ｇｒａｐｈアプリケーションプログラミングインタフェースは、
（ａ）前記アプリケーションから受信した資産情報に対する要求を識別するステップと、
（ｂ）前記要求に基づいて、特定の資産識別子、データストア識別子、およびクライアント要求機能を含む複数の呼び出しパラメータを有するＡＲＭ＿ｇｒａｐｈ呼び出しを生成するステップと、
（ｃ）関係オブジェクトモジュール経由で、前記サーバコンピュータによって受信されたＡＲＭ＿ｇｒａｐｈ呼び出しは前記サーバコンピュータの前記プロセッサに、
（ｉ）前記ＡＲＭ＿ｇｒａｐｈ呼び出しを構文解析して前記複数の呼び出しパラメータを取り出すことと、
（ｉｉ）前記ＡＲＭ＿ｇｒａｐｈ呼び出しに応じてＡＲＭグラフをロードすることと、
（ｉｉｉ）前記ＡＲＭグラフを問い合わせることと、
（ｉｖ）前記の特定の資産識別子、ならびに資産関係参照および注釈のうち少なくとも１つを備える複数の受理パラメータを有するＡＲＭ＿ｇｒａｐｈ受理を発行することと
を行わせ、
（ｄ）前記クライアントコンピューティング装置が前記ＡＲＭ＿ｇｒａｐｈ受理を受信し、前記受理パラメータを前記アプリケーションに提供することを可能とするステップと
を含む複数の機能を前記プロセッサに実行させるデータと機械命令とを備えることを特徴とする請求項１６に記載のシステム。
【請求項１８】
前記データは、
（ａ）資産識別子領域、ならびに資産関係参照領域および注釈領域のうち少なくとも１つによって定義されたＡＲＭファイルデータ構造と、
（ｂ）複数の資産ノードを含むＡＲＭグラフであって、複数の資産ノードのそれぞれの資産ノードは、依存関係が存在する前記複数の資産ノードの全ての他のノードに対するマッピングを含むＡＲＭグラフと
を含む複数のデータ構造を備えることを特徴とする請求項１５に記載のシステム。
【請求項１９】
前記ＡＲＭ＿ｄａｔａ＿ｐｒｏｖｉｄｅｒアプリケーションプログラムインタフェースは、
（ａ）前記アプリケーションから受信したＡＲＭ＿ｄａｔａ＿ｐｒｏｖｉｄｅｒ呼び出しを識別するステップであって、前記ＡＲＭ＿ｄａｔａ＿ｐｒｏｖｉｄｅｒ呼び出しは、資産識別子、クライアント要求機能、ならびに参照関係および注釈のうち少なくとも１つを含む複数の呼び出しパラメータを有するステップと、
（ｂ）前記ＡＲＭ＿ｄａｔａ＿ｐｒｏｖｉｄｅｒ呼び出しに応じて、前記資産識別子によって識別された資産に対する前記アプリケーションから利用可能なデジタル資産情報にアクセスしてパラメータを取り出すステップであって、前記パラメータは参照関係および注釈のうち少なくとも１つを含む、ステップと、
（ｃ）前記の取り出したパラメータに基づいてＡＲＭファイルデータ構造を生成するステップと、
（ｄ）前記ＡＲＭファイルデータ構造を前記サーバコンピュータに記憶用に提供するステップと
を含む複数の機能を前記プロセッサに実行させるデータと機械命令とを備えることを特徴とする請求項１８に記載のシステム。
【請求項２０】
前記関係エンジンは、
（ａ）前記データストアにアクセスしてそれぞれのＡＲＭファイルを識別するステップと、
（ｂ）識別したそれぞれのＡＲＭファイルが前記ＡＲＭグラフにマップされるか否かを判定するステップと、
（ｃ）判定の結果に従って、それぞれのＡＲＭファイルを集計し、前記ＡＲＭグラフにマップされていないそれぞれのＡＲＭファイルに対して前記ＡＲＭグラフ内に新規資産ノードを生成するステップと
を含む複数の機能を実行するよう構成されることを特徴とする請求項１８に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＸＮＡ関係管理に関する。
【背景技術】
【０００２】
ビデオゲームをプレイするために使用するもののようなメディアコンソールは、過去数年で大幅に市場に浸透した。結果として、ゲーム開発者は便宜的な方法でゲームを製造して市場に出すことに特に関心がある。しかしながら、ゲームおよび他のメディアコンソールソフトウェアの開発には、アーティストおよびプログラマから成る大規模なチームによる相当な工数が必要である。アーティストおよびプログラマから成るゲーム開発チームは、自身の開発グループ内部の他のアーティストおよびプログラマの同時の活動を明確に知らずに、新規ゲームの別々の部分に取り組むことがよくある。このような開発環境では、アーティストにより開発されたゲームコンポーネントは、他のコンポーネントにも含まれる幾つかのコンポーネント要素を含むことがある。
【０００３】
ゲームまたは他のソフトウェアアプリケーションの多数のコンポーネントは、ソフトウェア要素を、同一の要素のファイルまたはデータとの依存関係を有する異なるコンポーネントと、共有することができる。例えば、ゲームにおける車の形状を、現物の“車”のメッシュにより定義することができ、そのメッシュに幾つかの色、素材、およびテクスチャが適用される。例えば、特定の赤を車のボディの色に使用することができ、テクスチャおよび色の両方を備えることができる「クロム（chrome）」を車のハイライトに使用することができる。この例では、その色／テクスチャの「クロム」がゲームの他の車およびコンポーネントにも使用されることもありうるであろう。残念ながら、ゲーム開発中に、他のコンポーネントにより共有される色またはテクスチャ要素をアーティストが変更すると、アーティストの変更により影響される他のコンポーネントを容易に判定することができない。さらに、アプリケーションをコンパイルして実行するまで複数の依存性が明らかにならず、意図しない変更が品質レビューサイクル中でのみ明らかになる恐れがある。さらに、相互に共有されたコンポーネントのテクスチャまたは色を修正するときに好ましくない変更を実際にもたらしたアーティストを、影響されうるゲームのそれぞれのコンポーネントをレビューせずに、コンパイルステップの前に判定することは困難である恐れがある。
【０００４】
過去に使用され、もはやゲーム内で使用されていないが、まだゲームのファイルセットに含まれるテクスチャファイルをもたらす変更が行われることがよくある。結果として、多数のゲームは過剰なコンテンツおよび／または孤立したファイルを含み、それらはもはやゲームにより使用されず、または必要とされない。テクスチャファイルを削除することで悪影響を受けるコンポーネントが明らかでない可能性があるので、ゲーム開発者は開発中にコンテンツを削除することを躊躇する。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従って、ゲーム開発業界内では、ゲームコンテンツの管理と、これらのコンポーネントのレンダリングにおいて使用する、コンポーネントとファイルとの間の関係の管理とを促進する新規のアプローチを開発することが必要である。最小のコストで普遍的に適用可能であり、かつゲームの開発中に発生するこれらおよび他の関連問題に対処するアプローチが必要である。
【課題を解決するための手段】
【０００６】
デジタルゲームコンテンツの関係情報の管理に対する実装を説明する幾つかの例を以下で提供する。ゲームコンテンツの関係情報は、一般に、例えばクライアントサーバゲーム開発環境のような分散処理システム内部に存在する一連のデジタルゲームコンテンツファイルに関連付けられる。
【０００７】
以下でより詳細に説明する１つの実装は、クライアントプロセスとサーバプロセスとの間で通信するためのデータプロバイダＡＰＩを提供する、というようなステップを含む。データプロバイダＡＰＩを、ゲームコンテンツ編集アプリケーションまたはツールと併用するために構成されるものとして説明する。別のステップは、データプロバイダＡＰＩを使用する資産関係管理ファイル（asset relationship management file）の生成に関する。この例示的な実装では、資産関係管理ファイルは、参照関係（relationship reference）および注釈（annotation）のような情報を含む。資産関係管理ファイルは、クライアントコンテンツ編集プロセスにより編集されているデジタル資産に対してデータプロバイダＡＰＩによって生成される。このコンテンツおよび編集プロセスは、例えば、アート編集、またはサウンド編集アプリケーションの一部であることができる。さらに別のステップは、資産関係管理ファイルをデータストアに記憶することに関する。最後に、例示的な実装は、一連の資産関係管理ファイルに基づく資産関係グラフを生成するステップを含む。資産関係グラフは、一般に、デジタルゲームコンテンツファイル間の依存関係をマップする資産グラフノードを含む。以下で説明する別の実装は、分散処理システム内のクライアントプロセスとサーバプロセスとの間で通信するためのグラフＡＰＩを提供するステップを含む。この例示的な実装では、グラフＡＰＩが、サーバプロセスを通して関係グラフにアクセスするために構成され、資産関係データおよび注釈データをクライアントプロセスに公開する。
【０００８】
本要約はいくつの概念を簡潔な形で導入するために提供されている。その概念を以下の「発明を実施するための最良の形態」でさらに詳細に説明する。しかしながら、本要約は特許請求する主題の主要または本質的な特徴を特定するようには意図しておらず、特許請求する主題の範囲の決定における支援として使用するようにも意図していない。
【０００９】
１つまたは複数の例示的な実施形態およびそれに対する修正の様々な態様と付随する利点は、付属図面と併せて捉えると、以下の詳細な説明を参照してより容易に理解でき、より良く理解できるであろう。
【発明を実施するための最良の形態】
【００１０】
＜図および開示した実施形態は限定的ではない＞
例示的な実施形態を、図面の参照図において示す。本明細書で開示する実施形態および図は限定的ではなく例示的と考えるべきであることを意図している。さらに、添付請求項では、語句「少なくとも１つの」または「〜のうち１つ」に続く接続詞「および」を代替物のリストで使用するとき、「および」の意図した意味は接続詞「または」に対応する。
【００１１】
＜例示的なコンピューティングシステム＞
図１は、ネットワーク上、インターネット上、または単一のコンピューティング装置上といったコンピューティング装置上で開始されたデジタルコンテンツ関係管理機能の様々な態様を可能とする例示的なコンピューティング装置および／またはコンピュータサーバの機能ブロック図である。
【００１２】
以下の議論は、後述するある特定の方法の実装に適したコンピューティング環境の簡潔で一般的な説明を与えることを意図している。さらに、以下の議論は、プログラムモジュールのようなコンピュータ実行可能命令をコンピューティングシステムで実装するコンテキストを示す。一般に、プログラムモジュールには、特定のタスクを実施するかまたは特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造、等が含まれる。当業界の技術者は、マルチプロセッサシステム、メインフレームコンピュータ、パーソナルコンピュータ、プロセッサ制御家庭用電化製品、ＰＤＡ（personal digital assistant）（サーバ機能性が要求されるときは含まれない）、等を含む他のコンピューティングシステム構成を適用できることを認識するであろう。１つの実装は、通信ネットワークを通してリンクしたリモート処理装置によりタスクを実施する分散コンピューティング環境を含む。分散コンピューティング環境では、プログラムモジュールをローカルおよびリモートメモリ記憶装置の両方に配置することができる。
【００１３】
図１を参照する。様々な方法の実装に適した例示的なシステムを示す。システムは汎用コンピューティング装置を、処理ユニット２１、システムメモリ２２、およびシステムバス２３を与えた従来のＰＣ２０の形で含む。システムバスは、システムメモリを含む様々なシステムコンポーネントを処理ユニット２１に結合し、メモリバスまたはメモリコントローラ、周辺バス、および任意の様々なバスアーキテクチャを使用したローカルバスを含む数種のバス構造のうち任意のものであることができる。システムメモリはＲＯＭ（read only memory）２４およびＲＡＭ（random access memory）２５を含む。
【００１４】
ＢＩＯＳ（basic input/output system）２６は、例えばシステム起動時にＰＣ２０内部の要素間での情報転送を可能とする基本ルーチンを含み、ＲＯＭ２４に記憶される。ＰＣ２０はさらに、ハードディスク（図示せず）を読み書きするハードディスクドライブ２７、取り外し可能磁気ディスク２９を読み書きする磁気ディスクドライブ２８、およびＣＤ−ＲＯＭ（compact disk-read only memory）または他の光媒体のような取り外し可能光ディスク３１を読み書きする光ディスクドライブ３０を含む。ハードディスクドライブ２７、磁気ディスクドライブ２８、および光ディスクドライブ３０はそれぞれ、ハードドライブインタフェース３２、磁気ディスクドライブインタフェース３３、および光ディスクドライブインタフェース３４によりシステムバス２３に接続される。ドライブおよびその関連コンピュータ可読媒体はコンピュータ可読機械命令、データ構造、プログラムモジュール、およびＰＣ２０に対する他のデータの不揮発性記憶を提供する。説明した例示的環境ではハードディスク２７、取り外し可能磁気ディスク２９、および取り外し可能光ディスク３１を使用するが、当業界の技術者は、磁気カセット、フラッシュメモリカード、ＤＶＤ（digital versatile disks）、ベルヌーイカートリッジ、ＲＡＭ、ＲＯＭ、等のような、コンピュータがアクセス可能なデータおよび機械命令を記憶可能な他種のコンピュータ可読媒体を使用してもよいことを認識するであろう。
【００１５】
オペレーティングシステム３５、１つまたは複数のアプリケーションプログラム３６、他のプログラムモジュール３７、およびプログラムまたは他のデータ３８を含む多数のプログラムモジュールおよび／またはデータをハードディスク２７、磁気ディスク２９、光ディスク３１、ＲＯＭ２４、またはＲＡＭ２５に記憶することができる。ユーザはＰＣ２０に命令または情報を入力し、キーボード４０およびポインティングデバイス４２のような入力装置を通して制御入力を提供することができる。ポインティングデバイス４２はマウス、スタイラスペン、無線リモート制御、または他のユーザインタラクティブポインタを含むことができる。以下の説明で使用するとき、用語「マウス」はスクリーン上のカーソル位置の制御に有用な任意のポインティングデバイスを網羅することを意図している。他の入力装置（図示せず）はマイクロフォン、ジョイスティック、触覚ジョイスティック、ヨーク、フットペダル、ゲームパッド、パラボラアンテナ、スキャナ、等を含むことができる。また、ＰＣ２０はＢｌｕｅｔｏｏｔｈ無線、もしくはプリンタのような他のインタフェース装置と通信するための他の無線インタフェース、またはネットワークを含むことができる。これらおよび他のＩ／０（input/output）装置を、システムバス２３に結合したＩ／０インタフェース４６を通して処理ユニット２１に接続することができる。語句「Ｉ／０インタフェース」は、シリアルポート、パラレルポート、ゲームポート、キーボードポート、および／またはＵＳＢ（universal serial bus）に特に使用されるそれぞれのインタフェースを網羅することを意図している。必要に応じて、モニタ４７をビデオアダプタ４８のような適切なインタフェース経由でシステムバス２３に接続することができる。一般に、ＰＣを（図示していないが、サウンドカードまたは他のオーディオインタフェースを通して）スピーカおよびプリンタのような他の周辺出力装置（図示せず）に結合することもできる。
【００１６】
以下で説明するある特定のプロセスを単一のマシン上で実践できるが、ＰＣ２０はリモートコンピュータ４９のような１つまたは複数のリモートコンピュータに対する論理接続を使用してネットワーク環境で動作することもできる。リモートコンピュータ４９は別のＰＣ、（ＰＣ２０のように構成可能な）サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または衛星または他の共通ネットワークノード（これらのいずれも図示せず）であることができ、リモートコンピュータは一般にＰＣ２０に関連して上述した要素の多数または全てを含むが、リモートコンピュータに対して外部メモリ記憶装置５０のみを図１では示した。図１に示す論理接続はＬＡＮ（local area network）５１およびＷＡＮ（wide area network）５２を含む。上記のネットワーク環境は職場、企業規模のコンピュータネットワーク、イントラネット、およびインターネットで一般的である。１つの特定の実装では、ＰＣ２０はサーバコンピュータ、他のＰＣ、データベース等のような他のコンピューティング装置を含むゲーム開発環境のコンポーネントである。
【００１７】
ＬＡＮネットワーク環境で使用するとき、ＰＣ２０はネットワークインタフェースまたはアダプタ５３を通してＬＡＮ５１に接続される。ＷＡＮネットワーク環境で使用するとき、ＰＣ２０は一般にモデム５４、またはケーブルモデム、ＤＳＬ（Digital Subscriber Line）インタフェース、またはインターネットのようなＷＡＮ５２上で通信を確立するためのＩＳＤＮ（Integrated Service Digital Network）インタフェースのような他の手段を含む。モデム５４は内部または外部にあることができ、システムバス２３に接続、またはＩ／０装置インタフェース４６経由、即ちシリアルポートを通してバスに結合される。ネットワーク環境では、ＰＣ２０により使用されるプログラムモジュール、またはその一部をリモートメモリ記憶装置に記憶することができる。当然のことながら、示したネットワーク接続は例であって、コンピュータ間の通信リンクを確立する、無線通信および広帯域ネットワークリンクのような他の手段を使用してもよい。
【００１８】
＜例示的動作環境＞
図２は、デジタルコンテンツ間の関係を管理する様々な方法を実装する例示的な動作環境２００のブロック図である。図２に示すように、サーバ２００はデータストア２１０およびクライアント２２０と通信する。クライアント２２０により生成されている資産関係管理（ＡＲＭ：asset relationship management）ファイル２３５を図２に示す。
【００１９】
サーバ２００は、図１を参照して議論した例示的なコンピューティング装置および／またはコンピュータサーバのような任意のコンピューティング装置であることができる。サーバ２００が上記コンポーネントを含むことは当業界の技術者には明らかであろうが、明確さのため、および本開示を簡潔にするため、プロセッサ２０６およびメモリ２０７を含むとしてのみサーバ２００を示す。メモリ２０７を、オブジェクトモデル・モジュール２０２、関係エンジンモジュール２０３を含む関係マネジャアプリケーション２０１を含むとして示してあり、メモリ２０７はＡＲＭ＿ｇｒａｐｈ  ＡＰＩ ２５０を含むこともできる。それらの各々を以下で詳細に議論する。
【００２０】
クライアント２２０は、図１を参照して議論した例示的なコンピューティング装置および／またはコンピュータサーバのような任意のコンピューティング装置またはシステムであることができる。幾つかの実装では、クライアント２２０はＬＡＮまたはＷＡＮのようなネットワークに結合したＰＣであり、またはインターネット上の安全な接続（図示せず）を通して１つまたは複数の他のコンピューティング装置に結合したＰＣである。他の実装では、クライアント２２０はアートエディタ、サウンドエディタ、資産レポートジェネレータおよび他の生産性アプリケーションのようなアプリケーションを実行するよう構成した任意のコンピューティング装置であることができる。図２に示すように、クライアント２２０はアートエディタ・アプリケーション２２１を含む。アートエディタ・アプリケーション２２１を使用して、デジタルゲームコンポーネントのようなデジタルコンテンツにアクセスすること、そのデジタルコンテンツを作成、修正および／または管理することができる。デジタルゲームコンポーネントは、実行可能ゲームアプリケーションの１つの要素であり、例えば、メッシュファイル、テクスチャおよび／または素材ファイル、サウンドファイル、ＡＩ（artificial intelligence）ファイル、または他の論理ファイル、または他のゲームコンポーネントと依存性を共有可能な任意の他のデジタル資産を含む。アートエディタ２２１を、ＡＲＭ＿ｄａｔａ＿ｐｒｏｖｉｄｅｒ  ＡＰＩ ２３０を含むとして示してある。しかしながら、ＡＲＭ＿ｄａｔａ＿ｐｒｏｖｉｄｅｒ  ＡＰＩ ２３０は、アートエディタ２２１に追加したアドオンコンポーネントまたはモジュールであることができ、または単にＡＰＩ呼び出しを通してアートエディタ２２１によってアクセスされることができる。ＡＲＭ＿ｄａｔａ＿ｐｒｏｖｉｄｅｒ  ＡＰＩ ２３０を、広範囲の既存アプリケーションを改良するように容易に構成して、貴重な資産関係データを開発プラットフォーム独立フォーマットで提供できることを意図している。
【００２１】
ＡＲＭファイル２３５は、参照関係２３６、および注釈２３７を含む特定のデジタル資産に関する任意のエクスポート可能な情報を含むことができる。参照関係２３６は、特定のデジタル資産が任意の他のデジタル資産と有する依存関係または参照関係を定義する論理ステートメントおよび／またはインジケータである。例えば、特定のデジタル資産がメッシュファイルである場合、参照関係２３６はメッシュが特定の素材ファイルを参照する論理ステートメントであることができる。しかしながら、代わりに、特定のデジタル資産が（色を定義するファイルのような）特定の素材ファイルである場合、参照関係２３６はメッシュが特定の素材ファイルに依存する論理ステートメントであることができる。注釈２３７は、エクスポートに有用でありうる他の情報を含むことができる。例えば、注釈は資産バージョンインジケータ、（例えば、アーティストによるサインオフを示す）資産承認インジケータ、資産説明、資産タイプインジケータ、資産に関連付けられたルール、および資産に関連付けられた属性を含むことができる。注釈は、色深度インジケータ、資産に関連付けられた圧縮アルゴリズム情報、または例えば資産の最終編集または最終サインオフ日を示すような特定の日付、といった特定の情報を提供することもできる。１つの実装では、ＡＲＭファイル２３５は、資産関係管理スキーマに従うＸＭＬ文書で具現化したデータ構造である。この実装では、スキーマはＡＲＭ＿ｄａｔａ＿ｐｒｏｖｉｄｅｒ  ＡＰＩにより資産ファイルから書き出した、資産識別、資産に関連付けられた参照関係および様々な注釈のようなデータを表すオブジェクトのためのフォーマットを定義する。ＸＭＬは広範囲に受け入れられ、アプリケーション中立文書フォーマットであるが、ＡＲＭファイルは任意の適切な文書フォーマットで具現化でき、ＸＭＬフォーマットに限定されないことに留意すべきである。
【００２２】
データストア２１０は、ＡＲＭファイル２１１および資産ファイル２１２のような複数のデータ構造、ならびに資産関係グラフ２１５を記憶し、それらを含む。ＡＲＭファイル２１１は、ＡＲＭファイル２３５に関して説明したように任意の資産関係管理ファイルであることができる。資産ファイル２１２は、一般に、メッシュファイル、素材ファイル、サウンドファイル、または別のデジタルゲームコンポーネントファイルのようなデジタルコンテンツファイルである。資産関係グラフ２１５は、図２でノードＡ、Ｂ、およびＣにより示されるように、複数のノードを含むことができる。例として、図２は、ノードＡがノードＢおよびノードＣを参照し、ノードＢがノードＣを参照し、しかしながらノードＣがノードＡおよびノードＢのどちらも参照しないことを示す。さらに、ノードＡ、Ｂ、およびＣはツリー構造を含むことができる。そのツリー構造はさらに、注釈（図示せず）のようなノード依存性および追加情報のマッピングを定義する。
【００２３】
例示および明確さのため、サーバ２００を、関係マネジャ２０１を含むとして示してある。関係マネジャ２０１は、図２では、オブジェクトモデル・モジュール２０２、および関係エンジンモジュール２０３を含むとして示してある。しかしながら、幾つかの実装では、関係マネジャ２０１は実際は１つの実行可能モジュールであり、オブジェクトモデル２０２および関係エンジン２０３の両方の機能性を提供する。他の実装では、オブジェクトモデル２０２および関係エンジン２０３は、別個だが動作的に組み込んだモジュールとして実装される。ＡＲＭ＿ｇｒａｐｈ  ＡＰＩ ２５０をサーバ２００上にオブジェクトモデル２０２および関係エンジン２０３とともに必要に応じて配置することができ、またはサーバ２００のオペレーティングシステム（図示せず）に組み込むことができ、またはアプリケーションの一部として組み込むことができ、または独立したモジュールとして構成することができる。ＡＲＭ＿ｇｒａｐｈ  ＡＰＩ ２５０を広範囲の既存アプリケーションを改良するように構成し、資産関係グラフ２１５内の資産関係データにアクセス可能とし、それによりこれらの既存のアプリケーションに対するこのアプローチの有益な機能性を提供することを意図している。
【００２４】
オブジェクトモデル２０２は、資産関係グラフ２１５に対するインタフェースを提供するように構成される。１つの実装では、オブジェクトモデル２０２は、資産関係グラフのノードをナビゲートし、依存情報を呼び出しアプリケーションに返すことで、資産情報を要求するＡＲＭ＿ｇｒａｐｈ  ＡＰＩからの呼び出しに応答するように構成される。この事例では、呼び出しアプリケーションは、サードパーティツール、様々なカスタムツール、ゲームビルドシステム、またはゲーム自体のような、オブジュクトモデル２０２と（例えば、ＡＲＭ＿ｇｒａｐｈ  ＡＰＩを通して）通信可能な任意のアプリケーションであることができる。一般に、関係エンジン２０３は、データストア２１０に含まれるＡＲＭファイル（例えば、ＡＲＭファイル２２１）を集計するように構成され、ＡＲＭファイルにより記述された異なる関係、依存性、およびコンテンツの注釈の全てから成るマルチグラフ表現を生成する。
【００２５】
１つの例示的な実装では、関係エンジン２０３は、データストア２１０をリアルタイムに監視するよう構成され、作成時に新規のＡＲＭファイルまたは修正したＡＲＭファイルを識別する。この実装では、関係エンジンは、ＡＲＭファイルを構文解析するよう構成され、ＡＲＭファイルにより識別された資産に対する関係情報および注釈を含む資産関係グラフ内のノードを生成することができる。図２では示していない別の実装では、関係エンジン２０３は、ＡＲＭ＿ｇｒａｐｈ  ＡＰＩ呼び出しに応じて、そのオンザフライ（on the fly）での制御下にあるメモリ内で関係グラフをインスタンス化するよう構成される。この実装では、資産関係グラフはデータストア２１０内部ではなくメモリ２０７内に存在することになる。この実装は実行時効率の観点から好適である可能性がある。この場合、多数のクライアントは高速に変化している資産関係情報への同時アクセスを求め、ノードの全数が異常に大きいということはない。
【００２６】
さらなる例として、図３はデジタルコンテンツ関係管理を可能とする適切な動作環境の別の機能ブロック図である。図３に示すように、サーバ２００はデータストア２１０およびクライアント２２０と通信するとして再度示してある。図２に示す実施形態は、データストア２１０を、ＡＲＭファイル２１１、資産ファイル２１２、および資産関係グラフ２１５を含むとして再度示してある。サーバ２００は、プロセッサ２０６およびメモリ２０７を含むとして再度示してあり、メモリ２０７はその内部に記憶した関係マネジャ２０１を有する。上で議論したように、関係マネジャ２０１はオブジェクトモデル２０２および関係エンジン２０３を含む。これら要素の各々の機能性および能力の議論のため、図２に関する上の議論を参照することができる。図３のクライアント２２０は、図１および２を参照して上で議論したもののようなコンピューティング装置を表す。クライアント装置２２０は図１の多数の他のコンポーネントを取り込むであろうことは当業界の技術者には明らかであろうが、明快さのため、図３はアプリケーション３００の記憶に使用するプロセッサ２２６およびメモリ２２７を示すに過ぎない。ＡＲＭ＿ｇｒａｐｈ  ＡＰＩ ２５０をアプリケーション３００内部に示してある。しかしながら、ＡＲＭ＿ｇｒａｐｈ  ＡＰＩ ２５０をアプリケーション３００に組み込む必要はなく、幾つかの実装では、ＡＲＭ＿ｇｒａｐｈ  ＡＰＩ ２５０は、アプリケーションまたはクライアント２２０のオペレーティングシステム（図示せず）と併用するためのプラグインまたは独立したモジュールである。
【００２７】
上で議論したように、ＡＲＭ＿ｇｒａｐｈ  ＡＰＩ ２５０は、広範囲の既存アプリケーションおよび／またはオペレーティングシステムを改良するよう構成され、クライアント装置上で実行しているプロセスから資産関係グラフ２１５内の資産関係データにアクセスすることができる。１つの例では、アプリケーション３００は資産依存性レポートの生成に使用可能なレポートツールであり、ゲーム開発中に利用して、孤立した資産を識別し、または資産ファイルへの無用の変更を追跡することができる。別の実装では、アプリケーション３００はゲーム・ビルド・パイプラインのコンポーネントアプリケーションであることができ、ＡＲＭ＿ｇｒａｐｈ  ＡＰＩを通して資産関係グラフ２１５を呼び出し、例えばゲーム実行ファイルのビルドまたはリビルドを最適化すること、機能性をテストすること、品質保証タスクを実装すること、および証明書承認プロセスを実装することができる。
【００２８】
図４は、分散処理システム内部のデジタルゲームコンテンツファイルに関連付けられたデジタルゲームコンテンツ関係情報を管理する例示的な方法のステップを示すフロー図である。幾つかの実施形態では方法４００を、図１−３を参照して議論したコンポーネント、装置、および技術で実装することができる。幾つかの実装では、方法４００の１つまたは複数のステップをコンピュータ可読媒体上で具現化することができる。そのコンピュータ可読媒体はコンピュータ可読コードを記憶し、その結果、コンピュータ可読コードをマイクロプロセッサのようなコンピューティング装置上で実行するときに一連のステップが実装される。以下の説明では、方法４００の様々なステップを、ある特定の方法のステップも実施可能であるサーバと（必要に応じて）通信してある特定の方法のステップを実施可能なクライアント装置のプロセッサに関して説明する。幾つかの実装では、方法４００の目的から逸脱せずに、または異なる結果をもたらすことなく、方法４００のある特定のステップを組み合わせること、同時または異なる順序で実施することができる。
【００２９】
方法４００はステップ４１０で開始し、分散処理システムにおけるクライアントプロセスとサーバプロセスとの間で通信するためのデータプロバイダＡＰＩを提供する。１つの実装では、データプロバイダＡＰＩは、ゲームコンテンツ編集アプリケーションまたはツールと併用するために構成されることができる。一般に、データプロバイダＡＰＩをプラグインとして提供でき、または、既存アプリケーションもしくはソフトウェアモジュールと併用するためのアドオンコンポーネントとして提供することができる。データプロバイダＡＰＩはそのインストール時に有効であり、データプロバイダＡＰＩをメッシュまたはサウンド編集向けのアートエディタのようなアプリケーションで操作するために構成する。
【００３０】
ステップ４２０では、資産関係管理ファイルをデータプロバイダＡＰＩで生成する。幾つかの実装では、資産関係管理ファイルは、特定のデジタル資産ファイルを一意に識別するデジタル資産識別、他のデジタル資産ファイルとのリンキングおよび／または依存関係を記述する参照関係、ならびに資産ファイルに関連または関する情報を含みうる注釈を含むことができる。一般に、資産関係管理ファイルは、メッシュファイルまたはサウンドファイルの編集のような、クライアントコンテンツ編集プロセスにより編集されているデジタル資産から、データプロバイダＡＰＩによって書き出される。
【００３１】
ステップ４３０では、資産関係管理ファイルをデータストア、例えばハードドライブ上に記憶する。資産関係管理ファイルを、生成後の任意の時点で記憶することができる。幾つかの実装では、ＡＲＭファイルを最初にキャッシュして次いで記憶する。別の実装では、ＡＲＭファイルを、記憶する前に関係エンジンにより待ち行列に入れ、ファイルの即時処理を可能とする。ＡＲＭファイルの幾つかの実装では、注釈オブジェクトおよび参照関係オブジェクトを定義する資産関係管理スキーマを含むことができる。１つの例では、資産関係管理ファイルを資産関係管理スキーマに従ってＸＭＬ文書内で具現化する。別の例では、注釈は資産バージョンインジケータ、資産承認インジケータ、資産の説明、または色深度インジケータのうち１つまたは複数を含むことができる。他の例では、注釈は、資産に関連付けられた圧縮アルゴリズムデータ、日付インジケータ、資産タイプインジケータ、資産に関連付けられたルール、または資産に関連付けられた属性のうち１つまたは複数を含むことができる。注釈は、資産から書き出すことができる任意の情報であることができ、プロセス内の他のユーザに対するリソースとして利用可能である。
【００３２】
ステップ４４０では、資産関係グラフを資産関係管理ファイルに基づいて生成する。幾つかの実装では、資産関係グラフは、一連のデジタルゲームコンテンツファイル間の依存性および参照関係をマップする一連の資産グラフノードから成る。１つの例示的な実装では、生成ステップは、最初に資産関係管理ファイルを関係管理エンジンに提供するステップを含む。この実装では、関係管理エンジンをデータストアと通信するために構成することができる。この実装は、資産関係管理ファイルを構文解析してそれぞれの参照関係および注釈を識別するステップも含む。実装の最終ステップは、資産関係グラフ内のノードツリーを生成することを含む。このステップでは、ノードツリーが最初に資産関係管理ファイルに関連付けられ、次いで、構文解析ステップで識別された任意の参照関係および注釈に関連付けられる資産関係グラフのそれぞれの資産ノードにマップされる。従って、資産関係グラフのそれぞれのノードは、ゲームコンポーネントのようなデジタルコンテンツファイルに対応し、それ自身と、関係管理エンジンにアクセス可能なＡＲＭファイルにより記述される任意の他のデジタルコンテンツファイルとの間の関係をマップする。別の例示的な実装はさらに、データストアを監視し、それぞれの新規の資産管理ファイルを識別して、次いで関係エンジンを起動し、それぞれの識別した新規の資産管理ファイルを、一意なノードとして資産関係グラフのインスタンス化にマップするよう関係エンジンを構成するステップを含む。資産関係グラフを例えばサーバメモリ内部のようなデータストアまたは任意の適切なメモリ位置内部でインスタンス化することができることに留意されたい。
【００３３】
別の例示的な実装はさらに、分散処理システム内のクライアントプロセスとサーバプロセスとの間で通信するグラフＡＰＩを提供するステップを含む。幾つかの実装では、グラフＡＰＩを構成して、サーバプロセスを通して関係グラフにアクセスして資産関係データおよび注釈データをクライアントプロセスに公開することができる。グラフＡＰＩの１つの実装は、特定の資産に関連付けられた情報を要求するクライアントプロセスからのグラフＡＰＩに対する呼び出しを受信すること、および呼び出しに応じてグラフＡＰＩからの資産情報要求を発行することのような一連のステップを含む。さらなるステップには、特定の資産に関連付けられた情報に対する関係グラフを問い合わせること、および、次いでグラフＡＰＩからのクライアントプロセスに対する要求への応答を返すことが含まれる。この実装では、応答は上記の特定の資産に関連付けられ、上記の問合せに基づく。
【００３４】
別の例示的な実装は、グラフＡＰＩを通して資産関係オブジェクトモデルにアクセスすることのような一連のステップを含む。この実装では、資産関係グラフの複数の資産ノードをナビゲートし、次いで参照関係および注釈を公開するように資産関係オブジェクトモデルを構成する。この実装における次のステップは、特定の資産に関連付けられた資産関係グラフにおけるそれぞれの参照関係を識別することを含む。
【００３５】
図５は、ＡＲＭ＿ｇｒａｐｈ  ＡＰＩ（application programming interface）を通して資産関係にアクセスする例示的な方法５００を示すフロー図である。幾つかの実施形態では方法５００を、図１−３を参照して議論したコンポーネント、および技術で実装することができる。幾つかの実装では、方法５００の１つまたは複数のステップを、コンピュータ可読コードを含むコンピュータ可読媒体で具現化し、その結果、コンピュータ可読コードをマイクロプロセッサのようなコンピューティング装置上で実行するときに一連のステップが実装される。以下の説明では、方法５００の一部を、ある方法のステップを上記方法の他の部分も実施可能なサーバと（必要に応じて）通信して実施可能なクライアント装置のプロセッサに関して説明する。幾つかの実装では、方法５００の目的から逸脱せずに、または異なる結果をもたらすことなく、方法５００のあるステップを組み合わせること、同時にまたは異なる順序で実施することができる。方法５００は一般にＡＰＩプロセスを説明し、ステップ５１０で開始する。
【００３６】
ステップ５１０では、ＡＲＭ＿ｇｒａｐｈ呼び出しをクライアントプロセスにより発行する。ＡＲＭ＿ｇｒａｐｈ呼び出しは、資産識別子、データストア識別子、およびクライアント要求機能のような１つまたは複数の呼び出しパラメータを含むことができる。ＡＲＭ＿ｇｒａｐｈ呼び出しは、グラフＡＰＩを有効にした任意の時点で行うことができる。幾つかの実装では、グラフＡＰＩをクライアント側またはサーバ側のいずれかに配置できるが、両方のインスタンス内でクライアントプロセスにより起動することができる。
【００３７】
ステップ５２０では、サーバプロセスはＡＲＭ＿ｇｒａｐｈ呼び出しを受信し、次いでその呼び出しを構文解析してパラメータを取り出す。幾つかの実装では、ＡＲＭ＿ｇｒａｐｈ呼び出しは即座にサーバプロセスを起動して呼び出しを構文解析してパラメータを取り出す。複数の呼び出しが小さいウインドウ内部で異なるクライアントから到着する他の実装では、呼び出しをＦＩＦＯバッファまたは待ち行列にキャッシュして、受信順序で出すことができる。
【００３８】
ステップ５３０では、サーバプロセスはＡＲＭ＿ｇｒａｐｈ呼び出しに応じてＡＲＭ＿ｇｒａｐｈをロードする。データストア内に配置した既存のＡＲＭグラフからＡＲＭグラフをロードすることができ、あるいはまた、呼び出しに基づいてオンザフライで生成されるインスタンスとしてロードすることができる。別のロードプロセスが実行中か否かに基づいてＡＲＭグラフを即座にロードするかまたは待ち行列に入れることができる。１つの実装では、最初にデジタル資産ファイルに対応するデータストア内のそれぞれのＡＲＭファイルにアクセスして、次いで資産ファイルに対するそれぞれの参照をそれぞれのＡＲＭファイルから抽出し、それぞれの資産ファイルに対するノードを生成して、次いで資産ファイル間のそれぞれの関係をそれらのノードを介してマップすることにより、ＡＲＭグラフをロードする。
【００３９】
ステップ５４０では、サーバプロセスはＡＲＭ＿ｇｒａｐｈ呼び出しに応じてＡＲＭグラフを問い合わせる。一般に、問合せはＡＲＭ＿ｇｒａｐｈ呼び出しから構文解析したパラメータに基づく。１つの例示的な実装では、問合せは、ＡＲＭ＿ｇｒａｐｈ呼び出しから構文解析したパラメータ、および特定の資産ファイルに関連する表面関係（surface relationship）および注釈に基づいて、ＡＲＭグラフの１つまたは複数のノードをナビゲートして特定の資産ファイルに対応する１つまたは複数の資産識別子を識別することを含む。問合せを、呼び出しを受信した後、およびＡＲＭグラフが問合せに利用可能となった後の任意の時点で行うことができる。
【００４０】
ステップ５５０では、サーバプロセスは、資産識別子、ならびに資産関係参照および注釈の少なくとも１つを含む複数の受理（acknowledgment）パラメータを有するＡＲＭ＿ｇｒａｐｈ受理を発行する。幾つかの実装では、受理パラメータはＡＲＭ＿ｇｒａｐｈの問合せにより判定された関係および注釈を含むことができる。幾つかの実装では、サーバプロセスは問合せが完了すると即座にＡＲＭ＿ｇｒａｐｈ受理を発行することができる。他の実装では、外部パラメータに依存して、ＡＲＭ＿ｇｒａｐｈ受理を待ち行列に入れて後に発行することができる。
【００４１】
ステップ５６０では、クライアントプロセスはＡＲＭ＿ｇｒａｐｈ受理を受信する。幾つかの実装では、クライアントプロセスは、受理が発行された後、およびクライアントプロセスが通信の受信に対してアクティブになった後の任意の時点で、ＡＲＭ＿ｇｒａｐｈ受理を受信することができる。さらなる実装は、ＡＲＭ＿ｇｒａｐｈ受理を構文解析して受理パラメータを取り出し、次いで取り出したパラメータをクライアントアプリケーションプロセスに提供するステップを含む。１つの例では、ＡＲＭ＿ｇｒａｐｈ受理を受信し、受理パラメータを構文解析して、次いで取り出したパラメータを例えばレポートアプリケーションまたはアートエディタに提供することができるようにＡＲＭ＿ｇｒａｐｈ  ＡＰＩを構成することができる。
【００４２】
１つの例示的な実装では、有形のコンピュータ可読媒体上に記憶したデータ構造は第１の資産を表す第１のＡＲＭグラフノードを含む。この実装では、第１のノードは第１の資産識別子を含むことができる。第１の資産識別子は、ゲームコンポーネントのような第１のデジタル資産、別の資産との関係を定義する参照関係、およびバイナリ名またはルートディレクトリのような資産に関する情報を含みうる注釈を一意に識別する。この実装では、データ構造はさらに第２の資産を表す第２の関係グラフノードを含む。第２の資産は、第２の資産識別子、ならびに少なくとも第１の関係グラフノードにマップする第２の参照関係および第２の注釈のうち少なくとも１つを含む。
【００４３】
図６はＡＲＭ＿ｄａｔａ＿ｐｒｏｖｉｄｅｒ  ＡＰＩで資産関係管理ファイルを生成する例示的な方法６００を示すフロー図である。幾つかの実施形態では方法６００を、図１−３を参照して議論したコンポーネント、および技術で実装することができる。幾つかの実装では、方法６００の１つまたは複数のステップを、コンピュータ可読コードを含むコンピュータ可読媒体上で具現化し、その結果、コンピュータ可読コードをマイクロプロセッサのようなコンピューティング装置上で実行するときに一連のステップが実装される。以下の説明では、方法６００の様々なステップを、ある特定の方法のステップも実施可能であるサーバと（必要に応じて）通信してある特定の方法のステップを実施可能なクライアント装置のプロセッサに関して説明する。幾つかの実装では、方法６００の目的から逸脱せずに、または異なる結果をもたらすことなく、方法６００のある特定のステップを組み合わせること、同時にまたは異なる順序で実施することができる。方法６００は一般に、アプリケーションプロセスとクライアントプロセスとの間の通信を含みうるＡＰＩプロセスを説明する。方法６００はステップ６１０で開始する。
【００４４】
ステップ６１０では、アプリケーションプロセスは、資産識別子、クライアント要求機能、参照関係および注釈のような１つまたは複数の呼び出しパラメータを含むＡＲＭ＿ｄａｔａ＿ｐｒｏｖｉｄｅｒ呼び出しを発行する。１つの実装では、クライアント要求機能は、１つまたは複数のパラメータをＡＲＭファイルに書き出す要求である。１つの実装では、アプリケーションプロセスは、アートエディタもしくはサウンドエディタのようなエディタ、またはレポート生成アプリケーションに関連付けられる。
【００４５】
ステップ６２０では、クライアントプロセスはＡＲＭ＿ｄａｔａ＿ｐｒｏｖｉｄｅｒ呼び出しを受信し、それに応じて、呼び出しを構文解析してパラメータを取り出し、クライアント要求機能を実行する。１つの例示的な実装では、クライアントプロセスはＡＰＩモジュールに関連付けられる。
【００４６】
ステップ６３０では、クライアントプロセスは、取り出したパラメータを含むＡＲＭファイルを発行する。１つの例示的な実装では、ＡＲＭファイルは資産関係管理スキーマに従ってフォーマットされたＸＭＬ文書であり、１つまたは複数のパラメータに対応する１つまたは複数のオブジェクトを定義する。１つの例では、資産関係管理スキーマは単純なリストである。別の例では、資産関係管理スキーマはノードのツリーである。ＡＲＭファイルは任意の適切な文書フォーマット、および多様な既製（即ち、既存）のソフトウェアパッケージでＡＲＭファイルを容易に交換および利用可能とするスキーマとを有することができる。
【００４７】
ステップ６４０では、サーバプロセスはＡＲＭファイルを受信してそのＡＲＭファイルをデータストア（例えば、ハードドライブ）に記憶する。幾つかの実装では、ＡＲＭファイルを、そのＡＲＭファイルに関連する資産ファイルを含む他のファイルとともにローカルに記憶することができる。他の実装では、オフサイトリポジトリ（off-site repository）が、必要に応じて取り出すためにＡＲＭファイルを記憶することができる。さらに他の実装では、ＡＲＭファイルを、資産関係エンジンが制御する揮発性または不揮発性メモリロケーション内に記憶して、オンザフライ資産関係グラフ作成に対する実行時アクセスを可能とすることができる。
【００４８】
さらなる例として、上述のコンテンツ管理アプリケーションおよびコンポーネントの例示的なアプリケーションを、ゲーム開発環境を参照して説明することができる。例えば、３つの別個のグループから成るゲーム開発チームに、新規ビデオゲーム向けの一連の車の開発を依頼する。第１のグループは消防車を開発し、第２のグループはパトカーを開発し、第３のグループはレース用スポーツカー（racy sports car）を開発することとする。第１のチームは消防車のメッシュを開発する。消防車のメッシュは、消防車の形状を定義するワイヤーフレームである。チームはメッシュファイルを中央リポジトリに保存し、素材ファイルおよびサウンドファイルの開発を開始する。素材ファイルおよびサウンドファイルはメッシュファイルに関連付けられ、消防車のレンダリング時に使用する。消防車の赤の正しい陰影を開発した後、第１のグループはメッシュファイルを、消防車の赤の素材ファイルに対するリンクと既存のエンジンサウンドファイルに対するリンクとともに保存する。消防車に対するファイルの全てを、他の開発グループがアクセス可能な同一リポジトリに保存する。
【００４９】
一方で、第２のグループは、パトカーの黒、白、およびクロム部分に対する既存の素材ファイルを選択して既存の車メッシュファイルからパトカーの資産ファイルを構築し、次いでサイレンのサウンドファイルを作成する。参照されるコンポーネントファイルとともに中央リポジトリに保存すると、これらの全てはパトカー資産メッシュファイルにより参照される。第３のグループは新規のスポーツカーメッシュを構築し、それを消防車の赤の素材ファイル、クロムの素材ファイルにリンクし、既存のエンジンサウンドファイルにリンクする。しかしながら、第３のグループは開発中に、既存のエンジンサウンドファイルがスポーツカーの大きな轟音（deep throated roar）には適しておらず、サウンドファイルを編集用に開くことを決定する。そのチームは上記の変更がゲーム内の任意の他のファイルに及ぼす影響を知りたいが、グループは独立して作業しているため、第３のグループは他のグループが同一コンテンツファイルを使用しているか否か、またはエンジンサウンドに対するサウンドファイルに加えた変更がゲームの他の資産にどのように影響を及ぼしうるかを知らない。
【００５０】
しかしながら上述の概念を使用するゲーム開発システムを用いると、上の資産ファイルの各々を保存するとき、ＡＲＭファイルもＡＲＭ＿ｄａｔａ＿ｐｒｏｖｉｄｅｒ  ＡＰＩにより作成される。そのＡＲＭファイルは、資産ファイルが他の資産ファイルに対して有する本質的な関係、および資産ファイルについての有用な情報を含む注釈を、関係管理スキーマに従ってＸＭＬ文書に書き出す。ＡＲＭファイルを、それが表す元の資産ファイル（例えば、車のメッシュ、色、テクスチャ、およびサウンドまたは論理ファイル等のような素材ファイル）のような他のファイルとともに中央データストアに記憶する。次いでＡＲＭファイルを使用して、ＡＲＭファイルが表す資産ファイル間の依存関係の全てをマップする資産関係グラフを生成することができる。ＡＲＭ＿ｄａｔａ＿ｐｒｏｖｉｄｅｒ  ＡＰＩを既存のゲーム開発またはコンテンツ編集スイートに対して改良できること、およびＡＲＭファイル内に含まれるデータを体系化するために使用する関係管理スキーマを複数のプラットフォームに渡って非常に容易に適用できることに留意することが重要である。この能力は、異なる開発ツールまたは専用開発ツールを使用する異なる企業に、資産ファイル依存性情報およびデジタル資産に関する他のデータを他者が使用可能な形態でエクスポートする能力を提供できる。
【００５１】
例えば、上述の第３のグループが既存のエンジンサウンドファイルにアクセスすると、コンテンツ編集アプリケーションはｇｒａｐｈ＿ＡＰＩ経由で関係グラフにアクセスし、エンジンサウンドファイルが別の資産ファイル、即ち消防車資産ファイルにより依存されていることを判定することができる。第３のグループは従って、編集したエンジンサウンドを新規ファイルに保存して、消防車のエンジンサウンドの変更を回避しなければならないことを認識するであろう。同様に、第３のグループがクロムの素材ファイルにアクセスすると、ＡＲＭ＿ｇｒａｐｈ  ＡＰＩを使用してそのグループに、クロムの素材ファイルがパトカーの資産ファイルにより依存され、従ってそのような変更が新規ゲームにおけるパトカーの見かけに影響を及ぼすのでクロムの素材ファイルを（同一のファイル名で）変更すべきでないことを警告することができる。上の例から明らかなように、ゲームに従事している複数のグループは、自身が従事している、メッシュファイル、素材ファイル、サウンドファイル、ＡＩ（artificial intelligence）ファイル、等のような資産ファイルをそれらのファイルが編集または作成されたときにリアルタイムに、異なる開発プラットフォームに渡っても追跡することができる。さらに、ＡＲＭ＿ｄａｔａ＿ｐｒｏｖｉｄｅｒ  ＡＰＩおよびｇｒａｐｈ＿ＡＰＩを通して、ゲームのコンパイル前に資産ファイルの依存性を判定することができ、従って、孤立したファイルおよび冗長性を削除してソフトウェアの「膨張」を軽減し、開発パイプラインを合理化し、品質保証プロセスを改善することができる。
【００５２】
本新規開発を、それを実践する好適な形態およびそれに対する修正に関連して説明したが、当業界の技術者は、添付請求項の範囲内で本概念に多数の他の修正を加えうることを理解するであろう。従って本概念の範囲は、上の説明により限定されること、専ら添付請求項を参照することにより判定されることを決して意図していない。
【図面の簡単な説明】
【００５３】
【図１】１つまたは複数のグレードレベルのタグ付けおよび／または検索機能を実装するのに適した従来の一般的なコンピューティング装置の機能ブロック図である。
【図２】デジタルコンテンツ関係管理を可能とするシステムの機能ブロック図である。
【図３】デジタルコンテンツ関係管理を可能とするシステムの別の機能ブロック図である。
【図４】分散処理システム内部のデジタルゲームコンテンツファイルに関連付けられたデジタルゲームコンテンツ関係情報を管理する例示的な方法のステップを示すフロー図である。
【図５】ＡＲＭ＿ｇｒａｐｈ  ＡＰＩ（application programming interface）を通して資産関係にアクセスする例示的な方法を示すフロー図である。
【図６】ＡＲＭ＿ｄａｔａ＿ｐｒｏｖｉｄｅｒ  ＡＰＩで資産関係管理ファイルを生成する例示的な方法を示すフロー図である。
【図１】
2009525533.tif 000003
【図２】
2009525533.tif 000004
【図３】
2009525533.tif 000005
【図４】
2009525533.tif 000006
【図５】
2009525533.tif 000007
【図６】
2009525533.tif 000008
【国際調査報告】
2009525533.tif 000009
2009525533.tif 000010