JP2018010624A - ゲーム環境内でカバーモードにあるキャラクタの曲線化された移動軌跡を決定する方法及びシステム - Google Patents

Abstract

【課題】カバーモードを特徴とするビデオゲームにおいて、カバーモードにあるキャラクタの曲線化された移動軌跡を決定する。【解決手段】コンピュータシステムであって、データとプログラム指示を格納したメモリを有し、該データはキャラクタと複数のカバーセグメントを含んだゲーム環境を現しており、プレイヤインターフェース、及びメモリに格納されたプログラム指示を実行するように構成された処理装置からなる。プログラム指示を実行すると、コンピュータは以下のステップからなる方法を実行する。カバーセグメントの選択された部分集合を決定すること、カバーセグメントの選択された部分集合に関連する制御ポイントを通過する曲線化されたパスを決定すること、プレイヤインターフェースを介してディスプレィ用画像をレンダリングすること、画像は、キャラクタがカバーモードにある間、曲線化されたパスに沿ったキャラクタの動きを示す。【選択図】図１３

Description

本発明は、カバーモードを特徴とするビデオゲームに関わり、特に、カバーモードにあるキャラクタの曲線化された移動軌跡を決定することに関する。

沢山のアクションゲームにおいて、キャラクタ（メインキャラクタ及びノンプレイングキャラクタ−ＮＰＣ等）は、移動可能な又は移動不可能な壁のようなオブジェクトに沿って「テークカバー（隠れる、避難する）」を行う「カバーモード」に入ることがある。これはキャラクタがその敵から守られる特別なナビゲーションモードであり、その動作は各オブジェクトについて予め決められたカバーラインに沿う形に制限される。例えば、キャラクタが、カバーモードのゲームでオブジェクトからオブジェクトへ移動する際には、システムは直線移動の連続したキャラクタ軌跡で移動する。しかし、これは不自然なぎざぎざの視覚効果を生成し、好ましくないゲーム経験をもたらすこととなる。

本発明の第１の広い観点によると、本発明はコンピュータシステムであり、以下のように構成される；データとプログラム指示を格納するメモリであって、該データはキャラクタ及び複数のカバーセグメントを含んだゲーム環境を表しており；プレイヤインターフェース；前記メモリに格納された前記プログラム指示を実行するように構成された処理装置。前記プログラム指示を実行すると、コンピュータは以下の方法を実行するが、該方法は以下のステップから構成される；前記カバーセグメントの選択された部分集合を決定し；前記カバーセグメントの選択された部分集合に関連した制御ポイントを通る曲線化されたパスを決定し；前記プレイヤインターフェースを介してディスプレィ用の画像をレンダリングする。該画像は前記キャラクタがカバーモードにある間、前記曲線化されたパスに沿った前記キャラクタの移動を表示する。

本発明の第２の広い観点によると、本発明は、ゲーム装置の処理装置によって実行されるゲームプログラムによって裏付けられるゲーム環境内で、キャラクタの動きを制御する方法を提供することであって、前記ゲーム環境はオブジェクト及び該オブジェクトに関連するカバーセグメントを含むものである。該方法によれば、処理装置はカバーセグメントの選択された部分集合を決定し；前記カバーセグメントの選択された部分集合に関連した制御ポイントを通る曲線化されたパスを決定し；前記プレイヤインターフェースを介してディスプレィ用の画像をレンダリングする。該画像は前記キャラクタがカバーモードにある間、前記曲線化されたパスに沿った前記キャラクタの移動を表示する。

本発の第３の広い観点によると、本発明は、コンピュータ可読指示を有するコンピュータ可読媒体を提供することであり、コンピュータ可読指示はゲーム装置の処理装置によって実行されると、該ゲーム装置は、ゲーム環境内のキャラクタの動きを制御する方法を実行する。前記ゲーム環境はオブジェクト及び該オブジェクトに関連するカバーセグメントを含むものである。前記方法は、カバーセグメントの選択された部分集合を決定し；前記カバーセグメントの選択された部分集合に関連した制御ポイントを通る曲線化されたパスを決定し；前記プレイヤインターフェースを介してディスプレィ用の画像をレンダリングする。該画像は前記キャラクタがカバーモードにある間、前記曲線化されたパスに沿った前記キャラクタの移動を表示する。

本発明の 第４の広い観点によると、ゲーム装置の処理装置によって実行されるゲームプログラムにより裏付けられるゲーム環境内で、キャラクタの動きを制御する方法を提供することである。該方法は、処理装置がキャラクタがカバーモードにあるか否かを決定し；該キャラクタがカバーモードにあると決定されると、該キャラクタについての曲線化されたカバーパスを特定するためにメモリを検索し、該カバーパスは少なく一つの曲線化された部分を有し、該キャラクタがカバーモードにある間、前記曲線化されたカバーパスに沿って前記キャラクタの動きを制限する。

本発明の第５の広い観点によると、本発明は、コンピュータ可読指示を有するコンピュータ可読媒体を提供することであり、コンピュータ可読指示はゲーム装置の処理装置によって実行されると、該ゲーム装置はゲーム環境内のキャラクタの動きを制御する方法を実行する。前記方法は、カバーモードにあるキャラクタを決定し；カバーモードにあるキャラクタの決定を受けて、該キャラクタについての曲線化されたカバーパスを特定するためにメモリを検索し、該カバーパスは少なくとも一つの曲線化された部分を有しており；前記キャラクタがカバーモードにある間、前記曲線化されたパスに沿った前記キャラクタの動きを制限する。

本発明の第６の広い観点によると、本発明はコンピュータシステムを提供することであり、該システムは、データ及びプログラム指示を格納したメモリ、前記データは、キャラクタを含むゲーム環境を表すものであり；プレイヤインターフェース；及び前記メモリに格納されたプログラム指示を実行するように構成された処理装置である。プログラム指示を実行すると、コンピュータはカバーモードにあるキャラクタを決定する方法を実行し、カバーモードにあるキャラクタを決定したところで、該キャラクタについてのカバーパスを特定するためにメモリを検索し、該カバーパスは、少なくとも一つの曲線化された部分を有し；前記キャラクタがカバーモードにある間、前記曲線化されたパスに沿った前記キャラクタの動きを制限する。

本発明の第７の広い観点によると、本発明は、ゲーム装置の処理装置によって実行されるゲームプログラムによって裏付けられるゲーム環境内で、キャラクタの動きを制御する方法を提供することである。この方法によると、処理装置はキャラクタの近傍のオブジェクトを特定し、該オブジェクトに関連したカバーセグメントのセットを決定し、前記キャラクタがカバーモードに無い場合には、ナビゲーションメッシュ内でユーザ定義軌跡に沿って前記キャラクタを移動させることを許容し、前記キャラクタがカバーモードにあり、オブジェクトの近傍にある時は、カバーパスにキャラクタの動きを制限する。カバーセグメントは線形（直線状）であり、カバーパスは曲線化されている。

本発明のこれらの及び他の観点及び特徴は、添付した図面と併せて以下の本発明の特定の実施例の記述を参照することで、当業者にとって明らかになる。

