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

Description

本発明は、プレイ対象となる複数のパートを含むゲームの実行を制御する技術に関する。

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

上述したソーシャルゲームにおいて、ユーザが複数のパートの各々をプレイすることができるように構成されたものが知られている。例えば、非特許文献１には、「クエスト」、「バトル」、「合成」等のパートを含むソーシャルゲーム（ドラゴンコレクション（登録商標））が記載されている。非特許文献２，３には、「スカウト」、「試合」、「強化」等のパートを含むソーシャルゲーム（プロ野球ドリームナイン（登録商標））が記載されている。

アプリＳＴＹＬＥ Vol.5（株式会社イースト・プレス、2011年11月15日発行），7頁 アプリＳＴＹＬＥ Vol.4（株式会社イースト・プレス、2011年9月15日発行），22頁 アプリＳＴＹＬＥ Vol.3（株式会社イースト・プレス、2011年7月1日発行），24-25頁

ところで、上述した従来のソーシャルゲームのように、ゲームが複数のパートからなりユーザが各々をプレイすることができるように構成されている場合、ゲームの性質あるいはゲームの設定等によっては、ユーザが特定のパートは頻繁にプレイする一方で、別のパートはあまりプレイしない場合があった。ゲームの制作者は複数のパートを満遍なくユーザがプレイすることを意図してゲームを制作しているが、あまりプレイしないパートが存在することは、ゲームの興趣性をユーザに十分に味わうことができない点で好ましくない。

本発明は上述した観点に鑑みてなされたもので、ゲームが複数のパートからなりユーザが各々のパートをプレイすることができるように構成されている場合に、一部のパートがあまりプレイされないという状況を生じ難くしたゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供することを目的とする。

本発明の第１の観点は、プレイ対象となる複数のパートを含むゲームの実行を制御するゲーム制御装置であって、
ユーザの操作に応じて、前記複数のパートの各々におけるゲームを進行させる手段であって、パートごとに時間経過に応じて回復する異なるポイントを消費することでゲームを進行させるゲーム進行手段と、
前記複数のパートのうち第１のパートにおけるゲームの進行状況が所定の条件を満たすか否かを判定する判定手段と、
前記所定の条件を満たした場合に、前記複数のパートのうち前記第１のパートとは異なる第２のパートにおいて、所定期間又は所定回数分のプレイだけ、前記ユーザが有利になるように第２のパートのゲームの難易度を変更する変更手段と、
を備える。

このゲーム制御装置では、ゲームの複数のパートのうち第１のパートにおけるゲームの進行状況が所定の条件を満たすと、ユーザが有利になるように第２のパートのゲームの難易度が変更される。そのため、ユーザは、当初は第１のパート自体にそれほど興味がなくあまりプレイせずに第２のパートを頻繁にプレイする場合であっても、第２のパートで有利な状況を得るために第１のパートをプレイするように動機付けられる。よって、このゲーム制御装置によれば、ゲームが複数のパートからなりユーザが各々をプレイすることができるように構成されている場合に、一部のパートがあまりプレイされないという状況を生じ難くすることができる。
また、第２のパートのゲームの難易度が変更されるのは、所定期間又は所定回数分のプレイだけに限られる。仮に、無期限に第２のパートのゲームの難易度が変更されてしまうと、ユーザが第１のパートのプレイを継続的にプレイしない状況が考えられ、そのような状況を回避することが好ましい。

上記ゲーム制御装置において、前記ゲーム上のキャラクタと、キャラクタの能力を表すキャラクタデータとを対応付けて記憶する記憶手段、を備え、前記第２のパートは、前記ユーザによる操作対象となるキャラクタの能力に基づいてゲームを進行させるものであって、前記変更手段は、前記第２のパートにおいて、前記ユーザによる操作対象となるキャラクタの能力が高くなるように、当該キャラクタに対応するキャラクタデータを変更してもよい。
この明細書において「キャラクタ」とは、例えばゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカードに表示されているものをも含む。キャラクタの能力を表すキャラクタデータとは、例えば、キャラクタの攻撃力・防御力やレベル、キャラクタの保持する能力等のデータであってよい。
このゲーム制御装置によれば、ユーザは、自らの操作対象となるキャラクタの能力が高くなることで、第２のパートのゲームを進行させやすくなるという利益が得られうる。ユーザはその利益を得るために、第１のパートのプレイを積極的に行うことが動機付けられる。

上記ゲーム制御装置において、前記ゲーム上のキャラクタと、キャラクタの能力を表すキャラクタデータとを対応付けて記憶する記憶手段、を備え、前記第２のパートは、前記ユーザによる操作対象となるキャラクタの能力に基づいてゲームを進行させるものであって、前記変更手段は、前記第２のパートにおいて、前記ユーザによる操作対象となるキャラクタの能力が高くなるように当該キャラクタに対応するキャラクタデータを変更する確率を増加させてもよい。
このゲーム制御装置によれば、ユーザは、自らの操作対象となるキャラクタの能力が高くなる確率が増加することで、第２のパートのゲームを進行させやすくなる可能性が高くなる、という利益が得られうる。ユーザはその利益を得るために、第１のパートのプレイを積極的に行うことが動機付けられる。

上記ゲーム制御装置において、ユーザと、当該ユーザが利用可能なゲーム上のポイントとを対応付けて記憶する第２の記憶手段、を備え、前記第２のパートは、前記ポイントが所定値以下になった場合にゲームの進行が抑制されるものであって、前記変更手段は、前記第２のパートにおいて、前記所定の条件を満たしたユーザに対応するポイントの消費量を少なくさせてもよい。
このゲーム制御装置によれば、ユーザは、ポイントの消費量が低下することでポイントが所定値以下になるまでの時間が長くなるため、第２のパートのプレイを長く行うことができる、という利益が得られうる。ユーザはその利益を得るために、第１のパートのプレイを積極的に行うことが動機付けられる。

上記ゲーム制御装置において、前記第２のパートは、複数のステージから構成されており、前記第２のパートの前記所定期間は、前記所定の条件を満たしたユーザがプレイ中のステージが終了するまでの期間であってもよい。なお、ステージとは、ゲーム上で区切られた範囲あるいは構成単位を示すものである。この場合、ユーザがプレイ中のステージを終了した後、次のステージで再度ゲームの難易度を低くする目的で、ユーザは、第１のパートをプレイすることが動機付けられる。

ユーザと、当該ユーザのゲーム上のレベルとを対応付けて記憶する第３の記憶手段、を備え、前記第２のパートの前記所定期間は、前記所定の条件を満たしたユーザのレベルが低いほど長く設定されてもよい。これにより、レベルが低いユーザ、つまり初級レベルのユーザに対しては、上級レベルのユーザよりも相対的に長期間の間、ゲームの難易度が低くなる。そのため、初級レベルのユーザであるほど実質的にゲームを有利に進行させやすく設定することができる。なお、ゲーム上のレベルは、例えば、対戦型ゲームにおいてユーザ、若しくはユーザが操作するキャラクタ等の強さの段階を表す数値であるほか、ユーザのプレイ時間の合計値、ユーザのゲームの実行回数（ゲームがネットワークを介して提供される場合には、ユーザのログイン回数等）などであってもよい。

上記ゲーム制御装置において、ユーザと、当該ユーザが利用可能なゲーム上のポイントとを対応付けて記憶する第２の記憶手段、を備え、前記第２のパートは、前記ポイントが所定値以下になった場合にゲームの進行が抑制されるものであって、前記第２のパートの前記所定期間は、前記所定の条件を満たしたユーザの、前記所定の条件を満たしてからの前記ポイントの消費量の積算値が所定の値に達するまでの期間であってもよい。この構成では、ユーザが有利になるように第２のパートのゲームの難易度が変更される所定期間を、ユーザ毎に柔軟に設定することができる。すなわち、ポイントの消費量は、ユーザ毎に、あるいはユーザのゲーム状況によって変わる場合が考えられるが、その場合でもユーザが有利になる期間を制限することができる。

上記ゲーム制御装置において、前記ゲーム進行手段は、前記複数のパートの各々に対するユーザの実行状況に基づいて、前記複数のパートの中から前記第１のパートと前記第２のパートを決定してもよい。ここで、ユーザによるパートの「実行状況」とは、例えば、パートの実行時間、実行回数、実行頻度（所定期間毎の実行時間又は実行回数）、最終実行時刻（例えば、最終ログイン又はログアウト時刻）から現在時刻までの経過時間等であってもよい。つまり、ユーザの実行状況は、そのユーザが複数のパートの中で特定のパートを頻繁に実行しているか否か（つまり、特定のパートをプレイすることに興味が高いか低いか）を判別可能となる情報であれば如何なる情報であってもよい。例えば、ユーザにとって興味が低いと考えられるパートを第１のパートとし、ユーザにとって興味が高いと考えられるパートを第２のパートとして決定してもよい。これにより、ユーザにとって興味が低いと考えられる第１のパートを行うことで、ユーザにとって興味が高いと思われる第２のパートにおいて有利な効果を得ることができるために、興味が低い第１のパートの実行をユーザに促すことができる。また逆に、ユーザにとって興味が高いと考えられるパートを第１のパートとし、ユーザにとって興味が低いと考えられるパートを第２のパートとして決定してもよい。第１のパートをさらに頻繁に実行して所定の条件を満たすことで、例えば第２のパートで利用可能な強力なアイテム等が入手できれば、そのアイテムを使って普段あまりプレイしていない第２のパートもプレイしてみようという動機付けになる。

