以下、本発明の実施の形態について、図面を参照して説明する。尚、この実施例により本発明が限定されるものではない。
図1は、本実施形態にかかる広場アプリケーション(以下、広場アプリ)等を実行するゲーム装置1の外観図である。ここでは、ゲーム装置1の一例として、携帯ゲーム装置を示す。図1において、ゲーム装置1は、折り畳み型の携帯ゲーム装置であり、開いた状態(開状態)のゲーム装置1を示している。ゲーム装置1は、開いた状態においてもユーザが両手または片手で把持することができるようなサイズで構成される。
ゲーム装置1は、下側ハウジング11および上側ハウジング21を有する。下側ハウジング11と上側ハウジング21とは、開閉可能(折り畳み可能)に連結されている。図1の例では、下側ハウジング11および上側ハウジング21は、それぞれ横長の長方形の板状で形成され、互いの長辺部分で回転可能に連結されている。通常、ユーザは、開状態でゲーム装置1を使用する。また、ユーザは、ゲーム装置1を使用しない場合には閉状態としてゲーム装置1を保管する。また、図1に示した例では、ゲーム装置1は、上記閉状態および開状態のみでなく、下側ハウジング11と上側ハウジング21とのなす角度が閉状態と開状態との間の任意の角度において、連結部分に発生する摩擦力などによってその開閉角度を維持することができる。つまり、上側ハウジング21を下側ハウジング11に対して任意の角度で静止させることができる。
下側ハウジング11には、下側LCD(Liquid Crystal Display:液晶表示装置)12が設けられる。下側LCD12は横長形状であり、長辺方向が下側ハウジング11の長辺方向に一致するように配置される。なお、本実施形態では、ゲーム装置1に内蔵されている表示装置としてLCDを用いているが、例えばEL(Electro Luminescence:電界発光)を利用した表示装置等、他の任意の表示装置を利用してもよい。また、ゲーム装置1は、任意の解像度の表示装置を利用することができる。なお、詳細は後述するが、下側LCD12は、主に、内側カメラ23または外側カメラ25で撮影されている画像をリアルタイムに表示するために用いられる。
下側ハウジング11には、入力装置として、各操作ボタン14A〜14Kおよびタッチパネル13が設けられる。図1に示されるように、各操作ボタン14A〜14Kのうち、方向入力ボタン14A、操作ボタン14B、操作ボタン14C、操作ボタン14D、操作ボタン14E、電源ボタン14F、スタートボタン14G、およびセレクトボタン14Hは、上側ハウジング21と下側ハウジング11とを折りたたんだときに内側となる、下側ハウジング11の内側主面上に設けられる。方向入力ボタン14Aは、例えば選択操作等に用いられる。各操作ボタン14B〜14Eは、例えば決定操作やキャンセル操作等に用いられる。電源ボタン14Fは、ゲーム装置1の電源をオン/オフするために用いられる。図1に示す例では、方向入力ボタン14Aおよび電源ボタン14Fは、下側ハウジング11の内側主面中央付近に設けられる下側LCD12に対して、左右一方側(図1では左側)の当該主面上に設けられる。また、操作ボタン14B〜14E、スタートボタン14G、およびセレクトボタン14Hは、下側LCD12に対して左右他方側(図1では右側)となる下側ハウジング11の内側主面上に設けられる。方向入力ボタン14A、操作ボタン14B〜14E、スタートボタン14G、およびセレクトボタン14Hは、ゲーム装置1に対する各種操作を行うために用いられる。
なお、図1においては、操作ボタン14I〜14Kの図示を省略している。例えば、Lボタン14Iは、下側ハウジング11の上側面の左端部に設けられ、Rボタン14Jは、下側ハウジング11の上側面の右端部に設けられる。Lボタン14IおよびRボタン14Jは、ゲーム装置1に対して、例えば撮影指示操作(シャッター操作)を行うために用いられる。さらに、音量ボタン14Kは、下側ハウジング11の左側面に設けられる。音量ボタン14Kは、ゲーム装置1が備えるスピーカの音量を調整するために用いられる。
また、ゲーム装置1は、各操作ボタン14A〜14Kとは別の入力装置として、さらにタッチパネル13を備えている。タッチパネル13は、下側LCD12の画面上を覆うように装着されている。なお、本実施形態では、タッチパネル13は、例えば抵抗膜方式のタッチパネルが用いられる。ただし、タッチパネル13は、抵抗膜方式に限らず、任意の押圧式のタッチパネルを用いることができる。また、本実施形態では、タッチパネル13として、例えば下側LCD12の解像度と同解像度(検出精度)のものを利用する。ただし、必ずしもタッチパネル13の解像度と下側LCD12の解像度とが一致している必要はない。また、下側ハウジング11の右側面には、挿入口(図1に示す破線)が設けられている。挿入口は、タッチパネル13に対する操作を行うために用いられるタッチペン27を収納することができる。なお、タッチパネル13に対する入力は、通常タッチペン27を用いて行われるが、タッチペン27に限らずユーザの指でタッチパネル13を操作することも可能である。
また、下側ハウジング11の右側面には、メモリカード28を収納するための挿入口(図1では、二点鎖線で示している)が設けられている。この挿入口の内側には、ゲーム装置1とメモリカード28とを電気的に接続するためのコネクタ(図示せず)が設けられる。メモリカード28は、例えばSD(Secure Digital)メモリカードであり、コネクタに着脱自在に装着される。メモリカード28は、例えば、ゲーム装置1によって撮影された画像を記憶(保存)したり、他の装置で生成された画像をゲーム装置1に読み込んだりするために用いられる。
さらに、下側ハウジング11の上側面には、カートリッジ29を収納するための挿入口(図1では、一点鎖線で示している)が設けられている。この挿入口の内側にも、ゲーム装置1とカートリッジ29とを電気的に接続するためのコネクタ(図示せず)が設けられる。カートリッジ29はゲームプログラム等を記録した記録媒体であり、下側ハウジング11に設けられた挿入口に着脱自在に装着される。
下側ハウジング11と上側ハウジング21との連結部の左側部分には、3つのLED15A〜15Cが取り付けられる。ここで、ゲーム装置1は、他の機器との間で無線通信を行うことが可能であり、第1LED15Aは、ゲーム装置1の電源がオンである場合に点灯する。第2LED15Bは、ゲーム装置1の充電中に点灯する。第3LED15Cは、無線通信が確立している場合に点灯する。したがって、3つのLED15A〜15Cによって、ゲーム装置1の電源のオン/オフ状況、充電状況、および、通信確立状況をユーザに通知することができる。
一方、上側ハウジング21には、上側LCD22が設けられる。上側LCD22は横長形状であり、長辺方向が上側ハウジング21の長辺方向に一致するように配置される。なお、下側LCD12と同様、上側LCD22に代えて、他の任意の方式および任意の解像度の表示装置を利用してもよい。なお、上側LCD22上を覆うように、タッチパネルを設けてもかまわない。例えば、上側LCD22には、ユーザに各操作ボタン14A〜14Kやタッチパネル13の役割を教えるための、操作説明画面が表示される。
また、上側ハウジング21には、2つのカメラ(内側カメラ23および外側カメラ25)が設けられる。図1に示されるように、内側カメラ23は、上側ハウジング21の連結部付近の内側主面に取り付けられる。一方、外側カメラ25は、内側カメラ23が取り付けられる内側主面の反対側の面、すなわち、上側ハウジング21の外側主面(ゲーム装置1が閉状態となった場合に外側となる面であり、図1に示す上側ハウジング21の背面)に取り付けられる。なお、図1においては、外側カメラ25を破線で示している。これによって、内側カメラ23は、上側ハウジング21の内側主面が向く方向を撮影することが可能であり、外側カメラ25は、内側カメラ23の撮影方向の逆方向、すなわち、上側ハウジング21の外側主面が向く方向を撮影することが可能である。このように、本実施形態では、2つの内側カメラ23および外側カメラ25の撮影方向が互いに逆方向となるように設けられる。例えば、ユーザは、ゲーム装置1からユーザの方を見た景色を内側カメラ23で撮影することができるとともに、ゲーム装置1からユーザの反対側の方向を見た景色を外側カメラ25で撮影することができる。
なお、上記連結部付近の内側主面には、音声入力装置としてマイク(図2に示すマイク42)が収納されている。そして、上記連結部付近の内側主面には、マイク42がゲーム装置1外部の音を検知できるように、マイクロフォン用孔16が形成される。マイク42を収納する位置およびマイクロフォン用孔16の位置は必ずしも上記連結部である必要はなく、例えば下側ハウジング11にマイク42を収納し、マイク42を収納位置に対応させて下側ハウジング11にマイクロフォン用孔16を設けるようにしても良い。
また、上側ハウジング21の外側主面には、第4LED26(図1では、破線で示す)が取り付けられる。第4LED26は、外側カメラ25によって撮影が行われた(シャッターボタンが押下された)時点で点灯する。また、外側カメラ25によって動画が撮影される間点灯する。第4LED26によって、ゲーム装置1による撮影が行われた(行われている)ことを撮影対象者や周囲に通知することができる。
また、上側ハウジング21の内側主面中央付近に設けられる上側LCD22に対して、左右両側の当該主面に音抜き孔24がそれぞれ形成される。音抜き孔24の奥の上側ハウジング21内にはスピーカが収納されている。音抜き孔24は、スピーカからの音をゲーム装置1の外部に放出するための孔である。
以上に説明したように、上側ハウジング21には、画像を撮影するための構成である内側カメラ23および外側カメラ25と、例えば撮影の際に操作説明画面を表示する表示手段である上側LCD22とが設けられる。一方、下側ハウジング11には、ゲーム装置1に対する操作入力を行うための入力装置(タッチパネル13および各ボタン14A〜14K)と、ゲーム画面を表示するための表示手段である下側LCD12とが設けられる。したがって、ゲーム装置1を使用する際には、ユーザは、下側LCD12に表示される撮影画像(カメラによって撮影された画像)を見ながら、下側ハウジング11を把持して入力装置に対する入力を行うことができる。
次に、図2を参照して、ゲーム装置1の内部構成を説明する。なお、図2は、ゲーム装置1の内部構成の一例を示すブロック図である。
図2において、ゲーム装置1は、CPU31、メインメモリ32、メモリ制御回路33、保存用データメモリ34、プリセットデータ用メモリ35、メモリカードインターフェース(メモリカードI/F)36およびカートリッジI/F44、無線通信モジュール37、ローカル通信モジュール38、リアルタイムクロック(RTC)39、電源回路40、およびインターフェース回路(I/F回路)41等の電子部品を備えている。これらの電子部品は、電子回路基板上に実装されて、下側ハウジング11(または上側ハウジング21でもよい)内に収納される。
CPU31は、所定のプログラムを実行するための情報処理手段である。なお、CPU31によって実行されるプログラムは、ゲーム装置1内の保存用データメモリ34に予め記憶されていてもよいし、メモリカード28および/またはカートリッジ29から取得されてもよいし、他の機器との通信によって他の機器から取得されてもよい。例えば、インターネットを経由して所定のサーバからダウンロードすることで取得しても良いし、据置型ゲーム装置と通信を行うことで、当該据置型ゲーム装置に記憶されている所定のプログラムをダウンロードすることで取得しても良い。
CPU31には、メインメモリ32、メモリ制御回路33、およびプリセットデータ用メモリ35が接続される。また、メモリ制御回路33には、保存用データメモリ34が接続される。メインメモリ32は、CPU31のワーク領域やバッファ領域として用いられる記憶手段である。本実施形態では、メインメモリ32として、例えばPSRAM(Pseudo−SRAM)を用いる。保存用データメモリ34は、CPU31によって実行されるプログラムや内側カメラ23および外側カメラ25によって撮影された画像のデータ等を記憶するための記憶手段である。保存用データメモリ34は、不揮発性の記憶媒体によって構成されており、例えば本実施例ではNAND型フラッシュメモリで構成される。メモリ制御回路33は、CPU31の指示に従って、保存用データメモリ34に対するデータの読み出しおよび書き込みを制御する回路である。プリセットデータ用メモリ35は、ゲーム装置1において予め設定される各種パラメータ等のデータ(プリセットデータ)を記憶するための記憶手段である。プリセットデータ用メモリ35としては、SPI(Serial Peripheral Interface)バスによってCPU31と接続されるフラッシュメモリを用いることができる。
メモリカードI/F36は、CPU31に接続される。メモリカードI/F36は、コネクタに装着されたメモリカード28に対するデータの読み出しおよび書き込みを、CPU31の指示に応じて行う。本実施形態では、外側カメラ25によって撮像された画像データがメモリカード28に書き込まれたり、メモリカード28に記憶された画像データがメモリカード28から読み出されて保存用データメモリ34に記憶されたりする。
カートリッジI/F44はCPU31に接続される。カートリッジI/F44は、コネクタに装着されたカートリッジ29に対するデータの読み出しおよび書き込みをCPU31の指示に従って行う。本実施形態では、情報処理装置10が実行することが可能なアプリケーションプログラムがカートリッジ29から読み出されてCPU31によって実行されたり、当該アプリケーションプログラムに関するデータ(例えばゲームのセーブデータ等)がカートリッジ29に書き込まれたりする。
なお、本発明にかかる広場アプリ処理のプログラムは、本ゲーム装置1のプリインストールアプリとして予め保存用データメモリ34に記憶された状態であることを前提とするが、有線または無線の通信回線を通じてコンピュータシステムに供給されてもよい。
無線通信モジュール37は、例えばIEEE802.11.b/gの規格に準拠した方式により、無線LANに接続する機能を有する。また、ローカル通信モジュール38は、所定の通信方式により同種のゲーム装置との間で無線通信を行う機能を有する。無線通信モジュール37およびローカル通信モジュール38は、CPU31に接続される。CPU31は、無線通信モジュール37を用いてインターネットを介して他の機器との間でデータを送受信することができる。また、CPU31は、ローカル通信モジュール38を用いて同種の他のゲーム装置との間でデータを送受信したりすることができる。例えば、CPU31は、ローカル通信モジュール38を用いて、近距離無線通信による通信範囲内(例えば、機器間の距離が数十メートル)にある他のゲーム装置を繰り返し探索して自動的に無線接続し、無線接続した他のゲーム装置に対してデータを自動的に送信するとともに、無線接続した他のゲーム装置から送信されるデータを自動的に受信することができる。
また、CPU31には、RTC39および電源回路40が接続される。RTC39は、時間をカウントしてCPU31に出力する。例えば、CPU31は、RTC39によって計時された時間に基づいて、現在時刻(日付)等を計算することもできる。電源回路40は、ゲーム装置1が有する電源(典型的には電池であり、下側ハウジング11に収納される)から供給される電力を制御し、ゲーム装置1の各部品に電力を供給する。
ここで、本実施形態では、電源が落とされていないときのゲーム装置1の動作状態として、「通常動作モード」と「スリープモード」とよばれる2つの状態がある。「通常モード」は、ゲーム装置1が開いており、ゲーム装置1を構成する部品の全てに電力が供給されている状態である。つまり、ユーザがゲーム装置1を直接操作しているような状態である。「スリープモード」は、ゲーム装置1が閉じられた(折り畳んだ)状態であるが、CPU31等の一部の構成部品には電力が供給されている状態であり、ユーザは直接的にはゲーム装置1に対して操作は行っていないが、CPU31による処理は可能な状態である。本実施形態では、この「スリープモード」中に、上記ローカル通信モジュール38を利用した「すれちがい通信」と呼ばれる通信が行われる(詳細は後述する)。
また、ゲーム装置1は、マイク42およびアンプ43を備えている。マイク42およびアンプ43は、それぞれI/F回路41に接続される。マイク42は、ゲーム装置1に向かって発声されたユーザの音声を検知して、当該音声を示す音声信号をI/F回路41に出力する。アンプ43は、I/F回路41から音声信号を増幅してスピーカ(図示せず)から出力させる。I/F回路41は、CPU31に接続される。
また、タッチパネル13は、I/F回路41に接続される。I/F回路41は、マイク42およびアンプ43(スピーカ)の制御を行う音声制御回路と、タッチパネル13の制御を行うタッチパネル制御回路とを含む。音声制御回路は、音声信号に対するA/D変換およびD/A変換を行ったり、音声信号を所定の形式の音声データに変換したりする。タッチパネル制御回路は、タッチパネル13からの信号に基づいて所定の形式のタッチ位置データを生成してCPU31に出力する。例えば、タッチ位置データは、タッチパネル13の入力面に対して入力が行われた位置の座標を示すデータである。なお、タッチパネル制御回路は、タッチパネル13からの信号の読み込み、および、タッチ位置データの生成を所定時間に1回の割合で行う。CPU31は、I/F回路41を介して、タッチ位置データを取得することにより、タッチパネル13に対して入力が行われた位置を知ることができる。
操作ボタン14は、上記各操作ボタン14A〜14Kから構成され、CPU31に接続される。操作ボタン14からCPU31へは、各操作ボタン14A〜14Kに対する入力状況(押下されたか否か)を示す操作データが出力される。CPU31は、操作ボタン14から操作データを取得することによって、操作ボタン14に対する入力に応じた処理を実行する。
内側カメラ23および外側カメラ25は、それぞれCPU31に接続される。内側カメラ23および外側カメラ25は、CPU31の指示に応じて画像を撮影し、撮影した画像データをCPU31に出力する。本実施形態では、CPU31は、内側カメラ23および外側カメラ25のいずれか一方に対して撮影指示を行い、撮影指示を受けたカメラが画像を撮影して画像データをCPU31に送る。
また、下側LCD12および上側LCD22は、それぞれCPU31に接続される。下側LCD12および上側LCD22は、それぞれCPU31の指示に従って画像を表示する。
以下、本実施形態で想定する広場アプリ等の処理の概要について説明する。まず、広場アプリ等の処理の内容の説明に先立ち、この処理の前提となる「すれちがい通信」の概要について説明する。図3および図4は、本実施形態におけるすれちがい通信について説明するための図である。本実施形態では、保存用データメモリ34の中に、すれちがい通信専用の記憶領域を設ける。当該領域は、複数の「スロット」と呼ばれる単位で論理的に分けられる。このスロットの一つ一つが、所定の1つのアプリと対応付けられる。各スロットには、「送信ボックス」「受信ボックス」「アプリID」というデータが記憶される。このうち、アプリIDが、当該スロットに対応するアプリを識別するためのデータである。送信ボックスには、すれちがい通信において他のゲーム装置に送信するためのデータが格納され、受信ボックスには、すれちがい通信において他のゲーム装置から受信したデータが格納される。
本実施形態では、すれちがい通信は、ゲーム装置1を上記スリープモードにしている間に行われるものとする。例えば、ユーザが、ゲーム装置を閉じた状態にして所持したまま外出したような場合に、ゲーム装置を同様の状態にして所持している他のユーザとすれ違った場合に、以下のような通信が行われる。まず、上記のようなスリープモード中において、各ゲーム装置1からは所定の周期でビーコン信号が発信される。また、互いに自機の通信可能範囲内に存在する他のゲーム装置を検出しあっている。そして、他のゲーム装置1が検知されたとき、いずれかのゲーム装置1が主導する形で、ゲーム装置間ですれちがい通信用のリンク(以下、このようなゲーム装置1同士での直接的な通信を「ローカル通信」と呼ぶ)が確立される。そして、ローカル通信が可能な状態となれば、ゲーム装置間で同じアプリIDが登録されたスロットの有無が判断される、そして、同じアプリIDを有するスロットが双方に存在すれば、図4に示すように、このスロットの送信ボックス内のデータが互いに送信される。相手側のゲーム装置1から送信されたデータは、受信ボックスに格納される。このようにして他のゲーム装置1から受信し、受信ボックスに格納されたデータについては、対応するアプリの起動時に当該受信ボックスから取得され、各アプリにおいて適宜用いられることになる。
次に、本実施形態にかかるアプリケーションの処理概要を説明する。本実施形態にかかるアプリケーションには、主に、「ユーザキャラクタ作成アプリ」と「広場アプリ」の2つがある。これらは、ゲーム装置1の基本的なメニュー画面であるホームメニューからユーザによって選択されることで適宜実行される(例えば、これらのアプリを示す各アイコンがユーザによって選択されることで実行開始される)。
ユーザキャラクタ作成アプリは、「ユーザキャラクタ」と呼ばれるキャラクタをユーザに生成させるためのアプリケーションである。本実施形態においては、ユーザキャラクタは複数のパーツによって構成されており、このパーツは、例えば、「目」、「鼻」、「口」、「輪郭」、「髪型」等に分類されている。そして、各分類毎に予め複数のパーツが用意されてゲーム装置1に記憶されている。ユーザは、当該ユーザキャラクタ作成アプリで各種パーツを組みあわせる操作を行うことで、例えば、ユーザの顔に似ている顔を有するユーザキャラクタを生成することができる。そして、当該ユーザキャラクタ作成アプリで生成されたユーザキャラクタは、保存用データメモリ34に保存される。なお、このユーザキャラクタは、複数体生成して保存することも可能である。また、一旦作成したユーザキャラクタの外見等を編集(例えばパーツを異なるものに変更)することも可能である。
一方、「広場アプリ」は、上記ユーザキャラクタをコレクションすることを主目的としたアプリである。ユーザキャラクタの収集は、上記すれちがい通信によって行われる。具体的には、上記ユーザキャラクタ作成アプリによって生成されたユーザキャラクタを、上述したようなすれちがい通信によって、他のゲーム装置1に送信すると共に、他のユーザが作成したユーザキャラクタを受信する。これにより、上記すれちがい通信が繰り返されることで、他のユーザが作成したユーザキャラクタを収集することが可能となる。そして、当該広場アプリにおいて、他のユーザの作ったユーザキャラクタを閲覧したり、自分と他のユーザのユーザキャラクタを用いた所定のミニゲーム等を実行することができる。また、このミニゲームでは、例えば、ユーザキャラクタの外観を変更することのできる「アクセサリ」のようなパーツを入手することが可能となっている。
ここで、当該広場アプリでは、自己の作成したユーザキャラクタと上記すれちがい通信で取得した他のユーザキャラクタとの間で「あいさつ」させることが可能である。以下、このあいさつにかかる処理を「あいさつ処理」と呼ぶ。更に、当該広場アプリでは、他のユーザキャラクタを「評価」し、その結果を相手に伝えることも可能となっている。本実施形態では、この評価対象について、他のユーザキャラクタの外観についての評価を行うものとする。以下では、この評価にかかる処理を「評価処理」と呼ぶ。以下、これらの処理を含めた、広場アプリの動作の流れの全体的な概要を説明する。
典型的な処理の流れとしては、以下のような流れを想定する。まず、広場アプリの初期設定として、すれちがい通信で用いるユーザキャラクタがユーザの操作によって登録される。本実施形態では、すれちがい通信で送受信することが可能なユーザキャラクタの数は1体のみであるとする。その後、ユーザがゲーム装置1をスリープモードにした状態で所持し、外出する。外出中に、何人かの他のユーザ(より正確には、広場アプリについてのすれちがい通信の設定が済んでいるユーザ)とすれ違うことで、上記のようなすれちがい通信(ユーザキャラクタの送受信)が何度か発生する。その後、外出を終えて帰って来たユーザが再度広場アプリを起動すると、「新着通知」として、今回の外出中に行われたすれちがい通信の回数等が示される。そして、今回の外出中に取得された他のユーザキャラクタについて、1体ずつ順番に、後述するような「あいさつ処理」と「評価処理」が行われる。そして、今回の外出中に取得された他のユーザキャラクタ全てに対しての「あいさつ処理」と「評価処理」が終われば、広場アプリのメイン画面が表示される、という流れとなる。換言すれば、本実施形態で説明する「あいさつ処理」と「評価処理」は、上記ゲーム装置をスリープモードにしてから、次に広場アプリが起動されるまでに上記すれちがい通信で取得された他のユーザキャラクタ(いわば新着のユーザキャラクタ)を対象として行われる処理である。以下、各処理の概要について説明する。
[広場アプリの初期設定]
まず、上記広場アプリが初めて起動されると(初回起動時)、当該広場アプリについての初期設定処理が自動的に開始される。この処理においては、当該広場アプリの内容についての簡単な紹介が行われた後、上記すれちがい通信に関する設定、および、上記あいさつ処理において使用される「共通あいさつ」の作成(具体的には文字列の入力)が行われる。
当該設定項目についてより具体的に説明する。上記すれちがい通信に関する主な設定項目としては、「すれちがい通信自体を行うか否か」という設定項目、「あいさつ処理を行うか否か」という設定項目、「評価処理を行うか否か」という設定項目、そして、すれちがい通信で用いるユーザキャラクタの選択、という設定項目がある。これらの設定項目については、当該初期設定処理において、各設定項目について「行う」「行わない」をユーザに問いかける画面を表示し、これに対するユーザの入力によって設定される。
本実施形態では、「すれちがい通信自体を行うか否か」という設定項目については、「行う」という設定にする。その結果、上述したようなすれちがい通信用のスロット(上記図3参照)のいずれか一つと当該広場アプリとが関連づけられる。具体的には、当該広場アプリを示すアプリIDが上記いずれかのスロットのアプリIDに記憶されることで、スロットと広場アプリとの関連付けが行われることになる。更に、すれちがい通信において送信対象となるユーザキャラクタの選択も行われる。具体的には、ユーザキャラクタの一覧画面等が表示され、ユーザがいずれかのユーザキャラクタを選択する操作を行うことで、すれちがい通信すれちがい通信で用いるユーザキャラクタが選択されることになる。なお、もし上記スロットの全てが既に他のアプリで用いられていた場合は、その旨を知らせるメッセージが適宜表示され、この時点では関連付けは行われない。いずれかのスロットが開放された後に、再度当該関連付けの設定が行われることになる。また、ユーザキャラクタが1体も作成されていない場合は、上記ユーザキャラクタの選択の際にその旨を示すメッセージと、上記ユーザキャラクタ作成アプリを用いてユーザキャラクタの作成を促す旨のメッセージが適宜表示される。
「あいさつ処理を行うか否か」という設定項目、および、「評価処理を行うか否か」という設定項目については、本実施形態では、自分側も相手側も共に「行う」と設定されている場合を例として説明する。ここで、本実施形態では、自分側と相手側の双方がこれらの設定項目を「行う」と設定している場合にのみ、あいさつ処理や評価処理が行われる。つまり、あいさつ処理についていずれか一方で「行わない」という設定がされていた場合は、あいさつ処理は行われない。また、「評価処理」についていずれか一方で「行わない」という設定がされていた場合は、評価処理は行われない。これは、いずれか一方が「あいさつ処理」を行うことを望まない場合や、「評価」されることを望まない場合にまで、強制的にあいさつや評価を行うことでユーザに不快感を与えないようにするためである。そのため、例えば、いずれか一方の側が、あいさつ処理については「行う」と設定しているが、評価処理については「行わない」と設定しているような場合は、あいさつ処理は行われるが、評価処理については行われないことになる。
次に、上記「共通あいさつ」の作成の説明に際し、本実施形態のあいさつ処理で用いられる「あいさつ」全般について説明する。本実施形態のあいさつ処理では、すれちがい通信で受信した他のユーザキャラクタと自己のユーザキャラクタとの間で「あいさつ」するような処理が行われる。この「あいさつ」として、本実施形態では2種類のあいさつが定義されている。1つめは、「共通あいさつ」と呼ばれる種類のあいさつであり、2つめは「個別あいさつ」と呼ばれる種類のあいさつである。「共通あいさつ」は、不特定多数の他のユーザ(他のゲーム装置1)に対してのあいさつ、という位置づけである。つまり、相手を特に指定しないで、無差別に行われるあいさつである。また、例えば、あるグループに属している全体(全員)に対してのあいさつも「共通あいさつ」である。また、この「共通あいさつ」は、ある属性を有する多数の相手向けのあいさつであってもよい。例えば、性別が「男」である他のユーザキャラクタに向けてのあいさつであってもよい。一方、「個別あいさつ」は、ある特定のユーザ(ゲーム装置1)に向けたあいさつ、という位置づけである。つまり、ユーザが個別の相手に対して行うことを意図しているあいさつである。換言すれば、(送信側のユーザの意図としては)あいさつする相手を指定・指名したあいさつである。そして、本実施形態では、基本的には「共通あいさつ」が用いられるが、2回以上すれちがい通信が行われたユーザに対しては、「個別あいさつ」を行うことも可能となる。つまり、初対面の相手に対しては「共通あいさつ」のみ利用できるが、2回以上すれ違ったことがある相手に対しては、「共通あいさつ」および「個別あいさつ」のいずれかを選択して利用可能となる。これは、2回もすれ違う(すれちがい通信が行われる)ような相手とは、それ以降何回もすれ違う可能性があることから、「個別あいさつ」によって、より親しい関係のあいさつを可能とするものである。
そして、広場アプリの初期設定においては、上記「共通あいさつ」の作成のみが行われる。本実施形態では、適宜入力画面が表示され、これに対して16文字までのテキストをユーザが入力する。このテキストが「共通あいさつ」として記憶される。その結果、「あいさつ処理」では、ここで作成・記憶された「共通あいさつ」が選択できる。なお、本実施形態では、当該「共通あいさつ」は一つしか作成できないものとする。
[スリープモード中のすれちがい通信]
このような広場アプリの初期設定が一通り終われば、上記ユーザキャラクタに関するデータや「共通あいさつ」のテキストデータ等が上記送信ボックスに格納される。その後、広場アプリのメイン画面が表示される。
ユーザは、一旦広場アプリを終了させてゲーム装置1をスリープモードにする。そして、当該ゲーム装置1を所持して外出する。外出中に上記のようなすれちがい通信が何度か行われた後、ユーザが帰ってきたとする。
外出から帰って来たユーザが広場アプリを起動すると、今回の外出中に発生したすれちがい通信(より正確には、上記ユーザキャラクタの送受信を伴うすれちがい通信。以下の説明では、すれちがい通信とはこのようなユーザキャラクタの送受信を伴うすれちがい通信のことを指すものとする)で得られた他のユーザキャラクタについての処理として、以下のような処理が実行される。
[新着通知]
まず、新着通知の処理が行われる。具体的には、図5に示すように、今回の外出中に発生したすれちがい通信の回数が表示される。図5では、画面左側には自己が作成したユーザキャラクタ101が表示され、画面右側には、すれちがいで得られた他のユーザキャラクタ102の列が表示されている。また、画面上部の略中央に、今回のすれちがい回数を示すメッセージが表示されている。そして、他のユーザキャラクタ102の列から1体ずつ自己のユーザキャラクタ101に近づいてきてすれ違うようなアニメーションが表示される。その後、図6に示すような、今までに発生した(ユーザキャラクタの送受信を伴う)すれちがい通信の合計回数が表示される。
新着通知にかかる表示が終わると、次に、他のユーザキャラクタ毎に、以下のような処理が順に行われる。
(1)相手側の自己紹介→(2)あいさつ処理→(3)相手側の近況報告等→(4)評価処理
図7〜図21は、これらの処理にかかる画面の一例である。例えば、図7においては、画面の左側に自己のユーザキャラクタ101が表示され、画面右側に、今回の外出中に発生したすれちがい通信で得られた他のユーザキャラクタ102が表示されている。このような画面を基本として、以下のような処理が実行される。
[(1)相手側の自己紹介]
まず最初に、(1)相手側の自己紹介が行われる。本実施形態では、図7に示すように、他のユーザの居住している「地域」と他のユーザの「名前」を自己紹介として表示する。この「地域」は、他のユーザキャラクタの送信元となったゲーム装置1の本体設定の一つとして記憶されている内容である。また、「名前」は、当該他のユーザキャラクタの作成者(つまり、他のユーザ)がそのユーザキャラクタに対して任意に付けた名前である。また、この表示は、他のユーザキャラクタ102が話しているかのように見せるため、吹き出しを用いた表示がなされる。
相手側の自己紹介が終わると、当該ユーザキャラクタ102が初対面となるユーザキャラクタであるときには、図8に示すように、「はじめまして」というメッセージが吹き出しを用いて表示される。また、以前にすれちがい通信で取得した実績がある他のユーザキャラクタの場合は、図9に示すように、すれ違った回数を示すメッセージが表示される。
[(2)あいさつ処理]
次に、(2)あいさつ処理が行われる。この処理では、まず「相手側から自分側へのあいさつ」が行われた後、「自分側から相手側へのあいさつ」が行われる。以下では、他のユーザキャラクタ102が初対面である場合と、そうではない場合とに分けて説明する。
[初対面の場合]
現在の処理にかかる他のユーザキャラクタが初対面のユーザキャラクタである場合は、まず、「相手側から自分側へのあいさつ」として、図10に示すように、相手側が設定した「共通あいさつ」が、他のユーザキャラクタ102が話している様子で表示される。その後、「自分側から相手側へのあいさつ」として、図11に示すように、ユーザ自身が設定した「共通あいさつ」が、自己のユーザキャラクタ101が話している様子で表示される。これは、上記初期設定において作成された最長16文字のテキストメッセージである。
[2度目以降の対面の場合]
現在の処理にかかる他のユーザキャラクタ102が初対面のユーザキャラクタではない場合は、「相手側から自分側へのあいさつ」としては、図12に示すように、相手側が設定した「共通あいさつ」、あるいは、「個別あいさつ」が表示される。いずれが表示されるかは、相手側がいずれのあいさつを行ったかによる。ここで、相手側のあいさつが「個別あいさつ」の場合は、その「個別あいさつ」の基となった自分側のあいさつの内容も共に表示される(図13参照)。具体的には、まず、自分側のあいさつの内容が先に表示される。そして、このあいさつ内容に対して返事するように、相手側の個別あいさつが表示される。これは、相手側の「個別あいさつ」の内容が、自分側のどのような内容のあいさつに対してのもの(返事)であるのかをユーザに把握させやすくするためである。それと同時に、自分側のユーザキャラクタ101と相手側のユーザキャラクタ102があたかも会話しているかのように見せることで、ユーザが他のユーザとコミュニケーションをとっている感覚をより高めている。
次に、「自分側から相手側へのあいさつ」として、まず、図14に示すようなあいさつの種類を選択するあいさつ選択ウィンドウ105が表示される。図14では「みんな向け」と「こべつの」の2つの選択肢が表示されている。これに対して、ユーザが「みんな向け」を選択すると、共通あいさつを選択したものとして扱われる。その結果、図15に示すように、自己の作成した「共通あいさつ」が表示される。一方、ユーザが「こべつの」を選択したときは、「個別あいさつ」を選択したとして扱われる。その結果、まず、「個別あいさつ」としてのテキストを入力するための画面(図示は省略)が表示される。この画面に対して、2バイト文字で16文字以内のテキストをユーザが所定の入力装置を用いて入力する。そして、入力が終われば、図16に示すような確認画面が表示される。この確認画面でユーザが了承すれば、図17に示すように、今入力した「個別あいさつ」が表示される。以上で、現在の他のユーザキャラクタに対するあいさつ処理は終了する。
ここで上記「個別あいさつ」については、その送信相手を特定する情報と共にすれちがい通信用の送信データとして適宜設定され、送信ボックスに格納される。そして、すれちがい通信によって送信される。なお、本実施形態では、「個別あいさつ」の送信に関しては、とりあえず不特定多数の相手に送信を行うものとする。そして、受信した側で、自分宛の「個別あいさつ」か否かを判断して振り分ける。
なお、上述したあいさつ処理を行うか否かの設定項目において「行わない」と設定されている場合は、図10〜図17にかかるあいさつ処理は省略される。
[(3)相手側の近況報告等]
あいさつ処理が終わると、次に、相手側からの近況報告等を示すメッセージがいくつか表示される。図示は省略するが、例えば、最近遊んだゲームが何かを示すメッセージ等が表示される。また、その他、趣味や好きな食べ物等、プロフィールについてのメッセージ等も表示される。
[(4)評価処理]
相手側の近況報告等を示すメッセージの表示が終われば、次に、評価処理が実行される。ここで、当該評価処理に関しては、個別あいさつの場合と同様に、2回以上すれちがい通信を行った相手にのみ可能となっている。つまり、初対面の相手に対しては評価処理は行われない。相手が初対面(初めてすれ違った人)である場合は、その時点では、再度会う(すれ違う)可能性については未知数であり、同じ人と2度とすれ違わない可能性も低くはない。一方、同じ人と2回目のすれちがい通信が発生した場合、比較的親しい間柄であると考えられることから、3回目以降のすれちがい通信が行われることが期待できる。そのため、再度すれ違う可能性が高い相手に対してのみ評価処理を行うようにして、無駄な評価作業を減らそうとするものである。
まず、図18に示すような、他のユーザキャラクタの外観に対するユーザの評価の選択画面が表示される。図18では、他のユーザキャラクタ102の問いかけメッセージと共に、評価選択ウィンドウ107に「ふつうかな」および「すごくいい!」という2つの選択肢が表示されている。ここでは、「すごくいい!」のほうが高評価であるとする。ユーザは、この選択肢から一方を選択する。すると、その選択肢に応じた所定のメッセージが、他のユーザキャラクタ102が話しているかのように表示される。例えば、「すごくいい!」が選ばれたときは、図19に示すように、喜びを示すようなメッセージが表示される。なお、本実施形態では、評価の方法として、2つの予め記憶されているメッセージのうち1つのメッセージを選択することにより評価を行うようしているが、これに限られず、ユーザのテキスト入力により評価を行うようにしていてもよい。
ここで、上記2つの選択肢のうち、高評価のほうの選択肢が選ばれた場合は、その旨を示すデータがすれちがい通信用の送信データの一つとして設定される。そして、以後に発生するすれちがい通信において、高評価したことを示すデータも他の各種データと共に相手側に送信される。そして、受信した側において、自分宛の高評価のデータが含まれているか否かを判断し、含まれていれば、次に説明するような「相手側から自分への評価」として表示されることになる。つまり、高評価の場合は、高評価したということがその相手側に通知されることになる(もちろん、同じユーザとすれ違うことが前提である)。
また、この評価処理に関しては、同じ相手(ユーザキャラクタ)に対しては、原則として1度しか行えない。但し、同じ相手であっても、その外観が変更されていた場合は(上記ユーザキャラクタ生成アプリで編集可能であるため)、変更この外観について再度評価を行うことが可能となっている。
自分側から相手側への評価が終われば、次に、相手側から自分への評価が表示される。これは、上記のように、相手側が自分に対して高評価を行っていた場合にのみ表示される。この場合は、図20に示すように、相手から自分への評価を示すメッセージが表示された後、図21に示すように、今までに高評価を受けた累計回数が表示される。一方、相手側が自分に対して高評価は行っていない場合(例えば、上記選択肢で「ふつうかな」を相手が選んでいた場合)は、相手側から自分への評価にかかる処理は実行されないこととなる。
以上のような、(1)相手側の自己紹介→(2)あいさつ処理→(3)相手側の近況報告等→(4)評価処理、の一連の処理が、すれちがい通信で取得した他のユーザキャラクタの数の回数分だけ繰り返された後、広場アプリのメイン画面が表示され、当該広場アプリのメインとなる処理が適宜実行される。このメインとなる処理については本実施形態の説明に直接関係しないため、説明は省略する。
このように、本実施形態では、近距離無線通信である「すれちがい通信」を用いてユーザキャラクタを収集すると共に、同じ相手と複数回すれちがい通信が発生している場合は、ユーザと親しい間柄の相手であるとして、上記「個別あいさつ」のような特定の相手向けのあいさつを可能としている。また、他のユーザの作成したユーザキャラクタについて評価を行い、その評価結果について相手側に送信することも可能となっている。これにより、ゲーム装置を所持して外出するだけで上記の様なすれちがい通信によるユーザキャラクタの収集が可能となり、サーバ等が不要の比較的簡易な構成で、自己のユーザキャラクタを他のユーザに評価してもらい、フィードバックしてもらうことが可能である。また、上記のように何度かすれ違った相手に対しては「個別あいさつ」という形で個別のメッセージを送信することができ、他のゲーム装置1を所持しているユーザとより親密なコミュニケーションを取っているプレイ感覚を提供することができる。
次に、ゲーム装置1によって実行される広場アプリ等の処理の詳細を説明する。まず、各種処理の際に用いられる各種データについて説明する。図22は、ゲーム装置1の保存用データメモリ34のメモリマップを示す図である。図2において、保存用データメモリ34は、プログラム記憶領域301およびデータ記憶領域305を含む。プログラム記憶領域301およびデータ記憶領域305のデータは、広場アプリの実行時に、必要に応じてメインメモリ32に適宜転送されて使用される。
プログラム記憶領域301は、CPU31によって実行される各種プログラムを記憶する。本実施形態では、すれちがい通信処理プログラム302と、ユーザキャラ生成アプリプログラム303と、広場アプリプログラム304などが記憶される。すれちがい通信処理プログラム302は、上述したようなスリープモードにおけるすれちがい通信を実行するためのプログラムである。ユーザキャラ生成アプリプログラム303は、上記ユーザキャラクタ作成アプリを実行するためのプログラムであり、広場アプリプログラム304は、上記広場アプリを実行するためのプログラムである。
データ記憶領域305には、本体設定データ306等が記憶される。また、データ記憶領域305は、ユーザキャラクタ記憶領域307、すれちがい通信用データ領域308、アプリ用データ領域309を含んでいる。
本体設定データ306は、主にゲーム装置1の本体に関する設定データである。図23は、本体設定データ306の構成の一例である。本体設定データ306は、ユーザ名データ311、地域データ312等から構成される。ユーザ名データ311は、ゲーム装置1の所有者(つまり、ユーザ)の氏名のデータである。なお、ユーザ名データ311には、ユーザを一意に識別するためのユーザIDも含まれている。地域データ312は、ユーザによって設定されるデータであり、典型的には、ユーザの住んでいる地域を示すデータである。その他、本体設定データ306には、ネットワークに接続するための情報等も含まれる。
図22に戻り、ユーザキャラクタ記憶領域307は、ユーザキャラクタを保存するための領域である。図24は、当該ユーザキャラクタ記憶領域307の構成の一例を示す図である。ユーザキャラクタ記憶領域307は、複数のユーザキャラクタデータ321の集合で構成されている。この領域には、ユーザ自身が作成したユーザキャラクタのデータの他、上記すれちがい通信で取得された、他のユーザによって作成されたユーザキャラクタも保存される。また、当該領域に保存されているユーザキャラクタは、上記広場アプリを含め、様々なアプリにおいて利用可能なデータである。
各ユーザキャラクタデータ321は、ユーザキャラクタID322、ユーザキャラクタ名323、構成パーツ情報324、作成者ID325等から構成される。ユーザキャラクタID322は、ユーザキャラクタを一意に識別するためのIDである。本実施形態では、ゲーム装置本体に固有の番号(例えばシリアルNo)等も利用して、全世界でユニークなIDとなるように生成される。具体的には、ゲーム装置本体に固有の番号と、ユーザキャクタが作成された時点の日時を利用することでユーザキャラクタID322が生成される。
ユーザキャラクタ名323は、各ユーザキャラクタに設定された名前であり、例えば、2バイト文字で10文字までの長さの文字列データである。
構成パーツ情報324は、ユーザキャラクタを構成している各パーツを示す情報である(上述したように、ユーザキャラクタは、「目」、「鼻」等に分類されているパーツの集まりで構成されている)。
作成者ID325は、ユーザキャラクタを作成した人の識別情報である。当該作成者ID325は、ゲーム装置本体に固有の番号を使用して生成される。その結果、作成者ID325は、ゲーム装置1毎に異なる識別情報となる。ユーザ自身が作成したユーザキャラクタであれば、上記本体設定データ306のユーザ名データ311が当該作成者情報325として記憶される。他のゲーム装置で作成されたユーザキャラクタであれば、そのユーザキャラクタを作成したユーザを示すデータ(他のゲーム装置1におけるユーザ名データ311)が作成者情報325となる。
図22に戻り、すれちがい通信用データ領域308は、上記図3および図4で説明したような、すれちがい通信において用いられる各種データを格納するための領域である。図25は、当該すれちがい通信用データ領域308の構成の一例を示す図である。すれちがい通信用データ領域308には複数のスロット331(本実施形態では計16スロット)が含まれている。各スロットは、アプリID332、すれちがい送信データ333、のすれちがい受信データ334で構成されている。
アプリID332は、当該スロットを使用する(対応付けられている)アプリケーションを識別するためのIDである。
すれちがい送信データ333は、すれちがい通信において他のゲーム装置1に送信するためのデータである。図26は、すれちがい送信データ333の構成の一例を示す図である。図26において、すれちがい送信データ333は、送信用ユーザキャラクタデータ341、共通あいさつ文字列データ342、プロフィールデータ343、地域データ344、あいさつ処理実行フラグ345、評価処理実行フラグ346、個別あいさつデータ347、評価リスト352から構成されている。
送信用ユーザキャラクタデータ341は、すれちがい通信において送信する対象となるユーザキャラクタのデータである。上記複数のユーザキャラクタデータ321のうちから、ユーザによって選ばれた1体分のユーザキャラクタデータ321(あるいは、このデータを特定するための情報)が送信用ユーザキャラクタデータ341として記憶される。
共通あいさつ文字列データ342は、上述したような「共通あいさつ」を示す文字列データである。
プロフィールデータ343は、上記広場アプリにおいて、あいさつ処理の後に行われる「相手側の近況報告等」で用いられるデータである。すれちがい通信における送信先となった他のゲーム装置1上で「相手側の近況報告等」が実行される際に、当該プロフィールデータ343の内容が用いられることになる。
地域データ344は、上記本体設定データ306の地域データ312がコピーされたものである。
あいさつ処理実行フラグ345は、上述したようなあいさつ処理を行うことを許可するか否かを示すフラグである。当該フラグがオンに設定されているときは、あいさつ処理を行うことを許可することを示す。オフに設定されているときは、あいさつ処理を行うことを許可しないことを示す。
評価処理実行フラグ346は、上述したような評価処理を行うことを許可するか否かを示すフラグである。当該フラグがオンに設定されているときは、評価処理を行うことを許可することを示す。オフに設定されているときは、評価処理を行うことを許可しないことを示す。
個別あいさつデータ347は、上述したような「個別あいさつ」に関するデータであり、直近の16件分の「個別あいさつ」のデータが記憶されている。個別あいさつ1件分のデータは、宛先ユーザキャラID348、個別あいさつ文字列データ349、引用あいさつ文字列データ350、引用あいさつ種別フラグ351で構成される。
宛先ユーザキャラID348は、「個別あいさつ」を行った対象である相手のユーザキャラクタを特定するためのデータであり、上記ユーザキャラクタID322に対応する。
個別あいさつ文字列データ349は、「個別あいさつ」の内容を示す文字列データである。
引用あいさつ文字列データ350は、当該「個別あいさつ」を生成した際の、他のユーザキャラクタからのあいさつの内容である。例えば、他のユーザキャラクタが行った「またあったね、元気?」という「あいさつ」に対して、「元気だよ。」という「個別あいさつ」を返す場合を想定する。この場合、上記個別あいさつ文字列データ349には「元気だよ。」という文字列のデータが格納され、引用あいさつ文字列データ350には、「またあったね、元気?」という文字列のデータが格納されることになる。
引用あいさつ種別フラグ351は、上記引用あいさつ文字列データ350として格納される、他のユーザキャラクタからのあいさつの種類が「共通あいさつ」であるか「個別あいさつ」であるかを示すフラグである。例えば、この値が”0”であれば「共通あいさつ」、”1”であれば、「個別あいさつ」であることを示す。
以上のようなデータで構成される個別あいさつのデータが最大で16件まで個別あいさつデータ347に記憶される。なお、新たに当該データを格納する際に既に16件まで埋まっている場合は、古いものが1件分消去されてから格納される。
評価リスト352は、当該すれちがい送信データの作成元のユーザ(つまり、送信者)が高評価したユーザキャラクタを示すデータである。直近に高評価したユーザキャラクタのユーザキャラクタID353が、最大で32件分まで格納される。
図25に戻り、すれちがい受信データ334は、すれちがい通信において他のゲーム装置1から受信したデータである。ここには、上記すれちがい送信データ333と同様の構成を有する受信データ335が複数件格納される。そのため、各受信データ335については説明を省略する。
なお、すれちがい送信データ333と受信データ335の構成が同じであるため、以下の説明では、これらのデータの参照符号の末尾に”S”または”R”を付加することで、すれちがい送信データ333と受信データ335のいずれに含まれるデータであるかを区別する。例えば、「送信用ユーザキャラクタデータ341S」は、すれちがい送信データ333に含まれている送信用ユーザキャラクタデータ341であることを示し、「送信用ユーザキャラクタデータ341R」は、受信データ335に含まれている送信用ユーザキャラクタデータ341であることを示す。また、その他のデータについても、末尾に”R”をつけたデータについては、受信データ335に含まれているデータ(つまり、すれちがい通信によって受信したデータに含まれているデータ)であることを示すものとする。
図22に戻り、アプリ用データ領域309は、ゲーム装置1で実行される各種アプリケーションで用いられるデータを記憶する領域である。図27は、当該アプリ用データ領域309の構成の一例を示す図である。当該領域には、各アプリ毎に論理的に分けられて、各アプリにおいて用いられる各種データが記憶される。図27の例では、広場アプリ用データ361と、ユーザキャラ生成アプリ用データ366と、その他のアプリ用データ367が示されている。ここでは主に、広場アプリ用データ361の内容について説明する。
広場アプリ用データ361は、アプリID362、アプリセーブデータ363、受信ユーザキャラ情報保存データ364等で構成される。
アプリID362は、当該「広場アプリ」を識別するためのIDである。上述のようなすれちがい通信に用いるスロットとの関連付けに用いられる。
アプリセーブデータ363は、広場アプリに関する各種設定等を記憶したデータである。図28は、アプリセーブデータ363の構成の一例を示す図である。図28において、アプリセーブデータ363は、すれちがい用ユーザキャラクタデータ371、共通あいさつ文字列データ372、プロフィールデータ373、あいさつ処理実行フラグ374、評価処理実行フラグ375、個別あいさつデータ376、評価リスト377、受けた評価データ378から構成される。また、図示は省略するが、広場アプリに関してすれちがい通信を利用するかか否か(つまり、すれちがい通信を行うか否か)の設定や、すれちがい通信の累計数等のデータもアプリセーブデータ363に含まれる。
すれちがい用ユーザキャラクタデータ371は、すれちがい通信における送信対象として設定したユーザキャラクタのデータである。
共通あいさつ文字列データ372は、上述したような「共通あいさつ」を示す文字列データである。
プロフィールデータ373は、上述したような「相手側の近況報告等」で用いられるデータである。
あいさつ処理実行フラグ374は、上述したようなあいさつ処理を行うことを許可するか否かを示すフラグである。また、評価処理実行フラグ375は、上述したような評価処理を行うことを許可するか否かを示すフラグである。その内容は、上記すれちがい送信データ333におけるあいさつ処理実行フラグ345および評価処理実行フラグ346と同様である。
個別あいさつデータ376は、直近の16件分の「個別あいさつ」についてのデータである。その構成は、上記すれちがい送信データ333における個別あいさつデータ347と同様である。
評価リスト377は、自分が高評価を与えた他のユーザキャラクタのユーザキャラクタIDのリストであり、最大で直近の32件分まで保存される。その構成は、上記すれちがい送信データ333における評価リスト352と同様である。
受けた評価データ378は、自己の作成したユーザキャラクタに対して高評価を行った他のユーザについてのデータであり、本実施形態では、最大で100件分の評価者情報379が記憶される。各評価者情報379は、評価対象ユーザキャラクタID380と、評価した作成者情報381で構成されている。評価対象ユーザキャラクタID380は、自己の作成したユーザキャラクタであって、高評価を受けた(評価の対象となった)ユーザキャラクタのIDである。評価した作成者情報381は、高評価を与えた他のユーザを示す情報であり、他のゲーム装置1から受信した作成者情報325Rが当該評価した作成者情報381として記憶される。例えば、ユーザAが2体のユーザキャラクタAおよびBを作成したとする。この2体を、すれちがい通信に用いるユーザキャラクタを適宜変更することで、ユーザBの所持するゲーム装置と、ユーザCが所持するゲーム装置に送信した場合を想定する。そして、ユーザキャラクタAについては、他のユーザBおよびCから高評価をされたが、ユーザキャラクタBについては、他のユーザCからしか高評価がなされなかった場合を想定する。このような場合は、受けた評価データ378としては、<ユーザキャラクタAのID+ユーザBの作成者情報>と、<ユーザキャラクタAのID+ユーザCの作成者情報>と、<ユーザキャラクタBのID+ユーザCの作成者情報>の3件分の情報となる。
図27に戻り、受信ユーザキャラ情報保存データ364は、すれちがい通信によって他のゲーム装置1から受信したユーザキャラクタに関するデータである。図29は、受信ユーザキャラ情報保存データ364の構成の一例を示す図である。図29において、受信ユーザキャラ情報保存データ364には、1000体分の受信ユーザキャラ391が記憶される。各受信ユーザキャラ391は、ユーザキャラデータ392、プロフィールデータ393、すれちがい回数394、前回すれちがい日時395、地域データ396、評価処理実行フラグ397で構成されている。
ユーザキャラデータ392は、上記受信データ335に含まれている送信用ユーザキャラクタデータ341Rがコピーされたものである。同様に、プロフィールデータ393は、上記受信データ335に含まれているプロフィールデータ343Rがコピーされたものである。
すれちがい回数394は、当該受信したユーザキャラクタの送信元のゲーム装置1との間で、上記のようなすれちがい通信が行われた回数を示すデータである。前回すれちがい日時395は、上記受信したユーザキャラクタの送信元のゲーム装置1とすれちがい通信が最後に行われた日時を示すデータである。地域データ396は、上記受信データ335に含まれている地域データ344Rがコピーされたものである。
評価処理実行フラグ397は、上記受信データ335に含まれている評価処理実行フラグ346Rがコピーされたものである。つまり、当該受信したユーザキャラクタの作成者が、このキャラクタが評価されることを望んでいるか否かを示すフラグである。
以下、ゲーム装置1が行う広場アプリについての処理の詳細動作を説明するが、広場アプリの詳細動作の説明に先立って、上述したすれちがい通信にかかる具体的な処理の流れについて簡単に説明する。
図30は、本実施形態にかかるすれちがい通信の処理の詳細を示したフローチャートである。このフローにかかる処理は、ゲーム装置1が「スリープモード」(すれちがい通信モード)中のときに実行される。まず、ステップS1において、ビーコン信号が発信される。このビーコン信号は、ゲーム装置同士のローカル通信確立のきっかけとなるような情報が含まれている。次に、ステップS2において、他のゲーム装置から発信されたビーコンの存在を検出する。
次に、ステップS3において、上記ビーコンの検出の結果、ビーコンが検出できたか否か、つまり、自機の通信可能範囲内に他のゲーム装置1が存在するか否かが判定される。その結果、自機の通信可能範囲内に他のゲーム装置1が存在していないときは(ステップS3でNO)、後述のステップS9に処理が進められる。一方、自機の通信可能範囲内に他のゲーム装置1が存在するときは(ステップS3でYES)、ステップS4において、ローカル通信を確立するための処理が実行される。ローカル通信が確立すれば、ステップS5において、通信相手となったゲーム装置1との間で、共通するアプリID332を有するスロット331があるか否かが判定される。つまり、すれちがい通信において送受信すべきデータが在るか否かが判定される。その結果、共通するアプリID332を有するスロット331がないときは(ステップS5でNO)、後述のステップS8に処理が進められる。一方、共通するアプリID332を有するスロット331が存在するときは(ステップS5でYES)、ステップS6において、当該スロット331にかかるすれちがい送信データ333が他のゲーム装置1に送信される。同時に、他のゲーム装置1から送信されてくるすれちがい送信データ333が、すれちがい受信データ334の受信データ335として格納される。
次に、ステップS7において、上記データの送受信が完了したか、または、ローカル通信が強制的に切断されたか(すれちがい通信が完了する前に、通信可能範囲外にユーザが移動したような場合等)が判定される。その結果、データの送受信が未完了であり、ローカル通信も切断されていなければ(ステップS7でNO)、上記ステップS6に戻り、データの送受信が継続される。一方、送受信が完了、または、ローカル通信が強制切断されたときは(ステップS7でYES)、ステップS8において、ローカル通信を終了するための処理が実行される。データの送受信が完了した場合は、通信を切断することで、すれちがい通信を「正常終了」させるための処理が実行される。また、送受信完了前にローカル通信が強制切断されていた場合は、それまでに受信したデータをクリアし、すれちがい通信が始まる前の状態に戻す処理が行われる。
次に、ステップS9において、「スリープモード」を終了させる指示がなされたか否かが判定され、終了指示がなされていないときは(ステップS9でNO)、上記ステップS1に戻り、処理が繰り返される。一方、終了指示がなされたときは(ステップS9でYES)、すれちがい通信処理が終了される。以降、ゲーム装置1が「通常モード」で動作することで、以下に説明するような処理が実行されることになる。
次に、ゲーム装置1で実行される広場アプリの処理の詳細について説明する。この処理は、ゲーム装置1のホームメニューから広場アプリの実行指示がユーザによって行われることで開始される。例えば、ホームメニューの中から、広場アプリに対応するアイコン画像をユーザが選択して所定のボタンを押下したときに開始される。
図31は、広場アプリの処理の詳細を示すフローチャートである。まず、図31において、広場アプリが起動されると、保存用データメモリ34からメインメモリ32への必要なファイルのロード等の初期処理が適宜実行される。その後、ステップS11において、ユーザキャラクタ記憶領域307が参照され、作成済みのユーザキャラクタ101が1体以上存在するか否かが判定される。当該判定の結果、ユーザキャラクタ101が1体も作成されていないときは(ステップS11でNO)、ステップS12において、ユーザキャラクタの作成を促すメッセージが表示される。そして、広場アプリ処理は終了する。つまり、ユーザキャラクタが未作成の状態では、広場アプリは実質的に利用できないことになる。
一方、ユーザキャラクタ101が1体以上作成済みであるときは(ステップS11でYES)、次に、ステップS13において、広場アプリが初回起動であるか否か(つまり、今まで一度も実行されたことが無いか否か)が判定される。その結果、初回起動のときは(ステップS13でYES)、ステップS14において、広場アプリ初期設定処理が実行される。この処理は、すれちがい通信で用いるユーザキャラクタの選択等、広場アプリを利用するために必要な各種設定を行うための処理である。一方、初回起動ではないときは(ステップS13でNO)、広場アプリ初期設定処理はスキップされて、後述のステップS15に処理が進められる。
図32は、上記ステップS14で示した広場アプリ初期設定処理の詳細を示すフローチャートである。図32において、まず、ステップS21で、広場アプリの簡単な紹介と説明が表示される。続くステップS22において、ユーザとの対話形式ですれちがい通信に関する設定を行う処理が実行される。具体的には、「すれちがい通信」を行うか否か、「あいさつ処理」を行うか否か、「評価処理」を行うか否か、等について、対話形式を用いて設定される。その結果、ユーザの入力内容に応じて、上記すれちがい通信用データ領域308のいずれかのスロット331と広場アプリとを関連づける処理が実行される。更に、ユーザキャラクタ記憶領域307から、すれちがい通信で用いるユーザキャラクタがユーザの入力内容に基づいて選択され、アプリセーブデータ363のすれちがい用ユーザキャラクタデータ371として保存される。また、アプリセーブデータ363のあいさつ処理実行フラグ374および評価処理実行フラグ375も、ユーザの入力内容に応じて適宜設定される。
次に、ステップS23において、プロフィールデータ373作成の元となる質問が適宜表示され、これに対するユーザの入力内容に応じて、プロフィールデータ373が適宜設定される。
次に、ステップS24において、「共通あいさつ」を生成するための処理が実行される。具体的には、「共通あいさつ」としての文字列を入力するための画面が表示される。これに対して、ユーザによって入力された所定の文字列が共通あいさつ文字列データ372として記録される。以上で、広場アプリ初期設定処理は終了する。
図31に戻り、次に、ステップS15において、広場アプリメイン処理が実行される。図33〜図38は、当該広場アプリメイン処理の詳細を示すフローチャートである。図33において、まず、ステップS41で、アプリセーブデータ363が参照され、広場アプリですれちがい通信を行う設定がなされているか否かが判定される。その結果、すれちがい通信を行わない旨の設定が成されているときは(ステップS41でNO)、後述するステップS80に処理が進められ、広場アプリのメイン画面が表示されることになる。
一方、すれちがい通信を行う旨の設定がなされているときは(ステップS41でYES)、次に、ステップS42において、すれちがい通信用データ領域308が参照され、今回の(直近の)スリープモード中においてすれちがい通信が発生したか否かが判定される。例えば、すれちがい受信データ334の内容が空であるか否かで判定される。当該判定の結果、すれちがい通信が発生していないときは(ステップS42でNO)、続くステップS43で、アプリセーブデータ363が参照されて、すれちがい通信の累計回数が0か否かが判定される。その結果、すれちがい通信の回数が0のときは(ステップS43でNO)、他のユーザキャラクタを1体も受信していない状態であると考えられるため、ステップS44において、ユーザにすれちがい通信を行わせることを支援するためのメッセージ(例えば、「人の集まるところですれちがい通信をしてみよう!」)が表示される。その後、後述のステップS80に処理が進められる。
一方、直近のスリープモード中においてすれちがい通信が発生していたときは(ステップS42でYES)、少なくとも1体は他のユーザキャラクタを受信していると考えられるため、新着通知にかかる処理が実行される。具体的には、ステップS45において、上記図5を用いて説明したような画面を用いて、今回のすれちがい通信においてすれ違った回数(受信した他のユーザキャラクタの数)が表示される。その後、当該回数が、累計すれちがい回数を示すデータ(図示は省略)に加算されて、上記図6で示したような画面が生成されて表示される。また、当該加算後の累計すれちがい回数はアプリセーブデータ363の一部として記憶される。
新着通知にかかる処理が終われば、次に、受信された各ユーザキャラクタについての処理が実行される。まず、ステップS46において、すれちがい受信データ334が参照されて、処理対象となるユーザキャラクタ(受信データ335)が古い順に1件選択されて読み出される。以下、当該選択されたユーザキャラクタを処理対象キャラクタと呼ぶ。
次に、ステップS47において、処理対象キャラの自己紹介を表示する処理が行われる。具体的には、受信データ335(その構成は上記図26で示したすれちがい送信データ333と同様である)の送信用ユーザキャラクタデータ341Rが参照され、これに含まれているユーザキャラクタ名323Rが取得される。また、受信データ335の地域データ344Rが参照されることで、地域名も取得される。そして、これらのデータに基づき、地域と名前を表示した自己紹介画面(上記図7参照)が生成されて表示される。
次に、図34のステップS48において、処理対象キャラクタが「初対面」となるユーザキャラクタか否かが判定される。「初対面」か否かは、例えば、当該処理対象キャラクタのユーザキャラクタID322Rを基にして受信ユーザキャラ情報保存データを検索し、検索できたか否かで判定される(検索できなかった場合は「初対面」となる)。
当該判定の結果、初対面であるときは(ステップS48でYES)、ステップS49において、初対面処理が実行される。図35は、当該初対面処理の詳細を示すフローチャートである。まず、ステップS101において、初対面用のあいさつが表示される。当該初対面用のあいさつは、予め定義されている文字列である。ここでは、上記図8で示したような、「はじめまして」というあいさつが表示される。
次に、ステップS102において、あいさつ処理の実行に関してお互いに許可されているか否かが判定される。例えば、まず、アプリセーブデータ363のあいさつ処理実行フラグ374が参照され、自分側のあいさつ処理の実行許可が設定されているか否かが判定される。その結果、許可されていなければ、当該ステップS102の判定結果はNOとなる。許可されていれば、次に、処理対象キャラクタのあいさつ処理実行フラグ345Rが参照され、相手側のあいさつ処理の実行許可が設定されているか否かが判定される。ここで許可されていないときは、当該ステップS102の判定結果はNOとなる。許可されているときは、当該ステップS102の判定結果はYESとなる。
ステップS102の判定の結果、少なくとも一方であいさつ処理の実行許可が設定されていないときは(ステップS102でNO)、後述のステップS105に処理が進められる。一方、双方ともにあいさつ処理の実行許可が設定されていれば(ステップS102でYES)、ステップS103において、受信データ335の共通あいさつ文字列データ342Rが参照され、処理対象キャラクタにかかる(つまり、相手側の)「共通あいさつ」が表示される。
次に、ステップS104において、アプリセーブデータ363の共通あいさつ文字列データ372が参照され、ユーザ自身が作成した(つまり、自分側の)「共通あいさつ」が表示される。つまり、初対面のときは、「個別あいさつ」は一切用いられないことになる。
次に、ステップS105において、処理対象キャラクタにかかる近況報告の処理が実行される。これは、受信データ335のプロフィールデータ343Rが参照されることで、その内容を反映したメッセージが生成されて表示される処理である。以上で、初対面処理は終了する。
図34に戻り、初対面処理が終わると、後述するステップS78に処理が進められ、次の他のユーザキャラクタにかかる処理に移行することになる(つまり、初対面時は、評価処理はなされないことになる)。
一方、図34のステップS48の判定の結果、初対面のキャラクタではないときは(ステップS48でNO)、次に、ステップS50において、処理対象キャラクタとの遭遇回数(すれちがい通信が行われた回数)を表示する処理が実行される。具体的には、受信ユーザキャラ情報保存データ364が参照され、処理対象キャラクタにかかるすれちがい回数394が取得される。そして、この回数に1を加算した値に基づいて上記図9で示したような画面が生成されて表示される。また、この加算後の値は、当該処理対象キャラクタにかかるすれちがい回数394として記憶される。
次に、ステップS51において、あいさつ処理を行うか否かが判定される。すなわち、双方ともに「あいさつ処理」の実行許可が設定されているか否かが判定される。当該判定の結果、少なくとも一方であいさつ処理の実行許可が設定されていないときは(ステップS51でNO)、後述のステップS67に処理が進められる。一方、双方ともにあいさつ処理の実行許可が設定されているときは(ステップS51でYES)、ステップS52において、処理対象キャラクタ(相手側)のあいさつの種類が「共通あいさつ」か否かかが判定される。具体的には、まず、処理対象キャラクタにかかる受信データ335の個別あいさつデータ347Rが参照され、自分側のユーザキャラクタのユーザキャラクタID322と一致する宛先ユーザキャラID348Rが検索される。その結果、検索できた場合は、相手側のあいさつは「個別あいさつ」であり、見つからなかった場合は、相手側のあいさつは「共通あいさつ」であると判定される。
ステップS52の判定の結果、処理対象キャラクタ側のあいさつが「共通あいさつ」であるときは(ステップS52でYES)、ステップS53において、処理対象キャラクタにかかる受信データ335の共通あいさつ文字列データ342Rに基づいて、処理対象キャラクタ側の「共通あいさつ」が表示される。
次に、ステップS54において、処理対象キャラクタとのすれちがい回数が2回目であるか否かが判定される。例えば、受信ユーザキャラ情報保存データ364が参照され、処理対象キャラクタに対応する受信ユーザキャラのデータが存在するか否かが判定される。そして、存在していれば、すれちがい回数394が参照され、「2回目」を示すデータが格納されているときは、今回、2回目のすれちがいが行われたと判定される。このような判定の結果、すれちがい回数が2回目のときは(ステップS54でYES)、ステップS55において、「個別あいさつ」が送信可能となった旨のメッセージを表示する。次に、ステップS56において、上記図14で示したような、あいさつ選択ウィンドウ105に表示する内容の設定が行われる。ここでは、上記図14で示されているような「みんな向け」と「こべつの」という2つの選択肢が設定される。その後、後述するステップS61に処理が進められる。
一方、上記ステップS54の判定の結果、2回目ではない(つまり、3回目以上)のときは(ステップS54でNO)、上記ステップS55の処理はスキップされる。
次に、上記ステップS52の判定の結果、処理対象キャラクタ側のあいさつが「共通あいさつ」ではないとき(ステップS52でNO)、つまり、「個別あいさつ」であるときの処理について説明する。このときは、上記図13で示したような、相手側の「個別あいさつ」と、これの基になった自分側のあいさつの文字列を示す画面を表示するための処理が実行される。まず、図36のステップS57において、処理対象キャラ側の個別あいさつデータ347Rが参照され、引用あいさつ文字列データ350Rが取得される。そして、当該データで示される文字列、つまり、前回のすれちがい時に自分側が行ったあいさつ内容が表示される。続いて、ステップS571において、同じく処理対象キャラ側の個別あいさつデータ347Rが参照され、自分宛の個別あいさつ文字列データ349Rが取得される。そして、当該データに基づき、相手側の「個別あいさつ」が表示される。その結果、まず、前回すれちがい時に自分側が行ったあいさつが表示され、これに答えるように、相手側の「個別あいさつ」が次に表示されることになる。このように、自分側のあいさつと相手側のあいさつを順番に表示することで、自分側のユーザキャラクタ101と相手側のユーザキャラクタ102とがあたかも会話しているかのような表現が行われることになる。。
次に、ステップS58において、処理対象データにかかる受信データ335の引用あいさつ種別フラグ351Rが参照され、当該処理対象キャラクタと前回すれちがい通信が行われた際に、自分側が送ったあいさつの種類が「個別あいさつ」であったか否かが判定される。その結果、前回送ったあいさつが「個別あいさつ」のときは(ステップS58でYES)、ステップS59において、あいさつ選択ウィンドウ105の内容が設定される。ここで設定される内容は、上記図14で示したようなあいさつ選択ウィンドウ105の内容となる。
一方、前回送ったあいさつが「共通あいさつ」のときは(ステップS58でNO)、ステップS581において、引用あいさつ文字列データ350Rと共通あいさつ文字列データ372とが参照され、その内容が一致するか否かが判定される。その結果、一致していないときは(ステップS581でNO)、上記ステップS59に処理が進められる。一方、一致しているときは(ステップS581でYES)、次のステップS60において、あいさつ選択ウィンドウ105の内容が設定されるが、ここで設定される内容は、図39に示すような、個別あいさつをするかしないかを問い合わせるような内容となる。これは、「共通あいさつ」で同じあいさつを複数回行ってしまうことを防止するため、「共通あいさつ」に対する相手側の「個別あいさつ」に対して「個別あいさつ」を返すことを促すためである。また、上記ステップS581の判定は、前回すれちがい通信が行われた後、「共通あいさつ」の文字列がユーザによって変更され、更にその後に同じ相手とすれちがい通信が行われた場合を想定したものである。つまり、ある相手に一旦「共通あいさつ」を送った後、「共通あいさつ」の文字列をユーザが変更した場合は、その後同じ相手に「共通あいさつ」を送ったとしても、そのあいさつ内容は別の文字列となっているため、同じ文字列の「共通あいさつ」が連続して行われることにはならない。このような、「共通あいさつ」の変更が行われたか否かを判別するために上記ステップS581の判定が行われている。
図36に戻り、次に、ステップS61において、上記ステップS59またはステップS60で設定された内容であいさつ選択ウィンドウ105が生成されて表示される。そして、当該選択ボックスに対するユーザからの入力が受け付けられる。
次に、ステップS62で、上記あいさつ選択ウィンドウ105に対するユーザの選択内容が「個別あいさつ」を選択したものであるか否かが判定される。当該判定の結果、「個別あいさつ」が選択されていないときは(ステップS62でNO)、ステップS63において、共通あいさつ文字列データ372に基づいた「共通あいさつ」が表示される。そして、後述のステップS67に処理が進められる。
一方、「個別あいさつ」が選択されたときは(ステップS62でYES)、ステップS64において、「個別あいさつ」を作成する処理が実行される。具体的には、文字列入力画面が表示され、ユーザからの文字列入力が受け付けられる。ユーザからの文字列入力が終われば、確認メッセージが表示され(上記図16参照)、入力内容が確定すれば、次のステップS65において、当該入力された文字列データに基づき、上記図17で示したように、上記ユーザの入力した「個別あいさつ」が表示される。次に、ステップS66において、アプリセーブデータ363の個別あいさつデータ376が更新される。具体的には、現在の処理対象キャラクタを示すユーザキャラクタID322Rが、アプリセーブデータ363の個別あいさつデータ376に含まれる宛先ユーザキャラIDとして記憶される。また、上記入力が確定した文字列のデータが個別あいさつ文字列データとして記憶され、現在の処理対象キャラクタ側のあいさつの文字列データが引用あいさつ文字列データとして記憶され、現在の処理対象キャラ側のあいさつの種別を示すデータが引用あいさつ種別フラグとして記憶される。以上で、あいさつ処理は終了する。
次に、図37のステップS67において、相手側の近況報告処理が行われる。相手側の近況報告処理が終われば、次に、評価処理が行われる。まず、ステップS68において、自分側と相手側の双方ともに評価処理の実行許可が設定されているか否かが判定される。これは、相手側と自分側の評価処理実行フラグが参照されることで判定される。当該判定の結果、少なくとも一方で評価処理の実行許可が設定されていないときは(ステップS68でNO)、後述のステップS78に処理が進められる。
一方、双方ともに評価処理の実行許可が設定されているときは(ステップS68でYES)、ステップS69において、処理対象キャラクタについて既に評価済みであるか否かが判定される。これは、まず、処理対象キャラとのすれちがい回数が2回目か否かが判定され、2回目であれば、まだ評価していないと判定される。一方、3回目以降であるときは、更に、受信ユーザキャラ情報保存データ364に保存されている処理対象キャラクタのユーザキャラデータ392と、受信データ335における送信用ユーザキャラクタデータ341Rとが比較され、ユーザキャラクタの外見が一致するか否かが判定される。その結果、外観に違いがあるときは、新たな外観についての評価はまだ行われていないとして、まだ評価していないと判定される。3回目以降であって、前回から外観に変化がないときは、評価済みであると判定される。なお、例えば2回目のすれちがいにおいて、相手側の評価処理実行フラグ346Rが「許可しない」設定であり、3回目のすれちがいにおいて、相手側の評価処理実行フラグ346Rが「許可する」設定となっていた場合であっても、2回目と3回目とで処理対象キャラの外観に変化がないときは、評価済みであると判定される。
ステップS69の判定の結果、既に評価済みであるときは(ステップS69でYES)、後述のステップS75に処理が進められる。一方、まだ評価していないときは(ステップS69でNO)、ステップS70において、上記図18で示したような画面が表示される。すなわち、2つの選択肢(高評価/普通)を有する評価選択ウィンドウ107が表示される。そして、ユーザからの入力が受け付けられる。
次に、ステップS71において、ユーザの入力内容に応じた処理対象キャラクタのリアクションが表示される(上記図19参照)。また、上記受信ユーザキャラ情報保存データ364に保存されている処理対象キャラのユーザキャラデータ392の内容が受信後のデータ内容に基づいて適宜更新される。
次に、ステップS72において、上記ユーザの入力にかかる内容が、高評価にかかる内容であるか否かが判定される。その結果、高評価であったときは(ステップS72でYES)、ステップS73において、次回すれ違ったときに、当該処理対象キャラの送信元のゲーム装置1に評価が送信される旨の通知メッセージが表示される。次に、ステップS74において、アプリセーブデータ363のうち、上記評価処理に関するデータが適宜更新される。具体的には、アプリセーブデータ363の評価リスト377に処理対象キャラのユーザキャラクタIDが保存される、このとき、当該IDが重複していれば、古い方のIDは削除される。また、既に32件登録されている状態であれば、一番古いデータが削除されてから保存される。
一方、上記ステップS72の判定の結果、高評価ではなかったときは(ステップS72でNO)、当該ステップS73およびステップS74の処理はスキップされる。
次に、図38のステップS75において、相手側から自分への評価データがあるか否かが判定される。具体的には、まず、アプリセーブデータ363の受けた評価データ378が参照され、既に100件分の評価を受けているか否か(既に100件登録されているか否か)が判定される。その結果、100件未満のときは、次に、処理対象キャラクタにかかる受信データ335の評価リスト352Rから自分のユーザキャラクタ(すれちがい通信用として現在設定されているユーザキャラクタ)のユーザキャラクタIDが検索される。その結果、見つかったときは、自分への評価データがあると判定され、見つからなかったときは、自分への評価データがないと判定される。一方、受けた評価データ378に既に100件分の評価が保存されていれば、相手側から自分への評価データがある場合でも、評価データはないものとして判定される。つまり、既に100件分の評価があるときは、相手側からの評価に関する処理は実行されないことになる。
ステップS75の判定の結果、相手側から自分への評価データがないときは(ステップS75でNO)、後述のステップS78に処理が進められる。一方、自分への評価データがあるときは(ステップS75でYES)、ステップS751において、受信データ335の評価リスト352RのユーザキャラID353R(評価対象ユーザキャラクタID380に対応)と受信データ335の送信用ユーザキャラクタデータ341Rにおける作成者ID325R(評価した作成者情報381に対応)の組み合わせが、受けた評価データ378に既に存在するかどうかが判定される。その結果、既に存在するときは(ステップS751でYES)、この相手からは既に評価を受けていることになるため、後述のステップS78に処理が進められる。一方、存在しないときは(ステップS751でNO)、この相手からはまだ評価を受けたことがないことになる。この場合は、続くステップS76において、相手側からの評価を表示する処理が実行される。すなわち、上記図20で示したような画面が表示される。
次に、ステップS77において、高評価の累計数が表示される。具体的には、まず、今回評価された自分側のユーザキャラクタID322が、評価者情報379の評価対象ユーザキャラクタID380として記憶され、今回の処理対象キャラクタの作成者情報325Rが評価した作成者情報381として記憶される。そして、受けた評価データ378に含まれる評価者情報379の件数が高評価の累計数として算出される。つまり、当該累計数は、複数のユーザキャラクタが作成されている場合は、これら全てのユーザキャラクタに対する高評価の数を合計した値が用いられることになる。各ユーザキャラクタは、相手毎に評価が得られるため、例えば、ユーザキャラクタAが、2人の他のユーザから高評価を得ており、ユーザキャラクタBについては4人の他のユーザから高評価を得ているときは、高評価の累計数は6となる。これは、高評価の数を集めることを目的にさせることで、ユーザに様々なユーザキャラクタを作成させて楽しんでもらう事を促進するためである。そして、この累計数に基づいて、上記図21で示したような画面が生成されて表示される。
なお、上記ステップS751の判定の結果、上記の組み合わせが既に存在するときに、上記ステップS76に処理を進めるようにしても良い。この場合は、高評価の累計数は更新しないようにしてもよい。つまり、既に評価を受けた相手については、その相手からの評価の表示のみを行い、累計数は加算しないようにしてもよい。
以上で、評価処理は終了する。このようにしてあいさつ処理や評価処理が終了したユーザキャラクタにかかる受信データ335は、処理済みであるとして、すれちがい受信データ334からクリアされる。
次に、ステップS78において、上述したような処理がまだ行われていない受信データ335が残っているか否かが判定される。その結果、まだ残っているときは(ステップS78でYES)、上記ステップS46に戻り、処理が繰り返される。一方、全て処理したときは(ステップS78でNO)、ステップS79において、上述した処理内容が反映されるようにすれちがい送信データ333が適宜更新される。すなわち、あいさつ処理における個別あいさつに関連するデータである個別あいさつデータ347Sや、評価処理に関する評価リスト352S等が適宜更新される。
次に、ステップS80において広場メイン画面が表示され、続くステップS81において、その他の広場アプリの処理が実行される。続くステップS82において、広場アプリの終了指示がユーザから指示されたか否かが判定され、終了指示がなされていなければ(ステップS82でNO)、上記ステップS81の処理が繰り返され、終了指示がなされたときは(ステップS82でYES)、当該広場アプリは終了され、ホームメニュー画面に戻ることになる。以上で、本実施形態にかかる広場アプリ処理の説明を終了する。
このように、本実施形態では、最初は不特定多数に向けた「共通あいさつ」を用いて不特定多数相手とのコミュニケーションを図りつつ、その中で複数回すれ違った相手に対しては、その相手を特定した「個別あいさつ」が送信できるようにしている。これにより、他のユーザとの通信内容が画一的になることを防ぎ、よくすれ違う相手との親密度を高めることを可能として、上記のようなすれちがい通信による他人とのコミュニケーションの興趣性をより高めることが可能となる。換言すれば、すれちがい通信を繰り返すことで、親しくなれる可能性の高い他人を抽出し、その相手に対して個別にアプローチすることを可能とすることで、新たな友達を作る可能性を高めることができる。
また、相手側の個別あいさつが表示される際、その個別あいさつの基になった自分側のあいさつ内容も合わせて表示されるようにしている。これにより、相手側のあいさつ(相手側の反応内容)が、自分が相手側に送ったどのようなあいさつに対してものであるかを把握させやすくすることができる。特に、上記のようなすれちがい通信によってあいさつが送受信される、換言すれば、あいさつ内容はリアルタイムにやりとりされるものではないため、このように過去に送ったあいさつ内容を表示することは効果的である。
また、自己が作成したユーザキャラクタを、近距離無線通信であるすれちがい通信を用いて送信し、他のユーザに評価してもらうことが可能となっている。つまり、ユーザが生活する地域の近隣範囲内において、簡易なシステム構成によって自己の作成したユーザキャラクタを他人に評価してもらい、その結果をフィードバックしてもらうことが可能となる。これにより、自己のユーザキャラクタを他人に評価してもらうことを手軽にユーザに楽しんでもらうことが可能となる。その結果、複雑なシステム構成を用いることなく、他人とのコミュニケーションをより活発化させることが可能となる。
また、評価については、高評価が行われたときにしか相手側にフィードバックしないようにしているため、ユーザが評価内容に不満を感じることを軽減して興趣性が下がってしまうことを防ぐことができる。更に、複数のユーザキャラクタを用いている場合、1つのユーザキャラクタについては原則評価は一回のみとする反面、各キャラクタに与えられた高評価の数を集計して表示するようにしている。そのため、よりたくさんの高評価を得るために、より多くのユーザキャラクタを生成し、より多くのすれちがい通信を行うことをユーザに促進させることが可能となる。
なお、上記実施形態では、「あいさつ」の内容については、文字列のみの場合を例に挙げたが、この他、ユーザが自由な表現で作成することができるものであれば、画像や音声なども含むようにしてもよい。また、ゲーム装置1上で作成されるものに限られず、外部の装置で作成されたものを利用可能としてもよい。また、その他、例えば、「あいさつ」を表示するときに、ユーザキャラクタに所定のアクションを行わせるようにしてもよい(エモーション動作等)。この場合は、所定のアクションの内容を示すデータを上記「共通あいさつ」や「個別あいさつ」のデータに含めるようにすればよい。
また、「個別あいさつ」を作成するタイミングに関して、上記実施形態では、上記あいさつ選択ウィンドウ105でユーザが「個別あいさつ」の作成を選択したときに、「個別あいさつ」の入力画面に遷移するようにしていた。この他、「個別あいさつ」については、他のタイミングにおいても作成することができるようにしてもよい。例えば、広場アプリのメイン処理の機能の一つとして「個別あいさつ」の作成と記憶が可能にしておき、ユーザは、この機能を用いて、いくつかの「個別あいさつ」を作成し、ゲーム装置1に記憶させておく。その後、上記の様なあいさつ処理が行われ、上記あいさつ選択ウィンドウ105で、ユーザが「個別あいさつ」の作成を選択したときは、入力画面は表示せずに、代わりに、上記の機能を用いて事前に作成しておいた「個別あいさつ」を選択肢(一覧)として表示させる。そして、ユーザにこの中から「個別あいさつ」を1つ選択させるようにすればよい。
また、上記実施形態では、すれちがい通信は「スリープモード」のときに行われる場合を例に挙げたが、「スリープモード」以外の状態においても上記すれちがい通信が行われるように構成しても良い。
また、上記実施形態では、送受信するゲーム装置1が共に携帯型ゲーム装置である場合を例に挙げたが、この他、いずれか一方は据置型ゲーム装置であってもよい。例えば、窓際に設置された据置型ゲーム装置と、その近くを通りがかったユーザの携帯型ゲーム装置との間で上記のようなすれちがい通信によりユーザキャラクタの送受信が行われてもよい。
また、上記ユーザキャラクタに関して、上記実施形態では、ユーザキャラ作成アプリにおいてユーザが作成したユーザキャラクタをすれちがい通信用のユーザキャラクタに設定する場合を例に挙げていたが、この他、上記すれちがい通信によって取得された他のユーザキャラクタを、上記すれちがい通信用のキャラクタ(つまり、自分側から送信するユーザキャラクタ)として設定できるようにしてもよい。
また、上記実施形態においては、他のゲーム装置1から受信した評価データに基づく評価結果を画面に表示する場合を例に挙げていたが、この他、評価結果を音声や振動等を用いてユーザに報知させるようにしてもよい。
また、上記実施形態においては、すれちがい通信によって受信した他のユーザキャラクタを利用したあいさつ処理や評価処理に関する一連の処理については単一の装置(ゲーム装置1)において実行される場合を説明したが、他の実施形態においては、上記一連の処理が複数の情報処理装置からなる情報処理システムにおいて実行されてもよい。例えば、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記一連の処理のうちの一部の処理がサーバ側装置によって実行されてもよい。さらには、端末側装置と、当該端末側装置とネットワークを介して通信可能なサーバ側装置とを含む情報処理システムにおいて、上記一連の処理のうちの主要な処理がサーバ側装置によって実行され、当該端末側装置では一部の処理が実行されてもよい。また、上記情報処理システムにおいて、サーバ側のシステムは、複数の情報処理装置によって構成され、サーバ側で実行するべき処理を複数の情報処理装置が分担して実行してもよい。