JP2014236785A - 情報処理装置、情報処理システム、情報処理プログラムおよび情報処理方法 - Google Patents

Abstract

【構成】 ゲーム装置１０は第１ＬＣＤ４４および第２ＬＣＤ４６を含み、通常、第１ＬＣＤにはシングルプレイのゲームのゲーム画面（１００）が表示され、第２ＬＣＤにはリスト画面（１５０）が表示される。リスト画面には、少なくとも、通信可能な他のゲーム装置のプレイヤのアイコンが表示される。また、通信可能か否かに拘わらず、友達としてゲーム装置に登録されたプレイヤおよび知り合いと判断されたプレイヤのアイコンも表示される。たとえば、通信したことのない通りすがりのプレイヤとの間で、ゲーム装置を用いて通信することにより、当該プレイヤが自動的に知り合いのプレイヤとして判断される。【効果】 友達として登録しなくても、過去に通信したプレイヤと容易に通信することができる。【選択図】 図１

Description

この発明は情報処理装置、情報処理システム、情報処理プログラムおよび情報処理方法に関し、特にたとえば、他の情報処理装置との間で通信アプリケーションを実行可能な、情報処理装置、情報処理システム、情報処理プログラムおよび情報処理方法に関する。

この種の情報処理装置の一例が特許文献１に開示されている。この特許文献１のゲーム装置は、アクセスポイントを介してサーバおよび他のゲーム装置と通信可能であり、特定の他の情報処理装置を通信の相手として登録する。

特開２０１２−１７８０６２［G06F 15/00, A63F 13/12, G06F 13/00］

しかし、特許文献１に開示されたゲーム装置では、特定の情報処理装置を通信の相手として登録するか登録しないかを選択できるに留まっていた。つまり、通信する場合には、特定の情報処理装置を登録する必要があり、面倒であった。

それゆえに、この発明の主たる目的は、新規な、情報処理装置、情報処理システム、情報処理プログラムおよび情報処理方法を提供することである。

また、この発明の他の目的は、コミュニケーションを多様化することができる、情報処理装置、情報処理システム、情報処理プログラムおよび情報処理方法を提供することである。

第１の発明は、通信部と、表示部と、第１分類登録部を備える情報処理装置である。通信部は、他の情報処理装置と通信する。表示部は、他の情報処理装置の情報を表示する。第１分類判断部は、通信部によって他の情報処理装置と通信したことに応じて、当該他の情報処理装置を自動的に第１分類として判断する。表示部は、第１分類判断部によって第１分類として判断された他の情報処理装置の情報を当該他の情報処理装置の通信状況に応じた態様で表示する。

第１の発明によれば、他の情報処理装置と通信したことに応じて当該他の情報処理装置を自動的に第１分類として判断し、第１分類として判断された他の情報処理装置の情報を通信状況に応じた態様で表示するので、その後に当該他の情報処理装置と通信する場合に、その通信状況を把握して通信を申し込むことができる。また、過去に通信した情報処理装置と再び通信したい場合に、第１分類の情報処理装置を探せば良いため、通信の利便性を向上させることができる。つまり、面倒な操作を省いて、コミュニケーションを多様化することができる。

第２の発明は、第１の発明に従属し、情報処理装置は、第２分類登録部をさらに備える。第２分類登録部は、他の情報処理装置との間で相互認証することにより、当該他の情報処理装置を第１分類とは異なる第２分類として登録する。

第２の発明によれば、他の情報処理装置との間で相互認証することにより、当該他の情報処理装置を第１分類とは異なる第２分類に登録することができる。

第３の発明は、第２の発明に従属し、第２分類登録部は、第１分類判断部によって第１分類と判断された他の情報処理装置との間で相互認証することにより、当該他の情報処理装置を第２分類として登録する。

第３の発明によれば、第１分類と判断された後に、相互認証することにより、他の情報処理装置を第２分類として登録するので、少なくとも一度通信したことにより親密度や信頼度を高くしてから、第２分類として登録することができる。したがって、情報処理装置のユーザ同士が近くに居なくても通信さえできれば、互いの情報処理装置を第２分類として登録することができる。

第４の発明は、第２または第３の発明に従属し、第１分類の他の情報処理装置と第２分類の他の情報処理装置とでは、通信部を用いて通信する場合に実行可能な機能の少なくとも一部が異なる。

第４の発明によれば、分類によって他の情報処理装置と通信する場合に実行可能な機能の一部が異なるので、たとえば、異なる機能を使用するか否かに応じて、第２分類として登録するかどうかを決定することもできる。

第５の発明は、第２ないし第４の発明のいずれかに従属し、表示部は、第１分類と第２分類とを識別可能な態様で他の情報処理装置の情報を表示する。たとえば、表示領域を分けたり、表示態様を変えたりすることにより、第１分類と第２分類とを識別可能に他の情報処理装置の情報が表示される。

第５の発明によれば、第１分類と第２分類とを容易に知ることができる。

第６の発明は、第２ないし第５の発明のいずれかに従属し、通信部が他の情報処理装置からの通信リクエストを受信したとき、当該他の情報処理装置の情報を、当該他の情報処理装置が少なくとも第１分類または第２分類であるか否かを識別可能な態様で通知するリクエスト通知部をさらに備える。たとえば、第１分類または第２分類或いはそれら以外の分類の別がテキスト情報で示される。

第６の発明によれば、通信リクエストの送信元である他の情報処理装置の分類を容易に知ることができる。

第７の発明は、第１ないし第６の発明のいずれかに従属し、通信部は、自機のユーザと他の情報処理装置のユーザとの間の合意に基づいて通信する。

第７の発明は、ユーザ同士の合意に基づいて通信したことに応じて、他のユーザが所持または使用する情報処理装置を第１分類をとして判断することができる。

第８の発明は、第１ないし第７の発明に従属し、他の情報処理装置は、通信部を用いて探索した不特定の他の情報処理装置である。

第８の発明によれば、不特定の他の情報処理装置を探索するので、たとえば、知らないユーザが所持ないし使用する情報処理装置との間で通信を行うことにより、第１分類の情報処理装置として判断することができる。したがって、その後同じユーザと再度通信したい場合に、第１分類の他の情報処理装置を検索することにより、容易に通信することができる。

第９の発明は、第８の発明に従属し、通信部は、近距離無線通信により不特定の他の情報処理装置を探索する。

第９の発明によれば、近くに居るユーザが所持する他の情報処理装置と通信することにより、第１分類として判断することができる。

第１０の発明は、第８の発明に従属し、通信部は、インターネット通信により不特定の他の情報処理装置を探索する。

第１０の発明によれば、近くに居ないユーザであっても、このユーザが所持する他の情報処理装置と通信することにより、第１分類として判断することができる。

第１１の発明は、第７ないし第１０の発明のいずれかに従属し、通信部は、不特定の他の情報処理装置を繰り返し探索する。更新部は、通信部の探索結果に応じて他の情報処理装置の通信状況を更新する。

第１１の発明によれば、通信部の探索結果に応じて他の情報処理装置の通信状況が更新されるので、これに基づいて第１分類や第２分類の他の情報処理装置の情報の表示態様を変化させることができる。したがって、最新の通信状況を知ることができる。

第１２の発明は、他の情報処理装置と通信する通信部と、他の情報処理装置の情報を表示する表示部と、通信部によって他の情報処理装置と通信したことに応じて、当該他の情報処理装置を自動的に第１分類として判断する第１分類判断部を備え、表示部は、第１分類判断部によって第１分類として判断された他の情報処理装置の情報を当該他の情報処理装置の通信状況に応じた態様で表示する、情報処理システムである。

第１３の発明は、他の情報処理装置と通信する通信手段を備えるコンピュータによって実行される情報処理プログラムであって、コンピュータを、他の情報処理装置の情報を表示手段に表示する表示制御部と、通信手段によって他の情報処理装置と通信したことに応じて、当該他の情報処理装置を自動的に第１分類として判断する第１分類判断部として機能させ、表示制御部は、第１分類判断部において第１分類として判断した他の情報処理装置の情報を当該他の情報処理装置の通信状況に応じた態様で表示手段に表示する、情報処理プログラムである。

第１４の発明は、他の情報処理装置と通信する通信手段を備えるコンピュータの情報処理方法であって、コンピュータは、（ａ）通信手段によって他の情報処理装置と通信したことに応じて、当該他の情報処理装置を自動的に第１分類として判断し、そして（ｂ）ステップ（ａ）において第１分類として判断した他の情報処理装置の情報を当該他の情報処理装置の通信状況に応じた態様で表示手段に表示する、情報処理方法である。

第１２−第１４の発明においても、第１の発明と同様に、コミュニケーションを多様化することができる。

この発明によれば、他の情報処理装置と通信したことに応じて当該他の情報処理装置の情報を第１分類に自動的に判断し、その情報を通信状況に応じた態様で表示するので、その後に当該他の情報処理装置と通信する場合に、その通信状況を把握して通信を申し込むことができる。また、過去に通信した情報処理装置と再び通信したい場合に、第１分類の情報処理装置を探せば良いため、通信の利便性を向上させることができる。つまり、面倒な操作を省いて、コミュニケーションを多様化することができる。

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

図１はこの実施例の通信ゲームシステムの限定しない一例を示す図解図である。 図２はこの実施例の通信ゲームシステムの限定しない他の例を示す図解図である。 図３は図１および図２に示すゲーム装置の電気的な構成の限定しない一例を示すブロック図である。 図４は図３に示す第１ＬＣＤに表示されるシングルプレイのゲーム画面の限定しない一例および第２ＬＣＤに表示されるリスト画面の限定しない一例を示す図解図である。 図５は図３に示す第２ＬＣＤに表示される要求画面の限定しない一例を示す図解図である。 図６は図３に示す第２ＬＣＤに表示される被要求画面の限定しない一例を示す図解図である。 図７は図３に示す第２ＬＣＤに表示される友達登録画面の限定しない一例を示す図解図である。 図８は図３に示すメインメモリのメモリマップの限定しない一例を示す図解図である。 図９はプレイヤデータの具体的な内容の限定しない一例を示す図解図である。 図１０はシングルプレイ処理用データの具体的な内容の限定しない一例を示す図解図である。 図１１は対戦プレイ処理用データの具体的な内容の限定しない一例を示す図解図である。 図１２は図３に示すＣＰＵのゲーム全体処理の限定しない一例を示すフロー図である。 図１３は図３に示すＣＰＵの対戦プレイ処理の限定しない一例の一部を示すフロー図である。 図１４は図３に示すＣＰＵの対戦プレイ処理の限定しない一例の他の一部であって、図１３に後続するフロー図である。 図１５は図３に示すＣＰＵの対戦プレイ処理の限定しない一例のその他の一部であって、図１４に後続するフロー図である。 図１６は図３に示すＣＰＵのビーコン送受信処理の限定しない一例の一部を示すフロー図である。 図１７は図３に示すＣＰＵのビーコン送受信処理の限定しない一例の他の一部であって、図１６に後続するフロー図である。

図１を参照して、この発明の一実施例である通信ゲームシステム１は、情報処理装置の一例であるゲーム装置１０を含む。図１からも分かるように、通信ゲームシステム１は、複数のゲーム装置１０によって構成される。たとえば、ゲーム装置１０は近距離無線通信により他のゲーム装置１０と通信可能である。

図１に示す複数のゲーム装置１０はそれぞれ異なるユーザないしプレイヤ（以下、単に「プレイヤ」という。）によって所持される。つまり、ゲーム装置１０は、携帯型（可搬型）のゲーム装置である。図１に示す通信ゲームシステム１では、それぞれ、３台のゲーム装置１０を示すが、２台以上であれば、４台以上であってもよい。これらのことは、図２に示す通信ゲームシステム３においても同じである。

