JP5162633B2 - ゲームシステム - Google Patents

Description

この発明はゲームシステムに関し、特にたとえば互いに無線通信可能な複数の携帯型ゲーム装置を備える、ゲームシステムに関する。

従来のこの種のゲームシステムの一例が非特許文献１および非特許文献２に開示される。この非特許文献１および非特許文献２に開示されるゲーム装置では、他のゲーム装置と通信することにより、ゲームデータを送受信することができる。

また、この種のゲームシステムの他の一例が特許文献１に開示される。この特許文献１に開示されるネットワークゲームは、提供するカードデータと希望するカードデータとを設定し、条件が合致した場合にカードデータを送受信するものである。
「ポケットモンスター赤緑青 必勝攻略方法」 株式会社双葉社発行，１９９７年１０月１５日，Ｐ１４−Ｐ１５ 「ポケットモンスタークリスタルバージョン 任天堂公式ガイドブック」 株式会社小学館発行，２００１年２月１０日，Ｐ３４，Ｐ４０ 特開２００３−２３６６１号公報

しかし、前者の場合には、友人・知人等の中に同じゲームソフトを持っている人が少ない等の場合には、送受信する機会や送受信可能なゲームデータが限定されてしまい、送受信の楽しさを十分に満喫できるとは言えなかった。つまり、ゲームの楽しさを低減していた。

また、後者の場合には、ゲームデータを送受信するために、ネットワークに接続する必要があり、いつでも手軽に送受信することができず、しかも、送受信処理のためのサーバを設ける必要があるため、サービス提供者の初期投資や運営費用等の負担が大きかった。

それゆえに、この発明の主たる目的は、手軽にゲームデータを送受信でき、興趣性を向上できる、ゲームシステムを提供することである。

請求項１の発明は、複数の携帯型のゲーム装置を含み、ゲーム装置間でゲームデータを送受信するゲームシステムであって、それぞれのゲーム装置は、ゲームデータを記憶するゲームデータ記憶手段、他のゲーム装置と通信する通信手段、ゲームデータを送受信可能な状態であると判断したとき、通信手段を用いて、不特定の他のゲーム装置を探索する探索手段、および探索手段によって探索された他のゲーム装置と通信することにより、ゲームデータ記憶手段に記憶されたゲームデータを他のゲーム装置に送信し、当該他のゲーム装置から送信されるゲームデータを受信して、当該受信したゲームデータをゲームデータ記憶手段に記憶するゲームデータ送受信手段を備える、ゲームシステムである。

請求項１の発明では、ゲームシステムは、複数の携帯型のゲーム装置（１０：実施例で相当する参照番号である。以下、同様である。）を含み、ゲーム装置（１０）間でゲームデータを送受信する。それぞれのゲーム装置（１０）には、ゲームデータ記憶手段（２８または４４）が設けられ、ゲームデータが記憶される。通信手段（１４）は、他のゲーム装置と通信する。探索手段（２０、Ｓ８１）は、ゲームデータを送受信可能な状態であると判断したとき（Ｓ７で“ＹＥＳ”）、この通信手段（１４）を用いて、不特定の他のゲーム装置（１０）を探索する。ゲームデータ送受信手段（２０，Ｓ１０５，Ｓ１０９，Ｓ１３５，Ｓ１３７）は、探索手段（２０、Ｓ８１）によって探索された他のゲーム装置（１０）と通信することにより、ゲームデータ記憶手段（２８または４４）に記憶されたゲームデータを当該他のゲーム装置（１０）に送信し、当該他のゲーム装置（１０）から送信されるゲームデータを受信して、当該受信したゲームデータをゲームデータ記憶手段（２８または４４）に記憶する。

請求項１の発明によれば、不特定の他のゲーム装置との間でゲームデータを送受信することができるので、手軽にゲームデータを送受信することができる。また、通信相手が知人に限定されず、多数の人とゲームデータの送受信をすることができるため、ゲームデータを送受信する可能性を高くすることができる。さらに、ゲーム装置同士でゲームデータの送受信を行うので、送受信処理のためのサーバを設ける必要がなくゲーム提供者の初期投資や運営費用等の負担を軽減することができる。

請求項２の発明は請求項１に従属し、探索手段は、ゲームデータを送受信可能な状態であると判断したとき、通信手段を用いて、所定範囲に存在する不特定の他のゲーム装置を探索する。

請求項２では、探索手段（２０，Ｓ８１）は、ゲームデータを送受信可能な状態であると判断したとき、通信手段（１４）を用いて、所定範囲（６４）に存在する不特定の他のゲーム装置（１０）を探索する。

請求項２の発明によれば、所定範囲に存在する不特定の他のゲーム装置を探索するので、人が集まる場所に出かければ、ゲームデータを送受信する可能性が高くなり、送受信の楽しさを増大させることができる。

請求項３の発明は請求項２に従属し、ゲーム装置は、ゲームプログラムを記憶するゲームプログラム記憶手段、およびゲームプログラムを実行するゲームプログラム実行手段をさらに備え、ゲームデータ交換手段は、ゲームプログラム実行手段によるゲームプログラムの実行中に、探索手段により所定範囲に存在する不特定の他のゲーム装置を探索し、当該探索された他のゲーム装置と通信することにより、ゲームデータ記憶手段に記憶されたゲームデータを当該他のゲーム装置に送信し、当該他のゲーム装置から送信されるゲームデータを受信して、当該受信したゲームデータをゲームデータ記憶手段に記憶する。
請求項３の発明では、ゲーム装置（１０）は、ゲームプログラムを記憶するゲームプログラム記憶手段（４２）およびゲームプログラムを実行するゲームプログラム実行手段（２２）をさらに備える。ゲームデータ送受信手段（２０，Ｓ１０５，Ｓ１０９，Ｓ１３５，Ｓ１３７）は、ゲームプログラム実行手段（２２）によるゲームプログラムの実行中に、探索手段（２０，Ｓ８１）によって探索された不特定の他のゲーム装置（１０）と通信することにより、ゲームデータ記憶手段（２８または４４）に記憶されたゲームデータを当該他のゲーム装置（１０）に送信し、当該他のゲーム装置（１０）から送信されるゲームデータを受信して、当該受信したゲームデータをゲームデータ記憶手段（２８または４４）に記憶する。
請求項３の発明によれば、ゲーム中であっても、ゲームデータを送受信できるので、ゲームデータの送受信を単に待つような退屈さをプレイヤに与えることはない。また、ゲーム中にゲームデータの送受信の機会を逃すこともない。
請求項４の発明は請求項３に従属し、ゲームプログラムは、ゲーム装置が備える処理手段にゲームデータを生成させ、当該生成されたゲームデータをゲームデータ記憶手段に記憶させる処理を行わせる。
請求項４の発明では、ゲームプログラムは、ゲーム装置（１０）が備える処理手段（２２）にゲームデータを生成させ、当該生成されたゲームデータをゲームデータ記憶手段（２８または４４）に記憶させる処理を行わせる。
請求項４の発明によれば、キャラクタデータのようなゲームデータを手軽に送受信できるので、ゲームの趣向性を向上させることができる。
請求項５の発明は請求項３または４に従属し、ゲームデータ送受信手段は、ゲームプログラム実行手段によるゲームプログラムの実行中に、ゲームデータ記憶手段に記憶されたゲームデータのうち、当該ゲームプログラムの実行に使用するゲームデータとして選択されているゲームデータを送信の対象から除外する。
請求項５の発明では、ゲームデータ送受信手段（２０，Ｓ１０５，Ｓ１０９，Ｓ１３５，Ｓ１３７）は、ゲームプログラム実行手段（２２）によるゲームプログラムの実行中に、ゲームデータ記憶手段（２８または４４）に記憶されたゲームデータのうち、ゲームプログラムの実行に使用するゲームデータとして選択されたゲームデータを送信の対象から除外する。

請求項６の発明は請求項３ないいし５のいずれかに従属し、ゲーム装置は、ゲームプログラム実行手段によって実行されるゲームプログラムに従う仮想ゲームの進行状況が所定条件を満たすことを判定する判定手段をさらに備え、ゲームデータ送受信手段は、判定手段によって所定条件を満たすことが判定されたことに応じて能動化または不能化される。

請求項６の発明では、ゲーム装置（１０）は、判定手段（２０，Ｓ４３）をさらに備える。判定手段（２０，Ｓ４３）は、ゲームプログラム実行手段（２２）によって実行されるゲームプログラムに従う仮想ゲームの進行状況が所定条件を満たすことを判定する。ゲームデータ送受信手段（２０，Ｓ１０５，Ｓ１０９，Ｓ１３５，Ｓ１３７）は、判定手段（２０，Ｓ４３）によって所定条件を満たすことが判定されたことに応じて能動化（Ｓ４３で“ＹＥＳ”のときＳ６９で交換可能フラグがオンとなる）または不能化される。

請求項６の発明によれば、ゲームの進行状況に応じてゲームデータの送受信を行うことができる。

請求項２５の発明は、複数の携帯型のゲーム装置を含み、ゲーム装置間でゲームデータを交換するゲームシステムであって、それぞれのゲーム装置は、ゲームデータを記憶するゲームデータ記憶手段、ゲームデータの交換処理を実行する条件データを設定する条件設定手段、他のゲーム装置と近距離無線によって通信する通信手段、条件設定手段によって設定された条件データに基づく条件が満たされるか否かを判定する判定手段、および判定手段により条件が満たされると判定されたときに限り、通信手段を用いて、他のゲーム装置と通信することにより、ゲームデータ記憶手段に記憶されたゲームデータを当該他のゲーム装置に送信し、当該他のゲーム装置から送信されたゲームデータを受信して、受信した当該ゲームデータをゲームデータ記憶手段に記憶するゲームデータ交換手段を備える、ゲームシステムである。
請求項２５の発明では、ゲームシステムは、複数の携帯型のゲーム装置（１０）を含み、ゲーム装置（１０）間でゲームデータを交換する。それぞれのゲーム装置（１０）には、ゲームデータ記憶手段（２８または４４）が設けられ、ゲームデータが記憶される。条件設定手段（２２，４２，２８６、図４の交換開始条件データ、交換終了条件データ）は、ゲームデータの交換処理を実行する条件データを設定する。通信手段（１４）は、他のゲーム装置と近距離無線によって通信する。判定手段（２０，Ｓ８９，Ｓ９５）は、条件設定手段（２２，４２，２８６）によって設定された条件データに基づく条件が満たされるか否かを判定する。ゲームデータ交換手段（２０，Ｓ１０５，Ｓ１０９，Ｓ１３５，Ｓ１３７）は、判定手段（２０，Ｓ８９，Ｓ９５）により条件が満たされると判定されたときに限り（Ｓ８９で“ＹＥＳ”かつＳ９５で“ＹＥＳ”）、通信手段（１４）を用いて、他のゲーム装置（１０）と通信することにより、ゲームデータ記憶手段（２８，４４）に記憶されたゲームデータを当該他のゲーム装置（１０）に送信し、当該他のゲーム装置（１０）から送信されるゲームデータを受信して、当該受信したゲームデータをゲームデータ記憶手段（２８または４４）に記憶する。
請求項２５の発明によれば、設定された条件を満たす場合にのみゲームデータを他のゲーム装置との間で交換することができるので、手軽にゲームデータを交換することができる。また、交換する相手が知人に限定されず、多数の人とゲームデータの交換をすることができるため、ゲームデータを交換する可能性を高くすることができる。さらに、携帯型のゲーム装置と近距離無線を使用するので、人が集まる場所に出かければ、ゲームデータを交換する可能性が高くなり、交換の楽しさをさらに増大させることができる。さらに、ゲーム装置同士でゲームデータの交換を行うので、交換処理のためのサーバを設ける必要がなくゲーム提供者の初期投資や運営費用等の負担を軽減することができる。
請求項２６の発明は、ゲームデータを記憶するゲームデータ記憶手段、および他のゲーム装置と近距離無線によって通信する通信手段を備えるゲーム装置のゲームデータ交換方法であって、（ａ）ゲームデータの交換処理を実行する条件データを設定し、（ｂ）ステップ（ａ）によって設定された条件データに基づく条件が満たされるか否かを判定し、そして（ｃ）ステップ（ｂ）により条件が満たされると判定されたときに限り、通信手段を用いて、他のゲーム装置と通信することにより、ゲームデータ記憶手段に記憶されたゲームデータを当該他のゲーム装置に送信し、当該他のゲーム装置から送信されたゲームデータを受信して、受信した当該ゲームデータをゲームデータ記憶手段に記憶する、ゲームデータ交換方法である。
請求項２６の発明においても、請求項２５の発明と同様に、手軽にゲームデータを交換することができる。

