WO2022137958A1

WO2022137958A1 - ゲームシステム、それに用いるコンピュータプログラム、及び制御方法

Info

Publication number: WO2022137958A1
Application number: PCT/JP2021/043007
Authority: WO
Inventors: 祐佐原; 泰地宮▲崎▼
Original assignee: 株式会社コナミデジタルエンタテインメント
Priority date: 2020-12-25
Filing date: 2021-11-24
Publication date: 2022-06-30
Also published as: KR20230104959A; CN116635119A; JP2022102913A

Abstract

パフォーマンスの開始前に、複数人によるパフォーマンスにおいて実行される呼吸を合わせるプロセスと同様のプロセスをゲームの複数のキャラクタに実行させることができるゲームシステムを提供する。ＨＭＤ型のゲーム機（４）は、ユーザによって操作されるユーザキャラクタ（５４Ｃ）を含む複数のキャラクタ（５４）が演奏動作を実行する演奏パフォーマンスを含む音楽ゲームを提供する。また、ＨＭＤ型のゲーム機（４）は、ユーザキャラクタ（５４Ｃ）が実行した連携アクションに応答する応答アクションを、他のキャラクタ（５４Ｂ）が実行した場合にユーザキャラクタ（５４Ｃ）と他のキャラクタ（５４Ｂ）との間に形成される連携状態の形成を要件に含む開始条件が満たされるか否か判別し、開始条件が満たされた場合にその開始条件の具備を契機に演奏パフォーマンスを開始させる一方で、開始条件が満たされるまで演奏パフォーマンスの開始を待機させる。

Description

ゲームシステム、それに用いるコンピュータプログラム、及び制御方法

　本発明は、ユーザのプレイ行為を入力するための入力装置、及びユーザのプレイ行為を通じて操作されるキャラクタとしてのユーザキャラクタを含む複数のキャラクタが含まれるようにゲーム画面を表示する表示装置に接続され、その複数のキャラクタが実行するパフォーマンスを含むゲームを提供するゲームシステム等に関する。

　ユーザのプレイ行為を入力するための入力装置、及びユーザのプレイ行為を通じて操作されるキャラクタとしてのユーザキャラクタを含む複数のキャラクタが含まれるようにゲーム画面を表示する表示装置に接続され、その複数のキャラクタが実行するパフォーマンスを含むゲームを提供するゲームシステムが存在する。このようなゲームとして、バンドのボーカルになりきってボーカル演奏を行う音楽ゲームを提供するゲームシステムが知られている（例えば特許文献１参照）。

特許第６７２７８０７号公報

　複数人による現実のパフォーマンスでは、アイコンタクト等を通じてそれらの複数人の間で呼吸を合わせてパフォーマンスが開始される場合も多い。このため、このような呼吸を合わせるプロセスには臨場感、或いは一体感を向上させる効果が期待される。一方、特許文献１の音楽ゲームでは、自分の歌とバンドメンバーの演奏とによるライブパフォーマンスが実現される。この音楽ゲームでは、プレーヤの開始アクション（ハンドアクション）の入力で演奏がスタートし、ライブシーケンスに移行する。つまり、この音楽ゲームでは、プレーヤのハンドアクションによりライブパフォーマンスが開始される。しかし、これは演奏再生ボタンを押す代わりとして開始アクションが利用されているに過ぎず、複数のキャラクタ間において呼吸を合わせるといった類いのプロセスではない。このため、ゲーム内のパフォーマンスに対する臨場感等を向上させる余地がある。

　そこで、本発明は、パフォーマンスの開始前に、複数人によるパフォーマンスにおいて実行される呼吸を合わせるプロセスと同様のプロセスをゲームの複数のキャラクタに実行させることができるゲームシステム等を提供することを目的とする。

　本発明のゲームシステムは、ユーザのプレイ行為を入力するための入力装置、及び前記ユーザのプレイ行為を通じて操作されるキャラクタとしてのユーザキャラクタを含む複数のキャラクタが含まれるようにゲーム画面を表示する表示装置に接続され、前記複数のキャラクタが実行するパフォーマンスを含むゲームを提供するゲームシステムであって、前記複数のキャラクタのうちの少なくとも一つのキャラクタが実行したアクションに対応する所定のアクションとしての対応アクションを他のキャラクタが実行した場合に前記一つのキャラクタと前記他のキャラクタとの間に少なくとも形成される連携状態の形成を要件に含む開始条件が満たされるか否か判別する条件判別手段と、前記開始条件が満たされた場合に当該開始条件の具備を契機に前記パフォーマンスが開始される一方で、前記開始条件が満たされるまで前記パフォーマンスの開始が待機されるように前記ゲームの進行を制御する進行制御手段と、を備えるものである。

　一方、本発明のコンピュータプログラムは、前記入力装置、及び前記表示装置に接続されるコンピュータを、上述のゲームシステムの各手段として機能させるように構成されたものである。

　また、本発明の制御方法は、ユーザのプレイ行為を入力するための入力装置、及び前記ユーザのプレイ行為を通じて操作されるキャラクタとしてのユーザキャラクタを含む複数のキャラクタが含まれるようにゲーム画面を表示する表示装置に接続され、前記複数のキャラクタが実行するパフォーマンスを含むゲームを提供するゲームシステムに組み込まれるコンピュータに、前記複数のキャラクタのうちの少なくとも一つのキャラクタが実行したアクションに対応する所定のアクションとしての対応アクションを他のキャラクタが実行した場合に前記一つのキャラクタと前記他のキャラクタとの間に少なくとも形成される連携状態の形成を要件に含む開始条件が満たされるか否か判別する条件判別手順と、前記開始条件が満たされた場合に当該開始条件の具備を契機に前記パフォーマンスが開始される一方で、前記開始条件が満たされるまで前記パフォーマンスの開始が待機されるように前記ゲームの進行を制御する進行制御手順と、を実行させるものである。

本発明の一形態に係るゲームシステムの概略構成を示す図。ゲームシステムの制御系の要部を示す機能ブロック図。ゲーム画面の一例を模式的に示す図。仮想三次元空間における各キャラクタの位置関係を説明するための説明図。視界範囲が図４の例の右傾斜範囲に移動した場合のゲーム画面の一例を模式的に示す図。演奏パフォーマンスの開始までの流れの一例を説明するための説明図。ゲーム画面に設定される視野範囲を説明するための説明図。応答アクションの一例を説明するための説明図。他のキャラクタ画像の動作の変化の流れを説明するための説明図。演奏データの構成の一例を示す図。演奏選択処理の手順の一例を示すフローチャート。連携応答処理の手順の一例を示すフローチャート。楽曲開始処理の手順の一例を示すフローチャート。演奏データ生成処理の手順の一例を示すフローチャート。

　以下、本発明の一形態に係るゲームシステムの一例を説明する。まず、図１を参照して、本発明の一形態に係るゲームシステムの全体構成を説明する。ゲームシステム１は、サーバ装置としてのセンターサーバ２を含んでいる。なお、センターサーバ２は、複数のコンピュータ装置としてのサーバユニットが組み合わされることにより一台の論理的なサーバ装置として構成されてもよい。あるいは、クラウドコンピューティングを利用して論理的にセンターサーバ２が構成されてもよい。

　センターサーバ２には、ネットワーク３を介して接続可能なクライアント装置として一台、或いは複数台の適宜の数のゲーム装置が接続される。ゲーム装置は、アーケードゲーム機（アミューズメント店舗等の施設に設置され、所定の対価の支払いと引き換えにそのプレイ料金に対応した範囲でユーザにゲームをプレイさせる業務用ゲーム機）等の各種のゲーム機を適宜に含んでいてよいが、図１の例ではユーザ端末装置４が示されている。具体的には、センターサーバ２には、ゲーム装置の一例として、ネットワーク３を介して複数のユーザ端末装置４が接続されている。

　ユーザ端末装置４は、ネットワーク接続が可能でかつユーザの個人用途に供されるコンピュータ装置である。ユーザ端末装置４は、各種のコンピュータソフトウエアを実装することにより、センターサーバ２が提供する種々のサービスをユーザに享受させることが可能である。このようなコンピュータソフトウエア（アプリケーション）には、有償或いは無償のゲームを提供するためのゲーム用のアプリケーションが含まれる。そして、ユーザ端末装置４は、そのようなゲーム用のアプリケーションの実行を通じて、ゲーム機として機能する。このようなユーザ端末装置４は、例えば、据置型又はブック型のパーソナルコンピュータ、据置型の家庭用ゲーム機、或いは携帯型タブレット端末装置や携帯電話（スマートフォンを含む。）等の各種モバイル端末装置を含んでいる。ユーザ端末装置４として、これらが適宜に利用されてよいが、図１の例ではＨＭＤ（ヘッドマウントディスプレイ、或いはヘッドマウントデバイス）型のゲーム機が利用されている。

　ＨＭＤ型のゲーム機は、ユーザの視界の大部分をディスプレイの表示面が占めるように頭部に装着されて使用される周知のゲーム装置である。ＨＭＤ型のゲーム機には、例えばＨＭＤ型の専用のゲーム装置、携帯電話等の適宜のモバイル端末装置とユーザの視界を表示面に向けるようにそれを収容するケースとの組合せにより構成されるゲーム装置、及び眼球の奥に焦点が合うように映像を投影するメガネ型のプロジェクタ（いわゆるスマートグラス）が含まれる。また、ＨＭＤ型の専用のゲーム装置には、タブレット端末装置、或いはスマートフォン等に接続され、それらのタブレット端末装置のアプリケーションを通じてゲーム機として機能する連動型のゲーム装置も含まれる。これらの各種のＨＭＤ型のゲーム機のいずれがユーザ端末装置４として利用されてもよい。以下、ユーザ端末装置４として機能するＨＭＤ型のゲーム機にはユーザ端末装置４と同様の符号を付して、ＨＭＤ型のゲーム機４と呼ぶ場合がある。

　ＨＭＤ型のゲーム機４には、ユーザのプレイ行為を入力するための各種の入力装置が適宜に設けられる。例えば、ＨＭＤ型のゲーム機４には、頭部の動作をプレイ行為として検知するセンサが内蔵され、そのセンサが入力装置として機能してもよい。あるいは、ＨＭＤ型のゲーム機４とは別の装置が適宜の手法でＨＭＤ型のゲーム機４に接続され、その別の装置が入力装置として機能してもよい。このようにＨＭＤ型のゲーム機４には、各種の入力装置が適宜に設けられてよいが、このような入力装置として図１の例では操作スティックＯＳが設けられている。操作スティックＯＳは、所定の無線通信規格を通じてＨＭＤ型のゲーム機４に接続される周知の入力装置である。操作スティックＯＳは各種の操作（プレイ行為）の入力に使用されてよく、それに応じて適宜の数の操作スティックＯＳが各ＨＭＤ型のゲーム機４に接続されてよいが、一例として左右の手でそれぞれ操作されるように各ＨＭＤ型のゲーム機４には二つの操作スティックＯＳ（図１ではそれらのうちの一つのみが示されている）がそれぞれ接続される。ＨＭＤ型のゲーム機４は、このような操作スティックＯＳを介して入力されるプレイ行為を通じて進行するゲームを提供する。

　ＨＭＤ型のゲーム機４は、各種のゲームを適宜に提供してよく、例えばアクションゲーム、シミュレーションゲーム、ロールプレイングゲーム等を提供してよいが、一例として音楽ゲームを提供する。音楽ゲームは、タイミングゲームの一種である。タイミングゲームは、適切なプレイ行為の実行時期を評価するタイプのゲームである。音楽ゲームの場合、その適切なプレイ行為を実行すべき実行時期が楽曲とともに提供される。また、音楽ゲームでは、楽曲のリズムと一致する時期が実行時期として利用される。つまり、音楽ゲームは、適切なプレイ行為を実行すべき時期を楽曲のリズムに合わせてユーザに案内し、実際にプレイ行為が実行された時期を評価するタイプのゲームである。また、例えば、音楽ゲームにはプレイ用に複数の楽曲が用意され、そこから選択された楽曲が実際のプレイに使用される。そのような音楽ゲームは、各種の出力装置を介して適宜に提供されてよいが、一例としてディスプレイに表示されるゲーム画面を通じて提供される。

