JP2006305091A - ゲームシステム、ゲーム装置およびゲームプログラム - Google Patents

Abstract

【構成】 ゲームシステム１００は複数のゲーム装置１０を含み、各ゲーム装置１０は通信可能に接続される。通信ゲームにおける仮想空間は複数のシーンで構成されており、各シーンに参加しているゲーム装置１０の中で、当該シーンの親機（シーンホスト）と子機（シーンビジター）とが決定される。ゲーム中では、シーンホストは、通信ゲームに参加しているすべてのゲーム装置１０で共有すべきシーン共有データおよび自機が存在するシーンに参加しているゲーム装置１０だけで共有すべきシーン固有データの更新処理を実行する。
【効果】 各シーンの親機が処理を分担するので、１台のゲーム装置に処理が集中することがなく、通信効率の低下を防止することができる。
【選択図】 図１

Description

この発明はゲームシステム、ゲーム装置およびゲームプログラムに関し、特にたとえば、通信機能を備えた複数のゲーム装置で構成され、各々のプレイヤが自身のゲーム装置を用いて仮想ゲームへ参加する、ゲームシステム、ゲーム装置およびゲームプログラムに関する。

従来、複数のゲーム装置間で通信ゲームを行う場合、各ゲーム装置間での通信結果を一致させるために、各ゲーム装置のプレイヤが操作した情報を１台のゲーム装置（親機）に集め、整合を取った上で他のすべてのゲーム装置（子機）に送信するという方法が採られている。ここで、親機と複数の子機との間で通信を行う通信ゲームにおいて、親機となるゲーム装置を所定の条件に応じて変えるものが知られている。この一例が特許文献１に開示される。特許文献１によれば、複数のゲーム装置間で通信ゲームを行う場合に、処理サイクルが所定の回数実行される度に、親機となるゲーム装置を順番に変更させるようにしてある。これにより、ゲームの進行において各ゲーム装置のプレイヤが受ける有利不利の偏りを無くし、公平にゲームをプレイすることができる。
特開２００４−１７４０９１号

この特許文献１に開示される背景技術では、ゲームの有利不利の偏りを無くすことができるため、対戦ゲーム等において効果的であるが、親機は常に１台しか存在しないため、通信ゲームに参加する子機の数が増加すると、親機の処理負担が増大し、通信効率の低下を招いてしまうという問題がある。

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

この発明の他の目的は、通信効率の低下を防止できる、ゲームシステム、ゲーム装置およびゲームプログラムを提供することである。

請求項１の発明は、通信機能を備えた複数のゲーム装置によって構成され、複数のシーンを含む仮想ゲーム空間内のいずれかのシーンに当該複数のゲーム装置の各々がプレイヤとして参加してプレイするゲームシステムである。各々のゲーム装置は、共有データゲーム記憶手段、固有ゲームデータ記憶手段、親機設定手段、子機設定手段、親機処理手段、および子機処理手段を含む。共有ゲームデータ記憶手段は、すべてのゲーム装置で共有すべき共有ゲームデータを記憶する。固有ゲームデータ記憶手段は、自機が参加しているシーンのみで共有すべきシーン固有の固有ゲームデータを記憶する。親機設定手段は、参加するシーンに他のゲーム装置が参加していないとき、自機を当該シーンの親機として設定する。子機設定手段は、参加するシーンに他のゲーム装置が参加しているとき、自機を当該シーンの子機として設定する。親機処理手段は、親機設定手段によって自機がシーンの親機として設定されたとき、少なくとも、共有ゲームデータの更新を自機以外のすべてのゲーム装置に指示し、または、固有ゲームデータの更新を当該シーンに参加しているすべての子機に指示する。そして、子機処理手段は、子機設定手段によって自機がシーンの子機として設定されたとき、少なくとも、親機からの指示に従って固有ゲームデータを更新する。

請求項１の発明では、ゲームシステム（１００：実施例における参照符号。以下、同じ。）は、通信機能を備える複数のゲーム装置（１０）によって構成される。複数のゲーム装置（１０）の各々は、複数のシーンを含む仮想ゲーム空間（２００）内のいずれかのシーンにプレイヤとして参加して通信ゲームをプレイする。各々のゲーム装置（１０）は、共有ゲームデータ記憶手段（４８，７６０）、固有ゲームデータ記憶手段（４８，７６２）、親機設定手段（４２）、子機設定手段（４２）、親機処理手段（４２，Ｓ５，Ｓ３９，Ｓ７３，Ｓ９３）および子機処理手段（４２，Ｓ３５，Ｓ６９，Ｓ８９）を含む。共有ゲームデータ記憶手段（４８，７６０）は、システム（１００）を構成し、通信ゲームをプレイする、すべてのゲーム装置（１０）で共有すべき共有ゲームデータ（７６０ａ，７６０ｂ，…）を記憶する。固有ゲームデータ記憶手段（４８，７６２）は、自機が参加しているシーンのみで共有すべきシーン固有の固有ゲームデータ（７６２ａ）を記憶する。親機設定手段（４２）は、参加（他のシーンに移動する場合も含む。以下、同じ。）するシーンに他のゲーム装置（１０）が参加していないとき、自機を当該シーンの親機（実施例では、「シーンホスト」という。）として設定する。子機設定手段（４２）は、参加するシーンに他のゲーム装置（１０）が参加しているとき、自機を当該シーンの子機（実施例では、「シーンビジター」という。）として設定する。親機処理手段（４２，Ｓ５，Ｓ３９，Ｓ７３，Ｓ９３）は、自機がシーンホストとして設定されたとき、少なくとも、共有ゲームデータの更新を自機以外のすべてのゲーム装置（１０）に指示し、または、固有ゲームデータの更新を当該シーンに参加するすべての子機に指示する。したがって、シーン毎に設定されたシーンホストが通信ゲームにおける処理を分担する。一方、子機処理手段（４２，Ｓ３５，Ｓ６９，Ｓ８９）は、自機がシーンビジターとして設定されたとき、少なくとも、親機からの指示に従って固有ゲームデータを更新する。

請求項１の発明によれば、シーン毎に設定した親機が処理を分担するので、１台のゲーム装置に処理が集中することがない。このため、通信ゲームに参加するゲーム装置の増加により、通信効率が低下するのを防止することができる。

請求項２の発明は、請求項１に従属し、子機処理手段は、共有ゲームデータの更新を自機が参加するシーンの親機に要求する共有ゲームデータ更新要求手段を含み、親機処理手段は、子機からの共有ゲームデータの更新要求を受けて、共有ゲームデータの更新を自機以外のすべてのゲーム装置に指示する。

請求項２の発明では、シーンビジターでは、共有ゲームデータ更新要求手段（４２，Ｓ１４７）が、共有ゲームデータ（７６０ａ，７６０ｂ，…）の更新を自機が参加するシーンのシーンホストに要求する。シーンホストは、子機からの共有ゲームデータの更新要求を受けて（Ｓ１１７）、共有ゲームデータ（７６０ａ，７６０ｂ，…）の更新を自機以外のすべてのゲーム装置（１０）に指示する（Ｓ１２１）。

請求項２の発明によれば、子機は同じシーンに参加する親機に共有ゲームデータの更新を要求し、これに応じて親機がすべてのゲーム装置に共有ゲームデータの更新を指示するので、ゲームデータの更新指示をする処理が各親機で分担される。つまり、処理が分散されるので、通信効率の低下を防止することができる。

請求項３の発明は請求項１または２に従属し、ゲーム装置は、他のゲーム装置から共有ゲームデータの更新指示を受信する更新指示受信手段、および更新指示手段によって共有ゲームデータの更新指示を受信したことに応じて共有ゲームデータを更新する共有ゲームデータ更新手段をさらに含む。

請求項３の発明では、ゲーム装置（１０）は、更新指示受信手段（４２，Ｓ１２９，Ｓ１５１，Ｓ１５９）および共有ゲームデータ更新手段（４２，Ｓ１３１，Ｓ１５３，Ｓ１６１）をさらに含む。更新指示手段（４２，Ｓ１２９，Ｓ１５１，Ｓ１５９）は、同じシーンまたは他のシーンに存在するシーンホストからの共有データ（７６０ａ，７６０ｂ，…）の更新指示を受信する。共有ゲームデータ更新手段（４２，Ｓ１３１，Ｓ１５３，Ｓ１６１）は、その更新指示を受信したことに応じて（Ｓ１２９，Ｓ１５１，Ｓ１５９で“ＹＥＳ”）、共有ゲームデータ（７６０ａ，７６０ｂ，…）を更新する。

請求項３の発明によれば、同じシーンまたは他のシーンの親機からの指示に応じて、各ゲーム装置は、共有ゲームデータを更新することができる。

請求項４の発明は請求項１ないし３のいずれかに従属し、ゲーム装置は、他のシーンに移動するとき、自機が親機である場合に現在のシーンに子機が存在するか否かを判断する子機有無判断手段、および子機有無判断手段によって現在のシーンに子機が存在すると判断されたとき所定のルールに従って選択した１の子機に親機になることを要求する親機設定要求手段をさらに含む。

請求項４の発明では、ゲーム装置（１０）は、子機有無判断手段（４２，Ｓ２０９）および親機設定要求手段（４２，Ｓ２１３）をさらに含む。子機有無判断手段（４２，Ｓ２１３）は、他のシーンに移動するとき、自機が親機である場合（Ｓ２０７で“ＹＥＳ”）に、現在のシーンに子機が存在するか否かを判断する。親機設定要求手段（４２，Ｓ２１３）は、子機が存在すると判断されたとき（Ｓ２０９で“ＹＥＳ”）、所定のルールに従って選択した１の子機に親機になることを要求する。たとえば、子機に割り当てられた通信ＩＤを参照して、小さい通信ＩＤの子機を選択する。または、ランダムに通信ＩＤ（子機）を選択する。

請求項４の発明では、親機が他のシーンに移動するとき、当該シーンに子機が存在する場合には、いずれかの子機に親機になることを要求するので、要求された子機がその後親機として処理を実行することができる。

請求項５の発明は請求項４に従属し、ゲーム装置は、他のゲーム装置から親機になることを要求されたかどうかを判断する親機設定要求判断手段、および親機設定要求判断手段によって親機になることを要求されたと判断されたとき、自機を親機として設定する設定変更手段をさらに含む。

請求項５の発明では、ゲーム装置（１０）は、親機設定要求判断手段（４２，Ｓ２３７）および設定変更手段（４２，Ｓ２３９）をさらに含む。親機設定要求判断手段（４２，Ｓ２３７）は、他のゲーム装置（１０）すなわち現在の親機から親機になることを要求されたかどうかを判断する。設定変更手段（４２，Ｓ２３９）は、親機になることを要求されたと判断されると（Ｓ２３７で“ＹＥＳ”）、自機を親機として設定する。

請求項５の発明によれば、親機になることを要求されたゲーム装置がシーンの親機に設定するため、その後、当該シーンにおける処理が滞ってしまうのを防止することができる。

請求項６の発明は請求項１ないし５のいずれかに従属し、ゲーム装置は、各々のゲーム装置が参加しているシーンについてのシーン識別情報および各々のゲーム装置が親機または子機のいずれに設定されているかを示す親子設定情報を含むシーン情報を記憶するシーン情報記憶手段をさらに含む。

請求項６の発明では、ゲーム装置（１０）は、シーン情報記憶手段（４８，７８）をさらに含み、このシーン情報記憶手段（４８，７８）はシーン情報を記憶する。シーン情報は、各々のゲーム装置（１０）が参加しているシーンについてのシーン識別情報（７８０）および各々のゲーム装置（１０）が親機または子機のいずれに設定されているかを示す親機設定情報（７８２）を含む。

請求項６の発明によれば、シーン情報を記憶しておくので、各ゲーム装置は、自機を含むすべてのゲーム装置の各々がどのシーンに参加しているのか知ることができ、また、自機を含むすべてのゲーム装置がシーンの親機であるか子機であるかを知ることができる。