この発明によれば、通信よって接続されるゲーム装置同士でゲームデータを送受信するので、手軽にゲームデータを送受信することができる。また、送受信する相手が友人・知人等に限定されないため、送受信の楽しさを十分に満喫することができ、したがって、ゲームの興趣性を向上させることができる。

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

図１はこの発明のゲームシステムに用いられる携帯ゲーム装置の一例を示すブロック図である。 図２は図１に示す携帯ゲーム機に設けられるＷＲＡＭのメモリマップを示す図解図である。 図３は図１に示すカートリッジに設けられるバックアップＲＡＭのメモリマップを示す図解図である。 図４は図３に示すＷＲＡＭの交換テーブルデータ記憶領域に記憶される交換テーブルの内容の一例を示す図解図である。 図５は図１実施例に示す携帯ゲーム装置を用いたゲームシステムの概略を説明するための図解図である。 図６はこの発明のゲームシステムにおいて親機と子機と間でゲームデータを交換する場合の流れを説明するための図解図である。 図７は図１に示す携帯ゲーム機のメインフローの一例を示すフロー図である。 図８は図１に示す携帯ゲーム機のゲーム処理の一部を示すフロー図である。 図９は図１に示す携帯ゲーム機のゲーム処理の他の一部を示すフロー図である。 図１０は図１に示す携帯ゲーム機のゲーム処理のその他の一部を示すフロー図である。 図１１は図１に示す携帯ゲーム機のゲーム処理のさらに他の一部を示すフロー図である。 図１２は図１に示す携帯ゲーム機のキャラクタ交換処理の一部を示すフロー図である。 図１３は図１に示す携帯ゲーム機のキャラクタ交換処理の他の一部を示すフロー図である。 図１４は図１に示す携帯ゲーム機のキャラクタ交換処理のその他の一部を示すフロー図である。 図１５は図１に示す携帯ゲーム機のキャラクタ交換処理のさらに他の一部を示すフロー図である。 図１６は図１に示す携帯ゲーム装置が通信相手のサーチおよび接続をする場合において、親機として接続を試みる期間および子機として接続を試みる期間を設定する方法を説明するための図解図である。 図１７は親機が子機に対してブロードキャスト送信する親機パケット、および子機が親機に対して送信する子機パケットを示す図解図である。 図１８は図１に示す携帯ゲーム機の通信相手のサーチおよび接続処理（１）を示すフロー図である。 図１９は図１に示す携帯ゲーム機の通信相手のサーチおよび接続処理（２）の一部を示すフロー図である。 図２０は図１に示す携帯ゲーム機の通信相手のサーチおよび接続処理（２）の他の一部を示すフロー図である。

この発明が適用される無線通信ゲームシステムは、一例として、図１に示すような携帯ゲーム装置１０を利用する。この実施例では、携帯ゲーム装置１０は、たとえばゲームボーイアドバンス（GAMEBOY ADVANCE ：商品名）のような携帯ゲーム機１２と、その携帯ゲーム機１２の通信コネクタ４６に接続された無線通信ユニット１４およびカートリッジコ
ネクタ４０に接続されたゲームカートリッジ１６を含む。つまり、この実施例では、携帯ゲーム装置１０は、携帯ゲーム機１２、無線通信ユニット１４およびカートリッジ１６によって構成される。

図１に示す携帯ゲーム機１２は、プロセサ２０を含み、このプロセサ２０は、ＣＰＵコア２２とそれに関連するブートＲＯＭ２４，ＬＣＤコントローラ２６，ＷＲＡＭ（ワーキングＲＡＭ：以下、同様である。）２８，ＶＲＡＭ３０および周辺回路３２とを含む。ただし、周辺回路３２は、音声（サウンド）回路，ＤＭＡ（Direct Memory Access）回路，タイマ回路，入出力インターフェイス（ＩＯ）などを含む。

携帯ゲーム機１２の前面に設けられたＬＣＤ１８には、プロセサ２０から表示信号、この実施例ではＲＧＢ信号が与えられ、したがって、ＬＣＤ１８ではゲーム画像がカラー表示される。そして、プロセサ２０からは、サウンド回路３４にオーディオ信号が与えられ、そのオーディオ信号によって、スピーカ３６からゲーム音楽や効果音などの音声（音）が出力される。また、携帯ゲーム機１２の前面にＬＣＤ１８を挟んで設けられる十字キーやスタートキー，セレクトキーおよびＡボタン並びにＢボタンがまとめて操作スイッチ３８として示され、この操作スイッチ３８からの操作信号がプロセサ２０に入力される。したがって、プロセサ２０は、操作スイッチ３８を通して与えられたプレイヤの指示に従った処理を実行する。

図示は省略するが、ＬＣＤ１８には電池（１次電池または２次電池）から電力が供給されており、所定のレジスタ（ＬＣＤ電力供給レジスタ）の値を０に設定することによって、ＬＣＤ１８への電力供給が停止される。また、当該レジスタの値を１に設定すると、ＬＣＤ１８への電力供給が開始（再開）される。たとえば、ＬＣＤ電力供給レジスタは、ＷＲＡＭ２８内に設けられ、その値はＣＰＵコア２２によって書き換えられる。つまり、ＣＰＵコア２２が電力供給の開始（オン）／停止（オフ）を制御する。

また、携帯ゲーム機１２はカートリッジコネクタ４０を有し、このカートリッジコネクタ４０には、カートリッジ１６が接続または挿入される。カートリッジ１６にはＲＯＭ４２およびバックアップＲＡＭ４４が内蔵され、ＲＯＭ４２には携帯ゲーム機１２で実行すべきゲーム（仮想ゲーム）のためのゲームプログラムやゲーム画像（キャラクタ画像を含む。）等が予め設定（記憶）されている。また、ＲＯＭ４２には、ＲＯＭ４２に記憶されるゲームプログラムを識別する識別情報(後述する「GameName」)が記憶されている。バックアップＲＡＭ４４は、そのゲームの途中データやゲームの結果データを記憶（セーブ）する。

ＣＰＵコア２２は携帯ゲーム機１２の電源がオンになったときに、ブートＲＯＭ２４に記憶されたブートプログラムを実行し、携帯ゲーム機１２の起動処理を行う。その後、ＣＰＵコア２２はカートリッジ１６のＲＯＭ４２に記憶されたゲームプログラムを実行し、実行中の一時的なデータをＷＲＡＭ２８に記憶しつつゲーム処理を実行する。また、ＣＰＵコア２２がゲームプログラムを実行することによって生成された画像データはＶＲＡＭ３０に記憶され、ＶＲＡＭ３０に記憶された画像データはＬＣＤコントローラ２６によってＬＣＤ１８に出力される。

携帯ゲーム機１２にはさらに通信コネクタ４６が設けられ、この通信コネクタ４６には無線通信ユニット１４のコネクタ４８が接続される。この実施例で用いる携帯ゲーム機１２は、一例としてゲームボーイアドバンス（商品名）であり、その場合、上述のカートリッジコネクタ４０は、ＬＣＤ１８を前面（正面）としたときの上面奥側に設けられる３２ピンコネクタであり、通信コネクタ４６は上面手前側に設けられる６ピンコネクタである。

無線通信ユニット１４は、ベースバンドＩＣ５０を含み、このベースバンドＩＣ５０はＲＯＭ５２を含む。ＲＯＭ５２には、たとえばＯＣＤ（One-Cartridge Download）プログラムやその他のプログラムが内蔵され、ベースバンドＩＣ５０は、それらのプログラムに従って動作する。

なお、ワンカートリッジダウンロードプログラムとは、ＯＣモード（ワンカートリッジモード：親機だけゲームカートリッジが装着されていて、子機はその親機カートリッジからの子機用プログラムのダウンロードを受けて動作するモード）において、子機へプログラムをダウンロードするためのプログラムである。

無線通信ユニット１４にはさらにＥＥＰＲＯＭ５４が設けられ、このＥＥＰＲＯＭ５４には、たとえば、プレイヤ名が固有に設定される。ベースバンド（Base Band ）ＩＣ５０は、携帯ゲーム機１２からコネクタ４６および４８を介して転送されてくるゲームデータや、ＥＥＰＲＯＭ５４のプレイヤ名等を含んだデータを、ＲＦ（Radio Frequency ）−ＩＣ５６に送出し、ＲＦ−ＩＣ５６は、そのデータを変調して、アンテナ５８から電波を送信する。ただし、その電波強度は、非常に微弱で、電波法においてユーザが無免許で利用できる程度の小さい値に設定されている。また、この無線通信ユニット１４には電源回路６０が設けられている。この電源回路６０は典型的には電池であり、無線通信ユニット１４の各コンポーネントに直流電源を供給する。

無線通信ユニットでは、また、他の携帯ゲーム装置から送信された電波をアンテナ５８で受信して、ＲＦ−ＩＣ５６によって復調し、復調信号がベースバンドＩＣ５０に入力される。したがって、ベースバンドＩＣ５０は、復調信号をデコードして、データを復元し、そのデータをコネクタ４８および４６を介して携帯ゲーム機１２すなわちＷＲＡＭ２８に転送する。

図２はＷＲＡＭ２８のメモリマップを示す。この実施例では、ＷＲＡＭ２８は、提供キャラクタ情報領域２８０、交換条件データ領域２８２、キャラクタデータ領域２８４および交換テーブル記憶領域２８６を含む。

提供キャラクタ情報領域２８０には、所有するゲームキャラクタ（以下、単に「キャラクタ」という。）のうち、他のプレイヤまたはユーザ（以下、単に「プレイヤ」という。）に提供することが選択されたキャラクタについての情報（キャラクタの種類，レベル等）が記憶される。ここで、提供キャラクタ情報１は提供キャラクタの種類を示す情報であり、提供キャラクタ情報２は提供キャラクタのレベルを示す情報である。また、提供キャラクタ情報領域２８０に記憶されるデータは、キャラクタデータ領域２８４に記憶されるデータのうち提供キャラクタについてのデータがコピーされて記憶されるものであり、ゲームデータ交換処理において、キャラクタデータ領域２８４を直接参照するようにすれば、提供キャラクタ情報記憶領域を別途設ける必要はない。

