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

Description

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

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

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

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

従来のソーシャルゲームでは、ユーザ間の対戦プレイを促進するために、対戦の勝者に報酬としてアイテムやポイントを付与すること、付与されたポイントによるランキングに基づきアイテムを付与することが行われるが、ユーザ間の対戦は非同期で行われていた。例えば、上述したデジタルカードゲームでは、各ユーザは、手持ちの複数のカードの中から攻撃用のチームに含まれるカード群と、防御用のチームに含まれるカード群とを設定する（俗に「デッキを組む」ともいう。）。このとき、ゲームにアクセス中のユーザは、攻撃用のチームに含まれるカード群を用いて他のユーザに対して対戦を仕掛ける。攻撃を仕掛けられた他のユーザ（対戦相手）は、予め設定された防御用のグループに含まれるカード群によってバトル（対戦）に応戦することになるが、そのバトルに対して影響を与えうる何らかの操作ができない仕組みとなっている。バトルを仕掛けた、ゲームにアクセス中のユーザは、バトルの結果を直ちに知ることができるが、その対戦相手は、バトルの終了後にゲームにアクセスした段階でバトルの勝敗を知ることになる。
しかし、上述した非同期の対戦において対戦の勝者に報酬を付与する場合、アクセス中のユーザは報酬を得るために自分よりも弱い他のユーザを選択して対戦プレイを行う傾向がある。この結果、弱いユーザが自分よりも強い他のユーザから集中的に対戦相手として選択され、連敗してしまうことがある。特に初心者ユーザでは、ゲームを開始して間もない時期に連敗することによりゲームを継続するモチベーションが低下し、ゲームの面白さを知る前にゲームをやめてしまうおそれがある。

本発明は上述した観点に鑑みてなされたもので、対戦プレイにおいて弱いユーザがゲームを継続するモチベーションを維持することができる、ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、オンラインシステムを提供することを目的とする。

本発明の第１の観点は、ゲーム制御装置である。
このゲーム制御装置は、
第１ユーザと前記第１ユーザにより選択された第２ユーザとの対戦処理を実行する対戦処理手段（５２）、
前記第１ユーザが勝利した場合に、前記第２ユーザの対戦履歴に基づいて変動する報酬を前記第１ユーザに付与する報酬付与手段（５５）、
前記第１ユーザにより前記第２ユーザとして選択されるユーザのリストを、前記ユーザの対戦履歴に基づく情報又は前記第１ユーザに付与される報酬に関する情報とともに前記第１ユーザに対戦処理前に提示する第１提示手段（５６）、
の各手段を備える。

本発明に係るゲーム制御装置は、ユーザの通信端末上でゲームを表示するために当該通信端末との間で無線又は有線による通信を確立できるサーバ等の情報処理装置であってもよい。
本発明において「報酬」とは、ゲーム上のオブジェクトやポイント等を含む。「オブジェクト」とは、例えば、ゲーム上のキャラクタやアイテム等を含む。キャラクタは、例えばゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカードに表示されているものをも含む。
本発明において、「対戦履歴」とは、例えば、過去の対戦処理におけるユーザの勝利回数、敗北回数、勝率、敗率、連勝回数、連敗回数等である。
本発明において、「対戦履歴に基づく情報」とは、例えば、対戦履歴を明示する情報（例えば、「連敗回数：３回」等のテキスト）であってもよいし、対戦履歴を暗示する情報（例えば、連敗回数が２回であれば星１つの画像情報等）であってもよい。
本発明において、「報酬に関する情報」とは、例えば、報酬を明示する情報（例えば、「１０００ポイント」等のテキスト）であってもよいし、報酬を暗示する情報（例えば、１０００ポイントであれば星１つの画像情報等）であってもよい。
このゲーム制御装置によれば、対戦に勝利したユーザに付与する報酬を、対戦相手の対戦履歴に基づいて、弱いユーザを対戦相手として選択しないように変動させるとともに、ユーザの対戦履歴に基づく情報又は報酬に関する情報を提示することで、ユーザに自分よりも弱いユーザを対戦相手として選択しないように促すことができる。このため、弱いユーザがゲームを継続するモチベーションを維持することができる。

上記ゲーム制御装置において、前記報酬付与手段（５５）は、前記対戦処理において前記第２ユーザが敗北した場合に更新される履歴情報を用いて前記報酬を変動させてもよい。
ここで、「ユーザが敗北した場合に更新される履歴情報」とは、例えば、ユーザが敗北した場合に増加又は減少するパラメータである。ユーザが敗北した場合に増加するパラメータは、例えば、敗北回数、敗率、連敗回数等である。ユーザが敗北した場合に減少するパラメータは、例えば、勝率、連勝回数（敗北することで０となる）等である。
このゲーム制御装置によれば、ユーザが敗北した場合に更新される履歴情報を用いて、敗北回数が多いユーザ、敗率が高いユーザ、連敗回数が多いユーザを避けるように報酬を変動させることができる。

上記ゲーム制御装置において、前記報酬付与手段（５５）は、前記第２ユーザが前記対戦処理直前の対戦処理で敗北している場合、前記第１ユーザに付与される報酬を減少させてもよい。
このゲーム制御装置によれば、第２ユーザが直前の対戦処理で敗北している場合に、第１ユーザが勝利時に得られる報酬を減少させることで、直前に敗北した第２ユーザが第１ユーザによって対戦相手として狙われるのを避けることができる。

上記ゲーム制御装置において、前記報酬付与手段（５５）は、前記第２ユーザが前記対戦処理前の所定期間又は所定回数の対戦処理において連続して敗北している場合、連続敗北回数に応じて前記第１ユーザに付与される報酬を減少させてもよい。
なお、対戦処理前の所定期間又は所定回数よりもさらに前の連続敗北回数によっては報酬を減少させなくてもよい。
このゲーム制御装置によれば、連敗している第２ユーザに勝利した場合に、連続敗北回数に応じて得られる報酬が少なくなるので、連敗している第２ユーザが第１ユーザによって対戦相手として狙われるのを避けることができる。

上記ゲーム制御装置において、前記報酬付与手段（５５）は、前記対戦処理前の所定期間又は所定回数の対戦処理における前記第２ユーザの勝率が低いほど前記第１ユーザに付与される報酬を減少させてもよい。
このゲーム制御装置によれば、第２ユーザに勝利した場合に得られる報酬が、第２ユーザの勝率が低いほど少なくなるので、勝率が低い第２ユーザが第１ユーザによって対戦相手として狙われるのを避けることができる。

上記ゲーム制御装置において、前記報酬付与手段（５５）は、前記第２ユーザの対戦履歴と前記第１ユーザの対戦履歴を比較して、前記第１ユーザに付与される報酬を変動させてもよい。
このゲーム制御装置によれば、対戦するユーザ同士の対戦履歴を比較して、弱いユーザに勝利したときに得られる報酬を減らすことができるため、第１ユーザよりも相対的に弱いユーザが第１ユーザによって対戦相手として狙われるのを避けることができる。

上記ゲーム制御装置において、
ユーザと他のユーザを関連付ける関連付け手段（５７）、
前記第２ユーザが前記第２ユーザに関連付けられた第３ユーザに対して前記第１ユーザとの対戦処理への参加を要請する要請手段（５８）、
前記第２ユーザの対戦相手のリストを、前記第２ユーザの対戦履歴に基づく情報又は前記第３ユーザに付与される報酬に関する情報とともに前記第３ユーザに対戦処理前に提示する第２提示手段（５９）、
を備え、
前記報酬付与手段（５５）は、前記第３ユーザが勝利した場合に、前記第２ユーザの対戦履歴に基づいて変動する報酬を前記第３ユーザに付与してもよい。
このゲーム制御装置によれば、対戦処理において第３ユーザが勝利した場合に、第２ユーザの対戦履歴に基づいて変動する報酬を第３ユーザに付与することで、第２ユーザが弱いほど第３ユーザが第２ユーザによって要請された対戦処理への参加を動機付けられる。このため、第２ユーザが弱いほど第３ユーザの対戦における協力を得られやすくなる。また、第１ユーザが第３ユーザからの攻撃を避けるために自分よりも弱いユーザを対戦相手として選択しないように促すことができる。このため、弱い第１ユーザがゲームを継続するモチベーションを維持することができる。

上記ゲーム制御装置において、前記報酬付与手段（５５）は、前記要請手段（５８）により参加要請の対象となっている対戦処理の直前の対戦処理で前記第２ユーザが敗北している場合、前記第３ユーザに付与される報酬を増加させてもよい。
このゲーム制御装置によれば、第１ユーザが直前の対戦処理で敗北している場合に、第３ユーザが勝利時に得られる報酬を増加させることで、第２ユーザが敗北した後に要請された対戦処理への参加を第３ユーザに動機付けることができる。

上記ゲーム制御装置において、前記報酬付与手段（５５）は、前記第２ユーザが前記対戦処理前の所定期間又は所定回数の対戦処理において連続して敗北している場合、連続敗北回数に応じて前記第３ユーザに付与される報酬を増加させてもよい。
このゲーム制御装置によれば、連敗している第２ユーザに要請された対戦処理に参加して勝利した場合に、第２ユーザの連続敗北回数に応じて得られる報酬が増えるので、第２ユーザが連敗した後に要請された対戦処理への参加を第３ユーザに動機付けることができる。

上記ゲーム制御装置において、前記報酬付与手段（５５）は、前記対戦処理前の所定期間又は所定回数の対戦処理における前記第２ユーザの勝率が低いほど前記第３ユーザに付与される報酬を増加させてもよい。
このゲーム制御装置によれば、第２ユーザに勝利した場合に第３ユーザが得られる報酬が、第２ユーザの勝率が低いほど少なくなるので、勝率が低い第２ユーザに要請された対戦処理への参加を第３ユーザに動機付けることができる。

上記ゲーム制御装置において、前記報酬付与手段（５５）は、前記第１ユーザの対戦履歴と前記第２ユーザの対戦履歴を比較して、前記第３ユーザに付与される報酬を変動させてもよい。
このゲーム制御装置によれば、ユーザ同士の対戦履歴を比較して、例えば第１ユーザよりも相対的に弱い第２ユーザから参加を要請された対戦処理において勝利したときに与えられる第３ユーザへの報酬を増やすことで、第２ユーザが相対的に弱いユーザであるほど対戦処理への参加を第３ユーザに動機付けることができる。

上記ゲーム制御装置において、前記対戦処理において減少し、対戦処理能力が制限される対戦処理用パラメータを前記第１ユーザ及び前記第２ユーザに対応付ける対応付け手段（６０）を備え、
前記報酬付与手段（５５）は、前記第２ユーザに対応付けられた前記対戦処理用パラメータに基づいて前記第１ユーザに付与される報酬を変動させてもよい。
このゲーム制御装置によれば、対戦処理用パラメータが減少して対戦処理能力が制限されるユーザに勝利したときに得られる報酬を減らし、特定のユーザが連続して対戦相手として選択されることを回避することができる。

本発明の第２の観点は、ゲーム制御装置である。
このゲーム制御装置は、
第１ユーザと前記第１ユーザにより選択された第２ユーザとの対戦処理を実行する対戦処理手段（５２）、
前記対戦処理において減少し、対戦処理能力が制限される対戦処理用パラメータを前記第１ユーザ及び前記第２ユーザに対応付ける対応付け手段（６０）、
前記第１ユーザが勝利した場合に、前記第２ユーザの対戦処理用パラメータに基づいて変動する報酬を前記第１ユーザに付与する報酬付与手段（５５）、
前記第１ユーザにより前記第２ユーザとして選択されるユーザのリストを、前記ユーザの対戦処理用パラメータに関する情報又は前記第１ユーザに付与される報酬に関する情報とともに前記第１ユーザに対戦処理前に提示する第１提示手段（５６）、
の各手段を備える。