請求項７の発明は請求項６に従属し、ゲーム装置は、少なくとも、他のシーンに移動したとき、シーン情報を更新するシーン情報更新手段をさらに含む。

請求項７の発明では、ゲーム装置は、シーン情報更新手段（４２，Ｓ２３，Ｓ７７）をさらに含み、このシーン情報更新手段（４２，Ｓ２３，Ｓ７７）は、少なくとも、他のシーンに移動したとき（Ｓ１７１で“ＹＥＳ”）、シーン情報を更新する。つまり、シーン識別情報（７８０）および親機設定情報（７８２）の少なくとも一方を変更する。これは、上述したように、親機になることを要求され、親機に設定を変更した場合には（ステップＳ１７３で“ＹＥＳ”）、親機設定情報（７８２）のみが変更されるからである。また、シーン情報は、すべてのゲーム装置についての情報であるため、他のゲーム装置（１０）からシーン情報の更新指示が与えられる場合もある。

請求項７の発明によれば、シーン情報が更新されるため、すべてのゲーム装置の最新のシーン情報を知ることができる。

請求項８は、複数のシーンを含む仮想空間にプレイヤとして参加し、通信ゲームをプレイするゲーム装置であって、共有ゲームデータ記憶手段、固有ゲームデータ記憶手段、親機設定手段、子機設定手段、親機処理手段、および子機処理手段を備える。共有ゲームデータ記憶手段は、通信ゲームを行うすべてのゲーム装置で共有すべき共有ゲームデータを記憶する。固有ゲームデータ記憶手段は、自機が参加しているシーンのみで共有すべきシーン固有の固有ゲームデータを記憶する。親機設定手段は、参加するシーンに他のゲーム装置が参加していないとき、自機を当該シーンの親機として設定する。子機設定手段は、参加するシーンに他のゲーム装置が参加しているとき、自機を当該シーンの子機として設定する。親機処理手段は、親機設定手段によって自機がシーンの親機として設定されたとき、少なくとも、共有ゲームデータの更新を自機以外のすべてのゲーム装置に指示し、または、固有ゲームデータの更新を当該シーンに参加しているすべての子機に指示する。そして、子機処理手段は、子機設定手段によって自機がシーンの子機として設定されたとき、少なくとも、親機からの指示に従って固有ゲームデータを更新する。

請求項８の発明においても、請求項１の発明と同様に、処理を分担することにより、通信効率の低下を防止することができる。

請求項１５の発明は、複数のシーンを含む仮想空間にプレイヤとして参加し、通信ゲームをプレイするゲーム装置のゲームプログラムであって、ゲーム装置は、通信ゲームを行うすべてのゲーム装置で共有すべき共有ゲームデータを記憶する共有ゲームデータ記憶手段、および自機が参加しているシーンのみで共有すべきシーン固有の固有ゲームデータを記憶する固有ゲームデータ記憶手段を備え、ゲームプログラムは、ゲーム装置のプロセサに、親機設定ステップ、子機設定ステップ、親機処理ステップ、および子機処理ステップを実行させる。親機設定ステップは、参加するシーンに他のゲーム装置が参加していないとき、自機を当該シーンの親機として設定する。子機設定ステップは、参加するシーンに他のゲーム装置が参加しているとき、自機を当該シーンの子機として設定する。親機処理ステップは、親機設定ステップによって自機がシーンの親機として設定されたとき、少なくとも、共有ゲームデータの更新を自機以外のすべてのゲーム装置に指示し、または、固有ゲームデータの更新を当該シーンに参加しているすべての子機に指示する。そして、子機処理ステップは、子機設定ステップによって自機がシーンの子機として設定されたとき、少なくとも、親機からの指示に従って固有ゲームデータを更新する。

請求項１５の発明においても、請求項１の発明と同様に、処理を分担することにより、通信効率の低下を防止することができる。

この発明によれば、シーン毎に存在する親機が処理を分担するので、１つのゲーム装置に処理が集中してしまうことがない。このため、通信効率の低下を防止することができる。

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

図１を参照して、この発明の一実施例であるゲームシステム（以下、単に「システム」という。）１００は複数のゲーム装置１０を含む。図１では、３台のゲーム装置１０によってシステム１００が構成されるように示してあるが、２台以上であれば、４台以上によって構成するようにしてもよい。システム１００では、複数のゲーム装置１０の各々は、通信（この実施例では、無線通信）可能に接続されており、１のゲーム装置１０が親機（説明の便宜上、以下において、「ネットワーク親機」と呼ぶことがある。）となり、ネットワーク親機以外の他のゲーム装置１０はすべて子機（説明の便宜上、以下において、「ネットワーク子機」と呼ぶことがある。）となる。

ここで、ネットワーク親機の決定の仕方は様々であるが、たとえば、無線通信を開始した後に、一番に何らかのボタンが操作されたゲーム装置を、ネットワーク親機として決定することができる。また、ネットワーク親機が決定されると、それ以外のゲーム装置１０はネットワーク子機として決定される。ただし、各ネットワーク子機を判別可能とするため、ネットワーク親機は、各ネットワーク子機に、識別情報ないし識別番号（以下、「通信ＩＤ」という。）を割り当てる。

図２は図１に示すゲーム装置１０の外観を示す図解図である。この図２を参照して、ゲーム装置１０は、第１の液晶表示器（ＬＣＤ）１２および第２のＬＣＤ１４を含む。このＬＣＤ１２およびＬＣＤ１４は、所定の配置位置となるようにハウジング1６に収納される。この実施例では、ハウジング１６は、上側ハウジング１６ａと下側ハウジング１６ｂとによって構成され、ＬＣＤ１２は上側ハウジング１６ａに収納され、ＬＣＤ１４は下側ハウジング１６ｂに収納される。したがって、ＬＣＤ１２とＬＣＤ１４とは縦（上下）に並ぶように近接して配置される。

なお、この実施例では、表示器としてＬＣＤを用いるようにしてあるが、ＬＣＤに代えて、ＥＬ(Electronic Luminescence)ディスプレイやプラズマディスプレイを用いるようにしてもよい。

図２からも分かるように、上側ハウジング１６ａは、ＬＣＤ１２の平面形状よりも少し大きな平面形状を有し、一方主面からＬＣＤ１２の表示面を露出するように開口部が形成される。一方、下側ハウジング１６ｂは、その平面形状が上側ハウジング１６ａよりも横長に選ばれ、横方向の略中央部にＬＣＤ１４の表示面を露出するように開口部が形成される。また、下側ハウジング１６ｂには、音抜き孔１８が形成されるとともに、操作スイッチ２０（２０ａ，２０ｂ，２０ｃ，２０ｄ，２０ｅ，２０Ｌおよび２０Ｒ）が設けられる。

また、上側ハウジング１６ａと下側ハウジング１６ｂとは、上側ハウジング１６ａの下辺（下端）と下側ハウジング１６ｂの上辺（上端）の一部とが回動可能に連結されている。したがって、たとえば、ゲームをプレイしない場合には、ＬＣＤ１２の表示面とＬＣＤ１４の表示面とが対面するように、上側ハウジング１６ａを回動させて折りたたんでおけば、ＬＣＤ１２の表示面およびＬＣＤ１４の表示面に傷がつくなどの破損を防止することができる。ただし、上側ハウジング１６ａと下側ハウジング１６ｂとは、回動可能に連結せずに、それらを一体的（固定的）に設けたハウジング１６を形成するようにしてもよい。

操作スイッチ２０は、方向指示スイッチ（十字スイッチ）２０ａ，スタートスイッチ２０ｂ、セレクトスイッチ２０ｃ、動作スイッチ（Ａボタン）２０ｄ、動作スイッチ（Ｂボタン）２０ｅ、動作スイッチ（Ｌボタン）２０Ｌおよび動作スイッチ（Ｒボタン）２０Ｒを含む。スイッチ２０ａ，２０ｂおよび２０ｃは、下側ハウジング１６ｂの一方主面であり、ＬＣＤ１４の左側に配置される。また、スイッチ２０ｄおよび２０ｅは、下側ハウジング１６ｂの一方主面であり、ＬＣＤ１４の右側に配置される。さらに、スイッチ２０Ｌおよびスイッチ２０Ｒは、それぞれ、下側ハウジング１６ｂの上端（天面）の一部であり、上側ハウジング１６ａとの連結部以外に当該連結部を挟むように、左右に配置される。

方向指示スイッチ２０ａは、ディジタルジョイスティックとして機能し、４つの押圧部の１つを操作することによって、プレイヤによって操作可能なプレイヤキャラクタ(またはプレイヤオブジェクト)の移動方向を指示したり、カーソルの移動方向を指示したりする等に用いられる。スタートスイッチ２０ｂは、プッシュボタンで構成され、ゲームを開始（再開）したり、一時停止(Pause)したりする等に用いられる。セレクトスイッチ２０ｃは、プッシュボタンで構成され、ゲームモードの選択等に用いられる。

動作スイッチ２０ｄすなわちＡボタンは、プッシュボタンで構成され、方向指示以外の動作、すなわち、プレイヤキャラクタに打つ（パンチ）、投げる、つかむ（取得）、乗る、ジャンプするなどの任意のアクションをさせることができる。たとえば、アクションゲームにおいては、ジャンプ、パンチ、武器を動かす等を指示することができる。また、ロールプレイングゲーム(ＲＰＧ)やシミュレーションＲＰＧにおいては、アイテムの取得、武器やコマンドの選択および決定等を指示することができる。動作スイッチ２０ｅすなわちＢボタンは、プッシュボタンで構成され、セレクトスイッチ２０ｃで選択したゲームモードの変更やＡボタン２０ｄで決定したアクションの取り消し等のために用いられる。

動作スイッチ（左押しボタン）２０Ｌおよび動作スイッチ（右押しボタン）２０Ｒは、プッシュボタンで構成され、左押しボタン（Ｌボタン）２０Ｌおよび右押しボタン（Ｒボタン）２０Ｒは、Ａボタン２０ｄおよびＢボタン２０ｅと同様の操作に用いることができ、また、Ａボタン２０ｄおよびＢボタン２０ｅの補助的な操作に用いることができる。

また、ＬＣＤ１４の上面には、タッチパネル２２が装着される。タッチパネル２２としては、たとえば、抵抗膜方式、光学式(赤外線方式)および静電容量結合式のいずれかの種類のものを用いることができる。また、タッチパネル２２は、その上面（検出面）をスティック２４ないしはペン（スタイラスペン）或いは指（以下、これらを「スティック２４等」という場合がある。）で、押圧したり、撫でたり、触れたりすることにより操作すると、スティック２４等の操作位置の座標を検出して、検出した座標（検出座標）に対応する座標データを出力する。

この実施例では、ＬＣＤ１４（ＬＣＤ１２も同じ、または略同じ。）の表示面の解像度は２５６ｄｏｔ×１９２ｄｏｔであり、タッチパネル２２の検出面の検出精度もその解像度に対応して２５６ｄｏｔ×１９２ｄｏｔとしてある。ただし、タッチパネル２２の検出面の検出精度は、ＬＣＤ１４の表示面の解像度よりも低くてもよく、高くてもよい。

ＬＣＤ１２およびＬＣＤ１４には異なるゲーム画像（ゲーム画面）を表示することができる。たとえば、一方のＬＣＤ（たとえば、ＬＣＤ１２）にゲームをプレイするためのゲーム画面を表示し、他方のＬＣＤ（たとえば、ＬＣＤ１４）に当該ゲームを操作するための文字情報を入力したり、アイコンを指示したりするためのゲーム画面（操作画面）を表示することができる。したがって、プレイヤはスティック２４等でタッチパネル２２を操作することにより、ＬＣＤ１４の画面上で、文字情報（コマンド）を入力したり、アイコン（或いは所定の画像）を指示したりすることができる。

このように、ゲーム装置１０は、２画面分の表示部となるＬＣＤ１２およびＬＣＤ１４を有し、いずれか一方（この実施例では、ＬＣＤ１４）の上面にタッチパネル２２が設けられるので、２画面（１２，１４）と２系統の操作部（２０，２２）とを有する構成になっている。

