JP6296523B1 - ゲームシステム及びプログラム - Google Patents

Abstract

【課題】ゲーム内で期間限定のイベントを開催する場合に、ユーザに不満を与えない。【解決手段】ゲームシステム（Ｓ）の取得手段（３０１）は、ゲーム内のイベントの期間内に所定の効果を発生させるためのパラメータであって、イベントの期間外は効果の発生が制限されるイベント用パラメータを取得する。受付手段（１０１）は、イベントの期間外において、イベント用パラメータを更新させるための操作を受け付ける。更新手段（３０３）は、操作に基づいて、イベント用パラメータを更新させる。【選択図】図１３

Description

本発明は、ゲームシステム及びプログラムに関する。

従来、ゲーム内において期間限定のイベントが開催されるゲームシステムが知られている。例えば、特許文献１には、期間限定のイベントを開催するゲームシステムが記載されている。

特開２０１４−１５０９２９号公報

上記のような技術では、イベントの開催を事前に認知させるために、イベントの内容やイベントの期間などをユーザに告知することがある。しかしながら、告知からイベントが始まるまでに時間がかかると、イベントを楽しみにしているユーザを待たせることになり、ユーザに不満感を与えることがあった。

本発明は上記課題に鑑みてなされたものであって、その目的は、ゲーム内で期間限定のイベントを開催する場合に、ユーザに不満を与えないゲームシステム及びプログラムを提供することである。

上記課題を解決するために、本発明の一態様に係るゲームシステムは、ゲーム内のイベントの期間内に所定の効果を発生させるためのパラメータであって、前記イベントの期間外は前記効果の発生が制限されるイベント用パラメータを取得する取得手段と、前記イベントの期間外において、前記イベント用パラメータを更新させるための操作を受け付ける受付手段と、前記操作に基づいて、前記イベント用パラメータを更新させる更新手段と、を含む。

ゲームシステムの全体構成を示す図である。 メニュー画像の一例を示す図である。 イベントの開催を時系列的に説明するための図である。 イベント画像の一例を示す図である。 エントリーが完了した場合のイベント画像の一例を示す図である。 ユーザがボーナスボタンを選択した場合のイベント画像の一例を示す図である。 強化ボタンが選択された場合のイベント画像の一例を示す図である。 応援団の強化中におけるイベント画像の一例を示す図である。 応援団の強化が完了した場合のイベント画像の一例を示す図である。 エントリー期間中にボーナスが上限に達した場合のイベント画像の一例を示す図である。 イベントの期間中のイベント画像の一例を示す図である。 対戦結果画像の一例を示す図である。 ゲームシステムで実現される機能のうち、本発明に関連する機能を示す機能ブロック図である。 イベントデータベースの一例を示す図である。 ボーナスデータベースの一例を示す図である。 イベントデータの一例を示す図である。 エントリー期間内に実行される処理の一例を示すフロー図である。 エントリー期間内に実行される処理の一例を示すフロー図である。 イベントの期間内に実行される処理の一例を示すフロー図である。 変形例における機能ブロック図である。

［１．ゲームシステムの全体構成］
以下、本発明に係る実施形態を図面に基づいて説明する。図１は、ゲームシステムの全体構成を示す図である。図１に示すように、本実施形態に係るゲームシステムＳは、ゲーム端末１０と、サーバ３０と、を含む。ゲーム端末１０とサーバ３０は、インターネットなどのネットワークＮに接続される。このため、ゲーム端末１０とサーバ３０との間で相互にデータ通信が可能である。なお、図１では、ゲーム端末１０とサーバ３０を１台ずつ示しているが、これらは複数台あってもよく、その台数は任意である。例えば、ゲーム端末１０は、ユーザの数だけ存在してもよい。

ゲーム端末１０は、ユーザが操作するコンピュータである。例えば、ゲーム端末１０は、携帯端末（例えば、スマートフォンなどの携帯電話又はタブレット型コンピュータ）、パーソナルコンピュータ、携帯ゲーム機、据置ゲーム機、業務用ゲーム機、又は、情報処理機能を備えた多機能型テレビジョン受像機（スマートテレビ）等である。

図１に示すように、ゲーム端末１０は、制御部１１、記憶部１２、通信部１３、操作部１４、及び表示部１５を含む。制御部１１は、少なくとも１つのマイクロプロセッサを含む。制御部１１は、オペレーティングシステムやプログラムに従って処理を実行する。記憶部１２は、主記憶部（例えば、ＲＡＭ）及び補助記憶部（例えば、不揮発性の半導体メモリ）を含む。記憶部１２は、プログラムやデータを記憶する。例えば、ゲーム端末１０がパーソナルコンピュータ等である場合、記憶部１２は、ハードディスクドライブ又はソリッドステートドライブ等の補助記憶部を含むようにしてもよい。通信部１３は、通信モジュールなどの通信インタフェースを含む。通信部１３は、ネットワークＮを介してデータ通信を行う。

操作部１４は、入力デバイスであり、例えば、キー、レバー、ゲームコントローラ（ゲームパッド）、マウスやタッチパネルなどのポインティングデバイス、又はキーボード等を含んでもよい。また例えば、操作部１４は、ユーザが音声又はジェスチャによって入力操作を行うためのマイクやカメラを含んでもよい。表示部１５は、例えば、液晶表示パネル又は有機ＥＬディスプレイ等であり、制御部１１の指示に従って画面を表示する。なお、操作部１４及び表示部１５は、ゲーム端末１０に内蔵されていなくともよく、ゲーム端末１０に接続された外部装置であってもよい。

サーバ３０は、サーバコンピュータである。図１に示すように、サーバ３０は、制御部３１、記憶部３２、及び通信部３３を含む。制御部３１、記憶部３２、及び通信部３３のハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。例えば、サーバ３０は、ゲームプログラムを記憶しており、ゲーム端末１０からの要求に応じてゲームプログラムを配信するようにしてもよいし、ゲームプログラムは、他のサーバコンピュータに記憶されており、当該他のサーバコンピュータからゲーム端末１０に配信されるようにしてもよい。

なお、記憶部１２又は記憶部３２に記憶されるものとして説明するプログラムやデータは、例えば、ネットワークＮを介してゲーム端末１０又はサーバ３０に供給されるようにしてもよい。また、ゲーム端末１０又はサーバ３０は、情報記憶媒体（例えば、光ディスク又はメモリカード等）に記憶されたプログラム又はデータを読み取るための読取部（例えば、光ディスクドライブ又はメモリカードスロット）を含むようにしてもよい。そして、情報記憶媒体を介してゲーム端末１０又はサーバ３０にプログラムやデータが供給されるようにしてもよい。

［２．ゲームの概要］
ゲームシステムＳでは、複数のユーザの各々がゲームをプレイする。例えば、ゲームは、ユーザが１人で遊べるモードと、他のユーザと協力又は対戦して一緒に遊ぶモードと、を含むようにしてもよい。本実施形態では、各ユーザが参加可能な期間限定のイベントが開催されるようになっている。

イベントとは、例えば、通常（イベントの期間外）とは異なる内容でゲームが進行するものである。例えば、イベントでは、ゲームの遊び方が通常とは異なる。例えば、イベントでは、ゲームのストーリーや登場人物に変化が生じる。例えば、イベントは、ユーザが１人で遊べるものであってもよいが、複数のユーザが参加できるものであってもよく、ユーザ同士で協力し合ったり、ユーザ同士で対戦したりするものであってもよい。例えば、イベントは、各ユーザが獲得した得点を他のユーザと競うものである。例えば、イベントは、１回だけ開催されてもよいし、同じイベントが、複数回繰り返し開催されてもよい。例えば、イベントは、当該イベントに設定されたイベントの期間に開催される。

イベントの期間とは、例えば、イベントが開催される期間である。イベントの期間の長さは任意に定めてよく、例えば、数日程度で終わるようにしてもよいし、数週間又は数ヶ月程度継続するようにしてもよい。例えば、イベントの期間は、ゲームの中の世界の架空の日時ではなく、現実世界の日時で示されるものである。即ち、本実施形態のイベントは、ゲームのストーリーが進行して架空の日時が経過すると終了するものではなく、現実世界において、所定の日時が訪れた場合に終了するものである。例えば、イベントの期間は、ゲームシステムＳの運営者が指定するようにしてもよいし、イベントの期間中に、イベントの期間の短縮又は延長が行われてもよい。

例えば、ユーザは、イベントの期間中に、他のユーザと繰り返し対戦する。例えば、ユーザは、個々の対戦の結果に応じて得点を獲得し、イベントの期間内にユーザが獲得した得点に基づいて、イベント全体でのユーザの評価が決まる。得点とは、例えば、イベント中の個々の対戦での結果の良し悪しを数値で示すものであり、本実施形態では、ポイントと記載する。評価とは、例えば、イベント全体での結果の良し悪しを示すものであり、ユーザのランキングなどである。例えば、イベントの期間中における総獲得ポイントで評価が決まってもよいし、１回の対戦で獲得した最高ポイントで評価が決まってもよい。また例えば、１日の中で獲得したポイントで評価が決まってもよいし、所定の評価対象期間内で獲得したポイントで評価が決まってもよい。評価対象期間は、ユーザの評価の対象となる期間であり、例えば、数日又は数週間程度の期間が設定されてもよい。例えば、イベントの期間中には、複数の評価対象期間が設定されてもよい。

本実施形態では、ゲームの一例として、ユーザが育成したキャラクタでチームを組み、対戦相手のチームと対戦する野球ゲームを説明する。対戦相手は、他のユーザであってもよいし、コンピュータであってもよい。例えば、ユーザがゲーム端末１０を操作してゲームプログラムを起動すると、運営者からのお知らせが表示された後に、メニュー画像が表示部１５に表示される。

図２は、メニュー画像の一例を示す図である。図２に示すように、メニュー画像Ｇ１の表示領域Ａ１０には、ユーザ名と、ユーザが保有するコイン及びストーンの数と、が表示される。コインやストーンは、後述するゲーム内通貨の一例であり、例えば、アイテムを購入したり、キャラクタの抽選や強化をしたりするために用いられる。

例えば、本実施形態のゲームは、複数のパートを含んでおり、メニュー画像Ｇ１には、どのパートを遊ぶかを選択するための選択画像Ｇ１１〜Ｇ１３が表示される。例えば、ゲームは、ユーザがキャラクタを育成するサクセスパートと、他のユーザが育成したキャラクタのチーム又は予めサーバ３０で用意したキャラクタのチームと対戦するスタジアムパートと、ユーザがクリアしたミッションの報酬を得るためのチャレンジパートと、を含む。選択画像Ｇ１１は、サクセスパートを遊ぶためのものである。選択画像Ｇ１２は、スタジアムパートを遊ぶためのものである。選択画像Ｇ１３は、チャレンジパートを遊ぶためのものである。図２の例では、選択画像Ｇ１２が選択されており、スタジアムパートを遊ぶための選択画像Ｇ１２０，Ｇ１２１が表示された状態となっている。

