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

Description

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

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

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

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

従来のソーシャルゲームにおいて、同一の対戦相手に対して複数のユーザがそれぞれ対戦を行い、各ユーザが対戦において与えたダメージを累積させることによって、当該対戦相手を撃破（当該対戦相手に勝利）するものが知られている。このようなゲームでは、結果として、複数のユーザが協力して対戦相手から勝利を得るようになっているが、各ユーザそれぞれの対戦においては、各ユーザが個々に対戦相手と対戦を行うように構成されている。このため、ユーザが対戦相手を撃破したとしても、当該ユーザは、自らの対戦を行うまでに既に当該対戦相手と対戦した（つまり、当該対戦相手から勝利を得るに至らなかった）他のユーザと協力して対戦を行ったという実感が得られないものとなっていた。

本発明は上述した観点に鑑みてなされたもので、ユーザによるゲーム上の対戦が行われる場合に、当該ユーザが、当該対戦における対戦相手と既に対戦した他のユーザと協力して対戦を行う実感が得られるようにしたゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供することを目的とする。

本発明の第１の観点は、ゲーム制御装置である。
当該ゲーム制御装置は、
ユーザによるゲーム上の対戦を実行する対戦実行手段と、
第１のユーザによる第１の対戦において前記第１のユーザが勝利条件を満たしていない場合に、前記第１のユーザに関する情報を記憶装置に記憶する記憶手段と、
所定の条件を満たす場合に、第２のユーザによる対戦であって前記第１の対戦における前記第１のユーザの対戦相手との対戦である第２の対戦中に、前記第１のユーザに関する情報を前記記憶装置から取得して前記第２のユーザに提供する情報提供手段と、
前記第１のユーザに関する情報が提供された場合に、前記第２の対戦において前記第２のユーザが有利になるようにゲーム上の設定を調整する調整手段と、
を備える。

ここで、「第１のユーザに関する情報」とは、例えば、第１のユーザであることを識別できる情報であれば何でもよいが、例えば、第１のユーザのゲーム上のユーザ名やアバタ画像等であってもよいし、第１のユーザがゲーム上保有するキャラクタやアイテムなどであってもよい。また、「第１のユーザに関する情報」は、例えば、テキストデータであってもよいし、画像データあるいは音声データなどであってもよい。
また、「所定の条件」とは、例えば、第２のユーザが所定数のエリアを制覇（クリア）したことであってもよいし、第２のユーザが所定数の他のユーザあるいはキャラクタとの対戦に勝利したことであってもよい。また、例えば、第２のユーザが所定数のアイテムを獲得したことであってもよいし、第２のユーザのゲームの進行度が所定値以上に達したことであってもよい。

このゲーム制御装置では、第２のユーザは、所定の条件を満たす場合に、第２の対戦中に、第１のユーザに関する情報を得ることができる。また、第１のユーザに関する情報が提供されると、第２の対戦において第２のユーザが有利になるようにゲーム上の設定が調整される。このため、第２のユーザは、自らの対戦を行うまでに既に同じ対戦相手と対戦した（つまり、当該対戦相手から勝利を得るに至らなかった）第１のユーザと協力して対戦を行っているという実感を得ることができる。

上記ゲーム制御装置において、前記所定の条件は、前記第１の対戦の結果に基づく前記第１のユーザの申請に応じて、前記第２のユーザが前記第２の対戦を行うことであってもよい。
このゲーム制御装置によれば、第２のユーザが、第１の対戦の結果に基づく第１のユーザの申請に応じて第２の対戦を行った場合、第２の対戦中に、第１のユーザに関する情報が第２のユーザに提供される。この場合、第２のユーザは、第１のユーザと協力して対戦していることをより実感できるだけでなく、第１のユーザからの申請に応えようという使命感を得ながら対戦を行うことができる。このため、第２のユーザにとっては、対戦相手から勝利を得た場合に得られる達成感を高めることができる。

上記ゲーム制御装置において、ユーザ同士を関係付ける関係付け手段を備え、前記所定の条件は、前記第２のユーザが前記第１のユーザと関係付けられていることであってもよい。
この場合、第２のユーザは、自らと関係付けられた第１のユーザ（仲間）に関する情報が第２の対戦中に提供されることにより、仲間と協力して対戦を行っているという実感を得ることができる。このため、仲間との関係性を高めることができ、ひいてはゲームのソーシャル性を高めることができる。

上記ゲーム制御装置において、前記所定の条件は、前記第２の対戦が、前記第１の対戦以降の所定期間内に行われることであってもよい。
このゲーム制御装置によれば、例えば、第２のユーザが、第１のユーザによる第１の対戦以降のほぼ同じ時期に第２の対戦を行った場合、第２の対戦中に、第１のユーザに関する情報が第２のユーザに提供される。このため、第２のユーザは、第１のユーザと協力して対戦していることをより実感できる。また、第１のユーザと第２のユーザが仲間として関係付けられている場合には、第１の対戦が第２の対戦とほぼ同時期に行われた（つまり、同一の対戦相手に対してほぼ同時期に対戦した）ことにより、第１のユーザに対して親近感を生じ得る。これにより、ユーザ間の交流を促進することができ、ひいてはユーザ間のさらなる密接な関係を構築することができる。

上記ゲーム制御装置において、前記情報提供手段は、前記第１のユーザが複数存在する場合に、複数の第１のユーザのうち、前記第１の対戦を行った時期が前記第２の対戦の時期から近い順に所定数のユーザに関する情報を、前記第２のユーザに提供してもよい。
この場合、第２のユーザは、第２の対戦の時期と近い時期に第１の対戦を行った所定数の第１のユーザに関する情報を、第２の対戦中に得ることができる。このため、第２のユーザは、第１の対戦が第２の対戦とほぼ同時期に行われた（つまり、同一の対戦相手に対してほぼ同時期に対戦した）ことにより、第１のユーザと協力して対戦していることをより実感できる。第２のユーザは所定数の第１のユーザに対して親近感を生じ得るため、第１のユーザと第２のユーザが仲間として関係付けられている場合には、第２のユーザと所定数の第１のユーザとの交流を促進することができ、ゲームのソーシャル性をさらに高めることができる。

上記ゲーム制御装置において、ユーザ同士を関係付ける関係付け手段を備え、前記情報提供手段は、前記第１のユーザが複数存在する場合に、複数の第１のユーザのうち、前記第２のユーザと関係付けられ、且つ、前記第２のユーザとの関係度合いを示す親密度が高い順に所定数のユーザに関する情報を、前記第２のユーザに提供してもよい。
この場合、第２のユーザは、複数の第１のユーザのうち、第２のユーザと関係付けられたユーザ（仲間）であって、第２のユーザとの親密度の高い所定数の仲間に関する情報を、第２の対戦中に得ることができる。このため、第２のユーザは、親密度の高い仲間と協力して対戦を行っているという実感を得ることができるので、親密度の高い仲間との関係度をさらに高めるように動機付けることができる。これにより、ユーザ間の密接な関係を構築することができる。

本発明の第２の観点は、ゲーム制御方法である。
当該ゲーム制御方法は、
ユーザによるゲーム上の対戦を実行するステップと、
第１のユーザによる第１の対戦において前記第１のユーザが勝利条件を満たしていない場合に、前記第１のユーザに関する情報を記憶装置に記憶するステップと、
所定の条件を満たす場合に、第２のユーザによる対戦であって前記第１の対戦における前記第１のユーザの対戦相手との対戦である第２の対戦中に、前記第１のユーザに関する情報を前記記憶装置から取得して前記第２のユーザに提供するステップと、
前記第１のユーザに関する情報が提供された場合に、前記第２の対戦において前記第２のユーザが有利になるようにゲーム上の設定を調整するステップと、
を備える。

本発明の第３の観点は、コンピュータに、
ユーザによるゲーム上の対戦を実行する機能、
第１のユーザによる第１の対戦において前記第１のユーザが勝利条件を満たしていない場合に、前記第１のユーザに関する情報を記憶装置に記憶する機能、
所定の条件を満たす場合に、第２のユーザによる対戦であって前記第１の対戦における前記第１のユーザの対戦相手との対戦である第２の対戦中に、前記第１のユーザに関する情報を前記記憶装置から取得して前記第２のユーザに提供する機能、及び
前記第１のユーザに関する情報が提供された場合に、前記第２の対戦において前記第２のユーザが有利になるようにゲーム上の設定を調整する機能、
を実現させるためのプログラムである。

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