また、この実施例では、スティック２４は、たとえば上側ハウジング１６ａの側面（右側面）近傍に設けられる収納部（収納穴）２６に収納することができ、必要に応じて取り出される。ただし、スティック２４を設けない場合には、収納部２６を設ける必要もない。

さらに、ゲーム装置１０はメモリカード（またはゲームカートリッジ）２８を含み、このメモリカード２８は着脱自在であり、下側ハウジング１６ｂの裏面ないしは下端（底面）に設けられる挿入口３０から挿入される。図２では省略するが、挿入口３０の奥部には、メモリカード２８の挿入方向先端部に設けられるコネクタ（図示せず）と接合するためのコネクタ４６（図３参照）が設けられており、したがって、メモリカード２８が挿入口３０に挿入されると、コネクタ同士が接合され、ゲーム装置１０のＣＰＵコア４２（図３参照）がメモリカード２８にアクセス可能となる。

さらにまた、ゲーム装置１０はアンテナ３２を含み、たとえば、このアンテナ３２によって微弱電波を送受信することにより、他のゲーム装置１０との間で無線通信が可能である。詳細な説明は省略するが、この実施例で示すゲーム装置１０が送受信する微弱電波は、電波法による規制のかからない強度に設定されている。

なお、図２では表現できないが、下側ハウジング１６ｂの音抜き孔１８と対応する位置であり、この下側ハウジング１６ｂの内部にはスピーカ３２（図３参照）が設けられる。

また、図２では省略するが、たとえば、下側ハウジング１６ｂの裏面側には、電池収容ボックスが設けられ、また、下側ハウジング１６ｂの底面側には、電源スイッチ、音量スイッチ、外部拡張コネクタおよびイヤフォンジャックなどが設けられる。

図３はゲーム装置１０の電気的な構成を示すブロック図である。図３を参照して、ゲーム装置１０は電子回路基板４０を含み、この電子回路基板４０にはＣＰＵコア４２等の回路コンポーネントが実装される。ＣＰＵコア４２は、バス４４を介してコネクタ４６に接続されるととともに、ＲＡＭ４８、第１のグラフィック処理ユニット（ＧＰＵ）５０、第２のＧＰＵ５２、入出カインターフエース回路（以下、「Ｉ／Ｆ回路」という。）５４およびＬＣＤコントローラ６０が接続される。

コネクタ４６には、上述したように、メモリカード２８が着脱自在に接続される。メモリカード２８は、ＲＯＭ２８ａおよびＲＡＭ２８ｂを含み、図示は省略するが、ＲＯＭ２８ａおよびＲＡＭ２８ｂは、互いにバスで接続され、さらに、コネクタ４６と接合されるコネクタ（図示せず）に接続される。したがって、上述したように、ＣＰＵコア４２は、ＲＯＭ２８ａおよびＲＡＭ２８ｂにアクセスすることができるのである。

ＲＯＭ２８ａは、ゲーム装置１０で実行すべきゲーム（仮想ゲーム）のためのゲームプログラム、画像（キャラクタ画像、背景画像、アイテム画像、アイコン（ボタン）画像、メッセージ画像など）データおよびゲームに必要な音（音楽）のデータ（音データ）等を予め記憶する。ＲＡＭ（バックアップＲＡＭ）２８ｂは、そのゲームの途中データやゲームの結果データを記憶（セーブ）する。

ＲＡＭ４８は、バッファメモリないしはワーキングメモリとして使用される。つまり、ＣＰＵコア４２は、メモリカード２８のＲＯＭ２８ａに記憶されたゲームプログラム、画像データおよび音データ等をＲＡＭ４８にロードし、ロードしたゲームプログラムを実行する。また、ＣＰＵコア４２は、ゲームの進行に応じて一時的に発生するデータ（ゲームデータやフラグデータ）をＲＡＭ４８に記憶しつつゲーム処理を実行する。

なお、ゲームプログラム、画像データおよび音データ等は、ＲＯＭ２８ａから一度に全部、または部分的かつ順次的に読み出され、ＲＡＭ４８に記憶（ロード）される。

ＧＰＵ５０およびＧＰＵ５２は、それぞれ、描画手段の一部を形成し、たとえばシングルチップＡＳＩＣで構成され、ＣＰＵコア４２からのグラフィックスコマンド（graphics command ：作画命令）を受け、そのグラフィックスコマンドに従ってゲーム画像データを生成する。ただし、ＣＰＵコア４２は、グラフィックスコマンドに加えて、ゲーム画像データの生成に必要な画像生成プログラム（ゲームプログラムに含まれる。）をＧＰＵ５０およびＧＰＵ５２のそれぞれに与える。

また、ＧＰＵ５０には、第１のビデオＲＡＭ（以下、「ＶＲＡＭ」という。）５６が接続され、ＧＰＵ５２には、第２のＶＲＡＭ５８が接続される。ＧＰＵ５０およびＧＰＵ５２が作画コマンドを実行するにあたって必要なデータ（画像データ：キャラクタデータやテクスチャ等のデータ）は、ＧＰＵ５０およびＧＰＵ５２が、それぞれ、第１のＶＲＡＭ５６および第２のＶＲＡＭ５８にアクセスして取得する。なお、ＣＰＵコア４２は、描画に必要な画像データをＧＰＵ５０およびＧＰＵ５２を介して第１のＶＲＡＭ５６および第２のＶＲＡＭ５８に書き込む。ＧＰＵ５０はＶＲＡＭ５６にアクセスして描画のためのゲーム画像データを作成し、ＧＰＵ５２はＶＲＡＭ５８にアクセスして描画のためのゲーム画像データを作成する。

ＶＲＡＭ５６およびＶＲＡＭ５８は、ＬＣＤコントローラ６０に接続される。ＬＣＤコントローラ６０はレジスタ６２を含み、レジスタ６２はたとえば１ビットで構成され、ＣＰＵコア４２の指示によって「０」または「１」の値（データ値）を記憶する。ＬＣＤコントローラ６０は、レジスタ６２のデータ値が「０」である場合には、ＧＰＵ５０によって作成されたゲーム画像データをＬＣＤ１２に出力し、ＧＰＵ５２によって作成されたゲーム画像データをＬＣＤ１４に出力する。また、ＬＣＤコントローラ６０は、レジスタ６２のデータ値が「１」である場合には、ＧＰＵ５０によって作成されたゲーム画像データをＬＣＤ１４に出力し、ＧＰＵ５２によって作成されたゲーム画像データをＬＣＤ１２に出力する。

なお、ＬＣＤコントローラ６０は、ＶＲＡＭ５６およびＶＲＡＭ５８から直接ゲーム画像データを読み出したり、ＧＰＵ５０およびＧＰＵ５２を介してＶＲＡＭ５６およびＶＲＡＭ５８からゲーム画像データを読み出したりする。

Ｉ／Ｆ回路５４には、操作スイッチ２０，タッチパネル２２およびスピーカ３２が接続される。ここで、操作スイッチ２０は、上述したスイッチ２０ａ，２０ｂ，２０ｃ，２０ｄ，２０ｅ，２０Ｌおよび２０Ｒであり、操作スイッチ２０が操作されると、対応する操作信号（操作データ）がＩ／Ｆ回路５４を介してＣＰＵコア４２に入力される。また、タッチパネル２２からの座標データがＩ／Ｆ回路５４を介してＣＰＵコア４２に入力される。さらに、ＣＰＵコア４２は、ゲーム音楽（ＢＧＭ）、効果音またはゲームキャラクタ（ゲームオブジェクト）の音声（擬制音）などのゲームに必要な音データをＲＡＭ４８から読み出し、Ｉ／Ｆ回路５４を介してスピーカ３２から出力する。

また、図２に示したように、ゲーム装置１０には、アンテナ３２が接続されており、このアンテナ３２は無線通信ユニット６４に接続される。無線通信ユニット６４は、バス４４を介してＣＰＵコア４２に接続される。ＣＰＵコア４２がゲームデータやコマンドを無線通信ユニット６４に与えると、無線通信ユニット６４はゲームデータ等をアナログ信号に変換して、微弱電波でアンテナ３２から送信（発信）する。一方、無線通信ユニット６４は、他のゲーム装置１０から送信された微弱電波をアンテナ３２を介して受信し、受信した微弱電波からアナログ信号を分離し、ディジタル変換した後、ＣＰＵコア４２に与える。このようにして、他のゲーム装置１０との間で無線通信が行われる。したがって、システム１００では、各々のゲーム装置１０で通信して同一の仮想ゲーム（通信ゲーム）をプレイすることができる。

従来、複数のゲーム装置間で通信ゲームを行う場合、各ゲーム装置間での通信結果を一致させるために、各ゲーム装置のプレイヤが操作した情報を１つのゲーム装置（ネットワーク親機）に集め、整合を取った上で他のすべてのゲーム装置（ネットワーク子機）に送信する方法が採られている。このような通信ゲームを行うゲームシステムでは、各ゲーム装置のプレイヤが受ける有利不利の偏りを無くすために、処理サイクルが所定の回数実行される度に、ネットワーク親機となるゲーム装置を順番に変更するようにしてある。

しかし、ネットワーク親機は常に１台であり、通信ゲームに参加するゲーム装置が増加すると、ネットワーク親機の処理負担も増大し、通信効率の低下を招いてしまう。

そこで、この実施例では、通信ゲームにおいて、複数のシーン（場面）を含む仮想空間における通信ゲームをプレイする場合に、シーン毎に、親機（以下、説明の都合上、「シーンホスト」という。）と子機（以下、説明の都合上、「シーンビジター」という。）とを決定し、各々のシーンホストによって処理を分担するようにしてある。つまり、ネットワーク親機のみに処理が集中するのを回避するのである。

図４は、システム１００で実行される仮想ゲーム（通信ゲーム）の仮想空間２００を２次元平面で表わした図解図である。たとえば、仮想空間２００は、４つのシーン（シーン１，シーン２，シーン３，シーン４）を含む。ただし、図４に示す例では、システム１００を構成する各ゲーム装置１０（これ以降では、Ａ，Ｂ，Ｃ，Ｄ，Ｅ，Ｆと表記して区別する場合がある。）を丸で示し、各シーンを区分する点線枠内に記載することにより、そのシーンにプレイヤとして参加していることを表現してある。上述したように、ゲーム装置Ａ−Ｆは互いに通信可能である。また、図４では、分かり易くするために、４つのシーンをそれぞれ四角形で示してある。たとえば、或る街中のシーンや或る建物内のシーンなどが仮想空間２００内に設けられるのである。ただし、シーンは、ゲームの種類などにより様々であり、ゲームのプログラムや開発者が設計する事項である。

図４に示す例では、シーン１には、ゲーム装置Ａ、ゲーム装置Ｂおよびゲーム装置Ｄが参加している。また、シーン２には、ゲーム装置Ｃが参加している。さらに、シーン３には、ゲーム装置Ｅおよびゲーム装置Ｆが参加している。そして、シーン４には、いずれのゲーム装置１０も参加していない。また、シーン１では、ゲーム装置Ａがシーンホスト（図面では、単に「ホスト」と表記する。以下、同じ。）であり、ゲーム装置Ｂおよびゲーム装置Ｄがシーンビジター（図面では、単に「ビジター」と表記する。以下、同じ。）である。シーン２では、ゲーム装置Ｃがシーンホストであり、シーンビジターは存在しない。シーン３では、ゲーム装置Ｅがシーンホストであり、ゲーム装置Ｆがシーンビジターである。

この図４に示す例を用いて、各シーンでシーンホストが設定される方法やゲーム装置１０（シーンホストまたはシーンビジター）が異なるシーンに移動する方法について説明する。ただし、ゲーム装置１０が無線通信（通信ゲーム）を開始した当初において、所望のシーンに参加する場合の方法（処理）は、ゲーム装置１０が或るシーンから他のシーンに移動する場合と同様の処理となるため、その詳細な説明は省略することにする。