図１は、本発明の限定されない例示的な実施例を実装したゲーム装置の構成を示すブロック図である。 図２は、図１のゲーム装置によって実行されるゲームプログラムの要素を示す図であり、ゲームデータ処理機能及びゲームレンダリング処理機能を有するものである。 図３は、本発明の実施例によるゲームデータの一例を示す図。 図４は、３Ｄグラフィック情景をディスプレィ装置に表示するためのゲーム画面に変換する処理の一例を示す図。 図５は、非限定的な実施例である、カバーパス演算サブ処理のステップを示すフローチャートであり、ゲーム装置によって実行されるゲームプログラムの部分を構成する。 図６は、非限定的な実施例である、ゲーム装置のブロック図であり、ゲームプログラムとカバーパス演算サブ処理を概念的に示すものである。 図７Ａは、カバーパス演算サブ処理の非限定的な実施例による、カバーセグメントの、曲線カバーパスへの変換を図示的かつ模式的に示した図。 図７Ｂは、カバーパス演算サブ処理の非限定的な実施例による、カバーセグメントの、曲線カバーパスへの変換を図示的かつ模式的に示した図。 図７Ｃは、カバーパス演算サブ処理の非限定的な実施例による、カバーセグメントの、曲線カバーパスへの変換を図示的かつ模式的に示した図。 図８は、キャラクタと各キャラクタの動作モードの間の関連を格納した、非限定的な実施例を示す図。 図９は、キャラクタと各キャラクタ周辺のオブジェクト間の関連をメモリに格納した非限定的な実施例を示す図。 図１０は、オブジェクトとカバーセグメント間の関連を示した非限定的な実施例を示す図。 図１１は、図８の拡張であり、キャラクタと各キャラクタの最終的なカバーパスのパラメータ間の更なる関連を示した非限定的な実施例を示す図。 図１２は、非限定的な実施例による曲線化されたカバーパスに沿ったキャラクタの動きを制限する方法を示すフローチャート。 図１３は、非限定的な実施例による、キャラクタがカバーモードであるかカバーモードでないかによってキャラクタの移動を制御する方法を示すフローチャートである。

図面及び記述は本発明のある実施例を、理解のために図解する目的のみであり、本発明の範囲を制限するものではない。

図１は、本発明の限定されない例示的な実施例を実装したゲーム装置１の構成を示すブロック図である。ある場合には、ゲーム装置１は、Ｘｂｏｘ（登録商標）、Ｐｌａｙｓｔａｔｉｏｎ（登録商標）又はＮｉｎｔｅｎｄｏ（登録商標）ゲーム筐体といった専用のゲーム筐体である。また他の場合には、ゲーム装置１は、多目的ワークステーション又はラップトップコンピュータである。更に他の場合、ゲーム装置１は、スマートフォンのようなモバイル装置であり、また更に他の場合には、ゲーム装置１は携帯型ゲーム装置である。

ゲーム装置１は、少なくとも一つの処理装置１０、少なくとも一つのコンピュータ可読メモリ１１，少なくとも一つの入出力モジュール１５及び少なくとも一つの電源２７を有し、更にビデオゲームを遊ぶのに使用されるゲーム装置で見受けられるさまざまな部品も含まれる。ゲーム装置１の様様な部品は、データバス、コントロールバス、パワーバスなどのような一つ以上のバスを介して互いに通信することが出来る。

図１に示すように、プレイヤ７は、ディスプレィ装置５のスクリーンに表示されるゲーム画像を見ながら、ゲームコントローラ３を介してゲームの局面を制御することでゲームをプレイする。従って、ゲーム装置１はゲームコントローラ３から入出力モジュール１５を介して入力を受ける。ゲーム装置１は、また、ディスプレィ装置５及び／又はオーディオ装置（例えば、スピーカ、図示せず）に入出力モジュール１５を介して出力を供給する。他の実施例では、入出力モジュール１５に接続されるのは、一つ以上のゲームコントローラ３及び／又は一つ以上のディスプレィ装置５でもよい。

処理装置１０は、一つ以上のコアを有する一つ以上の中央処理ユニット（ＣＰＵ）を有する。また処理装置１０は、出力データを、ディスプレィ装置５のディスプレィの入出力モジュール１５に供給するためのビデオエンコーダ／ビデオコーデック（コーダ／デコーダ、図示せず）と接続された、少なくとも一つのグラフィック処理ユニット（ＧＰＵ）を有する。更に該処理装置１０は、オーディオ装置の入出力モジュール１５に供給される出力データを生成するためのオーディオエンコーダ／オーディオコーデック（コーダ／デコーダ、図示せず）と接続された少なくとも一つのオーディオ処理ユニットを有する。

コンピュータ可読メモリ１１は、ＲＡＭ（ランダムアクセスメモリ）、ＲＯＭ（リードオンリーメモリ）、フラッシュメモリ、ハードディスク駆動装置、ＤＶＤ／ＣＤ／Ｂｌｕｅｒａｙ（登録商標）及び／又は他の適切なメモリ装置、技術又は構成を有する。コンピュータ可読メモリ１１は、ゲームプログラム３３，ゲームデータ３４及びオペレーティングシステム３５などの多様な情報を格納している。

ゲーム装置１の電源が入ると、処理装置１０は処理装置１０を起動するブート処理を実行し、コンピュータ可読メモリ１１と通信する。特にこのブート処理ではオペレーティングシステム３５を実行する。オペレーティングシステム３５は、ゲーム装置に適した何らかの商用又は専用オペレーティングシステムである。オペレーティングシステム３５が実行されると、処理装置１０はディスプレィ装置５に表示する画像を生成し、ゲーム装置１はゲームコントローラ３を介してプレイヤ７が選択することの出来る多様なオプションや、プレイするビデオゲームを選択、及び／又は開始するプレイヤのためのオプションを表示する。プレイヤ７により選択／開始されたビデオゲームは、ゲームプログラム３３によってエンコードされている。

処理装置１０は該ゲームプログラム３３を実行して、エンコードされたビデオゲームに関連する多様な種類の情報処理機能を実行することが出来るように構成されている。特に、図２に示すように、ゲームプログラム３３を実行することで処理装置は、以下に述べるゲームデータ処理機能２２及びゲームレンダリング処理機能２４を実行することとなる。

ゲームレンダリング処理機能２４はディスプレィ装置５に表示されるゲーム画像の生成を含むものである。ここで、ゲームデータ処理機能２２は、ゲームの進行やゲームの現在状態を表す情報を処理することを含む（例えば、ディスプレィ装置５に表示する必要のないゲームに関する情報の処理）。図２では、ゲームデータ処理機能２２及びゲームレンダリング処理機能２４は、単一のゲームプログラム３３の一部を構成している。しかし、他の実施例では、ゲームデータ処理機能２２及びゲームレンダリング処理機能２４は、別個のメモリに格納された別個のプログラムであり、分かれた、恐らく遠方の処理装置により実行される場合もある。例えば、ゲームレンダリング処理機能２２は、ＣＰＵで実行することもでき、ゲームレンダリング処理機能２４はＧＰＵで実行することも出来る。