図２に示すように、他の例の通信ゲームシステム３は、サーバ５を含み、このサーバ５に、インターネット７のようなネットワークを介して複数のゲーム装置１０が通信可能に接続される。つまり、ゲーム装置１０は、無線でデータ通信することにより、無線ＬＡＮに接続可能であり、アクセスポイント（図示せず）およびインターネット７を介してサーバ５や他のゲーム装置１０と通信可能である。

図３は、図１および図２に示したゲーム装置１０の電気的な構成の一例を示すブロック図である。図３に示すように、ゲーム装置１０は、ＣＰＵ２０を含み、このＣＰＵ２０には、メインメモリ２２、メモリ制御回路２４、インターネット通信モジュール２８、ローカル通信モジュール３０、入力装置３２、第１ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３４、ＬＣＤコントローラ３８、および第２ＧＰＵ４２が接続される。また、メモリ制御回路２４には、保存用データメモリ２６が接続される。さらに、第１ＧＰＵ３４とＬＣＤコントローラ３８との間には、第１ＶＲＡＭ（Ｖｉｄｅｏ ＲＡＭ）３６が接続され、第２ＧＰＵ４２とＬＣＤコントローラ３８との間には、第２ＶＲＡＭ４０が接続される。さらにまた、ＬＣＤコントローラ３８には、第１ＬＣＤ４４および第２ＬＣＤ４６が接続される。

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

なお、ＣＰＵ２０によって実行されるプログラムは、予めメモリに記憶されていてもよいし、ゲーム装置１０に装着可能なメモリカードから取得してもよいし、他の機器と通信することによって当該他の機器から取得（ダウンロード）してもよい。また、所定のプログラムを記憶する情報記憶媒体としては、保存用データメモリ２６のような不揮発性の記憶媒体に限らず、ＣＤ−ＲＯＭ、ＤＶＤ、あるいはそれらに類する光学式ディスク状記憶媒体でもよい。

メインメモリ２２は、ＣＰＵ２０のワーク領域やバッファ領域として用いられる記憶手段である。すなわち、メインメモリ２２は、上記情報処理に用いられる各種データを記憶（一時記憶）したり、外部（メモリカードまたは他の機器等）から取得されるプログラムを記憶したりする。この実施例では、メインメモリ２２として、たとえばＰＳＲＡＭ（Ｐｓｅｕｄｏ−ＳＲＡＭ）を用いる。

保存用データメモリ２６は、ＣＰＵ２０によって実行されるプログラムやゲームデータのようなデータ等を記憶（保存）するための記憶手段である。この保存用データメモリ２６は、不揮発性の記憶媒体によって構成されており、たとえば、ＮＡＮＤ型フラッシュメモリを用いることができる。メモリ制御回路２４は、ＣＰＵ２０の指示に従って、保存用データメモリ２６に対するデータの読み出しおよび書き込みを制御する。

インターネット通信モジュール２８は、たとえばＩＥＥＥ８０２．１１．ｂ／ｇの規格に準拠した方式により、無線ＬＡＮに接続する機能を有する。したがって、上述したように、ＣＰＵ２０は、インターネット通信モジュール２８を用いて、アクセスポイントおよびインターネット７を介して他の機器（コンピュータや他のゲーム装置など）との間でデータを送受信する。

ローカル通信モジュール３０は、近距離無線通信を行う機能を有する。具体的には、ローカル通信モジュール３０は、所定の通信方式（たとえば、赤外線方式）により、他の機器（他のゲーム装置など）との間で赤外線信号の送受信を行う機能、および所定の通信プロトコル（たとえば、マルチリンクプロトコル）に従って、同種のゲーム装置との間で無線通信を行う機能を有する。したがって、たとえば、ＣＰＵ２０は、ローカル通信モジュール３０を用いて、同種の他のゲーム装置との間でデータを直接送受信することもできる。

入力装置３２は、押しボタン、十字ボタン、アナログスティック、タッチパネルなどの様々な操作手段を含む。各ボタンに対する入力状況（押下されたか否かなど）を示す操作データやタッチパネルからの信号に基づく所定の形式のタッチ位置データが出力される。ＣＰＵ２０は、入力装置３２からの操作データやタッチ位置データを取得し、取得した操作データやタッチ位置データに応じた処理を実行する。詳細な説明は省略するが、この実施例では、タッチパネルは、第２ＬＣＤ４６上に設けられる。

第１ＧＰＵ３４は、ＣＰＵ２０からの指示に応じて、メインメモリ２２に記憶されているデータ（表示画像を生成するためのデータ）に基づいて第１の表示画像を生成し、第１ＶＲＡＭ３６に描画する。第２ＧＰＵ４２は、同様にＣＰＵ２０からの指示に応じて第２の表示画像を生成し、第２ＶＲＡＭ４０に描画する。

ＬＣＤコントローラ３８は、第１ＶＲＡＭ３６に描画された第１の表示画像を第１ＬＣＤ４４に出力し、第２ＶＲＡＭ４０に描画された第２の表示画像を第２ＬＣＤ４６に出力する。

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

また、図示は省略するが、ゲームに必要な音（音楽）を出力するためのスピーカも設けられる。

たとえば、このようなゲーム装置１０では、プレイヤがこの実施例のゲーム（アプリケーション）を開始すると、通常、シングルプレイのゲーム処理が開始（実行）される。ただし、シングルプレイモードとは、ゲーム装置１０のプレイヤが単独で仮想のゲーム世界に存在する１つのプレイヤキャラクタを操作してプレイする１人用のゲームを処理するモードを意味する。

また、シングルプレイモードのゲーム処理では、同じゲームをプレイするプレイヤが対戦相手の候補として探索され、探索された対戦相手の候補に対戦プレイを申し込んだり、対戦相手の候補から対戦プレイを申し込まれたりすることができる。対戦相手の候補に対戦プレイすることを承諾されたり、対戦相手の候補に対戦プレイすることを承諾したりすることにより、対戦プレイすることについて合意に達すると、対戦プレイすることが決定される。すると、対戦プレイすることが決定された複数のゲーム装置１０の間で接続が確立され、対戦プレイモードのゲーム処理が実行される。ただし、対戦プレイモードとは、複数のゲーム装置１０のプレイヤ間で、仮想のゲーム世界に存在するそれぞれのプレイヤキャラクタを操作してプレイ（対戦プレイ）する複数人用のゲームを処理するモードを意味する。

この実施例では、シングルプレイモードのゲーム処理を実行することにより、第１ＬＣＤ４４に、図４（Ａ）に示すようなゲーム画面１００が表示される。ゲーム画面１００には、背景としてゲーム世界の画像が表示され、そのゲーム世界の画像上に、プレイヤキャラクタ１０２およびこのプレイヤキャラクタ１０２が所有するモンスターキャラクタ１０４が表示される。

シングルプレイモードでは、プレイヤの操作に従って、プレイヤキャラクタ１０２は、仮想空間に構築されたゲーム世界を移動したり、ゲーム世界に存在する野生のモンスターキャラクタを捕獲したり、捕獲した（所有する）モンスターキャラクタ１０４をノンプレイヤキャラクタ（図示せず）が所有するモンスターキャラクタや野生のモンスターキャラクタと戦わせたりする。また、プレイヤキャラクタ１０２は、プレイヤの操作に従って、所定のアイテム（図示せず）を取得したり、使用したりする。

また、シングルプレイモードでは、図４（Ｂ）に示すように、対戦プレイモードのゲーム処理を実行する場合の対戦相手を選択等するためのリスト画面１５０が第２ＬＣＤ４６に表示される。このリスト画面１５０には、対戦相手の候補が表示される。ただし、リスト画面１５０は、シングルプレイモードのゲーム処理の実行中に常に表示されている必要は無く、プレイヤが表示／非表示を選択してもよい。また、他のゲーム装置１０のプレイヤと対戦プレイできない状態においては、リスト画面１５０は表示されない。たとえば、対戦プレイできない状態とは、通信不能な状態やシングルプレイモードのゲーム処理の都合上、対戦プレイの申し込みをできない状態などを意味する。つまり、リスト画面１５０は、他のゲーム装置１０のプレイヤに対戦プレイを申し込むことができる場合に表示される。

図４（Ｂ）に示すリスト画面１５０には、左上部にボタン画像１５２が表示され、右上部にボタン画像１５４が表示される。このボタン画像１５２とボタン画像１５４の間には、アイコン１５６およびアイコン１５８が表示される。また、ボタン画像１５２、１５４およびアイコン１５６、１５８の下側には、表示領域１６０、１６２、１６４が設けられる。表示領域１６０には、友達として登録されたプレイヤが使用するゲームアバターの顔画像を付したアイコン１７０ａ、１７０ｂが表示される。また、表示領域１６２には、知り合いと判断されたプレイヤが使用するゲームアバターの顔画像を付したアイコン１７２ａ、１７２ｂ、１７２ｃが表示される。さらに、表示領域１６４には、通りすがりと判断されたプレイヤが使用するゲームアバターの顔画像を付したアイコン１７４ａ、１７４ｂ、１７４ｃ、１７４ｄ、１７４ｅ、１７４ｆが表示される。

したがって、図４（Ｂ）に示すようなリスト画面１５０が表示されている場合には、友達のプレイヤ、知り合いのプレイヤおよび通りすがりのプレイヤのいずれかを対戦相手として選択可能である。

また、図４（Ｂ）に示すように、リスト画面１５０では、友達のプレイヤ、知り合いのプレイヤおよび通りすがりのプレイヤが使用するゲームアバターの顔画像を付したアイコンを、友達、知り合いおよび通りすがりに分けて表示するので、このリスト画面１５０を見たプレイヤはその分類を識別可能である。

ここで、友達のプレイヤとは、お互いもしくは一方的に、このゲームのプレイ中以外においても、通信することを許可（登録）している他のプレイヤを意味する。

友達のプレイヤとして登録されたプレイヤについての情報（プレイヤデータ）は、たとえば、ゲーム装置１０の保存用データメモリ２６に記憶される。このように、友達として登録されたプレイヤについてのプレイヤデータをゲーム装置１０の保存用データメモリ２６に記憶するので、このプレイヤデータを記憶するためのサーバや外部メモリを用意する必要がなく、その手間やコスト（設置コストや管理コスト）を削減することができる。

ここで、友達のプレイヤの登録方法の例について簡単に説明する。ただし、ここで説明する登録方法は、ゲーム装置１０に予め備えられる機能（本体機能）によって友達のプレイヤを登録する方法である。

たとえば、近くに居る他のプレイヤを友達のプレイヤとして登録する場合には、ローカル通信モジュール３０を用いた近距離無線通信により、プレイヤは自身のゲーム装置１０を用いて不特定の他のゲーム装置１０を探索し、探索した他のゲーム装置１０のプレイヤから所望のプレイヤを選択する。すると、ゲーム装置１０の保存用データメモリ２６に、選択されたプレイヤについての情報（後述する「プレイヤ情報」）を記憶（登録）することが、当該他のゲーム装置１０に通知される。このような処理がお互いのプレイヤが所持するゲーム装置１０で行われると、それぞれのゲーム装置１０において、他方のゲーム装置１０のプレイヤについてのプレイヤ情報が保存用データメモリ２６に記憶される。

また、たとえば、近くに居ない他のプレイヤを友達のプレイヤとして登録する場合には、一方のプレイヤが、自身が所持するゲーム装置１０（説明の都合上、「ゲーム装置Ａ」という。）を用いて、他方のプレイヤのプレイヤ情報を登録する。

