JP5820418B2 - ゲーム管理装置及びプログラム - Google Patents

Description

本発明は、ゲームを管理するゲーム管理装置、ゲームシステム、ゲーム管理方法及びプログラムに関するものである。

従来から、インターネット上に設置されたゲームサーバに、ユーザの端末装置（パーソナルコンピュータ、携帯電話端末等）を接続することによって、ユーザがゲームサーバから提供される各種ゲームサービスを受けることができるゲームシステムがある（特許文献１等）。また、プロ野球の対戦結果などを予想する予想ゲームのサービスを提供するゲームシステムもある（特許文献２）

特開２０１１−３０８９２号公報 特開２００２−８３２１５号公報

ユーザが予想ゲームで予想を行う場合、その予想ゲームで対象としている分野（例えば、野球、競馬等）の知識が乏しいユーザにとっては、予想に困ることもある。

本発明は、上記の事情に鑑みてなされたものであり、その目的は、ユーザが円滑に予想の入力を行うことができる、ユーザフレンドリーなゲーム環境を提供することである。

１）本発明の一局面によるゲーム管理装置（1,2,101,301）は、現実世界またはゲーム内で発生する結果を予想する予想ゲームを管理するものであって、過去の予想ゲームの結果、または各ユーザが現在予想中の情報に基づいて、ユーザの予想を補助するための予想補助情報を生成する予想補助情報生成手段（71）と、ユーザが予想入力を行うための入力画面内に、前記予想補助情報を表示させる表示制御手段（72）と、を備える。

この構成のゲーム管理装置は、例えば各ユーザのゲーム端末（端末装置）と通信を行うことができるサーバなどの情報処理装置（コンピュータ）により構成することができる。あるいは、本ゲーム管理装置は、ゲーム端末としての情報処理装置により構成することもできる。あるいは、本ゲーム管理装置は、相互に通信する複数の情報処理装置（サーバ、ゲーム端末）により構成することもできる。

本ゲーム管理装置が管理する予想ゲームは、現実世界で発生する結果を予想するものと、ゲーム内で発生する結果を予想するものの何れであってもよい。現実世界で発生する結果を予想するゲームとしては、例えば、実在する野球の選手またはチームの活躍を予想するものが挙げられる。その他に、サッカー等の各種スポーツ競技、競馬レース、カーレース、テレビ等の放送番組で行われるクイズ等、現実世界で発生する様々な結果を対象とした予想ゲームが適用できる。ゲーム内で発生する結果を予想するゲームとしては、ゲーム内に存在する複数のキャラクタ（例えば、野球ゲームの選手キャラクタ、競馬ゲームの競走馬キャラクタ等）またはチームの中から活躍するキャラクタまたはチームを予想するものが挙げられる。

本ゲーム管理装置は、ユーザが予想入力を行うための入力画面内に、ユーザの予想を補助するための予想補助情報を表示させる。これにより、ユーザは入力画面内で予想補助情報を見てそれを参考にしながら、予想の入力を行うことができる。これを実現するゲーム管理装置は、予想補助情報生成手段および表示制御手段を備えている。

予想補助情報生成手段は、過去の予想ゲームの結果、または各ユーザが現在予想中の情報に基づいて予想補助情報を生成する。過去の予想ゲームの結果に基づく予想補助情報には、予想対象（実在選手、キャラクタ、チーム等）を過去の評価の順に並べたランキング情報等がある。また、各ユーザが現在予想中の情報に基づく予想補助情報には、予想対象である実在選手、キャラクタ、チーム等の人気の程度を示す情報（どの予想対象にみんなが予想しているかを示す情報）等がある。そして、表示制御手段は、ユーザが予想入力を行うための入力画面内に、予想補助情報生成手段が生成した前記予想補助情報を表示させる。

例えば、野球を対象とした予想ゲームでは、ユーザが野球に詳しくなければ、どの選手が活躍するのかを予想するのが難しく感じることもある。このように、予想ゲームで対象としている分野の知識が乏しいユーザにとっては、予想に困ることもある。これに対して、本構成では、ユーザは、予想の入力画面内で、予想補助情報を見て、予想の手がかりを得ることができる。よって、予想ゲームで対象としている分野（例えば野球）にあまり詳しくないユーザ等であっても、それほど予想に困ることなく、予想の入力を行うことができる、ユーザフレンドリーなゲーム環境を実現できる。

２）上記の構成において、前記予想ゲームは、ゲーム内に存在する複数のキャラクタの中から活躍するキャラクタを予想するゲームを含み、ユーザが所有しているキャラクタの中から任意のキャラクタを選択したユーザからの予想入力を受け付ける予想受付手段（73）と、所定期間内に各ユーザがゲーム内で使用したキャラクタについてのゲーム結果を集計して、キャラクタ毎に活躍を評価する評価手段（74）と、ユーザが予想入力したキャラクタの前記評価に応じた特典をユーザに付与する特典付与手段（75）と、をさらに備えることが好ましい。

この構成によれば、ユーザは、ゲーム内に存在する複数のキャラクタの中から活躍するキャラクタを予想することができる。ユーザは、自分が所有しているキャラクタの中から、活躍しそうな任意のキャラクタを選択し、入力画面で予想補助情報を参考にしながら予想を入力する。ユーザの予想入力は、予想受付手段によって受け付けられる。このように、本構成では、ゲーム内の全てのキャラクタを対象として活躍を予想できるわけではなく、自分の手持ちのキャラクタの中から予想対象を選択する必要がある。よって、活躍しそうなキャラクタを所有していないユーザは、先ずゲーム内でそれを入手する必要がある。すなわち、各ユーザは自分が所有しているキャラクタの範囲内で予想を行なうことができ、その予想結果に応じた特典を獲得するのであるが、もし予想に該当するキャラクタを自分が所有していなければ、まずはそれを入手する必要がある、というこれまでにない面白みのあるゲーム性を実現している。

また、評価手段は、所定期間内（例えば０時から２４時までの２４時間）に各ユーザがゲーム内で使用したキャラクタについてのゲーム結果を集計し、キャラクタ毎に活躍を評価する。一例として、ユーザが現実世界の野球選手に対応した選手キャラクタを所有し、当該選手キャラクタを用いて自分のチームをつくって相手（他のユーザまたはＣＰＵ）と対戦する野球ゲームについて説明する。このような野球ゲームにおいて、ゲーム管理装置は、各ユーザがゲーム内で使用した選手キャラクタの安打数等のゲーム結果を集計する。そして、選手キャラクタ毎に、安打数の全体平均等を算出して活躍を評価する。

ここで「活躍」に関し、例えば野球ゲームでは、野手キャラクタによるヒット、盗塁、ファインプレイ等、投手キャラクタによる奪三振、勝利、セーブ等が含まれる。勝利した側のチームに貢献したキャラクタだけを活躍の評価対象とすることもできるが、負けたチームのキャラクタであっても、ヒットを打ったりファインプレイをしたりすれば、そのキャラクタの活躍を評価の対象とすることができる。ゲーム内で各ユーザが使用したキャラクタを対象として、ゲーム内集計が行われるので、基本的に、各キャラクタの個人成績（記録）を活躍の評価対象とすることが好ましい。他の例としては、競馬ゲームにおいて、優勝した競走馬キャラクタだけを活躍の評価対象とすることもできるが、例えば３着以内に入った競走馬キャラクタも活躍の評価対象とすることもできる。これらはほんの一例であり、キャラクタの活躍については、ゲームの種類、内容に応じた様々な形態を含む。

そして、特典付与手段は、ユーザが予想入力したキャラクタの前記評価に応じた特典をユーザに付与する。ここで、「特典」については、ゲーム内ポイントまたはアイテムの付与、キャラクタの能力向上、レアアイテムの抽選確率の上昇など、ゲームの種類や内容に応じた様々な特典を適用できる。

このように、本構成では、各ユーザがゲーム内で使用するキャラクタについてのゲーム結果を集計して、ゲーム内の各キャラクタの活躍を評価するので、現実世界で予想の対象となる野球の試合等が行われない日にも（例えば野球のオフシーズンにも）、ユーザが安定的に予想ゲームを遊戯できるようになる。

また、本構成においては、各ユーザがゲーム内で使用したキャラクタの活躍が、予想ゲームにおけるそのキャラクタの活躍の全体評価にも反映される。すなわち、各ユーザによるキャラクタを使用した遊戯が予想ゲームとリンクしている。このことから、各ユーザは、特に自分が活躍予想をしたキャラクタを使用して遊戯する場合、そのキャラクタに対してより良いゲーム結果を出せるように遊戯を行なおうとする。これにより、予想ゲームにリンクしているゲーム内の遊戯モードの興趣性を高めることができる。

３）上記の１）または２）の構成において、前記予想補助情報には、各キャラクタを過去の評価の順に並べたランキング情報を含み、前記入力画面内に前記ランキング情報として並べられた各キャラクタのうち、ユーザが所有しているキャラクタをユーザに報知する報知手段（76）をさらに備えることが好ましい。

この構成によれば、ユーザが予想を行う入力画面内に、予想補助情報として、各キャラクタを過去の評価の順に並べたランキング情報が表示される。例えば、前回の予想ゲームについてのキャラクタのランキング情報が、入力画面に表示される。さらに、入力画面内にランキング情報として並べられた各キャラクタのうち、ユーザが所有しているキャラクタがユーザに報知される。この予想ゲームでは、ユーザは、自分が所有しているキャラクタだけを予想の対象にすることができるが、ランキング情報に自分が所有しているキャラクタが報知されることにより、ランキング情報を参考にした予想入力を円滑に行うことができるようになる。もし、ランキング情報の中に、ユーザが所有しているキャラクタがない場合は、そのキャラクタを入手しようとする動機づけが与えられ、ゲームが活性化される。

また、報知されたキャラクタが高ランクであれば、次の予想ゲームでも高位置にランクされる可能性があることから、ユーザは、そのキャラクタの活躍を予想して入力するといった対応が可能となる。また、前記の報知により、せっかく自分が保有していながらも、前回の予想ゲームで活躍予想の入力をしなかったキャラクタが高ランクになってしまったというケースも判明する。この場合、ユーザに対して、次はそのキャラクタの活躍を予想した入力をしようとする動機付けを与える。このように、過去（例えば前回）の予想ゲームのランキング結果を入力画面に表示し、且つ、その中でユーザが所有しているキャラクタを報知することにより、ゲーム性を高めることができる。

４）上記の３）の構成において、ユーザに関係付けられた第２のユーザを管理する関係管理手段（77）をさらに備え、前記予想受付手段（73）は、前記第２のユーザが所有している特定のキャラクタを選択したユーザからの予想入力も受け付け、前記報知手段（76）は、前記入力画面内に前記ランキング情報として並べられた各キャラクタのうち、前記第２のユーザが所有している特定のキャラクタもユーザに報知することが好ましい。

本ゲーム管理装置は、ユーザと所定の関連付けがなされている仲間などの第２のユーザを管理する管理手段を備えている。ここで、仲間とは、ゲーム内で構築されるユーザ同士の仮想的な関係の総称であり、知人、友人、友達、クラスメイト、相棒、親類、家族、兄弟、姉妹、会社や組織の同僚などの様々なゲーム内の関係を含む。なお、ユーザと関連付けがなされている他のユーザ（第２のユーザ）であれば、仲間という関係でなくてもよい。ただし、以下の説明では、第２のユーザを、便宜上、仲間と称する。

前述のように、本構成では、ゲーム内の全てのキャラクタを対象として活躍を予想できるわけではなく、予想対象は自分の手持ちのキャラクタに限定される。この場合、手持ち以外のキャラクタを予想対象としたい場合は、まず、そのキャラクタをゲーム内で入手する必要があるが、直ちに所望のキャラクタを入手できるとは限らない。そこで本構成では、ユーザは、自分の仲間が所有している特定のキャラクタも、予想入力の対象とすることができるようにしている。すなわち、ユーザは、仲間が所有している特定のキャラクタを借りて予想対象を拡大することができる。

ここで、仲間が所有している特定のキャラクタとは、例えば、その仲間が貸出可能な設定をしているキャラクタとすることができる。また、特定のキャラクタは、仲間が所有するキャラクタの中で、最も能力の高いキャラクタであってもよい。また、特定のキャラクタは、仲間が所有する最も希少度レベルの高いキャラクタの中からランダムに選択されたキャラクタであってもよい。あるいは、特定のキャラクタは、仲間のチームオーダーの４番打者のキャラクタであってもよい。これらは一例であり、ユーザの仲間が所有するキャラクタの中で、所定の条件を満たすキャラクタを、特定のキャラクタとすることができる。

そして、入力画面内にランキング情報として並べられた各キャラクタのうち、仲間が所有している特定のキャラクタもユーザに報知される。これにより、どのキャラクタを仲間から借りて予想できるのかが、ランキング情報の中で明確化されるので、ユーザは円滑に予想入力を行うことができる。

また、本構成では、ユーザは、仲間が所有している特定のキャラクタを借りて予想対象を拡大することができるので、仲間が多いほど、予想対象のキャラクタが拡大する。よって、各ユーザは、積極的に多くの仲間を作ろうとする動機付けを与えられることになる。そして、各ユーザに仲間が増えることにより、ゲーム全体の活性化が図られる。

５）上記の４）の何れかの構成において、ユーザによって、前記第２のユーザが所有している特定のキャラクタを選択した予想入力が行われた場合、当該第２のユーザに対して報酬を付与する報酬付与手段（78）をさらに備えることが好ましい。

この構成によれば、ユーザＡが仲間であるユーザＢ（第２のユーザ）のキャラクタを借りて活躍予想をすれば、ユーザＢに報酬が与えられる。ここで、「報酬」については、ゲーム内ポイントまたはアイテムの付与、キャラクタの能力向上、レアアイテムの抽選確率の上昇など、ゲームの種類や内容に応じた様々な報酬を適用できる。ユーザＢのキャラクタを借りて予想をしたユーザＡは、ユーザＢに感謝するし、それによって報酬を得たユーザＢも、自分のキャラクタを活躍予想に使ってくれたユーザＡに感謝することが期待される。本構成により、予想対象のキャラクタの貸し借りを通して、仲間同士のゲーム内交流をより深めることができる。

６）上記の２）ないし５）の何れかの構成において、前記予想受付手段（73）は、予想対象のキャラクタに重みを設定したユーザからの予想入力を受け付け、前記特典付与手段（75）は、ユーザが予想入力したキャラクタの前記評価および前記重みに応じた特典をユーザに付与し、各キャラクタに設定可能な前記重みの上限を、各キャラクタの希少度に応じて異ならせる上限管理手段（79）をさらに備えることが好ましい。

この構成によれば、予想の重みづけが可能である。例えば、各ユーザが活躍しそうなキャラクタに予想用アイテム（又はポイント）を設定することで予想の入力を行う場合、設定する予想用アイテム数（又はポイント数）により、予想の重み付けを行うことができる。そして、キャラクタに設定した予想の重みが、予想ゲームにおける特典に反映される。

ここで、各キャラクタに設定可能な前記重みの上限は、各キャラクタの希少度（レアリティ）に応じて異なっている。すなわち、同じキャラクタでも、その希少度によって、ユーザが設定できる予想の重みの上限が違う。例えば、キャラクタには、１（最低）〜５（最高）の５段階の希少度の何れかが設定されている。そして、キャラクタの希少度とそのキャラクタに設定できる重み（例えば予想用アイテム数）の上限との関係は、例えば、希少度１：８、希少度２：１０、希少度３：１２、希少度４：１４、希少度５：１６となっており、希少度が高いほど重みの上限も大きくなる。ユーザは、より大きな重みを設定するには、より高い希少度のキャラクタを所有している必要がある。本構成により、ユーザに対して、希少度の高いキャラクタを入手しようとする動機付けを与えることができる。

７）上記の２）ないし６）の何れかの構成において、前記予想補助情報には、各ユーザが現在予想中の情報をまとめた統計情報であって、各キャラクタの人気の程度を示す情報を含むことが好ましい。

例えば、各ユーザが活躍しそうなキャラクタに予想用アイテム（又はポイント）を設定する予想ゲームでは、全ユーザがキャラクタに設定している予想用アイテムの情報を集計する。そして、ゲーム内のキャラクタ毎に、現在設定されている平均の予想用アイテム数、予想用アイテムを設定している人数、設定されている予想用アイテムの総数などの統計情報を求め、これを各キャラクタの人気の程度を示す情報とすることができる。このような情報を予想補助情報として、ユーザが予想入力を行うための入力画面内に表示するので、ユーザはこれを予想の手がかりとすることができる。よって、予想に困ることなく予想入力が可能なユーザフレンドリーなゲーム環境を実現できる。

