JP2014140557A - サーバシステム - Google Patents

Abstract

【課題】共通イベントをクリアしたときに付与する特典に工夫を凝らすことで共通イベントの興趣を更に高めること。
【解決手段】複数のプレーヤが参加して、共通の敵キャラクタを倒すような共通イベントに係り付与される特典を、（１）共通イベント終了時における累積参加人数が多いほどより価値の高いものとし、（２）プレーヤがそのイベントに初めて参加したタイミングにおける累積参加人数が少ない程より価値の高いものとし、（３）イベント開催から早期ほど価値の高いものとし、（４）参加要請を受けてからプレーヤが要請されたイベントに初めて参加したタイミングまでの経過時間が少ない程より価値の高いもの、とする。
【選択図】図４

Description

本発明は、プレーヤ端末と通信接続され、複数のプレーヤが参加可能な共通イベントに参加したプレーヤにゲーム進行上の特典を付与する特典付与処理を実行するサーバシステムに関する。

近年、スマートフォンや携帯電話機などをプラットフォームとする非同期型のオンラインゲームが人気である。非同期型のオンラインゲームでは、基本的には各プレーヤがプレイしているゲームは独立して管理され、他のプレイとは非同期とされる。但し、一部に他プレーヤとの共闘などをテーマとした「共通イベント」が設けられたゲームがある。共通イベントは、クリアするためには複数のプレーヤの協力が前提とされる高難易度のサブゲームとされるのが一般的である。例えば、単独プレイでは到底相手のヒットポイントを「０」にできないようなとてつもなく強い共通敵キャラクタを倒すために共闘する内容のイベントである（同期型の共通イベントとしては、例えば特許文献１に記載がある）。

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

共通敵キャラクタのヒットポイント（いわゆるライフの値）が莫大であったとしても、非同期とはいえ、共通イベントに参加して共闘したプレーヤの延べ人数が多数に上れば、何れはその共通敵キャラクタのヒットポイントを「０」にして倒すことが可能となる。こうした性質の共通イベントに登場する共通敵キャラクタは俗に「レイドボス」と呼ばれる。そして、共通イベントをクリアすると、主ゲームのプレイでは得られない特典が、共通イベントに参加したプレーヤへ与えられることがある。特典の特殊性も相まってプレーヤ同士が共闘・協働するこうした共通イベントは非同期型のオンラインゲームにあって花形イベントであり、ユーザに訴求する重要な要素とされる。

本発明は、上述した技術背景及び課題に鑑みてなされたものであり、共通イベントをクリアしたときに付与する特典に工夫を凝らすことで共通イベントの興趣を更に高めることを目的とする。なお、本発明の課題は、ＳＮＳ（ソーシャル・ネットワーキング・サービス）ゲームに限られるわけではないのは勿論である。

上述した課題を解決するための第１の発明は、プレーヤ端末と通信接続され、複数のプレーヤが参加可能な共通イベントに参加したプレーヤにゲーム進行上の特典を付与する特典付与処理を実行するサーバシステムであって、前記共通イベントに参加したプレーヤの参加履歴を管理する参加履歴管理手段（例えば、図１の本体装置１１０１、制御基板１１５０、図６のサーバ処理部２００ｓ、ゲーム管理部２１０、参加履歴管理部２１６、図１４のステップＳ２８、図１５のステップＳ４０）と、所与のタイミングでの前記参加履歴に基づいて前記特典の内容を可変に決定する第１の特典決定手段（例えば、図１の本体装置１１０１、制御基板１１５０、図６のサーバ処理部２００ｓ、ゲーム管理部２１０、特典決定部２２０、図１５のステップＳ５０）とを備え、前記第１の特典決定手段は、前記共通イベントの終了タイミングでの累積参加人数に基づいて前記特典の内容を可変に決定する手段（例えば、図６の参加人数基準決定部２２２、図９のクリア時累積参加人数基準特典データ５７０、図１６のステップＳ１０６）を有する、サーバシステムである。

第１の発明によれば、共通イベントの参加プレーヤへ与えられる特典の内容を、参加履歴に基づいて、つまりプレーヤの参加態様に応じて可変することができる。そして、共通イベントに参加した人数に応じて特典内容を変えることができる。

更には、第２の発明として、前記第１の特典決定手段が、前記共通イベントの終了タイミングでの累積参加人数が多くなるほど、前記特典の内容を次第に価値の高い内容にする手段（例えば、図６の参加人数基準決定部２２２、図９のクリア時累積参加人数基準特典データ５７０、図１６のステップＳ１０６）を有する、第１の発明のサーバシステムを構成することができる。

第２の発明によれば、第１の発明と同様の効果が得れる。そして、イベントに参加した人数が多ければ多い程、価値の高い特典が付与されるので、多くの友人を共通イベントに誘う動機付けになり、共通イベントを一層魅力的にすることができる。

また更に、第３の発明として、前記第１の特典決定手段が、当該参加プレーヤが前記共通イベントに参加したタイミングでの累積参加人数に基づいて、当該参加プレーヤに付与する前記特典の内容を可変に決定する手段（例えば、図６の参加人数基準決定部２２２、図１０の初回時累積参加人数基準特典データ５７２、図１６のステップＳ１０８）を有する、第１又は２の発明の何れかのサーバシステムを構成することができる。

第３の発明によれば、第１又は第２の発明と同様の効果が得られる。加えて、特典が与えられる参加プレーヤが、イベントに参加したタイミングで求められる累積参加人数に基づいて特典内容を変えることができる。例えば、累積参加人数が少ない程、より価値の高い特典とするならば、まだ皆が参加していない共通イベントに積極的に参加すれば、その分良い思いをすることができることとなり、共通イベントへの早期参加を促す効果が期待できる。

また更には、第４の発明として、前記共通イベントは、共通敵キャラクタと対戦するイベントであって、第１の共通敵キャラクタと対戦する第１の共通イベントと、前記第１の共通敵キャラクタよりも強い第２の共通敵キャラクタと対戦する第２の共通イベントとが有り、前記第１の特典決定手段が、前記第１の共通イベントに係る前記特典よりも、前記第２の共通イベントに係る前記特典の方が価値の高い内容の特典とする手段（例えば、図６の特典決定部２２０、図８の共通イベント初期設定データ５５２、クリア時累積参加人数基準特典データ５７０、初回時累積参加人数基準特典データ５７２、図１６のステップＳ１０６〜Ｓ１０８）を有する、第１〜第３の何れかの発明のサーバシステムを構成できる。

第４の発明によれば、第１〜第３の発明の何れかと同様の効果が得られる。加えて、より強い共通敵キャラクタほどより価値の高い特典が得られるようになる。

第５の発明は、当該参加プレーヤが前記共通イベントに参加した日時に基づいて当該参加プレーヤに付与する前記特典の内容を可変に決定する第２の特典決定手段（例えば、図１の本体装置１１０１、制御基板１１５０、図６のサーバ処理部２００ｓ、ゲーム管理部２１０、特典決定部２２０、参加日時基準決定部２２４、図１１の初回参加日時基準特典データ５７４、図１６のステップＳ１１０）、を更に備えた第１〜第４の何れかの発明のサーバシステムである。

第５の発明によれば、第１〜第４の発明の何れかと同様の効果が得られる。加えて、参加プレーヤが共通イベントに参加した日時に基づいても特典内容を変えることができる。

より具体的には、第６の発明として、前記第２の特典決定手段が、前記共通イベントの初回参加日時が初期である場合と、終期である場合とで前記特典の内容を異なる内容とする手段（例えば、図６の参加日時基準決定部２２４、図１１の初回参加日時基準特典データ５７４、図１６のステップＳ１１０）を有する、第５の発明のサーバシステムを構成できる。

第６の発明によれば、第５の発明と同様の効果が得られるとともに、共通イベントの初回参加日時が初期と後期とでは、特典内容を変えることができる。例えば、後期よりも初期の方がより価値の高い特典とするならば、できるだけ早く共通イベントに積極的に参加すれば、その分良い思いをすることができることとなり、共通イベントへの早期参加を促す効果が期待できる。

第７の発明は、一の参加プレーヤから他のプレーヤに前記共通イベントへ参加を要請する旨の参加要請通知をする参加要請通知手段（例えば、図１の本体装置１１０１、制御基板１１５０、図６のサーバ処理部２００ｓ、ゲーム管理部２１０、参加要請制御部２２８、図１５のステップＳ４４）と、前記参加要請から、前記他のプレーヤが前記共通イベントに参加するまでの経過時間に基づいて、当該他のプレーヤに付与する前記特典の内容を可変に決定する第３の特典決定手段（例えば、図１の本体装置１１０１、制御基板１１５０、図６のサーバ処理部２００ｓ、ゲーム管理部２１０、特典決定部２２０、要請後経過時間基準決定部２２６、図１２の要請後経過時間基準特典データ５７６、図１６のステップＳ１１２）と、を更に備えた第１〜第６の何れかの発明のサーバシステムである。