このとき、その他方のプレイヤが所持するゲーム装置１０（説明の都合上、「ゲーム装置Ｂ」という。）に、ゲーム装置Ａのプレイヤについてのプレイヤ情報を登録していない場合には、ゲーム装置Ａにおいて、ゲーム装置Ｂのプレイヤについてのプレイヤ情報が仮に登録（仮登録）される。そして、ゲーム装置Ａは、無線ＬＡＮによりインターネット接続し、ゲーム装置Ｂのプレイヤについてのプレイヤ情報を仮登録した旨を当該ゲーム装置Ｂに通知する。その後、ゲーム装置Ａでは、ゲーム装置Ｂから当該ゲーム装置Ａのプレイヤについてのプレイヤ情報を登録したことの通知を受けたときに、当該ゲーム装置Ｂのプレイヤについてのプレイヤ情報が実際に登録（本登録）される。

一方、ゲーム装置Ａにゲーム装置Ｂのプレイヤについてのプレイヤ情報が登録されたときに、ゲーム装置Ｂにゲーム装置Ａのプレイヤについてのプレイヤ情報が既に登録され、そのことが当該ゲーム装置Ａに通知されている場合には、当該ゲーム装置Ａではゲーム装置Ｂのプレイヤについてのプレイヤ情報がそのまま本登録される。

なお、友達のプレイヤ登録は必ずしもプレイヤ双方の同意に基づく必要はなく、一方のプレイヤの意思に基づいて一方的に登録されてもよい。

また、知り合いのプレイヤとは、友達のプレイヤとして登録されていないが、過去に一度でも対戦プレイを行ったことがある他のプレイヤを意味する。また、各プレイヤは、ゲーム装置１０を用いて他のゲーム装置１０と通信することにより、当該他のゲーム装置１０を所持するプレイヤとの間で、ゲーム世界におけるプレイヤキャラクタ１０２が所有しているモンスターキャラクタ１０４を交換（送受信）することができ、過去に一度でもモンスターキャラクタ１０４の交換を行ったことがある他のプレイヤも知り合いのプレイヤと判断される。

知り合いのプレイヤと判断されたプレイヤについてのプレイヤデータは、たとえば、当該ゲームのゲームデータとともに、セーブデータとして、ゲーム装置１０の保存用データメモリ２６に記憶される。図示は省略するが、セーブデータは、ゲーム装置１０に着脱可能に設けられたメモリカード（たとえば、ＳＤカード）に記憶されてもよい。

さらに、通りすがりのプレイヤとは、友達のプレイヤとして登録されておらず、しかも知り合いのプレイヤと判断されていないプレイヤであって、シングルプレイモードにおいて少なくとも一時的にこのゲーム装置１０と通信可能な状態になったと判断された他のゲーム装置１０を所持するプレイヤである。具体的には、シングルプレイモードにおいてこのゲーム装置１０で受信された情報通知の信号（後述する）を送信した他のゲーム装置１０を所持するプレイヤである。通りすがりのプレイヤとの間では、上述したように、この実施例のゲームを実行している場合に、合意の下に、対戦ゲームをプレイしたり、ゲームデータを交換したりできる。ただし、一度に交換できるのは、１つのキャラクタについてのデータである。

たとえば、通りすがりのプレイヤと判断されたプレイヤについてのプレイヤデータは、ゲームを終了したときに消去される。ただし、後述するように、ゲーム中であっても、通りすがりのプレイヤの数が所定数を超える場合には、最も古いプレイヤについてのプレイヤデータから順に上書き（消去）される。

この実施例では、ゲーム装置１０は、友達のプレイヤとして登録されたゲーム装置１０、知り合いのプレイヤとして判断されたゲーム装置１０、および通りすがりのプレイヤとして判断されたゲーム装置１０との間で実行可能な機能がそれぞれ異なる。たとえば、通りすがり、知り合いおよび友達の順で親密度ないし信頼度が高くなると仮定し、親密度ないし信頼度が高くなるにつれて、同一の機能が高機能化されたり、他に無い機能が使用可能にされたりする。

具体的には、共通する機能として、ゲーム装置１０は、友達、知り合いおよび通りすがりのプレイヤのゲーム装置１０との間で、キャラクタ（キャラクタデータ）の送受信（交換）が可能である。

たとえば、通りすがりのプレイヤのゲーム装置１０との間では、この実施例のゲームのプレイ中に、一度に１つのキャラクタを送受信（交換）することができる。ただし、知り合いのプレイヤのゲーム装置１０との間では、一度に複数のキャラクタを送受信（交換）することができる。

また、知り合いのプレイヤのゲーム装置１０との間では、対戦プレイした後に、当該知り合いのプレイヤを友達のプレイヤとして登録するかどうかを選択することができる。ただし、知り合いのプレイヤのゲーム装置１０との間では、この実施例のゲーム（アプリケーション）以外でゲームデータやメッセージを送受信することはできない。

友達のプレイヤのゲーム装置１０との間では、この実施例のゲーム（アプリケーション）以外のアプリケーションを実行する場合にも、すなわち、アプリケーションの種類に拘わらず、ゲームデータを交換（送受信）したり、メッセージを送受信したりすることができる。つまり、友達のプレイヤについてのプレイヤ情報（プレイヤデータ）は、アプリケーションの種類に拘わらず利用可能である。

また、この実施例では、リスト画面１５０では、友達、知り合いおよび通りすがりのプレイヤは、それぞれ、所定数（たとえば、１００）表示することができる。所定数を超える場合には、最も早く友達のプレイヤとして登録されたり、最も早く知り合いや通りすがりのプレイヤとして判断されたりしたプレイヤ（最も古いプレイヤ）についての情報（プレイヤデータ）から順に上書きされる。図示は省略するが、表示領域１６０、１６２、１６４は、友達、知り合いおよび通りすがりのプレイヤが使用するゲームアバターの顔画像を付したアイコン（１７０ａ、１７０ｂ、１７２ａ−１７２ｃ、１７４ａ−１７４ｆなど）を表示（描画）する欄の一部を表示する。

この実施例では、リスト画面１５０に、友達のプレイヤ、知り合いのプレイヤ、および通りすがりのプレイヤが使用するゲームアバターの顔画像を付したアイコンを表示するようにしてある。したがって、リスト画面１５０は、友達のプレイヤ、知り合いのプレイヤ、および通りすがりのプレイヤについての情報を表示していると言える。ただし、ゲームアバターの顔画像の情報（後述する「アバター情報」に含まれる。）は、ゲーム装置１０に登録（記憶）されたプレイヤ情報に含まれるため、リスト画面１５０は、友達のプレイヤ、知り合いのプレイヤ、および通りすがりのプレイヤが所持ないし使用するゲーム装置１０の情報を表示しているとも言える。

また、上述したボタン画像１５２およびボタン画像１５４は、リスト画面１５０をスクロールさせるための操作ボタンを示す。たとえば、入力装置３２に含まれるＬボタンまたはＲボタンを押すことにより、リスト画面１５０が左または右にスクロールされる。ただし、タッチパネル上でスライド操作を行うことにより、リスト画面１５０をスクロールさせることもできる。したがって、リスト画面１５０をスクロールさせることにより、現在表示されていないアイコンを表示することもできる。

アイコン１５６およびアイコン１５８は、通信方法（通信手段）を選択するために設けられる。この実施例では、アイコン１５６がオン（タッチ）された場合には、ローカル通信モジュール３０を用いた近距離無線通信（以下、「ローカル通信」ということがある）が選択される。一方、アイコン１５８がオンされた場合には、インターネット通信モジュール２８を用いた無線通信（以下、「インターネット通信」ということがある）が選択される。

詳細な説明は省略するが、デフォルト設定では、ローカル通信が選択されている。また、インターネット通信が選択された場合であっても、インターネット７に接続出来ない場合またはインターネット７への接続が切断された場合には、自動的にローカル通信に切り替えられる。

シングルプレイモードや対戦プレイモードのゲームの実行中には、各ゲーム装置１０は、状態通知の信号を、他のゲーム装置１０に送信したり、サーバ５に送信したりする。また、各ゲーム装置１０は、他のゲーム装置１０から送信される状態通知の信号を受信したり、サーバ５から送信される他のゲーム装置１０についてのゲームの状況についてのデータを受信したりする。以下、具体的に説明する。

ローカル通信が選択されている場合には、各ゲーム装置１０は、シングルプレイモードまたは対戦プレイモードのゲームの実行中に、状態通知のビーコン信号を、ローカル通信モジュール３０を用いて、不特定の他のゲーム装置１０に向けて繰り返し送信（ブロードキャスト）する。また、各ゲーム装置１０は、不特定の他のゲーム装置１０から送信された状態通知のビーコン信号を、ローカル通信モジュール３０を用いて繰り返し受信する。

ビーコン信号の送信の方式は、アクティブスキャン方式であってもよいし、パッシブスキャン方式であってもよい。具体的には、各ゲーム装置１０がビーコン信号を所定の周期で宛先を特定せずに送信（ブロードキャスト）してもよいし、各ゲーム装置１０から所定の周期で宛先を指定せずにプローブリクエストのパケットを送信し、このプローブリクエストのパケットを受信した他のゲーム装置１０からビーコン信号を送信してもよい（プローブレスポンス）。ただし、この実施例において送受信されるビーコン信号は近距離無線信号である。たとえば、近距離無線信号は、赤外線信号やBluetooth（登録商標）による電波信号である。

ここで、状態通知のビーコン信号は、種類ＩＤ、装置ＩＤ、ゲームＩＤ、プレイヤ情報、ゲーム状況などの情報を含む。

種類ＩＤは、ビーコン信号の種類を識別するための識別情報である。この実施例では、状態通知のビーコン信号の他に後述する３種類のビーコン信号がある。その種類が種類ＩＤによって識別されるのである。装置ＩＤは、ゲーム装置１０を識別するための識別情報である。ゲームＩＤは、ゲームの種類を識別するための識別情報である。

プレイヤ情報は、プレイヤＩＤ、プレイヤの名称、プレイヤのプロフィール情報、アバター情報などを含む。プレイヤＩＤは、ゲーム装置１０の所有者（プレイヤ）の識別情報であり、このプレイヤＩＤを含むビーコン信号の送信元を示す。プレイヤの名称は、プレイヤがゲーム装置１０に登録した名称である。プロフィール情報は、プレイヤがゲーム装置１０に登録した自身のプロフィール（性別、居住地、趣味など）の情報である。アバター情報は、プレイヤが使用するゲームアバターの顔（頭髪を含む。）のパーツ、体のパーツ、服装（帽子、眼鏡、装飾品なども含む。）についての設定情報（パラメータ）である。

ゲーム状況は、現在実行中のゲーム処理がシングルプレイモードであるか対戦プレイモードであるかを示す情報である。

また、インターネット通信が選択されている場合には、この実施例のゲームを実行中のゲーム装置１０は、状態通知のデータをサーバ５に送信する。サーバ５は、各ゲーム装置１０のゲーム状況および通信状況（以下、これらを「現在の状況」ということがある）を管理する。

ここで、通信状況は、ゲーム装置１０と通信可能かどうかを示す情報である。この実施例では、シングルプレイモードのゲーム装置１０とは通信可能であり、対戦プレイモードのゲーム装置１０とは通信不能である。また、通信不能の場合としては、ゲーム装置１０がオフラインである場合、インターネット通信おいてアクセスポイントにアクセスできない（インターネット７に接続できない）場合がある。

なお、ローカル通信においては、オフラインの場合やビーコン信号の届く範囲に存在しない場合に、ゲーム装置１０は通信不能である。