所有するキャラクタのうち他のプレイヤに提供するキャラクタは、プレイヤが操作スイッチ３８を用いて入力（指定）することによって選択され、または、ゲームの進行に基づいて自動的に選択される。

交換条件データ領域２８２には、他のプレイヤから提供を受けたいキャラクタに関する情報（キャラクタ種類，レベル等）が交換条件として記憶される。交換条件１にはキャラクタの種類が設定され、交換条件２にはレベルが設定される。この交換条件は、プレイヤによって操作スイッチ３８を用いて入力（指定）され、または、ゲームの進行に基づいて自動的に決定される。

キャラクタデータ領域２８４には、プレイヤが所有するキャラクタ（この実施例では、キャラクタ名「マリオ」、「ルイージ」、「クッパ」、「ピーチ」などのキャラクタ）についての情報（キャラクタ情報）が、キャラクタ毎に記憶される。プレイヤは仮想的なゲーム世界の中で、ゲーム世界中に存在するキャラクタを捕獲したり仲間にしたりしつつ冒険を進める。このように捕獲したり仲間にしたりしたキャラクタに関する情報がキャラクタデータ領域２８４に記憶される。図２からも分かるように、キャラクタ情報は、キャラクタ種類、レベルと当該キャラクタの属性値すなわち生命力（ライフ）および攻撃力（ヒットポイント）とを含む。たとえば、この実施例では、キャラクタデータ領域２８４には、第１キャラクタ情報データ２８４ａ、第２キャラクタ情報データ２８４ｂが記憶される。プレイヤが３つ以上のキャラクタを所有する場合には、第３キャラクタ情報データ，第４キャラクタ情報データ…と記憶される。

キャラクタ情報データ（キャラクタデータ領域２８４のデータ）は、ゲームの進行に従って随時更新される。たとえば、新たなキャラクタを捕獲したときには、当該新たなキャラクタについてのキャラクタ情報が追加される。また、既に捕獲済みのキャラクタのレベルがアップした場合には、当該キャラクタのレベルの値が更新される。

また、このキャラクタ情報データは、プレイヤの指示或いはゲームの進行状況に従ってバックアップＲＡＭ４４に記憶（セーブ）される。したがって、前回の続きからゲームを開始する場合には、バックアップＲＡＭ４４に記憶されたキャラクタ情報データが読み出され、キャラクタデータ領域２８４に書き込まれる（ロードされる）。

図３はバックアップＲＡＭ４４のメモリマップを示す。上述したように、バックアップＲＡＭ４４は、セーブしたゲームデータすなわちキャラクタ情報データを記憶する。この実施例では、たとえば、バックアップＲＡＭ４４には、第１キャラクタ情報データ２８４ａおよび第２キャラクタ情報データ２８４ｂが記憶される。

図２に戻って、交換テーブル記憶領域２８６は、仮想ゲームの進行状況が所定条件を満たすときに、ゲームデータの交換を可能にするためのテーブルを記憶する。このテーブルには、図４に示すように、仮想ゲームの進行状況に応じて、交換開始条件、交換終了条件、提供キャラクタの指定データ、要求キャラクタの指定データが記憶される。このテーブルを参照することにより、仮想ゲームの進行状況に応じて、提供キャラクタと交換条件が設定され、ゲームデータの交換が可能になる。

交換開始条件は、ゲームデータの交換を開始するための条件であり、この条件を満たすと、後述するように、所定のキャラクタの交換可能な状態となる。たとえば、この実施例では、交換開始条件としては、特定アイテムを取得（入手）したこと、特定の敵キャラクタ（プレイヤの操作に拘わらずゲームプログラムに従って行動や動作が制御されるノンプレイヤキャラクタ）を倒したこと、特定のノンプレイヤキャラクタ（敵キャラクタを除くノンプレイヤキャラクタ）を救出したり、或いはそのようなノンプレイヤキャラクタの願いを叶えたりしたこと、特定の月日（いずれか一方でも可）になったこと、および特定の時刻になったことなどが該当する。

交換終了条件は、特定の月日（いずれか一方でも可であり、交換開始条件に対応して決定される。）および特定の時刻などが該当する。なお、交換テーブルにおいて、横棒（バー）を表示してある項目については、特に交換終了条件がないことを示してあるが、当該項目については、キャラクタを交換することにより、交換の処理を終了する。

提供キャラクタの指定データは、提供キャラクタを設定するためのデータであり、提供
キャラクタの種類およびレベルの項目（条件）を含み、種類の項目には、提供するキャラクタの種類（この実施例では、キャラクタの名称）が記述され、レベルの項目には、対応するキャラクタのレベルが記述される。この記述に基づいて、所有するキャラクタのうちこの条件（種類およびレベル）を満たすキャラクタがあるか否かが判断され、この条件を満たすキャラクタがある場合には、そのキャラクタが提供キャラクタとして選択されて、そのキャラクタについての情報（キャラクタ種類，レベル等）が前述の提供キャラクタ情報領域２８０に記憶される。ただし、提供するキャラクタはプレイヤが任意に指定することも可能である。この場合には、所有するキャラクタからプレイヤが任意に指定したキャラクタが提供するキャラクタとして選択されて、そのキャラクタについての情報が前述の提供キャラクタ情報記憶領域２８０に記憶される。

なお、交換テーブルにおいては、種類やレベルについて、プレイヤが任意に指定できる場合には、「プレイヤ任意」と記述してあり、また、特に指定がない場合には、「不問」と記述してある。以下、同様である。

要求キャラクタの指定データは、交換条件を設定するためのデータであり、他のプレイヤに提供を要求するキャラクタの種類およびレベルの項目（条件）を含み、種類の項目には、要求するキャラクタの種類（この実施例では、キャラクタの名称）が記述され、レベルの項目には、対応するキャラクタのレベルが記述される。この記述に基づいて交換条件が決定される。ただし、要求するキャラクタの種類はプレイヤが任意に指定することも可能である。また、レベルについては、特に指定がない場合、提供するキャラクタのレベル以上のレベルを指定する場合やプレイヤが任意に指定できる場合がある。このようにして決定された交換条件が交換条件データ領域２８２に記憶される。

具体的には、交換テーブルを参照して、番号１では、交換開始条件が「特定アイテムを入手」したことであり、交換終了条件は特に定めがない。提供キャラクタの条件としては、種類が「マリオ」であり、そのレベルは「５」である。また、要求キャラクタとしては、種類が「クッパ」であり、そのレベルは「５」である。すなわち、ゲーム世界においてプレイヤキャラクタが特定アイテムを入手したときに、レベル５のマリオを所有していれば、他のプレイヤが所有するレベル５のクッパとの交換が可能になる。この場合、提供キャラクタ情報記憶領域２８０には、提供キャラクタの種類として「マリオ」が設定され、レベルとして「５」が設定される。そして、交換条件データ記憶領域２８２には、要求キャラクタの種類として「クッパ」が設定され、レベルとして「５」が設定される。

また、番号４では、交換開始条件が「特定の月日（４月１０日）」であり、交換終了条件が交換開始条件に相関する「特定の月日（４月１５日）」である。提供キャラクタの条件としては、種類が「クッパ」であり、そのレベルは「１０以上」である。また、要求キャラクタの条件としては、種類が「プレイヤ任意」であり、そのレベルは「提供キャラクタのレベル以上」である。すなわち、本実施例の携帯ゲーム機１２はタイマを備えており、このタイマによってゲーム世界における日付が管理されている。そして、ゲーム世界における日付が４月１０日から４月１５日までの間、レベル１０以上のクッパを所有しているプレイヤは、そのクッパのレベル以上についての任意のキャラクタと交換することが可能になる。たとえばレベル１５のクッパを所有しているプレイヤは、レベル１５以上のルイージとの交換を希望することができる。この場合、提供キャラクタ情報記憶領域２８０には、提供キャラクタの種類として「クッパ」が設定され、レベルとして「１５」が設定される。そして、交換条件データ記憶領域２８２には、要求キャラクタの種類として「ルイージ」が設定され、レベルとして「１５以上」が設定される。

このような交換テーブルは、予めプログラマ等の開発者によって決定され、図示は省略したが、カートリッジ１６のＲＯＭ４２内に記憶され、携帯ゲーム機１２の主電源がオン
された後、一時に或いは必要に応じて、ＷＲＡＭ２８にロードされる。提供キャラクタや交換条件（要求キャラクタ）は交換テーブルを参照して自動的に設定されるが、その一部または全部をプレイヤが任意に設定することができる。

なお、図４に示す交換テーブルは、単なる例示であり、これに限定される必要はない。

たとえば、この実施例のゲームシステムでは、少なくとも２台の図１に示すような携帯ゲーム装置１０を利用し、互いに通信させることにより、各携帯ゲーム装置１０のプレイヤは通信ゲームを楽しむことができる。つまり、図５の点線６４は自機携帯ゲーム装置６２の通信可能範囲を示しており、携帯ゲーム装置６２は、通信可能範囲６４に存在する携帯ゲーム装置との間で通信（無線通信）することができる。この通信可能範囲６４が上述の微弱な電波によって親機と子機との間のデータ通信が可能な範囲であり、この通信可能範囲６４の中に存在する複数の携帯ゲーム装置は、どれでもが、任意に、親機となりまたは子機となることができる。

なお、図５においては、自機携帯ゲーム装置６２の通信可能範囲６４に、ユーザ名「太郎」、「一郎」および「二郎」の携帯ゲーム装置が存在し、自機携帯ゲーム装置６２はユーザ名「二郎」の携帯ゲーム装置と無線通信している様子を示してある。

携帯ゲーム装置６２がその通信可能範囲６４に存在する他の携帯ゲーム装置にエントリして、複数のゲーム装置が通信ゲームを楽しむための携帯ゲーム装置の動作等については、本件出願人が先に出願した特願２００２−３０６８６７号に詳細に開示されており、また、本願の本質的な内容ではないため、ここでは、詳細な説明は省略することにする。

２台以上の携帯ゲーム装置が通信可能に接続されると、上述したように、各携帯ゲーム装置のプレイヤは通信ゲームを楽しむことができる。ただし、各プレイヤは自身の携帯ゲーム装置のみを用いて、つまり、通信せずに、単独でゲームを楽しむことができることは言うまでもない。なお、以下においては、通信または単独でゲームをプレイするモードをゲームモードという。

また、携帯ゲーム装置６２は、その通信可能範囲６４に存在する他の１の携帯ゲーム装置との間で、ゲームデータすなわちキャラクタ情報データを交換することができる。簡単に説明すると、自機の携帯ゲーム装置６２では、主電源がオンであり、かつ、ゲームをプレイしていない（ゲームを開始しておらず、また、ゲームを終了している）状態では、つまりゲームモードでない場合には、キャラクタの交換モードが設定される。

交換モードで交換可能な状態であれば、携帯ゲーム装置６２は、通信可能範囲６４に存在し、かつ、同じく交換可能な状態である他の携帯ゲーム装置を探索（サーチ）する。このとき、携帯ゲーム装置６２は、親機として子機を探す処理と、子機として親機を探す処理を交互に繰り返す。そして、通信可能な他の携帯ゲーム装置を探したときは、無線通信による接続状態（通信状態）の確立を試みる。このサーチおよび接続処理については、後で詳細に説明する（図１６〜図２０参照）。