例えば、サクセスパートでは、ユーザは、育成対象となるキャラクタに練習をさせ、当該キャラクタの能力パラメータを増加させたり、特殊スキルを身につけさせたりする。サクセスパートにおけるキャラクタの育成が完了すると、ユーザは、当該キャラクタを、スタジアムパートでの試合に出場させることができるようになる。

例えば、スタジアムパートの試合は、選択画像Ｇ１２０を選択することで遊ぶことができる。スタジアムパートでは、ユーザは、予めサーバ３０に保存されたデータの中のどのデータに基づく対戦をするかを指定したり、試合で使用するキャラクタやアイテムを指定したりする。アイテムは、ゲームを有利に進めるものであればよく、例えば、試合を有利に進めたり、試合後に獲得するポイントを増加させたりするものである。

例えば、ユーザは、一試合通じて操作可能であってもよいし、チャンスやピンチなどの所定場面だけ操作可能であってもよい。また例えば、一試合全てが自動的に進行してもよい。試合が終了すると、ユーザが試合で獲得したポイントが計算される。ポイントは、試合の結果に基づいて定まればよく、例えば、試合の得失点、ユーザの操作、及びキャラクタの動作に基づいて計算される。本実施形態では、試合で獲得したポイントによって、ユーザのランキングが決まるようになっている。ユーザは、ランキングを上げるべく、サクセスパートでのキャラクタの育成と、スタジアムパートでの試合と、を繰り返すことになる。

本実施形態では、スタジアムパートでの試合に関するイベントが開催される場合を説明するが、イベントはこれに限られず、サクセスパートに関するイベントであってもよいし、どのパートにも関係しないイベントであってもよい。例えば、イベントでは、ユーザは、試合を繰り返しプレイして、より多くのポイントを獲得することを目指す。例えば、ゲームの運営者がイベントの開催を決定すると、各ユーザにイベントの開催が事前に通知され、その後にイベントが開始される。

図３は、イベントの開催を時系列的に説明するための図である。なお、図３に示すｔ軸は、時間軸である。本実施形態では、イベントの開催が通知されると、各ユーザは、イベントに対してエントリーできるようになっている。エントリーは、例えば、イベントに対する参加表明であり、ユーザは、事前にエントリーしておくと、イベントの期間中にゲームを有利に進めることができるようになる。例えば、エントリーを受け付ける期間は、運営者側がイベントの準備をする準備期間ということもできる。なお、イベントの開催が通知された時点と、エントリーを開始する時点と、は異なってもよいが、ここでは、同じものとして説明する。以降、イベントの開催が通知されてエントリーを開始する時点を、エントリー開始時点ｔ１と記載する。

従来のイベントでは、ユーザは、イベントの開催を知っていても、イベントの開始時点ｔ２が訪れるまでは、ただ待つだけなので不満を感じることがあったが、本実施形態では、エントリー開始時点ｔ１からイベントの開始時点ｔ２までのエントリー期間中において、イベント中に獲得するポイントを増加させるための操作をすることができるようになっている。例えば、エントリー期間が訪れると、メニュー画像Ｇ１には、イベントの名称、エントリー期間、及びイベントが開催される期間に関する情報などを含む選択画像Ｇ１２１が表示される。まだエントリーしていないユーザが選択画像Ｇ１２１を選択すると、イベント画像が表示部１５に表示され、エントリーが可能な状態になる。

図４は、イベント画像の一例を示す図である。図４に示すように、イベント画像Ｇ２の表示領域Ａ２０は、表示領域Ａ１０と同様である。例えば、イベント画像Ｇ２の表示領域Ａ２１には、ユーザがまだエントリーしていないことを示すメッセージが表示される。なお、表示領域Ａ２１は、イベントに関する他の情報を含んでもよく、例えば、イベントでのゲームの遊び方、エントリー期間、及びイベントが開催される期間に関する情報などを含んでもよい。

本実施形態のイベントは、ユーザが所属する地方内でのランキングを競うものであり、ユーザは、エントリーボタンＢ２１０を選択した後に、エントリーする地方を指定できるようになっている。また、確認ボタンＢ２１１は、イベント中に獲得可能な報酬を確認するための画像である。ユーザは、エントリーボタンＢ２１０を選択し、エントリーする地方を指定すると、イベントにエントリーすることができる。ユーザのエントリーが完了すると、イベント画像Ｇ２の表示が変わり、エントリーが完了したことが分かるようになる。

図５は、エントリーが完了した場合のイベント画像Ｇ２の一例を示す図である。図５に示すように、表示領域Ａ２１には、ユーザがエントリーした地方が表示され、ユーザがエントリー済みであることが分かるようになっている。そして、エントリーボタンＢ２１０は消去され、その代わりに、エントリーする地方を変更するための変更ボタンＢ２１２が表示される。

本実施形態では、ユーザは、イベントにエントリーすると、自身が保有するコインと引き替えに、ゲーム内での応援団を強化することができるようになっている。例えば、応援団は、イベント中のユーザを応援するためのキャラクタである。ユーザは、応援団を強化すると、イベント中に獲得するポイントにボーナスを発生させることができる。

図５に示すように、エントリーが完了すると、イベント画像Ｇ２には、応援団の強化レベルと現在のボーナスを示すボーナスボタンＢ２２が表示される。強化レベルは、応援団の強化の程度を示す数値であり、エントリー期間中の操作によって段階的に上がる。図５の例では、ユーザがエントリーしたばかりなので、強化レベルは初期値の１であり、ボーナスは初期値の０％となっている。

図６は、ユーザがボーナスボタンＢ２２を選択した場合のイベント画像Ｇ２の一例を示す図である。図６に示すように、表示領域Ａ２３０には、応援団の強化後のボーナスと、応援団の強化に必要なコインと、が表示される。ユーザが、応援団を強化するための強化ボタンＢ２３１を選択すると、応援団の強化を確認するためのポップアップがイベント画像Ｇ２上に表示される。なお、本実施形態では、コインが不足していても強化ボタンＢ２３１が選択可能な場合を説明するが、コインが不足している場合は、強化ボタンＢ２３１を選択できないようにしてもよい。

図７は、強化ボタンＢ２３１が選択された場合のイベント画像Ｇ２の一例を示す図である。図７に示すように、イベント画像Ｇ２のポップアップＰ２４には、応援団を強化する前後でのボーナスの変化と、応援団の強化に必要なコインと、が表示される。応援団の強化は即時に完了してもよいが、本実施形態では、所定時間が経過した後に、応援団の強化が完了するようになっている。このため、ポップアップＰ２４には、応援団の強化に必要な時間も表示される。ユーザがキャンセルボタンＢ２４０を選択すると、図６の画面に戻り、応援団の強化は行われない。ユーザが強化確定ボタンＢ２４１を選択すると、応援団の強化が開始される。

図８は、応援団の強化中におけるイベント画像Ｇ２の一例を示す図である。図８の表示領域Ａ２０に示すように、ユーザのコインは、応援団の強化に必要な分（ここでは、１００枚）だけ減少する。また、表示領域Ａ２３の表示が更新され、表示領域Ａ２３０には、応援団の強化の完了までの残り時間が表示される。本実施形態では、応援団の強化中は、強化ボタンＢ２３１を選択できないようになっており、強化ボタンＢ２３１はグレーアウトされる。応援団の強化中は、ユーザは、強化ボタンＢ２３１を選択できないので、例えば、サクセスパートやスタジアムパートをプレイしつつ、応援団の強化が完了するのを待つことになる。

図９は、応援団の強化が完了した場合のイベント画像Ｇ２の一例を示す図である。図９に示すように、応援団の強化が完了したので、強化ボタンＢ２３１は、グレーアウトが解除され、再び選択可能な状態となる。また、表示領域Ａ２３０には、次の強化レベルになった場合のボーナスが表示される。なお、表示領域Ａ２３２には、応援団員のキャラクタが表示されるようになっており、現在のボーナスに応じた数のキャラクタが表示される。例えば、応援団の強化レベルが１から２に上がると、表示領域Ａ２３２内のキャラクタが１人から２人に増えた画像に変化する。

応援団の強化は、エントリー期間中に１回だけできるようにしてもよいが、本実施形態では、ユーザは、応援団を繰り返し強化することができ、応援団を強化するほどボーナスが増加するようになっている。また、応援団の強化に必要なコインと応援団の強化が完了するまでに必要な時間は、応援団の強化レベルに関係なく固定値であってもよいが、本実施形態では、応援団の強化レベルが上がるほど、必要なコインが多くなり、かつ、強化が完了するまでに必要な時間も長くなるようになっている。

また、エントリー期間中において、ユーザは、好きなだけ応援団を強化させてボーナスを増やすことができてもよいが、本実施形態では、エントリー期間中に上げることができるボーナスは、上限値が設定されており、それよりも大きくはならないように制限されている。即ち、エントリー期間中は、応援団の強化レベルに上限値が設定されている。

図１０は、エントリー期間中にボーナスが上限に達した場合のイベント画像Ｇ２の一例を示す図である。図１０に示すように、表示領域Ａ２３０には、ボーナスが上限に達したため、これ以上は応援団の強化をすることができないことを示すメッセージが表示され、強化ボタンＢ２３１は選択できないようにグレーアウトされる。図１０の状態になると、応援団を強化できないので、ユーザは、イベントの開始時点ｔ２を待つことになる。イベントの開始時点ｔ２が訪れると、エントリー期間が終了してイベントを選択可能な状態となる。

図１１は、イベントの期間中のイベント画像Ｇ２の一例を示す図である。図１１に示すように、イベントの期間になると、表示領域Ａ２５には、イベントの開催中であることを示すメッセージが表示され、表示領域Ａ２６には、ユーザの現在のランキングや報酬に関する情報が表示される。応援団の強化は、エントリー期間中だけ可能であってもよいが、本実施形態では、イベントの期間中でも、応援団の強化ができるようになっている。

エントリー期間中のボーナスの上限値とイベントの期間中のボーナスの上限値は、同じであってもよいが、本実施形態では、イベントの期間中は、エントリー期間におけるボーナスの上限値の制限が解除され、ユーザは、ボーナスを更に増加させることができるようになっている。このため、ユーザが、エントリー期間中にボーナスを上限値まで増やしたとしても、イベントの期間中は、更にボーナスを増やすことができるようになる。応援団を強化してボーナスを増やす流れは、イベントの期間中とエントリー期間中とで異なってもよいが、ここでは同じ流れとする。このため、ユーザがボーナスボタンＢ２２を選択すると、図６〜図１０を参照して説明した流れで応援団を強化することができる。

また、イベントの期間になると、イベント画像Ｇ２に、試合を開始するための試合ボタンＢ２７が表示されるようになる。ユーザは、試合ボタンＢ２７を選択することで、ユーザと同じ地方でエントリーした他のユーザのチームと試合をすることができる。イベントの期間中の試合は、通常のスタジアムパートでの試合と同じ流れで実行されてもよい。試合が終了すると、当該試合の結果を示す対戦結果画像が表示部１５に表示される。

