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

Description

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

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

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

アプリＳＴＹＬＥ Vol.5（株式会社イースト・プレス）、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）などの端末の個体識別情報、メールアドレス等）が含まれていてもよく、あるいは、ユーザが既に同一のサービス提供者による他のゲームを利用している場合には、そのユーザＩＤが含まれていてもよい。

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

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

例えば、図１０に示すゲームのトップページ上でメニューｍ１が選択操作されたことによってＨＴＴＰリクエストが通信端末１０からゲームサーバ２０宛に送信されると、ゲームサーバ２０のＣＰＵ２１は、そのＨＴＴＰリクエストに応じて、図１１に示すバトルのトップページを表示するためのＨＴＭＬデータを含むＨＴＴＰレスポンスを通信端末１０宛に送信する。このとき、ＨＴＭＬデータを作成するに当たって、ＣＰＵ２１は、バトル管理データからゲームを実行中のユーザのバトル相手となるモンスターキャラクタとそのＨＰを読み出してＲＡＭ２３に記憶させるとともに、読み出したデータに基づいてＨＴＭＬデータを生成する。

モンスターキャラクタとのバトル処理では、ゲームサーバ２０のＣＰＵ２１は、ユーザによる適切な操作に応じて、ユーザが保有する戦士カードのうちバトルで使用される所定数の戦士カードの選択結果を取得する。なお、以下では、理解の容易のために、バトルに参加する戦士カードの数を１枚とする。ＣＰＵ２１は、各ユーザについて、モンスターキャラクタを倒したタイミングで、あるいはランダムなタイミングで、ゲームデータベース３２が記憶するモンスターキャラクタデータのうちいずれかのモンスターキャラクタをバトルのために出現させる。具体的には、ＣＰＵ２１は、ユーザのバトル相手となるモンスターキャラクタのデータを読み出し、バトル管理データに新たに書き込む。このとき、モンスターキャラクタのデータのＨＰの初期値がランダムに決定される。例えば、モンスターキャラクタデータにおいてモンスターキャラクタＭＣ１のＨＰが１５００〜２０００の範囲として設定されているが、実際のバトル処理を行うときに使用されるＨＰの初期値として、１５００〜２０００の範囲の中からランダムに１つの値が決定される。

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

また、攻撃操作に応じてバトル相手のモンスターキャラクタから戦士カードに対して、一定の、あるいはランダムな値の攻撃力にて攻撃が加えられる。モンスターキャラクタの攻撃力は、ＨＰに概ね比例した値としてもよいし、一定の、あるいはランダムな値であってもよい。モンスターキャラクタから加えられる攻撃力、あるいはその攻撃力の積算値（複数回の攻撃操作に伴う攻撃力の積算値）が戦士カードの防御力を上回った場合に、その戦士カードが倒されたことになる。ユーザがバトルで使用される戦士カードが１枚のみの場合、その戦士カードが倒されたときにはユーザの敗北となる。なお、戦士カードが複数枚バトルに参加する場合、モンスターキャラクタから加えられる攻撃の対象となる戦士カードは一定の順に、あるいはランダムに決定されてよい。

攻撃操作によるモンスターキャラクタのＨＰの更新は、上述した
式（１）に限られない。例えば、上記式（１）におけるＰａは戦士カードの攻撃力ではなく、所定の範囲の中から攻撃操作に応じてランダムに決定される数値としても良い。 また、バトルの勝敗の決定方法は適宜設定することができる。例えば、所定回数の攻撃操作によって、あるいは所定時刻までにモンスターキャラクタのＨＰをゼロにすることができなければ、そのモンスターキャラクタは倒せなかったと判断される。

ＣＰＵ２１は、更新後のモンスターキャラクタのＨＰの値がゼロになっていない場合には、更新後のモンスターキャラクタのＨＰ（ＲＡＭ２３上の値）をバトル管理データに書き込む。ＣＰＵ２１は、更新後のモンスターキャラクタのＨＰの値がゼロになった場合には、モンスターキャラクタを撃破したと判断して、バトル管理データから、対象となるユーザについてのモンスターキャラクタのデータを消去するとともに、ゲームの進行度としてのユーザデータのモンスター撃破数を１だけ増加させる。 ＣＰＵ２１は、ユーザによる１回のバトルが行われると、ユーザのユーザデータにアクセスして、攻撃ポイントの値を所定量、あるいはバトルで使用した戦士カードに応じた量だけ低下させる処理を行う。

