JP2013215375A - ゲーム制御装置、ゲーム制御方法、プログラム、ゲーム制御システム - 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＿ｋ）

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

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

通知手段５６は、以下の情報のうち少なくともいずれかを通信端末１０宛に通知する機能を備える。
・対抗戦Ｂｋのエントリー開始時刻からの経過時間（「第１の時間」）
・対抗戦Ｂｋのエントリー開始時刻からのユーザ間対戦の総数（「第１の数」）
・対抗戦Ｂｋのエントリー終了時刻までの残り時間（「残り時間」）
・対抗戦Ｂｋのエントリー終了時刻までのユーザ間対戦の残り回数（「残り回数」）

例えば、図１２（ａ）では、ユーザが選択可能な対抗戦毎に、対抗戦のエントリー開始時刻からのユーザ間対戦の総数（第１の数）と、対抗戦のエントリー終了時刻までの残り時間とが通知される例が示されている。

通知手段５６の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、対抗戦の選択を促すウェブページ（図１２（ａ））や、対戦相手の選択を促すウェブページ（図１２（ｂ））を表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。このとき、ＣＰＵ２１は、図８のトップページのメニューｍ６が選択操作されたタイミング（より具体的には、メニューｍ６の選択操作に応じたＨＴＴＰリクエストを受信して処理するタイミング）における時刻（「基準時刻」という。）に基づいて、対抗戦データを参照して、対抗戦毎に、上述した第１の時間、第１の数、残り時間、及び残り回数の少なくともいずれかを算出する。例えば、図１７の対抗戦データにおいて、対抗戦Ｂ１についての第１の時間は、対抗戦Ｂ１のエントリー開始時刻から基準時刻までの間の時間として算出される。対抗戦Ｂ１についての第１の数は、基準時刻における変数ＣＮＴ＿１である。対抗戦Ｂ１についての残り時間は、基準時刻からエントリー終了時刻までの間の時間として算出される。対抗戦Ｂ１についての残り回数は、Ｃmax＿１から基準時刻における変数ＣＮＴ＿１を減算した値として算出される。

通知手段５６は、各対抗戦についてエントリーするのに必要な対抗戦チケットの枚数を通知する機能を備えていてもよい。この場合、ＣＰＵ２１は、対抗戦の選択を促すウェブページ（図１２（ａ））を表示するためのＨＴＭＬデータを生成するに当たって、対抗戦データを参照して、エントリーに必要な対抗戦チケットの枚数についての情報を含めるようにする。例えば、図１２（ａ）に示したウェブページでは、対抗戦Ｂ１にエントリーするのに必要な対抗戦チケットの枚数が「３枚」と表示される。

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

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

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

第２の特典付与手段５８は、対抗戦の第１の時間（つまり、エントリー開始時刻からの経過時間）に応じて、あるいは第１の数（つまり、エントリー開始時刻から実行されたユーザ間対戦の総数）に応じて変動する第２の特典を、その対抗戦へエントリーしたユーザに対して付与する機能を備える。なお、第２の特典は、第１の時間に代えて残り時間（つまり、エントリー受付時刻からエントリー終了時刻までの残り時間）に応じて、あるいは第１の数に代えて残り回数（つまり、エントリー受付時刻からエントリー終了時刻までのユーザ間対戦の残り回数）に応じて変動するものであってもよい。

第２の特典付与手段５８の機能は、以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、対象となる対抗戦についてエントリーリストを参照して、特典付与の対象となるユーザを特定する。また、ＣＰＵ２１は、特典付与の対象となる各ユーザについて、エントリー開始時刻と、エントリー開始時刻までに実行されたユーザ間対戦の総数とを読み出して、第１の時間、第１の数、残り時間、あるいは残り回数のうち少なくともいずれかを算出する。例えば、第１の時間、第１の数、残り時間、あるいは残り回数のうちいずれかと、第２の特典とを対応付ける対応付けデータを例えばＲＯＭ２２に記録しておき、ＣＰＵ２１は、その対応付けデータを参照して、各ユーザに付与する第２の特典の内容を決定する。
第２の特典をユーザに付与する処理は、付与対象となるユーザのユーザＩＤと、第２の特典として付与されるポイントやアイテムを関連付ける処理であってよい。例えば、第２の特典として付与されたイベントポイントに相当する強化ポイントをユーザに与える場合、ＣＰＵ２１は、付与対象となるユーザのユーザＩＤのユーザデータにおける強化ポイントを書き換える処理（与えられたポイントを加算する処理）であってよい。

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

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

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

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