上記ゲーム制御装置において、前記ゲーム進行手段は、前記複数のパートの各々に対するユーザの実行回数又は実行時間を計数し、実行回数が相対的に少ない、又は実行時間が相対的に短いパートを前記第１のパートとし、実行回数が相対的に多い、又は実行時間が相対的に長いパートを前記第２のパートとしてもよい。これにより、ユーザにとって興味が低いと考えられる実行回数の少ないパート、又は実行時間が短いパートを行うことで、ユーザにとって興味が高いと思われる実行回数の多いパート、又は実行時間が長いパートにおいて有利な効果を得ることができるために、興味が低いパートの実行をユーザに促すことができる。

上記ゲーム制御装置において、前記変更手段は、前記第１のパート、及び／又は、前記第２のパートの実行状況に基づいて、前記第２のパートの前記所定期間、又は前記所定回数を変更してもよい。例えば、実行回数が相対的に少ない、又は実行時間が相対的に短いパートを第１のパートとし、実行回数が相対的に多い、又は実行時間が相対的に長いパートを第２のパートとする場合、第１のパートの実行回数が相対的に少ない、又は実行時間が相対的に短いほど、第２のパートにおいて難易度が低下する所定期間が長く、又は所定回数が多くなり、第２のパートで受ける利益が増大する。これにより、第１のパートを実行しようとする動機付けがより強くなり、各パートをバランス良くユーザに実行させる仕組みを構築することができる。なお、第１のパートと第２のパートの実行回数の差が相対的に大きい、又は実行時間の差が相対的に大きいほど、第２のパートにおいて難易度が低下する所定期間を長く、又は所定回数を多くしても同様の効果が得られる。

上記ゲーム制御装置において、前記所定の条件を、前記第１のパート、及び／又は、前記第２のパートの実行状況に基づいて変動させるようにしてもよい。例えば、実行回数が相対的に少ない、又は実行時間が相対的に短いパートを第１のパートとし、実行回数が相対的に多い、又は実行時間が相対的に長いパートを第２のパートとする場合、第１のパートの実行回数が相対的に少ない、又は実行時間が相対的に短いほど、第１のパートのゲームの進行状況に関する所定の条件をより緩和する。これにより、所定の条件を満たすことが容易となるため、第１のパートを実行して第２のパートにおける利益（難易度が低下すること）を得るようにする動機付けが働きやすくなり、各パートをバランス良くユーザに実行させる仕組みを構築することができる。なお、第１のパートと第２のパートの実行回数の差が相対的に大きい、又は実行時間の差が相対的に大きいほど、第１のパートのゲームの進行状況に関する所定の条件をより緩和しても同様の効果が得られる。

本発明の第２の観点は、プレイ対象となる複数のパートを含むゲームの実行を制御するゲーム制御方法であって、ゲーム制御装置が、
ユーザの操作に応じて、前記複数のパートの各々におけるゲームを進行させるステップであって、パートごとに時間経過に応じて回復する異なるポイントを消費することでゲームを進行させるステップと、
前記複数のパートのうち第１のパートにおけるゲームの進行状況が所定の条件を満たすか否かを判定するステップと、
前記所定の条件を満たした場合に、前記複数のパートのうち前記第１のパートとは異なる第２のパートにおいて、所定期間又は所定回数分のプレイだけ、前記ユーザが有利になるように第２のパートのゲームの難易度を変更するステップと、
を含む。

本発明の第３の観点は、プレイ対象となる複数のパートを含むゲームの実行を制御するために、コンピュータに、
ユーザの操作に応じて、前記複数のパートの各々におけるゲームを進行させる機能であって、パートごとに時間経過に応じて回復する異なるポイントを消費することでゲームを進行させる機能と、
前記複数のパートのうち第１のパートにおけるゲームの進行状況が所定の条件を満たすか否かを判定する機能と、
前記所定の条件を満たした場合に、前記複数のパートのうち前記第１のパートとは異なる第２のパートにおいて、所定期間又は所定回数分のプレイだけ、前記ユーザが有利になるように第２のパートのゲームの難易度を変更する機能と、
を実現させるためのプログラムである。

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

本発明の第４の観点は、ユーザによって操作される通信端末と、当該通信端末とネットワークを介して接続され、プレイ対象となる複数のパートを含むゲームの実行を制御するサーバと、を備えたゲームシステムであって、
ユーザの操作に応じて、前記複数のパートの各々におけるゲームを進行させる手段であって、パートごとに時間経過に応じて回復する異なるポイントを消費することでゲームを進行させるゲーム進行手段、
前記複数のパートのうち第１のパートにおけるゲームの進行状況が所定の条件を満たすか否かを判定する判定手段、及び、
前記所定の条件を満たした場合に、前記複数のパートのうち前記第１のパートとは異なる第２のパートにおいて、所定期間又は所定回数分のプレイだけ、前記ユーザが有利になるように第２のパートのゲームの難易度を変更する変更手段
の各手段を、前記通信端末又は前記サーバのいずれか一方が備える。

本発明のゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムによれば、ゲームが複数のパートからなりユーザが各々のパートをプレイすることができるように構成されている場合に、一部のパートがあまりプレイされないという状況を生じ難くすることができる。

実施形態のゲームシステムの基本構成を示す図。 実施形態の通信端末の外観の例を示す図 実施形態の通信端末の構成を示すブロック図。 実施形態のゲームサーバの構成を示すブロック図。 実施形態のデータベースサーバの構成を示すブロック図。 データベースサーバに含まれるユーザデータベースの構成例を示す図。 実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 本実施形態のゲームのトップページを表示例を示す図。 ユーザがスカウトパートを実行するときのウェブページの一例を示す図。 ユーザがスカウトパートを実行するときのウェブページの一例を示す図。 ユーザが強化パートを実行するときのウェブページの一例を示す図。 ユーザが強化パートを実行するときのウェブページの一例を示す図。 試合パートが実行されるときのフローチャートの一例を示す図。 ユーザごとにフラグを管理する管理データの構成を例示する図。 ユーザが試合パートを実行するときのウェブページの一例を示す図。 ユーザが抽選パートを実行するときのウェブページの一例を示す図。 ミッションパートを実行するときのウェブページの一例を示す図。 ミッションパートを実行するときのウェブページの一例を示す図。 ミッションパートを実行するときのウェブページの一例を示す図。 実施形態のゲームサーバの主要な処理の一例を示すフローチャート。

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

また、図１には図示していないが、ゲームサーバ２０とは別に各通信端末１０のユーザを認証するための認証サーバを設けてもよい。また、多くの通信端末１０からのアクセスを受け入れるために複数のゲームサーバ２０を設ける場合は、その複数のゲームサーバ２０間の負荷を調整するためのロードバランサを設けてもよい。また、ゲームサーバ２０は単一のサーバ装置として構成してもよいが、機能を分散させた複数のサーバ装置として構成してもよい。
データベースサーバ３０は、ゲームを実行する上での後述する様々な情報を格納しており、それらの情報の読み書きのためにゲームサーバ２０と例えば有線で接続される。

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

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

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

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

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

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

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

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

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

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

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

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

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

以下の説明では、ユーザデータベース３１に含まれるユーザＩＤ、あるいはユーザを特定する表示名（後述する）ごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、以下のとおりである。
・表示名／表示画像
ゲームの実行時に通信端末１０にユーザを特定するために表示される表示名及び表示画像である。表示名はユーザによって予め指定される所定長以下のテキストであり、表示画像は例えばユーザによって予め選択されるアバタ画像である。表示名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
・技能レベル
ゲーム上のユーザの技能レベル示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値であり、例えばゲームにおけるスカウトパートの探索を継続的に行うことで順次技能レベルが上がるように構成される。
・行動ポイント
上記サッカー形式のデジタルカードゲームにおいて、ユーザによるゲーム上のスカウトを行う上で必要となるポイントである。行動ポイントは、スカウトパートをプレイすることで低減し、所定の時間が経過する毎に回復（増加）する値である。
・運営ポイント
上記サッカー形式のデジタルカードゲームにおいて、ユーザによるゲーム上の対戦を行う上で必要となるポイントである。運営ポイントは、他のユーザとの対戦等によって低減し、所定の時間が経過する毎に回復（増加）する値である。
・強化ポイント
上記サッカー形式のデジタルカードゲームにおいて、ユーザによる選手カードの強化（後述する一体化処理）を行う上で必要となるポイントである。強化ポイントは、選手カードの強化を行うことで低減し、他のユーザとの対戦で勝利するか、あるいは所定の時間が経過する毎に回復（増加）する値である。
・エールポイント
上記サッカー形式のデジタルカードゲームにおいて、仲間へ応援メッセージの送信することでユーザが取得するポイントである。
・選手数
ユーザが保有する選手カードの数である。選手数は、スカウトパートや強化パートの実行によって増減する。選手数の最大値（例えば、６０）は予め規定されている。
・所持コイン
ユーザがゲーム上で有料機能を利用するときに必要となるゲーム上の仮想通貨（コイン）の所持額である。所持コインは、ユーザがゲーム上で有料機能を利用したときに消費（低減）し、ユーザが、サービス提供者等に所定の方法で実際の金銭を支払うことでその支払額に応じて増加する。
・仲間のユーザＩＤ
対象とするユーザＩＤの仲間である他のユーザＩＤのデータである。
・保有カードの画像データ
上記サッカー形式のデジタルカードゲームの場合、保有カードの画像データは、ユーザが保持する選手カードについての画像を含むデータである。
・保有カードのパラメータ
保有カードのパラメータは、選手カードの能力値を示すデータである。例えば、図６に示すように、パラメータの項目として「オフェンス」，「ディフェンス」，「テクニック」の各々の各能力値が含まれてもよい。なお、選手カードはゲーム上のキャラクタの一例であり、選手カードのパラメータはキャラクタデータの一例である。

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

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

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

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