ゲームプログラム３３の実行中には、処理装置１０は、オブジェクト、キャラクタのような構成物、及び／又はあるゲームの規則に従ったレベルを操作し、ある種の人工的な知的アルゴリズムの適用を行う。ゲームプログラム３３の実行中、処理装置１０は、生成、ロード、格納、読み込みを行い、また、オブジェクトやキャラクタ及び／又はレベルに関するデータを持ったゲームデータ３４に全般的なアクセスを行う。図３は、本発明の実施例に基づくゲームデータ３４の一例である。ゲームデータ３４は、前述の構成に関するデータを有しており、従って、オブジェクトデータ４２，キャラクタデータ４６及び／又はレベルデータ４４を含む。

オブジェクトとは、ゲーム画像のフレーム（コマ）にグラフィカルに表示することの出来るゲーム環境における何らかの素子又は素子の部分を表す。オブジェクトは、建物、車両、家具、植物、空、大地、大洋、太陽及び／又は何らかの適当な素子を３次元的に表現したものである。オブジェクトは、数字、幾何学又は数学的な表現のような、他の非グラフィカルな表現であることもある。オブジェクトデータ４２は、ゲーム画像のフレーム内でのグラフィカルな表現のような、オブジェクトの現在表現についてのデータや、数字、幾何学又は数学的な表現についてのデータを格納する。オブジェクトデータ４２としては、画像データ、位置データ、材料／テクスチャデータ、物理状態データ、可視性データ、照明データ（例えば、方向、位置、色及び／又は強度）、サウンドデータ、モーションデータ、衝突データ、環境データ、タイマーデータ及び／又は該オブジェクトに関連する他のデータなどの属性データも格納することができる。オブジェクトのある種の属性データはゲームプログラム３３により制御することができる。

キャラクタは、オブジェクトに類似するが、属性は本質的により動的であり、オブジェクトが通常持たない追加的な属性を持っている。例えば、プレイングキャラクタのある属性は、プレイヤ７により制御することが出来る。プレイングキャラクタ又はノンプレイングキャラクタであれ、キャラクタのある属性は、ゲームプログラム３３により制御され得る。キャラクタの一例としては、限定されないいくつかの例を挙げれば、人、アバタ、動物などである。キャラクタは、数字、幾何学又は数学的な表現のような他の非視覚的表現も持つことがある。キャラクタは、キャラクタが装備する武器、又はキャラクタが着る衣服などの一つ以上のオブジェクトと関連することがある。キャラクタデータ４６は、ゲーム画面のフレームにおけるグラフィカルな表現、又は数字、幾何学又は数字の表現のような、キャラクタの現在表現についてのデータを格納する。キャラクタデータ４６は、画像データ、位置データ、材料／テクスチャデータ、物理状態データ、可視性データ、照明データ（例えば、方向、位置、色及び／又は強度）、サウンドデータ、モーションデータ、衝突データ、環境データ、タイマーデータ及び／又は該キャラクタに関連する他のデータなどの属性データも格納することができる。

ゲームデータ３４は、オブジェクトデータ４２、レベルデータ４４及び／又はキャラクタデータ４６の表現及び／又は属性の一部である、ディスプレィ装置５に表示される際のゲームの現在の視野又はカメラアングルに関するデータ（例えば、１人称視点、３人称視点など）を含む。

ゲームプログラム３３を実行する際には、処理装置１０は、プレイヤ７がゲームを選択／スタートした後に、イニシャライズ段階を行い、ゲームをイニシャライズする。イニシャライズ段階は、必要なゲームのセットアップを実行し、ゲームの開始に際してゲームデータ３４を準備するために使用される。ゲームデータ３４は、ゲームプログラム３３の処理に伴って変化（即ち、ゲームのプレイ中）する。ここで“ゲームの状態”という用語は、ここではゲームデータ３４の現在の状態又は性質、従って、多様なオブジェクトデータ４２、レベルデータ４４及び／又はキャラクタデータ４６及びそれらの対応する表現及び／又は属性を定義するために使用される。

イニシャライズ段階の後、ゲームプログラム３３を実行する処理装置１０は、一つ以上のゲームループを実行する。一つ以上のゲームループは、ゲームプレイ中継続的に実行され、ゲームデータ処理機能２２及びゲームレンダリング処理機能２４はルーチン的に実行されるようになる。

ゲームループは、（ｉ）ゲームデータ処理機能２２がゲームコントローラ３を介したプレイヤの入力処理を行ってゲーム状態をアップデートする際に実行され、その後、（ｉｉ）ゲームレンダリング処理機能２４がアップデートされたゲーム状態に基づいてディスプレィ装置５に表示すべきゲーム画像を生成するように機能する。ゲームループは時間経過を追跡し、ゲームプレイの進行を制御する。プレイヤが入力する以外のパラメータが、ゲーム状態に影響を与える点は注目すべき点である。例えば、多様なタイマー（即ち、経過時間、特定のイベントからの時間、一日のバーチャル時間など）がゲーム状態に影響を与え得る。別の言い方をすると、ゲームは、プレイヤ７が入力を行わなくても進行しており、従って、プレイヤの入力が無くてもゲーム状態はアップデートされるのである。

一般的に、ゲームデータ処理機能２２が毎秒実行する回数は、ゲーム状態に対する毎秒のアップデート回数を規定し（以後、「アップデート／秒」と称する）、ゲームレンダリング処理機能２４が毎秒実行する回数は、毎秒のゲーム画像のレンダリングを規定する（以後、「フレーム／秒」と称する）。理論的には、ゲームデータ処理機能２２とゲームレンダリング処理機能２４は、毎秒の実行回数が同じと考えられる。特定の非限定的な例として、目標が毎秒２５フレームだとすると、ゲームデータ処理機能２２とゲームレンダリング処理機能２４は、共に４０ｍｓ毎に実行可能な能力（即ち、１ｓ／２５ＦＰＳ）が望ましい。ゲームデータ処理機能２２が実行し、その後にゲームレンダリング処理機能２４が実行する場合、ゲームデータ処理機能２２とゲームレンダリング処理機能２４は共に４０ｍｓのタイムウインド（time window）で実行される必要がある。その時のゲーム状態によって、ゲームデータ処理機能２２及び／又はゲームレンダリング処理機能２４を行う時間は変わり得るものである。もしゲームデータ処理機能２２とゲームレンダリング処理機能２４が共に４０ｍｓ以下で実行されるなら、ゲームデータ処理機能２２とゲームレンダリング処理機能２４の次のサイクルを実行する前にスリープタイマーを使用することが出来る。しかし、ゲームデータ処理機能２２とゲームレンダリング処理機能２４が与えられたサイクルを実行するのに４０ｍｓ以上掛かる場合には、一定のゲームスピードを維持するためにゲーム画像の表示をスキップするのも一つのテクニックである。

目標となる毎秒フレーム数が、２５フレーム／秒以上又は以下の場合（例えば、６０フレーム／秒）もあるが、人間の目がゲーム画像フレームのレンダリングにおいて何らの遅れも感じないように、ゲームデータ処理機能２２とゲームレンダリング処理機能２４は２０から２５回／秒以下とならないように実行されることが望ましい。当然、フレームレートが高くなればなるほど、画像間の時間は短くなり、ゲームループを実行するに必要な処理装置もより高性能となり、ＧＰＵのような特別な処理装置に頼ることとなる。

