JP2023055566A - ゲームシステム、ゲーム制御装置及びプログラム - Google Patents

Abstract

【課題】複数の獲得可能なオブジェクトの中からユーザが獲得を希望するオブジェクトを選択可能なゲームの興趣性を高める。【解決手段】提示手段は複数の前記選択対象のオブジェクトを提示する。獲得手段は提示された複数の前記選択対象のオブジェクトの中からユーザが選択した選択対象のオブジェクトを、ユーザが獲得したオブジェクトとしてユーザのユーザ識別情報に関連付ける。前記提示手段は、前記選択対象のオブジェクトを提示する場合に、前記選択対象のオブジェクトに関連付けられている複数のパラメータの全ては分からないように、前記複数のパラメータの一部に関する情報のみを開示する。【選択図】図１７

Description

本発明はゲームシステム、ゲーム制御装置及びプログラムに関する。

従来より、画面に表示された複数の獲得可能なキャラクタの中から、ユーザが獲得を希望するキャラクタを選択することができるゲームが知られている。ユーザは獲得可能な各キャラクタの能力等のパラメータを画面で確認しながら、獲得したいキャラクタを選択する。

特許第３９４４４６０号公報

上記のゲームでは、ユーザは獲得可能な各キャラクタのランク等のパラメータが分かっているので、相対的にランクの高いキャラクタや人気の高いキャラクタばかりを選択する傾向にあり、ユーザに選択されるキャラクタに偏りが生じる。また、ユーザによるキャラクタの選択は、画面上で各キャラクタのパラメータを見比べながら能力の高いキャラクタを探すだけの単純な作業であり、面白さを感じにくい。

そこで、本発明の目的は、複数の獲得可能なオブジェクトの中からユーザが獲得を希望するオブジェクトを選択可能なゲームの興趣性を高めることができるゲームシステム、ゲーム制御装置及びプログラムを提供することにある。

本発明の一態様によるゲームシステムは、複数の選択対象のオブジェクトの中からユーザによって選択されたオブジェクトが用いられるゲームを提供するゲームシステムであって、複数の前記選択対象のオブジェクトを提示する提示手段と、前記提示手段によって提示された複数の前記選択対象のオブジェクトの中からユーザが選択した選択対象のオブジェクトを、ユーザが獲得したオブジェクトとしてユーザのユーザ識別情報に関連付ける獲得手段と、を含み、前記提示手段は、前記選択対象のオブジェクトを提示する場合に、前記選択対象のオブジェクトに関連付けられている複数のパラメータの全ては分からないように、前記複数のパラメータの一部に関する情報のみを開示する。

本発明の他の一態様によるゲーム制御装置は、複数の選択対象のオブジェクトの中からユーザによって選択されたオブジェクトが用いられるゲームを提供するゲーム制御装置であって、複数の前記選択対象のオブジェクトを提示する提示手段と、前記提示手段によって提示された複数の前記選択対象のオブジェクトの中からユーザが選択した選択対象のオブジェクトを、ユーザが獲得したオブジェクトとしてユーザのユーザ識別情報に関連付ける獲得手段と、を含み、前記提示手段は、前記選択対象のオブジェクトを提示する場合に、前記選択対象のオブジェクトに関連付けられている複数のパラメータの全ては分からないように、前記複数のパラメータの一部に関する情報のみを開示する。

本発明の一実施の形態に係るゲームシステムの構成例を示す概略のブロック図である。 ゲーム端末のハード構成の一例を示す概略のブロック図である。 サーバのハード構成の一例を示す概略のブロック図である。 選手情報画像の一例を示す図である。 イベントモードで実行されるゲームの概要を説明する図である。 ゲームサイクルの一例を説明する図である。 チーム設定画面の一例を示す図である。 試合中の画面画像の一例を示す図である。 スカウト画面画像の一例を示す図である。 球団ランク別抽選確率の一例を示す図である。 眼力ポイント別情報開示確率の一例を示す図である。 野手の寸評情報リストの一例を示す図である。 投手の寸評情報リストの一例を示す図である。 入替対象一覧画面の一例を示す図である。 選手入替確認画面の一例を示す図である。 契約更改画面の一例を示す図である。 ゲームシステムの機能的な構成の一例を示す概略の機能ブロック図である。 ユーザ情報テーブルの一例を示す図である。 キャラクタ情報テーブルの一例を示す図である。 所有キャラクタテーブルの一例を示す図である。 ユーザチームデータの一例を示す図である。 眼力ポイント別情報開示確率の他の例を示す図である。 ゲームシステムの機能的な構成の他の例を示す概略の機能ブロック図である。 ゲームシステムの機能的な構成の他の例を示す概略の機能ブロック図である。 ゲームのトップ画面の一例を示す図である。 ゲームシステムの処理の一例を示すフローチャートである。 スカウト処理の一例を示すフローチャートである。 ゲームシステムの処理の一例を示すフローチャートである。

以下、本発明の実施形態の一例を、図面を参照しながら説明する。

［１．ゲームシステムの構成］
図１は、本発明の実施の形態に係るゲームシステム１の構成例を示す概略のブロック図である。このゲームシステム１は、複数のゲーム端末１０－ｎ（ｎは正の整数。１０－１、１０－２、・・・）と、サーバ３０とを含んでいる。ゲームシステム１内のゲーム端末１０－ｎ及びサーバ３０は、インターネットなどのネットワークＮを介して、相互にデータ通信可能に接続されている。ここで、複数のゲーム端末１０－ｎは同様の構成であるため、特に区別しない場合には、単に「ゲーム端末１０」と記載して説明する。

本実施の形態のネットワークＮは、インターネットに限定されるものではなく、ゲームシステム１内のゲーム端末１０－ｎ及びサーバ３０を通信可能に相互に接続できるものであれば、例えば、専用回線、公衆回線（電話回線、移動体通信回線等）、有線ＬＡＮ（Local Area Network）、無線ＬＡＮ等であってもよく、或いはインターネットとこれらを組み合わせたものであってもよい。

ユーザが操作するゲーム端末１０は、ユーザがゲームをプレイするために使用するコンピュータである。ゲーム端末１０は、例えば、家庭用のゲーム機（据置型又は携帯型）、パーソナルコンピュータ、スマートフォン、携帯電話端末、ＰＨＳ（Personal Handy-phone System）端末、携帯情報端末（ＰＤＡ：Personal Digital Assistant）、タブレット型コンピュータ、多機能型テレビジョン受像機（いわゆるスマートテレビ）、遊戯施設等に設置される業務用（商業用）ゲーム機等である。

サーバ３０は、例えば、サーバコンピュータである。サーバ３０は、各ユーザを一意に識別するためのユーザＩＤと関連付けて、ユーザのゲームに関する情報を、例えばデータベースＤＢに記憶して管理する。データベースＤＢはサーバ３０内に構築されていてもよいし、サーバ３０とは別のサーバコンピュータ内に構築されていてもよい。

また、サーバ３０は、ユーザ間で通信対戦（オンライン対戦）が行われる場合の対戦相手決定処理（いわゆるマッチング処理）等を実行する。通信対戦では、例えば、ゲーム端末１０－１を操作するユーザＡと、ゲーム端末１０－２を操作するユーザＢとが、ネットワークＮを介して対戦ゲームを行うことができる。この通信対戦の場合、例えば、サーバ３０によってマッチングされたゲーム端末１０－１とゲーム端末１０－２との間で、Ｐ２Ｐ（Peer to Peer）接続等により直接通信して対戦する方法がある。あるいは、ゲーム端末１０－１とゲーム端末１０－２との間のデータのやり取りを、サーバ３０を経由して通信対戦する方法もある。何れの方法で通信対戦が行われてもよい。

ゲーム端末１０－ｎとサーバ３０との間の通信は、例えば、ベースのプロトコルとしてＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）上で動作するＨＴＴＰ（Hyper Text Transfer Protocol）を使用し、本システムで規定するアプリケーションプロトコルを上位に実装することによって実現できる。

一方、Ｐ２Ｐ等で接続されるゲーム端末１０－１とゲーム端末１０－２との間の通信は、例えば、ＯＳＩ参照モデルのトランスポート層上の通信規約であって主にＩＰプロトコル上に実装されるＵＤＰ（User Datagram Protocol）によって実現できる。上記のＵＤＰは、データの送達確認やエラー訂正を行わず、データを相手側の端末装置に送りっぱなしにする通信方式であるため、データの信頼度は低いがデータの転送速度が高いという利点がある。なお、ゲーム端末１０－１とゲーム端末１０－２との間の通信にＵＤＰ以外の他の既存プロトコルを用いたり、今後、新たに規定される新規プロトコルを用いたりすることも勿論可能である。

また、例えば、所定の周波数帯（例えば２．４ＧＨｚの周波数帯）を用いた近距離無線通信機能を有するゲーム端末１０－ｎでは、複数台のゲーム端末１０－ｎ間で、直接通信を行って対戦ゲーム等を実行することもできる。

（ゲーム端末のハード構成）
図２は、ゲーム端末１０のハード構成の一例を示す概略のブロック図である。ゲーム端末１０は、主に、ＣＰＵ（Central Processing Unit）１１と、ＲＯＭ（Read Only Memory）１２と、ＲＡＭ（Random Access Memory）１３と、補助記憶装置１４と、通信部１５と、操作部１６と、画像処理部１７と、サウンド処理部１８とを備え、これらはアドレスバス、データバス及びコントロールバス等を含むバスライン１９を介して相互に接続されている。なお、バスライン１９と各構成要素との間には必要に応じてインタフェース回路が介在しているが、ここではインタフェース回路の図示を省略している。また、ゲーム端末１０は、表示部２０及び音声出力部２１を備えている。

ＣＰＵ１１は、ゲームプログラムの命令を解釈して実行し、ゲーム端末１０全体の制御を行う。ＲＯＭ１２は、ゲーム端末１０の基本的な動作制御に必要なプログラムやデータ等を記憶している。ＲＡＭ１３は、各種プログラム及びデータを記憶し、ＣＰＵ１１に対する作業領域を確保する。

補助記憶装置１４は、ゲームプログラムや各種データ等を格納する記憶装置である。補助記憶装置１４としては、例えば、不揮発性の半導体メモリ、ハードディスクドライブ、ソリッドステートドライブ等を用いることができる。

通信部１５は、図示しない通信インタフェースを備え、ゲーム実行時にデータ通信するための通信制御機能を有している。ここで、データ通信用の通信制御機能には、例えば、インターネット接続機能、無線ＬＡＮ（Local Area Network）接続機能、所定の周波数帯（例えば２．４ＧＨｚの周波数帯）を用いた近距離無線通信機能などが含まれる。通信部１５は、ＣＰＵ１１からの命令に基づいてゲーム端末１０をネットワークＮに接続するための接続信号を発信するとともに、通信相手側から送信されてきた情報を受信してＣＰＵ１１へ供給する。

操作部１６は、ユーザが種々の操作命令をゲーム端末１０に入力するためのものである。操作部１６の一例としては、タッチインターフェースを備えた位置入力部（タッチパネルの構成要素）、物理的なボタン、コントローラ、アナログスティック、キーボード、ポインティングデバイス等を挙げることができる。また、マイクロフォン等の音声入力部から入力された音声を識別することにより、音声入力可能な操作部１６として構成してもよい。

画像処理部１７は、ＣＰＵ１１からの画像表示命令に基づいて表示部２０を駆動し、ゲーム画面を表示させる。表示部２０には、液晶ディスプレイや有機ＥＬ（Electro-Luminescence）ディスプレイ等の既知の種々の表示装置が適用できる。また、表示部２０を、液晶ディスプレイ等の表示装置にタッチインターフェースを備えた位置入力部を組み合わせたタッチパネルとすることもできる。表示部２０をタッチパネルとして構成した場合、画像処理部１７は図示しないタッチ入力検出部を備える。このタッチ入力検出部は、指やペン等の指示体が画面に接触したとき、当該画面上の接触位置座標を検出して座標信号をＣＰＵ１１へと供給する。これによって、表示部２０の画面上の接触位置がＣＰＵ１１に認識されるようになっている。表示部２０は、ゲーム装置１０と一体である必要はなく、例えば、ゲーム装置１０に対して外部接続されるテレビジョンモニタ等であってもよい。

サウンド処理部１８は、ＣＰＵ１１からの発音指示に基づいてアナログ音声信号を生成して音声出力部２１に出力する。

（サーバのハード構成）
図３は、サーバ３０のハード構成の一例を示す概略のブロック図である。サーバ３０は、主に、ＣＰＵ３１と、ＲＯＭ３２と、ＲＡＭ３３と、補助記憶装置３４と、通信部３５とを備え、これらはアドレスバス、データバス及びコントロールバス等を含むバスライン３６を介して相互に接続されている。なお、バスライン３６と各構成要素との間には必要に応じてインタフェース回路が介在しているが、ここではインタフェース回路の図示を省略している。

ＣＰＵ３１は、システムソフトウェアやアプリケーションソフトウェアの命令を解釈して実行し、サーバ３０全体の制御を行う。ＲＯＭ３２は、サーバ３０の基本的な動作制御に必要なプログラム等を記憶している。ＲＡＭ３３は、各種プログラム及びデータを記憶し、ＣＰＵ３１に対する作業領域を確保する。補助記憶装置３４は、プログラムや各種データ等を格納する記憶装置である。補助記憶装置３４としては、例えばハードディスクドライブ又はソリッドステートドライブ等を用いることができる。

通信部３５は、図示しない通信インタフェースを備え、ネットワークＮを介した各ゲーム端末１０－ｎとの間の通信を制御する。また、通信部３５は、ネットワークＮに接続されている図示しない他のサーバとの通信も制御するようになっている。例えば、サーバ３０をソーシャルネットワーキングサービス（ＳＮＳ）に組み込んだシステム構成とした場合、サーバ３０の通信部３５は、ＳＮＳサーバとの間の通信を制御する。また、例えば、サーバ３０は、ユーザがプレイしたゲーム動画を、観戦者に配信する動画配信サーバとの間の通信を制御する。なお、サーバ３０に動画配信機能を持たせることもできる。

サーバ３０は、単独のコンピュータで構成することもできるが、サーバ３０の有する各機能を複数のサーバに分散して持たせる機能分散型の構成とすることもできる。あるいは、ネットワークＮ上に複数のサーバ３０を設けて冗長化（多重化）を図ることにより、負荷分散型の構成としてもよい。また、サーバ３０は、クラウドコンピューティング技術を利用したクラウドサーバとして構成されてもよい。

プログラムやデータは、ネットワークＮを介して遠隔地からゲーム端末１０又はサーバ３０に供給されて、ＲＡＭ１３、補助記憶装置１４、ＲＡＭ３３又は補助記憶装置３４に記憶される。なお、情報記憶媒体（例えば光ディスク又はメモリカード等）に記憶されたプログラムやデータを読み取るための構成要素（例えば光ディスクドライブ又はメモリーカードスロット等）がゲーム端末１０又はサーバ３０に備えられてもよい。そして、プログラムやデータが、前記情報記憶媒体を介してゲーム端末１０又はサーバ３０に供給されてもよい。

なお以下では、ゲーム端末１０がタッチパネルを備えたスマートフォン又はタブレット型コンピュータである場合を想定する。

［２．ゲームの一例］
ゲームの一例の概要を、以下に説明する。
ゲームシステム１では、各種ゲームを実行できる。例えば、スポーツゲーム（野球、サッカー、テニス、アメリカンフットボール等を題材としたゲーム）、レースゲーム、格闘ゲーム、戦闘ゲーム、デジタルカードゲーム等、ゲーム形式・ジャンルを問わず様々なゲームを実行できる。なお、ゲームは、ゲーム端末１０がサーバ３０又は他のゲーム端末１０との間でデータ通信を行うことによって実行されてもよいし、ゲーム端末１０単体で実行されてもよい。

例えば、野球ゲームでは、一又は複数のオブジェクト（例えば、ゲームキャラクタ、ゲームカード、又はゲームアイテム等）に基づいて、対戦をはじめとする種々のゲームモードが実行される。以下では、ゲームシステム１で実行されるゲームの一例として、野球を題材とした野球ゲームについて説明し、必要に応じてその他のゲームについても言及する。

ゲーム内で使用可能なキャラクタ（オブジェクトの一例）として実在の野球選手を模した選手キャラクタが提供される。すなわち、実在の野球選手の名前が設定され、かつ、当該野球選手の能力や実績に基づいて能力パラメータが設定された選手キャラクタが提供される。本実施形態の野球ゲームの例では、現実世界の日本のプロ野球１２球団に支配下登録されている全ての野球選手にそれぞれ対応する複数の選手キャラクタが提供される。また、前記プロ野球１２球団で新たに支配下登録される野球選手が生じれば、当該野球選手に対応する選手キャラクタがゲーム内に追加されるようにしてもよい。また、例えば、現役を退いた実在のプロ野球選手に対応する選手キャラクタをゲーム内で使用可能としてもよい。

なお、選手キャラクタは架空の野球選手を示す選手キャラクタであってもよい。また、本実施形態の野球ゲームには、オリジナルの選手キャラクタを育成するゲームモードが搭載されている。この育成モードで育成が完了したオリジナルの選手キャラクタを、実在の野球選手を模した選手キャラクタとともに、種々のゲームモードで使用できるようにしてもよい。

本実施形態の野球ゲームには、様々なゲームモードが搭載されている。その一つは、ユーザがゲーム内で獲得した選手キャラクタを使用して自らの野球チームを編成し、対戦相手チームと試合を行う通常対戦モードである。例えば、ユーザはゲームアイテム又はゲームポイントを使用することによって、選手キャラクタの抽選を行うことができる。選手キャラクタの抽選を行うと、ゲームシステム１で用意された選手キャラクタ群のうちから抽選処理に基づいて選出された選手キャラクタがユーザに付与される。ユーザはこのようにして獲得した選手キャラクタを収集し、収集した選手キャラクタを使用して、通常対戦モード用の野球チームを自ら編成する。そして、ユーザは編成した自らの野球チームを使用して対戦相手チームと試合を行うことができる。

また、定期的に又は不定期で開催されるイベント期間中に、上記通常対戦モード用の野球チームとは別に用意されたイベント専用の野球チームを使用するイベントモードもある。開催されるイベントには様々なものがあるが、その中に、部分的にパラメータに関する情報が隠された選手キャラクタをユーザが推理して選手キャラクタをスカウトで獲得しながらイベント専用の野球チームを強化していくゲームがある。このイベントモードで使用される野球チームおよびユーザが獲得した選手キャラクタは、イベントモードでのみ使用可能であり、イベントモードの開催期間の終了時に、ユーザの所有ではなくなる。このイベントモードの詳細については後述する。

ここで、本実施形態の野球ゲームで使用される選手キャラクタの一例について、以下に説明する。図４は、表示部２０に表示される選手情報画像の一例を示す。図４では、野手の選手キャラクタの選手情報画像Ｇ１００の一例を示している。

図４に示すように、選手情報画像Ｇ１００は選手キャラクタの情報を示す。選手情報画像Ｇ１００は複数のページを含んでおり、パーツＰ１０７を指示することによってページを切り替えることができる。図４に示す例では第１ページが表示されており、他のページには選手キャラクタに関する別の情報が表示される。

選手情報画像Ｇ１００はパーツＰ１０１，Ｐ１０２を含む。パーツＰ１０１は選手キャラクタの画像を示す。パーツＰ１０２は選手キャラクタの名前及びシリーズを示す。図４に示す例では、選手キャラクタの名前が「選手Ｘ」になっているが、実際には実在の野球選手の名前が選手キャラクタの名前として設定される。また、図４に示す例では、選手キャラクタのシリーズが「２０２１年度シリーズ１」になっている。同一選手名の選手キャラクタがシリーズ毎に提供されることがあり、例えば「２０２１年度シリーズ１ 選手名Ｘ」、「２０２０年度シリーズ２ 選手名Ｘ」等が存在する。したがって、同一チーム内に、同一選手名であるが、シリーズが異なる選手キャラクタが存在する場合がある。シリーズの更新毎に、当該野球選手の実績に基づいて能力の変更等が行われる。

また、選手情報画像Ｇ１００はパーツＰ１０３～Ｐ１０６を含む。パーツＰ１０３は選手キャラクタのランクを示す。ランクは選手キャラクタのレアリティを示す。つまり、ランクが高いほど、レアリティが高いことを示す。なお、レアリティが高いほど、選手キャラクタの能力も高くなるため、ランクは選手キャラクタの能力を示すということもできる。例えばランクは、高い方から順に「Ｓ，Ａ，Ｂ，Ｃ，Ｄ」の５段階で示される。なお、同一選手名の選手キャラクタ間でランクが異なることもあり、同一チーム内に、同一選手名であるが、ランクが異なる選手キャラクタが存在する場合がある。また、ランクは例えば「グレード」、「レアリティ」、「希少度」、「レア度」等の他の名称であってもよい。

パーツＰ１０４は選手キャラクタに関連付けられている総合力パラメータを示す。この総合力パラメータは、各選手キャラクタに与えられた数値で、各選手キャラクタの強さを総合的に評価するパラメータである。総合力パラメータを、例えば「スピリッツ」等と称してもよい。

パーツＰ１０５は、選手キャラクタの守備情報、コスト情報、特訓レベル情報、レベル・経験値情報を示す。守備情報は、選手キャラクタのメインポジション（守備位置）と、選手キャラクタの守備力の高さとを示す。メインポジションとは、選手キャラクタの適正ポジションである。例えば、守備力は、高い方から順に「Ｓ，Ａ，Ｂ，Ｃ，Ｄ，Ｅ，Ｆ，Ｇ」の８段階で示される。「Ｓ」は守備力が非常に高いことを示し、「Ｇ」は守備力が非常に低いことを示す。なお、「一Ｄ」という省略表示は、選手キャラクタのメインポジションが「一塁手」であり、選手キャラクタの守備力が「Ｄ」であることを示す。

コスト情報は選手キャラクタのコストを示す。通常対戦モードでは、ユーザは所有している複数の選手キャラクタの中から所定数（例えば２４名）の選手キャラクタを選んでチームを編成する場合、選手キャラクタの合計コストが上限値（チームコスト）を越えないようにしてチームを編成する必要がある。

特訓レベル情報は選手キャラクタの特訓レベルを示す。選手キャラクタの特訓レベルは特訓を行うことによって上昇する。例えば、他の選手キャラクタを消費することによって選手キャラクタを特訓できる。特訓レベルが上昇すると、選手キャラクタの能力パラメータや総合力パラメータが上昇する。なお、「Ｌｖ０／１０」は、選手キャラクタの特訓レベルの上限が「１０」であり、現在の特訓レベルが「０」であることを示す。なお、同名かつ同ランク以上の選手キャラクタを消費することによって、選手キャラクタの上限レベルを上昇できる。例えば、上限レベルは元々の上限レベル＋５まで上昇させることができる。