本発明の第４の観点は、通信端末と、当該通信端末からアクセスされるサーバとを含むゲームシステムであって、
ユーザによるゲーム上の対戦を実行する対戦実行手段、
第１のユーザによる第１の対戦において前記第１のユーザが勝利条件を満たしていない場合に、前記第１のユーザに関する情報を記憶装置に記憶する記憶手段、
所定の条件を満たす場合に、第２のユーザによる対戦であって前記第１の対戦における前記第１のユーザの対戦相手との対戦である第２の対戦中に、前記第１のユーザに関する情報を前記記憶装置から取得して前記第２のユーザに提供する情報提供手段、
前記第１のユーザに関する情報が提供された場合に、前記第２の対戦において前記第２のユーザが有利になるようにゲーム上の設定を調整する調整手段、
の各手段を、前記通信端末又は前記サーバのいずれか一方が備える。

通信端末は、例えば携帯端末、スマートフォン、ＰＤＡ(Personal Digital Assistant)、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機、通信機能付きゲーム装置等であってよい。

本発明のゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムよれば、ユーザによるゲーム上の対戦が行われる場合に、当該ユーザは、当該対戦における対戦相手と既に対戦した他のユーザと協力して対戦を行う実感を得ることができる。

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

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

（１）ゲームシステムの構成
図１は、実施形態のゲームシステムのシステム構成例を示している。図１に示すように、このゲームシステムは、例えばインターネットなどの通信網ＮＷ（ネットワーク）に接続可能な通信端末１０ａ，１０ｂ，１０ｃ，…と、通信網ＮＷに接続されているゲームサーバ２０と、データベースサーバ３０とによって構成されている。各通信端末１０ａ，１０ｂ，１０ｃ，…はそれぞれ、個々のユーザによって操作される端末であり、例えば、携帯端末、スマートフォン、ＰＤＡ(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)の値とが対応付けられている。例えば、図７に示す例では、各モンスターキャラクタのＨＰは１５００〜２０００の範囲内であるが、この範囲の中からバトルを行うときにランダムにＨＰの値が設定されてもよい。

本実施形態のゲームでは、例えばユーザがモンスターキャラクタとのバトルにおいて敗北した場合に、他のユーザに対してそのバトルに対する支援要請を行うことができることとしているが、他のユーザに対して支援要請を行うこと及びその支援要請に対して他のユーザが受諾することは本発明における必須の要件ではない。なお、バトルの支援要請を行う条件は、ユーザがモンスターキャラクタとのバトルにおいて敗北したという条件に限られない。バトル開始時に無条件で支援要請できることとしてもよいし、バトルにおける所定の条件が満たされた場合にのみ支援要請ができることとしてもよい。「バトルにおける所定の条件」とは、例えば、ユーザがバトルで使用する戦士カード、及びバトル相手のモンスターキャラクタの攻撃力などのパラメータ（又は能力レベル）についての所定の条件でよく、より具体的には、例えば、戦士カードとモンスターキャラクタの攻撃力の差が一定値あることという条件としてもよい。
申請リストは、ユーザから行われた支援要請が順に書き込まれたリストである。
なお、申請リストは、本発明に必須のデータではないが、本発明をさらに好ましくするためのデータである。
申請リスト内の支援要請のうち支援が実行されたことによりモンスターキャラクタを撃破したものについては、リストから削除される。図８は、申請リストのデータ構成例を示す図である。図８に例示する申請リストでは、支援を要請した申請ユーザのユーザＩＤごとに、当該ユーザＩＤのユーザデータに含まれる複数の戦士カードのうちユーザによって予め指定された戦士カードの画像と、支援要請が行われたときのバトルのバトル相手（モンスターキャラクタ）と、バトル相手の残りＨＰと、支援要請に応じて支援する支援ユーザのユーザＩＤとが書き込まれる。残りＨＰは、対応するモンスターキャラクタの最新のＨＰの値を示している。例えば、１又は複数回のバトルにおいてＨＰが低減した場合に、低減後のＨＰが申請リストに書き込まれる。
また、図示を省略したが、申請ユーザのユーザＩＤごとに、支援要請が行われたときのバトルの日時（対戦日時）が記録されてもよい。この場合、申請ユーザの対戦日時から所定時間が経過するまでにモンスターキャラクタの残りＨＰをゼロにしなければ（つまり、モンスターキャラクタを撃破できなければ）、そのモンスターキャラクタは倒せなかったと判断され、当該申請ユーザの対戦日時に対応する支援要請がリストから削除されてもよい。

（５）本実施形態のゲーム
以下、本実施形態のゲームのモンスターキャラクタとのバトル処理について、図９〜１５を参照しながら説明する。図９は、本実施形態のゲームにおいて通信端末１０上に表示されるトップページの一例を示す図である。図１０〜１５は、バトル処理が実行されるときの通信端末１０上に表示されるウェブページの例を示す図である。また、ここでは、最初にバトル処理を実行するユーザが「ＡＢＣ」（以下、ユーザ：ＡＢＣと表記する。）である場合を一例として説明する。

図９に例示する本実施形態のゲームのトップページは、個々のユーザＩＤに応じたウェブページで構成される。図９の例では、ユーザデータ表示領域、戦士画像表示領域及びメニュー表示領域を含む。
ユーザデータ表示領域は、対象となるユーザＩＤのユーザデータに含まれる、技能レベル、戦士数、勝利数の各項目のデータ（図６参照）が表示される領域である。なお、図９において、戦士数の一例として「４０／６０」と表記されているが、これは、ユーザが保有する戦士カードが４０枚であり、最大で保有可能な戦士カードの枚数が６０枚であることを示す。
戦士画像表示領域は、対象となるユーザＩＤのユーザデータに含まれる複数の戦士カードのうちユーザによって予め指定された戦士カードの画像が表示される領域である。
メニュー表示領域は、本実施形態のゲームにおいてバトル処理の実行を開始するためのメニューｍ１を含む複数のメニュー（メニューｍ１以外は図示せず）が表示される領域である。

図９のトップページ上で、メニューｍ１が選択操作されると、図１０のステップＳ１に示すようにウェブページが更新される。ステップＳ１のウェブページには、モンスターキャラクタＭＣの画像のほか、「バトル開始」と表記されたメニューｍ１１などが表示される。

ステップＳ１のウェブページにおいてメニューｍ１１が選択されると、図１０のステップＳ２に示すようにウェブページが更新される。ステップＳ２のウェブページでは、ユーザ：ＡＢＣが保有する所定数（図の例では１０枚）の戦士カード２０２が表示される。また、ステップＳ２のウェブページでは、「攻撃する」と表記されたメニューｍ１２が表示される。戦士カード２０２は、ユーザ：ＡＢＣが保有する戦士カードの中からランダムに、あるいは予めユーザ：ＡＢＣの選択によって決定されてよい。
ここで、メニューｍ１２が選択操作されると、図１１のステップＳ３に示すようにウェブページが更新されて、ユーザ：ＡＢＣがモンスターキャラクタＭＣとの間でゲーム上のバトルを行うことになる。

モンスターキャラクタＭＣとのバトルでは、メニューｍ１２の選択操作に応じて行われる１０枚の戦士カードの攻撃によって、モンスターキャラクタＭＣのＨＰが低下する。メニューｍ１２が選択操作される毎に低下するＨＰの量は、戦士カードの攻撃力に応じて決定されてもよい。また、メニューｍ１２の選択操作に応じて、あるいはランダムなタイミングで、モンスターキャラクタＭＣから１０枚の戦士カードに対して順に攻撃が行われる。ステップＳ３のウェブページの１０枚の戦士カード２０２のうち、モンスターキャラクタＭＣに倒された戦士カード（ステップＳ３の例では、３枚のユーザの戦士カード２０２）については、倒れた形態でカードが表示される。バトルの結果、例えば、モンスターキャラクタＭＣのＨＰがゼロになり、且つ、ユーザ：ＡＢＣの１０枚の戦士カードのうち少なくとも１枚の戦士カードが倒されずにいる場合には、ユーザ：ＡＢＣがバトルに勝利し、モンスターキャラクタＭＣが撃破されたことになる。この場合、図１１のステップＳ４に示すようにウェブページが更新される。一方、例えば、モンスターキャラクタＭＣのＨＰがゼロにならず、且つ、ユーザ：ＡＢＣの１０枚の戦士カードがすべて倒された（全滅した）場合には、ユーザ：ＡＢＣがバトルに敗北した（勝利条件を満たさなかった）と判断されて、図１２のステップＳ５に示すようにウェブページが更新される。バトルに敗北した場合、モンスターキャラクタＭＣは消失せずに、バトル後に残存するＨＰが維持された状態となる。