　また、ＨＭＤ型のゲーム機４が提供するゲームは、複数のキャラクタ（車或いは動物等の各種の物を含む）、及びこれらの複数のキャラクタが実行するパフォーマンスを含んでいる。複数のキャラクタは、アクションゲーム等の種類に応じて各種のパフォーマンスを適宜に実行してよいが、音楽ゲームの場合、一例として楽器を演奏するパフォーマンス（以下、演奏パフォーマンス）を実行する。このため、ゲーム画面は、このような演奏パフォーマンスを実行する複数のキャラクタを含む場合がある。このようなゲーム画面の詳細は後述する。

　ネットワーク３は、センターサーバ２に対してＨＭＤ型のゲーム機４を接続させることができる限り、適宜に構成されてよい。一例として、ネットワーク３は、ＴＣＰ／ＩＰプロトコルを利用してネットワーク通信を実現するように構成される。典型的には、ＷＡＮとしてのインターネットと、ＬＡＮとしてのイントラネットと、を組み合わせてネットワーク３が構成される。図１の例では、センターサーバ２はルータ３ａを介して、ＨＭＤ型のゲーム機はアクセスポイント３ｂを介して、それぞれネットワーク３に接続されている。なお、ネットワーク３は、ＴＣＰ／ＩＰプロトコルを利用する形態に限定されない。ネットワーク３として、通信用の有線回線、或いは無線回線（赤外線通信、近距離無線通信等を含む）等を利用する各種の形態が利用されてよい。

　センターサーバ２は、ネットワーク３を介してＨＭＤ型のゲーム機４のユーザに各種のＷｅｂサービスを提供する。Ｗｅｂサービスは、各ＨＭＤ型のゲーム機４に各種データ或いはソフトウエアを配信（データ等のアップデートを含む）する配信サービスを含んでいる。なお、Ｗｅｂサービスは、音楽ゲームが対戦型、或いは協力型のゲームとしてプレイされる場合においてネットワーク３を介して他のＨＭＤ型のゲーム機４のユーザ（対戦者、或いは協力者）をマッチングするマッチングサービス、及び各ユーザを識別するためのユーザＩＤを付与するサービス等の各種のサービスを適宜に含んでいてよい。

　次に、図２を参照してゲームシステム１の制御系の要部を説明する。まず、センターサーバ２には、制御ユニット２１、及び記憶手段としての記憶部２２が設けられる。制御ユニット２１は、所定のコンピュータプログラムに従って各種の演算処理及び動作制御を実行するプロセッサの一例としてのＣＰＵと、その動作に必要な内部メモリその他の周辺装置とを組み合わせたコンピュータとして構成されている。

　記憶部２２は、ハードディスクアレイ等の不揮発性記憶媒体（コンピュータ読み取り可能な記憶媒体）を含んだ記憶ユニットによって実現される外部記憶装置である。記憶部２２は、一の記憶ユニット上に全てのデータを保持するように構成されてもよいし、複数の記憶ユニットにデータを分散して記憶するように構成されてもよい。記憶部２２には、ユーザに各種のサービスを提供するために必要な各種の処理を制御ユニット２１に実行させるコンピュータプログラムの一例として、プログラムＰＧ１が記録される。また、記憶部２２には、各種のサービスの提供に必要なサーバ用データが記憶される。そのようなサーバ用データは、サービス用の各種のデータを含んでいるが、図２の例ではそのような各種のデータの一種として、楽曲データＭＤ、シーケンスデータＱＤ、プレイデータＰＤ、及び演奏データＯＤが示されている。

　楽曲データＭＤは、各楽曲を再生するためのデータである。楽曲データＭＤは、例えば音楽ゲームにおいて各楽曲の再生に使用される。シーケンスデータＱＤは、音楽ゲームにおいて適切なプレイ行為を実行すべき各実行時期が記述されたデータである。シーケンスデータＱＤは、このような各実行時期をユーザに案内するために使用される。また、ユーザによって実際にプレイ行為が実行された場合には、シーケンスデータＱＤの実行時期に基づいてそのプレイ行為が評価される。つまり、シーケンスデータＱＤは各実行時期の案内及びその評価に使用される。このため、シーケンスデータＱＤには、各実行時期、及びその実行時期に実行されるべき適切なプレイ行為の情報が互いに関連付けられるように記述される。また、音楽ゲームにおいて、複数の楽曲或いは複数の難易度が用意される場合には、シーケンスデータＱＤは楽曲毎或いは難易度毎に用意される。さらに、音楽ゲームは複数のキャラクタをプレイ対象に含むときには、選択されるキャラクタ（あるいは後述のようにキャラクタ毎に相違する楽器）に応じて各実行時期や適切なプレイ行為が相違する場合もある。このような場合、シーケンスデータＱＤはそのようなキャラクタ（あるいは楽器）毎にも用意される。プレイデータＰＤは、各ユーザの過去のプレイ実績に関する情報が記述されたデータである。プレイデータＰＤは、前回までのプレイ結果（過去の実績）を次回以降に引き継ぐため、或いは各ユーザに固有の設定内容を引き継ぐために使用される。演奏データＯＤは、演奏パフォーマンスを実現するためのデータである。演奏データＯＤの詳細は後述する。

　なお、サーバ用データは、その他にも各種のサービスを実現するための各種のデータを含んでよい。例えば、そのようなデータには、画像データ、或いはＩＤ管理データ等が含まれてよい。画像データはゲーム画面等の各種画像を表示装置に表示させるためのデータである。ＩＤ管理データは、ユーザＩＤ等の各種ＩＤを管理するためのデータである。しかし、それらの図示は省略した。

　制御ユニット２１には、制御ユニット２１のハードウエア資源とソフトウエア資源としてのプログラムＰＧ１との組合せによって実現される論理的装置として、Ｗｅｂサービス管理部２４が設けられる。Ｗｅｂサービス管理部２４は、ＨＭＤ型のゲーム機４に対して上述のＷｅｂサービスを提供するための各種処理を実行する。

　一方、ＨＭＤ型のゲーム機４には、制御ユニット４１と、記憶手段としての記憶部４２とが設けられる。所定のコンピュータプログラムに従って各種の演算処理及び動作制御を実行するプロセッサの一例としてのＣＰＵと、その動作に必要な内部メモリその他の周辺装置とを組み合わせたコンピュータとして構成されている。

　記憶部４２は、ハードディスク、半導体記憶装置といった不揮発性記憶媒体（コンピュータ読み取り可能な記憶媒体）を含んだ記憶ユニットによって実現される外部記憶装置である。記憶部４２には、ユーザに各種のサービスを提供するために必要な各種の処理を制御ユニット４１に実行させるコンピュータプログラムの一例として、プログラムＰＧ２が記録される。また、記憶部４２には、音楽ゲームの提供に必要なゲームデータが記録される。そのようなゲームデータには、音楽ゲーム用の各種のデータが含まれるが、図２の例ではその一例として楽曲データＭＤ、シーケンスデータＱＤ、プレイデータＰＤ、及び演奏データＯＤが示されている。

　楽曲データＭＤ、シーケンスデータＱＤ、プレイデータＰＤ、及び演奏データＯＤは、初期インストール、各種記憶媒体を通じた提供等の各種の手法により記憶部４２に提供されてよいが、一例として配信サービスを通じてセンターサーバ２から提供される。なお、ゲームデータには、例えば、その他にも楽曲とは別の音声が存在する場合にそのような各種の音声を再生するための音声データ等、ゲーム用の各種のデータが含まれ得る。そのようなデータには、楽曲データＭＤ等と同様に配信サービス等を通じて提供される画像データ、或いはＩＤ管理データ等が適宜に含まれ得る。しかし、これらの図示は省略した。

　制御ユニット４１には、制御ユニット４１のハードウエア資源とソフトウエア資源としてのプログラムＰＧ２との組合せによって各種の論理的装置が構成される。そして、それらの論理的装置を通じて音楽ゲームの提供に必要な各種の処理（センターサーバ２のＷｅｂサービス管理部２４が提供するＷｅｂサービスを享受するために必要な処理を含む）が実行されるが、図２の例では、音楽ゲームに関連する論理的装置として、進行制御部４３、及びデータ管理部４４が示されている。

　進行制御部４３は、ゲームの進行に必要な各種の処理を行う論理的装置である。このような処理には、例えば、プレイのための各種準備を実行する処理、プレイ行為の各実行時期をユーザに案内する処理、或いはユーザが実行するプレイ行為を評価する処理も含まれる。また、プレイのための準備には各種設定等の適宜の要素が含まれるが、例えば選択機会の提供、及び各実行時期の案内開始の判別等が含まれる。具体的には、進行制御部４３は、このような各種の処理の一例として、演奏選択処理、連携応答処理、及び楽曲開始処理を実行する。一方、データ管理部４４は、記憶部４２に記録されるゲームデータの管理に関する各種の処理を行う論理的装置である。例えば、データ管理部４４は、センターサーバ２から提供されるゲームデータを取得したり記憶部４２に保存したりする処理を実行する。例えば、データ管理部４４は、このような各種の処理の一例として、演奏データ生成処理を実行する。演奏選択処理、連携応答処理、楽曲開始処理、及び演奏データ生成処理の手順の詳細は後述する。

　ＨＭＤ型のゲーム機４には、各種の出力装置、及び入力装置が適宜に設けられ得るが、図２の例では出力装置の一例としてディスプレイ４７、及びスピーカＳＰが、入力装置の一例としてセンサＳＭが、それぞれ設けられている。ディスプレイ４７は、ゲーム画面等を表示するための周知の表示装置である。スピーカＳＰは、楽曲を含む各種音声を再生するための周知の音声再生装置である。センサＳＭは、ＨＭＤ型のゲーム機４の各種の状態を検出するための周知の検出装置（検出手段）である。センサＳＭは検出対象の状態に応じた各種の検出装置を適宜に含んでいてよく、例えばユーザの視線をトラッキングするアイトラッキング用のセンサ等を適宜に含んでいてよいが、図２の例ではそのような各種のセンサの一例として加速度センサＳＭ１、及びジャイロセンサＳＭ２が示されている。

　加速度センサＳＭ１は、ＨＭＤ型のゲーム機４に生じる加速度（例えば三軸方向の加速度）を検出するための周知の検出装置である。このような加速度の検出を通じて加速度センサＳＭ１は適宜に活用されてよいが、一例として水平状態、ＨＭＤ型のゲーム機４の傾き、或いは向きといった状態の検出に使用される。同様に、ジャイロセンサＳＭ２は、基準軸（一例として三軸）に対する角度の変化を検出するための周知の検出装置である。このような角度の検出を通じてジャイロセンサＳＭ２は適宜に活用されてよいが、一例としてＨＭＤ型のゲーム機４の回転、傾き、或いは向きといった状態の検出に使用される。また、これらの加速度センサＳＭ１及びジャイロセンサＳＭ２の検出結果は、それぞれ単独で使用されてもよい（単独で使用される場合、いずれか一方は省略されてもよい）が、一例としてＨＭＤ型のゲーム機４の向き等の各種状態の検出に組み合わされて使用される。

　ＨＭＤ型のゲーム機４には、その他にも各種の出力装置、或いは入力装置が適宜に接続され得るが、図２の例では上述の操作スティックＯＳが接続されている。操作スティックＯＳは上述のとおりであるが、制御ユニット４１に接続され、プレイ行為に応じた各種の入力信号を制御ユニット４１に出力する。