第７の発明によれば、第１〜第６の発明の何れかと同様の効果が得られる。加えて、参加要請を受けてから要請に応じてイベントに参加するまでに要した時間に応じて特典の内容を決定できる。

より具体的には、第８の発明として、前記第３の特典決定手段が、前記経過時間が第１の経過時間の場合に前記他のプレーヤに付与する前記特典の内容を、前記第１の経過時間より長い第２の経過時間の場合に付与する前記特典よりも価値の高い内容とする手段（例えば、図６の要請後経過時間基準決定部２２６、図１２の要請後経過時間基準特典データ５７６、図１６のステップＳ１１２）を有する、第７の発明のサーバシステムを構成することができる。

第８の発明によれば、第７の発明と同様の効果が得られるとともに、できるだけ早く要請に応じればその分良い特典となる。つまり、積極的に共通イベントに参加すればその分報われることになるので早期参加の誘因となる。

ゲームシステムの構成の一例を示す図。 プレーヤ端末の構成例を示す図。 ゲーム内に挿入される共通イベントの概要についての説明図。 特典内容の決定の原理を説明するための図。 プレーヤ端末の機能構成例を示す機能ブロック図。 サーバシステムの機能構成例を示す機能ブロック図。 アカウント管理データのデータ構成の一例を示す図。 共通イベント初期設定データのデータ構成の一例を示す図。 クリア時累積参加人数基準特典データのデータ構成の一例を示す図。 初回時累積参加人数基準特典データのデータ構成の一例を示す図。 初回参加日時基準特典データのデータ構成の一例を示す図。 要請後経過時間基準特典データのデータ構成の一例を示す図。 共通イベント管理データのデータ構成の一例を示す図。 サーバシステムによる共通イベントに係る処理の流れを説明するためのフローチャート。 図１４より続くフローチャート。 特典付与処理の流れを説明するためのフローチャート。 変形例におけるプレーヤ端末の機能構成例を示す機能ブロック図。 変形例におけるサーバシステムの機能構成例を示す機能ブロック図。 変形例におけるサーバシステムによる共通イベントに係る処理の流れを説明するためのフローチャート。 図１９より続くフローチャート。

〔第１実施形態〕
本発明を適用した第１実施形態として、共通イベントが発動されるオンラインゲームの例について説明する。

［システムの構成の説明］
図１は、本実施形態におけるゲームシステムの構成の一例を示す図である。本実施形態のゲームシステムは、通信回線１に接続することのできるサーバシステム１１００と、プレーヤ２（２ａ，２ｂ，２ｃ，・・・）毎に用意されるプレーヤ端末１５００（１５００ａ，１５００ｂ，１５００ｃ，・・・）とを備えて構成される。

通信回線１は、データ通信が可能な通信路を意味する。すなわち、通信回線１とは、直接接続のための専用線（専用ケーブル）やイーサネット（登録商標）等によるＬＡＮ（Local Area Network）の他、電話通信網やケーブル網、インターネット等の通信網を含む意味であり、また、通信方法については有線／無線を問わない。

サーバシステム１１００は、単数又は複数のサーバシステムや記憶装置等を含んで構成され、コミュニティ型ウェブサイトやオンラインゲームを運営するための各種サービスを提供し、ゲーム実行に必要なプレイデータの管理や、クライアントプログラム及び各種データ等を配信することができる。

本実施形態では、サーバシステム１１００は、本体装置１１０１と、キーボード１１０６と、タッチパネル１１０８と、ストレージ１１４０とを備える。本体装置１１０１には、制御基板１１５０が搭載されている。制御基板１１５０には、ＣＰＵ（Central Processing Unit）１１５１やＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）などの各種マイクロプロセッサ、ＡＳＩＣ（Application Specific Integrated Circuit）、ＶＲＡＭやＲＡＭ，ＲＯＭ等の各種ＩＣメモリ１１５２、通信装置１１５３が搭載されている。

サーバシステム１１００は、例えば、（１）アカウント登録やプレーヤキャラクタの初期設定、及びログイン／ログアウトに関係する処理を担うアカウント管理サーバシステムとしての機能と、（２）ゲーム内で使用するアイテムを購入できるオンラインショッピングサービス処理を担うオンラインショッピングサーバとしての機能と、（３）ログインしてゲームに参加中のプレーヤ端末１５００へゲームを実行するのに必要なデータを随時管理・配信するゲーム管理サーバシステムとしての機能と、を有して構成される。
図示の例では、サーバシステム１１００は単体として記しているが、サーバシステム１１００には複数のブレードサーバを搭載し、それぞれが上述の３種の機能を分担して担い、相互に内部バスを介してデータ通信可能に接続された構成であっても良い。或いは、離れた場所に設置された独立した複数のサーバを通信回線１を介してデータ通信させることで、全体としてサーバシステム１１００として機能させる構成であっても良い。

図２は、プレーヤ端末１５００の構成例を示す正面外観図である。プレーヤ端末１５００は、プレーヤが試用するコンピュータであり、電子装置（電子機器）である。例えば、スマートフォンや、携帯型ゲーム装置、据置型家庭用ゲーム装置、業務用ゲーム装置、パソコン、タブレット型コンピュータなどにより実現される。そして、通信回線１に接続してサーバシステム１１００にアクセスすることができる。

本実施形態におけるプレーヤ端末１５００は、方向入力キー１５０２と、ホームキー１５０４と、画像表示デバイス兼接触位置入力デバイスとして機能するタッチパネル１５０６と、スピーカ１５１０と、マイク１５１２と、制御基板１５５０と、コンピュータ読み出し可能な情報記憶媒体であるメモリカード１５４０からデータを読み書きできるメモリカード読取装置１５４２と、を備える。その他、図示されていない内蔵バッテリーや電源ボタン、音量調節ボタン等が設けられている。

制御基板１５５０は、ＣＰＵ１５５１やＧＰＵ、ＤＳＰなどの各種マイクロプロセッサ、ＡＳＩＣ、ＶＲＡＭやＲＡＭ，ＲＯＭ等の各種ＩＣメモリ１５５２と、携帯電話基地局や無線ＬＡＮ基地局などと無線接続するための無線通信モジュール１５５３とが搭載されている。その他、タッチパネル１５０６のドライバ回路、方向入力キー１５０２及びホームキー１５０４からの信号を受信する回路、スピーカ１５１０へ音声信号を出力する出力アンプ回路、マイク１５１２で集音した音声の信号を生成する入力信号生成回路、メモリカード読取装置１５４２への信号入出力回路といった所謂Ｉ／Ｆ回路１５５４（インターフェース回路）等が搭載されている。これら制御基板１５５０に搭載されている各要素は、それぞれバス回路などを介して電気的に接続され、データの読み書きや信号の送受信が可能に接続されている。

制御基板１５５０は、サーバシステム１１００から取得したゲームクライアントプログラムやデータをＩＣメモリ１５５２に一時記憶する。そして、プログラムを実行して演算処理を実行し、方向入力キー１５０２やホームキー１５０４、タッチパネル１５０６からの操作入力に応じてプレーヤ端末１５００の各部を制御してゲームを実行する。尚、本実施形態では、プレーヤ端末１５００は必要なプログラムや各種設定データをサーバシステム１１００から取得する構成としているが、別途入手したメモリカード１５４０から読み出す構成としても良い。

本実施形態では、プレーヤはサーバシステム１１００が提供するサービスを利用するには、所定の手続きを行ってユーザアカウント（以降、単に「アカウント」と言う。）を取得する必要がある。取得したアカウントと対応づけられるパスワードをもってログインすることで、アイテムのオンライショッピングや、登録ユーザ間でのメッセージ交換、フレンドプレーヤ（図１参照）の管理、ゲームプレイなどのサービスが利用可能となる。

［主ゲームの概要と共通イベントについての説明］
本実施形態の主ゲームはシングルプレイ型のオンラインゲームである。「主」ゲームとの呼称は、共通イベントと区別するための便宜的なものであり、「ゲーム」であることに変わりはない。各プレーヤ２（２ａ，２ｂ）は、同じゲーム世界の設定であるが相互には非同期で、互いに独立したゲーム空間内で自身のプレーヤキャラクタ４（４ａ，４ｂ）を操作してシングルプレイする。マルチプレイ型オンラインゲームのように両プレーヤのプレーヤキャラクタが同じゲーム空間を共有することはないこととする。

