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

Abstract

【課題】複数のユーザ同士が共同で競い合うことを可能とするゲーム制御装置、ゲーム制御方法、プログラム、ゲーム制御システムを提供すること。
【解決手段】ユーザの操作に基づいて、ユーザを複数のグループのいずれかに対応付ける。異なるグループの間の競争であるグループ間競争を複数設ける。ユーザの参加を受け付けたグループ間競争において、当該ユーザと、当該ユーザとは異なるグループに対応付けられている他のユーザとの間のゲーム上の競争であるユーザ間競争を実行するためのユーザの操作を所定時間内、又は所定回数受け入れ、ユーザ間競争の結果に基づいてグループ間競争における勝敗を決定する。ユーザに対応付けられているグループのグループ間競争における勝敗に基づいて、当該ユーザに対して特典を付与するか否か、又は当該ユーザに対して付与する特典の内容を決定する。
【選択図】図１

Description

本発明は、通信を利用した複数のユーザによるゲームの実行を制御する技術に関する。

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

上述したソーシャルゲームにおいて、ユーザに対して所望の機能の実行を促す選択肢を提示するために、ゲームに設けられている複数の機能の各々が割り当てられた複数のメニューを、ユーザが視認できる表示部に表示させることが知られている。例えば、非特許文献１には、「クエスト」、「合戦」、「カード合成」、「ガチャ」といったメニューが表示されているソーシャルゲーム（戦国コレクション（登録商標））が記載されている。いずれかのメニューがユーザに選択されると、選択されたメニューに応じた機能（あるいは処理）が実行される。なお、「ガチャ」とは、ゲーム内で利用可能なアイテムをランダムに入手可能なアイテム抽選処理として慣用的に使用されている表現である。

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

ところで、上述したソーシャルゲームのように多数のユーザが参加するゲームにおいて、多数のユーザ同士が共同で競い合う新たなゲームの形態が望まれている。

本発明は上述した観点に鑑みてなされたもので、複数のユーザ同士が共同で競い合うことを可能とするゲーム制御装置、ゲーム制御方法、プログラム、ゲーム制御システムを提供することを目的とする。

本発明の第１の観点は、ユーザによって操作される通信端末からアクセス可能に構成され、前記通信端末によるゲームの実行を制御するゲーム制御装置であって、
ユーザの操作に基づいて、ユーザを複数のグループのいずれかに対応付ける対応付け手段と、
異なるグループの間の競争であるグループ間競争を複数設け、ユーザの操作に応じて、複数のグループ間競争のうち少なくともいずれかのグループ間競争へのユーザの参加を受け付ける受付手段と、
ユーザの参加を受け付けたグループ間競争において、当該ユーザと、当該ユーザとは異なるグループに対応付けられている他のユーザとの間の前記ゲーム上の競争であるユーザ間競争を実行するためのユーザの操作を所定時間内、又は所定回数受け入れ、ユーザ間競争の結果に基づいて前記グループ間競争における勝敗を決定する競争実行手段と、
ユーザに対応付けられているグループのグループ間競争における勝敗に基づいて、当該ユーザに対して特典を付与するか否か、又は当該ユーザに対して付与する特典の内容を決定する特典付与手段と、
を備える。

このゲーム制御装置では、複数のグループ間競争の中から、各ユーザがそれぞれ選択した１つまたは複数のグループ間競争において、ユーザが他のユーザと競争する個別のユーザ間競争の結果の総計に基づき、各ユーザが予め対応付けられているグループとしての競争結果が決定されるものである。すなわち、個々のユーザは自分自身の競争を行うが、その競争結果が、グループ間競争の結果に間接的に結びついているという構成を備えたものであり、さらに、各ユーザは、複数のグループ間競争に対して同時間帯に参加してユーザ間競争を行うことが可能であり、現実世界では不可能な団体戦を実現することができる。しかも、このゲーム制御装置によれば、ユーザが対応付けられているグループのグループ間競争における結果（勝敗等）に基づいて、当該ユーザに対して特典を付与するか否か、又は当該ユーザに対して付与する特典の内容を決定するように構成されているため、グループ間競争に参加して積極的にユーザ間競争を実行することをユーザに動機付けることができる。また、ユーザは同一のグループ間競争に対して、繰り返し参加することができる。

上記ゲーム制御装置において、前記グループ間競争の勝敗が決定されるまでの残り時間及び／又は残り回数を表示する表示手段、をさらに備えてもよい。
ここで、「残り時間」は、ユーザが残り時間を認識可能な情報であればよく、残り時間そのものの情報のほか、グループ間競争の勝敗が決定される時刻（つまり、グループ間競争の終了時刻）についての情報であってもよい。「残り回数」は、ユーザが残り回数を認識可能な情報であればよく、残り回数そのものの情報のほか、ユーザ間競争の現在までの実行回数についての情報であってもよい。つまり、グループ間競争におけるユーザ間競争の総実行回数がユーザにとって既知であれば、ユーザ間競争の現在までの実行回数を基に残り回数をユーザが認識可能である。
グループ間競争の勝敗が決定されるまでの残り時間及び／又は残り回数が表示されることによって、そのグループ間競争に参加した方がよいか否か、またグループ間競争が複数ある場合には、どのグループ間競争に参加するのが有利か等についてユーザに検討させることになり、ゲームの興趣性が増す。例えば、グループ間競争の残り時間及び／又は残り回数が少ない場合には、ユーザは、そのグループ間競争に参加することで、グループ間競争が勝利となった場合等に与えられる特典を早く得る可能性が高くなるが、一方、自らがそのグループ間競争におけるユーザ間競争を繰り返し行って自らのグループの勝利に貢献できる機会が少なくなる。また、後記する勝利の貢献に伴う特典を得る可能性が低くなる。逆に、グループ間競争の残り時間及び／又は残り回数が多い場合には、ユーザは、そのグループ間競争に参加することで、グループ間競争が勝利となった場合等に与えられる特典が得られうるタイミングが遅くなるが、一方、自らがそのグループ間競争におけるユーザ間競争を繰り返し行なうことができるので、自らのグループの勝利に貢献できる機会が多くなる。また、後記する勝利の貢献に伴う特典を得る可能性が高くなる。

上記ゲーム制御装置において、前記特典付与手段は、１つのグループ間競争について、ユーザによる前記ユーザ間競争が実行された回数に応じて、当該ユーザに対応付けられているグループが勝利したときに当該ユーザに対して付与する特典を増加あるいは減少させてもよい。
例えば、ユーザが対応付けられているグループが勝利した場合、そのユーザのユーザ間競争の実行回数が多い場合には、そのユーザの貢献度が高いと判断し、そのユーザに対する特典を増加させてもよい。逆に、ユーザが対応付けられているグループが勝利した場合、そのユーザのユーザ間競争の実行回数が少ない、またはゼロであった場合には、そのユーザの貢献度が少ないと判断し、そのユーザに対する特典を減少させてもよい。このような仕組みとすることで、グループ間競争に参加したユーザに対し、多くのユーザ間競争を実行して勝利することを動機付けることができる。

上記ゲーム制御装置において、前記特典付与手段は、１つのグループ間競争について、ユーザに対応付けられているグループに有利となったユーザ間競争が実行された回数に応じて、当該ユーザに対応付けられているグループが勝利したときに当該ユーザに対して付与する特典を増加あるいは減少させてもよい。ここで、グループとは例えば野球ゲームであれば、セ・リーグ、パ・リーグといったリーグの違いの他、個々のチームとすることができる。
例えば、ユーザ間競争が野球等の対戦であって、グループ間競争がユーザ間の野球等の対戦のスコアを積算して勝敗を争う場合等を想定すると、上述の、ユーザに対応付けられているグループに有利となったユーザ間競争とは、その野球等の対戦で勝利することである。これにより、そのユーザが属するグループの総得点が、対戦相手の属するグループの総得点よりも多くの得点が加算されるため、対戦で勝利した試合の実行数（つまり、ユーザ間競争の実行回数）が多いほど、ユーザがグループの勝利に貢献したと判断することができる。このような仕組みとすることで、グループ間競争に参加したユーザに対し、多くのユーザ間競争を実行して勝利することを動機付けることができる。なお、勝敗の判断を上記の総得点に代えて、単純に総勝利数とするようにしてもよい。

上記ゲーム制御装置において、前記受付手段は、１つのグループ間競争の勝敗が決定される毎に新たなグループ間競争を設けることによって、ユーザに対して所定数のグループ間競争を選択可能にしてもよい。
このように、常に所定数のグループ間競争を設定しておき、１つのグループ間競争の勝敗が決定されてから新たなグループ間競争を設けることで、ゲームの進行にスピード感を与え、ユーザを飽きさせないようにすることができる。仮に、グループ間競争を予め多数準備しておくと、ユーザが選択に迷うだけでなく、個々のグループ間競争へのユーザ参加人数が分散してしまうことになる。従って、個々のグループ間競争の決着がつくまでの時間が長くなり、この結果、グループ間競争の結果としての特典が与えられるまでの時間も長くなってしまい、ユーザに冗長感を与えてしまう可能性がある。そこで、本構成にようにすることで、ユーザは常に、所定数の限られたグループ間競争の中から参加するグループ間競争を容易に決定することができ、また、グループ間競争の決着も迅速に行われることから、特典を得るまでの時間も短くすることができ、ユーザにゲームを飽きさせないようにすることができる。また、所定数のグループ間競争の各々についてそれぞれ特徴付けたグループ間競争としてもよく、その場合、例えばユーザが愛着のあるグループ間競争に継続的に参加することも期待できる。