ゲーム進行手段５２は、通信端末１０に対するユーザの操作に応じて、通信端末１０に表示されるウェブページを逐次更新するためのＨＴＭＬデータを送信することで、ゲームを進行させる。例示のサッカー形式のデジタルカードゲーム（以下、適宜単に「ゲーム」と略記する。）は、ユーザのプレイ対象となる以下の複数のパート（部分）からなる。

・スカウトパート：自らのチームを作り上げていくために選手カードを探索するパート
・強化パート：２枚以上の選手カードを一体化して選手カードの能力を上昇させるパート
・試合パート：他のユーザのチームとサッカーの対戦するパート
・抽選パート：抽選によって選手カードを入手することを可能とするパート
・ミッションパート：自らのチームで日本全国の都道府県を制覇していくパート

スカウトパート及びミッションパートには、それぞれ後述するチーム代表戦や制覇戦が含まれており、これらの対戦が選手カード（キャラクタ）の能力を示すパラメータ（キャラクタデータ）に基づいて行われる。つまり、スカウトパート及びミッションパートはそれぞれ、ユーザによる操作対象となる選手カード（キャラクタ）の能力に基づいてゲームを進行させる第２のパートの例である。
スカウトパートは、後述するように、行動ポイントを消費してプレイが進行する。行動ポイントが所定値以下になった場合には、ユーザはプレイできず、時間が経過して行動ポイントが回復するまで待機する必要がある。つまり、スカウトパートは、ポイントが所定値以下になった場合にゲームの進行が抑制されるパートの一例である。

図７に示したように、ゲーム進行手段５２は、表示手段５２１、スカウト実行手段５２２、強化実行手段５２３、試合実行手段５２４、抽選実行手段５２５、ミッション実行手段５２６、判定手段５２７、及び、変更手段５２８を含む。スカウト実行手段５２２、強化実行手段５２３、試合実行手段５２４、抽選実行手段５２５、及びミッション実行手段５２６はそれぞれ、ゲームにおいて、スカウトパート、強化パート、試合パート、抽選パート、及びミッションパートを実行する。
なお、ゲーム進行手段５２を実行するに当たり、ゲームサーバ２０のＣＰＵ２１は、ウェブページ上に表示される各メニューに、ゲームを進行させるためのいずれかのパートを予め割り当てている。そして、ＣＰＵ２１は、通信端末１０においてウェブページ上のメニューが選択されたときに、選択されたメニューについての情報を通信端末１０から受信し、受信した情報に基づいて、選択されたメニューに割り当てられたパートを実行する。

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

表示手段５２１によって通信端末１０に表示されるゲームのトップページの例を図８に示す。このトップページは、個々のユーザＩＤに応じたウェブページで構成される。図８に例示されるトップページは、ユーザデータ表示領域、選手画像表示領域、メニュー表示領域を含む。
ユーザデータ表示領域は、対象となるユーザＩＤのユーザデータに含まれる、技能レベル、行動ポイント、運営ポイント、強化ポイント、エールポイント、選手数、仲間の各項目のデータ（図６参照）が表示される領域である。なお、ユーザデータ表示領域に表示される項目で、Ｘ／Ｙの形式で表記されているポイントまたは数は、Ｘがユーザの保有するポイントまたは数であり、Ｙがそのポイントまたは数の最大値であることを示す。例えば、選手数が「４０／６０」と表記されていれば、ユーザが保有する選手カードが４０枚であり、最大で保有可能な選手カードの枚数が６０枚であることを示す。
選手画像表示領域は、対象となるユーザＩＤのユーザデータに含まれる複数の選手カードのうちユーザによって予め指定された選手カードの画像が表示される領域である。
メニュー表示領域は、サッカー形式のデジタルカードゲームに設けられる複数のパート（スカウトパート、強化パート、試合パート、抽選パート、フォーメーションパート、ミッションパート）に対応した基本メニューとして、「スカウト」、「強化」、「試合」、「抽選」、「フォーメーション」、「ミッション」の各メニューｍ１〜ｍ６が表示される領域である。つまり、ゲームで実行される複数のパートが各々割り当てられた複数のメニューが、通信端末１０に表示されるウェブページの所定の位置にそれぞれ配置される。なお、メニューｍ５に対応するフォーメーションパートは、ユーザの操作に応じて選手キャラクタによるチームのフォーメーションの入れ替え、選手キャラクタのポジションの変更等を行うパートである。

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

スカウト実行手段５２２、強化実行手段５２３、試合実行手段５２４、抽選実行手段５２５、及びミッション実行手段５２６は、通信端末１０に表示されたメニューに対するユーザの選択操作に応じて、それぞれスカウトパート、強化パート、試合パート、抽選パート、及びミッションパートの各パートの実行を開始する。つまり、複数のメニューのいずれかを選択操作することによって、ゲームを構成する各パートの実行が開始される。好ましくは、各パートの実行が開始された場合、パートごとに階層的に細分化された複数のメニューを含むようにしてウェブページが更新されつつ各パートが実行される。

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

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

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

エリア代表戦では、ユーザは、そのエリアの代表チームとして予めゲームサーバ２０で設定されているチーム（特定のユーザのチームではない仮想的なチーム）と対戦する。エリア代表戦での対戦チームは、エリアが進むにつれて能力が高いパラメータが設定されていることが好ましい。エリア代表戦における対戦の勝敗の決定方法は、後述する試合パートと同様に設定されてよい。つまり、ユーザの選手カードのパラメータがその勝敗に影響を与える方法である限り如何なる方法を採ることができる。例えば、対戦するチーム間で複数の選手カードのパラメータの合計値を比較し、合計値が大きな方のチームが高い確率（例えば、６０〜９０％の範囲内の所定の確率）をもって勝利するように設定してよい。すなわち、エリア代表戦では、ユーザが保有する選手カードのパラメータが大きいほどユーザに有利となっている。

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

図１０に示すように、スカウトパートでは、ユーザによるメニューｍ１１の選択操作によって、ユーザが既にプレイした（つまり、探索した）各エリアの探索結果が概観できるウェブページが表示される。表示領域１１０では、エリアごとの「コンプリート率」が表示される。「コンプリート率」（達成度）は、各エリアにおいて発掘可能な種類の選手カードの最大数に対して、実際に発掘した種類の選手カードの数の比率を％表示した値である。例えば、図９に示した例において、エリア９がエリア９−１，９−２，９−３の３つのサブエリアからなる場合、各サブエリアで最大４枚の選手カードを発掘可能であるとすると、エリア９全体で１２枚の選手カードが発掘可能となる。このとき、発掘された選手の数がエリア９全体で６人の場合には、コンプリート率は５０％となる。
図１０に示す例では、ユーザがゲームのスカウトパートにおいて、エリア９が最も進行したエリアであることを示している。なお、図１０では、ユーザは、既にプレイ済みの他のエリア（エリア１〜８）の中でコンプリート率が１００％でないエリアを選択操作することで、選択したエリアの探索を再び行うことができるように構成されている。

［強化パート］
前述したように、強化実行手段５２３は、２枚以上の選手カードを一体化して特定の選手カードの能力を上昇させる強化パートを実行する機能を有する。このゲームでは、ユーザが強化パートを実行するには一定量の強化ポイントが必要となる。
この一体化の処理は、例えば以下のように行われてよい。強化対象となる選手カード（ユーザによって指定された、残留する選手カード）を選手Ａの選手カードとし、選手Ａの選手カードに一体化させられて消失する選手カードを選手Ｂの選手カードとする。この場合、一体化の処理では、ＣＰＵ２１が選手Ａの選手カードのオフェンス、ディフェンス、テクニックの能力値を示すパラメータに対して、選手Ｂの選手カードのオフェンス、ディフェンス、テクニックの能力値を示すパラメータの一定比率をそれぞれ加算することで、新たな選手Ａの選手カードのパラメータを算出するようにしてもよい。この一体化の処理によって、選手Ｂの選手カードの能力上の特徴が選手Ａの選手カードに反映されることになる。
一体化の処理後には、ＣＰＵ２１は、一体化の処理の後にユーザデータベース３１にアクセスし、対象となるユーザＩＤのユーザデータから選手Ｂの選手カードのデータを削除し、選手数の値を１だけ減少させ、選手Ａの選手カードのパラメータを書き換え、対象となるユーザＩＤの強化ポイントを所定量減少させる。なお、強化ポイントは、上記スカウトパートを実行したり、以下に説明する試合パートを実行したりすることによって増加する。

上記選手キャラクタの一体化処理についての通信端末１０における表示例について図１１Ａ及び図１１Ｂを参照して説明する。図１１Ａ及び図１１Ｂは、通信端末１０に対する操作に応じて一連に表示される表示例である。
ゲームサーバ２０のＣＰＵ２１は、例えば図８のウェブページ上でメニューｍ２が選択されたことを認識すると、一体化の対象となる複数の選手カードの選択を促すウェブページを表示するためのＨＴＭＬデータを通信端末１０宛に送信する。このとき最初に表示されるウェブページの一例は、図１１Ａ（ａ）に示すように、強化指定選手（強化対象となる選手カードに対応する選手キャラクタ）の一覧であり、選択操作によって強化指定選手を選択できるように構成されている。強化指定選手が選択されると次に、図１１Ａ（ｂ）に示すように、一体化させる選手（消失する選手カードに対応する選手キャラクタ）の一覧が表示される。図１１Ａに示す各ウェブページは、選択操作によっていずれかの選手を選択できるように構成されている。図１１Ｂ（ａ）は確認用画面であり、例えば強化指定選手として選手Ａ、一体化させる選手として選手Ｂが選択された例が示されている。ここで、「強化する」というメニューを選択する操作が行われると、その選択結果がゲームサーバ２０へ通知される。ゲームサーバ２０のＣＰＵ２１は、受信した選択結果に基づいて、選手Ａの選手カードの新たな能力値を示すパラメータを算出するとともに、ユーザデータベース３１にアクセスして、選手Ｂの選手カードのデータを、対象となるユーザＩＤのデータから削除する。ＣＰＵ２１は、新たなパラメータの増加度合いを示す値を含むＨＴＭＬデータを通信端末１０宛に送信する。このＨＴＭＬデータの受信により、通信端末１０は、図１１Ｂ（ｂ）及び図１１Ｂ（ｃ）に示すように、選択された選手Ａの選手カードと選手Ｂの選手カードが重なり合い、合体して選手Ａの選手カードのみが表示されるような演出表示を行う。図１１Ｂ（ｃ）に示すように、強化対象の選手Ａの選手カードの能力値の増加度合い（図１１Ｂ（ｃ）の例では、１３２％）を定量的に表示することが好ましい。

