JP7078596B2 - 画像生成プログラム、画像生成処理装置及び画像生成方法 - Google Patents

Description

本発明は、画像生成プログラム、画像生成処理装置及び画像生成方法に関する。

コンピュータ上で動作するゲームでは、複数のキャラクタが対戦を行う激しいいアクションにおいてキャラクタが攻撃するシーンが存在する。

攻撃シーンなどキャラクタ同士の接触するイベントにおいては、あらかじめ定められたアニメーションデータを用いてキャラクタに対して一連の動作を行わせることで、所望のシーンの画像を生成することが行われている。

このような複数のキャラクタに対して、一連の動作を行わせるアニメーションデータは、複数のキャラクタのそれぞれの大きさ、体型、姿勢などがアニメーションデータの想定と異なる場合には、適切なタイミングで、キャラクタの部分同士がヒットせず、適切なシーンが再現できないことがある。
このような不都合を解消するための従来技術としては、例えば以下のものが挙げられる。

一連の動作における攻撃がヒットするであろうタイミングを示す所定タイミングと、この所定タイミングにおけるキャラクタの姿勢と、攻撃対象のゲーム内座標とに基づいて、キャラクタの背骨の角度の補正の度合いを算出する算出機能を有しており、さらに、この度合いに基づいたキャラクタの背骨の角度の補正に応じてキャラクタの姿勢を補正する。そして、補正されたキャラクタの姿勢においてキャラクタが一連の動作を実行した際に、所定のタイミングにてキャラクタの攻撃が攻撃対象にヒットする様子が表現されるようにアニメーションを補正するビデオゲーム処理プログラムの技術が存在する（例えば、特許文献１参照）。

また、一方のキャラクタが他方のキャラクタに打撃武器等を用いて攻撃を行う場合、よりリアルな攻撃態様を創出するために、攻撃相手である他のキャラクタの回避行動（しゃがむ等）や弱点部位（頭部が弱点であるのか脚部が弱点であるのか等）に応じて武器の軌道を変更する必要がある。このために、キャラクタの所定部位が所定の仮想基準平面または仮想基準線分上を移動するような基本軌道を表す基本軌道データを取得する。基本軌道データを取得し、仮想基準平面または仮想基準線分の角度を変更することにより基本軌道を修正した修正軌道を生成して、修正軌道を移動する所定部位を起点にして関節モデルの各関節の位置および姿勢を決定することで、攻撃対象位置が異なっても、同じアニメーションデータの流用を可能とする技術が存在する（例えば、特許文献２参照）。

特許第６１５３９８５号公報 特許第６３１０５１７号公報

開示の技術は、複数のキャラクタに対して、アニメーションデータを適用する場合において、複数のキャラクタの大きさ、体型又は姿勢などが異なっていても、アニメーションデータを適切に適用して、複数のキャラクタに適切な一連の動作を行わせることを目的としている。

開示の技術によって、ゲーム空間での複数のキャラクタによる対戦における攻撃のヒットのタイミングを含むシーンで、所定のキャラクタと、前記対戦の相手キャラクタと、少なくとも前記相手キャラクタに前記対戦の動作を行わせるアニメーションデータとから、前記ヒットが発生することとなる前記所定のキャラクタの所定部分と前記相手キャラクタの相手部分と前記ヒットのタイミングとを特定するステップと、前記ヒットのタイミングでの前記相手部分から前記所定部分までのベクトルを計算するステップと、前記ヒットのタイミングで、前記相手部分が、前記所定部分にヒットするように、前記シーンに含まれる複数のフレームの各々に対して、前記ベクトルを用いて前記相手部分の位置を移動させることで、前記シーンの画像を生成するステップと、をゲーム装置に実行させる画像生成プログラムが提供される。
加えて、開示の技術によって、画像生成処理装置及び画像生成方法が提供される。

開示の技術によれば、複数のキャラクタに対して、アニメーションデータを適用する場合において、複数のキャラクタの大きさ、体型又は姿勢などが異なっていても、アニメーションデータを適切に適用して、複数のキャラクタに適切な一連の動作を行わせることができる。

図１は、一実施形態のハードウエア構成の一例を示した図である。 図２は、キャラクタの体型モデルの例を示した図である。 図３は、キャラクタ、アニメーションデータ、ヒットにおけるキャラクタの部分などの関連を定義する表の例を示した図である。 図４は、一実施形態の機能ブロック図の例を示した図である。 図５は、実施形態１の処理のフローチャートを示した図である。 図６は、実施形態１の画像生成処理の具体例のフローチャートを示した図である。 図７は、実施形態１の画像生成処理の他の具体例のフローチャートを示した図である。 図８は、実施形態１の複数のヒットが略同時に発生したときの具体例のフローチャートを示した図である。 図９は、キャラクタの姿勢を修正するフローチャートを示した図である。 図１０は、複数のヒットが連続して発生した時の処理を示す図である。 図１１は、基準キャラクタと実キャラクタの違いによりヒットが発生しない例を示した図である。 図１２は、実施形態１の具体例を示した図である。 図１３は、実施形態１の具体例を示した図である。 図１４は、実施形態１の変形例を示した図である。 図１５は、相手キャラクタの両足を固定してＩＫを適用して実施形態１の変形例の各タイミングを示した図である。 図１６は、実施形態２の処理のフローチャートを示した図である。 図１７は、実施形態２の画像生成処理の具体例のフローチャートを示した図である。 図１８は、実施形態２の具体例を示した図である。 図１９は、実施形態１の変形例の各タイミングを示した図である。

以下に説明する各種の実施形態は、各請求項に規定された発明を例示するためのものであって、限定するためのものではない。各実施形態のプログラムの手順は、方法の手順にも適用できる。また、プログラムは、一時的でない（non-transitory）記憶媒体に格納され得る。また、プログラム及び方法を実現する各手順は、矛盾の無い限り、順番を入れ換えたり、同時に実行したりすることができる。また、プログラムの一部は、汎用的なオペレーティングシステム又はハードウエアなどで実現されてもよい。
また、各実施形態は、それぞれが排他的なものではない。したがって、一方の実施形態の一部を他方の実施形態に組み入れることも意図されている。
各実施形態は、ゲームの画像を生成するための具体的な技術的要素により定義される。

