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

Abstract

【課題】ユーザを引きつける誘引力のあるゲームを実現できるようにしたゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供する。
【解決手段】本発明のゲーム制御装置は、第１イベント及び第２イベントが設けられたゲームの実行を制御する。このゲーム制御装置は、ユーザの入力情報に基づいて前記第１イベント又は前記第２イベントのいずれかを発生させる手段であって、所定の確率で前記第２イベントを発生させる発生手段と、ユーザの入力情報に基づいて前記第１イベントが発生した場合に、前記第１イベントにおけるユーザによるゲームの実行状況に応じて前記所定の確率を変動させる変動手段と、を備える。
【選択図】図１２

Description

本発明は、複数のユーザ間での移転対象となるオブジェクトを検索するときの技術に関する。

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

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

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

従来のゲームでは、ユーザの入力に基づきゲームが進行していく中で、例えば他のユーザとの対戦などを行うイベントが発生するものが知られている。このようなイベントは、例えば、ゲームを実行させるサーバの制御によって発生するようになっているため、ユーザから見た場合、当該イベントが偶発的に発生したような感覚が得られる。この場合、ユーザは、例えばイベントに対するモチベーションが特に高くない状態であっても、当該イベントにおけるゲームを実行しなければならない場合がある。したがって、従来のゲームでは、他のユーザと対戦を行うという要素を組み込む一方で、遊戯性という観点においてはユーザを引きつける誘引力に乏しいものとなっていた。これは、イベントが他のユーザとの対戦である場合に限られず、他の種類のイベントが発生する場合においても同様である。

本発明は上述した観点に鑑みてなされたもので、ユーザを引きつける誘引力のあるゲームを実現できるようにしたゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供することを目的とする。

本発明の第１の観点は、第１イベント及び第２イベントが設けられたゲームの実行を制御するゲーム制御装置である。
当該ゲーム制御装置は、
ユーザの入力情報に基づいて前記第１イベント又は前記第２イベントのいずれかを発生させる手段であって、所定の確率で前記第２イベントを発生させる発生手段（５４）と、
ユーザの入力情報に基づいて前記第１イベントが発生した場合に、前記第１イベントにおけるユーザによるゲームの実行状況に応じて前記所定の確率を変動させる変動手段（５５）と、
を備える。

このゲーム制御装置によれば、ユーザは、自らの入力によって、第１イベント又は第２イベントのいずれかを発生させることができる。ここで、例えば、第１イベントとしてはコンピュータとの対戦、第２イベントとしては他のユーザとの対戦とすることができる。また、第２イベントは所定の確率で発生するが、ユーザは、第１イベントにおける自らのゲームの実行状況によって当該所定の確率を変動させることが可能となる。ここで、例えば第１イベントにおけるユーザによるゲームの実行状況が進行するほど所定の確率が増加する場合には、ユーザが第１イベントにおけるゲームを進行させるほど、第２イベントが発生し易くなる。このため、例えば第２イベントがユーザにとって有利になり得るイベントである場合には、ユーザは、当該第２イベントが発生する確率を高めようと動機付けられ、第１イベントにおけるゲームを積極的に進行させることになる。このように、本構成によれば、第１イベントの実行状況によって、第２イベントの発生確率を変動できることから、ユーザは、自らの意思で第２イベントの発生に間接的に関与できることとなり、目的達成を図る面白さのあるゲームを実現することができる。また、ユーザは、目的達成を図るために、ゲームを継続して実行することが動機付けられるため、ユーザを引きつける誘引力のあるゲームを実現することができる。

上記ゲーム制御装置において、前記第２イベントにおける前記ユーザによるゲームの実行状況に応じて、前記ユーザに対して特典を付与する付与手段（５６）を備えてもよい。
このゲーム制御装置によれば、ユーザは、第２イベントが発生した場合、当該第２イベントにおけるゲームの実行状況に応じて特典を得ることができる。このため、ユーザは、特典を得るために、第１イベントを継続的に実行して第２イベントを発生させ易くすることが動機付けられる。

上記ゲーム制御装置において、前記変動手段（５５）は、時間の経過に伴って、前記所定の確率を低減してもよい。
このゲーム制御装置によれば、第２イベントの発生確率（所定の確率）が時間の経過に伴って低減する。このため、ユーザは、所定の確率が高い間に第２イベントを発生させることが動機付けられる。例えば、ユーザが第１イベントを積極的に実行することにより第２イベントの発生確率を一時的に高くしたとしても、そのまま放置した場合には第２イベントの発生確率が時間の経過に伴って低減することになる。したがって、ユーザは、継続的に第１イベントを実行することがもとめられる。また、本構成によれば、所定の確率が高い間、ユーザをゲームに集中させることができる。

上記ゲーム制御装置において、前記第２イベントが、第１ユーザの入力情報に基づいて、第１ユーザと第１ユーザ以外の他のユーザとを関連付けてゲームを実行するイベントである場合に、前記付与手段（５６）は、前記第２イベントにおいて、第１ユーザを同一のユーザと関連付けてゲームを実行した回数あるいは頻度に応じて、前記第１ユーザに付与する特典を変動させてもよい。
例えば、第２イベントにおいて第１ユーザが同一のユーザと関連付けてゲームを実行した回数あるいは頻度が多いほど、第１ユーザに付与される特典が大きくなるようにしてもよい。ここで、第１ユーザが同一のユーザと関連付けてゲームを実行することは、例えば、第１ユーザが同一のユーザとゲーム上の対戦を行うことであってもよい。この場合、第１ユーザと同一のユーザとの対戦回数あるいは対戦頻度が多いほど、第１ユーザが当該対戦で勝利したときに獲得できる特典をより大きくするという構成を採ることが可能となる。したがって、第１ユーザは、大きな特典を得るために、第２イベントにおいて同一のユーザと関連付けてゲームを実行することが動機付けられる。このとき、第１ユーザは、同一のユーザと関連付けてゲームを実行することにより、当該同一のユーザに対して親近感が生じ得ることから、ゲームを通じてユーザ間の交流を促進する仕組みとすることができ、ゲームのソーシャル性を向上させることができる。

上記ゲーム制御装置において、前記第１ユーザと関連付けてゲームを実行済みの複数の第２ユーザに関する情報を、前記第１ユーザと対応付けて記憶装置に記憶させる記憶手段（５９）と、前記第２イベントが発生した場合に、前記記憶装置を参照して、前記複数の第２ユーザの中から前記第１ユーザと関連付けて前記第２イベントにおけるゲームを実行する第２ユーザを選択する選択手段（６０）とを備え、前記記憶装置に記憶させる第２ユーザの数の上限が設定されてもよい。
この構成は、例えば、第２イベントにおいて第１ユーザが同一のユーザと関連付けてゲームを実行した回数あるいは頻度が多いほど、第１ユーザに大きな特典が付与されることによって、第１ユーザが大きな特典を得ることができる機会を増やすという面白みのあるゲームを実現するためのものである。すなわち、このゲーム制御装置によれば、第１ユーザが第２イベントを発生させた場合に、当該第１ユーザと関連付けて当該第２イベントにおけるゲームを実行する第２ユーザは、既に第１ユーザと関連付けて第２イベントにおけるゲームを実行したユーザに限定される。また、第１ユーザに対応付けられる第２ユーザの数には上限が設定されている。これにより、例えばゲームを実行する全てのユーザの中から第２ユーザが選択される場合と比べて、同一のユーザを第２ユーザとして選択する可能性が高くなる。このため、第２イベントにおいて第１ユーザが同一のユーザと関連付けてゲームを実行する回数あるいは頻度を多くすることができるため、第１ユーザは例えば大きな特典を得ることができ、且つ、第２ユーザとの関係性を高める機会が得られる。
また、このゲーム制御装置によれば、第１ユーザと関連付けて当該第２イベントにおけるゲームを実行する第２ユーザの選択範囲を限定することができるので、第２ユーザの選択に係る処理負荷を低減することができる。

上記ゲーム制御装置において、前記複数の第２ユーザのうち所定の条件を満たす第２ユーザに関する情報を前記記憶装置から消去する消去手段（６１）を備えてもよい。
ここで、「所定の条件」とは、ゲームの実行に関するものであれば如何なる条件であってもよいが、例えば、第１ユーザと関連付けてゲームを実行した回数あるいは頻度が所定の閾値に達したことであってもよいし、第２イベントが例えば各ユーザのそれぞれに対応付けられたパラメータに基づいて当該各ユーザ間の対戦を行うイベントである場合には、第１ユーザとの間におけるパラメータの差の絶対値が所定値以上に達したことであってもよい。
このゲーム制御装置によれば、所定の条件を満たす第２ユーザに関する情報が消去されることにより、第１ユーザは、選択手段によって新たに選択された第２ユーザと関連付けて第２イベントにおけるゲームを実行することが可能となる。このため、第１ユーザにとっては、自身と関連付けてゲームを実行した第２ユーザの総数を増やすことができるので、ユーザ間で幅の広い交流を促進するゲームを実現することができる。

上記ゲーム制御装置において、前記所定の確率に関する情報を前記ユーザに提示する提示手段（５３）を備えてもよい。
このゲーム制御装置によれば、ユーザは、所定の確率に関する情報が提示されることによって、第２イベントの発生確率を認識することができる。このため、ユーザが入力を行う際に、第２イベントが発生するか否かを当該ユーザに期待させる仕組みとすることができる。

上記ゲーム制御装置において、前記発生手段（５４）によるイベントの発生回数を所定値以下に制限する制限手段（５７）を備えてもよい。
例えば、所定の単位時間（例えば１時間）内のイベントの発生回数が所定値以下に制限されてもよい。この場合、ユーザは、ある単位時間内で第２イベントが発生しない場合であっても、それ以降の単位時間内で第２イベントを発生させるようにゲームを実行することが動機付けられる。これにより、例えば、ユーザを、単位時間が経過するごとに連続してゲームに引きつけることができる。
また、例えばイベントが無制限に発生する場合には、複数のユーザの各々が第２イベントを発生させるために集中してゲームを実行することにより、ゲーム制御装置の処理負荷が高くなる場合がある。そこで、イベントの発生回数を所定値以下に制限することにより、複数のユーザが集中してゲームを実行することに基づくゲーム制御装置の過負荷を抑制することができる。