他の実施例では、ゲームデータ処理機能２２とゲームレンダリング処理機能２４は別々のゲームループで、従って独立した処理で実行されることもある。こうした場合、ゲームレンダリング処理機能２４が実行中の時であっても、ゲームデータ処理機能２２は特別のレート（即ち、特別なアップデート回数／秒）でルーチン実行することが出来、またゲームデータ処理機能２２が実行中の時であっても、ゲームレンダリング処理機能２４は特別のレート（即、特別なフレーム数／秒）でルーチン実行することが出来る。

ゲームデータ処理機能２２とゲームレンダリング処理機能２４をルーチン的に行う処理は、当業者の範囲における多様な技術に基づいて実行され、そうした技術は本明細書において、ゲームデータ処理機能２２とゲームレンダリング処理機能２４がどのように実行されるかの一例として述べられる。

ゲームデータ処理機能２２が実行されると、コントローラ３を介したプレイヤ入力（もし有れば）及びゲームデータ３４が処理される。特に、プレイヤ７がビデオゲームをプレイする際には、プレイヤ７は、いくつかの例を挙げるが、左に移動せよ、右に移動せよ、ジャンプせよ、撃て、などの多様なコマンドをゲームコントローラ３を介して入力する。プレイヤが入力すると、ゲームデータ処理機能２２はゲームデータ３４をアップデートする。別の言い方をすると、オブジェクトデータ４２、レベルデータ４４及び／又はキャラクタデータ４６がゲームコントローラ３を介したプレイヤの入力に反応してアップデートされる。なおゲームデータ処理機能２２が実行するたびにゲームコントローラ３を介したプレイヤ入力がある訳では無い。プレイヤ入力が入力されなくても、ゲームデータ３４は処理され、アップデートされる。こうしたゲームデータ３４のアップデートは、表現及び／又は属性がゲームデータ３４に対するアップデートを規定しているとき、オブジェクトデータ４２、レベルデータ４４及び／又はキャラクタデータ４６の表現及び／又は属性に応じて行われる。例えば、タイマーデータは一つ以上のタイマー（例えば、経過時間、特定のイベントからの経過時間、一日のバーチャル時間など）を規定し、それらはゲームデータ３４（例えば、オブジェクトデータ４２、レベルデータ４４及び／又はキャラクタデータ４６）のアップデートを生じさせる。他の例として、プレイヤ７によって制御されないオブジェクトが衝突すると（跳ね返ったり、合流したり、砕けたりなど）、ゲームデータ３４、例えばオブジェクトデータ４２、レベルデータ４４及び／又はキャラクタデータ４６は衝突によりアップデートされる。

一般的に、ゲームデータ３４（例えば、オブジェクト、レベル及び／又はキャラクタの表現及び／又は属性）はゲームの３次元（３Ｄ）グラフィック画像を規定するデータを表す。一つ以上の３Ｄグラフィックオブジェクトを含む３次元（３Ｄ）グラフィック画像を、ディスプレィ装置５に表示する２次元（２Ｄ）のラスタライズされたゲーム画像に変換する処理は、一般的にレンダリングと呼ばれる。図４に、３Ｄグラフィックシーンをディスプレィ装置５にスクリーンを介して表示するためのゲーム画像に変換する例を示す。ステップ５２で、ゲームデータ処理機能２２は、ゲームの３次元（３Ｄ）グラフィックシーンを表現するデータを処理して、ワンセットのバーテックスデータ（バーテックス仕様として知られている）に変換する。バーテックスデータはレンダリングパイプライン５５（グラフィックパイプラインとしても知られている）により処理するのに適している。ステップ５５では、ゲームレンダリング処理機能２４がレンダリングパイプライン５５によりバーテックスデータを処理する。レンダリングパイプライン５５の出力は、スクリーンを介してディスプレィ装置５に表示する一般的なピクセルである（ステップ６０）。

より詳細に述べると、ステップ５２で、グラフィックシーンの３Ｄグラフィックオブジェクトは、一つ以上の３Ｄグラフィック要素に細分化される。要素は、レンダリングのための幾何学的な存在（例えば、点、線、ポリゴン、表面、オブジェクト、パッチなど）を規定するために互いにグループ化され接続された一つ以上のバーテックスのグループである。各３Ｄグラフィック要素毎に、バーテックスデータがこの段階で生成される。各要素のバーテックスデータは一つ以上の属性（例えば、位置、色、法線又はテクスチャ座標系情報など）を含むものである。バーテックスデータを引き出す際に、カメラ変換（a camera transformation）（例えば、回転変換）が行われ、３Ｄグラフィックシーンの３Ｄグラフィックオブジェクトを、現在の視点又はカメラアングルに変換する。また、バーテックスデータを引き出す際に、光源データ（例えば、方向、位置、色及び／又は強度）が考慮される。この段階で引き出されたバーテックスデータは、一般的にレンダリングパイプライン５５に送られるバーテックスの順序付きリストである。順序付きリストのフォーマットは一般的にレンダリングパイプライン５５の具体的な実行に依存する。

ステップ５５で、ゲームレンダリング処理機能２４はバーテックスデータをレンダリングパイプライン５５により処理する。レンダリングパイプラインはよく知られており（例えば、OpenGl、DirectXなど）、レンダリングパイプライン５５の実行に用いられる特定のレンダリングパイプラインに拘わらず、レンダリングパイプライン５５の一般的な処理は、３Ｄシーンの２Ｄラスタ表現（例えば、ピクセル）を生成することである。レンダリングパイプライン５５は、一般的に、バーテックスデータの２次元（２Ｄ）スクリーン空間への投影位置を計算し、ディスプレィ５に出力するためのゲーム画像（例えば、ピクセル）を引き出すために、光、色、位置情報、テクスチャ座標を考慮に入れた多様な処理及び／又は他の適当な処理を行なう（ステップ６０）。

ある場合には、ゲーム装置１はインターネットのサーバーと一つ以上のインターネット設備の間に配置される。従って、複数のプレイヤが同じオンラインゲームに参加することが出来、ゲームプログラムの機能（ゲームレンダリング機能及び／又はゲームデータ処理機能）は、少なくとも一部をサーバーにより実行することも可能である。

図６に示す様に、ゲーム装置１はコンピュータシステム（ゲームコンソール又はＰＣのような）であり、入出力モジュール１５（又はユーザインターフェース）はゲームコントローラ３及びディスプレィ装置５を介してプレイヤ７と対話するためのプレイヤインターフェースを実行することができる。コンピュータ可読メモリ１１はゲームデータ３４及びプログラム指示（コード）を格納している。処理装置１０はコンピュータ可読メモリ１１内に格納された、オペレーティングシステム及びゲームプログラム３３を含んだプログラム指示を実行する。ゲームプログラム３３を実行する際には、処理装置１０は、オブジェクト、キャラクタ及びレベルと共に（シミュレートされた）ゲーム環境を維持する。キャラクタには、メインとなる「プレイング」キャラクタ（プレイヤにより制御される）及び、適切な場合、一人以上のノンプレイングキャラクタ（ＮＰＣ）が含まれる。

