(57)【特許請求の範囲】
【請求項１】
第１店舗内の第１内部ネットワークに接続され、少なくとも第２店舗内の第２内部ネットワークに接続される他のゲーム装置の通信アドレスを外部ネットワークを介して受信して対戦相手の通信アドレスとし、ネットワーク対戦型ゲームを行うゲーム装置において、
ゲームの進行を管理するマスタ端末になる優先度を示す第１マスタ優先度Mp1を、前記第１店舗の状況に基づいて演算する演算手段と、
前記第１マスタ優先度Mp1を、前記外部ネットワークを介して対戦相手に送信する送信手段と、
前記他のゲーム装置のマスタ端末になる優先度を示す第2マスタ優先度Mp2を、前記外部ネットワークを介して受信する受信手段と、
前記第１マスタ優先度Mp1及び前記第２マスタ優先度Mp2を比較し、比較結果に基づいてマスタ端末又はスレーブ端末になるかを決定する決定手段と、
を有することを特徴とするゲーム装置。
【請求項２】
前記ゲーム装置は、前記決定手段で決定された結果を送信する決定結果送信手段と、他の決定結果送信手段から送信される結果を受信する決定結果受信手段と、をさらに有しており、
前記決定結果受信手段が前記第１内部ネットワークに接続されている別のゲーム装置の決定結果送信手段から送信される結果を受信した場合、前記演算手段は、前記第１店舗内のマスタ端末数及びスレーブ端末数を店舗状況に含めてそれらに基づいて前記第１マスタ優先度Mp1を演算することを特徴とする、請求項１に記載のゲーム装置。
【請求項３】
前記演算手段は、前記第１内部ネットワークと前記外部ネットワークとを結ぶ前記第１店舗の通信回線の通信帯域と、マスタ端末に割り当てられる通信帯域と、スレーブ端末に割り当てられる通信帯域とを店舗状況に含めてそれらに基づいて前記第１マスタ優先度Mp1を演算することを特徴とする、請求項１又は２に記載のゲーム装置。
【請求項４】
前記ゲーム装置は、プレイヤがマスタ端末でゲームを行った回数及びスレーブ端末でゲームを行った回数に基づくプレイヤのゲーム経験値を記憶する第１経験値記憶手段と、前記ゲーム経験値を更新する第１更新手段とをさらに有し、
前記演算手段は、前記第１経験値記憶手段に記憶されているゲーム経験値と店舗状況とを合わせてそれらに基づいて前記第１マスタ優先度Mp1を演算し、
前記第１更新手段は、前記決定手段による決定に応じ、前記ゲーム経験値に所定値を加算することにより前記ゲーム経験値を更新することを特徴とする、請求項１、２又は３に記載のゲーム装置。
【請求項５】
前記ゲーム装置は、プレイヤがゲームを行った回数であるゲーム回数とプレイヤがマスタ端末でゲームを行った回数であるマスタ回数とを記憶する第２経験値記憶手段と、前記ゲーム回数及びマスタ回数を更新する第２更新手段とをさらに有し、
前記演算手段は、前記ゲーム回数に対するマスタ回数の比と店舗状況とを合わせてそれらに基づいて前記第１マスタ優先度Mp1を演算し、
前記第２更新手段は、ゲーム回数を増加させることによりゲーム回数を更新し、前記決定手段による決定に応じてマスタ回数を増加させることによりマスタ回数を更新することを特徴とする、請求項１，２又は３に記載のゲーム装置。
【請求項６】
マスタ端末またはスレーブ端末になる場合に前記外部ネットワークに接続する前記第１店舗の通信帯域をオーバーするか否かを判断する第１通信帯域監視手段を有し、前記第１通信帯域監視手段は、マスタ端末となる場合に通信帯域をオーバーするときはマスタ禁止フラグを、スレーブ端末となる場合に通信帯域をオーバーするときはスレーブ禁止フラグをそれぞれオンに設定し、
前記第１通信帯域監視手段によって設定されたフラグを送信するフラグ送信手段と、前記他のゲーム装置のフラグ送信手段から送信されたフラグを外部ネットワークを介して受信するフラグ受信手段とを有し、
前記決定手段は、第１マスタ優先度Mp1及び前記第２マスタ優先度Mp2の比較よりも前記第１通信帯域監視手段によって設定されたフラグ又は前記フラグ受信手段によって受信したフラグに基づいてマスタ端末又はスレーブ端末になるかを優先して決定することを特徴とする、請求項１乃至５のいずれか１に記載のゲーム装置。
【請求項７】
前記決定手段による決定によって前記外部ネットワークに接続する前記第１店舗の通信帯域をオーバーするか否かを判断する第２通信帯域監視手段と、
前記第１店舗の通信帯域をオーバーする場合、且つ、前記第1内部ネットワークに複数のゲーム装置が接続されている場合、同一店舗内の少なくとも１つの他のゲーム装置に対し、マスタ端末からスレーブ端末への変更またはスレーブ端末からマスタ端末への変更を依頼する変更依頼メッセージを、前記第１内部ネットワークを介して送信する変更依頼送信手段と、
をさらに備えることを特徴とする、請求項１乃至５のいずれか１に記載のゲーム装置。
【請求項８】
前記決定手段は、前記第１マスタ優先度Mp1と前記第２マスタ優先度Mp2とが競合した場合、前記第１内部ネットワーク及び前記第２内部ネットワーク上で各ゲーム装置を識別する識別子に基づいて、前記ゲーム装置がマスタ端末になるかスレーブ端末になるかを決定することを特徴とする、請求項１乃至７のいずれか１に記載のゲーム装置。
【請求項９】
前記第２店舗内のゲーム装置に加え、前記第１店舗内の他のゲーム装置が対戦相手にさらに含まれているか否かを判断する店舗内対戦相手判断手段と、
対戦相手が同一店舗内に存在する場合、同一店舗内で対戦するゲーム装置のうちゲーム装置自身がマスタ端末又はスレーブ端末のうちいずれの候補になるかを所定のマスタ候補決定データに基づいて決定する候補決定手段と、をさらに有し、
前記候補決定手段がゲーム装置自身はマスタ候補であると決定した場合、前記演算手段は、同一店舗内で対戦する他のゲーム装置をスレーブ端末と見なして第１マスタ優先度Ｍｐ１を演算し、
前記決定手段は、ゲーム装置自身がマスタ候補の場合には、前記第１マスタ優先度Mp1及び前記受信手段が受信した第２マスタ優先度Mp2を比較し、比較結果に基づいてマスタ端末又はスレーブ端末のどちらになるかを決定することを特徴とする、請求項１に記載のゲーム装置。
【請求項１０】
第１店舗内の第１内部ネットワークに接続され、少なくとも第２店舗内の第２内部ネットワークに接続される他のゲーム装置の通信アドレスを外部ネットワークを介して受信して対戦相手の通信アドレスとし、ネットワーク対戦型ゲームを行うゲーム装置が行うゲーム方法であって、
ゲームの進行を管理するマスタ端末になる優先度を示す第１マスタ優先度Mp1を、前記第１店舗の状況に基づいて演算する演算ステップと、
前記第１マスタ優先度Mp1を、前記外部ネットワークを介して対戦相手に送信する送信ステップと、
前記他のゲーム装置のマスタ端末になる優先度を示す第2マスタ優先度Mp2を、前記外部ネットワークを介して受信する受信ステップと、
前記第１マスタ優先度Mp1及び前記第２マスタ優先度Mp2を比較し、比較結果に基づいてマスタ端末又はスレーブ端末になるかを決定する決定ステップと、
を含むことを特徴とするゲーム方法。
【請求項１１】
第１店舗内の第１内部ネットワークに接続され、少なくとも第２店舗内の第２内部ネットワークに接続される他のゲーム装置の通信アドレスを外部ネットワークを介して受信して対戦相手の通信アドレスとし、ネットワーク対戦型ゲームを行うゲーム装置としてコンピュータを機能させるためのゲームプログラムであって、
ゲームの進行を管理するマスタ端末になる優先度を示す第１マスタ優先度Mp1を、前記第１店舗の状況に基づいて演算する演算手段、
前記第１マスタ優先度Mp1を、前記外部ネットワークを介して対戦相手に送信する送信手段、
前記他のゲーム装置のマスタ端末になる優先度を示す第2マスタ優先度Mp2を、前記外部ネットワークを介して受信する受信手段、及び
前記第１マスタ優先度Mp1及び前記第２マスタ優先度Mp2を比較し、比較結果に基づいてマスタ端末又はスレーブ端末になるかを決定する決定手段、
として前記コンピュータを機能させるゲームプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介して接続されたゲーム装置同士が対戦するネットワーク対戦型ゲームに関する。
【背景技術】
【０００２】
近年、ゲームセンターなど店頭に設置されるゲーム装置、いわゆるアーケードゲームにおけるネットワーク対戦型ゲームが提案されている。ネットワーク対戦型ゲームでは、プレイヤが操作するゲーム装置のいずれかがマスタ端末となり、他のゲーム装置はスレーブ端末となるのが通常である。マスタ端末はゲームの進行を管理し、スレーブ端末はゲームの操作情報を出力する。（特許文献１参照）
より詳しくは、マスタ端末は、１）プレイヤによる操作指示入力を受け付け、２）プレイヤによりスレーブ端末へ入力されたデータをスレーブ端末受信し、３）マスタ端末における指示入力及びスレーブ端末からの指示入力に基づいてゲームの進行を管理し、４）ゲームの進行状況に基づいてゲーム装置自身で画面出力や音声出力を制御し、５）ゲームの進行状況を示す出力データを各スレーブ端末に送信する。一方、スレーブ端末は、１）プレイヤの操作指示入力を受け付け、２）プレイヤにより入力されたデータをマスタ端末に送信し、３）出力データをマスタ端末から受信し、４）受信した出力データに基づいて画面出力や音声出力を制御する。
【特許文献１】特開平８−２０６３６１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
上述したように、マスタ端末はスレーブ端末へゲームの進行状況を示す出力データを送信するのに対し、スレーブ端末は逆にこれをマスタ端末から受信する。そのため、マスタ端末は、送信用の通信帯域を、受信用の通信帯域よりも多く必要とする。逆に、スレーブ端末は、受信用の通信帯域を、送信用の通信帯域よりも多く必要とする。
一方、ゲームセンターの送信用及び受信用通信帯域は、一般的には同じではない。通常は、受信用通信帯域の方が送信用通信帯域よりも大きくなるように設定されている。これは、受信用通信帯域の不足によるパケットロスなどを防ぐためである。
【０００４】
また、ゲームセンターの通信帯域は、各ゲームセンターによって異なるのが通常である。あるゲームセンターでは送信用通信帯域が４Ｍｂｐｓ、受信用通信帯域が６Ｍｂｐｓであっても、別のゲームセンターでは送信用通信帯域が１Ｍｂｐｓ、受信用通信帯域が３００Ｋｂｐｓしかないこともあり得る。
ところで、１つのゲームセンター内に複数のゲーム装置がある場合、マスタ端末及びスレーブ端末の比率は、一定ではなく状況に応じて変化する。マスタ端末が多すぎると、ゲームセンターの送信用の通信帯域が不足する一方で受信用の通信帯域が余ってしまうことがあり得る。逆にスレーブ端末が多すぎると、ゲームセンターの送信用の通信帯域は余っている一方で、受信用の通信帯域が不足することがあり得る。今後アーケードゲームにおけるネットワーク対戦型ゲームが普及すると、このような事態を防止し、ゲームセンターが有する通信帯域を有効に利用することが望まれる。
【０００５】
また、あるゲームセンターＳ１ではマスタ端末が多く、別のゲームセンターＳ２ではスレーブ端末が多い状態が恒常的に発生すると、ゲームセンターＳ１とＳ２との間に不公平が生じる。なぜなら、プレイヤにとってはマスタ端末の方がゲーム進行上有利であり、とりわけ動きの早いゲームではその傾向が強くなる。そうすると、ネットワーク対戦型アーケードゲームがより普及したときには、プレイヤにとって有利なマスタ端末が多いゲームセンターＳ１の集客率が上がり、ゲームセンターＳ２の集客率は下がる事態が予測される。
【０００６】
本発明は、ネットワーク対戦型のゲーム装置が設置されている店舗の通信帯域を有効に活用し、円滑なネットワーク対戦を実現することを目的とする。
また本発明は、ネットワーク対戦型のゲーム装置が設置されている店舗間に不公平感が生じるのを防止することを目的とする。
【課題を解決するための手段】
【０００７】
前記の課題を解決するために、本願発明１は、第１店舗内の第１内部ネットワークに接続され、少なくとも第２店舗内の第２内部ネットワークに接続される他のゲーム装置の通信アドレスを外部ネットワークを介して受信して対戦相手の通信アドレスとし、ネットワーク対戦型ゲームを行うゲーム装置を提供する。このゲーム装置は、以下の手段を有することを特徴とする。
・ゲームの進行を管理するマスタ端末になる優先度を示す第１マスタ優先度Mp1を、前記第１店舗の状況に基づいて演算する演算手段、
・前記第１マスタ優先度Mp1を、前記外部ネットワークを介して対戦相手に送信する送信手段、
・前記他のゲーム装置のマスタ端末になる優先度を示す第2マスタ優先度Mp2を、前記外部ネットワークを介して受信する受信手段、
・前記第１マスタ優先度Mp1及び前記第２マスタ優先度Mp2を比較し、比較結果に基づいてマスタ端末又はスレーブ端末になるかを決定する決定手段。
【０００８】
このゲーム装置は、ネットワークを介して他のゲーム装置と接続された場合、マスタ端末またはスレーブ端末となってネットワーク対戦型ゲームを実行する。マスタ端末はゲームの進行を管理する。スレーブ端末は、マスタ端末から送信されるデータに基づく表示処理を行ったり、プレイヤの指示入力データをマスタ端末に送信したりする。マスタ端末となるか否かは、マスタ優先度に基づいて決定する。
【０００９】
より具体的には、ゲーム装置は、１以上の対戦相手とゲーム装置自身との間でマスタ優先度Mpを比較し、マスタ優先度Mpが一番高い端末をマスタ端末として決定する。マスタ優先度Mpは、店舗内のＬＡＮと外部ネットワークとを結ぶ店舗の通信回線の通信帯域や、店舗内のマスタ端末数とスレーブ端末数との比などに基づいて算出される。マスタ優先度Ｍｐに基づいてマスタ端末を決定することで、店舗の通信回線の通信帯域を有効に利用したり、店舗内のゲーム装置がマスタ端末またはスレーブ端末に偏ることを防止できる。
【００１０】
本願発明２は、前記発明１において、前記決定手段で決定された結果を送信する決定結果送信手段と、他の決定結果送信手段から送信される結果を受信する決定結果受信手段と、をさらに有するゲーム装置を提供する。前記決定結果受信手段が前記第１内部ネットワークに接続されている別のゲーム装置の決定結果送信手段から送信される結果を受信した場合、前記演算手段は、前記第１店舗内のマスタ端末数及びスレーブ端末数を店舗状況に含め、それらに基づいて前記第１マスタ優先度Mp1を演算する。
【００１１】
例えば、任意の店舗に設置されたゲーム装置は、マスタ優先度Mpを下式（１）に基づいて求めることができる。
Mp＝Nｓ−Ｎｍ                                          ・・・（１）
ここで、Nm：店舗内の現在のマスタ端末数
Ｎｓ：店舗内の現在のスレーブ端末数
店舗内のマスタ端末数Nm及びスレーブ端末数Nsは、決定結果受信手段が他のゲーム装置の決定結果送信手段から受信する決定結果を蓄積することにより、把握することができる。式（１）を用いれば、マスタ端末数Nmが多いほどマスタ優先度Mpが下がり、スレーブ端末数Nｓが多いほどマスタ優先度Mpが上がる。従って、同一店舗内がマスタ端末またはスレーブ端末のいずれか一方ばかりになることを防止できる。言い換えれば、同一店舗内のマスタ端末数とスレーブ端末数とのバランスを保ち、店舗間での公平性を担保することができる。
【００１２】
本願発明３は、前記発明１又は２において、前記演算手段は、前記第１内部ネットワークと前記外部ネットワークとを結ぶ前記第１店舗の通信回線の通信帯域と、マスタ端末に割り当てられる通信帯域と、スレーブ端末に割り当てられる通信帯域とを店舗状況に含め、それらに基づいて前記第１マスタ優先度Mp1を演算するゲーム装置を提供する。
例えば、任意の店舗に設置されたゲーム装置は、マスタ優先度Mpを下式（２）に基づいて演算することができる。
【００１３】
Mp＝Ｌｍ−Ｌｓ                                              （２）
ここで、Ｌｍ：ゲーム装置自身がマスタ端末になった場合の店舗の通信帯域の残り
Ｌｓ：ゲーム装置自身がスレーブ端末になった場合の店舗の通信帯域の残り
店舗の通信帯域とは、ＬＡＮ等の内部ネットワークと外部ネットワークとを結ぶ通信回線の通信帯域である。式（２）を用いれば、スレーブ端末になる場合に比してマスタ端末になった方が店舗内の通信帯域にゆとりがある場合、マスタ優先度Ｍｐが高くなる。その逆の場合、マスタ優先度Ｍｐは低下する。このようにして求めたマスタ優先度Mpに従えは、各店舗の通信帯域を有効に利用することができる。
【００１４】
本願発明４は、前記発明１、２又は３のいずれかにおいて、プレイヤがマスタ端末でゲームを行った回数及びスレーブ端末でゲームを行った回数に基づくプレイヤのゲーム経験値を記憶する第１経験値記憶手段と、前記ゲーム経験値を更新する第１更新手段とをさらに有するゲーム装置を提供する。このゲーム装置において、前記演算手段は、前記第１経験値記憶手段に記憶されているゲーム経験値と店舗状況とを合わせてそれらに基づいて前記第１マスタ優先度Mp1を演算する。前記第１更新手段は、前記決定手段による決定に応じ、前記ゲーム経験値に所定値を加算することにより前記ゲーム経験値を更新する。
【００１５】
ゲーム経験値とは、プレイヤが過去のゲームにおいてどのくらいマスタになりどのくらいスレーブになったかを示す値である。例えば、マスタ端末になった場合には“１”を、スレーブ端末になった場合には“−１”を、それぞれプレイヤのゲーム経験値に加算する。このようにして求めたプレイヤの最新のゲーム経験値を用い、例えばマスタ優先度Ｍｐを下式（３）で求めることができる。
【００１６】
Ｍｐ＝（Ｎｓ−Ｎｍ）×ｎ＋Ｅ                                    （３）
ここで、ｎ：Ｅに比して十分大きい正の数
Ｅ：プレイヤのゲーム経験値
Nm：店舗内の現在のマスタ端末数
Ｎｓ：店舗内の現在のスレーブ端末数
例えば、上式（３）を用いると、上式（１）だけでは対戦相手のマスタ優先度Mp2とゲーム装置自身のマスタ優先度Mp1とが同じになってしまう場合でも、互いのマスタ優先度に差を付けることができる。また、プレイヤがマスタ端末ばかりを経験したりスレーブ端末ばかりを経験するといった、プレイヤ間での不公平感を防止することができる。
【００１７】
本願発明５は、前記発明１、２又は３において、プレイヤがゲームを行った回数であるゲーム回数とプレイヤがマスタ端末でゲームを行った回数であるマスタ回数とを記憶する第２経験値記憶手段と、前記ゲーム回数及びマスタ回数を更新する第２更新手段とをさらに有するゲーム装置を提供する。このゲーム装置において、前記演算手段は、前記ゲーム回数に対するマスタ回数の比と店舗状況とを合わせてそれらに基づいて前記第１マスタ優先度Mp1を演算する。前記第２更新手段は、ゲーム回数を増加させることによりゲーム回数を更新し、前記決定手段による決定に応じてマスタ回数を増加させることによりマスタ回数を更新する。
【００１８】
例えば、上記式（３）において（マスタ回数）／（ゲーム回数）をゲーム経験値に代えて用いることにより、マスタ優先度を演算することが挙げられる。ゲームの体験回数に差があるプレイヤ同士のマスタ優先度を比較する場合であっても、ゲーム回数の差がマスタ優先度Ｍｐに及ぼす影響を緩和することができる。
本願発明６は、前記発明１乃至５において、マスタ端末またはスレーブ端末になる場合に前記外部ネットワークに接続する前記第１店舗の通信帯域をオーバーするか否かを判断する第１通信帯域監視手段を有するゲーム装置を提供する。前記第１通信帯域監視手段は、マスタ端末となる場合に通信帯域をオーバーするときはマスタ禁止フラグを、スレーブ端末となる場合に通信帯域をオーバーするときはスレーブ禁止フラグをそれぞれオンに設定する。さらに、このゲーム装置は、前記第１通信帯域監視手段によって設定されたフラグを送信するフラグ送信手段と、前記他のゲーム装置のフラグ送信手段から送信されたフラグを外部ネットワークを介して受信するフラグ受信手段とを有する。前記決定手段は、第１マスタ優先度Mp1及び前記第２マスタ優先度Mp2の比較よりも前記第１通信帯域監視手段によって設定されたフラグ又は前記フラグ受信手段によって受信したフラグに基づいてマスタ端末又はスレーブ端末になるかを優先して決定する。
【００１９】
例えば対戦相手のスレーブ禁止フラグがオンになっており、ゲーム装置自身のマスタ禁止フラグがオンになっていれば、マスタ優先度の比較結果にかかわらず対戦相手をマスタ端末と決定する。スレーブ禁止フラグまたはマスタ禁止フラグ（以下、まとめて禁止フラグと言うことがある）が競合した場合には、１）対戦相手同士を接続しない、２）マスタ優先度に従っていずれかをマスタ端末に決定する、等の処理が考えられる。禁止フラグを参照してマスタ端末を決定することにより、店舗の通信帯域がオーバーしてしまう事態を回避しやすくなる。
【００２０】
本願発明７は、前記発明１乃至５において、第２通信帯域監視手段と変更依頼送信手段とをさらに有するゲーム装置を提供する。前記第２通信帯域監視手段は、決定手段による決定によって前記外部ネットワークに接続する前記第１店舗の通信帯域をオーバーするか否かを判断する。前記変更依頼送信手段は、前記第１店舗の通信帯域をオーバーする場合、且つ、前記第1内部ネットワークに複数のゲーム装置が接続されている場合、同一店舗内の少なくとも１つの他のゲーム装置に対し、マスタ端末からスレーブ端末への変更またはスレーブ端末からマスタ端末への変更を依頼する変更依頼メッセージを、前記第１内部ネットワークを介して送信する。
【００２１】
例えば、第１店舗のゲーム装置T1と第２店舗のゲーム装置T2とが対戦しようとしている場合のゲーム装置T1の処理を考える。ゲーム装置T1のマスタ優先度Mp1と対戦相手T2のマスタ優先度Mp2とを比較した結果、ゲーム装置T1がマスタ端末、ゲーム装置T2がスレーブ端末になったとする。しかし、ゲーム装置T1がマスタ端末になると第１店舗における通信帯域がオーバーする場合、ゲーム装置T1の変更依頼送信手段は、同一店舗内の１以上の他のゲーム装置に対し、マスタ端末からスレーブ端末への変更依頼メッセージを、第１内部ネットワークを介して送信する。
【００２２】
本願発明８は、前記発明１乃至７において、前記決定手段は、前記第１マスタ優先度Mp1と前記第２マスタ優先度Mp2とが競合した場合、前記第１内部ネットワーク及び前記第２内部ネットワーク上で各ゲーム装置を識別する識別子に基づいて、前記ゲーム装置がマスタ端末になるかスレーブ端末になるかを決定することを特徴とするゲーム装置を提供する。
【００２３】
識別子とは、例えばIPアドレス、各ゲーム装置固有の装置番号などである。第１店舗のゲーム装置T1のマスタ優先度Mp1と第２店舗のゲーム装置T2のマスタ優先度Mp2とが競合した場合、両者のIPアドレスの大小に基づいてマスタ端末を決定しても良い。なお、マスタ優先度Mp1、Mp2が競合するとは、２つのマスタ優先度が全く同じである場合のみならず、その差が所定値以下の場合を含んでいてもよい。
【００２４】
本願発明９は、前記発明１において、店舗内対戦相手判断手段と候補決定手段とをさらに有するゲーム装置を提供する。このゲーム装置自身がマスタ候補の場合には、マスタ端末又はスレーブ端末のどちらになるかを決定する。店舗内対戦相手判断手段は、前記第２店舗内のゲーム装置に加え、前記第１店舗内の他のゲーム装置が対戦相手にさらに含まれているか否かを判断する。候補決定手段は、対戦相手が同一店舗内に存在する場合、同一店舗内で対戦するゲーム装置のうちゲーム装置自身がマスタ端末又はスレーブ端末のうちいずれの候補になるかを所定のマスタ候補決定データに基づいて決定する。前記候補決定手段がゲーム装置自身はマスタ候補であると決定した場合、前記演算手段は、同一店舗内で対戦する他のゲーム装置をスレーブ端末と見なして第１マスタ優先度Ｍｐ１を演算する。前記決定手段は、ゲーム装置自身がマスタ候補の場合には、前記第１マスタ優先度Mp1及び前記受信手段が受信した第２マスタ優先度Mp2を比較し、比較結果に基づいてマスタ端末又はスレーブ端末のどちらになるかを決定する。
【００２５】
本発明は、対戦相手の一部が同一店舗内に存在する場合にも適用可能である。例えば、第１店舗内のゲーム装置T1,T2と第２店舗内のゲーム装置T3とが対戦する場合を考える。ゲーム装置T1，T2，T3のいずれかがマスタ端末になるが、第１店舗のゲーム装置T1,T2のうちどちらがマスタ端末になっても第１店舗にとっては同じことである。従って、マスタ端末が第１店舗に割り当てられる場合と第２店舗に割り当てられる場合とに、大別できる。マスタ端末がどちらの店舗に割り当てられるかは両店舗のマスタ優先度によるが、仮に第１店舗に割り当てられる場合にはゲーム装置T1,T2のどちらがマスタ端末になるかを予め決めておく。すなわち、マスタ候補を予め決めておく。例えばＩＰアドレスが一番大きいゲーム装置、例えばゲーム装置T1をマスタ候補に決める。マスタ候補T1は、同一店舗内の対戦相手T2がスレーブ端末であると仮定してマスタ優先度を算出する。さらに、マスタ候補T1は、マスタ優先度を他店舗の対戦相手T3と比較してマスタ端末を決定する。つまり、ゲーム装置T1がマスタ端末になるのか、それとも対戦相手の１つT3がマスタ端末になるのかを、両者のマスタ優先度に基づいて決定する。さらにゲーム装置T1は、その決定を同一店舗内の対戦相手T2に通知する。通知しなければ、ゲーム装置T2は対戦相手のうちどれがマスタ端末になったかが分からないからである。こうすることで、１つのゲームに参加するゲーム装置が同一店舗に複数存在していても、マスタ優先度を用いてマスタ端末を決定することができる。
【００２６】
本願発明１０は、第１店舗内の第１内部ネットワークに接続され、少なくとも第２店舗内の第２内部ネットワークに接続される他のゲーム装置の通信アドレスを外部ネットワークを介して受信して対戦相手の通信アドレスとし、ネットワーク対戦型ゲームを行うゲーム装置が行うゲーム方法を提供する。この方法は、以下のステップを含む。
・ゲームの進行を管理するマスタ端末になる優先度を示す第１マスタ優先度Mp1を、前記第１店舗の状況に基づいて演算する演算ステップ、
・前記第１マスタ優先度Mp1を、前記外部ネットワークを介して対戦相手に送信する送信ステップ、
・前記他のゲーム装置のマスタ端末になる優先度を示す第2マスタ優先度Mp2を、前記外部ネットワークを介して受信する受信ステップ、
・前記第１マスタ優先度Mp1及び前記第２マスタ優先度Mp2を比較し、比較結果に基づいてマスタ端末又はスレーブ端末になるかを決定する決定ステップ。
【００２７】
この方法は、前記第１発明に係るゲーム装置が実行する。前記第１発明と同様の作用効果を奏する。
本願発明１１は、第１店舗内の第１内部ネットワークに接続され、少なくとも第２店舗内の第２内部ネットワークに接続される他のゲーム装置の通信アドレスを外部ネットワークを介して受信して対戦相手の通信アドレスとし、ネットワーク対戦型ゲームを行うゲーム装置としてコンピュータを機能させるためのゲームプログラムを提供する。このプログラムは、下記手段として前記コンピュータを機能させる。
・ゲームの進行を管理するマスタ端末になる優先度を示す第１マスタ優先度Mp1を、前記第１店舗の状況に基づいて演算する演算手段、
・前記第１マスタ優先度Mp1を、前記外部ネットワークを介して対戦相手に送信する送信手段、
・前記他のゲーム装置のマスタ端末になる優先度を示す第2マスタ優先度Mp2を、前記外部ネットワークを介して受信する受信手段、
・前記第１マスタ優先度Mp1及び前記第２マスタ優先度Mp2を比較し、比較結果に基づいてマスタ端末又はスレーブ端末になるかを決定する決定手段。
【００２８】
このプログラムは、前記第１発明に係るゲーム装置としてコンピュータを機能させる。前記第１発明と同様の作用効果を奏する。
【発明の効果】
【００２９】
本発明を用いれば、店舗間でネットワーク対戦型ゲームを行う際に、店舗間の公平さを担保し、店舗の通信帯域を有効に活用することができる。
【発明を実施するための最良の形態】
【００３０】
＜発明の概要＞
店舗Ａ内のゲーム装置と店舗Ｂ内のゲーム装置とは、外部ネットワークを介してネットワーク対戦型ゲームを行うにあたり、双方のマスタ優先度Ｍｐに基づいてマスタ端末を決定する。マスタ優先度Ｍｐは、ゲーム装置自身がゲームの進行を管理するマスタ端末になる優先度を示す。この方法は、対戦相手に少なくとも１つの他店舗のゲーム装置を含む場合に適用可能である。また、１対１の対戦のみならず、３者以上の対戦にも適用可能である。
【００３１】
マスタ優先度は、各店舗の状況に応じて演算される。マスタ優先度を求める式は、店舗内のマスタ端末数とスレーブ端末数とのバランスが取れるように、及び／または店舗の通信回線の通信帯域を有効利用できるように、設定される。例えばマスタ優先度は、各店舗内のマスタ端末数及びスレーブ端末数に基づいて演算される。また例えば、マスタ優先度は、店舗内の内部ネットワークと外部ネットワークとを結ぶ通信回線の通信帯域の残りに基づいて演算される。
【００３２】
＜第１実施形態例＞
本実施形態では、異なる店舗Ａ，Ｂに設置された２つのゲーム装置Ｔａ、Ｔｂが１対１のネットワーク対戦型ゲームを行う場合を例に取る。２つのゲーム装置は、それぞれマスタ優先度Ｍｐａ、Ｍｐｂを演算し、相手に通知する。各ゲーム装置は、ゲーム装置自身のマスタ優先度と対戦相手のマスタ優先度とを比較し、どちらか大きい方がマスタ端末であると決定する。その後、それぞれの役割に応じてゲームを開始する。
【００３３】
［構成］
図１は、本発明の第１実施形態例に係るゲーム装置を含むゲームシステムの概略構成を示す説明図である。このゲームシステムは、センターサーバ１００と複数の店舗２００ａ，ｂ・・・とを含んでいる。各店舗２００には、複数のゲーム装置Ｔが設置されている。同一店舗内のゲーム装置Ｔは、互いに内部ネットワーク３０１、例えばＬＡＮ(Local Area Network)により接続されている。さらに、各店舗内のＬＡＮ３０１は、店舗の通信回線（図示せず）を介し、インターネットなどの外部ネットワーク３００に接続されている。外部ネットワーク３００には、各店舗２００に加え、センターサーバ１００が接続されている。図中、店舗２００ａ内のゲーム装置Ｔａと示し、店舗２００ｂ内のゲーム装置Ｔｂと示している。また、マスタ端末として動作しているゲーム装置を“Ｍ”として示し、（スレーブ）端末として動作しているゲーム装置を“Ｓ”として示す。さらに、これからネットワーク対戦型ゲームを開始しようとしており、マスタ端末または（スレーブ）端末の役割が未定のゲーム装置を、“？”として示す。
【００３４】
（１）センターサーバ
センターサーバ１００は、プレイヤ毎の個人データを記憶し、ゲーム装置Ｔからの要求に応じて個人データを要求元ゲーム装置に送信する。図１に示すように、センターサーバ１００は下記の要素（ａ）〜（ｅ）を備えている。
（ａ）CPU１０１：後述するROM１０３に格納されている制御プログラムを読み出し、実行する。
（ｂ）RAM１０２：ゲームを行うに当たりプレイヤ個人が設定するデータや、過去の戦績に基づくデータなど、ゲーム毎に異なる個人データなどを一時的に記憶する。
（ｃ）ROM１０３：制御プログラムや個人データなどを記憶する。
（ｄ）ネットワーク通信部１０４：ネットワーク３００を介し、ゲーム装置Ｔとデータの送受信を行う。
（ｅ）データ蓄積部１０５：ゲーム装置Ｔから送信されてくる個人データなどを蓄積する。
【００３５】
（２）ゲーム装置
図２は、ゲーム装置Ｔの構成を示す。ゲーム装置Ｔは、センターサーバ１００から取得した個人データに基づいて、他のゲーム装置Ｔとネットワーク３００を介し、ゲームを行う。ゲーム装置Ｔは、下記（ａ）〜（ｍ）の要素を有している。
（ａ）CPU２０１：後述するROM２０３に記憶されている制御プログラムを実行する。
（ｂ）RAM２０２：各種変数やパラメータなどを一時的に記憶する。
（ｃ）ROM２０３：制御プログラムや各種パラメータなどを記憶する。
（ｄ）ネットワーク通信部２０４：ネットワーク３００及びＬＡＮ３０１を介し、センターサーバ１００や他のゲーム装置Ｔとデータの送受信を行う。
（ｅ）モニタ２０６：ゲーム画像を表示する。
（ｆ）描画処理部２０５：モニタ２０６に表示する画像データを生成する。
（ｇ）スピーカ２０８：ゲーム実行中やデモ画面表示中のサウンドを出力する。
（ｈ）音声再生部２０７：スピーカ２０８に発音させるためのサウンドデータを生成する。
（ｉ）入力操作部２１１：ジョイスティックや操作ボタンなどから構成されプレイヤの指示入力を受け付ける。
（ｊ）カードリーダ・ライタ２１２：挿入される磁気カードに対してデータの読取・書込処理を実行する。
（ｋ）コイン受付部２１３：挿入されるコインによるクレジットを受け付ける。
（ｌ）外部機器制御部２１０：操作部カードリーダ・ライタ２１２及びコイン受付部２１３などの外部機器を制御する。
（ｍ）外部入出力制御部２０９：カードリーダ・ライタ２１２及びコイン受付部２１３などの外部機器に対する制御信号を生成する。また、外部機器からの検出信号を受信してCPU２０１に送出する。
【００３６】
上記のように構成されたゲーム装置Ｔは、ＲＯＭ２０３に記憶された制御プログラムに従い、次のようにしてゲームを行う。プレイヤは、ゲーム装置Ｔにおいて自己の所有する磁気カードをカードリーダ・ライタ２１２に挿入し、コイン受付部２１３にコインを投入する。ゲーム装置Ｔは、カードリーダ・ライタ２１２に挿入された磁気カードからプレイヤを識別するプレイヤＩＤを読み取り、パスワードによる個人認証を行い、センターサーバ１００のデータ蓄積部１０５に格納されている個人データをダウンロードする。その後、プレイヤがネットワーク対戦を希望した場合ゲーム装置Ｔは、自己のネットワークアドレスをセンターサーバ１００に送信し、対戦相手のネットワークアドレスを取得する。さらに、その時点での店舗２００の状況に基づいてマスタ優先度を演算し、対戦相手に通知する。ゲーム装置自身と対戦相手とでマスタ優先度を比較した後、比較結果に基づいてマスタ端末を決定する。その後、ゲーム装置自身の役割に応じてゲームを開始する。マスタ優先度の演算方法の詳細は後述する。
【００３７】
ゲーム装置自身がスレーブ端末となる場合、マスタ端末となる対戦相手に対し、センターサーバ１００からダウンロードした個人データを送信する。その後、マスタ端末に対し、プレイヤの操作指示入力を示す入力データを送信する。入力データの送信は、操作指示入力が発生する度に行う。また、スレーブ端末は、マスタ端末から出力データを受信し、受信データに基づいて画像や音声を出力する。図３（Ａ）は、スレーブ端末からマスタ端末に送信される入力データの一例を示す。この例は、サッカーゲームの入力データを示す。この入力データは、「上下左右いずれのレバーが入力されたか」、「５つあるボタンのいずれが入力されたか」、を示す。
【００３８】
ゲーム装置自身がマスタ端末となる場合、ゲームに参加する全てのゲーム装置Ｔ（以下、単に全てのゲーム装置Ｔという）の個人データに基づいてゲームを開始する。個人データは、ゲームにより異なる。サッカーゲームを例に挙げれば、チーム名やチームを構成する選手などである。ゲーム開始後は、マスタ端末は、スレーブ端末から入力データを受信し、これに基づいてゲームを進行させる。さらに、マスタ端末はゲームの進行状況に応じた出力データを生成し、スレーブ端末に送信する。出力データの送信は、データの種類に応じた間隔で行うことが好ましい。図３（Ｂ）は、マスタ端末からスレーブ端末に送信される出力データの一例を示す。出力データは、スレーブ端末においてゲーム画面を表示するためのフレームデータやサウンドを出力するための音声データである。この例では、サッカーゲームの場合の出力データの例を示している。マスタ端末は、データの種類に応じた時間間隔で、各種の出力データをスレーブ端末に送信する。例えばフレームデータであれば１／６０(sec)毎に送信する。
【００３９】
［マスタ優先度の演算方法］
対戦するゲーム装置Ｔのうちどれがマスタ端末になるかを決定するために、ＲＯＭ２０３に記憶された制御プログラムはゲーム装置自身のマスタ優先度Ｍｐを演算する。マスタ優先度Ｍｐの演算方法は特に限定されない。ただし、マスタ優先度Ｍｐは、少なくとも店舗状況に基づいて演算される。ここで店舗状況とは、１）店舗内のマスタ端末数Ｎｍ及びスレーブ端末数Ｎｓ、及び／または２）店舗内のＬＡＮ３０１と外部ネットワーク３００とを結ぶ店舗の通信回線の通信帯域である。つまり、店舗内のマスタ端末数Ｎｍ及びスレーブ端末数Ｎｓのバランスが保たれるように、マスタ優先度Ｍｐを演算することが好ましい。また、店舗内のＬＡＮ３０１と外部ネットワーク３００とを結ぶ店舗の通信回線の通信帯域を有効利用できるよう、マスタ優先度Ｍｐを演算することが好ましい。以下にマスタ優先度Ｍｐの演算方法について例を挙げて説明する。
【００４０】
（１）演算方法１
第１の演算方法では、第１マスタ優先度Mp1を、各店舗内のマスタ端末数Ｎｍ及びスレーブ端末数Ｎｓに基づいて演算する。例えば、任意の店舗２００に設置されたゲーム装置Ｔは、マスタ優先度Mpを下式（１）に基づいて求めることができる。
Mp＝Ｎｓ−Ｎｍ                                          ・・・（１）
ここで、Nm：店舗内の現在のマスタ端末数
Ｎｓ：店舗内の現在のスレーブ端末数
式（１）を用いれば、マスタ端末数Nmが多いほどマスタ優先度Mpがマイナスの値になり、スレーブ端末数Nsが多いほどマスタ優先度Mpが大きくなる。両者がバランスしていればゼロに近くなる。従って、同一店舗内がマスタ端末またはスレーブ端末のいずれか一方ばかりになることを防止できる。言い換えれば、同一店舗内のマスタ端末数とスレーブ端末数とのバランスを保つことができる。
【００４１】
（２）演算方法２
第２の演算方法では、ＬＡＮ３０１と外部ネットワーク３００とを結ぶ店舗の通信回線の通信帯域Ｓと、マスタ端末に割り当てられる通信帯域と、スレーブ端末に割り当てられる通信帯域と、に基づいてマスタ優先度Ｍｐを演算する。例えば、任意の店舗２００に設置されたゲーム装置Ｔは、マスタ優先度Ｍｐを下式（２）に基づいて演算することができる。
【００４２】
Mp＝Ｌｍ−Ｌｓ                                          ・・・（２）
ここで、Ｌｍ：ゲーム装置自身がマスタ端末になった場合の店舗の通信帯域の残り
Ｌｓ：ゲーム装置自身がスレーブ端末になった場合の店舗の通信帯域の残り
店舗の通信帯域とは、ＬＡＮ３０１と外部ネットワーク３００とを結ぶ通信回線の通信帯域である。式（２）を用いれば、ゲーム装置がスレーブ端末になる場合に比してマスタ端末になった方が店舗内の通信帯域Ｓにゆとりがある場合、マスタ優先度Ｍｐが大きくなる。その逆の場合、マスタ優先度Ｍｐはマイナスの値になる。従って、店舗２００の通信帯域Ｓを有効に利用することができる。
【００４３】
実際には、店舗内のＬＡＮ３０１と外部ネットワーク３００とを結ぶ通信回線の通信帯域Ｓには、アップ帯域Ｓｕとダウン帯域Ｓｄとがある。アップ帯域Ｓｕとは、外部ネットワーク３００へデータを送信するための送信用通信帯域である。ダウン帯域Ｓｄとは、外部ネットワーク３００からのデータを受信するための受信用通信帯域である。従って、店舗２００の通信帯域の残りＬｍとＬｓは、それぞれアップ帯域Ｓｕの残りとダウン帯域Ｓｄの残りとの和である。すなわち、Ｌｍ及びＬｓについて下式が成り立つ。
【００４４】
Ｌｍ＝Ｌｕｍ＋Ｌｄｍ                                        （２−１）
Ｌｓ＝Ｌｕｓ＋Ｌｄｓ                                （２−２）
ここで、Ｌｕｍ：ゲーム装置自身がマスタ端末になった場合の店舗のアップ帯域Ｓｕの残り
Ｌｄｍ：ゲーム装置自身がマスタ端末になった場合の店舗のダウン帯域Ｓｄの残り
Ｌｕｓ：ゲーム装置自身がスレーブ端末になった場合の店舗のアップ帯域Ｓｕの残り
Ｌｄｓ：ゲーム装置自身がスレーブ端末になった場合の店舗のダウン帯域Ｓｄの残り
なお、アップ帯域Ｓｕの残りＬｕｍ及びダウン帯域Ｓｄの残りＬｄｍの値がマイナスの場合は、帯域オーバーであることを示す。
【００４５】
（３）演算方法３
第３の演算方法として、アップ帯域とダウン帯域とを別々に考えてもよい。例えば、上記の式（２）の変形として、下記式（２−３）を用いてマスタ優先度Ｍｐを求めても良い。
Ｍｐ＝（Ｌｕｍ−Ｌｕｓ）×ｎ＋（Ｌｄｍ−Ｌｄｓ）×ｍ    ・・・（２−３）
ここで、ｎ、ｍ：自然数
すなわち、ゲーム装置がマスタ端末になった場合に店舗２００のアップ帯域Ｓｕ及びダウン帯域Ｓｄの残りＬｕｍ、Ｌｄｍが多ければ、マスタ優先度Ｍｐが大きくなる。逆に、ゲーム装置がスレーブ端末になった場合に店舗２００のアップ帯域及びダウン帯域の残りＬｕｓ、Ｌｄｓが多ければ、マスタ優先度Ｍｐがマイナスの値になる。“ｎ”，“ｍ”は、アップ帯域及びダウン帯域の重み付である。重み付は、店舗の通信帯域のうち、アップ帯域Ｓｕ及びダウン帯域Ｓｄの大きさなどを考慮して設定すると良い。
【００４６】
このようにダウン帯域とアップ帯域とを別々に考える１つの理由は、店舗のアップ帯域Ｓｕ及びダウン帯域Ｓｄは、通常Ｓｕ＜Ｓｄの関係が成立するように設定されているからである。これは、外部ネットワーク３００上で送信されてきたデータを、確実に受信できるようにするためである。別の理由としては、マスタ端末のアップ帯域はダウン帯域よりも大きく、スレーブ端末ではその逆になるのが通常だからである。例えば次のようにそれぞれの通信帯域は設定されている。
【００４７】
マスタ端末のアップ帯域：８０ｋｂｐｓ
マスタ端末のダウン帯域：２０ｋｂｐｓ
スレーブ端末のアップ帯域：２０ｋｂｐｓ
スレーブ端末のダウン帯域：８０ｋｂｐｓ
従って、マスタ端末はスレーブ端末に比して店舗のアップ帯域Ｓｕを消費する。逆に、スレーブ端末はマスタ端末に比してダウン帯域を消費する。上式（２−３）を用いれば、店舗のアップ帯域Ｓｕ及びダウン帯域Ｓｄの違いや、マスタ端末及びスレーブ端末のアップ帯域とダウン帯域との消費量の違いを考慮したマスタ優先度Ｍｐを求めることができる。
【００４８】
（４）演算方法４
第４の演算方法として、店舗の通信帯域の残りが店舗の通信帯域に占める割合に基づいて、マスタ優先度Ｍｐを演算することもできる。例えば、アップ帯域とダウン帯域とを別々に考えると、上記の式（２−３）の変形として下記式（２−４）を用い、マスタ優先度Ｍｐを求めても良い。
【００４９】
Ｍｐ＝（Ｌｕｍ／Ｓｕ−Ｌｕｓ／Ｓｕ）×ｎ
＋（Ｌｄｍ／Ｓｄ−Ｌｄｓ／Ｓｄ）×ｍ                ・・・（２−４）
ここで、ｎ、ｍ：自然数
店舗のアップ帯域Ｓｕやダウン帯域Ｓｄは、店舗により異なるのが通常である。そのため、ＬｕｍやＬｄｍの値が同じでも、実際の店舗の通信帯域の余裕が同じとは限らない。店舗のアップ帯域Ｓｕ及びダウン帯域Ｓｄに対する割合に基づいてマスタ優先度Ｍｐを算出することで、店舗間での通信帯域そのものに差があっても、マスタ優先度Ｍｐを公平に比較することができる。
【００５０】
上式（２−４）を用いると、ゲーム装置がマスタ端末になった方が店舗２００のアップ帯域及びダウン帯域の残り割合Ｌｕｍ／Ｓｕ、Ｌｄｍ／Ｓｄが多ければ、マスタ優先度Ｍｐが大きくなる。逆に、ゲーム装置がスレーブ端末になった方が店舗２００のアップ帯域及びダウン帯域の残り割合Ｌｕｓ／Ｓｕ、Ｌｄｓ／Ｓｄが多ければ、マスタ優先度Ｍｐがマイナスの値になる。“ｎ”，“ｍ”は、アップ帯域及びダウン帯域の重み付である。重み付は、店舗の通信帯域のうち、アップ帯域Ｓｕ及びダウン帯域Ｓｄの大きさなどを考慮して設定すると良い。
【００５１】
（５）演算方法５
第５の演算方法では、店舗状況に加え、プレイヤのマスタ経験値Ｅをマスタ優先度Ｍｐに反映させる。マスタ経験値Ｅは、プレイヤが過去に行ったゲームにおいて、どのくらいマスタ端末でのプレイを経験しているかを示す値である。プレイヤがマスタ端末またはスレーブ端末のどちらかでゲームを行う毎に、マスタ経験値Ｅは更新される。マスタ経験値Ｅの詳細は後述する。そして、ゲームを開始する前に、プレイヤの最新のマスタ経験値に基づいてマスタ優先度Ｍｐを演算する。例えば、マスタ優先度Ｍｐを下式（３）で求めることができる。
【００５２】
Ｍｐ＝（Ｎｓ−Ｎｍ）×ｎ＋Ｅ                                ・・・（３）
ここで、ｎ：Ｅに比して十分大きい正の数
Ｅ：プレイヤのマスタ経験値
上式（３）を用いると、マスタ端末数Ｎｍ及びスレーブ端末数Ｎｓだけではマスタ優先度に差が付かない場合でも、互いのマスタ優先度に差を付けることができる場合がある。また、前述の式（２）や式（２−３）、式（２−４）にマスタ経験値Ｅを組み合わせることにより、通信帯域の余裕に差が付かない場合でも、互いのマスタ優先度に差を付けることができる場合がある。さらに、プレイヤがマスタ端末ばかりを経験したりスレーブ端末ばかりを経験するといった、プレイヤ間に生じうる不公平を防止できるという利点がある。
【００５３】
［マスタ経験値］
上記演算方法５で用いたマスタ経験値Ｅは、プレイヤの個人データの一部であるか、またはプレイヤの個人データの一部から求めることができる値である。
（例１）
Ｅnew＝Ｅold＋Ｘ          ・・・マスタ端末の場合        ・・・（４−１）
Ｅnew＝Ｅold−Ｘ          ・・・スレーブ端末の場合      ・・・（４−２）
ここで、Ｅnew：最新のマスタ経験値
Ｅold：１つ前のマスタ経験値
Ｘ：所定の値
例えばプレイヤがマスタ端末でプレイを行う場合、ゲーム装置はプレイヤのマスタ経験値（ゲーム経験値に相当）に所定の値、例えば“＋１”を加算する。逆に、ゲーム装置自身がスレーブ端末になった場合、マスタ経験値に所定の値、例えば“−１”を加算する。このようにして演算されるマスタ経験値は、プレイヤの経験がマスタ端末に偏るほど大きくなり、逆にスレーブ端末に偏るほどマイナスになる。両者がバランスしていればゼロに近くなる。
【００５４】
（例２）
Ｅnew＝（マスタ回数）／（ゲーム回数）                      ・・・（５）
ゲーム装置Ｔは、ゲーム装置自身を操作するプレイヤがゲームを行った回数であるゲーム回数を、所定のタイミング、例えばゲームの終了時に更新する。また、ゲーム装置Ｔは、ゲーム装置自身がマスタ端末になった場合、プレイヤのマスタ回数をインクリメントする。マスタ回数とは、プレイヤがマスタ端末でゲームを行った回数であり、初期値は“０”である。このようにして算出されるゲーム回数及びマスタ端末の最新の値に基づき、マスタ経験値Ｅnewを演算する。ゲームの体験回数に差があるプレイヤ同士のマスタ経験値を比較する場合であっても、ゲーム回数の差がマスタ優先度Ｍｐに及ぼす影響を緩和することができる。
【００５５】
［禁止フラグ］
ゲーム装置Tが実行する制御プログラムは、マスタ優先度Mpに加え、禁止フラグを用いてマスタ端末を決定することもできる（通信帯域監視手段に相当）。ゲーム装置Ｔは、例えば次のようにマスタ端末を決定する。まずゲーム装置Tは、マスタ端末になった場合に、店舗２００のアップ帯域Ｓｕ、ダウン帯域Ｓｄをオーバーするか否かを判断する。少なくともいずれかがオーバーする場合には、マスタ禁止フラグの値をオンに設定する。同様に、ゲーム装置Ｔは、スレーブ端末になった場合に、店舗２００のアップ帯域Ｓｕまたはダウン帯域Ｓｄのいずれかをオーバーするか否かを判断する。いずれかがオーバーする場合には、スレーブ禁止フラグをオンに設定する。ゲーム装置Ｔは、マスタ優先度Ｍｐに加え、スレーブ禁止フラグ及びマスタ禁止フラグの値を、対戦相手と互いに送受信し合う。
【００５６】
ゲーム装置Ｔは、ゲーム装置自身及び対戦相手のマスタ優先度Ｍｐに代えて、またはマスタ優先度Mpに加え、互いのスレーブ禁止フラグ及びマスタ禁止フラグの値に基づいてマスタ端末を決定する。具体的には、スレーブ禁止フラグまたはマスタ禁止フラグ（以下、まとめて禁止フラグと言うことがある）を、マスタ優先度よりも優先することが好ましい。例えば、対戦相手のスレーブ禁止フラグがオンになっており、ゲーム装置自身のスレーブ禁止フラグがオフであれば、マスタ優先度の比較結果にかかわらず、マスタ端末は対戦相手と決定する。禁止フラグの送受信をマスタ優先度の演算に先立って行えば、対戦するゲーム装置の役割が禁止フラグだけで決まる場合にはマスタ優先度を演算しなくてすむ利点がある。禁止フラグが競合した場合には、１）対戦相手同士を接続しない、２）マスタ優先度に従っていずれかをマスタ端末に決定する、等の処理が考えられる。対戦するゲーム装置の禁止フラグが全てオフであれば、マスタ優先度に基づいて各装置の役割を決めればよい。禁止フラグを参照してマスタ端末を決定することにより、いずれかの店舗の通信帯域がオーバーしてしまう事態を回避しやすくなる。
【００５７】
［ゲーム装置の処理］
次に、ゲーム装置Ｔが行う処理について、より詳細に説明する。説明を容易にするために、店舗２００ａのゲーム装置Ta1と店舗２００ｂのゲーム装置Tb1とが対戦するものとし、禁止フラグは用いないものとする。ゲーム装置Ta1、Tb1が行う処理は同一なので、以下ではゲーム装置Ta1の処理を説明する。なお、店舗内のマスタ端末数Ｎｍ及びスレーブ端末数Ｎｓとマスタ経験値Ｅとに基づいてマスタ優先度を演算する場合を例に取る（上式（３））。マスタ経験値Ｅは、マスタ端末になったか否かに基づいて所定値を加算することにより更新することとする（上式（４−１）、（４−２））。
【００５８】
（１）メインルーチン
図４は、ゲーム装置Ta1のＣＰＵ２０１が行うメインルーチンの流れの一例を示すフローチャートである。ゲーム装置Ta1は、ゲーム装置自身がマスタ端末であればマスタ処理によりゲームを実行し、ゲーム装置自身がスレーブ端末であればスレーブ処理によりゲームを実行する。
【００５９】
ステップＳ１：ＣＰＵ２０１は、カードリーダ・ライタ２１２が読み込んだプレイヤＩＤを取得する。
ステップＳ２：ＣＰＵ２０１は、プレイヤＩＤをセンターサーバ１００に送信し、プレイヤＩＤに応じた個人データをダウンロードする。このとき、プレイヤに対してパスワードの入力を要求し、パスワードによりプレイヤ本人か否かを認証することが好ましい。
【００６０】
ステップＳ３：ＣＰＵ２０１は、後述する対戦相手決定処理を実行し、ネットワーク３００を介して対戦する対戦相手のゲーム装置Tb1のＩＰアドレスを取得する。
ステップＳ４：ＣＰＵ２０１は、ゲーム装置自身Ta1のマスタ優先度Ｍｐａを、現在の店舗２００ａ内のマスタ端末数Ｎｍ及びスレーブ端末数Ｎｓと、プレイヤのマスタ経験値Ｅとに基づいて演算する（演算手段に相当）。マスタ優先度の演算に先立ち、ＣＰＵ２０１は、同一店舗内のゲーム装置Ｔａ2に役割の問い合わせを送信し、応答を所定時間収集する（決定結果送信手段、決定結果受信手段に相当）。この問い合わせに対する応答には、各ゲーム装置がマスタ端末またはスレーブ端末のいずれになっているかを示すデータが含まれる。ＣＰＵ２０１は、収集した応答に基づき、現在のマスタ端末数Ｎｍ及びスレーブ端末数Ｎｓを求める。マスタ経験値Ｅは、個人データに含まれている（第１経験値記憶手段に相当）。
【００６１】
ステップＳ５：ＣＰＵ２０１は、ゲーム装置自身Ta1のマスタ優先度Ｍｐａを、対戦相手Tb1に送信する（送信手段に相当）。また、対戦相手Tb1のマスタ優先度Ｍｐｂを受信する（受信手段に相当）。
ステップＳ６：ＣＰＵ２０１は、後述するマスタ決定処理により、いずれがマスタ端末になり、いずれがスレーブ端末になるかを決定する（決定手段に相当）。
【００６２】
ステップＳ７：ＣＰＵ２０１は、マスタ決定処理の結果に基づき、実行されようとしているゲームでゲーム装置自身がマスタ端末になるか否かを判断する。
ステップＳ８：ＣＰＵ２０１は、実行されようとしているゲームでマスタ端末になる場合にはマスタ処理を行う。この処理では、ＣＰＵ２０１は、マスタ端末としてゲームを実行し、ゲームが終了するとスレーブ端末にゲーム終了通知を送信する。
【００６３】
ステップＳ９：ＣＰＵ２０１は、ゲーム装置自身がマスタ端末ではないと判断すると、後述するスレーブ処理によりゲームを実行する。すなわち、プレイヤの指示入力を示す入力データをマスタ端末に送信し、マスタ端末から受信する出力データに基づいて出力を制御する処理を、ゲーム終了まで行う。
ステップＳ１０：ＣＰＵ２０１は、プレイヤのマスタ経験値を更新する（第１更新手段に相当）。
【００６４】
ステップＳ１１：ＣＰＵ２０１は、ゲーム結果の表示、センターサーバ１００への個人データのアップロードなどを行い、処理を終了する。
このメインルーチンとは独立に、ＣＰＵ２０１は、ゲーム実行中に同一店舗内のゲーム装置Ｔからの役割の問い合わせを受信すると、ゲーム装置自身がマスタ端末なのかスレーブ端末なのかを応答する処理を行う（図示せず）。
【００６５】
なお、マスタ優先度Ｍｐの演算を店舗２００の通信帯域に基づいて行う場合は、ＣＰＵ２０１はマスタ端末及びスレーブ端末それぞれが使用するアップ帯域及びダウン帯域と、店舗２００の通信帯域Ｓｕ、Ｓｄと、をＲＯＭ２０３などに記憶しておく。
（２）対戦相手決定処理
図５は、前記メインルーチンのステップＳ３において実行される対戦相手決定処理の流れの一例を示すフローチャートである。この処理では、ＣＰＵ２０１は、対戦相手のゲーム装置のＩＰアドレスを、センターサーバ１００を介して取得する。
【００６６】
ステップＳ３０１：ＣＰＵ２０１は、自分自身のＩＰアドレスをセンターサーバ１００に送信し、センターサーバ１００のRAM２０２に記憶されている募集リストへのＩＰアドレスの登録を要求する。
ステップＳ３０２〜Ｓ３０３：ＣＰＵ２０１は、他のゲーム装置Ｔから対戦要求を受信したか否かを判断し（Ｓ３０２）、まだであればセンターサーバ１００から募集リストを取得する（Ｓ３０３）。対戦要求を受信していれば、後述するステップＳ３１０に移行する。
【００６７】
ステップＳ３０４〜Ｓ３０５：ＣＰＵ２０１は、募集リストに、自分のアドレス以外のＩＰアドレスが登録されているかどうかを判断し（Ｓ３０４）、“Yes”と判断するといずれかのＩＰアドレスを選択する（Ｓ３０５）。
ステップＳ３０６：ＣＰＵ２０１は、選択したＩＰアドレスに対し、対戦要求コマンドが記述された対戦要求パケットを送信する。
【００６８】
ステップＳ３０７〜Ｓ３０９：ＣＰＵ２０１は、送信した対戦要求パケットに対する返答パケットの受信を待機し（Ｓ３０７）、対戦ＯＫの応答を受信すると（Ｓ３０８）、自分のＩＰアドレスを募集リストから抹消するようセンターサーバ１００に要求する（Ｓ３０９）。対戦が拒否された場合（Ｓ３０８）、再び前記ステップＳ３０２に戻り、前述の処理を繰り返す。
【００６９】
ステップＳ３１０：ＣＰＵ２０１は、ＩＰアドレスを募集リストに登録した後に対戦要求を受信した場合（Ｓ３０２）、対戦ＯＫの返答パケットを要求元に送信し（Ｓ３１０）、自分自身のＩＰアドレスを募集リストから抹消してもらう（Ｓ３０９）。
（３）マスタ決定処理
図６は、前記メインルーチンのステップＳ６でＣＰＵ２０１が実行するマスタ決定処理の流れの一例を示すフローチャートである。この処理では、ＣＰＵ２０１は、ゲーム装置自身及び対戦相手のマスタ優先度Ｍｐａ、Ｍｐｂの比較結果に基づき、いずれがマスタ端末となるかを決定する。
【００７０】
ステップＳ６０１、Ｓ６０２：ＣＰＵ２０１は、ゲーム装置自身のマスタ優先度Ｍｐａと対戦相手のマスタ優先度Ｍｐｂとを比較し（Ｓ６０１）、ゲーム装置自身のマスタ優先度Ｍｐａの方が大きければ（Ｍｐａ＞Ｍｐｂ）マスタ端末はゲーム装置自身Ta1であると判断する（Ｓ６０２）。
ステップＳ６０３、Ｓ６０４：ＣＰＵ２０１は、ゲーム装置自身のマスタ優先度Ｍｐａと対戦相手のマスタ優先度Ｍｐｂとが同じか否かを判断し（Ｓ６０３）、同じであれば（Ｍｐａ＝Ｍｐｂ）両者のＩＰアドレスに基づいてマスタ端末を決定する（Ｓ６０４）。例えば、ＩＰアドレスが大きい方のゲーム装置をマスタ端末と判断する。
【００７１】
ステップＳ６０５：その他の場合、すなわちＭｐａ＜Ｍｐｂであれば、ＣＰＵ２０１はマスタ端末は対戦相手Tb1であると判断する。
（４）マスタ処理
図７は、前記メインルーチンのステップＳ８でＣＰＵ２０１が実行するマスタ処理の流れの一例を示すフローチャートである。この処理では、ＣＰＵ２０１は、マスタ端末としてゲームを実行する。つまりゲーム装置Ta1は、マスタ端末として、対戦相手のスレーブ端末Tb1とゲームを行う。
【００７２】
ステップＳ８０１：ＣＰＵ２０１は、ゲーム装置自身Ｔａにおけるプレイヤの指示入力か、またはスレーブ端末Tb1からの入力データの受信を待機し、いずれかがあるとステップＳ８０２に移行する。
ステップＳ８０２：ＣＰＵ２０１は、入力データに基づいてゲームを進行させる。
ステップＳ８０３：ＣＰＵ２０１は、ゲーム装置自身の描画処理部２０５や音声再生部２０７に出力データを送出し、出力を制御する。
【００７３】
ステップＳ８０４：ＣＰＵ２０１は、対戦相手のスレーブ端末Tb1に対し、ネットワーク３００を介して出力データを送信する。
ステップＳ８０５〜Ｓ８０６：ＣＰＵ２０１は、ゲームが終了するか否かを判断する（Ｓ８０５）。ゲームが終了する場合（Ｓ８０５）、ＣＰＵ２０１は、ゲーム終了通知を全てのスレーブ端末、この場合はゲーム装置Tb1に送信する（Ｓ８０６）。ゲーム終了通知には、スレーブ端末Tb1がゲームの終了処理を行うために必要なデータが含まれている。ゲームが終了しないと判断すると、再びステップＳ８０１に戻り、前述の処理をゲーム終了まで繰り返す。
【００７４】
（５）スレーブ処理
図８は、前記メインルーチンのステップＳ９でＣＰＵ２０１が実行するスレーブ処理の流れの一例を示すフローチャートである。この処理では、ＣＰＵ２０１は、スレーブ端末としてゲームを実行する。つまりゲーム装置Ta1は、スレーブ端末として、対戦相手のマスタ端末Ｔｂとゲームを行う。
【００７５】
ステップＳ９０１〜Ｓ９０２：ＣＰＵ２０１は、プレイヤからの指示入力を待機し（Ｓ９０１）、指示入力がある度に入力データをマスタ端末Tb1に送信する（Ｓ９０２）。
ステップＳ９０３〜Ｓ９０４：ＣＰＵ２０１は、マスタ端末Tb1からの出力データの受信を待機し（Ｓ９０３）、受信した出力データを描画処理部２０５や音声再生部２０７に送出して画面出力や音声出力を制御する（Ｓ９０４）。
【００７６】
ステップＳ９０５：ＣＰＵ２０１は、マスタ端末Tb1からゲーム終了通知を受信したかどうかを判断し、受信した場合はメインルーチンに戻る。
［センターサーバの処理］
図９は、センターサーバ１００が行う処理の流れの一例を示すフローチャートである。センターサーバ１００のＣＰＵ１０１は、個人データをゲーム装置Ｔに送信する処理（Ｓ１１１〜Ｓ１１３）、募集リストへの登録（Ｓ１１４〜Ｓ１１６）、募集リストからの抹消（Ｓ１１７〜Ｓ１１８）を行う。
【００７７】
ステップＳ１１１〜Ｓ１１３：ＣＰＵ１０１は、いずれかのゲーム装置Ｔからの個人データの要求の受信及びパスワードによる個人認証を行うと（Ｓ１１１）、ROM１０３から要求された個人データを読み出し（Ｓ１１２）、要求元に送信する（Ｓ１１３）。個人データは、プレイヤＩＤ及びパスワードと対応付けられてROM１０３に記憶されている。
ステップＳ１１４〜Ｓ１１６：ＣＰＵ１０１は、いずれかのゲーム装置Ｔから募集リストへのＩＰアドレスの登録要求を受信すると（Ｓ１１４）、募集リストへその端末のＩＰアドレスを登録し（Ｓ１１５）、募集リストを要求元に送信する（Ｓ１１６）。
【００７８】
ステップＳ１１７〜Ｓ１１８：ＣＰＵ１０１は、いずれかのゲーム装置Ｔから募集リストからのＩＰアドレスの抹消要求を受信すると（Ｓ１１７）、募集リストから該当ＩＰアドレスを削除する（Ｓ１１８）。募集リストにはまだ対戦相手が未定のゲーム装置のＩＰアドレスだけを掲載しておくために、対戦相手が決まったゲーム装置のＩＰアドレスを募集リストから削除するのである。
【００７９】
ステップＳ１１９：ＣＰＵ１０１は、例えばセンターサーバ１００の電源がオフになるまで、前述の処理を繰り返す。
［第１実施形態例の効果］
店舗内のマスタ端末数やスレーブ端末数に基づく上式（１）や上式（３）に従ってマスタ優先度Ｍｐを演算すれば、店舗内のゲーム装置がマスタ端末またはスレーブ端末のいずれかに偏ることを防止できる。従って、店舗間の公平さを担保することができる。マスタ優先度Ｍｐを店舗の通信帯域に基づく上式（２）に従ってマスタ優先度Ｍｐを演算すれば、店舗のアップ帯域Ｓｕ、ダウン帯域Ｓｄを有効に使用することができる。また、禁止フラグの併用により、店舗の通信帯域がオーバーすることを防止できる。
【００８０】
＜第２実施形態例＞
第２実施形態例に係るゲーム装置は、マスタ優先度に基づいて自分自身の役割を決定した後、店舗の通信帯域をオーバーするか否かをその決定に基づいて判断する。その結果オーバーする場合には、同一店舗内の他のゲーム装置に対し、役割変更依頼を送信する。
図１０は、役割変更依頼の仕組みを示す説明図である。説明を容易にするため、店舗２００ａのゲーム装置Ta1と店舗２００ｂのゲーム装置Tb1とが対戦する場合を考える。図中、同一の破線で囲まれたゲーム装置T同士が対戦している。ゲーム装置Ta1、Tb1のマスタ優先度Mpa、Mpbが例えばMpa＞Mpbの場合、ゲーム装置Ta1がマスタ端末になる。ゲーム装置Ta1がマスタ端末になった場合、店舗２００ａの通信帯域がオーバーすると仮定する。この場合、ゲーム装置Ta1は、同一店舗内のゲーム装置であって他店舗のゲーム装置と対戦中のゲーム装置Ta2に対し、変更依頼メッセージ（図中MSGと表記）を送信する。ゲーム装置Ta1は、ゲーム装置Ta2に対して変更依頼メッセージ(MSG1)を送信すると、自分自身はマスタ端末として対戦相手Tb1とゲームを開始する。
【００８１】
一方、変更依頼メッセージMSG1を受信したゲーム装置Ta2は、他店舗２００ｃ内の対戦相手Tc1にこれを転送する（MSG2）。ゲーム装置Tc1が役割変更できる場合、ＯＫメッセージがゲーム装置Ta2に送信される。役割変更できない場合、ゲーム装置Tc1はゲーム装置Ta1と同様の処理を行う。つまり、同一店舗２００ｃ内のゲーム装置Tc2に対し、変更依頼メッセージ(MSG3)を送信する。これを受信したゲーム装置Tc2は、他店舗２００ｄの対戦相手Td1にこれを転送する（MSG4）。
【００８２】
以上の処理を、ＯＫメッセージを返すゲーム装置が現れるまで行う。ただし、変更依頼メッセージの転送が無限に続くことを避けるために、転送に上限を設けておくことが好ましい。例えば、変更メッセージの中に変更依頼メッセージの送信回数Nsと送信回数の上限Nmaxを含めておく。ゲーム装置Tは、変更依頼メッセージを転送する毎に送信回数Nsをインクリメントし、Ns＝Nmaxとなった変更依頼メッセージを受信した場合にはそれ以上の転送を停止するとよい。
【００８３】
図１１は、前記図１０に示す役割変更依頼の詳細な流れを示す説明図である。
ゲーム装置Ta1は、マスタ優先度に基づいて役割を決定した後、店舗の通信帯域がオーバーしているか否かを判断する（第２通信帯域監視手段に相当）。オーバーしていなければそのまま決定した役割に基づいて対戦相手とゲームを開始する。オーバーしていれば、同一店舗２００ａ内の任意のゲーム装置Ta2に対し、変更依頼メッセージMSG1を送信し（変更依頼送信手段に相当）（＃１）、その後対戦相手とゲームを開始する。
【００８４】
このメッセージMSG1では、送信回数Ns＝１、送信回数の上限Nmaxは所定値、例えば“４”である。メッセージMSG1の送信先は、好ましくは店舗の通信帯域のうちアップ帯域Ｓｕ、ダウン帯域Ｓｄのいずれがオーバーしたかにより変えると好ましい。例えば、アップ帯域Ｓｕがオーバーした場合は、同一店舗内のマスタ端末に変更依頼メッセージを送信するとよい。逆に、ダウン帯域Ｓｄがオーバーした場合は、同一店舗内のスレーブ端末に変更依頼メッセージを送信すると良い。各ゲーム装置Taがどちらの役割を担っているかは、同一店舗内のゲーム装置に送信した役割の問い合わせ（前記ステップＳ４）に対する応答と応答元とを対応付けて記憶することにより、把握することができる。
【００８５】
一方、ゲーム装置Ta2は、同一店舗内のゲーム装置Ta1から変更依頼メッセージMSG１を受信すると、他店舗２００ｃ内の対戦相手Tc1にそのメッセージを転送する（変更依頼メッセージMSG2）（＃２）。このメッセージMSG2では、送信回数Ns=2、送信回数の上限Nmax＝４である。ゲーム装置Ta2がマスタ端末であれば、任意の対戦相手に転送してよい。逆にゲーム装置Ta2がスレーブ端末であれば、対戦相手の中のマスタ端末にメッセージMSG2を送信する。ゲーム装置Ta2は、このメッセージMSG２に対する応答を待機し、応答に応じて役割を変更するかどうかを決定する。
【００８６】
まず、メッセージMSG2を受信したゲーム装置Tc1は、役割を変更した場合の店舗２００ｃの帯域負荷を演算し（＃３）、役割変更可能か否かを判断する。役割を変更しても店舗２００ｃのアップ帯域Ｓｕ・ダウン帯域Ｓｄが共にオーバーしないのであれば、役割変更可能を示すＯＫメッセージを店舗２００ａの対戦相手Ta2に送信する（＃４）。
逆に、ゲーム装置Tc1は、店舗の帯域オーバーのため役割を変更できないと判断すると、変更依頼メッセージを転送可能か否かを判断する。転送不可能であれば、ゲーム装置Tc1はRejectメッセージをゲーム装置Ta2に送信する（＃５）。
【００８７】
逆にゲーム装置Tc1は、役割を変更できないが、変更メッセージをさらに転送可能と判断すると、同一店舗２００ｃ内のゲーム装置Tc2に変更依頼メッセージMSG3を送信する（＃６）。このメッセージMSG3では、送信回数Ns=3、送信回数の上限Nmax＝４である。
ゲーム装置Tc2は、同一店舗２００ｃ内のゲーム装置Tc1から変更メッセージMSG3を受信すると、これを他店舗２００ｄ内の対戦相手Td1に転送する（MSG4）（＃７）。このメッセージMSG4では、送信回数Ns=4、送信回数の上限Nmax＝４である。店舗２００ｄのゲーム装置Td1は、前記ゲーム装置Tc1と同様の処理を行う（＃８〜＃１０）。その結果、役割変更がＯＫであれば、ＯＫメッセージがゲーム装置Ta2に転送される（＃９，＃１１，＃１３）。逆に役割変更が不可でかつ変更依頼メッセージの転送が不可であれば、Rejectメッセージがゲーム装置Ta2に転送される（＃１０，＃１２，＃１４）。この例では、Ns＝Nmaxとなっているので、転送不可と判断される。
【００８８】
ゲーム装置Ta2は、返ってきた応答に応じた処理を行う。すなわち、ＯＫメッセージが返ってくれば、対戦相手との間で役割を変更し、ゲームを続行する。逆にRejectメッセージが返ってくれば、役割を変更せずそのままの役割でゲームを続行する。
なお、同一店舗内の非対戦相手のゲーム装置から変更依頼メッセージを受信したときは、店舗の通信帯域の負荷を演算する必要はない。例えば、ゲーム装置Ta1からゲーム装置Ta2へ変更依頼メッセージMSG1が送信されたとき、ゲーム装置Ta2は店舗の帯域負荷を演算しなくて良い。ゲーム装置Ta1,Ta2のどちらがマスタ端末でどちらがスレーブ端末であっても、店舗内のマスタ端末数Nm及びスレーブ端末数Ｎｓは同じだからである。つまり、ゲーム装置Ta1,Ta2のどちらがマスタ端末でどちらがスレーブ端末であっても、店舗の通信帯域の余裕あるいはオーバー分は変わらないからである。
【００８９】
［ゲームデータの送信］
図１２は、マスタ端末が切り替わるときに次のマスタ端末に送信されるゲームデータの一例である。この例は、サッカーゲームのゲームデータを示す。ゲームデータは、ゲームの履歴を含み、ゲームの続行に必要なデータである。変更依頼メッセージに応じ、マスタ端末からスレーブ端末へ役割を変更するゲーム装置Tは、ゲームデータを新たにマスタ端末となる対戦相手に送信する。その逆に、スレーブ端末からマスタ端末に役割を変更するゲーム装置Tは、マスタ端末であった対戦相手からゲームデータを受信する。
【００９０】
例えばサッカーゲームのゲームデータであれば、選手の残り体力、各選手のイエローカード及びレッドカードの枚数、今までのシュート本数、今までのファウル本数、得点、チーム名、選手データなどが挙げられる。ゲームデータは、通信の確実性が担保される通信プロトコル、ＴＣＰ／ＩＰなどを用いて送信される。
［ゲーム装置が行う処理］
ゲーム装置Ｔは、前記メインルーチン、対戦相手決定処理、マスタ決定処理、マスタ処理、スレーブ処理を行う点で、前記第１実施形態と同様である。ただし、前述の処理に加え、変更依頼転送処理を行う。以下に変更依頼転送処理について説明する。前記と同様、各ゲーム装置が行う処理は同様であるので、以下では図１０におけるゲーム装置Ta1の処理について説明する。
【００９１】
図１３は、ＣＰＵ２０１が行う変更依頼転送処理の流れを示すフローチャートである。この処理は、前記メインルーチンと共に開始され、前記メインルーチンとは独立に実行される。以下では、前記図１０及び図１１を参照しながら具体的に説明する。
ステップＳ２１：ＣＰＵ２０１は、変更依頼メッセージの受信を待機し、受信すると下記ステップＳ２２〜Ｓ３２の処理を行う。
【００９２】
ステップＳ２２：ＣＰＵ２０１は、変更依頼メッセージが他店舗内の対戦相手からか、それとも同一店舗内の非対戦相手からかを判断する。
ステップＳ２３：変更依頼メッセージが同一店舗内の非対戦相手からであれば、ＣＰＵ２０１は店舗外の対戦相手に対し、変更依頼メッセージを送信する。このとき、ＣＰＵ２０１は、変更依頼メッセージ中の送信回数Ｎｓをインクリメントする。
【００９３】
ステップＳ２４、Ｓ２５：ＣＰＵ２０１は、店舗外の対戦相手からの応答を待機し（Ｓ２４）、応答が返ってくると、前記ステップＳ２１で受信した変更依頼メッセージの送信元に転送する（Ｓ２５）。
ステップＳ２６、Ｓ２７：ＣＰＵ２０１は、応答がＯＫメッセージであれば（Ｓ２６）、対戦相手と役割を変更し、対戦相手と間でゲームデータの送受信を行う（Ｓ２７）。応答がRejectメッセージであれば（Ｓ２６）、役割を変更することなく、次の変更依頼メッセージの受信を待機する。
【００９４】
ステップＳ２８：変更依頼メッセージが店舗外の対戦相手からであれば、ＣＰＵ２０１は自分自身の役割を変更した場合の店舗内の状況に基づいて店舗の通信帯域の負荷を演算する。店舗内の他のゲーム装置に対し、演算前に各自の役割を問い合わせることが好ましい。
ステップＳ２９：ＣＰＵ２０１は、自分自身の役割変更により、店舗の通信帯域がオーバーするか否かを判断する。
【００９５】
ステップＳ３０、Ｓ３１：店舗の通信帯域がオーバーしなければ、ＣＰＵ２０１は、受信した変更依頼メッセージの送信元に対し、ＯＫメッセージを送信する（Ｓ３０）。その後、対戦相手との間で役割を変更し、ゲームデータの送受信を行う（Ｓ３１）。
ステップＳ３２、Ｓ３３：ＣＰＵ２０１は、店舗の通信帯域がオーバーする場合（Ｓ３２）、受信した変更依頼メッセージの送信元に対し、Rejectメッセージを送信する（Ｓ３３）。転送可であれば、ＣＰＵ２０１は、同一店舗内の非対戦相手に変更依頼メッセージを転送する（Ｓ３４）。店舗のアップ帯域Ｓｕがオーバーする場合には、マスタ端末になっているゲーム装置をメッセージの転送先とするのが好ましい。逆に、ダウン帯域Ｓｄがオーバーする場合には、スレーブ端末になっているゲーム装置をメッセージの転送先とするのが好ましい。その後、前記ステップＳ２４〜Ｓ２７の処理を行う。
【００９６】
［第２実施形態の効果］
変更依頼によりゲーム装置の役割を柔軟に変更するので、店舗の通信帯域がオーバーする事態を防ぎやすくなる。複数の店舗が外部ネットワークで接続されたゲームシステム全体として、通信帯域の有効利用を促進すると期待できる。
＜第３実施形態例＞
前記第１及び第２実施形態では、１対１のネットワーク対戦の場合を例に取り説明した。しかし、３つ以上のゲーム装置Ｔが対戦する場合も本発明に含まれる。また、対戦相手が同一店舗内にいる場合も本発明に含まれる。互いに異なる店舗にある３つ以上のゲーム装置Tがネットワーク対戦を行う場合は、３つ以上のマスタ優先度を比較することを除き、前記第１及び第２実施形態と同様に処理を行えばよい。従って、以下では同一店舗内に少なくとも１つの対戦相手が存在する場合について説明する。説明を容易にするために、図１４に示すように、店舗２００ａ内のゲーム装置Ta1,Ta2と、店舗２００ｂ内のゲーム装置Tb1とが対戦する場合を考える。図中、破線で囲まれたゲーム装置同士が対戦する。
【００９７】
本実施形態のゲーム装置Ｔは、対戦相手が同一店舗内に存在する場合、ゲーム装置自身及び対戦相手のうちマスタ端末となる可能性のあるマスタ候補を決定する。同一店舗内では、どちらがマスタ端末になっても店舗としては変わりはないからである。マスタ候補は、例えば、IPアドレスなどの通信アドレス（マスタ候補決定データに相当）の大小に基づいて決定することができる。対戦相手の通信アドレスは、前記対戦相手決定処理（図５）で取得しているので、それを用いることができる。ゲーム装置自身がマスタ候補の場合は他店舗の対戦相手との間でマスタ優先度を交換し、マスタ端末を決定する。その後、ゲーム装置自身がマスタ端末か否かに応じて、マスタ処理またはスレーブ処理を行う。ゲーム装置自身がマスタ候補ではない場合、マスタ候補からマスタ端末の通知を待ってスレーブ処理を行う。
【００９８】
なお、同一店舗内に対戦相手が存在する場合、マスタ候補のゲーム装置はマスタ優先度Mpの演算においては、同一店舗内の対戦相手をスレーブ端末数に算入する。例えば、図１４においてゲーム装置Ta1がマスタ候補の場合、ゲーム装置Ta1は、マスタ端末数Ｎｍ＝１、スレーブ端末数Ｎｓ＝２としてマスタ優先度Ｍｐａを演算する。
マスタ候補の決定は、通信アドレスに代え、他のデータ（マスタ候補決定データに相当）に基づいて行うこともできる。例えば前記マスタ経験値Ｅが最も低いプレイヤが操作しているゲーム端末を、マスタ候補に決定しても良い。そのときは、同一店舗内で対戦するゲーム装置同士がマスタ経験値Ｅを送受信し合うことが必要である。マスタ経験値Ｅの交換は、対戦相手決定処理の後かつマスタ優先度の演算の前に行う。
【００９９】
［メインルーチン］
図１５は、ゲーム装置ＴのＣＰＵ２０１が行うメインルーチンの流れの一例を示すフローチャートである。説明を容易にするために、この例ではＩＰアドレスの大小に基づいてマスタ候補を決定することとする。
ステップＳ４１：ＣＰＵ２０１は、カードリーダ・ライタ２１２が読み込んだプレイヤＩＤを取得する。
【０１００】
ステップＳ４２：ＣＰＵ２０１は、プレイヤＩＤをセンターサーバ１００に送信し、プレイヤＩＤに応じた個人データをダウンロードする。このとき、プレイヤに対してパスワードの入力を要求し、パスワードによりプレイヤ本人か否かを認証することが好ましい。
ステップＳ４３：ＣＰＵ２０１は、前述の対戦相手決定処理を実行し、ネットワーク３００を介して対戦する対戦相手のゲーム装置Ta2、Tb1のＩＰアドレスを取得する。
【０１０１】
ステップＳ４４：ＣＰＵ２０１は、対戦相手のIPアドレスに基づいて、同一店舗２００ａ内に対戦相手がいるか否かを判断する（店舗内対戦相手判断手段に相当）。
ステップＳ４５：ＣＰＵ２０１は、同一店舗内に対戦相手がいる場合、いずれかをマスタ候補に決定する（候補決定手段に相当）。例えば、ＩＰアドレスが大きい方をマスタ候補とすることができる。
【０１０２】
ステップＳ４６：ＣＰＵ２０１は、ゲーム装置自身Ta1がマスタ候補か否かを判断し、マスタ候補であれば（IPアドレス大）ステップＳ４７に移行する。マスタ候補でなければ（IPアドレス小）、後述するステップＳ５４に移行する。
ステップＳ４７：ＣＰＵ２０１は、ゲーム装置自身Ta1のマスタ優先度Ｍｐａを演算する。演算方法は、前記第１実施形態で例示した演算方法を用いることができる。マスタ優先度Mpaの演算に先立ち、ＣＰＵ２０１は同一店舗内のゲーム装置に役割の問い合わせを送信する。ＣＰＵ２０１は、応答に基づき、現在のマスタ端末数Ｎｍ及びスレーブ端末数Ｎｓを求める。このとき同一店舗内の対戦相手Ta2は、スレーブ端末数Ｎｓに算入する。
【０１０３】
ステップＳ４８：ＣＰＵ２０１は、ゲーム装置自身Ta1のマスタ優先度Ｍｐａを、他店舗２００ｂの対戦相手Tb1に送信する。また、対戦相手Tb1のマスタ優先度Ｍｐｂを受信する。
ステップＳ４９：ＣＰＵ２０１は、前述のマスタ決定処理（図６）により、いずれがマスタ端末になり、いずれがスレーブ端末になるかを決定する。
【０１０４】
ステップＳ５０、Ｓ５１：ＣＰＵ２０１は、同一店舗内に対戦相手が存在していれば（Ｓ５０）、その対戦相手にマスタ端末のＩＰアドレスを通知する（Ｓ５１）。マスタ端末の通知は、前記マスタ処理（図７）で行ってもよい。
ステップＳ５２：ＣＰＵ２０１は、実行されようとしているゲームでゲーム装置自身がマスタ端末になるか否かを、マスタ決定処理の結果に基づき判断する。ゲーム装置自身がマスタ端末ではない場合、後述するステップＳ５５に移行し、スレーブ端末としてゲームを開始する。
【０１０５】
ステップＳ５３：ＣＰＵ２０１は、ゲーム装置自身がマスタ端末になる場合、前記マスタ処理を行うことによりマスタ端末としてゲームを実行し、ゲームが終了するとスレーブ端末にゲーム終了通知を送信する。
ステップＳ５４：ＣＰＵ２０１は、ゲーム装置自身がマスタ候補ではないと判断するとIPアドレス小）、同一店舗内の対戦相手からマスタ端末のＩＰアドレスの通知を待機し、通知されたＩＰアドレスをマスタ端末と認識してスレーブ処理を行う。
【０１０６】
ステップＳ５５：ＣＰＵ２０１は、前記スレーブ処理によりゲームを実行する。すなわち、プレイヤの指示入力を示す入力データをマスタ端末に送信し、マスタ端末から受信する出力データに基づいて出力を制御する処理を、ゲーム終了まで行う。
ステップＳ５６：ＣＰＵ２０１は、プレイヤのマスタ経験値Ｅを更新する。
ステップＳ５７：ＣＰＵ２０１は、ゲーム結果の表示、センターサーバ１００への個人データのアップロードなどを行い、処理を終了する。
【０１０７】
このメインルーチンとは独立に、第１実施形態と同様に、ＣＰＵ２０１は、ゲーム実行中に同一店舗内のゲーム装置Ｔからの役割の問い合わせに対し、ゲーム装置自身の役割を応答する処理を行う（図示せず）。
また、マスタ優先度Ｍｐの演算を店舗２００の通信帯域に基づいて行う場合は、ＣＰＵ２０１はマスタ端末及びスレーブ端末がそれぞれが使用するアップ帯域及びダウン帯域と、店舗２００の通信帯域Ｓｕ、Ｓｄと、をＲＯＭ２０３などに記憶しておくのも同様である。
【０１０８】
［図１５に示す処理の流れの具体例］
店舗２００ａ内のゲーム装置Ta1,Ta2と店舗２００ｂ内のゲーム装置Tb1とが対戦する場合に、各ゲーム装置が行う処理の流れを具体的に説明する。
（１）ゲーム装置Ta1
ゲーム装置Ta1は、対戦相手決定後（Ｓ４３)、ゲーム装置Ta1,Ta2のＩＰアドレスを比較する。ゲーム装置Ta1のＩＰアドレスの方が大きければ、自分自身がマスタ候補であると判断する（Ｓ４５）。ゲーム装置Ta1自身がマスタ装置であれば（Ｓ４６）、第１店舗のマスタ優先度Mpaを演算し、ゲーム装置Tb1に送信する（Ｓ４７，Ｓ４８）。また、ゲーム装置Tb1から第２店舗のマスタ優先度Mpbを受信する（Ｓ４８）。ゲーム装置Ta1は、マスタ優先度Mpa,Mpbを比較し、ゲーム装置Ta1自身またはゲーム装置Tb1のいずれがマスタ端末となるかを決定する（Ｓ４９）。説明を容易にする為に、Mpa＞Mpbであり、ゲーム装置Ta1自身がマスタ端末となると決定したと仮定する。
【０１０９】
ゲーム装置Ta1は、同一店舗内の対戦相手であるゲーム装置Ta2に、マスタ端末となるゲーム装置のＩＰアドレスを通知する（Ｓ５１）。この場合、ゲーム装置Ta1自身のＩＰアドレスを、マスタ端末として通知する。さらにゲーム装置Ta1は、自分自身がマスタ端末になる場合、マスタ処理を行う（Ｓ５２，Ｓ５３）。
（２）ゲーム装置Ta2
ゲーム装置Ta2は、対戦相手決定後（Ｓ４３)、ゲーム装置Ta1,Ta2のＩＰアドレスを比較する。ゲーム装置Ta2のＩＰアドレスの方が小さいので、ゲーム装置Ta1がマスタ候補であると判断し、自分自身（ゲーム装置Ta2）はスレーブ端末になると判断する（Ｓ４５）。ゲーム装置Ta2は、同一店舗内の対戦相手であるゲーム装置Ta1からのマスタ端末の通知を待機し、マスタ端末となるゲーム装置Ta1のＩＰアドレスの通知を受信する（Ｓ５４）。その後、ゲーム装置Ta2はスレーブ処理を行う（Ｓ５５）。
【０１１０】
（３）ゲーム装置Tb1
ゲーム装置Tb1は、対戦相手決定後（Ｓ４３)、第２店舗のマスタ優先度Mpbを演算し、ゲーム装置Ta1に送信する（Ｓ４７，Ｓ４８）。また、ゲーム装置Ta1から第１店舗のマスタ優先度Mpaを受信する（Ｓ４８）。ゲーム装置Tb1は、マスタ優先度Mpa,Mpbを比較し、ゲーム装置Ta1自身またはゲーム装置Tb1のいずれがマスタ端末となるかを決定する（Ｓ４９）。前述したように、Mpa＞Mpbであり、ゲーム装置Ta1がマスタ端末となると決定したと仮定する。ゲーム装置Tb1は、自分自身がマスタ端末かどうかを判断し、スレーブ端末なのでスレーブ処理を行う（Ｓ５２，Ｓ５５）。
【０１１１】
［第３実施形態の効果］
以上のようにして、対戦するゲーム装置が同一店舗に存在していても、マスタ優先度を用いてマスタ端末を決定することができる。
＜その他の実施形態例＞
（Ａ）前述の実施形態は、適宜組み合わせて実施することができる。また、マスタ優先度Ｍｐの演算方法は、前述の例に限定されない。
【０１１２】
（Ｂ）前述のマスタ決定処理（図６）において、対戦者同士のマスタ優先度が同じ場合にIPアドレスの大小でマスタ端末を決定している。しかし、マスタ優先度が同じ場合だけでなく、その差が所定値以下の場合もマスタ優先度が競合していると見なしてもよい。さらに、マスタ優先度が競合している場合には、IPアドレスに代えて、各ゲーム装置を特定する別の識別子に基づいてマスタ端末を決定しても良い。例えば各ゲーム装置に固有の装置番号を識別子として挙げることができる。
【０１１３】
なお、ゲーム装置ではなく店舗を特定する識別子であっても、次のようにしてマスタ端末を決めることができる。識別子の大小やアルファベット順等に基づいてマスタ端末を割り当てるいずれかの店舗を決め、その店舗に存在するゲーム装置をマスタ端末とすればよい。
（Ｃ）前述の方法をコンピュータ上で実行するためのプログラム及びそのプログラムを記録したコンピュータ読み取り可能な記録媒体は、本発明に含まれる。ここで記録媒体としては、コンピュータが読み書き可能なフレキシブルディスク、ハードディスク、半導体メモリ、ＣＤ−ＲＯＭ、ＤＶＤ、光磁気ディスク（ＭＯ）、その他のものが挙げられる。
【産業上の利用可能性】
【０１１４】
本発明は、ネットワーク対戦型ゲームに適用可能である。
【図面の簡単な説明】
【０１１５】
【図１】第１実施形態例に係るゲームシステムの概略構成を示す説明図
【図２】ゲーム装置Ｔの構成を示す説明図。
【図３】（Ａ）スレーブ端末からマスタ端末に送信される入力データの一例。  （Ｂ）マスタ端末からスレーブ端末に送信される出力データの一例。
【図４】ゲーム装置が行うメインルーチンの流れの一例を示すフローチャート。
【図５】対戦相手決定処理の流れの一例を示すフローチャート。
【図６】マスタ決定処理の流れの一例を示すフローチャート。
【図７】マスタ処理の流れの一例を示すフローチャート。
【図８】スレーブ処理の流れの一例を示すフローチャート。
【図９】センターサーバが行う処理の流れの一例を示すフローチャート。
【図１０】第２実施形態における変更依頼メッセージの概念説明図。
【図１１】ゲーム装置間での変更依頼メッセージの転送処理の流れを示す説明図。
【図１２】マスタ端末が切り替わるときに次のマスタ端末に送信されるゲームデータの一例。
【図１３】第２実施形態における変更依頼転送処理の流れの一例を示すフローチャート。
【図１４】第３実施形態における対戦状態の説明図。
【図１５】第３実施形態のゲーム装置が行うメインルーチンの流れの一例を示すフローチャート。
【符号の説明】
【０１１６】
１００：センターサーバ
２００：店舗
Ｔ：ゲーム装置
Ｍ：マスタ端末であるゲーム装置
Ｓ：スレーブ端末であるゲーム装置
【図１】
0003686415.tif 000002
【図２】
0003686415.tif 000003
【図３】
0003686415.tif 000004
【図４】
0003686415.tif 000005
【図５】
0003686415.tif 000006
【図６】
0003686415.tif 000007
【図７】
0003686415.tif 000008
【図８】
0003686415.tif 000009
【図９】
0003686415.tif 000010
【図１０】
0003686415.tif 000011
【図１１】
0003686415.tif 000012
【図１２】
0003686415.tif 000013
【図１３】
0003686415.tif 000014
【図１４】
0003686415.tif 000015
【図１５】
0003686415.tif 000016