JP2021058471A - コンピュータプログラムおよびゲームシステム - Google Patents

Abstract

【課題】育成ゲームを継続してプレイするモチベーションを育成のシミュレーションのアップデート以外の方法によってプレーヤに与える。【解決手段】楽曲に合わせてプレーヤがアクションを行う音楽ゲームを提供するノーツ処理部２６、育成ゲームにおいて仮想的に育成されるキャラクタがライブを行う様子を表わすライブ動画像７Ｖ２をノーツ処理部２６によって音楽ゲームが提供されている間、ディスプレイに表示させる動画像再生処理部２７、キャラクタが特別なパフォーマンスを行う様子を表わすスペシャルパフォーマンス動画像７Ｖ３を、音楽ゲームおよび育成ゲームそれぞれにおける状況に関する所定の要件が満たされる場合にディスプレイに表示させるスペシャルパフォーマンス処理部２９を端末装置２に設ける。【選択図】図３

Description

本発明は、育成ゲームによって仮想的に育成されるキャラクタの動画像を提供する技術に関する。

従来、人物のキャラクタをコンピュータによって仮想的に育成する育成ゲームが普及している。例えば、非特許文献１に記載される育成ゲームは、マネージャであるキャラクタが複数の男性キャラクタを、レッスンを受けさせたり勉強させたりしてアイドルに育成するゲームである。

また、特許文献１には、スポーツ選手であるキャラクタを育成する育成ゲームが提案されている。

特開２０１０−１６２１７７号公報

ウェブページ「ゲームシステム｜あんさんぶるスターズ！」（ＵＲＬ https://stars.happyelements.co.jp/system/），Happy Elements株式会社，２０１９年９月１２日検索

育成ゲームは、プレーヤ（ユーザ）がストーリに沿って戦略を立てながらキャラクタを効率的にまたは効果的に育成することに醍醐味がある。よって、プレーヤには複雑な操作があまり好まれず、育成ゲームは、プレーヤが幾つかのコマンドを与えるだけでレッスンなどのイベントがシミュレートされるように設計されている。したがって、シューティングゲームのような他のジャンルのゲームと比較すると、単位時間当たりの操作の手数がかなり少ない。しかも、育成ゲームは、シューティングゲームとは異なり、操作の俊敏性が基本的に要求されない。

また、近年、種々のコンピュータプログラムが、コンピュータの高性能化および通信速度の向上によって、オンラインサーバから容易に配信され、かつ、アップデートが容易に繰り返されるようになった。育成ゲームのコンピュータプログラムも、その一例である。これにより、育成ゲームは、カセットまたはＣＤ−ＲＯＭなどの記録媒体によってコンピュータプログラムが提供された頃とは異なり、何年もの間、継続してプレイされるようになった。

ところが、上述の通り、プレーヤは、幾つかのコマンドを与えるだけで育成ゲームをプレイすることができるので、継続してプレイしていると、アップデートがあっても育成ゲームに飽きてしまうことがある。

そこで、コンピュータプログラムのアップデートの際に、俊敏な操作が要求される要素を育成ゲームに取り入れることが、考えられる。

しかし、上述の通り、育成ゲームはストーリ性および戦略性を楽しむものであって、操作の俊敏性を楽しむものではない。俊敏な操作が苦手なプレーヤも多い。しかも、育成ゲームと無関係な要素を組み込んでも、プレーヤを惹きつけることができない。

本発明は、このような課題に鑑みてなされたものであって、育成ゲームを継続してプレイするモチベーションを、育成のシミュレーションのアップデート以外の方法によってプレーヤに与えられるようにすることを、目的とする。

本発明の一形態に係るコンピュータプログラムは、再生される楽曲である再生曲に合わせてプレーヤがアクションを行う音楽ゲームを提供する音楽ゲーム手段、育成ゲームにおいて仮想的に育成されるキャラクタがライブを行う様子を表わす第一の動画像を、前記音楽ゲーム手段によって前記音楽ゲームが提供されている間、ディスプレイに表示させる第一の表示処理手段、前記キャラクタが特別なパフォーマンスを行う様子を表わす第二の動画像を、前記音楽ゲームおよび前記育成ゲームそれぞれにおける状況に関する所定の要件が満たされる場合に前記ディスプレイに表示させる第二の表示処理手段としてコンピュータを機能させるためのコンピュータプログラムである。

好ましくは、前記コンピュータプログラムは、前記コンピュータをさらに、前記育成ゲームを提供する育成ゲーム手段として機能させる。

前記所定の要件の一例は、前記プレーヤによる前記音楽ゲームのプレイの評価が一定以上であるいう第一の要件が満たされ、かつ、前記育成ゲームおける前記キャラクタの価値が一定以上であるという第二の要件が満たされることである。

本発明によると、育成ゲームを継続してプレイするモチベーションを、育成のシミュレーションのアップデート以外の方法によってプレーヤに与えることができる。

ゲームシステムの全体的な構成の例を示す図である。 端末装置のハードウェア構成の例を示す図である。 端末装置の機能的構成の例を示す図である。 キャラクタのアバタの外観の例を示す図である。 キャラクタデータ記憶部の例を示す図である。 カードの例を示す図である。 カードデータの例を示す図である。 メニュー画面の例を示す図である。 ユニットデータ記憶部の例を示す図である。 ユニット編成画面の例を示す図である。 カード一覧画面の例を示す図である。 ユニット編成画面の例を示す図である。 ユニット編成画面の例を示す図である。 ユニットデータ記憶部の例を示す図である。 楽曲データ記憶部の例を示す図である。 動画像データ記憶部の例を示す図である。 条件選択画面の例を示す図である。 ノーツ設定画面である。 リズムゲーム画面の例を示す図である。 リズムゲーム画面の例を示す図である。 ノーツが等速度で移動する様子の例を示すである。 ノーツが加速しながら移動する様子の例を示す図である。 評価メッセージの例を示す図である。 ノーツのバリエーションの例を示す図である。 ノーツ再生データの例を示す図である。 動画像の例を示す図である。 スペシャルパフォーマンスデータの例を示す図である。 ノーツ発射源の変化の様子の例を示す図である。 選出処理の流れの例を示すフローチャートである。 スペシャルパフォーマンス動画像の１コマの例を示す図である。 アプリケーションによる全体的な処理の流れの例を示すフローチャートである。 アプリケーションによる全体的な処理の流れの例を示すフローチャートである。 ユニット編成画面の例を示す図である。 ユニット編成画面のグレーアウト時の例を示す図である。 ユニット編成画面の例を示す図である。

〔１．概要〕
図１は、ゲームシステム１の全体的な構成の例を示す図である。図２は、端末装置２のハードウェア構成の例を示す図である。図３は、端末装置２の機能的構成の例を示す図である。

図１に示すゲームシステム１は、複合ゲーム４をプレーヤへ提供するコンピュータネットワークシステムである。複合ゲーム４には、アイドル育成ゲーム４Ａおよびリズムゲーム４Ｂが含まれている。

アイドル育成ゲーム４Ａは、プレーヤ（遊技者）が仮想の人物（以下、「キャラクタ」と記載する。）をアイドルとして育成するシミュレーションゲームである。一方、リズムゲーム４Ｂは、楽曲のリズムに合わせてプレーヤがアクションすることによって進行する音楽ゲームである。さらに、リズムゲーム４Ｂの進行中、楽曲に合わせてキャラクタに歌唱およびダンスなどを行わせることができる。

すなわち、複合ゲーム４によると、プレーヤは、キャラクタを介してアイドル育成ゲーム４Ａおよびリズムゲーム４Ｂを複合的に楽しむことができる。

さらに、アイドル育成ゲーム４Ａにおけるキャラクタの育成の度合およびリズムゲーム４Ｂにおけるプレーヤの成績（プレイの上手さの評価）などに応じてキャラクタが楽曲の途中に特別なパフォーマンス（以下、「スペシャルパフォーマンス」と記載する。）を行うことがある。つまり、スペシャルパフォーマンスを報奨の１つとして提供することによって、プレーヤがアイドル育成ゲーム４Ａでキャラクタを育成するモチベーションおよびリズムゲーム４Ｂで好成績を収めるモチベーションの両方を高めることができる。

ゲームシステム１は、端末装置２およびサーバ３などによって構成される。端末装置２とサーバ３とは、インターネット、携帯電話網、またはＷｉ-Ｆｉなどの通信回線を介して通信することができる。

サーバ３は、複合ゲーム４のアプリケーション２Ｐを記憶しており、端末装置２からの要求に応じてアプリケーション２Ｐを端末装置２へ送信する。サーバ３として、例えば、アプリケーションストアのクラウドサーバまたはアプリケーション２Ｐのメーカのウェブサーバが用いられる。

端末装置２は、アプリケーション２Ｐをサーバ３からダウンロードし、実行する。端末装置２として、スマートフォン、タブレットコンピュータ、またはパーソナルコンピュータなどが用いられる。以下、スマートフォンが端末装置２として用いられる場合を例に説明する。

端末装置２は、図２に示すように、メインプロセッサ２Ａ、フラッシュメモリ２Ｂ、メインメモリ２Ｃ、ベースバンドプロセッサ２Ｄ、無線ＬＡＮチップ２Ｅ、ディスプレイ２Ｆ、タッチパネル２Ｇ、操作ボタン２Ｈ、デジタルカメラ２Ｊ、および音声システム２Ｋなどによって構成される。

メインプロセッサ２Ａは、端末装置２のメインのＣＰＵ（Central Processing Unit）であって、メインメモリ２Ｃにロードされたコンピュータプログラムを実行する。特に本実施形態では、アプリケーション２Ｐを実行する。

フラッシュメモリ２Ｂには、種々のアプリケーションがインストールされる。アプリケーション２Ｐも、サーバ３からダウンロードされるとフラッシュメモリ２Ｂにインストールされる。

メインメモリ２Ｃは、端末装置２のメインのＲＡＭ（Random Access Memory）であって、オペレーティングシステムおよびアプリケーション２Ｐなどのコンピュータプログラムがロードされる。

ベースバンドプロセッサ２Ｄは、いわゆる第４世代または第５世代などの規格に基づいて携帯電話の基地局を介して他の装置と通信する。

無線ＬＡＮチップ２Ｅは、ＩＥＥＥ（Institute of Electrical and Electronics Engineers）８０２．１１などの規格に基づいてＷｉ-Ｆｉ用の基地局を介して他の装置と通信する。

ディスプレイ２Ｆおよびタッチパネル２Ｇによってタッチパネルディスプレイが構成される。ディスプレイ２Ｆは、ＯＬＥＤ（Organic Light-Emitting Diode）ディスプレイまたは液晶ディスプレイなどのフラット型のディスプレイであって、後述する種々の画面を表示する。タッチパネル２Ｇは、プレーヤによってタッチされた位置を検知しメインプロセッサ２Ａへ通知する。

操作ボタン２Ｈは、ディスプレイ２Ｆに表示される画面をいわゆるホーム画面に切り換えるためのボタンである。また、操作ボタン２Ｈは、デジタルカメラ２Ｊのシャッタまたはスリープモードの解除のボタンとしても用いられる。

デジタルカメラ２Ｊは、写真または動画像を撮影し、写真または動画像の電子データを生成する。

音声システム２Ｋは、サウンドボード、マイクロフォン、およびスピーカなどによって構成され、音声をキャプチャして音声データを生成したり、音声データに基づいて音声を再生したりする。

アプリケーション２Ｐによると、図３に示すメニュー処理部２１、育成処理部２２、ユニット編成部２３、セッティング処理部２４、楽曲再生処理部２５、ノーツ処理部２６、動画像再生処理部２７、開始可否判別部２８、スペシャルパフォーマンス処理部２９、キャラクタデータ記憶部２Ｍ１、カードデータ記憶部２Ｍ２、ユニットデータ記憶部２Ｍ３、楽曲データ記憶部２Ｍ４、動画像データ記憶部２Ｍ５、ノーツ再生データ記憶部２Ｍ６、ノーツ設定データ記憶部２Ｍ７、およびパフォーマンスデータ記憶部２Ｍ８などが端末装置２に実現される。

以下、複合ゲーム４の具体例を、図３に示す各部の機能およびプレーヤの操作などとともに説明する。

〔２．アイドル育成ゲーム４Ａおよびリズムゲーム４Ｂの共通の事項〕
図４は、キャラクタ５のアバタの外観の例を示す図である。図５は、キャラクタデータ記憶部２Ｍ１の例を示す図である。図６は、カード４１の例を示す図である。図７は、カードデータ６Ｂの例を示す図である。図８は、メニュー画面７Ａの例を示す図である。

複合ゲーム４には、図４のような、育成の対象であるキャラクタとして複数のキャラクタ５が、予め用意されている。各キャラクタ５にはキャラクタ名および顔情報が予め設定されている。

「キャラクタ名」は、キャラクタ５の名前である。本実施形態では、ファーストネームのみがキャラクタ名として用いられるが、フルネームが用いられてもよい。

「顔情報」は、キャラクタ５の顔を再現するための情報であって、無表情のときの輪郭、肌の色、髪型、髪の色のほか、目、鼻、口、耳、眉などのパーツそれぞれの形状および位置である。なお、顔情報のフォーマットは、動画像を再生する方法に依存する。例えば、３次元モデルをレンダリングすることによって再生する場合は、顔の３次元モデルを構成する各ポリゴンの頂点の位置および顔のテクスチャなどが顔情報として用いられる。この場合においても、さらに、２次元のイラストを顔情報に含めておいてもよい。

以下、各キャラクタ５を「キャラクタ５ａ」、「キャラクタ５ｂ」、「キャラクタ５ｃ」、…と区別して記載することがある。

キャラクタデータ記憶部２Ｍ１には、図５に示すように、キャラクタ５ごとに、キャラクタ名および顔情報を示すキャラクタデータ６Ａが記憶されている。以下、キャラクタ５ａ、５ｂ、５ｃ、…のキャラクタデータ６Ａをそれぞれ「キャラクタデータ６Ａａ」、「キャラクタデータ６Ａｂ」、「キャラクタデータ６Ａｃ」…と区別して記載することがある。

