JP2014028079A - ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム - Google Patents

Abstract

【課題】複数のユーザが協力してゲームを行う場合に、コミュニケーションの程度が低いユーザ同士、あるいは今までコミュニケーションをとったことがないユーザ同士で協力してゲームを行うように動機付けることができるようにすること。
【解決手段】複数のユーザの協力によって処理が行われるイベントを含むゲームの実行が制御される。本発明のゲーム制御装置は、ユーザの入力情報に基づいて、当該ユーザを前記イベントに対応付ける対応付け手段と、イベントに対応付けられたユーザの入力情報に基づいて、イベント内の処理を実行する実行手段と、イベントに対応付けられたユーザの数に関する情報を取得する取得手段と、イベントに対応付けられたユーザのイベント内の処理の実行によって、当該ユーザに対して、取得手段によって取得されたユーザの数に関する情報に応じた特典を付与する特典付与手段と、を備える。
【選択図】図１５

Description

本発明は、複数のユーザの各々の操作に応じて、各ユーザによるゲームの進行を制御する技術に関する。

近年、特定のサービス提供者によるソーシャルネットワーキングサービス（ＳＮＳ）においてウェブブラウザ上で動作するＡＰＩ(Application Programming Interface)などの動作環境を基に作成されるゲーム用アプリケーションによって実行される、いわゆるソーシャルゲーム（Social Game）が普及している。ソーシャルゲームは、不特定多数のユーザ間でコミュニケーションをとりながらプレイするオンラインゲームの一種であると言える。ユーザは、インターネットに接続可能であって、かつウェブブラウザが搭載された通信端末を備えていれば、時間と場所を問わずソーシャルゲームを楽しむことができる。

上述したソーシャルゲームでは、従来のオンラインゲームよりも、ユーザ間の交流を図るためのコミュニケーション機能が充実している点が特徴の１つとなっている。ソーシャルゲームでは、例えば、関係付けられたユーザ（仲間）間で協力したゲームの実行のほか、仲間との挨拶や連絡など仲間とコミュニケーションを取ることによる情報交換、仲間との間のゲーム上のアイテムのプレゼントあるいはアイテムの交換が行なわれている。このようなソーシャルゲームの一例として、下記の非特許文献１に記載されたデジタルカードゲーム（ドラゴンコレクション（登録商標））が知られている。

アプリＳＴＹＬＥ Vol.5（株式会社イースト・プレス、平成23年11月15日発行）、7-8頁

従来のソーシャルゲームにおいて、複数のユーザが協力してプレイするように構成されたゲームが存在する。例えば、所定の期間内で特定のユーザが他のユーザと協力して敵キャラクタを攻撃するように構成されているゲームが知られている。しかしながら、このような従来のゲームでは、常に固定化した仲間のユーザ同士で協力してゲームを行う傾向にあり、コミュニケーションの程度が低い他のユーザ、あるいは今までコミュニケーションをとったことがない他のユーザと協力してゲームを行うように動機付ける仕組みとなっていなかった。つまり、従来の協力プレイを利用したゲームでは、十分にソーシャル性を発揮できる仕組みとなっていなかった。

本発明は上述した観点に鑑みてなされたもので、複数のユーザが協力してゲームを行う場合に、コミュニケーションの程度が低いユーザ同士、あるいは今までコミュニケーションをとったことがないユーザ同士で協力してゲームを行うように動機付けることができるゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供することを目的とする。

本発明の第１の観点は、複数のユーザの協力によって処理が行われるイベントを含むゲームの実行を制御するゲーム制御装置である。
このゲーム制御装置は、
ユーザの入力情報に基づいて、当該ユーザを前記イベントに対応付ける対応付け手段（５３）と、
前記イベントに対応付けられたユーザの入力情報に基づいて、前記イベント内の処理を実行する実行手段（５２）と、
前記イベントに対応付けられたユーザの数に関する情報を取得する取得手段（５４）と、
前記イベントに対応付けられたユーザの前記イベント内の前記処理の実行によって、当該ユーザに対して、前記取得手段（５４）によって取得されたユーザの数に関する情報に応じた特典を付与する特典付与手段（５５）と、
を備える。

このゲーム制御装置の実行対象となるゲームには、イベント以外のゲーム要素として、協力プレイによるものだけでなく、ユーザの単独プレイによるものが含まれてもよい。
このゲーム制御装置において、「ユーザの数に関する情報」とは、ユーザの数自体を示す数値データに限られず、当該数値データと同一の値でなくとも当該数値データと連動して変動する情報や、当該数値データに対応付けられた情報であってもよい。

このゲーム制御装置では、所定のイベントに対応付けられるユーザ（例えば、そのイベントに参加しているユーザ）の数に応じて、そのイベント内の処理の実行に伴う特典が付与される。つまり、イベントに対応付けられるユーザが多いほどイベント内の処理の実行に伴って多くの特典が付与されることになる。つまり、固定化した仲間のユーザ同士でイベント内の処理を実行するよりも、より多くのユーザがイベントに参加することが有利となる仕組みとなっている。そのため、このゲーム制御装置によれば、複数のユーザが協力してイベント内の処理を行う場合に、コミュニケーションの程度が低いユーザ同士、あるいは今までコミュニケーションをとったことがないユーザ同士で協力してゲームを行うように動機付けることができる。

上記ゲーム制御装置において、前記対応付け手段（５３）は、前記イベントの開始時刻から所定時間が経過したときに、ユーザの前記イベントへの対応付けを解除してもよい。
この構成により、イベントに参加しているユーザの数に応じて特典を得られるという有利な効果が持続する時間が制限されるため、限られた時間内でのユーザ間のコミュニケーションが促進されるとともに、有利な効果が持続し過ぎることないようにゲーム進行におけるユーザ間の公平性が担保される。

上記ゲーム制御装置において、前記対応付け手段（５３）は、Ｎ番目（Ｎ：２以上の整数）のユーザが前記イベントに対応付けられ、かつ当該ユーザがＮ−１番目に前記イベントに対応付けられたユーザと異なる場合に、前記Ｎ番目のユーザが対応付けられてから、又は前記Ｎ番目のユーザによる前記処理の実行が開始若しくは終了してから所定時間が経過したときに、ユーザの前記イベントへの対応付けを解除してもよい。
この構成により、イベントに対応付けられるユーザが連続して同一ユーザでない場合には、既に対応付けられている複数のユーザのイベントへの対応付けは解除されず、イベントに対応付けられたユーザの数に応じて特典を得られるという有利な効果が持続する。そのため、異なるユーザが入れ替わりイベント内の処理を実行するように動機付けられることになり、例えばイベントに対応付けられているユーザ間でコミュニケーションをとることが促進される。

上記ゲーム制御装置において、前記取得手段（５４）によって取得されたユーザの数が多いほど、前記所定時間を短くしてもよい。
イベントに対応付けられているユーザの数が多いほどより多くの特典が得られる状況となるが、そのような状況が長く継続すると、ゲーム進行におけるユーザ間の公平性が担保されない場合がある。そのため、ユーザの数が多いほど上記所定時間を短くすることで、ゲーム進行におけるユーザ間の公平性を担保することが好ましい。

上記ゲーム制御装置において、前記実行手段（５２）による前記イベント内の処理の実行回数が多いほど、前記所定時間を短くしてもよい。
イベントに対応付けられているユーザの数が多いほど、つまりイベント内の処理の実行回数が多くなるほど、より多くの特典が得られる状況となるが、そのような状況が長く継続すると、ゲーム進行の公平性が担保されない場合がある。そのため、イベント内の処理の実行回数が多いほど上記所定時間を短くすることで、ゲーム進行の公平性を担保することが好ましい。

上記ゲーム制御装置において、ユーザを前記イベントに対応付けるためのユーザの入力を受け付けるタイミングで、前記取得手段（５４）によって取得されたユーザの数に関する情報を、当該ユーザに提示する提示手段（５７）を備えてもよい。
このような提示手段（５７）を備えることで、例えばイベントに参加する（対応付けられる）前にユーザは、既にイベントに参加しているユーザの数がわかるため、これからイベントに参加しようとするときに、ユーザの数に応じた特典の大小を推定できるようになる。そのため、ユーザがイベントに参加することに対する動機付けがより強く働かせることができるようになる。

上記ゲーム制御装置において、前記特典付与手段（５５）は、前記イベントの結果が所定の条件を満たす場合に、前記イベントに対応付けられたユーザに対して、さらに特典を付与してもよい。「所定の条件」は、イベントの種別に応じて適宜決定してよいが、例えば、イベントが複数ユーザで協力してバトルを行うことである場合には、「所定の条件」は、そのバトルで勝利することであってもよい。
この構成では、イベントの結果次第でイベントに参加する（対応付けられる）ユーザに対して追加の特典が付与されるか否かが決定されるため、既にイベントに参加済みのユーザ間で、イベントの結果が所定の条件を満たすように、コミュニケーションをとることが促進される。

前記イベントの結果が所定の条件を満たす場合に付与される特典は、前記イベントが終了した時点において前記取得手段（５４）によって取得されたユーザの数に関する情報に応じた特典であってもよい。
この構成では、イベントが終了する時点までにできるだけ多くのユーザがイベントに参加する（対応付けられる）ことが、既にイベントに参加しているユーザにとって有利である。そのため、ユーザ間で、より多くのユーザがイベントに参加するよう働きかけが行われるようにコミュニケーションをとることが促進される。

上記ゲーム制御装置において、前記対応付け手段（５３）は、Ｎ番目（Ｎ：２以上の整数）のユーザが前記イベントに対応付けられ、かつ当該ユーザがＮ−１番目に前記イベントに対応付けられたユーザと同一である場合に、当該ユーザの前記イベントへの対応付けを解除してもよい。
この構成では、同一のユーザが連続してイベントに対応付けられた場合には、当該ユーザのイベントへの対応付けが解除され、イベントに対応付けられたユーザの数が低減することになる。そのため、より多くのユーザの間で入れ替わり対応付けが行われてイベント内の処理を実行することが動機付けられ、ユーザ間でコミュニケーションをとることが促進される。

上記ゲーム制御装置において、前記対応付け手段（５３）は、Ｎ番目（Ｎ：２以上の整数）のユーザが前記イベントに対応付けられ、かつ当該ユーザがＮ−１番目までに前記イベントに対応付けられたユーザのうちいずれかのユーザと同一である場合に、当該ユーザの前記イベントへの対応付けを解除してもよい。
この構成では、既にイベントに参加済みのユーザが再度イベントに参加して処理を実行した場合には、当該ユーザのイベントへの対応付けが解除され、イベントに対応付けられたユーザの数が低減することになる。つまり、固定化した仲間のユーザ同士で入れ替わりイベントに参加しても多くの特典を得ることができなくなるため、固定化した仲間のユーザ同士でイベント内の処理を実行することが回避される。結果として、複数のユーザが協力してイベント内の処理を行う場合に、コミュニケーションの程度が低いユーザ同士、あるいは今までコミュニケーションをとったことがないユーザ同士で協力してゲームを行うように動機付けることができる。

上記ゲーム制御装置において、前記対応付け手段（５３）は、Ｎ番目（Ｎ：２以上の整数）のユーザが前記イベントに対応付けられ、かつ当該ユーザがＮ−１番目までに前記イベントに対応付けられたユーザのうちいずれかのユーザと同一である場合に、前記所定時間を短くしてもよい。
この構成では、既にイベントに参加済みのユーザが再度イベントに参加して処理を実行した場合、イベントに参加しているユーザの数に応じて特典を得られるという有利な効果が持続する時間が短くなる。そのため、固定化した仲間のユーザ同士で入れ替わりイベントに参加しても多くの特典を得る機会が少なくなるため、固定化した仲間のユーザ同士でイベント内の処理を実行することが回避される。結果として、複数のユーザが協力してイベント内の処理を行う場合に、コミュニケーションの程度が低いユーザ同士、あるいは今までコミュニケーションをとったことがないユーザ同士で協力してゲームを行うように動機付けることができる。

本発明の第２の観点は、複数のユーザの協力によって処理が行われるイベントを含むゲームの実行を制御するゲーム制御方法である。
このゲーム制御方法は、
ユーザの入力情報に基づいて、当該ユーザを前記イベントに対応付けるステップと、
前記イベントに対応付けられたユーザの入力情報に基づいて、前記イベント内の処理を実行するステップと、
前記イベントに対応付けられたユーザの数に関する情報を取得するステップと、
前記イベントに対応付けられたユーザの前記イベント内の前記処理の実行によって、当該ユーザに対して、前記取得するステップによって取得されたユーザの数に関する情報に応じた特典を付与するステップと、
を備える。

本発明の第３の観点は、複数のユーザの協力によって処理が行われるイベントを含むゲームの実行を制御するプログラムである。
このプログラムは、
コンピュータに、
ユーザの入力情報に基づいて、当該ユーザを前記イベントに対応付ける機能、
前記イベントに対応付けられたユーザの入力情報に基づいて、前記イベント内の処理を実行する機能、
前記イベントに対応付けられたユーザの数に関する情報を取得する機能、及び、
前記イベントに対応付けられたユーザの前記イベント内の前記処理の実行によって、当該ユーザに対して、前記取得する機能によって取得されたユーザの数に関する情報に応じた特典を付与する機能、
を実現させるためのプログラムである。

コンピュータは、例えばネットワークサーバ、大型計算機等であってよい。また、このプログラムは、ＤＶＤ−ＲＯＭやＣＤ−ＲＯＭ等のコンピュータが読み取り可能な情報記憶媒体に格納されてもよい。