８）上記の１）ないし７）の何れかの構成において、前記予想ゲームは、ゲーム内に存在する複数のチームの中から活躍するチームを予想するゲームを含み、前記複数のチームの中の何れかのチームと、各ユーザとを関係付ける関係付け手段（80）と、前記複数のチームの中から任意のチームを選択したユーザからの予想入力を受け付ける第２予想受付手段（81）と、所定期間内に各ユーザが実行したゲーム結果を集計して、各ユーザに関係付けられているチーム毎に活躍を評価する第２評価手段（82）と、ユーザが予想入力したチームの前記評価に応じた特典をユーザに付与する第２特典付与手段（83）と、をさらに備えることが好ましい。

この構成によれば、ユーザは、ゲーム内に存在する複数のチームの中から活躍するチームを予想することができる。野球ゲームを例に挙げると、ゲーム内に現実世界のプロ野球（またはＭＬＢ）の球団に対応する複数のチームが存在し、その中のチームを対象として上位にランキングされそうなチームを予想する。ゲーム内のチームは、各ユーザが実行したゲーム結果を集計して、以下のようにして評価される。

先ず、ゲーム内の複数のチームの中の何れかのチームと、各ユーザとが関係付けられている。例えば、ユーザがゲーム内の複数のチームの中から任意に選んだお気に入りチームと、そのユーザの識別情報（ユーザＩＤ）とが関係付けられて、記憶装置に記憶される。

ユーザによるチームの予想対象は、必ずしもそのユーザに関係付けられているチームに限定されるものではなく、ゲーム内に存在する全てのチームを対象とすることができる。

また、第２評価手段は、所定期間内（例えば０時から２４時までの２４時間）に各ユーザが実行したゲーム結果を集計して、各ユーザに関係付けられているチーム毎に活躍を評価する。例えば、各ユーザが相手（他のユーザまたはＣＰＵ）と対戦した勝敗のゲーム結果を集計する。そして、ゲーム内のチーム毎に、勝率等を算出して活躍を評価する。

そして、第２特典付与手段は、ユーザが予想入力したチームの前記評価に応じた特典をユーザに付与する。このように、本構成では、各ユーザが通常行う遊戯のゲーム結果を集計して、ゲーム内のチームの活躍を評価するので、現実世界で予想の対象となる野球の試合等が行われない日にも（例えば野球のオフシーズンにも）、ユーザが安定的に予想ゲームを遊戯できるようになる。

また、各ユーザには、ゲーム内の複数のチームの何れかが対応づけられているので、ユーザのゲーム結果が、予想ゲームにおけるそのチームの活躍の全体評価にも反映される。すなわち、各ユーザによる遊戯が予想ゲームとリンクしている。このことから、各ユーザは、特に自分に関係付けられているチームを活躍するチームとして予想した場合、自分自身が良いゲーム結果を出せるように遊戯を行なおうとする。これにより、予想ゲームにリンクしているゲーム内の遊戯モードの興趣性を高めることができる。

９）上記の１）ないし８）の何れかの構成において、ゲーム内には現実世界に存在する複数の実在物のそれぞれに対応する複数のキャラクタが存在し、前記予想ゲームは、前記複数の実在物の中から活躍する実在物を予想するゲームを含み、ユーザが所有しているキャラクタの中から、現実世界での活躍を予想した実在物に対応するキャラクタを選択したユーザからの予想入力を所定の期限まで受け付ける第３予想受付手段（84）と、前記期限以降に、前記実在物の現実世界での活躍を評価する第３評価手段（85）と、ユーザが予想入力したキャラクタに対応した実在物の前記評価に応じた特典をユーザに付与する第３特典付与手段（86）と、をさらに備えることが好ましい。

この構成によれば、現実世界に存在する複数の実在物（例えば、野球選手）とゲーム内の複数のキャラクタとが対応している。ユーザは、複数の実在物の中から現実世界で活躍する実在物を予想することができる。ただし、ユーザが予想対象とすることができる実在物は、ユーザが所有しているキャラクタに対応する実在物だけである。よって、活躍しそうな実在物に対応するキャラクタを所有していないユーザは、先ずゲーム内でそれを入手する必要がある。すなわち、各ユーザはゲーム内でキャラクタを入手し、そのキャラクタを介して実在物の活躍を予想し、予想結果に応じた特典を獲得するというこれまでにない面白みのあるゲーム性を実現している。

前述のように、ユーザが予想入力を行うための入力画面内には、ユーザの予想を補助するための予想補助情報が表示される。例えば、過去の予想ゲームの結果に基づいて、実在選手に対応するキャラクタを、実在選手の過去の評価の順に並べたランキング情報等が入力画面に表示される。ユーザの予想入力は、第３予想受付手段により、所定の期限（例えば、対象となる野球の試合の開始時間）まで受け付けられる。この期限以降、実在物の現実世界での活躍が第３評価手段により評価される。例えば、実在物が野球選手の場合、野手によるヒット、盗塁、ファインプレイ等、投手による奪三振、勝利、セーブ等の活躍が評価される。評価の一例を挙げると、１安打の活躍度を「１０」、２安打の活躍度を「１５」、３安打以上の活躍度を「２０」等として、評価（活躍度の値）が求められる。

そして、第３特典付与手段は、ユーザが予想入力したキャラクタに対応した実在物の前記評価に応じた特典をユーザに付与する。本構成でも、ユーザは、予想の入力画面内で、予想補助情報を見て、予想の手がかりを得ることができる。よって、予想ゲームで対象としている分野（例えば野球）に詳しくないユーザであっても、それほど予想に困ることなく、予想の入力を行うことができる、ユーザフレンドリーなゲーム環境を実現できる。

１０）上記の１）ないし９）の何れかの構成において、前記予想ゲームは、現実世界に存在する複数の実在チームの中から活躍する実在チームを予想するゲームを含み、前記複数の実在チームの中から任意の実在チームを選択したユーザからの予想入力を所定の期限まで受け付ける第４予想受付手段（94）と、前記期限以降に、前記実在チームの現実世界での活躍を評価する第４評価手段（95）と、ユーザが予想入力した実在チームの前記評価に応じた特典をユーザに付与する第４特典付与手段（96）と、をさらに備えることが好ましい。

この構成によれば、ユーザは、現実世界に存在する複数の実在チーム（例えばプロ野球１２球団、ＭＬＢの３０球団等）の中から活躍する実在チームを予想することができる。例えば、ユーザは、現実世界のプロ野球の対戦カードに対して、勝利する側のチームを予想することができる。

ユーザの予想入力は、第３予想受付手段により、所定の期限（例えば、対象となる野球の試合の開始時間）まで受け付けられる。この期限以降、実在チームの現実世界での活躍が第４評価手段により評価される。そして、ユーザが予想入力した実在チームの前記評価に応じた特典がユーザに付与される。例えば、ユーザが予想入力した実在チームが現実世界で勝利したチームとして評価された場合、ユーザに特典（ポイント、アイテム等）が付与される。

本構成においても、ユーザが予想入力を行うための入力画面内には、ユーザの予想を補助するための予想補助情報が表示される。例えば、各実在チームの前日の勝敗情報、前週の勝率等の情報が入力画面に表示される。よって、予想ゲームで対象としている分野（例えば野球）に詳しくないユーザであっても、それほど予想に困ることなく、予想の入力を行うことができる、ユーザフレンドリーなゲーム環境を実現できる。

１１）本発明の他の一局面によるゲームシステムは、サーバ（1,2,101）と、当該サーバ（1,2,101）との間で通信を行う端末装置（3,301）と、を含み、現実世界またはゲーム内で発生する結果を予想する予想ゲームを管理するゲームシステムであって、過去の予想ゲームの結果、または各ユーザが現在予想中の情報に基づいて、ユーザの予想を補助するための予想補助情報を生成する予想補助情報生成手段（71）、ユーザが予想入力を行うための入力画面内に、前記予想補助情報を表示させる表示制御手段（72）、を前記サーバ（1,2,101）又は前記端末装置（3,301）のいずれか一方が備える。

１２）本発明の他の一局面によるゲーム管理方法は、現実世界またはゲーム内で発生する結果を予想する予想ゲームの管理を行うコンピュータにおけるゲーム管理方法であって、コンピュータが、過去の予想ゲームの結果、または各ユーザが現在予想中の情報に基づいて、ユーザの予想を補助するための予想補助情報を生成する予想補助情報生成ステップと、コンピュータが、ユーザが予想入力を行うための入力画面内に、前記予想補助情報を表示させる表示制御ステップと、を含む。

１３）本発明の他の一局面によるプログラムは、コンピュータを、現実世界またはゲーム内で発生する結果を予想する予想ゲームを管理するゲーム管理装置（1,2,101,301）として動作させるためのプログラムであって、前記コンピュータを、過去の予想ゲームの結果、または各ユーザが現在予想中の情報に基づいて、ユーザの予想を補助するための予想補助情報を生成する予想補助情報生成手段（71）、ユーザが予想入力を行うための入力画面内に、前記予想補助情報を表示させる表示制御手段（72）、として機能させるためのプログラムある。

本発明によれば、予想ゲームにおいて、ユーザが円滑に予想の入力を行うことができる、ユーザフレンドリーなゲーム環境を提供することができる。

本発明の一実施の形態に係るゲームシステムの構成例を示す説明図である。 ゲーム管理装置のハード構成の一例を示すブロック図である。 端末装置のハード構成の一例を示すブロック図である。 選手データベースの一例を示す説明図である。 ユーザが予想入力を行うための入力画面の一例を示す説明図である。 ユーザが予想入力を行うための入力画面の他の例を示す説明図である。 ユーザが予想入力を行うための入力画面の他の例を示す説明図である。 ユーザが予想入力を行うための入力画面の他の例を示す説明図である。 ゲーム管理装置の基本的な機能的構成の一例を示す機能ブロック図である。 ユーザ情報データベースの一例を示す説明図である。 ユーザが組んだオーダー情報の一例を示す説明図である。 対戦結果の情報の一例を示す説明図である。 ゲーム管理装置の主要な機能的構成の一例を示す機能ブロック図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 ユーザの予想入力情報の一例を示す説明図である。 野手の評価用情報の一例を示す説明図である。 先発投手の評価用情報の一例を示す説明図である。 リリーフ投手の評価用情報の一例を示す説明図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 キャラクタの希少度と設定可能なホープ数の上限との関係を示す説明図である。 ゲームサーバの動作の一例を示すフローチャートである。 ゲームサーバの動作の一例を示すフローチャートである。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 ユーザの予想入力情報の他の例を示す説明図である。 チームの評価用情報の一例を示す説明図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 ゲームシステムの他の構成例を示すブロック図である。 ゲームシステムの他の構成例を示すブロック図である。

以下、本発明の一実施の形態に係るゲーム管理装置、ゲームシステム、ゲーム管理方法及びプログラムについて、図面を参照しながら説明する。

〔ゲームシステムの概要〕
本発明の一実施の形態に係るゲーム管理装置が組み込まれたゲームシステムの構成例を、図１に示している。同図に示すように、このゲームシステムは、インターネットなどのネットワーク４上に設置されたゲームサーバ１と、当該ゲームサーバ１と通信可能に接続されたデータベースサーバ２と、ネットワーク４を介してゲームサーバ１と通信可能に接続できる各ユーザの端末装置３とによって構成される。

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

このゲームシステムの例において、本発明の一実施の形態に係るゲーム管理装置は、ゲームサーバ１およびデータベースサーバ２から構成することができる。ゲームサーバ１は、ゲームサービスを受ける各ユーザの端末装置３からのネットワーク４を介したアクセスを受け付けて、各ユーザのゲーム情報をデータベースサーバ２（記憶装置）に蓄積して管理し、各ユーザにネットワーク４を介したゲームサービスを提供する。

ゲームサーバ１によるゲームサービスの提供の形態としては、ゲーム用のプログラム（アプリケーションソフトウェア）がゲームサーバ１に実装されており、端末装置３でゲームを実行するのではなく、端末装置３でのゲーム操作入力に応じてゲームサーバ１でゲームを実行し、その実行結果を各ユーザの端末装置３に送信する形態がある。例えば、各ユーザの端末装置３に搭載されたウェブブラウザによってゲームがプレイできる、いわゆるブラウザゲームをゲームサーバ１が提供する。あるいは、ゲームサーバ１でゲームを実行した結果のゲーム映像を、例えばストリーミング形式で端末装置３に送信する、いわゆるクラウドゲーミングのサービスをゲームサーバ１が提供する。

あるいは、後述するように、ゲーム実行プログラムの一部または全部をユーザの端末装置３側にインストールし、端末装置３においてもゲーム実行処理が行われるようなゲームシステムとすることもできる。

本実施の形態では、ゲームサーバ１によるゲームサービスの提供の一形態として、ブラウザゲームを提供する例について説明する。このブラウザゲームを提供するサービス形態では、ユーザの端末装置３にゲーム専用のソフトウェアをダウンロード又はインストールする必要がなく、端末装置３をネットワーク４に接続できる環境であれば、ユーザはどこでも気軽にゲームサーバ１から提供されるゲームサービスを楽しむことができる。

このゲームシステムでは、ゲームサーバ１が、各ユーザの端末装置３における入力操作に応じてゲーム進行のための演算処理やデータ処理を実行する。そして、ゲームサーバ１は、演算処理等の実行結果に基づいてデータベースサーバ２内の各ユーザのゲーム情報を更新するとともに、当該実行結果をユーザの端末装置３の画面に表示させるためのウェブページ情報（ゲーム画面データ）を各ユーザの端末装置３に送信する。

各ユーザの端末装置３には、ユーザーエージェントとしてウェブサイト閲覧機能を有するウェブブラウザが搭載されており、ゲームサーバ１から送信されたウェブページ情報を端末装置３の画面に表示することができるようになっている。この端末装置３としては、例えば、携帯電話端末、ＰＨＳ（Personal Handy-phone System）端末、携帯情報端末（ＰＤＡ：Personal Digital Assistant）、携帯電話と携帯情報端末とを融合させた携帯端末であるスマートフォン、パーソナルコンピュータ（以下「ＰＣ」と呼称する）、タブレット型コンピュータ、通信機能を有するゲーム装置（据置型または携帯型のゲーム装置）または双方向の通信機能を備えた多機能型テレビジョン受像機（いわゆるスマートテレビ）など、ネットワーク４経由でゲームサーバ１に接続してゲームサービスの提供を受けることができる様々な端末が適用できる。

また、本実施の形態で提供されるゲームは、ユーザが、ゲームサービスを受けている他のユーザと交流を行いながらプレイすることができる、いわゆるソーシャルゲームの要素を有するものとすることができる。例えば、本実施の形態のゲームサーバ１およびデータベースサーバ２をソーシャルネットワーキングサービス（ＳＮＳ）のシステムに組み込むことによって、ＳＮＳのサービスの一つとしてソーシャルゲームサービスを提供するゲームシステムとすることができる。このようにＳＮＳのプラットフォーム上で動作するゲームシステムによりゲームサービスをユーザに提供することもできるが、ゲームサーバ１およびデータベースサーバ２をＳＮＳのシステムに組み込まずに、独立したゲームシステムとして構築してもよい。

本実施の形態のゲーム管理装置は、現実世界またはゲーム内で発生する結果を予想する予想ゲームを管理する。そして、本ゲーム管理装置は、過去の予想ゲームの結果、または各ユーザが現在予想中の情報に基づいて、ユーザの予想を補助するための予想補助情報を生成し、当該予想補助情報を、ユーザが予想入力を行うための入力画面内に表示させる。これにより、予想の入力画面内で、ユーザに予想の手がかりを与え、予想の入力を円滑に行うことができるようにする。以下に、これを実現する本実施の形態に係るゲーム管理装置（ゲームサーバ１等）の構成の詳細を説明する。

〔ゲーム管理装置の構成〕
上述のように本実施の形態では、ゲーム管理装置は、ゲームサーバ１およびデータベースサーバ２から構成される。図２にゲームサーバ１のハード構成の一例を示している。同図に示すように、ゲームサーバ１は、主に、ＣＰＵ（Central Processing Unit）１１と、主記憶装置としてのＲＯＭ（Read Only Memory）１２及びＲＡＭ（Random Access Memory）１３と、補助記憶装置１４と、通信制御部１５と、入出力制御部１６とを備えており、これらはアドレスバス、データバス及びコントロールバス等を含むバスライン１９を介して相互に接続されている。なお、バスライン１９と各構成要素との間には必要に応じてインタフェース回路が介在しているが、ここではインタフェース回路の図示を省略している。