各キャラクタ５には、さらに、図６のような仮想のカード４１が複数枚ずつ予め用意されている。以下、各カード４１を「カード４１ａ」、「カード４１ｂ」、「カード４１ｃ」、…と区別して記載することがある。図６の例では、キャラクタ５ごとに２枚または３枚のカード４１が用意されているが、もっと多くのカード４１が用意されていても構わない。

プレーヤは、これらのカード４１のうちの幾つかの所定のカード４１をデフォルトで与えられる。そして、アイドル育成ゲーム４Ａを進行させる過程において特定の条件を満たすと、その条件に応じて残りのカード４１のいずれかを取得することができる。

カードデータ記憶部２Ｍ２には、図７に示すように、カード４１それぞれのカードデータ６Ｂが記憶されている。以下、カード４１ａ、４１ｂ、４１ｃ、…それぞれのカードデータ６Ｂを「カードデータ６Ｂａ」、「カードデータ６Ｂｂ」、「カードデータ６Ｂｃ」、…と区別して記載することがある。

カードデータ６Ｂには、カードコード、カード画像、キャラクタ名、属性、経験値Ｋａ、現レベルＫｂ、ダンス値Ｋｃ、ボーカル値Ｋｄ、パフォーマンス値Ｋｅ、バックコーラス値Ｋｆ、レアリティ値Ｋｇ、および所有フラグなどが示される。

「カードコード」は、カード４１の識別するためのユニークなコードである。「カード画像」および「キャラクタ名」は、それぞれ、カード４１に対応するキャラクタ５の上半身の画像および名前である。例えば、カードデータ６Ｂａは、カード４１ａのカードデータ６Ｂであって、「Ｃ００１」がカードコードとして示され、キャラクタ５ａすなわちＡｒｔｈｅｒの上半身の画像がカード画像として示され、「Ａｒｔｈｅｒ」という文字列がキャラクタ名として示される。カード画像は、上半身の画像ではなく全身の画像であってもよい。

経験値Ｋａは、経験の度合を表わし、レッスンの受講、課外活動への取組み、またはフェスティバルでの競争などのイベントの結果に応じて上がる。

現レベルＫｂは、アイドルとしての現在のレベルであって、経験値Ｋａが所定の値を上回るごとに上がる。ただし、現レベルＫｂは上限値までしか上げることができず、上限値はレアリティ値Ｋｇごとに予め決まっている。本実施形態では、上限値＝１０×（１＋Ｋｇ）、である。したがって、例えばカード４１ａの上限値は、カード４１ａのレアリティ値Ｋｇが「２」なので、１０×（１＋２）＝３０、である。

ダンス値Ｋｃ、ボーカル値Ｋｄ、パフォーマンス値Ｋｅ、およびバックコーラス値Ｋｆは、それぞれ、ダンス、ボーカル、パフォーマンス、およびバックコーラスの才能（スキル、能力）の高さを表わす値である。なお、「ボーカル」は、一般にサイドボーカル（バックコーラス）を含むことがあるが、本実施形態では特にリードボーカルを意味する。また、「パフォーマンス」は一般にリードボーカル、バックコーラス、およびダンスを含むことがあるが、本実施形態では、特に派手な振舞いを意味する。また、アドリブ的な振舞いもパフォーマンスに含まれる。

フェスティバルでの競争は、フェスティバルへの出演者同士がダンス、ボーカル、パフォーマンス、またはバックコーラスの上手さを競い合う。相手よりもダンス値Ｋｃ、ボーカル値Ｋｄ、パフォーマンス値Ｋｅ、またはバックコーラス値Ｋｆが高いほど勝利する確率が高い。

例えば、カード４１ａのキャラクタ５とカード４１ｃのキャラクタ５とがボーカルの上手さを勝負した場合は、カード４１ａ、４１ｃそれぞれのボーカル値Ｋｄが「１４８８」、「４１４」なので、カード４１ａのキャラクタ５のほうが勝利しやすい。

「属性」は、ダンス、ボーカル、パフォーマンス、およびバックコーラスのうちの最も優れた才能である。つまり、特技である。属性ごとに異なる色または模様が予め対応付けられており、カード画像を表示する際に反映される（図１１参照）。

レアリティ値Ｋｇは、カード４１の希少性の高さを表わす。レアリティ値Ｋｇが大きいほど希少性が高い。つまり、レアリティ値Ｋｇは、入手の困難性を表わしている。本実施形態において、レアリティ値Ｋｇの最大値は「５」であり、最小値は「１」である。プレーヤにデフォルトで与えられるカード４１は、原則として、いずれもレアリティ値Ｋｇが「１」のものである。

つまり、レアリティ値Ｋｇは、カード４１の元々の価値を表わしている。一方、経験値Ｋａ、現レベルＫｂ、ダンス値Ｋｃ、ボーカル値Ｋｄ、パフォーマンス値Ｋｅ、およびバックコーラス値Ｋｆは、カード４１の使用による価値を表わしている
「所有フラグ」は、プレーヤによって所有されているか否かを示すフラグであって、「１」であれば所有されていることを意味し、「０」であれば所有されていないことを意味する。

なお、カードデータ６Ｂに示される幾つかの要素は、スペシャルパフォーマンスを行わせるための要件の１つとして参照される。これについては、後述する。

これらのカード４１は、すべてユニークなものである。しかも、上述の通りキャラクタ５ごとに複数枚のカード４１が用意されており、カード画像ごとに表情、ポーズ、および衣装などが異なる。プレーヤは、自分のお気に入りのキャラクタ５のカード４１を他のキャラクタ５のカード４１よりも優先的に収集したり、キャラクタ５を問わずレアリティ値Ｋｇが低いカード４１を高いカード４１よりも優先的に収集したり、自分なりの楽しみ方でカード４１を収集することができる。

アプリケーション２Ｐが起動しまたは所定の操作が行われると、メニュー処理部２１（図３参照）は、図８のようなメニュー画面７Ａをディスプレイ２Ｆに表示させる。

プレーヤは、アイドル育成ゲーム４Ａをプレイする場合は、レッスンボタン７Ａ１、課外活動ボタン７Ａ２、またはフェスティバルボタン７Ａ３をタップする。すると、後述するように、育成処理部２２などによってアイドル育成ゲーム４Ａが実行される。

一方、リズムゲーム４Ｂをプレイする場合は、リズムゲームボタン７Ａ４をタップする。すると、後述するように、楽曲再生処理部２５およびノーツ処理部２６などによってリズムゲーム４Ｂが実行される。

〔３．アイドル育成ゲーム４Ａ〕
アイドル育成ゲーム４Ａにおいて、プレーヤは、自分が所有するカード４１の中から所定の枚数（例えば、５枚）以内のカード４１を選択し、選択したカード４１のキャラクタ５に歌またはダンスなどのレッスンを受けさせたり、課外活動に取り組ませたり、フェスティバルへ出演させたりすることによって、選択したカード４１のレベルなどを向上させることができる。ただし、同じキャラクタ５のカード４１を複数同時に選択することは、できない。

育成処理部２２は、プレーヤによる操作に応じて、レッスンの受講、課外活動への取組み、およびフェスティバルでの競争の各イベントをシミュレートする。

具体的には、育成処理部２２は、プレーヤによって選択された１枚または複数枚のカード４１それぞれのキャラクタ５がレッスンを受講したり、課外活動に取り組んだり、フェスティバルで競争したりする様子を、それぞれのキャラクタ５の画像および音声をディスプレイ２Ｆによって表示しまたは音声システム２Ｋによって再生することによって、仮想的に再現する。

そして、育成処理部２２は、再現したイベントの結果に応じて、選択されたカード４１それぞれのカードデータ６Ｂに示される経験値Ｋａ、ダンス値Ｋｃ、ボーカル値Ｋｄ、パフォーマンス値Ｋｅ、またはバックコーラス値Ｋｆを上げる。

なお、アイドル育成ゲーム４Ａとして既存のアイドル育成ゲームを用いてもよい。例えば、Happy Elements株式会社のゲーム「あんさんぶるスターズ！」を用いてもよい。具体的には、このゲームでは４つの才能のうちダンス値Ｋｃ、ボーカル値Ｋｄ、およびパフォーマンス値Ｋｅが採用されているので、バックコーラス値Ｋｄに関する要素をこのゲームに拡張して用いてもよい。

〔４．リズムゲーム４Ｂおよび音楽ライブ〕
プレーヤは、自分が所有するカード４１の中から所定の枚数のカード４１を選択し、選択したカード４１のキャラクタ５を１つのユニット（グループ）として音楽ライブ（コンサート）に出演させ、このユニットのダンス、ボーカル、パフォーマンス、およびバックコーラスを視聴することができる。プレーヤは、カード４１を選択する際に、音楽ライブのステージでのメンバのデフォルトの配列（以下、「初期配列」と記載する。）も指定する。初期配列における真ん中のメンバ（以下、「センタ」と記載する。）がメインボーカルを担当し、他のメンバがバックコーラスを担当する。アイドル育成ゲーム４Ａにおけるレッスン等と同様、同じキャラクタ５のカード４１を複数選択することはできない。さらに、プレーヤは、音楽ライブを視聴しながらリズムゲーム４Ｂを楽しむことができる。なお、本実施形態では、スペシャルパフォーマンスもセンタが担当するものとする。

以下、音楽ライブの再現およびリズムゲーム４Ｂの仕組みを、所定の枚数が５枚でありかつプレーヤが管理することができるユニットの数が４つである場合を例に説明する。

（Ａ） 主要なデータ
図９は、ユニットデータ記憶部２Ｍ３の例を示す図である。図１０は、ユニット編成画面７Ｂの例を示す図である。図１１は、カード一覧画面７Ｃの例を示す図である。図１２は、ユニット編成画面７Ｂの例を示す図である。図１３は、ユニット編成画面７Ｂの例を示す図である。図１４は、ユニットデータ記憶部２Ｍ３の例を示す図である。

ユニットデータ記憶部２Ｍ３（図３参照）には、図９のように、ユニットごとに、ユニットコード、ユニット名、およびメンバカードコードを示すユニットデータ６Ｃが記憶されている。以下、１番目、２番目、…それぞれのユニットのユニットデータ６Ｃを「ユニットデータ６Ｃａ」、「ユニットデータ６Ｃｂ」、…と区別して記載することがある。

「ユニットコード」は、ユニットを識別するためのコードである。「ユニット名」は、ユニットの名前であって、プレーヤが任意に付けることができる。「メンバカードコード」は、ユニットを構成する５枚のカード４１それぞれのカードコードを、初期配列の順に並べたものである。

ただし、ユニット名が未だ決まっていない場合は、ユニットデータ６Ｃにはユニット名として「Ｎｕｌｌ」が示され、メンバが未だ決まっていない場合は、メンバカードコードとして「Ｎｕｌｌ」が示される。

プレーヤは、音楽ライブに出演させるユニットが既に望み通りに編成されている場合は、メニュー画面７Ａ（図８参照）において直ちにリズムゲームボタン７Ａ４をタップすればよい。しかし、未だ編成されていない場合は、ユニット編成ボタン７Ａ５をタップする。

ユニット編成ボタン７Ａ５がタップされると、ユニット編成部２３は、ユニットを編成するための処理を次のように実行する。

ユニット編成部２３は、図１０のようなユニット編成画面７Ｂをディスプレイ２Ｆに表示させる。ユニット編成画面７Ｂには、ユニットごとにユニットボタン７Ｂ１が配置されている。さらに、５つのメンバ領域７Ｂ２が設けられている。

いずれかのユニットボタン７Ｂ１がプレーヤによって選択されると、ユニット編成部２３は、選択されたユニットボタン７Ｂ１に対応するユニット（以下、「被選択ユニット」と記載する。）のユニットデータ６Ｃ（図９参照）をユニットデータ記憶部２Ｍ３から読み出す。読み出したユニットデータ６Ｃに示されるメンバカードコードに含まれる５つのカードコードそれぞれのカードデータ６Ｂ（図７参照）をカードデータ記憶部２Ｍ２から読み出す。

そして、ユニット編成部２３は、読み出した５つのカードデータ６Ｂそれぞれに基づいて、５つのカード４１それぞれのカード画像およびダンス値Ｋｃなどを初期配列の順に５つのメンバ領域７Ｂ２に１組ずつ配置する。ただし、読み出したユニットデータ６ＣのメンバカードコードがＮｕｌｌである場合つまり未編成である場合は、図１０のようにメンバ領域７Ｂ２に「未設定」という文字列を配置する。

ここでプレーヤは、被選択ユニットのメンバを次のように指定する。初期配列の最も左の位置のメンバを指定する場合は、プレーヤは、５つのメンバ領域７Ｂ２のうちのその位置に対応するメンバ領域７Ｂ２すなわちメンバ領域７Ｂ２ａを選択する。

すると、ユニット編成部２３は、図１１のようなカード一覧画面７Ｃをディスプレイ２Ｆに表示させる。カード一覧画面７Ｃには、プレーヤが所有するカード４１を見せるための所有カード領域７Ｃ１が設けられている。各所有カード領域７Ｃ１には、プレーヤが所有するカード４１ごとのカード画像、現レベルＫｂ、上限値、ダンス値Ｋｃ、ボーカル値Ｋｄ、パフォーマンス値Ｋｅ、バックコーラス値Ｋｆ、およびレアリティ値Ｋｇが配置される。レアリティ値Ｋｇは、星形のマークの個数によって表わされる。後述する各画面においても、同様である。

図１１の例では、６枚のカード４１のカード画像などが配置されているが、プレーヤがカード４１を７枚以上所有する場合は、カード一覧画面７Ｃをスクロールさせることによって、カード画像を一部ずつ表示させることができる。

プレーヤは、初期配置の最も左の位置のメンバとして指定したいカード４１をカード一覧画面７Ｃの中から見つけ、そのカード４１を、そのカード４１のカード画像が配置されている所有カード領域７Ｃ１をタップして選択する。例えば、カード４１ａ（図６参照）を選択する場合は、所有カード領域７Ｃ１ａをタップする。