本発明の第３の観点は、ゲーム制御装置である。
このゲーム制御装置は、
第１ユーザと前記第１ユーザにより選択された第２ユーザとの対戦処理を実行する対戦処理手段（５２）、
前記対戦処理の結果を記憶装置に記憶させる記憶手段（５３）、
前記記憶装置から前記第２ユーザの敗北履歴を取得し、前記第２ユーザの敗北履歴に基づく報酬を決定する決定手段（５４）、
前記第１ユーザが勝利した場合に、前記決定手段（５４）により決定された報酬を前記第１ユーザに付与する報酬付与手段（５５）、
前記第１ユーザにより前記第２ユーザとして選択されるユーザのリストを、前記ユーザの敗北履歴に基づく情報又は前記第１ユーザに付与される報酬に関する情報とともに前記第１ユーザに対戦処理前に提示する第１提示手段（５６）、
の各手段を備える。
なお、「敗北履歴」には、例えば、敗北回数、敗率、連敗回数等が含まれる。

本発明の第４の観点は、ゲーム制御方法である。
このゲーム制御方法は、
第１ユーザと前記第１ユーザにより選択された第２ユーザとの対戦処理を実行するステップ、
前記第１ユーザが勝利した場合に、前記第２ユーザの対戦履歴に基づいて変動する報酬を前記第１ユーザに付与するステップ、
前記第１ユーザにより前記第２ユーザとして選択されるユーザのリストを、前記ユーザの対戦履歴に基づく情報又は前記第１ユーザに付与される報酬に関する情報とともに前記第１ユーザに対戦処理前に提示するステップ、
を含む。

本発明の第５の観点は、コンピュータに、
第１ユーザと前記第１ユーザにより選択された第２ユーザとの対戦処理を実行する機能、
前記第１ユーザが勝利した場合に、前記第２ユーザの対戦履歴に基づいて変動する報酬を前記第１ユーザに付与する機能、
前記第１ユーザにより前記第２ユーザとして選択されるユーザのリストを、前記ユーザの対戦履歴に基づく情報又は前記第１ユーザに付与される報酬に関する情報とともに前記第１ユーザに対戦処理前に提示する機能、
を実現するためのプログラムである。

コンピュータは、例えばネットワークサーバ、大型計算機等であってよい。また、このプログラムは、光ディスク（ＤＶＤ−ＲＯＭ、ＣＤ−ＲＯＭ等）、フレキシブルディスク、半導体メモリ等のコンピュータ読み取り可能な情報記憶媒体に格納されてもよい。

本発明の第６の観点は、複数のユーザの通信端末（１０）と、当該通信端末（１０）からアクセスされるサーバ（２０）とを含む、ゲームシステムである。
このゲームシステムは、
第１ユーザと前記第１ユーザにより選択された第２ユーザとの対戦処理を実行する対戦処理手段（５２）、
前記第１ユーザが勝利した場合に、前記第２ユーザの対戦履歴に基づいて変動する報酬を前記第１ユーザに付与する報酬付与手段（５５）、
前記第１ユーザにより前記第２ユーザとして選択されるユーザのリストを、前記ユーザの対戦履歴に基づく情報又は前記第１ユーザに付与される報酬に関する情報とともに前記第１ユーザに対戦処理前に提示する第１提示手段（５６）、
の各手段を、前記通信端末（１０）または前記サーバ（２０）のいずれか一方が備える。

なお、上記では、本発明の理解を容易にするため、適宜図面に記載された符号を括弧書きで記載しているが、これにより本発明に係るゲーム制御装置等が図示の態様に限定されるものではない。

本発明のゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムによれば、対戦プレイにおいて弱いユーザがゲームを継続するモチベーションを維持することができる。

実施形態のゲームシステムの基本構成を示す図。 通信端末の外観の例を示す図。 通信端末の外観の例を示す図。 通信端末の構成を示すブロック図。 ゲームサーバの構成を示すブロック図。 データベースサーバの構成を示すブロック図。 ユーザデータベースの構成例を示す図。 対戦履歴データベースの構成例を示す図。 カードデータベースの構成例を示す図。 ユーザの通信端末に表示される一連のウェブページを例示する図。 ユーザの通信端末に表示される一連のウェブページを例示する図。 実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 実施形態のゲーム制御装置の主要な処理の一例を示すフローチャート。 実施形態のゲーム制御装置の主要な処理の一例を示すフローチャート。 参加要請データベースの構成例を示す図。 ユーザの通信端末に表示される一連のウェブページを例示する図。 ユーザの通信端末に表示される一連のウェブページを例示する図。 変形例１のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 変形例１のゲーム制御装置の主要な処理の一例を示すフローチャート。 ユーザの通信端末に表示されるウェブページを例示する図。 変形例２のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 ゲーム制御装置の各機能について、通信端末と、ゲームサーバ及びデータベースサーバとの間の分担例を示す図。 ゲーム制御装置の各機能について、通信端末と、ゲームサーバ及びデータベースサーバとの間の分担例を示す図。

以下、本発明のゲームシステムの一実施形態について説明する。

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

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

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

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

ウェブブラウザは、ゲームサーバ２０とＨＴＴＰ(HyperText Transfer Protocol)に従った通信を行う。ウェブブラウザは、ゲームサーバ２０から取得したＨＴＭＬデータを解釈して、画像処理部１４を介してウェブページを表示部１６に表示する。また、ウェブブラウザは、ユーザが指示入力部１５の操作によってウェブページ上のハイパーリンク(Hyperlink)またはメニューが選択されると、ウェブページの更新のために、その選択結果に応じたＨＴＴＰリクエストをゲームサーバ２０に送信する。

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

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

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

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

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

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

例えば、ＣＰＵ２１は、通信インタフェース部２５を介して、ゲームサーバ２０のウェブブラウザとの間でＨＴＴＰに従った通信を行う。例えば、ＣＰＵ２１は、通信インタフェース部２５を介して、通信端末１０から受信したＨＴＴＰリクエスト（例えば、ウェブページ上でのユーザのハイパーリンクまたはメニューの選択結果を含む。）に基づいて所定のデータ処理や、演算処理を行い、その処理結果を含むＨＴＴＰレスポンスをゲームサーバ２０のウェブブラウザに返す。ＨＴＴＰレスポンスには、ウェブページを更新するためのＨＴＭＬデータが含まれる。また、ゲームサーバ２０が通信端末１０のユーザの認証処理を行う場合には、ＣＰＵ２１はその認証処理を行う。
データベースアクセス部２４は、ＣＰＵ２１がデータベースサーバ３０に対してデータの読み書きを行うときのインタフェースである。

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

本実施形態のゲームのタイプは特に限定されるものではないが、以下では、実施形態のゲームの一例として、モンスターカード（以下適宜、単に「カード」という。）を用いたデジタルカードゲーム（以下適宜、単に「ゲーム」あるいは「本実施形態のゲーム」という。）を採り上げる。このゲームは、ユーザが、モンスターが描かれたデジタルカード（モンスターカード）を入手することによって自らのチーム（カードデッキ）を作り上げ、コンピュータ又は他のユーザのチームとバトルを行うように構成されている。なお、カードデッキは、一般的に複数のカードによって構成されている。
このゲームは、例えば、以下の処理を含む。
・クエスト処理：
少なくとも一枚のカードからなる自らのチームを作り上げていくために、ゲーム上で設定されているエリアを探索してカードを得る処理である。このゲームでは、クエスト処理を実行することで一定量の体力ポイント（後述する）を消費し、一定量の強化ポイント（後述する）を獲得する。
・対戦処理：
ユーザのチームと、コンピュータ又は他のユーザのチームとの間で対戦を行う処理である。ここで、コンピュータのチームとは、例えばＣＰＵ２１によって任意に抽出された複数のカードからなるチームである。対戦処理では、ユーザの入力に基づき、ユーザのチームとコンピュータのチームとの間で対戦を行うイベント（以下、ＣＯＭ対戦という。）、あるいはユーザのチームと他のユーザのチームとの間で対戦を行うイベント（以下、ユーザ間対戦という。）のいずれかが発生するようになっている。対戦処理において勝利したユーザは対戦相手に応じた強化ポイントを獲得し、敗北したユーザは自身の保有する強化ポイントの一部を失う。
なお、ここでは詳しく述べないが、本実施形態のゲームは、ユーザがゲーム上保有するカードから、対戦処理に用いられるチームを構成するカードを選択して登録する（チームを編成する）編成処理を含んでいる。

また、ここでは詳しく述べないが、本実施形態のゲームは、例えば、ユーザがゲーム上保有するカードを強化するための強化処理等を含んでもよい。

図６Ａ、図６Ｂに、本実施形態のゲームにおいて適用されるユーザデータベース３１の一例を示す。図６Ａに示すように、ユーザデータベース３１は、ユーザＩＤ（ユーザ識別情報）ごとに、ユーザ名／表示画像、進行レベル、体力ポイント、強化ポイント、抽選ポイント、仲間のユーザＩＤ、保有カード、アイテムの識別コード、攻撃Ｐ（攻撃ポイント）現在値／最大値、防御Ｐ（防御ポイント）現在値／最大値、の各項目についての情報を含む。

以下の説明では、ユーザデータベース３１に含まれるユーザＩＤごとのデータを総称してユーザデータという。ユーザデータを構成するデータのうち、図６Ａの各項目のデータは、以下のとおりである。
・ユーザ名／表示画像
ゲームの実行時に通信端末１０のユーザを特定するために表示されるユーザ名及び表示画像である。ユーザ名はユーザによって予め指定される所定長以下のテキストであり、表示画像は例えばユーザによって予め選択されるアバタ画像である。ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
・進行レベル
ゲーム上のユーザの進行レベルを示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値であり、例えば、クエスト処理が継続的に実行されることで、順次進行レベルが上がるように構成される。
・体力ポイント
体力ポイントは、ユーザがクエスト処理を行う際に消費するコストを示すパラメータであり、ユーザがクエスト処理を行うことで、体力ポイントは減少する。ユーザ毎に体力ポイントの上限値を定めてもよく、体力ポイントの上限値は、進行レベルが増加するにつれて増加するように設定されていてもよい。体力ポイントは、時間の経過によって上限値まで増加（回復）するように設定してもよい。
・強化ポイント
ユーザが、クエスト処理や対戦処理においてシステム又は他のユーザより取得したポイントである。このゲームでは、ユーザがカードを強化する強化処理を行う際に所定量の強化ポイントが消費される。
・抽選ポイント
抽選ポイントは、ユーザが抽選処理を行う際に消費するコストを示すパラメータであり、ユーザが抽選処理を行うことで、抽選ポイントは減少する。このゲームでは、他のユーザとの間で例えばメッセージの送受信等の交流を行うことで、ユーザが抽選ポイントを獲得する。なお、抽選ポイントは、時間の経過によって増加するように設定してもよい。
・仲間のユーザＩＤ
例えば仲間になるための申請などを契機として、ユーザと関連付けられた他のユーザ（仲間）のユーザＩＤのリストである。
・保有カード、アイテムの識別コード
ユーザがゲーム上保有するカードやアイテム（体力ポイントを回復させる回復アイテム等）の識別コードである。識別コードに対応するカード等のデータの内容については後述する。
・攻撃Ｐ（攻撃ポイント）現在値／最大値
対戦処理において、ユーザが攻撃側となった場合に使用可能なカードのコストである。攻撃ポイントは、ユーザが攻撃側となった場合に、使用したカードのコストに応じて減少し、時間の経過に応じて（例えば、２分ごとに1ポイント）最大値まで回復する。なお、図６Ａでは、○／○の形式で、現在値／最大値が記載されている。
・防御Ｐ（防御ポイント）現在値／最大値
対戦処理において、ユーザが防御側となった場合に使用可能なカードのコストである。防御ポイントは、ユーザが防御側となった場合に、一定の割合（例えば、２０％）減少し、時間の経過に応じて（例えば、２分ごとに1ポイント）最大値まで回復する。なお、図６Ａでは、○／○の形式で、現在値／最大値が記載されている。
なお、攻撃ポイント及び防御ポイントの最大値は、ユーザの進行レベルに応じて増加するように設定してもよい。また、攻撃側となった場合と防御側となった場合とで使用可能なカードのコストを示すパラメータを分けずに、同一のパラメータを用いてもよい。

