JP2010051736A - ゲーム装置及びコンピュータプログラム - Google Patents

Abstract

【課題】ゲーム装置の物理的なボタンに割り当てられる動作を視覚的にゲーム画面上で表示すると共に、ゲームにおける対戦の進行状況に応じてボタンに割り当てる動作を変更させて、ゲーム進行を行うゲーム装置及びゲームプログラムを提供する。
【解決手段】ゲーム画面上のメインキャラクタの周囲にコマンドアイコンを複数配置し、該コマンドアイコンの配置関係は、ゲーム装置の操作ボタンの物理的配置に対応する。コマンドアイコンの種類は、ゲーム画面内のメインキャラクタ間距離や、メインキャラクタの位置に応じて変更される。
【選択図】図１

Description

本発明は、ゲーム装置及びコンピュータプログラムに関する。

２人の対戦者が、それぞれのキャラクタをゲーム画面上で対戦させて勝敗を競い合うゲーム装置が提案されている（特許文献１を参照。）。かかるゲーム装置では、複数のボタンの操作の組合せにて、キャラクタの動作（主に攻撃動作）のバリエーションを持たせるようにしている。
特開２００３−２９９８７４号公報

これに対して、ボタンと動作とが直接連動し、かつ、ボタンに割り当てられる動作がゲームにおける対戦の進行状況に応じて変化するようなゲームは提案されていなかった。

本願はこのような課題を鑑み、ゲーム装置の物理的なボタンに割り当てられる動作を視覚的にゲーム画面上で表示すると共に、ゲームにおける対戦の進行状況に応じてボタンに割り当てる動作を変更させて、ゲーム進行を行うゲーム装置及びゲームプログラムを提供することを目的とする。

上記課題を解決するための一つの側面に対応する本発明は、
ゲーム画面を表示する表示手段と、
メインゲームプログラムを記憶する記憶手段と、
遊戯者からの操作入力を受け付ける複数の操作ボタンを有する操作手段と、
前記メインゲームプログラムを実行して、第１のメインキャラクタを前記操作入力に応じて第２のメインキャラクタと第１のゲーム空間内で対戦させる対戦ゲームの第１のゲーム画面を前記表示手段に表示させるゲーム実行手段とを備えるゲーム装置であって、
前記ゲーム実行手段は、
前記複数の操作ボタンのそれぞれに割り当てられた前記第１のメインキャラクタを操作するためのコマンドを表す第１のコマンド識別情報を前記第１のメインキャラクタと関連づけ、かつ、前記第２のメインキャラクタを操作するために割り当てられたコマンドを表す第２のコマンド識別情報を前記第２のメインキャラクタと関連づけて、前記第１のゲーム画面上で表示させ、
前記第１のゲーム空間内における前記第１のメインキャラクタと第２のメインキャラクタとの間の距離に応じて、前記第１のコマンド識別情報及び前記第２のコマンド識別情報の内容を変更することを特徴とする。

本願によれば、ゲーム装置の物理的なボタンに割り当てられる動作を視覚的にゲーム画面上で表示すると共に、ゲームにおける対戦の進行状況に応じてボタンに割り当てる動作を変更させて、ゲーム進行を行うゲーム装置及びゲームプログラムを提供することができる。

以下添付図面を参照して、本発明の好適な実施形態について詳細に説明する。

［第１の実施形態］
本実施形態における、ゲーム装置１００の基本構成を図１に示す。ＣＰＵ１０１は、ＲＡＭ（ランダムアクセスメモリ）１０２やＲＯＭ（リードオンリメモリ）１０５に格納されたプログラムやデータ等を用いてゲーム装置１００全体の制御を行うと共に、本実施形態に対応するゲームの進行を制御する。ＲＡＭ１０２は、内部記憶装置１１０内に格納されたゲーム用プログラム１１１やゲーム用データ１１２を読み込むエリアを備えると共に、ＣＰＵ１０１が各種の処理を実行する際に用いるワークエリアも備える。なお、本実施形態においては、メインのゲームを３種類の選択対象の中から選択された選択対象の内容に基づいて勝敗判定を行なうゲームとして説明する。

操作部１０３は、プレーヤ（遊戯者）からの入力を受付ける入力手段として機能する。操作部１０３は、複数のプレーヤからの入力をそれぞれ受け付けることが可能に構成されていてもよい。例えば、二人のプレーヤからの入力をそれぞれ受け付ける場合には、各プレーヤ毎の入力を受け付けるためのボタン群が各々用意される。

また、操作部１０３には、プレーヤ毎に３種類の選択対象に対応した選択ボタンが配備されていることが望ましい。本実施形態では、このような各選択ボタンをボタン１０３ａ、ボタン１０３ｂ、ボタン１０３ｃとそれぞれ呼ぶことにする。なお、これらのボタンは専用のボタンとして配置されてもよいし、本ゲームを実行する場合に、操作部１０３に含まれる複数の操作ボタンに各選択対象をそれぞれ割り当てたものでもよい。

通信Ｉ／Ｆ（インタフェース）１０４は、他のゲーム装置とケーブルを介して接続したり、インターネットやＬＡＮ（ローカルエリアネットワーク）に接続するためのＩ／Ｆとして機能する。ＲＯＭ１０５は、本ゲーム装置１００全体の制御を行うプログラム（例えば本ゲーム装置１００のブートプログラムや、メインゲームプログラム、サブゲームプログラム）やデータ（例えば本ゲーム装置１００の設定データ、ゲームに使用されるキャラクタを表すキャラクタデータ）等を格納する。すなわち、ＲＯＭ１０５は、キャラクタ記憶手段、プログラム記憶手段として機能している。また、表示部１０６は画面情報を表示する表示手段として、ＣＲＴや液晶画面により構成されており、ゲームに関する画面（ゲーム中の画面やゲームにおける各種の設定を行う画面）を表示する。

サウンド処理部１０７は、ゲーム用データ１１２に含まれるサウンドデータに基づいてＢＧＭや効果音を生成し、スピーカ１０８に生成したＢＧＭや効果音などを出力する。

内部記憶装置１１０は、例えばハードディスクやフラッシュメモリなど、書込と読出とが可能な記憶装置により構成されており、上述のゲーム用プログラム１１１及びゲーム用データ１１２を格納する。ここに格納されているデータは必要に応じてＲＡＭ１０２に読み出される。ゲーム用プログラム１１１はゲーム全体の制御を行うプログラムであり、少なくともメインゲームプログラムとサブゲームプログラムを含んでいる。

ゲーム用データ１１２は、ゲーム画面を構成する各オブジェクト（キャラクタ、文字、背景画面等）の画像を生成するためのデータや、上述のサウンドデータ、種々のパラメータ等を含む。すなわち、ゲームに使用されるキャラクタを現すキャラクタデータを含んでいる。プレーヤがネットワークにゲーム装置１００を接続してオンラインゲームを実行しようとする場合には、当該ゲーム用プログラム１１１やゲーム用データ１１２には、ゲームプログラムを提供するネットワーク上の所定のサーバーからダウンロードされたゲームプログラムやデータなども含まれる。

カードリーダー１１３は、例えばプレーヤが有するカードに記録された情報を読み取るためのカード情報の読取手段である。カードリーダー１１３は、複数のプレーヤから、カード情報をそれぞれ取得可能に構成されていてもよい。例えば、二人のプレーヤからカード情報をそれぞれ取得する場合において、一つのカードリーダーが用意される場合には、一方のプレーヤからカード情報を読み取った後に他方のプレーヤからカード情報を読み取ることとなり、またプレーヤ毎にカードリーダーが用意される場合には、各々のカードリーダーにて各々のプレーヤからカード情報を読み取ることとなる。

カード１１４は、ゲームを実行する際に利用可能な情報が記録されたカードである。１０９は上述の各部を繋ぐバスである。上述の構成を備える本実施形態におけるゲーム装置１００において実行される処理について以下に説明する。

