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

Abstract

【課題】対戦ゲームにおいてユーザ間の不均衡が抑制されるようにしたゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供する。【解決手段】ユーザと対戦相手との間で、オブジェクトからなるグループによる対戦ゲームを実行する実行手段５８と、ユーザと複数のオブジェクトを関連付ける関連付け手段５３と、ユーザに関連付けられた複数のオブジェクトを基に、ユーザの複数のグループを設定する設定手段５４と、設定手段５４によって設定された複数のグループの各々を、グループの種別に対応付ける対応付け手段５５と、対戦ゲームの実行時に、対戦相手のグループの種別を判定する判定手段５６と、対戦相手との対戦に適用されるユーザのグループとして、複数のグループのうち、判定手段５６により判定された対戦相手の種別に対応付けられたグループを選択する選択手段５７と、を備える。【選択図】図１２

Description

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

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

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

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

上述したソーシャルゲームでは、極めて大多数のユーザがゲームに参加しているが、ユーザ間のバトル（対戦）は非同期で行われる。例えば、上述したデジタルカードゲームでは、各ユーザは、手持ちの複数のカードの中から攻撃用のグループに含まれるカード群と、防御用のグループに含まれるカード群とを設定する（俗に「デッキを組む」ともいう。）。このとき、ゲームにアクセス中のユーザは、攻撃用のグループに含まれるカード群を用いて他のユーザに対してバトルを仕掛ける。攻撃を仕掛けられた他のユーザ（対戦相手）は、予め設定された防御用のグループに含まれるカード群によってバトルに応戦することになるが、そのバトルに対して影響を与えうる何らかの操作ができない仕組みとなっている。バトルを仕掛けた、ゲームにアクセス中のユーザは、バトルの結果を直ちに知ることができるが、その対戦相手は、バトルの終了後にゲームにアクセスした段階でバトルの勝敗を知ることになる。

このような非同期のバトルにおいて、ゲームにアクセス中の攻撃側のユーザは、自ら設定した攻撃用のカード群にとって有利になるような対戦相手（レベル、属性等）を選択することができ、また、例えば仲間のユーザのカードを借りてバトルに参加させることができる場合もあることから、攻撃側のユーザが有利となっており、バトルにおけるユーザ間で不均衡が生じていた。

本発明は上述した観点に鑑みてなされたもので、対戦ゲームにおいてユーザ間の不均衡が抑制されるようにしたゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供することを目的とする。

本発明の第１の観点は、ゲーム制御装置であって、
ユーザと対戦相手との間で、オブジェクトからなるグループによる対戦ゲームを実行する実行手段と、
ユーザと複数のオブジェクトを関連付ける関連付け手段と、
前記ユーザに関連付けられた複数のオブジェクトを基に、前記ユーザの複数のグループを設定する設定手段と、
前記設定手段によって設定された複数のグループの各々を、グループの種別に対応付ける対応付け手段と、
前記対戦ゲームの実行時に、前記対戦相手のグループの種別を判定する判定手段と、
前記対戦相手との対戦に適用される前記ユーザのグループとして、前記複数のグループのうち、前記判定手段により判定された対戦相手の種別に対応付けられたグループを選択する選択手段と、
を備える。

このゲーム制御装置において「オブジェクト」とは、例えば、ゲーム上のキャラクタやアイテム等を含む。キャラクタは、例えばゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカードに表示されているものをも含む。
このゲーム制御装置において「グループの種別」とは、グループの対戦ゲームにおける能力に対して異なる影響を与えうるグループの要素を識別するための情報である。そのようなグループの要素の例としては、グループに対応するユーザの登録情報、グループに含まれるオブジェクトの属性やタイプ、オブジェクトの組み合わせ、グループによって生ずるバトル時の効果等である。

ユーザは、対戦相手のグループの様々な種別を想定して、各種別に対して効果的なグループが選択されるように、自らの複数のグループを、対戦ゲームの実行前に予め設定しておくことが可能である。そして、対戦ゲームの実行時には、対戦相手のグループの種別の判定が行われ、判定された種別に応じて、予め設定しておいた複数のグループのうち、対戦相手のグループの種別に応じたグループが、対戦相手との対戦に適用される前記ユーザのグループとして選択される。そのため、ユーザが対戦ゲームの実行時に何らの入力を行わない場合であっても、予め設定しておいた複数のグループのうち適切なグループによって対戦が行われるようにすることができる。
例えばソーシャルゲーム等、非同期でユーザ間の対戦が行われる場合には、一般にユーザは、例えばログイン中の対戦相手からの入力を契機として開始される対戦ゲームについて、対戦結果に影響を与えうるような操作入力を行うことができないため、不利となる場合が多い。他方、このゲーム制御装置によれば、ユーザは、対戦相手の種別に対して効果的な自らのグループが選択されるように、予め複数のグループの各々を、想定される対戦相手のグループの種別に対応付けておくことができるため、そのユーザにとってバトルでの対戦相手との間の不均衡が抑制されるようになる。

上記ゲーム制御装置において、前記判定手段は、前記対戦相手としての他のユーザの登録情報、及び、前記対戦相手のグループを構成するオブジェクト若しくはオブジェクトの組み合わせのうち少なくともいずれかに基づいて、前記対戦相手のグループの種別を判定してもよい。
「登録情報」は、ユーザに関してゲーム上で登録された情報のうち、対戦相手のグループの対戦ゲームにおける能力に影響を与えうる情報である。例えばユーザが予め自らのゲーム上でユーザ属性を登録し、そのユーザ属性が対戦において所定の効果を発揮する場合には、そのユーザ属性は登録情報の一例である。上記判定によって、対戦相手のグループの対戦ゲームにおける能力に影響を与えうる情報に基づいて対戦相手のグループの種別を適切に判定することができる。

上記ゲーム制御装置において、前記設定手段は、前記ユーザの進行状況に応じて、設定可能なグループの数を変動させてもよい。
「ユーザの進行状況」とは、ゲームの進行度（例えば、ゲーム上の進行レベルやステージ等）やゲームの進行の速さなど、ユーザによるゲームの進行に関する状況である。ここで、ゲームの進行度は、ユーザ間の対戦ゲームにおけるゲームの進行度に限られない。１つのゲームの中に、対戦やクエスト等の複数のゲーム要素が含まれている場合には、対戦以外のゲーム要素（クエスト等）の進行度であってもよい。
例えばゲームの進行レベルが大きくなるほど設定可能なグループの数が増加する場合、ユーザは、対戦ゲームの実行時に有利となるようにゲームの進行レベルを大きくするように動機付けられる。また、例えばゲームの進行が速いほど設定可能なグループの数が増加する場合、ユーザは、対戦ゲームの実行時に有利となるようにゲームを継続的に進捗させるように動機付けられる。つまり、いったんゲームの進行レベルが大きくなった後でも、その後にゲームの進行が行われなくなった場合には、設定可能なグループの数が低下してしまうため、ユーザは、設定可能なグループの数が低下しないように継続的にゲームを進めることが動機付けられる。

上記ゲーム制御装置において、前記実行手段は、前記ユーザの前記対戦ゲームへのログインの有無とは無関係に前記対戦ゲームを実行し、前記判定手段は、対戦ゲームの実行時に前記ユーザがログインしている場合に、前記対戦相手のグループの種別を判定してもよい。
なお、現在時刻がユーザのログイン時刻の後の所定時間内である場合に、ユーザがログインしていると判定してもよいし、現在時刻がユーザの最終アクセス時刻から所定時間内である場合に、ユーザがログインしていると判定してもよい。
前記対戦ゲームがユーザのログインの有無と無関係に実行されるゲームでは、ユーザがログイン中であるにも関わらず対戦相手との間の対戦ゲームに対処することができない状況に対する不満が特に強いと考えられるが、そのような状況で特に、予め設定しておいた複数のグループのうち適切なグループによって対戦が行われるようにすることで、上記不満を抑制することができるようになる。

上記ゲーム制御装置において、前記対応付け手段は、前記ユーザの進行状況に応じて、対応付けることが可能な種別を変動させてもよい。これにより、ユーザがゲームを進行させるほど、対戦相手のより多くのグループの種別に対処することができ、より有利な立場に立てるため、ユーザによるゲームの進行を動機付けることができる。また、例えばゲームの進行が速いほど設定可能な種別の数が増加する場合、ユーザは、対戦ゲームの実行時に有利となるようにゲームを継続的に進捗させるように動機付けられる。