受付手段５３は、支援要請元のユーザ（第１のユーザ）からバトル（第１の対戦）における支援要請を受け付ける機能を備える。 受付手段５３の機能は、以下のようにして実現することができる。ゲームサーバ２０のＣＰＵ２１は、例えば、ゲームを実行中のユーザによってメニューｍ２２（「支援要請する」）の選択操作が行われたことを認識すると、ゲームデータベース３２内の支援要請リストに所要のデータを書き込むことによって、支援要請を受け付ける。支援要請リストに書き込まれるデータは、図９に示したように、例えばユーザＩＤ、バトル相手（バトルでユーザが敗北したときのモンスターキャラクタ）、バトルの終了時刻等である。

判定手段５４は、支援要請元のユーザ（第１のユーザ）以外のユーザに対して、第１のユーザとのゲームの進行度の差に応じて、第１のユーザのバトル（第１の対戦）における支援要請を行うか否かを判定する機能を備える。 判定手段５４の機能は、例えば以下のようにして実現することができる。ゲームサーバ２０のＣＰＵ２１は、ユーザの通信端末１０から、ゲームのトップページあるいはバトルのトップページに対するＨＴＴＰリクエストが送信された場合には、そのユーザよりもモンスター撃破数が少ない（つまり、進行度が低い）ユーザからの支援要請があるか否か、支援要請リストを検索する。より好ましくは、ＣＰＵ２１は、上記ＨＴＴＰリクエストを送信したユーザよりもモンスター撃破数が所定数以上少ないユーザからの支援要請があるか否か、支援要請リストを検索する。モンスター撃破数の比較は、ＨＴＴＰリクエストを送信したユーザと、支援要請リストに記述されたユーザとの間のユーザデータのモンスター撃破数を読み出して、比較することにより行われる。

要請手段５５は、判定手段５４の判定結果に応じて、支援要請元のユーザ（第１のユーザ）以外のユーザのうち支援要請先の第２のユーザを特定し、第２のユーザに対して支援要請を行う機能を備える。 要請手段５５の機能は、以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、上述したように、ＨＴＴＰリクエストを送信したユーザと、支援要請リストに記述されたユーザとの間のユーザデータのモンスター撃破数を比較する。そして、ＣＰＵ２１は、支援要請リストに記述されたユーザのうち、ＨＴＴＰリクエストを送信したユーザよりもモンスター撃破数が少ないユーザの支援要請を、ＨＴＴＰリクエストを送信したユーザの通信端末１０宛に送信する。つまり、ゲームのトップページあるいはバトルのトップページに対するＨＴＴＰリクエストがユーザから送信される度に、そのユーザを支援要請先とするか否かについて、モンスター撃破数に基づいて判定することにより、第２のユーザが特定される。この場合、ＣＰＵ２１は、既に支援要請を送信したいずれかのユーザから支援要請を受諾する返信があるまで、ゲームのトップページあるいはバトルのトップページに対するＨＴＴＰリクエストを送信するユーザについて上記処理を行う。 なお、第２のユーザを特定するタイミングは上述した例に限られない。その他の例として、ＣＰＵ２１は、ユーザによるメニューｍ２２（「支援要請する」）の選択操作を認識し、支援要請を受け付けたタイミングでユーザデータを参照し、その時点におけるモンスター撃破数の差から１又は複数の第２のユーザを予め特定してもよい。そして、特定された第２のユーザのいずれかのユーザからアクセスが行われた（つまり、ゲームのトップページあるいはバトルのトップページに対するＨＴＴＰリクエストが送信された）ときに、そのアクセスしたユーザに対して支援要請を送信してもよい。

要請手段５５は、好ましくは、例えば図１３のウェブページＰ６に示したように、支援要請元のユーザ（第１のユーザ）からの支援要請に対して、第１の支援（後述する第１の支援手段５６による第１の支援）、又は第２の支援（後述する第２の支援手段５７による第２の支援）のいずれかを、上記第２のユーザが選択可能に提示する機能を備えてもよい。第１の支援は、支援要請を受諾した他のユーザが支援要請元のユーザのバトルに直接関与することなく、間接的に支援する（応援する）支援方法である。第２の支援は、支援要請を受諾した他のユーザが支援要請元のユーザのバトル相手とバトルを行う（参戦する）支援方法である。 この要請手段５５の機能を実現するために、ＣＰＵ２１は、ＨＴＴＰリクエストの送信元ユーザに対して、仲間からの支援要請があることを通知するメッセージと支援方法の選択メニューを含むようにして、ゲームのトップページあるいはバトルのトップページを表示するためのＨＴＭＬデータを送信する（例えば、図１３のウェブページＰ６参照）。