携帯ゲーム装置６２は、他の携帯ゲーム装置との間で接続状態を確立すると、提供キャラクタの情報（提供キャラクタの種類情報やレベル情報）や交換条件をやり取りし、互いの交換条件が一致（合致）するか否かを判断する。交換条件が一致する場合には、提供キャラクタのデータを交換するものである。

図６は、交換条件が一致する場合における、２つの携帯ゲーム装置（親機と子機）間のやり取りの流れを示す図解図である。この図６を参照して、親機と子機との間で接続状態
が確立されると、子機は自身の提供キャラクタ情報１および提供キャラクタ情報２を親機に送信する。親機は、子機の提供キャラクタ情報１および提供キャラクタ情報２を受信すると、自身の交換条件１および交換条件２とそれぞれ比較し、一致するかどうかを判断する。それぞれが一致する場合、すなわち子機の提供キャラクタ情報１および提供キャラクタ情報２が自身の交換条件１および交換条件２を満たす場合には、親機は交換要求を子機に送信し、さらに、自身の提供キャラクタ情報１および提供キャラクタ情報２を子機に送信する。

子機は、親機の提供キャラクタ情報１および提供キャラクタ情報２を受信すると、自身の交換条件１および交換条件２とそれぞれ比較し、一致するかどうかを判断する。それぞれが一致する場合、すなわち親機の提供キャラクタ情報１および提供キャラクタ情報２が自身の交換条件１および交換条件２を満たす場合には、つまり交換条件を満たす場合には、子機は交換応答を親機に送信する。

すると、親機は、この交換応答を受信して、自身の提供キャラクタ（図６では、説明の便宜上、「キャラクタＡ」と表記する。）についてのキャラクタ情報データを子機に送信する。その後、子機は、自身の提供キャラクタ（図６では、説明の便宜上、「キャラクタＢ」と表記する。）についてのキャラクタ情報データを親機に送信する。このようにして、親機と子機との間で、キャラクタの交換が実行される。

なお、この実施例では、図６に示したように、親機および子機は、それぞれ、通信相手に対して提供キャラクタ情報を送信し、これを受信した携帯ゲーム装置が交換条件を満たすかどうかを判断するようにしているが、一方の携帯ゲーム装置（たとえば、子機）が自身の提供キャラクタ情報および交換条件を、他方の携帯ゲーム装置（たとえば、親機）に送信して、当該親機が、交換条件を満たすかどうかを一度に判断するようにしてもよい。

また、この実施例では、図６に示したように、子機から提供キャラクタ情報を送信し、これを受信した親機が自身の交換条件を満たすかどうか判断して、条件を満たすと判断した場合に、交換要求を送信するようにしてあるのは、無駄な通信を無くすためである。つまり、条件を満たさない場合には、そのままキャラクタの交換が中断されることになる。すなわち、親機からの提供キャラクタ情報の送信がされることがない。

さらに、上述したように、各キャラクタの画像データは、カートリッジ１６内のＲＯＭ４２に記憶されており、また、送受信するデータ量を低減して通信にかかる時間の効率を上げるために、この実施例では、キャラクタを交換する際には、キャラクタの種類を指定する識別番号を交換するようにしてあるが、交換するキャラクタについての画像データ等を交換するようにしてもよい。

図７以降を参照して後述する実施例では、ゲームモードと交換モードを区別せず、ゲームプレイを実行中に交換処理を平行して実行している。すなわち、ゲームプレイを実行している間も交換条件を満たす他のゲーム装置を探すようにし、交換条件を満たす他のゲーム装置を発見したときにゲームデータの交換処理を行うようにする。このようにすることによって、交換条件を満たす他のゲーム装置を探している間にゲームプレイできるので退屈することがない。

具体的には、携帯ゲーム機１２のプロセサ２０ないしはＣＰＵコア２２は、図７に示すフロー図に従って処理する。携帯ゲーム機１２の主電源がオンされると、ＣＰＵコア２２は処理を開始し、ステップＳ１で、交換可能フラグをオフ（０に設定）する。続くステップＳ３では、各キャラクタ（初期状態で所有するキャラクタ）の属性値すなわちレベル、生命力、攻撃力を初期化する。つまり、初期値に設定する。なお、ステップＳ３の処理は
、ゲームを最初にプレイするときのみおこなわれる処理であり、２回目以降にプレイするときには実行されない。

次のステップＳ５では、後で詳細に説明するゲーム処理（図８〜図１１参照）を実行する。そして、ステップＳ７で、交換可能フラグがオン（＝１）であるかどうかを判断する。ステップＳ７で“ＮＯ”であれば、つまり交換可能フラグがオフ（＝０）であれば、キャラクタを交換することができないと判断して、そのままステップＳ５に戻る。

一方、ステップＳ７で“ＹＥＳ”であれば、つまり交換可能フラグがオン（＝１）であれば、キャラクタを交換することができると判断して、ステップＳ９で、後述するキャラクタ交換処理（図１２〜図１５）を実行して、ステップＳ５に戻る。

図８に示すように、ゲーム処理が開始されると、ステップＳ２１では、戦闘開始かどうかを判断する。つまり、戦闘シーンに移行されたかどうかを判断する。図示は省略するが、たとえば、主人公のキャラクタ（プレイヤキャラクタ）が対戦相手のキャラクタ（敵キャラクタ）と遭遇すると、戦闘シーンが開始される。ステップＳ２１で“ＮＯ”であれば、つまり戦闘が開始されなければ、図１０に示すステップＳ４３に進む。一方、ステップＳ２１で“ＹＥＳ”であれば、つまり戦闘が開始されれば、ステップＳ２３で、戦闘処理を実行し、ステップＳ２５で、プレイヤキャラクタが所有するキャラクタのうち戦闘に参加したキャラクタの経験値を増加させる。

なお、キャラクタデータ領域２８４に記憶された複数のキャラクタのうちのいくつかがゲーム前にプレイヤによって選択され、図８のゲーム処理では、その選択されたキャラクタが使用される。

また、詳細な説明は省略するが、ステップＳ２３における戦闘処理では、たとえば、プレイヤキャラクタおよび敵キャラクタがそれぞれ所有するキャラクタ同士を戦わせる。この戦闘処理では、プレイヤキャラクタと敵キャラクタとの間で、攻撃ターンが交互に繰り返される。そして、プレイヤキャラクタまたは敵キャラクタが所有するすべてのキャラクタの生命力が無くなる（０になる）と戦闘が終了する。

さらに、ステップＳ２５においては、プレイヤキャラクタが所有するキャラクタのうち戦闘に参加したキャラクタの経験値を増加させているが、これはプレイヤキャラクタが戦闘に勝利したことを前提としてあるからである。ただし、戦闘処理において、プレイヤキャラクタが戦闘に敗北した場合には、ゲーム終了（ゲームオーバ）となり、そのままゲーム処理が終了（リターン）される。

続くステップＳ２７では、或るキャラクタについての経験値が所定値以上かどうかを判断する。つまり、プレイヤキャラクタが所有するキャラクタのうち、経験値が所定値以上のキャラクタが存在するかどうかを判断する。ここで、所定値は、予めプログラマ等の開発者が設定した値であり、ゲームの進行或いはキャラクタのレベルに応じて更新される。

ステップＳ２７で“ＮＯ”であれば、つまり或るキャラクタについての経験値が所定値以上でなければ、そのまま図９に示すステップＳ３８に進む。一方、ステップＳ２７で“ＹＥＳ”であれば、つまり或るキャラクタについての経験値が所定値以上であれば、ステップＳ２９で、当該キャラクタについてのレベルをアップするとともに、生命力および戦闘力を増加させる。つまり、ＷＲＡＭ２８のキャラクタデータ領域２８４に記憶される当該キャラクタについてのキャラクタ情報データを更新する。

続くステップＳ３１では、当該キャラクタが提供キャラクタに設定されているかどうか
を判断する。ステップＳ３１で“ＮＯ”であれば、つまり当該キャラクタが提供キャラクタに設定されていなければ、そのまま図９に示すステップＳ３５に進む。しかし、ステップＳ３１で“ＹＥＳ”であれば、つまり当該キャラクタが提供キャラクタに設定されていれば、ステップＳ３３で、ＷＲＡＭ２８の提供キャラクタ情報領域２８０に記憶される提供キャラクタ情報２のデータを更新して、つまりレベルのデータを更新して、ステップＳ３５に進む。これは、提供キャラクタに設定されているキャラクタのレベルが上がったときに、それに連動して提供キャラクタ情報を変更する必要があるからである。

図９に示すステップＳ３５では、交換条件２が提供キャラクタ情報２に基づくものかどうかを判断する。つまり、提供キャラクタのレベルに関連して要求キャラクタのレベルが決定されるかどうかを判断する。たとえば、この実施例では、図４に示した交換テーブルの番号４および５のように、交換条件２の示すレベルが提供キャラクタ情報２の示すレベルと一致する場合或いはそのレベル以上である場合が該当する。ステップＳ３５で“ＮＯ”であれば、つまり、交換条件２が提供キャラクタ情報２に基づくものでなければ、そのままステップＳ３８に進む。しかし、ステップＳ３５で“ＹＥＳ”であれば、つまり交換条件２が提供キャラクタ情報２に基づくものであれば、ステップＳ３７で、ＷＲＡＭ２８の交換条件データ記憶領域２８２に記憶される交換条件２のデータを更新してからステップＳ３８に進む。たとえば、番号４の場合に、提供キャラクタとしてレベル１５のクッパが設定されていて、このクッパがレベル１６にレベルアップしたときには、交換条件２のデータは「レベル１５以上」から「レベル１６以上」に変更される。

ステップＳ３８では、戦闘処理以外の仮想ゲームの処理が行われる。たとえば、プレイヤキャラクタや敵キャラクタを仮想ゲーム世界で移動させる処理や、プレイヤキャラクタがゲーム世界に存在するアイテムを入手したときに、プレイヤキャラクタの所持アイテムリストにそのアイテムを追加する処理や、ゲーム世界に存在する村人キャラクタを救出するイベントを発生したりする処理等が行なわれる。このステップＳ３８の処理の後、ステップＳ３９に進む。

ステップＳ３９では、ゲームデータすなわちキャラクタ情報データをセーブするかどうかを判断する。ここでは、プレイヤの操作ないしは所定のイベントが発生したかどうかに応じてセーブするか否かを判断するのである。ステップＳ３９で“ＮＯ”であれば、つまりキャラクタ情報データをセーブしない場合には、そのままゲーム処理をリターンする。一方、ステップＳ３９で“ＹＥＳ”であれば、つまりキャラクタ情報データをセーブする場合には、ステップＳ４１で、ＷＲＡＭ２８のキャラクタデータ記憶領域２８４に記憶されるすべてのキャラクタ情報データを読み出し、カートリッジ１６に設けられるバックアップＲＡＭ４４に書き込んで（上書きして）、ゲーム処理をリターンする。

また、図８に示したステップＳ２１で戦闘開始でないと判断した場合には、図１０に示すステップＳ４３で、交換イベントが発生したかどうかを判断する。つまり、仮想ゲームの進行状況が図４の交換テーブルの交換開始条件のいずれかを満たすか否かを判断する。ステップＳ４３で“ＮＯ”であれば、つまりいずれの交換開始条件も満たしていなければ、そのまま図１１に示すステップＳ７１に進む。

