JP2008200137A - ネットワークゲームシステム - Google Patents

Abstract

【課題】ネットワークを介して相互に接続されている複数のゲーム装置の間で、一方のゲーム装置に設定されている地域に関する気象状況を、他方のゲーム装置における仮想ゲーム空間に反映させて楽しむことができるネットワークゲームシステムを提供すること。
【解決手段】配信サーバは、気象データを第１のゲーム装置に対して配信する。第１のゲーム装置では、地域データ設定手段により設定された地域データに対応する気象データを配信サーバから取得して、第２のゲーム装置に送信する。更に、当該取得した気象データを用いて第２のゲーム装置との間で通信ゲームを実行する。また、第２のゲーム装置は、第１ゲーム装置から送信された気象データを受信する。そして、受信した気象データを用いて第１のゲーム装置との間で通信ゲームを実行する。
【選択図】図１０

Description

本発明は、ネットワークゲームシステムに関し、より特定的には、相互に通信可能に通信ネットワークに接続された複数のゲーム装置と、当該複数のゲーム装置とネットワークを介して接続され、かつ当該複数のゲーム装置にデータの配信を行う配信サーバとを含むネットワークゲームシステムに関する。

従来より、交通情報や天気予報等の情報を用いて、リアルなシミュレーションを行う装置が開示されている（例えば、特許文献１）。このような装置では、交通情報、気象情報、スポーツ等のイベント中継等の提供データを、テレビやインターネット等の各種通信媒体を通じて取得する。そして、当該取得したデータを各種のシミュレーションを行う基本データと組み合わせ、表示画面上でシミュレーションを実行している。これにより、現実の交通情報を反映したレースゲームや、自動車教習用の学習機として高速道路等の運転操作のシミュレーターが実行可能であった。
特開２００１−２２２６４号公報

しかしながら、上述したような上記特許文献１に開示された装置においては、従来から以下に示す問題点があった。例えば、あるゲーム装置単体に対して、上述のような交通情報や気象情報の提供が行われたとしても、当該提供を受けたゲーム装置自体に設定されている場所や時間等のデータに対応した上記各種情報を用いるだけしかできなかった。

それ故に、本発明の目的は、ネットワークを介して相互に接続されている複数のゲーム装置の間で、一方のゲーム装置に設定されている地域に関する気象状況を、他方のゲーム装置における仮想ゲーム空間に反映させて楽しむことができるネットワークゲームシステムを提供することである。

本発明は、上記の課題を解決するために、以下の構成を採用した。なお、括弧内の参照符号および補足説明等は、本発明の理解を助けるために後述する実施形態との対応関係の一例を示したものであって、本発明を何ら限定するものではない。

第１の発明は、相互に通信可能な複数のゲーム装置（３）と、当該複数のゲーム装置のうちの少なくとも１つのゲーム装置である第１のゲーム装置（３ａ）に通信ネットワークを介して接続され、地域ごとの気象データを配信可能な配信サーバ（４０）とを含むネットワークゲームシステムである。配信サーバは、配信手段（４３，４４）を備えており、複数の地域データごとの気象データを記憶し、第１ゲーム装置に気象データを配信する。第１のゲーム装置は、地域データ設定手段（１０）と、気象データ取得手段（１８）と、第１のゲーム処理手段（１０）とを備える。地域データ設定手段は、地域データを設定する。気象データ取得手段は、配信サーバから、地域データ設定手段により設定された地域データに対応する気象データを取得する。気象データ送信手段は、気象データ取得手段で取得した気象データを、複数のゲーム装置のうち当該第１のゲーム装置とは異なる第２のゲーム装置（３ｂ）に送信する。第１のゲーム処理手段は、気象データ取得手段で取得した気象データを用いて、第２のゲーム装置との間で通信ゲームを実行する。第２のゲーム装置は、気象データ受信手段（１８）と、第２のゲーム処理手段（１０）を備える。気象データ受信手段は、気象データ送信手段から送信される気象データを受信する。第２のゲーム処理手段は、気象データ受信手段で受信した気象データを用いて、前記第１のゲーム装置との間で通信ゲームを実行する。上記のような構成において、第１のゲーム装置は配信サーバから気象データを取得する。このとき、配信サーバから複数の地域データに対応する複数の気象データを受信し、当該受信した気象データの中から自己の地域データに一致する気象データを取得してもよいし、配信サーバに自己の地域データを送信し、当該地域データに一致する気象データを配信サーバから受信してもよい。なお、第２のゲーム装置においても地域データを設定し、配信サーバから当該地域データに対応する気象データを取得してもかまわない。また、第１のゲーム装置は、典型的には、気象データ取得手段で取得した気象データを利用して、気象情報をユーザに提示（典型的には、画面に気象情報を表示）する気象情報提示手段を有するが、この手段を有しなくてもかまわない。ユーザは気象情報提示手段を起動することにより、気象データ取得手段により取得した気象データを用いて、自己の地域の気象情報を知ることができる。なお、配信サーバから複数の地域データに対応する複数の気象データを受信するようにすれば（すなわち、自己の地域データ以外の気象データを受信するようにすれば）、自己以外の地域の気象情報をユーザに提示することができる。例えば、気象情報提示手段は、ディスク４またはフラッシュメモリ１７に記憶される気象情報表示プログラムであり、このプログラムをＣＰＵ１０が実行することにより、気象情報がユーザに提示される。ディスク４（気象情報表示プログラムが記憶されるディスクと同じでもよいし異なるディスクでもよい）またはフラッシュメモリ１７には、通信ゲームプログラム（このプログラムは、ＣＰＵ１０を第１のゲーム処理手段または第２のゲーム処理手段として機能させる）が記憶され、このプログラムをＣＰＵ１０が実行することにより、通信ゲームプログラムが実行される。気象情報表示プログラムは、ゲーム装置に不揮発的に記憶し、通信ゲームプログラムはディスク４に記憶しておいてもよい。ユーザは、気象情報表示プログラムと通信ゲームプログラムを選択的に起動することができる。地域データ設定手段は、気象情報表示プログラムに含まれるプログラムが、ＣＰＵ１０を地域データ設定手段として機能させてもよく、さらには、通信ゲームプログラムには、ＣＰＵ１０を地域データ設定手段として機能させるプログラムを含まないようにしてもよい。また、第１のゲーム装置と第２のゲーム装置は、ネットワークを介して互いに通信するが、サーバを介してもよいし、サーバを介さずに直接通信するものでもかまわない。第１のゲーム装置と第２のゲーム装置は、それぞれ、通信ゲームを実行する旨のユーザ操作がされたものであり、接続要求とそれに対する応答を互いに直接通信することにより、または、サーバによる仲介により、互いに接続し、通信ゲームを実行する。また、気象データ送信手段と気象データ受信手段は、気象データをゲーム装置間で直接通信してもよいし、サーバを介して通信してもよい。また、第１のゲーム処理手段および第２のゲーム処理手段は、それぞれ、第１のゲーム処理手段の気象データ取得手段で取得した気象データを使用して、通信ゲームを実行する。このとき、第１のゲーム装置は、自己の気象データ取得手段で取得した気象データを使用するとともに、当該気象データを第２のゲーム装置に送信し、第２のゲーム装置は、第１のゲーム装置から当該気象データを受信して、当該受信した気象データを使用する。

第２の発明は、第１の発明において、第２のゲーム装置は、気象データ受信手段で受信した気象データを用いて、気象情報をユーザに提示しつつ、第１のゲーム装置と通信ゲームを実行するか否かをユーザに選択させる選択手段（１０）と、選択手段により第１のゲーム装置と通信ゲームを実行することが選択されたときに、第１のゲーム装置と接続する第１の接続手段（１８）をさらに備える。また、第２のゲーム処理手段は、第１の接続手段により接続したゲーム装置と通信して、通信ゲームを実行する。また、第１のゲーム装置は、選択手段により第１のゲーム装置と通信ゲームを実行することが選択された第２ゲーム装置と接続する第２の接続手段をさらに備える。更に、第１のゲーム処理手段は、第２の接続手段により接続したゲーム装置と通信して、通信ゲームを実行する。例えば、第１のゲーム装置のユーザが他のゲーム装置と通信ゲームを実行することを希望する操作をおこなったときに、第１のゲーム装置の気象データ送信手段は、サーバを介して、または、サーバを介さずに直接、第２のゲーム装置に対して、気象データを送信する。第２のゲーム装置の気象データ受信手段は、気象データを受信して、当該気象データを用いて、気象情報をユーザに提示しつつ、第１のゲーム装置と通信ゲームを実行するか否かをユーザに選択させる。これにより、通信ゲームで用いられる気象データを考慮して、通信ゲームの相手を選択することができる。なお、気象データ受信手段は、複数の第１のゲーム装置から気象データを受信可能とし、各気象データごとの気象情報をユーザに提示しつつ、いずれかの第１のゲーム装置と通信ゲームを実行するかをユーザに選択させてもかまわない。なお、第１ゲーム装置は、気象データとともにユーザ名データを送信し、第２ゲーム装置は、気象データとユーザ名データを受信して、気象情報とともに当該ユーザ名データを用いてユーザ名情報を表示しつつ、ユーザに上記選択をさせてもかまわない。第１の接続手段および第２の接続手段は、互いの識別情報を直接通信することにより接続し、または、サーバを介して接続する。

第３の発明は、第１の発明において、第１のゲーム装置は、地域データ設定手段で設定した地域データを、第２のゲーム装置に送信する接続受付情報送信手段（１８）をさらに備える。また、第２のゲーム装置は、地域データを受信する地域データ受信手段（１８）と、地域データ受信手段で受信した地域データを用いて、地域情報をユーザに提示しつつ、第１のゲーム装置と通信ゲームを実行するか否かをユーザに選択させる選択手段（１０）と、選択手段により通信ゲームを実行することが選択されたときに、第１のゲーム装置と接続する第１の接続手段（１８）をさらに備える。また、第２のゲーム処理手段は、第１の接続手段により接続したゲーム装置と通信して、通信ゲームを実行する。また、第１のゲーム装置は、選択手段により第１のゲーム装置と通信ゲームを実行することが選択された第２ゲーム装置と接続する第２の接続手段（１８）をさらに備え、更に、第１のゲーム処理手段は、第２の接続手段により接続したゲーム装置と通信して、通信ゲームを実行する。例えば、第１のゲーム装置のユーザが他のゲーム装置と通信ゲームを実行することを希望する操作をおこなったときに、第１のゲーム装置の地域データ送信手段は、サーバを介して、または、サーバを介さずに直接、第２のゲーム装置に対して、地域データを送信する。第２のゲーム装置の地域データ受信手段は、地域データを受信して、当該地域データを用いて、地域情報をユーザに提示しつつ、第１のゲーム装置と通信ゲームを実行するか否かをユーザに選択させる。これにより、通信ゲームで用いられる気象データの元となる地域情報を参考にして、通信ゲームの相手を選択することができる。なお、地域データ受信手段は、複数の第１のゲーム装置から気象データを受信可能とし、各地域データごとの地域情報をユーザに提示しつつ、いずれの第１のゲーム装置と通信ゲームを実行するかをユーザに選択させてもかまわない。なお、第１ゲーム装置は、地域データとともにユーザ名データを送信し、第２ゲーム装置は、地域データとユーザ名データを受信して、地域象情報とともに当該ユーザ名データを用いてユーザ名情報を表示しつつ、ユーザに上記選択をさせてもかまわない。地域データ送信手段と地域データ受信手段は、地域データをゲーム装置間で直接通信してもよいし、サーバを介して通信してもよい。

第４の発明は、第１の発明において、配信手段は、気象データを複数のゲーム装置それぞれに対して配信可能である。また、第２のゲーム装置は、地域データを設定する地域データ設定手段（１０）と、配信サーバから、地域データ設定手段により設定された地域データに対応する気象データを取得する第１気象データ取得手段（１８）をさらに備える。また、第１のゲーム装置は、地域データ設定手段で取得した地域データを、第２のゲーム装置に送信する地域データ送信手段（１８）をさらに備える。また、第２のゲーム装置は、地域データを受信する地域データ受信手段と、配信サーバから、前記地域データ受信手段で受信した前記地域データに対応する前記気象データを取得する第２気象データ取得手段（１８）と、第２気象データ取得手段で取得された気象データを用いて、気象情報をユーザに提示しつつ、第１のゲーム装置と通信ゲームを実行するか否かをユーザに選択させる選択手段（１０）と、選択手段により通信ゲームを実行することが選択されたときに、第１のゲーム装置と接続する第１の接続手段（１８）をさらに備える。更に、第２のゲーム処理手段は、第１の接続手段により接続したゲーム装置と通信して、通信ゲームを実行する。また、第１のゲーム装置は、選択手段により第１のゲーム装置と通信ゲームを実行することが選択された第２ゲーム装置と接続する第２の接続手段をさらに備える。また、第１のゲーム処理手段は、第２の接続手段により接続したゲーム装置と通信して、通信ゲームを実行する。例えば、第１のゲーム装置のユーザが他のゲーム装置と通信ゲームを実行することを希望する操作をおこなったときに、第１のゲーム装置の地域データ送信手段は、サーバを介して、または、サーバを介さずに直接、第２のゲーム装置に対して、地域データを送信する。第２のゲーム装置の地域データ受信手段は、地域データを受信する。そして、第２の気象データ取得手段は、当該地域データに対応する気象データを取得する。そして、当該気象データを用いて、気象情報をユーザに提示しつつ、第１のゲーム装置と通信ゲームを実行するか否かをユーザに選択させる。これにより、通信ゲームで用いられる気象データを参考にして、通信ゲームの相手を選択することができる。なお、地域データ受信手段は、複数の第１のゲーム装置からの地域データを受信可能とし、第２の気象データ取得手段は、各地域データごとの気象データを取得して、各気象データを用いて気象情報をユーザに提示しつつ、いずれかの第１のゲーム装置と通信ゲームを実行するかをユーザに選択させてもかまわない。なお、第１ゲーム装置は、地域データとともにユーザ名データを送信し、第２ゲーム装置は、地域データとユーザ名データを受信して、地域象データに対応する気象情報とともに当該ユーザ名データを用いてユーザ名情報を表示しつつ、ユーザに上記選択をさせてもかまわない。

第５の発明は、相互に通信可能な複数のゲーム装置（３）と、当該複数のゲーム装置と通信ネットワークを介して接続され、かつ、地域ごとの気象データの配信を行う配信サーバ（４０）とを含むネットワークゲームシステムである。配信サーバは、気象データを前記複数のゲーム装置それぞれに対して配信するための配信手段を備える。また、ゲーム装置は、地域データを設定する地域データ設定手段（１０）と、配信サーバから、地域データ設定手段により設定された地域データに対応する気象データを取得する第１の気象データ取得手段（１８）をそれぞれ備える。また、複数のゲーム装置のうち、通信ゲームを実行する第１のゲーム装置と第２のゲーム装置について、第１のゲーム装置は、地域データを第２のゲーム装置に送信する地域データ送信手段と、第２のゲーム装置と通信して、自己の第１気象データ取得手段で取得した気象データを用いて、通信ゲームを行う第１のゲーム処理手段とを備える。
また、第２のゲーム装置は、第１ゲーム装置から地域データを受信する地域データ受信手段と、配信サーバから、地域データ受信手段で受信した地域データに基づいて、当該地域データに対応する気象データを取得する第２の気象データ取得手段と、第１のゲーム装置と通信して、第２の気象データ取得手段で取得した気象データを用いて、通信ゲームを行なう第２のゲーム処理手段を備える。このような構成において、第１のゲーム装置と第２のゲーム装置は、例えば、一方が接続要求を他方に送信し、他方がそれに応答することにより、互いに接続して通信ゲームを実行する。または、マッチングサーバにより接続して通信ゲームを実行してもよい。前者の場合、接続要求を送信したゲーム装置が第２のゲーム装置となり、それに応答したゲーム装置が第１のゲーム装置としてもよい。すなわち、接続要求を受けて応答した側のゲーム装置の地域データに対応する気象データが通信ゲームで用いられる。また、接続したゲーム装置のうち、いずれの地域データに対応する気象データを用いるかをユーザに選択させてもよい。

第６の発明は、相互に通信可能な複数のゲーム装置と、当該複数のゲーム装置と通信ネットワークを介して接続され、かつ、地域ごとの気象データの配信を行う配信サーバとを含むネットワークゲームシステムである。配信サーバは、気象データを前記複数のゲーム装置それぞれに対して配信するための配信手段を備える。ゲーム装置は、地域データを設定する地域データ設定手段と、配信サーバから、地域データ設定手段により設定された地域データに対応する前記気象データを取得する第１気象データ取得手段をそれぞれ備える。また、複数のゲーム装置のうち、通信ゲームを実行する第１のゲーム装置と第２のゲーム装置について、第１のゲーム装置は、地域データを第２のゲーム装置に送信する地域データ送信手段と、第２のゲーム装置と通信して、通信ゲームを行う第１のゲーム処理手段とを備える。第２のゲーム装置は、第１のゲーム装置と通信して、通信ゲームを行なう第２のゲーム処理手段と、第１ゲーム装置から地域データを受信する地域データ受信手段と、地域データ受信手段で受信した地域データを記憶する地域データ記憶手段と、地域データ記憶手段に記憶された地域データに基づいて、当該地域データに対応する気象データを配信サーバから取得する第２の気象データ取得手段と、第２の気象データ取得手段で取得した気象データを用いて、ゲームをおこなう第３のゲーム処理手段とを備える。ここで、第３のゲーム処理手段は、他のゲーム装置と通信せずにゲームをおこなってもよいし、他のゲーム装置と通信して通信ゲームを実行してもよい。前者の場合、第３のゲーム処理手段は、第１の気象データ取得手段で取得した気象データと、第２の気象データ取得手段で取得した気象データを選択的に用いてもよい。この場合、ユーザが選択できるようにしてもよい。また、第１のゲーム処理手段および第２のゲーム処理手段は、第１気象データ取得手段で取得した気象データを用いて、通信ゲームを実行してもよい。また、地域データ記憶手段は、地域データ受信手段が受信した地域データを複数記憶しても良い。また、不揮発的に記憶しても良い。そして、第２の気象データ取得手段は、地域データ記憶手段が記憶する地域データのうちのいずれかを選択して（ユーザ選択でもよい）、当該選択された地域データに対応する気象データを取得してもよい。

第７の発明は、第１、第５、または第６の発明において、ネットワークゲームシステムは、ゲーム装置同士のマッチングを行うためのマッチングサーバ（５０）を更に備える。マッチングサーバは、所定の条件に基づいて、第１のゲーム装置と第２のゲーム装置とを互いに接続対象としてマッチングする。