上記ゲーム制御装置において、前記受付手段は、各グループ間競争へのユーザの参加を、ユーザがゲーム上の一定量のアイテムを消費することによって受け付けるものであって、前記アイテムについてユーザがゲーム上で保有可能な総量が制限されていてもよい。
かかる制限によって、特定のユーザが大量のアイテムを１つのグループ間競争で消費して多くのユーザ間競争を実行することで、そのユーザによるユーザ間競争がグループ間競争の結果に影響を与え過ぎることを防止することができる。

上記ゲーム制御装置において、前記ユーザ間競争で勝利したユーザに対して特典を付与する第２の特典付与手段、を備えてもよい。
これにより、ユーザは、ユーザ間競争で勝利することで直ちに特典が得られる上、グループ間競争の結果次第で（つまり、自らのグループが勝利したときに）さらに特典が得られるため、グループ間競争への参加意欲を高めることができる。

本発明の第２の観点は、ユーザによって操作される通信端末からアクセス可能に構成され、前記通信端末によるゲームの実行を制御するゲーム制御装置、におけるゲーム制御方法であって、
ユーザの操作に基づいて、ユーザを複数のグループのいずれかに対応付けるステップと、
異なるグループの間の競争であるグループ間競争を複数設け、ユーザの操作に応じて、複数のグループ間競争のうち少なくともいずれかのグループ間競争へのユーザの参加を受け付けるステップと、
ユーザの参加を受け付けたグループ間競争において、当該ユーザと、当該ユーザとは異なるグループに対応付けられている他のユーザとの間の前記ゲーム上の競争であるユーザ間競争を実行するためのユーザの操作を所定時間内、又は所定回数受け入れ、ユーザ間競争の結果に基づいて前記グループ間競争における勝敗を決定するステップと、
ユーザに対応付けられているグループのグループ間競争における勝敗に基づいて、当該ユーザに対して特典を付与するか否か、又は当該ユーザに対して付与する特典の内容を決定するステップと、
を備える。

本発明の第３の観点は、ユーザによって操作される通信端末によるゲームの実行を制御するために、コンピュータに、
ユーザの操作に基づいて、ユーザを複数のグループのいずれかに対応付ける機能、
異なるグループの間の競争であるグループ間競争を複数設け、ユーザの操作に応じて、複数のグループ間競争のうち少なくともいずれかのグループ間競争へのユーザの参加を受け付ける機能、
ユーザの参加を受け付けたグループ間競争において、当該ユーザと、当該ユーザとは異なるグループに対応付けられている他のユーザとの間の前記ゲーム上の競争であるユーザ間競争を実行するためのユーザの操作を所定時間内、又は所定回数受け入れ、ユーザ間競争の結果に基づいて前記グループ間競争における勝敗を決定する機能、及び
ユーザに対応付けられているグループのグループ間競争における勝敗に基づいて、当該ユーザに対して特典を付与するか否か、又は当該ユーザに対して付与する特典の内容を決定する機能、
を実現させるためのプログラムである。

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

本発明の第４の観点は、ユーザによって操作される通信端末と、当該通信端末からアクセス可能に構成され、前記通信端末によるゲームの実行を制御するゲーム制御装置と、を含むゲーム制御システムであって、
前記ゲーム制御装置は、
ユーザの操作に基づいて、ユーザを複数のグループのいずれかに対応付ける対応付け手段と、
異なるグループの間の競争であるグループ間競争を複数設け、ユーザの操作に応じて、複数のグループ間競争のうち少なくともいずれかのグループ間競争へのユーザの参加を受け付ける受付手段と、
ユーザの参加を受け付けたグループ間競争において、当該ユーザと、当該ユーザとは異なるグループに対応付けられている他のユーザとの間の前記ゲーム上の競争であるユーザ間競争を実行するためのユーザの操作を所定時間内、又は所定回数受け入れ、ユーザ間競争の結果に基づいて前記グループ間競争における勝敗を決定する競争実行手段と、
ユーザに対応付けられているグループのグループ間競争における勝敗に基づいて、当該ユーザに対して特典を付与するか否か、又は当該ユーザに対して付与する特典の内容を決定する特典付与手段と、を備える。

本発明のゲーム制御装置、ゲーム制御方法、プログラム、ゲーム制御システムによれば、複数のユーザ同士が共同で競い合うことができる。

実施形態のゲームシステムの基本構成を示す図。 実施形態の通信端末の外観の例を示す図 実施形態の通信端末の構成を示すブロック図。 実施形態のゲームサーバの構成を示すブロック図。 実施形態のデータベースサーバの構成を示すブロック図。 データベースサーバに含まれるユーザデータベースの構成例を示す図。 実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 トップページを表示する通信端末の表示画面の一例を示す図。 ユーザがスカウトメニューを選択したときのウェブページの一例を示す図。 ユーザがスカウトメニューを選択したときのウェブページの一例を示す図。 ユーザがスカウトメニューを選択したときのウェブページの一例を示す図。 ユーザが対抗戦メニューを選択したときのウェブページの一例を示す図。 対抗戦へのエントリーの処理の一例を示すフローチャート。 エントリーリストのデータ構成例を示す図。 ユーザ間対戦の処理の一例を示すフローチャート。 ユーザ間対戦におけるウェブページの一例を示す図。 対抗戦データのデータ構成例を示す図。 実施形態のゲームサーバの主要な処理の一例を示すフローチャート。 実施形態のゲームサーバの主要な処理の一例を示すフローチャート。 新たな対抗戦の設定の処理の一例を示すフローチャート。 新たな対抗戦の設定を概念的に例示する図。 ユーザが対抗戦メニューを選択したときのウェブページの変形例を示す図。 特典が異なる複数の種類の対抗戦の設定例を説明するための図。

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

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

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

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

ウェブブラウザは、画像処理部１４を介して、取得したＨＴＭＬデータに基づき、ゲームサーバ２０から提供されるウェブページを表示部１６に表示する。また、ウェブブラウザは、ユーザが操作入力部１５の操作によってウェブページ上のハイパーリンク(Hyperlink)またはメニューが選択されると、その選択に応じたウェブページを表示するための新たなＨＴＭＬデータの送信（つまり、ウェブページの更新）をゲームサーバ２０へ要求する。

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

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

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

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

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

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

例えば、ＣＰＵ２１は、無線通信インタフェース部２５を介して、ＨＴＭＬデータを通信端末１０宛に送信する。なお、ゲームサーバ２０が通信端末１０のユーザの認証処理を行う場合には、ＣＰＵ２１はその認証処理を行う。
ＣＰＵ２１は、通信インタフェース部を介して、通信端末１０で表示されるウェブページ上でユーザにより選択されたハイパーリンクまたはメニューに応じた処理を行う。その処理は、例えば、新たなＨＴＭＬデータの送信、または、ゲームサーバ２０内の演算処理あるいはデータ処理などを含む。
データベースアクセス部２４は、ＣＰＵ２１がデータベースサーバ３０に対してデータの読み書きを行うときのインタフェースである。

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

本実施形態のゲームサーバ２０によって実現されるゲームのタイプは特に限定されるものではないが、以下では、実施形態の説明の便宜上、ゲームサーバ２０によって実現されるゲームの一例として、野球形式のデジタルカードゲームを採り上げる。
野球形式のデジタルカードゲームは、ユーザが野球選手に対応する選手カードを収集することによって自らのチームを作り上げ、他のユーザのチームと野球の対戦する、あるいは技能レベルごとの野球のリーグ戦を戦うように構成されているゲームである。野球形式のデジタルカードゲームには、自らのチームを作り上げていくために選手カードを探索するスカウト処理や、抽選によって選手カードを入手することを可能とする抽選処理、あるいは２枚以上の選手カードを一体化して特定の選手カードの能力を上昇させる強化処理等が設けられている。
野球形式のデジタルカードゲームに実装されている各機能については、後述する。

図６に、上述した野球形式のデジタルカードゲームにおいて適用されるユーザデータベース３１の一例を示す。この例では、ユーザデータベース３１は、ユーザＩＤ（ユーザ識別情報）ごとに、ユーザ名／表示画像、チーム、技能レベル、行動ポイント、運営ポイント、強化ポイント、エールポイント、選手数、対抗戦チケット枚数、仲間のユーザＩＤ、保有カードの画像データ、及び保有カードのパラメータの各項目についての情報を含む。ユーザデータベース３１に含まれる情報は、ゲームサーバ２０によって逐次更新されうる。

以下の説明では、ユーザデータベース３１に含まれるユーザＩＤ、あるいはユーザを特定するユーザ名（後述する）ごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、以下のとおりである。
・ユーザ名／表示画像
ゲームの実行時に通信端末１０にユーザを特定するために表示されるユーザ名及び表示画像である。ユーザ名はユーザによって予め指定される所定長以下のテキストであり、表示画像は例えばユーザによって予め選択されるアバタ画像である。ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
・チーム
上記野球形式のデジタルカードゲームにおいて、ユーザ登録時に、ユーザが指定するチームである。このゲームでは、例えば、Ｐ１〜Ｐ６の６チームからなるＰリーグ、Ｑ１〜Ｑ６の６チームからなるＱリーグが設けられており、ユーザはこの１２チームの中からいずれかのチームをユーザ登録時に選択する。
・技能レベル
ゲーム上のユーザの技能レベル示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値である。
・行動ポイント
上記野球形式のデジタルカードゲームにおいて、例えばユーザによるゲーム上のスカウトを行う上で必要となるポイントである。行動ポイントは、スカウトを行うことで低減し、所定の時間が経過する毎に回復（増加）する値である。
・運営ポイント
上記野球形式のデジタルカードゲームにおいて、例えばユーザによるゲーム上の対戦を行う上で必要となるポイントである。運営ポイントは、他のユーザとの対戦等によって低減し、所定の時間が経過する毎に回復（増加）する値である。
・強化ポイント
上記野球形式のデジタルカードゲームにおいて、例えばユーザによる選手カードの強化を行う上で必要となるポイントである。強化ポイントは、選手カードの強化を行うことで低減し、他のユーザとの対戦で勝利するか、あるいは所定の時間が経過する毎に回復（増加）する値である。
・エールポイント
上記野球形式のデジタルカードゲームにおいて、仲間のユーザへ応援メッセージの送信することでユーザが取得するポイントである。
・選手数
ユーザが保有する選手カードの数である。選手数は、スカウト処理や強化処理の実行によって増減する。選手数の最大値（例えば、６０）は予め規定されている。
・対抗戦チケット枚数
上記野球形式のデジタルカードゲームに設定される対抗戦にユーザがエントリーする（対抗戦において１試合のユーザ間対戦を行う権利を得る）ために必要となるチケットについて、ユーザが保持している枚数である。
・仲間
対象とするユーザＩＤの仲間である他のユーザＩＤのデータである。
・保有カードの画像データ
上記野球形式のデジタルカードゲームの場合、保有カードの画像データは、ユーザが保有する選手カードについての画像を含むデータである。
・保有カードのパラメータ
保有カードのパラメータは、選手カードの能力値を示すデータである。例えば、図６に示すように、パラメータの項目として「打力」，「走力」，「守備力」等の各々の各能力値、及び「必要ポイント」が含まれてもよい。「必要ポイント」は、選手カードを他のユーザとの対戦で使用するときに必要となるポイントである。このゲームでは、対戦で使用する選手カードの必要ポイントの総計が運営ポイント以下となるように制限されてもよい。