すると、ユニット編成部２３は、図１２のように、そのカード４１のカード画像などがメンバ領域７Ｂ２ａに配置された状態で、ユニット編成画面７Ｂをディスプレイ２Ｆに表示させる。

他の位置のメンバを指定する場合も同様に、プレーヤは上述のように操作を行い、ユニット編成部２３は上述のように処理を行う。

すなわち、例えば、初期配置における左から２番目の位置のメンバを指定する場合は、プレーヤは、メンバ領域７Ｂ２ｂを選択する。すると、ユニット編成部２３は、カード一覧画面７Ｃをディスプレイ２Ｆに表示させる。プレーヤは、その位置のメンバとして指定したいカード４１を選択する。すると、ユニット編成部２３は、そのカード４１のカード画像などがメンバ領域７Ｂ２ｂに配置された状態でユニット編成画面７Ｂをディスプレイ２Ｆに表示させる。

さらに、プレーヤは、ユニット名領域７Ｂ３をタップする。すると、ユニット編成部２３は、ソフトウェアキーボードをユニット編成画面７Ｂの下部にオーバラップさせて表示させる。ここで、プレーヤは、被選択ユニットのユニット名をソフトウェアキーボードによって入力する。

このようにして被選択ユニットのメンバおよびユニット名がすべて指定されまたは入力された結果、ユニット編成画面７Ｂには、図１３に示すように、５つのメンバ領域７Ｂ２それぞれに、プレーヤによって指定されたカード４１のカード画像およびダンス値Ｋｃなどが配置され、ユニット名領域７Ｂ３にユニット名が示される。

そのほか、実力評価領域７Ｂ５には、ダンス、ボーカル、パフォーマンス、およびバックコーラスそれぞれの総合力値が示される。各総合力値は、被選択ユニットの５枚のカード４１それぞれのカードデータ６Ｂに示されるダンス値Ｋｃの合計値、ボーカル値Ｋｄの合計値、パフォーマンス値Ｋｅの合計値、およびバックコーラス値Ｋｆの合計値である。さらに、これら４つの合計値の合計値がユニット総合力値Ｐａとして示される。

そして、プレーヤが保存ボタン７Ｂ４をタップすると、ユニット編成部２３は、ユニット編成画面７Ｂに配置されている５つのカード画像のカード４１それぞれのカードコードが配列順にメンバカードコードとして示され、かつ、ユニット名領域７Ｂ３のユニット名が示されるように、被選択ユニットのユニットデータ６Ｃを更新する。例えば、４番目のユニットについてカード４１が選択されユニット名が入力された場合は、図１４のようにユニットデータ６Ｃｄを更新する。

１〜５番目の位置それぞれのメンバを指定する順番は、任意である。特に、メインボーカルおよびスペシャルパフォーマンスを３番目の位置のメンバが担当するので、プレーヤは、３番目の位置のメンバを最初に選択してもよい。メインボーカルとスペシャルパフォーマンスとを別々のメンバが担当できるようにリズムゲーム４Ｂを構成してもよいが、この場合の例については、後述する。

図１５は、楽曲データ記憶部２Ｍ４の例を示す図である。図１６は、動画像データ記憶部２Ｍ５の例を示す図である。

楽曲データ記憶部２Ｍ４には、図１５に示すように、楽曲ごとに楽曲データ６Ｄが記憶されている。以下、各楽曲の楽曲データ６Ｄを「楽曲データ６Ｄ１」、「楽曲データ６Ｄ２」、…と区別して記載することがある。

楽曲データ６Ｄは、楽曲のインストルメンタルパート（楽器のみの演奏音）、メインボーカルパート（メインボーカルのみの歌声）、およびバックコーラスパート（バックコーラスのみの歌声）それぞれを再現するための音声データが含まれ、楽曲名（楽曲の名前）およびテンポ（６０秒当たりの拍数）が対応付けられている。メインボーカルパートの音声データおよびバックコーラスパートの音声データは、キャラクタ５ごとに１つずつ用意されている。キャラクタ５ごとの声優が実際に歌う音声を録音することによって用意してもよいし、公知の人工音声技術によって用意してもよい。

動画像データ記憶部２Ｍ５には、図１６に示すように、楽曲ごとに動画像データ６Ｅが記憶されている。以下、各楽曲の動画像データ６Ｅを「動画像データ６Ｅ１」、「動画像データ６Ｅ２」、…と区別して記載することがある。

動画像データ６Ｅは、５人のキャラクタ５が楽曲に合わせて歌ったり踊ったりする動画像を再生するためのデータである。動画像データ６Ｅは、公知のアニメーション用の２ＤＣＧ（2 Dimension Computer Graphics）エディタまたは公知の３ＤＣＧエディタによって作成される。動画像データ６Ｅのフォーマットは、動画像を再生する方法に依存する。

例えば、３次元モデルをレンダリングすることによって動画像を再生する場合は、動画像データ６Ｅには、５人の人間それぞれのモデルの全身の３次元データ、ステージでの各モデルのデフォルト（楽曲の演奏前）のポジションおよび楽曲の演奏中における各モデルの動作を表わす動作データ、ステージおよび周囲を再現するための環境データ、ならびに音楽ライブを仮想的に撮影するビデオカメラの時刻ごとの位置、撮影方向、および撮影範囲などを示すカメラデータなどが含まれる。３次元データには、３次元構造（例えば、各ポリゴンの各頂点の位置）のデータだけでなく表面のテクスチャのデータなどが含まれている。なお、各モデルの３次元モデルの顔の部分に被選択ユニットの各キャラクタ５の顔情報（図５参照）を適用することによって、各キャラクタ５の３次元モデルが得られる。

ノーツ再生データ記憶部２Ｍ６には、楽曲ごとにノーツ再生データ６Ｆ（図２５参照）が記憶されている。ノーツ再生データ６Ｆの内容および使い方については、後に説明する。なお、「ノーツ」は、リズムゲームにおける打撃の対象であるマークであって、楽曲に合わせて画面上を一直線に流れるように移動する。

ノーツ設定データ記憶部２Ｍ７には、ノーツ設定データ６Ｇが記憶されている。ノーツ設定データ６Ｇは、ノーツのスピード、加速度、および量を示すデータである。デフォルトでは、スピード、加速度、および量としてそれぞれ「遅」、「ゼロ」、および「少」が示される。なお、ノーツ設定データ６Ｇに示されるスピードは、ノーツの初速度である。加速度および量の詳細については、後に順次、説明する。

（Ｂ） リズムゲーム４Ｂの開始前のセッティング
図１７は、条件選択画面７Ｄの例を示す図である。図１８は、ノーツ設定画面７Ｅである。

プレーヤは、音楽ライブに出演させるユニット（以下、「出演ユニット」と記載する。）が所望の通りに編成されていれば、メニュー画面７Ａ（図８参照）においてリズムゲームボタン７Ａ４をタップする。すると、リズムゲーム４Ｂのセッティングのための処理がセッティング処理部２４（図３参照）によって次のように実行される。

セッティング処理部２４は、図１７のような条件選択画面７Ｄをディスプレイ２Ｆに表示させる。

ユニット画像領域７Ｄ１には、いずれかの１つのユニットがカレントユニットとして選択され、カレントユニットのユニット画像が配置される。ユニット画像領域７Ｄ１の外には、カレントユニットのユニット名ならびにダンス、ボーカル、パフォーマンス、およびバックコーラスそれぞれの総合力値が配置される。

ユニット画像は、予め用意された、お揃いの衣装を着た５人のキャラクタが並んだ画像（以下、「集合画像」と記載する。）の顔の部分に、カレントユニットの各キャラクタ５の顔の画像を合成することによって得られる。

例えば、セッティング処理部２４は、カレントユニットのユニットデータ６Ｃ（図１４参照）からメンバカードコードに含まれる５つのカードコードを抽出し、抽出した各カードコード対応するカードデータ６Ｂ（図７参照）を読み出す。そして、読み出した各カードデータ６Ｂのカード画像の顔の部分を集合画像に合成する。または、キャラクタデータ６Ａ（図５参照）の顔情報に基づいて各キャラクタ５の顔の画像を生成し集合画像に合成してもよい。

ユニット名は、そのユニットデータ６Ｃに示されるものである。各総合力値は、上述の通り、これらのカードデータ６Ｂに示されるダンス値Ｋｃの合計、ボーカル値Ｋｄの合計、パフォーマンス値Ｋｅの合計、およびバックコーラス値Ｋｆの合計である。

デフォルトでは、１番目のユニットがカレントユニットとして選択される。セッティング処理部２４は、プレーヤがユニット画像領域７Ｄ１を上へフリックするごとに、２番目、３番目、…のユニットをカレントユニットとして新たに選択し、ユニット画像等が配置し直されるように条件選択画面７Ｄを順次更新する。一方、プレーヤが下へフリックするごとに、４番目、３番目、…のユニットをカレントユニットとして新たに選択し、ユニット画像等が配置し直されるように条件選択画面７Ｄを順次更新する。図１７の例では、４番目のユニットのユニット画像等が配置されている。

楽曲領域７Ｄ２には、楽曲データ記憶部２Ｍ４に楽曲データ６Ｄ（図１５参照）が記憶されている楽曲ごとの楽曲名が配置される。プレーヤは、これらの楽曲の中から聴きたい楽曲を、その楽曲の楽曲名をタップすることによって選択する。以下、プレーヤが聴きたい楽曲を「リクエスト曲」と記載する。すべての楽曲名を一度に配置しきれない場合は、プレーヤは楽曲領域７Ｄ２をスクロールさせることによって、楽曲名を一部ずつ表示させることができる。

さらに、プレーヤは、リズムゲーム４Ｂの難易度を次のように設定することができる。プレーヤが設定ボタン７Ｄ３をタップすると、セッティング処理部２４は、図１８のようなノーツ設定画面７Ｅをディスプレイ２Ｆに表示させる。

スピード調整ボタン７Ｅ１ａ、７Ｅ１ｂ、および７Ｅ１ｃは、ノーツのスピードを指定するためのボタンであって、それぞれ、スピードＶａ、Ｖｂ、Ｖｃに対応する。ただし、０＜Ｖａ＜Ｖｂ＜Ｖｃ、である。

加速度調整ボタン７Ｅ２ａ、７Ｅ２ｂ、および７Ｅ２ｃは、ノーツの加速度を指定するためのボタンであって、それぞれ、加速度Ｒａ、Ｒｂ、Ｒｃに対応する。ただし、Ｒａ＜Ｒｂ＜Ｒｃ、であり、Ｒａ＝０、である。

ノーツ量調整ボタン７Ｅ３ａ、７Ｅ３ｂ、および７Ｅ３ｃは、ノーツの量を指定するためのボタンであって、それぞれ、「少」、「中」、および「多」に対応する。

プレーヤは、ノーツのスピード、加速度、および量のそれぞれを、対応するボタンをタップすることによって指定する。そして、確定ボタン７Ｅ４をタップする。

すると、セッティング処理部２４は、指定されたスピード、加速度、および量が示されるようにノーツ設定データ６Ｇを更新する。そして、条件選択画面７Ｄを再び表示させる。例えば、プレーヤがスピード調整ボタン７Ｅ１ｃ、加速度調整ボタン７Ｅ２ａ、およびノーツ量調整ボタン７Ｅ３ａをタップし確定ボタン７Ｅ４をタップした場合は、スピード、加速度、および量としてそれぞれＶｃ、Ｒａ、および「少」が示されるようにノーツ設定データ６Ｇが更新される。

（Ｃ） リズムゲーム４Ｂのルール
図１９は、リズムゲーム画面７Ｆの例を示す図である。図２０は、リズムゲーム画面７Ｆの例を示す図である。図２１は、ノーツ７０が等速度で移動する様子の例を示すである。図２２は、ノーツ７０が加速しながら移動する様子の例を示す図である。図２３は、評価メッセージ７Ｆ４の例を示す図である。図２４は、ノーツ７０のバリエーションの例を示す図である。

出演ユニットおよびリクエスト曲が選択され、必要に応じてスピード、加速度、および量が指定されたら、リズムゲーム４Ｂが開始される。リズムゲーム４Ｂの処理を説明する前に、リズムゲーム４Ｂのルールについて説明する。

リズムゲーム４Ｂは、原則として、リクエスト曲の演奏中に実行される。リズムゲーム４Ｂの実行中、ディスプレイ２Ｆには、図１９のようなリズムゲーム画面７Ｆが表示される。

楽曲インジケータ７Ｆ１は、リクエスト曲の演奏の進捗の度合を表わす。リクエスト曲の演奏が開始される前、楽曲インジケータ７Ｆ１は真っ白であるが、リクエスト曲全体の演奏時間に対する演奏済の部分の時間の割合に応じて、左から徐々に図２０のように所定の色（例えば、青色）に着色されていく。

ノーツ発射源７Ｆ２は、ノーツ７０（図２１〜図２４参照）が発射される円形の源である。基準カーブ７Ｆ３は、その中心がノーツ発射源７Ｆ２の中心と共通である円弧である。基準カーブ７Ｆ３の半径の長さは、距離Ｌｒである。

基準カーブ７Ｆ３の上に、７つの打撃マーク７９が等間隔に配置されている。各打撃マーク７９の形は菱形であるが、より好ましくは、正方形である。打撃マーク７９の一方の対角線の延長線がノーツ発射源７Ｆ２の中心を通る。以下、各打撃マーク７９を左から順に「打撃マーク７９ａ」、「打撃マーク７９ｂ」、…、「打撃マーク７９ｇ」と区別して記載することがある。

ノーツ７０は、多重円（例えば、三重円）のマークであって、ノーツ発射源７Ｆ２から発射されると徐々に大きくなりながら移動し、いずれかの打撃マーク７９の真上を通過する。図２１に示すように等速度で移動することもあれば、図２２に示すように徐々に速度を上げて移動することもある。また、通過する際にノーツ７０の中心と打撃マーク７９の中心とが一瞬、重なる。

なお、図２１および図２２では、楽曲インジケータ７Ｆ１およびスコアインジケータ７Ｆ６など一部のオブジェクトを省略している。後に順次説明する図２３、図２４、図２８においても同様である。