上記ゲーム制御装置において、前記対応付け手段は、グループ毎に、ユーザの入力情報に基づいて、複数の種別の中からいずれかの種別を対応付けてもよい。ユーザの入力情報に基づいて種別の対応付けを行うことで、ユーザは、予め自らのグループ内のオブジェクトの選択等、対戦相手のグループの種別に対して適切なグループの設定を行うように動機付けられる。

本発明の第２の観点は、ゲーム制御方法であって、
ユーザと複数のオブジェクトを関連付けるステップと、
前記ユーザに関連付けられた複数のオブジェクトを基に、前記ユーザの複数のグループを設定するステップと、
前記設定するステップによって設定された複数のグループの各々を、グループの種別に対応付けるステップと、
ユーザと対戦相手との間で、オブジェクトからなるグループによる対戦ゲームを実行するに当たって、前記対戦相手のグループの種別を判定するステップと、
前記対戦相手との対戦に適用される前記ユーザのグループとして、前記複数のグループのうち、前記判定するステップにより判定された対戦相手の種別に対応付けられたグループを選択するステップと、
を備える。

本発明の第３の観点は、ゲームの実行を制御するために、コンピュータに、
ユーザと対戦相手との間で、オブジェクトからなるグループによる対戦ゲームを実行する機能、
ユーザと複数のオブジェクトを関連付ける機能、
前記ユーザに関連付けられた複数のオブジェクトを基に、前記ユーザの複数のグループを設定する機能、
前記設定された複数のグループの各々を、グループの種別に対応付ける機能、
前記対戦ゲームの実行時に、前記対戦相手のグループの種別を判定する機能、及び、
前記対戦相手との対戦に適用される前記ユーザのグループとして、前記複数のグループのうち、前記判定された対戦相手の種別に対応付けられたグループを選択する機能、
を実現させるためのプログラムである。

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

本発明の第４の観点は、通信端末と、当該通信端末からアクセス可能なサーバと、を含むゲームシステムである。
このゲームシステムは、
ユーザと対戦相手との間で、オブジェクトからなるグループによる対戦ゲームを実行する実行手段、
ユーザと複数のオブジェクトを関連付ける関連付け手段、
前記ユーザに関連付けられた複数のオブジェクトを基に、前記ユーザの複数のグループを設定する設定手段、
前記設定手段によって設定された複数のグループの各々を、グループの種別に対応付ける対応付け手段、
前記対戦ゲームの実行時に、前記対戦相手のグループの種別を判定する判定手段、及び、
前記対戦相手との対戦に適用される前記ユーザのグループとして、前記複数のグループのうち、前記判定手段により判定された対戦相手の種別に対応付けられたグループを選択する選択手段、
の各手段を、前記通信端末又は前記サーバのいずれか一方が備える。

本発明のゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムによれば、対戦ゲームにおいてユーザ間の不均衡が抑制されるようにすることができる。

実施形態のゲームシステムの基本構成を示す図。 実施形態の通信端末の外観の例を示す図。 実施形態の通信端末の構成を示すブロック図。 実施形態のゲームサーバの構成を示すブロック図。 実施形態のデータベースサーバの構成を示すブロック図。 ユーザデータベースの構成例を示す図。 カードデータベースの構成例を示す図。 防御時のカードの特技発動テーブルの構成例を示す図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 攻撃チームの効果発動テーブルの構成例を示す図。 防御チームのチーム対応テーブルの構成例を示す図。 攻撃チームの種別の判定処理を示すフローチャート。 実施形態のバトル処理を示すフローチャート。 実施形態のゲーム制御装置の各機能について、通信端末と、ゲームサーバ 及びデータベースサーバとの間の分担例を示す図。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本実施形態のゲームサーバ２０によって実現されるゲームのタイプは特に限定されるものではないが、以下では、実施形態の説明の便宜上、ゲームサーバ２０によって実現されるゲームの一例として、ユーザの通信端末１０に対する操作に応じて、ユーザ同士で、ゲーム上で仮想的に保有する戦士カードを使用したバトルを行う対戦型デジタルカードゲームを採り上げる。このデジタルカードゲームは、自らの戦士カードを収集するためにエリアを探索するクエスト処理や、ユーザ間で戦士カードからなるチームによるバトルを行うバトル処理等が設けられている。

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

以下の説明では、ユーザデータベース３１に含まれるユーザＩＤ、あるいはユーザを特定するユーザ名（後述する）ごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、以下のとおりである。
・ユーザ名／表示画像
ゲームの実行時に通信端末１０にユーザを特定するために表示されるユーザ名及び表示画像である。ユーザ名はユーザによって予め指定される所定長以下のテキストであり、表示画像は例えばユーザによって予め選択されるアバタ画像である。ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
・ユーザ属性
本実施形態のゲームに対するユーザ登録時にユーザ自らが指定するゲーム上の属性である。本実施形態のゲームの例では、ユーザ属性は、α、β、又はγである。
・進行レベル
ユーザのゲームにおける進行度合いを示すデータであり、ユーザによるゲームの進行に伴って増加する値である。例えば、進行レベルは、例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値である。
・体力ポイント
本実施形態のゲームにおいて、後述するクエストを行う上で必要となるポイントである。体力ポイントは、クエストを行う度に低減し、所定の時間が経過する毎に回復（増加）する値である。
・仲間のユーザＩＤ
対象となるユーザＩＤと関係付けられた他のユーザＩＤのデータである。

図５に戻り、ゲームデータベース３２は、ゲームサーバ２０からのアクセスに基づき、ゲームサーバ２０によって実行されたゲームの進行に関する情報を記憶、更新する。ゲームの進行に関する情報は、ゲームの性質によって多様な情報を含みうる。本実施形態のゲームの場合を例に挙げれば、ゲームの進行に関する情報は、異なるユーザ同士のバトルの結果などを含む。ゲームデータベース３２はさらに、カードデータベース、及び防御時の特技発動テーブルを記憶する。

図７にカードデータベースの構成例を示す。図７に示すように、カードデータベースには、ユーザＩＤごとに各ユーザの保有カード（各ユーザに関連付けられている戦士カード）についての情報が含まれている。各保有カードは、カード属性、戦士タイプ、パラメータ（攻撃力、防御力）が対応付けられている。なお、図７には図示しないが、各保有カードは、ゲーム上で表示するための画像データと対応付けられていてもよい。

カード属性とは、ユーザ属性に対応する属性であり、ユーザ属性と同様に、本実施形態の例では、α、β、又はγのいずれかである。必ずしもすべての戦士カードにカード属性が設定されていなくてもよい。後述するように、本実施形態のゲームでは、ユーザが自らのユーザ属性と同じカード属性の戦士カードを用いてバトルを仕掛けると、攻撃力が増加する仕組みとなっている。
戦士タイプとは、戦士カードのタイプであり、本実施形態の例では、タイプＴ１，Ｔ２，Ｔ３の３種類が存在する。後述するように、本実施形態のゲームでは、ユーザが同じ戦士タイプの戦士カードを所定数、例えば３枚以上用いてバトルを仕掛けると、攻撃力が増加する仕組みとなっている。
パラメータ（攻撃力、防御力）は、戦士カードを用いたバトルの勝敗を決定する上で参照される値である。

本実施形態のゲームにおいて、ユーザ間のバトル処理は、ゲームにログインしているユーザの通信端末１０に対する操作入力を契機として開始されるが、例えばそのユーザがバトル相手を選択した時点でそのバトル相手がゲームにログインしているとは限らない。そこで、本実施形態のバトル処理は、以下のようにして行われる。ゲームにアクセス中のユーザがバトル処理を実行するときには、そのユーザはバトルを仕掛ける側、つまり戦士カードからなる攻撃チームを用いてバトル相手を攻撃する側となる。一方、バトル相手として選択されたユーザは、バトルを受ける側、つまり戦士カードからなる防御チームを用いて防御する側となる。この場合、防御する側のユーザは、他のユーザから仕掛けられたバトルの実行時には、防御チームの能力に影響を与えうる何らかの操作を行うことはできない。
以下、攻撃する側のユーザを「攻撃ユーザ」といい、防御する側のユーザを「防御ユーザ」という。
図７に示すカードデータベースでは、保有カードごとに、各ユーザの攻撃チーム、防御チームに設定されているか（所属しているか）否かをフラグ（１：設定されている、０：設定されていない）によって表している。防御チーム構成は、本実施形態の例では、４つの防御チームＡ〜Ｄからなる。