本発明の第２の観点は、第１ユーザとコンピュータとの間で対戦を行う第１イベント、及び前記第１ユーザと第２ユーザとの間で対戦を行う第２イベントが設けられたゲームの実行を制御するゲーム制御装置である。
当該ゲーム制御装置は、
前記第１ユーザの入力情報に基づいて前記第１イベント又は前記第２イベントのいずれかを発生させる手段であって、所定の確率で前記第２イベントを発生させる発生手段（５４）と、
前記第１ユーザの入力情報に基づいて前記第１イベントが発生した場合に、前記第１イベントにおける前記第１ユーザによるゲームの実行状況に応じて前記所定の確率を増加させる手段であって、時間の経過に伴って前記所定の確率を低減する変動手段（５５）と、
を備える。

このゲーム制御装置によれば、ユーザは、自らの入力によって、第１イベント又は第２イベントのいずれかを発生させることができる。また、第２イベントは所定の確率で発生するが、ユーザは、第１イベントにおける自らのゲームの実行状況（例えば、コンピュータとの対戦結果）によって当該所定の確率を変動させることが可能となる。ここで、例えば第１イベントにおいてユーザがコンピュータとの対戦に勝利するほど所定の確率が増加する場合には、ユーザが第１イベントにおいて対戦に勝利するほど、第２イベントが発生し易くなる。このため、例えば第２イベントにおいてユーザが他のユーザとの対戦に勝利することにより、ユーザがゲームの進行上有利になる場合には、ユーザは、第１イベントにおいて対戦に勝利することによって、ゲームの進行上有利になる可能性を高めることができる。これにより、ユーザは、ゲームを継続して実行することが動機付けられるため、ユーザを継続して引きつけるゲームを実現することができる。
また、このゲーム制御装置によれば、第２イベントの発生確率（所定の確率）が時間の経過に伴って低減する。このため、ユーザは、所定の確率が高い間に第２イベントを発生させることが動機付けられる。これにより、所定の確率が高い間、ユーザをゲームに集中させることができる。

本発明の第３の観点は、第１イベント及び第２イベントが設けられたゲームの実行を制御するゲーム制御方法である。
当該ゲーム制御方法は、
ユーザの入力情報に基づいて前記第１イベント又は前記第２イベントのいずれかを発生させるステップであって、所定の確率で前記第２イベントを発生させるステップと、
ユーザの入力情報に基づいて前記第１イベントが発生した場合に、前記第１イベントにおけるユーザによるゲームの実行状況に応じて前記所定の確率を変動させるステップと、
を備える。

本発明の第４の観点は、第１イベント及び第２イベントが設けられたゲームの実行を制御するプログラムであって、
コンピュータに、
ユーザの入力情報に基づいて前記第１イベント又は前記第２イベントのいずれかを発生させる機能であって、所定の確率で前記第２イベントを発生させる機能、及び
ユーザの入力情報に基づいて前記第１イベントが発生した場合に、前記第１イベントにおけるユーザによるゲームの実行状況に応じて前記所定の確率を変動させる機能、
を実現させるためのプログラムである。

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

本発明の第５の観点は、通信端末（１０）と、当該通信端末（１０）からアクセスされるサーバ（２０）とを含み、第１イベント及び第２イベントが設けられたゲームの実行を制御するゲームシステムであって、
ユーザの入力情報に基づいて前記第１イベント又は前記第２イベントのいずれかを発生させる手段であって、所定の確率で前記第２イベントを発生させる発生手段（５４）、
ユーザの入力情報に基づいて前記第１イベントが発生した場合に、前記第１イベントにおけるユーザによるゲームの実行状況に応じて前記所定の確率を変動させる変動手段（５５）、
の各手段を、前記通信端末（１０）又は前記サーバ（２０）のいずれか一方が備える。

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

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

本発明のゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムによれば、ユーザ引きつける誘引力のあるゲームを実現することができる。

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

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

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

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

また、ここでは詳しく述べないが、本実施形態のゲームは、例えばユーザがゲーム上保有するモンスターカードにおいて、当該ユーザのチームに含まれるモンスターカードと、それ以外のモンスターカード（つまり、当該ユーザのチームに含まれないモンスターカード）との交替等を実行するための編成処理を含んでもよい。

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

以下の説明では、ユーザデータベース３１に含まれるユーザＩＤごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、以下のとおりである。
・ユーザ名／表示画像
ゲームの実行時に通信端末１０のユーザを特定するために表示されるユーザ名及び表示画像である。ユーザ名はユーザによって予め指定される所定長以下のテキストであり、表示画像は例えばユーザによって予め選択されるアバタ画像である。ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
・進行レベル
ゲーム上のユーザの進行レベルを示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値であり、例えば、クエスト処理が継続的に実行されることで、順次進行レベルが上がるように構成される。
・体力ポイント
クエスト処理を実行する上で必要となるポイントである。体力ポイントは、探索を行う度に低減し、所定の時間が経過する毎に回復（増加）する値である。
・勝利ポイント
ユーザが、対戦処理においてコンピュータ又は他のユーザのチームとの対戦に勝利することにより取得したポイントである。このゲームでは、ユーザの勝利ポイントの合計が予め設定された所定値に達するごとに、当該ユーザに対してゲーム上の特典が付与されるようになっている。
・仲間のユーザＩＤ
例えば仲間になるための申請などを契機として、ユーザと関連付けられた他のユーザ（仲間）のユーザＩＤのリストである。
・保有カードのデータ
ユーザがゲーム上保有するモンスターカードのデータである。モンスターカードのデータの内容については後述する。

図５に戻り、ゲームデータベース３２は、ゲームサーバ２０からのアクセスに基づき、ゲームサーバ２０によって実行されたゲームの進行に関する情報を記憶、更新する。ゲームの進行に関する情報は、ゲームの性質によって多様な情報を含みうる。本実施形態のゲームの場合を例に挙げれば、ゲームの進行に関する情報は、例えば対戦結果についての情報（例えば勝敗等）などを含む。
また、ゲームデータベース３２は、上述した各種処理に関連して、モンスターカードデータベース及びイベントデータを記憶する。

モンスターカードデータベースは、本実施形態のゲームで用意される全てのモンスターカード（オブジェクト）の情報が記述されているデータベースである。なお、ここでは、オブジェクトの一例としてモンスターカードを挙げるが、オブジェクトは、ゲーム上の使用対象あるいは操作対象などになり得るオブジェクトであれば如何なるものでもよく、例えばゲーム上のアイテムやキャラクタを含んでもよい。キャラクタとは、例えば現実世界に存在するもの（例えばスポーツ選手や歌手、アイドル、動物等）を模したものや、ゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカードに表示されているものやフィギュアになっているものをも含む。
図７は、モンスターカードデータベースのデータ構成の一例を示す図である。図７に例示するモンスターカードデータベースは、モンスターカードの識別コード（図の例では、ＭＣ００１，ＭＣ００２，…）ごとに、対象となるモンスターカードの画像データ（画像）、対象となるモンスターの名前（モンスター名）及び対象となるモンスターカードの属性（図の例では、攻撃力や防御力などのモンスターの能力を示すパラメータ及びレア度）の各項目のデータを含む。例えば、攻撃力や防御力などのパラメータが大きいほど、モンスターカードに対応するモンスターの能力が高いことを示すように設定されてもよい。
また、レア度は、モンスターカードの希少価値の度合を示す値であり、例えば、その値が高い（つまり、希少価値が高い）ほど、ゲーム内で出現する確率が低く設定されてもよい。例えば、レア度を１〜５の５段階で表した場合、能力の際立ったモンスターや人気のあるモンスターに対応するモンスターカードのレア度が高く（例えば、４あるいは５など）設定されてもよい。
なお、属性は、例えば、オブジェクトの特徴や性質などを示す情報であってもよいし、オブジェクトの特徴や性質などを分類するための情報であってもよい。例えば、野球ゲームの場合、属性には、ゲーム上の選手（オブジェクト）のチームや、ポジション（例えば投手、捕手、一塁手、左翼手など）などが含まれてもよい。

イベントデータは、対戦（イベント）に関する情報がユーザごとに記述されているデータである。イベントデータのデータ構成例を図８に示す。図８に示すイベントデータは、ユーザ（ユーザＩＤ）ごとに、ユーザ間対戦の発生確率と、イベントの抽選権利回数とが含まれる。
ユーザ間対戦の発生確率は、対戦処理においてユーザ間対戦が発生する確率である。本実施形態のゲームでは、ユーザ間対戦の発生確率は、ＣＯＭ対戦の結果に応じて変動し得る。
イベントの抽選権利回数は、対戦処理においてイベント（つまり、ＣＯＭ対戦又はユーザ間対戦のいずれか）が発生する回数である。イベントの抽選権利回数は、上限値（例えば、５）が設定されていてもよい。本実施形態のゲームでは、イベントの抽選権利回数は、対象となるユーザがイベントを発生させたときに１つ減少し、所定時間（例えば１時間）が経過するごとに１つ増加するようになっている。なお、イベントの抽選権利回数は、例えばユーザの進行レベルが１つ上昇したときや、所定のアイテムを使用したときなどに上限値まで増加するようにしてもよい。

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

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