図５に戻り、ゲームデータベース３２は、ゲームサーバ２０からのアクセスに基づき、ゲームサーバ２０によって実行されるゲームの設定についての情報（例えば、後述するエントリーリスト、対抗戦データ等）や、ゲームの結果（ゲーム結果）に関する情報（例えば、後述する対抗戦の結果についての情報）を記憶、更新する。ゲーム結果に関する情報は、ゲームの性質によって多様な情報を含みうる。野球形式のデジタルカードゲームの場合を例に挙げれば、ゲーム結果に関する情報は、異なるユーザＩＤ同士の対戦の結果（スコア等）、特定の技能レベルの複数のユーザＩＤの間のリーグ戦の結果（スコア、ランキング等）、後述する対抗戦の結果などを含む。

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

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

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

ゲーム進行手段５２は、通信端末１０に対するユーザの操作に応じて、通信端末１０に表示されるウェブページを逐次更新するためのＨＴＭＬデータを送信することで、ゲームを進行させる。前述したように、野球形式のデジタルカードゲームには、ゲームを進行させる上で以下の処理が設けられている。
・スカウト処理：自らのチームを作り上げていくために選手カードを探索する処理
・強化処理： ２枚以上の選手カードを一体化して特定の選手カードの能力を上昇させる処理
・対戦処理： 他のユーザのチームと野球の対戦する処理
・抽選処理： ユーザが選手カードを入手するための抽選を行う処理
・対抗戦処理： グループ同士で行われる対抗戦の処理

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

ゲーム進行手段５２によって通信端末１０に表示されるゲームのトップページの例を図８に示す。このトップページは、個々のユーザＩＤに応じたウェブページで構成される。図８に例示されるトップページは、ユーザ名、チームのテキストのほか、ユーザデータ表示領域、選手画像表示領域及びメニュー表示領域を含む。
ユーザデータ表示領域は、対象となるユーザＩＤのユーザデータに含まれる、技能レベル、行動ポイント、運営ポイント、強化ポイント、エールポイント、選手数、仲間の各項目のデータ（図６参照）が表示される領域である。なお、ユーザデータ表示領域に表示される項目で、Ｘ／Ｙの形式で表記されているポイントまたは数は、Ｘがユーザの保有するポイントまたは数であり、Ｙがそのポイントまたは数の最大値であることを示す。例えば、選手数が「４０／６０」と表記されていれば、ユーザが保有する選手数が４０人であり、最大で保有可能な選手数が６０人であることを示す。
選手画像表示領域は、ユーザによって予め選択された選手カードの画像データが表示される領域である。
メニュー表示領域は、野球形式のデジタルカードゲームに設けられる複数の処理（スカウト処理、強化処理、対戦処理、抽選処理、オーダー処理、対抗戦処理）に対応した基本メニューとして、「スカウト」、「強化」、「試合」、「抽選」、「オーダー」、「対抗戦」の各メニューｍ１〜ｍ６が表示される領域である。つまり、ゲームで実行される複数の処理が各々割り当てられた複数のメニューが、通信端末１０に表示されるウェブページの所定の位置にそれぞれ配置される。なお、オーダー処理は、ユーザの指示の下、選手カードのオーダーの入れ替え、控えの選手カードとの交替等を実行する処理である。
ゲーム進行手段５２、通信端末１０に表示されたメニューに対するユーザの選択操作に応じた処理を実行する。好ましくは、各処理が実行された場合、処理ごとに細分化された複数のメニューを含む新たなウェブページが表示されるようにして、階層的に各処理が実行される。

例えば図８に示すトップページをユーザの通信端末１０に表示する場合について、ゲーム進行手段５２は以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、データベースアクセス部２４を介してユーザデータベース３１にアクセスし、ユーザデータ表示領域に含まれる各項目のデータと、選手画像表示領域に表示すべき選手カードの画像データを読み出す。次にＣＰＵ２１は、図８に示したトップページが構成されるようにＨＴＭＬデータを生成し、通信端末１０宛に送信する。生成されるＨＴＭＬデータは、ユーザごと（つまり、ユーザＩＤごと）に異なるものとなる。通信端末１０は、受信したＨＴＭＬデータを解釈してトップページの画像を表示部１６（表示画面１６ａ）に表示する。

［スカウト処理］
ゲーム進行手段５２は、ユーザが自らのチームを作り上げていくために選手カードを探索できるようにするスカウト処理を実行する。
図９〜１１は、スカウト処理が実行された場合に通信端末１０に表示されるウェブページの例を示す。図９は、トップページにおいてスカウトメニューが選択操作されたときのウェブページの表示例である。図１０は、図９に示す画面において「エリア一覧へ」と表示されたメニューｍ１１が選択操作されたときのウェブページの表示例である。図１１は、スカウト処理の実行中に、ユーザに対して対抗戦チケットが得られたことを通知するためのウェブページの表示例である。

図９に例示するウェブページでは、表示領域１００において、複数の地域（エリア）に分けられた日本地図が、探索の対象となるエリアが強調表示された状態で表示される。このスカウト処理では、ユーザは、探索の対象となるエリア（図９の例では、エリア９（サブエリア９−１，９−２，…））ごとに設けられる「探索する」と表記されたメニューｍ１０を選択操作する。この操作を契機として、探索の対象となるエリアについての探索が行われ、選手が発掘された場合に表示領域１０２にその選手の選手カードが表示される仕組みになっている。このとき、メニューｍ１０が選択操作されて探索が行われる度に、表示領域１０１に表示されている「探索率」（％）の値が増加する。また、表示領域１０１には、１回の探索に要する行動力の値（図９の例では「５」）、１回の探索で得られる強化ポイントの値（図９の例では「１０」）が表示される。１回の探索につき、表示されている行動力の値だけ行動ポイントが減少し、表示されている量の強化ポイントが増加するように構成されている。ゲーム進行手段５２では、探索を行う度に、ＣＰＵ２１がユーザデータベース３１にアクセスし、対象となるユーザＩＤの行動ポイント及び強化ポイントの値を更新する。

スカウト処理において、ゲームサーバ２０のＣＰＵ２１は、メニューｍ１０に対する選択操作を認識すると、スカウト用に予め設けられた複数の選手の中から所定の、あるいはランダムな確率で抽選を行う。ＣＰＵ２１は、抽選により選手を得た（発掘した）場合には、ユーザデータベース３１にアクセスし、対象となるユーザＩＤのデータに対して、発掘された新たな選手のデータを追加して、選手数の値を１だけ増加させる。さらにＣＰＵ２１は、発掘された選手の選手カードを表示領域１０２に表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。なお、このＨＴＭＬデータは、表示領域１０１の探索率のデータが更新されるようにして構成されている。ユーザによるメニューｍ１０に対する選択操作が繰返し行われ、図９においてサブエリア９−１，９−２，…のすべてのエリアの探索率が１００％に達すると、エリア９についての探索は終了し、探索対象は次のエリア（この場合、エリア１０）に移る。なお、後述するように、探索率が１００％に達したとしても、表示領域１０２に表示可能な最大の枚数（図９のサブエリア９−１では、４枚）に相当する数の選手が発掘できたとは限らない。

スカウト処理では、探索対象となるエリアごとに、１回の探索に要する行動力が異なる。つまり、探索対象となるエリアごとに、１回の探索で減少する（消費される）行動ポイントの量が異なる。
スカウト処理では、メニューｍ１０に対する選択操作を行う度に行動ポイントが減少していくため、スカウト処理が実行された直後にトップページが表示される場合には、そのトップページに表示される行動ポイントがスカウト処理の実行前よりも減少されて表示されることになる。なお、行動ポイントは、例えば所定時間（例えば３分）が経過する度に１ポイントずつ回復（増加）する。

スカウト処理では、メニューｍ１０の選択操作に応じて所定の、あるいはランダムな確率で、図１１に例示したようにユーザに対して対抗戦チケットが付与される。対抗戦チケットは、後述するように、対抗戦にエントリーするために必要となるチケットである。以下、「対抗戦にエントリーする」とは、対抗戦において１試合のユーザ間対戦を行う権利を得ることを意味する。
なお、メニューｍ１０の選択操作に応じて対抗戦チケットが付与される確率は、表示領域１０１に表示されている行動力に概ね比例した値であってもよい。