［試合パート］
前述したように、試合実行手段５２４は、他のユーザのチームとサッカーの対戦を行う試合パートを実行する機能を有する。
このゲームでは、試合パートを実行するには運営ポイントを必要とし、試合に勝利することで強化ポイントを得ることができる。つまり、試合パートの実行によって、ユーザＩＤに対応する運営ポイント、強化ポイントの値が変化しうる。１回の試合で必要となる（消費する）運営ポイントは、ユーザのチームで組まれるフォーメーションによって定まる値である。ユーザは、ユーザが保有する選手カードの中から試合に出場させたい選手カードをフォーメーションパートによって組み替えることができるが、試合に出場させたい所定数の選手カードによって、運営ポイントの消費量が決定される。例えば、選手カードごとに１回の試合で必要となるコストが予め割り当てられており、試合に出場させたい所定数の選手のコストの合計が運営ポイントとなる。運営ポイントは、例えば所定時間（例えば1分）が経過する度に１ポイントずつ回復（増加）する。

試合実行手段５２４は、図１２〜１４を参照すると、例えば以下のとおり実現される。図１２は、試合実行手段５２４の機能を実現するために、主としてゲームサーバ２０のＣＰＵ２１によって実行される一連の処理を示すフローチャートである。図１３は、ユーザが試合に勝利することで、その後の所定期間又は所定回数分のプレイだけそのユーザが有利となるように管理するためのＦＬＡＧ（フラグ）の管理データの例を示す図である。図１３に示す管理データは、例えばゲームデータベース３２にて記録・更新されるデータであってよい。各ユーザに対してＦＬＡＧのデフォルト値は「０」に設定されている。図１４は、試合実行手段５２４の機能により実現される、ユーザの通信端末１０上に表示されるウェブページの例を示す図である。

あるユーザＩＤに対応するユーザの通信端末１０のトップページ上でメニューｍ３（図８参照）の選択操作がなされ、その選択結果を受信すると、ゲームサーバ２０のＣＰＵ２１は、そのユーザＩＤの対戦相手の複数の候補を、ユーザデータベース３１に含まれる他のユーザＩＤの中からランダムに決定する。このとき、対戦するユーザの候補の技能レベルは、メニューｍ３を選択操作したユーザと同一の技能レベルであることが好ましい。ＣＰＵ２１は、複数の対戦相手の候補のリストからいずれかの候補を選択可能とするウェブページを表示するためのＨＴＭＬデータをユーザの通信端末１０宛に送信する（ステップＳ１０）。複数の対戦相手の候補のリストからいずれかの候補を選択する操作がユーザによってなされると（ステップＳ２０：ＹＥＳ）、図１４（ａ）に示すように、対戦相手ととともに試合開始の指示を促すメニューを含むウェブページが表示される。図１４（ａ）にはまた、試合の実行後の運営ポイントの予定値（図では、７ポイント）が表示される。ここで、ユーザが「試合開始」のメニューを選択すると（ステップＳ３０：ＹＥＳ）、ＣＰＵ２１は対戦結果を決定する処理行う。対戦結果を決定するに当たって、ＣＰＵ２１は、データベースアクセス部２４を介してデータベースサーバ３０のユーザデータベース３１にアクセスし、対象となるユーザＩＤの運営ポイントが試合の実行に必要とする所定量以上である場合に、運営ポイントからその所定量を減少させるとともに、対戦相手となる２つのユーザＩＤに対応付けられた複数の選手カードの能力を示すパラメータを読み出す。そして、ＣＰＵ２１は、読み出したパラメータに基づいてユーザ間の対戦結果を決定する（ステップＳ４０）。例えば図１４（ｂ）では、例えばスコア等を含む試合結果が表示されるウェブページを示す。

対戦の勝敗の決定方法は、選手カードのパラメータがその勝敗に影響を与える方法である限り如何なる方法を採ることができる。例えば、対戦相手となる２人のユーザが保有する複数の選手カードのパラメータの合計値を比較し、合計値が大きな方のユーザが高い確率（例えば、６０〜９０％の範囲内の所定の確率）をもって勝利するように設定してよい。この勝率は、パラメータの合計値の差が大きいほど高い確率としてもよい。このとき、図６に示したように、能力値を示すパラメータの項目が複数存在する場合には、各選手カードのパラメータを代表する値として、各項目のパラメータの値に対して所定の重み付け（例えば、図６の例では、「オフェンス」を０．３、「ディフェンス」を０．３、「テクニック」を０．４の重み付けにする等）をもって総合的な能力値を算出してもよい。

ＣＰＵ２１は、ユーザがメニューｍ３を選択操作したことを契機とした試合において、そのユーザが勝利したことを決定した場合には（ステップＳ５０：ＹＥＳ）、管理データにアクセスして、そのユーザに対応するユーザＩＤのＦＬＡＧの値を「０」から「１」に変更するとともに（ステップＳ６０）、ＦＬＡＧの値が「１」である有効期間（所定期間又は所定回数のプレイを規定する期間）についてのデータを書き込む（ステップＳ７０）。なお、後述するように、ＦＬＡＧの値が「１」である有効期間の間、ユーザが有利となるように、試合パートとは別のパートにおいて難易度が変更される。

以下では、一例として、難易度の変更の対象となる他のパートがミッションパートである場合について説明する。ＦＬＡＧの有効期間は、所定期間又は所定回数分のプレイだけに限定することが好ましい。これは、仮にＦＬＡＧに有効期間を設定せずに無期限でユーザに有利となるようにした場合、例えば、他のユーザと対戦で勝利したユーザが得る利益が、他のユーザと対戦を行わなかったユーザよりも大きくなり過ぎて、ゲームの設定上バランスを欠くと考えられるためである。また、ＦＬＡＧの有効期間を無期限にしてしまうと、ユーザが試合パートを継続的に実行しない状況が考えられ、そのような状況を回避することが好ましい。ＣＰＵ２１は、ＦＬＡＧの有効期間が経過するとＦＬＡＧの値を「０」に設定する。
有効期間は任意に設定できるが、図１３に挙げた例では、有効期間は特定の日付（例えば、「2011.12.10まで」等」、あるいは、「ユーザが現在プレイ中のエリアが終了するまで」等とすることができる。

ＣＰＵ２１は、対戦相手となる２つのユーザＩＤに対応付けられた選手キャラクタの対戦の対戦結果を決定すると、その対戦結果を含むウェブページを表示させるためのＨＴＭＬデータを、対戦相手の２つのユーザＩＤのユーザの通信端末１０宛に送信する（ステップＳ８０）。そして、通信端末１０は、ゲームサーバ２０から受信したＨＴＭＬデータを解釈し、図１４（ｂ）に例示するように、対戦結果を含むウェブページを表示部１６に表示する。このとき、ウェブページには、メニューｍ３を選択操作したユーザの勝利によって、そのユーザに与えられた、他のパートにおける有利な内容を示すテキストが含まれることが好ましい。対戦結果を決定した後、ＣＰＵ２１は、データベースアクセス部２４を介して、対戦結果の詳細をゲームデータベース３２に書き込む処理を行う。
図８に例示するトップページ上でユーザがメニューｍ３を選択する操作が行われてから、対戦結果を含むウェブページが表示されるまでの時間は極めて短時間（例えば数秒）であるため、ユーザは、簡易な操作のみで極めて短期間で対戦結果を知ることができる。試合に勝利すれば、ユーザは一定量の強化ポイントを得ることができる。

本実施形態において、判定手段５２７は、ゲームに設けられる複数のパートのうち試合パート（第１のパートの一例）におけるゲームの進行状況が所定の条件を満たすか否かを判定する機能を備える。この機能は、例えば、図１２において、ＣＰＵ２１がステップＳ５０にて対戦結果についての判定を行うことによって実現される。この場合、ゲームの進行状況における所定の条件の一例は、メニューｍ３の選択操作を行ったユーザが他のユーザに対して勝利することである。

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

このゲームでは、ユーザは自らの仲間を登録することができるようになっている。登録可能な仲間の数の最大値は予め決定しておいてもよい。仲間のユーザ間では、メッセージの交換、ゲーム上のアイテムのプレゼントあるいはアイテムの交換、仲間にエールを送る（応援する）等、ネットワーク上の交流を図ることを可能とするネットワークサービスが提供される。ユーザは、仲間にエールを送ることで一定量のエールポイントを得ることができ、所定量のエールポイントと引き換えに選手カードを引く「エールポイントによる抽選」を、無料抽選として行うことができる。

図１５は、通信端末１０に表示されるウェブページ上のメニューｍ４（図８参照）が選択操作されたときに表示され、エールポイントによる抽選の実行をユーザに促すウェブページの表示例である。図１３に示すウェブページでは、ユーザが所持するエールポイント（所持エールポイント）と、この抽選１回に必要なエールポイントとが表示される。図１３のページにおいて、「抽選する」と表記されたメニューを選択操作することで抽選処理が実行される。抽選処理は、様々な方法を採りうる。例えば、抽選対象となる複数の選手カードから抽選の都度、ランダムに１つの選手カードを選択する方法を採ることができる。この方法では実質的に、各選手カードが選択される確率（出現確率）は同一である。また、抽選対象となる複数の選手カードの各々についてそれぞれ出現確率、あるいは出現確率の範囲を予め決めておき、その出現確率に従って１つの選手カードを選択する方法を採ることができる。