また、実施形態における各種のキャラクタは、プレイヤーが操作できるプレイヤーキャラクタであってもよいし、プレイヤーが操作できないノンプレイヤーキャラクタであってもよい。二つ以上のキャラクタにより対戦の画像生成を実現する各実施形態では、プレイヤーからの操作を画像生成に反映させるように、少なくとも１つのキャラクタは、プレイヤーが操作可能なプレイヤーキャラクタであることが望ましい。

また、以下に説明する各実施形態では、説明に一貫性を持たせ、分かりやすくするために、複数のキャラクタのうち「相手キャラクタ」と称されるキャラクタが攻撃を行うキャラクタであるとして説明を行う。しかしながら、開示の技術は、必ずしも相手キャラクタが攻撃を行うキャラクタであることに限定されないことは言うまでもない。

また、キャラクタに一連の動作を行わせるアニメーションデータは、複数のキャラクタのうちの少なくとも１つのキャラクタに対して適用されればよい。したがって、対戦に関連する複数のキャラクタのうちの一部のキャラクタはアニメーションデータの適用を受けなくてもよい。

また、実施形態では、「ヒット」という言葉を用いる。ヒットとは、少なくとも２つのキャラクタの各々の一部の部分が接触または接近し、一方のキャラクタから他方のキャラクタにインパクト（影響）を与えることを言う。このヒットが発生するときを、ヒットのタイミングという。

実施形態では、後述するスケルトンモデルを用いて説明を行う。スケルトンモデルにおいて、ヒットは、一方のキャラクタの骨又は関節が、他方のキャラクタの骨又は関節に接触する場合に限定されない。ヒットは、キャラクタの重心、骨から一定の距離だけ離れた体表部分、及び衣服の部分など、骨又は関節が存在しないキャラクタの部分であってもよい。したがって、以下の説明におけるキャラクタの「部分」とは、キャラクタの骨又は関節の一部でなくてもよい。なお、部分は、キャラクタ全体であってもよいし、キャラクタの特定の部分ではなく、どの部分であってもよいと定義されていてもよい。
また、実施形態は、スケルトンモデルに限定されず、スケルトンモデル以外のモデルに対しても適用され得る。

なお、部分が骨の部分を示している場合、ヒットのタイミングで一方のキャラクタの骨と他方のキャラクタの骨とを接触させて画像生成を行うと、二つのキャラクタの体表部分同士がめり込む不自然な画像が生成されてしまうことがある。このような不自然な画像を生成させないように、二つのキャラクタの表面が接触した時点で、キャラクタ同士の体が重ならない（めり込まない）ようにキャラクタの動作が制御されてもよい。このような制御は、骨から体表までの距離のデータを、キャラクタを定義するデータが持っていることにより実現できる。なお、このような制御を行わせるか否かは、利用するマシンの能力に依存して、当業者が適宜決定すればよい。説明をわかりやすくするために、このような、キャラクタ同士の重なりについては以下の説明においては言及しないが、当然に考慮される事項であることは言うまでもない。

以下、図面を参照しながら説明する。各図において、同じ構成又は同様の構成には、同じ符号が付されている。説明を簡略化して分かりやすくするために、同じ符号が付された構成に対して、繰り返し同じ説明を省略する場合があることに留意すべきである。

図１は、一実施形態のハードウエア構成の一例を示した図である。ゲーム装置１００において本実施形態が実現される。なお、ゲーム装置の一部のプログラム又は方法は、ネットワークＮＷ１４０を介して接続されたサーバ装置１５０によって実行されてもよい。

ゲーム装置１００は、ＣＰＵ１０２、ＲＡＭ１０４、ＲＯＭ１０６、表示制御部１０８、オーディオ制御部１１２、外部記憶制御部１２０、コントローラインタフェース部１２２、タッチパネルインタフェース部１２４、ネットワークインタフェース部１２６を備える。
表示制御部１０８には、ディスプレイ１１０が接続され、本実施形態において生成された画像が表示される。

オーディオ制御部１１２には、マイク１１４及びスピーカ１１６等が接続される。ＲＡＭ１０４、ＲＯＭ１０６、外部記憶制御部１２０に接続されたメモリカード１３０及びＤｉｓｋ１３２には、本実施形態を実現するプログラム及びデータが格納され得る。なお、外部記憶制御部１２０には、その他の記憶装置（不図示）が接続されてもよい。また、本実施形態を実現する一部のプログラム、或いはデータは、サーバ装置１５０内に格納されていてもよい。
コントローラインタフェース部１２２には、プレイヤーからの操作指示を受け付けるコントローラ（不図示）が接続され得る。

タッチパネルインタフェース部１２４には、ディスプレイ１１０などに設置されたタッチセンサ１３４が接続される。タッチセンサ１３４を介して、プレイヤーからの操作指示が受け取られてもよい。

ネットワークインタフェース部１２６には、ネットワークＮＷ１４０が接続される。ネットワークＮＷ１４０は、電話回線、ＷＩＦＩ、近距離無線通信装置などが接続され、インターネットなどへのアクセスが実現される。ネットワークＮＷ１４０には、サーバ装置１５０、他のプレイヤーのゲーム装置１６２などが接続され得る。ゲーム装置１００は、ネットワーク１４０を介して、サーバ装置１５０及び複数のゲーム装置１６２と通信を行うことができる。本実施形態の一部は、サーバ装置１５０又はゲーム装置１６２の中で実現されてもよい。ゲームにおけるキャラクタの一部は、他のプレイヤーがゲーム装置１６２を操作することで、ゲーム装置１００内で動きなどの種々の挙動が制御されてもよい。このようにすることで、ゲーム装置１００において、複数のプレイヤーによってそれぞれのキャラクタが操作されて、対戦ゲームの画像が生成されてもよい。
ＣＰＵ１０２は、ＲＡＭ１０４、ＲＯＭ１０６、メモリカード１３０又はＤｉｓｋ１３２に格納されたプログラムを実行することができる。
図１に示されたハードウエア構成は、実施形態の主要なハードウエアを例示するものであって、これらのハードウエア以外のハードウエアが接続されてもよい。

図２は、ゲームプログラムが制御するキャラクタの例として、スケルトンモデルが例示されている。図２のスケルトンモデルは、人間の形を表しているが、キャラクタは、人間の形に限定されない。例えばキャラクタが動物である場合には、動物のスケルトンモデルが用いられてもよい。キャラクタは建物或いは物体などであってもよい。