図２は、本発明の実施形態に対応する処理のフローチャートである。図２に示すフローチャートに対応する処理は、ＲＡＭ１０２に読み出された内部記憶装置１１０に記憶されているゲーム用プログラム１１１をＣＰＵ１０１が実行することにより実現される。ゲーム用プログラム１１１は、メインゲームプログラム、サブゲームプログラムを含んでいるので、ＣＰＵ１０１はメインゲーム実行手段、サブゲーム実行手段として機能する。

図２において、ステップＳ２０１では、プレーヤが提示したカード１１４に記録された情報を、カードリーダー１１３を用いて読み込む。ステップＳ２０１における読み込み処理について、図４を参照してより詳細に後述する。ステップＳ２０２では、カード１１４に記録された情報に基づいて、画面表示するマップ画面を選択する。このマップ画面の情報は、ゲーム用データ１１２に複数含まれており、カード１１４から読み取った情報に従って、マップを選択することができる。

例えば、１０種類のマップ画面がゲーム用データ１１２に登録されており、マップを選択するための識別情報が１０通り設定され、カード１１４にはそのうちのいずれかが記録されているとする。この場合、ステップＳ２０１で読み取られたカード情報には１０通りの識別情報のうちの１つが含まれているので、ステップＳ２０２では、該識別情報に対応するマップ画面が選択される。

次に、ステップＳ２０３では、ステップＳ２０２で選択されたマップ画面を表示部１０６に表示する。ここで表示されるマップ画面の一例を図３に示す。図３において画面３００には、プレーヤが操作するキャラクタの画像３０１が表示される。また、マップは、各イベントポイントを示すアイコン３０２が複数配置され、それぞれのイベントポイント３０２が接続されて構成される。各イベントポイント３０２を接続するルート上には、グーアイコン３０３、チョキアイコン３０４及びパーアイコン３０５のいずれかが表示されている。

プレーヤは、操作部１０３上で、表示されたアイコンに従ったボタンを操作して、キャラクタ３０１を所望のイベントポイントに移動させることができる。例えば、キャラクタ３０１をすぐ上のイベントポイントに移動させたい場合には、パーアイコン３０５に対応するパーボタン１０３ｃを操作部１０３において操作すればよい。同様に、左下に移動したい場合はグーボタン１０３ａ、右下に移動したい場合にはチョキボタン１０３ｂをそれぞれ操作すればよい。

図２に戻って、続くステップＳ２０４では、上記のような操作部１０３を利用した移動操作を受けつける。さらに、ステップＳ２０５では、キャラクタ３０１がいずれかのイベントポイント３０２上に位置する状態で、操作部１０３に含まれる決定ボタンが操作され、イベントポイント３０２が決定されたか否かが判定される。

もし、イベントポイント３０２が決定された場合には（ステップＳ２０５において「ＹＥＳ」）、ステップＳ２０６に移行して当該イベントポイント３０２におけるイベント処理を実行する。ステップＳ２０７では、イベント処理が終了したか否かを判定する。もし、ステップＳ２０６におけるイベント処理が終了した場合には（ステップＳ２０７において「ＹＥＳ」）、ステップＳ２０３に戻って、マップ画面を再度表示部１０６に表示する。一方、イベント処理が終了しない場合には（ステップＳ２０７において「ＮＯ」）、ステップＳ２０６におけるイベント処理を継続する。なお、本実施形態では、図２に示すフローチャートに従って処理を説明しているが、これに限定されるものではなく、ステップＳ２０２からステップＳ２０５の処理を経ずにＳ２０６におけるイベント処理を実行してもよい。

次に、図４を参照して、ステップＳ２０１におけるカード情報の読込処理の詳細を説明する。

まず、ステップＳ４０１では、メインカード情報を取得したか否かを判定する。本実施形態における「メインカード」とは、１枚目にカードリーダー１１３で読み取ったカードをいう。各カード１１４には、カードを識別するためのＩＤ情報が記録されている。ステップＳ４０１では、このＩＤ情報をメインカード情報として取得する。

ステップＳ４０１でＩＤ情報を取得すると、続くステップＳ４０２において、ＩＤ情報（メインカード情報）に対応するキャラクタデータを、メインキャラクタ用のデータとして、ゲーム用データ１１２に含まれるキャラクタテーブルから抽出し、ＲＡＭ１０２に格納する。すなわち、ＣＰＵ１０１がゲーム用プログラム１１１を実行することにより、キャラクタ記憶手段よりメインキャラクタとしてキャラクタデータを読み出すメインキャラクタ読出手段が実現されており、ＲＡＭ１０２は、メインキャラクタ読出手段により読み出されたキャラクタデータをメインキャラクタデータとして記憶するメインキャラクタ記憶手段として機能している。キャラクタテーブルの一例は、図５に示す通りである。

図５において、キャラクタテーブル５００には、カード１１４に記録され、カードリーダー１１３で読み取られるＩＤ情報５０１、ＩＤ情報に割り当てられたキャラクタのキャラクタ名５０２、ゲームを進行する上で必要となるキャラクタの基本的なパラメータである攻撃力５０３、防御力５０４、体力５０５、キャラクタ画像５０６が登録される。なお、ここで示したテーブルのエントリはあくまで一例であって、これに限定されるものではない。また、図５では、省略しているが、ステップＳ２０２においてマップを選択するためのマップＩＤが更に含まれていてもよい。

このようにして、ステップＳ４０２では、カード１１４から読み取ったＩＤ情報に従い、対応するキャラクタ名などのキャラクタの情報を、キャラクタテーブル５００から抽出してＲＡＭ１０２に格納する。

ステップＳ４０２でメインキャラクタの情報を抽出すると、ステップＳ４０３において、カード情報読込用画面を表示部１０６に表示する。このカード情報読込用画面の一例は、図６に示す通りである。図６は、発明の実施形態に対応するカード情報読込用画面の一例を示す図である。

図６において、カード情報読込用画面６００には、ステップＳ４０２で抽出したメインキャラクタの情報に含まれるキャラクタ名５０２とキャラクタ画像５０６とに基づき、キャラクタ表示６０１と、キャラクタ名表示６０２とが行われる。図６では、キャラクタ名として「キャラクタＡ」が表示されている。サポートキャラクタ名表示領域６０３、６０４及び６０５は、サポートキャラクタのカード情報を取得した際に、サポートキャラクタ名を表示する領域である。

画面６００ではまた、メインキャラクタを示すメインキャラアイコン６０６と、各サポートキャラクタを示すアイコン６０７、アイコン６０８及びアイコン６０９とが表示される。サポートキャラクタは、カード１１４を読み込んだ順に、上からアイコン６０７、アイコン６０８、アイコン６０９にそれぞれ割り当てられていく。例えば、２枚目のカード１１４が読み込まれると、該カード１１４のＩＤ情報から特定されるキャラクタは、アイコン６０７に割り当てられるサポートキャラクタとなる。同様にして、３枚目はアイコン６０８、４枚目はアイコン６０９に割り当てられる。

以下では、アイコン６０７に割り当てられたサポートキャラクタを「キャラクタ１」、アイコン６０８に割り当てられたサポートキャラクタを「キャラクタ２」、アイコン６０９に割り当てられたサポートキャラクタを「キャラクタ３」と呼ぶことにする。図６では記載していないが、各サポートキャラクタの画像は、メインキャラクタ表示６０１の付近に表示される。表示６１０は、プレーヤが「１Ｐ（Ｐｌａｙｅｒ１ともいう）」に割り当てられていることを示している。

