JP2011097993A - ゲームシステムおよびゲームプログラム - Google Patents

Abstract

【構成】 ゲームシステム１００は、サーバ１０２を含み、サーバ１０２は、ネットワーク１０４を介して複数のゲーム装置１０と通信可能に接続される。サーバ１０２は、通信ゲーム中に、ゲーム装置１０からの接続中メッセージを受信しない場合には、当該ゲーム装置１０が通信ゲームを途中終了したと判断し、通信ゲームに参加中のプレイヤの悪評スコアを加算する。また、通信ゲームを終了し、次回の通信ゲームへの参加を拒否するゲーム装置１０が存在する場合には、当該次回の通信ゲームへの参加を許可するゲーム装置１０の悪評スコアを加算する。たとえば、悪評スコアの高いプレイヤは、次回の通信ゲームへの参加を拒否される。
【効果】 通信ゲームの継続を拒否されるようなプレイヤによる、不正行為や不快な行為を抑制したり防止したりすることができる。
【選択図】 図４

Description

この発明はゲームシステムおよびゲームプログラムに関し、特にたとえば、インターネットのようなネットワークを介して通信ゲームをプレイする、ゲームシステムおよびゲームプログラムに関する。

従来、ネットワークを介して接続された複数のゲーム装置間で実行される通信対戦ゲームにおいて、自己に不利な状況に陥った場合に、ゲーム装置間の通信を強制的に切断することで対戦を無効にするような不正行為が跋扈している。

このような不正行為を防止する方法の一例が特許文献１に開示されている。特許文献１に開示される不正行為防止方法では、店舗内のＬＡＮとゲーム装置との接続をプレイヤが切断した場合、異常処理を実行することにより、以降の不正行為への抑止力とする。たとえば、ゲーム装置は、ネットワーク対戦ゲームの実行中に、ルータを介して他のゲーム装置との間でパケットを送受信する。所定時間経過してもパケットを受信しない場合には、ルータに応答要求を送信し、ルータから返答がなければプレイヤが故意に内部ネットワークを切断したとみなし、ゲームを強制終了させたり、切断時の成績を記録したりするなどの異常処理を行う。これにより、ゲーム展開が不利になった場合に、ＬＡＮケーブルを引き抜く行為など、プレイヤが故意に通信障害を引き起こそうとする不正行為への意欲を喪失させる。
特開２００６−２１２２８８号公報

上述の特許文献１に開示された不正行為防止方法は、ＬＡＮケーブルを抜くなどの通信を強制的に切断するような不正行為に対して異常処理を実行することにより、そのような不正行為への意欲を喪失させるものである。しかし、この特許文献１の不正行為防止方法は、不利な状況下におかれた際に、途中でゲームや通信を強制終了させるような不正行為を防止する場合に有用であるが、ゲームソフト（ゲームプログラム）の改造（改変）などのゲームプログラムの想定外の使用方法によってゲームを有利に進めるような不正行為や対戦相手に対する過剰な嫌がらせを行うなどの不快な行為を防止することは困難である。特に、そのような不正行為や不快な行為は近年増加しており、有効な対策が求められている。

それゆえに、この発明の主たる目的は、新規な、ゲームシステムおよびゲームプログラムを提供することである。

また、この発明の他の目的は、ゲームプログラムの想定外使用による不正行為を防止できる、ゲームシステムおよびゲームプログラムを提供することである。

さらに、この発明のその他の目的は、対戦ゲームの相手を不快にさせるような行為を防止できる、ゲームシステムおよびゲームプログラムを提供することである。

第１の発明は、通信ゲームを行うゲームシステムであって、拒否判断手段および制限情報更新手段を備える。拒否判断手段は、１のゲーム装置が他のゲーム装置によって通信ゲームの継続を拒否されたか否かを判断する。制限情報更新手段は、拒否判断手段の判断結果に応じて、１のゲーム装置の通信ゲームについての制限情報を更新させる。

第１の発明によれば、通信ゲームの継続を拒否されたゲーム装置の制限情報を更新するので、ゲームプログラムを想定外使用するような不正行為や過剰な嫌がらせを行うなどの不快な行為を行う者を間接的に検出することができる。したがって、そのような不正行為や不快な行為を抑制したり防止したりすることができる。

第２の発明は、第１の発明に従属し、ゲームシステムは、通信対象選択手段をさらに備える。通信対象選択手段は、各ゲーム装置の制限情報に基づいて通信ゲームの対象となるゲーム装置を選択する。

第２の発明によれば、制限情報に基づいて通信ゲームの対象となるゲーム装置を選択するので、その選択を簡単に行うことができる。

第３の発明は、第２の発明に従属し、通信対象選択手段は、制限情報が少なくとも近似する複数のゲーム装置を通信ゲームの対象として選択する。たとえば、制限情報が同じまたは近似するゲーム装置同士が通信ゲームの対象として選択される。

第３の発明によれば、制限情報が少なくとも近似するゲーム装置同士を通信ゲームの対象として選択するので、同じまたは類似する評価を他のプレイヤから受けていると考えられるプレイヤ同士を通信ゲームの対象として選択することができる。

第４の発明は、第１ないし第３の発明のいずれかに従属し、ゲームシステムは、通信ゲームを実行する通信ゲーム処理手段をさらに備える。この通信ゲーム処理手段は、少なくとも通信ゲームに参加中の各ゲーム装置の制限情報を、当該通信ゲームの処理に反映させる。たとえば、制限情報に基づいて、通信ゲームの継続を拒否される頻度が高いプレイヤは、不正行為や不快な行為を行う者であると判断して、そのようなプレイヤのプレイヤキャラクタの属性（攻撃力、生命力、性能など）を他のプレイヤのプレイヤキャラクタの属性よりも劣るように調整する。

第４の発明によれば、制限情報を通信ゲームの処理に反映させるので、ゲームプログラムを想定外使用する不正行為や過剰な嫌がらせを行うなどの不快な行為を抑制したり防止したりすることができる。

第５の発明は、第４の発明に従属し、ゲームシステムは、通信ゲームに参加する各ゲーム装置の制限情報を比較する比較手段をさらに備える。通信ゲーム処理手段は、さらに、比較手段の比較結果を、通信ゲームの処理に反映させる。たとえば、格闘ゲームをプレイする場合に、ゲーム装置（プレイヤ）同士の制限情報を比較し、その比較結果に応じて、攻撃する側の攻撃力を変化させたり、防御する側の体力値の減少量を変化させたりする。つまり、ゲームプログラムを想定外使用する不正行為や過剰な嫌がらせを行うプレイヤが操作するプレイヤキャラクタの攻撃力を低下させたり、体力値の減少量を増加させたりする。

第５の発明においも、第４の発明と同様に、ゲームプログラムを想定外使用する不正行為や過剰な嫌がらせを行うなどの不快な行為を抑制したり防止したりすることができる。

第６の発明は、第４の発明に従属し、通信ゲーム処理手段は、制限情報が所定の条件を満たすとき、通信ゲームに影響を及ぼす。たとえば、制限情報が不正行為や不快な行為に関する指標であると仮定すると、そのような指標に基づいてプレイヤが不正行為や不快な行為を（頻繁）に行っていると判断される場合には、当該プレイヤについては、通信ゲームについて不利な扱いをする。逆に、プレイヤが不正行為や不快な行為を行っていないと判断される場合には、通信ゲームについて有利な扱いをする。これらはいずれか一方が実施されてもよい。

第６の発明によれば、制限情報に基づいて通信ゲームに影響を及ぼすので、ゲームプログラムを想定外使用する不正行為や過剰な嫌がらせを行うなどの不快な行為を抑制することができる。

第７の発明は、第６の発明に従属し、通信ゲーム処理手段は、制限情報に基づく値が所定以上であるとき、通信ゲームへの参加自体を拒否する。たとえば、プレイヤが不正行為や不快な行為を頻繁に行うと判断される場合には、当該プレイヤを通信ゲームに参加させないようにするのである。

第７の発明によれば、不正行為や不快な行為を頻繁に行うプレイヤを通信ゲームに参加させないようにするので、そのような行為を未然に防止することができる。

第８の発明は、第１ないし第７の発明のいずれかに従属し、通信ゲームの継続を拒否されたことは当該通信ゲーム中に切断されたことを含む。たとえば、通信ゲーム中に、通信中の他のゲーム装置が、電源をオフしたり、通信を強制的に切断したりして、通信ゲームや通信を途中で終了すると、通信ゲームの継続を拒否されたと判断する。

第８の発明によれば、ゲームを途中で終了される場合に、ゲームプログラムを想定外使用する不正行為や過剰な嫌がらせを行うなどの不快な行為が行われたと判断して、制限情報を更新することができる。

第９の発明は、第８の発明に従属し、拒否判断手段は、他のゲーム装置からの通信データを１のゲーム装置で一定時間受信しなかったとき、当該１のゲーム装置が当該他のゲーム装置によって通信ゲームの継続を拒否されたことを判断する。

第９の発明によれば、他のゲーム装置からの通信データを一定時間受信しなかった場合に、通信ゲームの継続を拒否されたことを判断するので、ゲーム装置の電源がオフされたり、通信を強制的に切断されたりしたことを、間接的に検出することができる。

第１０の発明は、第１ないし第９の発明のいずれかに従属し、通信ゲームの継続を拒否されたことは次回の通信ゲームへの参加を拒否されたことを含む。

第１０の発明によれば、次回の通信ゲームへの参加を拒否された場合にも、直前の通信ゲームにおいて、ゲームプログラムを想定外使用する不正行為や過剰な嫌がらせを行うなどの不快な行為が行われたと判断して、制限情報を更新することができる。

第１１の発明は、第１ないし第１０の発明のいずれかに従属し、ゲームシステムは拒否情報更新手段を備える。拒否情報更新手段は、他のゲーム装置が通信ゲームの継続を拒否した回数を示す拒否情報を更新する。制限情報更新手段は、さらに、拒否情報更新手段によって更新された拒否情報に基づいて、１のゲーム装置の通信ゲームについての制限情報を更新させる。

第１１の発明によれば、他のゲーム装置が拒否した回数を１のゲーム装置の制限情報を更新する際に加味するので、他のゲーム装置の制限情報を故意に更新させようとするような行為を防止することができる。

第１２の発明は、第１１の発明に従属し、制限情報更新手段は、拒否情報更新手段によって更新された拒否情報が示す回数が大きい程、制限情報を変更する度合いを小さくする。

第１２の発明によれば、たとえば頻繁に通信ゲームの継続を拒否するような他のゲーム装置については、１のゲーム装置の制限情報の更新に与える影響を少なくすることができる。

第１３の発明は、第１ないし第１２の発明のいずれかに従属し、ゲームシステムは、通信ゲームの継続を拒否した他のゲーム装置の数を検出する拒否数検出手段をさらに備える。制限情報更新手段は、さらに、拒否数検出手段の検出結果に基づいて、１のゲーム装置の通信ゲームについての制限情報を更新させる。

第１３の発明によれば、ゲームの継続を拒否した他のゲーム装置の数に応じて制限情報を更新するので、たとえば一度に多数の他のゲーム装置によって通信ゲームを拒否された１のゲーム装置の制限情報を大幅に変更することができる。

第１４の発明は、第１の発明に従属し、ゲームシステムは、参加者登録手段および再度参加受付手段をさらに備える。参加者登録手段は、通信ゲームの開始時に当該通信ゲームに参加するゲーム装置を参加者として登録する。再度参加者受付手段は、通信ゲームの終了時に参加者から再度通信ゲームへ参加するか否かの指示を受け付ける。拒否判断手段は、再度参加受付手段によって受け付けられた指示に基づいて、通信ゲームの継続が拒否されたゲーム装置が存在するか否かを判断する。

第１４の発明によれば、通信ゲームへの参加者を登録しておき、通信ゲームの終了時に再度通信ゲームに参加するか否かの指示を受け付けるので、通信ゲームの継続を拒否したかどうかを簡単に知ることができる。

第１５の発明は、第１４の発明に従属し、ゲームシステムは、差分取得手段および差分判断手段をさらに備える。差分取得手段は、前回の通信ゲームの参加者数と次回の通信ゲームの参加者数との差分を取得する。差分判断手段は、差分取得手段によって取得された差分が所定の条件を満たしているか否かを判断する。拒否判断手段は、差分判断手段によって差分が所定の条件を満たしていないことが判断されたとき、通信ゲームの継続が拒否されたゲーム装置を判断する。

第１５の発明によれば、前回の通信ゲームの参加者数と次回の通信ゲームの参加者数との差分が所定の条件を満たす場合にのみ、通信ゲームの継続が拒否されたゲーム装置を判断するので、そのような場合にのみ制限情報を更新することができる。

第１６の発明は、通信ゲームを行うゲームシステムのゲームプログラムであって、コンピュータを、１のゲーム装置が他のゲーム装置によって通信ゲームの継続を拒否されたか否かを判断する拒否判断手段、および拒否判断手段の判断結果に応じて、１のゲーム装置の通信ゲームについての制限情報を更新させる制限情報更新手段として機能させる。

第１６の発明においても、第１の発明と同様に、ゲームプログラムを想定外使用するような不正行為や過剰な嫌がらせを行うなどの不快な行為を抑制したり防止したりすることができる。

この発明によれば、通信ゲームの相手から通信ゲームの継続を拒否されたことに応じて通信ゲームの制限情報を更新するので、この制限情報に基づいて不正行為を行うプレイヤの通信ゲームへの参加およびプレイを制限することができる。つまり、ゲームプログラムの想定外使用による不正行為を抑制したり防止したりすることができる。また、対戦ゲームの相手を不快にさせるような行為を抑制したり防止したりすることができる。

この発明の上述の目的，その他の目的，特徴および利点は、図面を参照して行う以下の第１実施例の詳細な説明から一層明らかとなろう。

図１はこの発明のゲーム装置の外観構成の一実施例を示す図解図である。 図２は図１に示すゲーム装置を折り畳んだ状態の上面図および左側面図を示す図解図である。 図３は図１および図２に示すゲーム装置の電気的な構成を示すブロック図である。 図４は図１−図３に示すゲーム装置を用いたゲームシステムの例を示す図解図である。 図５は図４に示すサーバのＲＡＭのメモリマップの例を示す図解図である。 図６は現在参加プレイヤリストの具体例を示す図解図である。 図７は図１−図４に示すゲーム装置のメインメモリのメモリマップの例を示す図解図である。 図８は図３に示すゲーム装置のＣＰＵの全体処理の一部を示すフロー図である。 図９は図３に示すゲーム装置のＣＰＵの全体処理の第２の一部であって、図８に後続するフロー図である。 図１０は図３に示すゲーム装置のＣＰＵの全体処理の第３の一部であって、図９に後続するフロー図である。 図１１は図３に示すゲーム装置のＣＰＵの全体処理の第４の一部であって、図９に後続するフロー図である。 図１２は図４に示すサーバのＣＰＵの全体処理の一部を示すフロー図である。 図１３は図４に示すサーバのＣＰＵの全体処理の第２の一部であって、図１２に後続するフロー図である。 図１４は図４に示すサーバのＣＰＵの全体処理の第３の一部であって、図１３に後続するフロー図である。 図１５は図４に示すサーバのＣＰＵの全体処理の第４の一部であって、図１４に後続するフロー図である。 図１６は図４に示すサーバのＣＰＵの全体処理の第５の一部であって、図１５に後続するフロー図である。 図１７は図４に示すサーバのＣＰＵの悪評スコアの更新処理を示すフロー図である。 図１８は第２実施例のゲーム装置のＣＰＵの全体処理の一部を示すフロー図である。 図１９は第２実施例のサーバのＣＰＵの全体処理の一部を示すフロー図である。 図２０は第２実施例のサーバのＣＰＵの全体処理の第２の一部であって、図１９に後続するフロー図である。 図２１は第２実施例のサーバのＣＰＵの全体処理の第３の一部であって、図２０に後続するフロー図である。 図２２は第２実施例のサーバのＣＰＵの全体処理の第４の一部であって、図２１に後続するフロー図である。 図２３は第３実施例のゲーム装置のメインメモリのメモリマップの例を示す図解図である。 図２４は図２３に示すデータ記憶領域の具体例を示す図解図である。 図２５は第３実施例のゲーム装置のＣＰＵの全体処理の一部を示すフロー図である。 図２６は第３実施例のゲーム装置のＣＰＵの全体処理の第２の一部であって、図２５に後続するフロー図である。 図２７は第３実施例のゲーム装置のＣＰＵの全体処理の第３の一部であって、図２６に後続するフロー図である。 図２８は第３実施例のゲーム装置のＣＰＵの全体処理の第４の一部であって、図２７に後続するフロー図である。 図２９は第３実施例のゲーム装置のＣＰＵの全体処理の第５の一部であって、図２８に後続するフロー図である。

＜第１実施例＞
図１を参照して、この発明の第１実施例のゲーム装置１０は、上側ハウジング１２および下側ハウジング１４を含み、上側ハウジング１２と下側ハウジング１４とは、開閉可能（折り畳み可能）に連結されている。図１の例では、上側ハウジング１２および下側ハウジング１４は、それぞれ横長の長方形の板状に形成され、互いの長辺部分で回動可能に連結されている。つまり、この第１実施例のゲーム装置１０は、折り畳み型の携帯ゲーム装置であり、図１には、当該ゲーム装置１０を開いた状態（開状態）で示してある。ゲーム装置１０は、開いた状態においてもユーザが両手または片手で把持することができるようなサイズで構成される。