キャラクタ等を動かす際に，複数の骨２００ａを関節２００ｂで繋いだスケルトンモデル（骨格モデル）（図２）が使われる場合がある。このようなスケルトンモデルは，仮想空間ばかりでなく，ロボット制御等の実空間における対象物を制御する場合にも用いられ得る。

本明細書で扱うモデルは，図２のように親子関係で繋がった複数の骨２００ａ、関節２００ｂ及び体表２００ｃで構成される。関節の回転（曲げ，捻り）の状態は，親骨を基準とした子骨の向きで表すことができる。骨の向きを表すために，各々の骨に対しては座標系（不図示）が定められる。親子関係にある骨の原点同士を結ぶ線分は骨となる。

三次元（３Ｄ）仮想空間又は実空間上でキャラクタ（人体，動物，構造物等）の姿勢（ポーズ，動き等）を制御する際に用いられるこのようなスケルトンモデルにおいては，図２に示す各々の骨および関節の位置，角度，回転（曲げ，捻り）等を意図したとおりに制御することが必要となる。図２に示されるスケルトンモデルでは，各々の骨は関節で結合されており，各々の骨の動きが他の骨の動きに影響を与える。

本実施形態では、例示として，図２のスケルトンモデルを用いた場合を想定する。このスケルトンモデルは，人体の構造、動物及び構造物等をスケルトンモデル化したものである。したがって，例えば，肘から先の腕の可動範囲には，一定の制限がある。この制限を超えた角度（曲げ，捻り）に腕を曲げるポーズを取らせることは，現実の人間又は動物に対するモデルからかけ離れたものになる。人間又は動物として自然なポーズを取るスケルトンモデルを生成するためには，たとえば肘の関節から先の骨の可動範囲に対して，一定の制限を課すことが必要となる。

たとえば親骨（親骨）に対する子骨（子骨）の向きを親骨の座標系を基準とした３軸（ｘ，ｙ，ｚ）の各軸回りの回転角度で表現してキャラクタの動作の制御が行われてもよい。

関節を中心点とする球面上の所与の点を焦点とし，関節に対応する中心点と焦点とを結ぶ軸に直交する平面を射影面とし，関節の可動範囲を，射影面上において設定してもよい。

或いは、子骨の向きが，予め定められた可動範囲内に収まっていない場合、あるキャラクタの腕が、他のキャラクタの体内にめり込んでしまうなどの不自然な状況が発生する場合には，可動範囲の形状に応じた条件を満たすように、骨又は関節から体表までの距離を保持しておき、前記親骨に対する前記子骨の向きを補正してもよい。

本実施形態において説明するアニメーションデータは、このスケルトンモデルの骨及び関節における種々のパラメータ等を時間軸と共に記憶しているデータである。同じスケルトンモデル又は類似のスケルトンモデルを持つキャラクタには、同じアニメーションデータが適用できる。スケルトンモデルが完全に一致しないキャラクタに対しても、一部の骨及び関節を一体化して取り扱ったり、制御対象から無視したりすることで、異なる体型、異なる初期ポーズ、異なる大きさのキャラクタに同じアニメーションデータを適用して、異なるキャラクタに対して、同様の一連の動作を行わせて、シーンの画像を生成することができる。
なお、本実施形態は、図２のスケルトンモデル以外のモデルにも適用できることは言うまでもない。
図２の機能ブロック構成によって、以下に示す実施形態の処理が実行される。

図３は、キャラクタ、アニメーションデータ、ヒットにおけるキャラクタの部分などの関連を定義する定義表３００の例を示した図である。
図３の表３００において、例えば基準キャラクタＣ０は、平手打ちのアニメーションの動作を行うことができ、そのアニメーションデータが格納されているアドレスのロケーションに付けられたラベルは、「平手打ち」であることが分かる。また、平手打ちの動作を行われる際の基準キャラクタＣ０が平手打ちのヒットを受ける部分（基準部分）は、右手のひらであり、相手キャラクタの相手部分は、右手のひらであることが分かる。この場合には、相手キャラクタが平手打ちを基準キャラクタに与える場合を定義している。その他のエントリも、各キャラクタの動作等を定義しているが、具体的な説明は省略する。

また、仮想カメラのアニメーションデータが格納されているメモリ上のロケーションのラベルはカメラ３であることが分かる。また、仮想カメラのアニメーションデータには、基準キャラクタ或いは相手キャラクタのいずれに追随するかの情報が格納されていてもよい。或いは仮想カメラは、キャラクタの位置に依存せずに固定されている旨のデータが格納されていてもよい。
また、平手打ちのヒットのタイミングは、シーンの開始から０．２３秒後であることが分かる。

なお、アニメーションデータは、ヒットの後におけるキャラクタのアニメーションが含まれていてもよい。或いは、ヒットの後の各キャラクタの動作は、キャラクタに対するインパクトの大きさ、重力、風などの環境をシミュレーションすることで、実現されてもよい。本明細書では、ヒットまでの画像生成に関する技術を主として説明することとし、ヒットの後の各キャラクタの動作や挙動については、当業者が適宜に選択して実施することができる。

図３の表３００は、以上のように、各キャラクタのアニメーションデータ、ヒット時における各キャラクタのヒットする部分の位置、仮想カメラ、ヒットのタイミングなどの関連性を定義している。なお、表３００に格納されるデータは以上のデータに限られるものではない。また、表３００に示されているデータが必ず存在しなければならないわけではない。例えば、ヒットのタイミングは、モーションデータにおいて、基準キャラクタ又は相手キャラクタ部分の動作が一番大きくなるタイミングをヒットのタイミングと特定してもよい。

表３００の例示では、各部分が具体的に定義されているが、ヒットする部分がキャラクタの体のどの部分であってもよい場合には、具体的な部分が指定されていなくてもよい。

また、各キャラクタの骨格モデルの形式が定義されていてもよい。同じ骨格モデル又は似た骨格モデルを持つ実キャラクタに基準キャラクタに関連付けられたモーションデータが利用できることは言うまでもない。

