(第1の実施形態)
図1は、本発明の一実施形態である携帯型のゲーム装置の外観図である。図1において、本実施形態のゲーム装置1は、2つの液晶表示器(以下、「LCD」という)11および12を所定の配置位置となるように、ハウジング18に収納して構成される。具体的には、第1LCD11および第2LCD12を互いに上下に配置して収納する場合は、ハウジング18が下部ハウジング18aおよび上部ハウジング18bから構成される。上部ハウジング18bは、下部ハウジング18aの上辺の一部で回動自在に支持される。上部ハウジング18bは、第2LCD12の平面形状よりも少し大きな平面形状を有し、一方主面から第2LCD12の表示画面を露出するように開口部が形成される。下部ハウジング18aは、横方向の略中央部に第1LCD11の表示画面を露出する開口部が形成される。下部ハウジング18aの平面形状は、上部ハウジング18bよりも横長に選ばれる。下部ハウジング18aには、第1LCD11を挟むいずれか一方にスピーカ15の音抜き孔15aが形成されるとともに、第1LCD11を挟む左右に操作スイッチ部14が装着される。
操作スイッチ部14は、第1LCD11の右横における下部ハウジング18aの一方主面に装着される動作スイッチ14aおよび14bと、第1LCD11の左横における下部ハウジング18aの一方主面に装着される方向指示スイッチ14c、スタートスイッチ14d、およびセレクトスイッチ14eとを含む。動作スイッチ14aおよび14bは、例えばアクションゲームにおいてはジャンプ、パンチ、武器を動かす等の指示、ロールプレイングゲーム(RPG)やシミュレーションRPGにおいてはアイテムの取得、武器またはコマンドの選択決定等の指示入力に使用される。方向指示スイッチ14cは、プレイヤによって操作可能なプレイヤオブジェクト(またはプレイヤキャラクタ)の移動方向を指示したり、カーソルの移動方向を指示したりする等のゲーム画面における方向指示に用いられる。また、必要に応じて、動作スイッチをさらに追加したり、下部ハウジング18aにおける操作スイッチ14の装着領域の上部面(上部側面)の左右に側面スイッチ14fおよび14gを設けたりしても構わない。
また、第1LCD11の上面には、タッチパネル13(図1における破線領域)が装着される。タッチパネル13は、例えば、抵抗膜方式、光学式(赤外線方式)、静電容量結合式のいずれの種類でもよく、その上面をスティック16(または指でも可)で押圧操作、移動操作、または撫でる操作をしたとき、スティック16の座標位置を検出して座標データを出力するものである。
上部ハウジング18bの側面近傍には、必要に応じてタッチパネル13を操作するスティック16を収納するための収納孔15b(図1における二点破線領域)が形成される。この収納孔15bには、スティック16が収納される。下部ハウジング18aの側面の一部には、ゲームプログラムを記憶したメモリ(例えば、ROM)を内蔵したゲームカートリッジ17(以下、単にカートリッジ17と記載する)を着脱自在に装着するためのカートリッジ挿入部(図1における一点破線領域)が形成される。カートリッジ17は、ゲームプログラムを記憶する情報記憶媒体であり、例えば、ROMまたはフラッシュメモリのような不揮発性半導体メモリが用いられる。カートリッジ挿入部の内部には、カートリッジ17と電気的に接続するためのコネクタ(図2参照)が内蔵される。さらに、下部ハウジング18a(または上部ハウジング18bでも可)には、CPU等の各種電子部品を実装した電子回路基板が収納される。なお、ゲームプログラムを記憶する情報記憶媒体としては、上記不揮発性半導体メモリに限らず、CD−ROM、DVD、あるいはそれらに類する光学式ディスク状記憶媒体でもよい。
次に、図2を参照して、ゲーム装置1の内部構成について説明する。なお、図2は、ゲーム装置1の内部構成を示すブロック図である。
図2において、ハウジング18aに収納される電子回路基板には、CPUコア21が実装される。CPUコア21には、所定のバスを介して、カートリッジ17と接続するためのコネクタ28が接続されるととともに、入出力インターフェース(I/F)回路27、第1のグラフィック処理ユニット(第1GPU)24、第2のグラフィック処理ユニット(第2GPU)26、およびワーキングRAM(WRAM)22が接続される。
コネクタ28には、カートリッジ17が着脱自在に接続される。カートリッジ17は、上述したようにゲームプログラムを格納するための記憶媒体であり、具体的には、ゲームプログラムを記憶するROM171とバックアップデータを書き換え可能に記憶するRAM172とを搭載する。カートリッジ17のROM171に記憶されたゲームプログラムは、WRAM22にロードされ、当該WRAM22にロードされたゲームプログラムがCPUコア21によって実行される。CPUコア21がゲームプログラムを実行して得られる一時的なデータや画像を生成するためのデータがWRAM22に記憶される。
I/F回路27には、タッチパネル13、操作スイッチ部14、およびスピーカ15が接続される。スピーカ15は、上述した音抜き孔15bの内側位置に配置される。
第1GPU24には、第1ビデオRAM(以下「VRAM」)23が接続され、第2GPU26には、第2のビデオRAM(以下「VRAM」)25が接続される。第1GPU24は、CPUコア21からの指示に応じて、WRAM22に記憶される画像を生成するためのデータに基づいて第1ゲーム画像を生成する。生成された第1ゲーム画像は、第1GPU24によって第1VRAM23に描画される。第2GPU26は、CPUコア21からの指示に応じて、WRAM22に記憶される画像を生成するためのデータに基づいて第2ゲーム画像を生成する。生成された第2ゲーム画像は、第2GPU26によって第2VRAM25に描画される。
第1VRAM23は第1LCD11に接続され、第2VRAM25は第2LCD12に接続される。第1GPU24は、CPUコア21からの指示に応じて第1VRAM23に描画された第1ゲーム画像を第1LCD11に出力する。そして、第1LCD11は、第1GPU24から出力された第1ゲーム画像を表示する。第2GPU26は、CPUコア21からの指示に応じて第2VRAM25に描画された第2ゲーム画像を第2LCD12に出力する。そして、第2LCD12は、第2GPU26から出力された第2ゲーム画像を表示する。
以下、カートリッジ17に格納されたゲームプログラムによってゲーム装置1において実行されるゲーム処理について説明する。なお、本発明においては、タッチパネルによって表示画面が覆われる第1LCD11のみを表示装置として用いる。従って、本発明に係るゲーム装置は、第2LCD12を有しない構成であってもよい。換言すれば、本発明に係るゲーム装置は、1つの表示装置のみで構成されるゲーム装置やPDA等を用いて実現することができる。
まず、ゲーム装置1において行われるゲームの概要を図3〜図9を用いて説明する。図3は、第1LCD11の表示画面に表示されるゲーム画像の一例を示す図である。本発明に係るゲーム装置で行われるゲームの種類はどのような種類であってもよいが、第1の実施形態では図3に示すようなロールプレイングゲームを例として説明する。このロールプレイングゲームでは、プレイヤが操作するプレイヤキャラクタがゲームマップ上を移動する移動シーン(図3(a))と、プレイヤキャラクタが敵キャラクタと戦闘する戦闘シーン(図3(b))とがある。移動シーンにおいて、プレイヤキャラクタが敵キャラクタと遭遇する所定の条件が満たされると、図3(a)に示すように、表示画面に「敵が現れた!!」と表示される。その後、ゲーム画像は、図3(b)に示すような戦闘シーンに切り替わる。なお、図1に示したような2つの表示装置を有するゲーム装置の場合は、移動シーンを第2LCD12に表示するとともに、戦闘シーンを第1LCD11に表示するようにしてもよい。
図3(b)に示す戦闘シーンにおいては、敵キャラクタ31を含むゲーム画像が第1LCD11の表示画面に表示される。このゲーム画像には、表示画面内を移動する目標画像32が含まれる。目標画像32は、プレイヤの指示目標を示す画像である。つまり、プレイヤは、敵キャラクタを攻撃するためのゲーム操作として、プレイヤの指が目標画像32に触れるようにタッチパネル13に対する入力を行う。なお、図3(b)において点線で描かれた円形および折れ線は、目標画像32が移動する様子を示し、実際のゲーム画像では表示されていない。
また、図3(b)に示す表示画面には、敵キャラクタの特性パラメータが表示される。特性パラメータとは、ゲームに登場するゲームキャラクタの特性を示す値である。具体的には、敵キャラクタのHP(ヒットポイント)およびMP(マジックポイント)が特性パラメータとして第1LCD11に表示される。ゲーム画像が戦闘シーンに切り替わった後は、プレイヤキャラクタおよび敵キャラクタが互いに攻撃を行うことによって戦闘が進む。
戦闘中においてプレイヤキャラクタが攻撃するターンになると、プレイヤは、敵キャラクタを攻撃するためのゲーム操作(攻撃操作)を行う。図4(a)は、プレイヤが攻撃操作を行う場合のゲーム画像の一例を示す図である。図4(a)に示すように、プレイヤは、タッチパネル入力で目標画像32を指定する。すなわち、目標画像32が表示される位置にプレイヤの指が触れるようにタッチパネル13に対する入力を行う。プレイヤが目標画像32を正しく指定することができた場合、プレイヤキャラクタによる敵キャラクタへの攻撃が行われる。一方、プレイヤが目標画像32を正しく指定することができなかった
場合、攻撃は行われない。
図4(b)は、プレイヤが攻撃操作を行った後のゲーム画像の一例を示す図である。なお、図4(b)は、プレイヤが目標画像32を正しく指定することができた場合のゲーム画像である。この場合、ゲーム装置1は、プレイヤキャラクタによる敵キャラクタへの攻撃処理として次のゲーム処理を行う。すなわち、プレイヤキャラクタによる敵キャラクタへの攻撃を示す攻撃エフェクト画像(効果画像)33が表示される。また、当該攻撃による敵キャラクタのダメージ量を示すダメージ画像34が表示される。図4(b)に示すダメージ画像34は、敵キャラクタに10のダメージ量を与えたことを示す。さらに、ゲーム装置1は、敵キャラクタ31の特性パラメータであるHPを変化させる処理を行う。図4(b)の例においては、ゲーム装置1は、敵キャラクタ31のHPを10だけ減算する。その結果、表示画面の左上における敵キャラクタの特性パラメータを示す表示において、敵キャラクタ31(図4(b)においては、「敵A」と表示されている)のHPが10だけ減算されて表示される。
なお、目標画像32は、ゲーム装置1において予め設定された規則(移動パターン)に従って移動してもよいし、ランダムに移動してもよい。第1の実施形態では、目標画像32は、表示画面の端で方向を変えて移動する。なお、他の実施形態では、目標画像32は、一定時間間隔またはランダムに決定される時間間隔で方向を変えて移動するようにしてもよい。また、方向を変える規則もどのような規則であってよい。例えば、定められた所定の角度だけ方向を変化させるような規則であってもよいし、ランダムに決められる角度だけ方向を変化させるような規則であってもよい。
また、第1の実施形態では、プレイヤが目標画像32を正しく指定することができた場合、目標画像32の表示形態が変化する。具体的には、目標画像32の色、形、または大きさが変化する。なお、ここでは、目標画像32の変化前の表示形態を斜線(図3(b))で示し、目標画像32の変化後の表示形態を黒丸(図3(b))で示している。目標画像32の表示形態が変化することによって、プレイヤは、目標画像32を正しく指定したことを視覚的に認識することができる。つまり、目標画像32を正しく指定したことがプレイヤにとって分かりやすくなる。
また、第1の実施形態では、敵キャラクタに与えられるダメージは、プレイヤが目標画像32を指定した位置に応じて変化する。すなわち、ゲーム装置1は、プレイヤが目標画像32を指定した位置と敵キャラクタ31との位置関係に応じて当該敵キャラクタのHPを変化させる。第1の実施形態では、敵キャラクタに与えられるダメージは、敵キャラクタの目の位置、敵キャラクタが持つ盾の位置、およびそれら以外の位置(通常位置)に応じて変化する。例えば、図4(b)においては、プレイヤによって通常位置が指定されており、この場合に敵キャラクタに与えられるダメージは“10”である。
図5(a)は、敵キャラクタの目の位置に対してプレイヤが攻撃操作を行う場合のゲーム画像の一例を示す図である。第1の実施形態では目標画像32は表示画面上を2次元的に移動することが可能であるので、プレイヤは、表示画面上の自由な位置を指定することができる。そのため、プレイヤは、例えば図5(a)のように敵キャラクタの目の位置を指定すること、すなわち、敵キャラクタの目の位置で目標画像32の移動を停止させることも可能である。図5(b)は、敵キャラクタの目の位置に対してプレイヤが攻撃操作を行った後のゲーム画像の一例を示す図である。図5(b)に示すように、敵キャラクタの目の位置がプレイヤによって指定された場合、敵キャラクタに与えられるダメージは“20”である。つまり、目の位置は敵キャラクタの弱点位置として設定されており、弱点位置がプレイヤによって指定された場合に敵キャラクタに与えられるダメージは、上記通常位置がプレイヤによって指定された場合よりも大きくなる。
図6(a)は、敵キャラクタが持つ盾の位置に対してプレイヤが攻撃操作を行う場合のゲーム画像の一例を示す図である。また、図6(b)は、敵キャラクタが持つ盾の位置に対してプレイヤが攻撃操作を行った後のゲーム画像の一例を示す図である。図6(b)に示すように、敵キャラクタが持つ盾の位置がプレイヤによって指定された場合、敵キャラクタに与えられるダメージは“5”である。敵キャラクタが持つ盾の位置は、通常位置よりも防御力が高い位置として設定されている。そのため、防御力が高い位置がプレイヤによって指定された場合に敵キャラクタに与えられるダメージは、上記通常位置がプレイヤによって指定された場合よりも小さくなる。
図7(a)は、敵キャラクタの画像以外の位置に対してプレイヤが攻撃操作を行う場合のゲーム画像の一例を示す図である。第1の実施形態では、ゲーム装置1は、敵キャラクタ31の画像上を通過するように目標画像32を移動させる。従って、目標画像32は、敵キャラクタ31の画像上のみを移動するのではなく、敵キャラクタ31の画像が表示される位置以外の位置も移動する。つまり、図7(a)のように敵キャラクタ31から外れた位置をプレイヤが指定することもあり得る。図7(b)は、敵キャラクタの画像以外の位置に対してプレイヤが攻撃操作を行った後のゲーム画像の一例を示す図である。図7(b)に示すように、プレイヤが敵キャラクタ31から外れた位置を指定してしまった場合、敵キャラクタ31にはダメージが与えられない。
以上、図4〜図7に示したように、第1の実施形態では、プレイヤが目標画像32を指定した位置と敵キャラクタ31との位置関係に応じて当該敵キャラクタのHPが変化する。従って、プレイヤは、目標画像32を指定するタイミングのみならず、目標画像32を指定する位置にも注意して入力操作を行わなければならない。つまり、本発明におけるゲームでは、移動する画像を観察しながら最適な位置で目標画像を指示するという操作スキルがゲームに反映されることとなる。また、実施の形態1では、プレイヤが目標画像32を指定した位置によって敵キャラクタに与えられるダメージが変化するので、プレイヤは、敵キャラクタの弱点を探すといった楽しみ方でゲームを遊ぶこともできる。
なお、以上の図4〜図7では、目標画像32が1つである場合について説明したが、目標画像32は複数であっても構わない。図8は、複数の目標画像を含むゲーム画像の一例を示す図である。図8では、5つの目標画像32a、32b、32c、32dおよび32eが第1LCD11の表示画面に表示されている。第1の実施形態では、各目標画像32a〜32eは表示画面の端で方向を変えて移動する。なお、他の実施形態では、各目標画像32a〜32eは互いに異なる規則に従って移動してもよいし、各目標画像32a〜32eのうちのいくつかはランダムに移動してもよい。
図9(a)は、目標画像が複数である場合においてプレイヤが攻撃操作を行うときのゲーム画像の一例を示す図である。図9(a)のように目標画像が複数である場合、プレイヤは、1回の攻撃操作において複数の目標画像を指定することが可能である。なお、第1の実施形態では、ゲーム装置1は、各目標画像32a〜eの移動が開始されてからの経過時間を計測し、経過時間が予め定められた制限時間を超えるまでの間、プレイヤによるタッチパネルへの入力を受け付ける。つまり、プレイヤは、目標画像32a〜eの移動が開始されてから制限時間が経過するまでに目標画像32を指定しなければならない。図9(a)では、プレイヤは4つの目標画像(目標画像32a、32c、32dおよび32e)を指定している。
図9(b)は、目標画像が複数である場合においてプレイヤが攻撃操作を行った後のゲーム画像の一例を示す図である。目標画像が複数である場合、ゲーム装置1は、プレイヤが指定した全ての目標画像についてダメージを算出する。最終的に敵キャラクタ31に与
えられる総ダメージは、各目標画像32毎に算出されたダメージの和として算出される。例えば図9(b)においては、目標画像32cが指定されたことによるダメージは“20”、目標画像dが指定されたことによるダメージは“5”、目標画像32eが指定されたことによるダメージは“10”と算出される。なお、目標画像32aはキャラクタ31の画像上で指定されていないので、目標画像32aによるダメージは“0”と計算される。その結果、敵キャラクタ31に与えられる総ダメージは、20+5+10+0=35となる。また、目標画像32bは制限時間内に指定されていないので、目標画像32bによるダメージは計算されない。
以上、図9に示したように、複数の目標画像を同時に表示させることによって、プレイヤが狙うべき目標画像を複数の目標画像からプレイヤに選択させることができる。プレイヤは、狙うべき位置(図4(a)の例では、敵キャラクタ31の目の位置)を通過する目標画像を複数の目標画像の中から見極めなければならないので、単一の目標画像が表示される場合よりもさらに操作スキルが要求される。従って、目標画像を複数にすることによってゲーム性をさらに向上することができる。
次に、ゲーム装置1によって実行されるゲーム処理の詳細を説明する。まず、ゲーム処理の際にWRAM22に記憶されるデータについて説明する。図10は、ゲーム装置1のWRAM22のメモリマップを示す図である。図10に示すように、ゲーム処理の際、WRAM22には、敵キャラクタデータ41が記憶される。敵キャラクタデータ41は、敵キャラクタと、当該敵キャラクタに関する情報とを対応付けたデータである。以下、図11を用いて敵キャラクタデータ41の詳細を説明する。
図11は、敵キャラクタデータ41の一例を示す図である。図11に示すように、敵キャラクタデータ41は、HPと、MPと、第1〜第3ダメージ領域と、目標画像情報とを各敵キャラクタ毎に対応付けたデータである。HPは、プレイヤキャラクタとの戦闘の開始時における敵キャラクタのHPである。戦闘が進むにつれて敵キャラクタデータ41のHPが減少していき、HPが0になると当該敵キャラクタは倒されたことになる。MPは、プレイヤキャラクタとの戦闘の開始時における敵キャラクタのMPである。
また、図11において、第1〜第3の各ダメージ領域は、第1LCD11の表示画面において敵キャラクタの画像が表示される領域を複数に分割した領域である。つまり、敵キャラクタの画像が表示される領域には、複数のダメージ領域(ここでは、3つのダメージ領域)が関連付けられて定義されている。例えば、敵キャラクタAの画像の領域は、敵キャラクタAの目が表示される第2ダメージ領域と、敵キャラクタAの盾が表示される第3ダメージ領域と、その他の部位(通常部位)が表示される第1ダメージ領域とに分けられる。なお、図11に示す敵キャラクタAは図3(b)に示す敵キャラクタ31である。また、ダメージ領域は、表示画面上の座標によって表現される。第1の実施形態では、プレイヤがタッチパネル13によって指定した位置がいずれのダメージ領域に含まれるかに応じて、敵キャラクタに与えられるダメージが変化する。ここでは、第1ダメージ領域は、敵キャラクタに対して基準ダメージ量と等しいダメージ量が与えられる領域である。第2ダメージ領域は、敵キャラクタに対して基準ダメージ量の2倍のダメージ量が与えられる領域である。第3ダメージ領域は、敵キャラクタに対して基準ダメージ量の半分のダメージ量が与えられる領域である。なお、基準ダメージ量とは、予め定められた所定の方法で算出されるプレイヤキャラクタの攻撃力によって決まるダメージ量である。
また、図11において、目標画像情報とは、敵キャラクタが画面に表示された際に表示される目標画像の大きさを示す情報である。ここでは、目標画像情報は、予め定められた基準値に対する倍率として表現される。図11では、敵キャラクタAが画面に表示される場合には、目標画像の大きさは基準値の大きさである。また、敵キャラクタBが画面に表
示される場合には、目標画像の大きさは基準値の2倍の大きさである。このように、第1の実施形態では、敵キャラクタの種類によって目標画像の大きさが異なるが、他の実施形態では、目標画像の速度や数や移動パターンが異なるようにしてもよい。
図10の説明に戻り、WRAM22には、目標画像データが記憶される。ここでは、表示画面に同時に表示される目標画像の数と同数の目標画像データがWRAM22に記憶される。目標画像データは、目標画像の表示または移動に関する情報を示すデータである。なお、図10では第1目標画像データ421および第2目標画像データ422のみを示す。第1目標画像データ421は、表示座標データ421aと、速度ベクトルデータ421bと、大きさデータ421cと、初期状態データ421dとを含む。表示座標データ421aとは、表示画面上における目標画像の位置(表示位置)を示すデータである。表示位置は、表示画面上における座標値によって表現される。速度ベクトルデータ421bは、目標画像の移動速度の大きさおよび移動方向を表すベクトルを示すデータである。大きさデータ421cは、目標画像の大きさを示すデータである。初期状態データ421dは、戦闘シーンの開始時における、目標画像の表示位置と、移動速度の大きさおよび移動方向と、目標画像の大きさとを示すデータである。なお、目標画像の色や模様などを示すデータも含まれる。また、図10では、第1目標画像データ421についてのみ詳細を示しているが、他の目標画像データも第1目標画像データ421と同様のデータを含んでいる。
また、WRAM22には、経過時間データ43、入力座標データ44、指示座標データ45、およびダメージデータ46が記憶される。経過時間データ43は、戦闘シーンにおいて目標画像の移動が開始されてから経過した時間を示すデータである。入力座標データ44は、プレイヤによるタッチパネル13への入力が行われた表示画面上の位置を示すデータである。指示座標データ45は、プレイヤによって目標画像が指示された表示画面上の位置を示すデータである。入力座標データ44および指示座標データ45は、表示画面上における座標値によって表現される。また、1回の攻撃操作の間にプレイヤによって指定された位置を示す座標は、全て指示座標データ45としてWRAM22に記憶される。すなわち、1回の攻撃操作において複数の目標画像が指定された場合、WRAM22には複数の座標を示す指示座標データ45が記憶される。なお、ダメージデータ46は、プレイヤによる攻撃操作によって敵キャラクタに与えられる総ダメージを計算する際に用いられる。なお、1回の攻撃操作において複数の目標画像が指定された結果、複数の目標画像によるダメージが敵キャラクタに与えられる場合、WRAM22には複数のダメージデータ46が記憶される。
また、WRAM22には、スキル情報データ47およびスキル情報テーブル48が記憶される。スキル情報データ47は、プレイヤの操作スキルを示す指標となる情報(スキル情報)を示すデータである。第1の実施形態では、スキル情報は、1回の攻撃操作においてプレイヤが指定することができた目標画像の数を示す。その他、スキル情報は、プレイヤによる入力が行われた位置と目標画像の表示位置との距離であってもよい。また、スキル情報は、制限時間内にタッチパネル13に対して入力が与えられた回数に対する、正しく指定された目標画像の個数の割合であってもよい。第1の実施形態では、ゲーム装置1は、目標画像の移動速度をスキル情報に基づいて変化させる。スキル情報テーブル48は、目標画像の移動速度を変化させる処理が行われる際に用いられる(後述する図14参照)。
なお、図10に示したデータの他、WRAM22には、カートリッジ17から読み込まれたゲームプログラムや、ゲーム画像(敵キャラクタの画像データや目標画像の画像データ等)のデータや、ゲーム処理において用いられる種々のデータ(例えば、プレイヤキャラクタのHPおよびMP)が記憶される。
次に、ゲーム装置1において実行されるゲーム処理の流れを図12〜図17を用いて説明する。図12は、ゲーム装置1において実行されるゲーム処理の流れを示すフローチャートである。ゲーム装置1の電源が投入されると、ゲーム装置1のCPUコア21は、図示しないブートROMに記憶されている起動プログラムを実行し、WRAM22等の各ユニットが初期化される。そして、カートリッジ17に格納されたゲームプログラムがWRAM22に読み込まれ、当該ゲームプログラムの実行が開始される。その結果、第1GPU24を介して第1LCD11にゲーム画像が表示されることによって、ゲームが開始される。図12に示すフローチャートは、ゲーム画像が戦闘シーンに切り替わった後におけるゲーム処理を示す。つまり、ゲーム開始後、ゲーム中にプレイヤキャラクタと敵キャラクタとの戦闘が開始されると、図12に示すフローチャートの処理が開始される。なお、本実施形態においては、戦闘シーン以外の状況におけるゲーム処理は本発明と直接関連しないので説明を省略する。
図12では、まず、ステップ10(図では「ステップ」を単に「S」と略す。)において、敵キャラクタの画像および当該敵キャラクタの特性パラメータが第1LCD11の表示画面に表示される(図3(b)参照。)。敵キャラクタの特性パラメータとしては、HPおよびMPが表示される。具体的には、CPUコア21は、表示される敵キャラクタのHPおよびMPをWRAM22の敵キャラクタデータ41から読み出し、読み出したHPおよびMPを特性パラメータとして第1LCD11の表示画面に表示する。
ステップ10の次に、ステップ11において、プレイヤキャラクタの攻撃ターンとなったか否かが判定される。なお、攻撃ターンは予め定められたルールに従って決定される。このルールはどのようなものであってもよいが、ここでは、プレイヤキャラクタの攻撃ターンと敵キャラクタの攻撃ターンとが交互になるように決められるものとする。ステップ11においてプレイヤキャラクタの攻撃ターンでないと判定された場合、ステップ12の処理が行われる。すなわち、ステップ12において、敵キャラクタによるプレイヤキャラクタに対する攻撃が行われる。具体的には、敵キャラクタによる攻撃に応じてプレイヤキャラクタの特性パラメータ(HPおよびMP)の値が変化する。すなわち、WRAM22に記憶されているプレイヤキャラクタの特性パラメータの値が更新される。ステップ12の処理の後、ステップ13の処理が行われる。
一方、ステップ11においてプレイヤキャラクタの攻撃ターンであると判定された場合、ステップ13〜21において、プレイヤキャラクタによる敵キャラクタに対する攻撃が行われる。まず、ステップ13において、目標画像の表示処理が行われる。目標画像の表示処理は、目標画像の初期表示位置、移動速度および移動方向ならびに目標画像の大きさを決定し、表示画面に目標画像を表示する処理である。以下、図13を用いて目標画像の表示処理を説明する。
図13は、図12のステップ13の詳細な処理の流れを示すフローチャートである。目標画像の表示処理では、まず、ステップ30において、目標画像の初期配置位置が決定される。具体的には、CPUコア21は、WRAM22に記憶されている目標画像データ(ここでは、第1目標画像データ421とする。)に含まれる初期状態データ421dを読み込む。そして、読み込んだ初期状態データ421dにより示される表示位置に初期配置位置を決定する。続くステップ31において、目標画像の移動速度が決定される。この移動速度は、上記初期状態データ421dにより示される速度と、前述のスキル情報データ47およびスキル情報テーブル48(図10参照。)とを用いて決定される。以下、図14を用いて目標画像の移動速度の決定方法を説明する。
ステップ31においては、CPUコア21は、まず、基準速度を決定する。基準速度は、上記初期状態データ421dにより示される移動速度の大きさに決定される。次に、基
準速度がスキル情報データ47およびスキル情報テーブル48に基づいて調整されることによって、目標画像の移動速度が決定される。図14は、WRAM22に記憶されるスキル情報テーブル48の一例を示す図である。スキル情報テーブル48とは、スキル情報と速度調整情報とを対応付けるテーブルである。ここで、スキル情報は、前回の攻撃操作においてプレイヤが指定することができた目標画像の数を示す。このスキル情報は、後述するステップ56においてWRAM22記憶されたスキル情報データ47により示される情報である。また、速度調整情報は、基準速度を調整すべき倍率を示す情報である。基準速度を調整する際、CPUコア21は、スキル情報テーブル48を参照することによって、スキル情報データ47により示される回数に対応する倍率を決定する。図14を例にとって説明すると、スキル情報データ47が4回を示す場合、倍率は2倍に決定される。すなわち、基準速度を2倍した値が目標画像の移動速度の大きさになる。
なお、第1の実施形態では、スキル情報テーブル48においてスキル情報と速度調整情報とを対応付けたが、他の実施形態では、スキル情報と目標画像の大きさを示す情報とを対応付けてもよい。これによって、プレイヤのスキルに応じて目標画像の大きさを変化させることができる。また、他の実施形態では、表示画面に同時に表示される目標画像の数や目標画像の移動パターンをスキル情報と対応付けてもよい。
図13の説明に戻り、ステップ32において、目標画像の移動方向が決定される。目標画像の移動方向は、上記初期状態データ421dにより示される移動方向に決定される。続くステップ33において、目標画像の大きさが決定される。目標画像の大きさは、WRAM22の敵キャラクタデータ41に含まれる目標画像情報(図11参照。)を参照することによって決定される。図11の例では、敵キャラクタBが表示画面に表示される場合には、目標画像の大きさは基準値の2倍の大きさに決定される。なお、基準値はゲーム装置1において予め定められている。続くステップ34において、ステップ30において決定された位置に目標画像が表示される。以上のステップ30〜34で、1つの目標画像が表示されたことになる。
ステップ34の次に、ステップ35において、規定数の目標画像を表示したか否かが判定される。第1の実施形態では、当該規定数はゲームプログラムによって予め定められている。なお、他の実施形態では、敵キャラクタの種類に応じて規定数を変化させてもよいし、プレイヤが直接的(直接数を指定するなど)又は間接的(取得しているアイテムなどに応じて)に規定数を設定することができるようにしてもよい。ステップ35において規定数の目標画像を表示したと判定された場合、CPUコア21は目標画像の表示処理を終了する。一方、ステップ35において規定数の目標画像を表示していないと判定された場合、ステップ30〜34の処理が繰り返される。ステップ30〜34の処理は、規定数の目標画像が表示されるまで繰り返される。
図12の説明に戻り、ステップ13の次にステップ14において、経過時間の計時が開始される。すなわち、ステップ14が行われた時点からの経過時間が経過時間データ43としてWRAM22に更新して記憶される。続くステップ15において、経過時間が制限時間を経過したか否かが判定される。この判定は、WRAM22の経過時間データ43により示される経過時間が予め定められた制限時間よりも大きくなったか否かによって行われる。ステップ15において経過時間が制限時間を経過したと判定された場合、後述するステップ21の処理が行われる。一方、ステップ15において経過時間が制限時間を経過していないと判定された場合、ステップ16の処理が行われる。すなわち、ステップ16において、目標画像の移動制御処理が行われる。
なお、他の実施形態では、ステップ15において、今回の攻撃操作においてプレイヤがタッチパネル13に対する入力を行った回数が所定の回数を超えたか否かを判定するよう
にしてもよい。ここで、今回の攻撃操作においてプレイヤがタッチパネル13に対する入力を行った回数は、後述するステップ18において入力が検出された回数を計測することによって得ることができる。また、所定の回数は、例えば目標画像の数と同数とすればよい。なお、上記のように制限時間を設ける場合には、表示画面上の同じ位置をプレイヤが何度も指定することによって、容易に所望の位置を指定することができるおそれがある。図5を例にとって説明すると、プレイヤは、目の位置を連打することによって、目の位置を通過する目標画像を見極めなくても容易に目の位置を指定することができる。従って、制限時間を設けても、プレイヤの操作スキルがゲーム展開に正確に反映されないおそれがある。これに対して、プレイヤによる入力回数に制限を設けることによって、ゲーム装置1は、プレイヤが所望の位置を連打することを制限することができる。これによって、プレイヤの操作スキルをゲーム展開に正確に反映させることができる。
以下、図15を用いて目標画像の移動制御処理の詳細を説明する。図15は、図12のステップ16の詳細な処理の流れを示すフローチャートである。目標画像の移動制御処理では、まず、ステップ40において、表示画面上の目標画像のうちの1つが選択される。なお、図15の説明においては、ステップ40において選択されている目標画像を選択目標画像と呼ぶ。続くステップ41において、選択目標画像は停止しているか否かが判定される。この判定は、WRAM22に記憶されている、選択目標画像に対応する目標画像データの速度ベクトルデータ421bを参照することによって行われる。すなわち、当該速度ベクトルデータ421bが0であれば、選択目標画像は停止していると判定され、当該速度ベクトルデータ421bが0でなければ、選択目標画像は停止していないと判定される。なお、選択目標画像が停止していることは、当該選択目標画像はプレイヤによってすでに指定された目標画像であることを意味する。つまり、ステップ41は、選択目標画像がプレイヤによってすでに指定されたか否かを判定する処理である。
ステップ41において選択目標画像は停止していると判定された場合、後述するステップ46の処理が行われる。一方、ステップ41において選択目標画像は停止していないと判定された場合、ステップ42の処理が行われる。すなわち、ステップ42において、選択目標画像の移動方向および移動速度に基づいて選択目標画像の移動後の座標が算出される。具体的には、CPUコア21は、選択目標画像に対応する目標画像データ42の速度ベクトルデータ421bにより示される方向および大きさに基づいて移動後の座標を算出する。算出された移動後の座標は、選択目標画像に対応する目標画像データの表示座標データ421aとしてWRAM22に記憶される。つまり、選択目標画像に対応する目標画像データの表示座標データ421aの内容は、ステップ42において算出された移動後の座標に更新される。
続くステップ43において、選択目標画像が表示画面の端に到達したか否かが判定される。なお、この判定は、ステップ42において算出された座標が表示画面内の領域を示すか否かによって行われる。ステップ43において選択目標画像が表示画面の端に到達していないと判定された場合、ステップ44の処理がスキップされ、ステップ45の処理が行われる。一方、選択目標画像が表示画面の端に到達したと判定された場合、ステップ44の処理が行われる。
ステップ44においては、選択目標画像の移動方向が変更される。具体的には、選択目標画像に対応する目標画像データ42の速度ベクトルデータ421bの値が更新される。第1の実施形態では、選択目標画像の移動方向の更新後の値は、表示画面の辺に対する選択目標画像の入射角と反射角とが等しくなるように設定される。なお、他の実施形態では当該反射角をランダムに決定してもよい。ステップ44の次に、ステップ45の処理が行われる。ステップ45においては、選択目標画像が移動後の座標に移動して表示される。第1の実施形態では、移動後の座標とは、ステップ42において算出された座標であると
する。なお、他の実施形態では、移動後の座標は、ステップ45における変更後の速度ベクトルデータ421bを用いて算出し直すことによって得られる座標であってもよい。
ステップ45の次に、ステップ46において、全ての目標画像が選択されたか否かが判定される。ステップ46において全ての目標画像が選択されていない場合、ステップ40〜46の処理が繰り返される。なお、ステップ40では、ステップ40〜46のループにおいてまだ選択されていない目標画像が選択される。ステップ46において全ての目標画像が選択されたと判定されると、CPUコア21は目標画像の移動制御処理を終了する。以上の移動制御処理によって、すでに停止している目標画像を除いて目標画像が移動されたこととなる。
再び図12の説明に戻り、ステップ16の次に、ステップ17において、プレイヤによるタッチパネル13への入力が検出される。具体的には、CPUコア21は、プレイヤによる入力があった位置を示す座標をタッチパネル13から取得する。取得された座標は、入力座標データ44としてWRAM22に記憶される。なお、ステップ17の時点でプレイヤによるタッチパネル13への入力がない場合、タッチパネル13からは当該入力がないことを示す情報が取得されるものとする。続くステップ18において、プレイヤによるタッチパネル13への入力が検出されたか否かが判定される。具体的には、ステップ17において取得された情報は入力がないことを示す情報であるか否かが判定される。ステップ18においてプレイヤによるタッチパネル13への入力が検出されていない場合、ステップ15の処理が行われる。一方、ステップ18において入力が検出された場合、ステップ19の目標画像の指定受付処理が行われる。以下、図16を用いて目標画像の指定受付処理の詳細を説明する。
図16は、図12のステップ19の詳細な処理の流れを示すフローチャートである。目標画像の指定受付処理では、まず、ステップ50において、表示画面上の目標画像のうちの1つが選択される。なお、図16の説明においては、ステップ50において選択されている目標画像を選択目標画像と呼ぶ。続くステップ51において、選択目標画像の表示座標が検出され、検出された表示座標と入力座標との距離が算出される。ここで、選択目標画像の表示座標は、選択目標画像に対応する目標画像データの表示座標データ421aにより示される。また、入力座標は、ステップ17においてWRAM22に記憶された入力座標データ44により示される。続くステップ52において、ステップ51で算出された距離は所定距離以下であるか否かが判定される。すなわち、入力座標から所定距離内の範囲に表示座標が位置するか否かが判定される。なお、当該所定距離はゲーム装置1において予め定められている。ステップ52の処理は、プレイヤが選択目標画像を正しく指定することができたか否かを判定するための処理である。
ステップ52において、ステップ51で算出された距離は所定距離よりも大きいと判定された場合、プレイヤは選択目標画像を指定していない、または選択目標画像を正しく指定することができなかったと判断される。従ってこの場合、ステップ53および54の処理がスキップされ、ステップ55の処理が行われる。一方、ステップ52において、ステップ51で算出された距離は所定距離以下であると判定された場合、ステップ53の処理が行われる。すなわち、ステップ53において、選択目標画像の表示座標が指示座標に決定される。具体的には、選択目標画像に対応する目標画像データ42に含まれる表示座標データ421aにより示される座標が、指示座標データ45としてWRAM22に記憶される。この指示座標は、プレイヤが敵キャラクタに対する攻撃を行うために指定した位置を示す座標であるので、以下では、指示座標により示される位置を攻撃ポイントと呼ぶ。ステップ53は、攻撃ポイントを決定する処理である。
なお、上記ステップ53では、選択目標画像の表示座標を指示座標としたが、入力座標
を指示座標としてもよい。また、指示座標は、選択目標画像の表示座標と入力座標とに基づいて算出されてもよい。例えば、選択目標画像の表示座標と入力座標との中点の座標が指示座標とされてもよい。
ステップ53の次に、ステップ54において、CPUコア21は選択目標画像の移動を停止する。すなわち、選択目標画像に対応する目標画像データ42に含まれる速度ベクトルデータ421bにより示されるベクトルを0にする。また、ステップ54において、選択目標画像の表示形態が変更される。ステップ54の次に、ステップ55の処理が行われる。
ステップ55においては、全ての目標画像が選択されたか否かが判定される。ステップ55において全ての目標画像が選択されていない場合、ステップ50〜54の処理が繰り返される。なお、ステップ50では、ステップ50〜55のループにおいてまだ選択されていない目標画像が選択される。ステップ55において全ての目標画像が選択されたと判定されると、ステップ56の処理が行われる。すなわち、ステップ56においてスキル情報が記憶される。具体的には、今回の攻撃操作においてプレイヤが指定することができた目標画像の数がスキル情報としてWRAM22に記憶される。なお、この数は、停止している目標画像の数、すなわち、速度ベクトルデータ421bが0である目標画像データ42の数である。ステップ56が完了すると、CPUコア21は、目標画像の指定受付処理を終了する。
再び図12の説明に戻り、ステップ19の次にステップ20において、表示画面上の全ての目標画像が指定されたか否かが判定される。この判定は、WRAM22の画像データに含まれる速度ベクトルデータ421bが全て0であるか否かによって行われる。すなわち、当該速度ベクトルデータ421bが全て0である場合、表示画面上の全ての目標画像が指定されたと判定され、ステップ21の処理が行われる。一方、0でない値を示す速度ベクトルデータ421bがある場合、表示画面上の目標画像にはまだ指定されていないものがあると判定され、ステップ15〜20の処理が繰り返される。
ステップ21においては、ダメージ計算処理が行われる。ダメージ計算処理は、敵キャラクタに与えられるダメージ量を計算する処理である。図17は、図12のステップ21の詳細な処理の流れを示すフローチャートである。図17に示すダメージ計算処理では、まず、ステップ60において、ステップ53で決定された攻撃ポイントに対応するダメージ領域が決定される。具体的には、敵キャラクタデータ41により示される第1〜第3のダメージ領域のうち、ステップ53において決定された指示座標の位置を含むダメージ領域が決定される。なお、当該指示座標の位置を含むダメージ領域がない場合、すなわち、敵キャラクタの画像データが表示される領域外の位置を指示座標が示す場合、ステップ60においてダメージ領域は決定されない。
ステップ60の次にステップ61において、ステップ60で決定したダメージ領域とプレイヤキャラクタの攻撃力とに基づいてダメージ量が算出される。具体的には、ステップ60で決定したダメージ領域が第1ダメージ領域である場合、プレイヤキャラクタの攻撃力がそのままダメージ量となる。また、ステップ60で決定したダメージ領域が第2ダメージ領域である場合、プレイヤキャラクタの攻撃力を2倍した値がダメージ量となる。ステップ60で決定したダメージ領域が第3ダメージ領域である場合、プレイヤキャラクタの攻撃力を0.5倍した値がダメージ量となる。なお、プレイヤキャラクタの攻撃力は、プレイヤキャラクタの能力値やプレイヤキャラクタが持っている武器等に基づいて所定の方法で算出されるものとする。また、ステップ60においてダメージ領域が決定されなかった場合、ダメージ量は0とされる。ステップ61において算出されたダメージ量は、WRAM22に記憶されているダメージデータ46としてWRAM22に記憶される。続く
ステップ62において、直前のステップ60および61における攻撃ポイントにエフェクト画像およびダメージ画像が表示される(図4(b)参照。)。これらのエフェクト画像およびダメージ画像は、直前のステップ61で算出されたダメージ量に応じた画像が表示される。
ステップ63においては、全ての攻撃ポイントについてダメージ量が算出されたか否かが判定される。ダメージ量がまだ算出されていない攻撃ポイントがあると判定される場合、ステップ60および61の処理が繰り返される。一方、全ての攻撃ポイントについてダメージ量が算出されたと判定される場合、ステップ64の処理が行われる。すなわち、ステップ64では、全ての攻撃ポイントにおけるダメージを加算することによって総ダメージが算出される。具体的には、CPUコア21は、ステップ60および61において記憶されたダメージデータ46により示されるダメージ量を全て加算することによって総ダメージを算出する。なお、総ダメージが算出されると、その時点でWRAM22に記憶されているダメージデータ46は消去される。
続くステップ65において、ステップ64で算出された総ダメージが0であるか否かが判定される。総ダメージが0であると判定された場合、ステップ66の処理が行われる。すなわち、ステップ66において、攻撃が失敗したことを表すエフェクト表示が行われ、ダメージ計算処理が終了する。一方、ステップ65において総ダメージが0でないと判定された場合、ステップ67の処理が行われる。すなわち、ステップ67において、攻撃エフェクト画像およびダメージ画像が表示される(図4(b)参照。)。このダメージ画像により示されるダメージ量は、ステップ65で算出された総ダメージ量である。さらに、ステップ68において、ステップ65で算出された総ダメージ量に基づいて敵キャラクタの特性パラメータが更新される。具体的には、CPUコア21は、表示画面上の敵キャラクタを示す敵キャラクタデータ41のHPから総ダメージ量を減算する。これに応じて、第1LCD11に表示されている敵キャラクタのHPの値が減算後の値に変更される。
ステップ68の次に、ステップ69において、敵キャラクタのHPが0になったか否かが判定される。すなわち、直前のステップ68における減算後のHPが0になったか否かが判定される。敵キャラクタのHPが0になっていない場合、ダメージ計算処理が終了する。一方、敵キャラクタのHPが0になった場合、ステップ70の処理が行われる。すなわち、ステップ70において、敵キャラクタを倒したことを表すエフェクト画像が表示される。ステップ70が完了すると、CPUコア21は、ダメージ計算処理を終了する。
なお、第1の実施形態では、ステップ19によって攻撃ポイントが全て決定された後でステップ21によってダメージ量の算出や攻撃エフェクト画像の表示が行われた。ここで、他の実施形態においては、ゲーム装置1は、攻撃ポイントが1つ指定される度にダメージ量を計算し、攻撃ポイントが1つ指定される度に当該攻撃ポイントにおける攻撃エフェクト画像を表示するようにしてもよい。
再び図12の説明に戻り、ステップ21の後、ステップ22の処理が行われる。ステップ22においては、戦闘終了か否かが判定される。この判定は、例えば、プレイヤキャラクタのHPまたは全ての敵キャラクタのHPが0になったか否かによって行われる。すなわち、プレイヤキャラクタのHPまたは全ての敵キャラクタのHPが0になった場合、戦闘終了と判定され、図11に示すゲーム処理が終了する。一方、プレイヤキャラクタのHPが0になっておらず、かついずれか1匹の敵キャラクタのHPが0になっていなければ、戦闘終了でないと判定され、ステップ11の処理に戻る。以降、戦闘終了と判定されるまで、ステップ11〜22の処理が繰り返される。以上で、第1の実施形態におけるゲーム処理の説明を終了する。
以上のように、第1の実施形態によれば、ゲーム装置1は、表示画面上を動き回る目標画像をプレイヤに指定させることによって敵キャラクタへの攻撃操作をプレイヤに行わせる。そのため、プレイヤは、目標画像を指定するタイミングと指定する位置との両方に注意して入力操作を行わなければならない。つまり、移動する画像を観察しながら最適な位置でタイミングよく目標画像を指示するという操作スキルがゲームに反映されることとなる。これによって、単純にタイミングのみに注意して遊ぶ従来のゲームに比べてゲーム性の高いゲームを提供することができる。なお、目標画像を複数表示することや、プレイヤによる攻撃操作に制限時間を設けること等によって、プレイヤの操作スキルをより反映させることができる。
なお、以上に説明した第1の実施形態においては、以下に示す変形例を用いてもよい。図18は、第1の実施形態の変形例におけるゲーム画像の一例を示す図である。図18においては、敵キャラクタの画像の領域を通過する目標画像32fの移動速度は、敵キャラクタの画像以外の領域を通過する目標画像32gの移動速度よりも速い。このように、敵キャラクタの画像の領域を目標画像が通過するとき、目標画像の移動速度を速くするようにしてもよい。以下、図19および図20を用いて具体的な処理を説明する。
図19は、図18に示す変形例において用いられるテーブルを示す図である。図19に示すテーブルは、ダメージ領域と当該ダメージ領域を通過するときの目標画像の移動速度とを対応付けたテーブルである。図19においては、第1ダメージ領域を通過するときの目標画像の移動速度は基準速度に等しい速度であり、第2ダメージ領域を通過するときの目標画像の移動速度は基準速度の2倍の速度であり、第3ダメージ領域を通過するときの目標画像の移動速度は基準速度の半分の速度である。なお、基準速度はゲーム装置1において予め定められているとする。図19においては、攻撃効果が大きい(与えるダメージ量が大きい)ダメージ領域を通過するときほど移動速度が速くなるようにテーブルが設定されている。これによって、プレイヤの操作スキルをゲームにより反映することができる。
図20は、図18に示す変形例において行われる目標画像の移動制御処理を示すフローチャートである。この変形例においては、図15に示す処理に代えて図20に示す処理が行われる。なお、図20において、図15と同じ処理には同じステップ番号を付し、説明を省略する。
図20に示す処理では、ステップ41の判定が否定であった場合、ステップ80の処理が行われる。すなわち、ステップ80において、選択目標画像が含まれる領域が検出される。ここで、検出される可能性のある領域は、第1〜第3のダメージ領域および敵キャラクタの画像以外の領域のいずれかである。続くステップ81において、ステップ80で検出した領域に基づいて選択目標画像の移動速度が調整される。具体的には、CPUコア21は、図19に示すテーブルを用いて移動速度を算出する。なお、目標画像が敵キャラクタの画像以外の領域に含まれる場合、移動速度の調整は行われない。以上の処理によって、目標画像がある領域に応じて移動速度を変化させることができる。なお、この変形例では、ダメージ領域に応じて目標画像の移動速度を変化させたが、敵キャラクタの画像の領域では移動速度を均一にしてもよい。
また、他の変形例として、敵キャラクタの画像の領域を目標画像が通過するとき、目標画像を小さくするようにしてもよい。具体的には、図19に示すテーブルにおいて、移動速度に代えて目標画像の大きさを定義しておき、図20に示すステップ81において、ステップ80で検出した領域に基づいて選択目標画像の大きさを調整してもよい。図21は、第1の実施形態の変形例におけるゲーム画像の他の一例を示す図である。図21においては、敵キャラクタの画像の領域を通過する目標画像32jは、敵キャラクタの画像以外
の領域を通過する目標画像32hおよび32iよりも小さく表示される。このように、攻撃効果がある(ダメージを与えることができる)領域を通過するときには目標画像を小さくすることによって、プレイヤの操作スキルをゲームにより反映することができる。なお、図21において、ダメージ領域に応じて目標画像の大きさを変化させるようにしてもよい。
さらに、他の変形例においては、複数の目標画像が表示される場合、目標画像を指定することによって敵キャラクタに与えられるダメージや、目標画像の大きさ等を目標画像毎に異なるようにしてもよい。この変形例において用いられるテーブルの一例を図22に示す。図22に示すテーブルは、各目標画像に対して基準ダメージと目標画像の大きさとを対応付けたテーブルである。ゲーム処理においては、このテーブルを参照することによって目標画像の大きさが決定される。また、このテーブルを参照することによって目標画像によって与えられるダメージ量が算出される。具体的には、図13のステップ23において、CPUコア21は、図22に示すテーブルに基づいて目標画像の大きさを決定する。また、図17のステップ61において、図22に示すテーブルを用いてダメージ量を算出する。例えば、当該テーブルにおける基準ダメージを上記プレイヤキャラクタの攻撃力としてダメージ量を算出してもよい。
また、他の実施形態においては、第1LCD11に表示される敵キャラクタの画像を移動させるようにしてもよい。これによって、プレイヤが敵キャラクタを指定する操作の難易度を上げることができる。なお、敵キャラクタの画像を移動させる処理は、例えば図11のステップ16の次に行う。敵キャラクタの画像を移動させるアルゴリズムは、目標画像の移動と同様、ゲーム装置1において予め設定された規則に従って移動してもよいし、ランダムに移動してもよい。また、敵キャラクタの画像を移動させる他、敵キャラクタの画像の大きさを変化させるようにしてもよい。
上記の他にも、第1の実施形態の種々のバリエーションとして以下の例が考えられる。すなわち、目標画像の大きさ、数、および移動速度は、ゲームの難易度や、プレイヤキャラクタが装備した武器(アイテム)や、プレイヤキャラクタのレベルや、敵キャラクタの強さ等に応じて変化させてもよい。例えば、ゲームに登場するあるアイテムや魔法を使うと、敵キャラクタの弱点部分(第1の実施形態で言えば第2ダメージ領域)が大きく表示されるようにしてもよい。これによって、プレイヤが弱点部分を指定しやすくなる。また、敵キャラクタが魔法を使うと敵キャラクタの防御の高い部分(第1の実施形態で言えば第3ダメージ領域)が大きく表示され、その結果プレイヤはダメージを与えにくくなるようにしてもよい。
また、第1の実施形態においては、プレイヤキャラクタが敵キャラクタにダメージを与えるための攻撃処理を行う場合を例として説明したが、その他のゲーム処理においても本発明を適用することができる。例えば、ゲーム装置1は、怪我をしたプレイヤキャラクタの画像を表示してもよい。そして、怪我をしている部分でプレイヤが目標画像を指定すると、ゲーム装置1は、プレイヤキャラクタの怪我が回復する処理を行う。また、プレイヤキャラクタに対する攻撃は、HPを減少させる攻撃に限らない。例えば、特定の弱点部分を指定すると、敵キャラクタに特殊な効果(ダメージ)を与えることができるようにしてもよい。具体的には、敵キャラクタの目を攻撃すると(敵キャラクタの目の位置で目標画像を指定すると)、以後の敵キャラクタによるプレイヤキャラクタへの攻撃が当たりにくくなるようにしてもよい。
(第2の実施形態)
次に、本発明に係る第2の実施形態を説明する。第2の実施形態においては、上記第1の実施形態とは異なるゲームに本発明を適用する場合を説明する。なお、ゲーム装置1の
外観および内部構成は図1および図2と同様であるので説明を省略する。
まず、ゲーム装置1において行われるゲームの概要を図23および図24を用いて説明する。図23および図24は、第1LCD11の表示画面に表示されるゲーム画像の一例を示す図である。図23(a)に示すように、第2の実施形態では、ゲーム装置1は、複数の目標画像が移動する様子を示すゲーム画像を第1LCD11の表示画面に表示する。また、表示画面の上部には「正三角形になるように止めろ!!」という指示が表示されている。プレイヤは、この指示に従って目標画像を指定する。すなわち、目標画像を指定した位置が正三角形になるようにタッチパネル13に対して入力を行う。ここで、ゲーム装置1からプレイヤに対して指示される図形(ここでは正三角形)を参照図形と呼ぶ。図23(b)は、プレイヤによる入力が指示通りに行われた場合のゲーム画像を示す図である。この場合、ゲーム装置1は、ゲームが成功したことを示すために「OK」と表示画面に表示する(図23(d))。一方、図23(c)は、プレイヤによる入力が指示通りに行われなかった場合のゲーム画像を示す図である。この場合、ゲーム装置1は、ゲームが失敗したことを示すために「NG」と表示画面に表示する(図23(e))。
図24は、図23とは異なる指示がプレイヤに与えられた場合のゲーム画像を示す図である。図24では、十字の形状をしたガイド35が目標画像の他に表示される。また、表示画面の上部には「ガイドに沿って止めろ!!」という指示が表示されている。つまり、図24ではガイド35が参照図形である。プレイヤは、この指示に従い、目標画像をガイド35上で指定するようにタッチパネル13に対して入力を行う(図24(b))。そして、プレイヤによる入力が指示通りに行われると、ゲーム装置1は、ゲームが成功したことを示すために「OK」と表示画面に表示する(図24(c))。
次に、第2の実施形態に係るゲーム装置において実行されるゲーム処理を説明する。図25は、第2の実施形態に係るゲーム装置において実行されるゲーム処理の流れを示すフローチャートである。ゲーム装置の電源が投入されてからゲームが開始されるまでの処理は、第1の実施形態と同様である。図25に示すフローチャートは、ゲームが開始されてからのゲーム処理の流れを示すものである。
ゲーム処理が開始されると、まず、目標画像を表示および移動させる処理や、プレイヤによるタッチパネル13への入力を検出する処理等が行われる。具体的には、図12に示すステップ13〜20の処理が行われる。これらの処理は第1の実施形態における処理と同様である。その後、ステップ90以降の処理が行われる。
ステップ90において、プレイヤの入力によって得られた複数の指示座標によって形成される図形(入力図形)の図形的特徴が算出される。図形的特徴とは、入力図形の特徴を示す指標であり、例えば、入力図形の頂点の数(すなわち、指示座標の数)である。つまり、ステップ90において、入力図形の頂点の数が算出される。これによって、ゲーム装置1は入力図形が何角形であるのかを判断することができる。
ステップ91において、ステップ90で算出した図形的特徴と上記参照図形の図形的特徴とが比較される。なお、参照図形を示すデータはゲーム装置1において予め用意されている。具体的には、ゲーム装置1のWRAM22には参照図形の頂点の座標が記憶されている。ステップ91では、CPUコア21は、指示座標の数と参照図形の頂点の数とを比較する。続くステップ92では、ステップ90で算出した図形的特徴と参照図形の図形的特徴とが一致するか否かが判定される。すなわち、指示座標の数と参照図形の頂点の数とが等しいか否かが判定される。この判定によって、入力図形と参照図形とが同じ種類の図形であるか否かを判定することができる。図23の例では、入力図形が三角形であるか否かが判定される。
ステップ92において図形的特徴が一致しないと判定された場合、ステップ95の処理が行われる。すなわち、ステップ95において、CPUコア21は、ゲームが失敗したことを示すために表示画面に「NG」と表示する。一方、ステップ92において図形的特徴が一致すると判定された場合、ステップ93の処理が行われる。すなわち、ステップ93において、参照図形の周囲の所定範囲内に各指示座標が含まれるか否かが判定される。ここでは、所定範囲内とは、参照図形の各辺から所定距離以内とする。すなわち、ステップ93においては、参照図形の各辺から所定距離以内に各指示座標があるか否かが判定される。従って、全ての指示座標が参照図形の各辺から所定距離以内に位置する場合、ステップ93の判定は肯定となる。逆に、参照図形の各辺から所定距離以内に位置しない指示座標がある場合、ステップ93の判定は否定となる。
以上のステップ91〜83によって、プレイヤが指示通りに入力を行ったか否か、すなわち、入力図形が参照図形と一致するか否かが判断される。なお、この判断の方法はどのようなものであってもよい。例えば、図23のように正三角形であるか否かを判定する場合には、各指示座標の間の距離がほぼ等しくなるか否かを判定するようにしてもよい。
ステップ93の判定が肯定であった場合、ステップ94の処理が行われる。すなわち、ステップ94において、CPUコア21は、ゲームが成功したことを示すために表示画面に「OK」と表示する。一方、ステップ93の判定が否定であった場合、ステップ95の処理が行われる。ステップ94または85の処理の後、CPUコア21は、ゲーム処理を終了する。
以上のように、第2の実施形態におけるゲームは、指定した目標画像が所定の位置関係となるように、表示画面上を移動する目標画像を指定して遊ぶゲームである。このゲームにおいても第1の実施形態と同様、プレイヤは、目標画像を指定するタイミングと指定する位置との両方に注意して入力操作を行わなければならない。従って、ゲーム装置は、単純にタイミングだけに注意して遊ぶ従来のゲームに比べて操作スキルが要求されるゲームを提供することができるので、ゲーム性の高いゲームを提供することができる。
なお、第1の実施形態においても第2の実施形態のように、プレイヤが指定した複数の目標画像の間の位置関係をゲーム処理に反映させるようにしてもよい。すなわち、ゲーム装置1は、複数の指示座標の位置関係に応じて敵キャラクタの特性パラメータを変化させてもよい。例えば、プレイヤが3つの目標画像を指定した各位置が正三角形の頂点の位置になる場合、通常よりも大きなダメージを敵キャラクタに与えるようにしてもよい。
ところで、上述の各実施例では、2画面分の液晶表示部の一例として、物理的に分離された2つのLCD11および12を上下に配置した場合(上下2画面の場合)を説明したが、図26に示すように、上部ハウジング18bを除いて、2画面分のLCD11および12を左右に配置した状態で収納できるように、1つのハウジング18cを横長に形成してもよい。その場合、右利きのユーザーが多いことを考慮して、好ましくは、タッチパネル13の装着された第1LCD11が右側に配置され、第2LCD12が左側に配置される構成となる。ただし、左利き用の携帯ゲーム装置を作る場合は、その逆の配置となる。
その他の配置例として、物理的に分離された2つのLCD11および12を上下に配置する構成に代えて、図27に示すように、横幅が同じで縦の長さが2倍のサイズからなる縦長サイズの1つのLCD11a(すなわち、物理的には1つで、表示サイズが縦に2画面あるLCD)を用いて、縦方向に2画面分の液晶表示部を配置することによって、2画面分のゲーム画像を上下に表示(すなわち上下の境界部分無しに隣接して表示)するように構成してもよい。また、縦幅が同じで横の長さが2倍のサイズからなる1つの横長サイ
ズのLCD11bを用いて、図28に示すように、横方向に2画面分のマップ画像を左右に表示(すなわち左右の境界部分無しに隣接して表示)するように構成してもよい。すなわち、図27および図28の例は、物理的に1つの画面を2つに分割して使用することにより複数のゲーム画像を表示するものである。