図１２は、対戦結果画像の一例を示す図である。図１２に示すように、対戦結果画像Ｇ３の表示領域Ａ３０は、表示領域Ａ１０と同じである。表示領域Ａ３１には、試合で獲得したポイント、現在のボーナス、イベントの期間中のポイントの最大値、及び現在のランキングが表示される。図１２の例では、ボーナスが１５０％であり、ユーザが５万ポイント獲得したことを示している。即ち、ユーザが試合で実際に獲得したポイントは、２万ポイントであったが、その１５０％である３万ポイントのボーナスが発生し、これらの合計である５万ポイントが、ユーザが試合で獲得したポイントとなる。

なお、イベントの期間は、例えば、地区予選期間、本大会期間、及び決勝戦期間のように、複数の小期間に分かれていてもよい。小期間の数は、２つ以上の任意の数であってよく、例えば、小期間ごとにランキングがリセットされるようにしてもよいし、小期間が経過するたびに、ランキングの高いユーザだけが次の小期間のイベントに参加できるようにしてもよい。この場合、各期間におけるランキングを集計する集計期間中は、試合をすることができず、応援団の強化のみが可能であってもよい。

上記のように、本実施形態では、イベントを楽しみにしているユーザを、イベントの開始時点ｔ２までただ待たせるのではなく、エントリー期間中に応援団を強化させることによって、ゲーム内で期間限定のイベントを開催する場合に、ユーザに不満を与えないようにしている。以降、ゲームシステムＳの構成の詳細を説明する。

［３．ゲームシステムにおいて実現される機能］
図１３は、ゲームシステムＳで実現される機能のうち、本発明に関連する機能を示す機能ブロック図である。ここでは、サーバ３０において実現される機能と、ゲーム端末１０において実現される機能と、を順番に説明する。

［３−１．サーバにおいて実現される機能］
図１３に示すように、サーバ３０において、データベース記憶部３００、取得部３０１、通知部３０２、更新部３０３、ゲーム内通貨増減部３０４、及び効果発生部３０５が実現される。

［３−１−１．データベース記憶部］
データベース記憶部３００は、記憶部３２を主として実現される。データベース記憶部３００は、ゲームに関するデータを統括的に管理し、各ユーザがゲームをプレイするために必要なデータベースを記憶する。ここでは、データベース記憶部３００が記憶するデータベースの一例として、イベントデータベースＤＢ１と、ボーナスデータベースＤＢ２と、を説明する。

図１４は、イベントデータベースＤＢ１の一例を示す図である。図１４に示すように、イベントデータベースＤＢ１は、各ユーザのエントリー状況やイベントの進行状況を示すデータベースである。例えば、イベントデータベースＤＢ１には、ユーザＩＤに関連付けて、エントリーフラグ、地方情報、応援団の強化レベル、ボーナスパラメータ、応援団のステータス、応援団の強化の完了予定時間、イベントの期間内の最高獲得ポイント、及び現在のランキング等が格納される。

ユーザＩＤは、ユーザを識別するためのユーザ識別情報の一例であり、ゲームシステムＳ内でユーザを一意に識別する情報である。エントリーフラグは、ユーザによるエントリーの有無を示す情報である。ユーザがエントリーを完了すると、当該ユーザのエントリーフラグが更新される。地方情報は、ユーザがエントリーした地方であり、複数の地方のうちユーザが選択した地方を示す。

応援団の強化レベルは、応援団の強化の程度を示す。例えば、強化レベルの数値が大きいほど、応援団がより強く強化されていることを示す。例えば、ユーザが強化確定ボタンＢ２４１を選択するたびに、強化レベルが１つずつ上がる。ボーナスパラメータは、現在の強化レベルに応じたボーナスを示すパラメータである。例えば、ボーナスパラメータの値は、ボーナスの大きさを示し、ここでは、ポイントの増加分を示すパーセントで示される。例えば、強化レベルが上がるほど、ボーナスパラメータが大きくなる。強化レベルとボーナスパラメータとの関係は、後述するボーナスデータベースＤＢ２に定義されているものとする。

応援団のステータスは、応援団を強化中であるか、それ以外の状態（例えば、強化を完了した状態や強化する前の状態）であるか、を示す情報である。完了予定時間は、応援団の強化完了を予定している日時である。別の言い方をすれば、完了予定時間は、強化完了までにあとどれだけの時間が必要かを示す。例えば、完了予定時間は、応援団の強化が開始すると、次の強化レベルに応じた時間が格納される。完了予定時間が訪れると、応援団の強化が完了し、ステータスが強化完了を示すことになる。強化レベルと、強化完了までに必要な時間と、の関係は、後述するボーナスデータベースＤＢ２に定義されているものとする。なお、ここで言う時間は、例えば、いわゆるサーバ時間であり、ゲーム端末１０がサーバ３０に接続した場合に送られてくる時間に基づいた時間を元にしている。サーバ時間を利用するのは、ゲーム端末１０の時間は、ユーザが容易に変更可能だからである。例えば、ゲーム端末１０は、サーバ３０に接続した時に送られてくる時間と、サーバ３０から送られてきた時間を受け取った時間からの相対的な現在時間と、に基づいてサーバ時間を取得する。例えば、ゲーム端末１０とサーバ３０との接続中は、ゲーム端末１０に対し、定期的にサーバ時間が送られており、ゲーム端末１０は、最新のサーバ時間と、サーバ時間が送られてきたゲーム端末１０内の時間と、現在の時刻と、に基づいて完了予定時間を算出する。

最高獲得ポイントは、イベントの期間内に獲得したポイントの最高値である。ランキングは、最高獲得ポイントに応じたユーザのランキングである。エントリー期間中は、まだイベントが開始されていないので、最高獲得ポイントと現在のランキングにはデータが格納されない。

なお、イベントデータベースＤＢ１に格納されるデータは、図１４の例に限られない。例えば、イベントデータベースＤＢ１は、エントリー期間やイベントの期間を示す日時情報が格納されていてもよい。また例えば、イベントデータベースＤＢ１には、イベントの期間中にユーザが獲得したポイントの履歴や総獲得ポイントが格納されてもよい。また例えば、イベントデータベースＤＢ１には、イベントの期間中における試合の結果の履歴が格納されてもよい。

図１５は、ボーナスデータベースＤＢ２の一例を示す図である。図１５に示すように、ボーナスデータベースＤＢ２は、応援団の強化レベルとボーナスパラメータとの関係を示すデータベースである。別の言い方をすれば、ボーナスデータベースＤＢ２は、強化確定ボタンＢ２４１の選択とボーナスパラメータとの関係を示すデータベースである。例えば、ボーナスデータベースＤＢ２には、強化レベルごとに、当該強化レベルになった場合のボーナスパラメータの値、当該強化レベルになるための必要コイン、当該強化レベルになるための必要経過時間、当該強化レベルになることができる強化可能期間、及びイベント画像Ｇ２の表示情報が格納される。

図１５に示すように、例えば、強化レベルが上がるほど、ボーナスパラメータは大きくなる。また例えば、強化レベルが上がるほど、必要コインは多くなる。また例えば、強化レベルが上がるほど、必要経過時間が長くなる。なお、必要経過時間は、応援団の強化が開始されてから強化が完了するまでの時間の長さを示す。例えば、応援団の強化の開始時点は、ユーザが強化確定ボタンＢ２４１を選択した時点であってもよいし、この時点よりも後の時点であってもよい。

強化可能期間は、強化レベルに達することができる期間である。例えば、本実施形態では、エントリー期間とイベントの期間において、応援団の強化が可能なので、強化可能期間としては、これらの何れかとなる。即ち、ここでは、強化可能期間として、２つの期間が存在し、強化レベルの上限（即ち、ボーナスパラメータの上限）が２段階存在する場合を説明する。ただし、強化レベルの上限は、３段階以上存在してもよく、この場合は、強化可能期間は、３つ以上存在することになる。

例えば、エントリー期間の中で、強化可能期間が複数に分かれていてもよい。例えば、エントリー開始時点ｔ１から数日間は、強化レベル１０までしか上げることができず、その後からイベントの期間の開始時点ｔ２までは、強化レベル１５まで上げることができるようになってもよい。同様に、イベントの期間の中で強化可能期間が複数に分かれていてもよい。例えば、イベントの期間の開始時点ｔ２から数日間は、強化レベル２０までしか上げることができず、その後からイベントの期間の終了時点ｔ３までは、強化レベル２５まで上げることができるようにしてもよい。このように、強化可能期間を複数に分けることで、エントリー期間内で段階的にボーナスパラメータの上限を解除したり、イベントの期間内で段階的にボーナスパラメータの上限を解除したりしてもよい。

表示情報は、イベント画像Ｇ２の表示態様を示す情報である。表示態様とは、画像の表示のさせ方であり、例えば、画像の種類、色、模様、輝度、サイズ、解像度、又はエフェクト（点滅や回転など）である。本実施形態では、応援団の強化レベルが上がりボーナスパラメータが大きくなるほど、表示領域Ａ２２５内の応援団の人数が増えるので、図１５に示すように、表示情報は、表示領域Ａ２２５における応援団の人数を示すものといえる。なお、表示情報は、ボーナスパラメータと表示態様との相関関係を示せばよく、応援団の人数以外のものを示してもよい。例えば、応援団以外のキャラクタの数によってボーナスパラメータの大きさを示してもよいし、画像の色やサイズによってボーナスパラメータの大きさを示してもよい。他にも例えば、キャラクタ以外を利用してボーナスパラメータの大きさを表現してもよく、動物や物の数や種類の違いによってボーナスパラメータの大きさを表現してもよい。

なお、データベース記憶部３００に記憶されるデータは、上記の例に限られない。データベース記憶部３００は、ユーザに関する各種情報を示すユーザデータベースを記憶してもよい。ユーザデータベースには、ユーザが保有するゲーム内通貨（例えば、コインやストーンなど）が格納されていてもよい。また例えば、データベース記憶部３００は、ユーザが育成したキャラクタを示すキャラクタデータベースを記憶してもよい。この場合、キャラクタデータベースには、キャラクタの能力パラメータや特殊スキルパラメータなどが格納されるようにしてよい。また例えば、データベース記憶部３００は、ゲーム端末１０に表示させる各画像の画像データを記憶してもよい。

［３−１−２．取得部］
取得部３０１は、制御部３１を主として実現される。取得部３０１は、ゲーム内のイベントの期間内に所定の効果を発生させるためのパラメータであって、イベントの期間外は効果の発生が制限されるボーナスパラメータを取得する。

効果とは、例えば、イベントの結果の良し悪しに影響するものであり、イベントの期間内におけるゲームを有利に進めるものである。例えば、ポイントを獲得することを目指すイベントであれば、効果は、ポイントを稼ぎやすくなるものであり、ポイントの獲得量にボーナスが発生することである。また例えば、イベントにおいてオブジェクト（キャラクタ、アイテム、カードなど）を使用する場合には、効果は、オブジェクトの能力が高くなることであってもよい。また例えば、効果は、対戦に勝利しやすくなることであってもよい。本実施形態では、イベントの期間には、イベントの期間内にユーザが獲得したポイントに基づいて、ユーザの評価が決まるイベントが開催されるので、ポイントの獲得量を大きくする効果を一例として説明する。即ち、応援団の強化によって得られるボーナスを、効果の一例として説明する。