図４は、画像生成装置に関する一実施形態の機能ブロック図４００の例を示した図である。アニメーションデータテーブル４０２は、シーンに関連する１つ又は複数のキャラクタの一連の動作を定義するアニメーションデータを定義している。アニメーションデータは、二つのキャラクタが対戦を行う場合、二つのキャラクタの両方の一連の動作を定義してもよい。或いは、片方（例えば攻撃側のキャラクタ）だけに対するアニメーションデータが定義されていてもよい。この場合、アニメーションデータが定義されていないキャラクタは、静止しているか、重力及び風などの環境の影響、プレイヤーの指示等によって動いてもよい。なお、以下に述べる実施形態では、ヒットが適切な部分に適用されるように、アニメーションデータ以外の要因での動作を禁止してもよい。或いは、アニメーションデータ以外の要因での動作を考慮して、アニメーション動作が変更されても、その変更に追随または相殺するようにすることで、ヒットの位置が、ずれないようにしてもよい。以下に述べる各実施形態及びその変形例は、アニメーションデータ以外の動作要因を考慮しているものと、考慮していないものがある点に留意すべきである。この点については、各実施形態及びその変形例を説明する際にも言及する。

基準キャラクタデータテーブル４０４、実キャラクタデータテーブル４０６、相手キャラクタデータテーブル４０８は、それぞれのキャラクタの骨格モデルの種別、骨格の周りの体型及び服などの着衣している物を定義している。なお、基準キャラクタ及び実キャラクタは、下記の実施形態において、「所定のキャラクタ」と明記される場合がある点に留意すべきである。

図４における特定部４１０は、シーンの画像が生成される前に、モーションデータ、関与するキャラクタ、キャラクタのヒットのする部分、ヒットのタイミング等を特定する。少なくともこれらの情報を特定することで、所望のシーンの画像が生成される。

画像生成部４２０は、ベクトル計算部４２２、移動部４２４、アニメーションデータ適用部４２６を含む。ベクトル計算部４２２は、ヒットに関与する基準キャラクタの部分と実キャラクタ部分が異なる位置ベクトルに存在することを把握するために、それぞれの位置ベクトルとの差分ベクトルを計算する。また、計算された差分ベクトルをヒットまでのシーンに含まれるタイミングに適用するために、差分ベクトルをタイミングに応じて按分するなどの計算も行うことができる。

移動部４２４は、例えば、ベクトル計算部４２２で計算されたベクトルにヒットの部分の位置ベクトルを加えたり引いたりすることによって、ヒットの部分の位置を移動させるなどの処理を行う。

アニメーションデータ適用部は、アニメーションデータを単にキャラクタに適用するばかりでなく、上記の部分の移動、キャラクタの固定部分の存在などを考慮して、キャラクタの姿勢を制御することで、キャラクタに適切なアニメーションの動作を行わせる。また、仮想カメラを適切に移動させて、画像を生成する。
操作受取部４３０は、プレイヤーからの操作を受け取る。
なお、図１に示したように、ネットワークインタフェース部を介して、他の装置からの情報が考慮されることは言うまでもない。また、音響などを生成したり、外部からの音などを収集したりする機能が含まれてもよい。図４に示された機能は、主な機能を示した一例であって、本実施形態を限定するためのものではない点に留意すべきである。

＜実施形態１＞
図５は、実施形態１の処理のフローチャートを示した図である。図５を説明する前に、本実施形態１で対処する状況の例を示した図１１を説明する。
図１１は、基準キャラクタと実キャラクタの違いによりヒットが発生しない例を示した図である。
図１１（ａ）は、一連のヒットのシーンが５つのタイミングのフレームで構成されており、５つのフレームを重ねて描いている。

図１１（ａ）では、基準キャラクタＣ０に対して、相手キャラクタＤ１が右手を振り下ろして、相手キャラクタＤ１の右手のひらＤ１ｔが、基準キャラクタＣ０の右手のひらＣ０ｔにヒットする様子が示されている。

相手キャラクタＤ１が右手を振り下ろす動作が、一連の５つの相手キャラクタ（相手キャラクタＤ１０ないし相手キャラクタＤ１４）で示されている。実際の攻撃シーンは、一秒間に例えば３０フレームの映像が生成される。このため、１／２秒のヒットのシーンであっても初期フレームも含めて１６フレームの画像が生成されることになる。図１１（ａ）は、フレーム数を少なくして、５つのフレームにより簡略化して示されている点に留意すべきである。
図１１（ａ）に示されるように、アニメーションデータは、基準キャラクタ及び相手キャラクタの大きさ、体型又は姿勢などを前提に定義されている。

図１１（ｂ）は、基準キャラクタＣ０よりも体型が小さい実キャラクタＣ２と相手キャラクタＤ１とに対してアニメーションデータを適用した例を示している。この場合には、実キャラクタＣ２が基準キャラクタＣ０よりも小さい体系であるため、実キャラクタＣ２の右手のひらＣ２ｔに、相手キャラクタＤ１の右手のひらＤ１ｔがヒットしていない。

図１１に示すように、本明細書における各実施形態は、アニメーションデータを適用してもヒットするべきキャラクタの部分同士がヒットしない場合など、アニメーションデータの適用の際に発生する不都合を解消し、適切なシーンの画像を生成することを目的の一つとしている。
図５に戻る。図５のフローチャートは、実施形態１の処理の概略を示すフローチャートである。以下に、このフローチャートの各ステップについて説明する。

ステップＳ５０２は、ゲーム空間での複数のキャラクタによる対戦における攻撃のヒットのタイミングを含むシーンにおいて、少なくとも以下の情報を特定する。すなわち、基準体型を持つ基準キャラクタと、対戦の相手キャラクタと、基準キャラクタ及び相手キャラクタのうちの少なくともいずれかに対戦の動作を行わせるアニメーションデータとから、ヒットが発生することとなる基準キャラクタの基準部分と相手キャラクタの相手部分とヒットのタイミングとが特定される。

ゲームの進行を制御するゲームプログラムによって、現在使用すべきアニメーションデータが選択される。また、シーンに登場している実キャラクタ及び相手キャラクタが少なくとも特定される。実キャラクタとは、実際にシーンに登場するキャラクタであって、アニメーションデータが基準で適用される基準キャラクタとは異なる大きさ、体型、姿勢などを持つキャラクタを言う。また、相手キャラクタとは、実キャラクタの対戦のキャラクタを言う。実施形態の理解を助けるために、相手キャラクタ自体は、アニメーションデータが基準で適用されるキャラクタであるとして説明する。しかしながら、相手キャラクタも、基準キャラクタとは異なる大きさ、体型、姿勢を有していてもよい。この場合にも、実施形態の技術がそのまま適用できることは言うまでもない。