また、ユーザデータベース３１は、図６Ｂに例示する対戦履歴データベースを含む。対戦履歴データベースは、ユーザＩＤごとに、後述する対戦処理における対戦履歴に基づく情報を含む。本実施形態では、対戦履歴に基づく情報は、勝利回数、敗北回数、連勝回数、連敗回数、等を含む。各項目のデータは、以下のとおりである。
・勝利回数
対戦処理におけるユーザの勝利回数である。
・敗北回数
対戦処理におけるユーザの敗北回数である。
・連勝回数
対戦処理におけるユーザの連続勝利回数である。なお、連勝回数は、ユーザが対戦処理において敗北することで０に戻る。
・連敗回数
対戦処理におけるユーザの連続敗北回数である。なお、連敗回数は、ユーザが対戦処理において勝利することで０に戻る。
なお、対戦履歴データベースは、対戦履歴に基づく情報として、勝率、敗率等のデータをさらに含んでもよい。
なお、図６Ｂでは、ユーザが攻撃した場合（攻撃側となった場合）とユーザが攻撃された場合（防御側となった場合）とで別々に勝利回数、敗北回数、連勝回数、連敗回数を記録しているが、両者を合算してもよい。
勝利回数、敗北回数、連勝回数、連敗回数は、対戦処理が行われることにより更新される。なお、所定期間（例えば１日、１週間）毎に、連勝回数、連敗回数に「０」を書き込むことで、連勝回数、連敗回数をリセットしてもよい。また、所定回数の対戦処理が行われる毎に「連勝回数」及び「連敗回数」のリセットを行ってもよい。
ユーザデータベース３１に含まれる情報は、ゲームサーバ２０によって逐次更新されうる。

図５に戻り、ゲームデータベース３２は、ゲームサーバ２０からのアクセスに基づき、ゲームサーバ２０によって実行されたゲームの進行に関する情報を記憶、更新する。ゲームの進行に関する情報は、ゲームの性質によって多様な情報を含みうる。
また、ゲームデータベース３２は、上述した各種処理に関連して、カードデータベースを記憶する。

カードデータベースは、本実施形態のゲームで用意される全てのカードの情報が記述されているデータベースである。
図７は、カードデータベースのデータ構成の一例を示す図である。図７に例示するカードデータベースは、カードの識別コード（図の例では、ＭＣ００１，ＭＣ００２，…）ごとに、対象となるカードの画像データ（画像）、対象となるカードの名前（モンスター名）、対象となるカードのパラメータ（図の例では、モンスターの能力を示す攻撃力や防御力及びレア度）、及びカードの使用コストの各項目のデータを含む。例えば、攻撃力や防御力などのパラメータが大きいほど、カードに対応するモンスターの対戦処理等における能力が高いことを示すように設定されてもよい。
また、レア度は、カードの希少価値の度合を示す値であり、例えば、その値が高い（つまり、希少価値が高い）ほど、ゲーム内で出現する確率が低く設定されてもよい。例えば、レア度を１〜５の５段階で表した場合、能力の際立ったモンスターや人気のあるモンスターに対応するカードのレア度が高く（例えば、４あるいは５など）設定されてもよい。
使用コストは、対戦処理においてカードを使用するのに必要な攻撃ポイントまたは防御ポイントの値である。レア度が高いカードほど使用コストが高く設定されてもよい。

（５）本実施形態のゲーム
以下、本実施形態のゲームについて、図８、図９を参照しながら説明する。
なお、以下の説明において、通信端末１０に表示されるウェブページ上で表示されるメニュー、マーク等はウェブページ上で所望の位置に配置されるものであって、通信端末１０で視認されるメニュー、マーク等の表示画面上の位置は、ユーザの方向指示釦あるいはタッチパネル操作によるウェブページのスクロール操作によって変化しうる。

図８のトップページＰ１は、モンスター画像表示領域１０１、ユーザデータ表示領域１０２及びメニュー表示領域１０３を含む。トップページＰ１は処理対象のユーザ毎に構成されるが、図８のトップページＰ１は、処理対象のユーザが「Ａ」というユーザ（以下、「ユーザ：Ａ」と表記する。）である場合の例である。
モンスター画像表示領域１０１は、処理対象となるユーザのユーザデータベースに記録された識別コードに対応する複数のカードのうち、当該ユーザによって予め指定されたカードの画像が表示される領域である。ユーザデータ表示領域１０２は、処理対象となるユーザのユーザデータベースに記録された、進行レベル、体力ポイント等の各項目のデータ（図６Ａ参照）が表示される領域である。メニュー表示領域１０３には、本実施形態のゲームに設けられるイベント処理（クエスト処理、対戦処理）にそれぞれ対応するメニューｍ１（「クエスト」）、メニューｍ２（「対戦」）が含まれる。なお、メニュー表示領域１０３には、上述した編成処理、強化処理に対応するメニューが含まれてもよい。
このトップページＰ１上で、メニューｍ１、ｍ２が選択されることで、ゲームの実行が開始される。

〔クエスト処理〕
先ず、クエスト処理の一例を説明する。図８のトップページＰ１上でユーザ：Ａがメニューｍ１を選択すると、クエスト処理が開始され、Ｐ２に示すようにウェブページが更新される。ウェブページＰ２には、探索の対象となるエリアの進行度合いを示す達成率のゲージと、探索の対象となるエリアの探索処理を実行するための「クエスト実行」と表記されたメニューｍ１０と、１回の探索に要する体力ポイントの値、１回の探索で得られる強化ポイントなどが含まれる。
ユーザ：Ａがメニューｍ１０を選択する度に、所定の条件に沿った、あるいはランダムな増加量で達成率の値が増加する。そして、達成率が１００％に達すると、エリアの探索が終了して次のエリアに進むことができる。メニューｍ１０が選択される度に、ユーザ：Ａの体力ポイントが所定量（図８の例では、８）だけ消費される。探索対象のエリアは、複数設けられてもよい。
ウェブページＰ２においてメニューｍ１０の選択を繰り返し行うと、上述したように体力ポイントが低下していくが、体力ポイントが１回の探索に要する体力ポイント（例えば８）よりも少なくなると、それ以上探索の実行ができない状態となる。その場合、ユーザが再び探索を実行できるようになるには、時間の経過によって体力ポイントが回復（増加）するまで待機することが必要となる。
なお、クエスト処理では、メニューｍ１０が選択される度に、所定の、あるいはランダムな確率で、ゲーム上で用意されているカードあるいはアイテムなどのオブジェクトをユーザが入手できるように構成されている。メニューｍ１０が選択されたときにユーザがカードを入手したときは、例えばＰ３に示すように、入手したカードの情報を含むウェブページに更新される。

〔対戦処理〕
次に、対戦処理の一例を説明する。図８のトップページＰ１上でメニューｍ２が選択されると、対戦処理が開始され、図９のＰ４に示すようにウェブページが更新される。ウェブページＰ４には、攻撃側ユーザ（ユーザ：Ａ）の対戦相手（防御側ユーザ）の候補となる他のユーザ：Ｂ、Ｃ、Ｄ、Ｅの情報とともに、対戦相手を決定するためのメニューｍ２１〜２４（「対戦」）などが含まれる。
また、他のユーザ：Ｂ、Ｃ、Ｄ、Ｅの情報には、それぞれ、ユーザ：Ａが対戦して勝利したときに得られる報酬に関する情報が含まれる。ウェブページＰ４の例では、報酬に関する情報として、ユーザ：Ｂの欄に星が１つ、ユーザ：Ｃの欄に星が３つ、ユーザ:Ｄの欄に星が２つ、ユーザ：Ｅの欄に星が３つ、それぞれ含まれる。星の数は、ユーザ：Ａが対戦して勝利したときに得られる報酬を暗示しており、ウェブページＰ４では、例えば、ユーザ：Ｂに勝利した場合よりもユーザ：Ｄに勝利したほうが得られる報酬が多いことを示している。

ウェブページＰ４上でユーザ：Ａが例えばユーザ：Ｅに対応するメニューｍ２４を選択すると、Ｐ５に示すようにウェブページが更新される。ウェブページＰ５には、ユーザ：Ａの対戦相手として選択されたユーザ：Ｅの画像とともに、対戦の実行を指示するためのメニューｍ２５（「対戦開始」）等が含まれる。なお、図示しないが、ウェブページＰ５は、ユーザ：Ａのチームの編成処理用のウェブページへのショートカットメニューを含んでいてもよい。
ウェブページＰ５上でユーザ：Ａがメニューｍ２５（「対戦開始」）の選択を行うと、ユーザ：Ａのチームと対戦相手であるユーザ：Ｅのチームとの間で対戦が行われる。ここで、ユーザ：Ａのチームは、チームを構成するカードとしてユーザ：Ａが登録したカードから、カードの使用コストがユーザ：Ａの攻撃ポイントの現在値の範囲内となるように決定される。同様に、ユーザ：Ｅのチームは、チームを構成するカードとしてユーザ：Ｅが登録したカードから、カードの使用コストがユーザ：Ｅの防御ポイントの現在値の範囲内となるように決定される。
なお、ユーザ間の対戦は非同期で行われるため、ユーザ：Ｅとの対戦を開始する際に、ユーザ：Ａはユーザ：Ｅから対戦の承諾を得る必要はない。
対戦処理は、例えば、攻撃側のチームのカード情報、および、防御側のチームのカード情報に基づいて実施される。例えば、攻撃側のチームのカードの攻撃力の総和と、防御側のチームのカードの防御力の総和とを比較し、数字が大きい側を勝利、小さい側を敗北と決定することで、対戦結果を決定することができる。
なお、本実施例では、攻撃ポイント、防御ポイントに応じて使用できるカードが選択され、選択されたカードに基づき、攻撃力、防御力が決定されるような対戦処理としたが、対戦処理はこれに限られない。例えば、攻撃ポイントや防御ポイントをデータとして持たずに、ユーザが登録しているカード(オブジェクト)の攻撃力・防御力で対戦を行っても良いし、ユーザ：Ａがあらかじめ登録した攻撃側のチームのカードの攻撃力の総和に、ユーザ：Ａの攻撃ポイントの現在値／最大値の割合を乗じた値と、ユーザ：Ｅがあらかじめ登録した防御側のチームのカードの防御力の総和に、ユーザ：Ｅの防御ポイントの現在値／最大値の割合を乗じた値とを比較し、数字が大きい側を勝利、小さい側を敗北と決定してもよい。
また、対戦処理は攻撃力・防御力等のパラメータの総和の比較によるものに限らず、チームに設定されたカードの攻撃力・防御力を所定の計算式により変動させた上で比較し勝敗を決定してもよいし、パラメータの数値の大小に応じて勝つ確率を変動させた上で抽選処理を行い、勝敗を決定してもよい。

対戦が終了すると、対戦の結果を通知するウェブページ（Ｐ６に例示するウェブページ）がユーザ：Ａの通信端末１０上に表示される。なお、ウェブページＰ６は、ユーザ：Ａが対戦に勝利した場合に通信端末１０の表示部１６に表示されるウェブページの一例を示している。このゲームでは、ユーザ：Ａが対戦相手であるユーザ：Ｅに勝利すると、所定量の強化ポイント（図９の例では１０００）又は所定のアイテムが特典としてユーザ：Ａに付与される。なお、ウェブページＰ４で提示された星の数により、ユーザ：Ａが勝利したときに付与される強化ポイント又はアイテムを変動させてもよい。例えば、星が３つ提示されたユーザ：Ｃに勝利した場合には、星が１つのみ提示されたユーザ：Ｅに勝利した場合よりも多くの強化ポイント（例えば、３０００ポイント）が付与される。あるいは、星の数に応じたアイテムを付与してもよい。
なお、防御側ユーザであるユーザ：Ｅが勝利した場合には、ユーザ：Ｅに特典が付与される。この場合、ユーザ：Ｅに付与する特典は変動させなくてもよいし、攻撃側ユーザ：Ａの対戦履歴に応じて変動させてもよい。

