WO2006022080A1

WO2006022080A1 - ゲーム装置

Info

Publication number: WO2006022080A1
Application number: PCT/JP2005/012054
Authority: WO
Inventors: Kenji Kobayashi; Masaru Nakamura; Ryuta Tamura; Jun Wakita; Yukizumi Terao
Original assignee: Konami Digital Entertainment Co., Ltd.
Priority date: 2004-08-25
Filing date: 2005-06-30
Publication date: 2006-03-02
Also published as: KR100939419B1; HK1105907A1; EP1782867B1; EP1782867A4; CA2573136A1; KR20070046938A; KR100885107B1; JP3771245B2; TWI315208B; KR20080091289A; CN101005883B; TWI272114B; TW200611742A; EP1782867A1; TW200706223A; CN101005883A; JP2006061242A

Abstract

　少なくとも３つのゲーム装置（２Ａ～２Ｄ）を用いてゲームシステムを構築する。ゲーム装置（２Ａ～２Ｄ）は、プログラムを実行してプレイヤーにゲームをプレイさせるものであり、そのプロセッサ（２１）はゲームに参加する２以上のゲーム装置（２Ａ～２Ｄ）を特定してゲームを開始する。また、プロセッサ（２１）はプレイ中のゲームの進行に応じたゲーム情報（スコア情報および攻撃識別子）を生成し、通信インターフェイス（２２）を用いて、上記２以上のゲーム装置（２Ａ～２Ｄ）の各々に生成したゲーム情報を送信する一方、２以上の他のゲーム装置（２Ａ～２Ｄ）の各々で生成されたゲーム情報を受信して、受信したゲーム情報に応じてゲームの状況を変化させる。

Description

明細書

ゲーム装置

技術分野

[0001] 本発明は、ネットワーク型のゲームシステムに用いられるゲーム装置に関する。

背景技術

[0002] 特開 2004— 081809号公報に記載のゲームシステムでは、ゲーム装置（ゲーム端末）の各々は、ゲーム中に、ネットワーク経由で、このゲーム装置自身の情報をサーバ装置 (ゲームサーバ）へ送信し、このサーバ装置力他のプレイヤーの情報を受信する。また、特開 2004— 081809号公報には、サーバ装置の機能を 1又は複数のゲーム装置に担わせるようにしてもよい旨の記載がある。つまり、特開 2004— 081809 号公報には、ネットワークゲームシステムにおいて、 1つのサーバ装置又はゲーム装置をマスターとし、残りのゲーム装置をスレーブとしたマスター Zスレーブ通信方式を行うことが開示されている。

発明の開示

発明が解決しょうとする課題

[0003] ところで、マスター Zスレーブ通信方式のゲームシステムでは、ゲーム中にマスターが通信不能となると、全てのゲーム装置間で情報の授受が不可能となる。したがって、全てのゲーム装置においてゲームの続行が不能となる。つまり、 1つの装置が通信不能となることによって全てのゲーム装置にぉ、てゲームが中断されると、う事態が生じ得る。

本発明は上述した問題に鑑みてなされたものであり、上述の事態が生じ得ないゲームシステムを構築することができるゲーム装置を提供することを目的とする。

課題を解決するための手段

[0004] 以下、本発明について説明する。なお、本発明の理解を容易にするために添付図面の参照符号を括弧書きにて付記するが、それにより本発明が図示の形態に限定されるものではない。

[0005] 本発明に係るゲーム装置（2B)は、他のゲーム装置（2A, 2C、 2D)と通信する通信部（21、 22)と、ゲームプログラムを実行してプレイヤーがゲームをプレイすることを可能にするゲームプログラム実行部（21)と、ゲームの参加者となる 2以上の前記他のゲーム装置（2A、 2C)を特定して、前記ゲームプログラム実行部（21)にゲームを開始させる制御部（21、 SC1〜SC5)と、プレイ中のゲームの進行に応じてゲーム情報を生成し、前記通信部（21、 22)を用いて、前記 2以上の他のゲーム装置の各々に生成した前記ゲーム情報を送信するゲーム情報生成部（21、 SC8、 SJ1〜SJ11) と、前記通信部（21、 22)を用いて、前記 2以上の他のゲーム装置の各々で生成されたゲーム情報を受信して、受信した前記ゲーム情報に応じてゲームの進行を変化させる変化部（21、 SC8、 SK1〜SK7)と、を備える。

[0006] このゲーム装置を 3つ以上用いてゲームシステムを構築すれば、いずれか 1つのゲーム装置が通信不能となっても他のゲーム装置間で相互にゲーム情報を送受信することができる。マスターがスレーブに対して指示を送るマスター Zスレーブ通信方式では、マスターが通信不能になると残りの 2つ以上のゲーム装置が正常であってもゲーム情報の送受信が不能になるが、このゲーム装置によれば、 1つのゲーム装置が通信不能となっても残りの 2つ以上のゲーム装置においてゲームを続行することができる。

[0007] また、上述したゲーム装置において、前記制御部（21、 SC1〜SC5)は、このゲーム装置自身がマスターとなるべき力スレーブになるべきかを所定の判定条件に基づいて判定する判定部（21、 SC2、 SC3)と、ゲームに参加する他のゲーム装置（2A、 2C)の通信アドレスを記憶する記憶部（27)と、前記判定部（21、 SC2、 SC3)によつてこのゲーム装置自身がマスターであると判定された場合、スレーブとなるべき他のゲーム装置（2A, 2C、 2D)力ものゲーム参カ卩要求を待ち、前記ゲーム参加要求を受信すると、参加者の人数が所定数に達しない限りゲーム参加を許可することを示す応答を返信し、スレーブとなるべき前記 2以上の他のゲーム装置（2A、 2C)の通信ァドレスを前記記憶部（27)に記憶させ、前記スレーブとなるべき他のゲーム装置の各々に対して他のスレーブとなるべきゲーム装置の通信アドレスを送信するマスター機能実行部（21、 SC4)と、前記判定部（21、 SC2、 SC3)によってこのゲーム装置自身がスレーブであると判定された場合、マスターの候補であるゲーム装置に対してゲーム参カ卩要求を送信し、マスターとなるべきゲーム装置力もゲーム参カ卩を許可することを示す応答を受信すると、マスターとなるべきゲーム装置から取得した他のスレーブとなるべきゲーム装置の通信アドレスとマスターとなるべきゲーム装置の通信アドレスとを前記記憶部（27)に記憶させるスレーブ機能実行部（21、 SC5)とを備えることが好ましい。さらに、前記ゲーム情報生成部（21、 SC8、 SJ1〜SJ11)は、前記記憶部（27)に記憶された通信アドレスを用いて、前記 2以上の他のゲーム装置（2A、 2C )の各々に前記ゲーム情報を送信する。

[0008] この発明によれば、同じゲームに参加する複数のゲーム装置を特定する参加者グルービング処理 (エントリー期間）にあっては、マスター Zスレーブ方式を採用することにより、ゲームの参加者のグルーピングをゲーム装置がで行うことができる。多人数参加型オンラインゲーム（Multiplayer Online Game)は同じグループのゲーム参加者を特定することがゲームを開始する条件となる。ゲーム装置以外のサーバ装置が参加者グルーピングを行うことも考えられる力多数のゲーム装置がゲームに参加を希望する場合には、サーバ装置の負荷が多い。一方、多数のゲーム装置の各々が対等な関係で相互に通信しながら参加者グルーピングを行うことも理論的には考えられるが、これではゲーム装置の間のトラフィック（traffic)が極めて増大する。この発明では、ゲームの参加者のグルーピングをマスターのゲーム装置で行うことにより、サーバ装置の負荷を低減し、さらにゲーム装置の間のトラフィックを低減できる。

[0009] また、上述したゲーム装置において、前記マスター機能実行部（21、 SC4)は、ゲームの開始時期を前記 2以上の他のゲーム装置（2A、 2C)に通知し、前記開始時期にゲームプログラムを実行してプレイヤーがゲームをプレイすることが可能になることが開始するように前記ゲームプログラム実行部（21)を制御し、前記スレーブ機能実行部（21、 SC5)は、マスターから前記開始時期の通知を受信すると、前記開始時期にゲームプログラムを実行してプレイヤーがゲームをプレイすることが可能になることが開始するように前記ゲームプログラム実行部（21)を制御する、ことが好ま、。このゲーム装置を 3つ以上用いてゲームシステムを構築すれば、これらのゲーム装置のゲームの開始を同期させることができる。

[0010] また、上述したゲーム装置において、前記制御部は、所定の条件が充足されると、このゲーム装置と前記 2以上の他のゲーム装置（2A、 2C)との間の通信モードを、このゲーム装置が前記 2以上の他のゲーム装置（2A、 2C)の各々と並行に通信するとともに、前記ゲーム情報生成部（21、 SC8、 SJ1〜SJ11)及び前記変化部（21、 SC8 、 SK1〜SK7)が有効に作動する、他の通信モードに移行させる通信モード移行部 (21、 SF10、 SH7)を備えることが好ましい。これにより、所定の条件が充足されると、マスター 'スレーブの関係を解消して個別通信モードに移行させることができ、ゲームのプレイ中に 1つのゲーム装置が通信不能となっても、残りの 2つ以上のゲーム装置において確実にゲームを続行することができる。

[0011] また、上述したゲーム装置において、前記移行部に関する前記所定の条件は、前記マスター機能実行部（21、 SC4)が前記開始時期を前記 2以上の他のゲーム装置 (2A、 2C)に通知したこと、または、前記スレーブ機能実行部（21、 SC5)がマスター力前記開始時期の通知を受信したことであるとが好ましい。これにより、複数のゲーム装置でゲームの開始を確実に同期させることができる。そして、ゲーム開始からは、各ゲーム装置が対等な関係で相互に通信を行う個別通信モードに切り替わる。多人数参加型オンラインゲームで重要なのは、プレイ中のゲーム情報の送受信である。この発明によれば、ゲーム開始を契機として個別通信モードに移行させるから、プレイ中にあるゲーム装置が通信不能に陥ったとしても、他のゲーム装置同士の間で通信を続行しながらゲームを続行することが可能となる。ゲームのプレイ前の参加グルービング処理中に、あるゲーム装置が通信不能となれば、そのゲーム装置は他のゲーム装置とゲームをプレイできな、が、そのゲーム装置の使用者が別のゲームをプレイすることができる代替策をそのゲーム装置がとれると好ましい。

[0012] また、上述したゲーム装置は、画像を表示する表示部（24)と、プレイヤーの操作に応じた信号を出力する入力装置（23)とをさらに備え、前記ゲームプログラム実行部（ 21)は、前記信号に応じてゲームを進行させるとともに、ゲームの進行に応じた画像を前記表示部（24)に表示させる。前記ゲーム情報生成部（21、 SC8、 SJ1〜SJ11) は、前記入力装置（23)の操作に応じて取得した得点を示す得点情報を前記ゲーム情報として生成し、この得点情報を前記 2以上の他のゲーム装置（2A、 2C)の各々に送信し、前記変化部（21、 SC8、 SK1〜SK7)は、前記得点情報を前記ゲーム情報として受信すると、受信した前記得点情報に応じた画像を前記表示部（24)に表示させると好ましい。あるいは、前記ゲーム情報生成部（21、 SC8、 SJ1〜SJ11)は、前記入力装置（23)の操作に応じて他のゲーム参加者に不利になるゲーム要素を指示する攻撃情報を前記ゲーム情報として生成し、この攻撃情報を前記 2以上の他のゲーム装置（2A、 2C)のうち少なくとも一つに送信し、前記変化部（21、 SC8、 SK1〜 SK7)は、前記攻撃情報を前記ゲーム情報として受信すると、受信した前記攻撃情報の指示する前記ゲーム要素に応じた画像を前記表示部（24)に表示させるようにしてもよい。

[0013] これにより、プレイヤ一は他のプレイヤーのゲームの進行に応じた画像を視認しな力 Sらゲームをプレイすることができる。ゲームは、画面に表示される画像及びスピーカ力も発音される音によって成り立つ。そして、画像や音は、ゲームを構成する個々の部品として考えることができる。例えば、ゲームの画像は、背景、移動するオブジェクト、そのオブジェクトを見えにくくするブラインド、それらの明るさ等によって構成される。また、ゲームの音は、楽音や得点を取得時の効果音、あるいは、楽音のテンポ等によって構成される。ゲーム要素とは、ゲームの画像や音を構成する個々の部品に相当し、プログラム上では、パラメータとして与えられる。そして、ゲーム要素を指定することによって、ゲームの難易度を高くする視覚効果や聴覚効果を与えることが可能である。例えば、ゲーム要素には、表示中のゲーム画面の幅を狭くすること、表示中のゲーム画面を暗くすること、表示中のゲーム画面を揺らすこと、出力される楽音の音量を小さくすること、出力される楽音の出力時期を遅らせることが含まれる。

[0014] また、上記のゲーム装置において、前記入力信号からの信号に基づいて、前記他のゲーム装置（2A, 2C、 2D)のうちどれが前記攻撃情報の送信先となるべき力を特定する送信先特定部（21、 SJ11)をさらに備え、前記ゲーム情報生成部（21、 SC8、 SJ1〜SJ11)は、生成した前記攻撃情報を前記送信先特定部により特定された前記他のゲーム装置（2A, 2C、 2D)へ送信するようにしてもよい。これにより、ユーザは、所望の他のゲーム参加者のプレイの邪魔をすることができる。

[0015] また、上記のゲーム装置において、ゲームに参加する前記 2以上の他のゲーム装置（2A、 2C)との通信を監視して通信断を検出する検出部（21、 SK5)を備え、前記ゲーム情報生成部（21、 SC8、 SJ1〜SJ11)は、前記検出部（21、 SK5)により通信断が検出された他のゲーム装置（2A)への前記ゲーム情報の送信を停止し、ゲームに参加する残りの他のゲーム装置（2C)に対して、前記ゲーム情報の送信を続行する、ことが好ましい。これにより、無駄な送信が削減されるから、通信資源を節約することが可能となる。さらに、残りのゲーム装置とは通信を続行するので、通信障害によるゲームへの影響を最小限に止めることができる。