先ず、クエスト処理の一例を説明する。図９のトップページＰ１上でメニューｍ１が選択操作されると、クエスト処理の実行が開始され、Ｐ２に示すようにウェブページが更新される。ウェブページＰ２には、探索の対象となるエリア（図の例では、エリア４）の進行度合いを示す達成率のゲージと、探索処理を実行するための「クエスト実行」と表記されたメニューｍ１０と、１回の探索に要する体力ポイントの値（図の例では８ポイント）などが含まれる。
メニューｍ１０がユーザ：ＡＢＣによって選択操作される度に一定の、あるいはランダムな増加量で達成率の値が増加する。そして、達成率が１００％に達すると、エリアの探索が終了して次のエリアに進むことができる。メニューｍ１０が選択操作される度に、ユーザ：ＡＢＣの体力ポイントが所定量（図９の例では、８）だけ消費される。探索対象のエリアは、複数設けられてもよい。なお、クエスト処理では、メニューｍ１０が選択操作される度に、所定の、あるいはランダムな確率で、ゲーム上で用意されているモンスターカードあるいはアイテムなどのオブジェクトをユーザが入手できるように構成されている。

なお、ウェブページＰ２においてメニューｍ１０の選択操作を繰り返し行うと、上述したように体力ポイントが低下していくが、体力ポイントが１回の探索に要する体力ポイント（例えば８）よりも少なくなると、それ以上探索の実行ができない状態となる。その場合、ユーザが再び探索を実行できるようになるには、時間の経過によって体力ポイントが回復（増加）するまで待機することが必要となる。

次に、対戦処理の一例を説明する。図１０のトップページＰ１上でメニューｍ２が選択操作されると、対戦処理の実行が開始され、Ｐ３に示すようにウェブページが更新される。ウェブページＰ３には、ユーザ：ＡＢＣが保有する勝利ポイント（図の例では、３０００）と、対戦相手のチームの抽選を行うための「対戦チーム抽選」と表記されたメニューｍ２０と、ユーザ：ＡＢＣのイベントの抽選権利回数を表すマーク（図の例では、５つの星のマークＳＴ）と、ユーザ：ＡＢＣのユーザ間対戦の発生確率を示すゲージなどが含まれる。
イベントの抽選権利回数が１以上（図の例では、星のマークＳＴの数が１つ以上）の場合に、ユーザ：ＡＢＣがメニューｍ２０（「対戦チーム抽選」）を選択操作すると、ＣＯＭ対戦あるいはユーザ間対戦のいずれかのイベントが発生する。ここで、ウェブページＰ３に示す例では、ユーザ間対戦の発生確率は５０％である。

次に、ウェブページＰ３上でメニューｍ２０（「対戦チーム抽選」）が選択操作されたときにＣＯＭ対戦が発生した場合におけるゲームの流れの一例を説明する。ＣＯＭ対戦が発生した場合、Ｐ４に示すようにウェブページが更新される。ウェブページＰ４には、対戦相手（つまり、コンピュータ）の表示画像とともに、対戦開始を指示するための「対戦開始」と表記されたメニューｍ２１などが含まれる。ウェブページＰ４上でユーザ：ＡＢＣがメニューｍ２１（「対戦開始」）の選択操作を行うと、ユーザ：ＡＢＣのチームとコンピュータのチームとの間で対戦（ＣＯＭ対戦）が行われる。
ＣＯＭ対戦が終了すると、対戦の結果を通知するウェブページ（Ｐ５に例示するウェブページ）がユーザ：ＡＢＣの通信端末１０上に表示される。なお、ウェブページＰ５は、ユーザ：ＡＢＣがＣＯＭ対戦に勝利した場合に通信端末１０の表示部１６に表示されるウェブページの一例を示している。このゲームでは、ユーザ：ＡＢＣがＣＯＭ対戦に勝利すると、所定量の勝利ポイント（図の例では１００）が特典としてユーザ：ＡＢＣに付与されるとともに、ユーザ：ＡＢＣのユーザ間対戦の発生確率が所定値（図の例では１０％）だけ増加するようになっている。
なお、ユーザ：ＡＢＣがＣＯＭ対戦で敗北した場合、ユーザ：ＡＢＣのユーザ間対戦の発生確率は変動しなくてもよいし、所定値（例えば５％）だけ低減してもよい。

ウェブページＰ５がユーザ：ＡＢＣの通信端末１０に表示されてから所定時間経過すると、Ｐ６に示すようにウェブページが更新される。ウェブページＰ６の構成は、ウェブページＰ３の構成と同様である。ウェブページＰ６では、ユーザ：ＡＢＣがＣＯＭ対戦に勝利したことにより、勝利ポイントの値及びユーザ間対戦の発生確率が所定値だけ増加した状態で表示される。また、ウェブページＰ６では、ＣＯＭ対戦が発生したことにより、イベントの抽選権利回数を表す星のマークＳＴの数が１つ減少している。

次に、ウェブページＰ３上でメニューｍ２０（「対戦チーム抽選」）が選択操作されたときにユーザ間対戦が発生した場合におけるゲームの流れの一例を説明する。ユーザ間対戦が発生した場合、Ｐ７に示すようにウェブページが更新される。ウェブページＰ７には、対戦相手（つまり、他のユーザ）の表示画像とともに、対戦開始を指示するための「対戦開始」と表記されたメニューｍ２１などが含まれる。ここで、ユーザの対戦相手となる他のユーザは、例えば抽選によって決定されてもよい。ウェブページＰ７上でユーザ：ＡＢＣがメニューｍ２１（「対戦開始」）の選択操作を行うと、ユーザ：ＡＢＣのチームと他のユーザのチームとの間で対戦（ユーザ間対戦）が行われる。
ユーザ間対戦が終了すると、対戦の結果を通知するウェブページ（Ｐ８に例示するウェブページ）がユーザ：ＡＢＣの通信端末１０上に表示される。なお、ウェブページＰ８は、ユーザ：ＡＢＣがユーザ間対戦に勝利した場合に通信端末１０の表示部１６に表示されるウェブページの一例を示している。このゲームでは、ユーザ：ＡＢＣがユーザ間対戦に勝利すると、所定量の勝利ポイント（図の例では５００）と、所定のアイテム又はキャラクタ（図の例ではレア度４のモンスターカード）とが特典としてユーザ：ＡＢＣに付与されるようになっている。ここで、このゲームでは、ユーザがユーザ間対戦で勝利した場合、当該ユーザがＣＯＭ対戦で勝利したときと比べて大きな特典が当該ユーザに付与されるようになっている。つまり、ユーザは、ユーザ間対戦で勝利することによって、ゲームを有利に進めることが可能になる。また、このゲームでは、ユーザ間対戦が発生すると、ユーザ間対戦の発生確率は０％まで低減する。

ウェブページＰ８がユーザ：ＡＢＣの通信端末１０に表示されてから所定時間経過すると、Ｐ９に示すようにウェブページが更新される。ウェブページＰ９の構成は、ウェブページＰ３の構成と同様である。ウェブページＰ９では、ユーザ：ＡＢＣがユーザ間対戦に勝利したことにより、勝利ポイントの値が所定値だけ増加した状態で表示される。また、ウェブページＰ９では、ユーザ間対戦が発生したことにより、イベントの抽選権利回数を表す星のマークＳＴの数が１つ減少するとともに、ユーザ間対戦の発生確率が０％まで低減している。

このようにして、ユーザ：ＡＢＣは、メニューｍ２０を選択操作することによって、ＣＯＭ対戦又はユーザ間対戦のいずれかを発生させることができる。また、ユーザ間対戦は、ユーザ：ＡＢＣのユーザ間対戦の発生確率で発生するが、ユーザ：ＡＢＣは、ＣＯＭ対戦において勝利することによって当該発生確率を増加させることが可能となる。このため、ユーザ：ＡＢＣは、例えばユーザ間対戦が自身にとって有利になり得るイベントである場合には、ユーザは、ＣＯＭ対戦において勝利することによって、ゲームの進行上有利になる可能性を高めることができる。

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

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

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

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

クエスト処理において、ＣＰＵ２１は、メニューｍ１０に対する選択操作を認識すると、複数のモンスターカードの中から選択されたモンスターカードをユーザに付与する（対応付ける）ことを、所定の、あるいはランダムな確率で決定する。ここで、ＣＰＵ２１は、モンスターカードを付与することを決定した場合、モンスターカードを入手したことを通知するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信してもよい。ＣＰＵ２１は、複数のモンスターカードの中から選択されたモンスターカードをユーザに付与することを決定した場合には、クエスト用に予め設けられた複数のモンスターカードの中から、ユーザに対して付与されるモンスターカードを選択する。次に、ＣＰＵ２１は、選択したモンスターカードのデータをモンスターカードデータベースから読み出した後に、ユーザデータベース３１にアクセスする。そして、ＣＰＵ２１は、対象となるユーザＩＤのユーザデータ（保有カードのデータ）に対して、読み出したデータを追記する。
また、ＣＰＵ２１は、クエスト処理において、モンスターカードと同様に所定のアイテムをユーザに付与してもよい。ここで、所定のアイテムは、例えば、ユーザのイベントの抽選権利回数を上限値まで増加させるアイテムなどであってもよい。

また、実行手段５２は、対戦処理において、イベントにおけるゲームを実行する機能（本実施形態では、対戦を実行する機能）を備える。この機能は、例えば以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、ウェブページＰ４又はＰ７上でメニューｍ２１（「対戦開始」）が選択操作されたことを認識すると、処理対象のユーザ（ここでは、ユーザ：ＡＢＣ）のチームと、対戦相手（コンピュータ又は他のユーザ）のチームとの対戦結果を決定する処理を行う。
対戦結果の決定方法は、各チームに含まれるモンスターカードのパラメータの値がその勝敗に影響を与える方法である限り如何なる方法を採ることができる。例えば、対戦を行う２つのチームの各々に含まれる複数のモンスターカードのパラメータの値の合計を比較し、合計が大きな方のチームが高い確率（例えば、６０〜９０％の範囲内の所定の確率）をもって勝利するように設定してもよい。この勝率は、パラメータの値の合計の差が大きいほど高い確率としてもよい。このとき、図７に示したように、パラメータの値を示す項目が複数（図７の例では、攻撃力と防御力の２つ）存在する場合には、各モンスターカードのパラメータの値を代表する値として、各項目の値に対して所定の重み付け（例えば、図７の例では、「攻撃力」を０．４、「防御力」を０．２の重み付けにする等）を行うことにより、総合的なパラメータの値を設定してもよい。