通常、ユーザは、開状態でゲーム装置１０を使用する。また、ユーザは、ゲーム装置１０を使用しない場合には閉状態で保管する。ただし、ゲーム装置１０は、上記閉状態および開状態のみでなく、上側ハウジング１２と下側ハウジング１４とのなす角度が閉状態と開状態との間の任意の角度において、連結部分に発生する摩擦力などによってその開閉角度を維持することができる。つまり、上側ハウジング１２を下側ハウジング１４に対して任意の角度で静止させることができる。

なお、ゲーム装置１０は、後述するカメラ（３２，３４）を搭載しており、当該カメラ（３２，３４）によって画像を撮像し、撮像した画像を画面に表示したり、撮像した画像のデータを保存したりする撮像装置としても機能する。

図１に示すように、上側ハウジング１２には第１ＬＣＤ１６が設けられ、下側ハウジング１４には第２ＬＣＤ１８が設けられる。第１ＬＣＤ１６および第２ＬＣＤ１８は、横長形状であり、それぞれの長辺方向が上側ハウジング１２および下側ハウジング１４の長辺方向と一致するように配置される。たとえば、第１ＬＣＤ１６および第２ＬＣＤ１８の解像度は、２５６(横)×１９２(縦）画素（ドット）に設定される。

なお、この第１実施例では、表示器としてＬＣＤを用いるようにしてあるが、ＬＣＤに代えて、ＥＬ(Electronic Luminescence)ディスプレイやプラズマディスプレイを用いるようにしてもよい。また、ゲーム装置１０は、任意の解像度の表示装置を利用することができる。

図１および図２に示すように、下側ハウジング１４には、入力装置として、各操作ボタン２０ａ−２０ｋが設けられる。この各操作ボタン２０ａ−２０ｋのうち、方向入力ボタン２０ａ、操作ボタン２０ｂ、操作ボタン２０ｃ、操作ボタン２０ｄ、操作ボタン２０ｅ、電源ボタン２０ｆ、スタートボタン２０ｇ、およびセレクトボタン２０ｈは、下側ハウジング１４の第２ＬＣＤ１８が設けられる側の面（内側の面）に配置される。具体的には、方向入力ボタン２０ａおよび電源ボタン２０ｆは、第２ＬＣＤ１８の左側に配置され、操作ボタン２０ｂ−２０ｅ，２０ｇおよび２０ｈは、第２ＬＣＤ１８の右側に配置される。また、上側ハウジング１２と下側ハウジング１４とを折り畳んだときには、操作ボタン２０ａ−２０ｈはゲーム装置１０の内部に収められる。

方向入力ボタン（十字キー）２０ａは、ディジタルジョイスティックとして機能し、プレイヤオブジェクトの移動方向を指示したり、カーソルを移動させたりするなどに用いられる。各操作ボタン２０ｂ−２０ｅは、プッシュボタンであり、たとえば、プレイヤオブジェクトに任意の動作をさせたり、決定やキャンセルを実行したりする等に用いられる。電源ボタン２０ｆは、プッシュボタンであり、ゲーム装置１０の主電源をオン／オフするために用いられる。スタートボタン２０ｇは、プッシュボタンであり、ゲームを中断（ポーズ）したり、開始（再開）したりするために用いられる。セレクトボタン２０ｈは、プッシュボタンであり、ゲームモードやメニューの選択等に用いられる。

図１においては、操作ボタン２０ｉ−２０ｋを省略したが、図２（Ａ）に示すように、操作ボタン（Ｌボタン）２０ｉは、下側ハウジング１４の上側面の左端部に設けられ、操作ボタン（Ｒボタン）２０ｊは、下側ハウジング１４の上側面の右端部に設けられる。また、図２（Ｂ）に示すように、音量ボタン２０ｋは、下側ハウジング１４の左側面に設けられる。

なお、図２（Ａ）は、ゲーム装置１０を折り畳んだ状態で、上面（上ハウジング１２）側から見た図であり、図２（Ｂ）は、同じくゲーム装置１０を折り畳んだ状態で、左側面から見た図である。

Ｌボタン２０ｉおよびＲボタン２０ｊは、プッシュボタンであり、操作ボタン２０ｂ−２０ｅと同様の操作に用いたり、それらの操作ボタン２０ｂ−２０ｅの補助的な操作に用いたりすることができる。また、この第１実施例では、Ｌボタン２０ｉおよびＲボタン２０ｊは、撮影指示の操作（シャッター操作）を行うために用いることもできる。音量ボタン２０ｋは、２つのプッシュボタンを用いて構成され、図示しない２つのスピーカ（右スピーカおよび左スピーカ）から出力される音の大きさを調整するために用いられる。この第１実施例では、音量ボタン２０ｋには、２つの押圧部を含む操作部が設けられ、各押圧部に対応して上記のプッシュボタンが設けられる。したがって、一方の押圧部を押すと音量が大きくされ、他方の押圧部を押すと音量が小さくされる。たとえば、押圧部を押し続けると、音量が次第に大きくされたり、次第に小さくされたりする。

図１に戻って、ゲーム装置１０は、操作ボタン２０ａ−２０ｋとは別の入力装置として、さらにタッチパネル２２を備えている。タッチパネル２２は、第２ＬＣＤ１８の画面上を覆うように装着されている。この第１実施例では、タッチパネル２２は、たとえば抵抗膜方式のタッチパネルが用いられる。ただし、タッチパネル２２は、抵抗膜方式に限らず、任意の押圧式のタッチパネルを用いることができる。また、この第１実施例では、タッチパネル２２として、たとえば第２ＬＣＤ１８の解像度と同解像度（検出精度）のものを利用する。ただし、必ずしもタッチパネル２２の解像度と第２ＬＣＤ１８の解像度とが一致している必要はない。

また、下側ハウジング１４の右側面には、挿入口（図１に示す破線）が設けられている。挿入口は、タッチパネル２２に対する操作を行うために用いられるタッチペン２４を収納することができる。通常、タッチパネル２２に対する入力は、タッチペン２４を用いて行われるが、タッチペン２４に限らずユーザの指でタッチパネル２２を操作することも可能である。したがって、たとえば、タッチペン２４を用いない場合には、タッチペン２４の挿入口および収納部を設ける必要はない。

また、下側ハウジング１４の右側面には、メモリカード２６を収納するための挿入口（図１では、二点鎖線で示している）が設けられている。この挿入口の内側には、ゲーム装置１０とメモリカード２６とを電気的に接続するためのコネクタ（図示せず）が設けられる。メモリカード２６は、たとえばＳＤカードであり、コネクタに着脱自在に装着される。このメモリカード２６は、たとえば、ゲーム装置１０によって撮像された画像を記憶（保存）したり、他の装置で生成（撮像）ないし記憶された画像をゲーム装置１０に読み込んだりするために用いられる。

さらに、下側ハウジング１４の上側面には、メモリカード２８を収納するための挿入口（図１では、一点鎖線で示している）が設けられている。この挿入口の内側にも、ゲーム装置１０とメモリカード２８とを電気的に接続するためのコネクタ（図示せず）が設けられる。メモリカード２８は、情報処理プログラムおよび必要なデータなどを記録した記録媒体であり、下側ハウジング１４に設けられた挿入口に着脱自在に装着される。

また、上側ハウジング１２と下側ハウジング１４との連結部（ヒンジ）の左端部分には、インジケータ３０が設けられる。このインジケータ３０は、３つのＬＥＤ３０ａ，３０ｂ，３０ｃによって構成される。ここで、ゲーム装置１０は、他の機器との間で無線通信を行うことが可能であり、第１ＬＥＤ３０ａは、無線通信が確立している場合に点灯する。第２ＬＥＤ３０ｂは、ゲーム装置１０の充電中に点灯する。第３ＬＥＤ３０ｃは、ゲーム装置１０の主電源がオンである場合に点灯する。したがって、インジケータ３０（ＬＥＤ３０ａ−３０ｃ）によって、ゲーム装置１０の通信確立状況、充電状況、および主電源のオン／オフ状況をユーザに通知することができる。

上述したように、上側ハウジング１２には、第１ＬＣＤ１６が設けられる。この第１実施例では、第２ＬＣＤ１８を覆うように、タッチパネル２２を設けているが、第１ＬＣＤ１６を覆うように、タッチパネル２２を設けてもよい。または、第１ＬＣＤ１６および第２ＬＣＤ１８のそれぞれを覆うように、２つのタッチパネル２２を設けるようにしてもよい。たとえば、第２ＬＣＤ１８には、各操作ボタン２０ａ−２０ｋやタッチパネル２２の役割ないし操作方法をユーザに教えるための操作説明画面やゲーム画面が表示される。

また、上側ハウジング１２には、２つのカメラ（内側カメラ３２および外側カメラ３４）が設けられる。図１に示すように、内側カメラ３２は、上側ハウジング１２と下側ハウジング１４との連結部付近であり、第１ＬＣＤ１６が設けられる側の面に、この第１ＬＣＤ１６の表示面とその撮影面とが平行または面一になるように取り付けられる。一方、外側カメラ３４は、図２（Ａ）に示すように、内側カメラ３２が取り付けられる面とは反対側の面、すなわち、上側ハウジング１２の外側の面（ゲーム装置１０が閉状態となった場合に外側となる面であり、図１に示す上側ハウジング１２の背面）に取り付けられる。ただし、図１においては、外側カメラ３４を破線で示してある。

したがって、内側カメラ３２は、上側ハウジング１２の内側の面が向く方向を撮像することが可能であり、外側カメラ３４は、内側カメラ３２の撮像方向の逆方向、すなわち、上側ハウジング１２の外側の面が向く方向を撮像することが可能である。このように、この第１実施例では、内側カメラ３２および外側カメラ３４の撮像方向が互いに逆方向となるように、それら２つのカメラ３２，３４が設けられる。たとえば、ゲーム装置１０を把持したユーザは、このゲーム装置１０側からユーザの方を見た景色（たとえば、当該ユーザを含む）を内側カメラ３２で撮像することができるとともに、ゲーム装置１０側からユーザとは反対側の方向を見た景色を外側カメラ３４で撮像することができる。

なお、上記連結部付近の内側の面には、音声入力装置としてマイク８４（図３参照）が収納されている。そして、上記連結部付近の内側の面には、マイク８４がゲーム装置１０外部の音を検知できるように、そのマイク８４用の孔３６が形成される。マイク８４を収納する位置およびマイク８４用の孔３６の位置は必ずしも上記連結部である必要はなく、たとえば下側ハウジング１４にマイク８４を収納し、マイク８４の収納位置に対応させて下側ハウジング１４にマイク８４用の孔３６を設けるようにしてもよい。

また、上側ハウジング１２の外側の面には、外側カメラ３４の近傍に第４ＬＥＤ３８（図１では、破線で示す）が取り付けられる。第４ＬＥＤ３８は、内側カメラ３２または外側カメラ３４によって撮影が行われた（シャッターボタンが押下された）時点で点灯する。また、内側カメラ３２または外側カメラ３４によって動画が撮影される場合には、第４ＬＥＤ３８は、撮影の間点灯し続ける。つまり、第４ＬＥＤ３８を点灯することによって、ゲーム装置１０による撮影が行われた（行われている）ことを撮影対象者や周囲に通知することができる。

また、上側ハウジング１２には、第１ＬＣＤ１６の両側に、音抜き孔４０が形成される。この音抜き孔４０に対応する位置であり、上側ハウジング１２の内部には、上述したスピーカが収納されている。音抜き孔４０は、スピーカからの音をゲーム装置１０の外部に放出するための孔である。

以上に説明したように、上側ハウジング１２には、画像を撮像するための構成である内側カメラ３２および外側カメラ３４と、主として、撮影された画像（撮影画像）およびゲーム画面を表示するための表示手段である第１ＬＣＤ１６とが設けられる。一方、下側ハウジング１４には、ゲーム装置１０に対する操作入力を行うための入力装置（操作ボタン２０（２０ａ−２０ｋ）およびタッチパネル２２）と、主として、操作画面およびゲーム画面を表示するための表示手段である第２ＬＣＤ１８とが設けられる。したがって、ゲーム装置１０は、２つの画面（１６，１８）および２系統の操作部（２０，２２）を備えている。

図３は、この第１実施例のゲーム装置１０の電気的な構成を示すブロック図である。図３に示すように、ゲーム装置１０は、ＣＰＵ５０、メインメモリ５２、メモリ制御回路５４、保存用データメモリ５６、プリセットデータ用メモリ５８、メモリカードインターフェース（メモリカードＩ／Ｆ）６０、メモリカードＩ／Ｆ６２、無線通信モジュール６４、ローカル通信モジュール６６、リアルタイムクロック（ＲＴＣ）６８、電源回路７０、およびインターフェース回路（Ｉ／Ｆ回路）７２、第１ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）７４、第２ＧＰＵ７６、第１ＶＲＡＭ（Ｖｉｄｅｏ ＲＡＭ）７８、第２ＶＲＡＭ８０、およびＬＣＤコントローラ８２等の電子部品を備えている。これらの電子部品（回路コンポーネント）は、電子回路基板上に実装されて、下側ハウジング１４（または上側ハウジング１２でもよい）内に収納される。

ＣＰＵ５０は、所定のプログラムを実行するための情報処理手段である。この第１実施例では、所定のプログラムは、ゲーム装置１０内のメモリ（たとえば保存用データメモリ５６）やメモリカード２６および／または２８に記憶されており、ＣＰＵ５０は、当該所定のプログラムを実行することによって、後述する情報処理を実行する。

なお、ＣＰＵ５０によって実行されるプログラムは、ゲーム装置１０内のメモリに予め記憶していてもよいし、メモリカード２６および／または２８から取得してもよいし、他の機器と通信することによって当該他の機器から取得してもよい。

ＣＰＵ５０には、メインメモリ５２、メモリ制御回路５４、およびプリセットデータ用メモリ５８が接続される。また、メモリ制御回路５４には、保存用データメモリ５６が接続される。メインメモリ５２は、ＣＰＵ５０のワーク領域やバッファ領域として用いられる記憶手段である。すなわち、メインメモリ５２は、上記情報処理に用いられる各種データを記憶（一時記憶）したり、外部（メモリカード２６および２８や他の機器等）から取得されるプログラムを記憶したりする。この第１実施例では、メインメモリ５２として、たとえばＰＳＲＡＭ（Ｐｓｅｕｄｏ−ＳＲＡＭ）を用いる。保存用データメモリ５６は、ＣＰＵ５０によって実行されるプログラムや内側カメラ３２および外側カメラ３４によって撮像された画像のデータ等を記憶（保存）するための記憶手段である。この保存用データメモリ５６は、不揮発性の記憶媒体によって構成されており、たとえば、ＮＡＮＤ型フラッシュメモリを用いることができる。メモリ制御回路５４は、ＣＰＵ５０の指示に従って、保存用データメモリ５６に対するデータの読み出しおよび書き込みを制御する。プリセットデータ用メモリ５８は、ゲーム装置１０において予め設定される各種パラメータ等のデータ（プリセットデータ）を記憶するための記憶手段である。プリセットデータ用メモリ５８としては、ＳＰＩ（Ｓｅｒｉａｌ Ｐｅｒｉｐｈｅｒａｌ Ｉｎｔｅｒｆａｃｅ）バスによってＣＰＵ５０と接続されるフラッシュメモリを用いることができる。

メモリカードＩ／Ｆ６０および６２は、それぞれＣＰＵ５０に接続される。メモリカードＩ／Ｆ６０は、コネクタに装着されたメモリカード２６に対するデータの読み出しおよび書き込みを、ＣＰＵ５０の指示に応じて行う。また、メモリカードＩ／Ｆ６２は、コネクタに装着されたメモリカード２８に対するデータの読み出しおよび書き込みを、ＣＰＵ５０の指示に応じて行う。この第１実施例では、内側カメラ３２および外側カメラ３４によって撮像された画像に対応する画像データや他の装置から受信された画像データがメモリカード２６に書き込まれたり、メモリカード２６に記憶された画像データがメモリカード２６から読み出されて保存用データメモリ５６に記憶されたり、他の装置へ送信されたりする。また、メモリカード２８に記憶された各種プログラムが、ＣＰＵ５０によって読み出されて実行されたりする。

なお、ゲームプログラムなどの情報処理プログラムは、メモリカード２８等の外部記憶媒体を通じてゲーム装置１０に供給されるだけでなく、有線または無線の通信回線を通じてゲーム装置１０に供給されてもよい。また、情報処理プログラムは、ゲーム装置１０内部の不揮発性記憶装置に予め記録されていてもよい。さらに、情報処理プログラムを記憶する情報記憶媒体としては、上記不揮発性記憶装置に限らず、ＣＤ−ＲＯＭ、ＤＶＤ、あるいはそれらに類する光学式ディスク状記憶媒体でもよい。

無線通信モジュール６４は、たとえばＩＥＥＥ８０２．１１．ｂ／ｇの規格に準拠した方式により、無線ＬＡＮに接続する機能を有する。また、ローカル通信モジュール６６は、所定の通信方式により同種のゲーム装置との間で無線通信を行う機能を有する。無線通信モジュール６４およびローカル通信モジュール６６は、ＣＰＵ５０に接続される。ＣＰＵ５０は、無線通信モジュール６４を用いてインターネットを介して他の機器との間でデータを送受信したり、ローカル通信モジュール６６を用いて同種の他のゲーム装置との間でデータを送受信したりすることができる。

また、ＣＰＵ５０には、ＲＴＣ６８および電源回路７０が接続される。ＲＴＣ６８は、時間をカウントしてＣＰＵ５０に出力する。たとえば、ＣＰＵ５０は、ＲＴＣ６８によって計時された時間に基づいて、日付および現在時刻等を計算することもできる。電源回路７０は、ゲーム装置１０が有する電源（典型的には電池であり、下側ハウジング１４に収納される）から供給される電力を制御し、ゲーム装置１０の各回路コンポーネントに電力を供給する。

また、ゲーム装置１０は、マイク８４およびアンプ８６を備えている。マイク８４およびアンプ８６は、それぞれＩ／Ｆ回路７２に接続される。マイク８４は、ゲーム装置１０に向かって発声ないし発生されたユーザの音声ないし音（拍手や手拍子など）を検知して、当該音声ないし音を示す音声信号をＩ／Ｆ回路７２に出力する。アンプ８６は、Ｉ／Ｆ回路７２から与えられる音声信号を増幅してスピーカ（図示せず）に与える。Ｉ／Ｆ回路７２は、ＣＰＵ５０に接続される。

また、タッチパネル２２は、Ｉ／Ｆ回路７２に接続される。Ｉ／Ｆ回路７２は、マイク８４およびアンプ８６（スピーカ）の制御を行う音声制御回路と、タッチパネル２２の制御を行うタッチパネル制御回路とを含む。音声制御回路は、音声信号に対するＡ／Ｄ変換およびＤ／Ａ変換を行ったり、音声信号を所定の形式の音声データに変換したりする。タッチパネル制御回路は、タッチパネル２２からの信号に基づいて所定の形式のタッチ位置データを生成してＣＰＵ５０に出力する。たとえば、タッチ位置データは、タッチパネル２２の入力面に対して入力が行われた位置の座標を示すデータである。

なお、タッチパネル制御回路は、タッチパネル２２からの信号の読み込み、および、タッチ位置データの生成を所定時間に１回の割合で行う。ＣＰＵ５０は、Ｉ／Ｆ回路７２を介して、タッチ位置データを取得することにより、タッチパネル２２に対して入力が行われた位置を知ることができる。

操作ボタン２０は、上記の各操作ボタン２０ａ−２０ｋによって構成され、ＣＰＵ５０に接続される。操作ボタン２０からＣＰＵ５０へは、各操作ボタン２０ａ−２０ｋに対する入力状況（押下されたか否か）を示す操作データが出力される。ＣＰＵ５０は、操作ボタン２０からの操作データを取得し、取得した操作データに応じた処理を実行する。

内側カメラ３２および外側カメラ３４は、それぞれＣＰＵ５０に接続される。内側カメラ３２および外側カメラ３４は、ＣＰＵ５０の指示に応じて画像を撮像し、撮像した画像に対応する画像データをＣＰＵ５０に出力する。この第１実施例では、ＣＰＵ５０は、内側カメラ３２および外側カメラ３４のいずれか一方に対して撮像指示を行い、撮像指示を受けたカメラ（３２，３４）が画像を撮像して画像データをＣＰＵ５０に送る。

第１ＧＰＵ７４には、第１ＶＲＡＭ７８が接続され、第２ＧＰＵ７６には、第２ＶＲＡＭ８０が接続される。第１ＧＰＵ７４は、ＣＰＵ５０からの指示に応じて、メインメモリ５２に記憶されている表示画像を生成するためのデータに基づいて第１の表示画像を生成し、第１ＶＲＡＭ７８に描画する。第２ＧＰＵ７６は、同様にＣＰＵ５０からの指示に応じて第２の表示画像を生成し、第２ＶＲＡＭ８０に描画する。第１ＶＲＡＭ７８および第２ＶＲＡＭ８０は、ＬＣＤコントローラ８２に接続されている。

ＬＣＤコントローラ８２は、レジスタ８２ａを含む。レジスタ８２ａは、ＣＰＵ５０からの指示に応じて、「０」または「１」の値を記憶する。ＬＣＤコントローラ８２は、レジスタ８２ａの値が「０」である場合には、第１ＶＲＡＭ７８に描画された第１の表示画像を第２ＬＣＤ１８に出力し、第２ＶＲＡＭ８０に描画された第２の表示画像を第１ＬＣＤ１６に出力する。また、レジスタ８２ａの値が「１」である場合には、第１ＶＲＡＭ７８に描画された第１の表示画像を第１ＬＣＤ１６に出力し、第２ＶＲＡＭ８０に描画された第２の表示画像を第２ＬＣＤ１８に出力する。

図４は図１ないし図３に示したゲーム装置１０を用いたゲームシステム１００の例を示す図解図である。図４に示すように、ゲームシステム１００は、サーバ１０２を含み、サーバ１０２はインターネットまたはＬＡＮのようなネットワーク１０４を介して複数のゲーム装置１０と通信可能に接続される。また、サーバ１０２には、データベース１０６が直接接続される。ただし、データベース１０６は、ネットワーク１０４を介してサーバ１０２に接続されてもよい。このサーバ１０２は、汎用のサーバであり、ＣＰＵ１０２ａおよびＲＡＭ１０２ｂなどのコンポーネントを含む。

たとえば、図４に示すようなゲームシステム１００では、サーバ１０２は、ゲーム装置１０からの通信ゲームへの参加の申し込みを受け付ける。たとえば、通信ゲームは、複数のゲーム装置１０（プレイヤ）が対戦ないし競争（以下、単に「対戦」という）するような仮想ゲームである。あるいは、通信ゲームは、複数のゲーム装置１０（プレイヤ）が協力して戦闘や冒険を行う仮想ゲームであってもよい。サーバ１０２は、ゲーム装置１０からの通信ゲームへの参加の申し込みを受け付けると、通信ゲームの対戦相手となるプレイヤ、すなわち通信ゲームへの参加予定者を決定（マッチング）する。このとき、複数のグループが形成される場合があるが、この第１実施例では、簡単のため、１つのグループが形成されることにする。参加予定者のグループが決定されると、サーバ１０２は、参加予定者の各ゲーム装置１０に対して他の参加予定者のゲーム装置１０についての接続情報（たとえば、ＩＰアドレス）を送信する。

各ゲーム装置１０は、サーバ１０２から送信されたＩＰアドレスを受信すると、受信したＩＰアドレスに基づいて、他の参加予定者のゲーム装置１０との間で接続状態を確立（通信を開始）し、通信ゲームを開始する。このとき、接続状態が確立したゲーム装置１０が通信ゲームへの参加者すなわち対戦相手として確定される。ただし、接続できなかったゲーム装置１０は、今回の通信ゲームに参加しなかったと判断される。

通信ゲームの実行中では、各ゲーム装置１０は、自己のプレイヤによって入力される操作データ（自己の操作データ）および対戦相手（他の参加者）のゲーム装置１０から送信される操作データ（他の操作データ）に基づいてゲーム処理を実行する。たとえば、各プレイヤキャラクタの位置や動作が制御され、ゲーム画面が更新されたり、ゲームに必要な音（音楽）が出力されたりする。また、通信ゲームが進行され、それに応じて得点処理（減点されることもある）が実行される。各ゲーム装置１０は、通信ゲームを終了すると、通信ゲームを終了したことの通知（終了通知）をサーバ１０２に送信する。

なお、この第１実施例では、各ゲーム装置１０の間で操作データを送受信するようにしてあるが、操作による結果のデータ（結果データ）を送受信するようにしてもよい。たとえば、操作データまたは結果データのいずれを送受信するかは、通信ゲームの種類や設計によって選択的に決定される。

また、詳細な説明は省略するが、通信ゲームを終了すると、各ゲーム装置１０では、同一の対戦相手と通信ゲームを再度（続けて）行うか否かがプレイヤに問い合わされ、プレイヤによって再度通信ゲームを実行することが選択されたゲーム装置１０間で、再度通信ゲームが実行される。つまり、継続して通信ゲームが行われる。

たとえば、このような通信ゲームでは、或るゲーム装置１０のプレイヤが、不利な状況に陥った際に、通信ゲームを強制的に終了したり、通信自体を強制的に切断したりして、通信ゲーム（対戦）を無効にしようとすることがある。このような場合には、通信ゲームや通信自体を強制的に切断したプレイヤに対して何らかのペナルティを課すようにすれば、そのような行為を抑制することができると考えられる。

しかし、通信ゲームや通信自体を強制的に切断したプレイヤに対してペナルティを課すようにする場合には、ゲームソフト（ゲームプログラム）を改造（改変）したり、ゲームプログラムを想定外の方法で使用したりして通信ゲームを有利に進めるような不正行為や対戦相手に対する過剰な嫌がらせを行うなどの不快な行為を防止することは困難である。特に、そのような不正行為や不快な行為は近年増加しており、有効な対策が求められている。

そこで、この第１実施例では、通信ゲームを途中で終了（途中終了）されたり、次回の通信ゲームへの参加を拒否されたりしたプレイヤ、すなわち通信ゲームを継続することを拒否されたプレイヤを、上記のような不正行為や不快な行為を行った者として間接的に検出し、そのようなプレイヤに対して、次回以降の通信ゲームに参加できないようにしたり、次回以降の通信ゲームにおいて不利な状況でプレイさせたりするようにしてある。

この第１実施例では、途中終了とは、通信ゲームの実行中に、ゲーム装置１０の電源をオフしたり、通信を強制的に切断したりすることを意味する。ただし、プレイヤが意図的に通信を切断しない場合であっても、通信環境の悪化によって通信が切断されてしまう場合もある。

つまり、この第１実施例では、通信ゲームを途中終了されたり、次回の通信ゲームへの参加を拒否されたりしたということは、通信ゲームを途中終了したり、次回の通信ゲームへの参加を拒否したりしたプレイヤが、上記のような、不正行為に遭ったり、不快な行為を受けたりしたと仮定してある。

ただし、これを逆手にとって、或るプレイヤを陥れるために、故意に、通信ゲームを途中終了したり、次回の通信ゲームへの参加を拒否したりすることで、不正行為や不快な行為を行った事実のないプレイヤを、そのような行為を行ったように仕立てようとすることも考えられる。このため、通信ゲームを途中終了したり、次回の通信ゲームへの参加を拒否したりする回数が多いプレイヤ（ゲーム装置１０）については、後述するように、不正行為や不快な行為に基づくプレイヤの悪評についてのスコア（悪評スコア）に与える影響を少なくしてある。

図５は、サーバ１０２に内蔵されるＲＡＭ１０２ｂのメモリマップ１５０の例を示す図解図である。図５に示すように、ＲＡＭ１０２ｂは、プログラム記憶領域１５２およびデータ記憶領域１５４を含む。プログラム記憶領域１５２には、メイン処理プログラム１５２ａ、通信処理プログラム１５２ｂ、マッチングプログラム１５２ｃ、接続情報送信プログラム１５２ｄ、参加者確定プログラム１５２ｅ、参加者情報送信プログラム１５２ｆ、接続確認プログラム１５２ｇ、悪評スコア算出プログラム１５２ｈ、接続拒否回数カウントプログラム１５２ｉおよびバックアッププログラム１５２ｊなどが記憶される。

メイン処理プログラム１５２ａは、この第１実施例の通信ゲームをゲーム装置１０間で実行させるためのメインルーチンを処理するためのプログラムである。通信処理プログラム１５２ｂは、ゲーム装置１０との間で通信処理を行うためのプログラムである。マッチングプログラム１５２ｃは、通信ゲームへの参加の申し込みを行った複数のゲーム装置１０から、当該通信ゲームの対戦相手となる参加予定者のゲーム装置１０を決定（マッチング）するためのプログラムである。この実施例では、マッチングプログラム１５２ｃは、ゲーム装置１０（プレイヤ）についての悪評スコアをデータベース１０６から読み出し、同じまたは同程度の悪評スコアを有するゲーム装置１０同士を参加予定者として決定する。

接続情報送信プログラム１５２ｄは、各参加予定者のゲーム装置１０に他の参加者のゲーム装置１０の接続情報（ＩＰアドレス）を送信するためのプログラムである。参加者確定プログラム１５２ｅは、通信ゲームへの参加者を確定するためのプログラムである。具体的には、サーバ１０２のＣＰＵ１０２ａは、各参加予定者のゲーム装置１０に他の参加予定者のゲーム装置１０の接続情報を送信してから一定時間（たとえば、３０秒）内に、開始通知を送信してきたゲーム装置１０を通信ゲームの参加者として確定する。ただし、ＣＰＵ１０２ａは、上記の一定時間内に、開始通知を送信して来ないゲーム装置１０については、今回の通信ゲームには不参加であると判断する。

参加者情報送信プログラム１５２ｆは、確定した参加者のゲーム装置１０の識別情報のリスト（参加者情報）を、参加者のゲーム装置１０に送信するためのプログラムである。接続確認プログラム１５２ｇは、参加中のゲーム装置１０から送信される接続中メッセージを受信し、参加者の全員から接続中メッセージを受信した場合には、その旨を示すデータ（全員接続データ）を参加者のゲーム装置１０に送信し、参加者の一部から接続中メッセージを受信した場合には、切断したゲーム装置１０の総数についてのデータ（切断数データ）を参加者（参加中）のゲーム装置１０に送信するためのプログラムである。

悪評スコア算出プログラム１５２ｈは、通信ゲームを途中で終了されたり、次回の通信ゲームの継続を拒否されたりしたプレイヤ（ゲーム装置１０）についての悪評スコアを更新するためのプログラムである。継続拒否回数カウントプログラム１５２ｉは、プレイヤ（ゲーム装置１０）毎に、通信ゲームを継続することを拒否した回数（継続拒否回数）をカウントするためのプログラムである。この第１実施例では、後述する継続拒否回数データ１５４ｇが示す継続拒否回数がカウントアップされる。バックアッププログラム１５２ｊは、ＲＡＭ１０２ｂに記憶されたデータをデータベース１０６や他の外部記憶媒体（メモリカードなど）に記憶するためのプログラムである。この第１実施例では、主として、各プレイヤすなわち各ゲーム装置１０の識別情報に対応して、後述する悪評スコアデータ１５４ｆ、継続拒否回数データ１５４ｇおよび対戦中フラグ１５４ｈのそれぞれがデータベース１０６に記憶される。

なお、図示は省略するが、プログラム記憶領域には、画像生成プログラムなどの他のプログラムも記憶される。たとえば、画像生成プログラムは、各ゲーム装置１０が通信ゲームの参加を申し込む際の申し込み画面（図示せず）を表示するための画像データを生成する。

データ記憶領域１５４には、送受信データバッファ１５４ａが設けられる。また、データ記憶領域１５４には、リクエストリストデータ１５４ｂ、参加予定プレイヤリストデータ１５４ｃ、現在参加プレイヤリストデータ１５４ｄ、不参加予定プレイヤリストデータ１５４ｅ、悪評スコアデータ１５４ｆ、継続拒否回数データ１５４ｇが記憶される。さらに、データ記憶領域１５４には、対戦中フラグ１５４ｈが設けられる。

送受信データバッファ１５４ａは、各ゲーム装置１０に送信するデータなどを記憶（一時記憶）したり、各ゲーム装置１０から送信されたデータなどを受信して一時記憶したりするためのバッファである。リクエストリストデータ１５４ｂは、図示は省略するが、通信ゲームへの参加を申し込んだゲーム装置１０の識別情報（プレイヤ名など）および接続情報（ＩＰアドレス）を記載したリスト（リクエストリスト）についてのデータである。

参加予定プレイヤリストデータ１５４ｃは、初回および次回以降の通信ゲームへの参加予定者のゲーム装置１０の識別情報を記載したリスト（参加予定プレイヤリスト）である。たとえば、初回では、データベース１０６に記憶されたプレイヤ毎の悪評スコアデータ１５４ｆが示す悪評スコアに従って参加予定者が決定され、次回以降では、直前の通信ゲームを正常終了したプレイヤのうち、次回の通信ゲームを継続することを許可したプイレヤが参加予定者として決定される。

現在参加プレイヤリストデータ１５４ｄは、実際に通信ゲームに参加している参加者のゲーム装置１０（プレイヤ）の識別情報および通信ゲームを途中終了したかどうかを示す情報（途中終了フラグ）を記載したリスト（現在参加プレイヤリスト）についてのデータである。たとえば、現在参加プレイヤリストデータ１５４ｄに従う現在参加プレイヤリストは、図６のように示される。図６では、簡単のため、プレイヤすなわちゲーム装置１０の識別情報を、一文字のアルファベットで示してあるが、実際には、プレイヤの名称や当該ゲーム装置１０に内蔵される無線通信モジュール６４のＭＡＣアドレスのような固有の識別情報である。また、途中終了フラグは、通信ゲームを途中終了したかどうかを示すフラグである。たとえば、途中終了フラグは、各プレイヤ（ゲーム装置１０）に対応して設けられ、それぞれ１ビットのレジスタで構成される。各途中終了フラグは、対応するプレイヤ（ゲーム装置１０）が通信ゲームを途中終了した場合にオンされ、レジスタにデータ値「１」が設定される。一方、各途中終了フラグは、対応するプレイヤ（ゲーム装置１０）が通信ゲームを途中終了しない場合にオフされ、レジスタにデータ値「０」が設定される。したがって、通信ゲームが終了された場合に、途中終了フラグがオフであるプレイヤ（ゲーム装置１０）はその通信ゲームを正常に終了（正常終了）したことを意味する。一方、通信ゲームが終了された場合に、途中終了フラグがオンであるプレイヤ（ゲーム装置１０）はその通信ゲームを途中終了したことを意味する。

図５に戻って、不参加予定プレイヤリストデータ１５４ｅは、次回以降の通信ゲームへの参加を拒否したゲーム装置１０の識別情報を記載したリスト（非参加予定プレイヤリスト）である。

悪評スコアデータ１５４ｆは、各プレイヤ（ゲーム装置１０）についての悪評スコアのデータである。上述したように、悪評スコアデータ１５４ｆは、データベース１０６にバックアップされるため、通信ゲームの参加の申し込みを受け付けた後に、参加予定者を決定（マッチング）する際に、参加の申し込みの有ったゲーム装置１０の各々についてデータベース１０６から読み込まれ、通信ゲームが実行されることにより更新される。ただし、バックアップの処理は、一定時間（たとえば、３０秒〜６０秒）毎のタイミングなどの所定のイベントが発生したときに実行され、データベース１０６に記憶されている、少なくとも、悪評スコアデータ１５４ｆと、後述する継続拒否回数データ１５４ｇと、後述する対戦中フラグ１５４ｈとが更新される。

継続拒否回数データ１５４ｇは、各プレイヤ（ゲーム装置１０）についての継続拒否回数のデータである。ただし、継続拒否回数は、通信ゲームを継続することを拒否した回数、すなわち、通信ゲームを途中終了した回数および次回の通信ゲームへの参加を拒否した回数を意味する。上述したように、この継続拒否回数データ１５４ｇは、データベース１０６にバックアップされるため、たとえば通信ゲームの募集を開始する際にデータベース１０６から読み込まれ、通信ゲームの募集時に更新されたり、通信ゲームが実行されることにより更新されたりする。

対戦中フラグ１５４ｈは、各プレイヤ（ゲーム装置１０）についての通信ゲームの開始および終了（正常終了）を監視（記録）するためのフラグである。対戦中フラグ１５４ｈは、サーバ１０２に登録されたゲーム装置１０の数だけ設けられ、各対戦中フラグ１５４ｈは１ビットのレジスタで構成される。或るゲーム装置１０についての対戦中フラグ１５４ｈがオンされると、対応するレジスタにデータ値「１」が設定される。また、或るゲーム装置１０についての対戦中フラグ１５４ｈがオフされると、対応するレジスタにデータ値「０」が設定される。ただし、ゲーム装置１０からの開始通知を受信したときに、当該ゲーム装置１０についての対戦中フラグ１５４ｈがオンされる。一方、ゲーム装置１０からの終了通知を受信したときに、当該ゲーム装置１０に対応する対戦中フラグ１５４ｈがオフされる。したがって、ゲーム装置１０が、通信ゲームを途中終了した場合には、当該ゲーム装置１０から終了通知は送信されないため、かかる場合には、当該ゲーム装置１０に対応する対戦中フラグ１５４ｈはオフされない。

また、上述したように、対戦中フラグ１５４ｈは、データベース１０６にバックアップされるため、たとえばゲーム装置１０からの接続リクエストを受信したときに、当該ゲーム装置１０についての対戦中フラグ１５４ｈがデータベース１０６から読み込まれ、当該ゲーム装置１０が通信ゲームを開始したときにオンされ、当該ゲーム装置１０が通信ゲームを正常終了したときにオフされる。

なお、図示は省略するが、データ記憶領域１５４には、画像データなどの他のデータが記憶されるとともに、サーバ１０２の処理に必要な他のフラグやカウンタ（タイマ）も設けられる。

図７はゲーム装置１０のメインメモリ５２のメモリマップ２００の例を示す図解図である。図７に示すように、メインメモリ５２は、プログラム記憶領域２０２およびデータ記憶領域２０４を含む。プログラム記憶領域２０２には、メイン処理プログラム２０２ａ、通信処理プログラム２０２ｂ、画像生成プログラム２０２ｃ、画像表示プログラム２０２ｄ、接続処理プログラム２０２ｅ、接続確認プログラム２０２ｆ、次ゲーム拒否判断プログラム２０２ｇ、次ゲーム拒否判断通知プログラム２０２ｈ、通信強制終了プログラム２０２ｉおよびバックアッププログラム２０２ｊが記憶される。

メイン処理プログラム２０２ａは、通信ゲームのメインルーチンを処理するためのプログラムである。通信処理プログラム２０２ｂは、他のゲーム装置１０またはサーバ１０２との間で通信を実行するためのプログラムである。画像生成プログラム２０２ｃは、後述する画像データ２０４ｃを用いて、第１ＬＣＤ１６および第２ＬＣＤ１８に表示するゲーム画面（メニュー画面や操作画面なども含む）に対応するゲーム画像データを生成するためのプログラムである。画像表示プログラム２０２ｄは、画像生成プログラム２０２ｃに従って生成されたゲーム画像データをゲーム画面として第１ＬＣＤ１６および第２ＬＣＤ１８に表示するためのプログラムである。

接続処理プログラム２０２ｅは、サーバ１０２から受信した接続情報（ＩＰアドレス）に従って他の参加予定者のゲーム装置１０との間で接続状態を確立するためのプログラムである。接続確認プログラム２０２ｆは、通信ゲームの実行中に、接続中メッセージをサーバ１０２に送信するとともに、サーバ１０２から送信される全員接続データまたは切断数データを受信するためのプログラムである。

ここで、接続中メッセージは、ゲーム装置１０が通信ゲームを実行中であること、すなわち他（対戦相手）のゲーム装置１０やサーバ１０２と通信中（接続中）であることを示すメッセージである。

次ゲーム拒否判断プログラム２０２ｇは、次回の通信ゲームを継続して行うことを拒否するかどうかを判断するためのプログラムである。この実施例では、通信ゲームを終了すると、たとえば、同じ対戦相手（厳密には、通信ゲームを正常終了した対戦相手）と、再度プレイするかどうかの選択画面（図示せず）が第１ＬＣＤ１６または第２ＬＣＤ１８或いはその両方に表示される。ここで、プレイヤが再度プレイすることを選択すると、通信ゲームを継続して行うことを拒否しない（許可する）ことが判断される。しかし、プレイヤが再度プレイしない（たとえば、通信ゲームを止める、または他のプレイヤと対戦する）ことを選択すると、通信ゲームを継続して行うことを拒否することが判断される。

次ゲーム拒否判断通知プログラム２０２ｈは、次ゲーム拒否判断プログラム２０２ｇの判断結果の通知をサーバ１０２に送信するためのプログラムである。この第１実施例では、再度プレイすることが選択された場合には、通信ゲームを継続して行うことを許可する旨の通知（継続許可通知）がサーバ１０２に送信される。しかし、通信ゲームを止めることが選択された場合には、通信ゲームを継続して行うことを拒否する旨の通知（継続拒否通知）がサーバ１０２に送信される。また、他のプレイヤと対戦したりすることが選択された場合には、ゲーム装置１０は他のプレイヤと対戦するための通信ゲームへの参加の申し込み通知をサーバ１０２に送信する。

通信強制終了プログラム２０２ｉは、通信ないし通信ゲームを強制的に終了するためのプログラムである。この実施例では、ゲーム装置１０が、サーバ１０２に通信ゲームへの参加の申し込みをした場合に、サーバ１０２からの通信ゲーム不可通知を受信すると、通信ゲームをプレイすることなく、通信を強制的に終了される。つまり、通信ゲームに参加することが拒否される。また、通信ゲームのプレイ中に、他の参加者（ゲーム装置１０）がすべて通信ゲームを途中で終了した場合、つまり通信ゲームの参加者が自己のゲーム装置１０だけになった場合にも、通信ゲーム（通信）が強制的に終了される。

バックアッププログラム２０２ｊは、メインメモリ５２に記憶されたゲームデータ（途中データや結果データ）を、プレイヤの指示などの所定のイベントに従って、メモリカード２８や保存用データメモリ５６に記憶（セーブ）するためのプログラムである。

図示は省略するが、プログラム記憶領域２０２には、音出力プログラムなども記憶される。音出力プログラムは、通信ゲームに必要な音（音楽）を生成および出力するためのプログラムである。

データ記憶領域２０４には、操作データバッファ２０４ａおよび送受信データバッファ２０４ｂが設けられる。また、データ記憶領域２０４には、画像データ２０４ｃおよび参加者情報データ２０４ｄが記憶される。

操作データバッファ２０４ａは、プレイヤによって操作された操作ボタン２０に対応する操作データまたはタッチパネル２２から入力される座標データを記憶（一時記憶）するためのバッファである。送受信データバッファ２０４ｂは、他のゲーム装置１０やサーバ１０２に送信するデータなどを記憶（一時記憶）したり、他のゲーム装置１０やサーバ１０２から送信されたデータなどを受信して一時記憶したりするためのバッファである。

画像データ２０４ｃは、上述したゲーム画像データを生成するためのポリゴンデータやテクスチャデータなどのデータである。参加者情報データ２０４ｄは、通信ゲームに参加することが確定したプレイヤ（ゲーム装置１０）の識別情報を記載したリスト（参加者情報）についてのデータである。ただし、参加者情報は、第１実施例では、単なる参加者数についてのデータであってもよい。この参加者情報データ２０４ｄは、上述したように、サーバ１０２から送信される。

図示は省略するが、データ記憶領域２０４には、音データなど、通信ゲームの処理の実行に必要な他のデータが記憶されるとともに、通信ゲームの処理の実行に必要なフラグやカウンタ（タイマ）なども設けられる。

以下、具体的な動作について説明する。ただし、図８ないし図１１がゲーム装置１０のＣＰＵ５０の全体処理であり、図１２ないし図１６がサーバ１０２のＣＰＵ１０２ａの全体処理である。

図８に示すように、ゲーム装置１０のＣＰＵ５０は全体処理を開始すると、ステップＳ１で、接続リクエストをサーバ１０２に送信する。具体的には、ＣＰＵ５０は、通信ゲームへの参加の申し込み通知をサーバ１０２に送信する。次のステップＳ３では、サーバ１０２から通信ゲーム不可通知を受信したかどうかを判断する。

ステップＳ３で“ＹＥＳ”であれば、つまりサーバ１０２から通信ゲーム不可通知を受信すると、図１１に示すステップＳ５３で、通信を終了し、全体処理を終了する。つまり、通信ゲームへの参加が拒否され、通信が強制的に終了される。一方、ステップＳ３で“ＮＯ”であれば、つまりサーバ１０２から通信ゲーム不可通知を受信しなければ、次のステップＳ５で、サーバ１０２から参加予定者の接続情報を受信したかどうかを判断する。

ステップＳ５で“ＮＯ”であれば、つまりサーバ１０２から参加予定者の接続情報を受信しなければ、そのままステップＳ３に戻る。一方、ステップＳ５で“ＹＥＳ”であれば、つまりサーバ１０２から参加予定者の接続情報を受信すれば、ステップＳ７で、その接続情報に従って参加予定者のゲーム装置１０と接続する。つまり、ゲーム装置１０は、参加予定者のゲーム装置１０との間で接続状態を確立する。続くステップＳ９では、開始通知をサーバ１０２に送信する。

なお、ステップＳ７では、すべての参加予定者のゲーム装置１０と接続できることを前提としてあるが、一定時間（たとえば、３０秒）を経過しても、接続状態を確立することができない参加予定者のゲーム装置１０については、今回の通信ゲームに参加しないと判断して、そのままステップＳ９に進むようにしてよい。また、このとき、すべての参加予定者のゲーム装置１０と接続状態を確立できない場合には、通信ゲームに参加できないと判断して、ステップＳ５３に進むようにしてもよい。

続いて、ステップＳ１１では、サーバ１０２から参加者情報を受信したかどうかを判断する。ステップＳ１１で“ＮＯ”であれば、つまりサーバ１０２から参加者情報を受信していなければ、同じステップＳ１１に戻る。一方、ステップＳ１１で“ＹＥＳ”であれば、つまりサーバ１０２から参加者情報を受信すれば、ステップＳ１３で、参加者情報（参加者情報データ２０４ｄ）をメインメモリ５２に記憶して、図９に示すステップＳ１５で、対戦が終わったかどうかを判断する。つまり、ＣＰＵ５０は、対戦ゲームの勝敗が決まる、ゲームオーバとなる、ステージクリアとなる等の条件によって通信ゲームを正常終了したかどうかを判断する。

ステップＳ１５で“ＹＥＳ”であれば、つまり対戦が終われば、図１１に示すステップＳ３９に進む。一方、ステップＳ１５で“ＮＯ”であれば、つまり対戦が終わっていなければ、ステップＳ１７で、自己の操作データを対戦相手（他の参加者）のゲーム装置１０に送信する。

なお、詳細な説明は省略するが、ステップＳ１７では、ＣＰＵ５０は、無線通信モジュール６４を用いて、操作データバッファ２０４ａに記憶された操作データの複製に自己のゲーム装置１０の識別情報を付加して、対戦相手のゲーム装置１０に送信する。ただし、操作データは、対戦相手のゲーム装置１０に、ブロードキャストされてもよく、複数の対戦相手の各々のゲーム装置１０の間で巡回的に送信されてもよい。

続くステップＳ１９では、すべての対戦相手の操作データを受信したかどうかを判断する。ここでは、ＣＰＵ５０は、参加者情報データ２０４ｄを参照して、すべての参加者（対戦相手）のゲーム装置１０からの操作データを受信したかどうかを判断するのである。ステップＳ１９で“ＹＥＳ”であれば、つまりすべての対戦相手の操作データを受信すると、そのままステップＳ２３に進む。一方、ステップＳ１９で“ＮＯ”であれば、つまり操作データを受信していない対戦相手のゲーム装置１０が存在する場合には、ステップＳ２１で、一定時間を経過したかどうかを判断する。ＣＰＵ５０は、自己の操作データを送信してから、または対戦相手からの操作データを最初に受信してからの時間を、ＲＴＣ６８によって計時された時間に基づいて取得し、取得した時間が一定時間（たとえば、１０秒）を経過したかどうかを判断する。

ステップＳ２１で“ＮＯ”であれば、つまり一定時間を経過していなければ、そのままステップＳ１９に戻る。一方、ステップＳ２１で“ＹＥＳ”であれば、つまり一定時間を経過すれば、ステップＳ２３で、自己および対戦相手の操作データをゲームに反映する。具体的には、ＣＰＵ５０は、ステップＳ２３で、各プレイヤキャラクタの位置を更新したり、各プレイヤキャラクタの動作を制御したりして、ゲーム画面を更新する。ただし、操作データを受信できなかった相手が存在する場合は、当該相手のプレイヤキャラクタを静止させてもよいし、過去の操作データから、位置や動作を推定してもよい。このとき、ＣＰＵ５０は、ゲームに必要な音（音楽）を生成および出力する。また、必要に応じて、ＣＰＵ５０は、得点処理を実行する。次のステップＳ２５では、接続中メッセージをサーバ１０２に送信する。

続いて、図１０に示すステップＳ２７では、全員接続データまたは切断数データをサーバ１０２から受信したかどうかを判断する。ただし、この第１実施例では、ゲーム装置１０は、参加者情報（参加者情報データ２０４ｄ）を管理しているため、切断数データに代えて、通信ゲームを途中終了したゲーム装置１０（プレイヤ）の識別情報をサーバ１０２が送信し、これを受信するようにしても、切断したプレイヤの数（通信ゲームを途中終了したプレイヤの人数）を知ることができる。

ステップＳ２７で“ＹＥＳ”であれば、つまり全員接続データまたは切断数データをサーバ１０２から受信すれば、そのままステップＳ３３に移行する。一方、ステップＳ２７で“ＮＯ”であれば、つまり全員接続データおよび切断数データをサーバ１０２から受信しなければ、ステップＳ２９で、一定時間を経過したかどうかを判断する。図示は省略するが、ＣＰＵ５０は、接続中メッセージをサーバ１０２に送信してからの時間を、ＲＴＣ６８によって計時される時間に基づいて取得し、取得した時間が一定時間（たとえば、３０秒）を経過したかどうかを判断する。

ステップＳ２９で“ＮＯ”であれば、つまり一定時間を経過していなければ、そのままステップＳ２７に戻る。一方、ステップＳ２９で“ＹＥＳ”であれば、つまり一定時間を経過すれば、ステップＳ３１で、受信不能データを作成して、ステップＳ３３に進む。ここで、受信不能データは、サーバ１０２から全員接続データおよび切断数データを受信できなかったことを示すデータである。また、この受信不能データは、メインメモリ５２のバッファ領域（図示せず）に一時記憶される。

ステップＳ３３では、全員接続データまたは受信不能データが有るかどうかを判断する。ステップＳ３３で“ＹＥＳ”であれば、つまり全員接続データまたは受信不能データが有れば、図９に示したステップＳ１５に戻って通信ゲームを続行する。一方、ステップＳ３３で“ＮＯ”であれば、つまり切断数データが有れば、ステップＳ３５で、切断したプレイヤの総数が全参加者数−１よりも小さいかどうかを判断する。つまり、自己のゲーム装置１０だけが通信ゲームに参加している状態でないかどうかを判断する。ただし、切断数データが示す数は、通信ゲームの開始から現時点までの間に、通信ゲームを途中終了したゲーム装置１０の総数（切断したプレイヤの総数）である。

なお、この第１実施例では、受信不能データが有る場合にも通信ゲームを続行するようにしてあるが、受信不能データが連続して作成される場合には、自己のゲーム装置１０の通信が途絶えている可能性が高い。このため、受信不能データが連続して作成される個数をカウントしておき、その個数が一定数（たとえば、３）を超える場合には、通信（通信ゲーム）を終了するようにしてもよい。

図１０に戻って、ステップＳ３５で“ＹＥＳ”であれば、つまり切断したプレイヤの総数が全参加者数−１よりも小さければ、そのままステップＳ１５に戻り、通信ゲームを続行する。一方、ステップＳ３５で“ＮＯ”であれば、つまり切断したプレイヤの総数が参加者数−１以上であれば、ステップＳ３７で、サーバ１０２に終了通知を送信して、ステップＳ５３に進む。この第１実施例では、通信ゲームの参加者が自己のゲーム装置１０のみになった場合には、通信ゲームを終了（正常終了）するようにしてある。ただし、かかる場合であっても、通信ゲームを続行してもよい。これらは、通信ゲームの種類や設計に応じて決定される事項である。

また、対戦が終わると、上述したように、ステップＳ１５で“ＹＥＳ”となり、図１１に示すステップＳ３９で、終了通知をサーバ１０２に送信する。なお、自己のゲーム装置１０が通信ゲームを途中終了した場合には、このような終了通知が送信されることはない。続くステップＳ４１では、対戦結果をサーバ１０２に送信する。この第１実施例では、対戦結果をサーバ１０２に送信するようにしてあるが、各ゲーム装置１０で対戦結果をバックアップするようにしてもよい。

次のステップＳ４３では、続けて対戦するかどうかをプレイヤに問い合わせる。ここでは、ＣＰＵ５０は、同じ対戦相手と再度通信ゲームをプレイするか否かを選択するための選択画面を第１ＬＣＤ１６または第２ＬＣＤ１８或いはそれらの両方に表示する。ただし、上述したように、選択画面では、通信ゲームを止めることや他のプレイヤと対戦することも選択することができる。

ステップＳ４５では、続けて対戦するかどうかを判断する。つまり、ＣＰＵ５０は、選択画面において、同じ対戦相手と再度通信ゲームをプレイすることが選択されたかどうかを判断する。ステップＳ４５で“ＮＯ”であれば、つまり通信ゲームを止めることや他のプレイヤと対戦することが選択されれば、ステップＳ４６で継続拒否通知をサーバに送信し、ステップＳ５３に進む。

なお、図示は省略するが、他のプレイヤと対戦する場合には、通信を終了せずに、他のプレイヤと対戦するための通信ゲームの参加の申し込みの通知をサーバ１０２に送信して、図８に示したステップＳ３に戻る。

また、ステップＳ４５で“ＹＥＳ”であれば、つまり、同じ対戦相手と続けて対戦することが選択されれば、ステップＳ４７で、継続許可通知をサーバ１０２に送信して、ステップＳ４９で、サーバ１０２から次回の参加予定者の識別情報を受信したかどうかを判断する。ステップＳ４９で“ＮＯ”であれば、つまりサーバ１０２から次回の参加予定者の識別情報を受信していなければ、同じステップＳ４９に戻る。一方、ステップＳ４９で“ＹＥＳ”であれば、つまりサーバ１０２から次回の参加予定者の識別情報を受信すれば、ステップＳ５１で、次回の参加予定者が２人以上であるかどうかを判断する。つまり、ＣＰＵ５０は、受信した参加予定者の識別情報に、当該ゲーム装置１０（プレイヤ）の識別情報以外の識別情報も記載されているかどうかを判断するのである。

ステップＳ５１で“ＹＥＳ”であれば、つまり次回の参加予定者が２人以上であれば、図８に示したステップＳ９に戻り、再度対戦ゲームを行う。一方、ステップＳ５１で“ＮＯ”であれば、つまり次回の参加予定者が２人未満であれば、通信ゲームが成立しないため、ステップＳ５３で、通信を終了して、全体処理を終了する。

図１２に示すように、サーバ１０２のＣＰＵ１０２ａは全体処理を開始すると、ステップＳ７１で、ゲーム装置１０からの接続リクエスト（参加の申し込みの通知）を受信したかどうかを判断する。ステップＳ７１で“ＮＯ”であれば、つまりゲーム装置１０からの接続リクエストを受信していなければ、そのまま図１３に示すステップＳ８９に進む。一方、ステップＳ７１で“ＹＥＳ”であれば、つまりゲーム装置１０からの接続リクエストを受信すれば、ステップＳ７３で、当該ゲーム装置１０の対戦中フラグ１５４ｈがオンかどうかを判断する。ここでは、ＣＰＵ１０２ａは、接続リクエストの送り主であるゲーム装置１０についての対戦中フラグ１５４ｈをデータベース１０６から読み込み、その対戦中フラグ１５４ｈがオンであるかどうかを判断するのである。

ステップＳ７３で“ＮＯ”であれば、つまり当該ゲーム装置１０の対戦中フラグ１５４ｈがオフであれば、前回の通信ゲームを正常終了したと判断して、そのままステップＳ７７に進む。一方、ステップＳ７３で“ＹＥＳ”であれば、つまり当該ゲーム装置１０の対戦中フラグ１５４ｈがオンであれば、前回の通信ゲームを正常終了していないと判断して、つまり前回の通信ゲームを途中で終了したと判断して、ステップＳ７５で、当該ゲーム装置１０の継続拒否回数を１加算して、ステップＳ７７に進む。つまり、ステップＳ７５では、ＣＰＵ１０２ａは、接続リクエストの送り主であるゲーム装置１０についての継続拒否回数データ１５４ｇをデータベース１０６から読み込み、その継続拒否回数データ１５４ｇが示す継続拒否回数を１加算するのである。

ステップＳ７７では、当該ゲーム装置１０をリクエストリストに追加する。ここでは、ＣＰＵ１０２ａは、リクエストリストデータ１５４ｂが示すリクエストリストに、接続リクエストの送り主であるゲーム装置１０の識別情報を追加する。続いて、ステップＳ７９で、参加受付を終了するかどうかを判断する。たとえば、ＣＰＵ１０２ａは、参加受付の開始（前回の対戦相手の決定処理）から一定時間（たとえば、６０秒）を経過したり、所定数の参加申し込みを受け付けたりすると、参加受付の終了であると判断する。ステップＳ７９で“ＮＯ”であれば、つまり参加受付を終了しない場合には、ステップＳ７１に戻る。一方、ステップＳ７９で“ＹＥＳ”であれば、つまり参加受付を終了する場合には、ステップＳ８１で、各ゲーム装置１０（プレイヤ）についての悪評スコアを取得する。つまり、ＣＰＵ１０２ａは、リクエストリストに記載された識別情報に対応するゲーム装置１０（プレイヤ）の各々についての悪評スコアデータ１５４ｆをデータベース１０６から読み込む。

続くステップＳ８３では、悪評スコアが一定値以上のゲーム装置１０に通信ゲーム不可通知を送信する。この第１実施例では、悪評スコアは最低値（０）から加算されるようにしてあり、一定値はこのゲームシステム１００（サーバ１０２）の管理者等によって任意に決定される。このため、上述したように、悪評スコアが一定値以上であるゲーム装置１０（プレイヤ）は通信ゲームへの参加すら拒否される。

図１３に示すように、次のステップＳ８５では、悪評スコアが所定範囲内のプレイヤを結びつける（マッチングする）。つまり、ＣＰＵ１０２ａは、悪評スコアが同じまたは同程度のプレイヤ（ゲーム装置１０）同士が対戦相手となるように参加予定者を決定する。したがって、参加予定者としての２つのゲーム装置１０または３つ以上のゲーム装置１０で構成されるグループが生成される。たとえば、ステップＳ８５では、２つ以上のグループが生成される場合があり、ステップＳ８７以降の処理は、グループ毎に実行される。ただし、簡単のため、ステップＳ８５では、１つのグループが生成されたと仮定して、ステップＳ８７以降の処理について説明する。

ステップＳ８７では、参加予定者の接続情報を各ゲーム装置１０に送信する。つまり、ＣＰＵ１０２ａは、グループに含まれる各参加予定者（ゲーム装置１０）に、他の参加予定者の接続情報（ＩＰアドレス）を送信する。次のステップＳ８９では、接続情報を送信したゲーム装置のうち、今回の通信ゲームへの参加者となるゲーム装置が確定したかどうかを判断する。ここでは、ＣＰＵ１０２ａは、グループに含まれる各参加予定者のゲーム装置１０に、他の参加予定者のゲーム装置１０の接続情報を送信してから一定時間（たとえば、６０秒）を経過したか、または、それらすべての参加予定者のゲーム装置１０から開始通知を受信したかどうかを判断する。

なお、図示は省略するが、一定時間（６０秒）をカウントするためのタイマはサーバ１０２の内部に設けられており、ＣＰＵ１０２ａは、ステップＳ８７の処理を実行したときにタイマをスタートし、ステップＳ８９で、タイマのカウント値に応じて一定時間を経過したかどうかを判断する。タイマのカウント値が所定値に達した場合は、タイムアウトになったとして、参加者が確定したと判断される。カウント値が所定値に達していない場合でも、全ての参加予定者のゲーム装置１０から開始通知を受信した場合には、参加者が確定したと判断される。また、タイマのカウント中に参加予定者のゲーム装置１０のいずれかから開始通知を受信したときは、カウント値をリセットすることで、最後に参加予定者のゲーム装置１０のいずれかから開始通知を受信してから一定時間を経過したかによって参加者の確定を判断するようにしてもよい。

ステップＳ８９で“ＮＯ”であれば、つまり今回の通信ゲームへの参加者が確定していなければ、ステップＳ９１へ進む。一方、ステップＳ８９で“ＹＥＳ”であれば、つまり今回の通信ゲームへの参加者が確定すれば、ステップＳ１０１へ進む。

ステップＳ９１では、参加予定者の接続情報を送信したゲーム装置１０のいずれかから開始通知を受信したかどうかを判断する。ステップＳ９１で“ＮＯ”であれば、つまりゲーム装置１０から開始通知を受信していなければ、ステップＳ８９に戻る。一方、ステップＳ９１で“ＹＥＳ”であれば、つまりゲーム装置１０から開始通知を受信すれば、ステップＳ９３で、開始通知の送り主であるゲーム装置１０についての対戦中フラグ１５４ｈをオンし、ステップＳ９５で、開始通知の送り主であるゲーム装置１０を現在参加プレイヤリストに記憶して、ステップＳ８９へ戻る。つまり、ステップＳ９５では、ＣＰＵ１０２ａは、図６に示したような現在参加プレイヤリストデータ１５４ｄが示す現在参加プレイヤリストに、開始通知の送り主であるゲーム装置１０の識別情報を記載するとともに、その識別情報に対応して設けられる途中終了フラグをオフする。このようにして、開始通知の送り主であるゲーム装置１０のプレイヤが、今回の通信ゲームの参加者として現在参加プレイヤリストに登録される。

そして、ステップＳ１０１で、参加者情報データを全参加者のゲーム装置１０に送信して、図１４に示すステップＳ１０３に進む。ただし、参加者情報データは、現在参加プレイヤリストに記載されたゲーム装置１０の識別情報を抽出した情報（リスト）についてのデータである。

なお、上述したように、参加者情報データとして、参加者数（参加者の総数）のデータを送信するようにしてもよい。

図１４に示すように、ステップＳ１０３では、通信ゲームに参加しているゲーム装置１０のいずれかから終了通知を受信したかどうかを判断する。ステップＳ１０３で“ＮＯ”であれば、つまりゲーム装置１０から終了通知を受信していなければ、そのままステップＳ１１１に進む。一方、ステップＳ１０３で“ＹＥＳ”であれば、つまりゲーム装置１０から終了通知を受信すれば、ステップＳ１０５で、終了通知の送り主であるゲーム装置１０についての対戦中フラグ１５４ｈをオフして、ステップＳ１１１に進む。つまり、ステップＳ１０５では、終了通知の送り主のゲーム装置１０が通信ゲームを正常終了したことが記録される。

ステップＳ１１１では、ゲーム装置１０から接続中メッセージを受信したかどうかを判断する。ステップＳ１１１で“ＮＯ”であれば、つまりゲーム装置１０から接続中メッセージを受信していなければ、そのままステップＳ１１５に進む。一方、ステップＳ１１１で“ＹＥＳ”であれば、つまりゲーム装置１０から接続中メッセージを受信すれば、ステップＳ１１３で、接続中メッセージの送り主のゲーム装置１０の識別情報をＲＡＭ１０２ｂのバッファ領域（図示せず）に一時記憶して、ステップＳ１１５に進む。

ステップＳ１１５では、現在参加中の全ゲーム装置１０から接続中メッセージを受信したかどうかを判断する。つまり、ＣＰＵ１０２ａは、現在参加プレイヤリストにおいて、途中終了フラグがオフである識別情報のゲーム装置１０のすべてから接続中メッセージを受信したかどうかを判断する。ステップＳ１１５で“ＮＯ”であれば、つまり現在参加中のゲーム装置１０のうち、接続中メッセージを受信していないゲーム装置１０が有れば、そのまま図１５に示すステップＳ１１９に進む。一方、ステップＳ１１５で“ＹＥＳ”であれば、つまり現在参加中の全ゲーム装置１０から接続中メッセージを受信すれば、ステップＳ１１７で、全員接続データを現在参加中の各ゲーム装置に送信して、図１５に示すステップＳ１２７に進む。

図１５に示すステップＳ１１９では、一定時間を経過したかどうかを判断する。図示は省略するが、ＣＰＵ１０２ａは、ステップＳ１１１において、今回のセッションにおいて、接続メッセージを最初に受信したときに、内部タイマのカウントを開始し、そのカウント値が一定時間（たとえば、１０秒）を経過したかどうかを判断する。

ただし、一定時間をカウントする方法はこれに限られず、接続メッセージを最初に受信したときに、内部タイマの値を保存しておき、現在のタイマ値との差を算出し、当該差が一定値に達しているかによって判断してもよい。

ステップＳ１１９で“ＮＯ”であれば、つまり一定時間を経過していなければ、図１４に示したステップＳ１１１に戻る。一方、ステップＳ１１９で“ＹＥＳ”であれば、つまり一定時間を経過すれば、ステップＳ１２１で、現在参加プレイヤリストを更新する。つまり、ステップＳ１２１では、ＣＰＵ１０２ａは、接続中メッセージを一定時間内に受信しなかったゲーム装置１０については、通信ゲームを途中終了したと判断して、現在参加プレイヤリストにおいて、当該ゲーム装置１０の識別情報に対応する途中終了フラグをオンする。

続いて、ステップＳ１２３では、切断数データを現在参加中の各ゲーム装置に送信する。つまり、ＣＰＵ５０は、現在参加プレイヤリストにおいて、途中終了フラグがオンであるゲーム装置１０の数に対応する切断数データを、途中終了フラグがオフであるゲーム装置１０に送信する。さらに、ステップＳ１２５で、後述する悪評スコアの更新処理（図１７参照）を実行して、ステップＳ１２７で、受信したすべての接続中メッセージを削除する。つまり、今回のセッションについての接続中データが削除される。ただし、ステップＳ１２５の処理は、通信ゲームを途中終了されたゲーム装置１０すなわち通信ゲームに参加中のゲーム装置１０が複数存在する場合には、各ゲーム装置１０について実行される。

ステップＳ１２９では、一度通信ゲームが終了した後に、次回の通信ゲームの参加予定者が確定したかどうかを判断する。ここでは、ＣＰＵ１０２ａは、後述の継続許可通知または継続拒否通知を受信することなく一定時間（たとえば、３０秒）を経過したか、または、最後に継続許可通知または継続拒否通知を受信してから一定時間（たとえば、３０秒）を経過したか、あるいは、直前の通信ゲームを正常終了したすべてのゲーム装置１０から継続許可通知または継続拒否通知を受信したかどうかを判断する。すべてのゲーム装置１０から継続許可通知または継続拒否通知を受信したかどうかについては、ＣＰＵ１０２ａは、参加予定プレイヤリストや不参加予定プレイヤリストを参照することで判断することができる。

なお、参加予定プレイヤリストおよび不参加予定プレイヤリストに識別情報が記載されていないゲーム装置１０からの継続許可通知や継続拒否通知については、ＣＰＵ１０２ａは、継続許可通知や継続拒否通知を受信していないと判断することができる。

なお、ＣＰＵ１０２ａは、最初にステップＳ１２９の判断を行ったときに、図示しない内部タイマをスタートし、そのカウント値が一定時間を経過したかどうかを判断する。また、継続許可通知や継続拒否通知を受信するたびに、内部タイマのカウント値をリセットすることで、最後に継続許可通知や継続拒否通知を受信してからの時間を計測することも可能である。

ステップＳ１２９で“ＮＯ”であれば、つまり参加予定者が確定していなければ、ステップＳ１３１へ進む。一方、ステップＳ１２９で“ＹＥＳ”であれば、つまり参加予定者が確定すれば、後述する図１６のステップＳ１３９へ進む。ステップＳ１３１で、ゲーム装置１０から継続許可通知を受信したかどうかを判断する。ステップＳ１３１で“ＮＯ”であれば、つまりゲーム装置１０から継続許可通知を受信していなければ、ステップＳ１３２へ進む。一方、ステップＳ１３１で“ＹＥＳ”であれば、つまりゲーム装置１０から継続許可通知を受信すれば、ステップＳ１３３で、参加予定プレイヤリストに当該ゲーム装置１０（プレイヤ）を追加し、ステップＳ１２９へ戻る。つまり、ＣＰＵ１０２ａは、ステップＳ１３３で、参加予定プレイヤリストデータ１５４ｃが示す参加予定プレイヤリストに、継続許可通知の送り主であるゲーム装置１０の識別情報を記載する。

また、ステップＳ１３２では、ゲーム装置１０から継続拒否通知を受信したかどうかを判断する。ステップＳ１３２で“ＮＯ”であれば、つまりゲーム装置１０から継続拒否通知を受信していなければ、そのままステップＳ１２９に戻る。一方、ステップＳ１３２で“ＹＥＳ”であれば、つまりゲーム装置１０から継続拒否通知を受信すれば、不参加予定プレイヤリストに当該プレイヤを追加して、ステップＳ１２９に戻る。つまり、ＣＰＵ１０２ａは、ステップＳ１３４で、不参加予定プレイヤリストデータ１５４ｅが示す不参加予定プレイヤリストに、継続拒否通知の送り主であるゲーム装置１０の識別情報を記載する。

図１６に示すように、ステップＳ１３９では、直前の通信ゲームを正常終了したゲーム装置１０の識別情報を取得する。ここでは、ＣＰＵ１０２ａは、現在参加プレイヤリストを参照して、途中終了フラグがオフであるゲーム装置１０（プレイヤ）の識別情報を取得する。

次のステップＳ１４１では、参加予定者の識別情報を取得する。ここでは、ＣＰＵ１０２ａは、参加予定者リストを参照して、当該参加予定者リストに記載されているゲーム装置１０（プレイヤ）の識別情報を取得する。続いて、ステップＳ１４３では、直前の通信ゲームを正常終了したゲーム装置１０（プレイヤ）のうち、次回不参加のゲーム装置１０（プレイヤ）が存在するかどうかを判断する。つまり、ＣＰＵ１０２ａは、ステップＳ１３９で取得した直前の通信ゲームを正常終了した参加者の識別情報の数が、ステップＳ１４１で取得した参加予定者の識別情報の数よりも多いかどうかどうかを判断する。

ステップＳ１４３で“ＮＯ”であれば、つまり直前の通信ゲームを正常終了したすべてのゲーム装置１０（プレイヤ）が次回の通信ゲームに参加予定である場合には、そのままステップＳ１５１に進む。一方、ステップＳ１４３で“ＹＥＳ”であれば、つまり直前の通信ゲームを正常終了したプレイヤのうち、次回不参加のゲーム装置１０（プレイヤ）が存在する場合には、ステップＳ１４５で、不参加人数が所定値以上であるかどうかを判断する。たとえば、所定値は「３」に設定される。ただし、所定値に代えて、前回正常終了したゲーム装置１０（プレイヤ）の総数に対する不参加人数の割合が所定の割合（たとえば、３０％）以上かどうかを判断するようにしてもよい。また、所定値や所定の割合は、前回正常終了したゲーム装置１０（プレイヤ）の総数に応じて可変的に設定するようにしてもよい。

なお、この第１実施例では、不正行為や不快な行為に出会うと、参加者の多くが次回の通信ゲームを継続したくないと感じ、一斉に次回の通信ゲームの継続を拒否すると思われる。しかし、何らかの用事ができた場合のように、単に次回の通信ゲームの継続を拒否するような場合には、参加者の多くが一斉に次回の通信ゲームの継続を拒否することは考えにくく、少数の人が拒否するに過ぎないと考えられる。このような前提のもとで、不参加人数が所定値（所定の割合）以上である場合に、次の通信ゲームを継続してプレイするプレイヤが不正行為や不快な行為を行う者として判断して、悪評スコアを更新するようにしてあるが、これに限定される必要はない。不参加人数に拘わらず、不参加者が１人でも存在する場合には、次の通信ゲームを継続してプレイするプレイヤの悪評スコアを更新するようにしてよい。

ステップＳ１４５で“ＮＯ”であれば、つまり不参加人数が所定値未満であれば、悪評スコアを更新しないと判断して、そのままステップＳ１４９に進む。一方、ステップＳ１４５で“ＹＥＳ”であれば、つまり不参加人数が所定値以上であれば、ステップＳ１４７で、悪評スコアの更新処理を実行する。ただし、ステップＳ１４７では、直前の通信ゲームを正常終了し、次回参加予定のゲーム装置１０（プレイヤ）についての悪評スコアが更新される。そして、ステップＳ１４９で、次回不参加のゲーム装置１０（プレイヤ）の継続拒否回数を１加算し、ステップＳ１５１で、参加予定者の識別情報を参加予定者のゲーム装置１０に送信して、ステップＳ７１に戻る。

図１７は、図１５に示したステップＳ１２５および図１６に示したステップＳ１４７の悪評スコアの更新処理のフロー図である。図１７に示すように、ＣＰＵ１０２ａは、悪評スコアの更新処理を開始すると、ステップＳ１６１で、継続を拒否した対戦相手の継続拒否回数データ１５４ｇから加算スコア値を取得する。ただし、「継続を拒否した対戦相手」は、通信ゲームを途中終了したゲーム装置１０（プレイヤ）または次回の通信ゲームへの参加を拒否したゲーム装置１０（プレイヤ）である。このステップＳ１６１では、継続拒否回数が多い場合には、加算スコア値は比較的小さい値に設定される。これは、通信ゲームを頻繁に途中終了したり、次回の通信ゲームへの参加を拒否したりして、通信ゲームを途中終了または次回の通信ゲームへの参加を拒否されるプレイヤの悪評スコアを故意に高くするような行為を防止するためである。また、通信ゲームを様々なプレイヤとプレイしたいと考えるプレイヤは、継続拒否回数が自然と多くなるため、このような悪意の無い行為によって切断されるプレイヤの悪評スコアが高くなってしまうのを防止するためでもある。

たとえば、継続拒否回数毎や継続拒否回数の範囲毎に、悪評スコアの加算スコア値が予め決定されている。ただし、上述したように、継続拒否回数が大きくなるに従って加算スコア値は小さくされる。したがって、継続拒否回数またはその範囲に対応して、加算スコア値を予め設定したテーブルを用意しておき、これを参照して、加算スコア値を決定することができる。また、継続拒否回数に対する加算スコア値を数式（たとえば、反比例の式）によって決定してもよい。

ただし、ステップＳ１６１では、継続を拒否した対戦相手が複数存在する場合には、それぞれの対戦相手の継続拒否回数データ１５４ｇから加算スコア値を取得し、それらを合計した値を得る。

続くステップＳ１６３では、継続を拒否した対戦相手が複数存在するかどうかを判断する。つまり、同時または同時期に、継続を拒否した対戦相手が複数存在するかどうかを判断するのである。ステップＳ１６３で“ＮＯ”であれば、つまり継続を拒否した対戦相手が１人であれば、そのままステップＳ１６７に進む。一方、ステップＳ１６３で“ＹＥＳ”であれば、つまり継続を拒否した対戦相手が複数存在する場合には、ステップＳ１６５で、継続を拒否した対戦相手の数から加算スコア値を補正する。ここでは、継続を拒否した対戦相手の数が多いほど、加算スコア値が大きくされる。したがって、たとえば、継続を拒否した対戦相手の数やその範囲に応じて、加算スコア値を増大させる数値ないし倍率を記載したテーブルを用意しておき、このテーブルを参照して、加算スコア値を補正することができる。また、継続を拒否した対戦相手の数に対する補正後の加算スコア値を数式（たとえば、比例の式）によって決定してもよい。または、加算スコア値に、継続を拒否した対戦相手の数を乗算してもよい。

なお、この第１実施例では、同時または同時期に、一度に複数の対戦相手に継続を拒否された場合には、異なる時期に分散して複数の対戦相手に継続を拒否された場合よりも、不正行為や不快な行為が悪質であったと考えて、ステップＳ１６５において、さらに加算スコア値を大きくするようにしてある。ただし、複数人分についての加算スコア値は、ステップＳ１６１で算出されているため、ステップＳ１６５の処理は無くてもよい。かかる場合には、ステップＳ１６３も省略される。

そして、ステップＳ１６７で、補正後の加算スコア値を、当該プレイヤ（ゲーム装置１０）の悪評スコアに加算して、全体処理にリターンする。

第１実施例によれば、通信ゲームを途中で終了されたり、継続して行う次回の通信ゲームを拒否されたりしたプレイヤについての悪評スコアを更新し、悪評スコアが一定値以上の場合には、通信ゲームに参加できないようにするため、ゲームプログラムを改造したり、ゲームプログラムを想定外使用したりするような不正行為や対戦相手に過度の嫌がらせを行うような不快な行為を間接的な方法によって検知し、そのような行為を抑制ないし防止することができる。

なお、第１実施例では、通信ゲームの内容についてはその詳細を説明していないが、たとえば、悪評スコアに応じて、通信ゲームにおけるプレイヤキャラクタの属性（体力値、レベル、技、性能など）を変更し、悪評スコアが高いプレイヤについては通信ゲームにおいて不利な状況になるように設定してもよい。これは、悪評スコアが段階的にまたは線形的に大きくなるについて、同じく段階的にまたは線形的にプレイヤキャラクタの属性を変化させるようにすればよい。プレイヤキャラクタの属性に限らず、ゲームフィールドやコースにおいて、悪評スコアの高いプレイヤを不利な状況に置くようにしてもよい。ただし、悪評スコアは、サーバ１０２で管理されるため、通信ゲームの開始時に、サーバ１０２から各ゲーム装置１０に、悪評スコアに応じたプレイヤキャラクタの属性を変化させるためのデータを送信するようにする必要がある。または、各々のゲーム装置１０に、悪評スコアを送信し、ゲーム装置１０が悪評スコアに応じて、自己のプレイヤキャラクタの属性値を変化させるようにしてもよい。

また、第１実施例では、通信ゲームが開始されると、ゲーム装置間で操作データないし結果データを送受信するようにしたが、これに限定される必要はない。たとえば、サーバを介して操作データないし結果データを送受信するようにしてもよい。また、各ゲーム装置から操作データを受けたサーバがゲーム処理を実行し、その結果を結果データとして各ゲーム装置に送信するようにしてもよい。このように、ゲーム処理をサーバが実行する場合には、各プレイヤの悪評スコアを比較することにより、サーバ側で上述したように、プレイヤキャラクタの属性を変化させることができる。また、プレイヤキャラクタの属性を変化させることに代えて、サーバは、各プレイヤの悪評スコアを比較することにより、比較結果をゲーム処理に反映させることもできる。たとえば、格闘ゲームをプレイする場合には、プレイヤ同士の悪評スコアを比較し、悪評スコアの大きさに応じて、攻撃する側のプレイヤキャラクタの攻撃力の大小を変化させたり、防御する側のプレイヤキャラクタの生命力の減算値の大小を変化させたりすることができる。

さらに、第１実施例では、対戦中フラグをオン／オフすることにより、ゲーム装置が次に通信ゲームへの参加を申し込んだ際に、当該ゲーム装置に対応する対戦中フラグがオンである場合に、当該ゲーム装置についての継続拒否回数を１加算するようにしたが、通信ゲームを途中終了した際に、すぐに継続拒否回数を１加算するようにしてもよい。かかる場合には、対戦中フラグを設ける必要がなく、一定時間内に接続中メッセージを受信しなかったゲーム装置についての継続拒否回数を１加算すればよい。つまり、図１２−図１６に示したサーバ１０２のＣＰＵ１０２ａの全体処理において、ステップＳ７３、Ｓ７５、Ｓ９３、Ｓ１０３およびＳ１０５を削除するとともに、ステップＳ１１９で“ＹＥＳ”と判断された後であり、ステップＳ１２７までの間に、一定時間内に接続中メッセージを受信しなかったゲーム装置についての継続拒否回数を１加算する処理を実行するようにすればよい。

さらにまた、第１実施例では、携帯型のゲーム装置について説明したが、家庭用のゲーム装置やアーケードゲーム機のような据置型のゲーム装置を用いることもできる。

また、ゲーム装置は、ケーブルを用いてネットワークに接続されるようにしてもよい。

さらに、ゲーム装置の構成は第１実施例のものに限定される必要はない。たとえば、表示装置（ＬＣＤ）およびカメラは、それぞれ１つでもよい。また、タッチパネルは無くてもよい。
＜第２実施例＞
第２実施例のゲームシステム１００は、第１実施例において、通信ゲームへの参加の申し込み時に、対戦中フラグ１５４ｈの状態（オン／オフ）に応じて継続拒否回数を加算すること、および、通信ゲームの実行中に、各ゲーム装置１０が接続中メッセージをサーバ１０２に送信することに代えて、ゲーム装置１０が他のゲーム装置１０から一定時間内に操作データ（または結果データ）を受信しない場合に、当該他のゲーム装置１０が切断したことの通知をサーバ１０２に送信し、切断したことが通知されたゲーム装置１０についての継続拒否回数をカウントするようにしたものである。以下、第２実施例のゲームシステム１００について説明するが、第１実施例で説明した内容と重複する内容については説明を省略することにする。

図示は省略するが、第２実施例では、対戦中フラグ１５４ｈを使用しないため、対戦中フラグ１５４ｈは、サーバ１０２のＲＡＭ１０２ｂのデータ記憶領域１５４に記憶されない。したがって、対戦中フラグ１５４ｈは、データベース１０６に記憶（バックアップ）されることもない。また、接続中メッセージを受信したことに応じて、全員接続データや切断数データを各ゲーム装置１０に送信する処理が不要であるため、接続確認プログラム１５２ｇはプログラム記憶領域１５２に記憶されることはない。また、第２実施例では、継続拒否回数カウントプログラム１５２ｉは、通信処理プログラム１５２ｂに従ってゲーム装置１０からの切断通知を受信したときに、切断通知に含まれる識別情報に対応するゲーム装置１０（プレイヤ）の継続拒否回数を１加算する。

一方、図示は省略するが、ゲーム装置１０のメインメモリ５０のプログラム記憶領域５２には、接続確認プログラム２０２ｆに代えて、他のゲーム装置１０から一定時間内に操作データ（または結果データ）を受信しない場合に、当該他のゲーム装置１０が通信ゲームを途中終了したことと当該他のゲーム装置１０の識別情報とを含む切断通知をサーバ１０２に送信するためのプログラムが記憶される。

したがって、第２実施例では、第１実施例に示したゲーム装置１０のＣＰＵ５０の全体処理の一部が変更されるとともに、同じく第１実施例に示したサーバ１０２のＣＰＵ１０２ａの全体処理の一部も変更される。以下、異なる処理について具体的に説明する。

第２実施例では、ゲーム装置１０のＣＰＵ５０は、図１８に示すように、一定時間内に操作データを受信しない対戦相手が存在する場合には、つまりステップＳ２１で“ＹＥＳ”であれば、ステップＳ２０１で、操作データを受信していない対戦相手についての切断通知をサーバ１０２に送信する。ここでは、ＣＰＵ５０は、操作データを受信していない対戦相手のゲーム装置１０についての識別情報を含む切断通知をサーバ１０２に送信する。ただし、一定時間内に操作データを受信していない対戦相手のゲーム装置１０が複数存在する場合には、そのような複数のゲーム装置１０の各々についての識別情報を含む切断通知がサーバ１０２に送信される。

このように、切断通知をサーバ１０２に送信するようにしてあるため、各ゲーム装置１０から接続中メッセージをサーバ１０２に送信する必要がない。したがって、第２実施例では、図１８に示すように、第１実施例に示したステップＳ２５−Ｓ３３の処理が省略される。

一方、サーバ１０２のＣＰＵ１０２ａの全体処理では、図１９および図２０に示すように、対戦中フラグ１５４ｈに関するステップＳ７３、Ｓ７５、Ｓ９３、Ｓ１０３およびＳ１０５の処理が削除される。また、ゲーム装置１０からは、接続中メッセージに代えて、必要に応じて切断通知が送信されるため、図２１および図２２に示すように、ステップＳ１１１−Ｓ１２７の処理に代えて、ステップＳ２１１−Ｓ２２３の処理が実行される。

具体的には、ＣＰＵ１０２ａは、ステップＳ２１１で、切断通知を受信したかどうかを判断する。ステップＳ２１１で“ＮＯ”であれば、つまり切断通知を受信していなければ、図２２に示すステップＳ１２９に進む。一方、ステップＳ２１１で“ＹＥＳ”であれば、つまり切断通知を受信すれば、ステップＳ２１３で、切断通知の送り主であるゲーム装置１０の識別情報をＲＡＭ１０２ｂのバッファ領域（図示せず）に一時記憶する。次のステップＳ２１５では、通知されたプレイヤ（切断通知の送り主であるゲーム装置１０が操作データを受信していない対戦相手）が通信ゲームに現在参加中であるかどうかを判断する。ここでは、ＣＰＵ１０２ａは、現在参加プレイヤリストデータ１５４ｄを参照して、切断通知に含まれる識別情報に対応して設定された途中終了フラグがオフであるかどうかを判断するのである。

ステップＳ２１５で“ＮＯ”であれば、つまり通知されたプレイヤが通信ゲームに参加中でなければ、そのままステップＳ２２１に進む。一方、ステップＳ２１５で“ＹＥＳ”であれば、つまり通知されたプレイヤが通信ゲームに参加中であれば、ステップＳ２１７で、切断通知されたプレイヤの継続拒否回数を１加算し、ステップＳ２１９で、現在参加プレイヤリストを更新して、ステップＳ２２１に進む。ただし、ステップＳ２１９では、今回の切断通知に記載された識別情報に対応して設定された途中終了フラグがオンされる。このとき、切断通知に２つ以上の識別情報が記載されている場合には、その数に応じて、ステップＳ２１５−Ｓ２１９の処理が並列的に実行される。

なお、このように、ステップＳ２１５の判断処理を設けるのは、この第２実施例では、一定時間内に操作データを受信しない場合に、各ゲーム装置１０が切断通知を送信するので、通信ゲームを途中終了したゲーム装置１０の継続拒否回数が一度に複数加算されないようにするためである。たとえば、４人で対戦（通信ゲーム）を行っているような状況で、或る１人のプレイヤが通信ゲームを途中終了した場合には、他の３人はサーバへ切断通知を送信することになる。このような場合に、すべての切断通知に応じて継続拒否回数を加算すると、途中終了を行ったプレイヤ（ゲーム装置１０）の継続拒否回数は「３」だけ加算されてしまう。しかし、途中終了は１回しか行われていないため、本来であれば、途中終了を行ったゲーム装置１０の継続拒否回数は「１」だけ加算されるべきである。つまり、ステップＳ２１５は、１回の途中終了に対して、途中終了を行ったゲーム装置１０の継続拒否回数を「１」だけ加算するための処理である。すなわち、切断通知をされたプレイヤの継続拒否回数を加算した後は、当該プレイヤの途中終了フラグがオンになっているので、他のプレイヤから同様の通知を受け取ったとしても、ステップＳ２１５で“ＮＯ”となり、重複して当該通知されたプレイヤの継続拒否回数が重複加算されることはない。

ステップＳ２２１では、図１７に示した悪評スコアの更新処理を実行する。ただし、ステップＳ２２１では、ステップＳ２１３において識別情報を一時記憶した切断通知の送り主であるゲーム装置１０のプレイヤについての悪評スコアが更新される。次のステップＳ２２３では、受信した切断通知を削除し、図２２に示すステップＳ１２９に進む。ただし、ステップＳ２２３では、切断通知の送り主であるゲーム装置１０の識別情報も削除（消去）される。

第２実施例においても、第１実施例と同様に、ゲームプログラムの想定外使用による不正行為や過剰な嫌がらせなどの不快な行為を抑制したり防止したりすることができる。また、接続中データを用いることなく、通信ゲームを行う際に不可欠な操作データ（または結果データ）の受信の有無によって切断の有無を判断することができるため、データの送受信量を少なくすることができ、ネットワークへのトラフィックを抑えることができる。

なお、第２実施例では、第１実施例に示した対戦中フラグを使用しない場合について説明したが、第１実施例と同様に、対戦中フラグを用いて、継続拒否回数をカウントするようにしてもよい。かかる場合には、第１実施例に示したステップＳ７３，Ｓ７５、Ｓ９３、Ｓ１０３およびＳ１０５の処理が実行され、図２１に示したステップＳ２１５およびＳ２１７の処理が削除される。
＜第３実施例＞
第３実施例のゲームシステム１００は、通信ゲームへの参加を希望するゲーム装置１０からの参加の申し込み通知が送信されてから通信ゲームの参加予定者を決定（マッチング）するまでの処理をサーバ１０２で行い、自己の継続拒否回数および自己の悪評スコアを各ゲーム装置１０で管理するようにした以外は、第１実施例と同じである。以下、第３実施例のゲームシステム１００について説明するが、第１実施例および第２実施例と同様の内容については簡単に説明することにする。

図２３は、第３実施例のゲーム装置１０のメインメモリ５２のメモリマップ３００の例を示す。図２３に示すように、メインメモリ５２は、プログラム記憶領域３０２およびデータ記憶領域３０４を含む。プログラム記憶領域３０２には、メイン処理プログラム３０２ａ、通信処理プログラム３０２ｂ、画像生成プログラム３０２ｃ、画像表示プログラム３０２ｄ、接続処理プログラム３０２ｅ、接続確認プログラム３０２ｆ、悪評スコア算出プログラム３０２ｇ、次ゲーム拒否判断プログラム３０２ｈ、接続拒否回数カウントプログラム３０２ｉ、通信強制終了プログラム３０２ｊおよびバックアッププログラム３０２ｋなどが記憶される。

これらのプログラム３０２ａ−３０２ｋのうち、悪評スコア算出プログラム３０２ｇが新たに加えられ、次ゲーム拒否判断通知プログラム２０２ｈに代えて継続拒否回数カウントプログラム３０２ｉが記憶された以外は、第１実施例で説明したゲーム装置１０のメインメモリ５２に記憶されるプログラムと同じであるため、重複した説明は省略する。第３実施例では、ゲーム装置１０のメインメモリ５２には、悪評スコア算出プログラム３０２ｇがさらに記憶されているが、この悪評スコア算出プログラム３０２ｇは、第１実施例では、サーバ１０２のＲＡＭ１０２ｂに記憶されていたものと同じであるため、重複した説明は省略する。また、継続拒否回数カウントプログラム３０２ｉは、通信ゲームへの参加の申し込み通知を送信する際に対戦中フラグ３０４ｉがオンである場合や次回の通信ゲームへの参加を拒否する場合に、自己の継続拒否回数を１加算するためのプログラムである。

図２４は、図２３に示したデータ記憶領域３０４の具体的な内容を示す図解図である。図２４に示すように、データ記憶領域３０４には、操作データバッファ３０４ａおよび送受信データバッファ３０４ｂが設けられる。また、データ記憶領域３０４には、画像データ３０４ｃ、参加予定プレイヤリストデータ３０４ｄ、現在参加プレイヤリストデータ３０４ｅ、悪評スコアデータ３０４ｆ、自己の継続拒否回数データ３０４ｇおよび相手の継続拒否回数データ３０４ｈが記憶される。さらに、データ記憶領域３０４には、対戦中フラグ３０４ｉが設けられる。

第３実施例では、上述したように、自己の継続拒否回数および自己の悪評スコアを各ゲーム装置１０で管理するため、参加者情報データ２０４ｄに代えて、参加予定プレイヤリストデータ３４０ｄおよび現在参加プレイヤリストデータ３０４ｅがデータ記憶領域３０４に記憶される。また、悪評スコアデータ３０４ｆ、自己の継続拒否回数データ３０４ｇ、相手の継続拒否回数データ３０４ｈがさらに記憶される。ここで、相手の継続拒否回数データ３０４ｈは、他の参加者（対戦相手）についての継続拒否回数のデータである。したがって、対戦相手が複数人である場合には、相手の継続拒否回数データ３０４ｈには、それぞれの対戦相手についての継続拒否回数が記載される。
これらは、第１実施例では、サーバ１０２のＲＡＭ１０２ｂのデータ記憶領域１５４に記憶されていたデータである。ただし、第３実施例では、自己の継続拒否回数データ３０４ｇおよび相手の継続拒否回数データ３０４ｈを分けて記載してあるが、これらは第１実施例の継続拒否回数データ１５４ｇに相当する。さらに、第３実施例では、ゲーム装置１０のデータ記憶領域３０４に、対戦中フラグ３０４ｉが設けられるが、これは自己のゲーム装置１０のみについてのフラグである。これらは、第１実施例で説明した内容と同様であるため、重複した説明は省略する。

第３実施例では、各ゲーム装置１０のＣＰＵ５０は、図２５−図２９に示すような全体処理を実行する。なお、図示および詳細な説明は省略するが、第３実施例では、サーバ１０２は、第１実施例に示したステップＳ７１−Ｓ８７の処理を繰り返し実行することになる。また、第１実施例で説明した処理と同じ処理については簡単に説明することにする。

図２５に示すように、ＣＰＵ５０は、全体処理を開始すると、ステップＳ３０１で、対戦中フラグ３０４ｉがオンであるかどうかを判断する。なお、図示は省略するが、ＣＰＵ５０は、全体処理を開始したときに、メモリカード２６、２８または保存用データメモリ５６から、悪評スコアデータ３０４ｆ、自己の継続拒否回数データ３０４ｇおよび対戦中フラグ３０４ｉなどのバックアップデータをデータ記憶領域３０４に読み込んでいる。ステップＳ３０１で“ＮＯ”であれば、つまり対戦中フラグ３０４ｉがオフであれば、そのままステップＳ３０５に進む。一方、ステップＳ３０１で“ＹＥＳ”であれば、つまり対戦中フラグ３０４ｉがオンであれば、ステップＳ３０３で、自己の継続拒否回数を１加算して、ステップＳ３０５に進む。

ステップＳ３０５では、自己の悪評スコアと接続リクエストとをサーバ１０２に送信する。次のステップＳ３０７では、サーバ１０２から通信ゲーム不可通知を受信したかどうかを判断する。ステップＳ３０７で“ＹＥＳ”であれば、つまり通信ゲーム不可通知を受信すれば、図２９に示すように、ステップＳ３６５で、通信を終了して、全体処理を終了する。一方、ステップＳ３０７で“ＮＯ”であれば、つまり通信ゲーム不可通知を受信していなければ、ステップＳ３０９で、サーバ１０２から参加予定者の接続情報を受信したかどうかを判断する。

なお、第３実施例では、悪評スコアを自身のゲーム装置１０で管理するようにしてあるため、サーバ１０２が通信ゲームの実行の許可または不可を判断せずに、ゲーム装置１０自身で判断するようにしてもよい。かかる場合には、ステップＳ３０７の処理を削除して、ステップＳ３０３の処理とステップＳ３０５の処理との間において、悪評スコアが一定値以上であるかどうかが判断される。悪評スコアが一定値以上であれば、そのままステップＳ３６５に進む。一方、悪評スコアが一定値未満あれば、ステップＳ３０５の処理が実行される。

図２５に戻って、ステップＳ３０９で“ＮＯ”であれば、つまり参加予定者の接続情報を受信していなければ、再びステップＳ３０９を繰り返す。一方、ステップＳ３０９で“ＹＥＳ”であれば、つまり参加予定者の接続情報を受信すれば、ステップＳ３１１で、参加予定者と接続する。つまり、参加予定者のゲーム装置１０との間で接続状態が確立される。なお、図示は省略するが、第３実施例では、サーバ１０２から参加予定者の接続情報を受信すると、ゲーム装置１０はサーバ１０２との接続を解除する。

続くステップＳ３１３では、参加者が確定したかどうかを判断する。ここでは、ＣＰＵ５０は、サーバ１０２から受信した接続情報に従ってすべての参加予定者と接続状態を確立するか、参加予定者との接続処理を開始してから一定時間を経過したかどうかを判断する。ステップＳ３１３で“ＮＯ”であれば、つまり参加者が確定していなければ、そのままステップＳ３１１に戻る。一方、ステップＳ３１３で“ＹＥＳ”であれば、つまり参加者が確定すれば、図２６に示すステップＳ３１５で、現在参加プレイヤリストデータ３０４ｅを作成および記憶し、ステップＳ３１７で、自己の継続拒否回数データ３０４ｇを対戦相手に送信する。

なお、現在参加プレイヤリストデータ３０４ｅが示す現在参加プレイヤリストは、図６に示した第１実施例の現在参加プレイヤリストと同じで良いが、第３実施例では、自己のゲーム装置１０についての内容（識別情報および途中終了フラグ）は現在参加プレイヤリストに記載（登録）しなくてもよい。このことは、参加予定プレイヤリスト（図示せず）についても同様である。

続くステップＳ３１９では、相手の継続拒否回数データ３０４ｈを受信する。次のステップＳ３２１では、対戦中フラグ３０４ｉをオンし、ステップＳ３２３で、バックアップ処理を実行する。ここでは、データ記憶領域３０４に記憶されているデータやフラグのうち、上述したバックアップデータがメモリカード２６、２８や保存用データメモリ５６に記憶される。

なお、簡単のため、第３実施例では、ステップＳ３１９において、対戦相手（他の参加者）の継続拒否回数データ３０４ｈをすべて受信できることを前提としてあるが、対戦相手の継続拒否回数データ３０４ｈをすべて受信できたか否かを判断するようにしてもよい。また、かかる場合には、一定時間を経過しても受信できない場合には、継続拒否回数データ３０４ｈを受信しない対戦相手を現在参加プレイヤリストから削除（消去）し、当該対戦相手を参加者として含めないようにしてもよい。

図２７に示すように、次のステップＳ３２５では、対戦が終わったかどうかを判断する。ステップＳ３２５で“ＮＯ”であれば、つまり対戦が終わっていなければ、ステップＳ３２７で、自己の操作データを対戦相手のゲーム装置１０に送信する。そして、ステップＳ３２９で、すべての対戦相手から操作データを受信したかどうかを判断する。ステップＳ３２９で“ＹＥＳ”であれば、つまりすべての対戦相手から操作データを受信した場合には、そのままステップＳ３３９に進む。一方、ステップＳ３２９で“ＮＯ”であれば、つまり操作データを受信していない対戦相手が存在する場合には、ステップＳ３３１で、一定時間を経過したかどうかを判断する。

なお、ステップＳ３３１では、ＣＰＵ５０は、ＲＴＣ６８によって計時される時間を参照して、ステップＳ３２７の処理を実行してから一定時間（たとえば、１０秒）を経過したかどうかを判断する。

また、第３実施例では、ゲーム装置１０間で操作データを送受信するようにしてあるが、プレイヤの操作によって各ゲーム装置１０のＣＰＵ５０がゲーム処理を行い、その結果データを送受信するようにしてもよい。

ステップＳ３３１で“ＮＯ”であれば、つまり一定時間を経過していなければ、そのままステップＳ３２９に戻る。一方、ステップＳ３３１で“ＹＥＳ”であれば、つまり一定時間を経過すれば、ステップＳ３３３で、図１７に示したフロー図に従って自己の悪評スコアの更新処理を実行する。

次のステップＳ３３５では、現在参加プレイヤリストを更新する。つまり、ＣＰＵ５０は、現在参加プレイヤリストデータ３０４ｅが示す現在参加プレイヤリストにおいて、一定時間内に操作データを受信しなかった対戦相手（プレイヤ）の識別情報に対応して設定されている途中終了フラグをオンする。

続いて、ステップＳ３３７では、全対戦相手の操作データを受信していないかどうかを判断する。ここでは、ＣＰＵ５０は、現在参加プレイヤリストを参照し、すべての対戦相手の識別情報に対して設定されている途中終了フラグがオンであるかどうかを判断する。つまり、通信ゲームの参加者が自己のゲーム装置１０のみであるかどうかを判断するのである。ステップＳ３３７で“ＹＥＳ”であれば、つまり全対戦相手の操作データを受信していない場合には、通信ゲームを終了するべく、図２９に示すステップＳ３６５に進む。一方、ステップＳ３３７で“ＮＯ”であれば、つまり少なくとも１人の対戦相手の操作データを受信している場合には、ステップＳ３３９で、自己および対戦相手の操作データを通信ゲームに反映させて、ステップＳ３２５に戻る。

また、ステップＳ３２５で“ＹＥＳ”であれば、つまり対戦が終われば、ステップＳ３４１で、対戦中フラグ３０４ｉをオフする。つまり、通信ゲームを正常終了したことが記録される。次のステップＳ３４３では、バックアップ処理を実行する。このバックアップ処理は、上述したステップＳ３２３のバックアップ処理と同じである。次にステップＳ３４５で、続けて対戦するかどうかをプレイヤに問い合わせる。ここでは、第１実施例で説明したように、選択画面がゲーム装置１０の第１ＬＣＤ１６または第２ＬＣＤ１８或いはそれらの両方に表示される。

図２８に示すように、次のステップＳ３４７では、続けて対戦するかどうかを判断する。ステップＳ３４７で“ＮＯ”であれば、つまり続けて対戦しない場合には、ステップＳ３６１で、自己の継続拒否回数を１加算して、ステップＳ３６５に進む。一方、ステップＳ３４７で“ＹＥＳ”であれば、つまり続けて対戦する場合には、ステップＳ３４９で、継続許可通知を対戦相手に送信する。ただし、ここでは、直前の通信ゲームを正常終了した対戦相手のゲーム装置１０のみに、継続許可通知が送信される。

次のステップＳ３５１では、直前の通信ゲームを正常終了した対戦相手からの継続許可通知を受信したかどうかを判断する。ステップＳ３５１で“ＮＯ”であれば、つまり継続許可通知を受信していない場合には、そのままステップＳ３５７に進む。一方、ステップＳ３５１で“ＹＥＳ”であれば、つまり継続許可通知を受信した場合には、ステップＳ３５３で、参加予定者リストを更新する。ここでは、継続許可通知の送り主であるゲーム装置１０の識別情報が参加予定者リストに追加される。

そして、次のステップＳ３５５では、直前の通信ゲームを正常終了した対戦相手の全員から継続許可通知を受信したかどうかを判断する。具体的には、ＣＰＵ５０は、現在参加プレイヤリストにおいて、途中終了フラグがオフであるすべてのゲーム装置１０の識別情報が、参加予定者リストに記載されているかどうかを判断する。ステップＳ３５５で“ＹＥＳ”であれば、つまり直前の通信ゲームを正常終了した対戦相手の全員から継続許可通知を受信した場合には、そのまま図２９に示すステップＳ３６３に進む。一方、ステップＳ３５５で“ＮＯ”であれば、つまり直前の通信ゲームを正常終了した対戦相手のうち継続許可通知を受信していない対戦相手が存在する場合には、ステップＳ３５７に進む。

ステップＳ３５７では、一定時間を経過したかどうかを判断する。ここでは、ＣＰＵ５０は、ＲＴＣ６８によって計時される時間を参照して、ステップＳ３４９の処理を実行してから一定時間（たとえば、６０秒）を経過したかどうかを判断する。ステップＳ３５７で“ＮＯ”であれば、つまり一定時間を経過していなければ、そのままステップＳ３５１に戻る。一方、ステップＳ３５７で“ＹＥＳ”であれば、つまり一定時間を経過すれば、ステップＳ３５９で、図１７に示したフロー図に従って自己の悪評スコアの更新処理を実行して、ステップＳ３６３に進む。

図２９に示すように、ステップＳ３６３では、次回の参加予定者が２人以上であるかどうかを判断する。ステップＳ３６３で“ＹＥＳ”であれば、つまり次回の参加予定者が２人以上であれば、図２５に示したステップＳ３１１に戻る。一方、ステップＳ３６３で“ＮＯ”であれば、つまり次回の参加予定者が１人（自身のみ）であれば、ステップＳ３６５で、通信を終了してから、全体処理を終了する。

第３実施例によれば、第１実施例と同様に、ゲームプログラムの想定外使用による不正行為や過剰な嫌がらせなどの不快な行為を抑制したり防止したりすることができる。

また、第３実施例によれば、通信ゲームへの参加者を決定した後では、ゲーム装置間で処理を実行するので、つまり、サーバは通信ゲーム中に各ゲーム装置の状態を管理したり、ゲーム処理を実行したりする必要がないので、サーバへの負担を軽減することができる。

なお、第３実施例では、通信ゲームの対戦相手をサーバがマッチング（決定）するようにしたが、他の実施例としては、サーバを用いずに、ゲーム装置間で対戦相手を決定するようにしてもよい。かかる場合には、たとえば、通信ゲームの対戦相手を募集したゲーム装置が親機として機能し、そのような親機に通信ゲームの参加を申し込んだゲーム装置が子機として機能し、対戦相手が決定された後に、通信ゲームが実行される。したがって、サーバを用いる必要がない。

また、第３実施例では、直前の通信ゲームを正常終了したゲーム装置のうち、次回の通信ゲームに不参加のゲーム装置が存在する場合には、その数に拘わらず、自己の悪評スコアを更新するようにしたが、第１実施例および第２実施例と同様に、一定数以上の不参加者が存在する場合にのみ、自己の悪評スコアを更新するようにしてもよい。

さらに、第３実施例では、同じ対戦相手と再度通信ゲームをプレイすることが選択されず、通信ゲームを止めることや他のプレイヤと対戦することが選択された場合には、つまり次回の通信ゲームの参加を拒否する場合には、自己の継続拒否回数を１加算して、通信を終了するようにした。ただし、次回の通信ゲームへの参加を拒否する場合には、自己の継続拒否回数を１加算する前後において、継続拒否通知を他の参加者のゲーム装置１０に送信するようにしてもよい。かかる場合には、正常終了した相手から継続拒否通知を受信した場合には、参加予定者リストには当該相手を追加しないようにすればよいと考えられる。具体的には、継続拒否通知を相手に送信する処理をステップＳ３４７で“ＮＯ”と判断された後に追加し、さらに、継続拒否通知を受信したかどうかを判断する処理をステップＳ３５１で“ＮＯ”と判断された後に追加し、継続拒否通知を受信した場合には、参加予定者リストに追加しない処理を実行して、ステップＳ３５５に進む。したがって、ステップＳ３５５では、ＣＰＵ５０は、全員から継続許可通知または継続拒否通知を受け取ったかどうかを判断する。ただし、継続拒否通知を受信していないと判断された場合には、ステップＳ３５７に進むようにすればよい。

さらにまた、上述の第１実施例および第２実施例では、サーバが悪評スコアを管理するようにしたが、第３実施例では、各ゲーム装置１０が悪評スコアを管理するので、各ゲーム装置は、ゲーム開始時に、悪評スコアに従ってプレイヤキャラクタの属性を変化させるようにしてもよい。かかる場合には、たとえば、ＣＰＵ５０は、ステップＳ３２３とステップＳ３２５との間において、悪評スコアに従うプレイヤキャラクタの属性を変化させる処理を実行すればよい。

なお、上述の実施例では、ゲーム装置（プレイヤ）の悪評スコアが一定値以上である場合に、当該プレイヤの通信ゲームへの参加を拒否するようにしてあるが、一度でも通信ゲームを途中終了されたり、次回の通信ゲームへの参加を断られたりした場合に、当該ゲーム装置の通信ゲームへの参加を拒否するようにしてもよい。

また、上述の実施例では、悪評スコアを更新する場合には、加算スコア値を求めて、それを加算するようにしたが、単に通信ゲームの継続を拒否された回数をカウントするようにしてもよい。かかる場合には、ゲーム装置（プレイヤ）の悪評スコアが一定値以上である場合に、つまり通信ゲームの継続を拒否された回数が一定回数以上である場合に、当該ゲーム装置の通信ゲームへの参加を拒否するようにしてもよい。

さらに、上述の実施例では、通信ゲームを途中終了された場合と、次回の通信ゲームへの参加を断られた場合との両方において、悪評スコアを更新するようにしたが、いずれか一方の場合にのみ、悪評スコアを更新するようにしてもよい。

さらにまた、上述の実施例では、通信ゲームを途中終了された場合と、次回の通信ゲームへの参加を断られた場合とで、同じ悪評スコアの更新処理を実行するようにしたが、場合に応じて、加算スコア値を変化させたり、加算スコア値の補正方法を変化させたりしてもよい。たとえば、通信ゲームを途中終了された場合には、通信環境の悪化により、通信が途絶えることもあるため、次回の通信ゲームへの参加を断られる場合よりも、加算スコア値を小さい値に設定してもよい。また、通信ゲームを途中終了することは、次回の通信ゲームへの参加を断る場合に比べて、悪質であると考える場合には、通信ゲームを途中終了する場合の加算スコア値を大きい値に設定してもよい。いずれを選択するのかは、開発者等が任意に設定する事項である。

また、上述の実施例では、サーバで通信ゲームの対戦相手となる参加予定者をマッチングする際に、悪評スコアが同じまたは同程度のプレイヤ（ゲーム装置）を決定するようにしたが、プレイヤ自身が対戦相手となる参加予定者を決定するようにしてもよい。かかる場合には、各プレイヤの悪評スコアを表示するようにすれば、悪評スコアを対戦相手となる参加予定者を決定する際の指標にすることができる。

さらに、上述の実施例では、悪評スコアが一定値以上であるプレイヤ（ゲーム装置）については、通信ゲームへの参加を拒否し、悪評スコアが一定値未満であるプレイヤについては、その値が同じまたは同程度のプレイヤ同士を通信ゲームへの参加予定者として決定するようにしてあるが、いずれかの方法のみを採用するようにしてもよい。また、悪評スコアが一定値未満である場合には、特に制限無く、参加の申し込み通知のあったプレイヤ同士を参加予定者として決定し、一定値以上である場合には、悪評スコアの値が同じまたは同程度のプレイヤ同士で通信ゲームを行うようにしてもよい。

さらにまた、上述の実施例では、直前の通信ゲームを正常終了した参加者と、次回の通信ゲームへの参加予定者との差分を求め、その差分に基づいて悪評スコアを更新するようにしてあるが、単に次回の通信ゲームへの参加を拒否した者に基づいて悪評スコアを更新するようにしてもよい。

また、上述の実施例では、悪評スコアの初期値（最低値）を「０」として、悪評スコアが更新されるたびに、悪評スコアを加算するようにしたが、これに限定される必要はない。たとえば、悪評スコアの初期値（最高値）を設定しておき、悪評スコアが更新される度に、悪評スコアを減算するようにしてもよい。かかる場合には、悪評スコアが一定値以下になると、通信ゲームへの参加が拒否される。

さらに、上述の実施例では、悪評スコアの加算のみを行うようにしたが、通信ゲームを正常終了したゲーム装置（プレイヤ）については、悪評スコアを減算するようにしてもよい。かかる場合には、通信ゲームを途中終了されかった場合に、悪評スコアが更新され、その値が減算される。

さらにまた、上述の実施例では、次回の通信ゲームへの参加を拒否されたゲーム装置（プレイヤ）の全員について悪評スコアを更新するようにしたが、これに限定されるべきではない。たとえば、直前に通信ゲームを行った対戦相手のうち、一部の対戦相手についてのみ、悪評スコアを更新するようにしてもよい。かかる場合には、次回の通信ゲームを行うか否かの選択画面に、どのプレイヤ（ゲーム装置）とプレイしたくないかを選択する項目をさらに設けるようして、その選択結果もサーバに送信するようにすればよい。また、ゲームプログラムの想定外使用による不正行為や過剰な嫌がらせなどの不快な行為を受けておらず、単に通信ゲームを止める場合もある。したがって、次回の通信ゲームに参加するか否かの選択画面において、そのような不正行為や不快な行為があったために通信ゲームを止めることを選択するボタン画像（第１ボタン画像）と、単に通信ゲームを止めることを選択するボタン画像（第２ボタン画像）とを設けておき、第１ボタン画像がオンされた場合にのみ、悪評スコアを更新するようにしてもよい。これは、上述した一部の対戦相手についてのみ悪評スコアを更新することと共に採用されてもよい。

また、上述の実施例では、ステップＳ８９においてサーバは、直前のステップＳ８７で参加予定者の接続情報を参加者のゲーム装置に送信してからの時間をカウントし、カウント値によって参加者の確定を判断しているが、ゲーム装置側で、ステップＳ５で接続情報を受信してからの時間を計測し、一定時間内に開始通知をサーバに送信することができなかった場合にその旨をサーバに通知し、サーバがその旨の通知を受信することによって、当該ゲーム装置は参加者とならないと判断することもできる。

１０ …ゲーム装置
１２，１４ …ハウジング
１６，１８ …ＬＣＤ
２０ …操作ボタン
２２ …タッチパネル
２４ …タッチペン
２６，２８ …メモリカード
３２，３４ …カメラ
５０ …ＣＰＵ
５２ …メインメモリ
５４ …メモリ制御回路
５６ …保存用データメモリ
５８ …プリセットデータ用メモリ
６０，６２ …メモリカードＩ／Ｆ
６４ …無線通信モジュール
６６ …ローカル通信モジュール
６８ …ＲＴＣ
７０ …電源回路
７２ …Ｉ／Ｆ回路
７４，７６ …ＧＰＵ
７８，８０ …ＶＲＡＭ
８２ …ＬＣＤコントローラ
８４ …マイク

Claims (16)

1. 通信ゲームを行うゲームシステムであって、
   １のゲーム装置が他のゲーム装置によって前記通信ゲームの継続を拒否されたか否かを判断する拒否判断手段、および
   前記拒否判断手段の判断結果に応じて、前記１のゲーム装置の前記通信ゲームについての制限情報を更新させる制限情報更新手段を備える、ゲームシステム。
2. 各前記ゲーム装置の前記制限情報に基づいて前記通信ゲームの対象となるゲーム装置を選択する通信対象選択手段をさらに備える、請求項１記載のゲームシステム。
3. 前記通信対象選択手段は、前記制限情報が少なくとも近似する複数の前記ゲーム装置を前記通信ゲームの対象として選択する、請求項２記載のゲームシステム。
4. 少なくとも前記通信ゲームを実行する通信ゲーム処理手段をさらに備え、
   前記通信ゲーム処理手段は、前記通信ゲームに参加中の各前記ゲーム装置の前記制限情報を、当該通信ゲームの処理に反映させる、請求項１ないし３のいずれかに記載のゲームシステム。
5. 前記通信ゲームに参加する各前記ゲーム装置の前記制限情報を比較する比較手段をさらに備え、
   前記通信ゲーム処理手段は、さらに、前記比較手段の比較結果を、前記通信ゲームの処理に反映させる、請求項４記載のゲームシステム。
6. 前記通信ゲーム処理手段は、前記制限情報が所定の条件を満たすとき、前記通信ゲームに対して影響を及ぼす、請求項４記載のゲームシステム。
7. 前記通信ゲーム処理手段は、前記制限情報に基づく値が所定以上であるとき、前記通信ゲームへの参加自体を拒否する、請求項６記載のゲームシステム。
8. 前記通信ゲームの継続を拒否されたことは当該通信ゲーム中に切断されたことを含む、請求項１ないし７のいずれかに記載のゲームシステム。
9. 前記拒否判断手段は、前記他のゲーム装置からの通信データを前記１のゲーム装置で一定時間受信しなかったとき、当該１のゲーム装置が当該他のゲーム装置によって前記通信ゲームの継続を拒否されたことを判断する、請求項８記載のゲームシステム。
10. 前記通信ゲームの継続を拒否されたことは次回の前記通信ゲームへの参加を拒否されたことを含む、請求項１ないし９のいずれかに記載のゲームシステム。
11. 前記他のゲーム装置が前記通信ゲームの継続を拒否した回数を示す拒否情報を更新する拒否情報更新手段をさらに備え、
    前記制限情報更新手段は、さらに、前記拒否情報更新手段によって更新された拒否情報に基づいて、前記１のゲーム装置の前記通信ゲームについての前記制限情報を更新させる、請求項１ないし１０のいずれかに記載のゲームシステム。
12. 前記制限情報更新手段は、前記拒否情報更新手段によって更新された拒否情報が示す回数が大きい程、前記制限情報を変更する度合いを小さくする、請求項１１記載のゲームシステム。
13. 前記通信ゲームの継続を拒否した前記他のゲーム装置の数を検出する拒否数検出手段をさらに備え、
    前記制限情報更新手段は、さらに、前記拒否数検出手段の検出結果に基づいて、前記１のゲーム装置の前記通信ゲームについての前記制限情報を更新させる、請求項１ないし１２のいずれかに記載のゲームシステム。
14. 前記通信ゲームの開始時に当該通信ゲームに参加する前記ゲーム装置を参加者として登録する参加者登録手段、および
    前記通信ゲームの終了時に前記参加者から再度前記通信ゲームへ参加するか否かの指示を受け付ける再度参加受付手段をさらに備え、
    前記拒否判断手段は、前記再度参加受付手段によって受け付けられた指示に基づいて、前記通信ゲームの継続が拒否された前記ゲーム装置が存在するか否かを判断する、請求項１記載のゲームシステム。
15. 前回の前記通信ゲームの参加者数と次回の前記通信ゲームの参加者数との差分を取得する差分取得手段、および
    前記差分取得手段によって取得された差分が所定の条件を満たしているか否かを判断する差分判断手段をさらに備え、
    前記拒否判断手段は、前記差分判断手段によって前記差分が前記所定の条件を満たしていないことが判断されたとき、前記通信ゲームの継続が拒否された前記ゲーム装置を判断する、請求項１４記載のゲームシステム。
16. 通信ゲームを行うゲームシステムのゲームプログラムであって、
    コンピュータを、
    １のゲーム装置が他のゲーム装置によって前記通信ゲームの継続を拒否されたか否かを判断する拒否判断手段、および
    前記拒否判断手段の判断結果に応じて、前記１のゲーム装置の前記通信ゲームについての制限情報を更新させる制限情報更新手段として機能させる、ゲームプログラム。

Images