図５は或るシーンに存在するシーンビジターが他のシーンに移動する場合の一例を示す図解図である。具体的には、シーン１のシーンビジターとしてのゲーム装置Ｄがシーン２に移動する例が示される。つまり、図５（Ａ）はシーン１のシーンビジターとしてのゲーム装置Ｄがシーン２に移動する前の状態を示し、図５（Ｂ）はそのゲーム装置Ｄがシーン２に移動した後の状態を示す。

なお、これ以降では、簡単のため、シーン１のシーンホストをシーン１ホストと呼び、シーン１のシーンビジターをシーン１ビジターと呼ぶことがある。説明は省略するが、他のシーン（この実施例では、シーン２，シーン３，シーン４）のシーンホストおよびシーンビジターについても同様である。

図５（Ａ）および図５（Ｂ）に示すように、シーン２には、シーン２ホストとしてのゲーム装置Ｃが存在するため、つまり他のゲーム装置１０が既に存在するため、ゲーム装置Ｄはシーンビジターとしてシーン２に参加することになる。つまり、ゲーム装置Ｄは、シーン２に移動したとき、シーンビジターとして設定される。後で詳細に説明するが、ゲーム装置１０が他のシーンに移動（参加）する場合には、現在参加しているシーンにおける役割（シーンホストまたはシーンビジター）についての設定は解除される。つまり、後述するシーン情報が更新される。

なお、ゲーム装置１０が通信ゲームを開始した当初において、所望のシーンに参加する場合に、当該所望のシーンに他のゲーム装置１０が既に参加している場合も同様に、シーンビジターとして設定される。

図６は或るシーンに存在するシーンビジターが他のシーンに移動する場合の他の例を示す図解図である。具体的には、シーン１ビジターとしてのゲーム装置Ｄがシーン４に移動する例が示される。図６（Ａ）はシーン１ビジターとしてのゲーム装置Ｄがシーン４に移動する前の状態を示し、図６（Ｂ）はそのゲーム装置Ｄがシーン４に移動した後の状態を示す。この実施例では、移動後のシーンに他のゲーム装置１０（シーンホスト）が存在しない場合には、移動したゲーム装置１０をシーンホストに設定するようにしてある。したがって、ゲーム装置Ｄは、シーン４に移動したとき、シーンホストとして設定される。

なお、ゲーム装置１０が通信ゲームを開始した当初において、所望のシーンに参加する場合に、当該所望のシーンに他のゲーム装置１０が全く参加していない場合に、シーンホストとして設定される。

図７は或るシーンのシーンホストが他のシーンに移動する場合の一例を示す図解図である。具体的には、シーン１ホストとしてのゲーム装置Ａがシーン２に移動する例が示される。図７（Ａ）はシーン１ホストとしてのゲーム装置Ａがシーン２に移動する前の状態を示し、図７（Ｂ）はそのゲーム装置Ａがシーン２に移動した後の状態を示す。かかる場合には、上述のシーンビジターが移動する場合とは異なり、移動前のシーンにおいて他のゲーム装置１０にシーンホストの設定を要求する手続き（処理）が必要となる。これは、シーンビジターが移動する場合と同様に、シーンホストがそのまま他のシーンに移動してしまうと、移動前のシーンにシーンホストが存在しないことになり、当該移動前のシーンにおけるゲーム処理が滞ってしまうためである。つまり、不具合（不都合）が発生する。

ただし、移動前のシーンにシーンホストのみしか存在しない場合には、その後のゲーム処理が滞ることがなく、また、シーンビジターも存在しないため、シーンホストの設定を要求する手続きは不要である。

図７（Ａ）および図７（Ｂ）に示すように、シーン１ホストすなわちゲーム装置Ａがシーン２に移動する場合には、ゲーム装置Ａは、シーン２に移動する前に、シーン１ビジターとしてのゲーム装置Ｂにシーンホストになることを要求する。つまり、ゲーム装置Ａは、ゲーム装置Ｂにシーンホストへの設定変更を要求する。

ここで、図７（Ａ）に示す例では、シーンビジターとしてのゲーム装置Ｂおよびゲーム装置Ｄのうち、ゲーム装置Ｂにシーンホストの設定を要求するようにしてある。これは、通信ＩＤを用いて所定のルールに従って、シーンホストへの設定変更を要求するシーンビジターを選択するようにしてあるためである。この実施例では、分かり易くするために、ゲーム装置１０の各々を識別するためのアルファベットと通信ＩＤとが同一であるものとする。通信ＩＤは、ネットワーク親機が各ネットワーク子機に対して割り当てる。たとえば、ネットワーク親機は、接続要求を受信した順番で、順次（アルファベット順に）通信ＩＤを割り当てる。したがって、最初にネットワーク親機に接続要求を送信したネットワーク子機には、通信ＩＤとして「Ａ」が割り当てられる。この次にネットワーク親機に接続要求を送信したネットワーク子機には、通信ＩＤとして「Ｂ」が割り当てられる。そして、その次にネットワーク親機に接続要求を送信したネットワーク子機には、通信ＩＤとして「Ｃ」が割り当てられる。これ以降に、ネットワーク親機に接続要求を送信したネットワーク子機についても同様である。

この実施例では、或るシーンから他のシーンに移動しようとするシーンホストが、小さい（アルファベット順の番号が若い）通信ＩＤの割り当てられたシーンビジターに、シーンホストになるように要求するのである。したがって、図７（Ａ）に示すように、ゲーム装置Ａはゲーム装置Ｂにシーンホストへの設定変更を要求しているのである。

ただし、アルファベット順の番号が若い通信ＩＤのネットワーク子機を選択する方法に限定する必要はなく、ランダムにネットワーク子機を選択するようにしてもよい。つまり、所定のルールは様々であり、ゲームのプログラマや開発者設計する事項である。

そして、図７（Ｂ）に示すように、ゲーム装置Ｂはシーン１ホストになり、また、ゲーム装置Ａはシーン２に移動する。このゲーム装置Ａのシーン２への移動については、図５（Ａ）および図５（Ｂ）に示したように、ゲーム装置Ｄがシーン２に移動する場合と同じであるため、重複した説明は省略する。

図８は或るシーンのシーンホストが他のシーンに移動する場合の他の例を示す図解図である。具体的には、シーン１ホストとしてのゲーム装置Ａがシーン４に移動する例が示される。図８（Ａ）はシーン１ホストとしてのゲーム装置Ａがシーン４へ移動する前の状態を示し、図８（Ｂ）はそのゲーム装置Ａがシーン４に移動した後の状態を示している。この図８に示す例では、移動後のシーン４において、ゲーム装置Ａがシーンホストとして設定される以外は、図７に示した場合と同じであるため、重複した説明は省略する。つまり、図７（Ａ）を用いて説明したのと同様に、ゲーム装置Ａは、移動前のシーン１においてゲーム装置Ｂにシーンホストへの設定変更を要求して、シーン４に移動する。また、ゲーム装置Ａが移動後のシーン４においてシーンホストとして設定されるのは、図６を用いて説明した場合と同じである。

このように、ゲーム装置１０は、各シーン（仮想ゲーム空間２００内）を自由に移動し、各シーンにおいて、シーンホストやシーンビジターとして設定され、それぞれの役割を果たしながら、通信ゲームを実行する。

図９〜図１３は、通信ゲームにおけるゲームデータ（ゲーム全体データ）の更新処理を説明するための図解図である。この図９〜図１３においては、簡単のため、仮想空間２００にシーン１およびシーン２のみが含まれる場合について示してある。また、シーン１には、ゲーム装置Ａとゲーム装置Ｂとが参加し、ゲーム装置Ａがシーン１ホストであり、ゲーム装置Ｂがシーン１ビジターである。シーン２には、ゲーム装置Ｃおよびゲーム装置Ｄとが参加し、ゲーム装置Ｃがシーン２ホストであり、ゲーム装置Ｄがシーン２ビジターである。さらに、図９〜図１３では、各ゲーム装置Ａ〜Ｄに内蔵されるＲＡＭ４８に記憶されたゲーム全体データ（シーン共有データおよびシーン固有データ）のみを示してある。なお、ＲＡＭ４８の内容については、後で詳細に説明するため、ここでは省略する。

図９は、シーン１において、シーン１ビジターとしてのゲーム装置Ｂがシーン１ホストとしてのゲーム装置Ａにゲームデータ（シーン共有データ）の書き換え（変更）を要求した状態を示す。ここで、ゲーム全体データは、シーン共有データとシーン固有データとを含む。シーン共有データは、仮想ゲーム（通信ゲーム）をプレイしている（通信ゲームに参加している）すべてのプレイヤ（ゲーム装置１０）と共有するデータである。各ゲーム装置１０は、自身（自機）がどのシーンに参加しているかに拘わらず、すべてのシーンについてのシーン共有データをメモリ（ＲＡＭ４８）に保持しており、このシーン共有データは、或るシーンにいずれのゲーム装置１０も参加していなくても保存される。つまり、通信ゲームの終了時には、セーブされるデータである。この実施例では、メモリカード２８のＲＡＭ２８ｂにセーブされる（図３参照）。また、シーン固有データは、同一シーンでプレイしているプレイヤ（ゲーム装置１０）とのみ共有するデータである。各ゲーム装置１０は、自機が現在参加しているシーンのシーン固有データをＲＡＭ４８に保持しており、このシーン固有データは、別のシーンに移動する場合に破棄される。

したがって、たとえば、ロールプレイングゲームのような仮想ゲームの町並みのシーンでは、或る商店に陳列されている商品の情報はシーン共有データである。つまり、或る商店において、どんな商品が陳列されているのかは、いずれのプレイヤが見ても同じ状態であり、また、誰かが商品を購入した場合には、その後に当該商店を訪れても商品は無くなった状態である必要がある。これに対して、或る商店の店主のようなノンプレイヤオブジェクトの状態（現在位置や動作など）はシーン固有データである。つまり、ノンプレイヤオブジェクトがどこに居て、何をしているのかは、そのシーンに参加しているプレイヤには同じように見える必要はあるが、他のシーンに参加しているプレイヤには何ら関係がない。また、そのシーンから誰も居なくなった後に、誰かが再びそのシーンに参加した場合に、つまりその商店を誰かが訪れた場合に、シーン固有データが初期化されて、ノンプレイヤオブジェクトが別の位置に移動していたとしても特に違和感がない。

図９に戻って、ゲーム装置Ｂがシーン共有データに含まれるシーン１データ（変数ａ１）の変更をゲーム装置Ａに要求すると、これに応じて、ゲーム装置Ａは、図１０に示すように、自機のＲＡＭ４８に保持されている変数ａ１を書き換える。ここでは、変数ａ１の値を「０」から「１」に書き換える。つまり、シーン共有データが更新される。そして、ゲーム装置Ａは、他のすべてのゲーム装置Ｂ、ゲーム装置Ｃおよびゲーム装置Ｄに、変数ａ１の更新を指示する。これは、上述したように、シーン共有データは、通信ゲームに参加しているすべてのゲーム装置１０の間で共有する必要があるからである。したがって、図１１に示すように、ゲーム装置Ｂ、ゲーム装置Ｃおよびゲーム装置Ｄにおいても、変数ａ１が書き換えられ、つまり、シーン共有データが更新される。

なお、図示は省略するが、シーンホストがシーン共有データを更新した場合には、当該シーン共有データの更新が他のすべてのゲーム装置１０に指示されるだけである。

また、図１２は、シーンホストがシーン固有データの更新をシーンビジターに指示した状態を示す図解図である。具体的には、シーン１において、シーン１ホストとしてのゲーム装置Ａがシーン１データ（変数ｎ１）の更新をシーン１ビジターとしてのゲーム装置Ｂに指示した状態を示す。ただし、ゲーム装置Ａは自身のＲＡＭ４８に保持するシーン固有データの更新をした時に、ゲーム装置Ｂにその更新を指示する。これに応じて、図１３に示すように、ゲーム装置Ｂが自身のＲＡＭ４８に保持される変数ｎ１を更新する。ここでは、変数ｎ１の値が「０」から「１」に書き換えられる。つまり、シーン固有データが更新される。