次に、ＣＰＵ２１は、対戦の結果を決定すると、対戦結果をユーザ：ＡＢＣに通知するウェブページ（例えば、ウェブページＰ５，Ｐ８など）を表示するためのＨＴＭＬデータを生成して、ユーザ：ＡＢＣの通信端末１０に送信する。なお、ＣＰＵ２１は、後述する変動手段５５及び付与手段５６の機能に基づく処理を行った後に、ＨＴＭＬデータを生成する。

また、ＣＰＵ２１は、対戦の結果を決定した場合、イベントの抽選権利回数を更新（減少）する処理を行う。この場合、ＣＰＵ２１は、イベントデータにアクセスして、処理対象のユーザ（ここでは、ユーザ：ＡＢＣ）のユーザＩＤに対応するイベントの抽選権利回数の値を１つ減らす。
さらに、ＣＰＵ２１は、例えば所定時間（例えば１時間）が経過するごとに、イベントの抽選権利回数を更新（増加）する処理を行ってもよい。この場合、ＣＰＵ２１は、例えば所定の時刻を起点として所定時間が経過するごとにイベントデータにアクセスして、全てのユーザ（ユーザＩＤ）のイベントの抽選権利回数の値を１つ増加させる。また、ＣＰＵ２１は、例えばゲーム上で所定のアイテムが使用された場合、イベントデータにアクセスして、当該アイテムを使用したユーザのユーザＩＤに対応するイベントの抽選権利回数を上限値（例えば、５）まで増加させてもよい。

提示手段５３は、ユーザ間対戦の発生確率（所定の確率）に関する情報をユーザに提示する機能を備える。
提示手段５３をゲーム制御装置に設けることにより、ユーザは、ユーザ間対戦の発生確率に関する情報が提示されることによって、ユーザ間対戦（第２イベント）の発生確率を認識することができる。このため、ユーザが入力を行う際に、ユーザ間対戦が発生するか否かを当該ユーザに期待させる仕組みとすることができる。

提示手段５３の機能は、例えば以下のように実現される。ゲームサーバ２０のＣＰＵ２１は、トップページＰ１上でメニューｍ２（「対戦」）が選択操作されたことを認識すると、ウェブページＰ３を表示するためのＨＴＭＬデータを生成して、ユーザ：ＡＢＣの通信端末１０宛に送信する。ウェブページＰ３を表示するためのＨＴＭＬデータの生成に当たって、ＣＰＵ２１は、イベントデータにアクセスして、ユーザ：ＡＢＣのユーザＩＤに対応するユーザ間対戦の発生確率及びイベントの抽選権利回数を抽出する。また、ＣＰＵ２１は、ユーザデータベース３１にアクセスして、ユーザ：ＡＢＣのユーザＩＤに対応する勝利ポイントを抽出する。そして、ＣＰＵ２１は、抽出した情報をウェブページに含むようにＨＴＭＬデータを生成する。ここで、ユーザ間対戦の発生確率は、例えばゲージ形式で表示されてもよい。また、ＣＰＵ２１は、抽出したイベントの抽選権利回数に相当する数のマーク（ウェブページＰ３の例では星のマークＳＴ）をウェブページに含めてもよい。

また、ＣＰＵ２１は、上述した実行手段５２の機能に基づいてイベントの抽選権利回数を更新すると、ウェブページＰ６又はＰ９を表示するためのＨＴＭＬデータを生成して、ユーザ：ＡＢＣの通信端末１０宛に送信する。ウェブページＰ６又はＰ９を表示するためのＨＴＭＬデータの生成におけるＣＰＵ２１の処理内容は、ウェブページＰ３と同様である。
なお、ユーザ間対戦の発生確率に関する情報は、例えば音声データや画像データなどで構成されてもよい。

発生手段５４は、ユーザの入力情報に基づいてＣＯＭ対戦（第１イベント）又はユーザ間対戦（第２イベント）のいずれかを発生させる機能と、ユーザ間対戦の発生確率（所定の確率）で前記ユーザ間対戦を発生させる機能とを備える。
発生手段５４の機能は、例えば以下のとおり実現される。ゲームサーバ２０のＣＰＵ２１は、例えばウェブページＰ３上でメニューｍ２０（「対戦チーム抽選」）が選択操作されたことを認識すると、ＣＯＭ対戦又はユーザ間対戦のいずれかを発生させることを決定する。ここで、ＣＰＵ２１は、イベントデータにアクセスして、ユーザ：ＡＢＣのユーザＩＤに対応するユーザ間対戦の発生確率を抽出する。次に、ＣＰＵ２１は、抽出した発生確率に基づいて、ユーザ間対戦を発生させるか否かを決定する。例えば、発生確率が５０％の場合には、ＣＰＵ２１は、０．１〜１．０の範囲内で０．１間隔の乱数を発生させ、発生した数が０．５以下であったときにユーザ間対戦を発生させると決定してもよい。また、ＣＰＵ２１は、ユーザ間対戦を発生させないと決定した場合、ＣＯＭ対戦を発生させることを決定する。
また、ＣＰＵ２１は、ユーザデータベース３１にアクセスして、ユーザ：ＡＢＣのユーザＩＤに対応する保有カードのデータの中から、ユーザ：ＡＢＣのチームに含まれる複数のモンスターカードの識別コードを抽出する。そして、ＣＰＵ２１は、抽出した識別コードに対応するモンスターカードの情報をモンスターカードデータベースから取得して、ＲＡＭ２３に記録する。

ＣＰＵ２１は、ＣＯＭ対戦を発生させることを決定した場合、モンスターカードデータベースにアクセスして、例えば予め設定されたチームに含まれる複数のモンスターカードの情報（例えば、モンスターカードのパラメータなど）を抽出して、ＲＡＭ２３に記録する。次に、ＣＰＵ２１は、ウェブページＰ４を表示するためのＨＴＭＬデータを生成して、ユーザ：ＡＢＣの通信端末１０に送信する。
また、ＣＰＵ２１は、ユーザ間対戦を発生させることを決定した場合、ユーザデータベース３１にアクセスして、ユーザデータベース３１に含まれるユーザの中からユーザ：ＡＢＣの対戦相手となる他のユーザを、ランダム、あるいは所定の規則に基づき決定する。このとき、対戦相手の進行レベルは、ユーザ：ＡＢＣと同一の進行レベルであってもよい。ＣＰＵ２１は、対戦相手となる他のユーザを決定すると、当該他のユーザのユーザＩＤに対応する保有カードのデータの中から、当該他のユーザのチームに含まれる複数のモンスターカードの識別コードを抽出する。そして、ＣＰＵ２１は、抽出した識別コードに対応するモンスターカードの情報をモンスターカードデータベースから取得して、ＲＡＭ２３に記録する。次に、ＣＰＵ２１は、ウェブページＰ７を表示するためのＨＴＭＬデータを生成して、ユーザ：ＡＢＣの通信端末１０に送信する。
ＣＰＵ２１は、上述した実行手段５２の機能に基づいて、ＲＡＭ２３に記録された各チームのモンスターカードの情報を用いて対戦実行処理を行う。

なお、ここでは、第１イベントがＣＯＭ対戦であって、第２イベントがユーザ間対戦である場合を一例として説明したが、イベントは対戦に限られない。例えば、第１イベント及び第２イベントは、アイテムやキャラクタ等のオブジェクトの抽選であってもよい。この場合、第２イベントにおける抽選によってユーザが入手できるオブジェクトは、第１イベントにおける抽選によって入手できるオブジェクトよりも価値が高く設定されてもよい。
また、第１イベント及び第２イベントは、上述したスカウト処理であってもよい。この場合、第２イベントにおけるスカウト処理は、第１イベントにおけるスカウト処理と比べて、１回の探索（メニューｍ１０の選択操作）における達成率の増加量が大きく設定されてもよい。
さらに、第１イベント及び第２イベントの各々のイベントの種類は、同じであってもよいし、異なっていてもよい。例えば、第１イベントが対戦の場合、第２イベントは抽選であってもよい。

変動手段５５は、ユーザの入力情報に基づいてＣＯＭ対戦（第１イベント）が発生した場合に、前記ＣＯＭ対戦におけるユーザによるゲームの実行状況に応じてユーザ間対戦の発生確率（所定の確率）を変動させる機能を備える。
ここで、第１イベントにおけるユーザによるゲームの実行状況とは、例えば、第１イベントが対戦である場合には、当該対戦における当該ユーザの勝敗であってもよいし、当該ユーザの対戦数あるいは対戦頻度などであってもよい。また、第１イベントにおけるユーザによるゲームの実行状況とは、例えば、第１イベントが抽選である場合には、当該ユーザによって抽選が行われた数あるいは頻度であってもよいし、当該抽選において当該ユーザが入手した特定のアイテムの数などであってもよい。さらに、例えば、第１イベントが所定のルートを進行するゲームであった場合には、当該ユーザの進行度であってもよい。