ステップＳ４０４では、サポートカードの情報を取得したか否かを判定する。もし、取得した場合には（ステップＳ４０４においてＹＥＳ）、ステップＳ４０５に移行して、取得したＩＤ情報に対応するサポートキャラクタの情報をキャラクタテーブル５００から抽出して、ＲＡＭ１０２に格納する。すなわち、ＣＰＵ１０１がゲーム用プログラム１１１を実行することにより、キャラクタ記憶手段よりサポートキャラクタとしてキャラクタデータを読み出すサポートキャラクタ読出手段が実現されており、ＲＡＭ１０２は、サポートキャラクタ読出手段により読み出されたキャラクタデータをサポートキャラクタデータとして記憶するサポートキャラクタ記憶手段として機能している。続くステップＳ４０６では、抽出したサポートキャラクタの情報に基づいて、サポートキャラクタの画像をメインキャラクタ表示６０１の付近に表示し、サポートキャラクタ名表示領域に対応するサポートキャラクタ名を表示して、カード情報読込用画面を更新する。

続くステップＳ４０７では、３枚分のサポートカード情報を取得したか否かを判定する。もし、取得した場合には（ステップＳ４０７において「ＹＥＳ」）、ステップＳ４０８に移行する。一方、３枚分のサポートカード情報を取得していない場合は（ステップＳ４０７において「ＮＯ」）、ステップＳ４０４に戻って処理を継続する。

次に、図２のステップＳ２０６におけるイベント処理の詳細について説明する。図７Ａは、本実施形態におけるイベント処理の一例として、プレーヤからの操作を受けつける処理を示すフローチャートである。図７Ａに示すフローチャートに対応する処理は、ＲＡＭ１０２に読み出された内部記憶装置１１０に記憶されているゲーム用プログラム１１１をＣＰＵ１０１が実行することにより実現される。すなわち、ＣＰＵ１０１がゲーム用プログラム１１１を実行することにより、メインゲーム実行手段として機能することにより実現されるものである。

まず、ステップＳ７０１では、メインゲームを実行するためのイベント画面を表示する。このイベント画面の一例を図８Ａに示す。図８Ａにおいて、画面８００には、メインキャラクタ８０１と８０２とが表示されている。このメインキャラクタ８０１及び８０２の表示用画像は、キャラクタテーブル５００のキャラクタ画像５０６に含まれている。メインキャラクタ８０１の周辺には、コマンドリング８０９の円周上にコマンド識別情報が該メインキャラクタ８０１を取り囲むように配置されている。ここでのコマンド識別情報には、コマンドアイコン８０３、８０４、８０５が含まれる。同様に、メインキャラクタ８０２の周辺には、コマンドリング８１０の円周上にコマンド識別情報としてのコマンドアイコン８０６、８０７、８０８が該メインキャラクタ８０２を取り囲むように配置されている。このような配置をとることにより、メインキャラクタを視認することで、メインキャラクタと共に移動するコマンドリング８０９も同時に視認することができ、操作の効率化を図ることができる。なお、これらのコマンドアイコンは、各キャラクタを操作するプレーヤ（所謂ＣＰＵ対戦の場合はＣＰＵ１０１）の選択肢に対応している。画面８００上でのコマンドアイコンの配置は、操作部１０３のボタン１０３ａ、ボタン１０３ｂ、ボタン１０３ｃの物理的配置と視覚的に対応している。

また、プレーヤが操作するキャラクタ及びアイコン群を識別するために、プレーヤの識別表示８２１及び８２２が画面上に表示されている。また、キャラクタ８０１のサポートキャラクタについてアイコン画像８１３、８１４及び８１５が画面左下に表示される。同様にキャラクタ８０２のサポートキャラクタについてアイコン画像８１７、８１８及び８１９が画面右下に表示される。各サポートキャラクタの画像は、キャラクタテーブル５００のキャラクタ画像５０６に含まれている。メーター８１６及び８２０は、各プレーヤに割り当てられたサポートキャラクタのうち、アクティブ（選択状態）にあるサポートキャラクタのゲージを示している。ゲージの値は、ゲームの進行に応じて増加する。また、アクティブなサポートキャラクタはプレーヤが操作部１０３を利用して任意に変更することができる。

画面８００では、Ｐｌａｙｅｒ１側のサポートキャラクタについて「サポートキャラクタ１」がアクティブにあり、Ｐｌａｙｅｒ２側のサポートキャラクタについて「サポートキャラクタＢ」がアクティブにあることを示している。なお、アクティブなサポートキャラクタのアイコンは、他に比べて大きく表示される。画面８００では、アイコン８１３及び８１７が他より大きく表示されている。

図８Ａの場合、キャラクタ８０１、アイコン群８０３乃至８０５及び８１３乃至８１５がＰｌａｙｅｒ１に割り当てられ、キャラクタ８０２、アイコン群８０６乃至８０８及び８１７乃至８１９がＰｌａｙｅｒ２に割り当てられている場合が示されている。本実施形態では、第１のプレーヤが第２のプレーヤと対戦する場合について説明するところ、第１のプレーヤがＰｌａｙｅｒ１に割り当てられ、第２のプレーヤがＰｌａｙｅｒ２に割り当てられる。なお、第１及び第２のプレーヤのいずれか一方をＣＰＵ１０１が代わりに担当してもよい。また、キャラクタ８０１及び８０２のそれぞれに与えられている体力の値は、体力メーター８１１及び８１２により画面上に示される。該体力の初期値は、各キャラクタの体力５０５の値に基づく。

次に、図８Ｂを参照してコマンドアイコンと操作部１０３の各ボタンとの対応関係を説明する。図８Ｂは、画面８００におけるコマンドリング上の各コマンドアイコンの表示位置関係と、操作部１０３のボタン１０３ａ乃至１０３ｃの配置位置との対応関係を説明するための図である。

図８Ｂにおいて、キャラクタ８０１用のコマンドリング８０９を上側に示している。コマンドアイコンＡ（８０３）、Ｂ（８０４）、Ｃ（８０５）は、後述する図１０で示すような三次元ゲーム空間（ＸＹＺ空間）において、高さ方向（Ｚ軸方向）と横方向（Ｙ軸方向）で規定される二次元平面に配置される。このとき、Ａは、ＢやＣよりも高さ方向で上側に位置し、Ｂは横方向で右側（正の側）に位置する。

これに対して、ボタン１０３ａ乃至１０３ｃは、操作部１０３において、ボタン１０３ａ乃至１０３ｃで規定される二次元平面の縦軸（第１軸）と横軸（第２軸）を基準に考えることができる。このとき、ボタン１０３ａは、ボタン１０３ｂ及び１０３ｃよりも第１軸で正方向の側に位置し、かつ、ボタン１０３ｂは、ボタン１０３ｃよりも第２軸で正方向の側に位置する。

ここで、コマンドアイコンＡとボタン１０３ａとが対応し、コマンドアイコンＢとボタン１０３ｂが対応し、コマンドアイコンＣとボタン１０３ｃとが対応していることは、各アイコン、ボタンの位置関係から明らかである。

以下、本実施形態の説明では、コマンドアイコンＡに割り当てられるコマンドを「コマンドＡ」、同様にコマンドアイコンＢ、コマンドアイコンＣに割り当てられるコマンドを「コマンドＢ」、「コマンドＣ」と呼ぶ。コマンドＡは、ボタン１０３ａの操作により選択されるコマンドであり、同様にコマンドＢ、コマンドＣは、ボタン１０３ｂ、１０３ｃの操作により選択されるコマンドである。

ゲームが開始されると、プレーヤは操作部１０３のボタン１０３ａ乃至１０３ｃのいずれかを選択することができる。コマンドアイコン８０３乃至８０５及び８０６乃至８０８の内容は、キャラクタ８０１と８０２との距離に応じて変化する。また、画面の奥行き方向（Ｘ軸方向）における各キャラクタの位置に応じてコマンドアイコンの表示サイズが変化する。

