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

Description

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

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

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

アプリＳＴＹＬＥ Vol.2（株式会社イースト・プレス）、26-27頁

上記非特許文献１に記載されているゲームでは、ユーザが他のユーザからゲームキャラクタを補助的に借りてバトルを行う場合、他のユーザからそのバトルにおける指示は存在せず、ユーザ間で協力してバトルを行っている感覚を味わうことはできない。つまり、ユーザが他のユーザからゲームキャラクタを補助的に借りてバトルを行ったとしても、そのバトルにおいてユーザ間で連携している感覚が得られないものとなっている。

本発明は上述した観点に鑑みてなされたもので、ユーザ間で協力してゲームを進行させている感覚が得られるゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステムを提供することを目的とする。

本発明の第１の観点は、複数のユーザの各々の操作に応じて、各ユーザによるゲームの進行を制御するゲーム制御装置である。
このゲーム制御装置は、
ゲーム上のキャラクタと、キャラクタのデータであるキャラクタデータとを対応付けて記憶する記憶手段と、
ユーザごとに、ユーザの操作に応じてキャラクタデータを変更する制御手段と、
前記複数のユーザのうち第１のユーザのキャラクタを特定する情報を、第１のユーザとは異なる第２のユーザに対して提供する提供手段と、
を備え、
前記制御手段は、第２のユーザに対して第１のユーザのキャラクタを特定する情報が提供された場合には、第２のユーザの操作に応じて、第２のユーザのキャラクタのキャラクタデータと同時に、第１のユーザのキャラクタのキャラクタデータを変更する。

このゲーム制御装置において「キャラクタデータ」とは、キャラクタに関連するデータであって、ゲームの進行に応じて変更されうるデータである。キャラクタデータは、ゲームの性質によって様々な種別のデータを採りうるが、例えば対戦型ゲームの場合には、キャラクタデータは敵キャラクタの体力を示す値（ＨＰ）などであってよい。
このゲーム制御装置において「キャラクタを特定する情報」とは、ゲーム上の異なるキャラクタを区別できる情報、あるいはゲーム上のキャラクタを特定可能な情報であれば如何なるものでもよい。例えば、キャラクタを特定する情報は、キャラクタの外観を示す画像、キャラクタの名称を示すテキスト、または、キャラクタを特定するための識別コードなどであってよい。
このゲーム制御装置において「キャラクタ」とは、例えばゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカードに表示されているものをも含む。

このゲーム制御装置では、キャラクタデータがユーザの操作に応じて変更されながら、複数のユーザに対してユーザごとにゲームを進行させる。このゲーム制御装置ではさらに、第１のユーザのキャラクタを特定する情報が第２のユーザに提供された場合、第２のユーザの操作に応じて、第２のユーザのキャラクタのキャラクタデータが変更されるのみならず、第１のユーザのキャラクタのキャラクタデータも変更される。これにより、第２のユーザの操作が第１のユーザのゲームの進行に対して直接的に影響を与えることができるため、第１のユーザと第２のユーザは、互いに協力してゲームを進行させている感覚を得ることができる。
ユーザのキャラクタは、対戦型ゲームの場合には敵キャラクタであってもよいが、ゲームの性質によって適宜設定しうる。例えば、複数のユーザの各々が植物等を育成させることを競うゲームの場合には、ユーザのキャラクタは、ユーザの育成対象となる植物のキャラクタであってもよい。
なお、このゲーム制御装置において、前記制御手段は、第１のユーザに提示する表示画面において第２のユーザのキャラクタを表示させず、第２のユーザに提示する表示画面において第１のユーザのキャラクタを表示させてもよい。

上記ゲーム制御装置において、前記第２のユーザに提示する表示画面において、前記第１のユーザのキャラクタと前記第２のユーザのキャラクタの各々のキャラクタデータを表示させてもよい。これにより、第２のユーザは、自らの操作に基づく、自らのキャラクタのキャラクタデータの変更結果と、第１のユーザのキャラクタのキャラクタデータの変更結果とを視認することができるため、互いに協力してゲームを進行させている感覚を実感することができる。

上記ゲーム制御装置において、各ユーザのキャラクタは属性と対応付けられており、
前記制御手段は、前記第１のユーザのキャラクタと前記第２のユーザのキャラクタとが同じ属性である場合に、前記第２のユーザの操作に応じて前記第１のユーザのキャラクタのキャラクタデータを変更してもよい。
このゲーム制御装置において「キャラクタの属性」とは、例えばキャラクタの形態および／または色、模様、キャラクタそのものや能力を数値化したもの（レベル等）に加えて、キャラクタに設定された特定音(鳴き声等)など、キャラクタの違いを視覚的および／または聴覚的に区別可能な如何なる特性も含みうる。対戦型ゲームの場合、ユーザのキャラクタの属性は敵キャラクタの属性であってもよい。
このゲーム制御装置によれば、第２のユーザは、属性が異なる複数のキャラクタがゲーム上で設定されている場合であっても、自らのキャラクタのうち、第１のユーザのゲームの進行に対して影響を与えることができるキャラクタを認識しながらゲームを進めることができる。

上記ゲーム制御装置において、前記制御手段は、前記第２のユーザに対して複数のユーザのキャラクタを特定する情報が提供された場合には、前記第２のユーザによる選択操作に基づいて、いずれかのキャラクタを選択し、第２のユーザの操作に応じて、第２のユーザのキャラクタのキャラクタデータとともに、選択したキャラクタのキャラクタデータを変更してもよい。つまり、いずれかのキャラクタを選択するかについては、第２のユーザが選択可能とする。それによって、第２のユーザは、例えば、自らのキャラクタと同一の属性のキャラクタを選択することができるため、他のユーザと協力してゲームを進行させやすくなる。

上記ゲーム制御装置において、前記複数のユーザの間の関連付けを記憶する第２の記憶手段、を備え、前記提供手段は、前記第１のユーザと関連付けられているユーザを前記第２のユーザとして特定してもよい。ユーザ間の関連付けは、ユーザ同士を例えば仲間として予め関係付けることによって行われてよい。このゲーム制御装置によって、協力してゲームを進行させるユーザは、予め関連付けられたユーザ同士に限定されるため、そのユーザ同士の関係をより強化することができる。これにより、例えば仲間の間のコミュニティの活性化を図ることができる。

上記ゲーム制御装置において、前記複数のユーザの間の関連付けを記憶する第２の記憶手段、を備え、前記提供手段は、前記第１のユーザと関連付けられている複数のユーザのうち、前記第１のユーザのキャラクタを特定する情報の提供を希望するか否かについて問い合わせをし、当該情報の提供を希望することを最初に回答したユーザを、前記第２のユーザとして特定してもよい。これにより、早く他のユーザと協力してゲームを進行させたい、というユーザの欲求を満たすことができる。

本発明の第２の観点は、複数のユーザの各々の操作に応じて、各ユーザによるゲームの進行を制御するゲーム制御装置である。
このゲーム制御装置は、
ゲーム上のユーザの敵キャラクタと、敵キャラクタのデータであるキャラクタデータとを対応付けて記憶する記憶手段と、
ユーザごとに、ユーザの操作に応じてキャラクタデータを変更する制御手段と、
前記複数のユーザのうち第１のユーザの敵キャラクタを特定する情報を、第１のユーザとは異なる第２のユーザに対して提供する提供手段と、
を備え、
前記制御手段は、第２のユーザに対して第１のユーザの敵キャラクタを特定する情報が提供された場合には、第２のユーザの操作に応じて、第２のユーザの敵キャラクタのキャラクタデータと同時に、第１のユーザの敵キャラクタのキャラクタデータを変更する。

本発明の第３の観点は、複数のユーザの各々の操作に応じて、各ユーザによるゲームの進行を制御するゲーム制御方法である。
このゲーム制御方法は、
ゲーム上のキャラクタと、キャラクタのデータであるキャラクタデータとを対応付けて記憶装置に記憶させるステップと、
ユーザごとに、ユーザの操作に応じてキャラクタデータを変更するステップと、
前記複数のユーザのうち第１のユーザのキャラクタを特定する情報を、第１のユーザとは異なる第２のユーザに対して提供するステップと、
を含み、
前記変更するステップは、第２のユーザに対して第１のユーザのキャラクタを特定する情報が提供された場合には、第２のユーザの操作に応じて、第２のユーザのキャラクタのキャラクタデータと同時に、第１のユーザのキャラクタのキャラクタデータを変更することを特徴とする。
なお、第２のユーザに対して第１のユーザのキャラクタを特定する情報が提供された場合には、第１のユーザに提示する表示画面において第２のユーザのキャラクタを表示させず、第２のユーザに提示する表示画面において第１のユーザのキャラクタを表示させるステップを備えてもよい。

本発明の第４の観点は、複数のユーザの各々の操作に応じて、各ユーザによるゲームの進行を制御するために、コンピュータに、
ゲーム上のキャラクタと、キャラクタのデータであるキャラクタデータとを対応付けて記憶装置に記憶させる機能と、
ユーザごとに、ユーザの操作に応じてキャラクタデータを変更する機能と、
前記複数のユーザのうち第１のユーザのキャラクタを特定する情報を、第１のユーザとは異なる第２のユーザに対して提供する機能と、
を実現させるためのプログラムである。
このプログラムにおいて、前記変更する機能は、第２のユーザに対して第１のユーザのキャラクタを特定する情報が提供された場合には、第２のユーザの操作に応じて、第２のユーザのキャラクタのキャラクタデータと同時に、第１のユーザのキャラクタのキャラクタデータを変更する。
なお、上記プログラムによって、第２のユーザに対して第１のユーザのキャラクタを特定する情報が提供された場合には、第１のユーザに提示する表示画面において第２のユーザのキャラクタを表示させず、第２のユーザに提示する表示画面において第１のユーザのキャラクタを表示させる機能が実現されてもよい。

コンピュータは、例えばネットワークサーバ、大型計算機等であってよい。また、このプログラムは、ＤＶＤ−ＲＯＭやＣＤ−ＲＯＭ等のコンピュータが読み取り可能な情報記憶媒体に格納されてもよい。すなわち、本発明の第５の観点は、前記プログラムを記録したことを特徴とする、コンピュータ読み取り可能な記録媒体である。