本実施形態の主ゲームはＲＰＧタイプとする（勿論、本発明は主ゲームがＲＰＧ以外のジャンルであっても適用できる。）。主ゲームでは、プレーヤキャラクタ４（４ａ、４ｂ）はゲーム世界を旅しつつ遭遇した敵ＮＰＣと交戦を繰り返す。プレーヤキャラクタ４（４ａ、４ｂ）及び敵ＮＰＣにはそれぞれヒットポイント（ＨＰ：ライフポイント、体力値などと同義）が設定され、相手の攻撃を受けるとダメージ量に応じてヒットポイントが減らされる。ヒットポイントが「０」になると、そのキャラクタは死亡・撃破扱いとなる。プレーヤキャラクタのヒットポイントが「０」になればゲームオーバである。プレーヤキャラクタ４及び敵ＮＰＣのヒットポイントは、各プレーヤのそれぞれのゲームプレイ毎に管理される。

図３は、ゲーム内に挿入（発動）される共通イベントの概要についての説明図である。
主ゲームのプレイ中にイベント発動条件を満たすとサブゲームである「共通イベント」への参加権がプレーヤへ付与される。イベント発動条件は適宜設定可能であるが、例えば、ゲームマップ上の所定エリアにプレーヤキャラクタ４が到達すると、抽選処理が行われて一定の確率で当選するとイベント発動条件を満たすと判定され、参加権が付与されることとしてもよい。主ゲームのゲーム画面には、共通イベントに参加可能になった旨に通知が行われる。そして、プレーヤ２がプレーヤ端末１５００にて所定の共通イベントの選択・参加操作を行うと、当該共通イベントが実行される。

一度参加権を得た共通イベントについては、プレーヤは参加／不参加を任意に選択することができる。例えば、参加権を獲得した旨の通知が行われたタイミングで参加もできるし、参加権を得ている共通イベントのリストから何れかを選択して任意のタイミングで参加することもできる。そして、その共通イベントがクリアされるまでは何度でも参加できる。例えば、敵ボスＮＰＣ６へ所定回数の攻撃をした場合、或いは敵ボスＮＰＣ６の攻撃を受けてプレーヤキャラクタが戦闘不能になると、敵ボスＮＰＣ６のヒットポイントが「０」になっていなくとも、すなわちイベントがクリア条件を満たしていなくともその時の１回分のイベントへの参加は終了する。共通イベント自体はクリアされていないので、参加権を持ってさえいれば再挑戦が可能である。

共通イベントへの参加権は、主ゲームのプレイ中にイベント発動条件を満たすこと以外でも付与される。本実施形態では、共通イベントへの参加権を既に得たプレーヤ（例えば、プレーヤ２ａ）は、別のプレーヤ（例えば、プレーヤ２ｂ）へ当該共通イベントへの参加要請をすることができる。そして、この参加要請を受けた別のプレーヤ（プレーヤ２ｂ）は、自身の主ゲームにおいてイベント発動条件を満たしていなくとも、共通イベントへの参加権を得る。すなわち、別プレーヤ２ｂがプレーヤ端末１５００にて所定の共通イベントの選択・参加操作を行うと、参加要請をしたプレーヤ２ａと同じ共通イベントに参加できる。こうした参加要請は、公知のオンラインゲーム等で言うところの「応援要請」「救援要請」などに該当する。

共通イベントは、クリアするために複数のプレーヤの協力が前提とされる高難易度イベントである。時に期間限定のイベントとされる。
本実施形態では、例えば、ヒットポイントがとても高く、且つ時間経過とともに自己回復能力を有する特別に強い敵ボスＮＰＣ６（共通敵キャラクタ）が設定される。単独プレイで戦っていても敵ボスＮＰＣ６の自己回復を上回るダメージを与えることは容易ではない。図３の例では敵ボスＮＰＣ６を単数として描いているが、敵ボスＮＰＣ６は多数の敵ＮＰＣで構成された「群」でも良い。例えば、自己増殖する敵ＮＰＣの群で構成する場合には、それぞれのヒットポイントはそれほど高くなくとも、その数の多さによって単独プレイによる攻略を困難にする。いずれにせよ、共通イベントは単独プレイでのクリアは極めて難しい。

しかし、敵ボスＮＰＣ６のヒットポイントは、通常のゲームプレイ中に登場するＮＰＣの扱いとは異なり、サーバシステム１１００によりプレーヤ間のゲーム世界を跨いで共通のヒットポイントとして管理される。すなわち、プレーヤ２（２ａ）が敵ボスＮＰＣ６を攻撃してダメージを与えると、他のプレーヤ２（２ｂ）が敵ボスＮＰＣ６と戦う場合、その敵ボスＮＰＣ６のヒットポイントには、先のプレーヤ２（２ａ）が与えたダメージの影響が現れる。従って、複数のプレーヤ２（２ａ，２ｂ）が同じ共通イベントに参加し、（非同期ではあるが）共通の敵ボスＮＰＣ６を攻撃することで、敵ボスＮＰＣ６の自己回復能力を上回るダメージを与え続け、ついにはそのヒットポイントを「０」にして倒すことが可能となる。

このような敵ボスＮＰＣ６は俗に「レイドボス」と呼ばれる。共通イベントをクリアすると、主ゲームのプレイでは得られない特典（「報酬」とも言い換えられる。）が、共通イベントに参加したプレーヤ２（２ａ，２ｂ）へ与えられる。特典の特殊性も相まってプレーヤ同士が共闘・協働する共通イベントは、非同期型のオンラインゲームにあって花形イベントとされる。本実施形態では、共通イベントをクリアしたときの特典に工夫を凝らすことで共通イベントの興趣を更に高める。

［イベントクリア時の特典付与についての説明］
図４は、本実施形態における特典内容の決定の原理を説明するための図である。
本実施形態の共通イベントのクリアにより与えられる特典は、共通イベントの実行にともなって記憶・管理される各プレーヤの参加履歴（どのプレーヤが何時参加し、どの程度の貢献をしたか（敵ボスＮＰＣ６にダメージを与えたかなどの情報））に基づいて可変に決定される。特典の内容は、ゲーム内通貨や経験値などに代表される「ポイント」でも良いし、アイテムの種類や数、利用可能な味方ＮＰＣの種類や数、当選確率などでも良く、ゲーム内容に応じて適宜設定することができる。

特典を決定する原理は幾つかある。
第１の原理として、累積参加人数に基づいて特典を可変に決定する。累積参加人数は、参加したアカウントの累計（同一アカウントは何回参加しても１回として算出した累計）であっても良いし、延べ人数に相当する累計（同一アカウントでＮ回参加した場合にはＮを加算した累計）であっても良い。

具体的には、図４（１）のように、共通イベントの終了タイミングでの累積参加人数に基づいて特典の内容を可変に決定される。そして、本実施形態では、累計参加人数が多くなるほど、特典の内容を次第に価値の高い内容にする。プレーヤの立場になれば、参加者を増やせば増やすほど良い特典が得られるので、例えば友人などに積極的に参加要請をするようになる。すると、参加要請に呼応して他のプレーヤも共通イベントへ次々に参加し、ついにはイベントはおおいに盛り上がり、速やかにクリアできて、良い特典が得られる。つまり、共通イベントへの参加を促す効果を生む。尚、図４の例では、特典内容は、累積参加人数に対して比例して価値が上昇するレートを示しているが、レートはこれに限らず適宜設定可能である。例えば、段階的に上昇する構成でも良い。

また、図４（２）に示すように、特典内容は参加プレーヤが共通イベントに参加したタイミングでの累積参加人数に基づいて、当該参加プレーヤに付与する特典の内容を可変に決定する。本実施形態では特に、その参加プレーヤが初回参加したタイミングにおける累積参加人数が、少ない程ほど、その参加プレーヤに付与される特典の価値が高くなるような特典に決定する。プレーヤの立場から見れば、共通イベントの参加権を取得したならばできるだけ速やかに参加した方がより有益となる。ファーストアタック賞（敵ボスＮＰＣ６へ最初にダメージを与えたプレーヤに与えられる特典・報酬のこと）はなかなか得られなくとも、早く参加すればその分良い特典が得られることになるので、早期参加の誘因として作用する。尚、図４の例では、累積参加人数に反比例して価値が低下する例を示しているが、段階的に低下する構成も可能である。

第２の原理として、特典を受ける参加プレーヤの参加日時に基づいて特典を可変に決定する。例えば、共通イベントへの初回参加日時が初期である場合と終期である場合とで特典の内容を異なる内容とする。本実施形態では、図４（３）に示すように、ある参加プレーヤが共通イベントに初めて参加したタイミング（初回参加日時）において、当該共通イベントの開始日時からの経過時間が、大きくなるに従って特典の価値が低下するような特典に決定する。尚、ここで言う「共通イベントの開始日時」は、その共通イベントに何れかのプレーヤが最初に参加した初回参加日時を起点としても良いし、共通イベントを発動した日時（開催日時）を起点としても良い。
プレーヤの立場から見れば、共通イベントの参加権を取得したならばできるだけ速やかに参加した方が有益となる。また、「参加要請」を受けたならばできるだけ速やかに参加した方がプレーヤ２にとって有益となる。