（６）ゲーム制御装置における各機能の概要
本実施形態では、ゲームサーバ２０及びデータベースサーバ３０によってゲーム制御装置が構成されている。以下では、上述したゲームが適用される場合を例として、本実施形態のゲーム制御装置で実現される機能について、図１０を参照して説明する。図１０は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。
なお、図１０の機能ブロック図において、対戦処理手段５２、報酬付与手段５５、及び第１提示手段５６が本発明の主要な構成に対応している。その他の手段（つまり、実行手段５１、記憶手段５３、決定手段５４）は必ずしも必須の構成ではないが、本発明をさらに好ましくするための構成要素である。

実行手段５１は、通信端末１０に対するユーザのウェブページ上の選択に応じてＨＴＴＰリクエストを受信し、通信端末１０に表示されるウェブページを逐次更新するためのＨＴＭＬデータ（つまり、ＨＴＴＰレスポンス）を送信することで、ウェブサービスにより本実施形態のゲームを実行する機能を備える。
実行手段５１は、ゲームで実行される複数の処理が各々割り当てられた複数のメニューを通信端末１０に表示させる。具体的には、ＣＰＵ２１は、複数のメニューを含むウェブページを表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。そして、ＣＰＵ２１は、通信端末１０においてウェブページ上のメニューが選択されたときに、選択されたメニューについての情報を通信端末１０から受信し、受信した情報に基づいて、選択されたメニューに割り当てられた処理を実行する。ＣＰＵ２１は、処理の実行結果を含むＨＴＭＬデータを生成して通信端末１０へ返す。

実行手段５１がクエスト処理を実行する機能は、例えば以下のようにして実現される。
ゲームサーバ２０のＣＰＵ２１は、トップページ（図９のＰ１に例示するウェブページ）上でメニューｍ１が選択されると、クエスト処理用のウェブページ（図９のＰ２に例示するウェブページ）を表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。次に、ＣＰＵ２１は、メニューｍ１０（「クエスト実行」）の選択結果を含むＨＴＴＰリクエストを受信すると、以下の一連の処理を行う。すなわち、ＣＰＵ２１は、ユーザデータベースにアクセスし、対象となるユーザＩＤの体力ポイントの値を更新する（減少させる）。次に、ＣＰＵ２１は、ユーザの達成率の値を所定量だけ増加させる。さらに、ＣＰＵ２１は、例えば、増加した達成率の値を含むＨＴＭＬデータを生成して、ユーザの通信端末１０へ送信する。このとき、ＣＰＵ２１は、達成率の値が１００％に達したと判断した場合には、探索対象を次のエリアに移行するように、ＨＴＭＬデータを生成する。
クエスト処理では、探索対象となるエリアごとに、１回の探索に要する体力ポイントが異なってもよい。つまり、探索対象となるエリアごとに、１回の探索で減少する（消費される）体力ポイントの量が異なってもよい。例えば、ユーザの進行レベルが上がるごとに、消費される体力ポイントの量を多くしてもよい。

対戦処理手段５２は、攻撃側ユーザ（第１ユーザ）と、攻撃側ユーザにより選択された防御側ユーザ（第２ユーザ）との対戦処理を実行する機能を備える。この機能は、例えば以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、ウェブページＰ５上でメニューｍ２０（「対戦開始」）が選択されたことを認識した場合、ＣＰＵ２１は、ユーザデータベースにアクセスし、攻撃側ユーザの攻撃ポイントの現在値、及び、防御側ユーザの防御ポイントの現在値を取得する。次に、ＣＰＵ２１は、取得した攻撃ポイントの現在値に基づいて攻撃側ユーザのチームを構成するカードを決定するとともに、取得した防御ポイントの現在値を用いて防御側ユーザのチームを構成するカードを決定する。
ここで、ＣＰＵ２１は、チームを構成するカードとして攻撃側ユーザが登録したカードから、カードの使用コストが攻撃ポイントの現在値の範囲内となるように攻撃側ユーザのチームを構成するカードを決定する。同様に、ＣＰＵ２１は、チームを構成するカードとして防御側ユーザが登録したカードから、カードの使用コストが防御ポイントの現在値の範囲内となるように、防御側ユーザのチームを構成するカードを決定する。
次に、ＣＰＵ２１は、攻撃側ユーザのチームと、対戦相手として選択された防御側ユーザのチームとの対戦結果を決定する処理を行う。
本実施形態では、攻撃側ユーザと防御側ユーザとの対戦は、非同期で行われる。つまり、攻撃側ユーザの対戦相手は、防御側ユーザによるアクセスの如何に関わらず、攻撃側ユーザによる選択によって決定される。
対戦結果の決定方法は、各チームに含まれるカードのパラメータの値がその勝敗に影響を与える方法である限り如何なる方法を採ることができる。例えば、対戦を行う２つのチームの各々に含まれる複数のカードのパラメータの値の合計を比較し、合計が大きな方のチームが高い確率（例えば、６０〜９０％の範囲内の所定の確率）をもって勝利するように設定してもよい。この勝率は、パラメータの値の合計の差が大きいほど高い確率としてもよい。このとき、図７に示したように、パラメータの値を示す項目が複数（図７の例では、攻撃力と防御力の２つ）存在する場合には、各カードのパラメータの値を代表する値として、各項目の値に対して所定の重み付け（例えば、図７の例では、「攻撃力」を０．４、「防御力」を０．２の重み付けにする等）を行うことにより、総合的なパラメータの値を設定してもよい。
なお、攻撃側のチームのカードの攻撃力の総和と、防御側のチームのカードの防御力の総和とを比較する代わりに、攻撃側ユーザがあらかじめ登録した攻撃側のチームのカードの攻撃力の総和に、攻撃側ユーザの攻撃ポイントの現在値／最大値の割合を乗じた値と、防御側ユーザがあらかじめ登録した防御側のチームのカードの防御力の総和に、防御側ユーザの防御ポイントの現在値／最大値の割合を乗じた値とを比較し、数字が大きい側を勝利、小さい側を敗北と決定してもよい。

記憶手段５３は、対戦処理の結果を記憶装置に記憶させる機能を備える。記憶手段５３の機能は、例えば以下のようにして実現される。ユーザデータベース３１は、記憶装置の一例である。
対戦結果を決定すると、ＣＰＵ２１は、図６Ｂに例示する対戦履歴データベースにアクセスし、攻撃側ユーザの「攻撃時」の対戦履歴（「勝利回数」、「敗北回数」、「連勝回数」、「連敗回数」）、及び、防御側ユーザの「防御時」の対戦履歴を更新する。
具体的には、攻撃側ユーザが勝利した場合、ＣＰＵ２１は、攻撃側ユーザの「攻撃時」の「勝利回数」に１を加算するとともに、「攻撃時」の「連勝回数」に１を加算する。なお、攻撃側ユーザの加算前の「攻撃時」の「連勝回数」が０の場合は、「攻撃時」の「連勝回数」に１を書き込むとともに、「攻撃時」の「連敗回数」に０を書き込み、「攻撃時」の「連敗回数」をリセットする。また、ＣＰＵ２１は、敗北した防御側ユーザの「防御時」の「敗北回数」に１を加算するとともに、「防御時」の「連敗回数」に１を加算する。なお、防御側ユーザの加算前の「防御時」の「連敗回数」が「０」の場合は、「防御時」の「連敗回数」に１を書き込むとともに、「防御時」の「連勝回数」に「０」を書き込み、「防御時」の「連勝回数」をリセットする。
一方、攻撃側ユーザが敗北した場合、ＣＰＵ２１は、敗北した攻撃側ユーザの「攻撃時」の「敗北回数」に１を加算するとともに、「攻撃時」の「連敗回数」に１を加算する。なお、攻撃側ユーザの加算前の「攻撃時」の「連敗回数」が「０」の場合は、「攻撃時」の「連敗回数」に１を書き込むとともに、「攻撃時」の「連勝回数」に「０」を書き込み、「攻撃時」の「連勝回数」をリセットする。また、ＣＰＵ２１は、勝利した防御側ユーザの「防御時」の「勝利回数」に１を加算するとともに、「防御時」の「連勝回数」に１を加算する。なお、防御側ユーザの加算前の「防御時」の「連勝回数」が０の場合は、「防御時」の「連勝回数」に１を書き込むとともに、「防御時」の「連敗回数」に０を書き込み、「防御時」の「連敗回数」をリセットする。
なお、「連勝回数」及び「連敗回数」のリセットを行う度に、「連勝回数」及び「連敗回数」の値をユーザ毎に記録しておいてもよい。また、所定回数の対戦処理が行われる毎にリセットを行ってもよい。また、所定期間（例えば１日、１週間）毎にリセットを行ってもよい。

決定手段５４は、対戦相手として選択されるユーザ（防御側ユーザ）の対戦履歴に基づいて、対戦相手を選択したユーザ（攻撃側ユーザ）が勝利した場合に付与する報酬を決定する機能を備える。決定手段５４の機能は、例えば以下のようにして実現される。
ＣＰＵ２１は、ユーザデータベースにアクセスし、防御側ユーザとなるユーザの「防御時」の対戦履歴を取得する。次に、ＣＰＵ２１は、対戦履歴に基づいて報酬を決定する。例えば、ＣＰＵ２１は、防御側ユーザの「防御時」の勝率、すなわち、「防御時」の勝利数／（勝利数＋敗北数）が低いほど少ない報酬を決定することができる。例えば、勝率に比例する強化ポイントを報酬として決定することができる。あるいは、勝率に比例する数のアイテム、あるいは勝率に比例するパラメータ（攻撃力、レア度等）を備えたカード等を報酬として決定することができる。
あるいは、ＣＰＵ２１は、防御側ユーザの「防御時」の「連敗回数」に応じて変動する報酬を決定することができる。例えば、防御側ユーザの「連敗回数」に比例する強化ポイントを報酬として決定することができる。あるいは、報酬として付与するアイテムの数を「防御時」の「連敗回数」に応じて変動させることができる。例えば、防御側ユーザの「防御時」の「連敗回数」が０であればアイテムを３つ、防御側ユーザの「防御時」の「連敗回数」が１であればアイテムを２つ、防御側ユーザの「防御時」の「連敗回数」が２であればアイテムを１つ付与するとともに、防御側ユーザの「防御時」の「連敗回数」が３以上であればアイテムを付与しないことを決定することができる。
また、防御側ユーザの「防御時」の「連敗回数」が０であれば報酬を付与し、防御側ユーザの「連敗回数」が１以上であれば報酬を付与しないこと、あるいは「連敗回数」が０の場合よりも少ない報酬を付与することを決定してもよい。すなわち、防御側ユーザが直前の対戦処理で敗北している場合に報酬を減少させることを決定してもよい。
なお、ＣＰＵ２１は、防御側ユーザの「攻撃時」の対戦履歴に基づいて報酬を決定してもよいし、「攻撃時」及び「防御時」の両方の対戦履歴に基づいて報酬を決定してもよい。
あるいは、ＣＰＵ２１は、防御側ユーザの「防御時」の対戦履歴と攻撃側ユーザの「攻撃時」の対戦履歴を比較して、報酬を決定してもよい。例えば、防御側ユーザの「防御時」の勝率が攻撃側ユーザの「攻撃時」の勝率よりも低い場合は報酬としてアイテムを１つ、防御側ユーザの「防御時」の勝率が攻撃側ユーザの「攻撃時」の勝率よりも高い場合は報酬としてアイテムを２つ付与することを決定してもよい。あるいは、防御側ユーザの「防御時」の勝率が攻撃側ユーザの「攻撃時」の勝率よりも高い場合、防御側ユーザの「防御時」の勝率が攻撃側ユーザの「攻撃時」の勝率よりも低い場合の２倍の強化ポイントを報酬として決定してもよい。
なお、防御側ユーザが勝利した場合に付与する報酬については、攻撃側ユーザの対戦履歴に基づいて同様に決定してもよいし、攻撃側ユーザの対戦履歴によらずに一律に決定してもよい。
また、ＣＰＵ２１は、防御側ユーザの「防御時」の対戦履歴と攻撃側ユーザの「防御時」の対戦履歴の比較結果、防御側ユーザの「攻撃時」の対戦履歴と攻撃側ユーザの「攻撃時」の対戦履歴の比較結果、防御側ユーザの「攻撃時」の対戦履歴と攻撃側ユーザの「防御時」の対戦履歴の比較結果のいずれかに基づいて報酬を決定してもよい。
また、「攻撃時」及び「防御時」の両方の対戦履歴を合算した比較結果に基づいて報酬を決定してもよい。また、「攻撃時」と「防御時」に分けずに対戦履歴を記録し、当該対戦履歴の比較結果に基づいて報酬を決定してもよい。