ＣＰＵ１１は、システムソフトウェアやゲームプログラム等のアプリケーションソフトウェアの命令を解釈して実行し、ゲームサーバ１全体の制御を行う。ＲＯＭ１２は、ゲームサーバ１の基本的な動作制御に必要なプログラム等を記憶している。ＲＡＭ１３は、各種プログラム及びデータを記憶し、ＣＰＵ１１に対する作業領域を確保する。

補助記憶装置１４は、ゲームプログラム等のアプリケーションソフトウェアや各種データ等を格納する記憶装置である。補助記憶装置１４としては、例えばハードディスクドライブなどを用いることができる。ゲームサーバ１（コンピュータ）をゲーム管理装置として動作させるための本実施の形態のプログラムも、この補助記憶装置１４に記憶されており、当該プログラムはゲームサーバ１の起動時に補助記憶装置１４からバスライン１９を介してＲＡＭ１３へとロードされ、当該ＣＰＵ１１によって実行される。

通信制御部１５は、ネットワーク４と接続される通信インタフェース１５ａを備え、ネットワーク４を介した各ユーザの端末装置３との間の通信を制御する。また、通信制御部１５は、ネットワーク４に接続されている図示しないサーバとの通信も制御するようになっている。例えば、ゲームサーバ１をＳＮＳに組み込んだシステム構成とした場合、ゲームサーバ１の通信制御部１５は、ＳＮＳサーバとの間の通信を制御する。

入出力制御部１６は、キーボード、マウス、タッチパネル等の入力装置１７およびディスプレイ等の出力装置１８と接続され、これらの装置１７・１８との間の入出力制御を行う。オペレータは、キーボードやマウス等を使用して、野球の試合中に発生する事象の情報を手動でゲームサーバ１に入力することができる。また、入出力制御部１６は、データベースサーバ２と通信可能に接続されており、ＣＰＵ１１がデータベースサーバ２に対してデータ（レコード）の読み書きを実行するときの入出力制御を行うデータベースインタフェースでもある。

データベースサーバ２は、ゲームサーバ１が管理する各ユーザのゲーム情報を記憶する領域を有する記憶装置として、例えばＲＡＩＤ（Redundant Arrays of Inexpensive Disks）構成の大容量ハードディスク装置を具備する。このデータベースサーバ２は、例えば、各ユーザを一意に識別する識別情報（ユーザＩＤ）と対応付けて、各ユーザの各種ゲーム情報（ユーザ名、レベル、ゲーム内ポイント、所持アイテムなど）を記憶するリレーショナルデータベース、オブジェクトデータベース又はオブジェクト関係データベース等として構築することができる。また、データベースサーバ２は、ゲームサーバ１と直接的に接続されるのではなく、ネットワーク４を介して接続されるようになっていてもよい。

本実施の形態では、ゲーム管理装置がゲームサーバ１およびデータベースサーバ２から構成される例を示すが、これに限定されるものではない。例えば、ゲームサーバ１にデータベースサーバ２の機能を持たせて、ゲーム管理装置をゲームサーバ１のみで構成することもできる。また、ゲームサーバ１の有する各機能を複数のサーバに分散して持たせて、ゲームサーバ１を複数台のサーバとして構成することもできる。例えば、ユーザが端末装置３を操作してゲームサーバ１へアクセスした場合に、当該ユーザが正規のユーザかどうかを判別する認証機能を有する認証サーバを、ゲームサーバ１のメインサーバとは別に設け、メインサーバと認証サーバとでゲームサーバ１を構成してもよい。他の構成例としては、ユーザが課金対象のアイテムをゲーム内で購入した場合に課金管理を行う課金管理サーバを、ゲームサーバ１のメインサーバ等とは別に設け、メインサーバ、認証サーバおよび課金管理サーバによりゲームサーバ１を構成してもよい。

また、本ゲームサービスを利用するユーザ数が数十万人、数百万人、あるいはそれ以上となると、多数のユーザの端末装置３からの巨大なアクセスにも耐え得るサーバシステムの構築が求められるため、ネットワーク４上に複数のゲームサーバ１を設けて冗長化（多重化）を図ることにより、負荷分散型のシステム構成としてもよい。この場合、複数のゲームサーバ１間の負荷を調整するためのロードバランサを設けることが望ましい。

次に、本実施の形態に係るゲームサーバ１にアクセスしてゲームサービスの提供を受けるユーザの端末装置３の構成を説明する。

〔端末装置の構成〕
ユーザが操作する端末装置３としては、上述のように、ＰＣ、携帯電話、スマートフォンをはじめとして、ウェブサイト閲覧機能を有する様々な端末を適用できるが、本実施の形態では、ＰＣを例示してその構成を説明する。なお、ＰＣ以外の端末装置３についても、ウェブサイト閲覧機能を用いてゲーム画面を表示したり、ゲームを実行するための入力操作を行ったりといった、ゲームをプレイする上で必要となる基本的な構成は、ＰＣと同様である。

端末装置３の構成例を、図３に示している。同図に示すように、端末装置３は、主に、ＣＰＵ３１と、主記憶装置としてのＲＯＭ３２及びＲＡＭ３３と、画像処理部３４と、表示部３５と、サウンド処理部３６と、音声入力部３７と、音声出力部３８と、補助記憶装置３９と、操作入力部４０と、通信制御部４１とを備えており、構成要素３１〜３４、３６および３９〜４１はバスライン４２を介して相互に接続されている。なお、バスライン４２と各構成要素との間には必要に応じてインタフェース回路が介在しているが、ここではインタフェース回路の図示を省略している。

ＣＰＵ３１は、ウェブブラウザや、そのプラグインとして動作するソフトウェアを含む各種プログラムの命令を解釈して実行し、端末装置３全体の制御を行う。ＲＯＭ３２には、端末装置３の基本的な動作制御に必要なプログラム等が記憶されている。また、ＲＡＭ３３には、ＲＯＭ３２または補助記憶装置３９からロードされた各種プログラムやデータが記憶され、ＣＰＵ３１に対する作業領域を確保する。ＨＴＭＬ等で記述されたゲーム画面データを表示するウェブブラウザは、ＲＯＭ３２または補助記憶装置３９に記憶されており、ＲＡＭ３３にロードされてＣＰＵ３１によって実行される。また、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインソフトウェアを、ウェブブラウザと共にＲＯＭ３２または補助記憶装置３９に記憶していてもよい。

画像処理部３４は、ＣＰＵ３１からの画像表示命令に基づいて表示部３５を駆動し、当該表示部３５の画面に画像を表示させる。表示部３５には、液晶ディスプレイまたは有機ＬＥ（Electro-Luminescence）ディスプレイ等の既知の種々の表示装置が適用できる。

サウンド処理部３６は、音声入力部３７から音声が入力されたときにアナログ音声信号をデジタル音声信号に変換するとともに、ＣＰＵ３１からの発音指示に基づいてアナログ音声信号を生成して音声出力部３８に出力する。音声入力部３７は、端末装置３に内蔵されたマイクロフォン等からなり、例えばボイスチャット等を行う場合などに用いられる。音声出力部３８は、ゲーム実行時の効果音などを出力するスピーカ等からなる。

補助記憶装置３９は、各種プログラムやデータ等を格納する記憶装置である。補助記憶装置３９としては、例えばフラッシュメモリドライブ、ハードディスクドライブ、メモリカードリーダライタ等を用いることができる。

操作入力部４０は、ユーザの操作入力を受け入れて当該操作入力に対応した入力信号を、バスライン４２を介してＣＰＵ３１に出力するものである。操作入力部４０の例としては、キーボードやマウス等のポインティングデバイスがある。また、表示部３５の画面にタッチパネル（接触入力式のインタフェース）を搭載することによって表示部３５をいわゆるタッチスクリーンとして構成している端末装置３の場合、当該タッチパネルも操作入力部４０となる。

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

上記構成の端末装置３において、ゲームサービスを受けようとするユーザは、ウェブブラウザを立ち上げてゲームサーバ１が管理するゲームサイトにアクセスする操作を行う。このアクセスがゲームサーバ１に認証された場合、端末装置３の通信制御部４１がゲームサーバ１から送信されてくるＨＴＭＬ等で記述されたゲーム画面データを受信し、ＣＰＵ３１がウェブブラウザを実行してゲーム画面を表示部３５に表示させる。ここでユーザは、ゲーム画面に表示されている選択可能なボタンオブジェクトやハイパーリンクを、操作入力部４０を操作して選択入力する。この選択入力に応じてゲームサーバ１がゲームを進行させ、新たなゲーム画面データを端末装置３に送信する。そして、この新たなゲーム画面が端末装置３の表示部３５に表示され、以下、同様に、ユーザは、表示部３５に表示されているゲーム画面で選択可能なボタンオブジェクト等を選択する操作により、ゲームサーバ１が提供するゲームをプレイすることができるようになっている。

〔ゲームの説明〕
ゲーム管理装置によって提供されるゲームの例としては、サッカー、野球、テニス、アメリカンフットボール、バスケットボール、バレーボール、ゴルフ、ボクシング、競馬、カーレースなどを題材としたスポーツ・レースゲーム、シミュレーションゲーム、育成ゲーム、ロールプレイングゲーム、さらにはクイズゲームといったように、ゲーム形式・ジャンルを問わず様々なゲームを挙げることができる。その一例として、本実施の形態では、主に、ゲーム管理装置が野球ゲームを管理する例について、以下に説明する。

本実施の形態では、ゲーム内で、現実世界のプロ野球（またはＭＬＢ）の実在選手に対応する選手キャラクタが用いられる野球ゲームを例に挙げる。ゲーム内の選手キャラクタは、当該選手キャラクタの形態を端末装置３の画面上で視認可能としたカード形式とすることができる。すなわち、選手キャラクタは、デジタル選手カードとしてゲームサーバ１で管理されるとともに、ユーザの端末装置３の画面に表示される。また、選手キャラクタは、ゲーム内での試合等において、３次元コンピュータグラフィックスにより描写してもよい。また、ストリーミング形式等により、選手キャラクタやボールオブジェクト等を動画表示してもよい。

データベースサーバ２には、現実世界の実在選手と、当該実在選手に対応する選手キャラクタとを関係付けた選手データベース（以下、「選手ＤＢ」と称する）が記憶されている。図４には、選手ＤＢの一例を示している。図４の例では、実在選手の情報として、名前、背番号、守備位置、所属チーム等の情報が記憶される。また、実在選手に対応する選手キャラクタの情報として、「個別能力」、「調子」、「希少度」等の情報が記憶される。また、選手情報には、選手キャラクタの画像情報も含まれる。このようにして実在選手と選手キャラクタとを１対１で対応付けた選手情報には、実在選手および選手キャラクタを一意に識別するための選手ＩＤが付されている。そして、ゲームサーバ１は、実在選手および選手キャラクタを選手ＩＤにより管理し、各種処理を実行する。この選手情報により、現実世界の実在選手とゲーム内の選手キャラクタとがリンクされる。

選手キャラクタが野手の場合の個別能力としては、図４に例示するように、「ミート」、「パワー」、「走力」、「守備」等とすることができる。なお、選手キャラクタが投手の場合には、「球威」、「制球」、「変化」、「スタミナ」等とすることができる。また、各選手キャラクタには、能力をどの程度発揮できるかを決定するための「調子」というパラメータが設定される。この調子によって、選手キャラクタの持つ能力が、例えば２０％〜１００％の範囲で調整される。各選手キャラクタに設定される「調子」は、実在選手の現実世界での実際の活躍・成績に応じて、所定期間（１日、１週間等）毎に更新される。

また、選手キャラクタには、希少度（レア度）が設定されている。この希少度とは、選手キャラクタの希少価値の高さを示すパラメータであり、例えば、５種類（最低１〜最高５）の希少度が存在する。なお、希少度１〜５を、ゲーム内では、例えば「ノーマル」、「ブロンズ」、「シルバー」、「ゴールド」、「レジェンド」といった表現を用いて表してもよい。本実施の形態では、各選手キャラクタには、前記希少度１〜５の何れかが設定されており、同じ名前の選手キャラクタでも、希少度の異なる５種類のものが存在する。

本実施の形態の野球ゲームは、ユーザがゲーム内において選手キャラクタを保有し、保有する選手キャラクタの中から一軍選手を登録してオーダーを組み、自分だけのオリジナルチームを結成することができる。そして、ユーザは、他のユーザのチーム（またはＣＰＵ）と対戦してランキング等を競うことができる（対戦モード）。さらに、本ゲームには、前述のように、現実世界またはゲーム内で発生する結果を予想する予想ゲームモードが存在する。

ユーザは、対戦モードを遊戯することにより、予想ゲームで使用できる権利アイテム（本実施の形態では「ホープ」と称する）を入手できる。本実施の形態では、ユーザが対戦で相手に勝利すれば、所定数の「ホープ」を獲得できる。なお、ユーザが対戦で相手に負けても、勝利した場合よりも少ない数の「ホープ」を獲得できるようにしてもよい。ユーザは、対戦モードで入手した「ホープ」を使用して、以下に説明する予想ゲームを遊戯する。

本実施の形態の予想ゲームは、現実世界の野球のシーズン中においては、現実の試合で活躍する実在選手やチームをユーザが予想する。また、現実世界の野球のオフシーズン中（またはシーズン中でも野球の試合がない日）においては、実在選手の活躍を予想できないので、ゲーム内に存在する選手キャラクタ（またはチーム）の中から、活躍する選手キャラクタ（またはチーム）をユーザが予想する。すなわち、予想ゲームには、現実世界で発生する結果を予想する予想ゲームと、ゲーム内で発生する結果を予想する予想ゲームとが存在する。

まず、現実世界で発生する結果を予想する予想ゲームについて説明する。この予想ゲームを、本実施の形態では「現実結果予想モード」と称する。野球のシーズン中においては、野球の試合のある日は毎日、１日単位で、予想ゲームが開催される。例えば、本日の野球の試合の開始時間の１時間前に、予想の締切期限が設けられ、ユーザは締切期限までに、自分が保持する「ホープ」を使用して、予想の入力を行う。

図５に、ユーザが予想入力を行うための入力画面の一例を示す。この画面は、現実世界のプロ野球の実在選手の中から活躍する実在選手を予想するための入力画面である。この入力画面には、前回の予想ゲームの結果に基づいて求められた、予想対象（実在選手）の活躍度（評価）のランキング情報を表示する領域１１１と、次回予想の入力等を行うための領域１１２とが設けられる。領域１１１には、前回の予想ゲームの対象となった試合での活躍度の高い順に、実在選手に対応する選手キャラクタが並べて表示される。なお、画面に表示しきれないランキングの情報は、画面をスクロールさせる、または２ページ目以降をゲームサーバ１にリクエストすることにより、表示することができる。

また、領域１１１の前回ランキングに表示されている選手キャラクタの中で、前回の予想ゲームでユーザが活躍予想の入力をした選手欄には、その予想結果としての獲得報酬の情報１１３も表示される。これにより、ユーザは、前回の予想ゲームでどの実在選手の活躍を予想し、その実在選手が何位にランキングされ、どれだけの報酬が獲得できたのかを、次の予想ゲームに対する入力画面内で確認することができる。なお、前回の予想ゲームでユーザが活躍を予想しなかった選手欄には、獲得報酬の情報１１３が表示されない。

また、領域１１２には、前回のランキング順に並べられた各選手に対して、次回の予想ゲームにおける活躍予想を入力するための入力部１１４が設けられている。ユーザが活躍予想をしたい実在選手に対応する選手キャラクタの入力部１１４をクリックすれば、その選手キャラクタに対して「ホープ」を設定することができる。このように、現実世界での活躍を予想した実在選手に対応する選手キャラクタを選択することにより、選手キャラクタを介して、活躍する実在選手を予想できる。

本実施の形態では、各選手キャラクタに設定する「ホープ」の数をユーザが指定できるようになっており、設定する「ホープ」の数によって、予想の重み付が可能である。例えば、入力部１１４をクリックすればプルダウンメニューが表示され、対象となる選手キャラクタに設定する「ホープ」の数を選択できるようになっている。後述するように、各選手キャラクタに設定可能な前記重みの上限（設定可能な最大の「ホープ」数）は、各キャラクタの希少度（レアリティ）に応じて異なっていてもよい。同じ選手キャラクタでも、その希少度が高いほど、ユーザが設定できる予想の重みの上限を大きくすることが好ましい。