ステップＳ５０４は、ヒットのタイミングで、基準体型と異なる体型を持つ実キャラクタの、基準部分に対応する対応部分が、相手部分にヒットするシーンが生成されるように、実キャラクタ及び相手キャラクタのうちの少なくともいずれかにアニメーションデータが適用されるときに、実キャラクタの位置又は相手キャラクタの位置を移動させてシーンの画像を生成する。なお、実キャラクタの骨格モデルは基準キャラクタの骨格モデルに対応する骨格モデルを持っており、基準キャラクタと同じアニメーションデータが実キャラクタにも適用できる。
以上の処理によって、実キャラクタの対応部分と相手キャラクタの相手部分がヒットのタイミングでヒットすることが実現される。

図１２は、実施形態１の具体例を示した図である。
図１２（ａ）に示されるように、基準キャラクタＣ０の手のひらである基準部分Ｃ０ｔから、実キャラクタＣ２の対応部分Ｃ２ｔへのベクトルＡが計算される。この場合、基準キャラクタ及び実キャラクタが、アニメーションデータにより動く場合には、ヒットのタイミングにおけるベクトルＡを計算すればよい。

なお、アニメーションデータを適用する際中に、アニメーションデータ以外の外的要因（例えば、重力、風などの環境の力、プレイヤーの動作指示など）で、キャラクタが動く場合には、実キャラクタの対応部分の動き及び相手キャラクタの相手部分の動きを考慮することが望ましい。このような場合の対処については、実施形態１の変形例において後述する。

図１２（ｂ）に示されるように、相手キャラクタＤ１のキャラクタ全体の位置ベクトルにベクトルＡを加える。このことにより、相手キャラクタＤ１の相手部分の位置ベクトルにベクトルＡが足されることとなり、相手キャラクタＤ２の相手部分の位置ベクトルに移動する。

図１２（ｃ）は、少なくとも相手キャラクタＤ２にアニメーションデータを適用して相手キャラクタＤ２が右手を振り下ろす動作が、一連の５つの相手キャラクタの動作（相手キャラクタＤ２０ないし相手キャラクタＤ２４）で示されている。

そして、ヒットのタイミングにおける実キャラクタＣ２の手のひらである対応部分Ｃ２ｔと、相手キャラクタＤ２４の手のひらである相手部分Ｄ２ｔとがヒットしている。

以上の処理を行うことによって、基準キャラクタＣ０とは大きさ、体型、姿勢などが異なる実キャラクタＣ２を用いても、相手キャラクタＤ１から相手キャラクタＤ２の移動によって、ヒットのタイミングで、適切なヒットが含まれるシーンが得られることとなる。

図１３は、図１２と異なり、実キャラクタＣ２の位置ベクトルからベクトルＡを引いた位置に実キャラクタＣ３に移動させて、実キャラクタＣ３と相手キャラクタＤ１とにアニメーションデータを適用することで、ヒットのタイミングにおける確実なヒットを実現させられることを示している。なお、図１３における各タイミングの相手キャラクタの位置は図示していないが、図１１における相手キャラクタＤ１の動作と同様であるので省略する。

なお、上記の説明における移動は、実キャラクタＣ２又は相手キャラクタＤ１のいずれかをベクトルＡだけ移動させる説明を行ったが、実キャラクタＣ２と相手キャラクタＤ１の位置が相対的にベクトルＡに基づいて移動すればよいため、両者のキャラクタが移動するようにしてもよい。

図６は、図５におけるステップＳ５０４の詳細を示すフローチャートである。以下にその詳細を説明する。
ステップＳ６０２で、（１）実キャラクタを移動させるか、（２）相手キャラクタを移動させるか、を決定する。この決定は、ゲームプログラムにおいて予め決定しておくことが望ましい。或いはプレイヤーが指定してもよい。なお、移動するキャラクタは、より小さなキャラクタである方が自然なシーンとなる場合が多い。このため、ゲームプログラムが、対戦するキャラクタのうち、小さいキャラクタの方を、移動するキャラクタに選択してもよい。

ステップＳ６０４で、アニメーションデータを用いて、ヒットのタイミングにおける基準キャラクタＣ０の基準部分から実キャラクタＣ２の対応部分へのベクトルＡを計算する。

ステップＳ６０６で、（１）実キャラクタＣ２の対応部分の位置ベクトルからベクトルＡを引いた位置ベクトルが実キャラクタＣ３の対応部分の位置ベクトルとなるように実キャラクタＣ２を実キャラクタＣ３に移動させる、又は（２）相手キャラクタＤ１の相手部分の位置ベクトルにベクトルＡを足した位置ベクトルが相手キャラクタＤ２の相手部分の位置ベクトルとなるように相手キャラクタＤ１を相手キャラクタＤ２に移動させる。

ステップＳ６０８で、追随するキャラクタ（実キャラクタ又は相手キャラクタ）の移動に対応させて仮想カメラを移動させる。仮想カメラの視線方向を変更せずに、仮想カメラを追随するキャラクタ（実キャラクタ又は相手キャラクタ）の移動と同じ移動方向に平行移動させることによって、撮像対象のシーンを仮想カメラが見失うことが防止できる。

なお、仮想カメラは、実キャラクタ又は相手キャラクタに追随させずに、広角度に撮像されている場合には、仮想カメラの移動を行うことは必ずしも必要ない場合がある点に留意すべきである。

ステップＳ６１０で、アニメーションデータを実キャラクタ及び相手キャラクタのうちの少なくともいずれかに適用して、仮想カメラを用いてシーンの画像を生成する。
以上の処理によって、適切なシーンの画像が生成される。

＜実施形態１の変形例＞
次に、上記実施形態１の変形例について説明する。実施形態１では、ヒットのタイミングにおけるベクトルＡを用いているため、シーンの途中でのアニメーションデータ以外の外的要因（例えば、重力、風などの環境の力、プレイヤーの動作指示など）で、いずれかのキャラクタが動く場合には、実キャラクタの対応部分の動き及び相手キャラクタの相手部分の動きが、充分に考慮できない場合がある。このような外的要因により、ヒットが適切に実現できないことがある。