報酬付与手段５５は、対戦処理において勝利したユーザに対し、決定された報酬を付与する機能を備える。報酬付与手段５５の機能は、例えば以下のとおり実現される。
ＣＰＵ２１は、対戦処理において攻撃側ユーザが勝利したと判定すると、ユーザデータベースにアクセスし、防御側ユーザの対戦履歴を取得する。次に、ＣＰＵ２１は、対戦履歴に基づいて報酬を上述したように決定する。その後、ＣＰＵ２１は、決定した報酬を攻撃側ユーザに付与する。例えば、決定した報酬が強化ポイントであれば、ＣＰＵ２１は、ユーザデータベースにアクセスし、攻撃側ユーザの強化ポイントに報酬分の強化ポイントを加算する。また、報酬がアイテムであれば、ＣＰＵ２１は、ユーザデータベースにアクセスし、攻撃側ユーザの「保有カード、アイテムの識別コード」の欄に報酬として付与するアイテムの識別コードを書き込む。

第１提示手段５６は、攻撃側ユーザにより対戦相手（防御側ユーザ）として選択されるユーザのリストを、防御側ユーザの対戦履歴に基づく情報又は攻撃側ユーザに付与される報酬に関する情報とともに攻撃側ユーザに対戦処理前に提示する機能を備える。第１提示手段５６の機能は、例えば以下の通り実現される。

ＣＰＵ２１は、図８のトップページＰ１上でユーザ（攻撃側ユーザ）によりメニューｍ２が選択されたことを認識すると、他のユーザから防御側ユーザとなるユーザを決定する。この際、ＣＰＵ２１は、他のユーザの対戦履歴に基づいて、防御側ユーザとなるユーザを選択してもよい。例えば、連敗回数が所定回数以上のユーザ、敗率が所定割合以上のユーザ、敗北回数が所定回数以上のユーザを除外して防御側ユーザとなるユーザを決定してもよい。あるいは、連敗回数、敗率、敗北回数に応じて、防御側ユーザとなる確率を変更してもよい。例えば、防御側ユーザとなる確率を、連敗回数が３回以上であれば１０％、連敗回数が２回であれば２０％、連敗回数が１回であれば３０％、連敗回数が０であれば４０％、となるように設定してもよい。
次に、ＣＰＵ２１は、ユーザデータベースにアクセスし、決定した防御側ユーザの対戦履歴を取得する。次に、ＣＰＵ２１は、取得した防御側ユーザの対戦履歴に基づく情報、又は、決定した攻撃側ユーザに付与される報酬に関する情報とともに、攻撃側ユーザにより対戦相手として選択されるユーザのリストを含むウェブページＰ４のＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。
例えば、防御側ユーザの対戦履歴に基づく情報は、対戦履歴を明示する情報（例えば、「勝率：１０％」（「敗率：９０％」）、「連敗回数：３回」、「敗北回数：１２９回」等のテキスト）であってもよいし、対戦履歴を暗示する情報であってもよい。
例えば、防御側ユーザの勝率が５０％以上であれば星３つ、勝率が３０％以上５０％未満であれば星２つ、勝率が１０％以上３０％未満であれば星１つの画像情報を提示し、勝率が１０％未満であれば星の画像情報を提示しないことで対戦履歴を暗示してもよい。あるいは、防御側ユーザの連敗回数が０であれば星３つ、連敗回数が１回であれば星２つ、連敗回数が２回であれば星１つの画像情報を提示し、連敗回数が３回以上であれば星の画像情報を提示しないことで対戦履歴を暗示してもよい。あるいは、敗北回数が２０回未満であれば星３つ、２０回以上５０回未満であれば星２つ、５０回以上１００回未満であれば星１つの画像情報を提示し、１００回以上であれば星の画像情報を提示しないことで対戦履歴を暗示してもよい。
また、報酬に関する情報は、例えば、報酬を明示する情報（例えば、アイテム名、「１０００強化ポイント」等）であってもよいし、報酬を暗示する情報であってもよい。
例えば、報酬が１０００強化ポイントであれば星１つ、２０００強化ポイントであれば星２つ、３０００強化ポイントであれば星３つの画像情報を提示することで報酬を暗示してもよい。
あるいは、報酬がアイテム１つであれば星１つ、アイテム２つであれば星２つ、アイテム３つであれば星３つの画像情報を提示することで報酬を暗示してもよい。
あるいは、「多い」、「やや多い」、「やや少ない」、「少ない」等のテキストにより報酬を暗示してもよい。

（７）本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、図１１〜図１２のフローチャートを参照して説明する。図１１は、本実施形態のゲームにおいてクエスト処理を行うときのフローチャートである。図１２は、本実施形態のゲームにおいて、対戦処理を行うときのフローチャートである。
なお、図１１〜図１２のフローチャートにおける各処理の実行に伴って適宜、Ｐ１〜Ｐ６の各ウェブページを表示するためのＨＴＭＬデータがゲームサーバ２０から通信端末１０宛に送信されるが、煩雑とならないようにＨＴＭＬデータの送信処理をフローチャートには記載しない場合もある。フローチャート上で、ウェブページＰ１〜Ｐ６の各々が表示されるタイミングは、Ｐ１〜Ｐ６の符号で示してある。
なお、図１１〜図１２のフローチャートでは、ユーザ：Ａがゲームを実行する場合を一例として説明する。

〔クエスト処理〕
図１１を参照して、クエスト処理を行うときのフローチャートの一例を説明する。
ＣＰＵ２１は、図８のトップページＰ１でメニューｍ１（「クエスト」）が選択されたことを認識すると、クエスト処理を開始する。まず、ウェブページＰ２のメニューｍ１０（「クエスト実行」）が選択されたことを認識すると（ステップＳ１００：ＹＥＳ）、ＣＰＵ２１は、ユーザデータベースにアクセスしてユーザ：Ａの達成率、体力ポイント、経験値等を更新する（ステップＳ１０２）。次に、ＣＰＵ２１は、複数のカードの中から選択されたカードをユーザ：Ａに付与するか否かについて、所定の、あるいはランダムな確率で決定する（ステップＳ１０４）。ステップＳ１０４において、カードをユーザ：Ａに付与することを決定すると（ステップＳ１０４：ＹＥＳ）、ＣＰＵ２１は、ユーザ：Ａにカードを付与する（ステップＳ１０６）。すなわち、ＣＰＵ２１は、ユーザデータベースにアクセスして、付与されることが決定したカードの識別コードを、ユーザ:Ａのその後、ＣＰＵ２１は、クエスト処理を終了する。
ステップＳ１０４において、カードをユーザ：Ａに付与しないことを決定すると（ステップＳ１０４：ＮＯ）、ＣＰＵ２１は、クエスト処理を終了する。
なお、メニューｍ１０以外が選択された場合（ステップＳ１００：ＮＯ）、ＣＰＵ２１は、クエスト処理を終了する。

〔対戦処理〕
次に、図１２を参照して、対戦処理を行うときのフローチャートの一例を説明する。
ＣＰＵ２１は、図８のトップページＰ１でメニューｍ２（「対戦」）が選択されたことを認識すると、対戦処理を開始する。まず、ユーザ：Ａ（攻撃側ユーザ）以外のユーザから対戦相手の候補となる防御側ユーザを決定する（ステップＳ２００）。次に、ＣＰＵ２１は、防御側ユーザのリストとともに提示する、防御側ユーザの対戦履歴に基づく情報又は攻撃側ユーザに付与される報酬に関する情報を決定する（ステップＳ２０２）。具体的には、ＣＰＵ２１は、ユーザデータベースにアクセスし、防御側ユーザの対戦履歴を取得し、対戦履歴に基づく情報又は報酬に関する情報を決定する。
次に、ＣＰＵ２１は、ウェブページＰ５でメニューｍ２１〜２４（「対戦」）のいずれかが選択されたか否かを判定する（ステップS２０４）。メニューｍ２１〜ｍ２４（「対戦」）以外が選択された場合（ステップＳ２０４：ＮＯ）、ＣＰＵ２１は、対戦処理を終了する。
メニューｍ２１〜２４のいずれかが選択された場合（ステップＳ２０４：ＹＥＳ）、ＣＰＵ２１は、攻撃側ユーザ（ユーザ：Ａ）の対戦相手として選択された防御側ユーザ（図９ではユーザ：Ｅ）の画像とともに、対戦の実行を指示するためのメニューｍ２５（「対戦開始」）が提示されたウェブページＰ５において、メニューｍ２５が選択されたか否かを判定する（ステップＳ２０６）。メニューｍ２５以外が選択された場合（ステップＳ２０６：ＮＯ）、対戦処理を終了する。
ウェブページＰ５上でメニューｍ２０（「対戦開始」）が選択されたことを認識すると（ステップＳ２０６：ＹＥＳ）、ＣＰＵ２１は、対戦結果を決定する（ステップＳ２０８）。
攻撃側ユーザ（ユーザ：Ａ）が対戦に勝利した場合（ステップＳ２０８：ＹＥＳ）、ＣＰＵ２１は、攻撃側ユーザ（ユーザ：Ａ）に対して付与する報酬を決定する処理を行う（ステップＳ２１０）。すなわち、ＣＰＵ２１は、ユーザデータベースにアクセスして防御側ユーザの対戦履歴を取得し、対戦履歴に基づいて報酬を決定する。あるいはＣＰＵ２１は、ステップＳ２０２で決定した、対戦履歴に基づく報酬をＲＡＭ１３から読み出す。
次に、ＣＰＵ２１は、決定した報酬を攻撃側ユーザ（ユーザ：Ａ）に付与する（ステップＳ２１２）。報酬が強化ポイントであれば、ＣＰＵ２１は、ユーザデータベースにアクセスして、ユーザ：ＡのユーザＩＤに対応する強化ポイントの値を所定値（例えば１０００）だけ増加させる。また、報酬がアイテムであれば、ＣＰＵ２１は、ユーザデータベースにアクセスし、ユーザ：ＡのユーザＩＤに対応する「保有カード、アイテムの識別コード」の欄に報酬として付与するアイテムの識別コードを書き込む。その後、ＣＰＵ２１は、対戦処理を終了する。
一方、ユーザ：Ａが対戦に敗北した場合（ステップＳ２０８：ＮＯ）、ＣＰＵ２１は、ユーザ：Ａに攻撃された防御側ユーザ（ユーザ：Ｅ）に付与する報酬を決定する（ステップＳ２１４）。すなわち、ＣＰＵ２１は、ユーザデータベースにアクセスして攻撃側ユーザ（ユーザ：Ａ）の対戦履歴を取得し、対戦履歴に基づいて報酬を決定する。なお、防御側ユーザが勝利した場合の報酬を攻撃側ユーザ（ユーザ：Ａ）の対戦履歴によらず一律に設定してもよい。
次に、ＣＰＵ２１は、決定した報酬を防御側ユーザ（ユーザ：Ｅ）に付与する（ステップＳ２１６）。報酬が強化ポイントであれば、ＣＰＵ２１は、ユーザデータベースにアクセスして、ユーザ：ＥのユーザＩＤに対応する強化ポイントの値を所定値（例えば１０００）だけ増加させる。また、報酬がアイテムであれば、ＣＰＵ２１は、ユーザデータベースにアクセスし、ユーザ：ＥのユーザＩＤに対応する「保有カード、アイテムの識別コード」の欄に報酬として付与するアイテムの識別コードを書き込む。その後、ＣＰＵ２１は、対戦処理を終了する。
なお、ステップＳ２００とステップＳ２０２の順番を逆にしてもよい。すなわち、防御側ユーザの対戦履歴に基づく情報又は攻撃側ユーザに付与される報酬に関する情報をあらかじめ定めておき、当該情報に合致するユーザを抽出して防御側ユーザとして決定してもよい。