第３の原理として、参加要請を受けた参加プレーヤが、参加要請を受けた時点から実際に最初に参加するまでの経過時間に基づいて特典を可変に決定する。
具体的には、図４（３）に示すように、参加要請を受けた時点からの経過時間が大きくなるに従って特典の価値が低下するような特典に決定する。
プレーヤの立場から見れば、友人からの要請にできるだけ早く応じることで、友人と（相手は見えてなくとも）一緒にゲームを楽しんでいる気分を楽しめる上に、早く応じた分だけ良い報いがあり、良いことずくめとなる。つまり、積極的に共通イベントに参加すればその分報われることになるので早期参加の誘因となる。尚、図４の例では、経過時間に反比例して価値が低下する例を示しているが、段階的に低下する構成も可能である。

本実施形態では、このように特典内容を可変に決定することで、共通イベントに係る興趣を高め、ゲームの魅力を高める。

［プレーヤ端末の機能構成の説明］
次に、本実施形態における機能構成について説明する。
図５は、本実施形態におけるプレーヤ端末１５００の機能構成の一例を示す機能ブロック図である。本実施形態のプレーヤ端末１５００は、操作入力部１００と、処理部２００と、音出力部３５０と、画像表示部３６０と、通信部３７０と、記憶部５００とを備える。

操作入力部１００は、プレーヤによって為された各種の操作入力に応じて操作入力信号を処理部２００に出力する。例えば、プッシュスイッチや、ジョイスティック、タッチパッド、トラックボール、加速度センサ、ジャイロ、ＣＣＤモジュール、などによって実現できる。図２の方向入力キー１５０２や、ホームキー１５０４、タッチパネル１５０６がこれに該当する。

処理部２００は、例えばＣＰＵやＧＰＵ等のマイクロプロセッサや、ＡＳＩＣ（特定用途向け集積回路）、ＩＣメモリなどの電子部品によって実現され、操作入力部１００や記憶部５００を含む各機能部との間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部１００からの操作入力信号、サーバシステム１１００から受信した各種データに基づいて各種の演算処理を実行して、プレーヤ端末１５００の動作を制御する。図２の制御基板１５５０がこれに該当する。そして、本実施形態における処理部２００は、プレーヤ端末演算部２０２と、音生成部２５０と、画像生成部２６０と、通信制御部２７０とを備える。

プレーヤ端末演算部２０２は、当該コンピュータをゲームプレイのための端末として機能させるための各種演算処理を実行する。例えば、本実施形態の構成では、操作信号送信制御部２０４と、ゲーム画面表示制御部２０６とを含む。また、計時、ソフトウェアキーボード等の機能に係る処理を行う。

操作信号送信制御部２０４は、操作入力部１００へ為された操作に応じて、各種データやリクエスト情報をサーバシステム１１００へ送信するための処理を実行する。

ゲーム画面表示制御部２０６は、サーバシステム１１００から受信した各種データに基づいてゲーム画面を表示するための制御を行う。例えば、本実施形態のオンラインゲームをウェブゲームとして実現するならば、ウェブブラウザをベースとしてＨＴＭＬとともにＪａｖａ（登録商標）やＣＳＳ（Cascading Style Sheets）を利用して能動的に画面表示を制御するウェブ技術や、Adobe（登録商標） Flashなどのプラグインを用いて実現できる。勿論、その他の方法でもかまわない。また、本実施形態では、ゲーム空間画像（例えば、３ＤＣＧなど）をサーバシステム１１００にて生成する構成とするが、ゲーム空間画像をプレーヤ端末１５００で生成する構成も可能である。その場合、ゲーム画面表示制御部２０６は、３ＤＣＧを生成するための仮想３次元空間に配置されたオブジェクトの制御を含むこととなる。

音生成部２５０は、例えばデジタルシグナルプロセッサ（ＤＳＰ）や、音声合成ＩＣなどのプロセッサ、音声ファイル再生可能なオーディオコーデック等によって実現され、ゲーム画面表示制御部２０６による処理結果に基づいてゲームに係る効果音やＢＧＭ、各種操作音の音信号を生成し、音出力部３５０に出力する。

音出力部３５０は、音生成部２５０から入力される音信号に基づいて効果音やＢＧＭ等を音出力する装置によって実現される。図２のスピーカ１５１０がこれに該当する。

画像生成部２６０は、例えば、ＧＰＵ、デジタルシグナルプロセッサ（ＤＳＰ）などのプロセッサ、ビデオ信号ＩＣ、ビデオコーデックなどのプログラム、フレームバッファ等の描画フレーム用ＩＣメモリ等によって実現される。画像生成部２６０は、ゲーム画面表示制御部２０６による処理結果に基づいて１フレーム時間（例えば１／６０秒）で１枚のゲーム画面の画像を生成し、生成したゲーム画面の画像信号を画像表示部３６０に出力する。
本実施形態では、例えば、サーバシステム１１００から受信したデータに基づいて、ゲーム画面の画像を生成することができる。また、ゲーム画面表示制御部２０６の制御に従って、ゲーム空間画像に各種情報表示体を合成することができる。もし、ゲーム空間画像の３ＤＣＧをサーバシステム１１００で生成せずプレーヤ端末１５００で生成する構成ではレンダリング処理を担うことができる。

画像表示部３６０は、画像生成部２６０から入力される画像信号に基づいて各種ゲーム画像を表示する。例えば、フラットパネルディスプレイ、ブラウン管（ＣＲＴ）、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。本実施形態では、図２のタッチパネル１５０６がこれに該当する。

通信制御部２７０は、データ通信に係るデータ処理を実行し、通信部３７０を介して外部装置とのデータのやりとりを実現する。通信部３７０は、通信回線１と接続して通信を実現する。例えば、無線通信機、モデム、ＴＡ（ターミナルアダプタ）、有線用の通信ケーブルのジャックや制御回路等によって実現され、図２の無線通信モジュール１５５３がこれに該当する。

記憶部５００は、処理部２００にプレーヤ端末１５００を統合的に制御させるための諸機能を実現するためのシステムプログラムや、ゲームプレイに必要なプログラム、各種データ等を記憶する。また、処理部２００の作業領域として用いられ、処理部２００が各種プログラムに従って実行した演算結果や操作入力部１００から入力される入力データ等を一時的に記憶する。こうした機能は、例えばＲＡＭやＲＯＭなどのＩＣメモリ、ハードディスク等の磁気ディスク、ＣＤ−ＲＯＭやＤＶＤなどの光学ディスクなどによって実現される。図２の制御基板１５５０が搭載するＩＣメモリ１５５２やメモリカード１５４０がこれに該当する。

本実施形態の記憶部５００は、システムプログラム５０１と、ゲームクライアントプログラム５０２とを記憶している。システムプログラム５０１は、プレーヤ端末１５００のコンピュータとしての入出力の基本機能を実現するためのプログラムである。ゲームクライアントプログラム５０２は、処理部２００が読み出して実行することによってプレーヤ端末演算部２０２としての機能を実現させるためのアプリケーションソフトであるが、システムプログラム５０１の一部として組み込まれた構成であっても良い。ゲームクライアントプログラム５０２は、オンラインゲームを実現する技術手法に応じて専用のクライアントプログラムであっても良いし、ウェブブラウザプログラム及びインタラクティブな画像表示を実現するプラグインなどにより構成するとしても良い。
尚、記憶部５００には、その他、ゲーム進行状況を記述するためのデータ、計時のためのカウンタ、各種フラグなどを適宜記憶することができる。

［サーバシステムの機能構成の説明］
図６は、本実施形態におけるサーバシステム１１００の機能構成例を示す機能ブロック図である。本実施形態におけるサーバシステム１１００は、操作入力部１００ｓと、サーバ処理部２００ｓと、画像表示部３６０ｓと、通信部３７０ｓと、サーバ記憶部５００ｓとを備える。

操作入力部１００ｓは、サーバの管理のための各種操作を入力するための手段であり、プレーヤ端末１５００の操作入力部１００と同様に実現される。図１のキーボード１１０６がこれに該当する。