インターネット通信が選択されている場合には、各ゲーム装置１０は、ゲーム状況が変化するときに、状態通知のデータをサーバ５に送信する。ここで、ゲーム状況が変化するときとは、シングルプレイモードから対戦プレイモードに変化するとき、そして、対戦プレイモードからシングルプレイモードに変化するときを意味する。ただし、状態通知のデータは、上述した状態通知のビーコン信号と同様の内容であるが、種類ＩＤは、ゲーム装置１０からサーバ５に送信されるデータの種類を示す。また、インターネット通信が選択されている場合には、ゲーム装置１０は、ゲームを開始するときにそのことをサーバ５に通知し、また、ゲームを終了するときにそのことをサーバ５に通知する。これによって、サーバ５は、ゲーム装置１０がオンラインになったことやオフラインになったことを知ることができる。

一方、サーバ５は、自身に接続されるゲーム装置１０の各々に、自身に接続される他のゲーム装置１０の各々の現在の状況を通知する。詳細な説明は省略するが、サーバ５は、ゲームの種類毎にゲーム装置１０のプレイヤおよびその現在の状況を管理する。このとき、状態通知のデータに含まれるゲームＩＤに基づいて同じ種類のゲームをプレイしているゲーム装置１０を判別する。そして、各ゲーム装置１０には、同じ種類のゲームをプレイしている他のゲーム装置１０の現在の状況が通知される。ただし、他のゲーム装置１０の現在の状況には、当該他のゲーム装置１０のプレイヤ情報が付加されている。

ここで、リスト画面１５０を更新（生成）する方法について説明する。ローカル通信が選択されている場合には、たとえば、ゲーム装置１０は、他のゲーム装置１０からの状態通知のビーコン信号を受信すると、この状態通知のビーコン信号に含まれるゲームＩＤがこの実施例のゲームのゲームＩＤと一致するかどうかを判断する。ゲームＩＤが一致しない場合には、受信された状態通知のビーコン信号は消去（破棄）される。

ゲームＩＤが一致する場合には、プレイヤＩＤが示すプレイヤが友達として登録されたり、知り合いと判断されたりしたプレイヤであるかどうかが判断される。プレイヤＩＤが示すプレイヤが友達として登録されたり、知り合いと判断されたりしたプレイヤである場合には、ゲーム状況に応じてアイコンの表示態様が変化される。ゲーム状況がシングルプレイモードを示す場合には、通常の色および明るさでアイコンが表示され、ゲーム状況が対戦プレイモードである場合には、アイコンがグレーアウトで表示される。これは、現在、対戦プレイ中であり、他の対戦プレイを実行することができないためである。図４（Ｂ）では、顔画像に斜線を付すことにより、グレーアウトで表示されていることを示してある。ただし、通常とは異なる表示態様とすればよく、アイコンの色、形状または大きさあるいはそれらのいずれか２つ以上を変化させるようにしてもよい。また、アイコンを非表示にしてもよい。

また、友達や知り合いのプレイヤが所持するゲーム装置１０からの状態通知のビーコン信号を所定時間（たとえば、１８０秒）受信しない場合には、当該ゲーム装置１０はオフラインである、またはビーコン信号の届く範囲に存在しない（近距離に居ない）ため、対戦プレイすることができない。したがって、かかる場合にも、アイコンがグレーアウトで表示される。

ただし、その後に、ゲーム装置１０が、シングルプレイモードのゲーム処理を実行することにより、オンラインとなり、ビーコン信号が届く範囲に存在する（近距離に居る）場合には、対応するアイコンは通常の色および明るさで表示される。つまり、現在の状況をアイコンの表示態様の変化によってリアルタイムに知ることができる。

また、この実施例では、通信不能になった他のゲーム装置１０を所持するプレイヤについては、最後に受信した情報（状態通知のビーコン信号の情報）を保持しておくことにより、対応するアイコンがグレーアウトで表示されている場合であっても、当該プレイヤの情報（プロフィールなど）を見ることができる。その後に、通信可能となった場合には、保持していた情報が最新の情報に更新される。

なお、この実施例では、対戦プレイ中の場合と、オフラインまたは近距離に居ない場合には、アイコンをグレーアウトするようにしたが、これらを識別可能にするために、アイコンの表示態様を変化させてもよい。たとえば、対戦プレイ中では、アイコンを通常の色および明るさで表示し、当該アイコンの近傍に対戦プレイ中であることを示す画像ないしテキストを表示するようにしてもよい。このことは、後述する通りすがりのプレイヤについても同様である。

ゲームＩＤが一致する場合であり、プレイヤＩＤが示すプレイヤが友達や知り合いのプレイヤでない場合には、通りすがりのプレイヤとして既に判断（表示欄に追加）されているかどうかを判断する。

通りすがりのプレイヤとして既に追加されている場合には、ゲーム状況に応じてアイコンの表示態様が変化される。表示態様の変化は、友達や知り合いのプレイヤのアイコンの場合と同じである。ただし、既に通りすがりのプレイヤとして追加されたプレイヤが所持するゲーム装置１０からの状態通知のビーコン信号を所定時間（たとえば、１８０秒）受信しない場合には、当該ゲーム装置１０はオフラインである、またはビーコン信号の届く範囲に存在しないため、アイコンがグレーアウトで表示される。

なお、この実施例では、オフラインやビーコン信号の届く範囲に存在しないゲーム装置１０を所持するプレイヤのアイコンをグレーアウトで表示するようにしてあるが、アイコンを非表示にしてもよい。

また、現在のゲーム状況が対戦プレイ中であるプレイヤやオフラインのプレイヤを除けば、友達、知り合いおよび通りすがりのプレイヤであって、ビーコン信号の届く範囲に存在しないゲーム装置１０を所持するプレイヤのアイコンを非表示する場合には、ビーコン信号の届く範囲（所定範囲）内に存在し、対戦プレイが可能であるプレイヤのアイコンのみがリスト画面１５０に表示されると言える。

このように、ローカル通信が選択されている場合には、シングルプレイモードにおいて、各ゲーム装置１０は、他のゲーム装置１０に状態通知のビーコン信号を送信し、他のゲーム装置１０からの状態通知のビーコン信号を受信することにより、対戦相手の候補を互いに探索しているのである。ただし、対戦相手の候補は、状態通知のビーコン信号を送受信可能な所定範囲に存在するゲーム装置１０である。つまり、比較的近距離に居る他のプレイヤを探索するのである。

なお、この実施例では、状態通知のビーコン信号に含まれるプレイヤ情報（プレイヤデータ）を参照して、友達として登録されているかどうか、知り合いと判断されたかどうかを判断するようにしてあるが、これに限定される必要はない。他のゲーム装置１０の識別情報（装置ＩＤ）に基づいて、友達として登録されているか、知り合いと判断されたかを判断するようにしてもよい。

また、インターネット通信が選択されている場合には、サーバ５から通知される他のゲーム装置１０の現在の状況に応じて、ローカル通信が選択されている場合と同様に、リスト画面１５０が更新（生成）される。ただし、ゲームＩＤが一致するかどうか、すなわち、同じ種類のゲームをプレイしているかどうかはサーバ５で判断（管理）されるため、この判断処理がゲーム装置１０で実行されることはない。また、上述したように、ゲーム状況が変化される場合に、ゲーム装置１０は状態通知のデータをサーバ５に送信するため、ゲーム装置１０がオフラインであること、またはアクセスポイントにアクセスできないことを判断する所定時間はシングルプレイモードと対戦プレイモードで異なる。たとえば、サーバ５は、ゲーム状況がシングルプレイモードである場合には、３０分〜１時間経過しても、状態通知のデータを送信してこないゲーム装置１０についてはオフラインまたはアクセスポイントにアクセスできないと判断する。また、たとえば、サーバ５は、ゲーム状況が対戦プレイモードである場合には、１８０〜５４０秒経過しても、状態通知のデータを送信してこないゲーム装置１０についてはオフラインまたはアクセスポイントにアクセスできないと判断する。

このように、インターネット通信が選択されている場合には、シングルプレイモードにおいて、各ゲーム装置１０は、サーバ５に状態通知のデータを送信し、サーバ５から他のゲーム装置１０のプレイヤ情報が付加された現在の状況を受信することにより、つまりサーバ５を介して、対戦相手の候補を互いに探索している。この場合、対戦相手の候補は、インターネット７に接続している不特定の他のゲーム装置１０である。

上述したように、状態通知の信号は、対戦プレイモードのゲームが実行されている場合にも送信されるが、これは対戦プレイのゲーム処理を実行中であることを他のゲーム装置１０に通知するためである。図示は省略するが、対戦プレイにおいては、対戦相手を選択する必要がないため、リスト画面１５０は表示されない。

なお、上述したように、この実施例では、ローカル通信とインターネット通信を選択する（切り替える）ことができる。上述したように、これらの通信方法は異なるため、ローカル通信またはインターネット通信が選択されている場合に、通りすがりのプレイヤとして判断されたプレイヤが所持ないし使用するゲーム装置１０とは、通信方法が切り替えられると、ほとんどの場合に通信不能となる。したがって、ローカル通信からインターネット通信に切り替えられたり、インターネット通信からローカル通信に切り替えられたりした場合には、通りすがりのプレイヤを一旦消去するようにしてもよい。

また、シングルプレイモードのゲーム処理が実行されている場合に、リスト画面１５０において、所望のアイコン（図４（Ｂ）では、１７０ａ、１７０ｂ、１７２ａ−１７２ｃ、１７４ａ−１７４ｆ）を選択（タッチ）することにより、対応するプレイヤのプロフィール情報を見たり、対応するプレイヤに対戦プレイを申し込んだりすることができる。

たとえば、図４（Ｂ）に示すリスト画面１５０において、アイコン１７０ａを選択し、対応するプレイヤに対戦プレイを申し込む（対戦を要求する）と、図５に示すような対戦プレイを要求する画面（要求画面）２００が第２ＬＣＤ４６に表示される。図示は省略するが、このとき、第１ＬＣＤ４４には、シングルプレイのゲーム画面１００が表示されたままであり、プレイヤの操作に従って、シングルプレイは継続される。たとえば、対戦プレイを申し込んでいる最中であっても、プレイヤの操作に従って、プレイヤキャラクタ１０２およびモンスターキャラクタ１０４はゲーム世界を移動される。

また、図５に示すように、要求画面２００は、表示領域２０２が画面の中央に表示され、その下側にアイコン２０４が表示される。また、要求画面２００の右下部には、ボタン画像２０６が表示される。表示領域２０２には、誰に（どのプレイヤ）に対戦プレイを申し込んだかを示す情報（テキスト情報）が表示される。アイコン２０４は、対戦プレイを申し込んだ相手のプレイヤが使用するゲームアバターの顔画像が付されたアイコンである。図５からも分かるように、対戦プレイを申し込んだ相手のプレイヤは友達のプレイヤ（アイコン１７０ａに対応するプレイヤ）である。また、アイコン２０４を選択（タッチ）することにより、対応するプレイヤのプロフィール情報を見ることができる。ボタン画像２０６は、リスト画面１５０に戻るためのボタンである。ボタン画像２０６がオン（タッチ）されると、第２ＬＣＤ４６には、図４（Ｂ）に示したようなリスト画面１５０が表示される。このとき、対戦プレイの申し込みをキャンセルするようにしてもよい。

このように、プレイヤは、リスト画面１５０を用いて、シングルプレイのゲーム中の任意のタイミングで、他のゲーム装置１０のプレイヤに対戦を申し込むことができる。ただし、上述したように、リスト画面１５０が表示されていない場合のように、他のゲーム装置１０と対戦プレイできない状態においては、対戦を申し込むことができない。

また、対戦プレイを申し込む（対戦を要求する）と、対戦を要求するための信号がゲーム装置１０から送信される。この対戦を要求するための信号は、種類ＩＤ、装置ＩＤ、ゲームＩＤ、プレイヤＩＤ、要求先ＩＤなどの情報を含む。ただし、ローカル通信が選択されている場合には、ゲーム装置１０は、ローカル通信モジュール３０を用いて、対戦プレイを要求するためのビーコン信号（対戦要求のビーコン信号）を送信（ブロードキャスト）する。一方、インターネット通信が選択されている場合には、ゲーム装置１０は、インターネット通信モジュール２８を用いて、対戦プレイを要求するためのデータ（対戦要求のデータ）をサーバ５に送信する。