図１０に示すように、スカウト処理では、ユーザによるメニューｍ１１の選択操作によって、ユーザが既にプレイした（つまり、探索した）各エリアの探索結果が概観できるウェブページが表示される。表示領域１１０では、エリアごとの「コンプリート率」が表示される。「コンプリート率」（達成度）は、各エリアにおいて発掘可能な種類の選手の最大数に対して、実際に発掘した種類の選手の数の比率を％表示した値である。例えば、図９に示した例において、エリア９がエリア９−１，９−２，９−３の３つのサブエリアからなる場合、各サブエリアで最大４人の選手（４種類の選手カード）を発掘可能であるとすると、エリア９全体で１２人の選手（１２枚の選手カード）が発掘可能となる。このとき、発掘された選手の数がエリア９全体で６人の場合には、コンプリート率は５０％となる。
図１０に示す例では、ユーザがゲームのスカウト処理において、エリア９が最も進行したエリアであることを示している。なお、図１０では、ユーザは、既にプレイ済みの他のエリア（エリア１〜８）の中でコンプリート率が１００％でないエリアを選択操作することで、選択したエリアの探索を再び行うことができるように構成されている。なお、前述した対抗戦チケットは、ユーザがプレイ済みの他のエリアについて探索を再び行った場合であっても付与されうる。
［強化処理］
前述したように、ゲーム進行手段５２は、２枚以上の選手カードを一体化して特定の選手カードの能力を上昇させる強化処理を実行する機能を備える。このゲームでは、ユーザが強化処理を実行するには一定量の強化ポイントが必要となる。
強化処理は、例えば以下のように行われてよい。強化対象となる選手カード（ユーザによって指定された、残留する選手カード）を選手Ａの選手カードとし、選手Ａの選手カードに一体化させられて消失する選手カードを選手Ｂの選手カードとする。この場合、強化処理では、ＣＰＵ２１が選手Ａの選手カードの「打力」，「走力」，「守備力」の能力値を示すパラメータに対して、選手Ｂの選手カードの「打力」，「走力」，「守備力」の能力値を示すパラメータの一定比率をそれぞれ加算することで、新たな選手Ａの選手カードのパラメータを算出するようにしてもよい。この強化処理によって、選手Ｂの選手カードの能力上の特徴が選手Ａの選手カードに反映されることになる。
強化処理後には、ＣＰＵ２１は、強化処理の後にユーザデータベース３１にアクセスし、対象となるユーザＩＤのユーザデータから選手Ｂの選手カードのデータを削除し、選手数の値を１だけ減少させ、選手Ａの選手カードのパラメータを書き換え、対象となるユーザＩＤの強化ポイントを所定量減少させる。なお、強化ポイントは、上記スカウトパートを実行したり、以下に説明する試合パートを実行したりすることによって増加する。

［対戦処理］
前述したように、ゲーム進行手段５２は、図８のトップページのメニューｍ３の選択操作に応じて、他のユーザのチームと野球の対戦を行う対戦処理を実行する機能を備える。この対戦処理の詳細は、後述するユーザ間対戦実行手段５４と同様であるため、ここでは重複説明を省略する。

［抽選処理］
前述したように、ゲーム進行手段５２は、抽選によって選手カードを入手することを可能とする抽選処理を実行する。抽選処理は、好ましくは、選手カードを抽選箱の中から１枚を取り出す（引く）ような演出を経て実行される。抽選によって出現する選手カードは基本的にランダムであるが、技術能力の際立った選手や人気のある選手の選手カード（いわゆるレアカード）が抽選で出現する確率は非常に低く設定されている。抽選処理には、所定量のエールポイントと引き換えに行われてもよい。

以上、ゲーム進行手段５２の主要な機能（スカウト処理、強化処理、対戦処理、及び抽選処理）について説明した。
ゲーム進行手段５２はさらに、ユーザが保持する各ポイントあるいは選手数に基づいて、ユーザによって選択されたメニューに応じた機能（スカウト処理、強化処理、対戦処理、及び抽選処理）が実行できるか否かを判定し、選択されたメニューに応じた機能が実行できない場合には、機能が実行できないことをユーザに報知するためのテキストを含むページを通信端末１０上に表示する。例えば、１回の探索に行動力が「５」必要となるエリアについてスカウト処理を実行しようとする場合に、ユーザの行動ポイントが「３」のときには、スカウト処理が実行できないため、例えば「行動力が足りません。行動力は３分ごとに１回復します。ゆっくり待ちましょう。」などといったテキストを表示させる。このとき、ゲームサーバ２０のＣＰＵ２１は、ユーザデータベース３１にアクセスして、ユーザの行動ポイントのデータと、探索対象のエリアに要する行動力（既定値）との比較処理を行って、スカウト処理の実行可否を判定する。

上述したように、このゲームでは、図８のユーザデータ表示領域に表示される行動ポイント、運営ポイント、強化ポイント、エールポイント、および選手数は、スカウト処理、強化処理、対戦処理、及び抽選処理の各機能の実行によって変動しうるものとなっている。
なお、スカウト処理、強化処理、対戦処理、及び抽選処理の実行に応じたポイントの増加量及び減少量（消費量）は既定値であるが、その値は、ユーザのゲーム内の状況によって異なってよい。例えば、前述したように、スカウト処理では、探索対象となるエリアごとに必要となる行動力が異なる場合には、スカウト処理の実行による行動ポイントの消費量が、ユーザのゲームの進行度合いによって変化する。例えば、このゲームのスカウト処理では、エリア１、エリア２、…とゲームが進行するにつれて、１回の探索に要する行動力が増加するように設定されている。このとき、図９のメニューｍ１０の選択操作に応じて対抗戦チケットが付与される確率が、表示領域１０１に表示されている行動力に概ね比例した値である場合には、ユーザのエリアの進行に応じて対抗戦チケットが得られる確率が増加することになるため、ユーザがスカウト処理をより多く実行する要因となりうる。

［対抗戦処理］
ゲーム進行手段５２は、後述する受付手段５３、ユーザ間対戦実行手段５４、対抗戦実行手段５５及び特典付与手段５６と協働して、グループ同士で行われる対抗戦の処理を実行する機能を備える。
本実施形態において、対抗戦は、ユーザのチームに応じて複数のユーザをＰグループ（Ｐリーグに属するチームのユーザ）とＱグループ（Ｑリーグに属するチームのユーザ）に分け、ＰグループとＱグループとで戦う、いわば団体戦である。図８では、ユーザ名：ＫＮＭで、かつチーム：Ｐ１のユーザの携帯端末１０に表示されるトップページを例示したが、このユーザが対抗戦にエントリーする場合、Ｐグループに属することになる。対抗戦の勝敗は、Ｐグループに属するユーザとＱグループに属するユーザとの間で行われる複数のユーザ間の対戦（ユーザ間対戦）の結果に基づいて決定される。後述するように、ＰグループとＱグループのいずれか勝利したグループに属するユーザにのみ特典が付与されるか、あるいは、ＰグループとＱグループのいずれか勝利したグループに属するユーザは敗北したグループに属するユーザよりも多くの特典が付与される。

図１２に、図８のトップページのメニューｍ６が選択操作されたときの、ユーザの携帯端末１０上のウェブページの変化の一例を示す。図１２の（ａ）に示される例では、ゲーム進行手段５２は、対抗戦Ｂ１，Ｂ２，Ｂ３，…の複数の対抗戦を選択可能に携帯端末１０に表示させる。
図１２（ａ）のウェブページにおいて、表示領域２００には、ユーザが属するグループ（図１２の例では、Ｐグループ）と、ユーザが所持する対抗戦チケットの枚数（図１２の例では、８枚）とが表示されている。図１２（ａ）のウェブページにおいて、表示領域２０１〜２０３には、それぞれ対抗戦Ｂ１〜Ｂ３についての情報が表示されている。各対抗戦について表示される情報には、対抗戦にエントリーするために必要な対抗戦チケットの枚数が含まれる。例えば、図示の例では、対抗戦Ｂ１にエントリーするためには３枚の対抗戦チケットが必要である。図１２（ａ）には、好ましい表示例として、ユーザが所属するグループが勝利したときにユーザが得られる特典と、対抗戦の状況を示す情報（既に実行されたユーザ間対戦の実行回数、対抗戦の残り時間）とについても、表示領域２０１〜２０３の各々に表示されている。ここで、ユーザが得られる特典は、例えば、イベントポイント（対抗戦Ｂ１の例では、５０ｐｔ）であって、ユーザがゲーム上で利用可能な一定量のポイント（上述したエールポイントや強化ポイント）と交換可能なポイントである。
なお、同一の対抗戦において、ユーザは、対抗戦チケットを消費する限り、何度でもユーザ間対戦を行う（つまり、エントリーする）ことができるようにしてもよい。例えば、ユーザが２０枚の対抗戦チケットを保持している場合には、図１２（ａ）の対抗戦Ｂ１において６回のユーザ間対戦を行うことができるようにしてもよい。

受付手段５３は、異なるグループ（Ｐグループ、Ｑグループ）の間の対戦である対抗戦（グループ間競争）を複数設け、ユーザの操作に応じて、複数の対抗戦のうち少なくともいずれかの対抗戦へのユーザのエントリーを受け付ける機能を備える。
受付手段５３の機能の実現方法の一例について、図１３及び図１４を参照して説明する。図１３は、ユーザの対抗戦へのエントリーを行うときのゲームサーバ２０のＣＰＵ２１の処理を示すフローチャートの一例である。図１４は、対抗戦ごとにエントリーされたユーザのリストであるエントリーリストのデータ構成の一例を示す。エントリーリストは、例えばゲームデータベース３２に記憶されるデータである。