次に、ＣＰＵ２１は、さらに対抗戦Ｂｋについてエントリーリストを参照し、対抗戦Ｂｋにエントリーしたユーザに対して第２の特典を付与する（ステップＳ２１０）。すなわち、ＣＰＵ２１は、エントリーした各ユーザについて、エントリー受付時刻に応じた第１の時間、第１の数、残り時間、あるいは残り回数のうち少なくともいずれかを算出し、これらの値に応じた第２の特典の内容を、例えばＲＯＭ２２に記憶するデータを参照して決定する。ユーザに付与される第２の特典の内容は、例えば、一定量のエールポイント、強化ポイント等のゲーム上で利用可能なポイントである。

上述したように、上記ゲーム制御装置では、ユーザが他のユーザと対戦する個別のユーザ間対戦の結果の総計に基づき、各ユーザが予め対応付けられているグループとしての対抗戦の結果が決定される。すなわち、個々のユーザは自分自身の対戦を行うが、その対戦結果が、対抗戦の結果に間接的に結びついているという構成を備えたものである。しかも、このゲーム制御装置によれば、ユーザが対応付けられているグループの対抗戦における結果（勝敗等）に基づいて、当該ユーザに対して第１の特典を付与するか否か、又は当該ユーザに対して付与する第１の特典の内容を決定するように構成されているため、対抗戦にエントリー（参加）して積極的にユーザ間対戦を実行することをユーザに動機付けることができる。ユーザは同一の対抗戦に対して、繰り返しエントリーすることができる。
また、このゲーム制御装置では、ユーザが対抗戦にエントリーした時点の対抗戦の状況（第１の時間、あるいは第１の数）に応じて変動する第２の特典を、ユーザに付与する。このとき、対抗戦の状況（第１の時間、第１の数、残り時間、又はユーザ間対戦の残り回数）がユーザに通知されるため、ユーザは、対抗戦の状況と、付与される第２の特典とを勘案しながら、対抗戦にエントリーすべきか否か判断するように構成されているため、興趣性の高いゲームを実現することができる。

なお、上述した実施形態では、登録手段５１（対応付け手段）がユーザをＰグループ又はＱグループに対応付け、受付手段５３は、異なるグループの間の競争である対抗戦を複数設け、ユーザの操作に応じて、複数の対抗戦のうち少なくともいずれかの対抗戦へのユーザのエントリー（参加）を受け付ける場合について示したが、これに限られない。グループ間競争としての対抗戦は単一でもよい。すなわち、上記実施形態のように、ユーザが複数の対抗戦の中からまず任意の対抗戦を選択するのではなく、１つの対抗戦のみが設けられており、その1つの対抗戦の中で、ユーザが任意の対戦相手のユーザを選択するといった形態でもよい。なお、対抗戦を複数設ける場合には、各ユーザは、複数の対抗戦に対して同時間帯にエントリーしてユーザ間対戦を並行して行うことが可能であり、現実世界では不可能な団体戦を実現することができる。また、このように複数の対抗戦にエントリーすることで、ユーザは、各対抗戦における複数の特典を同時に、あるいは時間を前後して獲得する可能性も見込めるので、遊戯性が向上する。さらに、このような複数の特典を獲得しようとする場合には、複数の対抗戦にエントリーするための対抗戦チケットが必要になるので（例えば、上述した実施形態の例では、１対抗戦にエントリーするために３チケット、３つの対抗戦にエントリーするために９チケットが必要）、ユーザはこの対抗戦チケットを入手しようとして、図１０に示すスカウト処理を積極的に行うようになる。つまり、対抗戦が複数設けられる場合には、ユーザは対抗戦のみではなく、この対抗戦に連携した他のモード（スカウト処理等）についてもより積極的に行うようになることが動機づけられるので、単一のゲームモードを遊戯するだけではない深いゲーム性が実現される。

（７）変形例
（７−１）変形例１
上述した実施形態のゲーム制御装置において、第２の特典付与手段５８は、対抗戦において、第１の時間（つまり、エントリー開始時刻からの経過時間）が短いほど、あるいは第１の数（つまり、エントリー開始時刻から実行されたユーザ間対戦の総数）が少ないほど、その対抗戦においてユーザ間対戦の操作を行ったユーザに対して付与する第２の特典を大きくしてもよい。なお、特典の大きさは、付与されるポイントやアイテム等の数などの定量的に評価可能な指標に限られず、希少性を考慮したものであってよい。例えば、１つのアイテムが付与される場合であっても、希少性の高い（レアな）アイテムは希少性の低い（比較的流通している）アイテムよりも大きい特典である。