以上説明したように、このゲーム制御装置では、攻撃側ユーザが勝利した場合に攻撃側ユーザに付与する報酬を、防御側ユーザの対戦履歴に基づいて変動させることで、攻撃側ユーザが弱い防御側ユーザを対戦相手として選択しないように促すことができる。
特に本発明に係るゲームでは、防御側ユーザの承諾なしに非同期で対戦処理が行われるため、防御側ユーザはチームを構成するカードを変更することができず、かつ対戦の結果に影響を与える操作ができない状態にある。このため、対戦処理の開始前に編成処理を行うことができる攻撃側ユーザと比較して、防御側ユーザは不利な立場にあり、連続して敗北しやすくなる。本発明によれば、このような不利な立場に陥った防御側ユーザの対戦相手としての魅力を失わせ、攻撃側ユーザから対戦相手として選択されにくくすることができる。このため、弱い防御側ユーザがゲームを継続するモチベーションを維持することができる。
なお、上記実施形態においては、対戦相手となる防御側ユーザのリストを提示するとき（図１２のステップＳ２０２）、及び、報酬を決定するとき（図１２のステップＳ２１０）に対戦履歴を取得していたが、本発明はこれに限らず、報酬付与前であれば対戦処理中の任意の時点で対戦履歴を取得することができる。例えば、攻撃側ユーザがメニューｍ２５（「対戦開始」）の選択をしたとき（図１２のステップＳ２０６）に対戦履歴を取得してもよい。
また、上記実施形態においては、対戦結果が決定した後（図１２のステップＳ２０８の後）に報酬を決定していたが、本発明はこれに限らず、報酬付与前であれば対戦処理中の任意の時点で報酬を決定することができる。例えば、攻撃側ユーザに提示する情報を決定するとき（図１２のステップＳ２０２）、攻撃側ユーザがメニューｍ２５（「対戦開始」）の選択をしたとき（図１２のステップＳ２０６）に報酬を決定してもよい。また、ステップＳ２０８で判定された、ユーザ：Ａとユーザ：Ｅの対戦結果が反映された対戦履歴に基づいて報酬を決定してもよいし、ステップＳ２０８で判定された対戦結果が反映される前の対戦履歴に基づいて報酬を決定してもよい。
また、上記実施形態においては、報酬付与手段５５は、対戦履歴に基づいて報酬の多寡を変動させていたが、本発明はこれに限らない、報酬付与手段５５は、対戦履歴に基づいて報酬として付与するオブジェクト(アイテムやカード等)の質を変動させてもよい。例えば、敗北回数が多い、又は、敗北率が高いほど、質(ゲーム内外の有益度)の高いアイテム又はカードが付与されるとしても良い。なお、質の高いオブジェクトを付与とは、例えば、報酬をカードとした場合に、より高いレア度のカードを付与することでも良い。
また、報酬付与手段５５は、対戦履歴に基づいて報酬を付与する確率を変動させてもよい。例えば、敗北率が高い、又は、敗北回数が多いほど、報酬を獲得できる確率を高くしても良い。この場合において、第１提示手段５６も報酬を付与する確率に関する情報を提示することとしても良い。
また、上記実施形態においては、ユーザ間の対戦を非同期で行っていたが、本発明はこれに限らず、ユーザ間対戦を同期させて行い、攻撃側ユーザが防御側ユーザに対戦の申し込みをし、防御側ユーザから対戦の承諾を得た後に対戦処理を実行してもよい。

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

（８−１）変形例１
図１３は本変形例に係る対戦処理において用いられる参加要請データベースの一例である。参加要請データベースは、データベースサーバ３０に記憶される。
この例では、参加要請データベースは、イベントコードごとに、対戦処理において参加を要請したユーザ（要請元ユーザ）のユーザＩＤ、要請元ユーザの対戦相手のユーザ（対戦相手ユーザ）のユーザＩＤ、要請元ユーザにより参加を要請されたユーザ（要請先ユーザ）のユーザＩＤ、参加の要請をされて対戦処理に参加済みのユーザ（救援ユーザ）のユーザＩＤの各項目についての情報を含む。要請元ユーザは第２ユーザの一例であり、対戦相手ユーザは第１ユーザの一例であり、要請先ユーザは第３ユーザの一例である。以下では、要請元ユーザの例としてユーザ：Ｅ、対戦相手ユーザの例としてユーザ：Ａ、要請先ユーザの例としてユーザ：Ｇ、Ｈ、Ｉ、救援ユーザの例としてユーザ：Ｇを挙げて説明する。

本変形例のゲームについて、図１４を参照しながら説明する。図１４のＰ７は本変形例に係る対戦処理において、防御側のユーザ：Ｅが敗北した場合にユーザの通信端末に表示されるウェブページの一例である。図１４のウェブページＰ７は、ユーザ：Ｅが他のユーザから攻撃され、敗北したことを示すメニューｍ３（「防御失敗」）を含む。
ユーザ：Ｅがメニューｍ３を選択すると、図１４のＰ８に示すようにウェブページが更新される。ウェブページＰ８は、ユーザ：Ｅを攻撃したユーザ：Ａに関する情報、及び、ユーザ：Ａとの対戦処理への参加を仲間に要請するためのメニューｍ３０（「救援要請」）を含む。
ユーザ：ＥがウェブページＰ８においてメニューｍ３０を選択すると、図１４のＰ９に示すようにウェブページが更新される。ウェブページＰ９は、ユーザ：Ｅの仲間（ユーザ：Ｇ、Ｈ、Ｉ）に対してユーザ：Ａとの対戦処理への参加の要請がされたことを示す情報（「以下の仲間に救援要請をしました」）を含む。
なお、ユーザ：Ｅが要請先ユーザを選択可能としてもよい。

要請先ユーザ（ここでは、ユーザ：Ｇ）が、その後、ゲームにアクセスすると、図１５に示すようなトップページＰ１０がユーザ：Ｇの通信端末１０上に表示される。トップページＰ１０は、救援要請があったことを示すメニューｍ４（「救援要請があります」）を含む。
トップページＰ１０において、ユーザ：Ｇがメニューｍ４を選択操作すると、図１５のＰ１１に例示するウェブページがユーザ：Ｇの通信端末１０上に表示される。ウェブページＰ１１は、ユーザ：Ｇに救援要請をした要請者のユーザ名、対戦処理の対戦相手、ユーザ：Ｇが救援して勝利したときに得られる報酬に関する情報が含まれる。ウェブページＰ１０の例では、要請者：Ｅ（対戦相手：Ａ）の欄に星が３つの画像、要請者：Ｈ（対戦相手：Ｃ）の欄に星が３つの画像、要請者:Ｉ（対戦相手：Ｄ）の欄に星が２つの画像が、それぞれ含まれる。星の数は、ユーザ：Ｇが対戦して勝利したときに得られる報酬を暗示しており、ウェブページＰ１０では、例えば、対戦相手：Ｄに勝利した場合よりも対戦相手：Ａに勝利したほうが得られる報酬が多いことを示している。
また、ウェブページＰ１０は、ユーザ：Ｇが救援する要請者（及びユーザ：Ｇの対戦相手）を決定するためのメニューｍ４１〜ｍ４３（「救援する」）などが含まれる。

ウェブページＰ１０上でユーザ：Ｇが例えば要請者：Ｅ（対戦相手：Ａ）に対応するメニューｍ４１を選択すると、Ｐ１２に示すようにウェブページが更新される。ウェブページＰ１２には、ユーザ：Ｇの対戦相手として選択されたユーザ：Ａの画像とともに、対戦の実行を指示するためのメニューｍ４４（「対戦開始」）等が含まれる。
ウェブページＰ１２上でユーザ：Ｇがメニューｍ４４（「対戦開始」）の選択を行うと、ユーザ：Ｇのチームと対戦相手：Ａのチームとの間で対戦が行われる。以後、上記実施形態と同様に対戦処理が行われる。

次に、本変形例に係るゲーム制御装置の機能ブロック図を、図１６に示す。図１６に示すように、本変形例では、図１０の機能ブロック図と比較して、関連付け手段５７、要請手段５８、第２提示手段５９が追加された点で異なる。

関連付け手段５７は、ユーザと他のユーザを関連付ける機能を備える。
関連付け手段５７の機能は、例えば以下のようにして実現される。

ユーザ：Ｅが他のユーザ：Ｇに対して仲間申請をし、ユーザ：Ｇが申請を承認した場合、ＣＰＵ２１は、ユーザデータベースにアクセスし、ユーザ：ＥのユーザＩＤの「仲間のユーザＩＤ」の欄にユーザ：ＧのユーザＩＤを書き込むとともに、ユーザ：ＧのユーザＩＤの「仲間のユーザＩＤ」の欄にユーザ：ＥのユーザＩＤを書き込む。
なお、関連付け手段５７は、上述した申請及び承認の手順を省略して、ユーザ同士の関連付けを行っても良い。例えば、ＣＰＵ２１は、仲間になりたいユーザＩＤ（あるいは、対応するユーザ名）を指定した申請メッセージ（申請）を受け付けることで、指定先のユーザＩＤのユーザの承諾を得ることなく指定先のユーザＩＤを仲間として登録してもよい。
なお、ユーザ同士を関係付ける条件は、上述したものに限られず、同一のゲーム上のステージ若しくはエリアを実行するユーザや試合を行ったユーザ同士を仲間として登録してもよい。あるいは、所定回数の挨拶メッセージを送信するユーザ同士を自動的に仲間として登録してもよいし、ユーザ間で対戦を所定回数以上対戦を行ったユーザ同士や、協力して敵キャラクタと対戦をしたユーザ同士を自動的に仲間として登録してもよい。
また、イベントへの参加要請や参加申請を契機にしてユーザ同士を関連付けてもよい。
ゲーム内でユーザ同士のグループ（ギルド等）が設定されている場合、例えば、あるユーザ（「ユーザ：Ｅ」とする。）があるグループへの参加が承認されたときに、当該グループ内の他のユーザ（「ユーザ：Ｇ、Ｈ、Ｉ」とする。）のユーザＩＤをユーザ：Ｅの「仲間のユーザＩＤ」の欄に書き込むとともに、ユーザ：Ｅのユーザデータにユーザ：Ｇ、Ｈ、ＩのユーザＩＤを「仲間のユーザＩＤ」の欄に書き込んでもよい。
本実施形態では、ユーザ同士の仲間関係の登録をユーザデータベース３１にデータを書き込むことによって実現する例を示したが、この例に限られない。仲間関係に関するデータは、ゲームサーバ２０からアクセス可能なネットワーク上の外部の記憶装置に書き込まれるようにしてもよい。

要請手段５８は、要請元ユーザが、自分の仲間として関連付けられたユーザに対して、対戦相手ユーザとの対戦処理への参加を要請する機能を有する。要請手段５８の機能は、例えば以下のようにして実現される。

ＣＰＵ２１は、ウェブページＰ８において要請元ユーザ：Ｅによりメニューｍ３０が選択されたことを認識すると、ユーザデータベースにアクセスし、要請元ユーザ：Ｅの仲間のユーザのユーザＩＤを取得する。次に、ＣＰＵ２１は、参加要請データベースにアクセスし、新たなイベントコードに対して、要請元ユーザ（ユーザ：Ｅ）のユーザＩＤ、ユーザ：Ｅにより参加要請がされた対戦処理における対戦相手ユーザ（ユーザ：Ａ）のユーザＩＤ、参加を要請された要請先ユーザのユーザＩＤ（ユーザ：Ｅの仲間のユーザのユーザＩＤ）を書き込む。なお、この時点では、参加済みのユーザ（救援ユーザ）のユーザＩＤは書き込まれていない。
その後、要請先ユーザ（ユーザ：Ｇ）がゲームにアクセスし、ウェブページＰ１１においてメニューｍ４１の選択を行ったことを認識すると、ＣＰＵ２１は、要請先ユーザ：ＧのユーザＩＤを対応する救援要請データベースの救援ユーザＩＤに書き込む。

