各実施形態の詳細を説明するに先立ち、図1を参照して、各実施形態で共通して使用されるゲーム装置の構成について説明する。以下、説明を具体的にするために、当該ゲーム装置を用いたゲームシステム1を一例として説明する。なお、図1は、当該ゲームシステム1を説明するための外観図である。以下、据置型ゲーム装置を一例にして、当該ゲームシステム1について説明する。
図1において、当該ゲームシステム1は、家庭用テレビジョン受像機等のスピーカ2aを備えたディスプレイ(以下、モニタと記載する)2に、接続コードを介して接続される据置型ゲーム装置(以下、単にゲーム装置と記載する)3および当該ゲーム装置3に操作情報を与えるコントローラ7によって構成される。ゲーム装置3は、接続端子を介して受信ユニット6が接続される。受信ユニット6は、コントローラ7から無線送信される送信データを受信し、コントローラ7とゲーム装置3とは無線通信によって接続される。また、ゲーム装置3には、当該ゲーム装置3に対して交換可能に用いられる情報記憶媒体の一例の光ディスク4が脱着される。ゲーム装置3の上部主面には、当該ゲーム装置3の電源ON/OFFスイッチ、ゲーム処理のリセットスイッチ、およびゲーム装置3上部の蓋を開くOPENスイッチが設けられている。ここで、プレイヤがOPENスイッチを押下することによって上記蓋が開き、光ディスク4の脱着が可能となる。
また、ゲーム装置3には、セーブデータ等を固定的に記憶するバックアップメモリ等を搭載する外部メモリカード5が必要に応じて着脱自在に装着される。ゲーム装置3は、光ディスク4に記憶されたゲームプログラムなどを実行することによって、その結果をゲーム画像としてモニタ2に表示する。さらに、ゲーム装置3は、外部メモリカード5に記憶されたセーブデータを用いて、過去に実行されたゲーム状態を再現して、ゲーム画像をモニタ2に表示することもできる。そして、ゲーム装置3のプレイヤは、モニタ2に表示されたゲーム画像を見ながら、コントローラ7を操作することによって、ゲーム進行を楽しむことができる。
コントローラ7は、その内部に備える通信部75(後述)から受信ユニット6が接続されたゲーム装置3へ、例えばBluetooth(ブルートゥース;登録商標)の技術を用いて送信データを無線送信する。コントローラ7は、主にモニタ2に表示されるゲーム空間に登場するプレイヤオブジェクトを操作するための操作手段である。コントローラ7は、複数の操作ボタン、キー、およびスティック等の操作部が設けられている。また、後述により明らかとなるが、コントローラ7は、当該コントローラ7から見た画像を撮像する撮像情報演算部74を備えている。また、撮像情報演算部74の撮像対象の一例として、モニタ2の表示画面近傍に2つのLEDモジュール(以下、マーカと記載する)8Lおよび8Rが設置される。マーカ8Lおよび8Rは、コントローラ7の位置を示すためのものである。これらマーカ8Lおよび8Rは、それぞれモニタ2の前方に向かって赤外光を出力する。
次に、図2を参照して、ゲーム装置3の構成について説明する。なお、図2は、ゲーム装置3の機能ブロック図である。
図2において、ゲーム装置3は、各種プログラムを実行する例えばリスク(RISC)CPU(セントラルプロセッシングユニット)30を備える。CPU30は、図示しないブートROMに記憶された起動プログラムを実行し、メインメモリ33等のメモリの初期化等を行った後、光ディスク4に記憶されているゲームプログラムの実行し、そのゲームプログラムに応じたゲーム処理等を行うものである。CPU30には、メモリコントローラ31を介して、GPU(Graphics Processing Unit)32、メインメモリ33、DSP(Digital Signal Processor)34、およびARAM(Audio RAM)35が接続される。また、メモリコントローラ31には、所定のバスを介して、コントローラI/F(インターフェース)36、ビデオI/F37、外部メモリI/F38、オーディオI/F39、およびディスクI/F41が接続され、それぞれ受信ユニット6、モニタ2、外部メモリカード5、スピーカ2a、およびディスクドライブ40が接続されている。
GPU32は、CPU30の命令に基づいて画像処理を行うものあり、例えば、3Dグラフィックスの表示に必要な計算処理を行う半導体チップで構成される。GPU32は、図示しない画像処理専用のメモリやメインメモリ33の一部の記憶領域を用いて画像処理を行う。GPU32は、これらを用いてモニタ2に表示すべきゲーム画像データやムービ映像を生成し、適宜メモリコントローラ31およびビデオI/F37を介してモニタ2に出力する。
メインメモリ33は、CPU30で使用される記憶領域であって、CPU30の処理に必要なゲームプログラム等を適宜記憶する。例えば、メインメモリ33は、CPU30によって光ディスク4から読み出されたゲームプログラムや各種データ等を記憶する。このメインメモリ33に記憶されたゲームプログラムや各種データ等がCPU30によって実行される。
DSP34は、ゲームプログラム実行時にCPU30において生成されるサウンドデータ等を処理するものであり、そのサウンドデータ等を記憶するためのARAM35が接続される。ARAM35は、DSP34が所定の処理(例えば、先読みしておいたゲームプログラムやサウンドデータの記憶)を行う際に用いられる。DSP34は、ARAM35に記憶されたサウンドデータを読み出し、メモリコントローラ31およびオーディオI/F39を介してモニタ2に備えるスピーカ2aに出力させる。
メモリコントローラ31は、データ転送を統括的に制御するものであり、上述した各種I/Fが接続される。コントローラI/F36は、例えば4つのコントローラI/F36a〜36dで構成され、それらが有するコネクタを介して嵌合可能な外部機器とゲーム装置3とを通信可能に接続する。例えば、受信ユニット6は、上記コネクタと嵌合し、コントローラI/F36を介してゲーム装置3と接続される。上述したように受信ユニット6は、コントローラ7からの送信データを受信し、コントローラI/F36を介して当該送信データをCPU30へ出力する。ビデオI/F37には、モニタ2が接続される。外部メモリI/F38には、外部メモリカード5が接続され、その外部メモリカード5に設けられたバックアップメモリ等とアクセス可能となる。オーディオI/F39にはモニタ2に内蔵されるスピーカ2aが接続され、DSP34がARAM35から読み出したサウンドデータやディスクドライブ40から直接出力されるサウンドデータをスピーカ2aから出力可能に接続される。ディスクI/F41には、ディスクドライブ40が接続される。ディスクドライブ40は、所定の読み出し位置に配置された光ディスク4に記憶されたデータを読み出し、ゲーム装置3のバスやオーディオI/F39に出力する。
図3および図4を参照して、本発明の入力装置の一例であるコントローラ7について説明する。なお、図3は、コントローラ7の上面後方から見た斜視図である。図4は、コントローラ7を下面後方から見た斜視図である。
図3および図4において、コントローラ7は、例えばプラスチック成型によって形成されたハウジング71を有しており、当該ハウジング71に複数の操作部72が設けられている。ハウジング71は、その前後方向を長手方向とした略直方体形状を有しており、全体として大人や子供の片手で把持可能な大きさである。
ハウジング71上面の中央前面側に、十字キー72aが設けられる。この十字キー72aは、十字型の4方向プッシュスイッチであり、矢印で示す4つの方向(前後左右)に対応する操作部分が十字の突出片にそれぞれ90°間隔で配置される。プレイヤが十字キー72aのいずれかの操作部分を押下することによって前後左右いずれかの方向を選択される。例えばプレイヤが十字キー72aを操作することによって、仮想ゲーム世界に登場するプレイヤキャラクタ等の移動方向を指示したり、カーソルの移動方向を指示したりすることができる。
なお、十字キー72aは、上述したプレイヤの方向入力操作に応じて操作信号を出力する操作部であるが、他の態様の操作部でもかまわない。例えば、リング状に4方向の操作部分を備えたプッシュスイッチとその中央に設けられたセンタスイッチとを複合した複合スイッチを上記十字キー72aの代わりに設けてもかまわない。また、ハウジング71上面から突出した傾倒可能なスティックを倒すことによって、傾倒方向に応じて操作信号を出力する操作部を上記十字キー72aの代わりに設けてもかまわない。さらに、水平移動可能な円盤状部材をスライドさせることによって、当該スライド方向に応じた操作信号を出力する操作部を、上記十字キー72aの代わりに設けてもかまわない。また、タッチパッドを、上記十字キー72aの代わりに設けてもかまわない。また、少なくとも4つの方向(前後左右)をそれぞれ示すスイッチに対して、プレイヤによって押下されたスイッチに応じて操作信号を出力する操作部を上記十字キー72aの代わりに設けてもかまわない。
ハウジング71上面の十字キー72aより後面側に、複数の操作ボタン72b〜72gが設けられる。操作ボタン72b〜72gは、プレイヤがボタン頭部を押下することによって、それぞれの操作ボタン72b〜72gに割り当てられた操作信号を出力する操作部である。例えば、操作ボタン72b〜72dには、Xボタン、Yボタン、およびBボタン等としての機能が割り当てられる。また、操作ボタン72e〜72gには、セレクトスイッチ、メニュースイッチ、およびスタートスイッチ等としての機能が割り当てられる。これら操作ボタン72b〜72gは、ゲーム装置3が実行するゲームプログラムに応じてそれぞれの機能が割り当てられるが、本発明の説明とは直接関連しないため詳細な説明を省略する。なお、図3に示した配置例では、操作ボタン72b〜72dは、ハウジング71上面の中央前後方向に沿って並設されている。また、操作ボタン72e〜72gは、ハウジング71上面の左右方向に沿って操作ボタン72bおよび72dの間に並設されている。そして、操作ボタン72fは、その上面がハウジング71の上面に埋没しており、プレイヤが不意に誤って押下することのないタイプのボタンである。
また、ハウジング71上面の十字キー72aより前面側に、操作ボタン72hが設けられる。操作ボタン72hは、遠隔からゲーム装置3本体の電源をオン/オフする電源スイッチである。この操作ボタン72hも、その上面がハウジング71の上面に埋没しており、プレイヤが不意に誤って押下することのないタイプのボタンである。
また、ハウジング71上面の操作ボタン72cより後面側に、複数のLED702が設けられる。ここで、コントローラ7は、他のコントローラ7と区別するためにコントローラ種別(番号)が設けられている。例えば、LED702は、コントローラ7に現在設定されている上記コントローラ種別をプレイヤに通知するために用いられる。具体的には、コントローラ7から受信ユニット6へ送信データを送信する際、上記コントローラ種別に応じて複数のLED702のうち、種別に対応するLEDが点灯する。
一方、ハウジング71下面には、凹部が形成されている。後述で明らかとなるが、ハウジング71下面の凹部は、プレイヤがコントローラ7を把持したときに当該プレイヤの人差し指や中指が位置するような位置に形成される。そして、上記凹部の後面側傾斜面には、操作ボタン72iが設けられる。操作ボタン72iは、例えばAボタンとして機能する操作部であり、シューティングゲームにおけるトリガスイッチや、プレイヤオブジェクトを所定オブジェクトに対して注目させる操作等に用いられる。
また、ハウジング71前面には、撮像情報演算部74の一部を構成する撮像素子743が設けられる。ここで、撮像情報演算部74は、コントローラ7が撮像した画像データを解析してその中で輝度が高い場所を判別してその場所の重心位置やサイズなどを検出するためのシステムであり、例えば、最大200フレーム/秒程度のサンプリング周期であるため比較的高速なコントローラ7の動きでも追跡して解析することができる。また、ハウジング70の後面には、コネクタ73が設けられている。コネクタ73は、例えば32ピンのエッジコネクタであり、例えば接続ケーブルと嵌合して接続するために利用される。
ここで、説明を具体的にするために、コントローラ7に対して設定する座標系について定義する。図3および図4に示すように、互いに直交するXYZ軸をコントローラ7に対して定義する。具体的には、コントローラ7の前後方向となるハウジング71の長手方向をZ軸とし、コントローラ7の前面(撮像情報演算部74が設けられている面)方向をZ軸正方向とする。また、コントローラ7の上下方向をY軸とし、ハウジング71の上面(十字キー72a等が設けられた面)方向をY軸正方向とする。さらに、コントローラ7の左右方向をX軸とし、ハウジング71の左側面(図3では表されずに図4で表されている側面)方向をX軸正方向とする。
次に、図5を参照して、コントローラ7の内部構造について説明する。なお、図5(a)は、コントローラ7の上筐体(ハウジング71の一部)を外した状態を示す斜視図である。図5(b)は、コントローラ7の下筐体(ハウジング71の一部)を外した状態を示す斜視図である。ここで、図5(b)に示す基板700は、図5(a)に示す基板700の裏面から見た斜視図となっている。
図5(a)において、ハウジング71の内部には基板700が固設されており、当該基板700の上主面上に操作ボタン72a〜72h、加速度センサ701、LED702、水晶振動子703、無線モジュール753、およびアンテナ754等が設けられる。そして、これらは、基板700等に形成された配線(図示せず)によってマイコン751(図6参照)に接続される。加速度センサ701は、コントローラ7が配置された3次元空間における傾きや振動等の算出に用いることができる加速度を検出して出力する。
より詳細には、図6に示すように、コントローラ7は3軸の加速度センサ701を備えていることが好ましい。この3軸の加速度センサ701は、3方向、すなわち、上下方向(図3に示すY軸)、左右方向(図3に示すX軸)、および前後方向(図3に示すZ軸)で直線加速度を検知する。また、他の実施形態においては、ゲーム処理に用いる制御信号の種類によっては、X軸とY軸(または他の対になった軸)のそれぞれに沿った直線加速度のみを検知する2軸の加速度検出手段を使用してもよい。例えば、この3軸または2軸の加速度センサ701は、アナログ・デバイセズ株式会社(Analog Devices, Inc.)またはSTマイクロエレクトロニクス社(STMicroelectronics N.V.)から入手可能であるタイプのものでもよい。加速度センサ701は、シリコン微細加工されたMEMS(Micro Electro Mechanical Systems:微小電子機械システム)の技術に基づいた静電容量式(静電容量結合式)であることが好ましい。しかしながら、既存の加速度検出手段の技術(例えば、圧電方式や圧電抵抗方式)あるいは将来開発される他の適切な技術を用いて3軸または2軸の加速度センサ701が提供されてもよい。
当業者には公知であるように、加速度センサ701に用いられるような加速度検出手段は、加速度センサの持つ各軸に対応する直線に沿った加速度(直線加速度)のみを検知することができる。つまり、加速度センサ701からの直接の出力は、その2軸または3軸のそれぞれに沿った直線加速度(静的または動的)を示す信号である。このため、加速度センサ701は、非直線状(例えば、円弧状)の経路に沿った動き、回転、回転運動、角変位、傾斜、位置、または姿勢等の物理特性を直接検知することはできない。
しかしながら、加速度センサ701から出力される加速度の信号に対して追加の処理を行うことによって、コントローラ7に関するさらなる情報を推測または算出(判定)することができることは、当業者であれば本明細書の説明から容易に理解できるであろう。例えば、静的な加速度(重力加速度)が検知されると、加速度センサ701からの出力を用いて、傾斜角度と検知された加速度とを用いた演算によって重力ベクトルに対する対象(コントローラ7)の傾きを判定することができる。このように、加速度センサ701をマイコン751(または他のプロセッサ)と組み合わせて用いることによって、コントローラ7の傾き、姿勢または位置を判定することができる。同様に、加速度センサ701を備えるコントローラ7が例えば後述するようにユーザの手で動的に加速されて動かされる場合に、加速度センサ701によって生成される加速度信号を処理することによって、コントローラ7のさまざまな動きおよび/または位置を算出することができる。他の実施例では、加速度センサ701は、信号をマイコン42に出力する前に内蔵の加速度検出手段から出力される加速度信号に対して所望の処理を行うための、組込み式の信号処理装置または他の種類の専用の処理装置を備えていてもよい。例えば、組込み式または専用の処理装置は、加速度センサが静的な加速度(例えば、重力加速度)を検出するためのものである場合、検知された加速度信号をそれに相当する傾斜角(あるいは、他の好ましいパラメータ)に変換するものであってもよい。
また、無線モジュール753およびアンテナ754を有する通信部75によって、コントローラ7がワイヤレスコントローラとして機能する。なお、水晶振動子703は、後述するマイコン751の基本クロックを生成する。
一方、図5(b)において、基板700の下主面上の前端縁に撮像情報演算部74が設けられる。撮像情報演算部74は、コントローラ7の前方から順に赤外線フィルタ741、レンズ742、撮像素子743、および画像処理回路744によって構成されており、それぞれ基板700の下主面に取り付けられる。また、基板700の下主面上の後端縁にコネクタ73が取り付けられる。そして、操作ボタン72iが撮像情報演算部74の後方の基板700の下主面上に取り付けられていて、それよりさらに後方に、電池705が収容される。電池705とコネクタ73との間の基板700の下主面上には、バイブレータ704が取り付けられる。このバイブレータ704は、例えば振動モータやソレノイドであってよい。バイブレータ704が作動することによってコントローラ7に振動が発生するので、それを把持しているプレイヤの手にその振動が伝達され、いわゆる振動対応ゲームが実現できる。
次に、図6を参照して、コントローラ7の内部構成について説明する。なお、図6は、コントローラ7の構成を示すブロック図である。
撮像情報演算部74は、赤外線フィルタ741、レンズ742、撮像素子743、および画像処理回路744を含んでいる。赤外線フィルタ741は、コントローラ7の前方から入射する光から赤外線のみを通過させる。ここで、モニタ2の表示画面近傍に配置されるマーカ8Lおよび8Rは、モニタ2の前方に向かって赤外光を出力する赤外LEDである。したがって、赤外線フィルタ741を設けることによってマーカ8Lおよび8Rの画像をより正確に撮像することができる。レンズ742は、赤外線フィルタ741を透過した赤外線を集光して撮像素子743へ出射する。撮像素子743は、例えばCMOSセンサやあるいはCCDのような固体撮像素子であり、レンズ742が集光した赤外線を撮像する。したがって、撮像素子743は、赤外線フィルタ741を通過した赤外線だけを撮像して画像データを生成する。撮像素子743で生成された画像データは、画像処理回路744で処理される。具体的には、画像処理回路744は、撮像素子743から得られた画像データ(マーカ8Lおよび8Rの撮像画像)を処理して高輝度部分を検知し、それらの位置座標や面積を検出した結果を示す処理結果データを通信部75へ出力する。なお、これらの撮像情報演算部74は、コントローラ7のハウジング71に固設されており、ハウジング71自体の方向を変えることによってその撮像方向を変更することができる。この撮像情報演算部74から出力される処理結果データに基づいて、コントローラ7の位置や動きに応じた信号を得ることができ、当該信号に基づいてモニタ2の画面座標系に基づいた入力座標を得ることができる。つまり、コントローラ7は、撮像情報演算部74から出力される処理結果データによってポインティングデバイスとして機能する。
加速度センサ701は、上述したようにコントローラ7の上下方向(Y軸方向)、左右方向(X軸方向)、および前後方向(Z軸方向)の3軸成分に分けてそれぞれ加速度を検知して出力するセンサである。加速度センサ701が検知した3軸成分の加速度を示すデータは、それぞれ通信部75へ出力される。この加速度センサ701から出力される加速度データに基づいて、コントローラ7の動きを判定することができる。なお、加速度センサ701は、特定のアプリケーションで必要なデータに応じて何れか2軸に対してそれぞれ加速度を検出する加速度センサが用いられてもかまわない。
通信部75は、マイクロコンピュータ(Micro Computer:マイコン)751、メモリ752、無線モジュール753、およびアンテナ754を含んでいる。マイコン751は、処理の際にメモリ752を記憶領域として用いながら、送信データを無線送信する無線モジュール753を制御する。
コントローラ7に設けられた操作部72からの操作信号(キーデータ)、加速度センサ701からの3軸方向の加速度信号(X、Y、およびZ軸方向加速度データ)、および撮像情報演算部74からの処理結果データは、マイコン751に出力される。マイコン751は、入力した各データ(キーデータ、X、Y、およびZ軸方向加速度データ、処理結果データ)を受信ユニット6へ送信する送信データとして一時的にメモリ752に格納する。ここで、通信部75から受信ユニット6への無線送信は、所定の周期毎に行われるが、ゲームの処理は1/60秒を単位として行われることが一般的であるので、それよりも短い周期で送信を行うことが必要となる。具体的には、ゲームの処理単位は16.7ms(1/60秒)であり、ブルートゥース(登録商標)で構成される通信部75の送信間隔は5msである。マイコン751は、受信ユニット6への送信タイミングが到来すると、メモリ752に格納されている送信データを一連の操作情報として出力し、無線モジュール753へ出力する。そして、無線モジュール753は、例えばBluetooth(ブルートゥース;登録商標)の技術を用いて、所定周波数の搬送波を用いて操作情報をその電波信号としてアンテナ754から放射する。つまり、コントローラ7に設けられた操作部72からのキーデータ、加速度センサ701からのX、Y、およびZ軸方向加速度データ、および撮像情報演算部74からの処理結果データがコントローラ7から送信される。そして、ゲーム装置3の受信ユニット6でその電波信号を受信し、ゲーム装置3で当該電波信号を復調や復号することによって、一連の操作情報(キーデータ、X、Y、およびZ軸方向加速度データ、および処理結果データ)を取得する。そして、ゲーム装置3のCPU30は、取得した操作情報とゲームプログラムとに基づいて、ゲーム処理を行う。なお、Bluetooth(登録商標)の技術を用いて通信部75を構成する場合、通信部75は、他のデバイスから無線送信された送信データを受信する機能も備えることができる。
(第1の実施形態)
次に、図7〜図9を用いて、第1の実施形態で想定するゲームの概要について説明する。図7は、第1の実施形態で想定するゲームの画面の一例である。本ゲームは、ダーツゲームであり、図7においては、モニタ2にはダーツボード100と、カーソル101が表示されている。プレイヤは、コントローラ7の前面をモニタに向けた状態で、あたかもダーツを持つようにコントローラ7を把持する。この状態で、当該コントローラ7を上下左右に動かすことで、カーソル101を移動させる。このときのカーソル101は、コントローラ7の撮像情報演算部74によって撮像される撮像画像内のマーカ8Lおよび8Rの位置座標を用いて算出される指示位置に合せて移動表示される。そして、プレイヤは、ダーツを打ち出したい位置にカーソル101を合わせたら、あたかもダーツを投げるかのように、コントローラ7を少し前に、かつ、ある程度の勢いをつけて突き出す。この突き出し動作時におけるZ軸方向(モニタ2の方向)の加速度を調べて、加速度が所定値を超えたタイミング(ダーツが手から離れたものとみなされるタイミング)を検出する。そして、このときのカーソル101の位置をダーツが飛んでいく目標位置として確定する。また、当該突き出し動作時におけるZ軸方向(モニタ2の方向)の一連の加速度を調べることで、一連の突き出し動作の開始タイミングを求め、上記加速度が所定値を超えたタイミングとの差分からダーツの速度を算出する。その結果、図8および図9に示すように、当該算出された速度で、ダーツボード100(より正確には、上記目標位置)に向かってダーツ102が飛んでいく様子が表示されることになる。このように、本ダーツゲームでは、コントローラ7をダーツ102に見立てて、画面内に表示されているダーツボード100に投げるような動作を行うことで点数を競うものである。なお、点数を競うのではなく、ダーツボード100の任意の範囲内にダーツが当たれば成功とし、それ以外の場所にダーツが当たった場合は失敗とするようなルールにしてもよい。
次に、ゲームシステム1において行われるゲーム処理の詳細を説明する。まず、図10を参照して、ゲーム処理において用いられる主なデータについて説明する。なお、図10は、ゲーム装置3のメインメモリ33に記憶される主なデータを示す図である。
図10に示すように、メインメモリ33には、加速度データDa、ポインティング有効フラグDb、および画像データDc等が記憶される。なお、メインメモリ33には、図10に示す情報に含まれるデータの他、仮想ゲーム空間に関するデータ(地形データ等)等、ゲーム処理に必要なデータが記憶される。
加速度データDaは、コントローラ7から送信データとして送信されてくる一連の操作情報に含まれる加速度データであり、得られた加速度データを所定フレーム分(例えば、ゲーム処理間隔である1フレーム(1/60秒)に対して30フレーム分)格納する。加速度データDaには、加速度センサ701がX、Y、およびZ軸の3軸成分に分けてそれぞれ検出したX軸方向加速度データDa1、Y軸方向加速度データDa2、およびZ軸方向加速度データDa3が含まれる。なお、ゲーム装置3に備える受信ユニット6は、コントローラ7から所定間隔例えば5msごとに送信される操作情報に含まれる加速度データDaを受信し、受信ユニット6に備える図示しないバッファに蓄えられる。その後、ゲーム処理間隔である1フレーム毎に読み出されてメインメモリ33に記憶される。
ポインティング有効フラグDbは、撮像素子743のあるコントローラ7の前面がモニタ2に向けているかどうか、換言すれば、コントローラ7でモニタ2の画面座標系における位置が指示されているか否か(ポインティングされているか否か)を示すためのフラグである。コントローラ7の前面を、モニタ2に向けていない場合は、本フラグはオフに設定されることになる。
画像データDcは、ダーツボード画像データDc1、ダーツ画像データDc2およびカーソル画像データDc3等を含み、仮想ゲーム世界にダーツボード100やダーツ102を配置してゲーム画像を生成するためのデータである。
次に、図11〜図13を参照して、ゲーム装置3において行われるゲーム処理の詳細を説明する。なお、図11および図12は、ゲーム装置3において実行されるゲーム処理の流れを示すフローチャートである。図13は、図12におけるステップ14の打ち出しパラメータ計算処理の詳細な動作を示すサブルーチンである。なお、図11〜図13に示すフローチャートにおいては、ゲーム処理のうち、プレイヤがダーツに見立てたコントローラ7を打ち出すようなゲーム操作に基づいて行われるゲーム処理について説明し、本願発明と直接関連しない他のゲーム処理については詳細な説明を省略する。また、図11〜図13では、CPU30が実行する各ステップを「S」と略称する。
ゲーム装置3の電源が投入されると、ゲーム装置3のCPU30は、図示しないブートROMに記憶されている起動プログラムを実行し、これによってメインメモリ33等の各ユニットが初期化される。そして、光ディスク4に記憶されたゲームプログラムがメインメモリ33に読み込まれ、CPU30によって当該ゲームプログラムの実行が開始される。図11〜図12に示すフローチャートは、以上の処理が完了した後に行われるゲーム処理を示すフローチャートである。また、図11〜図12に示すステップ1〜ステップ15の処理ループは、1フレーム毎に繰り返し実行される。
図11において、まず、CPU30は、上記ポインティング有効フラグDbの初期化を行う(ステップ1)。次に、CPU30は、コントローラ7による画面指示(以下、ポインティング機能)が有効であるか否かを確認する(ステップ2)。これは、例えば、上記撮像情報演算部74から出力される処理結果データにおいて、上記マーカ8Lあるいは8Rから出力された赤外光が撮影されていることが示されているか否かで判定する。その結果、マーカ8Lあるいは8Rからの赤外光が撮影されていないときは(ステップ2でNO)、コントローラ7の前面をモニタ2の方向に向けていないと考えられるため、ポインティング有効フラグDbをオフに設定する(ステップ9)。更に、カーソル101を非表示にして(ステップ10)、処理をステップ6に進める。
一方、マーカ8Lあるいは8Rからの赤外光が撮影されているときは(ステップ2でYES)、コントローラ7の前面をモニタ2の方向に向けていると考えられるため、CPU30は、ポインティング有効フラグDbをオンに設定する(ステップ3)。続いて、コントローラ7から送信データとして送信されてくる一連の操作情報から、モニタ2の画面座標系に基づいた入力座標、つまり、コントローラ7が指示している座標(ポインティング座標)を取得し、仮想ゲーム空間における座標系に基づいたカーソル座標に変換する(ステップ4)。カーソル座標は、仮想ゲーム空間内におけるカーソル101の位置を示すものであり、例えば線形変換等を用いて変換される。
次に、CPU30は、上記変換されたカーソル座標に基づいて、カーソル101を表示する(ステップ5)。
次に、CPU30は、コントローラ7から送信データとして送信されてくる一連の操作情報から、Z軸方向の加速度(以下、Z軸加速度と呼ぶ)を取得する(ステップ6)。
次に、CPU30は、ステップ6で取得したZ軸加速度(今回のフレームにおけるZ軸加速度)と、前回のフレームにおいて取得されたZ軸加速度との差分を求める(ステップ7)。
次に、CPU30は、メインメモリ内に設けられたバッファ(図示せず)に今回のZ軸加速度を格納する(ステップ8)。つまり、加速度データを当該バッファに蓄えていく。なお、当該バッファは、リングバッファとして構成されており、バッファサイズは20であるとする。
次に、CPU30は、今回のフレームにおけるZ軸加速度が所定値を超えているか否かを判定する(ステップ11)。本ゲームにおいては、当該所定値を超えた時点をダーツが手から離れた時点とみなしている。つまり、当該判定は、ダーツが手から離れたか、すなわち打ち出し操作の終了時点を判定していることになる。その結果、所定値を超えていないときは(ステップ11でNO)、上記ステップ2に戻って処理を繰り返す。
一方、ステップ11の判定の結果、今回のフレームにおけるZ軸加速度が所定値を超えているときは(ステップ11でYES)、CPU30は、ポインティング有効フラグDbがオンであるか否かを判定する(ステップ12)。その結果、ポインティング有効フラグDbがオフのときは(ステップ12でNO)、上記ステップ2に戻って処理を繰り返す。一方、ポインティング有効フラグDbがオンであれば(ステップ12でYES)、上記カーソル座標を、ダーツ102の到達目標地点として確定する(ステップ13)。これはつまり、プレイヤによる位置の指示を確定することでもある。
続いて、CPU30は、ダーツ102が飛ぶ速度等を算出するために、打ち出しパラメータ計算処理を行う(ステップ14)。本処理では、図14のグラフで示すような、一連の打ち出し操作における加速度について、上記所定値を超えた時点(図14のT1)から波形を遡って調べていき、一連の打ち出し操作の開始時点(図14のT0;加速が開始されたタイミング)を探すための処理が行われる。
図13は、上記ステップ14で示した打ち出しパラメータ計算処理の詳細を示すフローチャートである。図13において、まず、CPU30は、変数iを0にする(ステップ21)。次に、上記バッファに蓄えられた加速度データのうち、新しいものからi個目のZ軸加速度を取得する(ステップ22)。続いて、i+1個前のZ軸加速度を取得する(ステップ23)。
続いて、CPU30は、i個目のZ軸加速度が、i+1個前のZ軸加速度より大きいか否かを判定する(ステップ24)。その結果、i個目のZ軸加速度がi+1個前のZ軸加速度より大きければ(ステップ24でYES)、CPU30は、iに1を加算する(ステップ25)。その後、上記バッファ内のZ軸加速度について全て調べたかを判定する(ステップ26)。全てのZ軸加速度を調べ終わっていなければ(ステップ26でNO)、ステップ24の判定に戻り、全て調べ終えたときは(ステップ26でYES)、処理を次に進める。なお、ここではZ軸の値は正の方向に向かって打ち出す場合を想定しているが、もちろん、これに限らず打ち出す方向を負の方向を打ち出す方向として設定してもよい。この場合は、上記ステップ24の判定では、i個目のZ軸加速度がi+1個前のZ軸加速度より小さいか否か(i個目のZ軸加速度<i+1個前の加速度)を判定することになる。
一方、上記ステップ24の判定の結果、i個目のZ軸加速度がi+1個前のZ軸加速度より大きくないときは(ステップ24でNO)、現在からi個前のフレームが打ち出し開始フレーム、すなわち、打ち出し開始時点T0であると考えられる。そのため、現在からi個前のフレームを打ち出し開始フレームとして確定する(ステップ27)。
続いて、CPU30は、i個前のフレームから現在までのフレーム数(つまり、打ち出し開始から打ち出し終了までにかかった時間)に基づいて、ダーツの飛んでいく速度を決定する(ステップ28)。例えば、当該速度は、上記打ち出し開始から打ち出し終了までにかかった時間に反比例するように算出される。更に、CPU30は、上記打ち出し開始フレーム時における加速度データ(X軸Y軸も含む)から、そのときのコントローラ7の傾きを算出する(ステップ29)。つまり、打ち出し開始時点のダーツの傾き具合を調べる。以上で、打ち出しパラメータ計算処理が終了する。
図12に戻り、ステップ14の打ち出しパラメータ計算処理が終われば、CPU30は、上記算出された速度に基づいてダーツ102を射出する処理を行う。このとき、ダーツ102の軌道等の計算上では、打ち出し位置は予め決められた位置を用いる。ただし、画面表示上、上記ステップ29で求めたコントローラ7の傾きに基づき、ダーツ102が射出箇所を変化させる。例えば、コントローラ7を右手で持っていた時などで、当該コントローラ7が左に傾いていたら、画面中央からやや右よりの位置からダーツ102が飛んでいくように表示(図9参照)する。また、コントローラ7を左手で持っていたとき等で、当該コントローラ7が右に傾いていれば、画面中央からやや左側寄りの位置からダーツ102が飛んでいくように表示する。また、このとき、上記算出された速度が所定値以上なら、上記ステップ13で確定した到達目標地点にダーツ102が刺さるように表示される。しかし、上記速度が足りないときは、当該到達目標地点より少し下にダーツ102が刺さるような調整が行われる。つまり、上記算出された速度に応じて、到達目標地点を変化させる。以上で、第1の実施形態にかかるゲーム処理は終了する。
このように、第1の実施形態では、レバーやボタンに依存せずに、手にした入力装置(コントローラ7)を所望の方向に動かすだけで、位置の指定操作とオブジェクトの動作指示操作とを行うことができる。そのため、斬新で直感的な操作が可能となり、新しい操作感覚のゲームを提供することができる。また、ゲームの内容によっては、ダーツを投げる、あるいは物を引き抜くといったような動作について、現実世界における当該動作を同じような動作を行わせてゲームに反映させることができ、よりリアリティが高く、感情移入しやすいゲームを提供することができる。その結果、ゲームの興趣性を高めることが可能となる。
なお、上述のような打ち出す操作を、メニューの項目選択や、ボタンを押す動作に見立ててもよい。例えば、画面上に一覧形式でメニューを表示し、選択したい項目にカーソルを合わせて、上述のような打ち出し操作を行うことで、当該項目を選択できるようにしてもよい。この場合も、人間の実際の操作感覚に近い形で操作することができ、直感的なインターフェースを提供することが可能となる。
(第2の実施形態)
次に、図15から図24を参照して、本発明の第2の実施形態について説明する。図15〜図17は、第2の実施形態で想定するゲームの画面の一例である。本ゲームは、画面に表示されているオブジェクトを制限時間内に引き抜くゲームである。図15では、引き抜き対象となるオブジェクト201(以下、引き抜き物と呼ぶ)と、手の形をしたカーソル202が表示されている。このような画面において、プレイヤは、コントローラ7の前面をモニタに向け、手先を上下左右に動かすことでカーソル202を動かす。その結果、カーソル202が引き抜き物201に近づくと、図16に示すように、カーソル202の表示が引き抜き物201を掴んだ状態に変化する。この状態で、プレイヤは、当該引き抜き物201を引き抜くかのように、コントローラ7を上方向に勢いをつけて動かす(つまり、引き抜き操作を行う)。このとき、動かした勢い(加速度)が十分なものであれば、引き抜きアニメーションが表示され、その結果、図17に示すように、引き抜き物201が引き抜かれた状態となり、引き抜き成功となる。一方、勢いが足りないときは、引き抜き物201を抜くことができず、引き抜き損ねた旨のアニメーションが表示されて、引き抜き失敗となる。このような操作を繰り返すことで、画面に表示されている複数の引き抜き物を、制限時間内に全て引き抜くことができれば目的達成(ゲームクリアに成功)となり、制限時間内に全て引き抜けなかったときは目的非達成(ゲームクリアに失敗)となる。
ここで、説明の便宜上、上述の一連の処理について、以下の3つの状態に分ける。
1.引き抜き物を掴んでいない状態である、「フリー」状態。
2.引き抜き物を掴み、引き抜き操作が行われるまでの間である、「掴み中」状態。
3.引き抜きアニメーションが表示されている間である、「引抜き中」状態。
従って、上述した処理は、以下のように状態遷移することになる。
「フリー」状態→(カーソルを移動した結果)「掴み中」に遷移→(引き抜き操作の結果)「引き抜き中」状態に遷移→(引き抜きアニメーションが終われば)「フリー」状態に遷移。
次に、図18を参照して、第2の実施形態にかかるゲーム処理において用いられる主なデータについて説明する。なお、図18は、ゲーム装置3のメインメモリ33に記憶される主なデータを示す図である。
図18に示すように、メインメモリ33には、加速度データDa、現在地データpos、最寄り物位置データOBJpos、ポインティング位置データDPDPos、ベクトルデータacc1〜3、総合ベクトルデータTotal、距離データdistance、カウントデータnData、掴み確定カウンタfCtr、および画像データDn等が記憶される。なお、メインメモリ33には、図18に示す情報に含まれるデータの他、仮想ゲーム空間に関するデータ(地形データ等)等、ゲーム処理に必要なデータが記憶される。
加速度データDaは、第1の実施形態における加速度データDaと同様である。そのため、ここでは詳細な説明は省略する。
現在地データPosは、カーソル202の現在位置を示すためのデータである。最寄り物位置データOBJPosは、カーソル202の位置から最寄りの位置にある上記引き抜き物201の位置を示すためのデータである。ポインティング位置データDPDPosは、プレイヤがコントローラ7でポインティングしている位置を示すためのデータである。
ベクトルデータacc1〜3および総合ベクトルデータTotalは、後述するフローチャートで、主に上述の引き抜き操作における加速度の検知のために用いられるデータである。
距離データDistanceは、カーソル202と、当該カーソル202から最寄りの位置にある上記引き抜き物201との間の距離を示すためのデータである。カウントデータnDataおよび掴み確定カウンタfCtrは、後述するフローチャートで用いられるカウント値を示すデータである。
以下、図19〜図24を用いて、本発明の第2の実施形態にかかるゲーム処理の詳細を説明する。図19および図20は、第2の実施形態にかかるゲーム処理を示すフローチャートである。
ゲーム装置3の電源が投入されると、ゲーム装置3のCPU30は、図示しないブートROMに記憶されている起動プログラムを実行し、これによってメインメモリ33等の各ユニットが初期化される。そして、光ディスク4に記憶されたゲームプログラムがメインメモリ33に読み込まれ、CPU30によって当該ゲームプログラムの実行が開始される。図19〜図20に示すフローチャートは、以上の処理が完了した後に行われるゲーム処理を示すフローチャートである。また、図19〜図20に示すステップ31〜ステップ49の処理ループは、1フレーム毎に繰り返し実行される。
図19において、まず、CPU30は、状態を「フリー」にし、各種データの初期化を行う(ステップ31)。次に、CPU30は、状態が「引き抜き中」であるか否かを判定する(ステップ32)。その結果、「引き抜き中」でないときは(ステップ32でNO)、続いて、状態が「掴み中」であるか否かを判定する(ステップ33)。その結果、「掴み中」でもないときは(ステップ33でNO)、「フリー」状態であるため、カーソルの移動処理を行う(ステップ37)。この処理では、プレイヤがコントローラ7で指示しているポインティング位置にカーソル202を移動させるための処理が行われる(詳細は後述)。
カーソル移動処理が終われば、続けて、CPU30は、カーソル202の位置から所定範囲内に引き抜き物201があるか否かを判定する(ステップ38)。その結果、引き抜き物201が所定範囲内にあるときは(ステップ38でYES)、掴み確定カウンタfCtrに1を加算する(ステップ39)。ここで、掴み確定カウンタfCtrとは、プレイヤの「掴む意思」を確認するべく、カーソル202が引き抜き物201の近くに留まっている時間を計るためのものである。続いて、CPU30は、掴み確定カウンタfCtrの値が所定値以上であるか否かを判定する(ステップ40)。その結果、所定値以上であれば(ステップ40でYES)、「掴み中」状態に遷移し(ステップ41)、ステップ32の処理に戻る。一方、所定値以上でないときは(ステップ40でNO)、そのままステップ32の処理に戻る。このように、カーソル202が引き抜き物201の側に来たときに、すぐにそれを掴まずに、ある程度の時間、カーソル202がその近辺に留まっている場合に、プレイヤに掴む意思があるとして、上記引き抜き物201を掴む処理を行う。これにより、例えば、引き抜き物201の上を通過したいだけにも関わらず、当該引き抜き物201を掴んでしまうというような、過敏な反応による操作性の低下を防ぐことができる。
次に、上記ステップ33の判定でYESの場合の処理、すなわち、「掴み中」に遷移した後の処理について説明する。ステップ33の判定で、「掴み中」であると判定されたとき(ステップ33でYES)、CPU30は、カーソル202を掴んでいる様子の表示(図16参照)に変化させたうえで、引き抜き力判定処理を行う(ステップ34)。この処理は、上方向の加速度を検出することによって、上述したような引き抜き操作が行われたか、また、その引き抜く勢いがどの程度かを判定するための処理である(詳細は後述)。なお、「掴み中」に遷移した後は、「フリー」状態に戻るまで、コントローラ7の指示位置に関する処理は行われない。
ステップ34の処理の次に、CPU30は、引き抜きOKフラグがオンであるかどうかを判定する(ステップ35)。ここで、引き抜きOKフラグとは、プレイヤによって行われた引き抜き操作の際に、引き抜きが成功するのに十分な加速度(勢い)があったか否かを示すためのフラグである。つまり、当該判定では、引き抜き操作について、引き抜きが成功するのに十分な勢いがあったかどうかを判定している。当該判定の結果、オンであるときは(ステップ35でYES)、十分な勢いがあったとして「引き抜き中」に遷移する。更に、予め用意されたアニメーションである、引き抜きアニメーションの表示処理を開始する(ステップS36)。なお、当該引き抜きアニメーションは、数十フレーム分のコマ数を有している。その後、ステップ32の処理に戻る。
一方、引き抜きOKフラグがオンではないときは(ステップ35でNO)、CPU30は、引き抜きNGフラグがオンであるか否かを判定する(図20のステップ43)。ここで、引き抜きNGフラグとは、引き抜き操作自体は完了したが、引き抜くに足る勢いが無かったことを示すためのフラグである。換言すれば、当該判定では、引き抜く勢いは足りないものの、引き抜き操作自体は行われたのかどうかを判定する。当該判定の結果、引き抜きNGフラグがオンの場合(ステップ43でYES)、これは、引き抜き操作は行われた(所定値以上の上向きの加速度は検出された)が、引き抜けるだけの勢いがなかったことを示している。従って、この場合は、引き抜き失敗のアニメーション、例えば、カーソル202と引き抜き物201が振動する様子を表示する(ステップ44)。続いて、制限時間を経過したか否かを判定する(ステップ45)。まだ制限時間内であれば(ステップ45でNO)、ステップ32の処理に戻り、制限時間が経過していれば(ステップ45でYES)、例えば失敗メッセージ等を表示して、ゲーム処理を終了する。
一方、引き抜きNGフラグがオンでないときは(ステップ43でNO)、まだ引き抜き操作が完了していないため、そのまま上記ステップ45の制限時間が経過したか否かの判定に進む。
次に、上記ステップ32の判定でYESの場合、すなわち、「引き抜き中」状態に遷移した後の処理について説明する。ステップ32の判定で「引き抜き中」と判定されると(ステップ32でYES)、CPU30は、上記引き抜きアニメーションが終了したか否かを判定する(ステップ46)。当該判定の結果、まだ引き抜きアニメーションが終了していないときは(ステップ46でNO)、そのまま上記ステップ32の処理に戻る。
一方、引き抜きアニメーションが終了したときは(ステップ46でYES)、続けて、CPU30は、引き抜き物201が全て引き抜かれたか否かを判定する(ステップ47)。当該判定の結果、全ての引き抜き物201が引き抜かれていれば(ステップ47でYES)、例えば点数の加算などの成功処理が行われ(ステップ49)、ゲーム処理が終了する。一方、まだ引き抜かれていない引き抜き対象物があるときは(ステップ47でNO)、カーソルの形状を何も掴んでいない様子(図15参照)に変化させたうえで、状態を「フリー」に遷移させる(ステップ48)。そして、上記ステップ32の処理に戻り、処理を繰り返す。以上で、ゲーム処理が終了する。
次に、上記ステップ37で示したカーソル移動処理の詳細について説明する。図21は、上記ステップ37で示したカーソル移動処理の詳細を示すフローチャートである。図21において、まず、現在地データPosに現在のカーソル位置の座標(例えばカーソル202の中心座標)を設定する(ステップ61)。次に、ポインティング機能が有効か否かを判定する(ステップ62)。この処理は、上記第1の実施形態で図11を用いて説明したステップ2の処理と同様である。そのため、詳細な処理内容の説明は省略する。当該判定の結果、ポインティング機能が有効であれば(ステップ62でYES)、続いて、コントローラ7が指示している座標(ポインティング座標)を取得する。そして、仮想ゲーム空間における座標系に基づいた座標に変換して、当該変換した座標をポインティング位置データDPDposに設定する(ステップ63)。次に、カーソル202の座標を、上記ポインティング位置データDPDPosの座標に近づける。つまり、カーソル202の位置を、プレイヤがコントローラ7で指示した位置に近づける(ステップ64)。具体的には、カーソルの座標は以下の式で算出される。
Pos=Pos+定数×(DPDPos−Pos)
次に、CPU30は、カーソル202の位置から所定距離内に引き抜き物201があるかどうかを判定する(ステップ65)。当該判定の結果、所定距離内に引き抜き物201がなければ(ステップ65でNO)、そのままカーソル移動処理を終了する。
一方、所定距離内に引き抜き物201があるときは(ステップ65でYES)、当該引き抜き物201にカーソル202があたかも吸い寄せられていくような表現を行うため、以下のような処理を行ってカーソル202の座標を調整する。まず、最寄り物位置データOBJPosに当該引き抜き物201の位置(例えば、当該引き抜き物201の中心の座標)を設定する(ステップ66)。次に、距離データDistanceを、以下の式で求める(ステップ67)。
Distance=Pos−OBJPos
次に、CPU30は、カーソル202の座標を引き抜き物201の座標に近づける(ステップ68)。具体的には、以下の式でカーソル202の座標を算出する。
Pos=Pos+(OBJPos−Pos)×定数/(Distance×Distance×Distance)
これにより、カーソルを、引き抜き物201までの距離の2乗に反比例した大きさだけ近づけている。
このような処理を行うことで、カーソル202が引き抜き物201に近づけば近づくほど、あたかも当該引き抜き物201に吸い寄せられるような表現を行うことができる。これにより、当該引き抜き物201の表示場所を正確に指示しなくてもよいため、引き抜き物201を掴みやすくすることができ、ひいては操作性の向上を図ることができる。以上で、カーソル移動処理は終了する。
次に、上記ステップ34で示した引き抜き力判定処理について説明する。まず、当該処理の概要を図22を用いて説明する。また、以下の説明では、加速度をベクトルで表現して説明する。当該処理では、まず、コントローラ7の座標系(以下、ローカル座標系)を空間座標系(重力方向がY軸のマイナス方向となる直交座標系)に変換するための回転行列を求める。当該回転行列は、コントローラ7の姿勢にかかわらず、例えば、上記ハウジング71の上面が上を向いていようが、側面が上を向いていようが、人間の感覚からして「上」方向にコントローラを振れば、当該ゲーム処理内でも「上」方向に振られたと判定するために用いられるものである。例えば、図22(a)に示すような水平状態にあるコントローラ7を、図22(b)に示すように時計回りに90度傾けた場合(ハウジング71の左側面を上方向に向けた状態)を考える。この場合は、図22(c)に示すように、傾けた後のコントローラ7のローカル座標系における重力方向のベクトル301(X軸マイナス方向)と、空間座標系における重力方向のベクトル302(Y軸マイナス方向;以下、重力ベクトルと呼ぶ)とから、回転行列303が求められる。
次に、コントローラ7から検出されたローカル座標系におけるベクトルに上記回転行列をかける。例えば、図22(b)の状態(傾けた状態)にした後、図22(d)に示すように、コントローラ7が上方向に振られたとする。この場合は、ローカル座標系におけるX軸プラス方向のベクトル304(コントローラ7を基準に考えると、左方向に振られたことになる)が検出される。そして、図22(e)に示すように、ゲーム空間座標内にこのX軸プラス方向のベクトル304を適用し、上記回転行列をかける。すると、ゲーム空間座標内におけるY軸プラス方向のベクトル305に変換される。次に、当該ベクトルから重力ベクトル分を差し引くことで、プレイヤの力による純粋なベクトルを求める。そして、このベクトルが所定値以上であれば、引き抜きに足る勢いがあると判定する、というような処理が行われる。
図23は、上記ステップ34で示した引き抜き力判定処理の詳細を示すフローチャートである。図23において、CPU30は、まず、上記引き抜きOKフラグおよび引き抜きNGフラグをオフにする(ステップ71)。次に、コントローラ7の姿勢変換用回転行列の算出処理を行う(ステップ72)。この処理の詳細については後述するが、上述した図22の回転行列303を求めるための処理が行われる。
上記ステップ72で回転行列が算出できれば、次に、今回のフレームで検出されたコントロ−ラ7のベクトルをベクトルデータacc1に設定する(ステップ73)。次に、当該ベクトルデータacc1に上記回転行列をかけたものをベクトルデータacc2として算出する(ステップ74)。つまり、acc2=姿勢変換用回転行列×acc1、となる。そして、ベクトルデータacc2から重力ベクトルを引いたものを、ベクトルデータacc3として算出する(ステップ75)。
次に、ベクトルデータacc3のY方向のベクトルの値が、予め定められた値である成功値以上かを判定する(ステップ76)。この成功値以上のベクトルがあれば、引き抜くのに十分な勢いがあったということになる。当該判定の結果、成功値以上であれば(ステップ76でYES)、引き抜きOKフラグをオンに設定する(ステップ77)。
一方、成功値以上でないときは(ステップ76でNO)、次に、予め定められた値である失敗値以上か否かを算出する(ステップ78)。この失敗値は、上記成功値よりも低い値が設定されている。つまり、上記成功値未満で当該失敗値以上のベクトルがあるときは、引き抜く勢いは足りないものの、引き抜き操作自体は行われたことを示すことになる。当該判定の結果、失敗値以上であれば(ステップ78でYES)、引き抜きNGフラグをオンに設定する(ステップ79)。一方、失敗値以上でないときは(ステップ78でNO)、そのまま上向き加速度検知処理を終了する。以上で、上向き加速度検知処理が終了する。この処理によって、上述したように、引き抜き操作における引き抜く勢いを検知することができる。
次に、上記ステップ72で示した姿勢変換用回転行列の算出処理について説明する。本処理の概要を説明すると、まず、現在のフレームから64フレーム前までの各フレーム毎におけるベクトル(加速度)を調べる。ここで、当該ベクトルについては、第1の実施形態でも説明したリングバッファに格納されるものとする。また、当該バッファサイズは64(つまり、64フレーム分)であるとする。次に、「1」に近い値のベクトルを有していたフレームの数を累計する。ここで、この「1」という値は、上記重力ベクトルの値(常にY軸マイナス方向に1のベクトルがかかっている)を基準としたものである。そのため、「1」前後のベクトルであれば、コントローラ7はあまり大きな動きをしていないと考えられる。つまり、ここでは、あまり動きが大きくないときのフレームをカウントしていき、動きが大きいときのフレームは除外している。換言すれば、過去64フレームを見て、この間のコントローラ7の動きが大きかったか否かを判定している。そして、このフレームの数が49以上(つまり、あまり大きな動きが検出されなかったとき。例えば、あまり勢いをつけずに、軽い動きでコントローラ7を右に90度傾けたとき)であれば、上述のような回転行列を算出する。逆に、過去64フレームにおいて、動きが大きかったと判定されたとき(上記フレーム数が48以下)は、それまでに用いていた回転行列を引き続き用いるようにする、という処理が行われる。
図24は、当該回転行列算出処理の詳細を示すフローチャートである。図24において、まず、総合ベクトルデータTotalに0を設定する。更に、カウントデータnDataに0を設定する(ステップ81)
次に、調べるフレームを示すための変数iに0を設定する(ステップ82)。次に、iが64未満であるかを判定する。つまり、過去64フレーム分を調べたかどうかを判定する(ステップ83)。当該判定の結果、64未満であれば(ステップ83でYES)、ベクトルデータacc1に最新のフレームからi個前のフレームにおけるベクトルを設定する(ステップ84)。
次に、当該ベクトルデータacc1の値が、0.8〜1.2の範囲内であるかどうかを判定する(ステップ85)。つまり、i個前のフレームにおけるコントローラ7の動きが大きかったかどうかを判定する。当該判定の結果、ベクトルデータaccの値が、0.8〜1.2の範囲内であれば(ステップ85でYES)、総合ベクトルデータTotalにベクトルデータacc1の値を加算する。これにより、加算されたベクトルデータaccの向きの平均が求まる。更に、カウントデータnDataに1を加算する(ステップ86)。次に、変数iに1を加算する(ステップ87)。そして、上記ステップ83の処理に戻る。一方、ベクトルデータacc1の値が、0.8〜1.2の範囲内ではないときは(ステップ85でNO)、ステップ86の処理を飛ばして、ステップ87の処理に進む。
一方、上記ステップ83でiが64より大きいと判定されれば(ステップ83でNO)、続いて、nDataが48より大きいか否かを判定する(ステップ88)。その結果、48より大きいときは(ステップ88でYES)、新たに姿勢変換用回転行列を求める(ステップ89)。この姿勢変換用回転行列は、回転行列×Total=重力ベクトル、という式が成立する回転行列のうち、回転角度が一番小さいものを姿勢変換用回転行列として採用することで求められる。
一方、nDataが48より小さいときは(ステップ88でNO)、新たな回転行列は算出せずに、それまで用いていた回転行列をそのまま姿勢変換用の回転行列として採用する(ステップ90)。以上で姿勢変換用の回転行列算出処理は終了する。このように、過去数十フレームにおいて、重力ベクトルとほぼ同じ大きさのベクトルがどの程度あったかを判定し、その結果に応じて新たに回転行列を求めることで、コントローラ7の動きの大きさに応じて、上記回転行列を求めることができる。これにより、コントローラ7の姿勢がどのような状態であっても、プレイヤがコントローラ7を振る動作(振る方向)を空間座標系を基準として捉えて処理することが可能となる。特に、検出される加速度ベクトルの大きさが重力ベクトルとほぼ同じ状態のままベクトルの方向のみが変化するような操作、すなわちコントローラ7を略静止状態に保ったままひねりながら回転させるような操作を行った場合に検出される重力加速度に近い値の加速度ベクトルの方向の変化を正確に把握して正しい方向(重力ベクトルの方向である空間座標系のY軸のマイナス方向)になるように補正することができるので、コントローラ7がどのような向きに変化されてもプレイヤによる振り方向を正確に検出することができる。また、現在から所定時間だけ遡ったときまでの間に複数検出される重力加速度に近い値の加速度の向きの平均を求めて、その平均の向きが重力ベクトルの方向になるように補正しているので、より精度良く振り方向を正確に検出することができる。
以上のように、上述した第2の実施形態では、コントローラ7で引き抜き物を指示(選択物確定)し、その後の引き抜き操作における加速度に応じて、引き抜き物が抜けるか抜けないかの制御を行っている。このような処理を行うことで、第1の実施形態と同様、直感的でわかりやすい操作感覚のゲームを提供することができる。また、上述のように姿勢変換用回転行列を算出して用いることで、コントローラ7の姿勢に関わらず、プレイヤがコントローラ7を振る動作について、空間座標系を基準として捉えて処理することが可能となる。その結果、プレイヤにとって違和感のない操作を提供することができる。
なお、上述した第2の実施形態においては、カーソル202が引き抜き物201の近づくと、自動的に当該物を掴んで、「掴み中」状態に遷移していた。これに限らずに、コントローラ7のボタン(例えばAボタン)が押されたときに、引き抜き物を掴むようにしてもよい。例えば、Aボタンが押された時点におけるカーソル位置を算出し、当該位置から所定範囲内に引き抜き物があれば、当該物を掴んで、「掴み中」に遷移するようにする。つまり、Aボタンを押したときに、(引き抜き物が近くにあれば)指示位置を確定するようにしてもよい。
また、加速度データから所定の加速のパターンが得られれば、掴むようにしてもよい。例えば、引き抜き物の近傍で、当該引き抜き物を囲むような円を描く操作を行うことで、「掴み中」状態に遷移するようにしてもよい。この場合は、コントローラ7の加速のパターンが円を描くようなパターン(例えば、X軸プラス方向からY軸プラス方向を経由してX軸マイナス方向、そしてY軸マイナス方向へと加速のかかり具合が変化していくパターン等)であるかどうかを加速度データに基づいて判定することが考えられる。
また、同じような加速のパターンが所定回数以上繰り返されたときに、指示位置を確定するようにしてもよい。例えば、のこぎりで丸太を切るというゲームを考える。このようなゲームにおいて、コントローラ7を前後に繰り返し動かすような動作を行ったとき、つまり、Z軸プラス方向の加速度とZ軸マイナス方向の加速度とが交互に検出されるようなパターンが続いたときに、その時点のカーソルの位置を丸太を切り込む位置として確定するというような処理を行ってもよい。このような処理を行うことで、現実世界での「のこぎりをひく」動作と同様の動作を行わせてゲームに反映させることができ、よりリアリティが高く、感情移入しやすいゲームを提供することができる。
なお、上述の実施形態では、モニタ2の表示画面近傍にマーカ8Lおよび8Rを設け、コントローラ7にマーカ8Lおよび8Rから出力される赤外光を撮像するための撮像装置を設けることによってコントローラ7の位置を検出するようにしたが、これに限られる必要はない。例えば、コントローラ7にマーカを設け、モニタ2の表示画面近傍に撮像装置を設けるようにしてもよい。また、撮像装置に代えて受光センサ等を用いてもよい。