この構成では、対抗戦の受付を開始してから早いタイミングでその対抗戦に参加するほど、大きい第２の特典を得ることができるため、ユーザは、早めにその対抗戦においてユーザ間対戦を実行することを動機付けられる。
同時に、ユーザが、対抗戦の受付終了間際になって駆け込み的にその対抗戦でユーザ間対戦を実行して短時間で特典を得ることを抑制できる。つまり、仮に第２の特典が一定であり、対抗戦の受付開始直後にユーザ間対戦を行って得られる第２の特典と、対抗戦の受付終了直前にユーザ間対戦を行って得られる第２の特典とが同一であったならば、対抗戦の大勢がより明確であり、かつ特典（第１の特典及び第２の特典）が得られるまでの時間が短い後者の行動（つまり、受付終了直前にユーザ間対戦を行うこと）を多くのユーザが選択する状況が考えられるが、かかる状況は対抗戦を活性化させる点で好ましくない。そこで、本変形例では、対抗戦の形勢がより不確実な、対抗戦の受付開始のより早い段階でユーザ間対戦を行うユーザに対して、より大きなインセンティブを付与する。これによって、対抗戦が行われる期間の序盤、中盤、終盤で満遍なくユーザがユーザ間対戦を行うことが図られ、対抗戦が活性化される。

本変形例を実現するために、第１の時間、又は第１の数と、第２の特典との対応関係を示す対応付けデータをＲＯＭ２２に記憶しておく。ゲームサーバ２０のＣＰＵ２１は、対象となる対抗戦のエントリーリストに記録された各ユーザについての第１の時間、又は第１の数に基づき、ＲＯＭ２２の対応付けデータを参照して、各ユーザの第２の特典を決定する。なお、前述したように、第１の時間は、対抗戦データとエントリーリストを参照し、対象となる対抗戦のエントリー開始時刻からエントリー受付時刻までの経過時間として算出される。第１の数は、対象となる対抗戦のエントリー開始時刻からのユーザ間対戦の総数として読み出される。

本変形例における対応付けデータの一例を図１９に示す。図１９（ａ）に示した例では、は、横軸が原点をエントリー開始時刻としたときのエントリー受付時刻（つまり、第１の時間）を、縦軸が第２の特典の大きさをそれぞれ示す。図１９（ｂ）に示した例では、横軸が、エントリー受付時刻までに実行されたユーザ間対戦の総数（つまり、第１の数）を、縦軸が第２の特典の大きさをそれぞれ示す。図１９に示した例では、第１の時間が短いほど、あるいは第１の数が少ないほど、対象となる対抗戦においてユーザ間対戦の操作を行ったユーザに対して付与する第２の特典を、段階的に大きくする設定としている。図１９に示す対応付けデータは一例に過ぎず、第２の特典は、第１の時間、あるいは第１の数に応じて線形に、あるいは非線形に変化させてもよい。

（７−２）変形例２
上述した実施形態のゲーム制御装置において、第２の特典は、第１の特典よりも小さくてもよい。仮に第２の特典が第１の特典よりも大きい場合には、ユーザは、対抗戦の勝敗を考慮することなく、第２の特典を得ることを主目的として対抗戦の状況のみを考慮してユーザ間対戦を実行することになることが考えられる。これでは、対抗戦の勝敗に対してユーザが興味を無くしてしまい、対抗戦の興趣性が失われる虞がある。そこで、第２の特典を第１の特典よりも小さくすることで、ユーザは、あくまで対抗戦の帰趨を第一義的に考慮しつつ、第２の特典を付随的なボーナスとして位置付けるようになる。これによって、対抗戦の興趣性を維持しつつ、ユーザに追加的な楽しみを与える構成とすることができる。
図１９に示した例は、変形例１と変形例２を組み合わせた場合の第１の特典と第２の特典の設定例を示している。この例では、第１の時間、あるいは第１の数とは無関係に対抗戦の勝敗で決定される第１の特典は、常に第２の特典よりも大きく設定されている。なお、図１９の設定例は一例に過ぎず、本変形例では、第２の特典は第１の時間、あるいは第１の数に応じて必ずしも変動させる必要はない。