[0016] また、上記のゲーム装置において、前記ゲームプログラム実行部（21)は、前記検出部（21、 SK5)により通信断が検出された他のゲーム装置（2A)の替わりに参加者としてゲームをプレイし、通信断が検出された他のゲーム装置が生成すべきであった前記ゲーム情報を生成して、このゲーム情報を前記変化部（21、 SC8、 SK1〜SK7 )に引き渡し、前記変化部（21、 SC8、 SK1〜SK7)は、前記検出部（21、 SK5)により通信断が検出されると、通信断が検出された他のゲーム装置（2A)の替わりに前記ゲームプログラム実行部（21)力前記ゲーム情報を取得すると共に、ゲームに参カロする残りの他のゲーム装置（2C)からの前記ゲーム情報の取得を続行し、取得した前記ゲーム情報に応じてゲームの進行を変化させる、ことが好ましい。これにより、ゲーム参加者の数に応じてゲーム内容が大きく変化するゲームのプレイ中に 1つのゲーム装置が通信不能となっても、そのゲーム装置がゲームプログラム実行部により代替されるから、ゲーム内容を大きく変化させることなくゲームを続行することができる。なお、変化部は、ゲーム情報を記憶し、通信断が検出されると、ゲームプログラム実行部は記憶内容を参照して通信断が検出された直前のゲーム情報を引き継いでゲームの進行を変化させることが好ましい。例えば、ゲーム情報が得点情報である場合には、通信断が検出される直前の得点に、通信断が検出されたゲーム装置の代わりにゲームプログラム実行部がプレイしたゲームの得点を加算して、他のゲーム参加者の得点とすればよい。

[0017] また、上記のゲーム装置において、前記ゲームプログラム実行部（21)は、前記プログラムに従って複数の曲を順次演奏し、前記検出部（21、 SK5)により通信断が検出されるたときに演奏中の曲の次の曲の演奏開始から、通信断が検出された他のゲーム装置の替わりに参加者としてゲームをプレイし始める、ことが好ましい。これにより、ゲームの流れを途切れさせることなぐ通信不能となった他のゲーム装置をゲームプログラム実行部〖こ代替させることができる。

発明の効果

[0018] 本発明によれば、いずれ力 1つのゲーム装置が通信不能となっても他のゲーム装置間で相互にゲーム情報を送受信することができるゲームシステムを構築可能なゲーム装置を提供することができる。このゲームシステムでは、 1つのゲーム装置が通信不能となっても残りの 2つ以上のゲーム装置においてゲームを続行することができる。

図面の簡単な説明

[0019] [図 1]本発明の一実施形態に係るゲームシステムの全体構成を示す図である。

[図 2]ゲーム中に図 1のゲームシステムのゲーム装置に表示されるゲーム画面の一例を示す図である。

[図 3]図 1のゲームシステムの挙動を単純化して示す図である。

[図 4]図 1のゲームシステム中のデータサーバの電気的構成を示す図である。

[図 5]図 4のデータサーバに格納された個人情報テーブルの内容の一例を示す図である。

[図 6]図 1のゲームシステム中のロビーサーバの電気的構成を示す図である。

[図 7]図 1のゲームシステム中のゲーム装置の電気的構成を示す図である。

[図 8]図 7のゲーム装置に格納されたゲーム参加者テーブルの内容の一例を示す図である。

[図 9]図 1のゲームシステムの動作例を説明するためのシーケンス図である。

[図 10]図 1のゲームシステムの次の段階の動作例を説明するためのシーケンス図である。

[図 11]図 1のゲームシステムの次の段階の動作例を説明するためのシーケンス図である。

[図 12]図 1のゲームシステムの次の段階の動作例を説明するためのシーケンス図である。

[図 13]図 7のゲーム装置が実行する認証処理を示すフローチャートである。 [図 14]図 4のデータサーバが実行する個人情報認証 Z登録処理を示すフローチヤ一トである。

[図 15]図 4のデータサーバに格納された個人情報テーブルの内容の一例を示す図である。

[図 16]図 7のゲーム装置のゲーム処理を示すフローチャートである。

[図 17]図 16のフロー中のマスター Zスレーブ決定処理を示すフローチャートである。

[図 18]図 6のロビーサーバ処理を示すフローチャートである。

[図 19]図 16のフロー中のマスター処理を示すフローチャートである。

[図 20]図 19のフロー中の参加者追加処理を示すフローチャートである。

[図 21]図 16のフロー中のスレーブ処理を示すフローチャートである。

[図 22]図 16フロー中の交換情報送信処理を示すフローチャートである。

[図 23]図 16のフロー中の交換情報受信処理を示すフローチャートである。

発明を実施するための最良の形態

[0020] く構成〉

図 1は、本発明の一実施形態に係るゲームシステム 100の全体構成を示す。

ゲームシステム 100は、インターネット 1を介して相互に通信可能なアーケードゲーム装置 2A〜2D、ロビーサーバ（lobby server) 3及びデータサーバ 4を有する。ゲームシステム 100は、最大で 3人のプレイヤー（3台のゲーム装置）がプレイするゲーム（多人数参加型オンラインゲーム（Multiplayer Online Game) )を実行する。

[0021] このゲームの内容について説明する。ただし、以降の説明では、ゲーム装置 2A〜

2Dの総称として「ゲーム装置 2」を用いる。

このゲームでは 3つのミニゲームが順次実行される。各ゲームは 1つの楽曲の演奏開始とともに開始し、演奏とともに進行し、演奏終了とともに終了する。つまり、このゲームは、 1曲目のミニゲーム（n= l)、 2曲目のミニゲーム（n= 2)及び 3曲目のミニゲーム（n= 3)を連ねた構成となっている。 nは、曲の順序を示し、 1〜3のいずれかの整数である。

[0022] 図 2は、ゲーム中にゲーム装置 2に表示されるゲーム画面の一例を示す。

ゲーム画面の中央部には、選択された楽曲に合わせてオブジェクト OBが図中上方に現れて図中下方に落ちて消える様子を示す画像が配置されている。オブジェクト o

Bには複数のタイプがある。この画像において、オブジェクト OBが消える地点のわずかに上方にはオブジェクト OBの落下方向に直交する水平ライン HLが存在し、この水平ライン HLにオブジェクト OBが重なったときにプレイヤーがこのオブジェクト OB のタイプに応じた操作を行うと、このゲーム装置 2はこのオブジェクト OBのタイプに応じた音を発する。つまり、プレイヤーの操作の時期及び内容が適切であればあるほど、選択された楽曲の再生がより正確に行われる。

[0023] ゲーム画面の下部には、そのプレイヤーのスコア（score)、ボーナスポイント（bonu s points)、操作適時'性ケーン、 manipulation timeliness gauge MG、及び攻撃レベル（attack level) ALを示す画像が配置されている。水平ライン HLにォブジェクト OBが重なったときにこのオブジェクト OBに応じた操作が行われると、スコアは増える。上記の操作の時期と理想的な時期とのズレが予め定められた第 1の範囲以下であれば、ボーナスポイントは増え、一度でもズレが第 1の範囲を越えるとボーナスポイントは 0に戻る。楽曲が終了した後に、ボーナスポイントには所定の係数が乗ぜられて、その積がスコアに加算される。操作適時性ゲージ MGは操作適時性 (manipul ation timeliness)の累積値を長さで表す。上記の操作の時期と理想的な時期とのズレが予め定められた第 2の範囲以下であれば、操作適時性の累積値は増える。攻撃レベル ALは他のプレイヤーに対する攻撃の強度であり、操作適時性の累積値が閾値未満であれば「1」、閾値以上であれば「2」となる。特定のタイプのオブジェクト O Bが水平ライン HLに重なったときに、このオブジェクト OBのタイプに応じた操作が行われると、そのときの攻撃レベル ALに応じた強度の攻撃 (邪魔）が他のプレイヤーに対して行われ、この後、操作適時性の累積値が初期値 (最小値)に戻る。

[0024] ゲーム画面の左部には、予め用意された複数の候補力このゲーム装置の現在のプレイヤーに選択されたキャラクタ画像が配置されて、る。

ゲーム画面の右部には、ゲームを現在プレイしているすべてのプレイヤー（このゲーム画像を見ているプレイヤーを含む）のプレイヤー情報に関する画像力そのゲームに参加可能な最大人数（3人)分、配置されている。プレイヤー情報には、プレイヤ一名、現在スコア、称号 (degree)、現在のセリフ（speech)、キャラクタ画像の部分画像などがある。なお、キャラクタ画像の部分画像は、他のゲーム装置 2を使用している他のプレイヤーに選択されたキャラクタ画像から一部分を抜き出して縮小することにより得られる。

[0025] 図 3はゲームシステム 100の挙動を単純化して示す。

ゲームシステム 100では、ゲームの開始に先立って参加者グルーピングが行われる。参加者グルーピングとは、一つのゲームをプレイする競争者（competitors)の組を決定することをいう。この参加者グルーピングのための期間がエントリー期間であり、ゲームの開始時に終了する。エントリー期間での参加者グルーピングはマスター Z スレーブ通信モードで行われる。マスター Zスレーブ通信モードでは、各スレーブは一つのマスターとだけ通信する。例えば、ゲーム装置 2Aがマスターとなり、ゲーム装置 2B及び 2Cがスレーブとなった場合、ゲーム装置 2B及び 2Cは!、ずれもゲーム装置 2Aのみと通信する。どのゲーム装置をマスターにするかは、エントリー期間の最初の段階で決定される。

[0026] エントリー期間が終わってゲームが始まると、通信制御の方式はマスター Zスレーブ通信モードから個別通信モードに移行する。個別通信モードでは、通信制御に関して各ゲーム装置が対等な立場となり、各ゲーム装置は他のいずれのゲーム装置とも通信が可能となる。したがって、例えば、何らかのエラーが生じてゲーム装置 2Aが通信不能となっても、ゲーム装置 2B及び 2Cは相互に通信可能であるからゲームを続行することができる。この際、ゲーム装置 2Bは自分のコンピュータ内に仮想ゲーム装置 BAを生成して、仮想ゲーム装置 BAにゲーム装置 2Aを代替させる。また、ゲーム装置 2Cは自分のコンピュータ内に仮想ゲーム装置 CAを生成して、仮想ゲーム装置 CAにゲーム装置 2Aを代替させる。これにより、プレイヤーの人数が減ったことによるゲーム内容の変化を最小とすることができる。なお、仮想ゲーム装置は、仮想的かつ自律的にゲーム装置として動作するコンピュータの機能であり、ゲーム装置 2B, 2 Cの各々にとつては、通信不能になった他のゲーム装置 2Aがあた力もゲームをプレィし続けているかのように動作する。通信不能となったゲーム装置 2A力他のゲーム装置 2B, 2Cをそれぞれ代替する仮想ゲーム装置を生成し、ゲームを続行することも可能である。 [0027] 図 4はデータサーノの電気的構成を示す。

データサーバ 4は、プレイヤーの個人情報を管理するものであり、 CPU (中央処理装置)等のプロセッサ 41、通信インターフェイス 42及び格納部 43を備える。通信インターフェイス 42はプロセッサ 41とインターネット 1との間でデータを中継するものであり、プロセッサ 41は通信インターフェイス 42を介して各ゲーム装置 2と通信する。格納部 43は、 IPL (Initial Program Loader)が書き込まれている ROM (Read Only

Memory)、ワークエリアとして用いられる RAM (Random Access Memory)、個人情報テーブル Tlが確保されてヽるハードディスクを有する。このハードディスクには、後述の個人情報認証 Z登録処理をプロセッサが実行するためのプログラムが書き込まれている。プロセッサ 41は、 ROM力も IPLを読み出してこれを実行することによって、ハードディスク力この個人情報認証 Z登録処理を実行するためのプログラムを読み出してこれを実行する。

[0028] 図 5は個人情報テーブル T1の内容の一例を示す。

個人情報テーブル T1には、ゲームシステム 100の利用者 (ゲーム装置でプレイする潜在的可能性のある者)の各々のプレイヤー ID、カード ID及び個人情報が格納されている。プレイヤー IDは利用者に固有の識別子であり、ゲーム提供事業者によつて利用者に予め付与される。カード IDは、利用者がゲームに使用するカードに固有の識別子であり、カードに書き込まれている。カードは利用者それぞれに与えられる。個人情報は利用者に関する情報であり、一人の利用者が複数のカードを使い分けるのを可能とするために、プレイヤー IDとカード IDとの組合せに対応付けられて、る

[0029] 個人情報に含まれ得る項目としては、プレイヤーレベル、ゲーム履歴、プレイヤー名、レベル 1用攻撃識別子、レベル 2用攻撃識別子、攻撃時セリフ、被攻撃時セリフ及び画像識別子を示す項目がある。プレイヤーレベルはこの利用者のこのゲームに関する上手さの指標であり、 1以上 30以下のいずれかの自然数をとる。ゲーム履歴は利用者がプレイしたゲームの履歴である。プレイヤ一名は利用者の名前である。レベル 1用攻撃識別子は、ゲームプレイの間に攻撃レベル ALが 1の場合に、他のプレィヤーに与えられる攻撃の種類を示す。レベル 2用攻撃識別子は、ゲームプレイの間に攻撃レベル ALが 2の場合に、他のプレイヤーに与えられる攻撃の種類を示す。レベル 1用攻撃識別子およびレベル 2用攻撃識別子は、ゲームをプレイしてヽなヽ時に、利用者が複数の候補の中から選択可能である。攻撃時セリフは、ゲームプレイの間に攻撃を行うときに用いるセリフである。被攻撃時セリフは、ゲームプレイの間に攻撃を受けたときに用いるセリフである。これらのセリフはゲーム中に他のプレイヤーが使用しているゲーム装置のゲーム画面に表示される（図 2参照)。これらのセリフは、ゲームをプレイしていない時に、利用者が編集可能である。画像識別子はこの利用者が選択したキャラクタ画像を示す。

[0030] 図 6は図 1のゲームシステム中のロビーサーバ（lobby server) 3の電気的構成を示す。

ロビーサーバ 3は、各ゲーム装置からゲーム参加（game participation)の要求を受けて応答を返す。ロビーサーバ 3は、例えば CPUであるプロセッサ 31、通信インタ一フェイス 32及び格納部 33を備える。通信インターフェイス 32はプロセッサ 31とインターネット 1との間でデータを中継する。プロセッサ 31は通信インターフェイス 32を介してゲーム装置 2と通信する。格納部 33は IPLが書き込まれている ROM、ワークエリァとして用いられる RAM、及び後述の図 18に示すロビーサーバの処理をプロセッサが実行するためのプログラムが書き込まれたノヽードディスクを有する。プロセッサ 31 は、 ROM力 IPLを読み出してこれを実行することによって、ハードディスクからロビ一サーバの処理を実行するためのプログラムを読み出してこれを実行する。