なお、図８Ａに示すようなメインゲームを実行するための表示画面を表示させるための情報として、ＲＡＭ１０２には、図９に示すような情報が保存される。図９において、テーブル９００には、まず、プレーヤを識別するためのプレーヤ情報９０１が登録される。このプレーヤ情報９０１としては、Ｐｌａｙｅｒ１（８２１）及び２（８２２）に対応する「１」及び「２」の数字がそれぞれ登録される。以降の項目については、各プレーヤ情報毎の値が登録されることとなる。

キャラクタ名９０２には、Ｐｌａｙｅｒ１とＰｌａｙｅｒ２がそれぞれ操作するキャラクタ８０１及び８０２のキャラクタ名が登録される。ここで登録されるキャラクタ名は、図４のフローチャートにおいて取得したメインキャラクタのキャラクタ名に対応する。

選択ボタン９０３には、コマンドアイコン８０３乃至８０８に対応する選択ボタン１０３ａ乃至１０３ｃのうち選択されたボタンを識別する情報としてＡ、Ｂ、Ｃのいずれかが、プレーヤ毎に登録される。図９では、Ｐｌａｙｅｒ１については、選択用ボタン１０３ａが選択され、Ｐｌａｙｅｒ２については選択用ボタン１０３ｂが選択された場合を示している。なお、ゲーム開始時点では選択ボタン９０３はブランクとされ、ゲーム開始後に操作を受けつけると操作されたボタンに対応する情報が登録される。

次に、位置９０４は、各キャラクタの３次元空間内における位置を示すアドレス情報を示している。キャラクタが移動可能な空間には３次元座標が設定され、キャラクタの位置は該３次元座標系における座標値として取得される。

相対距離９０５は、キャラクタ８０１と８０２との相対距離を表しており、位置９０４に登録された各キャラクタの座標値に基づいて、以下の式１によりキャラクタ間の距離を決定することができる。
Dr = {(x1-x2)2+(y1-y2)2+(z1-z2)2}1/2 式１

次に、攻撃力９０６には、各キャラクタの攻撃力の値が登録される。また、防御力９０７には、各キャラクタの防御力の値が登録される。体力９０８には、各キャラクタの体力の値が登録される。画面８００の上方には、この体力９０８の値に応じた体力メーター８１１及び８１２が表示されている。攻撃力９０６、防御力９０７及び体力９０８の初期値として登録される値は、図５に基づきメインキャラクタとサポートキャラクタを設定した際の値である。

図９の情報に基づいて図８Ａに示すような画面が表示され、イベントとしての対戦ゲームが開始されると（ステップＳ７０２において「ＹＥＳ」）、ステップＳ７０３に移行して、プレーヤから操作部１０３によるキャラクタの移動操作を受け付ける。

次に、ステップＳ７０４では、移動したキャラクタの移動後の位置情報を取得する。取得した座標値（ｘ１、ｙ１、ｚ１）及び（ｘ２、ｙ２、ｚ２）はテーブル９００の位置９０４に登録する。ここで、図１０を参照して本実施形態におけるキャラクタの移動空間及び３次元座標値の概念を説明する。

図１０では、説明の簡単のためにキャラクタ８０１のみを用いて説明する。３次元空間１０００は、キャラクタ８０１が移動可能な空間であり、当該３次元空間を二次元的に表現した画面が画面８００に相当する。空間１０００内にはＸＹＺ（縦・横・高さ）の３次元座標系１００１が設定される。原点は空間内のどこに設けても良いが、図１０では画面左奥とした。キャラクタ８０１の位置は、キャラクタの足と接する所定の大きさの面１００２を規定し、該面１００２の中心位置とする。なお、キャラクタの位置の特定方法は、このような足下の面を設定する方法でなくても、キャラクタ８０１の重心位置（腰付近の位置）を決定しこれに基づいても良いし、頭部の位置に依ってもよい。

図１０のような面１００２をキャラクタ位置を特定するために規定した場合、キャラクタ８０１が地面の上で移動している限りは、ｚ方向の移動量は０となり、座標値ｚ１は０のままである。一方、キャラクタ８０１がジャンプした場合には、ｚ方向の移動量が増加し、ｚ１は正の値を取る。この場合にはキャラクタのｚ１の値に基づいてキャラクタがジャンプしたと判定することができる。図１０では省略しているが、キャラクタ８０２についても同様にして面１００２を設定してその位置情報を３次元座標値として取得することができる。

取得した座標値（ｘ１、ｙ１、ｚ１）及び（ｘ２、ｙ２、ｚ２）を用いれば、上記の式１に従って、キャラクタ間距離Ｄｒを算出することが可能となる。

図７の説明に戻ると、ステップＳ７０５では、ステップＳ７０４で取得した各座標値に従って、キャラクタ８０１及び８０２の表示サイズと、コマンドアイコン８０３乃至８０５、及び、８０６乃至８０８の表示サイズとを変更する。係る変更は、各キャラクタの座標値のうち、Ｘ軸方向の座標値ｘ１とｘ２とに基づいて行うことができる。

表示サイズの変更は、例えば以下のようにして行うことができる。まず、ｘ１、ｘ２の取り得る範囲が、Ｘｍａｘ≧ｘ１、ｘ２≧Ｘｍｉｎであり、表示サイズをＤｍａｘ（％）からＤｍｉｎ（％）までとした場合、表示サイズＤｓ（％）は、例えばｘ１について以下のように求めることができる。
Ds = Dmin + {(x1-Xmin)/(Xmax-Xmin)}*(Dmax-Dmin) 式２

ここでＸｍａｘを１００、Ｘｍｉｎを０、Ｄｍａｘを１００％、Ｄｍｉｎを５０％とした場合を考えると、ｘ１が６０であればＤｓは８０％、ｘ１が３０であれば６５％となる。このようにして求めた表示サイズは、１００％の最大表示に対する縮小率を示しており、８０％であれば、最大表示サイズの８０％に表示サイズが縮小される。サイズの縮小方法は、公知の画像処理技術を用いることができるので、ここでは詳細な説明は省略する。

次にステップＳ７０６では、ステップＳ７０５において取得したキャラクタ８０１と８０２の三次元座標値に基づいて、キャラクタ間距離Ｄｒを計算する。ここでの計算は上記の式１に基づいて行うことができる。

次いでステップＳ７０７では、算出したキャラクタ間距離Ｄｒが所定の閾値Ｔｈ１よりも大きいか否かを判定する。Ｔｈ１の値は画面８００のサイズやキャラクタ８０１や８０２のサイズに応じて任意に設定することができる。

もし、キャラクタ間距離Ｄｒが閾値Ｔｈ１よりも大きい場合には（ステップＳ７０７において「ＹＥＳ」）、ステップＳ７０９に移行する。一方、キャラクタ間距離Ｄｒが閾値Ｔｈ１以下の場合には（ステップＳ７０７において「ＮＯ」）、ステップＳ７０８に移行する。

ステップＳ７０８では、キャラクタ間距離が「近距離」になったとして、コマンドリング上のコマンドアイコンの内容を近距離用のコマンド配置とする。ステップＳ７０９では、キャラクタ間距離が「中・遠距離」になったとして、コマンドリング上のコマンドアイコンの内容を中・遠距離用のコマンド配置とする。

ここで、コマンド配置について図１１を参照して説明する。図１１に示すコマンド配置テーブル１１００は、近距離、中・遠距離、及び、ジャンプにおけるコマンド配置を記載している。近距離と中・遠距離については、図７のキャラクタ間距離Ｄｒに基づいて判定したキャラクタ間距離の大きさにより決定されるが、ジャンプについては、操作ボタン１０３ａ乃至１０３ｃのいずれかのボタンのうち、ジャンプコマンドが割り当てられたボタンが操作された場合に選択されるコマンド配置である。当該ジャンプコマンドに関連する操作は、図７Ｂのフローチャートを参照して後述する。