種類ＩＤ、装置ＩＤ、ゲームＩＤ、プレイヤＩＤは、上述したとおりである。要求先ＩＤは、対戦を申し込む（要求する）相手のプレイヤの識別情報（プレイヤＩＤ）である。図５の要求画面２００が第２ＬＣＤ４６に表示されている場合には、アイコン１７０ａに対応するプレイヤのプレイヤＩＤが要求先ＩＤとして対戦要求のビーコン信号や対戦要求のデータに含まれる。このように、要求先ＩＤを含めるのは、ビーコン信号はブロードキャストされるため、対戦要求のビーコン信号を受信した側で、対戦プレイが申し込まれたかどうかを判断する必要があるからである。また、サーバ５で対戦要求されたプレイヤを特定するためである。インターネット通信では、サーバ５は、対戦要求のデータを受信すると要求先ＩＤが示すプレイヤが所持するゲーム装置１０にこの対戦要求のデータを送信する。ただし、サーバ５には、プレイヤＩＤに対応して、プレイヤＩＤが示すプレイヤが所持するゲーム装置１０への接続情報（ＩＰアドレス）が記憶されている。

一方、対戦プレイを申し込まれた（対戦を要求された）場合には、図６に示すような対戦を要求された場合の画面（被要求画面）２５０が第２ＬＣＤ４６に表示される。図示は省略するが、このとき、第１ＬＣＤ４４には、シングルプレイのゲーム画面１００が表示されたままであり、プレイヤの操作に従って、シングルプレイは継続される。たとえば、対戦プレイを申し込まれている最中であっても、その申し込みに対して応答することなく、応答を保留したままで、プレイヤの操作に従って、プレイヤキャラクタ１０２およびモンスターキャラクタ１０４はゲーム世界を移動される。つまり、対戦プレイを申し込まれても、ゲームが中断することがなく、また、割り込みで対戦プレイが開始されることもないのである。

図６に示すように、被要求画面２５０には、その上部に表示領域２５２が設けられ、その下側にアイコン２５４が表示される。さらに、アイコン２５４の下側に、アイコン２５６およびアイコン２５８が表示される。

表示領域２５２には、誰（どのプレイヤ）から対戦プレイを申し込まれたかの情報（テキスト情報）が表示される。このテキスト情報には、対戦プレイを申し込んできたプレイヤが、友達、知り合い、通りすがりのいずれであるかの情報も含まれる。したがって、プレイヤは、対戦を申し込んできたプレイヤの分類を知ることができるので、その分類を加味して、対戦プレイを行うかどうかを判断することできる。たとえば、知り合いのプレイヤからの対戦プレイの申し込みであれば、少なくとも一度は対戦プレイやキャラクタの交換を行っているため、通りすがりのプレイヤと対戦プレイする場合に比べて安心して対戦プレイを行うことができる。また、友達のプレイヤからの対戦プレイの申し込みであれば、知り合いのプレイヤよりも親密度や信頼度が高いと考えられるため、さらに安心して対戦プレイを行うことができる。

アイコン２５４は、対戦プレイを申し込んできたプレイヤが使用するゲームアバターの顔画像を付したアイコンである。ここでは、図６からも分かるように、リスト画面１５０に表示されていたアイコン１７２ａに対応する知り合いのプレイヤから対戦プレイが申し込まれている。また、アイコン２５４を選択（タッチ）することにより、対応するプレイヤのプロフィール情報を見ることができる。アイコン２５６は、対戦プレイの申し込みを受諾するためのボタンである。また、アイコン２５８は、対戦プレイの申し込みを拒否するためのボタンである。

被要求画面２５０が表示されている場合に、アイコン２５６がオン（タッチ）されると、ゲーム装置１０から対戦プレイの申し込みを受諾したことを示す信号が送信される。要求受諾の信号は、種類ＩＤ、装置ＩＤ、ゲームＩＤ、プレイヤＩＤ、要求元ＩＤなどの情報を含む。ただし、ローカル通信が選択されている場合には、ゲーム装置１０は、ローカル通信モジュール３０を用いて、申し込みを受諾したことを示すビーコン信号（要求受諾のビーコン信号）を送信（ブロードキャスト）する。インターネット通信が選択されている場合には、ゲーム装置１０は、インターネット通信モジュール２８を用いて、申し込みを受諾したことを示すデータ（要求受諾のデータ）をサーバ５に送信する。

種類ＩＤ、装置ＩＤ、ゲームＩＤ、プレイヤＩＤは、上述したとおりである。要求元ＩＤは、対戦プレイを申し込んできた（対戦を要求してきた）相手のプレイヤの識別情報（プレイヤＩＤ）である。このようにするのは、ローカル通信が選択されて場合には、要求受諾のビーコン信号がブロードキャストされるため、ビーコン信号を受信した側で、対戦プレイの要求が受諾されたことを判断する必要があるからである。また、サーバ５で、対戦要求が受諾されたプレイヤを特定するためである。インターネット通信では、サーバ５は、対戦受諾データを受信すると要求元ＩＤが示すプレイヤが所持するゲーム装置１０にこの対戦受諾データを送信する。

また、被要求画面２５０が表示されている場合に、アイコン２５８がオン（タッチ）されると、ゲーム装置１０は、対戦プレイの申し込みを拒否するための信号（要求拒否のビーコン信号）ないしデータ（要求拒否データ）を送信する。

要求拒否のビーコン信号および要求拒否データは、種類ＩＤが示す種類が異なる以外は、要求受諾のビーコン信号および要求受諾のデータと同じである。

ただし、この実施例では、アイコン２５８をオン（タッチ）しなくても、被要求画面２５０が表示されてから、所定時間（この実施例では、３０秒−６０秒）応答しない場合には、自動的に要求拒否のビーコン信号または要求拒否データが送信される。

このように、対戦プレイの申し込みがあっても、勝手に割り込みで対戦プレイが開始されることが無く、その申し込みに対する応答（受諾または拒否）を保留して、シングルプレイのゲームを継続することができる。そして、何ら応答せずに、シングルプレイのゲームを継続していれば、自動的に対戦プレイの申し込みを拒否することができる。つまり、プレイヤの手を煩わせることがない。

この実施例では、被要求画面２５０が表示された時点から所定時間をカウントするようにしてあるが、これに限定される必要はない。対戦要求のビーコン信号ないし対戦要求のデータを受信した時点から所定時間をカウントするようにしてもよい。

また、所定時間のカウントを、対戦要求のビーコン信号または対戦要求のデータの送信側のゲーム装置１０で行い、受信側のゲーム装置１０から所定時間応答が無い場合に、送信側のゲーム装置１０で自動的に対戦プレイの申し込みをキャンセルしてもよい。

このように、プレイヤの操作に従って、他のゲーム装置１０のプレイヤに対戦を申し込んだり、他のゲーム装置のプレイヤからの対戦の申し込みを受諾または拒否したりすることができる。

対戦プレイの申し込みが受諾された場合には、対戦プレイを開始するべく、対戦プレイを申し込んだプレイヤのゲーム装置１０と、それを受諾したプレイヤのゲーム装置１０は、それぞれシングルプレイモードのゲーム処理を中断し、それらのゲーム装置１０の間でデータの送受信を行うための接続が確立される。ローカル通信が選択されている場合には、ローカル通信モジュール３０を用いて、ゲーム装置１０間でデータの送受信を行うための接続が確立される。一方、インターネット通信が選択されている場合には、サーバ５から対戦プレイを行う複数のゲーム装置１０に対戦相手のゲーム装置１０への接続情報（ＩＰアドレス）が通知され、インターネット通信モジュール２８を用いて、複数のゲーム装置１０間でデータの送受信を行うための接続が確立される。

接続が確立されると、対戦プレイモードのゲーム処理（以下、「対戦プレイ処理」という）が実行される。このとき、たとえば、対戦プレイを申し込んだ側のゲーム装置１０が親機として機能し、対戦プレイを申し込まれた側のゲーム装置１０が子機として機能する。親機は、子機の操作データを受信して、受信した子機の操作データと自機の操作データに基づいて対戦プレイモードのゲーム制御処理を実行し、処理結果に応じたゲーム画像を生成および出力（画面表示など）するとともに、処理結果のデータ（処理結果データ）を子機に送信する。子機は、受信した処理結果データに応じたゲーム画像を生成および出力する。

なお、接続が確立されると、対戦プレイ処理が開始されるため、対戦プレイの申し込みは、接続（通信接続）の要求であるとも言える。

対戦プレイモードでは、対戦を申し込んだプレイヤが使用するモンスターキャラクタと、その申し込みを受諾したプレイヤが使用するモンスターキャラクタとがゲーム世界に配置され、それぞれのプレイヤの操作に従って、互いに他のモンスターキャラクタを攻撃したり、他のモンスターキャラクタの攻撃を防御したりする。

対戦の決着がつき、対戦プレイ処理を終了すると、たとえば、中断されていたシングルプレイモードのゲーム処理が再開される。したがって、シングルプレイモードのゲーム処理が中断されるときに、シングルプレイモードのゲーム処理で用いられるゲームデータ（シングルプレイ処理用データ５０４ｆ）は保存（セーブ）され、再開するときに、読み出される。したがって、たとえば、中断した時点からシングルプレイモードのゲーム処理を再開することができる。

上述したように、この実施例では、一度でも対戦プレイを行ったプレイヤは知り合いとして判断される。このため、対戦プレイを終了したときに、今回の対戦相手が通りすがりのプレイヤであった場合には、知り合いのプレイヤと判断され、当該プレイヤのプレイヤデータが、当該ゲームのゲームデータとともに、セーブデータとして、ゲーム装置１０の保存用データメモリ２６に記憶される。ここで、対戦相手である通りすがりのプレイヤと知り合いになった旨を表示してもよい。

また、この実施例では、対戦プレイを終了したときに、今回の対戦相手が知り合いのプレイヤであった場合には、友達として登録するかどうかを選択（決定）することができる。たとえば、対戦プレイを終了すると、今回の対戦相手が知り合いのプレイヤである場合には、図７に示すような友達登録画面３００が第２ＬＣＤ４６に表示される。

図７に示すように、友達登録画面３００には、その上部に表示領域３０２が設けられ、その下側にアイコン３０４が表示される。さらに、アイコン３０４の下側に、アイコン３０６およびアイコン３０８が表示される。

表示領域３０２には、今回の対戦相手（ここでは、Ｂさん）を友達のプレイヤとして登録するかどうかを質問するテキスト情報が表示される。アイコン３０４は、今回の対戦相手である知り合いのプレイヤが使用するゲームアバターの顔画像を付したアイコンである。このアイコン３０４を選択（タッチ）することにより、対応するプレイヤ（Ｂさん）のプロフィール情報を見ることができる。アイコン３０６は、今回の対戦相手である知り合いのプレイヤを友達のプレイヤとして登録することを選択するためのボタンである。また、アイコン３０８は、今回の対戦相手である知り合いのプレイを友達のプレイヤとして登録しないことを選択するためのボタンである。