[0031] 格納部 33の RAMにはエントリーリスト L1及び L2が確保されている。エントリーリスト L1及び L2は、それぞれ、ゲーム参カ卩要求を現在受け付けている一つ以上のマスタ一のゲーム装置の通信アドレスを格納するものであり、ロビーサーバの処理の開始前 (初期状態）には空になっており、ロビーサーバの処理において更新される。エントリ一リスト L1ZL2はプレイヤーレベルが比較的に低い Z高いプレイヤー用のエントリ一リストであり、ゲーム装置力の要求の内容に応じて使い分けられる。

[0032] 図 7は図 1のゲームシステム中のゲーム装置 2の電気的構成を示す。

ゲーム装置 2は、プログラムを実行してプレイヤーがゲームをプレイすることを可能にする。ゲーム装置 2は、例えば CPUであるプロセッサ 21、通信インターフェイス 22 、入力装置 23、表示装置 24、スピーカ 25、カード読取装置 26及び格納部 27を備える。通信インターフェイス 22はプロセッサ 21とインターネット 1との間でデータを中継する。プロセッサ 21は通信インターフェイス 22を介して他のゲーム装置 2、ロビーサーバ 3及びデータサーノと通信する。入力装置 23は複数のボタンを備える。ボタンが押されると、押されたボタンに固有の入力信号を入力装置 23は生成して、この入力信号をプロセッサ 21に供給する。表示装置 24はプロセッサ 21からの画像データを受けて動画像を表示する。スピーカ 25はプロセッサ 21からの楽音信号を受けて放音する。カード読取装置 26は、ゲームに使用されるカードがカード読取装置 26にセットされると、セットされたカード力カード IDを読み取ってプロセッサ 21に供給する。

[0033] 格納部 27は、 ROMと、ワークエリアとして用いられる RAMとを有する。

この ROMには、画像テーブル T2、称号テーブル Τ3、レベル変換テーブル Τ4及び楽曲テーブル Τ5が確保されており、装置情報、宛先情報 Dl、宛先情報 D2及びゲームプログラム Pが書き込まれている。一方、格納部 27の RAMには、送出領域 R1 及び R2、マスターフラグ F及びゲーム参加者テーブル T6が確保される。プロセッサ 2 1は、ゲームプログラム Pを実行することによって、プレイヤーがゲームをプレイすることを可能にするゲームプログラム実行部として機能する。

[0034] 画像テーブル T2には、このゲーム装置を利用する不特定の利用者がゲーム内で使用可能な複数のキャラクタ画像候補の各々について、キャラクタ画像に固有の画像識別子を示すデータと、キャラクタ画像の表示に用いられる画像データとが対応付けて格納されている。プレイヤ一は、画像テーブル T2内のキャラクタ画像候補力ゝら所望のキャラクタ画像を選択できる。

称号テーブル T3には、このゲーム装置を利用する不特定の利用者がゲーム内で使用可能な複数の称号の各々について、称号に固有の称号識別子を示すデータと、称号の表示に用いられる文字列データと、称号に応じたプレイヤーレベルの範囲を示すデータとが対応付けて格納されている。称号は、昔の軍隊での地位 (degree)を連想させる名詞句であり、高い地位を連想させる称号 (例えば将軍 (General) )には高、プレイヤーレベルが対応付けられており、低、地位を連想させる称号 (例えば歩兵（Foot— soldier) )には低!、プレイヤーレベルが対応付けられて!/、る。 [0035] レベル変換テーブル T4は、プレイヤーレベルをゲームレベルに変換するために使用される。レベル変換テーブル Τ4は、ゲームレベルのとり得る値と、各ゲームレベルに相当するプレイヤーレベルの範囲とを対応付けて格納している。具体的には、プレィヤーレベルが 1以上 15以下であればゲームレベルとして 1が特定され、プレイヤーレベルが 16以上 30以下であればゲームレベルとして 2が特定されるようになっている

[0036] ここで、ゲームレべノレについて説明する。このゲームにおいて、他のプレイヤーに比べてプレイヤーレベルが著しく異なるプレイヤーが参加すると、ゲーム展開が容易に予想でき、つまらなくなる（すなわちゲームバランスが崩れる）。これを避けるために、同一のプレイヤーレベルのプレイヤー同士の参加しか認めないようにすることが考えられる。し力し、この態様では、プレイヤーレベルの刻みが細かければ細かいほど、ゲームに必要な最低限の数の参加者を集めるのに要する時間が長くなる。この時間を短縮するためには、プレイヤーレベルの刻みを粗くすることになる力そうすると、上手さの指標としてのプレイヤーレベルの精度が低下してしまう。そこで、ゲームシステム 100では、プレイヤーレベルではなぐゲームレベルが同一のプレイヤー同士の参加しか認めな、ようにして、る。ゲームレベルはこのゲームの難易度の指標であり、その刻みはプレイヤーレベルの刻みよりも遥かに粗く設定されている。具体的には、プレイヤーレベルの刻みが 1〜30の 30段階であるのに対し、ゲームレベルの刻みは 1〜2の 2段階である。よって、ゲームに必要な最低限の数の参加者を集めるのに要する時間が十分に短くなる。

[0037] 楽曲テーブル Τ5には、プレイヤーがゲーム内で使用可能な複数の楽曲候補の各々について、楽曲に固有の楽曲識別子を示すデータと、楽曲の名称を示すデータと、楽曲の演奏に用いられる楽曲データと、ゲームレベルとが対応付けて格納されている。楽曲には、ゲームの難易度が比較的に低い楽曲とゲームの難度が高い楽曲とがあり、前者についてのゲームレベルは 1、後者についてのゲームレベルは 2である。

[0038] 装置情報は各ゲーム装置 2に固有の情報であり、ゲーム装置 2の通信アドレスを示す通信アドレス、ゲーム装置 2が設置されている店舗の名称 (以降、「店舗名」）を示す店舗名情報、及びこの店舗がある地域の名称を示す地域名情報を含む。宛先情報 Dlはロビーサーバ 3の通信アドレスを示す。

宛先情報 D2はデータサーノの通信アドレスを示す。

ゲームプログラム Pはプロセッサ 21に実行されて、後述の認証処理およびゲーム処理を実現する。

[0039] 送出領域 R1及び R2は、それぞれ、ゲーム中に他のゲーム参加者のゲーム装置 2 へ送信したり引き渡したりする情報を一時的に保持する記憶領域である。この明細書において、「送信する（transmit)」とは物理的に遠隔のゲーム装置に情報を送ることであり、「引き渡す (give)」とは同じゲーム装置内で情報を交換すること、例えば、ゲーム装置が自分のコンピュータ内の仮想ゲーム装置に情報を渡すことをいう。

マスターフラグ Fは 0又は 1の数値をを格納する記憶領域である。マスターフラグ Fに 1が書き込まれていれば、このゲーム装置がマスターであり、マスターフラグ Fに 0が書き込まれてヽれば、このゲーム装置はスレーブである。

ゲーム参カ卩者テープノレ（game participant table)T6は、このゲームの開始および進行に必要な情報 (各ゲーム参加者に関する情報）を格納する。その内容は次に述べる通りである。

[0040] 図 8は、図 7のゲーム装置に格納されたゲーム参加者テーブル T6の内容の一例を示す。

ゲーム参加者テーブル T6は、現在ゲームに参加しているゲーム装置 2 (このゲーム装置自身も含む）と現在ゲームに参加しているプレイヤーに対応する 3つのレコード RC1〜RC3を有する。レコード RC1はこのゲーム参加者テーブル T6を有するゲーム装置 2自身に対応し、レコード RC2及び RC3はそれぞれ他のゲーム参加者のゲーム装置 2に対応している。各レコードには、対応するゲーム装置 2に関連するゲーム情報が格納される。ゲーム情報はゲームに用いられる情報であり、具体的には、代替状況情報、装置情報、個人情報、称号識別子、選択情報、曲順情報およびスコア情報を含む。

[0041] 代替状況情報は、仮想ゲーム装置による代替に関して、他のゲーム装置 2 (レコ一ド RC 1以外のレコードに対応するゲーム装置）の状況を示し、レコード RC 1に対応するゲーム装置 2により生成される。代替状況情報に示される状況としては、「代替不要」、「要代替」、「代替中」の 3つがある。「代替不要」は、対象のゲーム装置が通信可能でゲームに参加できる状態である。「要代替」は、対象のゲーム装置が通信不可能な状態である。「代替中」は、対象のゲーム装置が仮想ゲーム装置で代替されている状態である。もちろん、レコード RC1に対応するゲーム装置 2自身が仮想ゲーム装置により代替されることはないから、レコード RC1内の代替状況情報が示す状況は常に「代替不要」のみである。

[0042] ゲーム参加者テーブル T6における装置情報は、各レコードに対応するゲーム装置 2の格納部 27から読み出されてこのゲーム装置に渡される。また、ゲーム参加者テーブル T6における称号識別子、選択情報 (画像識別子および楽曲識別子)及びスコア情報は、それぞれ、各レコードに対応するゲーム装置 2において生成されてこのゲーム装置に渡されるものである。つまり、これらの情報はいずれも、各レコードに対応するゲーム装置 2に起源を持つ。他方、ゲーム参加者テーブル T6における個人情報はデータサーバ 4の格納部 43から読み出されてこのゲーム装置に渡されるものであり、データサーバ 4に起源を持つ。

[0043] 曲順情報は、このゲームに用いられる 3つの楽曲の使用順序を示すものであり、ゲームに参加するゲーム装置 2のうちのマスターにより生成されてスレーブに渡される。つまり、この情報はマスターに起源を持つ。よって、ゲーム参加者テーブル T6を有する装置がマスターであれば、この装置はこのゲーム装置自身が生成した曲順情報をゲーム参加者テーブル T6に格納する。ゲーム参加者テーブル T6を有する装置がスレーブであれば、この装置はマスターから渡された曲順情報をゲーム参加者テープル T6に格納する。但し、曲順情報に示される 3つの楽曲は、マスターおよび 2つのスレーブによりそれぞれ指定される。 3つの楽曲が決まった後に、マスターで曲順が決定される。

[0044] <動作 >

図 9〜図 12はそれぞれゲームシステム 100の異なる段階での動作例を説明するためのシーケンス図である。図 9の動作、図 10の動作、図 11の動作、図 12の動作は次々と行われる。以下の説明では、データサーノの個人情報テーブル T1の内容が図 5に示す通りであると仮定する。また、ゲーム装置 2A〜2Dを使用するプレイヤーのプレイヤーレベルカ^、ずれも 1〜 15の範囲内にあると仮定する。

[0045] 図 9にはゲーム装置 2A〜2Dの各々が次々とデータサーバ 4から、ゲーム装置自身のプレイヤーに対応する個人情報を取得する動作が示されて!/、る。この動作は、各ゲーム装置 2のプロセッサ 21が図 13の認証処理を行い、データサーバ 4のプロセッサ 41が図 14の個人情報認証 Z登録処理を行うことによって遂行される。以降、この動作について説明する。

[0046] この動作では、まず、カード IDが「A」であるカードがゲーム装置 2Aにセットされる。

すると、ゲーム装置 2Aでは、カード読取装置 26がこのカード力カード IDを読み取つてプロセッサ 21に供給する。プロセッサ 21はカード ID「A」の供給を受けると、格納部 27から宛先情報 D2及び送信元情報 (このゲーム装置自身の通信アドレス）を読み出し、この送信元情報および供給されたカード IDを含む認証要求信号を、読み出した宛先情報 D2が示す通信アドレスを持つデータサーノへ送信する（図 13のステツプ SA1)。なお、ゲーム装置 2から送信される信号には必ず送信元情報が含まれるから、図 9〜図 12及び以降の説明では送信元情報の送信に関する記載を省略する。

[0047] 一方、データサーバ 4のプロセッサ 41は、！/、ずれかのゲーム装置から要求を受信した力否かの判定（図 14のステップ SB1)を、要求を受信するまで繰り返す。この繰り返し処理において、プロセッサ 41はゲーム装置 2Aからの認証要求を受信する。要求を受信すると、ステップ SB1の判定結果が「YES」となり、プロセッサ 21は受信した要求が認証要求である力否かを判定する (ステップ SB2)。受信した要求はゲーム装置 2 A力の認証要求であるから、受信した要求に係るカードが登録済みである力否かを、次に判定する (ステップ SB3)。具体的には、受信した要求に含まれているカード ID がある力否かを個人情報テーブル T1内で検索し、ヒットしたレコードの数が 1以上の場合にはそのカードは登録済みであると判定し、ヒットしたレコードの数力^の場合にはそのカードは未登録であると判定する。

[0048] 図 5に示すように、個人情報テーブル T1には、受信した認証要求に含まれて!/、るカード ID「A」を含むレコードが格納されているから、この局面ではステップ SB3の判定結果が「YES」となる。よって、プロセッサ 41は、このカード IDに対応付けられている個人情報を個人情報テーブル T1から読み出し、これを含む認証結果をゲーム装置 2Aに返信する (ステップ SB4)。なお、「返信」とは、受信した要求に含まれている送信元情報が示す通信アドレスの装置へ情報または信号を送信することを、う。以降、データサーバ 4における処理はステップ SB1に戻る。

[0049] ゲーム装置 2Aのプロセッサ 21は、認証要求の送信後、認証結果を受信した力否かの判定（図 13のステップ SA2)を、認証結果を受信するまで繰り返す。この繰り返し処理において、プロセッサ 21はデータサーバ 4からの認証結果を受信する。認証結果を受信すると、ステップ SA2の判定結果が「YES」となる。よって、プロセッサ 21は、受信した認証結果がカードの未登録を示すものであるカゝ否かを判定する (ステップ SA3)。プロセッサ 21が受信した認証結果に含まれている情報は個人情報であり、力一ドの未登録を示す情報ではないから、ステップ S A3の判定結果は「NO」となり、認証処理が終了する。

[0050] 以降、ゲーム装置 2B〜2Dのプロセッサ 21が、次々と上記の認証処理を行い、力ード ID「B」〜「D」のヽずれかに対応付けられてヽる個人情報を取得する。

ただし、図 5に示すように、ゲーム装置 2Aのカード ID「A」、ゲーム装置 2Bのカード ID「B」およびゲーム装置 2Dのカード ID「D」のカードはデータサーバ 4に登録されているが、ゲーム装置 2Cにセットされたカード ID「C」のカードは未登録であるから、データサーバ 4はゲーム装置 2C力の認証要求を受信すると、この認証要求に係る力一ドは未登録であると判定し、未登録を示す情報を含む認証結果をゲーム装置 2C に返信する（ステップ SB1〜SB3及び SB5)。以降、データサーバ 4における処理はステップ SB 1に戻る。