コマンド配置テーブル１１００において、タイプ１１０１は、近距離、中・遠距離、ジャンプのいずれのコマンド配置に該当するかを示す。ボタンａ（１１０２）は、ボタン１０３ａに割り当てられるコマンドの種類を示す。同様に、ボタンｂ（１１０３）、ボタンｃ（１１０４）は、ボタン１０３ｂ、ボタン１０３ｃにそれぞれ割り当てられるコマンドを示している。

よって、ステップＳ７０８では、コマンド配置テーブルのタイプが近距離のコマンド配置に従い、コマンドアイコンＡにコマンド１１、コマンドアイコンＢにコマンド１２、コマンドアイコンＣにコマンド１３の対応する各アイコン画像を配置する。ステップＳ７０９では、コマンド配置テーブルのタイプが中・遠距離のコマンド配置に従い、コマンドアイコンＡにコマンド２１、コマンドアイコンＢにコマンド２２、コマンドアイコンＣにコマンド２３の対応する各アイコン画像を配置する。なお、近距離のコマンドの一例としては、「攻撃」（近くにいる相手を攻撃）、「投技」（密着した相手への攻撃）、「防御」（相手の攻撃から身を守る）の組み合わせがあり、中・遠距離のコマンドの一例としては、「手裏剣」（遠くにいる相手を攻撃）、「ダッシュ」（相手のいる方向への移動）、「バックステップ」（相手と逆方向への移動）の組み合わせがある。従って、従来のゲームのように多くのコマンドの中からコマンド選択をしなければならないという煩わしさがなくなり、キャラクタ間距離に応じて必要なコマンドのみが選択できるので、攻撃・防御・移動の操作を効率よく行えることとなる。

以上のように、本実施形態によればキャラクタの３次元空間内における表示位置に応じてキャラクタ及びコマンドリングに表示されるコマンドの表示サイズを変更することができる。また、キャラクタ間距離に応じて使用できるコマンドの種類が変更されるので、より趣味性の高いゲーム体験を提供することができる。

次に、図７Ｂを参照して、ゲームにおける勝敗判定の処理について説明する。図７Ｂは、本実施形態におけるイベント処理の一例として、勝敗判定処理を示すフローチャートである。図７Ｂに示すフローチャートに対応する処理は、ＲＡＭ１０２に読み出された内部記憶装置１１０に記憶されているゲーム用プログラム１１１をＣＰＵ１０１が実行することにより実現される。

まず、ステップＳ７１１では、操作部１０３のボタン１０３ａ乃至１０３ｃのいずれかのボタンの操作を受けつけたか否かを判定する。もし、操作を受けつけた場合には（ステップＳ７１１において「ＹＥＳ」）、ステップＳ７１２に移行する。ステップＳ７１２では、操作を受け付けたボタンがジャンプコマンドが割り当てられたボタンであったか否かを判定する。ここでジャンプコマンドとは、画面８００内に表示されているキャラクタをジャンプさせるために操作するコマンドである。ジャンプコマンドを受け付けたか否かは、ボタン１０３ａ乃至１０３ｃに割り当てられているコマンドに基づいて判定することができる。

もし、ジャンプコマンドを受け付けた場合には（ステップＳ７１２において「ＹＥＳ」）、ステップＳ７１３に移行する。ステップＳ７１３では、コマンド配置テーブル１１００のタイプ１１０１が「ジャンプ」のコマンド配置に従い、コマンドアイコンＡにコマンド３１、コマンドアイコンＢにコマンド３２、コマンドアイコンＣにコマンド３３の対応する各アイコン画像を配置する。その後、ステップＳ７１１に戻る。

図７Ｂの処理を行っている間も、図７ＡのステップＳ７０３からステップＳ７０９における処理は継続している。図７Ｂでは処理の記載を省略しているが、ジャンプコマンドに対応してキャラクタが画面８００内でジャンプした後、地面に着地した場合にはジャンプ用コマンドの配置から、キャラクタ間の距離に応じたコマンド配置に戻る。係る処理は、ジャンプしたキャラクタの三次元座標値のｚ軸方向の値に着目し、ｚ１或いはｚ２が所定の閾値Ｔｈ２よりも大きいか否かを判定することにより行う。閾値Ｔｈ２は、任意の正の値を取ることができる。もし、閾値Ｔｈ２よりもｚ方向の値が大きければジャンプが継続しており、そうでなければ着地したと判定することができる。もし、着地判定がなされれば、コマンド配置はその時点でのキャラクタ間距離Ｄｒに応じた配置となる。

図７Ｂの説明に戻り、ステップＳ７１２において、ボタン操作に対応するコマンドがジャンプコマンドでなかった場合（ステップＳ７１２において「ＮＯ」）、ステップＳ７１４に移行する。この場合、選択されたコマンドには攻撃目的のコマンドや、防御目的のコマンドが含まれる。コマンドの実行の結果に基づいて、ステップＳ７１４では、キャラクタが受けたダメージの有無を判定する。例えば、相手方のキャラクタが先に攻撃を仕掛けてきて、その攻撃を受けてしまった場合や、防御したものの相手方の攻撃力が勝っていたためにダメージを受けてしまう場合など、対戦ゲームにおける一般的なダメージの要因に基づいてここでのダメージの有無を判定することができる。もしダメージがあると判定された場合（ステップＳ７１４において「ＹＥＳ」）、ステップＳ７１５に移行する。

続くステップＳ７１５では、キャラクタに与えるダメージ値（Ｄｄｍ）を算出する。ダメージ値は予め定められた算出条件に従って、算出することができる。例えば、テーブル９００で各キャラクタに設定された攻撃力９０６と防御力９０７との単純な差分としても良いし、攻撃力９０６の値に重み（例えば、２倍する。）をつけて、防御力９０７との差分をとっても良い。

続くステップＳ７１７では、テーブル９００に登録されているダメージを受けたキャラクタの体力９０８の値から、算出したダメージ値Ｄｄｍを減算して、体力９０８の値を更新する。更に、ステップＳ７１８では減算後の体力９０８に基づき、体力メーター８１１または８１２の表示を更新する。さらに、ステップＳ７１８では、体力９０８の減算に基づき、体力９０８が「０」となったキャラクタが存在するか否かを判定する。もし、体力９０８が「０」となったキャラクタが存在する場合は（ステップＳ７１８において「ＹＥＳ」）、ステップＳ７２１に移行する。一方、そのようなキャラクタが存在しない場合は（ステップＳ７１８において「ＮＯ」）、ステップＳ７１９に移行する。

ステップＳ７１９では、Ｄｄｍが閾値Ｔｈ３を超えるか否かを判定する。ここでは一度に受けたダメージが一定値以上か否かを判定する。もし、Ｄｄｍが閾値Ｔｈ３を超える場合には、ステップＳ７２０に移行する。一方、Ｄｄｍが閾値Ｔｈ３を超えない場合はステップＳ７１１に戻る。ステップＳ７２０では、当該キャラクタについてはコマンド操作を一定期間受け付けないこととする。この場合、コマンドリング８０９や８１０が画面上から消去される。一定期間は、例えば、「５秒」等のように設定することができる。当該一定期間が経過した場合は、ステップＳ７１１に戻ってゲームを継続する。

ステップＳ７２１では、最終的な勝敗を画面８００に表示する。具体的には、体力９０８が「０」でないキャラクタを勝者とし、体力９０８が「０」となったキャラクタを敗者とするように表示を行う。その後、図２の処理に戻る。

以上のようにして、キャラクタの対戦を行い、最終的に体力９０８が「０」となった場合に対戦ゲームを終了させることができる。

なお、図７Ｂでは、一度に受けたダメージが一定値以上の場合に、該当するキャラクタについてコマンドを受け付け無いこととしたが、これ以外の条件においてコマンドの受付を停止しても良い。例えば、特定の攻撃を行う場合には、その間においてコマンドの受付を停止しても良い。