なお、シーン固有データは、そのシーンにおけるシーンホストがランダム（乱数）に決定（発生および更新）するため、シーンビジターがシーン固有データの更新をシーンホストに要求することはない。また、上述したように、シーン固有データは、他のシーンに参加しているゲーム装置１０には何ら関係ないため、他のシーンに参加しているゲーム装置１０にその更新が指示されることもない。

このようにして、通信ゲームにおいては、各シーンに存在するシーンホストによってゲーム全体データの更新処理が実行される。つまり、従来のゲームシステムにおいて、ネットワーク親機のみが実行していた処理が各シーンホストによって分担される。ただし、いずれのゲーム装置１０も参加していないシーンにおいては、シーンホストは存在しない。

なお、当然ではあるが、ネットワーク親機がシーンホストとしてシーンに参加している場合には、ゲーム全体データの更新処理を分担する必要がある。

図１４は、ゲーム装置１０に内蔵されるＲＡＭ４８のメモリマップの一例を示す図解図である。図１４に示すように、ＲＡＭ４８は、通信ＩＤ記憶領域７０、ゲームプログラム記憶領域７２、画像データ記憶領域７４、ゲーム全体データ記憶領域７６、シーン情報記憶領域７８およびその他の領域８０を含む。

通信ＩＤ記憶領域７０は、ゲーム装置１０に割り当てられた通信ＩＤを記憶する領域である。したがって、この通信ＩＤ記憶領域７０は、通信ゲームを行う度に書き換えられる。ただし、上述したように、ネットワーク親機がネットワーク子機に通信ＩＤを割り当てるため、ネットワーク親機には、通信ＩＤは割り当てられない。このため、通信ゲームに参加しているゲーム装置１０であって、通信ＩＤが記述されていないものがネットワーク親機であると識別することができる。

ゲームプログラム記憶領域７２は、任意のゲーム（この実施例では、通信ゲームである。以下、同じ。）を実行するためのゲームプログラムを記憶する。ここで、ゲームプログラムは、ゲーム全体処理プログラム、画像表示プログラム、音（音楽）再生プログラム、バックアッププログラムなどで構成される。ただし、この実施例では、通信ゲームを実行するようにしてあるため、ゲームプログラムには、通信プログラムも含まれる。画像データ記憶領域７４は、任意のゲームに登場する、プレイヤオブジェクト、敵オブジェクトなどのノンプレイヤオブジェクト、アイテムオブジェクト、背景オブジェクトを描画（生成および表示）するための画像データ（ポリゴンデータやテクスチャデータなど）を記憶する。

ゲーム全体データ記憶領域７６は、シーン共有データ記憶領域７６０とシーン固有データ記憶領域７６２とによって構成される。シーン共有データ記憶領域７６０には、シーン共有データ、すなわち、シーン１データ７６０ａ（変数ａ１，ｂ１，…）、シーン２データ７６０ｂ（変数ａ２，ｂ２，…）、…が記憶される。また、シーン固有データ記憶領域７６２には、現在のシーンについてのシーン固有データ、すなわち、シーンｘデータ７６２ａ（変数ｎｘ，ｏｘ，…）が記憶される。ただし、この実施例では、変数ｘは、１〜４の整数であり、現在参加しているシーン番号を示す。このように、シーン固有データについては、全てのシーンについての固有データを記憶する必要はなく、自機が参加しているシーンの固有データのみを記憶すればよいので、メモリ（ＲＡＭ４８）の使用量ないし容量を節約することができる。

シーン情報記憶領域７８には、シーン情報を記憶するための領域である。具体的には、各ゲーム装置１０についてのシーン番号データ７８０および各ゲーム装置１０についてのシーンホストデータ７８２が記憶される。シーン番号データ７８０は、各ゲーム装置１０に対応して、各ゲーム装置１０が現在参加しているシーンのシーン番号（識別情報）を示すデータである。シーンホストデータ７８２は、各ゲーム装置１０がシーンホストとして設定されているか、シーンビジターとして設定されているかを示すデータ（フラグ）である。たとえば、シーンホストデータ７８２は、通信ゲームに参加しているゲーム装置１０と同じ或いはそれ以上の数のビット数を有するレジスタで構成され、各ビットが各ゲーム装置１０に対応する。そして、ゲーム装置１０がシーンホストとして設定されている場合には、フラグ（以下、「シーンホストフラグ」という。）はオンであり、対応するビットにはデータ値「１」が設定される。一方、ゲーム装置１０がシーンビジターとして設定されている場合には、シーンホストフラグはオフであり、対応するビットにはデータ値「０」が設定される。

その他の領域８０は、ＣＰＵコア４２のワーキング領域や他の記憶領域として用いられる。たとえば、ゲームに必要な音（音楽）を出力するための音（音楽）データが記憶される。

具体的には、ゲーム装置１０のＣＰＵコア４２が以下に示すようなフロー図を処理することにより、通信ゲームに参加したり、シーンを移動したり、ゲーム全体データを更新したりする。図１５および図１６は、ゲーム装置１０（自機）がネットワーク親機である場合における通信処理を示すフロー図である。なお、自機がネットワーク親機か否かの判断は、通信ＩＤが割り当てられているか否かで判断することができる。以下、同じである。

図１５に示すように、ＣＰＵコア４２は、ネットワーク親機の場合における通信処理を開始すると、ステップＳ１で、メモリカード２８からシーン共有データを読み出して、ＲＡＭ４８に書き込む。続くステップＳ３では、ゲーム開始時のシーンのシーン固有データおよびシーン情報を作成して、ＲＡＭ４８に書き込む。ここで、シーン固有データを作成するとは、具体的には、ＣＰＵコア４２が、シーン固有データに含まれる各変数（またはフラグ）の値をランダムに設定する。また、ＣＰＵコア４２は、シーン番号データ７８０として、自機の識別情報に対応してゲーム開示時のシーン番号を記述するとともに、シーンホストデータ７８２として、自機に対応するビットにデータ値「１」を設定する。つまり、自機のシーンホストフラグをオンする。

次のステップＳ５では、後述する、シーンホストの場合におけるゲームデータ更新処理（図１９および図２０参照）を実行し、ステップＳ７で、ネットワーク親機としての通信開始処理を実行する。続くステップＳ９では、ネットワーク子機（他のゲーム装置１０）からの接続を待機し、ステップＳ１１で、ネットワーク子機（他のゲーム装置１０）からの接続要求があるかどうかを判断する。ステップＳ１１で“ＮＯ”であれば、つまりネットワーク子機からの接続要求がなければ、そのまま図１６に示すステップＳ２１に移行する。一方、ステップＳ１１で“ＹＥＳ”であれば、つまりネットワーク子機からの接続要求があれば、ステップＳ１３で、通信ゲームを一時停止する。

この実施例では、簡単のため、通信ゲームにおけるゲームデータの更新処理のみを後で説明するが（図１９〜図２２参照）、厳密には、ＣＰＵコア４２は、通信処理と並行して、通信ゲームのゲーム処理も実行しているのである。したがって、ステップＳ１３では、その通信ゲームを一時停止しているのである。

なお、簡単に説明すると、通信ゲーム処理では、プレイヤの指示に従って、ゲームオブジェクトに任意のアクションを実行させるアニメーション処理を実行したり、またその様子を表現したりゲーム世界を表示するための画像処理を実行したり、ゲームに必要な音の再生処理を実行したりする。

次のステップＳ１５では、ネットワーク子機と接続する。ここで、本実施例は親機と子機とが微弱電波によって無線通信をしながらゲームを進行させる無線通信ゲームシステムであるので、本来的には「接続」の用語を用いるべきではない。しかしながら、親機となる携帯ゲーム装置と子機となる携帯ゲーム装置との間での通信可能な連係状態を表す用語として、有線通信の場合の用語を借りて、便宜上「接続」と表現することとしてある。

なお、このような接続処理（後述するネットワーク子機として接続処理も同じ。）の一例は、本件出願人が先に出願し、既に出願公開された特開２００４−１３５７７８号公報に詳細に開示されており、また、このような接続処理は、本願発明の本質的な内容ではないため、その説明は省略することにする。

続くステップＳ１７で、シーン共有データおよびシーン情報を接続したネットワーク子機に送信し、ステップＳ１９で、通信ゲームを再開して、ステップＳ２１に進む。図１６に示すように、ステップＳ２１では、ゲーム終了かどうかを判断する。具体的には、プレイヤからゲーム終了の指示が入力されたり、ゲームオーバーになってしまったりしたかどうかを判断する。ステップＳ２１で“ＹＥＳ”であれば、つまりゲーム終了であれば、そのままネットワーク親機である場合における通信処理を終了する。

なお、この実施例では、ネットワーク親機が通信ゲームを終了すると、ネットワーク子機においても通信ゲームが終了（強制終了）される。

しかし、ステップＳ２１で“ＮＯ”であれば、つまりゲーム終了でなければ、ステップＳ２３で、後述する、シーン情報更新処理（図２３参照）を実行する。続くステップＳ２５では、自機が他のシーンへ移動したかを判断する。ここでは、シーン情報に含まれるシーン番号データ７８０を参照して、自機についてのシーン番号が更新されたかどうかを判断する。ステップＳ２５で“ＮＯ”であれば、つまり自機が他のシーンへ移動していなければ、ステップＳ２７で、自機がシーンホストであるかどうかを判断する。ここでは、シーンホストデータ７８２を参照して、自機のシーンホストフラグがオンであるかどうかを判断する。ステップＳ２７で“ＮＯ”であれば、シーンビジターであれば、そのままステップＳ３５に移行する。一方、ステップＳ２７で“ＹＥＳ”であれば、つまり自機がシーンホストであれば、そのままステップＳ３９に移行する。

また、ステップＳ２５で“ＹＥＳ”であれば、つまり自機がシーン移動していれば、ステップＳ２９で、自機がシーンホストであるかどうかを判断する。この判断手法は、ステップＳ２７の場合と同じである。ステップＳ２９で“ＮＯ”であれば、つまり自機がシーンビジターであれば、ステップＳ３１で、シーンホストから移動先のシーンのシーン固有データを受信し、ステップＳ３３で、受信したシーン固有データをＲＡＭ４８に書き込む。そして、ステップＳ３５で、後述する、シーンビジターの場合におけるゲームデータ更新処理（図２１および図２２）を実行して、図１５に示したステップＳ７に戻る。

しかし、ステップＳ２９で“ＹＥＳ”であれば、つまり自機がシーンホストであれば、ステップＳ３７で、移動先のシーンのシーン固有データを作成して、ＲＡＭ４８に書き込む。そして、ステップＳ３９で、後述する、シーンホストの場合におけるゲームデータ更新処理を実行して、ステップＳ７に戻る。

図１７および図１８は、ゲーム装置１０（自機）がネットワーク子機である場合における通信処理を示すフロー図である。図１７に示すように、ＣＰＵコア４２はネットワーク子機の場合における通信処理を開始すると、ステップＳ５１で、子機として通信開始処理を実行する。次のステップＳ５３では、ネットワーク親機をサーチし、ステップＳ５５で、ネットワーク親機が見つかったかどうかを判断する。ステップＳ５５で“ＮＯ”であれば、つまりネットワーク親機が見つからなければ、そのままステップＳ５３に戻って、ネットワーク親機のサーチを継続する。一方、ステップＳ５５で“ＹＥＳ”であれば、つまりネットワーク親機が見つかれば、ステップＳ５７で、ネットワーク親機と接続する。

なお、上述したように、このような通信処理は、特開２００４−１３５７７８号公報に詳細に開示されている。

また、この実施例では、ステップＳ５５で、ネットワーク親機が見つからない場合には、ステップＳ５３に戻って、ネットワーク親機をサーチし続けるようにしてある。しかし、電池（バッテリ）の無駄な浪費を削減するために、たとえば、ネットワーク親機のサーチ時間が一定時間を超えた場合には、ネットワーク親機が見つからない旨を通知して、通信処理を終了する、またはネットワーク親機としての通信処理（図１５および図１６）を開始するようにしてもよい。

