JP5579911B1 - 報酬付与プログラム及び報酬付与装置 - Google Patents

Abstract

【課題】プレイヤーに継続してイベントに参加させる。
【解決手段】次のイベントＢで利用するイベントＡの報酬（楽曲Ｂ）をプレイ結果に応じて配布時期をずらす。これにより、早く報酬を受け取ったプレイヤーは次回のイベントＢで有利になるので、プレイヤーが積極的にイベントに参加することを期待できる。
【選択図】図２３

Description

本発明は、所定のタイミングに合わせて操作を入力するゲームを実行するゲームプログラムに関する。

プレイヤーの操作タイミングを評価するゲームが知られている。例えば、特許文献１に記載のゲームは、２つの画像が重なったタイミングにおけるプレイヤーの操作を評価するゲームである。また、特許文献２に記載のゲームは、タッチパネルを備えたゲーム機で、音楽に合わせて表示されるタッチ画像に対するタッチ入力を評価するゲームである。

近年では、タッチパネルを備えたゲーム機が広く普及し、特許文献２に記載のゲームのように、ゲーム画面上に表示される画像に対して直接操作を入力するゲームが多くなっている。

プレイヤーがネットワークを介して他のプレイヤーと関係するソーシャルゲームでは、期間限定のイベントが繰り返し開催されることが多い。プレイヤーは、イベントに参加することでゲーム内で用いるアイテムなどを得ることができる。

特許第３６８６９２５号公報 特開２００７−１１１５６８号公報

ソーシャルゲームでは、継続してゲームをプレイするプレイヤーの総数が重要である。魅力的なイベントを開催することでゲームのプレイを継続するきっかけになる。 本発明は、上記に鑑みてなされたものであり、プレイヤーに継続的にイベントに参加させることを目的とする。

本発明に係る報酬付与プログラムは、各ゲーム装置からイベントに関するゲームのプレイ結果を受信するプレイ結果受信手段、前記プレイ結果を集計し、集計した結果に応じて前記各ゲーム装置に報酬を配布する時期を決めるプレイ結果集計手段、前記プレイ結果集計手段が決めた時期に前記報酬をプレイヤが使用できるように該当する前記ゲーム装置へ前記報酬に関する情報を付与する報酬付与手段、として機能させることを特徴とする。

本発明によれば、プレイヤーに継続的にイベントに参加させることができる。

本実施の形態におけるゲームプログラムが実行されるゲーム機の内部構成を示すブロック図である。 ゲーム画面の一例を示す図である。 時系列順にゲーム画面を示す図である。 本実施の形態におけるゲームプログラムによって構成されるゲーム装置の構成を示す機能ブロック図である。 上記ゲーム装置の全体的な処理の流れを示すフローチャートである。 ラインがゲーム画面の下側と右側から出現し、ラインの出現位置から仮想交点までの距離が異なる例を示す図である。 ラインの出現位置と仮想交点までの距離を等しくする例を示す図である。 判定処理の流れを示すフローチャートである。 操作内容を指示するアイコン等を表示したゲーム画面の例を示す図である。 タップ、フリック、ホールドの操作入力位置の適正範囲を示す図である。 フリック操作の判定を説明する図である。 フリック操作を連続して入力する様子を示す図である。 ライン、予兆画像のバリエーションを示す図である。 ラインの表示位置を移動させたゲーム画面を時系列順に示す図である。 仮想交点の位置を動かす様子を示す図である。 フリック・アンド・シュートのゲーム画面の例を示す図である。 フリック・アンド・シュートにおいて穴を表示したゲーム画面の例を示す図である。 アンロックチャレンジの流れを示すフローチャートである。 フレンドがアンロックチャレンジをサポートするときの処理の流れを示すシーケンス図である。 シェアソング機能を実現するゲームシステムの全体の構成を示す全体構成図である。 プレイヤーがシェアソングをプレイする流れを示すフローチャートである。 シェアソングをゲーム画面上に表示した例を示す図である。 イベントの報酬を配布する時期を説明する図である。

［第１の実施の形態］
以下、本発明の実施の形態について図面を用いて説明する。

図１は、本実施の形態におけるゲームプログラム１が実行されるゲーム機３の内部構成を示すブロック図である。

ゲーム機３は、バス３０に、ＣＰＵ３１、ＲＡＭ３２、ＲＯＭ３３、ストレージ３４、画像処理ユニット３５、入力インタフェース３６、音声処理ユニット３７、無線通信ユニット３８、およびメディアインタフェース３９を接続する。画像処理ユニット３５と入力インタフェース３６には、タッチパネル４０が接続される。タッチパネル４０は、画像処理ユニット３５により生成されるゲーム画面を表示するとともに、プレイヤーがタッチパネル４０に接触した接触座標を入力して入力インタフェース３６へ渡す。音声処理ユニット３７には、スピーカー４１が接続される。スピーカー４１は、音声処理ユニット３７によりアナログ信号に変換されて増幅された効果音やＢＧＭ等の音声を出力する。例えば、ゲーム機３として、タッチパネル４０を備えたスマートフォンなどが利用できる。

ゲーム機３は、無線通信ユニット３８あるいはメディアインタフェース３９からゲームプログラム１を受信してストレージ３４に格納する。ＣＰＵ３１がストレージ３４に格納されたゲームプログラム１をＲＡＭ３２上に読み出して実行し、上記のハードウェア資源を用いて後述するゲーム装置を構成する。ゲームプログラム１は、磁気ディスク、光ディスク、半導体メモリ等の記録媒体に記録することも、ネットワークを通して提供することも可能である。

＜ゲームについて＞
次に、本実施の形態におけるゲームプログラムによって提供されるゲームについて説明する。

操作対象のオブジェクトをゲーム画面上で移動させて、ゲーム画面上の様々な場所に対して操作を入力させるタイミングゲームの場合、プレイヤーはタイミングだけでなく、操作入力位置も判断しなければならない。そのため、オブジェクトを高速に移動させるとゲームの難易度が上がってしまう。一方、オブジェクトの移動速度が遅いとスピード感が失われてしまう。本実施の形態では、スピード感のあるタイミングゲームを提供する。

また、入力装置としてタッチパネルを用いた場合、ボタン操作とは違って、タップ（接指をゲーム画面に接触させる動作）の他にも、フリック（指で弾く動作）、ホールド（しばらく押し続ける動作）などの様々な操作を入力することができる。そこで本実施の形態では、様々な入力操作に対してより適した判定方法を提供する。

本ゲームは、ゲーム画面の端から出現する複数のラインの先端同士が衝突するタイミング（以下「ジャストタイミング」とする）におけるプレイヤーの操作を評価するタイミングゲームである。プレイヤーが、複数のラインの衝突タイミングで、ゲーム画面上のラインの衝突位置において、タップ、フリック、ホールドなどの操作を行うことでスコアが加算される。

図２に、ゲーム画面の一例を示す。同図に示すゲーム画面には、ライン５１Ａ，５１Ｂと予兆画像５２Ａ〜５２Ｃが表示されている。実際のゲーム画面には、スコアなどの情報も表示されるが、ここでは図示していない。また、ゲーム画面の背景として再生される音楽に合わせたプロモーションビデオを表示してもよい。

ライン５１Ａ，５１Ｂは、ゲーム機３から出力される音楽に合わせてゲーム画面の端から出現して伸び、ゲーム画面内の仮想交点５３で先端同士が衝突する。仮想交点５３はゲーム画面上には表示されない。

予兆画像５２Ａ〜５２Ｃは、ライン５１Ａ，５１Ｂの先端が互いに近接する予兆を示す画像であり、ライン５１Ａ，５１Ｂの出現前、あるいはライン５１Ａ，５１Ｂの出現と同時にゲーム画面内に表示され、動きなどの変化を伴ってライン５１Ａ，５１Ｂの大まかな衝突タイミングと仮想交点５３の位置をプレイヤーに示す。図２に示す例では、予兆画像５２Ａ〜５２Ｃとして、ライン５１Ａ，５１Ｂの進行方向を複数の折れ線で表した画像を用い、予兆画像５２Ａ〜５２Ｃの折れ点の進行方向で仮想交点５３の位置を示し、予兆画像５２Ａ〜５２Ｃ間の間隔の変化でライン５１Ａ，５１Ｂの衝突タイミングを示した。

ここで、ライン５１Ａ，５１Ｂと予兆画像５２Ａ〜５２Ｃの動きについて説明する。図３は、ライン５１Ａ，５１Ｂがゲーム画面内に出現して仮想交点５３に近接する様子を時系列順に示した図である。

図３（ａ）〜（ｃ）に示すように、ライン５１Ａ，５１Ｂは、ゲーム画面の上下端の左側から出現してゲーム画面中央付近の仮想交点５３に向かって伸びる。つまり、ライン５１Ａは右下方向に、ライン５１Ｂは右上方向に伸びる。

予兆画像５２Ａは、ライン５１Ａ，５１Ｂの出現より少し前に、ゲーム画面左側から出現して右側に移動する。別の予兆画像５２Ｂは、ライン５１Ａ，５１Ｂの出現と同時に、予兆画像５２Ａの後を追って、ゲーム画面左側から出現して右側に移動する。さらに別の予兆画像５２Ｃは、ライン５１Ａ，５１Ｂの出現後、予兆画像５２Ａ，５２Ｂの後を追って、ゲーム画面左側から出現して右側に移動する。

予兆画像５２Ａ〜５２Ｃそれぞれの移動速度は出現の遅いものほど速くなっている。したがって、図３（ａ）〜（ｃ）に示すように、予兆画像５２Ａ〜５２Ｃ間の間隔はライン５１Ａ，５１Ｂが仮想交点５３に近づくに連れて狭くなり、予兆画像５２Ａ〜５２Ｃは、時間が経過するとともに、波紋のように仮想交点５３に押し寄せ、ライン５１Ａ，５１Ｂが仮想交点５３で衝突するタイミングで重なる。このとき、予兆画像５２Ａ〜５２Ｃの折れ点は仮想交点５３で重なっている。