第２提示手段５９は、要請先ユーザに対し、対戦相手のリストを、要請元ユーザの対戦履歴に基づく情報又は要請先ユーザに付与される報酬に関する情報とともに要請先ユーザに対戦処理前に提示する機能を有する。第２提示手段５９の機能は、例えば以下のようにして実現される。

ＣＰＵ２１は、ユーザ：Ｇがゲームにアクセスすると、図１３に例示する参加要請データベースにアクセスし、ユーザ：Ｇに対応するユーザＩＤがいずれかのイベントコードの要請先ユーザＩＤの欄に記録されているか否かを判定する。ユーザ：Ｇに対応するユーザＩＤがいずれかのイベントＩＤの要請先ユーザＩＤの欄に記録されている場合、ＣＰＵ２１は、図１５に示すように、メニューｍ４を含むトップページＰ９のＨＴＭＬデータを生成し、ユーザ：Ｇの通信端末１０宛に送信する。
トップページＰ９において、要請先ユーザ：Ｇがメニューｍ４を選択操作した場合、ＣＰＵ２１は、参加要請データベースにアクセスし、ユーザ：ＧのユーザＩＤが要請先ユーザＩＤに記録されたイベントＩＤの欄に記録された情報に基づき、要請元ユーザ及び対戦相手ユーザのユーザＩＤを取得する。次に、ＣＰＵ２１は、ユーザデータベースにアクセスして取得された、要請元ユーザの対戦履歴に基づく情報、又は、対戦履歴に基づいて決定された、要請先ユーザ：Ｇが勝利した場合に付与する報酬に関する情報とともに、要請先ユーザ：Ｇが救援する要請元ユーザ（要請者）及び対戦相手ユーザ（対戦相手）のリストを含むウェブページＰ１０のＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。

次に、要請先ユーザが参加要請を受諾し、参加要請を受諾した要請先ユーザ（救援ユーザ）が要請元ユーザを救援するために対戦相手と対戦する救援処理のフローの一例について、図１７のフローチャートを参照して説明する。
ＣＰＵ２１は、トップページＰ９において、要請先ユーザ（ユーザ：Ｇ）がメニューｍ４を選択したか否かを判定する（ステップＳ３００）。要請先ユーザ：Ｇがメニューｍ４以外の選択を行った場合（ステップＳ３００：ＮＯ）、ＣＰＵ２１は、救援処理を終了する。
要請先ユーザ：Ｇがメニューｍ４を選択した場合（ステップＳ３００：ＹＥＳ）、ＣＰＵ２１は、ウェブページＰ１０において、ユーザ：Ｇがメニューｍ４１〜ｍ４３を選択したか否かを判定する（ステップＳ３０２）。要請先ユーザ：Ｇがメニューｍ４１〜ｍ４３以外の選択を行った場合（ステップＳ３０２：ＮＯ）、ＣＰＵ２１は、救援処理を終了する。
要請先ユーザ：Ｇがメニューｍ４１〜ｍ４３のいずれかの選択を行った場合（ステップＳ３０２：ＹＥＳ）、ＣＰＵ２１は、選択されたメニューｍ４１〜ｍ４３に応じて対戦相手を決定する（ステップＳ３０４）。すなわち、ＣＰＵ２１は、要請先ユーザ：ＧのユーザＩＤを対応する救援要請データベースの救援ユーザＩＤに書き込むとともに、対戦相手ユーザのユーザＩＤを取得する。以後、ユーザ：Ｇは救援ユーザとなる。
次に、ＣＰＵ２１は、ウェブページＰ１１において、救援ユーザ：Ｇがメニューｍ４４を選択したか否かを判定する（ステップＳ３０６）。救援ユーザ：Ｇがメニューｍ４３以外の選択操作を行った場合（ステップＳ３０６：ＮＯ）、ＣＰＵ２１は、救援処理を終了する。

救援ユーザ：Ｇがメニューｍ４４を選択した場合（ステップＳ３０６：ＹＥＳ）、ＣＰＵ２１は、対戦結果を決定する（ステップＳ３０８）。
救援ユーザ：Ｇが対戦に勝利した場合（ステップＳ３０８：ＹＥＳ）、ＣＰＵ２１は、救援ユーザ：Ｇに対して付与する報酬を決定する処理を行う（ステップＳ３１０）。すなわち、ＣＰＵ２１は、ユーザデータベースにアクセスして要請元ユーザ：Ｅの対戦履歴を取得し、対戦履歴に基づいて報酬を決定する。
次に、ＣＰＵ２１は、決定した報酬を救援ユーザ：Ｇに付与する（ステップＳ３１２）。報酬が強化ポイントであれば、ＣＰＵ２１は、ユーザデータベースにアクセスして、ユーザ：ＧのユーザＩＤに対応する強化ポイントの値を所定値（例えば１０００）だけ増加させる。また、報酬がアイテムであれば、ＣＰＵ２１は、ユーザデータベースにアクセスし、救援ユーザ：ＧのユーザＩＤに対応する「保有カード、アイテムの識別コード」の欄に報酬として付与するアイテムの識別コードを書き込む。その後、ＣＰＵ２１は、救援処理を終了する。
一方、救援ユーザ：Ｇが対戦に敗北した場合（ステップＳ３０８：ＮＯ）、ＣＰＵ２１は、対戦相手ユーザ（ユーザ：Ａ）に付与する報酬を決定する（ステップＳ３１４）。すなわち、ＣＰＵ２１は、ユーザデータベースにアクセスして救援ユーザ：Ｇの対戦履歴を取得し、対戦履歴に基づいて報酬を決定する。なお、対戦相手ユーザが勝利した場合の報酬を救援ユーザの対戦履歴によらず一律に設定してもよい。
次に、ＣＰＵ２１は、決定した報酬を対戦相手ユーザ（ユーザ：Ａ）に付与する（ステップＳ３１６）。報酬が強化ポイントであれば、ＣＰＵ２１は、ユーザデータベースにアクセスして、対戦相手ユーザ：ＡのユーザＩＤに対応する強化ポイントの値を所定値（例えば１０００）だけ増加させる。また、報酬がアイテムであれば、ＣＰＵ２１は、ユーザデータベースにアクセスし、対戦相手ユーザ：ＡのユーザＩＤに対応する「保有カード、アイテムの識別コード」の欄に報酬として付与するアイテムの識別コードを書き込む。その後、ＣＰＵ２１は、対戦処理を終了する。

本変形例においては、対戦処理において救援ユーザが勝利した場合に、要請元ユーザの対戦履歴に基づいて変動する報酬が救援ユーザに付与される。このため、要請元ユーザが弱いほど救援ユーザに要請された対戦処理への参加を動機付けることができる。また、攻撃側ユーザが救援ユーザからの攻撃を避けるために自分よりも弱いユーザを対戦相手として選択しないように促すことができる。このため、弱い攻撃側ユーザがゲームを継続するモチベーションを維持することができる。
なお、本変形例においては、要請先ユーザを要請元ユーザの仲間に限定しているが、本発明はこれに限らず、仲間以外の任意のユーザに参加要請を可能としてもよい。例えば、要請元ユーザが参加要請をした時点でゲームにアクセスしているユーザにランダムに参加要請をしてもよい。つまり、関連付け手段５７は必須ではなく、要請手段５８は、第２ユーザが任意の第３ユーザに対して前記第１ユーザとの対戦処理への参加を要請しても良い。
また、本変形例では、防御側ユーザが要請元ユーザとなる場合について説明したが、本発明はこれに限らず、攻撃側ユーザが要請元ユーザとなってもよい。例えば、攻撃側ユーザ：Ａと防御側ユーザ：Ｅとの対戦処理において、攻撃側ユーザ：Ａが敗北した場合、攻撃側ユーザ：Ａが要請元ユーザとして仲間のユーザに対して対戦処理への参加を仲間に要請可能としてもよい。
また、参加要請データベースにおいて要請先ユーザＩＤを記録する代わりに、ユーザデータベースにおいて要請元ユーザが参加要請をしたか否かをフラグにより管理してもよい。この場合、例えば、ユーザ：Ｇがゲームにアクセスした場合、ＣＰＵ２１はユーザデータベースにアクセスし、ユーザ：Ｇの仲間のユーザのフラグを確認する。フラグによりユーザ：Ｅ、Ｈ、Ｉが参加要請をしたことを認識した場合、ＣＰＵ２１は、図１５に例示するトップページＰ１０、ウェブページＰ１１のＨＴＭＬデータを生成して、ユーザ：Ｇの通信端末１０宛に送信する。

（８−２）変形例２
図１８のＰ１３は本変形例に係る対戦処理において、対戦相手を選択するために攻撃側ユーザ：Ａの通信端末に表示されるウェブページの一例である。ウェブページＰ１３は、ユーザ：Ａの対戦相手の候補となる他のユーザ：Ｂ、Ｃ、Ｄ、Ｅの情報とともに、対戦相手を決定するためのメニューｍ２１〜２４（「対戦」）などが含まれる。
また、対戦相手の候補となる他のユーザ：Ｂ、Ｃ、Ｄ、Ｅの情報には、それぞれ、ユーザ：Ｂ、Ｃ、Ｄ、Ｅの防御ポイント（防御Ｐ）の現在値と、ユーザ：Ａが対戦して勝利したときに得られる報酬に関する情報が含まれる。ウェブページＰ４の例では、報酬に関する情報として、ユーザ：Ｂの欄に星が１つ、ユーザ：Ｃの欄に星が３つ、ユーザ:Ｄの欄に星が２つ、ユーザ：Ｅの欄に星が３つ、それぞれ含まれる。星の数は、ユーザ：Ａが対戦して勝利したときに得られる報酬を暗示しており、ウェブページＰ４では、例えば、ユーザ：Ｂに勝利した場合よりもユーザ：Ｄに勝利したほうが得られる報酬が多いことを示している。

本変形例に係るゲーム制御装置の機能ブロック図を、図１９に示す。図１９に示すように、本変形例では、図１６の機能ブロック図と比較して、対応付け手段６０が追加された点で異なる。

本変形例における決定手段５４は、防御側ユーザの防御ポイントの現在値に基づいて、攻撃側ユーザが勝利した場合に付与する報酬を決定する機能を備える。決定手段５４の機能は、例えば以下のようにして実現される。
ＣＰＵ２１は、ユーザデータベースにアクセスし、防御側ユーザの防御ポイントの現在値を取得する。次に、ＣＰＵ２１は、防御ポイントの現在値に基づいて報酬を決定する。例えば、ＣＰＵ２１は、防御側ユーザの防御ポイントの現在値が低いほど少ない報酬を決定することができる。例えば、防御側ユーザの防御ポイントの現在値に比例する強化ポイントを報酬として決定することができる。
なお、防御側ユーザが勝利した場合に防御側ユーザに付与する報酬については、攻撃側ユーザの攻撃ポイントの現在値に基づいて同様に決定してもよいし、攻撃側ユーザの攻撃ポイントの現在値によらずに一律に決定してもよい。

対応付け手段６０は、攻撃ポイントの現在値及び防御ポイントの現在値をユーザに対応付ける機能を有する。攻撃ポイントの現在値及び防御ポイントの現在値は、対戦処理において減少し、対戦処理能力が制限される対戦処理用パラメータの一例である。対応付け手段６０の機能は、例えば以下のようにして実現される。