上述したように、ネットワーク親機と接続すると、ステップＳ５９で、ネットワーク親機からシーン共有データおよびシーン情報を受信し、ステップＳ６１で、受信したシーン共有データおよびシーン情報をＲＡＭ４８に書き込む。続いて、ステップＳ６３では、ゲーム開始時のシーンにシーンホストが存在するかどうかを判断する。ここでは、シーン情報に含まれるシーン番号データ７８０を参照して、自機が参加するシーンに、他のゲーム装置１０が参加しているかどうかを判断する。

ステップＳ６３で“ＹＥＳ”であれば、つまりゲーム開始時のシーンにシーンホストが存在すれば、シーンビジターとして当該シーンに参加すべく、ステップＳ６５で，シーンホストからそのシーンのシーン固有データを受信し、ステップＳ６７で、受信したシーン固有データをＲＡＭ４８に書き込む。そして、ステップＳ６９で、後述する、シーンビジターの場合におけるゲームデータ更新処理を実行し、図１８に示すステップＳ７５に進む。

一方、ステップＳ６３で“ＮＯ”であれば、つまりゲーム開始時のシーンにシーンホストが存在しなければ、シーンホストとして当該シーンに参加すべく、ステップＳ７１で、ゲーム開始時のシーンのシーン固有データを作成して、ＲＡＭ４８に書き込む。そして、ステップＳ７３で、後述する、シーンホストとしてゲーム処理を実行し、ステップＳ７５に進む。

なお、図示は省略するが、シーンホストまたはシーンビジターとして、シーンに参加するとき、シーン情報すなわちシーン番号データ７８０およびシーンホストデータ７８２に自機の内容を追加する。つまり、自機が参加するシーンの番号を、自機の識別情報に対応して記述したデータをシーン番号データ７８０に追加する。また、シーンホストとして参加する場合には、自機についてのシーンホストフラグをオンする。

図１８に示すように、ステップＳ７５では、ゲーム終了かどうかを判断する。ここでは、プレイヤによってゲーム終了の指示が与えられたり、ゲームオーバーになったり、ネットワーク親機が通信ゲームを終了したりしたかどうかを判断する。ステップＳ７５で“ＹＥＳ”であれば、つまりゲーム終了であれば、そのままネットワーク子機の場合における通信処理を終了する。一方、ステップＳ７５で“ＮＯ”であれば、つまりゲーム終了でなければ、ステップＳ７７で、後述するシーン情報更新処理を実行し、ステップＳ７９で、自機が他のシーンへ移動したどうかを判断する。この判断手法は、上述したステップＳ２５の場合と同様である。

ステップＳ７９で“ＮＯ”であれば、つまり他のシーンに移動していなければ、ステップＳ８１で、自機がシーンホストであるかどうかを判断する。ステップＳ８１で“ＮＯ”であれば、つまり自機がシーンビジターであれば、そのままステップＳ８９に移行する。しかし、ステップＳ８１で“ＹＥＳ”であれば、つまり自機がシーンホストであれば、そのままステップＳ９３に進む。

一方、ステップＳ７９で“ＹＥＳ”であれば、つまり他のシーンへ移動していれば、ステップＳ８３で、自機がシーンホストであるかどうかを判断する。この判断手法は、上述したステップＳ２５の処理と同じである。ステップＳ８３で“ＮＯ”であれば、つまり自機がシーンビジターである場合には、ステップＳ８５で、シーンホストから移動先のシーンのシーン固有データを受信し、ステップＳ８７で、受信したシーン固有データをＲＡＭ４８に書き込む。そして、ステップＳ８９で、後述する、シーンビジターの場合におけるゲームデータ更新処理を実行して、ステップＳ７５に戻る。

また、ステップＳ８３で“ＹＥＳ”であれば、つまり自機がシーンホストである場合には、ステップＳ９１で、移動先のシーンのシーン固有データを作成して、ＲＡＭ４８に書き込む。そして、ステップＳ９３で、後述する、シーンホストの場合におけるゲームデータ更新処理を実行し、ステップＳ７５に戻る。

図１９および図２０は、シーンホストの場合におけるゲームデータ更新処理（上述したステップＳ５，Ｓ３９，Ｓ７３，Ｓ９３）である。このゲーム処理は、ネットワーク親機またはネットワーク子機に拘わらず、シーンにおける親機（シーンホスト）である場合に実行される。図１９に示すように、ＣＰＵコア４２は、シーンホストの場合におけるゲームデータ更新処理を開始すると、ステップＳ１０１で、シーンビジターからシーン共有データ（ここでは、説明の便宜上、「変数ａ１」とする。）のロックを要求されたかどうかを判断する。

ステップＳ１０１で“ＮＯ”であれば、つまり変数ａ１のロックを要求されていなければそのまま図２０に示すステップＳ１２５に進む。しかし、ステップＳ１０１で“ＹＥＳ”であれば、つまり変数ａ１のロックを要求されれば、ステップＳ１０３で、変数ａ１がロックされているかどうかを判断する。つまり、今回変数ａ１のロックを要求してきたシーンビジターとは異なるシーンビジターの要求によって既に変数ａ１がロックされているかどうかを判断するのである。

ステップＳ１０３で“ＹＥＳ”であれば、つまり変数ａ１がロックされていれば、ステップＳ１０５で、今回変数ａ１のロックを要求してきたシーンビジターの要求を拒否して、ステップＳ１２５に進む。つまり、ステップＳ１０５では、今回変数ａ１のロックを要求してきたシーンビジターに要求拒否を通知する。一方、ステップ１０３で“ＮＯ”であれば、つまり変数ａ１がロックされていなければ、ステップＳ１０７で、変数ａ１をロックして、ステップＳ１０９で、他のシーンビジターが同時に変数ａ１のロックを要求しているかどうかを判断する。

ステップＳ１０９で“ＹＥＳ”であれば、つまり、他のシーンビジターが同時に変数ａ１のロックを要求している場合には、ステップＳ１１１で、通信ＩＤの小さいシーンビジターに変数ａ１をロックしたことを通知し、ステップＳ１１３で、他のシーンビジターに要求拒否の通知をして、ステップＳ１１７に進む。一方、ステップＳ１０９で“ＮＯ”であれば、つまり他のシーンビジターが同時に変数ａ１のロックを要求していない場合には、ステップＳ１１５で、シーンビジターに変数ａ１をロックしたことを通信して、ステップＳ１１７に進む。

ステップＳ１１７では、シーンビジターから変数ａ１の変更要求を受信する。ただし、このシーンビジターは、変数ａ１のロックを通知したシーンビジターである。続くステップＳ１１９では、自機のシーン共有データ内の変数ａ１を変更し、ステップＳ１２１で、ゲームに参加しているすべてのゲーム装置１０に変数ａ１の変更を指示する。そして、ステップＳ１２３で、変数ａ１のロックを解除し、ステップＳ１２５に進む。

図２０に示すステップＳ１２５では、自機のシーン固有データ（ここでは、説明の便宜上、「変数ｎ１」とする。）を変更する。続くステップＳ１２７では、同じシーン内の全てのシーンビジターに変数ｎ１の変更を指示する。そして、ステップＳ１２９では、他のシーンのシーンホストからシーン共有データ（ここでは、説明の便宜上、「変数ａ２」とする。）の変更指示を受信したかどうかを判断する。ステップＳ１２９で“ＮＯ”であれば、つまり変数ａ２の変更指示を受信していなければ、そのまま、シーンホストの場合におけるゲームデータ更新処理をリターンする。しかし、ステップＳ１２９で“ＹＥＳ”であれば、つまり変数ａ２の変更指示を受信すれば、ステップＳ１３１で、変数ａ２を変更して、シーンホストの場合におけるゲームデータ更新処理をリターンする。

図２１および図２２は、シーンビジターの場合におけるゲームデータ更新処理（上述したステップＳ３５，Ｓ６９，Ｓ８９）を示すフロー図である。このゲーム処理は、ネットワーク親機またはネットワーク子機に拘わらず、シーンにおける子機（シーンビジター）である場合に実行される。図２１に示すように、ＣＰＵコア４２は、シーンビジターの場合におけるゲームデータ更新処理を開始すると、ステップＳ１４１で、変数ａ１すなわちシーン共有データを書き換えるかどうかを判断する。つまり、ゲームの進行により、シーン共有データ（ここでは、「変数ａ１」）を書き換える必要性があるかどうかを判断する。ステップＳ１４１で“ＮＯ”であれば、つまり変数ａ１を書き換えない場合には、そのままステップＳ１５１に進む。しかし、ステップＳ１４１で“ＹＥＳ”であれば、つまり変数ａ１を書き換える場合には、ステップＳ１４３で、シーンホストへ変数ａ１のロックを要求する。

続くステップＳ１５５では、シーンホストからロック通知を受信したかどうかを判断する。ステップＳ１４５で“ＹＥＳ”であれば、つまりシーンホストからロック通知を受信すれば、ステップＳ１４７で、シーンホストへ変数ａ１の変更を要求して、ステップＳ１５１に進む。しかし、ステップＳ１４５で“ＮＯ”であれば、つまりシーンホストからロック通知がなければ、ステップＳ１４９で、シーンホストから要求拒否を受信したかどうかを判断する。ステップＳ１４９で“ＮＯ”であれば、つまり要求拒否を受信していなければ、そのまま図２２に示すステップＳ１５５に進む。しかし、ステップＳ１４９で“ＹＥＳ”であれば、つまり要求拒否を受信すれば、ステップＳ１５１に進む。

ステップＳ１５１では、変数ａ１の変更指示を受信したかどうかを判断する。つまり、他のシーンのシーンホスト（他のゲーム装置１０）から変数ａ１の変更指示があるかどうかを判断する。ステップＳ１５１で“ＮＯ”であれば、つまり変数ａ１の変更指示がなければ、そのままステップＳ１５５に進む。しかし、ステップＳ１５１で“ＹＥＳ”であれば、ステップＳ１５３で、自機のシーン共有データ内の変数ａ１を変更して、ステップＳ１５５に進む。

図２２に示すように、ステップＳ１５５では、シーンホストから変数ｎ１すなわちシーン固有データの変更指示を受信したかどうかを判断する。ステップＳ１５５で“ＮＯ”であれば、つまり変数ｎ１の変更指示を受信していなければ、そのままステップＳ１５９に進む。しかし、ステップＳ１５５で“ＹＥＳ”であれば、つまり変数ｎ１の変更指示を受信すれば、ステップＳ１５７で、自機のシーン固有データ内の変数ｎ１を変更し、ステップＳ１５９に進む。

ステップＳ１５９では、他のシーン（ここでは、シーン２）のシーンホストから変数ａ２の変更指示を受信したかどうかを判断する。ステップＳ１５９で“ＮＯ”であれば、つまり変数ａ２の変更指示を受信していなければ、そのまま、シーンビジターの場合におけるゲームデータ更新処理をリターンする。しかし、ステップＳ１５９で“ＹＥＳ”であれば、つまり変数ａ２の変更指示を受信すれば、ステップＳ１６１で、自機のシーン共有データ内の変数ａ２を変更して、シーンビジターの場合におけるゲームデータ更新処理をリターンする。

図２３は、上述したステップＳ２３およびステップＳ７７におけるシーン情報更新処理を示すフロー図である。この図２３を参照して、ＣＰＵコア４２は、シーン情報更新処理を開始すると、ステップＳ１７１で、自機が他のシーンへ移動したかどうかを判断する。ステップＳ１７１で“ＹＥＳ”であれば、つまり自機が他のシーンへ移動すれば、ステップＳ１７５で、シーン情報すなわちシーン番号データ７８０およびシーンホストデータ７８２の少なくとも一方を更新する。以下、同じ。しかし、ステップＳ１７１で“ＮＯ”であれば、つまり自機が他のシーンへ移動していなければ、ステップＳ１７３で、自機がシーンホストに変わったかどうかを判断する。