レベル・経験値情報は選手キャラクタのレベル及び経験値を示す。試合に出場した選手キャラクタには経験値が付与される。経験値が所定値に達すると、選手キャラクタのレベルが上昇する。選手キャラクタのレベルが上昇すると、選手キャラクタの能力パラメータや総合力パラメータが上昇する。なお、「Ｌｖ１／５０」は、選手キャラクタの上限レベルが「５０」であり、現在のレベルが「１」であることを示している。

パーツＰ１０６は、選手キャラクタの弾道パラメータ、ミートパラメータ、パワーパラメータ、及び走力パラメータを示す。弾道パラメータは、選手キャラクタの打球がどの程度高く上がるのかを示す。弾道パラメータの例としては、「アーチスト」、「パワーヒッター」、「高弾道」、「中弾道」、「ラインドライブ」、「低弾道」、「グラウンダー」等がある。ミートパラメータは選手キャラクタのミート力（投手が投げたボールにバットを当てる能力）を示す。パワーパラメータは選手キャラクタのパワー（投手が投げたボールをバットで打つことによって遠くに飛ばす能力）を示す。走力パラメータは選手キャラクタの足の速さを示す。

図４に示す例では、ミートパラメータ、パワーパラメータ、及び走力パラメータの各々について、数値とアルファベットとが表示されている。数値は能力値を示し、アルファベットは能力の高さを示す。能力の高さは、高い方から順に「Ｓ，Ａ，Ｂ，Ｃ，Ｄ，Ｅ，Ｆ，Ｇ」の８段階の能力ランクで示される。例えば、能力ランクと能力値との関係は、Ｓランク（能力値１００以上），Ａランク（能力値８０～９９），Ｂランク（能力値７０～７９），Ｃランク（能力値６０～６９），Ｄランク（能力値５０～５９），Ｅランク（能力値４０～４９），Ｆランク（能力値２０～３９），Ｇランク（能力値１９以下）である。

選手キャラクタには、上記で説明した以外のパラメータも関連付けられている。例えば、守備適性のパラメータが選手キャラクタに関連付けられている。守備適性のパラメータは、メインポジションおよびサブポジションのそれぞれの守備力の値、及び守備力の高さを示す守備適性ランク（例えば、高い方から順に「Ｓ，Ａ，Ｂ，Ｃ，Ｄ，Ｅ，Ｆ，Ｇ」の８段階）を含む。サブポジションとは、メインポジション以外に守備適性のあるサブのポジションである。選手キャラクタによっては、サブポジションが２以上設定されている場合や、サブポジションが１つも設定されていない場合がある。

選手キャラクタに関連付けられているその他のパラメータとしては、例えば、特殊能力パラメータがある。特殊能力の例としては、チャンスに強い（チャンスの際に能力が上昇する）という特殊能力や、左投手に強い（相手投手が左投手である際に能力が上昇する）という特殊能力等がある。

選手キャラクタに関連付けられているその他のパラメータとしては、例えば、選手キャラクタの「利き腕（右投又は左投）」および「打撃スタイル（右打、左打又は左右両打）」のパラメータがある。その他にも、例えば、守備力の高さを示す捕球パラメータ、スローイングパラメータ、肩力パラメータ等がある。図４に例示する選手情報画像Ｇ１００に表示されていないパラメータは、パーツＰ１０７を指示してページを切り替えることにより画面上で確認することができる。

なお、図４は野手の選手キャラクタを示しているが、投手の選手キャラクタの場合には、野手のポジション情報の代わりに投手のポジション情報（例えば、先発、中継ぎ、抑え等）が表示される。また、野手用の能力パラメータの代わりに投手用の能力パラメータ（例えば、球威パラメータ、制球パラメータ、スタミナパラメータ等）が表示される。また、パーツＰ１０７を指示してページを切り替えることにより、投手キャラクタが投球可能な少なくとも１つの球種、球種毎の球速、球種毎のランク（例えば、高い方から順に「Ｓ，Ａ，Ｂ，Ｃ，Ｄ，Ｅ，Ｆ，Ｇ」の８段階）、捕球パラメータ、スローイングパラメータ、肩力パラメータ、特殊能力パラメータ等が画面に表示される。

（イベントモードのゲームの一例）
次に、イベントモードで実行されるゲームの一例を説明する。図５は、イベントモードで実行されるゲームの概要を説明する図である。図５に示すように、本実施形態のゲームは、主に「試合」、「スカウト」、「選手推理」および「オーダー強化」の４つのパートで成り立っている。ゲームの概略の流れを以下に説明する。

イベントモードのゲーム開始時に、ユーザにはイベント専用の野球チームが付与される。ユーザは、付与されたチームを使用して、試合パートでイベント専用試合を実行し、試合の実行結果に応じた「眼力ポイント」を獲得する。一定数の試合（例えば、３試合）を実行すると、「スカウト」と称されるユーザが選手キャラクタを選択的に獲得するための処理が実行される。

上記スカウト処理の実行により、画面には、複数のスカウト候補の選手キャラクタが表示される。スカウト候補の選手キャラクタとは、ユーザのチームへの入団候補の選手キャラクタであり、ユーザが選択的に獲得しうる選手キャラクタである。画面に表示される各スカウト候補の選手キャラクタについては、誰なのか全容が明かされない。すなわち、スカウト候補のキャラクタ画像および名前（名称）が隠されているとともに、能力等のパラメータについての情報も部分的に隠されており、一部のパラメータに関する情報だけが切り抜かれてユーザに開示される。前記試合の実行により獲得した「眼力ポイント」に基づいて、ユーザに開示される各スカウト候補の選手キャラクタに関する情報の詳しさ（精度）が変化する。

選手推理パートでは、ユーザは、開示された各スカウト候補の選手キャラクタに関する情報に基づいて、どの選手キャラクタが強い選手なのかを推理したり、どの選手キャラクタを獲得すればチームの総合力を高めることができるのかを推理して、選手キャラクタを選択して獲得する。以降、上記スカウト処理に基づいてユーザが選手キャラクタを獲得することを「スカウトする」と称する場合がある。ユーザは、スカウトで選手キャラクタを獲得した後に、はじめてどの選手キャラクタだったのかが画面上で確認できるようになる。

上記のように推理パートでスカウトされた選手キャラクタは、ユーザのイベント専用のチームのオーダーに組み込まれることで、チームが強化される（オーダー強化パート）。ユーザは、強化されたチームを使用して、再度、試合パートで試合を実行する。以降も、「試合」、「スカウト」、「選手推理」および「オーダー強化」の４つのパートを順に繰り返し、推理を伴うスカウトで選手キャラクタを獲得しながらチームを強化していく。

例えば、イベントモードにおいて、ユーザは、後述の「合計オーダーポイント」および「累計球団運営ポイント」に応じた報酬を獲得できる。また、例えば、ユーザは後述のミッション（課題）を達成することでも報酬を獲得できる。
以下には、本実施形態のイベントモードのゲームをより詳細に説明する。

（ゲームサイクル）
図６は、イベントモードで実行されるゲームのゲームサイクルの一例を説明する図である。本実施形態のゲームは、野球の試合が１試合実行される毎にゲーム内の仮想的な時間が１ヶ月進行する。図６に示すように、本実施形態のゲームは、１サイクルを１年（１２試合）とし、１年は３ヵ月毎の４シーズン（春→夏→秋→冬）に分けられる。春シーズンは３月～５月、夏シーズンは６月～８月、秋シーズンは９月～１１月、冬シーズンは１２月～２月であり、各シーズン３試合ずつ実行される。ゲームの開始時は３月からスタートする。冬シーズンが終了すると、次の年（次サイクル）の春シーズンに移行し、以降も、３試合毎にシーズンが移行する。ユーザは、イベント期間中であれば何サイクルでもゲームを実行できる。

ユーザのチーム（球団）には、チームの格又は強さを示す要素として「球団ランク」が設定されている。例えば、球団ランクは、ランクが低い方から順に、「弱小」、「普通」、「強豪」、「常勝」、「名門」の５段階で示される。ゲームの開始時は「弱小」ランクである。特定の条件を満たすと球団ランクが上がり、イベントモードのゲームが有利に進められる。例えば、球団ランクは、３月～翌年２月の１年（１サイクル）を通した試合の勝利数で決定される。この場合、ゲーム上の２月の終了時点で「球団ランク改定」というゲーム内イベントが発生する。例えば、１サイクルの試合の勝利数が５勝以下なら「弱小」、６勝以上なら「普通」、８勝以上なら「強豪」、９勝以上なら「常勝」、１０勝以上なら「名門」となる。なお、球団ランクは、１サイクルで１つだけ上がるか、１つだけ下がるか、又は現状維持かが決定される。よって、例えば、「弱小」ランクから１０勝しても、いきなり「名門」ランクにはならない。なお、バリエーションとしては、１サイクルで２段階以上、球団ランクが上昇するようにしてもよい。

試合には、通常の試合と、通常の試合の場合よりも多くの報酬が得られる（例えば、獲得できる球団運営ポイントが２倍になる）ビッグゲームの試合がある。特定の条件を満たすと、通常の試合に代えてビッグゲームの試合が実行される。本実施の形態では、球団ランク「弱小」以上で５月の試合に勝利すると６月の試合がビッグゲームになる。また、球団ランク「強豪」以上で３～８月の試合に４勝以上すると９月の試合がビッグゲームになる。また、球団ランク「強豪」以上で９月のビッグゲームの試合に勝利すると１０月の試合がビッグゲームになる。これらは一例であり、ビッグゲーム発生の特定の条件は任意に設定可能である。なお、ビッグゲームを発生させず、通常の試合だけが実行されるようにしてもよい。

前述のスカウト処理は、図６に例示するように、各シーズン終了後の所定のタイミングで（つまり１サイクルで計４回）実行される。スカウト処理の実行に伴い、ユーザが前述の推理をして獲得した選手キャラクタがユーザのチームのオーダーに組み込まれる。

イベントモードで用いられる全ての選手キャラクタには、契約年数というパラメータが設定されている。契約年数は１年～５年の何れかである。各選手キャラクタの契約年数は秋シーズンの終了（１１月の試合終了）毎に１ずつ減っていく。契約年数が０になった選手キャラクタは、基本的に、ユーザのチームを退団となる。契約年数が０になった選手キャラクタが発生した場合に、「契約更改」というゲーム内イベントが発生する。また、「選手退団」および「選手加入」というゲーム内イベントが発生する可能性がある。これらのゲーム内イベントについては後述する。なお、「契約年数」は、「契約可能年数」又は「残契約年数」と呼称してもよい（以下、「契約年数」を「契約可能年数」又は「残契約年数」と称する場合がある）。

なお、以下の説明では、当シーズン終了後（又は当月の試合終了後）であって次シーズン前（又は次月の試合前）に発生する処理又はゲーム内イベント（スカウト、球団ランク改定、契約更改、選手退団、選手加入等）については、当シーズン中の処理又はゲーム内イベントとして扱う。

（イベントモードの試合パート）
試合パートでは、試合を実行するために必要なポイントであるイベントコストを「１」消費して、イベント専用の試合を１試合実行できる。例えば、イベントコストの最大値は「５」であり、１時間で「１」ずつ自然回復する。なお、回復アイテムの使用等により、自然回復を待たずにイベントコストが瞬時に回復するようにしてもよい。また、バリエーションとしては、イベントコストの消費を条件とせずに、ユーザが何度でも試合を実行できるようにしてもよい。

試合パートで試合を行うにあたり、ユーザに付与されるイベント専用の野球チームは、野手キャラクタ（「捕手」、「一塁手」、「二塁手」、「三塁手」、「遊撃手」、「中堅手」、「右翼手」、「左翼手」の各ポジション１名、「指名打者（ＤＨ：Designated Hitter）」１名および代打４名）、および投手（「先発」５名、「中継」４名、「抑え」１名およびベンチ１名）の合計２４名で構成される。イベントモードのゲーム開始時にユーザに付与される初期イベントオーダーは、全てのユーザで共通の固定のオーダーである。例えば、初期イベントオーダーの２４名の選手キャラクタは、ゲームシステム１で提供される選手キャラクタの中からゲーム運営側が定めたものである。また、初期イベントオーダーの２４名の選手キャラクタは、全てＢランクであり、全てのユーザが同じ条件でゲームをスタートする。

また、イベントモードでユーザが獲得できるスカウト候補の選手キャラクタのランクは、Ｓランク、Ａランク、Ｂランクの何れかである。また、各スカウト候補の選手キャラクタの能力に関するパラメータの状態は、能力パラメータのレベルが最大であり、特訓レベルも最大である等、フルスペック状態である。

なお、通常対戦モードでは、ユーザは所有している複数の選手キャラクタの中から所定数（例えば、２４名）の選手キャラクタを選んでチームを編成する場合、選手キャラクタの合計コストが上限値（チームコスト）を越えないようにしてチームを編成する必要がある。一方、イベントモードでは、ユーザが実際に所有している選手キャラクタではなく、イベントモード期間中だけユーザが所有できるイベント専用の選手キャラクタでチームが構成される。また、イベントモードでは、チームコストの制限はない。よって、ユーザが普段はなかなか獲得できないような選手を、イベントモードでは使う機会を与えることができる。これにより、ユーザに対して使用したことのない選手キャラクタの魅力を伝え、選手キャラクタを実際に所有したいという動機付けができる。

図７は、イベントモードにおいて、チームを編成するためのチーム設定画面の一例を示す図である。図７に示すチーム設定画面Ｇ２００は、ユーザがチームを設定（編成）するための画像である。すなわち、チーム設定画面Ｇ２００は、ユーザのチームに所属する選手キャラクタのポジションを入れ替えるための画像である。

図７に示すように、チーム設定画面Ｇ２００はパーツＰ２０１及びＰ２０２と領域Ａ２０４とを含む。パーツＰ２０１は野手のポジション編成を選択するためのパーツであり、パーツＰ２０２は投手のポジション編成を選択するためのパーツである。図７はパーツＰ２０１が選択された状態を示している。パーツＰ２０１が選択された場合、チームの野手メンバとして登録されている選手キャラクタが領域Ａ２０３に表示される。すなわち、チームの野手メンバとして登録されている複数の選手キャラクタにそれぞれ対応する複数のパーツＰ２０５が領域Ａ２０４に表示される。図７の例では、各パーツＰ２０５内に選手キャラクタの名前が表示されている。なお、図７では省略するが、各パーツＰ２０５に選手キャラクタの画像、ランク又はレベル等が表示されるようにしてもよい。

領域Ａ２０４は、スターティングメンバ用の領域Ａ２０４１と、ベンチメンバ用の領域Ａ２０４２とを含む。領域Ａ２０４１には、スターティングメンバとして登録されている選手キャラクタを示すパーツＰ２０５が表示される。すなわち、ポジション毎に１つのパーツＰ２０５（１名の選手キャラクタ）が関連付けられる。一方、領域Ａ２０４２には、ベンチメンバとして登録されている選手キャラクタを示すパーツＰ２０５が表示される。例えば、パーツＰ２０５を他のパーツＰ２０５にドラッグアンドドロップすることによって、選手キャラクタのポジションを入れ替えたり、スターティングメンバとベンチメンバの間で選手キャラクタを入れ替えたりすることができる。

パーツＰ２０２が選択された場合、チームの投手メンバとして登録されている選手キャラクタが領域Ａ２０４に表示される。この場合の領域Ａ２０４には、先発投手メンバ、中継投手メンバ、及び抑え投手メンバとして登録されている選手キャラクタが表示される。ユーザは先発投手メンバ、中継投手メンバ、及び抑え投手メンバの間で選手キャラクタを入れ替えたり、先発投手メンバ、中継投手メンバ、又は抑え投手メンバとして登録されている選手キャラクタをベンチの選手キャラクタと入れ替えたりすることもできる。

また、チーム設定画面Ｇ２００はパーツＰ２０３も含む。パーツＰ２０３はチーム総合力値を示す。チーム総合力値は、チームのメンバとして登録されている各選手キャラクタの総合力パラメータに基づいて、所定の算出処理を実行することによって算出される。例えば、チーム総合力値は、チームのメンバとして登録されている２４名の選手キャラクタの総合力パラメータの合計である。あるいは、チーム総合力値は、例えば、チーム内の一部の選手キャラクタ（例えば、先発メンバーの選手のみ等）の総合力パラメータに基づいて算出されるようにしてもよい。

なお、選手キャラクタのメインポジションとは異なるポジションに設定した場合は、ポジション不適正のペナルティが発生する。例えば、メインポジション「一塁手」の選手キャラクタを、一塁手以外の守備位置に配置すると、ポジション不適正のペナルティで、ポジション不適正がない場合よりも、当該選手キャラクタの総合力パラメータの値が低下する。これにより、チーム総合力値も、ポジション不適正がない場合よりも減少する。一例を挙げると、Ｓランクの選手キャラクタでも、ポジション不適正があればＡランクの選手キャラクタよりも低い総合力パラメータの値になってしまう。なお、例えば、サブポジションのポジション適性がＢランク以上の選手キャラクタに限り、当該選手キャラクタをサブポジションの守備位置に配置しても、ポジション不適正のペナルティが発生しないようにしてもよい。

よって、ユーザは、チームを構成する各選手キャラクタのポジションを考慮してチーム設定を行うことを要求される。また、ユーザは、スカウトで選手キャラクタを獲得する場合にも、ポジションの重複を考慮して、どの選手キャラクタを獲得するのかを検討することを要求される。

また、チーム設定画面Ｇ２００はパーツＰ２０７も含む。パーツＰ２０７は合計オーダーポイントを示す。合計オーダーポイントは、チームのメンバとして登録されている２４名の選手キャラクタのオーダーポイントの合計である。選手キャラクタのオーダーポイントは、当該選手キャラクタのパラメータに基づいて、所定の算出処理を実行することによって算出される。例えば、野手キャラクタのオーダーポイントは、ミートパラメータ値、パワーパラメータ値、走力パラメータ値、選手ランク及び総合力パラメータ値に基づいて算出される。また、例えば、投手キャラクタのオーダーポイントは、球威パラメータ値、制球パラメータ値、スタミナパラメータ値、選手ランク及び総合力パラメータ値に基づいて算出される。選手キャラクタの各能力値、選手ランク及び総合力パラメータ値が高いほど、オーダーポイントは高くなる。例えば、合計オーダーポイントに応じてユーザに報酬が付与される。また、合計オーダーポイントが向上すると、後述する球団運営ポイントが獲得しやすくなる。なお、合計オーダーポイントは、例えば、チーム内の一部の選手キャラクタ（例えば、先発メンバーの選手のみ等）のオーダーポイントに基づいて算出されるようにしてもよい。

さらに、チーム設定画面Ｇ２００は、パーツＰ２０８、Ｐ２０９及びＰ２１０も含む。パーツＰ２０８は打順を設定するためのパーツである。パーツＰ２０８が選択された場合に、打順を設定するための画像が表示部２０に表示される。パーツＰ２０９はチームのデータをセーブするためのパーツである。パーツＰ２０９が選択された場合に、ユーザによって設定されたチームのデータがデータベースＤＢ（又は補助記憶装置１４，３４等）に保存される。パーツＰ２１０は、イベントモードのトップ画面に遷移するためのパーツである。

ユーザは以上のようにして設定した自らのチーム（以下「ユーザチーム」と記載する。）を使用して対戦相手チームと試合を行うことができる。対戦相手については、例えば、ユーザチームのチーム総合力値と同程度のチーム総合力値を有する対戦相手チームがマッチングされる。

本実施形態に係る野球ゲームは、下記に説明するような「自動進行パート」及び「アクションパート」の二つのパートを備えている。

自動進行パートは、試合が自動的に進行するパートである。すなわち、自動進行パートでは、ユーザが攻撃時の打撃操作・走塁操作や守備時の投球操作・守備操作を行うことなく、試合状況が更新されていく。言い換えれば、自動進行パートでは、ユーザチームに関するパラメータ（例えば、ユーザチームの選手キャラクタの能力パラメータ等）と、対戦相手チームに関するパラメータ（例えば、対戦チームの選手キャラクタの能力パラメータ等）とに基づいて、試合経過がコンピュータによって自動的に生成（決定）される。自動進行パートでは、ユーザはコンピュータによって自動的に生成される試合経過を見ることになる。

一方、アクションパートは、ユーザが攻撃時の打撃操作・走塁操作や守備時の投球操作・守備操作を行うパートである。すなわち、アクションパートでは、ユーザの操作に応じて選手キャラクタが動作を行う。例えば、攻撃時であれば、ユーザの操作（打撃操作又は走塁操作）に応じて選手キャラクタが打撃又は走塁を行い、守備時であれば、ユーザの操作（投球操作又は守備操作）に応じて選手キャラクタが投球又は守備を行う。このように、アクションパートでは、選手キャラクタに対するユーザの操作に基づいて試合状況が更新されていく。

実施形態に係る野球ゲームでは、基本的に試合が自動進行パートで進行し、試合経過の概要（試合のポイント）のみを画面に表示するようになっている。そして、自動進行パート中で試合状況が所定状況になった場合に限って、自動進行パートからアクションパートに切り替わり、選手キャラクタに対する操作を行うことが可能な操作機会をユーザに提供するようになっている。

上記の「所定状況」とは、例えば、ユーザチームにとって得点チャンスの状況（例えば、ユーザチームの攻撃時で三塁又は二塁に走者がいる状況）、ユーザチームにとって得点チャンスを作りやすい状況（例えば、ユーザチームの攻撃時でノーアウト・走者なしの状況）、又はユーザチームにとって失点ピンチの状況（例えば、対戦相手チームの攻撃時で三塁又は二塁に走者がいる状況）等である。

一つの試合では予め定められた回数の操作機会がユーザに提供される。例えば、一つの試合中に３回の操作機会がユーザに提供される。この場合、例えば、１回表～３回裏のイニング間で１回の操作機会が提供され、４回表～６回裏のイニング間で１回の操作機会が提供され、７回表～９回裏のイニング間で１回の操作機会が提供される。なお、一つの試合における操作機会の回数は上記例に限られず、２回以下であってもよいし、４回以上であってもよい。また、一つの試合における操作機会の回数は固定でなくてもよく、試合毎に変化するようにしてもよい。操作機会の発生タイミングも上記例に限られない。アクションパートが終了した場合には、アクションパートから自動進行パートへと切り替わり、再び試合が自動的に進行する。

