図1を参照して、この発明の一実施例であるゲームシステム10は、ビデオゲーム装置(以下、単に「ゲーム装置」という。)12およびコントローラ22を含む。なお、図示は省略するが、この実施例のゲーム装置12は、最大4つのコントローラ22と通信可能に設計されている。また、ゲーム装置12と各コントローラ22とは、無線によって接続される。たとえば、無線通信は、Bluetooth(登録商標)規格に従って実行されるが、赤外線や無線LANなど他の規格に従って実行されてもよい。さらには、有線で接続されても良い。
ゲーム装置12は、略直方体のハウジング14を含み、ハウジング14の前面にはディスクスロット16が設けられる。ディスクスロット16から、ゲームプログラム等を記憶した情報記憶媒体の一例である光ディスク18が挿入されて、ハウジング14内のディスクドライブ54(図2参照)に装着される。図示は省略するが、ディスクスロット16の周囲には、LEDと導光板とが配置され、様々な処理に応答させて、ディスクスロット16を点灯または点滅させることが可能である。
また、ゲーム装置12のハウジング14の前面であり、その上部には、電源ボタン20aおよびリセットボタン20bが設けられ、その下部には、イジェクトボタン20cが設けられる。さらに、リセットボタン20bとイジェクトボタン20cとの間であり、ディスクスロット16の近傍には、外部メモリカード用コネクタカバー28が設けられる。この外部メモリカード用コネクタカバー28の内側には、外部メモリカード用コネクタ62(図2参照)が設けられ、図示しない外部メモリカード(以下、単に「メモリカード」という。)が挿入される。メモリカードは、光ディスク18から読み出したゲームプログラム等をローディングして一時的に記憶したり、このゲームシステム10を利用してプレイしたゲームのゲームデータ(ゲームの結果データまたは途中データ)を保存(セーブ)しておいたりするために利用される。ただし、上記のゲームデータの保存は、メモリカードに対して行うことに代えて、たとえばゲーム装置12の内部に設けられるフラッシュメモリ44(図2参照)のような内部メモリに対して行うようにしてもよい。また、メモリカードは、内部メモリのバックアップメモリとして用いるようにしてもよい。さらに、ゲーム装置12では、ゲーム以外の他のアプリケーションを実行することも可能であり、かかる場合には、メモリカードには当該他のアプリケーションのデータを保存することができる。
なお、メモリカードとしては、汎用のSDカードを用いることができるが、メモリスティックやマルチメディアカード(登録商標)のような他の汎用のメモリカードを用いることもできる。
図1では省略するが、ゲーム装置12のハウジング14の後面には、AVケーブルコネクタ58(図2参照)が設けられ、そのAVコネクタ58を用いて、AVケーブル32aを通してゲーム装置12にモニタ34およびスピーカ34aを接続する。このモニタ34およびスピーカ34aは典型的にはカラーテレビジョン受像機であり、AVケーブル32aによって、ゲーム装置12からの映像信号がカラーテレビのビデオ入力端子に入力され、ゲーム装置12からの音声信号が音声入力端子に入力される。したがって、カラーテレビ(モニタ)34の画面上にたとえば3次元(3D)ビデオゲームのゲーム画像が表示され、左右のスピーカ34aからゲーム音楽や効果音などのステレオゲーム音声が出力される。また、モニタ34の周辺(この実施例では、モニタ34の上側)には、2つの赤外LED(マーカ)34m,34nを備えるマーカ部34bが設けられる。このマーカ部34bは、電源ケーブル32bを通してゲーム装置12に接続される。したがって、マーカ部34bには、ゲーム装置12から電源が供給される。これによって、マーカ34m,34nは発光し、それぞれモニタ34の前方に向けて赤外光を出力する。
なお、ゲーム装置12の電源は、一般的なACアダプタ(図示せず)によって与えられる。ACアダプタは家庭用の標準的な壁ソケットに差し込まれ、ゲーム装置12は、家庭用電源(商用電源)を、駆動に適した低いDC電圧信号に変換する。他の実施例では、電源としてバッテリが用いられてもよい。
このゲームシステム10において、ユーザまたはプレイヤがゲーム(またはゲームに限らず、他のアプリケーション)をプレイするために、ユーザはまずゲーム装置12の電源をオンし、次いで、ユーザはビデオゲーム(もしくはプレイしたいと思う他のアプリケーション)のプログラムを記録している適宜の光ディスク18を選択し、その光ディスク18をゲーム装置12のディスクドライブ54にローディングする。応じて、ゲーム装置12がその光ディスク18に記録されているプログラムに基づいてビデオゲームもしくは他のアプリケーションを実行し始めるようにする。ユーザはゲーム装置12に入力を与えるためにコントローラ22を操作する。たとえば、入力手段26のどれかを操作することによってゲームもしくは他のアプリケーションをスタートさせる。また、入力手段26に対する操作以外にも、コントローラ22自体を動かすことによって、動画オブジェクト(プレイヤオブジェクト)を異なる方向に移動させ、または3Dのゲーム世界におけるユーザの視点(カメラ位置)を変化させることができる。
ただし、ビデオゲームや他のアプリケーションのプログラムは、ゲーム装置12の内部メモリ(フラッシュメモリ42(図2参照))に記憶(インストール)しておき、当該内部メモリから実行するようにしてもよい。かかる場合には,光ディスク18のような記憶媒体に記憶されたプログラムを内部メモリにインストールしてもよいし、ダウンロードされたプログラムを内部メモリにインストールしてもよい。
図2は図1実施例のビデオゲームシステム10の電気的な構成を示すブロック図である。図示は省略するが、ハウジング14内の各コンポーネントは、プリント基板に実装される。図2に示すように、ゲーム装置12には、CPU40が設けられ、ゲームプロセッサとして機能する。また、CPU40には、システムLSI42が接続される。このシステムLSI42には、外部メインメモリ46、ROM/RTC48、ディスクドライブ54およびAV IC56が接続される。
外部メインメモリ46は、ゲームプログラム等のプログラムを記憶したり、各種データを記憶したりして、CPU40のワーク領域やバッファ領域として用いられる。ROM/RTC48は、いわゆるブートROMであり、ゲーム装置12の起動用のプログラムが組み込まれるとともに、時間をカウントする時計回路が設けられる。ディスクドライブ54は、光ディスク18からプログラムやテクスチャデータ等を読み出し、CPU40の制御の下で、後述する内部メインメモリ42eまたは外部メインメモリ46に書き込む。
システムLSI42には、入出力プロセッサ42a、GPU(Graphics Processor Unit)42b,DSP(Digital Signal Processor)42c,VRAM42dおよび内部メインメモリ42eが設けられ、図示は省略するが、これらは内部バスによって互いに接続される。
入出力プロセッサ(I/Oプロセッサ)42aは、データの送受信を実行したり、データのダウンロードを実行したりする。データの送受信やダウンロードについては後述する。
GPU42bは、描画手段の一部を形成し、CPU40からのグラフィクスコマンド(作画命令)を受け、そのコマンドに従ってゲーム画像データを生成する。ただし、CPU40は、グラフィクスコマンドに加えて、ゲーム画像データの生成に必要な画像生成プログラムをGPU42bに与える。
図示は省略するが、上述したように、GPU42bにはVRAM42dが接続される。GPU42bが作画コマンドを実行するにあたって必要なデータ(画像データ:ポリゴンデータやテクスチャデータなどのデータ)は、GPU42bがVRAM42dにアクセスして取得する。ただし、CPU40は、描画に必要な画像データを、GPU42bを介してVRAM42dに書き込む。GPU42bは、VRAM42dにアクセスして描画のためのゲーム画像データを作成する。
なお、この実施例では、GPU42bがゲーム画像データを生成する場合について説明するが、ゲームアプリケーション以外の任意のアプリケーションを実行する場合には、GPU42bは当該任意のアプリケーションについての画像データを生成する。
また、DSP42cは、オーディオプロセッサとして機能し、内部メインメモリ42eや外部メインメモリ46に記憶されるサウンドデータや音波形(音色)データを用いて、スピーカ34aから出力する音、音声或いは音楽に対応するオーディオデータを生成する。
上述のように生成されたゲーム画像データおよびオーディオデータは、AV IC56によって読み出され、AVコネクタ58を介してモニタ34およびスピーカ34aに出力される。したがって、ゲーム画面がモニタ34に表示され、ゲームに必要な音(音楽)がスピーカ34aから出力される。
また、入出力プロセッサ42aには、フラッシュメモリ44、無線通信モジュール50および無線コントローラモジュール52が接続されるとともに、拡張コネクタ60およびメモリカード用コネクタ62が接続される。また、無線通信モジュール50にはアンテナ50aが接続され、無線コントローラモジュール52にはアンテナ52aが接続される。
入出力プロセッサ42aは、無線通信モジュール50を介して、ネットワークに接続される他のゲーム装置や各種サーバと通信することができる。ただし、ネットワークを介さずに、直接的に他のゲーム装置と通信することもできる。入出力プロセッサ42aは、定期的にフラッシュメモリ44にアクセスし、ネットワークへ送信する必要があるデータ(「送信データ」とする)の有無を検出し、当該送信データが有る場合には、無線通信モジュール50およびアンテナ50aを介してネットワークに送信する。また、入出力プロセッサ42aは、他のゲーム装置から送信されるデータ(「受信データ」とする)を、ネットワーク、アンテナ50aおよび無線通信モジュール50を介して受信し、当該受信データをフラッシュメモリ44に記憶する。ただし、受信データが一定の条件を満たさない場合には、当該受信データはそのまま破棄される。さらに、入出力プロセッサ42aは、ダウンロードサーバ(図8に示す104,106など)からダウンロードしたデータ(ダウンロードデータとする)をネットワーク、アンテナ50aおよび無線通信モジュール50を介して受信し、そのダウンロードデータをフラッシュメモリ44に記憶する。
また、入出力プロセッサ42aは、コントローラ22から送信される入力データをアンテナ52aおよび無線コントローラモジュール52を介して受信し、内部メインメモリ42eまたは外部メインメモリ46のバッファ領域に記憶(一時記憶)する。入力データは、CPU40の処理(たとえば、ゲーム処理)によって利用された後、バッファ領域から消去される。
なお、この実施例では、上述したように、無線コントローラモジュール52は、Bluetooth規格に従ってコントローラ22との間で通信を行う。
さらに、入出力プロセッサ42aには、拡張コネクタ60およびメモリカード用コネクタ62が接続される。拡張コネクタ60は、USBやSCSIのようなインターフェイスのためのコネクタであり、外部記憶媒体のようなメディアを接続したり、コントローラ22とは異なる他のコントローラのような周辺機器を接続したりすることができる。また、拡張コネクタ60に有線LANアダプタを接続し、無線通信モジュール50に代えて当該有線LANを利用することもできる。メモリカード用コネクタ62には、メモリカードのような外部記憶媒体を接続することができる。したがって、たとえば、入出力プロセッサ42aは、拡張コネクタ60やメモリカード用コネクタ62を介して、外部記憶媒体にアクセスし、データを保存したり、データを読み出したりすることができる。
詳細な説明は省略するが、図1にも示したように、ゲーム装置12(ハウジング14)には、電源ボタン20a,リセットボタン20bおよびイジェクトボタン20cが設けられる。電源ボタン20aは、システムLSI42に接続される。この電源ボタン20aがオンされると、システムLSI42には、ゲーム装置12の各コンポーネントに図示しないACアダプタを経て電源が供給され、通常の通電状態となるモード(「通常モード」と呼ぶこととする)が設定される。一方、電源ボタン20aがオフされると、システムLSI42には、ゲーム装置12の一部のコンポーネントのみに電源が供給され、消費電力を必要最低限に抑えるモード(以下、「スタンバイモード」という)が設定される。
この実施例では、スタンバイモードが設定された場合には、システムLSI42は、入出力プロセッサ42a、フラッシュメモリ44、外部メインメモリ46、ROM/RTC48および無線通信モジュール50、無線コントローラモジュール52以外のコンポーネントに対して、電源供給を停止する指示を行う。したがって、この実施例では、スタンバイモードにおいて、CPU40がアプリケーションを実行することはない。
なお、システムLSI42には、スタンバイモードにおいても電源が供給されるが、GPU42b、DSP42cおよびVRAM42dへのクロックの供給を停止することにより、これらを駆動しないようにして、消費電力を低減するようにしてある。
また、図示は省略するが、ゲーム装置12のハウジング14内部には、CPU40やシステムLSI42などのICの熱を外部に排出するためのファンが設けられる。スタンバイモードでは、このファンも停止される。
ただし、スタンバイモードを利用したくない場合には、スタンバイモードを利用しない設定にしておくことにより、電源ボタン20aがオフされたときに、すべての回路コンポーネントへの電源供給が完全に停止される。
また、通常モードとスタンバイモードとの切り替えは、コントローラ22の電源スイッチ26hのオン/オフの切り替えによって、遠隔操作によって行うことが可能である。当該遠隔操作を行わない場合には、スタンバイモードにおいて無線コントローラモジュール52aへの電源供給を行わない設定にしてもよい。
リセットボタン20bもまた、システムLSI42に接続される。リセットボタン20bが押されると、システムLSI42は、ゲーム装置12の起動プログラムを再起動する。イジェクトボタン20cは、ディスクドライブ54に接続される。イジェクトボタン20cが押されると、ディスクドライブ54から光ディスク18が排出される。
図3(A)ないし図3(E)は、コントローラ22の外観の一例を示す。図3(A)はコントローラ22の先端面を示し、図3(B)はコントローラ22の上面を示し、図3(C)はコントローラ22の右側面を示し、図3(D)はコントローラ22の下面を示し、そして、図3(E)はコントローラ22の後端面を示す。
図3(A)ないし図3(E)を参照して、コントローラ22は、たとえばプラスチック成型によって形成されたハウジング22aを有している。ハウジング22aは、略直方体形状であり、ユーザが片手で把持可能な大きさである。ハウジング22a(コントローラ22)には、入力手段(複数のボタンないしスイッチ)26が設けられる。具体的には、図3(B)に示すように、ハウジング22aの上面には、十字キー26a,1ボタン26b,2ボタン26c,Aボタン26d,−ボタン26e,HOMEボタン26f,+ボタン26gおよび電源スイッチ26hが設けられる。また、図3(C)および図3(D)に示すように、ハウジング22aの下面に傾斜面が形成されており、この傾斜面に、Bトリガースイッチ26iが設けられる。
十字キー26aは、4方向プッシュスイッチであり、矢印で示す4つの方向、前(または上)、後ろ(または下)、右および左の操作部を含む。この操作部のいずれか1つを操作することによって、プレイヤによって操作可能なキャラクタまたはオブジェクト(プレイヤキャラクタまたはプレイヤオブジェクト)の移動方向を指示したり、カーソルの移動方向を指示したりすることができる。
1ボタン26bおよび2ボタン26cは、それぞれ、押しボタンスイッチである。たとえば3次元ゲーム画像を表示する際の視点位置や視点方向、すなわち仮想カメラの位置や画角を調整する等のゲームの操作に使用される。または、1ボタン26bおよび2ボタン26cは、Aボタン26dおよびBトリガースイッチ26iと同じ操作或いは補助的な操作をする場合に用いるようにしてもよい。
Aボタンスイッチ26dは、押しボタンスイッチであり、プレイヤキャラクタまたはプレイヤオブジェクトに、方向指示以外の動作、すなわち、打つ(パンチ)、投げる、つかむ(取得)、乗る、ジャンプするなどの任意のアクションをさせるために使用される。たとえば、アクションゲームにおいては、ジャンプ、パンチ、武器を動かすなどを指示することができる。また、ロールプレイングゲーム(RPG)やシミュレーションRPGにおいては、アイテムの取得、武器やコマンドの選択および決定等を指示することができる。また、Aボタンスイッチ26dは、ゲーム画面上でポインタ(指示画像)が指示するアイコンないしボタン画像の決定を指示するために使用される。たとえば、アイコンやボタン画像が決定されると、これらに対応して予め設定されている指示ないし命令(ゲームのコマンド)を入力することができる。
−ボタン26e、HOMEボタン26f、+ボタン26gおよび電源スイッチ26hもまた、押しボタンスイッチである。−ボタン26eは、ゲームモードを選択するために使用される。HOMEボタン26fは、ゲームメニュー(メニュー画面)を表示するために使用される。+ボタン26gは、ゲームを開始(再開)したり、一時停止したりするなどのために使用される。電源スイッチ26hは、ゲーム装置12の電源を遠隔操作によってオン/オフするために使用される。
なお、この実施例では、コントローラ22自体をオン/オフするための電源スイッチは設けておらず、コントローラ22の入力手段26のいずれかを操作することによってコントローラ22はオンとなり、一定時間(たとえば、30秒)以上操作しなければ自動的にオフとなるようにしてある。
Bトリガースイッチ26iもまた、押しボタンスイッチであり、主として、弾を撃つなどのトリガを模した入力を行ったり、コントローラ22で選択した位置を指定したりするために使用される。また、Bトリガースイッチ26iを押し続けると、プレイヤオブジェクトの動作やパラメータを一定の状態に維持することもできる。また、一定の場合には、Bトリガースイッチ26iは、通常のBボタンと同様に機能し、Aボタン26dによって決定したアクションやコマンドなどを取り消すなどのために使用される。
また、図3(E)に示すように、ハウジング22aの後端面に外部拡張コネクタ22bが設けられ、また、図3(B)に示すように、ハウジング22aの上面であり、後端面側にはインジケータ22cが設けられる。外部拡張コネクタ22bは、コントローラ22とは異なる拡張コントローラ(図示せず)を接続するためなどに使用される。インジケータ22cは、たとえば、4つのLEDで構成される。たとえば、インジケータ22cでは、4つのうちのいずれか1つを点灯させることにより、点灯したLEDに応じて、コントローラ22の識別情報(コントローラ番号)を示すことができる。また、インジケータ22cでは、点灯させるLEDの個数によってコントローラ22の電池残量を示すこともできる。
さらに、コントローラ22は、撮像情報演算部80(図4参照)を有しており、図3(A)に示すように、ハウジング22aの先端面には撮像情報演算部80の光入射口22dが設けられる。また、コントローラ22は、スピーカ86(図4参照)を有しており、このスピーカ86は、図3(B)に示すように、ハウジング22aの上面であり、1ボタン26bとHOMEボタン26fとの間に設けられる音抜き孔22eに対応して、ハウジング22a内部に設けられる。
なお、図3(A)ないし図3(E)に示したコントローラ22の形状や、各入力手段26の形状、数および設置位置等は単なる一例に過ぎず、それらが適宜改変された場合であっても、本発明を実現できることは言うまでもない。
図4はコントローラ22の電気的な構成を示すブロック図である。この図4を参照して、コントローラ22はプロセッサ70を含み、このプロセッサ70には、内部バス(図示せず)によって、外部拡張コネクタ22b、入力手段26、メモリ72、加速度センサ74、無線モジュール76、撮像情報演算部80、LED82(インジケータ22c)、バイブレータ84、スピーカ86および電源回路88が接続される。また、無線モジュール76には、アンテナ78が接続される。
なお、簡単のため、図4では省略するが、上述したように、インジケータ22cは4つのLED82によって構成される。
プロセッサ70は、コントローラ22の全体制御を司り、入力手段26、加速度センサ74および撮像情報演算部80によって入力された情報(入力情報)を、入力データとして無線モジュール76およびアンテナ78を介してゲーム装置12に送信(入力)する。このとき、プロセッサ70は、メモリ72を作業領域ないしバッファ領域として用いる。また、上述した入力手段26(26a−26i)からの操作信号(操作データ)は、プロセッサ70に入力され、プロセッサ70は操作データを一旦メモリ72に記憶する。
加速度センサ74は、コントローラ22の縦方向(y軸方向)、横方向(x軸方向)および前後方向(z軸方向)の3軸で各々の加速度を検出する。この加速度センサ74は、典型的には、静電容量式の加速度センサであるが、他の方式のものを用いるようにしてもよい。
たとえば、加速度センサ74は、第1所定時間毎に、x軸,y軸,z軸の各々についての加速度(ax,ay,az)を検出し、検出した加速度のデータ(加速度データ)をプロセッサ70に入力する。たとえば、加速度センサ74は、各軸方向の加速度を、−2.0g〜2.0g(gは重力加速度である。以下、同じ。)の範囲で検出する。プロセッサ70は、加速度センサ74から与えられる加速度データを、第2所定時間毎に検出し、一旦メモリ72に記憶する。
プロセッサ70は、操作データ、加速度データおよび後述するマーカ座標データの少なくとも1つを含む入力データを作成し、作成した入力データを、第3所定時間(たとえば、5msec)毎にゲーム装置12に送信する。
なお、図3(A)−図3(E)では省略したが、この実施例では、加速度センサ74は、ハウジング22a内部の基板上の十字キー26aが配置される付近に設けられる。
ここで、加速度センサ74から出力される加速度データに基づいて、ゲーム装置12のプロセッサ(たとえば、CPU40)またはコントローラ22のプロセッサ(たとえば、プロセッサ70)などのコンピュータが処理を行うことによって、コントローラ22に関するさらなる情報を推測または算出(判定)することができることは、当業者であれば本明細書の説明から容易に理解できるであろう。
たとえば、コントローラ22に1軸の加速度センサ74を搭載し、当該コントローラ22が静的な状態であることを前提としてコンピュータ側で処理する場合、すなわち、加速度センサ74によって検出される加速度が重力加速度のみであるとして処理する場合、コントローラ22が現実に静的な状態であれば、検出された加速度データに基づいてコントローラ22の姿勢が重力方向に対して傾いているか否かまたはどの程度傾いているかを知ることができる。具体的には、加速度センサ74の検出軸が鉛直下方向である状態を基準としたとき、1G(重力加速度)がかかっているか否かだけで傾いているか否かを知ることができるし、その大きさによってどの程度傾いているかを知ることもできる。
また、コントローラ22に多軸の加速度センサ74を搭載する場合には、さらに各軸の加速度データに対して処理を施すことによって、重力方向に対してどの程度傾いているかをより詳細に知ることができる。この場合において、加速度センサ74の出力に基づいて、プロセッサ70がコントローラ22の傾き角度のデータを算出する処理を行ってもよいが、当該傾き角度のデータの算出処理を行うことなく、加速度センサ74からの出力に基づいて、おおよその傾きを推定できるような処理としてもよい。このように、加速度センサ74をプロセッサ70と組み合わせることによって、コントローラ22の傾き、姿勢または位置を判定することができる。
一方、加速度センサ74が動的な状態を前提とする場合には、重力加速度成分に加えて加速度センサの動きに応じた加速度を検出するので、重力加速度成分を所定の処理により除去すれば、動きの方向などを知ることができる。具体的には、加速度センサ74を搭載するコントローラ22がユーザの手で動的に加速されて動かされている場合に、加速度センサ74によって生成される加速度データを処理することによって、コントローラ22の様々な動きおよび/または位置を算出することができる。
なお、加速度センサ74が動的な状態であることを前提とする場合であっても、加速度センサ74の動きに応じた加速度を所定の処理により除去すれば、重力方向に対する傾きを知ることができる。他の実施例では、加速度センサ74は、加速度データをプロセッサ70に出力する前に、内蔵の加速度検出手段から出力される加速度信号(加速度データ)に対して所望の処理を行うための、組込み式の信号処理装置また他の種類の専用の処理装置を備えてもよい。たとえば、組込み式または専用の処理装置は、加速度センサ74が静的な加速度(たとえば、重力加速度)を検出するためのものである場合、検知された加速度データをそれに相当する傾斜角(あるいは、他の好ましいパラメータ)に変換するものであってもよい。
無線モジュール76は、たとえばBluetoothの技術を用いて、所定周波数の搬送波を入力データで変調し、その微弱電波信号をアンテナ78から放射する。つまり、入力データは、無線モジュール76によって微弱電波信号に変調されてアンテナ78(コントローラ22)から送信される。この微弱電波信号が上述したゲーム装置12に設けられた無線コントローラモジュール52によって受信される。受信された微弱電波は、復調および復号の処理を施され、したがって、ゲーム装置12(CPU40)は、コントローラ22からの入力データを取得することができる。そして、CPU40は、取得した入力データとアプリケーションプログラム(ゲームプログラム)とに従ってアプリケーションの処理(ゲーム処理)を行う。
さらに、上述したように、コントローラ22には、撮像情報演算部80が設けられる。この撮像情報演算部80は、赤外線フィルタ80a、レンズ80b、撮像素子80cおよび画像処理回路80dによって構成される。赤外線フィルタ80aは、コントローラ22の前方から入射する光から赤外線のみを通過させる。上述したように、モニタ34の表示画面近傍(周辺)に配置されるマーカ340mおよび340nは、モニタ34の前方に向かって赤外光を出力する赤外LEDである。したがって、赤外線フィルタ80aを設けることによってマーカ340mおよび340nの画像をより正確に撮像することができる。レンズ80bは、赤外線フィルタ80aを透過した赤外線を集光して撮像素子80cへ出射する。撮像素子80cは、たとえばCMOSセンサあるいはCCDのような固体撮像素子であり、レンズ80bによって集光された赤外線を撮像する。したがって、撮像素子80cは、赤外線フィルタ80aを通過した赤外線だけを撮像して画像データを生成する。以下では、撮像素子80cによって撮像された画像を撮像画像と呼ぶ。撮像素子80cによって生成された画像データは、画像処理回路80dで処理される。画像処理回路80dは、撮像画像内における撮像対象(マーカ340mおよび340n)の位置を算出し、第4所定時間毎に、当該位置を示す各座標値を撮像データ(後述するマーカ座標データ)としてプロセッサ70に出力する。なお、画像処理回路80dにおける処理については後述する。
図5は、コントローラ22を用いてゲームプレイするときの状態を概説する図解図である。図5に示すように、ビデオゲームシステム10でコントローラ22を用いてゲームをプレイする際、プレイヤは、一方の手でコントローラ22を把持する。厳密に言うと、プレイヤは、コントローラ22の先端面(撮像情報演算部80が撮像する光の入射口22d側)がマーカ340mおよび340nの方を向く状態でコントローラ22を把持する。ただし、図1からも分かるように、マーカ340mおよび340nは、モニタ34の画面の横方向と平行に配置されている。この状態で、プレイヤは、コントローラ22が指示する画面上の位置を変更したり、コントローラ22と各マーカ340mおよび340nとの距離を変更したりすることによってゲーム操作を行う。
図6は、マーカ340mおよび340nと、コントローラ22との視野角を説明するための図である。図6に示すように、マーカ340mおよび340nは、それぞれ、視野角θ1の範囲で赤外光を放射する。また、撮像情報演算部80の撮像素子80cは、コントローラ22の視線方向を中心とした視野角θ2の範囲で入射する光を受光することができる。たとえば、マーカ340mおよび340nの視野角θ1は、共に34°(半値角)であり、一方、撮像素子80cの視野角θ2は41°である。プレイヤは、撮像素子80cが2つのマーカ340mおよび340nからの赤外光を受光することが可能な位置および向きとなるように、コントローラ22を把持する。具体的には、撮像素子80cの視野角θ2の中にマーカ340mおよび340nの少なくとも一方が存在し、かつ、マーカ340mまたは340nの少なくとも一方の視野角θ1の中にコントローラ22が存在する状態となるように、プレイヤはコントローラ22を把持する。この状態にあるとき、コントローラ22は、マーカ340mおよび340nの少なくとも一方を検知することができる。プレイヤは、この状態を満たす範囲でコントローラ22の位置および向きを変化させることによってゲーム操作を行うことができる。
なお、コントローラ22の位置および向きがこの範囲外となった場合、コントローラ22の位置および向きに基づいたゲーム操作を行うことができなくなる。以下では、上記範囲を「操作可能範囲」と呼ぶ。
操作可能範囲内でコントローラ22が把持される場合、撮像情報演算部80によって各マーカ340mおよび340nの画像が撮像される。すなわち、撮像素子80cによって得られる撮像画像には、撮像対象である各マーカ340mおよび340nの画像(対象画像)が含まれる。図7は、対象画像を含む撮像画像の一例を示す図である。対象画像を含む撮像画像の画像データを用いて、画像処理回路80dは、各マーカ340mおよび340nの撮像画像における位置を表す座標(マーカ座標)を算出する。
撮像画像の画像データにおいて対象画像は高輝度部分として現れるため、画像処理回路80dは、まず、この高輝度部分を対象画像の候補として検出する。次に、画像処理回路80dは、検出された高輝度部分の大きさに基づいて、その高輝度部分が対象画像であるか否かを判定する。撮像画像には、対象画像である2つのマーカ340mおよび340nに対応する画像340m’および340n’のみならず、窓からの太陽光や部屋の蛍光灯の光によって対象画像以外の画像が含まれていることがある。高輝度部分が対象画像であるか否かの判定処理は、対象画像である画像340m’および340n’と、それ以外の画像とを区別し、対象画像を正確に検出するために実行される。具体的には、当該判定処理においては、検出された高輝度部分が、予め定められた所定範囲内の大きさであるか否かが判定される。そして、高輝度部分が所定範囲内の大きさである場合には、当該高輝度部分は対象画像を表すと判定される。逆に、高輝度部分が所定範囲内の大きさでない場合には、当該高輝度部分は対象画像以外の画像を表すと判定される。
さらに、上記の判定処理の結果、対象画像を表すと判定された高輝度部分について、画像処理回路80dは当該高輝度部分の位置を算出する。具体的には、当該高輝度部分の重心位置を算出する。ここでは、当該重心位置の座標をマーカ座標と呼ぶ。また、重心位置は撮像素子80cの解像度よりも詳細なスケールで算出することが可能である。ここでは、撮像素子80cによって撮像された撮像画像の解像度が126×96であるとし、重心位置は1024×768のスケールで算出されるものとする。つまり、マーカ座標は、(0,0)から(1024,768)までの整数値で表現される。
なお、撮像画像における位置は、撮像画像の左上を原点とし、下向きをY軸正方向とし、右向きをX軸正方向とする座標系(XY座標系)で表現されるものとする。
また、対象画像が正しく検出される場合には、判定処理によって2つの高輝度部分が対象画像として判定されるので、2箇所のマーカ座標が算出される。画像処理回路80dは、算出された2箇所のマーカ座標を示すデータを出力する。出力されたマーカ座標のデータ(マーカ座標データ)は、上述したように、プロセッサ70によって入力データに含まれ、ゲーム装置12に送信される。
ゲーム装置12(CPU40)は、受信した入力データからマーカ座標データを検出すると、このマーカ座標データに基づいて、モニタ34の画面上におけるコントローラ22の指示位置(指示座標)と、コントローラ22からマーカ340mおよび340nまでの各距離とを算出することができる。具体的には、2つのマーカ座標の中点の位置から、コントローラ22の向いている位置すなわち指示位置が算出される。また、撮像画像における対象画像間の距離が、コントローラ22と、マーカ340mおよび340nとの距離に応じて変化するので、2つのマーカ座標間の距離を算出することによって、ゲーム装置12はコントローラ22とマーカ340mおよび340nとの間の距離を把握できる。
図8は上述のゲーム装置12を用いた通信システム(ネットワークゲームシステム110を含む。)100の一例を示す図解図である。図8に示すように、通信システム100は、複数のゲーム装置12を含み、各ゲーム装置12はインターネットやLANのようなネットワーク108を介して、メールサーバ102、配信サーバ104およびゲームサーバ106に接続される。このようなネットワーク108に接続されることによって、メールサーバ102を介したメッセージの送受信や配信サーバ104またはゲームサーバ106からのデータのダウンロードを行うことが可能となる。
なお、この実施例では、複数のゲーム装置12がネットワーク108に接続されている場合について説明するが、通信ゲームは2台または3台以上のゲーム装置12でプレイするため、少なくとも2台のゲーム装置12がネットワーク108に接続されていればよい。また、配信サーバ104は、ダウンロードデータ(コンテンツ)の種類に応じて複数設けられてもよい。さらに、ゲームサーバ106は、ゲームの種類に応じて複数設けられてもよい。後述するように、この実施例では、ゲームサーバ106は、ゲームプログラムを配信するサーバとしても機能する。ただし、ゲームサーバ106とは別個独立に、ゲームプログラムを配信するサーバを設けるようにしてもよい。たとえば、配信サーバ104がそのゲームプログラムを配信するようにしてもよい。
また、ネットワーク108にはPCも接続され、さらに、携帯電話網(図示せず)を介して携帯電話機も接続される。それら以外にも、様々な電子機器をネットワーク108に接続して、メールサーバ102を介してゲーム装置12とメッセージの送受信を行うことができる。
ゲーム装置12同士は、ネットワーク108を介して通信可能である。プレイヤが入力したメッセージやゲーム装置12で生成したメッセージは、電子メールの形式に変換され、ネットワーク108およびメールサーバ102を介して、ゲーム装置12同士で送受信(やり取り)される。このため、メールサーバ102は、汎用的なメールサーバを用いることができる。したがって、ゲーム装置12は、PCや携帯電話機のような端末(他のゲーム装置12以外の端末)との間でメッセージすなわち電子メールをやり取りすることも可能である。このようなゲーム装置12におけるメッセージの送受信の処理は、ユーザが送受信指示を行わなくとも所定のスケジュールで自動的に実行されるので、ユーザは定期的なチェック作業を自ら行わなくとも、メッセージを受け取った状態でゲームをプレイしたり、他のアプリケーションを実行したりすることができる。また、ゲーム装置12は、アドレス帳(後述する本体フレンドリスト44d)に宛先を登録したゲーム装置12またはゲーム装置12以外の端末(以下、単に「他の端末」ということがある)との間でのみメッセージの送受信を行うようにすることもでき、したがって汎用的なメールシステムを用いてもスパムメールのような不要なメッセージをユーザが受け取らないようにすることが可能である。
また、ゲーム装置12は、受信したメッセージをモニタ34に表示するためのアプリケーションである伝言板機能を実行することができる。ただし、その他のアプリケーション(ゲーム等)に依存する固有のメッセージであって、当該アプリケーションによってのみ利用されるデータについては、当該アプリケーションでのみ読み取り可能とすることができる。したがって、特定のユーザのみにメッセージを送りたい場合には、個々のアプリケーションに依存するデータをメッセージに含めて送信すれば、伝言板機能では読めない形式にすることができる。ただし、アプリケーションの種類に拘わらず参照可能なメッセージは、伝言板機能によってモニタ34に表示して誰でも参照する(読む)ことができる。
伝言板機能は、受信したメッセージをモニタ34に表示する機能を有するアプリケーションであり、ネットワーク108から取得したメッセージを表示する。ただし、他のゲーム装置12や他の端末から受信したメッセージのみならず、自身宛に作成したメッセージを同様に表示することもできる。したがって、ゲーム装置12がネットワーク108に接続されていない場合であっても、家庭内の伝言板ないし個人用のメモ帳として、この伝言板機能を利用することができるし、ゲーム等のアプリケーションによって生成された記録を後から伝言板機能によって閲覧できるようにしておくこともできる。このとき、ゲーム装置12において生成されたメッセージを、ネットワーク108から取得したメッセージと同様の形式(本実施例においては電子メール形式)で同じ領域に記憶しておくようにすれば、表示のための処理を個別に用意する必要がなくなる。たとえば、メモまたは伝言を生成する際に電子メール形式のデータに変換を行ったり、ゲームプログラムの処理において電子メール形式のデータを生成したりすればよい。
図9は、ゲーム装置12に内蔵されるフラッシュメモリ44に記憶されるデータの構成を模式的に示した図解図である。この図9を用いて、本実施例におけるメッセージの送受信処理とダウンロード処理について概要を説明する。
なお、図9で説明するダウンロード処理は、タスクに従って入出力プロセッサ42aによって実行されるが、後述するように、プレイヤの指示に従ってCPU40によって実行される場合もある。
ゲーム装置12は、メールサーバ102とメッセージの送受信を行い、配信サーバ104やゲームサーバ106からデータのダウンロードを行い、2種類の通信処理を行う。メッセージの送受信処理およびタスク(図10参照)に従うダウンロード処理は、入出力プロセッサ42aによって実行される。
フラッシュメモリ44は、記憶領域として、送信メッセージボックス44a、受信メッセージボックス44b、管理用ファイル44c、本体フレンドリスト44d、タスクリスト44e、セーブ領域44f、データベース44gおよび本体アプリ領域44hを含む。
送信メッセージボックス44aは、ゲーム装置12から他のゲーム装置12や他の端末に送信する電子メール形式のメッセージ(送信データ)を記憶する領域である。図9からも分かるように、送信データは、メールサーバ102に送信される。したがって、ゲーム装置12は、メールサーバ102およびネットワーク108を介して、他のゲーム装置12にメッセージを送信することができる。入出力プロセッサ42aは、所定のスケジュールに基づいて(たとえば、10分毎に)送信メッセージボックス44aを参照し、送信データが記憶されている場合には、記憶されている送信データをネットワーク108に送信する。送信データがネットワーク108に送信されると、当該送信データは送信メッセージボックス44aから削除される。
したがって、電子メールの送信を入出力プロセッサ42aがアプリケーションとは独立に行うので、伝言板機能やゲーム等、CPU40で実行されるアプリケーションでは、メッセージの作成後、当該メッセージを電子メール形式で送信メッセージボックス44aに記録しておく処理を行うだけで、メッセージをネットワーク108に対して送信することができる。
なお、本実施例においては、より汎用的な電子メール形式のデータをメールサーバ102との間で送受信するが、データの形式は電子メールに限られず、さまざまなフォーマットにて転用可能である。特にゲーム装置12同士の通信に限られる場合は、汎用的なフォーマットでなくとも良いし、他の端末と通信する場合であっても、当該他の端末で処理可能なフォーマットであれば適用することができる。また、電子メールを受信する端末からのアクセスがあるまで、当該電子メールを保持する性質のものであれば、メールサーバ102以外の種類のサーバを適用することもできる。
また、何らかの理由でゲーム装置12の送信機能が停止されていたり、通信障害が発生したりしている場合には、送信データの送信が行われないため、送信メッセージボックス44aのデータ量が一杯になる可能性がある。かかる場合には、送信メッセージボックス44aへの送信メッセージの登録を受け付けないようにする。
受信メッセージボックス44bは、他のゲーム装置12、他の端末や配信サーバ104から送信される電子メール形式のメッセージ(受信データ)を記憶する領域である。図9からも分かるように、受信データは、メールサーバ102、配信サーバ104、ゲームサーバ106から送信される。入出力プロセッサ42aは、所定のスケジュールに基づいて(たとえば、10分毎に)メールサーバ102にアクセスして、当該メールサーバ102に新着メールがあるかどうかを確認し、新着メールがある場合に、当該新着メールを受信して受信データとして受信メッセージボックス44bに記憶する。受信メッセージボックス44bでは、受信データは、アプリケーションによって開かれ(使用され)、削除されるか、当該受信メッセージボックス44bが一杯になるまで保持される。ただし、受信メッセージボックス44bが一杯になると、新たな受信データを受信する毎に、最も古い受信データから順に削除される。また、ゲーム装置12が通常モードである場合に、受信メッセージボックス44bに保持された受信データは、ゲームデータのようなアプリケーションに依存するデータが添付されたものを除いて、ヘッダ情報に従ってデータベース44gに移動され、伝言板機能によって読み出し可能な状態となる。
なお、メールサーバ102からの受信データは、他のゲーム装置12や他の端末からのメッセージである。また、配信サーバ104やゲームサーバ106からの受信データは、配信サーバ104やゲームサーバ106の管理者等からの複数ユーザに対するお知らせのようなメッセージである。たとえば、配信サーバ104やゲームサーバ106の管理者等からは、新作のゲームアプリケーション(ゲームソフト)の情報やゲーム内におけるイベントの情報などのメッセージが送信(通知)される。配信サーバ104やゲームサーバ106から受信したデータを受信メッセージボックス44bに記憶する処理の詳細については後述する。
管理用ファイル44cは、ゲーム装置12についての管理情報であり、ゲーム装置12の識別情報、ユーザのプロファイルなど、ゲーム装置12固有の情報が記憶され、必要に応じて読み出される。詳細な説明は省略するが、たとえば、ユーザのプロファイルとしては、アプリケーションの実行により、アプリケーション毎に割り当てられるユーザの識別情報(後述するプロファイルIDを含む)が該当する。
本体フレンドリスト44dは、いわゆる電子メールのアドレス帳に相当し、登録した他のゲーム装置12の識別情報(またはメールアドレス)および他の端末のメールアドレスが記述される。この本体フレンドリスト44dは、伝言板機能を実行する場合に参照可能であるのみならず、各種アプリケーションからも参照可能である。
ただし、本体フレンドリスト44dに記述された他のゲーム装置12の識別情報および他の端末のメールアドレスのうち、フレンド登録(アドレス登録)が実行された他のゲーム装置12の識別情報または他の端末のメールアドレスから送信された電子メール(受信データ)以外は受信メッセージボックス44bから削除される。つまり、送信元が不明である場合には、受信データがフィルタリングされる。これによって、スパムメールのような所望でない電子メールを自動的に削除することができる。
タスクリスト44eは、配信サーバ104やゲームサーバ106からデータをダウンロードするスケジュールを表すタスクのリストであって、ゲーム装置12の必要のために予め登録されたタスクやユーザによって任意に登録されたタスクをそれぞれ記憶する。それぞれのタスクが実行されることによって、ダウンロード処理が行われることになる。ただし、この実施例では、1つのアプリケーションにおいては、1つのタスクを登録することができる。
図10に、各タスクに含まれる属性情報の一例を示す。1つのタスクには、タスクの識別情報(タスクID)、アプリケーションの識別情報(アプリID)、配信元のURL、残りダウンロード回数、タスクの起動間隔、リトライマージン、コンテンツ更新間隔およびファイル名が含まれる。
タスクIDは、当該タスクを一意に識別するためのIDである。アプリIDは、当該タスクを登録したアプリケーションを一意に識別するためのIDである。このアプリIDは、タスクの登録処理を行ったアプリケーションに応じて決定される。
配信元のURLは、配信元(配信サーバ104やゲームサーバ106)の場所を示し、ダウンロードデータのファイル名までを含む。この配信元のURLは、ユーザによって設定されたり、アプリケーションによって自動的に設定されたりする。
残りダウンロード回数は、ダウンロードを実行可能な回数を示す。この実施例では、ゲーム装置12(入出力プロセッサ42a)がダウンロードデータを受信するために、ネットワーク108(配信サーバ104やゲームサーバ106)に接続要求(リクエスト)を送信すると、通常の場合において、残りダウンロード回数が1減算される。そして、残りダウンロード回数が0になると、当該タスクはタスクリスト44eから削除され、当該タスクは実行不能となる。このように、残りダウンロード回数を設定することにより、必要な期間においてダウンロードデータの配信を行わせることができ、ダウンロードデータの配信が不要になった場合には、無駄なダウンロード処理を実行し続けることを防ぐことができる。
タスクの起動間隔は、タスクを実行する時間間隔であり、具体的には、タスクを実行してから次に当該タスクを実行するまでの時間(期間)を意味する。ただし、タスクを登録した時点では、その登録時刻を基準にして、次に当該タスクを実行する時間が決定される。このタスクの起動間隔は、ユーザによって設定されたり、ダウンロードデータ(コンテンツ)の種類に応じて自動的に設定されたりする。
リトライマージンは、タスクの起動間隔によって決まる次回のタスクの実行時刻(予定時刻)を超過することが許容される時間である。たとえば、ゲーム装置12の電源が完全にオフされている場合や、ネットワーク108に障害が生じている場合等には、ダウンロード処理(タスク)を実行することができない。その後、ダウンロード処理(タスク)を実行可能な状態になったときに、当該タスクの予定時刻を大幅に超過している場合には、当該タスクの実行によってダウンロードされるダウンロードデータ自体が既に不要になっている場合がある。したがって、タスク登録時に上記リトライマージンを設定し、タスクの起動間隔に応じてタスクの予定時刻が決定されると、リトライマージンに応じて、リトライが許容される時刻(リトライ許容時刻)が決定される。このリトライ許容時刻を越えると、当該タスクは実行されず、その後、タスクリスト44eから削除される。このリトライマージンは、ユーザによって設定されたり、ダウンロードデータの種類に応じて自動的に設定されたりする。
コンテンツ更新間隔は、配信元のURLに関して当該配信元で設定されるコンテンツ(ダウンロードデータ)を更新する間隔の平均値である。したがって、ダウンロードデータの種類によっては、このコンテンツ更新間隔が示すダウンロードデータを更新する間隔の平均値を考慮して、タスク起動間隔が設定される。具体的には、タスク起動間隔をコンテンツ更新間隔よりも長い時間に設定しておけば、同じダウンロードデータを重複して取得するような無駄を無くすことができる。逆に、タスク起動間隔をコンテンツ更新間隔よりも短い時間に設定しておけば、更新されるコンテンツのダウンロードを逃すことが無くなる。更新間隔の平均値は、予め想定されている値でもよいし、ダウンロードを実行する毎に配信サーバ104やゲームサーバ106から更新間隔の平均値を取得してタスクを更新するようにしてもよい。
ファイル名は、ダウンロードデータを保存する場合に付与するファイル名であり、たとえば、オプションによって指定可能である。ただし、ダウンロードデータにはファイル名が付されているため、ファイル名を指定しなくても所定のファイル名でデータを取得することは可能である。
なお、タスクの実行については後で詳細に説明する。ダウンロードデータは、その識別情報(アプリID)が示すアプリケーションにおいて利用することができる。たとえば、ゲームのアプリケーションにおいては、ダウンロードデータは、当該ゲームについての追加マップ、追加キャラクタ、追加アイテムなどのデータである。
図9に戻って、セーブ領域44fは、アプリケーションのデータを保存(セーブ)する領域であり、領域内にダウンロードボックス440を含む。ダウンロードボックス440は、上述したように、タスクに従って配信サーバ104やゲームサーバ106からダウンロードされたダウンロードデータが記憶される領域である。ただし、ダウンロードボックス440には、ユーザの指示に従って、CPU40によって、配信サーバ104やゲームサーバ106からダウンロードされたダウンロードデータも記憶される。
詳細な説明は省略するが、ダウンロードデータには、タスクが登録されたアプリケーションやCPU40が実行中のアプリケーションを識別するためのアプリIDが予め付されている。ただし、アプリIDは必ずしもダウンロードデータに予め付されている必要はなく、他の実施例としては、ダウンロードボックス440に登録する際に、タスクの属性情報が示すアプリIDを参照して、これを付すようにしてもよい。したがって、様々な種類のアプリケーションについてのダウンロードデータがダウンロードボックス440に記憶されている場合であっても、そのアプリIDによって各ダウンロードデータを識別することができる。また、セーブ領域44fは、アプリケーション毎に領域が確保されている。したがって、他の実施例としては、ダウンロードデータに対応したアプリケーションのデータを記憶する領域内にアプリケーション毎のダウンロードボックスを設けることも考えられる。
データベース44gは、上述の伝言板機能によって利用される、日付毎のメッセージを格納しておく領域であり、他のアプリケーションからも参照可能である。上述したように、受信データは受信メッセージボックス44bに記憶されるが、受信メッセージボックス44bの容量は有限であり、一杯になると、受信データは古いものから順に削除される。したがって、メッセージの長期間保存や共用化のために、データベース44gを設け、受信データ(メッセージ)は、たとえばゲームデータが添付されたもののような、個々のアプリケーションでしか利用しないものを除いて、受信メッセージボックス44bからデータベース44gに移動される。このとき、メッセージのヘッダ情報が参照され、日付毎に管理されるデータベース44gの各領域に記憶される。たとえば、伝言板日時指定の情報として年月日および時間が記述されている場合には、当該受信データは指定された年月日に対応する領域に記憶される。ただし、メッセージのヘッダ情報に日時等の指定が無ければ、当該メッセージを受信した日に対応する領域に、当該メッセージは記憶される。日付毎の領域の管理方法としては、たとえば日付毎にフォルダを設定し、メッセージを対応するフォルダ内に保存するようにすればよい。また、保存する際のファイル名を、時刻を表すファイル名にしてもよい。
なお、図示は省略するが、メモリカードがメモリカード用コネクタ62に装着されている場合には、データベース44gの内容はメモリカードに自動的またはユーザの指示によりバックアップすることができる。
本体アプリ領域44hは、本体機能として組み込まれたアプリケーションのプログラム(ソフト)を記憶する領域である。たとえば、ゲーム装置12を起動した際のメニュープログラムや、伝言板機能、フレンド登録機能のようなゲーム装置12自体の機能(本体機能)のアプリケーションは、本体アプリ領域44hに記憶(インストール)されている。つまり、ゲーム装置12は、光ディスク18に記憶されているゲーム等のプログラムを読み出してアプリケーションを実行することも、フラッシュメモリ44に記憶されているプログラムを読み出してアプリケーションを実行することも可能である。また、本体アプリ領域44hに記憶されるプログラムは上述のソフト以外にも追加することが可能である。
ここで、入出力プロセッサ42aによって実行されるダウンロード処理の概要について説明する。ただし、ダウンロード処理は、上述したタスクに記述される配信元のURLに設定されたサーバ(この実施例では、配信サーバ104,ゲームサーバ106)に対して実行される。図11(A)に示すように、或るタスクがタスクリスト44eに登録されると、その時刻t1を基準に当該タスクがスケジューリングされる。たとえば、図11(A)に示す例では、タスクの実行間隔T1に従って時刻(予定時刻)t2に当該タスクがスケジューリングされる。なお、この実行間隔T1が、当該タスクの属性情報のタスク起動間隔に相当する。時刻は、ROM/RTC48から得ることができる。タスクが実行されると、当該実行時刻に実行間隔T1を加えた予定時刻に、次回タスクが実行される。ダウンロードのタスクは、ダウンロードの実行とともに残りダウンロード回数が1減算され、このとき、次回タスクを実行する予定時刻(実行予定時刻)がスケジューリングされる。
図11(B)に示すように、入出力プロセッサ42aの内部では、処理の単位時間となる所定時間毎にトリガが発生し、当該トリガ発生時に、トリガ発生時刻と、前述のメッセージの送受信を行う予定時刻や、ダウンロードを行う予定時刻等とを比較する処理が行われ、予定時刻を超過している場合に当該処理が起動することになる。したがって、トリガの発生時よりも後にタスクがスケジューリングされている場合には、当該タスクは次回のトリガの発生時に実行されるため、タスクの実際の実行時刻は、図11(A)でスケジューリングした予定時刻t2から若干遅れてしまうことがある。
また、図11(C)に示すように、スタンバイモードではなく、ゲーム装置12の電源が完全にオフされた場合のように、タスクの実行自体が停止される場合も有り得る。かかる場合には、再びゲーム装置12が起動した後にタスクが実行されることになるが、タスクの実行時刻にかなりの遅れが生じてしまうことがある。
なお、タスクの実行は、アプリケーションからの要求によって、一時的に停止させたり、再開させたりすることが可能であって、そのような場合にもタスクの実行時刻に遅れが生じる可能性がある。
このように、タスクの実行時刻の遅延が発生した場合、ダウンロードするデータが既に不要なものになっている場合があるので、遅延が発生した場合に、当該タスクの実行を許容するか否かを決定するために、タスクの属性情報として、リトライマージンが設定されている。具体的には、タスクを実行するとき、タスクの実行を開始する時点(現在時刻)が、タスクの実行予定時刻にリトライマージンが示す時間を加算したリトライ許容時刻を越えているかどうかを判断する。そして、現在時刻がリトライ許容時刻を越えている場合には、タスクの実行は行わずに、当該タスクはタスクリスト44eから削除される。一方、現在時刻がリトライ許容時刻に満たない場合には、当該タスクを実行し、以降の処理を続行する。
具体的には、入出力プロセッサ42aは、図12に示すフロー図に従ってタスクに従うダウンロード処理を実行する。このダウンロード処理は、入出力プロセッサ42aがCPU40と独立に実行するものであって、上述のスタンバイモード時であっても実行される。また、CPU40がアプリケーションを実行している間であっても、独立に実行されている。ただし、このダウンロード処理は、タスクが登録されている状態で、上述のように、入出力プロセッサ42a内でトリガが発生する毎に実行され続ける。また、ダウンロード処理は、タスク毎に実行される。
この図12に示すように、入出力プロセッサ42aはステップS1で、タスクを実行するためのトリガ(タスク実行トリガ)の発生を検出する。ステップS1で“NO”であれば、つまりタスク実行トリガが無ければ、そのままステップS1に戻る。一方、ステップS1で“YES”であれば、つまりタスク実行トリガが有れば、ステップS3で、当該タスクの実行予定時刻であるかどうかを判断する。厳密に言うと、ここでは、入出力プロセッサ42aは、現在時刻が実行予定時刻以降であるかどうかを判断する。
ステップS3で“NO”であれば、つまり当該タスクの実行予定時刻でなければ、そのままステップS1に戻る。一方、ステップS3で“YES”であれば、つまり当該タスクの実行予定時刻であれば、ステップS5で、リトライ許容時刻を過ぎているかどうかを判断する。ステップS5で“YES”であれば、つまりリトライ許容時刻を過ぎていれば、ステップS7で、当該タスクをタスクリスト44eから消去して、ダウンロード処理を終了する。
ただし、ダウンロード処理はタスク毎に実行されるので、リトライ許容時刻を過ぎたタスクに関するダウンロード処理が終了するという意味であって、他のタスクについてはそれ以降もトリガ発生とともにダウンロード処理が起動(実行)されることになる。
一方、ステップS5で“NO”であれば、つまりリトライ許容時刻を過ぎていなければ、ステップS9で、サーバ(104,106)に接続要求を送信する。つまり、入出力プロセッサ42aは、当該タスクの属性が示すコンテンツすなわちダウンロードデータの配信元のURLにアクセス要求を送信するのである。続いて、ステップS11で、当該タスクの残りダウンロード回数を1減算する。ここで、図示は省略するが、入出力プロセッサ42aは、残りダウンロード回数が0になった時点で、当該タスクをタスクリスト44eから消去し、次回のダウンロードが行われないようにする。ステップS13では、次回のタスク実行予定時刻をスケジューリングする。
そして、ステップS15では、サーバ(104,106)との接続に成功したかどうかを判断する。ステップS15で“NO”であれば、つまりサーバ(104,106)との接続に失敗すれば、そのままステップS1に戻る。なお、この実施例では、入出力プロセッサ42aは、サーバ(104,106)との接続に失敗すると、直にステップS1に戻るようにしてあるが、所定回数接続要求を送信しても(たとえば、3回のリトライ)、接続に成功しない場合に、ステップS1に戻るようにしてもよい。また、ネットワーク108やサーバ(104,106)にエラーが発生している場合には、リトライを行わないようにしてもよい。さらに、そのようなエラーが発生している場合には、上述の残りダウンロード回数の減算を行うとダウンロードが行われないまま終了してしまう可能性があるので、ステップS11の処理を、ステップS15とステップS17との間で実行するようにしてもよい。
ステップS15で“YES”であれば、つまりサーバ(104,106)との接続に成功すれば、ステップS17で、ダウンロードを実行する。つまり、入出力プロセッサ42aは、ダウンロードデータを取得する。そして、ステップS19で、ダウンロードデータがメッセージ配信用のデータであるかどうかを判断する。たとえば、メッセージ配信用のデータを電子メール形式のデータとし、入出力プロセッサ42aは、取得したダウンロードデータが電子メールの形式であるかどうかを判断する。または、メッセージ配信用のデータであることを示す情報をダウンロードデータに含め、ダウンロード実行後にゲーム装置12において電子メール形式のデータに変換するようにしてもよい。たとえば、メッセージ配信用のデータとして配信される内容としては、配信元(配信サーバ104,ゲームサーバ106)から、新しいアプリケーションの配信を開始したことのメッセージや或るアプリケーションについての追加データを配信したことのメッセージが考えられる。
ステップS19で“YES”であれば、つまりダウンロードデータがメッセージ配信用のデータである場合には、ステップS21で、当該ダウンロードデータを受信データとして受信メッセージボックス44bに格納して、ステップS1に戻る。一方、ステップS19で“NO”であれば、つまりダウンロードデータがメッセージ配信用のデータでない場合には、ステップS23で、当該ダウンロードデータをダウンロードボックス440に格納して、ステップS1に戻る。
なお、受信メッセージボックス44bに格納されたメッセージ配信用のデータは、その後、伝言板機能によってモニタ34に出力され、配信元からのメッセージがプレイヤに通知される。
たとえば、2台以上のゲーム装置12、ゲームサーバ106およびネットワーク108によって、ネットワークゲームシステム110が構成される。ただし、ネットワークゲームシステム110は、メールサーバ102や配信サーバ104を含んでもよい。
このようなネットワークゲームシステム110では、ネットワーク108に接続される或るゲーム装置12がネットワーク108に接続される他のゲーム装置12との間で、通信ゲームをプレイすることができる。以下、具体的に説明するが、この実施例では、親機は通信ゲームへの参加を募集するゲーム装置12を意味し、子機は通信ゲームへの参加を希望するゲーム装置12を意味する。また、この実施例のネットワークゲームシステム110では、所定のゲームについての製品版のゲームプログラムを有するゲーム装置12と、製品版に対応する体験版のゲームプログラムを有するゲーム装置12とが混在する。
図13を参照して、製品版のゲームプログラム200は、スタンドアロンのゲームプログラム210、ネットワーク接続のゲームプログラム212およびゲームデータ220を含む。スタンドアロンのゲームプログラム210は、他のゲーム装置12と通信をしないで、この製品版のゲームプログラム200を有するゲーム装置12単体でゲームをプレイするためのプログラムである。このスタンドアロンのゲームプログラム210は、1人プレイ用ゲームプログラム210aおよび複数人プレイ用ゲームプログラム20bを含む。1人プレイ用ゲームプログラム210aは、ゲーム装置12を用いて1人でゲームをプレイするためのプログラムである。複数人プレイ用ゲームプログラム20bは、ゲーム装置12を用いて2人以上でゲームをプレイするためのプログラムである。
ネットワーク接続のゲームプログラム212は、他のゲーム装置12と通信することにより、通信ゲームをプレイするためのプログラムである。このネットワーク接続のゲームプログラム212は、プロファイルIDの作成要求プログラム212a、ともだち登録プログラム212b、募集プログラム212c、参加プログラム212dおよび通信用ゲームプログラム212eによって構成される。
プロファイルIDの作成要求プログラム212aは、この通信ゲームにおいて主としてユーザ認証のために使用するユーザないしプレイヤのプロファイルIDの作成要求(この実施例では、仮プロファイルID)をゲームサーバ106に送信するためのプログラムである。ただし、作成要求するプロファイルIDは、ゲーム装置12自身(自己)のプロファイルIDである。ともだち登録プログラム212bは、通信ゲームの相手として決定することが可能なともだち(ユーザないしプレイヤ)のリスト(ゲームフレンドリスト)に、ともだちの名称(名前,ニックネーム,呼名など)と、そのともだちのプロファイルIDとを登録するためのプログラムである。
募集プログラム212cは、通信ゲームをプレイするに先立って、当該通信ゲームをプレイする相手を募集するためのプログラムである。この実施例では、ゲームサーバ106が通信ゲームの相手を仲介するため、当該募集プログラム212cを実行することにより、通信ゲームをプレイする相手の募集受付の要求がゲームサーバ106に送信される。参加プログラム212dは、通信ゲームをプレイするに先立って、当該通信ゲームへの参加を要求するためのプログラムである。上述したように、この実施例では、ゲームサーバ106が通信ゲームの相手を仲介するため、当該参加プログラム212dを実行することにより、通信ゲームへの参加の要求がゲームサーバ106に送信される。つまり、この製品版のゲームプログラム200を有するゲーム装置12は、親機(募集プログラムを実行するゲーム装置12)または子機(参加プログラムを実行するゲーム装置12)として通信ゲームに参加することができる。通信用ゲームプログラム212eは、通信ゲームをプレイするためのプログラムであって、当該通信ゲームのメインルーチンを処理するためのプログラムである。この通信用ゲームプログラム212eは、通信ゲームの参加者を募集したり、通信ゲームへの参加を要求したりして、通信ゲームの相手が決定された後に実行される。
ゲームデータ220は、スタンドアロン用のデータ220a、ネットワーク接続用のデータ220bおよび共通のデータ220cを含む。スタンドアロン用のデータ220aは、ゲーム装置12単体でゲームをプレイする場合にのみ用いられる画像データ(ポリゴンやテクスチャなどのデータ。以下、同じ。)などのデータである。ネットワーク接続用のデータ220bは、通信ゲームをプレイする場合にのみ用いられる画像データなどのデータである。共通のデータは、ゲーム装置12単体でゲームをプレイする場合および通信ゲームをプレイする場合に共通して用いられる画像データなどのデータである。
また、図14を参照して、体験版のゲームプログラム200´は、ネットワーク接続のゲームプログラム212´およびゲームデータ220´を含む。図13および図14を参照して分かるように、この体験版のゲームプログラム200´は、製品版のゲームプログラム200の一部によって構成される。具体的には、体験版のゲームプログラム200´には、スタンドアロンのゲームプログラム210は含まれていない。つまり、通信ゲームのみが実行可能である。
なお、図14に示す体験版のゲームプログラム200´においては、図13に示した製品版のゲームプログラム200に含まれるプログラムやゲームデータのうち、同じプログラムや同じゲームデータについては同じ参照符号を付してある。また、同じプログラムや同じゲームデータについての重複した説明は省略することにする。
図14から分かるように、ネットワーク接続のゲームプログラム212´には、募集プログラム212cは含まれていない。つまり、体験版のゲームプログラム200´を有するゲーム装置12では、通信ゲームへの参加の要求ができるだけである。言い換えると、当該ゲーム装置12は通信ゲームにおいて子機としてのみ機能する。また、体験版のゲームプログラム200´には、スタンドアロンのゲームプログラム210は含まれず、ゲーム装置12単体でのゲームをプレイすることができない。このため、ゲームデータ220´には、スタンドアロン用の画像データ220aも記憶されない。
図15および図16は、第1のゲーム装置12と第2のゲーム装置12とが通信ゲームをプレイするまでの流れの一例を時系列に従って示した説明図である。ここでは、簡単のため、2台のゲーム装置12がネットワーク108を介して通信することにより、通信ゲームをプレイするまでの処理について説明するが、3台以上のゲーム装置12が通信ゲームをプレイできることは言うまでもない。この場合、1台のゲーム装置12が親機として働き、他のすべてのゲーム装置12が子機として働く。また、通信ゲームをプレイするプレイヤ同士は、少なくとも知人であることを前提する。
なお、図15および図16では、説明の都合上、第1のゲーム装置12と第2のゲーム装置12との処理がほぼ同時期に実行されるように示してあるが、必ずしも同時期である必要はない。
図15に示すように、第1のゲーム装置12は、ゲームサーバ106の管理者(運営者)またはゲームサーバ106を用いてゲームを提供する提供者から製品版のゲームプログラム200を記憶した光ディスク18を購入する。ただし、製品版のゲームプログラム200が収録された光ディスク18を店頭で購入してもよい。または、後述する体験版のゲームプログラム200´と同様に、製品版のゲームプログラム200をゲームサーバ106からダウンロード可能にしてもよい。なお、製品版のゲームプログラム200をゲームサーバ106からダウンロードする場合には、プリペイドカードやクレジットカード決済等により課金処理が行われる。
一方、第2のゲーム装置12は、体験版のゲームプログラム200´をゲームサーバ106から無料でダウンロードする。つまり、体験版のゲームプログラム200´をゲームサーバ106からダウンロードする場合には、課金処理は行われない。ただし、体験版のゲームプログラム200´が収録された光ディスク18を無料で入手できるようにしてもよい。かかる場合には、体験版のゲームプログラム200´は、たとえば、他のゲームについての製品版のゲームプログラムを記憶した光ディスク18におまけとして記憶されたり、雑誌の付録の光ディスク18に記憶されたり、無料で配布される光ディスク18に記憶されたりする。
ここで、第1のゲーム装置12で、製品版のゲームプログラム200が起動されると、図17(A)に示すメニュー画面300が当該第1のゲーム装置12に接続されるモニタ34に表示される。図17(A)に示すように、このメニュー画面300には、4つのボタン画像(またはアイコン)302,304,306,308が設けられる。このメニュー画面300では、すべてのボタン画像302−308を選択(オン)することができる。ボタン画像302がオンされると、第1のゲーム装置12単体で、1人プレイ用のゲームをプレイすることができる。また、ボタン画像304がオンされると、第1のゲーム装置12単体で、複数人プレイ用のゲームをプレイすることができる。さらに、ボタン画像306がオンされると、他のゲーム装置12との間で通信ゲームをプレイすることが選択される。さらにまた、ボタン画像308がオンされると、後述するように、ゲームフレンド(通信ゲームの相手)のプロファイルIDを登録したり、当該第1のゲーム装置12の(自己の)プロファイルIDを見たりすることができる。
また、第2のゲーム装置12で、体験版のゲームプログラム200´が起動されると、図17(B)に示すようなメニュー画面300´がモニタ34に表示される。このメニュー画面300´では、メニュー画面300と同様に、ボタン画像302−308が表示される。ただし、ボタン画像302とボタン画像304とはグレーアウトされ、オン(選択)することはできない。つまり、この実施例の体験版のゲームプログラム200´では、製品版のゲームプログラム200においてプレイすることができるゲーム装置12単体のゲームを、プレイすることができないのである。
なお、この実施例では、製品版のゲームプログラム200を購入すると、他にプレイできるゲームがあることを知らせるために、メニュー画面300´において、ボタン画像302およびボタン画像304をグレーアウトで表示してあるが、これに限定される必要はない。ボタン画像302およびボタン画像304は表示しなくてもよいし、ボタン画像302およびボタン画像304を選択可能に表示しておき、ボタン画像302およびボタン画像304が選択されたときに、体験版ではプレイできない旨のメッセージをモニタ34に表示するようにしてもよい。
ここで、製品版のゲームプログラム200が初めて起動された場合に、ボタン画像306がオンされると、第1のゲーム装置12は通信ゲームで使用するプロファイルIDの作成をゲームサーバ106に要求する。同様に、体験版のゲームプログラム200´が初めて起動された場合には、ボタン画像306がオンされると、第2のゲーム装置12は通信ゲームで使用するプロファイルIDの作成をゲームサーバ106に要求する。このようにするのは、プロファイルIDが未作成であり、しかも、通信ゲームの相手のプロファイルIDが未登録だからである。
ただし、製品版のゲームプログラム200や体験版のゲームプログラム200´を起動するのが2回目以降であっても、自己のプロファイルIDが登録されていない場合(たとえば、1回目の起動のときにボタン画像306がオンされなかった場合等)には、自己のプロファイルIDの作成がゲームサーバ106に要求される。
図15に戻って、第1のゲーム装置12は、自己のプロファイルIDの作成をゲームサーバ106に要求する。第2のゲーム装置12もまた、自己のプロファイルIDの作成をゲームサーバに106に要求する。
ゲームサーバ106は、第1のゲーム装置12や第2のゲーム装置12からのプロファイルIDの作成要求を受けて、各々のプロファイルIDを作成する。そして、ゲームサーバ106は、作成したプロファイルIDを第1のゲーム装置12および第2のゲーム装置12の各々に送信する。
この実施例では、プロファイルIDは、ゲーム装置12の無線通信モジュール50のMACアドレスと、ゲームコード(ゲームの種類を示すID(アプリID))と、乱数(8バイト)とから構成される。ただし、ゲームサーバ106からゲーム装置12に送信されるプロファイルIDには、CRC(Cyclic Redundancy Check)チェック用のデータが付加される。
第1のゲーム装置12および第2のゲーム装置12の各々は、ゲームサーバ106から送信されたプロファイルIDを受信して、フラッシュメモリ44内の管理用ファイル44cに記憶する。詳細な説明は省略するが、このように、ゲームサーバ106から第1のゲーム装置12や第2のゲーム装置12にプロファイルIDを送信(配信)する場合には、ゲームサーバ106が第1のゲーム装置12や第2のゲーム装置12を宛先として直接的に送信するようにしてもよく、第1のゲーム装置12や第2のゲーム装置12がダウンロード処理を実行するようにしてもよい。ただし、ダウンロード処理は、上述したように、タスクに従って実行することができ、また、ユーザないしプレイヤの指示に従って実行することもできる。
続いて、第1のゲーム装置12のユーザ(プレイヤ)と第2のゲーム装置12のプレイヤとは、互いに自己のプロファイルIDを教え合う。たとえば、プレイヤ同士が、プロファイルIDを、口頭で教え合ってもよいし、手紙や電子メールで教えあってもよい。また、上述したように、第1のゲーム装置12と第2のゲーム装置12とで、メッセージを送受信することにより、プロファイルIDを教え合うこともできる。したがって、第1のゲーム装置12では、第2のゲーム装置12のプロファイルIDを通信ゲームのフレンドリスト(ゲームフレンドリスト)に登録することができる。一方、第2のゲーム装置12では、第1のゲーム装置12のプロファイルIDをゲームフレンドリストに登録することができる。
ここで、図17(A)に示すメニュー画面300において(図17(B)に示すメニュー画面300´も同様)、ボタン画像308が選択されると、図18に示すような友達設定のサブメニュー画面400がモニタ34に表示される。このサブメニュー画面400には、3つのボタン画像402,404,406が表示される。ボタン画像402が選択されると、通信ゲームをプレイすることを許容する相手(ゲームフレンド)を登録することができる。具体的には、図19(A)に示すようなゲームフレンドのプロファイルIDの登録画面420がモニタ34に表示される。この登録画面420には、入力欄422および入力欄424が設けられるとともに、ボタン画像426およびボタン画像428が設けられる。入力欄422には、ゲームフレンドとして登録したプレイヤの名前(名称)が入力される。また、入力欄424には、ゲームフレンドとして登録するプレイヤのプロファイルID(CRCチェック用のデータ付加されている)が入力される。入力欄422に名前が入力され、入力欄424にプロファイルIDが入力された状態で、ボタン画像426がオンされると、プレイヤおよびプロファイルIDが図20に示すようなフレンドリストに登録される。しかし、登録画面420でボタン画像428がオンされると、ゲームフレンドの登録がキャンセルされ、サブメニュー画面400に戻る。
ここで、図20に示すように、ゲームフレンドリストでは、プレイヤの名前ないし名称(プレイヤの識別情報でも可)に対応して、当該プレイヤ(ゲーム装置12)に対して決定されたプロファイルIDが記述される。ただし、図20では、簡単のため、プロファイルIDを5つのアルファベット文字で表現してある。図示は省略するが、このゲームフレンドリストは、フラッシュメモリ44に設けられるセーブ領域44fのうちの当該アプリケーション(この実施例のゲームアプリケーション)に割り当てられた領域に記憶される。
図18に戻って、サブメニュー画面400でボタン画像404がオンされると、図19(B)に示すような自己のプロファイルIDの表示画面440がモニタ34に表示される。図19(B)に示すように、表示画面440には、表示領域442およびボタン画像444が設けられる。表示領域442には、ゲームサーバ106で作成され、ゲーム装置12に登録された自己のプロファイルIDが表示される。ここでも、簡単のため、プロファイルIDを5つのアルファベットで示してある。ただし、厳密に言うと、プロファイルIDにCRCチェック用のデータが付加された文字列が表示される。また、ボタン画像444がオンされると、上述したサブメニュー画面400に戻る。つまり、プレイヤは、表示画面440で自己のプロファイルIDを確認して、上述したように、他のプレイヤ(知人ないし友達)とプロファイルIDを教え合うのである。
図18に戻って、サブメニュー画面400でボタン画像406がオンされると、サブメニュー画面400を終了して、上述したメニュー画面300に戻る。
第1のゲーム装置12と第2のゲーム装置12とで互いのプロファイルIDがゲームフレンドリストに登録されると、図16に示すように、第1のゲーム装置12は、第2のゲーム装置12のプロファイルIDをゲームサーバ106に送信する。一方、第2のゲーム装置12は、第1のゲーム装置12のプロファイルIDをゲームサーバ106に送信する。
ゲームサーバ106では、第1のゲーム装置12および第2のゲーム装置12から送信されたプロファイルIDを受信すると、これらをゲームフレンドリストに登録する。後で詳細に説明するが、ゲームサーバ106は、プレイヤ(ゲーム装置12)毎のデータ(プレイヤデータ)を管理し、このプレイヤデータに対応するプレイヤのゲームフレンドリストが含まれる。図示は省略するが、ゲームサーバ106で管理されるプレイヤデータに含まれるゲームフレンドリストは、当該プレイヤのゲーム装置12に登録されている当該ゲームについてのゲームフレンドリストの内容と同じである。したがって、ここでは、ゲームサーバ106は、第1のゲーム装置12のゲームフレンドリストに第2のゲーム装置12のプロファイルIDを登録し、第2のゲーム装置12のゲームフレンドリストに第1のゲーム装置12のプロファイルIDを登録する。
その後、第1のゲーム装置12は、プレイヤの指示に従って、ゲームサーバ106にともだちの募集要求を行う。具体的には、第1のゲーム装置12において、図17(A)に示すメニュー画面300でボタン画像306がオンされ、図21に示す通信対戦のサブメニュー画面500がモニタ34に表示され、さらに、このサブメニュー画面500でボタン画像502がオンされる。
ここで、図21に示すサブメニュー画面500は、通信ゲームに親機として参加するか、子機として参加するかを決定するための画面である。つまり、製品版のゲームプログラム200を有するゲーム装置12では、親機または子機を選択して、通信ゲームに参加することができるのである。ボタン画像502がオンされると、親機として通信ゲームに参加するべく、ともだちの募集要求がゲームサーバ106に行われる。ボタン画像504がオンされると、募集中の通信ゲームに子機として参加するべく、参加要求がゲームサーバ106に行われる。このように、製品版のゲームプログラム200を有する第1のゲーム装置12は、子機として通信ゲームに参加することもできるが、このことは、本願発明の本質的な内容ではないため、図15および図16を用いた説明においては省略してある。また、ボタン画像506がオンされると、通信ゲームへの参加をキャンセルして、図17(A)に示すメニュー画面300に戻る。
一方、第2のゲーム装置12は、ゲームサーバ106に対して、通信ゲームへの参加要求を行う。ここで、体験版のゲームプログラム200´を有する第2のゲーム装置12では、上述したように、通信ゲームへの参加要求しかできないため、メニュー画面300´でボタン画像306がオンされた場合であっても、上述したようなサブメニュー画面500は表示されず、そのまま参加要求がゲームサーバ106に行われる。
ゲームサーバ106は、ともだちの募集要求や参加要求を受けると、各ゲームフレンドの通信ゲームについてのリクエストの状態を示すリスト(個別リクエスト状態リスト)を、第1のゲーム装置12(親機)および第2のゲーム装置12(子機)に送信する。後で説明するが、個別リクエスト状態リストには、プレイヤ名に対してリクエスト状態(募集,参加,オンライン,オフライン)が記述される。
親機および子機では、個別リクエスト状態リストを受信すると、当該当該リクエスト状態リストがモニタ34に表示され、プレイヤに報知される。たとえば、図22に示すような個別リクエスト状態リストの表示画面600がモニタ34に表示される。ただし、この表示画面600は、参加要求した場合の例であり、子機で表示される。図22に示すように、表示画面600には、画面上部に表示領域602が設けられ、その下側にリクエスト状態の表示部604が設けられる。表示領域602には、通信ゲーム(図22では、ゲームA)の相手である親機を選択すべき旨のメッセージが表示される。また、表示部604には、プレイヤの名前に対応してリクエスト状態が記述されたテーブルが表示される。
ここで、リクエスト状態が「募集」であれば、当該通信ゲームの参加者を募集している状態(募集中)であることを示す。また、リクエスト状態が「参加」であれば、当該通信ゲームへの参加要求を行っている状態であることを示す。さらに、リクエスト状態が「オンライン」であれば、ネットワーク108に接続しているが、未だ募集要求も参加要求も行っていない状態を示す。さらにまた、リクエスト状態が「オフライン」であれば、ゲームサーバ106に接続していない状態を示す。ただし、ゲームサーバ106に接続していない状態としては、ゲーム装置12同士(ここで、第1のゲーム装置12と第2のゲーム装置12)がネットワーク108を介して通信ゲームを行っている状態、または、ゲーム装置12の電源がオフ(スタンバイモードを含む)である状態が該当する。
なお、親機で表示されるリクエスト状態の表示画面については図示を省略する。簡単に説明すると、親機では、参加要求があるのを待機するため、図22に示すような表示画面600の表示領域602には、参加要求があるまで待機すべき旨のメッセージが表示される。また、表示領域604には、図22に示すような個別リクエスト状態リストが表示される。ただし、参加要求が長時間無い場合に、参加要求を待ち続けるのは酷であるため、ともだちの募集要求を終了することを選択するためのボタン画像がさらに表示される。したがって、親機において、プレイヤが募集の終了を選択すると、その旨がゲームサーバ106に通知され、したがって、当該親機についてのリクエスト状態が更新される。具体的には、リクエスト状態が、「募集」から「オンライン」に変更される。ただし、親機がゲームサーバ106との通信を終了したり、電源を切ったりした場合には、リクエスト状態が「募集」から「オフライン」に変更される。
子機では、図22に示した表示画面600において、通信ゲームに参加するための親機を、個別リクエスト状態リストのテーブルから選択する。ただし、ここで選択可能な相手は、リクエスト状態が「募集」となっている親機(プレイヤ)だけである。所望の親機が選択されると、図16に示すように、子機は、ゲームサーバ106に対して当該親機への接続要求を行う。ゲームサーバ106は、子機からの接続要求を受信すると、当該接続要求をリクエスト状態リストに従って照合する。具体的には、ゲームサーバ106は、子機から接続要求のあった親機についてのリクエスト状態を調べて、そのリクエスト状態が「募集」であるかどうかを判断する。また、当該親機のゲームフレンドリストに当該子機のプロファイルIDが登録されているかどうかを判断する。
ゲームサーバ106は、当該親機のリクエスト状態が「募集」であり、かつ当該親機のゲームフレンドリストに当該子機のプロファイルIDが登録されている場合には、照合の結果が正しいと判断して、子機からの接続要求を受け入れるべく、当該親機の接続アドレス(たとえば、IPアドレス)を送信する。したがって、その後、親機と子機とはネットワーク108を介して直接通信(ピア・ツー・ピア)して、通信ゲームを行うことができる。
ただし、ゲームサーバ106は、当該親機のリクエスト状態が「募集」でなかったり、当該親機のゲームフレンドリストに当該子機のプロファイルIDが登録されていなかったりする場合には、照合の結果が正しくないと判断して、子機からの接続要求を受け入れることができないと判断して、当該子機に接続不可を示すメッセージを通知する。
図23は、図8に示したゲームサーバ106の管理するデータベース(図示せず)のメモリマップを示す。図示は省略するが、データベース(DB)は、ゲームサーバ106の内部または外部に設けることができる。図23を参照して、ゲームサーバ106のDBには、体験版プログラム記憶領域120、ゲーム別プレイヤデータ記憶領域122、リクエスト状態リスト記憶領域124などが設けられる。体験版プログラム記憶領域120には、少なくとも1種類の体験版のゲームプログラム(200´)が記憶される。
ゲーム別プレイヤデータ記憶領域122には、ゲームサーバ106が提供するゲーム毎のプレイヤデータが記憶される。たとえば、ゲームAに関するプレイヤデータの記憶領域130には、プレイヤaデータを記憶する記憶領域140,プレイヤbデータを記憶する記憶領域142,…が設けられる。
記憶領域140には、さらに3つの記憶領域140a,140b,140cが設けられる。記憶領域140aには、プレイヤaに対して決定されたプロファイルIDが記憶され、記憶領域140bには、プレイヤaのプレイヤ名が記憶され、記憶領域140cには、プレイヤaのゲームフレンドリストが記憶される。ただし、プレイヤaのゲーム装置12は、ゲームAの通信ゲームを実行して、ゲームサーバ106に接続済みであり、プロファイルIDは既に作成されている。また、プレイヤaのゲームフレンドが登録されていない場合には、ゲームフレンドリストには何ら記載されていない。
同様に、記憶領域142には、さらに3つの記憶領域142a,142b,142cが設けられる。ただし、プレイヤbは、ゲームAの通信ゲームを未だ実行しておらず、ゲームサーバ106に未接続であるため、プロファイルIDは作成されていない。つまり、記憶領域142aには、何も設定されていない。同様に、記憶領域142bにはプレイヤ名は登録されておらず、また、記憶領域142cのゲームフレンドリストには何ら記載されていない。
なお、説明の都合上、図23においては、ゲームサーバ106に未接続のプレイヤbについてのプレイヤデータの記憶領域142が既に確保されているように示してあるが、実際には、プレイヤb(ゲーム装置12)がゲームサーバ106に接続し、当該プレイヤbについてのプロファイルIDを作成したときに、記憶領域142は確保されるのである。
また、図示は省略するが、ゲームAとは異なるゲームB或いはその他のゲームについても同様に、プレイヤデータが記憶される。
全リクエスト状態リスト記憶領域124には、全リクエスト状態リスト124aが記憶される。この全リクエスト状態リスト124aは、ゲームサーバ106で管理する全てのプレイヤについてのリクエスト状態が記憶される。全リクエスト状態リスト124aでは、プレイヤ名に対応して、ゲーム名およびリクエスト状態が記述される。ただし、リクエスト状態がオフラインである場合には、ゲーム名の欄には何ら記述されない。
したがって、上述したように、ゲーム装置12から個別リクエスト状態リストの要求があると、ゲームサーバ106は、まず、当該ゲーム装置12(プレイヤ)についてのゲームフレンドリストを参照して、当該ゲームフレンドリストに登録されているプレイヤを検出する。次に、ゲームサーバ106は、全リクエスト状態リスト124aを参照して、検出したプレイヤのうち、要求元のゲーム装置12と同じゲームを実行中のゲーム装置12(プレイヤ)およびそのリクエスト状態を抽出することにより、個別リクエスト状態リストを作成する。そして、ゲームサーバ106は、作成した個別リクエスト状態リストを、要求元のゲーム装置12に送信する。
以下、ゲーム装置12およびゲームサーバ106の具体的な処理について、フロー図を用いて説明することにする。ただし、厳密に言うと、ゲーム装置12においては、主として、CPU40が処理を実行する。また、同様に、ゲームサーバ106においても、主として、CPU(図示せず)が処理を実行する。
図24は体験版のダウンロード処理を示すフロー図である。この体験版のダウンロード処理は、プレイヤの指示に従ってゲーム装置12のCPU40が実行する。なお、図12を用いて説明したように、入出力プロセッサ42aがタスクに従ってダウンロード処理を実行することにより、体験版のゲームプログラム(200´)をダウンロードすることもできる。
図24を参照して、CPU40は、体験版のダウンロード処理を開始すると、ステップS31で、ゲームサーバ106に接続する。続くステップS33では、体験版リストを要求する。図示は省略するが、体験版リストは、体験版のゲームプログラム200´についてのリストであり、たとえば、ゲームソフトのタイトルが記述される。続くステップS35では、ゲームサーバ106からの体験版リストを取得する。そして、ステップS37で、取得した体験版リストをモニタ34に表示する。つまり、プレイヤは、体験版リストを見て、ダウンロードする体験版のゲームプログラム200´を決定するのである。
次のステップS39では、体験版のゲームプログラム200´を決定したかどうかを判断する。ステップS39で“NO”であれば、つまり体験版のゲームプログラム200´を決定していなければ、ステップS41で、キャンセルかどうかを判断する。つまり、体験版のゲームプログラム200´のダウンロードを中止するかどうかを判断する。ステップS41で“YES”であれば、つまりキャンセルであれば、そのまま体験版のダウロード処理を終了する。図示は省略するが、このとき、ゲームサーバ106の接続状態は解除される。一方、ステップS41で“NO”であれば、つまりキャンセルでなければ、体験版のゲームプログラム200´の選択中であると判断して、ステップS39に戻る。
また、ステップS39で“YES”であれば、つまり体験版のゲームプログラム200´を決定すると、ステップS43で、該当する(決定した)体験版のゲームプログラム200´の配信要求をゲームサーバ106に送信する。そして、ステップS45で、体験版のゲームプログラム200´の受信を完了したかどうかを判断する。ステップS45で“YES”であれば、つまり体験版のゲームプログラム200´の受信を完了すれば、ステップS47で、受信した体験版のゲームプログラム200´をフラッシュメモリ44に格納して、体験版のダウンロード処理を終了する。
しかし、ステップS45で“NO”であれば、つまり体験版のゲームプログラム200´の受信を完了していなければ、ステップS49で、タイムアウトであるかどうかを判断する。詳細な説明は省略するが、ゲーム装置12では、体験版のダウンロード処理を開始すると同時に、図示しない内部タイマをスタートして、一定時間(たとえば、10分)をカウントするようにしてある。この一定時間を超える場合には、体験版のダウンロード処理のタイムアウトであると判断するようにしてある。これは、ネットワーク108に通信障害が発生していたり、ゲームサーバ106に対する不適切な処理を防止したりするためである。
ステップS49で“NO”であれば、つまりタイムアウトでなければ、そのままステップS45に戻る。一方、ステップS49で“YES”であれば、つまりタイムアウトであれば、ステップS51で、エラー表示を行って、体験版のダウンロード処理を終了する。たとえば、ステップS51では、タイムアウトになり、体験版のゲームプログラム200´のダウンロードを中止した旨および後でダウンロード処理を実行し直す必要がある旨のメッセージがモニタ34に表示される。また、図示は省略するが、タイムアウトになった場合には、ゲームサーバ106との接続状態は解除される。
なお、図示等は省略するが、ゲームサーバ106のDBで製品版のゲームプログラム200を管理し、当該製品版のゲームプログラム200のダウンロードを可能にした場合には、図24に示した体験版のダウンロード処理とほぼ同じ処理が実行される。ただし、製品版のゲームプログラム200をダウンロードする場合には、たとえば、当該ゲームプログラム200の受信を完了した時点で課金する処理が実行される。この課金処理は、ゲームサーバ106側で実行するようにしてもよい。
図25は、ゲーム装置12(CPU40)の製品版のゲーム全体処理のフロー図である。つまり、この製品版のゲーム全体処理は、製品版のゲームプログラム200を有しているゲーム装置12において実行される。CPU40は、製品版のゲーム全体処理を開始すると、ステップS61で、図17(A)に示したようなメニュー画面300をモニタ34に表示する。続くステップS63では、ともだち設定が選択されたかどうかを判断する。つまり、メニュー画面300のボタン画像308がオンされたかどうかを判断する。
ステップS63で“YES”であれば、つまりともだち設定が選択されれば、ステップS65で、後述するともだち設定処理(図27および図28参照)を実行して、ステップS79に進む。一方、ステップS63で“NO”であれば、つまりともだち設定が選択されていなければ、ステップS67で、通信対戦が選択されたかどうかを判断する。つまり、メニュー画面300のボタン画像306がオンされたかどうかを判断する。
ステップS67で“NO”であれば、つまり通信対戦が選択されていなければ、そのままステップS79に進む。一方、ステップS67で“YES”であれば、つまり通信対戦が選択されれば、ステップS69で、図21に示したような通信対戦のサブメニュー画面500をモニタ34に表示する。次のステップS71では、ともだちを募集するかどうかを判断する。つまり、サブメニュー画面500のボタン画像502がオンされたかどうかを判断する。ステップS71で“YES”であれば、つまりともだちを募集する場合には、ステップS73で、後述する親機処理(図29参照)を実行して、ステップS79に進む。
しかし、ステップS71で“NO”であれば、つまりともだちを募集しない場合には、ステップS75で、募集中の通信ゲームに参加するかどうかを判断する。つまり、サブメニュー画面500のボタン画像504がオンされたかどうかを判断する。ステップS75で“YES”であれば、つまり募集中の通信ゲームに参加する場合には、ステップS77で、後述する子機処理(図30参照)を実行して、ステップS79に進む。一方、ステップS75で“NO”であれば、つまり募集中の通信ゲームに参加しない場合には、そのままステップS79に進む。
なお、ここでは、簡単のため、ステップS75で“NO”の場合には、そのままステップS79に進むようにしてあるが、上述したように、サブメニュー画面500でボタン画像506がオンされた場合には、メニュー画面300に戻る。したがって、ステップS75で“NO”と判断された後に、メニュー画面300に戻るかどうかを判断して、“YES”ならステップS61に戻り、“NO”ならステップS79に進むようにすればよい。
ステップS79では、その他の処理かどうかを判断する。ここでは、メニュー画面300で、ボタン画像302またはボタン画像304がオンされたかどうかを判断したり、既にボタン画像302,304がオンされている場合には、ゲーム装置12単体でのゲーム処理を実行するかどうかを判断したりする。ステップS79で“NO”であれば、つまりその他の処理でなければ、そのままステップS83に進む。一方、ステップS79で“YES”であれば、つまりその他の処理であれば、ステップS81で、ゲーム装置12単体でのゲーム処理を開始したり、そのゲーム処理を進行させたりして、ステップS83に進む。
ステップS83では、最初に戻るかどうかを判断する。つまり、メニュー画面300に戻るかどうかを判断する。ステップS83で“YES”であれば、つまり最初に戻る場合には、ステップS61に戻る。一方、ステップS83で“NO”であれば、つまり最初に戻らない場合には、そのまま製品版のゲーム全体処理を終了する。
なお、図示は省略するが、初めて製品版のゲーム全体処理を実行する場合のように、自己のプロファイルIDが登録されていない場合に、ステップS67で通信対戦が選択されたと判断すると、強制的にステップS65の処理を実行して、プレイヤに自己のプロファイルIDの登録を行わせるようにしてある。
図26は、ゲーム装置12(CPU40)の体験版のゲーム全体処理を示すフロー図である。つまり、この体験版のゲーム全体処理は、体験版のゲームプログラム200´を有しているゲーム装置12において実行される。CPU40は、体験版のゲーム全体処理を開始すると、ステップS91で、図17(B)に示したようなメニュー画面300´をモニタ34に表示する。続くステップS93では、ともだち設定が選択されたかどうかを判断する。つまり、メニュー画面300´のボタン画像308がオンされたかどうかを判断する。
ステップS93で“YES”であれば、つまりともだち設定が選択されれば、ステップS95で、後述するともだち設定処理(図27および図28参照)を実行して、ステップS101に進む。一方、ステップS93で“NO”であれば、つまりともだち設定が選択されていなければ、ステップS97で、通信対戦が選択されたかどうかを判断する。つまり、メニュー画面300´のボタン画像306がオンされたかどうかを判断する。
ステップS97で“NO”であれば、つまり通信対戦が選択されていなければ、そのままステップS101に進む。一方、ステップS97で“YES”であれば、つまり通信対戦が選択されていれば、ステップS99で、後述する子機処理(図30参照)を実行して、ステップS101に進む。
ステップS101では、最初に戻るかどうかを判断する。ステップS101で“YES”であれば、つまり最初に戻る場合には、ステップS91に戻る。一方、ステップS101で“NO”であれば、つまり最初に戻らない場合には、そのまま体験版のゲーム全体処理を終了する。
なお、図示は省略するが、初めて体験版のゲーム全体処理が実行された場合のように、自己のプロファイルIDが登録されていない場合に、ステップS97で通信対戦が選択されたことが判断されると、強制的にステップS95の処理を実行して、プレイヤに自己のプロファイルIDを登録させるようにしてある。
図27および図28は、図25に示したステップS65および図26に示したステップS95のともだち設定処理のフロー図である。図27を参照して、CPU40はともだち設定処理を開始すると、ステップS121で、自己のプロファイルIDがあるかどうかを判断する。ここでは、CPU40は、フラッシュメモリ44の管理用ファイル44cに当該ゲームについてのプロファイルIDが記憶されているかどうかを判断する。上述したように、プロファイルIDは、当該ゲームを識別可能なアプリIDを含むため、複数のゲームについてのプロファイルIDが記憶されている場合であっても容易に判断することができる。
ステップS121で“YES”であれば、つまり自己のプロファイルIDがあれば、そのままステップS129に進む。一方、ステップS121で“NO”であれば、つまり自己のプロファイルIDがなければ、ステップS123で、ゲームサーバ106に、プロファイルIDの作成要求を送信する。たとえば、製品版のゲームプログラム200または体験版のゲームプログラム200´に予め設定(記憶)されている仮のプロファイルIDがゲームサーバ106に送信される。
続くステップS125では、プロファイルIDを受信したかどうかを判断する。ステップS125で“NO”であれば、つまりプロファイルIDを受信していなければ、そのまま同じステップS125に戻る。一方、ステップS125で“YES”であれば、つまりプロファイルIDを受信すれば、ステップS127で、受信したプロファイルIDをフラッシュメモリ44の自己のプロファイルIDエリア(管理用ファイル44c)に格納して、ステップS129に進む。
ステップS129では、図18に示した友達設定のサブメニュー画面400をモニタ34に表示する。続くステップS131では、自己のプロファイルIDを見るかどうかを判断する。つまり、サブメニュー画面400のボタン画像404がオンされたかどうかを判断する。ステップS131で“NO”であれば、つまり自己のプロファイルIDを見ない場合には、図28のステップS137に進む。
しかし、ステップS131で“YES”であれば、つまり自己のプロファイルIDを見る場合には、ステップS133で、自己のプロファイルIDを表示する。つまり、図19(B)に示したような自己のプロファイルIDの表示画面440がモニタ34に表示される。このとき、表示領域442には、管理用ファイル44cに格納されている当該ゲームについての自己のプロファイルIDが表示される。そして、ステップS135では、サブメニュー画面400に戻るかどうかを判断する。具体的には、表示画面440のボタン画像444がオンされたかどうかを判断する。ステップS135で“NO”であれば、つまりサブメニュー画面400に戻らない場合には、そのまま同じステップS135に戻る。一方、ステップS135で“YES”であれば、つまりサブメニュー画面400に戻る場合には、ステップS129に戻る。
図28に示すように、ステップS137では、他人のプロファイルIDを登録するかどうかを判断する。つまり、サブメニュー画面400のボタン画像402がオンされたかどうかを判断する。ステップS137で“NO”であれば、つまり他人のプロファイルIDを登録しない場合には、そのままステップS155に進む。一方、ステップS137で“YES”であれば、つまり他人のプロファイルIDを登録する場合には、ステップS139で、図19(A)に示したようなゲームフレンドのプロファイルIDの登録画面420をモニタ34に表示する。
続いて、ステップS141では、入力が完了したかどうかを判断する。ここでは、登録画面420において、入力欄422にゲームフレンドの名前が入力され、入力欄424にそのゲームフレンドのプロファイルIDが入力され、ボタン画像426がオンされたかどうかを判断する。ステップS141で“NO”であれば、つまり入力が完了していなければ、同じステップS141に戻る。一方、ステップS141で“YES”であれば、つまり入力が完了すれば、ステップS143で、入力されたプロファイルIDを、これに付されたCRCのチェック用データに基づいて照合する。
次のステップS145では、照合結果が一致を示すかどうかを判断する。ステップS145で“YES”であれば、つまり照合結果が一致を示す場合には、プロファイルIDが正しいと判断して、ステップS147で、入力されたプロファイルIDをゲームフレンドリストに格納し、ステップS149で、入力されたプロファファイルIDをゲームサーバ106に送信して、ステップS155に進む。
ただし、ステップS149では、入力されたプロファイルIDを、ゲームサーバ106を宛先とする送信データとして送信メッセージボックス44aに登録しておき、その後のメッセージ送受信処理によって、ゲームサーバ106に送信するようにしてもよい。
また、ステップS145で“NO”であれば、つまり照合結果が一致を示さない場合には、ステップS151で、エラー表示を実行し、ステップS153で、再入力するかどうかを判断する。図示等は省略するが、登録画面420において、ゲームフレンドの名前またはプロファイルID或いはその両方が入力されずに、ボタン画像426がオンされた場合にも、ステップS145で“NO”と判断される。また、図示は省略するが、ステップS151では、たとえば、プロファイルIDが正しく入力されていない旨および再入力するか(登録し直すか)否かを質問する旨のメッセージとともに、再入力するか否かを選択するためのボタン画像がモニタ34に表示される。ステップS153で“YES”であれば、つまり再入力することが選択されると、ステップS139に戻る。一方、ステップS153で“NO”であれば、つまり再入力しないことが選択されると、ステップS155に進む。
ステップS155では、キャンセルかどうかを判断する。つまり、サブメニュー画面400のボタン画像406がオンされたかどうかを判断する。ステップS155で“NO”であれば、つまりキャンセルでなければ、そのまま図27に示したステップS129に戻る。一方、ステップS155で“YES”であれば、つまりキャンセルであれば、全体処理にリターンする。
なお、図示は省略するが、ステップS155で“YES”の場合には、「最初に戻る」ことを示すフラグがオン(成立)される。したがって、図25のステップS83または図26のステップS101において“YES”となり、メニュー画面300またはメニュー画面300´に戻る。その後、当該「最初に戻る」ことを示すフラグがオフ(不成立)される。
図29は図25に示したステップS73の親機処理のフロー図である。図29に示すように、CPU40は親機処理を開始すると、ステップS171で、ゲームサーバ106にともだちの募集要求を送信する。具体的には、CPU40は、フラッシュメモリ44の管理用ファイル44cに格納してある自己のプロファイルIDを、アプリID(ゲームの識別情報)および募集要求である旨の情報とともに、ゲームサーバ106に送信する。続くステップS173で、ゲームサーバ106から送信された個別リクエスト状態リストを受信し、ステップS175で、受信した個別リクエスト状態リストをモニタ34に表示する。
そして、ステップS177で、相手からの接続要求があるかどうかを判断する。具体的には、ゲームフレンドリストに登録されている友達(プレイヤ)が所有するゲーム装置12からの接続要求があるかどうかを判断する。ただし、ゲームフレンドリストに登録されているプレイヤであるかどうかの判断は、後述するように、ゲームサーバ106で行われる。したがって、ここで接続要求がある場合には、その相手(要求元)は、ゲームフレンドリストに登録されたプレイヤであると言える。したがって、接続要求のあったゲーム装置12との間で通信ゲームをプレイする場合に、安心してプレイすることができる。
ステップS177で“NO”であれば、つまり相手からの接続要求がなければ、そのままステップS181に進む。一方、ステップS177で“YES”であれば、つまり相手からの接続要求があれば、ステップS179で、相手との接続処理を実行して、ステップS181に進む。詳細な説明は省略するが、ステップS179では、相手から接続先アドレス(IPアドレス)を受け取って、接続状態を確立する。
ステップS181では、募集を継続するかどうかを判断する。ここで、募集を継続するかどうかを判断するのは、プレイヤの指示によって、募集が中止される場合があるからである。募集が中止されるのは、たとえば、参加を希望するゲーム装置12が長時間現れない場合や3人以上でプレイ可能な通信ゲームにおいて、所望の人数でプレイヤの参加を締め切る場合である。図示は省略するが、ステップS181の処理に先立って、たとえば、募集を継続するか否かを選択する旨のメッセージおよびそのいずれかを選択するためのボタン画像がモニタ34に表示される。
ステップS181で“YES”であれば、つまり募集を継続する場合には、ステップS171に戻る。つまり、募集を継続することがゲームサーバ106に通知される。一方、ステップS181で“NO”であれば、つまり募集を辞める場合には、ステップS183で、接続相手との間で対戦ゲーム(通信ゲーム)処理を実行し、通信ゲームを終了した後に、全体処理にリターンする。
なお、図示は省略するが、相手からの接続要求が全くない状態で、募集を止めた場合には、CPU40は、ステップS183の処理を実行せずに、そのまま全体処理にリターンする。
また、図示は省略するが、親機処理を終了して全体処理にリターンする場合には、「最初に戻る」ことを示すフラグがオン(成立)される。したがって、図25のステップS83において“YES”となり、メニュー画面300に戻る。その後、当該「最初に戻る」ことを示すフラグがオフ(不成立)される。
図30は図25に示したステップS77および図26に示したステップS99の子機処理のフロー図である。図30に示すように、CPU40は子機処理を開始すると、ステップS201で、ゲームサーバ106に参加要求を送信する。具体的には、CPU40は、フラッシュメモリ44の管理用ファイル44cに格納してある自己のプロファイルIDを、アプリID(ゲームの識別情報)および参加要求である旨の情報とともに、ゲームサーバ106に送信する。
続くステップS203では、ゲームサーバ106から送信された個別リクエスト状態リストを受信し、ステップS205では、受信した個別リクエスト状態リストを表示する。具体的には、図22に示したようなリクエスト状態リストの表示画面600がモニタ34に表示される。そして、ステップS207では、接続相手を決定したかどうかを判断する。ここでは、表示画面600において、プレイヤが接続相手を決定したかどうかを判断する。
ステップS207で“NO”であれば、つまり接続相手を決定していなければ、そのままステップS221に進む。一方、ステップS207で“YES”であれば、つまり接続相手を決定すれば、ステップS209で、決定された相手のプロファイルIDを付加した接続要求をサーバに送信する。ここでは、CPU40は、決定された相手のプロファイルIDをフラッシュメモリ44のセーブ領域44fに記憶されたゲームフレンドリストから検索する。
続いて、ステップS211では、ゲームサーバ106からの接続先アドレスを受信したかどうかを判断する。つまり、決定した相手のゲーム装置12のIPアドレスを受信したかどうかを判断する。ステップS211で“YES”であれば、つまり接続先アドレスを受信すれば、ステップS213で、接続相手への接続処理を実行する。ここでは、CPU40は、接続先アドレス(親機のIPアドレス)宛に、接続要求(自身のIPアドレス)を送信する。そして、ステップS215で、接続相手との間で対戦ゲーム(通信ゲーム)処理を実行し、通信ゲームを終了した後に、全体処理にリターンする。
また、ステップS211で“NO”であれば、つまり接続先アドレスを受信していなければ、ステップS217で、接続不可メッセージを受信したかどうかを判断する。後述するが、ゲームサーバ106は、ステップS209において送信したプロファイルIDを有するゲーム装置12(親機)のゲームフレンドリストに当該ゲーム装置12(子機)のプロファイルIDが存在しない場合には、その子機宛に接続不可メッセージが送信される。つまり、知人や友達でないプレイヤ同士では、通信ゲームをプレイすることができない。
ステップS217で“NO”であれば、つまり接続不可メッセージを受信していなければ、そのままステップS221に進む。一方、ステップS217で“YES”であれば、つまり接続不可メッセージを受信すれば、ステップS219で、エラー表示を実行して、ステップS221に進む。たとえば、ステップS219では、決定した(希望の)相手とは通信ゲームをプレイすることができない旨のメッセージとともに、参加を辞めるかどうかを選択すべき旨のメッセージおよび選択するためのボタン画像がモニタ34に表示される。
ステップS221では、参加を辞めるかどうかを判断する。ステップS221で“NO”であれば、つまり参加を辞めない場合には、ステップS201に戻る。一方、ステップS221で“YES”であれば、つまり参加を辞める場合には、そのまま全体処理にリターンする。
なお、図示は省略するが、子機処理を終了して全体処理にリターンする場合には、「最初に戻る」ことを示すフラグがオン(成立)される。したがって、図25のステップS83または図26のステップS101において“YES”となり、メニュー画面300またはメニュー画面300´に戻る。その後、当該「最初に戻る」ことを示すフラグがオフ(不成立)される。
図31−図34は、ゲームサーバ106のCPU(図示せず)の全体処理を示すフロー図である。図31に示すように、ゲームサーバ106のCPUは全体処理を開始すると、ステップS301で、体験版リストの要求を受信したかどうかを判断する。ステップS301で“NO”であれば、つまり体験版リスト要求を受信していなければ、そのままステップS305に進む。一方、ステップS301で“YES”であれば、つまり体験版リスト要求を受信すれば、ステップS303で、要求元のゲーム装置12に体験版リストを送信して、ステップS305に進む。
ステップS305では、ダウンロード要求を受信したかどうかを判断する。ステップS305で“NO”であれば、つまりダウンロード要求を受信していなければ、そのまま図32に示すステップS309に進む。一方、ステップS305で“YES”であれば、つまりダウンロード要求を受信すれば、ステップS307で、要求元のゲーム装置12に、要求のあった体験版データすなわち体験版のゲームプログラム200´を送信して、ステップS309に進む。
なお、図示は省略するが、製品版のゲームプログラム200をダウンロードにより販売する場合には、ステップS301−S307と同様の処理がゲームサーバ106の全体処理の中で実行される。
図32に示すステップS309では、プロファイルIDの作成要求つまり仮プロファイルIDを受信したかどうかを判断する。ステップS309で“NO”であれば、つまり仮プロファイルIDを受信していなければ、そのままステップS323に進む。一方、ステップS309で“YES”であれば、つまり仮プロファイルIDを受信すれば、ステップS311で、当該仮プロファイルIDが使用可能かどうかを判断する。ここでは、ゲームサーバ106は、データベースのゲーム別プレイヤデータ記憶領域122内の当該ゲームについての記憶領域(130,132,…)を参照して、受信した仮プロファイルIDと同じプロファイルIDが記憶されているかどうかを検索する。そして、ゲームサーバ106は、受信した仮プロファイルIDと同じプロファイルIDが記憶されている場合には、当該仮プロファイルIDを使用不可と判断し、逆に仮プロファイルと同じプロファイルIDが記憶されていない場合には、当該仮プロファイルを使用可能と判断する。
ステップS311で“YES”であれば、つまり仮プロファイルIDが使用可能であれば、当該仮プロファイルIDをプロファイルIDに決定し、ステップS317に進む。一方、ステップS311で“NO”であれば、つまり仮プロファイルが使用不可であれば、プロファイルIDを新規に作成し、ステップS317に進む。ただし、プロファイルIDにおいて、本体のMACアドレスとゲームコード(アプリID)とは固定であるため、ステップS315では、乱数が変更されるとともに、プロファイルIDに付加されるCRCのチェック用データも変更される。
ステップS317では、要求元のゲーム装置12のプレイヤについてのデータ領域(ゲーム別プレイヤデータ記憶領域122に設けられる当該要求元のゲーム装置12のプレイヤについての記憶領域)にプロファイルIDの記憶領域を作成する。続く、ステップS319では、プロファイルIDを作成した記憶領域に書き込み、ステップS321で、当該プロファイルIDを要求元のゲーム装置12に送信する。
続いて、ステップS323では、プロファイルIDを受信したかどうかを判断する。ステップS323で“NO”であれば、つまりプロファイルIDを受信していなければ、そのまま図33に示すステップS327に進む。一方、ステップS323で“YES”であれば、つまりプロファイルIDを受信すれば、ステップS325で、受信したプロファイルIDを、送信元のプレイヤについてのゲームフレンドリストに書き込み、ステップS327に進む。
図33に示すように、ステップS327では、ともだちの募集要求を受信したかどうかを判断する。ステップS327で“YES”であれば、つまりともだち募集要求を受信すれば、ステップS329で、要求元のゲーム装置12のリクエスト状態を募集に更新して、ステップS335に進む。つまり、ステップS329では、ゲームサーバ106のCPUは、全リクエスト状態リスト記憶領域124に記憶される全リクエスト状態リスト124aにおいて、当該要求元のゲーム装置12のプレイヤについてのリクエスト状態を募集に変更するのである。
また、ステップS327で“NO”であれば、つまりともだち募集を受信しなければ、ステップS331で、参加要求を受信したかどうかを判断する。ステップS331で“NO”であれば、つまり参加要求を受信していなければ、そのままステップS335に進む。一方、ステップS331で“YES”であれば、つまり参加要求を受信すれば、ステップS333で、要求元のゲーム装置12のプレイヤについてのリクエスト状態を参加に更新して、ステップS335に進む。つまり、ステップS333では、ゲームサーバ106のCPUは、全リクエスト状態リスト記憶領域124に記憶される全リクエスト状態リスト124aにおいて、当該要求元のゲーム装置のプレイヤについてのリクエスト状態を参加に変更するのである。
ステップS335では、受信したプロファイルIDから実行中のゲーム(通信ゲーム)を判別し、ステップS337では、ステップS335において判別された通信ゲームについての個別リクエスト状態リストを、要求元のゲームフレンドリストに基づいて作成する。つまり、ステップS337では、要求元のゲーム装置12のプレイヤについてのゲームフレンドリストに記述されたプレイヤのうち、当該要求元のゲーム装置12と同じ通信ゲームを実行しているプレイヤおよびそのリクエスト状態を、全リクエスト状態リスト124aを参照することにより抽出し、当該要求元のゲーム装置12のプレイヤに提示する個別リクエスト状態リストを作成する。そして、ステップS339では、ともだちの募集要求または参加要求の要求元のゲーム装置12に個別リクエスト状態リストを送信する。
続いて、図34に示すステップS341では、接続要求を受信したかどうかを判断する。ステップS341で“NO”であれば、つまり接続要求を受信していなければ、そのまま図31に示したステップS301に戻る。一方、ステップS341で“YES”であれば、つまり接続要求を受信すれば、ステップS343で、接続先のリクエスト状態を検出する。つまり、ステップS343では、ゲームサーバ106のCPUは、全リクエスト状態リスト124aを参照して、接続先のゲーム装置12についてのプレイヤのリクエスト状態を検出する。
続くステップS345では、リクエスト状態が募集であるかどうかを判断する。ステップS345で“NO”であれば、つまりリクエスト状態が募集でなければ、ステップS351で、要求元のゲーム装置12に接続不可メッセージを送信して、ステップS301に戻る。一方、ステップS345で“YES”であれば、つまりリクエスト状態が募集であれば、ステップS347で、接続先のゲームフレンドリストに接続元(接続要求元)のプレイヤが登録されているかどうかを判断する。ここでは、ゲームサーバ106のCPUは、接続先のゲーム装置12のプレイヤについてのゲームフレンドリストを参照して、当該ゲームフレンドリストに接続元のゲーム装置12のプレイヤ(プロファイルID)が登録されているかどうかを判断する。
ただし、ここでは、接続元のゲーム装置12(プレイヤ)のゲームフレンドリストに接続先のゲーム装置12(プレイヤ)のプロファイルIDが登録されているかどうかを調べる必要はない。なぜならば、個別リクエスト状態リストには、接続元のゲーム装置12のゲームフレンドリストに登録されているプロファイルIDを有するゲーム装置12(プレイヤ)が記述され、ここから接続先のゲーム装置12(プレイヤ)が選択されるからである。
ステップS347で“NO”であれば、つまり接続先のゲームフレンドリストに接続元のプレイヤが登録されていなければ、そのままステップS351に進む。一方、ステップS347で“YES”であれば、つまり接続先のゲームフレンドリストに接続元のプレイヤが登録されていれば、ステップS349で、要求元のゲーム装置12に接続先アドレス(この実施例では、接続先の親機のIPアドレス)を送信して、ステップS301に戻る。
この実施例によれば、無料で配布される体験版のゲームプログラムを有する第2のゲーム装置は、それに対応する製品版のゲームプログラムを有する、かつ当該第2のゲーム装置をゲームフレンドリストに登録している第1のゲーム装置との間でのみ、通信ゲームをプレイできる。つまり、製品版のゲームプログラムを必要としないので、無料で通信ゲームを体験することができる。また、ゲームフレンドリストに登録されている相手(ゲームフレンドリストを交換して登録している相手)のみと通信ゲームをプレイできるので、不特定のプレイヤと通信ゲームをプレイする場合に比べて参加しやすいネットワークゲームを実現することができる。
また、この実施例によれば、体験版のゲームプログラムは通信ゲームに必要なゲームプログラムおよびデータを備えるので、製品版のゲームプログラムを有するゲーム装置と体験版のゲームプログラムを有するゲーム装置との間で通信ゲームを実行することができる。
なお、この実施例では、体験版のゲームプログラムを有する第2のゲーム装置がゲームサーバに接続要求を送信すると、ゲームサーバは接続要求の示す第1のゲーム装置のゲームフレンドリストを参照して、接続の可否を判断するようにしてあるが、製品版のゲームプログラムおよび体験版のゲームプログラムのそれぞれに固有の識別情報を含ませておき、接続要求先のゲーム装置が有しているゲームプログラムが製品版のゲームプログラムか体験版のゲームプログラムかを当該識別情報に基づいて判別し、接続の可否を判断するようにしてもよい。このようにすれば、接続の可否を容易に判断することができ、したがって、体験版のゲームプログラムを有する第2のゲーム装置同士を誤って接続してしまうことを防止することができる。また、このことは、製品版のゲームプログラムについても同様であり、製品版のゲームプログラムに固有の識別情報を含ませておき、当該識別情報に基づいて募集要求の可否を容易に判断することが可能である。
また、この実施例では、上述したように、本体フレンドリストに登録されているプレイヤ同士では、メッセージの送受信により、プロファイルIDを知らせることもできる。したがって、たとえば、ゲーム装置が自己のプロファイルIDを登録したとき、本体フレンドリストに登録されたすべてのプレイヤのゲーム装置に対して当該プロファイルIDを含むメッセージを送信するようにし、また、他のゲーム装置から送信されたプロファイルIDを含むメッセージを受信したとき、当該メッセージに含まれるプロファイルIDをゲームフレンドリストに登録するようにすれば、自動的にプロファイルIDを交換し、ゲームフレンドリストに登録することができる。
さらに、この実施例では、体験版のゲームプログラムはゲームサーバに予め記憶されているようにしたが、製品版のゲームプログラムに体験版のゲームプログラムを含ませておき、製品版のゲームプログラムを有するゲーム装置からゲームサーバに体験版のゲームプログラムをアップロードし、当該製品版のゲームプログラムを有するゲーム装置のゲームフレンドリストに登録されたプレイヤのゲーム装置に対してはアップロードされた体験版のゲームプログラムを配信するようにしてもよい。
また、この実施例では、ゲーム装置とモニタとが個別に設けられたビデオゲームシステムを用いたネットワークゲームシステムについてのみ説明したが、これに限定される必要はない。ゲームシステムに代えて、ゲーム機能を備える汎用のコンピュータ、または、ゲーム装置とモニタとが一体的に形成された携帯型のゲーム装置やゲーム機能を備える携帯電話機、PC、PDAのような携帯端末を用いることもできる。