図８に、防御時の特技発動テーブルの構成例を示す。本実施形態のゲームでは、バトルに参加したときに所定の特技が例えば一定の、あるいはランダムな確率で発動する戦士カードが設けられている。なお、戦士カードとその発動する特技は、図８に記述したものに限定されるものではない。図８には、防御時の特技発動テーブルを例示するが、攻撃時の特技発動テーブルを設けてもよい。
図８に示す特技発動テーブルには、戦士カードが防御チームに設定されているときにそのバトルで発動する特技が記述されている。例えば、戦士カードＣ１が防御チームに設定されている場合には、バトル相手（つまり、攻撃ユーザの攻撃チーム）に含まれ、かつカード属性がαの戦士カードの攻撃力を、例えば８〜１８％の範囲でランダムに決定される量だけ低下させる特技が発動する。戦士カードＣ１９が防御チームに設定されている場合には、バトル相手に含まれ、かつタイプＴ１の戦士カードの攻撃力を、例えば８〜１８％の範囲でランダムに決定される量だけ低下させる特技が発動する。

（５）本実施形態のゲーム
以下、本実施形態のゲームについて、図９〜１１を参照しながら説明する。図９〜１１はそれぞれ、本実施形態のゲームにおいてクエスト処理、チーム編成処理、バトル処理、を行うときに通信端末１０上に表示されるウェブページの一例を示す図である。
以下では、処理対象のユーザのユーザ名が「ＫＮＭ」であるユーザ（以下、ユーザＫＮＭ）を例として説明する。

（５−１）クエスト処理（図９）
図９のウェブページＰ０は、本実施形態のゲームのトップページの一例であり、個々のユーザＩＤに応じて構成される。図８の例では、戦士画像表示領域１０１、ユーザデータ表示領域１０２、及びメニュー表示領域１０３を含む。
戦士画像表示領域１０１は、処理対象のユーザＫＮＭの保有カードに含まれる複数の戦士カードのうちユーザによって予め指定された戦士カードの画像が表示される領域である。
ユーザデータ表示領域１０２は、処理対象のユーザＫＮＭの「進行レベル」、「体力ポイント」、「戦士数」、「仲間」のデータが表示される領域である。なお、「戦士数」は、ユーザの保有カードの総数であり、「仲間」は、図６に示した「仲間のユーザＩＤ」の数である。また、図８に例示するように、「戦士数」が「４０／６０」と表記されている場合、ユーザが保有する戦士カードが４０枚であり、最大で保有可能な戦士カードの枚数が６０枚であることを示す。
メニュー表示領域１０３は、本実施形態のゲームに設けられる複数の機能（クエスト処理、バトル処理）に対応した基本メニューとして、「クエスト」、「バトル」のテキストが表記されたメニューｍ１,ｍ２が表示される領域である。

ウェブページＰ０上でメニューｍ１が選択操作されると、Ｐ１に示すようにウェブページが更新される。このウェブページＰ１には、ユーザが所定量の体力ポイントを消費してエリアを探索するためのメニューｍ１０が含まれる。メニューｍ１０が選択操作される度に、一定の、あるいはランダムな増加量で探索率の値が増加し、探索率が１００％に達するとエリアの探索が終了する。探索対象のエリアは、複数設けられてもよい。ユーザがメニューｍ１０を選択操作すると、所定の、あるいはランダムな確率で、ウェブページＰ２に例示するように戦士カードがユーザに付与される。
なお、体力ポイントが上記所定量未満になった場合にはクエスト処理を実行することはできない。その場合には、体力ポイントが回復するまで待機する必要がある。

（５−２）チーム編成処理（図１０）
図１０のウェブページＰ０上で「戦士数」の項目が選択操作されると、Ｐ３に示すようにウェブページが更新される。このウェブページＰ３では、処理対象のユーザＫＮＭのバトルにおける攻撃チームと防御チームに対して戦士カードを設定する、あるいは設定を解除するためのチーム編成処理を行うことができる。ウェブページＰ３には、メニューｍ１１（「攻撃チーム」）とメニューｍ１２（「防御チーム」）が表示され、いずれかのメニューの選択操作を行うことで、攻撃チーム又は防御チームのいずれかのチーム編成を行うことができる。図１０に示すウェブページＰ３は、メニューｍ１２が選択され、防御チームのチーム編成を行うときのウェブページである。この例では、防御チーム一覧として防御チームＡ〜Ｄの各々に対して、プルダウンメニューｍ１５及びメニューｍ１６（「戦士リストを見る」）が対応付けて配置されて表示される。プルダウンメニューｍ１５は、以下の６つの選択肢の中のいずれかから選択できるように構成されている。これらの選択肢は、バトル相手の攻撃チームで発動する効果に対応しており、その発動する効果を抑制する防御チームがバトル時に選択されるようにするために設けられている。

「α対策チーム」 …バトル相手（攻撃ユーザ）のユーザ属性がαであって、その攻撃チーム内にカード属性がαの戦士カードが含まれるときの選択肢
「β対策チーム」 …バトル相手（攻撃ユーザ）のユーザ属性がβであって、その攻撃チーム内にカード属性がβの戦士カードが含まれるときの選択肢
「γ対策チーム」 …バトル相手（攻撃ユーザ）のユーザ属性がγであって、その攻撃チーム内にカード属性がγの戦士カードが含まれるときの選択肢
「Ｔ１対策チーム」…バトル相手（攻撃ユーザ）の攻撃チーム内にタイプＴ１の戦士カードが３枚以上含まれるときの選択肢
「Ｔ２対策チーム」…バトル相手（攻撃ユーザ）の攻撃チーム内にタイプＴ２の戦士カードが３枚以上含まれるときの選択肢
「Ｔ３対策チーム」…バトル相手（攻撃ユーザ）の攻撃チーム内にタイプＴ３の戦士カードが３枚以上含まれるときの選択肢

ウェブページＰ３に示した例では、ユーザが、防御チームＡ，Ｂ，Ｃ，Ｄに対してそれぞれ、「α対策チーム」、「β対策チーム」、「γ対策チーム」、「Ｔ３対策チーム」を選択した場合が示されている。

ウェブページＰ３において、メニューｍ１６（「戦士リストを見る」）が選択操作されると、例えばＰ４に示すようにウェブページが更新されて、選択操作されたメニューｍ１６に対応する防御チームに設定されている戦士カードの一覧（戦士リスト）を閲覧することができる。ウェブページＰ４は、一例として防御チームＡの戦士リストである。
ウェブページＰ４では、各戦士カードについて、設定されている戦士カードに代えて別の戦士カードを新たに設定するためのメニューｍ２０（「変更する」）と、設定されている戦士カードの設定を解除するためのメニューｍ２１（「外す」）とが設けられている。また、各戦士カードには、攻撃力や防御力などのパラメータの値や、特技がある場合にはその特技の内容がテキスト形式で表示される。
本実施形態のゲームにおいて、攻撃チームと防御チームに設定可能な戦士カードの数は、例えば所定数以内に限定してもよい。設定されている戦士カードの数がその所定数に満たない場合には、設定する戦士カードを追加するためのメニューｍ２２（「設定する」）が設けられる。

なお、このゲームでは、例えばウェブページＰ３において、防御チームＡとしてα対策チームが選択されているため、バトルを仕掛けてくる攻撃ユーザのユーザ属性がαであって、かつその攻撃チーム内にカード属性がαの戦士カードがいると判定された場合に、防御チームＡが防御チームとして選択される仕組みとなっている。そのような判定条件を満たす攻撃チームは、カード属性がαの戦士カードの攻撃力が増加するため、防御ユーザとなるユーザＫＮＭとしては、予め防御チームＡに対して、例えば戦士カードＣ１，Ｃ１２等、攻撃ユーザのカード属性がαの戦士カードの攻撃力を低下させる特技を備えた戦士カード（図８参照）を設定しておくことが好ましい。

（５−３）バトル処理（図１１）
図１１のウェブページＰ０上でメニューｍ２が選択操作されると、Ｐ５に示すようにウェブページが更新される。このウェブページＰ５には、バトル相手となる他のユーザの一覧が表示される。この一覧の中からいずれかのユーザが防御ユーザとして選択されると、Ｐ６に示すようにウェブページが更新される。この例では、ユーザＫＮＭ（攻撃ユーザ）とユーザＡＢＣ（防御ユーザ）との間でバトルが行われる例が示されている。ウェブページＰ６において、「バトル開始」と表記されたメニューｍ３０が選択操作されると、例えばＰ７に示すようにウェブページが更新される。ウェブページＰ７には、ユーザＫＮＭがバトルで勝利した場合の表示例が示されている。

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

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