変動手段５５の機能は、例えば以下のようにして実現される。なお、ここでは、ＣＯＭ対戦におけるユーザによるゲームの実行状況が、ＣＯＭ対戦における当該ユーザの勝敗である場合を一例として説明する。ゲームサーバ２０のＣＰＵ２１は、ＣＯＭ対戦においてユーザ：ＡＢＣが勝利した場合、イベントデータにアクセスして、ユーザ：ＡＢＣのユーザＩＤに対応するユーザ間対戦の発生確率を所定値（例えば１０％）だけ増加させる。
また、ＣＰＵ２１は、ＣＯＭ対戦においてユーザ：ＡＢＣが敗北した場合、イベントデータにアクセスして、ユーザ：ＡＢＣのユーザＩＤに対応するユーザ間対戦の発生確率を所定値（例えば５％）だけ減少させてもよい。
さらに、ＣＰＵ２１は、ユーザ間対戦（第２イベント）が発生した場合に、ユーザ間対戦の発生確率（所定の確率）を減少してもよい。この場合、ＣＰＵ２１は、ユーザ間対戦が発生すると、イベントデータにアクセスして、ユーザ：ＡＢＣのユーザＩＤに対応するユーザ間対戦の発生確率を所定値（例えば０％）まで減少させる。

付与手段５６は、ユーザ間対戦（第２イベント）におけるユーザによるゲームの実行状況に応じて、前記ユーザに対して特典を付与する機能を備える。
付与手段５６をゲーム制御装置に設けることにより、ユーザは、ユーザ間対戦が発生した場合、ユーザ間対戦におけるゲームの実行状況に応じて特典を得ることができる。このため、ユーザは、特典を得るために、ＣＯＭ対戦（第１イベント）を継続的に実行してユーザ間対戦を発生させ易くすることが動機付けられる。

ここで、「特典」とは、ゲーム上のポイント若しくはアイテム、又はゲーム上の有利な効果などであってよい。ここで、アイテムとは、例えば、ユーザがゲーム上で保有することができるオブジェクトであってもよいし、ユーザがゲーム上で収集することが必要なオブジェクトであってもよいし、ユーザがゲーム上で有利な効果を得られるオブジェクトなどであってもよい。例えば、アイテムは、キャラクタのパラメータやポイントなどを回復する回復薬や、キャラクタの能力を上昇させる薬品などであってもよいし、キャラクタが使用する武器や防具などであってもよい。
また、ゲーム上の有利な効果とは、例えば、ゲーム上保有するアイテムのパラメータを上昇させることであってもよいし、アイテムを用いることなくキャラクタの能力を向上させることであってもよい。また、ゲーム上の有利な効果とは、例えば、ユーザが、特殊なアイテムや希少価値の高いアイテムを入手できること、あるいはこれらのアイテムを入手できる確率を上昇させることであってもよい。さらに、ゲーム上の有利な効果とは、ゲームにおけるシナリオの進行を進め易くするように設定を調整することであってもよく、例えば、ユーザの操作などに応じて消費するゲーム上のポイントの消費量を通常よりも低減させることであってもよいし、ポイントを入手できることであってもよい。さらにまた、ゲーム上の有利な効果とは、間接的にゲームを有利に進められるようにゲーム上の設定を調整することであってもよく、例えば、ユーザが特殊なアイテムを取得可能なイベントを発生させることでもよいし、アイテムのパラメータが大幅に上昇する確率を上昇させることであってもよい。

付与手段５６の機能は、例えば以下のようにして実現される。なお、ここでは、ユーザ間対戦におけるユーザによるゲームの実行状況が、ユーザ間対戦における当該ユーザの勝敗である場合を一例として説明する。ゲームサーバ２０のＣＰＵ２１は、ユーザ間対戦においてユーザ：ＡＢＣが勝利した場合、ユーザ：ＡＢＣに対して特典を付与する処理を行う。この処理の内容は例えば以下のとおりである。なお、特典の内容は任意に設定されてもよいが、ここでは、所定量の勝利ポイントと所定のレア度のモンスターカードが特典として付与される場合を一例として説明する。ＣＰＵ２１は、先ず、ユーザデータベース３１にアクセスして、ユーザ：ＡＢＣのユーザＩＤに対応する勝利ポイントの値を所定値（例えば５００）だけ増加させる。また、ＣＰＵ２１は、モンスターカードデータベースにアクセスして、所定のレア度（例えばレア度４）のモンスターカードをランダム、あるいは所定の規則に基づいて抽出する。そして、ＣＰＵ２１は、ユーザ：ＡＢＣのユーザＩＤに対応する保有カードの項目に、抽出したモンスターカードの識別コードを追記する。
なお、ここでは、ユーザ：ＡＢＣがユーザ間対戦に勝利した場合に特典が付与される場合を一例として説明したが、この場合に限られない。例えば、ユーザ：ＡＢＣによる特殊なアイテムの取得、ユーザ：ＡＢＣによる特殊なアイテムの取得数、特定のオブジェクト（例えば、敵キャラクタなど）に対してユーザ：ＡＢＣが与えたダメージの量、あるいは、ユーザによる特定のオブジェクトの討伐数などに応じた特典がユーザ：ＡＢＣに付与されてもよい。

また、付与手段５６は、ＣＯＭ対戦（第１イベント）におけるユーザによるゲームの実行状況に応じて、前記ユーザに対して特典を付与してもよい。この場合、ユーザに付与される特典は、ユーザ間対戦（第２イベント）におけるユーザによるゲームの実行状況に応じて当該ユーザに付与される特典より小さくてもよい。
この場合における付与手段５６の機能は、例えば以下のように実現される。ゲームサーバ２０のＣＰＵ２１は、ＣＯＭ対戦においてユーザ：ＡＢＣが勝利した場合、ユーザ：ＡＢＣに対して特典を付与する処理を行う。この処理の内容について具体的に説明すると、ＣＰＵ２１は、ユーザデータベース３１にアクセスして、ユーザ：ＡＢＣのユーザＩＤに対応する勝利ポイントの値を所定値（例えば１００）だけ増加させる。この場合、勝利ポイントの増加量は、ユーザ間対戦に勝利した場合の勝利ポイントの増加量と比べて低く設定されている。また、ユーザ：ＡＢＣがＣＯＭ対戦に勝利した場合には、ユーザ：ＡＢＣに対してモンスターカードが付与されてもよいが、例えば付与されるモンスターカードのレア度は、ユーザ間対戦に勝利した場合と比べて低く設定されていることが好ましい。

制限手段５７は、発生手段５４による対戦（イベント）の発生回数を所定値以下に制限する機能を備える。
例えば、所定の単位時間（例えば１時間）内の対戦の発生回数が所定値以下に制限されてもよい。この場合、ユーザは、ある単位時間内でユーザ間対戦（第２イベント）が発生しない場合であっても、それ以降の単位時間内でユーザ間対戦を発生させるようにゲームを実行することが動機付けられる。これにより、例えば、ユーザを、単位時間が経過するごとに連続してゲームに引きつけることができる。
また、例えば対戦が無制限に発生する場合には、複数のユーザの各々がユーザ間対戦を発生させるために集中してゲームを実行することにより、ゲーム制御装置の処理負荷が高くなる場合がある。そこで、対戦の発生回数を所定値以下に制限することにより、複数のユーザが集中してゲームを実行することに基づくゲーム制御装置の過負荷を抑制することができる。

制限手段５７の機能は、例えば以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、例えば任意のタイミングでイベントデータを参照して、全てのユーザ（ユーザＩＤ）に対応するイベントの抽選権利回数の値が所定の上限値（例えば５）以下となるように調整する。例えば、上述した実行手段５２の機能に基づいて、所定時間（例えば１時間）が経過するごとにイベントの抽選権利回数が１つ増加する場合には、ＣＰＵ２１は、処理対象のユーザに対応するイベントの抽選権利回数が上限値であるときには、イベントの抽選権利回数を増加しなくてもよい。

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

先ず図１３のフローチャートにおいて、トップページＰ１上でメニューｍ１（「クエスト」）が選択操作されたことを認識すると、ゲームサーバ２０のＣＰＵ２１は、図９のＰ２に例示するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＡＢＣの通信端末１０に送信する。ＣＰＵ２１は、メニューｍ１０（「クエスト実行」）が選択操作されたことを認識すると（ステップＳ１００：ＹＥＳ）、複数のモンスターカードの中から選択されたモンスターカードをユーザ：ＡＢＣに付与することを、所定の、あるいはランダムな確率で決定する（ステップＳ１０２）。次に、ＣＰＵ２１は、モンスターカードを付与することを決定すると（ステップＳ１０２：ＹＥＳ）、ユーザ：ＡＢＣにモンスターカードを付与する処理を行う（ステップＳ１０４）。この場合、ＣＰＵ２１は、ゲームデータベース３２内のモンスターカードデータベースにアクセスし、クエスト用に予め設けられた複数のモンスターカードの中から、付与されるモンスターカードを選択する。次に、ＣＰＵ２１は、選択したモンスターカードのデータをモンスターカードデータベースから読み出した後に、ユーザデータベース３１にアクセスする。そして、ＣＰＵ２１は、ユーザ：ＡＢＣのユーザＩＤに対応する保有カードのデータに対して、読み出したデータを追記する。なお、ＣＰＵ２１は、ステップＳ１０２においてモンスターカードをユーザに付与しないことを決定した場合（ステップＳ１０２：ＮＯ）、ステップＳ１０６の処理に移行する。
ＣＰＵ２１は、ユーザ：ＡＢＣの達成率と体力ポイントとを更新し（ステップＳ１０６）、更新後の達成率を表示するＨＴＭＬデータを生成してユーザ：ＡＢＣの通信端末１０に送信する。
なお、ＣＰＵ２１は、メニューｍ１０が選択操作されずに所定時間経過した場合（ステップＳ１００：ＮＯ）、クエスト処理を終了してもよい。
また、ＣＰＵ２１は、ステップＳ１０２の処理において、ユーザ：ＡＢＣに対して所定のアイテム（例えば、ユーザの体力ポイント及びイベントの抽選権利回数を上限値まで回復させるアイテム）を、所定の、あるいはランダムな確率で付与することを決定してもよい。

