IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社コナミデジタルエンタテインメントの特許一覧

特開2022-102913ゲームシステム、それに用いるコンピュータプログラム、及び制御方法
<>
  • 特開-ゲームシステム、それに用いるコンピュータプログラム、及び制御方法 図1
  • 特開-ゲームシステム、それに用いるコンピュータプログラム、及び制御方法 図2
  • 特開-ゲームシステム、それに用いるコンピュータプログラム、及び制御方法 図3
  • 特開-ゲームシステム、それに用いるコンピュータプログラム、及び制御方法 図4
  • 特開-ゲームシステム、それに用いるコンピュータプログラム、及び制御方法 図5
  • 特開-ゲームシステム、それに用いるコンピュータプログラム、及び制御方法 図6
  • 特開-ゲームシステム、それに用いるコンピュータプログラム、及び制御方法 図7
  • 特開-ゲームシステム、それに用いるコンピュータプログラム、及び制御方法 図8
  • 特開-ゲームシステム、それに用いるコンピュータプログラム、及び制御方法 図9
  • 特開-ゲームシステム、それに用いるコンピュータプログラム、及び制御方法 図10
  • 特開-ゲームシステム、それに用いるコンピュータプログラム、及び制御方法 図11
  • 特開-ゲームシステム、それに用いるコンピュータプログラム、及び制御方法 図12
  • 特開-ゲームシステム、それに用いるコンピュータプログラム、及び制御方法 図13
  • 特開-ゲームシステム、それに用いるコンピュータプログラム、及び制御方法 図14
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022102913
(43)【公開日】2022-07-07
(54)【発明の名称】ゲームシステム、それに用いるコンピュータプログラム、及び制御方法
(51)【国際特許分類】
   A63F 13/48 20140101AFI20220630BHJP
   A63F 13/847 20140101ALI20220630BHJP
   A63F 13/814 20140101ALI20220630BHJP
   A63F 13/798 20140101ALI20220630BHJP