イベントの期間外とは、例えば、イベントの期間に含まれない期間であり、イベントの期間の開始前であってもよいし、イベントの期間の終了後であってもよい。例えば、イベントの期間外は、イベントの期間以外の全期間であってもよい。また例えば、イベントの期間外は、イベントの開始時点ｔ２の所定時間前（例えば、エントリー開始時点ｔ１）から当該開始時点ｔ２までの期間と、イベントの終了時点ｔ３から当該終了時点の所定時間後までの期間と、の少なくとも一方を含んでいてもよい。

効果の発生を制限とは、例えば、効果の発生を禁止すること、効果を発生させないこと、効果を発生させるためにボーナスパラメータが使用されないことである。

本実施形態では、各ユーザのボーナスパラメータがイベントデータベースＤＢ１に格納されているので、取得部３０１は、イベントデータベースＤＢ１を参照してボーナスパラメータを取得することになる。ボーナスパラメータは、本発明に係るイベント用パラメータの一例である。

イベント用パラメータとは、例えば、効果の大きさを数値で示す情報であり、イベント用パラメータの数値が大きいほど効果が大きくなってもよいし、これとは逆に、数値が小さいほど効果が大きくなってもよい。例えば、イベント用パラメータは、イベントの期間前は、その値が変化するが、効果を発生させるためには使用されないものである。即ち、例えば、イベント用パラメータは、イベントの期間前においては、効果を発生させるために参照されないものである。

［３−１−３．通知部］
通知部３０２は、制御部３１を主として実現される。通知部３０２は、イベントの開始前において、イベントの開催をユーザに通知する。イベントの開始前とは、例えば、イベントの開始時点ｔ２よりも前である。通知とは、例えば、イベントの開催に関する情報をユーザに提示することである。この情報は、例えば、イベントの遊び方、イベントの期間、イベントの内容、又はイベントにおけるミッションなどを含んでもよい。

通知部３０２は、所定の通知方法によってイベントの開催を通知すればよく、例えば、本実施形態のようにゲームプログラム（ゲームアプリ）内のイベント画像Ｇ２で通知してもよいし、メニュー画像Ｇ１が表示される前の運営者からのお知らせにおいて通知してもよい。他にも例えば、通知部３０２は、ゲームプログラム以外の方法を利用して通知してもよい。他の方法としては、ユーザにメッセージを通知可能な方法であればよく、例えば、電子メール、メッセージアプリ、又はウェブサイトなどを利用してもよい。

［３−１−４．更新部］
更新部３０３は、制御部３１を主として実現される。更新部３０３は、後述する受付部１０１が受け付けた操作に基づいて、ボーナスパラメータを更新させる。この操作は、ボーナスパラメータを更新するための任意の操作であればよく、例えば、イベントの開催を通知するイベント画像Ｇ２に対する操作であってもよい。本実施形態では、強化確定ボタンＢ２４１を選択することが操作の一例として説明するが、特にポップアップＰ２４による確認をしない場合には、強化ボタンＢ２３１を選択することが操作に相当してもよい。他にも、画像内の他のボタン、アイコン、スライドバーなどを選択するといった種々の操作が、ボーナスパラメータを更新するための操作であってよい。以降、「強化確定ボタンＢ２４１を選択」と記載した箇所については、「操作」と読み替えることができる。

更新とは、例えば、ボーナスパラメータの値を変化させることであり、値を増加又は減少させることである。本実施形態では、値が大きいほどゲームが有利になるボーナスパラメータがイベント用パラメータとして用いられるので、更新が増加を意味する場合を説明する。このため、以降の説明において、増加と記載した箇所は、更新と読み替えることができる。なお、値が小さいほどゲームが有利になるパラメータ（例えば、キャラクタの疲労度など）がイベント用パラメータとして用いられるのであれば、更新は減少を意味することになる。

例えば、更新部３０３は、ユーザが強化確定ボタンＢ２４１を選択した場合に、当該ユーザのボーナスパラメータを増加させる。更新部３０３は、ユーザ１人あたり１回だけボーナスパラメータの増加を可能にしてもよいし、複数回増加可能にしてもよい。本実施形態では、更新部３０３は、受付部１０１が強化確定ボタンＢ２４１の選択を受け付けるたびに、効果が大きくなるようにボーナスパラメータを更新する場合を説明する。別の言い方をすれば、更新部３０３は、ユーザが強化確定ボタンＢ２４１を選択する回数が増えるほど、ボーナスパラメータの増加量を大きくする。

例えば、更新部３０３は、イベントの開始前は、ボーナスパラメータの上限を所定値未満に制限するようにしてもよい。この所定値は、例えば、エントリー期間においてボーナスパラメータが取りうる最大値であり、図１５のデータ例であれば、１５０％である。なお、ボーナスパラメータの上限は、予め定められていればよく、例えば、全ユーザで共通であってもよいし、ユーザによって異なってもよい。ユーザによって上限を異ならせる場合には、ユーザのプレイ期間やレベルなどによって上限を決めてもよい。

例えば、更新部３０３は、イベントの開始後は、ボーナスパラメータの上限の制限を解除するようにしてもよい。例えば、更新部３０３は、イベントの開始後は、ボーナスパラメータの上限を一切設けないようにしてもよいし、これまでの上限よりも大きな上限を設けるようにしてもよい。別の言い方をすれば、更新部３０３は、イベントの開始後は、ボーナスパラメータの上限をなくしてもよいし、上限を増加させてもよい。

更に、更新部３０３は、ボーナスパラメータの上限を、イベントの開催の通知以降、時間経過に伴って段階的に増加させるようにしてもよい。段階的とは、例えば、ボーナスパラメータが徐々に変わることである。例えば、更新部３０３は、ボーナスパラメータの上限を複数回増加させる。別の言い方をすれば、更新部３０３は、ボーナスパラメータの上限を徐々に増加させる。例えば、更新部３０３は、イベントの開催が通知された後は、時間が経過するほど上限が大きくなるように、当該上限を増加させる。別の言い方をすれば、更新部３０３は、イベントの期間が近づくほど上限が大きくなるように、当該上限を増加させる。

また例えば、更新部３０３は、イベントの期間外における操作と、イベントの期間内における操作と、の両方に基づいて、ボーナスパラメータを更新させるようにしてもよい。即ち、更新部３０３は、イベントの期間外だけではなく、イベントの期間内においてもボーナスパラメータを更新してもよい。例えば、更新部３０３は、イベントの期間外とイベントの期間内の各々において、ユーザ１人あたり１回だけボーナスパラメータを増加させてもよいし、複数回増加させることができるようにしてもよい。また例えば、更新部３０３は、イベントの期間外でボーナスパラメータを更新可能な回数と、イベントの期間内でボーナスパラメータを更新可能な回数と、を同じにしてもよいし、互いに異ならせてもよい。

また例えば、更新部３０３は、ゲーム内通貨との引き替えを条件にして、ボーナスパラメータを更新するようにしてもよい。ゲーム内通貨とは、例えば、ゲームの中で有効な仮想通貨であり、コイン、ポイント、ストーン、又はチケットなどと呼ばれるものである。引き替えとは、例えば、ゲーム内通貨の消費を条件とすることである。本実施形態では、引き替え対象となるゲーム内通貨がコインである場合を説明する。更新部３０３は、ボーナスデータベースＤＢ２を参照し、ボーナスパラメータの更新に必要なコインを特定し、ユーザがそれ以上のコインを有していれば、ボーナスパラメータの更新を許可する。

また例えば、更新部３０３は、受付部１０１が強化確定ボタンＢ２４１の選択を受け付けてから必要経過時間が経過した場合に、ボーナスパラメータを更新する。必要経過時間は、所定時間であり、例えば、ボーナスパラメータが変化するまでに必要な時間として予め定められた時間である。本実施形態では、必要経過時間は、ボーナスデータベースＤＢ２に格納されている。更新部３０３は、受付部１０１が強化確定ボタンＢ２４１の選択を受け付けた場合に、イベントデータベースＤＢ１の完了予定時間に、現時点から必要経過時間後の日時を格納する。更新部３０３は、先述したサーバ時間を利用した計時処理を実行し、必要経過時間が訪れたと判定した場合にボーナスパラメータを更新する。

例えば、更新部３０３がサーバ３０で実現される場合には、サーバ３０における更新部３０３は、サーバ３０のリアルタイムクロックを利用した計時処理を実行し、必要経過時間が訪れたかを判定することになる。また例えば、更新部３０３がゲーム端末１０で実現される場合には、サーバ３０から受信したサーバ時間と、当該サーバ時間を受信した時間と、がデータ記憶部１００に記憶されており、更新部３０３は、サーバ時間を受信した時間と現在時刻との差と、サーバ時間を受信した時間と、に基づいて正規の現在時刻を取得し、当該現在時刻に基づいて必要経過時間が訪れたかを判定することになる。

［３−１−５．ゲーム内通貨増減部］
ゲーム内通貨増減部３０４は、制御部３１を主として実現される。ゲーム内通貨増減部３０４は、ゲームの実行結果に基づいて、ユーザが所有するゲーム内通貨を増減させる。例えば、ゲーム内通貨が増減するための条件が定められており、ゲーム内通貨増減部３０４は、当該条件が満たされた場合に、ゲーム内通貨を増減させる。この条件としては、例えば、対戦をすること、所定のミッションをクリアすること、ゲーム内通貨を購入する操作をすることなどである。

本実施形態では、コインと引き替えにボーナスパラメータが増加するので、ゲーム内通貨増減部３０４は、ボーナスパラメータが更新される場合に、コインを減少させる。例えば、ゲーム内通貨増減部３０４は、更新部３０３がボーナスパラメータを更新する前後又はそれと同時に、コインを減少させる。コインの消費量は、ボーナスパラメータの値に関係なく固定値であってもよいが、本実施形態では、ゲーム内通貨増減部３０４は、ボーナスパラメータが示すボーナスが大きくなるほど、コインの消費量を大きくする。例えば、ゲーム内通貨増減部３０４は、ボーナスパラメータが大きいほどコインの消費量を大きくする。本実施形態では、ボーナスパラメータとコインの消費量との関係は、ボーナスデータベースＤＢ２に定められているので、ゲーム内通貨増減部３０４は、ボーナスパラメータに関連付けられた消費量のコインを消費させることになる。

［３−１−６．効果発生部］
効果発生部３０５は、制御部３１を主として実現される。効果発生部３０５は、ボーナスパラメータに基づいて、イベントの期間内に所定の効果を発生させる。即ち、効果発生部３０５は、ボーナスパラメータに基づいて、イベントの期間内の効果の程度を決定する。例えば、イベントが有利になること、イベントの結果に関するパラメータが変化すること、ゲーム内通貨が付与されること、アイテムが付与されること、又は、表示部１５に所定の画像が表示されることが、効果が発生することに相当する。