また、ユーザが予想対象とすることができる実在選手は、ユーザが所有している選手キャラクタに対応する実在選手だけである。入力画面内にランキング情報として並べられた各選手キャラクタのうち、ユーザが所有していない選手キャラクタの欄には、その選手キャラクタを所有していないことを示す未入手ラベル１１５が表示される。一方、ユーザが所有している選手キャラクタの欄には、前記未入手ラベル１１５（および後述する助っ人ありラベル１１６）は表示されない。このように、本実施の形態では、未入手ラベル１１５等が表示されることなく選手キャラクタが画面に表示されることをもって、その選手キャラクタをユーザが所有していることを報知している。

ユーザが所有していない選手キャラクタに対応する実在選手の活躍は予想できないので、前記未入手ラベル１１５が表示された選手キャラクタの欄には、入力部１１４が表示されない。なお、この場合、例えば、入力部１１４をグレーアウト状態で表示して入力部１１４の操作を無効化してもよい。

本実施の形態では、活躍しそうな実在選手に対応する選手キャラクタを所有していないユーザは、先ずゲーム内でそれを入手する必要がある。すなわち、各ユーザはゲーム内で選手キャラクタを入手し、その選手キャラクタを介して実在選手の活躍を予想し、予想結果に応じた特典を獲得するというこれまでにない面白みのあるゲーム性を実現している。本実施の形態では、ユーザは、以下のようにして選手キャラクタを入手することができる。

ゲーム開始時に、各ユーザには、所定数（例えば２０人）の選手キャラクタがゲームサーバ１より付与される。その後、ユーザは、予想ゲームを遊戯して特典としてのコイン（ゲーム内ポイント）を獲得する。そして、ユーザは、獲得したコインを使用して抽選モードを遊戯することにより、抽選で選手キャラクタを入手することができる。

なお、ゲーム内で選手キャラクタを入手する態様は上記に限定されない。例えば、ユーザは、仲間等の他のユーザからプレゼントとして選手キャラクタを贈られることにより、その選手キャラクタを入手することができる。また、例えば、行動力ポイントを消費しながらゲーム内エリア（ステージ）を探索し、選手キャラクタをスカウトするという「スカウトモード」を遊戯することにより、選手キャラクタを入手できるようにしてもよい。あるいは、所定期間（例えば１週間）、毎日ゲームにログインした場合に、連続ログインボーナスとして選手キャラクタを入手できるようにしてもよい。あるいは、ゲーム内で開催される様々な期間限定イベントで報酬獲得条件を満たした場合に、報酬として選手キャラクタを入手できるようにしてもよい。これらはほんの一例であり、ゲーム内で選手キャラクタを入手可能とする態様は種々考えられる。

ユーザが入力部１１を操作して、自分が所有している選手キャラクタに「ホープ」を設定する入力をすれば、その入力情報がユーザの端末装置３からゲームサーバ１へ送信される。ゲームサーバ１は、予想の締切期限まで、ユーザの前記入力を受け入れる。このようにユーザが活躍予想の入力をした選手キャラクタの欄には、予想済みであることを示す情報１１７が表示される。図５では、ユーザが選手ＥＫに、５ホープを設定したことにより、「５ホープ予想済」という情報１１７が表示されている例を示している。

また、ユーザは、自分の仲間が所有している特定の選手キャラクタも、予想入力の対象とすることができる。すなわち、ユーザは、仲間が所有している特定の選手キャラクタを借りて予想対象を拡大することができる。本実施の形態では、各ユーザが、自分の所有している選手キャラクタの中から任意の１つを貸出可能なキャラクタ（助っ人キャラクタ）として設定することができる。よって、各ユーザは、自分の仲間が貸出可能としている助っ人キャラクタを借りて、予想対象とすることができる。

ユーザにとっては、仲間が多いほど、予想対象のキャラクタが拡大するので有利である。但し、助っ人キャラクタは所定数（例えば１人）しか使えない。本実施の形態では、仲間の助っ人キャラクタを使用した予想枠は、１枠のみである。このように、仲間の助っ人キャラクタを使用した予想枠は限定されているが、仲間が多いほど、多くの助っ人の中から選択可能となるので、選択の自由度が高まることにより予想対象の拡大が図れる。

ユーザが所有していない選手キャラクタではあるが、仲間が貸し出している助っ人キャラクタである場合、その選手キャラクタの欄には、助っ人ありラベル１１６が表示される。この場合、助っ人ありラベル１１６が表示された選手キャラクタの欄には、「助っ人で予想する」と表示された入力部１１８が設けられる。この入力部１１８をクリックすれば、入力部１１４と同様にして、活躍予想をする実在選手に対応する選手キャラクタに対して「ホープ」を設定することができる。

また、図５の入力画面には、各ユーザが現在予想中の情報をまとめた統計情報として、現時点で各選手キャラクタに設定されている全体平均のホープ数の情報１１９も表示される。全体平均のホープ数が大きいということは、それだけその選手の人気が高いことを示し、ユーザはこれを予想の手がかりとすることができる。全体平均のホープ数に代えて、またはそれと一緒に、各選手キャラクタに「ホープ」を設定している人数、各選手キャラクタに設定されている「ホープ」の総数などの統計情報を表示してもよい。

また、ユーザは、図５の入力画面と図６の入力画面を相互に切り替えることができる。図５は、ユーザが所有していない選手キャラクタを含む全てのキャラクタに対応する選手を、ランキング順に並べた入力画面である。これに対して、図６は、ユーザが所有している選手キャラクタ（および前記仲間の助っ人キャラクタ）のみを対象とした入力画面である。図６の画面では、ポジション指定部１２１およびチーム指定部１２２の何れか又は両方で抽出条件を設定（例えばプルダウンメニューから選択）して、入力画面に表示する選手キャラクタを絞り込むことができる。また、ユーザが条件指定することによって、仲間から借りることができる助っ人キャラクタのみを抽出表示したり、前回の予想的中順（獲得報酬順）、活躍ランク順等に並び替えたりできるようにしてもよい。

図６の入力画面には、前記抽出条件を満たした、ユーザが所有する選手キャラクタの情報１２３が表示されると共に、当該選手キャラクタに対応する予想ゲームの前回情報１２４および今回情報１２５が表示される。ここで、選手キャラクタの情報１２３をクリック等すると、当該選手キャラクタのより詳細な情報（能力値等）を確認する画面が表示される。また、選手キャラクタに対応する実在選手のリアル情報（打率、防御率等）も表示される。

ユーザの予想を補助するための予想補助情報の一つである前回情報１２４には、活躍ランキング、活躍度、獲得報酬等の情報が含まれる。また、今回情報１２５の表示領域には、前述の、活躍予想を入力するための入力部１１４、予想済みであることを示す情報１１７、全体平均のホープ数の情報１１９等が表示される。

予想の締切期限後は、ユーザは予想入力を行うことができない。そして、予想ゲームの対象となる現実世界の試合中または試合の終了後に、各実在選手のその試合での実績（ヒット、盗塁、奪三振等の活躍内容）がゲームサーバ１に入力される。また、ゲームサーバ１は、入力された各実在選手の実績に基づいて、その活躍を評価する活躍度を求める。例えば、１安打の活躍度を１０、２安打の活躍度を１５、３安打以上の活躍度を２０等として、各実在選手の活躍度が求められる。

その後、ゲームサーバ１は、ユーザが予想入力した選手キャラクタに対応した実在選手の評価（活躍度）に応じた特典をユーザに付与する。本ゲームでは、実在選手の活躍度と、予想入力で設定された「ホープ」数とを掛け合わせた数のコインを、特典としてユーザに付与する。ユーザが複数の選手の活躍を予想していた場合、ゲームサーバ１は、それぞれの選手に対してユーザが獲得したコインを算出し、それらを合計してユーザに付与する総コインを求める。

上記のように、ユーザの端末装置３に表示される予想ゲームの入力画面内には、ユーザの予想を補助するための予想補助情報として、各選手キャラクタを過去の評価（前回の活躍度）の順に並べたランキング情報等が表示される。これにより、ユーザは、予想の入力画面内で、予想補助情報を見て、予想の手がかりを得ることができるので、円滑な予想の入力が可能となる。

また、本予想ゲームでは、現実世界のプロ野球の実在チームの中から活躍する実在チームを予想することもできる。例えば、ユーザは、その日に開催されるプロ野球の対戦カードに対して、勝利する側のチームを予想することができる。図７に、ユーザが予想入力を行うための入力画面の一例を示す。この入力画面には、その日のプロ野球の対戦カードが表示されると共に、対戦カード毎に勝敗を予想するための入力部１３１が表示される。ユーザが予想をしたい対戦カードの入力部１３１をクリックすれば、プルダウンメニューが表示され、その対戦カードの両チームの何れか一方のチームを勝利（活躍）チームとして選択できる。また、入力部１３１で引き分けを選択できるようにしてもよい。また、ホープ設定部１３２で予想の重みを付ける「ホープ」数を指定することができる。なお、ホープ設定部１３２で「ホープ」数を指定せずに、入力部１３１で予想入力を行った場合、デフォルトで１「ホープ」が設定されることになる。このようにして、ある対戦カードについての予想入力が行われた場合、予想済みであることを示す情報１３３がその対戦カードの欄に表示される。

また、図７の入力画面には、ユーザの予想を補助するための予想補助情報として、各チームの前回の勝敗情報１３４も表示される。ユーザは、前回の勝敗情報１３４を見て、予想の手がかりを得ることができる。

予想の締切期限後は、ユーザは予想入力を行うことができない。そして、予想ゲームの対象となる現実世界の対戦カードの試合終了後に、その勝敗の結果がゲームサーバ１に入力される。また、ゲームサーバ１は、入力された勝敗の結果に基づいて、試合に勝利した方のチームを活躍したチームとして評価する。ユーザの勝敗予想で勝利すると予想したチームが実際に勝利した場合（または引き分けと予想して、実際に引き分けた場合）、ゲームサーバ１はユーザに特典を付与する。本ゲームでは、予想入力で設定された「ホープ」数に所定値（例えば１０）を掛け合わせた数のコインを、特典としてユーザに付与する。ユーザが複数の対戦カードの勝敗を予想していた場合、ゲームサーバ１は、それぞれの対戦カードに対してユーザが獲得したコインを算出し、それらを合計してユーザに付与する総コインを求める。

次に、ゲーム内で発生する結果を予想する予想ゲームについて説明する。この予想ゲームを、本実施の形態では「ゲーム結果予想モード」と称する。この「ゲーム結果予想モード」では、ゲーム内に存在する複数の選手キャラクタ（またはチーム）の中から活躍する選手キャラクタ（またはチーム）を予想することができる。前述の「現実結果予想モード」は野球のシーズン中に行われるものであるが、野球のオフシーズン中においては、毎日、この「ゲーム結果予想モード」の予想ゲームが開催される。例えば、毎日、所定時刻（例えば２４時）に、予想の締切期限が設けられ、ユーザは締切期限までに、自分が保持する「ホープ」を使用して、予想の入力を行う。

ゲーム結果予想モードで選手キャラクタの活躍予想を行う場合、ユーザは、基本的に、自分が所有している選手キャラクタの中から、活躍しそうな任意の選手キャラクタを選択し、前述のように「ホープ」を設定する。現実結果予想モードと、ゲーム結果予想モードとは、予想対象が実在選手かゲーム内の選手キャラクタかの違いはあるが、基本的な遊戯方法は同一であり、予想の入力画面は、両者共通の画面構成（図５、図６参照）とすることができる。なお、ゲーム結果予想モードでは、図５の入力画面の領域１１１には、前回の予想ゲームの結果に基づいて求められた、予想対象（選手キャラクタ）の活躍度（評価）のランキング情報が表示される。

ゲーム内の選手キャラクタの活躍の評価は、ゲーム内の全ユーザの全対戦結果を集計して行われる。例えば、ユーザＡの対戦相手としてユーザＰ、Ｑ、Ｒ・・・がマッチングされて各々対戦した場合、それらの対戦結果すべてが集計の対象となる。同様に、他のユーザＢ、Ｃ、Ｄ・・・についても、同様に各ユーザの対戦結果が集計される。そして、すべてのユーザＡ、Ｂ、Ｃ、Ｄ・・・の集計結果に基づき、ゲーム内の選手キャラクタの活躍が評価され、評価順にランキングが求められる。

なお、ゲームサーバ１は、対戦相手の決定処理においては、ユーザ間のレベルまたは戦力が所定範囲内の相手となるようにマッチングする。例えば、ユーザＡのレベルがＬｖ１５の場合、その対戦相手のレベルは例えばＬｖ１０〜Ｌｖ２０の範囲であり、極端にレベルが相違する相手はマッチングされない。また、各ユーザが設定しているオーダーに含まれる選手キャラクタの能力に基づいて、各ユーザのチームの戦力値を算出（例えば、オーダーの全選手の能力の合計を算出）し、この戦力値が所定範囲内の相手をマッチングするようにしてもよい。

ゲームサーバ１は、ユーザＡの対戦相手候補として、ユーザＡのレベルまたは戦力とほぼ同じ程度の（前記所定範囲内の）ユーザを、対戦相手候補として所定数（例えば４人）抽出し、ユーザＡに提示する。ユーザＡは、提示された対戦相手候補の中から、任意の相手を選択して対戦を行うことができる。なお、ゲームサーバ１が特定の１人の対戦相手を決定してもよい。

ゲームサーバ１は、所定期間内（例えば０時から２４時までの２４時間）に各ユーザが、対戦で使用した選手キャラクタ（チームオーダーのキャラクタ）についてのゲーム結果（安打数等）を集計する。そして、選手キャラクタ毎に、安打数の全体平均等を算出して活躍を評価する。例えば、ゲームサーバ１は、１安打の活躍度を１０、２安打の活躍度を１５、３安打以上の活躍度を２０等として、各選手キャラクタの活躍度（評価）を求める。そして、ゲームサーバ１は、前述の現実結果予想モードと同様に、ユーザが予想入力した選手キャラクタの評価に応じた特典をユーザに付与する。

また、ゲーム結果予想モードでは、ゲーム内に存在する複数のチームの中から活躍するチームを予想することもできる。本ゲーム内には、現実世界のプロ野球（またはＭＬＢ）の球団に対応する複数のチームが存在し、その中のチームを対象として上位にランキングされそうなチームをユーザが予想する。ゲームサーバ１は、各ユーザが実行した対戦ゲームの結果を集計して、以下のようにしてゲーム内のチームを評価する。

先ず、ゲーム内の複数のチームの中の何れかのチームと、各ユーザとが関係付けられている。本ゲームでは、ゲーム開始時に、ユーザがゲーム内の複数のチームの中からお気に入りチームを選択する。そして、このお気に入りチームが、ユーザと関係付けられたチームとなる。なお、ユーザによるチームの予想対象は、必ずしもそのユーザに関係付けられているチームに限定されるものではなく、ゲーム内に存在する全てのチームを対象とすることができる。

そして、ゲームサーバ１は、所定期間内（例えば０時から２４時までの２４時間）に各ユーザが実行した対戦結果を集計して、各ユーザに関係付けられているチーム毎に活躍を評価する。例えば、ユーザＡ、Ｂ、Ｃのお気に入りチームが何れも「チームＧ」であった場合、ユーザＡ、Ｂ、Ｃの対戦結果（勝敗）は、全て「チームＧ」の対戦結果として集計される。そして、ゲームサーバ１は、ゲーム内のチーム毎に、勝率を算出して活躍を評価する。例えば、ゲームサーバ１は、勝率に基づく各チームのランキングを求め、このランキングにより各チームを評価する。そして、ゲームサーバ１は、ユーザが予想入力したチームの評価（ランキングの順位）に応じた特典をユーザに付与する。例えば、ランキング１位の場合、予想入力で設定された「ホープ」数に「２０」を掛け合わせた数のコインを、特典としてユーザに付与する。また、ランキング２位の場合、予想入力で設定された「ホープ」数に「１５」を掛け合わせた数のコインを、特典としてユーザに付与する。