抽選実行手段５２５では、以下の処理が行われる。ゲームサーバ２０のＣＰＵ２１は、エールポイントによる抽選用に予め設けられた複数の選手カードの中から抽選処理を行って選手カードを決定する。ＣＰＵ２１は、ユーザデータベース３１にアクセスし、対象となるユーザＩＤのエールポイントを所定量減少させる。さらにＣＰＵ２１は、抽選により選手カードを引いた場合には、対象となるユーザＩＤのデータから、抽選で引いた選手カードのデータを追加して、選手数の値を１だけ増加させる。

［ミッションパート］
前述したように、ミッション実行手段５２６は、各ユーザの通信端末１０に対する操作に応じて、各ユーザが自らのチームで日本全国の都道府県内の他のユーザのチームと順に対戦して制覇していくミッションパートを実行する機能を有する。
以下、ミッションパートによって実現されるプレイ内容について、図１６〜１８を参照して説明する。図１６〜１８は、ミッションパートによって実現されるプレイ内容を示すウェブページの例を示している。先ず、図８のトップページにおいてメニューｍ６が選択操作されると、図１６のステップＳ１に示すように、日本全国の都道府県の各々を区画して表示する表示領域１９０と、プレイの対象となるエリアをユーザに選択させるための表示領域１９１とが表示される。表示領域１９１には、プレイの対象となるエリアをプルダウン方式にて選択操作するためのメニューｍ１５と、選択結果を確定させるためのメニューｍ１６とが含まれる。ここで、メニューｍ１５によっていずれかのエリア（都道府県のいずれか；図１４のステップＳ２では、一例として「北海道」）を指定した上でメニューｍ１６が選択操作されると、その指定されたエリアのプレイが開始される。
なお、日本全国の複数のエリアは、ミッションパートのプレイを構成する複数のステージの一例である。

ミッションパートにおけるプレイ内容は、トレーニングモードと制覇戦とを含む。
トレーニングモードにおけるプレイの流れを図１７に示す。図１７に示すように、トレーニングモードでは、ステップＳ３〜Ｓ７の練習ステージ（ランニング、パスワーク練習、フォーメーション練習、シュート練習、練習試合）のプレイが行われる。各練習ステージでは、メニューｍ２０の選択操作が行われる度に、スカウトパートの探索処理における探索率と同様に、各ステージのウェブページに含まれる練習量を示すゲージ２０１〜２０５がランダムな伸び量で伸びる。メニューｍ２０の選択操作がなされる度に、一定量の行動ポイントが消費されるように構成されてもよい。ゲージ２０１〜２０４の各々が右端（１００％）に達すると、次の練習ステージに移行する。ステップＳ７に示す練習試合のステージが終了すると、制覇戦に進む。ユーザは、制覇戦において、ランダムに選択された他のユーザとの試合を行う。その試合で勝利した場合には、ユーザがステップＳ２で指定したエリアを制覇したと判断される。制覇戦の対戦相手となる他のユーザは、例えば同一の技能レベルの中から任意に選択してもよいが、ユーザの登録時に予めユーザが自身のエリアを登録している場合には、図１６においてユーザが選択したエリアと同じエリアを登録している他のユーザの中から同一技能レベルのユーザを選択してもよい。制覇戦の対戦方法は、上述した試合パートにおける対戦と同様の方法でよい。
図１８は、ユーザが特定のエリア（図１８では、北海道）において制覇戦で勝利した場合に、通信端末１０に表示されるウェブページの一例を示す図である。図１８に示すように、画像領域１９０では、制覇したエリアに、制覇したことを示すマーク（例えば旗のマーク）を表示するようにしてもよい。

以上、ゲーム進行手段５２の主要な機能について説明した。
上述したように、このゲームでは、図８のユーザデータ表示領域に表示される行動ポイント、運営ポイント、強化ポイント、エールポイント、及び選手数は、スカウトパート、強化パート、試合パート、抽選パート、及びミッションパートの各パートの実行によって変動しうるものとなっている。
ゲーム進行手段５２はさらに、ユーザが保持する各ポイントあるいは選手数に基づいて、ユーザによって選択されたメニューに応じたパートが実行できるか否かを判定し、選択されたメニューに応じたパートが実行できない場合には、選択されたパートが実行できないことをユーザに報知するためのテキストを含むページを通信端末１０上に表示する。例えば、１回の探索処理に行動ポイントが「５」必要となるエリアについてスカウトパートを実行しようとする場合に、ユーザの行動ポイントが「３」のときには、スカウトパートが実行できないため、例えば「行動ポイントが足りません。行動ポイントは３分ごとに１回復します。ゆっくり待ちましょう。」などといったテキストを表示させる。このとき、ゲームサーバ２０のＣＰＵ２１は、ユーザデータベース３１にアクセスして、ユーザの行動ポイントのデータと、探索対象のエリアに要する行動ポイント（既定値）との比較処理を行って、スカウトパートの実行可否を判定する。
ゲーム進行手段５２において、例えば、時間の経過に応じて行動ポイントを増加させるときには、ＣＰＵ２１が内蔵するタイマを動作させ、所定時間（例えば３分）が経過すると、ユーザデータベース３１にアクセスして、行動ポイントの値をインクリメントする。なお、スカウトパート、強化パート、試合パート、抽選パート、及びミッションパートの実行に応じたポイントの増加量及び／又は減少量（消費量）は既定値であるが、その値は、ユーザのゲーム内の状況（例えばユーザのゲーム上の技能レベル）によって異なってよい。

変更手段５２８は、所定の条件を満たした場合に、ゲームを構成する複数のパートのうち第１のパート（本実施形態では、試合パート）とは異なる第２のパート（本実施形態では、ミッションパート）において、所定期間又は所定回数分のプレイだけ、ユーザが有利になるように第２のパートのゲームの難易度を変更する機能を備える。
変更手段５２８の機能は、以下のとおり実現される。ゲームサーバ２０のＣＰＵ２１は、管理データを参照し、対象となるユーザＩＤのＦＬＡＧの値が「１」である場合には、指定されている有効期間（つまり、所定期間又は所定回数分のプレイの間）の間、ユーザが有利となるようにミッションパートにおけるゲームの難易度を変更する処理を行う。ゲームの難易度を変更する処理は、ゲームの性質によって様々な方法を採りうるが、例えば本実施形態のゲームの場合には、対戦時においてユーザを有利とするため、そのユーザが保有する選手カードのパラメータの値を増加させる、または、そのユーザの対戦相手（他のユーザ、またはＣＰＵ２１が用意する仮想的な対戦相手）の保有する選手カードのパラメータの値を対戦中だけ低下させることであってよい。

（６）本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、図１９のフローチャートを参照して説明する。図１９に示す処理はユーザＩＤごとに行われる。

先ず、ユーザがゲームを開始すると、図８に示すトップページがユーザの通信端末１０に表示される。このトップページには、ゲーム内において、プレイ対象となる複数のパートの各々の実行を開始するために設けられた複数のメニューｍ１〜ｍ６が設けられている。このトップページにおいて、ユーザによって選択操作されたメニューがメニューｍ１〜ｍ５の場合には（ステップＳ１００）、ゲーム進行手段５２は、それぞれスカウトパート、強化パート、試合パート、抽選パート、及びフォーメーションパートの各パートの実行を開始する（ステップＳ１１０〜Ｓ１５０）。ここで、ステップＳ１３０の詳細な処理は、図１２に示したとおりである。つまり、メニューｍ３の選択操作を行ったユーザが他のユーザとの対戦に勝利することで、所定の有効期間の間、対象となるユーザＩＤの管理データにおけるＦＬＡＧの値が「１」に設定される。

トップページにおいて、ユーザによって選択操作されたメニューがメニューｍ６の場合には（ステップＳ１００）、ゲーム進行手段５２は、先ずＦＬＡＧが「１」であるか否か判定する（ステップＳ１６０）。ＦＬＡＧが「１」である場合には、ユーザに有利となるように、そのユーザが保有する選手カードのパラメータをすべて所定数（例えば、５００）だけ増加させる（ステップＳ１７０）。ＦＬＡＧが「０」である場合には、そのユーザが保有する選手カードのパラメータの変更は行われない。その後、ミッションパートの実行が行われる（ステップＳ１８０）。ミッションパートにおけるプレイ内容は、前述したように、トレーニングモードと制覇戦とが含まれる。制覇戦では、ランダムに選択された他のユーザとの試合が行われるが、ＦＬＡＧが「１」である場合には、ユーザが保有する選手カードのパラメータが増加しているため、ＦＬＡＧが「０」である場合と比較して、制覇戦ではそのユーザが有利となるように難易度が変更される。

上述したように、本実施形態によれば、ユーザが試合パート（第１のパート）を実行して他のユーザとの対戦で勝利することで、ミッションパート（第２のパート）において、所定期間又は所定回数分のプレイだけユーザが有利になるように第２のパートのゲームの難易度が変更される。そのため、ミッションパートのプレイにおいて有利にゲームを進行させて良好な結果を得る目的で、積極的に試合パートのプレイを行うようにユーザを動機付けることが可能となる。
上述した動機付けは、仮に上述したミッションパート（第２のパート）の難易度の変更を行わないときに試合パート（第１のパート）がユーザに積極的にプレイされない場合に、特に有効である。例えば、上述した野球形式のデジタルカードゲームの場合、ユーザは他のユーザと対戦して勝利することで強化ポイントを得ることができるが、強化ポイントを得る他の方法がゲーム上で設けられている場合（例えば選手カードの売却によって強化ポイントが得られるように設定されている場合等）には、他のユーザとの試合を行わなくても自らのチームを強くすることができるため、積極的に他のユーザとの対戦を行わない状況が考えられる。このような状況は、他のユーザとの対戦の興趣性をユーザが味わえないか、あるいは対戦によるユーザ間のゲーム上での交流を阻害しうるものであり、好ましい状況ではない。そこで、本実施形態では、ユーザが試合パート（第１のパート）を実行して所定の条件を満足させることによって、試合パート以外の他のパート（第２のパート）を実行するときの難易度を低下させるように構成し、ユーザが試合パートをより積極的にプレイする動機付けを行っている。