ステップＳ１７３で“ＮＯ”であれば、つまりシーンホストに変わっていなければ、図２４に示すステップＳ１８７に進む。しかし、ステップＳ１７３で“ＹＥＳ”であれば、つまりシーンホストに変わっていれば、シーンホストデータ７８２を更新すべく、ステップＳ１７５に進む。

ステップＳ１７５でシーン情報を更新すると、ステップＳ１７７で、自機がネットワーク親機であるかどうかを判断する。ステップＳ１７７で“ＹＥＳ”であれば、つまり自機がネットワーク親機であれば、ステップＳ１７９で、すべてのネットワーク子機に、シーン情報を送信して、シーン情報更新処理をリターンする。一方、ステップＳ１７７で“ＮＯ”であれば、つまり自機がネットワーク子機であれば、ステップＳ１８１で、ネットワーク親機にシーン情報を送信する。

続いて、ステップＳ１８３では、ネットワーク親機からシーン情報を受信したかどうかを判断する。ステップＳ１８３で“ＮＯ”であれば、つまりネットワーク親機からシーン情報を受信しなければ、そのままシーン情報更新処理をリターンする。しかし、ステップＳ１８３で“ＹＥＳ”であれば、つまりネットワーク親機からシーン情報を受信すれば、ステップＳ１８５で、シーン情報を更新して、シーン情報更新処理をリターンする。

上述したように、ステップＳ１７３で“ＮＯ”であれば、図２４に示すステップＳ１８７で、自機がネットワーク親機であるかどうかを判断する。ステップＳ１８７で自機がネットワーク親機でなければ、そのまま図２３に示したステップＳ１８３に進む。しかし、ステップＳ１８７で“ＹＥＳ”であれば、つまり自機がネットワーク親機であれば、ステップＳ１８９で、ネットワーク子機からシーン情報を受信したかどうかを判断する。ステップＳ１８９で“ＮＯ”であれば、つまりネットワーク子機からシーン情報を受信していなければ、図２３に示したように、シーン情報更新処理をリターンする。一方、ステップＳ１８９で“ＹＥＳ”であれば、つまりネットワーク子機からシーン情報を受信すれば、ステップＳ１９１で、シーン情報を更新して、図２３に示したステップＳ１７９に戻る。

図２５および図２６は、シーン移動処理を示すフロー図である。このシーン移動処理は、ネットワーク親機またはネットワーク子機に拘わらず共通である。また、シーン移動処理は、システム１００を構成する各ゲーム装置１０で実行される通信ゲームにおいて、ユーザによってシーン移動の指示が与えられたり、所定のイベントが発生したりすることにより、割り込みで実行される。したがって、このシーン移動処理の実行中では、通信ゲームの処理は、一時停止される。

図２５を参照して、ＣＰＵコア４２は、シーン移動処理を開始すると、ステップＳ２０１で、自機がネットワーク親機であるかどうかを判断する。ステップＳ２０１で“ＹＥＳ”であれば、つまり自機がネットワーク親機であれば、そのまま図２６に示すステップＳ２０７に進む。しかし、ステップＳ２０１で“ＮＯ”であれば、つまり自機がネットワーク子機であれば、ステップＳ２０３で、ネットワーク親機にシーン切替を要求する。そして、ステップＳ２０５で、シーン切替許可を受信したかどうかを判断する。ステップＳ２０５で“ＮＯ”であれば、つまりシーン切替許可を受信していなければ、同じステップＳ２０５に戻って、シーン切替許可の受信を待機する。図示は省略するが、後述するように、シーン切替許可を受信しない場合には、シーン切替待機を受信する。したがって、ステップＳ２０５に戻るのである。一方、ステップＳ２０５で“ＹＥＳ”であれば、つまりシーン切替許可を受信すれば、ステップＳ２０７に進む。

図２６に示すように、ステップＳ２０７では、自機が現在のシーンのシーンホストかどうかを判断する。ステップＳ２０７で“ＮＯ”であれば、つまり自機が現在のシーンのシーンビジターであれば、そのままステップＳ２１５に進む。一方、ステップＳ２０７で“ＹＥＳ”であれば、つまり自機が現在のシーンのシーンホストであれば、ステップＳ２０９で、現在のシーンにシーンビジターが存在するかどうかを判断する。つまり、シーン情報に含まれるシーン番号データ７８０を参照して、自機のシーン番号と同じシーン番号のゲーム装置１０が存在するかどうかを判断するのである。

ステップＳ２０９で“ＮＯ”であれば、つまり現在のシーンにシーンビジターが存在しない場合には、そのままステップＳ２１５に進む。しかし、ステップＳ２０９で“ＹＥＳ”であれば、つまり現在のシーンにシーンビジターが存在する場合には、ステップＳ２１１で、現在のシーンのシーンビジター（すべてのシーンビジター）に通信処理の一時停止を指示する。図示は省略するが、このとき、通信ゲームの一時停止も指示される。次のステップＳ２１３では、通信ＩＤの最も小さいシーンビジターに現在のシーンのシーンホストになることを要求する。

続いて、ステップＳ２１５では、現在のシーンのシーン固有データをＲＡＭ４８上から破棄し、ステップＳ２１７で、他のシーンに移動して、シーン移動処理をリターンする。

なお、図示は省略するが、シーンを移動する場合（シーンに参加する場合も同じ。）に、移動後のシーンに他のゲーム装置１０が存在する場合には、自機をシーンビジターとして設定し、また、移動後のシーンに他のゲーム装置１０が存在しない場合には、自機をシーンホストとして設定する。これは、上述したように、ＣＰＵコア４２がシーン情報を更新することにより、設定される。

図２７は、シーンホストがシーンから抜ける場合のシーンビジターの処理を示すフロー図である。この処理は、ゲーム装置１０がシーンビジターである場合に、一定時間毎に実行する。図２７を参照して、ＣＰＵコア４２は、シーンホストがシーンから抜ける場合の処理を開始すると、ステップＳ２３１で、シーンホストから一時停止の指示を受信したかどうかを判断する。ステップＳ２３１で“ＮＯ”であれば、つまりシーンホストから一時停止の指示を受信していなければ、そのままシーンホストがシーンから抜ける場合の処理を終了する。

しかし、ステップＳ２３１で“ＹＥＳ”であれば、つまりシーンホストから一時停止の指示を受信すれば、ステップＳ２３３で、通信処理を一時停止する。また、このとき、通信ゲームの処理も一時停止する。次のステップＳ２３５では、シーンホストへ送信するデータをバッファに蓄積する。続くステップＳ２３７では、シーンホストになることを要求されたかどうかを判断する。ステップＳ２３７で“ＹＥＳ”であれば、つまりシーンホストになることを要求されれば、ステップＳ２３９で、シーンホストとして通信処理を再開する。このとき、通信ゲームも再開する。そして、ステップＳ２４１で、シーンビジターに通信処理の再開を指示し、ステップＳ２４３で、バッファに蓄積しているデータを処理し、シーンホストがシーンから抜ける場合の処理を終了する。

なお、ステップＳ２３９で、シーンホストとして通信処理を再開したとき、現在のシーンにシーンビジターが存在しない場合には、ステップＳ２４１の処理は実行されず、そのままステップＳ２４３の処理が実行される。

また、ステップＳ２３７で“ＮＯ”であれば、つまりシーンホストになることを要求されていなければ、ステップＳ２４５で、シーンホストから通信処理の再開指示を受信したかどうかを判断する。ステップＳ２４５で“ＮＯ”であれば、つまりシーンホストから通信処理の再開指示を受信していなければ、そのままステップＳ２３７に戻る。一方、ステップＳ２４５で“ＹＥＳ”であれば、つまりシーンホストから通信処理の再開指示を受信すれば、ステップＳ２４７で、シーンビジターとして通信処理を再開する。このとき、通信ゲームの処理も再開する。そして、ステップＳ２４９で、バッファに蓄積しているデータをシーンホストに送信して、シーンホストがシーンから抜ける場合の処理を終了する。

図２８は、ネットワーク親機におけるシーン切替管理処理を示すフロー図である。つまり、ネットワーク親機は、図１５および図１６に示した通信処理および通信ゲームの処理に加えて、シーン切替管理処理を並列的に実行しているのである。図２８を参照して、ＣＰＵコア４２は、シーン切替処理を開始すると、ステップＳ２６１で、ネットワーク子機からシーン切替要求を受信したかどうかを判断する。ステップＳ２６１で“ＮＯ”であれば、つまりネットワーク子機からシーン切替要求を受信していなければ、そのままシーン切替処理を終了する。

しかし、ステップＳ２６１で“ＹＥＳ”であれば、つまりネットワーク子機からシーン切替要求を受信すれば、ステップＳ２６３で、他のネットワーク子機からシーン切替要求を同時に受信したかどうかを判断する。ただし、厳密に同時である場合のみならず、数μ秒程度のずれがある場合も含む。ステップＳ２６３で“ＮＯ”であれば、つまり他のネットワーク子機からシーン切替要求を同時に受信していなければ、ステップＳ２６５で、シーン切替要求のあったネットワーク子機にシーン切替許可を通知して、シーン切替管理処理を終了する。

また、ステップＳ２６３で“ＹＥＳ”であれば、つまり他のネットワーク子機からシーン切替要求を同時に受信すれば、ステップＳ２６７で、通信ＩＤの小さいネットワーク子機に切替許可を通知し、ステップＳ２６９で、他のネットワーク子機にシーン切替待機を指示して、シーン切替管理処理を終了する。

この実施例によれば、仮想ゲーム空間に含まれるシーン毎にシーンホストを決定して、各シーンホストで処理を分担するようにするので、ネットワーク親機のみに処理負担が集中することがない。このため、通信するゲーム装置の数が増えた場合であっても、ネットワーク親機の処理負担が増大することがなく、通信効率が低下するのを防止することができる。また、シーン固有データについては、自機が参加しているシーンの固有データのみを記憶すればよいので、仮想ゲーム空間を構成するシーンの数が増えてもメモリ容量が著しく増加することがなく、メモリの効率化を図ることができる。

なお、この実施例では、表示器が一体的に形成されたゲーム装置を用いてシステムを構成する場合について示したが、表示器が別に設けられたゲーム装置によってシステムを構成する場合にも適用できる。

また、この実施例では、各ゲーム装置を無線接続するようにしたが、これに限定される必要はなく、有線接続するようにしてもよいし、インターネット網等を用いて接続するようにしてもよい。

さらに、ゲーム装置の構成は、上述の実施例の構成に限定されるべきでない。たとえば、ＬＣＤは１つでもよく、タッチパネルは２つのＬＣＤのそれぞれに設けるようにしてもよい。さらに、左右２つのスピーカを設けるようにしてもよい。