アクションパートでのユーザの操作に基づく選手キャラクタの活躍（成績）の程度に応じて（換言すれば、ユーザの操作に基づくゲームの結果に応じて）、活躍ポイントが蓄積される。打撃操作に基づくゲームの結果と、活躍ポイントとの関係は、例えば、アウト「０」、四球「１５０」、シングルヒット「２５０」、２塁打「３００」、３塁打「３５０」、本塁打「５００」等である。また、投球操作に基づくゲームの結果と、活躍ポイントとの関係は、例えば、被安打「０」、アウト「２５０」、奪三振「３００」、ダブルプレー「３５０」等である。一つの試合中に蓄積された活躍ポイントの累計は、各アクションパートの終了後に画面に表示される活躍ゲージで確認できる。なお、試合に勝利した場合は、蓄積された活躍ポイントの累計をそのまま獲得できるが、試合に負けた場合（又は引き分けた場合）は、獲得した活躍ポイントが削減されるようにしてもよい。例えば、引き分けた場合１０％削減、１点差負けの場合２０％削減、２点差で負けの場合３０％削減、…等である。

図８は、試合中の画面画像の一例を示す図である。図８に示すように、試合中の画面画像Ｇ３００はパーツＰ３０１、Ｐ３０２およびＰ３０３を含んでいる。パーツＰ３０１は、ユーザチームのチーム名（Ａチーム）を示し、パーツＰ３０２は、対戦相手チームのチーム名（Ｂチーム）を示す。また、パーツＰ３０３は、ユーザチームのチーム総合力値と対戦相手チームのチーム総合力値との間の比較（大小，高低）を示す。また、パーツＰ３０３の左端に関連付けて表示された数値（３８５００）は、ユーザチームのチーム総合力値を示している。一方、パーツＰ３０３の右端に関連付けて表示された数値（３６７００）は、対戦相手チームのチーム総合力値を示している。

また、試合中の画面画像Ｇ３００は、パーツＰ３０４およびＰ３０５を含んでいる。パーツＰ３０４は、活躍ポイントの累計を示し、パーツＰ３０５は、活躍ポイントの累計を視覚化した活躍ゲージである。一つの試合中に獲得した活躍ポイントの累計に応じて、ユーザには「眼力ポイント」が付与される。例えば、一つの試合中の活躍ポイントの累計が２００ポイント以上で眼力ポイント「＋１ポイント」、５００ポイント以上で眼力ポイントがさらに「＋１ポイント（合計２ポイント）」、７００ポイント以上で眼力ポイントがさらに「＋１ポイント（合計３ポイント）」が付与される。

図８に示すパーツＰ３０５の活躍ゲージには、報酬としての眼力ポイントを獲得するために必要な活躍ポイントの量に対応する位置に関連付けて、報酬画像Ｐ３０５１，Ｐ３０５２，Ｐ３０５３が表示される。図８の例では、報酬画像Ｐ３０５１，Ｐ３０５２，Ｐ３０５３が２００，５００，７００ポイントのそれぞれに対応する位置に表示されており、ユーザの活躍ポイントの累計が２００，５００，７００ポイントになった場合にユーザに報酬が付与されることが示されている。また、図８の例では、２００ポイントに対応する位置に関連付けて表示されていた報酬画像Ｐ３０５１に重ねて、ユーザによって報酬が獲得されたことを示す獲得画像Ｐ３０５４が表示されている。これは、ユーザの活躍ポイントの累計が２００ポイントに達したことによって、眼力ポイントがユーザに付与されたことを示している。

本実施形態では、一つの試合で獲得できる眼力ポイントの最大は「３ポイント」である。ここで、眼力ポイントは、各シーズンの終了後に実行されるスカウトにおいて、ユーザに開示される各スカウト候補の選手キャラクタに関する情報の詳しさ（精度）に影響を及ぼすゲーム要素である。一つのシーズン中、試合毎にユーザが獲得した眼力ポイントは蓄積される。本実施形態では一つのシーズンの試合数は３であるため、一つのシーズンで獲得できる眼力ポイントの最大は「９ポイント」である。眼力ポイントは、シーズン毎にリセットされ、シーズンの開始時は０ポイントからスタートする。

また、一つの試合が終了すると、ユーザには「球団運営ポイント」が付与される。球団運営ポイントは、試合の勝敗結果、ユーザチームの２４名の選手キャラクタの能力値、試合で獲得した活躍ポイント、球団ランクおよびビックゲームか否か等に基づいて、所定の算出処理を実行することによって算出される。この球団運営ポイントは、イベント期間を通して累計される。そして、累計球団運営ポイントに応じて、ユーザに報酬（例えば、アイテム、ゲーム内通貨等）が付与される。

（スカウトパート）
次に、イベントモードのスカウトパートについて説明する。本実施形態のゲームでは、前述のとおり各シーズン３試合ずつ試合が実行され、各シーズン終了後（すなわち、各シーズンの最後の試合の終了後）に、スカウト処理が実行される。

図９は、スカウト処理が実行されたことにより表示部２０に表示されるスカウト画面画像Ｇ４００の一例を示す図である。スカウト画面画像Ｇ４００には、ユーザが獲得可能な複数のスカウト候補の選手キャラクタに関する情報が表示される。図９では、３つのスカウト候補表示領域Ａ４０１が設けられ、３人のスカウト候補の選手キャラクタに関する情報が表示されている例を示している。

ここで、スカウト処理によりユーザに提示される（画面に表示される）スカウト候補の選手キャラクタの人数は、スカウト候補がユーザに提示される前に実行されたゲームの実行結果に基づいて変化する。本実施形態では、スカウト処理が実行されるシーズン中に実行された３試合（すなわち、スカウト処理の直前の３試合）の結果に基づいて、ユーザに提示されるスカウト候補の選手キャラクタの人数が２人～５人の範囲で変化する。具体的には、１回のスカウト処理で最低２人のスカウト候補が画面に表示される。そして、対象シーズン中の試合で１勝する毎にスカウト候補が１人ずつ追加される。つまり、対象シーズン中の勝利数０なら２人、勝利数１なら３人、勝利数２なら４人、勝利数３なら５人のスカウト候補の選手キャラクタがユーザに提示される。

なお、図９のスカウト画面画像Ｇ４００に表示しきれないスカウト候補の選手キャラクタの情報が存在する場合、ユーザが画面をスクロールする操作を行うことにより、表示されていなかったスカウト候補表示領域Ａ４０１が表示される。

また、１回のスカウト処理あたり、ユーザが獲得可能な選手キャラクタの人数（スカウト可能人数）は、球団ランクによって異なる。本実施形態の例では、球団ランクが「弱小」または「普通」の場合は２人であり、「強豪」、「常勝」または「名門」の場合は３人である。前述のとおり、球団ランクは１年（１サイクル）を通した試合の勝利数で決定されるので、スカウト処理前のゲームの実行結果に基づいて、ユーザが獲得可能な選手キャラクタの人数が変化するといえる。

ところで、本実施形態の例では、上述のとおり、ユーザに提示されるスカウト候補の選手キャラクタの人数が２人～５人であり、ユーザが獲得可能な選手キャラクタの人数が２人～３人である。よって、ユーザに提示されるスカウト候補の選手キャラクタの人数が、獲得可能な選手キャラクタの人数を下回る場合も生じうる。この場合、ユーザが獲得可能な選手キャラクタの人数は、ユーザに提示されるスカウト候補の選手キャラクタの人数が上限となる。

スカウト候補対象の選手キャラクタ群は、例えば、ゲーム運営側により予め定められている。本実施の形態では、最新シリーズのプロ野球の現役選手に対応する選手キャラクタがスカウト候補対象の選手キャラクタ群として管理されている。本実施の形態では、スカウト候補対象の選手キャラクタのランクは、Ｂランク、Ａランク又はＳランクの何れかである。なお、スカウト候補対象の選手キャラクタのランクはこれに限らず、例えば、Ｃランク以下を含めてもよい。

本実施の形態では、図６に示すように、１年（１サイクル）の中で５月、８月、１１月および２月の４回、スカウト処理が実行される。５月、８月および２月に実行されるスカウト処理では、契約年数１年～５年の何れかの選手キャラクタがスカウト候補として登場する。一方、１１月に実行されるスカウト処理では、契約年数３年～５年の何れかの選手キャラクタがスカウト候補として登場する。つまり、１１月に実行されるスカウト処理では、契約年数１年～２年の選手キャラクタはスカウト候補として登場しない。これは一例であり、契約年数の範囲は上記に限定されない。例えば、どのタイミング（実行月）のスカウト処理でも契約年数の範囲は同じ（例えば、２年～６年等）としてもよいし、スカウト処理のタイミング（実行月）によって契約年数の範囲が異なっていてもよい。

また、本実施の形態では、ユーザチームのオーダー内のメンバと同名の選手キャラクタは、スカウト候補として選出されない。また、ユーザチームのオーダー内のメンバと同名であれば、ランクが異なっていてもスカウト候補として選出されない。これは一例であり、ユーザチームのオーダー内のメンバと同名の選手キャラクタがスカウト候補として選出されるようにしてもよい。

スカウト画面画像Ｇ４００に表示されることでユーザに提示される各スカウト候補の選手キャラクタは、スカウト候補対象の選手キャラクタ群の中から確率に基づいて決定される。本実施の形態では、ユーザチームの球団ランクによって、スカウト候補の選手キャラクタのランク別の抽選確率が変わる。図１０に、球団ランク別抽選確率の一例を示す。図１０は、球団ランクと、スカウト候補の選手キャラクタのランク別の抽選確率と、の関係を示すデータテーブルである。図１０の例では、球団ランクが最低の「弱小」の場合、スカウト候補として選出される選手キャラクタのランク別抽選確率は、Ｂランク＝６０％、Ａランク＝３０％、Ｓランク＝１０％となる。球団ランクが高くなるほど、Ｂランクの抽選確率は低下する一方、Ｓランクの抽選確率は高くなる。球団ランクが最高の「名門」の場合、スカウト候補として選出される選手キャラクタのランク別抽選確率は、Ｂランク＝０％、Ａランク＝５０％、Ｓランク＝５０％となる。

図９のスカウト画面画像Ｇ４００の各スカウト候補表示領域Ａ４０１には、パーツＰ４０２～Ｐ４０７が表示される。パーツＰ４０２は、スカウト候補の選手キャラクタの実際の画像の代わりに表示されるシルエット画像、および実際の選手名の代わりに表示される仮の選手名（「選手１」、「選手２」、…）を示す。すなわち、スカウト画面画像Ｇ４００内には、選手キャラクタの画像および選手名（名称）が表示されないので、ユーザは提示された選手キャラクタがどの選手キャラクタなのかが直接的には分からない。すなわち、本実施の形態では、選手キャラクタが実在のプロ野球選手に対応しているので、ユーザはスカウト画面画像Ｇ４００上に提示された各スカウト候補が、それぞれどのプロ野球選手に対応している選手キャラクタなのかがわからない。

上記シルエット画像は、例えば、全てのスカウト候補に共通の画像であってもよいし、野手キャラクタと投手キャラクタとで別のシルエット画像を用いてもよい。野手キャラクタと投手キャラクタとで別のシルエット画像を用いる場合、ユーザは提示されたスカウト候補が野手であるか投手であるかは分かるが、選手キャラクタを特定するには到らない。なお、スカウト候補の選手キャラクタが直接的に特定できなければ、シルエット画像でなくてもよい。例えば、シルエット画像に代えて、どの選手か分からないようなイラスト画像等であってもよい。あるいはパーツＰ４０２からシルエット画像を省いてもよい。

また、仮の選手名の表示も、「選手１」、「選手２」、…という表示に限らず、実際の選手名が分からないような表示であれば、その他の文字や記号を使用してもよい。あるいはパーツＰ４０２から仮の選手名の表示を省いてもよい。

パーツＰ４０３～Ｐ４０６は、スカウト候補の選手キャラクタの全てのパラメータのうち、ユーザに開示され得る開示対象パラメータに関する情報を表示する領域である。

パーツＰ４０３は、スカウト候補の選手キャラクタのメインポジションの情報を示す。本実施の形態では、メインポジションの情報は常に開示される開示対象パラメータである。なお、バリエーションとしては、メインポジションの情報は、確率に基づいて開示の有無が決定される等、開示の有無が変化するようにしてもよい。

パーツＰ４０４は、スカウト候補の選手キャラクタのランクの情報を示す。パーツＰ４０５は、スカウト候補の選手キャラクタの契約年数（契約可能年数）の情報を示す。パーツＰ４０６は、スカウト候補の選手キャラクタに関する寸評情報を示す。パーツＰ４０６には、寸評情報として、「寸評１」、「寸評２」および「寸評３」の３つの表示スペースが確保されている。図９の例では、パーツＰ４０６には、「寸評１」、「寸評２」および「寸評３」を表示するための３行分の寸評欄が設けられている。よって、１人のスカウト候補の選手キャラクタに対して、最大で３つの寸評情報が表示されうる。寸評情報の詳細は後述する。パーツＰ４０４～Ｐ４０６に表示される各情報は、確率に基づいて開示の有無が決定される開示対象情報である。すなわち、パーツＰ４０４～Ｐ４０６のランク、契約年数、寸評１～寸評３の各情報は、開示される場合と開示されない場合とがある開示有無変化情報である。

パーツＰ４０４～Ｐ４０６に表示されうるランク、契約年数、寸評情報（寸評１～寸評３）の各情報が開示される確率は、スカウト処理が実行されるシーズン中にユーザが獲得した眼力ポイントに応じて変化する。上述のとおり、一つのシーズンで獲得できる眼力ポイントは０～９ポイントである。図１１に、眼力ポイント別情報開示確率の一例を示す。図１１は、眼力ポイントと、開示有無変化情報の開示確率と、の関係を示すデータテーブルである。例えば、眼力ポイント＝０の場合、選手キャラクタのランクの情報は２５％、契約可能年数の情報は４０％、寸評情報（寸評１～寸評３のそれぞれ）は１０％の確率で開示される（すなわち、スカウト画面画像Ｇ４００に表示される）。また、例えば、眼力ポイント＝６の場合、選手キャラクタのランクの情報は１００％、契約可能年数の情報は１００％、寸評１～寸評３の情報はそれぞれ７０％の確率で開示される。

図１１の例では、選手キャラクタのランクの情報は、眼力ポイントが高いほど開示確率が高くなり、眼力ポイントが３以上で１００％開示される。また、契約可能年数の情報は、眼力ポイントが高いほど開示確率が高くなり、眼力ポイントが６以上で１００％開示される。また、寸評情報（寸評１～寸評３）は、眼力ポイントが高いほど開示確率が高くなり、眼力ポイント＝９で１００％開示される。すなわち、眼力ポイントに応じて、スカウト候補の選手キャラクタのパラメータに関する情報の開示量が変化する。換言すれば、眼力ポイントに応じて、スカウト候補に関する情報の開示の詳しさが変化する。眼力ポイントが高いほど、スカウト候補の選手キャラクタのパラメータに関する情報として、より詳しい情報が開示される又は開示され易くなる。

図１２は、野手の寸評情報テーブルＴＢＬ１０４の一例を示す図である。寸評情報テーブルＴＢＬ１０４は、スカウト候補が野手の選手キャラクタの場合において、寸評情報として表示され得る情報のリストである。寸評情報テーブルＴＢＬ１０４は、「寸評ＩＤ」、「寸評名」、「表示例」及び「説明」のフィールドを含む。「寸評ＩＤ」フィールドは、寸評情報を一意の識別するための識別情報を示す。「寸評名フィールド」は各寸評情報につけられた名称を示す。「表示例」フィールドは、スカウト画面画像Ｇ４００に表示される具体的な情報の一例を示す。「説明」フィールドは、寸評情報の内容の説明を示す。なお、「表示例」及び「説明」のフィールドは省略してもよい。

図１２の例では、６つの寸評情報がリストに登録されており、６つの寸評情報の中から選ばれた最大で３つの寸評情報が、スカウト画面画像Ｇ４００のパーツＰ４０６に表示される可能性がある。

野手の寸評情報「〇投〇打」は、スカウト候補の選手キャラクタの「利き腕（右投又は左投）」及び「打撃スタイル（右打、左打又は左右両打）」のパラメータに関する情報である。例えば、スカウト候補の選手キャラクタの利き腕が右投、且つ、打撃スタイルが左打の場合、表示例のように、「右投左打」と表示される。

野手の寸評情報「得意分野」は、スカウト候補の選手キャラクタの能力パラメータに関する情報である。寸評情報「得意分野」は、野手の３つの能力（ミート、パワー、走力）のうち最も能力値が高い能力が選ばれて、「・・・に定評がある」と表示される。例えば、スカウト候補の選手キャラクタの能力のうち最も能力値が高い能力がパワーであった場合、表示例のように、「ミートに定評がある」と表示される。なお、最も能力値が高い能力が同値で複数存在する場合、例えば、ミート＞パワー＞走力の優先順が適用される。あるいは、同値の複数の能力の中からランダムに１つ選択してもよい。あるいは、同値の複数の能力を何れも寸評情報「得意分野」に表示するものとしてもよい（表示例：ミートとパワーに定評がある）。

野手の寸評情報「能力ランク」は、スカウト候補の選手キャラクタの能力ランクのパラメータに関する情報である。野手の３つの能力（ミート、パワー、走力）からランダムに１つ抽選され、抽選で選ばれた１つの能力の具体的な能力ランクが表示される。例えば、表示例のように「パワーＡ」と表示される。

野手の寸評情報「メイン守備適性」は、スカウト候補の選手キャラクタのメインポジションのパラメータに関する情報である。寸評情報「メイン守備適性」として、具体的なメインポジションの守備適性ランクが表示される。例えば、スカウト候補の選手キャラクタのメインポジションが「中堅手」でありその守備適性が「Ｂランク」であった場合、表示例のように、「中堅手適性Ｂ」と表示される。

野手の寸評情報「サブポジ状況」は、スカウト候補の選手キャラクタのサブポジションのパラメータに関する情報である。スカウト候補の選手キャラクタがサブポジションを１つ以上所持している場合、最も守備適性が高いサブポジションが選ばれて、「・・・もできる」と表示される。例えば、スカウト候補の選手キャラクタが「右翼手」を含むサブポジションを所有し、最も守備適性が高いサブポジションが「右翼手」であった場合、表示例のように、「右翼手もできる」と表示される。なお、サブポジションがない場合は、「サブポジなし」と表示される。

野手の寸評情報「弾道」は、スカウト候補の選手キャラクタの弾道のパラメータに関する情報である。例えば、スカウト候補の選手キャラクタの弾道のパラメータが、高角度高スピンの弾道である「アーチスト」の場合、表示例のように、「アーチスト」と表示される。

図１３は、投手の寸評情報テーブルＴＢＬ１０５の一例を示す図である。寸評情報テーブルＴＢＬ１０５は、スカウト候補が投手の選手キャラクタの場合において、寸評情報として表示され得る情報のリストである。寸評情報テーブルＴＢＬ１０５は、寸評情報テーブルＴＢＬ１０４と同様に、「寸評ＩＤ」、「寸評名」、「表示例」及び「説明」のフィールドを含む。

投手の寸評情報「〇投〇打」は、前述の野手の寸評情報「〇投〇打」と同様である。

投手の寸評情報「得意分野」は、スカウト候補の選手キャラクタの能力パラメータに関する情報である。寸評情報「得意分野」は、投手の３つの能力（球威、制球、スタミナ）のうち最も能力値が高い能力が選ばれて、「・・・に定評がある」と表示される。例えば、スカウト候補の選手キャラクタの能力のうち最も能力値が高い能力が「球威」であった場合、表示例のように、「球威に定評がある」と表示される。なお、最も能力値が高い能力が同値で複数存在する場合、例えば、球威＞制球＞スタミナの優先順が適用される。あるいは、同値の複数の能力の中からランダムに１つ選択してもよい。あるいは、同値の複数の能力を何れも寸評情報「得意分野」に表示するものとしてもよい（表示例：制球とスタミナに定評がある）。

投手の寸評情報「能力ランク」は、スカウト候補の選手キャラクタの能力ランクのパラメータに関する情報である。投手の３つの能力（球威、制球、スタミナ）からランダムに１つ抽選され、抽選で選ばれた１つの能力の具体的な能力ランクが表示される。例えば、表示例のように「スタミナＡ」と表示される。

投手の寸評情報「サブポジ状況」は、スカウト候補の選手キャラクタのサブポジションのパラメータに関する情報である。スカウト候補の選手キャラクタがサブポジションを１つ以上所持している場合、最も守備適性が高いサブポジションが選ばれて、「・・・もできる」と表示される。例えば、スカウト候補の選手キャラクタが「中継ぎ」を含むサブポジションを所有し、最も守備適性が高いサブポジションが「中継ぎ」であった場合、「中継ぎもできる」と表示される。なお、サブポジションがない場合は、表示例のように、「サブポジなし」と表示される。

投手の寸評情報「球速」は、スカウト候補の選手キャラクタの球種および球速のパラメータに関する情報である。例えば、球種についてはストレート系の球種が選択され、当該球種の球速の情報が併せて表示される。例えば、スカウト候補の選手キャラクタの球種「ストレート」の球速が「１６１ｋｍ／ｈ」の場合、表示例のように、「ストレート１６１ｋｍ／ｈ」と表示される。なお、選択される球種はストレート系に限定されるものではない。例えば、スカウト候補の選手キャラクタに関連付けられている全ての球種からランダムに選択された球種および当該球種の球速が、寸評情報「球速」として表示されてもよい。

投手の寸評情報「決め球」は、スカウト候補の選手キャラクタの球種のパラメータに関する情報である。寸評情報「決め球」は、スカウト候補の選手キャラクタに関連付けられている全ての球種のうち、最も変化量の大きい球種が選ばれて、「決め球は・・・」と表示される。例えば、スカウト候補の選手キャラクタにおける最も変化量の大きい球種が「フォーク」であった場合、表示例のように、「決め球はフォーク」と表示される。なお、最も変化量の大きい球種が同値で複数存在する場合、球種ランクの高い方が表示される。あるいは、同値の複数の球種の中からランダムに１つ選択してもよい。あるいは、同値の複数の球種を何れも寸評情報「決め球」に表示するものとしてもよい（表示例：決め球はフォークとスライダー）。

図１２又は図１３の例では、スカウト候補の選手キャラクタ１人あたり、６つの寸評情報が登録されている。一方、スカウト画面画像Ｇ４００のスカウト候補表示領域Ａ４０１には、最大で３つの寸評情報（寸評１～寸評３）を表示する枠（３行の欄）が設けられている。よって、６つの寸評情報の中から選ばれた最大で３つの寸評情報が、スカウト画面画像Ｇ４００のパーツＰ４０６に表示される可能性がある。図１２又は図１３のリストからどの寸評情報が選ばれて表示されるかについて、以下に説明する。