プレーヤは、ノーツ７０がいずれかの打撃マーク７９を通過している間にノーツ７０を原則としてタップすることによって打撃する。ノーツ７０の中心と打撃マーク７９の中心とができるだけ近い状態で打撃したほうがよい。打撃した時点の両中心の距離Ｄが短いほど高く評価され、より高いポイントがプレーヤに与えられるからである。１つのノーツ７０について１回しか打撃することができない。２回目以降の打撃は、無効である。または、１つのノーツ７０について２回以上打撃した場合は、原則として失敗したものとみなしてもよい。

例えば、距離Ｄが所定の距離Ｄ１（例えば、３ドット）未満であれば、「ＰＥＲＦＥＣＴ」と評価され５点が与えられる。または、距離Ｄが所定の距離Ｄ１以上かつ所定の距離Ｄ２（例えば、５ドット）未満であれば、「ＧＲＥＡＴ」と評価され２点が与えられる。または、距離Ｄが所定の距離Ｄ２以上かつ所定の距離Ｄ３（例えば、７ドット）未満であれば、「ＧＯＯＤ」と評価され１点が与えられる。「ＰＥＲＦＥＣＴ」、「ＧＲＥＡＴ」、および「ＧＯＯＤ」と評価された場合は、打撃に成功したものとみなされる。しかし、距離Ｄが所定の距離Ｄ３以上であれば、打撃に失敗したものとみなされ（つまり、「ＭＩＳＳ」と評価され）、ポイントが与えられない。距離Ｄが所定の距離Ｄ３以上になっても打撃が行われなかった場合も「ＭＩＳＳ」と評価され、ポイントが与えられない。

また、打撃した際に、評価を表わす評価メッセージ７Ｆ４がリズムゲーム画面７Ｆに現われる。例えば、距離Ｄが所定の距離Ｄ１未満であれば図２３（Ａ）のように「ＰＥＲＦＥＣＴ」という文字列が評価メッセージ７Ｆ４として現われる。または、距離Ｄが所定の距離Ｄ３以上であれば図２３（Ｂ）のように「ＭＩＳＳ」という文字列が評価メッセージ７Ｆ４として現われる。

２つのノーツ７０が同時に発射され、互いに同じスピードでノーツ発射源７Ｆ２から離れながら、図２４（Ａ）に示すように互いに異なる方向へ進むことがある。または、２つ以上のノーツ７０が１つずつ連続的に発射され、図２４（Ｂ）に示すように連結して進むことも、ある。

図２４（Ｃ）に示すように、ノーツ７０に「＞＞＞」のマークが付いている場合は、プレーヤは、ノーツ７０をタップする代わりに右方向へフリックすることによって打撃しなければならない。または、「＜＜＜」のマークが付いている場合は、左方向へフリックすることによって打撃しなければならない。

また、所定の回数連続してプレーヤがＰＥＲＦＥＣＴを獲得したり、ＰＥＲＦＥＣＴの累計が所定の回数に達したり、後述するコンボの回数が所定の値に達したりするなど、所定の要件を満たした場合は、ボーナスポイントがポイントとしてプレーヤに与えられる。この際に、図２０のように「スコア２０％ＵＰ！」のようなボーナス通知メッセージ７Ｆ５が現われる。そのほか、出演ユニットのカード４１の才能の高さ（ダンス値Ｋｃ、ボーカル値Ｋｄ、パフォーマンス値Ｋｅ、バックコーラス値Ｋｆ）に応じたボーナスポイントが与えられることもある。

スコアインジケータ７Ｆ６、コンボカウンタ７Ｆ７、およびボルテージインジケータ７Ｆ８は、いずれもリズムゲーム４Ｂにおけるプレーヤの成績（プレイの上手さの評価）を表わす。

スコアインジケータ７Ｆ６は、リズムゲーム４Ｂが開始されてからプレーヤが獲得したポイントの合計である総スコアＳａをプレーヤの成績の１つとして表わす。獲得したポイントには、ボーナスポイントも含まれる。リズムゲーム４Ｂが開始される前、総スコアＳａはゼロであり、スコアインジケータ７Ｆ６は真っ白だが、リズムゲーム４Ｂが開始された後、総スコアＳａが増えるにつれて、左から徐々に、図２０のようにスコアインジケータ７Ｆ６が所定の色（例えば、赤色）に着色されていく。

ところで、リクエスト曲として演奏される楽曲によってもノーツ設定データ６Ｇに設定されている内容によっても、発射されるノーツ７０の総数が異なるので、満点も異なる。そこで、リクエスト曲およびノーツ設定データ６Ｇに基づいて満点が予め算出され、スコアインジケータ７Ｆ６は、満点に対する総スコアＳａの割合に応じて着色されていく。

コンボカウンタ７Ｆ７は、コンボ回数Ｃａをプレーヤの成績の１つとして表わす。「コンボ」は打撃を連続で成功させることであって、「コンボ回数」は、打撃を連続で成功させた回数である。よって、打撃に失敗すると、コンボ回数Ｃａはゼロにリセットされる。

ボルテージインジケータ７Ｆ８は、音楽ライブを視聴する仮想の観客のボルテージ（興奮度）の高さであるボルテージ度数Ｕａをプレーヤの成績の１つとして表わす。ボルテージインジケータ７Ｆ８は、横一列の多数のセルからなり、ボルテージ度数Ｕａに応じた個数分のセルが、図２０に示すように左から着色される。ボルテージ度数Ｕａが所定の最大値のときに、すべてのセルが着色された状態になる。

ボルテージ度数Ｕａのデフォルト値はゼロである。ボルテージ度数Ｕａは、打撃に成功すると所定の量だけ上がり、失敗すると所定の量だけ下がる。ただし、所定の最大値よりも高くならず、ゼロよりも低くならない。つまり、ボルテージ度数Ｕａが所定の最大値であるときに打撃に成功しても、ボルテージ度数Ｕａは上がらない。また、ボルテージ度数Ｕａがゼロであるときに打撃に失敗しても、ボルテージ度数Ｕａは下がらない。ボルテージ度数Ｕａの上がる量は、「ＰＥＲＦＥＣＴ」、「ＧＲＥＡＴ」、「ＧＯＯＤ」の順に多くなるように定めてもよい。

（Ｄ） リクエスト曲の再生
プレーヤは、条件選択画面７Ｄ（図１７参照）において出演ユニットおよびリクエスト曲を選択し、必要に応じてスピード、加速度、および量を指定したら、決定ボタン７Ｄ４をタップする。すると、カレントユニットが出演ユニットとして選択され、リズムゲーム４Ｂが開始される。リズムゲーム４Ｂの処理には、主にリクエスト曲の再生、ノーツ７０の制御、およびポイント等の演算が含まれる。リクエスト曲の再生は、楽曲再生処理部２５（図３参照）によって次のように行われる。

リズムゲーム４Ｂが開始される前に、出演ユニットの５枚のカード４１のカードコードおよび各カード４１のキャラクタ名が楽曲再生処理部２５、動画像再生処理部２７、開始可否判別部２８、およびスペシャルパフォーマンス処理部２９に通知される。

楽曲再生処理部２５は、条件選択画面７Ｄで選択された楽曲すなわちリクエスト曲の楽曲データ６Ｄ（図１５参照）を楽曲データ記憶部２Ｍ４から検索する。その楽曲データ６Ｄの中からインストルメンタルパートの音声データ、出演ユニットのセンタのキャラクタ５のメインボーカルパートの音声データ、および出演ユニットの他のキャラクタ５それぞれのバックコーラスパートの音声データを読み出す。

そして、楽曲再生処理部２５は、これらの読み出した音声データをデコードし、楽器、メインボーカル、およびバックコーラスそれぞれの音声を同期させて音声システム２Ｋによって出力する。なお、音声システム２Ｋにデコード機能が備わっている場合は、デコードを音声システム２Ｋに行わせてもよい。

（Ｅ） ノーツ７０の制御およびポイント等の処理
図２５は、ノーツ再生データ６Ｆの例を示す図である。

リズムゲームボタン７Ａ４がタップされると、ノーツ処理部２６は、上述のルールおよびリクエスト曲のノーツ再生データ６Ｆに基づいて、ノーツ７０の制御およびポイント等の演算の処理を実行する。

ところで、ノーツ再生データ６Ｆは、前述の通り、楽曲ごとに用意され、ノーツ再生データ記憶部２Ｍ６に記憶されている。ノーツ再生データ６Ｆには、図２５のように、リズムゲーム４Ｂの実行中かつ楽曲の演奏中に発射される各ノーツ７０に関する情報が示される。

「グループコード」は、１つまたは複数のノーツ７０からなるグループを識別する識別子である。「タイプ」は、グループの種類であって、次のようなものがある。

「ノーマル」、「右フリック」、および「左フリック」の各グループは、１つのノーツ７０のみからなる。ノーマルのグループのノーツ７０は、図２１〜図２３に示したような形態であって、タップによって打撃される。右フリックのグループのノーツ７０は、図２４（Ｃ）に示したような形態であって、右フリックによって打撃される。左フリックのグループのノーツ７０は、左フリックによって打撃される。

「ダブル」および「ｉ連」の各グループは、複数のノーツ７０からなるグループである。なお「ｉ」は、２以上の整数である。ダブルのグループのノーツ７０の個数は「２」であって、２つのノーツ７０が同時に発射され、図２４（Ａ）に示したように互いに同じスピードで別々の方向へ進み、タップによって打撃される。ｉ連のグループのノーツ７０の個数は「ｉ」であって、ｉ個のノーツ７０が１つずつ１拍ごとに発射され、図２４（Ｂ）に示したように連なって進み、タップによって打撃される。

「発射方向」は、そのグループの各ノーツ７０が発射される方向である。「１」、「２」、…、「７」の各値は、それぞれ、ノーツ発射源７Ｆ２から打撃マーク７９ａ、打撃マーク７９ｂ、…、打撃マーク７９ｇへの方向を意味する。そのグループのタイプがダブルである場合は、値が２つ示されるが、１つ目の値が左側のノーツ７０の発射方向を表わし、２つ目の値が右側のノーツ７０の発射方向を表わす。または、そのグループのタイプがｉ連である場合は、値がｉ個示されるが、ｉ個目の値が、ｉ番目に発射されるノーツ７０の発射方向を表わす。

「発射条件」は、そのグループのノーツ７０を発射するか否かを決めるための条件であって、全体のノーツの量を調整するために用いられる。発射条件として「少」、「中」、および「多」のうちのいずれか１つまたは複数が示されている。上述の通り、ノーツ設定データ６Ｇにも、ノーツの量として「少」、「中」、および「多」のうちの１つが設定されている。ノーツ設定データ６Ｇに示される量が発射条件に含まれる場合は、そのグループのノーツ７０が発射される。

したがって、例えば、グループコードが「Ｎ００１」であるグループについては、発射条件に「少」、「中」、および「多」のすべてが含まれるので、ノーツ設定データ６Ｇに示される量に関わらずノーツ７０が発射される。しかし、「Ｎ００４」であるグループについては、発射条件に「多」のみが含まれるので、ノーツ設定データ６Ｇに示される量が「多」の場合にのみノーツ７０が発射される。

「到達時刻」は、そのグループの１番目のノーツ７０の中心がそのノーツ７０の発射方向の打撃マーク７９の中心と重なる時刻である。到達時刻は、楽曲の開始時を基準とする。後述する他の時刻も同様である。以下、「ノーツ７０が打撃マーク７９に到達する」とは、ノーツ７０および打撃マーク７９それぞれの中心が重なることを意味する。また、ノーツ７０は、ノーツ発射源７Ｆ２から発射される時点において、その中心がノーツ発射源７Ｆ２の中心と重なっているものとする。各グループの到達時刻は、楽曲のリズムおよびテンポに合うように設定されている。

そのグループの２番目以降のノーツ７０の到達時刻は、１拍当たりの時間に基づいて算出することができる。すなわち、ｋ番目のノーツ７０の到達時刻は、１番目のノーツ７０の到達時刻＋（６０［秒］／テンポ）×（ｋ−１）、である。

図３に戻って、ノーツ処理部２６は、リクエスト曲のノーツ再生データ６Ｆをノーツ再生データ記憶部２Ｍ６から読み出し、ノーツ設定データ記憶部２Ｍ７からノーツ設定データ６Ｇを読み出す。読み出したノーツ再生データ６Ｆおよびノーツ設定データ６Ｇに基づいて前述の方法で、発射すべきノーツ７０を特定する。

ノーツ処理部２６は、特定したノーツ７０が到達時刻にオンタイムで打撃マーク７９に到達するように、そのノーツ７０を発射すべき時刻（以下、「発射時刻」と記載する。）を算出する。発射時刻は、ノーツ再生データ６Ｆに示されるそのノーツ７０の到達時刻ならびにノーツ設定データ６Ｇに示されるスピードおよび加速度などに基づいて公知の計算方法で算出される。計算方法の一例は、次の通りである。

一般に、初速度Ｖおよび加速度Ｒで移動する物体は、時間Ｔの間に（１）式の距離Ｘ、移動する。

そのノーツ７０がノーツ発射源７Ｆ２から発射されて打撃マーク７９に到達するまでに移動する距離は、基準カーブ７Ｆ３の半径の長さすなわち距離Ｌｒである。そのノーツ７０の初速度（スピード）および加速度は、ノーツ設定データ６Ｇに設定されている。そこで、これらの値を（１）式に代入し、Ｔの解を求めれば、そのノーツ７０がノーツ発射源７Ｆ２から発射されてから打撃マーク７９に到達するまでに掛かる所要時間が算出される。

例えば、そのノーツ設定データ６Ｇにスピードおよび加速度としてそれぞれＶｂ、Ｒｃが設定されている場合は、

を満たすＴが所要時間として算出される。

ノーツ処理部２６は、このような方法で所要時間を算出し、特定した各ノーツ７０の到達時刻から所要時間だけ遡った時刻を各ノーツ７０の発射時刻として算出する。ただし、ｉ連のグループのノーツ７０の場合は、１番目のノーツ７０の発射時刻だけ、このような方法で算出し、２番目以降のノーツ７０の発射時刻は、リクエスト曲の１拍分の時間を足すことによって算出すればよい。