なお、ステップＳ５のウェブページには、他のユーザに支援要請を行うための「支援要請する」と表記されたメニューｍ１３が表示される。
ここで、メニューｍ１３が選択操作されると、ユーザ：ＡＢＣは、申請ユーザとして申請リストに登録される。なお、メニューｍ１３が選択操作された場合、他のモンスターキャラクタとのバトルが行われるようにしてもよい。この場合、他のモンスターキャラクタの画像が表示されたステップＳ１のウェブページに更新される。

次に、ユーザ：ＡＢＣが支援要請を行ったときに、他のユーザがその支援要請を受諾してユーザ：ＡＢＣを支援する場合の一例について説明する。ここでは、支援要請を受諾してユーザ：ＡＢＣを支援する他のユーザ（支援ユーザ）が「ＸＹＺ」（以下、ユーザ：ＸＹＺと表記する。）である場合を一例として説明する。

先ず、ステップＳ５のウェブページにおいてユーザ：ＡＢＣがメニューｍ１３を選択操作すると、他のユーザに対して支援要請を受けるか否かを確認するためのメッセージが表示される。ここでは、他のユーザであるユーザ：ＸＹＺ向けのウェブページの一例を図１３のステップＳ６に示す。ステップＳ６のウェブページには、支援するか否かの選択を促すために、「参戦する」と表記されたメニューｍ１４と、「参戦しない」と表記されたメニューｍ１５とが表示される。ステップＳ６のウェブページにおいてメニューｍ１４（「参戦する」）が選択操作されると、図１３のステップＳ７に示すようにウェブページが更新されて、ユーザ：ＸＹＺが、自ら保有する所定数（図の例では１０枚）の戦士カード２０３を使用して、ユーザ：ＡＢＣのバトル相手であるモンスターキャラクタＭＣとバトルを行う画面に遷移する。ステップＳ７のウェブページは、例えば図１０のステップＳ２のウェブページと同形式であるが、モンスターキャラクタＭＣのＨＰの値は、ユーザ：ＡＢＣが敗北した時点のＨＰ（つまり、ステップＳ５のウェブページのモンスターキャラクタＭＣのＨＰ）の値となっている。
そして、ステップＳ７のウェブページにおいて、「攻撃する」と表記されたメニューｍ１６が選択操作されると、図１４のステップＳ８に示すようにウェブページが更新されて、ユーザ：ＸＹＺがモンスターキャラクタＭＣとの間でゲーム上のバトルを行うことになる。

ここで、図１４のステップＳ８に示すウェブページに更新されると、ユーザ：ＡＢＣが予め指定した戦士カードの画像（例えば、ユーザ：ＡＢＣのトップページの戦士画像表示領域に表示される戦士カードの画像）ＳＣが、ゲーム画面を瞬時に横切るように移動し、その後、図１４のステップＳ９に示すウェブページに更新される。ステップＳ９のウェブページは、例えば図１１のステップＳ３のウェブページと同形式であるが、ユーザ：ＡＢＣがユーザ：ＸＹＺのバトルに参戦したことを示すメッセージが含まれる。この場合、例えば、ユーザ：ＸＹＺがバトルで使用する戦士カード２０３の攻撃力が増加する。
これにより、ユーザ：ＸＹＺは、申請ユーザであるユーザ：ＡＢＣと協力してバトルを行っているという実感を得ることができる。

ユーザ：ＸＹＺによるバトルの結果、例えば、モンスターキャラクタＭＣのＨＰがゼロになり、且つ、ユーザ：ＸＹＺの１０枚の戦士カードのうち少なくとも１枚の戦士カードが倒されずにいる場合には、ユーザ：ＸＹＺがバトルに勝利し、モンスターキャラクタＭＣが撃破されたことになる。この場合、図１５のステップＳ１０に示すようにウェブページが更新される。一方、例えば、モンスターキャラクタＭＣのＨＰがゼロにならず、且つ、ユーザ：ＸＹＺの１０枚の戦士カードがすべて倒された（全滅した）場合には、ユーザ：ＸＹＺがバトルに敗北したと判断されて、図１５のステップＳ５に示すようにウェブページが更新される。バトルに敗北した場合、モンスターキャラクタＭＣは消失せずに、バトル後に残存するＨＰが維持された状態となる。
また、支援ユーザであるユーザ：ＸＹＺがバトルに敗北した場合には、ユーザ：ＸＹＺは、当該バトルの対戦相手であったモンスターキャラクタＭＣをバトルの対象とした支援要請を行うことができないようにしてもよい。なお、支援ユーザが支援要請を行えるようにしてもよいが、この場合には、ゲームバランスが偏るおそれがあるとともに、処理が煩雑になるおそれがある。このため、支援ユーザは、支援要請を行えないようにすることが好ましい。この場合、申請ユーザはユーザ：ＡＢＣのまま変わることなく、新たな支援ユーザがユーザ：ＡＢＣからの支援要請を受諾してバトルを行うことになる。

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

登録手段５１は、例えば通信端末１０に提供するウェブページ上での通信端末１０への適切な操作入力に基づいてユーザの要求を認識し、登録処理（ユーザ登録）を行う機能を備える。この登録処理は、ユーザが本実施形態のゲームにユーザ登録を行うときに実行される。
なお、登録手段５１は、本発明に必須の構成要素ではないが、本発明をさらに好ましくするための構成要素である。

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

対戦実行手段５２は、ユーザによるゲーム上のバトル（対戦）を実行する機能を備える。
ここで、本実施形態のゲームでは、バトルの相手（対戦相手）がモンスターキャラクタである場合を一例として説明しているが、対戦相手は、例えば、他のユーザであってもよいし、他のユーザの保有する複数あるいは単一の戦士カードからなるチームであってもよいし、ＣＰＵ２１が任意に抽出した複数あるいは単一の戦士カードからなるチームであってもよい。
対戦実行手段５２の機能は、例えば、通信端末１０に表示するウェブページを、通信端末１０からの要求に応じて逐次更新させることによって、ゲーム上のバトルを実行するようにしてもよい。この場合、対戦実行手段５２の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、通信端末１０からＨＴＴＰリクエストを受信し、そのＨＴＴＰリクエストに応じてゲーム上の所定の処理を行い、ゲームの実行結果としてのＨＴＭＬデータを含むＨＴＴＰレスポンスを通信端末１０宛に返信する。

例えば、図９に示すゲームのトップページ上でメニューｍ１が選択操作されたことによってＨＴＴＰリクエストが通信端末１０からゲームサーバ２０宛に送信されると、ゲームサーバ２０のＣＰＵ２１は、そのＨＴＴＰリクエストに応じて、図１０のステップＳ１に示すウェブページを表示するためのＨＴＭＬデータを含むＨＴＴＰレスポンスを通信端末１０宛に送信する。このとき、ＨＴＭＬデータを作成するに当たって、ＣＰＵ２１は、モンスターキャラクタデータからゲームを実行中のユーザのバトル相手となるモンスターキャラクタを読み出してＲＡＭ２３に記憶させるとともに、読み出したデータに基づいてＨＴＭＬデータを生成する。
また、ＣＰＵ２１は、例えば、ユーザの通信端末１０から、ゲームのトップページに対するＨＴＴＰリクエスト、あるいはメニューｍ１の選択操作に基づくＨＴＴＰリクエストが送信された場合には、そのユーザよりも勝利数が少ないユーザからの支援要請があるか否か、要請リストを検索し、ＨＴＴＰリクエストを送信したユーザよりも勝利数が少ないユーザが存在する場合には、当該ユーザの支援要請を、ＨＴＴＰリクエストを送信したユーザの通信端末１０宛に送信してもよい。なお、「そのユーザよりも勝利数が少ないユーザからの支援要請があるか否か」という条件は必須の条件ではなく、この条件についての判別処理を行わなくてもよい。この場合、ＨＴＴＰリクエストを送信したユーザの通信端末１０には、例えば、ステップＳ６に示したウェブページが表示される。