ゲームプログラム３３を実行する際に、処理装置１０はゲーム環境内のキャラクタの動きを検知し、及び／又はモニターし、及び／又は制御し、あるキャラクタがいわゆる「カバーモード」になっているか否かをも検知する。プレイヤ７により制御されるププレイングキャラクタに関しては、カバーモードはプレイヤ７によりはっきりと入ることが出来るか、又は該キャラクタが自分が殆ど「テークカバー（隠れる、避難する）」となるオブジェクトになりつつあることが分かることで自動的に入ることが出来る。プレイングキャラクタ又はノンプレイングキャラクタの場合、ゲームプログラム３３は、処理装置１０で実行することで該処理装置１０にカバーモードのＮＰＣを何時配置するかについての決定を行なわせる人工知能（ＡＩ）ルーチン又はサブプログラムを有する。

あるキャラクタがカバーモードに入っているか否かの表示はコンピュータ可読メモリ１１内に、図８に示す様に格納されている。そこでは、アバタ２という名のキャラクタがカバーモードにあり、アバタ１及びアバタ３という名のキャラクタはカバーモードではなく、ノーマルモードであることがわかる。「ノーマルモード」は、キャラクタのモードがカバーモードでないことを言うときに使用されるが、「ノーマル」及び「カバー」以外の他のモードであってもよい。本記述の目的から、キャラクタがプレイングキャラクタでるかノンプレイングキャラクタでるかは問題では無い。

あるキャラクタが（例えば、プレイヤ入力又は他の要素に基づいて）ある方向に移動しようとしているとき、キャラクタの位置が結果的に何処に変わるかは、該キャラクタがカバーモードにあるか否かによる。もし、キャラクタがカバーモードにあった場合、該キャラクタの動きは「カバーパス」を追う形に制限される。このためにゲームプログラム３３を実行する際には、処理装置１０はメモリ１１内のカバーパスを調べ、キャラクタがカバーモードにある内は、該キャラクタの位置をカバーパスに沿った位置に留めるようにする。キャラクタがカバーモードに無い場合には、キャラクタの移動／移動方向の制約はより少なくなる。図１１に示す様に、カバーパスを定義するパラメータセット（例えば、カバーパスのパラメータ定義）がカバーモードにあるキャラクタ（この場合、アバタ２）と関連してメモリ１１に格納されており、またカバーモードに無いキャラクタ（この場合アバタ１とアバタ３）にも関連して潜在的に格納されている。

本発明の実施例では、適切に言うと、一連の直線ばかりからなるカバーパスではなく、曲線に沿って方向を円滑に変化させてゆくカバーパスを計算することに関わることである。カバーパスの計算は、図６及び後に詳細に説明する図５に示す様に、ゲームプログラム３３のカバーパス演算サブ処理５００の部分として実行される。

従って、図５に、限定されない実施例によるカバーパス演算サブ処理５００のステップ５１０〜５７０を示す。カバーパス演算サブ処理５００は、キャラクタ毎に実行され、多様な方法で、開始される。例えば、カバーパス演算サブ処理５００は、キャラクタがカバーモードに入ることを見込んで、カバーパスを継続的に自動計算するように設定されている。また、カバーパス演算サブ処理５００は、ゲームプログラム３３からのコマンドにのみ応答して開始されるようにすることも出来、その場合、ゲームプログラム３３の結果として、キャラクタがカバーモードに入ることが決定され、またゲーム環境内のオブジェクトの動きに対応するアップデートを経て、従って、当該キャラクタについて前もって演算されたカバーパスを潜在的に変更する形で開始されるようにすることも出来る。カバーパスが演算されるキャラクタはメイン（プレイヤ）キャラクタ又はノンプレイングキャラクタ（ＮＰＣ）である。即ち、メインキャラクタ及びＮＰＣはそれぞれカバーモードに入ることができ、本発明の実施例は、両方のシナリオに適用することが出来る。

カバーパス演算サブ処理５００のステップ５１０を実行すると、処理装置１０は、キャラクタに関連するカバーセグメント、即ち、キャラクタがテークカバー（隠れる、避難する）に使用する、カメラ視野内にある近接オブジェクトの線状セグメントを特定する。カバーセグメントは、ある敵や敵対的なイベントからキャラクタを守るオブジェクトの近傍の領域に関わるものである。多様なオブジェクトに対するセグメントがゲームエディタ内で前もって作成されており、それらはこの目的のフック又はマーカーであったり、ゲーム環境のメタデータの一部を形成するものであったりする。カバーセグメントは、ゲーム環境内の、静的なオブジェクトのセグメントであったり、又は動的なオブジェクトのセグメントであったりする。静的なオブジェクトの例としては、壁、フェンス、建物などがいくつかの非限定的な例として挙げることが出来る。こうしたオブジェクトについては、ゲーム環境内での位置が変わることが無く、カバーセグメントは、ゲーム環境のレベル内で、静的な位置に定義された線状セグメントである。一方、動的なオブジェクトの例としては、車両、家具、箱などがある。こうしたオブジェクトについては、カバーセグメントはこれらのオブジェクトに関連したオブジェクトデータ４２に含まれており、ゲーム環境内で他数回インスタンス生成される。例えば、動的なオブジェクトが動き、または動かされ（例えば、物理的又はゲームプレイにより）ると、当該オブジェクトのカバーセグメントも動く。

実施例では、カバーパス演算サブ処理５００のステップ５１０を実行すると、処理装置１０はメモリ１１を参照して、（ａ）対象となったキャラクタの近傍の一つ以上のオブジェクトを決定し、（ｂ）それらのオブジェクトに関連したカバーセグメントを特定する。このために、図９に示す様に、メモリ１１は、キャラクタとそれぞれのキャラクタの近傍のゼロ個以上のオブジェクトとの間の関連を格納しており、また図１０に示す様に、メモリ１１は、オブジェクトと、ゼロ個以上のカバーセグメント間の関連もオブジェクト毎に格納している。

もし、オブジェクトが高さを持っている場合には、関連するカバーセグメントはグランドに投影されるが、カバーセグメントは地形又は床のスロープに追随することができる。カバーセグメントはナビゲーションメッシュの境界に関連付けることが出来るが、閉曲面を形成するために相互接続する必要は無い。奇妙な形状のオブジェクトに、方向を変えてオブジェクトの形状を近似する、多数の接続された直線状のカバーセグメントが関連付けられる。

カメラで見ることの出来るオブジェクトに対応した多数のカバーセグメントが存在し、これらの内、ごく僅かがカバーパス演算サブ処理５００のステップ５１０で識別される。特に、どのカバーセグメントがステップ５１０で識別されるかに関する決定は、ゲームプログラムの人工知能又はゲームプレイのルール次第であり、距離、アライメント、障害物の無いパスなどの基準を元にしたプレイヤの意図を予測する。

実施例では、カバーパス演算サブ処理５００のステップ５２０を実行する際に、処理装置１０はステップ５１０で識別された多様なカバーセグメントのあるものを、問題のキャラクタに対する「ギザギザなカバーパス」を生成するものとして保持する。隣接するカバーセグメントはゲーム環境内の同じオブジェクト又は異なるオブジェクトに属している。それらが異なるオブジェクトに属している場合は、接続されていないカバーセグメントを、それにも拘わらず隣接しているものと考えることが出来る。例えば、互いの近くにある複数のオブジェクトは、最も近い端部が互いにある閾距離内にあるカバーセグメントを有しており、これらのカバーセグメントは、接続されてはいないが、ギザギザなカバーパスの「近接したカバーセグメント」と考えることが出来る。閾距離は、例えば１５ｃｍ、１ｍ等であり、ゲーム世界のスケールに依存する。また、ある実施例では、閾距離はピクセルで計測することも可能である（例えば、５０ピクセル、２０ピクセル、５ピクセル等）。この段階では、従って、ギザギザなカバーパスは近接したカバーセグメントの連鎖として表され、それらはある場合には、緩やかな／バラバラの連鎖である。例えば、図７Ａには、ステップ５２０のおかげで、ギザギザなカバーパスを形成する複数のカバーセグメント７１０〜７５０が示されている。この非限定的な実施例では、カバーセグメント７１０，７２０はオブジェクトＡと関連しており、カバーセグメント７３０はオブジェクトＢと関連しており、カバーセグメント７４０及び７５０はオブジェクトＣと関連している。