一方、ステップＳ４３で“ＹＥＳ”であれば、つまりいずれかの交換開始条件を満たしていれば、ステップＳ４５で、交換テーブルを参照して、当該交換開始条件に対応する提供キャラクタの種類が「プレイヤ任意」であるかどうかを判断する。ステップＳ４５で“ＹＥＳ”であれば、つまり提供キャラクタの種類が「プレイヤ任意」であれば、ステップＳ４７で、プレイヤに所有するキャラクタのうちから提供キャラクタを指定させて、図１１に示すステップＳ５９に進む。たとえば、ステップＳ４７では、所有するキャラクタの一覧を表示して提供キャラクタを選択する選択画面をＬＣＤ１８に表示し、この選択画面
を見て、プレイヤは操作スイッチ３８を操作して、所望の提供キャラクタを選択（指定）するのである。これ以降においては、説明の便宜上、提供キャラクタに選択されたキャラクタを「キャラクタＸ」と呼ぶことにする。

一方、ステップＳ４５で“ＮＯ”であれば、つまり提供キャラクタの種類が「プレイヤ任意」でなければ、ステップＳ４９で、交換テーブルを参照して、すなわち提供キャラクタの種類で指定されるキャラクタを所有しているかどうかを判断する。ステップＳ４９で“ＮＯ”であれば、つまり提供キャラクタの種類で指定されるキャラクタを所有していなければ、交換するキャラクタを所有していないと判断して、図９に示したように、そのままゲーム処理を終了する。一方、ステップ４９で“ＹＥＳ”であれば、つまり提供キャラクタの種類で指定されるキャラクタを所有していれば、そのキャラクタをキャラクタＸとして（すなわち提供キャラクタに指定して）、ステップＳ５１で、交換テーブルを参照して、提供キャラクタのレベルが「不問」であるかどうかを判断する。

ステップＳ５１で“ＹＥＳ”あれば、つまり提供キャラクタのレベルが「不問」であれば、そのままステップＳ５５に進む。一方、ステップＳ５１で“ＮＯ”であれば、つまり提供キャラクタのレベルが「不問」でなければ、ステップＳ５３で、キャラクタＸが提供キャラクタのレベルを満たすかどうかを判断する。つまり、キャラクタＸについてのキャラクタ情報データに含まれるレベルが、提供キャラクタのレベルと同じであるかどうかを判断する。

ステップＳ５３で“ＮＯ”であれば、つまりキャラクタＸが提供キャラクタのレベルを満たさない場合には、キャラクタＸを交換できないと判断して、そのままゲーム処理をリターンする。一方、ステップＳ５３で“ＹＥＳ”であれば、つまりキャラクタＸが提供キャラクタのレベルを満たす場合には、ステップＳ５５に進む。

ステップＳ５５では、「キャラクタＸを交換しますか？」という確認メッセージをＬＣＤ１８に表示する。そして、ステップＳ５７では、プレイヤがキャラクタＸを交換することを希望したかどうかを判断する。つまり、プレイヤが操作スイッチ３８を操作して、キャラクタＸを交換することに同意したかどうかを判断する。

ステップＳ５７で“ＮＯ”であれば、つまりプレイヤがキャラクタＸを交換することを希望しない場合には、そのままゲーム処理を終了する。一方、ステップＳ５７で“ＹＥＳ”であれば、つまりプレイヤがキャラクタＸを交換することを希望した場合には、図１１に示すステップＳ５９に進む。

このように、キャラクタＸを交換するか否かをプレイヤに確認するので、プレイヤが意図しないキャラクタが誤って交換されてしまうのを防止することができる。

次に、ステップＳ５９において、交換テーブルを参照して、当該交換開始条件に対応する要求キャラクタの種類が「プレイヤ任意」であるかどうかを判断する。ステップＳ５９で“ＮＯ”であれば、つまり要求キャラクタの種類が「プレイヤ任意」でなければ、そのままステップＳ６３に進む。しかし、ステップＳ５９で“ＹＥＳ”であれば、つまり要求キャラクタの種類が「プレイヤ任意」であれば、ステップＳ６１で、プレイヤに要求キャラクタの種類を指定させて、ステップＳ６３に進む。ステップＳ６１では、たとえば、ゲームに登場する全ての（または主要な）キャラクタの一覧を表示し、その一覧から任意のキャラクタをプレイヤに選択させる選択画面をＬＣＤ１８に表示し、プレイヤはこの選択画面を見て所望の要求キャラクタを選択（指定）するのである。

ステップＳ６３では、交換テーブルを参照して、当該交換開始条件に対応する要求キャ
ラクタのレベルが「プレイヤ任意」であるかどうかを判断する。ステップＳ６３で“ＮＯ”であれば、つまり要求キャラクタのレベルが「プレイヤ任意」でなければ、そのままステップＳ６７に進む。一方、ステップ６３で“ＹＥＳ”であれば、つまり要求キャラクタのレベルが「プレイヤ任意」であれば、ステップＳ６５で、プレイヤに要求キャラクタレベルを指定させて、ステップＳ６７に進む。この要求キャラクタのレベルの指定は、上述したステップＳ４７およびＳ６１におけるキャラクタの種類の指定とほぼ同じであるため、ここでは、詳細な説明は省略することにする。

ステップＳ６７では、提供キャラクタ情報１、提供キャラクタ情報２、交換条件１および交換条件２のそれぞれを設定（確定）する。つまり、提供キャラクタ情報１および提供キャラクタ情報２を提供キャラクタ情報領域２８０に記憶するとともに、交換条件１および交換条件２を交換条件データ領域２８２に記憶する。そして、ステップＳ６９で、交換可能フラグをオン（１に）して、図９に示したように、ゲーム処理をリターンする。この実施例では、ステップＳ６７においては、提供キャラクタ情報１にキャラクタＸの種類が設定され、提供キャラクタ情報２に当該キャラクタＸのレベルが設定され、交換条件１に要求キャラクタの種類が設定され、そして、交換条件２に当該要求キャラクタのレベルが設定される。つまり、プレイヤの指定に従って、或いは交換テーブルの定義に従って、提供キャラクタと要求キャラクタの種類やレベルがそれぞれ設定されるのである。

また、図１０に示したステップＳ４３で交換開始条件を満たさないと判断された場合には、図１１に進み、ステップＳ７１で、交換終了条件を満たすかどうかを判断する。ステップＳ７１で“ＮＯ”であれば、つまり交換終了条件を満たしていなければ、そのままゲーム処理をリターンする。一方、ステップＳ７１で“ＹＥＳ”であれば、つまり交換終了条件を満たしていれば、ステップＳ７３で、提供キャラクタ情報および交換条件をクリアし、ステップＳ７５で、交換可能フラグをオフ（０に）して、ゲーム処理をリターンする。

また、図７に示したステップＳ９のキャラクタ交換処理を開始すると、図１２に示すように、ステップ８１で、後で詳細に説明する通信相手のサーチおよび接続処理（図１８，図１９および図２０参照）を実行する。続くステップＳ８３では、自機が親機かどうかを判断する。つまり、親機として、他の携帯ゲーム装置との間で接続を確立したかどうかを、親機フラグがオンであるかどうかに応じて判断するのである。なお、親機フラグは、後述する通信相手サーチおよび接続処理において、親機として他の携帯ゲーム装置と接続した場合に、オンになるフラグである。

ステップＳ８３で“ＮＯ”であれば、つまり自機が親機でなければ、ステップＳ８５で、自機が子機であるかどうかを判断する。つまり、子機として、他の携帯ゲーム装置との間で接続を確立したかどうかを、子機フラグがオンであるかどうかに応じて判断するのである。なお、子機フラグは、後述する通信相手サーチおよび接続処理において、子機として他の携帯ゲーム装置と接続した場合に、オンになるフラグである。

ステップ８５で“ＹＥＳ”であれば、つまり自機が子機であれば、図１４に示すステップＳ１１７に進む。一方、ステップＳ８５で“ＮＯ”であれば、つまり自機が子機でなければ、他の携帯ゲーム装置が接続可能範囲に存在しない、或いは、他の携帯ゲーム装置との接続を失敗したと判断して、図１３に示すように、キャラクタ交換処理をリターンする。

また、ステップＳ８３で“ＹＥＳ”であれば、つまり自機が親機であれば、ステップＳ８７で、通信相手（子機）の提供キャラクタ情報１および提供キャラクタ情報２を受信する。続くステップＳ８９では、通信相手の提供キャラクタ情報１が自身の交換条件１を満
たすかどうかを判断する。

ステップＳ８９で“ＮＯ”であれば、つまり通信相手の提供キャラクタ情報１が自身の交換条件１を満たさない場合には、ステップＳ９１で通信相手に非交換要求を送信し、ステップＳ９３で、通信を切断して、キャラクタ交換処理をリターンする。一方、ステップＳ８９で“ＹＥＳ”であれば、つまり通信相手の提供キャラクタ情報１が自身の交換条件１を満たす場合には、ステップＳ９５で、通信相手の提供キャラクタ情報２が自身の交換条件２を満たすかどうかを判断する。

ステップＳ９５で“ＮＯ”であれば、つまり通信相手の提供キャラクタ情報２が自身の交換条件２を満たさない場合には、ステップＳ９１に進む。一方、ステップＳ９５で“ＹＥＳ”であれば、つまり通信相手の提供キャラクタ情報２が自身の交換条件２を満たす場合には、ステップＳ９７で、通信相手に交換要求を送信する。続いて、ステップＳ９９で、通信相手に自身の提供キャラクタ情報１および提供キャラクタ情報２を送信する。

そして、ステップＳ１０１で、通信相手から交換応答があったかどうかを判断する。ステップＳ１０１で“ＮＯ”であれば、つまり通信相手から交換応答がなかった場合には、ステップＳ１０３で、通信相手から非交換応答があったかどうかを判断する。ステップＳ１０３で“ＮＯ”であれば、つまり通信相手から非交換応答がなかった場合には、通信相手から何ら応答がないと判断して、そのままステップＳ９９に戻って、自機の提供キャラクタ情報１および提供キャラクタ情報２を再度送信する。一方、ステップＳ１０３で“ＹＥＳ”であれば、つまり通信相手から非交換応答があった場合には、ステップＳ９３に進む。

なお、ステップＳ１０１の後、後述のステップＳ１２８，Ｓ１２９（図１４参照）と同様に、プレイヤに対して交換するかどうかの意思確認を行ってもよい。

また、ステップＳ１０１で“ＹＥＳ”であれば、つまり通信相手から交換応答があった場合には、図１３に示すステップＳ１０５で、キャラクタＸ（前述のステップＳ４５〜Ｓ５７の処理で提供キャラクタに選択されたキャラクタ）のデータ（ＷＲＡＭ２８に記憶されたキャラクタ情報データ）を送信し、ステップＳ１０７で、当該データを、ＷＲＡＭ２８およびバックアップＲＡＭ４４のそれぞれから削除する。次いで、ステップＳ１０９では、通信相手から送信されるキャラクタのデータすなわちキャラクタ情報データを受信し、ＷＲＡＭ２８のキャラクタデータ領域２８４に新規に記録（登録）する。なお、バックアップＲＡＭ４４には、図９のステップＳ３９およびＳ４１に示したように、セーブするときに当該キャラクタ情報データが新規に記録される。このようにして、自機が親機の場合におけるキャラクタの交換が実行される。