[0051] 一方、ゲーム装置 2Cのプロセッサ 21は、ステップ SA1にて認証要求を送信した後にデータサーバ 4からの認証結果を受信すると、受信した認証結果は未登録を示すものであると判定し、データサーバ 4に登録すべき情報項目をこのゲーム装置の利用者から取得する (ステップ SA1〜SA4)。登録すべき情報項目は 3つに大別される。 1 つ目の項目はカード ID「C」であり、既にカード読取装置 26から供給されている。 2つ目の項目はカード IDが「C」のカードを携行して、るプレイヤー（利用者）のプレイヤ一 ID「3」であり、 3つ目の項目はこのプレイヤーの個人情報である。 2つ目及び 3つ目の情報項目の取得方法は任意であるが、ゲーム装置 2では、以下の方法を使用する。まず、プロセッサ 21は、表示装置 24に情報の入力を促す画像を表示させ、この表示に応じて利用者が入力装置 23を操作することにより、プレイヤー IDおよびプレイヤーの個人情報を示す入力信号が入力装置 23からプロセッサ 21に供給される。プ口セッサ 21は、この入力信号を用いて 2つ目および 3つ目の情報を取得する。そして、プロセッサ 21は取得した情報項目を含むカード登録要求をデータサーノへ送信する（ステップ SA5)。

[0052] このカード登録要求はデータサーノのプロセッサ 41により受信される。すると、データサーバ 4では、図 14のステップ SB1の判定結果が「YES」となり、ステップ SB2の判定結果が「NO」となる。次に、プロセッサ 41は、受信した要求がカード登録要求であるか否かを判定する（ステップ SB6)。ステップ SB6の判定結果は「YES」となる力、プロセッサ 41は、受信した要求に係るカードを登録する (ステップ SB7)。具体的には、この受信した要求に含まれている上記 3つの情報項目を対応付けて個人情報テ一ブル T1に格納する。この結果、図 5に示す個人情報テーブル T1の内容は、図 15 に示す内容に更新される。

[0053] 次にプロセッサ 41は、受信した要求に含まれているカード ID「C」に対応付けられて V、る個人情報を個人情報テーブル T1から読み出し、これを含む認証結果をゲーム装置 2Cに返信する（ステップ SB4)。この認証結果はゲーム装置 2Cのプロセッサ 21 により受信される (ステップ SA6)。以降、データサーバ 4における処理はステップ SB 1に戻り、ゲーム装置 2Cでは認証処理が終了する。

[0054] ゲーム装置 2では、認証処理の終了後に、複数のゲームモードから 1つを選択させるための画面が表示装置 24に表示される。複数のゲームモードには、多人数参加型オンラインゲームを行うための多人数参加モードがあり、各ゲーム装置 2のプロセッサ 21は多人数参加モードが選択されると後述のゲーム処理を開始する。

[0055] 図 10にはゲーム装置 2Aにて多人数参加モードが選択されてからこのゲームを行うプレイヤー（ゲーム装置 2)の参加者グルーピングが完了するまでの動作が示されている。この動作は、各ゲーム装置 2のプロセッサ 21が図 16の多人数参加ゲーム処理を行い、ロビーサーバ 3のプロセッサ 31が図 18のロビーサーバ処理を行うことによつてもたらされる。 [0056] 図 10では、まず、ゲーム装置 2Aにおいて多人数参加モードが選択される。すると、図 16の多人数参加ゲーム処理が開始される。まず、ゲーム装置 2のプロセッサ 21は初期化を実行する（ステップ SC1)。ステップ SCIの初期化で、ゲーム装置 2Aのプロセッサ 21は、ゲーム装置 2Aの格納部 27に空の参加拒否受信履歴リスト（後述する）を書き込むとともにゲーム参加者テーブル T6を確保し、確保したゲーム参加者テーブル T6のうち他のプレイヤーに対応するレコード RC2, RC3に「要代替」を示す代替状況情報を格納する。また、ステップ SC1の初期化で、ゲーム装置 2のプロセッサ 21 は、自分側のプレイヤーのレコード RC1に、この格納部 27に書き込まれているゲーム装置自身の装置情報と、データサーバ 4から受信した認証結果に含まれて、る自分側のプレイヤーの個人情報とを格納する。更にステップ SC1の初期化で、ゲーム装置 2のプロセッサ 21は、この個人情報内のプレイヤーレベルに対応する称号識別子を称号テーブル T3を用いて特定して、レコード RC1に格納する。

[0057] 参加拒否受信履歴リストは、ゲーム装置がスレーブである場合に意義がある。後述の通り、マスターにゲーム参加要求（game— participation— request)を送信したスレーブはマスターから参加拒否通知（participation— rejection— notice)を受信することがある。参加拒否通知を受信したスレーブは、参加拒否受信履歴リストに参加拒否通知を送信したマスターの識別子 (例えば通信アドレス）を書き込む。このスレーブは、参加拒否受信履歴リストに示されたマスターに再びゲーム参加要求を送信しないので、無益なゲーム参加要求送信を避けることが可能である。初期化の段階では、、ずれのゲーム装置 2にお、ても参加拒否受信履歴リストは空である。

[0058] 代替状況情報は、上記の通り他のゲーム装置 2 (図 8のレコード RC1以外のレコードに対応するゲーム装置)が仮想ゲーム装置で代替中か、代替を要するか、代替を要しないかの状況を示す。ゲームの開始前に通信不能となることもありえるし、他のゲーム参加希望者が現れないこともありえるので、初期化の段階では、他のプレイヤーに対応するレコード RC2, RC3に「要代替」を示す代替状況情報を格納する。

[0059] 次にプロセッサ 21はマスター Zスレーブ決定処理を行う（ステップ SC2)。マスター Zスレーブ決定処理は、このゲーム装置自身がマスターである力スレーブであるかを決定する処理であり、より具体的にはマスターフラグ Fの値を決定する処理である。 [0060] 図 17はマスター Zスレーブ決定処理を示すフローチャートである。

プロセッサ 21は、ゲームレベルを示す情報を含むエントリーリスト要求（entry list request)をロビーサーバ 3へ送信する（ステップ SD1)。エントリーリスト要求は、口ビーサーバ 3が格納部 33に記憶しているエントリーリストを返信することをロビーサ一ノ 3に要請する。エントリーリスト要求は、ゲーム参加を希望するプレイヤーのゲームレベルを示す情報を含む。具体的には、プロセッサ 21は、ロビーサーバ 3の通信アドレスを示す宛先情報 D1を格納部 27から読み出し、現在このゲーム装置を操作しているプレイヤーについての図 16のステップ SC1で特定したプレイヤーレベルを、レべル変換テーブル T4を参照してゲームレベルに変換し、このゲームレベルを示す情報を含むエントリーリスト要求を、読み出した宛先情報 D1が示す通信アドレスのロビーサーバ 3へ送信する。ゲーム装置 2Aを使用するプレイヤーのプレイヤーレベルは 1 〜 15の範囲内にあるから、ゲームレベルは 1である。

[0061] 図 18は、参加者グルーピングを実現するためのロビーサーバ 3の処理を示すフロ一チャートである。このフローチャートは、同一のゲームレベルの参加者に関する処理の流れを示すが、ロビーサーバ 3は他のゲームレベルの参加者に関する処理を図示の流れと並列に実行する。ロビーサーバ 3のプロセッサ 31は、ゲーム装置から要求を受信したか否かの判定（図 18のステップ SE1)を、要求を受信するまで繰り返す。この繰り返し処理において、ゲーム装置 2Aからの要求を受信すると、プロセッサ 31 は受信した要求がエントリーリスト要求である力否かを判定する (ステップ SE2)。ェントリーリスト要求が受信された場合、そこに含まれるゲームレベルが 1であればエントリ一リスト L1が返信され、エントリーリスト要求に含まれるゲームレベルが 2であればェントリーリスト L2が返信される。各エントリーリストには、対応するゲームレベルに関してゲーム参加要求を現在受け付けている一つ以上のマスターのゲーム装置の通信アドレスが書き込まれうる。但し、初期状態では、各エントリーリストには何も書き込まれていない（空である）。ゲーム装置 2Aからのエントリーリスト要求については、ステツプ SE2の判定結果は「YES」となるから、プロセッサ 31は、エントリーリスト要求に示されるゲームレベルに応じたエントリーリスト L1を格納部 33から読み出して返信する (ステツプ SE3)。以降、ロビーサーバ 3における処理はステップ SE1に戻る。 [0062] ゲーム装置 2Aのプロセッサ 21は、エントリーリスト要求の送信後、エントリーリストを受信した力否かの判定（図 17のステップ SD2)を、エントリーリストを受信するまで繰り返す。この繰り返し処理において、ゲーム装置 2Aのプロセッサ 21は、ロビーサーバ 3 力ものエントリーリストを受信すると、プロセッサ 21は、受信したエントリーリストが空であるか否かを判定する（ステップ SD3)。ゲーム装置 2Aに関しては、ステップ SD3の判定結果は「YES」となる。空のエントリーリストを受信したプロセッサ 21は、ゲーム装置自身を使用するプレイヤーに対応する前述のゲームレベルを示す情報とゲーム装置自身の通信アドレスを含むエントリー登録要求（entry record request)をロビ一サーバ 3へ送信する（ステップ SD4)。エントリー登録要求は、ロビーサーバ 3が格納部 33に記憶しているエントリーリストのうちエントリー登録要求で指定されたゲームレベルに対応するエントリーリストに、送信元のゲーム装置のアドレスを書き込むことをロビーサーバ 3に要請する。次に、プロセッサ 21はマスターフラグ Fに 1を書き込む (ステップ SD5)。すなわち最初にエントリーリスト要求を送信したゲーム装置 2Aが以降マスターとして振る舞う。こうしてゲーム装置 2Aにとつてのマスター Zスレーブ決定処理が終了する。

[0063] 送信されたエントリー登録要求はロビーサーバ 3のプロセッサ 31により受信される。

これにより、図 18のステップ SE2の判定結果が「NO」となる。よって、プロセッサ 31は受信した情報がエントリー登録要求である力否かを判定する (ステップ SE4)。この判定結果は「YES」となるから、プロセッサ 31は受信したエントリー登録要求に含まれて V、る送信元情報を用いて送信元のゲーム装置 2Aの通信アドレスを特定し、これを、受信したエントリー登録要求に示されるゲームレベルに応じたエントリーリスト L1に登録する (ステップ SE5)。具体的には、受信したエントリー登録要求に含まれている送信元情報 (ゲーム装置の通信アドレス）を含むようにエントリーリスト L1を更新する。以降、ロビーサーバ 3における処理はステップ SE1に戻る。

[0064] 一方、マスター Zスレーブ決定処理（図 16のステップ SC2)を終え、最初にエントリ一リスト要求を送信したことによりマスターとなるべきゲーム装置 2Aのプロセッサ 21は、マスターフラグ Fの値が 1である力否かを判定する (ステップ SC3)。この判定結果は「YES」となるから、プロセッサ 21はゲーム装置 2A自身をマスターとして認識し、マスター処理を行う（ステップ SC4)。

[0065] 図 19はマスター処理を示すフローチャートである。マスター処理における主要な処理には、他のゲーム装置力のゲーム参カ卩要求を待ち、ゲーム参加要求を受信すると、参加者の人数が所定の最大人数 m (この実施の形態では 3)に達するまでゲーム参加を許可する応答を返信する処理と、ゲームに参加する前記 2以上の他のゲーム装置 (スレーブ)の通信アドレス等のデータをゲーム参加者テーブル T6に記憶させる処理と、ゲームに参加する 2以上の他のゲーム装置の各々に対して、記憶した他の参加者の通信アドレス等のデータを送信する処理がある。以下、詳述する。

[0066] プロセッサ 21は、スタート時点から 60秒経過でするとタイムアウトするタイマをスタートさせるとともに、キャラクタ画像および楽曲選択処理を開始する (ステップ SF1)。ゲーム装置 2A〜2Cの各々において、プレイヤ一は自分で使用するキャラクタ画像および一つの楽曲を選択する（図 11)。キャラクタ画像および楽曲選択処理では、プロセッサ 21はプレイヤーにその選択を促す。まずプロセッサ 21は、キャラクタ画像の候補の中から一つおよび楽曲の候補の中から一つを仮選択する。次に、プレイヤーがキャラクタ画像および楽曲を確定的に選択するまで、プロセッサ 21は仮選択されたキャラクタ画像および楽曲を、画像テーブル T2と楽曲テーブル T5と入力装置 23からの入力信号とを用いて切り替える。キャラクタ画像および楽曲を確定的に選択する旨を示す入力装置 23からの入力信号により、プロセッサ 21はキャラクタ画像および楽曲を確定的に選択する。この選択処理では、仮選択されたキャラクタ画像と仮選択された楽曲の名称とが表示装置 24に表示され、仮選択された楽曲の楽音信号が生成されてスピーカ 25に供給される。また、キャラクタ画像および楽曲選択処理開始直後の仮選択は基本的にはランダムに行われる力ゲーム参加者テーブル T6のレコード RC1に格納された個人情報に画像識別子を示す情報が含まれて、る場合にはこの画像識別子に応じたキャラクタ画像が最初に仮選択される。キャラクタ画像および楽曲選択処理は後述のステップ SF2〜SF9の処理と並列に行われ、ステップ SF8又は SF9の判定結果が「YES」となると終了する。

[0067] ステップ SF2〜SF9では、プロセッサ 21は、ステップ SF8又は SF9の判定結果が「 YESJとなるまで、次に列記する処理を順に繰り返し行う。 (1)ゲーム装置自身のプレイヤーのキャラクタ画像および楽曲の選択が完了したか否かを判定し (ステップ SF2)、完了したと判定した場合にのみ、選択結果を表す選択情報 (画像識別子および楽曲識別子)をゲーム参加者テーブル T6のレコード RC 1に格納する（ステップ SF3)。

(2)他のゲーム装置 (スレーブ)力も選択情報を受信した力否かを判定し (ステップ S F4)、この判定結果力 S「YES」の場合にのみ、選択結果を表す選択情報 (画像識別子または楽曲識別子）をゲーム参加者テーブル T6のレコード RC2又は RC3に格納する（ステップ SF5)。レコード RC2及び RC3のどちらに格納するかは、受信した選択情報に含まれて、る送信元情報に基づ、て決定される。

(3)スレーブ力もゲーム参カ卩要求を受信した力否かを判定し (ステップ SF6)、この判定結果が「YES」の場合にのみ、後述の参加者追加処理を行う（ステップ SF7)。参加者追加処理は、ゲーム参加要求を送信したスレーブを参加者として許可するか拒否する処理である。