プレイヤーは、予兆画像５２Ａ〜５２Ｃを観察することで、ライン５１Ａ，５１Ｂの先端が衝突する大まかなタイミングと仮想交点５３の位置を推測することができる。

＜ゲーム装置＞
次に、本実施の形態におけるゲームプログラムがゲーム機３に読み込まれて構成されるゲーム装置について説明する。

図４は、本実施の形態におけるゲームプログラムによって構成されるゲーム装置の構成を示す機能ブロック図である。同図に示すゲーム装置は、操作入力部１１、予兆画像制御部１２、ライン制御部１３、タイミング判定部１４、スコア処理部１５、画像出力部１６、背景処理部１７、音声出力部１８、およびゲームデータ蓄積部１９を備える。

操作入力部１１は、プレイヤーの操作を入力する。プレイヤーは、ゲーム機３のタッチパネル４０に指などで接触することで操作を入力する。操作入力部１１は、ゲーム画面上の接触座標、操作の種類などの操作情報を取得してタイミング判定部１４へ送信する。

予兆画像制御部１２は、ライン５１Ａ，５１Ｂに対応する予兆画像５２Ａ〜５２Ｃをゲーム画面上に出現させるとともに、予兆画像５２Ａ〜５２Ｃの動きなどを制御し、予兆画像５２Ａ〜５２Ｃの位置情報などを画像出力部１６へ送信して、ゲーム画面上の予兆画像５２Ａ〜５２Ｃを更新させる。予兆画像５２Ａ〜５２Ｃの出現タイミング、および動きのデータなどはゲームデータ蓄積部１９から読み出す。

ライン制御部１３は、音声出力部１７から出力される音楽に合わせてライン５１Ａ，５１Ｂをゲーム画面上に出現させるとともに、ライン５１Ａ，５１Ｂの先端同士が衝突するように移動を制御し、ライン５１Ａ，５１Ｂの位置情報などを画像出力部１６へ送信して、ゲーム画面上のライン５１Ａ，５１Ｂを更新させる。また、ライン５１Ａ，５１Ｂの先端同士が衝突する位置である仮想交点５３の位置情報、ライン５１Ａ，５１Ｂの位置情報、およびライン５１Ａ，５１Ｂの先端が衝突するまでの時間などの近接情報をタイミング判定部１４へ送信する。ライン５１Ａ，５１Ｂの出現タイミング、伸びる速度などは、ゲームデータ蓄積部１９から読み出す。

タイミング判定部１４は、操作入力部１１から操作情報を受信するとともに、ライン制御部１３からライン５１Ａ，５１Ｂの先端の近接情報を受信し、適切なタイミングで適切な位置で操作が入力されたか否かを判定し、操作の成否をスコア処理部１５へ送信する。

スコア処理部１５は、タイミング判定部１４から受信した操作の成否に基づいてスコアの加算処理を行う。また、スコア処理部１５は、スコアなどのパラメータの値を画像出力部１６へ送信し、ゲーム画面に表示されている値を更新させる。

画像出力部１６は、ライン制御部１３からライン５１Ａ，５１Ｂの位置情報を受信してゲーム画面にライン５１Ａ，５１Ｂを表示するとともに、予兆画像制御部１２から予兆画像５２Ａ〜５２Ｃの位置情報を受信してゲーム画面に予兆画像５２Ａ〜５２Ｃを表示する。また、スコアなどのパラメータの値や背景画像などをゲーム画面に表示する。

背景処理部１７は、ライン５１Ａ，５１Ｂ、予兆画像５２Ａ〜５２Ｃの後ろに表示する背景画像をゲームデータ蓄積部１９から読み出して画像出力部１６に表示させる。

音声出力部１８は、ゲームデータ蓄積部１９から音楽データを取得して出力する。

ゲームデータ蓄積部１９は、ゲーム画面に表示する画像データ、再生する音楽や効果音などの音声データ、ライン出現データ、および予兆出現データなどを格納する。

ライン出現データは、仮想交点の位置、出現数、ラインの出現タイミング、出現位置、伸びる方向・速さなどの情報で構成される。仮想交点の位置はゲーム画面上の座標を表す。出現数は仮想交点で交差するラインの数を表す。出現タイミングは、音楽の再生を開始してからどのくらいの時間が経過したときにラインを出現させるのかをライン毎に記載したデータである。出現位置は、例えばゲーム画面のいずれかの角を原点としたときの座標をライン毎に記載したデータである。伸びる方向・速さは、ライン毎の伸びる方向及び速さを記載したデータである。ラインの伸びる速さは、ライン毎に異なってもよい。

予兆出現データは、ライン出現データに関連付けられており、予兆画像の出現タイミング、出現位置、移動速度、変化情報などの情報で構成される。出現タイミングは、音楽の再生を開始してからどのくらいの時間が経過したときにラインを出現させるのか、あるいは、ラインの出現タイミングから予兆画像の出現タイミングまでの相対時間を記載したデータである。出現位置は、予兆画像を出現させる位置を記載したデータである。移動速度は、予兆画像の移動速度を記載したデータである。変化情報は、例えば予兆画像の色を変化させる場合など、どのように変化させるのかを記載したデータである。

＜ゲームの流れ＞
次に、上記ゲーム装置の処理の流れについて説明する。

図５は、本ゲーム装置の全体的な処理の流れを示すフローチャートである。

ゲームが開始されると、初期化処理が行われる（ステップＳ１１）。初期化処理は、例えば、スコアのクリアなどパラメータの初期化や、再生する音楽と使用するライン出現データ、予兆出現データの選択などがある。プレイヤーが選択した音楽や難易度に応じて予め設定された音楽が再生する音楽として選択される。

初期化処理が終了すると、音声出力部１７が音楽の再生を開始する（ステップＳ１２）。

ライン制御部１３は、ゲームデータ蓄積部１９からライン出現データを読み出し、新たなライン５１Ａ，５１Ｂを出現させるか否か判定する（ステップＳ１３）。新たなライン５１Ａ，５１Ｂを出現させるか否かは、例えば、音楽の再生時間とライン出現データの出現タイミングとを比較して判定する。音楽の再生時間が出現タイミング以上になっていたときに、新たなライン５１Ａ，５１Ｂを出現させると判定する。

新たなライン５１Ａ，５１Ｂを出現させると判定した場合は、予兆画像５２Ａ〜５２Ｃ、ライン５１Ａ，５１Ｂをゲーム画面上に出現させる（ステップＳ１４）。ライン制御部１３は、ゲームデータ蓄積部１９から読みだしたライン出現データの出現位置にライン５１Ａ，５１Ｂを出現させ、予兆画像制御部１２は、ライン制御部１３が出現させたライン５１Ａ，５１Ｂに対応する予兆出現データをゲームデータ蓄積部１９から読み出し、予兆画像５２Ａ〜５２Ｃをゲーム画面上に出現させる。例えば、予兆画像５２Ａ〜５２Ｃはジャストタイミングの３拍前、ライン５１Ａ，５１Ｂはジャストタイミングの２拍前にゲーム画面内に出現させる。

所定の間隔（例えば６０ｆｐｓ間隔）で、ライン制御部１３がゲーム画面上のライン５１Ａ，５１Ｂを移動させ（ステップＳ１５）、予兆画像制御部１２が予兆画像５２Ａ〜５２Ｃを更新する（ステップＳ１６）。仮想交点５３からライン５１Ａ，５１Ｂそれぞれの出現位置までの距離が等しい場合は、ライン５１Ａ，５１Ｂの移動速度は同じである。仮想交点５３からライン５１Ａ，５１Ｂそれぞれの出現位置までの距離が互いに異なる場合はライン５１Ａ，５１Ｂの移動速度が異なる。

例えば、図６に示すように、ライン５１Ａがゲーム画面下から出現し、ライン５１Ｂがゲーム画面右側から出現した場合、ライン５１Ａの出現位置から仮想交点５３までの距離Ｌａはライン５１Ｂの出現位置から仮想交点５３までの距離Ｌｂよりも短いので、ライン５１Ａの移動速度Ｖａはライン５１Ｂの移動速度Ｖｂよりも遅くなる。なお、図６に示すように、仮想交点５３の位置からライン５１Ａ，５１Ｂが出現するゲーム画面の端までの距離が異なるときに、ライン５１Ａ，５１Ｂの移動速度を同じにする場合は、例えば、一方のラインの出現位置をゲーム画面の端ではなく、仮想交点５３から各ライン５１Ａ，５１Ｂの先端までの距離が同じ位置にライン５１Ａ，５１Ｂを出現させる。具体的には、図７（ａ）の例では、ライン５１Ａ，５１Ｂの出現時間であるジャストタイミングの２拍前に、ライン５１Ｂを、仮想交点５３からライン５１Ｂの先端までの距離がＬａとなる位置にＬｂ−Ｌａの長さで出現させて、ライン５１Ａ，５１Ｂを同じ移動速度Ｖａで移動させる。なお、ライン５１Ｂを、仮想交点５３からの距離がＬａとなる位置に、長さを０（ライン５１Ａと同じ長さ）で出現させてもよい。つまり、ライン５１Ｂはゲーム画面の端ではなくゲーム画面内から伸びる線となる。別の例としては、ライン５１Ａ，５１Ｂがゲーム画面内に出現するタイミングをずらす。具体的には、図７（ｂ）の例では、ライン５１Ａ，５１Ｂの出現時間であるジャストタイミングの２拍前に、ライン５１Ａを、ゲーム画面内には出現させずにゲーム画面外の仮想交点５３からライン５１Ａの先端までの距離がＬｂとなる位置に出現させて、ライン５１Ａ，５１Ｂを同じ移動速度Ｖｂで移動させる。ライン５１Ｂがある程度伸びて、ライン５１Ｂの先端から仮想交点５３までの距離が、仮想交点５３からライン５１Ａの出現位置であるゲーム画面の端までの距離と同じになるタイミングでライン５１Ａはゲーム画面内に出現する。ライン５１Ｂは通常通りジャストタイミングの２拍前にゲーム画面内に出現し、ライン５１Ａはジャストタイミングの１拍前にゲーム画面内に出現する。なお、上記では、仮想交点５３の位置から出現位置であるゲーム画面の端までが異なる場合にラインの出現位置や出現タイミングをずらす例について説明したが、仮想交点５３から出現位置までの距離が同じ場合であっても、ゲームの難易度をあげるため、マンネリ化を防ぐために、ラインの出現位置や出現タイミングをずらしてもよい。