本発明の第４の観点は、通信端末（１０）と、当該通信端末からアクセスされるサーバ（２０）とを含み、複数のユーザの協力によって処理が行われるイベントを含むゲームの実行を制御するゲームシステムである。
このゲームシステムは、
ユーザの入力情報に基づいて、当該ユーザを前記イベントに対応付ける対応付け手段（５３）、
前記イベントに対応付けられたユーザの入力情報に基づいて、前記イベント内の処理を実行する実行手段（５２）、
前記イベントに対応付けられたユーザの数に関する情報を取得する取得手段（５４）、及び、
前記イベントに対応付けられたユーザの前記イベント内の前記処理の実行によって、当該ユーザに対して、前記取得手段（５４）によって取得されたユーザの数に関する情報に応じた特典を付与する特典付与手段（５５）、
の各手段を、前記通信端末（１０）又は前記サーバ（２０）のいずれか一方が備えた、
を備えた、ゲームシステムである。
なお、上記では、本発明の理解を容易にするため、適宜図面に記載された符号を括弧書きで記載しているが、これにより本発明に係るゲーム制御装置等が図示の態様に限定されるものではない。

本発明のゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムによれば、複数のユーザが協力してゲームを行う場合に、コミュニケーションの程度が低いユーザ同士、あるいは今までコミュニケーションをとったことがないユーザ同士で協力してゲームを行うように動機付けることができる。

実施形態のゲームシステムの基本構成を示す図。 実施形態の通信端末の外観の例を示す図。 実施形態の通信端末の構成を示すブロック図。 実施形態のゲームサーバの構成を示すブロック図。 実施形態のデータベースサーバの構成を示すブロック図。 ユーザデータベースの構成例を示す図。 恐竜キャラクタデータの内容を例示する図。 バトル管理データのデータ構成例を例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 実施形態の通信端末とゲームサーバの間の主要な処理を示すシーケンスチャート。 実施形態の通信端末とゲームサーバの間の主要な処理を示すシーケンスチャート。 実施形態の変形例に係る機能ブロック図。 バトル管理データの更新例を説明するための図。 ゲーム制御装置の各機能について、通信端末と、ゲームサーバ及びデータベースサーバとの間の分担例を示す図。

以下、本発明の実施形態について説明する。

（１）ゲームシステムの構成
図１は、実施形態のゲームシステムのシステム構成例を示している。図１に示すように、このゲームシステムは、例えばインターネットなどの通信網ＮＷ（ネットワーク）に接続可能な通信端末１０ａ，１０ｂ，１０ｃ，…と、通信網ＮＷに接続されているゲームサーバ２０と、データベースサーバ３０とによって構成されている。各通信端末１０ａ，１０ｂ，１０ｃ，…はそれぞれ、個々のユーザによって操作される端末であり、例えば、携帯端末、スマートフォン、ＰＤＡ(Personal Digital Assistant)、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機（いわゆる多機能型のスマートテレビも含む。）などの通信端末である。なお、以下の説明において、各通信端末１０ａ，１０ｂ，１０ｃ，…に共通して言及するときには、通信端末１０と表記する。
このゲームシステムにおいて、ゲームサーバ２０は、クライアントである通信端末１０と通信可能に構成されており、通信端末１０に対してゲーミングサービスを提供する。ゲームサーバ２０には、ゲーム用アプリケーションとしてウェブブラウザ上で動作可能なアプリケーションが実装されている。データベースサーバ３０は、ゲームを実行する上での後述する様々な情報を格納しており、それらの情報の読み書きのためにゲームサーバ２０と例えば有線で接続される。
通信端末１０は、ゲームサーバ２０によって提供されるウェブページを表示可能なウェブブラウザを備えており、ユーザは、通信端末１０でウェブページに対する操作をしてゲームを実行する。

また、図１には図示していないが、ゲームサーバ２０とは別に各通信端末１０のユーザを認証するための認証サーバを設けてもよい。また、多くの通信端末１０からのアクセスを受け入れるために複数のゲームサーバ２０を設ける場合は、その複数のゲームサーバ２０間の負荷を調整するためのロードバランサを設けてもよい。また、ゲームサーバ２０は単一のサーバ装置として構成してもよいが、機能を分散させた複数のサーバ装置として構成してもよい。

（２）通信端末の構成
図２及び図３を参照して通信端末１０について説明する。
図２は、通信端末１０の外観の例を示す図であって、（ａ）は、例えば折り畳み式の携帯端末（携帯電話機）などの釦入力方式の通信端末を例示したものであり、（ｂ）は、例えばスマートフォンなどのタッチパネル入力方式の通信端末を例示したものである。図３は、通信端末１０の内部構成を示すブロック図である。
図３に示すように、通信端末１０は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ(Read Only Memory)１２、ＲＡＭ(Random Access Memory)１３、画像処理部１４、指示入力部１５、表示部１６、及び、信号送受信部としての通信インタフェース部１７を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス１８が設けられている。

ＣＰＵ１１は、ＲＯＭ１２内のウェブブラウザをＲＡＭ１３にロードして実行する。そして、ＣＰＵ１１は、指示入力部１５等によってユーザに入力されるＵＲＬ(Uniform Resource Locator)の適切な指定に基づき、通信インタフェース部１７を介して、ゲームサーバ２０からウェブページを表示するためのデータ、すなわち、ＨＴＭＬ(HyperText Markup Language)文書や当該文書と関連付けられた画像などのオブジェクトのデータ（以下、総称して適宜「ＨＴＭＬデータ」と表記する。）を通信インタフェース部１７を介して取得し、そのＨＴＭＬデータを解釈する。なお、通信端末１０には、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインが実装されていてよい。
なお、ＨＴＭＬデータの取得に当たって、ＣＰＵ１１は、予め登録されたユーザＩＤ（ユーザ識別情報）、あるいは指示入力部１５を介して入力されるユーザＩＤを含むアクセス要求メッセージを、通信インタフェース部１７を介してゲームサーバ２０へ通知する。

ウェブブラウザは、画像処理部１４を介して、取得したＨＴＭＬデータに基づき、ゲームサーバ２０から提供されるウェブページを表示部１６に表示する。また、ウェブブラウザは、ユーザが指示入力部１５の操作によってウェブページ上のハイパーリンク(Hyperlink)またはメニューが選択されると、その選択に応じたウェブページを表示するための新たなＨＴＭＬデータの送信（つまり、ウェブページの更新）をゲームサーバ２０へ要求する。

画像処理部１４は、ＨＴＭＬデータの解析結果としてＣＰＵ１１から与えられる表示用画像データに基づいて、表示部１６にウェブページを表示する。表示部１６は、例えば、マトリクス状に画素単位で配置された薄膜トランジスタを含むＬＣＤ(Liquid Cristal Display)モニタであり、表示用画像データに基づいて薄膜トランジスタを駆動することでウェブページの画像を表示画面１６ａに表示する。

通信端末１０が釦入力方式の通信端末（図２（ａ））である場合、指示入力部１５は、ユーザの操作入力を受け入れるための方向指示釦と決定釦などの複数の指示入力釦を含む釦群１５ａ、及び、テンキーなどの複数の指示入力釦を含む釦群１５ｂを備え、各釦の押下（操作）入力を認識してＣＰＵ１１へ出力するためのインタフェース回路を含む。例えば、方向指示釦は、表示部１６に表示されているウェブページをスクロールして表示することをＣＰＵ１１へ指示するために設けられる。また、決定釦は、例えばウェブページ上で複数のハイパーリンクまたはメニューが表示されるときに、アクティブ表示（例えば強調表示）されている１つのハイパーリンクまたはメニューをユーザが選択することをＣＰＵ１１へ指示するために設けられる。なお、通信端末１０を小型の携帯端末によって構成する場合には、これらの釦は、ユーザが通信端末１０を片手で保持したままその親指で操作（クリック）しやすいように、通信端末１０の前面に配置されていることが好ましい。図２（ａ）に示す例では、釦群１５ｂは、釦群１５ａの下方に配置され、「０」〜「９」、「＊」、「＃」（テンキー）が表記された複数の指示入力釦を含む。

通信端末１０がタッチパネル入力方式の通信端末（図２（ｂ））である場合、指示入力部１５は、主として表示画面１６ａに指先あるいはペンで触れることによるタッチパネル方式の入力を受け付ける。タッチパネル入力方式は、静電容量方式などの公知の方式でよい。なお、図２（ｂ）に示すように、通信端末１０がタッチパネル入力方式の場合であっても釦群１５ａが設けられる場合もある。

通信端末１０に表示されるウェブページ上のメニューの選択操作は、例えば通信端末１０が携帯端末である場合には、方向指示釦の押下操作によってメニューを選択し、決定釦の押下操作によって、選択したメニューを確定することによって行われる。また、選択操作は、例えば通信端末１０がタッチパネル入力方式の場合には、ウェブページが表示されている表示画面１６ａ上のメニューの位置を指あるいはペンで指示（タッチ操作）することによって行われる。

（３）ゲームサーバの構成
図４を参照してゲームサーバ２０の構成について説明する。
ゲームサーバ２０は、例えば階層構造の複数のウェブページからなるゲームのウェブサイトを管理しており、通信端末１０に対してゲームのウェブサービスを提供する。図３に示すように、ゲームサーバ２０は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、データベース（ＤＢ）アクセス部２４、及び、通信インタフェース部２５を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス２６が設けられている。なお、ゲームサーバ２０は、ハードウエアに関しては汎用のウェブサーバと同一の構成をとることができる。

ＲＯＭ２２には、クライアントである通信端末１０のウェブブラウザに対してＨＴＭＬ文書や画像などのオブジェクトの表示（ウェブページの表示）のサービスを提供するアプリケーションプログラムが格納されている。ＲＯＭ２２には、アプリケーションプログラム以外にもＣＰＵ２１によって参照される各種データが格納されている。
ＣＰＵ２１は、ＲＯＭ２２内のゲームプログラムをＲＡＭ２３にロードして実行し、通信インタフェース部２５を介して、各種の処理を行う。

例えば、ＣＰＵ２１は、通信インタフェース部２５を介して、ＨＴＭＬデータを通信端末１０宛に送信する。なお、ゲームサーバ２０が通信端末１０のユーザの認証処理を行う場合には、ＣＰＵ２１はその認証処理を行う。
ＣＰＵ２１は、通信インタフェース部を介して、通信端末１０で表示されるウェブページ上でユーザにより選択されたハイパーリンクまたはメニューに応じた処理を行う。その処理は、例えば、新たなＨＴＭＬデータの送信、または、ゲームサーバ２０内の演算処理あるいはデータ処理などを含む。
データベースアクセス部２４は、ＣＰＵ２１がデータベースサーバ３０に対してデータの読み書きを行うときのインタフェースである。

（４）データベースサーバの構成
データベースサーバ３０（記憶装置）は、大容量のハードディスク装置やＲＡＩＤ（Redundant Arrays of Inexpensive Disks）等の形態の装置等、汎用ストレージで実現できる。データベースサーバ３０内の各データベースは、ゲームサーバ２０のデータベースアクセス部２４を介してＣＰＵ２１からのデータの読み書きが可能となるように構成されている。
図５に、データベースサーバ３０の構成の一例を示す。図５に示すように、データベースサーバ３０は、ユーザデータベース３１と、ゲームデータベース３２とを備える。

本実施形態のゲームシステムによって実現されるゲームのタイプは特に限定されるものではないが、以下では、本実施形態のゲームの一例として、ユーザの通信端末１０に対する操作に応じて、ユーザがゲーム上で仮想的に保有する戦士カードを用いてエリアを探索するクエストを実行するデジタルカードゲーム（以下、適宜「本実施形態のゲーム」という。）を採り上げる。後述するように、クエストの途中でゲーム上の恐竜キャラクタとの間で他のユーザと協力してバトルを行う仕組みとなっている。

図６に、本実施形態のゲームにおいて適用されるユーザデータベース３１の一例を示す。この例では、ユーザデータベース３１は、ユーザＩＤ（ユーザ識別情報）ごとに、ユーザ名、進行レベル、体力ポイント、攻撃ポイント、特典ポイント、恐竜撃破数、仲間のユーザＩＤ、保有カードの各項目についてのデータを含む。ユーザデータベース３１に含まれるデータは、ゲームサーバ２０によって逐次更新されうる。

以下の説明では、ユーザデータベース３１に含まれるユーザＩＤ、あるいはユーザを特定するユーザ名（後述する）ごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータの内容は、以下のとおりである。
・ユーザ名
ゲームの実行時に通信端末１０のユーザを特定するために表示されるユーザ名である。ユーザ名はユーザによって予め指定される所定長以下のテキストである。ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
・進行レベル
ゲーム上のユーザの進行レベル示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値である。ユーザがクエストを実行することで経験値が増加し、経験値が一定値に達すると進行レベルが１だけ増加し、経験値がリセットされる（ゼロになる）。
・体力ポイント
クエストを実行する毎に所定量減少し、所定の時間が経過する毎に回復（増加）するポイントである。ユーザがクエストを実行するときの体力の値を示している。
・攻撃ポイント
本実施形態のゲームにおいて、戦士カードを使用した恐竜キャラクタとのバトルを行う上で必要となるポイントである。ユーザは、１又は複数の保有カードによって恐竜キャラクタとバトルを行うときの攻撃チームを組むことができるが、攻撃チームに含まれる保有カードのポイント消費量（攻撃ポイントの消費量）の総和が攻撃ポイントを超えることはできない。攻撃ポイントは、恐竜キャラクタと１回のバトルを行うことで、攻撃チームに含まれる保有カードのポイント消費量の総和が低減し、所定の時間が経過する毎に回復（増加）する。
・特典ポイント
恐竜キャラクタとバトルを行ったときに恐竜キャラクタに与えたダメージに応じて得られる特典である。
・恐竜撃破数
本実施形態のゲームにおいて、ユーザがバトルによって撃破した恐竜キャラクタの数である。
・仲間のユーザＩＤ
対象となるユーザＩＤと関係付けられた他のユーザＩＤのデータである。
・保有カードのデータ
保有カードのデータは、ユーザが保有している戦士カード（保有カード）のデータであり、例えば、図６に示すように、戦士カードのカードＩＤ（ＷＲ０８０等）と、ポイント消費量（攻撃ポイントの消費量）と、攻撃力及び防御力のパラメータの値とから構成される。本実施形態のゲームでは、戦士カードが恐竜キャラクタとバトルを行うときに、攻撃力の値が大きいほど恐竜キャラクタに対して多くのダメージを与えることができ、防御力の値が大きいほど恐竜キャラクタから攻撃を受けたときにダメージを受け難くすることができる設定となっている。