図１はこの発明のゲームシステムを示す図解図である。 図２は図１実施例に示すゲーム装置の一例を示す図解図である。 図３は図２に示すゲーム装置の電気的な構成を示すブロック図である。 図４は図１実施例のゲームシステムでプレイする通信ゲームの仮想空間２００をシーン毎に分けて示した平面図である。 図５は図１実施例のゲームシステムでプレイする通信ゲームにおいてシーンビジターがシーンを移動する様子の一例を示す図解図である。 図６は図１実施例のゲームシステムでプレイする通信ゲームにおいてシーンビジターがシーンを移動する様子の他の例を示す図解図である。 図７は図１実施例のゲームシステムでプレイする通信ゲームにおいてシーンホストがシーンを移動する様子の一例を示す図解図である。 図８は図１実施例のゲームシステムでプレイする通信ゲームにおいてシーンホストがシーンを移動する様子の他の例を示す図解図である。 図９は図１実施例のゲームシステムでプレイする通信ゲームにおいて、シーンビジターがシーン共有データの変更を要求する状態を示す図解図である。 図１０は図１実施例のゲームシステムでプレイする通信ゲームにおいて、シーンホストが、図９に示したシーンビジターの要求に応じてシーン共有データを変更し、その後、シーン共有データの変更をすべてのゲーム装置に指示する状態を示す図解図である。 図１１は図１実施例のゲームシステムでプレイする通信ゲームにおいて、図１０に示したシーンホストの指示に応じてすべてのゲーム装置でシーン共有データが変更された状態を示す図解図である。 図１２は図１実施例のゲームシステムでプレイする通信ゲームにおいて、シーンホストがシーンビジターにシーン固有データの変更を指示した状態を示す図解図である。 図１３は図１実施例のゲームシステムでプレイする通信ゲームにおいて、図１２に示したシーンホストの指示に応じてシーンビジターのシーン固有データが更新された状態を示す図解図である。 図１４は図３に示すＲＡＭのメモリマップを示す図解図である。 図１５はネットワーク親機の通信処理の一部を示すフロー図である。 図１６はネットワーク親機の通信処理の他の一部であり、図１５に後続するフロー図である。 図１７はネットワーク子機の通信処理の一部を示すフロー図である。 図１８はネットワーク子機の通信処理の他の一部であり、図１７に後続するフロー図である。 図１９はシーンホストの場合におけるゲームデータ更新処理の一部を示すフロー図である。 図２０はシーンホストの場合におけるゲームデータ更新処理の他の一部であり、図１９に後続するフロー図である。 図２１はシーンビジターの場合におけるゲームデータ更新処理の一部を示すフロー図である。 図２２はシーンビジターの場合におけるゲームデータ更新処理の他の一部であり、図２１に後続するフロー図である。 図２３はシーン情報更新処理の一部を示すフロー図である。 図２４はシーン情報更新処理の他の一部を示すフロー図である。 図２５はシーン移動処理の一部を示すフロー図である。 図２６はシーン移動処理の他の一部であり、図２５に後続するフロー図である。 図２７はシーンホストがシーンから抜ける場合のシーンビジターの処理を示すフロー図である。 図２８はネットワーク親機のシーン切替管理処理を示すフロー図である。

符号の説明

１０ …ゲーム装置
１２，１４ …ＬＣＤ
１６，１６ａ，１６ｂ …ハウジング
２０ …操作スイッチ
２２ …タッチパネル
２４ …スティック
２８ …メモリカード
２８ａ …ＲＯＭ
２８ｂ，４８ …ＲＡＭ
３２ …アンテナ
４０ …電子回路基板
４２ …ＣＰＵコア
５０，５２ …ＧＰＵ
５４ …Ｉ／Ｆ回路
５６，５８ …ＶＲＡＭ
６０ …ＬＣＤコントローラ
６４ …無線通信ユニット
１００ …ゲームシステム

Claims (20)

1. 通信機能を備えた複数のゲーム装置によって構成され、複数のシーンを含む仮想ゲーム空間内のいずれかのシーンに当該複数のゲーム装置の各々がプレイヤとして参加してプレイするゲームシステムであって、
   各々の前記ゲーム装置は、
   すべての前記ゲーム装置で共有すべき共有ゲームデータを記憶する共有ゲームデータ記憶手段、
   自機が参加している前記シーンのみで共有すべきシーン固有の固有ゲームデータを記憶する固有ゲームデータ記憶手段、
   参加するシーンに他の前記ゲーム装置が参加していないとき、自機を当該シーンの親機として設定する親機設定手段、
   参加するシーンに他の前記ゲーム装置が参加しているとき、自機を当該シーンの子機として設定する子機設定手段、
   前記親機設定手段によって自機が前記シーンの親機として設定されたとき、少なくとも、前記共有ゲームデータの更新を自機以外のすべてのゲーム装置に指示し、または、前記固有ゲームデータの更新を当該シーンに参加しているすべての子機に指示する親機処理手段、および
   前記子機設定手段によって自機が前記シーンの子機として設定されたとき、少なくとも、前記親機からの指示に従って前記固有ゲームデータを更新する子機処理手段を含む、ゲームシステム。
2. 前記子機処理手段は、前記共有ゲームデータの更新を自機が参加する前記シーンの前記親機に要求する共有ゲームデータ更新要求手段を含み、
   前記親機処理手段は、前記子機からの前記共有ゲームデータの更新要求を受けて、前記共有ゲームデータの更新を自機以外のすべての前記ゲーム装置に指示する、請求項１記載のゲームシステム。
3. 前記ゲーム装置は、他の前記ゲーム装置から前記共有ゲームデータの更新指示を受信する更新指示受信手段、および前記更新指示手段によって前記共有ゲームデータの更新指示を受信したことに応じて前記共有ゲームデータを更新する共有ゲームデータ更新手段をさらに含む、請求項１または２記載のゲームシステム。
4. 前記ゲーム装置は、他のシーンに移動するとき、自機が親機である場合に現在のシーンに子機が存在するか否かを判断する子機有無判断手段、および前記子機有無判断手段によって現在のシーンに子機が存在すると判断されたとき所定のルールに従って選択した１の子機に親機になることを要求する親機設定要求手段をさらに含む、請求項１ないし３のいずれかに記載のゲームシステム。
5. 前記ゲーム装置は、他の前記ゲーム装置から親機になることを要求されたかどうかを判断する親機設定要求判断手段、および前記親機設定要求判断手段によって親機になることを要求されたと判断されたとき、自機を親機として設定する設定変更手段をさらに含む、請求項４記載のゲームシステム。
6. 前記ゲーム装置は、各々の前記ゲーム装置が参加しているシーンについてのシーン識別情報および各々の前記ゲーム装置が親機または子機のいずれに設定されているかを示す親子設定情報を含むシーン情報を記憶するシーン情報記憶手段をさらに含む、請求項１ないし５のいずれかに記載のゲームシステム。
7. 前記ゲーム装置は、少なくとも、他のシーンに移動したとき、前記シーン情報を更新するシーン情報更新手段をさらに含む、請求項６記載のゲームシステム。
8. 複数のシーンを含む仮想空間にプレイヤとして参加し、通信ゲームをプレイするゲーム装置であって、
   前記通信ゲームを行うすべてのゲーム装置で共有すべき共有ゲームデータを記憶する共有ゲームデータ記憶手段、
   自機が参加している前記シーンのみで共有すべきシーン固有の固有ゲームデータを記憶する固有ゲームデータ記憶手段、
   参加するシーンに他の前記ゲーム装置が参加していないとき、自機を当該シーンの親機として設定する親機設定手段、
   参加するシーンに他の前記ゲーム装置が参加しているとき、自機を当該シーンの子機として設定する子機設定手段、
   前記親機設定手段によって自機が前記シーンの親機として設定されたとき、少なくとも、前記共有ゲームデータの更新を自機以外のすべてのゲーム装置に指示し、または、前記固有ゲームデータの更新を当該シーンに参加しているすべての子機に指示する親機処理手段、および
   前記子機設定手段によって自機が前記シーンの子機として設定されたとき、少なくとも、前記親機からの指示に従って前記固有ゲームデータを更新する子機処理手段を備える、ゲーム装置。
9. 前記子機処理手段は、前記共有ゲームデータの更新を自機が参加する前記シーンの前記親機に要求する共有ゲームデータ更新要求手段を含み、
   前記親機処理手段は、前記子機からの前記共有ゲームデータの更新要求を受けて、前記共有ゲームデータの更新を自機以外のすべての前記ゲーム装置に指示する、請求項８記載のゲーム装置。
10. 他の前記ゲーム装置から前記共有ゲームデータの更新指示を受信する更新指示受信手段、および前記更新指示手段によって前記共有ゲームデータの更新指示を受信したことに応じて前記共有ゲームデータを更新する共有ゲームデータ更新手段をさらに備える、請求項８または９記載のゲーム装置。
11. 他のシーンに移動するとき、自機が親機である場合に現在のシーンに子機が存在するか否かを判断する子機有無判断手段、および前記子機有無判断手段によって現在のシーンに子機が存在すると判断されたとき所定のルールに従って選択した１の子機に親機になることを要求する親機設定要求手段をさらに備える、請求項８ないし１０のいずれかに記載のゲーム装置。
12. 他の前記ゲーム装置から親機になることを要求されたかどうかを判断する親機設定要求判断手段、および前記親機設定要求判断手段によって親機になることを要求されたと判断されたとき、自機を親機として設定する設定変更手段をさらに備える、請求項１１記載のゲーム装置。
13. 各々の前記ゲーム装置が参加しているシーンについてのシーン識別情報および各々の前記ゲーム装置が親機または子機のいずれに設定されているかを示す親子設定情報を含むシーン情報を記憶するシーン情報記憶手段をさらに備える、請求項８ないし１２のいずれかに記載のゲーム装置。
14. 少なくとも、他のシーンに移動したとき、前記シーン情報を更新するシーン情報更新手段をさらに備える、請求項１３記載のゲーム装置。
15. 複数のシーンを含む仮想空間にプレイヤとして参加し、通信ゲームをプレイするゲーム装置のゲームプログラムであって、
    前記ゲーム装置は、前記通信ゲームを行うすべてのゲーム装置で共有すべき共有ゲームデータを記憶する共有ゲームデータ記憶手段、および自機が参加している前記シーンのみで共有すべきシーン固有の固有ゲームデータを記憶する固有ゲームデータ記憶手段を備え、
    前記ゲームプログラムは、前記ゲーム装置のプロセサに、
    参加するシーンに他の前記ゲーム装置が参加していないとき、自機を当該シーンの親機として設定する親機設定ステップ、
    参加するシーンに他の前記ゲーム装置が参加しているとき、自機を当該シーンの子機として設定する子機設定ステップ、
    前記親機設定ステップによって自機が前記シーンの親機として設定されたとき、少なくとも、前記共有ゲームデータの更新を自機以外のすべてのゲーム装置に指示し、または、前記固有ゲームデータの更新を当該シーンに参加しているすべての子機に指示する親機処理ステップ、および
    前記子機設定ステップによって自機が前記シーンの子機として設定されたとき、少なくとも、前記親機からの指示に従って前記固有ゲームデータを更新する子機処理ステップを実行させる、ゲームプログラム。
16. 前記子機処理ステップは、前記共有ゲームデータの更新を自機が参加する前記シーンの前記親機に要求する共有ゲームデータ更新要求ステップを含み、
    前記親機処理ステップは、前記子機からの前記共有ゲームデータの更新要求を受けて、前記共有ゲームデータの更新を自機以外のすべての前記ゲーム装置に指示する、請求項１５記載のゲームプログラム。
17. 他の前記ゲーム装置から前記共有ゲームデータの更新指示を受信する更新指示受信ステップ、および前記更新指示ステップによって前記共有ゲームデータの更新指示を受信したことに応じて前記共有ゲームデータを更新する共有ゲームデータ更新ステップをさらに実行させる、請求項１５または１６記載のゲームプログラム。
18. 他のシーンに移動するとき、自機が親機である場合に現在のシーンに子機が存在するか否かを判断する子機有無判断ステップ、および前記子機有無判断ステップによって現在のシーンに子機が存在すると判断されたとき所定のルールに従って選択した１の子機に親機になることを要求する親機設定要求ステップをさらに備える、請求項１５ないし１７のいずれかに記載のゲームプログラム。
19. 他の前記ゲーム装置から親機になることを要求されたかどうかを判断する親機設定要求判断ステップ、および前記親機設定要求判断ステップによって親機になることを要求されたと判断されたとき、自機を親機として設定する設定変更ステップをさらに備える、請求項１８記載のゲームプログラム。
20. 前記ゲーム装置は、各々の前記ゲーム装置が参加しているシーンについてのシーン識別情報および各々の前記ゲーム装置が親機または子機のいずれに設定されているかを示す親子設定情報を含むシーン情報を記憶するシーン情報記憶手段をさらに備え、
    少なくとも、他のシーンに移動したとき、前記シーン情報を更新するシーン情報更新ステップをさらに実行させる、請求項１５ないし請求項１９のいずれかに記載のゲームプログラム。

Images