図１３のフローチャートでは先ず、ユーザが図１２（ａ）に示すウェブページにおいていずれかの対抗戦を選択操作することによって、そのユーザの携帯端末１０から、いずれかの対抗戦に対するエントリー要求が通知されると（ステップＳ１０：ＹＥＳ）、ＣＰＵ２１は、ユーザデータベース３１にアクセスして対象となるユーザが所持する対抗戦チケットの枚数（保有チケット枚数；Ｎｕ）を読み出し、ユーザによって選択された対抗戦のエントリーに必要なチケット枚数（Ｎｅｎｔ）と比較する（ステップＳ１２）。なお、対抗戦のエントリーに必要なチケット枚数（Ｎｅｎｔ）は、その対抗戦が設定されるときに決定される値である。ＣＰＵ２１は、保有チケット枚数（Ｎｕ）が、対抗戦のエントリーに必要なチケット枚数（Ｎｅｎｔ）よりも多い場合に（ステップＳ１４：ＹＥＳ）、選択された対抗戦に対するユーザのエントリーを許可し、ユーザのユーザＩＤをエントリーリストに書き込む（ステップＳ１８）。図１４に例示するエントリーリストには、ＰグループとＱグループの各々に属するユーザのユーザＩＤとチームとが対応付けられて記述されている。ＣＰＵ２１は、ユーザにエントリー完了であることを通知するためのＨＴＭＬデータを送信し（ステップＳ１８）、ユーザデータベース３１内のユーザの対抗戦チケットの枚数のデータを、対抗戦のエントリーに必要なチケット枚数だけ減ずる処理を行う（ステップＳ２０）。一方、ＣＰＵ２１は、保有チケット枚数（Ｎｕ）が、対抗戦のエントリーに必要なチケット枚数（Ｎｅｎｔ）よりも少ない場合には（ステップＳ１４：ＮＯ）、選択された対抗戦に対するユーザのエントリーを許可せず、ユーザにエントリー不可であることを通知するためのＨＴＭＬデータを送信する（ステップＳ２２）。
ユーザは、同一の対抗戦に何度でもエントリーしてもよく、その場合には再度ステップＳ１０から処理が行われる。

受付手段５３では、ＣＰＵ２１は、対抗戦を複数設定するに当たって、各対抗戦について対抗戦データを作成する。後述するように、対抗戦データは、例えばゲームデータベース３２に記憶されるデータであって、対抗戦の実行を管理するためのデータである。対抗戦データについて後述する。

ユーザ間対戦実行手段５４は、ユーザがエントリー済みの対抗戦において、ユーザの操作に応じて、異なるグループに属するユーザ間での対戦処理を実行する機能を備える。
ユーザ間対戦実行手段５４の機能は例えば、以下のとおり実現される。図１２の（ａ）に示すウェブページにおいて、エントリー済みのいずれかの対抗戦をユーザが選択する操作を行うと、ゲームサーバ２０のＣＰＵ２１は、図１２の（ｂ）に示すウェブページに遷移させる。図１２の（ｂ）に示すウェブページの例は、ユーザが、エントリー済みの対抗戦Ｂ１を選択した場合の例を示している。このウェブページは、選択された対抗戦（この場合、対抗戦Ｂ１）の状況を示す情報を含む表示領域２０４と、対戦相手の候補である他の複数のユーザの一覧を選択可能に表示する表示領域２０５とを含む。図８に例示した、ユーザ名：ＫＮＭで、かつチーム：Ｐ１のユーザは、Ｐグループに属しているため、ＣＰＵ２１は、例えば、このユーザ向けのウェブページの画像領域２０５に表示する対戦相手の候補として、対抗戦Ｂ１にエントリー済みであり、かつＱグループに属している複数のユーザをランダムに選択する。このとき、対戦するユーザＩＤ同士の技能レベルが同程度であることが好ましい。

以下、ユーザ間での対戦処理を実行するときのゲームサーバ２０のＣＰＵ２１の処理を、図１５及び図１６を参照して説明する。図１５は、ユーザ間での対戦処理を実行するときのゲームサーバ２０のＣＰＵ２１の処理を示すフローチャートである。図１６は、対戦処理が実行されるときにユーザの携帯端末１０に表示されるウェブページの表示例を示す図である。

図１５のフローチャートにおいて先ず、例えば図１２の（ｂ）に示すように、ユーザの携帯端末１０にウェブページにおいて複数の対戦相手の候補のリストが表示される（ステップＳ３０）。いずれかの対戦相手を選択する操作が行われると（ステップＳ３２：ＹＥＳ）、ＣＰＵ２１は、ユーザの携帯端末１０宛に新たなＨＴＭＬデータを送信する。それによって、図１６（ａ）に示すように、ユーザの携帯端末１０には、ユーザによって選択された対戦相手の情報と、「試合開始」のメニューとを含むウェブページが表示される。ここで、「試合開始」のメニューの選択操作がなされると（ステップＳ３４：ＹＥＳ）、ＣＰＵ２１は、ユーザデータベース３１にアクセスして、対戦する各ユーザの選手カードのパラメータを読み出して、対戦結果を決定する（ステップＳ３６）。対戦の実行に当たって、ＣＰＵ２１は、ユーザデータベース３１にアクセスし、対象となるユーザＩＤの運営ポイントが試合の実行に必要とする所定量以上である場合に、運営ポイントからその所定量を減少させるようにしてもよい。

対戦結果の決定方法は、ユーザが保有する選手カードのパラメータ（能力値）がその勝敗に影響を与える方法である限り如何なる方法を採ることができる。例えば、対戦相手となる２つのユーザＩＤに対応付けられた複数の選手カードのパラメータ（能力値）を比較し、パラメータがより大きい選手カードをより多く保有しているユーザが、高い確率（例えば、６０〜９０％の範囲内の所定の確率）をもって勝利するように設定してよい。この勝率は、パラメータの差が大きいほど高い確率としてもよい。このとき、図６に示したように、能力値の項目が複数存在する場合には、所定の重み付け（例えば、図６の例では、「打力」を０．３、「走力」を０．３、「守備力」を０．４の重み付けにする等）をもって総合的な能力値を算出し、この総合的な能力値を比較対象とすることができる。

ＣＰＵ２１は、対戦結果を決定すると対戦結果をユーザに通知するために、その対戦結果を含むウェブページを表示させるＨＴＭＬデータを、「試合開始」のメニューの選択操作を行ったユーザの携帯端末１０宛に送信する（ステップＳ３８）。「試合開始」のメニューを選択する操作が行われてから、対戦結果を含むウェブページが表示されるまの時間は極めて短時間（例えば数秒）であるため、ユーザは、簡易な操作のみで極めて短期間で対戦結果を知ることができる。図１６（ｂ）は、対戦処理の実行によって表示されるウェブページを示す図である。図１６（ｂ）のウェブページでは、例えばスコア等を含む試合結果が表示される。

対抗戦実行手段５５は、複数の対抗戦の各々について、ユーザ同士の対戦であるユーザ間対戦を行うためのユーザの操作を所定時間内、又は所定回数受け入れ、ユーザ間対戦の結果に基づいて、各対抗戦における勝敗を決定する機能を備える。
本実施形態において、対抗戦は、エントリー開始時刻からエントリー終了時刻までの所定時間内、又は予め定められた所定回数だけ、ユーザ間対戦を行うためのユーザの操作を受け入れる。所定時間内、又は所定回数という条件を満たす限り、その対抗戦にエントリー済みの特定のユーザが何度でもユーザ間対戦を実行するようにしてもよいし、特定のユーザが実行可能なユーザ間対戦の数に上限を設定してもよい。

対抗戦実行手段５５の機能を実現するに当たって、ＣＰＵ２１は、図１７に例示する対抗戦データを参照する。対抗戦データは、例えばゲームデータベース３２に記憶されるデータであって、対抗戦の実行を管理するためのデータである。本実施形態では、ＣＰＵ２１は、同時に開催されているｎ個の対抗戦Ｂ１〜Ｂｎを管理している。

対抗戦Ｂ１〜Ｂｎのうちいずれかの対抗戦Ｂｋ（ｋ：１〜ｎ）についての対抗戦データには、対抗戦Ｂｋを設定するときに予め定められる定数のデータとして、以下のデータが含まれる。
・エントリーに必要な対抗戦チケットの枚数（Ｎent＿ｋ）
・エントリー開始時刻
・エントリー終了時刻
・ユーザ間対戦の最大数（Ｃmax＿ｋ）

対抗戦Ｂ１〜Ｂｎのうちいずれかの対抗戦Ｂｋ（ｋ：１〜ｎ）についての対抗戦データには、対抗戦Ｂｋの進行に応じて変化する変数のデータとして、以下のデータが含まれる。ＣＰＵ２１は、ユーザ間対戦の実行に応じてゲームデータベース３２にアクセスし、以下の変数を逐次書き換える。
・実行されたユーザ間対戦の総数（ＣＮＴ＿ｋ）
・Ｐグループの総得点
・Ｑグループの総得点

ＣＰＵ２１は、対抗戦Ｂｋについてのユーザ間対戦を行うためのユーザの操作が所定時間内に限定されている場合、ユーザ間対戦を行うためのユーザの操作を認識すると、対抗戦データのエントリー開始時刻及びエントリー終了時刻を参照して、そのユーザ間対戦の実行を許可するか否かを決定する。ＣＰＵ２１は、対抗戦Ｂｋについてのユーザ間対戦が所定回数までに限定されている場合、ユーザ間対戦を行うためのユーザの操作を認識すると、対抗戦データのユーザ間対戦の最大数を参照して、そのユーザ間対戦の実行を許可するか否かを決定する。
ＣＰＵ２１は、ユーザ間対戦の結果（例えば、対戦のスコア）が決定されると、ゲームデータベース３２にアクセスして、ユーザ間対戦の総数をインクリメントするとともに、ユーザ間対戦においてＰグループ、Ｑグループに属しているユーザが取得した得点をそれぞれ、Ｐグループの総得点、Ｑグループの総得点に加算する。ＣＰＵ２１は、対抗戦Ｂｋについてのエントリー終了時刻に達すると、その時点でのＰグループの総得点及びＱグループの総得点に基づいて、対抗戦ＢｋにおけるＰグループ及びＱグループの勝敗を決定する。例えば、総得点が多い方のグループの勝利とする。