図８に、ユーザがゲーム内のチームを対象として予想入力を行うための入力画面の一例を示す。この入力画面には、前回の予想ゲームの結果に基づいて求められた、予想対象（ゲーム内のチーム）の評価（勝率）のランキング情報を表示する領域１４１と、次回予想の入力等を行うための領域１４２とが設けられる。なお、画面に表示しきれないランキングの情報は、画面をスクロールさせる、または２ページ目以降をゲームサーバ１にリクエストすることにより、表示することができる。

領域１４１には、各チームに対する予想ゲームの前回情報として、ランキング順位、勝率、ユーザの獲得報酬等が表示される。なお、前回の予想ゲームでユーザが活躍予想の入力をしなかったチームの欄の獲得報酬は、「０」となる（または、獲得報酬の情報が表示されない）。

また、領域１４２には、前回のランキング順に並べられた各チームに対して、次回の予想ゲームにおける活躍予想を入力するための入力部１４３が設けられている。ユーザが活躍予想をしたいチームの入力部１４３をクリックすれば、そのチームに対して「ホープ」を設定することができる。また、ここで設定する「ホープ」の数によって、予想の重み付が可能である。また、ユーザが活躍予想の入力をしたチームの欄には、予想済みであることを示す情報１４４が表示される。また、各ユーザが現在予想中の情報をまとめた統計情報として、現時点で各チームに設定されている全体平均のホープ数の情報１４５も表示される。

このように、ユーザがチームに対する予想入力を行うための入力画面内にも、ユーザの予想を補助するための予想補助情報として、各チームを過去の（図８では前回の）評価の順に並べたランキング情報や、全体平均のホープ数の情報が表示されるので、ユーザはそれほど予想に困ることなく、予想の入力を行うことができる。

〔ゲーム管理装置の機能的構成および動作〕
次に、上記のゲームを実現するゲーム管理装置の機能的構成の一例について説明する。図９は、端末装置３と通信するゲーム管理装置（ゲームサーバ１およびデータベースサーバ２）の基本的な構成を示す機能ブロック図である。

本実施の形態に係るゲーム管理装置は、ユーザ情報記憶制御手段６０、受信手段６１、実行手段６２、画面生成手段６３、送信手段６４、アクセス管理手段６５および交流制御手段６６等を備えている。これらの各手段は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。

ユーザ情報記憶制御手段６０は、各ユーザのゲームに関する情報をデータベースサーバ２に記憶して管理する。ユーザ情報記憶制御手段６０がデータベースサーバ２に記憶している、ユーザのゲームに関する情報であるユーザ情報データベースの一例（この例ではユーザＩＤ＝０００００１の１人分の情報）を、図１０に示す。

ユーザ情報記憶制御手段６０は、ユーザＩＤと対応付けて、ユーザの基本情報、お気に入りチーム、レベル情報、保有キャラクタ、保有ホープ、保有コイン、仲間情報、アクセスログ、交流履歴、対戦情報等を、データベースサーバ２の所定の記憶領域に記憶する。

ユーザの基本情報としては、ログインＩＤ、パスワード、ユーザ名（ゲーム内で使用するニックネーム等）等がある。ここで、ログインＩＤおよびパスワードは、各ユーザが端末装置３を操作してゲームサーバ１にアクセスしたときのログイン認証に用いられる。ユーザ名は、ゲーム内で使用するニックネーム等である。お気に入りチームは、ユーザがゲームサービスを受けるための利用登録をした際や、ゲームを初めて実行した際に、ユーザが自ら設定したお気に入りチームの情報である。レベル情報は、ユーザのゲームの進行の程度を示すものであり、本野球ゲームでは、ユーザが対戦モードを遊戯することにより経験値が蓄積され、当該経験値が一定量に達する毎にゲームレベルがアップするようになっている。

保有キャラクタの情報とは、ゲーム内でユーザが保有している選手キャラクタの情報（選手ＩＤ）である。図４に示すように、データベースサーバ２には選手ＤＢが存在する。よって、ゲームサーバ１は、ユーザ情報記憶制御手段６０によって記憶されている選手ＩＤに基づいて、当該選手ＩＤに対応する選手キャラクタに関する各種情報を、選手ＤＢから取得できる。また、ユーザは、自分が所有している選手キャラクタのうちの１つを、助っ人として仲間に貸し出す選手キャラクタとして設定できる。ユーザが貸し出しの設定を行った選手キャラクタには、助っ人フラグが設定される。

また、保有ホープおよび保有コインの情報は、ゲーム内でユーザが保有している「ホープ」および「コイン」の数の情報である。ゲームサーバ１は、ユーザが対戦モードで「ホープ」を入手したり、予想ゲームで「ホープ」を使用したりする毎に、所有ホープの情報を更新する。また、ゲームサーバ１は、ユーザが予想ゲームで「コイン」を入手したり、抽選モードで「コイン」を消費する毎に、所有コインの情報を更新する。

また、ユーザは、自分が保有している選手キャラクタの中から、所定数（例えば１５）の選手キャラクタを一軍選手として選択し、野球のオーダーを組むことができる。ゲームサーバ１は、ユーザが組んだオーダー情報を、当該ユーザのユーザＩＤと関係付けてデータベースサーバ２の所定領域に記憶する。図１１に、ユーザＩＤ＝０００００１のユーザのオーダー情報の一例を示す。オーダー情報には、オーダーＩＤ、ポジション、選手ＩＤの各情報が含まれる。オーダーＩＤの１から９は、打者の１番から９番の打順に対応する。オーダーＩＤの１０から１５は、投手（先発２、中継２、抑え２）に対応する。

また、仲間情報とは、ユーザに関係付けられた仲間の情報であり、ユーザＩＤと対応付けられて仲間のユーザＩＤがデータベースサーバ２に記憶される。また、アクセスログとは、ユーザの端末装置３がゲームサーバ１へアクセス（ログイン）した日時等の時間情報である。また、交流履歴とは、ユーザが他のユーザ（仲間等）にゲーム内で交流を行った履歴の情報である。この交流履歴には、交流の種類、相手、時間の情報が含まれる。交流の種類としては、挨拶、メッセージ送信、プレゼント、チャットなどがある。交流の相手の情報として、相手のユーザＩＤが記憶される。

また、対戦情報としては、ユーザのチームが他のユーザのチームやコンピュータ（ゲームサーバ１のＣＰＵ１１）と対戦した結果を一意に特定するための対戦ＩＤが、ユーザＩＤと対応付けられて記憶される。後述するように、データベースサーバ２は、対戦ＩＤと対応付けられて、対戦日時、対戦スコア、対戦に使用された選手キャラクタの個人成績等の対戦結果に関する情報が記憶された対戦データベースを備えている。よって、ゲームサーバ１は、各ユーザの対戦結果（対戦ＩＤに対応する情報）を、対戦データベースから取得できるようになっている。

次に、図９に示す受信手段６１、実行手段６２、画面生成手段６３、送信手段６４について説明する。受信手段６１および送信手段６４は、ゲームサーバ１のＣＰＵ１１および通信制御部１５により実現される機能である。

ユーザの端末装置３のウェブブラウザによってゲーム画面が表示されているとき、ユーザがゲーム画面上の選択可能なボタンオブジェクトやハイパーリンクが設定された文字列等を選択する入力の操作を行った場合、当該入力に関する情報（ゲーム画面のリクエスト等）が端末装置３のウェブブラウザによってゲームサーバ１へ送信される。ゲームサーバ１では、前記入力に関する情報を受信手段６１が受信したとき、実行手段６２が、当該情報に応じてユーザのゲームに関する情報を読み出して演算やデータ処理を行うことによってゲームを実行する。

例えば、個別対戦モードで他のユーザのチームと対戦するという入力操作がユーザによって行われた場合を例に挙げると、実行手段６２は、対戦を行う両ユーザのユーザＩＤに対応した両チームの選手キャラクタ（オーダーに設定されているキャラクタ）の情報をデータベースサーバ２から読み出す。そして、実行手段６２は、ＡＩ（Artificial Intelligence）プログラム等により、両チームの選手キャラクタの能力等のパラメータに基づいて、野球の試合のシミュレーションを実行し、試合の勝敗を決定する。

ゲームサーバ１は、実行手段６２によって実行された対戦結果の情報を、データベースサーバ２の所定の領域に記憶する。図１２に、対戦ＩＤ＝１００の対戦結果の情報（対戦データベース）の一例を示す。対戦結果の情報には、対戦ＩＤ、対戦日時、勝利したチームのユーザＩＤ、敗北したチームのユーザＩＤ、対戦スコア、両チームの対戦に使用された（オーダーに含まれていた）選手キャラクタの個人成績、対戦寸評、対戦データファイルなどの対戦結果に関する情報が含まれる。

次に、画面生成手段６３について説明する。画面生成手段６３は、実行手段６２による実行結果に応じて、例えばＨＴＭＬデータからなるゲーム画面データを生成する。ＨＴＭＬデータには、データベースサーバ２から読み出された選手カード等の画像データを含めてもよい。また、ＨＴＭＬデータには、端末装置３のウェブブラウザのプラグインによって動作するスクリプト（プログラム）が埋め込まれていてもよい。ゲームサーバ１から提供されたスクリプトが端末装置３で実行される場合は、端末装置３で表示されるゲーム画面を動画とすることも可能である。あるいは、画面生成手段６３は、ストリーミング形式の映像を生成してもよい。

また、送信手段６４は、画面生成手段６３により生成された画面データ（ＨＴＭＬデータ、ストリーミング形式の映像データ等）を、ゲーム画面のリクエストに対するレスポンスとして、または実行手段６２による実行結果として、ユーザの端末装置３へ送信する。このゲーム画面データを受信したユーザの端末装置３では、ウェブブラウザおよびそのプラグイン等によって表示部３５にゲーム画面が表示される。

次に、アクセス管理手段６５について説明する。アクセス管理手段６５は、ゲームサービスを受けようとするユーザが端末装置３を操作してゲームサーバ１にアクセス（ログイン）しようとした際、当該ユーザのゲーム参加資格の有無を判断してログイン認証を行う。この認証の例としては、ユーザＩＤと対応付けられたログインＩＤおよびパスワードに基づく認証がある。また、ユーザがゲームサーバ１にアクセスする度にログインＩＤおよびパスワードを入力する手間を省略できるように、端末装置３である携帯電話やスマートフォンの個体識別番号（電話番号とは別の端末を一意に識別するための情報）、または契約者固有ＩＤ（端末の契約者を一意に識別するための情報であって、機種変更を行っても契約者が同一である限りは変更されないＩＤ）を利用した認証を行ってもよい。

次に、交流制御手段６６について説明する。交流制御手段６６は、ゲーム内で行われるユーザ同士の交流やコミュニケーションを実現するものである。交流制御手段６６は、ユーザの端末装置３から、他のユーザ（特に、仲間）に対して所定の交流を行う情報を受信し、受信した情報に基づいて、当該ユーザから当該他のユーザに対しての交流処理を実行する実行手段６２を制御する。交流処理には、例えば、挨拶、メッセージの伝達、プレゼント、チャットなどがある。

次に、図１３および図１４等の機能ブロック図等を参照して、ゲーム管理装置（ゲームサーバ１およびデータベースサーバ２）の主要な機能的構成について説明する。図１３に示すように、現実世界またはゲーム内で発生する結果を予想する予想ゲームを管理するゲーム管理装置としてのゲームサーバ１は、主に、予想補助情報生成手段７１および表示制御手段７２を備えている。これらの各手段は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。

予想補助情報生成手段７１は、過去の予想ゲームの結果、または各ユーザが現在予想中の情報に基づいて、ユーザの予想を補助するための予想補助情報を生成する機能を有する。また、表示制御手段７２は、ユーザが予想入力を行うための入力画面（例えば図５〜図８）内に、前記予想補助情報を表示させる機能を有する。

過去の予想ゲームの結果に基づく予想補助情報には、図５または図８に例示するように、予想対象（実在選手、選手キャラクタ、チーム等）を過去の評価の順に並べたランキング情報等がある。また、各ユーザが現在予想中の情報に基づく予想補助情報には、図５、図６、図８に例示するように、予想対象（実在選手、選手キャラクタ、チーム等）の人気の程度を示す情報（平均使用ホープ数の情報１１９、１４５等）がある。

本実施の形態の野球を対象とした予想ゲームでは、ユーザが野球に詳しくなければ、どの選手、チームが活躍するのかを予想するのが難しく感じることもある。このように、予想ゲームで対象としている分野の知識が乏しいユーザにとっては、予想に困ることもある。これに対して、本構成では、ユーザは、予想の入力画面内で、予想補助情報を見て、予想の手がかりを得ることができる。よって、予想ゲームで対象としている分野にあまり詳しくないユーザ等であっても、それほど予想に困ることなく、予想の入力を行うことができる、ユーザフレンドリーなゲーム環境を実現できる。

ここで、先ず、ゲーム内に存在する複数の選手キャラクタの中から活躍する選手キャラクタを予想する予想ゲームを管理するゲームサーバ１の機能的構成を、図１４を参照して説明する。図１４に示すように、ゲームサーバ１は、前記の予想補助情報生成手段７１および表示制御手段７２の他に、予想受付手段７３、評価手段７４、特典付与手段７５を備えている。

予想受付手段７３は、ユーザが所有している選手キャラクタの中から任意の選手キャラクタを選択したユーザからの予想入力を受け付ける機能を有する。ユーザは、図５または図６の入力画面において、活躍予想をしたい選手キャラクタの入力部１１４をクリックして「ホープ」を設定することができる。ユーザが端末装置３でこの予想入力操作をすれば、端末装置３からゲームサーバ１へ予想入力情報が送信される。ゲームサーバ１の予想受付手段７３は、この予想入力情報を受け付けて、ユーザＩＤと対応付けて予想入力情報をデータベースサーバ２に記憶する。図１５に、ユーザＩＤ＝０００００１のユーザの予想入力情報の一例を示す。ユーザＩＤと対応付けて記憶されている予想入力情報には、ユーザが「ホープ」を設定した選手キャラクタの選手ＩＤ（活躍予想の選手ＩＤ）と、「ホープ」の設定数の情報とが含まれる。また、本実施の形態の予想ゲームは、毎日、定期的に開催されるので、各日の予想ゲームには、それらを一意に識別するための予想ゲームＩＤが付される。そして、ユーザの予想入力情報にも、予想ゲームＩＤが対応付けられる。

また、ユーザが仲間の助っ人キャラクタを借りて予想入力を行った場合には、その仲間のユーザＩＤが併せて記憶される。

本実施の形態では、予想受付手段７３は、予想対象のキャラクタに重み（「ホープ」の数による重み）を設定したユーザからの予想入力を受け付けるが、予想の重み付けができない構成を採用することも可能である。例えば、ユーザが活躍を予想して入力した選手キャラクタには「１」ホープのみが設定され、それ以上のホープは設定できないようにしてもよい。

また、ユーザが活躍を予想できるキャラクタの数を、所定数以内に限定してもよい。本実施の形態では、ユーザの基本の予想枠は５枠であり、５人以内の選手キャラクの活躍を予想することができる。よって、予想受付手段７３は、原則、５人以内の選手キャラクに対するユーザの予想入力のみを受け付ける。但し、所定の条件（例えば、前回の予想ゲームで獲得したコインが１０００を超える、課金する等）を満たせば、ユーザの予想枠を基本の予想枠より増加させることができるようにしてもよい。

評価手段７４は、所定期間内に各ユーザがゲーム内で使用した選手キャラクタについてのゲーム結果を集計して、ゲーム内の選手キャラクタ毎に活躍を評価する機能を有する。本実施の形態では、毎日、０時から２４時までの２４時間を前記所定期間とし、この期間内に、全ユーザがゲーム内で行った全ての対戦結果を対象として集計が行われる。

ここで「活躍」に関し、野球ゲームでは、野手キャラクタによるヒット、盗塁、ファインプレイ等、投手キャラクタによる奪三振、勝利、セーブ等が含まれる。勝利した側のチームに貢献した選手キャラクタだけを活躍の評価対象とすることもできるが、負けたチームの選手キャラクタであっても、ヒットを打ったりファインプレイをしたりすれば、その選手キャラクタの活躍を評価の対象とすることができる。ゲーム内で各ユーザが使用した選手キャラクタを対象として、ゲーム内集計が行われるので、基本的に、対戦の勝敗に関わらず、各選手キャラクタの個人成績（安打、奪三振等）を活躍の評価対象とすることが好ましい。本実施の形態では、対戦の勝敗に関わらず、ゲーム内で使用された（各ユーザのチームオーダーに組み込まれた）選手キャラクタの個人成績を集計して、各選手キャラクタの活躍を評価する。