モンスターキャラクタとのバトル処理では、ゲームサーバ２０のＣＰＵ２１は、ユーザによる適切な操作に応じて、ユーザが保有する戦士カードのうちバトルで使用される所定数の戦士カードの選択結果を取得する。なお、以下では、理解の容易のために、バトルに参加する戦士カードの数を１枚とする。ＣＰＵ２１は、各ユーザについて、モンスターキャラクタを倒したタイミングで、あるいはランダムなタイミングで、ゲームデータベース３２が記憶するモンスターキャラクタデータのうちいずれかのモンスターキャラクタをバトルのために出現させる。具体的には、ＣＰＵ２１は、ユーザのバトル相手となるモンスターキャラクタのデータを読み出し、ＲＡＭ２３に新たに書き込む。このとき、モンスターキャラクタのデータのＨＰの初期値がランダムに決定される。例えば、モンスターキャラクタデータにおいてモンスターキャラクタＭＣ１のＨＰが１５００〜２０００の範囲として設定されているが、実際のバトル処理を行うときに使用されるＨＰの初期値として、１５００〜２０００の範囲の中からランダムに１つの値が決定される。
なお、ＣＰＵ２１は、支援ユーザからのメニューｍ１４（「参戦する」）の選択操作を認識すると、当該支援ユーザと、支援対象のバトルにおけるモンスターキャラクタとの間で、バトルの処理を実行する。具体的には、ＣＰＵ２１は、支援ユーザが支援対象のバトルにおけるモンスターキャラクタに対して攻撃操作が可能となるようにＨＴＭＬデータを生成して、支援ユーザの通信端末１０宛に送信する（例えば、図１３のステップＳ７のウェブページ参照）。このとき、バトル相手となるモンスターキャラクタのＨＰは、要請リストに書き込まれている残りＨＰの値を元にバトルが開始される。このとき、ＣＰＵ２１は、要請リストに書き込まれている残りＨＰの値をＲＡＭ２３に書き込む。なお、ＣＰＵ２１は、支援ユーザからのメニューｍ１４の選択操作を認識すると、当該支援ユーザのユーザＩＤを、申請リストのうち、支援対象の申請ユーザのユーザＩＤに対応する支援ユーザのユーザＩＤの箇所（図８参照）に記録する。

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

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

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

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

ＣＰＵ２１は、更新後のモンスターキャラクタのＨＰの値がゼロになった場合には、モンスターキャラクタを撃破した（モンスターキャラクタに勝利した）と判断し、ユーザデータの勝利数を１だけ増加させる。

記憶手段５３は、ゲームを実行中のユーザ（第１のユーザ）によるバトル（第１の対戦）において当該ユーザが勝利条件を満たしていない場合に、当該ユーザに関する情報をゲームデータベース３２（記憶装置）に記憶する機能を備える。
ここで、ユーザに関する情報とは、例えば、当該ユーザであることを識別できる情報であれば何でもよいが、例えば、当該ユーザのゲーム上のユーザ名やアバタ画像等であってもよいし、当該ユーザがゲーム上保有するキャラクタやアイテムなどであってもよい。また、ユーザに関する情報は、例えば、テキストデータであってもよいし、画像データあるいは音声データなどであってもよい。
記憶手段５３の機能は、例えば以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、例えば、ゲームを実行中のユーザによってメニューｍ１３（「支援要請する」）の選択操作が行われたことを認識すると、ゲームデータベース３２内の申請リストに所要のデータを書き込むことによって、当該ユーザに関する情報を記憶する。申請リストに書き込まれるデータは、図８に示したように、例えばメニューｍ１３を選択操作したユーザ（申請ユーザ）のユーザＩＤ、戦士カードの画像、バトル相手（バトルでユーザが敗北したときのモンスターキャラクタ）、モンスターキャラクタの残りＨＰ等である。なお、メニューｍ１３の選択操作が行われなくても、ゲームを実行中のユーザがバトルに敗北した場合には、当該ユーザに関する情報が申請リストに記憶されてもよい。
なお、本実施形態では、ゲームを実行中のユーザによってメニューｍ１３（「支援要請する」）の選択操作が行われたことによって、当該ユーザに関する情報がゲームデータベース３２に記憶される場合を一例として説明しているが、例えば、当該ユーザがバトルにおいて勝利条件を満たしていないと判別されたときには、当該ユーザに関する情報がゲームデータベース３２内の所定の記憶領域に自動的に記憶されてもよい。

情報提供手段５４は、所定の条件を満たす場合に、支援ユーザ（第２のユーザ）による対戦であって、バトルにおいて勝利条件を満たさなかったユーザ（第１のユーザ）のバトル（第１の対戦）における当該ユーザの対戦相手との対戦であるバトル（第２の対戦）中に、当該ユーザに関する情報をゲームデータベース３２（記憶装置）から取得して支援ユーザに提供する機能を備える。
ここで、「所定の条件」とは、例えば、支援ユーザが所定数のエリアを制覇（クリア）したことであってもよいし、支援ユーザが所定数の他のユーザあるいはキャラクタとの対戦に勝利したことであってもよい。また、例えば、支援ユーザが所定数のアイテムを獲得したことであってもよいし、支援ユーザのゲームの進行度が所定値以上に達したことであってもよい。
また、バトルにおいて勝利条件を満たさなかったユーザは、申請ユーザだけでなく、申請ユーザからの支援要請に応じてバトルを行ったものの勝利することができなかった支援ユーザも含む。

また、所定の条件は、バトルにおいて勝利条件を満たさなかったユーザ（第１のユーザ）のバトル（第１の対戦）の結果に基づく当該ユーザの支援要請（申請）に応じて、支援ユーザ（第２のユーザ）がバトル（第２の対戦）を行うことであってもよい。
例えば、支援ユーザが、申請ユーザのバトルの結果に基づく申請ユーザの申請に応じてバトルを行った場合、支援ユーザのバトル中に、申請ユーザに関する情報が支援ユーザに提供される。この場合、支援ユーザは、申請ユーザと協力して対戦していることをより実感できるだけでなく、申請ユーザからの申請に応えようという使命感を得ながらバトルを行うことができる。このため、支援ユーザにとっては、対戦相手から勝利を得た場合に得られる達成感を高めることができる。

情報提供手段５４の機能は、例えば以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、ステップＳ７のウェブページにおいてメニューｍ１２（「攻撃する」）の選択操作を認識すると、支援ユーザに対応する申請ユーザの戦士カードの画像を申請リストから取得して、ステップＳ８のウェブページに含めるようにＨＴＭＬデータを生成して、支援ユーザの通信端末１０宛に送信する。なお、ステップＳ８のウェブページは、戦士カードの画像ＳＣがゲーム画面を瞬時に横切るように表示されるように構成されているが、戦士カードの画像ＳＣがゲーム画面上に常に表示されるようにウェブページが構成されてもよい。
なお、本実施形態では、申請ユーザの戦士カードの画像を、申請ユーザに関する情報として提供する場合について説明したが、申請ユーザに関する情報は、例えば、申請ユーザのユーザ名であってもよいし、申請ユーザの表示画像などであってもよい。
また、バトルにおいて勝利条件を満たさなかったユーザに関する情報がゲームデータベース３２内の所定の記憶領域に記憶されている場合には、ＣＰＵ２１は、当該情報を当該記憶領域から取得して提供するようにしてもよい。

調整手段５５は、バトルにおいて勝利条件を満たさなかったユーザ（第１のユーザ）に関する情報が提供された場合に、支援ユーザによるバトル（第２の対戦）において支援ユーザ（第２のユーザ）が有利になるようにゲーム上の設定を調整する機能を備える。
調整手段５５の機能は、以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、ステップＳ７のウェブページにおいてメニューｍ１２（「攻撃する」）の選択操作を認識すると、支援ユーザによるバトル（第２の対戦）において、支援ユーザが使用する戦士カードの攻撃力を増加させる、あるいはバトル相手のモンスターキャラクタの攻撃力を低下させる処理を行うことにより、支援ユーザが有利になるようにゲーム上の設定を調整する。なお、戦士カードの攻撃力の増加、あるいはモンスターキャラクタの攻撃力の低下は、所定比率の増加あるいは低下でもよいし、所定量の増加あるいは低下でもよい。また、例えば、バトル相手のモンスターキャラクタのＨＰを所定比率、あるいは所定量低下させることにより、支援ユーザが有利になるようにゲーム上の設定を調整してもよい。
さらに、申請ユーザに関する情報に基づいて、支援ユーザが有利になるように調整されてもよい。例えば、支援ユーザがバトルで使用する戦士カードの攻撃力に、申請ユーザの保有する戦士カードの攻撃力が加わった状態でバトルが行われるようにしてもよい。この場合に用いられる申請ユーザの戦士カードは、申請ユーザがバトルで使用した戦士カードであってもよいし、ステップＳ８のウェブページで表示される戦士カードであってもよい。