そして、タイミング判定部１４は、プレイヤーによる操作に対する判定処理を行う（ステップＳ１７）。判定処理の詳細については後述する。

さらに、ゲームの終了条件を満たしているか否か判定する（ステップＳ１８）。ゲームの終了条件は、例えば音楽の再生が終了した場合はゲームクリアと判定し、判定処理でミスと判定された回数が所定の値を超えた場合はゲームオーバーと判定する。ゲームの終了条件を満たしていない場合は、ステップＳ１３に戻り、ゲームを継続する。

ゲームの終了条件を満たしている場合は、ゲームクリアした旨あるいはゲームオーバーになった旨をゲーム画面に表示してゲームを終了する（ステップＳ１９）。ゲーム終了後は、ゲームクリアの場合はステップＳ１１に戻って新たにゲームを開始し、ゲームオーバーの場合はタイトルに戻る。

＜判定処理＞
続いて、判定処理について説明する。判定処理では、ラインの先端同士が衝突するタイミングでゲーム画面上のラインの衝突位置に対して操作が入力されたか否かを判定する。

図８は、判定処理の流れを示すフローチャートである。

まず、タップ、フリック、ホールドの操作が入力されたか否か判定する（ステップＳ２１）。

操作が入力された場合（ステップＳ２１のＹｅｓ）、ゲーム画面上の操作入力座標を取得し（ステップＳ２２）、操作入力位置が適正範囲内であるか否か判定する（ステップＳ２３）。操作入力位置が適正範囲内であるか否かは、操作入力座標とラインの先端同士が衝突する位置を示す仮想交点５３とを比較して判定する。

操作入力座標が仮想交点５３から所定の範囲内である場合（ステップＳ２３のＹｅｓ）、入力された操作内容が適切か否か判定する（ステップＳ２４）。プレイヤは、ゲーム画面の表示により入力すべき操作を認識できる。

例えば、図９（ａ）に示すように、仮想交点上にフリックの方向を示すアイコン５４が表示されている場合は、アイコン５４の方向にフリックすべきことを示す。アイコン５４を表示するタイミングは、ラインの出現と同時（２拍前）でもよいし、予兆画像の出現と同時（３拍前）でもよく、また、操作の直前（例えば１拍前）でもよい。フリックの方向を示すアイコン５４中の矢印は固定ではなく、ラインが衝突するまで回転させて操作の直前までフリックの方向を分からなくさせてもよい。この場合、ラインが衝突するタイミングにおけるアイコン５４の向きにフリックすると成功と判定される。

また、図９（ｂ）に示すように、４つのライン５１Ａ〜５１Ｄが衝突する場合はホールドすべきことを示す。ラインの色や形状を変更してホールドすべきことを示してもよいし、ホールドを示すアイコンを仮想交点５３の位置に表示してもよい。ホールドの時間は、ライン５１Ａ〜５１Ｄが消滅するまでである。ライン５１Ａ〜５１Ｄを消滅させる方法としては、例えば、ライン５１Ａ〜５１Ｄを、仮想交点５３に集まるように徐々に短くして消滅させてもよいし、ライン５１Ａ〜５１Ｄの太さを細くして消滅させてもよい。あるいは、ライン５１Ａ〜５１Ｄの透明度を徐々に高くして消滅させてもよいし、ライン５１Ａ〜５１Ｄの長さ、太さや色などを変化させずに所定のタイミングで消滅させてもよい。

操作内容が適切である場合（ステップＳ２４のＹｅｓ）、操作のタイミングを判定する（ステップＳ２５）。操作のタイミングは、ライン５１Ａ，５１Ｂの先端が衝突するジャストタイミングと操作のタイミングの時間差を求めて判定する。例えば、ジャストタイミングの判定幅を２フレームとし、ジャストタイミング前後の数フレームから数十フレームの間を適正範囲とする。適正範囲の幅はゲームの難易度の設定による。難易度を低くする場合は適正範囲を広くし、難易度を高くする場合は適正範囲を狭くする。また、プレイしている曲のテンポに合わせて適正範囲を変更してもよい。例えば、テンポの速い曲は適正範囲を狭くし、テンポの遅い曲は適正範囲を広くする。いずれの場合もジャストタイミングの判定幅は２フレームのままとする。

操作位置、操作内容、操作タイミングの全てが適切な場合はスコアを加算し（ステップＳ２６）、ライン５１Ａ，５１Ｂをゲーム画面上から削除する（ステップＳ２７）。操作のタイミングがジャストタイミングの場合は最大のスコアを加算し、それ以外の場合は、より少ないスコアを加算する。また、操作位置が衝突位置に近いほど加算するスコアを多くする。

一方、操作が入力されてない場合（ステップＳ２１のＮｏ）、操作入力位置が適正範囲外の場合（ステップＳ２３のＮｏ）、および操作内容が適切でない場合は（ステップＳ２４のＮｏ）、操作のタイミングを逃したか否か判定する（ステップＳ２８）。ライン５１Ａ，５１Ｂの先端が衝突後、所定の時間経過していた場合つまり操作のタイミングの適正範囲を超えた場合はミスと判定し（ステップＳ２８のＹｅｓ）、ミスの処理を行って（ステップＳ２９）、操作入力を逃したライン５１Ａ，５１Ｂをゲーム画面上から削除する（ステップＳ２６）。

ここで、操作入力位置の判定についてより詳しく説明する。図１０（ａ）〜（ｃ）に、タップ、フリック、ホールドそれぞれの操作入力位置の適正範囲５５を示す。タップとホールドの適正範囲５５は、仮想交点５３を中心とした円である（図１０（ａ）及び（ｃ））。フリックの適正範囲５５は、フリックを示すアイコン５４を中心とし、フリック方向に広がった楕円である（図１０（ｂ））。楕円の長軸の長さはタップ、ホールドの適正範囲５５の円の直径よりも長くする。楕円の短軸の長さはタップ、ホールドの適正範囲５５の円の直径と同じか短くする。なお、適正範囲５５をフリック方向に長い長方形などの形状にしてもよい。

タップ操作の判定は、タップされた位置が適正範囲５５内であるか否かを判定する。

ホールド操作の判定は、まずホールド開始位置が適正範囲５５内であるか否かを判定し、ホールド中はホールド位置が適正範囲５５内であるか否かを判定する。ホールド位置が適正範囲５５外に外れた場合はミスとする。ホールド操作時間内（ゲーム画面を押し続ける時間）にホールド終了（指が離れた）した場合はミスとする。また、ホールド操作の判定については、ホールド開始位置が適正範囲５５内であるか否か及びホールド操作時間のみを判定し、ゲーム画面から指を離さない限り、つまりホールド位置を移動させてもミスとしなくてもよい。この場合、ホールド中にプレイヤーが次に操作入力すべきラインがゲーム画面内に出現し、プレイヤー自身の指が邪魔でラインの動きが見えにくいときでも、ホールド位置を移動させてラインの動きを確認できる。あるいは、ホールド位置の判定については、ホールド開始時及びホールド終了時において適正範囲５５内であれば、ホールド操作時間中に適正範囲５５外をホールドした場合でもホールド操作成功と判定してもよい。

別の実施例として、ホールド操作の適正範囲５５をホールド開始後に広げたり、あるいは狭くしてもよいし、適正範囲５５の形状を円から別の形状に変化させてもよい。さらに、適正範囲５５を移動させてもよい。移動する適正範囲５５にホールド位置を追従させることができなかった場合はミスと判定する。具体的には、ホールド開始後、所定の目印オブジェクトをゲーム画面内に表示して移動させ、目印オブジェクトの移動に合わせて適正範囲５５を移動させる。プレイヤーは、ホールドした指をゲーム画面から離さず、目印オブジェクトを追うように（指を適正範囲５５内に維持するように）移動させる。

フリック操作の判定は、まずフリックの始点が適正範囲５５内であるか否かを判定し、その後フリックの終点を求め、フリックの始点から終点の方向がフリックで指示された方向であるか否かを判定する。本実施例では、図１１に示すように、フリックの適正範囲５５を後部分５５Ａ、前部分５５Ｂに分け、フリックの始点が後部分５５Ａの場合は、押下位置が適正範囲５５の中心線５５Ｃを超えた位置をフリックの終点とし、フリックの始点が前部分５５Ｂの場合は、押下位置が適正範囲５５を超えた位置をフリックの終点とする。また、中心線５５Ｃあるいは適正範囲５５を超えずに指がゲーム画面から離れた場合は、指が離れた位置をフリックの終点とする。終点が決まると、フリックの始点から終点の方向とフリックで指示された方向の開きが所定の角度内（例えば３０度以内）であればフリックの方向は正しいと判定する。押下位置が中心線５５Ｃあるいは適正範囲５５を超えた位置をフリックの終点とすることで、指をゲーム画面から離さなくてもフリック操作と判定される。その結果、図１２に示すように、同じ方向へのフリック操作が連続して出現する場合、一つ一つフリック操作を入力する代わりに、指をフリックの方向へスライドさせても正しい操作が入力されたと判定される。図１２の例では、下のアイコンから順次フリック操作の判定が行われる。押下位置が中心線あるいは適正範囲を超えてフリックが判定されたときには、次のアイコンの適正範囲内が押下されている。そのため、指をスライドさせても続けてフリックの判定が行われる。