第１の支援手段５６（支援手段）は、支援要請元のユーザ（第１のユーザ）からの支援要請に応じた、第１のユーザ以外のユーザ（第２のユーザ）による所定の操作入力の情報に基づいて、バトルにおける第１のユーザのバトル能力、又はバトルのバトル相手のバトル能力を、第１のユーザが有利となるように調整する第１の支援を実行する機能を備える。ここで、第２のユーザは、支援要請先のユーザのうち支援要請を受諾したユーザを意味する。第２のユーザは、１人のユーザとは限らず複数存在してもよい。 第１の支援手段５６の機能は、以下のようにして実現することができる。ゲームサーバ２０のＣＰＵ２１は、いずれかのユーザ（支援要請先の第２のユーザ）からのメニューｍ３２（「応援する」）の選択操作（所定の操作入力）を認識すると、支援要請元のユーザ（第１のユーザ）の支援対象となるバトルにおいて、第１のユーザが使用する戦士カードの攻撃力を増加させる、あるいはバトル相手のモンスターキャラクタの攻撃力を低下させる処理を行う。なお、戦士カードの攻撃力の増加、あるいはモンスターキャラクタの攻撃力の低下は、所定比率の増加あるいは低下でもよいし、所定量の増加あるいは低下でもよい。

第２の支援手段５７は、支援要請元のユーザ（第１のユーザ）からの支援要請に応じて、第１のユーザ以外のユーザ（第２のユーザ）によって第１のユーザのバトル相手のモンスターキャラクタとのバトルを行う第２の支援を実行する機能を備える。 第２の支援手段５７の機能は、以下のようにして実現することができる。ゲームサーバ２０のＣＰＵ２１は、いずれかのユーザ（支援要請先の第２のユーザ）からのメニューｍ３１（「参戦する」）の選択操作（所定の操作入力）を認識すると、そのユーザと、支援対象のバトルにおけるモンスターキャラクタとの間で、バトルの処理を実行する。具体的には、ＣＰＵ２１は、第２のユーザが支援対象のバトルにおけるモンスターキャラクタに対して攻撃操作が可能となるようにＨＴＭＬデータを生成して、第２のユーザの通信端末１０宛に送信する（例えば、図１３のウェブページＰ７参照）。このとき、バトル相手となるモンスターキャラクタのＨＰは、支援要請リストに書き込まれているＨＰの値を元にバトルが開始される。

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

（７−１）支援要請を受諾したユーザが参戦することで支援する場合 先ず、ゲームを実行中のユーザＫＮＭ（第１のユーザ）が例えばモンスターキャラクタＭＣ１にバトルに敗北すると、例えば図１３のウェブページＰ４が表示される。ここで、メニューｍ２２（「支援要請する」）が選択操作され、支援要請を含むＨＴＴＰリクエストを受信すると（ステップＳ１００）、ゲームサーバ２０のＣＰＵ２１は、ゲームデータベース３２内の支援要請リストに所要のデータを書き込む（ステップＳ１１０）。書き込まれるデータは、図９に示したように、例えば、ユーザＩＤ、バトル相手（バトルでユーザが敗北したときのモンスターキャラクタ）、バトルの終了時刻等である。支援要請リストへの書き込み後、ＣＰＵ２１は、支援要請が受け付けられたことを通知するためのＨＴＭＬデータをユーザＫＮＭの通信端末１０宛に送信する（ステップＳ１２０）。これにより、例えば図１３のウェブページＰ５がユーザＫＮＭの通信端末１０に表示される。ユーザＫＮＭの支援要請が支援要請リストに書き込まれた後、ＣＰＵ２１は、ゲームのトップページあるいはバトルのトップページを表示するためのＨＴＭＬデータを送信するユーザを認識する度に、そのユーザがユーザＫＮＭよりもモンスター撃破数が多いか否かを判定し、多い場合には、そのユーザに対してユーザＫＮＭの支援要請を送信する（ステップＳ１４０）。つまり、支援要請元のユーザよりもモンスター撃破数が多い（つまり、ゲームの進行度が高い）ユーザを対象として支援要請が行われる。ここでは、ユーザＡＢＣの通信端末１０宛にユーザＫＮＭの支援要請が送信された場合を想定する。支援要請を受信したユーザＡＢＣの通信端末１０には、例えば図１３のウェブページＰ６が表示される。