第８の発明は、第１、第５、または第６の発明において、第１のゲーム装置は、接続要求受信手段（１８）と、接続許可信号送信手段（１８）とを更に備える。接続要求受信手段は、第２のゲーム機からの接続要求信号を受信する。接続許可信号送信手段は、第２のゲーム機に接続要求信号に応じた接続許可信号を送信する。また、第２のゲーム装置は、アドレス記憶手段（１７）と、接続要求送信手段（１８）と、接続許可受信手段（１８）とを備える。アドレス記憶手段は、第１のゲーム装置のネットワークアドレスを記憶する。接続要求送信手段は、第１のゲーム装置のネットワークアドレスに対して接続要求信号を送信する。接続許可受信手段は、第１のゲーム機から、接続要求に応じた接続許可信号を受信する。

第９の発明は、第５の発明において、第１のゲーム装置は、他のゲーム装置からの接続を受け付けていることを示す接続受付情報を送信する受付情報送信手段を更に備える。第２のゲーム装置は、接続可能装置取得手段と、接続可能装置表示手段と、選択手段とを更に備える。接続可能装置取得手段は、少なくとも１つ以上のゲーム装置に関する接続受付情報を取得する。接続可能装置表示手段は、取得した接続受付情報にかかるゲーム装置に関する接続受付情報を一覧できるように画面に表示する。選択手段は、表示されたゲーム装置の情報から所望のゲーム装置を第１のゲーム装置として選択する。

第１０の発明は、第９の発明において、受付情報送信手段は、地域データを接続受付情報に含めて送信する。また、第２の気象データ取得手段は、取得した接続受付情報に含まれる地域データに基づいて、当該地域データに対応する前記気象データを取得する。更に、接続可能装置表示手段は、取得した気象データを接続受付情報にかかるゲーム装置の情報と対応づけて画面に表示する。

第１１の発明は、第１、第５、または第６の発明において、気象データとは、天候についてのデータである。

第１２の発明は、第１、第５、または第６の発明において、気象データとは、気温についてのデータである。

第１３の発明は、第１の発明において、気象データ取得手段は、第１または第２のゲーム処理手段で実行されるゲームプログラムとは異なるアプリケーションプログラムの実行によって気象データを取得する。

第１４の発明は、第５の発明において、第１の気象データ取得手段および第２の気象データ取得手段は、第１または第２のゲーム処理手段で実行されるゲームプログラムとは異なるアプリケーションプログラムの実行によって気象データを取得する。

第１５の発明は、第１３または第１４の発明において、ゲーム処理手段で実行されるゲームプログラムとは異なるアプリケーションプログラムを実行する専用アプリ実行手段を更に備える。また、地域データは、専用アプリ実行手段によるアプリケーションプログラムの実行でのみ変更可能である。

第１６の発明は、第１５の発明において、地域データは、第１の区分に係るデータと第２の区分にかかるデータとで構成されている。また、第１の区分に係るデータは、ゲーム装置の設置されている国を示すデータである。第２の区分に係るデータは、ゲーム装置の設置されている国においての地域を示すデータである。そして、専用アプリ実行手段は、第２の区分にかかるデータのみ変更可能である。

第１７の発明は、第５の発明において、第２のゲーム装置は、通信地域記憶手段（１７）と、地域表示手段（１０）と、地域選択手段（１０）とを更に備える。通信地域記憶手段は、設定データ受信手段により受信された地域データを少なくとも１つ以上不揮発に記憶する。地域表示手段は、通信地域記憶手段に記憶されている地域データに基づくゲームデータを、プレイヤが選択可能なように提示する。地域選択手段は、地域表示手段が表示したゲームデータから、プレイヤの選択操作に基づいた所定のゲームデータを選択する。更に、ゲーム処理手段は、地域選択手段によって選択されたゲームデータを用いてゲーム処理を行う。

第１８の発明は、第５の発明において、第２のゲーム装置は、配信サーバから、自己の地域データ設定手段で設定された地域データに基づいて、当該地域データに対応する気象データを取得する第３の気象データ取得手段を更に備える。また、第２のゲーム処理手段は、第２の気象データ取得手段で取得した気象データおよび第３の気象データ取得手段で取得した気象データを仮想ゲーム空間に反映してゲーム処理を実行する。

第１の発明によれば、ネットワークを介した通信ゲームを行う際に、通信相手の住んでいる地域の天気等の気象情報を、自己のゲーム装置のゲーム処理に反映することができる。これにより、例えば、第２のゲーム装置のプレイヤの地域の天気が晴れであっても、通信相手である第１のゲーム装置のプレイヤの地域で雨が降っていれば、第２のゲーム装置におけるゲーム処理で、当該雨という天気を反映させてゲームを実行することが可能となる。その結果、あたかも通信相手の地域に出向いてプレイをしているような印象をプレイヤに与えることが可能となる。これにより、他のゲーム装置と通信することの楽しさをより高めることができ、他人とのコミュニケーションを促進して、通信ゲームの興趣を更に高めることが可能となる。

第２乃至第４の発明によれば、プレイヤが通信相手を決定する際に、通信相手の情報をプレイヤに提示することができる。

第５の発明によれば、第１の発明と同様の効果が得られる。

第６の発明によれば、あるゲーム装置が他のゲーム装置との間で通信対戦を行うに連れて、地域データが増やていくようにすることができる。これにより、他のプレイヤのゲーム装置と通信を行っていなくても、他のプレイヤの地域の気象データを用いてゲームを行うことが可能となる。

第７の発明によれば、不特定多数の相手に対して効率よく接続相手を検索することができる。

第８の発明によれば、マッチングサーバを介さず、直接に他のゲーム装置との接続を行うことができ、マッチングサーバにかかるコストを削減することができる。

第９乃至第１０の発明によれば、プレイヤが通信相手を決定する際に、通信相手の情報をプレイヤに提示することができる。

第１１乃至第１２の発明によれば、通信相手の気象情報をプレイヤに認識させやすくすることができ、通信ゲームにおける臨場感を高めることができる。

第１３乃至１５の発明によれば、ゲームアプリケーション以外のアプリケーション向けのデータを、ゲームアプリケーションに流用することができる。これにより、データの共用化が可能となり、より効率的なゲーム開発が可能となる。

第１６の発明によれば、プレイヤによる地域データの、必要以上の変更を防止することが可能となる。

第１７の発明によれば、ゲームの購入直後の状態では、例えば、対戦用のステージとして１カ所しか地域が選択できないが、通信対戦を繰り返すことで、通信対戦した相手の地域に関するステージが選べるようになるゲームを提供することができる。これにより、プレイヤのゲームに対するモチベーションを維持させることができ、長く飽きのこないゲームを提供することが可能となる。

第１８の発明によれば、第１のゲーム装置にかかる地域の気象状況を反映してゲームをプレイしているときに、第２のゲーム装置のプレイヤの住んでいる地域にかかる気象状況についてもゲーム中に反映させることが可能となる。これにより、特に、多人数で同時にプレイする通信ゲームにおいて、各プレイヤの住んでいる地域の気象情報についてお互いに認識させることが可能となり、通信ゲームの興趣を高めることが可能となる。

各実施形態の詳細を説明するに先立ち、各実施形態で共通して使用されるゲーム装置の構成について説明する。
（ゲームシステムの全体構成）
図１を参照して、本発明の実施形態に係るゲーム装置を含むゲームシステム１について説明する。図１は、ゲームシステム１の外観図である。以下、据置型のゲーム装置を一例にして、本実施形態のゲーム装置およびゲームプログラムについて説明する。図１において、ゲームシステム１は、テレビジョン受像器（以下、単に「テレビ」と記載する）２、ゲーム装置３、光ディスク４、コントローラ７、およびマーカ部８を含む。本システムは、コントローラ７を用いたゲーム操作に基づいてゲーム装置３でゲーム処理を実行するものである。

ゲーム装置３には、当該ゲーム装置３に対して交換可能に用いられる情報記憶媒体の一例である光ディスク４が脱着可能に挿入される。光ディスク４には、ゲーム装置３において実行されるためのゲームプログラムが記憶されている。ゲーム装置３の前面には光ディスク４の挿入口が設けられている。ゲーム装置３は、挿入口に挿入された光ディスク４に記憶されたゲームプログラムを読み出して実行することによってゲーム処理を実行する。

ゲーム装置３には、表示装置の一例であるテレビ２が接続コードを介して接続される。テレビ２は、ゲーム装置３において実行されるゲーム処理の結果得られるゲーム画像を表示する。また、テレビ２の画面の周辺（図１では画面の上側）には、マーカ部８が設置される。マーカ部８は、その両端に２つのマーカ８Ｒおよび８Ｌを備えている。マーカ８Ｒ（マーカ８Ｌも同様）は、具体的には１以上の赤外ＬＥＤであり、テレビ２の前方に向かって赤外光を出力する。マーカ部８はゲーム装置３に接続されており、ゲーム装置３はマーカ部８が備える各赤外ＬＥＤの点灯を制御することが可能である。

コントローラ７は、自機に対して行われた操作の内容を示す操作データをゲーム装置３に与える入力装置である。コントローラ７とゲーム装置３とは無線通信によって接続される。本実施形態では、コントローラ７とゲーム装置３との間の無線通信には例えばＢｌｕｅｔｏｏｔｈ（ブルートゥース）（登録商標）の技術が用いられる。なお、他の実施形態においてはコントローラ７とゲーム装置３とは有線で接続されてもよい。

（ゲーム装置３の内部構成）
次に、図２を参照して、ゲーム装置３の内部構成について説明する。図２は、ゲーム装置３の構成を示すブロック図である。ゲーム装置３は、ＣＰＵ１０、システムＬＳＩ１１、外部メインメモリ１２、ＲＯＭ／ＲＴＣ１３、ディスクドライブ１４、およびＡＶ−ＩＣ１５等を有する。

ＣＰＵ１０は、光ディスク４に記憶されたゲームプログラムを実行することによってゲーム処理を実行するものであり、ゲームプロセッサとして機能する。ＣＰＵ１０は、システムＬＳＩ１１に接続される。システムＬＳＩ１１には、ＣＰＵ１０の他、外部メインメモリ１２、ＲＯＭ／ＲＴＣ１３、ディスクドライブ１４およびＡＶ−ＩＣ１５が接続される。システムＬＳＩ１１は、それに接続される各構成要素間のデータ転送の制御、表示すべき画像の生成、外部装置からのデータの取得等の処理を行う。システムＬＳＩの内部構成について後述する。揮発性の外部メインメモリ１２は、光ディスク４から読み出されたゲームプログラムや、フラッシュメモリ１７から読み出されたゲームプログラム等のプログラムを記憶したり、各種データを記憶したりするものであり、ＣＰＵ１０のワーク領域やバッファ領域として用いられる。ＲＯＭ／ＲＴＣ１３は、ゲーム装置３の起動用のプログラムが組み込まれるＲＯＭ（いわゆるブートＲＯＭ）と、時間をカウントするクロック回路（ＲＴＣ：Ｒｅａｌ Ｔｉｍｅ Ｃｌｏｃｋ）とを有する。ディスクドライブ１４は、光ディスク４からプログラムデータやテクスチャデータ等を読み出し、後述する内部メインメモリ１１ｅまたは外部メインメモリ１２に読み出したデータを書き込む。

また、システムＬＳＩ１１には、入出力プロセッサ１１ａ、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｏｒ Ｕｎｉｔ）１１ｂ、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）１１ｃ、ＶＲＡＭ１１ｄ、および内部メインメモリ１１ｅが設けられる。図示は省略するが、これらの構成要素１１ａ〜１１ｅは内部バスによって互いに接続される。

ＧＰＵ１１ｂは、描画手段の一部を形成し、ＣＰＵ１０からのグラフィクスコマンド（作画命令）に従って画像を生成する。より具体的には、ＧＰＵ１１ｂは、当該グラフィクスコマンドに従って３Ｄグラフィックスの表示に必要な計算処理、例えば、レンダリングの前処理にあたる３Ｄ座標から２Ｄ座標への座標変換などの処理や、テクスチャの張り込みなどの最終的なレンダリング処理を行うことで、ゲーム画像データを生成する。ここで、ＣＰＵ１０は、グラフィクスコマンドに加えて、ゲーム画像データの生成に必要な画像生成プログラムをＧＰＵ１１ｂに与える。ＶＲＡＭ１１ｄは、ＧＰＵ１１ｂがグラフィクスコマンドを実行するために必要なデータ（ポリゴンデータやテクスチャデータ等のデータ）を記憶する。画像が生成される際には、ＧＰＵ１１ｂは、ＶＲＡＭ１１ｄに記憶されたデータを用いて画像データを作成する。

ＤＳＰ１１ｃは、オーディオプロセッサとして機能し、内部メインメモリ１１ｅや外部メインメモリ１２に記憶されるサウンドデータや音波形（音色）データを用いて、音声データを生成する。

上述のように生成された画像データおよび音声データは、ＡＶ−ＩＣ１５によって読み出される。ＡＶ−ＩＣ１５は、読み出した画像データをＡＶコネクタ１６を介してテレビ２に出力するとともに、読み出した音声データを、テレビ２に内蔵されるスピーカ２ａに出力する。これによって、画像がテレビ２に表示されるとともに音がスピーカ２ａから出力される。

入出力プロセッサ（Ｉ／Ｏプロセッサ）１１ａは、それに接続される構成要素との間でデータの送受信を実行したり、外部装置からのデータのダウンロードを実行したりする。入出力プロセッサ１１ａは、フラッシュメモリ１７、無線通信モジュール１８、無線コントローラモジュール１９、拡張コネクタ２０、および外部メモリカード用コネクタ２１に接続される。無線通信モジュール１８にはアンテナ２２が接続され、無線コントローラモジュール１９にはアンテナ２３が接続される。

入出力プロセッサ１１ａは、無線通信モジュール１８およびアンテナ２２を介してネットワークに接続し、ネットワークに接続される他のゲーム装置や各種サーバと通信することができる。入出力プロセッサ１１ａは、定期的にフラッシュメモリ１７にアクセスし、ネットワークへ送信する必要があるデータの有無を検出し、当該データが有る場合には、無線通信モジュール１８およびアンテナ２２を介してネットワークに送信する。また、入出力プロセッサ１１ａは、他のゲーム装置から送信されてくるデータやダウンロードサーバからダウンロードしたデータを、ネットワーク、アンテナ２２および無線通信モジュール１８を介して受信し、受信したデータをフラッシュメモリ１７に記憶する。ＣＰＵ１０はゲームプログラムを実行することにより、フラッシュメモリ１７に記憶されたデータを読み出してゲームプログラムで利用する。フラッシュメモリ１７には、ゲーム装置３と他のゲーム装置や各種サーバとの間で送受信されるデータの他、ゲーム装置３を利用してプレイしたゲームのセーブデータ（ゲームの結果データまたは途中データ）が記憶されてもよい。

また、入出力プロセッサ１１ａは、コントローラ２２から送信される操作データをアンテナ２３および無線コントローラモジュール１９を介して受信し、内部メインメモリ１１ｅまたは外部メインメモリ１２のバッファ領域に記憶（一時記憶）する。

さらに、入出力プロセッサ１１ａには、拡張コネクタ２０および外部メモリカード用コネクタ２１が接続される。拡張コネクタ２０は、ＵＳＢやＳＣＳＩのようなインターフェースのためのコネクタであり、外部記憶媒体のようなメディアを接続したり、他のコントローラのような周辺機器を接続したり、有線の通信用コネクタを接続することによって無線通信モジュール１８に替えてネットワークとの通信を行ったりすることができる。外部メモリカード用コネクタ２１は、メモリカードのような外部記憶媒体を接続するためのコネクタである。例えば、入出力プロセッサ１１ａは、拡張コネクタ２０や外部メモリカード用コネクタ２１を介して、外部記憶媒体にアクセスし、データを保存したり、データを読み出したりすることができる。

ゲーム装置３には、電源ボタン２４、リセットボタン２５、およびイジェクトボタン２６が設けられる。電源ボタン２４およびリセットボタン２５は、システムＬＳＩ１１に接続される。電源ボタン２４がオンにされると、ゲーム装置３の各構成要素に対して、図示しないＡＣアダプタを経て電源が供給される。また、一旦電源がオンにされた状態で、再度電源ボタン２４を押すと、豆電球１個程度の電力しか使わない低電力スタンバイモードへの移行が行われる。この状態でも、ゲーム装置３への通電は行われているため、インターネット等のネットワークに常時接続しておくことができる。なお、一旦電源がオンにされた状態で、電源をオフにしたいときは、電源ボタン２４を所定時間以上長押しすることで、電源をオフとすることが可能である。リセットボタン２５が押されると、システムＬＳＩ１１は、ゲーム装置３の起動プログラムを再起動する。イジェクトボタン２６は、ディスクドライブ１４に接続される。イジェクトボタン２６が押されると、ディスクドライブ１４から光ディスク４が排出される。

ここで、本実施形態にかかるゲーム装置３が行う通信の種類について説明する。当該通信の種類は、大きく分けて２種類ある。１つめは、上述の低電力スタンバイモード中においても通信を行い得る、常時接続型のネットワークを利用した通信（以下、常時接続利用型通信と呼ぶ）である。もう１つは、例えば、通信対戦ゲーム等のアプリケーションプログラムに依存し、必要に応じて、その都度接続、通信制御が行われる通信である（以下、随時接続型通信と呼ぶ）。常時接続利用型通信においては、後述するようなゲームプログラム等の各種プログラムに関わらず、上述のように入出力プロセッサ１１ａが独立して上記フラッシュメモリ１７に書き込まれた送信データを送信し、また、受信したデータを当該フラッシュメモリ１７に書き込む。そのため、常時接続利用型通信を利用するアプリケーション（例えばメールアプリケーション等）は、送信したいデータをフラッシュメモリ１７に書込み、受信データをフラッシュメモリ１７から読み出すだけでよい。また、常時接続利用型通信を利用すれば、上記低電力スタンバイモード中であっても、定期的に通信を行うことができ、更に、所定のゲームプログラムが実行中であっても、そのバックグラウンドのプロセスとして通信を行うことが可能である。なお、本実施形態では、後述する配信サーバとの通信については、常時接続型通信を利用して定期的に総合天気データ（詳細は後述）を取得する。また、後述するような本実施形態で想定する通信対戦ゲームにかかる通信では、上記随時接続型通信を利用する。

次に、図３および図４を参照して、コントローラ７について説明する。なお、図３は、コントローラ７の上面後方から見た斜視図である。図４は、コントローラ７を下面前方から見た斜視図である。

図３および図４において、コントローラ７は、ハウジング７１と、当該ハウジング７１の表面に設けられた複数個の操作ボタンで構成される操作部７２とを備える。本実施例のハウジング７１は、その前後方向を長手方向とした略直方体形状を有しており、全体として大人や子供の片手で把持可能な大きさであり、例えばプラスチック成型によって形成されている。

