WO2013121480A1

WO2013121480A1 - ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム

Info

Publication number: WO2013121480A1
Application number: PCT/JP2012/007022
Authority: WO
Inventors: 実米山; 清水　明彦; 謙史鴻上
Original assignee: 株式会社コナミデジタルエンタテインメント
Priority date: 2012-02-13
Filing date: 2012-11-01
Publication date: 2013-08-22
Also published as: JP2013162949A; JP5529184B2

Abstract

　対戦結果がキャラクタ間の能力値に基づいて決定される場合に、興趣性に富むゲームを提供するゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステムが提供される。このゲーム制御方法では、ユーザ識別情報に対応付けられたキャラクタ間の第１の対戦を実行し、キャラクタに設定された第１の能力値に基づいて第１の対戦の対戦結果を決定する。所定の操作入力又はゲームの進行状況に関する情報に基づいて、特定のアイテムをユーザに付与する。前記ユーザが前記アイテムを使用すると、当該ユーザのユーザ識別情報に対応するキャラクタの第１の能力値を、第１の能力値よりも高い第２の能力値に所定期間変更する。ユーザ識別情報に対応付けられたキャラクタ間の第２の対戦を前記第１の対戦と別に実行し、キャラクタの第２の能力値に基づいて第２の対戦の対戦結果を決定する。

Description

ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム

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

　従来から、ユーザが自らゲーム装置を操作してゲームを楽しむことが行われている。この場合、ゲーム装置は、ゲーム用アプリケーションソフトウエア（ゲーム用アプリケーション）を読み込み、実行するためのハードウエアを備えている。このようなゲーム用アプリケーションにより実行されるゲームとして野球ゲーム等の対戦ゲームが知られている。このような対戦ゲームには、ゲームをより興趣に富むものとするために、対戦そのものはもとより、多彩なバリエーションが盛り込むようにすることが行われている。その一例は、ユーザの操作対象となるキャラクタの能力をユーザがカスタマイズできるような機能を含ませることなどである。
　例えば、特許文献１には、キャラクタの行動スケジュールを作成するスケジュール作成手段を備え、キャラクタに特定の行動を指示すること等によりキャラクタの能力の増加などを図ることができるようにしたゲームシステム（野球ゲーム）が開示されている。このゲームシステムでは、キャラクタを育成し（つまり、キャラクタの能力を向上させて）、その後に他のユーザあるいはコンピュータとの間で対戦を行うこと、あるいは育成と対戦を交互に行うことが想定されている。

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

特開２０００－１８９６７７号公報

　上述した従来のゲームシステムは、キャラクタを育成する要素が盛り込まれている点で興趣性の高いゲームであるといえる。しかしながら、他のユーザあるいはコンピュータとの間で行われた対戦の対戦結果がキャラクタ間の能力値に基づいて決定される場合に、対戦する両者のキャラクタの能力差が大きいと、対戦結果が容易に予測できることから、興趣性に乏しい面がある。

　本発明は上述した観点に鑑みてなされたもので、対戦結果がキャラクタ間の能力値に基づいて決定される場合に、興趣性に富むゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステムを提供することを目的とする。

　本発明の第１の観点は、ゲーム制御装置である。
　当該ゲーム制御装置は、
　ユーザ識別情報に対応付けられたキャラクタ間の第１の対戦を実行し、キャラクタに設定された第１の能力値に基づいて第１の対戦の対戦結果を決定する第１の対戦実行手段と、
　所定の操作入力又はゲームの進行状況に関する情報に基づいて、特定のアイテムをユーザに付与する付与手段と、
　前記ユーザが前記アイテムを使用すると、当該ユーザのユーザ識別情報に対応するキャラクタの第１の能力値を、第１の能力値よりも高い第２の能力値に所定期間変更する変更手段と、
　ユーザ識別情報に対応付けられたキャラクタ間の第２の対戦を前記第１の対戦と別に実行し、キャラクタの第２の能力値に基づいて第２の対戦の対戦結果を決定する第２の対戦実行手段と、
　を備える。

　ここで、所定の操作入力に関する情報とは、例えば、ゲーム制御装置にアクセス可能な外部装置に対して所定の操作入力が行われたことを示す情報であってもよい。また、ゲームの進行状況に関する情報とは、例えば、ゲーム上の所定のエリアを制覇したり、キャラクタが所定のレベルに達したことなどであってもよい。
　このゲーム制御装置では、第１の対戦の対戦結果が、キャラクタに設定された第１の能力値に基づいて決定されるので、第１の対戦で勝利を得るために、例えばキャラクタを育成してキャラクタの能力値を向上させるという動機付けをユーザに与えることができる。
　また、第２の対戦の対戦結果が、特定のアイテムの使用により所定期間増加した第２の能力値に基づいて決定される。これにより、能力値の低いキャラクタを有するユーザに対して、第２の対戦では第１の対戦と比較して勝利を得る可能性が高くなるという期待感を与えることができる。また、第２の対戦では、特定のアイテムの使用によって、対戦相手の能力値の高いキャラクタとの能力差を小さくする、あるいはユーザ側のキャラクタの能力の優位性をより高めることができるので、対戦結果を容易に予測することができなくなることから、ゲームの興趣性を高めることができる。また、ユーザは、同じキャラクタに対して異なる能力値が適用される２つの対戦を楽しむことができ、特定のアイテムを使用したときのゲーム上の効果を実感することができるようになる。

　上記ゲーム制御装置において、前記ユーザ識別情報に複数のキャラクタが対応付けられている場合に、所定の操作入力に基づいて、複数のキャラクタのうち少なくとも一のキャラクタを選択する選択手段を備え、
　前記変更手段は、前記選択手段によって選択されたキャラクタの第１の能力値を変更させてもよい。
　このゲーム制御装置によれば、ユーザ識別情報に対応付けられた複数のキャラクタのうち、第１の能力値の変更対象となる少なくとも一のキャラクタを選択することができる。このため、第２の対戦で勝利を得るために、どのキャラクタの第１の能力値を変更するかについてユーザに検討させることになり、ゲームの興趣性を高めることができる。

　また、上記ゲーム制御装置において、前記キャラクタには、前記第１の対戦及び前記第２の対戦のうち少なくともいずれかが実行されるためのポイントの値が設定されており、
　前記第１の対戦は、前記ポイントの値の合計が第１の閾値以下のキャラクタ間で実行され、
　前記第２の対戦は、前記ポイントの値の合計が前記第１の閾値よりも小さい第２の閾値以下のキャラクタ間で実行されてもよい。
　例えば、キャラクタの能力値が高いほどポイントの値が大きく設定されている場合には、グループにキャラクタが複数存在する設定においては、当該キャラクタのポイント値の合計が大きくなることから、能力値の高いキャラクタだけでグループを構成することはできないため、第２の対戦の実行が制限される。これにより、第２の対戦は、第１の対戦と比較して、能力値の差が小さいグループ間（キャラクタ間）で実行されるようになる。この場合、特定のアイテムの使用による能力値の増加が、第２の対戦の対戦結果の決定により大きな影響を与えることになるので、対戦結果を容易に予測することができない。これにより、ゲームの興趣性を高めることができる。