本実施形態では、登録要求メッセージは、ユーザの選択操作に基づくユーザ属性の選択結果（α、β、又はγのいずれか）を含む。ユーザ属性の選択は、登録処理時にゲームサーバ２０から提供されるウェブページ上での、例えばプルダウン形式での選択操作によって行われてよい。
ＣＰＵ２１は、登録要求メッセージを受信し、登録要求メッセージにユーザＩＤが含まれていない場合には、ユーザＩＤを新たに発行してそのユーザＩＤの登録処理を行った後、登録処理が完了した旨のメッセージを通信端末１０へ送信する。ＣＰＵ２１は、登録要求メッセージを受信し、登録要求メッセージにユーザＩＤが含まれている場合には、そのユーザＩＤの登録処理を行った後、登録処理が完了したことを示す登録完了メッセージを通信端末１０へ送信する。
登録が完了すると、ＣＰＵ２１は、ユーザＩＤに対応するユーザデータを生成し、ユーザデータベース３１に格納する。登録が完了すると、ユーザは、本実施形態のゲームを実行することが可能となる。

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

クエスト実行手段５２は、通信端末１０に対するユーザの操作に応じて、通信端末１０に表示されるウェブページを逐次更新するためのＨＴＭＬデータを送信することで、クエスト処理を実行する機能を備える。クエスト実行手段５２の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、通信インタフェース部２５を介して通信端末１０からＨＴＴＰリクエストを受信し、そのＨＴＴＰリクエストによって要求される処理を実行し、その実行結果であるＨＴＭＬデータを含むＨＴＴＰレスポンスを通信端末１０宛に返す。

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

次いで、ウェブページＰ０においてメニューｍ１（「クエスト」）に対する選択操作結果を含むＨＴＴＰリクエストを受信すると、ＣＰＵ２１は、処理対象のユーザＫＮＭ向けのクエスト処理のウェブページを生成するためのＨＴＭＬデータを生成して、ユーザＫＮＭの通信端末１０宛に送信する。それによって、ウェブページＰ１がユーザＫＮＭの通信端末１０に表示される。ＣＰＵ２１は、ウェブページＰ１においてメニューｍ１０（「探索する」）が選択操作されたことを認識すると、探索率（％）の値を所定の、あるいはランダムな増加量で増加させ、探索率が１００％に達すると、ユーザの探索対象となるエリアを移行させる。ＣＰＵ２１は、メニューｍ１０が選択操作される度に、ユーザデータにアクセスして体力ポイントを例えば一定量減少させる。ＣＰＵ２１は、メニューｍ１０が選択操作される度に一定の、あるいはランダムな確率で、戦士カードをユーザに付与する。戦士カードをユーザに付与する場合、ＣＰＵ２１は、例えば一定の確率で戦士カードを付与することを決定し、戦士カードを付与することを決定した場合には、ゲーム上で用意されている戦士カードの中からいずれかの戦士カードを選択する。ＣＰＵ２１は、戦士カードを選択すると、カードデータベースにアクセスして、選択した戦士カードをユーザＫＮＭの保有カードとして書き込む。このとき、付与される戦士カードのカード属性、戦士タイプ、及びパラメータ（攻撃力、防御力）は予め初期のデータが決まっており、そのデータが書き込まれる。

関連付け手段５３は、ユーザと複数の戦士カード（オブジェクト）を関連付ける機能を備える。
関連付け手段５３を実現するために、例えば上述したように、ゲームサーバ２０のＣＰＵ２１は、クエスト処理において戦士カードが付与されたときに、カードデータベースにアクセスして、付与された戦士カードを保有カードとして書き込む処理を行う。これによって、ユーザと、付与された戦士カードとが関連付けられる。ユーザの保有カードとして戦士カードを関連付けるタイミングは、クエスト処理で戦士カードがユーザに付与されるタイミングに限られない。例えば、ゲームにおいて一定の対価、あるいはゲーム上のポイントに応じて抽選によって戦士カードをユーザに付与する、くじの機能が設けられている場合には、そのくじの機能をユーザが実行して戦士カードが付与されるタイミングにおいても、ユーザと付与される戦士カードとが関連付けられる。また、例えば仲間とのトレード、あるいは仲間からのプレゼントとして、戦士カードを仲間から得たタイミングにおいても、ユーザと付与される戦士カードとが関連付けられる。

設定手段５４は、保有カードとしてユーザに関連付けられた複数の戦士カード（オブジェクト）を基に、ユーザの複数の防御チーム（グループ）を設定する機能を備える。本実施形態のゲームでは、防御チームとして４つの防御チームＡ〜Ｄが設定される。
設定手段５４の機能は、以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、例えば図１０のウェブページＰ３において、防御チームＡ〜Ｄの各々に対応付けられたメニューｍ１６（「戦士リストを見る」）が選択操作されたことを認識すると、カードデータベース（図７）を参照して、処理対象のユーザＫＮＭの保有カードのうち防御チームＡについてフラグが「１」（設定されている）となっている戦士カードを読み出して、戦士リストを生成し、その戦士リストを含むＨＴＭＬデータを通信端末１０宛に送信する。

ウェブページＰ４において、メニューｍ２０（「変更する」）が選択操作されたことを認識すると、ＣＰＵ２１は、カードデータベースを参照してユーザの保有カードの一覧を含むＨＴＭＬデータを生成して通信端末１０宛に送信する。このＨＴＭＬデータによって表示されるウェブページ（図示せず）には、現在設定されている戦士カードに代わって新たに設定する戦士カードの選択操作を受け入れるように構成されている。新たに設定する戦士カードの選択結果を含むＨＴＴＰリクエストを受信すると、ＣＰＵ２１は、カードデータベースにアクセスして、設定を外す保有カード（つまり、選択操作されたメニューｍ２０に対応する戦士カード）の防御チームＡにおけるフラグを「１」から「０」に変更し、新たに防御チームＡに設定する保有カードのフラグを「０」から「１」に変更する。

ウェブページＰ４において、メニューｍ２１（「外す」）が選択操作されたことを認識すると、ＣＰＵ２１は、カードデータベースにアクセスして、設定を外す保有カード（つまり、選択操作されたメニューｍ２１に対応する戦士カード）の防御チームＡにおけるフラグを「１」から「０」に変更する。

ウェブページＰ４において、メニューｍ２２（「設定する」）が選択操作されたことを認識すると、ＣＰＵ２１は、カードデータベースを参照してユーザの保有カードの一覧を含むＨＴＭＬデータを生成して通信端末１０宛に送信する。このＨＴＭＬデータによって表示されるウェブページ（図示せず）には、新たに設定する戦士カードの選択操作を受け入れるように構成されている。新たに設定する戦士カードの選択結果を含むＨＴＴＰリクエストを受信すると、ＣＰＵ２１は、カードデータベースにアクセスして、新たに防御チームＡに設定する保有カード（つまり、選択操作されたメニューｍ２２に対応する戦士カード）のフラグを「０」から「１」に変更する。

以上例示したようにして、予め設けられた４つの防御チームの各々について、戦士カードを特定の防御チームに設定する、あるいは戦士カードについて特定の防御チームに対する設定を解除するユーザの選択操作に基づいて、ユーザ所望の複数の防御チーム（グループ）が編成される。なお、攻撃チームについても、防御チームと同様に、ユーザの選択操作に基づいて戦士カードを設定する、あるいは戦士カードの設定を解除することが可能である。

対応付け手段５５は、設定手段５４によって設定された複数の防御チーム（グループ）の各々を、攻撃ユーザの攻撃チーム（グループ）の種別として予め想定される種別に対応付けておく機能を備える。
この対応付け手段５５の機能により、攻撃ユーザの種別の異なる攻撃チームに対して、非同期で応戦する防御側のユーザが効果的に応戦できるようにするために、複数の防御チームを、攻撃チームの想定される種別ごとにユーザが予め割り当てておくことができるようになる。

図１３に、バトル相手の攻撃チーム（グループ）の種別（チーム種別）の例である種別Ｖ１〜Ｖ６について、効果発動条件と、発動する効果とを対応付けた、攻撃チームの効果発動テーブルを示す。例えばチーム種別がＶ１である場合、攻撃ユーザのユーザ属性がαであって、カード属性がαの戦士カードを含むことを条件（効果発動条件）として、カード属性がαの戦士カードの攻撃力が１０〜２０％の範囲内のランダムな値で増加する。チーム種別がＶ４である場合、タイプＴ１の戦士カードが３枚以上含むことを条件（効果発動条件）として、タイプＴ１の戦士カードの攻撃力が５〜１５％の範囲内のランダムな値で増加する。
図１３に例示した効果発動テーブルを前提としたときに、対応付け手段５５では、例えば図１４に示したように、例えばユーザの入力情報に基づいて、防御チームＡ〜Ｄに対する対応付けを行う。図１４は、ユーザＩＤごとに、防御チームＡ〜Ｄのそれぞれを、攻撃チームの想定される種別ごとに対応付ける、防御チームのチーム対応テーブルである。この例では、ユーザＩＤ：０００００１（ユーザＫＮＭ）の防御チームＡは、バトル相手の攻撃チームの種別がＶ１である場合を予め想定して、対応付けられていることを意味している。