図７は、このようなアニメーションデータ以外の外的要因（例えば、重力、風などの環境の力、プレイヤーの動作指示など）を適切に考慮するように、各タイミングに外的要因の影響を考慮する例を示す実施形態１の変形例である。
なお、本明細書及び図面において映像フレームの番号を用いて実施形態が説明される場合には、タイミングは映像フレームの番号で表され得る。例えばアニメーションの開始のフレームをフレーム０とすれば、順次フレームの番号をインクリメントして、ｋ番目のフレームはフレームｋとなる。隣り合うフレーム時間間隔は一定であるため、フレームの番号は、所定のタイミングを意味することとなる点に留意すべきである。

ステップＳ７０２で、処理するフレーム番号を初期化してｋ＝０とする、また、（１０）実キャラクタを移動させるか、（２０）相手キャラクタを移動させるか、を決定する。この決定の仕方については、図６に述べた。

ステップＳ７０４でｋがＭを超えているか否かをチェックする。フレームＭは、ヒットが発生するフレームを意味する。ｋがＭを超えている場合には、処理を終了する。なお、ヒットの後のキャラクタの動きは、更にアニメーションデータを適用してもよいし、ヒットのインパクトを考慮して、キャラクタの動きを実際の人間などの動きと似た形で動作させるシミュレーションの処理を適用してもよい。ヒットの後における処理は、本実施形態に影響されることなく、当業者が適宜にキャラクタの動作処理を適用してよい。
ステップＳ７０４で、判断が肯定的であれば、処理は終了する。判断が否定的であれば、処理は、ステップＳ７０６に移る。
ステップＳ７０６で、アニメーションデータを用いてフレームｋにおいて：

（ｋ１)透明な基準キャラクタの基準部分から実キャラクタの対応部分へのベクトルＡｋを計算し、かつ、（ｋ２）透明な相手キャラクタの相手部分から相手キャラクタの相手部分へのベクトルＢｋを計算する。ここで、透明な基準キャラクタ及び透明な相手キャラクタとは、前記アニメーションデータ以外の外的要因（例えば、重力、風などの環境の力、プレイヤーの動作指示など）による位置の移動を考慮しないキャラクタである。

ステップＳ７０８で、（１０）実キャラクタの対応部分の位置ベクトルからベクトル（Ａｋ－Ｂｋ）を引いた位置ベクトルが実キャラクタの対応部分の位置ベクトルとなるよう実キャラクタを移動させる、又は（２０）相手キャラクタの相手部分の位置ベクトルにベクトル（Ａｋ－Ｂｋ）を足した位置ベクトルが相手キャラクタの相手部分の位置ベクトルとなるよう相手キャラクタを移動させる。
この処理により、上記外的要因が考慮されることとなる。
ステップＳ７１０で、追随するキャラクタ（実キャラクタ又は相手キャラクタ）の移動に対応させて仮想カメラを移動させる。
ステップＳ７１２で、仮想カメラを用いてシーンのフレームｋの画像を生成する。
ステップＳ７１４で、ｋをインクリメントして、ステップＳ７０４に戻る。

以上の処理を行うことにより、各フレームで、アニメーションデータ以外の外的要因（例えば、重力、風などの環境の力、プレイヤーの動作指示など）による位置の移動を考慮して、実キャラクタ又は相手キャラクタの位置が適宜修正され、自然でかつ適切な画像が生成される。

図１４は、実施形態１の変形例を示した図である。
図１４（ａ）では、フレーム０での基準キャラクタＣ０と、相手キャラクタＤ１が示されている。また、フレームｋ＝０~４までの実キャラクタ（それぞれ実キャラクタＣ４０ないしＣ４４）の外的要因（例えば、重力、風などの環境の力、プレイヤーの動作指示など）による位置の移動の様子を示している。

図１４（ｂ）では、基準キャラクタＣ０の基準部分Ｃ０Ｑから実キャラクタの対応部分への各フレームでのベクトルＡｋ（ベクトルＡ０ないしベクトルＡ４）が示されている。

なお、説明を簡単にするために、相手キャラクタの外的要因（例えば、重力、風などの環境の力、プレイヤーの動作指示など）は無いものとして、透明な相手キャラクタＤ１の相手部分から相手キャラクタの相手部分へのベクトルＢｋ（Ｂ０＝Ｂ１＝Ｂ３＝Ｂ４）＝０としている。

この場合には、ベクトルＡｋ－Ｂｋは、ベクトルＡ０ないしベクトルＡ４となる。これらのベクトルを用いて、各タイミングの相手キャラクタを移動させる。図１４（ｂ）では、透明な相手キャラクタＤ１の首関節Ｄ１Ｑを起点として、各タイミングの相手キャラクタをベクトル（Ａｋ－Ｂｋ）だけ移動させている。

図１５は、相手キャラクタの両足先（Ｆａ、Ｆｂ）及び相手キャラクタの相手部分の位置を固定してＩＫを適用して相手キャラクタの姿勢を修正して、実施形態１の変形例の各フレームを示した図である。
図１５（ａ）は、実キャラクタの右手のひらである対応部分Ｃ４ｔと相手キャラクタＤ４の右手のひらである相手部分Ｄ４ｔとがヒットしていることが分かる。
図１５（ｂ）は、ｋ＝０ないし４の各フレームＦ０ないしＦ４における実キャラクタＣ４と相手キャラクタＤ４を含む生成された画像の例を示している。

図８は、実施形態１の複数のヒットが略同時に発生したときの具体例のフローチャートを示した図である。シーンが同時に複数のヒットを含む場合であって、複数のヒットの各々が、異なる相手キャラクタを持っているときには、シーンのフレームｋにおいて、異なる相手キャラクタの各々から求まる移動の方向及び移動の距離に基づいて、複数の相手キャラクタの各々の位置を移動させる。フレームｋの画像を生成する。
上記の処理を、フレーム０からヒットのタイミングのフレームＭまで繰り返すことで、実行される。
ステップＳ８０２とステップＳ８１０との間で、１フレームごとに、フレーム０からフレームＭまで、以下の処理を繰り返し実行する。
ステップＳ８０４で、第１のヒットのシーンにおけるフレームｋのアニメーションの実行を行う。
ステップＳ８０６で、第２のヒットのシーンにおけるフレームｋのアニメーションの実行を行う。
ステップＳ８０８で、仮想カメラを用いてシーンのフレームｋの画像を生成する。
以上の処理で、略同時に実行されるアニメーションを略同時に実行するシーンに含まれる画像を生成することができる。