図５に戻り、ゲームデータベース３２は、ゲームサーバ２０からのアクセスに基づき、ゲームサーバ２０によって実行されたゲームの進行に関する情報、恐竜キャラクタに関するデータ（恐竜キャラクタデータ）、バトル管理データを記憶する。ゲームの進行に関する情報は、ゲームの性質によって多様な情報を含みうる。本実施形態のゲームの場合を例に挙げれば、ゲームの進行に関する情報は、各ユーザのクエストの実行結果や、恐竜キャラクタとのバトルの詳細情報などを含んでもよい。

恐竜キャラクタデータの一例を図７に示す。恐竜キャラクタデータは、バトルの相手となる恐竜キャラクタに関するデータを含む。恐竜キャラクタデータは、恐竜キャラクタに固有のキャラクタＩＤ（ＤＣ１，ＤＣ２，ＤＣ３，…）ごとに、恐竜キャラクタの画像と、恐竜キャラクタの体力を示すＨＰ(Hit Point)の値とが対応付けられている。例えば、図７に示す例では、各恐竜キャラクタのＨＰは１５００〜２０００の範囲内であるが、この範囲の中からバトルを行うときにランダムにＨＰの値が設定されてもよい。
後述するように、恐竜キャラクタデータの中からバトル相手となる恐竜キャラクタが選択されると、その恐竜キャラクタのデータが例えばＲＡＭ２３にロードされる。

バトル管理データは、ユーザごとにバトルの状態を管理するためのデータである。図８にバトル管理データのデータ構成例を示す。図８に示すバトル管理データでは、ユーザ（ユーザ名又はユーザＩＤ）ごとに、バトルＩＤ、バトル相手、消滅時刻、バトル履歴、残ＨＰ、追撃レベル、追撃終了時刻、及び、撃破フラグの各項目についてのデータを含む。
各項目のデータの内容は、以下のとおりである。

・バトルＩＤ
恐竜キャラクタが出現したときに、その恐竜キャラクタと行われる一連のバトルを識別するための識別情報（図８の例では、識別番号）である。本実施形態のゲームでは、ユーザがクエストを実行中に恐竜キャラクタと遭遇し、その恐竜キャラクタとのバトルが開始されるが、恐竜キャラクタと遭遇したユーザを、以下の説明では「発見ユーザ」という。バトル管理データでは、バトルＩＤは、発見ユーザに対応付けて記述される。
発見ユーザと恐竜キャラクタとの間のバトル、及び、後述する支援ユーザと恐竜キャラクタとのバトルはすべて、共通のバトルＩＤに対応付けて管理される。なお、発見ユーザと恐竜キャラクタとの間のバトル、及び、後述する支援ユーザと恐竜キャラクタとのバトルを総称して、「恐竜キャラクタとのバトル」と適宜表記する。なお、本発明のイベントは、複数のユーザによって処理が行われるイベントであるが、本実施形態において、発見ユーザ及び支援ユーザによる共通の恐竜キャラクタとのバトルは、イベントの一例である。
・バトル相手
特定のバトルにおいてバトルの相手となる恐竜キャラクタを示す。
・消滅時刻
特定のバトルにおいてバトル相手の恐竜キャラクタが消滅する時刻である。本実施形態のゲームでは、恐竜キャラクタを消滅時刻までに撃破した場合に、恐竜撃破数が増加する。
・バトル履歴
本実施形態のゲームでは、発見ユーザが恐竜キャラクタを撃破できなかった場合には、発見ユーザは他のユーザに対して支援要請を行うことができ、支援要請を受諾したユーザがその恐竜キャラクタとバトルを行うことができるように構成されている。支援要請を受諾してバトルを行うユーザを、以下の説明では「支援ユーザ」という。
バトル履歴の項目には、発見ユーザ（図８の例では、ユーザＫＮＭ）と、バトルに対応付けられた１又は複数の支援ユーザ（図８の例では、ユーザＡＢＣ，ユーザＱＲＳ）が順に記述されている。また、発見ユーザと支援ユーザの各々と恐竜キャラクタとのバトルによる恐竜キャラクタのＨＰ低下量が記述される。
・残ＨＰ
バトル相手の恐竜キャラクタの残りのＨＰを示す。図８の例では、発見ユーザであるユーザＫＮＭと恐竜キャラクタのバトルの結果、恐竜キャラクタの残ＨＰが２０００から１１００まで低下したことを意味している。
・追撃レベル
特定のバトルにおいて、支援を行ったユーザの数（つまり、特定のバトルに対応付けられた、異なるユーザＩＤの支援ユーザの数）と同一の値である。追撃レベルは、後述する追撃終了時刻まで上昇可能な値である。本実施形態のゲームでは、同一の攻撃チームを使用する場合に、追撃レベルが増加すればするほど、恐竜キャラクタに与えるダメージ（つまり、ＨＰの低下量）がより大きくなるように構成されている。
・追撃終了時刻
追撃レベルが上昇可能な追撃期間の終期である。追撃終了時刻に達すると、追撃レベルがリセットされる（つまり、ゼロに戻る）。
・撃破フラグ
バトル相手の恐竜キャラクタが撃破されたか否かを示すフラグである。撃破フラグが「０」である場合には恐竜キャラクタが撃破されていないことを意味し、撃破フラグが「１」である場合には恐竜キャラクタが撃破されたことを意味する。

（５）本実施形態のゲーム
以下、本実施形態のゲームの恐竜キャラクタとのバトル処理について、図９〜１４を参照しながら説明する。
図９は、ユーザがクエスト実行中に恐竜キャラクタと遭遇するときのウェブページの表示例を示す図である。図１０は、発見ユーザが恐竜キャラクタとバトルを行うときのウェブページの表示例を示す図である。図１１は、発見ユーザが支援要請を行うときのウェブページの表示例を示す図である。図１２は、１番目の支援ユーザが恐竜キャラクタとバトルを行うときのウェブページの表示例を示す図である。図１３は、２番目の支援ユーザが恐竜キャラクタとバトルを行うときのウェブページの表示例を示す図である。図１４は、バトルに参加しているユーザ間でメッセージの送受信を行うときのウェブページの表示例を示す図である。
なお、以下の説明において、通信端末１０に表示されるウェブページ上で表示されるメニュー、マーク等はウェブページ上で所望の位置に配置されるものであって、通信端末１０で視認されるメニュー、マーク等の表示画面上の位置は、ユーザの方向指示釦あるいはタッチパネル操作によるウェブページのスクロール操作によって変化しうる。

（５−１）恐竜キャラクタとの遭遇（図９）
図９のトップページＰ０は個々のユーザＩＤに応じたウェブページで構成されるが、図９の例では、ユーザＫＮＭのトップページＰ０を示している。
図９の例では、トップページＰ０は、ユーザデータ表示領域、戦士画像表示領域及びメニュー表示領域を含む。ユーザデータ表示領域は、対象となるユーザＩＤのユーザデータに含まれる、進行レベル、体力ポイント、攻撃ポイント、特典ポイント、恐竜撃破数の各項目のデータ（図６参照）が表示される領域である。
戦士画像表示領域は、対象となるユーザＩＤのユーザデータに含まれる複数の戦士カードのうちユーザによって予め指定された戦士カードの画像が表示される領域である。
メニュー表示領域は、本実施形態のゲームにおいて、クエスト処理の実行を開始するためのメニューｍ１を含む複数のメニュー（メニューｍ１以外は図示せず）が表示される領域である。なお、クエスト処理とは、アイテムを取得するためにエリアを探索する処理である。

図９のゲームのトップページＰ０上でメニューｍ１が選択操作されると、Ｐ１に示すようにウェブページが更新される。このウェブページＰ１には、ユーザがクエストとしてエリアを探索するためのメニューｍ５（「探索する」）が含まれる。メニューｍ５が選択操作される度に、所定の、あるいはランダムな確率で、ゲーム上で用意されている様々なアイテムのいずれかをユーザが入手できるように構成してもよい。メニューｍ５が選択操作される度に一定の、あるいはランダムな増加量で進行度の値が増加し、進行度が１００％に達するとエリアの探索が終了する。メニュー５が選択操作される度に、ユーザＫＮＭの体力ポイントが所定量だけ消費され（図９の例では、−５）、ユーザＫＮＭの経験値が所定量だけ増加する（図９の例では、＋８）。探索対象のエリアは、複数設けられてもよく、実行中のエリアの達成率が１００％に達すると次のエリアに移動できるとしてもよい。
体力ポイントが上記所定量未満になった場合にはクエスト処理を実行することはできない。その場合には、体力ポイントが回復するまでユーザＫＮＭは待機する必要がある。

メニューｍ５の選択操作に応じてランダムなタイミングで、あるいは、所定数のエリアのクエストが完了すると、ユーザＫＮＭは恐竜キャラクタに遭遇する仕組みとなっている。例えば、図９のウェブページＰ２では、ユーザＫＮＭが遭遇した恐竜キャラクタＤＣ１（「恐竜ＤＣ１」）の画像と、メニューｍ１０（「バトルする」）及びメニューｍ１１（「バトルしない」）とが含まれる。この場合、発見ユーザは、ユーザＫＮＭである。ウェブページＰ２においてメニューｍ１０が選択操作されると、Ｐ３に示すようにウェブページが更新される。このウェブページＰ３では、例えば、遭遇した恐竜キャラクタが消滅するまでの時間（つまり、消滅時刻までの時間）と、プルダウンメニューｍ１５とが表示される。

プルダウンメニューｍ１５は、所定数の攻撃チーム、例えば攻撃チーム１〜３のいずれかを選択することができるように設定されている。この場合、プルダウンメニューｍ１５に設定される複数の攻撃チームは、例えば、以下のように予め設定されてもよいが、ウェブページＰ３が表示される時点でユーザＫＮＭの攻撃ポイントが少ない場合には、選択できない攻撃チームもありうる。
・攻撃チーム１：ユーザの攻撃ポイントの最大値の１００％を消費して、ユーザが保有する戦士カードの中から編成した攻撃チーム
・攻撃チーム２：ユーザの攻撃ポイントの最大値の６０％を消費して、ユーザが保有する戦士カードの中から編成した攻撃チーム
・攻撃チーム３：ユーザの攻撃ポイントの最大値の３０％を消費して、ユーザが保有する戦士カードの中から編成した攻撃チーム

（５−２）発見ユーザと恐竜キャラクタとのバトル（図１０）
図９のウェブページＰ３においてユーザＫＮＭの攻撃チームが選択操作されると、図１０のＰ４に示すようにウェブページが更新される。すなわち、選択された攻撃チームに含まれる戦士カードを使用してユーザＫＮＭが恐竜キャラクタＤＣ１との間でバトルを実行するためのウェブページに切り替わる。
ウェブページＰ４は、ユーザＫＮＭがバトルで使用する複数枚の戦士カードからなる攻撃チームＴＭの画像と、バトル相手の恐竜キャラクタＤＣ１の画像と、恐竜キャラクタＤＣ１のＨＰ(Hit Point)を示すＨＰゲージと、メニューｍ２０（「攻撃する」）とを含む。ＨＰは、恐竜キャラクタの体力を示す値である。ユーザＫＮＭが使用する戦士カードがすべて倒される前に恐竜キャラクタのＨＰをゼロにできれば、ユーザＫＮＭがバトルに勝利して恐竜キャラクタＤＣ１を撃破したことを意味し、ユーザＫＮＭが使用する戦士カードがすべて倒された時点で恐竜キャラクタのＨＰがゼロになっていなければ、ユーザＫＮＭがバトルで敗北したことを意味する。

ウェブページＰ４においてメニューｍ２０が選択操作されると、Ｐ５に示すようにウェブページが更新される。ウェブページＰ５では、ウェブページＰ４と比べて、ユーザＫＮＭがバトルに使用する戦士カードによって恐竜キャラクタＤＣ１に対する攻撃が行われ、その結果、恐竜キャラクタのＨＰが低下した場合が示されている。なお、メニューｍ２０が選択操作される度にバトル相手の恐竜キャラクタから戦士カードに対して攻撃が加えられる。
ウェブページＰ６に示すように、恐竜キャラクタＤＣ１のＨＰがゼロに達した時点で攻撃チーム内のいずれかの戦士カードが倒されずに残っていれば、ユーザＫＮＭがバトルに勝利し、恐竜キャラクタＤＣ１が撃破されたことになる。