本実施形態では、ポイントのボーナスが効果の一例なので、効果発生部３０５は、ボーナスパラメータが大きくなるほど試合後に獲得するポイントを大きくし、ボーナスパラメータが小さくなるほど試合後に獲得するポイントを小さくする。本実施形態では、イベントの期間中は、ユーザがポイントを獲得することを目指すので、効果発生部３０５は、ボーナスパラメータに基づいて、ユーザが獲得するポイントを増加させることになる。

［３−２．ゲーム端末において実現される機能］
図１３に示すように、ゲーム端末１０においては、データ記憶部１００、受付部１０１、及び表示制御部１０２が実現される。

［３−２−１．データ記憶部］
データ記憶部１００は、記憶部１２を主として実現される。データ記憶部１００は、ゲームを実行するために必要なデータを記憶する。ここでは、データ記憶部１００が記憶するデータの一例として、イベントデータＤＴ１を説明する。

図１６は、イベントデータＤＴ１の一例を示す図である。図１６に示すように、イベントデータＤＴ１は、ユーザのエントリー状況やイベントの進行状況を示すデータである。ここでは、イベントデータＤＴ１は、イベントデータベースＤＢ１のうち、ゲーム端末１０のユーザに対応するレコードの内容が格納される場合を説明するが、他のユーザのレコードの内容が格納されていてもよい。

本実施形態では、ゲーム端末１０がイベントデータＤＴ１を更新した場合は、ゲーム端末１０は、サーバ３０に対し、更新後のイベントデータＤＴ１を送信し、サーバ３０は、当該更新後のイベントデータＤＴ１をイベントデータベースＤＢ１に格納する。一方、サーバ３０がイベントデータベースＤＢ１を更新した場合は、サーバ３０は、更新したレコードに対応するユーザのゲーム端末１０に対し、更新後のレコードの内容を送信し、ゲーム端末１０は、当該更新後のレコードの内容をイベントデータＤＴ１に格納する。このようにして、サーバ３０とゲーム端末１０との間で通信が行われることで、イベントデータベースＤＢ１とイベントデータＤＴ１との整合性が取られている。

なお、データ記憶部１００に記憶されるデータは、上記の例に限られない。データ記憶部１００は、ゲームに必要なデータを記憶すればよい。例えば、データ記憶部１００は、ユーザＩＤを記憶してもよいし、ボーナスデータベースＤＢ２を記憶してもよい。

［３−２−２．表示制御部］
表示制御部１０２は、制御部１１を主として実現される。表示制御部１０２は、イベントの期間前に、強化確定ボタンＢ２４１の選択を受け付けるためのイベント画像Ｇ２を表示部１５に表示させる。先述したように、イベント画像Ｇ２は、イベントの期間、イベントの内容、又はイベントにおけるミッションなどの情報を含む画像である。なお、ボーナスパラメータを更新するための操作を受け付けるための画像としては、強化確定ボタンＢ２４１のようなボタンに限られず、任意の画像を適用可能であり、例えば、アイコンであってもよいし、スライドバーのようなものであってもよい。

例えば、表示制御部１０２は、イベント画像Ｇ２において、ボーナスパラメータが示す効果を識別可能に表示させるようにしてもよい。例えば、表示制御部１０２は、効果の内容や大きさを示す情報をイベント画像Ｇ２に表示させる。本実施形態では、表示制御部１０２は、イベント画像Ｇ２のボーナスボタンＢ２２内にボーナスパラメータを表示させたり、表示領域Ａ２３２に応援団を表示させたりすることによって、ボーナスパラメータが示す効果を識別可能に表示させることになる。

また例えば、表示制御部１０２は、ボーナスパラメータが示す効果の大きさを示すようにイベント画像Ｇ２の表示態様を変化させるようにしてもよい。ここでの効果の大きさとは、例えば、効果の度合いであり、ゲームで有利になる度合いである。例えば、本実施形態のように、ポイントの変化量を変える効果が発生する場合は、変化量の大きさが効果の大きさに相当する。本実施形態では、ボーナスパラメータとイベント画像Ｇ２の表示態様との関係は、ボーナスデータベースＤＢ２に定義されているので、表示制御部１０２は、ボーナスデータベースＤＢ２に格納された表示情報に基づいて、イベント画像Ｇ２の表示態様を変化させることになる。例えば、表示制御部１０２は、ボーナスパラメータが示すボーナスが大きくなるほど、表示領域Ａ２３２におけるキャラクタの数を多くする。なお、ボーナスの大きさは、キャラクタの数以外によって示されるようにしてもよく、例えば、ボーナスが大きくなるほど画像のサイズを大きくしてもよいし、ボーナスが大きくなるほど画像の輝度を上げたりしてもよい。

［３−２−３．受付部］
受付部１０１は、制御部１１を主として実現される。受付部１０１は、イベントの期間外において、ボーナスパラメータを更新させるための操作を受け付ける。本実施形態では、この操作が強化確定ボタンＢ２４１を選択する操作なので、受付部１０１は、操作部１４の検出信号に基づいて、強化確定ボタンＢ２４１が選択されたかを判定することになる。

例えば、受付部１０１は、通知部３０２による通知がなされてから、強化確定ボタンＢ２４１の選択を受け付けるようにしてもよい。即ち、通知部３０２による通知前は、イベント画像Ｇ２が表示されないので、受付部１０１は、強化確定ボタンＢ２４１の選択を受け付けない。通知部３０２による通知後は、イベント画像Ｇ２が表示されるので、受付部１０１は、強化確定ボタンＢ２４１の選択を受け付ける。例えば、受付部１０１は、強化確定ボタンＢ２４１の選択を繰り返し受け付け可能であるようにしてもよい。

例えば、受付部１０１は、イベントの期間内も強化確定ボタンＢ２４１の選択を受け付け可能であるようにしてもよい。即ち、受付部１０１は、イベントの期間外だけでなく、イベントの期間の開始時点ｔ２から終了時点ｔ３までの任意の時点において、強化確定ボタンＢ２４１の選択を受け付けるようにしてもよい。

例えば、受付部１０１は、強化確定ボタンＢ２４１の選択を受け付けてから所定時間が経過するまでの間は、次の選択の受け付けを制限するようにしてもよい。この所定時間は、強化確定ボタンＢ２４１の選択を受け付け可能になるまでに必要な時間である。所定時間は、固定値であってもよいが、ボーナスパラメータが示す効果が大きくなるほど、所定時間が長くなるようにしてもよい。本実施形態では、ボーナスデータベースＤＢ２に格納された必要経過時間が、当該所定時間に相当する。

なお、受付部１０１は、本実施形態のように強化確定ボタンＢ２４１を表示させるための強化ボタンＢ２３１をグレーアウトする以外の方法によって、強化確定ボタンＢ２４１の選択を制限してもよい。例えば、受付部１０１は、強化ボタンＢ２３１はグレーアウトせずポップアップＰ２４を表示可能な状態にして、ポップアップＰ２４において強化確定ボタンＢ２４１をグレーアウトしてもよい。また例えば、受付部１０１は、グレーアウトではなく、強化ボタンＢ２３１又は強化確定ボタンＢ２４１自体を表示させないようにしてもよいし、強化ボタンＢ２３１又は強化確定ボタンＢ２４１の表示は変えずに属性を「ｅｎａｂｌｅ」にする（ボタン選択を無効化する）ようにしてもよい。

［４．ゲームシステムにおいて実行される処理］
次に、ゲームシステムＳにおいて実行される処理を説明する。ここでは、エントリー期間内に実行される処理と、イベントの期間内に実行される処理と、を説明する。以降説明する処理は、制御部１１が記憶部１２に記憶されたプログラムに従って動作し、制御部３１が記憶部３２に記憶されたプログラムに従って動作することによって実行される。下記の処理は、図１３に示す各機能ブロックによる処理の一例である。

［４−１．エントリー期間内に実行される処理］
図１７−図１８は、エントリー期間内に実行される処理の一例を示すフロー図である。図１７に示すように、まず、サーバ３０においては、イベントのエントリー開始時点ｔ１が訪れると、制御部３１は、イベントの開催を通知可能な状態にする（Ｓ３０１）。Ｓ３０１の処理は、運営者により所定の操作が行われた場合に実行されてもよいし、エントリー開始時点ｔ１が訪れた場合に実行するようにバッチが組まれているようにしてもよい。Ｓ３０１においては、制御部３１は、イベント画像Ｇ２を表示させるための選択画像Ｇ１２１（図２）を含むように、メニュー画像Ｇ１の表示データを更新する。

ゲーム端末１０においては、ゲームプログラムが起動されると、制御部１１は、サーバ３０に対し、最新のデータを要求する（Ｓ１０１）。例えば、ゲームプログラムが起動するまでの間に、サーバ３０側でデータの更新が行われている場合があるので、ゲームプログラムの起動時に、最新のデータが要求されるようになっている。例えば、ゲームで使用されるデータにはバージョン情報（例えば、更新日時）が関連付けられており、Ｓ１０１においては、制御部１１は、記憶部１２に記憶されたデータのバージョン情報をサーバ３０に送信する。なお、ゲーム端末１０からサーバ３０にデータが送信される場合には、ゲーム端末１０を識別する情報（例えば、ユーザＩＤやＩＰアドレスなど）が送信され、サーバ３０は、どのゲーム端末１０と通信するかを特定可能となっている。

サーバ３０においては、最新のデータの要求を受信すると、制御部３１は、ゲーム端末１０に対し、記憶部３２に記憶された最新のデータを送信する（Ｓ３０３）。Ｓ３０３においては、制御部３１は、ゲーム端末１０から受信したバージョン情報と、記憶部３２に記憶されたバージョン情報と、を比較する。制御部３１は、全データのバージョン情報が一致していれば、ゲーム端末１０に記憶されたデータが最新であると判定し、特にデータの送信はしない。一方、制御部３１は、バージョン情報が一致していないデータがある場合は、ゲーム端末１０に対し、最新版の当該データを送信する。ここでは、メニュー画像Ｇ１の表示データが更新されているので、最新版の当該表示データが送信される。また、イベントデータＤＴ１も、このタイミングで送信されるようにしてもよい。

ゲーム端末１０においては、最新のデータを受信すると、制御部１１は、メニュー画像Ｇ１（図２）を表示部１５に表示させる（Ｓ１０３）。ここでは、エントリー期間になっているので、Ｓ１０３において表示されるメニュー画像Ｇ１は、エントリー期間前は表示されなかった選択画像Ｇ１２１を含むことになる。

制御部１１は、ユーザが選択画像Ｇ１２１を選択した場合に、サーバ３０に対し、イベント画像Ｇ２の表示要求を送信する（Ｓ１０５）。なお、他の選択画像Ｇ１１，Ｇ１３，Ｇ１２０が選択された場合は、制御部１１は、サクセスパート、チャレンジパート、又はスタジアムパートの通常の試合に係る処理を実行し、以降の処理は実行されない。

サーバ３０においては、イベント画像Ｇ２の表示要求を受信すると、制御部３１は、イベントデータベースＤＢ１のエントリーフラグを参照し、イベント画像Ｇ２の表示要求をしたユーザがエントリー済みかを判定する（Ｓ３０５）。まだエントリーしていないと判定された場合（Ｓ３０５；Ｎ）、制御部３１は、エントリー前である旨のステータスを送信する（Ｓ３０７）。ステータスは、予め定められた情報であればよく、ゲーム端末１０は、どの情報がどのステータスを意味しているかを示すデータを、予め記憶部１２に記憶しているものとする。この点は、以降の処理でも同様である。