その後、ステップＳ１１１で通信を切断し、ステップＳ１１３交換可能フラグをオフ（０に）し、ステップＳ１１５で提供キャラクタ情報１、提供キャラクタ情報２、交換条件１および交換条件２をクリアする。そして、ステップＳ１１６で、Ｓ１０７において削除したキャラクタＸの画像、属性データ（キャラクタ名やレベル等）およびそのキャラクタＸが削除された旨を表示し、Ｓ１０９において新規に記憶したキャラクタの画像、属性データ（キャラクタ名やレベル等）およびそのキャラクタを新しく得た旨を表示して、キャラクタ交換処理をリターンする。

また、上述したように、ステップＳ８５において、自機が子機であると判断した場合には、図１４に示すステップＳ１１７で、自身の提供キャラクタ情報１および提供キャラクタ情報２を通信相手（親機）に送信する。次に、ステップＳ１１９で、通信相手から交換要求を受信したかどうかを判断する。

ステップＳ１１９で“ＮＯ”であれば、つまり通信相手から交換要求を受信していなければ、ステップＳ１２１で、通信相手から非交換要求を受信したかどうかを判断する。ステップＳ１２１で“ＮＯ”であれば、つまり通信相手から非交換要求を受信していなければ、通信相手から何ら応答がないと判断して、そのままステップＳ１１７に戻って、自機の提供キャラクタ情報１および提供キャラクタ情報２を再度送信する。一方、ステップＳ１２１で“ＹＥＳ”であれば、つまり通信相手から非交換要求を受信すれば、ステップＳ１３１で、通信を切断して、図１５に示すように、キャラクタ交換処理をリターンする。

一方、ステップＳ１１９で“ＹＥＳ”であれば、つまり通信相手から交換要求を受信すれば、ステップＳ１２３で、通信相手の提供キャラクタ情報１および提供キャラクタ情報２を受信し、ステップＳ１２５で、通信相手の提供キャラクタ情報１が自身の交換条件１を満たすかどうかを判断する。ステップＳ１２５で“ＮＯ”ならば、つまり通信相手の提供キャラクタ情報１が自身の交換条件１を満たさない場合には、ステップＳ１３０で、通信相手に非交換応答を送信した後、ステップＳ１３１で、通信を切断して、キャラクタ交換処理をリターンする。

しかし、ステップＳ１２５で“ＹＥＳ”であれば、つまり通信相手の提供キャラクタ情報１が自身の交換条件１を満たす場合には、ステップＳ１２７で、通信相手の提供キャラクタ情報２が自身の交換条件２を満たすかどうかを判断する。ステップＳ１２７で“ＮＯ”であれば、つまり通信相手の提供キャラクタ情報２が自身の交換条件２を満たさない場合には、ステップＳ１３０に進む。

一方、ステップＳ１２７で“ＹＥＳ”であれば、つまり通信相手の提供キャラクタ情報２が自身の交換条件２を満たす場合には、ステップＳ１２８で、交換するかどうかの意思確認をプレイヤに対して行う。具体的には、自己の提供キャラクタ（交換により失うキャラクタ）および通信相手の提供キャラクタ（交換により得るキャラクタ）の情報（種類、レベル等）や通信相手（交換相手）のユーザ名（親機パケット，子機パケットに含まれるUserNameに基づく）をＬＣＤ１８に表示し、プレイヤに対して、交換するかどうかの意思確認を行う。

そして、ステップＳ１２９で、プレイヤが交換することを希望しているかどうかを判断する。このステップＳ１２９において、プレイヤが交換を希望していることを判断したとき（操作スイッチ３８の入力により交換希望が選択されたことを判断したとき）には、“ＹＥＳ”となり、図１５に示すステップＳ１３３で、通信相手に交換応答を送信し、ステップＳ１３５で、通信相手から送信されるキャラクタのデータすなわちキャラクタ情報データを受信し、ＷＲＡＭ２８のキャラクタデータ領域２８４に新規に記憶（登録）する。なお、セーブするときに、当該キャラクタ情報データがバックアップＲＡＭ４４に新規に登録されるのは、上述した場合と同様である。ステップＳ１２９において、プレイヤが交換を希望していないと判断したときには、“ＮＯ”となり、ステップＳ１３０に進む。

続くステップＳ１３７では、通信相手にキャラクタＸのデータすなわちキャラクタＸについてのキャラクタ情報データを送信し、ステップＳ１３９で、キャラクタＸのデータ（キャラクタ情報データ）を、ＷＲＡＭ２８およびバックアップＲＡＭ４４のそれぞれから削除する。このようにして、自機が子機の場合におけるキャラクタの交換が実行される。そして、ステップＳ１４１で通信を切断し、ステップＳ１４３で交換可能フラグをオフ（０に）し、ステップＳ１４５で提供キャラクタ情報１、提供キャラクタ情報２、交換条件１および交換条件２をクリアする。その後、ステップＳ１４６で、Ｓ１３５において新規に記憶したキャラクタの画像、属性データ（キャラクタ名やレベル等）およびそのキャラクタを新しく得た旨を表示し、また、Ｓ１３９において削除したキャラクタＸの画像、属
性データ（キャラクタ名やレベル等）およびそのキャラクタＸが削除された旨を表示して、キャラクタ交換処理をリターンする。

なお、上述したように、この実施例では、通信相手の携帯ゲーム装置に提供キャラクタ情報１および提供キャラクタ情報２を送信して、これを受信した通信相手の携帯ゲーム装置が自身の交換条件１および交換条件２を満たすかどうかを判断するようにしてあるが、通信相手の携帯ゲーム装置に交換条件１および交換条件２を送信して、これを受信した通信相手の携帯ゲーム装置が自身の提供キャラクタ情報１および提供キャラクタ情報２を満たすかどうかを判断するようにしてもよい。

また、通信相手の携帯ゲーム装置に提供キャラクタ情報１，提供キャラクタ情報２，交換条件１，交換条件２のすべてを送信して、これを受信した通信相手の携帯ゲーム装置が、相手の提供キャラクタ情報が自身の交換条件を満たすか、および、自身の提供キャラクタ情報が相手の交換条件を満たすかの両方を判断するようにしてもよい。

次に、図１６〜図２０を参照して、前述のステップＳ８１（図１２）の通信相手のサーチおよび接続処理について説明する。この処理では、携帯ゲーム装置１０は、親機または子機として他の携帯ゲーム装置との間で接続を確立するように動作する。親機として接続の確立を試みる場合には、携帯ゲーム装置１０は、通信可能範囲６４に存在する他の携帯ゲーム装置をサーチすべく、接続可能を示すデータを含むブロードキャストデータをブロードキャスト送信する。このブロードキャストデータを受信した子機としての他の携帯ゲーム装置から接続要求があれば、携帯ゲーム装置１０は親機として当該子機との間で接続を確立することができる。

一方、子機として接続の確立を試みる場合には、携帯ゲーム装置１０は、親機からのブロードキャストデータの受信を待機する。そして、親機からのブローキャストデータを受信すると、これに応答して、親機に接続要求を送信することにより、親機との間で接続を確立することができる。

このような通信相手のサーチおよび接続処理では、各携帯ゲーム装置１０は、親機として動作して子機をサーチする処理と、子機として動作して親機からのサーチを受ける処理を交互に繰り返す。具体的には、所定の期間（図１６のＴｃｙｃｌｅ）を１周期として、各周期の一部を親機として動作する期間（図１６のＴｓｐ）とし、残りを子機として動作する期間（Ｔｓｃ）とする。ここで、親機として動作中のゲーム装置と子機として動作中のゲーム装置との間で接続可能であり、親機として動作中のゲーム装置と親機として動作中のゲーム装置、および、子機として動作中のゲーム装置と子機として動作中のゲーム装置は、接続不可能である。ゆえに、親機として動作する期間と子機として動作する期間を固定的にした場合、偶然にそれらの期間が一致している２つのゲーム装置において接続を確立することが不可能になる。このようなことを防ぐため、１周期における親機として動作する期間と子機として動作する期間の配分または配置をランダムに変えるようにしてある。配分をランダムに変える方式が図１６（Ａ）に示すような「通信相手のサーチおよび接続処理（１）」であり、配置をランダムに変える方式が図１６（Ｂ）に示すような「通信相手のサーチおよび接続処理（２）」である。

図１６（Ａ）を参照して、通信相手のサーチおよび接続処理（１）は、上述したように、ＴｓｐおよびＴｓｃの配分がランダムに決定される。この処理（１サイクル）の期間を固定値のＴｃｙｃｌｅ（たとえば、４秒）とし、Ｔｓｃの長さは０からＴｃｙｃｌｅの間のランダム値に決定され、Ｔｓｐの長さはＴｃｙｃｌｅの残りの期間（Ｔｃｙｃｌｅ−Ｔｓｃ）に決まる。また、ＴｓｃおよびＴｓｐが、この順番でＴｃｙｃｌｅに設定される。Ｔｓｃの長さは毎回ランダムに決定されるため、Ｔｓｐの長さもランダムに決定される。
これにより、通信可能範囲６４に存在する他の携帯ゲーム装置との間で接続を確立できない状態を回避するようにしてある。ただし、Ｔｓｐが短くなり過ぎると、他の携帯ゲーム装置を正確にサーチすることができず、他の携帯ゲーム装置との間で接続を確立できない場合があるため、Ｔｓｐについての必要最小限の期間を決定しておき、これを確保できない場合には、再度Ｔｓｃを決定し直すようにしてもよい。

なお、この実施例では、Ｔｓｃ、Ｔｓｐの順でＴｃｙｃｌｅを設定するようにしてあるが、逆の順番で設定するようにしてもよい。

図１６（Ｂ）を参照して、通信相手のサーチおよび接続処理（２）は、上述したように、ＴｓｐやＴｓｃの配置がランダムに決定される。言い換えると、Ｔｓｐの長さを固定値として、Ｔｃｙｃｌｅ内におけるＴｓｐの開始位置をランダムに設定する。具体的に説明すると、図１６（Ｂ）に示すように、通信相手のサーチおよび接続処理（２）では、Ｔｃｙｃｌｅ（この実施例では、固定値であり、４秒に設定される。）には、固定値で決定されるＴｓｐおよびこのＴｓｐを間に挟むようにランダムに決定されるＴｓｃ１およびＴｓｃ２が設けられる。つまり、Ｔｃｙｃｌｅには、Ｔｓｃ１、ＴｓｐおよびＴｓｃ２がこの順で設けられる。また、Ｔｓｃ１の長さは０から（Ｔｃｙｃｌｅ−Ｔｓｐ）の間でランダムに決定され、Ｔｓｃ２の長さは、Ｔｃｙｃｌｅからランダムに決定されたＴｓｃ１およびＴｓｐを減算して決定される。

なお、本実施例では、Ｔｓｃ、Ｔｓｐの順でＴｃｙｃｌｅが設定されるのでＴｓｐの開始位置をランダムにしたが、Ｔｓｐ、Ｔｓｃの順でＴｃｙｃｌｅが設定される場合には、Ｔｓｃの開始時期をランダムに決定すればよい。

図１７（Ａ）は親機から子機へブロードキャスト送信される親機パケットの詳細を示す図である。親機パケットは、同期データを格納しておくためのフィールドsyncをその先頭に有し、その同期データフィールドsyncに後続して、ゲーム装置（親機）の識別番号ＰＩＤを格納するためのフィールドPIDを有する。そのフィールドPIDに続いて、ユーザ名フィールドUserNameが形成される。このユーザ名フィールドUserNameには、ＥＥＰＲＯＭ５４（図１）から読み出されたユーザ名（プレイヤ名）、この実施例では、「太郎」、「一郎」などが登録される。