他方、ウェブページＰ７に示すように、恐竜キャラクタＤＣ１のＨＰがゼロに達する前にすべての戦士カードが倒されると、ユーザＫＮＭがバトルに敗北したことになる。ウェブページＰ７では、ユーザＫＮＭとのバトルによって恐竜キャラクタＤＣ１が怯んだ状態となっていることが通知される。恐竜キャラクタが怯んだ状態となっている期間が、追撃レベルが上昇可能な追撃期間である。ウェブページＰ７の例では、追撃期間が８分であること（「復活まで、あと８分！」）と表示されている。この追撃期間内に、恐竜キャラクタに対して攻撃が行われた場合には、通常よりも多くのダメージを恐竜キャラクタに与えられるように構成されている。また、恐竜キャラクタＤＣ１の消滅時刻までの時間(ウェブページＰ７の例では、２０分)も表示されている。ウェブページＰ７が表示される時点では、支援ユーザが１度もバトルを実行していないため、追撃レベルが「０」と表示されている。
ウェブページ７には、他のユーザに対して支援要請を行うためのメニューｍ２１（「支援要請する」）と、再度自ら攻撃を行うためのメニューｍ２２（「もう一度攻撃する」）とが表示される。例えば、図９のウェブページＰ３において攻撃チーム３を選択した場合等、少ない攻撃ポイントを消費してウェブページＰ４，Ｐ５での攻撃を行った場合には、ユーザＫＮＭの攻撃ポイントが十分に残っている場合がある。その場合には、ユーザＫＮＭは、メニューｍ２２を選択して直ちに恐竜キャラクタＤＣ１と再度バトルを行うことができる。
なお、ウェブページＰ７では、メニューｍ２１及びメニューｍ２２を設けた例について説明したが、これに限られない。ユーザＫＮＭが敗北した場合に、自動的に他のユーザに支援要請が行われるようにしてもよい。その場合には、ウェブページＰ７には、ユーザＫＮＭが敗北したため支援要請が行われたことを通知するテキストが表示される。

（５−３）発見ユーザによる支援要請（図１１）
図１１のウェブページＰ７（図１０のウェブページＰ７と同じ）において、メニューｍ２１（「支援要請する」）が選択操作されると、Ｐ８に示すようにウェブページが更新されて、ユーザＫＮＭの支援要請が受け付けられたことが通知される。
なお、図９〜１１に関連付けて、発見ユーザが恐竜キャラクタを撃破できなかったときに、発見ユーザが他のユーザに対して支援要請を行う場合について説明したが、これに限られない。発見ユーザは、自ら恐竜キャラクタとのバトルを行わずに支援要請を行うことができるようにしてもよい。その場合には、図９のウェブページＰ２において、支援要請を行うためのメニューを設けるようにすればよく、当該メニューの選択操作に応じて、ユーザＫＮＭの支援要請が受け付けられる。

（５−４）１番目の支援ユーザと恐竜キャラクタとのバトル（図１２）
図１２に示す例では、１番目の支援ユーザがユーザＡＢＣである場合を例にしている。
ユーザＫＮＭによる支援要請が受け付けられると、その支援要請を例えばクエストを実行中の他のユーザが閲覧することができる仕組みとなっている。図１２のウェブページＰ９は、ユーザＡＢＣがクエストを実行中に表示されるウェブページであり、ユーザＫＮＭからの支援要請を受諾するか否かを選択するためのメニューｍ３１（「受諾する」）及びメニューｍ３２（「受諾しない」）が表示されている。好ましくは、ウェブページＰ９では、支援対象のバトルについての情報として、バトル相手の恐竜キャラクタ及び残ＨＰのデータ、恐竜キャラクタの消滅時刻までの残り時間（２０分）、追撃終了時刻までの残り時間（８分）、及び現在の追撃レベル（０）の例が表示されている。

ウェブページＰ９においてメニューｍ３１（「受諾する」）が選択操作されると、図９のウェブページＰ３に示したのと同様に攻撃チームを選択するためのウェブページ（図示せず）が表示され、ユーザＡＢＣと恐竜キャラクタＤＣ１とのバトルが開始される。恐竜キャラクタＤＣ１のＨＰゲージは、図１０のウェブページＰ７で表示されているものと同じ値となっている。バトルが開始された後のウェブページの表示の変化は、発見ユーザと恐竜キャラクタＤＣ１とのバトルと同様であるが、ウェブページＰ１０では、追撃レベルが０→１に上昇して表示される。つまり、支援ユーザＡＢＣによるバトルの開始によって、支援ユーザの数が０→１と変化したため、追撃レベルが０→１に上昇している。

図１２では、発見ユーザＫＮＭと同様に、１番目の支援ユーザＡＢＣもバトルに敗北した場合の表示例がウェブページＰ１１に示されている。ウェブページＰ１１に示すように、恐竜キャラクタＤＣ１のＨＰがゼロに達する前にすべての戦士カードが倒されると、ユーザＡＢＣがバトルに敗北したことになる。ウェブページＰ１１では、ユーザＡＢＣとのバトルによって恐竜キャラクタＤＣ１が怯んだ状態となっていることが通知される。ウェブページＰ１１の例では、追撃期間が３分であること（「復活まで、あと３分！」）と表示されている。この追撃期間内に、恐竜キャラクタに対して攻撃が行われた場合には、通常よりも多くのダメージを恐竜キャラクタに与えられるように構成されている。また、恐竜キャラクタＤＣ１の消滅時刻までの時間(ウェブページＰ１１の例では、１５分)も表示されている。ウェブページＰ１１が表示される時点では、支援ユーザが１人であるため、追撃レベルが「１」と表示されている。
ウェブページＰ１１には、再度自ら攻撃を行うためのメニューｍ２２（「もう一度攻撃する」）が表示される。ユーザＡＢＣの攻撃ポイントが十分に残っている場合には、ユーザＡＢＣは、メニューｍ２２を選択して直ちに恐竜キャラクタＤＣ１と再度バトルを行うことができる。

（５−５）２番目の支援ユーザと恐竜キャラクタとのバトル（図１３）
図１３に示す例では、２番目の支援ユーザがユーザＱＲＳである場合を例にしている。２番目の支援ユーザは、発見ユーザによる支援要請を２番目に受諾したユーザである。
図１３のウェブページＰ１２は、ユーザＱＲＳがクエストを実行中に表示されるウェブページであり、ユーザＫＮＭからの支援要請を受諾するか否かを選択するためのメニューｍ３１（「受諾する」）及びメニューｍ３２（「受諾しない」）が表示されている。好ましくは、ウェブページＰ１２では、支援対象のバトルについての情報として、バトル相手の恐竜キャラクタ及び残ＨＰのデータ、恐竜キャラクタの消滅時刻までの残り時間（１５分）、追撃終了時刻までの残り時間（３分）、及び現在の追撃レベル（１）の例が表示されている。

ウェブページＰ１２においてメニューｍ３１（「受諾する」）が選択操作されると、図９のウェブページＰ３に示したのと同様に攻撃チームを選択するためのウェブページ（図示せず）が表示され、ユーザＱＲＳと恐竜キャラクタＤＣ１とのバトルが開始される。恐竜キャラクタＤＣ１のＨＰゲージは、図１２のウェブページＰ１１で表示されているものと同じ値となっている。バトルが開始された後のウェブページの表示の変化は、１番目の支援ユーザと恐竜キャラクタＤＣ１とのバトルと同様であるが、ウェブページＰ１３では、追撃レベルが１→２に上昇して表示される。つまり、支援ユーザＱＲＳによるバトルの開始によって、支援ユーザの数が１→２と変化したため、追撃レベルが１→２に上昇している。

図１３では、２番目の支援ユーザＱＲＳがバトルに勝利した場合の表示例がウェブページＰ１４に示されている。ウェブページＰ１４に示すように、恐竜キャラクタＤＣ１のＨＰがゼロに達した時点で攻撃チーム内のいずれかの戦士カードが倒されずに残っていれば、ユーザＱＲＳがバトルに勝利し、恐竜キャラクタＤＣ１が撃破されたことになる。

（５−６）バトルに参加しているユーザ間でのメッセージの送受信（図１４）
「バトルに参加しているユーザ」とは、発見ユーザと支援ユーザを意味する。
本実施形態のゲームでは、恐竜キャラクタに遭遇してからその恐竜キャラクタが撃破されるか、消滅するまでの間（つまり、恐竜キャラクタとのバトルが行われている間）、そのバトルに参加しているユーザ間でメッセージの送信及び受信が可能となるように構成されている。図１４では、発見ユーザＫＮＭと１番目の支援ユーザＡＢＣとの間で、メッセージの送信及び受信が行われる場合が例示されている。

図１４のウェブページＰ１５に示すように、例えばクエストを実行中のユーザＫＮＭ向けのウェブページ上では、特定のバトルに参加しているユーザ（発見ユーザと支援ユーザ）のリストが表示される。発見ユーザであるユーザＫＮＭ向けのリストには、支援ユーザであるユーザＡＢＣ，ユーザＱＲＳが選択操作可能に表示される。ウェブページＰ１５において例えばユーザＡＢＣが選択操作されると、Ｐ１６に示すようにウェブページが更新される。ウェブページＰ１６には、選択されたユーザＡＢＣ宛てのメッセージを入力するためのテキストボックスｂ１とメニューｍ４０（「送信」）が表示されている。

ウェブページＰ１６においてユーザＫＮＭがメッセージをテキストボックスｂ１に入力した状態でメニューｍ４０が選択操作されると、メッセージがゲームサーバ２０へ送信される。メッセージがゲームサーバ２０に正しく受信されると、そのメッセージがゲームサーバ２０に受け付けられる。
ユーザＫＮＭからのメッセージが受け付けられた後、例えばクエストを実行中のユーザＡＢＣ向けのウェブページが更新されると、更新後のウェブページには、Ｐ１７に示すようにユーザＫＮＭからのメッセージが表示される。

（６）ゲーム制御装置における各処理の概要
次に、上述した本実施形態のゲームを実現するためゲーム制御装置における各処理について説明する。
本実施形態では、ゲームサーバ２０及びデータベースサーバ３０によってゲーム制御装置が構成されている。以下では、上述したデジタルカードゲームが適用される場合を例として、本実施形態のゲーム制御装置で実現される機能について、図１５を参照して説明する。図１５は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。なお、図１５の機能ブロック図中、登録手段５１及び通信手段５６は、必ずしも必須の構成要素ではない。

登録手段５１は、例えば通信端末１０に提供するウェブページ上での通信端末１０への適切な操作入力に基づいてユーザの登録要求を認識し、登録処理を行う機能を備える。この登録処理は、ユーザが本実施形態のゲームにユーザ登録を行うときに実行される。
登録手段５１の機能は、例えば以下のように実現される。ゲームサーバ２０のＣＰＵ２１は、通信インタフェース部２５を介して通信端末１０から登録要求メッセージを受信する。登録要求メッセージは、ゲームサーバ２０から提供されるウェブページ上での通信端末１０に対する所定の操作（例えば、所定のメニューの選択操作やユーザが指定するユーザＩＤやパスワード等のテキスト入力等）によって自動的に生成されるように、ウェブページが構成されていてもよい。登録要求メッセージには、送信元の通信端末１０を特定するための情報（例えばＵＩＤ（Unique Identifier）などの端末の個体識別情報、メールアドレス等）が含まれていてもよく、あるいは、ユーザが既に同一のサービス提供者による他のゲームを利用している場合には、そのユーザＩＤが含まれていてもよい。

ＣＰＵ２１は、登録要求メッセージを受信し、登録要求メッセージにユーザＩＤが含まれていない場合には、ユーザＩＤを新規に発行してそのユーザＩＤの登録処理を行った後、登録処理が完了した旨のメッセージを通信端末１０へ送信する。ＣＰＵ２１は、登録要求メッセージを受信し、登録要求メッセージにユーザＩＤが含まれている場合には、そのユーザＩＤの登録処理を行った後、登録処理が完了したことを示す登録完了メッセージを通信端末１０へ送信する。
登録が完了すると、ＣＰＵ２１は、ユーザＩＤに対応するユーザデータを生成し、ユーザデータベース３１に格納する。登録が完了すると、ユーザは、本実施形態のゲームを実行することが可能となる。

登録手段５１は、異なるユーザ間を関連付けて登録する機能をも備えていていもよい。つまり、登録手段５１は、例えばユーザＩＤに基づく申請を契機として、当該ユーザＩＤを他のユーザＩＤとを関連付けて記録してもよい。すなわち、登録手段５１は、ユーザＩＤに基づく申請を契機として、他のユーザＩＤ（つまり、他のユーザ）を「仲間」として記録してもよい。
この場合の登録手段５１の機能は例えば、以下のように実現される。ゲームサーバ２０ａのＣＰＵ２１は、通信インタフェース部２５を介して、あるユーザＩＤに対応するユーザの通信端末１０から、仲間になりたいユーザＩＤ（あるいは、対応するユーザ名）を指定した申請メッセージ（仲間申請）を受け付ける。この申請メッセージの送信は、ユーザの通信端末１０に提供されるウェブページの機能として予め設定されてもよい。
ＣＰＵ２１は、申請メッセージを受け付けると、申請先ユーザのユーザデータの「仲間申請」の項目に申請元ユーザのユーザＩＤを書き込む。さらにＣＰＵ２１は、申請メッセージに含まれるユーザＩＤに基づくアクセスがあったタイミングで、そのユーザＩＤに対応する通信端末１０宛に、他のユーザＩＤに基づく申請を承認するか否かを返信することを要求するウェブページを表示するためのＨＴＭＬデータを送信する。その申請を承認することが返信されれば、ＣＰＵ２１は、両者を仲間として登録する。具体的には、ＣＰＵ２１は、ユーザデータベース３１内の対応する２つのユーザＩＤのユーザデータの「仲間のユーザＩＤ」の箇所（図６参照）にデータ（相手のユーザＩＤ）を書き込む。なお、ＣＰＵ２１は、仲間申請先のユーザの承認を不要とする場合は、ゲームを実行中のユーザによる所定の操作を契機として、両者を仲間として登録しても良い。

ゲーム実行手段５２は、ユーザによるゲームを実行する機能を備える。
ゲーム実行手段５２の機能は、例えば、通信端末１０に表示するウェブページを、通信端末１０からの要求に応じて逐次更新させることによって、ゲーム上のバトルを実行するようにしてもよい。この場合、ゲーム実行手段５２の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、通信端末１０からＨＴＴＰリクエストを受信し、そのＨＴＴＰリクエストに応じてゲーム上の所定の処理を行い、ゲームの実行結果としてのＨＴＭＬデータを含むＨＴＴＰレスポンスを通信端末１０へ返信する。