図９は、キャラクタの姿勢を修正するフローチャートを示した図である。例えば、キャラクタを下方に移動させることにより、キャラクタの足が地面に潜り込まないようにさせる処理が必要な場合がある。このような場合には、一旦キャラクタを移動した後に、キャラクタの足を地面に設置させる。キャラクタの足を固定して、例えばインバース・キネマティクスを適用して、キャラクタのその他の姿勢を修正することで対応できる。

なお、キャラクタの移動距離が大きい場合（例えば、キャラクタが空中に飛び上がってしまって、足が地面に設置できない場合など）には、キャラクタを空中に浮遊させておくことで対応する以外に、適切な対処が見つからない場合もあり得る。このような場合には、キャラクタを空中に浮遊させたままとすることで、対処してもよい。

ステップＳ９０２で、移動させるキャラクタが固定部分を持つかが判断される。判断が否定的であれば、処理は終了する。判断が肯定的であれば、処理はステップＳ９０４に移る。
ステップＳ９０４で、キャラクタを移動させる。なお、実施形態２においては、キャラクタの部分を移動させる。
ステップＳ９０６で、足先など、固定部分を固定位置に戻す処理を行う。

ステップＳ９０８で、固定部分以外の部分にインバース・キネマティクスを適用して、キャラクタの姿勢を修正する。なお、この場合、ヒットが発生する部分については、移動させないように処理することが望ましい。
以上の処理によって、移動させたキャラクタの姿勢を修正することができる。

シーンが略同時に複数のヒットを含む場合であって、複数のヒットの各々が、実キャラクタの異なる対応部分を持っているときには、異なる対応部分の各々から求まる移動の方向及び移動の距離を平均した値に基づいて、実キャラクタ又は相手キャラクタの位置を移動させる。

図１０は、複数のヒットが連続して発生した時の処理を示す図である。
ステップＳ１００２で、第１のヒットのシーンにおけるアニメーションを実行する。
ステップＳ１００４で、第１のヒットのタイミングの状態を初期状態に設定した後に、第２のヒットのシーンにおけるアニメーションを実行する。
以上の処理によって、連続するヒットに対して、適切な画像生成処理が行える。
以上のように、複数のキャラクタに対して、アニメーションデータを適用する場合において、複数のキャラクタの大きさ、体型又は姿勢などが異なっていても、アニメーションデータを適切に適用して、複数のキャラクタに適切な一連の動作を行わせることが可能となる。
＜実施形態２＞

図１６は、実施形態２の処理のフローチャートを示した図である。実施形態２は、ヒットのタイミングにおける所定のキャラクタの所定部分と相手キャラクタの相手部分がヒットすることとなるように制御を行う。この場合、ヒットのタイミングにおける相手部分から所定部分までのベクトルを利用する。そして、このベクトルがヒットのタイミングでゼロとなるように、例えば相手キャラクタの相手部分の位置をタイミングごとに制御する。

既に説明した実施形態１では、キャラクタ全体の位置を移動させたが、この実施形態２では、キャラクタの部分を移動させ、その移動にともなってキャラクタの姿勢を、インバース・キネマティクスを用いて修正するようにすることで、なるべく自然な姿勢で、ヒットがなされるシーンの画像が得られるようにするものである。
図１６のフローを説明する。
ステップＳ１６０２で、ヒットが発生することとなる所定のキャラクタの所定部分と相手キャラクタの相手部分とヒットのタイミングとを特定する。
ステップＳ１６０４で、ヒットのタイミングでの相手部分から所定部分までのベクトルＺを計算する。

ステップＳ１６０６で、ヒットのタイミングで、所定部分が、相手部分にヒットするように、シーンに含まれる複数のタイミングの各々に対して、ベクトルを用いて相手部分の位置を移動させることで、シーンの画像を生成する。

図１７は、実施形態２の画像生成処理の具体例のフローチャートを示した図である。
以下に、実施形態２の画像生成処理の具体的な処理の例を示す。
ステップＳ１７０２では、実施形態１と同様のゲーム空間での複数のキャラクタによる対戦における攻撃のヒットのタイミングを含むシーンを想定している。複数のフレームの各々に、開始のフレームからヒットのタイミングのフレームまで、増加する重み係数（Ｐ０…ＰＭ）を割り当てる。
ステップＳ１７０４で、タイミングｋを初期化する（ｋ＝０）。そして、ヒットのタイミングでの前記相手部分から前記所定部分までのベクトルを計算する。

ステップＳ１７０６で、ｋがＭを超えているか否かをチェックする。フレームＭは、ヒットが発生するフレームを意味する。ｋがＭを超えている場合には、処理を終了する。なお、ヒットの後のキャラクタの動きは、更にアニメーションデータを適用してもよいし、ヒットのインパクトを考慮して、キャラクタの動きを実際の人間などの動きと似た形で動作させるシミュレーションの処理を適用してもよい。ヒットの後における処理は、本実施形態に影響されることなく、当業者が適宜にキャラクタの動作処理を適用してよい。

ステップＳ１７０８でアニメーションデータを相手キャラクタに適用する。ベクトルＺは計算済みであるため、フレームｋでの相手部分の位置ベクトルをYk、重み係数をPkとして、
Yk ← Yk＋Pk・Z

を計算して、相手部分を移動させる。
ステップＳ１７１０で、少なくとも相手部分を固定してキャラクタにインバース・キネマティクスを適用して、所定のキャラクタの姿勢を補正する。
ステップＳ１７１２で、仮想カメラを用いてシーンのフレームｋの画像を生成する。
ステップＳ１７１４でｋをインクリメントする。
以上の処理で、各タイミングでの相手部分の位置が修正されると共に、相手キャラクタの姿勢も、インバース・キネマティクスを用いて修正される。

図１８は、実施形態２の具体例を示した図である。ヒットのフレームにおいて、本来であれば、所定のキャラクタＥ１の右手のひらである所定部分Ｅ１ｔと、相手キャラクタＤ１の右手のひらである相手部分Ｄ１ｔとはヒットすることとなるはずである。しかしながら、所定部分Ｅ１ｔと相手部分Ｄ１ｔとは、ベクトルＺだけ離れた状態となっている。

そこで、各フレームにおける相手キャラクタの相手部分の位置を、それぞれベクトルＺ０、Ｚ１、Ｚ２、Ｚ３及びＺだけ移動させる処理を行う。それぞれベクトルＺ０、Ｚ１、Ｚ２、Ｚ３及びＺは、単調増加関数の重み係数をかけて、徐々に大きくなるベクトルとすることが望ましい。インパクトのフレームでの相手部分の位置ベクトルにベクトルＺを加えるため、相手部分Ｄ１ｔは、所定部分Ｅ１ｔにヒットすることとなる。

