以下、本発明の一実施の形態に係るゲーム管理装置、ゲームシステム、ゲーム管理方法及びプログラムについて、図面を参照しながら説明する。
〔ゲームシステムの概要〕
本発明の一実施の形態に係るゲーム管理装置が組み込まれたゲームシステムの構成例を、図1に示している。同図に示すように、このゲームシステムは、インターネットなどのネットワーク4上に設置されたゲームサーバ1と、当該ゲームサーバ1と通信可能に接続されたデータベースサーバ2と、ネットワーク4を介してゲームサーバ1と通信可能に接続できる各ユーザの端末装置3とによって構成される。
本実施の形態のネットワーク4は、インターネットに限定されるものではなく、ゲームサーバ1と各ユーザの端末装置3との間を通信可能に相互に接続できるものであれば、例えば、専用回線、公衆回線(電話回線、移動体通信回線等)、有線LAN(Local Area Network)、無線LAN等であってもよく、或いはインターネットとこれらを組み合わせたものであってもよい。
このゲームシステムの例において、本発明の一実施の形態に係るゲーム管理装置は、ゲームサーバ1およびデータベースサーバ2から構成することができる。ゲームサーバ1は、ゲームサービスを受ける各ユーザの端末装置3からのネットワーク4を介したアクセスを受け付けて、各ユーザのゲーム情報をデータベースサーバ2(記憶装置)に蓄積して管理し、各ユーザにネットワーク4を介したゲームサービスを提供する。
ゲームサーバ1によるゲームサービスの提供の形態としては、ゲーム用のプログラム(アプリケーションソフトウェア)がゲームサーバ1に実装されており、端末装置3でゲームを実行するのではなく、端末装置3でのゲーム操作入力に応じてゲームサーバ1でゲームを実行し、その実行結果を各ユーザの端末装置3に送信する形態がある。例えば、各ユーザの端末装置3に搭載されたウェブブラウザによってゲームがプレイできる、いわゆるブラウザゲームをゲームサーバ1が提供する。あるいは、ゲームサーバ1でゲームを実行した結果のゲーム映像を、例えばストリーミング形式で端末装置3に送信する、いわゆるクラウドゲーミングのサービスをゲームサーバ1が提供する。
あるいは、後述するように、ゲーム実行プログラムの一部または全部をユーザの端末装置3側にインストールし、端末装置3においてもゲーム実行処理が行われるようなゲームシステムとすることもできる。
本実施の形態では、ゲームサーバ1によるゲームサービスの提供の一形態として、ブラウザゲームを提供する例について説明する。このブラウザゲームを提供するサービス形態では、ユーザの端末装置3にゲーム専用のソフトウェアをダウンロード又はインストールする必要がなく、端末装置3をネットワーク4に接続できる環境であれば、ユーザはどこでも気軽にゲームサーバ1から提供されるゲームサービスを楽しむことができる。
このゲームシステムでは、ゲームサーバ1が、各ユーザの端末装置3における入力操作に応じてゲーム進行のための演算処理やデータ処理を実行する。そして、ゲームサーバ1は、演算処理等の実行結果に基づいてデータベースサーバ2内の各ユーザのゲーム情報を更新するとともに、当該実行結果をユーザの端末装置3の画面に表示させるためのウェブページ情報(ゲーム画面データ)を各ユーザの端末装置3に送信する。
各ユーザの端末装置3には、ユーザーエージェントとしてウェブサイト閲覧機能を有するウェブブラウザが搭載されており、ゲームサーバ1から送信されたウェブページ情報を端末装置3の画面に表示することができるようになっている。この端末装置3としては、例えば、携帯電話端末、PHS(Personal Handy-phone System)端末、携帯情報端末(PDA:Personal Digital Assistant)、携帯電話と携帯情報端末とを融合させた携帯端末であるスマートフォン、パーソナルコンピュータ(以下「PC」と呼称する)、タブレット型コンピュータ、通信機能を有するゲーム装置(据置型または携帯型のゲーム装置)または双方向の通信機能を備えた多機能型テレビジョン受像機(いわゆるスマートテレビ)など、ネットワーク4経由でゲームサーバ1に接続してゲームサービスの提供を受けることができる様々な端末が適用できる。
また、本実施の形態で提供されるゲームは、ユーザが、ゲームサービスを受けている他のユーザと交流を行いながらプレイすることができる、いわゆるソーシャルゲームの要素を有するものとすることができる。例えば、本実施の形態のゲームサーバ1およびデータベースサーバ2をソーシャルネットワーキングサービス(SNS)のシステムに組み込むことによって、SNSのサービスの一つとしてソーシャルゲームサービスを提供するゲームシステムとすることができる。このようにSNSのプラットフォーム上で動作するゲームシステムによりゲームサービスをユーザに提供することもできるが、ゲームサーバ1およびデータベースサーバ2をSNSのシステムに組み込まずに、独立したゲームシステムとして構築してもよい。
本実施の形態のゲーム管理装置は、第1ゲーム(例えば予想ゲーム)を実行するための権利(アイテム、ポイント等)を、他の第2ゲーム(例えばパズルゲーム)によって獲得するゲームを管理する。そして、本ゲーム管理装置は、ユーザが獲得した前記権利の使用に制限を設ける(例えば使用期限を設ける)一方で、ユーザが自らの意思で、権利数を低減させる(又は対価を支払う)ための入力を行えば、権利の制限を解除(又は緩和)する。これにより、ユーザは制限された権利について、その制限を解除(または緩和)するかしないかを考えながら遊戯することにより、遊戯のバリエーションが増える。以下に、これを実現する本実施の形態に係るゲーム管理装置(ゲームサーバ1等)の構成の詳細を説明する。
〔ゲーム管理装置の構成〕
上述のように本実施の形態では、ゲーム管理装置は、ゲームサーバ1およびデータベースサーバ2から構成される。図2にゲームサーバ1のハード構成の一例を示している。同図に示すように、ゲームサーバ1は、主に、CPU(Central Processing Unit)11と、主記憶装置としてのROM(Read Only Memory)12及びRAM(Random Access Memory)13と、補助記憶装置14と、通信制御部15と、入出力制御部16とを備えており、これらはアドレスバス、データバス及びコントロールバス等を含むバスライン17を介して相互に接続されている。なお、バスライン17と各構成要素との間には必要に応じてインタフェース回路が介在しているが、ここではインタフェース回路の図示を省略している。
CPU11は、システムソフトウェアやゲームプログラム等のアプリケーションソフトウェアの命令を解釈して実行し、ゲームサーバ1全体の制御を行う。ROM12は、ゲームサーバ1の基本的な動作制御に必要なプログラム等を記憶している。RAM13は、各種プログラム及びデータを記憶し、CPU11に対する作業領域を確保する。
補助記憶装置14は、ゲームプログラム等のアプリケーションソフトウェアや各種データ等を格納する記憶装置である。補助記憶装置14としては、例えばハードディスクドライブなどを用いることができる。ゲームサーバ1(コンピュータ)をゲーム管理装置として動作させるための本実施の形態のプログラムも、この補助記憶装置14に記憶されており、当該プログラムはゲームサーバ1の起動時に補助記憶装置14からバスライン17を介してRAM13へとロードされ、当該CPU11によって実行される。
通信制御部15は、ネットワーク4と接続される通信インタフェース15aを備え、ネットワーク4を介した各ユーザの端末装置3との間の通信を制御する。また、通信制御部15は、ネットワーク4に接続されている図示しないサーバとの通信も制御するようになっている。例えば、ゲームサーバ1をSNSに組み込んだシステム構成とした場合、ゲームサーバ1の通信制御部15は、SNSサーバとの間の通信を制御する。
入出力制御部16は、データベースサーバ2と通信可能に接続されており、CPU11がデータベースサーバ2に対してデータ(レコード)の読み書きを実行するときの入出力制御を行うデータベースインタフェースである。
データベースサーバ2は、ゲームサーバ1が管理する各ユーザのゲーム情報を記憶する領域を有する記憶装置として、例えばRAID(Redundant Arrays of Inexpensive Disks)構成の大容量ハードディスク装置を具備する。このデータベースサーバ2は、例えば、各ユーザを一意に識別する識別情報(ユーザID)と対応付けて、各ユーザの各種ゲーム情報(ユーザ名、レベル、ゲーム内ポイント、所持アイテムなど)を記憶するリレーショナルデータベース、オブジェクトデータベース又はオブジェクト関係データベース等として構築することができる。
本実施の形態では、ゲーム管理装置がゲームサーバ1およびデータベースサーバ2から構成される例を示すが、これに限定されるものではない。例えば、ゲームサーバ1にデータベースサーバ2の機能を持たせて、ゲーム管理装置をゲームサーバ1のみで構成することもできる。また、ゲームサーバ1の有する各機能を複数のサーバに分散して持たせて、ゲームサーバ1を複数台のサーバとして構成することもできる。例えば、ユーザが端末装置3を操作してゲームサーバ1へアクセスした場合に、当該ユーザが正規のユーザかどうかを判別する認証機能を有する認証サーバを、ゲームサーバ1のメインサーバとは別に設け、メインサーバと認証サーバとでゲームサーバ1を構成してもよい。他の構成例としては、ユーザが課金対象のアイテムをゲーム内で購入した場合に課金管理を行う課金管理サーバを、ゲームサーバ1のメインサーバ等とは別に設け、メインサーバ、認証サーバおよび課金管理サーバによりゲームサーバ1を構成してもよい。
また、本ゲームサービスを利用するユーザ数が数十万人、数百万人、あるいはそれ以上となると、多数のユーザの端末装置3からの巨大なアクセスにも耐え得るサーバシステムの構築が求められるため、ネットワーク4上に複数のゲームサーバ1を設けて冗長化(多重化)を図ることにより、負荷分散型のシステム構成としてもよい。この場合、複数のゲームサーバ1間の負荷を調整するためのロードバランサを設けることが望ましい。
次に、本実施の形態に係るゲームサーバ1にアクセスしてゲームサービスの提供を受けるユーザの端末装置3の構成を説明する。
〔端末装置の構成〕
ユーザが操作する端末装置3としては、上述のように携帯電話端末やスマートフォンをはじめとして、ウェブサイト閲覧機能を有する様々な端末を適用できるが、本実施の形態では、携帯端末を例示してその構成を説明する。なお、携帯端末以外の端末装置3についても、ウェブサイト閲覧機能を用いてゲーム画面を表示したり、ゲームを実行するための入力操作を行うといった、ゲームをプレイする上で必要となる基本的な構成は、携帯端末と同様である。
ウェブサイト閲覧機能等を有する携帯端末は、フィーチャーフォン(Feature phone)やスマートフォン(Smartphone)等とも呼称され、図3にその構成例を示している。同図に示すように、端末装置3は、主に、CPU31と、主記憶装置としてのROM32及びRAM33と、画像処理部34と、表示部35と、サウンド処理部36と、音声入力部37と、音声出力部38と、補助記憶装置39と、操作入力部40と、通信制御部41とを備えており、構成要素31〜34、36および39〜41はバスライン42を介して相互に接続されている。なお、バスライン42と各構成要素との間には必要に応じてインタフェース回路が介在しているが、ここではインタフェース回路の図示を省略している。
CPU31は、ウェブブラウザを含む各種プログラムの命令を解釈して実行し、端末装置3全体の制御を行う。ROM32には、端末装置3の基本的な動作制御に必要なプログラム等が記憶されている。また、RAM33には、ROM32または補助記憶装置39からロードされた各種プログラムやデータが記憶され、CPU31に対する作業領域を確保する。HTML等で記述されたゲーム画面データを表示するウェブブラウザは、ROM32または補助記憶装置39に記憶されており、RAM33にロードされてCPU31によって実行される。また、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインソフトウェアを、ウェブブラウザと共にROM32または補助記憶装置39に記憶していてもよい。
画像処理部34は、CPU31からの画像表示命令に基づいて表示部35を駆動し、当該表示部35の画面に画像を表示させる。表示部35には、液晶ディスプレイまたは有機LE(Electro-Luminescence)ディスプレイ等の既知の種々の表示装置が適用できる。
サウンド処理部36は、音声入力部37から音声が入力されたときにアナログ音声信号をデジタル音声信号に変換するとともに、CPU31からの発音指示に基づいてアナログ音声信号を生成して音声出力部38に出力する。音声入力部37は、端末装置3に内蔵されたマイクロフォンからなり、電話通信する場合や録音を行う場合などに用いられる。音声出力部38は、電話通信時の受話スピーカおよび電話着信音やゲーム実行時の効果音などを出力するスピーカからなる。
補助記憶装置39は、各種プログラムやデータ等を格納する記憶装置である。補助記憶装置39としては、携帯電話端末の内部メモリとして、例えばフラッシュメモリドライブ等を用いることができ、また、携帯電話端末の外部メモリとして、例えばメモリカードリーダライタ等を用いることができる。
操作入力部40は、ユーザの操作入力を受け入れて当該操作入力に対応した入力信号を、バスライン42を介してCPU31に出力するものである。操作入力部40の例としては、端末装置3の本体に設けられた方向指示ボタン、決定ボタン、英数文字等入力ボタンなどの物理的ボタンがある。また、表示部35の画面にタッチパネル(接触入力式のインタフェース)を搭載することによって表示部35をいわゆるタッチスクリーンとして構成している端末装置3の場合、当該タッチパネルも操作入力部40となる。
また、一般的な音声認識技術を利用して、音声入力部37から入力された音声をCPU31が解析し、各種入力を、音声により行うことができる構成としてもよい。
通信制御部41は、通信インタフェース41aを備え、ゲーム操作時等にデータ通信するための通信制御機能および携帯電話端末として音声データを送受信するための通信制御機能等を有している。ここで、データ通信用の通信制御機能には、例えば、無線LAN接続機能、無線LANや携帯電話回線網を介したインターネット接続機能、所定の周波数帯(例えば2.4GHzの周波数帯)を用いた近距離無線通信機能などが含まれる。通信制御部41は、CPU31からの命令に基づいて端末装置3を無線LANやインターネット等に接続するための接続信号を発信するとともに、通信相手側から送信されてきた情報を受信してCPU31へ供給する。
なお、端末装置3には、その他にもGPS(Global Positioning System)信号受信回路、CCD(Charge Coupled Device)イメージセンサ等の撮像装置(カメラ)、3軸加速度センサなどが備えられていてもよく、例えば、GPS位置情報などをゲーム内で活用してもよい。
上記構成の端末装置3において、ゲームサービスを受けようとするユーザは、ウェブブラウザを立ち上げてゲームサーバ1が管理するゲームサイトにアクセスする入力操作を行う。このアクセスがゲームサーバ1に認証された場合、端末装置3の通信制御部41がゲームサーバ1から送信されてくるHTML等で記述されたゲーム画面データを受信し、CPU31がウェブブラウザを実行してゲーム画面を表示部35に表示させる。ここでユーザは、ゲーム画面に表示されている選択可能なボタンオブジェクトやハイパーリンクを、操作入力部40を操作して選択入力する。この選択入力に応じてゲームサーバ1がゲームを進行させ、新たなゲーム画面データを端末装置3に送信する。そして、この新たなゲーム画面が端末装置3の表示部35に表示され、以下、同様に、ユーザは、表示部35に表示されているゲーム画面で選択可能なボタンオブジェクト等を選択する操作により、ゲームサーバ1が提供するゲームをプレイすることができるようになっている。
〔ゲームの説明〕
ゲーム管理装置によって提供されるゲームの例としては、サッカー、野球、テニス、アメリカンフットボール、バスケットボール、バレーボール、ゴルフ、ボクシング、競馬、カーレースなどを題材としたスポーツ・レースゲーム、シミュレーションゲーム、育成ゲーム、ロールプレイングゲーム、さらにはクイズゲームといったように、ゲーム形式・ジャンルを問わず様々なゲームを挙げることができる。その一例として、本実施の形態では、主に、ゲーム管理装置が野球ゲームを管理する例について、以下に説明する。
本実施の形態では、ゲーム内で、現実世界のプロ野球(またはMLB)の実在選手に対応する選手キャラクタが用いられる野球ゲームを例に挙げる。ゲーム内の選手キャラクタは、当該選手キャラクタの形態を端末装置3の画面上で視認可能としたカード形式とすることができる。すなわち、選手キャラクタは、デジタル選手カードとしてゲームサーバ1で管理されるとともに、ユーザの端末装置3の画面に表示される。また、選手キャラクタは、ゲーム内での試合等において、3次元コンピュータグラフィックスにより描写してもよい。また、ストリーミング形式等により、選手キャラクタやボールオブジェクト等を動画表示してもよい。
図4に、本ゲームのメイン画面(ホーム画面、マイページ画面とも称される)の一例を示す。このメイン画面には、ユーザのゲーム情報201として、ユーザの画像(アバター、写真等)、所有ポイント、所有アイテム、仲間人数などが表示される。また、メイン画面には、各種モードを選択するためのボタン群202等が表示される。また、端末装置3の方向キーやタッチパネル等を操作して画面をスクロールさせることによって、表示されていないシステム運営者からのお知らせ等の、様々な情報が表示される。
本実施の形態のゲームでは、現実世界の野球のシーズン中においては、現実の試合で活躍する実在選手を予想して、その結果(スコア)を他のユーザと競う予想ゲームを主に楽しむことができる。また、現実世界の野球のオフシーズンにおいては、毎日、ユーザ同士で戦うトーナメントが開催され、対戦ゲームを主に楽しむことができる。
先ず、野球シーズン中のゲームについて説明する。ゲーム内には、複数のゲームモードが存在し、その中の1つが予想ゲーム(第1ゲーム)である。この予想ゲームを遊戯するためには、「ホープ」と称される権利アイテムが必要であり、当該権利アイテムを獲得することができるゲームモードとして、パズルゲーム(第2ゲーム)も存在する。ユーザは、パズルゲームを遊戯して「ホープ」を獲得し、その「ホープ」を使用して予想ゲームを遊戯することになる。
本実施の形態のパズルゲームは、1分間の制限時間内に獲得した得点に応じて、「ホープ」を獲得できる。パズルゲームの画面の一例を、図5に示す。画面には、遊戯の残り時間の表示領域205、スコアゲージ206、パズル用のアイコン表示領域207が設けられている。ゲームの開始と同時に、アイコン表示領域207には複数種類のアイコンがマトリクス状に並べられた状態で登場する。ユーザは指またはペンで画面上のアイコンを押さえて、上下左右の何れかの方向に一コマずつアイコンを移動(ドラッグ操作)させる。このアイコンの移動操作により、移動させたアイコンと、移動先にあったアイコンとが入れ替わる。アイコンには、顔の形をした「おおだま」アイコン208と、ボールの形をした「こだま」アイコン209とがある。図5の例では、顔の形の異なる4種類の「おおだま」アイコン208が存在する。そして、同じ形状の「おおだま」アイコン208が、縦、横、L字状に3つ以上繋がると、繋がった「おおだま」アイコン208を消すことができ、得点が向上する。また、「こだま」アイコン209は、隣で「おおだま」アイコン208が消えると、自動的に「おおだま」アイコン208に変化する。さらに、消えたアイコンの位置には、自動的に「おおだま」又は「こだま」のアイコンが補充される。このような「こだま」から「おおだま」への変化、および消えた位置へのアイコンの補充により、ユーザがアイコンの移動操作をしなくても、同じ形状の「おおだま」アイコン208が3つ以上繋がり、連鎖的にアイコンが消去されることがある。
上記のパズルゲームにおいて、「おおだま」アイコン208を1つ消去する毎に所定の得点(たとえ100点)を獲得できる。「おおだま」アイコン208の種類により獲得できる得点を変えてもよい。1分間のゲーム終了時に、ユーザが獲得した得点10000点につき1つの「ホープ」が、ユーザに付与される。例えば、ユーザがパズルゲームで25000点を獲得した場合、2つの「ホープ」を獲得できる。
このパズルゲームは、1プレイ1分で手軽に遊戯できるので、1日に複数回の遊戯が可能である。但し、パズルゲームを遊戯するためには、「行動力」というポイントを必要とする。例えば、パズルゲームを1回遊戯することにより、「行動力」を1ポイント消費する。この行動力は、ユーザが所有しているポイントであり、ゲーム中に消費されて減った行動力は、時間の経過により回復(例えば、8分経過毎に1ポイントずつ回復)する。また、ユーザのレベルアップ時または回復アイテムの使用により、消費されて減った行動力が一気に回復するようにしてもよい。ユーザが所有できる行動力の最大値は、ユーザのゲームのレベルが向上する毎に増えて行く。ユーザのレベルは、ゲーム経験の豊富さ、ゲームの習熟度の高さの指標となるものである。本実施の形態では、ユーザが所定のゲームモードを遊戯する(例えば、パズルゲームを遊戯する)ことにより経験値が蓄積され、当該経験値が一定量に達することによりレベルアップするようになっている。
ユーザが獲得した「ホープ」には、原則、その使用に制限が設けられている。本実施の形態では、「ホープ」には、その獲得後、最初に来る締切期限の予想ゲームでのみ使用できるという制限が付けられる。すなわち、「ホープ」は、原則、現実世界の直近の野球の試合を対象とした予想ゲームにのみ使用できるのである。使用期限を過ぎた「ホープ」は消滅してしまうので、ユーザは、使用期限内に「ホープ」を使い切ることが必要である。但し、ユーザは、自らの意思で、2つの「ホープ」を合体させるための入力操作を行うことにより、合体後の「ホープ」の使用制限を解除できる。この合体により、ユーザの手持ちの「ホープ」の数は減少するが、合体後の「ホープ」については、いつでも使用できるようになる。
次に、パズルゲームで獲得した「ホープ」を使用して遊戯する予想ゲームについて説明する。予想ゲームの画面の一例を、図6に示す。画面には、ユーザが現在所有している「ホープ」の数が表示される。上述のように、「ホープ」には使用期限付きのものと、合体により使用期限のないものとがある。よって、画面には、使用期限付きの「ホープ」の数を表示する領域211と、使用期限のない「ホープ」の数を表示する領域212とが設けられている。
また、予想ゲームの画面には、予想の締切期限までの残り時間を表示する領域213が設けられている。予想の締切期限は、現実世界の野球の試合開始時間としてもよいし、試合開始の所定時間前(例えば1時間前)としてもよい。
また、予想ゲームの画面には、予想可能な実在選手(選手のカード)を所定数(例えば15人)表示する領域214が設けられている。なお、画面に表示しきれない実在選手については、画面をスクロールすることにより表示される。各ユーザは、この領域214に表示される実在選手の中から、応援する(現実世界で活躍すると予想する)実在選手を選択することができる。予想可能な実在選手は、ゲーム内の全てのユーザに共通である。
上記領域214に表示される、予想可能な実在選手は、ゲームサーバ1によって予め選択される。例えば、ゲームサーバ1には、現実の試合に出場する可能性の高い実在選手(一軍登録されているレギュラー選手等)が予め登録されており、その中から、毎日、所定数の実在選手がゲームサーバ1によって抽出され、予想ゲームの画面に表示される。このゲームでは、数百人にものぼる実在選手の中から、予想可能な対象選手が所定数に絞られているので、野球に詳しくないユーザであっても、それほど予想に困ることがない。
なお、図5に示すパズルゲームにおいて、スコアゲージ206のゲージ表示が右端に到達すれば(例えば、得点が30000点に到達すれば)、予想可能な対象選手が1人追加されるようにしてもよい。
また、領域214に表示される実在選手には、期待度を示すマーク215も表示される。この期待度は、例えば、直近の所定期間(例えば1週間)の現実世界の成績(打率、防御率等)に基づいて決定される。マーク215の数が多い実在選手ほど、期待度も大きい。この期待度の情報により、野球に詳しくないユーザの予想もさらに容易となる。
本実施の形態の予想ゲームでは、各チームの4番打者やエース投手などの人気選手を応援(活躍予想)するには、その他の選手よりも多くの「ホープ」が必要である。上記領域214に表示される各実在選手には、活躍を予想するために最低必要な「ホープ」の数の情報216が表示されている。
予想ゲームの画面で、ユーザが現実世界で活躍すると予想する実在選手を選択(クリック等)すれば、その実在選手の予想に最低必要な数の「ホープ」が設定される。さらに、ユーザは、最低必要な数の「ホープ」よりも多い数の「ホープ」を、追加で設定することもできる。このように設定する「ホープ」の数により、予想の重み付けをすることもできる。なお、ユーザが特に指定せずとも、使用期限付きの「ホープ」が、使用期限のない「ホープ」よりも優先的に使用される。また、ユーザは、複数の実在選手に「ホープ」を設定して予想することができる。なお、各ユーザが予想可能な選手枠には、上限を設けてもよい(例えば最大5人まで予想可能)。
その後、予想の対象となる現実世界の試合中または試合の終了後に、前記領域214に表示されていた実在選手のその試合での実績がゲームサーバ1に入力される。そして、ゲームサーバ1は、入力された各実在選手の実績に基づいて、活躍度を算出する。例えば、単打が100、二塁打が200、三塁打が300、本塁打が400、1打点につき100、盗塁が100、奪三振が50、無失点/イニングが50等の評価ポイントに基づいて、各実在選手の活躍度を算出する。そして、ゲームサーバ1は、実在選手の活躍度に、ユーザが設定した「ホープ」の数を掛け合わせて、予想的中スコアを算出する。ユーザが複数の実在選手に「ホープ」を設定していた場合、ゲームサーバ1は、当該複数の実在選手の予想的中スコアを合計して、当該ユーザの予想的中スコアを求める。
ゲームサーバ1は、ゲーム内の全ユーザの予想的中スコアを算出した後、各ユーザのランキングを求める。そして、ランキング上位のユーザ(例えば100位以内のユーザ)には、アイテムや予想可能な選手枠の拡大などの報酬が付与される。
この予想ゲームは、シーズン中、現実世界で試合のある日は毎日開催される。ゲームサーバ1は、ある日の試合が終了して上記のようにランキングを出した後、翌日の試合の予想を受け付けるため、予想可能な所定数の実在選手を抽出する。翌日の試合の予想の受け付け期間は、例えば翌日の午前0時から予想の締切期限(例えば17時)までに設定される。このように、予想ゲームは、試合前にユーザの予想を受け付け、試合後に予想結果が出る1日に1回の遊戯サイクルである。
次に、現実世界の野球のオフシーズン中のゲームについて説明する。ゲーム内の各選手カードには、それらを一意に識別するための選手IDが付けられている。そして、図7に例示するように、データベースサーバ2には、選手IDと対応付けられて、選手名、背番号、ポジション、所属チーム、能力値、レア度、画像データなどが記憶された選手データベース(選手DB)が存在する。
オフシーズン中は、毎日、所定時間(例えば午前0時)になれば、各ユーザに、所定数の選手カードが付与される。本実施の形態では15枚の選手カードが各ユーザに付与されるものとする。なお、シーズン中とは異なり、毎日、ユーザ毎に違った選手カードが配られる。例えば、ゲームサーバ1は、ユーザ毎に、ランダムに15枚の選手カードを選択してユーザに付与する。あるいは、次のようにユーザに付与する選手カードを決定してもよい。各ユーザは、ゲームを初めて実行した際に、現実世界の複数のプロ野球チームのうちの希望する何れか1つのチームをお気に入りチームとして登録する。そこで、ゲームサーバ1は、ユーザのお気に入りチームの選手カードを、他のチームの選手カードよりも高い確率で選択し、ユーザ毎に15枚の選手カードを決定する。
ゲームサーバ1から各ユーザに付与された15枚の選手カードは、ユーザのチームのオーダーを構成するカードである。オフシーズン中は、毎日、所定時間(例えば22時)になれば、各ユーザのチームが自動的に対戦するトーナメント戦が開催される。各ユーザは、トーナメント戦の開始までに、以下に示すように、自分のチームの選手カードを「ホープ」で強化したり、チームを構成する選手カードを入れ替えたりして、チームを強化できる。
オフシーズン中も、ユーザは、図5に示すパズルゲームを遊戯することにより、「ホープ」を獲得することができる。ユーザは、獲得した「ホープ」を自分のチームの選手カードに設定することにより、当該カードの選手能力を向上させることができる。また、「ホープ」は、後述するように、ユーザの仲間等が放出した選手カードを入手するときにも使用できる。前述と同様、オフシーズン中にユーザが獲得した「ホープ」にも、例えば24時間の使用期限が設けられ、2つの「ホープ」を合体することにより、使用期限を解除できるようにしてもよい。
本実施の形態のゲームで対戦に勝利するためには、ユーザのチーム内の選手カードの能力の高さも重要であるが、それだけではなく、チーム内の複数の選手カードの組合せも重要となる。それは、対戦において、ユーザが所有する15枚の選手カード(ユーザのチームを構成する選手カード)の中に、所定のカードの組合せが存在すれば、対戦実行時に特殊効果が発生し、戦力が向上するからである。例えば、ユーザが、同一チームの選手カードを7枚以上所有している場合、「良好なチームワーク」という特殊効果が発生し、ユーザのチームの戦力が向上する。また、同一チームの3番打者、4番打者、5番打者の選手カードをオーダーに含めている場合に「息の合ったクリーンアップ」という特殊効果が発生し、当該3枚の選手カードの打撃能力が向上する。その他にも特殊効果を発生させる選手カードの組合せは複数存在する。
そこで、ユーザは、トーナメント戦が開始されるまでに、以下に示す方法により選手カードを入手し、自分のチームを構成する選手カードを入れ替えることにより、戦力アップを図ることができる。
オフシーズン中のパズルゲームにおいて、図5に示すスコアゲージ206のゲージ表示が右端に到達すれば(例えば、得点が30000点に到達すれば)、ユーザは、選手カードを1枚獲得できる。このパズルゲームで獲得できる選手カードは、例えば、ゲームサーバ1がゲーム内の全ての選手カードの中からランダムに選択した選手カードである。パズルゲーム(または後述する「場」)で選手カードを獲得した後のゲームの流れを、図8に示す。基本的に、ユーザのチームは15枚の選手カードで構成されるので、1枚カードを獲得すれば、それと入れ替えに、現在の手持ちの選手カードの中から何れか1枚のカードを放出しなければならない。なお、入手した選手カードを、自分のチームに加えたくなければ、入手した選手カードを直ぐに放出することもできる。
ユーザが放出する選手カードを1枚選択すれば、その選手カードは非保有状態となり、一旦、貯留領域に貯留される。以下、この貯留領域を「場」と呼称する。このように、各ユーザは、パズルゲームで選手カードを獲得しては、獲得した枚数分のカードを、現在の手持ちの選手カードの中から放出することを繰り返し、自分のチームをより強いチームに作り上げる。また、場には、各ユーザによって放出された選手カード(放出オブジェクト)が貯留される。
ユーザは、「場」に貯留されている選手カードを、いつでも確認することができる。そして、ユーザは、「場」の中の任意の選手カードを、所定の対価(本実施の形態では「ホープ」)と引き換えに入手できる。なお、「場」の中の選手カードを入手する場合、毎日1枚だけ対価不要で入手できるが、2枚目以降は対価が必要としてもよい。
ユーザが自分の端末装置3で「場」を確認するための入力操作を行えば、ゲームサーバ1から、例えば図9に示す「場」の確認画面が送信されてくる。この画面内には、「場」に貯留されている複数の選手カードを表示する選手カード表示領域221が設けられる。図9では、選手カード表示領域221に15枚の選手カードが表示されているが、「場」にそれ以上の選手カードが貯留されている場合、画面をスクロールする、または2頁目以降の画面を表示させることにより、表示されていない選手カードも確認できる。
本ゲームでは、ユーザが特殊効果を発生させる組合せを完成させるためには、残り1つだけ選手カードが不足しており、その選手カードが、ユーザが確認している「場」の中にあれば、その旨がユーザに報知される。すなわち、ユーザが入手可能な、「場」に貯留されている選手カードの中に、ユーザがすでに所有している選手カードと組み合わせることで特殊効果を発生させる補完カード(補完オブジェクト)が含まれている場合、その旨がユーザに報知される。
図9では、画面内に報知情報表示領域220が設けられ、架空のキャラクタが、補完カードを報知する例を示している。例えば、報知情報表示領域220には、ユーザが既に所有しているカード222と補完カード223とが表示されると共に、「この補完カードを入手すれば、既に所有しているカードと組み合わせて、「息の合ったクリーンアップ」のコンボが完成します!」というメッセージ224が表示される。なお、本ゲームでは、特殊効果を発生させるカードの組合せを「コンボ」と呼ぶ。ここで、ユーザが補完カード223を選択すれば、対価としての「ホープ」と引き換えに、補完カード223を入手できる。これにより、ユーザは、どの選手カードの組合わせが特殊効果を発生させるかについての知識がなくとも、容易に特殊効果を発生させる組合せを完成できる。
一方、「場」に貯留されている選手カードの中に、補完カードが存在しなければ、上記のメッセージ224等は画面に表示されない。
なお、ゲーム内の全てのユーザに共通の「場」をゲーム内に1つ設けても良いが、ユーザ数が多い場合、各ユーザが放出した選手カードが膨大な数となってしまう可能性がある。そこで、ゲーム内のユーザを1グループ数十人程度の複数のグループに分割し、グループ毎に「場」を設けてもよい。
あるいは、「場」は、ユーザに関係付けられた仲間(第2のユーザ)によって放出された選手カードを貯留することとし、ユーザ毎に「場」を設けてもよい。この場合、ユーザの仲間が放出した選手カードを、ユーザが対価を支払って入手することができるようになる。あるいは、「場」には、ユーザに関係付けられた仲間と、ユーザに関係付けられていない所定人数(例えば20人)の他のユーザとによって放出された選手カードを貯留することとしてもよい。
ゲームサーバ1は、毎日、所定時間(例えば22時)になれば、その時点でユーザが所有している選手カードによってユーザのチーム構成を確定し、自動的に対戦相手を決定して、トーナメント戦を実行する。その後、ゲームサーバ1は、トーナメント戦の結果が出れば、その結果を各ユーザに報知し、優勝者または所定順位以内に入ったユーザには、報酬としてアイテム等を付与する。
毎日、トーナメント戦の結果が出れば、各ユーザが所有している15枚の選手カードは破棄され、各ユーザのチーム構成が一旦リセットされる。そして、翌日の午前0時になれば、ユーザ毎に、新たに15枚の選手カードを決定し、各ユーザに付与する。オフシーズン中は、毎日これを繰り返す。
〔ゲーム管理装置の機能的構成および動作〕
次に、上記のゲームを実現するゲーム管理装置の機能的構成の一例について説明する。図10は、端末装置3と通信するゲーム管理装置(ゲームサーバ1およびデータベースサーバ2)の基本的な構成を示す機能ブロック図である。
本実施の形態に係るゲーム管理装置は、ユーザ情報記憶制御手段60、受信手段61、実行手段62、画面生成手段63、送信手段64、アクセス管理手段65および交流制御手段66等を備えている。これらの各手段は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。
ユーザ情報記憶制御手段60は、各ユーザのゲームに関する情報をデータベースサーバ2に記憶して管理する。ユーザ情報記憶制御手段60がデータベースサーバ2に記憶している、ユーザのゲームに関する情報であるユーザ情報データベースの一例(この例ではユーザID=000001の1人分の情報)を、図11に示す。
ユーザ情報記憶制御手段60は、ユーザIDと対応付けて、ユーザの基本情報、希望チーム、レベル情報、保有カード、保有ポイント、保有アイテム、仲間情報、アクセスログ、交流履歴等を、データベースサーバ2の所定の記憶領域に記憶する。
ユーザの基本情報としては、ログインID、パスワード、ユーザ名(ゲーム内で使用するニックネーム等)等がある。ここで、ログインIDおよびパスワードは、各ユーザが端末装置3を操作してゲームサーバ1にアクセスしたときのログイン認証に用いられる。ユーザ名は、ゲーム内で使用するニックネーム等である。希望チームは、ユーザがゲームサービスを受けるための利用登録をした際や、ゲームを初めて実行した際に、ユーザが自ら設定したお気に入りチームの情報である。レベル情報は、前述したユーザのゲームのレベルである。
保有カードの情報とは、オフシーズン中に、ゲーム内でユーザが保有している選手カードの情報(選手ID)である。図7に示すように、データベースサーバ2には選手DBが存在する。よって、ゲームサーバ1は、ユーザ情報記憶制御手段60によって記憶されている選手IDに基づいて、当該選手IDに対応する選手カードに関する各種情報を、選手DBから取得できる。
保有ポイントおよび保有アイテムの情報は、ゲーム内でユーザが保有している各種ポイント(ポイントに準ずる値などを含む)およびアイテムの情報である。本実施の形態では、前述の経験値および行動力が保有ポイントの情報に含まれる。また、アイテムには、前述の「ホープ」および回復アイテムが含まれる。「ホープ」には制限付きのものと、制限が解除されたものがあるので、それらを区別して記憶している。
また、仲間情報とは、ユーザに関係付けられた仲間の情報であり、ユーザIDと対応付けられて仲間のユーザIDがデータベースサーバ2に記憶される。また、アクセスログとは、ユーザの端末装置3がゲームサーバ1へアクセス(ログイン)した日時等の時間情報である。また、交流履歴とは、ユーザが他のユーザ(仲間等)にゲーム内で交流を行った履歴の情報である。この交流履歴には、交流の種類、相手、時間の情報が含まれる。交流の種類としては、挨拶、メッセージ送信、プレゼント、チャットなどがある。交流の相手の情報として、相手のユーザIDが記憶される。
次に、図10に示す受信手段61、実行手段62、画面生成手段63、送信手段64について説明する。受信手段61および送信手段64は、ゲームサーバ1のCPU11および通信制御部15により実現される機能である。
ユーザの端末装置3のウェブブラウザによってゲーム画面が表示されているとき、ユーザがゲーム画面上の選択可能なボタンオブジェクトやハイパーリンクが設定された文字列等を選択する入力の操作を行った場合、当該入力に関する情報(ゲーム画面のリクエスト等)が端末装置3のウェブブラウザによってゲームサーバ1へ送信される。ゲームサーバ1では、前記入力に関する情報を受信手段61が受信したとき、実行手段62が、当該情報に応じてユーザのゲームに関する情報を読み出して演算やデータ処理を実行する。
また、実行手段62は、オフシーズンのトーナメント戦では、毎日、所定時間になれば、対戦のマッチング処理を実行すると共に、自動的に対戦処理を実行する。対戦処理では、対戦を行う両ユーザのユーザIDに対応した両チームの選手カードの情報をデータベースサーバ2から読み出す。そして、実行手段62は、AI(Artificial Intelligence)プログラム等により、両チームの選手カードの能力等のパラメータに基づいて、野球の試合のシミュレーションを実行する。このとき、チーム内の複数の選手カードが特殊効果を発生させる組合せを構成している場合、当該特殊効果を発動させる。
次に、画面生成手段63について説明する。画面生成手段63は、実行手段62による実行結果に応じて、例えばHTMLデータからなるゲーム画面データを生成する。HTMLデータには、データベースサーバ2から読み出された選手カード等の画像データを含めてもよい。また、HTMLデータには、端末装置3のウェブブラウザのプラグインによって動作するスクリプト(プログラム)が埋め込まれていてもよい。ゲームサーバ1から提供されたスクリプトが端末装置3で実行される場合は、端末装置3で表示されるゲーム画面を動画とすることも可能である。あるいは、画面生成手段63は、ストリーミング形式の映像を生成してもよい。
また、送信手段64は、画面生成手段63により生成された画面データ(HTMLデータ、ストリーミング形式の映像データ等)を、ゲーム画面のリクエストに対するレスポンスとして、または実行手段62による実行結果として、ユーザの端末装置3へ送信する。このゲーム画面データを受信したユーザの端末装置3では、ウェブブラウザおよびそのプラグイン等によって表示部35にゲーム画面が表示される。
次に、アクセス管理手段65について説明する。アクセス管理手段65は、ゲームサービスを受けようとするユーザが端末装置3を操作してゲームサーバ1にアクセス(ログイン)しようとした際、当該ユーザのゲーム参加資格の有無を判断してログイン認証を行う。この認証の例としては、ユーザIDと対応付けられたログインIDおよびパスワードに基づく認証がある。また、ユーザがゲームサーバ1にアクセスする度にログインIDおよびパスワードを入力する手間を省略できるように、端末装置3である携帯電話やスマートフォンの個体識別番号(電話番号とは別の端末を一意に識別するための情報)、または契約者固有ID(端末の契約者を一意に識別するための情報であって、機種変更を行っても契約者が同一である限りは変更されないID)を利用した認証を行ってもよい。
次に、交流制御手段66について説明する。交流制御手段66は、ゲーム内で行われるユーザ同士の交流やコミュニケーションを実現するものである。交流制御手段66は、ユーザの端末装置3から、他のユーザ(特に、仲間)に対して所定の交流を行う情報を受信し、受信した情報に基づいて、当該ユーザから当該他のユーザに対しての交流処理を実行する実行手段62を制御する。交流処理には、例えば、挨拶、メッセージの伝達、プレゼント、チャットなどがある。
次に、図12の機能ブロック図等を参照して、第1ゲームを実行するための権利を、他の第2ゲームによって獲得するゲームを管理するゲーム管理装置(ゲームサーバ1およびデータベースサーバ2)の主要な機能的構成について説明する。本実施の形態で例示する第1ゲームは、現実世界のシーズン中の野球の試合で活躍する選手を予想する、前述の予想ゲームである。また、第2ゲームは、前述のパズルゲームである。
前述のように、シーズン中は、毎日(但し、現実世界の野球の試合のない日は除く)、現実世界の野球の試合を対象とした予想ゲームが行われる。ゲームサーバ1には、現実世界の野球の対戦カード、試合開始時間等の情報が、キーボード等の入力装置から直接、またはネットワーク経由で入力される。この入力に基づいて、ゲームサーバ1は、記憶装置(データベースサーバ2)に、図14に例示する予想ゲーム管理情報を記憶する。毎日行われる予想ゲームには、各日のゲームを一意に識別するための予想ゲームIDが付される。そして、予想ゲームIDに関係付けて、予想受付開始時間、予想締切時間、現実世界の対戦カード(および試合開始時間)、予想可能選手の選手ID等の情報が記憶される。
ある日の野球の対戦カードおよび試合開始時間の情報がゲームサーバ1に入力された場合、ゲームサーバ1は、例えば、その日行われる試合の中から最も早い試合開始時間の1時間前を、予想締切時間に設定する。また、ゲームサーバ1は、予想受付開始時間を、例えばその日の午前0時に設定する。なお、予想受付開始時間はこれに限定されものではまく、例えばある日の予想ゲームの予想の締切期限が経過した直後から、翌日の(次の)予想ゲームの予想の受付を開始してもよい。
また、ゲームサーバ1は、その日試合が行われるチームに所属する選手の中から、所定数(例えば15人)の実在選手を、予想可能選手として抽出する。前述のように、ゲームサーバ1には、現実の試合に出場する可能性の高い各チームの実在選手(一軍登録されているレギュラー選手)が予め登録されており、その中から例えばランダムに予想可能選手が抽出される。なお、図7に例示する選手データベースは、実在選手に対応した選手カードのデータベースであり、ゲームサーバ1は、この選手データベースに基づいて、実在選手も選手IDで管理している。よって、ゲームサーバ1は、前述のようにして抽出した予想可能選手の選手IDを、予想ゲームIDに関係付けて管理する。
図12に示すように、ゲーム管理装置としてのゲームサーバ1は、主に、制限手段71および制限変更手段72(制限解除手段)を備えている。これらの各手段は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。
制限手段71は、ユーザが獲得した予想ゲームを実行するための権利(本実施の形態では「ホープ」と称する権利アイテム)の使用に制限を設ける機能を有する。
この制限としては、使用対象、使用回数、使用期間等の制限がある。本実施の形態では、パズルゲームで獲得した「ホープ」は、原則、その獲得後最初に来る締切期限の予想ゲームでのみ使用できるという制限が設けられる。すなわち、権利の使用対象が、その権利の獲得後最初に来る締切期限の予想ゲームに限定されている。且つ、権利の使用回数が1回に制限されている(つまり、予想ゲームに使用した「ホープ」は消滅する)。
例えば、本日の野球の試合(最先の試合開始18時)の予想の締切期限が17時に設定されており、ユーザがその日の17時までに獲得した権利は、本日の野球の試合の予想にしか使用できないという制限が付けられる。また、ユーザが本日の17時30分に「ホープ」を獲得した場合、本日の野球の試合前ではあるが、既に締切期限の17時が過ぎているので、次に締切期限(例えば翌日の17時)を迎える野球の試合の予想にしか使用できないという制限が付けられる。このように、ユーザがパズルゲームで獲得した「ホープ」の使用は、直近の野球の試合(締切期限後は次の試合)を対象とした1回の予想ゲームに限定されている。
ユーザが所有する「ホープ」は、当該ユーザのユーザIDと対応付けてユーザ情報データベースに記憶される。ここで、ユーザがパズルゲームで獲得した直後の「ホープ」は、上記のような制限付きの権利であるため、図11に示すように、ゲームサーバ1によって、「ホープ(制限あり)」として記憶される。すなわち、ユーザがパズルゲームで「ホープ」を獲得する毎に、ユーザIDと対応付けて、「ホープ(制限あり)」の個数が加算される。そして、制限手段71は、この「ホープ(制限あり)」について、上記のように、直近の締切期限の予想ゲームでのみ使用を許可し、その締切期限後は、原則、消滅させる(ユーザが保有する「ホープ(制限あり)」の個数をゼロにする)。
制限変更手段72は、ユーザによる権利数(「ホープ」の保有数)を低減させるための入力に応じて、前記権利の制限を解除する機能を有する。本実施の形態では、ユーザが保有する制限付きの2つの「ホープ」を合体して、その数を1/2に低減させれば、合体後の「ホープ」の使用対象の制限は解除され、いつでも予想ゲームで1回使用できるようになる。
図15に、「ホープ」を合体するための操作画面の一例を示す。この画面には、現在保有している、制限付き及び制限なしの「ホープ」の数を表示する領域311が設けられる。また、画面には、合体する回数を入力するための入力領域313および合体処理を実行するための合体ボタン314が設けられる。図15の画面では、ユーザが制限付きの「ホープ」を12個保有しているので、2つの「ホープ」を1つに合体する処理を最大6回まで実行可能である。ユーザは、例えばプルダウン形式の入力領域313で合体回数を入力し、合体ボタン314を押せば、ユーザの端末装置3からゲームサーバ1に、その入力情報が送信される。この入力情報を受信したゲームサーバ1では、合体処理を実行する。例えば、合体回数3回の合体の場合、ゲームサーバ1は、ユーザ情報データベースにおいて、前記ユーザのユーザIDと関係付けられている制限付きの「ホープ」を6つ削減し、制限なしの「ホープ」を3つ加算する。
合体処理が実行された場合、ユーザのゲーム画面には、2つの「ホープ」が合体して1つになる動画演出等が行われるようにしてもよい。
あるいは、後述するように、複数の「ホープ」を合体して1つにすることにより、合体後の「ホープ」の使用期限が例えば1週間に延長される(すなわち、権利の制限が緩和される)ようにしてもよい。
また、このような権利の制限の解除または緩和は、権利数の低減に代えて、ユーザが対価(所定のゲーム内ポイント、アイテム等)を支払うことにより可能としてもよい。例えば、ユーザが回復アイテム1つを対価として支払うことにより、所定数(例えば1つ)の「ホープ」がいつでも使用できる、または所定期間(例えば1週間)使用できるようにする。なお、例えば2つの「ホープ」の合体は、1つの「ホープ」の使用制限を解除等するために、もう1つの「ホープ」を対価として支払うことと捉えることもできる。このように、「ホープ」(権利)に設けられた制限を解除または緩和するための対価は、「ホープ」自体であってもよいし、「ホープ」以外のポイントやアイテムであってもよい。
すなわち、前記制限変更手段72は、ユーザによる権利数を低減させるための入力又は対価を支払うための入力に応じて、権利の制限を解除または緩和する機能を有するものである。
ここで、本実施の形態のゲームサーバ1の1日の動作例を、図16及び図17のフローチャートを参照しながら、以下に説明する。
前述のように、1分間のパズルゲーム(図5参照)で獲得した得点10000点につき1つの「ホープ」がユーザに付与される。ユーザがパズルゲームで「ホープ」を入手した場合(S1でYES)、ゲームサーバ1は、その「ホープ」を制限付きの権利として記憶する(S2)。すなわち、図11のユーザ情報データベースにおいて、前記ユーザのユーザIDと関係付けられた「ホープ(制限あり)」の個数を加算する。これにより、ユーザがパズルゲームで獲得した「ホープ」には、直近の締切期限の予想ゲームでのみ使用できるという制限が付される。
また、前述のように、ユーザは、パズルゲームで獲得した「ホープ」を予想ゲームで使用できる。本実施の形態では、図6に例示する予想ゲームの画面で、ユーザが現実世界で活躍すると予想する実在選手を選択して、その実在選手に「ホープ」を設定することが、「ホープ」の使用に該当する。このようにして、ユーザが予想ゲームで「ホープ」を使用する入力をした場合(S3でYES)、ゲームサーバ1は、制限付き「ホープ」を優先的に使用する処理を実行する(S4)。すなわち、ユーザが制限付きと制限なしの両方の「ホープ」を所有している場合、先ず、制限付き「ホープ」から消費されるようにする。
ユーザが予想ゲームで「ホープ」を使用して実在選手の活躍を予想した場合、ゲームサーバ1は、ユーザの予想情報を、ユーザIDと関係付けてデータベースサーバ2に記憶する。図18に、ユーザID=000001のユーザの予想情報の一例を示す。この予想情報には、ユーザが「ホープ」を設定した実在選手の選手ID(活躍予想の選手ID)と、「ホープ」の設定数の情報とが含まれる。
また、前述のように、ユーザは、制限付き「ホープ」を合体して、その制限を解除することができる。本実施の形態では、図15に例示する画面で、入力領域313に合体回数を入力し、合体ボタン314を押せば、「ホープ」の合体を実行できる。ユーザが「ホープ」を合体する入力をした場合(S5でYES)、ゲームサーバ1は、ユーザが保有する2つの制限付き「ホープ」を合体して、1つの制限なし「ホープ」とする(S6)。なお、ユーザが指定した合体回数がnの場合、2×n個の制限付き「ホープ」を、n個の制限なし「ホープ」とする。
前記のステップS1〜S6の処理は、予想の締切時間(例えば17時)になるまで繰り返される。予想の締切時間を経過すれば(S7でYES)、その日の予想ゲームの予想の受け付けは終了となり、図17にステップS8以降の処理に移行する。ステップS8では、ユーザが使い残した制限付き「ホープ」があるか否かが判断される。ここで、制限付き「ホープ」が残存している場合(S8でYES)、ゲームサーバ1は、その制限付き「ホープ」を消滅させる(S9)。すなわち、制限付き「ホープ」には、直近の締切期限の予想ゲームでのみ使用できるという制限が付されているので、ゲームサーバ1は、締切期限を経過したことをもって、制限付き「ホープ」の各ユーザの保有数をゼロにリセットする。
予想の締切時間を経過した後も、ユーザは、パズルゲームを遊戯することで、「ホープ」を入手することができる。ユーザがパズルゲームで「ホープ」を入手した場合(S10でYES)、ゲームサーバ1は、その「ホープ」を制限付きの権利として記憶する(S11)。
また、現実世界において、予想ゲームの対象の野球の試合が終了した後(S12でYES)、ゲームサーバ1は、予想ゲームの結果を演算する予想結果演算処理を実行する(S13)。この予想結果演算処理の一例を、図19のフローチャートを参照しながら、以下に説明する。
先ず、図6の予想ゲームの画面の領域214に表示されていた、予想可能な実在選手の現実の試合での実績が、ゲームサーバ1に入力される(S21)。なお、実在選手の実績に関する情報については、ゲーム運営側のオペレータによってゲームサーバ1に直接的に入力またはネットワーク等を介して提供されるものであってもよいし、野球の試合の情報を販売等している会社やその系列グループのサーバから提供を受けた情報であってもよい。例えば、選手がヒットを打った等の情報を、1球毎、イニング毎または試合終了後に提供するような情報提供サーバは数多く存在するので、そのようなサーバの提供情報を利用して、実在選手の現実の試合での実績の情報をゲームサーバ1に取り込むこともできる。また、前記実績の情報は、現実世界の試合の画像や音声等を自動的に分析することによって取得される情報であってもよい。
その後、ゲームサーバ1は、入力された各実在選手の実績に基づいて、実在選手毎に活躍度を算出する(S22)。例えば、単打100、本塁打400、1打点につき100等の予め定められた評価ポイントを使用して、各実在選手の活躍度を算出する。例えば、ある実在選手の実績が、4打数3安打(単打2、本塁打1)2打点であった場合、単打100×2+本塁打400×1+打点100×2=800がその実在選手の活躍度となる。
次に、ゲームサーバ1は、予想ゲームにエントリーしているユーザ(すなわち「ホープ」を使用して実在選手の活躍予想をしたユーザ)毎に、予想の的中度を算出する。すなわち、ゲームサーバ1は、先ず、予想ゲームにエントリーしているユーザを特定する(S23)。そして、ゲームサーバ1は、ユーザが「ホープ」を設定した実在選手の活躍度に、当該実在選手に設定されている「ホープ」の数を掛け合わせて、予想的中スコアを算出する(S24)。例えば、ユーザが、活躍度800の実在選手に6個の「ホープ」を設定していた場合、800×6=4800がその実在選手に対する予想的中スコアとなる。ユーザが複数の実在選手に対して「ホープ」を設定している場合は、ゲームサーバ1は、各実在選手に対して予想的中スコアを算出する。
また、ゲームサーバ1は、ユーザが「ホープ」を設定した複数の実在選手の予想的中スコアを合計して、当該ユーザが獲得した予想的中スコアを求める(S25)。例えば、ユーザが5人の実在選手に「ホープ」を設定し、各実在選手の予想的中スコアがそれぞれ4800、1200、600、1000、400であった場合、当該ユーザが獲得した予想的中スコアは、4800+1200+600+1000+400=8000となる。
前記ステップS23〜S25の処理は、予想ゲームにエントリーしている全ユーザに対して実行される。ゲームサーバ1は、予想ゲームにエントリーしている全ユーザの予想的中スコアを算出した後(S26でYES)、各ユーザのランキングを求める(S27)。例えば、ゲームサーバ1は、その日の予想ゲームのみを対象としたデイリーランキングや、その週の予想ゲームを対象としたウィークリーランキング等を求める。そして、ユーザからのランキング確認要求に応じて、ゲームサーバ1は、ランキング表示画面を生成してユーザの端末装置3に送信する。このランキング表示画面では、ユーザ自身のランキングの他に、ユーザとその仲間を対象とした仲間内のランキングも確認することができる。
また、ゲームサーバ1は、ランキングに応じてユーザに報酬を付与する(S28)。例えば、ゲームサーバ1は、ランキングの上位100位以内のユーザには、回復アイテム、次の予想ゲームで予想可能な選手枠を拡大する(通常5枠のところを6枠とする)などの報酬を付与する。
なお、フローチャートでは省略しているが、予想ゲームの結果が出た後も、ユーザは、パズルゲームを遊戯することで、制限付きの「ホープ」を入手することができる。
以上のように、本実施の形態のゲームサーバ1は、図12に示す制限手段71および制限変更手段72を備えており、ユーザが第2ゲーム(パズルゲーム等)で獲得した、第1ゲーム(予想ゲーム等)を実行するための権利(「ホープ」)の使用に制限が設けられる一方、ユーザは、自らの意思で、権利数を低減させるための入力(合体操作等)又は対価を支払うための入力を行うことにより、権利の制限を解除または緩和することができる。この構成によって、制限が設けられた権利について、ユーザは、権利数を低減させないで(または対価を支払わないで)制限内でその権利を使用することも、権利数の低減等を伴っても権利の制限を解除または緩和して権利使用の自由度を高めることもできる。これにより、下記(a)〜(d)のような様々な遊戯が可能となる。
(a)パズルゲームを遊戯して獲得した予想ゲームで使用する「ホープ」を、「ホープ」の保有数の低減等を伴うことなく最大限有効に使用するため、制限内で(本実施の形態では直近の予想締切期限までに)その「ホープ」を使い切る。
(b)予想ゲームの締切期限の直前にパズルゲームを遊戯して「ホープ」を獲得した場合、その「ホープ」を使用する時間的余裕が少ない。そこで、合体等により「ホープ」の使用制限を解除または緩和することにより、予想ゲームについては、後日、時間をとってゆっくり遊戯する。
(c)パズルゲームを何度も遊戯して多目に「ホープ」を獲得したため、本日の野球の試合を対象とする予想ゲームには獲得した「ホープ」の一部を使用するが、残りの「ホープ」を合体等して権利の制限を解除または緩和し、明日以降の野球の試合を対象とする予想ゲームにも「ホープ」を使用できるようにする。
(d)休日等、時間のある日にパズルゲームを数多く遊戯して多数の「ホープ」を獲得し、その「ホープ」の制限を解除または緩和することにより、いつでも使える又は長期間使える「ホープ」を手元に貯めておく。
本構成により、ユーザは制限された「ホープ」(権利)について、その制限を解除(または緩和)するかしないかを考えながら遊戯することにより、上述のように遊戯のバリエーションが増え、ゲームの興趣性を高めることができる。
また、本実施の形態で対象とする予想ゲーム(第1ゲーム)は、現実世界の野球の試合で活躍する選手を予想する予想ゲームであり、試合前にユーザの予想を受け付け、試合後に予想結果が出る1日に1回の遊戯サイクルである。この予想ゲームの実行可能周期は1日である。また、パズルゲーム(第2ゲーム)は、1分間の制限時間内に獲得したスコアに応じて、予想ゲーム(第1ゲーム)を実行するための権利である「ホープ」を獲得するゲームである。このパズルゲームの実行可能周期は1分である。すなわち、本実施の形態は、第1ゲームの実行可能周期よりも第2ゲームの実行可能周期の方が短く設定されている好ましい形態である。
これにより、ユーザは、予想ゲームの1回の遊戯サイクルの中で、パズルゲームを複数回遊戯することによって、予想ゲームで使用するための複数の「ホープ」を獲得できる。当然、「ホープ」を多く獲得するほど、予想ゲームでは、活躍しそうな選手をより多く予想することができ、予想ゲームを有利に進めることができる。これにより、ユーザに対して、第1ゲームである予想ゲームを有利に進めるために、第2ゲームであるパズルゲームを数多く遊戯するように動機付けることができる。また、ユーザがパズルゲームで獲得した複数の「ホープ」は、前述のように、制限内で使用することも、制限を解除等して使用の自由度を高めることもでき、興趣性の高いゲームを実現できる。
なお、本実施の形態の予想ゲームおよびパズルゲームは、第1ゲームおよび第2ゲームの一例であり、これに限定されない。第1ゲームの実行可能周期よりも前記第2ゲームの実行可能周期の方が短く設定されていれば、ゲームの種類、内容は問わず、好ましい形態となる。
また、ゲームサーバ1は、図13に示すように、難易度変更手段73をさらに備えている構成とすることもできる。この第3報知手段81は、ユーザによる前記第1ゲームの結果に応じて、所定期間、前記第2ゲームにおける前記権利の獲得の難易度を変更する機能を有する。これにより、第1ゲーム(予想ゲーム等)の結果に応じて、第2ゲーム(パズルゲーム等)の難易度(権利獲得の難易度)を可変するフィードバック構成を実現する。
本実施の形態では、ユーザが予想ゲームで獲得した予想的中スコアが高いほど、パズルゲームの制限時間を長くする(通常1分のところ1分30秒、2分と長くパズルゲームを続けることができるようにする)ことにより、パズルゲームで「ホープ」をより獲得し易くする。予想ゲームの結果とパズルゲームの制限時間との関係の一例を、図20に示す。同図に示すように、予想的中スコアが5000未満、5000〜9999、10000〜14999、15000〜19999、20000以上の場合、パズルゲームのゲーム時間をそれぞれ、1分、1分15秒、1分30秒、1分45秒、2分とする。ゲームサーバ1は、図20に示す情報を記憶装置(補助記憶装置14等)に記憶している。
なお、予想ゲームの結果とパズルゲームの制限時間との関係は、上記に限定されるものではなく、任意に定めることができる。例えば、パズルゲームの制限時間を、予想的中スコアcの関数f(c)として表し、予想的中スコアcに応じて連続的にパズルゲームの制限時間を変更するようにしてもよい。
また、ユーザが予想ゲームで獲得した予想的中スコアが低いほど、パズルゲームの制限時間を短くする(通常1分のところ50秒、40秒とする)長くすることにより、パズルゲームにおける「ホープ」獲得の難易度を高くしてもよい。
あるいは、難易度変更手段73は、ユーザが予想ゲーム(第1ゲーム)で獲得した予想的中スコアが高いほど、パズルゲーム(第2ゲーム)自体の難易度を低下させることにより、パズルゲームで「ホープ」をより獲得し易くしてもよい。パズルゲーム自体の難易度を変更する例としては、パズルゲームの制限時間(例えば1分)を固定したままで、図5のパズルゲームの画面に登場する「おおだま」アイコン208の種類を増減する方法がある。すなわち、パズルゲームの画面に登場する「おおだま」アイコン208の種類を減少させるほど、同一種類の「おおだま」アイコン208が3つ以上繋がり易くなるので、パズルゲーム自体の難易度を低下させることができる。逆に、「おおだま」アイコン208の種類を増やせば、パズルゲーム自体の難易度も高くなる。そこで、例えば、予想的中スコアが10000未満、10000〜14999、15000〜19999、20000以上の場合、パズルゲームに登場する「おおだま」アイコンの種類数をそれぞれ、6種類、5種類、4種類、3種類とする。これにより、ユーザが予想ゲームで獲得した予想的中スコアが高いほど、パズルゲーム自体の難易度を低下させることができる。
また、パズルゲーム(第2ゲーム)自体の難易度を変更する他の例としては、同一種類の「おおだま」アイコン208がn個以上連続で繋がればそれを消去できる(得点を獲得できる)ゲームにおいて、nの値を変更する方法もある。例えば、同一種類の「おおだま」アイコン208が4個以上連続で繋がればそれを消去できるよりも、3個以上連続で繋がればそれを消去できる方が、よりパズルゲーム自体の難易度が低下する。そこで、例えば、予想的中スコアが20000未満の場合に前記nの値を4とし、予想的中スコアが20000以上の場合に前記nの値を3とする。
なお、ユーザによる第1ゲームの結果に応じて、所定期間、第2ゲームにおける権利の獲得の難易度を変更する方法は、上記に限定されるものではなく、第2ゲームの種類、内容に応じて種々の形態を適用できる。
上記のフィードバックによる効果は、所定期間(例えば1日)、有効である。この所定期間は、第1ゲームの実行可能周期に合わせて設定することが好ましく、本実施の形態の予想ゲームの場合、予想の締切期限から次の予想の締切期限までの期間とすることができる。パズルゲームにおいて「ホープ」獲得の難易度が低下する期間は、所定期間に限られているので、ユーザはその期間中にできるだけ多くパズルゲームを実行する動機付けを与えられる。
本構成により、パズルゲームを多く遊戯して予想ゲームで使用する「ホープ」を多く獲得すれば、予想ゲームでよい結果を出す可能性が高まり、予想ゲームでよい結果を出せば、パズルゲームで「ホープ」を獲得し易くなるという、両ゲーム間のフィードバックを実現する。これによりゲームの興趣性をさらに高めることができる。
ところで、前述のように、制限付き「ホープ」は、合体等によりその制限を解除して、いつでも使用できるようにしてもよいし、その制限を緩和して使用できる期間を延長してもよい。以下には、バリエーションとして、「ホープ」の合体数によって、「ホープ」の使用期限を順次、延ばす構成例について説明する。
本実施の形態の制限変更手段72は、権利数(「ホープ」の保有数)の低減の大きさに応じて、権利の制限緩和の程度を変更する機能を有する。本実施の形態では、ユーザが保有する制限付きの2つの「ホープ」を合体して、その数を1/2に低減させれば、合体後の「ホープ」の使用期限が1週間に延長される。また、ユーザが保有する制限付きの3つの「ホープ」を合体して、その数を1/3に低減させれば、合体後の「ホープ」の使用期限が1か月に延長される。さらに、ユーザが保有する制限付きの4つの「ホープ」を合体して、その数を1/4に低減させれば、合体後の「ホープ」の制限は解除され、いつでも予想ゲームで使用できるようになる。
なお、使用期限が延長された又は期限なしの「ホープ」を、ユーザが予想ゲームで使用すれば、その「ホープ」は消滅する。すなわち、何れの「ホープ」も、使用できる回数は1回だけである。
図21に、「ホープ」を合体するための操作画面の一例を示す。この画面には、現在保有している「ホープ」の数を表示する領域321が設けられる。本実施の形態では、本日の予想にのみ使用可能な「ホープ」(すなわち、合体していない「ホープ」)、合体により使用期限を延長した「ホープ」、合体によりいつでも使用可能となった「ホープ」に分けて、現在の保有数を表示している。また、使用期限を延長した「ホープ」については、「ホープ」によって延長期限が異なるが、その中で最も早い期限(最短期限)の情報も併せて表示している。
また、画面には、2つの「ホープ」を合体する処理を実行するための「2つ合体」ボタン322、3つの「ホープ」を合体する処理を実行するための「3つ合体」ボタン323、および4つの「ホープ」を合体する処理を実行するための「4つ合体」ボタン324が設けられる。ユーザがボタン322・323・324の何れかを押せば、ユーザの端末装置3からゲームサーバ1に、そのボタン操作の入力情報が送信される。この入力情報を受信したゲームサーバ1では、押されたボタンに応じた合体処理を実行する。合体処理が実行された場合、ユーザのゲーム画面には、2つ〜4つの「ホープ」が合体して1つになる動画演出等が行われるようにしてもよい。
図22に示すように、ゲームサーバ1は、ユーザIDと対応付けて、ユーザの保有する「ホープ」の情報をデータベースサーバ2に記憶して管理する。同図では、ユーザID=000001のユーザが保有している「ホープ」の情報を例示している。ユーザの保有する「ホープ」の情報として、未合体の「ホープ」、2つ合体後の「ホープ」、3つ合体後の「ホープ」および4つ合体後の「ホープ」の個数が、それぞれ記憶される。また、2つ合体後の「ホープ」および3つ合体後の「ホープ」については、延長された使用期限の情報も併せて記憶される。未合体の「ホープ」は、前述の制限付き「ホープ」であり、本実施の形態では直近の予想締切期限の予想ゲームにしか使用できない。2つ合体後の「ホープ」および3つ合体後の「ホープ」は、設定された期限まで使用できる。4つ合体後の「ホープ」は、前述の制限なし「ホープ」であり、いつでも使用できる。
例えば、図21の画面で、ユーザが「2つ合体」ボタン322を押した場合、ゲームサーバ1は、図22のユーザの保有する「ホープ」の情報において、ユーザIDと関係付けられている未合体の「ホープ」を2つ削減し、2つ合体後の「ホープ」を1つ追加し、その使用期限を1週間後に設定する。また、図21の画面で、ユーザが「3つ合体」ボタン323を押した場合、ゲームサーバ1は、図22において、ユーザIDと関係付けられている未合体の「ホープ」を3つ削減し、3つ合体後の「ホープ」を1つ追加し、その使用期限を1か月後に設定する。また、また、図21の画面で、ユーザが「4つ合体」ボタン324を押した場合、ゲームサーバ1は、図22において、ユーザIDと関係付けられている未合体の「ホープ」を4つ削減し、4つ合体後の「ホープ」を1つ追加する。
また、図15の画面における、合体する回数を入力するための入力領域313を、図21の画面にも設けて、一度に複数回の合体操作を行えるようにしてもよい。
このように、権利数の低減の大きさ(合体する「ホープ」の個数)に応じて、その低減後の権利の制限緩和の程度を変更することにより、ユーザは、権利数をあまり低減させないで制限内でその権利を使い切ることも、権利数の低減の程度は大きくなるが長期間使用できる権利として持っておくことも可能となり、ゲームの興趣性をより高めることができる。
なお、「ホープ」合体のバリエーションとしては、「合体後のホープ」と「未合体のホープ」とを合体したり、「合体後のホープ」同士を合体したりできるようにしてもよい。例えば、「2つ合体後のホープ」1つと「未合体のホープ」1つとを合体すれば、合体後の「ホープ」の使用期限は、「2つ合体後のホープ」の使用期限よりさらに3週間延長されるようにする。また、「2つ合体後のホープ」2つを合体すれば、合体後の「ホープ」はいつでも使用できるようにする。これらは一例であり、「ホープ」合体の形態には様々なバリエーションを取り得る。
また、本実施の形態では、使用期限の異なる複数の「ホープ」が存在することとなるが、ユーザが予想ゲームで「ホープ」を使用する入力をした場合、ゲームサーバ1は、使用期限の早い「ホープ」から自動的に使用する。
前述の実施の形態では、ユーザがパズルゲームで獲得した「ホープ」(合体されていない「ホープ」)は、直近の予想締切期限の予想ゲームにしか使用できないという使用対象の制限が付されている。以下には、バリエーションとして、ユーザがパズルゲームで獲得した「ホープ」に使用期限の制限を設ける構成を説明する。
本実施の形態の制限手段71は、ユーザが第2ゲーム(パズルゲーム)によって獲得した権利(「ホープ」)に、少なくとも、当該権利の獲得後最初に来る締切期限の予想ゲームには使用できる使用期限を設ける機能を有する。例えば、本日の野球の試合(18時試合開始)の予想の締切期限が17時に設定されており、ユーザがその日の14時にパズルゲームで獲得した「ホープ」には、その日の締切期限17時までの3時間の使用期限が設けられる。また、ユーザが17時30分にパズルゲームで「ホープ」を獲得した場合、本日の締切期限の17時が過ぎているので、その「ホープ」には、次の締切期限である翌日の17時までの23時間30分の使用期限が設けられる。
このように、各「ホープ」に使用期限を設定してその使用を制限する。なお、「ホープ」の使用期限は、使用可能な残り時間で管理することも、使用可能な最終時刻で管理することもできる。例えば、本日17時までの3時間を使用期限とする「ホープ」の場合、「残り3時間」の情報を記憶装置に記憶して管理することも、使用可能な最終時刻「本日17時」の情報を記憶して管理することも可能である。ただし、使用可能な残り時間の情報は、時間経過にともなって常時変動する情報(常時更新が必要)であるので、通常は使用可能な最終時刻を記憶して管理する。そして、使用可能な残り時間の情報を画面に表示する場合には、使用可能な最終時刻と現在時刻との差を演算して使用可能な残り時間を求める。
本構成の場合も、ユーザは、「ホープ」の合体等による権利数の低減又は対価を支払うための入力により、前述の実施の形態と同様に、権利の使用期限を解除または緩和することができる。
また、ゲームサーバ1は、図23に示すように、期限可変手段74をさらに備えている構成とすることもできる。この期限可変手段74は、ユーザが第2ゲームであるパズルゲームで「ホープ」を獲得する毎に、抽選によってその使用期限の長さを可変する機能を有する。
例えば、期限可変手段74は、ユーザがパズルゲームによって獲得した「ホープ」に、その獲得後最初に来る締切期限の予想ゲームには使用できる基本の使用期限(例えば前記締切期限の時刻を最終時刻とする使用期限)を設け、さらに抽選によって延長時間を付加することにより、使用期限の長さを可変する。図24Aに、延長時間と抽選確率の関係を示した確率テーブルの一例を示す。この例では、延長時間として、0時間、3時間、10時間、20時間、30時間の何れかがそれぞれ20%の確率で選択される。この場合、抽選で決定される延長時間によって、「ホープ」が直近の試合の予想ゲームにしか使えない場合もあるし、翌日以降の試合の予想ゲームにも使える場合もある。
各延長時間の抽選確率は任意に設定可能であり、例えば図24Bまたは図24Cに示すように、各延長時間の抽選確率を異ならせてもよい。また、選択される延長時間も図24A〜図24Cの例に限定されず、50時間、100時間等、より長い延長時間が選択されるようにしてもよい。
例えば、パズルゲームで14時に「ホープ」を獲得したものとする。この場合、直近の野球の試合の予想ゲームの締切期限17時までの時間が3時間であり、3時間の延長時間が抽選されたとした場合、3時間+3時間=6時間がその「ホープ」の使用期限となる。よって、この場合、「ホープ」には、使用可能な最終時刻をその日の20時とする使用期限が設けられる。また、抽選により30時間の延長時間が選ばれた場合、3時間+30時間=33時間が前記「ホープ」の使用期限となる。この場合、「ホープ」には、使用可能な最終時刻を翌日の23時とする使用期限が設けられるので、翌日の試合の予想ゲームにも余裕をもって使用できる。
また、本実施の形態でも、前述のように、2つの「ホープ」を合体することにより、その期限はなくなり、いつでも使用できるようになる。本実施の形態の場合、未合体の「ホープ」によって使用期限が異なっているので、ゲームサーバ1は、合体処理の際、自動的に、使用期限の早い「ホープ」から順番に合体に使用する。また、前述のように、合体する「ホープ」の数に応じて使用期限の制限緩和の程度を可変としてもよい。
本実施の形態のゲームサーバ1は、図25に示すように、ユーザIDと対応付けて、ユーザの保有する「ホープ」の情報をデータベースサーバ2に記憶して管理する。同図では、ユーザID=000001のユーザが保有している「ホープ」の情報を例示している。この例では、ユーザの保有する「ホープ」の情報として、未合体の「ホープ」(使用期限付き)および合体後の「ホープ」(使用期限なし)の個数が、それぞれ記憶される。また、未合体の「ホープ」には使用期限の情報も併せて記憶される。
また、本実施の形態でも、ユーザが予想ゲームで「ホープ」を使用する入力をした場合、ゲームサーバ1は、使用期限の早い「ホープ」から自動的に使用する。
本構成の場合、「ホープ」によって使用期限が異なっているので、例えば、使用期限の長い「ホープ」は合成等せずにそのまま使用し、使用期限の短い「ホープ」同士を合成等して使用期限を解除または緩和するといった対応が可能となり、よりゲームの興趣性を高めることができる。
なお、図23では、期限可変手段74の他に、次に説明する確率変動手段75を備えている構成を示しているが、確率変動手段75は省略することができる。
次に、ゲームサーバ1が、図23に示す確率変動手段75をさらに備えている好ましい構成について説明する。この確率変動手段75は、所定期間内にユーザが行った第2ゲーム(パズルゲーム)の実行回数が多いほど、前記期限可変手段74が抽選で決定する使用期限として長い期限が選択される確率が高くなるように前記抽選の確率を変動させる機能を有する。ここで、前記所定期間は、任意に設定することができる。例えば、第1ゲーム(予想ゲーム)の実行可能周期に合わせて、前回の予想の締切期限から今回の予想の締切期限までの期間を、前記所定期間とすることができる。
例えば、前回の予想の締切期限以降にユーザによって実行されたパズルゲームの実行回数が9回以下の場合、確率変動手段75は、図24Aの確率テーブルを選択する。そして、期限可変手段74は、確率変動手段75によって選択された図24Aの確率テーブルを使用して、「ホープ」の使用期限を抽選により決定する。
また、例えば、前回の予想の締切期限以降にユーザによって実行されたパズルゲームの実行回数が10回〜19回の場合、確率変動手段75は、図24Bの確率テーブルを選択する。図24Bの確率テーブルは、図24Aの確率テーブルよりも、長い延長時間が抽選される確率が高くなっている。そして、期限可変手段74は、選択された図24Bの確率テーブルを使用して、「ホープ」の使用期限を抽選により決定するので、パズルゲームの実行回数が9回以内の場合よりも、長い使用期限が選択され易くなる。
また、例えば、前回の予想の締切期限以降にユーザによって実行されたパズルゲームの実行回数が20回以上の場合、確率変動手段75は、図24Cの確率テーブルを選択する。図24Cの確率テーブルは、図24Bの確率テーブルよりも、長い延長時間が抽選される確率がさらに高くなっている。そして、期限可変手段74は、選択された図24Cの確率テーブルを使用して、「ホープ」の使用期限を抽選により決定するので、パズルゲームの実行回数が19回以内の場合よりも、長い使用期限が選択され易くなる。
本構成により、第2ゲーム(パズルゲーム)の実行回数が多いほど有利になるので、ユーザに対して、第2ゲームをより多く遊戯することを動機付けることができ、ゲームの活性化を図れる。
〔ゲームシステムの他の構成例〕
前述の各実施の形態では、ゲーム実行プログラムがゲームサーバ1側に実装されており、各ユーザの端末装置3における入力操作に応じて、ゲームサーバ1がゲーム進行のための演算処理やデータ処理を実行し、その実行結果を反映させた画面データを端末装置3へ送信することによって、ゲームが進行するゲームシステムへの適用例について説明した。これはいわゆるクライアントサーバ型のゲームシステムであり、サーバ(ゲームサーバ1およびデータベースサーバ2)によってゲーム管理装置を構成する例である。この構成は、前述のように、ブラウザゲーム、ソーシャルゲーム、クラウドゲーミング等のサービスをユーザに提供するのに適した構成であるが、ゲーム管理装置の構成はこれに限定されない。
例えば、ゲームサーバ1が、各ユーザのゲーム情報を管理し、ゲーム内でのユーザ間の交流等のゲームサービスをユーザに提供する一方、ゲームを進行させるゲーム実行処理については、基本的にはユーザの端末装置側にて行われるゲームシステムにも適用できる。
すなわち、ゲーム実行プログラムの一部または全部をユーザの端末装置側にダウンロードまたはインストールし、端末装置においてもゲーム実行処理が行われるようなゲームシステムにも適用できる。例えば、ユーザの端末装置が、インターネット通信、無線LAN通信、所定の周波数帯(例えば2.4GHzの周波数帯)を用いた近距離無線通信、または有線LAN通信などにより他のユーザの端末装置とピア・ツー・ピア接続し、ピア・ツー・ピア型のゲームを実行することも可能である。
そして、サーバと端末装置とは互いに通信して各種データの送受が可能であり、共にCPU、ROM、RAM、補助記憶装置、通信制御部等を備えた情報処理装置(コンピュータ)であって、同様のハード構成を有する。よって、サーバと端末装置とを含むゲームシステムにおいて、上述の各実施の形態で説明したゲーム管理装置が具備する各手段は、サーバ又は端末装置の何れか一方が備えていればよい。すなわち、ゲーム管理装置は、互いに通信して各種データの送受を行うサーバおよび端末装置に設けられる構成とすることができ、前述の実施の形態と同様の作用効果を奏する。
例えば、図12ではゲームサーバ1が、制限手段71および制限変更手段72を備えていたが、図26に例示するように、各手段の機能をサーバおよび端末装置の何れかに持たせることが可能である。ここで、図26に示すサーバのハード構成は、図2に示したゲームサーバ1と同様であり、端末装置のハード構成は、図3に示した端末装置3と同様である。図26には、サーバ101に制限手段71を設けると共に、端末装置301に制限変更手段72を設ける構成例を示している。なお、図26はゲームシステムの構成の一例であり、他の構成も可能である。
また、図27に示すように、端末装置301が、制限手段71および制限変更手段72を備えている構成とすることもできる。すなわち、ゲーム管理装置をゲーム端末である端末装置301それ自体に実装することができ、この場合も前述の実施の形態と同様の作用効果を奏する。この場合、サーバ101が、各ユーザのゲーム情報を管理したり、端末装置301間で行われる挨拶やメッセージの送受等のサービスをユーザに提供したりするが、その他の処理は全て端末装置301側で実行されるようにすることができる。あるいは、各ユーザのゲーム情報の管理も、各ユーザの端末装置301側で行うこともできる。
また、前述の各手段73〜75等についても、サーバ側だけではなく、端末装置(ゲーム端末)側に設けることもできる。
〔その他の実施の形態〕
前記の実施の形態では、ユーザと関連付けがなされている他のユーザを仲間とする例を示したが、ユーザと関連付けがなされている他のユーザであれば、仲間という関係でなくても本発明を適用できる。
また、前記の実施の形態では、第1ゲームを予想ゲーム、第2ゲームをパズルゲームとした例を示したが、これに限定されるものではなく、様々なゲームを適用できる。例えば、第1ゲームを対戦ゲーム、ロールプレイングゲーム等とすることができる。また、第2ゲームを、クイズゲーム、音楽(リズム)ゲーム等とすることができる。
また、前記の実施の形態では、第1ゲームとしての予想ゲームを、現実世界の野球の試合で活躍する選手を、所定の締切期限までにユーザが予想するゲームとして説明したが、予想ゲームはこれに限定されない。すなわち、予想ゲームは、現実世界またはゲーム内で発生する結果を、所定の締切期限までにユーザが予想するゲームであればよい。現実世界で発生する結果を予想するゲームとしては、野球、サッカー等の各種スポーツ競技、競馬レース、カーレース、テレビ等の放送番組で行われるクイズ等、現実世界で発生する様々な結果を対象とした予想ゲームが適用できる。
また、ゲーム内で発生する結果を予想するゲームとしては、ゲーム内に存在する複数のキャラクタ(例えば、野球ゲームの選手キャラクタ、競馬ゲームの競走馬キャラクタ等)の中から活躍するキャラクタを予想するものが挙げられる。これは、現実世界の実在選手の活躍を予想することに代えて、ゲーム内のキャラクタの活躍を予想するものである。ゲーム内のキャラクタが活躍したか否かの評価は、例えば、次のようにして行うことができる。
ここでは、各ユーザが所定数の選手キャラクタで自分のチームを作り、ユーザ同士で対戦を行なう野球ゲームを例示する。この対戦では、野球の試合のシミュレーションが実行され、両チームの各選手キャラクタの成績(打率等)が記録される。そして、所定期間(例えば1日)にゲーム内で実行された全ての対戦のゲーム結果(各選手キャラクタの成績)をゲームサーバ1が集計し、選手キャラクタ毎に活躍を評価する(例えば、平均打率等により評価する)。このようにして、ゲーム内のキャラクタの活躍を評価することにより、ユーザがどのキャラクタが活躍するかを予想するゲームを実現できる。
また、前記の実施の形態では、権利の制限を解除または緩和するためには、ユーザによる入力(権利数を低減させるための入力又は対価を支払うための入力)の操作が必要な構成について説明した。よって、ユーザが権利(制限付き「ホープ」)を使用期限内に使用せず、且つ、権利の制限を解除または緩和するための入力もせずに使用期限をむかえた場合、ゲーム管理装置は、その権利を消滅させる。これに対して、次のようなバリエーションも可能である。
すなわち、ユーザが制限付き「ホープ」(権利)を使用期限内に使用せずに使用期限をむかえた場合、ユーザの合成入力なしに、ゲーム管理装置が、使用期限をむかえた時点で残存している未合成の「ホープ」を自動的に合成(権利数を低減)し、その制限を解除または緩和する。これにより、使用期限を過ぎた「ホープ」が無駄になることはなくなり、また、ユーザの入力の手間を省くこともできる。
また、各種情報を記憶装置に記憶する記憶制御機能を有する構成(ユーザ情報記憶制御手段60など)に関し、記憶装置そのものについては当該構成に含まれないので、ゲーム管理装置(またはゲームシステム)の内外を問わず、どこに設置されていてもよい。例えば、記憶装置は、ゲームサーバ1が有するRAM13や補助記憶装置14、データベースサーバ2、端末装置3が有するRAM33や補助記憶装置39、あるいはゲーム管理装置や端末装置とは別構成のファイルサーバ(オンラインストレージ)等であってもよい。
また、前述の各実施の形態で説明した各構成は、適宜組み合わせて適用することができる。
また、本実施の形態に係るコンピュータ読み取り可能なプログラムは、ハードディスク、光ディスク(CD−ROM、DVD−ROM等)、フレキシブルディスク、半導体メモリ等のコンピュータ読み取り可能な各種記録媒体に記録され、当該記録媒体から読み出されてサーバ、端末装置(ゲーム端末)のCPUにより実行される。また、プログラムをサーバ等に提供する手段は、前述した記録媒体に限定されるものではなく、インターネット等の通信ネットワークを介して行うこともできる。