　次に、図３を参照して音楽ゲームをプレイするためのゲーム画面の一例について説明する。図３は、ＨＭＤ型のゲーム機４のディスプレイ４７に表示されるゲーム画面の一例を模式的に示す図である。音楽ゲームは各種のゲーム画面を含み得るが、図３の例はプレイ行為を実行すべき各実行時期を案内するためのゲーム画面を示している。また、音楽ゲームは適宜に構成されてよく、楽器の演奏を演出するようにプレイ行為に伴い楽器の演奏音が再生される場合も多い。このような場合、臨場感の向上のためにプレイ行為に伴い楽器の演奏動作を実行するキャラクタがゲーム画面に登場する場合もある。他のユーザ（協力者）、或いはコンピュータにそれぞれ対応する同様の複数のキャラクタが登場する場合もある。図３の例は、これらのキャラクタを含む場合のゲーム画面を示している。より具体的には、ユーザのプレイ行為に伴い、楽器の一例としてドラムを演奏する演奏動作を実行するキャラクタ、及び他のユーザ等のプレイ行為に伴い他の楽器を演奏する演奏動作を実行するキャラクタの両方を含むゲーム画面を示している。このようなゲーム画面は適宜に構成されてよいが、図３の例は仮想三次元空間を演出するように構成される場合を示している。さらに、このような仮想三次元空間は仮想カメラの撮影結果として適宜に切り取られてゲーム画面として表示されてよいが、図３の例はユーザに対応するキャラクタ（以下、ユーザキャラクタと呼ぶ場合がある）の視界を演出するように仮想三次元空間が切り取られ（概ねキャラクタの目の位置に設定された仮想カメラにより撮影され）、ゲーム画面として表示される場合を示している。この場合、ゲーム画面５０は、指示用オブジェクト５１、スコア表示領域５２、ステージ領域５３、キャラクタ画像５４、及びドラムセット画像５５を含んでいる。

　ドラムセット画像５５は、楽器のドラムセットを模した画像である。ドラムセット画像５５は、適宜のドラムセットに対応していてよいが、図３の例では二つのドラム画像５５ａ、及び四つのシンバル画像５５ｂを含んでいる。各ドラム画像５５ａ、及び各シンバル画像５５ｂは、それぞれドラムセットにおけるドラム、及びシンバルに対応する画像である。これらは実際のドラムセットと同様の配置に表示される。具体的には、二つのドラム画像５５ａは左右に並ぶようにドラムセット画像５５において中央付近に配置される。一方、四つのシンバル画像５５ｂは、ドラムセット画像５５において二つのドラム画像５５ａを挟むようにそれらの左右に二つずつ配置される。また、左側の二つのシンバル画像５５ｂ、及び右側の二つのシンバル画像５５ｂは、いずれもそれぞれ上下に分かれるように配置される。

　スコア表示領域５２は、スコア（獲得得点）を表示するための領域である。スコア表示領域５２は適宜に構成されてよいが、図３の例では正方形状に形成され、仮想三次元空間において奥側（ユーザ側が手前）に位置するように表示される。指示用オブジェクト５１は、各実行時期に対応する画像（換言すれば各実行時期を示す標識画像）である。指示用オブジェクト５１は、適宜の時期に仮想三次元空間における奥側の適宜の位置に出現し、手前側、つまりユーザに近づくように所定の移動経路に沿って移動する。このような移動経路は適宜に設定されてよいが、各ドラム画像５５ａ、及び各シンバル画像５５ｂのいずれかを通過するように設定される。各移動経路において各ドラム画像５５ａ、及び各シンバル画像５５ｂは現在時刻の基準を示す標識画像として機能する。このため、各指示用オブジェクト５１は、そのような移動経路に沿って、対応する実行時期において各ドラム画像５５ａ、及び各シンバル画像５５ｂのいずれかと一致するように移動する。移動経路は表示されてもよいが、図３の例では移動経路は表示されていない。各実行時期は指示用オブジェクト５１（指示用の標識画像）と各ドラム画像５５ａ等（現在時刻の標識画像）のいずれかとの間の相対的変位を通じて適宜に案内されてよいが、一例としてこのような指示用オブジェクト５１の各ドラム画像５５ａ等への移動を通じて案内される。

　また、指示用オブジェクト５１は各種に分類されてよいが、図３の例では第１指示用オブジェクト５１Ａ、及び第２指示用オブジェクト５１Ｂの二種類を含んでいる。第１指示用オブジェクト５１Ａ、及び第２指示用オブジェクト５１Ｂは、各実行時期において互いに異なるプレイ行為を要求する指示用オブジェクト５１である。具体的には、第１指示用オブジェクト５１Ａ、及び第２指示用オブジェクト５１Ｂはいずれも下側のシンバル画像５５ｂを叩く動作をプレイ行為としてユーザに要求するが、第１指示用オブジェクト５１Ａは左側のシンバル画像５５ｂに対する叩く動作の要求に、第２指示用オブジェクト５１Ｂは右側のシンバル画像５５ｂに対する叩く動作の要求に、それぞれ対応している。このため、第１指示用オブジェクト５１Ａ、及び第２指示用オブジェクト５１Ｂは適宜の位置に出現した後、各実行時期において、左右の下側のシンバル画像５５ｂの位置とそれぞれ一致するように、手前側に向かって移動する。

　ユーザに要求される叩く動作は、操作スティックＯＳを通じて入力される。具体的には、例えば第１指示用オブジェクト５１Ａと右側の下に位置するシンバル画像５５ｂとの一致に合わせてユーザには、仮想三次元空間におけるそのシンバル画像５５ｂの位置に対して叩く動作を実行するように操作スティックＯＳを振る動作が要求される。このため、このような各シンバル画像５５ｂ等への叩く動作が各実行時期における適切なプレイ行為として機能するように、シーケンスデータＱＤには、各指示用オブジェクト５１の移動経路、或いはその移動経路上の各シンバル画像５５ｂ等の情報が適切なプレイ行為の情報として記述される。そして、その叩く動作の実際の実行時期と実際の一致時期（シーケンスデータＱＤに記述された実行時期）との間のずれ時間が少ないほど高く評価される。第２指示用オブジェクト５１Ｂに関しても同様である。

　各ドラム画像５５ａ等を叩く動作の判定は適宜に実現されてよいが、一例として次のように実現される。まず各ドラム画像５５ａ、及び各シンバル画像５５ｂは仮想三次元空間における空間座標で定義された所定位置に配置され、その所定位置（空間座標）の各ドラム画像５５ａ等に向かって各指示用オブジェクト５１は移動する。また、各ドラム画像５５ａ等には、その所定位置を基準に評価範囲（各ドラム画像５５ａ等と同一またはそれよりちょっと大きい範囲）が設定される。スティック画像５６は操作スティックＯＳへの操作に伴い仮想三次元空間において移動するが、その先端部の位置（空間座標）が各ドラム画像５５ａ、或いはシンバル画像５５ｂの評価範囲に入ったか否かにより、叩く動作が実行されたか否か判別される。そして、その評価範囲にスティック画像５６が入った時期（実際のプレイ行為の時期）と、各ドラム画像５５ａ等に指示用オブジェクト５１が到達すべき時期（シーケンスデータＱＤの実行時期）との間のずれ時間が算出され、そのずれ時間に応じて評価が決定される。この評価は適宜に実行されてよいが、一例としてパーフェクト、グレート、グッド、或いはバッドといった評価結果を示す基準を通じて実現される。また、各実行時期を基準に所定時間内に叩く動作が実行されなければ、ミス操作（ミスに対応する評価結果）として判定される。同様に、バッドに属する期間より早く、若しくは遅く、叩く動作が実行された場合、ミスと判定される。なお、これらのいずれにも属さない時期に叩く動作が実行された場合には、その動作は何にも使用されず、無視されてよい。

　指示用オブジェクト５１は、その他にも左右の上側に位置するシンバル画像５５ｂに対応する種類、各ドラム画像５５ａに対応する種類等の種類を含み、これらの種類を通じて第１指示用オブジェクト５１Ａと同様にドラム画像５５ａ等を叩く動作を適宜に要求し得るが、図３の例ではそれらの表示は省略されている。また、第１指示用オブジェクト５１Ａ等の各種の指示用オブジェクト５１は、適宜の形態で表示されてよいが、一例としていずれもシンバル画像５５ｂ等の移動経路上に位置する現在時刻の標識画像と同様の形状に表示される。同様に、第１指示用オブジェクト５１Ａ等の各種の指示用オブジェクト５１は、互いに区別可能に適宜に表示されてよいが、一例として第１指示用オブジェクト５１Ａ、及び第２指示用オブジェクト５１Ｂは互いに異なる配色で表示される。ドラムセット画像５５における各ドラム画像５５ａ等も同様である。例えば、各ドラム画像５５ａは互いに異なる配色で表示されてよい。この場合、プレイ対象をユーザが容易に識別できるように、各指示用オブジェクト５１は、対応する各ドラム画像５５ａ等と同じ色で表示されてよい。

　ステージ領域５３は、仮想三次元空間に形成されるステージに対応する領域である。仮想三次元空間において各キャラクタは、そのステージにおいて演奏動作を実行する。このため、ステージ領域５３には、各キャラクタに対応するキャラクタ画像５４、及びドラムセット画像５５が配置される。ステージ領域５３には、適宜の数のキャラクタ画像５４が配置されてよいが、図３の例では三つのキャラクタ画像５４が表示されている。具体的には、キャラクタ画像５４は、キーボードを演奏する第１キャラクタ画像５４Ａ、ギターを演奏する第２キャラクタ画像５４Ｂ、及びドラムを演奏する第３キャラクタ画像５４Ｃを含んでいる。これらのキャラクタ画像５４Ａ、５４Ｂ、５４Ｃは、仮想三次元空間においてキーボード、ギター、及びドラム（いずれも楽器の一例）を演奏するための一つの演奏ユニットを形成する三体のキャラクタにそれぞれ対応している。これらの三体のキャラクタは、ユーザ、及び協力者（コンピュータを含む）に適宜に対応してよく、それらのいずれのプレイ行為に基づいて演奏動作を実行してもよいが、一例として第１キャラクタ画像５４Ａ、及び第２キャラクタ画像５４Ｂがコンピュータに、第３キャラクタ画像５４Ｃがユーザに、それぞれ対応している。この例において、第１キャラクタ画像５４Ａ～第３キャラクタ画像５４Ｃが本発明の複数のキャラクタとして機能する。

　第１キャラクタ画像５４Ａ～第３キャラクタ画像５４Ｃは適宜に表示されてよいが、図３の例ではユーザキャラクタ（第３キャラクタ画像５４Ｃ）の視界に対応するように、第１キャラクタ画像５４Ａ、及び第２キャラクタ画像５４Ｂは全身が、第３キャラクタ画像５４Ｃ（ユーザキャラクタ）は両手のみ（身体の一部のみ）が、それぞれ表示されている。また、仮想三次元空間においてユーザキャラクタがドラムを叩くためのスティックを握っている状況を示すように、第３キャラクタ画像５４Ｃの左右の両手には二つのスティック画像５６がそれぞれ表示されている。この場合、ユーザによる叩く動作の実行に伴い、第３キャラクタ画像５４Ｃもその叩く動作を再現するように動作する。より具体的には、叩く動作の実行に伴い、第３キャラクタ画像５４Ｃはスティック画像５６において対象のシンバル画像５５ｂ等を叩く動作（演奏動作）を実行する。第１キャラクタ画像５４Ａ、及び第２キャラクタ画像５４Ｂも同様である。つまり、協力者（コンピュータを含む）によるプレイ行為（対象の楽器、或いは入力装置の種類に応じて適宜でよいが、例えばキーボードの場合は鍵を弾く動作、ギターであれば弦を弾く動作）に伴い、第１キャラクタ画像５４Ａ、及び第２キャラクタ画像５４Ｂも同様の演奏動作をゲーム画面５０において実行する。

　図４～図５を参照して、ゲーム画面５０について更に説明する。図４は、仮想三次元空間における各キャラクタの位置関係を説明するための説明図である。図４の例は、仮想三次元空間におけるステージ、及び各キャラクタを上方から見た場合を模式的に示している。仮想三次元空間におけるステージ等は、ゲーム画面５０におけるステージ領域５３等に対応するため、図４の例では説明の便宜のためステージ、及び各キャラクタにはゲーム画面５０におけるステージ領域５３、及び各キャラクタ画像５４等と同様の符号が付されている。