　なお、前記キャラクタには、前記第１の対戦及び前記第２の対戦のうち少なくともいずれかが実行されるためのポイントの値が設定されており、前記第１の対戦は、前記ポイントの値が第１の閾値以下のキャラクタ間で実行され、前記第２の対戦は、前記ポイントの値が前記第１の閾値よりも小さい第２の閾値以下のキャラクタ間で実行されてもよい。
　例えば、キャラクタの能力値が高いほどポイントの値が大きく設定されている場合には、能力値の高いキャラクタによる第２の対戦の実行が制限される。これにより、第２の対戦は、第１の対戦と比較して、能力値の差が小さいキャラクタ間で実行されるようになる。この場合、特定のアイテムの使用による能力値の増加が、第２の対戦の対戦結果の決定により大きな影響を与えることになるので、対戦結果を容易に予測することができない。これにより、ゲームの興趣性を高めることができる。

　さらに、前記第１の対戦は、前記第１の能力値の合計が第１の閾値以下のキャラクタ間で実行され、前記第２の対戦は、前記第１の能力値の合計が前記第１の閾値よりも小さい第２の閾値以下のキャラクタ間で実行されてもよい。
　例えば、グループにキャラクタが複数存在する設定においては、グループ（キャラクタ）の能力値の合計が高い場合には、能力値の合計の高いグループ（キャラクタ）による第２の対戦の実行が制限される。これにより、第２の対戦は、第１の対戦と比較して、能力値の差が小さいグループ間（キャラクタ間）で実行されるようになる。この場合、特定のアイテムの使用による能力値の増加が、第２の対戦の対戦結果の決定により大きな影響を与えることになるので、対戦結果を容易に予測することができない。これにより、ゲームの興趣性を高めることができる。

　上記ゲーム制御装置において、前記キャラクタに複数の種類の能力値が設定されている場合に、前記複数の種類のうち少なくとも一つの種類の能力値が第１の能力値として設定されて構成され、前記変更手段は、複数の種類の能力値のうち前記アイテムに応じた第１の能力値を変更してもよい。
　例えば、元々能力値の高い種類に対し同種類のアイテムを使用することで、当該種類の能力値を所定期間さらに高めたり、各種能力値を所定期間平均化させることが可能になる。この場合、ユーザが、第２の対戦で勝利を得るために、複数の種類のうち増加させる能力値の種類を好みに応じて選択することができ、第２の対戦における戦略性を高めることができることから、ゲームの興趣性を高めることができる。

　上記ゲーム制御装置において、前記変更手段は、前記所定期間が経過したときに、前記キャラクタの第２の能力値を第１の能力値に戻してもよい。
　これにより、ユーザが、第２の対戦で勝利を得る可能性を高めるために、所定期間内に第２の対戦を行うことを動機付けることができる。

　上記ゲーム制御装置において、前記変更手段は、前記所定期間の経過に伴って、前記キャラクタの能力値を、第２の能力値から第１の能力値に段階的あるいは連続的に遷移させてもよい。
　例えば、キャラクタの能力値が前記所定期間の経過に伴って低下していくことにより、当該キャラクタが第２の対戦で勝利する可能性も徐々に低くなると考えられる。このため、ユーザが、第２の対戦で勝利を得る可能性を高めるために、極力早めに第２の対戦を行うことを動機付けることができる。したがって、第２の対戦の活性化を図ることができる。

　上記ゲーム制御装置において、前記第１の対戦及び前記第２の対戦のそれぞれが繰り返し実行される場合に、前記第２の対戦が開始されてから前記第２の対戦が終了するまでの期間は、前記第１の対戦が開始されてから前記第１の対戦が終了するまでの期間より短く設定されてもよい。
　これにより、ユーザが第２の対戦に参加できる機会が第１の対戦と比較して少なくなる。このため、特定のアイテムを使用することで、第１の対戦と比較して勝利する可能性が高まるという第２の対戦の利益を少ない参加機会でより多く得るために、第２の対戦に積極的に参加することをユーザに動機付けることができる。したがって、第２の対戦の活性化を図ることができる。

　上記ゲーム制御装置において、前記変更手段は、前記キャラクタの能力値が前記第２の能力値に変更されている間に前記ユーザが前記アイテムを使用すると、前記所定期間を延長してもよい。
　これにより、キャラクタの能力値を高めた状態を長い期間維持することができる。このため、第２の対戦で勝利を得られる期間が長くなるという期待感をユーザに与えることができる。また、アイテムの使用数（使用量）によっては、単にキャラクタ能力値を高めるだけでなく、所定期間をも延長できるので、アイテムの使用方法のバリエーションが拡大され、ゲームとしての遊戯性が高まる。

　本発明の第２の観点は、ゲーム制御方法である。
　このゲーム制御方法は、
　ユーザ識別情報に対応付けられたキャラクタ間の第１の対戦を実行し、キャラクタに設定された第１の能力値に基づいて第１の対戦の対戦結果を決定するステップと、
　所定の操作入力又はゲームの進行状況に関する情報に基づいて、特定のアイテムをユーザに付与するステップと、
　前記ユーザが前記アイテムを使用すると、当該ユーザのユーザ識別情報に対応するキャラクタの第１の能力値を、第１の能力値よりも高い第２の能力値に所定期間変更するステップと、
　ユーザ識別情報に対応付けられたキャラクタ間の第２の対戦を前記第１の対戦と別に実行し、キャラクタの第２の能力値に基づいて第２の対戦の対戦結果を決定するステップと、
　を備える。

　本発明の第３の観点は、ゲームの実行を制御するために、コンピュータに、
　ユーザ識別情報に対応付けられたキャラクタ間の第１の対戦を実行し、キャラクタに設定された第１の能力値に基づいて第１の対戦の対戦結果を決定する機能、
　所定の操作入力又はゲームの進行状況に関する情報に基づいて、特定のアイテムをユーザに付与する機能、
　前記ユーザが前記アイテムを使用すると、当該ユーザのユーザ識別情報に対応するキャラクタの第１の能力値を、第１の能力値よりも高い第２の能力値に所定期間変更する機能、及び
　ユーザ識別情報に対応付けられたキャラクタ間の第２の対戦を前記第１の対戦と別に実行し、キャラクタの第２の能力値に基づいて第２の対戦の対戦結果を決定する機能、
　を実現させるためのプログラムである。

　コンピュータは、例えばネットワークサーバ、大型計算機等であってよい。また、このプログラムは、ＤＶＤ－ＲＯＭやＣＤ－ＲＯＭ等のコンピュータが読み取り可能な情報記憶媒体に格納されてもよい。すなわち、本発明の第４の観点は、前記プログラムを記録したことを特徴とする、コンピュータ読み取り可能な記録媒体である。

　本発明の第５の観点は、通信端末と、当該通信端末からアクセスされ、前記通信端末によるゲームの実行を制御するサーバと、を含むゲームシステムであって、
　ユーザ識別情報に対応付けられたキャラクタ間の第１の対戦を実行し、キャラクタに設定された第１の能力値に基づいて第１の対戦の対戦結果を決定する第１の対戦実行手段、
　所定の操作入力又はゲームの進行状況に関する情報に基づいて、特定のアイテムをユーザに付与する付与手段、
　前記ユーザが前記アイテムを使用すると、当該ユーザのユーザ識別情報に対応するキャラクタの第１の能力値を、第１の能力値よりも高い第２の能力値に所定期間変更する変更手段、及び、
　ユーザ識別情報に対応付けられたキャラクタ間の第２の対戦を前記第１の対戦と別に実行し、キャラクタの第２の能力値に基づいて第２の対戦の対戦結果を決定する第２の対戦実行手段、
　の各手段を、前記通信端末又は前記サーバのいずれか一方が備える。