［クエスト処理］
実行対象のゲームの内容が例えば図９に関連付けて説明したクエストである場合、ゲームサーバ２０のＣＰＵ２１は、ユーザによるメニューｍ５（「探索する」）の選択操作結果を含むＨＴＴＰリクエストを受信すると、処理対象のユーザの進行度、体力ポイント、及び経験値を更新する処理を行う。ＣＰＵ２１は、ユーザの進行度、体力ポイント、及び経験値のデータを、クエストの実行開始時（メニューｍ１の選択時）にデータベースサーバ３０からＲＡＭ２３に転送し、クエスト中はＲＡＭ２３内のデータに対して更新処理を行い、クエスト終了時に、ＲＡＭ２３内の更新後のデータをデータベースサーバ３０内のデータに上書きするようにしてもよい。
メニューｍ５の選択操作に応じてランダムなタイミングで、あるいは、所定数のエリアのクエストが完了すると、ＣＰＵ２１は、ユーザを恐竜キャラクタに遭遇させることを決定する。このとき、ＣＰＵ２１は、恐竜キャラクタデータにアクセスして遭遇対象（つまりバトル相手）となるいずれかの恐竜キャラクタを例えばランダムに選択する。

［バトル処理］
ゲーム実行手段５２は、恐竜キャラクタとのバトル処理において、特定のバトル（イベント）の発見ユーザ及び支援ユーザ（イベントに対応付けられたユーザ）の入力情報に基づいて、当該バトル内の処理を実行する機能を備える。本実施形態では、入力情報は、ユーザの選択操作結果を含むＨＴＴＰリクエストである。

バトル処理におけるゲーム実行手段５２の機能は、例えば以下のようにして実現することができる。ゲームサーバ２０のＣＰＵ２１は先ず、実行対象のゲームの内容が例えば図１０に関連付けて説明した恐竜キャラクタとのバトルである場合、選択した恐竜キャラクタとのＨＰを恐竜キャラクタデータから読み出してＲＡＭ２３に記憶させるとともに、読み出したデータに基づいてＨＴＭＬデータを生成する。

バトルの開始前に、ＣＰＵ２１は、ユーザによる攻撃チームの選択操作に応じて、ユーザが保有する戦士カードの中からバトルで使用される戦士カードを選択する。
例えば、上述した攻撃チーム１が選択された場合には、ＣＰＵ２１は、ユーザの攻撃ポイントの最大値の１００％を消費してユーザの保有カードの中から戦士カードを選択する。このとき、ＣＰＵ２１は、例えば攻撃力の高い戦士カードから順に選択するとともにポイント消費量を積算していき、その積算値が攻撃ポイントの最大値の１００％を超えない範囲で最大枚数の戦士カードを選択する。戦士カードを選択した後は、ＣＰＵ２１は、ユーザの現在の攻撃ポイントからポイント消費量の積算値を減算して新たな攻撃ポイントを算出し、ユーザデータに記憶する。
上述した攻撃チーム２が選択された場合には、ＣＰＵ２１は、ユーザの攻撃ポイントの最大値の６０％を消費してユーザの保有カードの中から戦士カードを選択する。このとき、ＣＰＵ２１は、例えば攻撃力の高い戦士カードから順に選択するとともにポイント消費量を積算していき、その積算値が攻撃ポイントの最大値の６０％を超えない範囲で最大枚数の戦士カードを選択する。戦士カードを選択した後は、ＣＰＵ２１は、ユーザの現在の攻撃ポイントからポイント消費量の積算値を減算して新たな攻撃ポイントを算出し、ユーザデータに記憶する。
上述した攻撃チーム３が選択された場合には、ＣＰＵ２１は、ユーザの攻撃ポイントの最大値の３０％を消費してユーザの保有カードの中から戦士カードを選択する。このとき、ＣＰＵ２１は、例えば攻撃力の高い戦士カードから順に選択するとともにポイント消費量を積算していき、その積算値が攻撃ポイントの最大値の３０％を超えない範囲で最大枚数の戦士カードを選択する。戦士カードを選択した後は、ＣＰＵ２１は、ユーザの現在の攻撃ポイントからポイント消費量の積算値を減算して新たな攻撃ポイントを算出し、ユーザデータに記憶する。

ＣＰＵ２１は、バトル相手の恐竜キャラクタのデータを、バトル管理データに新たに書き込む。このとき、恐竜キャラクタのデータのＨＰの初期値がランダムに決定される。例えば、恐竜キャラクタデータにおいて恐竜キャラクタＤＣ１のＨＰが１５００〜２０００の範囲として設定されているが、実際のバトル処理を行うときに使用されるＨＰの初期値として、１５００〜２０００の範囲の中からランダムに１つの値が決定される。

ＣＰＵ２１は、出現中の恐竜キャラクタのデータをバトル管理データから読み出し、バトルで使用される戦士カードのデータをユーザデータから読み出して、ＲＡＭ２３に記憶させ、以下のバトル処理を実行する。
具体的には、恐竜キャラクタとのバトルにおいて例えばメニューｍ２０（「攻撃する」）が選択操作され、ユーザが戦士カードを使って恐竜キャラクタを攻撃するとき（例えば図１０のウェブページＰ４，Ｐ５等）には、ＣＰＵ２１は、使用される攻撃チームを構成する戦士カードの攻撃力の総和に応じて恐竜キャラクタのＨＰを低減させる処理を行う。なお、バトル中に倒された戦士カードの攻撃力については、攻撃力の総和の算出対象とはならない。以下、メニューｍ２０（「攻撃する」）に対する操作を「攻撃操作」という。
例えば、攻撃チームの攻撃力の総和をＰａとし、追撃レベルに応じて決定される係数をｋとすると、１回の攻撃操作によって、恐竜キャラクタのＨＰに対して行われる演算は、例えば以下の式（１）に従って行われるようにしてもよい。更新されたＨＰの値は、バトル実行中に逐次ＲＡＭ２３に上書きされる。

ＨＰ＝ＨＰ−Ｐａ×ｋ …（１）

ここで、係数ｋは、追撃レベルが上昇するほど増加する値である。一例を挙げれば、
・追撃レベルが０のときに、ｋ＝１．０
・追撃レベルが１のときに、ｋ＝１．２
・追撃レベルが２のときに、ｋ＝１．４
・追撃レベルが３のときに、ｋ＝１．６
などとテーブル形式で規定してもよい。
また、追撃レベルをＬとしたときに、ｋ＝（１＋Ｌ）と演算式によって求めるようにしてもよい。いずれの場合も、追撃レベルが上昇するほど、つまり支援ユーザの数が増加するほど、ユーザの攻撃チームによる攻撃によって、より多くのダメージ（ＨＰの低下量）が恐竜キャラクタに与えられるような仕組みとなっている。

また、攻撃操作に応じてバトル相手の恐竜キャラクタから攻撃チームに対して、一定の、あるいはランダムな値の攻撃力にて攻撃が加えられる。恐竜キャラクタの攻撃力は、ＨＰに概ね比例した値としてもよいし、一定の、あるいはランダムな値であってもよい。ＣＰＵ２１は、例えば、恐竜キャラクタから攻撃チームに対して加える攻撃力、あるいはその攻撃力の積算値（複数回の攻撃操作に伴う攻撃力の積算値）に応じて、ユーザの攻撃チームのうち倒される戦士カードの枚数を決定する。倒される戦士カードの枚数は、例えば、戦士カードに含まれる戦士カードの防御力の総和が大きいほど少なくしてもよい。
ＣＰＵ２１は、攻撃チームに含まれる戦士カードがすべて倒され、かつ恐竜キャラクタのＨＰがゼロになっていない場合には、ユーザの敗北であると判断する。他方、ＣＰＵ２１は、攻撃チームに含まれる少なくとも１枚の戦士カードが倒されずに残っており、かつ恐竜キャラクタのＨＰがゼロになった場合には、ユーザの勝利であると判断する。

攻撃操作による恐竜キャラクタのＨＰの更新は、上述した式（１）に限られない。例えば、上記式（１）におけるＰａは戦士カードの攻撃力ではなく、所定の範囲の中から攻撃操作に応じてランダムに決定される数値としても良い。その場合も、追撃レベルが上昇すればするほど恐竜キャラクタのＨＰの低下量が大きくなるように設定する。

対応付け手段５３は、ユーザの入力情報に基づいて、当該ユーザを支援ユーザとして特定のバトル（イベント）に対応付ける機能を備える。
対応付け手段５３の機能は、以下のようにして実現することができる。ゲームサーバ２０のＣＰＵ２１は、発見ユーザからの支援要請を受け付けると、例えばＲＡＭ２３内に、発見ユーザのユーザＩＤと対応付けて支援要請フラグをセットする。発見ユーザ以外のユーザであって、かつクエストを実行中のユーザの通信端末１０からＨＴＴＰリクエストを受信した場合、ＣＰＵ２１は、発見ユーザと対応付けられた支援要請フラグがセットされているか否かを判定し、セットされている場合には、発見ユーザからの支援要請を受諾するか否かを問い合わせるためのメニューを含むＨＴＭＬデータを生成して、ＨＴＴＰリクエストに対する返信を行う。それによって、発見ユーザ以外のユーザであって、かつクエストを実行中のユーザの通信端末１０には、例えば図１２のＰ９に例示したウェブページが表示される。この問い合わせに対して、支援要請を受諾することを含むＨＴＴＰリクエストを受信した場合には、ＣＰＵ２１は、ＨＴＴＰリクエストの送信元の通信端末１０のユーザを支援ユーザとして、対象となるバトルに対応付ける。この対応付けは、具体的には、後述するように、対象となるバトルＩＤに対応付けて支援ユーザのユーザＩＤがバトル管理データに書き込まれることによって行われる。

取得手段５４は、特定のバトルの支援ユーザ（イベントに対応付けられたユーザ）の数に関する情報として、追撃レベルの情報を取得する機能を備える。本実施形態では、「特定のバトルの支援ユーザの数」は、特定のバトルＩＤのバトルにおいて、重複しないユーザＩＤを備えた支援ユーザの数であり、追撃レベルに相当する。
取得手段５４の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、ユーザが恐竜キャラクタに遭遇した時点、発見ユーザ及び支援ユーザと恐竜キャラクタのバトルが開始及び終了する時点で、バトル管理データを更新する処理を行う。具体的には、以下のとおりである。

ＣＰＵ２１は、ユーザが恐竜キャラクタに遭遇した時点で、バトルＩＤを生成してバトル管理データに書き込む。ＣＰＵ２１は、バトル相手の恐竜キャラクタを恐竜キャラクタデータから選択すると、その恐竜キャラクタのキャラクタＩＤをバトルＩＤと対応付けてバトル管理データに書き込む。ＣＰＵ２１は、消滅時刻として例えばユーザが恐竜キャラクタに遭遇した時点から起算して所定時間後（例えば３０分後）に設定して、バトル管理データに書き込む。
ＣＰＵ２１は、発見ユーザ及び支援ユーザの各々と恐竜キャラクタのバトルが開始する時点で、発見ユーザ及び支援ユーザの各々のユーザＩＤをバトルＩＤと対応付けてバトル管理データに書き込む。

ＣＰＵ２１は、発見ユーザ及び支援ユーザの各々と恐竜キャラクタのバトルが開始する時点で、発見ユーザ及び支援ユーザの各々のユーザＩＤと対応付けて、追撃レベルをバトル管理データに書き込む。このとき、ＣＰＵ２１は、発見ユーザ（図８の例では、ユーザＫＮＭ）に対応する追撃レベルを「０」とし、１番目の支援ユーザ（図８の例では、ユーザＡＢＣ）に対応する追撃レベルを「１」とする。ＣＰＵ２１は、Ｎ番目（Ｎ：２以上の整数）の支援ユーザに対応する追撃レベルは決定するに当たって、Ｎ番目の支援ユーザのユーザＩＤと、既に書き込み済みの発見ユーザ及び１〜Ｎ−１番目の支援ユーザの各々のユーザＩＤとを比較する。その結果、一致するユーザＩＤが存在する場合には、ＣＰＵ２１は、Ｎ番目の支援ユーザに対応する追撃レベルを、Ｎ−１番目の支援ユーザに対応する追撃レベルと同一とする。他方、一致するユーザＩＤが存在しない場合には、ＣＰＵ２１は、Ｎ番目の支援ユーザに対応する追撃レベルを、Ｎ−１番目の支援ユーザに対応する追撃レベルに１加えた値とする。このような算出方法により、特定のバトルＩＤのバトルでは、追撃レベルは、重複しないユーザＩＤを備えた支援ユーザの数と同一となる。

ＣＰＵ２１は、発見ユーザ及び支援ユーザの各々と恐竜キャラクタのバトルが終了する時点で、ＲＡＭ２３内のデータを基に、発見ユーザ及び支援ユーザの各々のユーザＩＤと対応付けて、恐竜キャラクタのＨＰ低下量と残ＨＰをバトル管理データに書き込む。ＣＰＵ２１は、バトル相手の恐竜キャラクタが撃破されたか否か（つまり、ＨＰがゼロになったか否か）に応じて、撃破フラグをバトル管理データに書き込む。
また、ＣＰＵ２１は、恐竜キャラクタが撃破された場合（つまり、ＨＰの値がゼロになった場合）には、発見ユーザ及び支援ユーザの各々のユーザデータの恐竜撃破数を１だけ増加させる。

ＣＰＵ２１は、追撃レベルが上昇可能な追撃期間の終期として追撃終了時刻を設定して、バトル管理データに書き込む。追撃終了時刻の設定時刻は、特に限定されるものではないが、例えば、ユーザが恐竜キャラクタに遭遇した時点から起算して所定時間後（例えば２０分後）の時刻であってもよい。また、後に変形例で述べるように、追撃終了時刻の設定時刻は、支援ユーザのバトル実行状況に応じて設定されてもよい。
なお、ＣＰＵ２１は、現在時刻が追撃終了時刻に達した場合には、追撃レベルとしてゼロを書き込む。