対応付け手段５５の機能は、以下のようにして実現できる。例えば図１０のウェブページＰ３において、各防御チームに対応付けて設けられているプルダウンメニューｍ１５に用意される選択肢を、図１３に示したチーム種別に以下のように対応付けて、ゲームサーバ２０のＲＯＭ２２等に記憶させておく。ＣＰＵ２１は、ユーザによるプルダウンメニューｍ１５の選択結果を認識すると、対応付けられた種別をチーム対応テーブルに書き込む。なお、チーム対応テーブルは、例えばゲームデータベース３２に記憶させることができる。

［プルダウンメニューｍ１５の選択肢と種別の対応付けの例］
α対策チーム： Ｖ１
β対策チーム： Ｖ２
γ対策チーム： Ｖ３
Ｔ１対策チーム：Ｖ４
Ｔ２対策チーム：Ｖ５
Ｔ３対策チーム：Ｖ６

対応付け手段５５は、上述したように、防御チーム毎に、プルダウンメニューｍ１５に対する選択操作結果（ユーザの入力情報）に基づいて、複数の攻撃チームの種別の中からいずれかの種別を対応付けることが好ましい。これにより、ユーザは、予め自らの防御チーム内の戦士カードの選択等、攻撃チームの種別に対して適切な防御チームの設定を行うように動機付けられる。

判定手段５６は、本実施形態のバトル実行時に、バトル相手の攻撃チーム（グループ）の種別を判定する機能を備える。本実施形態のバトルは、非同期で行われるため、防御ユーザが、仕掛けられたバトルに効果的に予め対処しておくことができるようにするために、この判定手段５６と後述する選択手段５７が設けられている。

図１５を参照すると、判定手段５６の機能は、以下のようにして実現できる。図１５は、判定手段５６の機能を実現するために、ゲームサーバ２０のＣＰＵ２１によって実行される、攻撃チームのチーム種別の判定処理である。
ＣＰＵ２１は先ず、ユーザデータベース３１を参照して、バトルを仕掛けた攻撃ユーザのユーザ属性を判定する（ステップＳ１００）。ステップＳ１００において攻撃ユーザのユーザ属性がαである場合には、ＣＰＵ２１は、カードデータベースを参照して、攻撃ユーザの攻撃チームにα属性のカード（つまり、カード属性がαの戦士カード）があるか否かを判定する（ステップＳ１０２）。ＣＰＵ２１は、α属性のカードが存在する場合には（ステップＳ１０２：ＹＥＳ）、攻撃ユーザの攻撃チームのチーム種別をＶ１と判定し（ステップＳ１０４）、終了する。ステップＳ１０２においてα属性のカードが存在しない場合には（ステップＳ１０２：ＮＯ）、ステップＳ１１４へ進む。

ステップＳ１００において攻撃ユーザのユーザ属性がβである場合には、ＣＰＵ２１は、カードデータベースを参照して、攻撃ユーザの攻撃チームにβ属性のカード（つまり、カード属性がβの戦士カード）があるか否かを判定する（ステップＳ１０６）。ＣＰＵ２１は、β属性のカードが存在する場合には（ステップＳ１０６：ＹＥＳ）、攻撃ユーザの攻撃チームのチーム種別をＶ２と判定し（ステップＳ１０８）、終了する。ステップＳ１０６においてβ属性のカードが存在しない場合には（ステップＳ１０６：ＮＯ）、ステップＳ１１４へ進む。

ステップＳ１００において攻撃ユーザのユーザ属性がγである場合には、ＣＰＵ２１は、カードデータベースを参照して、攻撃ユーザの攻撃チームにγ属性のカード（つまり、カード属性がγの戦士カード）があるか否かを判定する（ステップＳ１１０）。ＣＰＵ２１は、γ属性のカードが存在する場合には（ステップＳ１１０：ＹＥＳ）、攻撃ユーザの攻撃チームのチーム種別をＶ３と判定し（ステップＳ１１２）、終了する。ステップＳ１１０においてγ属性のカードが存在しない場合には（ステップＳ１１０：ＮＯ）、ステップＳ１１４へ進む。

ステップＳ１１４では、ＣＰＵ２１は、カードデータベースを参照して、攻撃ユーザの攻撃チームにタイプＴ１の戦士カードが３枚以上あるか否か判定する。ＣＰＵ２１は、タイプＴ１のカードが３枚以上あると判定した場合には（ステップＳ１１４：ＹＥＳ）、攻撃ユーザの攻撃チームのチーム種別をＶ４と判定し（ステップＳ１１６）、終了する。タイプＴ１のカードが３枚以上ないと判定した場合には（ステップＳ１１４：ＮＯ）、ステップＳ１１８へ進む。

ステップＳ１１８では、ＣＰＵ２１は、カードデータベースを参照して、攻撃ユーザの攻撃チームにタイプＴ２の戦士カードが３枚以上あるか否か判定する。ＣＰＵ２１は、タイプＴ２のカードが３枚以上あると判定した場合には（ステップＳ１１８：ＹＥＳ）、攻撃ユーザの攻撃チームのチーム種別をＶ５と判定し（ステップＳ１２０）、終了する。タイプＴ２のカードが３枚以上ないと判定した場合には（ステップＳ１１８：ＮＯ）、ステップＳ１２２へ進む。

ステップＳ１２２では、ＣＰＵ２１は、カードデータベースを参照して、攻撃ユーザの攻撃チームにタイプＴ３の戦士カードが３枚以上あるか否か判定する。ＣＰＵ２１は、タイプＴ３のカードが３枚以上あると判定した場合には（ステップＳ１２２：ＹＥＳ）、攻撃ユーザの攻撃チームのチーム種別をＶ６と判定し（ステップＳ１２４）、終了する。タイプＴ３のカードが３枚以上ないと判定した場合には（ステップＳ１２２：ＮＯ）、ステップＳ１２６へ進む。
ステップＳ１２６へ進む場合には、ＣＰＵ２１は、攻撃ユーザの攻撃チームのチーム種別を判定せずに終了する。

上述したように、判定手段５６は、攻撃ユーザのユーザ属性（登録情報）、及び、攻撃チームに設定されている戦士カード（オブジェクト）若しくは戦士カードの組み合わせのうち少なくともいずれかに基づいて、攻撃チームの種別を判定してもよい。このような判定方法により、攻撃チームのバトルにおける能力に影響を与える要素に基づいて対戦相手のグループの種別を適切に判定することができる。

選択手段５７は、攻撃ユーザの攻撃チームに適用されるユーザの防御チーム（グループ）として、複数の防御チームのうち、判定手段５６により判定された攻撃チームの種別に対応付けられた防御チームを選択する機能を備える。
選択手段５７の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、攻撃ユーザの攻撃チームについて図１５のフローチャートに従って判定されたチーム種別に対応する防御チーム（防御チームＡ〜Ｄのいずれか）を、チーム対応テーブル（図１４）を参照して特定する。
なお、図１５のフローチャートにおいてチーム種別を判定しなかったときには、ＣＰＵ２１は、ユーザが予め設定する戦士カードごとの優先度と、戦士カードごとの防御力やコストとに基づいて防御チームを自動設定してバトル処理に適用してもよい。ここで、コストは例えば戦士カードに対応付けられる値であり、防御チームに設定されている戦士カードのコストの総和が所定量以下となるように制限してもよい。

バトル実行手段５８は、ユーザ間で、それぞれ戦士カード（オブジェクト）からなる攻撃チームと防御チームによるバトル処理を実行する機能を備える。
前述したように、本実施形態のゲームにおいて、ユーザ間のバトル処理は、ゲームにログインしているユーザが自らのトップページ上でメニューｍ２（「バトル」）を選択操作することによって開始され、そのユーザが攻撃チームを用いて、自ら選択したバトル相手を攻撃する側となる。バトル相手として選択された他のユーザは、防御チームを用いて防御する側となる。なお、バトル処理において、攻撃チームと防御チームに設定可能な戦士カードの数は、例えば所定数以内に限定してもよい。