本実施の形態では、ゲームサーバ１が、図１６Ａ、図１６Ｂ、図１６Ｃに示す評価用情報を、記憶装置（ＲＡＭ１３、補助記憶装置１４等）に記憶しており、当該評価用情報に基づいて、ゲーム内の各選手キャラクタの活躍度を求める。図１６Ａは野手、図１６Ｂは先発投手、図１６Ｃはリリーフ投手（中継、抑え）の活躍度を求めるためのテーブルである。本実施の形態では、レベル１〜レベル６の６段階の活躍レベルで各選手キャラクタを段階的に評価する。活躍レベル毎に、予め活躍内容と活躍度との関係が定められている。

図１６Ａに示すように、野手の場合、活躍レベル＝１の活躍内容は「打席に立つ」であり、その活躍度は「１」である。また、活躍レベル＝２の活躍内容は「１安打、盗塁、四球」であり、その活躍度は「１０」である。また、活躍レベル＝３の活躍内容は「２安打、２塁打、１打点」であり、その活躍度は「１５」である。また、活躍レベル＝４の活躍内容は「３安打以上、２打点、３塁打、１本塁打」であり、その活躍度は「２０」である。また、活躍レベル＝５の活躍内容は「２本塁打以上、３打点以上」であり、その活躍度は「２５」である。また、活躍レベル＝６の活躍内容は「４打点以上、サイクルヒット」であり、その活躍度は「３０」である。

例えば、「２安打（単打：１、本塁打：１）３打点１盗塁」の活躍をした選手キャラクタを例に挙げて説明する。この選手キャラクタの場合、打席に立つ（レベル１）、盗塁（レベル２）、２安打（レベル３）、１本塁打（レベル４）、３打点（レベル５）であり、活躍レベル１〜５の何れの活躍内容にも含まれる活躍をしている。この場合、この選手キャラクタの活躍は、最も高い活躍レベル５（活躍内容：３打点）を適用する。よって、この選手キャラクタの活躍度は「２５」と決定される。また、打席に立ったが無安打の選手キャラクタは活躍レベル＝１であり、活躍度は「１」と決定される。また４打点以上を挙げた選手キャラクタは、安打数に依らず活躍レベル＝６であり、活躍度は「３０」と決定される。

また、図１６Ｂに示すように、先発投手の場合、活躍レベル＝１の活躍内容は「登板」であり、その活躍度は「１」である。また、活躍レベル＝２の活躍内容は「奪三振」であり、その活躍度は「１０」である。また、活躍レベル＝３の活躍内容は「９奪三振以上」であり、その活躍度は「１５」である。また、活躍レベル＝４の活躍内容は「勝利（勝利投手）」であり、その活躍度は「２０」である。また、活躍レベル＝５の活躍内容は「防御率３．００未満で勝利」であり、その活躍度は「２５」である。また、活躍レベル＝６の活躍内容は「防御率２．００未満で勝利」であり、その活躍度は「３０」である。

また、図１６Ｃに示すように、リリーフ投手の場合、活躍レベル＝２の活躍内容は「登板」であり、その活躍度は「１０」である。また、活躍レベル＝３の活躍内容は「奪三振」であり、その活躍度は「１５」である。また、活躍レベル＝４の活躍内容は「投球イニング１以上かつＷＨＩＰ１．００以下」であり、その活躍度は「２０」である。また、活躍レベル＝５の活躍内容は「セーブ」であり、その活躍度は「２５」である。また、活躍レベル＝６の活躍内容は「投球イニング１以上かつＷＨＩＰ１．００でセーブ」であり、その活躍度は「３０」である。なお、リリーフ投手は登板した時点で活躍レベル＝２となるので、活躍レベル＝１は存在しない。

図１２に例示するように、ゲーム内で実行された全ての対戦には、それらを識別する対戦ＩＤが付され、その対戦結果が対戦データベースに記憶されて管理されている。この対戦結果の情報には、ゲーム内で使用された選手キャラクタの個人成績（ゲーム実行のシミュレーション結果に基づく活躍内容）の情報が含まれている。図１２の対戦結果の例では、選手ＩＤ＝０００１の選手キャラクタは、対戦のシミュレーション結果として、４打数２安打（単打１、二塁打１）打点１の活躍をしている。

例えば、選手ＩＤ＝０００１の選手キャラクタＡを自分のチームのオーダーに設定して対戦を遊戯したユーザがゲーム内に１００人存在し、この選手キャラクタＡを使用した対戦が１日に合計で１０００試合実行されたと仮定する。この場合、前記１０００試合を対象として、選手キャラクタＡが打った安打数、２塁打数、３塁打数、本塁打数、打点、盗塁数、四球数等の１試合当たりの平均が算出される。この結果、例えば、安打数＝２．８、２塁打数＝０．４、３塁打数＝０．１、本塁打数＝１．８、打点３．１、盗塁数０．３、四球数１．２であった場合、これを選手キャラクタのゲーム内の活躍内容とする。なお、平均値の小数点以下は四捨五入、切り捨て等の処理をしてもよい。この選手キャラクタＡの活躍の評価は、図１６Ａの評価用情報に基づいて、活躍度「２５」に決定される。

あるいは、所定期間に選手キャラクタＡが使用された全試合（例えば、前記１０００試合）について、図１６Ａの評価用情報に基づいて、先ず、選手キャラクタＡの１試合毎の活躍度を求め、その後、対象となる全試合の活躍度の平均を算出することにより、所定期間における選手キャラクタＡの活躍度を求めてもよい。

このようにして、評価手段７４は、ゲーム内で各ユーザが使用した選手キャラクタを対象として、ゲーム内集計を行い、選手キャラクタ毎に評価としての活躍度を求める。

また、特典付与手段７５は、ユーザが予想入力した選手キャラクタの、評価手段７４による前記評価（活躍度）に応じた特典をユーザに付与する機能を有する。ここで、「特典」については、ゲーム内ポイントまたはアイテムの付与、キャラクタの能力向上、レアアイテムの抽選確率の上昇など、ゲームの種類や内容に応じた様々な特典を適用できる。本実施の形態では、特典として、ゲーム内ポイントのひとつである「コイン」をユーザに付与する。例えば、特典付与手段７５は、ユーザが予想入力した選手キャラクタの活躍度に、ユーザがその選手キャラクタに設定した「ホープ」数を乗じた分のコインを、ユーザに付与する。具体例を挙げると、ユーザが選手キャラクタＡに５「ホープ」を設定していた場合であって、選手キャラクタＡの活躍度が「２５」と決定された場合、２５×５＝１２５コインがそのユーザに付与される。

ユーザが複数の選手キャラクタに「ホープ」を設定していた場合、特典付与手段７５は、同様にして、当該複数の選手キャラクタのそれぞれについて、ユーザに付与するコインを算出し、それらの合計をユーザに付与する。

本実施の形態の予想補助情報生成手段７１は、前回の予想ゲームの結果（本実施の形態では各選手キャラクタの活躍度）に基づいて、各選手キャラクタを過去の評価の順（前回の活躍度の順）に並べたランキング情報を生成し、これを予想補助情報とする。そして、ユーザからの予想入力画面の要求に応じて、表示制御手段７２が、前記前回のランキング情報を含む予想入力画面のデータを生成してユーザの端末装置３に送信することにより、図５に示すように、入力画面内に予想補助情報としての前回のランキング情報を表示させる。

また、ゲームサーバ１は、図１７に示す報知手段７６を備えていることが好ましい。この報知手段７６は、予想入力画面内に前回のランキング情報として並べられた各キャラクタのうち、ユーザが所有しているキャラクタをユーザに報知する機能を有する。例えば、図５に示す予想入力画面には、前回の活躍度のランキング順に複数の選手キャラクタが並べて表示されるが、その中でユーザが所有している選手キャラクタには、未入手ラベル１１５（および助っ人ありラベル１１６）を表示せず、これをもって、その選手キャラクタをユーザが所有していることを報知している。

なお、ユーザが所有している選手キャラクタに、例えば「入手済みラベル」を付すことにより、前回の活躍度のランキング順に並べられた選手キャラクタのうち、どの選手キャラクタをユーザが所有しているのかを報知してもよい。また、入手（または未入手）を示すラベルを付すことの他にも、前回の活躍度のランキング順に並べられた選手キャラクタのうち、ユーザが所有しているものと、所有していないものとが区別できるように、両者の背景の色や濃淡を異ならせてもよい。

本予想ゲームでは、ユーザが予想対象とすることができる選手キャラクタは、ユーザが所有している選手キャラクタのみである。一方、予想入力画面に表示される、前回のランキング情報には、ユーザが所有していない選手キャラクタも含まれる。よって、前回のランキングの中で、自分が所有している選手キャラクタがどれかなのかが報知されることにより、ランキング情報を参考にした予想入力を円滑に行うことができるようになる。もし、ランキング情報の中に、ユーザが所有している選手キャラクタがない場合は、その選手キャラクタを入手しようとする動機づけが与えられ、ゲームが活性化される。

また、報知された選手キャラクタが高ランクであれば、次の予想ゲームでも高位置にランクされる可能性があることから、ユーザは、その選手キャラクタの活躍を予想して入力するといった対応が可能となる。また、前記の報知により、せっかく自分が所有していながらも、前回の予想ゲームで活躍予想の入力をしなかった選手キャラクタが高ランクになってしまったというケースも判明する。この場合、ユーザに対して、次はその選手キャラクタの活躍を予想した入力をしようとする動機付けを与えることができる。このように、過去の（本実施の形態では前回の）予想ゲームのランキング結果を入力画面に表示し、且つ、その中でユーザが所有している選手キャラクタを報知することにより、ゲーム性を高めることができる。

なお、前回の予想ゲームのランキング結果だけではなく、前々回のランキング結果や、さらに前のランキング結果を、予想入力画面内に表示できるようにしてもよい。例えば、予想入力画面内に、ｎ回前（ｎは正の整数）の予想ゲームのランキング結果に切り替えるための図示しない操作部（ボタン等）を設け、ユーザが、過去のランキング結果を任意に切り替えることができるようにしてもよい。

また、ゲームサーバ１は、図１７に示す仲間管理手段７７（関係管理手段）を備えていることが好ましい。この仲間管理手段７７は、ユーザに関係付けられた仲間（第２のユーザ）を管理する機能を有する。あるユーザが他のユーザと仲間関係を構築するための一形態としては、２人のユーザの何れか一方が、他方のユーザに対してゲームサーバ１を介して仲間申請を行い、当該仲間申請を受けたユーザがゲームサーバ１を介して仲間になることを承認するという、両ユーザ間においてなされる仲間申請とその承認の操作が挙げられる。その他の形態としては、既にゲームサービスに登録済みのユーザが、未登録のユーザをゲームに招待し、招待を受けたユーザがゲームサービスに登録した場合に、招待した側とされた側との２人のユーザを仲間同士とする形態もある。仲間管理手段７７は、図１０に例示するように、仲間関係にあるユーザ同士のユーザＩＤを関係付けてデータベースサーバ２に記憶し、仲間管理を行う。

そして、予想受付手段７３は、ユーザの仲間が所有している特定の選手キャラクタを選択したユーザからの予想入力も受け付けることが好ましい。前述のように、ユーザは、ゲーム内の全ての選手キャラクタを対象として活躍を予想できるわけではなく、自分の所有する選手キャラクタの中から予想対象を選択する必要がある。そして、本構成では、ユーザは、自分の所有する選手キャラクタ以外に、自分の仲間が所有している特定のキャラクタ（前記助っ人キャラクタ）も、予想入力の対象とすることができる。すなわち、ユーザは、仲間の助っ人キャラクタを借りて予想対象を拡大することができる。

本実施の形態では、仲間が所有している特定のキャラクタとは、仲間が貸出可能な設定をしているキャラクタである。但し、これに限定されるものではない。例えば、前記特定のキャラクタは、仲間が所有するキャラクタの中で、最も能力の高いキャラクタであってもよい。この場合、ユーザが貸出可能な設定操作をせずとも、仲間が所有するキャラクタの中で、最も能力の高いキャラクタを、ゲームサーバ１が自動的に、特定のキャラクタとして認定する。また、特定のキャラクタは、仲間が所有する最も希少度レベルの高いキャラクタの中からランダムに選択されたキャラクタであってもよい。あるいは、特定のキャラクタは、仲間のチームオーダーの４番打者のキャラクタであってもよい。これらは一例であり、ユーザの仲間が所有するキャラクタの中で、所定の条件を満たすキャラクタを、ゲームサーバ１が自動的に、特定のキャラクタとして認定してもよい。

そして、本実施の形態の報知手段７６は、入力画面内にランキング情報として並べられた各選手キャラクタのうち、仲間が所有している特定のキャラクタ（以下、「助っ人キャラクタ」と称する）も、ユーザに報知する。例えば、図５に示す予想入力画面には、前回の活躍度のランキング順に複数の選手キャラクタが並べて表示されるが、その中でユーザが所有していない選手キャラクタであり、且つ、仲間の助っ人キャラクタに該当するものには、助っ人ありラベル１１６が表示され、これをもって、仲間の助っ人キャラクタを報知している。これにより、どの選手キャラクタを仲間から借りて予想できるのかがランキング情報の中で明確化されるので、ユーザは円滑に予想入力を行うことができる。

また、本構成では、ユーザは、仲間の助っ人キャラクタを借りて予想対象を拡大することができるので、仲間が多いほど、予想対象のキャラクタが拡大する。よって、各ユーザは、積極的に多くの仲間を作ろうとする動機付けを与えられることになる。そして、各ユーザに仲間が増えることにより、ゲーム全体の活性化が図られる。

なお、仲間の助っ人キャラクタを使用した予想枠は、所定数に限定されている（本実施の形態では１枠のみ）。但し、ユーザの仲間の人数によって、助っ人キャラクタを使用した予想枠を変動させてもよい。例えば、ユーザの仲間の人数が所定数未満（例えば２９人まで）では、助っ人キャラクタを使用した予想枠は１枠のみであるが、仲間の人数が所定数以上（例えば、３０人以上）になれば、助っ人キャラクタを使用した予想枠が１枠増えて２枠になるようにしてもよい。

また、ゲームサーバ１は、図１７に示す報酬付与手段７８を備えていることが好ましい。この報酬付与手段７８は、ユーザによって、仲間の助っ人キャラクタを選択した予想入力が行われた場合、当該仲間に対して報酬を付与する機能を有する。ここで、仲間に対して報酬を付与するタイミングは、ユーザが仲間の助っ人キャラクタを選択して予想入力したタイミングであってもよいが、予想ゲームの結果が出た後であってもよい。特に、予想の締切期限まで、予想の取り消し又は変更を許可する場合、少なくとも予想の締切期限を経過した後に、前記報酬を付与することが好ましい。ここで、「報酬」については、ゲーム内ポイントまたはアイテムの付与、キャラクタの能力向上、レアアイテムの抽選確率の上昇など、ゲームの種類や内容に応じた様々な報酬を適用できる。

図１５に例示するように、ユーザが仲間の助っ人キャラクタを借りて予想入力を行った場合には、活躍予想の選手ＩＤ（助っ人キャラクタの選手ＩＤ）と対応付けて、当該仲間のユーザＩＤが併せて記憶される。この情報に基づいて、報酬付与手段７８は、助っ人キャラクタの持ち主である仲間に、報酬（例えば１００コイン）を付与する。

例えば、ユーザＡが仲間であるユーザＢのキャラクタを借りて活躍予想をすれば、報酬付与手段７８は、ユーザＢに報酬を付与する。また、ゲームサーバ１は、報酬を付与したユーザＢに対して、例えば「仲間のＡさんがあなたのキャラクタを助っ人として使用したので、あなたに１００コインが付与されました」というメッセージを送って、ユーザＡのおかげで報酬が付与された旨を報知する。

本構成では、ユーザＢのキャラクタを借りて予想をしたユーザＡは、ユーザＢに感謝するし、それによって報酬を得たユーザＢも、自分のキャラクタを活躍予想に使ってくれたユーザＡに感謝することが期待される。また、キャラクタの貸し借りを切っ掛けにして、仲間同士で御礼のメッセージを送り合うことも期待される。本構成により、予想対象のキャラクタの貸し借りをした仲間同士でのコミュニケーションを促進し、仲間同士のゲーム内交流を深めることができる。