ゲーム端末１０においては、エントリー前である旨のステータスを受信すると、制御部１１は、エントリー前のイベント画像Ｇ２を表示部１５に表示させる（Ｓ１０７）。ここでは、エントリー期間中であり、かつ、ユーザがイベントにまだエントリーしていないので、イベント画像Ｇ２は、図４の状態となり、ユーザはイベントにエントリーする。ユーザは、エントリーボタンＢ２１０を選択し、エントリーする地方を入力することになる。

制御部１１は、ユーザがエントリーボタンＢ２１０を選択した場合に、サーバ３０に対して、所定のエントリー要求を送信する（Ｓ１０９）。エントリー要求は、所定形式のデータが送信されることで実行されるようにすればよく、例えば、ユーザがエントリーする地方を示す情報を含む。

サーバ３０においては、エントリー要求を受信すると、制御部３１は、エントリー要求をしたユーザのエントリー処理を実行する（Ｓ３０９）。Ｓ３０９においては、制御部３１は、イベントデータベースＤＢ１のうち、エントリー要求をしたユーザのユーザＩＤに対応するレコードのエントリーフラグをエントリー済みに更新し、エントリー要求に含まれる地方情報を格納する。これにより、ユーザのエントリーが完了し、応援団を強化可能な状態となる。

制御部３１は、エントリー後である旨のステータスを送信する（Ｓ３１１）。例えば、制御部３１は、現在の強化レベルとボーナスパラメータを特定し、ボーナスボタンＢ２２の表示内容を決定する。ユーザがエントリーしたばかりの時点では、ボーナスボタンＢ２２における応援団の強化レベルは初期値の１となり、ボーナスパラメータは初期値の０％となる。

ゲーム端末１０においては、エントリー後である旨のステータスを受信すると、制御部１１は、エントリー後のイベント画像Ｇ２（図５）を表示部１５に表示させる（Ｓ１１１）。ここでは、エントリー期間中であり、かつ、エントリーが完了しているので、イベント画像Ｇ２は、図５の状態となり、ユーザは応援団の強化をすることができる状態となる。

ゲーム端末１０においては、イベントデータＤＴ１と現在の強化レベルに基づいて、制御部１１は、イベント画像Ｇ２の表示を更新する（Ｓ１１３）。Ｓ１１３においては、イベント画像Ｇ２は、図６の状態となり、強化ボタンＢ２３１の選択が可能となる。例えば、Ｓ１１３においては、制御部１１は、ユーザの応援団の強化レベルに基づいて、次の強化レベルになった場合のボーナスパラメータの増加量を特定し、次の強化レベルに必要なコインも特定する。また例えば、制御部１１は、ユーザの応援団の強化レベルに基づいて、表示領域Ａ２３２に表示させる応援団の画像を決定する。

図１８に移り、制御部１１は、強化ボタンＢ２３１が選択された場合に、ポップアップＰ２４（図７）を表示部１５に表示させる（Ｓ１１５）。Ｓ１１５においては、制御部１１は、現在の強化レベルのボーナスパラメータ、次の強化レベルのボーナスパラメータ、次の強化レベルの必要経過時間、及び次の強化レベルに必要なコインに基づいて、ポップアップＰ２４を生成する。

制御部１１は、ポップアップＰ２４の強化確定ボタンＢ２４１が選択された場合に、サーバ３０に対して、ユーザの応援団の強化要求を送信する（Ｓ１１７）。強化要求は、所定形式のデータが送信されることで実行されるようにすればよい。なお、キャンセルボタンＢ２４０が選択された場合は、Ｓ１１３の処理に戻り、再びイベント画像Ｇ２が表示される。

サーバ３０においては、応援団の強化要求を受信すると、制御部３１は、イベントデータベースＤＢ１とボーナスデータベースＤＢ２に基づいて、制御部３１は、応援団の強化のために必要なコインが足りているかを判定する（Ｓ３１３）。Ｓ３１３においては、制御部３１は、ユーザの応援団の強化レベルに基づいて、次の強化レベルに必要なコインを特定し、ユーザのコインが当該必要なコイン以上であるかを判定する。ユーザのコインが足りていないと判定された場合（Ｓ３１３；Ｎ）、制御部３１は、コインが足りないため応援団を強化することができないことを示すエラーメッセージを送信し、本処理は終了する。この場合、ゲーム端末１０においては、イベント画像Ｇ２上で当該エラーメッセージが表示されるようにすればよい。

一方、ユーザのコインが足りていると判定された場合（Ｓ３１３；Ｙ）、制御部３１は、ユーザの応援団が強化中であることを示すようにイベントデータベースＤＢ１を更新する（Ｓ３１５）。Ｓ３１５においては、制御部３１は、応援団の強化に必要なコインの分だけ、ユーザのコインを減少させる。そして、制御部３１は、応援団ステータスを強化中にし、応援団の強化に必要な必要経過時間だけ後の時点を完了予定時間として格納する。

制御部３１は、ゲーム端末１０に対し、応援団が強化中である旨のステータスと次の強化レベルを送信する（Ｓ３１７）。なお、Ｓ３１７においては、制御部３１は、Ｓ３１５で更新したイベントデータベースＤＢ１のうち、ユーザに対応するレコードの内容も送信するようにしてもよい。

ゲーム端末１０においては、応援団が強化中である旨のステータスと次の強化レベルを受信すると、制御部１１は、応援団が強化中であることを示すイベント画像Ｇ２を表示させる（Ｓ１１９）。Ｓ１１９においては、応援団が強化中なので、イベント画像Ｇ２は、図８の状態となり、強化ボタンＢ２３１はグレーアウトされる。この場合、必要経過時間が経過するまでは、応援団を強化できないので、ユーザは、サクセスパートをプレイしたり、スタジアムパートをプレイしたりすることになる。なお、ゲーム端末１０において計時処理が行われることで、イベント画像Ｇ２において、必要経過時間までのカウントダウンが実行されてもよい。この場合、先述したように、サーバ時間に基づいて、計時処理が実行される。ゲーム端末１０は、必要経過時間が経過したと判定した場合に、サーバ３０に対してイベント画像Ｇ２の更新要求を送信し、応援団の強化が完了したことが表示領域Ａ２３内で通知されるようにしてもよい。

一方、図１７のＳ３０５において、エントリー済みであると判定された場合（Ｓ３０５；Ｙ）、図１８に移り、制御部３１は、イベントデータベースＤＢ１に基づいて、ユーザの応援団の必要経過時間が経過しているかを判定する（Ｓ３１９）。Ｓ３１９においては、制御部３１は、現時点が完了予定時間以降であれば、必要な時間が経過しているものと判定する。

必要経過時間が経過していないと判定された場合（Ｓ３１９；Ｎ）、ユーザの応援団は強化中であり、現時点では強化できないので、強化ボタンＢ２３１をグレーアウトするために、Ｓ３１７の処理に移行し、ゲーム端末１０において、図８の状態のイベント画像Ｇ２が表示されることになる。

一方、必要経過時間が経過したと判定された場合（Ｓ３１９；Ｙ）、制御部３１は、応援団の強化が完了するようにイベントデータベースＤＢ１を更新する（Ｓ３２１）。Ｓ３２１においては、制御部３１は、応援団の強化レベルとボーナスパラメータを増加させ、応援団のステータスを更新する。

制御部３１は、イベントデータベースＤＢ１とボーナスデータベースＤＢ２とに基づいて、ユーザのボーナスパラメータが上限に達しているかを判定する（Ｓ３２３）。Ｓ３２３においては、制御部３１は、ボーナスデータベースＤＢ２に格納された強化可能期間を参照し、エントリー期間中における強化レベルの最大値を特定する。そして、制御部３１は、ユーザの応援団の強化レベルが当該最大値未満であれば、ユーザのボーナスパラメータが上限に達していないと判定し、ユーザの応援団の強化レベルが当該最大値であれば、ユーザのボーナスパラメータが上限に達していると判定する。

ユーザのボーナスパラメータが上限に達していないと判定された場合（Ｓ３２３；Ｎ）、ユーザの応援団は強化可能な状態なので、Ｓ３１１の処理に移行し、ゲーム端末１０において、図６，９の状態のイベント画像Ｇ２が表示されることになる。

一方、ユーザのボーナスパラメータが上限に達していると判定された場合（Ｓ３２３；Ｙ）、制御部３１は、ボーナスパラメータが上限に達した旨のステータスを送信する（Ｓ３２５）。Ｓ３２５におけるイベント画像Ｇ２の生成方法自体は、Ｓ３１３と同様であるが、ここでは、ボーナスパラメータが上限に達しているので、強化ボタンＢ２３１は、グレーアウトした状態となる。

ゲーム端末１０においては、ボーナスパラメータが上限に達した旨のステータスを受信すると、制御部１１は、ボーナスパラメータが上限に達した場合のイベント画像Ｇ２を表示させる（Ｓ１２１）。Ｓ１２１においては、ボーナスパラメータが上限に達しているので、イベント画像Ｇ２は、図１０の状態となり、強化ボタンＢ２３１はグレーアウトされる。この場合、イベントの開始時点ｔ２になるまでは応援団を強化できないので、ユーザは、サクセスパートをプレイしたり、スタジアムパートをプレイしたりすることになる。

［４−２．イベントの期間内に実行される処理］
図１９は、イベントの期間内に実行される処理の一例を示すフロー図である。ここでは、エントリー期間中にエントリーを済ませたユーザが、イベントの期間内にイベントに参加する場合の処理を説明する。

図１９に示すように、まず、サーバ３０においては、イベントの開始時点ｔ２が訪れると、制御部３１は、イベントを開始するためのイベント開始処理を実行する（Ｓ３３１）。Ｓ３３１の処理は、運営者により所定の操作が行われた場合に実行されてもよいし、イベントの開始時点ｔ２が訪れた場合に実行するようにバッチが組まれているようにしてもよい。Ｓ３３１においては、制御部３１は、試合ボタンＢ２７を含むイベント画像Ｇ２（図１１）を表示できるように、イベント画像Ｇ２の表示データを更新する。

Ｓ１３１〜Ｓ１３３とＳ３３３は、それぞれＳ１０１〜Ｓ１０３とＳ３０３と同様であり、サーバ３０からゲーム端末１０に対し、最新のデータが送信される。ここでは、イベント画像Ｇ２の表示データが更新されているので、当該表示データがゲーム端末１０に送信されることになる。このイベント画像Ｇ２は、図１１の状態となり、試合ボタンＢ２７を含む。

ゲーム端末１０においては、表示データを受信すると、制御部１１は、イベントの期間中におけるイベント画像Ｇ２を表示部１５に表示させる（Ｓ１３５）。制御部１１は、操作部１４の検出信号に基づいて、ユーザの操作を特定する（Ｓ１３７）。ここでは、ボーナスボタンＢ２２の選択と、試合ボタンＢ２７の選択と、の何れかが行われる。