ハウジング７１上面の中央前面側に、十字キー７２ａが設けられる。この十字キー７２ａは、十字型の４方向プッシュスイッチであり、４つの方向（前後左右）に対応する操作部分が十字の突出片にそれぞれ９０°間隔で配置される。プレイヤが十字キー７２ａのいずれかの操作部分を押下することによって前後左右いずれかの方向を選択される。例えばプレイヤが十字キー７２ａを操作することによって、仮想ゲーム世界に登場するプレイヤキャラクタ等の移動方向を指示したり、複数の選択肢から選択指示したりすることができる。

なお、十字キー７２ａは、上述したプレイヤの方向入力操作に応じて操作信号を出力する操作部であるが、他の態様の操作部でもかまわない。例えば、十字方向に４つのプッシュスイッチを配設し、プレイヤによって押下されたプッシュスイッチに応じて操作信号を出力する操作部を設けてもかまわない。さらに、上記４つのプッシュスイッチとは別に、上記十字方向が交わる位置にセンタスイッチを配設し、４つのプッシュスイッチとセンタスイッチとを複合した操作部を設けてもかまわない。また、ハウジング７１上面から突出した傾倒可能なスティック（いわゆる、ジョイスティック）を倒すことによって、傾倒方向に応じて操作信号を出力する操作部を上記十字キー７２ａの代わりに設けてもかまわない。さらに、水平移動可能な円盤状部材をスライドさせることによって、当該スライド方向に応じた操作信号を出力する操作部を、上記十字キー７２ａの代わりに設けてもかまわない。また、タッチパッドを、上記十字キー７２ａの代わりに設けてもかまわない。

ハウジング７１上面の十字キー７２ａより後面側に、複数の操作ボタン７２ｂ〜７２ｇが設けられる。操作ボタン７２ｂ〜７２ｇは、プレイヤがボタン頭部を押下することによって、それぞれの操作ボタン７２ｂ〜７２ｇに割り当てられた操作信号を出力する操作部である。例えば、操作ボタン７２ｂ〜７２ｄには、１番ボタン、２番ボタン、およびＡボタン等としての機能が割り当てられる。また、操作ボタン７２ｅ〜７２ｇには、マイナスボタン、ホームボタン、およびプラスボタン等としての機能が割り当てられる。これら操作ボタン７２ａ〜７２ｇは、ゲーム装置３が実行するゲームプログラムに応じてそれぞれの操作機能が割り当てられる。なお、図３に示した配置例では、操作ボタン７２ｂ〜７２ｄは、ハウジング７１上面の中央前後方向に沿って並設されている。また、操作ボタン７２ｅ〜７２ｇは、ハウジング７１上面の左右方向に沿って操作ボタン７２ｂおよび７２ｄの間に並設されている。そして、操作ボタン７２ｆは、その上面がハウジング７１の上面に埋没しており、プレイヤが不意に誤って押下することのないタイプのボタンである。

また、ハウジング７１上面の十字キー７２ａより前面側に、操作ボタン７２ｈが設けられる。操作ボタン７２ｈは、遠隔からゲーム装置３本体の電源をオン／オフする電源スイッチである。この操作ボタン７２ｈも、その上面がハウジング７１の上面に埋没しており、プレイヤが不意に誤って押下することのないタイプのボタンである。

また、ハウジング７１上面の操作ボタン７２ｃより後面側に、複数のＬＥＤ７０２が設けられる。ここで、コントローラ７は、他のコントローラ７と区別するためにコントローラ種別（番号）が設けられている。例えば、ＬＥＤ７０２は、コントローラ７に現在設定されている上記コントローラ種別をプレイヤに通知するために用いられる。具体的には、コントローラ７から無線コントローラモジュール１９へ送信データを送信する際、上記コントローラ種別に応じて複数のＬＥＤ７０２のうち、種別に対応するＬＥＤが点灯する。

また、ハウジング７１上面には、操作ボタン７２ｂおよび操作ボタン７２ｅ〜７２ｇの間に後述するスピーカ（図５のスピーカ７０６）からの音を外部に放出するための音抜き孔が形成されている。

一方、ハウジング７１下面には、凹部が形成されている。後述で明らかとなるが、ハウジング７１下面の凹部は、プレイヤがコントローラ７の前面をマーカ８Ｌおよび８Ｒに向けて片手で把持したときに、当該プレイヤの人差し指や中指が位置するような位置に形成される。そして、上記凹部の後面側傾斜面には、操作ボタン７２ｉが設けられる。操作ボタン７２ｉは、例えばＢボタンとして機能する操作部である。

また、ハウジング７１前面には、撮像情報演算部７４の一部を構成する撮像素子７４３が設けられる。ここで、撮像情報演算部７４は、コントローラ７が撮像した画像データを解析してその中で輝度が高い場所を判別してその場所の重心位置やサイズなどを検出するためのシステムであり、例えば、最大２００フレーム／秒程度のサンプリング周期であるため比較的高速なコントローラ７の動きでも追跡して解析することができる。この撮像情報演算部７４の詳細な構成については、後述する。また、ハウジング７０の後面には、コネクタ７３が設けられている。コネクタ７３は、例えばエッジコネクタであり、例えば接続ケーブルと嵌合して接続するために利用される。

ここで、以下の説明を具体的にするために、コントローラ７に対して設定する座標系について定義する。図３および図４に示すように、互いに直交するｘｙｚ軸をコントローラ７に対して定義する。具体的には、コントローラ７の前後方向となるハウジング７１の長手方向をｚ軸とし、コントローラ７の前面（撮像情報演算部７４が設けられている面）方向をｚ軸正方向とする。また、コントローラ７の上下方向をｙ軸とし、ハウジング７１の下面（操作ボタン７２ｉが設けられた面）方向をｙ軸正方向とする。さらに、コントローラ７の左右方向をｘ軸とし、ハウジング７１の左側面（図３では表されずに図４で表されている側面）方向をｘ軸正方向とする。

次に、図５および図６を参照して、コントローラ７の内部構造について説明する。なお、図５は、コントローラ７の上ハウジング（ハウジング７１の一部）を外した状態を後面側から見た斜視図である。図６は、コントローラ７の下ハウジング（ハウジング７１の一部）を外した状態を前面側から見た斜視図である。ここで、図６に示す基板７００は、図５に示す基板７００の裏面から見た斜視図となっている。

図５において、ハウジング７１の内部には基板７００が固設されており、当該基板７００の上主面上に操作ボタン７２ａ〜７２ｈ、加速度センサ７０１、ＬＥＤ７０２、およびアンテナ７５４等が設けられる。そして、これらは、基板７００等に形成された配線（図示せず）によってマイコン７５１等（図６、図７参照）に接続される。マイコン７５１は本願発明のボタンデータ発生手段の一例として、操作ボタン７２ａ等の種類に応じた操作ボタンデータを発生させるように機能する。この仕組みは公知技術であるが、例えばキートップ下側に配置されたタクトスイッチなどのスイッチ機構による配線の接触／切断をマイコン７５１が検出することによって実現されている。より具体的には、操作ボタンが例えば押されると配線が接触して通電するので、この通電がどの操作ボタンにつながっている配線で発生したかをマイコン７５１が検出し、操作ボタンの種類に応じた信号を発生させている。

また、コントローラ７は、図示しない無線モジュール７５３（図７参照）およびアンテナ７５４によって、ワイヤレスコントローラとして機能する。なお、ハウジング７１内部には図示しない水晶振動子７０３が設けられており、後述するマイコン７５１の基本クロックを生成する。また、基板７００の上主面上に、スピーカ７０６およびアンプ７０８が設けられる。また、加速度センサ７０１は、操作ボタン７２ｄの左側の基板７００上（つまり、基板７００の中央部ではなく周辺部）に設けられる。したがって、加速度センサ７０１は、コントローラ７の長手方向を軸とした回転に応じて、重力加速度の方向変化に加え、遠心力による成分の含まれる加速度を検出することができるので、所定の演算により、検出される加速度データからコントローラ７の回転を良好な感度でゲーム装置３等が判定することができる。

一方、図６において、基板７００の下主面上の前端縁に撮像情報演算部７４が設けられる。撮像情報演算部７４は、コントローラ７の前方から順に赤外線フィルタ７４１、レンズ７４２、撮像素子７４３、および画像処理回路７４４によって構成されており、それぞれ基板７００の下主面に取り付けられる。また、基板７００の下主面上の後端縁にコネクタ７３が取り付けられる。さらに、基板７００の下主面上にサウンドＩＣ７０７およびマイコン７５１が設けられている。サウンドＩＣ７０７は、基板７００等に形成された配線によってマイコン７５１およびアンプ７０８と接続され、ゲーム装置３から送信されたサウンドデータに応じてアンプ７０８を介してスピーカ７０６に音声信号を出力する。

そして、基板７００の下主面上には、バイブレータ７０４が取り付けられる。バイブレータ７０４は、例えば振動モータやソレノイドである。バイブレータ７０４は、基板７００等に形成された配線によってマイコン７５１と接続され、ゲーム装置３から送信された振動データに応じてその作動をオン／オフする。バイブレータ７０４が作動することによってコントローラ７に振動が発生するので、それを把持しているプレイヤの手にその振動が伝達され、いわゆる振動対応ゲームが実現できる。ここで、バイブレータ７０４は、ハウジング７１のやや前方寄りに配置されるため、プレイヤが把持している状態において、ハウジング７１が大きく振動することになり、振動を感じやすくなる。

次に、図７を参照して、コントローラ７の内部構成について説明する。なお、図７は、コントローラ７の構成を示すブロック図である。

図７において、コントローラ７は、上述した操作部７２、撮像情報演算部７４、加速度センサ７０１、バイブレータ７０４、スピーカ７０６、サウンドＩＣ７０７、およびアンプ７０８の他に、その内部に通信部７５を備えている。

撮像情報演算部７４は、赤外線フィルタ７４１、レンズ７４２、撮像素子７４３、および画像処理回路７４４を含んでいる。赤外線フィルタ７４１は、コントローラ７の前方から入射する光から赤外線のみを通過させる。レンズ７４２は、赤外線フィルタ７４１を透過した赤外線を集光して撮像素子７４３へ出射する。撮像素子７４３は、例えばＣＭＯＳセンサやあるいはＣＣＤのような固体撮像素子であり、レンズ７４２が集光した赤外線を撮像する。したがって、撮像素子７４３は、赤外線フィルタ７４１を通過した赤外線だけを撮像して画像データを生成する。撮像素子７４３で生成された画像データは、画像処理回路７４４で処理される。具体的には、画像処理回路７４４は、撮像素子７４３から得られた画像データを処理して高輝度部分を検知し、それらの位置座標や面積を検出した結果を示す処理結果データを通信部７５へ出力する。なお、これらの撮像情報演算部７４は、コントローラ７のハウジング７１に固設されており、ハウジング７１自体の方向を変えることによってその撮像方向を変更することができる。後述により明らかとなるが、この撮像情報演算部７４から出力される処理結果データに基づいて、コントローラ７の位置や動きに応じた信号を得ることができる。

コントローラ７は、３軸（ｘ、ｙ、ｚ軸）の加速度センサ７０１を備えていることが好ましい。この３軸の加速度センサ７０１は、３方向、すなわち、上下方向、左右方向、および前後方向で直線加速度を検知する。また、他の実施形態においては、ゲーム処理に用いる制御信号の種類によっては、上下および左右方向（または他の対になった方向）のそれぞれに沿った直線加速度のみを検知する２軸の加速度検出手段を使用してもよい。例えば、この３軸または２軸の加速度センサ７０１は、アナログ・デバイセズ株式会社（Ａｎａｌｏｇ Ｄｅｖｉｃｅｓ， Ｉｎｃ．）またはＳＴマイクロエレクトロニクス社（ＳＴＭｉｃｒｏｅｌｅｃｔｒｏｎｉｃｓ Ｎ．Ｖ．）から入手可能であるタイプのものでもよい。加速度センサ７０１は、シリコン微細加工されたＭＥＭＳ（Ｍｉｃｒｏ Ｅｌｅｃｔｒｏ Ｍｅｃｈａｎｉｃａｌ Ｓｙｓｔｅｍｓ：微小電子機械システム）の技術に基づいた静電容量式（静電容量結合式）であってもよい。しかしながら、既存の加速度検出手段の技術（例えば、圧電方式や圧電抵抗方式）あるいは将来開発される他の適切な技術を用いて３軸または２軸の加速度センサ７０１が提供されてもよい。

当業者には公知であるように、加速度センサ７０１に用いられるような加速度検出手段は、加速度センサの持つ各軸に対応する直線に沿った加速度（直線加速度）のみを検知することができる。つまり、加速度センサ７０１からの直接の出力は、その２軸または３軸のそれぞれに沿った直線加速度（静的または動的）を示す信号である。このため、加速度センサ７０１は、非直線状（例えば、円弧状）の経路に沿った動き、回転、回転運動、角変位、傾斜、位置、または姿勢等の物理特性を直接検知することはできない。

しかしながら、加速度センサ７０１から出力される加速度の信号に基づいて、ゲーム装置のプロセッサ（例えばＣＰＵ３０）またはコントローラのプロセッサ（例えばマイコン７５１）などのコンピュータが処理を行うことによって、コントローラ７に関するさらなる情報を推測または算出（判定）することができることは、当業者であれば本明細書の説明から容易に理解できるであろう。例えば、加速度センサを搭載するコントローラが静的な状態であることを前提としてコンピュータ側で処理する場合（すなわち、加速度センサによって検出される加速度が重力加速度のみであるとして処理する場合）、コントローラが現実に静的な状態であれば、検出された加速度に基づいてコントローラの姿勢が重力方向に対して傾いているか否か又はどの程度傾いているかを知ることができる。具体的には、加速度センサの検出軸が鉛直下方向を向いている状態を基準としたとき、１Ｇ（重力加速度）がかかっているか否かだけで傾いているか否かを知ることができるし、その大きさによってどの程度傾いているかも知ることができる。また、多軸の加速度センサの場合には、さらに各軸の加速度の信号に対して処理を施すことによって、重力方向に対してどの程度傾いているかをより詳細に知ることができる。この場合において、、加速度センサ７０１からの出力に基づいて、プロセッサがコントローラ７の傾き角度のデータを算出する処理をおこなってもよいが、当該傾き角度のデータを算出する処理をおこなうことなく、加速度センサ７０１からの出力に基づいて、おおよその傾き具合を推定するような処理としてもよい。このように、加速度センサ７０１をプロセッサと組み合わせて用いることによって、コントローラ７の傾き、姿勢または位置を判定することができる。一方、加速度センサが動的な状態であることを前提とする場合には、重力加速度成分に加えて加速度センサの動きに応じた加速度を検出するので、重力加速度成分を所定の処理により除去すれば、動き方向などを知ることができる。具体的には、、加速度センサ７０１を備えるコントローラ７がユーザの手で動的に加速されて動かされる場合に、加速度センサ７０１によって生成される加速度信号を処理することによって、コントローラ７のさまざまな動きおよび／または位置を算出することができる。なお、加速度センサが動的な状態であることを前提とする場合であっても、加速度センサの動きに応じた加速度を所定の処理により除去すれば、重力方向対する傾きを知ることが可能である。他の実施例では、加速度センサ７０１は、信号をマイコン７５１に出力する前に内蔵の加速度検出手段から出力される加速度信号に対して所望の処理を行うための、組込み式の信号処理装置または他の種類の専用の処理装置を備えていてもよい。例えば、組込み式または専用の処理装置は、加速度センサが静的な加速度（例えば、重力加速度）を検出するためのものである場合、検知された加速度信号をそれに相当する傾斜角（あるいは、他の好ましいパラメータ）に変換するものであってもよい。

他の実施形態の例では、コントローラ７の動きを検出する動きセンサとして、回転素子または振動素子などを内蔵したジャイロセンサを用いてもよい。この実施形態で使用されるＭＥＭＳジャイロセンサの一例として、アナログ・デバイセズ株式会社から入手可能なものがある。加速度センサ７０１と異なり、ジャイロセンサは、それが内蔵する少なくとも一つのジャイロ素子の軸を中心とした回転（または角速度）を直接検知することができる。このように、ジャイロセンサと加速度センサとは基本的に異なるので、個々の用途のためにいずれの装置が選択されるかによって、これらの装置からの出力信号に対して行う処理を適宜変更する必要がある。

具体的には、加速度センサの代わりにジャイロセンサを用いて傾きや姿勢を算出する場合には、大幅な変更を行う。すなわち、ジャイロセンサを用いる場合、検出開始の状態において傾きの値を初期化する。そして、当該ジャイロセンサから出力される角速度データを積分する。次に、初期化された傾きの値からの傾きの変化量を算出する。この場合、算出される傾きは、角度に対応する値が算出されることになる。一方、加速度センサによって傾きを算出する場合には、重力加速度のそれぞれの軸に関する成分の値を、所定の基準と比較することによって傾きを算出するので、算出される傾きはベクトルで表すことが可能であり、初期化を行わずとも、加速度検出手段を用いて検出される絶対的な方向を検出することが可能である。また、傾きとして算出される値の性質は、ジャイロセンサが用いられる場合には角度であるのに対して、加速度センサが用いられる場合にはベクトルであるという違いがある。したがって、加速度センサに代えてジャイロセンサが用いられる場合、当該傾きのデータに対して、２つのデバイスの違いを考慮した所定の変換を行う必要がある。加速度検出手段とジャイロセンサとの基本的な差異と同様にジャイロセンサの特性は当業者に公知であるので、本明細書ではさらなる詳細を省略する。ジャイロセンサは、回転を直接検知できることによる利点を有する一方、一般的には、加速度センサは、本実施形態で用いるようなコントローラに適用される場合、ジャイロセンサに比べて費用効率が良いという利点を有する。

通信部７５は、マイクロコンピュータ（Ｍｉｃｒｏ Ｃｏｍｐｕｔｅｒ：マイコン）７５１、メモリ７５２、無線モジュール７５３、およびアンテナ７５４を含んでいる。マイコン７５１は、処理の際にメモリ７５２を記憶領域として用いながら、送信データを無線送信する無線モジュール７５３を制御する。また、マイコン７５１は、アンテナ７５４を介して無線モジュール７５３が受信したゲーム装置３からのデータに応じて、サウンドＩＣ７０７およびバイブレータ７０４の動作を制御する。サウンドＩＣ７０７は、通信部７５を介してゲーム装置３から送信されたサウンドデータ等を処理する。また、マイコン７５１は、通信部７５を介してゲーム装置３から送信された振動データ（例えば、バイブレータ７０４をＯＮまたはＯＦＦする信号）等に応じて、バイブレータ７０４を作動させる。