（７−３）変形例３
上述した実施形態のゲーム制御装置において、第１の特典及び第２の特典を一括してユーザに付与してもよい。つまり、第１の特典をユーザに付与し、第２の特典を別個にボーナス特典として付与してもよいが、これらを一括して付与してもよい。１つの対抗戦について一括して特典を付与することで、処理の煩雑さが抑制される。
例えば、第１の特典が２００ｐｔ一定であり、第２の特典がエントリーのタイミングに応じて１０〜５０ｐｔの範囲で変動する場合を想定する。この場合、ユーザがエントリーしてユーザ間対戦を行ったタイミングで、２０ｐｔの第２の特典を付与し、対抗戦が終了してそのユーザのグループが勝利した場合に２００ｐｔを付与してもよいし、本変形例のように、対抗戦が終了後に一括して２２０ｐｔをユーザに付与してもよい。本変形例の場合には、ユーザのポイント付与に対する通知が１回で済むため、通信処理が煩雑さが抑制される。

（７−３）変形例４
上述した実施形態のゲーム制御装置において、第２の特典として付与されるポイント又はアイテムの総量が決められており、第２の特典付与手段５８は、第１の時間が短い順、あるいは第１の数が少ないユーザの順に、総量からポイント又はアイテムを付与してもよい。この構成では、第２の特典として付与されるポイント又はアイテムの総量が決められており、いわゆる早い者勝ちによって第２の特典を得ることができる。そのため、ユーザが対抗戦のユーザ間対戦を競って早く実行することが動機付けられ、対抗戦が活性化される。
例えば、特定の対抗戦に設けられる第２の特典の総量を９００ｐｔとし、その対抗戦について、第１の時間が短い順、あるいは第１の数が少ないユーザの順、つまりユーザ間対戦の実行についての操作が早い順に３０ｐｔずつ第２の特典が付与される場合には、その操作が早い上位３０人のユーザに第２の特典が付与される。そのため、上位３０人に入るように、ユーザが競って対抗戦に早くエントリーすることが動機付けられ、対抗戦が活性化する要素となる。
本変形例を実現するために、第２の特典の総量を示す値をＲＡＭ２３に記憶しておき、対抗戦にエントリーするユーザの順に（つまり、エントリー受付時刻が早いユーザの順に）、所定量ずつ第２の特典を付与する。ＣＰＵ２１は、第２の特典を付与した場合には、総量から所定量を減算する処理を行い、総量が所定量以下となった場合には、第２の特典を付与する処理を中止する。

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

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

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

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

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

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

Claims (9)

1. 通信端末からアクセス可能に構成され、前記通信端末によるゲームの実行を制御するゲーム制御装置であって、
   ユーザをグループに対応付ける対応付け手段と、
   異なるグループの間の競争であるグループ間競争へのユーザの参加を受け付ける受付手段と、
   ユーザの参加を受け付けたグループ間競争において、当該ユーザと、当該ユーザとは異なるグループに対応付けられている他のユーザとの間の前記ゲーム上の競争であるユーザ間競争の結果に基づいて前記グループ間競争における勝敗を決定する競争実行手段と、
   ユーザに対応付けられているグループのグループ間競争における勝敗に基づいて、当該ユーザに対して第１の特典を付与するか否か、又は当該ユーザに対して付与する第１の特典の内容を決定する第１の特典付与手段と、
   前記受付手段がグループ間競争への参加の受け付けを開始してからの経過時間である第１の時間に応じて、あるいは前記受付手段がグループ間競争への参加の受け付けを開始してからの前記グループ間競争において実行されたユーザ間競争の総数である第１の数に応じて変動する第２の特典を、前記グループ間競争において前記操作を行ったユーザに対して付与する第２の特典付与手段と、
   前記第１の時間、前記第１の数、又は、前記グループ間競争のユーザの参加の受付が終了するまでの残り時間、若しくはユーザ間競争の残り回数のうち、少なくともいずれかを通信端末宛に通知する通知手段と、
   を備えたゲーム制御装置。
2. 前記対応付け手段は、ユーザを複数のグループのいずれかに対応付け、
   前記受付手段は、異なるグループの間の競争であるグループ間競争を複数設け、ユーザの操作に応じて、複数のグループ間競争のうち少なくともいずれかのグループ間競争へのユーザの参加を受け付けることを特徴とする、
   請求項１に記載されたゲーム制御装置。
3. 前記第２の特典付与手段は、前記第１の時間が短いほど、あるいは前記第１の数が少ないほど、前記操作を行ったユーザに対して付与する前記第２の特典を大きくすることを特徴とする、
   請求項１又は２に記載されたゲーム制御装置。
4. 前記第２の特典は、前記第１の特典よりも小さいことを特徴とする、
   請求項１〜３のいずれかに記載されたゲーム制御装置。
5. 前記第１の特典及び前記第２の特典を一括してユーザに付与することを特徴とする、
   請求項１〜４のいずれかに記載されたゲーム制御装置。