（７）本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲーム制御装置により行われる主要な処理のシーケンスの一例について、図１７のシーケンスチャートを参照して説明する。図１７は、本実施形態のゲーム制御装置によって行われる、本実施形態のゲームのバトル処理を示している。なお、図１７には、図１３〜図１５に記載された各ウェブページが表示されるタイミングを符号により示している。
また、図１７では、ユーザ：ＡＢＣが第１のユーザの例であり、ユーザ：ＸＹＺが第２のユーザの例である。

先ず、ゲームを実行中のユーザ：ＡＢＣ（第１のユーザ）が、例えばモンスターキャラクタＭＣとのバトルに敗北すると、例えば図１２のステップＳ５のウェブページが表示される。ここで、メニューｍ１３（「支援要請する」）が選択操作され、支援要請を含むＨＴＴＰリクエストを受信すると（ステップＳ１００）、ゲームサーバ２０のＣＰＵ２１は、ゲームデータベース３２内の申請リストに所要のデータを書き込む（ステップＳ１０２）。書き込まれるデータは、図８に示したように、例えば、申請ユーザ（ここでは、ユーザ：ＡＢＣ）のユーザＩＤ、戦士カードの画像、バトル相手（バトルでユーザが敗北したときのモンスターキャラクタ）、バトル相手の残りＨＰ等である。ユーザ：ＡＢＣの支援要請が申請リストに書き込まれた後、ＣＰＵ２１は、ゲームのトップページに対するＨＴＴＰリクエスト、あるいはメニューｍ１の選択操作に基づくＨＴＴＰリクエストを送信するユーザを認識する度に（ステップＳ１０４）、そのユーザがユーザ：ＡＢＣよりも勝利数が多いか否かを判定し、多い場合には、そのユーザに対してユーザ：ＡＢＣの支援要請を送信してもよい（ステップＳ１０６）。つまり、申請ユーザよりも勝利数が多いユーザを対象として支援要請が行われてもよい。ここでは、ユーザ：ＸＹＺの通信端末１０宛にユーザ：ＡＢＣの支援要請が送信された場合を想定する。支援要請を受信したユーザＡＢＣの通信端末１０には、例えば図１３のステップＳ６のウェブページが表示される。

ステップＳ６のウェブページ上でメニューｍ１４（「参戦する」）が選択操作され、支援要請が受諾されたことを認識すると（ステップＳ１０８）、ＣＰＵ２１は、ユーザＡＢＣと、ユーザＫＮＭがバトルで敗北したモンスターキャラクタＭＣとの間のバトル画面用のＨＴＭＬデータを生成して送信する（ステップＳ１１０）。その結果、例えば図１３のステップＳ７のウェブページがユーザ：ＸＹＺの通信端末１０に表示される。このとき、ユーザ：ＸＹＺのバトルにおけるモンスターキャラクタＭＣのＨＰは、申請リストのユーザ：ＡＢＣのデータが読み出されて表示される。そして、ユーザＡＢＣの攻撃操作が行われると（ステップＳ１１２）、ＣＰＵ２１は、所定の条件を満たすか否かを判別する（ステップＳ１１４）。例えば、所定の条件は、支援ユーザ（ユーザ：ＸＹＺ）が申請ユーザ（ユーザ：ＡＢＣ）のバトルの結果に基づく申請ユーザの申請に応じて、支援ユーザがバトルを行うことである場合であってもよい。ここでは、所定の条件を満たす場合を想定すると（ステップＳ１１４：ＹＥＳ）、ＣＰＵ２１は、図１４のステップＳ８に示すウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＸＹＺの通信端末１０宛に送信する（ステップＳ１１６）。また、ＣＰＵ２１は、支援ユーザによるバトルにおいて、支援ユーザが使用する戦士カードの攻撃力を増加させる、あるいはバトル相手のモンスターキャラクタの攻撃力を低下させるなどの処理を行うことにより、支援ユーザが有利になるようにゲーム上の設定を調整する（ステップＳ１１８）。そして、ＣＰＵ２１は、バトル処理を行い（ステップＳ１２０）、図１４のステップＳ９に示すウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＸＹＺの通信端末１０宛に送信する（ステップＳ１２２）。なお、ステップＳ１１４〜Ｓ１２２の処理は、ステップＳ１１２の攻撃操作が行われるごとに繰り返し行われてもよい。ここで、ユーザ：ＸＹＺがモンスターキャラクタＭＣを撃破した場合には、ＣＰＵ２１からのＨＴＭＬデータの送信（ステップＳ１２４）に応じて、例えば図１５のステップＳ１０のウェブページがユーザ：ＸＹＺの通信端末１０に表示される。一方、ユーザ：ＸＹＺがモンスターキャラクタＭＣに敗北した場合には、ＣＰＵ２１からのＨＴＭＬデータの送信（ステップＳ１２４）に応じて、例えば図１５のステップＳ１１のウェブページがユーザ：ＸＹＺの通信端末１０に表示される。
ＣＰＵ２１は、ユーザＡＢＣとモンスターキャラクタＭＣ１のバトルの後、申請リスト及びユーザデータを更新する（ステップＳ１２）。例えば、ユーザ：ＸＹＺがモンスターキャラクタＭＣを撃破した場合、申請リストから、該当データ（ユーザ：ＡＢＣの対戦相手としてのモンスターキャラクタＭＣ）を削除するとともに、ユーザ：ＡＢＣとユーザ：ＸＹＺのユーザデータにアクセスして、それぞれ勝利数を１だけ増加させる。

上述したように、実施形態のゲーム制御装置によれば、支援ユーザは、所定の条件を満たす場合に、自らのバトル中に、バトルにおいて勝利条件を満たさなかったユーザに関する情報を得ることができる。また、バトルにおいて勝利条件を満たさなかったユーザに関する情報が提供されると、支援ユーザによるバトルにおいて支援ユーザが有利になるようにゲーム上の設定が調整される。このため、支援ユーザは、自らのバトルを行うまでに既に同じ対戦相手と対戦した（つまり、当該対戦相手から勝利を得るに至らなかった）他のユーザと協力してバトルを行っているという実感を得ることができる。

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

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

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

本変形例では、所定の条件は、支援ユーザ（第２のユーザ）が、バトルにおいて勝利条件を満たさなかったユーザ（第１のユーザ）と関係付けられていることであってもよい。
この場合、支援ユーザは、自らと関係付けられた仲間の申請ユーザに関する情報がバトル中に提供されることにより、仲間と協力して対戦を行っているという実感を得ることができる。このため、仲間との関係性を高めることができ、ひいてはゲームのソーシャル性を高めることができる。

本変形例における情報提供手段５４の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、図１７のシーケンスのステップＳ１１４において、申請ユーザが支援ユーザの仲間であるか否かを判別し、仲間である場合には、ステップＳ１１６及びステップＳ１１８の処理を行う。一方、申請ユーザが支援ユーザの仲間でない場合には、ＣＰＵ２１は、ステップＳ１２０の処理を行う。なお、申請ユーザが支援ユーザの仲間であるか否かは、申請ユーザのユーザデータを参照して判別すればよい。

（８−２）変形例２
上記実施形態において、所定の条件は、支援ユーザ（第２のユーザ）によるバトル（第２の対戦）が、バトルにおいて勝利条件を満たさなかったユーザ（第１のユーザ）によるバトル（第１の対戦）以降の所定期間内に行われることであってもよい。
例えば、支援ユーザが、申請ユーザによるバトル以降のほぼ同じ時期にバトルを行った場合、支援ユーザによるバトル中に、申請ユーザに関する情報が支援ユーザに提供される。このため、支援ユーザは、申請ユーザと協力して対戦していることをより実感できる。また、申請ユーザと支援ユーザが仲間として関係付けられている場合には、申請ユーザによるバトルが支援ユーザによるバトルとほぼ同時期に行われた（つまり、同一の対戦相手に対してほぼ同時期に対戦した）ことにより、申請ユーザに対して親近感を生じ得る。これにより、ユーザ間の交流を促進することができ、ひいてはユーザ間のさらなる密接な関係を構築することができる。