ＣＰＵ２１は、対抗戦の選択を促すウェブページ（図１２（ａ））や、対戦相手の選択を促すウェブページ（図１２（ｂ））を表示するためのＨＴＭＬデータを生成して、ユーザの携帯端末１０宛に送信する。このとき、対抗戦の選択を促すウェブページでは、対抗戦の勝敗が決定されるまでの残り時間及び／又は残り回数が表示されることが好ましい。ここで、「残り時間」は、ユーザが残り時間を認識可能な情報であればよく、図１２（ａ）に示したように対抗戦Ｂｋの残り時間そのものの情報のほか、対抗戦Ｂｋのエントリー終了時刻についての情報であってもよい。「残り回数」は、ユーザが残り回数を認識可能な情報であればよく、残り回数そのものの情報のほか、ユーザ間対戦の現在までの実行回数についての情報であってもよい。例えば、図１２（ａ）に示した例では、対抗戦Ｂ1について「８３／１００試合目」と表示され、ユーザ間対戦の現在までの実行回数が例えば８３回であることが示されているが、この表示からユーザは、対抗戦Ｂ１についての残り回数が１７回であることを認識できる。

対抗戦の勝敗が決定されるまでの残り時間及び／又は残り回数が表示されることによって、その対抗戦にエントリーした方がよいか否かについてユーザに検討させることになり、ゲームの興趣性が増す。例えば、対抗戦の残り時間及び／又は残り回数が少ない場合には、ユーザは、その対抗戦にエントリーすることで、対抗戦で勝利した場合等に与えられる特典を早く得る可能性が高くなるが、一方、自らがその対抗戦におけるユーザ間対戦を繰り返し行って自らのグループの勝利に貢献できる機会が少なくなる。なお、後述する変形例３では、自らのグループが勝利した場合の貢献度に伴う特典を得る場合について記載しているが、その場合には、対抗戦の残り時間及び／又は残り回数が少ない場合には、貢献度に伴う特典を得る可能性が低くなる。逆に、対抗戦の残り時間及び／又は残り回数が多い場合には、ユーザは、その対抗戦にエントリーすることで、対抗戦で勝利した場合等に与えられる特典が得られうるタイミングが遅くなるが、一方、自らがその対抗戦におけるユーザ間対戦を繰り返し行って自らのグループの勝利に貢献できる機会が多くなる。なお、後述する変形例３では、自らのグループが勝利した場合の貢献度に伴う特典を得る場合について記載しているが、その場合には、対抗戦の残り時間及び／又は残り回数が多い場合には、貢献度に伴う特典を得る可能性が高くなる。

ＣＰＵ２１は、対抗戦の選択を促すウェブページ（図１２（ａ））を表示するためのＨＴＭＬデータを生成するに当たって、対抗戦データを参照して、エントリーに必要な対抗戦チケットの枚数についての情報を含めるようにする。例えば、図１２（ａ）に示したウェブページでは、対抗戦Ｂ１にエントリーするのに必要な対抗戦チケットの枚数が「３枚」と表示される。
ＣＰＵ２１は、エントリー済みのユーザ向けのウェブページには、そのユーザが属しているグループの現時点における総得点を逐次表示するようにしてもよい。例えば、図１２（ｂ）に示したように、Ｐグループに属しているユーザ向けのウェブページには、「Ｐグループ２５０得点ＸＱグループ？？？得点」と表示されている。これによって、ユーザは、自グループの現時点の総得点から自グループが有利であるのか不利であるのかを推測し、ユーザ間対戦を行うか否か判断することができる。つまり、自グループが不利であると判断されれば、ユーザにとって、積極的にユーザ間対戦を行って自グループの挽回を図る動機付けとなる。
なお、図１２（ｂ）に示したように、相手グループであるＱグループの総得点を表示しないようにしてもよい。これにより、グループ間の総得点差がユーザに分からなくなるため、ユーザは、自グループの現在の総得点と残り時間及び／又は残り回数に基づいてユーザ間対戦を行うべきか否か（つまり、自グループを助けるべきか否か）について判断するようになり、ゲームの興趣性が増す。また、対抗戦のグループ間の総得点差が多過ぎることがユーザに分かってしまうと、ユーザ間対戦を行っても大勢に影響がないとユーザに判断され、その対抗戦にエントリーする誘因を削ぐことになって好ましくない。

特典付与手段５６は、ユーザが所属している（つまり、ユーザに対応付けられている）グループの対抗戦における勝敗に基づいて、当該ユーザに対して特典を付与するか否か、又は当該ユーザに対して付与する特典の内容を決定する機能を備える。ユーザに付与される特典の内容は、特に限定するものではないが、本実施形態の例では、イベントポイントである。イベントポイントは、前述したように、ユーザがゲーム上で利用可能な一定量のポイント（上述したエールポイントや強化ポイント）や、ゲームにおけるアイテム（例えば、選手カード等）と交換可能なポイントであってよい。対抗戦にエントリーしたすべてのユーザに対して特典を付与する場合には、対抗戦に勝利したグループに属しているユーザは、対抗戦に敗北したグループに属しているユーザよりも多くの特典が得られるようにすることが好ましい。
例えば図１２（ａ）のウェブページに表示されているポイント（例えば対抗戦Ｂ１の場合には、５０ｐｔ（ポイント））は、自グループが勝利したときにユーザが得られる特典であり、エールポイント、強化ポイント等のゲーム上で利用可能なポイントに変換可能なポイントであってよい。

特典付与手段５６の機能は、以下のようにして実現できる。なお、対抗戦における勝敗に基づいてユーザに対して特典を付与するか否か、又はユーザに対して付与する特典の内容については、予めＲＯＭ２２に記録されているものとする。ゲームサーバ２０のＣＰＵ２１は、対抗戦Ｂｋについての勝敗を決定すると、勝利したグループに属しているユーザにのみ特典を付与するように設定されている場合には、ゲームデータベース３２の対抗戦Ｂｋについてのエントリーリストを参照して、勝利したグループに属しているユーザを特定する。ＣＰＵ２１は、勝利したグループ、及び敗北したグループに属しているユーザに特典を付与するように設定されている場合には、ゲームデータベース３２の対抗戦Ｂｋについてのエントリーリストを参照して、勝利したグループに属しているユーザ、及び敗北したグループに属しているユーザを特定する。ＣＰＵ２１は、対象となるユーザを特定すると、ＲＯＭ２２を参照して、各ユーザに対して付与すべき特典の内容を決定し、特典を付与する処理を行う。なお、特典を付与する処理とは、付与対象となるユーザのユーザＩＤと、付与されるポイントやアイテムを関連付ける処理であってよい。例えば、特典として付与されたイベントポイントに相当する強化ポイントをユーザに与える場合、ＣＰＵ２１は、付与対象となるユーザのユーザＩＤのユーザデータにおける強化ポイントを書き換える処理（与えられたポイントを加算する処理）であってよい。

（６）本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、図１８Ａ及び図１８Ｂのフローチャートを参照して説明する。図１８Ａ及び図１８Ｂのフローチャートは、主として受付手段５３、ユーザ間対戦実行手段５４、対抗戦実行手段５５、及び特典付与手段５６によって実行される処理であり、ゲームサーバ２０によって管理される複数の対抗戦の各々を対象として行われる。

図１８Ａにおいて、対抗戦Ｂｋ（ｋ：１〜ｎ）のエントリー開始時刻に達すると（ステップＳ１００：ＹＥＳ）、対抗戦Ｂｋについてのエントリーが開始される（ステップＳ１１０）。ステップＳ１１０以降、ユーザは、対抗戦Ｂｋにエントリーし、次いで対抗戦Ｂｋにおけるユーザ間対戦を実行するための操作を行うことができる。ここでは、図１３のフローチャートに従って、ユーザが対抗戦Ｂｋにエントリー済みである場合を想定する。
ユーザが、図８に例示したトップページ上でメニューｍ６を選択操作すると、例えば図１２の（ａ）に示すように、現在開催中の複数の対抗戦のリストを含むウェブページが表示される。この対抗戦のリストの中から対抗戦Ｂｋを選択する操作をユーザが行うと（ステップＳ１２０：ＹＥＳ）、選択された対抗戦Ｂｋに対するエントリー要求を含むメッセージがゲームサーバ２０宛に送信されて、図１３に示したようにユーザのエントリー要求が処理される。エントリーが完了すると、ゲームサーバ２０は、図１２の（ｂ）に示すウェブページを表示するＨＴＭＬデータを送信する。それにより、ユーザの対抗戦Ｂｋにおけるユーザ間対戦の対戦相手の候補のリストを含むウェブページがユーザの携帯端末１０に表示され、ユーザのいずれかの対戦相手の候補の選択操作に応じてユーザ間対戦が実行される（ステップＳ１３０）。ユーザ間対戦の処理は、図１５のフローチャートに関連付けて説明した通りである。