本発明の第６の観点は、ユーザによって操作される通信端末と、当該通信端末とネットワークを介して接続され、各ユーザの操作に応じて、各ユーザによるゲームの進行を制御するゲーム制御装置と、を備えたゲームシステムである。
このゲームシステムは、
ゲーム上のキャラクタと、キャラクタのデータであるキャラクタデータとを対応付けて記憶する記憶手段、
ユーザごとに、ユーザの操作に応じてキャラクタデータを変更する制御手段、及び、
前記複数のユーザのうち第１のユーザのキャラクタを特定する情報を、第１のユーザとは異なる第２のユーザに対して提供する提供手段、
の各手段を、前記通信端末又は前記サーバのいずれか一方が備え、
前記制御手段は、第２のユーザに対して第１のユーザのキャラクタを特定する情報が提供された場合には、第２のユーザの操作に応じて、第２のユーザのキャラクタのキャラクタデータと同時に、第１のユーザのキャラクタのキャラクタデータを変更する。
なお、前記制御手段は、第１のユーザに提示する表示画面において第２のユーザのキャラクタを表示させず、第２のユーザに提示する表示画面において第１のユーザのキャラクタを表示させてもよい。

実施形態のゲームシステムの基本構成を示す図。 実施形態の通信端末の外観の例を示す図。 実施形態の通信端末の外観の例を示す図。 実施形態の通信端末の構成を示すブロック図。 実施形態のゲームサーバの構成を示すブロック図。 実施形態のデータベースサーバの構成を示すブロック図。 データベースサーバに含まれるユーザデータベースの構成例を示す図。 実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 トップページを表示する通信端末の表示画面の一例を示す図。 モンスターキャラクタのデータの内容を例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 バトルデータの内容を例示する図。 バトルデータの内容を例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示されるウェブページを例示する図。 ユーザの通信端末において表示されるウェブページを例示する図。 ユーザの通信端末において表示されるウェブページを例示する図。 実施形態のゲームサーバの主要な処理の一例を示すフローチャート。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示されるウェブページを例示する図。 ユーザの通信端末において表示されるウェブページを例示する図。 ユーザの通信端末において表示されるウェブページを例示する図。

本発明は、２０１１年１２月１９日に日本国特許庁に出願された特願２０１１−２７７７２２の特許出願に関連しており、当該出願の内容のすべてが参照によってこの明細書に組み込まれる。

（１）第１の実施形態
以下、第１の実施形態について説明する。