スピードと加速度との組合せの個数が限られているので、組合せごとの所要時間を予め求めておいてもよい。

そして、ノーツ処理部２６は、特定した各ノーツ７０がリズムゲーム画面７Ｆの中で移動する様子を表わす動画像を生成する。つまり、特定した各ノーツ７０がそれぞれの発射時刻にノーツ発射源７Ｆ２から、ノーツ再生データ６Ｆに示されるそれぞれの発射方向へ、ノーツ設定データ６Ｇに設定されているスピードで発射され、ノーツ設定データ６Ｇに設定されている加速度で加速しながら進み、打撃マーク７９を通過する様子を表わす動画像を、生成する。

さらに、ノーツ処理部２６は、楽曲インジケータ７Ｆ１ないしメニューボタン７Ｆ９および打撃マーク７９の動画像を生成する。そして、上述のルールに基づいて、発射された各ノーツ７０に対する打撃を評価し、その結果に応じて総スコアＳａ、コンボ回数Ｃａ、およびボルテージ度数Ｕａを更新する。これらの値が更新されるのに合わせて、スコアインジケータ７Ｆ６、コンボカウンタ７Ｆ７、およびボルテージインジケータ７Ｆ８（図１９、図２０参照）の画像を更新する。また、打撃が行われた際の効果を表わす動画像も生成する。

リクエスト曲の演奏が開始されまたは１つ目のノーツ７０が打撃マーク７９を通過してから所定の時間（例えば、３０秒）が経過した以降にボルテージ度数Ｕａがゼロになった場合は、ノーツ処理部２６は、ゲームオーバのメッセージを表示させ、リズムゲーム４Ｂを終了させる。そして、メニュー処理部２１によってメニュー画面７Ａ（図１９、図２０参照）が表示される。メニューボタン７Ｆ９がタップされた場合もリズムゲーム４Ｂが終了されメニュー画面７Ａが表示される。

（Ｆ）動画像の再生
図２６は、動画像７Ｖの例を示す図である。

楽曲再生処理部２５およびノーツ処理部２６による処理と並行して、音楽ライブの様子を表わす動画像が動画像再生処理部２７によって次のように再生される。

動画像再生処理部２７は、決定ボタン７Ｄ４（図１７参照）がタップされると、リクエスト曲の動画像データ６Ｅ（図１６参照）を動画像データ記憶部２Ｍ５から読み出す。読み出した動画像データ６Ｅに含まれる５つのモデルそれぞれの３次元データを、出演ユニットの５人のキャラクタ５それぞれの顔情報に合わせて更新する。これにより、５人のキャラクタ５それぞれの３次元モデルが得られる。顔情報は、キャラクタデータ６Ａ（図５参照）に示されている。後述する、スペシャルパフォーマンスの再現の処理においても、同様である。

動画像再生処理部２７は、環境データに基づいてステージおよび周囲の３次元モデルを算出し、５人のキャラクタ５それぞれの３次元モデルをそれぞれの動作データに基づいて配置して動作させる。これらの３次元モデルを、カメラデータに示される仮想のビデオカメラの時刻ごとの位置、撮影方向、および撮影範囲に従ってレンダリングすることによって、音楽ライブの動画像を生成する。

以下、ノーツ処理部２６によって生成された動画像を「リズムゲーム動画像７Ｖ１」と記載する。また、動画像再生処理部２７が生成した、音楽ライブの動画像を「ライブ動画像７Ｖ２」と記載する。

そして、動画像再生処理部２７は、リズムゲーム動画像７Ｖ１およびライブ動画像７Ｖ２を、両者をリクエスト曲と同期させ、かつ、図２６に示すようにリズムゲーム動画像７Ｖ１およびライブ動画像７Ｖ２それぞれを下位のレイヤおよび上位のレイヤとして合成し、ディスプレイ２Ｆに表示させる。これにより、両動画像がマージされた動画像７Ｖが再現される。

なお、リズムゲーム４Ｂが終了するのに伴って、動画像再生処理部２７は、リズムゲーム動画像７Ｖ１を生成するのを終了する。そして、上述の通り、メニュー画面７Ａがメニュー処理部２１によってディスプレイ２Ｆに表示される。

〔５．スペシャルパフォーマンス〕
図２７は、スペシャルパフォーマンスデータ６Ｈの例を示す図である。図２８は、ノーツ発射源７Ｆ２の変化の様子の例を示す図である。図２９は、選出処理の流れの例を示すフローチャートである。図３０は、スペシャルパフォーマンス動画像７Ｖ３の１コマの例を示す図である。

パフォーマンスデータ記憶部２Ｍ８（図３参照）には、図２７に示すように、スペシャルパフォーマンスデータ６Ｈが複数、記憶されている。スペシャルパフォーマンスデータ６Ｈは、５人のキャラクタ５が楽曲に合わせてスペシャルパフォーマンスを行う動画像を再生するためのデータである。

スペシャルパフォーマンスは、上述の通り楽曲の途中で行われるが、本実施形態では、楽曲の間奏後に４〜１６小節程度、行われる。また、スペシャルパフォーマンスの長さは、楽曲ごとに決められている。

スペシャルパフォーマンスデータ６Ｈのフォーマットは、動画像データ６Ｅ（図１６参照）のフォーマットと同様である。つまり、スペシャルパフォーマンスデータ６Ｈは、環境データ、カメラデータ、ならびに各メンバの３次元データおよび動作データを含む。ただし、スペシャルパフォーマンスにおいてセンタのみが登場する場合は、センタ以外のメンバの３次元データおよび動作データは含まれていなくてもよい。

１つの楽曲ごとに、カード４１を問わず共通に使用される３つの共通パフォーマンスデータ６Ｈ１がスペシャルパフォーマンスデータ６Ｈとして用意されている。さらに、特定のカード４１のためだけに使用されるユニークパフォーマンスデータ６Ｈ２が、そのカード４１のカードコードおよび適用要件と対応付けられてスペシャルパフォーマンスデータ６Ｈとして用意されていることがある。「適用要件」は、そのユニークパフォーマンスデータ６Ｈ２を使用することが許可されるための要件である。複数の特定のカード４１それぞれについてユニークパフォーマンスデータ６Ｈ２が１つずつ用意されていてもよい。これらのスペシャルパフォーマンスデータ６Ｈ（共通パフォーマンスデータ６Ｈ１、ユニークパフォーマンスデータ６Ｈ２）それぞれによって再現されるスペシャルパフォーマンスの内容は、相違する。

例えば、「ＢＲＥＡＫＴＨＲＯＵＧＨ！」という楽曲名の楽曲には、３つの共通パフォーマンスデータ６Ｈ１ａ、６Ｈ１ｂ、６Ｈ１ｃが共通パフォーマンスデータ６Ｈ１として用意されている。さらに、ユニークパフォーマンスデータ６Ｈ２ａがカード４１ｐ（図６、図７参照）のユニークパフォーマンスデータ６Ｈ２として用意されている。ユニークパフォーマンスデータ６Ｈ２ａには、カード４１ｔのカードコードおよび「現レベルＫｂ≧５５」という適用要件が対応付けられている。ユニークパフォーマンスデータ６Ｈ２ａによって再現されるスペシャルパフォーマンスの内容は、共通パフォーマンスデータ６Ｈ１ａ〜６Ｈ１ｃによってそれぞれ再現されるスペシャルパフォーマンスの内容よりも高度であり、または、カード４１ｔのキャラクタ５の特徴または個性（例えば、身体の特徴的な動作）が表われている。

スペシャルパフォーマンスへ移行するための所定の要件（以下、「移行要件」と記載する。）が満たされると、スペシャルパフォーマンスが再現される。移行要件が満たされるか否かは、開始可否判別部２８によって判別される。移行要件は、例えば次の５つの要件がすべて満たされることである。
要件＿Ａ：出演ユニットの５枚のカード４１それぞれのレアリティ値Ｋｇの合計が閾値Ｋｔ１（例えば、１５）以上であること。
要件＿Ｂ：出演ユニットのセンタのレアリティ値Ｋｇが閾値Ｋｔ２（例えば、３）以上であること。
要件＿Ｃ：出演ユニットのユニット総合力値Ｐａが閾値Ｐｔ（例えば、１０００００）以上であること。
要件＿Ｄ：リクエスト曲が間奏に入る時点においてボルテージ度数Ｕａが閾値Ｕｔ（例えば、ボルテージの最大値の８０％）以上であること。
要件＿Ｅ：チャンスタイムにおいて所定の回数Ｃｔ（例えば、１６回）以上、打撃に成功すること。

「チャンスタイム」は、リクエスト曲の間奏の開始時から所定の長さの時間帯である。例えば、間奏の開始時から１５秒間の時間帯である。または、間奏の開始時から間奏の終了時までの時間帯であってもよい。なお、要件＿Ｅを満たし得るように、チャンスタイム中にノーツ７０がＣｔ個以上発射されるように各楽曲のノーツ再生データ６Ｆ（図２５参照）が設定されている。

要件＿Ａ、要件＿Ｂ、および要件＿Ｃが満たされるか否かは、リズムゲーム４Ｂが開始される時点で既に決まっている。

そこで、開始可否判別部２８は、リズムゲーム４Ｂが開始されてからリクエスト曲が間奏に入るまでの間に、要件＿Ａ、要件＿Ｂ、および要件＿Ｃが満たされるか否かを判別する。

すなわち、開始可否判別部２８は、出演ユニットの５枚のカード４１それぞれのカードデータ６Ｂ（図７参照）に示されるレアリティ値Ｋｇの合計を算出し、閾値Ｋｔ１以上であれば、要件＿Ａが満たされると判別する。センタのカード４１のカードデータ６Ｂに示されるレアリティ値Ｋｇが閾値Ｋｔ２以上であれば、要件＿Ｂが満たされると判別する。これら５つのカードデータ６Ｂに示されるダンス値Ｋｃ、ボーカル値Ｋｄ、パフォーマンス値Ｋｅ、バックコーラス値Ｋｆの合計値をユニット総合力値Ｐａとして算出し、ユニット総合力値Ｐａが閾値Ｐｔ以上であれば、要件＿Ｃが満たされると判別する。

なお、ダンス、ボーカル、パフォーマンス、およびバックコーラスのすべてが５枚のカード４１のいずれかの属性と一致する場合（つまり、出演ユニットのメンバに４つの属性すべてが含まれる場合）は、開始可否判別部２８は、特例として、要件＿Ｃを緩和する。例えば、「Ｐａ×α」が閾値Ｐｔ以上であれば要件＿Ｃが満たされると判別してもよい。ただし、α＞１、であって、例えば「１．５」である。図１３には、属性がダンスであるカード４１、ボーカルであるカード４１、パフォーマンスであるカード４１、およびバックコーラスであるカード４１が少なくとも１枚ずつ、選択されている。このような場合に、特例が適用される。

要件＿Ａ、要件＿Ｂ、および要件＿Ｃのすべてが満たされると判別した場合は、開始可否判別部２８は、さらに、リクエスト曲が間奏に入る数秒前（例えば、２秒前）においてボルテージ度数Ｕａが閾値Ｕｔ以上であるか否かをチェックする。そして、閾値Ｕｔ以上である場合は、要件＿Ｄが満たされると判別する。なお、以前にボルテージ度数Ｕａが閾値Ｕｔ以上であることがあっても、リクエスト曲が間奏に入る数秒前において閾値Ｕｔ以上でなければ、要件＿Ｄが満たされないと判別する。

要件＿Ｄが満たされると判別した場合は、開始可否判別部２８は、次のように、チャンスタイムの間、要件＿Ｅを満たすことを目標としてプレーヤに打撃を行わせる。開始可否判別部２８は、チャンスタイムに突入したことをノーツ処理部２６へ通知する。

すると、ノーツ処理部２６は、図２８（Ａ）のように、ノーツ発射源７Ｆ２の外枠を太くし、かつ、白抜きにする。プレーヤがノーツ７０の打撃に成功するごとに、図２８（Ｂ）のように、時計の１２時の位置から時計回りに所定の角度（例えば、１１．２５°）の分ずつ順に外枠を着色する。これにより、例えばチャンスタイム中に打撃に６回成功すると、図２８（Ｂ）に示すように外枠が着色される。

チャンスタイムの間は、さらに、プレーヤの緊張感を高めるために、他の時間帯よりも背景の画面の輝度を上げまたは音量を上げてもよい。

開始可否判別部２８は、チャンスタイム中に打撃に成功した回数をカウントする。そして、成功した回数が所定の回数Ｃｔに達したら、すなわち、ノーツ発射源７Ｆ２が図２８（Ｃ）のような状態になったら、要件＿Ｅが満たされると判別する。

そして、開始可否判別部２８は、チャンスタイムが終了するまでに要件＿Ａ〜要件＿Ｅのすべてが満たされると判別することができれば、移行要件が満たされると判別する。

移行要件が満たされると開始可否判別部２８によって判別されると、動画像再生処理部２７およびノーツ処理部２６それぞれの処理が一時的に停止されるとともに、スペシャルパフォーマンスを再現する処理がスペシャルパフォーマンス処理部２９によって次のように実行される。

スペシャルパフォーマンス処理部２９は、リクエスト曲に対応するスペシャルパフォーマンスデータ６Ｈの中からスペシャルパフォーマンスで使用するものを１つ、例えば図２９に示す手順で選出する。

スペシャルパフォーマンス処理部２９は、リクエスト曲に対応するスペシャルパフォーマンスデータ６Ｈの中から、出演ユニットのセンタのカード４１に対応するユニークパフォーマンスデータ６Ｈ２を検索する（図２９の＃１８１）。見つかったら（＃１８２でＹＥＳ）、そのユニークパフォーマンスデータ６Ｈ２に示される適用要件をそのカード４１が満たしているか否かを判別する（＃１８３）。

例えば、その適用要件が「現レベルＫｂ≧５５」であれば、スペシャルパフォーマンス処理部２９は、そのユニークパフォーマンスデータ６Ｈ２に示される現レベルＫｂが５５以上であるか否かをチェックし、５５以上であれば適用要件を満たしていると判別する。