ゲームサーバ２０は、ユーザ間対戦が終了する度に、ゲームデータベース３２内の対抗戦データにアクセスし、ユーザ間対戦による得点（スコア）を対抗戦ＢｋにおけるＰグループの総得点、及びＱグループの総得点に加算するとともに（ステップＳ１４０）、実行されたユーザ間対戦の総数ＣＮＴ＿ｋをインクリメントする（ステップＳ１５０）。ここで、ユーザ間対戦の総数ＣＮＴ＿ｋが所定のユーザ間対戦の最大数Ｃmax＿ｋに達したか（ステップＳ１６０：ＹＥＳ）、あるいは現在時刻がエントリー終了時刻に達した場合には（ステップＳ１７０：ＹＥＳ）、エントリー終了となる（ステップＳ１８０）。ステップＳ１６０又はステップＳ１７０の条件を満たさなければ、ステップＳ１２０に戻って次のユーザ間対戦を受け付ける。なお、ステップＳ１６０とステップＳ１７０のＡＮＤ条件を満たす（両条件を満たす）場合にエントリー終了としてもよい。

ゲームサーバ２０は、ステップＳ１８０でエントリー終了となった場合には、それ以降、ユーザが対抗戦Ｂｋにエントリーを行うことを許可せず、既に対抗戦Ｂｋにエントリー済みのユーザが対抗戦Ｂｋについてのユーザ間対戦を行うことを許可しない。エントリー終了になると、ゲームサーバ２０は、ゲームデータベース３２内の対抗戦データにおける対抗戦ＢｋのＰグループの総得点、及びＱグループの総得点に基づいて、ＰグループとＱグループの勝敗を決定する（ステップＳ１９０）。次いで、ゲームサーバ２０は、ユーザが所属しているグループの対抗戦Ｂｋにおける勝敗に基づいて、当該ユーザに対して特典を付与するか否か、又は当該ユーザに対して付与する特典の内容を、ゲームデータベース３２内の対抗戦Ｂｋのエントリーリストを参照して決定する。ユーザに付与される特典の内容は、例えば、例えば、一定量のエールポイント、強化ポイント等のゲーム上で利用可能なポイントである。

上述したように、このゲーム制御装置によれば、異なるグループの間の競争である対抗戦を複数設け、各対抗戦において、異なるグループに属しているユーザ同士のユーザ間対戦を実行するためのユーザの操作を所定時間内、又は所定回数受け入れて、ユーザ間対戦の結果に基づいて対抗戦における勝敗を決定するように構成されている。そのため、複数のユーザ同士が共同で競い合う、いわば団体戦をゲーム上で実現することができる。また、ユーザは、複数の対抗戦に対して同時間帯にエントリーして対戦することが可能であり、現実世界では不可能な団体戦を実現することができる。また、このゲーム制御装置によれば、ユーザが属しているグループの対抗戦における勝敗に基づいて、当該ユーザに対して特典を付与するか否か、又は当該ユーザに対して付与する特典の内容を決定するように構成されているため、ユーザの対抗戦へのエントリー、さらにはエントリーした対抗戦における積極的なユーザ間対戦の実行をユーザに動機付けることができる。

（７）変形例
（７−１）変形例１
上記実施形態において、受付手段５３は、１つの対抗戦の勝敗が決定される毎に新たな対抗戦を設けることによって、ユーザに対して所定数の対抗戦を選択可能にしてもよい。このように、１つの対抗戦の勝敗が決定されてから新たな対抗戦を設けることで、ゲームの進行にスピード感を与え、ユーザを飽きさせないようにすることができる。仮に、対抗戦を予め多数準備しておくと、ユーザが選択に迷うだけでなく、個々の対抗戦へのユーザ参加人数が分散してしまうことになる。従って、個々の対抗戦の勝敗の決定までの時間が長くなり、この結果、対抗戦の結果としての特典が与えられるまでの時間も長くなってしまい、ユーザに冗長感を与えてしまう可能性がある。そこで、上記構成のようにすることで、ユーザは常に、所定数の限られた対抗戦の中から参加する対抗戦を容易に決定することができ、また、対抗戦の勝敗決定も迅速に行われることから、特典を得るまでの時間も短くすることができ、ユーザにゲームを飽きさせないようにすることができる。

図１９に、ｎ個の対抗戦Ｂ１〜Ｂｎが常に設定される対抗戦の設定方法を概念的に示す。図１９では、ｎ個の対抗戦Ｂ１〜Ｂｎの各々の終了時刻が対抗戦ごとに異なりうるが、１つの対抗戦が終了すると、直ちに次の対抗戦が開始するようにして、ｎ個の対抗戦Ｂ１〜Ｂｎが常時開催される例を示している。例えば、対抗戦Ｂ１のエントリー終了時刻に達すると直ちに、新たな対抗戦Ｂ１のエントリー開始時刻が設定される。なお、例えば、連続する２つの対抗戦（例えば連続する２つの対抗戦Ｂ１）において、対抗戦に設定される条件（つまり、図１７の定数の値）は同じなくてもよく、別個に設定されてよい。このように、常に所定数の対抗戦を開催するように設定することで、ユーザは常に、所定数の対抗戦の中からエントリーする対抗戦を決定することができ、ユーザにゲームを飽きさせないようにすることができる。また、ｎ個の対抗戦の各々についてそれぞれ特徴付けた対抗戦（例えば、大阪対抗戦、埼玉対抗戦など）としてもよく、その場合、ユーザは愛着のある対抗戦に継続的にエントリーすることが考えられる。

本変形例の受付手段５３の機能は、図２０のフローチャートを参照して以下のようにして実現することができる。ゲームサーバ２０のＣＰＵ２１は、いずれかの対抗戦が終了すると（ステップＳ３００：ＹＥＳ）、新たな対抗戦を設定し（ステップＳ３１０）、エントリーに必要な対抗戦チケットの枚数、エントリー開始時刻、エントリー終了時刻、ユーザ間対戦の最大数の値を決定する。対抗戦チケットの枚数、ユーザ間対戦の最大数の値等はランダムに決定してよい。対抗戦におけるユーザ間対戦を実行するためのユーザの操作を所定時間内に受け入れる場合には、エントリー開始時刻、エントリー終了時刻を予め規定する。対抗戦におけるユーザ間対戦を実行するためのユーザの操作を所定時間受け入れる場合には、ユーザ間対戦の最大数の値を予め規定する。常時所定数の対抗戦を開催しているようにするため、終了した対抗戦（例えば、前の対抗戦Ｂ１）のエントリー終了時刻から新たな対抗戦（例えば、後の対抗戦Ｂ１）のエントリー開始時刻は、極力近接していることが好ましい。新たな対抗戦を設定すると、ＣＰＵ２１は、ゲームデータベース３２にアクセスして対抗戦データを更新する。

（７−２）変形例２
上記実施形態において、受付手段５３は、設定する対抗戦について様々な種別や仕掛けを設けるようにしてもよい。この点について、図２１及び図２２を参照して説明する。図２１は、対抗戦の選択をユーザに促すウェブページにおいて、一部の対抗戦に特別なアイテムとしてプレゼント袋１８５を設定した例を示している。図２２は、(ａ)に対抗戦の種類を例示し、（ｂ）にプレゼント袋の種類を例示する図である。
受付手段５３によって対抗戦を新たに設定する場合、例えば図２２（ａ）示されるように複数の対抗戦の種類Ｂａ，Ｂｂ，Ｂｃ，…の中から所定の発生確率をもって選択するようにしてもよい。この例では、エントリーに必要となる対抗戦チケットの枚数が３枚である場合に種類Ｂａ，Ｂｂ，Ｂｃの３種類の対抗戦が用意され、この順で、発生しにくい（レアな）対抗戦の種類となっており、この順で勝利あるいは敗北したときに得られる特典が大きく設定されている。
また、図２１及び図２２（ｂ）に示すように、例えばエントリーに必要となる対抗戦チケットの枚数が比較的多い場合（図の例では、１０枚）に、所定の確率で複数の種類のプレゼント袋の中からいずれかのプレゼント袋を対抗戦に設定してもよい。この場合、プレゼント袋が設定された対抗戦では、ユーザは、自グループが勝利したときに、通常の特典に加え、プレゼント袋によって規定されている特典がさらに付与される。このようなプレゼント袋を発生させることによって、ゲームの興趣性を高めることができる。

（７−３）変形例３
特典付与手段５６は、１つの対抗戦について、ユーザによるユーザ間対戦の実行回数に応じて、当該ユーザが属しているグループが勝利したときに当該ユーザに対して付与する特典を増加あるいは減少させるようにしてもよい。例えば、ユーザが属しているグループが勝利した場合、そのユーザのユーザ間対戦の実行回数が多い場合には、そのユーザの貢献度が高いと判断し、そのユーザに対する特典を増加させてもよい。逆に、ユーザが属しているグループが勝利した場合、そのユーザのユーザ間対戦の実行回数が少ない、またはゼロであった場合には、そのユーザの貢献度が少ないと判断し、そのユーザに対する特典を減少させてもよい。このような仕組みとすることで、対抗戦にエントリーしたユーザに対し、多くのユーザ間対戦を実行して勝利することを動機付けることができる。
本変形例の特典付与手段５６では、ゲームサーバ２０のＣＰＵ２１は、対抗戦についてエントリーしたユーザごとにユーザ間対戦を実行した回数をカウントしておき、対抗戦が終了した後に、そのカウント値に基づき、勝利したグループに属するユーザに対して付与される特典を決定すればよい。

（７−４）変形例４
特典付与手段５６は、１つの対抗戦について、ユーザが属しているグループに有利となったユーザ間対戦の実行回数に応じて、当該ユーザに対応付けられているグループが勝利したときに当該ユーザに対して付与する特典を増加あるいは減少させてもよい。
ユーザが属しているグループに有利となったユーザ間対戦とは、例えば、ユーザがユーザ間対戦で勝利することで、そのユーザが属するグループの総得点が、対戦相手の属するグループの総得点よりも多くの得点が加算されたことを意味する。そのようなユーザ間対戦の実行回数が多いほど、ユーザがグループの勝利に貢献したと判断することができる。このような仕組みとすることで、対抗戦にエントリーしたユーザに対し、多くのユーザ間対戦を実行して勝利することを動機付けることができる。
本変形例の特典付与手段５６では、ゲームサーバ２０のＣＰＵ２１は、対抗戦についてエントリーしたユーザごとに、ユーザ間対戦で勝利した回数をカウントしておき、対抗戦が終了した後に、そのカウント値に基づき、勝利したグループに属するユーザに対して付与される特典を決定すればよい。