次に、図１４を参照して、対戦処理を行うときのフローチャートの一例を説明する。
ＣＰＵ２１は、トップページＰ１上でメニューｍ２（「対戦」）が選択操作されたことを認識すると、Ｐ３に例示するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＡＢＣの通信端末１０に送信する。次に、ＣＰＵ２１は、ウェブページＰ３上でメニューｍ２０（「対戦チーム抽選」）が選択操作されたことを認識すると（ステップＳ２００：ＹＥＳ）、ＣＯＭ対戦又はユーザ間対戦のいずれかを発生させることを決定する（ステップＳ２０２）。

ＣＰＵ２１は、ユーザ間対戦を発生させないこと決定した場合、すなわちＣＯＭ対戦を発生させることを決定した場合（ステップＳ２０４：ＮＯ）、ＣＯＭ対戦を発生させる処理を行う（ステップＳ２０６）。具体的には、ＣＰＵ２１は、モンスターカードデータベースにアクセスして、例えば予め設定されたチームに含まれる複数のモンスターカードの情報（例えば、モンスターカードのパラメータなど）を抽出して、ＲＡＭ２３に記録する。次に、ＣＰＵ２１は、ウェブページＰ４を表示するためのＨＴＭＬデータを生成して、ユーザ：ＡＢＣの通信端末１０に送信する。

一方、ＣＰＵ２１は、ユーザ間対戦を発生させることを決定した場合（ステップＳ２０４：ＹＥＳ）、ユーザ間対戦を発生させる処理を行う（ステップＳ２０８）。具体的には、ＣＰＵ２１は、ユーザデータベース３１にアクセスして、ユーザデータベース３１に含まれるユーザの中からユーザ：ＡＢＣの対戦相手となる他のユーザを、ランダム、あるいは所定の規則に基づき決定する。このとき、対戦相手の進行レベルは、ユーザ：ＡＢＣと同一の進行レベルであってもよい。ＣＰＵ２１は、対戦相手となる他のユーザを決定すると、当該他のユーザのユーザＩＤに対応する保有カードのデータの中から、当該他のユーザのチームに含まれる複数のモンスターカードの識別コードを抽出する。そして、ＣＰＵ２１は、抽出した識別コードに対応するモンスターカードの情報をモンスターカードデータベースから取得して、ＲＡＭ２３に記録する。次に、ＣＰＵ２１は、ウェブページＰ７を表示するためのＨＴＭＬデータを生成して、ユーザ：ＡＢＣの通信端末１０に送信する。

次に、ＣＰＵ２１は、後述する対戦実行処理を行う（ステップＳ２１０）。
なお、ＣＰＵ２１は、ウェブページＰ３上でメニューｍ２０（「対戦チーム抽選」）が選択操作されない状態で所定時間が経過した場合（ステップＳ２００：ＮＯ）には、対戦処理を終了してもよい。

次に、図１５を参照して、対戦実行処理を行うときのフローチャートの一例を説明する。
ＣＰＵ２１は、ウェブページＰ４又はＰ７上でメニューｍ２１（「対戦開始」）が選択操作されたことを認識すると（ステップＳ３００：ＹＥＳ）、処理対象のユーザ（ここでは、ユーザ：ＡＢＣ）のチームと、対戦相手（コンピュータ又は他のユーザ）のチームとの対戦結果を決定する処理を行う（ステップＳ３０２）。
そして、ＣＰＵ２１は、ユーザ：ＡＢＣが対戦に勝利した場合（ステップＳ３０４：ＹＥＳ）、ユーザ：ＡＢＣに対して特典を付与する処理を行う（ステップＳ３０６）。ここで、ＣＰＵ２１は、ＣＯＭ対戦においてユーザ：ＡＢＣが勝利した場合、ユーザデータベース３１にアクセスして、ユーザ：ＡＢＣのユーザＩＤに対応する勝利ポイントの値を所定値（例えば１００）だけ増加させる。一方、ＣＰＵ２１は、ユーザ間対戦においてユーザ：ＡＢＣが勝利した場合、ユーザデータベース３１にアクセスして、ユーザ：ＡＢＣのユーザＩＤに対応する勝利ポイントの値を所定値（例えば５００）だけ増加させる。また、ＣＰＵ２１は、モンスターカードデータベースにアクセスして、所定のレア度（例えばレア度４）のモンスターカードをランダム、あるいは所定の規則に基づいて抽出する。そして、ＣＰＵ２１は、ユーザ：ＡＢＣのユーザＩＤに対応する保有カードの項目に、抽出したモンスターカードの識別コードを追記する。
なお、ＣＰＵ２１は、ユーザ：ＡＢＣが対戦に敗北した場合（ステップＳ３０４：ＮＯ）、ステップＳ３１０の処理に移行する。

次に、ＣＰＵ２１は、ユーザ間対戦の発生確率を変動させる処理を行う（ステップＳ３０８）。具体的には、ＣＰＵ２１は、ＣＯＭ対戦においてユーザ：ＡＢＣが勝利した場合、イベントデータにアクセスして、ユーザ：ＡＢＣのユーザＩＤに対応するユーザ間対戦の発生確率を所定値（例えば１０％）だけ増加させる。
そして、ＣＰＵ２１は、イベントの抽選権利回数を更新する（ステップＳ３１０）。この場合、ＣＰＵ２１は、イベントデータにアクセスして、ユーザ：ＡＢＣのユーザＩＤに対応するイベントの抽選権利回数の値を１つ減らす。

なお、ＣＰＵ２１は、ウェブページＰ４又はＰ７上でメニューｍ２１（「対戦開始」）が選択操作されない状態で所定時間経過した場合、対戦実行処理を終了してもよい。
また、ＣＰＵ２１は、ユーザ間対戦が発生した場合、イベントデータにアクセスして、ユーザ：ＡＢＣのユーザＩＤに対応するユーザ間対戦の発生確率を所定値（例えば０％）まで減少させてもよい。

上述したように、本実施形態のゲーム制御装置によれば、ユーザは、自らの入力によって、ＣＯＭ対戦（第１イベント）又はユーザ間対戦（第２イベント）のいずれかを発生させることができる。また、ユーザ間対戦は発生確率に基づき発生するが、ユーザは、ＣＯＭ対戦における自らのゲームの実行状況によって当該発生確率を変動させることが可能となる。ここで、例えばＣＯＭ対戦におけるユーザによるゲームの実行状況が進行するほど（ＣＯＭ対象に勝利するほど）、発生確率が増加する場合には、ユーザがＣＯＭ対象に勝利するほど、ユーザ間対戦が発生し易くなる。このため、例えばユーザ間対戦がユーザにとって有利になり得るイベントである場合には、ユーザは、ユーザ間対戦が発生する確率を高めようと動機付けられ、ＣＯＭ対戦において勝利するようにゲームを積極的に進行させることになる。このように、本構成によれば、ＣＯＭ対戦の勝敗によって、ユーザ間対戦の発生確率を変動できることから、ユーザは、自らの意思でユーザ間対戦の発生に間接的に関与できることとなり、目的達成を図る面白さのあるゲームを実現することができる。また、ユーザは、目的達成を図るために、ゲームを継続して実行することが動機付けられるため、ユーザを引きつける誘引力のあるゲームを実現することができる。

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

（８−１）変形例１
上記実施形態において、変動手段５５は、時間の経過に伴って、ユーザ間対戦の発生確率（所定の確率）を低減してもよい。
本変形例によれば、ユーザ間対戦の発生確率が時間の経過に伴って低減する。このため、ユーザは、ユーザ間対戦の発生確率が高い間にユーザ間対戦を発生させることが動機付けられる。例えば、ユーザがＣＯＭ対戦（第１イベント）を積極的に実行することによりユーザ間対戦（第２イベント）の発生確率を一時的に高くしたとしても、そのまま放置した場合にはユーザ間対戦の発生確率が時間の経過に伴って低減することになる。したがって、ユーザは、継続的にＣＯＭ対戦を実行することがもとめられる。また、本構成によれば、ユーザ間対戦の発生確率が高い間、ユーザをゲームに集中させることができる。

本変形例における変動手段５５の機能は、例えば以下のように実現される。ゲームサーバ２０のＣＰＵ２１は、例えば、所定時間（例えば１分）が経過するごとに、イベントデータにアクセスして、全てのユーザ（ユーザＩＤ）の各々に対応するユーザ間対戦の発生確率の値を所定値（例えば１％）だけ低減してもよい。
なお、ユーザ間対戦の発生確率が増加するタイミングが連続して発生する場合に、当該タイミングにおける発生確率の増加量は、連続するタイミング間における時間の経過に伴う発生確率の減少量よりも大きくなるように設定されていることが好ましい。例えば、ユーザ間対戦の発生確率が１０％増加してから１時間後に再度１０％増加する場合、当該１時間の間に減少する発生確率は１０％未満であってもよい。

（８−２）変形例２
上記実施形態において、ユーザ間対戦（第２イベント）が、ユーザ：ＡＢＣ（第１ユーザ）の入力情報に基づいて、ユーザ：ＡＢＣとユーザ：ＡＢＣ以外の他のユーザとを関連付けてゲームを実行するイベントである場合に、付与手段５６は、ユーザ間対戦において、ユーザ：ＡＢＣを同一のユーザと関連付けてゲームを実行した回数あるいは頻度に応じて、ユーザ：ＡＢＣに付与する特典を変動させてもよい。
例えば、ユーザ間対戦においてユーザ：ＡＢＣが同一のユーザと関連付けてゲームを実行した回数あるいは頻度が多いほど、ユーザ：ＡＢＣに付与される特典が大きくなるようにしてもよい。この場合、ユーザ：ＡＢＣは、大きな特典を得るために、ユーザ間対戦において同一のユーザと関連付けてゲームを実行することが動機付けられる。このとき、ユーザ：ＡＢＣは、同一のユーザと関連付けてゲームを実行することにより、当該同一のユーザに対して親近感が生じ得ることから、ゲームを通じてユーザ間の交流を促進する仕組みとすることができ、ゲームのソーシャル性を向上させることができる。