攻撃チームと防御チームの勝敗は、例えば以下の方法で決定される。すなわち、攻撃チームに設定されているすべての戦士カードの攻撃力の値の総和（「総攻撃力」という。）と、防御チームに設定されているすべての戦士カードの防御撃力の値の総和（「総防御力」という。）を比較し、総攻撃力が総防御力以上である場合には攻撃チームの勝利と判定し、総攻撃力が総防御力未満である場合には防御チームの勝利と判定する。このとき、バトル中の個々の戦士カードの攻撃力及び防御力の値は、カードデータベースに記憶されている値に対して、攻撃チームにおいて発動する効果（図１３参照）と、防御チーム内の戦士カードが発動する効果（図８参照）とにより変動する場合がある。総攻撃力及び総防御力は、個々の戦士カードの変動後の値に基づいて算出される。

上述した攻撃チームと防御チームの勝敗の決定方法を採る場合、バトル実行手段５８の機能は、以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、バトルの対象となる攻撃ユーザと防御ユーザが決定されると、カードデータベースを参照して、攻撃ユーザの攻撃チームに設定されている戦士カード（つまり、フラグの値が「１」の戦士カード）とその攻撃力の値と、防御ユーザの防御チームに設定されている戦士カード（つまり、フラグの値が「１」の戦士カード）とその防御力の値を読み出す。このとき、ＣＰＵ２１は、防御チームＡ〜Ｄのうちチーム対応テーブルによって特定した防御チームを読み出し対象とする。

ＣＰＵ２１は、読み出した戦士カードとその攻撃力及び防御力のデータをＲＡＭ２３に展開して、以下の処理を行う。ＣＰＵ２１は、攻撃チームの効果発動テーブル（図１３）を参照して、読み出した攻撃チームの各戦士カードについて、いずれかの効果発動条件を満足するか否かを判定し、満足する場合には条件に対応して発動する効果に基づいて戦士カードの攻撃力の値を変動（増加）させる。なお、この効果は、所定の、あるいはランダムな確率で発動させるようにしてもよい。ＣＰＵ２１は、特技発動テーブル（図８）を参照して、読み出した防御チーム内の各戦士カードについて、発動する特技がある場合にはその特技に基づいて、攻撃チームの戦士カードの攻撃力を変動（低下）させる。なお、特技についても、所定の、あるいはランダムな確率で発動させるようにしてもよい。
ＣＰＵ２１は、変動後の各戦士カードの攻撃力及び防御力に基づいて、攻撃チームの総攻撃力と防御チームの総防御力を算出し、両者を比較する。その結果、ＣＰＵ２１は、総攻撃力が総防御力以上である場合には攻撃チームの勝利と判定し、総攻撃力が総防御力未満である場合には防御チームの勝利と判定する。

なお、ＣＰＵ２１は、バトル相手となる他のユーザの一覧を作成するときには（図１１のウェブページＰ５）、処理対象のユーザ（図１１では、ユーザＫＮＭ）と同じか、あるいは近い進行レベルのユーザを選択することが好ましい。また、図１１のウェブページＰ５では、バトル相手をユーザが選択する場合を例として説明したが、これに限られない。バトル相手をＣＰＵ２１が自動的に選択するようにしてもよい。

（７）本実施形態のバトル処理のフロー
次に、本実施形態のバトル処理のフローの一例について、図１６のフローチャートを参照して説明する。図１６は、本実施形態のバトル処理を示すフローチャートである。図１６のフローチャートにおける各処理の実行に伴って適宜、図１１に示した各ウェブページを表示するためのＨＴＭＬデータがゲームサーバ２０から通信端末１０宛に送信されるが、ＨＴＭＬデータの送信処理はフローチャートには記載せず、図１１に示したウェブページの符号（Ｐ０，Ｐ５〜Ｐ７）を記載してある。
なお、図１６のフローチャートは、図１１に示したように、処理対象のユーザＫＮＭが他のユーザに対してバトルを仕掛けた場合（つまり、攻撃ユーザがユーザＫＮＭである場合）を想定している。

ゲームサーバ２０のＣＰＵ２１は、トップページ（図１１のウェブページＰ０）上でメニューｍ２（「バトル」）が選択されたことを認識すると（ステップＳ１３０：ＹＥＳ）、処理対象となるユーザのバトル相手の候補となる所定数のユーザを抽出し（ステップＳ１３２）、その所定数のユーザの各々の表示画像、ユーザ名、進行レベルを含むウェブページ（図１１のウェブページＰ５）を表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。ＣＰＵ２１は、メニューｍ２が選択されたことを認識しない場合には（ステップＳ１３０：ＮＯ）、終了する。ＣＰＵ２１は、ウェブページＰ５上でいずれかのバトル相手が選択されたことを認識すると（ステップＳ１３４：ＹＥＳ）、選択されたバトル相手（つまり、防御ユーザ）とのバトル処理の開始を促すウェブページ（図１１のウェブページＰ６）を表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。ＣＰＵ２１は、ウェブページＰ６においてメニューｍ３０が選択されたことを認識すると（ステップＳ１３６：ＹＥＳ）、ステップＳ１３８以降の処理を行う。

ＣＰＵ２１は先ず、カードデータベースにアクセスして、攻撃ユーザであるユーザＫＮＭの攻撃チームを読み出す（ステップＳ１３８）。つまり、ＣＰＵ２１は、ユーザＫＮＭの攻撃チームに設定されているすべての戦士カードとその攻撃力の値を読み出して、ＲＡＭ２３に展開する。次いでＣＰＵ２１は、読み出した攻撃チームの種別を、図１５に示したフローチャートの処理に従って判定する（ステップＳ１４０）。本実施形態の例では、攻撃チームの種別としてＶ１〜Ｖ６のいずれかが判定される。

次にＣＰＵ２１は、チーム対応テーブル（図１４）を参照して、ステップＳ１４０で判定した攻撃チームの種別に対応した、防御ユーザ（図１１の例では、ユーザＡＢＣ）の防御チーム（防御チームＡ〜Ｄのいずれか）を選択（特定）し、カードデータベースにアクセスして、選択した防御チームを読み出す（ステップＳ１４２）。つまり、ＣＰＵ２１は、防御チームに設定されているすべての戦士カードとその防御力の値を読み出して、ＲＡＭ２３に展開する。攻撃チームの種別に対応した防御チームが選択されることにより、攻撃チームに対して有利となるような効果の発動を抑制することができるようになる。

攻撃チームと防御チームを読み出した後、ＣＰＵ２１は、発動する効果や特技に基づいて戦士カードの攻撃力及び／又は防御力を変動させる（ステップＳ１４４）。より具体的には、ＣＰＵ２１は、攻撃チームの効果発動テーブル（図１３）を参照して、読み出した攻撃チームの各戦士カードについて、いずれかの効果発動条件を満足するか否かを判定し、満足する場合には条件に対応して発動する効果に基づいて戦士カードの攻撃力の値を変動させる。なお、この効果は、所定の、あるいはランダムな確率で発動させるようにしてもよい。ＣＰＵ２１は、特技発動テーブル（図８）を参照して、読み出した防御チーム内の各戦士カードについて、発動する特技がある場合にはその特技に基づいて、攻撃チームの戦士カードの攻撃力を変動させる。なお、特技についても、所定の、あるいはランダムな確率で発動させるようにしてもよい。

ＣＰＵ２１は、ステップＳ１４４によって変動した各戦士カードの攻撃力及び防御力に基づいて、攻撃チームの総攻撃力と防御チームの総防御力を算出する（ステップＳ１４６）。ＣＰＵ２１は、算出された攻撃チームの総攻撃力と防御チームの総防御力を比較し、総攻撃力が総防御力以上である場合には攻撃チームの勝利と判定し、総攻撃力が総防御力未満である場合には防御チームの勝利と判定する（ステップＳ１４８）。勝敗を決定すると、ＣＰＵ２１は、勝敗の結果を含むウェブページ（図１１のウェブページＰ７）を表示するためのＨＴＭＬデータをユーザＫＮＭの通信端末１０宛に送信する。
なお、ＣＰＵ２１は、ステップＳ１４８において勝敗が決定された後に防御ユーザであるユーザＡＢＣがログイン又はアクセスを行った場合に、勝敗の結果を含むＨＴＭＬデータをユーザＡＢＣの通信端末１０宛に送信する。

本実施形態のバトルでは、ログイン中のユーザ（攻撃ユーザ）と、他のユーザ（防御ユーザ）とのバトルは非同期で行われ、防御ユーザは、バトルの実行時には、防御チームの能力に影響を与えうる何らかの操作を行うことはできない。しかしながら、防御ユーザは、攻撃チームの様々な種別（つまり、バトルに対して影響を与えうる攻撃チームの要素）を想定して、各種別に対して効果的な防御チームが選択されるように、複数の防御チームを予め設定しておくことが可能である。