ユーザがボーナスボタンＢ２２を選択した場合（Ｓ１３７；ボーナスボタン）、ゲーム端末１０とサーバ３０との間で、応援団を強化する処理が実行される（Ｓ１３９，Ｓ３３５）。この処理は、エントリー期間中におけるＳ１１３〜Ｓ１２１とＳ３１３〜Ｓ３２５と同様であり、強化確定ボタンＢ２４１の選択によって、応援団が強化される。

一方、ユーザが試合ボタンＢ２７を選択した場合（Ｓ１３７；試合ボタン）、ゲーム端末１０とサーバ３０との間で、試合の処理が実行される（Ｓ１４１，Ｓ３３７）。Ｓ１４１とＳ３３７では、試合の設定が行われた後に試合が開始され、例えば、ゲーム端末１０はユーザの操作内容を示すデータをサーバ３０に送信し、サーバ３０は、当該データが示す操作に基づいて試合を進行するようにしてもよいし、ゲーム端末１０において試合が進行され、その結果だけがサーバ３０に送信されるようにしてもよい。

サーバ３０においては、試合が終了すると、制御部３１は、ユーザが獲得したポイントを計算し（Ｓ３３９）、計算したポイント及び対戦結果情報を送信する（Ｓ３４１）。Ｓ３３９においては、制御部３１は、試合の結果に基づいて、ユーザが獲得するポイントの基本量を決定し、当該基本量をボーナスパラメータに基づいて増加させることによって、ユーザが獲得するポイントを計算する。

ゲーム端末１０においては、ポイントと対戦結果情報を受信すると、制御部１１は、対戦結果画像Ｇ３を表示部１５に表示させ（Ｓ１４３）、本処理は終了する。

以上説明したゲームシステムＳによれば、ユーザは、イベントの期間内でボーナスを発生させるためのボーナスパラメータを、イベントの期間外でも更新することができるので、イベント開始まで待つことによって生じる不満感をユーザに与えることがない。また、イベント開始まで定期的にゲームをプレイさせることができ、アクティブユーザを増加させることができる。

また、イベントの開催を通知してから強化確定ボタンＢ２４１の選択を受け付けるので、常に強化確定ボタンＢ２４１の選択を受け付ける場合に比べて、イベントの特別感をユーザに与えることができる。

また、イベントの開始前におけるボーナスパラメータに上限を設けることで、イベントの開始前にユーザの優劣がつきすぎてしまうことを防止できる。

また、イベントの開始後はボーナスパラメータの上限を解除することで、イベントの期間内のユーザ間の競争を活性化することができる。

また、ボーナスパラメータの上限を、イベントの開催の通知以降、時間経過に伴って段階的に増加させることで、例えば、イベントの開始前にイベントへの期待感を段階的に大きくしたり、イベントの期間内においてイベントに変化を付けて飽きさせないようにしたりすることができる。

また、強化確定ボタンＢ２４１の選択を受け付けるイベント画像Ｇ２においてボーナスが識別可能に表示されるので、ユーザは、イベントが始まったときに発生するボーナスを確認しながら強化確定ボタンＢ２４１の選択をすることができる。

また、ボーナスの大きさを示すようにイベント画像Ｇ２の表示態様が変化し、ボーナスの大きさとイベント画像Ｇ２の表示態様に因果関係を持たせることができるので、イベントが始まったときに発生するボーナスの大きさを確認しやすくなる。

また、イベントの期間内も強化確定ボタンＢ２４１の選択を受け付け可能とすることで、開催中のイベントを継続してプレイさせる動機付けを与えることができる。

［５．変形例］
なお、本発明は、以上に説明した実施の形態に限定されるものではない。本発明の趣旨を逸脱しない範囲で、適宜変更可能である。

（１）例えば、実施形態では、エントリー期間中におけるボーナスパラメータに上限を設ける場合を説明したが、イベントの期間中に発生する効果を制限する方法はこれに限られない。例えば、ボーナスパラメータではなく、強化確定ボタンＢ２４１の選択回数によって、効果が大きくなりすぎないように制限をかけてもよい。

図２０は、変形例における機能ブロック図である。図２０に示すように、変形例では、実施形態で説明した機能に加えて、制限部１０３が実現される。ここでは、制限部１０３は、制御部１１を主として実現される。制限部１０３は、イベントの開始前は、強化確定ボタンＢ２４１の選択の回数を制限する。例えば、強化確定ボタンＢ２４１の選択の回数を制限するとは、強化確定ボタンＢ２４１を選択する回数を所定回数に制限することであり、強化確定ボタンＢ２４１を選択可能な回数が所定回数を超えないようにすることである。

例えば、データ記憶部１００は、強化確定ボタンＢ２４１を選択した回数を記憶してもよい。制限部１０３は、当該回数が所定回数に達した場合に、強化確定ボタンＢ２４１の選択自体を受け付けないように制限する。強化確定ボタンＢ２４１の選択自体を受け付けない方法は、実施形態で説明したように、制限部１０３は、強化ボタンＢ２３１をグレーアウトして、強化確定ボタンＢ２４１自体を表示できないようにしてもよい。他にも例えば、制限部１０３は、強化ボタンＢ２３１はグレーアウトせずポップアップＰ２４を表示可能な状態にして、ポップアップＰ２４において強化確定ボタンＢ２４１をグレーアウトしてもよい。また例えば、受付部１０１は、強化ボタンＢ２３１又は強化確定ボタンＢ２４１を表示させないようにしてもよいし、強化ボタンＢ２３１又は強化確定ボタンＢ２４１のボタン属性を「ｅｎａｂｌｅ」にする（無効化する）ようにしてもよい。

変形例（１）によれば、強化確定ボタンＢ２４１の選択の回数を制限することで、イベントの開始前にユーザの優劣がつきすぎてしまうことを防止できる。

（２）また例えば、制限部１０３は、イベントの開始後は、変形例（１）で説明した制限を解除するようにしてもよい。例えば、制限部１０３は、イベントの開始後は、強化確定ボタンＢ２４１の選択回数の上限を一切設けないようにしてもよいし、これまでの上限よりも回数が多い上限を設けるようにしてもよい。例えば、制限部１０３は、イベントの開始後は、強化確定ボタンＢ２４１の選択の上限をなくしてもよいし、上限を増加させてもよい。

変形例（２）によれば、イベントの開始後は、強化確定ボタンＢ２４１の選択の制限を解除することで、イベントの期間内のユーザ間の競争を活性化することができる。

（３）また例えば、制限部１０３は、変形例（１）で説明した強化確定ボタンＢ２４１の選択回数の上限を、イベントの開催の通知以降、時間経過に伴って段階的に増加させるようにしてもよい。例えば、制限部１０３は、強化確定ボタンＢ２４１の選択回数の上限を複数回増加させる。別の言い方をすれば、制限部１０３は、強化確定ボタンＢ２４１の選択回数の上限を徐々に増加させる。イベントの開催の通知後の時間と、選択回数の上限と、の関係は、データ記憶部１００に予め記憶させておいてもよい。この関係は、数式形式又はテーブル形式のデータとして記憶されていてもよいし、プログラムコードの一部として記述されてもよい。制限部１０３は、現時点に関連付けられた上限を設定することになる。

変形例（３）によれば、イベントの開催の通知以降、時間経過に伴って段階的に強化確定ボタンＢ２４１の選択の上限を増加させることで、例えば、イベントの開始前にイベントへの期待感を段階的に大きくしたり、イベントの期間内においてイベントに変化を付けて飽きさせないようにしたりすることができる。

（４）また例えば、上記変形例の２つ以上を組み合わせてもよい。

また例えば、応援団の強化にはコインが必要である場合を説明したが、他のパラメータが消費されることで応援団の強化が実行されるようにしてもよいし、特にパラメータを消費せずに応援団の強化が実行されてもよい。また例えば、イベントの内容や遊び方は、実施形態で説明した例に限られず、任意のイベントが開催されてよい。例えば、ユーザが指定した地方に関係なく対戦が可能なイベントであってもよいし、ユーザ同士で協力してゲームを進めるイベントであってもよいし、ユーザが１人だけでプレイする形式のイベントであってもよい。

また例えば、制限部１０３は、強化確定ボタンＢ２４１の選択回数が上限に達した場合に、強化確定ボタンＢ２４１の選択自体は受けつけるが、ボーナスパラメータを更新する処理に反映させないようにしてもよい。例えば、ボーナス用パラメータを更新する処理がサーバ３０側で実行される場合には、ゲーム端末１０が強化確定ボタンＢ２４１の選択は受け付けるが、強化確定ボタンＢ２４１の選択を受け付けたことを示すデータをサーバ３０に送信しないようにしてもよい。また例えば、ゲーム端末１０が強化確定ボタンＢ２４１の選択を受け付けたことを示すデータをサーバ３０に送信するが、サーバ３０側で当該データを受信したとしても、それに応じてボーナスパラメータを更新する処理を実行しない（受信したデータを無視する）ようにしてもよい。

また例えば、ゲーム端末１０とサーバ３０において、各機能が分担されてもよい。この場合、各機能ブロックの処理結果が、ゲーム端末１０とサーバ３０との間で送受信されるようにすればよい。

例えば、ゲーム端末１０において実現されるものとして説明した各機能は、サーバ３０において実現されてもよい。例えば、サーバ３０によって、受付部１０１、表示制御部１０２、及び制限部１０３が実現されてもよい。この場合、これら各機能は、制御部３１を主として実現される。例えば、ゲーム端末１０は、強化確定ボタンＢ２４１が選択された場合に、サーバ３０に対し、その旨を示すデータを送信する。サーバ３０における受付部１０１は、当該データを受信することによって、強化確定ボタンＢ２４１の選択を受け付けるようにしてもよい。また例えば、サーバ３０における表示制御部１０２は、ゲーム端末１０に対し、イベント画像Ｇ２の表示データを送信することによって、イベント画像Ｇ２を表示部１５に表示させるようにしてもよい。また例えば、サーバ３０における制限部１０３は、ゲーム端末１０から強化確定ボタンＢ２４１が選択された旨の通知を受信しても、制限部１０３は、ボーナスパラメータを変化させないように制限してもよい。

また例えば、サーバ３０において実現されるものとして説明した各機能は、ゲーム端末１０において実現されてもよい。例えば、ゲーム端末１０によって、取得部３０１、通知部３０２、更新部３０３、ゲーム内通貨増減部３０４、及び効果発生部３０５が実現されてもよい。この場合、これら各機能は、制御部１１を主として実現される。例えば、ゲーム端末１０における取得部３０１は、サーバ３０に対し、イベントデータベースＤＢ１の参照要求を送信し、ネットワークＮ経由でボーナスパラメータを取得してもよいし、データ記憶部１００に記憶されたイベントデータＤＴ１に格納されたボーナスパラメータを取得してもよい。また例えば、通知部３０２は、サーバ３０から通知に必要なデータを取得し、イベント画像Ｇ２や他の画像を利用して、イベントの開催を通知してもよい。更新部３０３は、イベントデータＤＴ１に格納されたボーナスパラメータを更新してもよいし、サーバ３０に対し、ボーナスパラメータの更新要求を送信し、サーバ３０にボーナスパラメータを更新させるようにしてもよい。ゲーム内通貨増減部３０４は、データ記憶部１００に記憶されたゲーム内通貨に関する情報を更新してもよいし、サーバ３０に対し、ゲーム内通貨の更新要求を送信し、サーバ３０にゲーム内通貨を更新させるようにしてもよい。効果発生部３０５は、ポイントを増加させる処理をゲーム端末１０において実行する。