　図４に示すように、各キャラクタ画像５４（仮想三次元空間における各キャラクタ）はステージ領域５３（仮想三次元空間におけるステージ）に所定の間隔を開けて配置される。各キャラクタ画像５４の位置、或いは間隔は、適宜でよく、可変的であってもよいが、一例として固定的である。つまり、各キャラクタ画像５４はステージ領域５３の予め決められた所定の位置にそれぞれ固定的に配置される。

　また、第３キャラクタ画像５４Ｃはユーザキャラクタに対応する。このため、第３キャラクタ画像５４Ｃには、視界範囲ＩＡが設定される。視界範囲ＩＡは、ゲーム画面５０を描画するための仮想カメラの撮影範囲に対応する。視界範囲ＩＡは適宜の範囲として設定されてよいが、図４の例では第３キャラクタ画像５４Ｃが正面を向いている場合に設定される視界範囲ＩＡが示されている。また、この視界範囲ＩＡは第３キャラクタ画像５４Ｃの動作、換言すればユーザの動作によって移動する。具体的には、ＨＭＤ型のゲーム機４はユーザの頭部に装着され、プレイされるが、このユーザの頭部の動きに伴い、第３キャラクタ画像５４Ｃの頭部も動作する。例えば、ユーザの頭部（ＨＭＤ型のゲーム機４）が身体における正面を向いた状態が仮想空間内の視界範囲ＩＡとなるように調整された場合、ユーザが正面を向いているとき、第３キャラクタ画像５４Ｃの頭部も仮想三次元空間において同様の方向を向くため、視界範囲ＩＡは図４の例において正面側（実線で表示される範囲）に設定される。

　一方、正面を向いた状態からユーザが右側を向いた場合、その頭部の動きはＨＭＤ型のゲーム機４のセンサＳＭにより検知され、第３キャラクタ画像５４Ｃの動きに反映される。つまり、そのような頭部の動きに伴い、第３キャラクタ画像５４Ｃの頭部も仮想三次元空間において同様の右を向くように動作する。この場合、視界範囲ＩＡは、その頭部の動きに合わせて右方向に角度が変化する。具体的には、ユーザの右を向く頭部の動きに伴い、視界範囲ＩＡは、一点鎖線で示す右傾斜範囲ＩＡ１に移動する。そして、このような右傾斜範囲ＩＡ１に含まれる仮想三次元空間がゲーム画面５０として表示される。

　図５は、視界範囲ＩＡが図４の例の右傾斜範囲ＩＡ１に移動した場合のゲーム画面５０の一例を模式的に示す図である。また、図４の例は、図３の例からユーザが右斜め上方向を向いた場合のゲーム画面５０にも対応している。このような上下方向への頭部の変化もセンサＳＭによって検出され、ゲーム画面５０に反映される。このため、この場合、図５に示すように、図３の例と比べて、視界（視界範囲ＩＡ）の移動に伴い、第２キャラクタ画像５４Ｂがゲーム画面５０の中央近くに移動している一方で、第１キャラクタ画像５４Ａの表示が消えている。また、ステージ領域５３、スコア表示領域５２、及びドラムセット画像５５にも同様の変化が生じている。

　次に、図６～図１０を参照して、音楽ゲームにおけるプレイの開始までの流れについて説明する。上述のようにユーザのプレイ行為（叩く動作）に伴い、ゲーム画面５０においてキャラクタ画像５４も同様の叩く動作、つまり演奏動作を実行する。このため、プレイの開始に伴い各キャラクタは演奏動作を実行する。ユーザキャラクタ以外の他のキャラクタ画像５４もプレイの開始に伴い同様の演奏動作を実行する。そして、これらの演奏動作の組み合わせ、換言すれば一つの演奏ユニット全体による演奏動作により演奏パフォーマンスが形成される。結果として、プレイの開始は、演奏動作、及び演奏パフォーマンスの開始に対応する。このような演奏パフォーマンス、つまりゲームのプレイは、開始条件が満たされた場合に開始される。また、演奏パフォーマンスにおいて第１キャラクタ画像５４Ａ、及び第２キャラクタ画像５４Ｂは、上述のように他のユーザによって操作されてもよいが、以下ではいずれもコンピュータによって操作（制御）される場合について説明する。

　図６は、演奏パフォーマンスの開始までの流れの一例を説明するための説明図である。図６に示すように、複数のキャラクタ画像５４（キャラクタ）間に連携状態が形成された後に開始アクションが実行された場合に開始条件が満たされ、演奏パフォーマンス、つまりゲームのプレイが開始される。具体的には、ゲーム画面５０において、プレイ（各指示用オブジェクト５１による実行時期の案内）の開始前にまず各キャラクタ画像５４は待機状態にて表示される。このような待機状態は適宜に表現されてよいが、コンピュータ制御のキャラクタの場合、所定の待機動作により表現される。このような待機動作として適宜の動作が実行されてよいが、例えば第２キャラクタ画像５４Ｂの場合、ギターをチューニングする動作を実行する。待機状態において第１キャラクタ画像５４Ａも同様にキーボードを軽く弾く動作等の適宜の待機動作を実行するが、図６の例では説明の便宜のためその表示が省略されている。

　一方、ユーザによって操作される第３キャラクタ画像５４Ｃ（他のユーザによって制御される場合、他のキャラクタも同様）にはユーザの動作（操作）が反映される。ユーザには、待機状態において各種の動作が許容されるが、そのような動作には連携アクションが含まれる。ユーザの連携アクションに伴い、第３キャラクタ画像５４Ｃも同様の連携アクションを実行する。連携アクションは、第２キャラクタ画像５４Ｂ及び第１キャラクタ画像５４Ａの両方が同時に対象となるように実行されてもよいが、一例として第２キャラクタ画像５４Ｂ及び第１キャラクタ画像５４Ａのいずれか一方にそれぞれ個別に対応するように実行される。第３キャラクタ画像５４Ｃが第２キャラクタ画像５４Ｂに対して連携アクションを実行した場合、その動作の実行をコンピュータが判別し、その連携アクションに応答するための応答アクションを第２キャラクタ画像５４Ｂに実行させる。そして、第２キャラクタ画像５４Ｂによって応答アクションが実行された場合、第３キャラクタ画像５４Ｃと第２キャラクタ画像５４Ｂとの間には連携状態が形成される。この例において、第３キャラクタ画像５４Ｃ、及び第２キャラクタ画像５４Ｂが本発明の一つのキャラクタ、及び他のキャラクタとしてそれぞれ機能する。また、連携アクション、及び応答アクションが、本発明のアクション、及び対応アクションとしてそれぞれ機能する。

　連携状態は、第２キャラクタ画像５４Ｂ及び第１キャラクタ画像５４Ａとの間に適宜に形成されてよい。例えば連携アクションが第２キャラクタ画像５４Ｂ及び第１キャラクタ画像５４Ａの両方を対象に実行され、いずれか一方の応答アクションにより連携状態が形成される場合等、連携状態は第２キャラクタ画像５４Ｂ及び第１キャラクタ画像５４Ａのいずれか一方（演奏ユニットの一部）との間に形成されれば演奏ユニット全体に形成されてもよいが、一例としてキャラクタ毎に個別に形成される。このため、第３キャラクタ画像５４Ｃによる第１キャラクタ画像５４Ａに対する連携アクション、及びそれに応答する第１キャラクタ画像５４Ａによる応答アクションが、第３キャラクタ画像５４Ｃと第１キャラクタ画像５４Ａとの間にも同様に実行される。そして、第３キャラクタ画像５４Ｃが第２キャラクタ画像５４Ｂ及び第１キャラクタ画像５４Ａの両方の間（換言すれば演奏ユニットの全体）に連携状態を形成した場合に、演奏ユニット全体が連携状態となる。連携アクションは、例えば第２キャラクタ画像５４Ｂ等のユーザキャラクタ以外の他のキャラクタによって実行されてもよく、この場合、そのような連携アクションに対してユーザが応答アクションを返した場合に連携状態が形成されてもよい。このように連携アクションは適宜のキャラクタによって実行されてよいが、一例として図６の例のようにユーザキャラクタによって実行される。

　開始条件は、各種の要件を含んでいてよく、適宜に満たされてよいが、一例として演奏ユニット全体における連携状態の形成、及びその連携状態における開始アクションの実行を要件に含んでいる。このため、演奏ユニット全体の連携状態において第３キャラクタ画像５４Ｃ（ユーザ）が開始アクションを実行した場合に開始条件が満たされる。そして、開始条件が満たされると演奏パフォーマンスが開始される。この例において、開始アクションが本発明の特別のアクションとして機能する。

　演奏パフォーマンスは、開始条件の具備を契機に適宜に開始されてよい。例えば、演奏パフォーマンスは音楽ゲームのプレイに対応し、音楽ゲームのプレイは楽曲のリズムに合わせた各実行時期の案内（指示用オブジェクト５１の表示）によって実現されるため、楽曲の再生を含んでいる。このため、開始条件具備の直後、つまり開始アクションの直後にプレイ用の楽曲の再生が開始されてもよい。このように演奏パフォーマンスは適宜に開始されてよいが、一例として開始条件具備に伴いまず開始演出が実行される。つまり、演奏パフォーマンスは開始演出用のパート、及び実際に各キャラクタ画像５４が演奏パフォーマンスを実行する演奏パートを含んでおり、開始条件の具備を契機にまず開始演出が開始される。

　開始演出は適宜に実現されてよいが、一例として楽曲再生までのカウントダウンとして機能するように実現される。このため、開始演出は、楽曲の再生にタイミングを合わせるための準備パートとして機能する。カウントダウンの機能は適宜に実現されてよいが、一例として各キャラクタ画像５４に一定間隔毎に順にスポットライトが当てられる演出により実現される。つまり、開始アクションの後に各キャラクタ画像５４に順にスポットライトが当てられる演出がまず開始され、全員にスポットライトが当たった後に楽曲の再生が開始される。そして、楽曲の再生に伴い、指示用オブジェクト５１の表示が開始され、それに対する演奏動作（プレイ行為）も開始される。つまり、各キャラクタ画像５４による実際の演奏動作（演奏パート）が開始される。この例において、準備パート、及び演奏パートが、本発明の準備パート、及びパフォーマンスパートとしてそれぞれ機能する。

　連携アクションは適宜のアクションであってよい。例えば、実際のバンド（演奏ユニット）によって演奏の開始時に実行されているように、ドラム担当がシンバル等を一定のリズムで軽く数回叩く動作が連携アクションとして採用されてもよい。あるいは、ユーザキャラクタが他のキャラクタに開始を呼びかけるような声かけ（発声）が連携アクションとして採用されてもよい。このように連携アクションとして各種のアクションが適宜に採用されてよいが、一例として対象のキャラクタに視線を向ける動作が採用される。また、このような視線を向ける動作は適宜に判別されてよく、例えば図５の例のように一つのキャラクタ画像５４のみが視界範囲ＩＡに含まれている場合にそのキャラクタ画像５４に視線が向けられていると判別されてもよく、この場合視界範囲ＩＡが視線を向ける動作の判別に使用されてよい。このように視線を向ける動作は適宜に判別されてよいが、一例として視界範囲ＩＡの一部に視野範囲が設定され、その視野範囲に基づいて視線の向ける動作の有無が判別される。このため、ゲーム画面５０（あるいは仮想三次元空間）には、ユーザの視線（ユーザキャラクタの視線）を判別するための視野範囲が設定される。

