(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-09-21
(45)【発行日】2022-09-30
(54)【発明の名称】プログラム及びゲームシステム
(51)【国際特許分類】
A63F 13/52 20140101AFI20220922BHJP
A63F 13/56 20140101ALI20220922BHJP
A63F 13/54 20140101ALI20220922BHJP
G06T 13/40 20110101ALI20220922BHJP
【FI】
A63F13/52
A63F13/56
A63F13/54
G06T13/40
(21)【出願番号】P 2017239510
(22)【出願日】2017-12-14
【審査請求日】2020-12-02
(73)【特許権者】
【識別番号】000134855
【氏名又は名称】株式会社バンダイナムコエンターテインメント
(74)【代理人】
【識別番号】100104710
【氏名又は名称】竹腰 昇
(74)【代理人】
【識別番号】100124682
【氏名又は名称】黒田 泰
(74)【代理人】
【識別番号】100090479
【氏名又は名称】井上 一
(72)【発明者】
【氏名】矢野 義人
(72)【発明者】
【氏名】中矢 陽一
(72)【発明者】
【氏名】渡辺 耕一郎
(72)【発明者】
【氏名】久保田 裕章
【審査官】宇佐田 健二
(56)【参考文献】
【文献】特開2010-119825(JP,A)
【文献】特開2010-072768(JP,A)
【文献】国際公開第2015/194509(WO,A1)
(58)【調査した分野】(Int.Cl.,DB名)
A63F 13/00-13/98,9/24
G06T 13/40
(57)【特許請求の範囲】
【請求項1】
プレーヤの操作情報に基づいて、移動体のアニメーション処理を行うアニメーション処理部と、
前記アニメーション処理における基準タイミング
と、ゲーム中に出力される音のタイミング情報
の特定処理を行うタイミング処理部として、
コンピュータを機能させ、
前記アニメーション処理部は、
前記プレーヤの前記操作情報と、前記移動体の時系列の複数の姿勢データを含むアニメーション情報とに基づいて、前記移動体を動作させる前記アニメーション処理を行い、
前記タイミング処理部は、
前記プレーヤの前記操作情報に基づいて、前記アニメーション処理における前記移動体の動作特徴タイミングを前記基準タイミングとして特定し、
前記アニメーション処理部は、
前記音のタイミング情報により表されるタイミングと、前記動作特徴タイミングとが一致するように、前記アニメーション処理の調整処理を行い、
前記アニメーション処理部は、
前記音のタイミング情報により表されるタイミングが、前記動作特徴タイミングよりも遅いタイミングである場合に、前記音のタイミング情報に合わせて前記移動体が動作するように、
(1)前記アニメーション処理の再生開始タイミングを遅らせる処理、或いは、
(2)前記動作特徴タイミングよりも前の所与の範囲において前記移動体の動作をスロー再生する処理を、
前記調整処理として行うこと特徴とするプログラム。
【請求項2】
請求項
1において、
前記アニメーション情報には、
前記動作特徴タイミングが、キーフレームを表すキーフレーム情報
として対応付けられており、
前記アニメーション処理部は、
前記音のタイミング情報により表されるタイミングと、前記キーフレーム情報により表される前記キーフレームの再生タイミングとが一致するように、前記調整処理を行うことを特徴とするプログラム。
【請求項3】
請求項
2において、
前記基準タイミングは、前記キーフレームの前記再生タイミングであることを特徴とするプログラム。
【請求項4】
請求項
1乃至3のいずれかにおいて、
前記アニメーション処理部は、
前記アニメーション処理の対象となる前記アニメーション情報の決定処理を行い、決定された前記アニメーション情報に対して前記調整処理を行うことを特徴とするプログラム。
【請求項5】
請求項
4において、
前記アニメーション処理部は、
前記音のタイミング情報に基づいて、前記アニメーション情報の前記決定処理を行うことを特徴とするプログラム。
【請求項6】
請求項
5において、
前記音のタイミング情報には、パラメータが関連づけられており、
前記アニメーション処理部は、
前記パラメータに基づいて、前記アニメーション情報の前記決定処理を行うことを特徴とするプログラム。
【請求項7】
請求項
6において、
前記ゲーム内で再生される音は、楽曲情報により表される楽曲であり、
前記パラメータは、音量、音程、及び音色の少なくとも1つに関するパラメータであることを特徴とするプログラム。
【請求項8】
請求項
4において、
前記ゲーム内で再生される音は、楽曲情報により表される楽曲であり、
前記アニメーション処理部は、
前記楽曲情報、前記プレーヤの操作情報、前記移動体が移動するフィールドの情報、及び前記移動体の状態を表す状態情報の少なくとも1つに基づいて、前記アニメーション情報の前記決定処理を行うことを特徴とするプログラム。
【請求項9】
プレーヤの操作情報に基づいて、移動体のアニメーション処理を行うアニメーション処理部と、
前記アニメーション処理における基準タイミング
と、ゲーム中に出力される音のタイミング情報
の特定処理を行うタイミング処理部と、
を含み、
前記アニメーション処理部は、
前記プレーヤの前記操作情報と、前記移動体の時系列の複数の姿勢データを含むアニメーション情報とに基づいて、前記移動体を動作させる前記アニメーション処理を行い、
前記タイミング処理部は、
前記プレーヤの前記操作情報に基づいて、前記アニメーション処理における前記移動体の動作特徴タイミングを前記基準タイミングとして特定し、
前記アニメーション処理部は、
前記音のタイミング情報により表されるタイミングと、前記動作特徴タイミングとが一致するように、前記アニメーション処理の調整処理を行い、
前記アニメーション処理部は、
前記音のタイミング情報により表されるタイミングが、前記動作特徴タイミングよりも遅いタイミングである場合に、前記音のタイミング情報に合わせて前記移動体が動作するように、
(1)前記アニメーション処理の再生開始タイミングを遅らせる処理、或いは、
(2)前記動作特徴タイミングよりも前の所与の範囲において前記移動体の動作をスロー再生する処理を、
前記調整処理として行うこと特徴とするゲームシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、プログラム及びゲームシステム等に関する。
【背景技術】
【0002】
従来より、プレーヤが音楽ゲームをプレイするためのゲームシステムが知られている。このゲームシステムでは、音出力部から楽曲が出力されると共に、表示部には、プレーヤの操作タイミングを指示するための指示マーク(音符)が表示される。プレーヤは、出力される楽曲を聞きながら、表示された指示マークにしたがった操作を行って、音楽ゲームを楽しむ。このようなゲームシステムの従来技術としては例えば特許文献1に開示される技術がある。
【0003】
また特許文献2には、ユーザに音楽鑑賞を楽しませる手法として、音楽に合わせてキャラクタオブジェクトが動作する動画像を生成する手法が開示されている。
【先行技術文献】
【特許文献】
【0004】
【文献】特開2008-61764号公報
【文献】国際公開第2015/194509号
【発明の概要】
【発明が解決しようとする課題】
【0005】
従来の音楽ゲームでは、プレーヤは音のタイミングに合わせて適切な操作を行う必要があり、難易度が高い。これに対して、従来より広く知られているアクションゲームの要素を、音楽ゲームに組み合わせることが考えられる。当該ゲームシステムでは、プレーヤ操作に基づいてキャラクタを動作させ、キャラクタの動作に合わせて楽曲等の音の出力制御を行う。このようにすれば、プレーヤは、キャラクタを操作するだけで楽曲を演奏をしているように感じられ、高揚感を得られる。
【0006】
キャラクタの動作では、跳躍動作における着地や踏切のように、当該動作において特徴的なタイミングを規定できる。当該特徴的なタイミングと音のタイミングがずれている場合、プレーヤは音楽を演奏している感覚を得にくくなってしまい、興趣性に欠ける。また、キャラクタの動作が行われるタイミングや動作の内容は、プレーヤ操作によって決定されるため、特許文献2の手法のように音楽に合わせたキャラクタ動作(アニメーション)をあらかじめ作り込んでおくことは困難である。
【0007】
本発明の幾つかの態様によれば、プレーヤ操作に基づく移動体のアニメーションを音のタイミングに合わせることで、興趣性の高いプログラム及びゲームシステム等を提供できる。
【課題を解決するための手段】
【0008】
本発明の一態様は、プレーヤの操作情報に基づいて、移動体のアニメーション処理を行うアニメーション処理部と、前記プレーヤの操作情報に基づいて基準タイミングを決定し、前記基準タイミングに基づいて、ゲーム中に出力される音のタイミング情報を決定するタイミング処理部と、を含み、前記アニメーション処理部は、前記音のタイミング情報に合わせて、前記移動体の前記アニメーション処理を行うゲームシステムに関係する。また本発明は、上記各部としてコンピュータを機能させるプログラム、又は該プログラムを記憶したコンピュータ読み取り可能な情報記憶媒体に関係する。
【0009】
本発明の一態様では、基準タイミングと音のタイミング情報を決定し、音のタイミング情報に合うように移動体のアニメーション処理が行われる。操作情報に基づいてアニメーション処理が行われる場合、移動体のアニメーションと音のタイミングをあらかじめ対応付けておくことは難しい。その点、本発明の一態様によれば、音のタイミングを適切に決定した上でアニメーション処理を行うことで、音に合わせた移動体のアニメーションを実現できる。
【0010】
また本発明の一態様では、前記アニメーション処理部は、前記音のタイミング情報に基づいて、前記アニメーション処理に用いられる前記移動体のアニメーション情報の調整処理を行ってもよい。
【0011】
このようにすれば、アニメーション情報の調整処理により、音に合わせた移動体のアニメーションを実現することが可能になる。
【0012】
また本発明の一態様では、前記アニメーション処理部は、前記音のタイミング情報に合わせて前記移動体が動作するように、前記調整処理を行ってもよい。
【0013】
このようにすれば、アニメーション情報の調整処理により、移動体を音のタイミングに合わせて動作させることが可能になる。
【0014】
また本発明の一態様では、前記アニメーション情報には、キーフレームを表すキーフレーム情報が対応付けられており、前記アニメーション処理部は、前記音のタイミング情報により表されるタイミングと、前記キーフレーム情報により表される前記キーフレームの再生タイミングとが一致するように、前記調整処理を行ってもよい。
【0015】
このようにすれば、キーフレーム情報に基づいて調整処理を行うことが可能になる。
【0016】
また本発明の一態様では、前記基準タイミングは、前記キーフレームの前記再生タイミングであってもよい。
【0017】
このようにすれば、キーフレームの再生タイミングを基準タイミングとして用いることが可能になる。
【0018】
また本発明の一態様では、前記アニメーション処理部は、前記アニメーション処理の対象となる前記アニメーション情報の決定処理を行い、決定された前記アニメーション情報に対して前記調整処理を行ってもよい。
【0019】
このようにすれば、複数のアニメーション情報の中から適切なアニメーション情報を選択することが可能になる。
【0020】
また本発明の一態様では、前記アニメーション処理部は、前記音のタイミング情報に基づいて、前記アニメーション情報の前記決定処理を行ってもよい。
【0021】
このようにすれば、音のタイミング情報に基づいて、アニメーション情報の決定処理を行うことが可能になる。
【0022】
また本発明の一態様では、前記音のタイミング情報には、パラメータが関連づけられており、前記アニメーション処理部は、前記パラメータに基づいて、前記アニメーション情報の前記決定処理を行ってもよい。
【0023】
このようにすれば、楽曲のパラメータに基づいて、アニメーション情報の決定処理を行うことが可能になる。
【0024】
また本発明の一態様では、前記ゲーム内で再生される音は、楽曲情報により表される楽曲であり、前記パラメータは、音量、音程、及び音色の少なくとも1つに関するパラメータであってもよい。
【0025】
このようにすれば、楽曲の音量、音程、音色に関するパラメータに基づいて、決定処理を行うことが可能になる。
【0026】
また本発明の一態様では、前記ゲーム内で再生される音は、楽曲情報により表される楽曲であり、前記アニメーション処理部は、前記楽曲情報、前記プレーヤの操作情報、前記移動体が移動するフィールドの情報、及び前記移動体の状態を表す状態情報の少なくとも1つに基づいて、前記アニメーション情報の前記決定処理を行ってもよい。
【0027】
このようにすれば、種々の情報に基づいて、アニメーション情報の決定処理を行うことが可能になる。
【図面の簡単な説明】
【0028】
【
図2】
図2(A)~
図2(E)は本実施形態のゲームシステムを実現する種々の装置の例。
【
図3】
図3(A)は本実施形態のゲームシステムで用いられる3次元マップの例、
図3(B)は表示部に表示されるゲーム画面の例。
【
図5】
図5(A)~
図5(C)は跳躍動作に対応するゲーム画面の例。
【
図7】
図7(A)~
図7(C)はスライディング動作に対応するゲーム画面の例。
【
図10】判定結果(ビートパラメータ)とパート楽曲部分の対応付けの例。
【
図13】オブジェクト制御を説明するフローチャート。
【
図14】モデルオブジェクト、スケルトン構造の例。
【
図18】基準タイミングと音のタイミングの関係例。
【
図19】アニメーション情報に対する調整処理の説明図。
【
図20】アニメーション処理を説明するフローチャート。
【
図21】アニメーション情報記憶部に記憶されるデータの例。
【
図23】
図23(A)~
図23(C)は複数のキーフレームを含むアニメーション情報に対する調整処理の説明図。
【
図24】アニメーション処理を説明する他のフローチャート。
【発明を実施するための形態】
【0029】
以下、本実施形態について説明する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また本実施形態で説明される構成の全てが、本発明の必須構成要件であるとは限らない。
【0030】
1.構成
図1に本実施形態のゲームシステム(ゲーム装置、画像生成システム、サーバシステム)のブロック図の例を示す。なお、本実施形態のゲームシステムの構成は
図1に限定されず、その構成要素(各部)の一部を省略したり、他の構成要素を追加するなどの種々の変形実施が可能である。
【0031】
操作部160は、プレーヤ(ユーザ)が操作データを入力するためのものであり、その機能は、操作ボタン、方向指示キー、アナログスティック、レバー、各種センサ(角速度センサ、加速度センサ等)、撮像部(カメラ)、マイク、或いはタッチパネル型ディスプレイなどにより実現できる。
【0032】
記憶部170は、処理部100や通信部196などのワーク領域となるもので、その機能はRAM、SSD、或いはHDDなどにより実現できる。
【0033】
記憶部170は、楽曲情報(BGM、音楽)を記憶する楽曲情報記憶部171、ゲーム進行履歴の情報(経過時間、ゲーム内パラメータ、キャラクタの移動履歴や移動方向等)を記憶するゲーム進行履歴記憶部172、移動体が移動するフィールドや当該フィールド上に配置されるオブジェクトの情報を記憶するフィールド・オブジェクト情報記憶部173、移動体(キャラクタ)のアニメーション情報を記憶するアニメーション情報記憶部174を含む。なお記憶部170の構成は
図1に限定されず、記憶部170は、プレーヤによる操作入力の情報を記憶するバッファや、オブジェクトの描画処理に使用される描画バッファ等の不図示の構成を含んでもよい。
【0034】
記憶媒体180(コンピュータにより読み取り可能な媒体)は、データやプログラムなどの各種の情報を記憶する。記憶媒体180は、SRAM、DRAMなどの半導体メモリーであってもよいし、レジスタであってもよいし、ハードディスク装置(HDD)などの磁気記憶装置であってもよいし、光学ディスク装置等の光学式記憶装置であってもよい。例えば、記憶媒体180はコンピュータにより読み取り可能な命令を格納しており、当該命令が処理部100(プロセッサ)により実行されることで、ゲームシステムの各部(通信部、処理部)の機能が実現されることになる。ここでの命令は、プログラムを構成する命令セットの命令でもよいし、処理部100(プロセッサ)のハードウェア回路に対して動作を指示する命令であってもよい。
【0035】
表示部190は、本実施形態により生成された画像を出力するものであり、その機能は、LCD、有機ELディスプレイ、CRT、各種プロジェクター型ディスプレイ、或いはHMDなどにより実現できる。音出力部192は、本実施形態により生成された音を出力するものであり、その機能は、スピーカ、或いはヘッドフォンなどにより実現できる。
【0036】
I/F(インターフェース)部194は、携帯型情報記憶媒体195とのインターフェース処理を行うものであり、その機能はI/F処理用のASICなどにより実現できる。携帯型情報記憶媒体195は、プレーヤがゲームプレイするための各種情報が記憶されるものであり、ICカード(メモリーカード)、USBメモリ、或いは磁気カードなどにより実現できる。
【0037】
通信部196は、有線や無線のネットワークを介して外部装置(例えば他のゲーム装置、管理装置、サーバシステム等)との間で通信を行うものであり、その機能は、通信用ASIC又は通信用プロセッサなどのハードウェアや、通信用ファームウェアにより実現できる。
【0038】
なお本実施形態の各部としてコンピュータを機能させるためのプログラム(データ)は、サーバシステム(ホスト装置)が有する情報記憶媒体からネットワーク及び通信部196を介して記憶媒体180(あるいは記憶部170)に配信してもよい。このようなサーバシステムによる記憶媒体の使用も本発明の範囲内に含めることができる。
【0039】
処理部100(プロセッサ)は、操作部160からの操作情報やプログラムなどに基づいて、ゲーム処理、表示処理、或いは音処理などを行う。処理部100は記憶部170をワーク領域として各種処理を行う。処理部110が行う本実施形態の各処理(各機能)は、プロセッサ(ハードウェアを含むプロセッサ)により実現できる。例えば本実施形態の各処理は、プログラム等の情報に基づき動作するプロセッサと、プログラム等の情報を記憶するメモリー(記憶装置)により実現できる。ここでのプロセッサは、例えば各部の機能が個別のハードウェアで実現されてもよいし、或いは各部の機能が一体のハードウェアで実現されてもよい。例えば、プロセッサはハードウェアを含み、そのハードウェアは、デジタル信号を処理する回路及びアナログ信号を処理する回路の少なくとも一方を含むことができる。例えば、プロセッサは、回路基板に実装された1又は複数の回路装置(例えばIC等)や、1又は複数の回路素子(例えば抵抗、キャパシター等)で構成することができる。プロセッサは、例えばCPU(Central Processing Unit)であってもよい。ただし、プロセッサはCPUに限定されるものではなく、GPU(Graphics Processing Unit)、或いはDSP(Digital Signal Processor)等、各種のプロセッサを用いることが可能である。またプロセッサはASIC(application specific integrated circuit)によるハードウェア回路でもよい。またプロセッサは、複数のCPUにより構成されていてもよいし、複数のASICによるハードウェア回路により構成されていてもよい。また、プロセッサは、複数のCPUと、複数のASICによるハードウェア回路と、の組み合わせにより構成されていてもよい。
【0040】
処理部100は、入力受け付け部102、ゲーム処理部104、キャラクタ処理部106、楽曲再生部112、オブジェクト制御部114、判定部116、表示処理部120を含む。また、キャラクタ処理部106は、アニメーション処理部108、タイミング処理部110を含む。なおこれらの構成要素の一部を省略したり、他の構成要素を追加するなどの変形実施が可能である。
【0041】
入力受け付け部102は、プレーヤの操作情報(入力情報)の受け付け処理を行う。例えば操作部160を用いてプレーヤが入力した操作の受け付け処理を行う。例えば操作部160からのデータをサンプリングし、A/D変換などを行って操作情報として受け付ける。
【0042】
ゲーム処理部104はゲーム処理(ゲーム演算処理)を行う。ここでゲーム処理としては、ゲーム開始条件が満たされた場合にゲームを開始する処理、ゲームを進行させる処理、或いはゲーム終了条件が満たされた場合にゲームを終了する処理などがある。またゲーム処理部104は、プレーヤのゲーム成績(得点、ポイント)の演算処理を行う。
【0043】
キャラクタ処理部106は、プレーヤがゲーム内で操作するキャラクタに関する処理を行う。キャラクタは、例えば後述する人型のキャラクタCAである。ただし、プレーヤによる操作対象は種々の移動体に拡張可能であり、キャラクタ処理部106を移動体に関する処理を行う移動体処理部に拡張して考えることも可能である。
【0044】
キャラクタ処理部106のアニメーション処理部108は、キャラクタのアニメーション処理を行う。具体的には、記憶部170のアニメーション情報記憶部174は、複数のアニメーション情報(モーション情報)を記憶しており、各アニメーション情報は、キャラクタの所与の動作(アクション、モーション、アニメーション)に対応する。アニメーション処理部108は、操作情報やオブジェクト情報に基づいて適切なアニメーション情報を決定(選択)し、当該アニメーション情報を再生する処理(モーション再生処理)を行うことで、キャラクタのアニメーションを実現する。
【0045】
また、本実施形態のアニメーション処理部108は、キャラクタのアニメーションを音(楽曲)に合わせるような調整処理を行う。タイミング処理部110は、操作情報や楽曲情報に基づいて、調整処理に必要なタイミング(基準タイミング、音のタイミング)の特定処理を行う。アニメーション処理部108は、タイミング処理部110で特定されたタイミングに基づいて、アニメーション情報に対する調整処理を行う。
【0046】
楽曲再生部112は、処理部100で行われる種々の処理の結果に基づいて音処理を行い、楽曲(BGM)を生成し、音出力部192に出力する。なお、以下の説明では楽曲再生部112における再生処理の対象が楽曲(BGM)である例を説明するが、楽曲再生部112は、効果音、又は音声などの楽曲以外のゲーム音を生成し、音出力部192に出力してもよい。
【0047】
オブジェクト制御部114は、キャラクタが移動するフィールドに配置され、キャラクタによる動作の対象となるオブジェクトの制御を行う。オブジェクト制御部114は、ゲームの進行履歴に基づいてオブジェクトの配置等に関する制御を行う。
【0048】
判定部116はプレーヤの操作情報に基づく判定処理を行う。例えば判定部116は、プレーヤに対応するキャラクタの位置、オブジェクトの位置、プレーヤが入力した操作の種類等の情報に基づいて、オブジェクトに対するキャラクタの動作が成功したか否かを判定する。
【0049】
表示処理部120は、表示部190にゲーム画像等の画像を表示するための処理(画像生成処理等)を行う。例えば処理部100で行われる種々の処理(ゲーム処理、シミュレーション処理)の結果に基づいて描画処理を行い、これにより画像を生成し、表示部190に出力する。例えば3次元ゲーム用の画像を生成する場合には、座標変換(ワールド座標変換、カメラ座標変換)、クリッピング処理、透視変換、或いは光源処理等のジオメトリ処理が行われ、その処理結果に基づいて、描画データ(プリミティブ面の頂点の位置座標、テクスチャ座標、色データ、法線ベクトル或いはα値等)が作成される。そして、この描画データ(プリミティブ面データ)に基づいて、透視変換後(ジオメトリ処理後)のオブジェクト(1又は複数プリミティブ面)を、描画バッファ(フレームバッファ、ワークバッファ等のピクセル単位で画像情報を記憶できるバッファ)に描画する。これにより、オブジェクト空間内において仮想カメラ(所与の視点)から見える画像が生成される。
【0050】
図2(A)に本実施形態のゲームシステムを実現する装置の一例を示す。
図2(A)は本実施形態のゲームシステムを携帯型ゲーム装置で実現する場合の例である。この携帯型ゲーム装置は、操作部160として機能する操作ボタン10、11、12、13、方向指示キー14、アナログスティック16、18、R、Lキー20、22や、液晶ディスプレイにより実現される表示部190を有する。なお本実施形態のゲームシステムを実現する装置は
図2(A)に限定されず、種々の変形実施が可能である。例えば本実施形態のゲームシステムを実現する装置は、
図2(B)に示す家庭用ゲーム装置(据え置き型)、
図2(C)に示す携帯型通信端末(スマートフォン、フューチャーフォン、携帯電話機)、
図2(D)に示す業務用ゲーム装置などであってもよい。或いは
図2(E)に示すように本実施形態のゲームシステムは、端末装置TM1~TMnとネットワーク510を介して通信接続されるサーバシステム500などにより実現してもよい。例えば本実施形態のゲームシステムの各処理を、サーバシステム500と端末装置TM1~TMnの分散処理等により実現してもよい。TM1~TMnの各端末装置は例えば
図2(A)~
図2(D)に示すような各種の装置により実現できる。
【0051】
図1に示したように、本実施形態のゲームシステムは、アニメーション処理部108、タイミング処理部110を含む。アニメーション処理部108は、プレーヤの操作情報に基づいて、移動体のアニメーション処理を行う。タイミング処理部110は、プレーヤの操作情報に基づいて基準タイミングを決定し、基準タイミングに基づいて、ゲーム中に出力される音のタイミング情報を決定する。さらにアニメーション処理部108は、音のタイミング情報に合わせて、移動体のアニメーション処理を行う。
【0052】
操作情報とは、プレーヤが操作部160に対して行った操作の内容(結果)を表す情報である。例えば操作情報は、
図2(A)の操作ボタン10、11、12、13、方向指示キー14、アナログスティック16、18、R、Lキー20、22のいずれに対する操作が行われたかを表す情報である。また操作情報は、プレーヤにより操作が行われたタイミングを特定する情報を含んでもよい。
【0053】
移動体とは、ゲームシステムにおいてプレーヤの操作情報に基づいてゲームマップ(狭義には3次元マップ)を移動するオブジェクトである。移動体は実空間のプレーヤに対応して仮想空間で移動するプレーヤ移動体である。移動体は、狭義には後述するキャラクタCA(プレーヤキャラクタ、アバター)である。ただし移動体として、車、バイク、飛行機等の乗り物を用いてもよい。即ち、本実施形態における移動体は、ゲームシステム中で形成される仮想的な空間を移動可能な種々のオブジェクトに拡張することが可能である。仮想カメラから見える画像は三人称視点の画像でもよく、一人称視点の画像でもよい。移動体であるプレーヤ移動体(キャラクタ)は、ゲーム画像に表示されるオブジェクトであってもよいし、ゲーム画像に表示されない仮想的なオブジェクトであってもよい。
【0054】
基準タイミングとは、アニメーション処理(狭義にはアニメーション情報の再生処理)の基準となるタイミング(或いは、当該タイミングを表す情報)である。基準タイミングは、例えば再生対象となるアニメーション情報における特徴的なタイミングであり、狭義にはキーフレームの再生タイミングを表す。基準タイミング(後述する
図18のt
K)は、例えば操作情報に基づいてアニメーション情報の再生開始タイミング(
図18のt
S)が特定されることで特定可能になる。
【0055】
音のタイミング情報とは、音出力部192で出力される音の特徴的なタイミングを表す情報である。以下、音のタイミング情報により表されるタイミングを、音のタイミングと表記する。なお、ここでの音は狭義には楽曲であり、音のタイミングとは楽曲の特徴タイミングのうちの、基準タイミングに対応するタイミングである。楽曲の特徴タイミングとは、当該楽曲にとって特徴的なタイミングのことであり、例えば後述する拍のタイミングや、所定のパートの音が出力されるタイミングである。ただし、ここでの音とは特徴的なタイミングが規定可能な音であればよく、例えば一定の間隔、リズムで出力される効果音(SE)等の種々の音に拡張して考えることが可能である。
【0056】
本実施形態の手法によれば、操作情報に基づいてアニメーション処理を行う場合において、基準タイミングと音のタイミングを合わせることで、アニメーションと音の連動性を高めることが可能になる。結果として、音に合わせて移動体(キャラクタ)を動作させている感覚、或いは、移動体を動作させることで音を奏でている感覚を、プレーヤに与えることが可能になる。本実施形態の手法では、プレーヤに爽快感、高揚感を与えるゲームシステムを実現することが可能になる。
【0057】
またアニメーション処理部108は、音のタイミング情報に基づいて、アニメーション処理に用いられる移動体のアニメーション情報の調整処理を行う。より具体的には、アニメーション処理部108は、音のタイミング情報に合わせて移動体が動作するように、調整処理を行う。
【0058】
アニメーション情報は、移動体に対して所定の動作を行わせるための情報であり、例えば
図16を用いて後述するように、移動体の姿勢(スケルトンの姿勢)を表す情報の集合である。本実施形態では、アニメーション情報の再生処理が実行されるタイミングは、プレーヤの操作情報によって決定されるため、アニメーション情報と音の時間的な関係(基準タイミングと音のタイミングの関係)は、操作情報が入力されるまでわからない。よって本実施形態では、アニメーション情報に対して調整処理を行う。このようにすれば、操作情報が入力されるタイミングによらず、音とアニメーションの連動性を高めることが可能になる。
【0059】
またアニメーション情報には、キーフレームを表すキーフレーム情報が対応付けられており、アニメーション処理部108は、音のタイミング情報により表されるタイミングと、キーフレーム情報により表されるキーフレームの再生タイミングとが一致するように、調整処理を行う。即ち、基準タイミングは、キーフレームの再生タイミングであってもよい。
【0060】
キーフレームとは、アニメーション情報を構成する複数のフレームのうちの特徴的なフレームを表す。キーフレームの再生タイミングと音のタイミングを一致させる(時間差を低減する)処理を行うことで、移動体のアニメーションと音を連動させるようなアニメーション情報の調整処理を実現することが可能になる。
【0061】
またアニメーション処理部108は、アニメーション処理の対象となるアニメーション情報の決定処理を行い、決定されたアニメーション情報に対して調整処理を行う。このようにすれば、多様なアニメーション情報から適切なアニメーション情報を決定(選択)することが可能になる。
【0062】
例えばアニメーション処理部108は、音のタイミング情報に基づいて、アニメーション情報の決定処理を行う。音のタイミング情報は上記のように移動体のアニメーションと音との連動性を決定する要素である。そのため、音のタイミング情報を用いることで、音とアニメーションの関係を考慮した決定処理、例えば音との連動性が高いアニメーション情報を再生対象とするような決定処理を実現できる。
【0063】
また音のタイミング情報には、パラメータが関連づけられており、アニメーション処理部108は、当該パラメータに基づいて、アニメーション情報の決定処理を行う。狭義には、ゲーム内で再生される音は、楽曲情報により表される楽曲であり、パラメータは、音量、音程、及び音色の少なくとも1つに関するパラメータである。
【0064】
ここで音量とは、音の大きさ(信号レベル)を表し、音程とは音の高低(信号の周波数)を表し、音色とは音の波形(信号波形、例えばエンベロープ)を表す。ただし音色に関するパラメータとして、音の出力元である楽器(パート)を表す情報を用いてもよい。
【0065】
このようにすれば、音(楽曲)のパラメータに応じてアニメーション情報を決定することが可能になる。例えば静かな楽曲では動きの小さいアニメーション情報を対象して決定し、激しい楽曲では動きの大きいアニメーション情報を対象として決定する処理等が可能になる。
【0066】
またアニメーション処理部108は、楽曲情報、プレーヤの操作情報、移動体が移動するフィールドの情報、及び移動体の状態を表す状態情報の少なくとも1つに基づいて、アニメーション情報の決定処理を行ってもよい。
【0067】
楽曲情報とは、例えば上述した音量、音程、音色の情報であってもよいし、楽曲のジャンルや作曲者等の他の情報であってもよい。操作情報とは、例えば
図2(A)等のように多様な入力インターフェースを有する操作部160において、いずれの入力インターフェースが操作対象となったかを表す情報(操作の種類情報)である。また、移動体が移動するフィールドとは、例えば後述するフィールドFEであってもよいし、オブジェクトOBを含んでもよい。移動体の状態とは、例えば移動体の現在の位置、姿勢、移動速度や、過去の位置、姿勢、移動速度の履歴である。また移動体に体力や耐久度等のゲーム内パラメータが設定される場合、移動体の状態情報として当該パラメータを用いてもよい。このようにすれば、ゲーム内で用いられる多様な情報に基づいて、適切なアニメーション情報を再生処理の対象として決定することが可能になる。
【0068】
また
図1に示したように、本実施形態のゲームシステムは、ゲーム処理部104、楽曲再生部112、キャラクタ処理部106、判定部116を含む。ゲーム処理部104は、ゲームの進行処理を行う。楽曲再生部112は、楽曲の再生処理を行う。キャラクタ処理部106は、プレーヤの操作情報に基づいてプレーヤに対応するキャラクタを、ゲーム空間のフィールドにおいて移動させる処理を行う。判定部116は、プレーヤの操作情報に基づいて、フィールドに配置されるオブジェクトに対するキャラクタの動作が成功したか否かを判定する。本実施形態では、楽曲再生部112は、フィールドでのキャラクタの存在エリアに応じて抽出した、楽曲の一部である楽曲部分を再生する制御を行う。さらに楽曲再生部112は、判定部116での判定結果に基づいて、楽曲部分の再生態様を変化させる制御を行う。
【0069】
ここでの楽曲部分とは、楽曲を演奏の時間軸方向に分割した一部(後述する時系列楽曲部分)、及び楽曲を楽曲パート毎に分割した一部(後述するパート楽曲部分)の少なくとも一方である。一例としては、後述するようにフィールドに設定される複数のエリアの各エリアに対して時系列楽曲部分が対応付けられており、楽曲再生部112は、キャラクタの存在エリアに基づいて、再生対象の時系列楽曲部分を決定する。そして楽曲再生部112は、再生態様を変化させる制御として、再生対象となるパート楽曲部分を変化させる制御を行う。ただし、所定エリアにギターを対応付け、他のエリアにドラムを対応付ける等、エリアに対してパート楽曲部分を対応付ける変形実施も可能である。
【0070】
このようにすれば、プレーヤによるキャラクタの操作に対応した楽曲の再生処理が可能になる。プレーヤから見れば、キャラクタをどのエリアに移動させるかに応じて、楽曲部分の選択(狭義には時系列方向での楽曲制御)が可能であるし、オブジェクトに対する動作を成功させることで、再生態様の変更(パート方向での楽曲制御)が可能である。即ち、適切なエリア移動、及びオブジェクトに対する動作を行うことで、自然に楽曲を演奏できるような興趣性の高いゲームシステム(プログラム)を実現できる。本実施形態のゲームシステムは従来の音楽ゲームのような難しい操作が不要である。さらに、本実施形態におけるオブジェクトに対する動作は、従来のアクションゲームのような単なる移動手段ではなく、演奏(音の厚み)を決定する重要な要素となる。そのため、当該動作自体をアクロバティック、スタイリッシュにすることで、プレーヤに爽快感を与えるゲームシステムを実現できる。
【0071】
また、本実施形態のゲームシステムは、オブジェクトを制御するオブジェクト制御部114を含む。オブジェクト制御部114は、判定部116での判定結果に基づいて、キャラクタの動作対象とは異なるオブジェクトに対する制御を行う。
【0072】
ここでのオブジェクトに対する制御とは、オブジェクトの配置/非配置を切り替える制御であってもよいし、配置済みのオブジェクトを変形させる制御であってもよい。或いは、オブジェクトの配置位置、配置姿勢、配置対象となるオブジェクトの種類を動的に決定する制御であってもよい。或いは、オブジェクトを発光(点滅)させたり、色を変更する制御であってもよい。
【0073】
このようにすれば、オブジェクトに対する動作の結果を、楽曲制御だけでなくオブジェクト制御に利用することが可能になる。本実施形態では、オブジェクトに対する動作が楽曲制御のトリガーとなる。そのため、キャラクタがオブジェクトに対する動作を継続的に行うように、プレーヤに対して操作を促す必要があると考えられる。さらに、適切なエリア移動が必要であること(エリアと楽曲部分が対応付けられているため)や、ゲームシステムの興趣性を高めることを考えた場合、同じオブジェクトを継続して動作対象とするのではなく、次々に異なるオブジェクトに対して動作が行われることが望ましい。その点、所与のオブジェクトに対する動作を、異なるオブジェクトに対する制御のトリガーとすることで、プレーヤを適切にガイドすること等が可能になる。より具体的には、現在の動作対象とは異なるオブジェクトを目立たせるような制御を行うことで、当該異なるオブジェクトが次の動作対象に適していることを、プレーヤに示すことが可能になる。
【0074】
オブジェクト制御部114は、ゲームの進行履歴に基づいて、オブジェクトの制御を行う。ここでのゲームの進行履歴とは、ゲームの経過時間、キャラクタの進行方向、及びプレーヤの操作入力の結果、の少なくとも1つである。ここで、ゲームの経過時間とは、ゲーム開始時からの経過時間であってもよいし、楽曲の演奏開始からの経過時間であってもよいし、所与のエリアでの滞在時間であってもよい。キャラクタの進行方向とは、キャラクタの位置の変位を表す情報であり、例えば異なる2タイミング間でのキャラの位置の差分を表すベクトル情報である。操作入力の結果とは、狭義には判定部116の判定結果であり、過去の動作についての成功/失敗の情報や、成功回数、失敗回数の情報である。或いは、跳躍動作を何回実行した等の情報(後述する
図21における「動作属性」や、その実行回数等)を操作入力の結果として用いてもよい。
【0075】
図3(A)、
図3(B)を用いて後述するように、キャラクタの背面に仮想カメラが配置される場合(三人称視点の場合)、プレーヤはキャラクタの進行方向の領域をゲーム画面上で観察することになる。よって、現在動作対象としているオブジェクトよりも、キャラクタの進行方向側に新たなオブジェクトを配置するような制御を行うことで、当該新たなオブジェクトの存在を明確にプレーヤに知らせることが可能になり、ゲームプレイをスムーズにできる。その他、経過時間や操作入力の結果を用いることで、ゲーム内の状況に合わせた柔軟なオブジェクト制御が可能になる。なお、ゲームの進行履歴は上記の情報に限定されず、ゲーム処理部104によるゲーム処理の過程で取得可能な種々の情報に拡張することが可能である。
【0076】
またオブジェクト制御部114は、所与の条件が成立した場合に、オブジェクトの制御を楽曲のリズムに基づいて行う。このようにすれば、オブジェクトを楽曲に合わせて制御することが可能になる。例えば、オブジェクトの基準位置が設定されている場合において、当該基準位置に対するオブジェクトの変位量を、楽曲のリズムに合わせて変更する。このようにすれば、オブジェクトが楽曲に合わせて移動することになり、オブジェクトの挙動と楽曲の連動性を高めることが可能になる。
【0077】
オブジェクト制御部114は、ゲーム処理部104により、キャラクタの存在エリアとは別のエリアにキャラクタを移動可能にする処理が行われた場合、又は、判定部116により、オブジェクトに対するキャラクタの動作が成功したと判定された場合に、所与の条件が成立したと判定する。このようにすれば、移動制限が解除されゲーム内でのフェーズが進行した場合や、キャラクタ動作が成功した場合に、オブジェクトの挙動と楽曲が連動することになる。つまり、ゲーム内での状況が変化した(狭義にはプレーヤにとって好ましい方向に変化した)ことが条件となるため、オブジェクトの挙動をゲーム内の盛り上がりに合わせることが可能になる。
【0078】
またゲーム処理部104は、判定部116での判定結果に基づいて、キャラクタの存在エリアとは別のエリアにキャラクタを移動可能にする処理を行ってもよい。狭義には、ゲーム処理部104は、キャラクタが通行不可であった経路を通行可能にすることで、キャラクタを別のエリアに移動可能にする。
【0079】
このようにすれば、エリアの移動制限を行うこと、当該移動制限を判定結果に基づいて解除することが可能になるとともに、移動制限の解除を経路の通行不可/通行可能の切り替えで実現することが可能になる。具体的には、オブジェクトに対する動作が成功することが移動制限解除の条件となるため、先のエリアに進むためにはプレーヤは適切な操作を行う必要があり、興趣性の高いゲームシステムを実現できる。なお、通行不可であった経路を通行可能にする制御は、上記オブジェクト制御により実現されてもよい。例えば、足場がなくて渡れない溝や上れない壁が設けられることで通行不可であった経路上に、移動用の足場オブジェクトを配置する制御を行ってもよい。当該制御は、例えばゲーム処理部104の指示に基づいて、オブジェクト制御部114が実行する。このようにすれば、判定部116の判定結果を用いたオブジェクト制御を行うことで、自然に移動制限を解除する制御を実現できる。
【0080】
またゲーム処理部104は、ゲームの進行上の時間制限を制御する処理を行い、楽曲部分が関連づけられているエリア毎に、時間制限を行う。このように時間制限を設けた場合、ゲーム内での評価を高くするためには、各エリアを所定の時間内に通過することが必要となり、興趣性の高いゲームシステムを実現できる。特に、各エリアと時系列楽曲部分を対応付けた場合、時系列楽曲部分の演奏時間と時間制限を対応付けることで、プレーヤに対して自然に良い演奏を行わせることが可能になる。
【0081】
またキャラクタ処理部106は、楽曲の再生速度と関連づけられた移動速度で、キャラクタを移動させる処理を行ってもよい。ここで楽曲の再生速度とは、例えば楽曲のテンポ(BPMの値)である。このようにすれば、テンポの速い楽曲ではキャラクタが速く移動し、テンポの遅い楽曲ではキャラクタがゆっくり移動するため、楽曲に合わせたキャラクタ処理を実現することが可能になる。
【0082】
2.本実施形態の手法
次に本実施形態の手法について具体的に説明する。従来の音楽ゲームでは、ゲームシステム側で楽曲のリズムに応じた操作タイミングを指示し、プレーヤは指示された操作タイミングに合わせて操作を行う。しかし、従来の音楽ゲームで高評価を獲得するためには、適切なタイミングで適切な操作を行う必要があり、難易度が非常に高い。
【0083】
また従来より、アクションゲームは広く知られており、例えば3次元マップ上でキャラクタを移動させるゲームがある。アクションゲームでは、プレーヤが操作するキャラクタに、パルクール或いはフリーランニングを行わせるものもある。パルクール(フリーランニング)とは、壁や地形を活かし、走る・跳ぶ・登るなどの動作を組み合わせて、目的地まで効率的に移動する手法である。キャラクタにパルクールを実行させることで、複雑な地形のマップ(或いは障害物が配置されたマップ)であっても、キャラクタがスムーズに移動することが可能になる。
【0084】
しかし、従来のアクションゲームでは、パルクールはマップ上での移動手段に過ぎなかった。即ち、キャラクタによる跳ぶ・登る等のアクションは目的地に移動する過程で行われるものであり、それ自体がゲーム中で重要な意味を持つものではなかった。
【0085】
そこで本実施形態では、音楽ゲームとアクションゲームを組み合わせたゲームシステムを提案する。以下、ゲームシステムの概要について説明する。なお、本実施形態の手法は下記ゲームシステムに適用するものに限定されず、格闘技ゲームやレースゲーム等の種々のゲームに適用可能である。また以下では移動体としてキャラクタを主に例にとり説明を行う。
【0086】
2.1 フィールド・オブジェクトの設定とキャラクタの動作
図3(A)は、本実施形態のゲームシステムにおける3次元マップの俯瞰図であり、
図3(B)は表示部190に表示されるゲーム画面の例である。本実施形態に係るゲームシステムでは、仮想的な3次元空間に、キャラクタCA(広義には移動体)が移動するための地形を表す3次元マップが構築される。3次元マップは、例えばフィールドFEと、オブジェクトOB(
図3(A)の例ではOB1,OB2)を含む。
【0087】
フィールドFEは、キャラクタCAが移動可能な領域を表す。フィールドFEは、例えば
図3(A)に示すように地面に相当する水平面であるが、フィールドFEが斜面等を含んで構成されてもよい。オブジェクトOBは、フィールドFE上に配置される物体(障害物)である。
図3(A)の例であれば、オブジェクトOB1は円柱状の物体であり、オブジェクトOB2は梁と支柱を含む平均台状の物体である。
【0088】
以下では、フィールドFEは、キャラクタが特殊なアクション(跳躍、壁上り等)を必要とせずに移動(歩行,走行)可能な領域として説明を行う。また、オブジェクトOBは、当該オブジェクトOBが存在する経路上を移動するために、キャラクタCAが特殊な動作(アクション)をする必要がある領域(物体)である。オブジェクトOBは、歩行又は走行による通過が許容されない領域と言い換えることが可能である。
【0089】
ただし、ここでのフィールドFEとオブジェクトOBの区別は便宜上のものであり、ゲーム処理部104での3次元マップの処理は任意の形態で実現可能である。例えば、ゲーム処理部104が、フィールドFEとオブジェクトOBを1つの3次元マップ情報として、まとめて処理してもよい。或いは、3次元マップの固定部分をフィールドFEとし、可動部分をオブジェクトOBとして処理を行ってもよい。
【0090】
キャラクタCAは、プレーヤの操作に基づいて3次元マップ上を移動する。例えば、
図2(A)のアナログスティック18を所定方向に倒す操作入力が行われることで、キャラクタCAは、フィールドFE上を上記所定方向に対応する方向に歩行(走行)する。またキャラクタCAは、オブジェクトOBに対する動作を実行する。例えば、キャラクタCAがオブジェクトOB1と所定の位置関係にある状態で、
図2(A)の操作ボタン(例えば10、11、12、13のいずれか)が押下されることで、キャラクタCAはOB1を飛び越える跳躍動作を実行する。
【0091】
また、3次元空間には仮想カメラVCが配置される。上述した表示処理部120の各処理により、
図3(B)に示したように、表示部190には仮想カメラVCから3次元空間を撮像したかのような画像が表示される。
【0092】
図4~
図6(C)は、オブジェクトOBに対するキャラクタCAの動作の例である。アニメーション情報記憶部174は、動作に応じたキャラクタCAのアニメーション情報を記憶しており、アニメーション処理部108は、当該アニメーション情報の再生処理を行うことで、キャラクタCAに所定の動作を実行させる。
【0093】
図4は、円柱状のオブジェクトOB1に対するキャラクタCAの動作を説明する図である。キャラクタCAは、オブジェクトOB1に対して跳躍動作(vault)を行って、オブジェクトOB1を飛び越える。跳躍動作は、例えば
図4に示したように、オブジェクトOB1の一方側から助走を行い(A1)、左手をオブジェクトOB1の上面に着けて両足を右側に振り上げ(A2)、左手を離してオブジェクトOB1の反対側の地面に着地する(A3)という各工程を連続して行うことで実現される。なお、
図4のA1~A3は跳躍動作のうちの代表的な姿勢の例示であり、A1とA2の間(例えばA4やA5)、A2とA3の間でも、キャラクタCAの姿勢は連続的に(滑らかな動作となるように)変化する。
【0094】
図5(A)~
図5(C)は、
図4の跳躍動作に対応するゲーム画面の例である。
図5(A)がA1に対応し、
図5(B)がA2に対応し、
図5(C)がA3に対応する。
【0095】
図6は、平均台状のオブジェクトOB2に対するキャラクタCAの動作を説明する図である。キャラクタCAは、オブジェクトOB2に対してスライディング動作を行って、オブジェクトOB2の梁の下をくぐり抜ける。スライディング動作は、例えば
図6に示したように、オブジェクトOB2の一方側から助走を行い(B1)、両膝を付くような姿勢で地面を滑り(B2)、オブジェクトOB2の反対側の地面で立つ(B3)という各工程を連続して行うことで実現される。
【0096】
図7(A)~
図7(C)は、
図6のスライディング動作に対応するゲーム画面の例である。
図7(A)がB1に対応し、
図7(B)がB2に対応し、
図7(C)がB3に対応する。
【0097】
2.2 楽曲部分と再生処理
以下、ゲーム内で出力される音が、楽曲情報により表される楽曲である例について説明する。本実施形態におけるゲームシステムでは、プレーヤによるキャラクタCAの操作に基づいて、音の出力制御が行われる。具体的には、楽曲を楽曲部分に分割し、いずれの楽曲部分を再生するかをプレーヤ操作に基づいて決定する。ここでの楽曲部分とは、楽曲を演奏の時間軸方向に分割した一部や楽曲を楽曲パート毎に分割した一部などである。
【0098】
図8は、楽曲部分を説明する模式図である。楽曲は、一般的に曲調の異なる複数の部分から構成される。例えば、1つの楽曲はイントロ(Intro)、Aメロ(1st Verse)、Bメロ(2nd Verse)、サビ(Chorus)等から構成される。楽曲に応じて、各部分が複数回現れたり、Cメロ(Bridge)が追加されることもあるが、ここではイントロ、Aメロ、Bメロ、サビが時系列的に連続して演奏されることで、1つの楽曲が構成される例について説明する。即ち、イントロ、Aメロ、Bメロ、サビのそれぞれが、時間軸方向での楽曲部分(以下、時間軸楽曲部分と表記)となる。
【0099】
また、1つの時間軸楽曲部分(例えばAメロ)に着目した場合、当該時間軸楽曲部分はさらにパートごとに分割できる。以下、パートごとの楽曲部分をパート楽曲部分と表記する。
図8の例であれば、パート楽曲部分は「伴奏(リズム)」、「ギター」、「ドラム」、「キーボード」であり、「ギター」は、さらに「ギター1」、「ギター2」、「ギター3」に細分化される。
【0100】
時間軸楽曲部分とパート楽曲部分の両方が特定されることで、具体的な音の情報(例えば音符の集合情報、メロディー)が特定される。
図8の場合、例えば「Aメロのギターパート1」、「Aメロのドラムパート」、「Aメロのキーボードパート」等のそれぞれに対して、音の情報が対応付けられる。
【0101】
楽曲再生部112は、
図8の楽曲部分のうち、いずれの楽曲部分を再生対象とするかの決定処理を行い、決定された楽曲部分の再生処理を行う。具体的には、楽曲再生部112は、時系列楽曲部分のいずれか1つを選択する処理、及びパート楽曲部分の1又は複数を選択する処理を行う。以下、具体的に説明する。
【0102】
2.2.1 時系列楽曲部分の選択処理
本実施形態のゲームシステムでは、フィールドFEを複数のエリアに分割し、各エリアに時間軸楽曲部分を割り当てる。
【0103】
図9はフィールドFEに設定されるエリアと、時間軸楽曲部分の対応関係を説明する図である。
図9の例では、フィールドFEには5つのエリアAR1~AR5が設定される。AR1は時系列楽曲部分のうち、イントロが対応する。AR2はAメロに対応し、AR3はBメロに対応し、AR4はサビに対応する。AR5はゴール領域であり、楽曲の終了に対応する領域である。なお、AR5をアウトロ(Outro,終結部)に対応させてもよい。
【0104】
楽曲再生部112は、プレーヤの操作するキャラクタCAが存在するエリアを判定し、当該エリアに対応する時系列楽曲部分を再生対象として選択する処理を行う。
図9の例であれば、キャラクタCAがエリアAR1に存在すると判定されたらイントロが再生対象となり、キャラクタCAがAR2に存在すると判定されたらAメロが再生対象となる。その他のエリアについても同様である。
【0105】
なお、具体的な再生位置、例えばAメロの何秒目を再生すればよいかは、例えば経過時間の情報により特定される。例えば、キャラクタCAがAR2にx秒だけ継続して存在している場合、楽曲再生部112は、音出力部192に対してAメロのx秒目の出力を指示する。
【0106】
楽曲は時系列楽曲部分のそれぞれの長さが決まっている。例えば楽曲情報は、イントロが楽曲開始(0秒)からt1秒まで、Aメロがt1秒からt2秒まで、Bメロがt2秒からt3秒まで、サビがt3秒からt4秒まで、という各時系列楽曲部分の再生タイミング(再生時間)の情報を含む。そのため、当該楽曲についての「良い演奏」とは、イントロ~サビの各時系列楽曲部分を規定の長さだけ再生対象とする演奏である。
【0107】
つまり「良い演奏」を実現するための操作とは、初期存在エリアがAR1であるキャラクタCAを、t1秒経過時にAR2に移動させ、t2秒経過時にAR3に移動させ、t3秒経過時にAR4に移動させ、t4秒経過時にAR5に移動させる、という操作になる。このような操作がプレーヤにより行われた場合、時系列楽曲部分の遷移がスムーズに行われ、プレーヤに爽快感を与えることが可能になる。
【0108】
ただし、望ましい遷移タイミング(上述したt1~t4等)は、楽曲自体を暗記しているプレーヤや、音楽的な知識が豊富なプレーヤでなければ把握が難しく、エリア移動を完全にプレーヤに委ねたのではゲームの難易度が高くなってしまう。よって本実施形態のゲームシステムでは、エリア間の移動をガイドするためのガイドキャラクタをゲーム画面上に表示してもよい。例えば、ガイドキャラクタは、
図3(A)に示した3次元空間のうち、ゲーム画面で視認しやすい高い位置を飛んで移動する鳥等の飛行オブジェクトである。
【0109】
図9のROは、ガイドキャラクタの移動経路の例である。ROに示したように、ガイドキャラクタは、AR1からAR5を順次移動する。そしてガイドキャラクタは、AR1とAR2の境界である地点P1を楽曲開始からt1秒だけ経過したタイミングで通過するように、移動制御が行われる。同様にガイドキャラクタは、P2をt2秒で通過し、P3をt3秒で通過し、P4をt4秒で通過するように制御される。プレーヤは自身の操作するキャラクタCAをガイドキャラクタに合わせて移動させることで、自然に「良い演奏」を実現することが可能になる。
【0110】
なお、ここではエリア間の移動がいつでも実行可能であることを想定している。ただし、エリア間の移動を制限し、所与の条件が満たされた場合に当該制限を解除する変形実施も可能である。詳細については後述する。
【0111】
2.2.2 パート楽曲部分の選択処理(再生態様の変更制御)
キャラクタCAが所定のエリア(例えばAR3)に存在すると判定され、対応する時系列楽曲部分(例えばBメロ)が再生される際、ギターパートのみが再生対象となる場合に比べて、ギター、ドラム、キーボードの3つのパートが再生対象となる方が、音の厚みが増すため「良い演奏」になると考えられる。或いは、ギターについても1小節に少数の音を演奏する場合に比べて、多数の音を演奏する場合の方が複雑な演奏であり「良い演奏」になると考えられる。なお、音の数は時系列方向で増やすもの(2分音符1つを4分音符2つに変える等)であってもよいし、1タイミングでの音を増やすもの(単音を和音に変える等)であってもよい。
【0112】
本実施形態では、キャラクタCAのオブジェクトOBに対する動作が成功したか否かを判定部116が判定し、楽曲再生部112は、判定結果に基づいてパート楽曲部分の選択処理を行う。オブジェクトOBに対する動作が成功すればするほど、選択されるパート数が増えたり、同じパートであっても単位時間当たり(例えば1小節当たり)の音の数が多い楽曲部分が選択対象となる。
【0113】
例えば本実施形態では、判定部116の判定結果に基づいて、パラメータ(以下、ビートパラメータと記載)を更新する。ビートパラメータは、キャラクタCAのオブジェクトOBに対する動作が成功したと判定された場合に増加し、失敗したと判定された場合に減少(或いは維持)されるパラメータである。
【0114】
図10は、ビートパラメータと、再生対象として選択されるパート楽曲部分の対応関係の例である。
図10に示すように、ビートパラメータがth1未満の場合は、伴奏(リズム)のみが再生対象となる。ここでの伴奏(リズム)とは、ベース等の演奏が行われるパートであってもよいし、単純に拍のタイミング(例えば後述する
図17のC1又はC2)で音が出力されるパートであってもよいし、ワルツやボレロ等の楽曲の種類に応じて音の出力タイミングが決定されるパートであってもよい。
【0115】
ビートパラメータがth1以上になると、伴奏(リズム)に加えて、ギター1が再生対象として選択される。ギター1は、ギターパートのうち相対的に音の数が少ない楽曲部分である。ビートパラメータがth1以上th2未満では、伴奏と音の少ないギターパートというシンプルな楽曲が出力される。
【0116】
ビートパラメータがth2以上になると、伴奏(リズム)に加えて、ギター2が再生対象として選択される。ギター2は、ギター1に比べて音の数が多い楽曲部分である。ビートパラメータがth2以上th3未満では、伴奏とギターという組み合わせはth1以上th2未満の場合と同様であるが、ギターの音の数が増えて厚みが増す。
【0117】
ビートパラメータがth3以上になると、伴奏(リズム)、ギター3及びドラムが再生対象として選択される。ギター3は、ギター2に比べてさらに音の数が多い楽曲部分である。ビートパラメータがth3以上th4未満では、ギターの音が増え、さらに楽器の種類も増えるため、th3未満の場合に比べて音の厚みが増す。
【0118】
ビートパラメータがth4以上になると、伴奏(リズム)、ギター3、ドラム及びキーボードが再生対象として選択される。この場合、さらに楽器の種類が増えるため、th4未満の場合に比べて音の厚みが増す。
【0119】
オブジェクトOBに対するキャラクタCAの動作が成功したか否かは、オブジェクトOBの種類と、プレーヤによる操作入力(例えばプレーヤが押下したボタンの種類)の組み合わせを判定すればよい。例えば、オブジェクトOB1の前で跳躍系の動作に対応するボタンを押下すれば
図4の動作が成功したと判定され、オブジェクトOB2の前でスライディング系の動作に対応するボタンを押下すれば
図6の動作が成功する。例えば記憶部170は、オブジェクトの種類と、成功と判定される操作入力を対応付ける対応付け情報を記憶しておき、判定部116は当該対応付け情報を参照して判定処理を実行する。
【0120】
下に隙間のないオブジェクトOB1の前でスライディング系の動作に対応するボタンを押下したり、オブジェクトOBに歩いて衝突した場合は動作が失敗したと判定される。なお、オブジェクトOB2は跳躍により飛び越えることも可能であるため、所与の種類のオブジェクトOBに対して、成功と判定される操作入力が複数あることは妨げられない。
【0121】
このように、オブジェクトOBに対するキャラクタCAの動作は、容易なプレーヤ操作により成功させることが可能である。そして
図10に示したように、オブジェクトOBに対する操作が成功すれば、音に厚みが出る。つまり本実施形態では、音楽的な知識が無かったりリズム感に乏しいプレーヤでも、容易に「良い演奏」を実現することができ、興趣性の高いゲームシステムを実現可能である。
【0122】
なお、以上の説明からわかるように「良い演奏」を実現するには、多数のオブジェクトOBを対象としてキャラクタCAに動作を行わせることが好ましい。しかし
図9に示したように、ガイドキャラクタの移動経路ROは比較的シンプルに設定される。そのため、例えば
図9の例であればAR21やAR41のように、ガイドキャラクタの移動経路ROからの距離が比較的遠い位置に、広い領域が存在することが考えられる。キャラクタCAの移動をガイドキャラクタの移動経路ROに合わせてしまうと、AR21やAR41等の領域に配置されたオブジェクトOBは、キャラクタCAによる動作の対象から外れてしまう。
【0123】
時系列楽曲部分の遷移のみを考えれば、ガイドキャラクタから離れないようにキャラクタCAを移動させればよいが、パート楽曲部分の選択を考慮すれば、あえてガイドキャラクタから離れて、AR21やAR41等の領域のオブジェクトOBでの動作を行う必要が出てくる。本実施形態では、安全を考慮してガイドキャラクタに追従するか、リスクを冒してガイドキャラクタから離れることでさらなる高評価を狙うか、という判断をプレーヤに行わせることで、興趣性の高いゲームシステムを実現できる。
【0124】
なお、同じオブジェクトOBに対して繰り返し動作を実行する場合はビートパラメータの増加幅を小さくし、新たなオブジェクトOBに対して動作を実行する場合はビートパラメータの増加幅を大きくしてもよい。或いは、ガイドキャラクタの移動経路ROに近いオブジェクトOBに対する動作を実行する場合はビートパラメータの増加幅を小さくし、移動経路ROから遠いオブジェクトOBに対して動作を実行する場合はビートパラメータの増加幅を大きくしてもよい。このようにすれば、ビートパラメータを効率的に上昇させるためには、ガイドキャラクタから離れる必要性が高くなるため、より興趣性の高いゲームシステムを実現できる。
【0125】
図11(A)は本実施形態の処理を説明するフローチャートである。
図11(A)は、例えばフレームごとに実行される処理である。この処理が開始されると、ゲーム処理部104は、操作部160に対してプレーヤの操作入力が行われたか否かを判定する(S101)。操作入力が行われた場合(S101でYes)、アニメーション処理部108は、操作入力に対応する動作をキャラクタに実行させるためのアニメーション処理を行う(S102)。S102の詳細については
図20等を用いて後述する。
【0126】
S102の処理後、又はS101でNoの場合、ビートパラメータの更新処理が行われる(S103)。
図11(B)は、ビートパラメータの更新処理を説明するフローチャートである。この処理では、キャラクタCAのオブジェクトOBに対する動作の判定が行われる(S201)。動作が成功した場合、ビートパラメータを増加させ(S202)、動作が失敗した場合、ビートパラメータを減少させる(S203)。そもそもオブジェクトOBに対する動作が行われていない場合(操作入力自体がなかった場合、操作入力がフィールドFEを歩行、走行するだけの操作であった場合等)、ビートパラメータは変更されない(S204)。なお、上述したように、オブジェクトOBの種類や配置に応じて、ビートパラメータの変更幅を調整してもよい。或いは、動作が連続して成功した場合(コンボが成立した場合)は、単発での成功に比べて増加幅を大きくする等の変形実施も可能である。
【0127】
プレーヤが何も操作していない時間が継続している場合に、厚みのある演奏が継続されてしまうことは好ましくないため、動作の失敗以外の要因でもビートパラメータを減少させる必要がある。しかし、ビートパラメータの値を急激に変化させる(例えば短時間で初期値に戻す)と、厚みのあった演奏が急に伴奏のみに変化することになるため、プレーヤに違和感を与えてしまう。よって本実施形態では、経過時間に関する情報に基づいてビートパラメータを変化させる。
【0128】
例えばゲーム処理部104は、所定時間の経過ごとに、ビートパラメータを所定値だけ減少させる(S205)。このようにすれば、プレーヤに違和感を与えないようなビートパラメータの管理が可能になる。また、ビートパラメータを高い値に維持するためには、継続的にオブジェクトOBに対する動作を成功させる必要が出てくるため、興趣性の高いゲームシステムを実現することも可能である。
【0129】
図11(A)に戻って説明を続ける。ビートパラメータの更新処理が完了したら、楽曲再生部112は、更新後のビートパラメータに基づいて、楽曲制御を行う(S104)。具体的には、キャラクタCAの存在エリアに基づいて時系列楽曲部分を決定し、ビートパラメータに基づいてパート楽曲部分を決定する。
【0130】
またビートパラメータは、フィールドFEに配置されるオブジェクトOBの制御に利用されてもよい(S105)。
【0131】
2.3 オブジェクト制御
図11(A)のS105に示したオブジェクトOBの制御の例について説明する。オブジェクトOBは、フィールドFEの所定位置に固定配置されることは妨げられない。ただし、オブジェクトOBがあらかじめ固定されている場合、複数のオブジェクトOBをどのような順番で移動していけばよいか、プレーヤにとってわかりにくくなってしまう。
【0132】
よって本実施形態のオブジェクト制御部114は、判定部116での判定結果に基づいて、キャラクタCAの動作対象になっているオブジェクトとは異なるオブジェクトに対する制御を行う。例えば、所与のオブジェクトOBに対する動作が成功した場合に、当該オブジェクトの近傍に次のオブジェクトOBが現れるように、オブジェクトOBの制御(3次元マップの更新処理)を行う。
【0133】
図12は、オブジェクト制御の具体例であり、オブジェクトOB1及びOB2については
図3(A)等と同様である。
図12では、プレーヤの操作により、キャラクタCAはオブジェクトOB1に対する動作、及びオブジェクトOB2に対する動作を行い、判定部116は動作が成功したと判定した。この場合、オブジェクト制御部114は、動作終了時のキャラクタCAの現在位置より、キャラクタCAの移動方向Vm側の位置に、新たにオブジェクトOB3、OB4を配置する。移動方向Vmは、例えばキャラクタCAの現在位置と、過去の位置との差分を表すベクトルである。新たなオブジェクトOB(OB3,OB4)は、瞬間的に現れてもよいし、フィールドFEの面からせり上がるように現れてもよい。或いは、変形例として後述するように、オブジェクトOBの動きを楽曲に合わせてもよい。
【0134】
このようにキャラクタの視界内(仮想カメラVCの撮像範囲内、ゲーム画面内)に入るように、次のオブジェクトを配置すれば、プレーヤは次々に現れるオブジェクトOBを対象として順次キャラクタCAの動作を実行すればよく、フィールドFE内を適切に移動することが可能になる。
図12の例であれば、プレーヤは、オブジェクトOB2を対象とした操作後、自然にオブジェクトOB3、OB4を対象とした操作を行うことが可能になる。
【0135】
なお、フィールドFE内でオブジェクトOBを配置可能な領域と、当該領域に配置されるオブジェクトの種類(形状)があらかじめ固定されていてもよい。この場合、オブジェクトOBの制御とは、各領域についてオブジェクトOBを出現させるか否かの制御となる。また、1つの領域について、配置可能なオブジェクトOBが複数通り設定されており、オブジェクト制御部114は、そのうちのいずれの種類のオブジェクトOBを出現させるかの制御を行ってもよい。或いは、フィールドFEの任意の位置に任意の種類のオブジェクトOBを配置可能にしておき、オブジェクト制御部114は、オブジェクトOBの種類及び配置位置を動的に決定してもよい。
【0136】
広義には、オブジェクトの制御には、ゲームの進行履歴が用いられる。ゲームの進行履歴とは、キャラクタの進行方向、及びプレーヤの操作入力の結果を含む。上記の例であれば、オブジェクトOB1やOB2に対する動作が成功したという操作入力の結果が取得された場合に、キャラクタの進行方向に新たなオブジェクト(OB3,OB4)を配置するオブジェクト制御が行われる。ただし、他の進行履歴を用いてオブジェクトOBの制御が行われてもよい。例えば、オブジェクト制御部114は、ゲームの経過時間に基づいて、オブジェクトの制御を行う。
【0137】
例えば
図9の例において、キャラクタCAがエリアAR2に存在する場合を考える。演奏開始からの経過時間Tがt1<T<t2であり、且つTとt2の差が十分大きい場合、キャラクタCAはある程度の時間エリアAR2に留まる余裕があり、AR3への移動を急ぐ必要がない。この場合、オブジェクト制御部114は、エリアAR3からの距離が相対的に遠い位置に次のオブジェクトOBを配置する制御を行う。このようにすれば、エリアAR2内に効率的にオブジェクトOBを配置し、キャラクタCAのオブジェクトOBに対する動作回数を増やすことが可能になる。
【0138】
Tとt2の差が小さい場合、時系列楽曲部分の遷移を考慮すれば、AR3への移動を念頭においたキャラクタCAの操作を、プレーヤに実行させるとよい。この場合、オブジェクト制御部114は、エリアAR3からの距離が相対的に近い位置に次のオブジェクトOBを配置する制御を行う。このようにすれば、キャラクタCAのエリアAR3への移動をスムーズに行わせることが可能になる。このように経過時間を考慮してオブジェクトOBを制御することで、ゲーム初心者であっても、時系列楽曲部分の遷移と、パート楽曲部分の選択のバランスがとれた、好ましい演奏を実現することが可能になる。
【0139】
或いは、オブジェクト制御部114は、一旦出現させたオブジェクトOBを所定時間の経過を条件に消失させる(非配置とする)制御を行ってもよい。このようにすれば、プレーヤはオブジェクトOBの出現後、速やかに当該オブジェクトOBの位置まで移動しなければ動作を実行できない。換言すれば、プレーヤがスムーズにキャラクタ操作を行った場合に、多数のオブジェクトOBで動作を行って楽曲の音を厚くすることが可能になり、興趣性の高いゲームシステムを実現できる。
【0140】
また、プレーヤの操作入力の結果に基づくオブジェクト制御とは、キャラクタCAのオブジェクトOBに対する動作が成功した場合に次のオブジェクトOBを追加し、失敗した場合に追加しない、といった単純な制御であってもよい。ただし、プレーヤの操作入力の結果として、より複雑な情報、例えば上述したビートパラメータの値を用いてもよい。
【0141】
例えばオブジェクト制御部114は、ビートパラメータが高い場合には、低い場合に比べて追加されるオブジェクトOBの数を多くしたり、追加されるオブジェクトOBの形状を複雑にする。このようにすれば、ビートパラメータが高いほど、追加されるオブジェクトOBに対するキャラクタCAの動作回数が増えたり、実行する動作が複雑に(派手に)なる。つまり、それまでの操作がうまくいっているほど、キャラクタCAに派手な動作を繰り出させることが可能になるため、興趣性の高いゲームシステムを実現できる。
【0142】
図13は、オブジェクト制御部114での処理を説明するフローチャートであり、
図11(A)のS105の処理に対応する。この処理が開始されると、オブジェクト制御部114は、ゲーム進行履歴を取得する(S301)。具体的には、ゲームの経過時間、キャラクタの進行方向、及びプレーヤの操作入力の結果を取得する。
【0143】
次にオブジェクト制御部114は、取得したゲーム進行履歴に基づいて、オブジェクトの配置位置の決定(S302)、及び追加配置するオブジェクトOBの数、種類の決定を行う(S303)。そしてオブジェクト制御部は、S302及びS303で決定した内容に基づいて、オブジェクトOBを実際に配置する処理、即ち3次元マップの更新処理を行う(S304)。
【0144】
2.4 アニメーション処理
以上で説明した手法により、キャラクタCAに種々の動作を行わせることで、自然に楽曲を演奏している感覚をプレーヤに与えることが可能になる。従来の音楽ゲームのように「良い演奏」のために複雑な操作が必要なく、また動作自体がアクロバティックであるため、プレーヤに強い爽快感を与えることが可能である。
【0145】
しかし、キャラクタCAが実行する動作には、当該動作において特徴的なタイミング(フレーム、姿勢)が存在する。例えば
図4~
図5(C)に示した跳躍動作であれば、オブジェクトOB1の上面に左手を付いて両足を振り上げる姿勢(A2)が特徴的である。そのため、A2(
図5(B))等の動作における特徴的なタイミング(以下、動作特徴タイミング)と、楽曲における特徴的なタイミング(以下、楽曲特徴タイミング)とが一致することが望ましい。動作特徴タイミングと楽曲特徴タイミングとの時間差が大きい場合、動作と楽曲の連動性が損なわれ、動作を用いて楽曲を演奏しているという感覚をプレーヤに与えることが難しくなってしまう。
【0146】
楽曲に合わせて動作するキャラクタアニメーションについては特許文献2に開示がある。しかし、特許文献2ではキャラクタの動作とプレーヤ操作が関連しないため、楽曲が決定された段階で当該楽曲に適したアニメーションを決定できる。それに対して本実施形態では、キャラクタCAの動作はプレーヤの操作入力に基づいて決定される。楽曲のどのタイミングで、どのような動作が実行されるかを事前に知ることができないため、特許文献2の手法を適用することは困難である。
【0147】
以下、キャラクタの動作と楽曲とをシンクロさせるためのアニメーション処理について説明する。
【0148】
2.4.1 基本的なアニメーション処理
アニメーション処理部108はアニメーション処理を行う。即ちキャラクタCAにアニメーション(モーション)を行わせるアニメーション再生処理を行う。このアニメーション再生処理は、アニメーション情報記憶部174に記憶されているアニメーション情報を再生することなどで実現できる。
【0149】
例えば
図14に示すように、キャラクタCA等を表すモデルオブジェクトMOBは、複数のパーツオブジェクト(腰32、胸34、首36、頭38、右上腕40、右前腕42、右手44、左上腕46、左前腕48、左手50、右股52、右すね54、右足56、左股58、左すね60、左足62)により構成されている。そして、これらのパーツオブジェクト(部位)の位置や回転角度(方向)は、スケルトンモデルを構成する骨B0~B19の位置(関節J0~J15の位置)や回転角度(親の骨に対する子の骨の相対的な回転角度)により特定される。なお、これらの骨、関節は仮想的なものであり、現実に表示されるオブジェクトではない。
【0150】
アニメーション情報記憶部174には、例えば、これらの骨(パーツオブジェクト、関節)の位置、回転角度がアニメーション情報(モーション情報)として記憶される。具体的には
図15に示すように、親の骨BMPに対する子の骨BMCの、X軸、Y軸、Z軸回りの回転角度α、β、γ等が、アニメーション情報として記憶される。
【0151】
なお、アニメーション情報の構造等は、
図14、
図15に限定されず、種々の変形実施が可能である。例えば骨の回転角度だけをアニメーション情報に含ませて、骨の位置(関節の位置)についてはモデルオブジェクトのモデルデータの中に含ませてもよい。また
図14の骨B1~B19以外に、モーション骨によるモデルオブジェクトの変形を補助する補助骨を設けてもよい。
【0152】
図16に本実施形態で使用されるアニメーション情報のデータ構造の例を示す。1つのアニメーション情報は、例えば時系列的に並べられた複数の姿勢データの集合であり、姿勢データは例えば各骨の回転角度を表すデータの集合である。
図16は、
図4に示した跳躍動作を実現するためのアニメーション情報の例であり、当該跳躍動作は0~N(Nは正の整数)の各フレームにおいて、キャラクタCAに対応する姿勢を取らせることで実現される。例えば
図16の0フレーム目が
図4のA1に対応し、k(kは1<k<Nの整数)フレーム目がA2に対応し、Nフレーム目がA3に対応する。
【0153】
またアニメーション情報は、キーフレームの情報を含む。キーフレームとは、当該アニメーション情報に対応するキャラクタCAの動作における、動作特徴タイミングを表すフレームのことである。例えば
図16のアニメーション情報は、A2に対応するkフレーム目がキーフレームであるという情報を含んでいる。即ち、処理対象(再生対象)であるアニメーション情報が決定されれば、当該アニメーション情報内でのキーフレームの位置、例えば「アニメーションの再生開始からkフレーム目」という相対的なタイミングを特定可能である。
【0154】
一方、楽曲側にも特徴的なタイミングが存在する。楽曲特徴タイミングは、例えば楽曲の拍のタイミングである。拍とは楽曲における基本的なリズムであって、拍のタイミングとは、4/4拍子の例であれば、
図17のC1のタイミングや、
図17のC2に示す裏拍と呼ばれるタイミングである。なお、具体的なタイミング間隔(拍の長さ、テンポ)は楽曲の速さ(BPMの値)に応じて変化する。特徴的なタイミングは楽曲の構成に依存することになるが、楽曲が特定されれば当該楽曲における楽曲特徴タイミングは特定可能である。なお、時系列楽曲部分に応じて楽曲特徴タイミングが変化する楽曲を用いてもよく、時系列楽曲部分に基づいて楽曲特徴タイミングが特定されてもよい。
【0155】
図18は、楽曲特徴タイミングと動作特徴タイミング(アニメーション情報のキーフレーム)の関係を示す図である。
図18の横軸は実時間であり、例えばゲーム開始からの経過時間(単位:msec)である。楽曲の再生が途中で停止することがないと仮定すれば、経過時間軸上での楽曲特徴タイミングの位置は、楽曲の再生開始時点で特定可能である。
【0156】
またアニメーション処理部108は、プレーヤの操作入力に基づいて、再生対象であるアニメーション情報の特定、及び、当該アニメーション情報の再生開始タイミングの特定処理を行う。具体的には、キャラクタCAの近傍に位置するオブジェクトOBの種類と、プレーヤによる操作入力の種類(例えば押下されたボタンの種類)に基づいて、再生対象であるアニメーション情報が特定される。また、プレーヤによる操作入力が実行されたタイミングに基づいて、アニメーション情報の再生開始タイミングが特定される。
【0157】
図18では、t
Sのタイミングを開始タイミングとして、
図16に示したアニメーション情報を再生する、という特定処理が行われた例を示している。フレームレートはゲームシステムの設計上既知であるため、経過時間軸上での各フレームの位置を特定することは容易である。或いは、アニメーション情報自体が、フレーム単位ではなく時間単位(例えばmsec単位)で姿勢データを保持していてもよい。
【0158】
図18に示すように、経過時間軸上でのキーフレームの位置(t
K)と、楽曲特徴タイミング(tm1~tm5)は一致しない。そのため、ここままアニメーション情報の再生処理を行うと、動作と楽曲の連動性が損なわれる。
【0159】
そこで本実施形態のタイミング処理部110は、基準タイミング、及び音のタイミングの特定処理を行い、アニメーション処理部108は、音のタイミングに合わせて、キャラクタCA(広義には移動体)のアニメーション処理を行う。より具体的には、アニメーション処理部108は、音のタイミングに基づいて、アニメーション処理に用いられるアニメーション情報の調整処理を行うものであり、音のタイミング情報に合わせてキャラクタCAが動作するように、調整処理を行う。
【0160】
図19は、調整処理を説明する図である。
図18に示したように、t
Sを開始タイミングとして単純に
図16のアニメーション情報の再生処理を行った場合、キーフレームの再生タイミングは、いずれの楽曲特徴タイミングとも一致しない。
【0161】
よって本実施形態では、タイミング処理部110は、まずキーフレームの再生タイミングを基準タイミングとして特定する。そしてタイミング処理部110は、基準タイミングに基づいて、調整先となる楽曲特徴タイミングである音のタイミングを特定する。
図19の例であれば、基準タイミングとは調整前のキーフレームの再生タイミングであるt
Kであり、再生開始タイミングt
Sとアニメーション情報(
図16)から特定可能である。また、音のタイミングt
Mとは、基準タイミングより時間的に後、且つ、基準タイミングに近い楽曲特徴タイミングであり、例えばt
M=tm3である。ただし、tm4やtm5が音のタイミングとなることは妨げられない。
【0162】
アニメーション処理部108は、特定された基準タイミングtKを、音のタイミングtMに一致させるような調整処理を行う。なお、ここでの一致させる処理とは、完全一致させる処理に限定されず、プレーヤに違和感を与えない程度に時間差を小さくする処理を含む。
【0163】
単純な調整処理としては、(1)アニメーションの再生開始タイミングを遅らせる処理、(2)キーフレームよりも前の所定範囲をスロー再生する処理、(3)キーフレーム前の所与のフレームをコピーして追加する処理、等が考えられる。(1)~(3)は、いずれも基準タイミングを時間的に後方にずらす処理であるため、ずれ量を基準タイミングと音のタイミングの時間差に合わせることで、基準タイミングと音のタイミングを一致させられる。
【0164】
しかし、上記(1)~(3)の処理では、キャラクタCAの動作が不自然になる場面も出てくる。例えば(1)の処理では、プレーヤが操作を行ってからキャラクタCAが動き出すまでのタイムラグが大きくなる。また(2)の処理では、キャラクタCAの動作が遅くなるし、(3)の処理では、キャラクタCAの動作が所定姿勢で一時停止する。例えば格闘ゲームにおいて、腕を前方に打ち抜くパンチアニメーションを再生する場合、前方へ腕を振り出す動作がスロー再生されてはパンチの迫力に欠けるし、途中で腕が停止してしまっては攻撃アニメーションとして明らかに不自然である。
【0165】
よって本実施形態の調整処理は、調整後のアニメーションが不自然とならないように行われることが望ましい。例えば、(1)の調整処理は、動き出しまでのタイムラグが小さい場合、具体的には基準タイミングと音のタイミングの時間差(例えば調整前のtKとtMの差)がある程度小さい場合に用いられる。
【0166】
(2)の調整処理は、スロー再生されても違和感を与えないような動作範囲を対象として実行される。例えば、パンチアニメーションにおいて、腕を振りかぶるテイクバック動作は多少ゆっくりでも問題無い。よってテイクバック動作に対応するフレーム範囲を対象として、(2)の調整処理を実行するとよい。スロー再生する処理は、具体的には補間処理を行ってフレームを追加する処理により実現できる。例えば各アニメーション情報は、(2)の調整処理の対象とできるフレーム範囲や、各フレーム範囲の調整可能幅の情報を含んでもよい。ここでの調整可能幅とは、広義には、当該フレーム範囲の動作をどの程度間延びさせても不自然にならないかを表すパラメータである。
【0167】
また、(3)の調整処理は、同じ姿勢が継続されても違和感を与えないようなフレームを対象として実行される。例えばパンチアニメーションにおいて、テイクバック後、且つ腕を振り出す前の姿勢で停止することは、力をためる動作、狙いを定める動作と捉えられるため不自然でない。よって当該フレームをコピー対象として(3)の調整処理を行うとよい。また、コピー対象は1フレームに限定されず、複数のフレームを対象としてもよい。例えば
図4の跳躍動作の場合、助走の歩数を増やせばキーフレームの再生タイミングを遅らせることができ、且つ、歩数が増えることは動作として不自然でない。よって助走の2歩に対応するフレーム区間をコピーの対象として(3)の調整処理を行ってもよい。コピーしたフレームの追加箇所や、踏み切る足、動作開始時に踏み出す足等の調整まで考慮すれば、助走の1歩に対応するフレーム区間をコピーの対象とすることも妨げられない。各アニメーション情報は、(3)の調整処理の対象とできるフレーム(フレーム範囲)の情報を含んでもよい。
【0168】
また、(2)と(3)の調整処理を組み合わせることも妨げられない。例えば、助走の歩数を増やす(3)の調整処理を行いつつ、助走のピッチを変更する(2)の調整処理を行う。このようにすれば、キャラクタCAに自然な動作を行わせつつ、キーフレームの再生タイミングを柔軟に変更することが可能になる。当然、(1)の調整処理との組み合わせも妨げられない。
【0169】
図20は、アニメーション処理を説明するフローチャートである。
図20は、
図11(A)のS102の処理に対応する。この処理が開始されると、S101での操作入力に基づく操作情報が取得される(S401)。S401での処理は、例えばプレーヤにより押下されたボタンを特定する情報の取得処理である。
【0170】
またキャラクタCAの存在エリアに基づいて、再生対象となる時系列楽曲部分が特定される(S402)。なお、
図20には不図示であるが、再生対象となるパート楽曲部分が特定されてもよい。この処理は、楽曲再生部112で行われる。また、楽曲自体から楽曲特徴タイミングが特定可能である場合、S402の処理は省略可能である。
【0171】
アニメーション処理部108は、キャラクタCAの近傍に位置するオブジェクトOBと、S401で取得した操作情報に基づいて、処理対象となるアニメーション情報を決定する(S403)。タイミング処理部110は、
図18に示したように、基準タイミング(t
K)と、音のタイミング(t
M)を決定する(S404、S405)。
【0172】
アニメーション処理部108は、S404で決定された基準タイミングを、S405で決定された音のタイミングに一致させるように、アニメーション情報の調整処理を行う(S406)。S406の処理は、上述したように、動作が不自然にならないようなスロー再生(補間処理)や、所定フレーム(フレーム区間)のコピーにより実現できる。アニメーション処理部108は、調整処理後のアニメーション情報の再生処理を行う(S407)。
【0173】
2.4.2 アニメーション情報の決定処理
以上では、
図20のS403に示したように、オブジェクトOBと操作情報に基づいて処理対象のアニメーション情報が1つに特定(決定)される例を示した。しかし、アニメーション情報の決定処理は種々の変形実施が可能である。
【0174】
図21は、アニメーション情報記憶部174に記憶されるアニメーション情報の例であり、1行が1つのアニメーション情報に対応する。各アニメーション情報は、ファイル名と、動作属性、キーフレームの情報を含む。また
図21では省略しているが、各アニメーション情報は、
図16に示したように、各フレームでの姿勢(骨の位置、回転角度)の情報を含む。また調整処理において上述したように、アニメーション情報は、調整処理の対象として選択可能なフレーム等の情報を含んでもよい。
【0175】
図21に示すように、キャラクタCAに跳躍を行わせるアニメーションは1つに限定されず、FA1、FA2…のように複数のアニメーション情報が存在する。例えばパルクールでは、片足を跳躍対象物に載せるセーフティヴォルト、横方向から跳躍対象物に進入するスピードヴォルト、両手を跳躍対象物について当該手の間に両足を通すコングヴォルト等、多数の跳躍技が知られている。例えばキャラクタCAにセーフティヴォルトを行わせるアニメーション情報をFA1、スピードヴォルトを行わせるアニメーション情報をFA2、といったように、アニメーション情報記憶部174は、それぞれの跳躍動作を1つのアニメーション情報として管理する。
【0176】
スライディングについても同様であり、
図6のように膝を曲げて上半身を反らせるようなスライディング動作だけでなく、進行方向に足を延ばすフットファーストスライディングや、進行方向に対して両手を前に出すヘッドスライディング等が考えられる。アニメーション情報記憶部174は、それぞれが1つのスライディング動作を表すアニメーション情報を複数記憶する(FB1,FB2等)。
【0177】
その他、パルクールでは壁面によじ登る動作(クライムアップ、ウォールラン等)や、高い位置から安全に着地する動作(ランディング)も多用され、それぞれ複数通りの動作が知られている。よってアニメーション情報記憶部174は、これらについてもそれぞれの動作を実現するためのアニメーション情報を記憶する。さらに、アニメーション情報記憶部174が記憶するアニメーション情報は以上のものに限定されず、宙返り(フリップ)等、他の動作を行うアニメーション情報を含んでもよい。
【0178】
アニメーション処理部108は、
図21のような多数のアニメーション情報の中から、処理対象となる1つのアニメーション情報を決定する決定処理を行う。なお、オブジェクトOBと操作情報の種類から、
図21における動作属性を決定する処理も、アニメーション情報の決定処理に含まれ、当該動作属性のアニメーション情報が1つであれば、決定処理はそれで完了する。ただし、1つの動作属性に複数のアニメーション情報が含まれる場合、アニメーション処理部108は、そこから1つのアニメーション情報を決定する必要がある。
【0179】
アニメーション情報の決定処理は種々の手法により実現可能である。例えばアニメーション処理部108は、ビートパラメータや経過時間等のゲーム進行履歴に基づいて、決定処理を行ってもよい。一例としては、ビートパラメータが高いほど、或いは経過時間が長いほど、キャラクタCAの動きが激しいアニメーション情報が処理対象として決定される。動きが激しいとは、動き量が大きいことを表してもよいし、動きが速い(単位時間当たりの動き量が大きい)ことを表してもよい。このようにすれば、動作が成功してビートパラメータが上がると、音の厚みが増すとともに、キャラクタCAの動作も派手になるため、ゲームを盛り上げたり、プレーヤに爽快感を与えることが可能になる。或いは、経過時間が長くなればキャラクタCAがゴールに近づいている蓋然性が高くなるため、キャラクタCAの動作も派手にすることでゲームを盛り上げることが可能になる。
【0180】
或いは、アニメーション処理部108は、楽曲の情報に基づいて決定処理を行ってもよい。例えば楽曲情報記憶部171は、音量、音程、音色等のパラメータが関連付けられた楽曲情報を記憶する。具体的には、楽曲特徴タイミング(音のタイミング)のそれぞれについて、各特徴タイミングでの音量、音程、音色の情報が関連付けられる。アニメーション処理部108は、アニメーションの再生予定期間において、楽曲がどのような音量、音程、音色であるかを判定する。このようにすれば、再生される楽曲の状態に合わせて、キャラクタCAを動作させることが可能になる。
【0181】
例えば、音量が大きいほど、音程が高いほど、キャラクタCAの動きが激しいアニメーション情報が処理対象として決定される。音量(音程)は、単純な大小(高低)ではなく、所定期間内での音量変化(音程変化)を処理に用いてもよい。例えば音量変化(音程変化)が大きい場合に、キャラクタCAの動きが激しいアニメーション情報が処理対象として決定される。このようにすれば、楽曲が盛り上がっている場面で、キャラクタCAの動作を派手にして、ゲームを盛り上げることが可能になる。音色については、実際の音の波形やフーリエ変換の結果を用いてもよいが、出力されるパート(楽器)の情報を用いてアニメーション情報の決定処理が行われてもよい。例えばギターやドラムが出力される場合は、キャラクタCAの動きが激しいアニメーション情報を処理対象とし、ピアノが出力される場合は、キャラクタCAの動きが少ないアニメーション情報を処理対象とする、といった決定処理が考えられる。
【0182】
或いは、アニメーション処理部108は、音のタイミング情報に基づいて決定処理を行ってもよい。例えば、動作属性が「跳躍」であるという決定処理が行われた場合、タイミング処理部110は、跳躍動作に対応する複数のアニメーション情報(FA1,FA2,…)の各アニメーション情報を対象として、基準タイミング及び音のタイミングを求める。そしてアニメーション処理部108は、基準タイミングを音のタイミングに合わせやすいアニメーション情報を、処理対象として決定する。ここでの「合わせやすい」とは、単純には基準タイミングと音のタイミングの時間差が小さいことを表す。ただし、判断基準はこれに限定されず、調整処理を行った後のキャラクタCAの動作が自然であるか否かに基づいて、アニメーション情報を決定してもよい。換言すれば、アニメーション処理部108(タイミング処理部110)は、候補となる複数のアニメーション情報に対して調整処理を試行し、調整処理が適切に実行できるアニメーション情報を再生対象として決定する。
【0183】
また以上では、簡略化のために、1つのアニメーション情報に含まれるキーフレームが1つである例を説明した。しかし動作における特徴的なタイミング(フレーム、動作)は2つ以上であってもよく、その場合のアニメーション情報は複数のキーフレームを含む。例えば、
図4の動作において、助走の各足の着地、踏み切り、跳躍後の着地等をキーフレームと考えてもよく、この場合、
図4の跳躍動作に対応するアニメーション情報(
図16は、複数のキーフレームを含む。
【0184】
或いは、キャラクタCAに複雑な動作を行わせるアニメーション情報が用いられてもよい。
図22(A)~
図22(F)は、抱え込みの側方宙返り(以下、側宙)を行う動作の例であるが、側宙を組み合わせた跳躍動作を用いてもよい。例えば、キャラクタCAは、オブジェクトOB1よりも手前側から移動を開始し、助走から踏み切ってまずオブジェクトOB1の上面に着地し、そこから
図22(A)~
図22(F)に示した抱え込みの側宙を行って、オブジェクトOB1の奥側に着地する。キャラクタCAの一部がオブジェクトOB1又はフィールドFEに接地するという観点から考えれば、オブジェクトOB1の上面への着地、及び側宙によるフィールド面への着地の両方が、特徴的なタイミングとなる。動作としても、OB1に乗るまでの動作と、側宙によりOB1から降りる動作を分けて考えることが自然であり、上記跳躍動作は少なくとも2つの特徴を有する。即ち、キャラクタCAに上記跳躍動作を行わせるアニメーション情報は、複数のキーフレームを有する。その他、複数のキーフレームを有するアニメーション情報は種々考えられる。
【0185】
キーフレームが複数存在するアニメーション情報では、基準タイミングも複数設定される。例えば、タイミング処理部110は、第1のキーフレームに対応する第1の基準タイミングと第2のキーフレームに対応する第2の基準タイミングを決定し、第1の基準タイミングに対応する第1の音のタイミングと第2の基準タイミングに対応する第2の音のタイミングを決定する。アニメーション処理部108は、第1の基準タイミングを第1の音のタイミングに合わせ、第2の基準タイミングを第2の音のタイミングに合わせる処理を、調整処理として実行する。
【0186】
図23(A)~
図23(C)は、複数のキーフレームを含むアニメーション情報を対象とした調整処理を説明する図である。
図23(A)に示すように、基準タイミング及び音のタイミングが決定された場合、アニメーション処理部108は、開始タイミングから第1の基準タイミングまでの第1の調整期間、及び第1の基準タイミングから第2の基準タイミングまでの第2の調整期間を対象として、上述した調整処理を実行する。
【0187】
例えば、アニメーション処理部108は、第1の調整期間を延長して第1の基準タイミングを第1の音のタイミングに合わせる調整処理を行い(
図23(B))、その後、第2の調整期間を延長して第2の基準タイミングを第2の音のタイミングに合わせる調整処理を行う(
図23(C))。ただし上述したように、キャラクタCAに自然な動作を実行させるという観点から、各調整期間は延長可能な範囲が制限される。そのため、
図23(B)と
図23(C)の少なくとも一方の調整処理を実現できない場面も考えられる。或いは、あえて第1の基準タイミングと第1の音のタイミングを揃えないことで、第2の基準タイミングの調整がうまくいくといった場面も想定される。よってアニメーション処理部108での調整処理は、時系列的に前の調整期間から順次延長幅を決定する処理に限定されず、全体を考慮した上で各調整期間の最適な延長幅を決定する処理により実現されてもよい。例えばアニメーション処理部108は、所与の評価関数を設定し、当該評価関数による評価値が極大となるように、各調整期間の延長幅を決定する。
【0188】
アニメーション処理部108は、例えば上記評価関数の評価値に基づいて、再生対象となるアニメーション情報の決定処理を行ってもよい。評価関数は、キーフレームの数、音のタイミングに合わせることができた基準タイミングの数(以下、調整成功数)、音のタイミングに合わせることができなかった基準タイミングの数(以下、調整失敗数)等に基づいて、評価値を決定する関数である。例えば、調整成功数が多いほど値が大きくなり、調整失敗数が多いほど値が小さくなるような評価関数を用いる。キーフレーム数をどのように評価に用いるかは種々の考え方があるが、例えばキーフレーム数が動作の複雑さに関係することを考慮し、キーフレーム数が多いほど値が大きくなるような評価関数を用いる。
【0189】
選択されるアニメーション情報は、評価関数の具体的な形式に応じて変化することになる。例えばアニメーション処理部108は、元々のキーフレーム数が同じ複数のアニメーション情報が存在する場合、調整成功数が多いアニメーション情報を処理対象として決定する。或いは、アニメーション処理部108は、全キーフレーム数に対する調整成功数の割合が高いアニメーション情報を処理対象としてもよい。
【0190】
また、以上では楽曲特徴タイミングとして、
図17のC1やC2に示した拍のタイミングを用いた。ただし楽曲特徴タイミングはこれに限定されない。例えば、所定パートの音が出力されるタイミングを楽曲特徴タイミングとしてもよい。例えば、
図8に示した例において、ギターパートの出力タイミングを楽曲の特徴タイミングとする。ギター1では、音の数が相対的に少ないため、楽曲特徴タイミングも少ない(例えば1小節に1タイミング)。ギター3では、音の数が相対的に多いため、楽曲特徴タイミングも多い(例えば1小節に4タイミング、8タイミング等)。この場合、ゲームの進行履歴(狭義にはビートパラメータ)に応じて、音のタイミングが変化することになる。
【0191】
楽曲特徴タイミングが少ない場合、音のタイミング(tM)として選択可能なタイミングが限定される。そのため、基準タイミング(キーフレーム)が多いアニメーション情報では調整失敗数が増えやすい。結果として、アニメーション情報の決定処理では、基準タイミング(キーフレーム)の少ないアニメーション情報が処理対象となりやすくなる。
【0192】
一方、楽曲特徴タイミングが多い場合、音のタイミングの候補が増えるため、基準タイミング(キーフレーム)が多くても調整成功数が増えやすく、複雑な動作を行うアニメーション情報が処理対象となりやすい。このように楽曲特徴タイミング(音のタイミング)を可変とすることでも、状況に応じたアニメーション情報の決定処理が可能になる。
【0193】
図24は、アニメーション処理を説明する他のフローチャートである。S501及びS502は、
図20のS401、S402と同様である。
図24の例では、パートに応じて楽曲特徴タイミングを変更することを想定し、パート楽曲部分を決定する処理を追加している(S503)。
【0194】
また、アニメーション処理部108は、キャラクタCAの近傍に位置するオブジェクトOBと、S501で取得した操作情報に基づいて、処理対象となるアニメーション情報の候補セット(候補アニメーションセット)を決定する(S504)。例えば、操作情報とオブジェクトOBから動作属性が「跳躍」に決定された場合、候補アニメーションセットとは、跳躍動作に対応する複数のアニメーション情報(FA1,FA2,…)の集合である。
【0195】
そしてアニメーション処理部108は、候補アニメーションセットから1つのアニメーション情報を選択し(S505)、タイミング処理部110は、選択したアニメーション情報を対象として、基準タイミング及び音のタイミングを決定する(S506,S507)。アニメーション処理部108は、基準タイミング及び音のタイミングに基づいて評価値を算出する(S508)。ここでの評価値は、例えば上述した評価関数の極大値である。
【0196】
アニメーション処理部108は、候補アニメーションセットに未処理のアニメーション情報が残っているかを判定し(S509)、未処理のアニメーション情報が存在する場合にはS505に戻り、処理を継続する。候補アニメーションセットの全てのアニメーション情報の評価値が算出されたら(S509でNo)、当該評価値に基づいて処理対象のアニメーション情報を決定する(S510)。
【0197】
アニメーション情報決定後の調整処理(S511)、再生処理(S512)については、
図20のS406、S407と同様である。なお、評価値を評価関数の極大値とする例であれば、S511の調整処理は、S508の結果をそのまま用いればよい。
【0198】
なお、
図24では候補アニメーションセットの全てを評価対象とする例を示した。しかし、S512の再生処理は、S501の操作情報の取得後(厳密に言えば
図11(A)のS101の操作入力後)、できるだけ速やかに実行することが望ましい。再生処理までに時間がかかってしまうと、プレーヤが操作したにもかかわらず、アニメーションがなかなか開始されずに違和感を与えてしまう。
【0199】
よってアニメーション情報の決定処理、及び調整処理が高速で行われるように、処理負荷を軽減することが望ましい。よって例えば、候補アニメーションセットの全てを評価対象とするのではなく、評価値が所定閾値以上のアニメーション情報が見つかった段階で、決定処理を終了するといった変形実施が可能である。
【0200】
2.5 変形例
以下、いくつかの変形例について説明する。
【0201】
(変形例1)
以上の説明では、時系列楽曲部分内での再生位置は、経過時間(エリア存在時間)で決定される例を示した。例えば、キャラクタCAがエリアAR2にx秒だけ継続して存在した場合、Aメロのx秒目が再生される。即ち、エリアに応じた時系列楽曲部分の遷移という制限はあるものの、時系列楽曲部分内での楽曲の進行は時間とともに自動的に行われる。
【0202】
ただし、本実施形態ではオブジェクトOBに対するキャラクタCAの動作を演奏に用いる。つまり、楽曲の進行もプレーヤの操作(キャラクタCAの動作)に関連させるとよく、キャラクタCAが静止しているのに楽曲が進行することは好ましくない。
【0203】
よって本実施形態では、キャラクタCAの動作に基づいて、時系列楽曲部分内での再生位置を決定してもよい。例えば、キャラクタCAの動作が行われることで増加するパラメータ(以下、メロディパラメータ)を設定し、キャラクタCAの存在エリアとメロディパラメータに基づいて、時系列楽曲部分内での再生位置を決定する。なお、ここでのキャラクタCAの動作とは、オブジェクトOBに対する動作であってもよいし、フィールドFEを歩行、走行する動作であってもよい。また、メロディパラメータは、キャラクタCAが次のエリアに移動した場合、即ち、時系列楽曲部分の遷移が行われた場合に、初期化されるパラメータであってもよい。
【0204】
このようにすれば、キャラクタCAが動いていないときは楽曲の進行が停止するため、キャラクタCAの動作と楽曲との連動度合いを高めることが可能になる。
【0205】
(変形例2)
図12に示したように、オブジェクト制御部114は、判定部116の判定結果に基づいて、キャラクタCAの動作対象と異なるオブジェクトOBに対する制御を行う。ここでオブジェクト制御部114は、オブジェクトOBの挙動を楽曲(狭義には楽曲のテンポ、リズム)に合わせるような制御を行ってもよい。
【0206】
例えば、オブジェクト制御部114は、オブジェクトOBを楽曲の拍の周期に合わせて振動させる。或いはオブジェクト制御部114は、イコライザ画面を模した動きをオブジェクトOBに行わせる。イコライザとは、楽曲を複数の周波数成分に分け、各周波数成分の信号レベルの調整する機器であるが、各周波数成分の信号レベルをグラフとして表示する画面がインターフェースとして広く用いられる。例えばオブジェクト制御部114は、所与の周波数成分の信号レベルに合わせて、オブジェクトOBの位置(基準位置に対する移動量)を制御する。或いは、所定方向に複数のオブジェクトOBを配置し、各オブジェクトをそれぞれ異なる周波数成分に割り当ててもよい。このようにすれば、オブジェクト群があたかもイコライザのインターフェースのように機能する。
【0207】
また、ここではオブジェクトOBの位置、動きを制御する例を示したが、オブジェクトOBの色や質感等を制御することも妨げられない。
【0208】
本実施形態では、キャラクタCAの動作と楽曲の連動(
図8や
図9)、キャラクタCAの動作とオブジェクト制御の連動(
図12)が可能であったが、本変形例によれば、さらに、オブジェクトOBの挙動と楽曲の連動が可能になる。このように、キャラクタ動作(プレーヤ操作)、楽曲、オブジェクトという各要素の連動度合いを高めることにより、自分がゲーム内の音楽やフィールドをコントロールしている感覚を、プレーヤに対して強く与えることが可能になる。
【0209】
なお、楽曲に基づくオブジェクト制御は、所与の条件が満たされた場合に実行されてもよい。所与の条件とは、オブジェクトに対するキャラクタの動作が成功したと判定された場合や、ビートパラメータの値が所定閾値以上になった場合である。即ち、プレーヤによる操作が適切に行われ、楽曲が盛り上がっている場合に、オブジェクトOBと楽曲が連動するため、より興趣性の高いゲームシステムを実現できる。なお、後述する変形例5のように、エリア間移動が制限される実施形態の場合、当該移動の制限が解除されたことを、楽曲に基づくオブジェクト制御の条件としてもよい。
【0210】
(変形例3)
楽曲制御やオブジェクト制御に用いられる動作は、オブジェクトOBを対象としたものである例を説明した。しかしキャラクタCAのフィールドFE(地面、床面)での動作に基づいて、楽曲制御等が行われてもよい。
【0211】
例えば、パルクールでは
図22(A)~
図22(F)に示した側宙の他、側転、後方宙返り(バク宙)、前方宙返り等の回転技が用いられることがあり、これらの技は障害物や壁面の存在しない平面的な領域でも実行可能である。これらの動作も、歩行や走行等の単純な動作に比べて見栄えがよく、プレーヤに爽快感を与える。
【0212】
例えばゲーム処理部104は、オブジェクトOBを対象としない特定の動作が行われた場合に、ビートパラメータを増加させる処理を行う。このようにすれば、当該特定の動作についても、オブジェクトOBに対する動作と同様に、動作結果が楽曲やオブジェクトOBの制御に反映される。
【0213】
(変形例4)
以上では、アニメーション情報の調整処理の対象となる移動体が人型のキャラクタCAである例を説明した。しかし、移動体はこれに限定されず、例えばレースゲームにおける車やバイク、或いは飛行機は船舶等の乗り物であってもよい。この場合、車両等の特徴的な動作(方向転換、スピン、障害物に乗り上げることによるジャンプ等)が行われるタイミングと、楽曲特徴タイミングを合わせることが可能になる。
【0214】
或いは、
図3に示した仮想カメラVCを移動体としてもよい。
図3ではキャラクタCAの後方に仮想カメラVCを配置する例を示したが、カメラアングル(仮想カメラの位置、光軸方向)を可変とすることで、多様な表示画面を生成することが可能になる。カメラワークとして、パン、チルト、ズームイン、ズームアウト等、種々の技法が知られており、仮想カメラVC自体の動き、或いは被写体との関係から、特徴的なタイミングを規定することが可能である。
【0215】
仮想カメラVCを移動体とすることで、特徴的な表示画像が表示されるタイミングと、楽曲の特徴タイミングを合わせることが可能になる。
【0216】
(変形例5)
図9を用いて上述した例では、フィールドFEに設定されたエリア(AR1~AR5)間の移動は自由であり、ガイドオブジェクト等を利用することで、プレーヤに対して適切なタイミングでの移動を促していた。ただし、エリア間の移動をあらかじめ制限しておいてもよい。
【0217】
このようにすれば、プレーヤが楽曲自体の進行を無視して先のエリアに進むことを抑制可能である。例えばAメロの演奏が終わっていないのに、Bメロに対応するエリアAR3に進入することを抑制できる。
【0218】
この場合、制限の解除条件を設定する必要がある。単純には、経過時間に基づいて移動制限が解除される。例えばAR2からAR3への移動制限は、Aメロを演奏し終わるだけの時間が経過した場合に解除される。或いは、プレーヤの操作入力の結果、より具体的にはビートパラメータの値が所定閾値以上であることを制限解除の条件としてもよい。例えば、AR2である程度の動作を行い、Aメロを厚く演奏できた場合に、AR3への移動が可能になる。移動制限の解除は、例えばエリア間の移動経路の通行可能/通行不可を切り替える制御により実現される。
【0219】
また、ゲーム処理部104は、各エリアに時間制限を設けてもよい。ここでの時間制限とは、例えば各エリアに継続して存在することが許容される時間の上限である。そして、ゲーム処理部104は、キャラクタCAが上記時間制限を超えて所与のエリアに滞在している場合、ゲーム内評価を下げる処理を行う。
【0220】
移動制限は、時系列楽曲部分の演奏完了前に次のエリアへ移動することを抑制する効果がある。また、時間制限は、時系列楽曲部分の演奏が完了した場合に、当該エリアに留まることを抑止する(次のエリアへの移動を促す)効果がある。よって移動制限と時間制限を組み合わせることで、プレーヤに対して適切なタイミングでのエリア移動(時系列楽曲部分の遷移)を促すことが可能になる。
【0221】
(変形例6)
またキャラクタCAの移動速度を楽曲の情報に合わせて変更してもよい。ここでの楽曲の情報とは例えば楽曲のテンポ(拍のタイミングの間隔、BPMの値等)である。具体的には、楽曲のテンポが早ければキャラクタの移動速度も速くし、テンポが遅ければ移動速度を遅くする。或いは、楽曲の情報とは楽曲のリズムであってもよい。例えば楽曲がワルツかボレロかといった違いによりキャラクタの移動速度が変化する。静かな曲調であるほど移動速度が低く設定され、激しい曲調であるほど移動速度が速く設定される。
【0222】
このようにすれば、キャラクタCAの移動速度を楽曲と調和させることが可能になる。上述したように楽曲(音量、音程、音色)に応じてアニメーション情報の決定処理を行う実施形態と組み合わせてもよく、この場合、静かな曲調であればキャラクタCAはゆっくり移動しつつ動きの少ない動作を行い、激しい曲調であればキャラクタCAは素早く移動しつつ動きの激しい動作を行う。
【0223】
なお、上記のように本実施形態について詳細に説明したが、本発明の新規事項および効果から実体的に逸脱しない多くの変形が可能であることは当業者には容易に理解できるであろう。従って、このような変形例はすべて本発明の範囲に含まれるものとする。例えば、明細書又は図面において、少なくとも一度、より広義または同義な異なる用語(移動体等)と共に記載された用語(キャラクタ等)は、明細書又は図面のいかなる箇所においても、その異なる用語に置き換えることができる。また、オブジェクトに対する動作の判定処理、楽曲制御、オブジェクト制御、アニメーション処理(決定処理、調整処理を含む)も、本実施形態で説明したものに限定されず、これらと均等な手法・処理も本発明の範囲に含まれる。また本発明は種々のゲームに適用できる。また本発明は、業務用ゲームシステム、家庭用ゲームシステム、多数のプレーヤが参加する大型アトラクションシステム、シミュレータ、マルチメディア端末、ゲーム画像を生成するシステムボード、携帯電話機等の種々のゲームシステムに適用できる。例えばゲームシステムは、ゲームのプログラムがインストールされて実行される携帯電話機や携帯型情報端末であってもよい。
【符号の説明】
【0224】
10、11、12、13…操作ボタン、14…方向指示キー、
16、18…アナログスティック、20、22…R、Lボタン、100…処理部、
102…入力受け付け部、104…ゲーム処理部、106…キャラクタ処理部、
108…アニメーション処理部、110…タイミング処理部、112…楽曲再生部、
114…オブジェクト制御部、116…判定部、120…表示処理部、160…操作部、
170…記憶部、171…楽曲情報記憶部、172…ゲーム進行履歴記憶部、
173…フィールド・オブジェクト情報記憶部、174…アニメーション情報記憶部、
180…記憶媒体、190…表示部、192…音出力部、194…I/F部、
195…携帯型情報記憶媒体、196…通信部、500…サーバシステム、
510…ネットワーク、AR1~AR5…エリア、CA…キャラクタ、
FE…フィールド、OB(OB1~OB4)…オブジェクト、RO…移動経路、
TM1~TMn…端末装置、VC…仮想カメラ、Vm…移動方向