（７−５）変形例５
ユーザ間対戦で勝利したユーザに対して特典を付与する第２の特典付与手段、を備えてもよい。これにより、ユーザは、ユーザ間対戦で勝利することで直ちに特典が得られる上、対抗戦の結果次第で（つまり、自らのグループが勝利したときに）さらに特典が得られるため、対抗戦への参加意欲を高めることができる。なお、第２の特典付与手段で付与される特典は、特典付与手段５６で付与される特典と同様に、特に限定するものではなく、例えば、ゲーム上で利用可能なポイント（例えば、エールポイント、強化ポイント等）や、ゲームにおけるアイテム（例えば、選手カード等）と交換可能なイベントポイントであってよい。

（７−６）変形例６
上述した実施形態において、ユーザが保有可能な対抗戦チケットの枚数に上限が設定されていてもよい。つまり、上述したように、受付手段５３は、対抗戦ごとに予め定められた枚数の対抗戦チケットと引き換えにユーザの対抗戦へのエントリーを許可するが、この対抗戦チケットについてユーザが保有可能な総量が制限されていてもよい。このように制限すると、ユーザが大量の対抗戦チケットを１つの対抗戦につぎ込む（つまり、多くのユーザ間対戦を実行する）ことで特定のユーザのユーザ間対戦が対抗戦の結果に影響を与え過ぎることを防止することができる。

以上、本発明の実施形態について詳細に説明したが、本発明は上記実施形態に限定されない。また、各実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。
例えば、上述した実施形態では、適用されるゲームが野球形式のデジタルカードゲームである場合を想定したが、ゲームの種別は如何なるものでもよい。その場合、ゲームサーバ２０が取得可能なユーザの情報に基づいて、ユーザとグループの対応付け（グループ分け）は様々な観点から行うことができる。例えば、ユーザが登録したチームごとのグループ分け、国籍によるグループ分け、性別によるグループ分け等に行うことができる。
上述した実施形態では、競争が野球の対戦である場合を想定したが、競争はゲームの種別に応じて適宜定義できることは勿論である。例えば、複数のステージを制覇することを競うゲームであれば、競争は、一定時間に制覇したステージ数を競うものであってもよい。

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

１０…通信端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１４…画像処理部
１５…操作入力部
１６…表示部
１７…無線通信インタフェース部
１８…バス
２０…ゲームサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…データベースアクセス部
２５…通信インタフェース部
２６…バス
３０…データベースサーバ
３１…ユーザデータベース
３２…ゲームデータベース
５１…登録手段
５２…ゲーム進行手段
５３…受付手段
５４…ユーザ間対戦実行手段
５５…対抗戦実行手段
５６…特典付与手段

Claims (11)

1. ユーザによって操作される通信端末からアクセス可能に構成され、前記通信端末によるゲームの実行を制御するゲーム制御装置であって、
   ユーザの操作に基づいて、ユーザを複数のグループのいずれかに対応付ける対応付け手段と、
   異なるグループの間の競争であるグループ間競争を複数設け、ユーザの操作に応じて、複数のグループ間競争のうち少なくともいずれかのグループ間競争へのユーザの参加を受け付ける受付手段と、
   ユーザの参加を受け付けたグループ間競争において、当該ユーザと、当該ユーザとは異なるグループに対応付けられている他のユーザとの間の前記ゲーム上の競争であるユーザ間競争を実行するためのユーザの操作を所定時間内、又は所定回数受け入れ、ユーザ間競争の結果に基づいて前記グループ間競争における勝敗を決定する競争実行手段と、
   ユーザに対応付けられているグループのグループ間競争における勝敗に基づいて、当該ユーザに対して特典を付与するか否か、又は当該ユーザに対して付与する特典の内容を決定する特典付与手段と、
   前記グループ間競争の勝敗が決定されるまでの残り回数を表示する表示手段と、
   を備えた、ゲーム制御装置。
2. 前記受付手段は、各グループ間競争へのユーザの参加を、グループ間競争ごとに設定された量のアイテムをユーザが消費することによって受け付け、
   前記アイテムについてユーザがゲーム上で保有可能な総量が制限されていることを特徴とする、
   請求項１に記載されたゲーム制御装置。
3. 前記特典付与手段は、前記ユーザによって消費されるアイテムの量が多い場合に、消費されるアイテムの量が少ない場合よりも、前記ユーザに対応付けられているグループがグループ間競争で勝利したときに付与される特典を大きくすることを特徴とする、
   請求項１又は２に記載されたゲーム制御装置。
4. 前記特典付与手段は、１つのグループ間競争について、ユーザによる前記ユーザ間競争が実行された回数に応じて、当該ユーザに対応付けられているグループが勝利したときに当該ユーザに対して付与する特典を増加あるいは減少させることを特徴とする、
   請求項１〜３のいずれかに記載されたゲーム制御装置。
5. 前記特典付与手段は、１つのグループ間競争について、ユーザに対応付けられているグループに有利となったユーザ間競争が実行された回数に応じて、当該ユーザに対応付けられているグループが勝利したときに当該ユーザに対して付与する特典を増加あるいは減少させることを特徴とする、
   請求項１〜３のいずれかに記載されたゲーム制御装置。
6. 前記受付手段は、１つのグループ間競争の勝敗が決定される毎に新たなグループ間競争を設けることによって、ユーザに対して所定数のグループ間競争を選択可能にすることを特徴とする、
   請求項１〜５のいずれかに記載されたゲーム制御装置。
7. 前記受付手段は、各グループ間競争へのユーザの参加を、ユーザがゲーム上の一定量のアイテムを消費することによって受け付け、
   前記アイテムについてユーザがゲーム上で保有可能な総量が制限されていることを特徴とする、
   請求項１〜６のいずれかに記載されたゲーム制御装置。
8. 前記ユーザ間競争で勝利したユーザに対して特典を付与する第２の特典付与手段、を備えた、
   請求項１〜７のいずれかに記載されたゲーム制御装置。
9. ユーザによって操作される通信端末からアクセス可能に構成され、前記通信端末によるゲームの実行を制御するゲーム制御装置、におけるゲーム制御方法であって、
   ユーザの操作に基づいて、ユーザを複数のグループのいずれかに対応付けるステップと、
   異なるグループの間の競争であるグループ間競争を複数設け、各グループ間競争の勝敗が決定されるまでの残り回数を表示するステップと、
   ユーザの操作に応じて、複数のグループ間競争のうち少なくともいずれかのグループ間競争へのユーザの参加を受け付けるステップと、
   ユーザの参加を受け付けたグループ間競争において、当該ユーザと、当該ユーザとは異なるグループに対応付けられている他のユーザとの間の前記ゲーム上の競争であるユーザ間競争を実行するためのユーザの操作を所定時間内、又は所定回数受け入れ、ユーザ間競争の結果に基づいて前記グループ間競争における勝敗を決定するステップと、
   ユーザに対応付けられているグループのグループ間競争における勝敗に基づいて、当該ユーザに対して特典を付与するか否か、又は当該ユーザに対して付与する特典の内容を決定するステップと、
   を備えた、ゲーム制御方法。
10. ユーザによって操作される通信端末によるゲームの実行を制御するために、コンピュータに、
    ユーザの操作に基づいて、ユーザを複数のグループのいずれかに対応付ける機能、
    異なるグループの間の競争であるグループ間競争を複数設け、ユーザの操作に応じて、複数のグループ間競争のうち少なくともいずれかのグループ間競争へのユーザの参加を受け付ける機能、
    ユーザの参加を受け付けたグループ間競争において、当該ユーザと、当該ユーザとは異なるグループに対応付けられている他のユーザとの間の前記ゲーム上の競争であるユーザ間競争を実行するためのユーザの操作を所定時間内、又は所定回数受け入れ、ユーザ間競争の結果に基づいて前記グループ間競争における勝敗を決定する機能、
    ユーザに対応付けられているグループのグループ間競争における勝敗に基づいて、当該ユーザに対して特典を付与するか否か、又は当該ユーザに対して付与する特典の内容を決定する機能、及び
    前記グループ間競争の勝敗が決定されるまでの残り回数を表示する機能、
    を実現させるためのプログラム。
11. ユーザによって操作される通信端末と、当該通信端末からアクセス可能に構成され、前記通信端末によるゲームの実行を制御するゲーム制御装置と、を含むゲーム制御システムであって、
    前記ゲーム制御装置は、
    ユーザの操作に基づいて、ユーザを複数のグループのいずれかに対応付ける対応付け手段と、
    異なるグループの間の競争であるグループ間競争を複数設け、ユーザの操作に応じて、複数のグループ間競争のうち少なくともいずれかのグループ間競争へのユーザの参加を受け付ける受付手段と、
    ユーザの参加を受け付けたグループ間競争において、当該ユーザと、当該ユーザとは異なるグループに対応付けられている他のユーザとの間の前記ゲーム上の競争であるユーザ間競争を実行するためのユーザの操作を所定時間内、又は所定回数受け入れ、ユーザ間競争の結果に基づいて前記グループ間競争における勝敗を決定する競争実行手段と、
    ユーザに対応付けられているグループのグループ間競争における勝敗に基づいて、当該ユーザに対して特典を付与するか否か、又は当該ユーザに対して付与する特典の内容を決定する特典付与手段と、
    前記グループ間競争の勝敗が決定されるまでの残り回数を表示する表示手段と、を備えた、
    ゲーム制御システム。

Images