スカウト画面画像Ｇ４００に提示されるスカウト候補の選手キャラクタ１人ずつに対して、次の処理が行われる。図９のスカウト候補表示領域Ａ４０１の寸評１～寸評３に表示されうる３つの寸評情報を、図１２又は図１３の６つの寸評情報の中からランダムに（すなわち等確率で）抽選して決定する。この場合、寸評ＩＤが同じ寸評情報が重複して選ばれることはない。つまり、同一の寸評情報が、１人のスカウト候補のパーツＰ４０６内に重複して２箇所表示されることはない。

次に、上記で決定された３つの寸評情報のそれぞれに対して、図１１の眼力ポイント別情報開示確率を適用し、開示するか否かを抽選により決定する。例えば、眼力ポイントが「２ポイント」の場合、「３０％」の開示確率が適用される。この場合、上記３つの寸評情報のそれぞれに対して、３０％の確率でパーツＰ４０６に表示するか否かが抽選で決定される。

なお、上記では、スカウト候補の選手キャラクタ１人ずつの処理として、先ず６つの寸評情報の中から３つの寸評情報をランダムに選択し、選択された３つの寸評情報のそれぞれに対して、図１１の眼力ポイント別情報開示確率を適用し、開示するか否かを抽選により決定する例を説明した。スカウト候補が複数人の場合、その人数分同じ処理が実行される。これに限定されるものではなく、次の例のようにしてもよい。例えば、３人のスカウト候補が提示される場合、３人×３枠で最大９枠の寸評情報の開示枠がある。そこで、先ず、最大９枠のうちの何枠分を開示するかを、図１１の眼力ポイント別情報開示確率を適用し、抽選により決定する。例えば、眼力ポイントが「２ポイント」の場合、「３０％」の開示確率が適用される。そこで、３０％の確率で９回の抽選を行い、当該抽選に当選した回数を開示する合計の枠数として決定する。この抽選により、例えば、合計の開示枠が４枠に決定されたものとして説明を続ける。この場合、３人のスカウト候補に対して４枠をランダムに振り分ける。例えば、３人のスカウト候補の何れに振り分けるかを等確率で１枠ずつ抽選し、当該抽選を４回繰り返す。これにより、例えば、スカウト候補の「選手１」に１枠、「選手２」に３枠、「選手３」に０枠が振り分けられるといったように、スカウト候補によって開示される枠数が異なることがある。その後、振り分けられた各枠に表示する寸評情報を、図１２又は図１３の６つの寸評情報の中からランダムに決定する。なお、この場合、１人のスカウト候補のパーツＰ４０６内に寸評ＩＤが同じ寸評情報が重複して表示されないようにすることが好ましい。この例の場合、例えば、スカウト候補１人あたりの枠数の上限「３」を撤廃し、１人のスカウト候補に４枠以上の寸評情報が表示されるようにしてもよい。

図９のスカウト画面画像Ｇ４００の例では、スカウト候補の「選手１」の場合、選手キャラクタのランク、メインポジションおよび寸評情報３つのうちの１つが開示されている。一方、スカウト候補の「選手１」の契約可能年数および寸評情報３つのうちの２つが開示されていない。この場合、契約可能年数の情報を表示するパーツＰ４０５には「？年」が表示され、また、３つの寸評情報を表示するパーツＰ４０６内の２つの表示枠のそれぞれには「？？？」が表示される。すなわち、開示されなかったパラメータに関する情報が隠されている状態が視認できるように、画面表示されている。

また、図９のスカウト候補の「選手２」の場合、選手キャラクタのメインポジションおよび寸評情報３つのうちの２つが開示されている。一方、スカウト候補の「選手２」のランク、契約可能年数および寸評情報３つのうちの１つが開示されていない。この例の場合、ランクの情報を表示するパーツＰ４０４には「？」が表示され、契約可能年数の情報を表示するパーツＰ４０５には「？年」が表示され、また、３つの寸評情報を表示するパーツＰ４０６内の１つの表示枠には「？？？」が表示される。

また、図９のスカウト候補の「選手３」の場合、選手キャラクタのランク、メインポジションおよび契約可能年数が開示されている。一方、スカウト候補の「選手３」の寸評情報は、３つとも開示されていない。この例の場合、３つの寸評情報を表示するパーツＰ４０６内の３つの表示枠にはそれぞれ「？？？」が表示される。

（選手推理パート）
次に、イベントモードの選手推理パートについて説明する。前述のスカウト処理の実行により、スカウト画面画像Ｇ４００には複数のスカウト候補の選手キャラクタが表示されるが、選手キャラクタに関連付けられているパラメータの一部に関する情報が断片的に開示されるのみである。よって、ユーザは、スカウト候補がどのプロ野球選手に対応する選手キャラクタなのかや、どのスカウト候補が強い選手なのか等を推理して、獲得したいスカウト候補を選択することになる。図９のスカウト画面画像Ｇ４００の各スカウト候補表示領域Ａ４０１には、ユーザが獲得したいスカウト候補を選択するためのパーツＰ４０７が表示されている。このパーツＰ４０７は、例えばチェックボックスである。

図９のスカウト画面画像Ｇ４００はパーツＰ４０８を含んでいる。このパーツＰ４０８はスカウト可能人数を示す。図９の例ではパーツＰ４０８に「スカウト可能人数１／２」と表示されている。ここで、スカウト可能人数の上限が分母の数字であり、現在チェックを入れて選択している人数が分子の数字である。「スカウト可能人数１／２」の場合、スカウト候補を２人まで選択でき、現在１人だけ選択していることを示している。図９の例ではスカウト候補の「選手２」が選択されている状態である。スカウト画面画像Ｇ４００上ではスカウト可能人数の上限まで、複数同時に選択できる。

図９のスカウト画面画像Ｇ４００はパーツＰ４０９を含んでいる。このパーツＰ４０９はスカウトを実行するためのボタン画像である。パーツＰ４０９をタッチする操作を行うと、図１４に例示する入替対象一覧画面Ｇ５００に遷移する。

図１４の入替対象一覧画面Ｇ５００は領域Ａ５０１を含んでいる。この領域Ａ５０１には、図９のスカウト画面画像Ｇ４００で選択されたスカウト候補の選手キャラクタに関する情報が表示される。この段階では、図９のスカウト候補表示領域Ａ４０１と同様に、領域Ａ５０１にはスカウト候補のパラメータの一部に関する情報が断片的に開示されるのみであり、スカウト候補のパラメータの情報が部分的にマスクされている。図１４の領域Ａ５０１のパーツＰ５０２～Ｐ５０６は、図９のスカウト候補表示領域Ａ４０１のパーツＰ４０２～Ｐ４０６と同様であり、その説明を省略する。

また、入替対象一覧画面Ｇ５００は、複数の入れ替え対象の選手キャラクタの情報を表示する入替対象表示領域Ａ５０７を含んでいる。入れ替え対象の選手キャラクタは、ユーザーチームの２４人のメンバである。なお入替対象一覧画面Ｇ５００に表示しきれないれ入れ替え対象の選手キャラクタの情報が存在する場合、ユーザが画面をスクロールする操作を行うことにより、表示されていなかった入れ替え対象の選手キャラクタの情報が表示される。

入替対象表示領域Ａ５０７には、パーツＰ５０８～Ｐ５１４が表示される。パーツＰ５０８は、選手キャラクタの画像（アイコン）、ランクおよび選手名を示す。パーツＰ５０９はメインポジションを示す。パーツＰ５１０はオーダー内のポジションを示す。パーツＰ５１１は残契約年数を示す。パーツＰ５１２～Ｐ５１４は、野手の３つの能力（ミート、パワー、走力）の能力値およびランクを示す。なお、投手キャラクタの場合、パーツＰ５１２～Ｐ５１４は、投手の３つの能力（球威、制球、スタミナ）の能力値およびランクを示す。

ここで、契約年数パラメータは１１月の試合終了後のタイミングで減算されるので、１１月の試合終了後に発生するスカウトイベントでは、ユーザチーム内に契約年数「０」の選手キャラクタが含まれている可能性がある。よって、入替対象一覧画面Ｇ５００には、パーツＰ５１１の残契約年数が「０」の入れ替え対象の選手キャラクタが表示される場合もある。

また、入替対象一覧画面Ｇ５００は、パーツＰ５１５を含んでいる。パーツＰ５１５は一覧表示される複数の入れ替え対象の選手キャラクタの表示の並び順を変更するためのパーツである。ユーザがパーツＰ５１５を指示する操作を行えば、並び順を変更するための画面が表示され、並び順を指定できる。図１４の例ではパワーの能力値の高さ順に表示される「パワー順」が指定されている。他の並び順としては、ミート等の能力値順、レベル順、残契約年数順、ポジション順などがある。

入替対象一覧画面Ｇ５００において、ユーザは、一覧表示される複数の入れ替え対象の中からスカウト候補と入れ替えたい選手キャラクタを検討し、入れ替えたい選手キャラクタが表示されている入替対象表示領域Ａ５０７を指でタッチする等の選択操作を行う。この操作により、図１５に例示する選手入替確認画面Ｇ６００に遷移する（あるいは選手入替確認画面Ｇ６００がポップアップで表示される）。

選手入替確認画面Ｇ６００はパーツＰ６０１～Ｐ６０４を含む。パーツＰ６０１は、入替対象一覧画面Ｇ５００でユーザが選択した入れ替え対象の選手キャラクタの情報を示す。パーツＰ６０２は、パーツＰ６０１に表示されている入れ替え対象の選手キャラクタと入れ替えられるスカウト候補の選手キャラクタの情報を示す。この段階でもスカウト候補のパラメータの一部に関する情報が断片的に開示されるのみである。パーツＰ６０３は、スカウト候補の選手キャラクタのユーザへの付与を実行し、当該選手キャラクタをパーツＰ６０１に表示されている入れ替え対象の選手キャラクタと入れ替える処理を実行するためのパーツである。パーツＰ６０４はキャンセルボタンである。パーツＰ６０３ではなくパーツＰ６０４が操作された場合、上記の入れ替え処理は実行されず、図１４の入替対象一覧画面Ｇ５００へ戻る。

ユーザがパーツＰ６０３を指でタッチする等の操作を行えば、スカウト候補の選手キャラクタがユーザが獲得したキャラクタとしてユーザのユーザＩＤに関連付けられる。そして、獲得したスカウト候補の選手キャラクタは、パーツＰ６０１に表示されている入れ替え対象の選手キャラクタに代わってユーザチームのメンバとして加入する。つまり、入れ替え対象の選手キャラクタはユーザチームのメンバから削除される。例えば、パーツＰ６０３が操作された場合、選手キャラクタ獲得演出が発生し、シルエット画像から選手キャラクタの画像に画面表示が変化するとともに、当該選手キャラクタのランク、選手名等も表示され、どの選手を獲得したのかがここで初めて明らかになる。選手キャラクタの獲得後は、選手確認用の画面において全てのパラメータを確認可能である。

その後、まだ獲得対象のスカウト候補がいる場合、すなわち、スカウト可能人数が２以上であり、図９のスカウト画面画像Ｇ４００で複数のスカウト候補にチェックを入れて選択していた場合、図１４の入替対象一覧画面Ｇ５００へ遷移する。そして、別の獲得対象のスカウト候補に対して上述の入れ替え処理が行われる。

（オーダー強化パート）
次に、イベントモードのオーダー強化パートについて説明する。上述の選手推理パートでユーザが推理しながら獲得したスカウト候補の選手キャラクタは、獲得後に初めてどのような選手であったかが明らかになる。獲得した選手キャラクタはユーザチームに加えられるので、基本的には強い（レベルや能力の高い）選手キャラクタを推理して獲得することによりチームを強化できる。また、スカウトで獲得後に明らかになった選手キャラクタのパラメータ、及びチーム内の既存のメンバのパラメータを考慮し、オーダーを編成してチームを強化できる。すなわち、図７に示すチーム設定画面Ｇ２００において、ユーザはチーム内のメンバのポジションを入れ替えたり、打順を変更したりできる。

但し、単純に強い選手キャラクタばかりを獲得するだけでは、効果的にチームを強化できない。なぜならば、野球のチームでは各ポジション（守備位置）に配置できる選手キャラクタは１人と決まっているため、単純に強い選手ばかりを選択的に獲得しても、ポジションが重なってしまってはオーダーを強化できない。ユーザチームの総合的な能力や評価（チーム総合力値、球団ランク等）を高めるためには、どのようなポジションや能力を持った選手を獲得する必要があるのかを考慮して、スカウトで獲得する選手キャラクタを推理しながら選択する必要がある。よって、選手推理パートにおけるスカウト候補の選択も、オーダー強化パートの一部といえる。

また、スカウトで獲得した選手キャラクタを含むユーザチームのメンバのそれぞれには、契約年数のパラメータが設定されており、残契約年数が０になったメンバはチームを退団する。よって、将来を見据えたチーム強化のためには、スカウトで獲得する選手キャラクタの契約年数（契約可能年数）、及びチーム内の既存のメンバの契約年数（残契約年数）を総合的に考慮し、どのスカウト候補を選択して獲得すべきかを検討することを要求される。

なお、上記では、ユーザが獲得したスカウト候補の選手キャラクタはユーザチームの既存のメンバと入れ替えられ、これにより入れ替えられた既存のメンバは削除され、チームのメンバの人数は２４名のまま変化しない例を説明した。これに限定されるものではなく、次の例のようにしてもよい。例えば、ユーザがスカウト候補の選手キャラクタを獲得しても、ユーザチームの既存のメンバが削除されることなく、獲得した選手キャラクタがユーザチームに追加のみされるようにしてもよい。この場合、ユーザが選手キャラクタを獲得すればチームメンバが増加するが、試合で使用できるのはオーダーに入れた所定数（例えば２４名）の選手キャラクタのみである。よって、ユーザはスカウトで獲得した選手キャラクタをオーダーに組み込むか否かを検討し、必要に応じて獲得した選手キャラクタをオーダーに組み込んでオーダーを強化する。この場合、チーム総合力値は、ユーザチーム内の一部の選手キャラクタ（オーダー内の選手キャラクタのみ）の総合力パラメータに基づいて算出される。

（契約更改等のゲーム内イベント）
前述のとおり、イベントモードで用いられる全ての選手キャラクタには、契約年数というパラメータが設定されている。契約年数は１年～５年の何れかである。各選手キャラクタの契約年数は一定の時期になると１ずつ減っていき、「０」になると退団となり、ユーザのチームメンバから削除される。本実施の形態では、秋シーズンの終了（１１月の試合終了）毎に、各選手キャラクタの契約年数が「１」減算される。よって、契約年数が０になる選手キャラクタは１１月に（１１月の試合の終了後に）発生する可能性がある。契約年数が０になった選手キャラクタが発生した場合に、「契約更改」というゲーム内イベントが発生する。契約更改イベントでは、ユーザは契約年数が「０」になった選手キャラクタのうちから１人だけ慰留する（ユーザチームに残るようにする）ことができる。また、１１月の試合終了後には、契約更改イベントに続いて、「選手退団」及び「選手加入」というゲーム内イベントが発生する可能性がある。

図１６は、表示部２０に表示される契約更改画面Ｇ７００の一例を示す図である。契約更改画面Ｇ７００には、ユーザチームの複数の選手キャラクタのうち、１１月の試合の終了後に契約年数が０になった選手キャラクタが慰留候補として一覧表示される。図１６では、２つの慰留候補表示領域Ａ７０１が設けられ、２人の慰留候補の選手キャラクタに関する情報が表示されている例を示している。

なお、図１６の契約更改画面Ｇ７００に表示しきれない慰留候補の選手キャラクタの情報が存在する場合、ユーザが画面をスクロールする操作を行うことにより、表示されていなかった慰留候補表示領域Ａ７０１が表示される。

慰留候補表示領域Ａ７０１には、パーツＰ７０２～Ｐ７０８が表示される。パーツＰ７０２は、選手キャラクタの画像（アイコン）及び選手名を示す。パーツ７０３は、選手キャラクタのランクを示す。パーツＰ７０４は、レベルを示す。パーツＰ７０５は、メインポジションを示す。パーツＰ７０６～Ｐ７０８は、野手の３つの能力（ミート、パワー、走力）の能力値およびランクを示す。また、投手キャラクタの場合、パーツ７０６～７０８は、投手の３つの能力（球威、制球、スタミナ）の能力値およびランクを示す。なお、ユーザが所定の操作を行うことにより、この慰留候補表示領域Ａ７０１に表示されていないパラメータの情報も確認できるようしてもよい。例えば、パーツＰ７０２をタップすれば、別画面に遷移し（又はポップアップ画面が開いて）、慰留候補の選手キャラクタの全てのパラメータが確認できるようにしてもよい。

また、各慰留候補表示領域Ａ７０１にはパーツＰ７０９が表示されている。パーツＰ７０９は、慰留候補表示領域Ａ７０１に表示されている慰留候補の選手キャラクタに対して慰留処理を実行するためのパーツである。ユーザは、契約更改画面Ｇ７００に表示される慰留候補の中から慰留したい１人を選択して、「この選手を慰留」と記されたパーツＰ７０９を指でタッチする等の操作をする。これにより、選択された慰留候補の選手キャラクタについてはユーザの所有状態が維持され、ユーザチームのメンバに留まる。また、慰留となった選手キャラクタの契約年数パラメータが、ランダム抽選により決定された１年～５年のうちの何れかの年数に更新される。なお、更新される契約年数はこれに限定されない。

なお、ユーザが慰留できる選手キャラクタの人数は１人に限定されるものではなく、２人以上であってもよい。また、例えば、確率に基づいて（例えばランダムに）、所定の範囲（例えば１人～３人等）の中で慰留できる最大の人数を変化させてもよい。あるいは、例えば、契約更改イベントまでに実行されたゲームの実行結果に基づいて（例えば、当シーズンの累計眼力ポイントに基づいて）、慰留できる最大の人数を変化させてもよい。

また、契約更改画面Ｇ７００はパーツＰ７１０を含んでいる。パーツＰ７１０は、慰留候補の選手キャラクタを誰も慰留しないで契約更改イベントを終了させるパーツである。慰留候補の中に魅力的な選手キャラクタがいなかった場合、誰も慰留しないという選択肢もある。後述する選手加入イベントにより、慰留候補よりも魅力的な代替選手が加入する場合もあり得るので、ユーザが敢えて誰も慰留しないという戦略も取り得るようにしている。

前述の契約更改イベントにおいて、ユーザに選択されなかった慰留候補（すなわち契約年数「０」）の選手キャラクタが存在する場合、続いて選手退団イベントが発生する。この選手退団イベントでは、ユーザチーム内の契約年数「０」の選手キャラクタがユーザチームから削除されることにより退団となる。そして、契約年数「０」の選手キャラクタが画面に一覧表示され、ユーザに退団が通知される。

ユーザチームのメンバが退団したことにより、ユーザチームの人数がオーダー構成に必要な２４人よりも少なくなると、続いて選手加入イベントが発生する。選手加入イベントでは、退団した選手キャラクタのポジションに応じて、Ｂランクの代替の選手キャラクタがユーザチームに加入する。

例えば、メインポジション一塁手の選手キャラクタが退団した場合、メインポジションが一塁手でＢランクの選手キャラクタの中からランダムに抽選された選手キャラクタが代替選手としてユーザチームに加入する（ユーザＩＤに関連付けられる）。この処理は退団した選手の数だけ繰り返される。そして、加入した選手キャラクタが画面に一覧表示され、ユーザに契約の切れた選手に代わって新たな選手が加入したことが通知される。

なお、選手加入イベントで加入する代替の選手キャラクタはＢランクに限定されず、他のランクであってもよい。また、退団した選手キャラクタのポジションと同じポジションの代替選手が加入するのではなく、例えば、全てのポジションを対象として代替選手が抽選されるようにしてもよい。あるいは、野手の選手キャラクタが退団した場合は、野手の全ポジションを対象として代替選手が抽選され、投手の選手キャラクタが退団した場合は、投手の全ポジションを対象として代替選手が抽選されるようにしてもよい。

なお、ユーザがスカウトで選手キャラクタを獲得した場合、ユーザチームの既存のメンバが削除されることなく、獲得した選手キャラクタがユーザチームに追加のみされるゲーム仕様の場合、選手退団イベントでユーザチームのメンバが退団しても、オーダー構成に必要な所定数（例えば２４人）を下回らないこともある。この場合、選手加入イベントは発生しないようにしてもよいし、発生するようにしてもよい。あるいは、オーダー構成に必要な所定数を下回った場合にのみ、選手加入イベントが発生し、ユーザチームのメンバが前記所定数になるまで新たな選手キャラクタが加入するようにしてもよい。

［３．ゲームシステムの機能的構成］
図１７は、ゲームシステム１の機能的な構成の一例を示す概略の機能ブロック図である。図１７に示すように、ゲームシステム１はデータ記憶部１００を含む。例えば、データ記憶部１００は、データベースＤＢ、ＲＯＭ１２、ＲＡＭ１３、補助記憶装置１４、ＲＯＭ３２、ＲＡＭ３３、及び補助記憶装置３４の少なくとも一つによって実現される。データ記憶部１００はゲームを提供するために必要なデータを記憶する。

データ記憶部１００に記憶されるデータの具体例として、上記で説明した野球ゲームを提供するために必要なデータについて説明する。データ記憶部１００は、ユーザ情報テーブルＴＢＬ１０１、キャラクタ情報テーブルＴＢＬ１０２、所有キャラクタテーブルＴＢＬ１０３、寸評情報テーブルＴＢＬ１０４及びＴＢＬ１０５、及びユーザチームデータＤＴ１０６等を記憶する。なお、寸評情報テーブルＴＢＬ１０４及びＴＢＬ１０５（図１２及び図１３参照）については既に説明済みであるため、ここではその説明を省略する。

例えば、データ記憶部１００に記憶されているゲームを実行するための各種データは、データベースＤＢ又はサーバ３０の補助記憶装置３４等に記憶されており、ゲーム端末１０がサーバ３０にアクセスした場合に、必要なデータがゲーム端末１０のＲＡＭ１３又は補助記憶装置１４にダウンロードされるようにすることができる。また、ゲーム端末１０で実行されたゲームの結果やデータの変更についての情報は、リアルタイムで又は所定のタイミングでゲーム端末１０からサーバ３０へ送信され、データベースＤＢ又はサーバ３０の補助記憶装置３４等に記憶されているデータが適宜更新されるようにすることができる。また、例えば、ゲームの少なくとも一部を、各ユーザのゲーム端末１０において、サーバ３０にログインせずにオフラインでもゲームが実行できるように、必要なデータをゲーム端末１０の補助記憶装置１４等に記憶しておくようにしてもよい。