コントローラ７に設けられた操作部７２からの操作信号（キーデータ）、加速度センサ７０１からの加速度信号（ｘ、ｙ、およびｚ軸方向加速度データ；以下、単に加速度データと記載する）、および撮像情報演算部７４からの処理結果データは、マイコン７５１に出力される。マイコン７５１は、入力した各データ（キーデータ、加速度データ、処理結果データ）を無線コントローラモジュール１９へ送信する送信データとして一時的にメモリ７５２に格納する。ここで、通信部７５から無線コントローラモジュール１９への無線送信は、所定の周期毎に行われるが、ゲームの処理は１／６０秒を単位として行われることが一般的であるので、それよりも短い周期で送信を行うことが必要となる。具体的には、ゲームの処理単位は１６．７ｍｓ（１／６０秒）であり、ブルートゥース（Ｂｌｕｅｔｏｏｔｈ；登録商標）で構成される通信部７５の送信間隔は例えば５ｍｓである。マイコン７５１は、無線コントローラモジュール１９への送信タイミングが到来すると、メモリ７５２に格納されている送信データを一連の操作情報として出力し、無線モジュール７５３へ出力する。そして、無線モジュール７５３は、例えばブルートゥース（登録商標）の技術に基づいて、所定周波数の搬送波を用いて操作情報で変調し、その電波信号をアンテナ７５４から放射する。つまり、コントローラ７に設けられた操作部７２からのキーデータ、加速度センサ７０１からの加速度データ、および撮像情報演算部７４からの処理結果データが無線モジュール７５３で電波信号に変調されてコントローラ７から送信される。そして、ゲーム装置３の無線コントローラモジュール１９でその電波信号を受信し、ゲーム装置３で当該電波信号を復調や復号することによって、一連の操作情報（キーデータ、加速度データ、および処理結果データ）を取得する。そして、ゲーム装置３のＣＰＵ３０は、取得した操作情報とゲームプログラムとに基づいて、ゲーム処理を行う。なお、ブルートゥース（登録商標）の技術を用いて通信部７５を構成する場合、通信部７５は、他のデバイスから無線送信された送信データを受信する機能も備えることができる。

次に、本発明の実施形態に係る配信サーバ４０およびマッチングサーバ５０の構成について説明する。図８に、天気情報の配信を実行する配信サーバ４０の構成を示す。配信サーバ４０は、外部記憶装置４１と、メモリ４２と、ＣＰＵ４３と、通信部４４とが、バスを介して相互に接続されている。外部記憶装置４１は、本発明の配信プログラムや各ゲーム装置との通信接続を行うための通信接続制御プログラムや後述する総合天気データが記憶されている。配信プログラムには、ＣＰＵ４３に実行させるための処理手順や各種命令等が記述されており、その中には、所定のゲーム装置からの配信要求信号に応じて後述の総合天気データの配信を制御するための内容が含まれている。メモリ４２は、配信システムを実行する場合に、外部記憶装置４１より配信プログラムや総合天気データ等のファイルを読み込むといった一時的にデータやプログラム等を記憶する内部記憶装置を示す。ＣＰＵ４３は、メモリ４２に読み込んだプログラムを実行する演算装置や制御装置である。また、通信部４４は、ネットワークを介してゲーム装置３等と通信を行う。その他、図示は省略するが、適宜、キーボードやマウス等の入出力装置やモニタ等の表示装置を備える、あるいは接続されていてもよい。

また、複数のゲーム装置３の間でマッチングを実行するマッチングサーバ５０の構成も、上記配信サーバ４０と同様である。図８の構成のサーバをマッチングサーバ５０として利用する場合は、外部記憶装置４１は、本発明のマッチングプログラムや後述するホストリスト等を格納する。メモリ４２は、マッチングを実行する場合に、外部記憶装置４１よりマッチングプログラムやホストリスト等のファイルを読み込むといった一時的にデータやプログラム等を記憶する内部記憶装置を示す。ＣＰＵ４３は、メモリ４２に読み込んだプログラムを実行する演算装置や制御装置である。また、通信部４４は、ネットワークを介してゲーム装置３等と通信を行う。その他、図示は省略するが、適宜、キーボードやマウス等の入出力装置やモニタ等の表示装置を備える、あるいは接続されていてもよい。

（第１の実施形態）
次に、第１の実施形態で想定しているゲームの概要について説明する。本実施形態では、通信対戦型の格闘ゲームを想定している。本ゲームでは、ネットワークを介して、他のプレイヤと１ＶＳ１で対戦することができる。この際、対戦するステージ（仮想空間）について、通信対戦する相手の住んでいる地域の天気をステージ内に反映することができる。例えば、大阪に住んでいるプレイヤが、北海道に住んでいるプレイヤに対して対戦を申し込んだとする。このとき、大阪の天気は「晴れ」、北海道の天気は「雪」であるとする。また、両プレイヤが対戦するステージについては、「北海道」の所定の名所をモチーフにした仮想空間であり、初期値では「晴れ」の天候が設定されて表現されることを前提とする。この場合、当該ステージについては、雪が積もっている状態、あるいは、雪が降っている状態で表現される。つまり、大阪のプレイヤは、自分のいる地域が晴れであるにも関わらず、雪が降っている北海道に出向いて対戦を行っているかの印象を受けることになる。

図９は、第１の実施形態におけるネットワーク構成を示す図である。図９では、配信サーバ４０、マッチングサーバ５０、第１のゲーム装置３ａ、第２のゲーム装置３ｂがネットワークに接続されている。また、このネットワークは、常時接続型のネットワークである。そのため、各ゲーム装置は当該常時接続型のネットワークを介して、相互に接続されていることになる。また、各ゲーム装置も、上述した低電力スタンバイモード等への移行も含め、２４時間稼働している状態である。

まず、配信サーバ４０について説明する。配信サーバ４０は所定の観測点で観測された世界各国の気象情報を総合天気データとして、所定の配信契約（例えば、いわゆる有料サービス等）を締結しているゲーム装置のみに配信する。ここでは、第１のゲーム装置の所有者のみが、当該配信のための契約を行っているものとする。そして、第１のゲーム装置は、例えば１時間毎に、配信サーバから総合天気データの配信を受ける。この総合天気データには、ある時間に観測された世界各国の気象情報が含まれている。

次に、マッチングサーバ５０は、第１のゲーム装置３ａあるいは第２のゲーム装置３ｂが通信対戦ゲームを行う際に、互いに対戦相手を探すときに利用されるサーバである。つまり、第１のゲーム装置３ａと第２のゲーム装置３ｂとの間で通信対戦を可能とすべく、両者を結びつけるためのサーバである。

第１のゲーム装置３ａおよび第２のゲーム装置３ｂは、それぞれ、通信対戦ゲームを行う各プレイヤの所有にかかるものである。このうち、第１のゲーム装置３ａには、上記のように、配信契約に基づいて、配信サーバ４０から気象情報の配信を受けることが可能な設定がなされている。また、配信に際して、第１のゲーム装置３ａの設置されている地域（つまり、所有者が住んでいる地域）についての情報（以下、地域情報）が予め第１のゲーム装置３ａのフラッシュメモリ１７に設定されている。一方、第２のゲーム装置３ｂは、その所有者が配信契約を締結していないため、上記配信サーバ４０から配信を受けることはできない。このような環境で、第１の実施形態では、第１と第２のゲーム装置との間で、同じ通信対戦格闘ゲームを用いて通信対戦を行う場合を例として説明する。

図１０は、第１の実施形態にかかる通信対戦ゲームの通信の流れの概要を示すための図である。本実施形態においては、まず、第１のゲーム装置３ａは、配信サーバ４０に総合天気データの配信要求を行い（Ｓ１）、これに応じて、配信サーバ４０は、総合天気データの配信を行う（Ｓ２）。第１のゲーム装置３ａは、総合天気データを受信し、自機に実装されている不揮発性メモリに保存する。すでに保存されている場合は、新たに受信した総合天気データで更新する（Ｓ３）。

次に、第１のゲーム装置３ａは、マッチングサーバ５０に対して、対戦者受付のためのホスト登録要求を送信する（Ｓ４）。ここで、対戦者受付とは、他のゲーム装置からの接続要求を待つことを言う。つまり、第１のゲーム装置は、接続要求を受け入れる側の立場になる（また、後述するように、天気情報を送信する側にもなる）。以下、このような、受動的に相手側からの接続を待つ側の装置のことをホスト機と呼ぶ。この際、第１のゲーム装置３ａは、マッチングの際の条件として利用可能な、プレイヤに関するゲームデータ（プレイ回数や対戦の勝率等）を付加して送信する。

次に、マッチングサーバ５０では、自己のメモリ上に格納されているホスト機のリスト（以下、ホストリストと呼ぶ）に、第１のゲーム装置３ａを登録する（Ｓ５）。この際、上記登録要求に含まれている当該第１のゲーム装置３ａのネットワークアドレスなど、接続のために必要な情報も併せて登録しておく。また、上記プレイヤに関するゲームデータを併せて登録しておく。

次に、第２のゲーム装置３ｂにおいて、プレイヤの操作に応じてマッチングサーバ５０に対戦者検索の要求を行う（Ｓ６）。この際、プレイヤが任意に検索条件を指定することもできる。ここで、第２のゲーム装置３ｂは、他のゲーム装置（ホスト機）に対して自ら接続を希望する側になる。つまり、他のゲーム装置に対して接続を要求する立場となる（また、後述するように、天気情報を受信する側にもなる）。以下、このような、自分が能動的に接続しにいく側の装置をゲスト機と呼ぶ。

次に、第２のゲーム装置３ｂの検索要求を受けたマッチングサーバ５０は、当該要求（検索条件が指定されていれば、その条件）に応じて、対戦相手候補をホストリストから検索する（Ｓ７）。そして、検索した結果を候補者リストとして、第２のゲーム装置３ｂに送信する（Ｓ８）。ここでは、第１のゲーム装置３ａが候補者リストに含まれているものとする。また、第１のゲーム装置３ａのネットワークアドレスも併せて含まれているものとする。

次に、候補者リストを受信した第２のゲーム装置３ｂでは、当該候補者リストを画面に表示し、プレイヤの選択操作に応じて、第１のゲーム装置３ａを対戦相手として選択する（Ｓ９）。そして、候補者リストに含まれている第１のゲーム装置３ａのネットワークアドレスに対して、接続要求を送信する（Ｓ１０）。当該接続要求は、例えば、第２のゲーム装置３ｂから第１のゲーム装置３ａへの「上りコネクション」の確立を要求するＳＹＮビット等である。

第１のゲーム装置３ａでは、当該接続要求に対して、接続を許可するか否かを判定する（Ｓ１１）。ここでは、接続は許可するものとする。そして、接続許可した旨の接続承認情報を第２のゲーム装置３ｂに送信する（例えば、ＡＣＫビット等）。このとき、当該接続承認情報には、第１のゲーム装置３ａから第２のゲーム装置３ｂへの「下りコネクション」の確立を要求する接続要求が含まれる（例えばＳＹＮビット）。次に、第２のゲーム装置３ｂでは、当該接続承認情報を受信する（Ｓ１２）。この際、図示はしないが、当該接続承認情報に含まれる「下りコネクション」の確立の接続要求に対して肯定応答（例えばＡＣＫビット）を送信する。これにより、第１と第２のゲーム装置の間で、通信対戦のためのコネクションが確立する。なお、第１のゲーム装置３ａと第２のゲーム装置３ｂとの間の通信プロトコルは、処理速度を優先して、例えばＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）のようなコネクションレス型通信を用いるようにしても良い。

次に、第１のゲーム装置３ａでは、配信サーバ４０から受けた総合天気データの中から、自機に設定されている地域情報に基づいて、当該地域の天気情報（晴れ、曇り、雨等）を検索し、取得する（Ｓ１３）。続いて、第１のゲーム装置３ａは、検索した天気情報をゲーム処理に反映する（Ｓ１４）。例えば、天気情報が「雨」を示す内容であれば、これから対戦するステージ（仮想空間）に雨を降らせる処理が行われる。

次に、第１のゲーム装置３ａは、取得した天気情報を、第２のゲーム装置３ｂに送信する（Ｓ１５）。これに応じて、第２のゲーム装置３ｂは、当該天気情報を受信する（Ｓ１６）。

次に、第２のゲーム装置３ｂは、受信した天気情報をゲーム処理に反映する（Ｓ１７）。例えば、天気情報が「雨」を示す内容であれば、これから対戦するステージ（仮想空間）に雨を降らせる処理が行われる。

そして、第１と第２のゲーム装置の間でゲームデータ、例えば操作データ等の送受信が行われつつ、通信対戦が行われる（Ｓ１８，Ｓ１９）。その結果、双方とも、雨が降っている仮想空間内で対戦することになる。そのため、第２のゲーム装置３ｂが設置されている地域では、実際の天気が「晴れ」であっても、仮想空間内においては、雨が降っているステージで対戦する。そのため、第２のゲーム装置３ｂのプレイヤに、あたかも第１のゲーム装置３ａのある地域に出向いて対戦しているかのような印象を与えることができる。

次に、本実施形態で用いられる各種データについて説明する。まず、各ゲーム装置で用いられるデータについて説明する。図１１は、図２に示した外部メインメモリ１２のメモリマップを示す図である。図１１において、外部メインメモリ１２は、ゲームプログラム領域１２１、データ記憶領域１２６、作業領域１２９を含む。ゲームプログラム領域１２１およびデータ記憶領域１２６のデータは、ディスク４に予め記憶されたものが、ゲーム処理に際して外部メインメモリ１２にコピーされたものである。

ゲームプログラム領域１２１には、後述する図２２〜図２６等のフローチャートの処理をＣＰＵ１０によって実現するためのメインプログラム１２２、ホスト処理プログラム１２３、ゲスト処理プログラム１２４、通信対戦処理プログラム１２５が記憶される。この他、図示はしないが、ゲーム処理に必要な各種プログラムも記憶される。データ記憶領域１２６には、通信対戦ゲームを実行するために必要なゲームデータ１２７および、マッチングサーバ５０へ接続するため各種情報であるマッチングサーバ接続データ１２８が記憶される。ゲームデータ１２７には、例えば、対戦の舞台となる仮想空間（ステージ）データやキャラクタオブジェクトデータなどが含まれている。また、マッチングサーバ接続データ１２８は、マッチングサーバのネットワークアドレスや、接続する際に用いるポート番号等の情報が含まれている。

作業領域１２９は、対戦ゲーム処理において、一時的に用いられるデータが格納される領域である。作業領域１２９には、天気情報１３０が格納される。当該天気情報１３０は、後述の天気情報マスタ１７６の天気情報１７６２をコピーしたデータである。

図１２は、図２に示したフラッシュメモリ３８のメモリマップを示す図である。上述のように、フラッシュメモリ３８は不揮発的なメモリであるため、以下に説明するデータは、ゲーム装置３の電源がオフとされても、消去されずに記憶され続ける。図１２において、フラッシュメモリ３８は、天気データ記憶領域１７１、地域コード１７７および通信許可フラグ１８０を含む。天気データ記憶領域１７１には、配信サーバ接続データ１７２、総合天気データ１７３、国名マスタ１７４、地域名マスタ１７５、天気情報マスタ１７６などのデータが記憶される。なお、これらのデータは、ゲームプログラム実行時には上記外部メインメモリ１２に転送されて記憶されてもよい。また、ここでは説明の便宜上、各データをテーブルデータの形式で説明するが、これらのデータは、実際にテーブルデータの形式で記憶されている必要はなく、ゲームプログラムにおいて、このテーブルに相当する内容の処理が記憶されていればよい。

配信サーバ接続データ１７２は、ゲーム装置３が、上記配信サーバ４０へ接続するためのデータ（配信サーバ４０のネットワークアドレスやユーザＩＤ、パスワード等）である。また、定期的に配信サーバ４０に接続させる場合は、スケジューリング情報として、配信サーバ４０に接続する時間（例えば毎日午前６：００）についての情報が含まれる。

総合天気データ１７３は、世界各国の天気について、その地域ごと（一般的には、観測点単位）に区分けして示すデータである。図１３は、総合天気データ１７３のデータ構造の一例を示した図である。総合天気データ１７３は、地域コード１７３１と天気コード１７３２との集合から成る。また、地域コード１７３１は、国コード１７３３と詳細コード１７３４との集合からなる。国コード１７３３は、例えば、「アメリカ」「日本」等の、国を示すためのコードである。後述の国名マスタ１７４の、国コード１７４１に対応する。詳細コード１７３４は、国コード１７３３との組み合わせにより、当該国における各地域、例えば、「日本」における「東京」「大阪」、「アメリカ」における「ワシントン」「カリフォルニア」のような、地域を特定するためのコードである。

次に、図１４は、国名マスタ１７４のデータ構造の一例を示した図である。国名マスタ１７４は、上述の国コードで示される具体的な国の名称を示すためのデータであり、国コード１７４１と、国名１７４２との集合から成る。国コード１７４１は、上述の総合天気データ１７３の国コード１７３３に対応する。

図１５は、地域名マスタ１７５のデータ構造の一例を示した図である。地域名マスタ１７５は、上述の地域コード１７３１（国コード１７３３と詳細コード１７３４との組み合わせ）により特定される地域の具体的な名称を示すためのデータである。総合天気データ１７３の地域コード１７３１に対応する地域コード１７５１（国コード１７５２と詳細コード１７５３とを含む）と地域名１７５４との集合から成る。

図１６は、天気情報マスタ１７６のデータ構造の一例を示した図である。天気情報マスタ１７６は、上記天気コード１７３２により示される天気の具体的な内容を示すためのデータである。天気情報マスタ１７６は、天気コード１７６１と天気情報１７６２との集合から成る。天気情報１７６２が、具体的な天気の内容を示すデータである。

図１２に戻り、地域コード１７７は、ゲーム装置３が設置されている地域（一般的に、ゲーム装置３の所有者の住所）を示すコードである。上記総合天気データ１７３の、地域コード１７３１と対応するデータであり、国コード１７８と詳細コード１７９との組み合わせからなる。

ここで、上述の天気データ記憶領域１７１に記憶される各種データは、本来的な用途としては、例えば、気象情報提供アプリケーションのような専用のアプリケーションに用いられるものである。当該気象情報提供アプリケーションは、フラッシュメモリ１７に記憶されており、図示しないメニューアプリケーション（フラッシュメモリ３８に記憶される）により当該専用アプリケーションの起動が指示されたときに、外部メインメモリ１２上に展開されて実行される。そして、天気予報等の気象情報をプレイヤに提供するアプリケーションである。しかし、本実施形態は、当該気象情報提供アプリケーション向けのデータを、上述のような通信対戦ゲーム等に流用するものである。

