以下、本発明の一実施の形態について図面を参照して説明する。
図1は、本発明の一実施の形態における業務用ゲーム機(アーケードゲーム装置)10の外観構成の例を示す構成図である。図1に示すように、業務用ゲーム機10は、筐体11の前面上部に音声を出力するスピーカ12と、CRTや液晶表示器などからなり、画像を表示する表示装置13とが配置されている。筐体11の前面下部にゲームを開始するためのコインを投入するためのコイン投入口14と、後述するゲーム用カード(以下、「ゲームカード」と呼ぶ。)を外部に排出するためのゲームカード排出口15とが設けられている。
表示装置13とコイン投入口14との間には、各種コントローラが配設されたコントローラ配設領域がある。そして、コントローラ配設領域の略中央部には、ステアリング形状のコントローラであるステアリング型コントローラC1が設けられている。また、ステアリング型コントローラC1の略中心部(一般的車両において、クラクションが配設される部分)には、プレイヤ操作ボタン16が設けられている。さらに、ステアリング型コントローラC1の左側の上方には、棒状コントローラ(シフトレバー)18が設けられている。ステアリング型コントローラC1及びシフトレバー18は、主に、業務用ゲーム機10にてプレイされるゲームのうち、プレイヤが後述する第1ゲームモードをプレイする際に使用される。すなわち、ステアリング型コントローラC1とシフトレバー18とは、主に、第1ゲームモードのビデオゲームを進行させるために操作される。以下、適宜ステアリング型コントローラC1を「ステアリングC1」と呼ぶこととする。
コントローラ配設領域の下方には、後述するゲームカードを挿入するためのゲームカード挿入口を備え、ゲームカード挿入口に挿入されたゲームカードに記載されたコードデータを読み取るスキャナ17aが設けられている。
また、コントローラ配設領域の上方、ステアリング型コントローラC1に対するシフトレバー18の位置の略逆側には、ユーザ情報が登録されたユーザカード(例えば、ICチップが内蔵されたカード)を挿入するためのユーザカード挿入口を備え、ユーザカード挿入口に挿入されたユーザカードからユーザ関連情報を読み出すとともにそのユーザカードに対してユーザ関連情報を書き込むことが可能なカードリーダライタ17bが設けられている。カードリーダライタ17bは、例えば、RFID(Radio Frequency Identification)対応のものが用いられる。なお、ゲームカード挿入口とユーザカード挿入口とが共通の1つのカード挿入口により構成されていてもよい。
また、筐体11の底面には、キャスター19aが複数配置されており、業務用ゲーム機10を容易に移動できるようにしている。筐体11の下面前側には、高さを調節するアジャスター19bが配置されており、設置場所の凹凸に関わらずに、業務用ゲーム機10を安定して設置できるようにしている。さらに、筐体11の内部には、制御回路を搭載した基盤などが収納されたシールドケース(図示せず)が設けられている。
次に、業務用ゲーム機10の物理的動作について説明する。
図2は、ステアリング型コントローラC1が、例えばプレイヤによって、位置(または姿勢)を変えられたときの、業務用ゲーム機10の外観構成を示す構成図である。図2に示すように、ステアリング型コントローラC1は、付け根の部分の角度を変更可能に構成されている。なお、本例においては、ステアリング型コントローラC1は、所定の条件が満たされるまではロック(固定)されており、所定の条件が満たされたときにロックが解除され、位置変更(または姿勢変更)が可能となる。なお、ステアリング型コントローラC1の位置変更は、人の力に頼らない構成としてもよいし、人の力を補助する機構が備えられた構成としてもよい。また、ステアリング型コントローラC1は、所定の位置(退避位置)まで移動されたことに応じて、その場に(またはその姿勢で)ロックされるものとする。本例においては、ステアリング型コントローラC1は、ステアリング型コントローラ駆動部CD1(図示せず)によって業務用ゲーム機10における位置が制御されるものとする。
図3は、ステアリング型コントローラC1が所定の位置(本例においては、図2に示した位置。)に移動されたことに応じて、レバー型コントローラC2が出現したときの、業務用ゲーム機10の外観構成を示す構成図である。図3に示すように、レバー型コントローラC2は、ステアリング型コントローラC1の両側に、人が片手で握れる程度の持ち手を供えたコントローラ(レバー形状のコントローラ、レバー型コントローラ。)C2が2個ずつ設けられている。なお、本例においては、レバー型コントローラC2にはそれぞれ枠CLが設けられており、レバー型コントローラC2はそれぞれ回転可能に構成されている。また、レバー型コントローラC2には、トリガー型コントローラC3が設けられている。レバー型コントローラC2とトリガー型コントローラC3は、主に、業務用ゲーム機10にてプレイされるゲームのうち、プレイヤが後述する第2ゲームモードをプレイする際に使用される。すなわち、レバー型コントローラC2とトリガー型コントローラC3は、主に、第2ゲームモードのビデオゲームを進行させるために操作される。以下、適宜レバー型コントローラC2を「ジャイロレバーC2」と、トリガー型コントローラC3を「トリガーC3」と呼ぶこととする。なお、レバー型コントローラC2は、それぞれ枠CLに沿って回転可能に構成されていてもよく、プレイヤによる指示の入力が可能な構成であればよい。
なお、業務用ゲーム機10を1つ使用して2人のプレイヤが協力してプレイする場合は、先ず、1のプレイヤがステアリングを使用してドライブモードによるビデオゲームを行い、次に他のプレイヤがステアリングを使用してドライブモードによるビデオゲームを行い、その結果を利用したバトルモードによるビデオゲームを、それぞれが2つのジャイロレバーC2を使用して行うこととなる。
レバー型コントローラC2は、ゲームの進行中に、後述する条件が成立したときにステアリング型コントローラC1の位置がゲーム開始時の配置(図1に示す状態。)から上方向に移動した状態(図2,3に示す状態)となったことに応じて、レバー型コントローラ駆動部CD2(図示せず。)により、初期位置(図1に示すように、プレイヤによる操作が不能な位置。外観に現れない位置。)から特定の位置(図3に示すように、プレイヤによる操作が可能な位置。外観に現れた位置。)に移動させられる。
具体的には、図1に示す状態ではレバー型コントローラC2は業務用ゲーム10の内部に格納されており、ステアリング型コントローラが持ち上げられたことに応じて(図2に示した状態になったことに応じて)、業務用ゲーム機10の一部が駆動し、レバー型コントローラC2が前方にせり出される。すなわち、本例においては、レバー型コントローラC2は、収納状態から露出状態に移動可能に構成される。なお、2種類のコントローラの駆動方法はこれに限定されず、第1コントローラが操作できない(または不便な)位置に移動したことに応じて、第2コントローラが操作可能な(または、利便な)位置に移動する構成とされていればよい。また、本例においては、各コントローラC1,C2は、ゲーム終了に応じて初期位置に戻る構成とされているものとする。
次に、業務用ゲーム機10の内部構成について説明する。
図4は、業務用ゲーム機10の回路構成の例を示すブロック図である。図4に示すように、業務用ゲーム機10は、シールドケース内に制御回路(コンピュータ装置)20aが収められている。制御回路20aは、CPU21と、ROM22と、RAM23と、画像処理部24と、音声処理部26と、音声出力部27と、入出力制御部28と、通信制御部29とを備えている。
CPU21は、ROM22に記憶されたゲーム処理プログラムを実行し、プレイヤの操作に応じて業務用ゲーム機10において提供するゲームを進行するための各種の制御を実行する機能を有する。なお、CPU21は、内部タイマを含んでいるものとする。
ROM22は、CPU21により実行されるゲーム処理プログラム、及びゲームの進行に応じて変更されることのない各種のデータを記憶する。RAM23は、CPU21のワークエリアとして使用され、ゲームの進行に応じて変更されるデータを記憶する。
画像処理部24は、表示部25に接続されており、CPU21の制御に従って、ゲーム進行やプレイヤ操作に応じたゲーム画面を表示部25に表示させる。表示部25は、例えば、液晶表示装置によって構成される。なお、本例においては、業務用ゲーム機10に表示画面が1つの場合を例に説明を行うため、表示装置13と表示部25は同一のものである。よって、以下、表示部25を用いて説明を行うものとする。
音声処理部26は、音声出力部27に接続されており、CPU21の制御に従って、ゲーム進行やプレイヤ操作に応じて音声を出力させる。
入出力制御部28は、コイン投入口14からのコインの投入を検知するコイン投入センサ14Sと、ステアリング型コントローラ駆動部CD1と、レバー型コントローラ駆動部CD2と、操作ボタン16と、スキャナ17(スキャナ17a,17b)と、
カードスタッカ(図示せず)に積まれたゲームカードをゲームカード排出口15から外部に排出するためのゲームカード排出部15Dとに接続されている。ステアリング型コントローラ駆動部CD1は、ステアリング型コントローラC1の状態を検知するセンサ(図示せず)を含む。また、レバー型コントローラ駆動部CD2は、レバー型コントローラC2の状態を検知するセンサ(図示せず)を含む。
コイン投入センサ14Sの検出信号、操作ボタン16の入力信号、スキャナ17によりカードから読み取られたデータを示す信号、ステアリング型コントローラC1が所定の位置に移動したことの検出信号、およびレバー型コントローラが特定の位置に移動したことの検出信号を含む各種信号は、入出力制御部28を介してCPU21に入力される。また、レバー型コントローラC2を特定の位置に移動させるための指示や、ステアリング型コントローラC1とレバー型コントローラC2とをそれぞれ初期位置に移動させるための指示は、入出力制御部28を介してCPU21から各駆動部(ステアリング型コントローラ駆動部CD1とレバー型コントローラ駆動部CD2)に伝えられる。
通信制御部29は、他の機器(外部機器)に接続されており、接続された外部機器50との間における情報の送受信を制御する。通信制御部29に接続される外部機器50は、業務用ゲーム機10と同じ構成を有する他の業務用ゲーム機とすることができる。接続される他の業務用ゲーム機は業務用ゲーム機10に隣接して設置され、専用線接続されるものであってもよいし、遠隔地に設置され、電話回線やインターネット等の通信回線を介して接続されるものであってもよい。また、通信制御部29に接続される外部機器50は、業務用ゲーム機10が設置されたゲームセンタの管理コンピュータ等であってもよい。なお、CPU21、ROM22、RAM23、画像処理部24、音声処理部26、入出力制御部28、及び通信制御部29は、それぞれ内部バス31によって接続されているものとする。また、業務用ゲーム機の構成はこれに限定されず、例えば、外部記憶装置(情報記憶手段)にゲームの進行に応じて変更されるデータなど各種データを記憶する構成としてもよい。
本実施の形態の例に係る業務用ゲーム機10では、ゲームに参加して敵キャラクタと対戦することとなるプレイヤキャラクタを選択するために、プレイヤキャラクタとして選択可能なキャラクタの情報を書き込んだゲームカードを用いるものとしている。ゲームカードは、複数種類のうちの何枚かが基本ゲームカードとしてゲームの実行とは別に提供される。また、新たにゲームを行うためにコインを投入すると、新たなゲームカードが1枚提供される。なお、プレイヤがゲームカードを有していない場合にも選択できるプレイヤキャラクタを設定しておく構成としてもよい。
次に、本実施の形態の例にかかる業務用ゲーム機10で用いられるゲームカードについて説明する。ゲームカード30には、キャラクタの名称やステータスに関するキャラクタ情報を示す表示と、コードデータとが描かれている。なお、本例の場合は、ゲームカード一枚につき、プレイヤキャラクタとしてゲームに参加させることが可能な複数種類のキャラクタのうち、いずれか1種類が描かれている。スキャナ17aがコードデータを読み取ると、ゲームカード30に描かれているキャラクタがプレイヤキャラクタとしてゲームに登場することとなる。
また、本例においては、1枚のゲームカードに、車両形態時のプレイヤキャラクタに関する情報と、車両形態とは異なる戦闘形態(例えば、動物型や人型のロボット形態)時のプレイヤキャラクタに関する情報とを特定可能なコードデータが描かれているものとする。
なお、コードデータは、ゲームカード30を一意に識別するためのデータをコード化したものであり、本実施の形態で用いられるゲームカードには、上述したようにキャラクタ情報を示すものの他、例えば、プレイヤキャラクタの攻撃力を上昇させるアイテムや、コマンド内容を変更させるアイテムを示すコードデータが描かれているものも含むこととする。
次に、本実施の形態の例にかかる業務用ゲーム機10で用いられるユーザカードについて説明する。ユーザカード31は、例えば、業務用ゲーム機10に隣接して設けられたカード販売機を利用してユーザ(プレイヤ)が購入することによりそのユーザに所持されるカードであり、そのユーザに関するユーザ情報や、そのユーザのゲーム履歴に関するゲーム履歴情報を含むユーザ関連情報が格納される記憶媒体を備えたカードである。
図5は、ユーザカード31に格納されるユーザ関連情報の例を示す説明図である。図5に示すように、ユーザ関連情報は、ユーザ情報とゲーム履歴情報とを含む情報である。
ユーザ情報は、本例では、各ユーザカードに一意に付与されているカードID、ユーザの性別、誕生日、登録名などを含む情報である。ユーザの性別、誕生日、登録名は、例えば、業務用ゲーム機10を用いて登録される。ユーザ情報に、家族構成などユーザに関するその他の情報が含まれていてもよい。
ゲーム履歴情報は、本例では、最終プレイ年月日、残り保存回数、本例のビデオゲームにおける経験値、一緒にプレイした回数(他のプレイヤ毎に、本例のビデオゲームを2人プレイで一緒にプレイしたそれぞれの回数)、一緒にプレイした人数(本例のビデオゲームを2人プレイで一緒にプレイした他のプレイヤの人数)、ボス撃破回数(ボスキャラクタに勝利した回数)、ランキング入賞回数、大会参加回数、大会勝利回数、COM戦戦績(敵キャラクタが業務用ゲーム機10が制御するノンプレイヤキャラクタであるときの勝敗数)、対戦戦績(敵キャラクタが他のプレイヤが操作するキャラクタであるときの勝敗数)、前回の勝敗、現在の連勝数、最高連勝記録、所持ゲームポイント、累計ゲームポイント、所持オプション、非ボス戦回数(ボスキャラクタ以外の敵キャラクタである非ボスキャラクタと勝負した回数)、ボス撃破フラグなどを含む情報である。本例では、ユーザカード31は、使用回数に上限(例えば400回)が設けられており、残り保存回数は、ユーザカード31にゲーム履歴情報を保存(更新)することが可能な残りの回数を意味する。
次に、業務用ゲーム機10にて実行される「超速変形」について説明する。本例における「超速変形」とは、車両形態でコースを走り終えたプレイヤキャラクタが、戦闘形態(以下「ロボット形態」という。)に変形し、ロボット形態に変形した敵キャラクタとの戦闘を開始するゲームシステムである。以下、プレイヤのチームを構成する3体のプレイヤキャラクタ(それぞれ車両形態とロボット形態とを有するキャラクタであって、適宜「マシン」という。)と、敵チームを構成する3体のマシン(敵は、他のプレイヤであってもよいし、コンピュータであってもよい。以下、敵側のマシンを「敵キャラクタ」または「敵マシン」という。)がバトルマップへ降り立ち、各マシンの技(動作)やチーム全体のEP(エネルギーポイント。0になるとゲームオーバとなるポイント。)など、戦闘(バトル)に関連する情報を表示するまでを「超速変形」または「超速変形処理」という。
業務用ゲーム機10は、超速変形前のゲームモード(車両形態のプレイヤキャラクタが、プレイヤによるステアリングC1の操作に応じて所定のコースを走行するゲームモード。ドライブモード。)と、超速変形後のゲームモード(ロボット形態のプレイヤキャラクタが、プレイヤによるジャイロレバーC2の操作に応じて敵キャラクタとバトルするゲームモード。バトルモード。)とが、異なるゲームモード(特に、ジャンルや使用するコントローラが異なるゲームモード)であることを特徴とする。本例においては、適宜「ドライブモード」を「第1ゲームモード」、「バトルモード」を「第2ゲームモード」と呼び、各モードを区別する。
次に、RAM23に記憶される各種データ(情報)の例について説明する。
本例においては、RAM23は、キャラクタ情報記憶部23aと、第1ゲームモード情報記憶部23bと、第2ゲームモード情報記憶部23cと、プレイヤキャラクタ管理テーブル23dと、入力コマンド管理テーブル23eとを含む。
キャラクタ情報記憶部23aは、少なくとも1種類のキャラクタに関する情報であって、第1ゲームモードにおける各キャラクタの形態と、第2ゲームモードにおける各キャラクタの形態とを示す情報を含むキャラクタ情報を記憶する記憶領域である。
図6は、キャラクタ情報記憶部23aに記憶されるキャラクタ情報の格納状態の例を示す説明図である。図6に示すように、キャラクタ情報は、キャラクタIDと、第1ゲームモードにおけるキャラクタの各種情報と、第2ゲームモードにおけるキャラクタの各種情報とを含む。具体的には、キャラクタ情報は、第1ゲームモードにおけるキャラクタの走行形態(本例においては「車両」のみであるため「車両形態」と呼ぶ。)と、走行性能(ステータス)とを特定するための情報を含む。また、キャラクタ情報は、第2ゲームモードにおけるキャラクタのバトル形態(「戦闘形態」と同義。)と、バトル性能(ステータス)と、ジャイロレバーC2を用いて入力された指示(バトルコマンド)に応じて実行するキャラクタの動作(本例においては、「技」。)とを特定するための情報を含む。なお、本例においては、バトル形態として、ロボット形態、例えば人型のロボット形態が採用されている場合を例にして説明を行う。なお、戦闘形態は人型に限定されず、第1ゲームモードにおける形態と異なる形態であればよい。ただし、動物型や航空機型など、車両形態と操作性が異なることをプレイヤに認識させやすい形態とすることが好ましい。また、車両形態と色等を同じにすることで、車両形態から変形したことをプレイヤに認識させやすい形態とすることが好ましい。
なお、本例においては、車両形態とロボット戦闘形態とを有するキャラクタを用いてビデオゲームが行われる場合を例にして説明を行うが、第1ゲームモードと第2ゲームモードにおける操作対象の形態は同一であってもよく、プレイヤが使用するコントローラやゲーム内容が異なる構成であればよい。
本例では、バトルモードにおいて、プレイヤキャラクタは、ジャイロレバーC2による指示内容に応じて、無難な攻撃として設定された「ノーマルアタック」と、ノーマル攻撃よりも強力な攻撃として設定された「バーストアタック」と、相手側に指示されたのがバーストアタックである場合にのみノーマルアタックよりも強力な攻撃を実行する攻撃として設定された「カウンターアタック」のうち何れかを実行する。なお、本例においては、業務用ゲーム機10を正面から見て右のジャイロレバーを押し込むとノーマルアタック、左のジャイロレバーを押し込むとバーストアタック、両ジャイロレバーを略同時に押し込むとカウンターアタックが実行される構成となっているものとする。
第1ゲームモード情報記憶部23bと、第2ゲームモード情報記憶部23cとは、各ゲームモードを実行するために必要な各種情報を記憶する記憶領域である。なお、「超速変形」に関する情報は、第1ゲームモード情報記憶部23bまたは第2ゲームモード情報記憶部23cの少なくとも一方に記憶されている構成としてもよいし、他の記憶領域に記憶されている構成としてもよい。また、各情報が1つの記憶領域(ゲーム情報記憶部)に記憶されている構成としてもよい。
図7は、第2ゲームモード情報記憶部23cに記憶される第2ゲームモード情報の格納状態の例を示す説明図である。ここでは、ゲーム情報の例として、第2ゲームモード情報に含まれる「技」の相関関係情報を例にして説明を行う。本例において、相関関係情報は、ジャイロレバーC2を用いて入力され得る指示と、敵キャラクタに対して指示される得る内容(敵が他のプレイヤである場合には、他のプレイヤによって入力され得る指示。)との組み合わせに応じて各キャラクタに実行させる動作である「技」の内容を示す情報である。
図7に示すように、相関関係情報は、プレイヤによる指示内容と、敵による指示内容とに応じて、プレイヤキャラクタと敵キャラクタとが実行する「技」の内容が決定される構成となっている。すなわち、例えば、プレイヤが「ノーマルアタック」を指示し、敵(対戦プレイヤまたはコンピュータ)が「ノーマルアタック」を指示した場合、互いのキャラクタがそれぞれ「ノーマルアタック」を行うこととなるが、プレイヤが「カウンターアタック」を指示、敵が「ノーマルアタック」を指示した場合、プレイヤのキャラクタ(すなわち、プレイヤキャラクタ)は「カウンターアタック」や「ノーマルアタック」よりも弱い攻撃を行い(カウンター失敗)、敵のキャラクタのみ「ノーマルアタック」を行うこととなる。また、一方が「カウンターアタック」を指示し、他方が「バーストアタック」を指示した場合、「カウンターアタック」が「バーストブレイク」として実行され、他方の「バーストアタック」は実行されないこととなる(行動不能)。
プレイヤキャラクタ管理テーブル23dは、キャラクタ情報の中からプレイヤに操作されるキャラクタとして特定されたキャラクタ(プレイヤキャラクタ)に関する情報が登録される記憶領域である。業務用ゲーム機10は、プレイヤキャラクタ管理テーブル23dに登録されたキャラクタ情報を、ビデオゲームの進行に応じて適宜更新する。
入力コマンド管理テーブル23eは、各コントローラを用いて入力された指示(入力コマンド)が登録される記憶領域である。本例においては、バトルモードに、入力コマンド管理テーブル23eに登録された入力コマンドに応じて、その後のゲーム展開が決定されることとなる。バトルモード時に実行される処理については、後で詳しく説明する(図13,14参照。)。
次に、本例の業務用ゲーム機10の動作について説明する。
図8は、業務用ゲーム機10が実行するゲーム処理の例を示すフローチャートである。ゲーム処理は、コイン投入口14からコインが投入されたことをコイン投入センサ14Sにより検出すると開始される。本例では、ゲーム処理が開始される前に、ユーザカード挿入口にユーザカード31が挿入されているものとする。所定のタイミングでユーザカード31の挿入を促す案内を行い、ユーザ関連情報を必要とするときまでにユーザカード挿入口にユーザカード31を挿入させるようにしてもよい。本例におけるゲーム処理では、プレイヤX(ユーザX)の操作対象となるプレイヤキャラクタを決定してからゲームを終了するまでの処理が実行される。なお、本発明に関係しない処理については、その内容を省略している場合がある。
CPU21は、先ず、カード排出部15Dを制御し、カードスタッカに積まれたゲームカード30を一枚排出する(ステップS101)。
次に、CPU21は、画像処理部24に指示を送り、手持ちのゲームカード30をゲームカード挿入口17に挿入することをプレイヤXに指示する画面(ゲームカード挿入指示画面)を表示部25に表示させる(ステップS102)。
プレイヤXによりカード30がカード挿入口に挿入されると、CPU21は、ゲームカード30に記載されたコードデータをスキャナ17aに読み取らせる(ステップS103)。
コードデータを読み取らせると、CPU21は、ゲームカードがメインキャラクタを示すカードであるか否かを判定する(ステップS104)。ここで、例えばコードデータがアイテムを示している場合、CPU21は、メインキャラクタを示すゲームカードでないと判定し(ステップS104のN)、ステップS102の処理に移行する。なお、このとき、CPU21が、所定の規則に従って、キャラクタ情報記憶部23aに記憶されたキャラクタ情報の中からメインキャラクタとするキャラクタの情報(メインキャラクタ情報)を決定し、後述するステップS109の処理に移行する構成としてもよい。
一方、コードデータがキャラクタを示している場合、CPU21は、メインキャラクタを示すカードであると判定し(ステップS104のY)、画像処理部24に指示を送り、サブキャラクタを示すゲームカードの挿入指示画面を表示部25に表示させる(ステップS105)。
次いで、CPU21は、ゲームカードの挿入を受け付けたか否かを判定する(ステップS106)。ここで、例えばプレイヤXによるゲームカードを挿入しない旨の選択操作を受け付けたことによりゲームカードの挿入を受け付けていないと判定すると(ステップS106のN)、CPU21は、「レンタカーを支給する処理」として予め設定された処理を実行する(ステップS107)。具体的には、CPU21は、所定の規則に従って、キャラクタ情報記憶部23aに記憶されたキャラクタ情報の中からサブキャラクタとするキャラクタの情報(サブキャラクタ情報)を決定し、後述するステップS109の処理に移行する。なお、メインキャラクタについても上記と同様にして「レンタカーを支給する処理」を行うようにしてもよい。この場合、メインキャラクタとしてレンタカーを支給した場合には、サブキャラクタについても自動的にレンタカーが支給されるようにすればよい。
一方、ゲームカードの挿入を受け付けたと判定すると(ステップS106のY)、CPU21は、挿入されたゲームカードがサブキャラクタを示すゲームカードであるか否かを判定する(ステップS108)。ここで、挿入されたゲームカードがサブキャラクタを示していないと判定すると(ステップS108のN)、CPU21は、ステップS105の処理に移行する。
一方、例えば挿入されたゲームカードがメインキャラクタと異なるキャラクタを示していることにより、挿入されたゲームカードがサブキャラクタを示していると判定すると(ステップS108のY)、CPU21は、メインキャラクタを示す情報(メインキャラクタ情報)とサブキャラクタ情報とを、キャラクタ情報記憶部23aから読み出して、プレイヤキャラクタ管理テーブルに登録する(ステップS109)。すなわち、本例のビデオゲームにおいてプレイヤX側のキャラクタとして用いられるメインキャラクタとサブキャラクタとが決定され、そのメインキャラクタを示す情報とサブキャラクタを示す情報とがプレイヤキャラクタ管理テーブルに登録される。なお、サブキャラクタは使用されない構成としてもよいし、複数のサブキャラクタが使用される構成としてもよい。
キャラクタ情報を登録すると、CPU21は、ユーザカード挿入口に挿入されているユーザカード31に記憶されているユーザ関連情報をカードリーダライタ17bに読み取らせ、読み取られたユーザ関連情報に基づいて、所定のステータス更新ルールに従って、プレイヤキャラクタ管理テーブルに登録されているキャラクタのステータスを更新する(ステップS110)。ステータス更新ルールには、例えば、経験値に応じて所定のステータス(例えば、加速性能、グリップ性能など)を所定ポイント加算するといったルールや、ボス撃破回数が所定回数以上である場合に所定のステータスを所定ポイント加算するといったルールや、二人プレイである場合に相手プレイヤと過去に一緒にプレイした回数が所定回数以上である場合に所定のステータスを所定ポイント加算するといったルールなど、様々なルールが考えられる。
キャラクタのステータスを更新すると、CPU21は、第1ゲームモードによりビデオゲームの進行を制御する第1ゲームモード処理を開始する(ステップS200)。
図9は、本例の業務用ゲーム機10が実行する第1ゲームモード処理の例を示すフローチャートである。第1ゲームモード処理では、第1コントローラを用いて入力された指示に従って第1ゲームモードにおけるビデオゲームの進行を制御するための処理が行われる。なお、本発明に関係しない処理については、その内容を省略している場合がある。
第1ゲームモード処理を開始すると、CPU21は、第1ゲームモード情報記憶部23bを参照して、参戦キャラクタ登場演出(参戦マシン登場演出)を実行するための処理を行う(ステップS201)。本例においては、CPU21は、画像処理部24に指示を送り、プレイヤキャラクタ管理テーブル23dに登録されたキャラクタ情報が示すプレイヤキャラクタを含むゲーム画面(第1ゲームモード画面)を表示部25に表示させる処理等を行う。
次いで、CPU21は、画像処理部24に指示を送り、車両形態のプレイヤキャラクタが走行することとなるコースに関する情報を表示するコース情報表示画面を表示部25に表示させる(ステップS202)。
コース情報表示画面を表示させると、CPU21は、ステアリングC1を用いて入力された指示に従って第1ゲームモードにおけるビデオゲームの進行を制御する(ステップS203)。本例においては、CPU21は、ステアリングC1の回転角度により車両形態のメインキャラクタの進行方向を含むコース状況に応じた動作(例えば、ドリフト等)を表示する。なお、本例においては、メインキャラクタ(メインマシン)がプレイヤによる指示によらずに加速するように制御され、CPU21は、シフトレバー18操作による減速やブースト(超加速)操作などに応じて、メインキャラクタの速度を決定する。なお、サブキャラクタは、第1ゲームモードによるビデオゲームが進行しているときのゲーム画面には表れない(図10参照)。メインキャラクタの競争相手としては、CPU21によって制御される敵マシンが存在する。
図10は、第1ゲームモードによるビデオゲームが進行しているときのゲーム画面(第1ゲーム画面)の例について説明するための説明図である。図10に示すように、第1ゲーム画面には、コースに配置されたボーナスアイテムBI(以下「アイテム」という。)と、プレイヤXによるアイテムの取得数を示すアイテム取得数表示領域101と、スタートしてからの経過時間を表示するタイム表示領域102とコース概形表示領域103と、エンジン回転数とギア数とを表示する表示領域104と、走行スピードを表示する表示領域106とが設けられている。なお、本例においては、EP表示領域105では、合計EPがゲージ形式(ゲージ内のメータの増減でEPの量を示す形式)で表示される。
第1ゲームモードの進行を制御するのと併せて、CPU21は、第2ゲームモードへの移行条件が充足されたか否かを判定する(ステップS204)。ここで、予め設定された移行条件が充足されていないと判定するまでは(ステップS204のN)、CPU21は、第1ゲームモードでのゲーム進行を継続する。ここで、本例においては、第2ゲームモードへの移行条件(第2ゲームモード移行条件)としては、「プレイヤキャラクタがコースを走り終えることと、プレイヤキャラクタが走行を開始してから所定時間が経過することとの、何れか一方が満たされること」が設定されているものとする。なお、第2ゲームモード移行条件はこれに限定されず、例えば、第1ゲームモードにおけるビデオゲームの進行に依らない条件(例えば、「所定の強制終了ボタンが押下されること」や、「ゲーム開始から特定時間が経過すること」など)であってもよい。すなわち、CPU21が、第1ゲームモードにおける制御結果に依らず、独立して条件判定を行う構成とされていてもよい。また、本例においては、第2ゲームモードへの移行条件は、第1ゲームモード情報として第1ゲームモード情報記憶部23bに記憶されているものとする。
一方、例えばプレイヤキャラクタがコースの走行を終えたことにより、第2ゲームモードへの移行条件が充足されたと判定すると(ステップS204のY)、CPU21は、第1ゲームモードにおけるプレイ内容の評価(第1ゲームモード評価)を算出する(ステップS205)。本例においては、CPU21は、コースのクリアタイムや獲得したアイテム数などを用いた所定の算出式を用いて、第1ゲームモード評価としての数値を算出する。なお、CPU21は、算出した第1ゲームモード評価を、プレイヤキャラクタ管理テーブル23dに登録する。
次いで、CPU21は、ゲームモードを第1ゲームモードから第2ゲームモードに移行するためにゲームモード移行処理を実行する(ステップS300)。
図11は、本例の業務用ゲーム機10が実行するゲームモード移行処理の例を示すフローチャートである。なお、本発明に関係しない処理については、その内容を省略している場合がある。
ゲームモード移行処理を開始すると、CPU21は、プレイヤXに対して、進行中のゲームモードを移行するための操作であるゲームモード移行操作の内容を報知する(ステップS301)。本例においては、CPU21は、例えば、「ステアリングを押し上げて超速変形するのだ」というアナウンスを音声出力する。なお、報知方法は特に限定されず、例えば、ゲームモード移行操作の内容を報知する画面を表示部25に表示する構成としてもよい。
ゲームモード移行操作の内容を報知すると、CPU21は、ゲームモード移行操作を受け付けたか否か(または、検出したか否か)を判定する(ステップS302)。ここで、ステアリング型コントローラ駆動部CD1からの通知によりゲームモード移行操作を受け付けたと判定すると(ステップS302のY)、CPU21は、画像処理部24に指示を送り、ゲームモードの移行をプレイヤXに報知するための移行演出画面を表示部25に表示させる(ステップS303)。
移行演出画面を表示させると、CPU21は、レバー型コントローラ駆動部CD2に指示を送り、第2コントローラ(レバー型コントローラ、ジャイロレバー)C2を特定の位置に移動させる(ステップS304)。
そして、第2コントローラの移動が完了したと判定すると(ステップS305のY)、CPU21は、第2ゲームモードによりビデオゲームの進行を制御する第2ゲームモード処理を開始する(ステップS400)。なお、本例においては、CPU21は、第2コントローラが特定の位置に移動し、固定された旨の通知を第2コントローラ駆動部CD2から受け付けた場合に、第2コントローラの移動が完了したと判定する。
図12は、本例の業務用ゲーム機10が実行する第2ゲームモード処理の例を示すフローチャートである。第2ゲームモード処理では、第1コントローラとは異なる第2コントローラを用いて入力された指示に従って第2ゲームモードにおけるビデオゲームの進行を制御するための処理が行われる。なお、本発明に関係しない処理については、その内容を省略している場合がある。
第2ゲームモード処理において、CPU21は、先ず、ユーザカード挿入口に挿入されているユーザカード31に記憶されているユーザ関連情報をカードリーダライタ17bに読み取らせ、読み取られたユーザ関連情報に基づいて、所定の敵キャラクタタイプ決定ルールに従って、敵キャラクタのタイプ(ボスキャラクタ、または非ボスキャラクタ)を決定する(ステップS401)。敵キャラクタタイプ決定ルールには、例えば、ボス撃破フラグがオフである場合に所定確率でボスキャラクタとするといったルール、非ボス戦回数が所定回数以下であるときには高確率でボスキャラクタとすることに決定して非ボス戦回数が所定回数を超えている場合には低確率でボスキャラクタとすることに決定するといったルール、ボス撃破回数が所定回数以下であるときには高確率でボスキャラクタとすることに決定してボス撃破回数が所定回数を超えている場合には低確率でボスキャラクタとすることに決定するといったルールなど、様々なルールが考えられる。なお、敵キャラクタのタイプの決定は、第2ゲームモード処理時でなく第1ゲームモード処理時(例えばステップS205の処理時)に行うようにしてもよい。また、敵キャラクタのタイプを決定する際の確率を定める際に、第1ゲームモードでの評価を加味するようにしてもよい。
次に、CPU21は、第1ゲームモード評価による第2ゲームモードへの影響内容を特定する(ステップS402)。本例においては、CPU21は、第2ゲームモード情報記憶部23cに記憶された規則に従い、キャラクタのステータスの変更値を特定する。
影響内容を特定すると、CPU21は、特定した影響内容に従ってバトル関連情報を更新する(ステップS403)。ここで、「バトル関連情報」とは、戦闘形態のプレイヤキャラクタと敵キャラクタとの戦闘に関連する情報であり、例えば、各キャラクタの攻撃力やEPなどが含まれる。本例においては、CPU21は、アイテムボーナスとしてプレイヤキャラクタのステータスを上昇させるために、プレイヤキャラクタ管理テーブル23dに登録された情報を更新する。これにより、CPU21は、第1ゲームモードにおけるビデオゲームの進行結果を第2ゲームモードにおけるビデオゲームの進行に反映させる。
バトル関連情報を更新すると、CPU21は、画像処理部24に指示を送り、バトル関連情報をプレイヤXに提示するバトル関連情報表示画面を表示部25に表示させる(ステップS404)。
バトル関連情報表示画面を表示させると、例えば所定時間の経過に応じて、CPU21は、画像処理部24に指示を送り、プレイヤXにコマンドの入力を促すコマンド入力画面を表示部25に表示させる(ステップS405)。
図13は、コマンド入力画面の例について説明するための説明図である。図13に示すように、コマンド入力画面には、コマンドの入力対象(すなわち、実行させる「技」の設定対象)となるプレイヤキャラクタ(メインキャラクタPC1と2体のサブキャラクタPC2,PC3)と、敵キャラクタNPC1,NPC2,NPC3と、プレイヤキャラクタ(メインキャラクタPC1と2体のサブキャラクタPC2,PC3)の合計EPをゲージ形式(ゲージ内のメータの増減でEPの量を示す形式)で表示するEP表示領域105と、敵キャラクタのエンジンメーターを表示する敵エンジンメーター表示領域201と、敵キャラクタ全員の合計EPをゲージ形式で表示する敵EP表示領域202と、バトルターン数を表示するバトルターン数表示領域とが設けられている。ここで「バトルターン」とは、コマンド入力後に実行される技シーケンスの回数であり、バトルターン数が「1」の場合、これがバトルにおいて最初のコマンド入力であることを意味する。
コマンド入力画面を表示させると、CPU21は、ゲームカードの挿入を受け付けたか否かを判定する(ステップS406)。ここで、ゲームカードの挿入を受け付けていないと判定すると(ステップS406のN)、CPU21は、後述するステップS409の処理に移行する。
一方、ゲームカードの挿入を受け付けたと判定すると(ステップS406のY)、CPU21は、受け付けたゲームカードが、バトルを補助する効果が設定されたスペシャルカードであるか否かを判定する(ステップS407)。ここで、受け付けたゲームカードがスペシャルカードでないと判定すると(ステップS407のN)、CPU21は、無効と判定し、ステップS406の処理に移行する。
一方、受け付けたゲームカードがスペシャルカードであると判定すると(ステップS407のY)、CPU21は、スペシャルカードに応じた内容を入力コマンド管理テーブル23eに登録する(ステップS408)。なお、本例においては、CPU21は、スペシャルカードが挿入された後、トリガーC3が引かれたことに応じて、挿入されたスペシャルカードに応じた内容を入力コマンド管理テーブル23eに登録する。また、業務用ゲーム機10を1台使用して2人のプレイヤがビデオゲームを行う場合、CPU21は、引かれたトリガーC3に対応するプレイヤの入力コマンド管理テーブル23eに、挿入されたスペシャルカードに応じた内容を登録するものとする。
次いで、CPU21は、第2コントローラC2を用いたコマンドの入力を受け付けたか否かを判定する(ステップS409)。ここで、第2コントローラC2を用いたコマンドの入力(すなわち、プレイヤXによる指示)を受け付けたと判定すると(ステップS409のY)、CPU21は、プレイヤキャラクタ管理テーブル23dを参照して、受け付けたコマンドに応じた「技」を入力コマンド管理テーブル23eに登録する(ステップS410)。
入力コマンド管理テーブル23eに「技」を登録すると、CPU21は、各キャラクタに「技」が登録されたか否かを判定する(ステップS411)。すなわち、CPU21は、プレイヤキャラクタと敵キャラクタに対して「技」が登録されたか否かを判定する。ここで、各キャラクタに「技」が登録されていないと判定すると(ステップS411のN)、CPU21は、ステップS405の処理に移行する。なお、本例においては、「技」が登録されていないキャラクタに応じてコマンド入力画面の内容が更新されるものとする。すなわち、コマンド入力画面では、例えば、「技」が登録されていないプレイヤキャラクタが識別可能に表示されるものとする。
一方、各キャラクタに「技」が登録されたと判定すると(ステップS411のY)、CPU21は、入力されたコマンドに応じたキャラクタ間の戦闘を実現するバトル処理を開始する(ステップS500)。
図14は、本例の業務用ゲーム機10が実行するバトル処理の例を示すフローチャートである。なお、本発明に関係しない処理については、その内容を省略している場合がある。
バトル処理において、CPU21は、先ず、キャラクタ情報に基づいて決定される行動順序に応じて、プレイヤキャラクタと敵キャラクタとの組合せを決定する(ステップS501)。本例においては、CPU21は、バトルに参加する全キャラクタのスピードに乱数を加えた所定の方法で各キャラクタの行動順序を決定し、その後に、行動順序の近いプレイヤキャラクタと敵キャラクタとを組み合わせる。なお、対戦相手は予め決められていてもよい。ステップS501では、CPU21は、上述したステップS401にて決定したタイプの敵キャラクタを決定する。
キャラクタの組み合わせを決定すると、CPU21は、相関関係情報に基づいて(図7参照)、入力コマンドコマンド管理テーブル23eを更新する(ステップS502)。
相関関係情報に基づいて入力コマンドコマンド管理テーブル23eを更新すると(すなわち、各キャラクタの組み合わせに応じて実行される「技」を決定すると)、CPU21は、画像処理部24に指示を送り、キャラクタの組合せを示す組み合わせ表示画面を表示部25に表示させる(ステップS503)。なお、ステップS503は、スペシャルカードの処理(ステップS504〜S506)のあとに行うようにしてもよい。
次いで、CPU21は、プレイヤまたは敵の入力コマンド管理テーブル23eにスペシャルカードに応じた内容が登録されているか否かを判定する(ステップS504)。ここで、スペシャルカードに応じた内容が登録されていると判定すると(ステップS504のY)、CPU21は、登録された内容に従った処理(スペシャルカードに応じた内容)を実行し(ステップS505)、後述するステップS507の処理に移行する。
一方、スペシャルカードに応じた内容が登録されていないと判定すると(ステップS504のN)、CPU21は、入力コマンドコマンド管理テーブル23eを参照し、行動順序に従って各キャラクタの「技」を実行する(ステップS506)。
そして、1のキャラクタの「技」の実行後、または全員の「技」の実行後に、CPU21は、プレイヤか敵のどちらかのEPが0になったか否かを判定する(ステップS507)。ここで、どちらのEPも0になっていないと判定すると(ステップS507のN)、CPU21は、第2ゲームモード処理におけるステップS404の処理に移行する。
一方、どちらかのEPが0になったと判定すると(ステップS507のY)、CPU21は、予め設定された算定基準に基づいて、第2ゲームモードにおけるプレイヤの評価(第2ゲームモード評価)を算出する(ステップS508)。
第2ゲームモード評価を算出すると、CPU21は、第1ゲームモード評価と第2ゲームモード評価とに応じた経験値を今回のゲームの実行前の経験値に加算した値を新たな経験値としてカードリーダライタ17bに書き込ませ、ユーザカード挿入口に挿入されているユーザカード31に付与する(ステップS509)。すなわち、CPU21は、ユーザカード31に記憶されている今回のゲームの実行前の経験値に、今回のゲームの実行によって得られた経験値を加算する処理を行う。なお、経験値は、例えば、キャラクタ毎に付与されるものとする。
また、同様に、CPU21は、ユーザ関連情報における経験値以外の所定の項目の情報をゲームの内容に応じて更新する処理を行う(ステップS510)。ステップS510では、最終プレイ年月日の更新、残り保存回数の更新、前回の勝敗の更新など、ゲーム履歴情報のうち該当項目を更新する処理が行われる。なお、ステップS509〜S510の処理は、ステップS511のあとに行うようにしてもよい。
ユーザカード31の登録情報を更新すると、CPU21は、画像処理部24に指示を送り、第2ゲームモード評価を含むバトル結果表示画面を表示部25に表示させる(ステップS511)。
バトル結果表示画面を表示させると、CPU21は、ゲーム処理におけるステップS111の処理に移行する(図8参照)。ゲーム処理におけるステップS111の処理では、CPU21は、ゲームを終了するか否かを判定する(ステップS111)。ゲームの終了判定方法は特に限定されず、例えば、CPU21が、画像処理部24に指示を送り、プレイヤの意思を確認するためのコンテニュー画面を表示部25に表示させる構成としてもよい。
上記の例では、業務用ゲーム機10を例に説明していたが、そのゲームの内容を、家庭用のゲーム装置、携帯用のゲーム装置などの他のビデオゲーム処理装置に適用することも可能である。
以上に説明したように、上述した一実施の形態では、プレイヤが操作する操作対象(例えば、プレイヤキャラクタ)を表示画面に表示して、敵キャラクタとの対戦を含むビデオゲームの進行を制御するビデオゲーム処理装置(例えば、業務用ゲーム機10)が、ビデオゲームにおけるゲームモードである第1ゲームモード(例えば、ドライブモード)と、ビデオゲームにおける第1ゲームモードとは異なるゲームモードである第2ゲームモード(例えば、バトルモード)とに関するゲーム情報を記憶するゲーム情報記憶部(例えば、第1ゲームモード情報記憶部23bと第2ゲームモード情報記憶部23c)と、少なくとも1種類の操作対象(例えば、キャラクタ)に関する情報であって、第1ゲームモードにおける形態(例えば、走行形態)と、第2ゲームモードにおける形態(例えば、バトル形態)とを示す情報を含む操作対象情報を記憶する操作対象情報記憶部(例えば、キャラクタ情報記憶部23a)とを備え、操作対象の識別情報を含むゲームカード情報の入力を受け付け、受け付けたゲームカード情報に基づいて、操作対象情報の中から所定数の操作対象情報が示す操作対象(例えば、1体のメインキャラクタと2体のサブキャラクタ)を各ゲームモードにおけるプレイヤの操作対象として特定(例えば、キャラクタ情報をプレイヤキャラクタ管理テーブル23dに登録することにより特定)し、プレイヤに関する情報であるユーザ情報とそのプレイヤによるビデオゲームの過去の実行履歴に関する履歴情報(ゲーム履歴情報)とを含むユーザ関連情報が記憶されたユーザカード31からユーザ関連情報を読み取り、読み取ったユーザ関連情報に基づいて、特定した操作対象のステータスを更新する構成としたので、バリエーションに富んだ対戦型のビデオゲームであって、プレイヤの興味を持続させることができるビデオゲームを提供することができるようになる。
すなわち、ユーザカード31に記憶されたユーザ関連情報に基づいて操作対象のステータスを更新する構成としているので、ユーザ情報やゲーム履歴情報を用いてステータスを更新することができ、ユーザ関連情報を利用してユーザ毎にバリエーションに富んだビデオゲームを提供することが可能となる。特に、ユーザカード31に記憶されたユーザ関連情報を用いる構成としているので、通信ネットワークを介した通信処理を行う必要がなく、各所に設置されているビデオゲーム処理装置(例えば、業務用ゲーム機10)にて簡単かつ迅速にバリエーションに富んだビデオゲームを提供することが可能となる。
また、上述した一実施の形態では、ビデオゲーム処理装置(例えば、業務用ゲーム機10)が、ビデオゲームのゲーム内容を示すゲーム内容情報(ゲームの実行回数、二人プレイの場合の相手プレイヤ、勝敗の別、ボスキャラクタとの対戦であったか否かなど、ゲームの内容に関する各種の情報)に従って、ユーザカード31に記憶されているユーザ関連情報を更新する構成としているので、ユーザカード31内のユーザ関連情報を最新の情報としておくことができ、次回のゲームの際に最新の情報を利用することができるようになる。
また、上述した一実施の形態では、ビデオゲーム処理装置(例えば、業務用ゲーム機10)が、プレイヤからのゲーム開始要求(例えば、コインの投入)を受け付け、ゲーム開始要求が受け付けられたことに応じて、第1コントローラ(例えば、ステアリング型コントローラC1)を用いて入力された指示に従って第1ゲームモードにおけるビデオゲームの進行を制御し、所定条件(例えば、第2ゲームモード移行条件)が満たされたか否かを判定し(例えば、ステップS204)、所定条件が満たされたと判定されたことに応じて、プレイヤXに対し、ゲームモードを移行する操作として設定された操作であるゲームモード移行操作を促し(例えば、ステップS301)、プレイヤXによるゲームモード移行操作を受け付け、ゲームモード移行操作が受け付けられたことに応じて、収納状態の第2コントローラ(例えば、レバー型コントローラC2)を露出状態に移動させ、第2コントローラが露出状態に移動させられたことに応じて、第2コントローラを用いて入力された指示に従って第2ゲームモード(例えば、バトルモード)におけるビデオゲームの進行を制御する構成としたので、さらにバリエーションに富んだ対戦型のビデオゲームであって、さらにプレイヤの興味を持続させることができるビデオゲームを提供することができるようになる。
すなわち、単に2つのバトルモードをプレイすることができるようにするだけでなく、それぞれ異なるコントローラを使用させるため、プレイヤの興味を持続させるのに有効である。また、ゲームモード移行操作としてプレイヤ自身に体を動かす機会を与えることができるため、プレイヤの気分を効果的に転換させることができるようになる。なお、「所定条件」が、第1ゲームモードにおける制御結果に関わる条件である構成としてもよい。このような構成とすることにより、複数のゲームモード間の関連性を強めることができるようになる。
また、上述した一実施の形態では、ゲームモード移行操作は、第1コントローラ(例えば、ステアリング型コントローラC1)の位置を、第2コントローラ(例えば、レバー型コントローラC2)を操作する際に邪魔にならない所定の退避位置に移動させる操作である構成としたので、複数のコントローラを配置することにより各コントローラの操作性が低下することを防止することができるようになる。また、業務用ゲーム機の外観設計の自由度を向上させることができるようになる。
また、上述した一実施の形態では、ビデオゲーム処理装置(例えば業務用ゲーム機10)において、第1コントローラはステアリング形状であり、第1ゲームモードは、プレイヤが車両を操作するドライブモードであり、第2コントローラはトリガーを備えたレバー形状であり、第2ゲームモードは、プレイヤがロボットを操作して敵キャラクタとの戦闘を行うバトルモードである構成としているので、一個の筐体で複数のジャンルのビデオゲームをプレイ可能なゲーム機を提供することができるようになる。すなわち、従来、特にアーケードゲーム機の分野では、ゲームのジャンルによって使用するコントローラが異なることが一般的であり、使い勝手良く一体化させることが困難であるという課題があったが、複数のコントローラの配置を変更可能な構成とすることにより、このような課題を解決することができている。
また、上述した一実施の形態では、ビデオゲーム処理装置(例えば業務用ゲーム機10)が、特定したプレイヤXの操作対象を各ゲームモードに応じた形態で表示画面に表示し、第1ゲームモードにおけるビデオゲームの進行結果(例えば、第1ゲームモード評価)を第2ゲームモードにおけるビデオゲームの進行に反映させる(例えば、ステップS402)構成としているので、異なるゲームモード間に関連を持たせることができるようになり、ゲームの趣向性を向上させることができるようになる。
また、上述した一実施の形態では、ゲーム情報(例えば、第2ゲームモード情報)が、第2ゲームモードにおいて第2コントローラを用いて入力され得る指示と、敵キャラクタに対して指示され得る内容との組み合わせに応じて実行すべき処理の内容を示す情報である相関関係情報を含み(図7参照)、ビデオゲーム処理装置(例えば業務用ゲーム機10)が、相関関係情報を参照して、第2コントローラを用いて入力された指示に応じて実行する処理内容を決定する(例えば、ステップS502)構成としているので、プレイヤに敵との手の読みあいを楽しませることができるようになる。
また、上述した一実施の形態では、ビデオゲーム処理装置(例えば業務用ゲーム機10)が、カードリーダライタ17bによって読み取られたユーザ関連情報に基づいて、敵キャラクタをボスキャラクタとするか非ボスキャラクタとするか決定する構成としているので、ユーザカード31に記憶されたユーザ関連情報を利用したバリエーションに富んだ対戦型のビデオゲームを提供することが可能となる。
また、上述した一実施の形態において、ビデオゲーム処理装置(例えば業務用ゲーム機10)が、ユーザ関連情報が示すビデオゲームの経験値、ビデオゲームにおいて取得可能なゲームポイント、及び他のプレイヤと同時プレイした回数により特定される同時プレイポイント(一緒にプレイした回数)のうち少なくとも何れか1つに基づいて、操作対象のステータスを更新する構成とした場合には、ユーザ関連情報が示すビデオゲームの経験値、ビデオゲームにおいて取得可能なゲームポイント、あるいは他のプレイヤと同時プレイした回数により特定される同時プレイポイントを利用したバリエーションに富んだ対戦型のビデオゲームを提供することが可能となる。
なお、上述した実施の形態では特に言及していないが、ビデオゲーム処理装置(例えば業務用ゲーム機10)が、バトル処理(図14参照)において、技シーケンス中の(例えば、ステップS505における技の実行中。)のヒットの瞬間などにタイミングよくジャイロレバーC2またはトリガーC3の操作を受け付けると、バーストパワーゲージ増加ボーナスをプレイヤに付与する構成としてもよい。また、このような構成とする場合に、ノーマルアタックの場合は、複数回のトリガータイミングが設定されている構成としてもよい。
なお、上述した実施の形態では、ビデオゲーム処理装置(例えば業務用ゲーム機10)は、自己が備える記憶装置(ROM22)に記憶されている制御プログラム(ビデオゲーム処理プログラム)に従って、上述した各種の処理を実行する。