本実施形態において、判定手段５２７における所定の条件は、図１２のステップＳ５０に示したように、他のユーザとの対戦で勝利することであるが、所定の条件はこれに限られず、適宜設定されうるものである。例えば、他のユーザとの対戦の勝敗とは無関係に、試合が終了したことをもって所定の条件を満たしたと判断することもできる。

本実施形態では、ＦＬＡＧが「１」に設定されている期間（つまり、ゲームの難易度がユーザに有利となるように変更される期間）は、判定手段５２７における所定の条件を満たした後、図１３に示した管理データに記述されている有効期間（所定期間又は所定回数のプレイを規定する期間）に限定される。このとき、有効期間は、例えばスカウトパートやミッションパートにおいてユーザが現在プレイ中のエリアが終了するまでの期間に設定してもよい。これにより、ユーザは、プレイ中のエリアを終了した後、次のステージで再度ゲームの難易度を低くする目的で、試合パートを実行することが動機付けられる。
なお、本実施形態では、ユーザが試合に勝利した場合（つまり、第１のパートのゲームの進行状況における所定の条件を満たした場合）に、そのユーザに対応するユーザＩＤのＦＬＡＧの値が「０」から「１」に変更され、直ちにミッションパート（第２のパート）が有利となる有効期間が開始する場合について説明したが、この場合に限られない。このような有効期間の開始タイミングは、ＦＬＡＧの値が「１」に変更された後のユーザの操作入力によって決定できるようにしてもよい。

（７）変形例
以下、上述した実施形態についての変形例について説明する。
（７−１）変形例１
上述した実施形態において、ＦＬＡＧが「１」である期間におけるゲームの難易度の変更態様は、適宜設定することができる。例えば、図１９のフローチャートのステップＳ１７０では、ユーザが保有する選手カードのパラメータをすべて所定数（例えば、５００）だけ増加させるようにしたが、これに限られない。ステップＳ１７０では代替的に、ユーザが保有する選手カードのパラメータをすべて所定数だけ増加させる確率を高めることでもよい。例えば、ミッションパートにおいて、ユーザが保有する選手カードのパラメータを一定の確率で上昇させるように設定されている場合に、図１９のステップＳ１７０では、その確率を増加させるようにする。選手カードのパラメータを増加させる確率を高めることであっても、第２のパートとしてのミッションパートにおけるゲームを進行させやすくなる可能性が高くなる、という利益が得られうる。ユーザはその利益を得るために、試合パートを積極的に実行することが動機付けられる。この場合、ステップＳ１６０でＦＬＡＧが「１」である場合には、ゲームサーバ２０のＣＰＵ２１は、例えば所定の確率、あるいはランダムな確率で選手カードのパラメータが増加するか否かを決定する処理を行い、パラメータを増加することを決定した場合にステップＳ１７０へ進むようにする。
また、パラメータが増加、又はパラメータが増加する確率が高まる選手カードは、全ての選手カードではなく、所定の選手カード、または、ランダムに選択された選手カードでも良い。このようにすることで、ゲームにおける第１のパートを行う度に第２のパートで生じる有利な効果が異なるためによりゲームの興趣性を向上させることができる。

（７−２）変形例２
第１のパート及び第２のパートは、ゲームが複数のパートから構成される場合に、ゲームの性質に応じて適宜設定されうるものである。上述した実施形態では、第１のパートが試合パートに対応し、第２のパートがミッションパートに対応する場合について説明したが、これに限られない。例えば、上述したデジタルカードゲームの場合、第１のパートが試合パートに対応し、第２のパートがスカウトパートに対応してもよい。この場合、ユーザは、試合パートにおいて他のユーザに勝利することで、スカウトパートでユーザがプレイしているエリアのエリア代表戦において、選手カードのパラメータが増加し、それによってスカウトパートにおいてゲームの難易度が低下するように構成してもよい。

なお、第１のパート及び第２のパートの設定は、ユーザ毎に行われてもよい。例えば、上述した実施形態において、ゲーム進行手段５２は、複数のパートの各々に対するユーザ毎の実行回数を計数し、実行回数が相対的に少ないパートを第１のパートとし、実行回数が相対的に多いパートを第２のパートとしてもよい。より好ましくは、ゲーム進行手段５２は、実行回数が最も少ないパートを第１のパートとし、実行回数が最も多いパートを第２のパートとする。このようにすることで、ユーザ毎に、ユーザにとって興味が低いと考えられる実行回数の低いパートを行うことで、ユーザにとって興味が高いと考えられる実行回数の多いパートにおいて有利な効果を得ることができるために、興味が低いパートの実行をユーザに促すことができる。上記ゲーム進行手段５２の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、ユーザ毎に各パートに対応するトップページ上の各メニューの選択操作の回数を計数するカウンタを動作させ、カウンタの値に応じてユーザ毎に第１のパートと第２のパートを動的に設定する。このとき、各パートにおいて、ゲームの進行状況における所定の条件と、ユーザが有利になるゲームの難易度の変更内容とを予めＲＯＭ２２等の記憶手段に記憶しておき、ＣＰＵ２１は、第１のパートと第２のパートの設定結果に応じてＲＯＭ２２から読み出すようにする。

ゲーム進行手段５２は、複数のパートの各々に対するユーザ毎の実行時間を計数し、実行時間が相対的に短いパートを第１のパートとし、実行時間が相対的に長いパートを第２のパートとしてもよい。より好ましくは、ゲーム進行手段５２は、実行時間が最も短いパートを第１のパートとし、実行時間が最も長いパートを第２のパートとする。このようにすることでも同様に、興味が低いパートの実行をユーザに促すことができる。ＣＰＵ２１は、実行時間を計測するために、ユーザ毎に各パートのメニュー（例えば、スカウトパートの場合には、メニューｍ１，ｍ１０，ｍ１１）の操作時刻をＲＡＭ２３に記憶させ、メニューが最初に操作された時刻からタイマを動作させ、最後に操作された時刻との間の時間におけるタイマの値を実行時間として算出する。このとき、所定時間継続して操作が行われない場合には、対象となるメニューを実行していない可能性が高いと判断して、タイマをリセットしてもよい。
なお、上述したゲームがオンラインゲームとしてユーザに提供される場合には、各パートの実行回数よりも実行時間で計測する方がより適切な計測値が得られると考えられる。

また、ゲーム上で複数のユーザがチームあるいはグループを形成している場合には、チームあるいはグループ内の複数のユーザの各パートの実行回数又は実行時間の統計値（例えば、平均値や合計値等）に基づいて、そのチームあるいはグループについての第１のパート及び第２のパートを決定してもよい。ゲームに参加している全ユーザについての各パートの実行回数又は実行時間の統計値（例えば、平均値や合計値等）に基づいて、ユーザ全体についての第１のパート及び第２のパートを決定してもよい。これらの場合、ＣＰＵ２１は、ユーザ毎に測定した実行回数又は実行時間を、チームあるいはグループ単位で、又はユーザ全体で累積し、その累積値に基づいて、第１のパート及び第２のパートを特定する。

ゲーム進行手段５２は、複数のパートの各々に対するユーザの実行状況に基づいて、複数のパートの中から第１のパートと第２のパートを決定してもよい。つまり、第１のパートと第２のパートの特定は、各パートの実行回数又は実行時間に限られない。各パートの実行時間、実行回数以外のユーザによるパートの実行状況に関する情報は、例えば、各パートの実行頻度（所定期間毎の実行時間又は実行回数）、最終実行時刻（例えば、最終ログイン又はログアウト時刻）から現在時刻までの経過時間等であってもよい。つまり、ユーザの実行状況は、そのユーザが複数のパートの中で特定のパートを頻繁に実行しているか否か（つまり、特定のパートをプレイすることに興味が高いか低いか）を判別可能となる情報であれば如何なる情報であってもよい。例えば、ユーザにとって興味が低いと考えられるパートを第１のパートとし、ユーザにとって興味が高いと考えられるパートを第２のパートとして決定してもよい。これにより、ユーザにとって興味が低いと考えられる第１のパートを行うことで、ユーザにとって興味が高いと思われる第２のパートにおいて有利な効果を得ることができるために、興味が低い第１のパートの実行をユーザに促すことができる。これにより、各パートをバランス良くユーザに実行させる仕組みを構築することができる。
また逆に、ユーザにとって興味が高いと考えられるパートを第１のパートとし、ユーザにとって興味が低いと考えられるパートを第２のパートとして決定してもよい。第１のパートをさらに頻繁に実行して所定の条件を満たすことで、例えば第２のパートで利用可能な強力なアイテム等が入手できれば、そのアイテムを使って普段あまりプレイしていない第２のパートもプレイしてみようという動機付けになる。
複数のパートの各々に対するユーザの実行状況に関する情報を得るために、ゲームサーバ２０のＣＰＵ２１は、ログイン時刻やログアウト時刻を逐次、ユーザデータに記録しておき、あるいは、各パートについての所定期間（例えば１週間）内の実行時間又は実行回数を計数することによって実行頻度を算出する。このような実行状況に関する各パートのデータに対して、第１のパート又は第２のパートを決定するために、予め所定の閾値が設定される。