　図７は、ゲーム画面５０に設定される視野範囲を説明するための説明図である。図７の例は、図５の例のゲーム画面５０に設定される視野範囲を示している。図７に示すように、視野範囲ＩＲは、中心視野範囲ＩＲ１、及び周辺視野範囲ＩＲ２を含んでいる。視野範囲ＩＲはゲーム画面５０の適宜の位置に形成されてよく、その位置は可変的であってもよい。また、視野範囲ＩＲの位置がゲーム画面５０において可変的に設定される場合、その位置は、例えばアイトラッキングによる視線のトラッキングといった各種の検出結果等を通じて適宜に設定されてよい。このように視野範囲ＩＲはゲーム画面５０に適宜に設定されてよいが、一例としてゲーム画面５０（視界範囲）の中央付近に固定的に形成される。また、視野範囲ＩＲは可視化されていてもよいが、一例として不可視に設定される。つまり、図７の例では便宜的に中心視野範囲ＩＲ１がドット柄で、周辺視野範囲ＩＲ２が右斜線で、それぞれ表示されているが、図５の例のように実際のゲーム画面５０には視野範囲ＩＲは表示されない。

　中心視野範囲ＩＲ１は、視線を向ける動作の判別に使用される範囲である。中心視野範囲ＩＲ１は適宜の形状に形成されてよいが、一例として所定の大きさの円形に形成される。また、視線を向ける動作の判別は、中心視野範囲ＩＲ１を利用して適宜に実現されてよく、例えば頭部等の主要部位が含まれている場合に視線を向けていると判別されてもよいが、一例として中心視野範囲ＩＲ１にキャラクタ画像５４が一定割合以上含まれている（入っている）場合にそのキャラクタ画像５４に視線を向けていると判別される。また、このような一定割合は適宜に設定されてよいが、一例として対象のキャラクタ画像５４の半分以上の面積が利用される。例えば、図７の例では第２キャラクタ画像５４Ｂの半分以上が、中心視野範囲ＩＲ１に入っている。この場合、ユーザキャラクタ（第３キャラクタ画像５４Ｃ）は第２キャラクタ画像５４Ｂに視線を向けていると判別される。

　一方、周辺視野範囲ＩＲ２は中心視野範囲ＩＲ１を含むようにその周囲に形成される領域である。周辺視野範囲ＩＲ２の形状も適宜に形成されてよいが、一例として中心視野範囲ＩＲ１を中央付近に含む所定の大きさの楕円形に形成される。周辺視野範囲ＩＲ２は適宜に利用されてよく、省略されてもよいが、一例として連携アクションの判別のための準備に使用される。具体的には、周辺視野範囲ＩＲ２にキャラクタ画像５４が入ってきた場合にそのキャラクタ画像５４に視線を向ける可能性があるとコンピュータは判別し、中心視野範囲ＩＲ１にキャラクタ画像５４が含まれるか否か判別を開始する。一例として、このような視野範囲ＩＲがゲーム画面５０に設定され、連携アクションの実行の有無、つまりユーザのキャラクタ画像５４が他のキャラクタ画像５４に視線を向けているか否の判別が実現される。

　図８は、応答アクションの一例を説明するための説明図である。応答アクションとして、連携アクションに応じて、或いは連携アクションとは独立して各種の動作（反応）が適宜に採用されてよく、例えば各キャラクタが自己の楽器を軽く演奏する動作やサムアップ等の連携アクションの認識を示す各種の動作が採用されてよいが、この種の動作の一例として視線を向ける動作が利用される。つまり、ユーザキャラクタが連携アクションとして他のキャラクタに視線を向ける動作を実行した後、その他のキャラクタもそのユーザキャラクタに視線を向ける同様の動作を応答アクションとして実行する。図８の例は、応答アクションとしてこのような視線を向ける動作を実行する他のキャラクタ画像５４の一例を模式的に示している。また、図８の例の（Ａ）は応答アクション前のキャラクタ画像５４を、（Ｂ）は応答アクション時のキャラクタ画像５４を、それぞれ示している。

　図８の（Ａ）に示すように、他のキャラクタ画像５４（コンピュータによって制御されるキャラクタ）は、応答アクション前において正面側、つまり連携アクションとして視線を向けたキャラクタ画像５４（ユーザ）の方向を向いていない。応答アクション前において他のキャラクタ画像５４は適宜の方向を向いていてよく、例えば背中を向けるような方向を向いていてもよいが、図８の例では左方向に首を向け、視線も同様の左方向を向いている。一方、図８の（Ｂ）に示すように、その他のキャラクタ画像５４は、応答アクション時には正面側に首を向け、視線も同様の正面側を向く。つまり、ユーザによって連携アクションとして視線を向ける動作が実行された場合（中心視野範囲ＩＲ１にキャラクタ画像５４が一定割合以上含まれた場合）、その視線を向ける動作に応答してユーザに視線を返すように、他のキャラクタ画像５４もユーザの方に同様の視線を向ける動作を実行する。これは他のキャラクタ画像５４がユーザの方（正面側）に背中を向けていても（背中を向けるような方向を向いていても）同様である。つまり、応答アクション前の向きにかかわらず、他のキャラクタ画像５４は応答アクションとしてユーザの方に視線を向ける動作を実行する。なお、演奏開始前はユーザが視線を他のキャラクタ画像５４等に向けやすいように、ユーザに対して背中を向けることがないように他のキャラクタ画像５４等の動きが制御されてもよい。

　他のキャラクタ画像５４の視線の向きは適宜に判別されてよいが、一例として他のキャラクタ画像５４にもユーザキャラクタと同様の視野範囲ＩＲが設定され、視野範囲ＩＲに入っているか否か、より具体的には視野範囲ＩＲに中心視野範囲ＩＲ１にユーザキャラクタが一定割合以上入っているか否かに応じて判別される。また、このような視線を向ける動作（視線を返す動作）は、適宜のタイミングで実行されてよく、例えば連携アクションとは時差的に実行されてもよい。つまり、視線を向ける動作に対して視線を返す動作は、ユーザが視線を外した後において実行されてもよい。このように視線を返す動作は適宜のタイミングで実行されてよいが、一例として双方によるアイコンタクトが実現されるようにユーザが視線を向けている最中に実行される。この場合において、他のキャラクタ画像５４が視線を向ける前にユーザが視線を外した場合、応答アクションは未完了と判断されてもよい（この場合、応答アクションのために再度連携アクションの実行が要求される）が、一例として他のキャラクタ画像５４が視線を向ける動作の開始後であればユーザの視線を外す動作は許容される。一例として、連携アクションの対象となった（視線を向けられた）キャラクタ画像５４は、このような応答アクションを実行する。

　図９は、連携アクションとして視線を向けられた他のキャラクタ画像５４の動作の変化の流れを説明するための説明図である。そのような他のキャラクタ画像５４として、例えば図３の例において第１キャラクタ画像５４Ａ等の適宜のキャラクタ画像５４が機能してよいが、図９の例では図３の例の第２キャラクタ画像５４Ｂが機能する場合を示している。この場合、図９に示すように、第２キャラクタ画像５４Ｂはゲーム画面５０においてまず上述のように待機状態を形成し、その待機（アイドル）状態において待機動作を実行する（Ｓ１）。また、第２キャラクタ画像５４Ｂ（コンピュータ）は、待機状態においてユーザキャラクタ、つまり第３キャラクタ画像５４Ｃが連携アクションを実行したか否か判別する（Ｓ２）。より具体的には、第２キャラクタ画像５４Ｂは第３キャラクタ画像５４Ｃが視線をこちらに向けているか否か（自己がユーザの中心視野範囲ＩＲ１に一定割合以上含まれているか否か）判別する。そして、第３キャラクタ画像５４Ｃが視線をこちらに向けていない（自己がユーザの中心視野範囲ＩＲ１に一定割合以上含まれていない）場合、第２キャラクタ画像５４Ｂは待機状態を継続する。

　一方、第３キャラクタ画像５４Ｃが視線をこちらに向けている（自己が中心視野範囲ＩＲ１に一定割合以上含まれている）場合、第２キャラクタ画像５４Ｂは第３キャラクタ画像５４Ｃの方を振り向く振り向き動作（応答アクション）を実行する（Ｓ３）。応答アクションは、適宜に構成されてよく、振り向き動作（第３キャラクタ画像５４Ｃの方に視線を向ける動作）のみによって構成されてもよいが、一例として応答ジェスチャも含んでいる。応答ジェスチャは、応答アクションの実行をユーザに伝えるための動作である。つまり、第２キャラクタ画像５４Ｂは振り向き動作に続いて応答アクションの一つとして応答ジェスチャを実行する（Ｓ４）。このような応答ジェスチャとして、手を振る、親指と人差し指とで輪を作る（ＯＫサイン）、頷く等の各種頭部の動作、或いは発声等が採用されてよいが、一例としてサムアップ（親指を立てる）動作が採用される。つまり、第２キャラクタ画像５４Ｂは振り向き動作に続いて、或いはそれと同時にサムアップ動作を実行する。そして、第２キャラクタ画像５４Ｂは、振り向き動作、及び応答ジェスチャの実行により応答アクションを完了し、連携状態を形成する。

　なお、連携状態の形成までの流れは適宜でよく、例えばユーザが他のキャラクタに視線を向け、他のキャラクタも視線を返した状態でユーザ（ユーザキャラクタ）がサムアップ動作などの適宜の動作を行い、これに対して更に他のキャラクタが同様のサムアップ動作等の適宜の動作を行った場合に連携状態は形成されてもよい。あるいは、これらの動作の一部が適宜に省略されてもよい。これらの場合において、連携状態を形成するために相互に実行し合う各種動作の一部が適宜に連携アクション、及び応答アクションとして機能してよい。開始条件も同様である。例えば、開始条件はユーザキャラクタと他の全キャラクタとの間に連携状態が形成された場合に満たされてもよい。つまり、開始条件は、開始アクションを要件に含んでいなくてもよい。この場合、開始演出は適宜に開始されてよいが、例えば最後の他のキャラクタとの間に連携状態が形成された直後に開始演出が実行される。また、操作スティックＯＳには、スティック画像５６に対する操作と区別するために、サムアップ動作等の手の一部を利用する動作のための各種ボタンが適宜に設けられていてよい。あるいは、別途ユーザの全体（主要部位でもよい）を撮影するためのカメラが設けられてもよく、そのようなカメラによってサムアップ動作等の各種の部位の動作を含む適宜の動作が検出されてもよい。

　第２キャラクタ画像５４Ｂは、連携状態（第１キャラクタ画像５４Ａとの連携状態の形成を待つ待機中）において適宜の動作を実行してよいが、一例として待機状態と同様に待機動作を実行する（Ｓ５）。また、第２キャラクタ画像５４Ｂ等との連携状態（待機動作中）においてユーザによって開始アクションが実行されたか否か判別される（Ｓ６）。このような開始アクションとして各種の動作が適宜に機能してよいが、一例としてサムアップ動作が機能する。つまり、第２キャラクタ画像５４Ｂ等との連携状態においてユーザによって開始アクションとしてサムアップ動作が実行されたか否か判別される。連携状態の形成から所定時間内にサムアップ動作、つまり開始アクションが実行されない場合、第２キャラクタ画像５４Ｂは連携状態を解除して、再度待機状態に戻る。

　一方、連携状態の形成から所定時間内にサムアップ動作、つまり開始アクションが実行された場合、第２キャラクタ画像５４Ｂはその開始アクションに対して応答ジェスチャを更に実行する（Ｓ７）。このような応答ジェスチャは省略されてもよいが、一例として実行される。また、この応答ジェスチャは応答アクションとしての応答ジェスチャと相違していてもよいが、一例として同様に構成される。つまり、第３キャラクタ画像５４Ｃによる開始アクションに伴い、応答ジェスチャとして同様のサムアップ動作を実行する。第１キャラクタ画像５４Ａも同様の流れで動作が変化し、第３キャラクタ画像５４Ｃとの間に連携状態等を形成する。