図１８は、ユーザ情報テーブルＴＢＬ１０１の一例を示す。図１８の例ではユーザＩＤ「Ｕ１」のユーザ１人分の情報が記憶されるユーザ情報テーブルＴＢＬ１０１を示しているが、ゲームシステム１に登録されている全てのユーザを対象としたユーザ情報テーブルＴＢＬ１０１が、ゲームシステム１のデータ記憶部１００（例えば、データベースＤＢや補助記憶装置３４等）に記憶されている。

ユーザ情報テーブルＴＢＬ１０１は、「ユーザＩＤ」、「ユーザ名」、「お気に入りチーム」、「ゲームレベル」、「報酬」等のフィールドを含む。「ユーザＩＤ」フィールドは各ユーザを一意に特定するための識別情報を示す。「ユーザ名」フィールドはユーザの名前を示す。「お気に入りチーム」フィールドは、ユーザが選んだお気に入りチーム（例えば、日本プロ野球１２球団の何れか）（例えば、日本プロ野球１２球団の何れか）を示す。「ゲームレベル」フィールドはユーザのゲームレベルを示す。ゲームレベルは、野球ゲームにおけるユーザの操作スキルのレベルを評価した情報である。「報酬」フィールドはユーザが獲得した報酬（各種ポイント、アイテム等）を示す。

本実施の形態では、通常対戦モードで使用するチームと、イベントモードで使用するチームとは独立して管理されている。そこで、ユーザ情報テーブルＴＢＬ１０１には、通常対戦モードに関するフィールドと、イベントモードに関するフィールドとが存在する。通常対戦モードに関するフィールドには、「チームランク」及び「チーム総合力」等のフィールドが含まれる。イベントモードに関するフィールドには、「現在の年月」、「球団ランク」、「チーム総合力」、「眼力ポイント」、「合計オーダーポイント」、「累計球団運営ポイント」等のフィールドが含まれる。

なお、図１８では省略されているが、その他のフィールドもユーザ情報テーブルＴＢＬ１０１に含まれる。例えば、ユーザが所有しているゲーム内の様々なポイント、ゲームアイテム、ユーザのユーザＩＤに関連付けられる他のユーザ（仲間、フレンド等）のユーザＩＤ、対戦履歴等のフィールドが、ユーザ情報テーブルＴＢＬ１０１に含まれる。

図１９は、キャラクタ情報テーブルＴＢＬ１０２の一例を示す。キャラクタ情報テーブルＴＢＬ１０２は、ゲームシステム１が提供するゲーム内で扱う全ての選手キャラクタを管理するためのマスターデータである。キャラクタ情報テーブルＴＢＬ１０２には、全ての選手キャラクタの初期データがオリジナルパラメータとして記憶されている。例えば、キャラクタ情報テーブルＴＢＬ１０２は、サーバ３０及びゲーム端末１０のそれぞれの記憶装置（例えば、ＲＡＭ１３、補助記憶装置１４、ＲＡＭ３３、補助記憶装置３４、データベースＤＢ等）に記憶されて管理されている。サーバ３０及びゲーム端末１０に記憶されるキャラクタ情報テーブルＴＢＬ１０２は基本的に同じものであり、例えば、サーバ３０においてゲーム運営側がキャラクタ情報テーブルＴＢＬ１０２を変更した場合、変更した情報がネットワークＮを介してサーバ３０からゲーム端末１０へ配信される。キャラクタ情報テーブルＴＢＬ１０２は、「キャラクタＩＤ」、「名前」、「ランク」、「ポジション情報」、「能力情報」、「契約年数」等のフィールドを含む。

「キャラクタＩＤ」フィールドは、選手キャラクタを一意に識別するための識別情報を示す。「名前」フィールドは、選手キャラクタの名前を示す。本実施の形態では、実在の野球選手を模した選手キャラクタには、当該実在の野球選手の名前が設定される。「ランク」フィールドは、選手キャラクタのランクを示す。「ポジション情報」フィールドは、選手キャラクタのポジションパラメータを示す。ポジションパラメータには、メインポジション及びサブポジションの情報が含まれる。「能力情報」フィールドは、選手キャラクタの能力パラメータを示す。能力パラメータには、総合能力値、野手の３つの能力（ミート、パワー、走力）、弾道、投手の３つの能力（球威、制球、スタミナ）、球種、球速、変化量、特殊能力、守備適性能力値、守備適性ランク等が含まれる。

なお、図１９では省略されているが、その他のフィールドもキャラクタ情報テーブルＴＢＬ１０２に含まれる。例えば、選手キャラクタのレベル、上限レベル、コスト、特訓レベル等のフィールドが、キャラクタ情報テーブルＴＢＬ１０２に含まれる。

図２０は、所有キャラクタテーブルＴＢＬ１０３の一例を示す。所有キャラクタテーブルＴＢＬ１０３は、ユーザが所有している選手キャラクタのリストを示すデータである。所有キャラクタテーブルＴＢＬ１０３は、通常対戦モードで使用可能なユーザ所有の選手キャラクタを管理するフィールドと、イベントモードで使用可能なユーザ所有の選手キャラクタを管理するフィールドとを含む。前述のとおり、イベントモードで使用されるユーザのチームおよびチームに所属する選手キャラクタは、イベントモードでのみ使用可能であり、イベントモードの開催期間の終了時に、ユーザの所有ではなくなる。この点が、常設の通常対戦モードで使用可能な選手キャラクタとは異なる。

所有キャラクタテーブルＴＢＬ１０３は、「シリアル番号」、「キャラクタＩＤ」、「オリジナルパラメータ」及び「現在パラメータ」のフィールドを含む。「シリアル番号」フィールドは、ユーザが所有している選手キャラクタを一意に識別するためのシリアル番号を示す。ユーザが同一の選手キャラクタを複数所有する場合、これらの選手キャラクタの選手キャラクタＩＤは同一であるが、シリアル番号は異なる。「オリジナルパラメータ」フィールドは、選手キャラクタのパラメータの初期値を示す。なお、「オリジナルパラメータ」フィールドは、キャラクタ情報テーブルＴＢＬ１０２を参照すればよいので省略可能である。「現在パラメータ」フィールドは、選手キャラクタのパラメータの現在値を示す。

図２１は、ユーザチームデータＤＴ１０６の一例を示す。ユーザチームデータＤＴ１０６は、ユーザが設定した、イベントモードで使用されるユーザチームのオーダーデータである。ここでは省略しているが、通常対戦モードで使用されるユーザチームのデータも、データ記憶部１００に記憶してゲームシステム１が管理している。通常対戦モード又はイベントモードのオーダーデータは、それぞれ１つに限らず２以上であってもよい。例えば、ＣＰＵ対戦（コンピュータ対戦）用のチームのオーダーと、リアルタイム対戦用のチームのオーダーとを使い分けることができるようにしてもよい。

図２１に示すように、ユーザチームデータＤＴ１０６は、ユーザ毎に（ユーザＩＤと関連付けて）記憶される。ユーザチームデータＤＴ１０６は、イベントモードでユーザが所有している選手キャラクタの投手メンバ（先発投手メンバ、中継ぎ投手メンバ、抑え投手メンバ及びベンチメンバ）、及び野手メンバ（スターティングメンバ及びベンチメンバ）を示す。また、ユーザチームデータＤＴ１０６は、ユーザの操作に基づいて設定された（又はゲームシステム１により自動で設定された）チーム内のポジションの情報および打順の情報を含む。

本実施の形態のゲームシステム１、サーバ３０又はゲーム端末１０は、複数の選択対象のオブジェクトの中からユーザによって選択されたオブジェクトが用いられるゲームを提供する。

ここで、「ユーザ」とは、例えば、ゲームシステムで提供されるゲームをプレイする人である。例えば、ユーザ識別情報が各ユーザに対して設定され、各ユーザはユーザ識別情報によって識別（特定）される。「ユーザ識別情報」とは、各ユーザを一意に識別するための情報である。例えば、ユーザＩＤ、重複しないユーザ名、又はメールアドレス等が「ユーザ識別情報」の一例に相当する。

また、「オブジェクト」とは、ゲームにおいて使用され得るものである。例えば、ゲームキャラクタ、ゲームカード、又はゲームアイテム等が「オブジェクト」の一例に相当する。例えば、スポーツ選手等の人物、競走馬等の生物、モンスター等の架空の人物や生物、ロボット等の非生物を示すゲームキャラクタやゲームカードが「オブジェクト」の一例に相当する。また、例えば、キャラクタに装備される装備アイテムが「オブジェクト」の一例に相当する。例えば、「オブジェクト」は、実在する人物や生物に対応するゲームキャラクタやゲームカードであってもよいし、実在する人物等に対応するものでなくてもよい。「オブジェクト」は、例えばスポーツゲーム（野球、サッカー、テニス、アメリカンフットボール、バスケットボール、アイスホッケー、バレーボール、ラグビー等を題材としたゲーム）、レースゲーム、格闘ゲーム、戦闘ゲーム、デジタルカードゲーム、ロールプレイングゲーム、シミュレーションゲーム、アドベンチャーゲーム又は育成ゲームのように、ゲーム形式・ジャンルを問わず様々なゲームで使用され得る。前述の野球ゲームの例では、選手キャラクタが「オブジェクト」の一例に相当する。

また、「選択対象のオブジェクト」とは、ユーザの意思に基づいて選択され得る対象となるオブジェクトである。例えば、ユーザの操作によって選択可能に画面に表示された複数のオブジェクトのそれぞれが「選択対象のオブジェクト」の一例に相当する。例えば、タッチインターフェースを備えたタッチパネルに複数の選択対象のオブジェクトが表示される場合、ユーザはタッチ操作により選択対象のオブジェクトを選択してもよい。また、例えば、ユーザは、ボタン操作、ポインティングディバイスによるカーソル操作または音声入力操作等の種々の入力操作により、選択対象のオブジェクトを選択してもよい。前述の野球ゲームの例では、表示部２０に表示される複数のスカウト候補の選手キャラクタのそれぞれが、「選択対象のオブジェクト」の一例に相当する。

複数のスカウト候補の選手キャラクタの中からユーザによって選択された選手キャラクタが試合で用いられる前述の野球ゲームが、「複数の選択対象のオブジェクトの中からユーザによって選択されたオブジェクトが用いられるゲーム」の一例に相当する。

図１７に示すように、ゲームシステム１は制御部１１０を含む。制御部１１０は、記憶装置（ＲＯＭ１２、ＲＡＭ１３、補助記憶装置１４、ＲＯＭ３２、ＲＡＭ３３又は補助記憶装置３４等）に記憶されているゲームプログラムを、ゲーム端末１０のＣＰＵ１１又はサーバ３０のＣＰＵ３１が実行することにより実現される。制御部１１０の機能の一部をゲーム端末１０によって実現し、残りの機能をサーバ３０によって実現してもよい。または、制御部１１０の機能の全てをサーバ３０によって実現してもよいし、制御部１１０の機能の全てをゲーム端末１０によって実現してもよい。

制御部１１０は、提示部１１０１（提示手段の一例）及び獲得部１１０２（獲得手段の一例）を含む。

提示部１１０１は、複数の前記選択対象のオブジェクトを提示する機能を有する。

ここで、「選択対象のオブジェクトを提示する」とは、選択対象のオブジェクトに関する少なくとも一部の情報をユーザが認識できるようにユーザに示すことである。例えば、選択対象のオブジェクトに関する少なくとも一部の情報を画面に表示することが「選択対象のオブジェクトを提示する」の一例に相当する。なお、画面に表示することの他、選択対象のオブジェクトに関する少なくとも一部の情報を音声でユーザに示すことも、「選択対象のオブジェクトを提示する」の一例に相当し、画面表示と音声提示とを組み合わせても良い。また、提示される選択対象のオブジェクトの画像に関しては、画像が表示されてもよいし、画像の一部のみが表示されてもよいし、画像がシルエットとして表示されてもよいし、実際の画像とは異なる仮の画像が表示されてもよいし、画像が表示されなくてもよい。また、選択対象のオブジェクトの名称に関しては、名称が表示されてもよいし、名称の一部のみが表示されてもよいし、名称のイニシャルが表示されてもよいし、実際の名称とは異なる仮の名称が表示されてもよいし、名称が表示されなくてもよい。

前述の野球ゲームの例では、図９に例示するスカウト画面画像Ｇ４００を表示部２０に表示することにより、複数のスカウト候補の選手キャラクタに関する情報をユーザが視認できるようにしており、これが「複数の前記選択対象のオブジェクトを提示する」の一例に相当する。

選択対象のオブジェクトの画像や名称から、当該オブジェクトの能力等のパラメータが分かる又は見当がつくような場合、実際の画像や名称が分からないようにすることが望ましい。前述の野球ゲームの例では、実在のプロ野球選手に対応する選手キャラクタが使用されており、スカウト候補の選手キャラクタの画像や名称が画面に表示されると、そのスカウト候補が誰でどんなパラメータを有するのかの見当がつく。よって、前述の野球ゲームでは、スカウト候補の選手キャラクタの画像や名称が分からないように、シルエット画像および仮の選手名を使用して画面に提示する例を示した。

獲得部１１０２は、前記提示手段によって提示された複数の前記選択対象のオブジェクトの中からユーザが選択した選択対象のオブジェクトを、ユーザが獲得したオブジェクトとしてユーザのユーザ識別情報に関連付ける機能を有する。

ここで、「ユーザが獲得したオブジェクト」とは、ゲーム上、ユーザの所有となったオブジェクトであり、ユーザのユーザ識別情報に関連付けられたオブジェクトである。「ユーザが獲得したオブジェクト」は、例えば、ゲーム内でユーザが使用できるオブジェクトであってもよい。また、「ユーザが獲得したオブジェクト」は、例えば、ゲーム上の使用はせずにコレクションとしてユーザが所有しているだけのオブジェクトであってもよい。

前述の野球ゲームでは、画面に表示された複数のスカウト候補の選手キャラクタの中からユーザが選択したスカウト候補の選手キャラクタを、ユーザが獲得した選手キャラクタとしてユーザのユーザＩＤに関連付ける例を示した。

また、前記提示部１１０１は、前記選択対象のオブジェクトを提示する場合に、前記選択対象のオブジェクトに関連付けられている複数のパラメータの全ては分からないように、前記複数のパラメータの一部に関する情報のみを開示する機能を有する。

ここで、「オブジェクトに関連付けられているパラメータ」とは、オブジェクトに設定されたパラメータである。「オブジェクトに関連付けられているパラメータ」は、数値パラメータであってもよいし、数値パラメータでなくてもよい。例えば、オブジェクトの総合的な能力又は性能の高低を示すパラメータ（例えば、総合能力値、ランク、レベル等）が、「オブジェクトに関連付けられているパラメータ」の一例に相当する。また、例えば、オブジェクトに設定された役割を示すパラメータ（例えば、スポーツゲームのポジション等）が、「オブジェクトに関連付けられているパラメータ」の一例に相当する。また、例えば、オブジェクトに設定された使用可能期限や使用可能回数を示すパラメータが、「オブジェクトに関連付けられているパラメータ」の一例に相当する。また、例えば、オブジェクトの特定の能力又は性能の高低を示すパラメータ（例えば、攻撃力や守備力等）が、「オブジェクトに関連付けられているパラメータ」の一例に相当する。また、例えば、オブジェクトの能力又は性能を向上するために必要なパラメータ（例えば、経験値等）が、「オブジェクトに関連付けられているパラメータ」の一例に相当する。また、例えば、オブジェクトの状態の良し悪しを示すパラメータ（例えば、疲労度、やる気等）が、「オブジェクトに関連付けられているパラメータ」の一例に相当する。また、例えば、オブジェクトの希少性を示す希少度が、「オブジェクトに関連付けられているパラメータ」の一例に相当する。また、例えば、オブジェクトが有する特殊能力の情報が、「オブジェクトに関連付けられているパラメータ」の一例に相当する。また、例えば、オブジェクトの体形や形状の情報（画像、身長、重量、足や手等のパーツの大きさ等）、性別情報等を「オブジェクトに関連付けられているパラメータ」に含めてもよい。

また、「選択対象のオブジェクトに関連付けられている複数のパラメータ」は、当該オブジェクトに関連付けられている全てのパラメータであってもよいし、全てのパラメータのうちの２以上の一部のパラメータであってもよい。

例えば、「選択対象のオブジェクトに関連付けられている複数のパラメータ」は、ユーザに開示され得る開示対象パラメータとすることができる。ここで、「開示対象パラメータ」とは、選択対象のオブジェクトが提示される場合に、当該オブジェクトに関連付けられている全てのパラメータのうち、ユーザに開示され得る対象のパラメータをいう。「ユーザに開示され得る対象のパラメータ」には、常に開示されるパラメータと、開示される場合と開示されない場合とがあるパラメータとを含めることができる。一例を挙げると、野球ゲームの野手の選手キャラクタには、「画像」、「名称」、「所属球団」、「ランク」、「契約可能年数」、「能力値（ミート、パワー、走力等）」、「弾道」、「ポジション」、「利き腕（右投又は左投）」、「打撃スタイル（右打、左打又は左右両打）」等のパラメータが関連付けられており、これらのパラメータのうちの「ランク」、「契約可能年数」、「能力値」、「弾道」、「ポジション」、「利き腕」、「打撃スタイル」のみが、選択対象のオブジェクトの提示の際に開示され得る場合、当該「ランク」、「契約可能年数」、「能力値」、「弾道」、「ポジション」、「利き腕」、「打撃スタイル」が「開示対象パラメータ」の一例に相当する。なお、この例の場合、「画像」、「名称」、「所属球団」については、選択対象のオブジェクトに関連付けられているパラメータではあるが、「開示対象パラメータ」には含まれない。

また、「選択対象のオブジェクトに関連付けられている複数のパラメータの全ては分からないようにする」とは、選択対象のオブジェクトに関連付けられている複数のパラメータの一部をユーザが認識し得るが、その全部をユーザが認識し得ない状態にすることをいう。例えば、選択対象のオブジェクトに関連付けられている複数のパラメータのうちの一部のパラメータに関する情報だけが画面に表示されており、その他のパラメータについてはユーザが直接知り得ないようにしているため、選択対象のオブジェクトの一部の情報についてはユーザが推測せざるを得ない状態にすることが、「選択対象のオブジェクトに関連付けられている複数のパラメータの全ては分からないようにする」の一例に相当する。

また、例えば、選択対象のオブジェクトに関連付けられている複数のパラメータのうちの一部のパラメータに関する情報だけが画面に表示されており、その他のパラメータに関する情報が表示されておらず、且つ、表示されていないパラメータに関する情報にはユーザがアクセスできない状態にすることが、「選択対象のオブジェクトに関連付けられている複数のパラメータの全ては分からないようにする」の一例に相当する。一方、例えば、選択対象のキャラクタの複数のパラメータのうちの一部のパラメータに関する情報だけが画面に表示されており、その他のパラメータに関する情報が当該画面には表示されていないが、ユーザが所定の操作をすれば、当該画面には表示されていないパラメータを、当該画面以外で確認できる状態の場合、「選択対象のオブジェクトに関連付けられている複数のパラメータの全ては分からないようにする」には含まれない。当該画面以外で確認できる状態の場合とは、例えば、スクロールにより表示される画面、別の画面、またはポップアップ画面等で確認できる状態の場合である。

また、「開示する」とは、情報を隠さずにユーザが認識し得るように示すことをいう。例えば、情報を隠さずにユーザが認識し得るように画面に表示することが、「開示する」の一例に相当する。また、情報を隠さずにユーザが認識し得るようにスピーカーから音声で伝えることも、「開示する」の一例に相当する。

また、「複数のパラメータの一部に関する情報」とは、複数のパラメータのうちの一部分のパラメータに関する情報をいう。ここで、「パラメータに関する情報」は、例えば、パラメータそのものを示す情報とすることができる。例えば、オブジェクトのランクが「Aランク」であれば、具体的な「Aランク」という情報が「パラメータに関する情報」の一例に相当する。また、「パラメータに関する情報」は、例えば、パラメータの一部を示す情報とすることができる。例えば、能力等のパラメータの値が３桁（例えば「２５５」）であった場合、３桁目のみ表示して下二桁を隠した情報（表示例「２？？」）が「パラメータに関する情報」の一例に相当する。また、「パラメータに関する情報」は、例えば、パラメータを説明するような情報とすることができる。例えば、野球ゲームの野手キャラクタのミート、パワー、走力の各能力のうち、最も高い値の能力がミートである場合、「ミートに定評がある」という寸評形式で能力パラメータを説明した情報が「パラメータに関する情報」の一例に相当する。

また、「複数のパラメータの一部に関する情報のみを開示する」とは、複数のパラメータの全部に関する情報をユーザが認識し得るように示さずに、複数のパラメータに関する情報の一部のみを隠さずにユーザが認識し得るように示すことをいう。複数のパラメータのうちのどのパラメータを開示するかについては、開示するパラメータの一部又は全部を予め定めていてもよいし、開示するパラメータの一部又は全部を確率に基づいた抽選により決定してもよい。開示するパラメータを予め定める場合であっても、例えばローテーションにより、選択対象のオブジェクトを提示する毎に、開示するパラメータが変化するようにしてもよい。

前述の野球ゲームでは、スカウト候補の選手キャラクタを画面を通して提示する場合に、図９のスカウト画面画像Ｇ４００のように、前記複数のパラメータの一部に関する情報のみが開示される例を示した。すなわち、図９の例では、スカウト候補の選手キャラクタに関連付けられている複数の開示対象パラメータ（「ランク」、「契約年数」、「寸評情報に表示されうるパラメータである能力（ミート、パワー、走力、弾道、球威、制球、スタミナ、球種、球速等）、ポジション（メイン及びサブのポジション）、利き腕（右投又は左投）、打撃スタイル（右打、左打又は左右両打）」）の全ては分からないように、前記複数の開示対象パラメータの一部に関する情報のみを開示している。

また、前記選択対象のオブジェクトに関連付けられている複数のパラメータは、前記ゲームの実行結果に影響を及ぼすパラメータとすることができる。

ここで、「ゲームの実行結果」とは、オブジェクトのパラメータに基づいて実行されたゲームの結果をいう。例えば、対戦ゲームの場合は勝敗や得失点等が、「ゲームの実行結果」の一例に相当する。野球ゲームの例では、選手キャラクタの打撃、守備、走塁又は投球の成績（ヒット、アウト、エラー、盗塁、奪三振等）、チームの勝敗又は得失点等が、「ゲームの実行結果」の一例に相当する。また、例えば、成功／失敗が決まるゲームの場合は、成功又は失敗が「ゲームの実行結果」の一例に相当する。