サーバ処理部２００ｓは、例えばＣＰＵやＧＰＵ等のマイクロプロセッサや、ＡＳＩＣ（特定用途向け集積回路）、ＩＣメモリなどの電子部品によって実現され、操作入力部１００ｓやサーバ記憶部５００ｓを含む各機能部との間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部１００ｓからの操作入力信号、プレーヤ端末１５００から受信したデータに基づいて各種の演算処理を実行して、サーバシステム１１００の動作を統合的に制御する。そして、本実施形態では、アカウント管理部２０８と、ゲーム管理部２１０と、画像生成部２６０ｓと、通信制御部２７０ｓとを含む。

アカウント管理部２０８は、アカウント登録手続きに係る処理を行う。登録手続きを経たプレーヤへ固有のアカウントを発給し、アカウント管理データ５１０を生成してその管理を行う。また、ログインに関する処理を実行する。

ゲーム管理部２１０は、ゲーム進行に関する処理を実行する。本実施形態では、主ゲーム進行制御部２１２と、共通イベント制御部２１４と、特典決定部２２０と、参加要請制御部２２８と、特典付与制御部２３０と、計時部２３２とを含む。

主ゲーム進行制御部２１２は、本実施形態における主たるゲーム、すなわち共通イベントが挿入される側のゲームの進行制御と、プレイ結果の反映に係る処理を実行する。これに伴うアカウント毎に実行される主ゲームの進行状況を記述する各種データは、サーバ記憶部５００ｓにプレイデータ５７８としてアカウント別に記憶・管理される。また、主ゲーム進行制御部２１２は共通イベントの発動判定も行う。

共通イベント制御部２１４は、発動された共通イベントの進行制御を行う。これに伴うアカウント毎に実行される主ゲームの進行状況を記述する各種データは、サーバ記憶部５００ｓに共通イベント管理データ５８０としてイベント別に記憶・管理される。共通イベント管理データ５８０には、例えば各プレーヤの参加履歴なども含まれる。よって、共通イベント制御部２１４は、発動された共通イベントへの参加履歴を管理する参加履歴管理部２１６を有すると言える。

特典決定部２２０は、共通イベントがクリアした時に付与する特典（報酬）を可変に決定する。本実施形態では、共通イベントへの参加人数に基づいて特典を決定する参加人数基準決定部２２２（図４（１）、（２）に対応）と、特典を受けるプレーヤが参加した日時に基づいて特典を決定する参加日時基準決定部２２４（図４（３）に対応）と、参加要請を受けた日時を起点とする経過時間に基づいて特典を決定する要請後経過時間基準決定部２２６（図４（４）に対応）と、を有する。

参加要請制御部２２８は、一のプレーヤから他のプレーヤへの参加要請に係る制御を実行する。本実施形態では、一のプレーヤにより選択された他プレーヤとともに、自動的に選択した他プレーヤにも参加要請をする。後者の自動選択では、例えば、参加要請時にログインしているプレーヤを優先的に選択したり、更にその中から課金額や課金頻度の高いプレーヤを優先的に選択する。自動選択の数は、共通イベントの難易度、本実施形態で言えば、敵ボスＮＰＣ６のレベルや初期ヒットポイント、攻撃力など強さを現わすパラメータ値が大きい程、多くすることができる。参加要請を受けたプレーヤは、共通イベントへの参加権を付与されることになるので参加権付与部と言い換えることもできる。本実施形態では、参加要請を受ける側のアカウントに対応づけて参加要請の情報を設定し、当該アカウントがログインしたときに参照可能にする。勿論、参加要請の形態はこれに限らず、参加要請先のプレーヤのプレーヤ端末１５００へ参加要請の信号を送信するとしても良い（例えば電子メールでもよいし、プッシュ通知としてもよい）。

特典付与制御部２３０は、特典決定部２２０で決定された内容の特典を、共通イベントに参加したプレーヤへ付与する処理を行う。

計時部２３２は、システムクロックを利用して日時や経過時間などの計時に係る処理を実行する。

画像生成部２６０ｓは、サーバシステム１１００の保守に関する画像を生成し、画像表示部３６０ｓへ出力することができる。また、本実施形態では、ゲーム空間画像などプレーヤ端末１５００で表示させる各種画像の生成処理も実行することができる。

画像表示部３６０ｓは、画像生成部２６０ｓから入力される画像信号に基づいてシステム管理のための各種画像を表示する。例えば、フラットパネルディスプレイ、ブラウン管（ＣＲＴ）、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。図１のタッチパネル１１０８がこれに該当する。

通信制御部２７０ｓは、データ通信に係るデータ処理を実行し、通信部３７０ｓを介して外部装置とのデータのやりとりを実現する。

通信部３７０ｓは、通信回線１と接続して通信を実現する。例えば、無線通信機、モデム、ＴＡ（ターミナルアダプタ）、有線用の通信ケーブルのジャックや制御回路等によって実現される。図１の通信装置１１５３がこれに該当する。

サーバ記憶部５００ｓは、サーバ処理部２００ｓにサーバシステム１１００を統合的に制御させるための諸機能を実現するためのシステムプログラムや、ゲームを管理するために必要なプログラム、各種データ等を記憶する。また、サーバ処理部２００ｓの作業領域として用いられ、サーバ処理部２００ｓが各種プログラムに従って実行した演算結果などを一時的に記憶する。この機能は、例えばＲＡＭやＲＯＭなどのＩＣメモリ、ハードディスク等の磁気ディスク、ＣＤ−ＲＯＭやＤＶＤなどの光学ディスクなどによって実現される。図１では本体装置１１０１が搭載するＩＣメモリ１１５２やハードディスクなどの情報記憶媒体、及びストレージ１１４０がこれに該当する。

そして、本実施形態のサーバ記憶部５００ｓは、サーバシステムプログラム５０５と、ゲーム管理プログラム５０６と、配信用ゲームクライアントプログラム５０７と、アカウント管理データ５１０と、ゲーム初期設定データ５５０と、プレイデータ５７８と、共通イベント管理データ５８０とを記憶する。また、その他、タイマやカウンタ、各種フラグなどの情報を適宜記憶することができる。

サーバシステムプログラム５０５は、サーバ処理部２００ｓが読み出して実行することでサーバシステム１１００にコンピュータとして必要な基本的な入出力機能を実現する為のシステムプログラムである。

ゲーム管理プログラム５０６は、サーバ処理部２００ｓが読み出して実行することで、アカウント管理部２０８とゲーム管理部２１０としての機能を実現させるためのプログラムである。

配信用ゲームクライアントプログラム５０７は、プレーヤ端末１５００へ提供されるゲームクライアントプログラム５０２（図５参照）のオリジナルである。

アカウント管理データ５１０は、アカウント管理部２０８により、アカウント登録したプレーヤ毎に用意される。
例えば図７に示すように、１つのアカウント管理データ５１０は、アカウント５１２と、フレンドリスト５１４と、プレーヤキャラクタ設定データ５１６と、セーブデータ５１８と、ログイン履歴５２４と、共通イベント参加権リスト５２６と、参加要請データ５３０と、を含む。

フレンドリスト５１４には、当該アカウントのプレーヤが親しい友人とみなした他プレーヤのアカウントのリストである。

プレーヤキャラクタ設定データ５１６は、プレーヤキャラクタ４を表示・動作させるために必要なデータが格納されている。

セーブデータ５１８は、これまでのゲームプレイの結果に関する各種データが格納される。例えば、主ゲームプレイ中に付与されるポイントの合計値を格納する所持ポイント５２０や、所持しているアイテムの情報を格納する所持アイテムリスト５２２、プレイ成績に応じて自動的に変更されるプレーヤレベル５２３などが含まれる。

ログイン履歴５２４には、過去のログイン／ログアウトの日時が時系列に格納されている。
共通イベント参加権リスト５２６は、参加可能な共通イベントのイベントＩＤを格納する。主ゲームのプレイ中にイベント発動条件を満たした場合、その発動する共通イベントのイベントＩＤが追加される。また、応答要請を受けるとそれに係る共通イベントのイベントＩＤが追加される。そして、共通イベントがクリアされるとリストから削除される。

参加要請データ５３０は、他のプレーヤによる参加要請を受けると作成される。
１つの参加要請データ５３０には、当該要請を発した発信元アカウント５３２と、要請が行われた日時を格納する要請日時５３４と、イベントＩＤ５３６と、対応フラグ５３８とを含む。イベントＩＤ５３６は、参加権が付与される共通イベントの識別情報を格納する。対応フラグ５３８はデフォルトが「０」で、当該参加要請の後にイベントＩＤ５３６が示す共通イベントに参加すると「１（要請に対して対応済）」へ変更される。

図６に戻り、ゲーム初期設定データ５５０は、主ゲームを実行するために必要な各種初期設定データを格納する。ゲームの舞台となるゲーム空間のデータ、プレーヤが選択可能なプレーヤキャラクタの雛形データ及び能力等の初期設定データ、登場する敵ＮＰＣの出現条件や出現位置や能力等の初期設定データ、などが含まれる。本実施形態では、共通イベント初期設定データ５５２を含む。