　開始条件の要件は、ユーザに対応するキャラクタ以外の全キャラクタとの間の連携状態における開始アクションのみであってもよいし、他の要件を含んでいてもよい。また、このような他の要件として第３キャラクタ画像５４Ｃ以外の全キャラクタ画像５４による応答ジェスチャ（Ｓ７）が機能してもよい。このように開始条件の要件は適宜であってよいが、一例として第１キャラクタ画像５４Ａ、及び第２キャラクタ画像５４Ｂの両者から応答ジェスチャ（Ｓ７）が実行された後に演奏パフォーマンスが開始される。より具体的には、第１キャラクタ画像５４Ａ、及び第２キャラクタ画像５４Ｂの両者からの応答ジェスチャ（Ｓ７）により開始条件が満たされ、開始演出が開始される。そして、開始演出によるカウントダウンの後に楽曲の再生、つまり演奏パートが開始される。一例として、このような流れで他のキャラクタの動作は変化し、演奏パフォーマンスは開始される。なお、ユーザキャラクタ以外のキャラクタがコンピュータによって制御される場合、開始アクションの実行に伴い、応答ジェスチャ（Ｓ７）も自動で実行される。このため、この場合、開始アクションの有無の判別が、開始条件が満たされるか否かの判別と同様に機能してよい。

　次に、演奏データＯＤの詳細について説明する。第１キャラクタ画像５４Ａ、或いは第２キャラクタ画像５４Ｂといった他のキャラクタ画像５４による演奏動作（演奏パフォーマンス）がコンピュータによって制御される場合、他のキャラクタ画像５４は適宜の演奏動作を実行してよく、予め設定された演奏動作（一つの動作であっても複数の動作出会ってもよい）を実行してもよいが、一例としてユーザが過去に他のキャラクタ画像５４を通じてプレイしている場合にはそのプレイ時と同様の演奏動作を実行する。つまり、コンピュータは、そのプレイ時にユーザが行った演奏動作（プレイ実績）と同様の動作をトレースする（引き写す）ように他のキャラクタ画像５４の動作を制御する。演奏データＯＤは、このようなユーザの演奏動作の実績を他のキャラクタに実行させるためのデータである。例えば、ユーザが第２キャラクタ画像５４Ｂを介してプレイした（プレイ用のキャラクタを選択するキャラクタ選択機会においてユーザキャラクタとして選択された）場合、そのプレイにおけるプレイ内容（第２キャラクタ画像５４Ｂを介したギターの演奏動作の実績）が演奏データＯＤに記録され、管理される。ユーザが第１キャラクタ画像５４Ａを介してプレイした場合の実績も同様である。

　図１０は、演奏データＯＤの構成の一例を示す図である。図１０に示すように、動画データ部ＯＤ１、及び情報管理部ＯＤ２を含んでいる。動画データ部ＯＤ１は、他のキャラクタ画像５４に演奏動作を実行させるための動画データとして構成される部分である。このような動画データ部は各種の動画データとして適宜に構成されてよいが、一例として各キャラクタ画像５４の動作はモーションキャプチャーデータとして構成されるため、動画データ部も同様にモーションキャプチャーデータとして構成される。このモーションキャプチャーデータは適宜に生成されてよく、例えばユーザの全身を撮影するカメラからユーザのモーションを検出してデータ化してもよいし、ユーザの身体に付けられたマーカからその動きを検出してデータ化してもよい。このようにモーションキャプチャーデータ（動画データ部ＯＤ１）は適宜に生成されてよいが、一例としてＨＭＤ型のゲーム機４の時間経過による動き（頭部の動き）、及び操作スティックＯＳの時間経過による動きを記録し、それらをモーションに置換することにより生成される。動画データ部は演奏動作毎に用意される。一方、情報管理部ＯＤ２は、各動画データ部を管理するための情報が記述された部分である。情報管理部ＯＤ２は、各動画データ部の管理に必要な各種の情報を適宜に含み得るが、図１０の例では動画データ部（演奏動作）毎にそれに関する情報を管理する演奏レコードＯＤＲを含んでいる。演奏レコードＯＤＲは、このような管理のために、“演奏ＩＤ”、“キャラクタ”、“楽曲”“ユーザＩＤ”、及び“日時”の情報を含んでいる。演奏レコードＯＤＲには、これらの情報が相互に関連付けられるように記録されている。また、この例において演奏データＯＤが本発明の候補データとして機能する。

　“演奏ＩＤ”は、各演奏動作（動画データ部）を管理するために演奏動作毎にユニークな演奏ＩＤを示す情報である。“キャラクタ”は、その演奏動作に対応するキャラクタを特定するための情報である。このような情報として各キャラクタを特定可能な適宜の情報が利用されてよいが、一例としてキャラクタ毎にユニークなキャラクタＩＤの情報が利用される。具体的には、例えば第３キャラクタ画像５４Ｃを介してプレイした実績に対応する演奏動作の場合、その第３キャラクタ画像５４Ｃに対応するキャラクタＩＤの情報が“キャラクタ”に記述される。第１キャラクタ画像５４Ａ等の場合も同様である。また、各キャラクタは演奏する楽器と対応付けられている。このため、“キャラクタ”の情報は演奏対象の楽器の情報としても機能する。このため、“キャラクタ”に代えて“楽器”の情報（例えば楽器のＩＤ）が記述されてもよい。“楽曲”は演奏動作の際に使用された楽曲を示す情報である。“楽曲”には各楽曲を特定可能な適宜の情報が記述されてよいが、一例として楽曲毎にユニークな楽曲ＩＤの情報が記述される。“ユーザＩＤ”は、各ユーザを識別するためにユーザ毎にユニークなユーザＩＤを示す情報である。プレイ実績として使用可能な演奏動作は、各ユーザにとって自己のプレイ実績に限定されてもよいが、一例として他のユーザのプレイ実績も使用可能である。“日時”は各演奏動作の実績に対応するプレイの日時を示す情報である。なお、演奏データＯＤは、これらの情報に限定されず、例えば演奏パフォーマンスの実現に必要な情報等を適宜に管理してよい。あるいは、これらの情報の一部が適宜に省略されてもよい。

　次に、演奏選択処理、連携応答処理、楽曲開始処理、及び演奏データ生成処理の手順について説明する。演奏選択処理は、ユーザキャラクタ以外の他のキャラクタに実行させるべき演奏動作を選択する演奏選択機会を提供するための処理である。例えば、ユーザが第３キャラクタ画像５４Ｃを介して音楽ゲームをプレイする場合において、第１キャラクタ画像５４Ａ、及び第２キャラクタ画像５４Ｂにそれぞれ実行させるべき演奏動作が演奏選択機会にて選択される。具体的には、同じキャラクタに対して複数のプレイ実績が存在する場合、演奏データＯＤはその同じキャラクタに対して複数の動画データ部ＯＤ１（複数の演奏動作）を含んでいる。この場合、それらの複数の演奏動作の候補から他のキャラクタに実行させるべき演奏動作が演奏選択機会において選択される。図１１の例は、このような演奏選択機会を提供するための手順の一例を示している。この場合、進行制御部４３は、音楽ゲームのプレイに使用するキャラクタを選択するためのキャラクタ選択機会をユーザに提供する毎に図１１の演奏選択処理を開始し、まずそのキャラクタ選択機会におけるキャラクタの選択結果を取得する（ステップＳ１０１）。

　続いて進行制御部４３は、キャラクタ選択機会において選択したキャラクタ以外のキャラクタに実行させるべき演奏動作を選択するための演奏選択機会を提供する（ステップＳ１０２）。具体的には、進行制御部４３は、演奏データＯＤを参照し、対象のキャラクタ毎に複数の演奏動作の候補（他のユーザの演奏実績、及び予め用意された複数の所定の動作を含んでいてよい）から一つの演奏動作が選択されるように演奏選択機会を提供する。また、このような演奏選択機会は適宜に実現されてよいが、一例として演奏動作の選択に必要な情報を含む演奏選択機会用の選択画面（不図示）を通じて実現される。演奏動作の選択に必要な情報には、例えば、演奏動作の実績に対応するユーザ（誰の演奏動作であるか）、或いはそのユーザのレベルや得点等の各種成績に関する情報といった各種の情報が適宜に含まれていてよい。演奏選択機会における選択肢は、ユーザが選択した楽曲、楽器に対応して提示される。例えば、ユーザが選択した楽曲と同一の楽曲であって、ユーザが選択した楽器とは異なる楽器により生成された演奏データＯＤが、演奏選択機会における選択肢としてユーザに提示される。選択肢の限定条件はこれ以外、例えば演奏データＯＤが作成された期間等が適宜に含まれていてもよい。

　次に進行制御部４３は、演奏選択機会における選択結果に基づいて他のキャラクタの演奏動作を決定する（ステップＳ１０３）。そして、この決定の後に進行制御部４３は今回の演奏選択処理を終了する。これにより、ユーザキャラクタ以外の他のキャラクタに実行させるべき演奏動作を選択する演奏選択機会が実現される。また、演奏選択機会では、このような演奏動作の候補として、他のユーザのプレイ実績を含む複数の演奏動作の実績が提示される。このため、このような演奏選択機会を通じて、演奏パフォーマンスにおいて他のキャラクタに実際のプレイ実績に対応する演奏動作が実行される。

　連携応答処理は、各キャラクタに連携状態を形成させるための処理である。各キャラクタは他のユーザによって操作されてもよく、その場合連携状態の形成は他のユーザによって応答アクションが実行されたか否か判別され、応答アクションが実行された場合に形成されるが、図１２の例はコンピュータ（進行制御部４３）によって各キャラクタの動作が制御される場合を示している。この場合、進行制御部４３は、ユーザキャラクタ（例えば図３の例の第３キャラクタ画像５４Ｃ）が（周辺視野範囲ＩＲ２に他のキャラクタを含む状況において）ユーザによって操作される毎に図１２の連携応答処理を開始し、まずそのユーザの操作が連携アクションに該当するか否か判別する（ステップＳ２０１）。一例として、そのユーザの操作が中心視野範囲ＩＲ１に他のキャラクタを一定割合以上含めるように視線を向ける動作に対応する場合、その操作（動作）は連携アクションに該当する。このため、進行制御部４３は、そのユーザの操作が中心視野範囲ＩＲ１に他のキャラクタを一定割合以上含める動作に該当するか否か判別する。ユーザの操作が中心視野範囲ＩＲ１に他のキャラクタを一定割合以上含める動作（視線を向ける動作）に該当しない場合、つまりそのユーザの操作が連携アクションに該当しない場合、進行制御部４３は以降の処理をスキップして今回の連携応答処理を終了する。

　一方、ユーザの操作が中心視野範囲ＩＲ１に他のキャラクタを一定割合以上含める動作（視線を向ける動作）に該当する場合、つまりそのユーザの操作が連携アクションに該当する場合、進行制御部４３はその連携アクションの対象のキャラクタ、つまり中心視野範囲ＩＲ１に一定割合以上含まれるキャラクタに応答アクションを実行させる（ステップＳ２０２）。具体的には、例えば応答アクションとして上述のように視線を向ける（視線を返す）動作、及び応答ジェスチャ（サムアップ）が採用される場合、ユーザのキャラクタに視線を向ける動作を実行し、かつサムアップ動作を実行するように、対象のキャラクタの動作を制御する。

　続いて進行制御部４３は、ユーザキャラクタとステップＳ２０２において応答アクションを実行させたキャラクタとの間に連携状態を形成させる（ステップＳ２０３）。連携状態の形成は適宜に実現されてよく、例えば専用の動作により連携状態が表現される場合にはそのような動作の実行により実現されてもよいが、一例として連携状態の有無を管理するためのフラグの更新により実現される。具体的には、各キャラクタには、連携状態の有無を管理するためのパラメータが設定される。このため、進行制御部４３は、このフラグを連携状態の形成を示す状態に更新することにより連携状態の形成を実現する。そして、連携状態を形成した後に進行制御部４３は今回の連携応答処理を終了する。これにより、他のキャラクタの動作が連携アクションに応じて応答アクションを実行するように制御される。つまり、ユーザキャラクタと他のキャラクタとの間に連携状態が積極的に形成されるように、他のキャラクタの動作が制御される。そして、連携状態が形成された場合には、その状態がフラグにより管理される。