ここで、地域コード１７７の設定・変更について補足説明する。上述のように、地域コード１７７は、国コード１７８と詳細コード１７９との組み合わせからなるが、このうち、国コード１７８については、ゲーム装置３が出荷される前に予めメーカー側で設定され、プレイヤが変更できないように設定される。一方、詳細コード１７９については、プレイヤ側で変更可能なように設定される。つまり、例えば、日本向けに出荷されるゲーム装置３については、国コード１７８は「日本」を示すコードに固定される。詳細コード１７９については、当該ゲーム装置を入手した各プレイヤが、各自で自己の住んでいる地域を示す値を設定する。また、プレイヤが行う当該設定作業については、上述のような通信対戦ゲームプログラムではなく、上記気象情報提供アプリケーションによってのみ可能である。これにより、不要なデータの改竄を防止せしめることができる。

次に、通信許可フラグ１８０は、ゲーム装置３が、他のゲーム装置との通信を行うことを許可するか否かを示すためのフラグである。当該フラグがオンに設定されているゲーム装置３は、他のゲーム装置３との通信を行うことができる。一方、オフに設定されているゲーム装置３は、他のゲーム装置３との通信を行うことはできない。そのため、当該フラグがオフに設定されているゲーム装置３で通信対戦ゲームを実行しても、実際は通信対戦はできないことになる。なお、当該フラグのオン／オフの設定は、上記メニューアプリケーションから実行される、図示しない専用の本体設定アプリケーションにおいて可能である。

次に、配信サーバ４０で用いられるデータについて説明する。図１７は、配信サーバにおけるメモリ４２ａのメモリマップを示す図である。メモリ４２ａは、プログラム記憶領域４２１およびデータ記憶領域４２２を含む。プログラム記憶領域４２１には、天気データの配信を行うための配信処理プログラム４２３等が記憶される。また、データ記憶領域４２２には、総合天気データ４２４および配信先データ４２５等が記憶される。

総合天気データ４２４は、図示しない別のサーバ等から、所定の観測点から得られた観測データの提供を受け、当該データに基づいて、配信サーバ４０において生成されるデータである。同時に、上記ゲーム装置３に記憶される総合天気データ１７３の元となるデータでもある。そのレイアウトや内容は、上述した総合天気データ１７３と同様であるため、詳細な説明は省略する。配信先データ４２５は、配信先となるゲーム装置のネットワークアドレスなどが含まれているデータである。

次に、マッチングサーバ５０で用いられるデータについて説明する。図１８は、マッチングサーバ５０におけるメモリ４２ｂのメモリマップを示す図である。マッチングサーバ５０のメモリ４２ｂには、プログラム記憶領域５１１およびデータ記憶領域５１２が含まれる。プログラム記憶領域５１１には、マッチング処理を行うためのマッチングプログラム５１３等が記憶され、データ記憶領域には、ホストリスト５１４が記憶される。

ホストリスト５１４は、図１９に示すように、装置名５１４１と、アドレス情報５１４２、プレイヤデータ５１４３の集合からなる。装置名５１４１は、各ゲーム装置３について、それぞれのプレイヤが設定した名称である。アドレス情報５１４２は、各ゲーム装置と通信するために必要な情報である。例えば、ゲーム装置が設置されている各家庭のルータのＩＰアドレスや、通信対戦に使うためのポート番号、各ゲーム装置に固有のＭＡＣアドレスなどが含まれている。プレイヤデータ５１４３は、マッチングの際の条件として利用可能な、プレイヤに関するゲームデータ、例えば、プレイ回数や対戦の勝率等のデータである。

次に、図２０〜図２６を参照して、第１の実施形態にかかる通信対戦処理について説明する。本実施形態においては、上述したように、ゲーム装置３は常時接続型のネットワークを介して、相互に接続されている。また、各ゲーム装置３は、スタンバイモード等への移行も含め、２４時間稼働している状態である。

まず、第１のゲーム装置３ａが配信サーバから総合天気データを取得する動作（図１０のＳ１〜Ｓ３に相当）について説明し、その後、第１のゲーム装置３ａと第２のゲーム装置３ｂで実行される処理（図１０のＳ４以降に相当）について説明する。なお、説明の便宜上、以下では、第１のゲーム装置３ａをホスト機、第２のゲーム装置３ｂをゲスト機と呼ぶ。

図２０はホスト機によって実行される総合天気データ取得処理を示すフローチャートである。また、図２１は、配信サーバ４０で実行される配信処理を示すフローチャートである。

まず、ホスト機のＣＰＵ１０は、図示しない本体内蔵時計、および、予め設定されているスケジューリング情報に基づいて、総合天気データ１７３の取得時間（例えば午前７：００）になったか否かを判定する（ステップＳ１０１）。

その結果、総合天気データ１７３の取得時間になっていないときは（ステップＳ１０１でＮＯ）、そのまま処理を終了する。一方、取得時間になったときは（ステップＳ１０１でＹＥＳ）、ＣＰＵ１０は、配信サーバ４０への配信要求を行う（ステップＳ１０２）。このステップＳ１０２の処理をより具体的に説明すると、まず、ＣＰＵは、配信要求を示すデータ（例えばネットワークパケット）を生成する。次に、ＣＰＵ１０は、フラッシュメモリ１７から、配信サーバ４０に接続するための接続情報を読み出す。続いて、ＣＰＵ１０は、当該情報に基づき、無線通信モジュール１８を介して配信サーバ４０へとアクセスする。そして、ＣＰＵ１０は、上記配信要求を示すデータを配信サーバ４０へと送信する。配信サーバ４０では、当該配信要求に応じて、配信サーバ４０のメモリ４２ａに記憶されている総合天気データ４２４を配信する（後述の図２１のステップＳ１０６）。

次に、ＣＰＵ１０は、配信サーバ４０から送信されてくる総合天気データ４２４の受信が完了したか否かを判定する（ステップＳ１０３）。その結果、まだ受信が完了していないときは（ステップＳ１０３でＮＯ）、受信が完了するまで待つ。一方、受信が完了すれば（ステップＳ１０３でＹＥＳ）、ＣＰＵ１０は、受信した総合天気データ４２４で、フラッシュメモリ１７に記憶されている総合天気データ１７３を更新する（ステップＳ１０４）。以上で、ホスト機にかかる天気データ取得処理は終了する。

次に、配信サーバ４０の配信処理について図２１を用いて説明する。図２１において、まず、配信サーバ４０のＣＰＵ４３は、いずれかのゲーム装置３から配信要求が送信されてきたか否かを判定する（ステップＳ１０５）。配信要求がされてこなければ（ステップＳ１０５でＮＯ）、配信サーバ４０における処理は終了する。配信要求が送信されてくれば（ステップＳ１０５でＹＥＳ）、所定の認証処理を行った後に、メモリ４２から総合天気データ４２４を読み出して、配信要求を送信してきたゲーム装置３に対して当該総合天気データ４２４を送信する（ステップＳ１０６）。以上で、配信サーバ４０における処理は終了する。

次に、ホスト機とゲスト機との間で行われる通信対戦ゲーム処理について説明する。図２２は、第１の実施形態にかかるゲーム装置３の通信対戦処理を示すフローチャートである。ここで、上記ホスト機、およびゲスト機双方とも、図２２で示す処理が行われる。そして、以下に説明するような処理の分岐（ステップＳ１１３の結果）によって、ホスト機になる場合もあり、ゲスト機となる場合もある。つまり、ゲーム装置３は、共通の通信対戦ゲームプログラムを実行するが、各ゲーム装置３おける処理内容によって、ホスト機にもゲスト機にもなり得る。

本実施形態にかかる通信対戦ゲームプログラムの実行開始がプレイヤの操作によって指示されると、光ディスク４に記憶された通信対戦ゲームプログラムが外部メインメモリ１２に読み込まれ、ＣＰＵ１０によって当該ゲームプログラムの実行が開始される。図２２に示すフローチャートは、以上の処理が完了した後に行われるゲーム処理を示すフローチャートである。図２２において、まず、ＣＰＵ１０は、各種データやフラグ等の初期化を行うための初期設定処理を行う（ステップＳ１１１）。

次に、ＣＰＵ１０は、フラッシュメモリ１７に記憶されている通信許可フラグ１８０を参照し、自機が他のゲーム装置との通信を許可する設定となっているか否かを判定する（ステップＳ１１２）。その結果、通信が許可されていないときは（ステップＳ１１２でＮＯ）、ＣＰＵ１０は、非通信ゲーム処理を行う（ステップＳ１１６）。当該非通信ゲーム処理は、例えば、他のプレイヤ（他のゲーム装置）との通信は行わずに、プレイヤが一人で遊ぶためのゲーム処理である（シングルプレイモード等）。

一方、通信が許可されているときは（ステップＳ１１２でＹＥＳ）、続いて、ＣＰＵ１０は、プレイヤの指示に基づいて、対戦相手を受け付けるか否かの判定を行う（ステップＳ１１３）。つまり、自機がホスト機となって他のプレイヤから対戦要求（接続要求）が来るのを待つか、ゲスト機となって、自ら他のプレイヤのゲーム機に対戦要求を行うのかを判定する。

ステップＳ１１３の判定の結果、対戦相手を受け付けるときは（ステップＳ１１３でＹＥＳ）、自機がホスト機としての処理を行うことになるため、ホスト処理を行う（ステップＳ１１４）。当該ホスト処理の詳細は後述する。一方、対戦相手を受け付けないときは（ステップＳ１１３でＮＯ）、自機がゲスト機としての処理を行うことになるため、ゲスト処理を行う（ステップＳ１１５）。当該ゲスト処理の詳細も後述する。つまり、当該ステップＳ１１３の判定の結果によって、ゲーム装置３は、ホスト機となるかゲスト機となるかが決定されることになる。

次に、ＣＰＵ１０は、プレイヤの指示操作等に基づき、通信対戦ゲームを終了するか否かを判定する（ステップＳ１１７）。ＹＥＳの場合、ゲーム処理を終了し、ＮＯの場合、ステップＳ１１２に戻って、通信対戦ゲーム処理を繰り返す。

次に、上記ステップＳ１１４で示したホスト処理について説明する。図２３は、上記ステップＳ１１４で示したホスト処理の詳細を示すフローチャートである。図２３において、まず、マッチングサーバ５０へのホストとしての登録依頼を行う（ステップＳ１２１）。この処理は、図１０のＳ４の処理に相当する。このステップＳ１２１の処理をより具体的に説明すると、まず、ＣＰＵ１０は、外部メインメモリ１２から、マッチングサーバ接続データ１２８を読み出す。続いて、当該データに基づいて、マッチングサーバ５０への接続処理を行い、ホスト登録要求の旨の登録要求データを送信する。当該登録要求データには、自己のネットワークアドレスや、通信対戦の際に用いられるポート番号等のデータが含まれる。更に、当該登録要求を行ったプレイヤの現在までの対戦回数や勝率などの情報が含まれている。マッチングサーバ５０では、これに応じて、マッチングサーバ５０のメモリ４２に記憶されているホストリスト５１４へ、受信した登録要求データに基づくゲーム装置３の登録処理を行う（図１０のＳ５の処理に相当）。

マッチングサーバ５０へのホスト登録が終われば、次に、ホスト機のＣＰＵ１０は、接続要求受信可能な状態で待機する。そして、所定時間内に接続要求を受信したか否かを判定する（ステップＳ１２２）。当該判定の結果、所定時間内に接続要求を受信したときは（ステップＳ１２２でＹＥＳ）、ＣＰＵ１０は、当該接続要求を送信してきたゲーム装置３、すなわちゲスト機との通信対戦のための接続を許可するか否かを判定する（ステップＳ１２３；図１０のＳ１１に相当）。ここで、許可しない場合の例としては、例えば、フレンドリストと呼ばれる、プレイヤの友達のみを登録したリストデータ（例えばフラッシュメモリ１７に記憶される）に登録されたゲーム装置３ではない場合に、接続を許可しないとすることが考えられる。その他、予め特定のプレイヤと対戦の約束をしていた場合に、接続要求を受信する度に、相手の情報を画面に表示し、プレイヤが、当該約束をしていたプレイヤ以外からの接続要求を拒否するための操作を行うことで、許可しないという場合も考えられる。

ステップＳ１２３の判定の結果、接続を許可しないと判定したときは（ステップＳ１２３でＮＯ）、ＣＰＵ１０は、ステップＳ１２２に戻って処理を繰り返す。一方、接続を許可すると判定したときは（ステップＳ１２３でＹＥＳ）、ＣＰＵ１０は、接続要求を送信してきたゲーム装置３に対して、接続を許可することを伝えるための接続承認情報を送信する（ステップＳ１２４）。

接続承認情報を送信する、もしくはステップＳ１２２で所定時間内に接続要求を受信しなければ、次に、ＣＰＵ１０は、自機の設置されている地域の天気を示す天気情報を読み出すための天気更新処理を行う（ステップＳ１２５）。図２４は、上記ステップＳ１２５で示した天気更新処理の詳細を示すフローチャートである。図２４において、まず、ＣＰＵ１０は、自機に保存されている地域コード１７７に基づいて天気情報を読み出す処理を行う（ステップＳ１５１；図１０のＳ１３に相当）。このステップＳ１５１の処理をより具体的に説明すると、まず、ＣＰＵ１０は、フラッシュメモリ１７に記憶されている地域コード１７７を読み出す。続いて、ＣＰＵ１０は、当該地域コード１７７をキーとして、上記配信サーバ４０から配信され、外部メインメモリ１２に記憶している総合天気データ１７３から該当する地域コード１７３１を検索する。そして、検索した地域コード１７３１に対応づけられている天気コード１７３２を読み出す。続いて、ＣＰＵ１０は、当該読み出した天気コード１７３２をキーとして、天気情報マスタ１７６から天気情報１７６２を検索し、読み出す。そして、ＣＰＵ１０は、読み出した天気情報１７６２を、作業領域１２９に天気情報１３０としてコピーする。以上で、ＣＰＵ１０は、自機の設置されている地域の天気情報を取得することができる。

次に、ＣＰＵ１０は、作業領域１２９に記憶されている天気情報１３０で示される天気を、対戦の舞台となるステージ（仮想空間）に反映するための処理を行う（ステップＳ１５２；図１０のＳ１４に相当）。例えば、天気情報１３０が「雪」を示していれば、ステージに雪を降らせる処理、例えば天気を示すフラグに「雪」を設定する等の処理を行う。あるいは、ステージを雪が積もった状態とする処理を行う。このとき、後に説明する通信ゲーム処理（ステップＳ１２７）において、雪が積もったステージでは、雪が積もっていないときに比べ、キャラクタの移動速度を低下させるような処理を行うようにしてもよい。また、所定の必殺技について、ステージに雪が積もっているときのみ使用可能なように予め設定しておき、当該必殺技を使用可能とするようにフラグを設定するようにしてもよい。以上で、天気更新処理が終了する。

図２２に戻り、天気更新処理が終われば、ＣＰＵ１０は、接続承認情報を送信したか否かを判定する（ステップＳ１２６）。つまり、上記ステップＳ１２４の処理が行われたか否かを判定する。その結果、接続承認情報を送信していたときは（ステップＳ１２６でＹＥＳ）、接続相手とネットワークを介して対戦格闘を行うための通信ゲーム処理が行われる（ステップＳ１２７）。図２５は、上記ステップＳ１２７で示した通信ゲーム処理の詳細を示すフローチャートである。図２５において、まず、ＣＰＵ１０は、接続承認情報を送信したゲーム装置（つまり、ゲスト機）に対して、上記天気情報１３０を送信する（ステップＳ１６１）。つまり、自己の地域の天気の情報をゲスト機に送信することになる（図１０のＳ１５の処理に相当）。

次に、対戦ゲームデータの送受信等の、その他の通信対戦格闘ゲームに関する処理が行われる（ステップＳ１６２；図１０のＳ１８に相当）。例えば、ホスト機のプレイヤの操作に基づいたプレイヤキャラクタの移動や技の表示、および、当該操作データのゲスト機への送信や、ゲスト機のプレイヤが行った操作データの受信、および、これに基づいた対戦相手の行動の画面への表示等、対戦格闘に関するゲーム処理が行われる。なお、これら送受信されるゲームデータについても、天気情報が反映されたゲームデータを送受信するようにしても良い。例えば、天気情報が「雪」の場合、対戦の舞台となるステージに雪が積もっているよう設定すると共に、各プレイヤキャラクタの移動速度を雪が積もっていないときよりも低下させるように設定したとする（通常であれば単位時間内の移動距離が１であるところ、雪が積もっているときは、移動距離を５とする、等）。この場合は、送受信される操作データ（例えば、キャラクタの移動距離）については、雪の影響を反映させた後の操作データを送受信するようにしてもよい。もちろん、雪の影響を反映させる前の操作データを送受信して、受信した側のゲーム装置において雪の影響を反映させるように処理を行っても良い。以上で、通信ゲーム処理は終了する。

図２２に戻り、上記ステップＳ１２６の判定の結果、接続承認情報を送信していないときは（ステップＳ１２６でＮＯ）、ネットワークを介さない対戦ゲーム処理を行う（ステップＳ１２８）。つまり、対戦相手を受け付けたものの、所定時間内に対戦希望者が現れなかったために、ＣＰＵ１０がプレイヤの対戦相手を努める、シングルプレイでの対戦ゲームが行われる（上記ステップＳ１１６の非通信ゲーム処理と同等の処理が行われることになる）。なお、第１の実施形態では、ホスト機１台とゲスト機１台との接続例について述べられているが、ホスト機１台に対してゲスト機が複数台で構成することも可能である。その場合には、接続承認情報の送信を複数のゲスト機のうち少なくとも１台に対して行ってさえいればＳ１２６では接続承認情報を送信していたと判定し（ステップＳ１２６でＹＥＳ）、接続承認情報の送信をいずれのゲスト機に対しても行っていなければＳ１２６では接続承認情報を送信していないと判定する（ステップＳ１２６でＮＯ）ようにすれば良い。さらに、接続承認情報の送信をゲスト機に対して行ってから対戦ゲームが始まった以降に、当該ゲスト機が接続を切断することも考えられる。このような切断時にも対応できるように、例えばホスト機側ではゲスト機の現時点での接続数を作業領域１２９に格納させて、当該接続数が０であるかどうかをＳ１２６で判定させることも考えられる。すなわち、接続数が０であれば、接続承認情報を送信していない時と同様の処理を行い（ステップＳ１２６でＮＯ）、接続数が１以上であれば、接続承認情報を送信した時と同様の処理を行う（ステップＳ１２６でＹＥＳ）。以上で、ホスト処理は終了する。