なお、フリック操作の適正範囲５５についても、フリック開始後（フリックの始点を認識後）に広げたり、あるいは狭くしてもよいし、形状を変化させてもよい。適正範囲５５の形状を変化させる例としては、最初はタップ、ホールドと同様に円形の適正範囲５５を設定し、フリック開始後にフリック方向に広がる楕円、扇型、三角形などに変化させる。適正範囲５５を扇型や三角形に変化させるときは、フリックの始点に扇型や三角形の角を合わせ、フリック方向に広がるように扇型や三角形を設定する。例えば、フリックの始点の角の角度を６０度とし、その角の中心を通る線がフリック方向となるように扇型や三角形の適正範囲５５を設定する。フリックの始点に置いた角に対向する円弧や辺を超えて指をスライドさせた場合はフリック成功と判定する。フリックの始点に置いた角を挟む２辺を超えて指をスライドさせた場合はフリックの方向が誤りと判定する。

＜変形例＞
次に、ライン、予兆画像のバリエーションについて説明する。

図１３は、ライン、予兆画像のバリエーションを示す図である。以下、図１３に示した各バリエーションについて説明する。

図１３（ａ）は、複数組みのラインが同時に出現する例を示す図である。図１３（ａ）に示す例では、それぞれ別々の仮想交点５３Ａ，５３Ｂで衝突する複数組みのライン５１Ａ〜５１Ｄが同時にゲーム画面上に出現する。図１３（ａ）に示す例の場合、プレイヤーは、仮想交点５３Ａ，５３Ｂの順にタップする。複数組みのラインが同時にゲーム画面内に存在すると操作を入力する順番及び互いに衝突するラインの組みがわかりにくくなる。そこで、ラインが衝突する直前（例えば１拍前）にラインの先端を大きくしたり、色を変えたり、形を変化させたり、回転させたりなどのエフェクトを表示したり動きを加えたりすることで、操作を入力する順番及び互いに衝突するラインの組みを分かりやすくしてもよい。また、衝突するライン同士を分かりやすくするために、衝突するラインの組み毎に色を変えたり、形を異ならせてもよい。さらに、ラインの先端の形状を異ならせてもよいし、予兆画像を衝突する組み毎に変えるものでもよい。

図１３（ｂ）は、ライン５１Ａ，５１Ｂが消えたり現れたりする例を示す図である。図１３（ｂ）に示す例では、ライン５１Ａ，５１Ｂが伸びるときに、仮想交点５３の直前までライン５１Ａ，５１Ｂを一時的に非表示とする。あるいは、ライン５１Ａ，５１Ｂの一部を非表示とする。ライン５１Ａ，５１Ｂを非表示としたとき、予兆画像も非表示としてもよいし、予兆画像だけを表示してもよい。

図１３（ｃ）は、色の変化でラインの衝突を予兆させる例を示す図である。同図に示す例では、ライン５１Ａ，５１Ｂの衝突時にライン５１Ａ，５１Ｂによって区切られる部分に色が変化する予兆画像５２（図１３（ｃ）では５角形）を配置した。予兆画像５２は、ライン５１Ａ，５１Ｂの伸びに応じて色が変化する。例えば、予兆画像５２の色を出現時には他の部分との区別が無いように黒あるいは透明とし、徐々に赤くあるいは透明度を減少させていく。プレイヤーは、予兆画像５２の色の濃さ、透明度でライン５１Ａ，５１Ｂが衝突する大まかなタイミングを知り、予兆画像５２の形状でライン５１Ａ，５１Ｂの伸びる方向と仮想交点５３の位置を知ることができる。

図１３（ｄ）は、線の太さの変化でラインの衝突を予兆させる例を示す図である。同図に示す例では、ライン５１Ａ，５１Ｂと仮想交点５３を含む太い線を予兆画像５２とした。予兆画像５２は、ライン５１Ａ，５１Ｂが接近するのに伴って細くなっていく。プレイヤーは、予兆画像５２の太さの変化でライン５１Ａ，５１Ｂが衝突する大まかなタイミングを知り、予兆画像５２の位置でライン５１Ａ，５１Ｂの伸びる方向、仮想交点５３の大まかな位置を知ることができる。

なお、予兆画像の色、透明度、太さなどをコンフィグメニューなどでユーザが任意に指定できるようにしてもよい。

図示していないが、タッチした場所から一定範囲内のどこかに自動で仮想交点が発生し、その仮想交点に向かうラインが出現するようにしてもよい。これは、複数人で行う場合にも適用でき、課題（ライン）を与える側とその課題をプレイする側に分かれてゲーム進行する。第１プレイヤが自身の第１ゲーム装置の画面の所定位置をタップすると、その課題情報を第２プレイヤが操作する第２ゲーム装置に送信し、その情報を受けた第２ゲーム装置の表示画面に、第１プレイヤがタップした位置またはその近辺を仮想交点とするラインを表示する。第２プレイヤはそのラインに対して操作することでゲームを進行する。

＜ラインの奥行方向の移動＞
これまでに説明した実施例では、ラインはラインの伸びる方向にのみ移動し、ラインの伸びる方向以外の方向には移動しなかった。ここでは、ラインをラインの伸びる方向以外に移動させてラインが奥行方向に移動しているように見せる実施例について説明する。

図１４は、ラインの表示位置を移動させたゲーム画面を（ａ）〜（ｃ）の順で時系列順に示す図である。図１４に示す実施例では、遠近法を用いた奥行き感のある背景に重ねてライン５１Ａ，５１Ｂ、予兆画像５２Ａ，５２Ｂを表示し、ライン５１Ａ，５１Ｂが奥から手前（奥行方向）に移動しているように、ライン５１Ａ，５１Ｂの表示位置を移動させた。

ゲーム画面の背景として、ゲーム画面中央に設定した消失点５６から放射状に広がる線で床５８Ａ、天井５８Ｂを表現し、奥行き感を出した。床５８Ａの両サイドには、再生する音楽の音量を示すレベルメータ５８Ｃを配置した。１フレーム毎に床５８Ａ、天井５８Ｂおよびレベルメータ５８Ｃのゲーム画面上の表示位置を手前に向けて移動させ、プレイヤーが消失点５６へ向かって移動しているように感じさせる。具体的には、ゲーム画面上で消失点５６から離れるように、床５８Ａの横線を下方向に、天井５８Ｂの横線を上方向に、左右のレベルメータ５８Ｃを左右下方向に移動させる。床５８Ａ、天井５８Ｂ、レベルメータ５８Ｃなどの背景画像の移動速度は、再生する音楽のテンポ（ＢＰＭ）に合わせる。なお、床５８Ａ、天井５８Ｂ、およびレベルメータ５８Ｃは、奥行き感及びスピード感を出すための背景であり、プレイヤーの操作には関係しない。床５８Ａ、天井５８Ｂ、およびレベルメータ５８Ｃを消失点５６から離れるように移動させて表示することで背景が奥行方向に移動するように表示されてスピード感が生まれる。

ライン５１Ａ，５１Ｂは、奥行き感を出した背景の上に重ねて表示し、ライン５１Ａ，５１Ｂの表示位置が消失点５６から離れるように移動させる。具体的には、図１４（ａ）〜（ｃ）に示すように、ゲーム画面上で消失点５６より上に表示されている横方向に伸びるライン５１Ａを経過時間に合わせて上方向に移動させ、消失点５６より右に表示されている縦方向に伸びるライン５１Ｂを経過時間に合わせて右方向に移動させる。ライン５１Ａ，５１Ｂのサイズ（太さ）も経過時間に合わせて大きく（太く）する。

予兆画像５２Ａ，５２Ｂは、ライン５１Ａ，５１Ｂの最終的な衝突位置である衝突予定位置５７ではなく、現在の表示位置でライン５１Ａ，５１Ｂを伸ばした先の仮想交点５３を示すように表示される。図１４に示す例では、ライン５１Ａ，５１Ｂの長手方向に伸びる帯状の予兆画像５２Ａ，５２Ｂを表示した。２つの帯状の予兆画像５２Ａ，５２Ｂの交点が仮想交点５３に対応する。

次に、ライン５１Ａ，５１Ｂ、予兆画像５２Ａ，５２Ｂの表示位置を計算する処理について説明する。

ライン５１Ａ，５１Ｂの表示位置は、時間の経過に伴って消失点５６から最終的な衝突位置である衝突予定位置５７に移動する仮想交点５３の位置に基いて決定する。仮想交点５３の位置は、消失点５６と衝突予定位置５７を結ぶ線上で経過時間に合わせて補間して決定する。

図１５に、仮想交点５３の位置を動かす様子を示す。同図に示す例では、消失点５６から衝突予定位置５７までを仮想交点５３が１小節で移動するとし、予兆画像５２Ａ，５２Ｂをジャストタイミングの３拍前、ライン５１Ａ，５１Ｂをジャストタイミングの２拍前に出現させるとした。

ジャストタイミングから３拍前、つまり予兆画像５２Ａ，５２Ｂを出現させるタイミングになると、図１５（ａ）に示すように、仮想交点５３を衝突予定位置５７から消失点５６までの３／４の位置Ｐに配置し、仮想交点５３を基準にして予兆画像５２Ａ，５２Ｂを表示する。具体的には、仮想交点５３からライン５１Ａ，５１Ｂが出現する辺まで帯状の予兆画像５２Ａ，５２Ｂを表示する。