次に、サポートキャラクタに関する処理を説明する。まず、図８Ａに示すゲーム画面８００において、Ｐｌａｙｅｒ１側のサポートキャラクタは画面左下、Ｐｌａｙｅｒ２側のサポートキャラクタは画面右下に表示されている。このうち他より大きく表示されている大アイコン８１３及び８１７が現在アクティブなサポートキャラクタである。アクティブなサポートキャラクタについては、キャラクタ名とゲージ値がボックス８１６及び８２０内に表示されている。当該表示において、ゲージ８１６或いは８２０の値が最大値の場合、ゲージが満タン（フル）となったアクティブなサポートキャラクタを使った攻撃が可能となる。

係る表示を行うための内部処理について図１２を参照して説明する。図１２は、発明の実施形態に対応するサポートキャラクタの処理の一例を示すフローチャートである。図１２に示すフローチャートに対応する処理は、ＲＡＭ１０２に読み出された内部記憶装置１１０に記憶されているゲーム用プログラム１１１をＣＰＵ１０１が実行することにより実現される。

まず、ステップＳ１２０１では、３つのサポートキャラクタのうち処理対象のサポートキャラクタを選択する。サポートキャラクタの情報は、図１３に示すようにテーブル化されている。

図１３において、サポートキャラクタ１３０１には、図５のキャラクタテーブル５００に登録されたサポートキャラクタのキャラクタ名が登録される。状態１３０２には、サポートキャラクタの状態として、「アクティブ」、「非アクティブ」のいずれかが登録される。ここで、「アクティブ」なサポートキャラクタは、画面８００上で大アイコンで表示され、「非アクティブ」なサポートキャラクタは画面８００上で小アイコンで表示される。

ゲージ値１３０３には、ゲージ８１６或いは８２０に表示されるべきゲージの値が数値として登録される。経過時間１３０４には、サポートキャラクタの状態が「アクティブ」から「非アクティブ」に変更されてからの経過時間が登録される。

即ち、ステップＳ１２０１では、サポートキャラクタテーブル１３００に登録されているサポートキャラクタを順に選択していく。続くステップＳ１２０２では、選択されたサポートキャラクタがアクティブであるか否かを判定する。当該判定は、サポートキャラクタテーブル１３００の状態１３０２の内容に基づいて判定することができる。

もし、状態が「アクティブ」の場合はステップＳ１２０９に移行し、「非アクティブ」の場合はステップＳ１２０３に移行する。ステップＳ１２０３では、経過時間１３０４の値に応じてゲージの値を増加させ、ゲージ値１３０３を更新する。続くステップＳ１２０４では、サポートキャラクタの状態がアクティブに変更されたか否かを判定する。サポートキャラクタの状態変更は、メインのキャラクタ８０１や８０２について、コマンドリングが非表示状態となり、コマンド選択の受け付けを停止している期間に操作部１０３の操作を介して行うことができる。もし、アクティブに変更された場合には（ステップＳ１２０４において「ＹＥＳ」）、ステップＳ１２０５に移行する。一方、アクティブに変更されていない場合は（ステップＳ１２０４において「ＮＯ」）、ステップＳ１２０１に戻って処理を継続する。

ステップＳ１２０５では、経過時間１３０４の値をリセットする。次いで、ステップＳ１２０６に移行して、ゲージ値がフルであるか否かを判定する。ゲージ値１３０３には予め最大値を設けておき、ゲージ値１３０３と当該最大値が一致していれば、ゲージフルと判定される。もしゲージフルの場合は（ステップＳ１２０６において「ＹＥＳ」）、ステップＳ１２０７に移行する。ゲージフルでなければ（ステップＳ１２０６において「ＮＯ」）、ステップＳ１２０１に戻る。

ステップＳ１２０７では、ゲージフルでアクティブ状態のサポートキャラクタを利用した攻撃操作を受け付け、該操作の受け付けに従いメインキャラクタの代わりに対戦相手の他方のメインキャラクタへの攻撃を行う。ここでの攻撃によるダメージはメインキャラクタによる攻撃と同様に相手方のダメージとなり、体力値より減算される。その後、ステップＳ１２０８に移行してゲージ値１３０３をリセットし、ステップＳ１２０１に戻る。

ステップＳ１２０２からステップＳ１２０９移行した場合の、ステップＳ１２０９では、サポートキャラクタの状態１３０２が、「アクティブ」から「非アクティブ」に変更されたか否かを判定する。もし変更された場合は（ステップＳ１２０９において「ＹＥＳ」）、ステップＳ１２１０に移行する。変更されていない場合は、ステップＳ１２０１に戻る。

ステップＳ１２１０では、非アクティブになってからの経過時間の計測を開始し、経過時間をテーブル１３００に登録する。

以上のように、本実施形態ではサポートキャラクタを使って、メインキャラクタの代わりに攻撃を行うことができる。

［第２の実施形態］
次に、発明の第２の実施形態について説明する。第２の実施形態では、第１の実施形態の図８Ａに示すような対戦ゲームにおいて、所定の条件が満足された場合に実行されるサブゲームを説明する。所定の条件には、例えば当該サブゲームの実行指示をいずれかのプレーヤが出した場合や、いずれかのキャラクタに与えられているパラメータの値が、サブゲームを実行するための条件に合致した場合などが考えられる。但し、サブゲームの開始条件自体は本実施形態の本質的特徴には当たらない。

図１４はサブゲームの画面１４００を示している。画面１４００では、メインキャラクタ１４０１と１４０２が表示される。各メインキャラクタは、着地点１４０３、１４０４、１４０５のいずれかに位置し、当該着地点を移動しながら移動速度を加速していく。その過程において、相手方のキャラクタと衝突した際に、より移動速度の速い側のキャラクタが相手方にダメージを与えることができる。着地点１４０３、１４０４及び１４０５の位置は、一定時間間隔で変更されるが、着地点同士の位置関係は変更されない。

本実施形態では、着地点１４０３、１４０４及び１４０５は、操作部１０３の操作ボタン１０３ａ、１０３ｂ及び１０３ｃのいずれかに一意に対応づけられる。例えば、着地点１４０３とボタン１０３ａ、着地点１４０４とボタン１０３ｂ、着地点１４０５とボタン１０３ｃとを対応づけすることができる。仮に、操作ボタン１０３ａ乃至１０３ｃが図８Ｂの下側に示したような配置となっており、かつ、ボタン１０３ａの外観が赤色、１０３ｂの外観が青色、１０３ｃの外観が緑色であった場合、着地点１４０３を赤色、１４０４を青色、１４０５を緑色で画面１４００内に表示すれば、各ボタンと着地点の対応関係を色の対応関係で容易に把握することができる。

また、ボタン１０３ａ乃至１０３ｃの物理的配置が図８Ｂの下側の三角形状に従う場合、図１５に示すように、着地点の位置関係を当該三角形状に従いつつ、変形することで、着地点の位置を変更しつつ、ボタンとの対応関係を維持することができる。なお、着地点１４０３乃至１４０５の配置位置については、予め複数パターンについて位置情報を特定しておき、当該複数パターンのうちいずれか１つを任意に選択することで、着地点の変更が可能となる。

図１５では、一例として着地点の配置パターンを（ａ）から（ｅ）まで示している。この例によれば、赤の着地点１４０３は常に他の着地点よりも上側に位置し、かつ、青の着地点１４０４は緑の着地点１４０５よりも右側、言い換えれば緑の着地点１４０５は青の着地点１４０４よりも左側に位置している。このような相対的な位置関係を維持することで、プレイヤはボタン１０３ａ乃至１０３ｃの物理的配置との対応関係を視覚的に容易に把握して、ボタン１０３ａ乃至１０３ｃ自体を見なくても、操作することができる。

次に、図１６のフローチャートを参照して、本実施形態に対応するサブゲームにおける処理を説明する。

まず、ステップＳ１６０１では、着地回数を表すパラメータ：Ｎｇを０回にリセットする。次いでステップＳ１６０２では、プレーヤからのボタン操作を受け付ける。ここで操作されるボタンは、ボタン１０３ａから１０３ｃのうちのいずれかである。また、受け付けたボタンに応じて、キャラクタを対応する着地点１４０３乃至１４０５のいずれかに移動させる。