共通イベント初期設定データ５５２は、共通イベント毎に用意され、イベントを実行するために必要な各種初期設定データを格納する。例えば、図８に示すように、イベントＩＤ５５４と、イベント発動条件５５６と、イベントクリア条件５５８と、イベント参加終了条件５５９と、イベント初期設定データ５６０と、参加人数上限値５６８と、クリア時累積参加人数基準特典データ５７０と、初回時累積参加人数基準特典データ５７２と、初回参加日時基準特典データ５７４と、要請後経過時間基準特典データ５７６とを含む。

イベント発動条件５５６は、当該共通イベントの発動条件を定義する。例えば、開催日時と終了日時、ゲーム進行状況を示す各種パラメータ値の組み合わせ（例えば、プレーヤキャラクタ４のゲーム空間内の位置とプレーヤキャラクタ４のレベルとの組み合わせ）などに基づいて適宜定義される。

イベントクリア条件５５８は、当該共通イベントが終了するための条件を定義する。本実施形態では「敵ボスＮＰＣ６（図３参照）のヒットポイント≦０」が設定されるが、イベントの内容によって適宜設定可能である。

イベント参加終了条件５５９は、共通イベントへの１回の参加の終了条件を定義する。本実施形態では、イベントクリア条件５５８を満たした場合と、プレーヤキャラクタ４が敵ボスＮＰＣ６へ所定回数攻撃をした場合と、プレーヤキャラクタ４のイベント中にのみ適用されるヒットポイントが敵ボスＮＰＣ６の攻撃を受けて減算され「０」になった場合と、イベントへの参加開始から所定時間経過した場合と、のＯＲ条件が設定される。

イベント初期設定データ５６０は、イベント実行用の各種初期設定データを格納する。本実施形態では、敵ボスＮＰＣ６の強さの指標である敵ボスＮＰＣレベル５６１と、敵ボスＮＰＣ初期ヒットポイント５６３と、敵ボスＮＰＣ攻撃力５６５とを含む。

参加人数上限値５６８は、当該共通イベントへの参加人数の上限を定義する。上限に達して以降は、参加要請が制限される。つまり、以降の新規参加者を制限し、過度に参加人数が多くならないようにしてサーバ処理負荷の超過を防ぐ。

クリア時累積参加人数基準特典データ５７０は、図４（１）を参照して説明した特典の決定に係り、所与のタイミングにおいて算出される累積参加人数に基づく特典内容を定義する。例えば、図９に示すように、累積参加人数５７０ａに対応づけて、その時の特典内容となる特典ポイント５７０ｂ及び特典アイテム５７０ｃを格納する。尚、特典ポイント５７０ｂについては、累積参加人数を変数とする関数で定義するとしても良い。

初回時累積参加人数基準特典データ５７２は、図４（２）を参照して説明した特典の決定に係り、特典が付与される参加プレーヤが初めて参加したタイミングにおいて算出される累積参加人数に基づく特典を定義する。例えば、図１０に示すように、累積参加人数５７２ａに対応づけて、特典ポイント５７２ｂ及び特典アイテム５７２ｃを格納する。尚、特典ポイント５７２ｂについては、累積参加人数を変数とする関数で定義するとしても良い。

初回参加日時基準特典データ５７４は、図４（３）を参照して説明した特典の決定に係り、特典が付与される参加プレーヤが初めて参加した日時に基づく特典を定義する。例えば、図１１に示すように、日時条件５７４ａに対応づけて、特典ポイント５７４ｂ及び特典アイテム５７４ｃを格納する。日時条件５７４ａは、図１１のようにイベント開始日時を基準に日単位で定義しても良いし時間単位でも良い。特典ポイント５７４ｂについては、累積参加人数を変数とする関数で定義するとしても良い。

要請後経過時間基準特典データ５７６は、図４（４）を参照して説明した特典の決定に係り、当該共通イベントへの参加要請を受けた日時から、特典が付与される参加プレーヤが初めて参加した日時までの経過時間に基づく特典を定義する。例えば、図１２に示すように、経過時間５７６ａに対応づけて、特典ポイント５７６ｂ及び特典アイテム５７６ｃを格納する。特典ポイント５７６ｂについては、累積参加人数を変数とする関数で定義するとしても良い。

図６に戻り、プレイデータ５７８は、アカウント別に主ゲームの進行状況を示す各種パラメータ値を格納する。共通イベントが実行される場合も、イベントの進行状況を示す各種パラメータ値も格納される。

共通イベント管理データ５８０は、共通イベント毎に用意される。例えば、図１３に示すように、イベントＩＤ５８２と、ボスヒットポイント５８４と、参加履歴データ５９０と、イベントクリア日時５９８とを含む。ボスヒットポイント５８４は、本実施形態における共通イベントのイベントクリア条件５５８（図８）を判断するためのパラメータ値である。

参加履歴データ５９０は、当該共通イベントに、何時、どのアカウントのプレーヤキャラクタが、どれだけイベントクリアのために貢献したか、を示す各種パラメータ値を時系列に格納する。例えば、参加日時５９２（参加開始日時と参加終了日時、又は参加開始日時と参加時間）と対応づけて、参加プレーヤのアカウントを格納する参加アカウント５９４と、敵ボスＮＰＣに与えたダメージ量５９６とを格納する。

イベントクリア日時５９８は、当該共通イベントのイベントクリア条件５５８（図８）を満たしたと判定された日時が格納される。デフォルトは未設定を意味する値である。

［処理の流れの説明］
次に、サーバシステムの処理の流れについて説明する。ここで説明する処理の流れは、サーバ処理部２００ｓがサーバシステムプログラム５０５を実行した状態で、ゲーム管理プログラム５０６を実行することにより実現される。
尚、プレーヤは既にアカウント登録を済ませており、プレーヤキャラクタを選択するなど主ゲームをプレイすることが可能であるとする。また、何人かの他プレーヤをフレンド登録しているものとする。フレンドリストへのフレンドプレーヤの登録／抹消は公知技術を適宜利用可能なので、ここでの説明は省略する。

図１４〜図１５は、本実施形態におけるサーバシステム１１００による共通イベントに係る処理の流れを説明するためのフローチャートであって、プレーヤ端末１５００がログインし、主ゲームのプレイリクエストを受信し、主ゲームの進行開始した後の処理の流れに該当する。

サーバシステム１１００のサーバ処理部２００ｓは、主ゲームをプレイしているアカウント別にループＡを実行する（ステップＳ１０〜Ｓ４８）。

ループＡでは、サーバ処理部２００ｓは、先ず処理対象プレーヤが共通イベントをプレイ中でなければ（ステップＳ１２のＮＯ）、未対応参加要請の通知処理を行う（ステップＳ１４）。
具体的には、処理対象アカウントのアカウント管理データ５１０（図７）を参照して、対応フラグ５３８が「０（未対応）」の参加要請データ５３０が有れば、プレーヤ端末１５００へ未対応の参加要請が有る旨の通知（例えば、発信元アカウント５３２や、要請日時５３４，イベントＩＤ５３６などの表示を含むウィンドウ表示など）を表示させるためのデータを送信する。プレーヤ端末１５００ではこれを受信すると通知を行う。当該通知を見たプレーヤは参加要請に応じるならば、所定の参加権を得ている共通イベントのリスト（共通イベント参加権リスト５２６）から該当するイベントを選択してイベントへの参加をすることができる。

次に、サーバ処理部２００ｓは、プレーヤ端末１５００から参加権を得ている共通イベントのリスト表示のリクエストを受信したならば（ステップＳ１６のＹＥＳ）、共通イベント参加権リスト５２６をプレーヤ端末１５００へ送信する（ステップＳ１８）。
プレーヤ端末１５００では当該リストを、リストアップされたイベントＩＤを選択可能に表示する。プレーヤは、そのリストから参加を希望する共通イベントのイベントＩＤを選択して所定の参加リクエストを指示操作する。プレーヤ端末１５００は、選択されたイベントＩＤと参加リクエストをサーバシステム１１００へ送信することになる。

サーバ処理部２００ｓは、イベントＩＤと参加リクエストを受信すると（ステップＳ２０のＹＥＳ）、受信したイベントＩＤに対応する参加要請データ５３０の対応フラグ５３８を「１（対応済）」に変更する（ステップＳ２２）。

次いで、サーバ処理部２００ｓは、発動中の共通イベントの合計数が同時に発動可能な所定の上限値未満であれば（ステップＳ２６のＹＥＳ）、当該受信したイベントＩＤに対応する共通イベント管理データ５８０の参加履歴データ５９０に新たに登録を追加する（ステップＳ２８）。すなわち、参加日時５９２と対応づけて、処理対象アカウントを参加アカウント５９４に格納する。この段階ではダメージ量５９６はデフォルトの「０」を設定する。次いで、共通イベントの進行制御を開始する（ステップＳ３０）。