特典付与手段５５は、特定のバトル（イベント）に対応付けられた発見ユーザ及び支援ユーザのバトル内の処理の実行によって、当該ユーザに対して、取得手段５４によって取得された支援ユーザの数に関する情報、つまり追撃レベルに応じた特典を付与する機能を備える。本実施形態では、「バトル内の処理の実行」は、例えば攻撃操作の実行に相当する。
追撃レベルに応じた特典の一例は、特定のバトルにおいて、発見ユーザ及び支援ユーザの各々に対して、各ユーザが恐竜キャラクタに与えたダメージ（つまり、ＨＰ低下量）に応じた特典であってもよい。式（１）により示したように、ＨＰ低下量は、Ｐａ×ｋ（Ｐａ：攻撃チームの攻撃力の総和、ｋ：追撃レベルに応じて増加する係数）によって定まるため、追撃レベルが上昇するほど多くのダメージを恐竜キャラクタに与えることができ、より大きい特典をユーザが得ることができる。
特典は、例えばゲーム上の特典ポイントとして付与することができる。特典ポイントは、その大きさに応じて例えば体力ポイントやゲーム上の様々なアイテムと交換可能であってもよい。

特典付与手段５５の機能は、以下のようにして実現することができる。ゲームサーバ２０のＣＰＵ２１は、例えばバトルが終了したタイミングで、バトル管理データにアクセスし、発見ユーザ及び支援ユーザの各々のＨＰ低下量を読み出す。次いでＣＰＵ２１は、読み出したＨＰ低下量に基づいて、発見ユーザ及び支援ユーザの各々に付与すべき特典ポイントを算出する。特典ポイントを算出するに当たって、ＣＰＵ２１は、ＨＰ低下量と特典ポイントの関係を記述したＲＯＭ２２内のデータ（図示せず）を参照してもよいし、ＨＰ低下量に対して所定の演算式を当てはめて特典ポイントを算出する。いずれの場合でも、ＨＰ低下量が大きいほど特典ポイントが大きくなるように設定される。
なお、ユーザに特典ポイントを付与するタイミングは、適宜設定することができる。ＣＰＵ２１は、バトルが終了する都度に、算出した特典ポイントをユーザに付与してもよいし、恐竜キャラクタとのバトルの結果が決定するか、あるいは恐竜キャラクタが消滅した後に、一括して（つまり、それまで算出した特典ポイントを積算して）ユーザに付与してもよい。なお、ユーザへの特典ポイントの付与は、例えばユーザデータに特典ポイントを記憶させることであってもよい。特典ポイントがユーザに付与された場合には、その都度ユーザに通知することが好ましい。

通信手段５６は、ユーザ間でのメッセージの送受信を行う機能を備える。
通信手段５６の機能は、例えば、図１４に示したユーザＫＮＭとユーザＡＢＣ間のメッセージの送受信を例にすると、以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、ユーザＫＮＭの通信端末１０から、入力されたメッセージとその送信先のユーザ（この場合、ユーザＡＢＣ）の情報を含むＨＴＴＰリクエストを受信すると、メッセージとその送信先のユーザの情報を一時的に記憶する。次いでＣＰＵ２１は、ユーザＡＢＣの通信端末１０からクエストについてのＨＴＴＰリクエスト（例えば、図９のメニューｍ１又はｍ５の選択操作結果を含むＨＴＴＰリクエスト）を受信すると、そのＨＴＴＰリクエストに応じた実行結果とともに、一時的に記憶しておいたユーザＫＮＭからのメッセージを含むようにしてＨＴＭＬデータを生成して、ユーザＡＢＣの通信端末１０へ送信する。それによって、ユーザＡＢＣの通信端末１０に、ユーザＫＮＭからのメッセージが表示される。

（７）本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、図１６Ａ及び図１６Ｂのシーケンスチャートを参照して説明する。図１６Ａ及び図１６Ｂは、本実施形態のゲーム制御装置によって行われる、本実施形態のゲームのバトル処理を示している。図１６Ａ及び図１６Ｂでは、図１１〜１３に記載された各ウェブページが表示されるタイミングを符号により示している。なお、図１６Ａ及び図１６Ｂでは、図９〜１３で示したように、発見ユーザがユーザＫＮＭであり、１番目の支援ユーザがユーザＡＢＣ、２番目の支援ユーザがユーザＱＲＳである場合を例として示している。

図１６Ａでは先ず、ユーザＫＮＭが恐竜キャラクタＤＣ１に遭遇し、バトル処理が行われることが想定されている（ステップＳ１００）。このバトル処理では、ゲームサーバ２０のＣＰＵ２１は、ユーザＫＮＭによる攻撃操作結果を含むＨＴＴＰリクエストを受信すると、例えば上記式（１）に従って、ユーザＫＮＭによって予め選択された攻撃チームを構成する戦士カードの攻撃力の総和に応じて恐竜キャラクタＤＣ１のＨＰを低減させる処理を行う。また、ＣＰＵ２１は、攻撃操作に応じてバトル相手の恐竜キャラクタＤＣ１から攻撃チームに対して、一定の、あるいはランダムな値の攻撃力にて攻撃を加える処理を行う。例えば、ＣＰＵ２１は、恐竜キャラクタＤＣ１から攻撃チームに対して加える攻撃力を例えばランダムに決定し、その攻撃力あるいはその攻撃力の積算値（複数回の攻撃操作に伴う攻撃力の積算値）に応じて、ユーザの攻撃チームのうち倒される戦士カードの枚数を決定する。

バトル処理が終了すると、ＣＰＵ２１は、バトル管理データを更新する。具体的には、ＣＰＵ２１は、図８に例示したバトル管理データのユーザＫＮＭ（ユーザＩＤ：０００００１）に対応付けて記載されているように、ＨＰ低下量、残ＨＰ、追撃終了時刻、撃破フラグの値を書き込むことによってバトル管理データを更新する（ステップＳ１１０）。ここでは、発見ユーザであるユーザＫＮＭがバトルに敗北した場合が想定されており、撃破フラグには「０」が書き込まれる。
ユーザＫＮＭが敗北した後、支援要請を行うためのメニューの選択操作に応じて、ユーザＫＮＭの通信端末１０は、支援要請を行うためのメニューの選択操作結果を含むＨＴＴＰをゲームサーバ２０へ送信する（ステップＳ１２０）。ゲームサーバ２０は、ユーザＫＮＭからの支援要請を受け付けると、支援要請を受け付けたことを示すテキストを含むＨＴＭＬデータを生成して、ユーザＫＮＭの通信端末１０へ送信する（ステップＳ１３０）。次いで、ＣＰＵ２１は、例えばＲＡＭ２３内に、発見ユーザであるユーザＫＮＭのユーザＩＤと対応付けて支援要請フラグをセットする（ステップＳ１４０）。

発見ユーザ（この例では、ユーザＫＮＭ）以外のユーザであって、かつクエストを実行中の他のユーザの通信端末１０からＨＴＴＰリクエストを受信した場合、ＣＰＵ２１は、発見ユーザと対応付けられた支援要請フラグがセットされているか否かを判定し、セットされている場合には、発見ユーザからの支援要請を受諾するか否かを問い合わせるためのメニューを含むＨＴＭＬデータを生成して、ＨＴＴＰリクエストに対する返信を行う（ステップＳ１５０）。この問い合わせに対して、支援要請を受諾することを含むＨＴＴＰリクエストを受信した場合には、ＣＰＵ２１は、ＨＴＴＰリクエストの送信元の通信端末１０のユーザを支援ユーザとして、対象となるバトルに対応付ける。図１６Ａの例では、ユーザＡＢＣが、ユーザＫＮＭからの支援要請を受諾するメニューを選択操作し（ステップＳ１６０：ＹＥＳ）、それによってユーザＡＢＣの通信端末１０は、その選択操作結果（支援要請の受諾）を含むＨＴＴＰリクエストをゲームサーバ２０へ送信する（ステップＳ１７０）。このＨＴＴＰリクエストを受信すると、ゲームサーバ２０は、バトル履歴の欄に１番目の支援ユーザであるユーザＡＢＣのユーザＩＤを書き込み、かつ追撃レベルを「１」と書き込むことによって、バトル管理データを更新する（ステップＳ１８０）。

その後、ユーザＡＢＣと恐竜キャラクタＤＣ１との間のバトル処理が行われる（ステップＳ１９０）。ＣＰＵ２１は、ステップＳ１９０のバトル処理における恐竜キャラクタの初期ＨＰとして、発見ユーザであるユーザＫＮＭに対応する残ＨＰをバトル管理データから読み出し、ＲＡＭ２３に転送してから処理を行う。ステップＳ１９０のバトル処理の内容は、ステップＳ１００と同様であるが、追撃レベルが「１」であるため、追撃レベルが「０」のときよりも上記式（１）におけるｋが増加し、ユーザＡＢＣは、恐竜キャラクタＤＣ１に対してより多くのダメージ（Ｐａ×ｋ）を与えやすくなっている。

ユーザＡＢＣと恐竜キャラクタＤＣ１との間のバトル処理が終了すると、ＣＰＵ２１は、バトル管理データを更新する（ステップＳ２００）。具体的には、ＣＰＵ２１は、図８に例示したバトル管理データのユーザＡＢＣ（ユーザＩＤ：０００３３３）に対応付けて記載されているように、ＨＰ低下量、残ＨＰ、追撃終了時刻、撃破フラグの値を書き込むことによってバトル管理データを更新する。ここでは、１番目の支援ユーザであるユーザＡＢＣがバトルに敗北した場合が想定されており、撃破フラグには「０」が書き込まれる。
仮に、ユーザＡＢＣがバトルに勝利した場合には（つまり、撃破フラグ＝１の場合には）、支援要請フラグがリセットされるが（ステップＳ２１０）、この例では、撃破フラグ＝０であるため、支援要請フラグはリセットされない。

図１６Ｂでは、ユーザＱＲＳが、ステップＳ１５０のユーザＫＮＭからの支援要請を受諾するメニューを選択操作し（ステップＳ２２０：ＹＥＳ）、それによってユーザＱＲＳの通信端末１０は、その選択操作結果（支援要請の受諾）を含むＨＴＴＰリクエストをゲームサーバ２０へ送信する（ステップＳ２３０）。このＨＴＴＰリクエストを受信すると、ゲームサーバ２０は、バトル履歴の欄に２番目の支援ユーザであるユーザＱＲＳのユーザＩＤを書き込み、かつ追撃レベルを「２」と書き込むことによって、バトル管理データを更新する（ステップＳ２４０）。

その後、ユーザＱＲＳと恐竜キャラクタＤＣ１との間のバトル処理が行われる（ステップＳ２５０）。ＣＰＵ２１は、ステップＳ２５０のバトル処理における恐竜キャラクタの初期ＨＰとして、直前の１番目の支援ユーザであるユーザＡＢＣに対応する残ＨＰをバトル管理データから読み出し、ＲＡＭ２３に転送してから処理を行う。ステップＳ２５０のバトル処理の内容は、ステップＳ１９０と同様であるが、追撃レベルが「２」であるため、追撃レベルが「１」のときよりも上記式（１）におけるｋが増加し、ユーザＱＲＳは、恐竜キャラクタＤＣ１に対してより一層多くのダメージ（Ｐａ×ｋ）を与えやすくなっている。

ユーザＱＲＳと恐竜キャラクタＤＣ１との間のバトル処理が終了すると、ＣＰＵ２１は、バトル管理データを更新する（ステップＳ２６０）。具体的には、ＣＰＵ２１は、図８に例示したバトル管理データのユーザＱＲＳ（ユーザＩＤ：１２３４５５）に対応付けて記載されているように、ＨＰ低下量、残ＨＰ、追撃終了時刻、撃破フラグの値を書き込むことによってバトル管理データを更新する。ここでは、２番目の支援ユーザであるユーザＱＲＳがバトルに勝利した場合が想定されており、撃破フラグには「１」が書き込まれ、それによって支援要請フラグがリセットされる（ステップＳ２７０）。支援要請フラグがリセットされると、発見ユーザ（この例では、ユーザＫＮＭ）以外のユーザ向けのＨＴＭＬデータに、発見ユーザからの支援要請を受諾するか否かの問い合わせが含まれないようになる。

恐竜キャラクタとのバトルが終了した（つまり、恐竜キャラクタとの勝敗が決定した）ため、ＣＰＵ２１は、特典ポイントを算出し（ステップＳ２８０）、算出したポイントを通知するためのＨＴＭＬデータを生成して、バトルに参加したユーザ（発見ユーザＫＮＭ、１番目の支援ユーザＡＢＣ、２番目の支援ユーザＱＲＳ）の通信端末１０へ送信する（ステップＳ２９０）。なお、ＣＰＵ２１は、例えば、バトル管理データにアクセスし、発見ユーザＫＮＭ、１番目の支援ユーザＡＢＣ、２番目の支援ユーザＱＲＳの各々に対応付けられたＨＰ低下量（つまり、恐竜キャラクタＤＣ１に与えたダメージ）のデータを読み出し、そのＨＰ低下量に応じた特典ポイントを算出する。