そして、適用要件を満たしていると判別した場合は（＃１８４でＹＥＳ）、スペシャルパフォーマンス処理部２９は、そのユニークパフォーマンスデータ６Ｈ２を選出する（＃１８５）。

適用要件を満たしていないと判別した場合（＃１８４でＮＯ）およびそのようなユニークパフォーマンスデータ６Ｈ２が見つからなかった場合は（＃１８２でＮＯ）、スペシャルパフォーマンス処理部２９は、３つの共通パフォーマンスデータ６Ｈ１のうちの１つを選出する（＃１８６）。

例えば、スペシャルパフォーマンス処理部２９は、３つの共通パフォーマンスデータ６Ｈ１の中からランダムに１つを選出する。または、所定のルールに従って選出する。例えば、出演ユニットのカード４１すべての現レベルＫｂの合計が閾値Ｋｂ１未満であれば１つ目の共通パフォーマンスデータ６Ｈ１を選出し、閾値Ｋｂ１以上かつ閾値Ｋｂ２未満であれば２つ目の共通パフォーマンスデータ６Ｈ１を選出し、閾値Ｋｂ１以上であれが３つ目の共通パフォーマンスデータ６Ｈ１を選出する。この場合は、３つ目、２つ目、１つ目の順に高度なパフォーマンスが再現されるように各共通パフォーマンスデータ６Ｈ１が設定されているのが望ましい。

スペシャルパフォーマンス処理部２９は、選出したスペシャルパフォーマンスデータ６Ｈに含まれるモデルそれぞれの３次元データを、出演ユニットのキャラクタ５それぞれの顔情報に合わせて更新する。これにより、キャラクタ５それぞれの３次元モデルが得られる。

スペシャルパフォーマンス処理部２９は、スペシャルパフォーマンスデータ６Ｈに含まれる環境データに基づいてステージおよび周囲の３次元モデルを算出し、キャラクタ５それぞれの３次元モデルをそれぞれの動作データに基づいて配置して動作させる。ただし、スペシャルパフォーマンスにセンタのみが登場する場合は、センタについてのみ上記の処理を行う。

そして、スペシャルパフォーマンス処理部２９は、これらの３次元モデルを、カメラデータに示される仮想のビデオカメラの時刻ごとの位置、撮影方向、および撮影範囲に従ってレンダリングすることによって、図３０に示すようなコマ（フレーム）を有するスペシャルパフォーマンスの動画像を生成する。

以下、スペシャルパフォーマンス処理部２９によって生成された動画像を「スペシャルパフォーマンス動画像７Ｖ３」と記載する。図３０には、センタのキャラクタ５が、通常とは異なる振付でソロのパートを歌う様子を例示しているが、スペシャルパフォーマンス動画像７Ｖ３には、そのほか、通常は行わないパフォーマンスをキャラクタ５が行う様子が表われる。

そして、動画像再生処理部２７は、スペシャルパフォーマンス動画像７Ｖ３をリクエスト曲と同期させてディスプレイ２Ｆに表示させる。図３０の通り、リズムゲーム画面７Ｆ（図１９、図２０参照）およびリズムゲーム動画像７Ｖ１（図２６参照）はスペシャルパフォーマンス動画像７Ｖ３にマージされない。

このように、移行要件が満たされるとリズムゲーム４Ｂが一時的に停止し、スペシャルパフォーマンスが再現される。よって、プレーヤは、リズムゲーム４Ｂへの集中から一時的に解放され、スペシャルパフォーマンスをゆっくりと鑑賞することができる。

一方、移行要件が満たされていないと開始可否判別部２８によって判別された場合は、スペシャルパフォーマンス処理部２９による処理が行われることなく、動画像再生処理部２７およびノーツ処理部２６それぞれの処理が継続される。

ところで、スペシャルパフォーマンスが再現される間、リズムゲーム４Ｂが停止するので、プレーヤは、リズムゲーム４Ｂが停止しなければ本来行うべき打撃を行うことができないので、スペシャルパフォーマンスがなければ取得できるポイントを取得できない。そこで、スペシャルパフォーマンスが再現された場合は、本来行うべき打撃によって生じるすべてのポイントを総スコアＳａに加算してもよい。

〔６．リズムゲーム４Ｂの再開〕
スペシャルパフォーマンスが終了したら、ノーツ処理部２６は、ノーツ７０の制御、ポイント等の処理、およびリズムゲーム動画像７Ｖ１の生成を再開し、動画像再生処理部２７は、ライブ動画像７Ｖ２の生成およびリズムゲーム動画像７Ｖ１およびライブ動画像７Ｖ２のマージ等を再開する。これにより、音楽ライブの様子を背景にリズムゲーム４Ｂが再開される。

この際に、ノーツ処理部２６はリクエスト曲のノーツ再生データ６Ｆ（図２５参照）に従い、動画像再生処理部２７はリクエスト曲の動画像データ６Ｅ（図１６参照）に従うが、スペシャルパフォーマンスの時間帯の部分はスキップし、スペシャルパフォーマンスの終了時刻からの部分に従う。これにより、スペシャルパフォーマンスが再現されなかった場合の流れに合流することができる。

楽曲再生処理部２５によるリクエスト曲の再生の処理が終わると、ノーツ処理部２６および動画像再生処理部２７もそれぞれの処理を終了する。リズムゲーム４Ｂの成績（例えば、総スコアＳａ、コンボ回数Ｃａ、およびボルテージ度数Ｕａそれぞれの最終値およびゲーム中の最高値）を表示させる。そして、メニュー処理部２１によってメニュー画面７Ａ（図８参照）が再びディスプレイ２Ｆに表示される。

なお、リズムゲーム４Ｂの結果を出演ユニットの各カード４１に反映させてもよい。例えば、リズムゲーム４Ｂの終了時の総スコアＳａ、コンボ回数Ｃａ、またはボルテージ度数Ｕａに応じた値を、各カード４１の経験値Ｋａに加算してもよい。または、スペシャルパフォーマンスを再生することができた場合に、所定の値を各カード４１の経験値Ｋａに加算してもよい。

〔７．まとめ〕
図３１〜図３２は、アプリケーション２Ｐによる全体的な処理の流れの例を示すフローチャートである。

次に、端末装置２がアプリケーション２Ｐに基づいて行う全体的な処理の流れを、図３１〜図３２のフローチャートを参照しながら説明する。

端末装置２は、アプリケーション２Ｐを起動すると、メニュー画面７Ａ（図８参照）を表示する（図３１の＃１０１）。レッスンボタン７Ａ１、課題活動ボタン７Ａ２、またはフェスティバルボタン７Ａ３がタップされると（＃１０２でＹＥＳ）、プレーヤによる操作に応じて、対象のカード４１のキャラクタ５の育成をシミュレートする（＃１０３）。すなわち、レッスンボタン７Ａ１がタップされた場合は、そのキャラクタ５がレッスンを受講するのをシミュレートする。課題活動ボタン７Ａ２がタップされた場合は、そのキャラクタ５が課外活動に取り組むのをシミュレートする。フェスティバルボタン７Ａ３がタップされた場合は、フェスティバルでの競争をシミュレートする。そして、そのカード４１のカードデータ６Ｂ（図７参照）を更新する。

または、ユニット編成ボタン７Ａ５がタップされると（＃１０４でＹＥＳ）、端末装置２は、ユニットのメンバを編成するための処理を行う（＃１０５）。すなわち、ユニット編成画面７Ｂ（図１０、図１２、図１３参照）およびカード一覧画面７Ｃ（図１１参照）を表示し、ユニット編成画面７Ｂおよびカード一覧画面７Ｃに対する操作に応じて、対象のユニット（被選択ユニット）のユニットデータ６Ｃ（図９、図１４参照）を更新する。

または、リズムゲームボタン７Ａ４がタップされると（＃１０６でＹＥＳ）、端末装置２は、リズムゲーム４Ｂおよび音楽ライブの条件を受け付ける処理を行う（＃１０７）。すなわち、条件選択画面７Ｄ（図１７参照）を表示し、リクエスト曲および出演ユニットを受け付ける。さらに、必要に応じて、ノーツ設定画面７Ｅ（図１８参照）を表示し、ノーツのスピード（初速度）、加速度、および量の選択を受け付け、ノーツ設定データ６Ｇを更新する。

そして、決定ボタン７Ｄ４がタップされると、端末装置２は、ステップ＃１０７で受け付けた（条件選択画面７Ｄでプレーヤが選択した）リクエスト曲の再生、ノーツ７０の制御、および音楽ライブの動画像の再生などを開始する（＃１０８〜＃１１０）。つまり、リズムゲーム４Ｂおよび音楽ライブを開始する。

リズムゲーム４Ｂおよび音楽ライブにおいて、リクエスト曲は、リクエスト曲の楽曲データ６Ｄ（図１５参照）に基づいて再生される。ノーツ７０は、ノーツ設定データ６Ｇおよびリクエスト曲のノーツ再生データ６Ｆに基づいて、リクエスト曲と同期してリズムゲーム画面７Ｆ（図１９〜図２４参照）の中で発射され移動する。また、プレーヤによるノーツ７０の打撃の結果に応じて総スコアＳａ、コンボ回数Ｃａ、およびボルテージ度数Ｕａが更新される。音楽ライブの動画像は、リクエスト曲の動画像データ６Ｅ（図１６参照）およびキャラクタデータ６Ａ（図５参照）に基づいて生成される。そして、リズムゲーム動画像７Ｖ１（リズムゲーム画面７Ｆの中のノーツ７０その他のオブジェクトの動画像）とライブ動画像７Ｖ２（音楽ライブの動画像）とが合成され、リクエスト曲と同期して動画像７Ｖとして表示される（図２６参照）。

リズムゲーム４Ｂおよび音楽ライブの開始時からリクエスト曲の間奏の直前または数秒前までの間に、端末装置２は、要件＿Ａ、要件＿Ｂ、および要件＿Ｃが満たされているか否かを判別する（＃１１１）。

リズムゲーム４Ｂの途中でメニューボタン７Ｆ９がタップされた場合（＃１１２でＹＥＳ）、および、リズムゲーム４Ｂが開始されまたは１つ目のノーツ７０が打撃マーク７９を通過してから所定の時間が経過した後にボルテージ度数Ｕａがゼロになった場合は（＃１１３でＹＥＳ）、端末装置２は、リズムゲーム４Ｂおよび音楽ライブを終了してメニュー画面７Ａを再び表示する（＃１０１）。

端末装置２は、リクエスト曲の再生個所が間奏の開始時の数秒前（例えば、２秒前）に到達し（＃１１４でＹＥＳ）、かつ、要件＿Ａ、要件＿Ｂ、および要件＿Ｃがすべて満たされるとステップ＃１１１において判別していれば（＃１１５でＹＥＳ）、要件＿Ｄが満たされるか否かを判別する（＃１１６）。具体的には、間奏の開始時の数秒前においてボルテージ度数Ｕａが閾値Ｕｔ以上であれば、要件＿Ｄが満たされると判別する。

端末装置２は、要件＿Ｄが満たされると判別すると（図３２の＃１１７）、チャンスタイムの間（リクエスト曲の間奏の開始時から所定の長さの時間帯）、図２８に示したようにノーツ発射源７Ｆ２の形態を変更するとともに、プレーヤが成功した打撃の回数をカウントする（＃１１８）。そして、カウントした回数に基づいて、要件＿Ｅが満たされるか否かを判別する（＃１１９）。具体的には、カウントした回数が所定の回数Ｃｔに達したら、要件＿Ｅが満たされると判別する。

端末装置２は、要件＿Ｅが満たされると判別すると（＃１２０でＹＥＳ）、スペシャルパフォーマンスを次のように提供する。

端末装置２は、リクエスト曲に対応する複数のスペシャルパフォーマンスデータ６Ｈの中からスペシャルパフォーマンスに使用するものを１つ、選出する（＃１２１）。選出する方法は、前に図２９で説明した通りである。

リクエスト曲の間奏が終了すると、端末装置２は、ノーツ７０の制御等を一時的に停止するとともに（＃１２２）、動画像データ６Ｅに基づいて動画像を生成する処理を一時的に停止する（＃１２３）。そして、ステップ＃１２１で選出したスペシャルパフォーマンスデータ６Ｈに基づいてスペシャルパフォーマンス動画像７Ｖ３（図３０参照）を生成し表示する（＃１２４）。つまり、リズムゲーム４Ｂを一時的に停止し、音楽ライブの通常の動画像の代わりにスペシャルパフォーマンスの動画像を提供する。

そして、スペシャルパフォーマンスの動画像が終わったら、端末装置２は、リズムゲーム４Ｂおよび音楽ライブの通常の動画像の提供を再開する（＃１２５、＃１２６）。なお、この際に、楽曲データ６Ｄ、動画像データ６Ｅ、およびノーツ再生データ６Ｆは、それぞれ、スペシャルパフォーマンス直後の時刻からの部分が用いられる。

再開後も、スペシャルパフォーマンス前と同様に、端末装置２は、メニューボタン７Ｆ９がタップされた場合（＃１３０でＹＥＳ）、および、ボルテージ度数Ｕａがゼロになった場合に（＃１３１でＹＥＳ）、リズムゲーム４Ｂおよび音楽ライブを終了してメニュー画面７Ａを再び表示する（＃１０１）。リクエスト曲が最後まで演奏されたら（＃１３２でＹＥＳ）、メニュー画面７Ａを表示する（＃１０１）。

または、要件＿Ａ、要件＿Ｂ、および要件＿Ｃのうちの少なくとも１つが満たされないとステップ＃１１１において判別した場合（＃１１５でＮＯ）、端末装置２は、ステップ＃１１８〜＃１１９のチャンスタイムに関する処理も、ステップ＃１２１〜１２６のスペシャルパフォーマンスに関する処理も、行わない（＃１２７、＃１２８）。要件＿Ｄが満たされないとステップ＃１１６で判別した場合も（＃１１７でＮＯ）、同様である。そして、原則としてメニューボタン７Ｆ９がタップされまたはボルテージ度数Ｕａがゼロにならない限り、リクエスト曲が最後まで演奏されるまでリズムゲーム４Ｂおよび音楽ライブを継続する（＃１３０〜＃１３２）。