カバーパス演算サブ処理５００は、セグメントが互いの線形の延長と見なしうる限りでは、多数の近接したカバーセグメントを単一直線セグメントと見なしている。例えば、実質的に共線的な近接したカバーセグメント（例えば、セグメントを延長して、それらが交わるとき、閾角度以下で交差したり、またそれらが平行であれば、セグメント間の最小距離が閾距離よりも小さかったり）及びそれらの先端が距離的に近いカバーセグメント（例えば、ある閾距離以内）は単一の延長されたカバーセグメントの一部と見なすことが出来る。また、垂直方向の傾斜の変化は、二つの傾斜領域のグランドへの投影が互いの線的な延長である限り、カバーセグメントを分割しない（例えば、壁と同じナビゲーションメッシュに沿った隣接する階段又はエスカレータと、関連したカバーセグメントは、単一で、共通のカバーセグメントの一部と見なすことが出来る）

実施例では、カバーパス演算サブ処理５００のステップ５３０を実行する際に、処理装置１０はステップ５２０で結合されたセグメントの（潜在的にばらばらの）連鎖を分析してギザギザなカバーパスを形成し、曲線化する候補であるギザギザなカバーパスの部分を決定しようとする。例えば、ギザギザなカバーパスの二つの近接するカバーセグメントが曲線候補と見なされるための基準は、それらが十分に整合されているかであり、例えば、それらが４５度以下、又は３０度以下、又は１０度又は５度以下の角度を形成していることなどである。逆に、閾角度よりも大きな角度で交わる（又は、延長して交わる）ギザギザなカバーパスの近接したカバーセグメントは、曲線化部分に変換されることはなく、それらの大きな交差角度から、描画された画像に曲線が無くなることが予想される。今日の技術の観点から曲線化候補を選択する方法は、当業者にとっていくつかしかない。

実施例では、カバーパス演算サブ処理５００のステップ５４０を実行する際に、処理装置１０はステップ５３０で決定されたギザギザなカバーパスの部分に沿った制御ポイントのセットを選択する。非限定的な実施例では、４個の制御ポイントを、曲線部分へ変換する予定の各カバーセグメントについて使用する。他の非限定的な実施例では、いくつかの制御ポイントを曲線化すべき各カバーセグメントについて用いること出来、各カバーセグメントは曲線化すべき他のカバーセグメントに隣接している。また異なる（例えば、より少ない）数の制御ポイントを曲線化すべきカバーセグメントについて使用することが出来るが、該カバーセグメントは曲線化すべきでないカバーセグメントと隣接するカバーセグメントである。カバーセグメントに沿った制御ポイントの位置は、隣接するカバーセグメントに基づいて計算することが出来、カバーセグメントが最も近い位置での接線と位置を用いて、近接するカバーセグメント間の連続性を保証する。他の実施例では、カバーセグメントに対する制御ポイントはカバーセグメントそのものの上にある必要は無く、カバーセグメントから僅かにオフセットしていてもよい。ある実施例では、カバーセグメントと一致するよりむしろ、制御ポイントは曲線化すべき二つの隣接するカバーセグメント間のギャップに位置することも出来る。図７Ｂに示すように、制御ポイント７６０は曲線化すべきギザギザなカバーパスの各セグメント７２０，７３０及び７４０上に示されており、セグメント７３０及び７４０間のギャップに位置する一つの制御ポイントが例外である。

カバーパスの部分に関して言及する際に、「曲線化」の言葉は、該部分が連続して形成され、一つ以上が可変に形成された場合、一次導関数は、一定で無い連続関数であることを意味する。あるいは、導き出された基本的なカバーセグメントのグループを一つにする線図よりも、カバーパスの部分がより滑らか（例えば、その一次導関数においてより小さな局所分散をもつ）であることを意味する。

実施例では、カバーパス演算サブ処理５００のステップ５５０を実行する際に、処理装置１０は、ステップ５４０で選択された制御ポイント７６０を通る、２−Ｄ又は３−Ｄの滑らかな曲がった表面を生成する。この目的のために、一つ以上のスプラインが演算される。スプラインを演算するために、一つの選択は、求心的（centripetal）なCatmull-Romアルゴリズムを適用することである（例えば、P. J. Barry and R. N. Goldman: A recursive evaluation algorithm for a class of Catmull–Rom splines. SIGGRAPH Computer Graphics, 22(4):199-204, 1988,参照、ここで参照することで明細書に導入される）。このタイプのスプラインはある種の利点を有しており、例えば、連続性を維持し、曲線内でのループ化を防止しつつ、その制御ポイントのそれぞれを通過するように制限することが出来る。隣接するセグメントを横断する円滑なCatmull-Romスプラインを生成するために、セグメントの二つの最も左の制御ポイントを右手に、二つの最も右の制御ポイントを左手に考える。これを図７Ｃに示すが、ここでスプライン７７０はセグメント７２０の二つの制御ポイント及びセグメント７３０の二つの制御ポイントから演算される。また、スプライン７８０は、セグメント７３０の二つの制御ポイント及びセグメント７４０の二つの制御ポイントから演算される。この目的のために、セグメント７３０は二つの異なるスプラインで使用する４個の制御ポイントを有し、真ん中の制御ポイント間の領域は直線セグメントを残している。スプラインは、一つ以上が互いに連結されており、Catmull-Romスプラインであるが、これにかぎらない。本発明の範囲を逸脱しない限り、スプライン又は他の曲線化パスを生成する技術を使用することが出来る。例えば、異なる数の制御ポイントを使用し、Hermite曲線やspherical blendのようなスプラインの異なるタイプを使用することも出来る。

実施例において、カバーパス演算サブ処理５００のステップ５６０を実行する際に、処理装置１０はステップ５３０で決定されたギザギザなカバーパスの部分をステップ５５０で決定された対応する曲線化された部分と置き換え、これによりキャラクタのための最終的なカバーパスを生成する。最終的なカバーパスは曲線化された部分と非曲線化部分を含むものである。図７Ｃの例では、最終的なカバーパスは、もともと閾角以下で整合していたカバーセグメントだった場所で、一つ以上の曲線化された部分（例えば、スプライン７７０又はその一部分）を含み、大きすぎた角度で曲線化されなかった隣接するカバーセグメントも含む。最終的なカバーパスは、キャラクタがカバーモードにあってキャラクタの動きがそれに沿って制限さるパスであり、ゲームプログラム３３の他の観点によって使用され得る。図１１は、図８の延長であり、各キャラクタと対応する最終的なカバーパスの間の関連の一例を示すものであり、メモリ１１に格納されている。