ウェブページＰ６上でメニューｍ３１（「参戦する」）が選択操作され、支援要請が受諾されたことを認識すると（ステップＳ１５０）、ＣＰＵ２１は、ユーザＡＢＣと、ユーザＫＮＭがバトルで敗北したモンスターキャラクタＭＣ１との間のバトル画面用のＨＴＭＬデータを生成して送信する（ステップＳ１６０）。その結果、例えば図１３のウェブページＰ７がユーザＡＢＣの通信端末１０に表示される。このとき、ユーザＡＢＣのバトルにおけるモンスターキャラクタＭＣ１のＨＰは、バトル管理データのユーザＫＮＭのデータが読み出されて表示される。そして、ユーザＡＢＣの１又は複数回の攻撃操作に基づいて、ＣＰＵ２１は、バトル処理を行う（ステップＳ１７０）。ここで、ユーザＡＢＣがモンスターキャラクタＭＣ１を撃破した場合には、ＣＰＵ２１からのＨＴＭＬデータの送信に応じて、例えば図１３のウェブページＰ８がユーザＡＢＣの通信端末１０に表示される。 ＣＰＵ２１は、ユーザＡＢＣとモンスターキャラクタＭＣ１のバトルの後、支援要請リスト、バトル管理データ、及びユーザデータを更新する（ステップＳ１８０）。例えば、ユーザＡＢＣがモンスターキャラクタＭＣ１を撃破した場合、支援要請リストから、該当データ（ユーザＫ
ＮＭの対戦相手としてのモンスターキャラクタＭＣ１）を削除するとともに、バトル管理データ中、ユーザＫＮＭの出現中のモンスターの欄からモンスターキャラクタＭＣ１を削除する。また、ＣＰＵ２１は、ユーザＫＮＭとユーザＡＢＣのユーザデータにアクセスして、それぞれモンスター撃破数を１だけ増加させる。 その後、例えば、ユーザＫＮＭの通信端末１０からのゲームまたはバトルのトップページのＨＴＴＰリクエストの受信に応じて、ユーザＡＢＣによる支援結果を通知するためのＨＴＭＬデータをユーザＫＮＭの通信端末１０宛に送信する(ステップＳ１９０)。これにより、例えば図１３のウェブページＰ９がユーザＫＮＭの通信端末１０に表示される。

（７−２）支援要請を受諾したユーザが応援することで支援する場合 ステップＳ１００〜Ｓ１４０については、（７−１）の場合と同じであるため、重複説明を省略する。 ウェブページＰ６上でメニューｍ３２（「応援する」）が選択操作され、支援要請が受諾されたことを認識すると（ステップＳ２００）、ＣＰＵ２１は、応援により所定の特典が得られたことを通知するためのＨＴＭＬデータを生成して送信する（ステップＳ２１０）。その後に、ユーザＫＮＭが支援対象のモンスターキャラクタＭＣ１と再度バトルを行うときにＨＴＭＬデータが送信されると、ユーザＫＮＭの通信端末１０には、図１４のウェブページＰ１１に例示したように、応援によって攻撃力が上昇したことを通知するためのメッセージが表示される。その後、バトル処理において攻撃操作が行われたことを認識する度に、ＣＰＵ２１は、ユーザＫＮＭが使用する戦士カードの攻撃力を、例えば一定量あるいは一定比率上昇させるように調整する(ステップＳ２４０)。ＣＰＵ２１は、攻撃操作に応じて、調整された攻撃力に基づいてモンスターキャラクタＭＣ１のＨＰの低下量を決定してＨＰを更新する（ステップＳ２５０）。ＣＰＵ２１は、モンスターキャラクタＭＣ１のＨＰを更新すると、更新後のＨＰを含むＨＴＭＬデータを生成して（ステップＳ２６０）、ユーザＫＮＭの通信端末１０宛に送信する（ステップＳ２７０）。なお、図１７では、ステップＳ２３０〜Ｓ２７０は、１回の攻撃操作に応じた一連の処理を示しているが、複数回の攻撃操作が行われる場合には、ステップＳ２３０〜Ｓ２７０の処理が繰り返し行われる。