実施形態のゲームシステムの基本構成を示す図。実施形態の通信端末の外観の例を示す図。実施形態の通信端末の外観の例を示す図。実施形態の通信端末の構成を示すブロック図。実施形態のゲームサーバの構成を示すブロック図。実施形態のデータベースサーバの構成を示すブロック図。データベースサーバに含まれる第１のユーザデータベースの構成例を示す図。実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。トップページを表示する通信端末の表示画面の一例を示す図。ユーザがオーダーメニューを選択したときのウェブページの一例を示す図。ユーザがスカウトメニューを選択したときのウェブページの一例を示す図。ユーザがスカウトメニューを選択したときのウェブページの一例を示す図。ユーザがスカウトメニューを選択したときのウェブページの一例を示す図。ユーザが強化メニューを選択したときのウェブページの一例を示す図。ユーザが強化メニューを選択したときのウェブページの一例を示す図。個別対戦の処理の一例を示すフローチャート。個別対戦におけるウェブページの一例を示す図。定期リーグ戦用のリーグ戦データの構成例を示す図。の処理の一例を示すフローチャート。定期リーグ戦用のランキングデータのデータ構成例を示す図。通信端末における表示例を示す図。定期リーグ戦の処理の一例を示すフローチャート。ユーザが特別リーグ戦メニューを選択したときのウェブページの一例を示す図。設定用データのデータ構成例を示す図。特別リーグ戦用のユーザデータのキャラクタの調子と能力値との関係を説明する図。データベースサーバに含まれる第２のユーザデータベースの構成例の一部を示す図。特別リーグ戦の処理の一例を示すフローチャート。

　本発明は、２０１２年２月１３日に日本国特許庁に出願された特願２０１２－０２８０５５の特許出願に関連しており、当該出願の内容のすべてが参照によってこの明細書に組み込まれる。

　以下、本発明のゲームシステムの一実施形態について説明する。