ところで、前述のように、本実施の形態の予想受付手段７３は、予想対象のキャラクタに重み（「ホープ」の数による重み）を設定したユーザからの予想入力を受け付け、特典付与手段７５は、ユーザが予想入力したキャラクタの評価（活躍度）および前記重み（「ホープ」数）に応じた特典（コイン）をユーザに付与する。この構成において、ゲームサーバ１は、図１８に示す上限管理手段７９を備えていることが好ましい。

この上限管理手段７９は、各キャラクタに設定可能な前記重みの上限（最大ホープ数）を、各キャラクタの希少度に応じて異ならせる機能を有する。この構成の場合、同じキャラクタでも、その希少度によって、ユーザが設定できる「ホープ」の数の上限が異なる。キャラクタの希少度と、そのキャラクタに設定可能なホープ数の上限との関係の一例を、図１９に示す。同図に示すように、キャラクタの希少度とそのキャラクタに設定できる「ホープ」の数の上限との関係は、例えば、希少度１：８、希少度２：１０、希少度３：１２、希少度４：１４、希少度５：１６となっており、希少度が高いほど、キャラクタに設定できる「ホープ」の数の上限も大きくなる。なお、キャラクタの希少度と設定可能なホープ数の上限との関係は、上記に限定されるものではなく、任意に設定可能である。

本構成の場合、ユーザは、より大きな重みを設定するには、より高い希少度のキャラクタを所有している必要がある。よって、ユーザに対して、希少度の高いキャラクタを入手しようとする動機付けを与えることができる。

ところで、予想入力画面に表示される予想補助情報には、各ユーザが現在予想中の情報をまとめた統計情報であって、各キャラクタの人気の程度を示す情報を含めることができる。この情報の一例としては、図５または図６に示す平均使用ホープ数の情報１１９がある。ゲームサーバ１は、全ユーザがキャラクタに設定している「ホープ」の情報を集計し、ゲーム内のキャラクタ毎に、現在設定されている平均のホープ数（平均使用ホープ数）を算出する。そして、ゲームサーバ１は、予想入力画面に表示されている選手キャラクタに対して、平均使用ホープ数の情報１１９を表示する表示制御を行う。平均使用ホープ数が大きいということは、それだけ誰もがそのキャラクタの活躍を確実視しているということであり、予想の手がかりとなる。

また、全ユーザがキャラクタに設定している「ホープ」の情報を集計し、ゲーム内のキャラクタ毎に、「ホープ」を設定している人数、設定されている「ホープ」の総数などの統計情報を求め、これを各キャラクタの人気の程度を示す情報として、予想入力画面に表示してもよい。このような情報を予想補助情報として、ユーザが予想入力を行うための入力画面内に表示するので、ユーザはこれを予想の手がかりとすることができる。よって、予想に困ることなく予想入力が可能なユーザフレンドリーなゲーム環境を実現できる。

ここで、本実施の形態のゲームサーバ１の動作例を、図２０及び図２１のフローチャートを参照しながら、以下に説明する。

ユーザが自分の端末装置３でゲーム結果予想モードを選択する操作を行えば、端末装置３からゲームサーバ１へ、予想入力画面の要求が送信される。ゲームサーバ１は、ユーザより予想入力画面の要求があれば（Ｓ１でＹＥＳ）、前回の予想ゲームの結果（各選手キャラクタの活躍度）に基づいて、前回のランキング順に選手キャラクタを並べた入力画面のデータを生成する（Ｓ２）。

また、ゲームサーバ１は、前回のランキング順に並べられた選手キャラクタのうち、ユーザが所有している選手キャラクタを報知するための情報を、前記入力画面に含める（Ｓ３）。また、ゲームサーバ１は、前回のランキング順に並べられた選手キャラクタのうち、ユーザ自身は所有していないが、仲間の助っ人キャラクタに該当する選手キャラクタを報知する情報も、前記入力画面に含める（Ｓ４）。さらに、ゲームサーバ１は、全ユーザがキャラクタに設定している「ホープ」の情報を集計し、入力画面に表示されている各選手キャラクタに現時点で設定されている全体平均のホープ数（平均使用ホープ数）の情報も、前記入力画面に含める（Ｓ５）。

そして、ゲームサーバ１は、ステップＳ２〜Ｓ５の処理によって生成した入力画面データを、ユーザの端末装置３に送信する（Ｓ６）。これにより、ユーザの端末装置３には、図５に例示する予想入力画面が表示される。この予想入力画面内には、予想補助情報として、前回のランキング情報や現時点での平均使用ホープ数の情報が表示されるので、ユーザは予想の手がかりを得ることができる。

その後、ユーザにより任意の選手キャラクタを選択した予想入力が行われた場合（図２１のＳ７でＹＥＳ）、ゲームサーバ１はその予想入力を受け付け（Ｓ８）、ユーザＩＤと対応付けて予想入力情報（図１５参照）をデータベースサーバ２に記憶する（Ｓ９）。この予想入力情報には、ユーザが活躍予想をした（「ホープ」を設定した）選手キャラクタの選手ＩＤおよび「ホープ」の設定数の情報を含む。

前記ステップＳ１〜Ｓ９は、予想ゲームの締切期限（本実施の形態では２４時）まで繰り返される。そして、締切期限になれば（Ｓ１０でＹＥＳ）、ゲームサーバ１は、所定期間（本実施の形態では０時〜２４時の２４時間）の全対戦結果を集計し（Ｓ１１）、対戦で使用された選手キャラクタ毎に活躍度を求める（Ｓ１２）。本実施の形態では、図１６Ａ〜図１６Ｃの評価用情報に基づいて、各選手キャラクタの活躍度が決定される。

その後、ゲームサーバ１は、ユーザが予想入力したキャラクタの活躍度に応じた特典（本実施の形態ではコイン）をユーザに付与する（Ｓ１３）。すなわち、ユーザが予想入力した選手キャラクタの活躍度に、ユーザがその選手キャラクタに設定した「ホープ」数を乗じた分のコインをユーザに付与する。なお、ユーザが仲間の助っ人キャラクタを借りて予想入力を行っていた場合、図１５に例示するように、当該仲間のユーザＩＤも記憶されているので、当該仲間にも報酬（例えば１００コイン）を付与してもよい。

そして、ゲームサーバ１は、各ユーザに、予想ゲームの結果、付与した特典、報酬を報知する（Ｓ１４）。なお、ユーザの端末装置３がゲームサーバ１にログインしている場合は、ゲームサーバ１はそのユーザに直ぐに報知できるが、もしログインしていない場合は、その後のログイン時に報知することになる。勿論、ユーザの端末装置３がゲームサーバ１に常時接続している場合は、ゲームサーバ１はユーザに直ぐに報知できる。

以上のように、本実施の形態では、各ユーザがゲーム内で使用するキャラクタについてのゲーム結果を集計して、ゲーム内の各キャラクタの活躍を評価するので、現実世界で予想の対象となる野球の試合等が行われない日にも（例えば野球のオフシーズンにも）、ユーザが安定的に予想ゲームを遊戯できるようになる。

また、各ユーザがゲーム内で使用したキャラクタの活躍が、予想ゲームにおけるそのキャラクタの活躍の全体評価にも反映される。すなわち、各ユーザによるキャラクタを使用した遊戯（本実施の形態では対戦モードの遊戯）が予想ゲームとリンクしている。このことから、各ユーザは、特に自分が活躍予想をしたキャラクタを使用して遊戯する場合、そのキャラクタに対してより良いゲーム結果を出せるように遊戯を行なおうとする。これにより、予想ゲームにリンクしているゲーム内の遊戯モードの興趣性を高めることができる。

次に、ゲーム内に存在する複数のチームの中から活躍するチームを予想する予想ゲームを管理するゲームサーバ１の機能的構成を、図２２を参照して説明する。同図に示すように、ゲームサーバ１は、前記の予想補助情報生成手段７１および表示制御手段７２の他に、関係付け手段８０、第２予想受付手段８１、第２評価手段８２、第２特典付与手段８３を備えている。

本実施の形態の予想補助情報生成手段７１は、前回の予想ゲームの結果（本実施の形態では各チームの勝率）に基づいて、各チームを過去の評価の順（前回の勝率の順）に並べたランキング情報を生成し、これを予想補助情報とする。そして、ユーザからの予想入力画面の要求に応じて、表示制御手段７２が、前記前回のランキング情報を含む予想入力画面のデータを生成してユーザの端末装置３に送信することにより、図８に示すように、入力画面内に予想補助情報としての前回のランキング情報を表示させる。

また、予想補助情報生成手段７１は、各ユーザが現在予想中の情報をまとめた統計情報であって、各チームの人気の程度を示す情報（前述の平均使用ホープ数の情報）を生成する。そして、表示制御手段７２が、図８の予想入力画面に表示されているチームに対して、平均使用ホープ数の情報１４５を表示する表示制御を行う。平均使用ホープ数が大きいということは、それだけ誰もがそのチームの活躍を確実視しているということであり、予想の手がかりとなる。

また、全ユーザがチームに設定している「ホープ」の情報を集計し、ゲーム内のチーム毎に、「ホープ」を設定している人数、設定されている「ホープ」の総数などの統計情報を求め、これを各チームの人気の程度を示す情報として、予想入力画面に表示してもよい。

このように、ユーザがチームに対する予想入力を行うための入力画面内にも、ユーザの予想を補助するための予想補助情報（前記ランキング情報、平均使用ホープ数等）が表示されるので、ユーザはそれほど予想に困ることなく、予想の入力を行うことができる。

関係付け手段８０は、ゲーム内に存在する複数のチームの何れかのチームと、各ユーザとを関係付ける機能を有する。本実施の形態では、前述のように、ゲーム開始時に、各ユーザがゲーム内の複数のチーム（プロ野球１２球団に対応するチーム）の中からお気に入りチームを選択する。そして、関係付け手段８０は、図１０に示すように、ユーザが選んだお気に入りチーム（またはそのチームＩＤ）と、当該ユーザのユーザＩＤとを関係付けて、データベースサーバ２に記憶する。

第２予想受付手段８１は、ゲーム内に存在する前記複数のチームの中から任意のチームを選択したユーザからの予想入力を受け付ける機能を有する。ユーザは、図８の入力画面において、活躍予想をしたいチームの入力部１４３をクリックして「ホープ」を設定することができる。ユーザが端末装置３でこの予想入力操作をすれば、端末装置３からゲームサーバ１へ予想入力情報が送信される。ゲームサーバ１の第２予想受付手段８１は、この予想入力情報を受け付けて、ユーザＩＤと対応付けて予想入力情報をデータベースサーバ２に記憶する。図２３に、ユーザＩＤ＝０００００１のユーザの予想入力情報の一例を示す。ユーザＩＤと対応付けて記憶されている予想入力情報には、ユーザが「ホープ」を設定したゲーム内のチーム（活躍予想のチーム）と、「ホープ」の設定数の情報とが含まれる。また、ユーザの予想入力情報には、予想ゲームＩＤも対応付けられる。

本実施の形態では、予想対象のチームに重み（「ホープ」の数による重み）を設定したユーザからの予想入力を受け付けるが、予想の重み付けができない構成を採用することも可能である。例えば、ユーザが活躍を予想して入力したチームには「１」ホープのみが設定され、それ以上のホープは設定できないようにしてもよい。

本実施の形態では、ユーザが活躍を予想できるチームの数に制限はなく、ゲーム内の１２チームの全てに「ホープ」を設定することができる。なお、選手キャラクタの予想と同様に、ユーザが活躍を予想できるチームを、所定数（例えば５チーム）以内に限定してもよい。

第２評価手段８２は、所定期間内に各ユーザが実行したゲーム結果を集計して、各ユーザに関係付けられているチーム毎に活躍を評価する機能を有する。本実施の形態では、選手キャラクタの予想と同様に、毎日、０時から２４時までの２４時間を前記所定期間とし、この期間内に、全ユーザがゲーム内で行った全ての対戦結果を対象として集計が行われる。

図１２に例示するように、ゲーム内で実行された全ての対戦には、それらを識別する対戦ＩＤが付され、その対戦結果が対戦データベースに記憶されて管理されている。この対戦結果の情報には、勝利チームのユーザＩＤおよび敗戦チームのユーザＩＤの情報が含まれている。例えば、お気に入りチームが「チームＧ」のユーザＡが対戦で勝利した場合、ユーザＡに関係付けられている「チームＧ」が勝利したものとして集計される。同様に、お気に入りチームが「チームＧ」の各ユーザの対戦結果（勝敗）は、全て「チームＧ」の対戦結果として集計される。そして第２評価手段８２は、は、ゲーム内のチーム毎に、勝率を算出し、勝率に基づく各チームのランキングを求め、このランキングにより各チームを評価する。本実施の形態では、ゲームサーバ１が、図２４に示す評価用情報を、記憶装置（ＲＡＭ１３、補助記憶装置１４等）に記憶しており、当該評価用情報に基づいて、ゲーム内のチームの活躍度を求める。

このように、ゲーム内のチームの活躍の評価は、勝率に基づいて行うことが好ましい。その理由は、チーム毎に、関係付けられているユーザ数が異なるので、チームの評価がユーザ数に依存しないようにするためである。仮に、勝ち数に基づいてチームを評価した場合、お気に入りチームとして選択しているユーザが多い特定のチームの評価が常に高くなってしまう可能性があるが、勝率に着目して各チームを評価すれば、そのようなことはなくなる。

また、第２特典付与手段８３は、ユーザが予想入力したチームの前記評価（活躍度）に応じた特典をユーザに付与する機能を有する。本実施の形態では、チームの活躍度（図２４参照）に、ユーザが設定した「ホープ」数を掛け合わせた数のコインを、特典としてユーザに付与する。例えば、ユーザが５「ホープ」を設定したチームがランキング１位（活躍度＝２０）になった場合、２０×５＝１００コインがユーザに付与される。

以上のように、本構成では、各ユーザが通常行う遊戯のゲーム結果を集計して、ゲーム内のチームの活躍を評価するので、現実世界で予想の対象となる野球の試合等が行われない日にも（例えば野球のオフシーズンにも）、ユーザが安定的に予想ゲームを遊戯できるようになる。

また、各ユーザには、ゲーム内の複数のチームの何れかが対応づけられているので、ユーザのゲーム結果が、予想ゲームにおけるそのチームの活躍の全体評価にも反映される。すなわち、各ユーザによる遊戯が予想ゲームとリンクしている。このことから、各ユーザは、特に自分に関係付けられているチームを活躍するチームとして予想した場合、自分自身が良いゲーム結果を出せるように遊戯を行なおうとする。これにより、予想ゲームにリンクしているゲーム内の遊戯モードの興趣性を高めることができる。

次に、現実世界に存在する複数の実在物（本実施の形態では野球選手）の中から活躍する実在物を予想するゲームを管理するゲームサーバ１の機能的構成を、図２５を参照して説明する。同図に示すように、ゲームサーバ１は、前記の予想補助情報生成手段７１および表示制御手段７２の他に、第３予想受付手段８４、第３評価手段８５、第３特典付与手段８６を備えている。

本実施の形態の予想補助情報生成手段７１は、前回の予想ゲームの結果（本実施の形態では実在選手の活躍度）に基づいて、実在選手に対応する選手キャラクタを過去の評価の順（前回の活躍度の順）に並べたランキング情報を生成し、これを予想補助情報とする。そして、ユーザからの予想入力画面の要求に応じて、表示制御手段７２が、前記前回のランキング情報を含む予想入力画面のデータを生成してユーザの端末装置３に送信することにより、図５に示すように、入力画面内に予想補助情報としての前回のランキング情報を表示させる。

また、予想補助情報生成手段７１は、選手キャラクタの予想と同様に、各ユーザが現在予想中の情報をまとめた統計情報であって、各選手の人気の程度を示す情報（前述の平均使用ホープ数の情報）を生成する。そして、表示制御手段７２が、図５の予想入力画面に表示されている選手キャラクタに対して、平均使用ホープ数の情報１１９を表示する表示制御を行う。このように、ユーザが実在選手に対する予想入力を行うための入力画面内にも、ユーザの予想を補助するための予想補助情報（前記ランキング情報、平均使用ホープ数等）が表示されるので、ユーザはそれほど予想に困ることなく、予想の入力を行うことができる。