次に、ステップＳ１６０３では、受け付けたボタン操作に応じて着地回数Ｎｇを１更新する。次に、ステップＳ１６０４では、Ｎｇの更新から一定時間経過したか否かを判定する。この一定時間は、例えば０．５秒、或いは、１秒とすることができる。もし、一定時間が経過した場合には（ステップＳ１６０４において「ＹＥＳ」）、ステップＳ１６０１に戻って、Ｎｇを０にリセットする。一方、一定時間が経過しない場合には（ステップＳ１６０４において「ＮＯ」）、ステップＳ１６０５に移行して、次のボタン操作を受け付けたか否かを判定する。もし、次のボタン操作を受け付けた場合には（ステップＳ１６０５において「ＹＥＳ」）、ステップＳ１６０６移行して、Ｎｇを更新する。その後、ステップＳ１６０７に移行する。なお、このとき、キャラクタ１４０１は受け付けたボタン位置に対応する着地点に移動表示される。一方、次のボタン操作を受け付けない場合は（ステップＳ１６０５において「ＮＯ」）、ステップＳ１６０４に戻って、一定時間が経過したか否かを判定する。

ステップＳ１６０７では、他のキャラクタと衝突したか否かが判定される。当該判定は、ボタン操作に基づく二つのキャラクタの着地点が共通する場合や、移動元から移動先への軌跡が交差する場合などに衝突と判定することができる。より具体的に、Ｐｌａｙｅｒ１がボタン１０３ａを操作し、Ｐｌａｙｅｒ２側のＣＰＵがボタン１０３ａに対応する着地点１４０３を次の着地点に指定した場合には、移動先の着地点が共通するので衝突が発生する。また、Ｐｌａｙｅｒ１がボタン１０３ｂを操作して緑色の着地点１４０５から、青色の着地点１４０４に移動しようとし、Ｐｌａｙｅｒ２側のＣＰＵがボタン１０３ｃに対応する緑色の着地点１４０５を次の着地点に指定して青色の着地点１４０４から移動しようとする場合に、移動の軌跡が交差して衝突が発生する。

もし、衝突していないと判定される場合（ステップＳ１６０７において「ＮＯ」）、ステップＳ１６０４に戻って一定時間の経過を判定する。一方、衝突したと判定される場合（ステップＳ１６０７において「ＹＥＳ」）、ステップＳ１６０８に移行する。ステップＳ１６０８では、両キャラクタの着地回数Ｎｇを比較し、着地回数がより多いキャラクタを勝者と判定する。本実施形態では、着地回数Ｎｇが増えるほどに、メインキャラクタの移動速度が加速していく。従って、着地回数が多いということは移動速度が早いことを意味し、勝敗判定に置いては、速度自体を比較しなくても着地回数を比較すればよい。

続くステップＳ１６０９では、敗者側のダメージを算出し、その体力値から減算する。なお、ステップＳ１６０８でＮｇが同一の場合には、両者共にダメージを受けることとして、両キャラクタについてダメージを体力値から減算する。

続くステップＳ１６１０では、体力値が０になったキャラクタが存在するか否かを判定する。もし体力値が０になったキャラクタが存在する場合には（ステップＳ１６１０において「ＹＥＳ」）、ステップＳ１６１１において本サブゲームにおける勝敗表示を行う。一方、体力値が０になったキャラクタが存在しない場合には、ステップＳ１６０１に戻って処理を続ける。

以上のように本実施形態では、選択ボタンの操作に応じて画面上を高速で移動するメインキャラクタが衝突した際の勝敗を、キャラクタの移動速度（着地回数）に基づいて決定することができ、ゲームの遊戯性を高めることができる。

以上の処理（例えば上記実施形態では図２、図４、図７Ａ、図７Ｂ、図１０、図１２、及び、図１６に示すフローチャートに従った処理、及び、必要なゲーム用データ）をプログラムとしてＣＤ−Ｒ、ＲＯＭやＤＶＤ−ＲＯＭ、ＭＯ等の記憶媒体に記憶させ、この記憶媒体に記憶されているプログラムをコンピュータにより読み出させる（インストール、もしくはコピーさせる）ことで、このコンピュータは以上の処理を行うことができる。よって、このようなプログラム及び記憶媒体も本発明の範疇にあることは明白である。

発明の実施形態に対応するゲーム装置１００の基本構成を示す図である。 発明の実施形態に対応する処理の一例を示すフローチャートである。 発明の実施形態に対応するマップ画面の一例を示す図である。 発明の実施形態に対応するカード情報読込処理の一例を示すフローチャートである。 発明の実施形態に対応するキャラクタテーブルのデータ構成の一例を示す図である。 発明の実施形態に対応するカード情報読込用画面の一例を示す図である。 発明の実施形態に対応するイベント処理における操作受付処理の一例を示すフローチャートである。 発明の実施形態に対応するイベント処理における勝敗判定処理の一例を示すフローチャートである。 発明の実施形態に対応するメインゲームを実行するためのイベント画面の一例を示す図である。 発明の実施形態に対応する操作部１０３の各ボタンとゲーム画面上のコマンドアイコンとの対応関係を説明するための図である。 発明の実施形態に対応するメインゲームの画面表示を行うための情報を登録するデータテーブルの一例を示す図である。 発明の実施形態に対応するメインキャラクタの位置情報の特定方法を説明するための図である。 発明の実施形態に対応するコマンドアイコンの配置のパターンの一例を示すコマンド配置テーブルである。 発明の実施形態に対応するサポートキャラクタに関する処理の一例を示すフローチャートである。 発明の実施形態に対応するサポートキャラクタテーブルの構成の一例を示す図である。 発明の第２の実施形態に対応するサブゲーム実行時の画面表示の一例を示す図である。 発明の第２の実施形態に対応する着地点の配置パターンの一例を示すフローチャートである。 発明の第２の実施形態に対応するサブゲームの処理の一例を示すフローチャートである。

符号の説明

１０１ ＣＰＵ
１０２ ＲＡＭ
１０３ 操作部
１０４ 通信Ｉ／Ｆ
１０５ ＲＯＭ
１０６ 表示部
１０７ サウンド処理部
１０８ スピーカ
１０９ バス
１１０ 内部記憶装置
１１１ ゲーム用プログラム
１１２ ゲーム用データ
１１３ カードリーダー
１１４ カード

Claims (11)

1. ゲーム画面を表示する表示手段と、
   メインゲームプログラムを記憶する記憶手段と、
   遊戯者からの操作入力を受け付ける複数の操作ボタンを有する操作手段と、
   前記メインゲームプログラムを実行して、第１のメインキャラクタを前記操作入力に応じて第２のメインキャラクタと第１のゲーム空間内で対戦させる対戦ゲームの第１のゲーム画面を前記表示手段に表示させるゲーム実行手段とを備えるゲーム装置であって、
   前記ゲーム実行手段は、
   前記複数の操作ボタンのそれぞれに割り当てられた前記第１のメインキャラクタを操作するためのコマンドを表す第１のコマンド識別情報を前記第１のメインキャラクタと関連づけ、かつ、前記第２のメインキャラクタを操作するために割り当てられたコマンドを表す第２のコマンド識別情報を前記第２のメインキャラクタと関連づけて、前記第１のゲーム画面上で表示させ、
   前記第１のゲーム空間内における前記第１のメインキャラクタと第２のメインキャラクタとの間の距離に応じて、前記第１のコマンド識別情報及び前記第２のコマンド識別情報の内容を変更する
   ことを特徴とするゲーム装置。