上述したように、支援要請を受諾したユーザＡＢＣが応援することによる支援を選択する場合、その支援方法は、ユーザＡＢＣが支援要請元のユーザＫＮＭのバトル相手と直接的にバトルすることではなく、例えば、支援要請元のユーザＫＮＭのバトル能力をユーザＫＮＭが有利となるように調整することである。言わば、第２の支援は、ユーザＫＮＭによるモンスターキャラクタＭＣ１とのバトルを間接的に支援するものである。つまり、ユーザＫＮＭが例えば自らの操作によってモンスターキャラクタＭＣ１とのバトルに勝利するように補助されるため、ユーザＫＮＭにとっては、バトルに勝利すれば自らバトルに勝利したという達成感を得ることができる。

以上説明したように、本実施形態のゲーム制御装置では、支援要請元のユーザ（第１のユーザ）の支援要請先が、ゲームの進行度の差に応じて決定される。例えば、第１のユーザよりもモンスター撃破数の多い（つまり、ゲームの進行度が高い）ユーザ（第２のユーザ）に対して支援要請が行われる。ゲームの進行度が高い第２のユーザはゲーム上の能力（例えば、バトルで使用する戦士カードの能力等）が高いと考えられるため、第２のユーザに対して支援要請が行われることで、第１のユーザに対する支援は実効性が高いものとなる。その結果、ゲームの進行度が低いユーザであっても、ゲームのシナリオに応じたゲームの面白味を感じられるようになる。また、ゲームの進行度が高いユーザが、ゲームの進行度が低いユーザのゲームの進行を補助する構成となるため、ユーザ全体でゲームの活性化が図れるようになる。

上記実施形態では、モンスター撃破数の差に応じて支援要請を行うか否か判定し、モンスター撃破数の差は適宜設定できる。また、上記実施形態の説明においても述べたが、判定手段５４は、支援要請元のユーザ（第１のユーザ）以外のユーザのうち、第１のユーザとのモンスター撃破数（ゲームの進行度）の差が所定値以上であるユーザに対して支援要請を行うと判定してもよい。 この構成では、支援要請先のユーザ（第２のユーザ）の数を適切に制限することができる。また、第１のユーザと比べて第２のユーザの進行度を十分に高く設定できるため、第１のユーザよりもゲーム上の能力が十分に高いユーザによる支援を受けることが期待でき、支援の実効性をより高めることができる。

上記実施形態において、第１の支援手段５６を設けることは必須ではなく、支援要請先のユーザ（第２のユーザ）を特定した後、その支援方法は適宜設定してもよいが、第１の支援手段５６によって実現される第１の支援は、以下の点で好ましい。 第２のユーザによって行われる第１の支援は、支援要請元のユーザ（第１のユーザ）のバトル相手と直接的にバトルすることではなく、第１のユーザがバトルで使用する戦士カードの攻撃力（第１のユーザの対戦能力）、又は第１のユーザのバトル相手の攻撃力を、第１のユーザが有利となるように調整することである。言わば、第１の支援は、第１のユーザによる第１の対戦を間接的に支援するものである。つまり、第１のユーザが例えば自らの操作によって第１の対戦に勝利するように補助されるため、第１のユーザにとっては自ら対戦に勝利したという達成感を得ることができる。

上記実施形態において、第２の支援手段５７を設けることは必須ではなく、支援要請先のユーザ（第２のユーザ）を特定した後、その支援方法は適宜設定してもよいが、支援要請元のユーザ（第１のユーザ）のバトル相手と直接的にバトルを行う第２の支援によっても、第１のユーザのゲームの進行を第２のユーザが補助することができる。また、第２の支援では、ゲームの進行度が高い第２のユーザによって、言わば直接的な支援が受けられるため、支援の実効性がより高くなる。

上記実施形態では、要請手段５５は、好ましくは、例えば図１３のウェブページＰ６に示したように、支援要請元のユーザ（第１のユーザ）からの支援要請に対して、第１の支援（メニューｍ３２）、及び第２の支援（メニューｍ３１）の方法を双方提示し、第２のユーザがいずれかの支援を選択可能にする例を示したが、その双方を提示せずにいずれか一方を提示するようにしてもよい。なお、第１の支援、及び第２の支援の方法を双方提示し、第２のユーザがいずれかの支援を選択可能にする構成とした場合には、第２のユーザが自らのゲームの進行状況に応じた柔軟な選択を可能とするゲーム設定とすることができる。