たとえば、友達登録画面３００が表示されている場合において、アイコン３０６がオン（タッチ）されると、友達のプレイヤとして登録することが、今回の対戦相手である知り合いのプレイヤが使用するゲーム装置１０に送信（通知）される。一方、今回の対戦相手である知り合いのプレイヤが使用するゲーム装置１０から友達のプレイヤとして登録することが通知されると、友達のプレイヤとして登録することについて合意に達する。つまり、相互認証される。よって、各ゲーム装置１０において、今回の対戦相手である知り合いのプレイヤが友達のプレイヤとして登録される。これは、前述の本体機能によって友達のプレイヤを登録する方法とは異なり、このゲーム（アプリケーション）を実行することにより、友達のプレイヤとして登録する方法である。つまり、このゲームでは、通りすがりのプレイヤと一度対戦プレイやキャラクタの交換を行うと、知り合いのプレイヤと判断され、さらに、知り合いのプレイヤと対戦プレイ（キャラクタの交換でもよい）を行うと、合意の下に、友達のプレイヤとして登録することができるのである。

ただし、友達登録画面３００が表示されている場合において、アイコン３０６がオンされても、今回の対戦相手である知り合いのプレイヤが使用するゲーム装置１０から友達のプレイヤとして登録することの通知がない場合には、友達のプレイヤとして登録することについて合意に達しないため、当該知り合いのプレイヤは友達のプレイヤとして登録されない。

また、友達登録画面３００が表示されている場合において、アイコン３０８がオン（タッチ）されると、今回の対戦相手を友達のプレイヤとして登録しないことが選択される。かかる場合には、今回の対戦相手である知り合いのプレイヤが使用するゲーム装置１０から友達のプレイヤとして登録することが通知されたとしても、友達のプレイヤとして登録することについて合意に達しないため、当該知り合いのプレイヤは友達のプレイヤとして登録されない。

上述したように、知り合いのプレイヤと友達のプレイヤとでは、各プレイヤが使用（所持）するゲーム装置１０との間で実行可能な機能が異なるため、使用する機能に応じて、友達のプレイヤとして登録するかどうかを決定してよい。また、知り合いのプレイヤを友達として登録した旨または登録しなかった旨の表示をしてもよい。

図８は、図２に示したゲーム装置１０のメインメモリ２２のメモリマップ５００の一例を示す図解図である。図８に示すように、メインメモリ２２は、プログラム記憶領域５０２およびデータ記憶領域５０４を含む。プログラム記憶領域５０２には、情報処理プログラムの一例であるアプリケーションプログラムとしてのゲームプログラムが記憶される。このゲームプログラムは、メイン処理プログラム５０２ａ、画像生成プログラム５０２ｂ、画像表示プログラム５０２ｃ、シングルプレイ処理プログラム５０２ｄ、対戦プレイ処理プログラム５０２ｅ、接続関連処理プログラム５０２ｆおよび通信処理プログラム５０２ｇなどによって構成される。

メイン処理プログラム５０２ａは、この実施例のゲームのメインルーチン（ゲーム全体処理）についてのプログラムである。画像生成プログラム５０２ｂは、ポリゴンデータやテクスチャデータなどのデータを用いて、各種の画面（１００、１５０、２００、２５０など）についての画像データを生成するためのプログラムである。画像表示プログラム５０２ｃは、画像生成プログラム５０２ｂに従って生成された画像データを第１ＬＣＤ５６や第２ＬＣＤ５８に出力するためのプログラムである。

シングルプレイ処理プログラム５０２ｄは、シングルプレイモードのゲーム処理についてのプログラムである。対戦プレイ処理プログラム５０２ｅは、対戦プレイモードのゲーム処理についてのプログラムである。接続関連処理プログラム５０２ｆは、シングルプレイモードのゲーム処理を実行中に、他のゲーム装置１０に対戦要求を送信したり、他のゲーム装置１０からの対戦要求を受信したり、他のゲーム装置１０からの対戦要求に応答（受諾または拒否）したりするためのプログラムである。通信処理プログラム５０２ｇは、インターネット通信モジュール２８を用いて通信したり、ローカル通信モジュール３０を用いて通信したりするためのプログラムである。

なお、プログラム記憶領域５０２には、音出力プログラムやバックアッププログラムなども記憶される。音出力プログラムは、ゲームの音（音楽）を生成および出力するためのプログラムである。バックアッププログラムは、プレイヤの指示または所定のイベントに応じて、ゲームデータを保存（セーブ）するためのプログラムである。

また、データ記憶領域５０４には、送受信データバッファ５０４ａおよび操作入力データバッファ５０４ｂが設けられる。

送受信データバッファ５０４ａは、他のゲーム装置１０との間で送受信されるデータ（ビーコン信号を含む）を一時記憶するための領域である。操作入力データバッファ５０４ｂは、入力装置３２からの操作データやタッチ位置データを一時記憶するための領域である。

また、データ記憶領域５０４には、友達データ５０４ｃ、知り合いデータ５０４ｄ、通りすがりデータ５０４ｅ、シングルプレイヤ処理用データ５０４ｆ、対戦プレイ処理用データ５０４ｇ、キャラクタデータ５０４ｈ、マップデータ５０４ｉおよび自機プレイヤデータ５０４ｊなどが記憶される。

友達データ５０４ｃは、友達のプレイヤとして登録されているプレイヤについてのプレイヤデータである。プレイヤデータは、図９に示すように、プレイヤＩＤ、プレイヤ名、プロフィール情報、アバター情報およびゲーム状況などの情報を含む。これらは、状態通知のビーコン信号に含まれるプレイヤ情報である。ただし、プレイヤデータは、プレイヤ毎に記憶されるため、複数のプレイヤが友達として登録（記憶）されている場合には、それぞれのプレイヤに対応してプレイヤデータが記憶される。知り合いデータ５０４ｄおよび通りすがりデータ５０４ｅについても同様である。

知り合いデータ５０４ｄは、知り合いのプレイヤと判断されたプレイヤについてのプレイヤデータである。通りすがりデータ５０４ｅは、友達のプレイヤとして登録されておらず、しかも知り合いのプレイヤと判断されていないプレイヤであって、当該ゲーム装置１０で受信した状態通知のビーコン信号または状態通知のデータの送信元のゲーム装置１０のプレイヤについてのプレイヤデータである。

上述したように、友達および知り合いのプレイヤのプレイヤデータは、保存用データメモリ２６に記憶されるため、友達データ５０４ｃおよび知り合いデータ５０４ｄは、ゲーム開始時に保存用データメモリ２６からデータ記憶領域５０４に読み出される（ロードされる）。

シングルプレイ処理用データ５０４ｆは、シングルプレイモードのゲーム処理で用いられるデータである。図１０に示すように、シングルプレイ処理用データ５０４ｆは、現在位置データ、レベルデータ、所持アイテムデータおよび所有キャラクタデータなどを含む。現在位置データは、仮想空間におけるプレイヤキャラクタの現地位置のデータ（座標データ）である。レベルデータは、プレイヤキャラクタやプレイヤキャラクタが所有するモンスターキャラクタについてのレベルを示すデータである。所持アイテムデータは、プレイヤキャラクタが所持するアイテムを識別する情報（データ）である。所有キャラクタデータは、プレイヤキャラクタが所有するモンスターキャラクタを識別する情報（データ）である。

図８に戻って、対戦プレイ処理用データ５０４ｇは、対戦プレイモードのゲーム処理で用いられるデータである。図１１に示すように、対戦プレイ処理用データ５０４ｇは、受信データおよび対戦相手データを含む。受信データは、対戦相手のゲーム装置１０から受信したデータである。当該ゲーム装置１０が親機として機能する場合には、受信データは、子機として機能する対戦相手のゲーム装置１０から受信した操作入力データである。一方、ゲーム装置１０が子機として機能する場合には、受信データは、親機として機能する対戦相手のゲーム装置１０から受信した処理結果データである。処理結果データは、親機の操作入力データおよび／または子機からの操作入力データに基づいて対戦プレイモードのゲーム処理を実行した結果についてのデータである。この処理結果データに基づいて、子機は、ゲームパラメータを更新したり、ゲーム画面を更新したりする。対戦相手データは、対戦相手（対戦するプレイヤ）についてのプレイヤＩＤのデータである。

図８に戻って、キャラクタデータ５０４ｈは、この実施例のゲームで使用される各種キャラクタ（プレイヤキャラクタやモンスターキャラクタなど）についてのデータである。マップデータ５０４ｉは、仮想空間にこの実施例のゲーム世界を構築するためのデータである。

自機プレイヤデータ５０４ｊは、ゲーム装置１０を所持するプレイヤ（所有者）について登録されたプレイヤデータである。自機プレイヤデータ５０４ｊの内容は、図９に示したプレイヤデータと同じである。

また、データ記憶領域５０４には、対戦プレイフラグ５０４ｋが設けられる。この対戦プレイフラグ５０４ｋは、対戦プレイ中であるかどうかを判定するためのフラグである。たとえば、対戦プレイフラグ５０４ｋは、１ビットのレジスタで構成され、対戦プレイ中である場合には、レジスタに「１」が設定され、対戦プレイ中でない場合には、レジスタに「０」が設定される。対戦プレイフラグ５０４ｋは、対戦プレイを開始するときにオンされ、対戦プレイを終了するときにオフされる。

図１２は、図３に示したＣＰＵ２０のゲーム全体処理を示すフロー図である。ただし、ローカル通信が選択されている場合のゲーム全体処理が示される。なお、図１２（後述する図１３−図１７についても同様。）に示すフロー図の各ステップの処理は、単なる一例に過ぎず、同様の結果が得られるのであれば、各ステップの処理順序を入れ替えてもよい。また、この実施例では、図１２−図１７に示すフロー図の各ステップの処理をＣＰＵ２０が実行するものとして説明するが、ＣＰＵ２０以外のプロセッサや専用回路が一部のステップを実行するようにしてもよい。

図１２に示すように、ＣＰＵ２０は、ゲーム全体処理を開始すると、ステップＳ１で、初期設定を行う。ここでは、シングルプレイのゲーム世界を構築したり、プレイヤキャラクタなどのキャラクタを初期位置またはセーブした位置に配置したりする。次のステップＳ３では、後述するビーコン送受信処理（図１６および図１７参照）を開始する。つまり、ビーコン送受信処理は、ゲーム全体処理と並行して実行される。

次のステップＳ５では、操作入力データを取得する。ここでは、ＣＰＵ２０は、操作入力データバッファ５０４ｂに記憶された操作データおよび／またはタッチ位置データを取得する。当然のことではあるが、ステップＳ５では、操作入力データバッファ５０４ｂに操作データおよび／またはタッチ位置データが記憶されていない場合には、操作データおよび／またはタッチ位置データを取得せずに、そのままステップＳ７に進む。

続いて、ステップＳ７では、対戦プレイモードかどうかを判断する。ここでは、ＣＰＵ２０は、対戦プレイフラグ５０４ｋがオンであるかどうかを判断する。

ステップＳ７で“ＮＯ”であれば、つまりシングルプレイモードであれば、ステップＳ９で、シングルプレイ処理を実行して、ステップＳ１３に進む。詳細な説明は省略するが、シングルプレイ処理では、シングルプレイのゲーム処理が実行されるとともに、状態通知のビーコン信号を受信したことに応じて、リスト画面１５０の画像データが更新される。したがって、友達、知り合いおよび通りすがりのプレイアに対応するアイコンが追加されたり、アイコンの表示態様が変化さたりする。また、プレイヤの操作に応じて対戦プレイを申し込んだり、他のゲーム装置１０（プレイヤ）から対戦プレイを申し込まれたりする。そして、対戦相手の候補に対戦プレイすることを承諾されたり、対戦相手の候補に対戦プレイすることを承諾したりすることにより、対戦プレイすることについて合意に達すると、対戦プレイすることが決定される。

一方、ステップＳ７で“ＹＥＳ”であれば、つまり対戦プレイモードであれば、ステップＳ１１で、後述する対戦プレイ処理（図１３-図１５参照）を実行して、ステップＳ１３に進む。ステップＳ１３では、表示処理を実行する。この実施例では、ＣＰＵ２０は、第１ＬＣＤ４４および第２ＬＣＤ４６のそれぞれに画像データを出力する。図示は省略するが、このとき、ゲームの音も出力される。

