(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023011071
(43)【公開日】2023-01-23
(54)【発明の名称】プラン処理プログラムおよびプラン処理システム
(51)【国際特許分類】
A63F 13/55 20140101AFI20230116BHJP
A63F 13/35 20140101ALI20230116BHJP
A63F 13/56 20140101ALI20230116BHJP
【FI】
A63F13/55
A63F13/35
A63F13/56
【審査請求】未請求
【請求項の数】9
【出願形態】OL
(21)【出願番号】P 2021114675
(22)【出願日】2021-07-11
【新規性喪失の例外の表示】特許法第30条第2項適用申請有り 令和3年6月17日にGDC2021のウェブサイト(https://schedule.gdconf.com/session/ai-summit-advanced-real-time-hierarchical-task-networks-a-new-approach/879049)にて公開 令和3年7月2日にCEDEC2021のウェブサイト(https://cedec.cesa.or.jp/2021/session/detail/s6062d4207f1c6)にて公開
(71)【出願人】
【識別番号】308033283
【氏名又は名称】株式会社スクウェア・エニックス
(74)【代理人】
【識別番号】100155402
【弁理士】
【氏名又は名称】松田 真
(72)【発明者】
【氏名】三宅 陽一郎
(72)【発明者】
【氏名】並木 幸介
(72)【発明者】
【氏名】森 寅嘉
(57)【要約】
【課題】階層型タスクネットワークに基づいて、環境の変化に柔軟に対応できるようなプランニングを行う。
【解決手段】キャラクタが実行するタスクを階層型タスクネットワークに基づいてプランニングする、プラン処理プログラムが、サーバに、ゴール情報に基づいて、複数のタスクにより構成されたプランをドメインから生成する、プラン生成機能を実現させ、前記プラン生成機能では、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する機能を実現させる。
【選択図】
図19
【特許請求の範囲】
【請求項1】
キャラクタが実行するタスクを階層型タスクネットワークに基づいてプランニングする、プラン処理プログラムであって、
サーバに、
ゴール情報に基づいて、複数のタスクにより構成されたプランをドメインから生成する、プラン生成機能を実現させ、
前記プラン生成機能では、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する機能を
実現させるためのプラン処理プログラム。
【請求項2】
前記サーバに、
前記プラン生成機能が生成したプランを取得し、前記プランに含まれるタスクを順次実行するプラン実行機能を実現させ、
前記プラン実行機能では、取得した前記プランの一部を変更してから、前記プランに含まれるタスクを順次実行する機能を
実現させるための請求項1に記載のプラン処理プログラム。
【請求項3】
前記サーバに、
前記タスクをより具体的な複数のタスクに分解するタスク分解機能をさらに実現させ、
前記プラン生成機能では、前記タスク分解機能に所定の階層までタスク分解を行わせてから前記プランを生成する機能を実現させ、
前記プラン実行機能では、前記プランに含まれるタスクの少なくとも一部を、前記所定の階層よりも深い階層までタスク分解してから、前記プランに含まれるタスクを順次実行する機能を
実現させるための請求項2に記載のプラン処理プログラム。
【請求項4】
前記プラン生成機能では、前記ドメインに含まれる複数の選択可能なタスクをシミュレータにより仮実行して評価値を計算し、前記ゴール情報と前記評価値とに基づいて前記プランを生成する機能を
実現させるための請求項1から請求項3のうちいずれか一項に記載のプラン処理プログラム。
【請求項5】
前記プランは、前記キャラクタがタスクを実行し得る空間に対応する第1の空間情報を用いて前記タスクを実行するものであり、
前記シミュレータは、前記空間に対応する第2の空間情報を用いて前記選択可能なタスクを仮実行するものであり、
前記第2の空間情報は、前記第1の空間情報よりも情報量が少ない、
請求項4に記載のプラン処理プログラム。
【請求項6】
前記プラン生成機能では、前記ゴール情報と、前記キャラクタ以外のオブジェクトのタスク実行、アクションまたは状態変化とに基づいて、前記プランを前記ドメインから生成する機能を
実現させるための請求項1から請求項5のうちいずれか一項に記載のプラン処理プログラム。
【請求項7】
前記プラン生成機能では、複数のタスクにより構成される部分的プランに含まれる一以上の代表タスクについての代表評価値を算出し、前記代表タスクについての評価が高くなるような部分的プランについての評価値を算出する機能を
実現させるための請求項1から請求項6のうちいずれか一項に記載のプラン処理プログラム。
【請求項8】
通信ネットワークと、サーバと、ユーザ端末とを備え、キャラクタが実行するタスクを階層型タスクネットワークに基づいてプランニングする、プラン処理システムであって、
ゴール情報に基づいて、複数のタスクにより構成されたプランをドメインから生成する、プラン生成手段を含み、
前記プラン生成手段では、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する、
プラン処理システム。
【請求項9】
キャラクタが実行するタスクを階層型タスクネットワークに基づいてプランニングする、プラン処理プログラムであって、
ユーザ端末に、
ゴール情報に基づいて、複数のタスクにより構成されたプランをドメインから生成する、プラン生成機能を実現させ、
前記プラン生成機能では、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する機能を
実現させるためのプラン処理プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明の実施形態の少なくとも一つは、プラン処理プログラムおよびプラン処理システムに関する。
【背景技術】
【0002】
従来、ビデオゲームにおいてキャラクタの移動制御を行うための技術が種々提案されている。
【0003】
特許文献1にはゲームプログラムが記載されている。ゲームプログラムは、コンピュータを、仮想のゲーム空間内において、ゲームプレイヤが操作しないノンプレイヤキャラクタの移動開始位置と該ノンプレイヤキャラクタの移動の目標位置とから、探索領域においてノンプレイヤキャラクタが経由可能な経由候補位置の配置を決定する決定手段として機能させる。ゲームプログラムは、コンピュータを、決定手段によって配置を決定した経由候補位置に基づき、移動開始位置から目標位置までの経路を選択する経路選択手段として機能させる。ゲームプログラムは、コンピュータを、経路選択手段によって選択された経路にしたがって、ノンプレイヤキャラクタを目標位置に移動させるキャラクタ制御手段として機能させる。決定手段は、記憶部から仮想ゲーム空間に対応した複数の経由候補位置の情報である探索経路情報を読み出し、この探索経路情報に基づいて、探索領域の所定範囲に配される経由候補位置の間隔よりも、所定範囲外に配される経由候補位置の間隔の方が大きくなるように、探索領域の経由候補位置の配置を決定する。
【先行技術文献】
【特許文献】
【0004】
【発明の概要】
【発明が解決しようとする課題】
【0005】
ところで、ビデオゲームにおいてキャラクタに実行させるべきタスクを自動で決定してキャラクタの制御を行う方法として、階層型タスクネットワーク(Hierarchical Task Network、略称HTN)を用いることが行われてきた。階層型タスクネットワークは、所定の条件下において実行され得るタスクの集合をドメインとして保持し、その時点でのワールドステートの状況を把握して、ワールドステートの状況に応じたタスクを適切な実行順序で実行させるようにプランを決定することができる。
【0006】
例えばゲームなどにおいて、プランの生成時とプランの実行時との間に環境が変化することがある。例えば、制御対象となるキャラクタが敵キャラクタに対して遠距離攻撃を行うための一連のタスクを実行している途中で、敵キャラクタが射程距離外に退避した場合、制御対象キャラクタは遠距離攻撃を行うタスクを続けて実行することができなくなる。プランが生成された後に環境が変化すると、既存の階層型タスクネットワークに基づくプランニングでは、生成済みのプランをうまく環境変化に適応させる手段がないため、プランの再生成(リプランニング)が発生していた。このリプランニングが頻繁に行われると、制御対象となるキャラクタから長期的な一貫性が失われる可能性がある。
【0007】
本発明の少なくとも一つの実施形態の目的は、上記課題を解決し、階層型タスクネットワークに基づいて、環境の変化に柔軟に対応できるようなプランニングを実現させることである。
【課題を解決するための手段】
【0008】
非限定的な観点によると、本発明の一実施形態に係るプラン処理プログラムは、キャラクタが実行するタスクを階層型タスクネットワークに基づいてプランニングする、プラン処理プログラムであって、サーバに、ゴール情報に基づいて、複数のタスクにより構成されたプランをドメインから生成する、プラン生成機能を実現させ、プラン生成機能では、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する機能を実現させるためのものである。
【0009】
非限定的な観点によると、本発明の一実施形態に係るプラン処理システムは、通信ネットワークと、サーバと、ユーザ端末とを備え、キャラクタが実行するタスクを階層型タスクネットワークに基づいてプランニングする、プラン処理システムであって、ゴール情報に基づいて、複数のタスクにより構成されたプランをドメインから生成する、プラン生成手段を含み、プラン生成手段では、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成するものである。
【0010】
非限定的な観点によると、本発明の一実施形態に係るプラン処理プログラムは、キャラクタが実行するタスクを階層型タスクネットワークに基づいてプランニングする、プラン処理プログラムであって、ユーザ端末に、ゴール情報に基づいて、複数のタスクにより構成されたプランをドメインから生成する、プラン生成機能を実現させ、前記プラン生成機能では、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する機能を実現させるためのものである。
【発明の効果】
【0011】
本願の各実施形態により1または2以上の不足が解決される。
【図面の簡単な説明】
【0012】
【
図1】本発明の実施形態の少なくとも一つに対応するビデオゲーム処理システムの構成の例を示すブロック図である。
【
図2】本発明の実施形態の少なくとも一つに対応するサーバの構成を示すブロック図である。
【
図3】本発明の実施形態の少なくとも一つに対応するプラン処理プログラムの処理例を示すフローチャートである。
【
図4】本発明の実施形態の少なくとも一つに対応するサーバの構成を示すブロック図である。
【
図5】本発明の実施形態の少なくとも一つに対応するプラン処理プログラムの処理例を示すフローチャートである。
【
図6】本発明の実施形態の少なくとも一つに対応するサーバの構成を示すブロック図である。
【
図7】本発明の実施形態の少なくとも一つに対応するプラン処理プログラムの処理例を示すフローチャートである。
【
図8】本発明の実施形態の少なくとも一つに対応するサーバの構成を示すブロック図である。
【
図9】本発明の実施形態の少なくとも一つに対応するプラン処理プログラムの処理例を示すフローチャートである。
【
図10】本発明の実施形態の少なくとも一つに対応するビデオゲーム処理システムの構成の例を示すブロック図である。
【
図11】本発明の実施形態の少なくとも一つに対応するプラン処理システムの構成を示すブロック図である。
【
図12】本発明の実施形態の少なくとも一つに対応するプラン処理の例を示すフローチャートである。
【
図13】本発明の実施形態の少なくとも一つに対応するユーザ端末の構成を示すブロック図である。
【
図14】本発明の実施形態の少なくとも一つに対応するプラン処理の例を示すフローチャートである。
【
図15】本発明の実施形態の少なくとも一つに対応するサーバの構成を示すブロック図である。
【
図16】本発明の実施形態の少なくとも一つに対応するプラン処理プログラムの処理例を示すフローチャートである。
【
図17】本発明の実施形態の少なくとも一つに対応する、階層型タスクネットワークの構成例を示すブロック図である。
【
図18】一般的な階層型タスクネットワークに基づいたプラン生成例を示す概念図である。
【
図19】本発明の実施形態の少なくとも一つに対応する、プラナーが生成するプランを例示する概念図である。
【
図20】本発明の実施形態の少なくとも一つに対応するプラン処理プログラムにおける、階層型タスクネットワークの構造例を示す概念図である。
【
図21】本発明の実施形態の少なくとも一つに対応するプラン処理プログラムにおける、タスクの分解例を示す概念図である。
【
図22】本発明の実施形態の少なくとも一つに対応するプラン処理プログラムにおける、タスクの分解例を示す概念図である。
【
図23】本発明の実施形態の少なくとも一つに対応するプラン処理プログラムにおける、タスクの分解例を示す概念図である。
【
図24】本発明の実施形態の少なくとも一つに対応するプラン処理プログラムにおける、タスクの分解例を示す概念図である。
【
図25】本発明の実施形態の少なくとも一つに対応するプラン処理プログラムにおける、シミュレータを用いたプラン生成を例示する概念図である。
【
図26】本発明の実施形態の少なくとも一つに対応するプラン処理プログラムが用いるシミュレータにおいて、情報量の少ない第2の空間情報によってゲーム空間を表現した場合を例示する概念図である。
【
図27】本発明の実施形態の少なくとも一つに対応する、制御対象キャラクタ以外のオブジェクトのタスク実行、アクションまたは状態変化を考慮したプラン生成例を示す概念図である。
【
図28】本発明の実施形態の少なくとも一つに対応する、プラン生成部が生成するマルチシナリオプランの一例を示す概念図である。
【
図29】本発明の実施形態の少なくとも一つに対応する、プラン生成部によるタスクの展開例を示す概念図である。
【
図30】本発明の実施形態の少なくとも一つに対応する、時間遡行の分岐を追加する例を示す概念図である。
【
図31】本発明の実施形態の少なくとも一つに対応する部分的プランを例示する概念図である。
【
図32】本発明の実施形態の少なくとも一つに対応する、部分タスクに対応する狙撃ポイントの候補を示す概念図である。
【
図33】本発明の実施形態の少なくとも一つに対応する、代表評価値の算定と枝刈りを例示する概念図である。
【
図34】本発明の実施形態の少なくとも一つに対応する、プランの実装例を例示する概念図である。
【
図35】本発明の実施形態の少なくとも一つに対応するプランの実装例における、タスクの割り当て処理を例示する概念図である。
【
図36】本発明の実施形態の少なくとも一つに対応するプランの実装例における、コンポジットタスクの展開を示す概念図である。
【
図37】本発明の実施形態の少なくとも一つに対応するプランの実装例における、タスクの分解を示す概念図である。
【発明を実施するための形態】
【0013】
以下、本発明の実施形態の例について図面を参照して説明する。なお、以下で説明する各実施形態の例における各種構成要素は、矛盾等が生じない範囲で適宜組み合わせ可能である。また、ある実施形態の例として説明した内容については、他の実施形態においてその説明を省略している場合がある。また、各実施形態の特徴部分に関係しない動作や処理については、その内容を省略している場合がある。さらに、以下で説明する各種フローやシーケンスを構成する各種処理の順序は、処理内容に矛盾等が生じない範囲で順不同である。
【0014】
[第1の実施形態]
本発明の第1の実施形態の概要について説明をする。以下では、第1の実施形態として、コンピュータの一例であるサーバにおいて実行されるプラン処理プログラムを例示して説明する。
【0015】
図1は、本発明の実施形態の少なくとも一つに対応するビデオゲーム処理システム100の構成の例を示すブロック図である。ビデオゲーム処理システム100は、ビデオゲーム処理サーバ10(サーバ10)と、ビデオゲーム処理システム100のユーザ(ゲームのプレイヤ等)が使用するユーザ端末20とを備える。ユーザ端末20A、20B、および20Cはそれぞれ、ユーザ端末20の一例である。ビデオゲーム処理システム100の構成はこれに限定されない。例えば、ビデオゲーム処理システム100は、単一のユーザ端末を複数のユーザが使用する構成であってよい。ビデオゲーム処理システム100が複数のサーバを備えてもよい。
【0016】
サーバ10とユーザ端末20は、コンピュータの一例である。サーバ10とユーザ端末20は、それぞれインターネットなどの通信ネットワーク30に通信可能に接続されている。通信ネットワーク30とサーバ10との間の接続、および通信ネットワーク30とユーザ端末20との間の接続は有線接続であっても無線接続であってもよい。例えば、ユーザ端末20は、通信事業者が管理する基地局と無線通信回線によるデータ通信を行うことにより、通信ネットワーク30と接続してよい。
【0017】
ビデオゲーム処理システム100は、サーバ10とユーザ端末20とを備えることにより、ユーザの操作に応じて各種処理を実行するための各種機能を実現する。
【0018】
サーバ10はビデオゲームの進行を制御する。サーバ10は、ビデオゲーム処理システム100の管理者によって管理され、複数のユーザ端末20に対して各種処理に関する情報を提供するための各種機能を有する。
【0019】
サーバ10は、プロセッサ11と、メモリ12と、記憶装置13とを備える。プロセッサ11は、例えば、各種の演算および制御を行うCPU(Central Processing Unit)等の中央処理装置である。また、サーバ10がGPU(Graphics Processing Unit)を備える場合には、各種の演算および制御の一部をGPUによって行うようにしてもよい。サーバ10は、メモリ12に読み出したデータを用いて各種の情報処理をプロセッサ11にて実行し、得られた処理結果を必要に応じて記憶装置13に記憶させる。
【0020】
記憶装置13は、各種情報を格納する記憶媒体としての機能を有する。記憶装置13の構成は特に限定されないが、ユーザ端末20にかかる処理負荷を軽減させるといった観点から、ビデオゲーム処理システム100にて行われる制御に必要な各種情報を全て記憶可能な構成であることが好ましい。このような例には、HDDやSSDがある。ただし、各種情報を記憶する記憶装置は、サーバ10がアクセス可能な状態で記憶領域を備えていればよく、例えば専用の記憶領域をサーバ10の外部に有する構成とされていてもよい。
【0021】
サーバ10は、ゲーム画像をレンダリング可能なゲームサーバなどの情報処理装置によって構成されてよい。
【0022】
ユーザ端末20はユーザによって管理され、ネットワーク配信型のゲームを行うことが可能な通信端末によって構成される。ネットワーク配信型のゲームを行うことが可能な通信端末の例として、例えば携帯電話端末、PDA(Personal Digital Assistant)、携帯型ゲーム装置、VRゴーグル、ARグラス、スマートグラス、ARコンタクト、所謂ウェアラブルデバイスなどがある。ビデオゲーム処理システム100が含み得るユーザ端末の構成はこれらに限定されず、ユーザが合成画像を認識し得る構成であればよい。ユーザ端末の構成の他の例には、各種通信端末を組み合わせたものやパーソナルコンピュータ、据置型ゲーム装置がある。
【0023】
ユーザ端末20は、通信ネットワーク30に接続し、サーバ10との通信を行うことにより各種処理を実行するためのハードウェア(例えば、座標に応じたブラウザ画面やゲーム画面を表示する表示装置など)およびソフトウェアを備える。なお、複数のユーザ端末20のそれぞれは、サーバ10を介さずに互いに直接通信を行うこともできる構成とされていてもよい。
【0024】
ユーザ端末20は表示装置が内蔵されていてよい。また、ユーザ端末20に対して、表示装置が無線接続あるいは有線接続されていてもよい。なお、表示装置は極めて一般的な構成であるため、ここでは図示を省略している。ゲーム画面は例えば、前述の合成画像として表示装置によって表示され、ユーザがこの合成画像を認識する。ゲーム画面は例えば、ユーザ端末が備える表示装置の一例であるディスプレイや、ユーザ端末と接続された表示装置の一例であるディスプレイに表示される。表示装置には、例えば、ホログラム表示が可能なホログラムディスプレイ装置や、画像(ゲーム画面を含む)をスクリーン等に映写する映写装置、XR表示を行う装置なども含まれる。XRには、VR(Virtual Reality)、AR(Augmented Reality)、MR(Mixed Reality)、およびSR(Substitutional Reality)などが含まれる。
【0025】
ユーザ端末20は、プロセッサ21と、メモリ22と、記憶装置23とを備える。プロセッサ21は、例えば、各種の演算および制御を行うCPU(Central Processing Unit)等の中央処理装置である。また、ユーザ端末20がGPU(Graphics Processing Unit)を備える場合には、各種の演算および制御の一部をGPUによって行うようにしてもよい。ユーザ端末20は、メモリ22に読み出したデータを用いて各種の情報処理をプロセッサ21にて実行し、得られた処理結果を必要に応じて記憶装置23に記憶させる。記憶装置23は、各種情報を格納する記憶媒体としての機能を有する。
【0026】
ユーザ端末20には入力装置が内蔵されていてよい。また、ユーザ端末20に対して入力装置が無線接続あるいは有線接続されていてもよい。入力装置はユーザによる操作入力を受け付ける。ユーザによる操作入力に応じて、サーバ10が備えるプロセッサまたはユーザ端末20が備えるプロセッサが、各種の制御処理を実行する。入力装置の例として、携帯電話端末が備えるタッチパネル画面、ARグラスに無線接続あるいは有線接続されたコントローラなどがある。また、ユーザ端末20が備えるカメラも入力装置に相当し得る。ユーザはカメラの前で手を動かす等のジェスチャーにより、操作入力を行う(ジェスチャー入力)。
【0027】
その他、ユーザ端末20はスピーカ等の他の出力装置を備えていてよい。他の出力装置は、ユーザに対して音声やその他の各種の情報を出力する。
【0028】
図2は、本発明の実施形態の少なくとも一つに対応するサーバの構成を示すブロック図である。サーバ10の構成の例であるサーバ10Aは、プラン生成部101を少なくとも備える。サーバ10Aが備えるプロセッサは、記憶装置に保持されたプラン処理プログラムを参照し、そのプログラムを実行することにより、プラン生成部101を機能的に実現する。
【0029】
プラン生成部101は、ゴール情報に基づいて、複数のタスクにより構成されたプランをドメインから生成する機能を有する。プラン生成部101は、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する機能を有する。
【0030】
次に、本発明の第1の実施形態におけるプログラム実行処理について説明する。
図3は、本発明の実施形態の少なくとも一つに対応するプラン処理プログラムの処理例を示すフローチャートである。
【0031】
プラン生成部101は、ゴール情報を取得する(St11)。プラン生成部101は、取得したゴール情報に基づいて、複数のタスクにより構成されたプランをドメインから生成する(St12)。ここで、プラン生成部101は、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する。
【0032】
サーバ10Aによって実行されるプラン処理プログラムは、キャラクタが実行するタスクを階層型タスクネットワークに基づいてプランニングする。キャラクタが実行するタスクを階層型タスクネットワークに基づいてプランニングするとは、階層型タスクネットワークを用いて、キャラクタが実行するタスクで構成されたプランを構築することをいう。キャラクタとは、構築されたプランに基づいて行動が制御される対象(制御対象キャラクタ)のことをいう。例えば、ゲームに登場する、ユーザが操作不能なキャラクタ(ノンプレイヤキャラクタ)等が制御対象キャラクタに相当する。ただし、キャラクタは人型のものには限られず、ゲームに登場する乗り物や機械、城などの各種オブジェクトも、制御対象キャラクタに該当し得る。
【0033】
ゴール情報とは、制御対象キャラクタが達成する目標に関するデータを意味する。ゴール情報は例えば、敵を無力化することや、自身の生存などであってよい。これら以外のゴール情報が設定されてもよい。
【0034】
タスクとは、制御対象キャラクタが実行する、階層型タスクネットワーク等におけるタスクを意味する。タスクには、プリミティブタスク(Primitive Task)とコンパウンドタスク(Compound Task)が含まれる。
【0035】
プランとは、プラナー(Planner)が生成する具体的な計画を意味する。
【0036】
ドメインとは、実行可能な処理(タスク)を集めた集合を意味する。
【0037】
状態とは、変化する物事の、その時その時の様子を意味する。例えば、制御対象キャラクタにバフがかけられていることなどが、状態の一例である。状態は、制御対象キャラクタ以外の対象の状態を意味していてもよい。例えば、敵キャラクタにデバフがかけられていることや、制御対象キャラクタが存在するフィールドの天気が雨であることなども、状態の一例である。
【0038】
条件とは、物事を決定したり約束したりするときに、前提あるいは制約となる事柄をいう。より具体的には、条件とは、タスクを決定するときに、前提あるいは制約となる事柄をいう。
例えば、「敵がいない」「敵が逃走中である」「自身の体力値が100以上である」「攻撃値200以上の武器を所持している」などが、条件の一例である。
【0039】
第1の実施形態の一側面として、階層型タスクネットワークに基づいて、環境の変化に柔軟に対応できるようなプランニングを行うことができる。
【0040】
[第2の実施形態]
本発明の第2の実施形態の概要について説明をする。以下では、第2の実施形態として、コンピュータの一例であるサーバにおいて実行されるプラン処理プログラムを例示して説明する。なお、サーバは、
図1に記載のビデオゲーム処理システム100が備えるサーバ10であってよい。
【0041】
図4は、本発明の実施形態の少なくとも一つに対応するサーバの構成を示すブロック図である。サーバ10の構成の例であるサーバ10Bは、プラン生成部101と、プラン実行部102とを少なくとも備える。サーバ10Bが備えるプロセッサは、記憶装置に保持されたプラン処理プログラムを参照し、そのプログラムを実行することにより、プラン生成部101と、プラン実行部102とを機能的に実現する。
【0042】
プラン生成部101は、ゴール情報に基づいて、複数のタスクにより構成されたプランをドメインから生成する機能を有する。プラン生成部101は、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する機能を有する。
【0043】
プラン実行部102は、プラン生成部101が生成したプランを取得し、プランに含まれるタスクを順次実行する機能を有する。プラン実行部は、取得したプランの一部を変更してから、プランに含まれるタスクを順次実行する機能を有する。
【0044】
次に、本発明の第2の実施形態におけるプログラム実行処理について説明する。
図5は、本発明の実施形態の少なくとも一つに対応するプラン処理プログラムの処理例を示すフローチャートである。
【0045】
プラン生成部101は、ゴール情報を取得する(St21)。プラン生成部101は、取得したゴール情報に基づいて、複数のタスクにより構成されたプランをドメインから生成する(St22)。ここで、プラン生成部101は、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する。
【0046】
プラン実行部102は、プラン生成部101が生成したプランを取得する(St23)。プラン実行部102は、取得したプランの一部を変更しつつ、プランに含まれるタスクを順次実行する(St24)。
【0047】
ゴール情報とは、制御対象キャラクタが達成する目標に関するデータを意味する。ゴール情報は例えば、敵を無力化することや、自身の生存などであってよい。これら以外のゴール情報が設定されてもよい。
【0048】
タスクとは、制御対象キャラクタが実行する、階層型タスクネットワーク等におけるタスクを意味する。タスクには、プリミティブタスク(Primitive Task)とコンパウンドタスク(Compound Task)が含まれる。
【0049】
プランとは、プラナー(Planner)が生成する具体的な計画を意味する。
【0050】
ドメインとは、実行可能な処理(タスク)を集めた集合を意味する。
【0051】
状態とは、変化する物事の、その時その時の様子を意味する。例えば、制御対象キャラクタにバフがかけられていることなどが、状態の一例である。状態は、制御対象キャラクタ以外の対象の状態を意味していてもよい。例えば、敵キャラクタにデバフがかけられていることや、制御対象キャラクタが存在するフィールドの天気が雨であることなども、状態の一例である。
【0052】
条件とは、物事を決定したり約束したりするときに、前提あるいは制約となる事柄をいう。より具体的には、条件とは、タスクを決定するときに、前提あるいは制約となる事柄をいう。
例えば、「敵がいない」「敵が逃走中である」「自身の体力値が100以上である」「攻撃値200以上の武器を所持している」などが、条件の一例である。
【0053】
取得したプランの一部を変更することには、例えば、取得したプランに含まれる一部のタスクを改変、置き換え、または削除することが含まれる。取得したプランの一部を変更することには、プランに新たなタスクを追加することが含まれてもよい。取得したプランの一部を変更することには、取得したプランに含まれるタスクの実行を保留することが含まれてもよい。
【0054】
第2の実施形態の一側面として、タスクの実行主体(例えば制御対象キャラクタ)の制御を柔軟に行うことができる。
【0055】
[第3の実施形態]
本発明の第3の実施形態の概要について説明をする。以下では、第3の実施形態として、コンピュータの一例であるサーバにおいて実行されるスタイルトランスファープログラムを例示して説明する。なお、サーバは、
図1に記載のビデオゲーム処理システム100が備えるサーバ10であってよい。
【0056】
図6は、本発明の実施形態の少なくとも一つに対応するサーバの構成を示すブロック図である。サーバ10の構成の例であるサーバ10Cは、プラン生成部101Cと、シミュレータ110とを少なくとも備える。サーバ10Cが備えるプロセッサは、記憶装置に保持されたプラン処理プログラムを参照し、そのプログラムを実行することにより、プラン生成部101Cとシミュレータ110とを機能的に実現する。
【0057】
プラン生成部101Cは、ゴール情報に基づいて、複数のタスクにより構成されたプランをドメインから生成する機能を有する。プラン生成部101Cは、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する機能を有する。
【0058】
プラン生成部101Cは、ドメインに含まれる複数の選択可能なタスクをシミュレータ110により仮実行して評価値を計算し、ゴール情報と前記評価値とに基づいてプランを生成する機能を有する。
【0059】
次に、本発明の第3の実施形態におけるプログラム実行処理について説明する。
図7は、本発明の実施形態の少なくとも一つに対応するプラン処理プログラムの処理例を示すフローチャートである。
【0060】
プラン生成部101Cは、ゴール情報を取得する(St31)。プラン生成部101Cは、ドメインに含まれる複数の選択可能なタスクをシミュレータ110により仮実行して評価値を計算する(St32)。プラン生成部101Cは、取得したゴール情報と、計算した評価値とに基づいて、複数のタスクにより構成されたプランをドメインから生成する(St33)。ここで、プラン生成部101Cは、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する。
【0061】
ゴール情報とは、制御対象キャラクタが達成する目標に関するデータを意味する。ゴール情報は例えば、敵を無力化することや、自身の生存などであってよい。これら以外のゴール情報が設定されてもよい。
【0062】
タスクとは、制御対象キャラクタが実行する、階層型タスクネットワーク等におけるタスクを意味する。タスクには、プリミティブタスク(Primitive Task)とコンパウンドタスク(Compound Task)が含まれる。
【0063】
プランとは、プラナー(Planner)が生成した具体的な計画を意味する。
【0064】
ドメインとは、実行可能な処理(タスク)を集めた集合を意味する。
【0065】
状態とは、変化する物事の、その時その時の様子を意味する。例えば、制御対象キャラクタにバフがかけられていることなどが、状態の一例である。状態は、制御対象キャラクタ以外の対象の状態を意味していてもよい。例えば、敵キャラクタにデバフがかけられていることや、制御対象キャラクタが存在するフィールドの天気が雨であることなども、状態の一例である。
【0066】
条件とは、物事を決定したり約束したりするときに、前提あるいは制約となる事柄をいう。より具体的には、条件とは、タスクを決定するときに、前提あるいは制約となる事柄をいう。
例えば、「敵がいない」「敵が逃走中である」「自身の体力値が100以上である」「攻撃値200以上の武器を所持している」などが、条件の一例である。
【0067】
シミュレータとは、タスクの実行を仮実行するプログラム、装置、システム、またはこれらの組み合わせを言う。
【0068】
第3の実施形態の一側面として、プラン生成はロジカルな推論に基づいて行われていたところ、シミュレーションを行うことにより、タスク実行に応じた状況の変化を予測した上でプランニングを行うことができる。
【0069】
[第4の実施形態]
本発明の第4の実施形態の概要について説明をする。以下では、第4の実施形態として、コンピュータの一例であるサーバにおいて実行されるスタイルトランスファープログラムを例示して説明する。なお、サーバは、
図1に記載のビデオゲーム処理システム100が備えるサーバ10であってよい。
【0070】
図8は、本発明の実施形態の少なくとも一つに対応するサーバの構成を示すブロック図である。サーバ10の構成の例であるサーバ10Dは、プラン生成部101Dを少なくとも備える。サーバ10Dが備えるプロセッサは、記憶装置に保持されたプラン処理プログラムを参照し、そのプログラムを実行することにより、プラン生成部101Dを機能的に実現する。
【0071】
プラン生成部101Dは、ゴール情報に基づいて、複数のタスクにより構成されたプランをドメインから生成する機能を有する。プラン生成部101Dは、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する機能を有する。
【0072】
プラン生成部101Dは、ゴール情報と、制御対象キャラクタ以外のオブジェクトのタスク実行、アクションまたは状態変化とに基づいて、プランをドメインから生成する機能を有する。
【0073】
次に、本発明の第4の実施形態におけるプログラム実行処理について説明する。
図9は、本発明の実施形態の少なくとも一つに対応するプラン処理プログラムの処理例を示すフローチャートである。
【0074】
プラン生成部101Dは、ゴール情報を取得する(St41)。プラン生成部101Dは、取得したゴール情報と、制御対象キャラクタ以外のオブジェクトのタスク実行、アクションまたは状態変化とに基づいて、複数のタスクにより構成されたプランをドメインから生成する(St42)。ここで、プラン生成部101Dは、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する。
【0075】
ゴール情報とは、制御対象キャラクタが達成する目標に関するデータを意味する。ゴール情報は例えば、敵を無力化することや、自身の生存などであってよい。これら以外のゴール情報が設定されてもよい。
【0076】
タスクとは、制御対象キャラクタが実行する、階層型タスクネットワーク等におけるタスクを意味する。タスクには、プリミティブタスク(Primitive Task)とコンパウンドタスク(Compound Task)が含まれる。
【0077】
プランとは、プラナー(Planner)が生成する具体的な計画を意味する。
【0078】
ドメインとは、実行可能な処理(タスク)を集めた集合を意味する。
【0079】
状態とは、変化する物事の、その時その時の様子を意味する。例えば、制御対象キャラクタにバフがかけられていることなどが、状態の一例である。状態は、制御対象キャラクタ以外の対象の状態を意味していてもよい。例えば、敵キャラクタにデバフがかけられていることや、制御対象キャラクタが存在するフィールドの天気が雨であることなども、状態の一例である。
【0080】
条件とは、物事を決定したり約束したりするときに、前提あるいは制約となる事柄をいう。より具体的には、条件とは、タスクを決定するときに、前提あるいは制約となる事柄をいう。
例えば、「敵がいない」「敵が逃走中である」「自身の体力値が100以上である」「攻撃値200以上の武器を所持している」などが、条件の一例である。
【0081】
キャラクタ以外のオブジェクト、におけるキャラクタとは、プラン生成部101Dが生成したプランに基づいて制御されるキャラクタを意味する。便宜上、当該キャラクタを制御対象キャラクタと表現する。そして、キャラクタ以外のオブジェクトとは、制御対象キャラクタとは異なるオブジェクトを意味する。オブジェクトには制御対象キャラクタとは異なるキャラクタが含まれる。例えば、対戦要素が含まれるゲームにおいて、制御対象キャラクタと敵対するキャラクタ(敵キャラクタ)が、キャラクタ以外のオブジェクトに含まれる。制御対象キャラクタと協力するキャラクタ(味方キャラクタ)も、キャラクタ以外のオブジェクトに含まれる。また、キャラクタ以外の任意のオブジェクト、例えばゲームに登場する自動車オブジェクトや建物オブジェクト等も、キャラクタ以外のオブジェクトに含まれる。キャラクタ以外のオブジェクトは、制御対象キャラクタが属するゲーム世界そのもの(ゲームオブジェクト)であってもよい。
【0082】
キャラクタ以外のオブジェクトは、タスクを実行可能なオブジェクトであってよい。キャラクタ以外のオブジェクトは、アクションを実行可能なオブジェクトであってもよい。たとえば敵キャラクタはタスクを実行可能であり、アクションを実行可能でもある。
【0083】
制御対象キャラクタ以外のオブジェクトのタスク実行、アクションまたは状態変化は、制御対象キャラクタによるタスク実行に応じたものであっても、そうでないものであってもよい。
【0084】
第4の実施形態の一側面として、制御対象キャラクタ以外のオブジェクト(例えば敵キャラクタ)に起因した環境の変化にも柔軟に対応できるようなプランニングを行うことができる。
【0085】
[第5の実施形態]
本発明の第5の実施形態の概要について説明をする。以下では、第5の実施形態として、プラン処理システムを例示して説明する。
【0086】
図10は、本発明の実施形態の少なくとも一つに対応するビデオゲーム処理システム100Aの構成の例を示すブロック図である。プラン処理システムの一例であるビデオゲーム処理システム100Aは、ビデオゲーム処理サーバ10(サーバ10)と、ビデオゲーム処理システム100Aのユーザ(ゲームのプレイヤ等)が使用するユーザ端末20とを備える。ユーザ端末20A、20B、および20Cはそれぞれ、ユーザ端末20の一例である。ビデオゲーム処理システム100Aの構成はこれに限定されない。例えば、ビデオゲーム処理システム100Aは、単一のユーザ端末を複数のユーザが使用する構成であってよい。ビデオゲーム処理システム100Aが複数のサーバを備えてもよい。
【0087】
サーバ10とユーザ端末20は、コンピュータの一例である。サーバ10とユーザ端末20は、それぞれインターネットなどの通信ネットワーク30に通信可能に接続されている。通信ネットワーク30とサーバ10との間の接続、および通信ネットワーク30とユーザ端末20との間の接続は有線接続であっても無線接続であってもよい。例えば、ユーザ端末20は、通信事業者が管理する基地局と無線通信回線によるデータ通信を行うことにより、通信ネットワーク30と接続してよい。
【0088】
ビデオゲーム処理システム100Aは、サーバ10とユーザ端末20とを備えることにより、ユーザの操作に応じて各種処理を実行するための各種機能を実現する。
【0089】
サーバ10はビデオゲームの進行を制御する。サーバ10は、ビデオゲーム処理システム100Aの管理者によって管理され、複数のユーザ端末20に対して各種処理に関する情報を提供するための各種機能を有する。
【0090】
サーバ10は、プロセッサ11と、メモリ12と、記憶装置13とを備える。プロセッサ11は、例えば、各種の演算および制御を行うCPU(Central Processing Unit)等の中央処理装置である。また、サーバ10がGPU(Graphics Processing Unit)を備える場合には、各種の演算および制御の一部をGPUによって行うようにしてもよい。サーバ10は、メモリ12に読み出したデータを用いて各種の情報処理をプロセッサ11にて実行し、得られた処理結果を必要に応じて記憶装置13に記憶させる。
【0091】
記憶装置13は、各種情報を格納する記憶媒体としての機能を有する。記憶装置13の構成は特に限定されないが、ユーザ端末20にかかる処理負荷を軽減させるといった観点から、ビデオゲーム処理システム100Aにて行われる制御に必要な各種情報を全て記憶可能な構成であることが好ましい。このような例には、HDDやSSDがある。ただし、各種情報を記憶する記憶装置は、サーバ10がアクセス可能な状態で記憶領域を備えていればよく、例えば専用の記憶領域をサーバ10の外部に有する構成とされていてもよい。
【0092】
サーバ10は、ゲーム画像をレンダリング可能なゲームサーバなどの情報処理装置によって構成されてよい。
【0093】
ユーザ端末20はユーザによって管理され、ネットワーク配信型のゲームを行うことが可能な通信端末によって構成される。ネットワーク配信型のゲームを行うことが可能な通信端末の例として、例えば携帯電話端末、PDA(Personal Digital Assistant)、携帯型ゲーム装置、VRゴーグル、ARグラス、スマートグラス、ARコンタクト、所謂ウェアラブルデバイスなどがある。ビデオゲーム処理システム100Aが含み得るユーザ端末の構成はこれらに限定されず、ユーザが合成画像を認識し得る構成であればよい。ユーザ端末の構成の他の例には、各種通信端末を組み合わせたものやパーソナルコンピュータ、据置型ゲーム装置がある。
【0094】
ユーザ端末20は、通信ネットワーク30に接続し、サーバ10との通信を行うことにより各種処理を実行するためのハードウェア(例えば、座標に応じたブラウザ画面やゲーム画面を表示する表示装置など)およびソフトウェアを備える。なお、複数のユーザ端末20のそれぞれは、サーバ10を介さずに互いに直接通信を行うこともできる構成とされていてもよい。
【0095】
ユーザ端末20は表示装置が内蔵されていてよい。また、ユーザ端末20に対して、表示装置が無線接続あるいは有線接続されていてもよい。なお、表示装置は極めて一般的な構成であるため、ここでは図示を省略している。ゲーム画面は例えば、前述の合成画像として表示装置によって表示され、ユーザがこの合成画像を認識する。ゲーム画面は例えば、ユーザ端末が備える表示装置の一例であるディスプレイや、ユーザ端末と接続された表示装置の一例であるディスプレイに表示される。表示装置には、例えば、ホログラム表示が可能なホログラムディスプレイ装置や、画像(ゲーム画面を含む)をスクリーン等に映写する映写装置、XR表示を行う装置なども含まれる。XRには、VR(Virtual Reality)、AR(Augmented Reality)、MR(Mixed Reality)、およびSR(Substitutional Reality)などが含まれる。
【0096】
ユーザ端末20は、プロセッサ21と、メモリ22と、記憶装置23とを備える。プロセッサ21は、例えば、各種の演算および制御を行うCPU(Central Processing Unit)等の中央処理装置である。また、ユーザ端末20がGPU(Graphics Processing Unit)を備える場合には、各種の演算および制御の一部をGPUによって行うようにしてもよい。ユーザ端末20は、メモリ22に読み出したデータを用いて各種の情報処理をプロセッサ21にて実行し、得られた処理結果を必要に応じて記憶装置23に記憶させる。記憶装置23は、各種情報を格納する記憶媒体としての機能を有する。
【0097】
ユーザ端末20には入力装置が内蔵されていてよい。また、ユーザ端末20に対して入力装置が無線接続あるいは有線接続されていてもよい。入力装置はユーザによる操作入力を受け付ける。ユーザによる操作入力に応じて、サーバ10が備えるプロセッサまたはユーザ端末20が備えるプロセッサが、各種の制御処理を実行する。入力装置の例として、携帯電話端末が備えるタッチパネル画面、ARグラスに無線接続あるいは有線接続されたコントローラなどがある。また、ユーザ端末20が備えるカメラも入力装置に相当し得る。ユーザはカメラの前で手を動かす等のジェスチャーにより、操作入力を行う(ジェスチャー入力)。
【0098】
その他、ユーザ端末20はスピーカ等の他の出力装置を備えていてよい。他の出力装置は、ユーザに対して音声やその他の各種の情報を出力する。
【0099】
図11は、本発明の実施形態の少なくとも一つに対応するプラン処理システムの構成を示すブロック図である。プラン処理システムの一例であるビデオゲーム処理システム100Aはプラン生成部501を少なくとも備える。ビデオゲーム処理システム100Aが備える一つ以上のプロセッサは、ビデオゲーム処理システム100Aが備える一つ以上の記憶装置に保持されたプラン処理プログラムを参照し、そのプログラムを実行することにより、プラン生成部501を機能的に実現する。
【0100】
プラン生成部501は、ゴール情報に基づいて、複数のタスクにより構成されたプランをドメインから生成する機能を有する。プラン生成部501は、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する機能を有する。
【0101】
次に、本発明の第5の実施形態におけるプログラム実行処理について説明する。
図12は、本発明の実施形態の少なくとも一つに対応するプラン処理の例を示すフローチャートである。
【0102】
プラン生成部501は、ゴール情報を取得する(St51)。プラン生成部501は、取得したゴール情報に基づいて、複数のタスクにより構成されたプランをドメインから生成する(St52)。ここで、プラン生成部501は、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する。
【0103】
ゴール情報とは、制御対象キャラクタが達成する目標に関するデータを意味する。ゴール情報は例えば、敵を無力化することや、自身の生存などであってよい。これら以外のゴール情報が設定されてもよい。
【0104】
タスクとは、制御対象キャラクタが実行する、階層型タスクネットワーク等におけるタスクを意味する。タスクには、プリミティブタスク(Primitive Task)とコンパウンドタスク(Compound Task)が含まれる。
【0105】
プランとは、プラナー(Planner)が生成する具体的な計画を意味する。
【0106】
ドメインとは、実行可能な処理(タスク)を集めた集合を意味する。
【0107】
状態とは、変化する物事の、その時その時の様子を意味する。例えば、制御対象キャラクタにバフがかけられていることなどが、状態の一例である。状態は、制御対象キャラクタ以外の対象の状態を意味していてもよい。例えば、敵キャラクタにデバフがかけられていることや、制御対象キャラクタが存在するフィールドの天気が雨であることなども、状態の一例である。
【0108】
条件とは、物事を決定したり約束したりするときに、前提あるいは制約となる事柄をいう。より具体的には、条件とは、タスクを決定するときに、前提あるいは制約となる事柄をいう。
例えば、「敵がいない」「敵が逃走中である」「自身の体力値が100以上である」「攻撃値200以上の武器を所持している」などが、条件の一例である。
【0109】
第5の実施形態の一側面として、階層型タスクネットワークに基づいて、環境の変化に柔軟に対応できるようなプランニングを行うことができる。
【0110】
[第6の実施形態]
本発明の第6の実施形態の概要について説明をする。以下では、第6の実施形態として、ユーザ端末において実行されるプラン処理プログラムを例示して説明する。なお、ユーザ端末20Xは、
図1または
図10に示された複数のユーザ端末20、20A~20Cのうちのいずれかであってよい。
【0111】
図13は、本発明の実施形態の少なくとも一つに対応するユーザ端末20Xの構成を示すブロック図である。ユーザ端末20Xは、プラン生成部201を少なくとも備える。ユーザ端末20Xが備えるプロセッサは、記憶装置に保持されたプラン処理プログラムを参照し、そのプログラムを実行することにより、プラン生成部201を機能的に実現する。
【0112】
プラン生成部201は、ゴール情報に基づいて、複数のタスクにより構成されたプランをドメインから生成する機能を有する。プラン生成部201は、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する機能を有する。
【0113】
次に、本発明の第6の実施形態におけるプログラム実行処理について説明する。
図14は、本発明の実施形態の少なくとも一つに対応するプラン処理の例を示すフローチャートである。
【0114】
プラン生成部201は、ゴール情報を取得する(St61)。プラン生成部201は、取得したゴール情報に基づいて、複数のタスクにより構成されたプランをドメインから生成する(St62)。ここで、プラン生成部201は、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する。
【0115】
ゴール情報とは、制御対象キャラクタが達成する目標に関するデータを意味する。ゴール情報は例えば、敵を無力化することや、自身の生存などであってよい。これら以外のゴール情報が設定されてもよい。
【0116】
タスクとは、制御対象キャラクタが実行する、階層型タスクネットワーク等におけるタスクを意味する。タスクには、プリミティブタスク(Primitive Task)とコンパウンドタスク(Compound Task)が含まれる。
【0117】
プランとは、プラナー(Planner)が生成する具体的な計画を意味する。
【0118】
ドメインとは、実行可能な処理(タスク)を集めた集合を意味する。
【0119】
状態とは、変化する物事の、その時その時の様子を意味する。例えば、制御対象キャラクタにバフがかけられていることなどが、状態の一例である。状態は、制御対象キャラクタ以外の対象の状態を意味していてもよい。例えば、敵キャラクタにデバフがかけられていることや、制御対象キャラクタが存在するフィールドの天気が雨であることなども、状態の一例である。
【0120】
条件とは、物事を決定したり約束したりするときに、前提あるいは制約となる事柄をいう。より具体的には、条件とは、タスクを決定するときに、前提あるいは制約となる事柄をいう。
例えば、「敵がいない」「敵が逃走中である」「自身の体力値が100以上である」「攻撃値200以上の武器を所持している」などが、条件の一例である。
【0121】
第6の実施形態の一側面として、階層型タスクネットワークに基づいて、環境の変化に柔軟に対応できるようなプランニングを行うことができる。
【0122】
[第7の実施形態]
本発明の第7の実施形態の概要について説明をする。以下では、第7の実施形態として、サーバにおいて実行されるプラン処理プログラムを例示して説明する。なお、サーバは、
図1または
図10に記載のサーバ10であってよい。
【0123】
図15は、本発明の実施形態の少なくとも一つに対応するサーバの構成を示すブロック図である。サーバ10の構成の例であるサーバ10Zは、プラン生成部101Zと、プラン実行部102Zと、タスク分解部103Zと、シミュレータ110Zとを少なくとも備える。サーバ10Zが備えるプロセッサは、記憶装置に保持されたプラン処理プログラムを参照し、そのプログラムを実行することにより、プラン生成部101Zと、プラン実行部102Zと、タスク分解部103Zと、シミュレータ110Zとを機能的に実現する。
【0124】
プラン生成部101Zは、ゴール情報に基づいて、複数のタスクにより構成されたプランをドメインから生成する機能を有する。プラン生成部101Zは、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する機能を有する。
【0125】
プラン実行部102Zは、プラン生成部101Zが生成したプランを取得し、プランに含まれるタスクを順次実行する機能を有する。プラン実行部102Zは、取得したプランの一部を変更してから、プランに含まれるタスクを順次実行する機能を有する。
【0126】
タスク分解部103Zは、タスクをより具体的な複数のタスクに分解する機能を有する。
【0127】
シミュレータ110Zについては後述する。
【0128】
次に、本発明の第7の実施形態におけるプログラム実行処理について説明する。
図16は、本発明の実施形態の少なくとも一つに対応するプラン処理プログラムの処理例を示すフローチャートである。
【0129】
プラン生成部101Zは、ゴール情報を取得する(St71)。プラン生成部101Zは、取得したゴール情報に基づいて、複数のタスクにより構成されたプランをドメインから生成する(St72)。ここで、プラン生成部101Zは、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する。
【0130】
プラン実行部102Zは、プラン生成部101Zが生成したプランを取得する(St73)。プラン実行部102Zは、取得したプランの一部を変更しつつ、プランに含まれるタスクを順次実行する(St74)。
【0131】
サーバ10Zによって実行されるプラン処理プログラムは、キャラクタが実行するタスクを階層型タスクネットワークに基づいてプランニングする。キャラクタが実行するタスクを階層型タスクネットワークに基づいてプランニングするとは、階層型タスクネットワークを用いて、キャラクタが実行するタスクで構成されたプランを構築することをいう。キャラクタとは、構築されたプランに基づいて行動が制御される対象(制御対象キャラクタ)のことをいう。例えば、ゲームに登場する、ユーザが操作不能なキャラクタ(ノンプレイヤキャラクタ)等が制御対象キャラクタに相当する。ただし、キャラクタは人型のものには限られず、ゲームに登場する乗り物や機械、城などの各種オブジェクトも、制御対象キャラクタに該当し得る。
【0132】
ゴール情報とは、制御対象キャラクタが達成する目標に関するデータを意味する。ゴール情報は例えば、敵を無力化することや、自身の生存などであってよい。これら以外のゴール情報が設定されてもよい。
【0133】
図17は、本発明の実施形態の少なくとも一つに対応する、階層型タスクネットワークの構成例を示すブロック図である。
【0134】
階層型タスクネットワークには、タスクと、ドメインと、プラナーと、ワールドステートと、プランとが関連する。制御対象キャラクタが属する空間(例えば仮想空間)をワールドとした時に、ワールドの状態をワールドステートという。ワールドステートには、ワールドについての各種の情報が記憶される。
【0135】
タスクとは、制御対象キャラクタが実行する、階層型タスクネットワーク等におけるタスクを意味する。タスクには、プリミティブタスク(Primitive Task)とコンパウンドタスク(Compound Task)が含まれる。コンパウンドタスクとは、階層型タスクネットワークにおいて実行されるタスクの1つであってタスクが達成すべき結果に至る方法を記述したメソッドを複数持つものをいう。メソッドとは、自身が選ばれるためのコンディションと、選ばれたときのタスク(への参照)のリストを持つものをいう。メソッドは、コンディションと、コンパウンドタスクとプリミティブタスクの何れかに対する参照であるリストとを持つ。プリミティブタスクとは、実際に操作対象に影響を与えるオペレータを含むタスクのことをいう。プリミティブタスクは、実行するためのコンディションと、実行する内容を表すオペレータと、実行した時ワールドステートへの影響(エフェクト)とを持つ。オペレータとは、実際の処理を行う単一の行動(アクション)のことをいう。
【0136】
ドメインとは、実行可能な処理(タスク)を集めた集合を意味する。ドメインは、コンパウンドタスクとプリミティブタスクとを含み得る。そのため、階層型タスクネットワークにおけるドメインの中では、タスクが階層化された状態で存在する。
【0137】
プラナー(Planner)は、本実施形態におけるプラン生成部101Zに対応する。プラナーは、ワールドステートからワールドの情報を取得しながら、ドメインから複数のタスクを抽出する。プラン生成部101Zは、抽出した複数のタスクを分解し、ゴール情報に基づいて実行順序も含めて実行すべきタスクを決定してプランを生成する。プランとは、プラナーが生成する具体的な計画を意味する。
【0138】
プラナーが上述のような階層型タスクネットワークに基づいてプランを生成することにより、制御対象キャラクタに長期的な視野を与え、一貫性のある行動をとらせることができる。
【0139】
図18は、一般的な階層型タスクネットワークに基づいたプラン生成例を示す概念図である。一般的な階層型タスクネットワークに基づいたプラン生成の場合、生成されたプランに含まれるタスクは、図示されているように一列のチェーン状に配列されることになる。
【0140】
制御対象キャラクタが登場するゲームなどにおいて、プランの生成時とプランの実行時との間に環境が変化することがある。例えば、制御対象キャラクタが敵キャラクタに対して遠距離攻撃を行うための一連のタスクを実行している途中で、敵キャラクタが射程距離外に退避した場合、制御対象キャラクタは遠距離攻撃を行うタスクを続けて実行することができなくなる。このように、プランが生成された後に環境が変化すると、既存の階層型タスクネットワークに基づくプランニングでは、生成済みのプランをうまく変化に適応させる手段がないため、プランの再生成(リプランニング)が発生する。このリプランニングが頻繁に行われると、制御対象キャラクタから長期的な一貫性が失われる可能性がある。
【0141】
そこで、本発明の実施形態の少なくとも一つに対応するプラン処理プログラムにおいては、プラン生成部101Zが、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する。
【0142】
状態とは、変化する物事の、その時その時の様子を意味する。例えば、制御対象キャラクタにバフがかけられていることなどが、状態の一例である。状態は、制御対象キャラクタ以外の対象の状態を意味していてもよい。例えば、敵キャラクタにデバフがかけられていることや、制御対象キャラクタが存在するフィールドの天気が雨であることなども、状態の一例である。
【0143】
条件とは、物事を決定したり約束したりするときに、前提あるいは制約となる事柄をいう。より具体的には、条件とは、タスクを決定するときに、前提あるいは制約となる事柄をいう。
例えば、「敵がいない」「敵が逃走中である」「自身の体力値が100以上である」「攻撃値200以上の武器を所持している」などが、条件の一例である。
【0144】
図19は、本発明の実施形態の少なくとも一つに対応する、プラナーが生成するプランを例示する概念図である。プラン生成部101Zは、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する。
図19には、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランの例として、第1プランと第2プランとが例示されている。第1プランは、状態または条件に応じて枝が分岐するツリー構造で構成されたプランである。第2プランは、有向非巡回グラフとして構成されたプランである。
【0145】
プラン生成部101Zが、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成することにより、制御対象キャラクタの行動を環境の変化に柔軟に対応させることができる。特に、環境の変化に応じたリプランニングの回数が少なくなるため、リアルタイム性が求められるゲーム等においても、制御対象キャラクタを柔軟に制御できる。また、制御対象キャラクタが、細かいアニメーション制御、確率的に発生する偶発イベント、および制御対象キャラクタとは別の意図をもったエージェント(例えば敵キャラクタ)がいる環境に対しても柔軟に対応できるようになる。
【0146】
図20は、本発明の実施形態の少なくとも一つに対応するプラン処理プログラムにおける、階層型タスクネットワークの構造例を示す概念図である。
【0147】
本発明の実施形態の少なくとも一つに対応するプラン処理プログラムは、プラナー(プラン生成部101Z)に加えて、エグゼキュータ(プラン実行部102Z)を備えている。
【0148】
エグゼキュータは、プラナーが生成した一以上のプランを取得して、取得したプランに含まれるタスクを順次実行する。エグゼキュータが直近のタスクを実行すると、当該直近のタスク実行に応じて制御対象キャラクタの身体(ボディ)が制御される。例えば、制御対象キャラクタのボディが、ゲーム内でアクションを行う。
【0149】
ここで、本発明の実施形態の少なくとも一つに対応するプラン処理プログラムにおいては、プランを立てるモジュールであるプラナーと、プランを実行するモジュールであるエグゼキュータとを分離し、役割分担を行ってよい。プラン実行を担当するエグゼキュータには、プランを一部変更したり保留したりできる権限を持たせる。エグゼキュータは、プラナーから取得したプランを単に実行するだけでなく、取得したプランの一部を変更する機能および権限を有する。エグゼキュータは、複数のプランを管理する機能と、タスクを評価する機能をさらに有していてもよい。
【0150】
ここで、
図20には、エグゼキュータがプラナーから取得した3つのプランであるプランA、プランB、およびプランCが例示されている。プランAからプランCには、そのプランを実行する基準となる前提条件を示す情報がそれぞれ含まれていてよい。プランAからプランCには、そのプランについての予測情報がそれぞれ含まれていてよい。予測情報は、後述のシミュレータを用いて計算されたタスクの評価値などが含まれる。
【0151】
エグゼキュータは、制御対象キャラクタのボディからのフィードバック情報等に基づいて、取得したプランの一部を変更する。制御対象キャラクタのボディからのフィードバック情報は、例えば制御対象キャラクタのボディについてのアニメーション結果を示す情報や、制御対象キャラクタのボディに紐づけられた各種センサが取得した情報(例えばキャラクタの視覚情報や聴覚情報)などであってよい。すなわちエグゼキュータは、制御対象キャラクタが知覚した情報に基づいて、プランの一部を動的に変更しつつ、これを実行する。
【0152】
取得したプランの一部を変更することには、例えば、取得したプランに含まれる一部のタスクを改変、置き換え、または削除することが含まれる。取得したプランの一部を変更することには、プランに新たなタスクを追加することが含まれてもよい。取得したプランの一部を変更することには、取得したプランに含まれるタスクの実行を保留することが含まれてもよい。取得したプランの一部を変更することには、例えばあるプランの実行中に別のプランへと実行対象となるプランを変更する事などが含まれてもよい。
図20には一例として、エグゼキュータがプランAの実行中に実行対象となるプランをプランBへと変更し、プランAに含まれるタスクに応じて、対応タスクをプランBに追加する例が示されている。
【0153】
なお、制御対象キャラクタのボディからのフィードバック情報に基づいて、エグゼキュータが手持ちのプランのうちいずれも実行不能であると判断した場合、エグゼキュータはプラナーにリプランニングクエリを送信してよい。リプラニングクエリを受信したプラナーはリプランニングを行い、再生成されたプランをエグゼキュータに送信する。
【0154】
以上のように、エグゼキュータがプランの一部を変更しつつ、プランに含まれるタスクを順次実行することにより、制御対象キャラクタの行動制御がプラン通りにはいかない状況にもロバストに対応することができる。例えばエグゼキュータは、敵キャラクタの行動に起因する環境の変化に応じてプランの一部を変更しつつこれを実行することにより、制御対象キャラクタに咄嗟の行動を起こさせることができる。
【0155】
(タスクの実行時分解)
図21は、本発明の実施形態の少なくとも一つに対応するプラン処理プログラムにおける、タスクの分解例を示す概念図である。
図22は、本発明の実施形態の少なくとも一つに対応するプラン処理プログラムにおける、タスクの分解例を示す概念図である。
図23は、本発明の実施形態の少なくとも一つに対応するプラン処理プログラムにおける、タスクの分解例を示す概念図である。
図24は、本発明の実施形態の少なくとも一つに対応するプラン処理プログラムにおける、タスクの分解例を示す概念図である。以下、
図21から
図24に基づいて、タスクの実行時分解について説明する。
【0156】
図17に基づいて前述したように、階層型タスクネットワークのドメインにはコンパウンドタスクとプリミティブタスクとが含まれる。従来の階層型タスクネットワークの実装において、プラナーは、プランの生成時にコンパウンドタスクをプリミティブタスクまで分解していた。しかしながら、環境の変化に応じてリプランニングが発生した場合、タスク分解処理のほとんどが無駄な処理となっていた。
【0157】
そこで、本発明の実施形態の少なくとも一つに対応するプラン処理プログラムにおいては、プラン生成部101Zが、タスク分解部103Zに所定の階層までタスク分解を行わせてからプランを生成する。そしてプラン実行部102Zが、プランに含まれるタスクの少なくとも一部を、前記所定の階層よりも深い階層までタスク分解してから、プランに含まれるタスクを順次実行する。
【0158】
図21は、プラン生成時におけるプラン生成部101Zによるタスク分解を示している。プラン生成時において、プラン生成部101Zが所定の階層までタスク分解を行う。
【0159】
図22から
図24は、プラン実行時におけるプラン実行部102Zによるタスク分解を示している。プラン実行時においてプラン実行部102Zが、前記所定の階層よりも深い階層までタスク分解してから、プランに含まれるタスクを順次実行する。なお、所定の階層よりも深い階層とは、例えばプリミティブタスクが存在する階層であってよい。
【0160】
所定の階層は、例えば第2階層などのように、あらかじめ決定されていてよい。所定の階層はどのタスクに対しても一律に決定されていてもよい。所定の階層は、分解前のタスクAについては第2階層までであり、分解前のタスクBについては第3階層まで、などのように、タスクに応じて決定されてもよい。所定の階層は、求められるタスクの実行速度や、ゲームにおける環境の変化の速さ等の種々の条件に基づいて、プラン処理プログラムを実行するプロセッサにより動的に決定されてもよい。
【0161】
例えば環境の変化が速いリアルタイムゲームなどにおいては、プランの生成時とプランの実行時とでは環境が大きく変わっていることがある。また、敵キャラクタ等の、制御対象キャラクタ以外のオブジェクトの行動や状況変化にも応じて環境は変わる。上述のように、プラン生成時にはある程度の階層まででタスク分解をストップし、プラン実行時に続きのタスク分解を行うことにより、制御対象キャラクタに、大まかなプランに沿いながらも、プラン実行時の環境に沿ったタスクを効率的に実行させることができる。
【0162】
(シミュレータを用いたプラン生成)
図17に基づき前述したように、プラナーはワールドステートからワールドの情報を取得しながら、ドメインから複数のタスクを抽出する。プラン生成部101Zは、抽出した複数のタスクを分解し、ゴール情報に基づいて実行順序も含めて実行すべきタスクを決定してプランを生成する。
【0163】
ここで、本発明の実施形態の少なくとも一つに対応するプラン処理プログラムにおけるプラン生成部101Zは、シミュレータ110Zをさらに用いてプラン生成を行ってよい。
【0164】
プラン生成部101Zは、ドメインに含まれる複数の選択可能なタスクをシミュレータにより仮実行して評価値を計算し、ゴール情報と前記評価値とに基づいてプランを生成する機能を有する。
【0165】
ステップSt72においてプラン生成部101Zは、ドメインに含まれる複数の選択可能なタスクをシミュレータにより仮実行して評価値を計算し、ゴール情報と前記評価値とに基づいてプランを生成する。
【0166】
シミュレータとは、タスクを仮実行するプログラム、装置、システム、またはこれらの組み合わせをいう。シミュレータは、
図15に基づいて上述したシミュレータ110Zであってもよい。
【0167】
評価値は、タスクに対して決定される値であってもよく、一連のタスクから構成されるグループに対して決定される値であってもよい。
【0168】
図25は、本発明の実施形態の少なくとも一つに対応するプラン処理プログラムにおける、シミュレータ110を用いたプラン生成を例示する概念図である。
【0169】
一例として、プラン生成部101Zが、制御対象キャラクタを制御するためのプランAを生成途中であるとする。プランAのゴール情報は「偵察対象エリアであるエリアB2からE5の偵察を完了する」であると仮定する。
【0170】
プラン生成部101Zが、制御対象キャラクタを制御するためのプランに含めるタスクの候補として、3つのタスクをドメインから取得した。タスクAは移動を行うコンパウンドタスクである。タスクBは敵キャラクタに対して積極攻撃を行うコンパウンドタスクである。タスクCは偵察対象エリアから後退するコンパウンドタスクである。タスクA~Cはそれぞれ、プリミティブタスクへの参照を含んでいる。
【0171】
プラン生成部101Zは、敵がいるか否かという条件に応じて採用されるべき後続タスクが変わるようなプランを生成する。敵がいない場合に採用されるべきタスクとして、タスクAが設定された。敵がいる場合に採用されるべきタスクとして、タスクBとタスクCの2つの候補がある。例えば、敵に負ける可能性が低い場合、制御対象キャラクタはタスクBを実行した方がよい。敵に負ける可能性が高い場合、制御対象キャラクタはタスクCを実行した方がよい。ここで、ゲーム内での環境は一定ではなく、敵の強さ、人数、位置、および状態(油断しているなど)も一定ではない。
【0172】
そこでプラン生成部101Zは、ドメインに含まれる複数の選択可能なタスクをシミュレータ110により仮実行して評価値を計算する。シミュレータ110には、ワールドステートから取得した情報が入力される。評価値の計算式または計算アルゴリズムは、タスクまたはタスクのグループに応じて定められて良い。例えば、敵に負ける確率が評価値として用いられてよい。そしてプラン生成部101Zは、ゴール情報と評価値とに基づいてプランを生成する。例えば、敵に負ける可能性が低いというシミューレ―ション結果が出た場合、プラン生成部101ZはタスクBを、敵がいる場合に採用されるべきタスクとして設定する。敵に負ける可能性が高いというシミューレ―ション結果が出た場合、プラン生成部101ZはタスクCを、敵がいる場合に採用されるべきタスクとして設定する。
【0173】
以上のように、プラン生成はロジカルな推論に基づいて行われていたところ、プラン生成部101Zがシミュレーションを行って得た評価値に基づいてプランを生成することにより、タスク実行に伴う環境や状況の変化を予測した上でプランニングを行うことができる。
【0174】
なお、ワールドステートにロケーション情報が含まれていてよい。プラン生成部101Zは、ロケーション情報に基づいたシミュレーションを行って得た評価値に基づいてプランを生成してもよい。これにより、たとえば制御対象キャラクタと敵キャラクタとの間の、地形を利用した戦略、敵味方の位置関係を利用した戦術等に基づいたプランを柔軟に生成することができる。
【0175】
(低解像度シミュレータ)
シミュレータ110が用いるワールドの解像度(粒度)は、プラン生成部101Zが生成するプランを実行するワールドの解像度(粒度)よりも小さい(荒い)ものであってよい。すなわち以下の通りである。プラン生成部101Zが生成するプランは、制御対象キャラクタが当該プランに含まれるタスクを実行し得る空間に対応する第1の空間情報を用いて前記タスクを実行するものであるとする。一方で、シミュレータ110は、制御対象キャラクタが当該プランに含まれるタスクを実行し得る空間に対応する第2の空間情報を用いて選択可能なタスクを仮実行するものであるとする。この時、第2の空間情報は、第1の空間情報よりも情報量が少ない。
【0176】
空間情報とは、その空間の少なくとも一部を表現または記述する情報であってよい。制御対象キャラクタが登場するゲーム空間の例であれば、ナビメッシュを変換したウェイポイントグラフなどが空間情報に該当する。2次元空間を複数のマスまたはヘックスで分割して表現したマップ情報なども、空間情報に該当する。3次元空間を複数に分割して表現したボクセル情報なども、空間情報に該当する。これら以外の空間情報であってもよい。
【0177】
図26は、本発明の実施形態の少なくとも一つに対応するプラン処理プログラムが用いるシミュレータ110において、情報量の少ない第2の空間情報によってゲーム空間を表現した場合を例示する概念図である。
図26に例示した第2の空間情報は、ユーザが実際にプレイするゲームのゲーム空間を簡略化して(解像度を小さくして)表現しえちる。キャラクタが移動不能な山や壁などの場所が×によって、キャラクタが△によって、それぞれ表現されている。
【0178】
第2の空間情報が第1の空間情報よりも情報量が少ないことにより、シミュレータ110によるタスクの仮実行を高速で行うことができ、プラン生成部101Zがプランを迅速に生成することができる。
【0179】
(敵対的プランニング)
次に、制御対象キャラクタ以外のオブジェクトが環境の変化に影響する場合のプランニングについて説明する。
【0180】
プラン生成部101Zは、ゴール情報と、キャラクタ以外のオブジェクトのタスク実行、アクションまたは状態変化とに基づいて、プランを前記ドメインから生成する機能を有する。
【0181】
ステップSt72においてプラン生成部101Zは、取得したゴール情報と、キャラクタ以外のオブジェクトのタスク実行、アクションまたは状態変化とに基づいて、複数のタスクにより構成されたプランをドメインから生成する。
【0182】
キャラクタ以外のオブジェクト、におけるキャラクタとは、プラン生成部101Zが生成したプランに基づいて制御されるキャラクタを意味する。便宜上、当該キャラクタを制御対象キャラクタと表現する。そして、キャラクタ以外のオブジェクトとは、制御対象キャラクタとは異なるオブジェクトを意味する。オブジェクトには制御対象キャラクタとは異なるキャラクタが含まれる。例えば、対戦要素が含まれるゲームにおいて、制御対象キャラクタと敵対するキャラクタ(敵キャラクタ)が、キャラクタ以外のオブジェクトに含まれる。制御対象キャラクタと協力するキャラクタ(味方キャラクタ)も、キャラクタ以外のオブジェクトに含まれる。また、キャラクタ以外の任意のオブジェクト、例えばゲームに登場する自動車オブジェクトや建物オブジェクト等も、キャラクタ以外のオブジェクトに含まれる。キャラクタ以外のオブジェクトは、制御対象キャラクタが属するゲーム世界そのもの(ゲームオブジェクト)であってもよい。
【0183】
キャラクタ以外のオブジェクトは、タスクを実行可能なオブジェクトであってよい。キャラクタ以外のオブジェクトは、アクションを実行可能なオブジェクトであってもよい。たとえば敵キャラクタはタスクを実行可能であり、アクションを実行可能でもある。
【0184】
制御対象キャラクタ以外のオブジェクトのタスク実行、アクションまたは状態変化は、制御対象キャラクタによるタスク実行に応じたものであっても、そうでないものであってもよい。
【0185】
図27は、本発明の実施形態の少なくとも一つに対応する、制御対象キャラクタ以外のオブジェクトのタスク実行、アクションまたは状態変化を考慮したプラン生成例を示す概念図である。
【0186】
制御対象キャラクタ以外のオブジェクトは、敵キャラクタである場合を例示して説明する。
図27に示されているプランは、敵と味方とが交互にタスクを実行するタイプの対戦ゲーム(ターン制バトルゲーム)におけるプラン生成を例示している。味方の手と記載されているノードが、制御対象キャラクタが実行するタスクに相当する。敵の手と記載されているノードが、敵キャラクタが実行するタスクに相当する。
【0187】
制御対象キャラクタが先行タスクを実行したとする。次に敵キャラクタが実行するタスクにより環境が変化する。プラン生成部101Zは、この環境の変化に対応したタスクがプランに含まれるようにプランを生成する。すなわちプラン生成部101Zは、制御対象キャラクタ以外のオブジェクトの行動等を考慮したプランを生成する。
【0188】
なお、制御対象キャラクタによるタスク実行と、制御対象キャラクタ以外のオブジェクトによるタスク実行とは、交互に行われるとは限らない。例えば、敵キャラクタまたは味方キャラクタが、2回連続してタスクを実行してもよい。ターン制ではない対戦型ゲームの場合などにおいては、敵キャラクタと味方キャラクタとがそれぞれ、相手のタスク実行を待たずに自身のタスクを実行してもよい。
【0189】
また、制御対象キャラクタ以外のオブジェクトは、上記の敵キャラクタには限られない。制御対象キャラクタ以外の、環境に変化を与えるようなオブジェクトが存在する場合、プラン生成部101Zは、そのオブジェクトによる環境の変化を考慮してプランを生成することができる。
【0190】
上記の構成により、キャラクタ以外のオブジェクト(例えば敵キャラクタ)に基づく環境の変化にも柔軟に対応できるようなプランニングを行うことができる。
【0191】
(マルチシナリオプラン)
図28は、本発明の実施形態の少なくとも一つに対応する、プラン生成部101Zが生成するマルチシナリオプランの一例を示す概念図である。
【0192】
ゴール情報として、「プライマリゴール:敵の無力化」と、「ガードゴール:自分の生存」とが与えられたとする。ドメインには以下の4つのコンパウンドタスクが含まれている。
・索敵タスク(タスク実行条件:敵がいない)
・戦闘タスク(タスク実行条件:敵がいる)
・追撃タスク(タスク実行条件:敵がいる、かつ、敵が逃走中である)
・撤退タスク(タスク実行条件:自分の体力値(HP)がゼロになる可能性がある)
【0193】
上記のドメインに基づいたマルチシナリオプランは、例えば
図28に示されているような有向グラフにより表現される。戦闘タスクと索敵タスクとの間は双方向に遷移可能である。戦闘タスクと追撃タスクとの間は双方向に遷移可能である。索敵タスクから撤退タスクに遷移可能であるが、撤退タスクから索敵タスクには遷移できない。戦闘タスクから撤退タスクに遷移可能であるが、撤退タスクから戦闘タスクには遷移できない。追撃タスクから撤退タスクに遷移可能であるが、撤退タスクから追撃タスクには遷移できない。
【0194】
プラン生成部101Zは、マルチシナリオプランに含まれる各タスクを例えばツリー構造になるように展開する。
図29は、本発明の実施形態の少なくとも一つに対応する、プラン生成部101Zによるタスクの展開例を示す概念図である。
【0195】
プラン生成部101Zは、
図28に示した戦闘タスクをツリー構造になるように展開する。戦闘タスクは、敵と戦闘を行うタスクであるため、制御対象キャラクタである自分と、敵キャラクタである敵のそれぞれが実行する行動(タスク)に応じて、環境が刻々と変化する。
【0196】
まず、プラン生成部101Zは、タイムステップT:0からタイムステップT:1へとツリーを展開する。すなわちプラン生成部101Zは、タイムステップT:0において制御対象キャラクタが行い得る行動(タスク)と、敵キャラクタが行い得る行動(タスク)とを列挙して、それぞれのパターンに応じてツリーにおける分岐枝を作成する。
【0197】
タイムステップT:1において制御対象キャラクタが元の行動を継続していた場合、プラン生成部101Zは制御対象キャラクタに同じ行動を継続させる。一方、タイムステップT:1において制御対象キャラクタが元の行動を終了していた場合、プラン生成部101Zは制御対象キャラクタが実行すべき次の行動(タスク)を選択する。この次の行動(タスク)の選択処理は、タイムステップT:0からタイムステップT:1へとツリーを展開する際と同様の処理であってよい。
【0198】
タイムステップT:1において敵キャラクタが元の行動を継続していた場合、プラン生成部101Zは、敵キャラクタが同じ行動を継続するという前提で、制御対象キャラクタについてのタスクの展開をさらに進める。一方、タイムステップT:1において敵キャラクタが元の行動を終了していた場合、プラン生成部101Zは、敵キャラクタが実行すべき次の行動(タスク)を選択する。この次の行動(タスク)の選択は、タイムステップT:0からタイムステップT:1へとツリーを展開する際と同様の処理であってよい。
【0199】
プラン生成部101Zは、上記のような処理を、タイムステップT:0から順次繰り返す。どの程度のステート数(タイムステップT:NにおけるNの値)まで処理を繰り返すかは、分岐枝ごとに異なっていても、同じであってもよい。
【0200】
(枝の優先度)
上記のように、制御対象キャラクタと敵キャラクタのそれぞれの行動に応じてタスクを展開した場合、ステート数が膨大になる可能性がある。タスク展開時のステート数の増大を抑えるために、枝に優先度を持たせることが考えられる。例えばプラン生成部101Zは、先行するタスクから後続するタスクへと接続する枝の優先度を、前記後続するタスクの評価値に応じて決定し、枝の優先度に基づいてプランを生成してよい。
【0201】
例えばプラン生成部101Zは、枝の先にあるステート(後続するステート)の評価値が所定の値より小さくなるような枝の優先度を下げる。以下、具体例を示す。所定の値を500とする。プラン生成部101Zは、タイムステップT:0における評価値が1000であり、タイムステップT:1における評価値が300となるような枝の優先度を下げる。この場合の枝の先にあるステートであるタイムステップT:1における評価値は300であり、所定の値である500より小さいからである。プラン生成部101Zは、タイムステップT:0における評価値が1000であり、タイムステップT:1における評価値が600となるような枝の優先度を下げない。この場合の枝の先にあるステートである、タイムステップT:1における評価値は600であり、これは所定の値である500より大きいからである。
【0202】
例えばプラン生成部101Zは、枝の先にあるステート(後続するステート)の評価値が所定の値より大きくなるような枝の優先度を上げる。以下、具体例を示す。所定の値を1200とする。プラン生成部101Zは、タイムステップT:0における評価値が1000であり、タイムステップT:1における評価値が1300となるような枝の優先度を上げる。この場合の枝の先にあるステートであるタイムステップT:1における評価値は1300であり、所定の値である1200より大きいからである。プラン生成部101Zは、タイムステップT:0における評価値が1000であり、タイムステップT:1における評価値が1100となるような枝の優先度を上げない。この場合の枝の先にあるステートであるタイムステップT:1における評価値は1100であり、所定の値である1200より小さいからである。
【0203】
プラン生成部101Zは、後続するステートにおける評価値と先行するステートにおける評価値との間の差分に応じて、枝の優先度を決定してもよい。
【0204】
例えばプラン生成部101Zは、先行するステートにおける評価値に対する後続するステートにおける評価値の減少度が所定の値より大きい枝の優先度を下げる。以下、具体例を示す。所定の値を500とする。プラン生成部101Zは、タイムステップT:0における評価値が1000であり、タイムステップT:1における評価値が300となるような枝の優先度を下げる。この場合の評価値の減少度は700であり、所定の値である500より大きいからである。プラン生成部101Zは、タイムステップT:0における評価値が1000であり、タイムステップT:1における評価値が600となるような枝の優先度を下げない。この場合の評価値の減少度は400であり、所定の値である500より小さいからである。
【0205】
例えばプラン生成部101Zは、先行するステートにおける評価値に対する後続するステートにおける評価値の増加度が所定の値より大きい枝の優先度を上げる。以下、具体例を示す。所定の値を200とする。プラン生成部101Zは、タイムステップT:0における評価値が1000であり、タイムステップT:1における評価値が1300となるような枝の優先度を上げる。この場合の評価値の増加度は300であり、所定の値である200より大きいからである。プラン生成部101Zは、タイムステップT:0における評価値が1000であり、タイムステップT:1における評価値が1100となるような枝の優先度を上げない。この場合の評価値の増加度は100であり、所定の値である200より小さいからである。
【0206】
その他、プラン生成部101Zは、後続するステートにおける評価値と先行するステートにおける評価値との間の差分に応じて、優先度の上昇の度合いまたは下降の度合いを決定してもよい。例えばプラン生成部101Zは、評価値の増加量が大きい程、優先度の上昇の度合いを大きくしてよい。プラン生成部101Zは、評価値の減少量が大きい程、優先度の下降の度合いを大きくしてよい。
【0207】
なお、先行するステートは、後続するステートの1つ前のステートであってもよく、後続するステートの2つ以上前のステートであってもよい。例えば、後続するステートがタイムステップT:5におけるステートであるとする。先行するステートは、タイムステップT:4におけるステートであってよく、タイムステップT:0(分岐のスタート地点)におけるステートであってもよい。
【0208】
プラン生成部101Zは、枝の優先度に基づいてプランを生成する。例えばプラン生成部101Zは、優先度の高い枝を、優先度の低い枝よりも優先して展開する。具体例を示すと、プラン生成部101Zは、優先度の低い枝を残りMステートだけさらに展開し、優先度の高い枝を残りNステート分だけさらに展開する。このとき、M<Nであり、Mは0以上の整数である。0ステートだけさらに展開するとは、それ以上の展開はしないことを意味する。
【0209】
上記のように、プラン生成部101Zが、先行するタスクから後続するタスクへと接続する枝の優先度を、前記後続するタスクの評価値に応じて決定し、枝の優先度に基づいてプランを生成することにより、タスクを展開する際にステート数が膨大になる事を防ぐことができる。
【0210】
(時間遡行と分岐追加)
例えばアクションゲームにおいて、制御対象キャラクタがゲーム内でアクションを行う。このアクションがタスクに対応する。制御対象キャラクタがアクションを行った結果、ゲーム内での状況がそのキャラクタにとって好転するとは限らない。むしろアクションを行った結果、状況がそのキャラクタにとって悪化することもあり得る。このような場合に、制御対象キャラクタに異なるアクションの実行を選択させるための方法の一つとして、生成されるプランが含むツリー構造に、時間遡行を行う分岐を追加することが考えられる。
【0211】
プラン生成部101Zは、タスクに対応するアクションをキャラクタが実行するとアクションの評価値が所定の値よりも低くなる場合、アクションを取り消すための分岐をプランに追加する。
【0212】
図30は、本発明の実施形態の少なくとも一つに対応する、時間遡行の分岐を追加する例を示す概念図である。制御対象キャラクタが、プランに含まれるタスクに対応するアクションAを実行開始する時点(タイムステップT:0)での評価値は1000である。ここで、例えば所定の値を400とする。プラン生成部101Zは、評価値が400を下回ったノード(タイムステップT:1またはタイムステップT:2)から、アクションAの開始時点のノード(タイムステップT:0)へと時間遡行する分岐をプランに追加する。時間遡行する分岐は、
図30において破線状の矢印で描かれている。この時間遡行する分岐によりアクションAが取り消され、制御対象キャラクタに異なるアクションを選択させることができる。
【0213】
なお、アクションAの実行途中に異なるアクションBまたはアクションCに行動を切り替えるような分岐に対応する評価値は、対応するタスクが有する属性に応じて計算されてよい。
【0214】
(部分的プラン)
次に、部分的プランについて説明する。部分的プランとは、プランに含まれ得る、ある程度の流れが決まっているタスクの集合を意味する。部分的プランは、例えば有向非巡回グラフ(DAG)で表現されることがある。
【0215】
図31は、本発明の実施形態の少なくとも一つに対応する部分的プランを例示する概念図である。ここでは、稜線射撃という部分的プランを例示する。部分的プランである稜線射撃は、プラン生成部101Zが生成するプランの一部に含まれ得る。
【0216】
部分的プランである稜線射撃は、以下の部分タスクから構成されている。
・狙撃ポイントを特定
・狙撃ポイントに移動
・狙撃ポイントで待機
・敵が来たら狙撃
・敵に回り込まれたら、狙撃ポイントから退避
【0217】
上記の複数の部分タスクのうち、「敵か来たら狙撃」という部分タスクが、部分的プラン「稜線射撃」の中の代表となるタスク(代表タスク)に相当する。
【0218】
なお、代表タスクとは、部分的プランを代表するタスクを意味する。代表タスクが部分的プランに複数含まれてもよい。
【0219】
図32は、本発明の実施形態の少なくとも一つに対応する、部分タスクに対応する狙撃ポイントの候補を示す概念図である。図示したように、ゲーム内において制御対象キャラクタが移動可能な狙撃ポイントは複数存在し得る。全ての狙撃ポイントを候補点としてシミュレータ110によるシミュレーションを行うのは、処理負荷が大きい場合がある。そこで、部分的計画が効果的な部分的計画かどうかを事前に判断して、枝狩りを行うことが考えられる。
【0220】
すなわち、プラン生成部101Zは、複数のタスクにより構成される部分的プランに含まれる一以上の代表タスクについての代表評価値を算出し、代表タスクについての評価が高くなるような部分的プランについての評価値を算出する。
【0221】
例えば部分的プラン「稜線射撃」の代表タスクが「敵が来たら狙撃」である上記の例のように、代表タスクは部分的プランの中心的なタスクであってよい。
【0222】
同じ部分的プランであっても、異なるタスクが代表タスクになることがある。例えば、敵キャラクタへの攻撃の成否に着目する場合、部分的プラン「稜線射撃」の代表タスクは「敵が来たら狙撃」となる。敵キャラクタに発見されずに済むか否かに着目する場合、部分的プラン「稜線射撃」の代表タスクは「狙撃ポイントに移動」となり得る。
【0223】
代表評価値は、値が大きいほど評価が高いものであっても、値が小さいほど評価が高いものであってもよい。
【0224】
図33は、本発明の実施形態の少なくとも一つに対応する、代表評価値の算定と枝刈りを例示する概念図である。タイムステップT:0において、制御対象キャラクタが移動を開始する。移動の目標位置(狙撃ポイント)に応じて、タイムステップT:1における3つの分岐が発生する。
【0225】
ここで、部分的プランは「稜線射撃」であり、代表タスクは「敵が来たら狙撃」であるとする。代表評価値は、値が大きいほど評価が高いものであると仮定する。また、代表タスクについての評価が高いか否かを分ける所定の閾値が400であると仮定する。
【0226】
プラン生成部101Zは、狙撃ポイントA、BおよびCの各々に対する、代表タスク「敵が来たら狙撃」についての代表評価値を算出する。
【0227】
狙撃ポイントAに対する代表タスク「敵が来たら狙撃」についての代表評価値は200である。狙撃ポイントBに対する代表タスク「敵が来たら狙撃」についての代表評価値は1200である。狙撃ポイントCに対する代表タスク「敵が来たら狙撃」についての代表評価値は300である。代表評価値が所定の閾値である400より小さい狙撃ポイントAおよび狙撃ポイントCについては枝刈りを行う。すなわちプラン生成部101Zは、狙撃ポイントAまたは狙撃ポイントCで「敵が来たら狙撃」するという分岐については、それ以降のタスク展開を行わない。
【0228】
代表評価値が所定の閾値である400より大きい狙撃ポイントBについては枝刈りを行わない。つまり、狙撃ポイントBで「敵が来たら狙撃」するという分岐については、それ以降のタスク展開を行う。
【0229】
そして、プラン生成部101Zは、代表タスクについての評価が高くなるような部分的プランについての評価値を算出する。上記の例では、狙撃ポイントBで狙撃を行うような部分的プラン「稜線射撃」についての評価値を算出する。プラン生成部101Zは、部分的プランについての評価値に基づいてプランを生成してよい。
【0230】
これにより、実行価値のあるタスクに絞ってタスク展開を行うことができるので、処理負荷を抑えることができる。
【0231】
第7の実施形態の一側面として、階層型タスクネットワークに基づいて、環境の変化に柔軟に対応できるようなプランニングを行うことができる。
【0232】
第7の実施形態の一側面として、タスクの実行主体(例えば制御対象キャラクタ)の制御を柔軟に行うことができる。
【0233】
第7の実施形態の一側面として、制御対象キャラクタに、大まかなプランに沿いながらも、プラン実行時の環境にあったタスクを効率的に実行させることができる。
【0234】
第7の実施形態の一側面として、プラン生成はロジカルな推論に基づいて行われていたところ、シミュレーションを行うことにより、タスク実行に応じた状況の変化を予測した上でプランニングを行うことができる。
【0235】
第7の実施形態の一側面として、シミュレータ110によるタスクの仮実行を高速で行うことができ、プラン生成部101Zがプランを迅速に生成することができる。
【0236】
第7の実施形態の一側面として、制御対象キャラクタ以外のオブジェクト(例えば敵キャラクタ)に起因した環境の変化にも柔軟に対応できるようなプランニングを行うことができる。
【0237】
第7の実施形態の一側面として、プラン生成部101Zがタスクを展開する際にステート数が膨大になる事を防ぐことができる。
【0238】
第7の実施形態の一側面として、リアルタイム性のある環境において、制御対象キャラクタに異なるアクションの実行を選択させることができる。
【0239】
第7の実施形態の一側面として、実行価値のあるタスクに絞ってタスク展開を行うことができる。そのため、処理負荷を抑えることができる。
【0240】
(実装例)
以下、本発明の実施形態の少なくとも一つに対応するプラン処理プログラムについて、実装例を示す。なお、本開示の範囲を実装例に限定する意図はない。
【0241】
本発明の実施形態の少なくとも一つに対応するプラン処理プログラムは、プランニングの手法(HTN)に状態空間探索を融合させている。従来型のプランニング手法であるHTNは、記号表現された離散的な状態空間を探索し、出力された行動リストを順番に実行するだけのものであった。一方、本発明の実施形態の少なくとも一つに対応するプラン処理プログラムにおいては、プラン生成部101Zが、ゲーム(キャラクタがタスクを実行し得る空間)に近い状況を再現したシミュレータを用いて状態空間を探索する。
【0242】
プラン生成部101Zが生成するプランにはタスクが含まれる。本発明の実施形態の少なくとも一つにおいて、タスクはプリコンディション(precondition)関数とシミュレート(simulate)関数とを有する。なお、タスクはEffectを持たないようにしてもよい。プリコンディション関数は、そのタスクが実行可能であるか否かを判定するための関数である。シミュレート関数は、そのタスクのシミュレーションを行うための関数である。
【0243】
以上のような構成とすることにより、プラン生成部101Zがプランを生成する際に、連続値の変化(例えば制御対象キャラクタの体力値、位置座標、射撃武器の残弾数など)を探索することができるようになる。
【0244】
シミュレータは、1シミュレーションステップごとに所定のゲーム内時間を更新する。そしてシミュレータは、1シミュレーションステップあたり1ノードのゲーム木で表現できるように、制御対象キャラクタの行動(アクション)を離散化する。
【0245】
次に、プランの実装例を説明する。
図34は、本発明の実施形態の少なくとも一つに対応する、プランの実装例を例示する概念図である。プラン生成部101Zは、ゲーム木に近い構造を有する、例えば
図34に示されているようなプラン木を出力(生成)する。
【0246】
プラン木に含まれる各ノードは、シチュエーションとタスクとを有している。これは、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランにおいて、シチュエーションがタスクに付加されていると解釈することができる。また、
図34に示されているような、シチュエーションとタスクとを組み合わせて生成されたプラン木を、以下、シチュエーションタスクネットワーク(Situation-Task Network)と表現する。
【0247】
シチュエーションタスクネットワークは、状態(シチュエーション)が複数接続されてネットワーク構造を呈しているため、状態空間であると解釈することができる。この実装例における状態空間探索とは、このシチュエーションタスクネットワークにおけるノードを探索することを意味する。状態空間探索を行う主体は、例えばプラン生成部101Zである。プラン生成部101Zはシミュレータを用いて、シチュエーションタスクネットワークに含まれるタスクを仮実行して評価値を得ることにより、状態空間探索を行ってよい。
【0248】
シチュエーションは、ゲーム空間の簡略化されたモデルを意味する。シチュエーションは、ゲーム空間における簡略化されたデータを含む。例えば、制御対象キャラクタの位置、体力値、敵対的なAIエージェントのステートIDなどの内部コンディションは、シチュエーションが含む簡略化されたデータの一例である。
【0249】
シチュエーションは、先行するシチュエーションおよび/または後続するシチュエーションへのリンクを有する。その結果、プラン木はグラフを形成する。
【0250】
タスクには、プリミティブタスク(Primitive Task)とコンポジットタスク(Composite Task)が含まれる。コンポジットタスク(Composite Task)は、コンパウンドタスク(Compound Task)と呼ばれることもある。
【0251】
本発明の実施形態の少なくとも一つに対応する実装例において、プリミティブタスクはシンプルなアクションタスクに相当する。アクションタスクは、プリコンディション(precondition)関数とシミュレート(simulate)関数とを持つ。
【0252】
本発明の実施形態の少なくとも一つに対応する実装例において、コンポジットタスクは、プリミティブタスクよりも複雑なアクションに対応する。実装例において、コンポジットタスクを2つの基本タイプに分けた。ただし、これはあくまで実装例であり、コンポジットタスクを1つのタイプにすることを排除する意図はない。
【0253】
コンポジットタスクの第1の基本タイプは、FSMタスクである。なお、FSMは、有限状態機械(Finite State Machine)の略語である。FSMタスクは、敵キャラクタなどの、制御対象キャラクタとは異なるキャラクタの振る舞いのモデルとして使用可能である。
【0254】
コンポジットタスクの第2の基本タイプは、ステップタスクである。ステップタスクは、きわめてシンプルな構造を有するFSMである。ステップタスクは、ビヘイビアツリーのシーケンスノードとほぼ同様のものである。しかしながら、ステップタスクは、簡単な1以上のループや、複数のブランチを有することができる。
【0255】
次に、処理負荷やノード数を削減するための工夫について説明する。ゲーム全体の状態探索では探索範囲が広すぎる場合、シミュレータは、制御対象キャラクタの付近に存在する全てのキャラクタや動的に動くオブジェクトの変化に絞ってシミュレーションを行ってよい。
【0256】
通常のゲーム木探索を適用する場合、ノード数が指数的に増大する可能性がある。本発明の実施形態の少なくとも一つに対応するプラン処理プログラムの場合、上述のプラン木においてHTNの考え方を活用してノード数の増加を抑えることができる。より具体的には、シミュレータがコンポジットタスクを実行できるようにする。コンポジットタスクは入れ子構造になっており、複数のサブタスクで構成されている。サブタスクは、コンポジットタスクまたはプリミティブタスクである。コンポジットタスクをサブタスクに分解する機能をシミュレータが有していてよい。プラナー(プラン生成部101Z)またはエグゼキュータ(プラン実行部102Z)が有するプラン分解機能を、シミュレータが間借りしてもよい。
【0257】
プラン生成部101Zは、ノードに対してコンポジットタスクが(シチュエーションと共に)配置されたプラン木を生成する。これにより、プラン生成部101Zはプラン木を完全に分解された状態で生成しなくてもよくなる。コンポジットタスクは内部的な遷移先が限定されているため、プラン木のノード数の増大を抑制することができる。
【0258】
プラン生成部101Zが行う状態空間探索において、ゲーム内での有意味な粒度の行動のみを探索することにより、ノード数の増大を抑制することもできる。
【0259】
粒度とは、データやプログラム、作業工程などの構成単位の粗さ、大きさなどを示す表現である。本発明の実施形態の少なくとも一つに対応する実装例においては、制御対象キャラクタ等が行うアクション(タスク)についての概念の大きさが、粒度の大きさに相当する。例えば、「歩く」というアクションの粒度は、「右足を前に出す」や「左足を前に出す」等のアクションの粒度よりも大きい。「右足を前に出す」というアクションの粒度は、「膝を上げる」「つま先を前に出す」「膝を下げる」等のアクションの粒度よりも大きい。概して、粒度の大きなコンパウンドタスクは、粒度のより小さなサブタスクを含んでいる。
【0260】
プラン生成部101Zが行う状態空間探索において、探索するタスクは、対象となるゲームにおける有意味な行動に相当する粒度を有するタスクに限定する。例えば、「遮蔽物の位置まで移動する」「敵に接近する」「敵から離れる」などのようなタスクが、対象となるゲームにおける有意味な行動に相当する粒度を有するタスクに相当する。すなわち、所定の大きさ以上の粒度を有するタスクに限定してプラン生成部101Zが状態空間探索を行う。これにより、探索するノードのノード数の増大を抑制することができる。また、有意味な粒度の行動しか探索しないという手法を、シミュレータを用いた状態空間探索に適用することにより、実用性の高いプラン木を生成することができる。
【0261】
さらに、プラン生成部101Zは、強化学習手法などで行われるような、最小単位の行動をランダムに選択するといった探索を行わない。これによっても、探索するノードのノード数の増大を抑制することができる。
【0262】
次に、プラン実行時の工夫について説明する。プラン実行部102Zは、シミュレータを用いた事前シミュレーションに基づいて生成されたプラン木の中から、現在の状況に近いノードを検索する。なお、現在の状況を示す各種の情報は、ワールドステートに記憶されていてよい。プラン実行部102Zは、ワールドステートから、現在の状況を示す各種の情報を取得してよい。
【0263】
プラン実行部102Zは、検索された1以上のノードうち、評価値の高いノードを選択する。プラン実行部102Zは、選択されたノードに相当する行動を制御対象キャラクタに実行させる。これにより、制御対象キャラクタは、現在の状況に合致した行動のうち、より有効なものを選んで実行することができる。
【0264】
次に、プラン木に含まれる各ノードの評価値の決定方法に係る工夫について説明する。プラン木の各ノードに対して評価値が設定されてよい。プラン生成部101Zは、シミュレータを用いたシミュレーションの最終結果(例えば勝利または敗北)から逆伝播して、プラン木の最終結果に相当するノードに至る途中のノードに評価値を反映する。これにより、プラン木の途中ノードの段階でも、その途中ノードを含む一連のタスクを実行した場合の行動の有効性(例えば勝算)を概算することができる。
【0265】
次に、シチュエーションタスクネットワーク(Situation-Task Network)に基づくシミュレーション、プランニング、プラン実行等についての実装例を説明する。
図34に示されているように、プラン木の各ノードには、シチュエーションを示す情報とタスクを示す情報の他に、複数のキャラクタを示す情報が含まれていてよい。複数のキャラクタには、制御対象キャラクタが含まれる。複数のキャラクタには、例えば敵キャラクタ等の、制御対象キャラクタ以外のキャラクタが含まれていてよい。
【0266】
プラン生成部101Zは、空間情報の一例である高さマップ上で実行されるシミュレータを用いて、シチュエーションタスクネットワークを生成する。制御対象キャラクタのアクション(つまりはタスク)を選択可能である場合、プラン生成部101Zはターミナルノードを展開して複数の分岐枝(ブランチ)を作成する。敵キャラクタに対応するモデルは、自身の振る舞いを変える時等に、一定の格率で分岐枝(ブランチ)を生成する。
【0267】
図35は、本発明の実施形態の少なくとも一つに対応するプランの実装例における、タスクの割り当て処理を例示する概念図である。ここでデシジョンメーカは、プラン生成部101Zに含まれる、タスクの割り当てを行うサブ機能である。
【0268】
タスクの割り当ては、例えば以下のようにして行われる。デシジョンメーカは、各々のキャラクタについてタスクを選択して、ターミナルシチュエーションノード(Terminal Situation Node)を展開する。デシジョンメーカは、プリコンディションがシチュエーションに合致している場合に、プリミティブタスクを割り当てることができる。
【0269】
デシジョンメーカは、プリコンディションがシチュエーションに合致している場合に、コンポジットタスクを割り当てることができる。また、デシジョンメーカは、現在のコンポジットタスクが含まれるノードにおいてタスク展開が許されている場合、現在のコンポジットタスクを展開することができる。この場合において、コンポジットタスクが含まれるノードから複数のコピーインスタンスを作成して、作成されたコピーインスタンスの内部的なステートIDを修正する。
【0270】
図36は、本発明の実施形態の少なくとも一つに対応するプランの実装例における、コンポジットタスクの展開を示す概念図である。タスクの展開前のゲーム内時間をt-1とし、タスクの展開後のゲーム内時間をtとする。FSMタスクが、ステートa、ステートb、およびステートcへの遷移を有すると仮定する。FSMタスクは、FSMタスクa~FSMタスクcへと展開され、それぞれインスタンスがコピーされる。FSMタスクがステート遷移を実行する前に、FSMタスクにおけるすべてのデータがコピーされて、タスクインスタンスのa~cのバージョンが作られる。
【0271】
各エージェントのデシジョンメーカが上記の処理を行い得る。従って、シチュエーションノードの合計数が大きなものとなる可能性がある。シチュエーションタスクネットワークのサイズを減じるための工夫の一つとして、プラン生成部101Zが有する展開ファンクションが、所定の閾値を取得する。そして例えば、展開ファンクションが乱数を生成し、乱数の値が所定の閾値を越える場合にのみ、タスクが展開される。
【0272】
次に、タスクの分解例について説明する。
図37は、本発明の実施形態の少なくとも一つに対応するプランの実装例における、タスクの分解を示す概念図である。シチュエーションタスクネットワークにより、所与のシチュエーションにおいて使用されるべきタスクが選択される。ここでいうタスクはデータであり、そのままではゲーム環境において実行できない。実行のために、エグゼキュータ(プラン実行部102Z)はタスクを、ゲーム環境において実行可能なオペレータまで分解する。
【0273】
まず、エグゼキュータはシチュエーションの分岐枝(ブランチ)を見通し、高い評価値を有するタスクを選択する。エグゼキュータは、選択されたタスクをオペレータまで分解して、オペレータを順次実行する。
【0274】
以上に説明したように、本願の各実施形態により1または2以上の不足が解決される。なお、夫々の実施形態による効果は、非限定的な効果または効果の一例である。
【0275】
上述した各実施形態では、ユーザ端末20およびサーバ10は、自己が備える記憶装置に記憶されている各種制御プログラム(例えば、プラン処理プログラム)に従って、上述した各種の処理を実行する。また、ユーザ端末20やサーバ10に限られない他のコンピュータが、自己が備える記憶装置に記憶されている各種制御プログラム(例えば、プラン処理プログラム)に従って、上述した各種の処理を実行してもよい。
【0276】
また、ビデオゲーム処理システム100および100Aの構成は、上述した各実施形態の例として説明した構成に限定されない。例えばユーザ端末が実行する処理として説明した処理の一部または全部をサーバ10が実行する構成としてもよいし、サーバ10が実行する処理として説明した処理の一部または全部をユーザ端末20が実行する構成としてもよい。また、サーバ10が備える記憶部(記憶装置)の一部または全部をユーザ端末20が備える構成としてもよい。すなわち、ビデオゲーム処理システム100および100Aにおける、ユーザ端末とサーバのどちらか一方が備える機能の一部または全部を、他の一方が備える構成とされていてもよい。
【0277】
また、プログラムが、上述した各実施形態の例として説明した機能の一部または全部を、通信ネットワークを含まない装置単体に実現させる構成としてもよい。
【0278】
[付記]
上述した実施形態の説明は、少なくとも下記発明を、当該発明の属する分野における通常の知識を有する者がその実施をすることができるように記載した。
[1]
キャラクタが実行するタスクを階層型タスクネットワークに基づいてプランニングする、プラン処理プログラムであって、
サーバに、
ゴール情報に基づいて、複数のタスクにより構成されたプランをドメインから生成する、プラン生成機能を実現させ、
前記プラン生成機能では、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する機能を
実現させるためのプラン処理プログラム。
[2]
前記サーバに、
前記プラン生成機能が生成したプランを取得し、前記プランに含まれるタスクを順次実行するプラン実行機能を実現させ、
前記プラン実行機能では、取得した前記プランの一部を変更してから、前記プランに含まれるタスクを順次実行する機能を
実現させるための[1]に記載のプラン処理プログラム。
[2-2]
前記サーバに、
前記タスクをより具体的な複数のタスクに分解するタスク分解機能をさらに実現させ、
前記プラン生成機能では、前記タスク分解機能に所定の階層までタスク分解を行わせてから前記プランを生成する機能を実現させ、
前記プラン実行機能では、前記プランに含まれるタスクの少なくとも一部を、前記所定の階層よりも深い階層までタスク分解してから、前記プランに含まれるタスクを順次実行する機能を
実現させるための[2]に記載のプラン処理プログラム。
[3]
前記プラン生成機能では、前記ドメインに含まれる複数の選択可能なタスクをシミュレータにより仮実行して評価値を計算し、前記ゴール情報と前記評価値とに基づいて前記プランを生成する機能を
実現させるための[1]から[2-2]のうちいずれか一項に記載のプラン処理プログラム。
[3-2]
前記プランは、前記キャラクタがタスクを実行し得る空間に対応する第1の空間情報を用いて前記タスクを実行するものであり、
前記シミュレータは、前記空間に対応する第2の空間情報を用いて前記選択可能なタスクを仮実行するものであり、
前記第2の空間情報は、前記第1の空間情報よりも情報量が少ない、
[3]に記載のプラン処理プログラム。
[4]
前記プラン生成機能では、前記ゴール情報と、前記キャラクタ以外のオブジェクトのタスク実行、アクションまたは状態変化とに基づいて、前記プランを前記ドメインから生成する機能を
実現させるための[1]から[3-2]のうちいずれか一項に記載のプラン処理プログラム。
[5]
前記プラン生成機能では、先行するタスクから後続するタスクへと接続する枝の優先度を、前記後続するタスクの評価値に応じて決定し、前記枝の優先度に基づいて前記プランを生成する機能を
実現させるための[1]から[4]のうちいずれか一項に記載のプラン処理プログラム。
[6]
前記プラン生成機能では、タスクに対応するアクションを前記キャラクタが実行すると前記アクションの評価値が所定の値よりも低くなる場合、前記アクションを取り消すための分岐を前記プランに追加する機能を
実現させるための[1]から[5]のうちいずれか一項に記載のプラン処理プログラム。
[7]
前記プラン生成機能では、複数のタスクにより構成される部分的プランに含まれる一以上の代表タスクについての代表評価値を算出し、前記代表タスクについての評価が高くなるような部分的プランについての評価値を算出する機能を
実現させるための[1]から[6]のうちいずれか一項に記載のプラン処理プログラム。
[8]
[1]から[7]のうちいずれか一項に記載のプラン処理プログラムが前記サーバに実現させる機能のうち少なくとも1つの機能を、当該サーバと通信可能なユーザ端末に実現させるためのプログラム。
[9]
[1]から[7]のうちいずれか一項に記載のプラン処理プログラムがインストールされたサーバ。
[10]
通信ネットワークと、サーバと、ユーザ端末とを備え、キャラクタが実行するタスクを階層型タスクネットワークに基づいてプランニングする、タスク処理システムであって、
ゴール情報に基づいて、複数のタスクにより構成されたプランをドメインから生成する、プラン生成手段を含み、
前記プラン生成手段では、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する、
タスク処理システム。
[11]
キャラクタが実行するタスクを階層型タスクネットワークに基づいてプランニングする、プラン処理プログラムであって、
ユーザ端末に、
ゴール情報に基づいて、複数のタスクにより構成されたプランをドメインから生成する、プラン生成機能を実現させ、
前記プラン生成機能では、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する機能を
実現させるためのプラン処理プログラム。
[12]
[11]に記載のプラン処理プログラムがインストールされたユーザ端末。
[13]
キャラクタが実行するタスクを階層型タスクネットワークに基づいてプランニングする、プラン処理プログラムであって、
コンピュータ装置に、
ゴール情報に基づいて、複数のタスクにより構成されたプランをドメインから生成する、プラン生成機能を実現させ、
前記プラン生成機能では、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する機能を
実現させるためのプラン処理プログラム。
[14]
キャラクタが実行するタスクを階層型タスクネットワークに基づいてプランニングする、コンピュータ装置によるタスク処理方法であって、
ゴール情報に基づいて、複数のタスクにより構成されたプランをドメインから生成する、プラン生成処理を含み、
前記プラン生成処理では、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する、
タスク処理方法。
[15]
キャラクタが実行するタスクを階層型タスクネットワークに基づいてプランニングする、通信ネットワークと、サーバと、ユーザ端末とを備えるシステムによるタスク処理方法であって、
ゴール情報に基づいて、複数のタスクにより構成されたプランをドメインから生成する、プラン生成処理を含み、
前記プラン生成処理では、状態または条件に応じて採用されるべき後続タスクが変わるように構成されたプランを生成する、
タスク処理方法。
【産業上の利用可能性】
【0279】
本発明の実施形態の一つによれば、階層型タスクネットワークに基づいて、環境の変化に柔軟に対応できるようなプランニングを行うことができるプラン処理プログラムおよびプラン処理システムとして有用である。
【符号の説明】
【0280】
10、10A、10B、10C、10D、10Z サーバ
11 プロセッサ
12 メモリ
13 記憶装置
20、20A、20B、20C、20X ユーザ端末
21 プロセッサ
22 メモリ
23 記憶装置
30 通信ネットワーク
100、100A ビデオゲーム処理システム
101、101C、101D、101Z、201、501 プラン生成部
102、102Z プラン実行部
103Z タスク分解部
110、110Z シミュレータ