上記実施形態では、バトル実行手段５２は、ユーザによるバトルの実行に伴って当該ユーザの攻撃ポイント（ゲーム上のパラメータ）を消費するように構成したが、これに限られない。なお、ユーザがバトルを実行するに当たって攻撃ポイントを消費するように構成した場合には、支援要請を受けたユーザ（第２のユーザ）が、第１の支援又は第２の支援のいずれかの支援方法を選択するに当たって、第２の支援（支援要請元のユーザのバトル相手とのバトルを実行すること）による自らの攻撃ポイントの消費量を考慮しながら選択することになるため、深いゲーム性を実現できる。 例えば、モンスターキャラクタを倒すことで、あるいはモンスター撃破数に応じて特典を得られるゲーム設定とした場合には、第２のユーザが、自らの攻撃ポイントの消費量と、得られる特典とを比較考量する構成とすることができる。より具体的には、第１の支援（言わば間接的な支援）を行った場合には、自らバトルを行わないため攻撃ポイントを減少させずに済むが、比較的少量の特典しか付与されず、モンスター撃破数を増加させることはできない。他方、第２の支援（言わば直接的な支援）を行った場合には、自らバトルを行うことで比較的な大きな特典を得るためにモンスター撃破数を増加させることができるが、攻撃ポイントが減少してしまうため別の新たなバトルを直ちに実行することができなくなる。よって、第２のユーザにとっては、このような損得の事情を勘案しながら支援方法の選択を行うようになる。

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

（８−１）変形例１ 上述した実施形態において、第１の支援手段５６は、支援要請元のユーザ（第１のユーザ）と支援要請先のユーザ（第２のユーザ）の間のモンスター撃破数（ゲームの進行度）の差が大きいほど、第１のユーザがより有利になるように調整してもよい。これにより、第２のユーザのゲームの進行度が第１のユーザよりも高いほど、第２のユーザによる支援によって第１のユーザのゲームの進行がしやすくなる。その結果、支援を行う第２のユーザ次第で、第１のユーザのゲームの進行率が調整されることになり、ゲーム性の幅を広げることができる。 本変形例の第１の支援手段５６を実現するために、ゲームサーバ２０のＣＰＵ２１は、第２のユーザから支援要請の受諾の返信があったときに、第１のユーザと第２のユーザのモンスター撃破数の差を、ユーザデータを参照してもとめる。モンスター撃破数の差と、ユーザがバトルで使用する戦士カードの攻撃力の上昇率との関係を示すデータを例えばＲＯＭ２２に記憶させておく。ＣＰＵ２１は、モンスター撃破数の差をもとめると、ＲＯＭ２２内のデータを参照して、第１のユーザがバトルで使用する戦士カードの攻撃力の上昇率を決定する。

（８−２）変形例２ 図１８は、本変形例のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。図１８の機能ブロック図は、図１５と比較すると、関係付け手段５８が追加された点で異なる。関係付け手段５８は、ユーザ間を関係付ける機能を備える。例えば、関係付け手段５８は、ユーザＩＤに基づく申請を契機として、当該ユーザＩＤと他のユーザＩＤとを仲間として関係付ける機能を備える。

関係付け手段５８の機能は例えば、以下のとおり実現される。ゲームサーバ２０のＣＰＵ２１は、通信インタフェース部２５を介して、あるユーザＩＤに対応するユーザの通信端末１０から、仲間になりたいユーザＩＤ（あるいは、対応するユーザ名）を指定した申請メッセージ（申請）を受け付ける。この申請メッセージの送信は、ユーザの通信端末１０に提供されるウェブページの機能として予め設定されている。ＣＰＵ２１は、申請メッセージを受け付けると、申請メッセージに含まれるユーザＩＤに基づくアクセスがあったタイミングで、そのユーザＩＤに対応する通信端末１０宛に、他のユーザＩＤに基づく申請を承認するか否かを返信することを要求するためのウェブページを表示させるＨＴＭＬデータを送信する。その申請を承認することが返信されれば、ＣＰＵ２１は、両者を仲間として登録する。具体的には、ＣＰＵ２１は、ユーザデータベース３１内の対応する２つのユーザＩＤのユーザデータの「仲間のユーザＩＤ」の箇所（図６参照）にデータを書き込む。 なお、ユーザ同士を関係付ける条件は、上記のような申請と承認を必要とする形式に限らず、同一のゲーム上のステージを実行するユーザ同士を仲間として登録してもよい。あるいは、所定回数の挨拶メッセージを送信するユーザ同士を自動的に仲間として登録してもよいし、ユーザ間でバトルを行うゲーム上のモードが存在する場合には、所定回数以上バトルを行ったユーザ同士を自動的に仲間として登録してもよい。