（７−３）変形例３
実施形態のゲーム制御装置において、変更手段５２８は、第１のパート、及び／又は、第２のパートの実行状況に基づいて、第２のパートにおいてユーザが有利となる所定期間、又は所定回数を変更してもよい。第１のパート、及び／又は、第２のパートの実行状況に関する情報は、上述したように、各パートの実行時間、実行回数のほか、例えば、各パートの実行頻度、最終実行時刻から現在時刻までの経過時間等であってもよい。
例えば、実行回数が相対的に少ない、又は実行時間が相対的に短いパートを第１のパートとし、実行回数が相対的に多い、又は実行時間が相対的に長いパートを第２のパートとする場合、第１のパートの実行回数が相対的に少ないほど、又は実行時間が相対的に短いほど、第２のパートにおいて難易度が低下する所定期間が長く、又は所定回数が多くなり、第２のパートで受ける利益が増大する。これにより、第１のパートを実行しようとする動機付けがより強くなり、各パートをバランス良くユーザに実行させる仕組みを構築することができる。
なお、第１のパートと第２のパートの実行回数の差が相対的に大きいほど、又は実行時間の差が相対的に大きいほど、第２のパートにおいて難易度が低下する所定期間を長く、又は所定回数を多くしても同様の効果が得られる。
本変形例を実現するために、ゲームサーバ２０のＣＰＵ２１は、第１のパート、及び／又は、第２のパートの実行状況に関する情報を取得する。例えば、実行状況に関する情報を実行回数とした場合、ＣＰＵ２１は、第１のパートの実行回数、若しくは第１のパートと第２のパートの実行回数の差に基づいて、第２のパートにおいてユーザが有利となる所定期間、又は所定回数を決定する。決定方法は、第１のパートの実行回数が少ないほど、あるいは第１のパートと第２のパートの実行回数の差が大きいほど、第２のパートにおいてユーザが有利となる所定期間をより長く、又は所定回数をより大きくする限り、如何なる方法であってもよい。

（７−４）変形例４
実施形態のゲーム制御装置において、判定手段５２７における所定の条件を、第１のパート、及び／又は、第２のパートの実行状況に基づいて変動させるようにしてもよい。
例えば、実行回数が相対的に少ない、又は実行時間が相対的に短いパートを第１のパートとし、実行回数が相対的に多い、又は実行時間が相対的に長いパートを第２のパートとする場合、第１のパートの実行回数が相対的に少ないほど、又は実行時間が相対的に短いほど、第１のパートのゲームの進行状況に関する所定の条件をより緩和する。これにより、所定の条件を満たすことが容易となるため、第１のパートを実行して第２のパートにおける利益（難易度が低下すること）を得るようにする動機付けが働きやすくなり、各パートをバランス良くユーザに実行させる仕組みを構築することができる。
なお、第１のパートと第２のパートの実行回数の差が相対的に大きいほど、又は実行時間の差が相対的に大きいほど、判定手段５２７の第１のパートのゲームの進行状況に関する所定の条件をより緩和しても同様の効果が得られる。
本変形例を実現するために、第１のパートのゲームの進行状況に関する所定の条件を複数設けておく。例えば、第１のパート（ここでは、「試合」とする。）で、他のユーザと試合で勝利するという条件である条件Ａと、他のユーザと対戦するという条件である条件Ｂ（条件Ａよりも緩和された条件）とを予め設けておく。この場合、ゲームサーバ２０のＣＰＵ２１は、例えば、第１のパートの実行回数が所定の閾値よりも少ない、若しくは第１のパートと第２のパートの実行回数の差が所定の閾値よりも大きいと判断した場合には、所定の条件として条件Ｂを適用し、第１のパートの実行回数が所定の閾値以上である、若しくは第１のパートと第２のパートの実行回数の差が所定の閾値以下であると判断した場合には、所定の条件として条件Ａを適用する。

（７−５）変形例５
また、試合パートにおいて他のユーザに勝利することで、スカウトパートにおいて１回の探索処理で減少する行動ポイントの量を低下させるようにしてもよい。これにより、ユーザは、スカウトパートにおいてより多くの回数の探索処理を連続的に行うことができるため、スカウトパートにおけるゲームの難易度が相対的に低下する。上述したスカウトパートにおける利益を得る目的で、ユーザは試合パートを実行することが動機付けられる。

（７−６）変形例６
スカウトパートにおいてゲームの難易度を低下させる場合、技能レベルが低いユーザが技能レベルの高いユーザよりも難易度がより低下するように設定することが好ましい。これにより、まだゲームに十分に慣れていない初級レベルのユーザがゲームをより楽しむことができる。例えば、変更手段５２８は、スカウトパートにおいて、レベルが低いユーザであるほど、より長い所定期間だけゲームの難易度を低下させる（例えば、上述したように選手カードのパラメータを増加させる）ようにしてもよい。かかる変更手段５２８の機能を実現するために、レベルと、ゲームの難易度を低下させる所定期間とを予め対応付けているデータを、例えばＲＡＭ２３に設けておく。ゲームサーバ２０のＣＰＵ２１は、図１２のフローチャートにおいてステップＳ５０の条件を満足した場合に、ユーザデータベース３１にアクセスして、対象となるユーザＩＤの技能レベルを読み出す。そして、ＣＰＵ２１は、ＲＡＭ２３内の上記データを参照して、レベルに応じた所定期間に基づき管理データ（図１３参照）の有効期間を書き込む。

また、スカウトパートにおいて、変更手段５２８は、試合パートにおいて他のユーザに勝利してから（つまり、第１のパートにおける所定の条件を満たしてから）の行動ポイントの消費量の積算値が所定の値に達するまでの期間、ゲームの難易度を低下させる（例えば、上述したように選手カードのパラメータを増加させる）ようにしてもよい。これにより、ユーザが有利になるようにスカウトパートのゲームの難易度が変更される期間を、ユーザ毎に柔軟に設定することができる。すなわち、行動ポイントの消費量は、ユーザ毎に、あるいはユーザのゲーム状況によって変わる場合が考えられるが、その場合でもユーザが有利になる期間を制限することができる。さらに、本実施形態のスカウトパートにおいて、ユーザの技能レベルが高くなるにつれて行動ポイントの消費量が増加するように設定されている場合には、初級レベルのユーザは、行動ポイントの消費量が相対的に少ないために、上級レベルのユーザよりも、行動ポイントの消費量の積算値が所定の値に達するまでの期間が長くなるため、スカウトパートをより長期間継続的にプレイでき、有利に進行させやすくなる。かかる変更手段５２８の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、ユーザが試合パートにおいて他のユーザに勝利してから、そのユーザがスカウトパートにおいて行動ポイントを消費する度に、行動ポイントの消費量の積算値を算出し、かつ算出した積算値を所定の値と比較する処理を行う。

以上、本発明の実施形態について詳細に説明したが、本発明は上記実施形態に限定されない。また、各実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。また、上述した実施形態、各変形例に記載されている技術的事項は、適宜組み合わせることが可能である。
上述した実施形態では、ソーシャルゲームに適用される場合を例として説明したが、これに限られない。例えば、ネットワーク上に置かれたサーバ装置と家庭用オンラインゲーム機とを接続した、いわゆるオンラインゲームシステムにおいても、上述した実施形態と同様に、各ユーザによるゲームの進行を制御できることは言うまでもない。

上述した実施形態では、複数のパートから第１のパート及び第２のパートを決定するときに、それぞれ単一のパートを決定する場合について説明したが、このような場合に限られない。第１のパート、第２のパートはそれぞれ、２以上のパートが含まれるようにして決定してもよい。例えば、複数のパートとして、パートＡ，Ｂ，Ｃ，Ｄが存在する場合に、実行回数が比較的少ないパートＡ，Ｂが第１のパートとして特定され、実行回数が比較的多いパートＣ，Ｄが第２のパートとして特定されてもよい。このように特定されたときに、判定手段５２７によって行われる判定における所定の条件は、第１のパート、及び／又は、第２のパートを構成する２以上のパートの各々の実行状況に基づいて決定してもよい。また、変更手段５２８によって行われる変更、すなわち第２のパートにおいてユーザが有利となるように第２のパートのゲームの難易度を変更する所定期間、又は所定回数は、第１のパート、及び／又は、第２のパートを構成する２以上のパートの各々の実行状況に基づいて決定してもよい。
なお、判定手段５２７によって行われる判定における所定の条件は、第１のパート、及び／又は、第２のパートを構成する２以上のパートの各々の実行状況に基づいて個別に設定してもよい。例えば、第１のパートを構成するパートＡ，ＢのうちパートＡよりもパートＢの実行回数が少ない場合には、パートＢを対象とする判定手段５２７の所定の条件を、パートＡのそれよりも相対的に緩くすることで、第１のパートの中でも特にパートＢに対する実行が促進されることが期待できる。また、第２のパートを構成するパートＣ，ＤのうちパートＣの実行回数が多い場合には、パートＣに対して設定される所定期間（パートＣの実行に有利な期間）をパートＤに対するそれよりも短くすることで、第２のパートの中でも特にパートＤに対する実行が促進されることが期待できる。このようにして、第１のパート、第２のパートがそれぞれ、２以上のパートを含む場合に、２以上のパートの各々をバランス良くユーザに実行させる仕組みを構築することができる。

