しかし、前者の場合には、交換条件を口頭で確認する必要があるため、交換する相手が友人・知人等に限られてしまう。そのため、友人・知人等の中に同じゲームソフトを持っている人が少ない等の場合には、交換する機会や交換可能なゲームデータが限定されてしまい、交換の楽しさを十分に満喫できるとは言えなかった。つまり、ゲームの楽しさを低減していた。
また、後者の場合には、ゲームデータを交換するために、ネットワークに接続する必要があり、いつでも手軽に交換することができず、しかも、交換処理のためのサーバを設ける必要があるため、サービス提供者の初期投資や運営費用等の負担が大きかった。
それゆえに、この発明の主たる目的は、手軽にゲームデータを交換でき、興趣性を向上できる、ゲームシステム、ゲーム装置およびゲームプログラムを提供することである。
請求項1の発明は、複数の携帯型のゲーム装置から構成され、各ゲーム装置間でゲームデータを交換するゲームシステムであって、それぞれのゲーム装置は、ゲームデータを記憶するゲームデータ記憶手段、ゲームデータ記憶手段に記憶されたゲームデータのうち、他のゲーム装置に提供することを許容する提供ゲームデータを指定する提供ゲームデータ指定手段、提供ゲームデータを他のゲーム装置に提供する代わりに、当該他のゲーム装置から提供を受けることを希望するゲームデータの条件である交換条件を示す交換条件データを設定する交換条件設定手段、他のゲーム装置と近距離無線によって通信するための通信手段、通信手段を用いて、他のゲーム装置に対して宛先を特定せずに交換希望データをブロードキャスト送信する交換希望送信手段、通信手段を用いて、他のゲーム装置から交換希望データを受信する交換希望受信手段、および通信手段を用いて、特定の他のゲーム
装置との間でゲームデータを交換するゲームデータ交換手段を備え、複数のゲーム装置のうちの第1ゲーム装置が交換希望送信手段を用いて交換希望データを送信し、複数のゲーム装置のうちの第2ゲーム装置が当該交換希望データを受信して、第1ゲーム装置のゲームデータ交換手段と第2ゲーム装置のゲームデータ交換手段は、通信手段を用いて提供ゲームデータに関連する属性情報および交換条件データの少なくとも一方を通信することにより、当該第1ゲーム装置の提供ゲームデータが当該第2ゲーム装置の交換条件を満たし、かつ、当該第2ゲーム装置の提供ゲームデータが当該第1ゲーム装置の交換条件を満たすか否かを判断し、両方の交換条件を満たす場合に、当該第1ゲーム装置の提供ゲームデータと、当該第2ゲーム装置の提供ゲームデータとを交換する、ゲームシステムである。
請求項1の発明では、ゲームシステムは、複数の携帯型のゲーム装置(10:実施例で相当する参照番号である。以下、同様である。)から構成され、各ゲーム装置(10)間でゲームデータを交換する。それぞれのゲーム装置(10)には、ゲームデータ記憶手段(28または44)が設けられ、ゲームデータが記憶される。提供ゲームデータ指定手段(20,38,S45〜S57,S67)は、ゲームデータ記憶手段(28または44)に記憶されたゲームデータのうち、他のゲーム装置(10)に提供することを許容するゲームデータである提供ゲームデータを指定する。たとえば、プレイヤが他のゲーム装置(10)に提供してもよいと考えるゲームデータをプレイヤからの指示に応じて指定したり、他のゲーム装置(10)に提供されるゲームデータをゲームプログラムによって自動的に指定したりする。交換条件設定手段(20,38,S59〜S67)は、提供ゲームデータを他のゲーム装置(10)に提供する代わりに、当該他のゲーム装置(10)から提供を受けることを希望する(提供を受けるべき)ゲームデータの条件である交換条件を設定する。ここで、交換条件は、他のゲーム装置(10)から提供を受けるべきゲームデータ(提供ゲームデータと交換されるゲームデータ)がどのようなゲームデータであるかの条件である。たとえば、他のゲーム装置(10)から提供を受けることを希望するゲームデータをプレイヤからの指示に応じて指定したり、ゲームプログラムによって自動的に指定したりする。通信手段(14)は、他のゲーム装置(10)と近距離無線によって通信する。交換希望送信手段(20,S167,S197)は、通信手段(14)を用いて、他のゲーム装置(10)に対して宛先を特定せずに交換希望データ(接続可能であることを示すデータ)をブロードキャスト送信する。交換希望受信手段(20,S155,S185,S211)は、通信手段(14)を用いて、他のゲーム装置(10)から交換希望データを受信する。ゲームデータ交換手段(20,S105〜S109,S135〜S139)は、通信手段(14)を用いて、他のゲーム装置(10)との間でゲームデータを交換する。
たとえば、複数のゲーム装置(10)のうちの第1ゲーム装置が交換希望送信手段(20,S167,S197)を用いて交換希望データを送信し、複数のゲーム装置のうちの第2ゲーム装置が当該交換希望データを受信する。第1ゲーム装置のゲームデータ交換手段(20,S105〜S109,S135〜S139)と第2ゲーム装置のゲームデータ交換手段(20,S105〜S109,S135〜S139)は、通信手段(14)を用いて、提供ゲームデータに関連する属性情報(キャラクタの種類、レベル)および交換条件データ(提供を希望するキャラクタの種類、レベル)の少なくとも一方を通信する。各ゲームデータ交換手段(20,S105〜S109,S135〜S139)は、当該第1ゲーム装置の提供ゲームデータが当該第2ゲーム装置の交換条件を満たし、かつ、当該第2ゲーム装置の提供ゲームデータが当該第1ゲーム装置の交換条件を満たすか否かを判断する。そして、両方の交換条件を満たす場合に、当該第1ゲーム装置の提供ゲームデータと、当該第2ゲーム装置の提供ゲームデータとを交換する。具体的には、自己のゲームデータ記憶手段(28または44)から提供ゲームデータを削除し、通信手段(14)を用いて他のゲーム装置(10)と通信することにより、当該他のゲーム装置(10)の提供ゲームデータを受信してゲームデータ記憶手段(28または44)に記憶する。つまり、
ゲームデータ記憶手段(28または44)には、プレイヤが仮想ゲームをプレイすることによって生成または獲得されたゲームデータやゲームプログラムに予め設定されたゲームデータが記憶される。
具体的には、第1ゲーム装置で提供ゲームデータに指定されたゲームデータが、第2ゲーム装置で設定された交換条件を満たし、かつ、第2ゲーム装置で提供ゲームデータに指定されたゲームデータが、第1ゲーム装置で設定された交換条件を満たす場合に、両方のゲームデータが交換される。交換条件を満たすか否かを判断する方法には、たとえば、以下のような3つの方法(方法1〜方法3)がある。
(1)方法1
(a)第1ゲーム装置は、自身の提供ゲームデータの所定情報(たとえば、提供ゲームデータのキャラクタの種類やレベル等)を第2ゲーム装置に送信する(この送信は第2ゲーム装置を指定して個別的に送信してもよいし、第2ゲーム装置を指定せずにブロードキャスト送信してもよい)。
(b)第2ゲーム装置は、第1ゲーム装置の提供ゲームデータに関する所定情報を受信して、自身の交換条件と比較する。条件を満たす場合には、第2ゲーム装置は、自身の提供ゲームデータに関する所定情報を第1ゲーム装置に送信する。
(c)第1ゲーム装置は、第2ゲーム装置の提供ゲームデータに関する所定情報を受信して、自身の交換条件と比較する。条件を満たす場合に、第1ゲーム装置と第2ゲーム装置との間でゲームデータの交換を行う。
(2)方法2
(a)第1ゲーム装置は、自身の交換条件を第2ゲーム装置に送信する(この送信は第2ゲーム装置を指定して個別的に送信してもよいし、第2ゲーム装置を指定せずにブロードキャスト送信してもよい)。
(b)第2ゲーム装置は、第1ゲーム装置の交換条件を受信して、自身の提供ゲームデータに関する所定情報と比較する。条件を満たす場合には、第2ゲーム装置は、自身の交換条件を第1ゲーム装置に送信する。
(c)第1ゲーム装置は、第2ゲーム装置の交換条件を受信して、自身の提供ゲームデータに関する所定情報と比較する。条件を満たす場合に、第1ゲーム装置と第2ゲーム装置との間でゲームデータの交換を行う。
(3)方法3
(a)第1ゲーム装置は、自身の提供ゲームデータに関する所定情報および交換条件を第2ゲーム装置に送信する(この送信は第2ゲーム装置を指定して個別的に送信してもよいし、第2ゲーム装置を指定せずにブロードキャスト送信してもよい)。
(b)第2ゲーム装置は、第1ゲーム装置の提供ゲームデータに関する所定情報および交換条件を受信して、自身の提供ゲームデータに関する所定情報および交換条件とそれぞれと比較する。条件を満たす場合には、第1ゲーム装置と第2ゲーム装置との間でゲームデータの交換を行う。
上記の3つの方法以外であってもよく、第1ゲーム装置と第2ゲーム装置との間で、提供ゲームデータの所定情報、交換条件を通信によりやり取りして、第1ゲーム装置の提供ゲームデータが第2ゲーム装置の交換条件を満たすことが第1ゲーム装置または第2ゲーム装置の少なくとも一方で判断され、かつ、第2ゲーム装置の提供ゲームデータが第1ゲーム装置の交換条件を満たすことが第1ゲーム装置または第2ゲーム装置の少なくとも一方で判断されればよい。以下、同様である。
請求項1の発明によれば、交換条件が合致するゲームデータを近距離無線による通信により交換することができるので、知人との間でゲームデータの交換を交渉するなどの煩わしさがない。すなわち、手軽にゲームデータを交換することができる。また、交換する相手が知人に限定されず、多数の人とゲームデータの交換をすることができるため、ゲーム
データを交換する可能性を高くすることができる。さらに、携帯型のゲーム装置と近距離無線を使用するので、人が集まる場所に出かければ、ゲームデータを交換する可能性が高くなり、交換の楽しさをさらに増大させることができる。さらに、ゲーム装置同士でゲームデータ交換処理を行うので、交換処理のためのサーバを設ける必要がなくゲーム提供者の初期投資や運営費用等の負担を軽減することができる。
請求項2の発明は、複数の携帯型のゲーム装置から構成され、各ゲーム装置間でゲームデータを交換するゲームシステムであって、それぞれのゲーム装置は、ゲームデータを記憶するゲームデータ記憶手段、ゲームデータ記憶手段に記憶されたゲームデータのうち、他のゲーム装置に提供することを許容する提供ゲームデータを指定する提供ゲームデータ指定手段、提供ゲームデータを他のゲーム装置に提供する代わりに、当該他のゲーム装置から提供を受けることを希望するゲームデータの条件である交換条件を示す交換条件データを設定する交換条件設定手段、他のゲーム装置と近距離無線によって通信するための通信手段、通信手段を用いて、特定の他のゲーム装置との間で無線通信による接続を確立するための処理を行う接続確立手段、および通信手段を用いて、特定の他のゲーム装置との間でゲームデータを交換するゲームデータ交換手段を備え、複数のゲーム装置のうちの第1ゲーム装置および第2ゲーム装置において、いずれか一方のゲーム装置の接続確立手段は、接続要求データをブロードキャスト送信し、当該接続要求データを受信した他方のゲーム装置との間で接続状態を確立する第1接続確立処理を実行し、かつ、他方のゲーム装置の接続確立手段は、接続要求データを受信して、当該接続要求データをブロードキャスト送信した一方のゲーム装置との間で接続状態を確立する第2接続確立処理を実行し、第1ゲーム装置のゲームデータ交換手段と第2ゲーム装置のゲームデータ交換手段は、通信手段を用いて提供ゲームデータに関連する属性情報および交換条件データの少なくとも一方を通信することにより、当該第1ゲーム装置の提供ゲームデータが当該第2ゲーム装置の交換条件を満たし、かつ、当該第2ゲーム装置の提供ゲームデータが当該第1ゲーム装置の交換条件を満たすか否かを判断し、両方の交換条件を満たすと判断した場合に、通信手段を用いて当該第1ゲーム装置と当該第2ゲーム装置とで通信することにより、第1ゲーム装置の提供ゲームデータと第2ゲーム装置の提供ゲームデータを交換する、ゲームシステムである。
請求項2の発明では、ゲームシステムは、複数の携帯型のゲーム装置(10)から構成され、各ゲーム装置(10)間でゲームデータを交換する。それぞれのゲーム装置(10)には、ゲームデータ記憶手段(28または44)が設けられ、ゲームデータが記憶される。提供ゲームデータ指定手段(20,38,S45〜S57,S67)は、ゲームデータ記憶手段(28または44)に記憶されたゲームデータのうち、他のゲーム装置(10)に提供する提供することを許容する提供ゲームデータを指定する。交換条件設定手段(20,38,S59〜S67)は、提供ゲームデータを他のゲーム装置(10)に提供する代わりに、当該他のゲーム装置(10)から提供を受けることを希望するゲームデータの条件である交換条件を示す交換条件データを設定する。通信手段(14)は、他のゲーム装置(10)と近距離無線によって通信する。接続確立手段(20,S81)は、通信手段(14)を用いて、特定の他のゲーム装置(10)との間で無線通信による接続を確立するための処理を行う。ゲームデータ交換手段(20,S105〜S109,S135〜S139)は、通信手段(14)を用いて、特定の他のゲーム装置(10)との間でゲームデータを交換する。
たとえば、複数のゲーム装置(10)のうちの第1ゲーム装置および第2ゲーム装置について、いずれか一方のゲーム装置の接続確立手段(20,S81)は、接続要求データ、たとえば接続可能を示すデータをブロードキャスト送信し、当該接続要求データを受信した他方のゲーム装置との間で接続状態を確立する第1接続確立処理(20,S165〜S177,S195〜S207)を実行し、かつ、他方のゲーム装置の接続確立手段(2
0,S81)は、接続要求を受信して、当該接続要求をブロードキャスト送信した一方のゲーム装置との間で接続状態を確立する第2接続確立処理(20,S153〜S163,S183〜S193,S209〜S217)を実行する。第1ゲーム装置のゲームデータ交換手段(20,S105〜S109,S135〜S139)と第2ゲーム装置のゲームデータ交換手段(20,S105〜S109,S135〜S139)は、通信手段(14)を用いて、当該第1ゲーム装置と当該第2ゲーム装置との間で提供ゲームデータに関連する属性情報および交換条件データの少なくとも一方を通信する。このことにより、当該第1ゲーム装置の提供ゲームデータが当該第2ゲーム装置の交換条件を満たし、かつ、当該第2ゲーム装置の提供ゲームデータが当該第1ゲーム装置の交換条件を満たすか否かを判断し、両方の交換条件を満たすと判断した場合に、通信手段(14)を用いて、当該第1ゲーム装置と当該第2ゲーム装置とで通信することにより、第1ゲーム装置の提供ゲームデータと第2ゲーム装置の提供ゲームデータを交換する。
請求項2の発明においても、請求項1の発明と同様に、手軽にゲームデータを交換することができる。
請求項3の発明は請求項1または2に従属し、ゲーム装置は、ゲームプログラムを記憶するゲームプログラム記憶手段、ゲームプログラムを実行することにより、ゲームデータを生成するゲームプログラム実行手段、およびゲームプログラム実行手段によって生成されたゲームデータをゲームデータ記憶手段に記憶するゲームデータ記憶処理手段をさらに備える。
請求項3の発明では、ゲーム装置(10)は、ゲームプログラムを記憶するゲームプログラム記憶手段(42)を備えている。ゲームプログラム実行手段(20,S21〜S41)は、そのゲームプログラムを実行することによりゲームデータを生成する。ここで、ゲームデータの生成とは、たとえば、ゲームの状況に応じて、キャラクタデータやアイテムデータ等を獲得したり、キャラクタの属性情報を変化させたりすることである。ゲームデータ記憶処理手段(20,S41)は、ゲームプログラム実行手段(20,S21〜S41)によって生成されたゲームデータをゲームデータ記憶手段(28または44)に記憶する。つまり、キャラクタデータ,アイテムデータや属性情報が記録される。
請求項3の発明によれば、キャラクタデータのようなゲームデータを手軽に交換できるので、ゲームの趣向性を向上させることができる。
請求項4の発明は、請求項1または2に従属し、交換条件データは、提供を受けることを希望するゲームデータの種類を指定するデータを含む。
請求項4の発明では、交換条件データ(交換条件データ記憶領域282に記憶されるデータ)は、提供を受けることを希望する(提供を受けるべき)ゲームデータの種類を指定するデータ(キャラクタの種類)を含む。
請求項4の発明によれば、ゲームキャラクタなどのゲームデータを種類別に交換することができる。
請求項5の発明は請求項4に従属し、交換条件データは、提供を受けることを希望するゲームデータの属性値をさらに含む。
請求項5の発明では、交換条件データは、提供を受けることを希望するゲームデータの属性値(たとえば、キャラクタのレベル)をさらに含む。
請求項5の発明によれば、ゲームの種類だけでなく、キャラクタのレベルのような属性値を指定してゲームデータの交換をすることができる。
請求項6の発明は請求項1に従属し、交換希望送信手段は、交換希望データを継続的にブロードキャストする。
請求項6の発明では、交換希望送信手段(20,S167,S197)は、交換希望データを継続的にブロードキャストする。
請求項6の発明によれば、交換条件を満たす他のゲーム装置を継続的に探しつづけることが可能になる。したがって、本発明のゲーム装置をプレイヤが所持して移動した場合に、通信可能範囲内に存在する他のゲーム装置は変動するので、継続的に他のゲーム装置を探すことによって、ゲームデータを交換する可能性を高めることができる。
請求項7の発明は請求項1ないし6のいずれかに従属し、提供ゲームデータ指定手段は、プレイヤからの指示により提供ゲームデータを指定する。
請求項7の発明では、提供ゲームデータ指定手段(20,38,S45〜S57,S67)は、プレイヤからの指示によりゲームデータを指定する。
請求項7の発明によれば、プレイヤが所望のゲームデータを指定することができる。
請求項8の発明は請求項7に従属し、提供ゲームデータ指定手段は、ゲーム装置が実行する仮想ゲームの進行状況が所定条件を満たすとき、有効にされる。
請求項8の発明では、ゲーム装置(10)が実行する仮想ゲームの進行状況が所定条件を満たすとき(S43で“YES”)、提供ゲームデータ指定手段(20,38,S45〜S57,S67)が有効にされる。
請求項8の発明によれば、たとえば、ゲームクリアやレベルアップなどのゲーム進行の意欲を高めることができる。
請求項9の発明は請求項1ないし8のいずれかに従属し、交換条件設定手段は、プレイヤからの指示により交換条件を設定する。
請求項9の発明では、交換条件設定手段(20,38,S59〜S67)は、プレイヤからの指示により交換条件を設定する。
請求項9の発明によれば、プレイヤは所望のゲームデータを、提供を受けることを希望するゲームデータとして設定することができる。
請求項10の発明は請求項9に従属し、交換条件設定手段は、ゲーム装置が実行する仮想ゲームの進行状況が所定条件を満たすとき、有効にされる。
請求項10の発明では、ゲーム装置(10)が実行する仮想ゲームの進行状況が所定条件を満たすとき(S43で“YES”)、交換条件設定手段(20,38,S59〜S67)が有効にされる。
請求項10の発明によれば、たとえば、ゲームクリアやレベルアップなどのゲーム進行の意欲を高めることができる。
請求項11は請求項1ないし6のいずれかに従属し、提供ゲームデータ指定手段は、ゲーム装置が実行する仮想ゲームの進行状況が所定条件を満たすとき、当該所定条件に応じて提供ゲームデータを自動的に指定する。
請求項11の発明では、ゲーム装置(10)が実行する仮想ゲームの進行状況が所定条件を満たすとき(S43で“YES”)、提供ゲームデータ指定手段(20,38,S45〜S57,S67)は当該所定条件に応じて提供ゲームデータを自動的に指定する。つまり、ゲームのプログラマ等の開発者が意図する提供ゲームデータが自動的に設定される。
請求項11の発明によれば、プレイヤの手を煩わすことがない。また、どのゲームデータが指定されるのかが不明であるため、交換の意外性や楽しさを増大させることができる。
請求項12の発明は請求項1ないし6のいずれかに従属し、交換条件設定手段は、ゲーム装置が実行する仮想ゲームの進行状況が所定条件を満たすとき、当該所定条件に応じて交換条件を自動的に設定する。
請求項12の発明では、ゲーム装置(10)が実行する仮想ゲームの進行状況が所定条件を満たすとき(S43で“YES”)、交換条件設定手段(20,38,S59〜S67)は当該所定条件に応じて交換条件を自動的に設定する。つまり、ゲームプログラマ等の開発者が意図する交換条件すなわち提供を受けることを希望するゲームデータが自動的に指定される。
請求項12の発明によれば、プレイヤの手を煩わすことがない。また、どのゲームデータ指定されるのかが不明であるため、交換の意外性や楽しさを増大させることができる。
請求項13の発明は請求項1ないし12のいずれかに従属し、ゲームデータ交換手段は、両方の交換条件を満たすと判断した場合に、プレイヤに交換するか否かを確認する確認手段を含む。
請求項13の発明では、確認手段(18,20、S128,S129)は、両方の交換条件を満たすと判断した場合に、プレイヤに交換するか否かを確認する。
請求項13の発明によれば、プレイヤに交換するか否かを確認した後に、ゲームデータを交換するので、プレイヤが意図しないゲームデータが誤って交換されてしまうことを防止することができる。
請求項14の発明は請求項2に従属し、ゲーム装置は、ゲームプログラムを記憶するゲームプログラム記憶手段、およびゲームプログラムを実行するゲームプログラム実行手段をさらに備え、ゲームプログラム実行手段によってゲームプログラムが実行されているときに、接続確立手段によって他のゲーム装置と接続し、ゲームデータ交換手段によって両方の交換条件を満たす他のゲーム装置との間でゲームデータの交換処理を実行する。
請求項14の発明では、ゲーム装置(10)は、ゲームプログラムを記憶するゲームプログラム記憶手段(42)を備える。ゲームプログラム実行手段(20,S21〜S41)は、そのゲームプログラムを実行する。そして、ゲームプログラム実行手段(20,S21〜S41)によってゲームプログラムが実行されているときに、接続確立手段(20,S81)によって他のゲーム装置(10)と接続し、ゲームデータ交換手段(20,S
105〜S109,S135〜S139)によって両方の交換条件を満たす他のゲーム装置(10)との間でゲームデータの交換処理を実行する。
請求項14の発明によれば、ゲーム中であっても、ゲームデータを交換できるので、単にゲームデータの交換を待つような退屈さをプレイヤに与えることはない。また、ゲーム中に交換の機会を逃すこともない。
請求項15の発明は請求項14に従属し、ゲーム装置は、ゲームプログラム実行手段による仮想ゲームの進行状況が所定条件を満たすときに、接続確立手段によって他のゲーム装置と接続し、ゲームデータ交換手段によって両方の交換条件を満たす他のゲーム装置との間でゲームデータの交換処理を実行する。
請求項15の発明では、ゲーム装置(10)は、ゲームプログラム実行手段(20,S21〜S41)による仮想ゲームの進行状況が所定条件を満たすときに、接続確立手段(20,S81)によって他のゲーム装置(10)と接続し、ゲームデータ交換手段(20,S105〜S109,S135〜S139)によって両方の交換条件を満たす他のゲーム装置(10)との間でゲームデータの交換処理を実行する。
請求項15の発明によれば、随時変化する仮想ゲームの進行状況に従う交換条件で、ゲームデータを交換することができる。
請求項16の発明は請求項1に従属し、交換希望送信手段は、自己の提供ゲームデータに関連する属性情報と交換条件データとの少なくとも一方をブロードキャスト送信する。
請求項16の発明では、交換希望送信手段(20,S167,S197)は、自己の提供ゲームデータに関連する属性情報と交換条件データとの少なくとも一方をブロードキャスト送信する。
請求項16の発明によれば、提供ゲームデータに関連する属性情報や交換条件データをブロードキャスト送信するので、多数の他のゲーム装置にその情報を与えることができ、交換条件を満たすことを判断する処理を迅速に行うことができる。
請求項17の発明は請求項1に従属し、提供ゲームデータ指定手段は、複数の提供ゲームデータを指定可能であり、交換条件設定手段は、提供ゲームデータのそれぞれについて交換条件データを対応付けて設定し、第1ゲーム装置のゲームデータ交換手段と第2ゲーム装置のゲームデータ交換手段は、当該第1ゲーム装置の提供ゲームデータのそれぞれと、当該第2ゲーム装置の提供ゲームデータのそれぞれとの組み合わせについて、当該第1ゲーム装置の提供ゲームデータの1つである第1提供ゲームデータが当該第2ゲーム装置の提供ゲームデータの1つである第2提供ゲームデータに対応付けられた交換条件を満たし、かつ、当該第2提供ゲームデータが当該第1提供ゲームデータに対応付けられた交換条件を満たすことを判断し、両方の交換条件を満たすときに、当該第1提供ゲームデータと、当該第2提供ゲームデータとを交換する。
請求項17の発明では、提供ゲームデータ指定手段(20,38)は、複数の提供ゲームデータを指定可能であり、交換条件設定手段(20,38)は、提供ゲームデータのそれぞれについて交換条件データを対応付けて設定し、第1ゲーム装置のゲームデータ交換手段(20)と第2ゲーム装置のゲームデータ交換手段(20)は、当該第1ゲーム装置の提供ゲームデータのそれぞれと、当該第2ゲーム装置の提供ゲームデータのそれぞれとの組み合わせに比較する。そして、当該第1ゲーム装置の提供ゲームデータのうちの1つである第1提供ゲームデータが当該第2ゲーム装置の提供ゲームデータのうちの1つであ
る第2提供ゲームデータに対応付けられた交換条件を満たし、かつ、当該第2提供ゲームデータが当該第1提供ゲームデータに対応付けられた交換条件を満たすことを判断し、両方の交換条件を満たすときに、当該第1提供ゲームデータと、当該第2提供ゲームデータとを交換する。
請求項17の発明によれば、提供ゲームデータを多数指定できるため、交換条件を満たす確立を高くすることができる。また、提供ゲームデータごとに交換条件を設定できるので、プレイヤが希望する交換を実現することができる。
請求項18の発明は請求項1に従属し、ゲームデータ記憶手段に記憶されたゲームデータのうちの少なくとも1つを選択する選択手段、ゲームプログラムを記憶するゲームプログラム記憶手段、および選択手段によって選択されたゲームデータを仮想ゲーム世界に登場させて、ゲームプログラムを実行するゲームプログラム実行手段をさらに備え、ゲームデータ交換手段は、提供ゲームデータ指定手段によって指定された提供ゲームデータのうち、選択手段によって選択されているゲームデータについては、交換条件を満たすか否かの判断および提供ゲームデータの交換を行わないようにする。
請求項18の発明では、選択手段(20)はゲームデータ記憶手段(28または44)に記憶されたゲームデータのうちの少なくとも1つを選択する。ゲームプログラム記憶手段(42)は、ゲームプログラムを記憶し、ゲームプログラム実行手段(20)は、選択手段(20)によって選択されたゲームデータを、仮想ゲーム世界に登場させて、そのゲームプログラムを実行する。そして、ゲームデータ交換手段(20)は、提供ゲームデータ指定手段(20,38)によって指定された提供ゲームデータのうち、選択手段(20)によって選択されているゲームデータについては、交換条件を満たすか否かの判断および提供ゲームデータの交換を行わないようにする。ただし、交換条件を満たすか否かの判断のみを行わないようにしてもよい。当該判断を行わなければ、提供ゲームデータの交換も行われないからである。
請求項18の発明によれば、仮想ゲームで使用している(登場している)ゲームデータについては交換されることがないため、不都合が生じない。
請求項19の発明は請求項13に従属し、特定の他のゲーム装置との間でゲーム装置の識別情報を交換する識別情報交換手段、および確認手段がプレイヤに交換するか否かを確認する際に、両方の交換条件を満たす特定の他のゲーム装置についての識別情報をプレイヤに提示する提示手段をさらに備える。
請求項19の発明では、識別情報交換手段(14,20)は、特定の他のゲーム装置(10)との間でゲーム装置(10)の識別情報(UserName)を交換する。提示手段(18,20,S128)は、確認手段(18,20、S128,S129)がプレイヤに交換するか否かを確認する際に、両方の交換条件を満たす当該特定の他のゲーム装置(10)についての識別情報をプレイヤに提示する。
請求項19の発明によれば、交換相手のプレイヤを確認して交換をするかどうかの決定をすることができるので、都合が良い。特に本発明は近距離無線により多数のゲーム装置と通信を行うため、通信相手が特定できないことがあり、自分のゲームデータを提供する相手の情報を知ることは意義が大きい。
請求項20の発明は請求項1に従属し、ゲーム装置は、表示手段、および表示手段に対する電力供給を制御する電力制御手段を備え、交換希望送信手段、交換希望受信手段、およびゲームデータ交換手段は、電力制御手段によって表示手段に対する電力供給が止めら
れている間に、それぞれの処理を実行し、電力制御手段は、ゲームデータ交換手段による処理に関連するタイミングで、表示手段に対して電力供給をし、表示手段は、交換に関連する情報を表示する。
請求項20の発明では、ゲーム装置(10)は、表示手段(18)を備える。電力制御手段(20,22)は、表示手段(18)に対する電力供給を制御する。交換希望送信手段(20,S167,S197)、交換希望受信手段(20,S155,S185,S211)、およびゲームデータ交換手段(20,S105〜S109,S135〜S139)は、電力制御手段(20,22)によって表示手段(18)に対する電力供給が止められている間に、それぞれの処理を実行する。また、電力制御手段(20,22)は、ゲームデータ交換手段(20,S105〜S109,S135〜S139)による処理に関連するタイミング(たとえば、交換条件を満たす他のゲーム装置が見つかったタイミング、交換するかどうかをユーザに確認するタイミング、または、交換が完了したタイミング)で、表示手段(18)に対して電力供給を開始(再開)する。すると、表示手段(18)は、交換に関連する情報(交換条件を満たす相手のキャラクタの情報や、交換により失ったキャラクタの情報や交換により得たキャラクタの情報や交換相手のユーザ名等)を表示する。
請求項20の発明によれば、消費電力を抑えつつ交換条件を満たす相手を探すことができる。
請求項21の発明は請求項1に従属し、ゲーム装置は、ゲームプログラムと、当該ゲームプログラムの識別情報であるゲーム識別情報と、ゲームデータとが記憶された媒体を着脱自在に装着する装着手段、媒体が装着手段に装着されたときに、当該媒体からゲームプログラムと、ゲーム識別情報と、ゲームデータとを読み取る読取手段、および読取手段によって読み取られたゲーム識別情報を特定の他のゲーム装置との間で交換するゲーム識別情報交換手段をさらに備え、ゲームデータ交換手段は、ゲーム識別情報が一致を示すとき、特定の他のゲーム装置のゲームデータ交換手段との間で、提供ゲームデータを交換する。
請求項21の発明では、ゲーム装置(10)は、ゲームプログラムと、このゲームプログラムの識別情報であるゲーム識別情報(GameName)と、ゲームデータとが記憶された媒体(16)を着脱自在に装着する装着手段(40)を備える。読取手段(20,22)は、着脱手段(40)に媒体(16)が装着されたときに、その媒体(16)からゲームプログラムとゲーム識別情報とゲームデータを読み取る。ゲーム識別情報交換手段(14,20,22)は、読取手段(20,22)によって読み取られたゲーム識別情報を、特定の他のゲーム装置(10)との間で交換する。ゲームデータ交換手段(20,S105〜S109,S135〜S139)は、ゲーム識別情報が一致するとき(S155,S185,S211で“YES”)、特定の他のゲーム装置(10)のゲームデータ交換手段(20,S105〜S109,S135〜S139)との間で、提供ゲームデータを交換する。
請求項21の発明によれば、実行しているゲームが一致する相手とのみ交換条件の判定をするので無駄がない。
請求項22の発明は、ゲームデータを記憶するゲームデータ記憶手段、ゲームデータ記憶手段に記憶されたゲームデータのうち、他のゲーム装置に提供することを許容するゲームデータである提供ゲームデータを指定する提供ゲームデータ指定手段、提供ゲームデータを他のゲーム装置に提供する代わりに、当該他のゲーム装置から提供を受けることを希望するゲームデータの条件である交換条件を示す交換条件データを設定する交換条件設定
手段、他のゲーム装置と近距離無線によって通信するための通信手段、通信手段を用いて、他のゲーム装置に対して宛先を特定せずに交換希望データをブロードキャスト送信する交換希望送信手段、通信手段を用いて、他のゲーム装置から交換希望データを受信する交換希望受信手段、および特定の他のゲーム装置との間でゲームデータを交換するゲームデータ交換手段を備え、ゲームデータ交換手段は、通信手段を用いて特定の他のゲーム装置との間で提供ゲームデータに関連する属性情報および交換条件データの少なくとも一方を通信することにより、当該他のゲーム装置のゲームデータ交換手段と共同して、自身の提供ゲームデータが当該他のゲーム装置の交換条件を満たし、かつ、当該他のゲーム装置の提供ゲームデータが自身の交換条件を満たすか否かを判断し、両方の交換条件を満たすと判断した場合に、通信手段を用いて当該他のゲーム装置と通信することにより、自己の提供ゲームデータと当該他のゲーム装置の提供ゲームデータを交換する、ゲーム装置である。
請求項22の発明では、ゲーム装置(10)には、ゲームデータ記憶手段(28または44)が設けられ、ゲームデータが記憶される。提供ゲームデータ指定手段(20,38,S45〜S57,S67)は、ゲームデータ記憶手段(28または44)に記憶されたゲームデータのうち、他のゲーム装置(10)に提供することを許容するゲームデータである提供ゲームデータを指定する。交換条件設定手段(20,38,S59〜S67)は、提供ゲームデータを他のゲーム装置(10)に提供する代わりに、当該他のゲーム装置(10)から提供を受けることを希望するゲームデータの条件である交換条件を示す交換条件データを設定する。通信手段(14)は、他のゲーム装置(10)との近距離無線によって通信する。交換希望送信手段(20,S167,S197)は、通信手段(14)を用いて、他のゲーム装置(10)に対して宛先を特定せずに交換希望データをブロードキャスト送信する。交換希望受信手段(20,S155,S185,S211)は、通信手段(14)を用いて、他のゲーム装置(10)から交換希望データを受信する。ゲームデータ交換手段(20,S105〜S109,S135〜S139)は、通信手段(14)を用いて、特定の他のゲーム装置(10)との間でゲームデータを交換する。たとえば、ゲームデータ交換手段(20,S105〜S109,S135〜S139)は、通信手段(14)を用いて当該他のゲーム装置(10)との間で提供ゲームデータに関連する属性情報および交換条件データの少なくとも一方を通信する。これにより、当該他のゲーム装置(10)のゲームデータ交換手段(20,S105〜S109,S135〜S139)と共同して、自身の提供ゲームデータが当該他のゲーム装置(10)の交換条件を満たし、かつ、当該他のゲーム装置(10)の提供ゲームデータが自身の交換条件を満たすか否かを判断し、両方の交換条件を満たすと判断した場合に、通信手段(14)を用いて、当該他のゲーム装置(10)と通信することにより、自己の提供ゲームデータと当該他のゲーム装置(10)の提供ゲームデータとを交換する。
請求項22の発明によれば、同じ種類の複数のゲーム装置によって本発明を実施することができる。すなわち、ゲーム装置のメーカーにとっては、1つの種類のゲーム装置を市場に提供すればよい。また、プレイヤにとっても、1つのゲーム装置を購入すればいずれのゲーム装置との間でも通信が可能になって都合がよい。
請求項23の発明は請求項22に従属し、交換希望送信手段の処理と交換希望受信手段の処理を交互に実行する切替手段を備える。
請求項23の発明では、切替手段(20,S153,S165,S183,S195,S209)は、交換希望送信手段(20,S167,S197)の処理と交換希望受信手段(20,S155,S185,S211)の処理とを交互に切替える。
請求項23の発明によれば、他のゲーム装置の間で確実に通信することができ、ゲーム
データを交換することができる。
請求項24の発明は請求項23に従属し、切替手段は、交換希望送信手段の処理により交換希望データのブロードキャストを行う第1期間と、交換希望受信手段の処理により交換希望データの受信を試みる第2期間とを交互に繰り返し、第1期間および第2期間の少なくとも一方の長さを可変的に設定する期間長さ設定手段をさらに備える。
請求項24の発明では、切替手段(20,S153,S165,S183,S195,S209)は、第1期間と第2期間とを交互に繰り返す。第1期間では、交換希望送信手段(20,S167,S197)の処理により交換希望データのブロードキャストを行う。第2期間では、交換希望手段(20,S155,S185)の処理により交換希望データの受信を試みる。期間長さ設定手段(20,S151,S181)は、第1期間および第2期間の少なくとも一方の長さを可変的(たとえば、ランダム)に設定する。
ここで、第1期間の処理を実行しているゲーム装置と第2期間の処理を実行しているゲーム装置との間で接続の確立が可能であり、第1期間の処理を実行しているゲーム装置と第1期間の処理を実行しているゲーム装置との間、および、第2期間の処理を実行しているゲーム装置と第2期間の処理を実行しているゲーム装置との間では接続の確立が不可能である。ゆえに、第1期間および第2期間が不変である場合には、それらの期間が一致しているゲーム装置の間ではいつまで経っても接続の確立ができないことになる。そこで、請求項24の発明では、第1期間と第2期間の少なくとも一方が可変的に設定され、これが繰り返されるので、複数のゲーム装置の間で第1期間および第2期間の繰り返しが継続的に一致することがない。
請求項24の発明によれば、他のゲーム装置との間で確実に通信することができ、ゲームデータを交換することができる。
請求項25の発明は請求項23に従属し、切替手段は、交換希望送信手段の処理により交換希望データのブロードキャストを行う第1期間と、交換希望受信手段の処理により交換希望データの受信を試みる第2期間とを交互に繰り返し、第1期間および第2期間の少なくとも一方の期間の始期を可変的に設定する期間始期設定手段をさらに備える。
請求項25の発明では、請求項24の発明で述べた第1期間および第2期間の少なくとも一方の開始時期を可変的(たとえばランダム)に設定する。
請求項25の発明においても、請求項24の発明と同様に、他のゲーム装置との間で確実に通信することができ、ゲームデータを交換することができる。
請求項26の発明は、ゲームデータを記憶するゲームデータ記憶手段、ゲームデータ記憶手段に記憶されたゲームデータのうち、他のゲーム装置に提供することを許容する提供ゲームデータを指定する提供ゲームデータ指定手段、提供ゲームデータを他のゲーム装置に提供する代わりに、当該他のゲーム装置から提供を受けることを希望するゲームデータの条件である交換条件を示す交換条件データを設定する交換条件設定手段、他のゲーム装置と近距離無線によって通信するための通信手段、通信手段を用いて、特定の他のゲーム装置との間で無線通信による接続を確立するための処理を行う接続確立手段、および提供ゲームデータと、交換条件を満たす特定の他のゲーム装置のゲームデータとを、通信手段を用いて交換するゲームデータ交換手段を備え、接続確立手段は、接続要求データをブロードキャスト送信し、当該接続要求データを受信した他のゲーム装置との間で接続状態を確立する第1接続確立処理を実行し、または、他のゲーム装置から送信された接続要求データを受信して、当該接続要求データをブロードキャスト送信した当該他のゲーム装置と
の間で接続状態を確立する第2接続確立処理を実行し、ゲームデータ交換手段は、通信手段を用いて他のゲーム装置との間で提供ゲームデータに関連する属性情報および交換条件データの少なくとも一方を通信することにより、当該他のゲーム装置のゲームデータ交換手段と共同して、自身の提供ゲームデータが当該他のゲーム装置の交換条件を満たし、かつ、当該他のゲーム装置の提供ゲームデータが自身の交換条件を満たすか否かを判断し、両方の交換条件を満たすと判断した場合に、通信手段を用いて当該他のゲーム装置と通信することにより、自己の提供ゲームデータと当該他のゲーム装置の提供ゲームデータとを交換する、ゲーム装置である。
請求項26の発明においても、請求項22の発明と同様に、同じ種類の複数のゲーム装置によって本発明を実施することができる。すなわち、ゲーム装置のメーカーにとっては、第1接続確立処理機能を持つゲーム装置と第2接続確立処理機能を持つゲーム装置の両方を市場に提供する必要がなく、1つの種類のゲーム装置を市場に提供すればよい。また、プレイヤにとっても、1つのゲーム装置を購入すればいずれのゲーム装置との間でも通信が可能になって都合がよい。
請求項27の発明は請求項26の従属し、第1接続確立処理を実行する機能と第2接続確立処理を実行する機能とを有し、第1接続確立処理と第2接続確立処理とを交互に実行する切替手段を備える。
請求項27の発明においても、請求項23の発明と同様に、他のゲーム装置の間で確実に通信することができ、ゲームデータを交換することができる。
請求項28の発明は請求項27に従属し、切替手段は、第1接続確立処理により接続要求データのブロードキャストを行う第1期間と、第2接続確立処理により接続要求データの受信を試みる第2期間とを交互に繰り返し、第1期間および第2期間の少なくとも一方の長さを可変的に設定する期間長さ設定手段をさらに備える。
請求項28の発明においても、請求項24の発明と同様に、他のゲーム装置との間で確実に通信することができ、ゲームデータを交換することができる。
請求項29の発明は請求項27に従属し、切替手段は、第1接続確立処理により接続要求データのブロードキャストを行う第1期間と、第2接続確立処理により接続要求データの受信を試みる第2期間とを交互に繰り返し、第1期間および第2期間の少なくとも一方の期間の始期を可変的に設定する期間始期設定手段をさらに備える。
請求項29の発明においても、請求項25の発明と同様に、他のゲーム装置との間で確実に通信することができ、ゲームデータを交換することができる。
請求項30は、プロセッサ、ゲームデータを記憶するゲームデータ記憶手段、および、他のゲーム装置と近距離無線によって通信するための通信手段を備える携帯型のゲーム装置を複数備え、当該各ゲーム装置間でゲームデータを交換するゲームシステムにおいて、当該各ゲーム装置に実行させるゲームプログラムであって、ゲーム装置のプロセサに、ゲームデータ記憶手段に記憶されたゲームデータのうち、他のゲーム装置に提供することを許容するゲームデータである提供ゲームデータを指定する提供ゲームデータ指定ステップ、提供ゲームデータを他のゲーム装置に提供する代わりに、当該他のゲーム装置から提供を受けることを希望するゲームデータの条件である交換条件を示す交換条件データを設定する交換条件設定ステップ、通信手段を用いて、他のゲーム装置に対して宛先を特定せずに交換希望データをブロードキャスト送信する交換希望送信ステップ、通信手段を用いて、他のゲーム装置の交換希望送信手段からの交換希望データを受信する交換希望受信ステ
ップ、および通信手段を用いて、特定の他のゲーム装置との間で提供ゲームデータに関連する属性情報および交換条件データの少なくとも一方を通信することにより、当該他のゲーム装置と共同して、自身の提供ゲームデータが当該他のゲーム装置の交換条件を満たし、かつ、当該他のゲーム装置の提供ゲームデータが自身の交換条件を満たすか否かを判断し、両方の交換条件を満たすと判断した場合に、通信手段を用いて当該他のゲーム装置と通信することにより、自己の提供ゲームデータと当該他のゲーム装置の提供ゲームデータとを交換するゲームデータ交換ステップを実行させる、ゲームプログラムである。
請求項30の発明においても、請求項1の発明と同様に、手軽にゲームデータを交換することができる。
請求項31の発明は、プロセッサ、ゲームデータを記憶するゲームデータ記憶手段、および、他のゲーム装置と近距離無線によって通信するための通信手段を備える携帯型のゲーム装置を複数備え、当該各ゲーム装置間でゲームデータを交換するゲームシステムにおいて、当該各ゲーム装置に実行させるゲームプログラムであって、ゲーム装置のプロセサに、ゲームデータ記憶手段に記憶されたゲームデータのうち、他のゲーム装置に提供することを許容するゲームデータである提供ゲームデータを指定する提供ゲームデータ指定ステップ、提供ゲームデータを他のゲーム装置に提供する代わりに、当該他のゲーム装置から提供を受けることを希望するゲームデータの条件である交換条件を示す交換条件データを設定する交換条件設定ステップ、通信手段を用いて、接続要求データをブロードキャスト送信し、当該接続要求データを受信した他のゲーム装置との間で無線通信による接続状態を確立する第1接続確立処理を実行させ、または、他のゲーム装置から送信された接続要求データを受信して、当該接続要求データをブロードキャスト送信した当該他のゲーム装置との間で接続状態を確立する第2接続確立処理を実行させる接続確立ステップ、および通信手段を用いて、他のゲーム装置との間で提供ゲームデータに関連する属性情報および交換条件データの少なくとも一方を通信することにより、当該他のゲーム装置と共同して、自身の提供ゲームデータが当該他のゲーム装置の交換条件を満たし、かつ、当該他のゲーム装置の提供ゲームデータが自身の交換条件を満たすか否かを判断し、両方の交換条件を満たすと判断した場合に、通信手段を用いて当該他のゲーム装置と通信することにより、自己の提供ゲームデータと当該他のゲーム装置の提供ゲームデータとを交換するゲームデータ交換ステップを実行させる、ゲームプログラムである。
請求項31においても、請求項2の発明と同様に、手軽にゲームデータを交換することができる。
この発明によれば、無線通信によって接続されるゲーム装置同士で交換条件が成立するかどうかを判断し、交換条件が成立する場合にゲームデータを交換するので、手軽にゲームデータを交換することができる。また、交換する相手が友人・知人等に限定されてないため、交換の楽しさを十分に満喫することができ、したがって、ゲームの興趣性を向上させることができる。
この発明の上述の目的,その他の目的,特徴および利点は、図面を参照して行う以下の実施例の詳細な説明から一層明らかとなろう。
この発明が適用される無線通信ゲームシステムは、一例として、図1に示すような携帯ゲーム装置10を利用する。この実施例では、携帯ゲーム装置10は、たとえばゲームボーイアドバンス(GAMEBOY ADVANCE :商品名)のような携帯ゲーム機12と、その携帯ゲーム機12の通信コネクタ46に接続された無線通信ユニット14およびカートリッジコネクタ40に接続されたゲームカートリッジ16を含む。つまり、この実施例では、携帯ゲーム装置10は、携帯ゲーム機12、無線通信ユニット14およびカートリッジ16によって構成される。
図1に示す携帯ゲーム機12は、プロセサ20を含み、このプロセサ20は、CPUコア22とそれに関連するブートROM24,LCDコントローラ26,WRAM(ワーキングRAM:以下、同様である。)28,VRAM30および周辺回路32とを含む。ただし、周辺回路32は、音声(サウンド)回路,DMA(Direct Memory Access)回路,
タイマ回路,入出力インターフェイス(IO)などを含む。
携帯ゲーム機12の前面に設けられたLCD18には、プロセサ20から表示信号、この実施例ではRGB信号が与えられ、したがって、LCD18ではゲーム画像がカラー表示される。そして、プロセサ20からは、サウンド回路34にオーディオ信号が与えられ、そのオーディオ信号によって、スピーカ36からゲーム音楽や効果音などの音声(音)が出力される。また、携帯ゲーム機12の前面にLCD18を挟んで設けられる十字キーやスタートキー,セレクトキーおよびAボタン並びにBボタンがまとめて操作スイッチ38として示され、この操作スイッチ38からの操作信号がプロセサ20に入力される。したがって、プロセサ20は、操作スイッチ38を通して与えられたプレイヤの指示に従った処理を実行する。
図示は省略するが、LCD18には電池(1次電池または2次電池)から電力が供給されており、所定のレジスタ(LCD電力供給レジスタ)の値を0に設定することによって、LCD18への電力供給が停止される。また、当該レジスタの値を1に設定すると、LCD18への電力供給が開始(再開)される。たとえば、LCD電力供給レジスタは、WRAM28内に設けられ、その値はCPUコア22によって書き換えられる。つまり、CPUコア22が電力供給の開始(オン)/停止(オフ)を制御する。
また、携帯ゲーム機12はカートリッジコネクタ40を有し、このカートリッジコネクタ40には、カートリッジ16が接続または挿入される。カートリッジ16にはROM42およびバックアップRAM44が内蔵され、ROM42には携帯ゲーム機12で実行すべきゲーム(仮想ゲーム)のためのゲームプログラムやゲーム画像(キャラクタ画像を含む。)等が予め設定(記憶)されている。また、ROM42には、ROM42に記憶されるゲームプログラムを識別する識別情報(後述する「GameName」)が記憶されている。バックアップRAM44は、そのゲームの途中データやゲームの結果データを記憶(セーブ)する。
CPUコア22は携帯ゲーム機12の電源がオンになったときに、ブートROM24に記憶されたブートプログラムを実行し、携帯ゲーム機12の起動処理を行う。その後、CPUコア22はカートリッジ16のROM42に記憶されたゲームプログラムを実行し、実行中の一時的なデータをWRAM28に記憶しつつゲーム処理を実行する。また、CPUコア22がゲームプログラムを実行することによって生成された画像データはVRAM30に記憶され、VRAM30に記憶された画像データはLCDコントローラ26によってLCD18に出力される。
携帯ゲーム機12にはさらに通信コネクタ46が設けられ、この通信コネクタ46には無線通信ユニット14のコネクタ48が接続される。この実施例で用いる携帯ゲーム機12は、一例としてゲームボーイアドバンス(商品名)であり、その場合、上述のカートリッジコネクタ40は、LCD18を前面(正面)としたときの上面奥側に設けられる32ピンコネクタであり、通信コネクタ46は上面手前側に設けられる6ピンコネクタである。
無線通信ユニット14は、ベースバンドIC50を含み、このベースバンドIC50はROM52を含む。ROM52には、たとえばOCD(One-Cartridge Download)プログラムやその他のプログラムが内蔵され、ベースバンドIC50は、それらのプログラムに従って動作する。
なお、ワンカートリッジダウンロードプログラムとは、OCモード(ワンカートリッジモード:親機だけゲームカートリッジが装着されていて、子機はその親機カートリッジか
らの子機用プログラムのダウンロードを受けて動作するモード)において、子機へプログラムをダウンロードするためのプログラムである。
無線通信ユニット14にはさらにEEPROM54が設けられ、このEEPROM54には、たとえば、プレイヤ名が固有に設定される。ベースバンド(Base Band )IC50は、携帯ゲーム機12からコネクタ46および48を介して転送されてくるゲームデータや、EEPROM54のプレイヤ名等を含んだデータを、RF(Radio Frequency )−IC56に送出し、RF−IC56は、そのデータを変調して、アンテナ58から電波を送信する。ただし、その電波強度は、非常に微弱で、電波法においてユーザが無免許で利用できる程度の小さい値に設定されている。また、この無線通信ユニット14には電源回路60が設けられている。この電源回路60は典型的には電池であり、無線通信ユニット14の各コンポーネントに直流電源を供給する。
無線通信ユニットでは、また、他の携帯ゲーム装置から送信された電波をアンテナ58で受信して、RF−IC56によって復調し、復調信号がベースバンドIC50に入力される。したがって、ベースバンドIC50は、復調信号をデコードして、データを復元し、そのデータをコネクタ48および46を介して携帯ゲーム機12すなわちWRAM28に転送する。
図2はWRAM28のメモリマップを示す。この実施例では、WRAM28は、提供キャラクタ情報領域280、交換条件データ領域282、キャラクタデータ領域284および交換テーブル記憶領域286を含む。
提供キャラクタ情報領域280には、所有するゲームキャラクタ(以下、単に「キャラクタ」という。)のうち、他のプレイヤまたはユーザ(以下、単に「プレイヤ」という。)に提供することが選択されたキャラクタについての情報(キャラクタの種類,レベル等)が記憶される。ここで、提供キャラクタ情報1は提供キャラクタの種類を示す情報であり、提供キャラクタ情報2は提供キャラクタのレベルを示す情報である。また、提供キャラクタ情報領域280に記憶されるデータは、キャラクタデータ領域284に記憶されるデータのうち提供キャラクタについてのデータがコピーされて記憶されるものであり、ゲームデータ交換処理において、キャラクタデータ領域284を直接参照するようにすれば、提供キャラクタ情報記憶領域を別途設ける必要はない。
所有するキャラクタのうち他のプレイヤに提供するキャラクタは、プレイヤが操作スイッチ38を用いて入力(指定)することによって選択され、または、ゲームの進行に基づいて自動的に選択される。
交換条件データ領域282には、他のプレイヤから提供を受けたいキャラクタに関する情報(キャラクタ種類,レベル等)が交換条件として記憶される。交換条件1にはキャラクタの種類が設定され、交換条件2にはレベルが設定される。この交換条件は、プレイヤによって操作スイッチ38を用いて入力(指定)され、または、ゲームの進行に基づいて自動的に決定される。
キャラクタデータ領域284には、プレイヤが所有するキャラクタ(この実施例では、キャラクタ名「マリオ」、「ルイージ」、「クッパ」、「ピーチ」などのキャラクタ)についての情報(キャラクタ情報)が、キャラクタ毎に記憶される。プレイヤは仮想的なゲーム世界の中で、ゲーム世界中に存在するキャラクタを捕獲したり仲間にしたりしつつ冒険を進める。このように捕獲したり仲間にしたりしたキャラクタに関する情報がキャラクタデータ領域284に記憶される。図2からも分かるように、キャラクタ情報は、キャラクタ種類、レベルと当該キャラクタの属性値すなわち生命力(ライフ)および攻撃力(ヒ
ットポイント)とを含む。たとえば、この実施例では、キャラクタデータ領域284には、第1キャラクタ情報データ284a、第2キャラクタ情報データ284bが記憶される。プレイヤが3つ以上のキャラクタを所有する場合には、第3キャラクタ情報データ,第4キャラクタ情報データ…と記憶される。
キャラクタ情報データ(キャラクタデータ領域284のデータ)は、ゲームの進行に従って随時更新される。たとえば、新たなキャラクタを捕獲したときには、当該新たなキャラクタについてのキャラクタ情報が追加される。また、既に捕獲済みのキャラクタのレベルがアップした場合には、当該キャラクタのレベルの値が更新される。
また、このキャラクタ情報データは、プレイヤの指示或いはゲームの進行状況に従ってバックアップRAM44に記憶(セーブ)される。したがって、前回の続きからゲームを開始する場合には、バックアップRAM44に記憶されたキャラクタ情報データが読み出され、キャラクタデータ領域284に書き込まれる(ロードされる)。
図3はバックアップRAM44のメモリマップを示す。上述したように、バックアップRAM44は、セーブしたゲームデータすなわちキャラクタ情報データを記憶する。この実施例では、たとえば、バックアップRAM44には、第1キャラクタ情報データ284aおよび第2キャラクタ情報データ284bが記憶される。
図2に戻って、交換テーブル記憶領域286は、仮想ゲームの進行状況が所定条件を満たすときに、ゲームデータの交換を可能にするためのテーブルを記憶する。このテーブルには、図4に示すように、仮想ゲームの進行状況に応じて、交換開始条件、交換終了条件、提供キャラクタの指定データ、要求キャラクタの指定データが記憶される。このテーブルを参照することにより、仮想ゲームの進行状況に応じて、提供キャラクタと交換条件が設定され、ゲームデータの交換が可能になる。
交換開始条件は、ゲームデータの交換を開始するための条件であり、この条件を満たすと、後述するように、所定のキャラクタの交換可能な状態となる。たとえば、この実施例では、交換開始条件としては、特定アイテムを取得(入手)したこと、特定の敵キャラクタ(プレイヤの操作に拘わらずゲームプログラムに従って行動や動作が制御されるノンプレイヤキャラクタ)を倒したこと、特定のノンプレイヤキャラクタ(敵キャラクタを除くノンプレイヤキャラクタ)を救出したり、或いはそのようなノンプレイヤキャラクタの願いを叶えたりしたこと、特定の月日(いずれか一方でも可)になったこと、および特定の時刻になったことなどが該当する。
交換終了条件は、特定の月日(いずれか一方でも可であり、交換開始条件に対応して決定される。)および特定の時刻などが該当する。なお、交換テーブルにおいて、横棒(バー)を表示してある項目については、特に交換終了条件がないことを示してあるが、当該項目については、キャラクタを交換することにより、交換の処理を終了する。
提供キャラクタの指定データは、提供キャラクタを設定するためのデータであり、提供キャラクタの種類およびレベルの項目(条件)を含み、種類の項目には、提供するキャラクタの種類(この実施例では、キャラクタの名称)が記述され、レベルの項目には、対応するキャラクタのレベルが記述される。この記述に基づいて、所有するキャラクタのうちこの条件(種類およびレベル)を満たすキャラクタがあるか否かが判断され、この条件を満たすキャラクタがある場合には、そのキャラクタが提供キャラクタとして選択されて、そのキャラクタについての情報(キャラクタ種類,レベル等)が前述の提供キャラクタ情報領域280に記憶される。ただし、提供するキャラクタはプレイヤが任意に指定することも可能である。この場合には、所有するキャラクタからプレイヤが任意に指定したキャ
ラクタが提供するキャラクタとして選択されて、そのキャラクタについての情報が前述の提供キャラクタ情報記憶領域280に記憶される。
なお、交換テーブルにおいては、種類やレベルについて、プレイヤが任意に指定できる場合には、「プレイヤ任意」と記述してあり、また、特に指定がない場合には、「不問」と記述してある。以下、同様である。
要求キャラクタの指定データは、交換条件を設定するためのデータであり、他のプレイヤに提供を要求するキャラクタの種類およびレベルの項目(条件)を含み、種類の項目には、要求するキャラクタの種類(この実施例では、キャラクタの名称)が記述され、レベルの項目には、対応するキャラクタのレベルが記述される。この記述に基づいて交換条件が決定される。ただし、要求するキャラクタの種類はプレイヤが任意に指定することも可能である。また、レベルについては、特に指定がない場合、提供するキャラクタのレベル以上のレベルを指定する場合やプレイヤが任意に指定できる場合がある。このようにして決定された交換条件が交換条件データ領域282に記憶される。
具体的には、交換テーブルを参照して、番号1では、交換開始条件が「特定アイテムを入手」したことであり、交換終了条件は特に定めがない。提供キャラクタの条件としては、種類が「マリオ」であり、そのレベルは「5」である。また、要求キャラクタとしては、種類が「クッパ」であり、そのレベルは「5」である。すなわち、ゲーム世界においてプレイヤキャラクタが特定アイテムを入手したときに、レベル5のマリオを所有していれば、他のプレイヤが所有するレベル5のクッパとの交換が可能になる。この場合、提供キャラクタ情報記憶領域280には、提供キャラクタの種類として「マリオ」が設定され、レベルとして「5」が設定される。そして、交換条件データ記憶領域282には、要求キャラクタの種類として「クッパ」が設定され、レベルとして「5」が設定される。
また、番号4では、交換開始条件が「特定の月日(4月10日)」であり、交換終了条件が交換開始条件に相関する「特定の月日(4月15日)」である。提供キャラクタの条件としては、種類が「クッパ」であり、そのレベルは「10以上」である。また、要求キャラクタの条件としては、種類が「プレイヤ任意」であり、そのレベルは「提供キャラクタのレベル以上」である。すなわち、本実施例の携帯ゲーム機12はタイマを備えており、このタイマによってゲーム世界における日付が管理されている。そして、ゲーム世界における日付が4月10日から4月15日までの間、レベル10以上のクッパを所有しているプレイヤは、そのクッパのレベル以上についての任意のキャラクタと交換することが可能になる。たとえばレベル15のクッパを所有しているプレイヤは、レベル15以上のルイージとの交換を希望することができる。この場合、提供キャラクタ情報記憶領域280には、提供キャラクタの種類として「クッパ」が設定され、レベルとして「15」が設定される。そして、交換条件データ記憶領域282には、要求キャラクタの種類として「ルイージ」が設定され、レベルとして「15以上」が設定される。
このような交換テーブルは、予めプログラマ等の開発者によって決定され、図示は省略したが、カートリッジ16のROM42内に記憶され、携帯ゲーム機12の主電源がオンされた後、一時に或いは必要に応じて、WRAM28にロードされる。提供キャラクタや交換条件(要求キャラクタ)は交換テーブルを参照して自動的に設定されるが、その一部または全部をプレイヤが任意に設定することができる。
なお、図4に示す交換テーブルは、単なる例示であり、これに限定される必要はない。
たとえば、この実施例のゲームシステムでは、少なくとも2台の図1に示すような携帯ゲーム装置10を利用し、互いに通信させることにより、各携帯ゲーム装置10のプレイ
ヤは通信ゲームを楽しむことができる。つまり、図5の点線64は自機携帯ゲーム装置62の通信可能範囲を示しており、携帯ゲーム装置62は、通信可能範囲64に存在する携帯ゲーム装置との間で通信(無線通信)することができる。この通信可能範囲64が上述の微弱な電波によって親機と子機との間のデータ通信が可能な範囲であり、この通信可能範囲64の中に存在する複数の携帯ゲーム装置は、どれでもが、任意に、親機となりまたは子機となることができる。
なお、図5においては、自機携帯ゲーム装置62の通信可能範囲64に、ユーザ名「太郎」、「一郎」および「二郎」の携帯ゲーム装置が存在し、自機携帯ゲーム装置62はユーザ名「二郎」の携帯ゲーム装置と無線通信している様子を示してある。
携帯ゲーム装置62がその通信可能範囲64に存在する他の携帯ゲーム装置にエントリして、複数のゲーム装置が通信ゲームを楽しむための携帯ゲーム装置の動作等については、本件出願人が先に出願した特願2002−306867号に詳細に開示されており、また、本願の本質的な内容ではないため、ここでは、詳細な説明は省略することにする。
2台以上の携帯ゲーム装置が通信可能に接続されると、上述したように、各携帯ゲーム装置のプレイヤは通信ゲームを楽しむことができる。ただし、各プレイヤは自身の携帯ゲーム装置のみを用いて、つまり、通信せずに、単独でゲームを楽しむことができることは言うまでもない。なお、以下においては、通信または単独でゲームをプレイするモードをゲームモードという。
また、携帯ゲーム装置62は、その通信可能範囲64に存在する他の1の携帯ゲーム装置との間で、ゲームデータすなわちキャラクタ情報データを交換することができる。簡単に説明すると、自機の携帯ゲーム装置62では、主電源がオンであり、かつ、ゲームをプレイしていない(ゲームを開始しておらず、また、ゲームを終了している)状態では、つまりゲームモードでない場合には、キャラクタの交換モードが設定される。
交換モードで交換可能な状態であれば、携帯ゲーム装置62は、通信可能範囲64に存在し、かつ、同じく交換可能な状態である他の携帯ゲーム装置を探索(サーチ)する。このとき、携帯ゲーム装置62は、親機として子機を探す処理と、子機として親機を探す処理を交互に繰り返す。そして、通信可能な他の携帯ゲーム装置を探したときは、無線通信による接続状態(通信状態)の確立を試みる。このサーチおよび接続処理については、後で詳細に説明する(図16〜図20参照)。
携帯ゲーム装置62は、他の携帯ゲーム装置との間で接続状態を確立すると、提供キャラクタの情報(提供キャラクタの種類情報やレベル情報)や交換条件をやり取りし、互いの交換条件が一致(合致)するか否かを判断する。交換条件が一致する場合には、提供キャラクタのデータを交換するものである。
図6は、交換条件が一致する場合における、2つの携帯ゲーム装置(親機と子機)間のやり取りの流れを示す図解図である。この図6を参照して、親機と子機との間で接続状態が確立されると、子機は自身の提供キャラクタ情報1および提供キャラクタ情報2を親機に送信する。親機は、子機の提供キャラクタ情報1および提供キャラクタ情報2を受信すると、自身の交換条件1および交換条件2とそれぞれ比較し、一致するかどうかを判断する。それぞれが一致する場合、すなわち子機の提供キャラクタ情報1および提供キャラクタ情報2が自身の交換条件1および交換条件2を満たす場合には、親機は交換要求を子機に送信し、さらに、自身の提供キャラクタ情報1および提供キャラクタ情報2を子機に送信する。
子機は、親機の提供キャラクタ情報1および提供キャラクタ情報2を受信すると、自身の交換条件1および交換条件2とそれぞれ比較し、一致するかどうかを判断する。それぞれが一致する場合、すなわち親機の提供キャラクタ情報1および提供キャラクタ情報2が自身の交換条件1および交換条件2を満たす場合には、つまり交換条件を満たす場合には、子機は交換応答を親機に送信する。
すると、親機は、この交換応答を受信して、自身の提供キャラクタ(図6では、説明の便宜上、「キャラクタA」と表記する。)についてのキャラクタ情報データを子機に送信する。その後、子機は、自身の提供キャラクタ(図6では、説明の便宜上、「キャラクタB」と表記する。)についてのキャラクタ情報データを親機に送信する。このようにして、親機と子機との間で、キャラクタの交換が実行される。
なお、この実施例では、図6に示したように、親機および子機は、それぞれ、通信相手に対して提供キャラクタ情報を送信し、これを受信した携帯ゲーム装置が交換条件を満たすかどうかを判断するようにしているが、一方の携帯ゲーム装置(たとえば、子機)が自身の提供キャラクタ情報および交換条件を、他方の携帯ゲーム装置(たとえば、親機)に送信して、当該親機が、交換条件を満たすかどうかを一度に判断するようにしてもよい。
また、この実施例では、図6に示したように、子機から提供キャラクタ情報を送信し、これを受信した親機が自身の交換条件を満たすかどうか判断して、条件を満たすと判断した場合に、交換要求を送信するようにしてあるのは、無駄な通信を無くすためである。つまり、条件を満たさない場合には、そのままキャラクタの交換が中断されることになる。すなわち、親機からの提供キャラクタ情報の送信がされることがない。
さらに、上述したように、各キャラクタの画像データは、カートリッジ16内のROM42に記憶されており、また、送受信するデータ量を低減して通信にかかる時間の効率を上げるために、この実施例では、キャラクタを交換する際には、キャラクタの種類を指定する識別番号を交換するようにしてあるが、交換するキャラクタについての画像データ等を交換するようにしてもよい。
図7以降を参照して後述する実施例では、ゲームモードと交換モードを区別せず、ゲームプレイを実行中に交換処理を平行して実行している。すなわち、ゲームプレイを実行している間も交換条件を満たす他のゲーム装置を探すようにし、交換条件を満たす他のゲーム装置を発見したときにゲームデータの交換処理を行うようにする。このようにすることによって、交換条件を満たす他のゲーム装置を探している間にゲームプレイできるので退屈することがない。
具体的には、携帯ゲーム機12のプロセサ20ないしはCPUコア22は、図7に示すフロー図に従って処理する。携帯ゲーム機12の主電源がオンされると、CPUコア22は処理を開始し、ステップS1で、交換可能フラグをオフ(0に設定)する。続くステップS3では、各キャラクタ(初期状態で所有するキャラクタ)の属性値すなわちレベル、生命力、攻撃力を初期化する。つまり、初期値に設定する。なお、ステップS3の処理は、ゲームを最初にプレイするときのみおこなわれる処理であり、2回目以降にプレイするときには実行されない。
次のステップS5では、後で詳細に説明するゲーム処理(図8〜図11参照)を実行する。そして、ステップS7で、交換可能フラグがオン(=1)であるかどうかを判断する。ステップS7で“NO”であれば、つまり交換可能フラグがオフ(=0)であれば、キャラクタを交換することができないと判断して、そのままステップS5に戻る。
一方、ステップS7で“YES”であれば、つまり交換可能フラグがオン(=1)であれば、キャラクタを交換することができると判断して、ステップS9で、後述するキャラクタ交換処理(図12〜図15)を実行して、ステップS5に戻る。
図8に示すように、ゲーム処理が開始されると、ステップS21では、戦闘開始かどうかを判断する。つまり、戦闘シーンに移行されたかどうかを判断する。図示は省略するが、たとえば、主人公のキャラクタ(プレイヤキャラクタ)が対戦相手のキャラクタ(敵キャラクタ)と遭遇すると、戦闘シーンが開始される。ステップS21で“NO”であれば、つまり戦闘が開始されなければ、図10に示すステップS43に進む。一方、ステップS21で“YES”であれば、つまり戦闘が開始されれば、ステップS23で、戦闘処理を実行し、ステップS25で、プレイヤキャラクタが所有するキャラクタのうち戦闘に参加したキャラクタの経験値を増加させる。
なお、キャラクタデータ領域284に記憶された複数のキャラクタのうちのいくつかがゲーム前にプレイヤによって選択され、図8のゲーム処理では、その選択されたキャラクタが使用される。
また、詳細な説明は省略するが、ステップS23における戦闘処理では、たとえば、プレイヤキャラクタおよび敵キャラクタがそれぞれ所有するキャラクタ同士を戦わせる。この戦闘処理では、プレイヤキャラクタと敵キャラクタとの間で、攻撃ターンが交互に繰り返される。そして、プレイヤキャラクタまたは敵キャラクタが所有するすべてのキャラクタの生命力が無くなる(0になる)と戦闘が終了する。
さらに、ステップS25においては、プレイヤキャラクタが所有するキャラクタのうち戦闘に参加したキャラクタの経験値を増加させているが、これはプレイヤキャラクタが戦闘に勝利したことを前提としてあるからである。ただし、戦闘処理において、プレイヤキャラクタが戦闘に敗北した場合には、ゲーム終了(ゲームオーバ)となり、そのままゲーム処理が終了(リターン)される。
続くステップS27では、或るキャラクタについての経験値が所定値以上かどうかを判断する。つまり、プレイヤキャラクタが所有するキャラクタのうち、経験値が所定値以上のキャラクタが存在するかどうかを判断する。ここで、所定値は、予めプログラマ等の開発者が設定した値であり、ゲームの進行或いはキャラクタのレベルに応じて更新される。
ステップS27で“NO”であれば、つまり或るキャラクタについての経験値が所定値以上でなければ、そのまま図9に示すステップS38に進む。一方、ステップS27で“YES”であれば、つまり或るキャラクタについての経験値が所定値以上であれば、ステップS29で、当該キャラクタについてのレベルをアップするとともに、生命力および戦闘力を増加させる。つまり、WRAM28のキャラクタデータ領域284に記憶される当該キャラクタについてのキャラクタ情報データを更新する。
続くステップS31では、当該キャラクタが提供キャラクタに設定されているかどうかを判断する。ステップS31で“NO”であれば、つまり当該キャラクタが提供キャラクタに設定されていなければ、そのまま図9に示すステップS35に進む。しかし、ステップS31で“YES”であれば、つまり当該キャラクタが提供キャラクタに設定されていれば、ステップS33で、WRAM28の提供キャラクタ情報領域280に記憶される提供キャラクタ情報2のデータを更新して、つまりレベルのデータを更新して、ステップS35に進む。これは、提供キャラクタに設定されているキャラクタのレベルが上がったときに、それに連動して提供キャラクタ情報を変更する必要があるからである。
図9に示すステップS35では、交換条件2が提供キャラクタ情報2に基づくものかどうかを判断する。つまり、提供キャラクタのレベルに関連して要求キャラクタのレベルが決定されるかどうかを判断する。たとえば、この実施例では、図4に示した交換テーブルの番号4および5のように、交換条件2の示すレベルが提供キャラクタ情報2の示すレベルと一致する場合或いはそのレベル以上である場合が該当する。ステップS35で“NO”であれば、つまり、交換条件2が提供キャラクタ情報2に基づくものでなければ、そのままステップS38に進む。しかし、ステップS35で“YES”であれば、つまり交換条件2が提供キャラクタ情報2に基づくものであれば、ステップS37で、WRAM28の交換条件データ記憶領域282に記憶される交換条件2のデータを更新してからステップS38に進む。たとえば、番号4の場合に、提供キャラクタとしてレベル15のクッパが設定されていて、このクッパがレベル16にレベルアップしたときには、交換条件2のデータは「レベル15以上」から「レベル16以上」に変更される。
ステップS38では、戦闘処理以外の仮想ゲームの処理が行われる。たとえば、プレイヤキャラクタや敵キャラクタを仮想ゲーム世界で移動させる処理や、プレイヤキャラクタがゲーム世界に存在するアイテムを入手したときに、プレイヤキャラクタの所持アイテムリストにそのアイテムを追加する処理や、ゲーム世界に存在する村人キャラクタを救出するイベントを発生したりする処理等が行なわれる。このステップS38の処理の後、ステップS39に進む。
ステップS39では、ゲームデータすなわちキャラクタ情報データをセーブするかどうかを判断する。ここでは、プレイヤの操作ないしは所定のイベントが発生したかどうかに応じてセーブするか否かを判断するのである。ステップS39で“NO”であれば、つまりキャラクタ情報データをセーブしない場合には、そのままゲーム処理をリターンする。一方、ステップS39で“YES”であれば、つまりキャラクタ情報データをセーブする場合には、ステップS41で、WRAM28のキャラクタデータ記憶領域284に記憶されるすべてのキャラクタ情報データを読み出し、カートリッジ16に設けられるバックアップRAM44に書き込んで(上書きして)、ゲーム処理をリターンする。
また、図8に示したステップS21で戦闘開始でないと判断した場合には、図10に示すステップS43で、交換イベントが発生したかどうかを判断する。つまり、仮想ゲームの進行状況が図4の交換テーブルの交換開始条件のいずれかを満たすか否かを判断する。ステップS43で“NO”であれば、つまりいずれの交換開始条件も満たしていなければ、そのまま図11に示すステップS71に進む。
一方、ステップS43で“YES”であれば、つまりいずれかの交換開始条件を満たしていれば、ステップS45で、交換テーブルを参照して、当該交換開始条件に対応する提供キャラクタの種類が「プレイヤ任意」であるかどうかを判断する。ステップS45で“YES”であれば、つまり提供キャラクタの種類が「プレイヤ任意」であれば、ステップS47で、プレイヤに所有するキャラクタのうちから提供キャラクタを指定させて、図11に示すステップS59に進む。たとえば、ステップS47では、所有するキャラクタの一覧を表示して提供キャラクタを選択する選択画面をLCD18に表示し、この選択画面を見て、プレイヤは操作スイッチ38を操作して、所望の提供キャラクタを選択(指定)するのである。これ以降においては、説明の便宜上、提供キャラクタに選択されたキャラクタを「キャラクタX」と呼ぶことにする。
一方、ステップS45で“NO”であれば、つまり提供キャラクタの種類が「プレイヤ任意」でなければ、ステップS49で、交換テーブルを参照して、すなわち提供キャラクタの種類で指定されるキャラクタを所有しているかどうかを判断する。ステップS49で“NO”であれば、つまり提供キャラクタの種類で指定されるキャラクタを所有していな
ければ、交換するキャラクタを所有していないと判断して、図9に示したように、そのままゲーム処理を終了する。一方、ステップ49で“YES”であれば、つまり提供キャラクタの種類で指定されるキャラクタを所有していれば、そのキャラクタをキャラクタXとして(すなわち提供キャラクタに指定して)、ステップS51で、交換テーブルを参照して、提供キャラクタのレベルが「不問」であるかどうかを判断する。
ステップS51で“YES”あれば、つまり提供キャラクタのレベルが「不問」であれば、そのままステップS55に進む。一方、ステップS51で“NO”であれば、つまり提供キャラクタのレベルが「不問」でなければ、ステップS53で、キャラクタXが提供キャラクタのレベルを満たすかどうかを判断する。つまり、キャラクタXについてのキャラクタ情報データに含まれるレベルが、提供キャラクタのレベルと同じであるかどうかを判断する。
ステップS53で“NO”であれば、つまりキャラクタXが提供キャラクタのレベルを満たさない場合には、キャラクタXを交換できないと判断して、そのままゲーム処理をリターンする。一方、ステップS53で“YES”であれば、つまりキャラクタXが提供キャラクタのレベルを満たす場合には、ステップS55に進む。
ステップS55では、「キャラクタXを交換しますか?」という確認メッセージをLCD18に表示する。そして、ステップS57では、プレイヤがキャラクタXを交換することを希望したかどうかを判断する。つまり、プレイヤが操作スイッチ38を操作して、キャラクタXを交換することに同意したかどうかを判断する。
ステップS57で“NO”であれば、つまりプレイヤがキャラクタXを交換することを希望しない場合には、そのままゲーム処理を終了する。一方、ステップS57で“YES”であれば、つまりプレイヤがキャラクタXを交換することを希望した場合には、図11に示すステップS59に進む。
このように、キャラクタXを交換するか否かをプレイヤに確認するので、プレイヤが意図しないキャラクタが誤って交換されてしまうのを防止することができる。
次に、ステップS59において、交換テーブルを参照して、当該交換開始条件に対応する要求キャラクタの種類が「プレイヤ任意」であるかどうかを判断する。ステップS59で“NO”であれば、つまり要求キャラクタの種類が「プレイヤ任意」でなければ、そのままステップS63に進む。しかし、ステップS59で“YES”であれば、つまり要求キャラクタの種類が「プレイヤ任意」であれば、ステップS61で、プレイヤに要求キャラクタの種類を指定させて、ステップS63に進む。ステップS61では、たとえば、ゲームに登場する全ての(または主要な)キャラクタの一覧を表示し、その一覧から任意のキャラクタをプレイヤに選択させる選択画面をLCD18に表示し、プレイヤはこの選択画面を見て所望の要求キャラクタを選択(指定)するのである。
ステップS63では、交換テーブルを参照して、当該交換開始条件に対応する要求キャラクタのレベルが「プレイヤ任意」であるかどうかを判断する。ステップS63で“NO”であれば、つまり要求キャラクタのレベルが「プレイヤ任意」でなければ、そのままステップS67に進む。一方、ステップ63で“YES”であれば、つまり要求キャラクタのレベルが「プレイヤ任意」であれば、ステップS65で、プレイヤに要求キャラクタレベルを指定させて、ステップS67に進む。この要求キャラクタのレベルの指定は、上述したステップS47およびS61におけるキャラクタの種類の指定とほぼ同じであるため、ここでは、詳細な説明は省略することにする。
ステップS67では、提供キャラクタ情報1、提供キャラクタ情報2、交換条件1および交換条件2のそれぞれを設定(確定)する。つまり、提供キャラクタ情報1および提供キャラクタ情報2を提供キャラクタ情報領域280に記憶するとともに、交換条件1および交換条件2を交換条件データ領域282に記憶する。そして、ステップS69で、交換可能フラグをオン(1に)して、図9に示したように、ゲーム処理をリターンする。この実施例では、ステップS67においては、提供キャラクタ情報1にキャラクタXの種類が設定され、提供キャラクタ情報2に当該キャラクタXのレベルが設定され、交換条件1に要求キャラクタの種類が設定され、そして、交換条件2に当該要求キャラクタのレベルが設定される。つまり、プレイヤの指定に従って、或いは交換テーブルの定義に従って、提供キャラクタと要求キャラクタの種類やレベルがそれぞれ設定されるのである。
また、図10に示したステップS43で交換開始条件を満たさないと判断された場合には、図11に進み、ステップS71で、交換終了条件を満たすかどうかを判断する。ステップS71で“NO”であれば、つまり交換終了条件を満たしていなければ、そのままゲーム処理をリターンする。一方、ステップS71で“YES”であれば、つまり交換終了条件を満たしていれば、ステップS73で、提供キャラクタ情報および交換条件をクリアし、ステップS75で、交換可能フラグをオフ(0に)して、ゲーム処理をリターンする。
また、図7に示したステップS9のキャラクタ交換処理を開始すると、図12に示すように、ステップ81で、後で詳細に説明する通信相手のサーチおよび接続処理(図18,図19および図20参照)を実行する。続くステップS83では、自機が親機かどうかを判断する。つまり、親機として、他の携帯ゲーム装置との間で接続を確立したかどうかを、親機フラグがオンであるかどうかに応じて判断するのである。なお、親機フラグは、後述する通信相手サーチおよび接続処理において、親機として他の携帯ゲーム装置と接続した場合に、オンになるフラグである。
ステップS83で“NO”であれば、つまり自機が親機でなければ、ステップS85で、自機が子機であるかどうかを判断する。つまり、子機として、他の携帯ゲーム装置との間で接続を確立したかどうかを、子機フラグがオンであるかどうかに応じて判断するのである。なお、子機フラグは、後述する通信相手サーチおよび接続処理において、子機として他の携帯ゲーム装置と接続した場合に、オンになるフラグである。
ステップ85で“YES”であれば、つまり自機が子機であれば、図14に示すステップS117に進む。一方、ステップS85で“NO”であれば、つまり自機が子機でなければ、他の携帯ゲーム装置が接続可能範囲に存在しない、或いは、他の携帯ゲーム装置との接続を失敗したと判断して、図13に示すように、キャラクタ交換処理をリターンする。
また、ステップS83で“YES”であれば、つまり自機が親機であれば、ステップS87で、通信相手(子機)の提供キャラクタ情報1および提供キャラクタ情報2を受信する。続くステップS89では、通信相手の提供キャラクタ情報1が自身の交換条件1を満たすかどうかを判断する。
ステップS89で“NO”であれば、つまり通信相手の提供キャラクタ情報1が自身の交換条件1を満たさない場合には、ステップS91で通信相手に非交換要求を送信し、ステップS93で、通信を切断して、キャラクタ交換処理をリターンする。一方、ステップS89で“YES”であれば、つまり通信相手の提供キャラクタ情報1が自身の交換条件1を満たす場合には、ステップS95で、通信相手の提供キャラクタ情報2が自身の交換条件2を満たすかどうかを判断する。
ステップS95で“NO”であれば、つまり通信相手の提供キャラクタ情報2が自身の交換条件2を満たさない場合には、ステップS91に進む。一方、ステップS95で“YES”であれば、つまり通信相手の提供キャラクタ情報2が自身の交換条件2を満たす場合には、ステップS97で、通信相手に交換要求を送信する。続いて、ステップS99で、通信相手に自身の提供キャラクタ情報1および提供キャラクタ情報2を送信する。
そして、ステップS101で、通信相手から交換応答があったかどうかを判断する。ステップS101で“NO”であれば、つまり通信相手から交換応答がなかった場合には、ステップS103で、通信相手から非交換応答があったかどうかを判断する。ステップS103で“NO”であれば、つまり通信相手から非交換応答がなかった場合には、通信相手から何ら応答がないと判断して、そのままステップS99に戻って、自機の提供キャラクタ情報1および提供キャラクタ情報2を再度送信する。一方、ステップS103で“YES”であれば、つまり通信相手から非交換応答があった場合には、ステップS93に進む。
なお、ステップS101の後、後述のステップS128,S129(図14参照)と同様に、プレイヤに対して交換するかどうかの意思確認を行ってもよい。
また、ステップS101で“YES”であれば、つまり通信相手から交換応答があった場合には、図13に示すステップS105で、キャラクタX(前述のステップS45〜S57の処理で提供キャラクタに選択されたキャラクタ)のデータ(WRAM28に記憶されたキャラクタ情報データ)を送信し、ステップS107で、当該データを、WRAM28およびバックアップRAM44のそれぞれから削除する。次いで、ステップS109では、通信相手から送信されるキャラクタのデータすなわちキャラクタ情報データを受信し、WRAM28のキャラクタデータ領域284に新規に記録(登録)する。なお、バックアップRAM44には、図9のステップS39およびS41に示したように、セーブするときに当該キャラクタ情報データが新規に記録される。このようにして、自機が親機の場合におけるキャラクタの交換が実行される。
その後、ステップS111で通信を切断し、ステップS113交換可能フラグをオフ(0に)し、ステップS115で提供キャラクタ情報1、提供キャラクタ情報2、交換条件1および交換条件2をクリアする。そして、ステップS116で、S107において削除したキャラクタXの画像、属性データ(キャラクタ名やレベル等)およびそのキャラクタXが削除された旨を表示し、S109において新規に記憶したキャラクタの画像、属性データ(キャラクタ名やレベル等)およびそのキャラクタを新しく得た旨を表示して、キャラクタ交換処理をリターンする。
また、上述したように、ステップS85において、自機が子機であると判断した場合には、図14に示すステップS117で、自身の提供キャラクタ情報1および提供キャラクタ情報2を通信相手(親機)に送信する。次に、ステップS119で、通信相手から交換要求を受信したかどうかを判断する。
ステップS119で“NO”であれば、つまり通信相手から交換要求を受信していなければ、ステップS121で、通信相手から非交換要求を受信したかどうかを判断する。ステップS121で“NO”であれば、つまり通信相手から非交換要求を受信していなければ、通信相手から何ら応答がないと判断して、そのままステップS117に戻って、自機の提供キャラクタ情報1および提供キャラクタ情報2を再度送信する。一方、ステップS121で“YES”であれば、つまり通信相手から非交換要求を受信すれば、ステップS131で、通信を切断して、図15に示すように、キャラクタ交換処理をリターンする。
一方、ステップS119で“YES”であれば、つまり通信相手から交換要求を受信すれば、ステップS123で、通信相手の提供キャラクタ情報1および提供キャラクタ情報2を受信し、ステップS125で、通信相手の提供キャラクタ情報1が自身の交換条件1を満たすかどうかを判断する。ステップS125で“NO”ならば、つまり通信相手の提供キャラクタ情報1が自身の交換条件1を満たさない場合には、ステップS130で、通信相手に非交換応答を送信した後、ステップS131で、通信を切断して、キャラクタ交換処理をリターンする。
しかし、ステップS125で“YES”であれば、つまり通信相手の提供キャラクタ情報1が自身の交換条件1を満たす場合には、ステップS127で、通信相手の提供キャラクタ情報2が自身の交換条件2を満たすかどうかを判断する。ステップS127で“NO”であれば、つまり通信相手の提供キャラクタ情報2が自身の交換条件2を満たさない場合には、ステップS130に進む。
一方、ステップS127で“YES”であれば、つまり通信相手の提供キャラクタ情報2が自身の交換条件2を満たす場合には、ステップS128で、交換するかどうかの意思確認をプレイヤに対して行う。具体的には、自己の提供キャラクタ(交換により失うキャラクタ)および通信相手の提供キャラクタ(交換により得るキャラクタ)の情報(種類、レベル等)や通信相手(交換相手)のユーザ名(親機パケット,子機パケットに含まれるUserNameに基づく)をLCD18に表示し、プレイヤに対して、交換するかどうかの意思確認を行う。
そして、ステップS129で、プレイヤが交換することを希望しているかどうかを判断する。このステップS129において、プレイヤが交換を希望していることを判断したとき(操作スイッチ38の入力により交換希望が選択されたことを判断したとき)には、“YES”となり、図15に示すステップS133で、通信相手に交換応答を送信し、ステップS135で、通信相手から送信されるキャラクタのデータすなわちキャラクタ情報データを受信し、WRAM28のキャラクタデータ領域284に新規に記憶(登録)する。なお、セーブするときに、当該キャラクタ情報データがバックアップRAM44に新規に登録されるのは、上述した場合と同様である。ステップS129において、プレイヤが交換を希望していないと判断したときには、“NO”となり、ステップS130に進む。
続くステップS137では、通信相手にキャラクタXのデータすなわちキャラクタXについてのキャラクタ情報データを送信し、ステップS139で、キャラクタXのデータ(キャラクタ情報データ)を、WRAM28およびバックアップRAM44のそれぞれから削除する。このようにして、自機が子機の場合におけるキャラクタの交換が実行される。そして、ステップS141で通信を切断し、ステップS143で交換可能フラグをオフ(0に)し、ステップS145で提供キャラクタ情報1、提供キャラクタ情報2、交換条件1および交換条件2をクリアする。その後、ステップS146で、S135において新規に記憶したキャラクタの画像、属性データ(キャラクタ名やレベル等)およびそのキャラクタを新しく得た旨を表示し、また、S139において削除したキャラクタXの画像、属性データ(キャラクタ名やレベル等)およびそのキャラクタXが削除された旨を表示して、キャラクタ交換処理をリターンする。
なお、上述したように、この実施例では、通信相手の携帯ゲーム装置に提供キャラクタ情報1および提供キャラクタ情報2を送信して、これを受信した通信相手の携帯ゲーム装置が自身の交換条件1および交換条件2を満たすかどうかを判断するようにしてあるが、通信相手の携帯ゲーム装置に交換条件1および交換条件2を送信して、これを受信した通信相手の携帯ゲーム装置が自身の提供キャラクタ情報1および提供キャラクタ情報2を満
たすかどうかを判断するようにしてもよい。
また、通信相手の携帯ゲーム装置に提供キャラクタ情報1,提供キャラクタ情報2,交換条件1,交換条件2のすべてを送信して、これを受信した通信相手の携帯ゲーム装置が、相手の提供キャラクタ情報が自身の交換条件を満たすか、および、自身の提供キャラクタ情報が相手の交換条件を満たすかの両方を判断するようにしてもよい。
次に、図16〜図20を参照して、前述のステップS81(図12)の通信相手のサーチおよび接続処理について説明する。この処理では、携帯ゲーム装置10は、親機または子機として他の携帯ゲーム装置との間で接続を確立するように動作する。親機として接続の確立を試みる場合には、携帯ゲーム装置10は、通信可能範囲64に存在する他の携帯ゲーム装置をサーチすべく、接続可能を示すデータを含むブロードキャストデータをブロードキャスト送信する。このブロードキャストデータを受信した子機としての他の携帯ゲーム装置から接続要求があれば、携帯ゲーム装置10は親機として当該子機との間で接続を確立することができる。
一方、子機として接続の確立を試みる場合には、携帯ゲーム装置10は、親機からのブロードキャストデータの受信を待機する。そして、親機からのブローキャストデータを受信すると、これに応答して、親機に接続要求を送信することにより、親機との間で接続を確立することができる。
このような通信相手のサーチおよび接続処理では、各携帯ゲーム装置10は、親機として動作して子機をサーチする処理と、子機として動作して親機からのサーチを受ける処理を交互に繰り返す。具体的には、所定の期間(図16のTcycle)を1周期として、各周期の一部を親機として動作する期間(図16のTsp)とし、残りを子機として動作する期間(Tsc)とする。ここで、親機として動作中のゲーム装置と子機として動作中のゲーム装置との間で接続可能であり、親機として動作中のゲーム装置と親機として動作中のゲーム装置、および、子機として動作中のゲーム装置と子機として動作中のゲーム装置は、接続不可能である。ゆえに、親機として動作する期間と子機として動作する期間を固定的にした場合、偶然にそれらの期間が一致している2つのゲーム装置において接続を確立することが不可能になる。このようなことを防ぐため、1周期における親機として動作する期間と子機として動作する期間の配分または配置をランダムに変えるようにしてある。配分をランダムに変える方式が図16(A)に示すような「通信相手のサーチおよび接続処理(1)」であり、配置をランダムに変える方式が図16(B)に示すような「通信相手のサーチおよび接続処理(2)」である。
図16(A)を参照して、通信相手のサーチおよび接続処理(1)は、上述したように、TspおよびTscの配分がランダムに決定される。この処理(1サイクル)の期間を固定値のTcycle(たとえば、4秒)とし、Tscの長さは0からTcycleの間のランダム値に決定され、Tspの長さはTcycleの残りの期間(Tcycle−Tsc)に決まる。また、TscおよびTspが、この順番でTcycleに設定される。Tscの長さは毎回ランダムに決定されるため、Tspの長さもランダムに決定される。これにより、通信可能範囲64に存在する他の携帯ゲーム装置との間で接続を確立できない状態を回避するようにしてある。ただし、Tspが短くなり過ぎると、他の携帯ゲーム装置を正確にサーチすることができず、他の携帯ゲーム装置との間で接続を確立できない場合があるため、Tspについての必要最小限の期間を決定しておき、これを確保できない場合には、再度Tscを決定し直すようにしてもよい。
なお、この実施例では、Tsc、Tspの順でTcycleを設定するようにしてあるが、逆の順番で設定するようにしてもよい。
図16(B)を参照して、通信相手のサーチおよび接続処理(2)は、上述したように、TspやTscの配置がランダムに決定される。言い換えると、Tspの長さを固定値として、Tcycle内におけるTspの開始位置をランダムに設定する。具体的に説明すると、図16(B)に示すように、通信相手のサーチおよび接続処理(2)では、Tcycle(この実施例では、固定値であり、4秒に設定される。)には、固定値で決定されるTspおよびこのTspを間に挟むようにランダムに決定されるTsc1およびTsc2が設けられる。つまり、Tcycleには、Tsc1、TspおよびTsc2がこの順で設けられる。また、Tsc1の長さは0から(Tcycle−Tsp)の間でランダムに決定され、Tsc2の長さは、Tcycleからランダムに決定されたTsc1およびTspを減算して決定される。
なお、本実施例では、Tsc、Tspの順でTcycleが設定されるのでTspの開始位置をランダムにしたが、Tsp、Tscの順でTcycleが設定される場合には、Tscの開始時期をランダムに決定すればよい。
図17(A)は親機から子機へブロードキャスト送信される親機パケットの詳細を示す図である。親機パケットは、同期データを格納しておくためのフィールドsyncをその先頭に有し、その同期データフィールドsyncに後続して、ゲーム装置(親機)の識別番号PIDを格納するためのフィールドPIDを有する。そのフィールドPIDに続いて、ユーザ名フィールドUserNameが形成される。このユーザ名フィールドUserNameには、EEPROM54(図1)から読み出されたユーザ名(プレイヤ名)、この実施例では、「太郎」、「一郎」などが登録される。
親機パケットは、ユーザ名フィールドUserNameに続いて、さらに、フィールドEFlag、GameNameおよびPayloadを順次含む。Eflagは、他の携帯ゲーム装置(子機)に対して接続
可能であることを示すデータであり、親機として他の携帯ゲーム装置(子機)をサーチしているときにオンになるフラグであり、他の携帯ゲーム装置(子機)と通信中の場合にはオフになるフラグである。GameNameは、上述したように、親機のゲーム装置に接続されたカートリッジ16のROM42に記憶されるゲームプログラムの識別情報である。
ペイロードフィールドPayloadには、親機から子機への実体的な送信データが格納され
る。具体的には、親機から子機へ送信される接続応答、ゲームデータの交換処理の際に必要になる提供キャラクタ情報1のデータおよび提供キャラクタ情報2のデータを送信したり、通信ゲームにおいて必要となるゲームデータ或いは交換するゲームデータ(キャラクタ情報データ)を送信したりするためのフィールドであり、親機から子機へ送信されるデータを格納するためのフィールドである。
図17(B)は子機から親機に送信される子機パケットの詳細を示す図である。子機パケットは、ゲーム装置(子機)の識別番号を格納する先頭フィールドCIDとそれに後続す
るユーザ名フィールドUserNameとペイロードフィールドPayloadとを含む。ユーザ名フィ
ールドは前述と同様、子機のユーザ名(プレイヤ名)の情報である。このペイロードフィールドPayloadは、子機から親機への実体的な送信データが格納される。具体的には、子
機から親機へ送信される接続要求、子機から親機へ送信される提供キャラクタ情報1および提供キャラクタ情報2のデータ、或いはゲームデータを格納するためのフィールドである。親機パケットと子機パケットをやりとりすることによって、親機と子機はお互いのユーザ名を知ることができる。
各携帯ゲーム装置10は、親機として動作するときには、親機パケットの送信と子機パケットの受信を交互に繰り返し、子機として動作するときには、親機パケットの受信と子
機パケットの送信を交互に繰り返す。通信相手サーチおよび接続処理(1)または(2)においては、Tspの期間において、携帯ゲーム装置10は、親機パケットをブロードキャスト送信した後、他の携帯ゲーム装置10から送信される子機パケット(接続要求)の受信を試みるという処理を繰り返す。また、Tscの期間において、携帯ゲーム装置10は、他のゲーム装置から送信される親機パケットの受信を試みて、受信に成功した場合には、子機パケット(接続要求)を送信するという処理を繰り返す。
また、携帯ゲーム装置10は、電池によって駆動されるため、電池の浪費を防止するために、親機として働く期間においては、所定期間(この実施例では、64ms)毎にブロードキャストデータを送信するようにしてある。つまり、間欠的にブロードキャスト送信が実行されるのである。
なお、上述したキャラクタ交換処理(図12〜図15)においては省略したが、提供キャラクタ情報1,提供キャラクタ情報2およびゲームデータ(キャラクタ情報データ)は、親機パケット或いは子機パケットのペイロードフィールドPayloadに格納されて、親機
と子機との間でやり取りされるのである。
以下、通信相手のサーチおよび接続処理(1)および通信相手のサーチおよび接続処理(2)について、フロー図を用いて、それぞれ、具体的に説明することにする。
図18は通信相手のサーチおよび接続処理(1)を示すフロー図である。この図18を参照して、通信相手のサーチおよび接続処理(1)を開始すると、ステップS151で、Tscを0からTcycleの範囲内でランダムに決定する。図示は省略するが、Tcycleは固定値であるため、Tscが決定されると、Tspも決定される。
続くステップS153〜S163が上述のTscにおいて実行される処理であり、子機として動作して親機をサーチする処理がされる。ステップS165〜S177が上述のTspにおいて実行される処理であり、親機として動作して子機をサーチする処理がされる。
ステップS153では、親機のサーチを開始する。図示は省略するが、このときタイマ回路をスタートする。次にステップS155で、親機の接続可能を示すブローキャストデータ(Eflagがオンのデータ)を受信したかどうかを判断する。
ステップS155で“YES”であれば、つまり親機の接続可能を示すブロードキャストデータ(親機パケット)を受信すれば、ステップS157で、親機に接続要求(子機パケット)を送信し、その後、ステップS159で、親機から接続応答を受信したかどうかを判断する。ステップS159で“NO”であれば、つまり親機から接続応答を受信していなければ、そのままステップS157に戻る。一方、ステップS159で“YES”であれば、つまり親機から接続応答を受信すれば、子機として他の携帯ゲーム装置との間で接続を確立したと判断して、ステップS161で、子機フラグをオンして、通信相手のサーチおよび接続処理(1)をリターンする。
なお、図18においては省略したが、通信相手のサーチおよび接続処理(1)が開始されたとき、子機フラグ(後述する親機フラグも同じ。)はオフ(リセット)される。
一方、ステップS155で“NO”であれば、つまり、親機からのブロードキャストデータを全く受信しないか、または、親機からのブロードキャストデータを受信したがそのブロードキャストデータが接続可能を示していなければ(Eflagがオフ)、ステップS163で、親機サーチ時間すなわち子機として他の携帯ゲーム装置に接続を試みる期間
がTsc秒経過したかどうかを判断する。
ただし、ステップS155においては、親機のブロードキャストデータのGameNameが自己に装着されたカートリッジ16のROM42に記憶されているGameNameと一致するかどうかを判断し、一致しない場合にも、ステップS163に進む。これは、後述する通信相手サーチおよび接続処理(2)におけるステップS185およびS211(図19および図20参照)においても同様である。
ステップS163で“NO”であれば、つまり親機サーチ時間がTsc秒経過していなければ、そのままステップS155に戻る。一方、ステップS163で“YES”であれば、つまり親機サーチ時間がTsc秒経過すれば、ステップS165で、子機のサーチを開始し、つまりタイマ回路をリセットおよびスタートし、ステップS167で、接続可能を示すデータ(Eflagがオンに設定された親機パケット)をブロードキャスト送信する。
続くステップS169では、子機から接続要求(子機パケット)を受信したかどうかを判断する。ステップS169で“YES”であれば、つまり子機から接続要求を受信すれば、ステップS171で、子機に接続応答を送信し、ステップS173で、親機フラグをオンして、通信相手のサーチおよび接続処理(1)をリターンする。つまり、親機として他の携帯ゲーム装置の間で接続が確立されるのである。
一方、ステップS169で“NO”であれば、つまり子機からの接続要求を受信しなければ、ステップS175で、64ms待機し、続くステップS177で、子機サーチ時間すなわち親機として他の通信ゲーム装置との接続を試みる期間がTsp秒経過したかどうかを判断する。ステップS177で“NO”であれば、つまり子機サーチ時間がTsp秒経過していなければ、そのままステップS167に戻る。一方、ステップS177で“YES”であれば、つまり子機サーチ時間がTsp秒経過すれば、Tcycleの期間が経過したと判断して、通信相手のサーチおよび接続処理(1)をリターンする。ステップS175で64ms待機することにより、S167のブロードキャスト送信処理が間欠的に行われることになり、消費電力が抑えることができる。
図19および図20は、通信相手のサーチおよび接続処理(2)を示すフロー図である。図19を参照して、通信相手のサーチおよび接続処理(2)を開始すると、ステップS181で、Tsc1を0から(Tcycle−Tsp)の範囲内でランダムに決定する。上述したように、通信相手のサーチおよび接続処理(2)では、TcycleおよびTspは固定値であるため、Tsc1が決定されると、Tsc2も決定される。
続くステップS183〜S193が上述のTsc1において実行される処理であり、子機として動作して親機をサーチする処理がされる。ステップS195〜S207が上述のTspにおいて実行される処理であり、親機として動作して子機をサーチする処理がされる。さらに、ステップS209〜S219が上述のTsc2において実行される処理であり、子機として動作して親機をサーチする処理がされる。
ステップS183では、親機のサーチを開始する。図示は省略するが、このときタイマ回路をスタートする。次にステップS185で、親機の接続可能を示すブローキャストデータを受信したかどうかを判断する。
ステップS185で“YES”であれば、つまり親機の接続可能を示すブロードキャストデータを受信すれば、ステップS187で、親機に接続要求を送信し、その後、ステップS189で、親機から接続応答を受信したかどうかを判断する。ステップS189で“
NO”であれば、つまり親機から接続応答を受信していなければ、そのままステップS187に戻る。一方、ステップS189で“YES”であれば、つまり親機から接続応答を受信すれば、子機として他の携帯ゲーム装置との間で接続を確立したと判断して、ステップS191で、子機フラグをオンして、図20に示すように、通信相手のサーチおよび接続処理(2)をリターンする。
なお、図19においては省略したが、通信相手のサーチおよび接続処理(2)が開始されたとき、子機フラグおよび親機フラグがオフされるのは、通信相手のサーチおよび接続処理(1)の場合と同じである。
一方、ステップS185で“NO”であれば、つまり、親機からのブロードキャストデータを全く受信しないか、または、親機からのブロードキャストデータを受信したがそのブロードキャストデータが接続可能を示していなければ(Eflagがオフ)、ステップS193で、親機サーチ時間すなわち子機として他の携帯ゲーム装置に接続を試みる期間がTsc1秒経過したかどうかを判断する。ステップS193で“NO”であれば、つまり親機サーチ時間がTsc1秒経過していなければ、そのままステップS185に戻る。一方、ステップS193で“YES”であれば、つまり親機サーチ時間がTsc1秒経過すれば、ステップS195で、子機のサーチを開始し、つまりタイマ回路をリセットおよびスタートし、ステップS197で、接続可能を示すデータをブロードキャスト送信する。
続くステップS199では、子機から接続要求を受信したかどうかを判断する。ステップS199で“YES”であれば、つまり子機から接続要求を受信すれば、ステップS201で、子機に接続応答を送信し、ステップS203で、親機フラグをオンして、通信相手のサーチおよび接続処理(2)をリターンする。つまり、親機として他の携帯ゲーム装置の間で接続が確立されるのである。
一方、ステップS199で“NO”であれば、つまり子機からの接続要求を受信しなければ、ステップS205で、64ms待機し、続くステップS207で、子機サーチ時間すなわち親機として他の通信ゲーム装置との接続を試みる期間がTsp秒経過したかどうかを判断する。ステップS207で“NO”であれば、つまり子機サーチ時間がTsp秒経過していなければ、そのままステップS197に戻る。一方、ステップS207で“YES”であれば、つまり子機サーチ時間がTsp秒経過すれば、図20に示すステップ209で、親機のサーチを開始する。このとき、タイマ回路をリセットおよびスタートする。
次のステップS211では、親機の接続可能を示すブローキャストデータを受信したかどうかを判断する。ステップS211で“YES”であれば、つまり親機の接続可能を示すブロードキャストデータを受信すれば、ステップS213で、親機に接続要求を送信し、その後、ステップS215で、親機から接続応答を受信したかどうかを判断する。ステップS215で“NO”であれば、つまり親機から接続応答を受信していなければ、そのままステップS213に戻る。一方、ステップS215で“YES”であれば、つまり親機から接続応答を受信すれば、子機として他の携帯ゲーム装置との間で接続を確立したと判断して、ステップS217で、子機フラグをオンして、通信相手のサーチおよび接続処理(2)をリターンする。
一方、ステップS211で“NO”であれば、つまり、親機からのブロードキャストデータを全く受信しないか、または、親機からのブロードキャストデータを受信したがそのブロードキャストデータが接続可能を示していなければ(Eflagがオフ)、ステップS219で、親機サーチ時間がTsc2秒経過したかどうかを判断する。ステップS21
9で“NO”であれば、つまり親機サーチ時間がTsc2秒経過していなければ、そのままステップS211に戻る。一方、ステップS219で“YES”であれば、つまり親機サーチ時間がTsc2秒経過すれば、Tcycleの期間が経過したと判断して、通信相手のサーチおよび接続処理(2)をリターンする。
この実施例によれば、無線通信より、交換条件が合致するキャラクタを自動で交換することができるので、知人との間でキャラクタの交換を交渉するなどの煩わしさがない。すなわち、手軽にゲームデータを交換することができる。
また、交換する相手が知人に限定されないため、人が集まる場所に出かければ、キャラクタを交換できる可能性を高くすることができ、交換の楽しさを増大させることができる。つまり、ゲームの興趣性を向上させることができる。
なお、この実施例では、携帯ゲーム装置を用いたゲームシステムについてのみ説明したが、当該携帯ゲーム装置に変えて、ゲーム機能を有する携帯電話機やPDAなどの携帯端末を用いることもできる。
また、この実施例では、一度に設定する交換条件として、1つの提供キャラクタと1つの交換条件を設定した。しかし、一度に複数の提供キャラクタ情報を設定しそれぞれについて交換条件を設定するようにしてもよい。すなわち、自分の所有するゲームデータのうちの複数を提供するゲームデータとして設定し、それぞれについて交換条件を設定するのである。このようにすれば、一度に複数の交換条件が設定されて、他のプレイヤの交換条件と一致する確率が高くなり、ゲームデータの交換が実行される可能性がさらに高くなる。
この場合、たとえば、ゲーム装置Aとゲーム装置Bにおいてそれぞれ複数の提供キャラクタが設定されそれぞれの提供キャラクタについて交換条件が設定されているとする。ゲーム装置Aとゲーム装置Bとの間でキャラクタを交換するときに、ゲーム装置Aの交換条件と、それを満たすゲーム装置Bの提供キャラクタの組をピックアップする。そして、ピックアップされたゲーム装置Aの交換条件(交換条件a)とゲーム装置Bの提供キャラクタ(提供キャラクタb)の組について、交換条件aが設定されているゲーム装置Aの提供キャラクタ(提供キャラクタa)が提供キャラクタbに対して設定されたゲーム装置Bの交換条件(交換条件b)を満たすか否かを判断し、満たす場合に、提供キャラクタaと提供キャラクタbとを交換する。
さらに、この実施例では、提供キャラクタ情報および交換条件として、キャラクタの種類とレベルを指定するようにしたが、これに限らず、キャラクタの種類のみを指定するようにしてもよいし、キャラクタの種類を指定せずにレベルだけを指定するようにしてもよい。また、指定する情報は、キャラクタの種類やレベル以外の情報であってもよい。
さらにまた、この実施例では、親機が所定の情報をブロードキャスト送信して、これを受信した子機との間で接続を確立した後、交換条件の判定のための情報を送受信しているが、親機から送信されるブロードキャストデータに交換条件の判定のための情報(上述の実施例では、提供キャラクタの情報(種類,レベル)や要求キャラクタの情報(種類,レベル))を含めても良い。そして、ブロードキャストデータを受信した子機は、そのブロードキャストデータに含まれる提供キャラクタの情報や要求キャラクタの情報を参照して、その指定情報が自身の提供キャラクタや交換条件を満たす場合のみその親機に対して接続要求をするようにすればよい。
さらにまた、この実施例では、交換テーブルに基づいて、ゲームの進行状況が所定条件
を満たすときに提供ゲームデータと交換条件が設定されるようにしたが、プレイヤがいつでも提供ゲームデータや交換条件を設定できるようにしてもよい。
さらにまた、この実施例では、ゲーム処理(図7のステップS5)を実行中に、同時に並行してキャラクタ交換処理(図7のステップS9)を実行するようにしたが、ゲーム処理を実行していないときに、キャラクタ交換処理のみを実行するようにしてもよい。この場合、交換の意思確認の処理時や交換があったときに交換されたゲームデータについての情報を表示する処理時以外は、LCD18の表示は必要ないため、省電力のためにLCD18への電力供給を切断しておき(LCD電力供給レジスタの値を0に設定してLCD18の表示をオフにしておき)、CPU20がキャラクタ交換処理を行う。そして、交換するかどうかをプレイヤに確認する処理(図14のステップS128,129)を実行するときや、交換したキャラクタについての情報を表示する処理(図13のステップS116や図15のステップS146)を実行するときに、LCD電力供給レジスタの値を1に設定することにより、LCDへの電力供給を行って、LCD18に交換確認のための画面や交換されたキャラクタについての情報を表示するようにしてもよい。このようにすることによって、たとえば、ゲーム装置を鞄やポケット等に携帯し、キャラクタ交換処理を実行させて交換条件が一致する相手を探し続けることができ、LCDの表示はオフになっているため省電力化が図れて都合が良い。このような状況を想定して、LCDの表示をオンする際には、ゲーム装置から音(音楽)を出力したり、バイブレーション機能を設けてゲーム装置を振動させたりして、プレイヤにその旨を報知するようにしてもよい。
さらにまた、提供キャラクタに設定されている場合であっても、そのキャラクタがゲーム処理(図8、図9)に使用するキャラクタとしてを選択されているときには、その提供キャラクタについては、交換の対象としないようにしてもよい。すなわち、ゲーム処理に使用するキャラクタとして、ゲーム開始前にプレイヤによって選択されているキャラクタについては、たとえそのキャラクタが提供キャラクタとして設定されている場合であっても、キャラクタ交換処理(図12〜図15)において、提供キャラクタに設定されていないものとして、処理から除外してもよい。
従来のこの種のゲームシステムの一例が非特許文献1および非特許文献2に開示される。この非特許文献1および非特許文献2に開示されるゲーム装置では、他のゲーム装置と通信することにより、ゲームデータを送受信することができる。