次に、上記ステップＳ１１５で示したゲスト処理について説明する。図２６は、上記ステップＳ１１５で示したゲスト処理の詳細を示すフローチャートである。図２６において、まず、ゲスト機のＣＰＵ１０は、対戦相手となるホスト機とのコネクションが確立済みであるか否かを判定する（ステップＳ１３１）。具体的には、上述したようなホスト機から送信されてくる接続承認情報を既に受信したか否かを判定する。当該判定の結果、既にホスト機とのコネクションが確立していれば（ステップＳ１３１でＹＥＳ）、ＣＰＵ１０は、後述するステップＳ１３７の処理へと進む。

一方、コネクションがまだ確立していないときは（ステップＳ１３１でＮＯ）、ＣＰＵ１０は、上記マッチングサーバ５０へ、対戦相手の検索要求を送信する（ステップＳ１３２；図１０のＳ６に相当）。このステップＳ１３２の処理をより具体的に説明すると、まず、ＣＰＵ１０は、外部メインメモリ１２に格納されているマッチングサーバ接続データ１２８を読み出す。上述のように、当該データには、マッチングサーバ５０のネットワークアドレス等が含まれている。そのため、ＣＰＵ１０は、当該データに基づいて、マッチングサーバ５０にアクセスすることができる。そして、ＣＰＵ１０は、マッチングサーバ５０に対して、対戦相手を検索する旨の要求を送信する。この際、プレイヤに関する情報、例えば累計対戦回数や勝率などのデータを付加して送信する。その他、ユーザの入力操作等に基づいた検索条件を付加して送信するようにしてもよい。

上記検索要求を受信したマッチングサーバ５０のＣＰＵ４３は、自機のメモリ４２ｂに格納されている上記ホストリスト５１４から、上記対戦相手を検索する（図１０のＳ７の処理に相当）。この際、マッチングサーバでは、例えば、上記対戦回数や勝率などの情報に基づいて、近似する勝率を有するプレイヤにかかるゲーム装置（ホスト機）を検索する。そして、マッチングサーバ５０のＣＰＵ４３は、検索した結果に基づいて候補者リスト（図示せず）を生成する。続けて、当該生成した候補者リストを、検索要求を送信してきたゲスト機に対して送信する（図１０のＳ８の処理に相当）。当該候補者リストには、各ホスト機のネットワークアドレス等、接続するために必要な情報も格納されている。

図２６に戻り、マッチングサーバへの検索要求を送信した後、ホスト機のＣＰＵ１０は、マッチングサーバから送信されてくる上記候補者リストを受信し、作業領域１２９に記憶する（ステップＳ１３３）。次に、ＣＰＵ１０は、当該候補者リストを画面に表示することでプレイヤに提示する。プレイヤは、当該候補者リストから、所望のホスト機を選択する操作を行う。ＣＰＵ１０は、当該選択操作に基づいて、対戦相手となるホスト機を選択し、そのネットワークアドレス等を候補者リストから読み出す（ステップＳ１３４；図１０のＳ９に相当）。

次に、ＣＰＵ１０は、ステップＳ１３４で選択したホスト機（のネットワークアドレス）に対して、接続要求を送信する（ステップＳ１３５；図１０のＳ１０に相当）。これに応じて、ホスト機では、上述したような接続を許可するか否かの判定処理が行われる。その結果、接続が許可された場合は、上記接続承認情報がホスト機から送信されてくる。

次に、ゲスト機のＣＰＵ１０は、所定時間内に接続承認情報を受信したか否かを判定する（ステップＳ１３６）。その結果、受信していないときは（ステップＳ１３６でＮＯ）、所定の待ち時間が経過したか否かを判定する（ステップＳ１４０）。当該判定の結果、所定の待ち時間が経過していなければ（ステップＳ１４０でＮＯ）、ＣＰＵ１０は、ステップＳ１３６の処理に戻り、処理を繰り返す。一方、所定の待ち時間が経過したときは（ステップＳ１４０でＹＥＳ）、ＣＰＵ１０は、タイムアウトの旨の表示を行う（ステップＳ１４１）。そして、上記図２２のステップＳ１１３の処理へと戻り、処理を繰り返す。また、接続承認情報が何らかの原因でホスト機に辿りつく前に欠落してしまう恐れがある。その場合の対応として、所定時間内に接続承認情報を受信していないと判定された（ステップＳ１３６でＮＯ）後に、再送信を行う所定時間間隔だけ時間が経過したかどうかを判定し、もし再送信を行う所定時間間隔だけ時間が経過していれば、ステップ１３５の処理に戻り、再送信を行う所定時間間隔だけ時間が経過していなければ、ステップ１４０へ進むようにしても良い。

一方、上記ステップＳ１３６の判定の結果、接続承認情報を所定時間内に受信したときは（ステップＳ１３６でＹＥＳ）、これをもってゲスト機とホスト機との間のコネクションが確立したことになる。そして、上述のように、続けて天気情報１３０がホスト機から送信されてくるため、当該天気情報１３０の受信を行う。受信が完了すれば、当該ホスト機から送信された天気情報１３０を作業領域１２９に記憶する。（ステップＳ１３７；図１０のＳ１６に相当）。

次に、ＣＰＵ１０は、天気情報１３０が示す天気を、対戦の舞台となるステージ（仮想空間）に反映するための処理を行う（ステップＳ１３８；図１０のＳ１７に相当）。本処理は、上述した図２４のステップＳ１５２（ホスト機における天気の反映処理）と同様であるため、詳細な説明は省略するが、結果的に、ホスト機の地域の天気が、ゲスト機におけるステージに反映されることになる。

次に、対戦ゲームデータの送受信等の、その他の通信対戦格闘ゲームに関する処理が行われる（ステップＳ１３９；図１０のＳ１９に相当）。本処理では、上記図２５で説明したステップＳ１６２のその他の通信ゲーム処理と同様の処理が行われる。つまり、ゲスト機のプレイヤの操作に基づいたプレイヤキャラクタの移動や技の表示、および、当該操作データのホスト機への送信や、ホスト機のプレイヤが行った操作データの受信、および、これに基づいた対戦相手の行動の画面への表示等、対戦格闘に関するゲーム処理が行われる。但し、当該対戦の舞台となるステージについては、上述のように、ホスト機の地域の天気が反映されたものとなる。以上で、通信ゲーム処理は終了する。

以上で、第１の実施形態にかかる通信対戦ゲーム処理は終了する。

このように、第１の実施形態では、ネットワークを介した通信対戦ゲームを行う際に、通信相手（ホスト機）の住んでいる地域の天気を、自分のゲーム装置（ゲスト機）のゲーム処理に反映することができる。これにより、例えば、ゲスト機のプレイヤの地域の天気が晴れであっても、通信対戦を行っているステージに雨が降っているような場合、通信相手の地域では現在雨が降っていることをプレイヤは認識することができる。その結果、あたかも通信相手の地域に出向いてプレイをしているかのごとき印象をプレイヤに与えることが可能となり、通信対戦ゲーム等の興趣を高めることが可能となる。

なお、上述した、ホスト機からゲスト機への天気情報の送信について、例えば週間天気予報のように、１週間分の天気にかかる情報を送信するようにしても良い。そして、１週間分の天気情報を受信したゲスト機では、例えば、通信対戦を行った日の翌日に一人用でプレイする際に、その前日に受信した１週間分の天気情報に基づいて、ホスト機の当日の天気をゲスト機のゲーム処理において反映するようにしてもよい。これにより、ゲスト機のプレイヤは、先日対戦したホスト機のプレイヤにかかる地域の天気を認識することが可能となり、また、単調なゲーム展開となることを防いで、飽きのこないゲームをプレイヤに提供することが可能となる。

また、上述のような天気情報として、気温や湿度、風速などの気象に関する情報も送るようにしても良い。そして、ゲーム処理において、当該気温や湿度や風速を反映するようにしてもよい。例えば、気温が低い場合は、厚着をしたキャラクタを表示するようにしたり、気温が高い場合は、薄着であって、汗をかいているキャラクタを表示するようにしたりしてもよい。また、風速が強い場合は、仮想空間内において向かい風となる状態のときは、キャラクタの移動速度を低下させ、追い風となるときは移動速度を高めるようにしてもよい。これにより、ゲスト機のプレイヤはホスト機の地域にかかる気象状況をよりリアルに認識することができ、通信対戦ゲームの楽しさをより高めることが可能となる。

また、通信を行うゲームについても、上記のような対戦型のゲームに限らない。例えば、プレイヤそれぞれが仮想ゲーム空間内に自分の村や街を持ち、これを発展させていくような、いわゆる都市発展型シミュレーション、あるいは都市開発型シミュレーションゲーム等にも適用することが可能である。この場合、ゲスト機のプレイヤがホスト機から上記天気情報を受信するとともに、ゲームデータとして、ホスト機のプレイヤが開発した街や村のデータを受信するようにする。そして、ゲスト機において、当該受信した天気情報を、当該受信したホスト機の街や村のデータに反映させて、仮想空間内にホスト機の街や村を生成する。そして、当該生成した街や村をゲスト機の画面に表示する。このようにすることで、ゲスト機のプレイヤにホスト機の街や村を訪問したような印象を与えることができる。更に、訪問したホスト機の街や村は、当該ホスト機の地域の天気が反映されて表示される（例えば、雪が積もっている）ため、ゲスト機のプレイヤに、自分の住んでいる地域以外の地域を訪問したかの印象をより強く与えることができ、他のゲーム装置と通信することの楽しさをより高めることができる。その結果、他人とのコミュニケーションを促進することが可能となり、通信ゲームの興趣を更に高めることが可能となる。

（第２の実施形態）
次に、図２７から図３２を参照して、本発明の第２の実施形態について説明する。上述の第１の実施形態では、配信サーバ４０が提供する天気情報配信サービスは、所定の配信契約を締結しているプレイヤのゲーム装置にしか提供されていなかった。そのため、第１のゲーム装置３ａ（ホスト機）のみしか、上記総合天気データ４２４を取得することができなかった。これに対して、第２の実施形態では、配信サービスは、例えば無料サービス等で、第１のゲーム装置３ａのみならず、第２のゲーム装置３ｂ（ゲスト機）も配信を受けることができる。つまり、配信サーバ４０に接続可能なゲーム装置は全て、総合天気データの配信を受けることができる。そのため、第２の実施形態では、第１の実施形態で行っていたような、ホスト機からゲスト機に対しての「天気情報」の送信は行わない。代わりに、ホスト機は、自機に設定されている「地域コード」をゲスト機に送信する。そして、ゲスト機の処理において、当該受信した地域コードに基づいて、上記配信された総合天気データからホスト機の天気情報を検索する。そして、ゲスト機では、当該検索した天気情報を反映し、通信対戦ゲームが行われる。なお、当該実施形態に係るゲーム装置および各サーバは、上述した第１の実施形態と同様であるため、同一の参照符号を付して詳細な説明を省略する。

第２の実施形態では、上記第１の実施形態と同様の通信対戦ゲームを実行することを前提として説明する。図２７は、第２の実施形態にかかる通信対戦ゲームの通信の流れの概要を示すための図である。図２７に示す流れでは、上記図１０で示した第１の実施形態における流れに比して、ゲスト機が総合天気データを取得する点（Ｓ２１、Ｓ２２）と、ゲスト機からの接続要求（Ｓ１０）に対するホスト機の接続許可判定以降（Ｓ１１以降）の処理の流れが異なっており、その他の処理の流れについては、第１の実施形態で説明した内容と同様である。そのため、両図において同一のステップには同一の符号が付されている。以下では、図２７におけるＳ２１、Ｓ２２の処理および、Ｓ１１以降の処理の流れを中心に説明する。

図２７においては、まず、ゲスト機も、ホスト機と同様の処理で配信サーバから総合天気データを取得し、記憶する（Ｓ２１、Ｓ２２）。そのため、ゲスト機のフラッシュメモリ１７にも、上記図１２で示したデータが格納されている。つまり、第２の実施形態においては、ホスト機もゲスト機も、そのデータの持ち方（構造）については同一である。そのため、当該データの内容についての詳細な説明は省略する。

次に、図２７のＳ１１以降の処理の流れについて説明する。ゲスト機からの接続要求を受信したホスト機は、第１の実施形態と同様に、接続許可の判定を行う（Ｓ１１）。その後、接続承認情報をゲスト機に対して送信するが、この際、ホスト機は、自機に設定されている地域コード１７７を読出し、ゲスト機に送信する。

これに応じて、ゲスト機では、接続承認情報およびホスト機の地域コードを受信する（Ｓ２３）。続いて、ホスト機においては、自己の地域コードに基づいて総合天気データから天気情報を検索し、読み出す（Ｓ１３）。一方、ゲスト機では、受信した地域コードをキーとして、総合天気データからホスト機の地域の天気情報を検索して読み出す（Ｓ２４）。そして、ホスト機では、自己の地域コードから検索された天気情報をゲーム処理に反映する（Ｓ１４）。ゲスト機でも、検索した天気情報をゲーム処理に反映するが（Ｓ１７）、当該天気情報はホスト機の地域の天気情報であるため、ゲスト機では、ホスト機の地域の天気を自己のゲーム処理に反映することとなる。その後、対戦ゲーム処理が行われる（Ｓ１８、Ｓ１９）。この結果、双方とも、ホスト機の地域の天気が反映されている仮想ゲーム空間内で対戦を行うことになる。

図２８は、第２の実施形態にかかるゲーム装置３の通信対戦処理を示すフローチャートである。ここで、図２８において、ステップＳ１１１からステップＳ１１３までの処理、およびステップＳ１１７の処理は、上述の第１の実施形態で図２２を用いて説明した処理と同様であるため、ここでは詳細な説明を省略する。また、この処理に先立って、ホスト機、ゲスト機双方とも、上記図２０を用いて説明した処理が行われることで、配信サーバ４０から総合天気データ１７３を取得している。

図２９は、第２の実施形態にかかるホスト処理（ステップＳ２００）の詳細を示すフローチャートである。図２９において、ステップＳ１２１からステップＳ１２３までの処理、および、ステップＳ１２６からステップＳ１２８までの処理は、上述の第１の実施形態で図２３を用いて説明した処理と同様であるため、ここでは詳細な説明を省略する。

図２９のステップＳ１２３における接続許可の判定の結果、ゲスト機の接続を許可したときは（ステップＳ１２３でＹＥＳ）、接続要求を送信してきたゲスト機に、接続承認情報を送信する。このとき、ホスト機のＣＰＵ１０は、フラッシュメモリ１７から地域コード１７７を読出し、接続承認情報と共に、ゲスト機に送信する（ステップＳ２０１）。

次に、ＣＰＵ１０は、第１の天気更新処理を行う（ステップ２０２）。図３０は、当該第１の天気更新処理の詳細を示すフローチャートである。当該第１の天気更新処理は、第１の実施形態で図２５を用いて説明した天気更新処理と同様の処理である。そのため、詳細な説明は省略するが、上記地域コード１７７をキーとして、総合天気データ１７３から天気情報を読み込み（ステップＳ１５１）、ゲーム処理に反映するための処理が行われる（ステップＳ１５２）。

その後の処理は、第１の実施形態と同様であるため、説明は省略する。以上で、第２の実施形態にかかるホスト処理は終了する。

次に、第２の実施形態にかかるゲスト処理（ステップＳ２１０）について説明する。図３１は、第２の実施形態にかかるゲスト処理の詳細を示すフローチャートである。図３１において、ステップＳ１３１からステップＳ１３５までの処理、および、ステップＳ１３９からステップＳ１４１までの処理は、上述の第１の実施形態で図２６を用いて説明した処理と同様であるため、ここでは詳細な説明を省略する。

図３１において、接続要求を送信後（ステップＳ１３５）、上述のように、ホスト機からは、接続承認情報に加え、地域コード１７７が送信されてくる。そのため、ゲスト機のＣＰＵ１０は、接続承認情報および地域コード１７７の受信処理を行い、所定時間内に当該受信が完了したか否かを判定する（ステップＳ２１１）。

当該判定の結果、所定時間内に接続承認情報および地域コード１７７の受信が完了しなければ（ステップＳ２１１でＮＯ）、ＣＰＵ１０は、処理をステップＳ１４０に進める。ステップＳ１４０以降の処理は第１の実施形態と同様であるため、説明は省略する。一方、所定時間内に接続承認情報および地域コード１７７の受信が完了すれば（ステップＳ２１１でＹＥＳ）、ＣＰＵ１０は、第２の天気更新処理を行う（ステップＳ２１２）。図３２は、上記ステップＳ２１２で示した第２の天気更新処理の詳細を示すフローチャートである。図３２において、まず、ＣＰＵ１０は、上記ホスト機から受信した地域コード１７７をキーとして、上記配信サーバから配信された総合天気データ１７３から該当する地域コード１７３１を検索する。そして、検索した地域コード１７３１に対応づけられている天気コード１７３２を読み出す（ステップＳ２１３）。続いて、ＣＰＵ１０は、当該読み出した天気コードをキーとして、天気情報マスタ１７６から天気情報１７６２を検索して読み出す。そして、ＣＰＵ１０は、読み出した天気情報１７６２を、作業領域１２９に天気情報１３０としてコピーする。以上で、ゲスト機のＣＰＵ１０は、ホスト機の設置されている地域の天気情報を取得することができる。

次に、ＣＰＵ１０は、上記天気情報１３０で示される天気を、対戦の舞台となるステージ（仮想空間）に反映するための処理を行う（ステップＳ１５２；図２７のＳ１７に相当）。当該処理内容は、第１の実施形態で説明した処理と同様であるため、詳細な説明は省略するが、当該処理の結果、ゲスト機で生成される仮想空間において、ホスト機の地域の天気が反映されることになる。以上で、第２の天気更新処理は終了する。

第２の天気更新処理が終われば、ＣＰＵ１０は、第１の実施形態と同様の通信ゲーム処理を行う（ステップＳ１３９）。以上で、第２の実施形態に係るゲスト処理は終了する。

このように、第２の実施形態では、ホスト機、ゲスト機を問わずに、ネットワークに接続している全てのゲーム装置が配信サーバから総合天気データの配信を受けることができる環境下において、ホスト機はゲスト機に対して、ホスト機自身に設定されている地域コードを送信する。これを受信したゲスト機は、当該地域コードに基づいて総合天気データを検索することで、ホスト機の地域の天気情報を取得することができる。そして、ゲスト機において当該天気情報をゲーム処理に反映することで、ホスト機の地域での天気下での通信対戦が可能となる。これにより、ゲスト機のプレイヤは、自己の地域の天気に関わらずに、対戦相手が住んでいる地域の天気を反映した仮想ゲーム空間で通信対戦等のゲームをプレイすることが可能となる。