本変形例における情報提供手段５４の機能は、以下のようにして実現される。なお、ここでは、申請ユーザのユーザＩＤごとに、支援要請が行われたときのバトルの日時（対戦日時）が申請リストに記録されていることを想定する。なお、対戦日時は、例えば、メニューｍ１１が選択操作された時期であってもよいし、メニューｍ１２が選択操作された時期であってもよい。ここで、メニューｍ１２が選択操作された時期を対戦日時とする場合には、１回のバトルにおいてメニューｍ１２が複数回選択操作されたときの最新の選択操作時期に基づいて、申請ユーザに関する情報を提供するか否かを判別することが可能となる。ゲームサーバ２０のＣＰＵ２１は、図１７のシーケンスのステップＳ１１４において、支援ユーザによるバトルの日時（例えば、メニューｍ１４が選択操作された時期）が、対戦日時の所定期間内であるか否かを判別し、所定期間内である場合には、ステップＳ１１６及びステップＳ１１８の処理を行う。一方、支援ユーザによるバトルの実行開始時期が対戦日時の所定期間内でない場合には、ＣＰＵ２１は、ステップＳ１２０の処理を行う。
なお、変形例１における所定の条件と本変形例における所定の条件とを組合せてもよい。具体的には、所定の条件は、支援ユーザ（第２のユーザ）によるバトル（第２の対戦）が、バトルにおいて勝利条件を満たさなかったユーザ（第１のユーザ）によるバトル（第１の対戦）以降の所定期間内に行われ、且つ、当該ユーザ（第１のユーザ）と支援ユーザ（第２のユーザ）が関係付けられている（仲間である）ことであってもよい。

（８−３）変形例３
上記実施形態において、情報提供手段５４は、バトルにおいて勝利条件を満たさなかったユーザ（第１のユーザ）が複数存在する場合に、複数の第１のユーザのうち、第１のユーザによるバトル（第１の対戦）を行った時期が支援ユーザによるバトル（第２の対戦）の時期から近い順に所定数のユーザに関する情報を、支援ユーザに提供してもよい。
この場合、支援ユーザは、自らのバトルの時期と近い時期にバトルを行った所定数の第１のユーザに関する情報を、自らのバトル中に得ることができる。このため、支援ユーザは、第１のユーザによるバトルが自らのバトルとほぼ同時期に行われた（つまり、同一の対戦相手に対してほぼ同時期に対戦した）ことにより、第１のユーザと協力して対戦していることをより実感できる。支援ユーザは所定数の第１のユーザに対して親近感を生じ得るため、第１のユーザと支援ユーザが仲間として関係付けられている場合には、支援ユーザと所定数の第１のユーザとの交流を促進することができ、ゲームのソーシャル性をさらに高めることができる。

本変形例における情報提供手段５４の機能は、以下のようにして実現される。なお、ここでは、申請ユーザのユーザＩＤごとに、当該ユーザＩＤに対応する複数の支援ユーザのＩＤが申請リストに記録されていることを想定する。また、申請ユーザのユーザＩＤ及び支援ユーザごとに、バトルの日時（例えば、メニューｍ１４又はメニューｍ１４が選択操作された時期）が申請リストに記録されていることを想定する。また、申請リストには、複数の支援ユーザのユーザＩＤごとに、各支援ユーザが予め指定した戦士カードの画像が記録されていることを想定する。ゲームサーバ２０のＣＰＵ２１は、ステップＳ１１６の処理において、同じ支援要請に対応する申請ユーザ及び複数の支援ユーザのうち、バトルの日時が、バトルを実行中の支援ユーザのバトルの日時から近い順に所定数（例えば２人）のユーザを抽出する。そして、ＣＰＵ２１は、抽出したユーザのユーザＩＤに対応する戦士カードの画像を含むように、ステップＳ８のウェブページを表示するためのＨＴＭＬデータを生成して、バトルを実行中の支援ユーザの通信端末１０宛に送信する。

（８−４）変形例４
上記実施形態において、情報提供手段５４は、バトルにおいて勝利条件を満たさなかったユーザ（第１のユーザ）が複数存在する場合に、複数の第１のユーザのうち、支援ユーザ（第２のユーザ）との関係度合いを示す親密度が高い順に所定数のユーザに関する情報を、支援ユーザに提供してもよい。
この場合、支援ユーザは、複数の第１のユーザのうち、支援ユーザと関係付けられたユーザ（仲間）であって、支援ユーザとの親密度の高い所定数の仲間に関する情報を、自らのバトル中に得ることができる。このため、支援ユーザは、親密度の高い仲間と協力してバトルを行っているという実感を得ることができるので、親密度の高い仲間との関係度をさらに高めるように動機付けることができる。これにより、ユーザ間の密接な関係を構築することができる。
ここで、親密度とは、仲間のユーザ間の関係性の高さを一定の基準で数値化したものである。親密度のデータ（親密度データ）の一例を図２０に示す。図２０に示す親密度データの例では、各ユーザの仲間のユーザ（ユーザＩＤ）と対応付けて、ユーザ間の応援メッセージの送信あるいは受信の頻度（応援頻度）、ゲーム上で使用可能なアイテムなどのプレゼントを送信あるいは受信した回数（プレゼント回数）などが記録され、これらの頻度や回数に基づいて一定の基準で親密度の値が設定される。応援頻度やプレゼント回数が多いほど親密度が高く設定される。また、一定の基準では、親密度の設定の基礎となる項目（図２０では、応援頻度やプレゼント回数など）ごとに、重み付けを考慮したものであってもよい。例えば、応援頻度が少なくてもプレゼント回数が多い場合に親密度を高く設定してもよい。このような親密度データは、例えば、ユーザデータベース３１内に記録される。

本変形例における情報提供手段５５の機能は、以下のようにして実現される。なお、ここでは、申請ユーザのユーザＩＤごとに、当該ユーザＩＤに対応する複数の支援ユーザのＩＤが申請リストに記録されていることを想定する。また、申請リストには、複数の支援ユーザのユーザＩＤごとに、各支援ユーザが予め指定した戦士カードの画像が記録されていることを想定する。ゲームサーバ２０のＣＰＵ２１は、ステップＳ１１６の処理において、同じ支援要請に対応する申請ユーザ及び複数の支援ユーザのうち、バトルを実行中の支援ユーザとの親密度の高い順に所定数（例えば２人）のユーザを抽出する。そして、ＣＰＵ２１は、抽出したユーザのユーザＩＤに対応する戦士カードの画像を含むように、ステップＳ８のウェブページを表示するためのＨＴＭＬデータを生成して、バトルを実行中の支援ユーザの通信端末１０宛に送信する。

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

上述した実施形態では、複数のカードを用いたバトルを行う場合を例として説明したが、これに限られない。カードでなく、例えば、ユーザのアバタ画像等の各種オブジェクトであってもよい。また、バトルにおけるカードやオブジェクトは複数でなくてもよく、単一のカードやオブジェクトで構わない。あるいは、カード等のオブジェクトを使用せずにバトル処理を行ってもよい。

上述した実施形態では、実行対象のゲームがカードを用いたバトルゲームである場合の例について説明したが、本発明のゲームはこれに限られず、任意のゲームに適用することができる。例えば、ロールプレイングゲーム、テーブルゲーム、パズルゲーム、スポーツゲーム、レースゲーム、シューティングゲーム、アクションゲーム、アドベンチャーゲーム、シミュレーションゲームなどの各種ジャンルのゲームにおいて、ユーザによる対戦が行われる場合には、当該ユーザの対戦相手と既に対戦し、且つ、当該対戦相手との対戦において勝利条件を満たしていない他のユーザに関する情報を当該ユーザに提供することによって、当該ユーザが対戦において有利になるようにすることができ、本発明を好適に適用することができる。

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

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