時間の経過に伴って仮想交点５３を線分上を衝突予定位置５７へ向けて移動させるとともに、予兆画像５２Ａ，５２Ｂの表示位置も仮想交点５３の位置に合わせて補正し、移動させる。

そして、ジャストタイミングから２拍前、つまりライン５１Ａ，５１Ｂを出現させるタイミングになると、図１５（ｂ）に示すように、仮想交点５３は衝突予定位置５７から消失点５６までの半分の位置Ｑまで移動しており、仮想交点５３を基準にして予兆画像５２Ａ，５２Ｂを表示するとともに、仮想交点５３を基準にしてライン５１Ａ，５１Ｂを出現させる。具体的には、仮想交点５３の縦の位置に合わせてライン５１Ａをゲーム画面の左端に出現させるとともに、仮想交点５３の横の位置に合わせてライン５１Ｂをゲーム画面の下辺に出現させる。

その後、ライン５１Ａ，５１Ｂを伸ばすとともに、仮想交点５３を衝突予定位置５７へ向けて移動させ、仮想交点５３の位置に合わせてライン５１Ａ，５１Ｂ及び予兆画像５２Ａ，５２Ｂの表示位置を補正して移動させる。ジャストタイミングになると、仮想交点５３は衝突予定位置５７に到達し、ライン５１Ａ，５１Ｂの先端同士が衝突予定位置５７で衝突する。ゲーム画面上のライン５１Ａ，５１Ｂの衝突位置をジャストタイミングでタップすることでスコアが加算される。ゲーム画面上をタップした位置と衝突位置、タップしたタイミングとジャストタイミングとを比較し、タップした位置と衝突位置とのずれ、タップしたタイミングとジャストタイミングとのずれが所定の範囲内であれば成功、所定の範囲外であれば失敗と判定する。

なお、ゲームの設定でライン５１Ａ，５１Ｂの移動速度を速くする場合は、例えば、予兆画像５２Ａ，５２Ｂの出現タイミングをジャストタイミングから２拍前、ライン５１Ａ，５１Ｂの出現タイミングをジャストタイミングから１拍前とする。ライン５１Ａ，５１Ｂの移動速度を遅くする場合は、予兆画像５２Ａ，５２Ｂの出現タイミングをジャストタイミングから４拍前、ライン５１Ａ，５１Ｂの出現タイミングをジャストタイミングから３拍前とする。

また、予兆画像５２Ａ，５２Ｂを表示させない設定を追加してもよい。予兆画像５２Ａ，５２Ｂを表示せずに、ライン５１Ａ，５１Ｂの表示位置が移動する場合、プレイヤーにとってライン５１Ａ，５１Ｂの衝突位置が把握しにくくなり、ゲームの難易度を上げることができる。

＜フリック・アンド・シュート＞
次に、フリック・アンド・シュートについて説明する。従来のタイミングゲームにおいては、指定されたタイミングで操作入力するだけで、ゲームが単調になることがある。本実施の形態では、操作入力後に演出を加えることで、よりエンターテイメント性を高めたゲームプログラムを提供する。

フリック・アンド・シュートは、図１６（ａ）に示すように、フリック操作が要求されたときにプレイヤーがフリック操作を成功させた場合、操作位置からフリックした方向に移動する光のオブジェクト６１を出現させる機能である。

光のオブジェクト６１の利用例としては、図１６（ｂ）に示すように、光のオブジェクト６１がゲーム画面の端で跳ね返ってライン５１Ｄに変化するとともに、ライン５１Ｃを出現させて、新たなライン５１Ｃ，５１Ｄの衝突に対する操作を要求する例がある。プレイヤーが、図１６（ａ）においてフリック操作に失敗した場合は、光のオブジェクト６１が出現しないので、図１６（ｂ）においてライン５１Ｄが出現せずにライン５１Ｃのみが出現する状態となり、ライン５１Ｃ，５１Ｄの衝突に対する操作が入力できずミスとなる。光のオブジェクト６１が変化したライン５１Ｃとライン５１Ｄの衝突に対する操作に成功した場合は、通常時よりもプレイヤーに有利となる特典を付与してもよい。例えば、高得点を付与したり、所定のアイテムを付与したり、適正範囲５５が一定時間広くなる効果やゲーム進行のスピードが一定時間スローになる効果などである。逆に、光のオブジェクト６１が変化したライン５１Ｃとライン５１Ｄの衝突に対する操作に失敗した場合（フリック操作失敗も含む）、プレイヤーに不利となる効果を発生させてもよい。例えば、得点を減点したり、適正範囲５５を一定時間狭くしたり、ゲーム進行のスピードが一定時間速くなるなどである。また、光のオブジェクト６１を出現させるときに、任意の方向にフリックできるようにしてもよい。この場合、光のオブジェクト６１がゲーム画面の端で跳ね返る方向を計算して光のオブジェクト６１が変化するライン５１Ｃとライン５１Ｃに衝突するライン５１Ｄの組みを出現させる。具体的には、光のオブジェクト６１のゲーム画面の端に対する入射角と反射角が等しくなるようにライン５１Ｃの移動方向を決めるとともに、ライン５１Ｃに衝突するようにライン５１Ｄの出現位置と移動方向を決める。

別の利用例としては、図１７に示すように、ゲーム画面上に穴６２を出現させ、フリック操作により出現した光のオブジェクト６１が穴６２に入ったときに、ボーナススコアを加算するなどプレイヤーに有利となる特典を与える。光のオブジェクト６１はゲーム画面の端で反射し、出現から所定時間経過した後に消滅する。光のオブジェクト６１の移動速度は一定としてもよいし、フリック操作に応じた速さにしてもよい。穴６２の出現タイミングは、ラインがゲーム画面内に出現したとき、ジャストタイミングの前、ジャストタイミングのとき、フリック操作後などがある。なお、ラインの衝突位置にフリックを示すアイコン５４を表示する代わりにゲーム画面上に穴６２を出現させることで、プレイヤーにフリック操作を要求してもよい。つまり、ゲーム画面上に穴６２が出現した場合は、プレイヤーはフリック操作を行って光のオブジェクト６１を穴６２に入れなければならない。アイコン５４を表示しない場合はフリックする方向についてミスの判定を行わない。また、ホールド操作のときにも穴６２を出現させてホールド操作後にフリック操作を要求し、フリック操作に応じて光のオブジェクト６１を出現させてもよい。

以上説明したように、本実施の形態によれば、ライン５１Ａ，５１Ｂの先端が衝突するタイミングで衝突した位置をタップするタイミングゲームにおいて、ライン５１Ａ，５１Ｂに対応して表示される、ライン５１Ａ，５１Ｂの先端が互いに近接する予兆を示す予兆画像５２Ａ〜５２Ｃを表示することで、プレイヤーは、予兆画像５２Ａ〜５２Ｃによりライン５１Ａ，５１Ｂの先端の衝突位置、衝突タイミングを推測できるので、ライン５１Ａ，５１Ｂを高速に移動させてゲームにスピード感を出すことができる。また、予兆画像５２Ａ〜５２Ｃによりゲーム画面をダイナミックに変化させることができる。

本実施の形態によれば、ライン５１Ａ，５１Ｂそれぞれの出現位置と仮想交点５３の距離に応じてライン５１Ａ，５１Ｂそれぞれの移動速度を異ならせたり、ライン５１Ａ，５１Ｂそれぞれの出現タイミングを異ならせて移動速度を同じにすることで、より趣向性の高いタイミングゲームを提供することができる。

本実施の形態によれば、ラインの出現数やアイコンなどによりプレイヤーに操作内容を提示するとともに、提示した操作内容に応じて操作位置の判定基準である適正範囲５５を変化させることで、より趣向性の高いタイミングゲームを提供することができる。

本実施の形態によれば、フリック操作後に光のオブジェクト６１を出現させ、さらに光のオブジェクト６１が近接した場合に所定の効果を発生するライン５１Ｄや穴６２を出現させることにより、変化に富んだゲームを提供することができる。

［第２の実施の形態］
近年、ゲームプログラム本体は無料でゲーム内で利用するアイテムに対して課金する基本プレイ無料（Ｆｒｅｅ ｔｏ Ｐｌａｙ）方式が広まっている。例えばリズムアクションゲームでは楽曲に対して課金することで新たな楽曲をプレイできるようになる。

しかしながら、ゲーム内のアイテムに対する課金に抵抗のあるプレイヤーも多く存在する。課金しないプレイヤーは新たにプレイできる楽曲が増えないため、ゲームをプレイすること自体をやめてしまうことがある。ネットワークを通じて他のプレイヤーと競ったり、協力するソーシャルゲームでは、継続してゲームをプレイするプレイヤーの総数が重要である。

そこで、本実施の形態では、課金することなく楽曲（ゲームデータ）を入手することはできるが、課金したプレイヤーはより有利に楽曲を入手できる方法について説明する。

＜アンロックチャレンジ＞
アンロックチャレンジは、プレイヤーが新たな楽曲を入手するゲームモードの一つである。

本ゲームでプレイする楽曲には「解禁」「ロック状態」「未出現」の３つの状態がある。「解禁」された楽曲は、プレイヤーが自由に選択してプレイすることができる。「ロック状態」の楽曲は、プレイヤーは存在を知っている（ゲーム機内にゲームデータが保存されている）が自由にプレイすることができない楽曲である。「未出現」の楽曲は、プレイヤーが存在を知らない（ゲーム機内にゲームデータが無い）楽曲である。「解禁」された楽曲は、後述するチケットを消費することでプレイヤーは自由にプレイすることができる。「ロック状態」の楽曲は「解禁」された楽曲と同じ条件（例えばチケットの消費）ではプレイできない。「ロック状態」の楽曲の入手方法としては、例えばイベントなどで楽曲を「ロック状態」として配布される。プレイヤーは、「ロック状態」の楽曲に対してアンロックチャレンジを行い、アンロックチャレンジの結果に応じてその楽曲を「解禁」の状態にすることができる。