　楽曲開始処理は、開始条件を契機に演奏パフォーマンス（各実行時期の案内）を開始させるための処理である。図１３の例は、図９の流れで他のキャラクタが動作する場合に実行される楽曲開始処理を示している。この場合、進行制御部４３は、ユーザによって開始アクションが実行される毎、及び連携状態の形成から所定時間経過毎に図１３の楽曲開始処理を開始し、まず開始条件を満たすか否か判別する（ステップＳ３０１）。具体的には、上述のように一例として開始アクション（例えばサムアップ動作）が実行され、かつそれに応答する応答ジェスチャが実行された場合に開始条件は満たされる。このため、進行制御部４３は、他のキャラクタの全部が応答ジェスチャを実行した場合に開始条件が満たされると判別してもよいが、応答ジェスチャは開始アクションの実行に伴いコンピュータ（進行制御部４３）によって自動で実行されるため、一例としてユーザのキャラクタと他のキャラクタの全部との間に連携状態が形成された状況において開始アクションが実行された場合に開始条件が満たされたと判別する。

　開始条件が満たされない場合、進行制御部４３は連携状態を解除するための解除条件が満たされるか否か判別する（ステップＳ３０２）。解除条件は適宜に満たされてよいが、一例として連携状態の形成から所定時間経過した場合に満たされる。このため、進行制御部４３は、連携状態の形成から所定時間経過しているか否か判別する。解除条件が満たされない場合、つまり連携状態の形成から所定時間経過していない場合、連携状態を維持する（ステップＳ３０３）。つまり、進行制御部４３は連携状態を示すフラグの状態をそのままの状態に維持する。一方、解除条件が満たされる場合、つまり連携状態の形成から所定時間経過した場合、進行制御部４３は連携状態を解除する（ステップＳ３０４）。具体的には、進行制御部４３は、連携状態を示すフラグの状態を非連携状態に対応するように変更する。そして、進行制御部４３は、連携状態の維持、或いは連携状態の解除の後に、今回の楽曲開始処理を終了する。

　一方、ステップＳ３０１において開始条件が満たされる場合、つまり開始アクションがユーザキャラクタと他のキャラクタの全部との間に連携状態が形成された状況において実行された場合、進行制御部４３は、開始演出を開始する（ステップＳ３０５）。具体的には、進行制御部４３は、開始演出をゲーム画面５０に表示する。続いて進行制御部４３は、その開始演出の後に楽曲の再生、換言すれば演奏パートを開始させる（ステップＳ３０３）。そして、楽曲の再生を開始させた後に進行制御部４３は今回の楽曲開始処理を終了する。これにより、ユーザキャラクタと他のキャラクタとの間の連携状態の形成を要件に含む開始条件の具備を契機に演奏パフォーマンスが開始される。より具体的には、ユーザキャラクタと他のキャラクタの全部との間に連携状態が形成された状況において開始アクションが実行された場合に開始条件が満たされ、演奏パフォーマンスの開始演出、つまり準備パートが開始される。そして、その開始演出の後に楽曲の再生、つまり演奏パートが開始される。

　演奏データ生成処理は、各ユーザのプレイ実績に基づいて演奏データＯＤを生成するための処理である。演奏データＯＤは適宜に生成されてよく、例えば一律に全ユーザの全プレイの実績に基づいて生成されてもよいが、一例としてユーザが演奏データＯＤの生成を希望した場合に生成される。この場合、演奏データＯＤの生成を希望したユーザ（別途生成の要否を確認するための機会が適宜にユーザに付与されてよい）のプレイにおいて演奏パートが開始されると、データ管理部４４は図１４の演奏データ生成処理を開始し、まず演奏パートにおけるユーザの操作、つまりユーザキャラクタの動作を記録する（ステップＳ４０１）。続いてデータ管理部４４は、ステップＳ４０１の記録結果に基づいて演奏データＯＤを生成する（ステップＳ４０２）。具体的には、データ管理部４４は、ユーザキャラクタの動作を再現するための動画データ部ＯＤ１、及びそれに対応する各種情報を記録する情報管理部ＯＤ２を生成する。そして、演奏データＯＤを生成した後にデータ管理部４４は今回の演奏データ生成処理を終了する。これにより、各ユーザのプレイ実績に対応する演奏動作を再現するための演奏データＯＤが生成される。なお、一律に演奏データＯＤが生成され、ユーザが希望した場合やベストスコアが算出された場合等所定条件を満たした場合にそれが保存されてもよい。

　以上に説明したように、この形態によれば、連携状態は、ユーザキャラクタ（例えば第３キャラクタ画像５４Ｃ）による連携アクションと、それに応答する他のキャラクタ（例えば第２キャラクタ画像５４Ｂ）による応答アクションとにより形成される。このため、これらの連携アクション、及び応答アクションを通じてゲームの複数のキャラクタに呼吸を合わせるプロセスを模倣させることができる。より具体的には、ユーザキャラクタによって視線を向ける動作が実行された場合に、その視線を向けられた他のキャラクタによる視線を返す動作、及びサムアップ動作により連携状態が形成される。これにより、これらのユーザキャラクタと他のキャラクタとの間にアイコンタクトを通じて呼吸を合わせるプロセスを模倣させることができる。

　また、開始条件が満たされた場合に演奏パフォーマンスが開始される一方で、開始条件が満たされるまで演奏パフォーマンスの開始が待機される。そして、そのような演奏パフォーマンスの開始の契機とされる開始条件は、連携状態の形成を要件に含んでいる。つまり、連携状態の形成を経て演奏パフォーマンスは開始される。このため、演奏パフォーマンスの開始前に、複数人による実際の演奏パフォーマンスにおいて実行される呼吸を合わせるプロセス、より具体的にはアイコンタクトを通じて呼吸を合わせるプロセスと同様のプロセスをゲームの複数のキャラクタに実行させることができる。結果として、演奏パフォーマンスの臨場感、或いは一体感を向上させることができる。

　また、ユーザキャラクタによる連携アクションの実行に伴い、他のキャラクタがコンピュータによって応答アクションを実行するように制御される場合、ユーザキャラクタによる連携アクションを契機に、積極的に連携状態を形成することができる。このため、開始条件具備の時期をユーザの都合に合わせることができる。さらに、そのような他のキャラクタが演奏パフォーマンスにおいてユーザのプレイ実績をトレースするように動作する場合、演奏パフォーマンスにおけるユーザキャラクタ以外の他のキャラクタの動作に過去のユーザのプレイ実績、つまり演奏動作の実績を反映することができる。これにより、演奏パフォーマンスのリアリティ、ひいては臨場感を更に向上させることができる。また、このような演奏動作の実績の活用により、各ユーザによる他のキャラクタの使用、或いは他のユーザによる自己の演奏実績の利用を促すことができ、ひいてはゲームの利用を促進することもできる。

　以上の形態において、ＨＭＤ型のゲーム機４の進行制御部４３が、図１３の楽曲開始処理を実行することにより本発明の条件判別手段、及び進行制御手段として機能する。具体的には、進行制御部４３が、図１３のステップＳ３０１を実行することにより条件判別手段として機能する。また、進行制御部４３が、図１３のステップＳ３０５、及びステップＳ３０３の処理を実行することにより進行制御手段として機能する。同様に、ＨＭＤ型のゲーム機４の進行制御部４３が、図１２の連携応答処理においてステップＳ２０２を実行することにより本発明のキャラクタ制御手段として機能する。さらに、ＨＭＤ型のゲーム機４の進行制御部４３が、図１１の演奏選択処理においてステップＳ１０２を実行することにより本発明の機会提供手段として機能する。

　本発明は上述した形態に限定されず、適宜の変形又は変更が施された形態にて実施されてよい。例えば、上述の形態では、図１１～図１４の処理はＨＭＤ型のゲーム機４で実行されている。しかし、本発明は、このような形態に限定されない。例えば、図１１～図１４の処理の全部あるいは一部はセンターサーバ２によって実行されてもよい。例えば、図１１～図１３の処理の全部をセンターサーバ２が実行する場合、センターサーバ２単体（複数のサーバ装置を含んでもよい）が本発明のゲームシステムとして機能してもよい。一方で、ＨＭＤ型のゲーム機４の単体が本発明のゲームシステムとして機能してよい。つまり、本発明のゲームシステムにおいてセンターサーバ２は適宜に省略されてよい。

　上述した実施の形態及び変形例のそれぞれから導き出される本発明の各種の態様を以下に記載する。なお、以下の説明では、本発明の各態様の理解を容易にするために添付図面に図示された対応する部材を括弧書きにて付記するが、それにより本発明が図示の形態に限定されるものではない。

　本発明のゲームシステムは、ユーザのプレイ行為を入力するための入力装置（ＯＳ）、及び前記ユーザのプレイ行為を通じて操作されるキャラクタとしてのユーザキャラクタ（５４Ｃ）を含む複数のキャラクタ（５４）が含まれるようにゲーム画面（５０）を表示する表示装置（４７）に接続され、前記複数のキャラクタが実行するパフォーマンスを含むゲームを提供するゲームシステム（４）であって、前記複数のキャラクタのうちの少なくとも一つのキャラクタ（５４Ｃ）が実行したアクションに対応する所定のアクションとしての対応アクションを他のキャラクタ（５４Ｂ）が実行した場合に前記一つのキャラクタと前記他のキャラクタとの間に少なくとも形成される連携状態の形成を要件に含む開始条件が満たされるか否か判別する条件判別手段（４３）と、前記開始条件が満たされた場合に当該開始条件の具備を契機に前記パフォーマンスが開始される一方で、前記開始条件が満たされるまで前記パフォーマンスの開始が待機されるように前記ゲームの進行を制御する進行制御手段（４３）と、を備えるものである。

　本発明によれば、連携状態は一つのキャラクタによるアクションとそれに対応する他のキャラクタによる対応アクションとにより形成される。このため、これらのアクション、及び対応アクションを通じてゲームの複数のキャラクタに呼吸を合わせるプロセスを模倣させることができる。また、開始条件が満たされた場合にパフォーマンスが開始される一方で、開始条件が満たされるまでパフォーマンスの開始が待機される。そして、そのようなパフォーマンスの開始の契機とされる開始条件は、連携状態の形成を要件に含んでいる。つまり、連携状態の形成を経てパフォーマンスは開始される。このため、パフォーマンスの開始前に、複数人によるパフォーマンスにおいて実行される呼吸を合わせるプロセスと同様のプロセスをゲームの複数のキャラクタに実行させることができる。結果として、パフォーマンスの臨場感、或いは一体感を向上させることができる。

　複数のキャラクタは、少なくとも一体のユーザキャラクタを含む限り、適宜に制御されてよい。例えば、複数のキャラクタは複数のユーザによってそれぞれ制御されてもよい。あるいは、ユーザキャラクタ以外の全キャラクタがコンピュータによって制御されてもよい。また、連携状態の形成の契機となるアクションはユーザキャラクタ（他のユーザに対応するキャラクタを含む）によって実行されてもよいし、コンピュータ制御のキャラクタによって実行されてもよい。例えば、本発明のゲームシステムの一態様として、前記ユーザキャラクタが前記一つのキャラクタとして機能する場合に、前記ユーザキャラクタによる前記アクションに対応して前記対応アクションを実行するように前記他のキャラクタを制御するキャラクタ制御手段（４３）を備える態様が採用されてもよい。この場合、連携状態の形成のためのアクションが実行された場合に他のキャラクタは対応アクションを実行するように制御される。これにより、ユーザキャラクタによるアクションを契機に、積極的に連携状態を形成することができる。このため、開始条件具備の時期をユーザの都合に合わせることができる。

