(58)【調査した分野】(Int.Cl.,DB名)
各プレイヤがクライアント装置を介して操作するキャラクタを構成員とするグループ同士の対戦ゲームをネットワーク経由で各クライアント装置に提供するための方法であって、
前記キャラクタに対応付けられたパラメータを記憶するサーバ装置が、
前記グループの内の所定のグループに所属するプレイヤからの、他のグループに対する攻撃の受付許容期間を設定し、
前記受付許容期間内に前記所定のグループに所属する前記プレイヤの内で攻撃の参加表明を行ったプレイヤが存在するか否かを判定し、
前記攻撃の参加表明を行ったプレイヤが存在すると判定した場合、前記所定のグループに所属するプレイヤの内で前記攻撃の参加表明を行った各プレイヤに対応する各キャラクタのパラメータを、前記攻撃の参加表明を行ったプレイヤに対応するキャラクタに基づいて変更するとともに、変更後の前記パラメータに基づき、前記他のグループに対する攻撃イベントを生成する演出処理を行い、
前記攻撃の参加表明を行ったプレイヤが存在しないと判定した場合、前記攻撃イベントを生成しない、方法。
各プレイヤがクライアント装置を介して操作するキャラクタを構成員とするグループ同士の対戦ゲームをネットワーク経由で各クライアント装置に提供するためのコンピュータを、
前記キャラクタに対応付けられたパラメータを記憶する記憶部と、
前記グループの内の所定のグループに所属するプレイヤからの、他のグループに対する攻撃の受付許容期間を設定する設定部と、
前記受付許容期間内に、前記所定のグループに所属する前記プレイヤの内で攻撃の参加表明を行ったプレイヤが存在するか否かを判定する判定部と、
前記判定部が前記攻撃の参加表明を行ったプレイヤが存在すると判定した場合、前記所定のグループに所属するプレイヤの内で前記攻撃の参加表明を行った各プレイヤに対応する各キャラクタのパラメータを、前記攻撃の参加表明を行ったプレイヤに対応するキャラクタに基づいて変更する変更部と、
変更後の前記パラメータに基づき、前記他のグループに対する攻撃イベントを生成する演出処理を行う演算部として機能させるコンピュータプログラムであって、
前記演算部は、前記判定部が前記攻撃の参加表明を行ったプレイヤが存在しないと判定した場合、前記攻撃イベントを生成しない、コンピュータプログラム。
【発明を実施するための形態】
【0010】
以下、各図を参照しながら発明の実施形態について説明する。
図1は本実施形態に係るゲームシステム100のネットワーク構成を示す。
ゲームシステム100は、ネットワーク20を介して複数のクライアント装置30に対戦ゲームサービスを提供するサーバ装置10を備える。サーバ装置10は、対戦ゲームサービスを提供する機能を有するネットワークノードであり、例えば、演算処理能力の高いホストコンピュータによって構成されるが、これに限らず、例えば、汎用の通信端末装置によって構成されてもよい。一方、クライアント装置30は、対戦ゲームサービスの提供を受ける機能を有するネットワークノードであり、例えば、汎用の通信端末装置によって構成される。本明細書では、演算処理能力に関らず、対戦ゲームサービスを提供するネットワークノードを「サーバ装置」と称し、対戦ゲームサービスの提供を受けるネットワークノードを「クライアント装置」と称する。クライアント装置30からのリクエストに応答してサーバ装置10がレスポンスを返すことで、オンラインゲームサービスが提供される。
【0011】
なお、サーバ装置10を構成するホストコンピュータは、必ずしも一台である必要はなく、ネットワーク20上に分散する複数のサブコンピュータから構成されてもよい。また、サーバ装置10又はクライアント装置30を構成する汎用の通信端末装置は、例えば、デスクトップ型パソコン、ノート型パソコン、タブレット型パソコン、ラップトップ型パソコン、及び携帯電話機を含む。携帯電話機は、例えば、PDC(Personal Digital Cellular)、PCS(Personal Communication System)、GSM(登録商標)(Global System for Mobile communications)、PHS(Personal Handy phone System)、PDA(Personal Digital Assistant)等のハンドヘルド携帯端末であり、例えば、W−CDMA(Wideband Code Division Multiple Access)、CDMA−2000(Code Division Multiple Access-2000)、IMT−2000(International Mobile Telecommunication-2000)、Wibro(Wireless Broadband Internet)等の規格でデータ通信可能である。また、ネットワーク20は、例えば、有線ネットワーク(例えば、近距離通信網(LAN)、広域通信網(WAN)、又は付加価値通信網(VAN)等)と無線ネットワーク(移動通信網、衛星通信網、ブルートゥース、WiFi(Wireless Fidelity)、HSDPA(High Speed Downlink Packet Access)等)とが混在する通信網である。サーバ装置10とクライアント装置30との間には、両者間の通信プロトコルを変換するゲートウェイサーバが介在してもよい。
【0012】
図2は本実施形態に係るサーバ装置10の構成を示すブロック図である。
サーバ装置10は、プロセッサ11、通信インタフェース12、及び記憶資源13を備える。プロセッサ11は、算術演算、論理演算、ビット演算等を処理する算術論理演算ユニット及び各種レジスタ(プログラムカウンタ、データレジスタ、命令レジスタ、汎用レジスタ等)やタイマから構成され、記憶資源13に格納されているコンピュータプログラム40を解釈及び実行し、複数のクライアント装置30からのリクエストに対するレスポンスを返す。コンピュータプログラム40は、複数のクライアント装置30からのリクエストに応答してゲーム処理を行うためのプログラムであり、メインプログラムの中で呼び出されて実行される複数のソフトウェアモジュールを備える。このようなソフトウェアモジュールは、それぞれ特定の処理(ゲーム演算処理、画像表示処理、通信処理等)を実行するためにモジュール化されたサブプログラムであり、例えば、プロシージャ、サブルーチン、メソッド、関数、及びデータ構造等を用いて作成される。モジュールは、その部分だけでコンパイル可能な単位である。このようにモジュール化されたサブプログラムの一つとして、コンピュータプログラム40は、対戦ゲームの演出処理を行う演出処理モジュール41を備える。演出処理モジュール41の詳細については、後述する。
【0013】
記憶資源(記憶部)13には、パラメータ50がキャラクタ毎に記憶されている。パラメータ50は、例えば、キャラクタの攻撃に関わる変数(具体的には、キャラクタの「攻撃値」などの変化に追従する変数)や、グループ同士の対戦において相手グループのキャラクタに攻撃を仕掛ける際に利用されるカード(詳細は後述)に記載された「技の種類」や技に関連する特定の「アイテム」、技の「属性」が挙げられるが、これに限定する趣旨ではない。例えば、「防御値」等に関わる変数を含めても良く、対戦ゲームで獲得した「報酬」を示す変数を含めても良い。報酬とは、その値が高い程、対戦ゲームを展開する上で、相手に対して相対的に優位に立てる効果を生じせしめる価値概念である。報酬は、例えば、ゲーム内でアイテムを購入するために使用する通貨や、キャラクタの攻撃力を増大させるアイテムや、キャラクタの体力又はダメージを回復させるアイテムでもよく、或いは敵キャラクタにダメージを与えることによって加算されるポイントでもよい。報酬は、キャラクタ間で交換可能な価値を有するものでもよい。さらに、パラメータ50は、例えば、プレイヤが対戦ゲームに参加した日からの経過期間を示す変数を含んでも良い。
【0014】
記憶資源13は、例えば、物理デバイス(例えば、ディスクドライブ又は半導体メモリ等のコンピュータ読み取り可能な記録媒体)の記憶領域が提供する論理デバイスである。複数の物理デバイスを一つの論理デバイスにマッピングしてもよく、或いは一つの物理デバイスを複数の論理デバイスにマッピングしてもよい。記憶資源13には、各クライアント装置30のアクセス履歴、プレイ状況、ゲーム進行状態等を示すデータやログ等が保存される。通信インタフェース12は、ネットワーク20を介してクライアント装置30に接続するためのハードウェアモジュールであり、例えば、ISDNモデム、ADSLモデム、ケーブルモデム等である。
【0015】
図3は本実施形態に係るクライアント装置30の構成を示すブロック図である。
クライアント装置30は、プロセッサ31、音声出力デバイス32、通信インタフェース33、記憶資源34、入力デバイス35、及び表示デバイス36を備える。プロセッサ31は、算術論理演算ユニット及び各種レジスタ(プログラムカウンタ、データレジスタ、命令レジスタ、汎用レジスタ等)やタイマから構成され、記憶資源34に格納されているコンピュータプログラム60を解釈及び実行し、入力デバイス35に入力された操作情報に従ってサーバ装置10にリクエストを送信し、サーバ装置10からのレスポンスを受信する。コンピュータプログラム60は、サーバ装置10に接続して対戦ゲームサービスの提供を受けるためのアプリケーションプログラムである。このアプリケーションプログラムは、サーバ装置10からネットワーク20を通じて配信可能である。
【0016】
記憶資源34は、物理デバイス(例えば、ディスクドライブ又は半導体メモリ等のコンピュータ読み取り可能な記録媒体)の記憶領域が提供する論理デバイスであり、クライアント装置10の処理に用いられるオペレーティングシステムプログラム、ドライバプログラム、各種データ等も格納する。ドライバプログラムとしては、例えば、入力デバイス35を制御するための入力デバイスドライバプログラムや、音声出力デバイス32及び表示デバイス36を制御するための出力デバイスドライバプログラム等がある。各種データとしては、例えば、ゲーム画面に登場する各オブジェクトや背景等の画像データ等がある。音声出力デバイス32は、例えば、ゲーム効果音等のサウンドデータを再生可能なサウンドプレイヤである。通信インタフェース33は、サーバ装置10との接続インタフェースを提供するものであり、無線通信インタフェース又は有線通信インタフェースによって構成される。入力デバイス35は、プレイヤからの入力操作を受け付けるインタフェースを提供するものであり、例えば、タッチパネル、キーボード、マウス等である。表示デバイス36は、ゲーム画面等の画像表示インタフェースをプレイヤに提供するものであり、例えば、有機ELディスプレイ、液晶ディスプレイ、CRTディスプレイ等である。
【0017】
プレイヤは、入力デバイス35を操作し、認証情報(ID及びパスワード等)を入力してサーバ装置10のゲームサービスにログインすると、プレイヤの認証情報に関連付けられたマイページ画面が表示デバイス36に表示される。マイページ画面では、個々のプレイヤが属するグループに関するメニュー画面が表示される。「グループ」は、各プレイヤがクライアント装置30を介して操作するキャラクタを構成員とする仮想的な集合体であり、このようなグループは、ゲームタイトル毎に作成及び結成されてもよく、或いは、複数のゲームタイトルに共通するものでもよい。このような目的で結成されたグループは、ソーシャルゲームの分野において、「ギルド」、「パーティ」、「チーム」、「コミュニティ」等と呼ばれることもある。キャラクタとは、プレイヤの指示に従い、プレイヤに代わって仮想空間内で行動する仮想上のオブジェクトを意味する。
【0018】
サーバ装置10が提供するゲームサービスへの参加経験のあるプレイヤが操作するキャラクタは、原則として、何れかのグループに属しており、その履歴情報は、プレイヤの認証情報に関連付けられて、サーバ装置10の記憶資源13に保存されている。このような履歴情報に基づいて、グループに関する編集メニュー画面が表示デバイス36に表示される。一方、サーバ装置10が提供するゲームサービスに初めて参加するプレイヤが操作するキャラクタは、原則として、特定のグループに属していないため、何れかのグループに属するメニュー画面(例えば、グループを検索したり、或いは新グループを結成したりする画面)が表示デバイス36に表示される。プレイヤの所属グループが決定又は選択された後、プレイヤがゲームサービスの参加を選択すると、その時点で実施されているゲームイベントの画面が表示デバイス36に表示される。
【0019】
図4は本実施形態に係るゲーム画面200の一例を示す説明図である。
ゲーム画面200は、イベントフィールド201及びパレット202を含む。イベントフィールド201は、グループ300、400間の対戦ゲームが展開される仮想的なフィールドであり、そこには、一方のグループ300に属するキャラクタ301、302、303と、他方のグループ400に属するキャラクタ401、402、403とが表示される。グループ同士の対戦は、「ギルド戦」と呼ばれたり、或いはギルドの頭文字(G)に由来して「GvG」と呼ばれたりすることがある。同一のグループに属する各キャラクタは、相互にコミュニケーションをとりながら、相手グループに属する相手キャラクタに攻撃を仕掛ける。パレット202は、各キャラクタが相手キャラクタに対して攻撃を仕掛ける際に使用できる「技」を選択するための仮想的な場である。パレット202には、仮想的なカードの束であるデッキ600と、デッキ600から選択された複数のカード601、602、603が表示される。各カードには、技の種類を示す表示(イラスト又は文字)、技に関連する特定のアイテムが描画されている。また、各カードには、攻撃値(技や発動される攻撃のポイントなど)、防御値(体力や生命力など)、属性(炎や水など)が設定されている。
【0020】
各プレイヤは、デッキ600から複数のカード601、602、603を捲り、それらのカード601、602、603に表示されている技、攻撃値、特定のアイテム、防御値等の組み合わせに応じて相手キャラクタを攻撃し、相手キャラクタに与えるダメージや自分が受けるダメージが算出される。ゲージ501は、グループ300に属するキャラクタ301、302、303が連続して相手キャラクタ401、402、403に攻撃を仕掛けた回数を表示する。同様に、ゲージ502は、グループ400に属するキャラクタ401、402、403が連続して相手キャラクタ301、302、303に攻撃を仕掛けた回数を表示する。連続して攻撃を仕掛ける回数は、「コンボ回数」と呼ばれ、コンボ回数を表示するゲージ501、502は、「コンボゲージ」と呼ばれる。本実施形態では、このようなコンボを利用した「連続攻撃」を可能とするほか、一定の期間内に攻撃参加を表明した複数のキャラクタによるコンボを利用した「一斉攻撃」を可能とする点に特徴がある。なお、以下の説明では、一斉攻撃するためのコンボを「一斉コンボ」と呼ぶ。
【0021】
図5は本実施形態に係る「一斉コンボ」を利用した演出効果を説明する図であり、グループG1に対して一斉攻撃が許可され、3人のプレイヤが参加表明をすることにより各プレイヤに対応する各キャラクタ301、302、303が一斉攻撃に参加する態様を示している。演出処理モジュール(指定部)41は、タイマ及び記憶資源13を参照し、一斉攻撃の受付開始タイミングが到来したか否かを判断する。ここで、一斉攻撃に関する詳細は、タイミング情報(一斉攻撃の受付開始タイミングや、一斉攻撃の受付終了タイミングなどを示す情報)や、グループ特定情報(いずれのグループに対して一斉攻撃を許可するかなどを示す情報)に記述されており、これらの情報は、記憶資源13に予め登録されている。なお、タイミング情報やグループ特定情報は、ゲーム運営者等によって適宜設定・変更可能となっている。
【0022】
演出処理モジュール41は、記憶資源13を参照し、グループG1に一斉攻撃の受付開始タイミングt1が到来したことを確認すると、グループG1に所属する各キャラクタのクライアント装置30に、一斉攻撃の受付を許可する期間(以下、「受付許可期間」という)や受付開始タイミングt1、受付終了タイミングt2などを通知する。演出処理モジュール41は、受付許可期間内(=Δt)に、グループG1に所属するキャラクタ301、302、303に対応する各プレイヤから一斉攻撃の参加表明を受けとると、各キャラクタ301、302、303のパラメータ50(ここでは、「攻撃値」)を参照し、各キャラクタ301、302、303のそれぞれの攻撃値AP1、AP2、AP3を把握する。演出処理モジュール(合成部、演算部)41は、その後、受付終了タイミングt2が到来したことを確認すると、受付許可期間内に一斉攻撃の参加表明を行った各プレイヤに対応するキャラクタ301、302、303の攻撃値(パラメータ)AP1、AP2、AP3を合成し、一斉攻撃イベントを生成する。この際、複数のプレイヤが一斉攻撃に参加表明したインセンティブ(すなわち、一斉コンボのインセンティブ)として、単純に各プレイヤに対応する各キャラクタの攻撃値を加算したものよりも、大きな攻撃値となるように、一斉攻撃イベントが生成される。
【0023】
一例として、参加表明したプレイヤの数に応じて一斉攻撃イベントのインセンティブの割合を決定しても良い。例えば、
図5に示すように、参加表明したプレイヤの数が「3」である場合には、各プレイヤに対応する各キャラクタ301、302、30のオリジナルの攻撃値AP1、AP2、AP3をそれぞれ30%ずつ増加させた攻撃値AP1’(=AP1×1.3)、AP2’(=AP2×1.3)、AP3’(=AP3×1.3)とし、これらを加算することで、インセンティブが付与された一斉攻撃イベントAPt1(=AP1’+AP2’+AP3’)を生成しても良い。なお、参加表明したプレイヤの数に応じて一斉攻撃イベントに付与されるインセンティブは、攻撃値のみに限定されるものではない。例えば、参加表明したプレイヤの数が増加するにつれ、攻撃値に加えて(あるいは代えて)防御値が増加されるインセンティブであっても良く、さらには参加表明したプレイヤの数が設定数に達した場合にのみ可能となる特殊な攻撃を発現させても良い。
【0024】
このように、一斉攻撃の受付許可期間を設け、この間に参加表明した複数のプレイヤに対応するキャラクタのパラメータを合成して一斉攻撃イベントを生成することで、各キャラクタを操作する各プレイヤは、従来に比べて攻撃の一体感をより一層味わうことができる。また、ゲームの習熟度が低いプレイヤであっても、指定された受付許可期間内に攻撃表明さえすれば、参加表明をした習熟度の高いプレイヤと相俟って一斉攻撃を繰り出すことができるため、ゲームの習熟度が低いプレイヤが参加表明を躊躇してしまう等の問題を抑制することができる。別言すれば、対戦ゲームの習熟度が低くても参加表明することで一斉攻撃の効果を増大させることができるため、対戦ゲームの習熟度の低いプレイヤが活躍する場面が増大し、ソーシャルゲームの活性化に繋がる。なお、生成される一斉攻撃イベントは、1つである必要はなく複数であっても良い。
【0025】
図6は本実施形態に係る「一斉コンボ」の演出処理の流れを示すフローチャートである。なお、演出処理モジュール41は、ステップ101〜ステップ110の処理をサーバ装置10に実行させるためのコマンドセットを用いて記述されたサブプログラムである。
【0026】
演出処理モジュール41は、タイマ及び記憶資源13を参照し、いずれかのグループに一斉攻撃の受付開始タイミングt1が到来したか否かを判断する(ステップS101)。演出処理モジュール41は、一斉攻撃の受付開始タイミングt1が到来していない場合には(ステップS101;NO)、ステップS101の処理を繰り返し実行する一方、一斉攻撃の受付開始タイミングt1が到来したと判断すると(ステップS101;YES)、対応するグループ(以下、「攻撃側グループ」という)に一斉攻撃の受付許可期間Δtを指定する(ステップS102)。
【0027】
演出処理モジュール41は、記憶資源13を参照し、攻撃側グループに所属する各キャラクタのクライアント装置30に、一斉攻撃の受付に関する詳細(一斉攻撃の受付開始タイミングt1、受付許可期間Δt、一斉攻撃の受付終了タイミングt2など)を通知する。
【0028】
演出処理モジュール41は、攻撃側グループに所属するいずれかのキャラクタに対応するプレイヤから一斉攻撃の参加表明があったか否かを判断する(ステップS103)。例えば、キャラクタ301(
図5参照)に対応するプレイヤから一斉攻撃の参加表明があると(ステップS103;YES)、キャラクタ301のパラメータ50(ここでは、「攻撃値」)を参照し、キャラクタ301の攻撃値AP1を把握する(ステップS104)。そして、演出処理モジュール41は、受付許可期間Δtが終了したか否か(すなわち、一斉攻撃の受付終了タイミングt2が到来したか否か)を判断する。演出処理モジュール41は、受付許可期間Δtが終了していないと判断すると(ステップS105;NO)、ステップS103に戻り、再び、攻撃側グループに所属するいずれかのキャラクタから一斉攻撃の参加表明があるか否かの判断を行う。一方、演出処理モジュール41は、受付許可期間が終了したと判断すると(ステップS105;YES)、最終的に2人以上のキャラクタが一斉攻撃の参加表明を行ったか否かを判断する(ステップS106)。例えば、
図5に示すように、3人のキャラクタ301、302、303に対応するプレイヤから一斉攻撃の参加表明を受けていた場合には(ステップS106;YES)、演出処理モジュール41は、受付期間内に一斉攻撃の参加表明を行った各プレイヤに対応するキャラクタ301、302、303の攻撃値(パラメータ)A1、A2、A3を合成し(ステップS107)、一斉攻撃イベントを生成し(ステップS108)、処理を終了する。なお、複数のプレイヤが一斉攻撃に参加表明したインセンティブとして、単純に各プレイヤに対応する各キャラクタの攻撃値を加算したものよりも、大きな攻撃値となるように、一斉攻撃イベントが生成されるが、詳細は既に説明したため、ここでは割愛する。
【0029】
一方、ステップS106において、最終的に2人以上のキャラクタに対応するプレイヤが一斉攻撃の参加表明を行っていないと判断すると(ステップS106;NO)、演出処理モジュール41は、ステップS109に進む。ここで、演出処理モジュール41は、1人のキャラクタに対応するプレイヤが一斉攻撃の参加表明を行っていた場合には、1人のキャラクタの攻撃値に基づき、単発の攻撃イベントを生成する一方、いずれのプレイヤも一斉攻撃の参加表明を行っていなかった場合には、いずれの攻撃イベントも生成することなく、処理を終了する。なお、単発の攻撃イベントを生成する場合であっても、何らかのインセンティブを与えても良い。例えば、1人のプレイヤに対応するキャラクタの攻撃値よりも大きな攻撃値となるように、単発の攻撃イベントを生成しても良い。
【0030】
また、ステップS103において、攻撃側グループに所属するいずれかのキャラクタに対応するプレイヤから一斉攻撃の参加表明がないと判断すると(ステップS103;NO)、演出処理モジュール41は、ステップS105に進み、受付許可期間Δtが終了したか否かを判断する。演出処理モジュール41は、受付許可期間Δtが終了したと判断すると(ステップS105;YES)、ステップS106に進む。一方、演出処理モジュール41は、受付許可期間Δtが終了していないと判断すると(ステップS105;NO)、ステップS103に戻り、再び、攻撃側グループに所属するいずれかのキャラクタから一斉攻撃の参加表明があるか否かの判断を行う。
【0031】
以上説明した「一斉コンボ」の演出処理は、演出処理モジュール41とプロセッサ11との協働により実現されるものであるが、専用のハードウェア資源(例えば、特定用途向け集積回路(ASIC))やファームウェアで同様の演出処理を行ってもよい。また、コンピュータプログラム40は、例えば、オブジェクト指向言語で記述されてもよい。オブジェクト指向言語では、各キャラクタ301〜303をオブジェクトとして取り扱い、パラメータ50を各キャラクタ301〜303の「属性値」として定義し、キャラクタ301〜303の振る舞い(例えば、攻撃等)を各キャラクタ301〜303の「メソッド」として定義することにより、対戦ゲーム処理が可能になる。キャラクタ301〜303だけでなく、例えば、ゲーム画面200に表示されるゲージ501、502やカード601、602、603等もオブジェクトとして取り扱い、これらの「属性値」や「メソッド」を定義することで、画像表示を制御することが可能である。但し、コンピュータプログラム40は、オブジェクト指向言語に限らず、例えば、手続き指向言語で記述されてもよい。コンピュータプログラム40は、所定の信号形式に符号化された上で、伝送媒体(有線通信網)又は伝送波(無線電波)を介してノード間を伝送することが可能である。
【0032】
なお、上述の実施形態は、本発明を説明するための一例であり、本発明を実施形態に限定する趣旨ではない。また、本発明は、その要旨を逸脱しない限り、様々な変形が可能である。例えば、当業者であれば、実施形態で述べたリソース(ハードウェア資源又はソフトウェア資源)を均等物に置換することが可能であり、そのような置換も本発明の範囲に含まれる。
【0033】
<応用例>
上述した本実施形態では、参加したプレイヤの数に応じて一斉攻撃イベントのインセンティブの割合を決定したが、これに加えて(あるいは代えて)参加したプレイヤのカードの組み合わせ(以下の例では、カードの属性)に応じて一斉攻撃イベントのインセンティブの割合を決定しても良い。
【0034】
図7は変形例に係る「一斉コンボ」を利用した演出効果を説明する図であり、
図5に対応している。
図5に対応する部分には同一符号を付し、詳細な説明は割愛する。
記憶資源13には、インセンティブの付与対象となるカードの属性(
図7ではカードの属性AT1)やインセンティブの割合の決定アルゴリズム等が記憶されている。なお、本変形例ではインセンティブの付与対象となるカードの属性が予め決められている場合を想定するが、本発明はこれに限る趣旨ではない。例えば、各プレイヤがデッキからカードを捲るなどして各プレイヤのカードが出揃った時点(すなわち、一斉攻撃の受付終了t2)において、最も重なりが多いカードの属性を、インセンティブの付与対象としても良い。その他、抽選等によりインセンティブの付与対象となるカードの属性をランダムに決定しても良く、また、第L番目(L≧2)に重なりが多いカードの属性を、インセンティブの付与対象としても良い。さらに、インセンティブの付与対象となるカードの属性は1種類である必要はなく、複数の種類のカード属性(例えば、カードの属性AT1及びAT4など)をインセンティブの付与対象としても良い。なお、複数の種類のカード属性をインセンティブの付与対象とした場合には、各カード属性に付与するインセンティブの大きさを変えたり、インセンティブの種類を変えても良い。
【0035】
本変形例に戻り、
図7に示すように、一斉攻撃に参加表明したプレイヤに対応するキャラクタ301については、インセンティブの付与対象となるカード属性AT1のカードが「3枚」含まれ、キャラクタ302については、インセンティブの付与対象となるカード属性AT1のカードが「1枚」含まれ、キャラクタ303については、インセンティブの付与対象となるカード属性AT1のカードが「2枚」含まれている。
【0036】
この状態において、演出処理モジュール41は、まず、一斉攻撃に参加表明したプレイヤの数に応じて第1インセンティブを決定する。
図7に示すように、参加表明したプレイヤの数が「3」である場合、各プレイヤに対応する各キャラクタ301、302、303のオリジナルの攻撃値AP1、AP2、AP3を合算し、合算した値を30%増加させ、これを第1インセンティブとする。
【0037】
次に、演出処理モジュール41は、一斉攻撃に参加表明したプレイヤのカードの属性に応じて第2インセンティブを決定する。上述したように、一斉攻撃に参加表明した各プレイヤに対応するキャラクタ301、302、303について、インセンティブの付与対象となるカード属性AT1のカードが合計「6枚」(=3+1+2)含まれている場合、全体の攻撃力をさらに6%(この場合、カード属性AT1のカード枚数に対応)増加させ、これを第2インセンティブとする。
【0038】
最後に、演出処理モジュール41は、第1インセンティブと第2インセンティブとを合成することにより、攻撃力が合計で36%増加した一斉攻撃イベントAPt2(=(AP1+AP2+AP3)×1.36)を生成する。
【0039】
なお、以上説明したインセンティブの割合を決定する方法は、あくまで一例であり、一斉攻撃に参加表明したプレイヤの数や、特定の属性を有するカードの枚数に応じてどれだけ攻撃力を増加させるかは、設計等に応じて適宜変更可能である。また、単に攻撃力を増加させるだけでなく、防御値やアイテムの付与などのインセンティブを一斉攻撃イベントに与えても良い。さらに、攻撃値だけでなく、その他のパラメータ(防御値、アイテムなど)を考慮に入れて、一斉攻撃のインセンティブの種類や割合を決定しても良い。
【0040】
また、参加するプレイヤの数に応じて一斉攻撃イベントの表現態様(視覚的表現)を変化させても良い。例えば、
図8に示すように、一斉攻撃を代行する代行キャラクタCh(例えば召喚獣など)をゲーム画面200に登場させ、一斉攻撃に参加表明するプレイヤが3人(「一斉コンボ3」)まで、10人(「一斉コンボ10」)まで、10人以上(「一斉コンボ10以上」)と変化するにつれ、代行キャラクタChも進化(電撃の帯電が激しくなるなど)させる。このように、参加するプレイヤの数に応じて一斉攻撃イベントの表現態様を変化させることで、攻撃側グループに属している各プレイヤに一斉攻撃への参加を促進させることが可能となる。
【0041】
なお、本実施形態では、1つの受付許容期間内に参加表明された各キャラクタのパラメータを合成して一斉攻撃イベントを生成する場合について説明したが、これに限る趣旨ではない。例えば、1つのギルド戦の対戦期間中に、複数の受付許容期間を設け、各許容期間内に参加表明された各キャラクタのパラメータを段階的に合成してゆき、受付許容期間の合計が所定数M(例えばM=5)に到達したときに、これまでに蓄積した複数の合成パラメータに基づき、一斉攻撃イベントを生成しても良い。なお、一斉攻撃イベントには、代行キャラクタChが攻撃する態様のほか、代行キャラクタChを使うことなしに各キャラクタが同じタイミングで一斉に攻撃する態様であっても良いのはもちろんである。
【0042】
また、本実施形態では、攻撃側グループが決まっている態様について説明したが、その他として、攻撃側グループを決めることなく、対戦している両グループのいずれもが一斉攻撃できる態様であっても良い。この場合、演出処理モジュール41は、一斉攻撃の受付開始タイミングt1が到来すると、両グループのプレイヤ(すなわち、その対戦ゲームに参加している全プレイヤ)に一斉攻撃の受付が開始したことを報知するべく、各プレイヤのクライアント装置30に一斉攻撃の受付に関する詳細(一斉攻撃の受付開始タイミングt1、受付許可期間Δt、一斉攻撃の受付終了タイミングt2など)を通知する。そして、演出処理モジュール41は、プレイヤから攻撃の参加表明がある毎に、各プレイヤのグループ属性が記述されている記憶資源13のパラメータ50等を参照することで、そのプレイヤのグループ属性を判断する。例えば、グループG1とグループG2が対戦している場合には、演出処理モジュール41は、攻撃の参加表明を行ったプレイヤが、グループG1またはグループG2のいずれに属しているのかを判断する。その後、演出処理モジュール41は、受付終了タイミングt2が到来し、受付許容期間Δtが終了したと判断すると、各グループのそれぞれについて、攻撃の参加表明を行った各ユーザに対応するキャラクタの攻撃値(パラメータ)を合成し、一斉攻撃イベントを生成する。なお、各グループで生成される一斉攻撃イベントのインセンティブは、グループ間で異なっても良い。例えば、グループG1については参加したプレイヤの数に応じて一斉攻撃イベントを付与する一方、グループG2については参加したプレイヤのカードの組み合わせに応じて一斉攻撃イベントを付与しても良い。また、2グループの対戦に限定されることはなく、3グループ以上の対戦においても一斉攻撃できる態様であっても良い。