(57)【要約】【課題】通信を介して複数人参加型のゲームを行う際に、通信による遅延等の影響による不快感を抑制し、よりリアルタイムな演奏環境で操作することが可能な音楽ゲームプログラムを提供する。【解決手段】音楽ゲームプログラムは、コンピュータを、通信を介して他のゲーム装置から当該他のゲーム装置への操作入力に関連するデータを取得する通信手段と、ゲーム装置への操作入力に従う演出データを生成する演出データ生成手段と、通信手段によって取得した楽曲データの第１の部分に対する他のゲーム装置への操作入力に関連するデータに基づいて、楽曲データの第２の部分に対する他のゲーム装置への操作入力による演出を推定して当該演出を示す推定演出データを生成する推定演出データ生成手段と、第２の部分に対するゲーム装置への操作入力に従う演出データおよび推定演出データに基づいて、ゲーム処理を実行するゲーム処理手段として機能させる。【選択図】図１３
2014150938.tif 000002
【特許請求の範囲】
【請求項１】
ゲーム装置のコンピュータにおいて、楽曲データに対する所定の演出手順に従って進行するゲーム処理を実行する音楽ゲームプログラムであって、
前記音楽ゲームプログラムは、前記コンピュータを、
通信を介して他のゲーム装置から当該他のゲーム装置への操作入力に関連するデータを取得する通信手段と、
前記ゲーム装置への操作入力に従う演出データを生成する演出データ生成手段と、
前記通信手段によって取得した前記楽曲データの第１の部分に対する前記他のゲーム装置への前記操作入力に関連するデータに基づいて、前記楽曲データの第２の部分に対する前記他のゲーム装置への操作入力による演出を推定して当該演出を示す推定演出データを生成する推定演出データ生成手段と、
前記第２の部分に対する前記ゲーム装置への操作入力に従う演出データおよび前記推定演出データに基づいて、前記ゲーム処理を実行するゲーム処理手段として機能させる、音楽ゲームプログラム。
【請求項２】
前記推定演出データ生成手段は、前記通信手段によって取得した前記楽曲データの第１の部分に対する前記他のゲーム装置への前記操作入力に関連するデータに基づいて、前記通信手段によって未だ取得していない前記楽曲データの第２の部分に対する前記他のゲーム装置への操作入力による演出を推定して当該演出を示す前記推定演出データを生成する、請求項１記載の音楽ゲームプログラム。
【請求項３】
前記他のゲーム装置への操作入力に関連するデータは、前記楽曲データの第１の部分の基準に対する前記他のゲーム装置への操作入力に基づいて前記演出手順と対比したときの評価を示す評価情報を含む、請求項１または２記載の音楽ゲームプログラム。
【請求項４】
前記推定演出データ生成手段は、前記通信手段によって取得した前記楽曲データの第１の部分に対する前記他のゲーム装置への前記評価情報に基づいて、前記通信手段によって取得していない前記楽曲データの第２の部分に対する前記他のゲーム装置への操作入力による演出を推定して当該演出を示す前記推定演出データを生成する、請求項３記載の音楽ゲームプログラム。
【請求項５】
前記推定演出データ生成手段は、前記通信手段によって取得した前記楽曲データの所定の単位毎に分割された少なくとも１つの区間に相当する第１の部分に対する前記他のゲーム装置への前記操作入力に関連するデータに基づいて、前記楽曲データの第２の部分に対する前記他のゲーム装置への操作入力による演出を推定して当該演出を示す前記推定演出データを生成する、請求項１〜４のいずれか一項に記載の音楽ゲームプログラム。
【請求項６】
前記推定演出データ生成手段は、
前記楽曲データの第１の部分を構成する複数の要素パターンと前記楽曲データの第２の部分を構成する複数の要素パターンとが同じかどうかを判断し、
判断結果に応じて、前記通信手段によって取得した前記楽曲データの第１の部分を構成する複数の要素パターンそれぞれに対応する前記他のゲーム装置への前記操作入力に関連するデータに基づいて、前記楽曲データの第２の部分に対する前記他のゲーム装置への操作入力による演出を推定して当該演出を示す前記推定演出データを生成する、請求項１〜５のいずれか一項に記載の音楽ゲームプログラム。
【請求項７】
前記推定演出データ生成手段は、
前記楽曲データの第１の部分を構成する要素パターンと前記楽曲データの第２の部分を構成する要素パターンとが同じかどうかを判断し、
判断結果に応じて、前記通信手段によって取得した前記楽曲データの第１の部分を構成する要素パターンに対する前記他のゲーム装置への操作入力の長さに基づいて、前記楽曲データの第２の部分を構成する要素パターンに対する前記他のゲーム装置への操作入力による演出の有無を推定して当該演出を示す前記推定演出データを生成する、請求項１〜５のいずれか一項に記載の音楽ゲームプログラム。
【請求項８】
前記推定演出データ生成手段は、
前記楽曲データの第１の部分を構成する複数の要素パターンと前記楽曲データの第２の部分を構成する複数の要素パターンとが同じかどうかを判断し、
判断結果に応じて、前記通信手段によって取得した前記楽曲データの第１の部分を構成する各要素パターンの長さまたは個数の少なくとも一方に対する前記他のゲーム装置への前記操作入力に関連するデータに基づいて、前記楽曲データの第２の部分に対する前記他のゲーム装置への操作入力による演出を推定して当該演出を示す前記推定演出データを生成する、請求項１〜５のいずれか一項に記載の音楽ゲームプログラム。
【請求項９】
前記要素パターンは、音符の種類に関するデータである、請求項８に記載の音楽ゲームプログラム。
【請求項１０】
前記演出データ生成手段は、前記ゲーム装置への操作入力に従う演出データおよび前記他のゲーム装置への操作入力に従う演出データの少なくとも一方を生成する、請求項１〜９のいずれか一項に記載の音楽ゲームプログラム。
【請求項１１】
前記推定演出データ生成手段は、
前記楽曲データの第１の部分に対する前記ゲーム装置への操作入力を取得したタイミングと、前記楽曲データの第１の部分に対する前記他のゲーム装置への操作入力を前記通信手段によって取得したタイミングとの差を判断し、
判断結果に基づいて、前記通信手段によって取得した前記楽曲データの第１の部分に対する前記他のゲーム装置への前記操作入力に関連するデータに基づいて、前記楽曲データの第２の部分に対する前記他のゲーム装置への操作入力による演出を推定せず、
前記ゲーム処理手段は、前記推定演出データが生成されない場合に、前記第２の部分に対する前記ゲーム装置および前記他のゲーム装置への操作入力に従う演出データに基づいて、前記ゲーム処理を実行する、請求項１０に記載の音楽ゲームプログラム。
【請求項１２】
前記推定演出データ生成手段は、
前記楽曲データの第２の部分が所定部分であるか否かを判断し、
前記楽曲データの第２の部分が所定部分であると判断された場合に、前記通信手段によって取得した前記楽曲データの第１の部分に対する前記他のゲーム装置への前記操作入力に関連するデータに基づいて、前記楽曲データの第２の部分に対する前記他のゲーム装置への操作入力による演出を推定せず、
前記ゲーム処理手段は、前記推定演出データが生成されない場合に、前記第２の部分に対する前記ゲーム装置および前記他のゲーム装置への操作入力に従う演出データに基づいて、前記ゲーム処理を実行する、請求項１０に記載の音楽ゲームプログラム。
【請求項１３】
楽曲データに対する所定の演出手順に従って進行するゲーム処理を実行するゲーム装置であって、
通信を介して他のゲーム装置から当該他のゲーム装置への操作入力に関連するデータを取得する通信手段と、
前記ゲーム装置への操作入力に従う演出データを生成する演出データ生成手段と、
前記通信手段によって取得した前記楽曲データの第１の部分に対する前記他のゲーム装置への前記操作入力に関連するデータに基づいて、前記楽曲データの第２の部分に対する前記他のゲーム装置への操作入力による演出を推定して当該演出を示す推定演出データを生成する推定演出データ生成手段と、
前記第２の部分に対する前記ゲーム装置への操作入力に従う演出データおよび前記推定演出データに基づいて、前記ゲーム処理を実行するゲーム処理手段とを備える、ゲーム装置。
【請求項１４】
楽曲データに対する所定の演出手順に従って進行するゲーム処理を実行するゲーム装置の制御方法であって、
通信を介して他のゲーム装置から当該他のゲーム装置への操作入力に関連するデータを取得するステップと、
前記ゲーム装置への操作入力に従う演出データを生成するステップと、
前記通信によって取得した前記楽曲データの第１の部分に対する前記他のゲーム装置への前記操作入力に関連するデータに基づいて、前記楽曲データの第２の部分に対する前記他のゲーム装置への操作入力による演出を推定して当該演出を示す推定演出データを生成するステップと、
前記第２の部分に対する前記ゲーム装置への操作入力に従う演出データおよび前記推定演出データに基づいて、前記ゲーム処理を実行するステップとを備える、ゲーム装置の制御方法。
【請求項１５】
楽曲データに対する所定の演出手順に従って進行するゲーム処理を実行するゲーム装置を有するゲームシステムであって、
通信を介して他のゲーム装置から当該他のゲーム装置への操作入力に関連するデータを取得する通信手段と、
前記ゲーム装置への操作入力に従う演出データを生成する演出データ生成手段と、
前記通信手段によって取得した前記楽曲データの第１の部分に対する前記他のゲーム装置への前記操作入力に関連するデータに基づいて、前記楽曲データの第２の部分に対する前記他のゲーム装置への操作入力による演出を推定して当該演出を示す推定演出データを生成する推定演出データ生成手段と、
前記第２の部分に対する前記ゲーム装置への操作入力に従う演出データおよび前記推定演出データに基づいて、前記ゲーム処理を実行するゲーム処理手段とを備える、ゲームシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、音楽ゲームプログラム、ゲーム装置、ゲーム装置の制御方法およびゲームシステムに関し、より特定的には、複数のユーザがそれぞれゲーム装置を用いて１つのゲーム処理を実行することが可能な音楽ゲームプログラム、ゲーム装置、ゲーム装置の制御方法およびゲームシステムに関する。
【背景技術】
【０００２】
従来より、記憶装置に記憶されている他パートの演奏データを用いて他パートの音を出力しつつ、プレイヤによる演奏操作に応じて自機パートの音を出力する合奏ゲームシステムが開示されている（特開２００８−１１３７６６号公報参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００８−１１３７６６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
一方で、複数のユーザがそれぞれゲーム装置を用いて１つのゲームを行う複数人参加型のゲームを行うゲームシステムにおいては、他のゲーム装置における操作結果を示すデータを自機で受信し、当該操作結果を自機に反映させることができる。しかしながら、このとき、通信による遅延のために、操作結果を反映させるのに遅延が生じてしまう場合がある。そのため、例えば、合奏ゲームの場合、通信による遅延が原因で他のゲーム装置における操作が行われてから即座に自機において音を出力することができず、ユーザにとっては演奏操作時に不快感を与えていた。
【０００５】
本発明は、通信を介して複数人参加型のゲームを行う際に、通信による遅延等の影響による不快感を抑制し、よりリアルタイムな演奏環境で操作することが可能な音楽ゲームプログラム、ゲーム装置、ゲーム装置の制御方法およびゲームシステムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明のある局面に従うゲーム装置のコンピュータにおいて、楽曲データに対する所定の演出手順に従って進行するゲーム処理を実行する音楽ゲームプログラムであって、音楽ゲームプログラムは、コンピュータを、通信を介して他のゲーム装置から当該他のゲーム装置への操作入力に関連するデータを取得する通信手段と、ゲーム装置への操作入力に従う演出データを生成する演出データ生成手段と、通信手段によって取得した楽曲データの第１の部分に対する他のゲーム装置への操作入力に関連するデータに基づいて、楽曲データの第２の部分に対する他のゲーム装置への操作入力による演出を推定して当該演出を示す推定演出データを生成する推定演出データ生成手段と、第２の部分に対するゲーム装置への操作入力に従う演出データおよび推定演出データに基づいて、ゲーム処理を実行するゲーム処理手段として機能させる。
【０００７】
上記推定演出データ生成手段は、通信手段によって取得した楽曲データの第１の部分に対する他のゲーム装置への操作入力に関連するデータに基づいて、通信手段によって未だ取得していない楽曲データの第２の部分に対する他のゲーム装置への操作入力による演出を推定して当該演出を示す推定演出データを生成するようにしても良い。
【０００８】
上記他のゲーム装置への操作入力に関するデータは、楽曲データの第１の部分の基準に対する他のゲーム装置への操作入力に基づいて演出手順と対比したときの評価を示す評価情報を含んでも良い。
【０００９】
上記推定演出データ生成手段は、通信手段によって取得した楽曲データの第１の部分に対する他のゲーム装置への評価情報に基づいて、通信手段によって取得していない楽曲データの第２の部分に対する他のゲーム装置への操作入力による演出を推定して当該演出を示す推定演出データを生成しても良い。
【００１０】
上記推定演出データ生成手段は、通信手段によって取得した楽曲データの所定の単位毎に分割された少なくとも１つの区間に相当する第１の部分に対する他のゲーム装置への操作入力に関連するデータに基づいて、楽曲データの第２の部分に対する他のゲーム装置への操作入力による演出を推定して当該演出を示す推定演出データを生成しても良い。
【００１１】
上記推定演出データ生成手段は、楽曲データの第１の部分を構成する複数の要素パターンと楽曲データの第２の部分を構成する複数の要素パターンとが同じかどうかを判断し、判断結果に応じて、通信手段によって取得した楽曲データの第１の部分を構成する複数の要素パターンそれぞれに対応する他のゲーム装置への操作入力に関連するデータに基づいて、楽曲データの第２の部分に対する他のゲーム装置への操作入力による演出を推定して当該演出を示す推定演出データを生成しても良い。
【００１２】
上記推定演出データ生成手段は、楽曲データの第１の部分を構成する要素パターンと楽曲データの第２の部分を構成する要素パターンとが同じかどうかを判断し、判断結果に応じて、通信手段によって取得した楽曲データの第１の部分を構成する要素パターンに対する他のゲーム装置への操作入力の長さに基づいて、楽曲データの第２の部分を構成する要素パターンに対する他のゲーム装置への操作入力による演出の有無を推定して当該演出を示す推定演出データを生成しても良い。
【００１３】
上記推定演出データ生成手段は、楽曲データの第１の部分を構成する複数の要素パターンと楽曲データの第２の部分を構成する複数の要素パターンとが同じかどうかを判断し、判断結果に応じて、通信手段によって取得した楽曲データの第１の部分を構成する各要素パターンの長さまたは個数の少なくとも一方に対する他のゲーム装置への操作入力に関連するデータに基づいて、楽曲データの第２の部分に対する他のゲーム装置への操作入力による演出を推定して当該演出を示す推定演出データを生成しても良い。
【００１４】
上記要素パターンは、音符の種類に関するデータであっても良い。
上記演出データ生成手段は、ゲーム装置への操作入力に従う演出データまたは他のゲーム装置への操作入力に従う演出データの少なくとも一方を生成しても良い。
【００１５】
上記推定演出データ生成手段は、楽曲データの第１の部分に対するゲーム装置への操作入力を取得したタイミングと、楽曲データの第１の部分に対する他のゲーム装置への操作入力を通信手段によって取得したタイミングとの差を判断し、判断結果に基づいて、通信手段によって取得した楽曲データの第１の部分に対する他のゲーム装置への操作入力に関連するデータに基づいて、楽曲データの第２の部分に対する他のゲーム装置への操作入力による演出を推定せず、ゲーム処理手段は、推定演出データが生成されない場合に、第２の部分に対するゲーム装置および他のゲーム装置への操作入力に従う演出データに基づいて、ゲーム処理を実行しても良い。
【００１６】
上記推定演出データ生成手段は、楽曲データの第２の部分が所定部分であるか否かを判断し、楽曲データの第２の部分が所定部分であると判断された場合に、通信手段によって取得した楽曲データの第１の部分に対する他のゲーム装置への操作入力に関連するデータに基づいて、楽曲データの第２の部分に対する他のゲーム装置への操作入力による演出を推定せず、ゲーム処理手段は、推定演出データが生成されない場合に、第２の部分に対するゲーム装置および他のゲーム装置への操作入力に従う演出データに基づいて、ゲーム処理を実行しても良い。
【００１７】
本発明のある局面に従う楽曲データに対する所定の演出手順に従って進行するゲーム処理を実行するゲーム装置であって、通信を介して他のゲーム装置から当該他のゲーム装置への操作入力に関連するデータを取得する通信手段と、ゲーム装置への操作入力に従う演出データを生成する演出データ生成手段と、通信手段によって取得した楽曲データの第１の部分に対する他のゲーム装置への操作入力に関連するデータに基づいて、楽曲データの第２の部分に対する他のゲーム装置への操作入力による演出を推定して当該演出を示す推定演出データを生成する推定演出データ生成手段と、第２の部分に対するゲーム装置への操作入力に従う演出データおよび推定演出データに基づいて、ゲーム処理を実行するゲーム処理手段とを備える。
【００１８】
本発明のある局面に従う楽曲データに対する所定の演出手順に従って進行するゲーム処理を実行するゲーム装置の制御方法であって、通信を介して他のゲーム装置から当該他のゲーム装置への操作入力に関連するデータを取得するステップと、ゲーム装置への操作入力に従う演出データを生成するステップと、通信によって取得した楽曲データの第１の部分に対する他のゲーム装置への操作入力に関連するデータに基づいて、楽曲データの第２の部分に対する他のゲーム装置への操作入力による演出を推定して当該演出を示す推定演出データを生成するステップと、第２の部分に対するゲーム装置への操作入力に従う演出データおよび推定演出データに基づいて、ゲーム処理を実行するステップとを備える。
【００１９】
本発明のある局面に従う楽曲データに対する所定の演出手順に従って進行するゲーム処理を実行するゲーム装置を有するゲームシステムであって、通信を介して他のゲーム装置から当該他のゲーム装置への操作入力に関連するデータを取得する通信手段と、ゲーム装置への操作入力に従う演出データを生成する演出データ生成手段と、通信手段によって取得した楽曲データの第１の部分に対する他のゲーム装置への操作入力に関連するデータに基づいて、楽曲データの第２の部分に対する他のゲーム装置への操作入力による演出を推定して当該演出を示す推定演出データを生成する推定演出データ生成手段と、第２の部分に対するゲーム装置への操作入力に従う演出データおよび推定演出データに基づいて、ゲーム処理を実行するゲーム処理手段とを備える。
【発明の効果】
【００２０】
通信を介して複数人参加型のゲームを行う際に、通信による遅延等の影響による不快感を抑制し、よりリアルタイムな演奏環境で操作することが可能である。
【図面の簡単な説明】
【００２１】
【図１】本実施形態に従うゲームシステムの構成を示すブロック図である。
【図２】ゲームシステムに含まれるゲーム装置１０の外観図である。
【図３】ゲーム装置１０の内部構成を示すブロック図である。
【図４】ゲーム装置の画面に表示されるゲーム画像の例を示す図である。
【図５】本実施形態に従うギター、ベース、ドラムの３つのパートからなる楽曲を２つのゲーム装置１０ａ，１０ｂによって合奏する場合を例として説明する図である。
【図６】ゲーム装置１０のメインメモリ２３に記憶される主なデータを示す図である。
【図７】ゲーム装置１０において実行されるゲーム処理の流れを示すフローチャートである。
【図８】図７に示す楽曲決定処理（ステップＳ３）の詳細を示すフローチャートである。
【図９】図７に示すパート決定処理（ステップＳ４）の詳細を示すフローチャートである。
【図１０】図７に示す演奏処理（ステップＳ５）の詳細を示すフローチャートである。
【図１１】送信する自機データ６０のパケット構成の概略を説明する図である。
【図１２】図１０に示す開始タイミング決定処理（ステップＳ３１）の詳細を示すフローチャートである。
【図１３】図１０に示す他パート音生成処理（ステップＳ６８）の詳細を示すフローチャートである。
【図１４】図１３に示す補間処理（ステップＳ８６）の詳細を示すフローチャートである。
【図１５】複数のゲーム装置によって合奏ゲームを行なう場合の状況を説明する図である。
【図１６】本実施の形態に従う補間処理の概念を説明する図である。
【図１７】本実施の形態に従う推定演出データの生成の具体例について説明する図である。
【図１８】本実施の形態に従う推定演出データの生成の具体例について説明する別の図である。
【図１９】本実施の形態に従う音符データの種類に応じた演奏フラグデータについて説明する図である。
【図２０】ゲーム中の演奏の操作期間と演奏フラグデータとの関係を説明する図である。
【図２１】本実施の形態に従う補間処理に基づく他パートの音を出力する具体例を説明する図である。
【発明を実施するための形態】
【００２２】
この実施の形態について、図面を参照しながら詳細に説明する。なお、図中の同一または相当部分については、同一符号を付してその説明は繰返さない。
【００２３】
＜１．全体構成＞
図１は、本実施形態に従うゲームシステムの構成を示すブロック図である。
【００２４】
図１を参照して、本ゲームシステムは、サーバ１および複数の携帯ゲーム装置（以下、単に「ゲーム装置」と呼ぶ。）１０ａ，１０ｂがインターネット等のネットワーク２を介して接続される構成である。
【００２５】
本実施形態では、ゲームシステムは複数（本例においては２つ）のゲーム装置１０ａ〜１０ｂを含み、図１では、２人のプレイヤがゲーム装置を１つずつ使用してゲームを行う場合を示しているが、ゲームシステムに含まれるゲーム装置の数は複数であればいくつであってもよい。
【００２６】
各ゲーム装置１０ａ，１０ｂは、無線でネットワーク２に接続可能であるが、有線で接続されるものであってもよい。また、各ゲーム装置は携帯ゲーム装置ではなく、据置型ゲーム装置であっても構わない。また、例えば、据置型ゲーム装置に携帯ゲーム装置を接続し、当該据置型ゲーム装置をネットワークに接続する構成でもよく、この場合、据置型ゲーム装置には複数の携帯ゲーム装置が接続されてもよい。
【００２７】
以下においては、ゲームシステムに含まれる各ゲーム装置を特に区別する必要がない場合は、１つのゲーム装置を単にゲーム装置１０と記載するものとする。
【００２８】
サーバ１は、通信ゲームを行うゲーム装置のグループの決定（マッチング）を行うための装置である。他の実施形態においては、ゲームシステムは、サーバ１を含まない構成であってもよい。サーバ１の動作の詳細については後述する。
【００２９】
＜ゲーム装置の構成＞
図２は、ゲームシステムに含まれるゲーム装置１０の外観図である。本実施形態においては、一例としてゲームシステムに含まれる各ゲーム装置は全て同じ構成であり、全て図２に示す構成である。
【００３０】
図２を参照して、ゲーム装置１０は、上側ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ：液晶表示装置）１１および下側ＬＣＤ１２を含む。ハウジング１３は上側ハウジング１３ａと下側ハウジング１３ｂとによって構成されている。
【００３１】
上側ＬＣＤ１１は上側ハウジング１３ａに収納され、下側ＬＣＤ１２は下側ハウジング１３ｂに収納される。上側ＬＣＤ１１および下側ＬＣＤ１２の解像度は、一例としていずれも２５６ｄｏｔ×１９２ｄｏｔである。
【００３２】
なお、本実施形態では表示装置としてＬＣＤを用いているが、例えばＥＬ（Ｅｌｅｃｔｒｏ Ｌｕｍｉｎｅｓｃｅｎｃｅ：電界発光）を利用した表示装置など、他の任意の表示装置を利用することも可能である。また任意の解像度のものを利用することも可能である。
【００３３】
上側ハウジング１３ａには、後述する１対のスピーカ（図３の１８）からの音を外部に放出するための音抜き孔１８ａおよび１８ｂが形成されている。
【００３４】
下側ハウジング１３ｂには、入力装置として、十字キー１４ａ、スタートスイッチ１４ｂ、３Ｄ調整スイッチ１４ｃ、Ａボタン１４ｄ、Ｂボタン１４ｅ、Ｘボタン１４ｆ、Ｙボタン１４ｇ、スライドパッド１４ｈ等の操作スイッチが設けられている。また、下側ハウジング１３ｂの側面には、図示しないＬボタンおよびＲボタンが設けられている。さらに、各操作スイッチとは別の入力装置として、下側ＬＣＤ１２の画面上にタッチパネル１５が装着されている。
【００３５】
３Ｄ調整スイッチ１４ｃは、スライドスイッチであり、上述のように上側ＬＣＤ２２の表示モードを切り替えるために用いられるスイッチである。３Ｄ調整スイッチ１４ｃは、上側ＬＣＤ２２に表示された立体視画像の立体感を調整するために用いられる。
【００３６】
スライドパッド１４ｈは、方向を指示するデバイスである。スライドパッド１４ｈは、そのキートップが、下側ハウジング１３ｂの内側面に平行にスライドするように構成されている。スライドパッド１４ｈは、ゲーム装置１０が実行するプログラムに応じて機能する。本例においては、十字キー１４ａの代わりに方向を入力するようにしても良い。
【００３７】
下側ハウジング１３ｂの側面には、メモリカード１７を収納するための挿入口３５（図２に示す点線）、スティック１６を収納するための挿入口３６（図２に示す点線）が設けられている。
【００３８】
タッチパネル１５は、抵抗膜方式のタッチパネルである。ただし、本発明は抵抗膜方式に限らず、任意の押圧式のタッチパネルを用いることができる。タッチパネル１５は、スティック１６に限らず指で操作することも可能である。
【００３９】
本実施形態では、タッチパネル１５として、下側ＬＣＤ１２の解像度と同じく２５６ｄｏｔ×１９２ｄｏｔの解像度（検出精度）のものを利用する。ただし、必ずしもタッチパネル１５の解像度と下側ＬＣＤ１２の解像度が一致している必要はない。
【００４０】
なお、本実施形態においては、ゲーム装置１０への操作入力として、少なくとも１つの操作スイッチまたはタッチパネル１５を備えていればよい。
【００４１】
メモリカード１７は、ゲームプログラムを記録した記録媒体であり、下側ハウジング１３ｂに設けられた挿入口３５に着脱自在に装着される。なお、ゲームプログラムはゲーム装置の内部メモリ（不揮発であることが好ましいが揮発性でもよい）に記憶してもよく、所定のサーバ（または他のゲーム装置）からダウンロードしたプログラムを当該内部メモリに記憶するようにしてもかまわない。
【００４２】
次に、ゲーム装置１０の内部構成について説明する。
図３は、ゲーム装置１０の内部構成を示すブロック図である。
【００４３】
図３を参照して、ゲーム装置１０は、上述した各部に加えて、情報処理部２１、メインメモリ２３、外部メモリインターフェイス（外部メモリＩ／Ｆ）３５、無線通信モジュール３７、リアルタイムクロック（ＲＴＣ）３８等の電子部品を備えている。これらの電子部品は、電子回路基板上に実装されて下側ハウジング１３ｂ（または上側ハウジング１３ａでもよい）内に収納される。
【００４４】
情報処理部２１は、所定のプログラムを実行するためのＣＰＵ（Central Processing Unit）２１１、画像処理を行うＧＰＵ（Graphics Processing Unit）２１２等を含む情報処理手段である。
【００４５】
情報処理部２１のＣＰＵ２１１は、ゲーム装置１０内のメモリ（例えば外部メモリＩ／Ｆ３４に接続されたメモリカード１７のＲＯＭ（Read Only Memory）１７ａに記憶されているプログラムを実行することによって、当該プログラムに応じた処理を実行する。なお、情報処理部２１のＣＰＵ２１１によって実行されるプログラムは、他の機器との通信によって他の機器から取得されてもよい。また、情報処理部２１は、ＶＲＡＭ（Video Random Access Memory）２１３を含む。情報処理部２１のＧＰＵ２１２は、情報処理部２１のＣＰＵ２１１からの命令に応じて画像を生成し、ＶＲＡＭ２１３に描画する。そして、情報処理部２１のＧＰＵ２１２は、ＶＲＡＭ２１３に描画された画像を上側ＬＣＤ１１及び／又は下側ＬＣＤ１２に出力し、上側ＬＣＤ１１及び／又は下側ＬＣＤ１２に当該画像が表示される。
【００４６】
情報処理部２１には、メインメモリ２３、外部メモリＩ／Ｆ３４が接続される。外部メモリＩ／Ｆ３４は、メモリカード１７を着脱自在に接続するためのインターフェイスである。
【００４７】
メインメモリ２３は、情報処理部２１（のＣＰＵ２１１）のワーク領域やバッファ領域として用いられる揮発性の記憶手段である。すなわち、メインメモリ２３は、上記プログラムに基づく処理に用いられる各種データを一時的に記憶したり、外部（メモリカード１７や他の機器等）から取得されるプログラムを一時的に記憶したりする。本実施形態では、メインメモリ２３として例えばＰＳＲＡＭ（Ｐｓｅｕｄｏ−ＳＲＡＭ）を用いる。
【００４８】
メモリカード１７は、情報処理部２１によって実行されるプログラムを記憶するための不揮発性の記憶手段である。メモリカード１７は、例えば読み取り専用の半導体メモリで構成される。メモリカード１７が外部メモリＩ／Ｆ３４に接続されると、情報処理部２１はメモリカード１７のＲＯＭ１７ａに記憶されたプログラムを読み込むことができる。情報処理部２１が読み込んだプログラムを実行することにより、所定の処理が行われる。
【００４９】
なお、本例においては、メモリカード１７によって実行されるプログラムについて説明するが、特にこれに限られず、読み書き可能な不揮発性メモリ（例えばＮＡＮＤ型フラッシュメモリ）で構成され、所定のデータを格納するために用いられる内部メモリを有していても良い。例えば、内部メモリには、無線通信モジュール３７を介した無線通信によってダウンロードされたデータやプログラムが格納されるようにしても良い。
【００５０】
無線通信モジュール３７は、例えばＩＥＥＥ８０２．１１ｂ／ｇの規格に準拠した方式により、無線ＬＡＮ（Local Area Network）に接続する機能を有する。無線通信モジュール３７は情報処理部２１に接続される。情報処理部２１は、無線通信モジュール３７を用いてインターネットを介して他の機器との間でデータを送受信したりすることができる。
【００５１】
また、情報処理部２１には、ＲＴＣ３８が接続される。ＲＴＣ３８は、時間をカウントして情報処理部２１に出力する。情報処理部２１は、ＲＴＣ３８によって計時された時間に基づき現在時刻（日付）を計算する。
【００５２】
また、情報処理部２１に、図示しない慣性センサの一種である加速度センサを接続して、加速度センサが検知した加速度を示す姿勢データ（加速度データ）を受信して、ゲーム装置１０の姿勢を検知するようにしてもよい。そして、当該姿勢データをゲーム装置１０への操作入力とすることも可能である。
【００５３】
また、本例においては、ゲーム装置１０への操作入力として、ゲーム装置１０の本体側に設けられた入力装置の例について説明するが、特に入力装置が一体として設けられる必要はない。具体的には、入力装置が別体（例えばリモートコントローラ等）として設けられ、無線あるいは有線で情報処理部２１と通信可能に設けられていても良い。そして、当該別体として設けられたリモートコントローラに加速度センサが設けられ、当該加速度センサが検知した姿勢データをゲーム装置１０への操作入力として、情報処理部２１に出力する構成としても良い。
【００５４】
また、情報処理部２１には、撮像部１９が接続される。撮像部１９は、情報処理部２１の指示に従って画像を撮像し、撮像した画像データを情報処理部２１に出力する。
【００５５】
撮像部１９は、所定の解像度を有する撮像素子（例えば、ＣＣＤイメージセンサやＣＭＯＳイメージセンサ等）と、レンズとを含む。レンズは、ズーム機構を有するものでもよい。
【００５６】
また、情報処理部２１には、Ｉ／Ｆ回路２２が接続される。Ｉ／Ｆ回路２２には、スピーカ１８が接続される。
【００５７】
具体的には、Ｉ／Ｆ回路２２には、図示しないアンプを介してスピーカ１８が接続される。アンプは、Ｉ／Ｆ回路２２からの音声信号を増幅し、音声をスピーカ１８から出力させる。
【００５８】
また、Ｉ／Ｆ回路２２には上述したタッチパネル１５も接続される。Ｉ／Ｆ回路２２は、スピーカ１８（アンプ）の制御を行う音声制御回路と、タッチパネルの制御を行うタッチパネル制御回路とを含む。音声制御回路は、音声信号に対するＡ／Ｄ変換及びＤ／Ａ変換を行ったり、音声信号を所定の形式の音声データに変換したりする。タッチパネル制御回路は、タッチパネル１５からの信号に基づいて所定の形式のタッチ位置データを生成して情報処理部２１に出力する。タッチ位置データは、タッチパネル１５の入力面において入力が行われた位置の座標を示す。
【００５９】
操作スイッチ１４は、上記各スイッチ、スライドパッドあるいはボタン１４ｄ〜１４ｇ等からなり、情報処理部２１に接続される。
【００６０】
操作スイッチ１４から情報処理部２１へは、上記各スイッチ、スライドパッドあるいはボタン１４ｄ〜１４ｇ等に対する入力状況（押下されたか否か）を示す操作データが出力される。情報処理部２１は、操作スイッチ１４からの操作データを取得することによって、上記各スイッチ、スライドパッドあるいはボタン１４ｄ〜１４ｇ等に対する入力に従った処理を実行する。
【００６１】
なお、ＣＰＵ２１１は、操作スイッチ１４からの操作データの取得を所定時間に１回の割合で行う。
【００６２】
下側ＬＣＤ１２及び上側ＬＣＤ１１は情報処理部２１に接続される。下側ＬＣＤ１２及び上側ＬＣＤ１１は、情報処理部２１（のＧＰＵ２１２）の指示に従って画像を表示する。
【００６３】
＜２．ゲームシステムの動作概要＞
次に、ゲームシステムにおいて実行される動作の概要について説明する。
【００６４】
本実施形態では、プレイヤに演奏を行わせる複数のゲーム装置によって合奏ゲームを行う場合を一例として説明する。
【００６５】
この合奏ゲームでは、複数のプレイヤが、複数のパートからなる楽曲の各パートをそれぞれ演奏して遊ぶ。すなわち、各プレイヤにはそれぞれ楽曲のパートが１つずつ割り当てられ、プレイヤは、割り当てられたパートの演奏をゲーム装置を用いて行うものとする。なお、同じパートを複数のプレイヤが演奏することができるようにしてもよい。
【００６６】
各プレイヤによって行われた演奏内容は、他のゲーム装置に送信され、ゲーム装置は、全てのゲーム装置における演奏内容を取得する。ゲーム装置は、取得した演奏内容を用いて全パートの音を一緒に出力する、すなわち、各演奏音を合奏として出力する。
【００６７】
本例において説明する合奏ゲームは、以上の処理によって各ゲーム装置における演奏を合わせて合奏として出力することによって、複数のプレイヤで合奏を行うためのものである。
【００６８】
まず、ゲーム装置を用いた演奏操作について説明する。楽曲の演奏が可能となる期間（演奏期間）中においては、プレイヤが所定の演奏ボタンのいずれかを押下する操作を行ったことに応じて、ゲーム装置からは自機パートの音が出力される。
【００６９】
本実施形態において、演奏ボタンは、十字キー１４ａの上下左右ボタン、Ａボタン１４ｄ、Ｂボタン１４ｅ、Ｘボタン１４ｆ、Ｙボタン１４ｇ、Ｌボタン、およびＲボタンの１０種類が割り当てられているものとする。なお、十字キー１４ａの代わりにスライドパッド１４ｈを用いるようにしても良い。
【００７０】
ゲーム装置の自機パートとは、そのゲーム装置に割り当てられたパートのことである。また、ゲーム装置の他パートとは、自動演奏あるいは他のゲーム装置に割り当てられたパートのことである。なお、他のゲーム装置に割り当てられたパートを他機パートとも称する。また、本実施形態では、押下されたキーの種類に応じて異なる音程の音が出力される。
【００７１】
具体的には、十字キー１４ａの上下左右ボタンおよび各ボタン１４ｄ〜１４ｇの８種類のボタンに対して例えばドレミファソラシドの８つの音程が１つずつ割り当てられるとともに、Ｌボタンによって音程が半音変化し、Ｒボタンによって音程が１オクターブ変化する。以上より、プレイヤは、１０種類の演奏ボタンを用いて自機パートの演奏を行うことができる。
【００７２】
また、自機の割り当てられたパートに応じて音色が変更される。すなわち、ゲーム装置には、各楽器ごとかつ各音程ごとの音データが記憶されている。
【００７３】
具体的には、例えば、ピアノおよびギターのパートを含む楽曲の演奏時には、ピアノのパートが割り当てられたゲーム装置では、ピアノについての音データが使用され、ギターのパートが割り当てられたゲーム装置では、ギターについての音データが使用される。
【００７４】
また、本実施形態では、各演奏ボタン操作に対して固定の音程を割り当てたが、同じ演奏ボタン操作をしたときでも、楽曲に応じて、および／または、１つの楽曲においてもある部分に応じて、異なる音程の音が出力されるようにしてもよい。この場合、ある演奏ボタン操作をしたときに出力される音程を指定するデータが楽曲ごと（および／または、楽曲における部分ごと）に定義されて、各ゲーム装置が当該定義したデータを記憶しており、これが合奏ゲーム実行中に利用される。
【００７５】
また、本実施形態では、演奏ボタンの操作が行われるべき正しいタイミングが楽曲ごとに定義されており、ゲーム装置１０は、演奏ボタンが操作されたタイミングが当該正しいタイミングを基準とする許容範囲内であるか否かを判定する。
【００７６】
この場合、当該正しいタイミングを基準とする許容範囲内であるか否かに関わらず演奏ボタンを操作したときは全て音が出力されるようにしてもよいし、当該正しいタイミングを基準とする許容範囲内のタイミングでボタンが操作されたときのみ音を出力するようにしてもよい。
【００７７】
また、本実施形態では、演奏ボタンの操作が行われるべき正しいタイミングと関連付けられる、操作が行われるべき正しい演奏ボタンが楽曲ごとに定義されており、ゲーム装置１０は、演奏ボタンの操作が当該正しい演奏ボタンであるか否かを判定する。
【００７８】
この場合、当該正しい演奏ボタンが操作されたときのみ、対応する音を出力するようにしてもよいし、正しい演奏ボタンが操作がされたかどうかに関わらず対応する音を出力するようにしてもかまわない。
【００７９】
本例において説明する合奏ゲームにおいては、演奏操作が可能となる演奏期間中、演奏すべき楽曲の演奏操作の指示画像がゲーム装置１０の画面に表示される。ここで、演奏操作の指示画像とは、演奏ボタン操作の正しいタイミング（および付加的に操作すべき正しい演奏ボタンの種類）をプレイヤに対して指示するものである。
【００８０】
プレイヤは、画面に表示された内容に従って演奏操作を行う。
図４は、ゲーム装置の画面に表示されるゲーム画像の例を示す図である。
【００８１】
図４を参照して上側ＬＣＤ１１または下側ＬＣＤ１２の画面には、３本のゲージ（例えばゲージ４１）、１対のカーソル４２、複数の演奏ボタン操作の操作指示画像（例えば操作指示画像４３および４４）、および、演奏ボタンを操作するタイミングや長さを示す操作期間画像（例えば操作期間画像４５）が表示される。図４に示すゲーム画像は、自機パートの演奏操作の正しいタイミング（および付加的に操作すべき正しい演奏ボタンの種類）をプレイヤに対して指示するための画像である。
【００８２】
横長形状のゲージは、縦方向に複数本並べて配置されている。また、ゲージには所定の単位毎の区間に分割された目盛りが付されており、１本のゲージは四分の四拍子の場合には例えば１６マスに区分され、四分の三拍子の場合には例えば１２マスに区分される。例えば四分の四拍子の場合には、４マスで１拍となり、１６マスで一小節となる。
【００８３】
１対のカーソル４２は、左右方向に関して同じ位置に配置され、一方がいずれかのゲージの上側に配置され、他方が当該ゲージの下側に配置される。また、操作指示画像および操作期間画像は、ゲージ上に配置される。操作指示画像は、上記１０種類の演奏ボタンのいずれかを表す画像（上下左右方向の矢印、または、Ａ，Ｂ，Ｘ，Ｙ，Ｌ，Ｒの文字）を含む。操作期間画像は、操作指示画像の右側に必要に応じて配置される。
【００８４】
なお、ゲームシステムに含まれる各ゲーム装置に割り当てられるパートが異なるので、各ゲーム装置の画面において、操作指示画像および操作期間画像はそれぞれ各ゲーム装置ごとに異なる位置に配置される。なお、演奏ボタン操作の操作指示画像は、本実施形態で採用した態様と異なるものであっても、種々の態様を採用可能であることは当業者にとっては容易に理解可能である。演奏操作の各指示画像（操作指示画像および操作期間画像）は、例えば、音楽の一般的な楽譜のようなものに操作すべき正しいタイミングを指示するカーソルを付したような態様でもよいし、操作指示画像を所定位置に向けて移動表示して、操作指示画像が当該所定位置に到達したときに操作すべき正しいタイミングとなるような態様でも良い。
【００８５】
上記演奏期間が開始されると、１対のカーソル４２は、時間に応じてゲージの左側から右側へ移動していき、ゲージの右端に達すると、当該ゲージの１つ下に表示されるゲージの左端に移動する。また、画面に表示されているゲージは、カーソル４２が画面内に常に表示されるように、カーソル４２の移動に応じて上方向にスクロールする。つまり、各ゲージは上方向に移動していき、操作指示画像および操作期間画像が配置された新たなゲージが画面の下側から追加して表示される。
【００８６】
各指示画像（操作指示画像および操作期間画像）が配置されたゲージは、演奏操作指示すなわち楽譜に相当するものであり、演奏ボタンを押下すべきタイミング、長さおよび押下すべき演奏ボタンの種類を表している。具体的には、プレイヤは、操作指示画像がカーソル４２によって指定されるタイミング（１対のカーソル４２の間に操作指示画像が位置するタイミング）で、当該操作指示画像によって表される演奏ボタンの操作を行う。
【００８７】
例えば、図４に示す画像が表示されている時点では、カーソル４２は、Ｒボタンを表す操作指示画像４３と十字キー１４ａの右方向を表す操作指示画像４４とを指定しているので、プレイヤはＲボタン１４および十字キー１４ａの右方向を同時に押下する操作を行う。また、操作期間画像は、演奏ボタンを押下するタイミングおよび長さを表している。つまり、プレイヤは、移動するカーソル４２が操作期間画像を指定している間、演奏ボタンを継続的に押下する。例えば、図４に示す操作期間画像４５は、Ｂボタン１４ｅを２目盛り分の時間だけ継続的に押下することを表している。
【００８８】
なお、ある演奏ボタンを比較的短い時間（例えば、１目盛り分の時間）だけ押下することを表す場合、操作期間画像は配置されないようにしても良い。ゲージ上に配置された各指示画像に従って演奏ボタンを押下することによって、プレイヤは、楽曲を正しく演奏することができる。
【００８９】
以上に説明した演奏操作を行うことによって、プレイヤは、自機パートの演奏を行うことができる。ここで、合奏を行うためには、他のゲーム装置に割り当てられた他パートの演奏内容を表すデータを演奏中に逐次取得し、その演奏中において、取得したデータに基づいて当該他パートの音を出力する必要がある。
【００９０】
しかしながら、他のゲーム装置から上記データを受信する際、特にネットワークを介した通信の場合には通信による遅延が発生する可能性があるため、他パートの音を出力するタイミングが自機パートの音を出力するタイミングよりも遅くなってしまう可能性がある。さらに、ネットワークを介さないローカルの通信の場合にも、環境によっては遅延が発生する可能性もある。合奏を行う場合には自機パートの音と他パートの音とを同期させなければならないが、これらの遅延が生じた場合には自機パートの音と他パートの音とを同期させて出力することができない。
【００９１】
そこで、本実施形態では、他パートを演奏するプレイヤの他のゲーム装置から取得したデータ（第１の部分に対する操作入力）に基づいて、必要に応じて当該他パートの他の部分（第２の部分）に対する音を出力するためのデータを推定する。すなわち、他パートの第２の部分に対する他のゲーム装置への操作入力を推定する推定データを生成する。そして、当該推定データに基づいて他パートの音を出力する。これによって、自機パートの音を出力するタイミングにおいて、推定データに基づいて他パートの音が出力されるため、遅延による操作性の問題を抑制してプレイヤの演奏と他のプレイヤの演奏とを違和感無く出力することができる。また、他パートの音は、他パートを演奏するプレイヤのリアルタイムな環境で操作された演奏状況に応じて推定されるデータであるため、他パートを演奏するプレイヤと合奏するプレイヤはよりリアルタイムな環境で操作することが可能である。
【００９２】
なお、本実施形態における他のゲーム装置からのデータの取得は、送信されてきたデータをリアルタイムで受信した場合のみならず、過去に受信した場合も含まれ得る。また、当該受信したデータを処理し易いように加工して加工したデータとして受け付けた場合も含まれる概念である。
【００９３】
次に、ゲームシステムにおける動作について説明する。
図５は、本実施形態に従うギター、ベース、ドラムの３つのパートからなる楽曲を２つのゲーム装置１０ａ，１０ｂによって合奏する場合を例として説明する図である。なお、ドラムのパートについては、自動演奏データとして演奏される場合について説明する。
【００９４】
図５を参照して、具体的には、ゲーム装置１０ａにはギターのパートが割り当てられ、ゲーム装置１０ｂにはベースのパートが割り当てられるものとする。そして、ドラムのパートは、自動演奏されるものとする。
【００９５】
なお、ゲーム装置１０ａとゲーム装置１０ｂはいずれも合奏ゲームのプログラムを記憶したメモリカードが装着されたゲーム装置であり、当該プログラムを実行することにより（または、装置本体内蔵のプログラムを実行することにより）、所定のサーバ（図１のサーバ１）に対して合奏ゲームの実行を希望するデータを送信し、当該サーバにおいて、合奏ゲームの実行を希望する複数のゲーム装置をグループ化することにより、合奏ゲームを行なう単位グループとして形成されたものである。
【００９６】
なお、合奏ゲームのプログラムを記憶したメモリカードが装着されていないゲーム装置であっても、当該サーバに合奏ゲームの実行を希望することを可能にしてもよい。具体的には、合奏ゲームの実行を希望するデータをサーバに送信し、かつ、合奏ゲームのプログラムの配信を受けるためのプログラムをゲーム装置本体に内蔵し、サーバから当該ゲーム装置にプログラムを配信することにより実現される。
【００９７】
また、ネットワークを介さないローカル通信により合奏ゲームの実行を希望する複数のゲーム装置をグループ化するようにしてもよい。具体的には、複数のゲーム装置間でローカル通信により接続情報を遣り取りして合奏ゲームを行なう単位グループを形成することが可能である。なお、合奏ゲームのプログラムを記憶したメモリカードが装着されていないゲーム装置であっても、合奏ゲームのプログラムを記憶したゲーム装置からローカル通信により当該プログラムの配信を受けることにより合奏ゲームの実行を可能とするようにしてもよい。
【００９８】
また、このようにしてグループ化されたゲーム装置であるゲーム装置１０ａとゲーム装置１０ｂとのそれぞれについて、担当するパートを決定する処理が合奏ゲームを開始する前におこなわれる。この処理は、例えば、図７のステップＳ４を参照して後述するような方法で実行される。
【００９９】
ここで決定されたパートが、演奏期間において参照される。さらに、グループ化されたゲーム装置において、共通の楽曲データを選択する処理が合奏ゲームを開始する前におこなわれる。ここで決定された楽曲が、演奏期間において参照される。
【０１００】
そして、各プレイヤによって各パートの演奏操作が行われる。つまり、演奏期間において、各ゲーム装置１０ａ，１０ｂは、それぞれの自機パートの音をそれぞれのプレイヤによる操作に応じて出力する。ここで、各ゲーム装置では、自機パートに応じて異なる処理が実行される。
【０１０１】
具体的には、自機パートに対応する演奏ボタン操作の操作指示画像が表示され、プレイヤの操作に応じた音を出力するとともに、他のゲーム装置から取得されたデータを用いて他パートの音が生成されて出力される。したがって、演奏期間において、プレイヤは、自機の演奏と、他のプレイヤによる演奏とタイミングを合わせて合奏を行うことができる。なお、ゲーム装置において、自動演奏するパートがある場合には、当該パートに対応する音が自動的に生成されてともに出力される。
【０１０２】
また、本実施形態においては、演奏期間において、ゲーム装置１０は、自機パートについて行われた演奏内容を示す演奏データを他のゲーム装置へ送信する（図５参照）。なお、後述するが当該演奏の演奏内容を示す演奏データは、送信処理のために必要な他の付加的な情報が付加されて自機データとして送信される。また、他のゲーム装置から送信された当該他のゲーム装置における演奏内容を示す演奏データは他機データとして受信される。
【０１０３】
本例においては、ゲーム装置１０ａにおいて行われた演奏内容を示す演奏データＭＡがゲーム装置１０ｂに送信され、ゲーム装置１０ｂにおいて行われた演奏内容を示す演奏データＭＢがゲーム装置１０ａに送信される。これによって、ゲーム装置１０は、他のゲーム装置の演奏における演奏内容を示す演奏データを取得することができる。
【０１０４】
これにより、ゲーム装置１０ａにおいては、ギターのパートについて、プレイヤの操作に従う演奏データＭＡに応じた音が出力される。また、ベースのパートについて、他のゲーム装置（ゲーム装置１０ｂ）から取得した他のプレイヤの操作に従う演奏データＭＢに応じた音が出力される。また、ドラムのパートについて、自動演奏データに応じた音が出力される。ゲーム装置１０ｂにおいては、ギターのパートについて、他のゲーム装置（ゲーム装置１０ａ）から取得した他のプレイヤの演奏データＭＡに応じた音が出力される。また、ベースのパートについて、プレイヤの操作に従う演奏データＭＢに応じた音が出力される。また、ドラムのパートについて、自動演奏データに応じた音が出力される。
【０１０５】
以上のように、本実施形態によれば、演奏をプレイヤに行わせる。そして、演奏においては、自機パートの音がプレイヤによる操作に応じて出力されるとともに、他パートの音は、すでに取得されている演奏データを用いて出力される。したがって、演奏時において、他のプレイヤによる演奏および／または自動演奏を自分の演奏に合わせて出力することができる。これによって、全パートの音についてタイミングを合わせて合奏する合奏ゲームを実行することができる。
【０１０６】
＜３．ゲーム処理におけるデータ＞
次に、本実施形態においてゲーム装置１０で実行されるゲーム処理について説明する。
【０１０７】
図６は、ゲーム装置１０のメインメモリ２３に記憶される主なデータを示す図である。
図６を参照して、メインメモリ２３には、合奏ゲームプログラム５０およびゲーム処理用データ５１等が記憶される。なお、メインメモリ２３には、図６に示すデータの他、楽曲の演奏音を出力するために必要な音源データやゲームに登場する各種オブジェクトの画像データ等、ゲーム処理に必要なデータが記憶される。
【０１０８】
合奏ゲームプログラム５０は、ゲーム装置１０に電源が投入された後の適宜のタイミングでメモリカード１７のＲＯＭ１７ａからその一部または全部が読み込まれてメインメモリ２３に記憶される。合奏ゲームプログラム５０は、後述する合奏ゲームのゲーム処理（図７）をＣＰＵ２１１が実行するためのプログラムである。
【０１０９】
ゲーム処理用データ５１には、後述するゲーム処理（図７）を実行する際に用いられる各種のデータが含まれる。具体的には、ゲーム処理用データ５１は、自機演奏データ５２、他機演奏データ５３、楽曲データ５６、パートデータ５７、グループデータ５８、および演奏楽曲指定データ５９を含む。
【０１１０】
自機演奏データ５２、他機演奏データ５３およびパートデータ５７は、プログラムの実行により生成されてメインメモリ２３に記憶されるデータであり、楽曲データ５６は、ＲＯＭ１７ａに記憶されたものが読み込まれてメインメモリ２３に記憶されるデータである。なお、ゲーム処理用データには、上記のデータの他、各パート（楽器）について音程毎の音データが含まれる。
【０１１１】
自機演奏データ５２は、自機で生成された演奏データである。つまり、自機演奏データ５２は、自機に割り当てられたパート（自機パート）の演奏の内容を示す。本実施形態では、自機演奏データ５２は、フレーム時間（一例として１／６０［ｓ］）間隔で操作スイッチ１４から取得される操作データ（いずれの演奏ボタンが操作されたかを示すデータ）と、当該操作データが取得されたフレーム時刻を示すフレーム番号データとを含む。
【０１１２】
なお、フレーム番号データは、演奏開始時点を例えばフレーム番号１としてその後インクリメントするものであり、演奏期間中における時点を示すものである。
【０１１３】
自機演奏データ５２には、操作データとフレーム番号データとの組が含まれる。したがって、自機演奏データ５２を参照することによって、ゲーム装置１０は、演奏期間中におけるどの時点で、どの演奏ボタンが押下されたかを知ることができる。なお、演奏データは、フレーム番号データを含まない構成であってもよく、例えばフレーム毎の操作データの配列であれば、フレーム番号に代えて当該配列のインデックスによって演奏の正しいタイミングを特定することができる。
【０１１４】
他機演奏データ５３は、他のゲーム装置で生成された演奏データである。つまり、他機演奏データ５３は、他の装置に割り当てられたパート（他パート）の演奏の内容を示す。本実施形態では、他機演奏データ５３は、自機演奏データ５２と同様、操作データとフレーム番号データとを複数組含む。なお、２つ以上のゲーム装置が合奏ゲームをおこなう場合（すなわち、一緒に合奏を行う他のゲーム装置が複数存在する場合）、他機演奏データ５３は、他装置毎に記憶される。
【０１１５】
なお、本実施形態においては、各演奏データ５２，５３は、演奏期間中における時点を示すデータ（フレーム番号データ）と、当該時点におけるプレイヤによって行われた演奏操作を示すデータ（操作データ）とを含むものであり、後述するが当該操作データは、パート音の生成に用いられる演出データに変更される。
【０１１６】
ここで、各演奏データ５２，５３は、プレイヤによる演奏内容を特定することができ、演奏内容を再現することができる情報であればどのようなものであってもよい。例えば、他の実施形態においては、各演奏データ５２，５３は、フレーム番号と、当該フレーム番号に相当する時刻において出力すべき音との対応を示すデータであってもよい。
【０１１７】
また、別の実施形態においては、各演奏データ５２，５３の操作データは、フレーム番号と、当該フレーム番号に相当する時刻において出力すべき音に対応する操作を評価する評価情報（例えば、適切な操作がされた場合には「ＯＫ」、適切でない操作がされた場合には「ＮＧ」等）を示す正誤データであってもよい。さらに、評価情報としては、基準となる正しい演奏ボタン操作との操作ずれ量、あるいは操作位置が所定の操作位置を基準とする許容範囲内であるか否かを判定し、許容範囲外の場合には当該所定の操作位置に対する位置ずれ量を含めるようにすることも可能である。例えば、操作指示画像を所定位置に向けて移動表示し、操作指示画像が操作可能なカーソルに到達したときに操作すべき正しいタイミングとなるような態様の場合に、カーソルの中央部分に操作指示画像を合わせた場合に正しい演奏ボタン操作とし、中央部分からずれた場合に適切でない演奏ボタン操作と判断して、中央部分からの位置ずれ量を含めるようにしても良い。
【０１１８】
楽曲データ５６は、楽曲の長さやパート数等、楽曲に関する各種データや楽曲の楽譜の音符に対応する演奏操作指示情報および演奏出力情報を含むデータである。
【０１１９】
演奏操作指示情報は、一例では楽曲の楽譜の音符に対応して演奏の操作を指示する情報であり、演奏出力情報は、楽曲の楽譜の音符に対する演奏の操作に従って出力する音に関する情報である。
【０１２０】
具体的には、楽曲データ５６は、演奏操作指示情報として、フレーム番号データと、当該フレーム番号データに相当する時刻において行なうべき演奏ボタン操作を示すデータ（演奏操作指示データ）を含む。また、楽曲データ５６は、演奏出力情報として、フレーム番号データと、当該フレーム番号データに相当する時刻において行なうべき演奏ボタン操作に応じて出力すべき音との対応を示すデータ（演奏出力データ）を含む。なお、当該演奏操作指示データおよび演奏出力データを総称して音符データとも称する。
【０１２１】
なお、演奏出力情報には、当該フレーム番号データに相当する時刻において行なうべき演奏ボタン操作等のズレ量に応じた音程のズレ量を示すデータを含めるようにしてもよい。例えば、演奏ボタン操作のタイミング（フレーム数）のズレや演奏ボタン操作のズレ（正しい演奏ボタンから何個分ずれた演奏ボタンを操作したか等）のデータを含んでもよい。
【０１２２】
当該演奏操作指示情報および演奏出力情報が、その楽曲を構成するパート毎に含まれている。さらには、プレイヤ操作に応じた音の出力に対するＢＧＭとなる音声ファイルデータも記憶されていてもよい。このデータは、上記演奏出力情報として用いられる。
【０１２３】
なお、当該演奏操作指示情報に従って、図４に示すゲーム画像として説明した操作指示画像および操作期間画像が表示される。
【０１２４】
ゲーム装置１０は、楽曲データ５６を用いて、プレイヤ操作に応じた演奏音を生成したり、自機パート以外のパート（他パート）について演奏音を生成したり、画面に表示される指示画像の配置を決定したりする。なお、自機パート以外のパートについての自動演奏は、パートごとに音声ファイルデータを用意してそれを再生するようにしてもよいし、他のゲーム装置から取得した演奏データに基づいてプログラム処理により音を出力するようにしてもよい。
【０１２５】
また、ゲーム装置１０は、複数の楽曲について楽曲データを記憶していてもよい。また、各ゲーム装置が利用可能な不揮発メモリ（たとえば内部メモリなど）に楽曲データ記憶領域を形成し、所定のサーバ（複数の楽曲データを記憶する）からダウンロードした楽曲データを当該楽曲データ記憶領域に記憶可能にしてもよい。さらに、各ゲーム装置におけるプレイヤ入力に基づいて楽曲データを作成し、当該作成されたデータを当該楽曲データ記憶領域に記憶するようにしてもよい。上記の場合、ゲームシステムに含まれる各ゲーム装置が記憶している楽曲データは、それぞれ異なる楽曲の楽曲データが記憶される可能性があることとなる。また、作成した楽曲データを他のゲーム装置に配信して、他のゲーム装置でも利用するようにしても良い。
【０１２６】
パートデータ５７は、合奏を行う際における、ゲーム装置とそれに割り当てられるパートとの対応を示すデータである。より具体的には、パートデータ５７は、ゲーム装置の識別情報とパートの識別情報とを対応付けたデータである。さらに、本実施形態では、パートデータ５７は、ゲーム装置との対応を示す。なお、パートとゲーム装置との対応が無い部分については当該パートについては必要に応じて自動演奏あるいは演奏無しとして処理することが可能である。
【０１２７】
グループデータ５８は、自機と同じグループに属する他のゲーム装置の識別情報を示す。また、演奏楽曲指定データ５９は、演奏時に各プレイヤによって演奏される楽曲（演奏楽曲）を識別するためのデータである。
【０１２８】
＜４．ゲーム処理の詳細＞
＜４．１  ゲーム処理のメインフロー＞
次に、ゲーム装置１０において行われるゲーム処理の詳細について説明する。
【０１２９】
図７は、ゲーム装置１０において実行されるゲーム処理の流れを示すフローチャートである。
【０１３０】
図７を参照して、まず、ゲーム装置１０の電源が投入されると、ゲーム装置１０のＣＰＵ２１１は、図示しないブートＲＯＭに記憶されている起動プログラムを実行し、メインメモリ２３等の各ユニットが初期化される。そして、メモリカード１７に格納されたゲームプログラムがメインメモリ２３に読み込まれ、ＣＰＵ２１１によって当該ゲームプログラムの実行が開始される。図７に示すフローチャートは、以上の処理が完了した後に実行されるゲーム処理を示すフローチャートである。
【０１３１】
まず、ステップＳ１において、ＣＰＵ２１１は、サーバ１に対して接続処理を行う。前述したように、サーバ１は、マッチング処理、すなわち、一緒に合奏ゲームを行うゲーム装置のグループを決定する処理を実行する。つまり、ステップＳ１の処理は、ゲーム装置１０がサーバ１に対してマッチング処理を実行することを要求する処理である。具体的には、ＣＰＵ２１１は、自機を識別するため情報（例えばＩＰアドレス）を含むマッチング要求データを無線通信モジュール３７を介してサーバ１へ送信する。
【０１３２】
サーバ１は、マッチング要求データを受信したことに応じて、同じくマッチング要求データを送信してきた他のゲーム装置のうちから、ゲーム装置１０と一緒に合奏ゲームを行うゲーム装置を接続相手として選出する。なお、メモリカード１７に格納されたゲームプログラムを識別するための情報（ゲームプログラムＩＤ）をマッチング要求データに含めて、サーバに送信してもよく、この場合、サーバ１は、同じゲームプログラムＩＤを含むマッチング要求データを送信してきた他のゲーム装置を、ゲーム装置１０の接続相手として選出する。なお、ゲームプログラムＩＤはゲームプログラムとともにメモリカード１７に記憶されている。
【０１３３】
本実施形態においては、ゲーム装置１０は、所定範囲内の数を示す番号データをマッチング要求データに含めて送信することができる。この番号データの数は、プレイヤによって指定される。サーバ１は、番号データを含むマッチング要求データを受信した場合、同じ数の番号データを含むマッチング要求データを送信してきた他のゲーム装置を、ゲーム装置１０の接続相手として選出する。上記番号データは、例えば知人同士で一緒に合奏ゲームを行いたい場合に有効である。すなわち、送信する番号データの数を知人と予め決めておくことによって、サーバ１は知人同士のゲーム装置をマッチングするので、知人同士で一緒に合奏ゲームを行うことができる。
【０１３４】
なお、マッチングの方法は、上記番号データを用いた方法に限らず、何らかの条件を示すデータをマッチング要求データに含ませて送信する方法であってもよいし、サーバ１がランダムにゲーム装置を選出する方法であってもよい。前者の場合、例えば、ゲームの習熟度を表すデータをマッチング要求データに含ませて送信し、習熟度が同じレベルのゲーム装置同士をマッチングする方法が考えられる。
【０１３５】
サーバ１は、予め定められた上限数の接続相手を選出した場合、または、上記上限数よりも小さい所定数の接続相手を選出してから所定時間が経過した場合、マッチング処理を終了する。これによって、ゲーム装置１０と、選出された接続相手のゲーム装置とからなるグループが形成されたこととなる。なお、合奏ゲームの場合、上記上限数は、楽曲を構成するパートの数とすることが好ましい。また、上記所定数および所定時間は、ゲーム装置１０によって設定されるようにしてもよい。サーバ１は、マッチング処理を終了すると、上記グループ内の各ゲーム装置へ接続相手のゲーム装置を識別するデータを送信する。また、本実施形態では、サーバ１は、上記データを送信する際、グループ内の１つのゲーム装置をリーダーとして選出し、選出されたゲーム装置にリーダーであることを通知する。
【０１３６】
ステップＳ２においては、ＣＰＵ２１１は、接続相手の識別情報を示すデータをサーバ１から受信しグループデータ５８としてメインメモリ２３に登録する（記憶する）。これによって、ゲーム装置１０は、グループに含まれる他のゲーム装置との通信が可能となる。以降においては、サーバ１を介さずに、グループに含まれる各ゲーム装置同士で直接通信が行われる。なお、本実施形態では、ゲームシステムに含まれる複数のゲーム装置を、サーバ１を用いて決定するようにしたが、ゲームシステムに含まれる複数のゲーム装置の決定方法は、どのような方法であってもよく、サーバ１を用いない方法であってもよい。また、マッチング後もサーバ１を介して通信するようにしてもかまわない。
【０１３７】
なお、ステップＳ１およびＳ２の処理は、メモリカード１７に格納されたゲームプログラムの実行によらず、ゲーム装置１０に内蔵されたプログラムによって実行してもかまわない。そのようにすれば、メモリカード１７を所持しないプレイヤであっても合奏ゲームに参加することが可能になる。なお、この場合、そのゲーム装置に対して、サーバまたは他のゲーム装置（典型的にはマッチングされたゲーム装置）からゲームプログラムが配信されてそれが実行される。
【０１３８】
なお、本例においては、一例としてサーバ／クライアント通信により一緒に合奏ゲームを行なうゲーム装置のグループを決定するマッチング処理等を実行する方式について説明しているがサーバ／クライアント通信に限られず、サーバを介さずにＰ２Ｐ通信により他のゲーム装置と通信して上記と同様の処理を実行するようにしてもよい。その場合、あるゲーム装置１０が上記のサーバ１のマッチング処理等の機能と同様の処理を実行するようにすればよい。当該処理を実行するためのプログラムは、装着されるメモリカードに記憶しておいてもよいし、装置本体に予め内蔵しておいてもよい。なお、Ｐ２Ｐ通信に限られずネットワークを介さないローカル通信においても同様の処理が可能である。
【０１３９】
ステップＳ３において、ＣＰＵ２１１は、楽曲決定処理を実行する。楽曲決定処理は、合奏ゲームにおいて演奏を行う楽曲を決定するための処理である。
【０１４０】
そして、ステップＳ３の次のステップＳ４において、ＣＰＵ２１１は、パート決定処理を実行する。パート決定処理は、ステップＳ３で決定された演奏楽曲を構成する各パートのうち、グループ内の各ゲーム装置においてそれぞれどのパートを演奏するかを決定する処理である。
【０１４１】
そして、ステップＳ４の次のステップＳ５において、ＣＰＵ２１１は、演奏処理を実行する。演奏処理は、演奏をプレイヤに行わせる処理である。
【０１４２】
そして、ステップＳ５の次のステップＳ６において、ＣＰＵ２１１は、合奏ゲームを終了するか否かを判定する。ステップＳ７の判定は、プレイヤにより合奏ゲームを終了する旨の指示があったか否か、あるいは所定回数の合奏を行ったか否か等により行われる。ステップＳ６の判定結果が否定である場合（ステップＳ６においてＮＯ）には、ステップＳ３の処理が再度実行される。このとき、リーダーであるゲーム装置を変更するようにしてもよい。例えば、リーダーであるゲーム装置は、次にリーダーとなるゲーム装置をグループ内の他のゲーム装置から選択するようにしてもよい。一方、ステップＳ６の判定結果が肯定である場合（ステップＳ６においてＹＥＳ）には、ＣＰＵ２１１は、図７に示すゲーム処理を終了する。
【０１４３】
＜４．２  楽曲決定処理のフロー＞
次に、楽曲決定処理の詳細について説明する。
【０１４４】
図８は、図７に示す楽曲決定処理（ステップＳ３）の詳細を示すフローチャートである。
【０１４５】
図８を参照して、楽曲決定処理においては、まずステップＳ１０において、ＣＰＵ２１１は、自機がリーダーに設定されているか否かを判定する。ステップＳ１０において、ＣＰＵ２１１は、自機がリーダーに設定されていると判定した場合（ステップＳ１０においてＹＥＳ）、ステップＳ１１の処理が実行される。
【０１４６】
一方、ステップＳ１０において、ＣＰＵ２１１は、自機がリーダーに設定されていないと判定した場合（ステップＳ１０においてＮＯ）、ステップＳ１３の処理が実行される。
【０１４７】
リーダーのゲーム装置では、ステップＳ１１の処理が実行される。すなわち、ステップＳ１１において、ＣＰＵ２１１は、演奏期間において演奏を行う楽曲を決定する。楽曲の決定は、メインメモリ２３に楽曲データ５６として記憶されている楽曲のうちから、所望の楽曲をゲーム装置１０のプレイヤが指定することによって行われる。その結果、決定された楽曲を識別するためのデータが演奏楽曲指定データ５９としてメインメモリ２３に登録される。つまり、本実施形態では、リーダーであるゲーム装置を用いるプレイヤが、演奏する楽曲を決定することができる。本例においては、リーダーであるゲーム装置を用いるプレイヤが演奏する楽曲を決定する場合について説明するが、特に当該方式に限られずグループ内の他のゲーム装置からの楽曲の選択も要求して多数決によって楽曲を決定するようにしてもよい。また、他の実施形態においては、メインメモリ２３に楽曲データ５６として記憶されている楽曲のうちからランダムに楽曲が決定されてもよい。あるいは、サーバ１に楽曲データが記憶されていて、当該サーバ１に記憶されている楽曲から演奏する楽曲を決定するようにしても良い。
【０１４８】
以下では、ステップＳ１１で決定された楽曲を演奏楽曲とも称する。
続くステップＳ１２において、ＣＰＵ２１１は、上記演奏楽曲を他のゲーム装置へ通知する。具体的には、当該演奏楽曲を示すデータ（演奏楽曲指定データ５９）が無線通信モジュール３７からネットワークを介して他のゲーム装置へ送信される。リーダーに設定されているゲーム装置においては、ステップＳ１２の後、後述するステップＳ１７の処理が実行される。
【０１４９】
一方、リーダーでないゲーム装置においては、ステップＳ１３の処理が実行される。すなわち、ステップＳ１３において、ＣＰＵ２１１は、決定された演奏楽曲の通知（ステップＳ１２）を無線通信モジュール３７によって受信する。具体的には、リーダーのゲーム装置から演奏楽曲指定データ５９を受信してメインメモリ２３に登録する。これによって、リーダーでないゲーム装置は、演奏楽曲を知ることができる。
【０１５０】
続くステップＳ１４において、ＣＰＵ２１１は、演奏楽曲の楽曲データが自機のメインメモリ２３に記憶されているか否かを判定する。なお、本実施形態においては、ゲーム装置１０は、プレイヤによって作成された楽曲データを新たに記憶したり、新たな楽曲データを他の装置から取得することが可能であるとする。したがって、各ゲーム装置において記憶されている楽曲データは必ずしも一致せず、あるゲーム装置において記憶されている楽曲データが他のゲーム装置では記憶されていないこともあり得る。
【０１５１】
ステップＳ１４において、ＣＰＵ２１１は、演奏楽曲の楽曲データが自機のメインメモリ２３に記憶されていると判定した場合（ステップＳ１４においてＹＥＳ）、ステップＳ１５の処理が実行される。
【０１５２】
一方、ステップＳ１４において、ＣＰＵ２１１は、演奏楽曲の楽曲データが自機のメインメモリ２３に記憶されていないと判定した場合（ステップＳ１４においてＮＯ）、ステップＳ１６の処理が実行される。
【０１５３】
ステップＳ１５において、ＣＰＵ２１１は、楽曲データの送信が不要である旨をリーダーのゲーム装置に対して通知する。一方、ステップＳ１６において、ＣＰＵ２１１は、楽曲データの送信を要求する。つまり、リーダーでないゲーム装置は、演奏楽曲の楽曲データを記憶していない場合には無線通信モジュール３７を用いて当該楽曲データの送信を要求し、当該楽曲データを記憶している場合には送信不要の旨を無線通信モジュール３７を用いて通知する。
【０１５４】
ステップＳ１５の後、ＣＰＵ２１１は図８に示す楽曲決定処理を終了する。また、ステップＳ１６の後、ＣＰＵ２１１は後述するステップＳ１９の処理を実行する。一方、リーダーのゲーム装置においては、ステップＳ１２の後にステップＳ１７の処理が実行される。すなわち、ステップＳ１７において、ＣＰＵ２１１は、他の全てのゲーム装置が演奏楽曲の楽曲データを記憶しているか否かを判定する。ステップＳ１７の判定は、上記ステップＳ１５またはＳ１６で他のゲーム装置から送信されてくる内容に基づいて行うことができる。すなわち、少なくとも１つの他のゲーム装置から楽曲データの送信の要求があった場合、ステップＳ１７の判定結果は、記憶していない（ステップＳ１７においてＮＯ）と判断される。
【０１５５】
一方、全ての他のゲーム装置から楽曲データの送信不要の通知があった場合、ステップＳ１７の判定結果は記憶している（ステップＳ１７においてＹＥＳ）と判断される。ステップＳ１７においてＮＯの場合、ステップＳ１８の処理が実行される。一方、ステップＳ１７の判定結果が肯定である場合、ステップＳ１８の処理がスキップされて、ＣＰＵ２１１は図８に示す楽曲決定処理を終了する（リターン）。
【０１５６】
ステップＳ１８において、ＣＰＵ２１１は、演奏楽曲の楽曲データを、楽曲データの送信を要求した他のゲーム装置、すなわち、演奏楽曲の楽曲データを記憶していない他のゲーム装置へ無線通信モジュール３７を用いて送信する。
【０１５７】
一方、リーダーでないゲーム装置においては、ステップＳ１６の次にステップＳ１９の処理が実行される。ステップＳ１９においては、ＣＰＵ２１１は、リーダーのゲーム装置からステップＳ１８で送信される楽曲データを無線通信モジュール３７によって受信する。これによって、リーダーでないゲーム装置のプレイヤは、自機が知らない楽曲（ゲーム装置に楽曲データが記憶されていない楽曲）についても合奏を行うことができるとともに、自機で演奏可能な楽曲の数を増やすことができる。ステップＳ１９の後、ＣＰＵ２１１は、図８に示す楽曲決定処理を終了する（リターン）。なお、本例においては、リーダーのゲーム装置が決定した楽曲データについて、グループ内のリーダーでない他のゲーム装置が当該楽曲データを記憶していない場合には、リーダーのゲーム装置に対して楽曲データを要求して、当該楽曲データを受信する場合について説明したが、特にこれに限られず、例えば、当該楽曲データを記憶していない場合には、演奏する楽曲データの再選択をリーダーのゲーム装置に対して要求するようにしてもよいし、あるいは、合奏を中止するようにしてもよい。
【０１５８】
＜４．３  パート決定処理のフロー＞
次に、パート決定処理の詳細について説明する。
【０１５９】
図９は、図７に示すパート決定処理（ステップＳ４）の詳細を示すフローチャートである。
【０１６０】
図９を参照して、パート決定処理においては、まずステップＳ２１において、ＣＰＵ２１１は、グループ内の全てのゲーム装置がパートを決定したか否かを判定する。
【０１６１】
ステップＳ２１の判定は、メインメモリ２３に記憶されているパートデータ５７を参照することによって行われる。すなわち、当該パートデータ５７を参照し、全てのゲーム装置についてゲーム装置とパートとの対応を示すデータがある場合、全てのゲーム装置がパートを決定したと判定される。
【０１６２】
ステップＳ２１において、グループ内の全てのゲーム装置がパートを決定したと判定した場合（ステップＳ２１においてＹＥＳ）、ＣＰＵ２１１は、図１０に示すパート決定処理を終了する（リターン）。
【０１６３】
なお、グループ内の全てのゲーム装置がパートを決定したと判定した場合に、パートの数がゲーム装置よりも多い場合には、残りの決定されていないパートについては自動演奏のパートとして処理しても良いし、あるいは演奏無し（無演奏）として処理しても良い。
【０１６４】
一方、ステップＳ２１において、グループ内の全てのゲーム装置がパートを決定していないと判定した場合（ステップＳ２１においてＮＯ）、ステップＳ２２の処理が実行される。
【０１６５】
ステップＳ２２において、ＣＰＵ２１１は、演奏楽曲の各パートのうちで、自機のプレイヤが選択可能なパートを上側ＬＣＤ１１または下側ＬＣＤ１２に表示させる。なお、本実施形態では、一例として複数のゲーム装置に対して同じパートが割り当てられないようにすることが可能である。つまり、ステップＳ２２では、他のゲーム装置がすでに選択したパートは除外され、残りのパートのみが選択可能なように表示される。具体的には、メインメモリ２３に記憶されているパートデータ５７にゲーム装置とパートとの対応が含まれている場合、当該パートは除外される。表示の様態としては、残りパートのみを表示してもよいし、残りパートと既に選択されたパートとの色を変える等して区別して表示するようにしてもよい。また、既に選択されたパートと同じパートを選択できるようにしてもよい。
【０１６６】
続くステップＳ２３において、ＣＰＵ２１１は、選択されたパートを示すデータ（選択パートデータ）を無線通信モジュール３７によって他のゲーム装置から受信したか否かを判定する。ここで、他のゲーム装置においてパートが選択された場合には、当該他のゲーム装置から、選択パートデータが送信されてくる。ステップＳ２３において、ＣＰＵ２１１は、当該選択パートデータが送信されてきたか否かを判定する。
【０１６７】
ステップＳ２３において、選択パートデータを受信したと判定した場合（ステップＳ２３においてＹＥＳ）、ステップＳ２４の処理が実行される。ステップＳ２３において、選択パートデータを受信していないと判定した場合（ステップＳ２３においてＮＯ）、ステップＳ２５の処理が実行される。
【０１６８】
ステップＳ２４において、ＣＰＵ２１１は、他のゲーム装置において選択されたパートを当該他のゲーム装置に割り当てる。つまり、ステップＳ２３で選択パートデータを送信してきたゲーム装置に対して、当該選択パートデータにより示されるパートが割り当てられる。
【０１６９】
したがって、ＣＰＵ２１１は、ステップＳ２３で選択パートデータを送信してきたゲーム装置と、当該選択パートデータにより示されるパートを含むように、メインメモリ２３に記憶されているパートデータ５７の内容を更新する。ステップＳ２４の後、ステップＳ２１の処理が再度実行される。
【０１７０】
一方、ステップＳ２５において、ＣＰＵ２１１は、自機においてパートが選択されたか否かを判定する。具体的には、操作スイッチ１４およびタッチパネル１５に対して行われた入力に基づいて、ステップＳ２２で表示されているパートのうちから１つを選択する操作が行われたか否かを判定する。
【０１７１】
ステップＳ２５において、ＣＰＵ２１１は、自機においてパートが選択されたと判定した場合（ステップＳ２５においてＹＥＳ）、ステップＳ２６の処理が実行される。ステップＳ２５において、ＣＰＵ２１１は、自機においてパートが選択されたと判定した場合（ステップＳ２５においてＮＯ）、ステップＳ２１の処理が再度実行される。
【０１７２】
ステップＳ２６において、ＣＰＵ２１１は、ステップＳ２５において選択されたパートを自機に割り当てる。そして、自機と、ステップＳ２５において選択されたパートを含むように、メインメモリ２３に記憶されているパートデータ５７の内容を更新する。
【０１７３】
続くステップＳ２７において、ＣＰＵ２１１は、ステップＳ２６で選択されたパートを示す選択パートデータを、グループデータ５８を参照して、グループに含まれる全ての他のゲーム装置へ送信する。ステップＳ２７の後、ステップＳ２１の処理が再度実行される。
【０１７４】
以上のステップＳ２１〜Ｓ２７で説明したように、本実施形態では、グループに含まれる各ゲーム装置のプレイヤが早い者順でパートを選択することによって、各ゲーム装置に割り当てられるパートが決定される。なお、他の実施形態においては、各ゲーム装置に割り当てられるパートはランダムに決定されてもよいし、パートを選択するプレイヤの順序をランダムに決定するようにしてもよい。また、本例においては、一例として複数のゲーム装置に対して同じパートが割り当てられないようにする場合について説明したが、特に当該場合に限られず複数のゲーム装置に対して同じパートが割り当てられることを許容するようにしてもよい。具体的には、ステップＳ２２において演奏楽曲の選択可能な全てのパートを表示するようにしてもよい。あるいは、複数のゲーム装置に対して同じパートを許容する個数（台数）を制限するようにしてもよい。
【０１７５】
＜４．４  演奏処理のフロー＞
次に、演奏処理の詳細について説明する。
【０１７６】
図１０は、図７に示す演奏処理（ステップＳ５）の詳細を示すフローチャートである。
図１０を参照して、演奏処理においては、まずステップＳ６１において、ＣＰＵ２１１は開始タイミング決定処理を実行する。
【０１７７】
開始タイミング決定処理は、演奏期間を開始するタイミングを決定する処理である。なお、演奏期間とは、プレイヤが演奏を行うことが可能な期間であり、換言すれば、ゲーム装置がプレイヤによる演奏操作を受け付ける期間である。開始タイミング決定処理については後述する。
【０１７８】
次に、ステップＳ６１の開始タイミング決定処理の次に、ステップＳ６２〜Ｓ７１の処理ループが実行される。なお、この処理ループは、１回の処理ループが１フレーム時間毎に実行される。
【０１７９】
ステップＳ６２において、ＣＰＵ２１１は、自機の演奏ボタンに対して行われた演奏操作を示す操作データを操作スイッチ１４から取得する。当該操作データは、各演奏ボタンが押下されたか否かを示すデータを含む。
【０１８０】
続くステップＳ６３において、ＣＰＵ２１１は、ステップＳ６２で取得された操作データに対して、自機に設定されている所定の変換を行い自機パート音の生成に用いられる演出データを生成する。具体的には、操作データにより押下されたことが示される演奏ボタンの種類が、楽曲データ５６のパートに基づいて変更される。操作データが正しい演奏ボタンが押下されていることを示していれば、当該操作データは、演出データとして、現在のタイミングで押下すべき正しい演奏ボタンが押下されていることを示す内容に変更される。
【０１８１】
ここで、押下すべき正しい演奏ボタンは、楽曲データ５６を参照することによって特定することができる。また、ＬボタンやＲボタンとあるボタン（十字キーなど）とを同時に押下すべきタイミングにおいて、操作データが当該あるボタンが押下されていることを示していれば、当該操作データは、演出データとして、当該あるボタンとＬボタンやＲボタンが同時に押下されていることを示す内容に変更される。なお、ＬボタンやＲボタンを押下すべきタイミングであるか否かは、楽曲データ５６を参照することによって決定することができる。
【０１８２】
すなわち、ステップＳ６３において、ＣＰＵ２１１は、ステップＳ６２で取得された操作データと楽曲データに含まれる自機に対応するパートの演奏操作指示データとを比較し、少なくとも両者のタイミングが許容範囲であることを判断して、比較結果に基づいてステップＳ６２で取得された操作データを楽曲データで定める演出データに変換する。演出データの一例として、一致している場合には演出データの一例として演奏フラグを立て（演奏フラグデータをオン）、一致していない場合には演出データの一例として演奏フラグを立てない（演奏フラグデータをオフ）ようにする。
【０１８３】
さらには、当該比較において、一致しない場合には、ステップＳ６２で取得された操作データと楽曲データに含まれる演奏操作指示データとの操作種類（例えば押下された演奏ボタンの種類）のずれ関係をさらに判断してもよい。具体的には、演奏ボタンに対応付けられている音に関して、押下された演奏ボタンの操作種類に基づいて、演奏操作指示データに対応する正しい音からずれている音程の個数を演出データに含めるようにしても良い。
【０１８４】
なお、楽曲データに関して楽譜内には休止位置、音符が存在しない無演奏部分といった所定部分も存在する。当該所定部分については、演奏操作指示データおよびそれに対応する演奏出力データは設けられないようにして、当該所定部分に対する操作データについて無効として処理して、無音状態（演出データ生成無し）とすることも可能である。あるいは、当該所定部分に対する操作データについても受け付けて演出データを生成することも可能である。この場合、演奏操作指示データとしては任意の操作データを許容するようにして、演出データとして演奏フラグデータをオンするようにすれば良い。そして、当該演奏フラグデータのオンに従って、演奏出力データについては出力すべき音を予め設定しておいても良いし、演出データに演奏ボタンに対応付けられている音に関する情報を含めて、演奏ボタンに従う音を任意に出力させるようにすることも可能である。当該処理によりいわゆるアドリブ演奏を行なうことが可能となる。
【０１８５】
続くステップＳ６４において、ＣＰＵ２１１は、取得した操作データを用いて自機データを生成し、グループデータ５８に登録された他のゲーム装置へ無線通信モジュール３７を介して送信する。
【０１８６】
図１１は、送信する自機データ６０のパケット構成の概略を説明する図である。
図１１を参照して、自機データ６０は、ステップＳ６２の操作データ６２と、当該操作データが取得されたフレーム時刻を示すフレーム番号データ６４と、送信情報６６とを含む。なお、その他のパケットを識別するための識別番号等を含むヘッダ情報が付加されていても良い。フレーム番号データは、例えば、演奏期間が開始された時点で取得されたフレーム番号を“１”として、１フレーム毎に１ずつインクリメントされた番号を示す。送信情報は、送信元である自機を識別するデータ（自機識別データ）および送信先であるグループデータ５８に登録されている他機を識別するデータ（他機識別データ）とを含む。
【０１８７】
なお、本例においては、一例として操作データとして押下された演奏ボタンの種類に関する情報について説明しているが、演奏ボタンの種類ではなく、操作の正誤データ（各ゲーム装置において、操作データと演奏操作指示データとを比較して、正しい操作が行なわれたか否かを示す評価情報）を他機のゲーム装置に送信するようにしてもよい。そして、当該他機のゲーム装置では、受信した評価情報（操作の正誤データ）に基づいて演出データに変換するようにしてもかまわない。さらに、評価情報に、正しい操作とのずれ量を含めて、当該ずれ量に基づく演出データに変換するようにしてもかまわない。当該評価情報に従って、正しい操作とのずれ量に基づく推定演出データを生成するようにしてもよい。  
【０１８８】
なお、受信する他機データのパケット構成についても同様である。
再び、図１０を参照して、ステップＳ６４の処理が１フレーム毎に実行されることによって、各ゲーム装置から他のゲーム装置へ、１フレーム毎にデータが逐次送信されることとなる。なお、当該他のゲーム装置は、１フレーム毎に送信されたデータを逐次受信する。なお、ゲーム装置から他のゲーム装置へ送信される演奏データが確実に送信先のゲーム装置で受信されるように、当該送信先のゲーム装置は、演奏データを受信したことを確認する通知を送信元のゲーム装置に返信するようにしてもよい。このとき、送信元のゲーム装置は、演奏データを送信してから所定時間内に返信がない場合、当該演奏データを再送信するようにしてもよい。また、上記のように生成された自機データ６０はメインメモリ２３に記憶される。
【０１８９】
なお、本実施形態においては、ゲーム装置１０は、自機データを演奏期間中において逐次送信するようにしたが、他の実施形態においては、ゲーム装置は、演奏処理に影響を与えない所定期間毎に自機データをまとめて他のゲーム装置へ送信するようにしてもよい。
【０１９０】
続くステップＳ６５において、ＣＰＵ２１１は、グループデータ５８に登録された他のゲーム装置から送信されてくるデータ（他機データ）を無線通信モジュール３７によって受信する。そして、当該データを他機演奏データ５３としてゲーム装置毎にメインメモリ２３に記憶する。
【０１９１】
なお、各ゲーム装置間の通信状況は常に一定ではなく遅延も生じるので、あるフレームにおけるステップＳ６２〜Ｓ７１の処理ループにおいては、他機データが受信されず、他の処理ループで複数回データを受信するとともに、当該受信に対応して複数回、他機演出データを生成することもある。また、通信状況が変化した場合には、パケットロストも発生する場合もある。
【０１９２】
続くステップＳ６６において、ＣＰＵ２１１は、ステップＳ６５で受信した他機データに対して、他機に設定されている所定の変換を行い他パートの音の生成に用いられる演出データを生成する。具体的には、操作データにより押下されたことが示される演奏ボタンの種類が、楽曲データ５６のパートに基づいて変更される。ステップＳ６３で上述したように操作データが正しい演奏ボタンが押下されていることを示していれば、当該操作データは、演出データとして、現在のタイミングで押下すべき正しい演奏ボタンが押下されていることを示す内容に変更される。
【０１９３】
すなわち、ステップＳ６６において、ＣＰＵ２１１は、ステップＳ６５で受信された他機データに含まれる操作データと楽曲データに含まれる他機に対応するパートの演奏操作指示データとを比較し、少なくとも両者のタイミングが許容範囲であることを判断して、比較結果に基づいてステップＳ６５で受信した操作データを楽曲データで定める演出データに変換する。演出データの一例として、一致している場合には演奏フラグを立て（演奏フラグデータをオン）、一致していない場合には演奏フラグを立てない（演奏フラグデータをオフ）ようにする。
【０１９４】
ステップＳ６６の後、ステップＳ６７〜Ｓ６９において、自機パートおよび他パートの演奏音が生成されて出力される。
【０１９５】
すなわち、ステップＳ６７において、ＣＰＵ２１１は、ステップＳ６３の処理後の演出データを用いて自機パートの演奏音を生成する。すなわち、現在のフレームにおいてプレイヤによって押下された演奏ボタンを上記操作データに基づいて判別し、押下された演奏ボタンの種類に基づいて、出力すべき音の音程を決定する。より具体的には、パートデータ５７を参照して当自機パートを判断し、当該自機パートに対応する音データが使用される。
【０１９６】
すなわち、例えば、自機パートがギターである場合には、ギターの音データが使用され、自機パートがピアノである場合には、ピアノの音データが使用される。なお、楽曲ごと（または楽曲の部分ごと）に各パートの音を変更したり、楽曲ごと（または楽曲の部分ごと）に演奏ボタン操作に対して出力する音を変更する場合には、演奏楽曲指定データ５９で指定される楽曲の楽曲データに含まれる自機パートに対応する音データが使用される。
【０１９７】
一例として、プレイヤ操作が正しい操作であるときのみ対応する音を出力する場合には、すなわち、プレイヤが演奏操作指示に基づく正しいタイミングで（かつ正しい演奏ボタン操作で）操作したときにのみ対応する音を出力する場合には、当該操作データが正しいタイミングか（かつ正しい演奏ボタン操作か）を、演奏楽曲指定データ５９で指定される楽曲の楽曲データに含まれる自機パートについての演奏操作指示データに基づいて判断して、当該判断が肯定のときのみ対応する音を出力する。具体的には、演出データとして、演奏フラグがオンしている場合のみ対応する音を出力する。
【０１９８】
続くステップＳ６８において、ＣＰＵ２１１は、楽曲データ５６を用いて他パートの演奏音を生成する。具体的には、楽曲データ５６を参照して、現在のフレームのタイミングで出力すべき音を特定し、特定された音を他パートの演奏音とする。これによって、ステップＳ６７で生成された自機パートの音とステップＳ６８で生成された他パートの音との同期をとることができる。
【０１９９】
なお、上述したようにゲーム装置間の通信には遅延が生じる場合があるので、遅延の度合いが大きい場合には他のゲーム装置から送信されたデータをゲーム装置が適切なタイミングで全て受信しているとは限らない。また、パケットロストが発生している場合も考えられる。そこで、本実施形態では、他のゲーム装置から受信したデータに基づいて、必要に応じて他パートを演奏するプレイヤの演奏に応じた他パートの音を出力するための推定された推定データを生成し、当該生成した推定データに基づいて他パートの演奏音を出力する。
【０２００】
当該他パートの演奏音の生成処理の詳細については後述する。
続くステップＳ６９において、ＣＰＵ２１１は、ステップＳ６７で生成された自機パートの演奏音と、ステップＳ６８で生成された他パートの演奏音とをスピーカ１８から出力させる。すなわち、プレイヤによる演奏操作に応じて自機パートの演奏音を出力しつつ、楽曲データ５６を用いて生成された他パートの演奏音を出力する。
【０２０１】
なお、他パートについて、プレイヤによる演奏ではなく、自動演奏が設定されている場合（例えば、演奏楽曲を構成するパートの数よりもグループに含まれるゲーム装置の数が少ない場合）には、楽曲データ５６を用いて他パートの自動演奏音を出力する。例えば、他パートの自動演奏に関しては、演出データとして、全ての演奏フラグをオンに設定して他パートの演奏音を出力するようにしても良いし、パート毎に音声ファイルデータを用意して、対応するパートの音声ファイルデータに基づいて演奏音を出力するようにしても良い。
【０２０２】
以上のステップＳ６７〜Ｓ６９によって、演奏楽曲の各パートの演奏音が合奏として出力されることとなる。
【０２０３】
なお、ステップＳ６９において、楽曲データに含まれるＢＧＭの音声ファイルデータに基づいて、楽曲のＢＧＭとなる演奏音を出力し、自機パートの演奏音と他パートの演奏音とＢＧＭの演奏音とを合成して出力するようにしてもよい。
【０２０４】
続くステップＳ７０において、ＣＰＵ２１１は、演奏楽曲指定データ５９で指定される楽曲データを参照して、パートデータ５７に登録された自機パートの演奏操作指示を表すゲーム画像（図４）を上側ＬＣＤ１１または下側ＬＣＤ１２に表示させる。ゲーム画像は、楽曲データ５６に基づいて生成することができる。
【０２０５】
ステップＳ７１において、ＣＰＵ２１１は、演奏期間が終了したか否かを判定する。演奏期間の長さは演奏楽曲の長さによって決まるので、ステップＳ７１の判定は、楽曲データ５６を参照して演奏楽曲の長さを用いて行うことができる。ステップＳ７１において、ＣＰＵ２１１は、演奏期間が終了したと判定した場合（ステップＳ４１においてＹＥＳ）、処理を終了する（エンド）。
【０２０６】
一方、ステップＳ７１において、ＣＰＵ２１１は、演奏期間が終了していないと判定した場合（ステップＳ７１においてＮＯ）、ステップＳ６２の処理が再度実行され、以降、演奏期間が終了するまでステップＳ６２〜Ｓ７１の処理ループが繰り返し実行される。
【０２０７】
＜４．４．１  開始タイミング決定処理のフロー＞
図１２は、図１０に示す開始タイミング決定処理（ステップＳ３１）の詳細を示すフローチャートである。
【０２０８】
図１２を参照して、開始タイミング決定処理においては、まずステップＳ５１において、ＣＰＵ２１１は、自機がリーダーに設定されているか否かを判定する。
【０２０９】
ステップＳ５１において、ＣＰＵ２１１は、自機がリーダーに設定されていると判定した場合（ステップＳ５１においてＹＥＳ）、ステップＳ５２の処理が実行される。ステップＳ５１において、ＣＰＵ２１１は、自機がリーダーに設定されていないと判定した場合（ステップＳ５１においてＮＯ）、ステップＳ５４の処理が実行される。
【０２１０】
リーダーのゲーム装置においては、ステップＳ５２およびＳ５３の処理が実行される。すなわち、ステップＳ５２において、ＣＰＵ２１１は、演奏期間を開始するタイミングを決定し、当該タイミングを示すデータを他のゲーム装置へ送信する。当該データは、例えば、演奏期間を開始するまでの残り時間を示すデータであってもよいし、演奏期間を開始する時刻を示すデータであってもよいし、演奏を即時に開始することを指示するデータであってもよい。また、他のゲーム装置へ通知されるタイミングは、リーダーのゲーム装置から他のゲーム装置へデータを送信した場合の遅延時間を考慮して決定されてもよい。このとき、リーダーのゲーム装置は、算出された遅延時間を考慮してグループ内の各ゲーム装置間でほぼ同じタイミングになるように、他のゲーム装置へそれぞれ異なる内容のデータを送信してもよい。
【０２１１】
続くステップＳ５３において、ＣＰＵ２１１は、ステップＳ５２で決定されたタイミングに従って演奏を開始する。すなわち、後述するステップＳ６２〜Ｓ７１（図１０）の処理ループを開始する。ステップＳ５３の後、ＣＰＵ２１１は、図１２に示す開始タイミング決定処理を終了する（リターン）。
【０２１２】
一方、リーダーでないゲーム装置においては、ステップＳ５４およびＳ５５の処理が実行される。すなわち、ステップＳ５４において、ＣＰＵ２１１は、演奏期間を開始するタイミングを示すデータをリーダーのゲーム装置から受信する。続くステップＳ５５において、ＣＰＵ２１１は、ステップＳ５４で受信したデータにより示される開始タイミングに従って演奏を開始する。ステップＳ５４の後、ＣＰＵ２１１は、図１２に示す開始タイミング決定処理を終了する（リターン）。
【０２１３】
以上に説明した開始タイミング決定処理によって、演奏期間を開始するタイミングがグループ内の各ゲーム装置間で同期することとなる。すなわち、各ゲーム装置は、ほぼ同じタイミングで演奏を開始し、ほぼ同じタイミングで演奏を終了する。これによって、他のゲーム装置からのデータ遅延が開始するタイミングのずれによって生じることを抑制することができる。なお、各ゲーム装置における開始タイミングは厳密に同時である必要はなく、演奏処理に影響を与えない範囲で例えば各ゲーム装置における開始タイミングにある程度のずれが生じていてもよい。なお、本例においては、各ゲーム装置における開始タイミングにずれが生じて他のゲーム装置からのデータ遅延が生じる場合であっても後述する補間処理に基づく推定演出データの生成により他のゲーム装置の演奏音が出力されるため開始タイミングのずれによるデータ遅延の影響による不快感を抑制することが可能である。また、一例として開始タイミング決定処理は、リーダーに設定されているゲーム装置から他のゲーム装置に対して開始タイミングを送信する場合について説明したが、例えば、サーバ１からそれぞれのゲーム装置に対して一斉に開始タイミングを送信するようにしても良い。
【０２１４】
＜４．４．２  他パート音生成処理のフロー＞
図１３は、図１０に示す他パート音生成処理（ステップＳ６８）の詳細を示すフローチャートである。この他パート音生成処理は、グループデータ５８に登録されたゲーム装置のそれぞれについて処理が実行される。
【０２１５】
図１３を参照して、他パート音生成処理においては、まずステップＳ８０において、ＣＰＵ２１１は、グループ内の他のゲーム装置の１つを選択する。なお、１回の他パート音生成処理の間にすでに選択されたゲーム装置以外のゲーム装置が選択される。ステップＳ８２〜Ｓ８８の処理においては、ステップＳ８０で選択されたゲーム装置に対応するパートの音が生成される。
【０２１６】
ステップＳ８２において、ＣＰＵ２１１は、現在のフレームに相当する他機の演出データ（図１０のステップＳ６６で生成した他機のゲーム装置の演出データ）がメインメモリ２３に記憶されているか否かを判定する。
【０２１７】
ステップＳ８２において、他のゲーム装置との通信が正常に行われている場合には、ステップＳ８２において、ＣＰＵ２１１は、現在のフレームに相当する他機の演出データが有ると判定（ステップＳ８２においてＹＥＳ）し、ステップＳ８４の処理を実行する。
【０２１８】
ステップＳ８４において、ＣＰＵ２１１は、他機の演出データを用いて、ステップＳ８０で選択された他のゲーム装置に対応する他パートの演奏音を生成する。他機の演出データは、上述した演奏処理のステップＳ６６でメインメモリ２３に記憶されている。
【０２１９】
他機の演出データを用いて他パートの演奏音を生成する方法は、自機の演出データを用いて自機パートの演奏音を生成する方法と同様である。ただし、あるゲーム装置から受信した他機データを用いて他パートの演奏音を生成する場合、パートデータ５７を参照して、当該あるゲーム装置のパートを判断し、当該他機データに基づく音出力は、当該パートに対応する音データが使用される。
【０２２０】
すなわち、例えば、当該あるゲーム装置のパートがギターである場合には、ギターの音データが使用され、当該あるゲーム装置のパートがピアノである場合には、ピアノの音データが使用される。なお、楽曲ごと（または楽曲の部分ごと）に各パートの音を変更したり、楽曲ごと（または楽曲の部分ごと）に演奏ボタン操作に対して出力する音を変更する場合には、演奏楽曲指定データ５９で指定される楽曲の楽曲データに含まれる当該あるゲーム装置のパートに対応する音データが使用される。また、プレイヤ操作が正しい操作であるときのみ対応する音を出力する場合には、当該あるゲーム装置の他機データに含まれる操作データが正しいタイミングか（かつ正しい演奏ボタン操作か）を、当該あるゲーム装置のパートについての演奏操作指示データに基づいて判断して、当該判断が肯定のときのみ対応する音を出力する。
【０２２１】
一方で、演奏中において、上述したようにゲーム装置間の通信には遅延が生じる場合があるので、遅延の度合いが大きい場合には他のゲーム装置から送信されたデータをゲーム装置が適切なタイミングで全て受信しているとは限らない。また、パケットロストが発生している場合も考えられる。その結果、当該他のゲーム装置については現在のフレームに相当する演奏部分のデータがメインメモリ２３に記憶されてない。
【０２２２】
現在のフレームに相当する他機の演出データが無い場合（ステップＳ８２においてＮＯ）には、ステップＳ８５に進み、ステップＳ８５において、ＣＰＵ２１１は、現在フレームから所定フレーム数以内に未処理の他機の演出データがメインメモリ２３に記憶されているか否かを判定する。
【０２２３】
ステップＳ８５において、現在フレームから所定フレーム数以内に未処理の他機の演出データがある場合（ステップＳ８５においてＹＥＳ）には、当該未処理の他機の演出データを用いて、上記のステップＳ８４で説明した他のゲーム装置に対応する他パートの演奏音をそのまま生成する。他機の演出データは、上述した演奏処理のステップＳ６６でメインメモリ２３に記憶されている。すなわち、当該処理は、ゲーム装置間の通信には遅延が生じる場合があるので、遅延の度合いがあまり問題にならない場合にはその遅延を許容して演奏処理するためのものである。この所定フレーム数以内のフレーム数は、任意の値に設定可能であるが、遅延した他機の演出データに基づく他パートの演奏音が耳触りにならない程度に設定することが可能である。
【０２２４】
なお、本例においては、所定フレーム数以内に未処理の他機の演出データが有る場合には、補間処理せず当該データをそのまま用いて演出データを生成する場合について説明しているが、所定フレーム数を超えるような場合であっても補間処理せず当該データをそのまま用いて演出データを生成するようにすることも可能である。具体的には、楽譜内において初めて音符が登場する拍のデータや、楽譜内において前奏の期間や休止期間が長い場合にその後、音符が登場する拍のデータ等であり、補間処理に使用可能なデータが存在しない場合等が挙げられる。
【０２２５】
一方、ステップＳ８５において、所定フレーム数以内に未処理の他機の演出データがメインメモリ２３に記憶されていない場合（ステップＳ８５においてＮＯ）には、ステップＳ８６の補間処理が実行される。補間処理は、現在のフレームに相当する他機の演出データが無い場合に当該演出データを推定して補間する。補間処理の詳細については後述する。
【０２２６】
そして、ステップＳ８８において、ＣＰＵ２１１は、補間処理された他機の推定された演出データ（推定演出データとも称する）を用いて、ステップＳ８０で選択された他のゲーム装置に対応する他パートの演奏音を生成する。他機の推定演出データは、上述した補間処理のステップＳ８６でメインメモリ２３に記憶されている。他機の推定演出データを用いて他パートの演奏音を生成する方法については、ステップＳ８４で説明したのと同様である。
【０２２７】
次に、ステップＳ８４またはＳ８８の次に、ステップＳ９０の処理が実行される。すなわち、ステップＳ９０において、ＣＰＵ２１１は、グループ内の全ての他のゲーム装置について、それに対応する他パート音を生成したか否かを判定する。ステップＳ９０の判定結果が肯定である場合、ＣＰＵ２１１は、図１４に示す他パート音生成処理を終了する（リターン）。
【０２２８】
一方、ステップＳ９０において、ＣＰＵ２１１は、グループ内の全ての他のゲーム装置について、それに対応する他パート音を生成していないと判定した場合（ステップＳ９０においてＮＯ）には、ステップＳ８０に戻り上記の処理を繰り返す。
【０２２９】
図１４は、図１３に示す補間処理（ステップＳ８６）の詳細を示すフローチャートである。
【０２３０】
図１４を参照して、まず、ＣＰＵ２１１は、他機のパートの現在のフレームは、所定部分であるか否かを判断する（ステップＳ１００）。本例においては、所定部分の一例としては、楽譜内の所定領域、具体的には、休止位置、音符が存在しない無演奏部分に相当する。当該所定部分については、本来演奏する音符が存在しない部分であるため当該部分についての推定演出データの生成を除外するための処理である。
【０２３１】
したがって、ステップＳ１００において、ＣＰＵ２１１は、他機のパートの現在のフレームが所定部分であると判断した場合（ステップＳ１００においてＹＥＳ）には、推定演出データを生成することなく、そのまま処理を終了する（リターン）。
【０２３２】
一方、ステップＳ１００において、他機のパートの現在のフレームが所定部分でない場合（ステップＳ１００においてＮＯ）には、次のステップＳ１０２に進む。
【０２３３】
次に、ＣＰＵ２１１は、他機の演出データについて直近の１小節以内に使用可能な拍のデータが有るか否かを判断する（ステップＳ１０２）。なお、本例においては、直近の１小節以内において、現在のフレームの時間にもっとも近い拍のデータから検索するものとする。
【０２３４】
ステップＳ１０２において、ＣＰＵ２１１は、他機の演出データについて直近の１小節以内に使用可能な拍のデータが有ると判断した場合には、当該データを抽出する（ステップＳ１０４）。
【０２３５】
そして、次に、ＣＰＵ２１１は、当該抽出したデータと、現在のフレームの拍のデータとを比較して推定演出データを生成する（ステップＳ１０６）。楽曲データ５６を参照して現在のフレームの拍のデータと抽出したデータとを比較する。そして、比較結果に基づいて推定演出データを生成する。具体的には、一例として、拍のデータとして拍を構成する要素のパターン（要素パターン）と、抽出したデータの要素のパターンとを比較して同じかどうかを判断し、その判断結果に基づいて推定演出データを生成する。当該処理の詳細については後述する（図１７）。
【０２３６】
そして、処理を終了する（リターン）。
一方、ステップＳ１０２において、ＣＰＵ２１１は、他機の演出データについて直近の１小節以内に使用可能な拍のデータが無いと判断した場合には、推定演出データを生成することなく、そのまま処理を終了する（リターン）。この場合には、推定演出データが無いため他パートの演奏音は無し（無音）として処理される。
【０２３７】
なお、本例においては、検索範囲として直近の１小節以内を一例として説明しているが、当該直近の範囲としたのは、直近（直前）の演奏状況に従って演出データを推定することにより、直前の演奏操作の上手下手（巧拙）の度合いがすぐに反映されて他パートの音が生成されるため他パートの演奏操作のリアルタイム感を出すことができる。なお、本例においては、一例として１小節を一例として説明しているが特に当該範囲に限られずさらに複数小節または小節以外の長さの単位を検索範囲とすることも可能である。
【０２３８】
なお、上記においては、他機のパートの現在のフレームが所定部分であるか否かを判断し、所定部分である場合には、推定演出データを生成しない旨説明したが、自機のパートの現在のフレームが所定部分である場合に、推定演出データを生成しないようにすることも可能である。
【０２３９】
＜５．推定演出データの詳細説明＞
＜５．１  合奏ゲームの演奏状況の説明＞
図１５は、複数のゲーム装置によって合奏ゲームを行なう場合の状況を説明する図である。
【０２４０】
図１５を参照して、本例においては、一例として２台のゲーム装置の演奏状況が示されている。ここでは、一例としてプレイヤＰが操作するゲーム装置を基準として、プレイヤＰが操作するゲーム装置から見たプレイヤＱの操作する他のゲーム装置の演奏状況が示されている。当該ゲーム装置がプレイヤＱの操作する他のゲーム装置からのデータを受信する場合について説明する。
【０２４１】
本例において、一例としてゲーム装置の演奏状況が完全に同期しない（ずれが生じている）理由としては、各ゲーム装置の開始タイミングにずれが生じて進行状況に差が生じる場合だけでなく、開始タイミングが同じ場合であっても通信遅延によりずれが生じて進行状況に差が生じる場合または両者が組み合わされて進行状況に差が生じる場合等が挙げられる。
【０２４２】
図１５（Ａ）においては、演奏状況（ゲームの進行状況）に関して、開始タイミングのずれおよび／または通信遅延によりプレイヤＱが操作する他のゲーム装置の方がプレイヤＰが操作するゲーム装置よりも先に進行している場合が示されている。
【０２４３】
当該場合においては、プレイヤＰが操作するゲーム装置は、プレイヤＱが操作する他のゲーム装置から、プレイヤＰが現在演奏しているフレームよりも先（未来の）に利用される演奏データを受信できることになる。
【０２４４】
プレイヤＱが操作するゲーム装置で受信した演奏データは、上述したようにメインメモリ２３に格納される。そして、プレイヤＰが自機で演奏するタイミングにおいて、メインメモリ２３に格納された当該受信した演奏データに含まれる対応するフレームの操作データに基づいて他機の演出データが生成される。そして、他機の演出データに従って他パートの音が出力される。
【０２４５】
したがって、当該演奏状況においては、プレイヤＰが操作するゲーム装置については、プレイヤＱが操作する他のゲーム装置からの演奏データを原則遅延なく受信することが可能である。そのため、プレイヤＰが自機で演奏するタイミングにおいて、対応する他機の演出データが有るため補間処理に基づく推定演出データの生成は行われない。
【０２４６】
図１５（Ｂ）においては、演奏状況（ゲームの進行状況）に関して、開始タイミングのずれおよび／または通信遅延によりプレイヤＱが操作する他のゲーム装置の方がプレイヤＰが操作するゲーム装置よりも遅れて進行している場合が示されている。
【０２４７】
当該場合においては、プレイヤＰが操作するゲーム装置は、プレイヤＱが操作する他のゲーム装置から、プレイヤＰが現在演奏しているフレームよりも前（過去の）に利用される演奏データを受信することになる。
【０２４８】
プレイヤＰが操作するゲーム装置で受信した演奏データは、上述したようにメインメモリ２３に格納される。一方で、プレイヤＰが自機で演奏するタイミングにおいて、メインメモリ２３には、現在の対応するフレームの他機の演奏データは格納されていない。
【０２４９】
したがって、当該演奏状況においては、プレイヤＰが操作するゲーム装置に関して、プレイヤＱが操作する他のゲーム装置から受信される演奏データは、既に演奏が終了したフレームに対応するデータである。そのため、現在の演奏している対応するフレームの他機のパートの音を出力するために（ギャップについて相手の演奏を再現するために）本例においては、補間処理に基づく推定演出データを生成する。そして、推定演出データに基づいて他機のパートの音を出力する。
【０２５０】
なお、同様に、図１５（Ａ）のプレイヤＱが操作する他のゲーム装置は、プレイヤＰが操作するゲーム装置から現在演奏しているフレームよりも前（過去）に利用される演奏データを受信することになる。したがって、同様にプレイヤＱが操作するため他のゲーム装置は、上記の補間処理に基づいて推定演出データを生成して、当該生成した推定演出データに基づいてプレイヤＰが操作するゲーム装置に対応するパートの音を出力する。
【０２５１】
図１５（Ｃ）においては、演奏状況（ゲームの進行状況）に関して、開始タイミングのずれおよび／または通信遅延によりプレイヤＱが操作する他のゲーム装置の方がプレイヤＰが操作するゲーム装置よりも遅れて進行している場合が示されている。さらにプレイヤＰが操作するゲーム装置において、通信環境の変動によりプレイヤＱの他のゲーム装置から送信されたパケットをロストしている場合、すなわち、適切にパケットを取得できなかった場合が示されている。
【０２５２】
当該場合においては、プレイヤＰのゲーム装置は、プレイヤＱの他のゲーム装置から現在演奏しているフレームに利用される演奏データをロストしてしまい、受信することができない。
【０２５３】
そのため、プレイヤＰが操作するゲーム装置においては、当該ロストした演奏データは、メインメモリ２３に格納されていない。すなわち、プレイヤＰが自機で演奏するタイミングにおいて、メインメモリ２３には、現在の対応するフレームの他機の演奏データは格納されていない。
【０２５４】
したがって、当該演奏状況においては、プレイヤＰが操作するゲーム装置については、現在の演奏している対応するフレームに関して、プレイヤＱが操作する他のゲーム装置からの演奏データが無いため、現在の演奏している対応するフレームの他機のパートの音を出力するために（ギャップについて相手の演奏を再現するために）本例においては、補間処理に基づく推定演出データを生成する。そして、推定演出データに基づいて他機のパートの音を出力する。
【０２５５】
なお、ここでは、プレイヤＱが操作する他のゲーム装置の方がプレイヤＰが操作するゲーム装置よりも遅れて進行している場合と、パケットロストがともに生じている場合について説明しているが、プレイヤＱが操作する他のゲーム装置とプレイヤＰが操作するゲーム装置の進行のタイミングが同じである場合に、パケットのロストのみが生じている場合についても同様の補間処理に基づく推定演出データが生成される。そして、推定演出データに基づいて他機のパートの音を出力する。
【０２５６】
＜５．２  補間処理の説明＞
図１６は、本実施の形態に従う補間処理の概念を説明する図である。
【０２５７】
図１６を参照して、ここでは、図１５（Ｂ）の演奏状況の一例が示されている。
具体的には、プレイヤＱが操作する他のゲーム装置の方がプレイヤＰが操作するゲーム装置よりも遅れて進行している場合が示されている。
【０２５８】
また、演奏するパートの音符データ（演奏操作指示データ）が拍毎に区切られている場合が示されている。
【０２５９】
上述したように当該演奏状況においては、プレイヤＰが操作するゲーム装置については、プレイヤＱが操作する他のゲーム装置からの演奏データは、既に演奏が終了したフレームに対応するデータであるため、現在の演奏している対応するフレームの他機のパートの音を出力するために本例においては、補間処理に基づく推定演出データを生成する。
【０２６０】
具体的には、本例における補間処理は、プレイヤＰのゲーム装置について、プレイヤＱのパートの演奏操作指示データと、プレイヤＱが操作する他のゲーム装置から受信した演奏データとを参照して、現在の自機で演奏するタイミングにおいて、１小節以内の直近で使用可能な拍の情報を利用して推定演出データを生成する。
【０２６１】
使用可能な拍の情報とは、他機のパートの拍内に少なくとも１つ以上の音符データが存在し、他機のパートの当該拍の少なくとも最初の音符データに対応するフレームのデータについて受信している場合を意味するものとする。
【０２６２】
本例においては、現在の自機が演奏するタイミングにおいて、他機のパートの拍から２拍戻った位置における拍の情報を利用する場合が示されている。当該拍の情報として、一例として他機のパートの拍内の音符データと、他機のパートの操作データとの比較に基づいて生成される演奏フラグデータを用いる。正しく演奏された場合には、演奏フラグデータはオンであり、正しく操作されない場合には演奏フラグデータはオフとなる。
【０２６３】
なお、使用可能な拍の情報が有るか否かについては、現在の自機が演奏するタイミングにおいて、他機のパートの拍に直近の１つ前の拍から検索し、使用可能な拍か否かを判断する。そして、１つ前の拍の情報が使用可能でなければ、さらに１つ前の拍の情報が使用可能か否かを判断し、１小節の範囲内で当該処理を繰り返す。なお、１小節の範囲内で使用可能な拍の情報が無い場合には推定演出データを生成せずに補間処理を終了する。この場合、つまり上述したように現在フレームから所定フレーム数以内に未処理の他機の演出データが無い場合であって、現在フレームから１小節の範囲内で使用可能な拍の情報が無い場合には、他機のパートについては無音となる。本例においては推定演出データを生成しない場合について説明するが、例えば、全てオフした演奏フラグデータを推定演出データとして生成しても良い。また、１小節に限らず、さらに複数小節に検索範囲を拡げて使用可能な拍を検索するようにしても良い。
【０２６４】
＜５．３  推定演出データの生成の具体例＞
図１７は、本実施の形態に従う推定演出データの生成の具体例について説明する図である。当該処理は、上述した補間処理において実行されるものである。
【０２６５】
図１７（Ａ）を参照して、まず、現在の自機が演奏するタイミングにおいて、他機が演奏するパートの拍と、他機のパートの使用可能な拍との音符データの構成が同じである場合について説明する。
【０２６６】
ここで、本例の補間処理において、現在の自機が演奏するタイミングにおける他機が演奏するパートの拍とは、推定演出データを生成するに際して推定される側の拍（以下、推定被拍ともする）であり、他機のパートの使用可能な拍とは、当該推定被拍に対応する推定演出データを生成する上で比較される推定元となる拍（以下、推定元拍とも称する）である。そして、当該比較される拍（推定元拍）のデータに対応して操作データに基づき生成された演出データが推定演出データを生成する際に利用される。
【０２６７】
本例においては、一例として、拍同士を比較して、推定被拍に対応する推定演出データを生成する。
【０２６８】
具体的には、推定被拍の音符データと推定元拍の音符データとの構成を比較して、比較結果に基づいて推定元拍に対応する演奏フラグデータに従って、推定被拍に対応する推定演出データを生成する。本例においては、推定元拍に対応する一群の演奏フラグデータをを推定利用データとも称する。すなわち、拍単位の演奏フラグデータ群を推定利用データと称する。また、本例においては一例として拍単位の演奏フラグデータ群である推定演出データが生成される。
【０２６９】
推定被拍と、推定元拍とにおける音符データの構成が同じとは、一例として１つの拍内の音符の個数が同じ場合とする。例えば楽曲が四分の四拍子の場合に、一拍子は１個の四分音符である。この場合に楽譜内に十六分音符が含まれる場合、十六分音符が４個連続して配置されて１拍の長さとなる。
【０２７０】
本例においては、推定被拍における音符データの構成の一例として、４個の音符データが配置されており、また、推定元拍における音符データの構成も４個の音符データが配置されているものとする。
【０２７１】
そして、本例においては、推定被拍の音符データの構成と、推定元拍の音符データの構成とが同じであり、１対１に対応付けられるため推定元拍に対応する推定利用データをそのまま推定被拍に対応する推定演出データとして利用する。
【０２７２】
具体的には、推定元拍に対応する演奏フラグデータで構成される推定利用データに従って、推定被拍に対応する推定演出データを生成する。
【０２７３】
ここでは、推定利用データとして、推定元拍に対応して操作データに基づき生成された演奏フラグデータが示されている。
【０２７４】
具体的には、推定利用データとして、推定元拍における４個の音符データの構成のうち１番目と３番目の音符データに対して、演奏フラグデータがオンされ、２番目と４番目の音符データに対して、演奏フラグデータがオフされている場合が示されている。
【０２７５】
すなわち、１番目と３番目の音符データについては、正しく操作されたために演奏フラグデータがオンし、２番目と４番目の音符データについては正しく操作されなかったために演奏フラグデータがオフしている。
【０２７６】
本例においては、音符データの構成が同じであるため推定利用データにおける当該１番目と３番目のオンしている演奏フラグデータに基づいて、推定被拍に対応する推定演出データを生成する。
【０２７７】
具体的には、推定被拍における１番目と３番目の音符データについて演奏フラグデータがオン、２番目と４番目の音符データについて演奏フラグデータがオフの推定演出データが生成される。
【０２７８】
これにより、現在の自機が演奏するタイミングにおいて、当該演奏フラグデータを含む推定演出データに基づいて他機のパートの音が出力される。
【０２７９】
図１７（Ｂ）を参照して、推定被拍と、推定元拍との音符データの構成が異なる場合（その１）について説明する。本例の場合には、推定被拍の音符データの構成が、推定元拍の音符データの構成よりも多い場合について説明する。
【０２８０】
推定被拍の音符データの構成が、推定元拍の音符データの構成よりも多い場合とは、例えば、推定被拍の音符データの構成として４個の音符データが配置されており、推定元拍の音符データの構成として２個の音符データが配置されているような場合である。
【０２８１】
本例においては、推定被拍における音符データの構成と、推定元拍の音符データの構成とが異なり１対１に対応付けられないため、推定利用データのうち対応付けられる演奏フラグデータに従って、推定被拍に対応する推定演出データを生成する。
【０２８２】
ここでは、推定利用データとして、推定元拍に対応して操作データに基づき生成された演奏フラグデータが示されている。
【０２８３】
具体的には、推定利用データとして、推定元拍における２個の音符データの構成のうち１番目の音符データに対して演奏フラグデータがオンされ、２番目の音符データに対して演奏フラグデータがオフされている場合が示されている。
【０２８４】
すなわち、１番目の音符データについては、正しく操作されたために演奏フラグデータはオンであり、２番目の音符データについては、正しく操作されなかったために演奏フラグデータはオフしている。
【０２８５】
そして、本例においては、推定被拍における４個の音符データのうち１番目の音符データについては、推定利用データのうち対応付けられる１番目の音符データの演奏フラグデータがオンであるため、演奏フラグデータをオンにする。
【０２８６】
また、推定被拍における４個の音符データのうち４番目の音符データについては、推定利用データのうち対応付けられる２番目の音符データの演奏フラグデータがオフであるため、演奏フラグデータをオフにする。
【０２８７】
また、推定被拍における４個の音符データのうち２番目および３番目の音符データについては、推定利用データのうち対応付けられる音符データが存在しない（休止位置等）ため、対応付けがなされた次の演奏フラグデータを利用する。
【０２８８】
本例においては、推定利用データのうち２番目の音符データの演奏フラグデータを利用する。当該演奏フラグデータは、オフであるため、推定被拍における４個の音符データのうち２番目および３番目の音符データについても、ともに演奏フラグデータをオフにする。
【０２８９】
これにより、現在の自機が演奏するタイミングにおいて、当該演奏フラグデータを含む推定演出データに基づいて他機のパートの音が出力される。
【０２９０】
図１７（Ｃ）を参照して、推定被拍と、推定元拍との音符データの構成が異なる場合（その３）について説明する。本例の場合には、推定被拍の音符データの構成が、推定元拍の音符データの構成よりも多い場合について説明する。
【０２９１】
本例においては、推定被拍における音符データの構成と、推定元拍の音符データの構成とが異なり１対１に対応付けられないため、推定利用データのうち対応付けられる演奏フラグデータに従って、推定被拍に対応する推定演出データを生成する。
【０２９２】
ここでは、推定利用データとして、推定元拍に対応して操作データに基づき生成された演奏フラグデータが示されている。
【０２９３】
具体的には、推定利用データとして、推定元拍における２個の音符データの構成のうち１番目の音符データに対して演奏フラグデータがオンされ、２番目の音符データに対して演奏フラグデータがオフされている場合が示されている。
【０２９４】
すなわち、１番目の音符データについては、正しく操作されたために演奏フラグデータはオンであり、２番目の音符データについては、正しく操作されなかったために演奏フラグデータはオフしている。
【０２９５】
そして、本例においては、推定被拍における４個の音符データのうち２番目の音符データについては、推定利用データのうち対応付けられる１番目の音符データの演奏フラグデータがオンであるため、演奏フラグデータをオンにする。
【０２９６】
また、推定被拍における４個の音符データのうち４番目の音符データについては、推定利用データのうち対応付けられる２番目の音符データの演奏フラグデータがオフであるため、演奏フラグデータをオフにする。
【０２９７】
また、推定被拍における４個の音符データのうち１番目の音符データについては、推定利用データのうち対応付けられる音符データが存在しないため、対応付けがされた次の演奏フラグデータを利用する。本例においては、推定利用データのうち１番目の音符データの演奏フラグデータを利用する。当該演奏フラグデータは、オンであるため推定被拍における４個の音符データのうち１番目の音符データについて演奏フラグデータをオンにする。
【０２９８】
また、推定被拍における４個の音符データのうち３番目の音符データについては、推定利用データのうち対応付けられる音符データが存在しないため、対応付けがされた次の演奏フラグデータを利用する。本例においては、推定利用データのうち４番目の音符データの演奏フラグデータを利用する。当該演奏フラグデータは、オフであるため推定被拍における４個の音符データのうち４番目の音符データについて演奏フラグデータをオフにする。
【０２９９】
これにより、現在の自機が演奏するタイミングにおいて、当該演奏フラグデータを含む推定演出データに基づいて他機のパートの音が出力される。
【０３００】
図１７（Ｄ）を参照して、推定被拍と、推定元拍との音符データの構成が異なる場合（その４）について説明する。本例の場合には、推定被拍の音符データの構成が、推定元拍の音符データの構成よりも多い場合について説明する。
【０３０１】
本例においては、推定被拍における音符データの構成と、推定元拍の音符データの構成とが異なり１対１に対応付けられないため、推定利用データのうち対応付けられる演奏フラグデータに従って、推定被拍に対応する推定演出データを生成する。
【０３０２】
ここでは、推定利用データとして、推定元拍に対応して操作データに基づき生成された演奏フラグデータが示されている。
【０３０３】
具体的には、推定利用データとして、推定元拍における２個の音符データの構成のうち１番目の音符データに対して演奏フラグデータがオンされ、２番目の音符データに対して演奏フラグデータがオフされている場合が示されている。
【０３０４】
すなわち、１番目の音符データについては、正しく操作されたために演奏フラグデータはオンであり、２番目の音符データについては、正しく操作されなかったために演奏フラグデータはオフしている。
【０３０５】
そして、本例においては、推定被拍における４個の音符データのうち３番目の音符データについては、推定利用データのうち対応付けられる１番目の音符データの演奏フラグデータがオンであるため、演奏フラグデータをオンにする。
【０３０６】
また、推定被拍における４個の音符データのうち４番目の音符データについては、推定利用データのうち対応付けられる２番目の音符データの演奏フラグデータがオフであるため、演奏フラグデータをオフにする。
【０３０７】
また、推定被拍における４個の音符データのうち１番目および２番目の音符データについては、推定利用データのうち対応付けられる音符データが存在しないため、対応付けがされた次の演奏フラグデータを利用する。本例においては、推定利用データのうち１番目の音符データの演奏フラグデータを利用する。当該演奏フラグデータは、オンであるため推定被拍における４個の音符データのうち１番目および２番目の音符データについて演奏フラグデータをともにオンにする。
【０３０８】
これにより、現在の自機が演奏するタイミングにおいて、当該演奏フラグデータを含む推定演出データに基づいて他機のパートの音が出力される。
【０３０９】
図１８は、本実施の形態に従う推定演出データの生成の具体例について説明する別の図である。
【０３１０】
図１８（Ａ）を参照して、推定被拍と、推定元拍との音符データの構成が異なる場合（その５）について説明する。本例の場合には、推定被拍の音符データの構成が、推定元拍の音符データの構成よりも多い場合について説明する。
【０３１１】
上述したように、本例においては、推定被拍における音符データの構成と、推定元拍の音符データの構成とが異なり１対１に対応付けられないため、推定利用データのうち対応付けられる演奏フラグデータに従って、推定被拍に対応する推定演出データを生成する。
【０３１２】
ここでは、推定利用データとして、推定元拍に対応して操作データに基づき生成された演奏フラグデータが示されている。
【０３１３】
具体的には、推定利用データとして、推定元拍における１個の音符データに対して演奏フラグデータがオフされている場合が示されている。
【０３１４】
そして、本例においては、推定被拍における４個の音符データのうち４番目の音符データについては、推定利用データのうち対応付けられる最初の音符データの演奏フラグデータがオフであるため、演奏フラグデータをオフにする。
【０３１５】
また、推定被拍における４個の音符データのうち１〜３番目の音符データについては、推定利用データのうち対応付けられる音符データが存在しないため（出始めから音符データが無い場合）、対応付けがなされた最初の演奏フラグデータを利用する。本例においては、最初の演奏フラグデータがオフであるため、推定被拍における４個の音符データのうち１〜３番目の音符データについても、ともに演奏フラグデータをオフにする。
【０３１６】
これにより、現在の自機が演奏するタイミングにおいて、当該演奏フラグデータを含む推定演出データに基づいて他機のパートの音が出力される。
【０３１７】
図１８（Ｂ）を参照して、推定被拍と、推定元拍との音符データの構成が異なる場合（その６）について説明する。本例の場合には、他機のパートの拍の音符データの構成が、使用可能な拍の音符データの構成よりも少ない場合について説明する。
【０３１８】
推定被拍における音符データの構成が、推定元拍における音符データの構成よりも少ない場合とは、例えば、推定被拍の音符データの構成として２個の音符データが配置されており、推定元拍の音符データの構成として４個の音符データが配置されているような場合である。
【０３１９】
本例においては、推定被拍における音符データの構成と、推定元拍の音符データの構成とが異なるが、推定元拍の音符データの構成が多いため対応付けが可能である。したがって、推定利用データのうち対応付けられる演奏フラグデータに従って、推定被拍に対応する推定演出データを生成する。
【０３２０】
ここでは、推定利用データとして、推定元拍に対応して操作データに基づき生成された演奏フラグデータが示されている。
【０３２１】
具体的には、推定利用データとして、推定元拍における４個の音符データの構成のうち１番目および３番目の音符データに対して演奏フラグデータがオンされ、２番目および４番目の音符データに対して演奏フラグデータがオフされている場合が示されている。
【０３２２】
すなわち、１番目および３番目の音符データについては、正しく操作されたために演奏フラグデータはオンであり、２番目および４番目の音符データについては、正しく操作されなかったために演奏フラグデータはオフしている。
【０３２３】
そして、本例においては、推定被拍における２個の音符データのうち１番目の音符データについては、推定利用データのうち対応づけられる１番目の音符データの演奏フラグデータがオンであるため、演奏フラグデータをオンにする。
【０３２４】
また、推定被拍における２個の音符データのうち２番目の音符データについては、推定利用データのうち対応づけられる４番目の音符データの演奏フラグデータがオフであるため演奏フラグデータをオフにする。
【０３２５】
これにより、現在の自機が演奏するタイミングにおいて、当該演奏フラグデータを含む推定演出データに基づいて他機のパートの音が出力される。
【０３２６】
なお、上記例においては、対応付けられない音符データについては、推定元拍の対応付けがなされた次の演奏フラグデータを利用する場合（出始めから音符データが無い場合には最初の演奏フラグデータを利用する）について説明するが、特にこれに限られず、例えば、対応付けがされた前の演奏フラグデータを利用するようにしても良い。例えば、上記の図１７（Ｂ）においては、推定被拍における４個の音符データのうち２番目および３番目の音符データについては、推定利用データのうち対応付けがなされた次の演奏フラグデータ（２番目の音符データの演奏フラグデータ）を利用する場合について説明したが、前の演奏フラグデータすなわち最初の音符データの演奏フラグデータを利用しても良い。その場合には、図１７（Ｂ）における推定被拍における４個の音符データのうち２番目および３番目の音符データについても１番目の音符データと同様に、演奏フラグデータはオンにされる。あるいは、対応付けられていない音符データについては、ランダムに演奏フラグデータのオン／オフを設定するようにしても良く、その手法には種々の方式があり、１つには限定されない。
【０３２７】
また、演奏フラグデータの対応付けのみならず、正しい操作とのずれ量を考慮して推定演出データを生成するようにしても良い。例えば、正しい操作とのずれ量に従って同じずれ量だけずらした音を推定して他機のパートの音を出力するようにしても良い。
【０３２８】
＜５．４  推定演出データの生成の具体例の詳細説明＞
上記においては、１つの拍内の音符の個数として４個の音符が含まれ得る構成について説明し、一例として当該音符の長さが同じ（音符の種類が同じ）場合に、推定被拍における音符データと、推定元拍における音符データとを対応づけて推定利用データ（演奏フラグデータのオン／オフ）に従って、推定被拍に対応する推定演出データを生成する場合について説明したが、音符の長さが異なる（音符の種類が異なる）場合についても同様に適用可能である。
【０３２９】
具体的には、１つの音符データは、複数フレームで構成されているため１フレーム時間（１／６０秒）ごとに操作の有無を判断して演奏フラグデータのオン／オフを記録することが可能である。
【０３３０】
そして、１つの音符データに対して何フレーム数分演奏したか（演奏フラグデータのオン）をカウントし、長さが異なる別の音符データを構成する（フレーム時間ごとの）複数の演奏フラグデータの一部を、当該カウント結果に対応する分（対応するフレーム時間）だけオン／オフを設定するようにして推定演出データを生成するようにしても良い。
【０３３１】
一方で推定被拍における音符データと、推定元拍における音符データとを比較するに際し、フレーム毎に演奏フラグデータのオン／オフを対応づけて設定することは処理負荷の関係上効率的でない可能性もある。
【０３３２】
本例においては、一拍を所定期間毎に分割（一例として１２分割）して、音符データの種類に応じて所定数の演奏フラグデータを予め対応付けて処理する方式について説明する。
【０３３３】
図１９は、本実施の形態に従う音符データの種類に応じた演奏フラグデータについて説明する図である。
【０３３４】
図１９（Ａ）を参照して、本例においては、一拍を１２個の区間に分割した場合が示されている。
【０３３５】
十六分音符は、四分音符の１／４の長さに相当する。したがって、当該分割方式に従えば、十六分音符は、３個の演奏フラグデータ分の期間に相当する。
【０３３６】
図示していないが、同様の方式に従って、８分音符は、６個の演奏フラグデータ分の期間に相当する。
【０３３７】
通常の音符データと異なる音符データについても同様に処理することが可能である。
図１９（Ｂ）を参照して、ここでは三連符について説明する。３連符は、一拍の１／３の長さの期間に相当する。したがって、当該分割方式に従えば、三連符は、４個の演奏フラグデータ分の期間に相当する。
【０３３８】
図１９（Ｃ）を参照して、ここでは二拍三連符について説明する。二拍三連符は、二拍の１／３の長さ、一拍の２／３の長さの期間に相当する。したがって、当該分割方式に従えば二拍三連符は、８個の演奏フラグデータ分の期間に相当する。
【０３３９】
当該方式で各音符データの種類に応じて演奏フラグデータを処理することが可能であるため、楽譜で一般的に用いられる四分音符や八分音符以外の特殊な長さの音符データを同じ形式に統一して楽曲データに含めて演奏処理することが可能である。
【０３４０】
当該処理により、例えば、上記の本実施の形態に従う推定演出データの生成においては、現在の自機が演奏するタイミングにおける他機のパートの拍（推定被拍）の音符データに従う最大１２個の演奏フラグデータと、他機のパートの使用可能な拍（推定元拍）の音符データに従う最大１２個の演奏フラグデータとを比較して、上記の図１７および図１８で説明した処理と同様の処理を実行するようにすれば良い。
【０３４１】
当該処理により、推定被拍と推定元拍とに含まれる音符データの長さが異なる場合であっても、容易に演奏フラグデータを対応づけることが可能であり、演奏フラグデータのオン／オフを設定して効率的に推定演出データを生成することが可能である。
【０３４２】
なお、本例においては、一例として拍の演奏フラグデータ同士の対応付けに基づいて推定演出データを生成する場合について説明したが、特に当該方式に限られず、例えば、音符の種別に従って推定演出データを生成するようにしても良い。
【０３４３】
例えば、現在の自機が演奏するタイミングにおいて、他機のパートの拍の音符の種類が四分音符で、使用可能な拍の音符の種類が十六分音符であるような場合、当該十六分音符に対する操作データに基づく演奏フラグデータに従って、他機のパートの拍（四分音符）における推定演出データを生成するようにしても良い。具体的には、十六分音符に対する操作データに基づく演奏フラグデータのオンの個数に従って他機のパートの拍（四分音符）における推定演出データを生成することが可能である。あるいは、十六分音符に対する操作データに基づく演奏フラグデータが全てオンであれば、当該四分音符に対する演奏フラグデータも全てオンとなるように拡張して他機のパートの拍の推定演出データを生成するようにしても良い。また、現在の自機が演奏するタイミングにおいて、他機のパートの拍の音符の種類が１６分音符で拍内に４個設けられ、使用可能な拍の音符の種類が四分音符で１個設けられているような場合、当該四分音符に対する操作データに基づく演奏フラグデータに従って、他機のパートの拍（十六分音符）における推定演出データを生成するようにしても良い。具体的には、１個の四分音符に対する操作データに基づく演奏フラグデータのオンに従って他機のパートの拍（十六分音符）における４個の十六分音符のうちの１個の十六分音符について演奏フラグデータをオンにする推定演出データを生成することが可能である。すなわち、拍の音符の長さまたは個数への操作データに基づく演奏フラグデータに従って他機のパートの拍の推定演出データを生成するようにしても良い。
【０３４４】
図２０は、ゲーム中の演奏の操作期間と演奏フラグデータとの関係を説明する図である。
【０３４５】
図２０を参照して、演奏フラグデータは、本例においては、上記したように一拍を１２分割した形式で管理される場合について説明する。
【０３４６】
一例として、本例においては、４個分の演奏フラグデータに相当する期間に対するゲーム中の演奏の操作期間が示されている。具体的には、最初の１つ目の演奏フラグデータに相当する期間の途中から４つ目の演奏フラグデータに相当する期間の途中まで操作スイッチ１４（演奏ボタン）を介して操作された場合が示されている。
【０３４７】
この場合、当該操作期間は、フレーム時間（１／６０秒）毎に操作データを取得することにより操作データの有無（操作期間）を判断することが可能である。
【０３４８】
そして、当該演奏フラグデータに対して操作されたか否かの判断（演出データの生成）については、ある演奏フラグデータに相当する期間と次の演奏フラグデータに相当する期間との切り替わりの時点において操作されていたか否か（操作データが有るか否か）で判断することが可能である。すなわち、ある演奏フラグデータに相当する期間を構成する複数フレームのうち最後のフレームに対して操作データが有るか否かで判断することが可能である。
【０３４９】
本例の場合には、上記の操作期間に従って、当該１つ目の演奏フラグデータに相当する期間の最後のフレームに対して操作データが有ると判断し、１つ目の演奏フラグデータはオンする。同様に、２つ目の演奏フラグデータに相当する期間の最後のフレームに対して操作データが有ると判断し、２つ目の演奏フラグデータはオンする。同様に、３つ目の演奏フラグデータに相当する期間の最後のフレームに対して操作データが有ると判断し、４つ目の演奏フラグデータはオンする。４つ目の演奏フラグデータについては、当該演奏フラグデータに相当する期間の最後のフレームに対して演奏データは無しと判断し、４つ目の演奏フラグデータはオフする。
【０３５０】
当該処理により、演出データの生成に関して、演奏フラグデータに相当する期間の操作データを常時監視する必要はなく、演奏フラグデータに相当する期間の最後のフレームに対して操作データの有無を判定すれば良い、すなわち所定期間（演奏フラグデータに相当する期間）毎に判定すれば良いため処理負荷を軽減することが可能である。
【０３５１】
なお、当該操作データの判断は一例であり、別の判断手法を用いることも当然に可能である。例えば、当該演奏フラグデータに相当する期間内に一部でも操作されている期間があれば演奏フラグデータをオンとして判断するようにしても良い。あるいは、反対に、当該演奏フラグデータに相当する期間内に一部しか操作されていなければ一律に演奏フラグデータをオフと判断するようにしてもよい。あるいは、演奏フラグデータに相当する期間をさらに細かく時分割して、時分割された期間の操作された期間の割合で判断するようにしても良い。
【０３５２】
＜６．具体例＞
図２１は、本実施の形態に従う補間処理に基づく他パートの音を出力する具体例を説明する図である。
【０３５３】
図２１（Ａ）を参照して、ここでは、現在の自機が演奏するタイミングにおいて、他機のパートの拍（推定被拍）の音符データは、一例として四分音符である場合が示されている。
【０３５４】
この場合、一拍を１２分割した場合には、四分音符は、１２個分の演奏フラグデータの期間に相当する。
【０３５５】
図２１（Ｂ）を参照して、本例において他機のパートの使用可能な拍（推定元拍）の演出データが示されている。
【０３５６】
具体的には、推定元拍の音符データの構成に対する操作データに基づいて生成された演出データ（推定利用データ）が示されている。
【０３５７】
本例においては、１拍が１２分割されている場合に、当該演出データ（推定利用データ）として、演奏フラグデータがオンの部分と、演奏フラグデータがオフの部分と、演奏フラグデータが無い部分すなわち音符データが存在しなかった部分（休止位置等）の情報が示されている。
【０３５８】
図２１（Ｃ）を参照して、推定演出データの生成について説明する。
図１７および図１８を参照して、本例においては、推定被拍における音符データの構成と、推定元拍の音符データの構成とが異なり１対１に対応付けられないため、推定利用データのうち対応付けられる演奏フラグデータに従って、推定被拍に対応する推定演出データを生成する。
【０３５９】
ここでは、推定利用データとして、推定元拍に対応して操作データに基づき生成された演奏フラグデータが示されている。
【０３６０】
具体的には、推定利用データとして、推定元拍における１〜３個目の演奏フラグデータがオンされ、４〜６個目には演奏フラグデータが無く、７〜１０個目の演奏フラグデータがオフされ、１１、１２個目の演奏フラグデータがオンされている場合が示されている。
【０３６１】
そして、本例においては、推定被拍における１２個の演奏フラグデータのうち、１〜３番目の演奏フラグデータについては、推定利用データとの対応付けに従って演奏フラグデータをオンにする。
【０３６２】
また、推定被拍における１２個の演奏フラグデータのうち、７〜１０番目の演奏フラグデータについては、推定利用データとの対応付けに従って演奏フラグデータをオフにする。
【０３６３】
また、推定被拍における１２個の演奏フラグデータのうち、１１，１２番目の演奏フラグデータについては、推定利用データとの対応付けに従って演奏フラグデータをオンにする。
【０３６４】
一方、推定被拍における１２個の演奏フラグデータのうち４番目〜６番目については、推定利用データが無いため対応づけられない。
【０３６５】
この場合、上記したように対応付けがされた次の演奏フラグデータを利用する。本例においては、推定被拍における７番目の演奏フラグデータにおいて推定利用データとの対応付けがされている。
【０３６６】
したがって、当該演奏フラグデータを利用して推定被拍における１２個の演奏フラグデータのうち４番目〜６番目については、７番目の演奏フラグデータを利用して演奏フラグデータをオフにする。
【０３６７】
図２１（Ｄ）を参照して、他機のパートの音符データおよび上記で生成された他機の推定演出データに基づいて現在の自機が演奏するタイミングにおいて、他機のパートの音が出力される。具体的には、他機のパートの四分音符の音符データに関して、１拍を１２分割した場合における３個の演奏フラグデータの期間（期間Ｉ）については音が出力され、次の６個の演奏フラグデータの期間（期間ＩＩおよび期間ＩＩＩ）については音が出力されず、最後の３個の演奏フラグデータの期間（期間ＩＶ）については音が出力される。
【０３６８】
以上に示したように、本実施形態では、ゲーム装置１０は、演奏期間中において、メインメモリ２３に記憶されている他機演奏データ５３を用いて演奏楽曲の各演奏部分について他パートの音を生成することが可能か否かを判定する。具体的には、自機が演奏するタイミングにおいて他機の対応するフレームにおける演出データが有るか否かを判定する。
【０３６９】
そして、他機の対応するフレームにおける演出データが無いと判定した場合、すなわち他パートの演奏音の生成が不可能である演奏部分については、取得している他のゲーム装置の演奏データに基づいて演出データを推定する推定演出データを生成して、それに基づいて他パートの演奏音を出力する。
【０３７０】
これによって、他パートの音が自機パートの音より遅れて出力されることなく、通信よる遅延等の影響による不快感を抑制し、合奏ゲームを楽しむことができる。さらに、直前に演奏された演奏状況が反映されて演奏が推定されるため他パートの演奏操作のリアルタイム感を出すことができ、リアルタイムな演奏環境で自機を操作することが可能となる。
【０３７１】
＜その他の実施形態＞
また、上記実施形態においては、演奏を行うための演奏操作は、適宜のタイミングで適宜の演奏ボタンを押下する操作であったが、演奏操作の形態はどのようなものであってもよい。例えば、ゲーム装置１０のタッチパネル１５入力装置として用いる場合には、ギターやピアノの画像を下側ＬＣＤ１２に表示させ、下側ＬＣＤ１２の画面上にタッチ入力を行う操作を演奏操作として用いることができる。具体的には、ギターの弦の画像を表示する場合には、ゲーム装置１０は、タッチパネル１５に対する入力に基づいて、弦を弾く方向および強さを算出し、当該方向および強さに基づいてギターの音を出力するようにしてもよい。さらに、このとき、上記方向および強さを示すデータを演奏データ（データ）として用いることができる。
【０３７２】
また、上記実施形態においては、複数人のプレイヤで合奏を行う合奏ゲームを例として説明したが、本発明は、複数のゲーム装置を用いて行われる複数人参加型のゲームに適用することが可能である。本ゲームシステムにおいて実行されるゲームは、例えば、演奏ボタンを適宜のタイミングで押下することによって、表示装置の画面に表示されるキャラクタに楽曲に合わせてダンスを踊らせるゲームであってもよい。なお、入力操作として、演奏ボタンの入力に限られず、加速度センサ等のモーションセンサを利用してプレイヤの動作を検知して、プレイヤの動作に従う検知信号を入力としてキャラクタに楽曲に合わせてダンスを踊らせるようにしてもよい。このゲームでは、各ゲーム装置によってそれぞれ操作される複数のキャラクタが登場する。各ゲーム装置には、プレイヤによる操作に応じて行われる当該複数のキャラクタの動作（ダンス）が表示される。
【０３７３】
このようなゲームを実行するためのゲームシステムにおいては、上記合奏ゲームと同様、各ゲーム装置は、楽曲に合わせてキャラクタをダンスさせる操作を受け付ける。
【０３７４】
ゲーム装置は、上記演奏データに代えて、自機の操作対象（キャラクタ）の動作内容を特定するための動作データを他のゲーム装置へ送信する。動作データは、例えば、プレイヤによる操作を示す操作データである。
【０３７５】
ゲーム装置は、他のゲーム装置から受信される動作データに基づいて、他の操作対象の動作を制御しつつ、プレイヤによる操作に応じて自機の操作対象の動作を制御する。そして、複数の操作対象の動作を画面に表示する。
【０３７６】
以上に説明したようなダンスゲームにおいても本発明を適用することが可能である。
具体的には、当該ダンスゲームにおいて、例えば通信による遅延等により他のゲーム装置から他機の操作対象（キャラクタ）の動作データが受信されていない場合には、以前に操作された操作状況に基づいて動作データを推定して、当該推定された動作データに基づいて他機の操作対象（キャラクタ）の動作を制御して画面に表示するようにしても良い。
【０３７７】
さらに、本発明は、通信による複数人対戦型の他のゲームにも同様に適用することが可能である。
【０３７８】
今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【符号の説明】
【０３７９】
１  サーバ、２  ネットワーク、１０，１０ａ，１０ｂ  ゲーム装置、１３ａ  上側ハウジング、１３ｂ  下側ハウジング、１４  操作スイッチ、１４ａ  十字キー、１４ｂ  スタートスイッチ、１４ｃ  調整スイッチ、１４ｈ  スライドパッド、１５  タッチパネル、１６  スティック、１７  メモリカード、１７ａ  ＲＯＭ、１８  スピーカ、１８ａ，１８ｂ  音抜き孔、１９  撮像部、２１  情報処理部、２２  Ｉ／Ｆ回路、２３  メインメモリ、３４  外部メモリＩ／Ｆ、３５，３６  挿入口、３７  無線通信モジュール、４１  ゲージ、４２  カーソル、４３，４４  操作指示画像、４５  操作期間画像、５０  合奏ゲームプログラム、５１  ゲーム処理用データ、５２  自機演奏データ、５３  他機演奏データ、５６  楽曲データ、５７  パートデータ、５８  グループデータ、５９  演奏楽曲指定データ、２１１  ＣＰＵ、２１２  ＧＰＵ、２１３  ＶＲＡＭ。
【図１】
2014150938.tif 000003
【図２】
2014150938.tif 000004
【図３】
2014150938.tif 000005
【図４】
2014150938.tif 000006
【図５】
2014150938.tif 000007
【図６】
2014150938.tif 000008
【図７】
2014150938.tif 000009
【図８】
2014150938.tif 000010
【図９】
2014150938.tif 000011
【図１０】
2014150938.tif 000012
【図１１】
2014150938.tif 000013
【図１２】
2014150938.tif 000014
【図１３】
2014150938.tif 000015
【図１４】
2014150938.tif 000016
【図１５】
2014150938.tif 000017
【図１６】
2014150938.tif 000018
【図１７】
2014150938.tif 000019
【図１８】
2014150938.tif 000020
【図１９】
2014150938.tif 000021
【図２０】
2014150938.tif 000022
【図２１】
2014150938.tif 000023