（第３の実施形態）
次に、図３３から図３７を参照して、本発明の第３の実施形態について説明する。本実施形態では、上述の第２の実施形態と同様の通信対戦格闘ゲームを一例として説明する。ここで、当該格闘ゲームにおいて、対戦の舞台となるステージについては、世界各国の地域の名所をモチーフとした仮想空間として構成されるものとする。例えば、日本の場合であれば、「京都」ステージとして、京都の名所の一つである「五重の塔」が存在するような仮想空間のデータが、ゲームデータとして予め設定され、ディスク４に記憶されている。また、「札幌」ステージとして、札幌の名所の一つである「時計台」が存在する仮想空間のデータがゲームデータとして予め設定、記憶されている。同様に、日本国内の地域（各都道府県等）について、その地域を連想させるような名所をモチーフとした仮想空間のデータがゲームデータとして予め設定されて、記憶されているとする。また、これら各ステージのデータは、上述したような地域コードに対応づけられて設定されている。

そして、本実施形態で想定する通信対戦格闘ゲームでは、当該ゲームをプレイヤが購入後、初めてプレイする際は、そのプレイヤの住んでいる地域、つまり、当該プレイヤの所有するゲーム装置に設定されている地域コードに対応するステージしか選択することができないように構成されている。しかし、上述したような通信対戦を、自分がゲスト機となって繰り返し行うことで、その後シングルプレイで遊ぶときにおいて、通信対戦を行った相手（ホスト機）が住んでいる地域のステージも選択できるようになる。併せて、当該地域の天気をゲーム内に反映してプレイすることができる。つまり、上述の通信対戦のように、通信が確立した状態でのプレイのみならず、オフライン時のプレイ（シングルプレイ）においても、以前対戦した相手の地域の天気情報をゲーム処理に反映する。

次に、第３の実施形態に係るゲーム処理で用いられるデータについて説明する。図３３は、図２に示した外部メインメモリ１２のメモリマップを示す図である。図３３において、外部メインメモリ１２は、ゲームプログラム領域１２１、データ記憶領域１２６、作業領域１２９を含む。ゲームプログラム領域１２１およびデータ記憶領域１２６のデータは、ディスク４に予め記憶されたものが、ゲーム処理に際して外部メインメモリ１２にコピーされたものである。ここで、第３の実施形態では、データ記憶領域１２６に、通信地域履歴３０１が含まれていることを除いては、上述した第１、第２の実施形態で説明したデータと同じデータが同じ構造で記憶される。そのため、通信地域履歴３０１以外のデータの説明は省略する。

通信地域履歴３０１は、上述の第２の実施形態で説明したような、通信対戦を行ったゲーム装置から送られてくる上記地域コードを記憶するためのデータである。図３４に示すように、通信地域履歴３０１には、地域コード３０２が最終通信日時３０３と共に記憶される。なお、当該データは、通信対戦ゲーム実行中は、上述のように外部メインメモリ１２に読み込まれて用いられるが、当該通信対戦ゲームが終了する際には、いわゆるセーブデータの一部として、フラッシュメモリ１７に記憶される。そして、次に通信対戦ゲームが開始されたときに、当該フラッシュメモリ１７から読み込まれ、図３３に示したように、外部メインメモリ１２に展開される。

次に、第３の実施形態にかかる通信対戦ゲーム処理の詳細を説明する。図３５は、第３の実施形態にかかるゲーム装置３の通信対戦処理を示すフローチャートである。ここで、第３の実施形態にかかる処理は、ステップＳ３００のゲスト処理およびステップＳ３１０の非通信ゲーム処理を除いて、第２の実施形態の処理と同様である。そのため、ここでは、ゲスト処理および非通信ゲーム処理を中心として説明する。

図３６は、第３の実施形態にかかるゲスト処理（ステップＳ３００）の詳細を示すフローチャートである。図３６においては、ステップＳ３０１の処理を除いて、上述の第２の実施形態で図３１を用いて説明したゲスト処理と同様であるため、ステップＳ３０１以外の処理については、ここでは詳細な説明を省略する。

上記第２の天気更新処理の次に、ＣＰＵ１０は、ホスト機から送信されてきた地域コードを、通信地域履歴３０１に登録する（ステップＳ３０１）。このとき、既に通信地域履歴３０１に記憶済みの地域コード３０２と重複する地域コードを受信した場合は、通信対戦を行った日時で最終通信日時３０３の更新を行う。

図３７は、第３の実施形態にかかる非通信ゲーム処理（ステップＳ３１０）の詳細を示すフローチャートである。本処理は、非通信であるため、シングルプレイ、つまり、プレイヤが一人で遊ぶときのゲーム処理である。図３７において、まず、ＣＰＵ１０は、通信地域履歴３０１から、そこに登録されている全ての地域コード３０２を順次読出す（ステップＳ３１１）。

次に、読み出した地域コードに基づいて、ステージリストを生成する（ステップＳ３１２）。当該ステージリストは、プレイヤに選択可能なステージを提示するためのリストである。また、上記のように、通信地域履歴３０１に登録されている地域コード３０２に対応するステージのみが含まれるリストとなる。

次に、ＣＰＵ１０は、当該ステージリストをモニタに表示し、プレイヤに対戦の舞台となるステージの選択を促す旨のメッセージを表示する。そして、プレイヤの選択操作に基づいて、対戦の舞台となるステージを選択する（ステップＳ３１３）。

次に、ＣＰＵ１０は、上記ステップＳ３１３で選択したステージに対応する地域コード３０２に基づいて、総合天気データ１７３から天気コードを検索して読み出す。更に、当該天気コードに基づいて、天気情報マスタ１７６から天気情報１７６２を検索して読み出す（ステップＳ３１４）。例えば、「京都ステージ」を選択した場合は、総合天気データ１７３に基づいて「京都」の天気が読み出されることになる。

次に、ＣＰＵ１０は、ステップＳ３１４で取得した天気情報を対戦舞台となるステージに反映する処理を行う（ステップＳ３１５）。例えば、雪が降っている様を表示できるようにする処理等である。

次に、ＣＰＵ１０は、ゲーム処理を行う（ステップＳ３１６）。その結果、プレイヤは、一人で遊ぶことになるが、対戦の舞台となるステージは、当該プレイヤが住んでいる地域以外の地域であり、かつ、そのときの当該地域の天気が反映された状態でプレイすることができる。例えば、東京に住んでいるプレイヤが、京都に住んでいるプレイヤと通信対戦を行えば、その後、一人で遊ぶ際には、「京都ステージ」を選択することができ、且つ、そのときの京都の天気がゲーム内に反映された状態（例えば、雪が降っている等）でゲームをプレイすることができる。

このように、第３の実施形態では、過去に自分がゲスト機として通信対戦を行った相手（ホスト機）の地域コードを自機に記憶しておく。そして、当該地域コードに応じて、一人用で遊ぶ際に選択できるステージの数が増えていく。更に、選択したステージに対応する地域の天気をゲームに反映して遊ぶことができる。これにより、例えば東京に住んでいるプレイヤに、そのプレイ時点での京都の天気を反映した「京都ステージ」でゲームをプレイさせることができる。その結果、通信を行わずにプレイする際であっても、あたかもネットワークを介して京都に移動したかのような印象を与え、ゲームの興趣を高めることができる。特に、ゲームの購入直後の状態では、上記のように１カ所しかステージが選択できないように設定したときに、上記のような通信対戦を繰り返すことで、通信対戦した相手の地域に関するステージが選べる（つまり、選択できるステージの数が増えていく）ように設定することができる。そのため、プレイヤのゲームに対するモチベーションを維持させることができ、長く飽きのこないゲームを提供することが可能となる。

また、上述の通信対戦のように、通信が確立した状態でのプレイのみならず、オフライン時のプレイ（シングルプレイ）においても、以前対戦した相手の地域の天気情報をゲーム処理に反映することができ、必ずしもネットワークに接続した状態でなくても、プレイヤが住んでいる地域とは別の地域の天気をゲームに反映することができる。

（第４の実施形態）
次に、図３８から図４２を参照して、本発明の第４の実施形態について説明する。本実施形態では、上述の第１または第２の実施形態において、マッチングサーバからの上記候補者リストに基づいて対戦相手をプレイヤに選択させる際に、対戦候補者のいる地域の、そのときの天気情報についてもプレイヤに提示する。

図３８は、第４の実施形態にかかる通信対戦ゲームの通信の流れの概要を示すための図である。図３８に示す処理の流れは、概ねにおいて、上述の第２の実施形態と同様の処理が行われるが、マッチングサーバを介したゲスト機における対戦相手の選択に関する処理の部分が異なっている。また、図３８では、上述の第２の実施形態で図２７を用いて説明した配信サーバからの総合天気データ取得に係る処理については省略している。すなわち、図３８に示す処理の流れは、ホスト機が配信サーバから総合天気データを取得した後の処理を示している。

図３８において、まず、ホスト機は、マッチングサーバ５０に対してホストしての登録要求を行う（Ｓ４）。このとき、上記登録要求に加え、ホスト機のフラッシュメモリ１７に記憶されている地域コードを読出して、マッチングサーバ５０に送信する。マッチングサーバ５０は、当該登録要求および地域コードを受信すると、上記ホストリストに、登録要求を送信したゲーム装置の情報と地域コードとを対応づけて登録する（Ｓ４１）。

次に、ゲスト機は、対戦相手の検索要求を送信する（Ｓ６）。これに応じて、マッチングサーバでは、対戦相手候補をホストリストから検索する（Ｓ７）。この際、上記地域コードも抽出して、候補者リストを生成する。つまり、候補者リストには、ホスト機となりうるゲーム装置のネットワークアドレス等の情報と、当該ホスト機に設定されている地域コードとが含まれる。
そして、マッチングサーバは、当該候補者リストをゲスト機に送信する（Ｓ８）。

次に、ゲスト機において、候補者リストの受信が行われ、当該候補者リストに基づいて、画面に表示すべき対戦相手選択用のリストを生成し、表示する（Ｓ４２）。図３９は、このときに表示される対戦相手選択用のリストの画面の一例である。図３９では、対戦候補者名３９１が一覧形式で表示されている。そして、各候補者名に左側に、天気を示すための画像３９２が表示されている。当該リストを提示することで、プレイヤに、対戦相手の天気がどういう天気であるかを認識させることができる。

その後、プレイヤの選択操作に応じて、第１のゲーム機を対戦相手として選択する（Ｓ９）。これ以降の処理の流れは、上記第２の実施形態と同様であるため、説明は省略する。

次に、第４の実施形態にかかる上記ホストリストについて図４０を用いて説明する。図４０に示されるように、第４の実施形態にかかるホストリスト５１５は、図１９で示したファイル構成に、地域コード５１４４が付加された構成となっている。当該地域コード５１４４に、上記ホスト機から送信されてきた地域コードが格納される。

次に、第４の実施形態にかかる通信対戦ゲーム処理の詳細を説明する。図４１は、第４の実施形態にかかるゲーム装置３の通信対戦処理を示すフローチャートである。ここで、第４の実施形態にかかる処理は、概ねにおいて第２の実施形態の処理と同様である。そのため、ここでは、第２の実施形態と処理が異なる点（主にステップＳ４００のゲスト処理）を中心として説明する。

まず、第４の実施形態では、上述のように、ホスト機がマッチングサーバにホスト登録依頼を行う際に、自己の地域コードも送信する。そのため、図２９を用いて説明したステップＳ１２１のマッチングサーバへのホスト登録依頼の処理の際に、ホスト機のＣＰＵ１０は、フラッシュメモリ１７から地域コード１７７を読み出して、当該登録依頼と共にマッチングサーバに送信する処理も行われる。この処理以外の、ホスト処理で行われる処理については、第２の実施形態と同様である。

次に、ゲスト処理について説明する。図４２は、第４の実施形態にかかるゲスト処理（ステップＳ４００）の詳細を示すフローチャートである。図４２において、ステップＳ１３１からステップＳ１３３までの処理、および、ステップＳ１３４以降の処理は、上述の第２の実施形態で図３１を用いて説明した処理と同様であるため、ここでは詳細な説明を省略する。

ステップＳ１３３の処理における候補者リストの受信が終われば、ＣＰＵ１０は、受信した候補者リストから、各候補の地域コードを読み出す（ステップＳ４０１）。

次に、ＣＰＵ１０は、各候補毎に、その地域コードに基づいて、上記総合天気データ１７３および天気情報マスタ１７６から天気情報１７６２を読み出す（ステップＳ４０２）。

次に、ＣＰＵ１０は、読み出した各候補毎の天気情報１７６２および候補者リストに含まれる各候補者のデータに基づいて、上記図３９で示したようなリストを生成し、画面に表示する（ステップＳ４０３）。

ステップＳ１３４以降の処理については、第２の実施形態と同様であるため、説明は省略する。

このように、第４の実施形態では、対戦相手を選択する際に、各対戦相手候補のいる地域の天気を参照でき、選択の際の参考にさせることが可能となる。これにより、たとえば、普段は雪が降らない地域に住んでいるプレイヤが、雪を見たいがために、雪の降っている地域の対戦相手を能動的に選択することが可能となる。

なお、第４の実施形態においては、ホスト機が接続承認情報をゲスト機に送る際に、地域コードも併せて送信していた。そして、ゲスト機では、当該送信された地域コードに基づいて天気情報を取得していたが、ゲスト機において、当該天気情報については、上記候補者リストを生成する際に取得した天気情報を用いるようにしても良い。これにより、処理の簡略化および高速化を図ることができる。また、上記地域コードに基づいて、対戦相手候補の地域自体についての情報（例えば地域名）もリストに表示するようにしても良い。

（第５の実施形態）
次に、図４３から図４５を参照して、本発明の第５の実施形態について説明する。上述の第１または第２の実施形態では、主に１対１での対戦を前提として説明していた。また、ホスト機のある地域の天気をゲーム処理に反映して通信対戦ゲームを行っていた。これに対し、第５の実施形態では、主に多人数（３人以上）で通信対戦ゲームを行う際の処理を想定する。例えば、通信対戦型のレースゲームなどである。この際、対戦の舞台となる仮想空間（レースのコース）については、ホスト機の地域の天気が反映されて表現されるが、これに加えて、各ゲストの地域の天気情報に関しても、ゲーム中に反映させた処理、例えば、各ゲストの地域の天気を、各ゲストの操作するキャラクタのコメントとして表示させたり、コース中の看板に表示させたりする等の処理を行う。

図４３は、第５の実施形態に係るネットワーク接続形態の概要を示す図である。図４３において、４台のゲーム装置３が通信対戦時においてメッシュ型のネットワークを構成するように接続されている。また、図４３においては、ホスト機は１台であり（ゲーム装置３ａ）、残りの３台はゲスト機である（ゲーム装置３ｂ〜３ｄ）。また、これらのゲーム装置は、上記マッチングサーバを介してマッチングされる。第５の実施形態に係る処理の流れは、通信対戦が実際に開始されるまでは、基本的に上記第２の実施形態と同様の処理の流れである。但し、メッシュ型ネットワークが構築されるように、ホスト機が新たなゲスト機に接続許可を与える度に、他のゲーム装置に各ゲーム装置のネットワークアドレス等を送信する処理を行うこと、および、プレイヤが４人揃うか所定時間が経過するかホスト機のプレイヤが開始を決定するかまではゲームが開始されない点は異なる。なお、メッシュ型ネットワークを構築するための処理については、当業者には公知であるので、詳細な説明は省略する。

図４４は、第５の実施形態にかかるゲスト処理を示すフローチャートである。図４４において、ステップＳ５００以外の処理は、上述の第２の実施形態で図３１を用いて説明したゲスト処理と同様であるため、ここでは詳細な説明を省略する。

図４５は、上記ステップＳ５００で示したその他の通信ゲーム処理の詳細を示すフローチャートである。図４５において、まず、ゲスト機のＣＰＵ１０は、フラッシュメモリ１７に記憶されている地域コード１７７を読み出す（ステップＳ５０１）。次に、ＣＰＵ１０は、当該地域コード１７７をキーとして、総合天気データ１７３および天気情報マスタ１７６から天気情報１７６２を検索する（ステップＳ５０２）。つまり、各ゲスト機において、自機が置かれている地域の天気情報１７６２を検索する。続いて、ＣＰＵ１０は、上記メッシュネットワークを介して、他のゲーム装置それぞれに対して天気情報１７６２の送信を行う（ステップＳ５０３）。

次に、同様にステップＳ５０３の処理を行った他のゲスト機から送信されてくる、各ゲスト機にかかる地域の天気情報１７６２を受信する（ステップＳ５０４）。次に、当該受信した天気情報に基づいて、ゲーム内に表示するコメントやオブジェクト（例えば看板等）を生成する（ステップＳ５０５）。

次に、通信対戦ゲーム処理を行う（ステップＳ５０６）。この処理において、ステップＳ５０５で生成したコメントやオブジェクトを適宜表示する。

このように、第５の実施形態では、ホスト機にかかる地域の天気情報をゲーム処理に反映させる事に加え、ゲスト機にかかる地域の天気情報についても、ゲーム内に流用することができる。これにより、ホスト機の天気を反映したコースでレースが行われているときに、各ゲストの住んでいる地域に係る天気について、それぞれのプレイヤに認識させることができ、通信対戦ゲームの興趣を更に高めることが可能となる。

なお、上記第５の実施形態では、天気情報を他のゲーム装置に送信するようにしていたが、天気情報は送らずに、直接上記コメント等のデータを送信するようにしても良い。つまり、各ゲスト機において、自機の置かれている地域の天気情報を読み出し、各ゲスト機において、当該天気情報を反映したコメントやオブジェクトを生成する。そして、通信対戦中（例えばレース中）に送受信されるゲームデータの一部として、当該コメントやオブジェクトのデータを他のゲーム装置に送信するようにしてもよい。そして、当該コメントやオブジェクトのデータを受信した各ゲーム機は、当該コメントやオブジェクトを適宜画面に表示するように処理すればよい。

また、上記のようなレースゲームであれば、各周回毎に、各ゲストの天気をコースに反映させるようにしてもよい。例えば、レースの１周目はホスト機の天気、２周目はゲストＡの天気、３周目はゲストＢの天気、というように、周回毎に各プレイヤの地域の天気を反映させるような処理を行っても良い。これにより、天気を利用してゲームの展開に変化を持たせることができ、単調なゲーム展開となることを防いで通信対戦ゲームの興趣を高めることが可能となる。