アンロックチャレンジは、アンロックチャレンジゲージが所定の値を超えたときに発動可能である。アンロックチャレンジゲージは、プレイヤーが楽曲（「解禁」された楽曲など）をプレイしたり、所定条件（例えば連続ログイン日数など）に応じて獲得することで蓄積される。本実施例では、楽曲をプレイするためにはチケットが必要である。チケットは所定時間（例えば数分）経過する度に所定の枚数まで１枚づつ増加する。チケットは経過時間に応じて増加するので無課金で楽曲をプレイすることが可能であるが、チケットを全て消費した場合にはチケットが貯まるまで楽曲をプレイすることができない。課金によりチケットを購入することで、チケットがプレイに必要な枚数まで増加するのを待つ必要がなくなる。課金してチケットを購入したプレイヤーは、無課金のプレイヤーよりも多くの回数をプレイできるので、アンロックチャレンジゲージが貯まりやすくなる。なお、チケットの消費量はプレイする楽曲あるいは難易度に応じて変化させてもよい。また、楽曲を途中からリトライする場合は通常の消費量より少ない枚数でプレイできる。チケットの消費量は楽曲の進行度に応じて変化させる。決められた複数の楽曲を連続してプレイするコースモードでは、コースの途中で失敗した場合は、チケットをさらに消費することでリトライすることが可能となる。

図１８は、アンロックチャレンジの流れを示すフローチャートである。

プレイヤーがアンロックチャレンジ対象の楽曲を指定すると、アンロックチャレンジゲージを消費し、アンロックポイントをクリアし、アンロックチャレンジタイマーを設定してアンロックチャレンジを開始する（ステップＳ３１）。ゲーム機は、各楽曲の状態を取得してアンロックチャレンジが可能な楽曲を選択し、アンロックチャレンジ対象候補としてプレイヤーに提示する。各楽曲の状態は、ゲームデータ蓄積部１９から取得する、あるいはネットワークを介してサーバから取得する。サーバはプレイヤー毎に各楽曲の状態を保持する。ゲーム機は「ロック状態」の楽曲をアンロックチャレンジ対象候補とする。アンロックチャレンジタイマーは、アンロックチャレンジの制限時間（例えば２０分）であり、アンロックチャレンジタイマーが満了するまでに所定のアンロックポイントを獲得すると楽曲が「解禁」される。アンロックチャレンジゲージ、アンロックポイント、およびアンロックチャレンジタイマーはサーバで管理される。

アンロックチャレンジが開始されると、プレイヤーはクリア条件を選択し（ステップＳ３２）、アンロックチャレンジ対象の楽曲でプレイを開始する（ステップＳ３３）。クリア条件はプレイの成否を判定する条件で、クリア条件にはアンロックポイントが関連付けられてサーバで管理される。難易度の高いクリア条件には多くのアンロックポイントが設定される。クリア条件としては、例えばプレイの結果であるランクＳ，Ａ，Ｂ，・・（Ｓが最高）を達成するという条件である。プレイヤーは自分の腕前に合わせてクリア条件を選択し、ゲームをプレイする。

ゲームが終了すると、クリア条件を満たしたか否か判定する（ステップＳ３４）。ゲーム機は、アンロックチャレンジ対象の楽曲のプレイ結果をサーバに送信し、サーバは、プレイ結果とプレイヤーが選択したクリア条件とを比較して成否を判定する。例えば、プレイヤーがランクＳをクリア条件として選択した場合、プレイの結果がランクＳであればクリア条件を満たしたと判定する。

クリア条件を満たした場合（ステップＳ３４のＹＥＳ）、クリア条件に設定されたアンロックポイントを獲得する(ステップＳ３５)。サーバは、プレイヤー毎にアンロックポイントを管理しており、獲得したアンロックポイントを該当プレイヤーがこれまでに獲得したアンロックポイントに加算する。

そして、アンロックポイントの合計が基準に達したか否か判定する（ステップＳ３６）。

アンロックポイントの合計が基準に達した場合は（ステップＳ３６のＹＥＳ）、アンロックチャレンジ対象の楽曲の状態を「解禁」に設定する（ステップＳ３７）。サーバが楽曲の状態を管理している場合は、サーバのデータを変更し、ゲーム機に楽曲の状態を変更した旨を通知する。

一方、クリア条件を満たしていない場合（ステップＳ３４のＮＯ）、およびアンロックポイントの合計が基準に達していない場合は（ステップＳ３６のＹＥＳ）、アンロックチャレンジタイマーが満了した否かを判定し（ステップＳ３８）、アンロックチャレンジタイマーが満了した場合は（ステップＳ３８のＹＥＳ）、アンロックチャレンジは失敗となる（ステップＳ３９）。アンロックチャレンジが失敗した場合は、蓄積されたアンロックポイントを０にクリアする。

アンロックチャレンジタイマーが満了していない場合は（ステップＳ３８のＮＯ）、ステップＳ３２に戻り、プレイヤーにクリア条件を再度選択させてアンロックチャレンジを続ける。プレイヤーにアンロックチャレンジを続けさせる際に、アンロックポイントの合計に応じて表示される範囲を変えた楽曲のジャケット画像を表示することでプレイモチベーションを高く保つ。例えば、ジャケット画像を１６分割しておき、アンロックポイントの基準に対する獲得したアンロックポイントの合計の割合に応じて表示するジャケット画像のピースの枚数を決める。

アンロックチャレンジを他のプレイヤーと関係を持つソーシャルゲームに適用する場合、アンロックチャレンジを他のプレイヤーにサポートしてもらう機能を設ける。具体的には、図１８のステップＳ３１でプレイヤーがアンロックチャレンジを開始したとき、サーバが他のプレイヤー（予めプレイヤが設定登録した仲間プレイヤー、以下「フレンド」という）にその旨を通知する。通知を受け取ったプレイヤーがアンロックチャレンジをサポートする。アンロックチャレンジのサポートは、他のプレイヤーもアンロックチャレンジ対象の楽曲をプレイすることで行う。このサポートはアンロックチャレンジ対象の楽曲を同時にプレイするものではなく、アンロックチャレンジの制限時間内にプレイすればよい。他のプレイヤーからサポートを受けた場合、ステップＳ３５で獲得できるアンロックポイントが増量される。例えば、１人のサポートを受けた場合は１０％アップ、２人のサポートを受けた場合は２０％アップなどとサポートの人数に応じて増量されるアンロックポイントを決定する。あるいは、サポートする他のプレイヤーのプレイ結果（ランク、スコアなど）に応じて増量されるアンロックポイントを決定してもよい。サポートした側のプレイヤーにはサポートポイントが付与される。プレイヤーは、サポートポイントを貯めることで様々なアイテムと交換できるようになる。

図１９は、フレンドがプレイヤーのアンロックチャレンジをサポートするときの処理の流れを示すシーケンス図である。

まず、プレイヤーが自分のゲーム機においてアンロックチャレンジを開始すると、アンロックチャレンジを開始した旨がサーバに通知される（ステップＳ３０１）。プレイヤーは、クリア条件を選択し（ステップＳ３０２）、ゲームをプレイする（ステップＳ３０３）。

サーバは、プレイヤーのゲーム機からアンロックチャレンジ開始の通知を受信すると（ステップＳ３０４）、プレイヤーのフレンドをサーバのデータベースから検索してフレンドに対してプレイヤーがアンロックチャレンジを開始した旨を通知する（ステップＳ３０５）。図１９ではフレンド１人にのみ通知しているが、実際はプレイヤーのフレンド全てに通知する。

フレンドのゲーム機がサーバからアンロックチャレンジ開始の通知を受信するとその旨をフレンドに知らせる（ステップＳ３０６）。プレイヤーがアンロックチャレンジを開始したことは、プッシュ通知やゲーム内のメール機能などを用いてフレンドに知らされる。通知を受けて、フレンドは自身のゲーム機においてサポートを開始する（ステップと３０７）。

サポートが成功するとサポートが成功した旨がサーバに通知され（ステップＳ３０８）、サーバはサポート成功の通知を受信し（ステップＳ３０９）、フレンドに対して付与するサポートポイントを計算する（ステップＳ３１０）。付与されるサポートポイントはフレンドのゲーム機に通知されて加算される（ステップＳ３１１）。本実施例では、付与されるサポートポイントの計算をサーバで行い、サポートポイントの管理をゲーム機で行ったが、サーバでサポートポイントの管理を行うものでもよい。この場合、付与されるサポートポイントをゲーム機で求めてもよい。

一方、プレイヤーがゲームをプレイしてクリア条件を満たすとクリア条件を満たした旨がサーバに通知され（ステップＳ３１２，Ｓ３１３）、プレイヤーに対して付与するアンロックポイントを計算する（ステップＳ３１４）。付与されるアンロックポイントはプレイヤーのゲーム機に通知されて加算される（ステップＳ３１５）。アンロックポイントを計算する処理では、フレンドからサポート成功の通知を受けているので、通常より１０％アップしたアンロックポイントが付与される。本実施例では、アンロックポイントの計算をサーバで行ったが、ゲーム機で行ってもよい。この場合、プレイヤーのゲーム機にもサポート成功の通知を送信し、プレイヤーのゲーム機で１０％アップの処理を行う。また、アンロックポイントの管理をサーバで行ってもよい。