また、「ゲームの実行結果に影響を及ぼすパラメータ」とは、選択対象のオブジェクトに関連付けられているパラメータのうち、ゲームの実行結果に変化をもたらし得るパラメータをいう。例えば、対戦ゲームの場合は勝敗や得失点等に影響を及ぼす、オブジェクトの能力パラメータ等が、「ゲームの実行結果に影響を及ぼすパラメータ」の一例に相当する。前述の野球ゲームの例では、選手キャラクタの「ランク」、「能力」、「ポジション」等のパラメータがゲームの実行結果（例えば、ヒット、アウト、エラー、盗塁、奪三振等）に影響を及ぼすパラメータである。また、選手キャラクタの「利き腕（右投又は左投）」や「打撃スタイル（右打、左打又は左右両打）」のパラメータも、打者と投手の相性（右腕投手は右打打者に強い傾向がある等）としてゲームの実行結果に影響を及ぼす場合、「ゲームの実行結果に影響を及ぼすパラメータ」となる。また、「契約年数」のパラメータは、前述の選手キャラクタの契約更改および選手退団の実行結果に影響を及ぼすので、「ゲームの実行結果に影響を及ぼすパラメータ」の一例である。

一方、オブジェクトの「画像」や「名称」は、ゲームの実行結果に特に影響を及ぼす要素ではない場合（例えば、対戦ゲームの勝敗等に関係しない場合）、「ゲームの実行結果に影響を及ぼすパラメータ」からは除外される。

また、前記提示部１１０１は、前記選択対象のオブジェクトを提示する場合に、開示されなかったパラメータに関する情報が隠されている状態が視認できるように画面に表示する機能を有する。

ここで、「開示されなかったパラメータに関する情報」とは、選択対象のオブジェクトに関連付けられている複数のパラメータには含まれているが、前記複数のパラメータの一部に関する情報のみが開示されたことにより、開示されなかった少なくとも１つのパラメータに関する情報をいう。

また、「開示されなかったパラメータに関する情報が隠されている状態が視認できるように画面に表示する」とは、開示されなかったパラメータに関する情報を敢えて隠していることがユーザに分かるように画面に表示することである。

例えば、開示されなかったパラメータに関する情報の表示欄（表示領域）は画面上に表示されているが、当該表示欄に例えば「？」等の記号を表示して情報が隠されていることをユーザに示すことが、「開示されなかったパラメータに関する情報が隠されている状態が視認できるように画面に表示する」の一例に相当する。あるいは、前記表示欄に、「この情報はマスクされました」等のメッセージ（情報が隠されている旨を示すメッセージ）が表示されるようにしてもよい。あるいは、前記表示欄は画面上に表示されているものの空白状態であったり、当該表示欄が所定の色（例えば、グレー）で塗りつぶされている状態が表示されるようにしてもよい。これは、通常、表示欄があるにもかかわらず何ら情報が表示されていない場合、当該表示欄に表示されるべき情報が表示されずに隠れているとユーザが認識するからである。

前述の野球ゲームの例では、図９のスカウト画面画像Ｇ４００に示すように、情報が開示されなかったランクの表示欄に「？」、契約可能年数の表示欄に「？年」、寸評情報の表示欄に「？？？」という情報が隠されている状態の表示を行い、情報を敢えて隠していることがユーザに分かるようにしている。

また、前記選択対象のオブジェクトに関連付けられている複数のパラメータの一部に関する情報には、確率に基づいて開示の有無が決定される１以上の開示有無変化情報が含まれるようにしてもよい。

ここで、「開示有無変化情報」とは、選択対象のオブジェクトに関連付けられている複数のパラメータの一部に関する情報であって、確率に基づいて開示の有無が決定される情報をいう。例えば、選択対象のオブジェクトが提示される際、確率に基づく抽選に当選した「開示有無変化情報」は画面に表示されるが、当選しなかった「開示有無変化情報」は表示されずに隠される。

開示有無変化情報の開示の有無を決定するための確率は固定であってもよいし、固定でなくてもよい。例えば、選択対象のオブジェクトが提示される毎に、前記確率が変化するようにしてもよい。一例を挙げると、選択対象のオブジェクトが提示される毎に、所定の範囲（例えば１０％～１００％の範囲）内でランダムに選ばれた確率が適用されるようにしてもよい。また、例えば、ゲームの実行結果に応じて、前記確率が変化するようにしてもよい。

前述の野球ゲームの例では、図９のスカウト画面画像Ｇ４００のパーツＰ４０４～Ｐ４０６のランク、契約年数、寸評情報（寸評１～寸評３）の各情報は、確率に基づいて開示される場合と開示されない場合とがあるので、当該各情報は「確率に基づいて開示の有無が決定される１以上の開示有無変化情報」の一例である。

また、前記提示部１１０１は、前記選択対象のオブジェクトを提示する前に実行された前記ゲームの実行結果に基づいて決定された前記確率に基づいて、前記開示有無変化情報を開示するか否かを決定する機能を有する。

ここで、「選択対象のオブジェクトを提示する前」は、選択対象のオブジェクトを提示するまでであれば、何れのタイミングまたは期間であってもよい。

また、「選択対象のオブジェクトを提示する前に実行されたゲームの実行結果」は、選択対象のオブジェクトを提示するまでであれば、何れのタイミングまたは期間に実行されたゲームの結果であってもよい。

一例として、野球の試合が実行される毎にゲーム内の仮想的な時間が進行し、３試合毎に１つのシーズンが終了し、各シーズン終了後の所定のタイミングで複数の選択対象の選手キャラクタが提示されるゲームを挙げて説明する。例えば、選択対象が提示される直前のシーズン中に行われた３試合の少なくとも１つの試合の実行結果が、「選択対象のオブジェクトを提示する前に実行されたゲームの実行結果」の一例に相当する。この場合、例えば、対象シーズン中の３試合全ての実行結果であってもよいし、当該３試合のうちの任意の１試合（又は２試合）の実行結果であってもよいし、当該３試合のうちの最もよい結果（又は悪い結果）が得られた試合の実行結果であってもよい。また、例えば、選択対象が提示される直前のシーズンだけでなく、それ以前のシーズンに行われた試合の実行結果を含めてもよい。また、対象シーズン中の試合の中の特定の１打席（又は複数打席）の結果であってもよい。

また、「ゲームの実行結果」は、例えば、ゲームの実行結果に応じて獲得できるゲーム要素（ポイント又はアイテム等）、勝敗、得失点、成功、失敗、勝利した数、負けた数、目標達成の有無等とすることができる。

また、「ゲームの実行結果に基づいて決定された確率」は、例えばゲームの実行結果に応じた値（勝利した数、獲得したポイント数、アイテム数等）に基づいた数式等の演算により得られる確率であってもよい。また、「ゲームの実行結果に基づいて決定された確率」は、例えばゲームの実行結果（前記の勝利した数、獲得したポイント数、アイテム数等）と確率との対応関係が定められた関係情報（ルックアップテーブル等）に基づいて決定される確率であってもよい。

例えば、ゲームの実行結果に応じて獲得したポイントが多いほど、情報が開示される確率が高くなるようにすることができる。また、例えば、ゲームの実行結果に応じて獲得したポイントがマイナス要素のポイント（例えば、エラー数や負け数に応じたポイント等）であった場合には、獲得したポイントが多いほど、情報が開示される確率が低くなるようにすることができる。

前述の野球ゲームでは、試合中の選手キャラクタの活躍の程度に応じて活躍ポイントが蓄積され、一つの試合中の活躍ポイントの累計に応じて、ユーザには眼力ポイントが付与される例を示した。この場合、試合の実行によりユーザが獲得した眼力ポイントが、「ゲームの実行結果」の一例である。そして、スカウト候補の選手キャラクタが提示される前の１シーズン（３試合）で獲得した眼力ポイントに基づいて開示確率が決定される（図１１参照）例を示した。この場合、スカウト候補提示前１シーズン（３試合）で獲得した眼力ポイントが、「選択対象のオブジェクトを提示する前に実行されたゲームの実行結果」の一例である。また、図１１に例示する眼力ポイント別情報開示確率のデータテーブルを参照して眼力ポイントに基づいて決定される開示確率が、「ゲームの実行結果に基づいて決定された確率」の一例に相当する。そして、前述の野球ゲームでは、前記眼力ポイントに基づいて決定された開示確率に基づいて、開示有無変化情報の一例としてのランク、契約年数および寸評情報（寸評１～寸評３）を開示するか否かを決定する例を示した。

また、前記提示部１１０１は、前記開示有無変化情報を開示する場合であって、当該開示有無変化情報として開示し得る複数の情報が存在する場合には、当該開示し得る複数の情報の中からランダムに選択した少なくとも１つを開示するようにしてもよい。

例えば、開示有無変化情報として開示し得る複数の情報の中から、ランダムに選択して開示し得る情報を先ず特定してから、当該特定された情報の開示の有無を確率に基づく抽選により決定してもよい。あるいは、開示有無変化情報の開示の有無を確率に基づく抽選により先ず決定し、その後、開示有無変化情報として開示し得る複数の情報の中から、ランダムに選択して開示する情報を特定するようにしてもよい。

前述の野球ゲームでは、スカウト候補の選手キャラクタ１人あたりの寸評情報（開示有無変化情報の一例）として開示し得る情報が６つ用意されている例を示した（図１２の野手の寸評情報テーブルＴＢＬ１０４、及び図１３の投手の寸評情報テーブルＴＢＬ１０５を参照）。前述の野球ゲームでは、６つの寸評情報に対して、画面に表示できる寸評情報は最大で３つであり、６つの寸評情報の中からランダムに選ばれた最大で３つの寸評情報を開示し得る例を示した。この場合、画面上の最大３つの表示スペースに、６つの寸評情報からランダムに選ばれた最大３つの寸評情報が開示されるので、開示される寸評情報を変化させることができる。

また、前記提示部１１０１は、前記選択対象のオブジェクトを提示する前に実行された前記ゲームの実行結果に基づいて、前記複数のパラメータの一部に関する情報の開示の詳しさを変化させるようにしてもよい。

ここで、「情報の開示の詳しさ」とは、ユーザに開示される情報の詳しさの程度をいう。「情報の開示の詳しさ」は、例えば、開示される情報の量が多いほど、詳しさの程度が高まる。一例を挙げると、オブジェクトの「ランク」に関する情報が開示される場合よりも、「ランク」および「能力」の２つのパラメータに関する情報が開示される方が詳しさの程度は高くなり、また、「ランク」、「能力」、「ポジション」の３つのパラメータに関する情報が開示される場合はさらに詳しさの程度は高くなる。

前述の野球ゲームでは、図１１に示すように、スカウト候補提示前１シーズン（３試合）で獲得した眼力ポイントが高いほど、スカウト候補の選手キャラクタのパラメータに関する情報の開示量が多くなる例を示した。これは、スカウト候補の選手キャラクタ（選択対象のオブジェクトの一例）を提示する前に実行されたゲームの実行結果に基づいて、前記情報の開示量が変化することにより、情報の開示の詳しさが変化する一例である。

また、「情報の開示の詳しさ」は、例えば、開示される情報の質が高いほど、詳しさの程度が高まる。ここで、「情報の質」については、ユーザがオブジェクトの強さ等を推理する上で有益な情報ほど情報の質は高いと言える。例えば、パラメータに関する情報が具体的であるほど、オブジェクトの強さ等を推理する上で有益であるため、情報の質が向上し、情報開示の詳しさの程度は高くなる。

一例を挙げると、野球の選手キャラクタには、ミート、パワー、走力、守備力の各能力のパラメータが関連付けられているものとする。そして、最も能力値の高い能力が「ミート」であり、「ミート」の能力値が「８５」でその能力ランクが「Ａ」であるとする。ここで、前述のとおり能力ランクは能力値の範囲を示すものであり、例えば、能力値８０～９９の範囲であれば能力ランクが「Ａ」となる。この場合、「打撃に定評がある」という寸評情報よりも、「ミートに定評がある」という寸評情報の方が具体的であり情報開示の詳しさの程度は高い。また、前記２つの寸評情報よりも、「ミートＡ」（ミートの能力ランクＡ）という寸評情報の方がさらに具体的であり、情報開示の詳しさの程度はより高くなる。また、前記３つの寸評情報よりも、「ミート８５」（ミートの能力値８５）という寸評情報の方がさらに具体的であり、情報開示の詳しさの程度はより高くなる。

また、例えば、選手キャラクタのポジション（メインポジション又はサブポジション）が一塁手であり、ポジション適性ランクが「B」であるとする。この場合、「内野手である」という寸評情報よりも、「一塁手である」という寸評情報の方が具体的であり情報開示の詳しさの程度は高い。また、前記２つの寸評情報よりも、「一塁手の適性B」という寸評情報の方がさらに具体的であり、情報開示の詳しさの程度はより高くなる。

図２２は眼力ポイント別情報開示確率の他の例を示す図である。前述の図１１では眼力ポイントに応じてスカウト候補のパラメータに関する情報の開示量が変化する例を示したが、図２２では眼力ポイントに応じてスカウト候補のパラメータに関する情報の質（具体性）が変化する例を示す。

図２２は、スカウト候補提示前１シーズン（３試合）で獲得した眼力ポイントと、スカウト候補の能力パラメータに関する寸評情報（開示有無変化情報の一例）の開示確率と、の関係を示すデータテーブルである。寸評情報としては、詳しさの程度が低い順に詳しさレベル１、２及び３の３つの寸評情報があり、眼力ポイントに応じた開示確率に基づいた抽選により、何れか１つの詳しさレベルの寸評情報が開示される。詳しさレベル１の寸評情報は、例えば前述の「得意分野」であり、詳しさレベル２の寸評情報は、例えば「能力ランク」であり、詳しさレベル３の寸評情報は、例えば「能力値」である。例えば、眼力ポイント＝０の場合、「得意分野」の寸評情報は７５％、「能力ランク」の寸評情報は２０％、「能力値」の寸評情報は１０％の確率で開示される。また、例えば、眼力ポイント＝６の場合、「得意分野」の寸評情報は０％、「能力ランク」の寸評情報は４０％、「能力値」の寸評情報は６０％の確率で開示される。

図２２の例では、最も具体性の低い「得意分野」の寸評情報は、眼力ポイントが高いほど開示確率が低くなり、眼力ポイントが５以上で開示されなくなる。また、最も具体性の高い「能力値」の寸評情報は、眼力ポイントが高いほど開示確率が高くなり、眼力ポイントが９で１００％開示される。このように、眼力ポイントが高いほど具体性の高い寸評情報が開示される又は開示され易くなる。

なお、例えば、ゲームの実行結果に応じて獲得したポイントがマイナス要素のポイント（例えば、エラー数や負け数に応じたポイント等）であった場合には、獲得したポイントが多いほど、前記複数のパラメータの一部に関する情報の開示の詳しさの程度が低くなるようにしてもよい。

次に、オブジェクトグループを総合評価する構成について説明する。前記ゲームは、ユーザが獲得したオブジェクトを含むオブジェクトグループを用いたゲームとすることができる。

ここで、「オブジェクトグループ」とは、２以上のオブジェクトから構成されるグループである。「オブジェクトグループ」は、例えば、チーム、集団、隊、パーティ、ギルド等と言い換えることもできる。例えば、野球ゲームの場合、ベンチ入りして試合に出場し得る所定数（例えば２４名）の選手キャラクタで構成される野球チームが、「オブジェクトグループ」の一例に相当する。また、サッカーゲームの場合、ベンチ入りして試合に出場し得る所定数（例えば２３名）の選手キャラクタで構成されるサッカーチームが、「オブジェクトグループ」の一例に相当する。

また、「ユーザが獲得したオブジェクトを含むオブジェクトグループ」は、ユーザが獲得したオブジェクト（すなわち、複数の選択対象のオブジェクトの中からユーザが選択したオブジェクト）だけでなくその他のオブジェクトも含むオブジェクトグループであってもよいし、ユーザが獲得したオブジェクトだけで構成されるオブジェクトグループであってもよい。
例えば、ゲーム開始時は複数の初期オブジェクトのみからなるオブジェクトグループであり、ゲーム開始後にユーザが獲得したオブジェクトがオブジェクトグループに加入するようにしてもよい。
例えば、オブジェクトグループに加入した「ユーザが獲得したオブジェクト」は、オブジェクトグループ内の何れかのオブジェクト（初期オブジェクト等）との入れ替えが行われてもよいし、当該入れ替えが行われることなく単にオブジェクトグループに追加されてもよい。

前述の野球ゲームは、スカウトでユーザが獲得した選手キャラクタを含むユーザチーム（オブジェクトグループの一例）を用いたゲームであり、「ユーザが獲得したオブジェクトを含むオブジェクトグループを用いたゲーム」の一例に相当する。

図２３は、ゲームシステム１の機能的な構成の他の例を示す概略の機能ブロック図である。図１７に示すゲームシステム１の構成と同様の構成には同一の部材番号を付して、その説明を省略する。図２３に示すように、ゲームシステム１の制御部１１０は、提示部１１０１及び獲得部１１０２の他に、評価部１１０３（評価手段の一例）を含む。

評価部１１０３は、前記オブジェクトグループを構成する各オブジェクトに関連付けられている前記複数のパラメータの少なくとも一部に基づいて、当該オブジェクトグループの総合評価を行う機能を有する。

ここで、「オブジェクトグループの総合評価」とは、オブジェクトグループを構成する各オブジェクトに関連付けられている複数のパラメータの全部又は一部に基づいて、オブジェクトグループ全体を総合的に評価した結果をいう。
「オブジェクトグループの総合評価」は、例えば、総合評価値（数値）であってもよいし、A、B、C、…等の記号で表される複数段階のランク（又はレベル）であってもよいし、初級、中級、…等の段位又は称号であってもよいし、これらを組み合わせてもよい。

例えば、オブジェクトグループ内のオブジェクトの少なくとも１つのパラメータ（例えば、能力値、ランク、ポジション等のパラメータ）に基づいて各オブジェクトの評価値（オーダーポイント等）を算出し、オブジェクトグループ内の全オブジェクトの評価値に基づいて算出された値（例えば、合計値又は平均値）をオブジェクトグループの総合評価とすることができる。

なお、オブジェクトグループを構成する全てのオブジェクトを対象としてオブジェクトグループの総合評価を行うのではなく、オブジェクトグループを構成する全てのオブジェクトの中の一部のオブジェクトを対象としてオブジェクトグループの総合評価を行ってもよい。すなわち、オブジェクトグループを構成する全てのオブジェクトの中の一部のオブジェクトを対象として、当該一部のオブジェクトに関連付けられている前記複数のパラメータの少なくとも一部に基づいて、オブジェクトグループの総合評価を行うことも、「前記オブジェクトグループを構成する各オブジェクトに関連付けられている前記複数のパラメータの少なくとも一部に基づいて、当該オブジェクトグループの総合評価を行う」の一例に相当する。

「オブジェクトグループの総合評価」は、例えば、ゲームの実行結果（対戦の勝敗等）を決定するために用いられてもよいし、ユーザに付与する報酬を決定するために用いられてもよい。

前述の野球ゲームの例では、ユーザチームを構成する各選手キャラクタの総合力パラメータを合計したチーム総合力値が、ユーザチームの総合評価の一例である。チーム総合力値は、ユーザチームを構成する全ての選手キャラクタの総合力パラメータに基づいて算出してもよいし、ユーザチームを構成する全ての選手キャラクタのうちの一部の選手キャラクタの総合力パラメータに基づいて算出してもよい。
また、ユーザチームを構成する各選手キャラクタのオーダーポイントを合計した合計オーダーポイントも、ユーザチームの総合評価の一例である。

選択対象のオブジェクトに関連付けられている前記複数のパラメータには、前記オブジェクトグループ内の役割に関する役割パラメータを含めることができる。

ここで、「役割」とは、オブジェクトグループ内におけるオブジェクトの役割をいう。例えば、野球ゲームやサッカーゲーム等のスポーツゲームの場合、ポジションが「役割」の一例に相当する。また、例えば、戦闘ゲームの場合、職業が「役割」の一例に相当する。

また、「役割パラメータ」とは、オブジェクトに設定された役割を示すパラメータである。
例えば、野球ゲームの場合、「投手」または「野手」のポジションが、「役割パラメータ」の一例に相当する。また、例えば、投手のポジションを細分化した、「先発」、「中継ぎ」、「セットアッパー」または「抑え」が、「役割パラメータ」の一例に相当する。また、例えば、「野手」のポジションを細分化した、「内野手」または「外野手」が、「役割パラメータ」の一例に相当する。また、例えば、「野手」のポジションをさらに細分化した、「捕手」、「一塁手」、「二塁手」、「三塁手」、「遊撃手」、「中堅手」、「右翼手」、「左翼手」または「ＤＨ」が、「役割パラメータ」の一例に相当する。

そして、評価部１１０３は、前記オブジェクトグループを構成する各オブジェクトの前記役割パラメータに基づいて、前記総合評価を変化させる機能を有する。

ここで、「オブジェクトグループを構成する各オブジェクトの役割パラメータに基づいて、オブジェクトグループの総合評価が変化する」とは、少なくとも役割パラメータを含む各オブジェクトのパラメータに基づいてオブジェクトグループの総合評価が行われるので、役割パラメータがオブジェクトグループの総合評価の結果に影響を及ぼすことをいう。

野球ゲームの例では、投手であれば先発、中継ぎ、抑えのポジション（役割の一例）、野手であれば捕手、一塁手、二塁手、…等のポジションが決まっている。よって、例えば、メインポジション「一塁手」のパラメータが関連付けられている選手キャラクタを、一塁手以外のポジションに設定するオーダーを組むと、ポジション不適正のペナルティで、ポジション不適正がない場合よりも総合評価が低下するようにすることができる。この場合、例えばランクや能力値の高い選手キャラクタばかりを獲得しても、チーム内のポジションが重複すると、結果的にチームの総合評価は上がらない。よって、ユーザは、ポジションの重複を考慮して、どの選手キャラクタを獲得するのかを検討することを要求される。

次に、オブジェクトに使用期間を設ける構成について説明する。選択対象のオブジェクトに関連付けられている前記複数のパラメータには、オブジェクトの使用期限に関するパラメータを含めることができる。

ここで、「オブジェクトの使用期限」とは、ゲーム内でオブジェクトを使用できる期限をいう。「オブジェクトの使用期限」は、例えば、ゲーム内の仮想的な時間に基づく期限とすることができる。例えば、ゲーム内の仮想的な時間に基づく２年後の１１月末まで等の期限を、「オブジェクトの使用期限」とすることができる。また、「オブジェクトの使用期限」は、例えば、現実世界の実際の時間に基づく期限とすることができる。例えば、現実世界の今月末まで等の期限を、「オブジェクトの使用期限」とすることができる。また、「オブジェクトの使用期限」は、オブジェクトの使用回数に基づいた使用期限であってもよい。例えば、オブジェクトを３回使用したら期限が切れるというものであってもよい。スポーツゲームの例では、選手キャラクタに設定される前述の契約年数のパラメータが「オブジェクトの使用期限に関するパラメータ」の一例に相当する。