尚、参加リクエストをプレーヤ端末１５００から受信しなくとも（ステップＳ２０のＮＯ）、イベント発動条件５５６（図８）が満たされた共通イベントがあれば（ステップＳ２４のＹＥＳ）、サーバ処理部２００ｓは、発動中の共通イベントの合計数が所定の上限値未満であれば（ステップＳ２６のＹＥＳ）該当する共通イベントの参加履歴データ５９０に新たに登録を追加し（ステップＳ２８）、共通イベントの進行制御を開始する（ステップＳ３０）。

共通イベントの進行制御が開始されたならば、サーバ処理部２００ｓは、イベントの進行状況を記述する各種パラメータ値をプレイデータ５７８に記憶・管理する。そして、イベントクリア条件５５８（図８）を満たしたならば（ステップＳ３２のＹＥＳ）、イベントクリア日時５９８（図１３）に現在日時を格納する（ステップＳ３４）。

図１５のフローチャートに移って、次に、サーバ処理部２００ｓは、イベント参加終了条件５５９を満たしているか判定する（ステップＳ３６）。もし、満たしていれば（ステップＳ３６のＹＥＳ）、更にその時点で既に共通イベントがイベントクリア条件５５８を満たしていたかを判定する（ステップＳ３８）。具体的には、現在日時とイベントクリア日時５９８とを比較する。

そして、もし参加終了時にイベントが未だクリアされていなければ（ステップＳ３８のＮＯ）、サーバ処理部２００ｓは、イベントプレイの結果を参加履歴データ５９０に反映させる（ステップＳ４０）。具体的には、処理対象アカウントと同じ参加アカウント５９４のうち、参加日時５９２が最も新しい登録を抽出し、参加日時５９２に参加終了日時又は参加開始からの経過時間を追加し、また対応するダメージ量５９６には参加開始から参加終了までのイベントプレイで敵ボスＮＰＣ６に与えた合計ダメージ量を格納する。

次いで、サーバ処理部２００ｓは、参加履歴データ５９０を参照して、その時点における参加人数の合計が当該共通イベントの参加人数上限値５６８に達していなければ（ステップＳ４２のＮＯ）、参加要請の選択処理を実行する（ステップＳ４４）。

参加要請の選択処理では、サーバ処理部２００ｓは、処理対象アカウントのアカウント管理データ５１０（図７）のフレンドリスト５１４をプレーヤ端末１５００へ送信する。プレーヤ端末１５００は、フレンドリスト５１４を受信すると、当該リストに含まれるアカウントを参加要請先候補として表示する。そして、プレーヤが表示されたリストから選択先を選択操作すると、プレーヤ端末１５００は選択されたアカウントとともに参加要請リクエストをサーバシステム１１００へ送信する。

尚、参加要請先の数は、プレーヤが任意に決定するとしても良いし、共通イベントの内容に応じて（本実施形態であれば敵ボスＮＰＣ６の強さ）に応じて上限を設けるとしても良い。後者の場合であれば、サーバ処理部２００ｓは、フレンドリスト５１４をプレーヤ端末１５００へ送信する前に、当該共通イベントに対応する共通イベント初期設定データ５５２（図８）のイベント初期設定データ５６０から敵ボスＮＰＣレベル５６１、敵ボスＮＰＣ初期ヒットポイント５６３、敵ボスＮＰＣ攻撃力５６５の少なくとも何れかを参照し、それらの値が大きい程、参加要請先の上限を大きく設定し、フレンドリスト５１４とともに設定した上限数をプレーヤ端末１５００へ送信すると良い。そして、プレーヤ端末１５００では、参加要請先として選択可能なアカウントの数を受信した上限数以下とするように制御する。この場合、共通イベントへの参加人数をある程度適当な範囲に抑える効果が期待できる。

サーバシステム１１００のサーバ処理部２００ｓは、参加要請リクエストを受信すると、要請先のアカウントに、現在ログイン中のアカウントの中から自動選抜したアカウントを加えて、それらのアカウントのアカウント管理データ５１０へ新たな参加要請データ５３０を加える（ステップＳ４６）。そして、当該処理対象アカウントへのループＡを終了する（ステップＳ４８）

尚、ステップＳ４６の自動選抜に当たっては、プレーヤレベル５２３（図７）が、比較的低いプレーヤを優先的に選択するとしても良い。この場合、比較的レベルが低いプレーヤにとってみれば、敵ボスＮＰＣ６は強すぎて歯が立たないかもしれない。しかし、「これからこんなスゴイ共通イベントもあるぞ！」という意味合いで、共通イベントのお試し予告をする効果が生まれ、プレーヤに将来の楽しみへの期待感を抱かせることができる。また、課金額や課金頻度の高いプレーヤを優先的に選択するとしてもよい。

ステップＳ３８に戻って、参加終了時にイベントがクリアされている場合には（ステップＳ３８のＹＥＳ）、サーバ処理部２００ｓはステップＳ４０をスキップする。つまり、共通イベントをプレイしている間に、他のプレーヤのプレイによりイベント自体がクリアした場合には、当該処理対象アカウントによる当該プレイはそもそも無かった扱いとなる。もし、共通イベントに参加するに当たり何らかの対価支払処理を伴う構成では、ステップＳ３８で否定判定された場合に、支払った対価の還付処理を行うと好適である。

主ゲームをプレイ中の全アカウントについてループＡを実行したならば、サーバ処理部２００ｓは、次に特典付与処理を実行する（ステップＳ５０）。

図１６は、本実施形態における特典付与処理の流れを説明するためのフローチャートである。同処理において、サーバ処理部２００ｓは先ず、イベントクリアされた状態で未だ特典が付与されていない共通イベントを抽出する（ステップＳ１００）。具体的には、イベントクリア日時５９８が未設定の所定値のままになっている共通イベント管理データ５８０を抽出する。そして、抽出された共通イベントについてループＢを実行する（ステップＳ１０２〜Ｓ１６６）。

ループＢでは、処理対象とする共通イベントの参加履歴データ５９０を参照し、全参加プレーヤについてループＣを実行する（ステップＳ１０４〜Ｓ１５２）。
ループＣでは、サーバ処理部２００ｓは、先ずイベントクリア時における累積参加人数を算出し、クリア時累積参加人数基準特典データ５７０（図９）に従って第１の特典となる特典ポイント５７０ｂと特典アイテム５７０ｃとを決定する（ステップＳ１０６）。

次いで、サーバ処理部２００ｓは、処理対象のプレーヤの初回参加時点における累積参加人数を算出し、初回時累積参加人数基準特典データ５７２（図１０）に従って第２の特典となる特典ポイント５７２ｂと特典アイテム５７２ｃとを決定する（ステップＳ１０８）。

次いで、サーバ処理部２００ｓは、処理対象のプレーヤの初回参加日時を初回参加日時基準特典データ５７４（図１１）に照らして、第３の特典となる特典ポイント５７４ｂと特典アイテム５７４ｃとを決定する（ステップＳ１１０）。

次いで、サーバ処理部２００ｓは、処理対象プレーヤのアカウント管理データ５１０を参照して、ループＢの処理対象とされている共通イベントのイベントＩＤが設置された参加要請データ５３０の要請日時５３４を起点として、処理対象のプレーヤの初回参加日時までの経過時間を算出する。そして、要請後経過時間基準特典データ５７６（図１２）に照らして、第４の特典となる特典ポイント５７６ｂと特典アイテム５７６ｃとを決定する（ステップＳ１１２）。

そして、第１〜第４の特典全てを、ループＣの処理対象とする参加プレーヤに付与する（ステップＳ１５０）。例えば、特典ポイントは当該参加プレーヤのプレイデータ５７８に加算され、特典アイテムはプレイデータ５７８の所持アイテムリストに追加登録される。自動セーブ機能を有する構成では、アカウント管理データ５１０のセーブデータ５１８に含まれる所持ポイント５２０、所持アイテムリスト５２２も更新すれば良い。

ここで留意すべきは、クリア時累積参加人数基準特典データ５７０（図９）、初回時累積参加人数基準特典データ５７２（図１０）、初回参加日時基準特典データ５７４（図１１）、要請後経過時間基準特典データ５７６（図１２）は、それぞれ共通イベント毎に設定される点である（図８参照）。つまり、本実施形態で言えば敵ボスＮＰＣ６に応じて設定されている。これらの特典データで定義される特典は、特典の選択条件（累積参加人数５７０ａ、累積参加人数５７２ａ、日時条件５７４ａ、経過時間５７６ａ）が同じ状態で比較した場合、敵ボスＮＰＣ６が強いほどより価値が高くなるように設定しておくと、強い敵ボスＮＰＣ６ほど高い報酬が得られるように構成できる。
この場合、特典決定部２２０は、第１の共通敵キャラクタと対戦する第１の共通イベントに係る特典よりも、当該第１の共通敵キャラクタよりも強い第２の共通敵キャラクタと対戦する第２の共通イベントに係る特典の方が、価値の高い内容の特典とするように機能する。