また例えば、ゲームシステムＳでは、取得部３０１、受付部１０１、及び更新部３０３以外の機能は省略してもよい。この場合、データベース記憶部３００は、ゲームシステムＳ外にあるデータベースサーバによって実現されるようにしてもよい。

また例えば、野球ゲームが実行される場合を説明したが、他のゲームに本発明に係る処理を適用してもよい。例えば、野球ゲーム以外のスポーツゲーム（例えば、サッカー、テニス、アメリカンフットボール、バスケットボール、バレーボール等を題材としたゲーム）に本発明に係る処理を適用してもよい。また例えば、スポーツゲームや育成ゲーム以外にも、アクションゲームやロールプレイングゲーム等のように、ゲーム形式・ジャンルを問わず種々のゲームに本発明に係る処理を適用してもよい。

［６．付記］
以上のような記載から、本発明は例えば以下のように把握される。

１）本発明の一態様に係るゲームシステム（Ｓ）は、ゲーム内のイベントの期間内に所定の効果を発生させるためのパラメータであって、前記イベントの期間外は前記効果の発生が制限されるイベント用パラメータを取得する取得手段（３０１）と、前記イベントの期間外において、前記イベント用パラメータを更新させるための操作を受け付ける受付手段（１０１）と、前記操作に基づいて、前記イベント用パラメータを更新させる更新手段（３０３）と、を含む。

１２）本発明の一態様に係るプログラムは、１）〜１１）の何れかに記載のゲームシステム（Ｓ）としてコンピュータを機能させる。

１３）本発明の一態様に係る情報記憶媒体は、１２）のプログラムを記録したコンピュータで読み取り可能な情報記憶媒体である。

１）、１２）、又は１３）に係る発明によれば、ユーザは、イベントの期間内で所定の効果を発生させるイベント用パラメータを、イベントの期間外でも更新することができるので、イベント開始まで待つことによって生じる不満感をユーザに与えることがない。

２）本発明の一態様では、前記ゲームシステム（Ｓ）は、前記イベントの開始前において、前記イベントの開催をユーザに通知する通知手段（３０２）を含み、前記受付手段（１０１）は、前記通知手段（３０２）による通知がなされてから、前記操作を受け付ける。２）の態様によれば、イベントの開催を通知してから操作を受け付けるので、常に操作を受け付ける場合に比べて、イベントの特別感をユーザに与えることができる。

３）本発明の一態様では、前記更新手段（３０３）は、前記イベントの開始前は、前記イベント用パラメータの上限を所定値未満に制限する。３）の態様によれば、イベントの開始前におけるイベント用パラメータに上限を設けることで、イベントの開始前にユーザの優劣がつきすぎてしまうことを防止できる。

４）本発明の一態様では、前記更新手段（３０３）は、前記イベントの開始後は、前記イベント用パラメータの上限の制限を解除する。４）の態様によれば、イベントの開始後はイベント用パラメータの上限を解除することで、イベントの期間内のユーザ間の競争を活性化することができる。

５）本発明の一態様では、前記更新手段（３０３）は、イベント用パラメータの上限を、前記イベントの開催の通知以降、時間経過に伴って段階的に増加させる。５）の態様によれば、イベント用パラメータの上限を、イベントの開催の通知以降、時間経過に伴って段階的に増加させることで、例えば、イベントの開始前にイベントへの期待感を段階的に大きくしたり、イベントの期間内においてイベントに変化を付けて飽きさせないようにしたりすることができる。

６）本発明の一態様では、ゲームシステム（Ｓ）は、前記イベントの開始前は、前記操作の回数を制限する制限手段（１０３）、を含む。６）の態様によれば、操作の回数を制限することで、イベントの開始前にユーザの優劣がつきすぎてしまうことを防止できる。

７）本発明の一態様では、前記制限手段（１０３）は、前記イベントの開始後は、前記制限を解除する。７）の態様によれば、イベントの開始後は、操作の制限を解除することで、イベントの期間内のユーザ間の競争を活性化することができる。

８）本発明の一態様では、前記制限手段（１０３）は、前記操作の回数の上限を、前記イベントの開催の通知以降、時間経過に伴って段階的に増加させる。８）の態様によれば、イベントの開催の通知以降、時間経過に伴って段階的に操作の回数の上限を増加させることで、例えば、イベントの開始前にイベントへの期待感を段階的に大きくしたり、イベントの期間内においてイベントに変化を付けて飽きさせないようにしたりすることができる。

９）本発明の一態様では、前記ゲームシステム（Ｓ）は、前記イベントの期間前に、前記操作を受け付けるためのイベント画像を表示手段（１５）に表示させる表示制御手段（１０２）を更に含み、前記表示制御手段（１０２）は、前記イベント画像において、前記効果を識別可能に表示させる。９）の態様によれば、操作を受け付けるイベント画像において効果が識別可能に表示されるので、ユーザは、イベントが始まったときに発生する効果を確認しながら操作をすることができる。

１０）本発明の一態様では、前記受付手段（１０１）は、前記操作を繰り返し受け付け可能であり、前記更新手段（３０３）は、前記操作を受け付けるたびに、前記効果が大きくなるように前記イベント用パラメータを更新し、前記表示制御手段（１０２）は、前記イベント用パラメータが示す前記効果の大きさを示すように前記イベント画像の表示態様を変化させる。１０）の態様によれば、効果の大きさを示すようにイベント画像の表示態様が変化し、効果の大きさとイベント画像の表示態様に因果関係を持たせることができるので、イベントが始まったときに発生する効果の大きさを確認しやすくなる。

１１）本発明の一態様では、前記受付手段（１０１）は、前記イベントの期間内も前記操作を受け付け可能であり、前記更新手段（３０３）は、前記イベントの期間外における前記操作と、前記イベントの期間内における前記操作と、の両方に基づいて、前記イベント用パラメータを更新させる。１１）の態様によれば、イベントの期間内も操作を受け付け可能とすることで、開催中のイベントを継続してプレイさせる動機付けを与えることができる。

Ｓ ゲームシステム、Ｎ ネットワーク、１０ ゲーム端末、３０ サーバ、１１，３１ 制御部、１２，３２ 記憶部、１３，３３ 通信部、１４ 操作部、１５ 表示部、Ｇ１ メニュー画像、Ｇ２ イベント画像、Ｇ３ 対戦結果画像、ｔ１ エントリー開始時点、ｔ２ 開始時点、ｔ３ 終了時点、１００ データ記憶部、１０１ 受付部、１０２ 表示制御部、１０３ 制限部、３００ データベース記憶部、３０１ 取得部、３０２ 通知部、３０３ 更新部、３０４ ゲーム内通貨増減部、３０５ 効果発生部、ＤＢ１ イベントデータベース、ＤＢ２ ボーナスデータベース、ＤＴ１ イベントデータ、Ａ１０，Ａ２０，Ａ２１，Ａ２３，Ａ２５，Ａ２６，Ａ３０，Ａ３１，Ａ２２５，Ａ２３０，Ａ２３２ 表示領域、Ｂ２２ ボーナスボタン、Ｂ２７ 試合ボタン、Ｇ１１，Ｇ１２，Ｇ１３，Ｇ１２０，Ｇ１２１ 選択画像、Ｐ２４ ポップアップ、Ｂ２１０ エントリーボタン、Ｂ２１１ 確認ボタン、Ｂ２１２ 変更ボタン、Ｂ２３１ 強化ボタン、Ｂ２４０ キャンセルボタン、Ｂ２４１ 強化確定ボタン。

Claims (11)

1. ゲーム内のイベントの期間内に所定の効果を発生させるためのパラメータであって、前記イベントの期間外は前記効果の発生が制限されるイベント用パラメータを取得する取得手段と、
   前記イベントの開始前において、前記イベントの開催をユーザに通知する通知手段と、
   前記イベントの期間外において、前記通知手段による通知がなされてから、前記イベント用パラメータを更新させるための操作を受け付ける受付手段と、
   前記操作に基づいて、前記イベント用パラメータを更新させる更新手段と、
   を含むゲームシステム。
2. 前記更新手段は、前記イベントの開始前は、前記イベント用パラメータの上限を所定値未満に制限する、
   請求項１に記載のゲームシステム。
3. 前記更新手段は、前記イベントの開始後は、前記イベント用パラメータの上限の制限を解除する、
   請求項２に記載のゲームシステム。
4. 前記更新手段は、イベント用パラメータの上限を、前記イベントの開催の通知以降、時間経過に伴って段階的に増加させる、
   請求項２又は３に記載のゲームシステム。
5. 前記ゲームシステムは、前記イベントの開始前は、前記操作の回数を制限する制限手段、
   を含む請求項１〜４の何れかに記載のゲームシステム。
6. 前記制限手段は、前記イベントの開始後は、前記制限を解除する、
   請求項５に記載のゲームシステム。
7. 前記制限手段は、前記操作の回数の上限を、前記イベントの開催の通知以降、時間経過に伴って段階的に増加させる、
   請求項５又は６に記載のゲームシステム。
8. 前記ゲームシステムは、前記イベントの期間前に、前記操作を受け付けるためのイベント画像を表示手段に表示させる表示制御手段を含み、
   前記表示制御手段は、前記イベント画像において、前記効果を識別可能に表示させる、
   請求項１〜７の何れかに記載のゲームシステム。
9. ゲーム内のイベントの期間内に所定の効果を発生させるためのパラメータであって、前記イベントの期間外は前記効果の発生が制限されるイベント用パラメータを取得する取得手段と、
   前記イベントの期間前に、前記イベント用パラメータを更新させるための操作を受け付けるためのイベント画像を表示手段に表示させ、前記イベント画像において、前記効果を識別可能に表示させる表示制御手段と、
   前記イベントの期間外において、前記操作を受け付ける受付手段と、
   前記操作を受け付けるたびに、前記効果が大きくなるように前記イベント用パラメータを更新させる更新手段と、
   を含み、
   前記表示制御手段は、前記イベント用パラメータが示す前記効果の大きさを示すように前記イベント画像の表示態様を変化させる、
   ゲームシステム。
10. 前記受付手段は、前記イベントの期間内も前記操作を受け付け可能であり、
    前記更新手段は、前記イベントの期間外における前記操作と、前記イベントの期間内における前記操作と、の両方に基づいて、前記イベント用パラメータを更新させる、
    請求項１〜９の何れかに記載のゲームシステム。
11. 請求項１〜１０の何れかに記載のゲームシステムとしてコンピュータを機能させるためのプログラム。

Images