上述した実施形態では、ネットワーク上のゲームサーバ２０及びデータベースサーバ３０によって、対戦実行手段５２、記憶手段５３、情報提供手段５４、及び調整手段５５の各機能を実現する構成としたが、この構成に限られない。これらのすべての手段を通信端末１０によって実現する構成としてもよいし、少なくとも一部の手段を通信端末１０によって実現する構成としてもよい。通信端末１０とゲームサーバ２０とでは実質的に同一のハードウエア構成を採ることができるため、上記実施形態に記載したようにして通信端末１０によっても各機能を実現できる。例えば、図２１（ａ），（ｂ）には、図１５に示した機能ブロック図の各機能について、通信端末１０と、ゲームサーバ２０及びデータベースサーバ３０との機能分担の例を示す。なお、上述した実施形態では、各種データ（例えば、モンスターキャラクタデータや申請データなど）をデータベースサーバ３０（ゲームデータベース３２）が記憶している構成としたが、通信端末１０内の記憶装置に記憶させてもよい。その場合には、記憶装置は、通信端末１０内のＲＡＭ１３や図示しないＨＤＤ(Hard Disk Drive)などの大容量記憶装置であってよい。

１０…通信端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１４…画像処理部
１５…指示入力部
１６…表示部
１７…通信インタフェース部
１８…バス
２０…ゲームサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…データベースアクセス部
２５…通信インタフェース部
２６…バス
３０…データベースサーバ
３１…ユーザデータベース
３２…ゲームデータベース
５１…登録手段
５２…対戦実行手段
５３…記憶手段
５４…情報提供手段
５５…調整手段

Claims (12)

1. ユーザのパラメータと、対戦相手のパラメータと、を記憶する記憶装置にアクセス可能なゲーム制御装置であって、
   ユーザによるゲーム上の対戦を、前記記憶装置に記憶された前記ユーザのパラメータと、前記対戦相手のパラメータとに基づいて実行する対戦実行手段と、
   第１のユーザと第１の対戦相手とによる対戦である第１の対戦において前記第１のユーザが勝利条件を満たしていない場合に、前記第１のユーザに関する情報を前記記憶装置に記憶する記憶手段と、
   前記勝利条件を満たしていない第１のユーザによる申請に応じて行われる対戦であって、且つ、第２のユーザと前記第１の対戦相手とによる対戦である第２の対戦中に、前記第１のユーザが前記第２の対戦に参戦したことを示す情報を前記第２のユーザに提供する情報提供手段と、
   前記第１のユーザが前記第２の対戦に参戦したことを示す情報が提供された場合に、前記第２の対戦において前記第２のユーザが有利になるように、前記第２のユーザのパラメータ、および、前記第１の対戦相手のパラメータの少なくとも１つを調整する調整手段と、
   を備えた、ゲーム制御装置。
2. ユーザのパラメータと、対戦相手のパラメータと、を記憶する記憶装置にアクセス可能なゲーム制御装置であって、
   ユーザによるゲーム上の対戦を、前記記憶装置に記憶された前記ユーザのパラメータと、前記対戦相手のパラメータとに基づいて実行する対戦実行手段と、
   複数の第１のユーザのそれぞれと第１の対戦相手とによる対戦である第１の対戦において前記複数の第１のユーザのいずれもが勝利条件を満たしていない場合に、各第１のユーザに関する情報を前記記憶装置に記憶する記憶手段と、
   所定の条件を満たす場合に、第２のユーザと前記第１の対戦相手とによる対戦である第２の対戦中に、前記複数の第１のユーザのうち、前記第１の対戦を行った時期が前記第２の対戦の時期から近い順に所定数の第１のユーザが前記第２の対戦に参戦したことを示す情報を前記第２のユーザに提供する情報提供手段と、
   前記所定数の第１のユーザが前記第２の対戦に参戦したことを示す情報が提供された場合に、前記第２の対戦において前記第２のユーザが有利になるように、前記第２のユーザのパラメータ、および、前記第１の対戦相手のパラメータの少なくとも１つを調整する調整手段と、
   を備えた、ゲーム制御装置。
3. ユーザのパラメータと、対戦相手のパラメータと、を記憶する記憶装置にアクセス可能なゲーム制御装置であって、
   ユーザ同士を関係付ける関係付け手段と、
   ユーザによるゲーム上の対戦を、前記記憶装置に記憶された前記ユーザのパラメータと、前記対戦相手のパラメータとに基づいて実行する対戦実行手段と、
   複数の第１のユーザのそれぞれと第１の対戦相手とによる対戦である第１の対戦において前記複数の第１のユーザのいずれもが勝利条件を満たしていない場合に、各第１のユーザに関する情報を前記記憶装置に記憶する記憶手段と、
   所定の条件を満たす場合に、第２のユーザと前記第１の対戦相手とによる対戦である第２の対戦中に、前記複数の第１のユーザのうち、前記第２のユーザと関係付けられ、且つ、前記第２のユーザとの関係度合いを示す親密度が高い順に所定数の第１のユーザが前記第２の対戦に参戦したことを示す情報を前記第２のユーザに提供する情報提供手段と、
   前記所定数の第１のユーザが前記第２の対戦に参戦したことを示す情報が提供された場合に、前記第２の対戦において前記第２のユーザが有利になるように、前記第２のユーザのパラメータ、および、前記第１の対戦相手のパラメータの少なくとも１つを調整する調整手段と、
   を備えた、ゲーム制御装置。
4. ユーザのパラメータと、対戦相手のパラメータと、を記憶する記憶装置にアクセス可能なコンピュータに、
   ユーザによるゲーム上の対戦を、前記記憶装置に記憶された前記ユーザのパラメータと、前記対戦相手のパラメータとに基づいて実行する機能、
   第１のユーザと第１の対戦相手とによる対戦である第１の対戦において前記第１のユーザが勝利条件を満たしていない場合に、前記第１のユーザに関する情報を前記記憶装置に記憶する機能、
   前記勝利条件を満たしていない第１のユーザによる申請に応じて行われる対戦であって、且つ、第２のユーザと前記第１の対戦相手とによる対戦である第２の対戦中に、前記第１のユーザが前記第２の対戦に参戦したことを示す情報を前記第２のユーザに提供する機能、及び
   前記第１のユーザが前記第２の対戦に参戦したことを示す情報が提供された場合に、前記第２の対戦において前記第２のユーザが有利になるように、前記第２のユーザのパラメータ、および、前記第１の対戦相手のパラメータの少なくとも１つを調整する機能、
   を実現させるためのプログラム。
5. ユーザのパラメータと、対戦相手のパラメータと、を記憶する記憶装置にアクセス可能なコンピュータに、
   ユーザによるゲーム上の対戦を、前記記憶装置に記憶された前記ユーザのパラメータと、前記対戦相手のパラメータとに基づいて実行する機能、
   複数の第１のユーザのそれぞれと第１の対戦相手とによる対戦である第１の対戦において前記複数の第１のユーザのいずれもが勝利条件を満たしていない場合に、各第１のユーザに関する情報を前記記憶装置に記憶する機能、
   所定の条件を満たす場合に、第２のユーザと前記第１の対戦相手とによる対戦である第２の対戦中に、前記複数の第１のユーザのうち、前記第１の対戦を行った時期が前記第２の対戦の時期から近い順に所定数の第１のユーザが前記第２の対戦に参戦したことを示す情報を前記第２のユーザに提供する機能、及び
   前記所定数の第１のユーザが前記第２の対戦に参戦したことを示す情報が提供された場合に、前記第２の対戦において前記第２のユーザが有利になるように、前記第２のユーザのパラメータ、および、前記第１の対戦相手のパラメータの少なくとも１つゲーム上の設定を調整する機能、
   を実現させるためのプログラム。
6. ユーザのパラメータと、対戦相手のパラメータと、を記憶する記憶装置にアクセス可能なコンピュータに、
   ユーザ同士を関係付ける機能、
   ユーザによるゲーム上の対戦を、前記記憶装置に記憶された前記ユーザのパラメータと、前記対戦相手のパラメータとに基づいて実行する機能、
   複数の第１のユーザのそれぞれと第１の対戦相手とによる対戦である第１の対戦において前記複数の第１のユーザのいずれもが勝利条件を満たしていない場合に、各第１のユーザに関する情報を前記記憶装置に記憶する機能、
   所定の条件を満たす場合に、第２のユーザと前記第１の対戦相手とによる対戦である第２の対戦中に、前記複数の第１のユーザのうち、前記第２のユーザと関係付けられ、且つ、前記第２のユーザとの関係度合いを示す親密度が高い順に所定数の第１のユーザが前記第２の対戦に参戦したことを示す情報を前記第２のユーザに提供する機能、及び
   前記所定数の第１のユーザが前記第２の対戦に参戦したことを示す情報が提供された場合に、前記第２の対戦において前記第２のユーザが有利になるように、前記第２のユーザのパラメータ、および、前記第１の対戦相手のパラメータの少なくとも１つを調整する機能、
   を実現させるためのプログラム。