そして、ステップＳ１５で、ゲームを終了するかどうかを判断する。ここでは、ＣＰＵ２０は、プレイヤによってゲームの終了が指示されたかどうかを判断する。ステップＳ１５で“ＮＯ”であれば、つまりゲームを終了しない場合には、ステップＳ５に戻る。一方、ステップＳ１５で“ＹＥＳ”であれば、つまりゲームを終了する場合には、ステップＳ１７で、ビーコン送受信処理を終了して、ゲーム全体処理を終了する。

なお、ステップＳ５−Ｓ１５のスキャンタイムが１フレームで実行される。たとえば、フレームは、画面更新の時間間隔（１／３０秒または１／６０秒）である。

また、上述したように、インターネット通信が選択されている場合には、ゲームの状況が変化するときに、状態通知のデータがサーバ５に送信される。したがって、かかる場合には、図１６および図１７に示すようなビーコン送受信処理は実行されない。また、上述したように、インターネット通信が選択されている場合には、ステップＳ３において、ゲームを開始したことをサーバ５に通知する。具体的には、ゲームＩＤとプレイヤ情報を含む開始通知がサーバ５に送信される。また、ステップＳ１７で、ゲームを終了したことをサーバ５に通知する。具体的には、ゲームＩＤとプレイヤ情報を含む終了通知がサーバ５に送信される。

図１３ないし図１５は、図１２のステップＳ１１に示した対戦プレイ処理のフロー図の一例である。ただし、図１３ないし図１５に示す対戦プレイ処理は、ゲーム装置１０が親機として機能する場合の処理である。図示は省略するが、対戦を開始するのに先立って、ゲーム装置１０は対戦相手のゲーム装置１０との間で通信接続を確立し、初期設定を行う。また、このとき、対戦プレイフラグ５０４ｋがオンされる。初期設定として、ＣＰＵ２０は、対戦プレイのゲーム世界を構築したり、プレイヤキャラクタなどのキャラクタを初期位置に配置したりする。

図１３に示すように、対戦プレイ処理では、ＣＰＵ２０は、ステップＳ３１で、対戦終了かどうかを判断する。ここでは、ＣＰＵ２０は、対戦プレイの勝敗を決定したかどうかを判断する。ステップＳ３１で“ＹＥＳ”であれば、つまり対戦終了であれば、図１４に示すステップＳ４１に進む。一方、ステップＳ３１で“ＮＯ”であれば、つまり対戦終了でなければ、ステップＳ３３で、相手の操作入力データを受信したかどうかを判断する。ステップＳ３３で“ＮＯ”であれば、つまり相手の操作入力データを受信していなければ、そのまま同じステップＳ３３に戻る。一方、ステップＳ３３で“ＹＥＳ”であれば、つまり相手の操作入力データを受信すれば、ステップＳ３５に進む。

なお、この実施例では、ステップＳ３３において、相手の操作入力データを受信しない場合には、そのまま同じステップＳ３３に戻るようにしてあるが、所定時間（たとえば、２〜３秒）経過しても操作入力データを受信しない場合には、ステップＳ３５に進むようにしてもよい。

ステップＳ３５では、対戦プレイについてのゲーム制御処理を実行する。簡単に説明すると、ＣＰＵ２０は、ステップＳ５で取得した自機の操作入力データおよびステップＳ３３で受信（取得）したと判断された相手の操作入力データの少なくとも一方に基づいて、自機のモンスターキャラクタ１０４と相手のモンスターキャラクタを戦闘（攻撃や防御）させる。また、ＣＰＵ２０は、攻撃を受けた側のモンスターキャラクタの体力値を減算する。そして、ＣＰＵ２０は、一方のモンスターキャラクタの体力値が０以下になると、勝敗を決定する。

次のステップＳ３７では、処理結果を対戦相手に送信する。つまり、ＣＰＵ２０は、ステップＳ３５におけるゲーム制御処理の処理結果データを対戦相手のゲーム装置１０に送信する。そして、ステップＳ３９で、ゲーム画面の画像を更新して、図１２に示したゲーム全体処理にリターンする。ＣＰＵ２０は、ステップＳ３９において、ステップＳ３５におけるゲーム制御処理の結果を反映した画像データを生成する。したがって、その後のゲーム全体処理において、ゲーム制御処理の結果を反映したゲーム画面が第１ＬＣＤ４４に表示される。

上述したように、対戦終了であれば、ステップＳ３１で“ＹＥＳ”となり、図１４に示すステップＳ４１で、図７に示したような友達登録画面３００の表示中であるかどうかを判断する。ステップＳ４１で“ＹＥＳ”であれば、つまり友達登録画面３００の表示中であれば、ステップＳ４３で、対戦相手のゲーム装置１０に友達登録を通知したかどうかを判断する。ステップＳ４３で“ＮＯ”であれば、つまり対戦相手のゲーム装置に友達登録を通知していなければ、図１５に示すステップＳ５５に進む。一方、ステップＳ４３で“ＹＥＳ”であれば、つまり対戦相手のゲーム装置１０に友達登録を通知していれば、図１５に示すステップＳ６１に進む。

また、ステップＳ４１で“ＮＯ”であれば、つまり友達登録画面３００の表示中でなければ、ステップＳ４５で、今回の対戦相手が友達のプレイヤであるかどうかを判断する。ここでは、ＣＰＵ２０は、対戦プレイ処理用データ５０４ｇに含まれる対戦相手データが示すプレイヤＩＤを有するプレイヤデータが友達データ５０４ｃ、知り合いデータ５０４ｄおよび通りすがりデータ５０４ｅのいずれに含まれるかを検出し、友達のプレイヤであるかどうかを判断する。なお、後述するステップＳ４９においても同様の処理が実行される。

ステップＳ４５で“ＹＥＳ”であれば、つまり今回の対戦相手が友達のプレイヤであれば、ステップＳ４７で、対戦プレイフラグ５０４ｋをオフして、ゲーム全体処理にリターンする。したがって、その後のゲーム全体処理において、シングルプレイ処理が再開される。一方、ステップＳ４５で“ＮＯ”であれば、つまり今回の対戦相手が友達のプレイヤでなければ、ステップＳ４９で、今回の対戦相手が知り合いのプレイヤであるかどうかを判断する。ステップＳ４９で“ＮＯ”であれば、つまり今回の対戦相手が通りすがりのプレイヤであれば、ステップＳ５１で、今回の対戦相手を知り合いのプレイヤと判断し、当該対戦相手を知り合いのプレイヤに変更してから、ゲーム全体処理にリターンする。ここでは、ＣＰＵ２０は、今回の対戦相手のプレイヤデータを通りすがりデータ５０４ｅから知り合いデータ５０４ｄに移動する。

一方、ステップＳ４９で“ＹＥＳ”であれば、つまり今回の対戦相手が知り合いのプレイヤであれば、ステップＳ５３で、友達登録画面３００の画像データを生成して、ゲーム全体処理にリターンする。したがって、その後のゲーム全体処理において、友達登録画面３００が第２ＬＣＤ４６に表示される。

上述したように、友達登録画面３００が表示中であるが、対戦相手のゲーム装置１０に友達登録を通知していなければ、ステップＳ４３で“ＮＯ”となり、図１５に示すように、ステップＳ５５で、操作が有るかどうかを判断する。ここでは、ＣＰＵ２０は、操作入力データバッファ５０４ｂに、操作データおよび／またはタッチ位置データが記憶されているかどうかを判断する。

ステップＳ５５で“ＮＯ”であれば、つまり操作が無ければ、そのままゲーム全体処理にリターンする。なお、この実施例では、操作が無い場合には、そのままゲーム全体処理にリターンするようにしてあるが、友達登録画面３００が表示されてから所定時間（たとえば、５〜１０秒）を経過しても操作が無い場合には、ステップＳ６７に進むようにしてもよい。

一方、ステップＳ５５で“ＹＥＳ”であれば、つまり操作が有れば、ステップＳ５７で、対戦相手を友達のプレイヤとして登録するかどうかを判断する。ここでは、ＣＰＵ２０は、アイコン３０６またはアイコン３０８がオンされたことを検出して、対戦相手を友達のプレイヤとして登録するかどうかを判断する。

ステップＳ５７で“ＮＯ”であれば、つまりアイコン３０８がオンされれば、対戦相手を友達のプレイヤとして登録しないことが判断され、ステップＳ６７に進む。一方、ステップＳ５７で“ＹＥＳ”であれば、つまりアイコン３０６がオンされれば、対戦相手を友達のプレイヤとして登録することが判断され、ステップＳ５９で、対戦相手が所持（使用）するゲーム装置１０に友達として登録すること（友達登録）を通知する。

続いて、ステップＳ６１では、対戦相手から友達登録の通知があるかどうかを判断する。ステップＳ６１で“ＮＯ”であれば、つまり対戦相手から友達登録の通知が無ければ、ステップＳ６３で、友達登録画面３００を表示したときから所定時間（たとえば、５〜１０秒）を経過したかどうかを判断する。ステップＳ６３で“ＮＯ”であれば、つまり友達登録画面３００を表示したときから所定時間を経過していなければ、そのままゲーム全体処理にリターンする。一方、ステップＳ６３で“ＹＥＳ”であれば、つまり友達登録画面３００を表示したときから所定時間を経過すれば、ステップＳ６７に進む。

また、ステップＳ６１で“ＹＥＳ”であれば、つまり対戦相手から友達登録の通知があれば、友達のプレイヤとして登録することが合意に達したと判断し、ステップＳ６５で、対戦相手を友達のプレイヤとして登録する。ここでは、ＣＰＵ２０は、対戦相手のプレイヤデータを知り合いデータ５０４ｄから友達データ５０４ｃに移動する。そして、ステップＳ６７では、対戦プレイフラグ５０４ｋをオフして、ゲーム全体処理にリターンする。

なお、ここでは、ゲーム装置１０が親機として機能する場合について説明したが、ゲーム装置１０が子機として機能する場合には、ステップＳ３３、Ｓ３５およびＳ３７に代えて、次の処理が実行される。

具体的には、ＣＰＵ２０は、ステップＳ３１で、対戦終了でないと判断すると、ステップＳ５において取得した自機の操作入力データを対戦相手が所持するゲーム装置１０（親機）に送信する。そして、ＣＰＵ２０は、親機から処理結果データを受信したかどうかを判断する。ＣＰＵ２０は、処理結果データを受信しない場合には、処理結果データの受信を待機し、処理結果データを受信すれば、ステップＳ３９で、処理結果データに従ってゲーム画面の画像を更新する。

図１６および図１７は、ビーコン送受信処理を示すフロー図である。ただし、このビーコの送受信処理は、ローカル通信が選択されている場合に実行される。

図１６に示すように、ＣＰＵ２０は、ビーコン送受信処理を開始すると、ステップＳ１０１で、送信カウンタをリセットする。つまり、カウント値が０に設定される。図示等は省略したが、送信カウンタ（後述する「受信カウンタ」も同じ。）は、メインメモリ２２のデータ記憶領域５０４に設けられる。

続くステップＳ１０３で、ビーコン出力処理を実行する。ここでは、ステップＳ４７、Ｓ７７、Ｓ８３、Ｓ９１で生成され、送受信データバッファ５０４ａに登録されたビーコン信号が送信（ブロードキャスト）される。次のステップＳ１０５で、送信カウンタをインクリメントする。つまり、送信カウンタのカウント値が１加算される。そして、ステップＳ１０７で、送信カウンタのカウント値が所定値以上であるかどうかを判断する。なお、所定値は、開発者等によって予め設定される数値である。ステップＳ１２１においても同じである。