本変形例における付与手段５６の機能は、例えば以下のように実現される。ゲームサーバ２０のＣＰＵ２１は、例えば、図１５のフローのステップＳ３０６の処理において、図１６に例示する対戦データを参照して、ユーザ：ＡＢＣに付与する特典を決定してもよい。図１６に例示する対戦データは、ユーザ（ユーザＩＤ）ごとに、ユーザ間対戦において対戦した相手ユーザのユーザＩＤと、当該相手ユーザとの対戦数とが対応付けられて記録されたデータである。対戦データは、例えばゲームデータベース３２に記録されている。ＣＰＵ２１は、例えば、図１４のフローのステップＳ２０８の処理においてユーザ間対戦を発生させたときに、対戦データにアクセスして、ユーザ：ＡＢＣの対戦相手として抽出されたユーザ（相手ユーザ）のユーザＩＤを、ユーザ：ＡＢＣのユーザＩＤに対応付けて記録する。また、ＣＰＵ２１は、図１５のフローのステップＳ３０２の処理において対戦結果を決定すると、対戦データにアクセスして、ユーザ：ＡＢＣのユーザＩＤに対応付けられたユーザのうち、ユーザ：ＡＢＣと対戦を行った相手ユーザの対戦数を１つ増加させる。
また、ＣＰＵ２１は、ユーザ：ＡＢＣに付与する特典の決定に当たって、対戦データにアクセスして、ユーザ：ＡＢＣのユーザＩＤに対応付けられたユーザのうち、ユーザ：ＡＢＣと対戦を行った相手ユーザの対戦数を抽出する。そして、ＣＰＵ２１は、例えば以下のように設定されたデータを用いて、特典を決定してもよい。
・対戦数が１の場合、レア度が１のモンスターカード
・対戦数が２の場合、レア度が２のモンスターカード
・対戦数が３の場合、レア度が３のモンスターカード
・対戦数が４の場合、レア度が４のモンスターカード
・対戦数が５以上の場合、レア度が５のモンスターカード
このように特典を設定した場合、同一の相手ユーザとの対戦数が多くなるほど、希少価値の高いモンスターカードが特典としてユーザ：ＡＢＣに付与されることになる。
なお、ＣＰＵ２１は、特典を決定すると、特典の内容に相当するモンスターカードをモンスターカードデータベースから抽出する。そして、ＣＰＵ２１は、ユーザデータベース３１にアクセスし、ユーザ：ＡＢＣのユーザＩＤに対応する保有カードのデータに対して、抽出したモンスターカードの識別コードを記録する。

なお、対戦データには、相手ユーザごとの対戦数の代わりに、相手ユーザごとの対戦頻度（例えば、処理対象のユーザの全ての対戦数に対する同一の相手ユーザとの対戦数の割合）が記録されてもよい。この場合、ＣＰＵ２１は、例えば対戦頻度が多くなるほど、大きな特典が処理対象のユーザに付与されるように、特典の内容を決定してもよい。
また、本変形例では、処理対象のユーザと、相手ユーザとの対戦数あるいは対戦頻度に応じて特典を変動する場合を一例として説明したが、この場合に限られない。例えば、処理対象のユーザと、他のユーザとが協力して所定の対戦相手と対戦を行った回数あるいは頻度に応じて、特典を変動してもよい。

また、本変形例では、図１７に例示するように、ユーザ間対戦（第２イベント）において、ユーザ：ＡＢＣ（第１ユーザ）を同一の相手ユーザと関連付けてゲームを実行した回数あるいは頻度が所定の閾値に達した場合に、ユーザ：ＡＢＣと当該同一の相手ユーザとを関係付ける関係付け手段５８を備えてもよい。
例えば、関係付け手段５８は、ユーザＩＤに基づく申請を契機として、当該ユーザＩＤを他のユーザＩＤとを関連付けて記録する。すなわち関係付け手段５８は、ユーザＩＤに基づく申請を契機として、他のユーザＩＤ（つまり、他のユーザ）を「仲間」として記録する。
関係付け手段５８の機能は例えば、以下のように実現される。ゲームサーバ２０のＣＰＵ２１は、ユーザ：ＡＢＣと同一の相手ユーザとの対戦数あるいは対戦頻度が所定値に達したことを認識すると、通信インタフェース部２５を介して、あるユーザＩＤ（例えばユーザ：ＡＢＣのユーザＩＤ）に対応するユーザの通信端末１０から、仲間になりたいユーザＩＤ（例えば同一の相手ユーザのユーザＩＤ）を指定した申請メッセージ（仲間申請）を受け付ける。この申請メッセージの送信は、ユーザの通信端末１０に提供されるウェブページの機能として予め設定されてもよい。
ＣＰＵ２１は、申請メッセージを受け付けると、申請メッセージに含まれるユーザＩＤに基づくアクセスがあったタイミングで、そのユーザＩＤに対応する通信端末１０へ、他のユーザＩＤに基づく申請を承認するか否かを返信することを要求するウェブページを表示するためのＨＴＭＬデータを送信する。その申請を承認することが返信されれば、ＣＰＵ２１は、両者を仲間として登録する。具体的には、ＣＰＵ２１は、ユーザデータベース３１内の対応する２つのユーザＩＤのユーザデータの「仲間のユーザＩＤ」の項目（図６参照）にデータ（相手のユーザＩＤ）を書き込む。なお、ＣＰＵ２１は、仲間申請先のユーザの承認を不要とする場合は、ゲームを実行中のユーザによる所定の操作を契機として、両者を仲間として登録してもよい。
なお、ユーザ同士を関係付ける条件は、上記のような申請と承認を必要とする形式に限られず、ユーザと協働してゲームを実行した他のユーザ、例えば、ゲーム上の同一のステージやエリアなどを実行する他のユーザや、バトルを行った他のユーザなどを、ユーザとゲーム内で関係付けられた他のユーザ、つまり仲間として登録してもよい。あるいは、所定回数の挨拶メッセージを送信するユーザ同士を自動的に仲間として登録してもよい。

（８−３）変形例３
上記変形例２において、ユーザ：ＡＢＣ（第１ユーザ）と関連付けてゲームを実行済みの複数の相手ユーザ（第２ユーザ）に関する情報を、ユーザ：ＡＢＣと対応付けて記憶装置に記憶させる記憶手段５９と、ユーザ間対戦（第２イベント）が発生した場合に、前記記憶装置を参照して、前記複数の相手ユーザの中からユーザ：ＡＢＣと関連付けてユーザ間対戦におけるゲームを実行する相手ユーザを選択する選択手段６０とを備え、前記記憶装置に記憶させる相手ユーザの数の上限が設定されてもよい。
変形例３のゲーム制御装置の機能ブロック図を図１８に示す。図１８に示すように、この機能ブロック図は、図１２に示したものとは、記憶手段５９及び選択手段６０が設けられている点で異なる。
本変形例によれば、ユーザ：ＡＢＣがユーザ間対戦を発生させた場合に、ユーザ：ＡＢＣと関連付けてユーザ間対戦におけるゲームを実行する相手ユーザは、既にユーザ：ＡＢＣと関連付けてユーザ間対戦におけるゲームを実行したユーザに限定される。また、ユーザ：ＡＢＣに対応付けられる相手ユーザの数には上限が設定されている。これにより、例えばゲームを実行する全てのユーザの中から相手ユーザが選択される場合と比べて、同一のユーザを相手ユーザとして選択する可能性が高くなる。このため、ユーザ間対戦においてユーザ：ＡＢＣが同一の相手ユーザと関連付けてゲームを実行する回数あるいは頻度を多くすることができるため、ユーザ：ＡＢＣは例えば大きな特典を得ることができ、且つ、相手ユーザとの関係性を高める機会が得られる。
また、このゲーム制御装置によれば、ユーザ：ＡＢＣと関連付けてユーザ間対戦におけるゲームを実行する相手ユーザの選択範囲を限定することができるので、相手ユーザの選択に係る処理負荷を低減することができる。

記憶手段５９の機能は、例えば以下のように実現される。なお、本変形例では、図１６に例示した対戦データの代わりに、図１９に例示する対戦データが例えばゲームデータベース３２（記憶装置）に記録されてもよい。図１９に例示する対戦データは、ユーザ（ユーザＩＤ）ごとに所定数（図の例では５０）の番号が対応付けられており、当該所定数の番号のうちいずれかの番号に対して、相手ユーザのユーザＩＤと当該相手ユーザとの対戦数とが対応付けて記録されている。つまり、一つのユーザＩＤに対応付けられる相手ユーザの数には上限（所定数）が設定されている。
ゲームサーバ２０のＣＰＵ２１は、例えば後述する選択手段６０の機能に基づいて、処理対象のユーザ（ここでは、ユーザ：ＡＢＣ）の対戦相手となる他のユーザを決定すると、当該他のユーザのユーザＩＤをユーザ：ＡＢＣのユーザＩＤと対応付けて対戦データに記録する。この場合、ＣＰＵ２１は、当該他のユーザのユーザＩＤを、選択手段６０の機能によって選択した番号に対応付けて記録する。また、ＣＰＵ２１は、当該他のユーザのユーザＩＤに対応する対戦数の値に１を記録する。

なお、ここでは、他のユーザのユーザＩＤが、選択手段６０の機能によって選択した番号に対応付けて記録される場合を一例として説明したが、この場合に限られない。例えば、ＣＰＵ２１は、選択手段６０の機能に基づいて、他のユーザのユーザＩＤをユーザデータベース３１から選択するごとに、当該他のユーザのユーザＩＤを、ユーザ：ＡＢＣのユーザＩＤに対応する番号の小さい順に順次記録していくようにしてもよい。