親機パケットは、ユーザ名フィールドUserNameに続いて、さらに、フィールドEFlag、GameNameおよびPayloadを順次含む。Eflagは、他の携帯ゲーム装置（子機）に対して接続
可能であることを示すデータであり、親機として他の携帯ゲーム装置（子機）をサーチしているときにオンになるフラグであり、他の携帯ゲーム装置（子機）と通信中の場合にはオフになるフラグである。GameNameは、上述したように、親機のゲーム装置に接続されたカートリッジ１６のＲＯＭ４２に記憶されるゲームプログラムの識別情報である。

ペイロードフィールドPayloadには、親機から子機への実体的な送信データが格納され
る。具体的には、親機から子機へ送信される接続応答、ゲームデータの交換処理の際に必要になる提供キャラクタ情報１のデータおよび提供キャラクタ情報２のデータを送信したり、通信ゲームにおいて必要となるゲームデータ或いは交換するゲームデータ（キャラクタ情報データ）を送信したりするためのフィールドであり、親機から子機へ送信されるデータを格納するためのフィールドである。

図１７（Ｂ）は子機から親機に送信される子機パケットの詳細を示す図である。子機パケットは、ゲーム装置（子機）の識別番号を格納する先頭フィールドCIDとそれに後続す
るユーザ名フィールドUserNameとペイロードフィールドPayloadとを含む。ユーザ名フィ
ールドは前述と同様、子機のユーザ名（プレイヤ名）の情報である。このペイロードフィ
ールドPayloadは、子機から親機への実体的な送信データが格納される。具体的には、子
機から親機へ送信される接続要求、子機から親機へ送信される提供キャラクタ情報１および提供キャラクタ情報２のデータ、或いはゲームデータを格納するためのフィールドである。親機パケットと子機パケットをやりとりすることによって、親機と子機はお互いのユーザ名を知ることができる。

各携帯ゲーム装置１０は、親機として動作するときには、親機パケットの送信と子機パケットの受信を交互に繰り返し、子機として動作するときには、親機パケットの受信と子機パケットの送信を交互に繰り返す。通信相手サーチおよび接続処理（１）または（２）においては、Ｔｓｐの期間において、携帯ゲーム装置１０は、親機パケットをブロードキャスト送信した後、他の携帯ゲーム装置１０から送信される子機パケット（接続要求）の受信を試みるという処理を繰り返す。また、Ｔｓｃの期間において、携帯ゲーム装置１０は、他のゲーム装置から送信される親機パケットの受信を試みて、受信に成功した場合には、子機パケット（接続要求）を送信するという処理を繰り返す。

また、携帯ゲーム装置１０は、電池によって駆動されるため、電池の浪費を防止するために、親機として働く期間においては、所定期間（この実施例では、６４ｍｓ）毎にブロードキャストデータを送信するようにしてある。つまり、間欠的にブロードキャスト送信が実行されるのである。

なお、上述したキャラクタ交換処理（図１２〜図１５）においては省略したが、提供キャラクタ情報１，提供キャラクタ情報２およびゲームデータ（キャラクタ情報データ）は、親機パケット或いは子機パケットのペイロードフィールドPayloadに格納されて、親機
と子機との間でやり取りされるのである。

以下、通信相手のサーチおよび接続処理（１）および通信相手のサーチおよび接続処理（２）について、フロー図を用いて、それぞれ、具体的に説明することにする。

図１８は通信相手のサーチおよび接続処理（１）を示すフロー図である。この図１８を参照して、通信相手のサーチおよび接続処理（１）を開始すると、ステップＳ１５１で、Ｔｓｃを０からＴｃｙｃｌｅの範囲内でランダムに決定する。図示は省略するが、Ｔｃｙｃｌｅは固定値であるため、Ｔｓｃが決定されると、Ｔｓｐも決定される。

続くステップＳ１５３〜Ｓ１６３が上述のＴｓｃにおいて実行される処理であり、子機として動作して親機をサーチする処理がされる。ステップＳ１６５〜Ｓ１７７が上述のＴｓｐにおいて実行される処理であり、親機として動作して子機をサーチする処理がされる。

ステップＳ１５３では、親機のサーチを開始する。図示は省略するが、このときタイマ回路をスタートする。次にステップＳ１５５で、親機の接続可能を示すブローキャストデータ（Ｅｆｌａｇがオンのデータ）を受信したかどうかを判断する。

ステップＳ１５５で“ＹＥＳ”であれば、つまり親機の接続可能を示すブロードキャストデータ（親機パケット）を受信すれば、ステップＳ１５７で、親機に接続要求（子機パケット）を送信し、その後、ステップＳ１５９で、親機から接続応答を受信したかどうかを判断する。ステップＳ１５９で“ＮＯ”であれば、つまり親機から接続応答を受信していなければ、そのままステップＳ１５７に戻る。一方、ステップＳ１５９で“ＹＥＳ”であれば、つまり親機から接続応答を受信すれば、子機として他の携帯ゲーム装置との間で接続を確立したと判断して、ステップＳ１６１で、子機フラグをオンして、通信相手のサーチおよび接続処理（１）をリターンする。

なお、図１８においては省略したが、通信相手のサーチおよび接続処理（１）が開始されたとき、子機フラグ（後述する親機フラグも同じ。）はオフ（リセット）される。

一方、ステップＳ１５５で“ＮＯ”であれば、つまり、親機からのブロードキャストデータを全く受信しないか、または、親機からのブロードキャストデータを受信したがそのブロードキャストデータが接続可能を示していなければ（Ｅｆｌａｇがオフ）、ステップＳ１６３で、親機サーチ時間すなわち子機として他の携帯ゲーム装置に接続を試みる期間がＴｓｃ秒経過したかどうかを判断する。

ただし、ステップＳ１５５においては、親機のブロードキャストデータのGameNameが自己に装着されたカートリッジ１６のＲＯＭ４２に記憶されているGameNameと一致するかどうかを判断し、一致しない場合にも、ステップＳ１６３に進む。これは、後述する通信相手サーチおよび接続処理（２）におけるステップＳ１８５およびＳ２１１（図１９および図２０参照）においても同様である。

ステップＳ１６３で“ＮＯ”であれば、つまり親機サーチ時間がＴｓｃ秒経過していなければ、そのままステップＳ１５５に戻る。一方、ステップＳ１６３で“ＹＥＳ”であれば、つまり親機サーチ時間がＴｓｃ秒経過すれば、ステップＳ１６５で、子機のサーチを開始し、つまりタイマ回路をリセットおよびスタートし、ステップＳ１６７で、接続可能を示すデータ（Ｅｆｌａｇがオンに設定された親機パケット）をブロードキャスト送信する。

続くステップＳ１６９では、子機から接続要求（子機パケット）を受信したかどうかを判断する。ステップＳ１６９で“ＹＥＳ”であれば、つまり子機から接続要求を受信すれば、ステップＳ１７１で、子機に接続応答を送信し、ステップＳ１７３で、親機フラグをオンして、通信相手のサーチおよび接続処理（１）をリターンする。つまり、親機として他の携帯ゲーム装置の間で接続が確立されるのである。

一方、ステップＳ１６９で“ＮＯ”であれば、つまり子機からの接続要求を受信しなければ、ステップＳ１７５で、６４ｍｓ待機し、続くステップＳ１７７で、子機サーチ時間すなわち親機として他の通信ゲーム装置との接続を試みる期間がＴｓｐ秒経過したかどうかを判断する。ステップＳ１７７で“ＮＯ”であれば、つまり子機サーチ時間がＴｓｐ秒経過していなければ、そのままステップＳ１６７に戻る。一方、ステップＳ１７７で“ＹＥＳ”であれば、つまり子機サーチ時間がＴｓｐ秒経過すれば、Ｔｃｙｃｌｅの期間が経過したと判断して、通信相手のサーチおよび接続処理（１）をリターンする。ステップＳ１７５で６４ｍｓ待機することにより、Ｓ１６７のブロードキャスト送信処理が間欠的に行われることになり、消費電力が抑えることができる。

図１９および図２０は、通信相手のサーチおよび接続処理（２）を示すフロー図である。図１９を参照して、通信相手のサーチおよび接続処理（２）を開始すると、ステップＳ１８１で、Ｔｓｃ１を０から（Ｔｃｙｃｌｅ−Ｔｓｐ）の範囲内でランダムに決定する。上述したように、通信相手のサーチおよび接続処理（２）では、ＴｃｙｃｌｅおよびＴｓｐは固定値であるため、Ｔｓｃ１が決定されると、Ｔｓｃ２も決定される。

続くステップＳ１８３〜Ｓ１９３が上述のＴｓｃ１において実行される処理であり、子機として動作して親機をサーチする処理がされる。ステップＳ１９５〜Ｓ２０７が上述のＴｓｐにおいて実行される処理であり、親機として動作して子機をサーチする処理がされる。さらに、ステップＳ２０９〜Ｓ２１９が上述のＴｓｃ２において実行される処理であり、子機として動作して親機をサーチする処理がされる。

ステップＳ１８３では、親機のサーチを開始する。図示は省略するが、このときタイマ回路をスタートする。次にステップＳ１８５で、親機の接続可能を示すブローキャストデータを受信したかどうかを判断する。

ステップＳ１８５で“ＹＥＳ”であれば、つまり親機の接続可能を示すブロードキャストデータを受信すれば、ステップＳ１８７で、親機に接続要求を送信し、その後、ステップＳ１８９で、親機から接続応答を受信したかどうかを判断する。ステップＳ１８９で“ＮＯ”であれば、つまり親機から接続応答を受信していなければ、そのままステップＳ１８７に戻る。一方、ステップＳ１８９で“ＹＥＳ”であれば、つまり親機から接続応答を受信すれば、子機として他の携帯ゲーム装置との間で接続を確立したと判断して、ステップＳ１９１で、子機フラグをオンして、図２０に示すように、通信相手のサーチおよび接続処理（２）をリターンする。

なお、図１９においては省略したが、通信相手のサーチおよび接続処理（２）が開始されたとき、子機フラグおよび親機フラグがオフされるのは、通信相手のサーチおよび接続処理（１）の場合と同じである。

一方、ステップＳ１８５で“ＮＯ”であれば、つまり、親機からのブロードキャストデータを全く受信しないか、または、親機からのブロードキャストデータを受信したがそのブロードキャストデータが接続可能を示していなければ（Ｅｆｌａｇがオフ）、ステップＳ１９３で、親機サーチ時間すなわち子機として他の携帯ゲーム装置に接続を試みる期間がＴｓｃ１秒経過したかどうかを判断する。ステップＳ１９３で“ＮＯ”であれば、つまり親機サーチ時間がＴｓｃ１秒経過していなければ、そのままステップＳ１８５に戻る。一方、ステップＳ１９３で“ＹＥＳ”であれば、つまり親機サーチ時間がＴｓｃ１秒経過すれば、ステップＳ１９５で、子機のサーチを開始し、つまりタイマ回路をリセットおよびスタートし、ステップＳ１９７で、接続可能を示すデータをブロードキャスト送信する。