ステップＳ１０７で“ＮＯ”であれば、つまり送信カウンタのカウント値が所定値未満であれば、そのままステップＳ１０３に戻る。一方、ステップＳ１０７で“ＹＥＳ”であれば、つまり送信カウンタのカウント値が所定値以上であれば、図１７に示すステップＳ１０９で、受信カウンタをリセットする。つまり、受信カウンタのカウント値が０に設定される。

続くステップＳ１１１では、他のゲーム装置１０からのビーコン信号の受信を試行する。このとき、他のゲーム装置１０からのビーコン信号を受信すると、ＣＰＵ２０は、受信したビーコン信号を送受信データバッファ５０４ａに記憶する。次のステップＳ１１３では、他のゲーム装置１０からのビーコン信号を受信したかどうかを判断する。ここでは、送受信データバッファ５０４ａに他のゲーム装置１０から送信されたビーコン信号が記憶されているかどうかを判断する。

ステップＳ１１３で“ＮＯ”であれば、つまり他のゲーム装置１０からのビーコン信号を受信していなければ、そのままステップＳ１１９に進む。一方、ステップＳ１１３で“ＹＥＳ”であれば、つまり他のゲーム装置１０からのビーコン信号を受信すれば、ステップＳ１１５で、ゲームＩＤが一致するかどうかを判断する。ＣＰＵ２０は、受信したビーコン信号に含まれるゲームＩＤが、自身が実行中のゲームのゲームＩＤと一致するかどうかを判断するのである。

ステップＳ１１５で“ＹＥＳ”であれば、つまりゲームＩＤが一致すれば、そのままステップＳ１１９に進む。一方、ステップＳ１１５で“ＮＯ”であれば、つまりゲームＩＤが一致しない場合には、ステップＳ１１７で、当該ビーコン信号を送受信データバッファ５０４ａから消去して、ステップＳ１１９に進む。

なお、ステップＳ１１１で、複数のビーコン信号を受信した場合には、ステップＳ１１５処理が各ビーコン信号について実行され、その判断結果に応じて、ステップＳ１１７の処理が実行される。

ステップＳ１１９では、受信カウンタをインクリメントする。つまり、受信カウンタのカウント値が１加算される。そして、ステップＳ１２１で、受信カウンタのカウント値が所定値以上であるかどうかを判断する。ステップＳ１２１で“ＮＯ”であれば、つまり受信カウンタのカウント値が所定値未満であれば、ステップＳ１１１に戻る。一方、ステップＳ１２１で“ＹＥＳ”であれば、つまり受信カウンタのカウント値が所定値以上であれば、図１６に示したステップＳ１０１に戻る。

このように、カウンタを用いて、繰り返しビーコン信号を送信したり、繰り返しビーコン信号の受信を試みたりしている。また、カウンタを用いることにより、ビーコン信号を送信する場合（モード）と受信する（受信を試みる）モードとを切り替えている。したがって、状態通知のビーコン信号を送受信する場合には、対戦プレイの候補を探索するモードと、探索されるモード（被探索モード）とが切り替えられる。このようなビーコン信号の送受信処理は、ゲームの全体処理の実行中に繰り返し行われるため、ゲーム装置１０は、対戦プレイの候補である他のゲーム装置１０を繰り返し探索することになる。

この実施例によれば、通りすがりのプレイヤと合意の上で通信することにより、知り合いのプレイヤと判断して、自動的に分類を変更するので、友達のプレイヤとして登録しなくても、その後においてゲーム状況や通信状況を知ることができる。したがって、その後に同じプレイヤと通信したい場合に、知り合いのプレイヤを検索し、現在の状況を把握して、通信を申し込むことができる。つまり、面倒な操作を省いて、コミュニケーションを多様化することができる。

また、この実施例では、ゲームを実行する場合には、少なくとも一度通信した知り合いのプレイヤを友達のプレイヤとして登録するので、直接会うことが困難なプレイヤであっても、通信を重ねることにより、親密度や信頼度を高めて、友達のプレイヤとして登録することができる。また、通りすがりのプレイヤのように、どのようなプレイヤであるかを全く知らないプレイヤを友達として登録することを防止することができる。ただし、通りすがりのプレイヤとの合意に基づいて、知り合いを経ることなく、友達のプレイヤとして登録可能な構成としてもよい。

さらに、この実施例では、一度通信を行ったプレイヤを、通りすがりのプレイヤから知り合いのプレイヤに変更するようにしたが、これに限定される必要はない。通信の回数は、２回以上の所定回数でもよい。また、通信の回数のみならず、期間を定めてもよい。たとえば、一週間に２回以上通信した場合に、通りすがりのプレイヤから知り合いのプレイヤに変更するようにしてもよい。

また、この実施例では、知り合いのプレイヤとの間で対戦プレイを行った後に、相互認証することにより、友達のプレイヤとして登録するようにしたが、対戦プレイを行わずに、相互認証することにより、友達のプレイヤとして登録してもよい。

なお、上述の実施例では、ゲーム装置のような情報処理装置のプレイヤを友達のプレイヤとして登録する場合について説明した。上述の実施例で示した友達のプレイヤとして登録する方法は、ＳＮＳ(Social Networking Service)を提供するウェブサイトにおいて友達またはそれに準ずる関係（以下、「友達等」という。）として他のユーザを登録する場合にも適用することができる。かかる場合には、たとえば、検索機能を用いて検索された他のユーザ、自身のプロフィール情報（出身地、居住地、出身校など）を用いて検索された他のユーザ、または自身が友達等として登録した他のユーザが友達等として登録している他のユーザが、上記の実施例のように、通りすがりまたはそれに準ずる関係（以下、「通りすがり等」という。）のユーザとして判断される。たとえば、通りすがり等のユーザと通信（メッセージの送受信）を行うと、上述の実施例のように、当該通りすがり等のユーザは、知り合いまたはそれに準ずる関係（以下、「知り合い等」という。）のユーザとして判断される。そして、知り合い等のユーザとの間で相互認証することにより、友達等のユーザとして登録するようにすることができる。

また、上述の実施例で説明したように、この実施例の通信ゲームシステムでは３台以上のゲーム装置で対戦プレイすることもできる。かかる場合において、知り合いのプレイヤが複数人存在するときには、対戦終了後に、複数人のそれぞれについて友達登録画面が表示されたり、複数人のそれぞれを選択可能な１つの友達登録画面が表示されたりする。そして、個別に友達のプレイヤとして登録するか否かが選択される。

さらに、この実施例では、ローカル通信およびインターネット通信が可能な携帯型のゲーム装置を用いた場合について説明したが、インターネット通信が可能な据置型のゲーム装置を用いることもできる。

さらにまた、ゲーム装置の構成は実施例のものに限定される必要はない。たとえば、表示装置（ＬＣＤ）は、１つのＬＣＤを２つの表示領域に分けて使用してもよい。また、タッチパネルは、第１ＬＣＤ上に、または、第１ＬＣＤ上および第２ＬＣＤ上の両方に設けてもよい。または、タッチパネルは設けなくてもよい。さらには、ゲーム装置は、ＧＰＳ機能を備えてもよい。かかる場合には、近距離に（所定範囲内に）存在する他のゲーム装置を、実際の距離に基づいて検出することができる。

なお、上述の実施例で示した具体的な数値は単なる一例であり、実際の製品に応じて適宜変更される。

１ …通信ゲームシステム
１０ …ゲーム装置
２０ …ＣＰＵ
２２ …メインメモリ
２４ …メモリ制御回路
２６ …保存用データメモリ
２８ …インターネット通信モジュール
３０ …ローカル通信モジュール
３２ …入力装置
３４、４２ …ＧＰＵ
３６、４０ …ＶＲＡＭ
３８ …ＬＣＤコントローラ
４４、４６ …ＬＣＤ

Claims (14)

1. 他の情報処理装置と通信する通信部と、
   前記他の情報処理装置の情報を表示する表示部と、
   前記通信部によって他の情報処理装置と通信したことに応じて、当該他の情報処理装置を自動的に第１分類として判断する第１分類判断部とを備え、
   前記表示部は、前記第１分類判断部によって前記第１分類として判断された他の情報処理装置の情報を当該他の情報処理装置の通信状況に応じた態様で表示する、情報処理装置。
2. 前記他の情報処理装置との間で相互認証することにより、当該他の情報処理装置を前記第１分類とは異なる第２分類として登録する第２分類登録部をさらに備える、請求項１記載の情報処理装置。
3. 前記第２分類登録部は、前記第１分類判断部によって前記第１分類と判断された他の情報処理装置との間で相互認証することにより、当該他の情報処理装置を前記第２分類として登録する、請求項２記載の情報処理装置。
4. 前記第１分類の他の情報処理装置と前記第２分類の他の情報処理装置とでは、前記通信部を用いて通信する場合に実行可能な機能の少なくとも一部が異なる、請求項２または３記載の情報処理装置。
5. 前記表示部は、前記第１分類と前記第２分類とを識別可能な態様で前記他の情報処理装置の情報を表示する、請求項２ないし４のいずれかに記載の情報処理装置。
6. 前記通信部が前記他の情報処理装置からの通信リクエストを受信したとき、当該他の情報処理装置の情報を、当該他の情報処理装置が少なくとも第１分類または第２分類であるか否かを識別可能な態様で通知するリクエスト通知部をさらに備える、請求項２ないし５のいずれかに記載の情報処理装置。
7. 前記通信部は、自機のユーザと前記他の情報処理装置のユーザとの間の合意に基づいて通信する、請求項１ないし６のいずれかに記載の情報処理装置。
8. 前記他の情報処理装置は、前記通信部を用いて探索した不特定の他の情報処理装置である、請求項１ないし７のいずれかに記載の情報処理装置。
9. 前記通信部は、近距離無線通信により前記不特定の他の情報処理装置を探索する、請求項８記載の情報処理装置。
10. 前記通信部は、インターネット通信により前記不特定の他の情報処理装置を探索する、請求項８記載の情報処理装置。
11. 前記通信部は、前記不特定の他の情報処理装置を繰り返し探索し、
    前記通信部の探索結果に応じて前記他の情報処理装置の通信状況を更新する更新部をさらに備える、請求項７ないし１０のいずれかに記載の情報処理装置。
12. 他の情報処理装置と通信する通信部と、
    前記他の情報処理装置の情報を表示する表示部と、
    前記通信部によって他の情報処理装置と通信したことに応じて、当該他の情報処理装置を自動的に第１分類として判断する第１分類判断部を備え、
    前記表示部は、前記第１分類判断部によって前記第１分類として判断された他の情報処理装置の情報を当該他の情報処理装置の通信状況に応じた態様で表示する、情報処理システム。
13. 他の情報処理装置と通信する通信手段を備えるコンピュータによって実行される情報処理プログラムであって、
    前記コンピュータを、
    前記他の情報処理装置の情報を表示手段に表示する表示制御部と、
    前記通信手段によって他の情報処理装置と通信したことに応じて、当該他の情報処理装置を自動的に第１分類として判断する第１分類判断部として機能させ、
    前記表示制御部は、前記第１分類判断部において前記第１分類として判断した他の情報処理装置の情報を当該他の情報処理装置の通信状況に応じた態様で前記表示手段に表示する、情報処理プログラム。
14. 他の情報処理装置と通信する通信手段を備えるコンピュータの情報処理方法であって、
    前記コンピュータは、
    （ａ）前記通信手段によって他の情報処理装置と通信したことに応じて、当該他の情報処理装置を自動的に第１分類として判断し、そして
    （ｂ）前記ステップ（ａ）において前記第１分類として判断した他の情報処理装置の情報を当該他の情報処理装置の通信状況に応じた態様で表示手段に表示する、情報処理方法。

Images