例えば、ユーザは、自らが他のユーザからバトルを仕掛けられて防御ユーザの立場になったときのために予め、例えば防御チームＡに戦士カードＣ１，Ｃ１２等、攻撃チームのカード属性がαの戦士カードの攻撃力を低下させる特技を備えた戦士カード（図８参照）を設定しておく。その設定後にバトルを仕掛けられた場合に、バトルを仕掛けた攻撃ユーザの攻撃チームの種別がＶ１と判定されたときには、防御チームＡがバトルにおける防御チームとして選択される。ここで、攻撃チームの種別がＶ１であるときには、カード属性がαの戦士カードの攻撃力が増加するが、防御チームＡには、攻撃チームのカード属性がαの戦士カードの攻撃力を低下させる特技を備えた戦士カードが含まれているため、攻撃チームの効果の発動を抑制するように作用する。
よって、本実施形態のゲーム制御装置によれば、非同期で行われるバトルにおいて、バトルにおいて防御ユーザとなるユーザが予め、ログイン中の攻撃ユーザによる攻撃パターンを複数想定して防御方法を用意しておき、攻撃パターンに応じた防御方法が選択されるようにすることができるため、バトルにおけるユーザ間の不均衡が抑制されるようになる。

（８）変形例
上述した各実施形態では、オブジェクトの一例として戦士カードを挙げたが、これに限られない。オブジェクトであれば如何なるものでもよい。例えば、オブジェクトは、ゲーム上のキャラクタやアイテム等を含むものでよく、例えばゲーム上の仮想的な人物や生物、若しくはモンスター等であり、本実施形態で示したように、それらがカードに表示されているものをも含む。

上述した実施形態において、攻撃チームにおいて発動する効果の内容や、防御チームに設定されている戦士カードの特技の内容は、それぞれ図１３や図８に示した内容に限られない。例えば、図１３では、攻撃チームにおいて発動する効果の内容は、自らの攻撃チームに設定されている戦士カードの攻撃力を増加させる効果の例であるが、防御チームの防御力を低下させる効果であってもよい。図８では、防御チームに設定されている戦士カードの特技の内容は、攻撃チームの攻撃力を低下させる効果の例であるが、自らの防御チームの防御力を増加させる効果であってもよい。

上述した実施形態において、判定手段５６による攻撃チームの種別の判定処理は、図１５に示した処理に限られない。判定手段５６による判定処理は、バトルの実行時において攻撃チームにおいて発動するバトル上の効果に適切に対応することができる防御チームを選択するために行われる。よって、攻撃チームにおける効果発動条件と、攻撃チームの種別の判定条件が一致していればよく、種別の判定処理は、攻撃チームにおける様々な効果発動条件に応じて変更されてよい。
例えば、図１３に例示した攻撃チームにおける効果発動条件では、攻撃チーム内に同一タイプの戦士カードが所定数（３枚）含まれることが条件として設定されているが、攻撃チーム内における同一タイプの戦士カードが所定の割合以上含まれることを条件として設定してもよい。その場合には、チーム種別Ｖ４〜Ｖ６の判定条件（ステップＳ１１４，Ｓ１１８，Ｓ１２２）をそれぞれ、「攻撃チームにタイプＴ１〜Ｔ３のカードが所定割合以上ある？」とすればよい。

上述した実施形態では、ゲームにログインしているユーザがバトル開始の操作を行い、そのユーザが攻撃チームを用いる攻撃ユーザとなり、バトル相手として選択された他のユーザが防御チームを用いる防御ユーザとなる場合について説明したが、逆であってもよい。つまり、ゲームにログインしているユーザがバトル開始の操作を行う場合、そのユーザが防御チームを用いる防御ユーザとなって、選択した他のユーザの攻撃チームからの攻撃を防ぐというゲーム設定でもよい。その場合、ユーザは、複数の攻撃チームを予め防御チームの種別に対応付けて設定しておき、適切な攻撃チームが選択されるようにする。つまり、非同期で行われるバトルにおいて、対処できない一方のユーザが予め、ログイン中の他のユーザによる防御パターンを複数想定して攻撃方法を用意しておき、防御パターンに応じた攻撃方法が選択されるようにすることができるため、バトルにおけるユーザ間の不均衡が抑制されるようになる。
以下、上述した各実施形態の変形例についてさらに説明する。

（８−１）変形例１
上述した実施形態において、設定手段５４は、防御ユーザの進行状況に応じて、設定可能な防御チーム（グループ）の数を変動させてもよい。
「ユーザの進行状況」とは、上述した実施形態のゲームにおけるクエスト又はバトルの進行についての進行レベルのほか、ゲームのステージ、ゲームの進行の速さなど、ユーザによるゲームの進行に関する状況である。
例えばゲームの進行レベルが大きくなるほど設定可能な防御チームの数が増加する場合、ユーザは、バトルの実行時に有利となるようにゲームの進行レベルを大きくするように動機付けられる。また、例えばゲームの進行が速いほど設定可能な防御チームの数が増加する場合、ユーザは、バトルの実行時に有利となるようにゲームを継続的に進捗させるように動機付けられる。つまり、いったんゲームの進行レベルが大きくなった後でも、その後にゲームの進行が行われなくなった場合には、設定可能な防御チームの数が低下してしまうため、ユーザは、設定可能な防御チームの数が低下しないように継続的にゲームを進めることが動機付けられる。

本変形例の対応付け手段５５の機能を実現するために、設定可能な防御チームの数の範囲（例えば、３〜１０個等）を予め決めておき、その範囲の最大値に相当する数の防御チームをユーザＩＤごとにカードデータベースに設けておく。ゲームの進行状況を示す値として防御チームの進行レベルの値を採る場合、ＣＰＵ２１は、ユーザデータを参照して、防御チームの進行レベルを読み出す。ゲームの進行状況を示す値として防御チームの進行の速さの値を採る場合、ＣＰＵ２１は、一定期間（例えば１週間）ごとにユーザデータを参照して、防御チームの進行レベルを読み出し、その一定期間における進行レベルの変化を算出することによって進行の速さの値（進行レベル／週）を算出する。進行レベル又は進行の速さと、防御チームの設定可能な数との対応テーブルを予めＲＯＭ２２等に設けておき、ＣＰＵ２１がＲＯＭ２２内の対応テーブルを参照して、防御チームの設定可能な数をユーザごとに算出する。あるいは、ＣＰＵ２１は、進行レベル又は進行の速さを所定の演算式に当てはめることで、防御チームの設定可能な数をユーザごとに算出してもよい。ＣＰＵ２１は、ユーザごとに防御チームの設定可能な数を算出すると、そのユーザに対して、設定可能な数までの防御チームを編成可能とする。ＣＰＵ２１は、防御チームの数の変動に対応して、例えば図１０のウェブページＰ３のプルダウンメニューｍ１５に設定されている選択肢の数を変動させるとともに、防御チームのチーム対応テーブルにおいて対応付け可能な数（防御チームと、攻撃チームの種別との組み合わせが可能な数）を変動させる。

（８−２）変形例２
上述した実施形態のゲームのバトル処理は、防御ユーザのログインの有無と無関係に実行されるが、判定手段５６は、バトルの実行時に防御チームがログインしている場合に、攻撃チーム（対戦相手のグループ）の種別を判定してもよい。なお、判定手段５６は、バトルの実行時に防御ユーザがログインしていない場合であっても、その防御ユーザの仲間がログインしている場合に、攻撃チームの種別を判定してもよい。
なお、現在時刻がユーザのログイン時刻の後の所定時間内である場合に、ユーザがログインしていると判定してもよいし、現在時刻がユーザの最終アクセス時刻から所定時間内である場合に、ユーザがログインしていると判定してもよい。
上述した実施形態のゲームのバトル処理のように、バトル処理が防御チームのログインの有無と無関係に実行される場合には、防御チームがログイン中であるにも関わらず、バトルを仕掛けてきた攻撃ユーザ（対戦相手）との間のバトルに対処することができない状況に対する不満が特に強いと考えられるが、そのような状況で特に、予め設定しておいた複数の防御チーム（グループ）のうち適切な防御チームによってバトルが行われるようにすることで、上記不満を抑制することができるようになる。
また、防御ユーザの仲間がログインしている場合にも攻撃チームの種別を判定することで、仲間がログインしているときに適切な防御チームがバトルで選択されるため、ゲームのソーシャル性を高めることができる。