続くステップＳ１９９では、子機から接続要求を受信したかどうかを判断する。ステップＳ１９９で“ＹＥＳ”であれば、つまり子機から接続要求を受信すれば、ステップＳ２０１で、子機に接続応答を送信し、ステップＳ２０３で、親機フラグをオンして、通信相手のサーチおよび接続処理（２）をリターンする。つまり、親機として他の携帯ゲーム装置の間で接続が確立されるのである。

一方、ステップＳ１９９で“ＮＯ”であれば、つまり子機からの接続要求を受信しなければ、ステップＳ２０５で、６４ｍｓ待機し、続くステップＳ２０７で、子機サーチ時間すなわち親機として他の通信ゲーム装置との接続を試みる期間がＴｓｐ秒経過したかどうかを判断する。ステップＳ２０７で“ＮＯ”であれば、つまり子機サーチ時間がＴｓｐ秒経過していなければ、そのままステップＳ１９７に戻る。一方、ステップＳ２０７で“ＹＥＳ”であれば、つまり子機サーチ時間がＴｓｐ秒経過すれば、図２０に示すステップ２０９で、親機のサーチを開始する。このとき、タイマ回路をリセットおよびスタートする。

次のステップＳ２１１では、親機の接続可能を示すブローキャストデータを受信したかどうかを判断する。ステップＳ２１１で“ＹＥＳ”であれば、つまり親機の接続可能を示すブロードキャストデータを受信すれば、ステップＳ２１３で、親機に接続要求を送信し、その後、ステップＳ２１５で、親機から接続応答を受信したかどうかを判断する。ステップＳ２１５で“ＮＯ”であれば、つまり親機から接続応答を受信していなければ、そのままステップＳ２１３に戻る。一方、ステップＳ２１５で“ＹＥＳ”であれば、つまり親
機から接続応答を受信すれば、子機として他の携帯ゲーム装置との間で接続を確立したと判断して、ステップＳ２１７で、子機フラグをオンして、通信相手のサーチおよび接続処理（２）をリターンする。

一方、ステップＳ２１１で“ＮＯ”であれば、つまり、親機からのブロードキャストデータを全く受信しないか、または、親機からのブロードキャストデータを受信したがそのブロードキャストデータが接続可能を示していなければ（Ｅｆｌａｇがオフ）、ステップＳ２１９で、親機サーチ時間がＴｓｃ２秒経過したかどうかを判断する。ステップＳ２１９で“ＮＯ”であれば、つまり親機サーチ時間がＴｓｃ２秒経過していなければ、そのままステップＳ２１１に戻る。一方、ステップＳ２１９で“ＹＥＳ”であれば、つまり親機サーチ時間がＴｓｃ２秒経過すれば、Ｔｃｙｃｌｅの期間が経過したと判断して、通信相手のサーチおよび接続処理（２）をリターンする。

この実施例によれば、無線通信より、交換条件が合致するキャラクタを自動で交換することができるので、知人との間でキャラクタの交換を交渉するなどの煩わしさがない。すなわち、手軽にゲームデータを交換することができる。

また、交換する相手が知人に限定されないため、人が集まる場所に出かければ、キャラクタを交換できる可能性を高くすることができ、交換の楽しさを増大させることができる。つまり、ゲームの興趣性を向上させることができる。

なお、この実施例では、携帯ゲーム装置を用いたゲームシステムについてのみ説明したが、当該携帯ゲーム装置に変えて、ゲーム機能を有する携帯電話機やＰＤＡなどの携帯端末を用いることもできる。

また、この実施例では、一度に設定する交換条件として、１つの提供キャラクタと１つの交換条件を設定した。しかし、一度に複数の提供キャラクタ情報を設定しそれぞれについて交換条件を設定するようにしてもよい。すなわち、自分の所有するゲームデータのうちの複数を提供するゲームデータとして設定し、それぞれについて交換条件を設定するのである。このようにすれば、一度に複数の交換条件が設定されて、他のプレイヤの交換条件と一致する確率が高くなり、ゲームデータの交換が実行される可能性がさらに高くなる。

この場合、たとえば、ゲーム装置Ａとゲーム装置Ｂにおいてそれぞれ複数の提供キャラクタが設定されそれぞれの提供キャラクタについて交換条件が設定されているとする。ゲーム装置Ａとゲーム装置Ｂとの間でキャラクタを交換するときに、ゲーム装置Ａの交換条件と、それを満たすゲーム装置Ｂの提供キャラクタの組をピックアップする。そして、ピックアップされたゲーム装置Ａの交換条件（交換条件ａ）とゲーム装置Ｂの提供キャラクタ（提供キャラクタｂ）の組について、交換条件ａが設定されているゲーム装置Ａの提供キャラクタ（提供キャラクタａ）が提供キャラクタｂに対して設定されたゲーム装置Ｂの交換条件（交換条件ｂ）を満たすか否かを判断し、満たす場合に、提供キャラクタａと提供キャラクタｂとを交換する。

さらに、この実施例では、提供キャラクタ情報および交換条件として、キャラクタの種類とレベルを指定するようにしたが、これに限らず、キャラクタの種類のみを指定するようにしてもよいし、キャラクタの種類を指定せずにレベルだけを指定するようにしてもよい。また、指定する情報は、キャラクタの種類やレベル以外の情報であってもよい。

さらにまた、この実施例では、親機が所定の情報をブロードキャスト送信して、これを受信した子機との間で接続を確立した後、交換条件の判定のための情報を送受信している
が、親機から送信されるブロードキャストデータに交換条件の判定のための情報（上述の実施例では、提供キャラクタの情報（種類，レベル）や要求キャラクタの情報（種類，レベル））を含めても良い。そして、ブロードキャストデータを受信した子機は、そのブロードキャストデータに含まれる提供キャラクタの情報や要求キャラクタの情報を参照して、その指定情報が自身の提供キャラクタや交換条件を満たす場合のみその親機に対して接続要求をするようにすればよい。

さらにまた、この実施例では、交換テーブルに基づいて、ゲームの進行状況が所定条件を満たすときに提供ゲームデータと交換条件が設定されるようにしたが、プレイヤがいつでも提供ゲームデータや交換条件を設定できるようにしてもよい。

さらにまた、この実施例では、ゲーム処理（図７のステップＳ５）を実行中に、同時に並行してキャラクタ交換処理（図７のステップＳ９）を実行するようにしたが、ゲーム処理を実行していないときに、キャラクタ交換処理のみを実行するようにしてもよい。この場合、交換の意思確認の処理時や交換があったときに交換されたゲームデータについての情報を表示する処理時以外は、ＬＣＤ１８の表示は必要ないため、省電力のためにＬＣＤ１８への電力供給を切断しておき（ＬＣＤ電力供給レジスタの値を０に設定してＬＣＤ１８の表示をオフにしておき）、ＣＰＵ２０がキャラクタ交換処理を行う。そして、交換するかどうかをプレイヤに確認する処理（図１４のステップＳ１２８，１２９）を実行するときや、交換したキャラクタについての情報を表示する処理（図１３のステップＳ１１６や図１５のステップＳ１４６）を実行するときに、ＬＣＤ電力供給レジスタの値を１に設定することにより、ＬＣＤへの電力供給を行って、ＬＣＤ１８に交換確認のための画面や交換されたキャラクタについての情報を表示するようにしてもよい。このようにすることによって、たとえば、ゲーム装置を鞄やポケット等に携帯し、キャラクタ交換処理を実行させて交換条件が一致する相手を探し続けることができ、ＬＣＤの表示はオフになっているため省電力化が図れて都合が良い。このような状況を想定して、ＬＣＤの表示をオンする際には、ゲーム装置から音（音楽）を出力したり、バイブレーション機能を設けてゲーム装置を振動させたりして、プレイヤにその旨を報知するようにしてもよい。

さらにまた、提供キャラクタに設定されている場合であっても、そのキャラクタがゲーム処理（図８、図９）に使用するキャラクタとしてを選択されているときには、その提供キャラクタについては、交換の対象としないようにしてもよい。すなわち、ゲーム処理に使用するキャラクタとして、ゲーム開始前にプレイヤによって選択されているキャラクタについては、たとえそのキャラクタが提供キャラクタとして設定されている場合であっても、キャラクタ交換処理（図１２〜図１５）において、提供キャラクタに設定されていないものとして、処理から除外してもよい。

１０ …携帯ゲーム装置
１２ …携帯ゲーム機
１４ …無線通信ユニット
１６ …カートリッジ
１８ …ＬＣＤ
２０ …プロセサ
２２ …ＣＰＵコア
２４ …ブートＲＯＭ
２８ …ＷＲＡＭ
３８ …操作スイッチ
４２ …ＲＯＭ
４４ …バックアップＲＡＭ

Claims (6)

1. 複数の携帯型のゲーム装置を含み、ゲーム装置間でゲームデータを送受信するゲームシステムであって、
   それぞれの前記ゲーム装置は、
   ゲームデータを記憶するゲームデータ記憶手段、
   他のゲーム装置と通信する通信手段、
   前記ゲームデータを送受信可能な状態であると判断したとき、前記通信手段を用いて、不特定の他のゲーム装置を探索する探索手段、および
   前記探索手段によって探索された他のゲーム装置と通信することにより、前記ゲームデータ記憶手段に記憶されたゲームデータを前記他のゲーム装置に送信し、当該他のゲーム装置から送信されるゲームデータを受信して、当該受信したゲームデータを前記ゲームデータ記憶手段に記憶するゲームデータ送受信手段を備える、ゲームシステム。
2. 前記探索手段は、前記ゲームデータを送受信可能な状態であると判断したとき、前記通信手段を用いて、所定範囲に存在する不特定の他のゲーム装置を探索する、請求項１記載のゲームシステム。
3. 前記ゲーム装置は、ゲームプログラムを記憶するゲームプログラム記憶手段、および前記ゲームプログラムを実行するゲームプログラム実行手段をさらに備え、
   前記ゲームデータ送受信手段は、前記ゲームプログラム実行手段によるゲームプログラムの実行中に、前記探索手段により所定範囲に存在する不特定の他のゲーム装置を探索し、当該探索された他のゲーム装置と通信することにより、前記ゲームデータ記憶手段に記憶されたゲームデータを当該他のゲーム装置に送信し、当該他のゲーム装置から送信されるゲームデータを受信して、当該受信したゲームデータを前記ゲームデータ記憶手段に記憶する、請求項２記載のゲームシステム。
4. 前記ゲームプログラムは、前記ゲーム装置が備える処理手段にゲームデータを生成させ、当該生成されたゲームデータを前記ゲームデータ記憶手段に記憶させる処理を行わせる、請求項３記載のゲームシステム。
5. 前記ゲームデータ送受信手段は、前記ゲームプログラム実行手段による前記ゲームプログラムの実行中に、前記ゲームデータ記憶手段に記憶されたゲームデータのうち、当該ゲームプログラムの実行に使用するゲームデータとして選択されているゲームデータを送信の対象から除外する、請求項３または４記載のゲームシステム。
6. 前記ゲーム装置は、前記ゲームプログラム実行手段によって実行される前記ゲームプログラムに従う仮想ゲームの進行状況が所定条件を満たすことを判定する判定手段をさらに備え、
   前記ゲームデータ送受信手段は、前記判定手段によって前記所定条件を満たすことが判定されたことに応じて能動化または不能化される、請求項３ないし５のいずれかに記載のゲームシステム。

Images