6. 前記第２の特典として付与されるポイント又はアイテムの総量が決められており、
   前記第２の特典付与手段は、前記第１の時間が短い順、あるいは前記第１の数が少ないユーザの順に、前記総量からポイント又はアイテムを付与することを特徴とする、
   請求項１〜５のいずれかに記載されたゲーム制御装置。
7. 通信端末からアクセス可能に構成され、前記通信端末によるゲームの実行を制御するゲーム制御装置、におけるゲーム制御方法であって、
   ユーザをグループに対応付けるステップと、
   異なるグループの間の競争であるグループ間競争へのユーザの参加を受け付けるステップと、
   ユーザの参加を受け付けたグループ間競争において、当該ユーザと、当該ユーザとは異なるグループに対応付けられている他のユーザとの間の前記ゲーム上の競争であるユーザ間競争の結果に基づいて前記グループ間競争における勝敗を決定するステップと、
   ユーザに対応付けられているグループのグループ間競争における勝敗に基づいて、当該ユーザに対して第１の特典を付与するか否か、又は当該ユーザに対して付与する第１の特典の内容を決定するステップと、
   グループ間競争への参加の受け付けを開始してからの経過時間である第１の時間に応じて、あるいは前記受付手段がグループ間競争への参加の受け付けを開始してからの前記グループ間競争において実行されたユーザ間競争の総数である第１の数に応じて変動する第２の特典を、前記グループ間競争において前記操作を行ったユーザに対して付与するステップと、
   前記第１の時間、前記第１の数、又は、前記グループ間競争のユーザの参加の受付が終了するまでの残り時間、若しくはユーザ間競争の残り回数のうち、少なくともいずれかを通信端末宛に通知するステップと、
   を備えたゲーム制御方法。
8. 通信端末によるゲームの実行を制御するために、コンピュータに、
   ユーザをグループに対応付ける機能、
   異なるグループの間の競争であるグループ間競争へのユーザの参加を受け付ける機能、
   ユーザの参加を受け付けたグループ間競争において、当該ユーザと、当該ユーザとは異なるグループに対応付けられている他のユーザとの間の前記ゲーム上の競争であるユーザ間競争の結果に基づいて前記グループ間競争における勝敗を決定する機能、
   ユーザに対応付けられているグループのグループ間競争における勝敗に基づいて、当該ユーザに対して第１の特典を付与するか否か、又は当該ユーザに対して付与する第１の特典の内容を決定する機能、
   グループ間競争への参加の受け付けを開始してからの経過時間である第１の時間に応じて、あるいは前記受付手段がグループ間競争への参加の受け付けを開始してからの前記グループ間競争において実行されたユーザ間競争の総数である第１の数に応じて変動する第２の特典を、前記グループ間競争において前記操作を行ったユーザに対して付与する機能、及び
   前記第１の時間、前記第１の数、又は、前記グループ間競争のユーザの参加の受付が終了するまでの残り時間、若しくはユーザ間競争の残り回数のうち、少なくともいずれかを通信端末宛に通知する機能、
   を実現させるためのプログラム。
9. 通信端末と、当該通信端末からアクセス可能に構成され、前記通信端末によるゲームの実行を制御するゲーム制御装置と、を含むゲーム制御システムであって、
   ユーザをグループに対応付ける対応付け手段、
   異なるグループの間の競争であるグループ間競争へのユーザの参加を受け付ける受付手段、
   ユーザの参加を受け付けたグループ間競争において、当該ユーザと、当該ユーザとは異なるグループに対応付けられている他のユーザとの間の前記ゲーム上の競争であるユーザ間競争の結果に基づいて前記グループ間競争における勝敗を決定する競争実行手段と、
   ユーザに対応付けられているグループのグループ間競争における勝敗に基づいて、当該ユーザに対して第１の特典を付与するか否か、又は当該ユーザに対して付与する第１の特典の内容を決定する特典付与手段、
   前記受付手段がグループ間競争への参加の受け付けを開始してからの経過時間である第１の時間に応じて、あるいは前記受付手段がグループ間競争への参加の受け付けを開始してからの前記グループ間競争において実行されたユーザ間競争の総数である第１の数に応じて変動する第２の特典を、前記グループ間競争において前記操作を行ったユーザに対して付与する第２の特典付与手段、及び
   前記第１の時間、前記第１の数、又は、前記グループ間競争のユーザの参加の受付が終了するまでの残り時間、若しくはユーザ間競争の残り回数のうち、少なくともいずれかを通信端末宛に通知する通知手段、
   の各手段を、前記通信端末又は前記ゲーム制御装置のいずれか一方が備えた、
   ゲーム制御システム。

Images