本変形例では、要請手段５５は、支援要請先のユーザ（第２のユーザ）を、支援要請元のユーザ（第１のユーザ）と仲間として関係付けられたユーザの中から選択してもよい。このように選択することで、第１のユーザにとっては、仲間によって支援を受けているという実感が得られるため、仲間との関係性を高めることができる。そのため、ゲームのソーシャル性を高めることができる。 本変
形例における要請手段５５の機能は、以下のようにして実現することができる。 ゲームサーバ２０のＣＰＵ２１は、ユーザからゲームのトップページあるいはバトルのトップページに対するＨＴＴＰリクエストが送信されると、支援要請リストに記述されたユーザのうち、ＨＴＴＰリクエストを送信したユーザよりもモンスター撃破数が少なく、かつ仲間のユーザからの支援要請を、ＨＴＴＰリクエストを送信したユーザの通信端末１０宛に送信する。つまり、ゲームのトップページあるいはバトルのトップページに対するＨＴＴＰリクエストがユーザから送信される度に、そのユーザを支援要請先とするか否かについて、モンスター撃破数と仲間であるか否かに基づいて判定することにより、第２のユーザが特定される。この場合についても、ＣＰＵ２１は、既に支援要請を送信したいずれかのユーザから支援要請を受諾する返信があるまで、ゲームのトップページあるいはバトルのトップページに対するＨＴＴＰリクエストを送信するユーザについて上記処理を行う。

なお、支援要請先のユーザを支援要請元のユーザの仲間に限定してしまうと、第２のユーザ（支援要請先のユーザ）が決定することができない可能性がある。つまり、支援要請を行った後、仲間からのログイン又はアクセスがなく、支援を適時に受けられず、支援の実効性が失われる可能性がある。そこで、以下のように処理を行ってもよい。 ＣＰＵ２１は、支援要請リストに書き込まれてから所定期間の間、ユーザからゲームのトップページあるいはバトルのトップページに対するＨＴＴＰリクエストが送信される度に、支援要請リストに記述されたユーザのうち、ＨＴＴＰリクエストを送信したユーザよりもモンスター撃破数が少なく、かつ仲間のユーザからの支援要請を、ＨＴＴＰリクエストを送信したユーザの通信端末１０宛に送信する。上記所定期間の間に、支援要請先のユーザから支援要請を受諾する返信がない場合には、支援要請先のユーザを支援要請元のユーザの仲間に限定しないようにする。つまり、ＣＰＵ２１は、支援要請リストに記述されたユーザのうち、ＨＴＴＰリクエストを送信したユーザよりもモンスター撃破数が少ないユーザからの支援要請を、ＨＴＴＰリクエストを送信したユーザの通信端末１０宛に送信する。 なお、バトルに終了時刻が設定されている場合には、その終了時刻の所定時間前までに仲間からの支援要請の受諾の返信がなければ、支援要請先のユーザを支援要請元のユーザの仲間に限定しないようにしてもよい。

（８−２）変形例３ 上述した実施形態において、第１の支援手段５６によって実行される第１の支援（バトルにおける支援要請元の第１のユーザのバトル能力、又は第１のユーザのバトルのバトル相手のバトル能力を、第１のユーザが有利となるように調整すること）の支援要請を複数のユーザから受諾することを許容してもよい。その場合には、支援要請を受諾したユーザの数が増加するにつれて、第１のユーザがより有利となるように調整されるようにしてもよい。 本変形例を実現するために、例えば、ＣＰＵ２１は、支援要請リストに書き込まれてから所定期間の間、ユーザからゲームのトップページあるいはバトルのトップページに対するＨＴＴＰリクエストが送信される度に、支援要請リストに記述されたユーザのうち、ＨＴＴＰリクエストを送信したユーザよりもモンスター撃破数が少ないユーザからの支援要請を、ＨＴＴＰリクエストを送信したユーザの通信端末１０宛に送信する。そして、ＣＰＵ２１は、上記所定期間の間に支援要請を受諾した（つまり、メニューｍ３２（「応援する」）の選択操作をした）ユーザの数をカウントする。ＣＰＵ２１は、そのカウント値に応じて、例えば第１のユーザがバトルで使用する戦士カードの攻撃力の上昇率を決定する。 なお、本変形例では、図１４のウェブページＰ１１において、例えば５人のユーザからの応援による支援を受けている場合には、「５人の応援により攻撃力ＵＰ中！」などと表示させることが好ましい。

