(57)【要約】【課題】  伸縮自在なキャラクタを操作対象とする場合に、プレーヤにとって操作し易い適切な仮想カメラの制御を実現する。【解決手段】プレーヤキャラクタＣＰは、ゲームコントローラからの２つの方向入力におうじて、プレーヤキャラクタＣＰの頭ＣＰｈと尾ＣＰｔをそれぞれの方向入力に基づいて移動制御することで移動制御される。プレーヤキャラクタＣＰの全体を撮影するようにメイン仮想カメラＣＭ１を制御し、更に頭ＣＰｈを部分撮影するサブ仮想カメラＣＭ２、尾ＣＰｔを部分撮影するサブ仮想カメラＣＭ３を設定する。メイン仮想カメラＣＭ１の撮影画像を主ゲーム画像Ｗ１に表示させ、サブ仮想カメラＣＭ２，ＣＭ３の撮影画像をそれぞれサブ画面Ｗ２，Ｗ３で表示制御する。【選択図】図７
2008186324.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータを、
３次元仮想空間中を移動可能なオブジェクトであって、方向操作入力に応じて移動する端部を有し、当該端部の移動に引きつられて全身が移動するように制御される紐状体形状のオブジェクトの移動及び体形変化を、前記方向操作入力に基づいて制御するオブジェクト制御手段、
前記オブジェクト制御手段による前記オブジェクトの制御に応じて、画角及び／又は位置の制御を行うことで前記オブジェクトの全体を撮影する全体用仮想カメラを制御する全体用仮想カメラ制御手段、
前記オブジェクト制御手段による前記端部の移動制御に応じて、少なくとも位置を制御することで、１）当該端部を撮影範囲内に収めるように、又は、２）当該端部の後方或いは当該端部位置から当該端部の移動方向に沿った方向に視線方向を向けるように、端部用仮想カメラを制御する端部用仮想カメラ制御手段、
前記全体用仮想カメラ及び前記端部用仮想カメラそれぞれで撮影された画像を少なくとも含む画像群から何れか一つの画像を主ゲーム画面として表示制御し、残る画像を前記主ゲーム画面よりも画像表示サイズが小さいサブ画面として表示制御するゲーム画面表示制御手段、
として前記コンピュータを機能させるためのプログラム。
【請求項２】
請求項１に記載のプログラムであって、
前記ゲーム画面表示制御手段が、所定の画面切換操作に応じて、前記主ゲーム画面及び前記サブ画面に表示制御する画像を交換する画面表示画像交換制御手段を有するように前記コンピュータを機能させるためのプログラム。
【請求項３】
請求項１又は２に記載のプログラムであって、
前記ゲーム画面表示制御手段が、前記主ゲーム画面に表示制御される画像が前記全体用仮想カメラで撮影された画像から他の画像に切り換わって後、所定時間経過した時点で、前記主ゲーム画面に表示制御する画像を前記全体用仮想カメラで撮影された画像に切り換える主ゲーム画面自動復帰制御手段を有するように前記コンピュータを機能させるためのプログラム。
【請求項４】
請求項１〜３の何れか一項に記載のプログラムであって、
前記ゲーム画面表示制御手段が、前記サブ画面の表示／非表示を制御するサブ画面表示／非表示制御手段を有するように前記コンピュータを機能させるためのプログラム。
【請求項５】
請求項４に記載のプログラムであって、
前記オブジェクト制御手段により制御されている前記オブジェクトの移動及び／又は体形変化の現況が、前記サブ画面を表示制御することとする所定のサブ画面表示状況条件を満たしたことを検出する状況条件合致検出手段として前記コンピュータを機能させ、
前記サブ画面表示／非表示制御手段が、前記検出に応じて前記サブ画面を表示させるように前記コンピュータを機能させる、
ためのプログラム。
【請求項６】
請求項５に記載のプログラムであって、
前記状況条件合致検出手段が、前記オブジェクトが静止している状況を前記サブ画面表示状況条件を満たす状況として前記検出を行うように前記コンピュータを機能させるためのプログラム。
【請求項７】
請求項４〜６の何れか一項に記載のプログラムであって、
前記全体用仮想カメラ制御手段により制御されている前記全体用仮想カメラの撮影条件が、前記サブ画面を表示制御することとする所定のサブ画面表示撮影条件を満たしたことを検出する撮影条件合致検出手段として前記コンピュータを機能させ、
前記サブ画面表示／非表示制御手段が、前記撮影条件合致検出手段の検出に応じて前記サブ画面を表示させるように前記コンピュータを機能させる、
ためのプログラム。
【請求項８】
請求項７に記載のプログラムであって、
前記撮影条件合致検出手段が、前記全体用仮想カメラから見て前記オブジェクト以外の他のオブジェクトによって前記端部が隠されている場合に前記サブ画面表示撮影条件を満たすとして前記検出を行うように前記コンピュータを機能させるためのプログラム。
【請求項９】
請求項１〜８の何れか一項に記載のプログラムであって、
前記コンピュータを更に、
所与のゲームイベントとして他オブジェクトを自動制御するイベントを実行させるイベント制御手段、
前記イベント制御手段によるイベントの実行が開始された場合に、前記他オブジェクトを撮影するイベント仮想カメラを設定するイベント仮想カメラ設定手段、
として機能させ、
前記ゲーム画面表示制御手段が、前記画像群に前記イベント仮想カメラによって撮影された画像を含めて前記表示制御を行う、
ように機能させるためのプログラム。
【請求項１０】
請求項９に記載のプログラムであって、
前記イベント仮想カメラ設定手段が、前記オブジェクトと前記他オブジェクトとの両方が撮影範囲内に収まるように前記イベント仮想カメラの画角及び／又は位置を設定するように前記コンピュータを機能させるためのプログラム。
【請求項１１】
請求項１〜１０の何れか一項に記載のプログラムであって、
前記オブジェクトを包含する包含領域を前記オブジェクト制御手段の制御に応じて可変して設定する包含領域設定手段として前記コンピュータを機能させ、
前記全体用仮想カメラ制御手段が、前記設定された包含領域全体が撮影画像に収まるように前記全体用仮想カメラの画角及び／又は位置を制御するように前記コンピュータを機能させる、
ためのプログラム。
【請求項１２】
請求項１〜１１の何れか一項に記載のプログラムであって、
前記オブジェクトは伸縮自在な紐状体形状を有し、
前記オブジェクト制御手段が、前記オブジェクトを伸縮させる制御を行うオブジェクト伸縮制御手段を有するように前記コンピュータを機能させるためのプログラム。
【請求項１３】
コンピュータを、
３次元仮想空間中を移動可能なオブジェクトを、方向操作入力に応じて移動制御するオブジェクト制御手段、
前記オブジェクトを撮影範囲内に含めるように第１仮想カメラの位置及び／又は視線方向を制御する第１仮想カメラ制御手段、
前記オブジェクトを撮影範囲内に含めるように、前記第１仮想カメラとは異なる第２仮想カメラの位置及び／又は視線方向を制御する第２仮想カメラ制御手段、
前記第１仮想カメラから見て前記オブジェクトが他のオブジェクトに隠れたことを検出する隠蔽検出手段、
前記第１仮想カメラによる撮影画像を主ゲーム画面として表示制御するとともに、前記隠蔽検出手段の検出に応じて、前記第２仮想カメラによる撮影画像を前記主ゲーム画面よりも画像表示サイズが小さいサブ画面として表示制御するゲーム画面表示制御手段、
として前記コンピュータを機能させるためのプログラム。
【請求項１４】
請求項１〜１３の何れか一項に記載のプログラムを記憶したコンピュータ読み取り可能な情報記憶媒体。
【請求項１５】
３次元仮想空間中を移動可能なオブジェクトであって、方向操作入力に応じて移動する端部を有し、当該端部の移動に引きつられて全身が移動するように制御される紐状体形状のオブジェクトの移動及び体形変化を、前記方向操作入力に基づいて制御するオブジェクト制御手段と、
前記オブジェクト制御手段による前記オブジェクトの制御に応じて、画角及び／又は位置の制御を行うことで前記オブジェクトの全体を撮影する全体用仮想カメラを制御する全体用仮想カメラ制御手段と、
前記オブジェクト制御手段による前記端部の移動制御に応じて、少なくとも位置を制御することで、１）当該端部を撮影範囲内に収めるように、又は、２）当該端部の後方或いは当該端部位置から当該端部の移動方向に沿った方向に視線方向を向けるように、端部用仮想カメラを制御する端部用仮想カメラ制御手段と、
前記全体用仮想カメラ及び前記端部用仮想カメラそれぞれで撮影された画像を少なくとも含む画像群から何れか一つの画像を主ゲーム画面として表示制御し、残る画像を前記主ゲーム画面よりも画像表示サイズが小さいサブ画面として表示制御するゲーム画面表示制御手段と、
を備えたゲーム装置。
【請求項１６】
３次元仮想空間中を移動可能なオブジェクトを、方向操作入力に応じて移動制御するオブジェクト制御手段と、
前記オブジェクトを撮影範囲内に含めるように第１仮想カメラの位置及び／又は視線方向を制御する第１仮想カメラ制御手段と、
前記オブジェクトを撮影範囲内に含めるように、前記第１仮想カメラとは異なる第２仮想カメラの位置及び／又は視線方向を制御する第２仮想カメラ制御手段と、
前記第１仮想カメラから見て前記オブジェクトが他のオブジェクトに隠れたことを検出する隠蔽検出手段と、
前記第１仮想カメラによる撮影画像を主ゲーム画面として表示制御するとともに、前記隠蔽検出手段の検出に応じて、前記第２仮想カメラによる撮影画像を前記主ゲーム画面よりも画像表示サイズが小さいサブ画面として表示制御するゲーム画面表示制御手段と、
を備えたゲーム装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータに、所与のオブジェクトが配置された３次元仮想空間を仮想カメラで撮影した画像を生成させるためのプログラム等に関する。
【背景技術】
【０００２】
近年のビデオゲームでは、３次元仮想空間にゲーム空間を形成する種々のオブジェクトや、プレーヤが操作するプレーヤのオブジェクト等を配置し、それらのプレーヤによる操作入力や予め設定された動きでそれらを動作制御してゲームを実行するものが多く、そうしたタイプのゲームにおけるゲーム画面は、同じ３次元仮想空間に仮想カメラで撮影した画像を生成し、これにゲーム進行に必要な情報（例えば、マップであったり、ゲームの残り時間、得点、ヒットポイント、残弾数など）を合成して作られる。換言すると、仮想カメラの位置や視線方向、画角を含む撮影条件に設定によって、ゲーム画面としてプレーヤに提供する視覚情報が決まるとも言える。したがって、如何に適切な撮影条件を決定するかで、そのゲームが操作しやすいユーザフレンドリーなものになるか、操作しにくいゲームとなるかに大きく影響する。
【０００３】
そうした仮想カメラの制御に関する技術としては、例えば、プレーヤキャラクタと攻撃目標カーソルの両方が撮影範囲に収まるように制御するものが知られている。（例えば、特許文献１参照）。
【特許文献１】特許第３１９７５３６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで、ゲームに登場するキャラクタは、ゲームの内容に応じて千差万別であるのは良く知られるところである。例えば、弾性体や、レオロジー物体（フックの法則に従わない固体、ニュートンの粘性法則に従わない液体、弾性力学や流体力学における抗力が無い粘弾性や塑性を示す物体などの総称。）に類する特性をもつキャラクタを登場させようとした場合、そのキャラクタは自由に伸び縮みし体系も一定とは限らない。プレーヤにとってみれば、レオロジー物体に類するキャラクタ操作しようとすると、当然のことながら端部がどういった状態で、何所にあるのかを知れるか否か必要となる。そのため、従来技術のように、単にそのキャラクタのローカル原点等の代表点を基準に仮想カメラを制御する方法では、場合によってはキャラクタの伸びた端が見えない状況が起り、著しく操作し難くなる心配があった。
【０００５】
本発明は、こうした事情を鑑みてなされたものであり、その目的とするところは、弾性体やレオロジー物体に類する伸縮自在なキャラクタを操作対象とする場合に、プレーヤにとって操作し易い適切な仮想カメラの制御を実現することである。
【課題を解決するための手段】
【０００６】
上記の課題を解決する第１の発明は、コンピュータを、３次元仮想空間中を移動可能なオブジェクト（例えば、図３のプレーヤキャラクタＣＰ）であって、方向操作入力に応じて移動する端部（例えば、図３の前端ノード２Ｆｒ、頭ＣＰｈ、後端ノード２ｒｒ、尾ＣＰｔ）を有し、当該端部の移動に引きつられて全身が移動するように制御される紐状体形状のオブジェクトの移動及び体形変化を、前記方向操作入力に基づいて制御するオブジェクト制御手段（例えば、図８の処理部２００、ゲーム演算部２１０、キャラクタ制御部２１２、図１４のステップＳ６〜Ｓ１０）、前記オブジェクト制御手段による前記オブジェクトの制御に応じて、画角及び／又は位置の制御を行うことで前記オブジェクトの全体を撮影する全体用仮想カメラ（例えば、図７のメイン仮想カメラＣＭ１）を制御する全体用仮想カメラ制御手段（例えば、図８の処理部２００、ゲーム演算部２１０、キャラクタ制御部２１２、図１４のステップＳ２０）、前記オブジェクト制御手段による前記端部の移動制御に応じて、少なくとも位置を制御することで、１）当該端部を撮影範囲内に収めるように、又は、２）当該端部の後方或いは当該端部位置から当該端部の移動方向に沿った方向に視線方向を向けるように、端部用仮想カメラ（例えば、図７のサブ仮想カメラＣＭ２、サブ仮想カメラＣＭ３）を制御する端部用仮想カメラ制御手段（例えば、図８の処理部２００、ゲーム演算部２１０、キャラクタ制御部２１２、図１４のステップＳ２２）、前記全体用仮想カメラ及び前記端部用仮想カメラそれぞれで撮影された画像を少なくとも含む画像群から何れか一つの画像を主ゲーム画面として表示制御し、残る画像を前記主ゲーム画面よりも画像表示サイズが小さいサブ画面として表示制御するゲーム画面表示制御手段（例えば、図８の処理部２００、画像生成部２６０、サブ画像表示制御部２６２、図１４のステップＳ２４）、として前記コンピュータを機能させるためのプログラムである。
【０００７】
第１４の発明は、３次元仮想空間中を移動可能なオブジェクトであって、方向操作入力に応じて移動する端部を有し、当該端部の移動に引きつられて全身が移動するように制御される紐状体形状のオブジェクトの移動及び体形変化を、前記方向操作入力に基づいて制御するオブジェクト制御手段と、前記オブジェクト制御手段による前記オブジェクトの制御に応じて、画角及び／又は位置の制御を行うことで前記オブジェクトの全体を撮影する全体用仮想カメラを制御する全体用仮想カメラ制御手段と、前記オブジェクト制御手段による前記端部の移動制御に応じて、少なくとも位置を制御することで、１）当該端部を撮影範囲内に収めるように、又は、２）当該端部の後方或いは当該端部位置から当該端部の移動方向に沿った方向に視線方向を向けるように、端部用仮想カメラを制御する端部用仮想カメラ制御手段と、前記全体用仮想カメラ及び前記端部用仮想カメラそれぞれで撮影された画像を少なくとも含む画像群から何れか一つの画像を主ゲーム画面として表示制御し、残る画像を前記主ゲーム画面よりも画像表示サイズが小さいサブ画面として表示制御するゲーム画面表示制御手段とを備えたゲーム装置である。
【０００８】
第１及び第１４の発明によれば、紐状体形状のオブジェクトの端部を方向操作入力に応じて移動させるようにして該オブジェクトの移動及び体形変化を方向操作入力に基づいて制御することができる。したがって、弾性体やレオロジー物体に類して紐のようなキャラクタを、その端部を操作するようにして操作対象とすることができる。
そして、そのオブジェクトの全体を撮影する全体用仮想カメラとオブジェクトの端部を撮影する端部用仮想カメラとを設定・制御し、全体用仮想カメラ及び端部用仮想カメラそれぞれで撮影された画像を少なくとも含む画像群から何れか一つの画像を主ゲーム画面として表示制御し、残る画像を前記主ゲーム画面よりも画像表示サイズが小さいサブ画面として表示制御することができる。
つまり、ゲーム画面には常時、オブジェクトの全体が映されるとともにオブジェクトの移動制御に重要な端部の様子が映しだされることになる。プレーヤが、キャラクタの全体とキャラクタの移動及び体形変化をさせるために端部を移動操作すると良いか判断しやすくなる。
【０００９】
第２の発明は、第１の発明のプログラムであって、前記ゲーム画面表示制御手段が、所定の画面切換操作に応じて、前記主ゲーム画面及び前記サブ画面に表示制御する画像を交換する画面表示画像交換制御手段（例えば、図８の処理部２００、画像生成部２６０、サブ画像表示制御部２６２、図１４のステップＳ２６）を有するように前記コンピュータを機能させるためのプログラムである。
【００１０】
第２の発明によれば、第１の発明と同様の効果を奏するとともに、所定の画面切換操作で、主ゲーム画面及びサブ画面に表示制御する画像を切り換えすることができる。したがって、サブ画面表示されている表示内容をより大きく見たいと思ったときに画面を切り換えれば、実質的に端部の様子を拡大表示することができるので、キャラクタの操作がより一層し易くなる。
【００１１】
第３の発明は、第１又は第２の発明のプログラムであって、前記ゲーム画面表示制御手段が、前記主ゲーム画面に表示制御される画像が前記全体用仮想カメラで撮影された画像から他の画像に切り換わって後、所定時間経過した時点で、前記主ゲーム画面に表示制御する画像を前記全体用仮想カメラで撮影された画像に切り換える主ゲーム画面自動復帰制御手段（例えば、図８の処理部２００、画像生成部２６０、サブ画像表示制御部２６２、図２１のステップＳ１８２〜Ｓ１８８）を有するように前記コンピュータを機能させるためのプログラムである。
【００１２】
第３の発明によれば、第１又は第２の発明と同様の効果を奏するとともに、主ゲーム画面に表示制御される画像が、全体用仮想カメラで撮影された画像から他の画像に切り換えされたとしても、所定時間経過した時点で元の状態に自動復帰さえることができる。
弾性体やレオロジー物体に類する特性を有する紐状体形状のキャラクタを操作対象とする場合に、キャラクタの全体を見て操作するのが適当であるから、一時的に主ゲーム画面とサブ画面とで表示する画像を交換しても、いずれはキャラクタの全体の様子を主ゲーム画面に戻すほうが都合は良い。したがって、画像の切換が元の状態に自動的に復帰することで、プレーヤがより操作し易い環境を実現できる。
【００１３】
第４の発明は、第１〜第３の何れか一つの発明のプログラムであって、前記ゲーム画面表示制御手段が、前記サブ画面の表示／非表示を制御するサブ画面表示／非表示制御手段（例えば、図８の処理部２００、画像生成部２６０、サブ画像表示制御部２６２、図２０のステップＳ２０２〜Ｓ２０４）を有するように前記コンピュータを機能させるためのプログラムである。
【００１４】
第４の発明によれば、サブ画面を表示としたり非表示とすることができる。例えば、主ゲーム画面とサブ画面を並列配置する場合には主ゲーム画面をより広く表示させたり、主ゲーム画面とサブ画面を重ね配置する場合には主ゲーム画面の画像がサブ画面で隠れてしまう状態をできるだけ少なくできる。したがって、常時サブ画面が表示されている形態に比べると、プレーヤはより操作し易くなる。
【００１５】
第５の発明は、第４の発明のプログラムであって、前記オブジェクト制御手段により制御されている前記オブジェクトの移動及び／又は体形変化の現況が、前記サブ画面を表示制御することとする所定のサブ画面表示状況条件を満たしたことを検出する状況条件合致検出手段（例えば、図８の処理部２００、画像生成部２６０、サブ画像表示制御部２６２、図２０のステップＳ２０２〜Ｓ２０４）として前記コンピュータを機能させ、前記サブ画面表示／非表示制御手段が、前記検出に応じて前記サブ画面を表示させるように前記コンピュータを機能させるためのプログラムである。
【００１６】
第５の発明によれば、第４の発明と同様の効果を奏するとともに、オブジェクトの移動及び／又は体形変化の現況に応じてサブ画面を表示／非表示制御することができる。例えば、サブ画面表示状況条件を、他のオブジェクトによってキャラクタの端部が隠れて見えなくなっていることを条件とするならば、主ゲーム画面上で端部が見えない状態になるとサブ画面を表示させ、再び見えるようになるとサブ画面を非表示とするように自動制御することができるようになり、プレーヤがより一層、プレーヤはより操作し易くなる。
【００１７】
第６の発明は、第５の発明のプログラムであって、前記状況条件合致検出手段が、前記オブジェクトが静止している状況を前記サブ画面表示状況条件を満たす状況として前記検出を行うように前記コンピュータを機能させるためのプログラムである。
【００１８】
第６の発明によれば、第５の発明と同様の効果を奏するとともに、キャラクタの移動中はサブ画面を表示しないようにして、移動中の状況を見易くする一方で一旦立ち止まることで、周囲の状況を詳しく観察できるようになるので、より一層プレーヤキャラクタＣＰを操作し易くなる。
【００１９】
第７の発明は、第４〜第６の何れか一つの発明のプログラムであって、前記全体用仮想カメラ制御手段により制御されている前記全体用仮想カメラの撮影条件が、前記サブ画面を表示制御することとする所定のサブ画面表示撮影条件を満たしたことを検出する撮影条件合致検出手段（例えば、図８の処理部２００、画像生成部２６０、サブ画像表示制御部２６２、図２０のステップＳ２０２〜Ｓ２０４）として前記コンピュータを機能させ、前記サブ画面表示／非表示制御手段が、前記撮影条件合致検出手段の検出に応じて前記サブ画面を表示させるように前記コンピュータを機能させるためのプログラムである。
【００２０】
第７の発明によれば、第１〜第６の何れか一つの発明と同様の効果を奏するとともに、全体酔う仮想カメラの撮影条件をサブ画面の表示制御のための条件とすることができる。したがって、主ゲーム画像で表示される画像が一時的に操作しにくい状況になってもこれを自動的にリカバーしプレーヤがプレーヤはより操作環境を維持することができる。
【００２１】
第８の発明は、第７の発明のプログラムであって、前記撮影条件合致検出手段が、前記全体用仮想カメラから見て前記オブジェクト以外の他のオブジェクトによって前記端部が隠されている場合に前記サブ画面表示撮影条件を満たすとして前記検出を行うように前記コンピュータを機能させるためのプログラムである。
【００２２】
第８の発明によれば、第７の発明と同様の効果を奏するとともに、例えば、全体用仮想カメラの撮影条件を適切に設定しても、ゲーム進行状況によっては、他のオブジェクトが全体用仮想カメラの視界に入り、一時的にキャラクタの端部が隠れて見えなくなっている状況において、主ゲーム画面上にサブ画面を表示させ、再び見えるようになるとサブ画面を非表示とするように自動制御することができるようになる。したがって、より一層プレーヤキャラクタＣＰを操作し易くなる。
【００２３】
第９の発明は、第１〜第８の何れか一つの発明のプログラムであって、前記コンピュータを更に、所与のゲームイベントとして他オブジェクトを自動制御するイベントを実行させるイベント制御手段（例えば、図８の処理部２００、ゲーム演算部２１０、図１４のステップＳ１２）、前記イベント制御手段によるイベントの実行が開始された場合に、前記他オブジェクトを撮影するイベント仮想カメラを設定するイベント仮想カメラ設定手段（例えば、図８の処理部２００、ゲーム演算部２１０、仮想カメラ制御部２１４、図１４のステップＳ１８）として機能させ、前記ゲーム画面表示制御手段が、前記画像群に前記イベント仮想カメラによって撮影された画像を含めて前記表示制御を行うように機能させるためのプログラムである。
【００２４】
第９の発明によれば、第１〜第８の何れかの発明と同様の効果を奏するとともに、イベントの実行にともなってイベントで自動制御される他オブジェクトを撮影するイベント仮想カメラを設定し、サブ画面表示することができる。したがって、全体用仮想カメラの撮影範囲外で発生したイベントであっても、何が起きているかもれなくプレーヤに知らせることが可能になる。
【００２５】
第１０の発明は、第９の発明のプログラムであって、前記イベント仮想カメラ設定手段が、前記オブジェクトと前記他オブジェクトとの両方が撮影範囲内に収まるように前記イベント仮想カメラの画角及び／又は位置を設定するように前記コンピュータを機能させるためのプログラムである。
【００２６】
第１０の発明によれば、第９の発明と同様の効果を奏するとともに、イベント仮想カメラの撮影範囲内にオブジェクトと他オブジェクトとの両方が収まるように制御できる。したがって、イベント仮想カメラで撮影した画像をサブ画面表示すれば、プレーヤにそのイベントがキャラクタに対してどのあたりで起きているかを知らせることができる。よって、より一層、プレーヤはキャラクタの操作がし易くなる。
【００２７】
第１１の発明は、第１〜第１０の何れか一つの発明のプログラムであって、前記オブジェクトを包含する包含領域を前記オブジェクト制御手段の制御に応じて可変して設定する包含領域設定手段（例えば、図８の処理部２００、ゲーム演算部２１０、仮想カメラ制御部２１４、図１８のステップＳ１１２）として前記コンピュータを機能させ、前記全体用仮想カメラ制御手段が、前記設定された包含領域全体が撮影画像に収まるように前記全体用仮想カメラの画角及び／又は位置を制御するように前記コンピュータを機能させるためのプログラムである。
【００２８】
第１１の発明によれば、第１〜第１０の発明の何れかと同様の効果を奏するとともに、キャラクタの代表寸法を体勢や体形によらずに速やかに求め、全体用仮想カメラの撮影範囲内にキャラクタが収まるように全体用仮想カメラの画角及び／又は位置を制御することができる。したがって、処理負荷を軽減することができる。
【００２９】
第１２の発明は、第１〜第１１の何れか一つの発明のプログラムであって、前記オブジェクトは伸縮自在な紐状体形状を有し、前記オブジェクト制御手段が、前記オブジェクトを伸縮させる制御を行うオブジェクト伸縮制御手段（例えば、図８の処理部２００、ゲーム演算部２１０、キャラクタ制御部２１２、図１４のステップＳ６）を有するように前記コンピュータを機能させるためのプログラムである。
【００３０】
第１２の発明によれば、第１〜第１１の何れかの発明と同様の効果を奏するとともに、キャラクタを伸縮自在に制御することができる。
【００３１】
第１３の発明は、コンピュータを、３次元仮想空間中を移動可能なオブジェクト（例えば、図７のプレーヤキャラクタＣＰ）を、方向操作入力に応じて移動制御するオブジェクト制御手段（例えば、図８の処理部２００、ゲーム演算部２１０、キャラクタ制御部２１２、図１４のステップＳ６〜Ｓ１０）、前記オブジェクトを撮影範囲内に含めるように第１仮想カメラ（例えば、図７のメイン仮想カメラＣＭ１）の位置及び／又は視線方向を制御する第１仮想カメラ制御手段（例えば、図８の処理部２００、ゲーム演算部２１０、キャラクタ制御部２１２、図１４のステップＳ２０）、前記オブジェクトを撮影範囲内に含めるように、前記第１仮想カメラとは異なる第２仮想カメラ（例えば、図７のサブ仮想カメラＣＭ２、ＣＭ３）の位置及び／又は視線方向を制御する第２仮想カメラ制御手段（例えば、図８の処理部２００、ゲーム演算部２１０、キャラクタ制御部２１２、図１４のステップＳ２２）、前記第１仮想カメラから見て前記オブジェクトが他のオブジェクトに隠れたことを検出する隠蔽検出手段（例えば、図８の処理部２００、ゲーム演算部２１０、キャラクタ制御部２１２、図１４のステップＳ２１）、前記第１仮想カメラによる撮影画像を主ゲーム画面として表示制御するとともに、前記隠蔽検出手段の検出に応じて、前記第２仮想カメラによる撮影画像を前記主ゲーム画面よりも画像表示サイズが小さいサブ画面として表示制御するゲーム画面表示制御手段（例えば、図８の処理部２００、画像生成部２６０、サブ画像表示制御部２６２、図１４のステップＳ２４）として前記コンピュータを機能させるためのプログラムである。
【００３２】
また、第１６の発明は、３次元仮想空間中を移動可能なオブジェクトを、方向操作入力に応じて移動制御するオブジェクト制御手段と、前記オブジェクトを撮影範囲内に含めるように第１仮想カメラの位置及び／又は視線方向を制御する第１仮想カメラ制御手段と、前記オブジェクトを撮影範囲内に含めるように、前記第１仮想カメラとは異なる第２仮想カメラの位置及び／又は視線方向を制御する第２仮想カメラ制御手段と、前記第１仮想カメラから見て前記オブジェクトが他のオブジェクトに隠れたことを検出する隠蔽検出手段と、前記第１仮想カメラによる撮影画像を主ゲーム画面として表示制御するとともに、前記隠蔽検出手段の検出に応じて、前記第２仮想カメラによる撮影画像を前記主ゲーム画面よりも画像表示サイズが小さいサブ画面として表示制御するゲーム画面表示制御手段と、を備えたゲーム装置である。
【００３３】
第１３及び第１６の発明によれば、方向操作入力に応じて３次元仮想空間内におけるオブジェクトの移動を制御することができるとともに、そのオブジェクトを撮影する第１仮想カメラを設定・制御し、第１仮想カメラで撮影した画像を主ゲーム画面として表示制御できる。しかし、第１仮想カメラから見てオブジェクトが他のオブジェクトに隠れてしまっている場合には、第１仮想カメラとは異なる第２仮想カメラにより撮影された画像を主ゲーム画面よりも画像表示サイズが小さいサブ画面として表示制御することができる。つまり、ゲーム画面には常時、オブジェクトが映し出されることになり、プレーヤの移動操作が容易になる。
【００３４】
第１４の発明は、第１〜第１３の何れか一つのプログラムを記憶したコンピュータ読み取り可能な情報記憶媒体である。ここで言う「情報記憶媒体」とは、例えば磁気ディスクや光学ディスク、ＩＣメモリなどを含む。第１４の発明によれば、第１〜第１３の何れか一つの発明のプログラムをコンピュータに読み取らせて実行させることによって、コンピュータに第１〜１３の何れか一つの発明と同様の効果を発揮させることができる。
【発明の効果】
【００３５】
本発明によれば、紐状体形状のオブジェクトの端部を方向操作入力に応じて移動させるようにして該オブジェクトの移動及び体形変化を方向操作入力に基づいて制御することができる。したがって、弾性体やレオロジー物体に類して紐状体形状のキャラクタを、その端部を操作するようにして操作対象とすることができる。
そして、そのオブジェクトの全体を撮影する全体用仮想カメラとオブジェクトの端部を撮影する端部用仮想カメラとを設定・制御し、全体用仮想カメラ及び端部用仮想カメラそれぞれで撮影された画像を少なくとも含む画像群から何れか一つの画像を主ゲーム画面として表示制御し、残る画像を前記主ゲーム画面よりも画像表示サイズが小さいサブ画面として表示制御することができる。
したがって、ゲーム画面には常時、オブジェクトの全体が映されるとともにオブジェクトの移動制御に重要な端部の様子が映しだされることとなり、プレーヤが弾性体やレオロジー物体に類して紐状体形状のキャラクタを操作するのに適切な画像表示を実現することができる。
【発明を実施するための最良の形態】
【００３６】
〔第１実施形態〕
以下、本発明を適用した第１実施形態として、伸縮自在なキャラクタが登場するビデオゲームを例に挙げて説明する。
【００３７】
［ゲーム装置の構成］
図１は、本実施形態における家庭用ゲーム装置の構成例を説明するシステム構成図である。家庭用ゲーム装置１２００のゲーム装置本体１２０１は、例えばＣＰＵや画像処理用ＬＳＩ、ＩＣメモリ等が実装された制御ユニット１２１０と、光学ディスク１２０２やメモリカード１２０４といった情報記憶媒体の読み取り装置１２０６，１２０８を備える。そして、家庭用ゲーム装置１２００は、光学ディスク１２０２やメモリカード１２０４からゲームプログラム及び各種設定データを読み出し、ゲームコントローラに為される操作入力に基づいて各種のゲーム演算を実行し、所与のビデオゲームを実行する。
【００３８】
家庭用ゲーム装置１２００の制御ユニット１２１０で生成されたゲーム画像やゲーム音は、信号ケーブル１２０９で接続されたビデオモニタ１２２０に出力される。プレーヤは、ビデオモニタ１２２０のディスプレイ１２２２に表示されるゲーム画像を見つつ、スピーカ１２２４から出力されるＢＧＭや効果音といったゲーム音を聞きながら、ゲームコントローラ１２３０から各種操作を入力してゲームを楽しむ。
【００３９】
ゲームコントローラ１２３０は、選択の決定やキャンセル、タイミングの入力などに用いられるコントローラ上面に設けられたプッシュボタン１２３２と、側面に設けられたプッシュボタン１２３３と、図で言うところの上下左右の各方向を単独入力するための方向入力キー１２３４と、右アナログレバー１２３６と、左アナログレバー１２３８とを備える。
【００４０】
右アナログレバー１２３６及び左アナログレバー１２３８は、図で言うところの上下方向と左右方向の２軸方向を同時入力可能な方向入力デバイスである。通常はゲームコントローラ１２３０を左右の手で把持し、レバー１２３６ａ，１２３８ａにそれぞれ親指を添えて操作する。レバー１２３６ａ，１２３８ａを倒すことによって２軸成分を含む任意の方向入力と、レバーの傾倒量に応じた任意操作量を入力することができる。また、何れのアナログレバーも、操作入力していない中立状態からレバーの軸方向に押し込むことでプッシュスイッチとしても使用することもできる。そして、本実施形態では、右アナログレバー１２３６及び左アナログレバー１２３８からの操作入力によって、プレーヤキャラクタの移動並びに伸縮の操作を入力する。
【００４１】
尚、ゲーム実行に必要なゲームプログラム及び各種設定データは、通信装置１２１２を介して通信回線１に接続し、外部装置からダウンロードして取得する構成であっても良い。ここで言う、通信回線とは、データ授受が可能な通信路を意味する。すなわち、通信回線とは、直接接続のための専用線（専用ケーブル）やイーサネット（登録商標）等によるＬＡＮ（Local Area Network）の他、電話通信網やケーブル網、インターネット等の通信網を含む意味であり、また、通信方法については有線／無線を問わない。
【００４２】
［プレーヤキャラクタの説明］
本実施形態におけるビデオゲームは、伸縮自在な紐状のキャラクタをプレーヤキャラクタとして操り、スタート地点から所定のゴール地点に移動することを目的とするゲームである。ゲーム空間には行く手を阻む地形的な障害や、プレーヤキャラクタの体力をそぎ落とそうとする他のキャラクタが設定されており、体力が「０」にならない内に無事ゴールに辿り着くことができればハッピーエンドでゲームクリアし、途中で体力が「０」になればバッドエンドでゲームオーバとなる。
【００４３】
図２は、本実施形態におけるプレーヤキャラクタのモデル構成を説明するための図である。同図に示すように、本実施形態におけるビデオゲームでプレーヤがゲームの主人公として操作するプレーヤキャラクタＣＰは、一頭一尾の想像上の紐状体形状を成すワーム（worm：細長く足のない動物。）としてデザインされており、紐のように柔軟であるとともにレオロジー物体のような伸縮自在な胴ＣＰｂを有する。つまり、プレーヤキャラクタＣＰは、頭ＣＰｈ及び尾ＣＰｔ方向を伸身前後方向として胴ＣＰｂの太さをそのままに伸縮自在なキャラクタとして設定されている。尚、本実施形態では胴ＣＰｂが伸び縮みする形態として説明するが、キャラクタのデザインによっては、頭ＣＰｈや尾ＣＰｔも自在に伸び縮みする設定として、全身どこでも伸び縮みする設定としても良いのは勿論である。
【００４４】
プレーヤキャラクタＣＰは、図２（ａ）に示すように、複数のノード２が、互いに前後の距離Ｌを一定にして配列され骨格モデルＢＭを有する。別の言い方をするならば、ノード２（＝制御点）が連結子４によって一列の関節構造として連結されており、連結子４は全て同じ固定長Ｌを有している。また、ノード２と連結子４との結合角度は、全て所定角度範囲θ内となるように限定されている。したがって、ノード２を関節と見なすと、骨格モデルＢＭは、複数の関節が一本の直列状に連結されており、しかも各関節では一定角度以上曲がらないことになる。
【００４５】
図２（ｂ）に示すように、プレーヤキャラクタＣＰにはヒット判定モデルＨＭが設定されている。本実施形態におけるヒット判定モデルＨＭでは、各ノードにヒット判定領域６が設定されている。本実施形態におけるヒット判定領域６は、対応するノード２の位置座標を中心にして、半径Ｒ（＝連結子４の長さＬ）の球状領域として設定されている。
【００４６】
そして図２（ｃ）に示すように、プレーヤキャラクタＣＰの表示モデルはポリゴンによって形成される。具体的には、各ノード２には、隣接するノードに向かうそれぞれのベクトルの和のベクトルを面に含む表示基準円１０が設定されている。そして、頭ＣＰｈ及び尾ＣＰｔは、骨格モデルＢＭの先頭及び末尾のノードを基準点として予め設定された頭部或いは尾部のモデルを配置する。そして、胴ＣＰｂについては、各ノードに設定されている表示基準円１０で定義される円周の外縁を滑らかに結ぶように複数のポリゴンを生成・変形・再配置する。胴部ＣＰｂにおけるポリゴンモデルの形成は、例えばスケルトンモデルへの外皮形成処理などの公知のモデリング技術を適宜用いることによって実現できる。
【００４７】
尚、本実施形態では、表示基準円１０の半径はヒット判定領域６の半径Ｒと同じに設定されているので、プレーヤキャラクタＣＰの外皮に何らかのオブジェクトが接触すると、ヒット判定される様に設定されているが、これに限るものではなくヒット判定領域６の半径Ｒよりやや大きく設定することによって、ヒットしたオブジェクトがプレーヤキャラクタＣＰに刺さって見えないように整合を図ったりしても良い。また、以下の説明では複数あるノード２のうち、キャラクタの前方側端のノードを「前端ノード２ｆｒ」、後方側端のノードを「後端ノード２ｒｒ」と呼称することがある。
【００４８】
［プレーヤキャラクタの操作方法の説明］
図３は、本実施形態におけるプレーヤキャラクタＣＰの移動操作と制御の関係を示す概念図である。同図に示すように、ゲームコントローラ１２３０の左アナログレバー１２３８に為された操作入力に応じて、骨格モデルＢＭの前端のノード２ｆｒに第１の操作力Ｆ１が設定される。また、右アナログレバー１２３６に為された操作入力に応じて後端のノード２ｒｒに第２の操作力Ｆ２が設定される。尚、操作力以外に、重力や風に押される力などのゲーム空間に設定された様々な力や、他のキャラクタとの衝突によって受ける力が適宜設定され得るがここでは説明を省略する。
【００４９】
さて、第１の操作力Ｆ１ならびに第２の操作力Ｆ２が設定されると、両操作力によって骨格モデルＢＭは前端及び後端がそれぞれ引っ張られる格好となり、先に説明した骨格モデルＢＭの拘束条件を考慮して所定の運動方程式に従って各ノードの位置が更新される。そして、各ノードの位置が更新された骨格モデルＢＭをベースに外皮を形成処理することによって、プレーヤキャラクタＣＰの表示モデルの位置が更新される。この様子を仮想カメラＣＭで撮影し、撮影した画像を生成してゲーム画面とすることで、プレーヤキャラクタＣＰがゲーム空間内を移動するように表現される。
【００５０】
また、本実施形態では、第１の操作力Ｆ１ならびに第２の操作力Ｆ２に基づいて、プレーヤがプレーヤキャラクタＣＰを任意に伸ばしたり縮めたりすることができる。
図４は、本実施形態におけるプレーヤキャラクタＣＰの任意伸長操作と制御の関係を示す概念図である。同図（ａ）に示すように、プレーヤがゲームコンロローラ１２３０の右アナログレバー１２３６から右方向入力、左アナログレバー１２３８から左方向入力を同時入力すると任意伸長操作の入力となる。すると、同図（ｂ）の俯瞰図に示すように、プレーヤキャラクタＣＰの骨格モデルＢＭは、左側の状態から右側の状態に変更される。すなわち、前端ノード２ｆｒと該前端ノードの次連結ノード２ｂとの間に新たなノード２ａが追加され、更に後端ノード２ｒｒと該後端ノードの次連結ノード２ｃとの間にも新たなノード２ｄが追加される。そして、同図（ｃ）の俯瞰図に示す様に、プレーヤキャラクタＣＰの表示モデルは変更された骨格モデルＢＭに基づいて外皮が形成されることによって、左側の全長が短い状態から右側の全長が伸びた状態に変化する。
【００５１】
一方、右アナログレバー１２３６から右方向入力され、左アナログレバー１２３８から左方向入力がされているが、同時入力とは見なされない場合には、同図（ｄ）の左側の状態のように、単に左アナログレバー１２３８への入力に応じた第１の操作力Ｆ１が、前端ノード２ｆｒに作用し、右アナログレバー１２３６への入力に応じた第２の操作力Ｆ２が、後端ノード２ｒｒに作用していると見なされる。したがって、同図（ｄ）の場合、第１の操作力Ｆ１及び第２の操作力Ｆ２が、プレーヤキャラクタＣＰの頭ＣＰｈ、尾ＣＰｔをそれぞれ引っ張る様に作用し、新たなノードの追加は行われずに前端ノード２ｆｒと後端ノード２ｒｒが反対方向に引っ張られる格好となる。この結果、例えば骨格モデルＢＭが湾曲状態であれば、同図（ｄ）右側の状態のように直線状態に近づくことになる。
【００５２】
また図５は、本実施形態におけるプレーヤキャラクタＣＰの任意短縮操作と制御の関係を示す概念図である。同図（ａ）に示すように、プレーヤがゲームコンロローラ１２３０の右アナログレバー１２３６から左方向入力、左アナログレバー１２３８から右方向入力を同時入力すると任意短縮操作の入力となる。任意短縮操作が入力されると、プレーヤキャラクタＣＰの骨格モデルＢＭは、同図（ｂ）の俯瞰図に示すように、左側の状態から右側の状態に変更される。すなわち、前端ノード２ｆｒの次連結ノード２ａが削除され、更に後端ノード２ｒｒの次連結ノード２ｄが削除される。そして、同図（ｃ）の俯瞰図に示す様に、プレーヤキャラクタＣＰの表示モデルは、変更された骨格モデルＢＭに基づいて外皮が形成されることによって、左側の状態から全長が縮んだ右側の状態に変化する。
【００５３】
一方、右アナログレバー１２３６から左方向入力されるとともに左アナログレバー１２３８から右方向入力がされているが同時入力とは見なされない場合には、単に左アナログレバー１２３８への入力に応じた第１の操作力Ｆ１が前端ノード２ｆｒに作用し、右アナログレバー１２３６への入力に応じた第２の操作力Ｆ２が後端ノード２ｒｒに作用するように制御される。したがって、同図（ｄ）の場合、第１の操作力Ｆ１及び第２の操作力Ｆ２はプレーヤキャラクタＣＰの頭ＣＰｈと尾ＣＰｔを近づける様に作用する。結果、骨格モデルＢＭが当初湾曲した状態であれば、同図（ｄ）左側の状態のようにノードの削除は行われずに前端ノード２ｆｒと後端ノード２ｒｒが近づく格好となるので、同図（ｄ）右側の状態のように湾曲がより強い状態になる。
【００５４】
本実施形態では、このようにプレーヤキャラクタＣＰを操作する。したがって、プレーヤの立場からすると、できるだけプレーヤキャラクタＣＰの頭ＣＰｈと尾ＣＰｔがゲーム画面内に移され、且つ有る程度その周囲の状況が見えるように仮想カメラＣＭの撮影条件が制御されるのが望ましいことになる。尚、ここで言う「撮影条件」とは、仮想カメラＣＭのワールド座標系の位置（より詳しくは主たる撮影対象であるプレーヤキャラクタＣＰに対する相対位置）、視点方向、レンズの焦点距離の設定（或いは画角設定）を含む意味である。
【００５５】
［仮想カメラの撮影条件設定の原理］
図６は、本実施形態における仮想カメラの撮影条件の設定方法を説明するための概念図である。本実施形態ではプレーヤキャラクタＣＰを主たる撮影対象とするメイン仮想カメラＣＭ１は、基本的にプレーヤキャラクタＣＰを包含する包含領域の全体が仮想カメラの撮影画像に収まるように撮影条件が設定される。
【００５６】
具体的には、先ず同図（ａ）に示すように、現時点におけるプレーヤキャラクタＣＰを包含する包含領域１０を設定する。包含領域１０は、バウンダリボックスと同義であり、ワールド座標系のＸｗ軸・Ｙｗ軸・Ｚｗ軸の各軸に沿った平面で形成された直方体である。
【００５７】
包含領域１０が設定されたならば、ゲーム画面の縦幅・横幅と比較するためのプレーヤキャラクタＣＰの代表寸法を求める。
本実施形態では、最長の対角線１２を求める。対角線１２は、例えば包含領域１０の中心１１を挟んで対称位置関係にあるＸｗＺｗ平面に平行な腹側平面１４の頂点と、背側平面１８の頂点を結ぶ４つの線分となる。尚、同図では、対角線１２として腹側平面１４における頭部に近傍する頂点１６から、背側平面１８における尾部に近傍する頂点２０を結ぶ線分を示している。
【００５８】
求められた４つの対角線を代表寸法算出のための基礎寸法の候補とし、それぞれメイン仮想カメラＣＭ１の撮影画像の画像座標系に投影して、投影線分２１の画像座標系のＸｃ軸成分投影寸法Ｌｘ及びＹｃ軸成分投影寸法Ｌｙを求める。そして、求められたＸｃ軸成分投影寸法Ｌｘの最大値、Ｙｃ軸成分投影寸法Ｌｙの最大値をそれぞれ求める。これらがゲーム画面の縦幅・横幅と比較するためのプレーヤキャラクタＣＰの各軸方向の代表寸法となる。
【００５９】
代表寸法を求めたならば、更に両者を比較して何れか大きい方の投影寸法Ｌｍ（同図の場合Ｘｃ軸成分投影寸法Ｌｘ。）を選択し、選択された投影寸法Ｌｍが対応する画像座標軸方向の画面幅Ｗｘ（＝メイン仮想カメラＣＭ１の撮影画像の縦寸法）または画面幅Ｗｙ（＝メイン仮想カメラＣＭ１の撮影画像の横寸法）に対して所定比率（８０％）を成すように、メイン仮想カメラＣＭ１の撮影条件を決定する。
【００６０】
例えば、画角θｃを固定とするならば、仮想カメラＣＭの視線方向２６を包含領域１０の中心１１に向け、次式（１）で中心１１から仮想カメラＣＭの適正撮影距離Ｌｃを幾何的に求める。
【００６１】
適正撮影距離Ｌｃ＝（１００／８０×Ｌｍ）／２×ｔａｎ（θｃ／２）  ………（１）
【００６２】
勿論、適正撮影距離Ｌｃを一定にして画角θｃを求める構成としても良く、その場合も幾何的に画角θｃを求めることができる。また、適正撮影距離Ｌｃと画角θｃの両方を求めるとしても良い。例えば、ゲームの演出上の観点からメイン仮想カメラＣＭ１にプレーヤキャラクタＣＰを回り込むといったカメラワークさせたい場合には、あらかじめカメラワークを定義するデータを定義し、このデータにしたがって配置位置を決定してから画角θｃを求める。つまり、先に適正撮影距離Ｌｃを決定し、決定した適性撮影距離Ｌｃ基づいて画角θｃを求めるとしても良い。
【００６３】
また、基礎寸法として複数の対角線を用いたが、予め所定の対角線を用いる構成としても良い。例えば、同図示すように、腹側平面１４の頂点１６から背側平面１８の頂点２０を結ぶ対角線１２を所定の対角線としても、本実施形態のように紐状のワーム型キャラクタの場合、いずれの対角線を選択してもそう大きな差がうまれないので、演算負荷を低減することができる。
【００６４】
メイン仮想カメラＣＭ１を、プレーヤキャラクタＣＰに対して左右どちらの方向に配置するかは適宜設定することができる。例えば、本実施形態では左アナログレバー１２３８からの操作入力に応じて頭ＣＰｈの移動が制御され、右アナログレバー１２３６からの操作入力に応じて尾ＣＰｔの移動が制御されるので、仮想カメラＣＭをプレーヤキャラクタＣＰの左側に配置すると望ましい。なぜならば、ゲーム画面の左にプレーヤキャラクタＣＰの頭ＣＰｂ、画面右側に尾ＣＰｔが映されることになるのでゲームコントローラ１２３０における入力手段の配置関係と左右の位置関係が合致し自然な操作感が得られるからである。
【００６５】
この結果、プレーヤがプレーヤキャラクタＣＰを操作する上で基点となるプレーヤキャラクタＣＰの頭ＣＰｈと尾ＣＰｔが常にメイン仮想カメラＣＭ１によって写されるとともに、ある程度その周囲が写されるように制御される。また、代表寸法を算出する処理が極めて簡単であるので処理負荷の低減することができる。
【００６６】
［サブ画面表示の説明］
さて、本実施形態は上記の如くメイン仮想カメラＣＭ１の撮影条件を適当に設定した場合であっても、例えばビルの陰になって見えなくなるといった具合に、プレーヤキャラクタＣＰ（被写体）とメイン仮想カメラＣＭ１との間に障害物が存在し、必ずしもプレーヤキャラクタＣＰの全身が撮影されるとは限らない。そこで、プレーヤキャラクタＣＰを撮影するサブ仮想カメラを別途設定し、サブ仮想カメラで撮影した画像を別途、サブ画面で表示するように制御する。
【００６７】
図７は、本実施形態におけるサブ仮想カメラの設定と、サブ画面表示の概念を説明するための概念図である。同図（ａ）に示すように、本実施形態ではプレーヤキャラクタＣＰの全身を撮影するメイン仮想カメラＣＭ１に加えて、頭ＣＰｈを部分撮影する第１のサブ仮想カメラＣＭ２と、尾ＣＰｂを部分撮影する第２のサブ仮想カメラＣＭ３とが設定される。そして、同図（ｂ）に示すように、第１のサブ仮想カメラＣＭ２及び第２のサブ仮想カメラＣＭ３で撮影されたそれぞれの画像は、メイン仮想カメラＣＭ１で撮影された画像をベースとした主ゲーム画面Ｗ１上に、それよりも画像サイズが小さいサブ画面Ｗ２，Ｗ３として重ね表示される。
【００６８】
この結果、仮にメイン仮想カメラＣＭ１とプレーヤキャラクタＣＰとの間に他のオブジェクトが障害物として存在し、一時的に頭ＣＰｈや尾ＣＰｔが見えない状態であっても、サブ画面Ｗ２，Ｗ３でそれら各部の状態を見ることができるようになるので、プレーヤはプレーヤキャラクタＣＰの状態をもれなく認識可能となる。よって、操作性が向上し、例えば頭ＣＰｈを動かしたいのにゲーム画面に映っていないといった事態が起ってゲーム操作に支障が出るのを防ぐことができる。
【００６９】
また、本実施形態ではサブ仮想カメラはイベントの発生に伴っても設定される。ここで言う「イベント」とは、ゲームの進行に応じて特別に他のオブジェクトが登場したり、すでにゲーム空間に配置されているオブジェクトが所定のタイミングで何らかの動作を開始するといった一連の制御を言う。例えば、プレーヤキャラクタＣＰの敵キャラクタの登場や、渡れなかった川に倒木が倒れて橋が架かるといった内容が考えられる。そして、イベントが発生した場合、イベントに伴って登場したキャラクタや自動制御されたキャラクタを被写体とするサブ仮想カメラの一種としてイベント仮想カメラＣＭ４が設定され、撮影された画像は同様にサブ画面Ｗ４がポップアップ表示される。
【００７０】
本実施形態では、イベント仮想カメラＣＭ４の撮影条件は、被写体となるキャラクタを映すように設定されるとともに、画角内にプレーヤキャラクタＣＰの一部が写るように設定される場合を含む。したがって、イベントが発生するとサブ画面Ｗ４が新たに表示され、これを見ることでプレーヤは、ゲーム空間内でどのような事態が起きたのか、そしてそれはプレーヤキャラクタＣＰに対して何所で起きているかを即座に知ることが可能になる。
【００７１】
本実施形態のように紐状体のキャラクタの両端を移動させるようにして操作するゲームでは、操作感と操作性を維持するためには、先に述べたようにゲーム画面内にプレーヤキャラクタＣＰを有る程度大きく表示しなければならなくなる。このことは逆に周囲の状況が写る範囲を小さくすることにもなるので、周囲の状況が認識しにくく操作性を低下させる原因ともなりえる。しかし、本実施形態のようにイベント仮想カメラＣＭ４を設定し、その撮影画像をサブ画面表示することよって、そうした不利な要因を取り除くことも可能になる。
【００７２】
［機能ブロックの説明］
次に、上述のような特徴を実現するための機能構成について説明する。
図８は、本実施形態における機能構成の一例を示す機能ブロック図である。同図に示すように本実施形態では、操作入力部１００と、処理部２００と、音出力部３５０と、画像表示部３６０と、通信部３７０と、記憶部５００とを備える。
【００７３】
操作入力部１００は、プレーヤによって為された各種の操作入力に応じて操作入力信号を処理部２００に出力する。図１では、ゲームコントローラ１２３０が操作入力部１００に該当する。そして、本実施形態における操作入力部１００は、一つの入力操作で少なくとも２軸の方向入力を可能にする第１方向入力部１０２及び第２方向入力部１０４を備える。
【００７４】
第１方向入力部１０２及び第２方向入力部１０４は、例えばアナログレバーやトラックパッド、マウス、トラックボール、タッチパネルによって実現される。また、少なくとも２軸以上の検出軸を有する多軸検出型加速度センサまたは検出軸方向を違えて組み合わされた単軸検出型加速度センサの集合、少なくとも２方向以上の検出方向を可能にする多方向検出型傾斜センサまたは検出方向を違えて組み合わされた単方向検出型傾斜センサの集合などによっても実現できる。本実施形態の第１方向入力部１０２及び第２方向入力部１０４は、図１の右アナログレバー１２３６ならびに左アナログレバー１２３８が該当し、プレーヤキャラクタＣＰの頭ＣＰｈ及び尾ＣＰｔそれぞれの移動方向と移動量の入力に用いられる。
【００７５】
処理部２００は、例えばマイクロプロセッサやＡＳＩＣ（特定用途向け集積回路）、ＩＣメモリなどの電子部品によって実現され、操作入力部１００や記憶部５００を含むゲーム装置１２００の各機能部との間でデータの入出力を行うとともに、所定のプログラムやデータ、操作入力部１００からの操作入力信号に基づいて各種の演算処理を実行して、ゲーム装置１２００の動作を制御する。図１では、ゲーム装置本体１２０１に内蔵された制御ユニット１２１０が処理部２００に該当する。
そして本実施形態における処理部２００は、ゲーム演算部２１０と、音生成部２５０と、画像生成部２６０と、通信制御部２７０とを備える。
【００７６】
ゲーム演算部２１０は、ゲームの進行に係る処理を実行する。例えば、ゲーム空間を仮想空間中に形成する処理や、仮想空間中に配置されたプレーヤキャラクタＰＣ以外のキャラクタの動作制御処理、ヒット判定処理、物理演算処理、ゲーム結果の算出処理、外皮の形成処理が実行対象に含まれる。そして本実施形態のゲーム演算部２１０は、キャラクタ制御部２１２と、仮想カメラ制御部２１４とを含んでいる。
【００７７】
キャラクタ制御部２１２は、プレーヤキャラクタＣＰのオブジェクトの大きさ及び／又は形状を変化させて動作制御を実行する。例えばプレーヤキャラクタＣＰの伸縮処理並びに移動処理、プレーヤキャラクタ以外のノンプレーヤキャラクタ（ＮＰＣ）の動作制御が該当する。
【００７８】
仮想カメラ制御部２１４は、仮想カメラの制御に係る処理を実行する。本実施形態ではメイン仮想カメラＣＭ１、サブ仮想カメラＣＭ２及びＣＭ３、イベント仮想カメラＣＭ４の撮影条件を設定する処理や、仮想カメラの配置や削除の処理、仮想カメラの移動制御処理が実行対象に含まれる。
【００７９】
音生成部２５０は、例えばデジタルシグナルプロセッサ（ＤＳＰ）などのプロセッサやその制御プログラムによって実現され、ゲーム演算部２１０による処理結果に基づいてゲームに係る効果音やＢＧＭ、各種操作音の音信号を生成し、音出力部３５０に出力する。
【００８０】
音出力部３５０は、音生成部２５０から入力される音信号に基づいて効果音やＢＧＭ等を音出力する装置によって実現される。図１ではビデオモニタ１２２０のスピーカ１２２４がこれに該当する。
【００８１】
画像生成部２６０は、例えば、デジタルシグナルプロセッサ（ＤＳＰ）などのプロセッサ、その制御プログラム、フレームバッファ等の描画フレーム用ＩＣメモリ等によって実現される。画像生成部２６０は、ゲーム演算部２１０による処理結果に基づいて１フレーム時間（１／６０秒）で１枚のゲーム画像を生成し、生成したゲーム画像の画像信号を画像表示部３６０に出力する。
【００８２】
そして、本実施形態では、画像生成部２６０はサブ画像表示制御部２６２を備える。
サブ画像表示制御部２６２は、メイン仮想カメラＣＭ１で撮影された画像、サブ仮想カメラＣＭ２で撮影された画像，サブ仮想カメラＣＭ３で撮影された画像、イベント仮想カメラＣＭ４で撮影された画像を含む画像群のうち、何れか一つの画像を主ゲーム画面Ｗ１として表示させるとともに、その他の画像をサブ画面Ｗ２〜Ｗ４として主ゲーム画面に合成表示する制御を実行する。また、プレーヤによるサブ画面の選択操作に応じて主ゲーム画面Ｗ１と選択されたサブ画面との間で、各々の画面で表示する画像を切り換える処理を実行する。
【００８３】
画像表示部３６０は、画像生成部２６０から入力される画像信号に基づいて各種ゲーム画像を表示する。例えば、フラットパネルディスプレイ、ブラウン管（ＣＲＴ）、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。図１ではビデオモニタ１２２０のディスプレイ１２２２が該当する。
【００８４】
通信制御部２７０は、データ通信に係るデータ処理を実行し、通信部３７０を介して外部装置とのデータのやりとりを実現する。
【００８５】
通信部３７０は、通信回線２と接続して通信を実現する。例えば、無線通信機、モデム、ＴＡ（ターミナルアダプタ）、有線用の通信ケーブルのジャックや制御回路等によって実現され、図１では通信装置１２１２、近距離無線モジュール１２１４がこれに該当する。
【００８６】
記憶部５００は、処理部２００にゲーム装置１２００を統合的に制御させるための諸機能を実現するためのシステムプログラムや、ゲームを実行させるために必要なゲームプログラム、各種データ等を記憶する。また、処理部２００の作業領域として用いられ、処理部２００が各種プログラムに従って実行した演算結果や操作部１００から入力される入力データ等を一時的に記憶する。この機能は、例えばＲＡＭやＲＯＭなどのＩＣメモリ、ハードディスク等の磁気ディスク、ＣＤ−ＲＯＭやＤＶＤなどの光学ディスクなどによって実現される。
【００８７】
本実施形態では、記憶部５００はゲームプログラム５０２と、サブ画像表示制御プログラム５０８とを記憶している。ゲームプログラム５０２は更にキャラクタ制御プログラム５０４と、仮想カメラ制御プログラム５０６０を含んでいる。
処理部２００がゲームプログラム５０２を読み出して実行することによって、処理部２００にゲーム演算部２１０としての機能を実現させることができる。また、処理部２００がサブ画面表示制御プログラム５０８を読み出して実行することによって、画像生成部２６０にサブ画面表示制御部２６２としての機能を実現させることができる。
【００８８】
また、記憶部５００には、予め用意されるデータとしてゲーム空間設定データ５２０、キャラクタ初期設定データ５２２、イベント設定データ５３２、メイン仮想カメラ初期設定データ５３６、頭部撮影条件候補データ５３８、尾部撮影条件候補データ５４０、イベント撮影条件候補データ５４２が記憶されている。
【００８９】
更にゲームの進行に伴って随時書き換えられるデータとして、キャラクタ制御データ５２４、作用力データ５３０、包含領域設定データ５３４、撮影条件データ５４４、画面表示位置設定データ５４６を記憶する。また、ゲームの進行に係る処理を実行するにあたり適宜必要となるタイマー値なども記憶される。本実施形態では、ノード増減許可タイマー５４８、撮影条件変更許可タイマー５５０を含む各種タイマーのタイマー値が一時的に記憶される。
【００９０】
ゲーム空間設定データ５２０には、仮想空間にゲーム空間を形成するための各種データが格納されている。例えば、プレーヤキャラクタＣＰが移動する地表や建物を含む配置物に関するモデルデータやテクスチャデータ及びモーションデータが含まれる。
【００９１】
キャラクタ初期設定データ５２２には、プレーヤキャラクタＣＰの初期設定データが格納されている。本実施形態では、ゲームスタート時におけるプレーヤキャラクタＣＰはある一定の長さの胴ＣＰｂを有するように設定されている。すなわち、所定数のノード２が配列された骨格モデルＢＭ及びそのヒット判定モデルＨＭに関するデータが格納されている。また、プレーヤキャラクタＣＰの頭ＣＰｈや尾ＣＰｔのモデルデータ、胴ＣＰｂの部分に外皮を形成する際のテクスチャデータなどが格納されている。
【００９２】
そして、プレーヤキャラクタＣＰをゲーム実行中に制御するためのデータは、キャラクタ制御データ５２４に格納される。
図９は、本実施形態におけるキャラクタ制御データ５２４のデータ構成例を示す図である。同図に示すように、キャラクタ制御データ５２４は、その時点におけるプレーヤキャラクタＣＰの骨格モデルに関するデータである制御データ５２５を含む。
【００９３】
骨格モデル制御データ５２５には、ノード識別情報５２５ａに対応づけて、該ノードのゲーム空間座標系における位置座標５２５ｂと、頭側連結ノード識別情報５２５ｃと、尾側連結ノード識別情報５２５ｄと、エフェクタ情報５２５ｅとが格納されている。
【００９４】
頭側連結ノード識別情報５２５ｃ及び尾側連結ノード識別情報５２５ｄとしては、当該ノードの配列順前後（頭側が前で尾側が後。）に連結されているノードの識別情報が設定される。すなわち、前者は当該ノードの頭側（前方側）に連結されているノードを定義し、後者は当該ノードの尾側（後方側）に連結されているノードを定義する。前端ノード２ｆｒ或いは後端ノード２ｒｒである場合には、その先に連結するノードが無いことになるので、例えば同図に示すように「ＮＵＬＬ」が格納される。
【００９５】
エフェクタ情報５２５ｅは、当該ノードが右アナログレバー１２３６又は左アナログレバー１２３８からの操作入力に応じた仮想力（操作力）を作用されるノードであるか否かを示している。例えば同図のように、右アナログレバー１２３６による操作入力に応じた仮想力が作用するノードには「２」、左アナログレバー１２３８による操作入力に応じた仮想力が作用するノードには「１」、それ以外には「０」が格納されている。
【００９６】
そして、本実施形態においてプレーヤキャラクタＣＰを伸ばす場合には、骨格モデル制御データ５２５に新たにノードを追加登録し、縮める場合には登録されているノードを削除する制御を実行する。ノードが追加或いは削除されることによって骨格モデルＢＭが伸びたり縮んだりする。
【００９７】
作用力データ５３０には、各ノードに作用している力に関する情報が格納される。
図１０は、本実施形態における作用力データ５３０のデータ構成例を示す図である。同図に示すように、例えばノード識別情報５３０ａに対応づけて、操作力ベクトル５３０ｂ、外力ベクトル５３０ｃ、及びこれらの力の合力に当る作用力ベクトル５３０ｄが格納されている。その他、ゲーム中にプレーヤキャラクタＣＰの動作制御に影響を与える力を適宜設定することができる。
【００９８】
操作力ベクトル５３０ｂは、右アナログレバー１２３６又は左アナログレバー１２３８による操作入力に応じて設定される仮想力（＝操作力）が、エフェクタ情報５２５ｅで設定されたノードに作用し、更に骨格モデルＢＭの連結構造に従って各ノードに作用している力のベクトルを格納する。つまり、エフェクタ情報５２５ｅで「２」が格納されているノードには右アナログレバー１２３６への操作入力に応じた操作力が直接作用するので、該操作力がそのままの状態で格納される。
【００９９】
一方、胴部分にあたるノードには操作力が直接的には作用しないが、先端のノードから順次連結した設定であるので、連結子４を伝って作用した結果としての力が格納される。したがって、その時点における骨格モデルＢＭが一直線上であれば、先頭のノード作用した操作力と同じ操作力が各ノードの操作力ベクトル５３０ｂに格納されるが、骨格モデルＢＭが湾曲している場合にはノード間の連結関係に従って先頭のノード作用した操作力の連結子方向成分の分力が格納されることになる。
【０１００】
外力ベクトル５３０ｃは、ゲーム空間自体に場として設定されている力や、ゲーム空間に配置されている他のオブジェクトの影響によって作用する仮想力を格納する。例えば、重力、他のオブジェクトとの衝突や接触によって生じる力や、環境風を受けることによって生じる力がこれに含まれる。その他、電磁力や、プレーヤキャラクタＣＰが好物に惹きつけられる様子を表す仮想力など適宜含めることができる。
【０１０１】
イベント設定データ５３２には、イベントの発生に必要なデータが格納されている。例えば、イベント毎に当該イベントを実行するための条件、イベントで登場する或いは動作されるオブジェクトのデータ並びにモーションデータが含まれる。
【０１０２】
包含領域設定データ５３４は、メイン仮想カメラＣＭ１の撮影条件を決定するために必要な包含領域１０を定義するデータを格納する。例えば、包含領域１０の頂点などの座標値や中心１１の座標値、対角線１２の情報を格納する。
【０１０３】
メイン仮想カメラ初期設定データ５３６は、メイン仮想カメラＣＭ１の撮影条件の初期設定を格納している。具体的には、メイン仮想カメラＣＭ１の撮影条件を決定する際に用いられる仮配置位置を算出するためのプレーヤキャラクタＣＰに対する相対位置座標、視線方向ベクトル、初期状態の画角（レンズの焦点距離でも可。）などが定義されている。
【０１０４】
頭部撮影条件候補データ５３８及び尾部撮影条件候補データ５４０は、サブ仮想カメラでプレーヤキャラクタＣＰの所定部分を撮影する撮影条件の選択肢を格納している。前者が、頭ＣＰｈを被写体とする第１のサブ仮想カメラＣＭ２に適用され、後者が尾ＣＰｔを被写体とする第２のサブ仮想カメラＣＭ３に適用される。これらのデータに格納されている撮影条件の候補は、撮影される部位に応じてゲームの操作性と演出の観点から適当に設定されている。
【０１０５】
図１１は、本実施形態における頭部撮影条件候補データ５３８のデータ構成の一例と、該例における撮影条件の概要を示す図である。同図に示すように、頭部撮影条件候補データ５３８には、設定５３８ａ毎に、ゲームの操作性と演出の観点から適当に設定された撮影条件５３８ｂが対応付けて格納されている。撮影条件５３８ｂには、例えばプレーヤキャラクタＣＰの代表点に対する相対位置座標や、視線方向の先を示す注視点、画角を決定するためのレンズの焦点距離が含まれる。
【０１０６】
本実施形態では、撮影画像内に頭ＣＰｈとその周囲がある撮影範囲内に収まるように設定された撮影条件（設定５３８ａがＣＳ０１，ＣＳ０２の例）や、頭部ＣＰｈの後方或いは頭部ＣＰｔの位置から当該部位の移動方向に沿った方向に視線方向を向けるように設定された撮影条件（設定５３８ａがＣＳ０３，ＣＳ０４の例）、頭ＣＰｈを正面とその周囲を撮影するように設定された撮影条件が含まれる。その他、頭部ＣＰｈの正面斜め上から撮影画像内に頭ＣＰｈとその周囲がある撮影範囲内に収まるように設定された撮影条件など、頭部ＣＰｈを移動させる際に周囲の状況が分かりやすいと思われる設定を適宜設定すると良い。
【０１０７】
尚、尾部撮影条件候補データ５４０は、基本的に撮影対象となる部分が異なるだけで、撮影条件の設定の考え方は同様であり、頭部撮影条件候補データ５３８と同様のデータ構成を有する。頭ＣＰｈ、尾ＣＰｔ以外にも部分撮影する場合には、同様に対応する撮影条件候補データを適宜追加する。
【０１０８】
イベント撮影条件候補データ５４２は、イベント仮想カメラＣＭ４でイベントキャラクタＣＩを撮影する撮影条件の選択肢を格納している。
図１２は、本実施形態におけるイベント撮影条件候補データ５４２のデータ構成の一例を示す図とその概念図である。同図に示すように、イベント撮影条件候補データ５４２には、イベント設定データ５３２で定義されているイベントのイベント番号５４２ａに対応づけて複数の設定５４２ｂ及び撮影条件５４２ｃが格納されている。撮影条件５４２ｃには、例えばイベントキャラクタＩＣの代表点に対する相対位置座標や、視線方向（或いは注視点）、画角を決定するためのレンズの焦点距離が含まれる。本実施形態では、イベントキャラクタＣＩの少なくとも一部がイベント仮想カメラＣＭ４で撮影される画像に写り、且つ同画像内にプレーヤキャラクタＣＰの一部が写るように考慮された撮影条件（設定５４２ｂがＣＳ１１、ＣＳ１２の例）や、イベントキャラクタＣＩとその周囲を撮影条件（設定５３８ａがＣＳ１３の例）が含まれる。
【０１０９】
前者のような撮影条件をイベント仮想カメラＣＭ４で撮影される画像内にイベントキャラクタとプレーヤキャラクタの両方が写るように設定するのは、プレーヤに両キャラクタの相対位置関係を見せるためであり、プレーヤキャラクタＣＰをどのように操作すればよいか判断し易くするためである。しかし、ゲームの内容によってはイベントキャラクタの相対位置を不明にしたほうが演出上好都合である場合には、後者のような撮影条件、すなわちイベントキャラクタＩＣが画角内に入るがプレーヤキャラクタＣＰは入らないといった撮影条件のみで構成するとしても良い。
【０１１０】
撮影条件データ５４４には、ゲーム実行中における現在の仮想カメラの撮影条件を含む仮想カメラの制御に係る情報を格納する。例えば、現在の仮想カメラのワールド座標系における位置座標値、仮想カメラの視線方向、画角θｃが含まれる。
【０１１１】
画像表示位置設定データ５４６には、主ゲーム画面、各サブ画面の表示位置、表示形態に関する情報が格納されている。
図１３は、本実施形態における画像表示位置設定データ５４６のデータ構成の一例を示すデータ構成図である。同図に示すように画像表示位置設定データ５４６には、画面種類５４６ａの主ゲーム画面、第１サブ画面、第２サブ画面、イベントサブ画面それぞれに対応づけて、画面表示範囲座標５４６ｂと、当該画面に表示される画像のソースがどの仮想カメラであるかを定義する対応仮想カメラ５４６ｃとが格納される。本実施形態では、プレーヤによるサブ画面の選択操作に応じて主ゲーム画面に表示される画像と選択されたサブ画面に表示される画像を切換制御するが、その場合該当する画面種類５４６ａに対応する対応仮想カメラ５４６ｃの定義を入れ換える。
【０１１２】
尚、主ゲーム画面Ｗ１の大きさは、ディスプレイ１２２２の画像表示範囲の大きさに相当し、画面全体で表示するように設定されている。また、同図の例ではサブ仮想カメラが２つ、イベント仮想カメラが一つ登録された例となっているが、ゲームの内容やプレーヤキャラクタのデザイン等に応じて、サブ仮想カメラやイベント仮想カメラの数は適宜設定可能である。また、サブ画面Ｗ２〜Ｗ４の表示位置や表示形態も同図（ｂ）の例に限るものではない。例えば、上重ね形態に限らずサブ画面Ｗ２〜Ｗ４を主ゲーム画面Ｗ１と並列表示する形態としても良い。
【０１１３】
ノード増減許可タイマー５４８は、時間経過を計時するタイマーのカウント値を格納する。本実施形態では、プレーヤキャラクタＣＰの伸長或いは短縮の制御が行われていない状態の時間経過を計時する。計時された時間、すなわちカウント値が所定の基準に満たない間は、レーヤキャラクタＣＰの伸縮制御が制限され実行されない。
【０１１４】
撮影条件変更許可タイマー５５０は、所定値からカウントダウンして撮影条件の再設定が許可される時間間隔を計時する。すなわち、本実施形態では本タイマーが基準時間を計時される都度、撮影条件の変更が許可される。尚、ゲーム開始時点における撮影条件変更許可タイマー５５０の初期値は「０」である。
【０１１５】
［動作の説明］
次に、本発明の動作について説明する。
図１４は、本実施形態における処理の流れを説明するためのフローチャートである。ここで説明される処理は、処理部２００がシステムプログラム５０１、ゲームプログラム５０２及びサブ画面表示制御プログラム５０８を読み出して実行することによって実現される。
【０１１６】
同図に示すように、ゲーム演算部２１０は先ずゲーム空間設定データ５２０、キャラクタ初期設定データ５２２、メイン仮想カメラ初期設定データ５３６を参照して、仮想空間中にゲーム空間を形成するとともに、形成したゲーム空間にプレーヤキャラクタＰＣと、プレーヤキャラクタＣＰを撮影するメイン仮想カメラＣＭ１を配置する（ステップＳ２）。
【０１１７】
プレーヤキャラクタＣＰの配置に伴って、キャラクタ制御データ５２４の骨格モデル制御データ５２５に初期状態の骨格モデルＢＭが登録され、登録された骨格モデルＢＭに従って外皮を形成処理してプレーヤキャラクタＣＰの表示モデルがゲーム空間に配置される。骨格モデルＢＭに外皮を形成する処理は、公知の技術を適宜利用可能であるので詳細な説明は省略する。撮影条件データ５４４には、メイン仮想カメラＣＭ１の初期の撮影条件が格納される。また、ゲームスタート時点からゲーム空間に配置されるＮＰＣが有る場合には、この段階で配置する。
【０１１８】
次に、ゲームが開始されたならば、ゲーム演算部２１０は、予め動作が設定されているオブジェクト（例えば、ＮＰＣなど）の動作を制御する（ステップＳ４）。例えば、風になびく木々、飛行船、プレーヤキャラクタＣＰの移動を邪魔するおもちゃの自動車などを設定するならば、それぞれ所定のモーションデータに基づいて移動制御する。
【０１１９】
次に、ゲーム演算部２１０は、プレーヤの操作入力に従ってプレーヤキャラクタＣＰを伸長或いは短縮させる任意伸縮処理を実行する（ステップＳ６）。
図１５は、本実施形態における任意伸縮処理の流れを説明するためのフローチャートである。同図に示すように、任意伸縮処理では先ず、ゲーム演算部２１０がノード増減許可タイマー５４８のカウントを所定数加算し（ステップＳ３０）、加算した後のノード増減許可タイマー５４８のカウント値が基準値に達しているか否かを判定する（ステップＳ３２）。
【０１２０】
ノード増減許可タイマー５４８のカウント値が基準値に達していなければ（ステップＳ３２のＮＯ）、任意伸縮処理をそのまま終了する。
一方、ノード増減許可タイマー５４８のカウント値が基準値に達している場合（ステップＳ３２のＹＥＳ）、ゲーム演算部２１０は更に所定の任意伸長操作が入力されているか否かを判定する（ステップＳ３４）。具体的には、右アナログレバー１２３６から右方向入力され、同時に左アナログレバー１２３８から左方向入力が入力されたか否かを判定する。すなわち、第１方向入力部１０２と第２方向入力部１０４から、同時入力と見なせる程度の時間差で、互いに相反する方向に方向入力されたか否かを判定する。したがって、左右に限らず両レバーで上下互い違いに入力された場合にも任意伸長操作が入力されたと判定する構成としても良い。
【０１２１】
そして、任意伸長操作が入力されたと判定された場合（ステップＳ３４のＹＥＳ）、ゲーム演算部２１０は、前端ノード（頭ＣＰｈのノード）を接続子４の長さＬだけ、前端ノード２ｆｒを、次連結ノードから当該全体ノードを向いた方向に移動させ（ステップＳ３６）、移動した先端ノード２ｆｒとその次連結ノードとの間に新たなノードを追加する（ステップＳ３８）。
【０１２２】
具体的には、例えば図９の例ならば、「ＮＯＤＥ１」がプレーヤキャラクタＣＰの前端ノード２ｆｒに当るので、その次に連結されている「ＮＯＤＥ２」から「ＮＯＤＥ１」へ向かうベクトルの方向へ、「ＮＯＤＥ１」を接続子４の長さＬだけ移動させる。そして、新たに追加されるノードに適当なノード識別情報（例えば「ＮＯＤＥ６」）を付与して、骨格モデル制御データ５２５に登録する。このとき、位置座標５２５ｂは、「ＮＯＤＥ１」と「ＮＯＤＥ２」の中間位置あるいは「ＮＯＤＥ１」の元位置とする。頭側連結ノード識別情報５２５ｃには「ＮＯＤＥ１」を格納し、尾側連結ノード識別情報５２５ｄには「ＮＯＤＥ２」を格納する。そして、「ＮＯＤＥ１」の尾側連結ノード識別情報５２５ｄを「ＮＯＤＥ２」から「ＮＯＤＥ６」に更新し、「ＮＯＤＥ２」の頭側連結ノード識別情報５２５ｃを「ＮＯＤＥ１」から「ＮＯＤＥ６」に更新する。エフェクタ情報５２５ｅには「０」を格納する。
【０１２３】
こうしてキャラクタ制御データ５２４に登録されている骨格モデルＢＭに新たなノードを追加したならば、ゲーム演算部２１０は同様にして後端ノード２ｒｒ（尾ＣＰｔのノード）を接続子４の長さＬだけ、後端ノード２ｒｒの一つ前に連結された次連結ノードから後端ノードを向いた方向に移動させ（ステップＳ４０）、移動した後端ノード２ｒｒと一つ前に連結された次連結ノードとの間に新たなノードを追加する（ステップＳ４２）。
そして、ノード増減許可タイマー５４８をリセットして「０」に戻してリスタートし（ステップＳ４４）、任意短縮処理を終了する。
【０１２４】
ステップＳ３４において否定判定がされた場合（ステップＳ３４のＮＯ）、ゲーム演算部２１０は特定の任意短縮操作が入力されたか否かを判定する（ステップＳ５０）。具体的には、右アナログレバー１２３６から左方向入力され、同時に左アナログレバー１２３８から右方向入力がされたか否かを判定する。すなわち、第１方向入力部１０２と第２方向入力部１０４から、同時と見なせるほどの時間差で互いに近寄るように方向入力されたか否かを判定する。したがって、左右に限らず両レバーで上下から寄せるように入力された場合にも任意短縮操作が入力されたと判定する構成としても良い。
【０１２５】
任意短縮操作が入力されなかったと判定された場合には（ステップＳ５０のＮＯ）、ゲーム演算部２１０は任意短縮処理を終了する。また、骨格モデルＢＭの全ノード数が２以下の場合にも任意短縮処理を終了する。
【０１２６】
一方、任意短縮操作が入力されたと判定された場合には（ステップＳ５０のＹＥＳ）、ゲーム演算部２１０は前端ノードの次連結ノードと、後端ノードの次連結ノードを削除し（ステップＳ５２）、前端ノードと後端ノードを夫々の削除した次連結ノードの位置に移動させる（ステップＳ５４）。
【０１２７】
具体的には、例えば図９の例ならば、前端ノードに当る「ＮＯＤＥ１」と、後端ノードに当る「ＮＯＤＥ５」の次に連結する「ＮＯＤＥ２」と「ＮＯＤＥ４」を削除する。そして、「ＮＯＤＥ１」の位置座標５２５ｂを「ＮＯＤＥ２」の値、「ＮＯＤＥ５」の位置座標５２５ｂを「ＮＯＤＥ４」の値に変更する。
更に、「ＮＯＤＥ１」の尾側連結ノード識別情報５２５ｄを「ＮＯＤＥ３」に変更し、「ＮＯＤＥ３」の頭側連結ノード識別情報５２５ｃを「ＮＯＤＥ１」に変更する。また、「ＮＯＤＥ５」の頭側連結ノード識別情報５２５ｃを「ＮＯＤＥ３」に変更し、「ＮＯＤＥ３」の尾側連結ノード識別情報５２５ｄを「ＮＯＤＥ５」に変更する。
【０１２８】
以上の任意伸縮処理によってプレーヤは任意にプレーヤキャラクタＣＰを伸ばしたり縮めたりすることできるようになる。
また、本実施形態では、ノード増減許可タイマー５４８が設けられ、カウント値が基準値に達していない場合、換言すればプレーヤキャラクタＣＰが伸長或いは短縮されない状態がある一定時間以上経過していない場合には、プレーヤが任意伸長操作や任意短縮操作を入力しても、伸長或いは短縮の制御は実行されない。これによって、伸長或いは短縮する動作にある種の時間的な「溜め」を作り、ゆっくりとプレーヤキャラクタＣＰの胴が伸びたり縮んだりする際の抵抗感を表現し、あたかも胴ＣＰｂがある程度生き物らしく成長や変形によって伸び縮みしているかのように見せることができる。
【０１２９】
任意伸縮処理を終了したならば、図１４のフローに戻って、ゲーム演算部２１０は次に作用力設定処理（ステップＳ８）を実行する。作用力設定処理は、プレーヤキャラクタＣＰに作用する力の設定と、その合力である作用力の算出に関する処理である。
【０１３０】
図１６は、本実施形態における作用力設定処理の流れを説明するためのフローチャートである。同図に示すように、作用力設定処理では先ず、プレーヤによる２種類の方向入力に応じた操作力をプレーヤキャラクタＣＰに設定する（ステップＳ７０〜７８）。
具体的には、左アナログレバー１２３８に入力されている傾倒方向と傾倒量に応じた第１の操作力Ｆ１（図３参照）を決定し、プレーヤキャラクタＣＰの頭ＣＰｈに対応する前端ノード２ｆｒに設定する（ステップＳ７０）。そして、前端ノード２ｆｒから各ノードに連結子４を介して伝わる操作力を先端からの連結順に算出して設定する（ステップＳ７２）。図１０の例で言うと、前端ノード２ｆｒは「ＮＯＤＥ１」とされる。したがって、設定された第１の操作力のベクトルは、作用力ベクトルデータ５３０の「ＮＯＤＥ１」に対応する操作力ベクトル５３０ｂに格納され、同様に第１の操作力ベクトルが各ノードに作用する分力が求められて各々に対応する操作力ベクトル５３０ｂに格納される。
【０１３１】
次に、ゲーム演算部２１０は、右アナログレバー１２３６に入力されている傾倒方向と傾倒量に応じた第２の操作力Ｆ２（図３参照）を決定し、プレーヤキャラクタＣＰの尾ＣＰｔに対応する後端ノード２ｒｒに設定する（ステップＳ７４）。
【０１３２】
次いで、後端ノードから各ノードに連結子４を介して伝わる第２の操作力の分力を連結順後ろから順番に算出し（ステップＳ７６）、算出した第２の操作力の分力と、ステップＳ１００並びにＳ１０２で算出されて各ノードの操作力ベクトル５３０ｂに格納されているベクトルとのベクトル和を求めて、操作力ベクトル５３０ｂを更新する（ステップＳ７８）。
【０１３３】
操作力の設定に係る処理を終了したならば、ゲーム演算部２１０は次に、プレーヤキャラクタＣＰに作用する外力を設定するために外力設定処理を実行する（ステップＳ８０）。外力設定処理では、骨格モデルＢＭの各ノードにについて、プレーヤキャラクタＣＰに作用する重力や電磁力、風力などゲーム空間に環境要因として設定されている力、或いは他のオブジェクトとの衝突によって受ける力などを算出し、算出した力を作用力データ５３０の外力ベクトル５３０ｃに格納する。
【０１３４】
外力設定処理を終了したならば、ゲーム演算部２１０は全ノードについて、操作力、外力及び特定力の合力を求め、それぞれの作用力ベクトル５３０ｄとして作用力データ５３０に格納して（ステップＳ８２）、作用力設定処理を終了する。
【０１３５】
作用力設定処理が終了したならば、図１４のフローに戻って、ゲーム演算部２１０は次にプレーヤキャラクタ移動制御処理を実行する（ステップＳ１０）。各ノードそれぞれに作用力ベクトル５３０ｄが作用し、且つ骨格モデルＢＭの可動条件を維持して、次のゲーム画面の描画タイミング（例えば、１／６０秒後）における位置座標を算出する。算出方法は、公知の物理演算処理によっても実現できる。そして、骨格モデル制御データ５２５の位置座標５２５ｂを、新たに算出した位置座標で更新する。
【０１３６】
次に、ゲーム演算部２１０は、イベント設定データ５３２を参照してイベントを実行する（ステップＳ１２）。すなわち、ゲーム進行状態がイベント設定データ５３２で定義されている条件を満たしている場合、該条件に対応づけられたイベントを実行する。本実施形態では、例えば図７で示したように、イベントキャラクタＣＩが登場してプレーヤキャラクタＣＰに向かって突進し、プレーヤキャラクタＣＰの行動を邪魔しようとイベントが含まれている。
【０１３７】
次に、ゲーム演算部２１０は、前回の撮影条件の変更から所定時間経過したか否かを判定する（ステップＳ１４）。具体的には、撮影条件変更許可タイマー５５０の値が「０（所定時間計時済み）」であるか否かを参照し、「０」であれば所定時間経過したと判定する。ゲーム開始時点における撮影条件変更許可タイマー５５０の初期値は「０」なので、ゲーム開始後最初に本ステップを実行する場合はそのまま次のステップに移行する（ステップＳ１４のＹＥＳ）。
【０１３８】
前回の撮影条件の変更から所定時間経過していたならば、ゲーム演算部２１０は次にイベントが実行中であるか否かを判定する（ステップＳ１６）。例えば、本実施形態ではイベントキャラクタＣＩがゲーム空間に登場してから所定時間が経過するまでを一つのイベントとして見なす。その他、例えば「樹木のオブジェクトが倒れて川に橋を架ける」といったイベントの場合には、樹木が倒れきって所定時間経過するまでを一つのイベントとするなど適宜設定する。
そして、イベントが実行中であると判定された場合（ステップＳ１６のＹＥＳ）、ゲーム演算部２１０はイベント仮想カメラ設定処理を実行する（ステップＳ１８）。イベント仮想カメラ設定処理は、イベントの発生にともなってイベントキャラクタＣＩを撮影するイベント仮想カメラＣＭ４を設定し、イベントが実行されている間、撮影を制御する処理である。
【０１３９】
図１７は、本実施形態におけるイベント仮想カメラ設定処理の流れを説明するためのフローチャートである。イベント仮想カメラ設定処理では、ゲーム演算部２１０は先ずイベント撮影条件候補データ５４２を参照して、予め定義されている撮影条件５４２ｃの中の何れかをランダムに選択し（ステップＳ９０）、選択された撮影条件候補に基づいて撮影した場合に、イベントキャラクタＣＩが撮影範囲内に写るか否かを判定する（ステップＳ９２）。具体的には、選択された撮影条件で配置されるイベント仮想カメラＣＭ４とイベントキャラクタＩＣとの間に他のオブジェクトが存在するか否かを判定し、他のオブジェクトが存在しなければイベントキャラクタＣＩが撮影範囲内に写ると判定する。
【０１４０】
そして、イベントキャラクタＣＩが撮影範囲内に写ると判定された場合には（ステップＳ９２のＹＥＳ）、現在選択されている撮影条件候補をそのままイベント仮想カメラＣＭ４の撮影条件として、撮影条件データ５４４に格納するとともにイベント仮想カメラＣＭ４をゲーム空間中に配置する（ステップＳ９４）。そして、イベント仮想カメラ設定処理を終了して、図１４のフローに戻る。
【０１４１】
尚、図１４のフローにおいて、ステップＳ１６で実行中のイベントが無いと判定された場合には（ステップＳ１７）、イベント仮想カメラＣＭ４で撮影する必要性がなくなったと判断して、ゲーム演算部２１０はイベント仮想カメラＣＭ４の設定を解除する（ステップＳ１７）。
【０１４２】
さて、イベント仮想カメラ設定処理を実行したならば、ゲーム演算部２１０は次にメイン仮想カメラ設定処理を実行する（ステップＳ２０）。メイン仮想カメラ設定処理は、プレーヤキャラクタＣＰの全身が常に撮影されるように撮影条件を求めて、メイン仮想カメラＣＭ１を配置・制御する処理である。
【０１４３】
図１８は、本実施形態におけるメイン仮想カメラ設定処理の流れを説明するためのフローチャートである。同図に示すように、ゲーム演算部２１０は先ず、プレーヤキャラクタＣＰの移動制御に伴ってメイン仮想カメラＣＭ１を移動させるための仮配置位置を算出する（ステップＳ１１０）。具体的には、仮想カメラ初期設定データ５３６を参照してプレーヤキャラクタＣＰの代表点に対する所定の相対位置関係を取得して、仮配置位置を求める。つまり、プレーヤキャラクタＣＰが真直ぐに前進すればメイン仮想カメラＣＭ１を該前進方向に同じように直進移動させ、プレーヤキャラクタＣＰに対して常に所定の相対位置となるように仮配置位置を決める。
尚、仮配置位置の決定は、プレーヤキャラクタＣＰの移動と平行させるに限らず、例えばプレーヤキャラクタＣＰの上を定期的に左右に振れ回りするなどメイン仮想カメラＣＭ１のモーションが設定されている場合には、当該モーションに基づいて仮配置位置を決定する構成としても良い。
【０１４４】
次に、仮配置位置が決まったならば、ゲーム演算部２１０はプレーヤキャラクタＣＰの全体が撮影できるようにプレーヤキャラクタＣＰからの距離及び／又は画角を調整する処理を実行する。本実施形態では、プレーヤキャラクタＣＰの全体を包含する包含領域１０を設定し（ステップＳ１１２）、メイン仮想カメラＣＭ１で仮配置位置から撮影した場合に、包含領域１０の中心１１が画面の所定位置（例えば、撮影画面の中心。）に写るように、視点方向２６を決定する（ステップＳ１１４）。
【０１４５】
次いで、包含領域１０の最長対角線１２を求め（ステップＳ１１６）、求めた各最長対角線をメイン仮想カメラＣＭ１の画像座標系に投影し、撮影画像上におけるＸ軸方向投影寸法とＹ軸方向投影寸法を算出する（ステップＳ１１８）。
そして、最長対角線１２の数だけ算出されたＸ軸方向投影寸法の中から最大Ｘ軸方向投影寸法Ｌｘを求めるとともに、同様に算出されたＹ軸方向投影寸法から最大Ｙ軸方向投影寸法Ｌｙを求め、両値（Ｌｘ及びＬｙ）を比較して大きい方の投影寸法Ｌｍを求める（ステップＳ１２０）。
【０１４６】
そして、ゲーム演算部２１０は、選択された投影寸法Ｌｍの軸方向に沿ったメイン仮想カメラの画像幅（最大Ｘ軸方向投影寸法Ｌｘが最大Ｙ軸方向投影寸法Ｌｙより大きければ画像の横幅Ｗｘ、逆の関係ならば画像の縦幅Ｗｙ。）とが、所定の比率を成すように撮影条件を決定する（ステップＳ１２２）。
本実施形態では、Ｌｙ≧Ｌｘならば１００：８０＝Ｗｙ：Ｌｙ、Ｌｘ＞Ｌｙならば１００：８０＝Ｗｘ：Ｌｘとなるように、メイン仮想カメラＣＭ１の包含領域１０の中心１１からの適正撮影距離Ｌｃを決定する（ステップＳ１２４）。すなわち、適正撮影距離Ｌｃ＝（１００／８０×Ｌｍ）／２×ｔａｎ（θｃ／２）となる。
【０１４７】
そして、仮配置位置から包含領域１０の中心１１までの距離が適正撮影距離Ｌｃとなる位置を視線方向２６に沿って求め、当該求めた位置をメイン仮想カメラＣＭ１の次の配置位置座標とする（ステップＳ１２４）。勿論、撮影条件の決定は、配置位置を仮配置位置のままとして、画角を変更することによって実現するとしても良い。
【０１４８】
尚、撮影条件の設定は、画角θｃを固定にして適正撮影距離Ｌｃを算出する上述の方法に限るものではない。プレーヤキャラクタＣＰに対するメイン仮想カメラＣＭ１の相対位置を変えたくない場合には、適正距離Ｌｃを仮配置位置までの距離とし、画角θｃを新たに求める構成とすることができる。また、適正撮影距離Ｌｃと画角θｃの両方を求めるとしても良い。例えば、ゲームの演出上の観点からメイン仮想カメラＣＭ１にプレーヤキャラクタＣＰを回り込むといったカメラワークさせたい場合には、あらかじめ仮想カメラ初期設定データ５３６にカメラワークを定義するデータを格納し、該データにしたがって配置位置を決定してから画角θｃを求める。つまり、先に適正撮影距離Ｌｃを決定し、決定した適性撮影距離Ｌｃにおいて画角θｃを求める構成としても良い。
【０１４９】
メイン仮想カメラ設定処理を終了したならば、図１４のフローに戻って、メイン仮想カメラＣＭ１から見てプレーヤキャラクタＣＰが隠れるか否かを判定する（ステップＳ２１）。具体的には、メイン仮想カメラＣＭ１の代表点と、プレーヤキャラクタＣＰの代表点との間に他のオブジェクトが存在するか否かを判定し、他のオブジェクトが存在する場合に「プレーヤキャラクタＣＰが隠れる」と判定する。プレーヤキャラクタＣＰの代表点としては、本実施形態では頭ＣＰと尾ＣＰｔとを代表点とする。尚、この隠れるか否かの判定は、別の方法で行っても良い。例えば、メイン仮想カメラＣＭ１の撮影画像を生成し、その生成した画像中にプレーヤキャラクタＣＰが含まれているか否か、頭ＣＰと尾ＣＰｔの部位が含まれているか否か、含まれているとするとどの程度の割合含まれているのか、といった撮影画像に対する所定の条件に応じて判定しても良い。
【０１５０】
そして、プレーヤキャラクタＣＰが隠れると判定された場合（ステップＳ２１のＹＥＳ）、ゲーム演算部２１０は次に、サブ仮想カメラ設定処理（ステップＳ２２）を実行する。サブ仮想カメラ設定処理は、プレーヤキャラクタＣＰの所定部分を常に撮影するようにサブ仮想カメラを配置・制御する処理である。ここで言う「所定部分」は、本実施形態ではプレーヤキャラクタＣＰの頭ＣＰと尾ＣＰｔである。これらの部分は、プレーヤキャラクタＣＰを移動操作する際に操作力が作用する箇所に該当するので、これらの部位とともにその周囲の状況をサブ仮想カメラで撮影することは、プレーヤキャラクタＣＰを操作するうえで視界を確保することになる。
【０１５１】
図１９は、本実施形態におけるサブ仮想カメラ設定処理の流れを説明するためのフローチャートである。同図に示すように、ゲーム演算部２１０は先ず頭部撮影条件候補データ５３８を参照し、予め設定されている撮影されている撮影条件候補の中から何れかをランダムに選択する（ステップＳ１４０）。そして、選択された撮影条件候補に基づいて撮影した場合に、サブ仮想カメラＣＭ２の画像内に被写体となる部分が写るか否かを判定する（ステップＳ１４２）。具体的には、サブ仮想カメラＣＭ２と頭ＣＰｈに対応する前端ノード２ｆｒとの間に、他のオブジェクトが存在するか否かを判定する。より具体的には、サブ仮想カメラＣＭ２の代表点と、前端ノード２ｆｒとの間に他のオブジェクトが存在するか否かを判定する。そして、他のオブジェクトが存在しなければサブ仮想カメラＣＭ２の画像内に被写体となる部分が写ると判定する。
【０１５２】
そして、サブ仮想カメラＣＭ２の画像内に被写体となる部分が写ると判定されない場合（ステップＳ１４２のＮＯ）、ステップＳ１４０に戻って撮影条件候補を再選択する。一方、画像内に被写体となる部分が写ると判定された場合には（ステップＳ１４２のＹＥＳ）、現在選択されている撮影条件候補をそのままサブ仮想カメラＣＭ２の撮影条件として、撮影条件データ５４４に格納するとともに、仮想カメラＣＭ２をゲーム空間中に配置する（ステップＳ１４４）。
【０１５３】
サブ仮想カメラＣＭ２について撮影条件を決定したならば、ゲーム演算部２１０は同様にして尾ＣＰｔを撮影するサブ仮想カメラＣＭ３の撮影条件を決定する。すなわち、尾部撮影条件候補データ５４２を参照し、予め設定されている撮影されている撮影条件候補の中から何れかをランダムに選択し（ステップＳ１４６）、選択された撮影条件候補に基づいて撮影した場合に、サブ仮想カメラＣＭ３の画像内に被写体となる部分（尾ＣＰｔ）が写るか否かを判定する（ステップＳ１４８）。
【０１５４】
そして、サブ仮想カメラＣＭ３の画像内に被写体となる部分が写ると判定されない場合（ステップＳ１４８のＮＯ）、ステップＳ１４６に戻って撮影条件候補を再選択する。一方、画像内に被写体となる部分が写ると判定された場合には（ステップＳ１４８のＹＥＳ）、現在選択されている撮影条件候補をそのままサブ仮想カメラＣＭ３の撮影条件として、撮影条件データ５４４に格納するとともにサブ仮想カメラＣＭ３をゲーム空間中に配置して（ステップＳ１５０）、サブ仮想カメラ設定処理を終了する。
尚、本実施形態では部分撮影する箇所を頭ＣＰｈ及び尾ＣＰｔとしているが、３箇所以上設定するケースでは、ステップＳ１４０〜Ｓ１４４と同様の処理を繰り返せば良い。
【０１５５】
さて、サブ仮想カメラ設定処理を終了したならば、図１４のフローに戻って、次に画像生成部２６０がゲーム画面表示処理を実行する（ステップＳ２４）。
図２０は、本実施形態におけるゲーム画面表示処理の流れを説明するためのフローチャートである。同図に示すように、ゲーム画面表示処理では先ず、画像生成部２６０はメイン仮想カメラＣＭ１から見た仮想空間画像を生成し、画面表示位置設定データ５４６で対応付けられている画像表示範囲座標５４６ｂに生成した画像を描画する（ステップＳ２００）。
【０１５６】
次に、サブ画面表示状況条件を満たすか否かを判定し、条件を満たしている場合にサブ画面を表示制御する。具体的には、先ず第１の条件として、メイン仮想カメラＣＭ１から見て、プレーヤキャラクタＣＰの頭ＣＰｈが他オブジェクトの背後に隠れるか否か、つまり頭ＣＰｈがメイン仮想カメラＣＭ１の撮影画像内に映るか否かを判定する（ステップＳ２０２）。このケースを換言すると、メイン仮想カメラＣＭ１の現在の撮影条件が、サブ画面表示状況条件を満しているか否かを判定するとも言える。
【０１５７】
そして、背後に隠れると判定された場合、つまりサブ画面表示状況条件を満たすと判定された場合（ステップＳ２０２のＹＥＳ）、画像生成部２６０は、サブ仮想カメラＣＭ２から見た仮想空間画像を生成し、画面表示位置設定データ５４６で対応付けられている画面種類５４８ａの画像表示範囲座標５４６ｂに生成した画像を描画する（ステップＳ２０４）。ゲーム開始時の初期のままであれば、メイン仮想カメラＣＭ１による撮影画像上に、サブ仮想カメラＣＭ２による撮影画像がサブ画面Ｗ２として所与の位置に合成される（図７参照）。
【０１５８】
更に第２の条件として、メイン仮想カメラＣＭ１から見て、尾ＣＰｔが他オブジェクトの背後に隠れるか否かを判定し（ステップＳ２０６）、背後に隠れると判定された場合には（ステップＳ２０６のＹＥＳ）、サブ仮想カメラＣＭ３から見た仮想空間画像を生成し、画面表示位置設定データ５４６で対応付けられている画面種類５４８ａの画像表示範囲座標５４６ｂに生成した画像を描画する（ステップＳ２０８）。ゲーム開始時の初期のままであれば、メイン仮想カメラＣＭ１による撮影画像上に、サブ仮想カメラＣＭ３による撮影画像がサブ画面Ｗ３として所与の位置に合成される。
【０１５９】
次に、画像生成部２６０は、撮影条件データ５４４を参照して、イベント仮想カメラＣＭ４が設定されているか否かを判定する（ステップＳ２１０）。そして、設定されていると判定された場合（ステップＳ２１０のＹＥＳ）、イベント仮想カメラＣＭ４の撮影画像を生成し、画面表示位置設定データ５４６でイベント仮想カメラＣＭ４に対応付けられている画像表示範囲座標５４６ｂに生成した画像を描画する（ステップＳ２１２）。ゲーム開始時の初期のままであれば、メイン仮想カメラＣＭ１による撮影画像上に、イベント仮想カメラＣＭ４による撮影画像がサブ画面Ｗ４として合成される。
【０１６０】
ここまでの処理で、メイン仮想カメラＣＭ１でプレーヤキャラクタＣＰの全身を撮影するように制御しても、他のオブジェクトとの位置関係によってその撮影画像に頭ＣＰｈや尾ＣＰｔが写らない場合には、主ゲーム画面Ｗ１にサブ画面Ｗ２，Ｗ３でそれら各部の部分撮影画像が合成された画像が形成されたことになる。更には、イベントが発生し実行中であれば、サブ画面Ｗ４が更に合成された画像が形成されたことになる。
そこで、画像生成部２６０が、当該形成された画像の画像信号を画像表示部３６０に出力して、ゲーム画面を表示させ（ステップＳ２１４）、ゲーム画面表示処理を終了する。
【０１６１】
尚、サブ画面を表示する条件として、オブジェクトの移動及び／又は体形変化の現況として、サブ仮想カメラＣＭ２，ＣＭ３の被写体として定められた所定部位がメイン仮想カメラＣＭ１の撮影画像範囲に入らないことを例に挙げたが、サブ画面表示状況条件はこれに限るものではない。例えば、プレーヤキャラクタＣＰが静止していることを条件としても良い。この場合、移動中はサブ画面を表示しないようにして、移動中の状況を見易くする一方で一旦立ち止まることで、周囲の状況を詳しく観察できるようになるので、より一層プレーヤキャラクタＣＰを操作し易くなるであろう。
また、別の例としては、プレーヤキャラクタＣＰの全長が基準値以上になることを条件としても良いし、所定の体勢を採っていることを条件としても良い。また例えば、移動及び／又は体形変化に限らず、プレーヤキャラクタＣＰが所定のアイテムが取得したり呪文を唱えるといったことや、所定部位が怪我をしたりアイテムを付属させているといった部位のステータス、接触を防ぎながら狭い場所をくぐりぬけるといったゲーム進行状態やゲームステージの種類などを条件とすることもできる。
【０１６２】
さて、ゲーム画像表示処理を終了したならば、図１４のフローに戻り、次に画像生成部２６０は画像表示切換処理を実行して、プレーヤの操作入力に応じて次のゲーム画面の描画タイミングで、主ゲーム画面Ｗ１に表示される画像の内容とサブ画面に表示される画像の内容とを切り換えできるように設定の画面表示位置設定データ５４６の変更をする（ステップＳ２６）。
【０１６３】
図２１は、本実施形態における画像表示切換処理の流れを説明するためのフローチャートである。同図に示すように、画像表示切換処理では先ず、画像生成部２６０は、ゲームコントローラ１２３０で所定の画面切換操作が入力されたか否かを判定する（ステップＳ１７０）。例えば、所定のプッシュボタン１２３２を押下すると画面切換操作が入力されたと判定される。
【０１６４】
画面切換操作が入力されたと判定した場合（ステップＳ１７０のＹＥＳ）、画像生成部２６０は、画面切換操作が入力される都度、現在表示しているサブ画面を切換先候補として識別表示する（ステップＳ１７２）。具体的には、例えば、現在主ゲーム画面Ｗ１上にサブ画面Ｗ２及びＷ３が表示されている場合、画面切換操作が入力されると、サブ画面Ｗ２の周囲の表示色や輝度、表示枠に特定デザインを適用するなどして表示制御する。この状態では、サブ画面Ｗ２を切換候補とする。もう一度画面切換ボタンスイッチが押されると、今度はサブ画面Ｗ２の識別表示を解除して、代わりにサブ画面Ｗ３を識別表示制御して切換候補とする。
【０１６５】
そして、ゲームコントローラ１２３０から所定の決定操作が入力された場合（ステップＳ１７４のＹＥＳ）、画像生成部２６０は、画面表示位置設定データ５４６における対応仮想カメラ５４６ｃの設定を、メイン仮想カメラＣＭ１と、先に選択決定されたサブ画面を撮影するサブ仮想カメラとで入れ換える（ステップＳ１７６）。この結果、次の制御サイクルでゲーム画面表示処理（図１４のステップＳ２４）が実行されると、主ゲーム画面Ｗ１に表示される画像の内容と、サブ画面に表示される画像の内容とが切り換わることになる。一方、所定の決定操作が入力されずに、所定のキャンセル操作が入力された場合には（ステップＳ１７８のＹＥＳ）、サブ画面の識別表示を解除する（ステップＳ１８０）。
【０１６６】
尚、本実施形態では、画面表示位置設定データ５４６を変更することで、次のゲーム画面の描画タイミングで瞬時に画像が入れ換えされる構成となっているが、適宜、公知の画面のトランジェント処理（例えば、ワイプ、オーバーラップなど。）を実行する構成としても良い。その場合、トランジェント処理実行中は、プレーヤキャラクタＣＰや他のオブジェクトの動作制御は一次中断すると好適である。
【０１６７】
次に、画像生成部２６０は、画面表示位置設定データ５４６を参照して、主ゲーム画面Ｗ１に対応する仮想カメラがメイン仮想カメラＣＭ１であるか否かを判定する（ステップＳ１８２）。
【０１６８】
メイン仮想カメラＣＭ１が対応付けられていない場合には（ステップＳ１８２のＮＯ）、復帰タイマーを稼動させる（ステップＳ１８４）。そして、稼動タイマーが所定時間を計時していなければ（ステップＳ１８６のＮＯ）、そのまま画像表示切換処理を終了する。一方、稼動タイマーが所定時間を計時したならば（ステップＳ１８６のＹＥＳ）、画面表示位置設定データ５４６における対応仮想カメラ５４６ｃを初期状態（例えば、図１３の状態）に戻して、主ゲーム画面Ｗ１にメイン仮想カメラＣＭ１の撮影画像が表示されるように設定を戻してから（ステップＳ１８８）、画像表示切換処理を終了する。
【０１６９】
つまり、プレーヤの操作入力に応じて、主ゲーム画面Ｗ１に表示されている画像と、何れかのサブ画面に表示されている画像とを入れ換えを実行しても、所定時間が経過すると自動的に元の状態に戻されることになる。このことは、メイン仮想カメラＣＭ１とは別の角度からプレーヤが頭ＣＰｈ或いは尾ＣＰｔが撮影されているサブ画面を一時的に大きく表示させて操作しやすい状態にしたとしても、その他多くの場合ではメイン仮想カメラＣＭ１がプレーヤキャラクタＣＰの全体を撮影し、これを主画面として表示することで本実施形態のようなゲームに適した操作性が実現されるのであるから、画像表示の切換を自動的に元に戻すことで快適なゲームプレイ環境を提供することができる。
【０１７０】
画像表示切換処理を終了したならば、図１４のフローに戻って、次にゲーム演算部２１０が、ゲームの終了条件を満たすか否かを判定する（ステップＳ２８）。本実施形態では、プレーヤキャラクタが所定のゴール地点に体力値が「０」になる前に無事たどりつければゲームクリアして終了条件を満たすと見なされる。また、移動中にイベントキャラクタＣＩなどの邪魔や、高所からの落下などによって体力値が「０」になってしまうとゲームオーバして終了条件を満たすと見なされる。
終了条件を満たしていなければ（ステップＳ２８のＹＥＳ）、ステップＳ４に戻り、終了条件を満たしていれば（ステップＳ２８のＮＯ）、ゲーム終了処理を実行して一連の処理を終了する。
【０１７１】
以上の一連の処理によって、本実施形態ではプレーヤキャラクタＣＰの全体が常にゲーム画面上に表示されるように制御される。
図２２は、本実施形態におけるメイン仮想カメラＣＭ１による撮影画像の例を示す図であって、プレーヤキャラクタＣＰの全長がそれぞれ異なる場合における例を示している。
同図（ａ）の状態から同図（ｂ）の状態までプレーヤキャラクタＣＰが伸びたとしても、メイン仮想カメラＣＭ１がプレーヤキャラクタＣＰから遠ざかるように撮影条件が変更され、プレーヤキャラクタＣＰの容姿が撮影画面に対して所定関係を成す大きさで撮影されるようになる。つまり、プレーヤキャラクタＣＰをメイン仮想カメラＣＭ１の画面座標系に投影した長さ（同図の場合は、Ｘ軸方向投影寸法Ｌｘ）が画面の幅（同図の場合は、横幅Ｗｘ）に対して「１．０」を下回る所定の割合を満たすように撮影される。したがって、同図（ａ）と同図（ｂ）における各Ｘ軸方向投影寸法Ｌｘは、原理上、近時した長さになる。
【０１７２】
そして、本実施形態では基本的にメイン仮想カメラＣＭ１でされた画像を、主ゲーム画面Ｗ１として表示制御するので、プレーヤは、プレーヤキャラクタＣＰの前端側、後端側いずれの側でもある程度周囲の状況を常に見る事が出来るので、プレーヤキャラクタＣＰの操作が寄りし易くなる。また、仮に、プレーヤキャラクタＣＰの全長ととともに胴回りも太くなるように設定したとしても、同図（ｃ）に示すように、やはりプレーヤキャラクタＣＰの前端側、後端側いずれの側でもある程度周囲の状況をゲーム画面上に映すことができる。しかも、こうしたメイン仮想カメラＣＭ１の撮影条件の設定を、包含領域１０に基づいて決定することによって、複雑な形状に変化するキャラクタであっても簡単な処理で実現することができる。
【０１７３】
また、本実施形態では、プレーヤキャラクタＣＰの移動や体形変化に伴って、頭ＣＰｈや尾ＣＰｔがゲーム画面で常に見えているように表示させることができる。
図２３〜２４は、本実施形態におけるゲーム画面例を示す図であって、主ゲーム画面Ｗ１とサブ画面Ｗ２の表示を切り換える場合の画面の変化を示している。尚、ここでは切換に際してトランジェント処理を実行する場合を示している。
【０１７４】
同図（ａ）では、主ゲーム画面Ｗ１のみが表示されている。つまり、メイン仮想カメラ設定処理によってメイン仮想カメラＣＭ１がプレーヤキャラクタＣＰの全身を映すように制御されている。この段階では、頭ＣＰｈも尾ＣＰｔも他のオブジェクトに隠れていないので、サブ画面表示はされていない。この状態からプレーヤキャラクタＣＰが移動制御されて、障害物３０の背面側に移動したとする。
【０１７５】
そして、メイン仮想カメラＣＭ１から見てプレーヤキャラクタＣＰが障害物３０の背後に隠れてしまうと、同図（ｂ）に示すようにサブ画面が表示制御される。同図（ｂ）の場合では、主ゲーム画面Ｗ１では頭ＣＰｈも尾ＣＰｔも見えていないので、頭ＣＰｈの様子を映すサブ画面Ｗ２と、尾ＣＰｔの様子を映すサブ画面Ｗ３が表示されている。プレーヤキャラクタＣＰが頭ＣＰｈ先に隠れることになるから、前者が先に表示され、続いて後者が追加して表示されることになる。
【０１７６】
ここで、プレーヤがゲームコントローラ１２３０から所定の画面切換操作を入力すると、同図（ｃ）に示すように選択されているサブ画面に識別表示がされる。この例では、サブ画面Ｗ２が選択されており、その画像表示の周辺に所定の選択表示枠３２が表示されて強調されている。
【０１７７】
サブ画面Ｗ２が切り換え先として選択決定されると、主ゲーム画面Ｗ１とサブ画面Ｗ２との間でトランジェント処理が実行され、例えば図２４（ａ）のように、サブ画面Ｗ２が徐々に拡大される。そして、サブ画面Ｗ２が主ゲーム画面Ｗ１と同程度の大きさに達すると、同図（ｂ）のように、主ゲーム画面Ｗ１にサブ仮想カメラＣＭ２による撮影画像が表示され、元のサブ画像Ｗ２の表示範囲にメイン仮想カメラＣＭ１による撮影画像が表示される。本実施形態のようなゲームの場合、プレーヤキャラクタＣＰを操作するうえで頭ＣＰｈ並びに尾ＣＰｔがプレーヤに見えている事が大切であるから、このようにサブ画面表示によってこれらの要部が常にゲーム画面上に映すことでプレイし易い環境を実現できる。
【０１７８】
また、本実施形態によれば、イベントが発生した場合にもサブ画面を表示させることができる。
図２５は、本実施形態におけるゲーム画面例を示す図であって、主ゲーム画面Ｗ１とサブ画面Ｗ４の表示を切り換える場合の画面の変化を示している。同図（ａ）に示すように、イベントが実行されると主ゲーム画面Ｗ１の所定位置にサブ画面Ｗ４が表示され、イベント仮想カメラＣＭ４の撮影画像が表示される。同図の例では、主ゲーム画面Ｗ１ではプレーヤキャラクタＣＰしか見えていないが、サブ画面Ｗ４ではイベントキャラクタＩＣがプレーヤキャラクタＣＰに向かって生きている様子が表示される。
【０１７９】
ここで、更にサブ画面Ｗ４で表示されている状態を詳細に見たいと考えて、サブ画面Ｗ４を切換候補として選択・決定すると、同図（ｂ）に示すように、サブ画面Ｗ４が識別表示されるとともに、トランジェント処理を伴って徐々に拡大表示される。そして、サブ画面Ｗ４が主ゲーム画面Ｗ１とほとんど同じ大きさまで変化すると、同図（ｃ）に示すように、切換が完了して主ゲーム画面Ｗ１にイベント仮想カメラＣＭ４の撮影画像が表示され、サブ画面Ｗ４にはメイン仮想カメラＣＭ１の撮影画像が表示される。
よって、プレーヤはイベントキャラクタＩＣがプレーヤキャラクタＣＰに向かってくる様子をより詳しくしることができるので、どちらの方向に回避すると良いかなどの判断をつけやすくなす。すなわち、よりプレーヤキャラクタＣＰを操作し易くなる。
【０１８０】
また、同図の例ではイベントがプレーヤキャラクタＣＰの近傍で発生しているが、ゲーム空間内の遠く離れた場所でイベントが発生した場合であっても、サブ画面Ｗ４でイベントキャラクタＩＣとプレーヤキャラクタＣＰとが画面内に映されることで、どこでイベントが起きたか理解できるので、そうした観点からもよりプレーヤキャラクタＣＰを操作し易くなる。
【０１８１】
［ハードウェア構成］
次に図２６を参照して、本実施形態における家庭用ゲーム装置１２００を実現するためのハードウェア構成の一例について説明する図である。家庭用ゲーム装置１２００は、ＣＰＵ１０００、ＲＯＭ１００２、ＲＡＭ１００４、情報記憶媒体１００６、画像生成ＩＣ１００８、音生成ＩＣ１０１０、Ｉ／Ｏポート１０１２，１０１４がシステムバス１０１６により相互にデータ入出力可能に接続されている。Ｉ／Ｏポート１０１２にはコントロール装置１０２２が、Ｉ／Ｏポート１０１４には通信装置１０２４が、それぞれ接続されている。
【０１８２】
ＣＰＵ１０００は、情報記憶媒体１００６に格納されるプログラム、ＲＯＭ１００２に格納されるシステムプログラム（装置本体の初期化情報等）、コントロール装置１０２２によって入力される信号等に従って、装置全体の制御や各種データ処理を行う。
【０１８３】
ＲＡＭ１００４は、ＣＰＵ１０００の作業領域等として用いられる記憶手段であり、情報記憶媒体１００６やＲＯＭ１００２内の所与の内容、ＣＰＵ１０００の演算結果等が格納される。
【０１８４】
情報記憶媒体１００６は、プログラム、画像データ、音データ、プレーデータ等が主に格納されるものであり、情報記憶媒体として、ＲＯＭ等のメモリやハードディスクや、ＣＤ−ＲＯＭ、ＤＶＤ、ＩＣカード、磁気ディスク、光ディスク等が用いられる。尚、この情報記憶媒体１００６は、図８に示す記憶部５００に相当するものである。
【０１８５】
また、この装置に設けられている画像生成ＩＣ１００８と音生成ＩＣ１０１０により、音や画像の好適な出力が行えるようになっている。
【０１８６】
画像生成ＩＣ１００８は、ＣＰＵ１０００の命令によって、ＲＯＭ１００２、ＲＡＭ１００４、情報記憶媒体１００６等から送られる情報に基づいて画素情報を生成する集積回路であり、生成される画像信号は、表示装置１０１８に出力される。表示装置１０１８は、ＣＲＴやＬＣＤ、ＥＬＤ、プラズマディスプレイ、或いはプロジェクター等により実現され、図８に示す画像表示部３６０に相当する。
【０１８７】
また、音生成ＩＣ１０１０は、ＣＰＵ１０００の命令によって、情報記憶媒体１００６やＲＯＭ１００２に記憶される情報、ＲＡＭ１００４に格納される音データに応じた音信号を生成する集積回路であり、生成される音信号はスピーカ１０２０によって出力される。スピーカ１０２０は、図８に示す音出力部３５０に相当するものである。
【０１８８】
コントロール装置１０２２は、プレーヤがゲームに係る操作を入力するための装置であり、その機能は、レバー、ボタン、筐体等のハードウェアにより実現される。尚、このコントロール装置１０２２は、図８に示す操作入力部１００に相当するものである。
【０１８９】
通信装置１０２４は装置内部で利用される情報を外部とやりとりするものであり、プログラムに応じた所与の情報を他の装置と送受すること等に利用される。尚、この通信装置１０２４は、図８に示す通信部３７０に相当するものである。
【０１９０】
そして、ゲーム処理等の上記した処理は、図８のゲームプログラム５０２等を格納した情報記憶媒体１００６と、これらプログラムに従って動作するＣＰＵ１０００、画像生成ＩＣ１００８、音生成ＩＣ１０１０等によって実現される。ＣＰＵ１０００、画像生成ＩＣ１００８、及び音生成ＩＣ１０１０は、図８に示す処理部２００に相当するものであり、主にＣＰＵ１０００がゲーム演算部２１０、画像生成ＩＣ１００８が画像生成部２６０に、音生成ＩＣ１０１０が音生成部２５０にそれぞれ相当する。
【０１９１】
尚、画像生成ＩＣ１００８、音生成ＩＣ１０１０等で行われる処理は、ＣＰＵ１０００或いは汎用のＤＳＰ等によりソフトウェア的に行ってもよい。この場合には、ＣＰＵ１０００が、図８に示す処理部２００に相当することとなる。
【０１９２】
〔変形例〕
以上、本発明の実施形態について説明したが、本発明の適用形態がこれらに限定されるものではなく、発明の主旨を逸脱しない限りにおいて適宜変更を加えることができる。
【０１９３】
例えば、家庭用ゲーム装置でビデオゲームを実行する構成を例に挙げたが、業務用のゲーム装置やパソコン、携帯型ゲーム装置などでゲームを実行することもできる。
【０１９４】
また、プレーヤキャラクタの伸長・短縮操作を例に挙げたがこれに限るものではない。例えば、プレーヤキャラクタが使用するアイテムの伸長・短縮制御に適用することもできる。
【０１９５】
また、画面表示切換処理における切換候補とするサブ画面の選択操作の方法として、プッシュボタン１２３２の押下に限らず、右アナログレバー１２３６や左アナログレバー１２３８を用いるとしても良い。
【０１９６】
例えば、図２７は、サブ画面の選択操作として右アナログレバー１２３６や左アナログレバー１２３８を用いる場合の画面表示切換処理の流れを説明するためのフローチャートである。尚、第１実施形態と同様のステップにつては同じ符号を付与し説明は省略する。
【０１９７】
同図に示すように、画像生成部２６０が、親指以外の指（例えば、一指し指）で操作可能なゲームコントローラ１２３０の側面に設けられた所定のプッシュスイッチ１２３３が押下されているか否かを判定し（ステップＳ１６０）、押下されていると判定した場合（ステップＳ１６０のＹＥＳ）、左右両方のアナログレバーの入力方向に基づいてサブ画面を選択する。
【０１９８】
具体的には、例えば、サブ画面を表示／非表示を示すフラグを記憶部５００に記憶しておいて、右アナログレバー１２３６及び左アナログレバー１２３８の２つの方向入力の中間方向を求め（ステップＳ２３２）、ディスプレイ１２２２の画像表示範囲の中心から先に求めた中間方向を中央に画面周縁に向かって広がる所定幅の扇型領域に含まれる表示状態のサブ画面を抽出し、そのサブ画面を切換候補とする（ステップＳ２３４）。扇型領域から表示状態のサブ画面がなければ、切換候補は未定とする。
【０１９９】
そして、押下されていた所定のプッシュスイッチ１２３３がリリースされた場合（ステップＳ２３６のＹＥＳ）、切換候補のサブ画面が有れば（ステップＳ２３８のＹＥＳ）、画面表示位置設定データの設定を、メイン仮想カメラと切換候補として選択されたサブ画面を撮影するサブ仮想カメラとで入れ換えて（ステップＳ２４０）、ステップＳ１８２に以降する。一方、切換候補のサブ画面がなければ（ステップＳ２３８のＮＯ）、画像の入れ換えを行わずにステップＳ１８２に移行する。
【０２００】
従って、プレーヤは右アナログレバー１２３６並びに左アナログレバー１２３８から指を離すことなく、プレーヤキャラクタＣＰの任意伸縮から移動、更にサブ画面の切り換えもできるようになるのでより一層操作性が高くなる。
【０２０１】
尚、同様の操作方法は、右アナログレバー１２３６及び左アナログレバー１２３８による方向入力で実現するに限らない。
例えば、図２８に示す家庭用ゲーム装置１２００Ｂのように、ゲームコントローラ１２３０Ｒ及び１２３０Ｌを用意する。ゲームコントローラ１２３０Ｒ及び１２３０Ｌは、右アナログレバー１２３６及び左アナログレバー１２３８に相当する十字方向キー１２３７に親指を添え、あたかも棒を持つ要領で左右両手に一本ずつもって操作される。そして、内蔵する無線通信機１２３９によって制御ユニット１２１０に実装された無線通信機１２１４と無線通信を実現して、ゲーム装置本体１２０１に操作入力信号を出力する。更に、ゲームコントローラ１２３０Ｒ及び１２３０Ｌは、それぞれ加速度センサ１２４０を内蔵しており、各コントローラの姿勢変化に伴う加速度を検出し操作入力信号として出力する。この加速度による方向入力の前後左右を、ディスプレイ１２２２の画面座標系の上下左右に対応づけることで右アナログレバー１２３６及び左アナログレバー１２３８の代わりとすると、ゲームコントローラ１２３０Ｒ及び１２３０Ｌを同時に同じ方向へ向けて振ることでサブ画面を切換候補として選択することが可能になる。この場合もまた、プレーヤは十字方向キー１２３７から親指を離すことなく、プレーヤキャラクタＣＰの任意伸縮から移動、更にサブ画面の切り換えもできるようになる。
【図面の簡単な説明】
【０２０２】
【図１】家庭用ゲーム装置の構成例を示すシステム構成図。
【図２】プレーヤキャラクタのモデル構成を説明するための図。
【図３】プレーヤキャラクタの移動操作と制御の関係を示す概念図。
【図４】プレーヤキャラクタの任意伸長操作と制御の関係を示す概念図。
【図５】プレーヤキャラクタの任意短縮操作と制御の関係を示す概念図。
【図６】仮想カメラの撮影条件の設定方法を説明するための概念図。
【図７】サブ仮想カメラの設定と、サブ画面表示の概念を説明するための概念図。
【図８】機能構成の一例を示す機能ブロック図。
【図９】キャラクタ制御データのデータ構成例を示す図。
【図１０】作用力データのデータ構成例を示す図。
【図１１】頭部撮影条件候補データのデータ構成の一例と、該例における撮影条件の概要を示す図。
【図１２】イベント撮影条件候補データのデータ構成の一例を示す図とその概念図。
【図１３】画像表示位置設定データのデータ構成の一例を示すデータ構成図。
【図１４】第１実施形態における処理の流れを説明するためのフローチャート。
【図１５】任意伸縮処理の流れを説明するためのフローチャート。
【図１６】作用力設定処理の流れを説明するためのフローチャート。
【図１７】イベント仮想カメラ設定処理の流れを説明するためのフローチャート。
【図１８】メイン仮想カメラ設定処理の流れを説明するためのフローチャート。
【図１９】サブ仮想カメラ設定処理の流れを説明するためのフローチャート。
【図２０】ゲーム画面表示処理の流れを説明するためのフローチャート。
【図２１】画像表示切換処理の流れを説明するためのフローチャート。
【図２２】メイン仮想カメラＣＭ１による撮影画像の例を示す図。
【図２３】ゲーム画面例を示す図であって、主ゲーム画面Ｗ１とサブ画面Ｗ２の表示を切り換える場合の画面の変化を示す図。
【図２４】図２３に続くゲーム画面例を示す図。
【図２５】ゲーム画面例を示す図であって、主ゲーム画面Ｗ１とサブ画面Ｗ４の表示を切り換える場合の画面の変化を示す図。
【図２６】ハードウェア構成の一例を示す構成図。
【図２７】画面表示切換処理の変形例の流れを説明するためのフローチャート。
【図２８】家庭用ゲーム装置の構成例の変形例を示すシステム構成図。
【符号の説明】
【０２０３】
１００  操作入力部
１０２  第１方向入力部
１０４  第２方向入力部
２００  処理部
２１０  ゲーム演算部
２１２  キャラクタ制御部
２１４  仮想カメラ制御部
２６０  画像生成部
２６２  サブ画面表示制御部
５００  記憶部
５２４  キャラクタ制御データ
５３０  作用力データ
５３４  包含領域設定データ
５３８  頭部撮影条件候補データ
５４０  尾部撮影条件候補データ
５４２  イベント撮影条件候補データ
５４４  撮影条件データ
５４６  画面表示位置設定データ
１２００  家庭用ゲーム装置
１２３０  ゲームコントローラ
１２３６  右アナログレバー
１２３８  左アナログレバー
ＰＣ  プレーヤキャラクタ
ＣＭ１  メイン仮想カメラ
ＣＭ２、ＣＭ３  サブ仮想カメラ
ＣＭ４  イベント仮想カメラ
Ｗ１  主ゲーム画面
Ｗ２、Ｗ３、Ｗ４  サブ画面
【図１】
2008186324.tif 000003
【図２】
2008186324.tif 000004
【図３】
2008186324.tif 000005
【図４】
2008186324.tif 000006
【図５】
2008186324.tif 000007
【図６】
2008186324.tif 000008
【図７】
2008186324.tif 000009
【図８】
2008186324.tif 000010
【図９】
2008186324.tif 000011
【図１０】
2008186324.tif 000012
【図１１】
2008186324.tif 000013
【図１２】
2008186324.tif 000014
【図１３】
2008186324.tif 000015
【図１４】
2008186324.tif 000016
【図１５】
2008186324.tif 000017
【図１６】
2008186324.tif 000018
【図１７】
2008186324.tif 000019
【図１８】
2008186324.tif 000020
【図１９】
2008186324.tif 000021
【図２０】
2008186324.tif 000022
【図２１】
2008186324.tif 000023
【図２２】
2008186324.tif 000024
【図２３】
2008186324.tif 000025
【図２４】
2008186324.tif 000026
【図２５】
2008186324.tif 000027
【図２６】
2008186324.tif 000028
【図２７】
2008186324.tif 000029
【図２８】
2008186324.tif 000030