以上説明したように、本実施の形態によれば、ロック状態の楽曲に対してアンロックチャレンジを開始してその楽曲をプレイし、プレイ結果が所定のクリア条件を満たした場合はアンロックポイントを獲得し、獲得したアンロックポイントの合計が基準に達した場合は楽曲の状態を解禁に設定することにより、プレイヤーは、自分のタイミングで楽曲を解禁の状態にすることが可能となる。

本実施の形態によれば、アンロックチャレンジは楽曲をプレイすることで蓄積されるアンロックチャレンジゲージが一定値以上蓄積されたときに発動可能とし、楽曲をプレイするためにチケットを消費させるとともに、チケットを課金により入手可能とすることで、課金プレイヤーは無課金プレイヤーよりも有利に楽曲を入手することを可能とする。

なお、上記では、アンロックチャレンジの処理をサーバで行う例で説明したが、ゲーム機で必要な情報を管理し、全ての処理（フレンドへの通知も含む）をゲーム機側で行ってもよいし、アンロックチャレンジの処理をサーバとゲーム機に分散させてもよい。例えば、楽曲の状態の管理をゲーム機で行い、チケットの管理など課金に関係の深い処理をサーバで行う。また、本実施の形態では、楽曲のゲームデータを例に説明したが、ゲーム中で利用する他のデジタルデータについても同様に適用出来る。

［第３の実施の形態］
従来のリズムアクションゲームでは、各プレイヤーが入手した楽曲を共有する仕組みは提供されていなかった。

そこで、本実施の形態では、自分が持っている楽曲（「解禁」された楽曲）を他のプレイヤーとシェアする仕組みと、楽曲をシェアするインセンティブを与える仕組みについて説明する。

＜シェアソング＞
図２０は、本実施の形態におけるゲームシステムの全体の構成を示す全体構成図である。

各ゲーム機３，３Ａ，３Ｂは、ネットワークを介してサーバ７に接続される。ゲーム機３Ａ，３Ｂはフレンドが所有するゲーム機である。サーバ７は、フレンド情報、シェアソング情報、ログイン日時の情報を含む各プレイヤーの情報を管理する。

フレンド情報は、プレイヤーがフレンドとして登録したプレイヤーの情報である。フレンドとしてプレイヤーを登録するには、フレンドとして登録したいプレイヤーの識別情報（例えば、ＩＤ１２３４５６）をサーバ７に通知し、相手のプレイヤーから認証が得られたときにお互いをフレンドとして登録する。フレンドを探す方法の例として、サーバ７は、プレイヤーの位置情報を元に地理的に近いプレイヤー、あるいは、プレイした楽曲と回数などのプレイ履歴からユーザの音楽的な趣向を判定し、趣向の近いプレイヤーをフレンド候補として推薦する方法がある。プレイヤーは、推薦されたフレンド候補をフレンドとして登録した旨をサーバ７に通知し、相手のフレンド候補プレイヤーから認証が得られたときにお互いをフレンドとして登録する。

シェアソング情報は、プレイヤーがシェアソングとして登録した楽曲の情報である。プレイヤーは自分の持っている解禁された楽曲からシェアソングとして共有する楽曲をサーバ７に登録する。シェアソングをサーバ７に登録するときには、シェアソングとして登録する楽曲の識別情報、シェアソングをプレイしたときのハイスコア（ランク）、シェアソングをプレイしたときの難易度（スタンダード、ハード、マスター）の情報をサーバ７へ送信する。

ログイン日時は、プレイヤーがゲーム機３を起動してサーバ７にアクセスした日時である。プレイヤーがゲーム機３を起動してゲームを動作させると自動的にサーバ７にアクセスし、ログイン日時が記録される。

プレイヤーが他のプレイヤーのシェアソングのプレイを希望する場合、ゲーム機３がサーバ７に対してシェアソングリストを要求する。サーバ７は要求を受信すると、シェアソングリストを要求したプレイヤーのフレンドを検索し、検索したフレンドのうちログイン日時が所定時間以内（例えば１２時間以内）のフレンドが登録しているシェアソングをシェアソングリストに記載する。そして、サーバ７はシェアソングリストをゲーム機３に返信する。プレイヤーは、シェアソングリストの中からプレイしたいシェアソングを選択してゲーム機３でプレイする。以下、シェアソングをプレイするときの流れを説明する。

図２１は、プレイヤーがシェアソングをプレイする流れを示すフローチャートである。

プレイヤーがフレンドのシェアソングをプレイするとき、ゲーム機３は、フレンドのシェアソングの一覧を記載したシェアソングリストをサーバ７から取得し（ステップＳ４１）、シェアソングリストをゲーム画面上に表示する（ステップＳ４２）。図２２に、シェアソングをゲーム画面上に表示した例を示す。同図の例では、シェアソングのジャケット６１を表示し、ジャケット６１に重ねてシェアソングを提供するプレイヤーがそのシェアソングをプレイしたときのランク６２を表示する。また、ジャケット６１の周囲に枠６３を表示する。シェアソングを提供するプレイヤーがプレイした難易度に応じて枠６３の色を変化させる。シェアソングを提供するプレイヤーのランク、スコア、難易度等を表示することで、フレンドに対して自分の腕前を自慢するなどの欲求を満たすことができる。

プレイヤーがプレイするシェアソングを選択すると（ステップＳ４３）、選択したシェアソングのゲームデータがゲーム機３内に存在するか否か判定し（ステップＳ４４）、ゲームデータが存在していなければ（ステップＳ４４のＮＯ）、シェアソングのゲームデータをサーバ７からダウンロードする（ステップＳ４５）。

そして、ゲームデータがゲーム機３にダウンロードされるとゲームのプレイを開始する（ステップＳ４６）。プレイヤーが選択したシェアソングは、通常、プレイヤーにとって解禁された状態の楽曲ではない。そのため、ゲーム機３はサーバ７からそのシェアソングをプレイする許可を取得した後、ゲームのプレイを開始する。あるいは、ゲーム機３はサーバ７からシェアソングリストを受信した時点で、シェアソングリストに記載された楽曲についてプレイする許可を得られたものとしてゲームのプレイを開始してもよい。

なお、シェアソングをプレイするためには、チケットの代わりにリンクエナジーと呼ばれるポイントを消費する。リンクエナジーは、他のプレイヤーに自分のシェアソングをプレイされる、ログインボーナス、ミッションクリア、課金などにより得ることができる。シェアソングをプレイするために必要なリンクエナジーをシェアソング毎のプレイ回数に応じて上昇させることで、プレイヤーがいろいろなフレンドのシェアソングをプレイする効果が期待できる。

以上説明したように、本実施の形態によれば、プレイヤーは自分の保持する楽曲の中からフレンドがプレイ可能なシェアソングをサーバ７に登録しておき、シェアソングをプレイしたいプレイヤーがサーバに要求してフレンドのシェアソング一覧を取得し、プレイヤーがシェアソング一覧から選択したシェアソングのゲームデータとそのシェアソングをプレイする許可をサーバから取得することで、フレンド間で楽曲を共有することが可能となる。

なお、本実施の形態では、シェアソングをサーバ７に登録しておき、サーバ７からシェアソングリストとプレイの許可を取得したが、上記で説明したサーバの処理をシェアソングを提供するフレンドのゲーム機自身が行い、シェアソング情報の送信とプレイの許可を与えてもよい。また、本実施の形態では、楽曲のゲームデータを例に説明したが、ゲーム中で利用する他のデジタルデータについても同様に適用出来る。

［第４の実施の形態］
プレイヤーがネットワークを介して他のプレイヤーと関係するソーシャルゲームでは、期間限定のイベントが繰り返し開催されることが多い。プレイヤーは、イベントに参加することでゲーム内で用いるアイテムなどを得ることができる。魅力的なイベントを開催することでゲームのプレイを継続するきっかけにもなる。

本実施の形態では、イベントの結果の順位に応じて報酬を配布する時期をずらすことで、プレイヤーが積極的にイベントに参加するようになる仕組みを導入する。

まず、イベントの参加について説明する。イベントとしては、例えば、指定された楽曲のスコアをプレイヤー間で競うものがある。イベントＡでは楽曲Ａのスコアをプレイヤー間で競い、イベントＢでは楽曲Ｂのスコアをプレイヤー間で競う。プレイヤーがイベントＡに参加する場合、ゲーム機はサーバに対してイベントＡに参加する旨を通知し、イベントＡで用いられる楽曲Ａをダウンロードする。ゲーム機が既に楽曲Ａを保持している場合は改めてダウンロードする必要はない。サーバはイベントに参加したプレイヤーを管理する。例えば、サーバがゲーム機からイベントＡに参加する旨の通知を受信したときに、サーバの保持するイベント参加者リストにプレイヤーの識別情報を記載する。サーバは通知を送信したゲーム機の識別情報を管理してもよい。

イベントに参加するプレイヤーはチケット（例えば２枚）を消費して楽曲Ａをプレイし、ゲーム機はプレイ結果をサーバへ送信する。サーバ側でプレイヤーのチケットを管理している場合は、ゲーム機がサーバに楽曲Ａをプレイすることを通知し、サーバは該当するプレイヤーのチケットの枚数（例えば２枚）を減らし、楽曲Ａのプレイを許可することをゲーム機に通知する。ゲーム機はサーバから通知を受けると楽曲Ａのプレイを開始する。楽曲Ａのプレイが終了し、楽曲Ａのプレイ結果が得られると、ゲーム機はスコアなどのプレイ結果をプレイヤーやゲーム機の識別情報と合わせてサーバへ送信する。サーバは、受信したプレイ結果をイベント参加者リストに記載されたプレイヤーに関連付けて記録する。