以上、本発明の実施形態について詳細に説明したが、本発明は上記実施形態に限定されない。また、各実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。例えば、上記実施形態及び各変形例に記載された技術的事項は適宜組合せて適用してもよい。

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

上述した実施形態では、本発明の実行対象のゲームがカードを用いたバトルゲームである場合の例について説明したが、本発明のゲームのこれに限られず、任意のゲームに適用することができる。例えば、ロールプレイングゲームやレースゲームのようにゲーム内のステージを進行させていくゲームでは、支援要請先のユーザのステージの進行度に応じて、支援要請元のユーザのステージの進行率を上昇させる（例えば、キャラクタやレースカー等の進行速度を早くする等）ようにすることができ、好適に本発明を適用することができる。また、本発明をＦＰＳ(First Person shooter)、ＴＰＳ(Third Person shooter)等のシューティングゲームに適用する場合には、支援要請先のユーザの敵オブジェクトの撃破数が多いほど（つまり、支援要請先のユーザの進行度が高いほど）、支援要請元のユーザに与えられる支援として、そのユーザのシューティングにおいて表示される照準の径が拡大するようにしてもよい。

上述した実施形態では、本発明のゲームの進行度の一例としてモンスター撃破数を挙げたが、ゲームの進行度は、ゲームの性質によって任意に設定可能である。例えば、ゲーム内でクリアしたステージの数や、ゲーム内で取得したアイテムの数、あるいはゲーム内で与えられた特定のミッションを達成した回数等、ミッションを所定回数達成する毎に上昇するレベル等のパラメータ、ゲーム画面上の特定のメニューの選択回数に応じて決定してもよい。

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

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

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

１０…通信端末 １１…ＣＰＵ １２…ＲＯＭ １３…ＲＡＭ １４…画像処理部 １５…指示入力部 １６…表示部 １７…通信インタフェース部 １８…バス ２０…ゲームサーバ ２１…ＣＰＵ ２２…ＲＯＭ ２３…ＲＡＭ ２４…データベースアクセス部 ２５…通信インタフェース部 ２６…バス ３０…データベースサーバ ３１…ユーザデータベース ３２…ゲームデータベース ５１…登録手段 ５２…バトル実行手段 ５３…受付手段 ５４…判定手段 ５５…要請手段 ５６…第１の支援手段 ５７…第２の支援手段

Claims (4)

1. ユーザによるゲーム上の対戦を実行する対戦実行手段と、
   第１のユーザから第１の対戦における支援要請を受け付ける受付手段と、
   第１のユーザ以外のユーザに対して、第１のユーザとのゲームの進行度の差に応じて、前記第１の対戦における支援要請を行うか否かを判定する判定手段と、
   前記判定手段の判定結果に応じて、第１のユーザ以外のユーザのうち、第１のユーザよりゲームの進行度が大きい支援要請先の第２のユーザを特定し、第２のユーザに対して前記支援要請を行って、第２のユーザが前記支援要請を受託したことを条件として、前記第１ユーザとのゲームの進行度の差の大きさに応じて、前記第１の対戦において前記第１のユーザがより有利になるように調整する、要請手段と、
   を備えた、ゲーム制御装置。
2. ユーザ間を関係付ける関係付け手段、を備え、
   前記要請手段は、前記第２のユーザを、前記第１のユーザと関係付けられたユーザの中
   から選択することを特徴とする、
   請求項１に記載されたゲーム制御装置。
3. コンピュータを、請求項１または２に記載されたゲーム制御装置の各手段として機能させるためのプログラム。
4. 通信端末と、当該通信端末からアクセスされるサーバとを含むゲームシステムであって、
   ユーザによるゲーム上の対戦を実行する対戦実行手段と、
   第１のユーザから第１の対戦における支援要請を受け付ける受付手段と、
   第１のユーザ以外のユーザに対して、第１のユーザとのゲームの進行度の差に応じて、前記第１の対戦における支援要請を行うか否かを判定する判定手段と、
   前記判定手段の判定結果に応じて、第１のユーザ以外のユーザのうち、第１のユーザよりゲームの進行度が大きい支援要請先の第２のユーザを特定し、第２のユーザに対して前記支援要請を行って、第２のユーザが前記支援要請を受託したことを条件として、前記第１ユーザとのゲームの進行度の差の大きさに応じて、前記第１の対戦において前記第１のユーザがより有利になるように調整する、要請手段と、
   の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
   ゲームシステム。

Images