または、要件＿Ｅが満たされないとステップ＃１１９において判別した場合は（＃１２０でＹＥＳ）、端末装置２は、ステップ＃１２１〜１２６のスペシャルパフォーマンスに関する処理を行わない（＃１２９）。そして、原則としてメニューボタン７Ｆ９がタップされまたはボルテージ度数Ｕａがゼロにならない限り、リクエスト曲が最後まで演奏されるまでリズムゲーム４Ｂおよび音楽ライブを継続する（＃１３０〜＃１３２）。

メニュー画面７Ａにおいて終了ボタン７Ａ６がタップされると（＃１３３でＹＥＳ）、端末装置２は、アプリケーション２Ｐを終了させる。

本実施形態によると、アイドル育成ゲーム４Ａを継続してプレイするモチベーションを、育成のシミュレーションのアップデート以外の方法によってプレーヤに与えることができる。

具体的には、本実施形態では、育成の既存のシミュレーションをアップデートしたり育成の新たなシミュレーションを取り入れたりするのではなく、リズムゲーム４Ｂ、すなわち、育成ゲームとは異なるジャンルのゲームを取り入れている。しかも、リズムゲーム４Ｂを単に取り入れるのではなく、アイドル育成ゲーム４Ａでプレーヤが育成したキャラクタ５がリズムゲーム４Ｂの進行に合わせてリズムゲーム４Ｂの楽曲を演奏する様子が再生される。

したがって、アイドル育成ゲーム４Ａへのリズムゲーム４Ｂの親和性が従来よりも向上し、プレーヤは、キャラクタ５との一体感を感じながら音楽ライブを楽しむことができる。

さらに、アイドル育成ゲーム４Ａおよびリズムゲーム４Ｂのそれぞれで一定の要件をクリアすれば、キャラクタ５によるスペシャルパフォーマンスが報奨として再生される。

したがって、プレーヤは、俊敏な操作が苦手であってもスペシャルパフォーマンスを目標にリズムゲーム４Ｂに集中しようとする意識が働く。スペシャルパフォーマンスの最中は、リズムゲーム４Ｂが停止するので、目標を達成したらリラックスしてスペシャルパフォーマンスを鑑賞することができる。そして、アイドル育成ゲーム４Ａに関する要件を満たすことも必要なので、アイドル育成ゲーム４Ａを継続するモチベーションを従来よりも高めることができる。

なお、このように、プレーヤが育成したキャラクタ５による音楽ライブおよびスペシャルパフォーマンスが、アイドル育成ゲーム４Ａを継続するモチベーションをプレーヤに与えるので、リズムゲーム４Ｂの難易度は低くても構わない。プレーヤは、俊敏な操作が苦手な場合および早くスペシャルパフォーマンスを鑑賞したい場合は、ノーツ７０のスピード、加速度、および量を調整することによって、難易度を低く設定することができる。

このようなプレーヤのために、デフォルトでは、難易度が最も低くなるようにノーツ７０のスピード、加速度、および量が設定されているのが望ましい。

〔８．変形例〕
（ａ）センタおよびスペシャルパフォーマの分担
図３３は、ユニット編成画面７ＢＸの例を示す図である。図３４は、ユニット編成画面７ＢＸのグレーアウト時の例を示す図である。

本実施形態では、出演ユニットのセンタのカード４１のキャラクタ５がメインボーカルおよびスペシャルパフォーマンスの両方を担当したが、異なる２枚のカード４１それぞれのキャラクタ５が担当することができるように、例えば次のように複合ゲーム４を構成してもよい。以下、スペシャルパフォーマンスを行うメンバを「スペシャルパフォーマ」と記載する。

図３のユニット編成部２３は、図１３などに示したユニット編成画面７Ｂの代わりに、図３３のようなユニット編成画面７ＢＸを表示させる。ユニット編成画面７ＢＸには、パフォーマ設定ボタン７Ｂ６が配置されている。

プレーヤがパフォーマ設定ボタン７Ｂ６をタップすると、ユニット編成部２３は、図３４のように、メンバ領域７Ｂ２がプレーヤに注目されるように、メンバ領域７Ｂ２以外の部分をグレーアウトしてユニット編成画面７ＢＸを表示させ直す。プレーヤは、スペシャルパフォーマを担当させるキャラクタ５を、そのキャラクタ５に対応するメンバ領域７Ｂ２をタップすることによって選択する。

すると、ユニット編成部２３は、グレーアウトを解除した状態でユニット編成画面７ＢＸを表示させ直す。この際に、選択されたキャラクタ５のカード４１のカード画像の上に所定の画像を、他のカード４１と区別するために重ねてもよい。例えば、「ＳＰ」のような文字列を重ねてもよい。

さらに、ユニット編成部２３は、被選択ユニットのユニットデータ６Ｃ（図９、図１４参照）のメンバカードコードの中のスペシャルパフォーマのカードコードの先頭または末尾に「ＳＰ」のような所定の識別子を付す。

開始可否判別部２８は、図３１のステップ＃１１１において要件＿Ｂ（出演ユニットのセンタのレアリティ値Ｋｇが閾値Ｋｔ２以上であること）の代わりに、要件＿Ｂ’（出演ユニットのスペシャルパフォーマのレアリティ値Ｋｇが閾値Ｋｔ２以上であること）が満たされるか否かを判別する。

スペシャルパフォーマンス処理部２９は、図２９のステップ＃１８１において、リクエスト曲に対応するスペシャルパフォーマンスデータ６Ｈの中から、出演ユニットのスペシャルパフォーマのカード４１に対応するユニークパフォーマンスデータ６Ｈ２を検索する。ステップ＃１８３において、そのユニークパフォーマンスデータ６Ｈ２に示される適用要件をスペシャルパフォーマのカード４１が満たしているか否かを判別する。そして、スペシャルパフォーマンスを行う３次元モデルを、スペシャルパフォーマの顔画像に合わせて更新し、動画像を生成する。

（ｂ）移行要件
本実施形態では、要件＿Ａ〜要件＿Ｅの組合せが移行要件（スペシャルパフォーマンスを提供するための要件）として用いられた。

要件＿Ａ〜要件＿Ｃは、出演ユニットに関する要件であって、特に出演ユニットのカード４１のレアリティ値Ｋｇまたはユニット総合力値Ｐａに関する要件であったが、経験値Ｋａまたは現レベルＫｂに関する要件であってもよい。例えば、センタの現レベルＫｂが所定のレベル以上であることを要件＿Ｂに追加してもよいし、要件＿Ｂの代わりに用いてもよい。または、経験値Ｋａないしレアリティ値Ｋｇのいずれかを任意に選択し要件を設定してもよい。例えば、要件＿Ｂを、出演ユニットのセンタの現レベルＫｂおよびレアリティ値Ｋｇがそれぞれ閾値Ｋｂ３（例えば、３０）以上および閾値Ｋｔ２（例えば、３）以上である、と設定してもよい。いずれにせよ、価値が高いほど移行要件が満たされやすいように、出演ユニットに関する要件が定められる。つまり、育成が進んでいるほど移行要件が満たされやすいように、または、希少性が高いほど移行要件が満たされやすいように、出演ユニットに関する要件が定められる。

要件＿Ｄは、リクエスト曲の開始時から間奏の数秒前までの時間帯における成績に関する要件であって、特にボルテージ度数Ｕａに関する要件であったが、総スコアＳａまたはコンボ回数Ｃａに関する要件であってもよい。いずれにせよ、この時間帯における成績が良いほど移行要件が満たされやすいように、この時間帯における成績に関する要件が定められる。

要件＿Ｅは、チャンスタイムにおける成績に関する要件であって、特に打撃の成功回数に関する要件であったが、コンボ数またはボルテージに関する要件であってもよい。いずれにせよ、チャンスタイムにおける成績が良いほど移行要件が満たされやすいように、チャンスタイムにおける成績に関する要件が定められる。移行要件に含まれるのは、要件＿Ｄおよび要件＿Ｅのうちのいずれか一方だけであってもよい。

本実施形態では、要件＿Ａ〜要件＿Ｅの５つすべてが満たされる場合に移行要件が満たされると判別されたが、５つのうち所定の個数（例えば、３つ）以上の要件が満たされれば移行要件が満たされると判別されるようにしてもよい。

または、出演ユニットの価値およびプレーヤによるリズムゲーム４Ｂのプレイの成績のそれぞれを５０点満点で算出し、両点数の合計が所定の点数以上であれば、移行要件が満たされると判別されるようにしてもよい。

（ｃ）スペシャルパフォーマンス
本実施形態では、キャラクタ５の３次元モデルを動作させることによってスペシャルパフォーマンスの動画像を生成した。つまり、視覚的なスペシャルパフォーマンスを提供した。視覚的なスペシャルパフォーマンスの代わりに、アドリブのようなまたは変則的な歌詞、音程、またはリズムによる音声をスペシャルパフォーマンスとして提供してもよい。またはアカペラをスペシャルパフォーマンスとして提供してもよい。つまり、聴覚的なスペシャルパフォーマンスを提供してもよい。または、視覚的なスペシャルパフォーマンスおよび聴覚的なスペシャルパフォーマンスの両方を提供してもよい。これらの場合は、スペシャルパフォーマンスデータ６Ｈ（図２７参照）に、スペシャルパフォーマンス用の音声データを含めておけばよい。

または、キャラクタ５の３次元モデルを動作させる代わりに、実写の動画像を再生することによってスペシャルパフォーマンスを提供してもよい。

本実施形態では、１枚のカード４１のキャラクタ５のみによるスペシャルパフォーマンスを再現したが、複数枚のカード４１それぞれのキャラクタ５が協力して行うスペシャルパフォーマンスを再現してもよい。さらに、複数枚のカード４１の組合せに応じたスペシャルパフォーマンスデータ６Ｈを用意しておき、このスペシャルパフォーマンスデータ６Ｈを優先的に用いてスペシャルパフォーマンスを再現してもよい。

（ｄ）サポートメンバ
図３５は、ユニット編成画面７ＢＹの例を示す図である。

プレーヤが所有するカード４１の中からサポートメンバをさらに選択し、音楽ライブをサポートさせることができるようにしてもよい。

この場合は、ユニット編成部２３は、ユニット編成画面７Ｂの代わりに図３５のようなユニット編成画面７ＢＹを表示させる。プレーヤは、３つのサポートメンバ領域７Ｂ７を順次タップする。すると、ユニット編成部２３は、被選択ユニットのメンバの選択の場合と同様に、カード一覧画面７Ｃ（図１１参照）を表示させ、サポートメンバのカード４１をプレーヤに選択させる。そして、被選択ユニットのユニットデータ６Ｃ（図９、図１４参照）のメンバカードコードの末尾に、サポートメンバとして選択された３枚のカード４１それぞれのカードコードを追記する。

または、条件選択画面７Ｄ（図１７参照）からカード一覧画面７Ｃを呼び出してサポートメンバを選択できるように構成してもよい。この場合は、音楽ライブごとにサポートメンバを変えることが、より簡単になる。

サポートメンバが音楽ライブのスタッフ（例えば、演出家またはプロデューサ）として音楽ライブをサポートする場合は、スペシャルパフォーマンス処理部２９は、サポートメンバの作業の特性が現われるようにスペシャルパフォーマンスを再現する。この場合は、カード４１ごとに、スペシャルパフォーマンスに変化を加えるためのデータを変化データとして予め用意しておき、サポートメンバとして選択されたカード４１の変化データに基づいてスペシャルパフォーマンスを再現すればよい。

または、サポートメンバがバックダンサとして音楽ライブをサポートする場合は、スペシャルパフォーマンス処理部２９は、サポートメンバとして選択されたカード４１のキャラクタ５が登場するようにスペシャルパフォーマンスを再現する。この場合は、スペシャルパフォーマンスデータ６Ｈにサポートメンバごとの３次元データおよび動作データを含ませておき、これらのデータに基づいてスペシャルパフォーマンスを再現すればよい。

（ｅ）ゲームシステム１全体の構成
本実施形態では、図３に示した各機能をすべて端末装置２に設けたが、一部の機能を他の装置に設けてもよい。例えば、キャラクタデータ記憶部２Ｍ１ないしパフォーマンスデータ記憶部２Ｍ８の各記憶部をサーバ３に設けてもよい。

この場合は、端末装置２は、アイドル育成ゲーム４Ａ、リズムゲーム４Ｂ、音楽ライブ、またはスペシャルパフォーマンスのために必要なデータを適宜、サーバ３からダウンロードする。また、プレーヤの操作に応じて更新したデータを適宜、サーバ３へアップロードする。このように構成すれば、プレーヤは、自分の所有する複数台の端末装置２のうちの１台において獲得しまたは育成したカード４１を、他の１台で使用して複合ゲーム４を楽しむことができる。

さらに、開始可否判別部２８をサーバ３に設けてもよい。この場合は、要件＿Ｄを満たしたか否かを判断するための情報として、リクエスト曲が間奏に入る時点におけるボルテージ度数Ｕａを端末装置２からサーバ３へ通知する。チャンスタイムの処理が行われる場合は、さらに、要件＿Ｅを判断するための情報として、チャンスタイム中、打撃に成功するごとに、その旨を端末装置２からサーバ３へ通知する。

さらに、アイドル育成ゲーム４Ａにおけるシミュレーション、リズムゲーム４Ｂにおけるノーツの制御および成績（総スコアＳａ、コンボ回数Ｃａ、ボルテージ度数Ｕａ）の算出、ならびに動画像７Ｖおよびスペシャルパフォーマンス動画像７Ｖ３の生成をサーバ３に行わせてもよい。この場合は、端末装置２は、各画面に対してなされた操作の内容をサーバ３へ通知する。サーバ３は、動画像７Ｖおよびリクエスト曲を端末装置２へストリーミング配信する。移行要件が満たされるか否かを判別し、満たされる場合は、スペシャルパフォーマンス動画像７Ｖ３を端末装置２へストリーミング配信する。サーバ３は、これらの処理をコンピュータプログラムを実行することに実行する。端末装置２は、動画像７Ｖおよびスペシャルパフォーマンス動画像７Ｖ３を表示し、リクエスト曲を再生する。