また、選択手段６０の機能は、例えば以下のように実現される。ゲームサーバ２０のＣＰＵ２１は、例えば発生手段５４の機能に基づいてユーザ間対戦を発生させることを決定すると、対戦データにアクセスして、処理対象のユーザ（ここでは、ユーザ：ＡＢＣ）のユーザＩＤに対応する所定数の番号の中から１つの番号をランダム、あるいは所定の規則に基づいて選択する。次に、ＣＰＵ２１は、選択した番号に対応する相手ユーザのユーザＩＤ及び対戦数が記録されている場合には、当該ユーザＩＤに対応する相手ユーザをユーザ間対戦における対戦相手として決定（選択）する。
また、ＣＰＵ２１は、選択した番号に対応する相手ユーザのユーザＩＤ及び対戦数が記録されていない場合には、ユーザデータベース３１にアクセスして、ユーザデータベース３１に含まれるユーザの中からユーザ：ＡＢＣの対戦相手となる他のユーザを、ランダム、あるいは所定の規則に基づき決定（選択）する。ここで、対戦相手として決定された他のユーザのユーザＩＤは、上述した記憶手段５９の機能に基づいて、対戦データに記録される。

（８−４）変形例４
変形例４のゲーム制御装置の機能ブロック図を図２０に示す。図２０に示すように、この機能ブロック図は、図１８に示したものとは、消去手段６１が設けられている点で異なる。
消去手段６１は、複数の相手ユーザ（第２ユーザ）のうち所定の条件を満たす相手ユーザ（第２ユーザ）に関する情報を記憶装置から消去する機能を備える。
ここで、「所定の条件」とは、ゲームの実行に関するものであれば如何なる条件であってもよいが、例えば、ユーザ：ＡＢＣ（第１ユーザ）と関連付けてゲームを実行した回数あるいは頻度が所定の閾値に達したことであってもよいし、ユーザ間対戦（第２イベント）が例えば各ユーザのそれぞれに対応付けられたパラメータに基づいて当該各ユーザ間の対戦を行うイベントである場合には、ユーザ：ＡＢＣとの間におけるパラメータの差の絶対値が所定値以上に達したことであってもよい。
本変形例によれば、所定の条件を満たす相手ユーザに関する情報が消去されることにより、ユーザ：ＡＢＣは、選択手段６０によって新たに選択された相手ユーザと関連付けてユーザ間対戦におけるゲームを実行することが可能となる。このため、ユーザ：ＡＢＣにとっては、自身と関連付けてゲームを実行した相手ユーザの総数を増やすことができるので、ユーザ間で幅の広い交流を促進するゲームを実現することができる。

消去手段６１の機能は、例えば以下のように実現される。なお、ここでは、ユーザ：ＡＢＣと関連付けてゲームを実行した回数が所定の閾値に達したことが所定の条件である場合を一例として説明する。ゲームサーバ２０のＣＰＵ２１は、例えば、図１９に例示する対戦データに任意のタイミングでアクセスして、全てのユーザ（ユーザＩＤ）の各々に対応付けられている相手ユーザのうち、対戦数が所定の閾値（例えば５）に達した相手ユーザのユーザＩＤ及び対戦数を対戦データから消去する。

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

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

上述した実施形態では、実行対象のゲームが、モンスターカードを用いたカードバトルゲームである場合の例について説明したが、本発明のゲームはこれに限られず、任意のゲームに適用することができる。例えば、ロールプレイングゲーム、テーブルゲーム、パズルゲーム、スポーツゲーム、レースゲーム、シューティングゲーム、アクションゲーム、アドベンチャーゲーム、シミュレーションゲームなどの各種ジャンルのゲームにおいて、第１イベント又は第２イベントのいずれかが発生可能に構成されている場合には、本発明を好適に適用することができる。

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

上述した実施形態では、ソーシャルゲームに適用される場合を例として説明したが、これに限られない。例えば、ネットワーク上に置かれたサーバ装置と家庭用オンラインゲーム機とを接続した、いわゆるオンラインゲームシステムにおいても、上述した実施形態と同様に、ユーザによるゲームの進行を制御できることは言うまでもない。
また、例えば、家庭用ゲーム機がオフライン状態の場合であっても、上述した実施形態と同様に、ユーザによるゲームの進行を制御することができる。
さらに、例えば、アドホックネットワーク等のように、複数の通信端末（例えば携帯電話やゲーム機など）が自律的にネットワークを構成して、データの送受信を各通信端末間で直接行う場合においても、上述した実施形態と同様に、ユーザによるゲームの進行を制御することができる。

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

１０…通信端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１４…画像処理部
１５…指示入力部
１６…表示部
１７…通信インタフェース部
１８…バス
２０…ゲームサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…データベースアクセス部
２５…通信インタフェース部
２６…バス
３０…データベースサーバ
３１…ユーザデータベース
３２…ゲームデータベース
５１…登録手段
５２…実行手段
５３…提示手段
５４…発生手段
５５…変動手段
５６…付与手段
５７…制限手段
５８…関係付け手段
５９…記憶手段
６０…選択手段
６１…消去手段

Claims (12)

1. 第１イベント及び第２イベントが設けられたゲームの実行を制御するゲーム制御装置であって、
   ユーザの入力情報に基づいて前記第１イベント又は前記第２イベントのいずれかを発生させる手段であって、所定の確率で前記第２イベントを発生させる発生手段と、
   ユーザの入力情報に基づいて前記第１イベントが発生した場合に、前記第１イベントにおけるユーザによるゲームの実行状況に応じて前記所定の確率を変動させる変動手段と、
   を備えた、ゲーム制御装置。
2. 前記第２イベントにおける前記ユーザによるゲームの実行状況に応じて、前記ユーザに対して特典を付与する付与手段を備えた、ことを特徴とする、
   請求項１に記載されたゲーム制御装置。
3. 前記変動手段は、時間の経過に伴って、前記所定の確率を低減することを特徴とする、
   請求項１又は２に記載されたゲーム制御装置。
4. 前記第２イベントが、第１ユーザの入力情報に基づいて、第１ユーザと第１ユーザ以外の他のユーザとを関連付けてゲームを実行するイベントである場合に、
   前記付与手段は、前記第２イベントにおいて、第１ユーザを同一のユーザと関連付けてゲームを実行した回数あるいは頻度に応じて、前記第１ユーザに付与する特典を変動させることを特徴とする、
   請求項２又は３に記載されたゲーム制御装置。
5. 前記第１ユーザと関連付けてゲームを実行済みの複数の第２ユーザに関する情報を、前記第１ユーザと対応付けて記憶装置に記憶させる記憶手段と、
   前記第２イベントが発生した場合に、前記記憶装置を参照して、前記複数の第２ユーザの中から前記第１ユーザと関連付けて前記第２イベントにおけるゲームを実行する第２ユーザを選択する選択手段とを備え、
   前記記憶装置に記憶させる第２ユーザの数の上限が設定されていることを特徴とする、
   請求項４に記載されたゲーム制御装置。
6. 前記複数の第２ユーザのうち所定の条件を満たす第２ユーザに関する情報を前記記憶装置から消去する消去手段を備えた、ことを特徴とする、
   請求項５に記載されたゲーム制御装置。
7. 前記所定の確率に関する情報を前記ユーザに提示する提示手段を備えた、ことを特徴とする、
   請求項１〜６のいずれかに記載されたゲーム制御装置。
8. 前記発生手段によるイベントの発生回数を所定値以下に制限する制限手段を備えた、ことを特徴とする、
   請求項１〜７のいずれかに記載されたゲーム制御装置。
9. 第１ユーザとコンピュータとの間で対戦を行う第１イベント、及び前記第１ユーザと第２ユーザとの間で対戦を行う第２イベントが設けられたゲームの実行を制御するゲーム制御装置であって、
   前記第１ユーザの入力情報に基づいて前記第１イベント又は前記第２イベントのいずれかを発生させる手段であって、所定の確率で前記第２イベントを発生させる発生手段と、
   前記第１ユーザの入力情報に基づいて前記第１イベントが発生した場合に、前記第１イベントにおける前記第１ユーザによるゲームの実行状況に応じて前記所定の確率を増加させる手段であって、時間の経過に伴って前記所定の確率を低減する変動手段と、
   を備えた、ゲーム制御装置。
10. 第１イベント及び第２イベントが設けられたゲームの実行を制御するゲーム制御方法であって、
    ユーザの入力情報に基づいて前記第１イベント又は前記第２イベントのいずれかを発生させるステップであって、所定の確率で前記第２イベントを発生させるステップと、
    ユーザの入力情報に基づいて前記第１イベントが発生した場合に、前記第１イベントにおけるユーザによるゲームの実行状況に応じて前記所定の確率を変動させるステップと、
    を備えた、ゲーム制御方法。
11. 第１イベント及び第２イベントが設けられたゲームの実行を制御するプログラムであって、
    コンピュータに、
    ユーザの入力情報に基づいて前記第１イベント又は前記第２イベントのいずれかを発生させる機能であって、所定の確率で前記第２イベントを発生させる機能、及び
    ユーザの入力情報に基づいて前記第１イベントが発生した場合に、前記第１イベントにおけるユーザによるゲームの実行状況に応じて前記所定の確率を変動させる機能、
    を実現させるためのプログラム。
12. 通信端末と、当該通信端末からアクセスされるサーバとを含み、第１イベント及び第２イベントが設けられたゲームの実行を制御するゲームシステムであって、
    ユーザの入力情報に基づいて前記第１イベント又は前記第２イベントのいずれかを発生させる手段であって、所定の確率で前記第２イベントを発生させる発生手段、
    ユーザの入力情報に基づいて前記第１イベントが発生した場合に、前記第１イベントにおけるユーザによるゲームの実行状況に応じて前記所定の確率を変動させる変動手段、
    の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
    ゲームシステム。

Images