以上説明したように、本実施形態のゲーム制御装置では、特定のバトル（イベント）に支援ユーザとして対応付けられるユーザの数（あるいは、バトルに参加しているユーザ数）に応じて、そのバトルにおいて恐竜キャラクタに与えたダメージに応じた特典ポイント（イベント内の処理の実行に伴う特典）が付与される。つまり、支援ユーザの数が多いほどバトルにおける攻撃操作によって恐竜キャラクタに与えるダメージが大きくなり、それによって多くの特典ポイントがユーザに付与されることになる。支援ユーザの数が多いほど有利となるため、バトルに参加していないユーザがバトルに参加することが動機付けられる。言い換えれば、固定化した仲間のユーザ同士でイベント内の処理を実行するよりも、より多くのユーザがイベントに参加することが有利となる仕組みとなっている。そのため、本実施形態のゲーム制御装置によれば、複数のユーザが協力して恐竜キャラクタに対するバトルを行う場合に、コミュニケーションの程度が低いユーザ同士、あるいは今までコミュニケーションをとったことがないユーザ同士で協力してゲームを行うように動機付けることができる。

上述した実施形態では、例えば図１２のウェブページＰ９、及び図１３のウェブページＰ１２に示したように、発見ユーザからの支援要請を受諾するか否かの問い合わせを表示するウェブページにおいて、現在の追撃レベルを含むバトルについての情報を表示する好ましい表示形態の例を示しているが、このようなバトルについての情報は表示しなくてもよい。なお、このウェブページにおいて、現在の追撃レベルを表示することで、バトルに参加する（支援ユーザとして対応付けられる）前にユーザは、既に支援ユーザとして対応付けられているユーザの数がわかるため、これからバトルに参加しようとするときに、ユーザの数に応じた特典ポイントの大小を推定できるようになる。そのため、ユーザがバトルに参加することに対する動機付けがより強く働かせることができるようになる。

この好ましい表示形態を実現するための機能ブロック図を図１７に示す。図１７の機能ブロック図は、図１５に示したものと比較して、提示手段５７が追加された点が異なる。
提示手段５７は、ユーザを特定のバトル（イベント）の支援ユーザとして対応付けるためのユーザの入力を受け付けるタイミングで、取得手段５４によって取得された支援ユーザの数に関する情報、つまり追撃レベルの情報を、当該ユーザに提示する機能を備える。この「ユーザの入力」は、例えば図１２のウェブページＰ９、及び図１３のウェブページＰ１２に示したように、他のユーザからの支援要請を受諾するか否かについての選択を行うためのユーザの操作入力である。提示手段５７の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、支援要請を含むＨＴＭＬデータを生成するに当たって、バトル管理データの追撃レベルの値を読み出して、ＨＴＭＬデータに含めるようにする。

（８）変形例
以下、上述した実施形態の変形例について説明する。

（８−１）変形例１
上述した実施形態では、支援ユーザの数を追撃レベルとしたが、単に支援ユーザの数によって追撃レベルを決定するのではなく、支援ユーザのうち、ある程度の攻撃ポイントを消費して攻撃を行った支援ユーザの数を追撃レベルとしてもよい。例えば、支援ユーザが恐竜キャラクタとのバトルを行うに当たって、攻撃チーム１（ユーザの攻撃ポイントの最大値の１００％を消費）又は攻撃チーム２（ユーザの攻撃ポイントの最大値の６０％を消費）を選択した支援ユーザの数を追撃レベルとしてもよい。つまり、攻撃チーム３（ユーザの攻撃ポイントの最大値の３０％を消費）を選択した支援ユーザは、恐竜キャラクタに対する攻撃に積極的に関与しなかったものとして、追撃レベルを算出する上で除外する。
このような構成とすることで、積極的にバトルに参加するユーザ同士のコミュニケーションを活性化させることができる。
本変形例を実現するために、ゲームサーバ２０のＣＰＵ２１は、追撃レベルを更新するに当たって、支援ユーザの攻撃チームの選択結果に基づいて、バトル管理データにその支援ユーザのユーザＩＤを書き込むか否かを決定する。あるいは、ＣＰＵ２１は、支援ユーザの攻撃チームの選択結果如何に関わらず、すべての支援ユーザのユーザＩＤと選択した攻撃チームとをバトル管理データに書き込んでおき、攻撃チーム３を選択した支援ユーザを、追撃レベルの算出の基礎としないようにしてもよい。

（８−２）変形例２
上述した実施形態において、対応付け手段５３は、特定のバトル（イベント）の開始時刻から所定時間が経過したときに、ユーザのバトルへの支援ユーザとしての対応付けを解除してもよい。なお、「全ての支援ユーザとしての対応付けの解除」は、実質的に追撃レベルをゼロにすることに等しい。
この構成により、バトル（イベント）に対応付けられたユーザの数に応じて特典を得られるという有利な効果が持続する時間が制限されるため、限られた時間内でのユーザ間のコミュニケーションが促進されるとともに、有利な効果が持続し過ぎることないようにゲーム進行におけるユーザ間の公平性が担保される。
本変形例を実現するために、ゲームサーバ２０のＣＰＵ２１は、例えば、発見ユーザが恐竜キャラクタと遭遇した時刻、又は発見ユーザと恐竜キャラクタとのバトルの開始時刻を起点として、所定時間後を追撃終了時刻として設定する。ＣＰＵ２１は、追撃終了時刻までに支援要請を受諾したユーザを支援ユーザとして対応付け、それによって追撃レベルを上昇させる。
また、ＣＰＵ２１は、所定時間が経過し追撃終了時刻に達した場合には、支援要請は行わず、追撃レベルをリセットする（ゼロにする）。あるいは、ＣＰＵ２１は、所定時間が経過し追撃終了時刻に達した場合には、追撃レベルを直ちにゼロにするのではなく、段階的に低下させてもよい。例えば、ＣＰＵ２１は、追撃終了時刻に達してから所定時間毎に追撃レベルを１つずつ低下させてもよいし、恐竜キャラクタと、当該バトルに支援ユーザとして対応付けられるユーザをランダムに、又は、所定の規則(例えば、対応付けられた順序等)に基づいて、解除しても良い。

（８−３）変形例３
上述した実施形態において、対応付け手段５３は、Ｎ番目（Ｎ：２以上の整数）のユーザが特定のバトル（イベント）に支援ユーザとして対応付けられ、かつ当該ユーザがＮ−１番目にバトルに支援ユーザとして対応付けられたユーザと異なる場合に、Ｎ番目のユーザが対応付けられてから、又はＮ番目のユーザによる処理の実行が開始若しくは終了してから所定時間が経過したときに、ユーザのバトルの支援ユーザとしての対応付けを解除してもよい。なお、「全ての支援ユーザとしての対応付けの解除」は、実質的に追撃レベルをゼロにすることに等しい。
この構成により、バトル（イベント）に支援ユーザとして対応付けられるユーザが連続して同一ユーザでない場合には、既に対応付けられている複数のユーザのバトルへの対応付けは解除されず、バトルに支援ユーザとして対応付けられたユーザの数に応じて特典を得られるという有利な効果が持続する。そのため、異なるユーザが入れ替わりバトル内の処理を実行するように動機付けられることになり、例えばバトルに支援ユーザとして対応付けられているユーザ間でコミュニケーションをとることが促進される。

この対応付け手段５３の機能によって実現されるバトル管理データの更新例について、図１８を参照して説明する。図１８は、本変形例において、バトル管理データの更新例を説明するための図である。図１８（ａ）は、特定のバトルにおいて発見ユーザ及び支援ユーザの各々のバトル期間、及び追撃終了時刻の変化の一例を時間軸に沿って示しており、図１８（ｂ）は、追撃レベルの変化の一例を時間軸に沿って示している。

図１８において、発見ユーザＵ０のバトル中における追撃レベルは初期値の「０」である。ユーザＵ１が支援ユーザとして対応付けられると、追撃レベルが「１」に上昇するとともに、その対応付けの時点から追撃終了時刻が例えば１０分間（所定時間）に設定される。
次に、ユーザＵ２が支援ユーザとして対応付けられると、追撃レベルが「１」から「２」に上昇するとともに、その対応付けの時点から追撃終了時刻が例えば１０分間（所定時間）に設定される。つまり、追撃レベルが上昇可能な追撃期間が延長される。ここで、ユーザＵ２がバトルに敗北した後に再度自らバトルを行う場合を想定する。この場合には、２番目と３番目の支援ユーザが同一であるため、追撃レベルは上昇せずに「２」のままであり、かつ追撃終了時刻が変更されない（＊１）。つまり、追撃期間が延長されない。

次に、ユーザＵ３が支援ユーザとして対応付けられると、追撃レベルが「２」から「３」に上昇するとともに、その対応付けの時点から追撃終了時刻が例えば１０分間（所定時間）に設定される。つまり、追撃レベルが上昇可能な追撃期間がさらに延長される。
次の支援ユーザであるユーザＵ１は直前の支援ユーザであるユーザＵ３と異なるユーザであるため、追撃終了時刻が変更される（追撃期間が延長される）が、１番目の支援ユーザと同一であるため、追撃レベルは上昇せずに「３」のままである。最後に、ユーザＵ４が支援ユーザとして対応付けられると、追撃レベルが「３」から「４」に上昇するとともに、その対応付けの時点から追撃終了時刻が例えば１０分間（所定時間）に設定される。つまり、追撃レベルが上昇可能な追撃期間がさらに延長される。

図１８に例示したように、本変形例では、新たに支援ユーザが対応付けられたときの追撃期間は、その直前の支援ユーザと同一のユーザでない場合に延長してもよい。これによって、追撃レベルがリセットされない有利な状況を継続させることを目的として、異なるユーザが入れ替わり支援ユーザとなってバトルを行うように動機付けられる。
本変形例を実現するために、ゲームサーバ２０のＣＰＵ２１は、同一の支援ユーザが連続してバトルを行う場合（例えば、図１２のメニューｍ２２が選択操作された場合）、又は、同一のユーザが連続して支援ユーザとして対応付けられた場合には、追撃終了時刻を変更せず、そうでない場合に追撃終了時刻を更新してバトル管理データに書き込む。更新後の追撃終了時刻は、最新の支援ユーザが対応付けられてから、又は、その支援ユーザによる攻撃操作が行われたときから、若しくはその支援ユーザによるバトルが終了してから所定時間が経過した時刻に設定される。

（８−４）変形例４
上述した変形例３において、取得手段５４によって取得されたユーザの数が多いほど、すなわち追撃レベルが大きいほど、変形例３における所定時間を短くしてもよい。
上述した実施形態の構成では、バトル（イベント）に支援ユーザとして対応付けられているユーザの数が多いほどより多くの特典が得られる状況となるが、そのような状況が長く継続すると、ゲーム進行におけるユーザ間の公平性が担保されない場合がある。そのため、ユーザの数が多いほど変形例３における所定時間を短くすることで、ゲーム進行におけるユーザ間の公平性を担保することが好ましい。
本変形例を実現するために、ゲームサーバ２０のＣＰＵ２１は、追撃終了時刻を更新してバトル管理データに書き込む場合に、追撃レベルの大きさに応じて追撃終了時刻までの時間を設定する。追撃終了時刻までの時間を設定するに当たって、ＣＰＵ２１は、追撃レベルと追撃終了時刻までの時間の予め既知の関係を参照してもよいし、追撃レベルを所定の演算式に当てはめて追撃終了時刻までの時間を算出してもよい。

（８−５）変形例５
上述した実施形態において、ゲーム実行手段５２による特定のバトル（イベント）内の処理の実行回数が多いほど、前記所定時間を短くしてもよい。
上述した実施形態の構成では、バトル（イベント）に支援ユーザとして対応付けられているユーザの数が多いほど、つまりバトルの処理の実行回数が多くなるほど、より多くの特典が得られる状況となるが、そのような状況が長く継続すると、ゲーム進行の公平性が担保されない場合がある。そのため、バトルの処理の実行回数が多いほど上記所定時間を短くすることで、ゲーム進行の公平性を担保することが好ましい。
本変形例を実現するために、ゲームサーバ２０のＣＰＵ２１は、特定のバトルが開始されてから攻撃操作結果を含むＨＴＴＰリクエストの受信回数をカウントする。そしてＣＰＵ２１は、追撃終了時刻を更新してバトル管理データに書き込む場合に、受信回数のカウント値の大きさに応じて追撃終了時刻までの時間を設定する。追撃終了時刻までの時間を設定するに当たって、ＣＰＵ２１は、受信回数のカウント値と追撃終了時刻までの時間の予め既知の関係を参照してもよいし、受信回数のカウント値を所定の演算式に当てはめて追撃終了時刻までの時間を算出してもよい。

（８−６）変形例６
上述した実施形態において、特典付与手段５５は、特定のバトル（イベント）の結果が所定の条件を満たす場合に、当該バトルに対応付けられたユーザに対して、さらに特典を付与してもよい。「所定の条件」は、本実施形態の場合、バトル相手の恐竜キャラクタを撃破してバトルで勝利することである。
特典は、例えばゲーム上の特典ポイントとして付与することができる。特典ポイントは、その大きさに応じて例えば体力ポイントやゲーム上の様々なアイテムと交換可能であってもよい。
この構成では、バトルの結果次第でバトルに参加するユーザ（発見ユーザ及び支援ユーザ）に対して追加の特典が付与されるか否かが決定されるため、既にバトルに参加済みのユーザ間で、バトル相手の恐竜キャラクタを撃破してバトルで勝利するように、コミュニケーションをとることが促進される。
本変形例における特典付与手段５５の機能は、例えば以下のようにして実現することができる。ゲームサーバ２０のＣＰＵ２１は、例えばバトルが終了したタイミングで、バトル管理データにアクセスし、撃破フラグを確認し、撃破フラグが「１」である場合には、発見ユーザ及び支援ユーザの各々に追加の特典ポイントを付与することを決定する。特典ポイントの量及び配分方法は、適宜決定することができる。１つのバトルについて勝利したときに付与される特典ポイントの量が固定である場合には、ＣＰＵ２１は、その特典ポイントを、発見ユーザ及び支援ユーザの各々に均等配分してもよいし、ＨＰ低下量に応じた比率（つまり、貢献度合い）に基づいて配分してもよい。