図２４は、ゲームシステム１の機能的な構成の他の例を示す概略の機能ブロック図である。図１７又は図２３に示すゲームシステム１の構成と同様の構成には同一の部材番号を付して、その説明を省略する。図２４に示すように、ゲームシステム１の制御部１１０は、提示部１１０１、獲得部１１０２及び評価部１１０３の他に、更新部１１０４（更新手段の一例）を含む。なお、図２４に例示する構成から評価部１１０３を省略することもできる。

更新部１１０４は、前記使用期限に関するパラメータに基づいて使用できなくなる１以上のオブジェクトの中からユーザの操作に基づいて選択された所定数のオブジェクトに対して、使用できるように前記使用期限に関するパラメータを更新する機能を有する。

前述の野球ゲームの例では、契約年数が０になった１以上の選手キャラクタが発生した場合に、契約更改イベントが発生する。この契約更改イベントにおいて、ユーザは契約年数が「０」になった選手キャラクタのうちから１人だけを選択する操作をして慰留する（ユーザチームに残るようにする）ことができる。そして、慰留となった選手キャラクタの契約年数パラメータは、ランダム抽選により決定された１年～５年のうちの何れかの年数に更新される例を示した。なお、更新される契約年数はこれに限定されず、例えば固定（例えば３年等）であってもよいし、契約年数によって抽選確率を異ならせてもよい（例えば、１年：１０％、２年：２５％、３年３０％、４年：２５％、５年：１０％等）。

［４．処理］
次に、本実施の形態のゲームシステム１で実行される処理の一例を以下に説明する。ここでは、前述の野球ゲームにおいてイベントモードのゲームを実行する場合のゲームシステム１の処理の一例を説明する。

図２５は、イベントモードのゲームのトップ画面の一例である。トップ画面Ｇ８００は、パーツＰ８０１～Ｐ８１５を含む。パーツＰ８０１は、年間スケジュールを確認するための画面（例えば、図６に示す情報を表示する画面）に遷移するためのパーツである。パーツＰ８０２は、イベントモードのゲーム説明が表示される画面に遷移するためのパーツである。パーツＰ８０３は、報酬一覧が表示される画面に遷移するためのパーツである。パーツＰ８０４、は現在のイベントコストを示す。パーツＰ８０５は、現在の球団ランクを示す。パーツＰ８０６は、ユーザチームの合計オーダーポイントを示す。パーツＰ８０７は、ユーザチームのチーム総合力値を示す。パーツＰ８０８は、ゲーム上の仮想的な現在の年月を示す。パーツＰ８０９は、今月のスケジュール（例えば、今月発生し得るイベント）を示す。パーツＰ８１０は、イベントオーダーを確認又は設定するためのチーム設定画面Ｇ２００（図７参照）に遷移するためのパーツである。パーツＰ８１１は、現在の眼力ポイントを示す。パーツＰ８１２は、イベントモードの試合を実行するためのパーツである。パーツＰ８１３は、スカウト方針を設定するためのパーツである。スカウト方針については後述する。パーツＰ８１４は、ミッション一覧が表示される画面に遷移するためのパーツである。パーツＰ８１５は、ユーザのマイページ画面に戻るためのパーツである。

図２６は、ゲームシステム１の処理の一例を示すフローチャートである。以下に説明する処理は、記憶装置（ＲＯＭ１２、ＲＡＭ１３、補助記憶装置１４、ＲＯＭ３２、ＲＡＭ３３又は補助記憶装置３４等）に記憶されているゲームプログラムを、制御部１１０（ゲーム端末１０のＣＰＵ１１又はサーバ３０のＣＰＵ３１）が実行することにより実現される。後述の図２７及び図２８のフローチャートに示す処理も同様である。

ユーザがイベントモードのトップ画面Ｇ８００のパーツＰ８１２を選択する操作を行うことにより、試合を開始することができる。試合が開始されると（Ｓ１００でＹＥＳ）、制御部１１０は、ユーザチームの各選手キャラクタのパラメータおよび相手チームの各選手キャラクタのパラメータに基づいて試合を実行する（Ｓ１０２）。例えば、制御部１１０は、仮想空間内で、ユーザチームに所属する選手キャラクタと対戦相手チームに所属する選手キャラクタとの両方を、それらの選手キャラクタのパラメータに基づいて仮想的に動作させることによって、試合状況を自動的に更新していく。制御部１１０はこのようにして自動的に更新される試合状況を表示部２０に表示させる。また、制御部１１０は、自動進行中の試合状況が所定状況（チャンスの状況又はピンチ状況等）になった場合に、自動進行パートからアクションパートに切り替えて、選手キャラクタに対するユーザの操作を可能とする。このアクションパートでは、制御部１１０は、ユーザの操作も基づいて選手キャラクタの動作を制御する。また、試合中は、アクションパートでのユーザの操作に基づく選手キャラクタの活躍（成績）の程度に応じて、活躍ポイントが蓄積される。なお、試合は、例えば、全て自動進行パートで進行する形式や、全てアクションパートで進行する形式であってもよい。

試合終了後、制御部１１０は、試合の実行結果に応じた眼力ポイントをユーザに付与する（Ｓ１０４）。本実施の形態では、制御部１１０は、一つの試合中にユーザが獲得した活躍ポイントの累計に応じた眼力ポイントをユーザに付与する。眼力ポイントは１シーズン（３試合）にわたって累積される。

また、制御部１１０は、試合終了後にスカウトイベントを発生させるか否かを判断する（Ｓ１０６）。ここで、ＣＰＵ１１は、各シーズン最終の５月、８月、１１月又は２月の試合終了後であれば、スカウトイベントを発生させる必要があると判断し（Ｓ１０６でＹＥＳ）、ステップＳ１０８のスカウト処理へ移行する。一方、制御部１１０は、５月、８月、１１月及び２月以外の月の試合終了後であれば、スカウトイベントを発生させる必要がないと判断し（Ｓ１０６でＮＯ）、ステップＳ１００に戻って次の試合の開始を待つ。

図２７は、図２６のステップＳ１０８のスカウト処理の一例を示すフローチャートである。制御部１１０は、スカウト処理を開始すると、スカウト可能人数を決定する（Ｓ１２０）。本実施の形態では、スカウト可能人数は球団ランクにより異なり、球団ランクが「弱小」または「普通」で２人、「強豪」以上で３人である。なお、ステップＳ１２０を実行するタイミングはこれに限定されるものではなく、図２７のスカウト処理開始から終了までの何れのタイミングで実行してもよい。

また、制御部１１０は、ユーザに提示するスカウト候補の選手キャラクタの人数を決定する（Ｓ１２２）。本実施の形態では、前述のとおりスカウト処理の直前の３試合の勝利数に基づいて、ユーザに提示されるスカウト候補の選手キャラクタの人数が２人～５人の範囲で変化する。

その後、制御部１１０は、ステップＳ１２２で決定した提示数分のスカウト候補の選手キャラクタを決定する（Ｓ１２４）。本実施の形態では、図１０に例示するように、ユーザチームの球団ランクによって、スカウト候補の選手キャラクタのランク別の抽選確率が変わる。制御部１１０は、球団ランクに応じた抽選確率を適用して、スカウト候補のランクを１人ずつ抽選で決定する。例えば、球団ランクが「強豪」であった場合、Ｂランク＝６０％、Ａランク＝３０％、Ｓランク＝１０％のランク別抽選確率を適用して、スカウト候補のランクをＢ、Ａ又はＳの何れかに決定する。その後、制御部１１０は、決定したランクを有する選手キャラクタ群の中からランダム抽選によりスカウト候補の選手キャラクタを決定する。例えば、提示するスカウト候補の人数が３人であれば、上記の処理を３回繰り返し、３人のスカウト候補の選手キャラクタを決定する。

その後、制御部１１０は、ステップＳ１２４で決定した各スカウト候補の選手キャラクタに関連付けられている複数のパラメータに関する情報のうち、開示する情報と隠す情報とを決定する（Ｓ１２６）。本実施の形態では、前述のとおり、スカウト処理直前の１シーズン中の眼力ポイントに応じて、スカウト候補に関する情報の開示の詳しさが変化する。例えば、制御部１１０は、図１１に例示する眼力ポイント別情報開示確率を適用し、ランクの情報、契約可能年数の情報および寸評情報（寸評１～寸評３のそれぞれ）を開示するか隠すかを抽選により決定する。本実施の形態では、メインポジションの情報は常に開示することとしているが、メインポジションの情報も抽選により開示の有無を変化させてもよい。

その後、制御部１１０は、ステップＳ１２６で開示することを決定した情報のみを開示し、隠すことを決定した情報をマスクして、提示数分のスカウト候補の選手キャラクタに関する情報を表示部２０に表示させる（Ｓ１２８）。これにより、例えば、図９のスカウト画面画像Ｇ４００が表示される。図９に示すように、画面上には複数のスカウト候補の選手キャラクタが表示されるが、スカウト候補によって開示される情報又は隠される情報が異なる。また、図９の例では、スカウト候補の選手キャラクタの実際の画像の代わりにシルエット画像が表示され、実際の選手名の代わりに仮の選手名（選手１～３）が表示されているので、ユーザは提示された各スカウト候補が誰なのか（どのプロ野球選手に対応している選手キャラクタなのか）がわからない。

ステップＳ１２８の実行後は図２６のステップＳ１１０に移行する。ユーザがスカウト画面画像Ｇ４００に表示されているスカウト候補の中から、スカウト可能人数以内のスカウト候補を選択する操作をした場合（Ｓ１１０でＹＥＳ）、制御部１１０は、複数の入れ替え対象の選手キャラクタの情報を表示部２０に表示させる（Ｓ１１２）。これにより、例えば、図１４の入替対象一覧画面Ｇ５００が表示される。入れ替え対象の選手キャラクタは、ユーザチームの既存のメンバである。一覧表示された複数の入れ替え対象の中からスカウト候補と入れ替えたい選手キャラクタをユーザが選択する操作を行えば（Ｓ１１４でＹＥＳ）、制御部１１０は、ユーザが選択したスカウト候補の選手キャラクタと、ユーザが選択した入れ替え対象の選手キャラクタとを入れ替える（Ｓ１１６）。すなわち、制御部１１０は、ユーザが選択したスカウト候補の選手キャラクタを、ユーザが獲得したキャラクタとしてユーザのユーザＩＤに関連付けて、所有キャラクタテーブルＴＢＬ１０３のイベントモードフィールドに記憶する。これにより、ユーザが選択したスカウト候補の選手キャラクタはユーザチームのメンバとして加入する。一方、ユーザが選択した入れ替え対象の選手キャラクタは、所有キャラクタテーブルＴＢＬ１０３のイベントモードフィールドから削除され、ユーザチームのメンバではなくなる。スカウト可能人数が２以上であり、ユーザが選択したスカウト候補が複数存在する場合、各スカウト候補に対して上記のＳ１１２～Ｓ１１６が実行される。

上記のスカウトで選手キャラクタを獲得した後は、当該選手キャラクタの全てのパラメータを確認可能である。すなわち、ユーザは、スカウト候補の選手キャラクタを獲得して初めて、その選手が誰だったのかや、確認できなかったパラメータが何だったのかが分かる。ユーザの推理が的中して強い選手キャラクタや人気の選手キャラクタを獲得できた場合には、単に強い選手キャラクタ等が獲得できた場合よりもユーザの喜びも一層大きくなる。

次に、各選手キャラクタに設定されている契約年数パラメータに基づく契約更改イベント等の処理について説明する。図２８は、契約年数パラメータに基づく処理の一例を示すフローチャートである。

制御部１１０は、契約年数パラメータを減算するタイミングを判断する（Ｓ１３０）。本実施の形態では、毎年、秋シーズンの終了（１１月の試合終了）後の所定のタイミングで契約年数パラメータを減算する。そこで、例えば、各ターンの試合終了後に、現在のターンが１１月の試合が終了した状態であるか否かを判定し、１１月の試合が終了した状態と判定すれば、契約年数パラメータを減算するタイミングであると判断する。

制御部１１０は、契約年数パラメータを減算するタイミングと判断すれば（Ｓ１３０でＹＥＳ）、ユーザチームに所属する各選手キャラクタに設定されている契約年数パラメータを「１」減算する（Ｓ１３２）。

なお、１１月の試合終了後に発生し得るイベントとしては、スカウト、契約更改、選手退団、選手加入の各イベントがあるが、ステップＳ１３２の契約年数減算処理は、前記スカウト等のイベントよりも前に実行することが望ましい。なぜならば、例えば、スカウトイベントを契約年数減算処理よりも前に実行した場合、スカウトで選手キャラクタを獲した直後に契約年数が減算されるのを回避するための特別な制御が必要になるが、契約年数減算処理をスカウトイベント等よりも前に実行すれば、そのような特別な制御は不要となるからである。

制御部１１０は、契約年数減算処理の後、所定のタイミングで（例えば、１１月のスカウトイベント終了後に）、ユーザチーム内に契約年数「０」の選手キャラクタが存在するか否かを判断する（Ｓ１３４）。ここで、契約年数「０」の選手キャラクタが１人以上存在する場合（Ｓ１３４でＹＥＳ）、契約更改イベントが発生し、制御部１１０は、契約年数「０」の選手キャラクタを慰留候補として表示部２０に表示させてユーザに提示する（Ｓ１３６）。これにより、例えば、図１６の契約更改画面Ｇ７００が表示される。

ユーザが、提示された慰留候補の選手キャラクタの中から１人を選択して慰留するための操作をすれば（Ｓ１３８でＹＥＳ）、制御部１１０は、選択された選手キャラクタの契約年数パラメータを１年～５年のうちの何れかの年数にランダムに決定し、契約年数パラメータを更新する（Ｓ１４０）。これにより、選択された慰留候補の選手キャラクタについてはユーザの所有状態が維持され、ユーザチームのメンバに留まる。その後、ステップＳ１４２へ遷移する。なお、ユーザが誰も慰留しないことを選択する操作をすれば（Ｓ１３８でＮＯ）、ステップＳ１４０が実行されずにステップＳ１４２へ遷移する。

ステップＳ１４２では、Ｓ１３６～Ｓ１４０の契約更改イベント後に、ユーザチーム内に契約年数「０」の選手キャラクタがまだ存在するか否かを判断する（Ｓ１４２）。ここで、契約年数「０」の選手キャラクタが１人以上存在する場合（Ｓ１４２でＹＥＳ）、制御部１１０は、選手退団イベントを実行する（Ｓ１４４）。この選手退団イベントでは、制御部１１０は、ユーザチーム内の契約年数「０」の選手キャラクタを、所有キャラクタテーブルＴＢＬ１０３のイベントモードフィールドから削除する。そして、制御部１１０は、契約年数「０」の選手キャラクタを画面に一覧表示し、ユーザに退団を通知する。

ユーザチームのメンバが退団したことにより、ユーザチームの人数がオーダー構成に必要な２４人よりも少なくなると、制御部１１０は、続いて選手加入イベントを実行する（Ｓ１４６）。選手加入イベントでは、制御部１１０は、退団した選手キャラクタのポジションに応じて、Ｂランクの代替の選手キャラクタをランダムに決定し、所有キャラクタテーブルＴＢＬ１０３のイベントモードフィールドにユーザＩＤと関連付けて追加する。そして、制御部１１０は、加入した選手キャラクタを画面に一覧表示し、契約の切れた選手に代わって新たな選手が加入したことをユーザに通知する。

［５．まとめ］
以上に説明した実施形態に係るゲームシステム１では、ユーザに提示された複数のスカウト候補の選手キャラクタの中からユーザが選択したものをユーザが獲得できる。ここで、複数のスカウト候補がユーザに提示される場合に、スカウト候補の選手キャラクタに関連付けられている複数のパラメータの全ては分からないように、複数のパラメータの一部に関する情報のみが開示される。これにより、開示された情報のみからどのような選手キャラクタなのかを「推理する」面白さが加味されることとなり、ゲームの興趣性を高めることができる。例えば、ユーザの推理が的中して強い選手キャラクタや人気の高い選手キャラクタが獲得できた場合には、従来のように選択時にそれが分かっている選手キャラクタを獲得できた場合よりもユーザの喜びも一層大きくなる。

例えば、現実世界の野球で高校生の選手をスカウトすることを考えると、その選手がどのような能力を持っているか全容がわからない状態でスカウトする。本実施形態に係るゲームでは、全容がわからない選手キャラクタに対して「ダイヤの原石を見極める」ようにユーザが推理を働かせてスカウトする（選手キャラクタを獲得する）醍醐味を楽しむことができる。

また、従来のゲーム（複数の獲得可能なキャラクタの中から、ユーザが獲得を希望するキャラクタを選択することができるゲーム）では、本実施形態の「推理する」という要素はない。よって、ユーザがキャラクタを選択する時点でランク等のパラメータが分かっているので、相対的にランクの高いキャラクタや人気の高いキャラクタばかりを選択する傾向にあり、ユーザに選択されるキャラクタに偏りが生じ易い。これに対して、本実施形態に係るゲームシステム１では、上記の推理の要素があるので、ユーザに選択される選手キャラクタに偏りが生じ難い。また、上記の推理のために、ユーザは部分的に開示された能力等のパラメータの情報を十分に考慮しながら選手キャラクタを吟味することになるので、普段興味のない選手キャラクタに興味を持ってもらう機会を提供することができる。例えば、ユーザが提示されたスカウト候補の選手キャラクタを推理する中で、ランクの如何に関わらずこの選手キャラクタはパワーがあって活躍しそうなので獲得したいという興味を持つことが期待できる。

また、従来では、本実施形態の「推理する」という要素はないので、ユーザがランクの高い選手や特定の球団の選手を容易に選択して獲得できる。よって、従来ではイベント期間の早い段階でチームの強化ができてしまい、その時点でユーザが遊戯をやめてしまうこともあった。これに対して実施形態に係るゲームシステム１では、上述のように「推理する」という面白さがありながらも、簡単には所望の選手キャラクタを獲得できないことも相俟ってので、ユーザが従来より長く遊戯を続けることを期待できる。

また、本実施形態に係るゲームシステム１では、スカウト候補の選手キャラクタを提示する場合、ゲームの実行結果に影響を及ぼさない選手キャラクタの「画像」及び「名称（選手名）」の情報を常に開示しない（例えば、シルエット画像等に置き換える）ようにしている。これにより、ユーザが選手キャラクタを獲得するまで、どのような選手なのかが分からないようにしている。

また、本実施形態に係るゲームシステム１では、図９に例示するように、開示されなかったパラメータに関する情報が隠されている状態の表示（例えば、情報表示欄に「？」の表示）を行い、情報を敢えて隠していることがユーザに分かるようにしている。これにより、ユーザは隠されている情報については推理しなければならないことが容易に理解できる。

また、本実施形態に係るゲームシステム１では、スカウト候補の提示前の試合の実行結果（例えば、試合で獲得した眼力ポイント）に応じた確率に基づいて、開示の有無が決定される開示有無変化情報（ランク、契約年数、寸評情報）が存在する。これにより、スカウト候補が提示される毎に、開示される情報及び開示されない情報が変化し得る。よって、ユーザによってバリエーションに富んだ推理が行われることになる。また、前記眼力ポイントに応じて開示有無変化情報の開示の詳しさ（例えば、開示される情報量の多さ又は情報の質の高さ）が変化するように、前記確率を設定している（図１１又は図２２参照）。これにより、ゲームの興趣性をさらに高めることができる。

また、本実施形態に係るゲームシステム１では、図９に例示するように、寸評情報を表示する画面上の限られた表示スペース（本実施の形態では、３つ分の寸評情報の表示スペースを有するパーツＰ４０６）に対して、図１２又は図１３に例示する６つの寸評情報の中からランダムに選択された最大３つの寸評情報が開示される。よって、限られた表示スペースに、様々な寸評情報をランダムに開示できるようになる。

また、本実施形態に係るゲームシステム１では、ユーザは単に強い選手キャラクタを獲得するのではなく、ユーザチームの総合評価（チーム総合力値または合計オーダーポイント等）を考慮して選手キャラクタを獲得することを要求される。特に、ユーザは、ボジションの重複による総合評価の影響を考慮した上で、開示されていないパラメータを推理しながらスカウト候補の選手キャラクタを選択することを要求される。よって、複数のキャラクタから構成されるグループを用いたゲームの興趣性を高めることができる。

また、本実施形態に係るゲームシステム１では、各選手キャラクタに契約年数パラメータが設定されている。また、契約年数が「０」になって使用できなくなる選手キャラクタの中からユーザが選択した選手キャラクタの契約年数が更新され、ユーザが当該選手キャラクタの使用を継続できるようにしている。これにより、ユーザは、選手キャラクタの契約年数を考慮するだけではなく、契約年数が「０」になっても選択的に継続使用できることも考慮することを要求され、ゲームの興趣性をさらに高めることができる。

［６．変形例］
本発明は以上に説明した実施形態に限定されるものではない。

［６－１］以上では、イベント期間が設けられているイベントモードのゲームについて説明したが、当該ゲームを期間の限定なくユーザがいつでも実行できる常設のゲームとしてもよい。

［６－２］スカウト候補の選手キャラクタに関連付けられている複数のパラメータの全ては分からないように、複数のパラメータの一部に関する情報のみを開示する仕様としては、下記のような仕様も適用できる。

例えば、数値パラメータの具体的な数値の特定の桁を隠して一部の桁のみを開示するようにしてもよい。具体的には、パワーの能力値が８５である場合、一桁目を隠して「パワー８？」と表示したり、二桁目を隠して「パワー？５」と表示したりしてもよい。例えば、「パワー？？」、「パワー？５」、「パワー８？」、「パワー８５」の順に具体性（情報の質）が高くなり、情報の詳しさが高まる。そこで、ユーザが獲得した眼力ポイントが大きいほど、前記の順に具体性が高くなるようにしてもよい。あるいは、ユーザが獲得した眼力ポイントが大きいほど、前記の順に具体性が高くなり易いように、図２２と同様に開示確率を設定するようにしてもよい。

また、例えば、複数のパラメータの組み合わせで特定のヒントを出すような仕様にしてもよい。例えば、複数の能力パラメータの組み合わせで特定のヒントを出してもよい。その一例としては、ミート、パワー及び走力の能力ランクが全てＡランク以上であれば、寸評情報として「超万能型の一流選手」と表示する。また、例えば、ミート及び走力の能力ランクがＡランク以上であれば、「俊足巧打の一流選手」と表示する。また、例えば、能力パラメータとポジションパラメータを組み合わせて、「俊足巧打の外野手」や「俊足巧打の中堅手」等と表示してもよい。その他、様々な種類のパラメータを組み合わせた表示が可能である。