また、最初は、小さい重み係数をかけたＺ０によって相手部分が移動するようにすることが望ましい。このようにすることによって、相手部分が初期のタイミングで大きく移動するのを避けることができる。そして、最後のインパクトのタイミングでは、相手部分Ｄ１ｔは、所定部分Ｅ１ｔにヒットすることとなるので、相手キャラクタの動作は滑らかになる。また、これらのベクトルによる相手部分の移動において、相手部分キャラクタにインバース・キネマティクスを適用して姿勢を修正することとすれば、相手キャラクタの姿勢もより自然なものとなる。

図１９は、実施形態１の変形例の各フレームを示した図である。
図１９（ａ）は、相手部分をそれぞれ移動させたのち、インバース・キネマティクスを適用した場合の相手キャラクタが重ねて描かれている。そして、ヒットのフレームで、所定部分Ｅ１ｔと相手部分Ｄ５ｔとが適切にヒットしている。
図１９（ｂ）は、ｋ＝１ないし４の各フレームＦ００ないしＦ０４における所定のキャラクタＥ１と相手キャラクタＤ５を含む生成された画像の例を示している。

以上のように、複数のキャラクタに対して、アニメーションデータを適用する場合において、複数のキャラクタの大きさ、体型又は姿勢などが異なっていても、アニメーションデータを適切に適用して、複数のキャラクタに適切な一連の動作を行わせることが可能となる。

１００ ゲーム装置
１０２ オーディオ制御部
１０４ ＲＡＭ
１０６ ＲＯＭ

１０８ 表示制御部
１１０ ディスプレイ
１１２ オーディオ制御部
１１４ マイク
１１６ スピーカ
１２０ 外部記憶制御部
１２２ コントローラインタフェース部
１２４ タッチパネルインタフェース部
１２６ ネットワークインタフェース部
１３０ メモリカード
１３４ タッチセンサ
１４０ ネットワーク
１５０ サーバ装置
１６２ ゲーム装置
２００ａ 骨
２００ｂ 関節
２００ｃ 体表

３００ 定義表
４００ 機能ブロック図
４０２ アニメーションデータテーブル
４０４ 基準キャラクタデータテーブル
４０６ 実キャラクタデータテーブル
４０８ 相手キャラクタデータテーブル
４１０ 特定部
４２０ 画像生成部
４２２ ベクトル計算部
４２４ 移動部
４２６ アニメーションデータ適用部
４３０ 操作受取部

Claims (5)

1. ゲーム空間での複数のキャラクタによる対戦における攻撃のヒットのタイミングを含むシーンで、所定のキャラクタと、前記対戦の相手キャラクタと、少なくとも前記相手キャラクタに前記対戦の動作を行わせるアニメーションデータとから、前記ヒットが発生することとなる前記所定のキャラクタの所定部分と前記相手キャラクタの相手部分と前記ヒットのタイミングとを特定するステップと、
   前記ヒットのタイミングでの前記相手部分から前記所定部分までのベクトルＺを計算するステップと、
   前記ヒットのタイミングで、前記相手部分が、前記所定部分にヒットするように、前記シーンに含まれる複数のフレームの各々における前記相手部分の位置を移動させる位置の計算において、前記相手部分の位置ベクトルに、前記ベクトルＺと重み係数との積を足すことで、前記シーンの画像を生成するステップと、
   をゲーム装置に実行させる画像生成プログラム。
2. 前記画像を生成するステップは、
   前記複数のフレームの各々に、開始のフレームから前記ヒットのタイミングのフレームまで、増加する重み係数を割り当てるステップと、
   前記複数のフレームの各々のタイミングで：
   前記アニメーションデータを前記相手キャラクタに適用した後の前記相手部分の位置ベクトルに前記各々のタイミングに対応する前記重み係数をかけた前記ベクトルＺを足すことで、前記相手部分を移動させるステップと、
   少なくとも前記相手部分を固定して前記相手キャラクタにインバース・キネマティクスを適用して、前記相手キャラクタの姿勢を補正するステップと、
   を含む請求項１に記載の画像生成プログラム。
3. 前記アニメーションデータは、前記ヒットのタイミング、前記所定部分及び前記相手部分の情報を含む、
   請求項1又は２に記載の画像生成プログラム。
4. ゲーム空間での複数のキャラクタによる対戦における攻撃のヒットのタイミングを含むシーンで、所定のキャラクタと、前記対戦の相手キャラクタと、少なくとも前記相手キャラクタに前記対戦の動作を行わせるアニメーションデータとから、前記ヒットが発生することとなる前記所定のキャラクタの所定部分と前記相手キャラクタの相手部分と前記ヒットのタイミングとを特定する特定部と、
   前記ヒットのタイミングでの前記相手部分から前記所定部分までのベクトルＺを計算するベクトル計算部と、
   前記ヒットのタイミングで、前記相手部分が、前記所定部分にヒットするように、前記シーンに含まれる複数のフレームの各々における前記相手部分の位置を移動させる位置の計算において、前記相手部分の位置ベクトルに前記ベクトルＺと重み係数との積を足すことで、前記対戦の画像を生成する画像生成部と、
   を有する画像生成装置。
5. ゲーム装置にゲーム空間の画像を生成させる画像生成方法であって、
   ゲーム空間での複数のキャラクタによる対戦における攻撃のヒットのタイミングを含むシーンで、所定のキャラクタと、前記対戦の相手キャラクタと、少なくとも前記相手キャラクタに前記対戦の動作を行わせるアニメーションデータとから、前記ヒットが発生することとなる前記所定のキャラクタの所定部分と前記相手キャラクタの相手部分と前記ヒットのタイミングとを特定するステップと、
   前記ヒットのタイミングでの前記相手部分から前記所定部分までのベクトルＺを計算するステップと、
   前記ヒットのタイミングで、前記相手部分が、前記所定部分にヒットするように、前記シーンに含まれる複数のフレームの各々における前記相手部分の位置を移動させる位置の計算において、前記相手部分の位置ベクトルに前記ベクトルＺと重み係数との積を足すことで、前記対戦の画像を生成するステップと、
   を有する、画像生成方法。

Images