（８−７）変形例７
上述した変形例６において、特定のバトル（イベント）の結果が所定の条件を満たす場合に付与される特典は、当該バトルが終了した時点において取得手段５４によって取得されたユーザの数に関する情報、すなわち追撃レベルに応じた特典であってもよい。
この構成では、バトルが終了する時点までにできるだけ多くのユーザがバトルに参加する（対応付けられる）ことが、既にバトルに参加しているユーザにとって有利である。そのため、ユーザ間で、より多くのユーザがバトルに参加するよう働きかけが行われるようにコミュニケーションをとることが促進される。
本変形例では、ゲームサーバ２０のＣＰＵ２１は、１つのバトルについて勝利したときに付与される追加の特典ポイントの量を、バトル終了時点の追撃レベルによって決定する。つまり、ＣＰＵ２１は、バトル終了時点の追撃レベルが大きいほど、特典ポイントの量を多くする。ＣＰＵ２１は、特典ポイントを算出するに当たって、追撃レベルと特典ポイントの予め既知の関係を参照してもよいし、追撃レベルを所定の演算式に当てはめて特典ポイントを算出してもよい。ＣＰＵ２１は、算出した特典ポイントを、発見ユーザ及び支援ユーザの各々に均等配分してもよいし、ＨＰ低下量に応じた比率（つまり、貢献度合い）に基づいて配分してもよい。

（８−８）変形例８
上述した実施形態において、対応付け手段５３は、Ｎ番目（Ｎ：２以上の整数）のユーザが特定のバトル（イベント）に対応付けられ、かつ当該ユーザがＮ−１番目にバトルに対応付けられたユーザと同一である場合に、当該ユーザのバトルへの対応付けを解除してもよい。
この構成では、同一のユーザが連続してバトルに支援ユーザとして対応付けられた場合には、当該ユーザのバトルへの対応付けが解除され、バトルに対応付けられたユーザの数が低減することになる。そのため、より多くのユーザの間で入れ替わり対応付けが行われてバトルの処理を実行することが動機付けられ、ユーザ間でコミュニケーションをとることが促進される。
本変形例を実現するために、ゲームサーバ２０のＣＰＵ２１は、バトル管理データにおいて同一のユーザＩＤのユーザが連続して支援ユーザとして対応付けられた場合、そのユーザＩＤのデータをバトル管理データから削除する（つまり、対応付けを解除する）。

（８−９）変形例９
上述した実施形態において、対応付け手段５３は、Ｎ番目（Ｎ：２以上の整数）のユーザが特定のバトル（イベント）に対応付けられ、かつ当該ユーザがＮ−１番目までにバトルに対応付けられたユーザのうちいずれかのユーザと同一である場合に、当該ユーザのバトルへの対応付けを解除してもよい。
この構成では、既にバトルに参加済み（つまり、支援済み）のユーザが再度バトルに参加して処理を実行した場合には、当該ユーザのバトルへの対応付けが解除され、バトルに対応付けられたユーザの数が低減することになる。つまり、固定化した仲間のユーザ同士で入れ替わりバトルに参加しても多くの特典を得ることができなくなるため、固定化した仲間のユーザ同士でバトルの処理を実行することが回避される。結果として、複数のユーザが協力してバトルの処理を行う場合に、コミュニケーションの程度が低いユーザ同士、あるいは今までコミュニケーションをとったことがないユーザ同士で協力してゲームを行うように動機付けることができる。
本変形例を実現するために、ゲームサーバ２０のＣＰＵ２１は、ユーザを新たに支援ユーザとしてバトルに対応付けるときに、そのユーザのユーザＩＤと、それまでに支援ユーザとして既に対応付けられているユーザＩＤと順に比較する。その結果、一致するユーザＩＤが存在する場合には、ＣＰＵ２１は、新たに支援ユーザとして対応付けることを許可せず、かつ既に対応付けられている同一のユーザＩＤの対応付けを解除する。

（８−１０）変形例１０
上述した変形例２又は変形例３において、対応付け手段５３は、Ｎ番目（Ｎ：２以上の整数）のユーザが特定のバトル（イベント）に対応付けられ、かつ当該ユーザがＮ−１番目までにバトルに対応付けられたユーザのうちいずれかのユーザと同一である場合に、前記所定時間を短くしてもよい。
この構成では、既にバトルに参加済み（つまり、支援済み）のユーザが再度バトルに参加して処理を実行した場合、バトルに参加しているユーザの数に応じて特典を得られるという有利な効果が持続する時間が短くなる。そのため、固定化した仲間のユーザ同士で入れ替わりバトルに参加しても多くの特典を得る機会が少なくなるため、固定化した仲間のユーザ同士でバトルの処理を実行することが回避される。結果として、複数のユーザが協力してバトルの処理を行う場合に、コミュニケーションの程度が低いユーザ同士、あるいは今までコミュニケーションをとったことがないユーザ同士で協力してゲームを行うように動機付けることができる。
本変形例を実現するために、ゲームサーバ２０のＣＰＵ２１は、ユーザを新たに支援ユーザとしてバトルに対応付けるときに、そのユーザのユーザＩＤと、それまでに支援ユーザとして既に対応付けられているユーザＩＤと順に比較する。その結果、一致するユーザＩＤが存在する場合には、ＣＰＵ２１は、変形例２又は変形例３における所定時間を短くして、追撃終了時刻を設定する。このとき、所定時間を短くする度合いは適宜予め決定しておくようにする。

以上、本発明の実施形態について詳細に説明したが、本発明は上記実施形態に限定されない。また、各実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。例えば、上記実施形態及び各変形例に記載された技術的事項は適宜組合せて適用してもよい。
例えば、ウェブページを用いたユーザへの通知方法は、テキスト形式の視覚的情報に限られず、音声などの聴覚的情報であってもよい。

上述した実施形態及び変形例では、カードを用いたバトルを行う場合を例として説明したが、これに限られない。カードでなく、例えば、ユーザのアバタ画像等の他のオブジェクトであってもよい。あるいは、カード等のオブジェクトを使用せずにバトル処理を行ってもよい。

上述した実施形態では、ユーザによる通信端末に対する所定の操作入力は、ユーザの通信端末に対する所定の操作釦の押下操作の入力や、タッチパネル機能を備えた通信端末に対する表示画面上のタッチ操作の入力であるとしたが、操作入力はこれに限られない。操作入力は、加速度センサを備えた通信端末を振ることによる操作入力、あるいはジェスチャによる操作入力（ジェスチャ入力）であってもよい。ジェスチャ入力では、撮像機能を備えた通信端末に対する所定のジェスチャを行うことで通信端末がそのジェスチャを画像認識し、予めジェスチャに対応付けられた操作入力を認識する。また、音声認識プログラムを実行可能な通信端末の場合には、操作入力は、音声を入力することにより行われてもよい。

上述した実施形態では、ソーシャルゲームに適用される場合を例として説明したが、これに限られない。例えば、ネットワーク上に置かれたサーバ装置と家庭用オンラインゲーム機とを接続した、いわゆるオンラインゲームシステムにおいても、上述した実施形態と同様に、各ユーザによるゲームの進行を制御できることは言うまでもない。

上述した実施形態では、ネットワーク上のゲームサーバ２０及びデータベースサーバ３０によって、図１５に示した各機能を実現する構成としたが、この構成に限られない。これらのすべての手段を通信端末１０によって実現する構成としてもよいし、少なくとも一部の手段を通信端末１０によって実現する構成としてもよい。通信端末１０とゲームサーバ２０とでは実質的に同一のハードウエア構成を採るため、上記実施形態に記載したようにして通信端末１０によっても各機能を実現できる。図１９（ａ），（ｂ）には、本実施形態のゲーム制御装置の各機能（図１５に示す各機能）について、通信端末１０と、ゲームサーバ２０及びデータベースサーバ３０との間の分担例を示す。

１０…通信端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１４…画像処理部
１５…指示入力部
１６…表示部
１７…通信インタフェース部
１８…バス
２０…ゲームサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…データベースアクセス部
２５…通信インタフェース部
２６…バス
３０…データベースサーバ
３１…ユーザデータベース
３２…ゲームデータベース
５１…登録手段
５２…ゲーム実行手段
５３…対応付け手段
５４…取得手段
５５…特典付与手段
５６…通信手段
５７…提示手段

Claims (14)

1. 複数のユーザの協力によって処理が行われるイベントを含むゲームの実行を制御するゲーム制御装置であって、
   ユーザの入力情報に基づいて、当該ユーザを前記イベントに対応付ける対応付け手段と、
   前記イベントに対応付けられたユーザの入力情報に基づいて、前記イベント内の処理を実行する実行手段と、
   前記イベントに対応付けられたユーザの数に関する情報を取得する取得手段と、
   前記イベントに対応付けられたユーザの前記イベント内の前記処理の実行によって、当該ユーザに対して、前記取得手段によって取得されたユーザの数に関する情報に応じた特典を付与する特典付与手段と、
   を備えた、ゲーム制御装置。
2. 前記対応付け手段は、前記イベントの開始時刻から所定時間が経過したときに、ユーザの前記イベントへの対応付けを解除することを特徴とする、
   請求項１に記載されたゲーム制御装置。
3. 前記対応付け手段は、Ｎ番目（Ｎ：２以上の整数）のユーザが前記イベントに対応付けられ、かつ当該ユーザがＮ−１番目に前記イベントに対応付けられたユーザと異なる場合に、前記Ｎ番目のユーザが対応付けられてから、又は前記Ｎ番目のユーザによる前記処理の実行が開始若しくは終了してから所定時間が経過したときに、ユーザの前記イベントへの対応付けを解除することを特徴とする、
   請求項１に記載されたゲーム制御装置。
4. 前記取得手段によって取得されたユーザの数が多いほど、前記所定時間が短いことを特徴とする、
   請求項３に記載されたゲーム制御装置。
5. 前記実行手段による前記イベント内の処理の実行回数が多いほど、前記所定時間が短いことを特徴とする、
   請求項３に記載されたゲーム制御装置。
6. ユーザを前記イベントに対応付けるためのユーザの入力を受け付けるタイミングで、前記取得手段によって取得されたユーザの数に関する情報を、当該ユーザに提示する提示手段を備えたことを特徴とする、
   請求項１〜５のいずれかに記載されたゲーム制御装置。
7. 前記特典付与手段は、前記イベントの結果が所定の条件を満たす場合に、前記イベントに対応付けられたユーザに対して、さらに特典を付与することを特徴とする、
   請求項１〜６のいずれかに記載されたゲーム制御装置。
8. 前記イベントの結果が所定の条件を満たす場合に付与される特典は、前記イベントが終了した時点において前記取得手段によって取得されたユーザの数に関する情報に応じた特典であることを特徴とする、
   請求項７に記載されたゲーム制御装置。
9. 前記対応付け手段は、Ｎ番目（Ｎ：２以上の整数）のユーザが前記イベントに対応付けられ、かつ当該ユーザがＮ−１番目に前記イベントに対応付けられたユーザと同一である場合に、当該ユーザの前記イベントへの対応付けを解除することを特徴とする、
   請求項１〜８のいずれかに記載されたゲーム制御装置。
10. 前記対応付け手段は、Ｎ番目（Ｎ：２以上の整数）のユーザが前記イベントに対応付けられ、かつ当該ユーザがＮ−１番目までに前記イベントに対応付けられたユーザのうちいずれかのユーザと同一である場合に、当該ユーザの前記イベントへの対応付けを解除することを特徴とする、
    請求項１〜８のいずれかに記載されたゲーム制御装置。
11. 前記対応付け手段は、Ｎ番目（Ｎ：２以上の整数）のユーザが前記イベントに対応付けられ、かつ当該ユーザがＮ−１番目までに前記イベントに対応付けられたユーザのうちいずれかのユーザと同一である場合に、前記所定時間を短くすることを特徴とする、
    請求項２又は３に記載されたゲーム制御装置。
12. 複数のユーザの協力によって処理が行われるイベントを含むゲームの実行を制御するゲーム制御方法であって、
    ユーザの入力情報に基づいて、当該ユーザを前記イベントに対応付けるステップと、
    前記イベントに対応付けられたユーザの入力情報に基づいて、前記イベント内の処理を実行するステップと、
    前記イベントに対応付けられたユーザの数に関する情報を取得するステップと、
    前記イベントに対応付けられたユーザの前記イベント内の前記処理の実行によって、当該ユーザに対して、前記取得するステップによって取得されたユーザの数に関する情報に応じた特典を付与するステップと、
    を備えた、ゲーム制御方法。
13. 複数のユーザの協力によって処理が行われるイベントを含むゲームの実行を制御するプログラムであって、
    コンピュータに、
    ユーザの入力情報に基づいて、当該ユーザを前記イベントに対応付ける機能、
    前記イベントに対応付けられたユーザの入力情報に基づいて、前記イベント内の処理を実行する機能、
    前記イベントに対応付けられたユーザの数に関する情報を取得する機能、及び、
    前記イベントに対応付けられたユーザの前記イベント内の前記処理の実行によって、当該ユーザに対して、前記取得する機能によって取得されたユーザの数に関する情報に応じた特典を付与する機能、
    を実現させるためのプログラム。
14. 通信端末と、当該通信端末からアクセスされるサーバとを含み、複数のユーザの協力によって処理が行われるイベントを含むゲームの実行を制御するゲームシステムであって、
    ユーザの入力情報に基づいて、当該ユーザを前記イベントに対応付ける対応付け手段、
    前記イベントに対応付けられたユーザの入力情報に基づいて、前記イベント内の処理を実行する実行手段、
    前記イベントに対応付けられたユーザの数に関する情報を取得する取得手段、及び、
    前記イベントに対応付けられたユーザの前記イベント内の前記処理の実行によって、当該ユーザに対して、前記取得手段によって取得されたユーザの数に関する情報に応じた特典を付与する特典付与手段、
    の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
    ゲームシステム。

Images