イベントＡの期間が終了すると、サーバは、イベントＡに参加した各プレイヤーのプレイ結果を成績順に並べて集計し、プレイヤーの順位を確定する。そして、プレイ結果が上位のプレイヤーから順に配布期間をずらして報酬を配布する。配布する報酬はゲーム内で利用できるチケットや楽曲（ゲームデータ）などのデジタルデータである。報酬内容は順位に応じて異なっても良いし、同じものでもよい。本実施例では、次に開催されるイベントＢで使用する楽曲Ｂを報酬として配布する。

続いて、報酬の配布時期について説明する。図２３は、イベントの報酬を配布する時期を説明する図である。同図では、イベントＡの終了後にイベントＡの報酬を配布する時期を示している。図２３に示すように、イベントＡの終了後、まずイベントＡの上位プレイヤー（例えば、１位〜１００位）に報酬を配布し、続いてイベントＢの中位プレイヤー（例えば、１０１位〜５００位）に報酬を配布する。最後にイベントに参加した残りの下位プレイヤー（例えば、５０１位以下）に報酬を配布する。これにより、成績が上位のプレイヤーは下位のプレイヤーに比べて早い時期に報酬を得ることができるので、報酬の恩恵を早く受けることになる。

報酬として順位に関わらず同じ楽曲を配布する場合、報酬を配布する処理として各プレイヤーに対して楽曲の状態を「解禁」として配布する。すでに楽曲を「ロック状態」として所有しているプレイヤーに対してはその「ロック状態」を「解禁」に変更する。サーバでプレイヤーの楽曲の状態を管理する場合はサーバ内のプレイヤーの楽曲の状態を変更する。ゲーム機で楽曲の状態を管理する場合は、サーバから報酬として受け取る楽曲の情報を受信してゲーム機内に楽曲を記憶したり、楽曲の状態を変更したりする。

本実施例では、報酬は次回のイベントＢで用いられる楽曲Ｂであるため、楽曲Ｂを早期に受け取ったプレイヤーほどその楽曲Ｂをプレイする時期が早くなり、イベントＢが開始されるまでに練習できる期間が長くなるので有利になる。図２３の例では、イベントＢの開始前にイベントＡの上位、中位プレイヤーに対して報酬である楽曲Ｂを付与し、下位プレイヤーに対してはイベントＢ開始後に楽曲Ｂを付与する。イベントＡに参加した上位、中位プレイヤーはイベントＢの開始前に報酬を受け取っているので、イベントＢが開始したときにはイベントＢで用いられる楽曲Ｂを保持しているが、下位プレイヤーは、イベントＢが開始した後に報酬を受け取るので、イベントＢが開始したときには楽曲Ｂを保持していない。

ここで、イベントＢに参加する際に消費するチケットに差をつける例について説明する。イベントＢに参加するためには楽曲Ｂをプレイすることが必要であるので、楽曲Ｂの保持の有無で楽曲Ｂをプレイする際に消費するチケットに差をつける。イベントＡの報酬として楽曲Ｂを付与されたプレイヤーは、下位プレイヤーやイベントＡに参加せずにイベントＢから参加したプレイヤー（イベントＢに参加するために楽曲Ｂをダウンロードしたプレイヤー）より少ないチケット枚数（例えば、１枚）で楽曲Ｂをプレイできる。下位プレイヤーがイベントＢに参加する場合、イベントＡの報酬として楽曲Ｂを取得するまでは、イベントＡの上位、中位プレイヤーより多いチケット枚数（例えば、２枚）を消費してイベントに参加する必要がある。下位プレイヤーは報酬である楽曲Ｂを受け取った後は、少量のチケット枚数（例えば、１枚）でイベントに参加できる。なお、楽曲Ｂを報酬として付与されるまでの期間にイベントＢに参加するためにチケットを多く消費した下位プレイヤーについては、イベントＢ終了時の結果に応じて報酬の楽曲Ｂを取得する前にプレイした楽曲Ｂに使用したチケットの一部を返却してもよいし、チケットの代わりに別のポイントなどで返却してもよい。

なお、イベントの報酬内容を順位に応じて異ならせても良い。例えば、イベントの上位プレイヤーには所定の楽曲を「解禁」状態で付与し、中位、下位プレイヤーには「ロック状態」として付与してもよいし、上位プレイヤーには所定の楽曲を最後までプレイできる状態で付与し、中位、下位プレイヤーには途中（全楽曲の５０％）までしかプレイできない状態（制限付き楽曲）で付与してもよい。「ロック状態」で楽曲を付与されたプレイヤーは、前述したアンロックチャレンジに成功しなければ、その楽曲を自由にプレイできる「解禁」状態にすることできないため時間又は労力を要し、次のイベントまでに練習する期間が短くなる。報酬が制限付き楽曲の場合、付与されたプレイヤーが所定の課題をクリアしたり、期間が経過すると段階的にプレイできる楽曲の範囲が増えるようにしてもよい。このプレイヤーは、楽曲の最後までプレイするために時間又は労力を要するため、次のイベントまでに練習する期間が短くなる。

以上説明したように、本実施の形態によれば、次のイベントＢで利用するイベントＡの報酬（楽曲Ｂ）をプレイ結果に応じて配布時期をずらすことで、早く報酬を受け取ったプレイヤーは次回のイベントＢで有利になるので、プレイヤーが積極的にイベントに参加することを期待できる。

上記では、成績上位のプレイヤーに早く報酬を配布したが、成績下位のプレイヤーから順に報酬を配布するものでもよい。また、イベントの報酬として楽曲を例に説明したが、配布する報酬は次のイベントに参加するプレイヤーにとって有利になる他のデジタルデータであってもよい。

［第５の実施の形態］
第５の実施の形態では、フレンドと協力あるいは対戦する実施例について説明する。

＜レイドボス＞
レイドボスは、ゲームの進行中に出会うボスの一種であり、ゲームのプレイ結果（楽曲のスコア）に応じてダメージを与えることができる。レイドボスイベントは、フレンドに協力を要請することができる。協力を要請されたフレンドは、チケットを消費してレイドボスイベントに参加することができる。なお、フレンドに協力を要請するためにはリンクエナジーが必要である。

レイドボスイベントでは、レイドボスの体力値をゲーム画面上に表示し、ゲームプレイ中にスコアが入る度にレイドボスの体力値を減少させてリアルタイムに反映させる。また、レイドボスの体力値に応じて画面全体の演出を変化させる。例えば、ゲームの背景の動く速度をレイドボスの体力値に応じて変化させたり、ゲーム画面全体の色みを変化させる。なお、ゲーム画面全体の演出の変化については、ネットワークを介した他のプレイヤーとの対戦、自身がハイスコアを出したときのゴーストデータとの対戦の場合にも、相手との点差に応じて同じように適用してもよい。

レイドボスイベント発生時に、プレイヤーがチケットを多めに消費することで与えるダメージの倍率が上がる。具体的には、通常３枚のチケットを消費するところを５枚のチケットを消費した場合、レイドボスに与えるダメージが通常の１．５倍になる。

＜アーケード筐体＞
本ゲームプログラムをゲームセンターなどに設置されたアーケード筐体で動作させてもよい。プレイヤーがアーケード筐体でプレイする場合、アーケード筐体を通じてサーバにログインすることで、プレイヤーの保持するゲーム機で獲得したチケットなどのアイテムをアーケード筐体でのプレイにも使用することができる。アーケード筐体でプレイしたときに、アンロックチャレンジを開始した場合やレイドボスを発見した場合、登録されているフレンドに対して通知を送信する。また、プレイヤーが所属店舗をサーバに設定しており、かつその店舗において３０分以内のプレイ履歴が存在する場合に、登録されているフレンドに対して通知を送信する。また、ゲーム機の位置情報を元に、プレイした店舗の近くにいるフレンドに対して通知を送信する。さらに、プレイヤーの保持するゲーム機で特定の条件を満たした場合に、アーケード筐体で使用できる特別なプレイチケットを配布してもよい。

１…ゲームプログラム
１１…操作入力部
１２…予兆画像制御部
１３…ライン制御部
１４…タイミング判定部
１５…スコア処理部
１６…画像出力部
１７…背景処理部
１８…音声出力部
１９…ゲームデータ蓄積部
３，３Ａ，３Ｂ…ゲーム機
５１Ａ〜５１Ｄ…ライン
５２，５２Ａ〜５２Ｃ…予兆画像
５３，５３Ａ，５３Ｂ…仮想交点
５４…アイコン
５５…適正範囲
５６…消失点
５７…衝突予定位置
６１…光のオブジェクト
６２…穴
６３…ジャケット
６４…ランク
６５…枠
７…サーバ

Claims (5)

1. コンピュータを、
   各ゲーム装置からイベントに関するゲームのプレイ結果を受信するプレイ結果受信手段、
   前記プレイ結果を集計し、集計した結果に応じて前記各ゲーム装置に報酬を配布する時期を決めるプレイ結果集計手段、
   前記プレイ結果集計手段が決めた時期に前記報酬をプレイヤが使用できるように該当する前記ゲーム装置へ前記報酬に関する情報を付与する報酬付与手段、
   として機能させることを特徴とする報酬付与プログラム。
2. 前記プレイ結果集計手段は、前記プレイ結果に応じて前記ゲーム装置をグループに分け、グループ毎に報酬が使用できる時期を決めることを特徴とする請求項１記載の報酬付与プログラム。
3. 前記報酬は、前記イベントの後に開催される別のイベントで使用されるデータであることを特徴とする請求項１又は２記載の報酬付与プログラム。
4. 前記報酬は、前記別のイベントでプレイされるゲームデータであって、当該報酬が使用できる時期は、前記別のイベントの開始前と開始後を含むことを特徴とする請求項３記載の報酬付与プログラム。
5. 請求項１乃至４のいずれかに記載の報酬付与プログラムを記憶したプログラム記憶部と、
   前記プログラム記憶部に記憶された報酬付与プログラムを実行するコンピュータと、
   を備えた報酬付与装置。

Images