2. 前記第１のメインキャラクタ及び第２のメインキャラクタの前記第１のゲーム空間内におけるそれぞれの位置に応じて、前記第１のメインキャラクタ及び前記第１のコマンド識別情報と、前記第２のメインキャラクタ及び前記第２のコマンド識別情報との表示サイズを変更することを特徴とする請求項１に記載のゲーム装置。
3. 前記第１のコマンド識別情報と前記第２のコマンド識別情報とは、各メインキャラクタの周囲に、各メインキャラクタを囲むように配置されることを特徴とする請求項１又は２に記載のゲーム装置。
4. 前記複数の操作ボタンの前記ゲーム装置における物理的な配置関係と、
   前記第１のゲーム画面内における前記第１のコマンド識別情報の配置関係とが、
   視覚的に対応していることを特徴とする請求項１乃至３のいずれか１項に記載のゲーム装置。
5. 前記複数の操作ボタンが、第１の操作ボタンと、第２の操作ボタンと、第３の操作ボタンとを含む場合に、前記第１乃至第３のボタンで規定され、かつ、第１軸と第２軸とを有する二次元平面において、前記第１のボタンは、前記第２及び第３のボタンよりも前記第１軸の正方向の側に位置し、かつ、前記第２のボタンは、前記第３のボタンよりも前記第２軸の正方向の側に位置し、
   前記第１のコマンド識別情報が、第１のコマンドアイコンと、第２のコマンドアイコンと、第３のコマンドアイコンとを含む場合に、前記第１乃至第３のコマンドアイコンは、前記第１のゲーム空間における横及び高さ方向で規定される二次元平面に配置され、前記第１のコマンドアイコンは、前記第２及び第３のコマンドアイコンよりも前記高さ方向で上側に位置し、かつ、前記第２のコマンドアイコンは、前記第３のコマンドアイコンよりも前記横方向で右側に位置し、
   前記第１のボタンと前記第１のコマンドアイコンとが対応し、前記第２のボタンと前記第２のコマンドアイコンとが対応し、前記第３のボタンと前記第３のコマンドアイコンとが対応し、
   前記第１軸の方向が、前記第１のゲーム空間における前記高さ方向と対応し、前記第２軸の方向が、前記第１のゲーム空間における前記横方向と対応する
   ことを特徴とする請求項４に記載のゲーム装置。
6. 前記対戦ゲームにおいて、前記第１のメインキャラクタと前記第２のメインキャラクタとのそれぞれに与えられた、第１のサポートキャラクタ群及び第２のサポートキャラクタ群の情報を登録するサポートキャラクタテーブルをさらに備え、
   前記ゲーム実行手段は、前記第１のサポートキャラクタ群と前記第２のサポートキャラクタ群とを、前記第１のメインキャラクタと前記第２のメインキャラクタとにそれぞれ関連づけて前記第１のゲーム画面中に表示させ、
   前記第１のサポートキャラクタ群及び第２のサポートキャラクタ群は、選択状態のサポートキャラクタをそれぞれ１つずつ含み、前記ゲーム実行手段は、該選択状態のサポートキャラクタについてのみ、該サポートキャラクタに与えられ、前記サポートキャラクタテーブルに登録された第２のパラメータの値を前記第１のゲーム画面中で表示し、
   前記ゲーム実行手段は、前記第２のパラメータの値を、前記サポートキャラクタが選択状態に置かれていない時間の長さに応じて増加させて、前記サポートキャラクタテーブルを更新する
   ことを特徴とする請求項１乃至５のいずれか１項に記載のゲーム装置。
7. 前記ゲーム実行手段は、前記第２のパラメータが最大値を有し、かつ、前記選択状態にある場合に、対応するサポートキャラクタを前記対戦において利用可能とすることを特徴とする請求項６に記載のゲーム装置。
8. 前記記憶手段は、サブゲームプログラムを更に記憶し、
   前記ゲーム実行手段は、前記メインプログラムの実行中に所定の条件が満たされた場合に、前記サブゲームプログラムを実行して、前記第１のメインキャラクタを前記操作入力に応じて前記第２のメインキャラクタと第２のゲーム空間内で対戦させる対戦ゲームの第２のゲーム画面を前記表示手段に表示させ、
   前記第２のゲーム画面では、前記第１のメインキャラクタ及び前記第２のメインキャラクタとが位置可能な複数の着地点が表示され、
   前記複数の着地点の前記第２のゲーム画面内での配置関係は、前記複数の操作ボタンの前記ゲーム装置における物理的な配置関係と視覚的に対応する
   ことを特徴とする請求項１乃至７のいずれか１項に記載のゲーム装置。
9. 前記複数の操作ボタンが、第１の操作ボタンと、第２の操作ボタンと、第３の操作ボタンとを含む場合に、前記第１乃至第３のボタンで規定され、かつ、第１軸と第２軸とを有する二次元平面において、前記第１のボタンは、前記第２及び第３のボタンよりも前記第１軸の正方向の側に位置し、かつ、前記第２のボタンは、前記第３のボタンよりも前記第２軸の正方向の側に位置し、
   前記複数の着地点が、第１の着地点と、第２の着地点と、第３の着地点とを含み、前記第２のゲーム空間が縦、横、高さ方向で規定される場合に、前記第１の着地点は、前記第２のゲーム空間内で前記第２及び第３の着地点よりも前記高さ方向で上側に位置し、かつ、前記第２の着地点は、前記第３の着地点よりも前記横方向で右側に位置し、
   前記第１のボタンと前記第１の着地点とが対応し、前記第２のボタンと前記第２の着地点とが対応し、前記第３のボタンと前記第３の着地点とが対応し、
   前記第１軸の方向が、前記第２のゲーム空間における前記高さ方向と対応し、前記第２軸の方向が、前記第２のゲーム空間における前記横方向と対応する
   ことを特徴とする請求項８に記載のゲーム装置。
10. 前記ゲーム実行手段は、前記第２のゲーム空間内で、前記第１のメインキャラクタ及び前記第２のメインキャラクタの少なくとも一方を、前記第１の操作ボタン、前記第２の操作ボタン、または、前記第３の操作ボタンに対する操作に応じて、対応する着地点に移動させて前記第２のゲーム画面を表示させ、
    前記第１のメインキャラクタと前記第２のメインキャラクタとが前記第１乃至第３の着地点のいずれかに着地した着地回数を計数する計数手段と、
    前記第１のメインキャラクタと前記第２のキャラクタが衝突表示されるか否かを判定する衝突判定手段と、
    前記衝突手段が衝突表示されると判定された場合に、前記第１のメインキャラクタの前記着地回数と前記第２のメインキャラクタの前記着地回数との大小に従って、衝突時の勝敗を決定する勝敗決定手段と
    を備えることを特徴とする請求項９に記載のゲーム装置。
11. ゲーム画面を表示する表示手段と、メインゲームプログラムを記憶する記憶手段と、遊戯者からの操作入力を受け付ける複数の操作ボタンを有する操作手段と、前記メインゲームプログラムを実行して、第１のメインキャラクタを前記操作入力に応じて第２のメインキャラクタと第１のゲーム空間内で対戦させる対戦ゲームの第１のゲーム画面を前記表示手段に表示させるゲーム実行手段とを備えるゲーム装置の制御方法をコンピュータに実行させるためのコンピュータプログラムであって、前記方法が、
    前記複数の操作ボタンのそれぞれに割り当てられた前記第１のメインキャラクタを操作するためのコマンドを表す第１のコマンド識別情報を前記第１のメインキャラクタと関連づけ、かつ、前記第２のメインキャラクタを操作するために割り当てられたコマンドを表す第２のコマンド識別情報を前記第２のメインキャラクタと関連づけて、前記第１のゲーム画面上で表示させる工程と、
    前記第１のゲーム空間内における前記第１のメインキャラクタと第２のメインキャラクタとの間の距離に応じて、前記第１のコマンド識別情報及び前記第２のコマンド識別情報の内容を変更する工程と
    を備えることを特徴とするコンピュータプログラム。