　（１）ゲームシステムの構成
　図１は、実施形態のゲームシステムのシステム構成例を示している。図１に示すように、このゲームシステムは、例えばインターネットなどの通信網ＮＷ（ネットワーク）に接続可能な通信端末１０ａ，１０ｂ，１０ｃ，…と、通信網ＮＷに接続されているゲームサーバ２０と、データベースサーバ３０とによって構成されている。各通信端末１０ａ，１０ｂ，１０ｃ，…はそれぞれ、個々のユーザによって操作される端末であり、例えば、携帯端末、スマートフォン、ＰＤＡ(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分）が経過する度に１ポイントずつ回復（増加）する。

　ゲーム進行手段５２が個別対戦処理を実行する機能は、図１４を参照すると、例えば以下のとおり実現される。図１４は、ゲーム進行手段５２が個別対戦処理を実行する機能を実現するために、主としてゲームサーバ２０のＣＰＵ２１によって実行される一連の処理を示すフローチャートである。図１５は、ゲーム進行手段５２の機能により実現される、ユーザの通信端末１０上に表示されるウェブページの例を示す図である。

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

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

　ＣＰＵ２１は、対戦結果を決定すると対戦結果をユーザに通知するために、その対戦結果を含むウェブページを表示させるＨＴＭＬデータを、「試合開始」のメニューの選択操作を行ったユーザの携帯端末１０宛に送信する（ステップＳ１８）。「試合開始」のメニューを選択する操作が行われてから、対戦結果を含むウェブページが表示されるまでの時間は極めて短時間（例えば数秒）であるため、ユーザは、簡易な操作のみで極めて短期間で対戦結果を知ることができる。図１５のウェブページＰ７は、対戦処理の実行によって表示されるウェブページを示す図である。図１５のウェブページＰ７のウェブページでは、例えばスコア等を含む試合結果が表示される。
　なお、ゲーム進行手段５２は、個別対戦を行った２人のユーザに対して調子アイテムを付与してもよい。ここで、個別対戦に勝利したユーザに付与される調子アイテムの数は、敗北したユーザよりも多くしてもよい。

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

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

　上述したように、このゲームでは、図８のユーザデータ表示領域に表示される行動ポイント、運営ポイント、強化ポイント、エールポイント、および選手数は、スカウト処理、強化処理、個別対戦処理、及び抽選処理の各機能の実行によって変動しうるものとなっている。

　［定期リーグ戦処理］
　定期リーグ戦実行手段５３は、ユーザＩＤに対応付けられた選手カード間の定期リーグ戦（第１の対戦）を実行する機能を備える。ここで、定期リーグ戦実行手段５３は、本発明の第１の対戦実行手段の一例である。
　定期リーグ戦実行手段５３により実行される定期リーグ戦は、所定の時刻（例えば、ゲームサーバ２０内のタイマで設定される時刻）に行われる。定期リーグ戦は、すべてのユーザＩＤが参加（あるいは登録）するように設定してもよいが、定期リーグ戦の参加を希望する一部のユーザＩＤのみが参加するように設定してもよい。
　定期リーグ戦のスケジュールは任意に設定しうるが、一例を挙げれば以下のように行うことができる。定期リーグ戦に参加しているユーザＩＤのチームは、月曜日から金曜日までの５日間で定期リーグ戦を戦う。その５日間の間、定期リーグ戦実行手段５３は、毎日所定の時刻において、定期リーグ戦に参加している異なるユーザＩＤのチーム間での対戦を、通信端末１０に対する操作入力を契機とせずに自動的に実行する。定期リーグ戦に参加しているユーザＩＤのチームは毎日、例えば他の異なる１５のユーザＩＤのチームと対戦を行う。そして、５日間の間で各ユーザＩＤのチームが行う計７５試合の対戦の対戦結果に基づいて、その５日間の週における定期リーグ戦のランキング（順位）を決定する。なお、上記形態の定期リーグ戦が行われる予定の時刻は予め決められたものであるが、別の形態として、所定期間毎、例えば６時間毎に自動的に実行するという形態も考えられる。また、毎日実行しなくてもよく、一日おき、あるいは週1回に実行するようにしてもよい。
　なお、本実施形態では、定期リーグ戦が自動的に実行されるように構成されているが、上述した個別対戦と同様に、ユーザによる通信端末１０の操作入力を契機として実行されてもよい。

　定期リーグ戦実行手段５３によって実行される対戦の勝敗の決定方法は、上述した個別対戦における勝敗の決定方法と同様とすることができる。つまり、チームを構成する選手カードの能力値がその勝敗に影響を与える方法である限り如何なる方法を採ることができる。
　なお、定期リーグ戦のすべての対戦結果を決定するには一定の時間が掛かり、その時間内においても強化処理の実行に応じて選手カードの能力値が更新されうる。したがって、定期リーグ戦の開始時刻においてプレイヤデータベース３１のコピーデータを作成し、定期リーグ戦実行手段５３の実行中は、そのコピーデータ内の選手データの能力値を参照するようにする。これにより、定期リーグ戦実行手段５３の実行中においてもゲーム進行手段５２によって選手カードの能力値（プレイヤデータベース３１そのもののデータ）を更新し続けることができる。

　定期リーグ戦実行手段５３は、少なくとも過去の一定期間のリーグ戦の対戦結果を記録してもよい。具体的には、定期リーグ戦実行手段５３では、ゲームサーバ２０のＣＰＵ２１がゲームデータベース３２にアクセスし、ゲームデータベース３２内の定期リーグ戦用のリーグ戦データに定期リーグ戦の対戦結果を書き込む。
　ここで、定期リーグ戦用のリーグ戦データの一例を図１６に示す。図１６に示す例では、定期リーグ戦が毎日実行される場合に、日付ごとに定期リーグ戦の対戦結果が記録されている。図１６の例では、定期リーグ戦の対戦結果には、対戦を特定するための対戦ＩＤ、勝利したチームに対応したユーザＩＤ（勝利したユーザＩＤ）、敗北したチームに対応したユーザＩＤ（敗北したユーザＩＤ）、スコア、その他のデータ（例えば、勝利投手に対応する選手カードのデータ等）が含まれている。

　定期リーグ戦実行手段５３は、定期リーグ戦におけるユーザＩＤのランキングを記録するとともに逐次更新する。具体的には、定期リーグ戦実行手段５３は、ゲームサーバ２０のＣＰＵ２１がデータベースサーバ３０のゲームデータベース３２にアクセスしてリーグ戦の過去の対戦結果を読み出し、その読み出した対戦結果に基づいてユーザＩＤ単位でのランキングを算出する。そして、ＣＰＵ２１は、ゲームデータベース３２にアクセスし、ゲームデータベース３２内の定期リーグ戦用のランキングデータに、算出したランキングを書き込む。例えば定期リーグ戦が５日間の間で毎日継続的に行われる場合には、その各日付において、すべての対戦が終了したタイミングでユーザＩＤのランキングを算出して、そのランキングを定期リーグ戦用のランキングデータに書き込む。これにより、毎日、定期リーグ戦用のランキングデータにおけるユーザＩＤのランキングが更新されることになる。
　ここで、定期リーグ戦用のランキングデータの一例を図１７に示す。図１７に示す例では、ユーザＩＤのランキングが１番から順に記録されているとともに、ユーザＩＤごとに定期リーグ戦における勝数、負数、引き分け数が記録されている。

　また、定期リーグ戦実行手段５３は、過去の所定の期間あるいは所定回数の１または複数の定期リーグ戦の対戦結果、および／または、当該対戦結果に基づくユーザＩＤごとのランキング（順位）を、プレイヤの通信端末１０宛に通知してもよい。過去の所定の期間とは、ゲームを実行している日の前週にあたる１週間であってもよいし、ゲームを実行している当日または前日から遡る直近の期間であってもよい。
　定期リーグ戦実行手段５３では、ゲームサーバ２０のＣＰＵ２１が、例えば図８に示すウェブページで「定期リーグ戦」のメニューｍ６が選択されたことを認識した場合に、直近の定期リーグ戦における対戦結果、および／または、過去の所定期間あるいは所定回数の１または複数の定期リーグ戦の対戦結果に基づくユーザＩＤごとの順位を含むウェブページを各プレイヤの通信端末１０に表示するためのＨＴＭＬデータを、通信端末１０宛に送信する。このＨＴＭＬデータを解釈して通信端末１０で表示されるウェブページの例を図１８に示す。図１８に示すウェブページの例では、ユーザＩＤに対応した定期リーグ戦の結果（例えば、４５勝１５敗等の勝敗結果や、６５７３位等のランキング）が表示されている。図１８に例示するウェブページでは、定期リーグ戦における複数の各節（第４節、第５節、第６節）についての情報が例えば通信端末１０の指示入力部１５の方向指示釦等でスクロール表示される例が示されている。図１８は、第５節のリーグ戦が行われている特定の日付における表示例であり、下から順に、第４節の対戦結果、第５節の対戦結果、第６節の対戦予定、現在のリーグ戦における総合的な勝敗結果およびランキングが示されている。

　図１８では、定期リーグ戦の次回（第６節）の対戦開始までの時間が表示されている。このように、定期リーグ戦実行手段５３では、定期リーグ戦の現実世界の開始時刻を、予め各プレイヤの通信端末１０宛に通知してもよい。これにより、各ユーザは、定期リーグ戦の現実世界の開始時刻を知ることができるので、定期リーグ戦を極力有利な状態で戦うことができるように、その開始時刻までに強化処理を計画的に行って選手カードの能力値を定期リーグ戦の次回の開始時刻までに上げるような準備をすることができる。

　次に図１９を参照し、定期リーグ戦の実行処理について説明する。図１９は、定期リーグ戦実行手段５３が定期リーグ戦の実行処理を実行する機能を実現するために、主としてゲームサーバ２０のＣＰＵ２１によって実行される一連の処理を示すフローチャートである。なお、ここでは、例えば、定期リーグ戦が月曜日から金曜日までの５日間で行われる場合を例にして説明する。この場合、５日間で第１～第５節の定期リーグ戦の結果によってユーザＩＤごとの順位が争われることになる。前述したように、各節の定期リーグ戦は、例えば現実世界の午後３時丁度等、予めユーザに通知された定刻に開始されるようにすることが好ましい。

　図１９において、月曜日から金曜日までの５日間の毎日、定期リーグ戦が行われる開始時刻になると（ステップＳ２０：ＹＥＳ）、ゲームサーバ２０のＣＰＵ２１は、定期リーグ戦を実行する。定期リーグ戦は、定期リーグ戦に参加しているユーザＩＤのユーザによる通信端末１０に対する操作入力を契機とせずに自動的に実行される。ゲームサーバ２０のＣＰＵ２１は、例えば第１節の定期リーグ戦を行う場合には、その第１節の定期リーグ戦における対戦の組合せ、つまり、あるユーザＩＤに対応するチームと、他の所定数のユーザＩＤのチームとの対戦の組合せを決定する（ステップＳ２２）。対戦の組合せを決定すると、ＣＰＵ２１は次にユーザデータベース３１を参照し、チームを構成する選手カードの能力値に基づいて、つまり、選手カードの能力値の差が勝敗に影響を与えるようにして、対戦結果を決定する（ステップＳ２４）。第１節の定期リーグ戦において、各ユーザＩＤに対応したチームの対戦数がＭであり、定期リーグ戦に参加しているユーザＩＤの数がＮであるとすると、第１節の定期リーグ戦では、Ｍ×Ｎ個の対戦の対戦結果を決定することになる。ＣＰＵ２１は、対戦結果を決定した後、その第１節の定期リーグ戦の対戦結果を定期リーグ戦用のリーグ戦データに記録するとともに、第１節の定期リーグ戦の対戦結果に基づくユーザＩＤのランキングを、定期リーグ戦用のランキングデータに記録する（ステップＳ２６）。その後、ＣＰＵ２１は、定期リーグ戦に参加している各ユーザＩＤに対応するユーザの通信端末１０宛に、第１節の対戦結果と、第１節が終了した時点におけるユーザＩＤのランキングを通知する（ステップＳ２８）。なお、この通知は、各ユーザが例えば図８に例示したウェブページで「定期リーグ戦」のメニューｍ６が選択された場合に、通信端末１０において、第１節の対戦結果と、第１節が終了した時点におけるユーザＩＤのランキングとを含むウェブページが表示されるようにして行うことができる。

　［特別リーグ戦処理］
　次に、特別リーグ戦処理について説明する。特別リーグ戦（第２の対戦）は、定期リーグ戦（第１の対戦）と同様に、ユーザＩＤに対応付けられた選手カード間の対戦であり、定期リーグ戦と別に実行される。特別リーグ戦は、定期リーグ戦と並行して実行されてもよいし、定期リーグ戦が実行される時間帯とは異なる時間帯に実行されてもよい。特別リーグ戦の対戦結果は、調子アイテムの使用により所定期間増加した能力値（第２の能力値）に基づいて決定される点において、定期リーグ戦と異なっている。
　特別リーグ戦処理は、変更手段５４及び特別リーグ戦実行手段５５により実行される。

　変更手段５４は、ユーザが調子アイテムを使用すると、当該ユーザのユーザＩＤに対応する選手カードの能力値（第１の能力値）を、当該能力値よりも高い能力値（第２の能力値）に所定期間変更する機能を備える。
　変更手段５４の機能について図２０～２２を参照して説明する。図２０は、図８に示すトップページにおいて「特別リーグ戦」メニューｍ７が選択操作されたときのウェブページの表示例である。図２１は、設定用データのデータ構成例の一例である。図２２は、特別リーグ戦用のユーザデータの構成例を示す図である。

　変更手段５４は、図８に示すトップページにおいて「特別リーグ戦」メニューｍ７が選択操作されると、図２０に示すウェブページを携帯端末１０上に表示させる。図２０に示すウェブページでは、図９に例示したウェブページと同様に、選手カードのオーダーが表示されている。なお、図２０に示すウェブページに表示された選手カードの能力値（打力、走力、守備力）は、後述する特別リーグ戦用のユーザデータに記録された値である。表示領域１２０には、ユーザが所持する調子アイテムの枚数（図２０の例では、４個）が表示されている。図２０のウェブページにおいて、表示領域１２１～１２３には、それぞれ選手カードの調子を表すアイコンが表示される。例えば、図示の例では、表示領域１２１に表示されたアイコンは、「選手Ａ」の調子が「普通」であることを示している。また、表示領域１２２に表示されたアイコンは、「選手Ｈ」の調子が「好調」であることを示している。さらに、表示領域１２３に表示されたアイコンは、「選手Ｋ」の調子が「絶好調」であることを示している。これらのアイコンは、図２１に例示する設定用データにて設定されている。図２０に示すウェブページにおいて、選手カードごとの表示領域に設けられた「調子アイテム使用」というメニューが選択操作されると、変更手段５４は、選択操作されたメニューに対応する選手カードを選択し、選択した選手カードの能力値を変更する処理を行う。ここで、変更手段５４は、本発明の選択手段の一例である。
　なお、図２０に示すウェブページは、例えば、複数の調子アイテムを一括して一つの選手カードに使用可能に構成されてもよい。また、例えば、複数の選手カードのそれぞれに一つずつ一括して調子アイテムを使用可能に構成されてもよい。

　図２１を参照し、設定用データについて説明する。設定用データは、ゲームデータベース３２に記憶されている。設定用データの内容は、ゲームサーバ２０によって適宜変更されうる。設定用データは、「普通」、「好調」、「絶好調」という調子毎に、アイコン、効果、継続期間を含んでもよい。本実施形態では、選手カードのデフォルトの調子は「普通」に設定されている。図２０に示したウェブページにおいて、選手カードに対して調子アイテムを使用すると、選手カードの調子が「絶好調」になる。そして、所定期間が経過した後、調子が「好調」になる。さらに、所定期間が経過したときには、調子が「普通」に戻ってもよい。
　選手カードの調子が「絶好調」の場合には、当該選手カードの能力値が、「普通」の調子と比べて所定の割合（図２１の例では１０％）だけ増加する。また、選手カードの調子が「好調」の場合には、当該選手カードの能力値が、「普通」の調子と比べて所定の割合（図２１の例では５％）だけ増加する。「好調」及び「絶好調」それぞれの調子の継続期間は、適宜設定してもよい。図２１の例示では、特別リーグ戦の節を単位として継続期間が設定されているが、例えば、時間（例えば１２時間等）によって設定されてもよい。また、継続期間の長さは、ランダム（図２１の例では１～３節）に設定してもよい。図２１に例示した設定データでは、調子が「絶好調」あるいは「好調」である期間は、最長で調子アイテム使用後特別リーグ戦５節分であり、最短で調子アイテム使用後特別リーグ戦３節分である。

　次に図２２を参照し、特別リーグ戦用のユーザデータについて説明する。特別リーグ戦用のユーザデータは、ユーザＩＤ毎にゲームデータベース３２に記憶されている。特別リーグ戦用のユーザデータは、ゲームサーバ２０によって適宜変更されうる。特別リーグ戦用のユーザデータは、基準データと変更データとを含む。基準データは、選手ＩＤ及び能力値（打力、走力、守備力）を含む。基準データの内容は、図６に示したユーザデータベース３１と同じ内容であることが好ましい。変更データは、能力値（打力、走力、守備力）と残り継続期間とを含む。残り継続期間は、「調子」及び「絶好調」それぞれの継続期間の和で示され、図２２の例示では、特別リーグ戦の節単位で設定されている。ここで、選手カードの変更データに数値が記録されている場合、当該選手カードは、調子アイテムが使用されたことにより、「絶好調」あるいは「好調」の調子にあることを示している。一方、選手カードの変更データにＮＵＬＬデータが記録されている場合（基準データにのみ数値が記録されている場合）、当該選手カードには、調子アイテムの使用の効果が生じていない（すなわち、調子が「普通」）ことを示している。

　図２３を参照し、変更手段５４の機能を実現するための処理について説明する。図２３は、変更手段５４の機能を実現するために、主としてゲームサーバ２０のＣＰＵ２１によって実行される一連の処理を示すフローチャートである。
　ゲームサーバ２０のＣＰＵ２１は、例えば図８のウェブページ上でメニューｍ７が選択されたことを認識すると、図２０に示したウェブページを表示するためのＨＴＭＬデータを通信端末１０宛に送信する（ステップＳ３０）。ここで、ＣＰＵ２１は、図２０に示すウェブページに表示される選手カードの能力値（打力、走力、守備力）を、特別リーグ戦用のユーザデータから読み出す。また、ＣＰＵ２１は、保有カードの画像データ等をユーザデータベース３１から取得する。さらに、ＣＰＵ２１は、それぞれの選手カードの調子に応じたアイコンを設定用データから抽出し、通信端末１０宛に送信するＨＴＭＬデータに含む。ここで、ＣＰＵ２１は、それぞれの選手カードの調子を、特別リーグ戦用のユーザデータの残り継続期間の値に基づき判別する。すなわち、残り継続期間の値が３～５の場合には、選手カードの調子が「絶好調」と判別され、残り継続期間の値が１または２の場合には、選手カードの調子が「好調」と判別される。また、残り継続期間にＮＵＬＬデータが記録されている場合には、選手カードの調子が「普通」と判別される。

　次に、図２０に示したウェブページにおいて「調子アイテム使用」メニューが選択操作されたことを認識すると（ステップＳ３２：ＹＥＳ）、ＣＰＵ２１は、選択操作されたメニューに対応する選手カードの調子が「絶好調」になるように、特別リーグ戦用のユーザデータに書き込みを行う（ステップＳ３４）。具体的に説明すると、ＣＰＵ２１は、特別リーグ戦用のユーザデータの変更データに、基準データの能力値から所定の割合（例えば１０％）だけ増加した能力値を記録する。また、ＣＰＵ２１は、調子が「絶好調」の状態の継続期間の長さ（図２１の例では１～３）を、ランダムあるいは所定の確率で決定し、調子が「好調」の状態の継続期間の長さ（図２１の例では２）を加えて、変更データの残り継続期間に記録する。そして、ＣＰＵ２１は、選択操作を行ったユーザのユーザデータベース３１の調子アイテムの個数を１つ減らす（ステップＳ３６）。

　特別リーグ戦実行手段５５は、ユーザＩＤに対応付けられた選手カード間の特別リーグ戦（第２の対戦）を実行する機能を備える。ここで、特別リーグ戦実行手段５５は、本発明の第２の対戦実行手段の一例である。特別リーグ戦実行手段５５は、定期リーグ戦実行手段５３と同様の機能を有していてもよい。

　次に図２４を参照し、特別リーグ戦の実行処理について説明する。図２４は、特別リーグ戦実行手段５５が特別リーグ戦の実行処理を実行する機能を実現するために、主としてゲームサーバ２０のＣＰＵ２１によって実行される一連の処理を示すフローチャートである。なお、ここでは、例えば、特別リーグ戦が月曜日から水曜日までの３日間で行われる場合を例にして説明する。この場合、３日間で第１～第３節の特別リーグ戦の結果によってユーザＩＤごとの順位が争われることになる。各節の特別リーグ戦は、例えば現実世界の午後７時丁度等、予めユーザに通知された定刻に開始されるようにすることが好ましい。

　図２４において、月曜日から水曜日までの３日間の毎日、特別リーグ戦が行われる開始時刻になると（ステップＳ４０のＹＥＳ）、ゲームサーバ２０のＣＰＵ２１は、特別リーグ戦を実行する。特別リーグ戦は、特別リーグ戦に参加しているユーザＩＤのユーザによる通信端末１０に対する操作入力を契機とせずに自動的に実行されてもよい。ゲームサーバ２０のＣＰＵ２１は、例えば第１節の特別リーグ戦を行う場合には、その第１節の特別リーグ戦における対戦の組合せ、つまり、あるユーザＩＤに対応するチームと、他の所定数のユーザＩＤのチームとの対戦の組合せを決定する（ステップＳ４２）。対戦の組合せを決定すると、ＣＰＵ２１は、特別リーグ戦用のユーザデータを参照し、チームを構成する選手カードの能力値に基づいて、つまり、選手カードの能力値の差が勝敗に影響を与えるようにして、対戦結果を決定する（ステップＳ４４）。ここで、ＣＰＵ２１は、特別リーグ戦用のユーザデータのうち変更データに能力値が記録されている選手カードについては、変更データに記録された能力値を用いる。また、ＣＰＵ２１は、特別リーグ戦用のユーザデータのうち変更データに能力値が記録されていない選手カードについては、基準データに記録された能力値を用いる。ＣＰＵ２１は、第１節の特別リーグ戦において、各ユーザＩＤに対応したチームの対戦数がＭであり、特別リーグ戦に参加しているユーザＩＤの数がＮであるとすると、第１節の特別リーグ戦では、Ｍ×Ｎ個の対戦の対戦結果を決定することになる。ＣＰＵ２１は、対戦結果を決定した後、その第１節の特別リーグ戦の対戦結果を特別リーグ戦用のリーグ戦データに記録するとともに、第１節の特別リーグ戦の対戦結果に基づくユーザＩＤのランキングを、特別リーグ戦用のランキングデータに記録する（ステップＳ４６）。ここで、特別リーグ戦用のリーグ戦データのデータ構成は、図１６に例示した定期リーグ戦用のリーグ戦データのデータ構成と同様である。また、特別リーグ戦用のランキングデータのデータ構成は、図１７に例示した定期リーグ用のランキングデータのデータ構成と同様である。その後、ＣＰＵ２１は、特別リーグ戦に参加している各ユーザＩＤに対応するユーザの通信端末１０宛に、第１節の対戦結果と、第１節が終了した時点におけるユーザＩＤのランキングを通知する（ステップＳ４８）。なお、この通知は、各ユーザが例えば図８に例示したウェブページで「特別リーグ戦」のメニューｍ７が選択された場合に、通信端末１０において、第１節の対戦結果と、第１節が終了した時点におけるユーザＩＤのランキングとを含むウェブページが表示されるようにして行うことができる。

　次に、ＣＰＵ２１は、特別リーグ戦用のユーザデータの残り継続期間を１つ減少することにより更新する（ステップＳ５０）。また、ＣＰＵ２１は、更新後の残り継続期間に基づいて変更データの能力値を更新する（ステップＳ５２）。具体的に説明すると、ＣＰＵ２１は、更新後の残り継続期間が２になった選手カードについては、調子が「絶好調」から「好調」になったと判別して、変更データの能力値を更新する。この場合、変更データには、基準データの能力値の所定の割合（例えば５％）だけ増加した能力値が記録される。また、ＣＰＵ２１は、更新後の残り継続期間が０になった選手カードについては、調子が「好調」から「普通」になったと判別して、変更データの能力値を更新する。この場合、変更データには、ＮＵＬＬデータが記録される。

　上述したように、このゲーム制御装置によれば、定期リーグ戦の対戦結果が、選手カードに設定されたユーザデータベース３１の能力値に基づいて決定されるので、定期リーグ戦で勝利を得るために、例えばキャラクタを育成してキャラクタの能力値を向上させるという動機付けをユーザに与えることができる。また、特別リーグ戦の対戦結果が、調子アイテムの使用により所定期間増加した能力値に基づいて決定される。これにより、能力値の低いキャラクタを有するユーザに対して、特別リーグ戦では定期リーグ戦と比較して勝利を得る可能性が高くなるという期待感を与えることができる。また、特別リーグ戦では、調子アイテムの使用によって、対戦相手の能力値の高いキャラクタとの能力差を小さくする、あるいはユーザ側の選手カードの能力の優位性をより高めることができるので、対戦結果を容易に予測することができなくなることから、ゲームの興趣性を高めることができる。また、ユーザは、同じ選手カードに対して異なる能力値が適用される２つの対戦を楽しむことができ、調子アイテムを使用したときのゲーム上の効果を実感することができるようになる。

　また、ゲーム制御装置において、変更手段５４は、調子アイテム使用後所定期間が経過したときに、選手カードの能力値を、ユーザデータベース３１の能力値に戻してもよい。
　これにより、ユーザが、特別リーグ戦で勝利を得る可能性を高めるために、所定期間内に特別リーグ戦を行うことを動機付けることができる。

　さらに、ゲーム制御装置において、変更手段５４は、調子アイテム使用後所定期間の経過に伴って、選手カードの能力値を、ユーザデータベース３１の能力値に段階的あるいは連続的に遷移させてもよい。
　例えば、選手カードの能力値が前記所定期間の経過に伴って低下していくことにより、当該選手カードを含むチームが特別リーグ戦で勝利する可能性も低くなると考えられる。このため、ユーザが、特別リーグ戦で勝利を得る可能性を高めるために、極力早めに特別リーグ戦を行うことを動機付けることができる。したがって、特別リーグ戦の活性化を図ることができる。

　（７）変形例
　（７－１）変形例１
　上記実施形態において、選手カードには、定期リーグ戦及び特別リーグ戦のうち少なくともいずれかが実行されるための必要ポイントの値が設定されており、定期リーグ戦は、必要ポイントの値の合計が第１の閾値以下のキャラクタ間で実行され、特別リーグ戦は、必要ポイントの値の合計が前記第１の閾値よりも小さい第２の閾値以下の選手カード間で実行されてもよい。
　例えば、選手カードの能力値が高いほど必要ポイントの値が大きく設定されている場合には、チームに選手カードが複数存在する設定においては、当該選手カードの必要ポイント値の合計が大きくなることから、能力値の高い選手カードだけでチームを構成することができないため、特別リーグ戦の実行が制限される。これにより、特別リーグ戦は、定期リーグ戦と比較して、能力値の差が小さいチーム間（選手カード間）で実行されるようになる。この場合、調子アイテムの使用による能力値の増加が、特別リーグ戦の対戦結果の決定に影響を与えることになるので、対戦結果を容易に予測することができない。これにより、ゲームの興趣性を高めることができる。

　（７－２）変形例２
　また、選手カードには、定期リーグ戦及び特別リーグ戦のうち少なくともいずれかが実行されるための必要ポイントの値が設定されており、前記定期リーグ戦は、前記必要ポイントの値が第１の閾値以下の選手カード間で実行され、前記特別リーグ戦は、前記必要ポイントの値が前記第１の閾値よりも小さい第２の閾値以下の選手カード間で実行されてもよい。なお、本変形例における第１の閾値、第２の閾値は、変形例１における第１の閾値、第２の閾値とはそれぞれ異なる値であってよい。
　例えば、選手カードの能力値が高いほど必要ポイントの値が大きく設定されている場合には、能力値の高い選手カードによる特別リーグ戦の実行が制限される。これにより、特別リーグ戦は、定期リーグ戦と比較して、能力値の差が小さい選手カード間で実行されるようになる。この場合、調子アイテムの使用による能力値の増加が、特別リーグ戦の対戦結果の決定に影響を与えることになるので、対戦結果を容易に予測することができない。これにより、ゲームの興趣性を高めることができる。

　（７－３）変形例３
　さらに、定期リーグ戦は、ユーザデータベース３１の能力値の合計が第１の閾値以下の選手カード間で実行され、特別リーグ戦は、ユーザデータベース３１の能力値の合計が前記第１の閾値よりも小さい第２の閾値以下の選手カード間で実行されてもよい。なお、本変形例における第１の閾値、第２の閾値は、変形例１、２における第１の閾値、第２の閾値とはそれぞれ異なる値であってよい。
　例えば、チームに選手カードが複数存在する設定においては、チーム（選手カード）の能力値の合計が高い場合には、能力値の合計の高いチーム（選手カード）による特別リーグの実行が制限される。これにより、特別リーグは、定期リーグと比較して、能力値の差が小さいチーム間（キャラクタ間）で実行されるようになる。この場合、調子アイテムの使用による能力値の増加が、特別リーグ戦の対戦結果の決定に影響を与えることになるので、対戦結果を容易に予測することができない。これにより、ゲームの興趣性を高めることができる。

　変形例１～３の定期リーグ戦実行手段５３及び特別リーグ戦実行手段５５では、ＣＰＵ２１は、定期リーグ戦及び特別リーグ戦のそれぞれを実行する際に、ユーザのチームの運営ポイント、試合に出場する選手カードの必要ポイント、あるいは試合に出場する選手カードの能力値の合計が所定の条件を満たすか否かを判別してもよい。所定の条件としては、例えば、運営ポイントが２００以下のチームが定期リーグ戦に参加でき、運営ポイントが１００以下のチームが特別リーグ戦に参加できるという条件を設けてもよい。また、例えば、必要ポイントが２０以下の選手カードが定期リーグ戦に参加でき、必要ポイントが１０以下の選手カードが特別リーグ戦に参加できるという条件を設けてもよい。さらに、例えば、能力値の合計が１０００以下の選手カードが定期リーグ戦に参加でき、能力値の合計が５００以下の選手カードが特別リーグ戦に参加できるという条件を設けてもよい。
　ＣＰＵ２１は、ユーザが所定の条件を満たさないと判別した場合には、例えば所定の条件を満たすようにオーダー処理等を行うことを促すメッセージを含むＨＴＭＬデータを当該ユーザの通信端末１０宛に送信してもよい。また、ＣＰＵ２１は、図９あるいは図２０に示すウェブページにおいて、選手カードに対する選択操作が行われる毎に、所定の条件を満たすか否か判別し、所定の条件を満たさない場合には、ウェブページにリーグ戦に参加できないことを通知するメッセージを表示してもよい。

　（７－４）変形例４
　上記実施形態において、選手カードに複数の種類の能力値が設定されている場合に、前記複数の種類のうち少なくとも一つの種類の能力値に設定されて構成され、変更手段５４は、複数の種類の能力値のうち調子アイテムに応じた能力値を変更してもよい。例えば、元々能力値の高い種類に対し同種類の調子アイテムを使用することで、当該種類の能力値を所定期間さらに高めたり、各種能力値を所定期間平均化させることが可能になる。この場合、ユーザが、特別リーグ戦で勝利を得るために、複数の種類のうち増加させる能力値の種類を好みに応じて選択することができ、特別リーグ戦における戦略性を高めることができることから、ゲームの興趣性を高めることができる。
　本変形例のゲーム進行手段５２では、ＣＰＵ２１は、例えば、打力用調子アイテム、走力用調子アイテム、守備力用調子アイテム等のように選手カードの能力値の種類に応じた特定のアイテムを、ランダムあるいは所定の確率でユーザに付与してもよい。
　また、本変形例の変更手段５４では、ＣＰＵ２１は、図２０のウェブページにおいて、例えば「打力用調子アイテム使用」のメニューが選択操作されると、特別リーグ用のユーザデータにおいて、選択操作されたメニューに対応する選手カードの打力の能力値を所定期間増加させればよい。

　（７－５）変形例５
　上記実施形態において、定期リーグ戦及び特別リーグ戦のそれぞれが繰り返し実行される場合に、特別リーグ戦が開始されてから特別リーグ戦が終了するまでの期間は、定期リーグ戦が開始されてから定期リーグ戦が終了するまでの期間より短く設定されてもよい。
　これにより、ユーザが特別リーグ戦に参加できる機会が定期リーグ戦と比較して少なくなる。このため、調子アイテムを使用することで、定期リーグ戦と比較して勝利する可能性が高まるという特別リーグ戦の利益を少ない参加機会でより多く得るために、特別リーグ戦に積極的に参加することをユーザに動機付けることができる。したがって、特別リーグ戦の活性化を図ることができる。
　本変形例の定期リーグ戦実行手段５３及び特別リーグ戦実行手段５４では、ゲームサーバ２０のＣＰＵ２１は、例えばゲームデータベース３２に予め記憶された定期リーグ戦及び特別リーグ戦のスケジュールデータに応じて、定期リーグ戦及び特別リーグ戦を実行してもよい。この場合、スケジュールデータでは、特別リーグ戦が開始されてから特別リーグ戦が終了するまでの期間が、定期リーグ戦が開始されてから定期リーグ戦が終了するまでの期間より短く設定されていればよい。

　（７－６）変形例６
　変更手段５４は、選手カードの能力値が高い能力値に変更されている間に前記ユーザが調子アイテムを使用すると、所定期間を延長してもよい。これにより、選手カードの能力値を高めた状態を長い期間維持することができる。このため、特別リーグ戦で勝利を得られる期間が長くなるという期待感をユーザに与えることができる。また、調子アイテムの使用数（使用量）によっては、単に選手カードの能力値を高めるだけでなく、所定期間をも延長できるので、調子アイテムの使用方法のバリエーションが拡大され、ゲームとしての遊戯性が高まる。
　本変形例の変更手段５４では、ゲームサーバ２０のＣＰＵ２１は、図２０に示したウェブページにおいて、調子が「絶好調」あるいは「好調」の選手カードに対して「調子アイテム使用」メニューが選択操作されると、特別リーグ用のユーザデータにおいて、当該選手カードの残り継続期間を増加すればよい。

　以上、本発明の実施形態について詳細に説明したが、本発明は上記実施形態に限定されない。また、各実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。
　例えば、上述した実施形態では、適用されるゲームが野球形式のデジタルカードゲームである場合を想定したが、キャラクタに設定されているパラメータを変更可能に構成されているゲームであれば、ゲームの種別は如何なるものでもよい。例えば、モンスターキャラクタが登場するモンスターゲームにおいて、特定のアイテムを使用することでユーザがモンスターキャラクタの能力値を変化させることができるようにしてもよい。

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

　例えば、上述した実施形態では、ネットワーク上のゲームサーバ２０及びデータベースサーバ３０によって、ゲーム進行手段５２、定期リーグ戦実行手段５３、変更手段５４、特別リーグ戦実行手段５５の各機能を実現する構成としたが、この構成に限られない。これらのすべての手段を通信端末１０によって実現する構成としてもよいし、少なくとも一部の手段を通信端末１０によって実現する構成としてもよい。通信端末１０とゲームサーバ２０とでは実質的に同一のハードウエア構成を採ることができるため、上記実施形態に記載したようにして通信端末１０によっても各機能を実現できる。通信端末１０は、ゲーム終了時には、ゲームの結果についてのデータをゲームサーバ２０へ送信し、ゲームサーバ２０は、受信したゲームの結果のデータをユーザと関連付けてゲームデータベース３２に記録するようにしてもよい。

Claims

　ユーザ識別情報に対応付けられたキャラクタ間の第１の対戦を実行し、キャラクタに設定された第１の能力値に基づいて第１の対戦の対戦結果を決定する第１の対戦実行手段と、
　所定の操作入力又はゲームの進行状況に関する情報に基づいて、特定のアイテムをユーザに付与する付与手段と、
　前記ユーザが前記アイテムを使用すると、当該ユーザのユーザ識別情報に対応するキャラクタの第１の能力値を、第１の能力値よりも高い第２の能力値に所定期間変更する変更手段と、
　ユーザ識別情報に対応付けられたキャラクタ間の第２の対戦を前記第１の対戦と別に実行し、キャラクタの第２の能力値に基づいて第２の対戦の対戦結果を決定する第２の対戦実行手段と、
　を備えた、ゲーム制御装置。
　前記ユーザ識別情報に複数のキャラクタが対応付けられている場合に、所定の操作入力に基づいて、複数のキャラクタのうち少なくとも一のキャラクタを選択する選択手段を備え、
　前記変更手段は、前記選択手段によって選択されたキャラクタの第１の能力値を変化させることを特徴とする、
　請求項１に記載されたゲーム制御装置。
　前記キャラクタには、前記第１の対戦及び前記第２の対戦のうち少なくともいずれかが実行されるためのポイントの値が設定されており、
　前記第１の対戦は、前記ポイントの値の合計が第１の閾値以下のキャラクタ間で実行され、
　前記第２の対戦は、前記ポイントの値の合計が前記第１の閾値よりも小さい第２の閾値以下のキャラクタ間で実行されることを特徴とする、
　請求項１又は２に記載されたゲーム制御装置。
　前記キャラクタには、前記第１の対戦及び前記第２の対戦のうち少なくともいずれかが実行されるためのポイントの値が設定されており、
　前記第１の対戦は、前記ポイントの値が第１の閾値以下のキャラクタ間で実行され、
　前記第２の対戦は、前記ポイントの値が前記第１の閾値よりも小さい第２の閾値以下のキャラクタ間で実行されることを特徴とする、
　請求項１又は２に記載されたゲーム制御装置。
　前記第１の対戦は、前記第１の能力値の合計が第１の閾値以下のキャラクタ間で実行され、
　前記第２の対戦は、前記第１の能力値の合計が前記第１の閾値よりも小さい第２の閾値以下のキャラクタ間で実行されることを特徴とする、
　請求項１又は２に記載されたゲーム制御装置。
　前記キャラクタに複数の種類の能力値が設定されている場合に、前記複数の種類のうち少なくとも一つの種類の能力値が第１の能力値として設定されて構成され、
　前記変更手段は、複数の種類の能力値のうち前記アイテムに応じた第１の能力値を変更することを特徴とする、
　請求項１～５のいずれかに記載されたゲーム制御装置。
　前記変更手段は、前記所定期間が経過したときに、前記キャラクタの第２の能力値を第１の能力値に戻すことを特徴とする、
　請求項１～６のいずれかに記載されたゲーム制御装置。
　前記変更手段は、前記所定時間の経過に伴って、前記キャラクタの能力値を、第２の能力値から第１の能力値に段階的あるいは連続的に遷移させることを特徴とする、
　請求項７に記載されたゲーム制御装置。
　前記第１の対戦及び前記第２の対戦のそれぞれが繰り返し実行される場合に、前記第２の対戦が開始されてから前記第２の対戦が終了するまでの期間は、前記第１の対戦が開始されてから前記第１の対戦が終了するまでの期間より短く設定されることを特徴とする、
　請求項１～８のいずれかに記載されたゲーム制御装置。
　前記変更手段は、前記キャラクタの能力値が前記第２の能力値に変更されている間に前記ユーザが前記アイテムを使用すると、前記所定期間を延長することを特徴とする、
　請求項１～９のいずれかに記載されたゲーム制御装置。
　ユーザ識別情報に対応付けられたキャラクタ間の第１の対戦を実行し、キャラクタに設定された第１の能力値に基づいて第１の対戦の対戦結果を決定するステップと、
　所定の操作入力又はゲームの進行状況に関する情報に基づいて、特定のアイテムをユーザに付与するステップと、
　前記ユーザが前記アイテムを使用すると、当該ユーザのユーザ識別情報に対応するキャラクタの第１の能力値を、第１の能力値よりも高い第２の能力値に所定期間変更するステップと、
　ユーザ識別情報に対応付けられたキャラクタ間の第２の対戦を前記第１の対戦と別に実行し、キャラクタの第２の能力値に基づいて第２の対戦の対戦結果を決定するステップと、
　を備えた、ゲーム制御方法。
　ゲームの実行を制御するために、コンピュータに、
　ユーザ識別情報に対応付けられたキャラクタ間の第１の対戦を実行し、キャラクタに設定された第１の能力値に基づいて第１の対戦の対戦結果を決定する機能、
　所定の操作入力又はゲームの進行状況に関する情報に基づいて、特定のアイテムをユーザに付与する機能、
　前記ユーザが前記アイテムを使用すると、当該ユーザのユーザ識別情報に対応するキャラクタの第１の能力値を、第１の能力値よりも高い第２の能力値に所定期間変更する機能、及び
　ユーザ識別情報に対応付けられたキャラクタ間の第２の対戦を前記第１の対戦と別に実行し、キャラクタの第２の能力値に基づいて第２の対戦の対戦結果を決定する機能、
　を実現させるためのプログラム。
　請求項１２に記載されたプログラムを記録したことを特徴とする、コンピュータ読み取り可能な記録媒体。
　通信端末と、当該通信端末からアクセスされ、前記通信端末によるゲームの実行を制御するサーバと、を含むゲームシステムであって、
　ユーザ識別情報に対応付けられたキャラクタ間の第１の対戦を実行し、キャラクタに設定された第１の能力値に基づいて第１の対戦の対戦結果を決定する第１の対戦実行手段、
　所定の操作入力又はゲームの進行状況に関する情報に基づいて、特定のアイテムをユーザに付与する付与手段、
　前記ユーザが前記アイテムを使用すると、当該ユーザのユーザ識別情報に対応するキャラクタの第１の能力値を、第１の能力値よりも高い第２の能力値に所定期間変更する変更手段、及び、
　ユーザ識別情報に対応付けられたキャラクタ間の第２の対戦を前記第１の対戦と別に実行し、キャラクタの第２の能力値に基づいて第２の対戦の対戦結果を決定する第２の対戦実行手段、
　の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
　ゲームシステム。