または、他のプレーヤが獲得しまたは育成したカード４１のカードデータ６Ｂを端末装置２にインポートしてリズムゲーム４Ｂ、音楽ライブ、およびスペシャルパフォーマンスのために使用できるように構成してもよい。カードデータ６Ｂのやり取りは、サーバ３などの他の装置を介して行ってもよいし、Ｐ２Ｐ（Peer To Peer）で行ってもよい。

（ｆ）その他
本実施形態では、リクエスト曲の間奏の時間帯にチャンスタイムの処理を実行したが、スペシャルパフォーマンスの前の時間帯であれば、他の時間帯であってもよい。リクエスト曲が例えば前から順にイントロ、Ａメロ、Ｂメロ、サビ、およびアウトロによって構成され、スペシャルパフォーマンスをサビで再現する場合は、Ｂメロの時間帯にチャンスタイムの処理を実行してもよい。

本実施形態では、ダンス、ボーカル、パフォーマンス、およびバックコーラスをキャラクタ５の才能として例示したが、他の才能であってもよい。例えば、バックコーラスの代わりにラップ（rap）、スキャット（scat）、または楽器の演奏であってもよい。または、才能は３つ以下であってもよいし、５つ以上であってもよい。

本実施形態では、キャラクタデータ６Ａ（図５参照）をキャラクタ５ごとに用意したが、カード４１ごとに用意してもよい。すると、キャラクタデータ６Ａの個数が増えるので開発者の負担が大きくなるが、例えば同じキャラクタ５のカード４１であってもレアリティ値Ｋｇが高いものほど大人っぽい顔の顔情報を用意するなど、きめ細かな再現を行うことができる。楽曲データ６Ｄ（図１５参照）のボーカルパートデータおよびバックコーラスパートデータも同様に、キャラクタ５ごとではなくカード４１ごとに、レアリティ値Ｋｇが高いものほど上手な歌声が再現されるように用意してもよい。

本実施形態では、１つのキャラクタ５に対してカード４１を複数枚、用意したが、１枚のみ用意してもよい。カード４１を収集する楽しみが若干、損なわれるが、キャラクタ５とカード４１との関連性がシンプルになり、複合ゲーム４を簡単化することができる。

ただし、この場合は、要件＿Ａ（出演ユニットの５枚のカード４１それぞれのレアリティ値Ｋｇの合計が閾値Ｋｔ１以上であること）および要件＿Ｂ（出演ユニットのセンタのレアリティ値Ｋｇが閾値Ｋｔ２以上であること）の代わりに、レアリティ値Ｋｇ以外の要素に関する要件を用いるのが望ましい。例えば、要件＿Ａおよび要件＿Ｂの代わりにそれぞれ要件＿Ａ’（出演ユニットの５枚のカード４１それぞれの現レベルＫｂの合計が閾値Ｋｔ３以上であること）および要件＿Ｂ’（出演ユニットのセンタの現レベルＫｂが閾値Ｋｔ４以上であること）を用いる。

本実施形態では、楽曲の歌のパートがメインボーカルおよびバックコーラスの２つである場合を例に説明したが、５つであってもよい。５つである場合は、各キャラクタ５の５つそれぞれのパートの音声データが含まれるように楽曲データ６Ｄを用意しておき、所定のルールに基づいて初期配列に応じてパートが割り当てられるようにすればよい。

本実施形態では、ユニットのメンバが５人である場合を例に説明したが、１〜４人であってもよいし、６人以上であってもよい。

本実施形態では、リズムゲーム４Ｂの難易度は、ノーツ７０のスピード、加速度、および量を調整することによって設定されたが、打撃が成功したか否かを判別する際の閾値（距離Ｄ１〜Ｄ３）を変更することによって設定できるようにしてもよい。

その他、ゲームシステム１、端末装置２、複合ゲーム４の全体または各部の構成、処理の内容、処理の順序、データの構成、画面の構成などは、本発明の趣旨に沿って適宜変更することができる。

１ ゲームシステム
２２ 育成処理部（育成ゲーム手段）
２６ ノーツ処理部（音楽ゲーム手段）
２７ 動画像再生処理部（第一の表示処理手段）
２８ 開始可否判別部（判別手段）
２９ スペシャルパフォーマンス処理部（第二の表示処理手段）
２Ｆ ディスプレイ
２Ｐ アプリケーション（コンピュータプログラム）
４Ａ アイドル育成ゲーム（育成ゲーム）
４Ｂ リズムゲーム（音楽ゲーム）
５ キャラクタ（キャラクタ、サブキャラクタ）
７０ ノーツ（第一のマーク）
７９ 打撃マーク（第二のマーク）
７Ｆ２ ノーツ発射源（発射源）
７Ｖ１ リズムゲーム動画像（第三の動画像）
７Ｖ２ ライブ動画像（第一の動画像）
７Ｖ３ スペシャルパフォーマンス動画像（第二の動画像）

本発明の一形態に係るコンピュータプログラムは、再生される楽曲である再生曲に合わせてプレーヤがアクションを行う音楽ゲームを提供する音楽ゲーム手段、育成ゲームにおいて仮想的に育成されかつ複数の才能のうちのいずれか１つが特技として設定されているキャラクタが、前記育成ゲームにおいて仮想的に育成されかつ前記複数の才能のうちのいずれか１つが特技として設定されている１または複数のサブキャラクタとともにライブを行う様子を表わす第一の動画像を、前記音楽ゲーム手段によって前記音楽ゲームが提供されている間、ディスプレイに表示させる第一の表示処理手段、前記キャラクタが特別なパフォーマンスを行う様子を表わす第二の動画像を、前記プレーヤによる前記音楽ゲームのプレイの評価が一定以上であるいう第一の要件が満たされかつ前記育成ゲームにおいて前記キャラクタおよび前記１または複数のサブキャラクタそれぞれの価値の合計が一定以上であるという第二の要件が満たされる場合に前記ディスプレイに表示させる第二の表示処理手段としてコンピュータを機能させるためのコンピュータプログラムであって、前記複数の才能のすべてが前記キャラクタおよび前記１または複数のサブキャラクタのそれぞれの前記特技のいずれかと一致する場合に、前記第二の要件を緩和させ、前記育成ゲームにおいて、希少性の異なる複数の仮想のカードが前記キャラクタおよび前記１または複数のサブキャラクタのそれぞれに対して用意されており、前記キャラクタおよび前記１または複数のサブキャラクタそれぞれの前記価値として、前記プレーヤが前記複数の仮想のカードの中から前記キャラクタおよび前記１または複数のサブキャラクタそれぞれについて選択したものの前記希少性の高さを用いる。

または、前記第二の表示処理手段は、前記１または複数のサブキャラクタとともに前記キャラクタが前記パフォーマンスを行う様子を表わす動画像を前記第二の動画像として表示させる。

Claims (18)

1. 再生される楽曲である再生曲に合わせてプレーヤがアクションを行う音楽ゲームを提供する音楽ゲーム手段、
   育成ゲームにおいて仮想的に育成されるキャラクタがライブを行う様子を表わす第一の動画像を、前記音楽ゲーム手段によって前記音楽ゲームが提供されている間、ディスプレイに表示させる第一の表示処理手段、
   前記キャラクタが特別なパフォーマンスを行う様子を表わす第二の動画像を、前記音楽ゲームおよび前記育成ゲームそれぞれにおける状況に関する所定の要件が満たされる場合に前記ディスプレイに表示させる第二の表示処理手段
   としてコンピュータを機能させるためのコンピュータプログラム。
2. 前記コンピュータをさらに、前記育成ゲームを提供する育成ゲーム手段として機能させる、
   請求項１に記載のコンピュータプログラム。
3. 前記所定の要件は、前記プレーヤによる前記音楽ゲームのプレイの評価が一定以上であるいう第一の要件が満たされ、かつ、前記育成ゲームおける前記キャラクタの価値が一定以上であるという第二の要件が満たされることである、
   請求項１または請求項２に記載のコンピュータプログラム。
4. 前記育成ゲームは、前記キャラクタがレッスンを受けるシミュレーションを行い、前記シミュレーションを行うごとに前記価値を向上させるゲームである、
   請求項３に記載のコンピュータプログラム。
5. 前記育成ゲームにおいて、希少性の異なる複数の仮想のカードが前記キャラクタに対して用意されており、
   前記価値は、前記プレーヤが前記複数の仮想のカードの中から選択したものの前記希少性の高さである、
   請求項３に記載のコンピュータプログラム。
6. 前記第一の表示処理手段は、前記育成ゲームにおいて仮想的に育成される１または複数のサブキャラクタとともに前記キャラクタが前記ライブを行う様子を表わす動画像を前記第一の動画像として前記ディスプレイに表示させ、
   前記所定の要件は、前記プレーヤによる前記音楽ゲームのプレイの評価が一定以上であるいう第一の要件が満たされ、かつ、前記育成ゲームにおいて前記キャラクタおよび前記１または複数のサブキャラクタそれぞれの価値の合計が一定以上であるという第三の要件が満たされることである、
   請求項１または請求項２に記載のコンピュータプログラム。
7. 前記キャラクタおよび前記１または複数のサブキャラクタのそれぞれには、複数の才能のうちのいずれか１つが特技として設定されており、
   前記複数の才能のすべてが前記キャラクタおよび前記１または複数のサブキャラクタのそれぞれの前記特技のいずれかと一致する場合に、前記第三の要件が緩和される、
   請求項６に記載のコンピュータプログラム。
8. 前記育成ゲームは、前記キャラクタおよび前記１または複数のサブキャラクタのいずれかがレッスンを受けるシミュレーションを行い、前記シミュレーションを行うごとに前記キャラクタおよび前記１または複数のサブキャラクタのうちの前記レッスンを受けたものの前記価値を向上させるゲームである、
   請求項６または請求項７に記載のコンピュータプログラム。
9. 前記育成ゲームにおいて、希少性の異なる複数の仮想のカードが前記キャラクタおよび前記１または複数のサブキャラクタのそれぞれに対して用意されており、
   前記キャラクタおよび前記１または複数のサブキャラクタそれぞれの前記価値は、前記プレーヤが前記複数の仮想のカードの中から前記キャラクタおよび前記１または複数のサブキャラクタそれぞれについて選択したものの前記希少性の高さである、
   請求項６または請求項７に記載のコンピュータプログラム。
10. 前記第二の表示処理手段は、前記１または複数のサブキャラクタとともに前記キャラクタが前記パフォーマンスを行う様子を表わす動画像を前記第二の動画像として表示させる、
    請求項６ないし請求項９のいずれかに記載のコンピュータプログラム。
11. 前記再生曲は、第一の部分を含み、かつ、前記第一の部分よりも後に第二の部分を含み、
    前記第二の表示処理手段は、前記第一の部分が再生されている間に前記第二の動画像を表示させ、
    前記第一の要件は、前記第二の部分が再生されている間における前記評価が一定以上である、という要件である、
    請求項３ないし請求項７のいずれかに記載のコンピュータプログラム。
12. 前記再生曲は、第一の部分を含み、前記第一の部分よりも後に第二の部分を含み、かつ、前記第二の部分よりも後に第三の部分を含み、
    前記第二の表示処理手段は、前記第一の部分が再生されている間に前記第二の動画像を表示させ、
    前記第一の要件は、前記第二の部分が再生されている間における前記評価が一定以上であり、かつ、前記第三の部分が再生されている間における前記評価が一定以上である、という要件である、
    請求項３ないし請求項７のいずれかに記載のコンピュータプログラム。
13. 前記音楽ゲーム手段は、前記音楽ゲームとして、発射源から第一のマークを発射し、前記発射源から所定の距離の位置にある第二のマークに前記第一のマークが到達したタイミングで前記プレーヤが前記アクションを行うと前記評価を上げるゲームを提供し、
    前記第一の表示処理手段は、前記発射源、前記第一のマーク、および前記第二のマークを表わす第三の動画像を前記第二の動画像に合成して前記ディスプレイに表示させる、
    請求項３ないし請求項１２のいずれかに記載のコンピュータプログラム。
14. 前記第一のマークは円形のマークであり、前記第二のマークは菱形または正方形のマークである、
    請求項１３に記載のコンピュータプログラム。
15. 前記音楽ゲーム手段は、前記第二の表示処理手段によって前記第二の動画像が表示されている間、前記第一のマークを発射するのを停止する、
    請求項１３または請求項１４に記載のコンピュータプログラム。
16. 前記音楽ゲーム手段は、複数の楽曲の中から前記再生曲として選択された楽曲のリズムに合わせて前記第二のマークに到達するように前記第一のマークを発射し、
    前記第一の表示処理手段は、前記再生曲に応じた動画像を前記第一の動画像として表示させ、
    前記第二の表示処理手段は、前記再生曲に応じた動画像を前記第二の動画像として表示させる、
    請求項１３ないし請求項１５のいずれかに記載のコンピュータプログラム。
17. 前記第二の表示処理手段は、前記育成ゲームにおいて仮想的に育成される複数のキャラクタの中から前記キャラクタとして選択されたものの特徴が表われた動画像を前記第二の動画像として表示させる、
    請求項１ないし請求項１５のいずれかに記載のコンピュータプログラム。
18. 再生される楽曲である再生曲に合わせてプレーヤがアクションを行う音楽ゲームを提供する音楽ゲーム手段と、
    育成ゲームにおいて仮想的に育成されるキャラクタがライブを行う様子を表わす第一の動画像を、前記音楽ゲーム手段によって前記音楽ゲームが提供されている間、ディスプレイに表示させる第一の表示処理手段と、
    前記音楽ゲームおよび前記育成ゲームそれぞれにおける状況に基づいて所定の要件が満たされるか否かを判別する判別手段と、
    前記キャラクタが特別なパフォーマンスを行う様子を表わす第二の動画像を、前記所定の要件が満たされると前記判別手段によって判別される場合に前記ディスプレイに表示させる第二の表示処理手段と、
    を有するゲームシステム。

Images