実施例において、カバーパス演算サブ処理５００のステップ５７０を実行する際に、処理装置１０はメモリ１１にキャラクタの最終的なカバーパスを格納する。これは最終的なカバーパスのパラメータ（例えば、多項式係数）又はその３−Ｄ空間内の実際の位置座標を格納することで行われるが、メモリ、正確性及び処理要求による。カバーパスは、キャラクタが実際にカバーモードに無くても、当該キャラクタについて演算される。キャラクタ周辺のキャラクタ及び／又はオブジェクトの動きによって、最終的なカバーパスは繰り返し演算される。

キャラクタは曲線化されたカバーパスを規定するために用いられた基礎となる線状のセグメントに対してある速度をもって移動する。線状のセグメントに沿った割合は、Catmull-Romアルゴリズムを用いて、曲線化されたカバーパス上で予想される。

こうして、図１２に示す様に、上記した記述に加えて本発明の実施例は、処理装置１０により裏付けられるものとしてのゲーム世界内でプレイング又はノンプレイングキャラクタの動きを制御するための処理又は方法１２００を含むものである。該処理又は方法は、キャラクタがカバーモードにあるか否かを決定すること（ステップ１２１０）；該キャラクタがカバーモードにあると決定した場合（ステップ１２１５）；コンピュータ可読メモリ１１を検索し、該キャラクタについての曲線化されたカバーパスを特定し（ステップ１２２０）、曲線化されたカバーパスに沿って該キャラクタの動きを制限する（ステップ１２３０）ことを含む。これはキャラクタがカバーモードにある時に実行され、それでなければこの処理は終了し、キャラクタ動きの制御は曲線化されたカバーパスに制約されない通常のモードに戻る。

図１３に示す様に、上記した記述に加えて本発明の実施例は、処理装置１０により裏付けられるものとしてのゲーム世界内でプレイング又はノンプレイングキャラクタの動きを制御するための処理又は方法１２００を含むものである。該処理又は方法は以下のステップを含む。キャラクタの近傍のオブジェクトを特定し（ステップ１３１０）；該オブジェクトと関連するカバーセグメントのセットを決定し（ステップ１３２０）；該キャラクタがカバーモードに無い場合、ナビゲーションメッシュ内のユーザ定義の軌跡に沿ってキャラクタを移動させることを許可し（ステップ１３３０）；キャラクタがカバーモードにあり、かつオブジェクト近傍にいる場合、キャラクタの動きをカバーパスに制限する。カバーセグメントは線状であり、カバーパスは曲線化されている（ステップ１３４０）。

述べられた実施例の改造や変形は可能である。従って、上記した実施例は例示的であり、限定的なものでは無い。本発明のある実施例を行うに必要な追加的な素子は述べられていないし、示されてもいないが、それらは当業者の知見の範囲である。また、実行する際において、ここで議論した実施例の何らかの特徴は、ここで議論した他の実施例の何らかの特徴と組合せことが出来る。更に、本発明のある実施例は、ここで特に開示されていない素子が無くてもよく、また機能することが出来、問題ないものである。

Claims (36)

1. コンピュータシステムであって、該コンピュータシステムは、
   − データ及びプログラム指示を格納したメモリ、該データはキャラクタ及び複数のカバーセグメントを含むゲーム環境を表わすものであり、
   − プレイヤインターフェース、
   − 前記メモリに格納されたプログラム指示を実行する様に構成された処理装置であって、前記プログラム指示を実行すると、前記コンピュータシステムは以下のステップからなる方法を実行する；
   〇 前記カバーセグメントの選択された部分集合を決定する、
   〇 前記カバーセグメントの選択された部分集合に関連する制御ポイントを通過する曲線化されたパスを決定する、
   〇 プレイヤインターフェースを介してディスプレィ用の画像をレンダリングする；前記画像は、前記キャラクタがカバーモードにあるとき、前記曲線化されたパスに沿った該キャラクタの移動を示す。
2. 請求項１記載のコンピュータシステムであって、前記コンピュータシステムによる実行される方法は、更に、前記キャラクタに関連してメモリ内に前記曲線化されたパスを格納するステップを含む。
3. 請求項１又は２記載のコンピュータシステムであって、前記コンピュータシステムによる実行される方法は、更に、前記選択された部分集合内の一つ以上のカバーセグメント上にある少なくともいくつかの制御ポイントを選択するステップを含む。
4. 請求項１又は２又は３記載のコンピュータシステムであって、前記コンピュータシステムによる実行される方法は、更に、前記選択された部分集合内の近接したカバーセグメント間のギャップ内にある少なくともいくつかの制御ポイントを選択するステップを含む。
5. 請求項１乃至４のうち、何れか１項記載のコンピュータシステムであって、前記制御ポイントのセットを通過する曲線化されたパスを決定することは、前記制御ポイントを通過する求心的（centripetal）なCatmull-Romスプラインのパラメータを決定することを含む。
6. 請求項５記載のコンピュータシステムであって、前記制御ポイントは前記選択された部分集合内の少なくとも二つの近接したカバーセグメント間に架かることを特徴とする。
7. 請求項１乃至６のうち、何れか１項記載のコンピュータシステムであって、前記データは更に、カバーモードになることが出来るキャラクタに関連しており、該キャラクタは、該キャラクタがカバーモードにあるとき、前記プレイヤインターフェースを介して受け取ったキャラクタを移動させるコマンドに反応して、前記ゲーム環境内で前記曲線化されたパスに沿って移動させられることを特徴とする。
8. 請求項７記載のコンピュータシステムであって、前記方法は、更に、カバーモードにある前記キャラクタに関連する曲線化されたパスをメモリ内に格納することを含む。
9. 請求項７記載のコンピュータシステムであって、各カバーセグメントは前記ゲーム環境内のオブジェクトに関連しており、前記キャラクタが前記ゲーム環境内で戦闘から避難することの出来るオブジェクトの近傍の領域を示すことを特徴とする。
10. 請求項９記載のコンピュータシステムであって、前記オブジェクトは前記ゲーム環境内の静的なオブジェクトであることを特徴とする。
11. 請求項９記載のコンピュータシステムであって、前記オブジェクトは前記ゲーム環境内の動的なオブジェクトであることを特徴とする。
12. 請求項７記載のコンピュータシステムであって、前記コンピュータシステムによる実行される方法は、更に、前記カバーモードにあるキャラクタに関連する曲線化されたパスのパラメータ定義を前記メモリ内に格納するステップを含む。
13. 請求項８記載のコンピュータシステムであって、前記処理装置は検出と格納を自律的に行うことを特徴とする。
14. 請求項８記載のコンピュータシステムであって、前記処理装置は、前記キャラクタをカバーモードに入れるユーザコマンドを検出すると、検出と格納を実行することを特徴とする。
15. 請求項８記載のコンピュータシステムであって、前記処理装置は、前記キャラクタがカバーモードに入るゲーム状態を検出すると、検出と格納を実行することを特徴とする。
16. 請求項１乃至１５のうち、何れか１項記載のコンピュータシステムであって、前記カバーセグメントの選択された部分集合を決定する場合、前記処理装置は前記ゲーム環境内の前記キャラクタ近傍の少なくとも一つオブジェクト及び該少なくとも一つのオブジェクトに関連する複数の線形セグメントを検出するように構成されており、前記カバーセグメントの選択された部分集合は、該少なくとも一つのオブジェクトから決定される。
17. 請求項１乃至１６のうち、何れか１項記載のコンピュータシステムであって、前記選択された部分集合内のカバーセグメントは、前記ゲーム環境内のキャラクタに近接した一つ以上のオブジェクトに関連したカバーセグメントを含むことを特徴とする。
18. 請求項１７記載のコンピュータシステムであって、少なくとも一つの前記オブジェクトは前記ゲーム環境内の静的なオブジェクトであることを特徴とする。
19. 請求項１７記載のコンピュータシステムであって、少なくとも一つの前記オブジェクトは前記ゲーム環境内の動的なオブジェクトであることを特徴とする。
20. 請求項１乃至１９のうち、何れか１項記載のコンピュータシステムであって、前記カバーセグメントの選択された部分集合を決定することは、前記ゲーム世界内の閾距離内で近接した端部を持ったカバーセグメントの部分集合を決定することである。
21. 請求項２０記載のコンピュータシステムであって、前記閾距離は、１ｍより大きくなく、その中で閾角度は４５度より大きくないことを特徴とする。
22. 請求項１乃至２１のうち、何れか１項記載のコンピュータシステムであって、前記カバーセグメントの選択された部分集合を決定することは、閾数以下のピクセルによって分かれている端部を持ったカバーセグメントの部分集合を決定することである。
23. 請求項１乃至２２のうち、何れか１項記載のコンピュータシステムであって、前記カバーセグメントの選択された部分集合を決定することは、延長した際に、閾角度より大きくない角度で交差するカバーセグメントの部分集合を決定することである。
24. ゲーム装置の処理装置によって実行されるゲームプログラムにより生成されるゲーム環境内のキャラクタの動きを制御する方法であって、前記ゲーム環境はオブジェクト、該オブジェクトに関連するカバーセグメントを含み、
    前記処理装置は、以下のステップを実行する；
    − 前記カバーセグメントの選択された部分集合を決定する、
    − 前記カバーセグメントの選択された部分集合に関連する制御ポイントを通過する曲線化されたパスを決定する、
    − プレイヤインターフェースを介してディスプレィ用の画像をレンダリングする；前記画像は、前記キャラクタがカバーモードにあるとき、前記曲線化されたパスに沿った該キャラクタの移動を示す。