（１−１）ゲームシステムの構成
図１は、実施形態のゲームシステムのシステム構成例を示している。図１に示すように、このゲームシステムは、例えばインターネットなどの通信網ＮＷ（ネットワーク）に接続可能な通信端末１０ａ，１０ｂ，１０ｃ，…と、通信網ＮＷに接続されているゲームサーバ２０と、データベースサーバ３０とによって構成されている。各通信端末１０ａ，１０ｂ，１０ｃ，…はそれぞれ、個々のユーザによって操作される端末であり、例えば、携帯端末、スマートフォン、ＰＤＡ(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）等の形態の装置等、汎用ストレージで実現できる。データベースサーバ３０内の各データベースは、ゲームサーバ２０のデータベースアクセス部２４を介してＣＰＵ２１からのデータの読み書きが可能となるように構成されている。
図５に、データベースサーバ３０の構成の一例を示す。図５に示すように、データベースサーバ３０は、ユーザデータベース３１と、ゲームデータベース３２とを備える。

本実施形態のゲームサーバ２０によって実現されるゲームのタイプは特に限定されるものではないが、以下では、実施形態の説明の便宜上、ゲームサーバ２０によって実現されるゲームの一例として、ユーザの通信端末１０に対する操作に応じて、ユーザがゲーム上で仮想的に保有する戦士カードを使い、ゲーム上のモンスターであるモンスターキャラクタとバトルを行う対戦型デジタルカードゲームを採り上げる。
このデジタルカードゲームは、ユーザが戦士カードを収集することによって自らのチーム（軍隊）を作り上げ、例えば、他のユーザのチーム（軍隊）やモンスターキャラクタとバトルを行うように構成されているゲームである。このデジタルカードゲームには、自らのチームを作り上げていくために戦士カードを探索するミッション遂行処理や、抽選によって戦士カードを入手することを可能とする抽選処理、あるいは２枚以上の戦士カードを一体化して戦士カードの能力を上昇させる強化処理等が設けられている。

図６に、上述した対戦型デジタルカードゲームにおいて適用されるユーザデータベース３１の一例を示す。この例では、ユーザデータベース３１は、ユーザＩＤ（ユーザ識別情報）ごとに、表示名／表示画像、技能レベル、体力ポイント、攻撃ポイント、強化ポイント、友情ポイント、戦士数、所持コイン、仲間のユーザＩＤ、保有カードの画像データ、及び保有カードのパラメータの各項目についての情報を含む。ユーザデータベース３１に含まれる情報は、ゲームサーバ２０によって逐次更新されうる。

以下の説明では、ユーザデータベース３１に含まれるユーザＩＤ、あるいはユーザを特定する表示名（後述する）ごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、以下のとおりである。
・表示名／表示画像
ゲームの実行時に通信端末１０のユーザを特定するために表示される表示名及び表示画像である。表示名はユーザによって予め指定される所定長以下のテキストであり、表示画像は例えばユーザによって予め選択されるアバタ画像である。表示名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
・技能レベル
ゲーム上のユーザの技能レベル示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値である。
・体力ポイント
上記対戦型デジタルカードゲームにおいて、ユーザによるゲーム上のミッション遂行を行う上で必要となるポイントである。体力ポイントは、ミッション遂行を行うことで低減し、所定の時間が経過する毎に回復（増加）する値である。
・攻撃ポイント
上記対戦型デジタルカードゲームにおいて、ユーザによるゲーム上のバトルを行う上で必要となるポイントである。攻撃ポイントは、他のユーザ、あるいはモンスターキャラクタとのバトルによって低減し、所定の時間が経過する毎に回復（増加）する値である。
・強化ポイント
上記対戦型デジタルカードゲームにおいて、ユーザによる戦士カードの強化を行う上で必要となるポイントである。強化ポイントは、戦士カードの強化を行うことで低減し、他のユーザとのバトルで勝利するか、あるいは所定の時間が経過する毎に回復（増加）する値である。
・友情ポイント
上記対戦型デジタルカードゲームにおいて、仲間へ応援メッセージを送信することでユーザが取得するポイントである。
・戦士数
ユーザが保有する戦士カードの数である。戦士数は、ミッション遂行処理や強化処理の実行によって増減する。戦士数の最大値（例えば、６０）は予め規定されている。
・所持コイン
ユーザＩＤに対応するユーザがゲーム上で有料機能を利用するときに必要となるゲーム上の仮想通貨（コイン）の所持額である。所持コインは、ユーザがゲーム上で有料機能を利用したときに消費（低減）し、ユーザが、サービス提供者等に所定の方法で実際の金銭を支払うことでその支払額に応じて増加する。
・仲間のユーザＩＤ
対象となるユーザＩＤと予め関連付けられた他のユーザＩＤのデータである。
・保有カードの画像データ
上記対戦型デジタルカードゲームの場合、保有カードの画像データは、ユーザが保有する戦士カードについての画像を含むデータである。
・保有カードのパラメータ
保有カードのパラメータは、戦士カードの能力値を示すデータである。例えば、図６に示すように、パラメータの項目として「攻撃力」，「防御力」の各々の各能力値、及び「必要ポイント」が含まれてもよい。「必要ポイント」は、戦士カードをバトルで使用するときに必要となるポイントである。このゲームでは、バトルで使用する戦士カードの必要ポイントの総計が攻撃ポイント以下となるように制限されてもよい。

図５に戻り、ゲームデータベース３２は、ゲームサーバ２０からのアクセスに基づき、ゲームサーバ２０によって実行されたゲームの進行に関する情報を記憶、更新する。ゲームの進行に関する情報は、ゲームの性質によって多様な情報を含みうる。対戦型デジタルカードゲームの場合を例に挙げれば、ゲームの進行に関する情報は、異なるユーザ同士のバトルの結果や、後述する掘削実行処理の処理結果などを含む。

（１−５）ゲーム制御装置における各処理の概要
本実施形態では、ゲームサーバ２０及びデータベースサーバ３０によってゲーム制御装置が構成されている。以下では、上述した対戦型デジタルカードゲームが適用される場合を例として、本実施形態のゲーム制御装置で実現される機能について、図７を参照して説明する。図７は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。
なお、以下の説明において、通信端末１０に表示されるウェブページ上で表示されるメニュー、マーク等はウェブページ上で所望の位置に配置されるものであって、通信端末１０で視認されるメニュー、マーク等の表示画面上の位置は、ユーザの方向指示釦によるウェブページのスクロール操作によって変化しうる。

登録手段５１は、例えば通信端末１０に提供するウェブページ上での通信端末１０への適切な操作入力に基づいてユーザの要求を認識し、登録処理を行う。この場合の登録手段５１は、例えば以下のとおり実行される。ゲームサーバ２０のＣＰＵ２１は、無線通信インタフェース部２５を介して通信端末１０から登録要求メッセージを受信する。登録要求メッセージは、ゲームサーバ２０から提供されるウェブページ上での通信端末１０に対する所定の操作（例えば、所定のメニューの選択操作、テキスト入力等）によって自動的に生成されるように、ウェブページが構成されていてもよい。登録要求メッセージには、送信元の通信端末１０を特定するための情報（例えばＩＰアドレス、メールアドレス等）が含まれていてもよく、あるいは、ユーザが既に同一のサービス提供者による他のゲームを利用している場合には、そのユーザＩＤが含まれていてもよい。
ＣＰＵ２１は、登録要求メッセージを受信し、登録要求メッセージにユーザＩＤが含まれていない場合には、ユーザＩＤを新規に発行してそのユーザＩＤの登録処理を行った後、登録処理が完了した旨のメッセージを通信端末１０へ送信する。ＣＰＵ２１は、登録要求メッセージを受信し、登録要求メッセージにユーザＩＤが含まれている場合には、そのユーザＩＤの登録処理を行った後、登録処理が完了したことを示す登録完了メッセージを通信端末１０へ送信する。
登録が完了すると、ＣＰＵ２１は、ユーザＩＤに対応するユーザデータを生成し、ユーザデータベース３１に格納する。

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

ゲーム進行手段５２は、通信端末１０に対するユーザの操作に応じて、通信端末１０に表示されるウェブページを逐次更新するためのＨＴＭＬデータを送信することで、ゲームを進行させる。対戦型デジタルカードゲーム（以下、適宜単に「ゲーム」と略記する。）の例では、ゲームを進行させる上で以下の処理が行われうる。
・ミッション遂行処理：
自らのチームを作り上げていくためにミッションを遂行して戦士カードを得る処理である。このゲームでは、ミッションを遂行するには、一定量の行動ポイントが必要となる。
・強化処理：
２人以上の戦士カードを一体化して特定の戦士の能力を上昇させる処理である。このゲームでは、ユーザが強化処理を実行するには一定量の強化ポイントが必要となる。
・バトル実行処理：
他のユーザのチームとバトルを行う処理である。
・抽選処理：
ユーザが戦士カードを入手するための抽選を行う処理である。
・掘削実行処理：
ユーザの操作に応じて土地を掘削し、その土地のモンスターキャラクタを倒すことによって土地を攻略するプレイを実行する処理である（後述する）。

表示手段５２１は、ゲームで実行される上記複数の処理が各々割り当てられた複数のメニューを通信端末１０に表示させる機能を備える。具体的には、ＣＰＵ２１は、複数のメニューを含むウェブページを表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。ゲームでは、ミッション遂行処理、強化処理、バトル実行処理、及び抽選処理の各処理の実行に伴ってゲーム上のポイントが消費される。

表示手段５２１によって通信端末１０に表示されるゲームのトップページの例を図８に示す。このトップページは、個々のユーザＩＤに応じたウェブページで構成される。図８に例示されるトップページは、ユーザデータ表示領域、戦士画像表示領域及びメニュー表示領域を含む。
ユーザデータ表示領域は、対象となるユーザＩＤのユーザデータに含まれる、技能レベル、体力ポイント、攻撃ポイント、強化ポイント、友情ポイント、戦士数、仲間の各項目のデータ（図６参照）が表示される領域である。なお、ユーザデータ表示領域に表示される項目で、Ｘ／Ｙの形式で表記されているポイントまたは数は、Ｘがユーザの保有するポイントまたは数であり、Ｙがそのポイントまたは数の最大値であることを示す。例えば、戦士数が「４０／６０」と表記されていれば、ユーザが保有する戦士カードが４０枚であり、最大で保有可能な戦士カードの枚数が６０枚であることを示す。
戦士画像表示領域は、対象となるユーザＩＤのユーザデータに含まれる複数の戦士カードのうちユーザによって予め指定された戦士カードの画像が表示される領域である。
メニュー表示領域は、対戦型デジタルカードゲームに設けられる複数の機能（ミッション遂行処理、強化処理、バトル実行処理、抽選処理、掘削実行処理）に対応した基本メニューとして、「ミッション」、「強化」、「バトル」、「抽選」、「掘削」のテキストが表記された各メニューｍ１〜ｍ５が表示される領域である。つまり、ゲームで実行される複数の処理が各々割り当てられた複数のメニューが、通信端末１０に表示されるウェブページの所定の位置にそれぞれ配置される。

例えば図８に示すトップページをユーザの通信端末１０に表示する場合、ゲーム進行手段５２は以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、データベースアクセス部２４を介してユーザデータベース３１にアクセスし、ユーザデータ表示領域に含まれる各項目のデータと、戦士画像表示領域に表示すべき戦士カードの画像データを読み出す。次にＣＰＵ２１は、図８に示したトップページが構成されるようにＨＴＭＬデータを生成し、通信端末１０宛に送信する。生成されるＨＴＭＬデータは、ユーザごと（つまり、ユーザＩＤごと）に異なるものとなる。通信端末１０は、受信したＨＴＭＬデータを解釈してトップページの画像を表示部１６（表示画面１６ａ）に表示する。
ゲーム進行手段５２は、通信端末１０に表示されたメニューｍ１〜ｍ５のいずれかに対するユーザの選択操作に応じて、それぞれミッション遂行処理、強化処理、バトル実行処理、抽選処理、及び、掘削実行処理を実行する。好ましくは、各処理が実行された場合、さらに細分化された複数のメニューを含む新たなウェブページが表示されるように、階層的に各処理が実行される。

［掘削実行処理］
上述したように、ゲーム進行手段５２は、ユーザ単位で掘削実行処理を実行し、ユーザの操作に応じてキャラクタデータが変化しうるキャラクタを用いてゲームを進行させる機能を備える。ゲーム進行手段５２における掘削実行処理の機能及びその実現方法について、以下で詳しく説明する。

掘削実行処理時には、ゲーム上のモンスターキャラクタのデータがＣＰＵ２１によって参照される。図９は、モンスターキャラクタのデータの内容を例示するものであり、掘削実行処理の実行とともに例えばＲＡＭ２３にロードされ、記憶されるデータである。このデータは、ゲームデータベース３２に記憶させておいてもよい。図９では、一例として属性が異なる３種類のモンスターキャラクタＭＣ１〜ＭＣ３の各々について、モンスターキャラクタのパラメータとしてレベル（Ｌｖ）、攻撃力の値、守備力の値、及び、モンスターキャラクタのＨＰの値（体力を示す値；キャラクタデータ）が示されている。モンスターキャラクタのレベルが大きくなるほど、そのモンスターキャラクタの攻撃力の値、守備力の値、及びＨＰの値が大きくなるように設定されてもよい。図９では、属性が異なる３種類のモンスターキャラクタを示しているが、本実施形態では、モンスターキャラクタは少なくとも１種類設けられていればよい。なお、図９において、モンスターキャラクタの画像は、モンスターキャラクタの属性の一例である。

掘削実行処理によるゲームの流れは、以下のとおりである。
掘削実行処理は、掘削モードとバトルモードの各ゲームの処理を含む。掘削モードでは、ユーザの操作に応じて、複数の区画の土地が順に掘り進められ（掘削され）、各区画を掘り終わると、モンスターキャラクタが出現する。モンスターキャラクタが出現した場合には、ユーザの通信端末１０に対する操作に応じて、ユーザが保有する戦士カードと、出現したモンスターキャラクタとの間で、バトルを行うバトルモードに移行する。戦士カードの攻撃によってモンスターキャラクタのＨＰ（体力を示す値）がゼロになると、モンスターキャラクタは倒されてモンスターキャラクタが出現した区画の土地が攻略されたことになり、ユーザの掘削対象の土地の区画は、次の区画に移る。逆に、モンスターキャラクタの攻撃によって戦士カードの体力が無くなると、そのモンスターキャラクタが出現した区画の土地の攻略が失敗したことになり、モンスターキャラクタはその区画から無くならない。その場合、ユーザは、戦士カードの体力が回復した後に、再度同じモンスターキャラクタとバトルを行うことになる。

掘削実行処理における掘削モードの流れについて、図１０を参照して説明する。図１０では、操作を行うユーザが「ＫＮＭ」（以下、ユーザ：ＫＮＭと表記する。）である場合を一例として示している。図１０のステップＳ１〜Ｓ３は、掘削モードにおけるユーザの通信端末１０に表示されるウェブページの例を順に示している。
先ず、図８のトップページにおいてユーザによってメニューｍ５が選択操作されると、掘削実行処理のトップページがユーザの通信端末１０に表示されるように、ＨＴＭＬデータを生成して通信端末１０宛に送信する（図１０，ステップＳ１）。図１０のステップＳ１は、掘削実行処理におけるトップページであり、後述するバトルモードにおいて、自らのバトル相手となるモンスターキャラクタを例えば最大で３体、表示可能とするための表示領域１００と、他のユーザのバトル相手となるモンスターキャラクタを例えば最大で３体、表示可能とするための表示領域２００とを含む。

このトップページ上の「開始」のメニューｍ７が選択操作されたことをＣＰＵ２１が認識すると、ユーザの通信端末１０に表示されるウェブページは、所定数（図１０では１０個）の区画の土地を表す表示画像３００と、対象となる区画の土地の掘削率を表す表示画像３５０と、「掘る」のメニューｍ８とを含むものに移行する（図１０，ステップＳ２）。表示画像３００では、ユーザの掘削の対象となる区画の土地が区画３０１であることが視認可能に表される。ここで、「掘る」のメニューｍ８が選択操作されたことをＣＰＵ２１が認識すると、その都度、表示画像３５０に表示されている「掘削率」（％）の値がランダムな増加量にて増加して表示される。表示画像３５０に表示されている「掘削率」（％）が１００％になると、その区画の土地の掘削が完了したことになる（図１０，ステップＳ３）。
なお、「掘る」のメニューｍ８が選択操作される度に、ユーザの体力ポイントが一定量消費され、体力ポイントがゼロになった場合には掘削を続けることはできない。その場合には、体力ポイントが回復するまで待機する必要がある。

掘削率が１００％に達してバトルモードに移行したときに通信端末１０に表示されるウェブページの一例を図１１に示す。図１１のステップＳ４に示すように、出現したモンスターキャラクタの画像及びそのレベル（図１１ではＬｖ８）が表示されるとともに、その出現したモンスターキャラクタに対して、ユーザ１人で戦うことを選択するためのメニューｍ１０と、仲間のユーザに対してバトルの支援要請を行うためのメニューｍ１１とが表示される。

提供手段５２３は、第１のユーザとは異なる第２のユーザの通信端末１０に対し、第１のユーザのモンスターキャラクタ（つまり、第１のユーザのバトル相手であるモンスターキャラクタ；敵キャラクタ）の情報を提供する機能を備える。つまり、提供手段５２３は、第２のユーザが、自らのバトル相手であるモンスターキャラクタに加えて、他のユーザである第１のユーザのバトル相手であるモンスターキャラクタをも同時に攻撃を加えられるように、第１のユーザのモンスターキャラクタを特定する情報を第２のユーザの通信端末１０に提供する機能を備える。以降の説明では、ユーザ：ＫＮＭが「第１のユーザ」に相当し、ユーザ：ＡＢＣが「第２のユーザ」に相当する。
なお、以下では、第１のユーザの通信端末１０に対する操作に応じて、第１のユーザの通信端末１０からゲームサーバ２０宛に支援要請を行うための支援要請メッセージが送信されたことを契機として、提供手段５２３の機能が実現される場合について説明するが、これに限られない。支援要請メッセージは、バトルモードに移行するとともに自動的に、ゲームサーバ２０から仲間のユーザの通信端末１０宛に送信されるようにしてもよい。

図１１を参照すると、提供手段５２３の機能は、具体的に以下のとおり実現される。
ゲームサーバ２０のＣＰＵ２１は、図１１のステップＳ４に示すウェブページにおいてメニューｍ１１が選択されたことを認識すると、ユーザ：ＫＮＭのユーザデータを参照してユーザ：ＫＮＭの仲間を特定し、その特定した仲間を選択可能な形式で表示するためのＨＴＭＬデータをユーザ：ＫＮＭの通信端末１０宛に送信する。これにより、ユーザ：ＫＮＭの通信端末１０には、図１１のステップＳ５に示すウェブページが表示される。このウェブページにおいて、ステップＳ５のウェブページのリスト上で、支援要請先のユーザとして、ユーザ：ＡＢＣが選択された場合を例として、以下説明していく。

ユーザ：ＫＮＭの通信端末１０から、支援要請先のユーザとしてユーザ：ＡＢＣを指定した支援要請メッセージを受信すると、ＣＰＵ２１は、その支援要請を受諾するか否かを選択するためのメニューｍ２０，ｍ２１を含むウェブページを表示するためのＨＴＭＬデータを、ユーザ：ＡＢＣの通信端末１０宛に送信する。このＨＴＭＬデータの送信では、支援要請元であるユーザ：ＫＮＭのアバタ画像、及び、ユーザ：ＫＮＭのバトル相手のモンスターキャラクタを特定する情報が、ユーザ：ＡＢＣに対して提供される。図１１のステップＳ５では、提供されるモンスターキャラクタを特定する情報は、そのモンスターキャラクタの画像とレベルを含む例を示しているが、これに限られない。モンスターキャラクタを特定するためのテキストであってもよい。

ゲームサーバ２０のＣＰＵ２１は、図１１のステップＳ５に示すウェブページにおいてメニューｍ２０が選択されたことを認識すると、ユーザ：ＫＮＭ、及びユーザ：ＡＢＣの通信端末１０宛に、バトルモードにおいてバトル相手となるモンスターキャラクタを表示するためのＨＴＭＬデータを送信する。その結果、図１１のステップＳ６に示すように、例えば、ユーザ：ＫＮＭの通信端末１０に表示されるウェブページには、表示領域１００のサブ領域１０１にモンスターキャラクタＭＣ１が配置される。ユーザ：ＡＢＣの通信端末１０に表示されるウェブページには、表示領域２００のサブ領域２０１にモンスターキャラクタＭＣ１が配置される。

以上が提供手段５２３の実現方法の例である。なお、ＣＰＵ２１は、ステップＳ６の時点で、ユーザごとにバトルデータをＲＡＭ２３に生成する。バトルデータは、ユーザのバトル相手となるモンスターキャラクタのデータを管理するためのものである。図１１のステップＳ６の時点で生成されるバトルデータの例を、図１２Ａ及び図１２Ｂに例示する。図１２Ａは、ユーザ：ＫＮＭに対応するバトルデータの例であり、図１２Ｂは、ユーザ：ＡＢＣに対応するバトルデータの例である。図１２Ａ及び図１２Ｂに示すように、バトルデータは、ユーザごとに、自らのバトル相手となるモンスターキャラクタ、及び、支援要請を受諾した他のユーザのバトル相手となるモンスターキャラクタについて、レベル（Ｌｖ）、攻撃力、及びＨＰ（体力を示す値；キャラクタデータ）のデータを含む。モンスターキャラクタの攻撃力、及び初期のＨＰの値は、図９に示したモンスターキャラクタのデータを参照してランダムに決定されてよい。後述するように、バトル中の攻撃指示に応じてモンスターキャラクタに対する攻撃が加えられると、ＣＰＵ２１は、その都度バトルデータにアクセスし、攻撃が加えられたモンスターキャラクタのＨＰの値を変更する。ＣＰＵ２１は、バトル中にＨＰがゼロになったモンスターキャラクタを、バトルデータから削除する。
なお、バトル中のモンスターキャラクタのＨＰ（キャラクタデータ）を記憶するＲＡＭ２３は、記憶手段５２２の一例であってよい。また、バトル中のモンスターキャラクタのＨＰの記憶、更新のためにＲＡＭ２３にＣＰＵ２１がアクセスすることは、記憶手段５２２を実現するための一例であってよい。

図１１のステップＳ６において、モンスターキャラクタが配置されるサブ領域１０１，２０１にはそれぞれ、モンスターキャラクタのＨＰを示すゲージ１０１ｇ，２０１ｇが表示される。このゲージは、ユーザの操作による戦士カードのモンスターキャラクタに対する攻撃の程度に応じて低下する目盛りであり、バトルデータにおけるモンスターキャラクタのＨＰの値と連動している。

制御手段５２４は、ユーザごとに、ユーザの操作に応じて、ユーザのバトル相手となるモンスターキャラクタのＨＰ（キャラクタデータ）を変更する機能を備える。本実施形態において、制御手段５２４は、より具体的には、ユーザの操作に基づく攻撃指示に基づき、ユーザが保有する戦士カードがモンスターキャラクタに対して攻撃することによって、そのモンスターキャラクタのＨＰを低下させる機能を備える。
さらに制御手段５２４は、第２のユーザ（支援要請を受諾したユーザ；ＡＢＣ）対して第１のユーザ（支援要請元のユーザ；ＫＮＭ）のモンスターキャラクタを特定する情報が提供された場合には、第２のユーザの操作に応じて、第２のユーザのモンスターキャラクタのＨＰの値（キャラクタデータ）と同時に、第１のユーザのモンスターキャラクタのＨＰの値をも変更する機能を備える。なお、制御手段５２４は、第１のユーザに提示する表示画面において第２のユーザのキャラクタを表示させず、第２のユーザに提示する表示画面において第１のユーザのキャラクタを表示させてもよい。

以下の説明では、ユーザ：ＫＮＭのバトル相手であるモンスターキャラクタはユーザ：ＫＮＭの敵キャラクタであり、ユーザ：ＡＢＣのバトル相手であるモンスターキャラクタはユーザ：ＡＢＣの敵キャラクタである。
図１３を参照すると、制御手段５２４の機能は、具体的に以下のとおり実現される。図１３では、ユーザ：ＫＮＭからの支援要請を受諾したユーザ：ＡＢＣの通信端末１０に表示される一連のウェブページを例示する図である。図１３のステップＳ７では、ユーザ：ＫＮＭからの支援要請を受諾した結果、ユーザ：ＫＮＭのバトル相手であるモンスターキャラクタが表示領域２００のサブ領域２０１に配置されて表示され、その後に、自らのバトル相手となるモンスターキャラクタが出現して表示領域１００のサブ領域１０１に配置された場合の例を示している。図１３のステップＳ７が表示される時点では、ユーザ：ＡＢＣ（第２のユーザ）の通信端末１０に対して、ユーザ：ＫＮＭ（第１のユーザ）のモンスターキャラクタを特定する情報が既に提供されていることが想定されている。

この場合、ユーザ：ＡＢＣが保有する戦士カードによるバトル相手のモンスターキャラクタ（サブ領域１０１のモンスターキャラクタ）への攻撃は、ユーザ：ＫＮＭのバトル相手のモンスターキャラクタ（サブ領域２０１のモンスターキャラクタ）に対しても効果を発揮する（つまり、体力を低下させる）ように構成されている。例えば、図１３のステップＳ７に示すウェブページにおいて、「モンスターを攻撃する」というテキストが表記されたメニューｍ２３が選択されると、攻撃指示メッセージが通信端末１０からゲームサーバ２０宛に送信される。ゲームサーバ２０のＣＰＵ２１は、攻撃指示メッセージを受信すると、ユーザ：ＡＢＣが保有する複数の戦士カード（Ｃ１）が２体のモンスターキャラクタを同時に攻撃する状態を表示するためのＨＴＭＬデータを生成し、ユーザ：ＡＢＣの通信端末１０宛に送信する。その結果、図１３のステップＳ８に示すウェブページがユーザ：ＡＢＣの通信端末１０で表示される。このウェブページでは、２体のモンスターキャラクタの各々に、ゲージ１０１ｇ，１０２ｇと同一のゲージＧが表示される。

手持ちの複数の戦士カードとモンスターキャラクタとのバトルは、以下のように設定されてもよい。例えば、ユーザが保有する戦士カードの中からモンスターキャラクタとのバトルに参加可能な戦士カードの数（例えば５〜１０枚）が予め規定される。ユーザは、攻撃ポイントを一定量消費して、１又は複数の戦士カードによる１回の攻撃をモンスターキャラクタに対して行う。その攻撃に参加した１又は複数の戦士カードの攻撃力の値の総和に応じて、モンスターキャラクタのＨＰの値が低下する。なお、攻撃ポイントがゼロになった場合には、モンスターキャラクタに対して攻撃を加えられない。一方、モンスターキャラクタからも戦士カードに対してランダムなタイミングで、バトルデータに示す攻撃力で攻撃が加えられる。その結果、一定時間内にモンスターキャラクタのＨＰの値がゼロになった場合には、ユーザの戦士カードが勝利してその区画の土地の攻略に成功したと判断され、そうでない場合には、ユーザはその区画の土地の攻略に失敗したと判断される。

より具体的には、ＣＰＵ２１は、メニューｍ２３が選択されたことを認識すると、例えば、バトルに参加中の所定数の戦士カードの中から一定の基準あるいはランダムに、攻撃を行う戦士カードを選択し、その戦士カードの攻撃力の総和をユーザデータから読み取り、ＲＡＭ２３内のバトルデータにおけるモンスターキャラクタのＨＰの値から減算する処理を行ってもよい。ＣＰＵ２１は、減算後のモンスターキャラクタのＨＰの値をバトルデータに書き込むとともに、減算後の値に応じてゲージＧの目盛りの量を決定し、ＨＴＭＬデータを生成する。このとき、ＣＰＵ２１は、ユーザのウェブページに表示されているすべてのモンスターキャラクタのＨＰの値から減算する処理を行う。つまり、ＣＰＵ２１は、ユーザの通信端末１０に表示されているモンスターキャラクタの数とは無関係に、そのユーザによる１回の攻撃（つまり、１回分の攻撃ポイントの消費）によって、すべてのモンスターキャラクタに対してＨＰを低下させるように、バトルデータを更新する。例えば、図１３のステップＳ９に示すウェブページは、戦士カードの１回の攻撃によって２体のモンスターキャラクタの双方のＨＰが低下したことを示している。なお、２体のモンスターキャラクタのＨＰの変化量は異なっていてもよい。例えば、同じ攻撃力であってもモンスターキャラクタのレベルによって、低下するＨＰの変化量が異なる場合が考えられる。

２体のモンスターキャラクタのＨＰの変化量を異ならせる方法として、様々な方法を採り得る。例えば、処理対象である第２のユーザ（支援要請を受諾したユーザ；ＡＢＣ）のモンスターキャラクタのＨＰの変化量を、第１のユーザ（支援要請元のユーザ；ＫＮＭ）のモンスターキャラクタのＨＰのそれよりも大きくする方法を採ってもよい。この場合、第２のユーザによる攻撃では、自身のバトル相手のモンスターキャラクタへの攻撃を主として行われ、第１のユーザのバトル相手のモンスターキャラクタへの攻撃は、言わば副次的に行われる。

図１３において、サブ領域１０１又はサブ領域２０１のいずれかを選択することでモンスターキャラクタを選択可能とし、それによって主攻撃対象のモンスターキャラクタをユーザが指定できるようにしてもよい。その場合、ユーザによって指定された主攻撃対象のモンスターキャラクタのＨＰの変化量を、指定されていないモンスターキャラクタのそれよりも大きくしてもよい。つまり、図１３の例では、サブ領域１０１が選択された状態でメニューｍ２３（「モンスターを攻撃する」）に対する選択操作を認識した場合、ＣＰＵ２１は、ユーザ：ＡＢＣのバトル相手のモンスターキャラクタのＨＰの変化量を、ユーザ：ＫＮＭのバトル相手のモンスターキャラクタのそれよりも大きくしてもよい。逆に、サブ領域２０１が選択された状態でメニューｍ２３（「モンスターを攻撃する」）に対する選択操作を認識した場合、ＣＰＵ２１は、ユーザ：ＫＮＭのバトル相手のモンスターキャラクタのＨＰの変化量を、ユーザ：ＡＢＣのバトル相手のモンスターキャラクタのそれよりも大きくしてもよい。

図１３のステップＳ７では、表示領域１００及び表示領域２００にモンスターキャラクタがそれぞれ１つのみ表示されている例であるが、各領域に複数のモンスターキャラクタが表示されている場合には、サブ領域ごとに、つまりモンスターキャラクタごとに主攻撃対象のモンスターキャラクタをユーザが指定（選択）できるようにしてもよい。その場合、以下のように処理が行われてもよい。
ＣＰＵ２１は、表示領域１００に表示されているいずれかのモンスターキャラクタが指定された場合には、表示領域２００のいずれのサブ領域に表示されているモンスターキャラクタの中に、指定されたモンスターキャラクタと同一の属性のモンスターキャラクタが存在するか否か判定する。同一の属性のモンスターキャラクタが存在する場合には、ＣＰＵ２１は、そのモンスターキャラクタと指定されたモンスターキャラクタのＨＰを変化させ、同一の属性のモンスターキャラクタが存在しない場合には、指定されたモンスターキャラクタのＨＰのみを変化させる。なお、ＣＰＵ２１は、表示領域１００内で指定されたモンスターキャラクタと同一の属性の別のモンスターキャラクタが表示領域１００内に存在した場合でも、指定されたモンスターキャラクタのＨＰのみを変化させる。
一方、ＣＰＵ２１は、表示領域２００に表示されているいずれかのモンスターキャラクタが指定された場合には、表示領域１００のいずれのサブ領域に表示されているモンスターキャラクタの中に、指定されたモンスターキャラクタと同一の属性のモンスターキャラクタが存在するか否か判定する。同一の属性のモンスターキャラクタが存在する場合には、ＣＰＵ２１は、そのモンスターキャラクタと指定されたモンスターキャラクタのＨＰを変化させ、同一の属性のモンスターキャラクタが存在しない場合には、指定されたモンスターキャラクタのＨＰのみを変化させる。なお、ＣＰＵ２１は、表示領域２００内で指定されたモンスターキャラクタと同一の属性の別のモンスターキャラクタが表示領域２００内に存在した場合でも、指定されたモンスターキャラクタのＨＰのみを変化させる。
上述した処理を実現するためには、図１２Ａ及び図１２Ｂに示すバトルデータを、各バトル相手に対応付けて、そのバトル相手が表示されるサブ領域を記述するように構成する。ＣＰＵ２１は、バトルデータを参照し、ユーザによって指定されたサブ領域に対応するバトル相手を特定する。ＣＰＵ２１は、例えば、バトルデータの「他のユーザとそのバトル相手」のいずれかを、指定されたモンスターキャラクタとして特定した場合、「自らのバトル相手」の中から、指定されたモンスターキャラクタと同一の属性のモンスターキャラクタが存在するか否か判定する。同一の属性のモンスターキャラクタが存在する場合には、そのモンスターキャラクタと指定されたモンスターキャラクタの双方のＨＰをユーザの攻撃指示に応じて低下させるようにする。

ＨＰの変化量は、仲間のユーザ間の親密度に応じて異なるようにしてもよい。親密度とは、仲間のユーザ間の関係性の高さを一定の基準で数値化したものであってもよく、例えば、ユーザ間のメッセージの送信あるいは受信の頻度、ゲーム上で使用可能なアイテムなどのプレゼントを送信あるいは受信した回数などに基づいて設定されてもよい。例えば、上記頻度や上記回数が多いほど、親密度が高く設定されてもよい。ユーザ間の親密度を記述したデータ（親密度データ）は、例えばユーザデータベース３１に記憶される。ＣＰＵ２１は、ＨＰの変化量を算出するに当たって親密度データを参照し、ユーザ間の親密度に応じてＨＰの変化量を調整する。例えば、親密度が所定値よりも低い場合のＨＰ変化量を基準値とした場合に、親密度がその所定値以上である場合には、ＨＰ変化量を基準値×ｋ（ｋは、１より大きい係数）とする。
図１３の例では、ユーザ：ＡＢＣとユーザ：ＫＮＭの間の親密度が高いほど、ユーザ：ＡＢＣによるメニューｍ２３（「モンスターを攻撃する」）の選択操作によって、支援要請元のユーザ：ＫＮＭのバトル相手のモンスターキャラクタのＨＰの変化量を大きくすることが好ましい。仲間の間の親密度が高いほど、バトルを有利に進行させることができるため、ユーザ間の交流を促進させることができる。

ＣＰＵ２１は、モンスターキャラクタから戦士カードに対する攻撃をランダムなタイミングで発生させる。例えば、ＣＰＵ２１は、ＲＡＭ２３のバトルデータにアクセスして、モンスターキャラクタの攻撃力の値を読み出す。ＣＰＵ２１は、モンスターキャラクタによる攻撃を、例えば、バトルに参加中のいずれかの戦士カードにランダムに与え、攻撃が与えられた戦士カードの防御力よりもモンスターキャラクタの攻撃力が大きい場合には、その戦士カードが攻撃によって倒されたと判断する。モンスターキャラクタの攻撃で倒されるにつれて、更新されるウェブページ上で、ユーザの戦士カードの枚数が減少していくように表示することが好ましい。

ＣＰＵ２１は、メニューｍ２３の選択操作に応じた処理が終了すると、ユーザ：ＡＢＣによる操作に基づく攻撃によってモンスターキャラクタのＨＰを示すゲージが更新されるように、新たなＨＴＭＬデータを生成してユーザ：ＫＮＭ、及びユーザ：ＡＢＣの通信端末１０宛に送信する。その結果、図１４のステップＳ１０に示すウェブページがユーザ：ＫＮＭ、及びユーザ：ＡＢＣの通信端末１０に表示される。図１４のステップＳ１０を図１３のステップＳ７と比較すると、ユーザ：ＡＢＣによる攻撃によって、ユーザ：ＫＮＭ、及びユーザ：ＡＢＣの双方のバトル相手であるモンスターキャラクタのＨＰが低下したことが分かる（ゲージ１０１ｇ,２０１ｇを参照）。
図１４に示すように、本実施形態では、支援要請を行ったユーザ：ＫＮＭに提示する表示画面には、ユーザ：ＫＮＭのバトル相手のモンスターキャラクタが下段に表示されるが、ユーザ：ＡＢＣのバトル相手のモンスターキャラクタは表示されない。一方、支援要請を受諾したユーザ：ＡＢＣに提示する表示画面には、ユーザ：ＫＮＭのバトル相手のモンスターキャラクタが上段に表示されと、ユーザ：ＡＢＣのバトル相手のモンスターキャラクタが下段に表示される。つまり、本実施形態では、支援要請に基づく共通のモンスターキャラクタ（敵キャラクタ）のみが各ユーザの表示画面に表示され、それ以外のモンスターキャラクタ（つまり、自身のバトル相手のモンスターキャラクタ）については、個々のユーザの表示画面にのみ表示される。要するに、本実施形態では、ユーザ間で協力バトルを行っているものの、ユーザ間で表示画面が異なりユーザ間で仮想空間を共有するものではない。

図１５Ａは、ユーザの保有する戦士カードがモンスターキャラクタに勝利して、対象となる区画３０１の土地の攻略に成功した場合の、バトル後に通信端末１０に表示されるウェブページの例を示す図である。図１５Ｂは、ユーザの保有する戦士カードがモンスターキャラクタに敗北して、対象となる区画３０１の土地の攻略に失敗した場合の、バトル後に通信端末１０に表示されるウェブページの例を示す図である。図１５Ａに示す例では、区画３０１の土地の攻略に成功したことを示す旗の画像が区画３０１に表示される。一方、図１５Ｂに示す例では、倒すことができなかったモンスターキャラクタの画像が区画３０１に表示される。図１５Ｂにおいて、区画３０１を選択操作することによって、再度モンスターキャラクタとのバトルが実行されるように設定してもよい。

なお、図１３及び図１４では、支援要請を受諾したユーザ：ＡＢＣのバトル相手のモンスターキャラクタと支援要請元のユーザ：ＫＮＭのバトル相手のモンスターキャラクタの属性が同じ（この場合、共にモンスターキャラクタＭＣ１）である場合について説明したが、両者のモンスターキャラクタの属性が異なる場合であっても、ユーザ：ＡＢＣのメニューｍ２３（「モンスターを攻撃する」）の選択操作によって、ユーザ：ＡＢＣのバトル相手のモンスターキャラクタとユーザ：ＫＮＭのバトル相手のモンスターキャラクタのＨＰを両方とも変化（低下）させてもよい。その場合、ユーザ：ＫＮＭのモンスターキャラクタのＨＰの変化量を、属性が一致する場合よりも少なくしてもよいし、それぞれのモンスターキャラクタの属性に応じた値としてもよい。
あるいは、両者のモンスターキャラクタの属性が異なる場合には、ユーザ：ＡＢＣのメニューｍ２３（「モンスターを攻撃する」）の選択操作によって、ユーザ：ＡＢＣのバトル相手のモンスターキャラクタのＨＰのみが低下し、ユーザ：ＫＮＭのモンスターキャラクタのＨＰを変化させないようにしてもよい。

（１−６）本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、図１６のフローチャートを参照して説明する。図１６は、掘削実行処理におけるバトルモードの処理の例を示すフローチャートである。図１６では、図１１〜１４と同様に、支援要請元のユーザがユーザ：ＫＮＭ（第１のユーザ）であり、支援要請先のユーザがユーザ：ＡＢＣ（第２のユーザ）である場合を例として説明する。なお、図１６のフローチャートにおいて、ステップＳ４〜Ｓ１０の画面表示は、図１１，図１３及び図１４のステップＳ４〜Ｓ１０におけるウェブページの表示例に対応している。

先ず、掘削実行処理におけるバトルモードに移行すると、ユーザ：ＫＮＭの通信端末１０には、そのバトルモードで出現したモンスターキャラクタの画像及びそのレベルを表示するウェブページが表示されるとともに、メニューｍ１１の選択操作に応じて、支援要請先のユーザを選択するためのリストを含むウェブページが表示される（ステップＳ４，Ｓ５）。このリストの中からいずれかのユーザが選択されると、通信端末１０からゲームサーバ２０宛に、支援要請先のユーザ（ユーザ：ＡＢＣ）を指定した支援要請メッセージが送信される（ステップＳ１００）。ゲームサーバ２０は、支援要請メッセージを受信すると、ユーザ：ＫＮＭのモンスターキャラクタを特定する情報を含むＨＴＭＬデータを生成して、支援要請先であるユーザ：ＡＢＣの通信端末１０宛に送信する（ステップＳ１０２）。

ステップＳ１０２のＨＴＭＬデータを受信すると、ユーザ：ＡＢＣの通信端末１０には、支援要請元のユーザ、そのモンスターキャラクタを特定する情報とともに、支援要請を受諾するか否かについてのメニューを含むウェブページが表示される（ステップＳ５）。これにより、ユーザ：ＡＢＣに対して、モンスターキャラクタを特定する情報が提供されたことになる。ここで、ユーザ：ＡＢＣによって支援要請を受諾する選択操作がなされると、通信端末１０からゲームサーバ２０宛に受諾メッセージが送信される（ステップＳ１０４）。ユーザ：ＡＢＣからの受諾メッセージを受けて、ゲームサーバ２０は、支援要請元のユーザ：ＫＮＭの通信端末１０と、支援要請を受諾したユーザ：ＡＢＣの通信端末１０とに対して、新たなＨＴＭＬデータを送信する（ステップＳ１０６，Ｓ１０８）。それによって、ユーザ：ＫＮＭの通信端末１０には、所定の表示領域に自らのバトル相手となるモンスターキャラクタを含むウェブページが表示され、ユーザ：ＡＢＣの通信端末１０には、所定の表示流域にユーザ：ＫＮＭのバトル相手となるモンスターキャラクタを含むウェブページが表示される（ステップＳ６）。

その後、例えば、ユーザ：ＡＢＣにとって自らのバトル相手となるモンスターキャラクタが出現した場合を想定すると、そのモンスターキャラクタを特定する情報を含むＨＴＭＬデータが送信される（ステップＳ１１０）。この場合、ステップＳ１１０で送信されたＨＴＭＬデータに基づき、ユーザ：ＡＢＣの通信端末１０で表示されるウェブページ（ステップＳ７）には、所定の表示領域に自らのバトル相手となるモンスターキャラクタが表示され、他の表示領域にユーザ：ＫＮＭのバトル相手となるモンスターキャラクタが表示される。ここで、ユーザ：ＡＢＣによるモンスターキャラクタへの攻撃指示の操作（メニューｍ２３の選択操作）がなされると、ユーザ：ＡＢＣの通信端末１０からゲームサーバ２０宛に攻撃指示メッセージが送信される（ステップＳ１１２）。ゲームサーバ２０は、攻撃指示メッセージに応じて、ユーザ：ＫＮＭ、及びユーザ：ＡＢＣの双方のモンスターキャラクタのＨＰを低下させるようにしてバトルデータを更新し（ステップＳ１１４）、新たなＨＰの値を反映させたＨＴＭＬデータを生成してユーザ：ＡＢＣの通信端末１０宛に送信する（ステップＳ１１６）。これにより、ユーザ：ＡＢＣの通信端末１０に表示されるウェブページ上では、モンスターキャラクタのＨＰを示すゲージが変化する（ステップＳ９）。なお、ゲームサーバ２０は、ユーザ：ＡＢＣによる攻撃指示に基づき、ユーザ：ＡＢＣの攻撃ポイントが一定量低下するように、ユーザデータを更新する。

ユーザ：ＡＢＣによる攻撃指示の操作に応じた処理が終了すると、ゲームサーバ２０は、新たなＨＴＭＬデータを生成してユーザ：ＡＢＣ、及びユーザ：ＫＮＭの通信端末１０宛に送信する（ステップＳ１１８，Ｓ１２０）。このＨＴＭＬデータによって表示されるウェブページでは、ユーザ：ＡＢＣ、及びユーザ：ＫＮＭの双方のバトル相手であるモンスターキャラクタのＨＰが低下したことが視認できるようになっている（ステップＳ１０）。

上述したように、掘削実行処理におけるバトルモードの処理では、自らのモンスターキャラクタのみを攻撃するのに必要となる一定量の攻撃ポイントを消費して、自らのモンスターキャラクタのみならず、他のユーザのモンスターキャラクタをも攻撃できるように構成されている。それによって、各ユーザは、互いに協力してゲームを進行させている感覚を得ることができる。
また、上述したバトルモードの処理では、他のユーザのモンスターキャラクタを攻撃することによって攻撃ポイントを消費したために自らのモンスターキャラクタを攻撃することができないといった状況や、逆に、自らのユーザのモンスターキャラクタを攻撃することによって攻撃ポイントを消費したために他のユーザのモンスターキャラクタを攻撃することができないといった状況が生じない。そのため、ユーザは、自らのモンスターキャラクタとともに他のユーザのモンスターキャラクタを攻撃することで、より積極的に他のユーザのバトルを手助けすることができるようになる。よって、ユーザ間で互いに協力してゲームを進行させやすくなり、ゲームにおけるユーザ間のコニュニティの活性化を図ることができる。

（２）第２の実施形態
以下、第２の実施形態について説明する。第２の実施形態のゲームサーバ２０及びデータベースサーバ３０の構成については、第１の実施形態と同様のハードウエア構成とすることができる。

第１の実施形態では、ユーザのバトル相手となるモンスターキャラクタが１種類である場合（図１１〜１４参照）、つまりモンスターキャラクタが単一の属性に対応付けられている場合を例として説明したが、これに限られない。ユーザのバトル相手となるモンスターキャラクタが複数の属性のいずれかと対応付けられてもよい。なお、モンスターキャラクタの属性とは、例えばモンスターキャラクタの形態および／または色、模様、キャラクタそのものや能力を数値化したもの（レベル等）に加えて、モンスターキャラクタに設定された特定音(鳴き声等)など、モンスターキャラクタの違いを視覚的および／または聴覚的に区別可能な如何なる特性も含みうる。以下、本実施形態では、図９に示したように、属性（図９の例では、外観の画像）が異なる複数のモンスターキャラクタ（図９では、モンスターキャラクタＭＣ１〜３）の少なくともいずれかがユーザのバトル相手となる場合について説明する。

第１の実施形態では、ユーザによる攻撃指示の操作（図１３のメニューｍ２３の選択操作）によって、そのユーザのウェブページに表示されているすべてのモンスターキャラクタのＨＰが低下したが、本実施形態では、ユーザのウェブページに表示されているモンスターキャラクタの中で攻撃指示の操作によってＨＰが低下するモンスターキャラクタを、ユーザが選択操作可能に構成されている。

本実施形態では、制御手段５２４は、支援要請元のユーザ（第１のユーザ）のバトル相手のモンスターキャラクタと支援要請を受諾したユーザ（第２のユーザ）のバトル相手のモンスターキャラクタとが同じ属性である場合に、第２のユーザの操作に応じて第１のユーザのモンスターキャラクタのＨＰ（キャラクタデータ）を変更する機能を備える点が、第１の実施形態と異なる。

図１７を参照すると、本実施形態の制御手段５２４の機能は、具体的に以下のとおり実現される。図１７では、例えば複数のユーザからの支援要請を受諾したユーザ：ＡＢＣの通信端末１０に表示される一連のウェブページを例示する図である。図１７のステップＳ２０では、自らのバトル相手となる３体のモンスターキャラクタがそれぞれ表示領域１００のサブ領域１０１〜１０３に配置され、かつ、他の２人のユーザのバトル相手である２体のモンスターキャラクタがそれぞれ表示領域２００のサブ領域２０１，２０２に配置されて表示されている場合の例を示している。図１７のステップＳ２０が表示される時点では、ユーザ：ＡＢＣの通信端末１０に対して、他のユーザのモンスターキャラクタを特定する情報（モンスターキャラクタＭＣ１，ＭＣ３）が既に提供されている。

この場合、例えば図１７のステップＳ２０に示すように、「最も多いモンスターを攻撃する」というテキストを表記したメニューｍ２５を設けてもよい。このメニューｍ２５は、ウェブページに表示されているモンスターキャラクタの中で、ユーザ：ＡＢＣのバトル相手のモンスターキャラクタのいずれかと同じ属性であって、かつ最も多い同じ属性のモンスターキャラクタに対する攻撃指示を行うためのメニューである。メニューｍ２５が選択されると、攻撃指示メッセージが通信端末１０からゲームサーバ２０宛に送信される。ゲームサーバ２０のＣＰＵ２１は、攻撃指示メッセージを受信すると、ユーザ：ＡＢＣに対して提供されているモンスターキャラクタの中で、ユーザ：ＡＢＣのバトル相手のモンスターキャラクタのいずれかと同じ属性であって、最も多い同じ属性のモンスターキャラクタ（図１７のステップＳ２１の例では、３体のモンスターキャラクタＭＣ１）を特定し、その特定したモンスターキャラクタ３体を、ユーザ：ＡＢＣが保有する複数の戦士カード（Ｃ２）が同時に攻撃する状態を表示するためのＨＴＭＬデータを生成してユーザ：ＡＢＣの通信端末１０宛に送信する。その結果、図１７のステップＳ２１に示すウェブページがユーザ：ＡＢＣの通信端末１０で表示される。このウェブページでは、３体のモンスターキャラクタＭＣ１の各々に、ＨＰを示すゲージＧが表示される。

図１７のステップＳ２０に示すウェブページ上で、ユーザ：ＡＢＣがメニューｍ２５を表示せずに、いずれかのサブ領域を選択操作することによって、攻撃指示の対象とするモンスターキャラクタを選択するように構成してもよい。この構成によれば、ユーザは、いずれのモンスターキャラクタを攻撃することによって他のユーザを支援できるか考慮しながら、攻撃対象のモンスターキャラクタを選択することができるようになる。

複数の戦士カードとモンスターキャラクタとのバトルは、第１の実施形態で説明した方法と同様の方法であってよい。ＣＰＵ２１は、メニューｍ２５が選択されたことを認識すると、戦士カードの攻撃力に応じて、１回分の攻撃ポイントの消費によって３体のモンスターキャラクタＭＣ１のＨＰの値をすべて低下させる処理を行う。ＣＰＵ２１は、低下後のモンスターキャラクタのＨＰの値をＲＡＭ２３内のバトルデータに書き込むとともに、低下後の値に応じてゲージＧの目盛りの量を決定し、ＨＴＭＬデータを生成してユーザ：ＡＢＣの通信端末１０宛に送信する。その結果、図１７のステップＳ２２に示すように、３体のモンスターキャラクタすべてのＨＰが低下したことを示すウェブページがユーザ：ＡＢＣの通信端末１０に表示される。

ＣＰＵ２１は、メニューｍ２５の選択操作に応じた処理が終了すると、ユーザ：ＡＢＣによる操作に基づく攻撃によってモンスターキャラクタのＨＰを示すゲージが更新されるように、関連するユーザ向けに新たなＨＴＭＬデータを生成して送信する。例えば、図１７の表示領域２００のサブ領域２０１に表示されているモンスターキャラクタＭＣ１がユーザ：ＫＮＭからの支援要請に基づくものであった場合には、モンスターキャラクタＭＣ１のＨＰを示すゲージを更新するように、ユーザ：ＡＢＣ及びユーザ：ＫＮＭ向けに新たなＨＴＭＬデータを生成して送信する。その結果、図１８のステップＳ２３に示すウェブページが、ユーザ：ＫＮＭ、及びユーザ：ＡＢＣの通信端末１０に表示される。図１７のステップＳ２０を図１８のステップＳ２３と比較すると、ユーザ：ＡＢＣによる攻撃によって、ユーザ：ＡＢＣ及びユーザ：ＫＮＭの双方のバトル相手であるモンスターキャラクタＭＣ１のＨＰが低下したことが分かる（ユーザ：ＫＮＭ宛に表示されるゲージ１０１ｇ、ユーザ：ＡＢＣ宛に表示される１０２ｇ，１０３ｇ，２０１ｇを参照）。
図１８に示すように、本実施形態では、支援要請を行ったユーザ：ＫＮＭに提示する表示画面には、ユーザ：ＫＮＭのバトル相手のモンスターキャラクタが下段に表示されるが、ユーザ：ＡＢＣのバトル相手のモンスターキャラクタは表示されない。一方、支援要請を受諾したユーザ：ＡＢＣに提示する表示画面には、ユーザ：ＫＮＭのバトル相手のモンスターキャラクタと、ユーザ：ＫＮＭ以外のユーザで支援要請を行ったユーザのバトル相手のモンスターキャラクタとが上段に表示され、ユーザ：ＡＢＣのバトル相手のモンスターキャラクタが下段に表示される。つまり、本実施形態では、支援要請に基づく共通のモンスターキャラクタ（敵キャラクタ）のみが各ユーザの表示画面に表示され、それ以外のモンスターキャラクタ（つまり、自身のバトル相手のモンスターキャラクタ）については、個々のユーザの表示画面にのみ表示される。要するに、本実施形態では、ユーザ間で協力バトルを行っているものの、ユーザ間で表示画面が異なりユーザ間で仮想空間を共有するものではない。

本実施形態では、属性が異なる複数のモンスターキャラクタがゲーム上に登場する場合に、支援を行うユーザによる攻撃指示によって、支援を行うユーザのモンスターキャラクタと支援要請元のユーザのモンスターキャラクタとで同一の属性のモンスターキャラクタに対して攻撃が加えられる。そのため、本実施形態によれば、属性が異なる複数のモンスターキャラクタがゲーム上に登場する場合に、他のユーザのモンスターキャラクタを含めて最も攻撃の効果の高いモンスターキャラクタに対して、ユーザが攻撃を加えられるようになる。
また、本実施形態では、属性が異なる複数のモンスターキャラクタがゲーム上で設定されている場合であっても、支援要請を受諾したユーザは、自らのモンスターキャラクタのうち、支援要請元のゲームの進行に対して影響を与えることができるキャラクタを認識しながらゲームを進めることができる。つまり、いずれのモンスターキャラクタを攻撃することによって他のユーザを支援できるかについてユーザに判断させる構成となるため、ゲームの興趣性が増す。

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

（３−１）変形例１
制御手段５２４は、複数のユーザからの支援要請を受けたユーザ（第２のユーザ）に対してその複数のユーザのモンスターキャラクタを特定する情報が提供された場合には、支援要請を受けたユーザによる選択操作に基づいて、いずれかのモンスターキャラクタを選択する機能を備えてもよい。つまり、他のユーザからの支援要請を複数受けた場合、支援要請によって提供されるモンスターキャラクタの中からいずれのモンスターキャラクタを選択するかについて、ユーザが選択可能とすることが好ましい。その場合、支援要請を受けたユーザは、例えば、自らのバトル相手であるモンスターキャラクタと同一の属性のモンスターキャラクタを選択することができるため、他のユーザを支援しやすくなる。

上述した制御手段５２４の機能は、以下のようにして実現することができる。ゲームサーバ２０のＣＰＵ２１は、例えば一定期間内に特定のユーザ宛の支援要請メッセージを複数受信した場合には、その複数の支援要請メッセージによって特定される支援要請元のユーザとそのユーザのバトル相手のモンスターキャラクタを特定する情報を一覧形式に表示するためのＨＴＭＬデータを生成して、支援要請先のユーザの通信端末１０宛に送信する。その結果、支援要請先のユーザの通信端末１０には、例えば図１９に示すウェブページが表示される。このウェブページ上で、支援要請先のユーザによって、いずれかのユーザあるいはモンスターキャラクタが選択されると、ＣＰＵ２１は、その選択結果に基づいて支援対象とするユーザ（支援要請の受諾の返信先のユーザ）を決定する。

（３−２）変形例２
図１１では、ユーザ：ＫＮＭは、支援要請先のユーザを選択するためのリストからいずれかのユーザを選択した後に（ステップＳ５）、自らのバトル相手となるモンスターキャラクタの属性を認識するように構成されている（ステップＳ６）。このステップＳ５及びステップＳ６は逆であってもよい。つまり、ユーザは、先に自らのバトル相手となるモンスターキャラクタの属性を確認した後に、支援要請先のユーザを選択する構成であってもよい。その場合、ユーザは、既に自らのバトル相手のモンスターキャラクタが分かっているため、それに応じて支援要請先のユーザを選択できるようにすることが好ましい。

さらに、変形例２では、制御手段５２４は、支援要請元のユーザ（第１のユーザ）から支援要請がなされた場合、第１のユーザに対して複数のユーザのモンスターキャラクタを特定する情報を提供し、第１のユーザによる選択操作に基づいて、いずれかのモンスターキャラクタを選択し、そのモンスターキャラクタをバトル相手とするユーザを支援要請先のユーザとして決定してもよい。例えば、図１１のステップＳ６のウェブページが表示された後、ユーザ：ＫＮＭの通信端末１０に対して図２０に示すウェブページを表示させるようにする。このウェブページは、支援要請先の候補となる複数のユーザと、各ユーザのバトル相手のモンスターキャラクタを特定する情報のリストを含む。このウェブページを見たユーザ：ＫＮＭは、自らのバトル相手のモンスターキャラクタ（ステップＳ６ではモンスターキャラクタＭＣ１）が分かっているため、そのモンスターキャラクタと同一の属性のモンスターキャラクタを図２０のリストの中から選択することが動機付けられる。同一の属性のモンスターキャラクタを選択することにより、支援を行うユーザにとって負担にならないため（つまり、自らの攻撃ポイントを他のユーザのモンスターキャラクタだけに対する攻撃で消費することにならないため）、支援要請を受けたユーザがその支援要請を受諾する可能性が高いためである。

上述した制御手段５２４の機能は、以下のようにして実現することができる。ゲームサーバ２０のＣＰＵ２１は、例えば図１１のステップＳ４のウェブページにおいてメニューｍ１１が選択されると、ステップＳ６に示すウェブページが表示されるように表示の更新を行う。このステップＳ６のウェブページ上では、例えば、ユーザ１人で戦うことを選択するためのメニューｍ１０と、仲間のユーザに対してバトルの支援要請を行うためのメニューｍ１１とを表示することが好ましい（図示せず）。そして、メニューｍ１１が選択されたことを認識した場合に、ＣＰＵ２１は、図２０のステップＳ５のウェブページが表示されるように表示の更新を行う。このとき、図２０に表示されるリスト内のユーザは、ユーザ：ＫＮＭの仲間のユーザであることが好ましい。ＣＰＵ２１は、仲間のユーザのリストを作成するに当たってＲＡＭ２３内のバトルデータを参照し、仲間のユーザのバトル相手のモンスターキャラクタを特定する情報を取得する。

（３−３）変形例３
図１１のステップＳ５では、ユーザ：ＫＮＭが支援要請先のユーザを選択する構成としたが、これに限られない。提供手段５２３は、第１のユーザ（支援要請元のユーザ）の仲間の複数のユーザ（第１のユーザと関連付けられている複数のユーザ）のうち、支援要請を受諾するか否か（つまり、第１のユーザのモンスターキャラクタを特定する情報の提供を希望するか否か）について問い合わせをし、受諾すること（つまり、当該情報の提供を希望すること）を最初に回答したユーザを、支援要請先のユーザ（第２のユーザ）として特定してもよい。これにより、仲間を早く助けたいという、支援要請を受諾したユーザの欲求を満たすことができる。
この場合、ゲームサーバ２０のＣＰＵ２１は、図１１のステップＳ４のウェブページにおけるメニューｍ１１の選択操作を認識すると、ステップＳ５のウェブページには移行せずに、ユーザ：ＫＮＭのユーザデータを参照して、ユーザ：ＫＮＭのすべての仲間の通信端末１０宛に、支援要請メッセージを送信する。各仲間の通信端末１０では、図１１のステップＳ５に示したように、支援要請を受諾するか否かを選択するためのメニューｍ２０，ｍ２１を含むウェブページが表示される。その後、ＣＰＵ２１は、支援要請メッセージに応じて最初にメニューｍ２０の選択操作を行ったユーザ（つまり、最初に受諾メッセージを送信した通信端末１０のユーザ）を特定し、そのユーザを支援要請先のユーザとする。

（３−４）変形例４
上述した第２の実施形態では、図１７及び図１８に示したように、属性が異なる複数のモンスターキャラクタがゲーム上に登場する場合には、支援要請を受諾したユーザ：ＡＢＣの操作に応じて、支援要請元のユーザ：ＫＮＭとの間で同一の属性のモンスターキャラクタＭＣ１のみのＨＰを低下させる場合を示したが、これに限られない。ＨＰの低下対象のモンスターキャラクタを様々に設定できるようにしてもよい。例えば、ユーザ：ＡＢＣの操作に応じて、属性の如何に関わらずすべてのモンスターキャラクタのＨＰを低下させてもよい。その場合、支援要請を受諾したユーザ：ＡＢＣのバトル相手と支援要請元のユーザ：ＫＮＭのバトル相手が同一の属性のモンスターキャラクタ（図１７のＭＣ１）のＨＰ変化量を、両者で同一でない属性のモンスターキャラクタ（図１７のＭＣ２，ＭＣ３）のそれよりも大きくしてもよい。

なお、上述した各実施形態、及び各変形例では、支援要請元のユーザと、支援要請先のユーザとが、仲間（関連付けられているユーザ同士）である場合について説明したが、仲間に限られない。ユーザは、仲間でない他のユーザをも支援することができる。但し、支援要請先を仲間に限定することで、仲間間のコミュニティの活性化を図ることができる。

以上、本発明の実施形態について詳細に説明したが、本発明は上記実施形態に限定されない。また、各実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。
例えば、上記説明では、支援を行うユーザが１人（上記実施形態の説明では、ユーザ：ＡＢＣ）の場合について説明したが、これに限られない。支援を行うユーザが複数可能となるように構成されてよい。その場合、ウェブページに表示可能な、他のユーザのモンスターキャラクタの最大数（例えば図１１では、３体）は、支援を行うユーザの数に応じて増加させることが好ましい。
上述した実施形態では、モンスターキャラクタの属性が視覚的に異なる場合について説明したが、前述したように、モンスターキャラクタの属性は聴覚的に異なる場合であってもよい。その場合、例えば、通信端末１０に表示されているモンスターキャラクタを選択操作することによって、そのモンスターキャラクタの鳴き声が出力されるように構成される。そして、支援を行うユーザによる攻撃指示によって、支援を行うユーザのモンスターキャラクタと支援要請元のユーザのモンスターキャラクタとで同一の鳴き声を出力するモンスターキャラクタに対して攻撃が加えられるようにしてもよい。
上述した実施形態では、掘削実行処理のバトルモードにおいて、ユーザのバトル相手がモンスターキャラクタである場合を例として説明したが、これに限られない。例えば、ユーザのバトル相手は、そのユーザの仲間以外の他のユーザの戦士カードなどであってもよい。
上述した実施形態では、ソーシャルゲームに適用される場合を例として説明したが、これに限られない。例えば、ネットワーク上に置かれたサーバ装置と家庭用オンラインゲーム機とを接続した、いわゆるオンラインゲームシステムにおいても、上述した実施形態と同様に、各ユーザによるゲームの進行を制御できることは言うまでもない。

上述した実施形態では、ネットワーク上のゲームサーバ２０及びデータベースサーバ３０によって、図７に示した各手段の機能を実現する構成としたが、この構成に限られない。これらのすべての手段を通信端末１０によって実現する構成としてもよいし、少なくとも一部の手段を通信端末１０によって実現する構成としてもよい。通信端末１０とゲームサーバ２０とでは実質的に同一のハードウエア構成を採ることができるため、上記実施形態に記載したようにして通信端末１０によっても各機能を実現できる。その場合、上述した実施形態において、ユーザデータベース、モンスターキャラクタデータ、及びバトルデータのうち少なくともいずれかを、各ユーザの通信端末１０内の記憶装置（ＲＡＭ１３、あるいは図示しないＨＤＤ(Hard Disk Drive)などの大容量記憶装置等）や、例えばネットワーク上の別の記憶装置に記憶させてもよい。

Claims (8)

1. 複数のユーザの各々の操作に応じて、各ユーザによるゲームの進行を制御するゲーム制御装置であって、
   ゲーム上のキャラクタと、キャラクタのデータであるキャラクタデータとを対応付けて記憶する記憶手段と、
   ユーザごとに、ユーザの操作に応じてキャラクタデータを変更する制御手段と、
   前記複数のユーザのうち第１のユーザのキャラクタを特定する情報を、第１のユーザとは異なる第２のユーザに対して提供する提供手段と、
   を備え、
   前記制御手段は、第２のユーザに対して第１のユーザのキャラクタを特定する情報が提供されない場合には、第１のユーザ、及び第２のユーザの各々の操作に応じて、第１のユーザ、及び第２のユーザのキャラクタのキャラクタデータをそれぞれ独立に変更し、
   第２のユーザに対して第１のユーザのキャラクタを特定する情報が提供された場合には、第２のユーザの操作に応じて、第２のユーザのキャラクタのキャラクタデータと同時に、第１のユーザのキャラクタのキャラクタデータを変更し、第１のユーザに提示する表示画面において第２のユーザのキャラクタを表示させず、第２のユーザに提示する表示画面において第１のユーザのキャラクタを表示させることを特徴とする、
   ゲーム制御装置。
2. 前記第２のユーザに提示する表示画面において、前記第１のユーザのキャラクタと前記第２のユーザのキャラクタの各々のキャラクタデータを表示させることを特徴とする、
   請求項１に記載されたゲーム制御装置。
3. 各ユーザのキャラクタは属性と対応付けられており、
   前記制御手段は、第２のユーザに対して第１のユーザのキャラクタを特定する情報が提供されない場合には、第１のユーザ、及び第２のユーザの各々の操作に応じて、第１のユーザ、及び第２のユーザのキャラクタのキャラクタデータをそれぞれ独立に変更し、第２のユーザに対して第１のユーザのキャラクタを特定する情報が提供され、かつ、第１のユーザのキャラクタと第２のユーザのキャラクタの属性が同一である場合、第２のユーザの操作に応じて、第２のユーザのキャラクタのキャラクタデータと同時に、第１のユーザのキャラクタのキャラクタデータを変更することを特徴とする、
   請求項１または２に記載されたゲーム制御装置。
4. 前記制御手段は、前記第２のユーザに対して複数のユーザのキャラクタを特定する情報が提供された場合には、前記第２のユーザによる選択操作に基づいて、いずれかのキャラクタを選択し、
   第２のユーザの操作に応じて、第２のユーザのキャラクタのキャラクタデータと同時に、選択したキャラクタのキャラクタデータを変更することを特徴とする、
   請求項１〜３のいずれかに記載されたゲーム制御装置。
5. 前記複数のユーザの間の関連付けを記憶する第２の記憶手段、を備え、
   前記提供手段は、前記第１のユーザと関連付けられているユーザを前記第２のユーザとして特定することを特徴とする、
   請求項１〜４のいずれかに記載されたゲーム制御装置。
6. 前記複数のユーザの間の関連付けを記憶する第２の記憶手段、を備え、
   前記提供手段は、前記第１のユーザと関連付けられている複数のユーザのうち、前記第１のユーザのキャラクタを特定する情報の提供を希望するか否かについて問い合わせをし、当該情報の提供を希望することを最初に回答したユーザを、前記第２のユーザとして特定することを特徴とする、
   請求項１〜４のいずれかに記載されたゲーム制御装置。
7. 複数のユーザの各々の操作に応じて、各ユーザによるゲームの進行を制御するコンピュータに、
   ゲーム上のキャラクタと、キャラクタのデータであるキャラクタデータとを対応付けて記憶装置に記憶させる機能と、
   ユーザごとに、ユーザの操作に応じてキャラクタデータを変更する機能と、
   前記複数のユーザのうち第１のユーザのキャラクタを特定する情報を、第１のユーザとは異なる第２のユーザに対して提供する機能と、
   第２のユーザに対して第１のユーザのキャラクタを特定する情報が提供された場合には、第１のユーザに提示する表示画面において第２のユーザのキャラクタを表示させず、第２のユーザに提示する表示画面において第１のユーザのキャラクタを表示させる機能と、
   を実現させるためのプログラムであって、
   前記変更する機能は、第２のユーザに対して第１のユーザのキャラクタを特定する情報が提供されない場合には、第１のユーザ、及び第２のユーザの各々の操作に応じて、第１のユーザ、及び第２のユーザのキャラクタのキャラクタデータをそれぞれ独立に変更し、第２のユーザに対して第１のユーザのキャラクタを特定する情報が提供された場合には、
   第２のユーザの操作に応じて、第２のユーザのキャラクタのキャラクタデータと同時に、第１のユーザのキャラクタのキャラクタデータを変更することを特徴とする、
   プログラム。
8. ユーザによって操作される通信端末と、当該通信端末とネットワークを介して接続され、各ユーザの操作に応じて、各ユーザによるゲームの進行を制御するゲーム制御装置と、を備えたゲームシステムであって、
   前記ゲーム制御装置は、
   ゲーム上のキャラクタと、キャラクタのデータであるキャラクタデータとを対応付けて記憶する記憶手段と、
   ユーザごとに、ユーザの操作に応じてキャラクタデータを変更する制御手段と、
   前記複数のユーザのうち第１のユーザのキャラクタを特定する情報を、第１のユーザとは異なる第２のユーザに対して提供する提供手段と、を備え、
   前記制御手段は、第２のユーザに対して第１のユーザのキャラクタを特定する情報が提供されない場合には、第１のユーザ、及び第２のユーザの各々の操作に応じて、第１のユーザ、及び第２のユーザのキャラクタのキャラクタデータをそれぞれ独立に変更し、
   第２のユーザに対して第１のユーザのキャラクタを特定する情報が提供された場合には、第２のユーザの操作に応じて、第２のユーザのキャラクタのキャラクタデータと同時に、第１のユーザのキャラクタのキャラクタデータを変更し、第１のユーザに提示する表示画面において第２のユーザのキャラクタを表示させず、第２のユーザに提示する表示画面において第１のユーザのキャラクタを表示させることを特徴とする、
   ゲームシステム。

Images