上述した実施形態のゲーム制御装置では、所定の条件を満たした場合に、ゲームを構成する複数のパートのうち第１のパート（本実施形態では、試合パート）とは異なる第２のパート（本実施形態では、ミッションパート）において、所定期間又は所定回数分のプレイだけ、ユーザが有利になるように第２のパートのゲームの難易度を変更する機能を備える変更手段５２８を含むように構成したが、これに限られない。つまり、第２のパートのゲームの難易度を変更する場合に限られず、第２のパートのゲーム上の特典を付与する場合であってもよい。この場合、ゲーム上の特典は、第２のパートのゲームの難易度を易化することのほかに、第２のパートのゲーム上で利用可能なオブジェクト（例えば、キャラクタカード等）やアイテムをユーザに付与すること、あるいは第２のパートのゲーム上の各種ポイントをユーザに付与することであってもよい。第１のパートにおけるゲームの進行状況が所定の条件を満たす場合に、第２のパートにおけるゲームにおいて上述した特典を付与する仕組みとすることで、第２のパートで特典を得る目的で、第１のパートのプレイを実行するようにユーザが動機付けられる。
すなわち、本発明の別の観点は、プレイ対象となる複数のパートを含むゲームの実行を制御するゲーム制御装置であって、
ユーザの操作に応じて、前記複数のパートの各々におけるゲームを進行させるゲーム進行手段と、
前記複数のパートのうち第１のパートにおけるゲームの進行状況が所定の条件を満たすか否かを判定する判定手段と、
前記所定の条件を満たした場合に、前記複数のパートのうち前記第１のパートとは異なる第２のパートのゲーム上の特典を付与する特典付与手段と、
を備えてもよい。
このような特典付与手段を実現するために、ゲームサーバ２０のＣＰＵ２１は、例えば、特典としてレア度の高い選手カードをユーザに付与する場合には、所定の条件を満たしたと判断したときに、ユーザに付与する選手カードの情報をプレイヤデータベースに書き込む。

上述した実施形態では、ネットワーク上のゲームサーバ２０及びデータベースサーバ３０によって、図７に示した各手段の機能を実現する構成としたが、この構成に限られない。これらのすべての手段を通信端末１０によって実現する構成としてもよいし、少なくとも一部の手段を通信端末１０によって実現する構成としてもよい。通信端末１０とゲームサーバ２０とでは実質的に同一のハードウエア構成を採ることができるため、上記実施形態に記載したようにして通信端末１０によっても各機能を実現できる。その場合、上述した実施形態において、ユーザデータベース、及び管理データのうち少なくともいずれかを、各ユーザの通信端末１０内の記憶装置（ＲＡＭ１３、あるいは図示しないＨＤＤ(Hard Disk Drive)などの大容量記憶装置等）や、例えばネットワーク上の別の記憶装置に記憶させてもよい。

１０…通信端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１４…画像処理部
１５…指示入力部
１６…表示部
１７…無線通信インタフェース部
１８…バス
２０…ゲームサーバ２０
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…データベースアクセス部
２５…通信インタフェース部
２６…バス
３０…データベースサーバ
３１…ユーザデータベース
３２…ゲームデータベース
５１…登録手段
５２…ゲーム進行手段
５２１…表示手段
５２２…スカウト実行手段
５２３…強化実行手段
５２４…試合実行手段
５２５…抽選実行手段
５２６…ミッション実行手段
５２７…判定手段
５２８…変更手段

Claims (14)

1. プレイ対象となる複数のパートを含むゲームの実行を制御するゲーム制御装置であって、
   ユーザの操作に応じて、前記複数のパートの各々におけるゲームを進行させる手段であって、パートごとに時間経過に応じて回復する異なるポイントを消費することでゲームを進行させるゲーム進行手段と、
   前記複数のパートのうち第１のパートにおけるゲームの進行状況が所定の条件を満たすか否かを判定する判定手段と、
   前記所定の条件を満たした場合に、前記複数のパートのうち前記第１のパートとは異なる第２のパートにおいて、所定期間又は所定回数分のプレイだけ、前記ユーザが有利になるように第２のパートのゲームの難易度を変更する変更手段と、
   を備えたゲーム制御装置。
2. 前記ゲーム上のキャラクタと、キャラクタの能力を表すキャラクタデータとを対応付けて記憶する記憶手段、を備え、
   前記第２のパートは、前記ユーザによる操作対象となるキャラクタの能力に基づいてゲームを進行させるものであって、
   前記変更手段は、前記第２のパートにおいて、前記ユーザによる操作対象となるキャラクタの能力が高くなるように、当該キャラクタに対応するキャラクタデータを変更することを特徴とする、
   請求項１に記載されたゲーム制御装置。
3. 前記ゲーム上のキャラクタと、キャラクタの能力を表すキャラクタデータとを対応付けて記憶する記憶手段、を備え、
   前記第２のパートは、前記ユーザによる操作対象となるキャラクタの能力に基づいてゲームを進行させるものであって、
   前記変更手段は、前記第２のパートにおいて、前記ユーザによる操作対象となるキャラクタの能力が高くなるように当該キャラクタに対応するキャラクタデータを変更する確率を増加させることを特徴とする、
   請求項１に記載されたゲーム制御装置。
4. ユーザと、当該ユーザが利用可能なゲーム上のポイントとを対応付けて記憶する第２の記憶手段、を備え、
   前記第２のパートは、前記ポイントが所定値以下になった場合にゲームの進行が抑制されるものであって、
   前記変更手段は、前記第２のパートにおいて、前記所定の条件を満たしたユーザに対応するポイントの消費量を少なくすることを特徴とする、
   請求項１〜３のいずれかに記載されたゲーム制御装置。
5. 前記第２のパートは、複数のステージから構成されており、
   前記第２のパートの前記所定期間は、前記所定の条件を満たしたユーザがプレイ中のステージが終了するまでの期間であることを特徴とする、
   請求項１〜４のいずれかに記載されたゲーム制御装置。
6. ユーザと、当該ユーザのゲーム上のレベルとを対応付けて記憶する第３の記憶手段、を備え、
   前記第２のパートの前記所定期間は、前記所定の条件を満たしたユーザのレベルが低いほど長く設定されていることを特徴とする、
   請求項１〜３のいずれかに記載されたゲーム制御装置。
7. ユーザと、当該ユーザが利用可能なゲーム上のポイントとを対応付けて記憶する第２の記憶手段、を備え、
   前記第２のパートは、前記ポイントが所定値以下になった場合にゲームの進行が抑制されるものであって、
   前記第２のパートの前記所定期間は、前記所定の条件を満たしたユーザの、前記所定の条件を満たしてからの前記ポイントの消費量の積算値が所定の値に達するまでの期間であることを特徴とする、
   請求項１〜３のいずれかに記載されたゲーム制御装置。
8. 前記ゲーム進行手段は、前記複数のパートの各々に対するユーザの実行状況に基づいて、前記複数のパートの中から前記第１のパートと前記第２のパートを決定することを特徴とする、
   請求項１に記載されたゲーム制御装置。
9. 前記ゲーム進行手段は、前記複数のパートの各々に対するユーザの実行回数又は実行時間を計数し、実行回数が相対的に少ない、又は実行時間が相対的に短いパートを前記第１のパートとし、実行回数が相対的に多い、又は実行時間が相対的に長いパートを前記第２のパートとすることを特徴とする、
   請求項８に記載されたゲーム制御装置。
10. 前記変更手段は、前記第１のパート、及び／又は、前記第２のパートの実行状況に基づいて、前記第２のパートの前記所定期間、又は前記所定回数を変更することを特徴とする、
    請求項８又は９に記載されたゲーム制御装置。
11. 前記所定の条件を、前記第１のパート、及び／又は、前記第２のパートの実行状況に基づいて変動させることを特徴とする、
    請求項８〜１０のいずれかに記載されたゲーム制御装置。
12. プレイ対象となる複数のパートを含むゲームの実行を制御するゲーム制御方法であって、ゲーム制御装置が、
    ユーザの操作に応じて、前記複数のパートの各々におけるゲームを進行させるステップであって、パートごとに時間経過に応じて回復する異なるポイントを消費することでゲームを進行させるステップと、
    前記複数のパートのうち第１のパートにおけるゲームの進行状況が所定の条件を満たすか否かを判定するステップと、
    前記所定の条件を満たした場合に、前記複数のパートのうち前記第１のパートとは異なる第２のパートにおいて、所定期間又は所定回数分のプレイだけ、前記ユーザが有利になるように第２のパートのゲームの難易度を変更するステップと、
    を含むゲーム制御方法。
13. プレイ対象となる複数のパートを含むゲームの実行を制御するために、コンピュータに、
    ユーザの操作に応じて、前記複数のパートの各々におけるゲームを進行させる機能であって、パートごとに時間経過に応じて回復する異なるポイントを消費することでゲームを進行させる機能と、
    前記複数のパートのうち第１のパートにおけるゲームの進行状況が所定の条件を満たすか否かを判定する機能と、
    前記所定の条件を満たした場合に、前記複数のパートのうち前記第１のパートとは異なる第２のパートにおいて、所定期間又は所定回数分のプレイだけ、前記ユーザが有利になるように第２のパートのゲームの難易度を変更する機能と、
    を実現させるためのプログラム。
14. ユーザによって操作される通信端末と、当該通信端末とネットワークを介して接続され、プレイ対象となる複数のパートを含むゲームの実行を制御するサーバと、を備えたゲームシステムであって、
    ユーザの操作に応じて、前記複数のパートの各々におけるゲームを進行させる手段であって、パートごとに時間経過に応じて回復する異なるポイントを消費することでゲームを進行させるゲーム進行手段、
    前記複数のパートのうち第１のパートにおけるゲームの進行状況が所定の条件を満たすか否かを判定する判定手段、及び、
    前記所定の条件を満たした場合に、前記複数のパートのうち前記第１のパートとは異なる第２のパートにおいて、所定期間又は所定回数分のプレイだけ、前記ユーザが有利になるように第２のパートのゲームの難易度を変更する変更手段、
    の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
    ゲームシステム。

Images