ＣＰＵ２１は、一定時間（例えば、２分）経過するごとに、ユーザデータベースにアクセスし、各ユーザの攻撃Ｐ及び防御Ｐの現在値が最大値であるか否かを判定し、最大値でなければ１を加算する。
また、ＣＰＵ２１は、対戦処理が行われると、ユーザデータベースにアクセスし、攻撃側ユーザのユーザＩＤに対応する攻撃Ｐ（ポイント）の現在値を、攻撃側ユーザが対戦処理において使用したカードの使用コストの合計値に応じて減少させる。例えば、攻撃側ユーザの攻撃ポイントの現在値が５０であり、攻撃側ユーザが対戦処理において使用したカードの使用コストの合計値が３０であれば、対戦処理後の攻撃側ユーザの攻撃ポイントの現在値を２０に書き換える。なお、使用コストの合計値の所定の割合（例えば５０％）の値を攻撃ポイントの現在値から減少させてもよい。
また、ＣＰＵ２１は、防御側ユーザのユーザＩＤに対応する防御Ｐ（ポイント）の現在値を、所定の減少率で減少させる。例えば、所定の減少率が２０％の場合、防御側ユーザの防御ポイントの現在値が５０であれば、対戦処理後の防御側ユーザの防御ポイントの現在値を４０に書き換える。なお、所定の値（例えば５ポイント）を防御ポイントの現在値から減少させてもよい。

本変形例における決定手段５４は、防御側ユーザの防御ポイントの現在値に基づいて、攻撃側ユーザが勝利した場合に付与する報酬を決定する機能を備える。決定手段５４の機能は、例えば以下のようにして実現される。
ＣＰＵ２１は、ユーザデータベースにアクセスし、防御側ユーザの防御ポイントの現在値を取得する。次に、ＣＰＵ２１は、防御ポイントの現在値に基づいて報酬を決定する。例えば、ＣＰＵ２１は、防御側ユーザの防御ポイントの現在値が小さいほど少ない報酬を決定することができる。例えば、防御側ユーザの防御ポイントの現在値に比例する強化ポイントを報酬として決定することができる。あるいは、防御側ユーザの防御ポイントの現在値に比例する数のアイテムを報酬として決定してもよい。例えば、防御ポイントの現在値が２０未満であればアイテムなし、防御ポイントの現在値が２０以上４０未満であればアイテム１つ、防御ポイントの現在値が４０以上６０未満であればアイテム２つ、防御ポイントの現在値が６０以上であればアイテム３つを報酬として決定してもよい。
また、決定手段５４は、攻撃側ユーザが仲間に対戦処理への参加を要請し、要請先ユーザが対戦処理に参加して勝利した場合に付与する報酬についても、防御側ユーザの防御ポイントの現在値に基づいて決定してもよい。

本変形例における第１提示手段５６は、攻撃側ユーザにより対戦相手（防御側ユーザ）として選択されるユーザのリストを、防御側ユーザの防御ポイントの現在値に関する情報又は攻撃側ユーザに付与される報酬に関する情報とともに攻撃側ユーザに対戦処理前に提示する機能を備える。第１提示手段５６の機能は、例えば以下の通り実現される。

ＣＰＵ２１は、図８のトップページＰ１上でユーザ（攻撃側ユーザ）によりメニューｍ２が選択されたことを認識すると、他のユーザから防御側ユーザとなるユーザを決定する。次に、ＣＰＵ２１は、ユーザデータベースにアクセスし、決定した防御側ユーザの防御ポイントの現在値を取得する。次に、ＣＰＵ２１は、取得した防御ポイントの現在値に基づく情報、又は、決定した攻撃側ユーザに付与される報酬に関する情報とともに、攻撃側ユーザにより対戦相手として選択されるユーザのリストを含むウェブページＰ４のＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。
例えば、防御側ユーザの防御ポイントの現在値に基づく情報は、防御ポイントの現在値を明示する情報（例えば、「防御Ｐ：２０」等）であってもよいし、防御ポイントの現在値を暗示する情報であってもよい。
例えば、防御ポイントの現在値が２０未満であれば星なし、防御ポイントの現在値が２０以上４０未満であれば星１つ、防御ポイントの現在値が４０以上６０未満であれば星２つ、防御ポイントの現在値が６０以上であれば星３つの画像情報を提示することで対戦履歴を暗示してもよい。あるいは、防御側ユーザの連敗回数が３回以上であれば星なし、連敗回数が２回であれば星１つ、連敗回数が１回であれば星２つ、連敗回数が０であれば星３つの画像情報を提示することで対戦履歴を暗示してもよい。あるいは、敗北回数が１００回以上であれば星なし、５０回以上１００回未満であれば星１つ、２０回以上５０回未満であれば星２つ、２０回未満であれば星３つの画像情報を提示することで対戦履歴を暗示してもよい。
また、報酬に関する情報は、例えば、報酬を明示する情報（例えば、アイテム名、「１０００強化ポイント」等）であってもよいし、報酬を暗示する情報であってもよい。
例えば、報酬が１０００強化ポイントであれば星１つ、２０００強化ポイントであれば星２つ、３０００強化ポイントであれば星３つの画像情報を提示することで対戦履歴を暗示してもよい。
あるいは、報酬がアイテム１つであれば星１つ、アイテム２つであれば星２つ、アイテム３つであれば星３つの画像情報を提示することで対戦履歴を暗示してもよい。

本変形例においても、図１２のフローチャートと同様に対戦処理が行われる。なお、本変形例では、図１２のフローチャートのステップＳ２１０において、攻撃側ユーザに付与する報酬を決定するとき、ＣＰＵ２１は、防御側ユーザの防御ポイントの現在値に基づいて報酬を決定する。なお、ステップＳ２０８で判定された、対戦結果が反映された防御ポイントの現在値に基づいて報酬を決定してもよいし、ステップＳ２０８で判定された対戦結果が反映される前の防御ポイントの現在値に基づいて報酬を決定してもよい。
また、本変形例では、図１２のフローチャートのステップＳ２１４において、防御側ユーザに付与する報酬を決定するとき、ＣＰＵ２１は、攻撃側ユーザの攻撃ポイントの現在値に基づいて報酬を決定する。なお、防御側ユーザが勝利した場合の報酬を一律に設定してもよい。

本変形例に係るゲームでは、防御側ユーザが短期間に連続して対戦相手として選択されると、防御ポイントが急激に減少してしまい、防御側ユーザのチームを構成するカードが少なくなり、連続して敗北するおそれがある。
本変形例においては、防御ポイント対戦処理用パラメータが減少して対戦処理能力が制限されるユーザに勝利したときに得られる報酬を減らすことで、特定のユーザが連続して対戦相手として選択されることを回避することができる。
なお、第２提示手段５９において、第１提示手段５６と同様に、防御側ユーザの防御ポイントの現在値に基づく情報を提示してもよい。

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

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

本発明に係るゲーム制御装置は、ユーザの通信端末上でゲームを表示するために当該通信端末との間で無線又は有線による通信を確立できるサーバ等の情報処理装置であってもよい。
上述した各実施形態では、ネットワーク上のゲームサーバ２０及びデータベースサーバ３０によって、実行手段５１、対戦処理手段５２、記憶手段５３、決定手段５４、報酬付与手段５５、第１提示手段５６の各機能を実現する構成としたが、この構成に限られない。これらの少なくとも一部の手段を通信端末１０によって実現する構成としてもよい。通信端末１０とゲームサーバ２０とでは実質的に同一のハードウエア構成を採ることができるため、上記各実施形態に記載したようにして通信端末１０によっても一部の機能を実現できる。例えば、図２０Ａ、図２０Ｂに、図１０に示した機能ブロック図の各機能について、通信端末１０と、ゲームサーバ２０及びデータベースサーバ３０との機能分担の例を示す。また、上述した各実施形態では、各種データ（例えば、カードデータベース、ユーザ毎の登録テーブルなど）をデータベースサーバ３０（ゲームデータベース３２）が記憶している構成としたが、その一部を通信端末１０内の記憶装置に記憶させてもよい。その場合には、記憶装置は、通信端末１０内のＲＡＭ１３や図示しないＨＤＤ(Hard Disk Drive)などの大容量記憶装置であってよい。

上述した実施形態では、ユーザ間の対戦ゲームがネットワーク上のサーバを介して実現される場合について説明したが、この場合に限られない。サーバを用いずに直接ユーザ端末間で行われる通信方式、例えばＰ２Ｐ(Peer to Peer)や無線アドホックネットワークによる通信を利用して、ユーザ間の対戦ゲームを実現してもよい。

１０…通信端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１４…画像処理部
１５…指示入力部
１６…表示部
１７…通信インタフェース部
１８…バス
２０…ゲームサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…データベースアクセス部
２５…通信インタフェース部
２６…バス
３０…データベースサーバ
３１…ユーザデータベース
３２…ゲームデータベース
５１…実行手段
５２…対戦処理手段
５３…記憶手段
５４…決定手段
５５…報酬付与手段
５６…第１提示手段
５７…関連付け手段
５８…要請手段
５９…第２提示手段
６０…対応付け手段

Claims (5)

1. 複数のユーザのそれぞれを識別するためのユーザ識別情報に対応付けられたユーザ情報を記憶する記憶装置にアクセス可能であり、かつ、複数のユーザ同士を対戦させる処理である対戦処理を実行するゲーム制御装置であって、
   対戦処理前に、第１ユーザの指示に応じて、前記第１ユーザの対戦相手の候補である複数の候補ユーザに関する情報と、前記対戦処理において前記第１ユーザが前記候補ユーザに勝利した場合に前記第１ユーザに付与される報酬の量に関する情報とを含む候補ユーザリストを、前記第１ユーザに提示する第１提示手段と、
   前記第１ユーザの指示に応じて、前記候補ユーザの中から、前記対戦処理において前記第１ユーザの対戦相手となる第２ユーザを識別するためのユーザ識別情報を選択する選択手段と、
   前記第１ユーザを識別するためのユーザ識別情報に対応付けられたユーザ情報と、前記選択手段によって選択されたユーザ識別情報に対応付けられたユーザ情報と、を参照して、前記第１ユーザと前記第２ユーザとの対戦処理を実行する対戦処理手段と、
   前記対戦処理において前記第１ユーザが勝利した場合、前記第１ユーザを識別するためのユーザ識別情報に、前記第１ユーザに付与する報酬を示す情報を対応付けて記憶する報酬付与手段と、を備え、
   前記第１提示手段は、前記候補ユーザリストに含まれる前記複数の候補ユーザのそれぞれについて、前記候補ユーザに関する情報と、前記候補ユーザに勝利した場合に前記第１ユーザに付与される前記報酬の量に関する情報との組み合わせを、前記第１ユーザが識別可能な表示態様で提示すると共に、前記報酬の量に関する情報を、前記第１ユーザが前記複数の候補ユーザ間で比較可能な表示態様で提示し、
   前記報酬の量に関する情報は、前記報酬の量を暗示する情報である、
   ゲーム制御装置。
2. 前記第１提示手段は、前記対戦処理において前記第１ユーザが勝利した場合に前記第１ユーザに付与されることになる報酬の量が多い候補ユーザを前記第１ユーザが識別できるよう、前記複数の候補ユーザの報酬の量に関する情報を１つの画面で前記第１ユーザに提示する、請求項１に記載のゲーム制御装置。
3. 前記報酬の量に関する情報は、前記候補ユーザ毎に所定の条件に基づいて決定される、
   請求項１または２に記載のゲーム制御装置。
4. 複数のユーザのそれぞれを識別するためのユーザ識別情報に対応付けられたユーザ情報を記憶する記憶装置にアクセス可能であり、かつ、複数のユーザ同士を対戦させる処理である対戦処理を実行するコンピュータを、請求項１〜３のいずれかに記載のゲーム制御装置の各手段として機能させるためのプログラム。
5. 複数の通信端末と、当該通信端末からアクセスされるサーバとを含むゲームシステムであって、
   請求項１〜３のいずれかに記載のゲーム制御装置の各手段を、前記通信端末または前記サーバのいずれか一方が備えた、ゲームシステム。

Images