(4)最大人数 (この実施の形態では 3人)分のキャラクタ画像および楽曲の選択が完了した力否かを判定する (ステップ SF8)。

(5)タイマがタイムアウトした力否かを判定する（ステップ SF9)。

ゲーム装置 2Aにお!/、てマスター処理（図 19)の上記（1)〜（5)の繰り返し処理が行われている間に、図 10に示すように、ゲーム装置 2Bにおいて多人数参加モードが選択されると仮定する。この場合、ゲーム装置 2Bのプロセッサ 21は、ゲーム装置 2A のプロセッサ 21と同様に、図 16の多人数参加ゲーム処理を開始し、前記の初期化を実行する（ステップ SC1)。ただし、ゲーム装置 2Bのゲーム参加者テーブル T6はゲーム装置 2Bの格納部 27に確保され、そのレコード RC1にはゲーム装置 2B自身の装置情報と、ゲーム装置 2Bのプロセッサ 21がデータサーバ 4から受信した認証結果に含まれて、るゲーム装置 2Bのプレイヤーの個人情報 (カード ID「B」に対応付けられた個人情報）とが格納される。

この後、マスター Zスレーブ決定処理 (ステップ SC2)において、ゲーム装置 2Bのプロセッサ 21は図 17に示すようにエントリーリスト要求を送信する（ステップ SD1)。図 10に示すように、このエントリーリスト要求にもゲームレベル（1)が指定されている。一つのゲームに参カ卩可能な最大人数は 3であるので、同じゲームレベルで 2番目にェントリーリスト要求を送信したゲーム装置 2Bはスレーブとなるべきである。ロビーサ一ノ 3からゲーム装置 2Bへ送信されるエントリーリスト L1には、ゲーム装置 2A (マスタ一の候補）の通信アドレスを示す情報が含まれて、るから、図 17のステップ SD3の判定の結果は「NO」となる。

[0069] よって、図 17のマスター Zスレーブ決定処理は、ステップ SD6に進み、ゲーム装置 2Bのプロセッサ 21は、受信したエントリーリスト L1から参加拒否受信履歴リスト内の情報と一致する情報を削除する。 2番目にエントリーリスト要求を送信したゲーム装置 2Bが初めてエントリーリストを受信した直後のこの局面では参加拒否受信履歴リストは空であるから、受信したエントリーリスト L1は変更されず、ゲーム装置 2Aの通信ァドレスを示す情報が含まれたままにされる。次に、プロセッサ 21は削除後のエントリーリスト L1が空である力否かを判定する（ステップ SD7)。この判定結果は「NO」となるから、変数 kを 1にセットする（ステップ SD8)。変数 kは、エントリーリスト内での、マスタ一の通信アドレスの並び順序数である。エントリーリストに、唯一のマスターの通信ァドレスしかない場合には、変数 kの最大値は 1である。エントリーリストに、二つのマスターの通信アドレスがある場合には、 k= lの通信アドレスと、 k= 2の通信アドレスがある。ステップ SD8で、ゲーム装置 2Bのプロセッサ 21は、エントリーリスト L1に含まれている k= 1番目の情報に注目し、注目している情報が示す通信アドレスのゲーム装置（マスターの候補であるゲーム装置 2A)へゲーム参加要求を送信する（ステップ S D9)。このゲーム参加要求には、送信元のスレーブとなるべきゲーム装置 2Bの装置情報、個人情報、及び称号識別子が含まれている。プロセッサ 21は、ゲーム参加要求を送信すると、参加許可通知（participation permission— noticeノま 7こはカロ拒否通知を受信するまで、参加許可通知を受信したか否かを判定する処理 (ステツプ SD10)と参加拒否通知を受信した力否かを判定する処理 (ステップ SD11)とを繰り返し行う。

[0070] ゲーム装置 2Bからのゲーム参加要求はゲーム装置 2Aのプロセッサ 21により受信される。これにより前述のマスター処理（図 19)での（3)のステップ SF6の判定結果が「YES」となる。よって、ゲーム装置 2Aのプロセッサ 21は参加者追加処理を行う（ステップ SF7)。

[0071] 図 20は参加者追加処理を示すフローチャートである。参加者追加処理は、ゲーム参加要求を送信したスレーブを参加者として許可するか拒否する処理である。

参加者追加処理では、まず、受信したゲーム参加要求の送信元のゲーム装置 2をゲーム参加者に追加するとゲーム参加者人数が最大人数 mを超えるカゝ否かを判定する (ステップ SG1)。つまり、現在のゲーム参加者人数が最大人数 mにすでに一致して、る力否かを判定する。最初にゲーム参加要求を送信したゲーム装置 2Bにつヽては、この判定結果は「NO」となるから、ゲーム装置 2Aのプロセッサ 21は受信したゲーム参カ卩要求を用いてゲーム参加者テーブル T6を更新する (ステップ SG2)。具体的には、受信したゲーム参加要求に含まれている装置情報、個人情報、及び称号識別子と「代替不要」を示す代替状況情報とをゲーム参加者テーブル T6のレコード RC2又は RC3に格納する。最初にゲーム参加要求を受信した場合には、つまりゲーム装置 2Bのためには、レコード RC2が格納に使用される。

[0072] 次に、ゲーム参加を許可する旨の参加許可通知をゲーム参加要求の送信元のゲーム装置 2へ返信することによりゲーム参加を許可して、ゲーム参加者人数 mを 1増加させ 2人とする（ステップ SG3)。この参加許可通知には、マスターのゲーム装置 2 Aの装置情報、個人情報、及び称号識別子が含まれている。次に、プロセッサ 21はゲーム参加を既に許可した他のゲーム装置 2が存在するカゝ否かを判定する (ステップ SG4)。この判定は、ゲーム参加者テーブル T6にゲーム装置自身および直前にゲーム参加を許可した他のゲーム装置とは異なるゲーム装置 2のゲーム情報が格納されている力否かを調べることにより行われる。この判定結果が「NO」の場合、プロセッサ 21は、ゲーム参加者人数 mが最大人数に一致した力否かを判定する (ステップ S G5)。ゲーム装置 2Bが参カ卩要求を送信した場合、ステップ SG5の判定結果が「NO」となる。よって、プロセッサ 21はタイマを再スタートさせる（ステップ SG6)。これによりタイマがタイムアウトするのは、この時点力も 60秒が経過した時点に延期される。このように、スレーブを参加者として許可した場合には、ステップ SF1でスタートしたタイマを再スタートする。従って、タイマがタイムアウトするのは、再スタートの時点から 60秒が経過した時点に延期される。これは、その新たな参加者のゲーム装置でキャラクタ画像および楽曲の選択が完了する前に、ゲーム開始指令を送信することを防止するためである（後述する図 19のステップ SF9, SF10参照）。こうして、ゲーム装置 2Bを新たな参加者として追加する参加者追加処理が終了する。

[0073] マスターであるゲーム装置 2Aからの参加許可通知がスレーブとなるべきゲーム装置 2Bのプロセッサ 21により受信される。これにより、ゲーム装置 2Bにおいて、図 17 のマスター Zスレーブ決定処理のステップ SD10の判定結果が「YES」となる。よって、処理はステップ SD12に進み、ゲーム装置 2Bのプロセッサ 21は、マスターフラグ F に 0を書き込むとともに、受信した参加許可通知を用いてゲーム参加者テーブル T6 を更新する (ステップ SD12)。この更新では、受信したゲーム参加要求に含まれている装置情報、個人情報、及び称号識別子と「代替不要」を示す代替状況情報とがゲーム参加者テーブル T6の空いているレコード RC2に格納される。こうして、ゲーム装置 2Bにおけるマスター Zスレーブ決定処理が終了する。

[0074] ゲーム装置 2Bにおけるマスター Zスレーブ決定処理ではマスターフラグ Fの値は 0 に決定されるから、図 16のステップ SC3の判定結果は「NO」となる。よって、ゲーム装置 2Bのプロセッサ 21は、このゲーム装置自身をスレーブとして認識するとともに参加許可通知の送信元のゲーム装置 2Aをマスターとして認識し、スレーブ処理を行う（ステップ SC5)。

[0075] 図 21はスレーブ処理を示すフローチャートである。スレーブ処理の主要な処理には、キャラクタ画像および楽曲選択処理が含まれる。以下、詳述する。

[0076] プロセッサ 21は、スタート時点から 60秒経過するとタイムアウトするタイマをスタートさせるとともに、キャラクタ画像および楽曲選択処理を開始する (ステップ SH1)。上述の通り、ゲーム装置 2A〜2Cの各々において、プレイヤ一は自分で使用するキャラクタ画像および一つの楽曲を選択する（図 11)。キャラクタ画像および楽曲選択処理では、キャラクタ画像や楽曲の選択を促す画像をゲーム装置 2の表示装置 24に表示させつつ、、キャラクタ画像および楽曲を確定的に選択する旨を示す入力装置 23からの入力信号の供給を待つ。この選択処理は後述のステップ SH2〜SH8の処理と並列に行われ、ステップ SH7又は SH8の判定結果が「YES」となると終了する。

[0077] ステップ SH2〜SH8の処理では、プロセッサ 21は、ステップ SH7又は SH8の判定結果が「YES」となるまで、次に列記する処理を順に繰り返し行う。

(A)自分のプレイヤーのキャラクタ画像および楽曲の選択が完了した力否かを判定し (ステップ SH2)、完了したと判定した場合にのみ、選択結果を表す選択情報 (画像識別子および楽曲識別子)をマスターへ送信する (ステップ SH3)。

(B)他のゲーム装置 (マスター)から共有情報を受信した力否かを判定し (ステップ S H4)、この判定結果が「YES」の場合にのみ、タイマを再スタートさせ (ステップ SH5) 、ゲーム参加者テーブル T6を更新する (ステップ SH6)。この更新では、受信した共有情報に含まれている装置情報、個人情報、及び称号識別子と「代替不要」を示す代替状況情報とをゲーム参加者テーブル T6のレコード RC3に格納する。

(C)他のゲーム装置 (マスター)力もゲーム開始指令を受信した力否かを判定する (ステツプ SH7)。

(D)タイマがタイムアウトした力否かを判定する（ステップ SH8)。

ゲーム装置 2Aにお!/、て前述のマスター処理（図 19)の（1)〜（5)の繰り返し処理が行われており、かつゲーム装置 2Bにお!/、て上述のスレーブ処理（図 21)の（A)〜（D )の繰り返し処理が行われている間に、図 10に示すように、ゲーム装置 2Cにおいて多人数参加モードが選択されると仮定する。この場合、ゲーム装置 2Cのプロセッサ 2 1は、ゲーム装置 2Bのプロセッサ 21と同様に、図 16の多人数参加ゲーム処理を開始し、前記の初期化を実行する (ステップ SC1)。ただし、ゲーム装置 2Cのゲーム参加者テーブル T6はゲーム装置 2Cの格納部 27に確保され、このゲーム参加者テーブノレ T6のレコード RC1にはゲーム装置 2C自身の装置情報とゲーム装置 2Cのプロセッサ 21がデータサーバ 4から受信した認証結果に含まれているゲーム装置 2Cのプレイヤーの個人情報 (カード ID「C」に対応付けられた個人情報）とが格納される。この後、マスター Zスレーブ決定処理 (ステップ SC2)において、ゲーム装置 2Cのプロセッサ 21は図 17に示すようにエントリーリスト要求を送信する（ステップ SD1)。図 10に示すように、このエントリーリスト要求にもゲームレベル（1)が指定されている。一つのゲームに参カ卩可能な最大人数は 3であるので、同じゲームレベルで 3番目にェントリーリスト要求を送信したゲーム装置 2Cはスレーブとなるべきである。マスター/ スレーブ決定処理（図 17)において、ゲーム装置 2Cのプロセッサ 21は、ゲーム装置 2Bのプロセッサ 21と同様のステップを経て、マスターの候補であるゲーム装置 2Aにゲーム参加要求を送信する（ステップ SD9)。ゲーム装置 2Cからゲーム装置 2Aへ送信されるゲーム参加要求には、ゲーム装置 2Cの装置情報、個人情報、及び称号識別子が含まれている。

[0079] ゲーム装置 2Cからのゲーム参加要求はゲーム装置 2Aのプロセッサ 21により受信される。このプロセッサ 21が行う参加者追加処理（図 20)は、このプロセッサ 21がゲーム装置 2Bからのゲーム参加要求を受信したときに行った処理と同様である。ただし、図 20のステップ SG2において情報が格納されるのはレコード RC3である。よって、ステップ SG2の処理が終わると、ゲーム装置 2Aのゲーム参加者テーブル T6のレコード RC1〜RC3が埋められる。また、ステップ SG3において返信される参加許可通知には、ゲーム装置 2Aの装置情報、個人情報、及び称号識別子と、ゲーム装置 2B の装置情報、個人情報、及び称号識別子とが含まれている。よって、図 17のステップ SD12の処理が終わると、ゲーム装置 2Cのゲーム参加者テーブル T6のレコード RC 1〜RC3が埋められ、以降、ゲーム装置 2Cのプロセッサ 21は自己をスレーブと認識して動作する。

[0080] また、マスターのゲーム装置 2Aでは、他のスレーブのゲーム装置 2Bについて既にゲーム参カ卩を許可しているから、参加者追加処理（図 20)でのステップ SG4の判定結果が「YES」となる。したがって、ゲーム装置 2Aのプロセッサ 21は既にゲーム参加を許可済みのゲーム装置 2Bへ共有情報を送信する (ステップ SG7)。この共有情報には、最後にゲーム参加を許可したゲーム装置 2Cの装置情報、個人情報、及び称号識別子が含まれている。

[0081] ゲーム装置 2Aからの共有情報はゲーム装置 2Bのプロセッサ 21により受信される。

これにより、スレーブ処理（図 21)の前述の（B)のステップ SH4の判定結果が「YES」となる。よって、このプロセッサ 21は、タイマを再スタートさせ (ステップ SH5)、ゲーム参加者テーブル T6を更新する (ステップ SH6)。この更新では、受信した共有情報に含まれている装置情報、個人情報、及び称号識別子と「代替不要」を示す代替状況情報とがゲーム参加者テーブル T6の空いているレコード RC3に格納される。こうして、ゲーム装置 2Cのゲーム参加者テーブル T6のレコード RC1〜RC3が埋められる。以降、ゲーム装置 2Cにおける処理はステップ SH7に移行する。