また、上述の各実施形態では、マッチングサーバを介した処理を行っていたが、マッチングサーバを用いずに、対戦相手を検索、接続できるようにしてもよい。例えば、一度対戦した相手については、当該相手のゲーム装置３のネットワークアドレス等を「フレンドリスト」と呼ばれるアドレス帳データとしてフラッシュメモリ１７に記憶しておく。そして、次に対戦する際は、マッチングサーバは介さずに、当該フレンドリストに記憶されているネットワークアドレスに対して、直接上記接続要求を送信するようにすればよい。この際、上記ホスト機となる第１のゲーム装置では、自機に記憶されている上記フレンドリストのネットワークアドレスに対して、上記ホスト登録要求に相当する内容のデータを送信するようにしてもよい。つまり、自己のフレンドリストに登録されているプレイヤ全員に対して、対戦を受け付けている旨を送信するようにしてもよい。そして、例えば、第２のゲーム装置が、上記フレンドリストに登録されているゲーム装置のうち、上記対戦受付を行っているゲーム装置のネットワークアドレスに対して、自機のネットワークアドレス等を付加して接続要求を送信する。当該接続要求を受信したゲーム装置（第１のゲーム装置）は、接続を許可するか否かの判定処理を経て、上記接続承認情報等を送信する。当該接続承認情報等を受信した第２のゲーム装置では、これに基づいて、第１のゲーム装置との間で接続を確立するための処理を行う。もちろん、他の通信ゲームを用いて接続した相手や、メールアプリケーションを用いてメールの送受信を行った相手等を当該フレンドリストに記憶するようにすれば、上述のような通信対戦ゲームで実際の通信対戦を一度も行わずとも、（通信相手も同じ通信対戦ゲームを実行していることを前提として）対戦相手として選択することが可能である。

本発明にかかるネットワークゲームシステムは、通信相手の地域にかかる気象情報を自己のゲーム装置におけるゲーム処理に反映することができ、通信対戦型のネットワークゲームシステム等に有用である。

本発明の一実施形態に係るゲームシステム１を説明するための外観図 図１のゲーム装置３の機能ブロック図 図１のコントローラ７の上面後方から見た斜視図 図３のコントローラ７を下面前方から見た斜視図 図３のコントローラ７の上ハウジングを外した状態を示す斜視図 図３のコントローラ７の下ハウジングを外した状態を示す斜視図 図３のコントローラ７の構成を示すブロック図 配信サーバ４０およびマッチングサーバ５０の構成を示すブロック図 第１の実施形態におけるネットワーク構成を示す図 第１の実施形態にかかる通信対戦ゲームの通信の流れの概要を示すための図 外部メインメモリ１２のメモリマップを示す図 フラッシュメモリ３８のメモリマップを示す図 総合天気データ１７３のデータ構造の一例を示した図 国名マスタ１７４のデータ構造の一例を示した図 地域名マスタ１７５のデータ構造の一例を示した図 天気情報マスタ１７６のデータ構造の一例を示した図 配信サーバにおけるメモリ４２ａのメモリマップを示す図 マッチングサーバ５０におけるメモリ４２ｂのメモリマップを示す図 ホストリスト５１４のデータ構造の一例を示した図 総合天気データ取得処理を示すフローチャート 配信処理を示すフローチャート 第１の実施形態にかかるゲーム装置３の通信対戦処理を示すフローチャート 図２２のステップＳ１１４で示したホスト処理の詳細を示すフローチャート 図２３のステップＳ１２５で示した天気更新処理の詳細を示すフローチャート 図２３のステップＳ１２７で示した通信ゲーム処理の詳細を示すフローチャート 図２２のステップＳ１１５で示したゲスト処理の詳細を示すフローチャート 第２の実施形態にかかる通信対戦ゲームの通信の流れの概要を示すための図 第２の実施形態にかかるゲーム装置３の通信対戦処理を示すフローチャート 図２８のステップＳ２００で示したホスト処理の詳細を示すフローチャート 図２９のステップＳ２０２で示した第１の天気更新処理の詳細を示すフローチャート 図２８のステップＳ２１０で示したゲスト処理の詳細を示すフローチャート 図３１のステップＳ２１２で示した第２の天気更新処理の詳細を示すフローチャート 第３の実施形態にかかる外部メインメモリ１２のメモリマップを示す図 通信地域履歴３０１のデータ構造の一例を示した図 第３の実施形態にかかるゲーム装置３の通信対戦処理を示すフローチャート 図３５のステップＳ３００で示したゲスト処理の詳細を示すフローチャート 図３５のステップＳ３１０で示した非通信ゲーム処理の詳細を示すフローチャート 第４の実施形態にかかる通信対戦ゲームの通信の流れの概要を示すための図 第４の実施形態にかかる対戦相手選択用のリストの画面の一例 第４の実施形態にかかるホストリストのデータ構造の一例を示した図 第４の実施形態にかかるゲーム装置３の通信対戦処理を示すフローチャート 図４１のステップＳ４００で示したゲスト処理の詳細を示すフローチャート 第５の実施形態に係るネットワーク接続形態の概要を示す図 第５の実施形態にかかるゲスト処理を示すフローチャート 図４４のステップＳ５００で示したその他の通信ゲーム処理の詳細を示すフローチャート

符号の説明

１…ゲームシステム
２…モニタ
２ａ…スピーカ
３…ゲーム装置
４…光ディスク
７…コントローラ
１０…ＣＰＵ
１１…システムＬＳＩ
１１ａ…入出力プロセッサ
１１ｂ…ＧＰＵ
１１ｃ…ＤＳＰ
１１ｄ…ＶＲＡＭ
１１ｅ…内部メインメモリ
１２…外部メインメモリ
１３…ＲＯＭ／ＲＴＣ
１４…ディスクドライブ
１５…ＡＶ−ＩＣ
１６…ＡＶコネクタ
１７…フラッシュメモリ
１８…無線通信モジュール
１９…無線コントローラモジュール
２０…拡張コネクタ
２１…外部メモリカード用コネクタ
２２…アンテナ
２３…アンテナ
２４…電源ボタン
２５…リセットボタン
２６…イジェクトボタン
７１…ハウジング
７２…操作部
７３…コネクタ
７４…撮像情報演算部
７４１…赤外線フィルタ
７４２…レンズ
７４３…撮像素子
７４４…画像処理回路
７５…通信部
７５１…マイコン
７５２…メモリ
７５３…無線モジュール
７５４…アンテナ
７００…基板
７０１…加速度センサ
７０２…ＬＥＤ
７０３…水晶振動子
７０４…バイブレータ
７０７…サウンドＩＣ
７０８…アンプ

Claims (18)

1. 相互に通信可能な複数のゲーム装置と、当該複数のゲーム装置のうちの少なくとも１つのゲーム装置である第１のゲーム装置に通信ネットワークを介して接続され、地域ごとの気象データを配信可能な配信サーバとを含むネットワークゲームシステムであって、
   前記配信サーバは、気象データを少なくとも前記第１のゲーム装置に対して配信するための配信手段を備え、
   前記第１のゲーム装置は、
   地域データを設定する地域データ設定手段と、
   前記配信サーバから、前記地域データ設定手段により設定された地域データに対応する前記気象データを取得する気象データ取得手段と、
   前記気象データ取得手段で取得した前記気象データを、前記複数のゲーム装置のうち当該第１のゲーム装置とは異なる第２のゲーム装置に送信する気象データ送信手段と、
   前記気象データ取得手段で取得した気象データを用いて、前記第２のゲーム装置との間で通信ゲームを実行する第１のゲーム処理手段とを備え、
   前記第２のゲーム装置は、
   前記気象データ送信手段から送信される気象データを受信する気象データ受信手段と、
   前記気象データ受信手段で受信した気象データを用いて、前記第１のゲーム装置との間で通信ゲームを実行する第２のゲーム処理手段を備え、ネットワークゲームシステム。
2. 第１ゲーム装置から第２ゲーム装置に気象データを送り、気象情報付リストから接続先を選択させる
   前記第２のゲーム装置は、
   前記気象データ受信手段で受信した前記気象データを用いて、気象情報をユーザに提示しつつ、前記第１のゲーム装置と通信ゲームを実行するか否かをユーザに選択させる選択手段と、
   前記選択手段により前記第１のゲーム装置と通信ゲームを実行することが選択されたときに、前記第１のゲーム装置と接続する第１の接続手段をさらに備え、
   前記第２のゲーム処理手段は、前記第１の接続手段により接続したゲーム装置と通信して、通信ゲームを実行し、
   前記第１のゲーム装置は、
   前記選択手段により前記第１のゲーム装置と通信ゲームを実行することが選択された前記第２ゲーム装置と接続する第２の接続手段をさらに備え、
   前記第１のゲーム処理手段は、前記第２の接続手段により接続したゲーム装置と通信して、通信ゲームを実行する、請求項１に記載のネットワークゲームシステム。
3. 前記第１のゲーム装置は、
   前記地域データ設定手段で設定した地域データを、前記第２のゲーム装置に送信する接続受付情報送信手段をさらに備え、
   前記第２のゲーム装置は、
   前記地域データを受信する地域データ受信手段と、
   前記地域データ受信手段で受信した前記地域データを用いて、地域情報をユーザに提示しつつ、前記第１のゲーム装置と通信ゲームを実行するか否かをユーザに選択させる選択手段と、
   前記選択手段により通信ゲームを実行することが選択されたときに、前記第１のゲーム装置と接続する第１の接続手段をさらに備え、
   前記第２のゲーム処理手段は、前記第１の接続手段により接続したゲーム装置と通信して、通信ゲームを実行し、
   前記第１のゲーム装置は、
   前記選択手段により前記第１のゲーム装置と通信ゲームを実行することが選択された前記第２ゲーム装置と接続する第２の接続手段をさらに備え、
   前記第１のゲーム処理手段は、前記第２の接続手段により接続したゲーム装置と通信して、通信ゲームを実行する、請求項１に記載のネットワークゲームシステム。
4. 前記配信手段は、前記気象データを前記複数のゲーム装置それぞれに対して配信可能であり、
   前記第２のゲーム装置は、
   地域データを設定する地域データ設定手段と、
   前記配信サーバから、前記地域データ設定手段により設定された地域データに対応する前記気象データを取得する第１気象データ取得手段をさらに備え、
   前記第１のゲーム装置は、
   前記地域データ設定手段で取得した地域データを、前記第２のゲーム装置に送信する地域データ送信手段をさらに備え、
   前記第２のゲーム装置は、
   前記地域データを受信する地域データ受信手段と、
   前記配信サーバから、前記地域データ受信手段で受信した前記地域データに対応する前記気象データを取得する第２気象データ取得手段と、
   前記第２気象データ取得手段で取得された気象データを用いて、気象情報をユーザに提示しつつ、前記第１のゲーム装置と通信ゲームを実行するか否かをユーザに選択させる選択手段と、
   前記選択手段により通信ゲームを実行することが選択されたときに、前記第１のゲーム装置と接続する第１の接続手段をさらに備え、
   前記第２のゲーム処理手段は、前記第１の接続手段により接続したゲーム装置と通信して、通信ゲームを実行し、
   前記第１のゲーム装置は、
   前記選択手段により前記第１のゲーム装置と通信ゲームを実行することが選択された前記第２ゲーム装置と接続する第２の接続手段をさらに備え、
   前記第１のゲーム処理手段は、前記第２の接続手段により接続したゲーム装置と通信して、通信ゲームを実行する、請求項１に記載のネットワークゲームシステム。
5. 相互に通信可能な複数のゲーム装置と、当該複数のゲーム装置と通信ネットワークを介して接続され、かつ、地域ごとの気象データの配信を行う配信サーバとを含むネットワークゲームシステムであって、
   前記配信サーバは、気象データを前記複数のゲーム装置それぞれに対して配信するための配信手段を備え、
   前記ゲーム装置は、
   地域データを設定する地域データ設定手段と、
   前記配信サーバから、前記地域データ設定手段により設定された地域データに対応する前記気象データを取得する第１の気象データ取得手段をそれぞれ備え、
   前記複数のゲーム装置のうち、通信ゲームを実行する第１のゲーム装置と第２のゲーム装置について、
   前記第１のゲーム装置は、
   前記地域データを前記第２のゲーム装置に送信する地域データ送信手段と
   前記第２のゲーム装置と通信して、自己の前記第１気象データ取得手段で取得した前記気象データを用いて、通信ゲームを行う第１のゲーム処理手段とを備え、
   前記第２のゲーム装置は、
   前記第１ゲーム装置から前記地域データを受信する地域データ受信手段と、
   前記配信サーバから、前記地域データ受信手段で受信した地域データに基づいて、当該地域データに対応する前記気象データを取得する第２の気象データ取得手段と、
   前記第１のゲーム装置と通信して、前記第２の気象データ取得手段で取得した気象データを用いて、通信ゲームを行なう第２のゲーム処理手段を備える、ネットワークゲームシステム。
6. 相互に通信可能な複数のゲーム装置と、当該複数のゲーム装置と通信ネットワークを介して接続され、かつ、地域ごとの気象データの配信を行う配信サーバとを含むネットワークゲームシステムであって、
   前記配信サーバは、気象データを前記複数のゲーム装置それぞれに対して配信するための配信手段を備え、
   前記ゲーム装置は、
   地域データを設定する地域データ設定手段と、
   前記配信サーバから、前記地域データ設定手段により設定された地域データに対応する前記気象データを取得する第１気象データ取得手段をそれぞれ備え、
   前記複数のゲーム装置のうち、通信ゲームを実行する第１のゲーム装置と第２のゲーム装置について、
   前記第１のゲーム装置は、
   前記地域データを前記第２のゲーム装置に送信する地域データ送信手段と、
   前記第２のゲーム装置と通信して、通信ゲームを行う第１のゲーム処理手段とを備え、
   前記第２のゲーム装置は、
   前記第１のゲーム装置と通信して、通信ゲームを行なう第２のゲーム処理手段と、
   前記第１ゲーム装置から前記地域データを受信する地域データ受信手段と、
   前記地域データ受信手段で受信した地域データを記憶する地域データ記憶手段と、
   前記配信サーバから、前記地域データ記憶手段に記憶された地域データに基づいて、当該地域データに対応する前記気象データを取得する第２の気象データ取得手段と、
   前記第２の気象データ取得手段で取得した気象データを用いて、ゲームをおこなう第３のゲーム処理手段とを備える、ネットワークゲームシステム。
7. 前記ネットワークゲームシステムは、前記ゲーム装置同士のマッチングを行うためのマッチングサーバを更に備え、
   前記マッチングサーバは、所定の条件に基づいて、前記第１のゲーム装置と第２のゲーム装置とを互いに接続対象としてマッチングする、請求項１、５、または６に記載のネットワークゲームシステム。
8. 前記第１のゲーム装置は、
   前記第２のゲーム機からの接続要求信号を受信する接続要求受信手段と、
   前記第２のゲーム機に前記接続要求信号に応じた接続許可信号を送信する接続許可信号送信手段とを更に備え、
   前記第２のゲーム装置は、
   前記第１のゲーム装置のネットワークアドレスを記憶するアドレス記憶手段と、
   前記第１のゲーム装置のネットワークアドレスに対して前記接続要求信号を送信する接続要求送信手段と、
   前記第１のゲーム機から、前記接続要求信号に応じた接続許可信号を受信する接続許可受信手段とを更に備える、請求項１、５、または６に記載のネットワークゲームシステム。
9. 前記第１のゲーム装置は、他のゲーム装置からの接続を受け付けていることを示す接続受付情報を所定のサーバあるいは前記第２のゲーム装置に送信する受付情報送信手段を更に備え、
   前記第２のゲーム装置は、
   少なくとも１つ以上のゲーム装置に関する接続受付情報を取得する接続可能装置取得手段と、
   前記取得した接続受付情報にかかるゲーム装置の情報を一覧できるように画面に表示する接続可能装置表示手段と、
   前記表示されたゲーム装置の情報から所望のゲーム装置を前記第１のゲーム装置として選択する選択手段とを更に備える、請求項５に記載のネットワークゲームシステム。
10. 前記受付情報送信手段は、前記地域データを前記接続受付情報に含めて送信し、
    前記第２の気象データ取得手段は、前記取得した接続受付情報に含まれる地域データに基づいて、当該地域データに対応する前記気象データを取得し、
    前記接続可能装置表示手段は、前記取得した気象データを前記接続受付情報にかかるゲーム装置の情報と対応づけて画面に表示する、請求項９に記載のネットワークゲームシステム。
11. 前記気象データとは、天候についてのデータである、請求項１、５、または６に記載のネットワークゲームシステム。
12. 前記気象データとは、気温についてのデータである、請求項１、５，または６に記載のネットワークゲームシステム。
13. 前記気象データ取得手段は、前記第１または第２のゲーム処理手段で実行されるゲームプログラムとは異なるアプリケーションプログラムの実行によって前記気象データを取得する、請求項１に記載のネットワークゲームシステム。
14. 前記第１の気象データ取得手段および第２の気象データ取得手段は、前記第１または第２のゲーム処理手段で実行されるゲームプログラムとは異なるアプリケーションプログラムの実行によって前記気象データを取得する、請求項５に記載のネットワークゲームシステム。
15. 前記第１または第２のゲーム処理手段で実行されるゲームプログラムとは異なるアプリケーションプログラムを実行する専用アプリ実行手段を更に備え、
    前記地域データは、前記専用アプリ実行手段による前記アプリケーションプログラムの実行でのみ変更可能である、請求項１３または請求項１４に記載のネットワークゲームシステム。
16. 前記地域データは、第１の区分に係るデータと第２の区分にかかるデータとで構成され、
    前記第１の区分に係るデータは、前記ゲーム装置の設置されている国を示し、
    前記第２の区分に係るデータは、前記ゲーム装置の設置されている国においての地域を示し、
    前記専用アプリ実行手段は、前記第２の区分にかかるデータのみ変更可能である、請求項１５に記載のネットワークゲームシステム。
17. 前記第２のゲーム装置は、
    前記設定データ受信手段により受信された前記地域データを少なくとも１つ以上不揮発に記憶する通信地域記憶手段と、
    前記通信地域記憶手段に記憶されている地域データに基づくゲームデータを、プレイヤが選択可能なように提示する地域表示手段と、
    前記地域表示手段が表示した前記ゲームデータから、プレイヤの選択操作に基づいた所定のゲームデータを選択する地域選択手段とを更に備え、
    前記ゲーム処理手段は、地域選択手段によって選択されたゲームデータを用いてゲーム処理を行う、請求項５に記載のネットワークゲームシステム。
18. 前記第２のゲーム装置は、
    前記配信サーバから、自己の前記地域データ設定手段で設定された地域データに基づいて、当該地域データに対応する前記気象データを取得する第３の気象データ取得手段を更に備え、
    前記第２のゲーム処理手段は、前記第２の気象データ取得手段で取得した気象データおよび前記第３の気象データ取得手段で取得した気象データを仮想ゲーム空間に反映してゲーム処理を実行する、請求項５に記載のネットワークゲームシステム。

Images