【FI】
A63F13/48
A63F13/847
A63F13/814
A63F13/798
【審査請求】未請求
【請求項の数】10
【出願形態】OL
(21)【出願番号】P 2020217979
(22)【出願日】2020-12-25
(71)【出願人】
【識別番号】506113602
【氏名又は名称】株式会社コナミデジタルエンタテインメント
(74)【代理人】
【識別番号】100099645
【弁理士】
【氏名又は名称】山本 晃司
(74)【代理人】
【識別番号】100161090
【弁理士】
【氏名又は名称】小田原 敬一
(72)【発明者】
【氏名】佐原 祐
(72)【発明者】
【氏名】宮▲崎▼ 泰地
(57)【要約】
【課題】パフォーマンスの開始前に、複数人によるパフォーマンスにおいて実行される呼吸を合わせるプロセスと同様のプロセスをゲームの複数のキャラクタに実行させることができるゲームシステムを提供する。
【解決手段】HMD型のゲーム機4は、ユーザによって操作されるユーザキャラクタ54Cを含む複数のキャラクタ54が演奏動作を実行する演奏パフォーマンスを含む音楽ゲームを提供する。また、HMD型のゲーム機4は、ユーザキャラクタ54Cが実行した連携アクションに応答する応答アクションを、他のキャラクタ54Bが実行した場合にユーザキャラクタ54Cと他のキャラクタ54Bとの間に形成される連携状態の形成を要件に含む開始条件が満たされるか否か判別し、開始条件が満たされた場合にその開始条件の具備を契機に演奏パフォーマンスを開始させる一方で、開始条件が満たされるまで演奏パフォーマンスの開始を待機させる。
【選択図】図6
【特許請求の範囲】
【請求項1】
ユーザのプレイ行為を入力するための入力装置、及び前記ユーザのプレイ行為を通じて操作されるキャラクタとしてのユーザキャラクタを含む複数のキャラクタが含まれるようにゲーム画面を表示する表示装置に接続され、前記複数のキャラクタが実行するパフォーマンスを含むゲームを提供するゲームシステムであって、
前記複数のキャラクタのうちの少なくとも一つのキャラクタが実行したアクションに対応する所定のアクションとしての対応アクションを他のキャラクタが実行した場合に前記一つのキャラクタと前記他のキャラクタとの間に少なくとも形成される連携状態の形成を要件に含む開始条件が満たされるか否か判別する条件判別手段と、
前記開始条件が満たされた場合に当該開始条件の具備を契機に前記パフォーマンスが開始される一方で、前記開始条件が満たされるまで前記パフォーマンスの開始が待機されるように前記ゲームの進行を制御する進行制御手段と、
を備える、ゲームシステム。
【請求項2】
前記ユーザキャラクタが前記一つのキャラクタとして機能する場合に、前記ユーザキャラクタによる前記アクションに対応して前記対応アクションを実行するように前記他のキャラクタを制御するキャラクタ制御手段を備える、請求項1に記載のゲームシステム。
【請求項3】
前記パフォーマンスにおける前記ユーザキャラクタの動作が前記プレイ行為を通じて制御される場合に、前記他のキャラクタと当該他のキャラクタが前記パフォーマンスにおいて実行すべき動作の候補として複数の動作とが関連付けられるように記述された候補データに基づいて、前記複数の動作のうち前記パフォーマンスにおいて前記他のキャラクタが実際に実行すべき動作を選択するための選択機会を提供する機会提供手段を備える、請求項2に記載のゲームシステム。
【請求項4】
前記ゲームは、各ユーザによって前記複数のキャラクタから前記ユーザキャラクタが選択されるように提供され、
前記複数の動作は、前記他のキャラクタが前記ユーザキャラクタとして過去に各ユーザによって前記ゲームのプレイに使用された実績が存在する場合に、当該実績において前記他のキャラクタが実行した動作を含んでいる、請求項3に記載のゲームシステム。
【請求項5】
前記連携状態は、前記一つのキャラクタに設定される視野範囲に前記他のキャラクタを入れる動作が前記アクションとして、前記他のキャラクタに設定される視野範囲に前記一つのキャラクタを入れる動作が前記対応アクションとして、それぞれ機能するように、前記一つのキャラクタの視野範囲に含まれる前記他のキャラクタが当該他のキャラクタの視野範囲に前記一つのキャラクタを入れた場合に形成される、請求項1~4のいずれか一項に記載のゲームシステム。
【請求項6】
前記開始条件は、前記連携状態において前記一つのキャラクタによって実行されるべき特別のアクションを更に要件に含み、前記連携状態において前記特別のアクションが実行された場合に満たされる、請求項1~5のいずれか一項に記載のゲームシステム。
【請求項7】
前記パフォーマンスは、当該パフォーマンスを前記複数のキャラクタが実際に実行するパフォーマンスパート、及び当該パフォーマンスパートの開始の時期を示すための準備パートを含み、
前記進行制御手段は、前記開始条件の具備を契機に前記パフォーマンスの開始として前記準備パートを開始させることにより前記準備パートの後に前記パフォーマンスパートが開始されるように前記ゲームの進行を制御する、請求項1~6のいずれか一項に記載のゲームシステム。
【請求項8】
前記ゲームとして、楽曲のリズムに合わせて前記ユーザが実行すべきプレイ行為の実行時期を案内するとともに、当該プレイ行為に伴い前記ユーザキャラクタが前記楽曲を演奏する演奏動作を実行する音楽ゲームが提供され、
前記パフォーマンスとして、前記音楽ゲームでは前記複数のキャラクタの各キャラクタによる前記演奏動作が実行される、請求項1~7のいずれか一項に記載のゲームシステム。
【請求項9】
前記入力装置、及び前記表示装置に接続されるコンピュータを、請求項1~8のいずれか一項に記載のゲームシステムの各手段として機能させるように構成されたコンピュータプログラム。
【請求項10】
ユーザのプレイ行為を入力するための入力装置、及び前記ユーザのプレイ行為を通じて操作されるキャラクタとしてのユーザキャラクタを含む複数のキャラクタが含まれるようにゲーム画面を表示する表示装置に接続され、前記複数のキャラクタが実行するパフォーマンスを含むゲームを提供するゲームシステムに組み込まれるコンピュータに、
前記複数のキャラクタのうちの少なくとも一つのキャラクタが実行したアクションに対応する所定のアクションとしての対応アクションを他のキャラクタが実行した場合に前記一つのキャラクタと前記他のキャラクタとの間に少なくとも形成される連携状態の形成を要件に含む開始条件が満たされるか否か判別する条件判別手順と、
前記開始条件が満たされた場合に当該開始条件の具備を契機に前記パフォーマンスが開始される一方で、前記開始条件が満たされるまで前記パフォーマンスの開始が待機されるように前記ゲームの進行を制御する進行制御手順と、
を実行させる、制御方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ユーザのプレイ行為を入力するための入力装置、及びユーザのプレイ行為を通じて操作されるキャラクタとしてのユーザキャラクタを含む複数のキャラクタが含まれるようにゲーム画面を表示する表示装置に接続され、その複数のキャラクタが実行するパフォーマンスを含むゲームを提供するゲームシステム等に関する。
【背景技術】
【0002】
ユーザのプレイ行為を入力するための入力装置、及びユーザのプレイ行為を通じて操作されるキャラクタとしてのユーザキャラクタを含む複数のキャラクタが含まれるようにゲーム画面を表示する表示装置に接続され、その複数のキャラクタが実行するパフォーマンスを含むゲームを提供するゲームシステムが存在する。このようなゲームとして、バンドのボーカルになりきってボーカル演奏を行う音楽ゲームを提供するゲームシステムが知られている(例えば特許文献1参照)。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特許第6727807号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
複数人による現実のパフォーマンスでは、アイコンタクト等を通じてそれらの複数人の間で呼吸を合わせてパフォーマンスが開始される場合も多い。このため、このような呼吸を合わせるプロセスには臨場感、或いは一体感を向上させる効果が期待される。一方、特許文献1の音楽ゲームでは、自分の歌とバンドメンバーの演奏とによるライブパフォーマンスが実現される。この音楽ゲームでは、プレーヤの開始アクション(ハンドアクション)の入力で演奏がスタートし、ライブシーケンスに移行する。つまり、この音楽ゲームでは、プレーヤのハンドアクションによりライブパフォーマンスが開始される。しかし、これは演奏再生ボタンを押す代わりとして開始アクションが利用されているに過ぎず、複数のキャラクタ間において呼吸を合わせるといった類いのプロセスではない。このため、ゲーム内のパフォーマンスに対する臨場感等を向上させる余地がある。
【0005】
そこで、本発明は、パフォーマンスの開始前に、複数人によるパフォーマンスにおいて実行される呼吸を合わせるプロセスと同様のプロセスをゲームの複数のキャラクタに実行させることができるゲームシステム等を提供することを目的とする。
【課題を解決するための手段】
【0006】
本発明のゲームシステムは、ユーザのプレイ行為を入力するための入力装置、及び前記ユーザのプレイ行為を通じて操作されるキャラクタとしてのユーザキャラクタを含む複数のキャラクタが含まれるようにゲーム画面を表示する表示装置に接続され、前記複数のキャラクタが実行するパフォーマンスを含むゲームを提供するゲームシステムであって、前記複数のキャラクタのうちの少なくとも一つのキャラクタが実行したアクションに対応する所定のアクションとしての対応アクションを他のキャラクタが実行した場合に前記一つのキャラクタと前記他のキャラクタとの間に少なくとも形成される連携状態の形成を要件に含む開始条件が満たされるか否か判別する条件判別手段と、前記開始条件が満たされた場合に当該開始条件の具備を契機に前記パフォーマンスが開始される一方で、前記開始条件が満たされるまで前記パフォーマンスの開始が待機されるように前記ゲームの進行を制御する進行制御手段と、を備えるものである。
【0007】
一方、本発明のコンピュータプログラムは、前記入力装置、及び前記表示装置に接続されるコンピュータを、上述のゲームシステムの各手段として機能させるように構成されたものである。
【0008】
また、本発明の制御方法は、ユーザのプレイ行為を入力するための入力装置、及び前記ユーザのプレイ行為を通じて操作されるキャラクタとしてのユーザキャラクタを含む複数のキャラクタが含まれるようにゲーム画面を表示する表示装置に接続され、前記複数のキャラクタが実行するパフォーマンスを含むゲームを提供するゲームシステムに組み込まれるコンピュータに、前記複数のキャラクタのうちの少なくとも一つのキャラクタが実行したアクションに対応する所定のアクションとしての対応アクションを他のキャラクタが実行した場合に前記一つのキャラクタと前記他のキャラクタとの間に少なくとも形成される連携状態の形成を要件に含む開始条件が満たされるか否か判別する条件判別手順と、前記開始条件が満たされた場合に当該開始条件の具備を契機に前記パフォーマンスが開始される一方で、前記開始条件が満たされるまで前記パフォーマンスの開始が待機されるように前記ゲームの進行を制御する進行制御手順と、を実行させるものである。
【図面の簡単な説明】
【0009】
図1】本発明の一形態に係るゲームシステムの概略構成を示す図。
図2】ゲームシステムの制御系の要部を示す機能ブロック図。
図3】ゲーム画面の一例を模式的に示す図。
図4】仮想三次元空間における各キャラクタの位置関係を説明するための説明図。
図5】視界範囲が図4の例の右傾斜範囲に移動した場合のゲーム画面の一例を模式的に示す図。
図6】演奏パフォーマンスの開始までの流れの一例を説明するための説明図。
図7】ゲーム画面に設定される視野範囲を説明するための説明図。
図8】応答アクションの一例を説明するための説明図。
図9】他のキャラクタ画像の動作の変化の流れを説明するための説明図。
図10】演奏データの構成の一例を示す図。
図11】演奏選択処理の手順の一例を示すフローチャート。
図12】連携応答処理の手順の一例を示すフローチャート。
図13】楽曲開始処理の手順の一例を示すフローチャート。
図14】演奏データ生成処理の手順の一例を示すフローチャート。
【発明を実施するための形態】
【0010】
以下、本発明の一形態に係るゲームシステムの一例を説明する。まず、図1を参照して、本発明の一形態に係るゲームシステムの全体構成を説明する。ゲームシステム1は、サーバ装置としてのセンターサーバ2を含んでいる。なお、センターサーバ2は、複数のコンピュータ装置としてのサーバユニットが組み合わされることにより一台の論理的なサーバ装置として構成されてもよい。あるいは、クラウドコンピューティングを利用して論理的にセンターサーバ2が構成されてもよい。
【0011】
センターサーバ2には、ネットワーク3を介して接続可能なクライアント装置として一台、或いは複数台の適宜の数のゲーム装置が接続される。ゲーム装置は、アーケードゲーム機(アミューズメント店舗等の施設に設置され、所定の対価の支払いと引き換えにそのプレイ料金に対応した範囲でユーザにゲームをプレイさせる業務用ゲーム機)等の各種のゲーム機を適宜に含んでいてよいが、図1の例ではユーザ端末装置4が示されている。具体的には、センターサーバ2には、ゲーム装置の一例として、ネットワーク3を介して複数のユーザ端末装置4が接続されている。
【0012】
ユーザ端末装置4は、ネットワーク接続が可能でかつユーザの個人用途に供されるコンピュータ装置である。ユーザ端末装置4は、各種のコンピュータソフトウエアを実装することにより、センターサーバ2が提供する種々のサービスをユーザに享受させることが可能である。このようなコンピュータソフトウエア(アプリケーション)には、有償或いは無償のゲームを提供するためのゲーム用のアプリケーションが含まれる。そして、ユーザ端末装置4は、そのようなゲーム用のアプリケーションの実行を通じて、ゲーム機として機能する。このようなユーザ端末装置4は、例えば、据置型又はブック型のパーソナルコンピュータ、据置型の家庭用ゲーム機、或いは携帯型タブレット端末装置や携帯電話(スマートフォンを含む。)等の各種モバイル端末装置を含んでいる。ユーザ端末装置4として、これらが適宜に利用されてよいが、図1の例ではHMD(ヘッドマウントディスプレイ、或いはヘッドマウントデバイス)型のゲーム機が利用されている。
【0013】
HMD型のゲーム機は、ユーザの視界の大部分をディスプレイの表示面が占めるように頭部に装着されて使用される周知のゲーム装置である。HMD型のゲーム機には、例えばHMD型の専用のゲーム装置、携帯電話等の適宜のモバイル端末装置とユーザの視界を表示面に向けるようにそれを収容するケースとの組合せにより構成されるゲーム装置、及び眼球の奥に焦点が合うように映像を投影するメガネ型のプロジェクタ(いわゆるスマートグラス)が含まれる。また、HMD型の専用のゲーム装置には、タブレット端末装置、或いはスマートフォン等に接続され、それらのタブレット端末装置のアプリケーションを通じてゲーム機として機能する連動型のゲーム装置も含まれる。これらの各種のHMD型のゲーム機のいずれがユーザ端末装置4として利用されてもよい。以下、ユーザ端末装置4として機能するHMD型のゲーム機にはユーザ端末装置4と同様の符号を付して、HMD型のゲーム機4と呼ぶ場合がある。
【0014】
HMD型のゲーム機4には、ユーザのプレイ行為を入力するための各種の入力装置が適宜に設けられる。例えば、HMD型のゲーム機4には、頭部の動作をプレイ行為として検知するセンサが内蔵され、そのセンサが入力装置として機能してもよい。あるいは、HMD型のゲーム機4とは別の装置が適宜の手法でHMD型のゲーム機4に接続され、その別の装置が入力装置として機能してもよい。このようにHMD型のゲーム機4には、各種の入力装置が適宜に設けられてよいが、このような入力装置として図1の例では操作スティックOSが設けられている。操作スティックOSは、所定の無線通信規格を通じてHMD型のゲーム機4に接続される周知の入力装置である。操作スティックOSは各種の操作(プレイ行為)の入力に使用されてよく、それに応じて適宜の数の操作スティックOSが各HMD型のゲーム機4に接続されてよいが、一例として左右の手でそれぞれ操作されるように各HMD型のゲーム機4には二つの操作スティックOS(図1ではそれらのうちの一つのみが示されている)がそれぞれ接続される。HMD型のゲーム機4は、このような操作スティックOSを介して入力されるプレイ行為を通じて進行するゲームを提供する。
【0015】
HMD型のゲーム機4は、各種のゲームを適宜に提供してよく、例えばアクションゲーム、シミュレーションゲーム、ロールプレイングゲーム等を提供してよいが、一例として音楽ゲームを提供する。音楽ゲームは、タイミングゲームの一種である。タイミングゲームは、適切なプレイ行為の実行時期を評価するタイプのゲームである。音楽ゲームの場合、その適切なプレイ行為を実行すべき実行時期が楽曲とともに提供される。また、音楽ゲームでは、楽曲のリズムと一致する時期が実行時期として利用される。つまり、音楽ゲームは、適切なプレイ行為を実行すべき時期を楽曲のリズムに合わせてユーザに案内し、実際にプレイ行為が実行された時期を評価するタイプのゲームである。また、例えば、音楽ゲームにはプレイ用に複数の楽曲が用意され、そこから選択された楽曲が実際のプレイに使用される。そのような音楽ゲームは、各種の出力装置を介して適宜に提供されてよいが、一例としてディスプレイに表示されるゲーム画面を通じて提供される。
【0016】
また、HMD型のゲーム機4が提供するゲームは、複数のキャラクタ(車或いは動物等の各種の物を含む)、及びこれらの複数のキャラクタが実行するパフォーマンスを含んでいる。複数のキャラクタは、アクションゲーム等の種類に応じて各種のパフォーマンスを適宜に実行してよいが、音楽ゲームの場合、一例として楽器を演奏するパフォーマンス(以下、演奏パフォーマンス)を実行する。このため、ゲーム画面は、このような演奏パフォーマンスを実行する複数のキャラクタを含む場合がある。このようなゲーム画面の詳細は後述する。
【0017】
ネットワーク3は、センターサーバ2に対してHMD型のゲーム機4を接続させることができる限り、適宜に構成されてよい。一例として、ネットワーク3は、TCP/IPプロトコルを利用してネットワーク通信を実現するように構成される。典型的には、WANとしてのインターネットと、LANとしてのイントラネットと、を組み合わせてネットワーク3が構成される。図1の例では、センターサーバ2はルータ3aを介して、HMD型のゲーム機はアクセスポイント3bを介して、それぞれネットワーク3に接続されている。なお、ネットワーク3は、TCP/IPプロトコルを利用する形態に限定されない。ネットワーク3として、通信用の有線回線、或いは無線回線(赤外線通信、近距離無線通信等を含む)等を利用する各種の形態が利用されてよい。
【0018】
センターサーバ2は、ネットワーク3を介してHMD型のゲーム機4のユーザに各種のWebサービスを提供する。Webサービスは、各HMD型のゲーム機4に各種データ或いはソフトウエアを配信(データ等のアップデートを含む)する配信サービスを含んでいる。なお、Webサービスは、音楽ゲームが対戦型、或いは協力型のゲームとしてプレイされる場合においてネットワーク3を介して他のHMD型のゲーム機4のユーザ(対戦者、或いは協力者)をマッチングするマッチングサービス、及び各ユーザを識別するためのユーザIDを付与するサービス等の各種のサービスを適宜に含んでいてよい。
【0019】
次に、図2を参照してゲームシステム1の制御系の要部を説明する。まず、センターサーバ2には、制御ユニット21、及び記憶手段としての記憶部22が設けられる。制御ユニット21は、所定のコンピュータプログラムに従って各種の演算処理及び動作制御を実行するプロセッサの一例としてのCPUと、その動作に必要な内部メモリその他の周辺装置とを組み合わせたコンピュータとして構成されている。
【0020】
記憶部22は、ハードディスクアレイ等の不揮発性記憶媒体(コンピュータ読み取り可能な記憶媒体)を含んだ記憶ユニットによって実現される外部記憶装置である。記憶部22は、一の記憶ユニット上に全てのデータを保持するように構成されてもよいし、複数の記憶ユニットにデータを分散して記憶するように構成されてもよい。記憶部22には、ユーザに各種のサービスを提供するために必要な各種の処理を制御ユニット21に実行させるコンピュータプログラムの一例として、プログラムPG1が記録される。また、記憶部22には、各種のサービスの提供に必要なサーバ用データが記憶される。そのようなサーバ用データは、サービス用の各種のデータを含んでいるが、図2の例ではそのような各種のデータの一種として、楽曲データMD、シーケンスデータQD、プレイデータPD、及び演奏データODが示されている。
【0021】
楽曲データMDは、各楽曲を再生するためのデータである。楽曲データMDは、例えば音楽ゲームにおいて各楽曲の再生に使用される。シーケンスデータQDは、音楽ゲームにおいて適切なプレイ行為を実行すべき各実行時期が記述されたデータである。シーケンスデータQDは、このような各実行時期をユーザに案内するために使用される。また、ユーザによって実際にプレイ行為が実行された場合には、シーケンスデータQDの実行時期に基づいてそのプレイ行為が評価される。つまり、シーケンスデータQDは各実行時期の案内及びその評価に使用される。このため、シーケンスデータQDには、各実行時期、及びその実行時期に実行されるべき適切なプレイ行為の情報が互いに関連付けられるように記述される。また、音楽ゲームにおいて、複数の楽曲或いは複数の難易度が用意される場合には、シーケンスデータQDは楽曲毎或いは難易度毎に用意される。さらに、音楽ゲームは複数のキャラクタをプレイ対象に含むときには、選択されるキャラクタ(あるいは後述のようにキャラクタ毎に相違する楽器)に応じて各実行時期や適切なプレイ行為が相違する場合もある。このような場合、シーケンスデータQDはそのようなキャラクタ(あるいは楽器)毎にも用意される。プレイデータPDは、各ユーザの過去のプレイ実績に関する情報が記述されたデータである。プレイデータPDは、前回までのプレイ結果(過去の実績)を次回以降に引き継ぐため、或いは各ユーザに固有の設定内容を引き継ぐために使用される。演奏データODは、演奏パフォーマンスを実現するためのデータである。演奏データODの詳細は後述する。
【0022】
なお、サーバ用データは、その他にも各種のサービスを実現するための各種のデータを含んでよい。例えば、そのようなデータには、画像データ、或いはID管理データ等が含まれてよい。画像データはゲーム画面等の各種画像を表示装置に表示させるためのデータである。ID管理データは、ユーザID等の各種IDを管理するためのデータである。しかし、それらの図示は省略した。
【0023】
制御ユニット21には、制御ユニット21のハードウエア資源とソフトウエア資源としてのプログラムPG1との組合せによって実現される論理的装置として、Webサービス管理部24が設けられる。Webサービス管理部24は、HMD型のゲーム機4に対して上述のWebサービスを提供するための各種処理を実行する。
【0024】
一方、HMD型のゲーム機4には、制御ユニット41と、記憶手段としての記憶部42とが設けられる。所定のコンピュータプログラムに従って各種の演算処理及び動作制御を実行するプロセッサの一例としてのCPUと、その動作に必要な内部メモリその他の周辺装置とを組み合わせたコンピュータとして構成されている。
【0025】
記憶部42は、ハードディスク、半導体記憶装置といった不揮発性記憶媒体(コンピュータ読み取り可能な記憶媒体)を含んだ記憶ユニットによって実現される外部記憶装置である。記憶部42には、ユーザに各種のサービスを提供するために必要な各種の処理を制御ユニット41に実行させるコンピュータプログラムの一例として、プログラムPG2が記録される。また、記憶部42には、音楽ゲームの提供に必要なゲームデータが記録される。そのようなゲームデータには、音楽ゲーム用の各種のデータが含まれるが、図2の例ではその一例として楽曲データMD、シーケンスデータQD、プレイデータPD、及び演奏データODが示されている。
【0026】
楽曲データMD、シーケンスデータQD、プレイデータPD、及び演奏データODは、初期インストール、各種記憶媒体を通じた提供等の各種の手法により記憶部42に提供されてよいが、一例として配信サービスを通じてセンターサーバ2から提供される。なお、ゲームデータには、例えば、その他にも楽曲とは別の音声が存在する場合にそのような各種の音声を再生するための音声データ等、ゲーム用の各種のデータが含まれ得る。そのようなデータには、楽曲データMD等と同様に配信サービス等を通じて提供される画像データ、或いはID管理データ等が適宜に含まれ得る。しかし、これらの図示は省略した。
【0027】
制御ユニット41には、制御ユニット41のハードウエア資源とソフトウエア資源としてのプログラムPG2との組合せによって各種の論理的装置が構成される。そして、それらの論理的装置を通じて音楽ゲームの提供に必要な各種の処理(センターサーバ2のWebサービス管理部24が提供するWebサービスを享受するために必要な処理を含む)が実行されるが、図2の例では、音楽ゲームに関連する論理的装置として、進行制御部43、及びデータ管理部44が示されている。
【0028】
進行制御部43は、ゲームの進行に必要な各種の処理を行う論理的装置である。このような処理には、例えば、プレイのための各種準備を実行する処理、プレイ行為の各実行時期をユーザに案内する処理、或いはユーザが実行するプレイ行為を評価する処理も含まれる。また、プレイのための準備には各種設定等の適宜の要素が含まれるが、例えば選択機会の提供、及び各実行時期の案内開始の判別等が含まれる。具体的には、進行制御部43は、このような各種の処理の一例として、演奏選択処理、連携応答処理、及び楽曲開始処理を実行する。一方、データ管理部44は、記憶部42に記録されるゲームデータの管理に関する各種の処理を行う論理的装置である。例えば、データ管理部44は、センターサーバ2から提供されるゲームデータを取得したり記憶部42に保存したりする処理を実行する。例えば、データ管理部44は、このような各種の処理の一例として、演奏データ生成処理を実行する。演奏選択処理、連携応答処理、楽曲開始処理、及び演奏データ生成処理の手順の詳細は後述する。
【0029】
HMD型のゲーム機4には、各種の出力装置、及び入力装置が適宜に設けられ得るが、図2の例では出力装置の一例としてディスプレイ47、及びスピーカSPが、入力装置の一例としてセンサSMが、それぞれ設けられている。ディスプレイ47は、ゲーム画面等を表示するための周知の表示装置である。スピーカSPは、楽曲を含む各種音声を再生するための周知の音声再生装置である。センサSMは、HMD型のゲーム機4の各種の状態を検出するための周知の検出装置(検出手段)である。センサSMは検出対象の状態に応じた各種の検出装置を適宜に含んでいてよく、例えばユーザの視線をトラッキングするアイトラッキング用のセンサ等を適宜に含んでいてよいが、図2の例ではそのような各種のセンサの一例として加速度センサSM1、及びジャイロセンサSM2が示されている。
【0030】
加速度センサSM1は、HMD型のゲーム機4に生じる加速度(例えば三軸方向の加速度)を検出するための周知の検出装置である。このような加速度の検出を通じて加速度センサSM1は適宜に活用されてよいが、一例として水平状態、HMD型のゲーム機4の傾き、或いは向きといった状態の検出に使用される。同様に、ジャイロセンサSM2は、基準軸(一例として三軸)に対する角度の変化を検出するための周知の検出装置である。このような角度の検出を通じてジャイロセンサSM2は適宜に活用されてよいが、一例としてHMD型のゲーム機4の回転、傾き、或いは向きといった状態の検出に使用される。また、これらの加速度センサSM1及びジャイロセンサSM2の検出結果は、それぞれ単独で使用されてもよい(単独で使用される場合、いずれか一方は省略されてもよい)が、一例としてHMD型のゲーム機4の向き等の各種状態の検出に組み合わされて使用される。
【0031】
HMD型のゲーム機4には、その他にも各種の出力装置、或いは入力装置が適宜に接続され得るが、図2の例では上述の操作スティックOSが接続されている。操作スティックOSは上述のとおりであるが、制御ユニット41に接続され、プレイ行為に応じた各種の入力信号を制御ユニット41に出力する。
【0032】
次に、図3を参照して音楽ゲームをプレイするためのゲーム画面の一例について説明する。図3は、HMD型のゲーム機4のディスプレイ47に表示されるゲーム画面の一例を模式的に示す図である。音楽ゲームは各種のゲーム画面を含み得るが、図3の例はプレイ行為を実行すべき各実行時期を案内するためのゲーム画面を示している。また、音楽ゲームは適宜に構成されてよく、楽器の演奏を演出するようにプレイ行為に伴い楽器の演奏音が再生される場合も多い。このような場合、臨場感の向上のためにプレイ行為に伴い楽器の演奏動作を実行するキャラクタがゲーム画面に登場する場合もある。他のユーザ(協力者)、或いはコンピュータにそれぞれ対応する同様の複数のキャラクタが登場する場合もある。図3の例は、これらのキャラクタを含む場合のゲーム画面を示している。より具体的には、ユーザのプレイ行為に伴い、楽器の一例としてドラムを演奏する演奏動作を実行するキャラクタ、及び他のユーザ等のプレイ行為に伴い他の楽器を演奏する演奏動作を実行するキャラクタの両方を含むゲーム画面を示している。このようなゲーム画面は適宜に構成されてよいが、図3の例は仮想三次元空間を演出するように構成される場合を示している。さらに、このような仮想三次元空間は仮想カメラの撮影結果として適宜に切り取られてゲーム画面として表示されてよいが、図3の例はユーザに対応するキャラクタ(以下、ユーザキャラクタと呼ぶ場合がある)の視界を演出するように仮想三次元空間が切り取られ(概ねキャラクタの目の位置に設定された仮想カメラにより撮影され)、ゲーム画面として表示される場合を示している。この場合、ゲーム画面50は、指示用オブジェクト51、スコア表示領域52、ステージ領域53、キャラクタ画像54、及びドラムセット画像55を含んでいる。
【0033】
ドラムセット画像55は、楽器のドラムセットを模した画像である。ドラムセット画像55は、適宜のドラムセットに対応していてよいが、図3の例では二つのドラム画像55a、及び四つのシンバル画像55bを含んでいる。各ドラム画像55a、及び各シンバル画像55bは、それぞれドラムセットにおけるドラム、及びシンバルに対応する画像である。これらは実際のドラムセットと同様の配置に表示される。具体的には、二つのドラム画像55aは左右に並ぶようにドラムセット画像55において中央付近に配置される。一方、四つのシンバル画像55bは、ドラムセット画像55において二つのドラム画像55aを挟むようにそれらの左右に二つずつ配置される。また、左側の二つのシンバル画像55b、及び右側の二つのシンバル画像55bは、いずれもそれぞれ上下に分かれるように配置される。
【0034】
スコア表示領域52は、スコア(獲得得点)を表示するための領域である。スコア表示領域52は適宜に構成されてよいが、図3の例では正方形状に形成され、仮想三次元空間において奥側(ユーザ側が手前)に位置するように表示される。指示用オブジェクト51は、各実行時期に対応する画像(換言すれば各実行時期を示す標識画像)である。指示用オブジェクト51は、適宜の時期に仮想三次元空間における奥側の適宜の位置に出現し、手前側、つまりユーザに近づくように所定の移動経路に沿って移動する。このような移動経路は適宜に設定されてよいが、各ドラム画像55a、及び各シンバル画像55bのいずれかを通過するように設定される。各移動経路において各ドラム画像55a、及び各シンバル画像55bは現在時刻の基準を示す標識画像として機能する。このため、各指示用オブジェクト51は、そのような移動経路に沿って、対応する実行時期において各ドラム画像55a、及び各シンバル画像55bのいずれかと一致するように移動する。移動経路は表示されてもよいが、図3の例では移動経路は表示されていない。各実行時期は指示用オブジェクト51(指示用の標識画像)と各ドラム画像55a等(現在時刻の標識画像)のいずれかとの間の相対的変位を通じて適宜に案内されてよいが、一例としてこのような指示用オブジェクト51の各ドラム画像55a等への移動を通じて案内される。
【0035】
また、指示用オブジェクト51は各種に分類されてよいが、図3の例では第1指示用オブジェクト51A、及び第2指示用オブジェクト51Bの二種類を含んでいる。第1指示用オブジェクト51A、及び第2指示用オブジェクト51Bは、各実行時期において互いに異なるプレイ行為を要求する指示用オブジェクト51である。具体的には、第1指示用オブジェクト51A、及び第2指示用オブジェクト51Bはいずれも下側のシンバル画像55bを叩く動作をプレイ行為としてユーザに要求するが、第1指示用オブジェクト51Aは左側のシンバル画像55bに対する叩く動作の要求に、第2指示用オブジェクト51Bは右側のシンバル画像55bに対する叩く動作の要求に、それぞれ対応している。このため、第1指示用オブジェクト51A、及び第2指示用オブジェクト51Bは適宜の位置に出現した後、各実行時期において、左右の下側のシンバル画像55bの位置とそれぞれ一致するように、手前側に向かって移動する。
【0036】
ユーザに要求される叩く動作は、操作スティックOSを通じて入力される。具体的には、例えば第1指示用オブジェクト51Aと右側の下に位置するシンバル画像55bとの一致に合わせてユーザには、仮想三次元空間におけるそのシンバル画像55bの位置に対して叩く動作を実行するように操作スティックOSを振る動作が要求される。このため、このような各シンバル画像55b等への叩く動作が各実行時期における適切なプレイ行為として機能するように、シーケンスデータQDには、各指示用オブジェクト51の移動経路、或いはその移動経路上の各シンバル画像55b等の情報が適切なプレイ行為の情報として記述される。そして、その叩く動作の実際の実行時期と実際の一致時期(シーケンスデータQDに記述された実行時期)との間のずれ時間が少ないほど高く評価される。第2指示用オブジェクト51Bに関しても同様である。
【0037】
各ドラム画像55a等を叩く動作の判定は適宜に実現されてよいが、一例として次のように実現される。まず各ドラム画像55a、及び各シンバル画像55bは仮想三次元空間における空間座標で定義された所定位置に配置され、その所定位置(空間座標)の各ドラム画像55a等に向かって各指示用オブジェクト51は移動する。また、各ドラム画像55a等には、その所定位置を基準に評価範囲(各ドラム画像55a等と同一またはそれよりちょっと大きい範囲)が設定される。スティック画像56は操作スティックOSへの操作に伴い仮想三次元空間において移動するが、その先端部の位置(空間座標)が各ドラム画像55a、或いはシンバル画像55bの評価範囲に入ったか否かにより、叩く動作が実行されたか否か判別される。そして、その評価範囲にスティック画像56が入った時期(実際のプレイ行為の時期)と、各ドラム画像55a等に指示用オブジェクト51が到達すべき時期(シーケンスデータQDの実行時期)との間のずれ時間が算出され、そのずれ時間に応じて評価が決定される。この評価は適宜に実行されてよいが、一例としてパーフェクト、グレート、グッド、或いはバッドといった評価結果を示す基準を通じて実現される。また、各実行時期を基準に所定時間内に叩く動作が実行されなければ、ミス操作(ミスに対応する評価結果)として判定される。同様に、バッドに属する期間より早く、若しくは遅く、叩く動作が実行された場合、ミスと判定される。なお、これらのいずれにも属さない時期に叩く動作が実行された場合には、その動作は何にも使用されず、無視されてよい。
【0038】
指示用オブジェクト51は、その他にも左右の上側に位置するシンバル画像55bに対応する種類、各ドラム画像55aに対応する種類等の種類を含み、これらの種類を通じて第1指示用オブジェクト51Aと同様にドラム画像55a等を叩く動作を適宜に要求し得るが、図3の例ではそれらの表示は省略されている。また、第1指示用オブジェクト51A等の各種の指示用オブジェクト51は、適宜の形態で表示されてよいが、一例としていずれもシンバル画像55b等の移動経路上に位置する現在時刻の標識画像と同様の形状に表示される。同様に、第1指示用オブジェクト51A等の各種の指示用オブジェクト51は、互いに区別可能に適宜に表示されてよいが、一例として第1指示用オブジェクト51A、及び第2指示用オブジェクト51Bは互いに異なる配色で表示される。ドラムセット画像55における各ドラム画像55a等も同様である。例えば、各ドラム画像55aは互いに異なる配色で表示されてよい。この場合、プレイ対象をユーザが容易に識別できるように、各指示用オブジェクト51は、対応する各ドラム画像55a等と同じ色で表示されてよい。
【0039】
ステージ領域53は、仮想三次元空間に形成されるステージに対応する領域である。仮想三次元空間において各キャラクタは、そのステージにおいて演奏動作を実行する。このため、ステージ領域53には、各キャラクタに対応するキャラクタ画像54、及びドラムセット画像55が配置される。ステージ領域53には、適宜の数のキャラクタ画像54が配置されてよいが、図3の例では三つのキャラクタ画像54が表示されている。具体的には、キャラクタ画像54は、キーボードを演奏する第1キャラクタ画像54A、ギターを演奏する第2キャラクタ画像54B、及びドラムを演奏する第3キャラクタ画像54Cを含んでいる。これらのキャラクタ画像54A、54B、54Cは、仮想三次元空間においてキーボード、ギター、及びドラム(いずれも楽器の一例)を演奏するための一つの演奏ユニットを形成する三体のキャラクタにそれぞれ対応している。これらの三体のキャラクタは、ユーザ、及び協力者(コンピュータを含む)に適宜に対応してよく、それらのいずれのプレイ行為に基づいて演奏動作を実行してもよいが、一例として第1キャラクタ画像54A、及び第2キャラクタ画像54Bがコンピュータに、第3キャラクタ画像54Cがユーザに、それぞれ対応している。この例において、第1キャラクタ画像54A~第3キャラクタ画像54Cが本発明の複数のキャラクタとして機能する。
【0040】
第1キャラクタ画像54A~第3キャラクタ画像54Cは適宜に表示されてよいが、図3の例ではユーザキャラクタ(第3キャラクタ画像54C)の視界に対応するように、第1キャラクタ画像54A、及び第2キャラクタ画像54Bは全身が、第3キャラクタ画像54C(ユーザキャラクタ)は両手のみ(身体の一部のみ)が、それぞれ表示されている。また、仮想三次元空間においてユーザキャラクタがドラムを叩くためのスティックを握っている状況を示すように、第3キャラクタ画像54Cの左右の両手には二つのスティック画像56がそれぞれ表示されている。この場合、ユーザによる叩く動作の実行に伴い、第3キャラクタ画像54Cもその叩く動作を再現するように動作する。より具体的には、叩く動作の実行に伴い、第3キャラクタ画像54Cはスティック画像56において対象のシンバル画像55b等を叩く動作(演奏動作)を実行する。第1キャラクタ画像54A、及び第2キャラクタ画像54Bも同様である。つまり、協力者(コンピュータを含む)によるプレイ行為(対象の楽器、或いは入力装置の種類に応じて適宜でよいが、例えばキーボードの場合は鍵を弾く動作、ギターであれば弦を弾く動作)に伴い、第1キャラクタ画像54A、及び第2キャラクタ画像54Bも同様の演奏動作をゲーム画面50において実行する。
【0041】
図4図5を参照して、ゲーム画面50について更に説明する。図4は、仮想三次元空間における各キャラクタの位置関係を説明するための説明図である。図4の例は、仮想三次元空間におけるステージ、及び各キャラクタを上方から見た場合を模式的に示している。仮想三次元空間におけるステージ等は、ゲーム画面50におけるステージ領域53等に対応するため、図4の例では説明の便宜のためステージ、及び各キャラクタにはゲーム画面50におけるステージ領域53、及び各キャラクタ画像54等と同様の符号が付されている。
【0042】
図4に示すように、各キャラクタ画像54(仮想三次元空間における各キャラクタ)はステージ領域53(仮想三次元空間におけるステージ)に所定の間隔を開けて配置される。各キャラクタ画像54の位置、或いは間隔は、適宜でよく、可変的であってもよいが、一例として固定的である。つまり、各キャラクタ画像54はステージ領域53の予め決められた所定の位置にそれぞれ固定的に配置される。
【0043】
また、第3キャラクタ画像54Cはユーザキャラクタに対応する。このため、第3キャラクタ画像54Cには、視界範囲IAが設定される。視界範囲IAは、ゲーム画面50を描画するための仮想カメラの撮影範囲に対応する。視界範囲IAは適宜の範囲として設定されてよいが、図4の例では第3キャラクタ画像54Cが正面を向いている場合に設定される視界範囲IAが示されている。また、この視界範囲IAは第3キャラクタ画像54Cの動作、換言すればユーザの動作によって移動する。具体的には、HMD型のゲーム機4はユーザの頭部に装着され、プレイされるが、このユーザの頭部の動きに伴い、第3キャラクタ画像54Cの頭部も動作する。例えば、ユーザの頭部(HMD型のゲーム機4)が身体における正面を向いた状態が仮想空間内の視界範囲IAとなるように調整された場合、ユーザが正面を向いているとき、第3キャラクタ画像54Cの頭部も仮想三次元空間において同様の方向を向くため、視界範囲IAは図4の例において正面側(実線で表示される範囲)に設定される。
【0044】
一方、正面を向いた状態からユーザが右側を向いた場合、その頭部の動きはHMD型のゲーム機4のセンサSMにより検知され、第3キャラクタ画像54Cの動きに反映される。つまり、そのような頭部の動きに伴い、第3キャラクタ画像54Cの頭部も仮想三次元空間において同様の右を向くように動作する。この場合、視界範囲IAは、その頭部の動きに合わせて右方向に角度が変化する。具体的には、ユーザの右を向く頭部の動きに伴い、視界範囲IAは、一点鎖線で示す右傾斜範囲IA1に移動する。そして、このような右傾斜範囲IA1に含まれる仮想三次元空間がゲーム画面50として表示される。
【0045】
図5は、視界範囲IAが図4の例の右傾斜範囲IA1に移動した場合のゲーム画面50の一例を模式的に示す図である。また、図4の例は、図3の例からユーザが右斜め上方向を向いた場合のゲーム画面50にも対応している。このような上下方向への頭部の変化もセンサSMによって検出され、ゲーム画面50に反映される。このため、この場合、図5に示すように、図3の例と比べて、視界(視界範囲IA)の移動に伴い、第2キャラクタ画像54Bがゲーム画面50の中央近くに移動している一方で、第1キャラクタ画像54Aの表示が消えている。また、ステージ領域53、スコア表示領域52、及びドラムセット画像55にも同様の変化が生じている。
【0046】
次に、図6図10を参照して、音楽ゲームにおけるプレイの開始までの流れについて説明する。上述のようにユーザのプレイ行為(叩く動作)に伴い、ゲーム画面50においてキャラクタ画像54も同様の叩く動作、つまり演奏動作を実行する。このため、プレイの開始に伴い各キャラクタは演奏動作を実行する。ユーザキャラクタ以外の他のキャラクタ画像54もプレイの開始に伴い同様の演奏動作を実行する。そして、これらの演奏動作の組み合わせ、換言すれば一つの演奏ユニット全体による演奏動作により演奏パフォーマンスが形成される。結果として、プレイの開始は、演奏動作、及び演奏パフォーマンスの開始に対応する。このような演奏パフォーマンス、つまりゲームのプレイは、開始条件が満たされた場合に開始される。また、演奏パフォーマンスにおいて第1キャラクタ画像54A、及び第2キャラクタ画像54Bは、上述のように他のユーザによって操作されてもよいが、以下ではいずれもコンピュータによって操作(制御)される場合について説明する。
【0047】
図6は、演奏パフォーマンスの開始までの流れの一例を説明するための説明図である。図6に示すように、複数のキャラクタ画像54(キャラクタ)間に連携状態が形成された後に開始アクションが実行された場合に開始条件が満たされ、演奏パフォーマンス、つまりゲームのプレイが開始される。具体的には、ゲーム画面50において、プレイ(各指示用オブジェクト51による実行時期の案内)の開始前にまず各キャラクタ画像54は待機状態にて表示される。このような待機状態は適宜に表現されてよいが、コンピュータ制御のキャラクタの場合、所定の待機動作により表現される。このような待機動作として適宜の動作が実行されてよいが、例えば第2キャラクタ画像54Bの場合、ギターをチューニングする動作を実行する。待機状態において第1キャラクタ画像54Aも同様にキーボードを軽く弾く動作等の適宜の待機動作を実行するが、図6の例では説明の便宜のためその表示が省略されている。
【0048】
一方、ユーザによって操作される第3キャラクタ画像54C(他のユーザによって制御される場合、他のキャラクタも同様)にはユーザの動作(操作)が反映される。ユーザには、待機状態において各種の動作が許容されるが、そのような動作には連携アクションが含まれる。ユーザの連携アクションに伴い、第3キャラクタ画像54Cも同様の連携アクションを実行する。連携アクションは、第2キャラクタ画像54B及び第1キャラクタ画像54Aの両方が同時に対象となるように実行されてもよいが、一例として第2キャラクタ画像54B及び第1キャラクタ画像54Aのいずれか一方にそれぞれ個別に対応するように実行される。第3キャラクタ画像54Cが第2キャラクタ画像54Bに対して連携アクションを実行した場合、その動作の実行をコンピュータが判別し、その連携アクションに応答するための応答アクションを第2キャラクタ画像54Bに実行させる。そして、第2キャラクタ画像54Bによって応答アクションが実行された場合、第3キャラクタ画像54Cと第2キャラクタ画像54Bとの間には連携状態が形成される。この例において、第3キャラクタ画像54C、及び第2キャラクタ画像54Bが本発明の一つのキャラクタ、及び他のキャラクタとしてそれぞれ機能する。また、連携アクション、及び応答アクションが、本発明のアクション、及び対応アクションとしてそれぞれ機能する。
【0049】
連携状態は、第2キャラクタ画像54B及び第1キャラクタ画像54Aとの間に適宜に形成されてよい。例えば連携アクションが第2キャラクタ画像54B及び第1キャラクタ画像54Aの両方を対象に実行され、いずれか一方の応答アクションにより連携状態が形成される場合等、連携状態は第2キャラクタ画像54B及び第1キャラクタ画像54Aのいずれか一方(演奏ユニットの一部)との間に形成されれば演奏ユニット全体に形成されてもよいが、一例としてキャラクタ毎に個別に形成される。このため、第3キャラクタ画像54Cによる第1キャラクタ画像54Aに対する連携アクション、及びそれに応答する第1キャラクタ画像54Aによる応答アクションが、第3キャラクタ画像54Cと第1キャラクタ画像54Aとの間にも同様に実行される。そして、第3キャラクタ画像54Cが第2キャラクタ画像54B及び第1キャラクタ画像54Aの両方の間(換言すれば演奏ユニットの全体)に連携状態を形成した場合に、演奏ユニット全体が連携状態となる。連携アクションは、例えば第2キャラクタ画像54B等のユーザキャラクタ以外の他のキャラクタによって実行されてもよく、この場合、そのような連携アクションに対してユーザが応答アクションを返した場合に連携状態が形成されてもよい。このように連携アクションは適宜のキャラクタによって実行されてよいが、一例として図6の例のようにユーザキャラクタによって実行される。
【0050】
開始条件は、各種の要件を含んでいてよく、適宜に満たされてよいが、一例として演奏ユニット全体における連携状態の形成、及びその連携状態における開始アクションの実行を要件に含んでいる。このため、演奏ユニット全体の連携状態において第3キャラクタ画像54C(ユーザ)が開始アクションを実行した場合に開始条件が満たされる。そして、開始条件が満たされると演奏パフォーマンスが開始される。この例において、開始アクションが本発明の特別のアクションとして機能する。
【0051】
演奏パフォーマンスは、開始条件の具備を契機に適宜に開始されてよい。例えば、演奏パフォーマンスは音楽ゲームのプレイに対応し、音楽ゲームのプレイは楽曲のリズムに合わせた各実行時期の案内(指示用オブジェクト51の表示)によって実現されるため、楽曲の再生を含んでいる。このため、開始条件具備の直後、つまり開始アクションの直後にプレイ用の楽曲の再生が開始されてもよい。このように演奏パフォーマンスは適宜に開始されてよいが、一例として開始条件具備に伴いまず開始演出が実行される。つまり、演奏パフォーマンスは開始演出用のパート、及び実際に各キャラクタ画像54が演奏パフォーマンスを実行する演奏パートを含んでおり、開始条件の具備を契機にまず開始演出が開始される。
【0052】
開始演出は適宜に実現されてよいが、一例として楽曲再生までのカウントダウンとして機能するように実現される。このため、開始演出は、楽曲の再生にタイミングを合わせるための準備パートとして機能する。カウントダウンの機能は適宜に実現されてよいが、一例として各キャラクタ画像54に一定間隔毎に順にスポットライトが当てられる演出により実現される。つまり、開始アクションの後に各キャラクタ画像54に順にスポットライトが当てられる演出がまず開始され、全員にスポットライトが当たった後に楽曲の再生が開始される。そして、楽曲の再生に伴い、指示用オブジェクト51の表示が開始され、それに対する演奏動作(プレイ行為)も開始される。つまり、各キャラクタ画像54による実際の演奏動作(演奏パート)が開始される。この例において、準備パート、及び演奏パートが、本発明の準備パート、及びパフォーマンスパートとしてそれぞれ機能する。
【0053】
連携アクションは適宜のアクションであってよい。例えば、実際のバンド(演奏ユニット)によって演奏の開始時に実行されているように、ドラム担当がシンバル等を一定のリズムで軽く数回叩く動作が連携アクションとして採用されてもよい。あるいは、ユーザキャラクタが他のキャラクタに開始を呼びかけるような声かけ(発声)が連携アクションとして採用されてもよい。このように連携アクションとして各種のアクションが適宜に採用されてよいが、一例として対象のキャラクタに視線を向ける動作が採用される。また、このような視線を向ける動作は適宜に判別されてよく、例えば図5の例のように一つのキャラクタ画像54のみが視界範囲IAに含まれている場合にそのキャラクタ画像54に視線が向けられていると判別されてもよく、この場合視界範囲IAが視線を向ける動作の判別に使用されてよい。このように視線を向ける動作は適宜に判別されてよいが、一例として視界範囲IAの一部に視野範囲が設定され、その視野範囲に基づいて視線の向ける動作の有無が判別される。このため、ゲーム画面50(あるいは仮想三次元空間)には、ユーザの視線(ユーザキャラクタの視線)を判別するための視野範囲が設定される。
【0054】
図7は、ゲーム画面50に設定される視野範囲を説明するための説明図である。図7の例は、図5の例のゲーム画面50に設定される視野範囲を示している。図7に示すように、視野範囲IRは、中心視野範囲IR1、及び周辺視野範囲IR2を含んでいる。視野範囲IRはゲーム画面50の適宜の位置に形成されてよく、その位置は可変的であってもよい。また、視野範囲IRの位置がゲーム画面50において可変的に設定される場合、その位置は、例えばアイトラッキングによる視線のトラッキングといった各種の検出結果等を通じて適宜に設定されてよい。このように視野範囲IRはゲーム画面50に適宜に設定されてよいが、一例としてゲーム画面50(視界範囲)の中央付近に固定的に形成される。また、視野範囲IRは可視化されていてもよいが、一例として不可視に設定される。つまり、図7の例では便宜的に中心視野範囲IR1がドット柄で、周辺視野範囲IR2が右斜線で、それぞれ表示されているが、図5の例のように実際のゲーム画面50には視野範囲IRは表示されない。
【0055】
中心視野範囲IR1は、視線を向ける動作の判別に使用される範囲である。中心視野範囲IR1は適宜の形状に形成されてよいが、一例として所定の大きさの円形に形成される。また、視線を向ける動作の判別は、中心視野範囲IR1を利用して適宜に実現されてよく、例えば頭部等の主要部位が含まれている場合に視線を向けていると判別されてもよいが、一例として中心視野範囲IR1にキャラクタ画像54が一定割合以上含まれている(入っている)場合にそのキャラクタ画像54に視線を向けていると判別される。また、このような一定割合は適宜に設定されてよいが、一例として対象のキャラクタ画像54の半分以上の面積が利用される。例えば、図7の例では第2キャラクタ画像54Bの半分以上が、中心視野範囲IR1に入っている。この場合、ユーザキャラクタ(第3キャラクタ画像54C)は第2キャラクタ画像54Bに視線を向けていると判別される。
【0056】
一方、周辺視野範囲IR2は中心視野範囲IR1を含むようにその周囲に形成される領域である。周辺視野範囲IR2の形状も適宜に形成されてよいが、一例として中心視野範囲IR1を中央付近に含む所定の大きさの楕円形に形成される。周辺視野範囲IR2は適宜に利用されてよく、省略されてもよいが、一例として連携アクションの判別のための準備に使用される。具体的には、周辺視野範囲IR2にキャラクタ画像54が入ってきた場合にそのキャラクタ画像54に視線を向ける可能性があるとコンピュータは判別し、中心視野範囲IR1にキャラクタ画像54が含まれるか否か判別を開始する。一例として、このような視野範囲IRがゲーム画面50に設定され、連携アクションの実行の有無、つまりユーザのキャラクタ画像54が他のキャラクタ画像54に視線を向けているか否の判別が実現される。
【0057】
図8は、応答アクションの一例を説明するための説明図である。応答アクションとして、連携アクションに応じて、或いは連携アクションとは独立して各種の動作(反応)が適宜に採用されてよく、例えば各キャラクタが自己の楽器を軽く演奏する動作やサムアップ等の連携アクションの認識を示す各種の動作が採用されてよいが、この種の動作の一例として視線を向ける動作が利用される。つまり、ユーザキャラクタが連携アクションとして他のキャラクタに視線を向ける動作を実行した後、その他のキャラクタもそのユーザキャラクタに視線を向ける同様の動作を応答アクションとして実行する。図8の例は、応答アクションとしてこのような視線を向ける動作を実行する他のキャラクタ画像54の一例を模式的に示している。また、図8の例の(A)は応答アクション前のキャラクタ画像54を、(B)は応答アクション時のキャラクタ画像54を、それぞれ示している。
【0058】
図8の(A)に示すように、他のキャラクタ画像54(コンピュータによって制御されるキャラクタ)は、応答アクション前において正面側、つまり連携アクションとして視線を向けたキャラクタ画像54(ユーザ)の方向を向いていない。応答アクション前において他のキャラクタ画像54は適宜の方向を向いていてよく、例えば背中を向けるような方向を向いていてもよいが、図8の例では左方向に首を向け、視線も同様の左方向を向いている。一方、図8の(B)に示すように、その他のキャラクタ画像54は、応答アクション時には正面側に首を向け、視線も同様の正面側を向く。つまり、ユーザによって連携アクションとして視線を向ける動作が実行された場合(中心視野範囲IR1にキャラクタ画像54が一定割合以上含まれた場合)、その視線を向ける動作に応答してユーザに視線を返すように、他のキャラクタ画像54もユーザの方に同様の視線を向ける動作を実行する。これは他のキャラクタ画像54がユーザの方(正面側)に背中を向けていても(背中を向けるような方向を向いていても)同様である。つまり、応答アクション前の向きにかかわらず、他のキャラクタ画像54は応答アクションとしてユーザの方に視線を向ける動作を実行する。なお、演奏開始前はユーザが視線を他のキャラクタ画像54等に向けやすいように、ユーザに対して背中を向けることがないように他のキャラクタ画像54等の動きが制御されてもよい。
【0059】
他のキャラクタ画像54の視線の向きは適宜に判別されてよいが、一例として他のキャラクタ画像54にもユーザキャラクタと同様の視野範囲IRが設定され、視野範囲IRに入っているか否か、より具体的には視野範囲IRに中心視野範囲IR1にユーザキャラクタが一定割合以上入っているか否かに応じて判別される。また、このような視線を向ける動作(視線を返す動作)は、適宜のタイミングで実行されてよく、例えば連携アクションとは時差的に実行されてもよい。つまり、視線を向ける動作に対して視線を返す動作は、ユーザが視線を外した後において実行されてもよい。このように視線を返す動作は適宜のタイミングで実行されてよいが、一例として双方によるアイコンタクトが実現されるようにユーザが視線を向けている最中に実行される。この場合において、他のキャラクタ画像54が視線を向ける前にユーザが視線を外した場合、応答アクションは未完了と判断されてもよい(この場合、応答アクションのために再度連携アクションの実行が要求される)が、一例として他のキャラクタ画像54が視線を向ける動作の開始後であればユーザの視線を外す動作は許容される。一例として、連携アクションの対象となった(視線を向けられた)キャラクタ画像54は、このような応答アクションを実行する。
【0060】
図9は、連携アクションとして視線を向けられた他のキャラクタ画像54の動作の変化の流れを説明するための説明図である。そのような他のキャラクタ画像54として、例えば図3の例において第1キャラクタ画像54A等の適宜のキャラクタ画像54が機能してよいが、図9の例では図3の例の第2キャラクタ画像54Bが機能する場合を示している。この場合、図9に示すように、第2キャラクタ画像54Bはゲーム画面50においてまず上述のように待機状態を形成し、その待機(アイドル)状態において待機動作を実行する(S1)。また、第2キャラクタ画像54B(コンピュータ)は、待機状態においてユーザキャラクタ、つまり第3キャラクタ画像54Cが連携アクションを実行したか否か判別する(S2)。より具体的には、第2キャラクタ画像54Bは第3キャラクタ画像54Cが視線をこちらに向けているか否か(自己がユーザの中心視野範囲IR1に一定割合以上含まれているか否か)判別する。そして、第3キャラクタ画像54Cが視線をこちらに向けていない(自己がユーザの中心視野範囲IR1に一定割合以上含まれていない)場合、第2キャラクタ画像54Bは待機状態を継続する。
【0061】
一方、第3キャラクタ画像54Cが視線をこちらに向けている(自己が中心視野範囲IR1に一定割合以上含まれている)場合、第2キャラクタ画像54Bは第3キャラクタ画像54Cの方を振り向く振り向き動作(応答アクション)を実行する(S3)。応答アクションは、適宜に構成されてよく、振り向き動作(第3キャラクタ画像54Cの方に視線を向ける動作)のみによって構成されてもよいが、一例として応答ジェスチャも含んでいる。応答ジェスチャは、応答アクションの実行をユーザに伝えるための動作である。つまり、第2キャラクタ画像54Bは振り向き動作に続いて応答アクションの一つとして応答ジェスチャを実行する(S4)。このような応答ジェスチャとして、手を振る、親指と人差し指とで輪を作る(OKサイン)、頷く等の各種頭部の動作、或いは発声等が採用されてよいが、一例としてサムアップ(親指を立てる)動作が採用される。つまり、第2キャラクタ画像54Bは振り向き動作に続いて、或いはそれと同時にサムアップ動作を実行する。そして、第2キャラクタ画像54Bは、振り向き動作、及び応答ジェスチャの実行により応答アクションを完了し、連携状態を形成する。
【0062】
なお、連携状態の形成までの流れは適宜でよく、例えばユーザが他のキャラクタに視線を向け、他のキャラクタも視線を返した状態でユーザ(ユーザキャラクタ)がサムアップ動作などの適宜の動作を行い、これに対して更に他のキャラクタが同様のサムアップ動作等の適宜の動作を行った場合に連携状態は形成されてもよい。あるいは、これらの動作の一部が適宜に省略されてもよい。これらの場合において、連携状態を形成するために相互に実行し合う各種動作の一部が適宜に連携アクション、及び応答アクションとして機能してよい。開始条件も同様である。例えば、開始条件はユーザキャラクタと他の全キャラクタとの間に連携状態が形成された場合に満たされてもよい。つまり、開始条件は、開始アクションを要件に含んでいなくてもよい。この場合、開始演出は適宜に開始されてよいが、例えば最後の他のキャラクタとの間に連携状態が形成された直後に開始演出が実行される。また、操作スティックOSには、スティック画像56に対する操作と区別するために、サムアップ動作等の手の一部を利用する動作のための各種ボタンが適宜に設けられていてよい。あるいは、別途ユーザの全体(主要部位でもよい)を撮影するためのカメラが設けられてもよく、そのようなカメラによってサムアップ動作等の各種の部位の動作を含む適宜の動作が検出されてもよい。
【0063】
第2キャラクタ画像54Bは、連携状態(第1キャラクタ画像54Aとの連携状態の形成を待つ待機中)において適宜の動作を実行してよいが、一例として待機状態と同様に待機動作を実行する(S5)。また、第2キャラクタ画像54B等との連携状態(待機動作中)においてユーザによって開始アクションが実行されたか否か判別される(S6)。このような開始アクションとして各種の動作が適宜に機能してよいが、一例としてサムアップ動作が機能する。つまり、第2キャラクタ画像54B等との連携状態においてユーザによって開始アクションとしてサムアップ動作が実行されたか否か判別される。連携状態の形成から所定時間内にサムアップ動作、つまり開始アクションが実行されない場合、第2キャラクタ画像54Bは連携状態を解除して、再度待機状態に戻る。
【0064】
一方、連携状態の形成から所定時間内にサムアップ動作、つまり開始アクションが実行された場合、第2キャラクタ画像54Bはその開始アクションに対して応答ジェスチャを更に実行する(S7)。このような応答ジェスチャは省略されてもよいが、一例として実行される。また、この応答ジェスチャは応答アクションとしての応答ジェスチャと相違していてもよいが、一例として同様に構成される。つまり、第3キャラクタ画像54Cによる開始アクションに伴い、応答ジェスチャとして同様のサムアップ動作を実行する。第1キャラクタ画像54Aも同様の流れで動作が変化し、第3キャラクタ画像54Cとの間に連携状態等を形成する。
【0065】
開始条件の要件は、ユーザに対応するキャラクタ以外の全キャラクタとの間の連携状態における開始アクションのみであってもよいし、他の要件を含んでいてもよい。また、このような他の要件として第3キャラクタ画像54C以外の全キャラクタ画像54による応答ジェスチャ(S7)が機能してもよい。このように開始条件の要件は適宜であってよいが、一例として第1キャラクタ画像54A、及び第2キャラクタ画像54Bの両者から応答ジェスチャ(S7)が実行された後に演奏パフォーマンスが開始される。より具体的には、第1キャラクタ画像54A、及び第2キャラクタ画像54Bの両者からの応答ジェスチャ(S7)により開始条件が満たされ、開始演出が開始される。そして、開始演出によるカウントダウンの後に楽曲の再生、つまり演奏パートが開始される。一例として、このような流れで他のキャラクタの動作は変化し、演奏パフォーマンスは開始される。なお、ユーザキャラクタ以外のキャラクタがコンピュータによって制御される場合、開始アクションの実行に伴い、応答ジェスチャ(S7)も自動で実行される。このため、この場合、開始アクションの有無の判別が、開始条件が満たされるか否かの判別と同様に機能してよい。
【0066】
次に、演奏データODの詳細について説明する。第1キャラクタ画像54A、或いは第2キャラクタ画像54Bといった他のキャラクタ画像54による演奏動作(演奏パフォーマンス)がコンピュータによって制御される場合、他のキャラクタ画像54は適宜の演奏動作を実行してよく、予め設定された演奏動作(一つの動作であっても複数の動作出会ってもよい)を実行してもよいが、一例としてユーザが過去に他のキャラクタ画像54を通じてプレイしている場合にはそのプレイ時と同様の演奏動作を実行する。つまり、コンピュータは、そのプレイ時にユーザが行った演奏動作(プレイ実績)と同様の動作をトレースする(引き写す)ように他のキャラクタ画像54の動作を制御する。演奏データODは、このようなユーザの演奏動作の実績を他のキャラクタに実行させるためのデータである。例えば、ユーザが第2キャラクタ画像54Bを介してプレイした(プレイ用のキャラクタを選択するキャラクタ選択機会においてユーザキャラクタとして選択された)場合、そのプレイにおけるプレイ内容(第2キャラクタ画像54Bを介したギターの演奏動作の実績)が演奏データODに記録され、管理される。ユーザが第1キャラクタ画像54Aを介してプレイした場合の実績も同様である。
【0067】
図10は、演奏データODの構成の一例を示す図である。図10に示すように、動画データ部OD1、及び情報管理部OD2を含んでいる。動画データ部OD1は、他のキャラクタ画像54に演奏動作を実行させるための動画データとして構成される部分である。このような動画データ部は各種の動画データとして適宜に構成されてよいが、一例として各キャラクタ画像54の動作はモーションキャプチャーデータとして構成されるため、動画データ部も同様にモーションキャプチャーデータとして構成される。このモーションキャプチャーデータは適宜に生成されてよく、例えばユーザの全身を撮影するカメラからユーザのモーションを検出してデータ化してもよいし、ユーザの身体に付けられたマーカからその動きを検出してデータ化してもよい。このようにモーションキャプチャーデータ(動画データ部OD1)は適宜に生成されてよいが、一例としてHMD型のゲーム機4の時間経過による動き(頭部の動き)、及び操作スティックOSの時間経過による動きを記録し、それらをモーションに置換することにより生成される。動画データ部は演奏動作毎に用意される。一方、情報管理部OD2は、各動画データ部を管理するための情報が記述された部分である。情報管理部OD2は、各動画データ部の管理に必要な各種の情報を適宜に含み得るが、図10の例では動画データ部(演奏動作)毎にそれに関する情報を管理する演奏レコードODRを含んでいる。演奏レコードODRは、このような管理のために、“演奏ID”、“キャラクタ”、“楽曲”“ユーザID”、及び“日時”の情報を含んでいる。演奏レコードODRには、これらの情報が相互に関連付けられるように記録されている。また、この例において演奏データODが本発明の候補データとして機能する。
【0068】
“演奏ID”は、各演奏動作(動画データ部)を管理するために演奏動作毎にユニークな演奏IDを示す情報である。“キャラクタ”は、その演奏動作に対応するキャラクタを特定するための情報である。このような情報として各キャラクタを特定可能な適宜の情報が利用されてよいが、一例としてキャラクタ毎にユニークなキャラクタIDの情報が利用される。具体的には、例えば第3キャラクタ画像54Cを介してプレイした実績に対応する演奏動作の場合、その第3キャラクタ画像54Cに対応するキャラクタIDの情報が“キャラクタ”に記述される。第1キャラクタ画像54A等の場合も同様である。また、各キャラクタは演奏する楽器と対応付けられている。このため、“キャラクタ”の情報は演奏対象の楽器の情報としても機能する。このため、“キャラクタ”に代えて“楽器”の情報(例えば楽器のID)が記述されてもよい。“楽曲”は演奏動作の際に使用された楽曲を示す情報である。“楽曲”には各楽曲を特定可能な適宜の情報が記述されてよいが、一例として楽曲毎にユニークな楽曲IDの情報が記述される。“ユーザID”は、各ユーザを識別するためにユーザ毎にユニークなユーザIDを示す情報である。プレイ実績として使用可能な演奏動作は、各ユーザにとって自己のプレイ実績に限定されてもよいが、一例として他のユーザのプレイ実績も使用可能である。“日時”は各演奏動作の実績に対応するプレイの日時を示す情報である。なお、演奏データODは、これらの情報に限定されず、例えば演奏パフォーマンスの実現に必要な情報等を適宜に管理してよい。あるいは、これらの情報の一部が適宜に省略されてもよい。
【0069】
次に、演奏選択処理、連携応答処理、楽曲開始処理、及び演奏データ生成処理の手順について説明する。演奏選択処理は、ユーザキャラクタ以外の他のキャラクタに実行させるべき演奏動作を選択する演奏選択機会を提供するための処理である。例えば、ユーザが第3キャラクタ画像54Cを介して音楽ゲームをプレイする場合において、第1キャラクタ画像54A、及び第2キャラクタ画像54Bにそれぞれ実行させるべき演奏動作が演奏選択機会にて選択される。具体的には、同じキャラクタに対して複数のプレイ実績が存在する場合、演奏データODはその同じキャラクタに対して複数の動画データ部OD1(複数の演奏動作)を含んでいる。この場合、それらの複数の演奏動作の候補から他のキャラクタに実行させるべき演奏動作が演奏選択機会において選択される。図11の例は、このような演奏選択機会を提供するための手順の一例を示している。この場合、進行制御部43は、音楽ゲームのプレイに使用するキャラクタを選択するためのキャラクタ選択機会をユーザに提供する毎に図11の演奏選択処理を開始し、まずそのキャラクタ選択機会におけるキャラクタの選択結果を取得する(ステップS101)。
【0070】
続いて進行制御部43は、キャラクタ選択機会において選択したキャラクタ以外のキャラクタに実行させるべき演奏動作を選択するための演奏選択機会を提供する(ステップS102)。具体的には、進行制御部43は、演奏データODを参照し、対象のキャラクタ毎に複数の演奏動作の候補(他のユーザの演奏実績、及び予め用意された複数の所定の動作を含んでいてよい)から一つの演奏動作が選択されるように演奏選択機会を提供する。また、このような演奏選択機会は適宜に実現されてよいが、一例として演奏動作の選択に必要な情報を含む演奏選択機会用の選択画面(不図示)を通じて実現される。演奏動作の選択に必要な情報には、例えば、演奏動作の実績に対応するユーザ(誰の演奏動作であるか)、或いはそのユーザのレベルや得点等の各種成績に関する情報といった各種の情報が適宜に含まれていてよい。演奏選択機会における選択肢は、ユーザが選択した楽曲、楽器に対応して提示される。例えば、ユーザが選択した楽曲と同一の楽曲であって、ユーザが選択した楽器とは異なる楽器により生成された演奏データODが、演奏選択機会における選択肢としてユーザに提示される。選択肢の限定条件はこれ以外、例えば演奏データODが作成された期間等が適宜に含まれていてもよい。
【0071】
次に進行制御部43は、演奏選択機会における選択結果に基づいて他のキャラクタの演奏動作を決定する(ステップS103)。そして、この決定の後に進行制御部43は今回の演奏選択処理を終了する。これにより、ユーザキャラクタ以外の他のキャラクタに実行させるべき演奏動作を選択する演奏選択機会が実現される。また、演奏選択機会では、このような演奏動作の候補として、他のユーザのプレイ実績を含む複数の演奏動作の実績が提示される。このため、このような演奏選択機会を通じて、演奏パフォーマンスにおいて他のキャラクタに実際のプレイ実績に対応する演奏動作が実行される。
【0072】
連携応答処理は、各キャラクタに連携状態を形成させるための処理である。各キャラクタは他のユーザによって操作されてもよく、その場合連携状態の形成は他のユーザによって応答アクションが実行されたか否か判別され、応答アクションが実行された場合に形成されるが、図12の例はコンピュータ(進行制御部43)によって各キャラクタの動作が制御される場合を示している。この場合、進行制御部43は、ユーザキャラクタ(例えば図3の例の第3キャラクタ画像54C)が(周辺視野範囲IR2に他のキャラクタを含む状況において)ユーザによって操作される毎に図12の連携応答処理を開始し、まずそのユーザの操作が連携アクションに該当するか否か判別する(ステップS201)。一例として、そのユーザの操作が中心視野範囲IR1に他のキャラクタを一定割合以上含めるように視線を向ける動作に対応する場合、その操作(動作)は連携アクションに該当する。このため、進行制御部43は、そのユーザの操作が中心視野範囲IR1に他のキャラクタを一定割合以上含める動作に該当するか否か判別する。ユーザの操作が中心視野範囲IR1に他のキャラクタを一定割合以上含める動作(視線を向ける動作)に該当しない場合、つまりそのユーザの操作が連携アクションに該当しない場合、進行制御部43は以降の処理をスキップして今回の連携応答処理を終了する。
【0073】
一方、ユーザの操作が中心視野範囲IR1に他のキャラクタを一定割合以上含める動作(視線を向ける動作)に該当する場合、つまりそのユーザの操作が連携アクションに該当する場合、進行制御部43はその連携アクションの対象のキャラクタ、つまり中心視野範囲IR1に一定割合以上含まれるキャラクタに応答アクションを実行させる(ステップS202)。具体的には、例えば応答アクションとして上述のように視線を向ける(視線を返す)動作、及び応答ジェスチャ(サムアップ)が採用される場合、ユーザのキャラクタに視線を向ける動作を実行し、かつサムアップ動作を実行するように、対象のキャラクタの動作を制御する。
【0074】
続いて進行制御部43は、ユーザキャラクタとステップS202において応答アクションを実行させたキャラクタとの間に連携状態を形成させる(ステップS203)。連携状態の形成は適宜に実現されてよく、例えば専用の動作により連携状態が表現される場合にはそのような動作の実行により実現されてもよいが、一例として連携状態の有無を管理するためのフラグの更新により実現される。具体的には、各キャラクタには、連携状態の有無を管理するためのパラメータが設定される。このため、進行制御部43は、このフラグを連携状態の形成を示す状態に更新することにより連携状態の形成を実現する。そして、連携状態を形成した後に進行制御部43は今回の連携応答処理を終了する。これにより、他のキャラクタの動作が連携アクションに応じて応答アクションを実行するように制御される。つまり、ユーザキャラクタと他のキャラクタとの間に連携状態が積極的に形成されるように、他のキャラクタの動作が制御される。そして、連携状態が形成された場合には、その状態がフラグにより管理される。
【0075】
楽曲開始処理は、開始条件を契機に演奏パフォーマンス(各実行時期の案内)を開始させるための処理である。図13の例は、図9の流れで他のキャラクタが動作する場合に実行される楽曲開始処理を示している。この場合、進行制御部43は、ユーザによって開始アクションが実行される毎、及び連携状態の形成から所定時間経過毎に図13の楽曲開始処理を開始し、まず開始条件を満たすか否か判別する(ステップS301)。具体的には、上述のように一例として開始アクション(例えばサムアップ動作)が実行され、かつそれに応答する応答ジェスチャが実行された場合に開始条件は満たされる。このため、進行制御部43は、他のキャラクタの全部が応答ジェスチャを実行した場合に開始条件が満たされると判別してもよいが、応答ジェスチャは開始アクションの実行に伴いコンピュータ(進行制御部43)によって自動で実行されるため、一例としてユーザのキャラクタと他のキャラクタの全部との間に連携状態が形成された状況において開始アクションが実行された場合に開始条件が満たされたと判別する。
【0076】
開始条件が満たされない場合、進行制御部43は連携状態を解除するための解除条件が満たされるか否か判別する(ステップS302)。解除条件は適宜に満たされてよいが、一例として連携状態の形成から所定時間経過した場合に満たされる。このため、進行制御部43は、連携状態の形成から所定時間経過しているか否か判別する。解除条件が満たされない場合、つまり連携状態の形成から所定時間経過していない場合、連携状態を維持する(ステップS303)。つまり、進行制御部43は連携状態を示すフラグの状態をそのままの状態に維持する。一方、解除条件が満たされる場合、つまり連携状態の形成から所定時間経過した場合、進行制御部43は連携状態を解除する(ステップS304)。具体的には、進行制御部43は、連携状態を示すフラグの状態を非連携状態に対応するように変更する。そして、進行制御部43は、連携状態の維持、或いは連携状態の解除の後に、今回の楽曲開始処理を終了する。
【0077】
一方、ステップS301において開始条件が満たされる場合、つまり開始アクションがユーザキャラクタと他のキャラクタの全部との間に連携状態が形成された状況において実行された場合、進行制御部43は、開始演出を開始する(ステップS305)。具体的には、進行制御部43は、開始演出をゲーム画面50に表示する。続いて進行制御部43は、その開始演出の後に楽曲の再生、換言すれば演奏パートを開始させる(ステップS303)。そして、楽曲の再生を開始させた後に進行制御部43は今回の楽曲開始処理を終了する。これにより、ユーザキャラクタと他のキャラクタとの間の連携状態の形成を要件に含む開始条件の具備を契機に演奏パフォーマンスが開始される。より具体的には、ユーザキャラクタと他のキャラクタの全部との間に連携状態が形成された状況において開始アクションが実行された場合に開始条件が満たされ、演奏パフォーマンスの開始演出、つまり準備パートが開始される。そして、その開始演出の後に楽曲の再生、つまり演奏パートが開始される。
【0078】
演奏データ生成処理は、各ユーザのプレイ実績に基づいて演奏データODを生成するための処理である。演奏データODは適宜に生成されてよく、例えば一律に全ユーザの全プレイの実績に基づいて生成されてもよいが、一例としてユーザが演奏データODの生成を希望した場合に生成される。この場合、演奏データODの生成を希望したユーザ(別途生成の要否を確認するための機会が適宜にユーザに付与されてよい)のプレイにおいて演奏パートが開始されると、データ管理部44は図14の演奏データ生成処理を開始し、まず演奏パートにおけるユーザの操作、つまりユーザキャラクタの動作を記録する(ステップS401)。続いてデータ管理部44は、ステップS401の記録結果に基づいて演奏データODを生成する(ステップS402)。具体的には、データ管理部44は、ユーザキャラクタの動作を再現するための動画データ部OD1、及びそれに対応する各種情報を記録する情報管理部OD2を生成する。そして、演奏データODを生成した後にデータ管理部44は今回の演奏データ生成処理を終了する。これにより、各ユーザのプレイ実績に対応する演奏動作を再現するための演奏データODが生成される。なお、一律に演奏データODが生成され、ユーザが希望した場合やベストスコアが算出された場合等所定条件を満たした場合にそれが保存されてもよい。
【0079】
以上に説明したように、この形態によれば、連携状態は、ユーザキャラクタ(例えば第3キャラクタ画像54C)による連携アクションと、それに応答する他のキャラクタ(例えば第2キャラクタ画像54B)による応答アクションとにより形成される。このため、これらの連携アクション、及び応答アクションを通じてゲームの複数のキャラクタに呼吸を合わせるプロセスを模倣させることができる。より具体的には、ユーザキャラクタによって視線を向ける動作が実行された場合に、その視線を向けられた他のキャラクタによる視線を返す動作、及びサムアップ動作により連携状態が形成される。これにより、これらのユーザキャラクタと他のキャラクタとの間にアイコンタクトを通じて呼吸を合わせるプロセスを模倣させることができる。
【0080】
また、開始条件が満たされた場合に演奏パフォーマンスが開始される一方で、開始条件が満たされるまで演奏パフォーマンスの開始が待機される。そして、そのような演奏パフォーマンスの開始の契機とされる開始条件は、連携状態の形成を要件に含んでいる。つまり、連携状態の形成を経て演奏パフォーマンスは開始される。このため、演奏パフォーマンスの開始前に、複数人による実際の演奏パフォーマンスにおいて実行される呼吸を合わせるプロセス、より具体的にはアイコンタクトを通じて呼吸を合わせるプロセスと同様のプロセスをゲームの複数のキャラクタに実行させることができる。結果として、演奏パフォーマンスの臨場感、或いは一体感を向上させることができる。
【0081】
また、ユーザキャラクタによる連携アクションの実行に伴い、他のキャラクタがコンピュータによって応答アクションを実行するように制御される場合、ユーザキャラクタによる連携アクションを契機に、積極的に連携状態を形成することができる。このため、開始条件具備の時期をユーザの都合に合わせることができる。さらに、そのような他のキャラクタが演奏パフォーマンスにおいてユーザのプレイ実績をトレースするように動作する場合、演奏パフォーマンスにおけるユーザキャラクタ以外の他のキャラクタの動作に過去のユーザのプレイ実績、つまり演奏動作の実績を反映することができる。これにより、演奏パフォーマンスのリアリティ、ひいては臨場感を更に向上させることができる。また、このような演奏動作の実績の活用により、各ユーザによる他のキャラクタの使用、或いは他のユーザによる自己の演奏実績の利用を促すことができ、ひいてはゲームの利用を促進することもできる。
【0082】
以上の形態において、HMD型のゲーム機4の進行制御部43が、図13の楽曲開始処理を実行することにより本発明の条件判別手段、及び進行制御手段として機能する。具体的には、進行制御部43が、図13のステップS301を実行することにより条件判別手段として機能する。また、進行制御部43が、図13のステップS305、及びステップS303の処理を実行することにより進行制御手段として機能する。同様に、HMD型のゲーム機4の進行制御部43が、図12の連携応答処理においてステップS202を実行することにより本発明のキャラクタ制御手段として機能する。さらに、HMD型のゲーム機4の進行制御部43が、図11の演奏選択処理においてステップS102を実行することにより本発明の機会提供手段として機能する。
【0083】
本発明は上述した形態に限定されず、適宜の変形又は変更が施された形態にて実施されてよい。例えば、上述の形態では、図11図14の処理はHMD型のゲーム機4で実行されている。しかし、本発明は、このような形態に限定されない。例えば、図11図14の処理の全部あるいは一部はセンターサーバ2によって実行されてもよい。例えば、図11図13の処理の全部をセンターサーバ2が実行する場合、センターサーバ2単体(複数のサーバ装置を含んでもよい)が本発明のゲームシステムとして機能してもよい。一方で、HMD型のゲーム機4の単体が本発明のゲームシステムとして機能してよい。つまり、本発明のゲームシステムにおいてセンターサーバ2は適宜に省略されてよい。
【0084】
上述した実施の形態及び変形例のそれぞれから導き出される本発明の各種の態様を以下に記載する。なお、以下の説明では、本発明の各態様の理解を容易にするために添付図面に図示された対応する部材を括弧書きにて付記するが、それにより本発明が図示の形態に限定されるものではない。
【0085】
本発明のゲームシステムは、ユーザのプレイ行為を入力するための入力装置(OS)、及び前記ユーザのプレイ行為を通じて操作されるキャラクタとしてのユーザキャラクタ(54C)を含む複数のキャラクタ(54)が含まれるようにゲーム画面(50)を表示する表示装置(47)に接続され、前記複数のキャラクタが実行するパフォーマンスを含むゲームを提供するゲームシステム(4)であって、前記複数のキャラクタのうちの少なくとも一つのキャラクタ(54C)が実行したアクションに対応する所定のアクションとしての対応アクションを他のキャラクタ(54B)が実行した場合に前記一つのキャラクタと前記他のキャラクタとの間に少なくとも形成される連携状態の形成を要件に含む開始条件が満たされるか否か判別する条件判別手段(43)と、前記開始条件が満たされた場合に当該開始条件の具備を契機に前記パフォーマンスが開始される一方で、前記開始条件が満たされるまで前記パフォーマンスの開始が待機されるように前記ゲームの進行を制御する進行制御手段(43)と、を備えるものである。
【0086】
本発明によれば、連携状態は一つのキャラクタによるアクションとそれに対応する他のキャラクタによる対応アクションとにより形成される。このため、これらのアクション、及び対応アクションを通じてゲームの複数のキャラクタに呼吸を合わせるプロセスを模倣させることができる。また、開始条件が満たされた場合にパフォーマンスが開始される一方で、開始条件が満たされるまでパフォーマンスの開始が待機される。そして、そのようなパフォーマンスの開始の契機とされる開始条件は、連携状態の形成を要件に含んでいる。つまり、連携状態の形成を経てパフォーマンスは開始される。このため、パフォーマンスの開始前に、複数人によるパフォーマンスにおいて実行される呼吸を合わせるプロセスと同様のプロセスをゲームの複数のキャラクタに実行させることができる。結果として、パフォーマンスの臨場感、或いは一体感を向上させることができる。
【0087】
複数のキャラクタは、少なくとも一体のユーザキャラクタを含む限り、適宜に制御されてよい。例えば、複数のキャラクタは複数のユーザによってそれぞれ制御されてもよい。あるいは、ユーザキャラクタ以外の全キャラクタがコンピュータによって制御されてもよい。また、連携状態の形成の契機となるアクションはユーザキャラクタ(他のユーザに対応するキャラクタを含む)によって実行されてもよいし、コンピュータ制御のキャラクタによって実行されてもよい。例えば、本発明のゲームシステムの一態様として、前記ユーザキャラクタが前記一つのキャラクタとして機能する場合に、前記ユーザキャラクタによる前記アクションに対応して前記対応アクションを実行するように前記他のキャラクタを制御するキャラクタ制御手段(43)を備える態様が採用されてもよい。この場合、連携状態の形成のためのアクションが実行された場合に他のキャラクタは対応アクションを実行するように制御される。これにより、ユーザキャラクタによるアクションを契機に、積極的に連携状態を形成することができる。このため、開始条件具備の時期をユーザの都合に合わせることができる。
【0088】
パフォーマンスにおいて各キャラクタの動作は適宜に制御されてよく、例えば全てコンピュータによって制御されてもよいし、ユーザキャラクタ以外のキャラクタのみコンピュータによって制御されてもよい。また、コンピュータ制御のキャラクタは、適宜に動作してよく、予め決められた所定の動作(固定的な動作、及び各種条件により変化する動作の両方を含む)を実行してもよい。さらに、そのような動作は一つであっても、複数であってもよい。具体的には、例えば、他のキャラクタが対応アクションを実行するように自動制御される態様として、前記パフォーマンスにおける前記ユーザキャラクタの動作が前記プレイ行為を通じて制御される場合に、前記他のキャラクタと当該他のキャラクタが前記パフォーマンスにおいて実行すべき動作の候補として複数の動作とが関連付けられるように記述された候補データ(OD)に基づいて、前記複数の動作のうち前記パフォーマンスにおいて前記他のキャラクタが実際に実行すべき動作を選択するための選択機会を提供する機会提供手段(43)を備える態様が採用されてもよい。
【0089】
あるいは、コンピュータ制御のキャラクタは、そのキャラクタが過去にユーザキャラクタとしてプレイに使用された実績がある場合、そのプレイにおいてユーザ(今回ゲームをプレイするユーザのみならず、その他のユーザを含んでいてよい)のプレイ行為に応じて実行された動作を実行してもよい。具体的には、選択機会が提供される本発明の態様において、前記ゲームは、各ユーザによって前記複数のキャラクタから前記ユーザキャラクタが選択されるように提供され、前記複数の動作は、前記他のキャラクタが前記ユーザキャラクタとして過去に各ユーザによって選択された実績が存在する場合に、当該実績において前記他のキャラクタが実行した動作を含んでいてもよい。この場合、パフォーマンスにおけるユーザキャラクタ以外の他のキャラクタの動作に過去のユーザのプレイ実績を反映することができる。
【0090】
連携状態を形成するためのアクション、及び対応アクションとして、各種のアクションが適宜に採用されてよい。例えば、頭、手、或いは脚といったキャラクタの各部位を動作させる各種のアクションが、連携状態を形成するためのアクション、或いは対応アクションとして適宜に利用されてもよい。また、発声、或いはアイコンタクトといったアクションが、連携状態を形成するためのアクション、或いは対応アクションとして適宜に利用されてもよい。具体的には、例えば、本発明のゲームシステムの一態様において、前記連携状態は、前記一つのキャラクタに設定される視野範囲(IR)に前記他のキャラクタを入れる動作が前記アクションとして、前記他のキャラクタに設定される視野範囲(IR)に前記一つのキャラクタを入れる動作が前記対応アクションとして、それぞれ機能するように、前記一つのキャラクタの視野範囲に含まれる前記他のキャラクタが当該他のキャラクタの視野範囲に前記一つのキャラクタを入れた場合に形成されてもよい。この場合、呼吸を合わせるプロセスの模倣として、ユーザキャラクタと他のキャラクタとにアイコンタクトに対応する動作を実行させることができる。
【0091】
開始条件は連携状態の形成のみを要件として含んでいてもよいし、各種の他の要件を適宜に含んでいてもよい。そのような他の要件として、ユーザのプレイ行為、プレイ状況、或いはゲームの都合等の適宜の条件が利用されてよい。例えば、本発明のゲームシステムの一態様において、前記開始条件は、前記連携状態において前記一つのキャラクタによって実行されるべき特別のアクションを更に要件に含み、前記連携状態において前記特別のアクションが実行された場合に満たされてもよい。
【0092】
パフォーマンスは、適宜のパートを含んでいてよく、例えばパフォーマンスを複数のキャラクタが実際に実行するパートのみならず、その他の各種のパートを適宜に含んでいてよい。具体的には、例えば、本発明のゲームシステムの一態様において、前記パフォーマンスは、当該パフォーマンスを前記複数のキャラクタが実際に実行するパフォーマンスパート、及び当該パフォーマンスパートの開始の時期を示すための準備パートを含み、前記進行制御手段は、前記開始条件の具備を契機に前記パフォーマンスの開始として前記準備パートを開始させることにより前記準備パートの後に前記パフォーマンスパートが開始されるように前記ゲームの進行を制御してもよい。
【0093】
ゲームとして、各種のゲームが適宜に提供されてよい。同様に、そのようなゲームでは、ゲームの種類に応じて複数のキャラクタによる各種のパフォーマンスが適宜に実行されてよい。例えば、サッカーゲーム、或いは野球ゲーム等のスポーツゲームにおけるゲームのプレイがパフォーマンスとして利用され、開始条件の具備を契機にキックオフやプレイボールが開始されてもよい。あるいは、音楽ゲームにおけるダンスや演奏等がパフォーマンスとして利用されてもよい。具体的には、例えば、本発明のゲームシステムの一態様において、前記ゲームとして、楽曲のリズムに合わせて前記ユーザが実行すべきプレイ行為の実行時期を案内するとともに、当該プレイ行為に伴い前記ユーザキャラクタが前記楽曲を演奏する演奏動作を実行する音楽ゲームが提供され、前記パフォーマンスとして、前記音楽ゲームでは前記複数のキャラクタの各キャラクタによる前記演奏動作が実行されてもよい。
【0094】
一方、本発明のコンピュータプログラム(PG2)は、前記入力装置、及び前記表示装置に接続されるコンピュータ(41)を、上述のゲームシステムの各手段として機能させるように構成されたものである。
【0095】
また、本発明の制御方法は、ユーザのプレイ行為を入力するための入力装置(OS)、及び前記ユーザのプレイ行為を通じて操作されるキャラクタとしてのユーザキャラクタ(54C)を含む複数のキャラクタ(54)が含まれるようにゲーム画面(50)を表示する表示装置(47)に接続され、前記複数のキャラクタが実行するパフォーマンスを含むゲームを提供するゲームシステム(4)に組み込まれるコンピュータ(41)に、前記複数のキャラクタのうちの少なくとも一つのキャラクタ(54C)が実行したアクションに対応する所定のアクションとしての対応アクションを他のキャラクタ(54B)が実行した場合に前記一つのキャラクタと前記他のキャラクタとの間に少なくとも形成される連携状態の形成を要件に含む開始条件が満たされるか否か判別する条件判別手順と、前記開始条件が満たされた場合に当該開始条件の具備を契機に前記パフォーマンスが開始される一方で、前記開始条件が満たされるまで前記パフォーマンスの開始が待機されるように前記ゲームの進行を制御する進行制御手順と、を実行させるものである。本発明のコンピュータプログラム、或いは制御方法を通じて、本発明のゲームシステムを実現することができる。
【符号の説明】
【0096】
1 ゲームシステム
2 センターサーバ
4 HMD型のゲーム機(ゲームシステム)
41 制御ユニット(コンピュータ)
43 進行制御部(条件判別手段、進行制御手段、キャラクタ制御手段、機会提供手段)
47 ディスプレイ(表示装置)
50 ゲーム画面
54 キャラクタ画像(キャラクタ)
54B 第2キャラクタ画像(他のキャラクタ)
54C 第3キャラクタ画像(ユーザキャラクタ、一つのキャラクタ)
IR 視野範囲
OS 操作スティック(入力装置)
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14