本変形例を実現するために、ゲームサーバ２０のＣＰＵ２１は、ユーザがログインした時刻やアクセスした時刻のログデータを、例えばユーザデータに記憶しておく。ＣＰＵ２１は、バトル処理を行うときには、防御ユーザがログインしているか否かを判定する。つまり、現在時刻が防御ユーザのログイン時刻の後の所定時間内であるか、又は現在時刻が防御ユーザからの最終アクセス時刻から所定時間内であるか否かを判定する。ＣＰＵ２１は、防御ユーザがログインしていると判定した場合に、上記バトル処理において攻撃ユーザの攻撃チームの種別を判定して、その判定結果に応じた防御チームを選択するようにする。防御ユーザがログインしていないと判定した場合、ＣＰＵ２１は、複数の防御チームのうちの既定の防御チームをバトル処理に適用してもよいし、ユーザが予め設定する戦士カードごとの優先度と、戦士カードごとの防御力やコストとに基づいて防御チームを自動設定してバトル処理に適用してもよい。ここで、コストは例えば戦士カードに対応付けられる値であり、防御チームに設定されている戦士カードのコストの総和が所定量以下となるように制限してもよい。
なお、防御ユーザの仲間がログインしているか否かを判定する場合には、ＣＰＵ２１は、防御ユーザのユーザデータを参照して、仲間のユーザを特定し、その仲間のユーザについて同様に、ログイン時刻やアクセスがあった時刻に基づいてログインしているか否かを判定する。

（８−３）変形例３
上述した実施形態において、対応付け手段５５は、ユーザの進行状に況応じて、対応付けることが可能な種別を変動させてもよい。例えば、攻撃チーム（グループ）の種別が３０種類、つまり、攻撃チームの効果発動条件が３０種類設けられている場合、進行レベルが増加するにつれて、対応付け可能な種別の数を初期値（例えば５種類）から１０、１５、…といった具合に次第に増加させていく。これにより、ユーザがゲームを進行させるほど、攻撃ユーザ（対戦相手）のより多くの攻撃チーム（グループ）の種別に対処することができ、より有利な立場に立てるため、ユーザによるゲームの進行を動機付けることができる。なお、変形例１と同様に、例えばゲームの進行が速いほど対応付けることが可能な種別の数を増加させてもよい。この場合、ユーザは、バトルの実行時に有利となるようにゲームを継続的に進捗させるように動機付けられる。
本変形例の対応付け手段５５の機能を実現するために、例えば攻撃チームの種別の数と同じ数の防御チームがユーザＩＤごとにカードデータベースに設けられており、ゲームサーバ２０のＣＰＵ２１は、ユーザの進行レベルに予め対応付けられた数の防御チームをユーザが編成可能とする。ＣＰＵ２１は、防御チームの数の増加に対応して、例えば図１０のウェブページＰ３のプルダウンメニューｍ１５に設定されている選択肢の数を増加させるとともに、防御チームのチーム対応テーブルにおいて対応付け可能な数（防御チームと、攻撃チームの種別との組み合わせが可能な数）を増加させる。

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

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

上述した各実施形態では、ネットワーク上のゲームサーバ２０及びデータベースサーバ３０によって、図１２に示した各手段が備える機能を実現する構成としたが、この構成に限られない。図１２に示した手段のうち少なくとも一部の手段を通信端末１０によって実現する構成としてもよい。通信端末１０とゲームサーバ２０とでは実質的に同一のハードウエア構成を採るため、上記実施形態に記載したようにして通信端末１０によっても各機能を実現できる。なお、上述した各実施形態では、カードデータベースをゲームデータベース３２が記憶する構成としたが、カードデータベースを通信端末１０内のＨＤＤ(Hard Disk Drive；図示せず)に、例えば一時的に記憶してもよい。図１７（ａ），（ｂ）には、本実施形態のゲーム制御装置の各機能（図１２に示す各機能）について、通信端末１０と、ゲームサーバ２０及びデータベースサーバ３０との間の分担例を示す。

１０…通信端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１４…画像処理部
１５…指示入力部
１６…表示部
１７…通信インタフェース部
１８…バス
２０…ゲームサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…データベースアクセス部
２５…通信インタフェース部
２６…バス
３０…データベースサーバ
３１…ユーザデータベース
３２…ゲームデータベース
５１…登録手段
５２…クエスト実行手段
５３…関連付け手段
５４…設定手段
５５…対応付け手段
５６…判定手段
５７…選択手段
５８…バトル実行手段

Claims (9)

1. ユーザと対戦相手との間で、オブジェクトからなるグループによる対戦ゲームを実行する実行手段と、
   ユーザと複数のオブジェクトを関連付ける関連付け手段と、
   前記ユーザに関連付けられた複数のオブジェクトを基に、前記ユーザの複数のグループを設定する設定手段と、
   前記設定手段によって設定された複数のグループの各々を、グループの種別に対応付ける対応付け手段と、
   前記対戦ゲームの実行時に、前記対戦相手のグループの種別を判定する判定手段と、
   前記対戦相手との対戦に適用される前記ユーザのグループとして、前記複数のグループのうち、前記判定手段により判定された対戦相手の種別に対応付けられたグループを選択する選択手段と、
   を備えた、ゲーム制御装置。
2. 前記判定手段は、前記対戦相手としての他のユーザの登録情報、及び、前記対戦相手のグループを構成するオブジェクト若しくはオブジェクトの組み合わせのうち少なくともいずれかに基づいて、前記対戦相手のグループの種別を判定することを特徴とする、
   請求項１に記載されたゲーム制御装置。
3. 前記設定手段は、前記ユーザの進行状況に応じて、設定可能なグループの数を変動させることを特徴とする、
   請求項１又は２に記載されたゲーム制御装置。
4. 前記実行手段は、前記ユーザの前記対戦ゲームへのログインの有無とは無関係に前記対戦ゲームを実行し、
   前記判定手段は、対戦ゲームの実行時に前記ユーザがログインしている場合に、前記対戦相手のグループの種別を判定することを特徴とする、
   請求項１〜３のいずれかに記載されたゲーム制御装置。
5. 前記対応付け手段は、前記ユーザの進行状況に応じて、対応付けることが可能な種別を変動させることを特徴とする
   請求項１〜４のいずれかに記載されたゲーム制御装置。
6. 前記対応付け手段は、グループ毎に、ユーザの入力情報に基づいて、複数の種別の中からいずれかの種別を対応付けることを特徴とする、
   請求項１〜５のいずれかに記載されたゲーム制御装置。
7. ユーザと複数のオブジェクトを関連付けるステップと、
   前記ユーザに関連付けられた複数のオブジェクトを基に、前記ユーザの複数のグループを設定するステップと、
   前記設定するステップによって設定された複数のグループの各々を、グループの種別に対応付けるステップと、
   ユーザと対戦相手との間で、オブジェクトからなるグループによる対戦ゲームを実行するに当たって、前記対戦相手のグループの種別を判定するステップと、
   前記対戦相手との対戦に適用される前記ユーザのグループとして、前記複数のグループのうち、前記判定するステップにより判定された対戦相手の種別に対応付けられたグループを選択するステップと、
   を備えた、ゲーム制御方法。
8. ゲームの実行を制御するために、コンピュータに、
   ユーザと対戦相手との間で、オブジェクトからなるグループによる対戦ゲームを実行する機能、
   ユーザと複数のオブジェクトを関連付ける機能、
   前記ユーザに関連付けられた複数のオブジェクトを基に、前記ユーザの複数のグループを設定する機能、
   前記設定された複数のグループの各々を、グループの種別に対応付ける機能、
   前記対戦ゲームの実行時に、前記対戦相手のグループの種別を判定する機能、及び、
   前記対戦相手との対戦に適用される前記ユーザのグループとして、前記複数のグループのうち、前記判定された対戦相手の種別に対応付けられたグループを選択する機能、
   を実現させるためのプログラム。
9. 通信端末と、当該通信端末からアクセス可能なサーバと、を含むゲームシステムであって、
   ユーザと対戦相手との間で、オブジェクトからなるグループによる対戦ゲームを実行する実行手段、
   ユーザと複数のオブジェクトを関連付ける関連付け手段、
   前記ユーザに関連付けられた複数のオブジェクトを基に、前記ユーザの複数のグループを設定する設定手段、
   前記設定手段によって設定された複数のグループの各々を、グループの種別に対応付ける対応付け手段、
   前記対戦ゲームの実行時に、前記対戦相手のグループの種別を判定する判定手段、及び、
   前記対戦相手との対戦に適用される前記ユーザのグループとして、前記複数のグループのうち、前記判定手段により判定された対戦相手の種別に対応付けられたグループを選択する選択手段、
   の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
   ゲームシステム。

Images