［６－３］また、画面に提示されるスカウト候補の選手キャラクタのポジションの範囲をユーザが指定できるようにしてもよい。例えば、図２５に例示するトップ画面Ｇ８００のパーツＰ８１３を選択する操作をすれば、スカウト方針画面に遷移し、スカウト方針としてポジションの範囲をユーザが指定できるようにする。例えば、「先発」、「中継ぎ・抑え」、「捕手・内野手」、「外野手」、「希望なし」の選択肢の中から、ユーザがスカウト方針を指定できる。この場合、ユーザが指定したポジションの範囲に応じて、画面に提示されるスカウト候補の選手キャラクタが抽選される。これは、ユーザが指定した役割パラメータの範囲に応じて、提示される複数の選択対象のオブジェクトが決定される構成である。この構成は、運が悪くどうしても特定のポジションの選手キャラクタを獲得できないユーザのための救済措置とすることができる。例えば、所定の条件を満たせば、スカウト方針の指定によりポジションの絞り込みができるようにしてもよい。例えば、１サイクル以上（１２試合以上）の試合を実行した後に、スカウト方針を指定できるようにしてもよい。あるいは、所定のアイテム又はゲーム内通貨を使用すれば、スカウト方針を指定できるようにしてもよい。また、特に条件を付けずに、ユーザがいつでもスカウト方針を指定できるようにしてもよい。

［６－４］また、以上の野球ゲームの例では、イベントモードのゲーム開始時にユーザに付与される初期オーダーは、全てのユーザで固定である例を示したが、ユーザによって付与される初期オーダーが異なっていてもよい。例えば、各ユーザの初期オーダーを構成する選手キャラクタを複数の選手キャラクタの中から抽選により決定してもよい。

［６－５］また、以上の野球ゲームの例では、ユーザが獲得できるスカウト候補の選手キャラクタのランクは、Ｓランク、Ａランク、Ｂランクとしているが、これに限定するものではなく、例えば、全てのランクを対象としてもよい。また、以上の野球ゲームの例では、スカウト候補の選手キャラクタのパラメータの状態は、能力等のパラメータのレベル最大のフルスペック状態としたが、これに限定するものではない。例えば、スカウト候補の選手キャラクタを獲得した時点の初期パラメータは最大ではなく、獲得後に選手キャラクタを成長させることができる（能力等のパラメータを変更できる）ようにしてもよい。

［６－６］また、以上の野球ゲームの例では、スカウト処理の直前の３試合の勝利数に基づいて、ユーザに提示されるスカウト候補の選手キャラクタの人数が２人～５人の範囲で変化する仕様を説明した。これは一例であり、１回のスカウトで２人以上のスカウト候補の選手キャラクタがユーザに提示されるようにすればよく、提示可能数の範囲や上限数は任意に設定できる。また、提示可能数を固定にしてもよい。

［６－７］また、以上の野球ゲームの例では、スカウト可能人数は球団ランクにより異なり、球団ランクが「弱小」または「普通」で２人、「強豪」以上で３人である仕様を説明した。これは一例であり、１回のスカウトでユーザが獲得可能な選手キャラクタの人数の範囲や上限数は任意に設定できる。また、獲得可能な選手キャラクタの人数を固定にしてもよい。

［６－８］以上では、野球ゲームの例について主に説明したが、本発明は他のゲームにも適用できる。例えば、他のスポーツゲーム（サッカー、テニス、アメリカンフットボール、バスケットボール、アイスホッケー、バレーボール、ラグビー等を題材としたゲーム）、レースゲーム、格闘ゲーム、戦闘ゲーム、デジタルカードゲーム、ロールプレイングゲーム、シミュレーションゲーム、アドベンチャーゲーム又は育成ゲームのように、ゲーム形式・ジャンルを問わず、「複数の選択対象のオブジェクトの中からユーザが獲得を希望するオブジェクトを選択可能なゲーム」なら様々なゲームに適用できる。

［６－９］ゲーム端末１０とサーバ３０は、互いに通信して各種データの送受が可能であり、共にＣＰＵ、ＲＯＭ、ＲＡＭ、補助記憶装置、通信部等を備えた情報処理装置（コンピュータ）であって、基本的には同様のハード構成を有する。よって、以上に説明した各種機能の一部をゲーム端末１０のＣＰＵ１１によって実現し、残りをサーバ３０のＣＰＵ３１によって実現してもよい。又は、以上に説明した各種機能のすべてをゲーム端末１０のＣＰＵ１１によって実現してもよい。あるいは、以上に説明した各種機能のすべてをサーバ３０のＣＰＵ３１によって実現してもよい。

［６－１０］各種情報を記憶装置に記憶する記憶制御機能を有する構成に関し、記憶装置そのものについては当該構成に含まれないので、ゲームシステム１の内外を問わず、どこに設置されていてもよい。例えば、記憶装置は、ゲームシステム１内の記憶装置（（例えば、ＲＡＭ１３、補助記憶装置１４、ＲＡＭ３３、補助記憶装置３４、データベースＤＢ等）、あるいはこれらとは別構成のファイルサーバ（オンラインストレージ）等であってもよい。

［６－１１］本実施の形態に係るコンピュータ読み取り可能なプログラムは、ハードディスク、光ディスク（ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ等）、フレキシブルディスク、半導体メモリ等のコンピュータ読み取り可能な各種記録媒体に記録され、当該記録媒体から読み出されてゲームシステム１又はゲーム制御装置を構成するコンピュータのＣＰＵにより実行される。また、プログラムをコンピュータに提供する手段は、前述した記録媒体に限定されるものではなく、インターネット等の通信ネットワークを介して行うこともできる。

［７．付記］
以上の記載から本発明は例えば以下のように把握される。なお、本発明の理解を容易にするために添付図面の参照符号を便宜的に括弧書きにて付記するが、それにより本発明が図示の態様に限定されるものではない。

１）本発明の一態様に係るゲームシステム（１）は、複数の選択対象のオブジェクト（例えばスカウト候補の選手キャラクタ）の中からユーザによって選択されたオブジェクトが用いられるゲーム（例えば野球ゲーム）を提供するものであって、複数の前記選択対象のオブジェクトを提示する提示手段（１１０１）と、前記提示手段（１１０１）によって提示された複数の前記選択対象のオブジェクトの中からユーザが選択した選択対象のオブジェクトを、ユーザが獲得したオブジェクトとしてユーザのユーザ識別情報に関連付ける獲得手段（１１０２）と、を含み、前記提示手段（１１０１）は、前記選択対象のオブジェクトを提示する場合に、前記選択対象のオブジェクトに関連付けられている複数のパラメータの全ては分からないように、前記複数のパラメータの一部に関する情報のみを開示する。

１２）本発明の一態様に係るゲーム制御装置（１０又は３０）は、複数の選択対象のオブジェクト（例えばスカウト候補の選手キャラクタ）の中からユーザによって選択されたオブジェクトが用いられるゲーム（例えば野球ゲーム）を提供するものであって、複数の前記選択対象のオブジェクトを提示する提示手段（１１０１）と、前記提示手段（１１０１）によって提示された複数の前記選択対象のオブジェクトの中からユーザが選択した選択対象のオブジェクトを、ユーザが獲得したオブジェクトとしてユーザのユーザ識別情報に関連付ける獲得手段（１１０２）と、を含み、前記提示手段（１１０１）は、前記選択対象のオブジェクトを提示する場合に、前記選択対象のオブジェクトに関連付けられている複数のパラメータの全ては分からないように、前記複数のパラメータの一部に関する情報のみを開示する。

１３）本発明の一態様に係るプログラムは、１）～１１）のいずれかに記載のゲームシステム（１）、又は、１２）に記載のゲーム制御装置（１０又は３０）としてコンピュータを機能させるためのプログラムである。

１４）本発明の一態様に係る情報記憶媒体は、１３）に記載のプログラムを記録したコンピュータで読み取り可能な情報記憶媒体である。

１５）本発明の一態様に係るゲームシステム（１）の制御方法は、複数の選択対象のオブジェクト（例えばスカウト候補の選手キャラクタ）の中からユーザによって選択されたオブジェクトが用いられるゲーム（例えば野球ゲーム）を提供するゲームシステム（１）を制御する方法であって、複数の前記選択対象のオブジェクトを提示する提示ステップ（Ｓ１２８）と、前記提示ステップ（Ｓ１２８）によって提示された複数の前記選択対象のオブジェクトの中からユーザが選択した選択対象のオブジェクトを、ユーザが獲得したオブジェクトとしてユーザのユーザ識別情報に関連付ける獲得ステップ（Ｓ１２８）と、を含み、前記提示ステップ（Ｓ１２８）では、前記選択対象のオブジェクトを提示する場合に、前記選択対象のオブジェクトに関連付けられている複数のパラメータの全ては分からないように、前記複数のパラメータの一部に関する情報のみを開示する。

１６）本発明の一態様に係るゲーム制御装置（１０又は３０）の制御方法は、複数の選択対象のオブジェクト（例えばスカウト候補の選手キャラクタ）の中からユーザによって選択されたオブジェクトが用いられるゲーム（例えば野球ゲーム）を提供するゲーム制御装置（１０又は３０）を制御する方法であって、複数の前記選択対象のオブジェクトを提示する提示ステップ（Ｓ１２８）と、前記提示ステップ（Ｓ１２８）によって提示された複数の前記選択対象のオブジェクトの中からユーザが選択した選択対象のオブジェクトを、ユーザが獲得したオブジェクトとしてユーザのユーザ識別情報に関連付ける獲得ステップ（Ｓ１２８）と、を含み、前記提示ステップ（Ｓ１２８）では、前記選択対象のオブジェクトを提示する場合に、前記選択対象のオブジェクトに関連付けられている複数のパラメータの全ては分からないように、前記複数のパラメータの一部に関する情報のみを開示する。

上記１）、１２）～１６）に記載の態様によれば、ユーザに提示された複数の選択対象のオブジェクトの中からユーザが選択したものをユーザが獲得できる。ここで、複数の選択対象のオブジェクトがユーザに提示される場合に、選択対象のオブジェクトに関連付けられている複数のパラメータの全ては分からないように、複数のパラメータの一部に関する情報のみが開示される。これにより、開示された情報のみからどのようなオブジェクトなのかを「推理する」面白さが加味されることとなり、ゲームの興趣性を高めることができる。例えば、ユーザの推理が的中して強いオブジェクトが獲得できた場合には、従来のように選択時に強いことが分かっているオブジェクトを獲得できた場合よりもユーザの喜びも一層大きくなる。

また、従来では上記の「推理する」という要素はなく、ユーザは選択対象のオブジェクトのランク等のパラメータが分かっているので、相対的にランクの高いオブジェクトや人気の高いオブジェクトばかりを選択する傾向にあり、ユーザに選択されるオブジェクトに偏りが生じ易い。これに対して、上記本発明の一態様によれば、上記の推理の要素があるので、ユーザに選択されるオブジェクトに偏りが生じ難い。また、上記本発明の一態様によれば、上記の推理のために、ユーザは部分的に開示されたパラメータの情報を十分に考慮しながらオブジェクトを吟味することになるので、普段興味のないオブジェクトに興味を持ってもらう機会を提供することができる。

２）本発明の一態様では、上記１）または１２）に記載の態様において、前記選択対象のオブジェクトに関連付けられている複数のパラメータは、前記ゲームの実行結果に影響を及ぼすパラメータ（例えば、「ランク」、「能力」、「ポジション」、「利き腕（右投又は左投）」、「打撃スタイル（右打、左打又は左右両打）」、「契約年数」等のパラメータ）であってもよい。

上記２）に記載の態様によれば、ゲームの実行結果に影響を及ぼさないパラメータ（例えば、オブジェクトの「画像」や「名称」等）は、開示される可能性のある「選択対象のオブジェクトに関連付けられている複数のパラメータ」から除外できる。よって、例えば、オブジェクトの「画像」や「名称」等の情報は、常に開示されないようにできる。例えば、オブジェクトの「画像」や「名称」等から当該オブジェクトのその他のパラメータが容易に推理できるような場合には、「画像」や「名称」等は開示しないことが望ましい。

３）本発明の一態様では、上記１）または２）に記載の態様において、前記提示手段は、前記選択対象のオブジェクトを提示する場合に、開示されなかったパラメータに関する情報が隠されている状態が視認できるように画面に表示する（例えば、情報の表示欄に「？」を表示する）ようにしてもよい。

上記３）に記載の態様によれば、開示されなかったパラメータに関する情報が隠されている状態の表示を行い、情報を敢えて隠していることがユーザに分かるようにしている。これにより、ユーザは隠されている情報については推理しなければならないことが容易に理解できる。

４）本発明の一態様では、上記１）ないし３）の何れかに記載の態様において、前記複数のパラメータの一部に関する情報には、確率に基づいて開示の有無が決定される１以上の開示有無変化情報（例えば、ランク、契約年数、寸評情報）が含まれるようにしてもよい。

上記４）に記載の態様によれば、確率に基づいて開示の有無が決定される開示有無変化情報を含むことにより、開示される情報及び開示されない情報が変化する。よって、ユーザによってバリエーションに富んだ推理が行われることになり、ゲームの興趣性をさらに高めることができる。

５）本発明の一態様では、上記４）に記載の態様において、前記提示手段（１１０１）は、前記選択対象のオブジェクトを提示する前に実行された前記ゲームの実行結果（例えば、直前の３試合の実行により獲得した眼力ポイント）に基づいて決定された前記確率に基づいて、前記開示有無変化情報を開示するか否かを決定するようにしてもよい。

上記５）に記載の態様によれば、選択対象のオブジェクトを提示する前のゲームの実行結果によって、開示有無変化情報の開示確率が変化するように構成したことにより、ゲームの興趣性をさらに高めることができる。

６）本発明の一態様では、上記５）に記載の態様において、前記提示手段（１１０１）は、前記開示有無変化情報（例えば寸評情報）を開示する場合であって、当該開示有無変化情報として開示し得る複数の情報（例えば、６つの情報）が存在する場合には、当該開示し得る複数の情報の中からランダムに選択した少なくとも１つを開示するようにしてもよい。

上記６）に記載の態様によれば、開示有無変化情報を表示する画面上の限られた表示スペース（例えば３つ分の情報表示スペース）に対して、複数の情報の中からランダムに選択された情報（例えば、６つの情報からランダムに選択された最大３つの情報）が開示される。よって、限られた表示スペースに、様々な情報をランダムに開示できるようになる。

７）本発明の一態様では、上記１）ないし６）の何れかに記載の態様において、前記提示手段（１１０１）は、前記選択対象のオブジェクトを提示する前に実行された前記ゲームの実行結果（例えば、直前の３試合の実行により獲得した眼力ポイント）に基づいて、前記複数のパラメータの一部に関する情報の開示の詳しさ（例えば、開示される情報量の多さ又は情報の質の高さ）を変化させるようにしてもよい。

上記７）に記載の態様によれば、選択対象のオブジェクトを提示する前のゲームの実行結果によって、選択対象のオブジェクトに関する情報の開示の詳しさが変化するように構成したことにより、ゲームの興趣性をさらに高めることができる。

８）本発明の一態様では、上記１）ないし７）の何れかに記載の態様において、前記ゲームは、前記ユーザが獲得したオブジェクト（例えば選手キャラクタ）を含むオブジェクトグループ（例えば野球チーム）を用いたゲームであり、前記オブジェクトグループを構成する各オブジェクトに関連付けられている前記複数のパラメータの少なくとも一部に基づいて、当該オブジェクトグループの総合評価（例えば、チーム総合力値または合計オーダーポイントの算出）を行う評価手段（１１０３）をさらに含むようにしてもよい。

上記８）に記載の態様によれば、オブジェクトグループの総合評価を考慮した上で、開示されていないパラメータを推理しながら選択対象のオブジェクトを選択することを要求されるので、ゲームの興趣性をさらに高めることができる。

９）本発明の一態様では、上記８）に記載の態様において、前記複数のパラメータには、前記オブジェクトグループ内の役割（例えば、ポジション）に関する役割パラメータが含まれ、
前記評価手段（１１０３）は、前記オブジェクトグループを構成する各オブジェクトの前記役割パラメータに基づいて、前記総合評価を変化させるようにしてもよい。

上記９）に記載の態様によれば、オブジェクトグループ内の役割が決まっているので、役割パラメータが重複するオブジェクトを獲得してもオブジェクトグループの総合評価を高めることができない。よって、ユーザは役割パラメータの重複による総合評価の影響を考慮した上で、開示されていないパラメータを推理しながら選択対象のオブジェクトを選択することを要求されるので、ゲームの興趣性をさらに高めることができる。

１０）本発明の一態様では、上記１）ないし９）の何れかに記載の態様において、前記複数のパラメータには、オブジェクトの使用期限に関するパラメータ（例えば契約年数パラメータ）が含まれるようにしてもよい。

上記１０）に記載の態様によれば、オブジェクトに関連付けられている使用期限に関するパラメータを考慮して、開示されていないパラメータを推理しながら選択対象のオブジェクトを選択することを要求されるので、ゲームの興趣性をさらに高めることができる。

１１）本発明の一態様では、上記１０）に記載の態様において、前記使用期限に関するパラメータに基づいて使用できなくなる１以上のオブジェクトの中からユーザの操作に基づいて選択された所定数のオブジェクトに対して、使用できるように前記使用期限に関するパラメータを更新する更新手段（１１０４）をさらに含むようにしてもよい。

上記１１）に記載の態様によれば、使用期限により使用できなくなるオブジェクトの中からユーザが選択したオブジェクトの使用期限に関するパラメータが更新され、ユーザが当該オブジェクトの使用を継続できるようになる。これにより、ユーザは、オブジェクトの使用期限を考慮するだけではなく、オブジェクトの使用期限が切れても選択的に継続使用できることも考慮することを要求され、ゲームの興趣性をさらに高めることができる。

１…ゲームシステム、Ｎ…ネットワーク、ＤＢ…データベース、１０…ゲーム端末、１１…ＣＰＵ、１３…ＲＡＭ、１４…補助記憶装置、２０…表示部、３０…サーバ、３１…ＣＰＵ、３３…ＲＡＭ、３４…補助記憶装置、１００…データ記憶部、１１０…制御部、１１０１…提示部、１１０２…獲得部、１１０３…評価部、１１０４…更新部、ＴＢＬ１０１…ユーザ情報テーブル、ＴＢＬ１０２…キャラクタ情報テーブル、ＴＢＬ１０３…所有キャラクタテーブル、ＴＢＬ１０４及びＴＢＬ１０５…寸評情報テーブル、ＤＴ１０６…ユーザチームデータ

Claims (13)

1. 複数の選択対象のオブジェクトの中からユーザによって選択されたオブジェクトが用いられるゲームを提供するゲームシステムであって、
   複数の前記選択対象のオブジェクトを提示する提示手段と、
   前記提示手段によって提示された複数の前記選択対象のオブジェクトの中からユーザが選択した選択対象のオブジェクトを、ユーザが獲得したオブジェクトとしてユーザのユーザ識別情報に関連付ける獲得手段と、
   を含み、
   前記提示手段は、前記選択対象のオブジェクトを提示する場合に、前記選択対象のオブジェクトに関連付けられている複数のパラメータの全ては分からないように、前記複数のパラメータの一部に関する情報のみを開示する
   ゲームシステム。
2. 前記選択対象のオブジェクトに関連付けられている複数のパラメータは、前記ゲームの実行結果に影響を及ぼすパラメータである
   請求項１に記載のゲームシステム。
3. 前記提示手段は、前記選択対象のオブジェクトを提示する場合に、開示されなかったパラメータに関する情報が隠されている状態が視認できるように画面に表示する
   請求項１または２に記載のゲームシステム。
4. 前記複数のパラメータの一部に関する情報には、確率に基づいて開示の有無が決定される１以上の開示有無変化情報が含まれている
   請求項１ないし３の何れか１項に記載のゲームシステム。
5. 前記提示手段は、前記選択対象のオブジェクトを提示する前に実行された前記ゲームの実行結果に基づいて決定された前記確率に基づいて、前記開示有無変化情報を開示するか否かを決定する
   請求項４に記載のゲームシステム。
6. 前記提示手段は、前記開示有無変化情報を開示する場合であって、当該開示有無変化情報として開示し得る複数の情報が存在する場合には、当該開示し得る複数の情報の中からランダムに選択した少なくとも１つを開示する
   請求項５に記載のゲームシステム。
7. 前記提示手段は、前記選択対象のオブジェクトを提示する前に実行された前記ゲームの実行結果に基づいて、前記複数のパラメータの一部に関する情報の開示の詳しさを変化させる
   請求項１ないし６の何れか１項に記載のゲームシステム。
8. 前記ゲームは、前記ユーザが獲得したオブジェクトを含むオブジェクトグループを用いたゲームであり、
   前記オブジェクトグループを構成する各オブジェクトに関連付けられている前記複数のパラメータの少なくとも一部に基づいて、当該オブジェクトグループの総合評価を行う評価手段をさらに含む
   請求項１ないし７の何れか１項に記載のゲームシステム。
9. 前記複数のパラメータには、前記オブジェクトグループ内の役割に関する役割パラメータが含まれ、
   前記評価手段は、前記オブジェクトグループを構成する各オブジェクトの前記役割パラメータに基づいて、前記総合評価を変化させる
   請求項８に記載のゲームシステム。
10. 前記複数のパラメータには、オブジェクトの使用期限に関するパラメータが含まれる
    請求項１ないし９の何れか１項に記載のゲームシステム。
11. 前記使用期限に関するパラメータに基づいて使用できなくなる１以上のオブジェクトの中からユーザの操作に基づいて選択された所定数のオブジェクトに対して、使用できるように前記使用期限に関するパラメータを更新する更新手段をさらに含む
    請求項１０に記載のゲームシステム。
12. 複数の選択対象のオブジェクトの中からユーザによって選択されたオブジェクトが用いられるゲームを提供するゲーム制御装置であって、
    複数の前記選択対象のオブジェクトを提示する提示手段と、
    前記提示手段によって提示された複数の前記選択対象のオブジェクトの中からユーザが選択した選択対象のオブジェクトを、ユーザが獲得したオブジェクトとしてユーザのユーザ識別情報に関連付ける獲得手段と、
    を含み、
    前記提示手段は、前記選択対象のオブジェクトを提示する場合に、前記選択対象のオブジェクトに関連付けられている複数のパラメータの全ては分からないように、前記複数のパラメータの一部に関する情報のみを開示する
    ゲーム制御装置。
13. コンピュータを請求項１ないし１１の何れか１項に記載のゲームシステムまたは請求項１２に記載のゲーム制御装置としてコンピュータを機能させるためのプログラム。

Images