[0082] 一方、ゲーム装置 2Aのプロセッサ 21は、共有情報を送信した後に、ゲーム参加者人数が最大人数に一致した力否かを判定する（図 20のステップ SG5)。ゲーム参カロ者人数はステップ SG2にて 3人になっているから、この判定結果が「YES」となる。よつて、プロセッサ 21は前述のゲームレベルを示す情報を含むエントリー削除要求（en try deletion request)をロビーサーバ 3へ送信する（ステップ SG8)。以降、ゲーム装置 2Aにおける処理はステップ SG6に移行する。エントリー削除要求は、エントリ一削除要求に示されたゲームレベルに対応するエントリーリストから、エントリー削除要求の送信元のゲーム装置の通信アドレスを削除することをロビーサーバ 3に要請する。

[0083] ゲーム装置 2Aからのエントリー削除要求はロビーサーバ 3のプロセッサ 31により受信される。プロセッサ 31が受信した要求はエントリーリスト要求ではなぐエントリ一登録要求でもないから、図 18のステップ SE2及び SE4の判定結果は「NO」となる。よつて、プロセッサ 31は受信した要求がエントリー削除要求であるか否かを判定する (ステツプ SE6)。この局面ではこの判定結果力^ YES」となる。よって、プロセッサ 31は、受信したエントリー削除要求で示されるゲームレベルに応じたエントリーリスト L1から、この情報に含まれて、る送信元情報と一致する情報を削除する (ステップ SE7)。つまり、ゲーム装置 2Aの通信アドレスを示す情報が含まれないように、格納部 33のエントリーリスト L1を更新する。これにより、エントリーリスト L1に登録されたマスターの通信アドレスの数は 1つ減少し、エントリーリスト L1は空となる。このようにして参加者グルーピングが終了し、ゲーム装置 2A〜2Cがーつのゲームをプレイするグループとされる。以降、ロビーサーバ 3における処理はステップ SE1に戻る。

[0084] この後、図 10に示すように、ゲーム装置 2Dにおいて多人数参加モードが選択されると仮定する。直前の参加者グルーピングの終了の際にエントリーリスト L1からゲーム装置 2Aの通信アドレスが削除されるので、このとき、ロビーサーバ 3のエントリーリスト L1は空である。 4番目にエントリーリスト要求を送信したゲーム装置 2Dは、空のェントリーリスト L1をロビーサーバ 3から受信する。空のエントリーリストを受信したゲーム装置 2Dは、ゲームレベル（1)を指定したエントリー登録要求をロビーサーバ 3に送信し、以下ゲーム装置 2Aと同様にマスターとして動作し、スレーブとなるべきゲーム装置からのゲーム参加要求を待つ。図 10では、ゲームレベル L1の参加者に関する情報フローのみが示されており、これらに対してロビーサーバ 3はエントリーリスト L1を用いて対処する。図示されていないが、ロビーサーバ 3は、エントリーリスト L2を用いてゲームレベル L2の参加者にも同様に対処する。

[0085] 以上のように、同じゲームレベルの 4番目にエントリーリスト要求を送信したゲーム装置 2Dはマスターとなり、同じゲームレベルの 5番目および 6番目にエントリーリスト要求を送信した二つのゲーム装置はスレーブとなる。以下、同様に、同じゲームレベルの 7, 10, 13, . . .番目のエントリーリスト要求を送信したゲーム装置はマスターになり、エントリーリスト要求を送信した他のゲーム装置はスレーブになる。つまり、同じゲ一ムレベルの参カ卩の順序数 (エントリーリスト要求の送信順序数）を iとし、一つのゲームに参カ卩可能な最大人数を mとした場合に、 i mod m=j = lであれば、そのゲーム装置はマスターになり、 j = 2または 0の場合はスレーブになる。

[0086] しかし、通信遅延または短期間でのゲーム参加希望者の集中などの要因により、ゲーム装置 2Aからのエントリー削除要求よりも先に 4番目のゲーム装置 2Dからのェントリーリスト要求がロビーサーバ装置 3に届くと、ロビーサーバ 3からゲーム装置 2Dへ、ゲーム装置 2Aの通信アドレスを示す情報を含むエントリーリスト L1が送信されることがありうる。この場合、ゲーム装置 2Dは、一時的にスレーブとして振る舞い、ゲーム装置 2Aにゲーム参カ卩要求を送信してしまう。しかし、この局面ではゲーム参加者人数が最大人数に一致して、るから、ゲーム装置 2D力ものゲーム参加要求を受けたゲーム装置 2Aにおいては図 20のステップ SG1の判定結果が「YES」となる。よって、ゲーム装置 2Aのプロセッサ 21は、ゲーム装置 2Dからのゲーム参加要求に対して参加拒否通知を返信する (ステップ SG9)。以降、ゲーム装置 2Aにおける処理は図 19 のステップ SF8に移行する。

[0087] ゲーム装置 2Aからの参加拒否通知はゲーム装置 2Dのプロセッサ 21により受信される。これにより、ゲーム装置 2Dにおいて図 17のステップ SD11の判定結果が「YE S」となる。よって、ゲーム装置 2Dのプロセッサ 21は、参加拒否通知に含まれている送信元情報を含むように参加拒否受信履歴リストを更新することによりゲーム装置 2A の通信アドレスを参加拒否受信履歴リストに登録する。また、ゲーム装置 2Dのプロセッサ 21は、変数 kを 1増加させることにより、エントリーリスト L1における次の通信アドレス（k= 2番目の通信アドレス）に注目する（ステップ SD 13)。そして、注目した通信アドレスがエントリーリスト L1に実在する力否かを判定する (ステップ SD14)。この判定結果が「YES」であれば処理がステップ SD9に戻ってゲーム装置 2A以外のマスタ一に対してゲーム参カ卩要求を送信する力ステップ SD14の判定結果が「NO」であれば、処理はステップ SD1に戻る。つまり、ロビーサーバ 3からエントリーリスト L1を取得する処理からやり直しになる。

このやり直しにおいてもゲーム装置 2Aからのエントリー削除要求がロビーサーバ 3 に届ヽてヽな、場合、ゲーム装置 2Dのプロセッサ 21はゲーム装置 2Aの通信アドレスを示す情報を含むエントリーリスト L1を受信することになる。しかし、参加拒否受信履歴リストにはゲーム装置 2Aの通信アドレスが登録されているから、ステップ SD6にて、受信したエントリーリスト L1は空になる。よって、ステップ SD7の判定結果は「YE S」となり、処理はステップ SD4に移行する。以降、ゲーム装置 4Dはマスターとして動作する。

[0088] 図 11には参加者グルーピングされたゲーム装置 2A〜2Cがゲームを開始するまでの動作が示されている。ゲーム装置 2A〜2Cの各々において、プレイヤーが自分で使用するキャラクタ画像および一つの楽曲を選択する。スレーブのゲーム装置 2Bは、選択されたキャラクタ画像を示す画像識別子と選択された楽曲を示す楽曲識別子を特定し、これらを含む選択情報をマスター (ゲーム装置 2A)へ送信する。同様に、スレーブのゲーム装置 2Cは画像識別子と楽曲識別子を含む選択情報をマスター（ゲーム装置 2A)へ送信する。すべてのスレーブ力選択情報を受信したマスターのゲーム装置 2Aは、曲順を決定した後、各スレーブにゲーム開始指令を送信する。図 11の動作は、各ゲーム装置 2のプロセッサ 21が図 19のマスター処理および図 21のスレーブ処理を行うことによってもたらされる。

[0089] 図 11では、まず、ゲーム装置 2Aにおいてキャラクタ画像および楽曲が選択される。

すると、ゲーム装置 2Aにおいて、マスター処理（図 19)の（1)のステップ SF2の判定結果が「YES」となり、プロセッサ 21は、表示装置 24に表示させている画像および入力装置 23から供給される入力信号に基づヽて、選択されたキャラクタ画像を示す画像識別子と選択された楽曲を示す楽曲識別子を特定し、これらを含む選択情報をゲーム参加者テーブル T6に格納する（ステップ SF3)。

[0090] 次に、図 11では、ゲーム装置 2Bにおいてキャラクタ画像および楽曲が選択される。

すると、ゲーム装置 2Bにおいて、スレーブ処理（図 21)の（A)のステップ SH2の判定結果が「YES」となり、プロセッサ 21は、表示装置 24に表示させている画像と入力装置 23から供給される入力信号とを用いて、選択されたキャラクタ画像を示す画像識別子と選択された楽曲を示す楽曲識別子を特定し、これらを含む選択情報をマスタ一（ゲーム装置 2A)へ送信する (ステップ SH3)。この選択情報はゲーム装置 2Aのプロセッサ 21により受信される。ゲーム装置 2Aでは、マスター処理（図 19)のタイマ力 Sタイムアウトしてな、から（ステップ SF9)、 (2)のステップ SF4の判定結果が「YES 」となり、プロセッサ 21は、受信した選択情報をゲーム参加者テーブル T6のレコード RC2に格納する（ステップ SF5)。

[0091] 次に、図 11では、ゲーム装置 2Cにおいてキャラクタ画像および楽曲が選択される。すると、ゲーム装置 2Cにおいて、上述のゲーム装置 2Bと同様に選択情報をマスタ一（ゲーム装置 2A)へ送信する。ただし、ゲーム装置 2Aにおいて、マスター処理（図 19)のステップ SF5で、ゲーム装置 2Cからの選択情報はゲーム参加者テーブル T6 のレコード RC3に格納される。

[0092] このように、ゲーム装置 2Aではタイマがタイムアウトする前に最大人数（3人）分の選択が完了するから、マスター処理（図 19)の（4)のステップ SF8の判定結果が「YE S」となって繰り返し処理を抜ける。よって、次にプロセッサ 21は、送出領域 R1に他のゲーム参加者のゲーム装置 2Bを、送出領域 R2に他のゲーム参加者のゲーム装置 2 Cを対応付けるとともに、ゲームの開始時期を通知するゲーム開始指令をスレーブ（ゲーム装置 2B及び 2C)へ送信してマスター処理を終える（ステップ SF10)。以降、ゲーム装置 2Aではゲーム開始指令で示された時期にゲームが開始される。ゲーム開始指令はゲーム装置 2A〜2Cの各々に対応した情報セットを含んでいる。各情報セットは、対応するゲーム装置 2の通信アドレスを示す情報、対応するゲーム装置 2 にて選択されたキャラクタ画像の画像識別子、対応するゲーム装置 2にて選択された楽曲の楽曲識別子、及び対応するゲーム装置 2にて特定された称号識別子を含む。また、ゲーム開始指令は 3つの楽曲識別子で示される 3曲の曲順をも示している。さらに、ゲーム開始指令は、ゲームを開始すべき時期も示す。即ち、マスターのプロセッサ 21は、ゲームの開始時期を 2以上の他のゲーム装置に通知する処理と、開始時期でプレイヤーがゲームをプレイ可能にする処理を実行する。

[0093] ゲーム装置 2A (マスター）からのゲーム開始指令はスレーブのプロセッサ 21により受信される。これにより、ゲーム装置 2B及び 2Cでは、スレーブ処理（図 21)の（C)のステップ SH7の判定結果が「YES」となって (A)〜（D)の繰り返し処理を抜ける。次にスレーブのプロセッサ 21は、受信したゲーム開始指令を用いてゲーム参加者テーブル T6を更新する (ステップ SH9)。具体的には、このゲーム開始指令に含まれている画像識別子、楽曲識別子および称号識別子をゲーム参加者テーブル T6の該当するレコードに格納する。こうして、スレーブにおいて、スレーブ処理が終了し、ゲームが開始される。スレーブのゲーム開始時期は、ゲーム開始指令で示された時期である。即ち、スレーブのプロセッサ 21はマスターから開始時期の通知を受信すると、その開始時期でプログラムを実行して、プレイヤーがゲームをプレイ可能にする処理を実行する。これにより、複数のゲーム装置 2A、 2B及び 2Cにおいて、ゲームの開始を同期させることが可能となる。スレーブのプロセッサ 21は、不足する参加者については仮想ゲーム装置をスタートさせる。不足する参加者に対応するレコードにつ、ての代替状況情報は、初期化段階（図 16のステップ SC1)で「要代替」に設定されてから変化せず（図 21のステップ SH6による参加者テーブル T6の更新がされないためである）、プロセッサ 21はそのレコードに対応する仮想ゲーム装置をスタートさせる。ゲーム開始に伴い、ゲーム装置 A1〜A3にとつてのエントリー期間が終了する。以降は、各ゲーム装置が対等な関係で他のいずれのゲーム装置とも通信を行う。

[0094] 但し、スレーブ処理（図 21)における（A)〜（D)の繰り返し処理においてタイマがタィムアウトすると、（D)のステップ SH8の判定結果が「YES」となって繰り返し処理を抜ける。次にスレーブのプロセッサ 21は、キャラクタ画像および楽曲の選択が未完了であるか否かを判定する (ステップ SH10)。この判定結果が「YES」の場合には、プ口セッサ 21は仮選択されて!、るキャラクタ画像および楽曲を強制的に選択し、この選択結果を示す選択情報をゲーム参加者テーブル T6に格納し、さらにこの選択結果を示す選択情報 (画像識別子および楽曲識別子)をマスターへ送信する (ステップ S Hl l)。この後プロセッサ 21は、ゲーム開始指令の受信を待つ (ステップ SH12)。逆にステップ SH10の判定が「NO」の場合には、処理はステップ SH 12に移行する。

[0095] マスターのタイマのタイムアウト時期はスレーブのタイマのタイムアウト時期よりも遅い。これは、参加者追加処理（図 20)でスレーブを参加者として許可するたびに、マスターのタイマを再スタートしてその新たな参加者のプレイヤーに、キャラクタ画像および楽曲の選択のための猶予時間を与えるためである。したがって、マスターのプロセッサ 21は、スレーブのタイマがタイムアウトした後にスレーブから送信されてくる選択情報をも、マスターのタイマのタイムアウト前、すなゎち図19の3 2〜3 9 ( (1)〜 (5) )の繰り返し処理を行っている間に受信することができる。

[0096] また、マスターにぉける図19の3 2〜3 9 ( (1)〜（5) )の繰り返し処理にぉぃてタイマがタイムアウトした場合には、（5)のステップ SF9の判定結果が「YES」となって繰り返し処理を抜ける。次にマスターのプロセッサ 21は、キャラクタ画像および楽曲の選択が未完了である力否かを判定する (ステップ SF11)。前述のように、スレーブでは設定時間内にキャラクタ画像および楽曲の選択がされないと強制的に選択が行われ、それらからの選択情報はマスターのタイムアウト前に確実にマスターに届くから、この判定では、マスターを使用中のプレイヤーによる選択が未完了かどうかのみに注目すれば足りる。インターネット 1における信号遅延を考慮して、マスターにおけるタイマの再スタート時 (ステップ SF7)にタイムアウトまでの時間を 60秒より長く設定するようにしてちょい。