特典の付与を行ったならば、サーバ処理部２００ｓはループＣを終了する（ステップＳ１５２）。そして、ループＢの処理対象とされる共通イベントの全参加プレーヤについてループＣを実行したならば、サーバ処理部２００ｓは次に、イベントクリアへの貢献度に応じた特典の付与を行う（ステップＳ１６０）。例えば、最初に敵ボスＮＰＣ６へダメージを与えた参加プレーヤには所定のファーストアタック特典を付与し、敵ボスＮＰＣ６のヒットポイントを「０」にした最後のダメージを与えた参加プレーヤへは所定のラストアタック特典を付与し、与えた総ダメージ数が最も多い参加プレーヤへは所定のＭＶＰ特典を付与する。

次に、サーバ処理部２００ｓは、ループＢの処理対象とされる共通イベントに対応する共通イベント管理データ５８０をサーバ記憶部５００ｓ（図６）から削除する（ステップＳ１６２）。更に、全アカウントのアカウント管理データ５１０の共通イベント参加権リスト５２６（図７）から、処理対象の共通イベントの参加権を登録抹消して（ステップＳ１６４）、ループＢを終了する（ステップＳ１６６）。

そして、ステップＳ１００で抽出した特典未付与のクリア済共通イベント全てについてループＢを実行したならば、特典付与処理を終了する。

図１５のフローチャートに戻って、特典付与処理を終了したならば図１４のステップＳ１０に戻る。

以上、本実施形態によれば、共通イベントの特典に係る魅力を高め、ひいては主ゲームの魅力を高めることができる。

〔変形例〕
以上、本発明を適用した実施形態について説明したが、本発明の形態はこれに限定されるものではなく、適宜構成要素の追加・省略・変更を施すことができる。

［その１］
例えば、主ゲームのジャンルはＲＰＧに限らず、アクションゲームなど、その他のジャンルでも構わない。

［その２］
また、上記実施形態では主ゲーム及び共通イベントの進行制御をサーバシステム１１００にて行う構成としたが、プレーヤ端末１５００にて行う構成も可能である。具体的には、図１７に示すようなプレーヤ端末１５００の機能構成例と、図１８に示すようなサーバシステム１１００の構成例との組み合わせが可能である。
より具体的には、主ゲーム進行制御部２１２と、共通イベント制御部２１４とを、処理部２００のプレーヤ端末演算部２０２の機能として実現する。この構成における主ゲーム進行制御部２１２は、主ゲームを開始する前に、（１）サーバシステム１１００に取得済のアカウントでログインする処理と、（２）ログイン後に当該アカウントのアカウント管理データ５１０を参照する処理と、を実行することができる。また、この構成における共通イベント制御部２１４は、参加履歴管理部２１６の代わりに、共通イベントの参加日時や、参加アカウント、ダメージ量などのイベント結果情報を、サーバシステム１１００へ送信制御するイベント結果送信制御部２１７を有する。参加履歴管理部２１６自体は、第１実施形態と同様にサーバシステム１１００にて実現される。これに伴って、プレーヤ端末１５００の記憶部５００にもゲーム初期設定データ５５０と、プレイデータ５７８とを記憶する。

サーバシステム１１００の共通イベントに係る処理の流れは、図１９〜図２０に示すように、基本的には第１実施形態と同様に実現される。但し、ステップＳ１２と、ステップＳ２４と、ステップＳ２６と、ステップＳ３６とは省略できる。ステップＳ３２〜Ｓ４６は、プレーヤ端末１５００から共通イベントのプレイ結果情報を受信した場合に（ステップＳ３１のＹＥＳ）、実行可能となる。

［その３］
また、上記実施形態では、１つの共通イベントに対して付与される特典の総量は、参加履歴に応じて変化することとなるが、総量一定の構成も可能である。例えば、付与される特典ポイントの総量が決まっている構成などである。この場合、上記実施形態における第１〜第３の特典として決定されるポイントを、総特典ポイントの分配率に置換する構成とすれば良い。

［その４］
また、上記実施形態では、クリア時累積参加人数基準特典データ５７０（図９）、初回時累積参加人数基準特典データ５７２（図１０）、初回参加日時基準特典データ５７４（図１１）、要請後経過時間基準特典データ５７６（図１２）を、それぞれ共通イベント毎に設定する構成としたが、全ての共通イベントで供用のデータとする構成も可能である。
この場合、特典付与処理において、第１〜第４の特典を決定する際、敵ボスＮＰＣ６が強いほど大きくなる係数を決定し、当該係数を乗じた分だけ特典の価値を補正してから付与するとしても良い。

２…プレーヤ
４…プレーヤキャラクタ
６…敵ボスＮＰＣ
２００ｓ…サーバ処理部
２０８…アカウント管理部
２１０…ゲーム管理部
２１２…主ゲーム進行制御部
２１４…共通イベント制御部
２１６…参加履歴管理部
２２０…特典決定部
２２２…参加人数基準決定部
２２４…参加日時基準決定部
２２６…要請後経過時間基準決定部
２２８…参加要請制御部
２３０…特典付与制御部
５００ｓ…サーバ記憶部
５０５…サーバシステムプログラム
５０６…ゲーム管理プログラム
５１０…アカウント管理データ
５５０…ゲーム初期設定データ
５５２…共通イベント初期設定データ
５７８…プレイデータ
５８０…共通イベント管理データ
１１００…サーバシステム
１１５０…制御基盤
１５００…プレーヤ端末

Claims (8)

1. プレーヤ端末と通信接続され、複数のプレーヤが参加可能な共通イベントに参加したプレーヤにゲーム進行上の特典を付与する特典付与処理を実行するサーバシステムであって、
   前記共通イベントに参加したプレーヤの参加履歴を管理する参加履歴管理手段と、
   所与のタイミングでの前記参加履歴に基づいて前記特典の内容を可変に決定する第１の特典決定手段と、
   を備え、
   前記第１の特典決定手段は、前記共通イベントの終了タイミングでの累積参加人数に基づいて前記特典の内容を可変に決定する手段を有する、
   サーバシステム。
2. 前記第１の特典決定手段は、前記共通イベントの終了タイミングでの累積参加人数が多くなるほど、前記特典の内容を次第に価値の高い内容にする手段を有する、
   請求項１に記載のサーバシステム。
3. 前記第１の特典決定手段は、当該参加プレーヤが前記共通イベントに参加したタイミングでの累積参加人数に基づいて、当該参加プレーヤに付与する前記特典の内容を可変に決定する手段を有する、
   請求項１又は２に記載のサーバシステム。
4. 前記共通イベントは、共通敵キャラクタと対戦するイベントであって、第１の共通敵キャラクタと対戦する第１の共通イベントと、前記第１の共通敵キャラクタよりも強い第２の共通敵キャラクタと対戦する第２の共通イベントとが有り、
   前記第１の特典決定手段は、前記第１の共通イベントに係る前記特典よりも、前記第２の共通イベントに係る前記特典の方が、価値の高い内容の特典とする手段を有する、
   請求項１〜３の何れか一項に記載のサーバシステム。
5. 当該参加プレーヤが前記共通イベントに参加した日時に基づいて当該参加プレーヤに付与する前記特典の内容を可変に決定する第２の特典決定手段、
   を更に備えた請求項１〜４の何れか一項に記載のサーバシステム。
6. 前記第２の特典決定手段は、前記共通イベントの初回参加日時が初期である場合と、終期である場合とで前記特典の内容を異なる内容とする手段を有する、
   請求項５に記載のサーバシステム。
7. 一の参加プレーヤから他のプレーヤに前記共通イベントへ参加を要請する旨の参加要請通知をする参加要請通知手段と、
   前記参加要請から、前記他のプレーヤが前記共通イベントに参加するまでの経過時間に基づいて、当該他のプレーヤに付与する前記特典の内容を可変に決定する第３の特典決定手段と、
   を更に備えた請求項１〜６の何れか一項に記載のサーバシステム。
8. 前記第３の特典決定手段は、前記経過時間が第１の経過時間の場合に前記他のプレーヤに付与する前記特典の内容を、前記第１の経過時間より長い第２の経過時間の場合に付与する前記特典よりも価値の高い内容とする手段を有する、
   請求項７に記載のサーバシステム。

Images