7. 通信端末と、当該通信端末からアクセスされるサーバと、ユーザのパラメータおよび対戦相手のパラメータを記憶する記憶装置とを含むゲームシステムであって、
   ユーザによるゲーム上の対戦を、前記記憶装置に記憶された前記ユーザのパラメータと、前記対戦相手のパラメータとに基づいて実行する対戦実行手段、
   第１のユーザと第１の対戦相手とによる対戦である第１の対戦において前記第１のユーザが勝利条件を満たしていない場合に、前記第１のユーザに関する情報を前記記憶装置に記憶する記憶手段、
   前記勝利条件を満たしていない第１のユーザによる申請に応じて行われる対戦であって、且つ、第２のユーザと前記第１の対戦相手とによる対戦である第２の対戦中に、前記第１のユーザが前記第２の対戦に参戦したことを示す情報を前記第２のユーザに提供する情報提供手段、
   前記第１のユーザが前記第２の対戦に参戦したことを示す情報が提供された場合に、前記第２の対戦において前記第２のユーザが有利になるように、前記第２のユーザのパラメータ、および、前記第１の対戦相手のパラメータの少なくとも１つを調整する調整手段、
   の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
   ゲームシステム。
8. 通信端末と、当該通信端末からアクセスされるサーバと、ユーザのパラメータおよび対戦相手のパラメータを記憶する記憶装置とを含むゲームシステムであって、
   ユーザによるゲーム上の対戦を、前記記憶装置に記憶された前記ユーザのパラメータと、前記対戦相手のパラメータとに基づいて実行する対戦実行手段、
   複数の第１のユーザのそれぞれと第１の対戦相手とによる対戦である第１の対戦において前記複数の第１のユーザのいずれもが勝利条件を満たしていない場合に、各第１のユーザに関する情報を前記記憶装置に記憶する記憶手段、
   所定の条件を満たす場合に、第２のユーザと前記第１の対戦相手とによる対戦である第２の対戦中に、前記複数の第１のユーザのうち、前記第１の対戦を行った時期が前記第２の対戦の時期から近い順に所定数の第１のユーザが前記第２の対戦に参戦したことを示す情報を前記第２のユーザに提供する情報提供手段、
   前記所定数の第１のユーザが前記第２の対戦に参戦したことを示す情報が提供された場合に、前記第２の対戦において前記第２のユーザが有利になるように、前記第２のユーザのパラメータ、および、前記第１の対戦相手のパラメータの少なくとも１つを調整する調整手段、
   の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
   ゲームシステム。
9. 通信端末と、当該通信端末からアクセスされるサーバと、ユーザのパラメータおよび対戦相手のパラメータを記憶する記憶装置とを含むゲームシステムであって、
   ユーザ同士を関係付ける関係付け手段と、
   ユーザによるゲーム上の対戦を、前記記憶装置に記憶された前記ユーザのパラメータと、前記対戦相手のパラメータとに基づいて実行する対戦実行手段、
   複数の第１のユーザのそれぞれと第１の対戦相手とによる対戦である第１の対戦において前記複数の第１のユーザのいずれもが勝利条件を満たしていない場合に、各第１のユーザに関する情報を前記記憶装置に記憶する記憶手段、
   所定の条件を満たす場合に、第２のユーザと前記第１の対戦相手とによる対戦である第２の対戦中に、前記複数の第１のユーザのうち、前記第２のユーザと関係付けられ、且つ、前記第２のユーザとの関係度合いを示す親密度が高い順に所定数の第１のユーザが前記第２の対戦に参戦したことを示す情報を前記第２のユーザに提供する情報提供手段、
   前記所定数の第１のユーザが前記第２の対戦に参戦したことを示す情報が提供された場合に、前記第２の対戦において前記第２のユーザが有利になるように、前記第２のユーザのパラメータ、および、前記第１の対戦相手のパラメータの少なくとも１つを調整する調整手段、
   の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
   ゲームシステム。
10. ユーザのパラメータと、対戦相手のパラメータと、を記憶する記憶装置にアクセス可能なゲーム制御装置であって、
    ユーザによるゲーム上の対戦を、前記ユーザのパラメータと、前記対戦相手のパラメータとに基づいて実行する対戦実行手段と、
    第１のユーザと第１の対戦相手とによる対戦である第１の対戦において前記第１のユーザが勝利条件を満たしていない場合に、前記第１のユーザに関する情報を前記記憶装置に記憶する記憶手段と、
    前記勝利条件を満たしていない第１のユーザによる申請に応じて行われる対戦であって、且つ、第２のユーザと前記第１の対戦相手とによる対戦である第２の対戦中に、前記第１のユーザが前記第２の対戦に参戦したことを示す情報を前記第２のユーザに提供する情報提供手段と、
    前記第１のユーザが前記第２の対戦に参戦したことを示す情報が提供されて、前記第２のユーザの操作する端末の表示領域に前記第１のユーザが前記第２の対戦に参戦したことを示す情報が表示された後、前記第２の対戦において前記第２のユーザが有利になるように、前記第２のユーザのパラメータ、および、前記第１の対戦相手のパラメータの少なくとも１つを調整して得られた前記第２の対戦の結果に関する情報を前記第２のユーザに提供する調整手段と、
    を備えた、ゲーム制御装置。
11. ユーザのパラメータと、対戦相手のパラメータと、を記憶する記憶装置にアクセス可能なコンピュータに、
    ユーザによるゲーム上の対戦を、前記記憶装置に記憶された前記ユーザのパラメータと、前記対戦相手のパラメータとに基づいて実行する機能、
    第１のユーザと第１の対戦相手とによる対戦である第１の対戦において前記第１のユーザが勝利条件を満たしていない場合に、前記第１のユーザに関する情報を前記記憶装置に記憶する機能、
    前記勝利条件を満たしていない第１のユーザによる申請に応じて行われる対戦であって、且つ、第２のユーザと前記第１の対戦相手とによる対戦である第２の対戦中に、前記第１のユーザが前記第２の対戦に参戦したことを示す情報を前記第２のユーザに提供する機能、及び
    前記第１のユーザが前記第２の対戦に参戦したことを示す情報が提供されて、前記第２のユーザの操作する端末の表示領域に前記第１のユーザが前記第２の対戦に参戦したことを示す情報が表示された後、前記第２の対戦において前記第２のユーザが有利になるように、前記第２のユーザのパラメータ、および、前記第１の対戦相手のパラメータの少なくとも１つを調整して得られた前記第２の対戦の結果に関する情報を前記第２のユーザに提供する機能、
    を実現させるためのプログラム。
12. 通信端末と、当該通信端末からアクセスされるサーバと、ユーザのパラメータおよび対戦相手のパラメータを記憶する記憶装置とを含むゲームシステムであって、
    ユーザによるゲーム上の対戦を、前記記憶装置に記憶された前記ユーザのパラメータと、前記対戦相手のパラメータとに基づいて実行する対戦実行手段、
    第１のユーザと第１の対戦相手とによる対戦である第１の対戦において前記第１のユーザが勝利条件を満たしていない場合に、前記第１のユーザに関する情報を前記記憶装置に記憶する記憶手段、
    前記勝利条件を満たしていない第１のユーザによる申請に応じて行われる対戦であって、且つ、第２のユーザと前記第１の対戦相手とによる対戦である第２の対戦中に、前記第１のユーザが前記第２の対戦に参戦したことを示す情報を前記第２のユーザに提供する情報提供手段、
    前記第１のユーザが前記第２の対戦に参戦したことを示す情報が提供されて、前記第２のユーザの操作する端末の表示領域に前記第１のユーザが前記第２の対戦に参戦したことを示す情報が表示された後、前記第２の対戦において前記第２のユーザが有利になるように、前記第２のユーザのパラメータ、および、前記第１の対戦相手のパラメータの少なくとも１つを調整して得られた前記第２の対戦の結果に関する情報を前記第２のユーザに提供する調整手段、
    の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
    ゲームシステム。
    

Images