[0097] ステップ SF11の判定結果が「YES」の場合、マスターのプロセッサ 21は、仮選択されているキャラクタ画像および楽曲を強制的に選択し、この選択結果を示す選択情報をゲーム参加者テーブル T6に格納する（ステップ SF12)。次にプロセッサ 21は、ゲーム参加者人数が最大人数 m未満であるか否かを判定する (ステップ SF13)。また、ステップ SF11の判定結果が「NO」の場合にも処理はステップ SF13に移行する。ステップ SF13の判定結果が「YES」の場合 (つまり参加者が不足する場合）、プロセッサ 21は前述のエントリー削除要求をロビーサーバ 3へ送信する（ステップ SF14) 。以降、処理はステップ SF10に移行し、スレーブが存在すればプロセッサ 21はゲーム開始指令をスレーブに送信するとともに、不足するスレーブについては仮想ゲーム装置をスタートさせる。不足する参加者に対応するレコードにつ、ての代替状況情報は、初期化段階（図 16のステップ SC1)で「要代替」に設定されてから変化せず（図 2 0のステップ SG2による参加者テーブル T6の更新がされないためである）、マスターはそのレコードに対応する仮想ゲーム装置をスタートさせる。

[0098] また、ステップ SF13の判定結果が「NO」の場合（つまり参加者がすでに最大人数に一致している場合）にも、処理はステップ SF10に移行する。この場合には、ステツプ SF10でプロセッサ 21はゲーム開始指令を各スレーブに送信する。参加者がすでに最大人数に一致している場合には、エントリー削除要求は、参加者追加処理 (ステップ SF7)、具体的には図 20のステップ SG5, SG8の処理ですでに送信されている

[0099] 図 12には多人数参加ゲームの開始後の動作が示されている。ゲーム開始後は、ゲーム装置 2A〜2Cの各々は、自装置のスコア情報 (スコアおよびボーナスポイント）を定期的に他のゲーム装置に送信する。ゲーム装置 2A〜2Cの各々は、自装置および他装置のスコア情報を図 8のゲーム参加者テーブル T6に格納する。また、自装置のプレイヤーのスコアとボーナスポイントは図 2のゲーム画面の下部に表示され、他のプレイヤーのスコアは、図 2のゲーム画面の右部に表示される。

図 12の動作は、ゲーム装置 2A〜2Cのプロセッサ 21が図 16の多人数参加ゲーム処理を行い、データサーノのプロセッサ 41が図 14の個人情報処理を行うことによつてもたらされる。ゲーム開始後の動作では、ゲーム装置 2間にマスター Zスレーブの関係は存在せず、各ゲーム装置 2の通信制御は個別に行われることになる。即ち、各ゲーム装置 2のプロセッサ 21は、マスター処理でのゲーム開始指令の送信（図 19 のステップ SF10)、またはスレーブ処理でのゲーム開始指令の受信（図 21のステツプ SH7または SH12)を条件として、マスター Zスレーブの関係を解消し、 2以上の他のゲーム装置との間の通信方式を個別通信モードに移行させる移行部として機能する。

[0100] 図 16に説明を戻す。マスター処理またはスレーブ処理を終えたプロセッサ 21は、 n = 1曲目の楽曲に注目する (ステップ SC6)。具体的には変数 nを 1にセットする。 nは曲順情報に示されたこのゲームに用いられる 3つの楽曲の使用順序数である。次に代替すべきゲーム装置 2が存在する力否かを判定する (ステップ SC7)。具体的には、「要代替」を示す代替状況情報を格納したレコードがゲーム参加者テーブル T6内に存在するか否かを調べる。この時点でのゲーム参加者テーブル T6の全てのレコード RC1〜RC3に「代替不要」を示す代替状況情報が格納されて!、れば、ステップ SC 7の判定結果は「NO」となり、処理はステップ SC8に移行する。

[0101] ステップ SC8では、プロセッサ 21は n= l曲目のミニゲーム処理を行う。 n曲目のミ二ゲーム処理とは、 n曲目のミニゲームをプレイヤーに行わせるために各ゲーム装置 2が行う処理である。ミニゲーム処理には、入力装置 23からの入力信号に基づいてスコアおよびボーナスポイントの算出を行うとともに他のプレイヤーへの攻撃イベントを発生させながら、ゲーム参加者テーブル T6に基づいて図 2に示すようなゲーム画面を表示する処理や、図 22の交換情報送信処理 (後述する）、図 23の交換情報受信処理 (後述する）が含まれており、これらは並列に実行される。

[0102] この局面で表示されるゲーム画面の左部には、このゲーム装置 2を使用中のプレイヤーにより選択されたキャラクタ画像が配置されており、右部には、ゲームを現在プレィして、るすべてのプレイヤー（このゲーム画像を見て、るこのゲーム装置のプレイヤ一を含む）に対応するキャラクタ画像の部分画像が配置されている。最も下にある部分画像はこのゲーム装置のプレイヤーに対応し、他の部分画像は他のプレイヤーに対応する。また、各部分画像の近傍には、部分画像に対応するプレイヤーのプレイヤー名および称号の画像が配置されている。ミニゲーム開始直後であるから、実際には、全てのスコアおよびボーナスポイントは 0、全てのセリフは空、操作適時性ゲージ MGが示す操作適時性の累積値は 0、攻撃レベル ALは 1となっており、また、水平ライン HLの近くまで落下して!/、るオブジェクト OBは未だ無!、。

[0103] 図 22に示すように、交換情報送信処理では、ゲーム装置 2のプロセッサ 21は、まず、0秒〜0. 5秒の範囲内のランダムな時間だけ待機する（ステップ SJ1)。図 12の動作例では、ゲーム装置 2Aに遅れてゲーム装置 2B力更に遅れてゲーム装置 2Cが待機を終えている。待機を終えたプロセッサ 21は、送出領域 R1及び R2の記憶内容をクリアし (ステップ SJ2)、 0. 5秒が経過するとタイムアウトするタイマをスタートさせる (ステップ SJ3)。以降、このタイマがタイムアウトするまで、楽曲が終了した力否かの判定 (ステップ SJ4)と、攻撃イベントが発生したか否かの判定 (ステップ SJ5)と、タイマがタイムアウトしたか否かの判定 (ステップ SJ6)とを順に繰り返し行う。

[0104] タイマがタイムアウトし、ステップ SJ6の判定結果が「YES」となると、プロセッサ 21はスコア情報を格納部 27の所定領域力も読み出す (ステップ SJ7)。スコア情報には、表示装置 24に表示されているスコアを示す情報とボーナスポイントを示す情報とが含まれており、交換情報送信処理および交換情報受信処理以外のゲーム処理により所定領域に書き込まれて更新されている。次にプロセッサ 21は読み出したスコア情報を送出領域 R1及び R2に書き込む (ステップ SJ8)。次にプロセッサ 21は、送出領域 R1及び R2内の情報を、各送出領域に対応付けられたゲーム装置 2の代替状態に応じた方法で送出する (ステップ SJ9)。具体的には、各送出領域に対応付けられたゲーム装置 2につヽてゲーム参加者テーブル T6を調べ、対応する代替状況情報が「代替不要」又は「要代替」を示す場合には当該ゲーム装置 2へ送信し、「2」を示す場合には当該ゲーム装置 2を代替している仮想ゲーム装置に引き渡す。例えば、ゲーム装置 2Aにお、て、ゲーム参加者テーブル T6のどのレコードでも代替状況情報が「代替不要」であれば、送出領域 R1内の情報はゲーム装置 2Bへ、送出領域 R2 内の情報はゲーム装置 2Cへ送信される。いずれかのレコードの代替状況情報が「要代替」であれば、そのレコードに対応する送出領域の情報は仮想ゲーム装置に引き渡される。また、ステップ SJ9において、プロセッサ 21は、送出する情報に攻撃識別子が含まれて!/、る場合には後述のセリフ表示処理を行う。

[0105] 一方、図 23に示すように、交換情報受信処理では、ゲーム装置 2のプロセッサ 21 は、楽曲が終了するまで、次の（ Q；)〜（ δ )の処理を順に繰り返して行う。

( a )攻撃識別子を受け取つたか否かを判定し (ステップ SK1)、受け取つたと判定した場合にのみ、受け取った攻撃識別子で示される種類の攻撃を実行する (ステップ S K2)。具体的には、ゲーム装置 2を使用中のプレイヤーのプレイを邪魔するようにゲーム装置 2を制御する。より具体的には、表示中のゲーム画面の幅を狭くしたり、暗くしたり、揺らしたり、スピーカ 25から出力される楽音の音量を小さくしたり楽音の出力時期を遅らせたりしてゲームの難易度を高くする。また、攻撃識別子を受け取ったゲーム装置は、ステップ SK2では攻撃を実行するとともにセリフ表示処理を行う。セリフ表示処理とは、攻撃識別子の送信元のゲーム装置につ！、て攻撃時セリフを示す個人情報がゲーム参加者テーブル T6に格納されている場合には、このセリフをゲーム画面上の該当箇所に一定時間だけ表示させる（例えば図 2の「まいったか！」）。また、セリフ表示処理では、このゲーム装置自身について被攻撃時セリフを示す個人情報がゲーム参加者テーブル T6に格納されている場合にはこのセリフをゲーム画面上の該当箇所に一定時間だけ表示させる。

( j8 )スコア情報を受け取った力否かを判定し (ステップ SK3)、受け取つたと判定した場合にのみ、受け取ったスコア情報でゲーム参加者テーブル T6を更新する (ステツプ SK4)。具体的には、受け取ったスコア情報をゲーム参加者テーブル T6の該当するレコードに格納する。

( _Ύ )ゲームに参加する他のゲーム装置 2の少なくとも 1つについて通信断が検出された力否かを判定し、通信断が検出されたと判定した場合にのみ (ステップ SK5)、通信断が検出されたゲーム装置 2の代替を予約する (ステップ SK6)。具体的には、交換情報受信処理においてプロセッサ 21はゲームに参加する他のゲーム装置 2毎に通信を監視しており、該当するゲーム装置 2から最後に情報を受信した時点から所定の時間が経過すると、このゲーム装置 2について通信断を検出し、通信断が検出されたゲーム装置 2に対応付けてゲーム参加者テーブル T6に格納されてヽる、「代替不要」を示す代替状況情報を、「要代替」を示すように更新する。実施に代替が開始されるのは、図 16のステップ SC11の代替開始処理である。通信断の検出方法は任意であり、例えば、ゲーム装置 2が情報を受信すると即座に確認応答を返信するように設計されて、る場合には所定の時間内に確認応答を受信することができなかつたことをもって通信断を検出するようにしてもょ、。

( δ )楽曲が終了した力否かを判定する (ステップ SK7)。

図 12の動作例では、交換情報送信処理においてゲーム装置 2Aに遅れてゲーム装置 2Bが、更に遅れてゲーム装置 2Cが待機を終えているから、まずゲーム装置 2A からゲーム装置 2B及び 2Cへ情報が送信され、次にゲーム装置 2Bからゲーム装置 2 A及び 2Cへ情報が送信され、次にゲーム装置 2Cからゲーム装置 2A及び 2Bへ情報が送信される。これらの情報は、それぞれ、宛先のゲーム装置 2により受信される。ここで受信される情報はスコア情報であるから、各ゲーム装置 2では、交換情報受信処理にお、て（ j8 )のステップ SK3の判定結果が「YES」となる。よって、各ゲーム装置 2のプロセッサ 21は、受信したスコア情報でゲーム参加者テーブル T6を更新する (ステツプ SK4)。この結果、まずゲーム装置 2B及び 2Cの、次にゲーム装置 2A及び 2C の、次にゲーム装置 2A及び 2Bのゲーム画面にお!、て他のゲーム参加者のスコア及びボーナスポイントが更新される。

[0107] 交換情報送信処理（図 22)では、ステップ SJ9の後、処理はステップ SJ2に戻る。つまり、 0. 5秒間隔で、直前の 0. 5秒の間に送出領域に書き込まれた情報が送出される。よって、スコア情報の送受信が 0. 5秒周期で繰り返し行われる。

[0108] また、ゲーム装置 2において、ゲームの状況が特定の状況になって攻撃イベントが発生することがある。具体的には、ゲーム画面上で特定のタイプのオブジェクト OBが水平ライン HLに重なったときにこのオブジェクト OBのタイプに応じた操作が行われて攻撃イベントが発生する。すると、ゲーム装置 2Aでの交換情報送信処理においてステップ SJ5の判定結果が「YES」となり、プロセッサ 21はゲームの状況に応じて攻撃識別子 (攻撃の種類を識別する）を決定する (ステップ SJ10)。具体的には、このときの攻撃レベル ALが 1であるか 2であるかを判定し、判定結果に応じた攻撃識別子がゲーム参加者テーブル T6のレコード RC1に格納されてヽる個人情報で示されて V、ればこの攻撃識別子に決定し、示されて!/、なければランダムに攻撃識別子を定める。次にプロセッサ 21は、攻撃識別子の書き込み先 (送出領域 R1及び R2の少なくとも一方。すなわち攻撃される他のゲーム装置に対応する）をランダムに選択し、攻撃識別子を選択した書き込み先に追記する (ステップ SJ11)。送出領域 R1及び R2の各々は、攻撃識別子とスコア情報の両方を同時に格納可能である。図 12に示すように、攻撃識別子がゲーム装置 2Bに送信される場合、攻撃識別子は送出領域 R1に追記される。

[0109] 以降、処理はステップ SJ6に移行する。この後、タイマがタイムアウトすると、プロセッサ 21は、最終的に、スコア情報を送出領域 R1及び R2に追記し (ステップ SJ8)、各ゲーム装置に送信する。例えば、ゲーム装置 2Aは、送出領域 R1内の攻撃識別子およびスコア情報をゲーム装置 2Bへ送信するとともに、送出領域 R2内のスコア情報をゲーム装置 2Cへ送信する (ステップ SJ9)。つまり、攻撃識別子は、 0. 5秒周期で繰り返し行われるスコア情報の送受信においてスコア情報と一緒に送受信される。また、ステップ SJ9ではセリフ表示処理も行われ、当該ゲーム装置にっ、てゲーム参加者テーブル T6のレコード RC1に格納されている個人情報で示される攻撃時セリフがゲーム画面上の該当箇所に一定時間だけ表示される。

[0110] ゲーム装置 2Bでは、ゲーム装置 2Aからの攻撃識別子を受信することにより、交換情報受信処理にぉ、て（ α )のステップ SKIの判定結果が「YES」となる。よって、ゲーム装置 2Bのプロセッサ 21は、受信した攻撃識別子で示される攻撃を実行する (ステツプ SK2)。これにより、ゲーム装置 2Bにおけるゲームの進行が変化し、その難易度が高くなる。また、ステップ SK2ではセリフ表示処理も行われるから、図 2に示すように、ゲーム装置 2Aについてゲーム参加者テーブル T6のレコード RC2に格納されている個人情報で示される攻撃時セリフがゲーム画面上の該当箇所に一定時間だけ表示される。

[0111] 図 12の動作例では、通信断が検出されることなく最初の楽曲が終了する。楽曲が終了すると、ステップ SJ4の判定結果が「YES」となって交換情報送信処理が終了するとともに（ δ )のステップ SK7の判定結果が「YES」となって交換情報受信処理が終了する。こうして、ゲーム装置 2A〜2Cにおいて n= l曲目のミニゲーム処理が終了する。