25. コンピュータ可読指示を格納したコンピュータ可読媒体であって、前記コンピュータ可読指示は、ゲーム装置の処理装置によって実行されると、前記ゲーム装置にゲーム環境内のキャラクタの動きを制御する方法を実行させることができ、前記ゲーム環境はオブジェクト、該オブジェクトに関連するカバーセグメントを含み、
    前記方法は以下のステップを有する；
    − 前記カバーセグメントの選択された部分集合を決定する、
    − 前記カバーセグメントの選択された部分集合に関連する制御ポイントを通過する曲線化されたパスを決定する、
    − プレイヤインターフェースを介してディスプレィ用の画像をレンダリングする；前記画像は、前記キャラクタがカバーモードにあるとき、前記曲線化されたパスに沿った該キャラクタの移動を示す。
26. ゲーム装置の処理装置によって実行されるゲームプログラムにより生成されるゲーム環境内のキャラクタの動きを制御する方法であって、
    前記処理装置は、以下のステップを実行する；
    − 前記キャラクタがカバーモードにあることを決定する、
    − 前記キャラクタがカバーモードにあると決定されると、メモリを検索して、該キャラクタについての曲線化されたカバーパスを特定する、該カバーパスは少なくとも一つの曲線化された部分を含む、
    − 前記キャラクタがカバーモードにある間、前記曲線化されたカバーパスに沿ってキャラクタの動きを制限する。
27. 請求項２６記載の方法であって、該方法は、更に、ゲーム装置のユーザからコマンドを受け取ると、前記キャラクタをカバーモードにするステップを有する。
28. 請求項２７記載の方法であって、前記キャラクタはプレイングキャラクタであることを特徴とする。
29. 請求項２６乃至２８のうち、何れか１項記載の方法であって、該方法は、更に、前記ゲームプログラムからのコマンドを受け取ると、前記キャラクタをカバーモードにするステップを有することを特徴とする。
30. 請求項２９記載の方法であって、前記キャラクタはノンプレイングキャラクタであることを特徴とする。
31. 請求項２６乃至３０のうち、何れか１項記載の方法であって、前記曲線化されたカバーパスは２−Ｄ空間内にあることを特徴とする。
32. 請求項２６乃至３１のうち、何れか１項記載の方法であって、前記曲線化されたカバーパスは３−Ｄ空間内にあることを特徴とする。
33. コンピュータ可読指示を格納するコンピュータ可読媒体であって、前記コンピュータ可読指示は、ゲーム装置の処理装置により実行されると、前記ゲーム装置にゲーム環境内のキャラクタの動きを制御する方法を実行させることが出来、
    前記方法は、以下のステップからなる、
    − 前記キャラクタがカバーモードにあることを決定する、
    − 前記キャラクタがカバーモードにあると決定されると、メモリを検索して、該キャラクタについての曲線化されたカバーパスを特定する、該カバーパスは少なくとも一つの曲線化された部分を含む、
    − 前記キャラクタがカバーモードにある間、前記曲線化されたカバーパスに沿ってキャラクタの動きを制限する。
34. コンピュータシステムであって、
    該コンピュータシステムは、
    − データ及びプログラム指示を格納するメモリを有し、該データはキャラクタを含むゲーム環境を表し、
    − プレイヤインターフェース、及び
    − 前記メモリ内に格納された前記プログラム指示を実行するように構成された処理装置を有し、
    前記プログラム指示の実行により、コンピュータは以下のステップからなる方法を実行する、
    〇 前記キャラクタがカバーモードにあることを決定する、
    〇 前記キャラクタがカバーモードにあると決定されると、メモリを検索して、該キャラクタについての曲線化されたカバーパスを特定する、該カバーパスは少なくとも一つの曲線化された部分を含む、
    〇 前記キャラクタがカバーモードにある間、前記曲線化されたカバーパスに沿ってキャラクタの動きを制限する。
35. ゲーム装置の処理装置によって実行されるゲームプログラムにより生成されるゲーム環境内でキャラクタの動きを制御する方法であって、
    前記処理装置は、以下のステップを実行することが出来る；
    − 前記キャラクタ近傍のオブジェクトを特定する、
    − 前記オブジェクトに関連したカバーセグメントのセットを決定する、
    − 前記キャラクタがカバーモードに無いときは、ナビゲーションメッシュ内のユーザ定義軌跡に沿って前記キャラクタを移動させることを許容し、
    − 前記キャラクタがカバーモードにあり、かつオブジェクトの近傍にいる時は、キャラクタの動きをカバーパスに制限する、前記カバーセグメントは線形であり、前記カバーパスは曲線化されている。
36. 請求項３５記載の方法であって、前記オブジェクトに関連するカバーセグメントのセットを決定する際は、前記処理装置は前記オブジェクトに関連するゲームプログラム内のフック(hooks）又はマーカー(markers)を決定するように構成されていることを特徴とする。
    
    
    

Images