第３予想受付手段８４は、ユーザが所有しているキャラクタの中から、現実世界での活躍を予想した実在選手に対応する選手キャラクタを選択したユーザからの予想入力を所定の締切期限（例えば現実の試合開始１時間前）まで受け付ける機能を有する。この機能は、前述した選手キャラクタの予想と同様の機能である。ユーザが図５の予想入力画面で予想入力操作をすれば、端末装置３からゲームサーバ１へ予想入力情報が送信される。ゲームサーバ１の第３予想受付手段８４は、この予想入力情報を受け付けて、ユーザＩＤと対応付けて、図１５に例示する予想入力情報をデータベースサーバ２に記憶する。

また、第３評価手段８５は、前記締切期限以降に、前記実在選手の現実世界での活躍を評価する機能を有する。ゲームサーバ１には、実在選手の現実世界での活躍内容（実績）に関する情報が入力される。ここで入力される活躍内容としては、例えば図１６Ａ〜図１６Ｃの評価用情報に含まれる活躍内容（安打、盗塁、奪三振等）が挙げられる。なお、実在選手の活躍内容に関する情報については、ゲーム運営側のオペレータによってゲームサーバ１に直接的に入力またはネットワーク等を介して提供されるものであってもよいし、野球の試合の情報を販売等している会社やその系列グループのサーバから提供を受けた情報であってもよい。例えば、選手がヒットを打った等の情報を、１球毎、イニング毎または試合終了後に提供するような情報提供サーバは数多く存在するので、そのようなサーバの提供情報を利用して、実在選手の現実の試合での活躍内容の情報をゲームサーバ１に取り込むこともできる。また、前記活躍内容の情報は、現実世界の試合の画像や音声等を自動的に分析することによって取得される情報であってもよい。

そして、第３評価手段８５は、例えば図１６Ａ〜図１６Ｃの評価用情報に基づいて、実在選手毎に、現実世界での活躍を評価し、活躍度を求める。そして、第３特典付与手段８６は、ユーザが予想入力したキャラクタに対応した実在選手の前記評価（活躍度）に応じた特典をユーザに付与する機能を有する。本実施の形態では、実在選手の活躍度に、ユーザが設定した「ホープ」数を掛け合わせた数のコインを、特典としてユーザに付与する。例えば、ユーザが５「ホープ」を設定した選手キャラクタに対応する実在選手の活躍度が「２０」であった場合、２０×５＝１００コインがユーザに付与される。

本構成でも、ユーザは、予想の入力画面内で、予想補助情報を見て、予想の手がかりを得ることができる。よって、予想ゲームで対象としている分野（例えば野球）に詳しくないユーザであっても、それほど予想に困ることなく、予想の入力を行うことができる、ユーザフレンドリーなゲーム環境を実現できる。

次に、現実世界に存在する複数の実在チーム（本実施の形態ではプロ野球の実在チーム）の中から活躍する実在チームを予想するゲームを管理するゲームサーバ１の機能的構成を、図２６を参照して説明する。同図に示すように、ゲームサーバ１は、前記の予想補助情報生成手段７１および表示制御手段７２の他に、第４予想受付手段９４、第４評価手段９５、第４特典付与手段９６を備えている。

本実施の形態の予想補助情報生成手段７１は、前回の予想ゲームの結果（本実施の形態では実在チームの勝敗）に基づいて、各チームの前回の勝敗情報を生成し、これを予想補助情報とする。そして、ユーザからの予想入力画面の要求に応じて、表示制御手段７２が、各チームの前回の勝敗情報を含む予想入力画面のデータを生成してユーザの端末装置３に送信することにより、図７に示すように、入力画面内に予想補助情報としての前回の勝敗情報１３４を表示させる。なお、予想補助情報は、前日の勝敗情報に限定されるものではなく、例えば各実在チームの前週の勝率等の情報であってもよい。

このように、ユーザが実在チームに対する予想入力を行うための入力画面内にも、ユーザの予想を補助するための予想補助情報が表示されるので、ユーザはそれほど予想に困ることなく、予想の入力を行うことができる。

第４予想受付手段９４は、複数の実在チームの中から任意の実在チームを選択したユーザからの予想入力を所定の締切期限（例えば現実の試合開始１時間前）まで受け付ける機能を有する。本実施の形態では、図７の入力画面において、その日に開催されるプロ野球の対戦カードに対して、ユーザが勝利する側のチームを予想して「ホープ」を設定する予想入力を行う。ユーザが端末装置３でこの予想入力操作をすれば、端末装置３からゲームサーバ１へ予想入力情報が送信される。ゲームサーバ１の第４予想受付手段９４は、この予想入力情報を受け付けて、ユーザＩＤと対応付けて予想入力情報をデータベースサーバ２に記憶する。

本実施の形態では、予想対象のチーム（そのチームの対戦カード）に重み（「ホープ」の数による重み）を設定したユーザからの予想入力を受け付けるが、予想の重み付けができない構成を採用することも可能である。例えば、ユーザが勝敗を予想して入力した対戦カードには「１」ホープのみが設定され、それ以上のホープは設定できないようにしてもよい。

また、本実施の形態では、ユーザが勝敗を予想できる対戦カードに制限はなく、全対戦カードの全てに「ホープ」を設定することができる。なお、勝敗予想できる対戦カードを、所定数（例えば３）以内に限定してもよい。

第４評価手段９５は、前記締切期限以降に、前記実在チームの現実世界での活躍を評価する機能を有する。ゲームサーバ１には、現実世界での対戦カードの勝敗に関する情報が入力される。なお、この情報については、ゲーム運営側のオペレータによってゲームサーバ１に直接的に入力またはネットワーク等を介して提供されるものであってもよいし、野球の試合の情報を販売等している会社やその系列グループのサーバから提供を受けた情報であってもよい。第４評価手段９５は、現実世界での試合に勝利した実在チームを評価し、第４特典付与手段９６は、ユーザが予想入力した実在チームの前記評価に応じた特典をユーザに付与する。すなわち、ユーザが勝利を予想して入力した実在チームが現実世界で勝利したチームとして評価された場合（対戦カードの勝敗予想が的中した場合、）、ユーザに特典としてコインが付与される。例えば、ユーザが設定した「ホープ」数に所定値（例えば１０）を掛け合わせた数のコインが、特典としてユーザに付与される。ユーザが複数の対戦カードの勝敗を予想していた場合、第４特典付与手段９６は、それぞれの対戦カードに対してユーザが獲得したコインを算出し、それらを合計してユーザに付与する。

本構成においても、ユーザが予想入力を行うための入力画面内には、ユーザの予想を補助するための予想補助情報が表示される。よって、予想ゲームで対象としている分野（例えば野球）に詳しくないユーザであっても、それほど予想に困ることなく、予想の入力を行うことができる、ユーザフレンドリーなゲーム環境を実現できる。

〔ゲームシステムの他の構成例〕
前述の各実施の形態では、ゲーム実行プログラムがゲームサーバ１側に実装されており、各ユーザの端末装置３における入力操作に応じて、ゲームサーバ１がゲーム進行のための演算処理やデータ処理を実行し、その実行結果を反映させた画面データを端末装置３へ送信することによって、ゲームが進行するゲームシステムへの適用例について説明した。これはいわゆるクライアントサーバ型のゲームシステムであり、サーバ（ゲームサーバ１およびデータベースサーバ２）によってゲーム管理装置を構成する例である。この構成は、前述のように、ブラウザゲーム、ソーシャルゲーム、クラウドゲーミング等のサービスをユーザに提供するのに適した構成であるが、ゲーム管理装置の構成はこれに限定されない。

例えば、ゲームサーバ１が、各ユーザのゲーム情報を管理し、ゲーム内でのユーザ間の交流等のゲームサービスをユーザに提供する一方、ゲームを進行させるゲーム実行処理については、基本的にはユーザの端末装置側にて行われるゲームシステムにも適用できる。

すなわち、ゲーム実行プログラムの一部または全部をユーザの端末装置側にダウンロードまたはインストールし、端末装置においてもゲーム実行処理が行われるようなゲームシステムにも適用できる。例えば、ユーザの端末装置が、インターネット通信、無線ＬＡＮ通信、所定の周波数帯（例えば２．４ＧＨｚの周波数帯）を用いた近距離無線通信、または有線ＬＡＮ通信などにより他のユーザの端末装置とピア・ツー・ピア接続し、ピア・ツー・ピア型のゲームを実行することも可能である。

そして、サーバと端末装置とは互いに通信して各種データの送受が可能であり、共にＣＰＵ、ＲＯＭ、ＲＡＭ、補助記憶装置、通信制御部等を備えた情報処理装置（コンピュータ）であって、同様のハード構成を有する。よって、サーバと端末装置とを含むゲームシステムにおいて、上述の各実施の形態で説明したゲーム管理装置が具備する各手段は、サーバ又は端末装置の何れか一方が備えていればよい。すなわち、ゲーム管理装置は、互いに通信して各種データの送受を行うサーバおよび端末装置に設けられる構成とすることができ、前述の実施の形態と同様の作用効果を奏する。

例えば、図１３ではゲームサーバ１が、予想補助情報生成手段７１および表示制御手段７２を備えていたが、図２７に例示するように、各手段の機能をサーバおよび端末装置の何れかに持たせることが可能である。ここで、図２７に示すサーバのハード構成は、図２に示したゲームサーバ１と同様であり、端末装置のハード構成は、図３に示した端末装置３と同様である。図２７には、サーバ１０１に予想補助情報生成手段７１を設けると共に、端末装置３０１に表示制御手段７２を設ける構成例を示している。なお、図２７はゲームシステムの構成の一例であり、他の構成も可能である。

また、図２８に示すように、端末装置３０１が、予想補助情報生成手段７１および表示制御手段７２を備えている構成とすることもできる。すなわち、ゲーム管理装置をゲーム端末である端末装置３０１それ自体に実装することができ、この場合も前述の実施の形態と同様の作用効果を奏する。この場合、サーバ１０１が、各ユーザのゲーム情報を管理したり、端末装置３０１間で行われる挨拶やメッセージの送受等のサービスをユーザに提供したりするが、その他の処理は全て端末装置３０１側で実行されるようにすることができる。あるいは、各ユーザのゲーム情報の管理も、各ユーザの端末装置３０１側で行うこともできる。

また、前述の各手段７３〜８６、９４〜９６等についても、サーバ側だけではなく、端末装置（ゲーム端末）側に設けることもできる。

〔その他の実施の形態〕
前記の実施の形態では、ユーザと関連付けがなされている他のユーザを仲間とする例を示したが、ユーザと関連付けがなされている他のユーザであれば、仲間という関係でなくても本発明を適用できる。

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

また、前述の各実施の形態で説明した各構成は、適宜組み合わせて適用することができる。

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

１ ゲームサーバ（ゲーム管理装置）
２ データベースサーバ（ゲーム管理装置）
３ 端末装置
７１ 予想補助情報生成手段
７２ 表示制御手段
７３ 予想受付手段
７４ 評価手段
７５ 特典付与手段
７６ 報知手段
７７ 仲間管理手段（関係管理手段）
７８ 報酬付与手段
７９ 上限管理手段
８０ 関係付け手段
８１ 第２予想受付手段
８２ 第２評価手段
８３ 第２特典付与手段
８４ 第３予想受付手段
８５ 第３評価手段
８６ 第３特典付与手段
９４ 第４予想受付手段
９５ 第４評価手段
９６ 第４特典付与手段
１０１ サーバ（ゲーム管理装置、ゲームシステム）
３０１ 端末装置（ゲーム管理装置、ゲームシステム）

Claims (13)

1. 現実世界またはゲーム内で発生する結果を予想する予想ゲームを管理するゲーム管理装置であって、
   前記予想ゲームは、ゲーム内に存在する複数のキャラクタの中から活躍するキャラクタを予想するゲームを含み、
   過去の予想ゲームの結果、または各ユーザが現在予想中の情報に基づいて、ユーザの予想を補助するための予想補助情報を生成する予想補助情報生成手段と、
   ユーザが予想入力を行うための入力画面内に、前記予想補助情報を表示させる表示制御手段と、
   ユーザが所有しているキャラクタおよびユーザに関係付けられた第２のユーザが所有している特定のキャラクタの中から任意のキャラクタを選択したユーザからの予想入力を受け付ける予想受付手段と、
   所定期間内に各ユーザが個々に行ったゲーム内で使用したキャラクタについての複数のゲーム結果を全体集計して、キャラクタ毎に活躍を評価する評価手段と、
   ユーザが予想入力したキャラクタの前記評価に応じた特典をユーザに付与する特典付与手段と、を備えるゲーム管理装置。
2. 前記予想補助情報には、各キャラクタを過去の評価の順に並べたランキング情報を含み、
   前記入力画面内に前記ランキング情報として並べられた各キャラクタのうち、ユーザが所有しているキャラクタをユーザに報知する報知手段をさらに備える請求項１に記載のゲーム管理装置。
3. ユーザに関係付けられた第２のユーザを管理する関係管理手段をさらに備え、
   前記報知手段は、前記入力画面内に前記ランキング情報として並べられた各キャラクタのうち、前記第２のユーザが所有している特定のキャラクタもユーザに報知する請求項２に記載のゲーム管理装置。
4. ユーザによって、前記第２のユーザが所有している特定のキャラクタを選択した予想入力が行われた場合、当該第２のユーザに対して報酬を付与する報酬付与手段をさらに備える請求項１ないし３の何れか１項に記載のゲーム管理装置。
5. 前記予想受付手段は、予想対象のキャラクタに重みを設定したユーザからの予想入力を受け付け、
   前記特典付与手段は、ユーザが予想入力したキャラクタの前記評価および前記重みに応じた特典をユーザに付与し、
   各キャラクタに設定可能な前記重みの上限を、各キャラクタの希少度に応じて異ならせる上限管理手段をさらに備える請求項１ないし４の何れか１項に記載のゲーム管理装置。
6. 前記予想補助情報には、各ユーザが現在予想中の情報をまとめた統計情報であって、各キャラクタの人気の程度を示す情報を含む請求項１ないし５の何れか１項に記載のゲーム管理装置。
7. 前記予想ゲームは、ゲーム内に存在する複数のチームの中から活躍するチームを予想するゲームを含み、
   前記複数のチームの中の何れかのチームと、各ユーザとを関係付ける関係付け手段と、
   前記複数のチームの中から任意のチームを選択したユーザからの予想入力を受け付ける第２予想受付手段と、
   所定期間内に各ユーザが実行したゲーム結果を集計して、各ユーザに関係付けられているチーム毎に活躍を評価する第２評価手段と、
   ユーザが予想入力したチームの前記評価に応じた特典をユーザに付与する第２特典付与手段と、をさらに備える請求項１ないし６の何れか１項に記載のゲーム管理装置。
8. ゲーム内には現実世界に存在する複数の実在物のそれぞれに対応する複数のキャラクタが存在し、
   前記予想ゲームは、前記複数の実在物の中から活躍する実在物を予想するゲームを含み、
   ユーザが所有しているキャラクタの中から、現実世界での活躍を予想した実在物に対応するキャラクタを選択したユーザからの予想入力を所定の期限まで受け付ける第３予想受付手段と、
   前記期限以降に、前記実在物の現実世界での活躍を評価する第３評価手段と、
   ユーザが予想入力したキャラクタに対応した実在物の前記評価に応じた特典をユーザに付与する第３特典付与手段と、をさらに備える請求項１ないし７の何れか１項に記載のゲーム管理装置。
9. 前記予想ゲームは、現実世界に存在する複数の実在チームの中から活躍する実在チームを予想するゲームを含み、
   前記複数の実在チームの中から任意の実在チームを選択したユーザからの予想入力を所定の期限まで受け付ける第４予想受付手段と、
   前記期限以降に、前記実在チームの現実世界での活躍を評価する第４評価手段と、
   ユーザが予想入力した実在チームの前記評価に応じた特典をユーザに付与する第４特典付与手段と、をさらに備える請求項１ないし８の何れか１項に記載のゲーム管理装置。
10. ユーザが操作するゲーム端末装置と通信可能なサーバとして構成される請求項１ないし９の何れか１項に記載のゲーム管理装置。
11. ユーザが操作するゲーム端末装置として構成される請求項１ないし９の何れか１項に記載のゲーム管理装置。
12. 相互に通信するサーバと端末装置とを含むゲームシステムとして構成され、前記各手段、を前記サーバ又は前記端末装置のいずれか一方が備える請求項１ないし９の何れか１項に記載のゲーム管理装置。
13. コンピュータを請求項１ないし９の何れか１項に記載のゲーム管理装置として動作させるためのプログラムであって、前記コンピュータを前記ゲーム管理装置が備えている各手段として機能させるためのプログラム。

Images