説明を図 16に戻す。次に、プロセッサ 21は、次の楽曲に注目し (ステップ SC9)、この楽曲が実在する力否かを判定する (ステップ SC10)。具体的には、 nをインクリメントし、インクリメント後の nが 3以下である力否かを判定する。ここでは、 n= 2≤3であるから、ステップ SC10の判定結果は「YES」となる。よって、処理はステップ SC7に移行する。

[0112] 以降、前述と同様の流れとなり、 n= 2曲目のミニゲーム処理 (交換情報送信処理および交換情報受信処理）が行われる (ステップ SC7及び SC8)。このミニゲーム処理において、図 12の動作例では、ゲーム装置 2Aに異常が発生し、ゲーム装置 2B及び 2Cはゲーム装置 2Aと通信不能となったと仮定する。よって、ゲーム装置 2B及び 2C において、ゲーム装置 2Aから最後に情報を受信した時点力所定時間が経過すると、交換情報受信処理において、（γ )つまり図 23のステップ SK5の判定結果が「YE S」となる。よって、ゲーム装置 2B及び 2Cのプロセッサ 21は、通信断となったゲーム装置 2の代替を予約する (ステップ SK6)。この結果、ゲーム装置 2B及び 2Cにおけるゲーム参加者テーブル T6は、ゲーム装置 2Aに対応するレコード RC2に「要代替」を示す代替状況情報が格納されるように更新される。一方、ゲーム装置 2B及び 2Cにおける交換情報送信処理では、「代替中」を示す代替状況情報を格納したレコードがゲーム参加者テーブル T6内に存在しな!、ため、プロセッサ 21はゲーム装置 2Aにもスコア情報を送信し続ける（図 22のステップ SJ9)。

[0113] 以降、 n= l曲目のミニゲーム処理と同様の流れとなる。そして、 2番目の楽曲が終了すると、ゲーム装置 2B及び 2Cにおいて n= 2曲目のミニゲーム処理が終了する。以降、ゲーム装置 2B及び 2Cでは、 n= l曲目のミニゲーム処理後と同様の処理が行われるが、ステップ SC7の判定結果は「YES」となる。ゲーム参加者テーブル T6に「要代替」を示す代替状況情報が格納されているからである。よって、プロセッサ 21は、代替すべきゲーム装置 2を仮想ゲーム装置で代替させるための代替開始処理を行う（ステップ SC11)。具体的には、仮想ゲーム装置を生成し、ゲーム参加者テーブル T6における代替すべきゲーム装置 2Aに応じたレコード RC2からスコア情報を読み出し、このスコア情報を仮想ゲーム装置にセットし、レコード RC2に「代替中」を示す代替状況情報を格納することによりゲーム参加者テーブル T6を更新する。こうして、ゲーム装置 2Bにおいてはゲーム装置 BA力ゲーム装置 2Cにおいては仮想ゲーム装置 CAが生成される。また、通信不能となったゲーム装置 2Aも、他のゲーム装置 2 B, 2Cをそれぞれ代替する仮想ゲーム装置を生成する。

[0114] 次にプロセッサ 21は n= 3曲目のミニゲーム処理を行う（ステップ SC8)。このミニゲーム処理においては、交換情報送信処理にて、ゲーム装置 2Bのプロセッサ 21は、ゲーム参加者テーブル T6を調べ、送出領域 R1内の情報を仮想ゲーム装置 BAに引き渡す（図 22のステップ SJ9)。一方、ゲーム装置 2Cのプロセッサ 21は、ゲーム参カロ者テーブル T6を調べ、送出領域 R1内の情報を仮想ゲーム装置 CAに引き渡す。通信不能となったゲーム装置 2Aも、他のゲーム装置 2B, 2Cをそれぞれ代替する仮想ゲーム装置へ送出領域 Rl, R2内の情報を引き渡す。つまり、情報が通信不能なルートを介して交換されることはなぐ無駄な送信を避けることができる。また、各ゲーム装置のプロセッサ 21は、交換情報受信処理にて、対応する仮想ゲーム装置から攻撃識別子を引き渡されたことをもって攻撃識別子を受け取つたと判定し (図 23のステップ SK1)、スコア情報を引き渡されたことをもってスコア情報を受け取つたと判定する（ステップ SK3)。よって、ゲーム装置 2Bはゲーム装置 2C及び仮想ゲーム装置 BA と多人数参加型ゲームを継続し、ゲーム装置 2Cはゲーム装置 2B及び仮想ゲーム装置 CAと多人数参加型ゲームを継続することができる。ゲーム装置 2Aも、二つの仮想ゲーム装置と多人数参加型ゲームを継続することができる。

[0115] ゲーム装置 2B及び 2Cにおいて、 3番目の楽曲が終了し、 n= 3曲目のミニゲーム処理が終了すると、以降、 n= l曲目のミニゲーム処理後と同様の処理が行われるが、 nがインクリメントされて 4となるから、ステップ SC10の判定結果は「NO」となる。よつて、ゲーム装置 2B及び 2Cのプロセッサ 21は、ゲーム参加者テーブル T6に格納されたスコア情報に基づいてスコア算出処理を行う（ステップ SC12)。このスコア算出処理では、ゲーム装置毎にボーナスポイントをスコアに変換して楽曲毎のスコアを算出し、 3曲分のスコアを合計して合計スコアを求め、求めた合計スコアを表示装置 24に表示させる。次にプロセッサ 21は、新しいプレイヤーレベルを決定し、今回のゲームを反映したゲーム履歴や新、プレイヤーレベルを示すようにゲーム参加者テープル T6内の該当する個人情報を更新する。通信が可能である限り、各ゲーム装置は、更新後の個人情報を含む更新要求をデータサーバ 4へ送信する (ステップ SC13)。こうしてこのゲーム処理が終了する。

[0116] 説明を図 14の個人情報認証 Z登録処理に戻す。データサーノのプロセッサ 41 は、ゲーム装置 2からの受信した要求が認証要求でもカード登録要求でもな、と判定した場合には、受信した情報が更新要求である力否かを判定する (ステップ SB1、 S B2、 SB6及び SB8)。受信した情報が更新要求である場合には、ステップ SB8の判定結果は「YES」となる。よって、プロセッサ 41は、この更新要求に含まれている個人情報を個人情報テーブル T1に上書き格納する (ステップ SB9)。この結果、個人情報テーブル Tlの内容は最新となる。

以上、現時点において、最も実践的であり、かつ好ましいと思われる実施形態に関連して本発明を説明したが、本発明は明細書中に開示された実施形態に限定されるものではなぐ請求の範囲及び明細書全体力読みとれる発明の要旨あるいは思想に反しない範囲で適宜変更可能であり、そのような変更を伴うゲーム装置もまた本発明の技術的範囲に包含されるものとして理解されなければならない。

Claims

請求の範囲

[1] 他のゲーム装置と通信する通信部と、

ゲームプログラムを実行してプレイヤーがゲームをプレイすることを可能にするゲームプログラム実行部と、

ゲームの参加者となる 2以上の前記他のゲーム装置を特定して、前記ゲームプログラム実行部にゲームを開始させる制御部と、

プレイ中のゲームの進行に応じてゲーム情報を生成し、前記通信部を用いて、前記 2以上の他のゲーム装置の各々に生成した前記ゲーム情報を送信するゲーム情報生成部と、

前記通信部を用いて、前記 2以上の他のゲーム装置の各々で生成されたゲーム情報を受信して、受信した前記ゲーム情報に応じてゲームの進行を変化させる変化部と、

を備えるゲーム装置。

[2] 前記制御部は、

このゲーム装置自身がマスターとなるべき力スレーブになるべきかを所定の判定条件に基づ、て判定する判定部と、

ゲームに参加する他のゲーム装置の通信アドレスを記憶する記憶部と、前記判定部によってこのゲーム装置自身がマスターであると判定された場合、スレーブとなるべき他のゲーム装置力のゲーム参カ卩要求を待ち、前記ゲーム参加要求を受信すると、参加者の人数が所定数に達しない限りゲーム参加を許可することを示す応答を返信し、スレーブとなるべき前記 2以上の他のゲーム装置の通信アドレスを前記記憶部に記憶させ、前記スレーブとなるべき他のゲーム装置の各々に対して他のスレーブとなるべきゲーム装置の通信アドレスを送信するマスター機能実行部と、前記判定部によってこのゲーム装置自身がスレーブであると判定された場合、マスターの候補であるゲーム装置に対してゲーム参カ卩要求を送信し、マスターとなるべきゲーム装置カゝらゲーム参加を許可することを示す応答を受信すると、マスターとなるべきゲーム装置から取得した他のスレーブとなるべきゲーム装置の通信アドレスとマスターとなるべきゲーム装置の通信アドレスとを前記記憶部に記憶させるスレーブ機能実行部とを備え、

前記ゲーム情報生成部は、前記記憶部に記憶された通信アドレスを用いて、前記 2 以上の他のゲーム装置の各々に前記ゲーム情報を送信する、

ことを特徴とする請求項 1に記載のゲーム装置。

[3] 前記マスター機能実行部は、ゲームの開始時期を前記 2以上の他のゲーム装置に通知し、前記開始時期にゲームプログラムを実行してプレイヤーがゲームをプレイすることが可能になることが開始するように前記ゲームプログラム実行部を制御し、前記スレーブ機能実行部は、マスターから前記開始時期の通知を受信すると、前記開始時期にゲームプログラムを実行してプレイヤーがゲームをプレイすることが可能になることが開始するように前記ゲームプログラム実行部を制御する、

ことを特徴とする請求項 2に記載のゲーム装置。

[4] 前記制御部は、所定の条件が充足されると、このゲーム装置と前記 2以上の他のゲーム装置との間の通信モードを、このゲーム装置が前記 2以上の他のゲーム装置の各々と並行に通信するとともに、前記ゲーム情報生成部及び前記変化部が有効に作動する、他の通信モードに移行させる通信モード移行部を備えることを特徴とする請求項 3に記載のゲーム装置。

[5] 前記移行部に関する前記所定の条件は、前記マスター機能実行部が前記開始時期を前記 2以上の他のゲーム装置に通知したこと、または、前記スレーブ機能実行部がマスター力前記開始時期の通知を受信したことであることを特徴とする請求項 4 に記載のゲーム装置。

[6] 画像を表示する表示部と、

プレイヤーの操作に応じた信号を出力する入力装置とをさらに備え、

前記ゲームプログラム実行部は、前記信号に応じてゲームを進行させるとともに、ゲームの進行に応じた画像を前記表示部に表示させ、

前記ゲーム情報生成部は、前記入力装置の操作に応じて取得した得点を示す得点情報を前記ゲーム情報として生成し、この得点情報を前記 2以上の他のゲーム装置の各々に送信し、

前記変化部は、前記得点情報を前記ゲーム情報として受信すると、受信した前記得点情報に応じた画像を前記表示部に表示させる、

ことを特徴とする請求項 1に記載のゲーム装置。

[7] 画像を表示する表示部と、

プレイヤーの操作に応じた信号を出力する入力装置とを備え、

前記ゲーム情報生成部は、前記入力装置の操作に応じて他のゲーム参加者に不利になるゲーム要素を指示する攻撃情報を前記ゲーム情報として生成し、この攻撃情報を前記 2以上の他のゲーム装置のうち少なくとも一つに送信し、

前記変化部は、前記攻撃情報を前記ゲーム情報として受信すると、受信した前記攻撃情報の指示する前記ゲーム要素に応じた画像を前記表示部に表示させる、ことを特徴とする請求項 1に記載のゲーム装置。

[8] 前記入力装置力の信号に基づいて、前記他のゲーム装置のうちどれが前記攻撃情報の送信先となるべき力を特定する送信先特定部をさらに備え、

前記ゲーム情報生成部は、生成した前記攻撃情報を前記送信先特定部により特定された前記他のゲーム装置へ送信する

ことを特徴とする請求項 7に記載のゲーム装置。

[9] ゲームに参加する前記 2以上の他のゲーム装置との通信を監視して通信断を検出する検出部を備え、

前記ゲーム情報生成部は、前記検出部により通信断が検出された他のゲーム装置への前記ゲーム情報の送信を停止し、ゲームに参加する残りの他のゲーム装置に対して、前記ゲーム情報の送信を続行する、

ことを特徴とする請求項 1に記載のゲーム装置。

[10] 前記ゲームプログラム実行部は、前記検出部により通信断が検出されたゲーム装置の替わりに参加者としてゲームをプレイし、通信断が検出されたゲーム装置が生成すべきであった前記ゲーム情報を生成して、このゲーム情報を前記変化部に引き渡し、

前記変化部は、前記検出部により通信断が検出されれた他のゲーム装置の替わりに前記ゲームプログラム実行部力前記ゲーム情報を取得すると共に、ゲームに参加する残りの他のゲーム装置力の前記ゲーム情報の取得を続行し、取得した前記ゲーム情報に応じてゲームの進行を変化させる、

ことを特徴とする請求項 9に記載のゲーム装置。

前記ゲームプログラム実行部は、前記プログラムに従って複数の曲を順次演奏し、前記検出部により通信断が検出されたときに演奏中の曲の次の曲の演奏開始から、通信断が検出された他のゲーム装置の替わりに参加者としてゲームをプレイし始めることを特徴とする請求項 10に記載のゲーム装置。