　パフォーマンスにおいて各キャラクタの動作は適宜に制御されてよく、例えば全てコンピュータによって制御されてもよいし、ユーザキャラクタ以外のキャラクタのみコンピュータによって制御されてもよい。また、コンピュータ制御のキャラクタは、適宜に動作してよく、予め決められた所定の動作（固定的な動作、及び各種条件により変化する動作の両方を含む）を実行してもよい。さらに、そのような動作は一つであっても、複数であってもよい。具体的には、例えば、他のキャラクタが対応アクションを実行するように自動制御される態様として、前記パフォーマンスにおける前記ユーザキャラクタの動作が前記プレイ行為を通じて制御される場合に、前記他のキャラクタと当該他のキャラクタが前記パフォーマンスにおいて実行すべき動作の候補として複数の動作とが関連付けられるように記述された候補データ（ＯＤ）に基づいて、前記複数の動作のうち前記パフォーマンスにおいて前記他のキャラクタが実際に実行すべき動作を選択するための選択機会を提供する機会提供手段（４３）を備える態様が採用されてもよい。

　あるいは、コンピュータ制御のキャラクタは、そのキャラクタが過去にユーザキャラクタとしてプレイに使用された実績がある場合、そのプレイにおいてユーザ（今回ゲームをプレイするユーザのみならず、その他のユーザを含んでいてよい）のプレイ行為に応じて実行された動作を実行してもよい。具体的には、選択機会が提供される本発明の態様において、前記ゲームは、各ユーザによって前記複数のキャラクタから前記ユーザキャラクタが選択されるように提供され、前記複数の動作は、前記他のキャラクタが前記ユーザキャラクタとして過去に各ユーザによって選択された実績が存在する場合に、当該実績において前記他のキャラクタが実行した動作を含んでいてもよい。この場合、パフォーマンスにおけるユーザキャラクタ以外の他のキャラクタの動作に過去のユーザのプレイ実績を反映することができる。

　連携状態を形成するためのアクション、及び対応アクションとして、各種のアクションが適宜に採用されてよい。例えば、頭、手、或いは脚といったキャラクタの各部位を動作させる各種のアクションが、連携状態を形成するためのアクション、或いは対応アクションとして適宜に利用されてもよい。また、発声、或いはアイコンタクトといったアクションが、連携状態を形成するためのアクション、或いは対応アクションとして適宜に利用されてもよい。具体的には、例えば、本発明のゲームシステムの一態様において、前記連携状態は、前記一つのキャラクタに設定される視野範囲（ＩＲ）に前記他のキャラクタを入れる動作が前記アクションとして、前記他のキャラクタに設定される視野範囲（ＩＲ）に前記一つのキャラクタを入れる動作が前記対応アクションとして、それぞれ機能するように、前記一つのキャラクタの視野範囲に含まれる前記他のキャラクタが当該他のキャラクタの視野範囲に前記一つのキャラクタを入れた場合に形成されてもよい。この場合、呼吸を合わせるプロセスの模倣として、ユーザキャラクタと他のキャラクタとにアイコンタクトに対応する動作を実行させることができる。

　開始条件は連携状態の形成のみを要件として含んでいてもよいし、各種の他の要件を適宜に含んでいてもよい。そのような他の要件として、ユーザのプレイ行為、プレイ状況、或いはゲームの都合等の適宜の条件が利用されてよい。例えば、本発明のゲームシステムの一態様において、前記開始条件は、前記連携状態において前記一つのキャラクタによって実行されるべき特別のアクションを更に要件に含み、前記連携状態において前記特別のアクションが実行された場合に満たされてもよい。

　パフォーマンスは、適宜のパートを含んでいてよく、例えばパフォーマンスを複数のキャラクタが実際に実行するパートのみならず、その他の各種のパートを適宜に含んでいてよい。具体的には、例えば、本発明のゲームシステムの一態様において、前記パフォーマンスは、当該パフォーマンスを前記複数のキャラクタが実際に実行するパフォーマンスパート、及び当該パフォーマンスパートの開始の時期を示すための準備パートを含み、前記進行制御手段は、前記開始条件の具備を契機に前記パフォーマンスの開始として前記準備パートを開始させることにより前記準備パートの後に前記パフォーマンスパートが開始されるように前記ゲームの進行を制御してもよい。

　ゲームとして、各種のゲームが適宜に提供されてよい。同様に、そのようなゲームでは、ゲームの種類に応じて複数のキャラクタによる各種のパフォーマンスが適宜に実行されてよい。例えば、サッカーゲーム、或いは野球ゲーム等のスポーツゲームにおけるゲームのプレイがパフォーマンスとして利用され、開始条件の具備を契機にキックオフやプレイボールが開始されてもよい。あるいは、音楽ゲームにおけるダンスや演奏等がパフォーマンスとして利用されてもよい。具体的には、例えば、本発明のゲームシステムの一態様において、前記ゲームとして、楽曲のリズムに合わせて前記ユーザが実行すべきプレイ行為の実行時期を案内するとともに、当該プレイ行為に伴い前記ユーザキャラクタが前記楽曲を演奏する演奏動作を実行する音楽ゲームが提供され、前記パフォーマンスとして、前記音楽ゲームでは前記複数のキャラクタの各キャラクタによる前記演奏動作が実行されてもよい。

　一方、本発明のコンピュータプログラム（ＰＧ２）は、前記入力装置、及び前記表示装置に接続されるコンピュータ（４１）を、上述のゲームシステムの各手段として機能させるように構成されたものである。

　また、本発明の制御方法は、ユーザのプレイ行為を入力するための入力装置（ＯＳ）、及び前記ユーザのプレイ行為を通じて操作されるキャラクタとしてのユーザキャラクタ（５４Ｃ）を含む複数のキャラクタ（５４）が含まれるようにゲーム画面（５０）を表示する表示装置（４７）に接続され、前記複数のキャラクタが実行するパフォーマンスを含むゲームを提供するゲームシステム（４）に組み込まれるコンピュータ（４１）に、前記複数のキャラクタのうちの少なくとも一つのキャラクタ（５４Ｃ）が実行したアクションに対応する所定のアクションとしての対応アクションを他のキャラクタ（５４Ｂ）が実行した場合に前記一つのキャラクタと前記他のキャラクタとの間に少なくとも形成される連携状態の形成を要件に含む開始条件が満たされるか否か判別する条件判別手順と、前記開始条件が満たされた場合に当該開始条件の具備を契機に前記パフォーマンスが開始される一方で、前記開始条件が満たされるまで前記パフォーマンスの開始が待機されるように前記ゲームの進行を制御する進行制御手順と、を実行させるものである。本発明のコンピュータプログラム、或いは制御方法を通じて、本発明のゲームシステムを実現することができる。

　１　ゲームシステム
　２　センターサーバ
　４　ＨＭＤ型のゲーム機（ゲームシステム）
　４１　制御ユニット（コンピュータ）
　４３　進行制御部（条件判別手段、進行制御手段、キャラクタ制御手段、機会提供手段）
　４７　ディスプレイ（表示装置）
　５０　ゲーム画面
　５４　キャラクタ画像（キャラクタ）
　５４Ｂ　第２キャラクタ画像（他のキャラクタ）
　５４Ｃ　第３キャラクタ画像（ユーザキャラクタ、一つのキャラクタ）
　ＩＲ　視野範囲
　ＯＳ　操作スティック（入力装置）

Claims

　ユーザのプレイ行為を入力するための入力装置、及び前記ユーザのプレイ行為を通じて操作されるキャラクタとしてのユーザキャラクタを含む複数のキャラクタが含まれるようにゲーム画面を表示する表示装置に接続され、前記複数のキャラクタが実行するパフォーマンスを含むゲームを提供するゲームシステムであって、
　前記複数のキャラクタのうちの少なくとも一つのキャラクタが実行したアクションに対応する所定のアクションとしての対応アクションを他のキャラクタが実行した場合に前記一つのキャラクタと前記他のキャラクタとの間に少なくとも形成される連携状態の形成を要件に含む開始条件が満たされるか否か判別する条件判別手段と、
　前記開始条件が満たされた場合に当該開始条件の具備を契機に前記パフォーマンスが開始される一方で、前記開始条件が満たされるまで前記パフォーマンスの開始が待機されるように前記ゲームの進行を制御する進行制御手段と、
を備える、ゲームシステム。
　前記ユーザキャラクタが前記一つのキャラクタとして機能する場合に、前記ユーザキャラクタによる前記アクションに対応して前記対応アクションを実行するように前記他のキャラクタを制御するキャラクタ制御手段を備える、請求項１のゲームシステム。
　前記パフォーマンスにおける前記ユーザキャラクタの動作が前記プレイ行為を通じて制御される場合に、前記他のキャラクタと当該他のキャラクタが前記パフォーマンスにおいて実行すべき動作の候補として複数の動作とが関連付けられるように記述された候補データに基づいて、前記複数の動作のうち前記パフォーマンスにおいて前記他のキャラクタが実際に実行すべき動作を選択するための選択機会を提供する機会提供手段を備える、請求項２のゲームシステム。
　前記ゲームは、各ユーザによって前記複数のキャラクタから前記ユーザキャラクタが選択されるように提供され、
　前記複数の動作は、前記他のキャラクタが前記ユーザキャラクタとして過去に各ユーザによって前記ゲームのプレイに使用された実績が存在する場合に、当該実績において前記他のキャラクタが実行した動作を含んでいる、請求項３のゲームシステム。
　前記連携状態は、前記一つのキャラクタに設定される視野範囲に前記他のキャラクタを入れる動作が前記アクションとして、前記他のキャラクタに設定される視野範囲に前記一つのキャラクタを入れる動作が前記対応アクションとして、それぞれ機能するように、前記一つのキャラクタの視野範囲に含まれる前記他のキャラクタが当該他のキャラクタの視野範囲に前記一つのキャラクタを入れた場合に形成される、請求項１～４のいずれか一項のゲームシステム。
　前記開始条件は、前記連携状態において前記一つのキャラクタによって実行されるべき特別のアクションを更に要件に含み、前記連携状態において前記特別のアクションが実行された場合に満たされる、請求項１～５のいずれか一項のゲームシステム。
　前記パフォーマンスは、当該パフォーマンスを前記複数のキャラクタが実際に実行するパフォーマンスパート、及び当該パフォーマンスパートの開始の時期を示すための準備パートを含み、
　前記進行制御手段は、前記開始条件の具備を契機に前記パフォーマンスの開始として前記準備パートを開始させることにより前記準備パートの後に前記パフォーマンスパートが開始されるように前記ゲームの進行を制御する、請求項１～６のいずれか一項のゲームシステム。
　前記ゲームとして、楽曲のリズムに合わせて前記ユーザが実行すべきプレイ行為の実行時期を案内するとともに、当該プレイ行為に伴い前記ユーザキャラクタが前記楽曲を演奏する演奏動作を実行する音楽ゲームが提供され、
　前記パフォーマンスとして、前記音楽ゲームでは前記複数のキャラクタの各キャラクタによる前記演奏動作が実行される、請求項１～７のいずれか一項のゲームシステム。
　前記入力装置、及び前記表示装置に接続されるコンピュータを、請求項１～８のいずれか一項のゲームシステムの各手段として機能させるように構成されたコンピュータプログラム。
　ユーザのプレイ行為を入力するための入力装置、及び前記ユーザのプレイ行為を通じて操作されるキャラクタとしてのユーザキャラクタを含む複数のキャラクタが含まれるようにゲーム画面を表示する表示装置に接続され、前記複数のキャラクタが実行するパフォーマンスを含むゲームを提供するゲームシステムに組み込まれるコンピュータに、
　前記複数のキャラクタのうちの少なくとも一つのキャラクタが実行したアクションに対応する所定のアクションとしての対応アクションを他のキャラクタが実行した場合に前記一つのキャラクタと前記他のキャラクタとの間に少なくとも形成される連携状態の形成を要件に含む開始条件が満たされるか否か判別する条件判別手順と、
　前記開始条件が満たされた場合に当該開始条件の具備を契機に前記パフォーマンスが開始される一方で、前記開始条件が満たされるまで前記パフォーマンスの開始が待機されるように前記ゲームの進行を制御する進行制御手順と、
を実行させる、制御方法。