以下、本発明の一実施の形態に係るゲーム管理装置、ゲーム管理方法及びプログラムについて、図面を参照しながら説明する。
〔ゲームシステムの概要〕
本発明の一実施の形態に係るゲーム管理装置が組み込まれたゲームシステムの構成例を、図1に示している。同図に示すように、このゲームシステムは、インターネットなどのネットワーク4上に設置されたゲームサーバ1と、当該ゲームサーバ1と通信可能に接続されたデータベースサーバ2と、ネットワーク4を介してゲームサーバ1と通信可能に接続できる各ユーザの端末装置3とによって構成される。
本実施の形態のネットワーク4は、インターネットに限定されるものではなく、ゲームサーバ1と各ユーザの端末装置3との間を通信可能に相互に接続できるものであれば、例えば、専用回線、公衆回線(電話回線、移動体通信回線等)、有線LAN(Local Area Network)、無線LAN等であってもよく、或いはインターネットとこれらを組み合わせたものであってもよい。
このゲームシステムの例において、本発明の一実施の形態に係るゲーム管理装置は、ゲームサーバ1およびデータベースサーバ2から構成される。ゲームサーバ1は、ゲームサービスを受ける各ユーザの端末装置3からのネットワーク4を介したアクセスを受け付けて、各ユーザのゲーム情報をデータベースサーバ2(記憶装置)に蓄積して管理し、各ユーザにネットワーク4を介したゲームサービスを提供する。
本実施の形態では、ゲームサーバ1によるゲームサービスの提供の一形態として、各ユーザの端末装置3に搭載されたウェブブラウザによってゲームがプレイできる、いわゆるブラウザゲームを提供する例について説明する。このブラウザゲームを提供するサービス形態では、ユーザの端末装置3にゲーム専用のソフトウェアをダウンロード又はインストールする必要がなく、端末装置3をネットワーク4に接続できる環境であれば、ユーザはどこでも気軽にゲームサーバ1から提供されるゲームサービスを楽しむことができる。
このゲームシステムでは、ブラウザゲーム用のプログラム(アプリケーションソフトウェア)がゲームサーバ1に実装されており、ゲームサーバ1が、各ユーザの端末装置3における入力操作に応じてゲーム進行のための演算処理やデータ処理を実行する。そして、ゲームサーバ1は、演算処理等の実行結果に基づいてデータベースサーバ2内の各ユーザのゲーム情報を更新するとともに、当該実行結果をユーザの端末装置3の画面に表示させるためのウェブページ情報(ゲーム画面データ)を各ユーザの端末装置3に送信する。
各ユーザの端末装置3には、ユーザーエージェントとしてウェブサイト閲覧機能を有するウェブブラウザが搭載されており、ゲームサーバ1から送信されたウェブページ情報を端末装置3の画面に表示することができるようになっている。この端末装置3としては、例えば、携帯電話端末、PHS(Personal Handy-phone System)端末、携帯情報端末(PDA:Personal Digital Assistant)、携帯電話と携帯情報端末とを融合させた携帯端末であるスマートフォン、パーソナルコンピュータ、タブレット型コンピュータまたは通信機能を有するゲーム装置(据置型または携帯型のゲーム装置)など、ネットワーク4経由でゲームサーバ1に接続してゲームサービスの提供を受けることができる様々な端末が適用できる。
また、本実施の形態で提供されるゲームは、ユーザが、ゲームサービスを受けている他のユーザと交流を行いながらプレイすることができる、いわゆるソーシャルゲームの要素を有するものとすることができる。例えば、本実施の形態のゲームサーバ1およびデータベースサーバ2をソーシャルネットワーキングサービス(SNS)のシステムに組み込むことによって、SNSのサービスの一つとしてソーシャルゲームサービスを提供するゲームシステムとすることができる。このようにSNSのプラットフォーム上で動作するゲームシステムによりゲームサービスをユーザに提供することもできるが、ゲームサーバ1およびデータベースサーバ2をSNSのシステムに組み込まずに、独立したゲームシステムとして構築してもよい。本ゲームシステムは、他のユーザと交流ができないようなオンラインゲームにも適用可能であるが、本実施の形態では、他のユーザと交流可能なゲームについて説明する。
本ゲームサーバ1によって提供されるゲームの例としては、野球、サッカー、テニス、アメリカンフットボール、バスケットボール、バレーボール、ゴルフ、ボクシング、競馬、カーレースなどを題材としたスポーツ・レースゲーム、シミュレーションゲーム、育成ゲーム、ロールプレイングゲームといったように、ゲーム形式・ジャンルを問わず様々なゲームを挙げることができる。その一例として、本実施の形態では、ゲームサーバ1がゲームサービスとして野球ゲームを提供する場合について、以下に説明する。
本実施の形態のゲームサーバ1は、現実世界の実在イベント(野球の試合等)で所定の現実事象(ヒット、得点が入る、各イニングが終了する等)が発生する毎に、当該各事象に関する情報を受け付け、現実事象をゲームに活用する。本実施の形態では、野球ゲームに合わせて、現実世界の実在イベントを野球の試合(プロ野球やMLB等の試合)として説明する。
そして、ゲームサーバ1は、現実世界の野球の試合で発生したヒット等の現実事象に対して、ユーザの端末装置3での所定の反映操作(キャラクタに能力情報を反映させるための操作)を受け付ける受付期間を設定する。例えば、イニング中に発生したヒット等に対しては、そのイニングの終了後にまとめて受付期間を設定する。そして、イニング終了毎に設けられる受付期間中に、ユーザが端末装置3で反映操作(例えば、端末装置3の画面に表示される反映ボタンを押す操作)を行えば、ゲームサーバ1は、各イニングで発生した現実事象に応じた能力情報(属性情報)をキャラクタに反映させるという特徴的な構成を有する。例えば第3イニング(3回の表裏)終了後の受付期間中にユーザが反映操作を行った場合は、第3イニング中に発生したヒット等の現実事象に応じてキャラクタが成長する一方、当該受付期間中に反映操作が行われなかった場合には第3イニングに関してキャラクタの成長はない。
上記の特徴的な構成により、現実世界の野球の試合中に発生するヒット等の現実事象にリアルタイムで連動させて、キャラクタをユーザの意思に基づく操作を介して育成可能とする。この場合、現実世界で発生する現実事象(単打、本塁打等)によってキャラクタの成長度が大きく異なるとともに、ユーザが反映操作を行わなければキャラクタの成長はないので、ユーザは、臨場感と緊張感を持って、現実世界の野球の試合を視聴しながらゲームをプレイすることができる。以下に、このような現実世界で発生する現実事象と連動した面白みのあるキャラクタ育成を実現可能とする、本実施の形態に係るゲーム管理装置(ゲームサーバ1等)の構成の詳細を説明する。
〔ゲーム管理装置の構成〕
上述のように本実施の形態では、ゲーム管理装置は、ゲームサーバ1およびデータベースサーバ2から構成される。図2にゲームサーバ1のハード構成の一例を示している。同図に示すように、ゲームサーバ1は、主に、CPU(Central Processing Unit)11と、主記憶装置としてのROM(Read Only Memory)12及びRAM(Random Access Memory)13と、補助記憶装置14と、通信制御部15と、入出力制御部16とを備えており、これらはアドレスバス、データバス及びコントロールバス等を含むバスライン19を介して相互に接続されている。なお、バスライン19と各構成要素との間には必要に応じてインタフェース回路が介在しているが、ここではインタフェース回路の図示を省略している。
CPU11は、システムソフトウェアやゲームプログラム等のアプリケーションソフトウェアの命令を解釈して実行し、ゲームサーバ1全体の制御を行う。ROM12は、ゲーム管理装置1の基本的な動作制御に必要なプログラム等を記憶している。RAM13は、各種プログラム及びデータを記憶し、CPU11に対する作業領域を確保する。
補助記憶装置14は、ゲームプログラム等のアプリケーションソフトウェアや各種データ等を格納する記憶装置である。補助記憶装置14としては、例えばハードディスクドライブなどを用いることができる。ゲームサーバ1(コンピュータ)をゲーム管理装置として動作させるための本実施の形態のプログラムも、この補助記憶装置14に記憶されており、当該プログラムはゲームサーバ1の起動時に補助記憶装置14からバスライン19を介してRAM13へとロードされ、当該CPU11によって実行される。
通信制御部15は、ネットワーク4と接続される通信インタフェース15aを備え、ネットワーク4を介した各ユーザの端末装置3との間の通信を制御する。また、通信制御部15は、ネットワーク4に接続されている図示しないサーバとの通信も制御するようになっている。例えば、ゲームサーバ1をSNSに組み込んだシステム構成とした場合、ゲームサーバ1の通信制御部15は、SNSサーバとの間の通信を制御する。また、通信制御部15は、後述する現実世界の野球の試合で発生する事象の情報を提供するサーバとの間の通信を制御する。
入出力制御部16は、キーボード、マウス、タッチパネル等の入力装置17およびディスプレイ等の出力装置18と接続され、これらの装置17・18との間の入出力制御を行う。オペレータは、キーボードやマウス等を使用して、野球の試合中に発生する事象の情報を手動でゲームサーバ1に入力することができる。また、入出力制御部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となる。
通信制御部41は、通信インタフェース41aを備え、ゲーム操作時等にデータ通信するための通信制御機能および携帯電話端末として音声データを送受信するための通信制御機能等を有している。ここで、データ通信用の通信制御機能には、例えば、無線LAN接続機能、無線LANや携帯電話回線網を介したインターネット接続機能、所定の周波数帯(例えば2.4GHzの周波数帯)を用いた近距離無線通信機能などが含まれる。通信制御部41は、CPU31からの命令に基づいてゲーム装置1を無線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が提供するゲームをプレイすることができるようになっている。
〔ゲーム管理装置の機能的構成〕
次に、上記のように構成されたゲーム管理装置(ゲームサーバ1およびデータベースサーバ2)の主要な機能について説明する。図4は、ゲーム管理装置の主要機能ブロック図である。
ゲーム管理装置は、主に、ゲーム情報管理手段51、ゲーム進行手段52、認証手段53、仲間管理手段54、現実事象受付手段55、操作受付手段56、関係情報記憶制御手段57、応援対象登録手段58(反映対象登録手段、イベント登録手段)、反映手段59およびキャラクタ登録手段60を備えている。これらの各手段51〜69は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。
ゲーム情報管理手段51は、各ユーザのゲーム情報をデータベースサーバ2に蓄積して管理する。ゲーム情報管理手段51で管理されるゲーム情報の項目は、本ゲームサーバ1がユーザに提供するゲームサービスの内容によって異なる。本実施の形態では、ユーザがゲーム内において選手キャラクタを所有し、当該選手キャラクタを用いてゲーム内で他のユーザと仮想的に試合(対戦)を行うことができる野球ゲームを例に挙げる。
ユーザが所有する選手キャラクタは、当該選手キャラクタの形態を端末装置3の画面上で視認可能としたカード形式とすることができる。すなわち、選手キャラクタは、デジタル選手カードとしてゲームサーバ1で管理されるとともに、ユーザの端末装置3の画面に表示される。図14には、ユーザの端末装置3の画面に表示される選手カード71を例示しており、選手キャラクタの形態およびその能力の高さなどを表記したデジタル選手カードとして画面上に表示される。図14の例では、キャラクタの能力の高さを星印の数により視覚的に分かり易く示している(例えば能力が高いほど星印の数を多くしている)。本実施の形態では、例えば、実在の野球選手を模写した実在選手キャラクタと、オリジナル選手キャラクタという2種類の選手カードを使用する。ユーザは、ゲームを進行させながら、実在選手キャラクタの選手カードを集めたり、強化モードでオリジナル選手キャラクタの能力を強化したりして、実在選手キャラクタとオリジナル選手キャラクタとからなる自分だけのオリジナルチームを結成し、他のユーザと対戦したりランキングを競ったりすることができる。また、後述するように、現実世界の野球の試合とリアルタイム連動させて初期状態キャラクタに能力情報を付加して育成することもでき、育成後のキャラクタはユーザ自身のオリジナル選手キャラクタとして登録される。また、ユーザは、集めた実在選手キャラクタのカード同士を合成することによって実在選手キャラクタの能力を向上させることもできる。このように、ユーザは、ゲーム内の様々なプレイモードで選手キャラクタを育成・強化してより強いチーム作りを目指してゲームを楽しむことができるようになっている。
このような野球ゲームにおいて、各ユーザのゲーム情報を管理するゲーム情報管理手段51は、図5に示すように、ユーザ情報記憶制御手段51a、レベル情報記憶制御手段51b、所有選手カード記憶制御手段51c(キャラクタ記憶制御手段)、所有ポイント記憶制御手段51d、所有コイン記憶制御手段51e、所有アイテム記憶制御手段51f、対戦結果記憶制御手段51g、ランキング記憶制御手段51hおよび初期状態キャラクタ記憶制御手段51iなどを備えている。図6には、ゲーム情報管理手段51の各記憶制御手段51a〜51iがデータベースサーバ2に記憶して管理する、各ユーザのゲーム情報の一例(この例ではユーザID=“000001”の1人分のゲーム情報)を示している。また、図7Aおよび図7Bには、初期状態キャラクタ記憶制御手段51iがデータベースサーバ2に記憶する、各ユーザの初期状態キャラクタの情報を示している。
図6に示すように、ユーザ情報記憶制御手段51aは、各ユーザを一意に識別するユーザIDと対応付けて、ログインID、パスワード、ユーザ名(ゲーム内で使用するニックネーム等)、チーム名等の各ユーザに関するユーザ情報を、ユーザID毎にデータベースサーバ2の所定の記憶領域に記憶する。ここで、ログインIDおよびパスワードは、各ユーザが端末装置3を操作してゲームサーバ1にアクセスしたときのログイン認証に用いられる。ユーザ名およびチーム名は、ユーザがゲームサービスを受けるための会員登録をした際や、ゲームを初めて実行した際に、ユーザが自ら設定した任意の情報である。ユーザ名およびチーム名は、必要に応じてゲーム画面に表示される。
レベル情報記憶制御手段51bは、ユーザIDと対応付けて、ゲームレベルとしてのユーザのレベルや所属リーグのレベル等のレベル情報を、ユーザID毎にデータベースサーバ2の所定の記憶領域に記憶する。本野球ゲームでは、例えば、ユーザがゲームを進行させることにより経験値が蓄積され、当該経験値が一定量に達することによりユーザのレベルがアップするようになっている。また、本野球ゲームでは、例えば、複数の異なるレベルのゲーム内リーグが存在し、各ユーザのチームが何れかのゲーム内リーグに所属して、同リーグの他のユーザのチームと自動で試合(ゲーム内リーグ戦)を行うようになっている。また、このゲーム内リーグ戦の成績に応じて、異なるゲーム内リーグに所属するユーザのチーム同士の入替戦が自動で実行され、ユーザのチームが所属するゲーム内リーグのレベルが変化するようになっている。レベル情報記憶制御手段51bは、このユーザのレベルや所属リーグのレベルを、ユーザIDと対応付けて記憶する。
所有選手カード記憶制御手段51cは、ユーザIDと対応付けて、ゲーム内でユーザが入手して所有している選手カード(キャラクタ)の情報を、ユーザID毎にデータベースサーバ2の所定の記憶領域に記憶する。この選手カードの情報の例としては、選手カードを一意に識別するための識別情報(選手カードID)、選手の能力の高さを示す能力値およびレギュラー選手フラグなどがある。
図6では、4つの能力項目(能力1〜4)に対して選手の能力値を設定できる例を示している。能力項目の例としては、選手カードが野手の場合は、能力1〜4を「パワー」、「ミート」、「走力」、「守備」等とすることができ、また選手カードが投手の場合は、能力1〜3を「球威」、「制球」、「変化」、「スタミナ」等とすることができる。能力項目はこの例に限らず、増減可能である。レギュラー選手フラグとは、ユーザが所有している選手カードのうち、他のユーザのチームとの試合に出場する一軍のレギュラー選手カード(ユーザのチームオーダーに組み込まれた選手カード)であるか、それともレギュラー以外の控え選手カードであるかを判別するフラグであり、これが「1」のときレギュラー選手カードとして登録されていることを示す。ユーザは、端末装置3を操作することにより、所有している選手カードからレギュラーを選択したり、チームオーダーを設定したりすることができるようになっている。
また、データベースサーバ2には、選手カードIDと対応付けられて、選手カードの画像データ、選手名、ポジション、所属球団、能力値(合成により強化されていない初期値)、およびレア度などが記憶された選手カードデータベースが存在する。そして、ゲーム情報管理手段51は、所有選手カード記憶制御手段51cが記憶している選手カードIDに基づいて、当該選手カードIDに対応する選手カードの画像データ等を選手カードデータベースから取得できるようになっている。
また、各ユーザがゲーム内で所有することができる選手カードの保有数には上限を設けられており、ゲーム情報管理手段51は、各ユーザの選手カードの保有数が上限を超えないように管理している。選手カードの保有数の上限は、例えば40枚、60枚、100枚等、任意に設定することができる。
所有ポイント記憶制御手段51dは、ユーザIDと対応付けて、ゲーム内でユーザが入手して所有している各種ポイント(ポイントに準ずる値などを含む)を、ユーザID毎にデータベースサーバ2の所定の記憶領域に記憶する。本ゲームにおいては、様々なゲームモードが存在し、ゲームモードに応じて様々なポイントを獲得したり、獲得したポイントを使用したりできるようになっている。
図6に示すように、ポイントの例としては、上述の経験値の他、体力ポイント、コスト、強化ポイント、抽選ポイントなどがある。体力ポイントは、当該体力ポイントを消費しながら選手カードのキャラクタが練習を行うという「練習モード」で使用される。コストは、他のユーザを指定して個別対戦の試合を行う「対戦モード」で使用されるものであり、対戦に必要なコスト(ポイント)という位置付けで、当該個別対戦を行うことにより消費される。なお、コストは、対戦中の攻撃に必要な攻撃コストと対戦中の防御に必要な防御コストとに分けてもよい。例えば、ゲーム中に消費されて減った体力ポイントやコストは、時間の経過により回復する(例えば、3分経過する毎に1ポイントずつ回復する)ようにしたり、前記経験値が一定量に達してユーザのレベルがアップすることにより回復するようにしたりできる。
また、前記の強化ポイントは、ユーザが所有する実在選手キャラクタのカード同士を合成することによって実在選手キャラクタの能力を向上させる「合成モード」で使用されるものであり、当該合成を行うことにより消費される。この強化ポイントは、例えば練習モードの実行や対戦モードの実行等によって獲得できるようにすることができる。
また、前記抽選ポイントは、ユーザが他のユーザ(特に仲間ユーザ)と交流(メッセージ送信等)を行うことによって獲得できるポイントである。また、抽選ポイントは、例えば練習モードの実行や対戦モードの実行等によっても獲得できるようにすることができる。この抽選ポイントは、例えば、ゲームサーバ1が管理している全ての実在選手キャラクタの中から乱数等に基づく抽選で所定枚数(例えば1枚)の実在選手キャラクタのカードを獲得できる「抽選モード」で使用可能であり、所定の抽選ポイントにつき1回の選手カード抽選を受けることができる。
所有コイン記憶制御手段51eは、ユーザIDと対応付けて、ゲーム内でユーザが所有しているコイン(前記ポイントとは別のゲーム内通貨)を、ユーザID毎にデータベースサーバ2の所定の記憶領域に記憶する。このコインは、例えば、課金対象のアイテムを獲得する等の際に必要となるものである。
所有アイテム記憶制御手段51fは、ユーザIDと対応付けて、ゲーム内でユーザが入手したアイテムを、ユーザID毎にデータベースサーバ2の所定の記憶領域に記憶する。図6に示すように、アイテムの例としては、回復アイテム、パズルカードのピース、フェイクカードなどがある。回復アイテムは、ゲーム中に消費して減った前述の体力ポイントおよび/またはコストを、時間の経過を待たずに一瞬で最大値まで回復させるアイテムである。例えば、回復アイテムは、前記コインを消費して購入したり、ゲーム内で所定のボーナス条件を満たしたりすることにより獲得できる。
パズルカードのピースは、所定数のピース(例えばP1〜P6の6つのピース)を全部集めてパズルカードを完成させることで強力な(能力値の高い)選手カードを入手することができるアイテムである。例えば、パズルカードのピースは、前記練習モードの実行時に乱数等に基づく抽選で当選した場合に獲得でき、また前記対戦モードで他のユーザが所有しているピースを狙って対戦して勝利した場合に、当該対戦相手のユーザから奪取できる。
フェイクカードは、前記パズルカードのピースにセットしておくことにより、前記対戦モードの対戦で他のユーザに負けても、狙われたピースを一度だけ奪取されないようにできるアイテムである。例えば、フェイクカードは、前記コインを消費して購入したり、ゲーム内で所定のボーナス条件を満たしたりすることにより獲得できる。
なお、ユーザがゲーム内で獲得して所有できるアイテムは、これらに限定されるものではなく、例えば、対戦に勝利したとき等に獲得できる宝アイテム、武器や防具等のキャラクタへの装備品、色々な効果・演出を発生させる魔法アイテムや特殊アイテム、その他の様々なアイテムを所有できるものとしてもよい。
対戦結果記憶制御手段51gは、ユーザIDと対応付けて、ユーザのチームが他のユーザのチームと対戦した結果を一意に特定するための対戦IDを、ユーザID毎にデータベースサーバ2の所定の記憶領域に記憶する。ここで、対戦IDにより一意に特定される対戦は、ユーザが対戦相手を指定して行う個別対戦、およびゲームサーバ1により自動で行われるゲーム内リーグ戦を含む。
また、データベースサーバ2は、対戦IDと対応付けられて、ゲーム内で行われた対戦日時、勝利したチームのユーザID、敗北したチームのユーザID、対戦スコア、勝利投手キャラクタ、敗戦投手キャラクタ、本塁打を打った選手キャラクタ、対戦寸評情報などの対戦結果に関する情報が記憶された対戦データベースを備えている。そして、ゲーム情報管理手段51は、対戦結果記憶制御手段51gが記憶している対戦IDに基づいて、当該対戦IDに対応する対戦結果に関する情報を、対戦データベースから取得できるようになっている。
ランキング記憶制御手段51hは、ユーザIDと対応付けて、前記ゲーム内リーグ戦におけるユーザのチームの勝利数および敗戦数、ならびに勝利数・敗戦数に基づく所属リーグ内の順位などのランキング情報を、ユーザID毎にデータベースサーバ2の所定の記憶領域に記憶する。
次に、図5に示す初期状態キャラクタ記憶制御手段51iについて説明する。初期状態キャラクタ記憶制御手段51iが記憶する初期状態キャラクタは、属性が設定されていない又は所定の初期属性のみが設定されている初期状態のキャラクタである。本実施の形態の初期状態キャラクタは、前記能力1〜4の能力項目がいずれも設定されていない、又は所定の初期能力(例えば、前記能力1〜4の各能力値として「10」)のみが設定されている。そして、本実施の形態のゲームには「リアルタイム連動育成モード」が搭載されており、ユーザは、現実世界の野球の試合中に発生するヒット等の現実事象に応じた能力値を、初期状態キャラクタに反映させてキャラクタを育成可能である。図7Aに示すように、初期状態キャラクタ記憶制御手段51iは、ユーザのユーザIDと対応付けて、初期状態キャラクタの情報(キャラクタID、能力1〜能力4等)を、データベースサーバ2(記憶装置)に記憶する。図7Aの例では、能力が設定されていないブランク(白紙状態)のキャラクタが初期状態キャラクタとして記憶されている。リアルタイム連動育成モード中のユーザの反映操作に従って、後述する反映手段59が初期状態キャラクタにヒット等の現実事象に応じた能力情報を反映させる能力反映処理を実行する。この能力反映処理により、例えば図7Bに示すように、初期状態キャラクタ記憶制御手段51iは、初期状態キャラクタの能力値を更新するように制御する。
次に、図4に示すゲーム進行手段52について説明する。ゲーム進行手段52は、ユーザによる端末装置3に対する操作に応じてゲームを実行し、当該実行結果に応じたゲーム画面データを生成してこれを端末装置3に送信し、端末装置3にユーザの操作に応じたゲーム画面を表示させることによってゲームを進行させる機能を有する。図4に示すように、このゲーム進行手段52は、ゲーム実行手段52aと、ゲーム画面生成手段52bと、ゲーム画面送信手段52cとを備えている。
ユーザの端末装置3のウェブブラウザによってゲーム画面が表示されているとき、ユーザがゲーム画面上の選択可能なボタンオブジェクトやハイパーリンクが設定された文字列等を選択する操作を行った場合、当該操作に応じたゲーム画面のリクエストが端末装置3のウェブブラウザによってゲームサーバ1へ送信される。このリクエストを受信したゲームサーバ1では、ゲーム実行手段52aが、当該リクエストに応じてユーザのゲーム情報を読み出して演算やデータ処理を行うことによってゲームを実行する。
例えば、対戦モードで他のユーザのチームと対戦するという操作がユーザによって行われた場合を例に挙げると、ゲーム実行手段52aは、対戦を行う両ユーザのユーザIDに対応した両チームの選手カード情報(試合に出場するレギュラー選手の選手カード情報)をデータベースサーバ2から読み出す。そして、ゲーム実行手段52aは、両チームの選手カードの能力値等に基づいて、勝敗を決定する演算を行う。この勝敗決定の演算の例としては、単純に両チームの選手カードの能力値の合計が高い方を勝利チームとしてもよいし、能力値の合計が高い方のチームが勝利する確率を高くして勝利チームを確率演算により求めてもよい。
ゲーム画面生成手段52bは、ゲーム実行手段52aによる実行結果に応じて、例えばHTMLデータからなるゲーム画面データを生成する。HTMLデータには、データベースサーバ2から読み出された選手カード等の画像データを含めてもよい。また、HTMLデータには、端末装置3のウェブブラウザのプラグインによって動作するスクリプト(プログラム)が埋め込まれていてもよい。ゲームサーバ1から提供されたスクリプトが端末装置3で実行される場合は、端末装置3で表示されるゲーム画面を動画とすることも可能である。
ゲーム画面送信手段52cは、ゲーム画面生成手段52bにより生成されたゲーム画面データ(HTMLデータ等)を、ゲーム画面のリクエストに対するレスポンスとしてユーザの端末装置3へ送信する。このゲーム画面データを受信したユーザの端末装置3では、ウェブブラウザによって表示部35にゲーム画面が表示される。
次に、認証手段53について説明する。認証手段53は、ゲームサービスを受けようとするユーザが端末装置3を操作してゲームサーバ1にアクセス(ログイン)しようとした際、当該ユーザのゲーム参加資格の有無を判断してログイン認証を行う。この認証の例としては、ユーザIDと対応付けられたログインIDおよびパスワードに基づく認証がある。例えば、ユーザが初めてゲームサービスを利用するときに、会員情報としてログインID(任意の英数文字やメールアドレス等)およびパスワードをゲームサーバ1に登録する。そして、次回からのゲームサーバ1へのログイン時には、ユーザが端末装置3を操作してログインIDおよびパスワードをゲームサーバ1へ送信する。このとき、ゲームサーバ1の認証手段53が、ユーザの端末装置3から受信したログインIDおよびパスワードの組み合わせが登録済みであるか否かを判断し、ログイン認証を行う。
また、SNSのシステムに本ゲームシステムを組み込む場合、SNSの会員登録情報(ログインIDおよびパスワード)をそのまま本ゲームシステムのゲームサービスを受けるための利用登録情報としてもよい。例えば、ユーザの端末装置3がSNSサーバにログインしている状態で、ゲームサーバ1が管理するゲームサイトに最初にアクセスした際、SNSサーバからゲームサーバ1へ自動的にユーザのログインIDおよびパスワードが転送され、これによってユーザが改めてログインIDおよびパスワードを登録することなくゲームサービスの利用登録ができるようにしてもよい。
また、ユーザがゲームサーバ1にアクセスする度にログインIDおよびパスワードを入力する手間を省略できるように、端末装置3である携帯電話やスマートフォンの個体識別番号(電話番号とは別の端末を一意に識別するための情報)、または契約者固有ID(端末の契約者を一意に識別するための情報であって、機種変更を行っても契約者が同一である限りは変更されないID)を利用した認証を行ってもよい。すなわち、ユーザが端末装置3を操作して会員登録した際に、当該端末装置3から送信されてくるデータに含まれる個体識別番号または契約者固有IDをゲームサーバ1が取得し、ログインIDおよびパスワードとともに、当該個体識別番号または契約者固有IDもユーザIDと対応付けてデータベースサーバ2に記憶しておくのである。そして、認証手段53は、端末装置3からアクセス要求を受けた際には、個体識別番号または契約者固有IDが登録済みであるか否かを判断してログイン認証を行う。これにより、ゲームサーバ1へのアクセス時には、ユーザはログインIDおよびパスワードの入力を省略してログインすることが可能となる。
また、ユーザがゲームサーバ1にアクセスする度にログインIDおよびパスワードを入力する手間を省略できる別の方法としては、HTTP cookieの情報(以下、Cookieと称する)を利用する方法もある。すなわち、ユーザが端末装置3を操作して会員登録した際に、ゲームサーバ1がログインIDおよびパスワードに対応した個体識別情報を発行してデータベースサーバ2へ登録するとともに、当該個体識別情報をCookieとして端末装置3へ送信する。このとき、端末装置3のブラウザは、受信したCookieを端末装置3内へ記憶する。次回からのゲームサーバ1へのアクセスの際には、端末装置3のブラウザがページ閲覧要求とともにCookieをゲームサーバ1へ送信するので、認証手段53は、端末装置3からアクセス要求を受けた際には、Cookieの個体識別情報が登録済みであるか否かを判断してログイン認証を行うことができる。
次に、仲間管理手段54について説明する。仲間管理手段54は、仲間関係が成立している2人のユーザを関係付けた仲間情報をデータベースサーバ2(記憶装置)に記憶する仲間情報記憶制御手段54aを備えている。あるユーザが他のユーザと仲間関係を構築するための一形態としては、2人のユーザの何れか一方が、他方のユーザに対してゲームサーバ1を介して仲間申請を行い、当該仲間申請を受けたユーザがゲームサーバ1を介して仲間になることを承認するという、両ユーザ間においてなされる仲間申請とその承認の操作が挙げられる。その他の形態としては、既にゲームサービスに登録済みのユーザが、未登録のユーザをゲームに招待し、招待を受けたユーザがゲームサービスに登録した場合に、招待した側とされた側との2人のユーザを仲間同士とする形態もある。図8には、仲間情報記憶制御手段54aがデータベースサーバ2に記憶する仲間情報の一例を示している。
図8に示すように、仲間情報記憶制御手段54aは、ある2人のユーザ間で仲間関係が成立したときに、仲間申請をしたユーザのユーザIDと当該仲間申請を承認したユーザのユーザIDとを関係付けた仲間情報をデータベースサーバ2へ記憶する。そして、仲間管理手段54は、各仲間情報にこれらを一意に識別するための仲間情報IDを付加し、仲間情報IDに基づいて仲間管理を行う。
図8の例では、仲間申請したユーザID=“000001”のユーザAと、それを承認したユーザID=“000002”のユーザBとの2人のユーザを関係付けた仲間情報が、仲間情報ID=“1”の仲間情報としてデータベースサーバ2に登録されている。これにより、ユーザAにとってユーザBは仲間関係にある仲間ユーザであり、ユーザBにとってもユーザAは仲間ユーザとなる。
また、各ユーザは複数の仲間を作ることができ、各ユーザを中心とする仲間グループを構成することが可能である。図8の例では、ユーザID=“000001”のユーザAは、ユーザID=“000005”および“000035”のユーザとも仲間関係を構築している。そして、仲間管理手段54は、各ユーザを中心とする仲間グループに所属する仲間関係にある仲間ユーザの情報をデータベースサーバ2に記憶して、ユーザ毎の仲間管理を行う。
図9(a)には、仲間管理手段54がデータベースサーバ2に記憶している仲間情報等に基づいて管理している、各ユーザの仲間に関する情報の一例を示している。仲間管理手段54の仲間情報記憶制御手段54aは、ユーザIDと対応付けて、仲間数の上限の情報、すでに仲間の関係になっている仲間ユーザのユーザID、仲間申請中のユーザのユーザID、および仲間申請を受けているが未承認のユーザのユーザIDなどの仲間に関する情報を、ユーザID毎にデータベースサーバ2の所定の記憶領域に記憶する。図9(a)の例では、ユーザID=“000001”のユーザ1人分の仲間に関する情報を示しており、仲間数の上限は45人、当該ユーザの仲間ユーザは10人、仲間申請中のユーザは1人、仲間申請を受けているが未承認のユーザは0人である。
本実施の形態の野球ゲームでは、仲間をつくることによって、仲間関係になった両ユーザにボーナスが付与される(例えば、前記体力ポイントやコストの最大値を所定ポイントだけ増加させることができる)。また、仲間ユーザと協力して試合をしたり、仲間同士で選手カードのプレゼントや応援を行ったりすることで、ゲームを有利に進めることができるゲーム仕様となっている。このようにゲーム内で仲間をつくることによるメリットをユーザに付与することにより、仲間を作ることを促進している。
但し、各ユーザが他のユーザと仲間関係を構築することができる仲間数には上限を設定することができる。仲間数の上限としては、各ユーザに共通の1つの上限(例えば、50人)を設けることができる。あるいは、各ユーザのゲームの進行度合いに応じて、仲間数の上限が所定範囲(例えば10人〜99人の範囲)で変動するようにしてもよい。本実施の形態では、仲間数の上限が10人〜99人の範囲で変動し、ユーザのレベルが高くなるほど、仲間数の上限が大きくなるようにしている。これにより、ユーザは、より多くの仲間を作ってゲームを有利にするために、ゲームを継続的に進めてレベルアップを図ろうとする動機付けを与えられることになる。仲間情報記憶制御手段54aは、ユーザIDと対応付けて、各ユーザの仲間数の上限を記憶しており、仲間管理手段54が各ユーザの仲間数の上限を管理する。
本実施の形態において、2人のユーザが仲間になるには、両ユーザの何れか一方が、他方のユーザに対してゲームサーバ1を介して仲間申請を行う。この仲間申請の操作例としては、先ず、仲間を作ろうとするユーザが、端末装置3の画面上に仲間候補の対象者をリストアップする操作を行う。このとき、ユーザは、仲間候補のユーザレベルを指定することができる。このユーザによる操作に応じて、ゲームサーバ1が仲間候補の対象者をリストアップした画面データを送信することにより、複数の仲間候補がリストアップされた画面がユーザの端末装置3に表示される。ここで、ユーザは、画面上にリストアップされた対象者のユーザレベルやゲーム内所属リーグレベル等を確認し、仲間にしたいユーザを選択して仲間申請の操作を行う。
例えば、ユーザID=“000001”のユーザAが、ユーザID=“000002”のユーザBに対して仲間申請の操作を行った場合を考える。図9(a)に示すように、この操作に応じてゲームサーバ1の仲間情報記憶制御手段54aは、仲間申請を行ったユーザAのゲーム情報として、当該ユーザAのユーザID=“000001”と対応付けて、被申請者であるユーザBのユーザID=“000002”を、「申請中のユーザID」として記憶する。
さらに、図10(a)に示すように、仲間情報記憶制御手段54aは、被申請者であるユーザBのゲーム情報として、当該ユーザBのユーザID=“000002”と対応付けて、仲間申請を行ったユーザAのユーザID=“000001”を、「未承認のユーザID」として記憶する。そして、ゲームサーバ1は、その後、ユーザBの端末装置3がゲームサーバ1にログインしたときに、ユーザAから仲間申請があった旨を通知する。
そして、仲間申請を受けたユーザBは、ゲームサーバ1から受信したユーザAのユーザレベルやゲーム内所属リーグレベル等の情報を、端末装置3の画面上で確認し、仲間として承認するか拒否するかを選択する操作を行う。ここで、ユーザBが仲間として承認する操作を行った場合、この操作に応じてゲームサーバ1の仲間管理手段54は、ユーザAとユーザBとの仲間関係を成立させ、図8に示すように両ユーザA・BのユーザIDを関係付けた仲間情報をデータベースサーバ2に登録する。そして、仲間情報記憶制御手段54aは、図9(b)に示すように、ユーザAのゲーム情報として、当該ユーザAのユーザID=“000001”と対応付けて、ユーザBのユーザID=“000002”を、「仲間ユーザID」として記憶し、「申請中のユーザID」からユーザBのユーザIDを削除する。
さらに、図10(b)に示すように、仲間情報記憶制御手段54aは、ユーザBのユーザID=“000002”と対応付けて、ユーザAのユーザID=“000001”を、「仲間ユーザID」として記憶し、「未承認のユーザID」からユーザAのユーザIDを削除する。そして、ゲームサーバ1は、その後、ユーザAの端末装置3がゲームサーバ1にログインしたときに、ユーザBから仲間の承認があった旨を通知する。
次に、現実事象受付手段55について説明する。現実事象受付手段55は、リアルタイム連動育成モードにおいて、現実世界の野球の試合で発生する現実事象に関する情報を受け付ける。つまり、現実事象受付手段55は、現実世界で発生した現実事象の情報をゲームサーバ1に取り込む機能を有する。この現実事象受付手段55は、基本的に、現実世界の野球の試合で現実事象が発生する毎に、現実事象に関する情報を受け付ける。
ここで、現実事象の例を示す。攻撃側の現実事象としては、ヒット(単打、二塁打、三塁打、本塁打)、四死球、犠打、先制打、同点打、逆転打、勝ち越し打、1得点/イニング、2得点/イニング、3得点/イニング、4得点以上/イニング、3安打/選手、4安打/選手、5安打以上/選手、サイクルヒット/選手、盗塁、三振、併殺打などがある。また、守備側の現実事象としては、奪三振、ダブルプレイ、トリプルプレイ、アウト獲得、無失点/イニング、エラー、投手暴投などがある。また、試合結果の現実事象としては、勝利、引き分け、敗北、さよなら勝利、完全試合、ノーヒットノーラン、完封、完投などがある。その他の現実事象としては、試合開始、イニングの表終了、イニングの裏終了(イニング終了)、試合終了などがある。
ゲーム内で適用する現実事象を何にするかは、任意に設定することができる。例えば、現実事象として例示した上述の全ての事象を、ゲーム内で適用する現実事象としてもよいし、そのうちの一部だけをゲーム内で適用する現実事象としてもよい。
現実事象受付手段55は、例えば、キーボードやマウス等の入力装置17を介したオペレータの手動操作による現実事象に関する情報の入力を受け付ける。または、現実事象受付手段55は、ゲームサーバ1とは別のコンピュータ等で入力された現実事象に関する情報を、通信制御部15を介して受信することにより、現実事象に関する情報を受け付ける。または、現実事象受付手段55は、現実世界の野球の試合で発生する事象の情報を提供するサーバからの情報を、通信制御部15を介して受信することにより、現実事象に関する情報を受け付ける。野球の試合でだれが本塁打を打ったか等の情報を、1球毎、イニングの表裏終了毎またはイニング終了毎に提供するような情報提供サーバは数多く存在するので、そのような情報提供サーバの提供情報を利用して、現実事象に関する情報をゲームサーバ1に取り込むことができる。現実事象には、各現実事象を一意に識別するための事象IDが定められており、データベースサーバ2には、現実事象と事象IDとを対応付けた情報が記憶されている。そして、ゲームサーバ1に取り込まれた現実事象は、事象IDにより管理される。
次に、操作受付手段56について説明する。操作受付手段56は、現実事象受付手段55によって受け付けられた現実事象に対して所定の受付期間を設定し、当該受付期間中における端末装置3での操作に関する操作情報を受け付ける機能を有する。ユーザは、操作受付手段56によって設定された受付期間中に、現実事象に応じた能力情報(属性情報)を初期状態キャラクタに反映させるための反映操作を行うことができる。操作受付手段56は、例えば、ヒット等の現実事象が発生する毎に、当該現実事象に対する受付期間を設定することができる。または、イニングの表の中または裏の中で発生したヒット等の現実事象に対しては、そのイニングの表または裏の終了後にまとめて受付期間を設定してもよい。または、イニング中に発生した現実事象に対しては、そのイニングの終了後にまとめて受付期間を設定してもよい。または、現実世界の野球の試合開始から所定時間(例えば15分)経過する毎に、その間に発生した現実事象に対してまとめて受付期間を設定してもよい。これらは一例であり、現実世界で発生した現実事象に対しては任意のタイミングで受付期間を開始することができる。
また、受付期間は、例えば、1分間、3分間、5分間等の所定長の期間とすることができる。または、受付期間を、次の現実事象が発生するまでとしたり、次のイニングの開始までとしたり、次のイニングが終了するまでとするなど、所定長以外の期間としてもよい。
ヒット等の現実事象が発生する毎に当該現実事象に対する受付期間を開始したり、イニングの終了毎に、そのイニングで発生した現実事象に対する受付期間を開始したりする場合、操作受付手段56は、受付期間開始の契機となる現実事象の発生を基準として、受付期間を開始する。受付期間の開始タイミングは、端末装置3での操作により初期状態キャラクタの属性を変化させることを可能とするゲーム中でのタイミングである。すなわち、現実事象には、初期状態キャラクタの属性を変化させることを可能とするゲーム中でのタイミングを規定する基準の事象(これを「基準事象」と呼称する)を含めることができる。
つまり、現実事象には、キャラクタに能力情報(属性情報)を反映させるための対象の事象(これを「対象事象」と呼称する)と、キャラクタの属性を変化させることを可能とするゲーム中でのタイミングを規定する基準事象とを含めることができる。ここで、対象事象と基準事象との関係は、ある現実事象が対象事象であれば基準事象ではなく、基準事象であれば対象事象ではないというような相互に独立した関係にあるわけではなく、ある現実事象(例えばヒット)が、対象事象でもあり且つ基準事象でもあるという関係も成り立つものである。
操作受付手段56は、基準事象が発生したとき(現実事象受付手段55が、当該基準事象として定められた現実事象を受け付けたとき)、その1つ前の基準事象後に発生した現実事象に対する受付期間を開始する。すなわち、操作受付手段56は、現実世界の野球の試合で発生する現実事象を、基準事象として定められた現実事象の発生によって区切って、受付期間を開始するのである。
例えば、現実世界の野球の試合でのヒット(単打、二塁打、三塁打、本塁打)、四死球、犠打、盗塁等を現実事象(=対象事象)とし、それら全てを基準事象でもあるとして定めた場合、個々のヒット等の現実事象が発生する毎に、それに対する受付期間が開始される。例えばヒット(=基準事象)が発生したとき、当該基準事象の1つ前の基準事象後に発生した現実事象とは、当該ヒットだけであり、操作受付手段56は、当該ヒットの発生後に、当該ヒットに対して受付期間を開始する。この場合、受付期間の終了(終期)を次の現実事象が発生するまでとすることができる。このように受付期間の終期を定めることにより、複数の受付期間が時間的に重複することがなくなる。これにより、ゲームサーバ1側の受付期間の管理が複雑化することを回避できるとともに、ユーザ側の反映操作も単純化できる(もしも複数の受付期間が時間的に重複する場合、どの受付期間に対する反映操作を行うのかを端末装置3側で選択する等の手間が必要になるが、受付期間の時間的な重複がなければそのような手間を省くことができる)。
また、個々の現実事象(ヒット等)が発生してもすぐに受付期間を開始するのではなく、イニング終了を待って、当該イニング中に発生した現実事象に対してまとめて受付期間を開始する場合、イニング終了という現実事象が基準事象となり、イニング終了以外のヒット等の現実事象については基準事象ではない対象事象となる。例えば、第3イニング終了(=基準事象)が発生したとき、当該基準事象の1つ前の基準事象(第2イニング終了)後に発生した現実事象として、例えば、ヒットや盗塁等があった場合、操作受付手段は、当該ヒットや盗塁等に対して受付期間を開始する。要するに、第3イニング中に発生した個々の現実事象に対する受付は、すべてイニング終了時から開始するのである。
ところで、野球の試合でのイニング(回)は、「表」と「裏」の2つから構成され、第2イニング終了(第2イニングの裏終了)後は、第3イニングとなる。よって、第2イニング終了後から第3イニング終了までとは、第3イニング全体の期間を含む。なお、厳密に言えば、第2イニング終了後から第3イニング終了までの期間中には、表裏の間(攻守交代のために選手が守備位置に移動等するための期間)という野球の試合進行が中断された期間を含むが、この表裏の間にはヒット等が発生し得ないので、表裏の間をイニングから排除して考えなくとも特に問題はない。
そして、受付期間中に端末装置3にて反映操作が行われれば、イニング中に発生したヒット等の現実事象(=対象事象)に応じた能力情報が初期状態キャラクタに反映される。
このように、現実事象の全部を基準事象としてもよいし、現実事象の一部を基準事象としてもよい。
なお、現実世界の野球の試合開始から15分経過する毎に、その間に発生した現実事象に対してまとめて受付期間を設定するのであれば、操作受付手段56は、野球の試合開始時間を基準として15分毎に受付期間を開始することができる。よって、受付期間開始の契機となる基準事象を定めることなく受付期間を開始することも可能である。但し、基準事象を用いないで受付期間を開始する場合、ユーザが野球の試合を視聴せずとも受付期間の開始(すなわち、反映操作をすべきタイミング)が分かってしまう。これでは野球の試合を視聴しながら反映操作をしてキャラクタを成長させるというゲームの楽しみ方を最大限に生かせない。よって、野球の試合の開始後、いつ発生するか分からない基準事象、例えば野球ゲームの場合であれば、イニング終了やヒット、ホームラン等を基準にして受付期間を開始することが望ましい。特に、ヒットやホームラン等については事前に予想することは不可能であるので、より継続的な視聴が必要となる。これにより、現実世界の野球の試合をリアルタイムで視聴しながらゲームをプレイする方向にユーザを導くことができる。
本実施の形態では、イニング終了を基準事象とし、各イニング中に発生した現実事象に対しては、各イニングの終了直後にまとめて受付期間を開始する例について以下に説明する。また、その受付期間の終了(終期)は、次のイニング終了までとして、複数の受付期間が時間的に重複しないようにする。例えば、現実世界の野球の試合で、1回表裏の攻撃が終わって第1イニングが終了した場合、第1イニング終了の情報がゲームサーバ1に入力されてから受付期間が開始となり、その後2回表裏の攻撃が終わって第2イニング終了の情報がゲームサーバ1に入力されるまでが、第1イニングに対する受付期間となる。なお、最後のイニング(延長戦でない場合第9イニング)に対する受付期間は、次のイニングの終了までとできないので、最後のイニング終了の入力から5分間を受付期間とする。
後述するように、ユーザは、この受付期間中に自分の端末装置3で反映操作を行わなければ、イニング中の現実事象に応じた能力情報を、初期状態キャラクタに付加する機会を逸することになる。ユーザが端末装置3で行う反映操作としては、図16または図18に例示するように、リアルタイム連動育成モード中の画面に表示される「反映」ボタン92を押すだけの簡単な操作が挙げられる。図16および図18の画面の詳細については後述する。
次に、関係情報記憶制御手段57について説明する。関係情報記憶制御手段57は、現実事象に対応する端末装置3での操作と、当該操作に基づく前記初期状態キャラクタに反映させる能力情報(属性情報)との関係情報を予めデータベースサーバ2(記憶装置)に記憶する。図11Aおよび図11Bに、関係情報記憶制御手段57がデータベースサーバ2に記憶する関係情報の例を示す。図11Aは、攻撃側の「現実事象」と「能力情報」との関係情報であり、図11Bは、守備側の「現実事象」等と「能力情報」との関係情報である。なお、ここで言う「現実事象」と「能力情報」との関係情報とは、正確には、「現実事象」に対応する端末装置3での反映操作と、当該反映操作に基づきキャラクタに反映させる「能力情報」との関係情報のことである。
図11Aおよび図11Bに示すように、関係情報には、初期状態キャラクタにゲーム上有利となる能力情報(以下、「プラスの能力情報」と呼称する)を反映させるための現実事象と、プラスの能力情報との対応関係が記憶されている。プラスの能力を反映させるための対象事象としては、単打、二塁打、三塁打、本塁打等があり、現実世界の選手の活躍内容によって、初期状態キャラクタに反映させる能力情報も異なっている。図11Aの例では、単打には「+10」、二塁打には「+20」、三塁打には「+50」、本塁打には「+100」の能力情報がそれぞれ対応付けられている。よって、単打よりも本塁打の方が10倍の能力情報が初期状態キャラクタに反映されることになる。ここで、能力情報の「+10」とは、本実施の形態では初期状態キャラクタの能力1〜能力4のそれぞれに能力値「10」を加算することとする。
なお、現実世界の実在選手の活躍内容によっては、初期状態キャラクタに、能力1〜能力4以外の特殊能力が付加されるようにしてもよい。例えば、本塁打、5安打以上/選手、サイクルヒット/選手、トリプルプレイ、完全試合、ノーヒットノーラン、完封などの大活躍の現実事象に対しては、様々な特殊能力(例えば、満塁の場面でミート能力やパワー能力が向上する特殊能力等)が付加されるように、関係情報に特殊能力の情報を含ませてもよい。
また、図11Bに示すように、本実施の形態では、試合開始、イニング終了、試合終了等の現実事象に対しては、能力情報を0に設定しているが、これらの現実事象にも能力情報(例えば「+5」等)を設定してもよい。
また、図12Aおよび図12Bに例示するように、関係情報には、初期状態キャラクタにゲーム上不利となる能力情報(以下、「マイナスの能力情報」と呼称する)を反映させるための現実事象とマイナスの能力情報との対応関係を含ませることもできる。マイナスの能力を反映させるための現実事象としては、攻撃側では三振、併殺打、送りバント失敗、盗塁失敗などが挙げられ、守備側では守備エラー、投手暴投、ボークなどが挙げられる。また、マイナスの能力を反映させる現実事象の内容によって、初期状態キャラクタに反映させるマイナスの能力情報も異なっている。図12Aの例では、三振には「−10」、併殺打には「−20」のマイナスの能力情報がそれぞれ対応付けられている。このように、関係情報にプラスの能力情報だけではなくマイナスの能力情報も含めた場合、初期状態キャラクタにマイナスの能力を反映させるための現実事象が現実世界で発生した場合、ユーザの反映操作により初期状態キャラクタがマイナス成長することもあり得る。
次に、応援対象登録手段58について説明する。本実施の形態では、現実世界の2つの野球チームが対戦する野球の試合を、リアルタイム連動育成モードの対象としている。この場合、ユーザは、現実世界の2つの野球チームの中の1つを、予め応援対象(反映対象)のチームとして選択して登録することができ、登録した応援対象のチームの現実世界での活躍に応じて、初期状態キャラクタを成長させることができる。すなわち、ユーザが選択して登録した応援対象のチームについての現実事象のみが、初期状態キャラクタの成長に影響を及ぼす。例えば、現実世界でチームAとチームBが対戦する野球の試合の場合であって、ユーザがチームAを応援対象として選択した場合、チームAの実在選手が本塁打を打った場合には初期状態キャラクタを成長させることができるが、チームBの実在選手が本塁打を打っても初期状態キャラクタを成長させることはできない。
ユーザは、遅くとも本ゲームの対象となる現実世界の野球の試合の終了までに、端末装置3にて自分が応援したい又はより活躍すると予想する側の実在チーム(以下、応援チームと称する)を選択して応援対象を登録する操作を行う。応援対象登録手段58は応援チーム登録手段58aを備えており、対象の野球の試合の終了までにユーザの端末装置3にて応援チームを選択する操作が行われた場合に、当該操作の情報を受信して、当該ユーザの応援チームを登録する。例えば、応援チーム登録手段58aは、記憶装置(データベースサーバ2等)の所定領域に、ユーザIDと対応付けて応援チームを記憶する記憶制御を実行する。図23に、応援対象登録手段58が記憶装置に記憶する情報の例を示す。この例では、オールスター第1戦(イベントID=007)のイベントにエントリーしているユーザの応援チーム(対象グループ)および後述の応援選手(対象メンバ)の情報が記憶されている(応援選手を登録しない構成の場合は、応援選手の情報記憶領域を省略できる)。なお、リアルタイム連動育成モードで対象となる現実世界の実在チームや実在選手は、ゲームサーバ1内ではチームIDや選手IDで管理しており、応援対象登録情報としては、ユーザIDと対応付けて応援チームのチームID等が記憶される。
ユーザが端末装置3で行う応援対象を登録する操作としては、図15に例示するリアルタイム連動育成イベント登録画面での簡単なボタン操作が挙げられる。この画面には、現実世界の野球の試合で対戦する2つの実在チームAとBの何れか一方を選択するためのラジオボタンと、「登録」ボタン90が表示されている。ユーザは、ラジオボタンで応援等したい実在チームを選択して「登録」ボタン90を押せば、応援チームを登録でき、リアルタイム連動育成イベントへのエントリーが完了する。もちろん、応援チームの選択は、ラジオボタン以外のリストボック等で出来るようにしてもよい。
次に、反映手段59について説明する。本実施の形態では、野球の試合開始から最初の基準事象(第1イニング終了)の情報が入力されるまでの間(すなわち第1イニング中)に入力された本塁打等の現実事象に応じた能力情報が、最初の基準事象の入力後に設けられる受付期間中の端末装置3での反映操作により、初期状態キャラクタに反映される。また、最初の基準事象(第1イニング終了)の情報が入力されてから2番目の基準事象(第2イニング終了)の情報が入力されるまでの間(すなわち第2イニング中)に入力された対象事象に応じた能力情報が、2番目の基準事象の入力後に設けられる受付期間中のユーザによる反映操作により、初期状態キャラクタに反映される。同様に、n−1番目の基準事象(第n−1イニング終了)の情報が入力されてからn番目の基準事象(第nイニング終了)の情報が入力されるまでの間(すなわち第nイニング中)に入力された対象事象に応じた能力情報が、n番目の基準事象の入力後に設けられる受付期間中のユーザによる反映操作により、初期状態キャラクタに反映される。これを実現する反映手段59は、操作受付手段56が第nイニング終了後の受付期間中にユーザの端末装置3から反映操作の情報を受信することにより、当該第nイニング中に発生した現実事象(応援チームの現実事象)に応じた能力情報を、関係情報に基づいて取得し、取得した能力情報を初期状態キャラクタに反映させる能力反映処理を実行する。
反映手段59は、各イニング中(基準事象間)に入力される現実事象を、記憶装置(RAM13、補助記憶装置14、またはデータベースサーバ2等)の所定領域に記憶する現実事象記憶制御手段59aを備えている。この現実事象記憶制御手段59aが記憶制御する情報の一例を図13に示す。図13には、第3イニング中(第2イニング終了の入力後から第3イニング終了の入力までの間)に現実事象受付手段55によって受け付けられた現実事象を記憶した例を示している。図13に示すように、第3イニングに発生したチームAの現実事象が、単打、本塁打、2得点、先制打、奪三振、アウト獲得、ダブルプレイ、アウト獲得、無失点であった場合、反映手段59の現実事象記憶制御手段59aは、これらの現実事象(事象ID)が入力される毎に記憶装置に記憶する。
なお、攻撃側において先制の2点本塁打を打った場合は、「本塁打」、「先制打」および「2得点」の3つが現実事象に該当する。また、守備側においてダブルプレイでアウトを取って無失点でイニングを終了した場合は、「ダブルプレイ」、「アウト獲得」および「無失点」の3つが現実事象に該当する。このように、複数の現実事象が重なって発生する場合もある。
そして、反映手段59は、図12A及び図12Bに例示する関係情報に基づいて、各現実事象に対応する、反映操作が行われた場合にキャラクタに反映させる能力情報を取得し、併せて記憶する。図13の例では、第3イニングに発生したチームAの現実事象に応じた能力情報の合計値は、10+100+40+10+10+5+50+5+20=+250である。この場合、チームAを応援チームとして登録しているユーザが、第3イニング終了後に設けられる受付期間中に端末装置3で反映操作を行えば、反映手段59は、能力情報「+250」を、当該ユーザの育成対象である初期状態キャラクタに反映させる。これにより、初期状態キャラクタの能力1〜能力4に「+250」が加算され、初期状態キャラクタの情報が加算後の能力に更新される(図7B参照)。
なお、チームAを応援チームとしているユーザが、第3イニング終了後に設けられる受付期間中に反映操作を行わなければ、前記「+250」の能力情報を初期状態キャラクタに反映させることはできない。よって、各イニング後の受付期間中に反映操作を行うユーザと、行わないユーザとでは、初期状態キャラクタの成長度合いに違いが生じる。例えば、図7Bにおいて、ユーザID=“000001”のユーザAおよびユーザID=“000002”のユーザBが、ともにチームAを応援チームとしているとする。ユーザAは第3イニング終了後の受付期間中に反映操作を行ったが、ユーザBは反映操作をし忘れた場合、両者の初期状態キャラクタの能力に250もの差が生じる。
また、図13に示すように、第3イニングに発生したチームBの現実事象が、2つのアウト獲得、エラー、アウト獲得、単打、三振、併殺打であった場合、反映手段59は、これらの各現実事象を記憶するとともに、図12A及び図12Bに例示する関係情報に基づいて、各現実事象に対応する能力情報を取得する。図13の例では、第3イニングに発生したチームBの現実事象に応じた能力情報の合計値は、5+5−50+5+10−10−20=−55である。この場合、チームBを応援チームとして登録しているユーザが、第3イニング終了後に設けられる受付期間中に端末装置3で反映操作を行えば、反映手段59は、第3イニングに発生したチームBの現実事象に応じた能力情報「−55」を、当該ユーザの育成対象である初期状態キャラクタに反映させる。この場合、初期状態キャラクタをマイナス成長させてしまう。
このように、マイナス成長もあり得る構成において、あるイニング中にマイナス成長させるような現実事象が発生した場合、ユーザは、当該イニング終了後の受付期間中にあえて反映操作を行わず、キャラクタのマイナス成長を回避するということも可能である。このように、マイナス成長もあり得る構成では、ユーザが現実世界で発生した現実事象を見極めて、マイナス成長を回避しながら効率よくキャラクタを育成することが要求され、これによりゲーム性を一層高めることができる。
なお、ユーザが現実世界で発生した現実事象に応じて反映操作をするか否かを正確に判断できるように、予め、同様な事象が発生すればプラス成長またはマイナス成長するのかを、ユーザが端末装置3でいつでも確認できるようにすることが望ましい。そこで、例えば図15〜図19等のリアルタイム連動育成モードの画面中に「能力情報一覧」ボタン102が表示されるようにし、ユーザが当該ボタン102を選択する操作を行えば、いつでも図22に例示する能力情報一覧画面が端末装置3に表示されるようにする。すなわち、ゲームサーバ1は、ユーザの端末装置3での「能力情報一覧」ボタン102の操作に応じて、能力情報一覧画面データを端末装置3へ送信する。この能力情報一覧画面中には、全ての現実事象と能力情報との対応関係が記載された表111が表示される。なお、表111が端末装置3の物理的な画面領域よりも大きくなる場合、端末装置3でスクロール操作等をすることにより、当該表111の全てを見ることができる。また、ユーザが能力情報一覧画面中の「戻る」ボタン112を選択すれば、前の画面に戻ることができる。
ところで、キャラクタがプラス成長しかしない構成の場合、図16に例示するように、受付期間中に反映操作等を行うための画面中に、イニング中に発生した現実事象とそれに対応する能力情報93を表示する領域を設け、初期状態キャラクタに反映される能力情報93をユーザに事前に報知するようにしてもよい。一方、プラス成長だけではなく、マイナス成長もあり得る構成においては、図18に例示するように、受付期間中に反映操作等を行うための画面中には、イニング中に発生した現実事象や能力情報を表示させないことが望ましい。この図18の画面において、ユーザが「反映」ボタン92を押せば、例えば図19の画面(キャラクタに能力情報が反映されたことを報知する画面)に遷移し、能力反映後に、イニング中に発生した現実事象とそれに対応する能力情報93をユーザが確認できるようにしてもよい。現実世界の野球の試合を視聴せずにユーザが反映操作を行った場合、図19の画面例のように、キャラクタにマイナスの能力を反映させてしまった後に、それに気づくこともある。
次に、キャラクタ登録手段60について説明する。キャラクタ登録手段60は、ユーザの端末装置3での反映操作に応じて反映手段59が初期状態キャラクタに能力情報を反映させた後のキャラクタを、当該ユーザのキャラクタとして登録する機能を有する。つまり、キャラクタ登録手段60は、能力反映後のキャラクタをユーザの所有とすべく、所有選手キャラクタ記憶制御手段51cを制御する。例えば、ユーザAが反映操作を行って育成したキャラクタは、現実世界の野球の試合の終了後(最後の受付期間中の反映操作の終了後、または最後の受付期間の終了後)、図20に例示する端末装置3の画面でユーザAが「育成終了」ボタン94を押すことにより、ユーザAの所有する選手カードとなる。これにより、例えば、図21に示すように、ユーザの端末装置3の画面には、自分が成長させたキャラクタがカード化された選手カード95および当該キャラクタの能力情報96等が表示される。
現実世界の野球の試合を通してユーザが初期状態から成長させたキャラクタは、言わば、その試合を利用して、あるいは記念して完成させた特別なキャラクタである。例えば、リアルタイム連動育成モードの対象となる現実世界の野球の試合を、プロ野球またはMLBの開幕戦、オールスター戦、日本シリーズの試合、ワールドシリーズの試合という特別な試合とした場合、ユーザは、そのような現実世界の特別な試合を記念して自分が一から作り上げたキャラクタを獲得できる。このような記念のキャラクタは、原則、これ以上成長しないようにすることができる。
なお、ユーザが端末装置3で「育成終了」ボタン94を押す操作をしなくとも、最後の受付期間中の反映操作の終了後、または最後の受付期間の終了後に、キャラクタ登録手段60が自動的に育成後のキャラクタを、ユーザのキャラクタとして登録するように構成してもよい。
〔ゲームシステムの動作〕
上記の構成において、本発明の実施の形態に係るゲームシステムの動作例を、図24のフローチャートを参照しながら以下に説明する。図24は、ユーザが端末装置3を操作してゲームサーバ1にアクセスしてゲームサービスを受けるときの、端末装置3およびゲームサーバ1の処理の流れを示すものである。
ユーザがゲームサービスを受ける場合、先ず、端末装置3の操作入力部40を操作してウェブブラウザを起動する(S11)。その後、ユーザは、ゲームサーバ1が管理するゲームサイトにアクセスする操作を行い、これにより、端末装置3からゲームサーバ1へアクセスリクエストが送信される(S12)。このとき、ゲームサーバ1は、端末装置3からのアクセスに対するログイン認証を行い(S21)、ゲームサービスの利用登録がなされているユーザからのアクセスであることを確認する。その後、ゲームサーバ1は、HTML等で記述されたメイン画面データを端末装置3に送信する(S22)。なお、メイン画面とは別のゲームのトップ画面がある場合は、まずトップ画面を送信してもよい。そして、メイン画面データを受信した端末装置3では、ウェブブラウザが当該データを解釈し、メイン画面を表示部35に表示させる(S13)。
図14に例示するように、メイン画面には、ユーザのチーム名70、ユーザが所有するオリジナルキャラクタの選手カード71の画像、ユーザのゲーム情報72(ユーザのレベル、体力ポイント、強化ポイント、仲間人数、選手カードの数、コスト、抽選ポイント、次のレベルにアップするために必要な経験値など)が表示される。メイン画面はマイページとも称される。また、メイン画面には、「抽選モード」ボタン81、「強化モード」ボタン82、「練習モード」ボタン83、「対戦モード」ボタン84、「合成モード」ボタン85、「リアルタイム連動育成モード」ボタン86等の各モードを選択するためのボタンが表示される。また、仲間に対して、挨拶、メッセージ送信、プレゼントを贈る等の様々な交流を行うための画面に遷移する「交流」ボタン87や、ユーザの手持ち選手カードで一軍のオーダを設定するための画面に遷移する「オーダ」ボタン88などのボタンも表示される。さらに、このメイン画面には、端末装置3の方向キーやタッチパネル等を操作して画面をスクロールさせることによって、図示しないボタン等のオブジェクトや様々な情報が表示されるようになっている。
ここでユーザが、画面に表示されている選択可能なボタン等のオブジェクトやハイパーリンクを選択する操作をすると、当該操作に応じた画面のリクエストが端末装置3からゲームサーバ1へ送信される(S14)。このリクエストを受信したゲームサーバ1は、ユーザの操作に応じた演算処理やデータ処理を行ってゲームを実行し(S23)、実行結果を反映させたゲーム画面データを端末装置3へ送信する(S24)。そして、画面データを受信した端末装置3では、ウェブブラウザが当該データを解釈し、ゲーム画面を表示部35に表示させる(S15)。
以降は、ユーザの端末装置3においては前記のS14およびS15が繰り返され、ゲームサーバ1においては前記のS23およびS24が繰り返され、これにより、端末装置3の画面に表示されている選択可能なボタン等をユーザが選択する度に、端末装置3のゲーム画面が次々と切り替わり、ゲームを進行させることができる。
その後、ユーザが端末装置3を操作してゲーム画面を閉じた場合(S16)、ゲームサーバ1はログアウト処理を行う(S25)。例えば、ユーザがウェブブラウザを閉じた場合、ゲームサーバ1はセッションタイムアウト後にログアウト処理を行う。
ところで、本ゲームシステムにおいては、ユーザがゲームサーバ1からログアウトした場合であっても、ゲームサーバ1側で当該ユーザのゲーム情報を読み出してゲームを進行させることができる。例えば、ログアウトしているユーザのチームに対して、ログインしている他のユーザが対戦(個別対戦)を仕掛けてくることもある。この場合も、ゲームサーバ1のゲーム進行手段52は、ユーザがログインしているか否かに依らずに、各ユーザのゲーム情報をデータベースサーバ2から読み出して対戦を実行し、その実行結果を反映させて各ユーザのゲーム情報を更新する。また、ゲーム内リーグ戦モードでは、ユーザによる端末装置3の操作なしに、ゲームサーバ1のゲーム進行手段52が、各ユーザのゲーム情報をデータベースサーバ2から読み出して、自動でゲーム内リーグ戦の試合を実行する。このように、ユーザがゲームサーバ1からログアウトしているときに実行された対戦の結果は、その後、ユーザがゲームサーバ1にアクセスしたときに画面で確認することができる。
〔ゲーム管理装置の動作〕
次に、本発明の実施の形態に係るゲーム管理装置のより詳細な動作例を、図25等のフローチャートを参照しながら説明する。図25は、ある1人のユーザを対象としたゲームサーバ1の処理の流れを示すものであり、ゲームサーバ1が管理している各々のユーザに対して同様の処理が行われる。
図25に示すように、ゲームサーバ1の認証手段53は、ユーザの端末装置3からアクセス要求を受けたとき(S31でYES)、端末装置3から送信されてきたログインID・パスワード、または携帯電話端末の個体識別番号等に基づいて、アクセスを許可するか否かを判断するログイン認証を行う(S32)。ここで、アクセスを許可しない場合(S32でNO)、ゲームサーバ1は、端末装置3にゲームサービスの利用登録を促す画面データを送信する(S33)。一方、アクセスを許可する場合(S32でYES)、アクセス情報(ログ)を記憶する(S34)。
そして、ゲームサーバ1は、アクセスを許可したユーザの端末装置3に、メイン画面データ(またはトップ画面データ)を送信する(S35)。その後、ユーザの端末装置3から送信されてくるユーザのゲーム操作に応じた画面リクエストを受信すると(S36でYES)、ゲーム実行手段52aは、当該画面リクエストに応じた演算処理やデータ処理を行ってゲームを実行する(S37)。
その後、ゲームサーバ1はゲームの実行によりユーザのゲーム情報を更新する必要があるか否かを判断し(S38)、更新の必要がある場合(S38でYES)、データベースサーバ2に記憶されているユーザのゲーム情報を更新する(S39)。例えば、ユーザのゲーム操作が他のユーザとの個別対戦を行う操作であった場合、当該対戦が実行された結果、試合結果の情報、コスト、強化ポイント、アイテム等のユーザのゲーム情報が更新されることになる。一方、例えば、ユーザのゲーム操作がゲーム内リーグ戦の結果確認の操作であった場合、当該操作に応じたゲームの実行処理としてはゲーム内リーグ戦の結果情報をデータベースサーバ2から読み出すデータ処理だけであって、当該処理の前後でユーザのゲーム情報に変化はなく、よってユーザのゲーム情報を更新する必要はない(S38でNO)。
その後、ゲーム画面生成手段52bがゲームの実行結果を反映させたゲーム画面データを生成し(S40)、ゲーム画面送信手段52cが当該ゲーム画面データをユーザの端末装置3へ送信する(S41)。その後、ユーザの端末装置3がログアウトしたか否かが判断され(S42)、端末装置3がログアウトするまで、前記S36〜S41の処理が繰り返されることで、ゲームが進行していく。
次に、図26ないし図28を参照して、リアルタイム連動育成モード(以下、「連動育成モード」と称す)におけるゲームサーバ1の処理の一例について説明する。
本実施の形態では、ユーザがリアルタイム連動育成モードで初期状態キャラクタを育成する場合、先ず、応援チームを選択してイベント登録を行う。図26のフローチャートは、ゲームサーバ1のイベント登録処理の一例を示す。
例えば、ユーザAが自分の端末装置3で、図14に示すメイン画面の「リアルタイム連動育成モード」ボタン86を選択する操作を行った場合、当該操作の情報が端末装置3からゲームサーバ1へ送信される。「連動育成モード」の選択情報を受信したゲームサーバ1では(S51でYES)、ユーザAが既にイベント登録済みか否かを判断する(S52)。この判断は、応援対象登録手段58が記憶している図23の登録情報の中に、ユーザAのユーザID=“000001”が存在するか否かを検索することにより可能である。ここで、ユーザAのイベント登録がまだ完了していない場合(S52でNO)、ゲームサーバ1は、図15に例示するイベント登録画面データを、ユーザAの端末装置3に送信する(S53)。
このイベント登録画面には、連動育成モードの対象となる野球の試合情報(試合開始時間等)が表示される。また、前述した、応援チームを選択するラジオボタンおよび「登録」ボタン90が表示される。さらに、「リアルタイム連動育成の詳細」ボタン101および「能力情報一覧」ボタン102なども表示される。ユーザが「リアルタイム連動育成の詳細」ボタン101を選択すれば、図示しない詳細表示画面に遷移し、連動育成モードでのプレイ方法を確認することができる。また、ユーザが「能力情報一覧」ボタン102を選択すれば、図22に例示する能力情報一覧画面に遷移し、表111に記載された現実事象および能力情報を確認することができる。「リアルタイム連動育成の詳細」ボタン101および「能力情報一覧」ボタン102は、連動育成モードの他の画面(図15〜図19等)にも表示される。
図15のイベント登録画面で、ユーザAにより応援チームとして例えばチームAが選択されて「登録」ボタン90が押された場合(S54でYES)、図23に示すように応援チーム登録手段58aがユーザAのユーザID(“000001”)と対応付けて、チームA(チームID=01)を応援チームとして登録する(S55)。これにより、イベント登録が完了し、ゲームサーバ1からは図示しないイベント登録完了画面がユーザAの端末装置3へ送信される。なお、イベント登録画面でユーザによりその他の操作が行われた場合は(S56)、ゲームサーバ1において当該操作に応じた処理が実行される(S57)。
イベント登録が完了しているユーザが自分の端末装置3で、図14に示すメイン画面の「リアルタイム連動育成モード」ボタン86を選択した場合(S51でYESおよびS52でYES)、ステップS53以降の登録処理に移行することなく、ゲームサーバ1からは、図16等の連動育成モードの画面データが端末装置3に送信される。
次に、連動育成モードにおけるゲームサーバ1の処理であって、現実世界の野球の試合が開始された後の処理について、図27および図28を参照しながら以下に説明する。図27は野球の試合の第1イニングの能力反映処理の例、図28は第2イニング以降の能力反映処理の例をそれぞれ示すフローチャートである。
図27に示すように、現実世界の野球の試合開始と略同時にゲームサーバ1に試合開始の情報が取り込まれた後(S61でYES)、現実事象受付手段55が現実事象の入力を受け付ける。例えば、第1イニング中にヒット等の現実事象が発生した場合、それを観察しているオペレータの入力操作等により、現実事象に関する情報がリアルタイムでゲームサーバ1に取り込まれ、現実事象受付手段55がそれを受け付ける。反映手段59の現実事象記憶制御手段59aは、最初の基準事象である第1イニング終了の情報が入力されるまで、ヒット等の現実事象が発生する毎に(S62でYES)、現実事象に関する情報を記憶装置に記憶する(S63)。図13に示すように、本実施の形態ではイニング中に発生した現実事象に関する情報が、対戦している2つの実在チーム(チームAとチームB)に分けて記憶される。
第1イニングが実際に終了したとき、第1イニング終了の情報がリアルタイムでゲームサーバ1に取り込まれる(S64でYES)。このとき、反映手段59は、第1イニング中に発生した現実事象に応じた能力情報を、図11Aおよび図11B(または図12Aおよび図12B)に示す関係情報に基づいて取得する(S65)。なお、現実事象に応じた能力情報の取得処理は、ステップS63において現実事象を記憶すると同時に実行してもよい。また、第1イニング終了により、操作受付手段56は、第1イニングで発生した現実事象絵に対する受付期間を開始する(S66)。本実施の形態の場合、第1イニングの受付期間は、第2イニング終了の情報が入力されるまでである。
なお、図27のS61〜S66は、ゲームサーバ1が管理している全てのユーザに共通の処理であり、S67〜S69は、ユーザ毎に実行される処理である。
受付期間中に、イベント登録しているユーザが図14に示すメイン画面の「リアルタイム連動育成モード」ボタン86を押すと、図16または図18に例示する画面(反映操作が可能な画面)が端末装置3に表示される。なお、図16および図18は、第3イニングの画面例であるが、第1イニングでも同様の画面が表示される。この画面には、試合中の得点状況や試合の進捗状況等のリアルタイム情報(図16の例では、チームAが2点、チームBが0点、「4回表チームAの攻撃中」の情報)が表示される。また、「更新」ボタン91を押せば、更新された最新の画面データがゲームサーバ1から端末装置3へ送信される。図16の画面は、反映操作の前に、イニング中に発生した現実事象(ユーザの応援チームの現実事象)とそれに対応する能力情報93が表示される画面例である。第1イニングの受付期間が終了するまでに(S67でNO)、ユーザが「反映」ボタン92を押すと(S68でYES)、反映手段59が、当該ユーザの応援チームの現実事象に応じた第1イニングの能力情報を、当該ユーザの初期状態キャラクタに反映させる(S69)。この能力情報が反映されたキャラクタの最新情報は、初期状態キャラクタ記憶制御手段により更新制御される(図7B参照)。
また、能力反映処理が実行された場合、ゲームサーバ1は、図17に例示するように、キャラクタに能力情報が反映されたことを報知する画面データをユーザの端末装置3へ送信する。図17の画面を含む連動育成モード中の画面(図16〜図19)には、「これまでに反映させた能力」ボタン103が表示され、ユーザが当該ボタン103を押すことにより、その時点までにキャラクタに反映された能力情報を確認できるようになっている。
なお、上述のようにマイナス成長もあり得る構成においては、図16に画面に代えて、図18に例示する画面(イニング中に発生した現実事象や能力情報が事前に表示されない画面)を適用することが望ましい。
一方、ユーザが第1イニングの受付期間が終了するまでに反映操作を行わなかった場合(S67でYES)、当該ユーザの初期状態キャラクタには、第1イニングで発生した現実事象に応じた能力情報は反映されることなく、第1イニングの能力反映処理は終了となる。
ところで、同一の受付期間中にユーザが反映操作を有効に行うことができる回数は1回のみであり、同一の受付期間中に複数回の反映操作を行ったからといって何度も能力反映処理が実行されるわけではない。そこで、あるイニングの受付期間中にユーザが「反映」ボタン92を押した後は、図17の画面に示すように、そのイニングの能力が「キャラクタに反映済み」である旨の表示が行われ、そのイニングの受付期間中には、「反映」ボタン92が表示されなくすることが望ましい。その後、次のイニングの受付期間が開始された場合、「更新」ボタン91を押すことにより(または図14の「リアルタイム連動育成モード」ボタン86を押すことにより)、図16または図18に示す画面に遷移し、次のイニングについての反映操作を可能とする。
第2イニング以降の能力反映処理も、基本的には第1イニングの能力反映処理と同様である。図28に第nイニング(nは2以上の整数)の能力反映処理を示すが、図27と同様の処理には同じステップ番号を付記し、適宜その説明を省略する。なお、図28のステップS66までの処理は、ゲームサーバ1が管理している全てのユーザに共通の処理であり、それ以降の処理は、ユーザ毎に実行される処理である。
第n−1イニング終了の基準事象の入力後(S71でYES)から第nイニングの処理が始まる。第nイニング終了の基準事象が入力されるまで、現実事象が入力される毎に(S62でYES)、各現実事象が記憶装置に記憶される(S63)。第nイニング終了の基準事象が入力された場合(S72でYES)、反映手段59は、第nイニング中に入力された現実事象に応じた能力情報を、関係情報に基づいて取得する(S73)。その後のS66〜S69の処理は図27と同じである。
ユーザによる反映操作に応じて初期状態キャラクタに能力が反映された後(S69)、または反映操作が行われることなく受付期間が終了した後(S67でYES)、試合終了でなければ(S74でNO)、第nイニングの能力反映処理は終了となる。一方、試合が終了している場合(S74でYES)、キャラクタ登録手段60が、初期状態キャラクタに能力を反映させた後のキャラクタを、ユーザのキャラクタとして登録する処理を実行する(S75)。例えば、ユーザがその試合の最後の反映操作を行った後に、ゲームサーバ1は、図20に例示する育成完了画面データを、ユーザの端末装置3へ送信する。この画面でユーザが「育成終了」ボタン94を押すことにより、キャラクタ登録手段60が成長後のキャラクタをユーザのキャラクタとして登録する。この場合、ゲームサーバ1は、図21に例示する画面データをユーザの端末装置3へ送信する。ユーザは、この画面で、完成したキャラクタの選手カード95および当該キャラクタの能力情報96を確認することができる。図21の画面でユーザが「メイン画面」ボタン97を押せば、図14のメイン画面に遷移する。
連動育成モードでユーザが成長させたキャラクタの選手カード95は、図示しない選手カード一覧画面でいつでも確認することができる。また、この選手カード95は、対戦モードでの対戦等に使用することもできるし、仲間等の他のユーザにプレゼントすることもできる。
上記のように、本実施の形態の構成では、現実世界の野球の試合で発生する現実事象に連動させて、初期状態キャラクタをユーザの意思に基づく操作を介して育成可能である。ユーザは、現実世界の野球場等に足を運んで、またはテレビ、ラジオ、インターネット等で野球の試合をリアルタイムで視聴しながら、イニングが終了する毎に、自分の端末装置3で反映操作をして、初期状態キャラクタの育成を楽しむ。この場合、現実世界でリアルタイムに発生する現実事象(単打、本塁打等)によって、初期状態キャラクタの成長度が大きく異なる。さらに、各イニングの受付期間中に反映操作を行わなければ、折角のキャラクタ成長の機会を逸することになる。よって、ユーザは、臨場感と緊張感を持って、現実世界の野球の試合を視聴しながらゲームをプレイすることができる。これにより、現実世界で発生する現実事象と連動させて一からキャラクタを作り上げるゲームプレイであって、臨場感と緊張感を備えたプレイが可能な興趣性の高いゲームを実現できる。
また、本実施の形態では、マイナス成長もあり得る構成としている。この構成において、現実世界で守備エラー等が発生した場合、そのイニングの受付期間中には反映操作を行わず、キャラクタのマイナス成長を回避するというユーザの意思に基づく技術介入も可能である。そのためには、現実世界の野球の試合をリアルタイムで実際に視聴することが必要であり、それをせずにユーザが反映操作を行った場合、キャラクタをマイナス成長させてしまうこともあり、キャラクタを効率よく成長させることは困難である。また、イニングが終了したことだけに注目するのではなく、イベントを継続的に視聴していなければ、守備エラー等が発生していないかを確認できない。よって、マイナス成長もあり得る構成は、現実世界の野球の試合をリアルタイムで視聴しながらゲームをプレイする方向にユーザを導くことができる。
次に、反映手段59による能力反映処理のバリエーションについて説明する。反映手段59は、能力反映処理を実行する場合に、各イニングの受付期間中における反映操作の情報を受信するタイミングが遅いほど、関係情報に基づいて取得した能力情報の初期状態キャラクタへの反映度を低くする。関係情報に基づいて取得した各イニングの能力情報をP0、補正係数をa1、ユーザの反映操作によりキャラクタに反映される能力情報をP1とした場合、
P1=P0×a1 ・・・(1)
として表すことができる。ここで、上式(1)中の補正係数a1は、0<a1≦1であり、反映手段59は、補正係数a1の値を、ユーザの反映操作のタイミング(受付期間の開始からの経過時間t)に応じて変化させる。一例を挙げると、経過時間tが1分増す毎に、補正係数a1を所定値ずつ(例えば0.2ずつ)小さくする。この構成の能力反映処理の一例を、図29のフローチャートを参照して以下に説明する。図29の処理は、図27または図28のS66〜S69の処理の変形例に該当する。
あるイニングの受付期間が開始された後(S66)、当該イニングの受付期間が終了するまでに(S67でNO)、端末装置3にて反映操作が行われた場合(S68でYES)、反映手段59は、当該操作のタイミングが受付期間の開始から1分以内であるか判断する(S81)。ステップS81でYESの場合、反映手段59は、補正係数をa1=1.0に設定する(S82)。また、反映操作のタイミングが受付期間の開始から1分を超えて2分以内ならば(S83でYES)、補正係数をa1=0.8に設定する(S84)。また、反映操作のタイミングが受付期間の開始から2分を超えて3分以内ならば(S85でYES)、補正係数をa1=0.6に設定する(S86)。また、反映操作のタイミングが受付期間の開始から3分を超えて4分以内ならば(S87でYES)、補正係数をa1=0.4に設定する(S88)。また、反映操作のタイミングが受付期間の開始から4分を超えているならば(S87でNO)、補正係数をa1=0.2に設定する(S89)。このようにして反映操作のタイミングに応じた補正係数a1を設定した後、反映手段59は、関係情報に基づいて取得したイニングの能力情報P0に補正係数a1を積算して算出した能力情報P1を、ユーザの初期状態キャラクタに反映させる(S90)。
具体例を示すと、第1イニング中に発生したヒット等の現実事象に応じた能力情報として、関係情報に基づいて「+100」が取得された場合、ユーザによる反映操作が受付期間の開始から1分以内に行われた場合には「+100」の能力が初期状態キャラクタへ反映される。一方、反映操作のタイミングが1分経過後から2分以内であった場合は「+80」、2分経過後から3分以内であった場合には「+60」、3分経過後から4分以内であった場合には「+40」、4分経過以降は「+20」となる。もちろん、ユーザによる反映操作が行われることなく受付期間を経過してしまった場合には、そのイニングに関する初期状態キャラクタの成長はない。なお、この例では、受付期間の開始から1分経過毎に段階的に反映度を低下させているが、これに限定されるものではなく、例えば10秒経過毎に反映度を低下させてもよい。また、補正係数a1を経過時間t(sec)の関数f(t)とし、経過時間tに応じた補正係数a1を算出してもよい。
本構成によれば、イニング終了後に受付期間が設定される毎に、高い反映度で初期状態キャラクタに能力を反映させるには、受付期間の開始の契機となるイニングの終了をユーザが認識し、受付期間の開始直後に反映操作を行う必要がある。そのためには、ユーザが現実世界の野球の試合を、リアルタイムで実際に視聴することが必要である。すなわち、現実世界の野球の試合を視聴せずに適当なタイミングでユーザが反映操作を行っても、初期状態キャラクタを効率よく成長させることは困難である。従って、受付期間中における反映操作のタイミングが遅くなるほどキャラクタへの能力反映度を低く抑える構成は、現実世界の野球の試合をリアルタイムで視聴しながらゲームをプレイする方向にユーザを導くことができる。
次に、反映手段59による能力反映処理の他のバリエーションについて説明する。反映手段59は、能力反映処理を実行する場合に、イベント登録している仲間の人数が多いユーザほど、関係情報に基づいて取得した能力情報の初期状態キャラクタへの反映度を高くする。関係情報に基づいて取得した各イニングの能力情報をP0、補正係数をa2、端末装置3での反映操作によりキャラクタに反映される能力情報をP1とした場合、
P1=P0×a2 ・・・(2)
として表すことができる。ここで、上式(2)中の補正係数a2は、1≦a2であり、反映手段59は、補正係数a2の値を、イベント登録している仲間の人数に応じて変化させる。一例を挙げると、イベント登録している仲間の人数が5人以下の場合には補正係数をa2=1.0とし、6人〜10人の場合には補正係数をa2=1.1とし、11人〜20人の場合には補正係数をa2=1.2とし、21人以上の場合には補正係数をa2=1.3とする。この場合、能力情報の反映度が最大で3割向上する。
なお、上式(1)に示した補正係数a1もあわせて適用し、
P1=P0×a1×a2 ・・・(3)
としてもよい。
このようにイベント登録している仲間の人数が多いユーザほど能力反映度を高めることにより、各ユーザは、自分の仲間に対して、積極的にイベント登録するように働きかけることが期待できる。例えば、ユーザは、多くの仲間にメッセージを送信してイベント登録を勧める。これにより、仲間相互間でコミュニケーションを積極的にとり合うゲーム環境を推進でき、仲間同士のコミュニティが活性化する。また、イベント登録して連動育成モードでプレイする人数も増えることより、ゲーム全体の活性化が図られる。
次に、ユーザが、応援チーム(対象グループ)だけでなく、応援選手(対象メンバ)の登録も可能とする構成について説明する。この構成では、ユーザが選択した応援チームの活躍に応じてキャラクタが成長するだけでなく、ユーザが選択した応援選手が活躍すれば、キャラクタの成長がより一層大きくなる。この構成を実現するゲームサーバ1の構成例を、図30の機能ブロック図等を参照しながら説明する。なお、既出の図面において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。
本ゲームサーバ1の応援対象登録手段58は、応援チーム登録手段58a(対象グループ登録手段)に加えて、応援選手登録手段58b(対象メンバ登録手段)を備えている。応援選手登録手段58bは、遅くとも野球の試合の終了までにユーザの端末装置3にて、応援チーム中の少なくとも1の実在選手を応援対象として選択する操作が行われた場合に、当該操作の情報を受信して、当該ユーザの応援選手を登録する。ユーザが登録できる応援選手の人数は、任意に設定できるが、本実施の形態では1人のみ登録できる例について説明する。応援選手登録手段58bは、例えば図23に示すように、データベースサーバ2の所定領域に、ユーザIDと対応付けて応援選手(選手ID)を記憶する記憶制御を実行する。
ユーザが端末装置3で行う応援選手を登録する操作としては、図31に例示する応援選手登録画面での簡単なボタン操作が挙げられる。この画面は、図15のイベント登録画面で応援チームを登録した後に表示される。例えば、ユーザが図15の画面でチームAを選択して「登録」ボタン90を押せば、応援チーム登録手段58aが応援チームとしてチームAを登録し、その後、ゲームサーバ1がチームAに所属する実在の選手A〜Zを選択肢として含む図31の画面データをユーザの端末装置3に送信する。この応援選手登録画面で、ユーザが応援したい実在選手を選択して「登録」ボタン90を押せば、応援選手登録手段58bが選択された実在選手を応援選手として登録する。
ところで、例えばプロ野球の試合では、一軍登録選手の人数は28人であり、そのうちベンチ入りできる選手数は25人である。一軍登録選手は公表されて予め分かっている。また、オールスター戦のような特別な試合でも、それに出場する選手は公表されて予め分かっている。よって、現実世界の試合で対戦する実在チームの選手の情報を、ゲームサーバ1に予め入力しておくことは可能である。ゲームサーバ1のデータベースサーバ2には、連動育成モードの対象となる野球の試合に出場する予定の実在選手の情報が記憶されている。従って、図31の応援選手登録画面に、ユーザの応援チームに所属する実在選手を選択肢として表示することが可能である。
そして、反映手段59は、能力反映処理を実行するに際し、ユーザの応援チームについての現実事象に応じた能力情報を、関係情報に基づいて取得し、取得した能力情報を、初期状態キャラクタに反映させるとともに、当該応援チームについての現実事象がユーザの応援選手についての現実事象であった場合には、当該応援対象選手が応援対象として登録されていない通常の選手であった場合よりも、当該能力情報をキャラクタへより大きく反映させる。例えば、ユーザの応援チームの選手が本塁打を打って初期状態キャラクタに「+100」の能力情報が反映されるところ、ホームランを打った選手がユーザの応援選手であった場合には、その2倍の「+200」の能力情報がキャラクタに反映されるようにする。なお、2倍に限らず、例えば1.5倍や3倍等、任意の反映度を設定することができる。
これを実現するため、反映手段59の現実事象記憶制御手段59aは、図32に例示するように、イニング中に現実事象(事象ID)が入力される毎に、その現実事象を生じさせた選手(選手ID)も併せて記憶する。
なお、例えば、勝利、引き分け、敗北等の事象を現実事象とする場合、これらの事象は特定の選手の活躍等によって生じたものとは必ずしも言いえない。よって、複数ある現実事象の全部ではなく、そのうちの一部についてのみ応援選手の現実事象となり得る場合もある。本実施の形態では、単打、二塁打、三塁打、本塁打、四死球、犠打、先制打、同点打、逆転打、勝ち越し打、3安打/選手、4安打/選手、5安打以上/選手、サイクルヒット/選手、盗塁、三振、併殺打、奪三振、エラー、投手暴投などを応援選手による現実事象となり得るものとして扱う。
なお、例えばユーザの応援選手が守備エラーをした場合には、マイナスの能力情報も2倍等になり、キャラクタを大きくマイナス成長させてしまう可能性もある。よって、マイナス成長を回避するため、連動育成モード中はリアルタイムで野球の試合を視聴することがより重要となる。
図33のフローチャートに、本実施の形態の能力反映処理の一例を示す。図33の処理は、図27または図28のS66〜S69の処理の変形例に該当する。
あるイニングの受付期間が開始された後(S66)、当該イニングの受付期間が終了するまでに(S67でNO)、端末装置3にて反映操作が行われた場合(S68でYES)、反映手段59は、当該イニング中に発生した現実事象の中にユーザの応援選手についての現実事象が存在するか否かを判断する(S91)。例えば、ユーザの応援選手が選手ID=001であった場合、反映手段59は、図32に例示するイニング中に発生した現実事象の中に、選手ID=001についての事象が含まれているかを検索する。この例では、本塁打が選手ID=001についての現実事象であるため、ステップ91でYESとなる。この場合、本塁打に対応する能力情報「+100」を2倍の「+200」にする(S92)。その後、反映手段59は、ユーザの初期状態キャラクタに能力情報を反映させる(S93)。なお、イニング中に発生した現実事象の中にユーザの応援選手についての現実事象が存在しない場合(S91でNO)、ステップS92に移行することなく、ユーザの初期状態キャラクタに能力情報が反映される(S93)。
その後、ゲームサーバ1からユーザの端末装置3へ送信される画面データの例を図34に示す。図34の画面(キャラクタに能力情報が反映されたことを報知する画面)には、ユーザの応援選手が活躍した現実事象がその他の現実事象と異なる状態(印を付す、文字の色や太さを変える等)で表示され、その能力情報が2倍になっていることをユーザが視認できるようにしている。
このように、本実施の形態の構成では、ユーザが自ら選んだ応援チームの現実世界での活躍に応じてキャラクタが成長するだけでなく、応援選手が活躍すればより一層キャラクタが成長する。よって、例えば、ユーザの応援チームが全体としては不調であったとしても、ユーザの応援選手が活躍(例えば本塁打を打つ等)すれば、キャラクタの大きな成長が見込める。また、応援チームも応援選手も活躍すれば、キャラクタをかなり大きく成長させることも可能となる。これにより、現実世界で繰り広げられる野球の試合の視聴中のユーザの応援も白熱し、ゲームプレイを楽しむと同時に、野球の試合もより一層楽しめるようになる。これが、現実世界と連動させてキャラクタを育成するゲーム性をさらに高めることに繋がり、興趣性の高いゲームを実現できる。
なお、上記の説明では、ユーザが図15のイベント登録画面で、応援チームを選択してイベント登録を行う例について説明したが、このイベント登録は必ずしも必須ではない。イベント登録せずに連動育成モードでのゲームプレイを可能とする場合、例えば、現実世界の野球の試合で対戦する2つの実在チームA・Bの両方についての現実事象に応じた能力情報を、キャラクタに反映させるようにする。この場合、例えば、図11Aまたは図12Aに示す関係情報(攻撃側の「現実事象」と「能力情報」との関係情報)に基づいて、2つの実在チームA・Bの攻撃側の現実事象に応じた能力情報を取得してキャラクタに反映させる。または、2つの実在チームA・Bの守備側の現実事象に応じた能力情報を取得してもよい。
ところで、上記では、現実世界で発生する現実事象に応じた能力情報を、ユーザの意思(操作)を介して、初期状態キャラクタに反映させながら、キャラクタを一から作り上げることができる構成について説明したが、初期状態キャラクタに代えて、ユーザが既に所有している選手カードのキャラクタに現実事象に応じた能力情報を反映させてもよい。これについて、以下に説明する。
連動育成モードにおいて、初期状態キャラクタに代えて、ユーザが既に所有しているキャラクタを能力情報の反映対象キャラクタ(以下、「対象キャラクタ」と呼称する)とする場合、所有選手カード記憶制御手段51c(キャラクタ記憶制御手段)がデータベースサーバ2に記憶しているユーザの手持ち選手カードの中の、少なくとも1の選手カード(キャラクタ)が対象キャラクタとなる。この構成の場合、初期状態キャラクタ記憶制御手段51i(図5参照)と、初期状態キャラクタに能力情報を反映させた後のキャラクタをユーザのキャラクタとして登録するキャラクタ登録手段60(図4参照)と、を省略することができる。それ以外の構成は、初期状態キャラクタがユーザの手持ちキャラクタに代わるだけであるため、図4、図5、図30等に示すゲームサーバ1の構成がそのまま適用でき、前述の作用効果と同様の作用効果を奏する。
また、ユーザの所有するキャラクタは、その他の方法(例えば、キャラクタ同士を合成する等)により能力を向上させることも可能であるが、本構成はキャラクタの能力向上のバリエーションを増やす。
なお、対象キャラクタとなるキャラクタは、ユーザの手持ちキャラクタの全部とすることができる。また、例えばゲームサーバ1が、ユーザの手持ちキャラクタ全体の中からランダム抽選で所定数(例えば1)の対象キャラクタを選択してもよい。
あるいは、ユーザが、自分が所有する複数のキャラクタの中から、対象キャラクタを任意に選択することができるようにしてもよい。この場合、図35に示すように、ゲームサーバ1は、ユーザの端末装置3にて、当該ユーザが所有する複数のキャラクタの中から対象キャラクタを選択する操作が行われた場合に、当該操作の情報を受信して、選択された対象キャラクタを登録する対象キャラクタ登録手段61をさらに備える。対象キャラクタ登録手段61は、記憶装置(データベースサーバ2等)の所定領域に、ユーザIDと対応付けて、ユーザに選択された対象キャラクタを記憶する記憶制御を実行する。例えば、図6のレギュラー選手フラグと同様にして、対象キャラクタであることを示すフラグを立てることにより、対象キャラクタを登録することができる。そして、反映手段59は、対象キャラクタ登録手段61に登録されている対象キャラクタに対して、前記能力反映処理を実行する。
ここで、ユーザが任意に選択可能な対象キャラクタを、所定数(例えば3)に限定することができる。この所定数(上限)を、ユーザの仲間の数に応じて変えることもできる。例えば、仲間が19人以下の場合には対象キャラクタの上限を1とし、仲間が20人〜39人の場合には当該上限を2とし、仲間が40人以上の場合には当該上限を3とする。このように、仲間の数が多いほど選択可能な対象キャラクタの数を多くすることにより、積極的に多くの仲間を作ろうとする動機付けをユーザに与えることができる。そして、各ユーザの仲間が増えることにより、ユーザ間のコミュニティの活性化が図られる。
本構成により、ユーザが、手持ちキャラクタの能力属性を分析・検討して、所望のキャラクタを対象キャラクタとして選択するということが可能となり、ゲーム性を高めることができる。例えば、ユーザのゲーム内チームの投手、捕手、一塁手、・・・等の各ポジションのキャラクタの中で、能力的に最も低いポジションのキャラクタを分析し、そのキャラクタを対象キャラクタとして育成することにより、自分のチームのボトムアップを図る等の戦略を立てることが可能となる。
また、本実施の形態のように、ユーザが、現実世界の実在選手(実在物)と対応する実在選手キャラクタを所有できる構成の場合には、次のようにすることもできる。すなわち、現実世界の野球の試合のオーダ(スターティングメンバ)に入っている実在選手に対応する実在選手キャラクタをユーザが所有している場合に、当該実在選手キャラクタを対象キャラクタとすることができるようにする。たとえば、ユーザが、現実世界の野球の試合のオーダに入っている実在選手全員に対応する実在選手キャラクタを全て所有している場合、これら全ての実在選手キャラクタを対象キャラクタとして選択できる。オーダに入っている実在選手の一部、例えば9人中の3人に対応する実在選手キャラクタを所有している場合は、その3人に対応する実在選手キャラクタを対象キャラクタとして選択できる。この場合、ユーザは、現実世界の野球の試合のオーダに入るような実在選手に対応する実在選手キャラクタを多く所有しているほど有利になるので、そのような実在選手キャラクタをゲーム内で入手しようとして、連動育成モード以外のゲームモードも積極的にプレイするように動機づけられる。これにより、ゲーム全体の活性化を図ることができる。
連動育成モードでユーザの所有するキャラクタを育成できるその他のバリエーションを次に説明する。野球の試合では、打順1番〜9番の9人の実在選手(実在物)が存在するので、例えばこの打順を利用して、9人の実在選手と、ユーザのゲーム内オーダの9のキャラクタ(打順1番〜9番のキャラクタ)とをそれぞれ一対一で対応付ける。そして、現実世界の9人の実在選手のそれぞれについての現実事象に応じた能力情報を、各実在選手に対応付けているユーザのキャラクタにそれぞれ反映させる。これを実現するに、反映手段59は、n人(ここでは9人)の実在選手と、ユーザが所有するnのキャラクタとを、打順に基づいてそれぞれ一対一で対応付けて、前記n人の実在選手のそれぞれについての現実事象に応じた能力情報を、関係情報に基づいてそれぞれ取得し、取得した当該能力情報を、各実在選手に対応付けているキャラクタにそれぞれ反映させる。
この例の場合、ユーザは、現実世界の実在チームの打順1番〜9番の実在選手の活躍を予想し、例えば打順1番および2番の実在選手が大活躍すると予想したならば、ゲーム内オーダの1番および2番に能力情報を大きく反映させたいキャラクタを配するといった策を立てることも可能となり、ゲーム性を高めることができる。
なお、上記では、n人の実在選手と、ユーザが所有するnのキャラクタとを、打順に基づいて、一対一の対応付けを行う例を示したが、これに限定されず他の基準に基づいた対応付けをしてもよい。例えば、ユーザのゲーム内チームに所属するキャラクタにも、投手、捕手、一塁手、・・・等のポジションの属性が設定されているので、ポジションに基づいて、9人の実在選手と、ユーザが所有する9のキャラクタとを、一対一で対応付けてもよい。野球以外の例えばサッカーの場合でも、11人の選手のポジションは決まっているので、このポジションに基づいて、野球の場合と同様の一対一の対応付けが可能である。
上述のように、連動育成モードでは、現実世界の野球の試合中に発生したヒット等の現実事象に対して受付期間が適宜設けられ、各受付期間中の端末装置3での操作によりキャラクタ(初期状態キャラクタまたはユーザの手持ちキャラクタ)を育成する。以下には、ユーザによって操作が行われた受付期間の数が多くなるほど、すなわち、ユーザが現実世界の野球の試合を継続的に視聴しながら本ゲームを継続的にプレイするほど、キャラクタへの能力情報の反映の度合いを大きくする構成について説明する。
この構成を実現する反映手段59は、前述の能力反映処理を実行する場合に、端末装置3から操作情報を受信した受付期間の数が多くなるほど、関係情報に基づいて取得した能力情報を、キャラクタへより大きく反映させる反映量補正処理を実行する。この処理の対象となるキャラクタは、初期状態キャラクタであってもよいし、ユーザが既に所有しているキャラクタであってもよい。ゲームサーバ1は、連動育成モード中においては、ユーザの端末装置3から操作情報を受信した受付期間の数を、ユーザIDと対応付けて記憶装置(データベースサーバ2等)に記憶する記憶制御を実行している。ここで、連動育成モードの対象となる野球の試合でイニング終了毎に、次のイニング終了までの受付期間が設けられる場合を想定して、反映量補正処理の具体例を以下に示す。
関係情報に基づいて取得した各イニングの能力情報をP0、補正係数をa3、受付期間中のユーザの反映操作によりキャラクタに反映される能力情報をP1とした場合、
P1=P0×a3 ・・・(4)
として表すことができる。上式(4)中の補正係数a3は、1≦a3であり、反映手段59は、補正係数a3の値を、端末装置3から操作情報を受信した受付期間の数に応じて変化させる。例えば、補正係数a3は、端末装置3での操作が行われた受付期間の数Nによって変動するNの関数として、下式(5)で表すことができる。
a3=f(N)=1+0.1×(N−1) ・・・(5)
この場合、1イニング目の終了後の受付期間中にユーザによる反映操作が行われた場合、補正係数a3=1+0.1×(1−1)=1.0となる。続けて、2イニング目の終了後の受付期間中にもユーザによる操作が行われた場合、補正係数a3=1+0.1×(2−1)=1.1となり、キャラクタに反映される能力情報P1は10%向上する。さらに続けて、3イニング目の終了後の受付期間中にもユーザによる反映操作が行われた場合、補正係数a3=1+0.1×(3−1)=1.2となり、キャラクタに反映される能力情報P1は20%向上する。同様に、毎イニング連続して受付期間中に反映操作が行われた場合、キャラクタに反映される能力情報P1は10%ずつ向上することになる。
一方、受付期間中に必要な操作が行われなかったイニングについては、端末装置3から操作情報を受信した受付期間の数Nがカウントされないので、反映量の増大度合いはその前のイニングのまま足踏みとなる。例えば、1イニング目および3イニング目の終了後の各受付期間中に反映操作が行われたが、2イニング目終了後の各受付期間中に反映操作が行われなかった場合、3イニング目の補正係数はa3=1+0.1×(2−1)=1.1となり、キャラクタに反映される能力情報P1は10%の向上となる。
なお、上記の例では、端末装置3から操作情報を受信した受付期間の数Nが1つ増加する毎に反映量を10%ずつ増加させているが、これに限定されるものではなく、反映量の増加の程度は任意に設定できる。
また、上式(1)に示した補正係数a1および/または上式(2)に示した補正係数a2も、上式(5)に示した補正係数a3と組み合わせて適用し、下式(6)〜(8)によりキャラクタに反映される能力情報P1を算出してもよい。
P1=P0×a1×a3 ・・・(6)
P1=P0×a2×a3 ・・・(7)
P1=P0×a1×a2×a3 ・・・(8)
ところで、図12Aおよび図12Bに例示するように、関係情報にプラスの能力情報だけではなくマイナスの能力情報を含めてもよい。このように、マイナスの能力情報を含む構成において、現実世界で実際にマイナスの能力情報を反映させるための現実事象(守備エラー等)が発生した場合、ユーザは、受付期間中にあえて反映操作を行わず、キャラクタへのマイナス能力情報の反映を回避するということも可能である。但し、ユーザが何も操作しなければ、野球の試合を継続的に視聴しているにもかかわらず、反映量の増大度合いは足踏み状態となってしまう。
そこで、ゲームサーバ1は、受付期間中に、ユーザによる反映操作だけではなく、非反映操作(キャラクタに属性情報を反映させない操作)も受け付けることが望ましい。例えば、図36に例示するように、受付期間中に反映操作等を行うための画面中には、「反映」ボタン92および「非反映」ボタン121が両方表示されるようにし、ユーザの判断で、何れかのボタン操作を可能とする。ここで、ユーザにより「反映」ボタン92を押す操作が行われた場合、端末装置3からは、キャラクタに能力情報を反映させるための反映操作情報がゲームサーバ1へ送信される。一方、ユーザにより「非反映」ボタン121を押す操作が行われた場合、端末装置3からは、キャラクタに能力情報を反映させない非反映操作情報がゲームサーバ1へ送信される。そして、反映手段59は、受付期間中に端末装置3から非反映操作情報を受信した場合には能力反映処理を実行せず、反映操作情報を受信した場合にのみ能力反映処理を実行する。
この構成では、現実世界で守備エラー等が発生したことによりキャラクタがマイナス成長しそうになった場合、ユーザは、受付期間中に非反映操作を行えばよい。反映手段59は、操作情報(反映操作情報と非反映操作情報の何れか)を受信した受付期間の数Nが多くなるほど、関係情報に基づいて取得した能力情報をキャラクタへより大きく反映させるので、ユーザによって非反映操作が行われた場合であっても、反映量補正処理における反映量の増大度合いは足踏み状態とはならない。これにより、ユーザの判断によりキャラクタのマイナス成長を回避しつつ、反映量の増大度合いが足踏み状態となる事態も回避できる。
ここで、図37のフローチャートに、本実施の形態の能力反映処理の一例を示す。図37の処理は、図27または図28のS66〜S69の処理の変形例に該当する。
あるイニングの受付期間が開始された後(S66)、当該イニングの受付期間が終了するまでに(S67でNO)、端末装置3にて反映操作と非反映操作の何れかが行われた場合(S101でYES)、反映手段59は、端末装置3から操作情報を受信した受付期間の数Nをインクリメントする(S102)。なお、この操作情報を受信した受付期間の数Nは、連動育成モードの対象とする現実世界の野球の試合の開始時に初期化されている。そして、端末装置3での操作が反映操作であった場合には(S103でYES)、例えば上式(5)の演算により、端末装置3から操作情報を受信した受付期間の数Nに応じた補正係数a3を取得する(S104)。そして、反映手段59は、上式(4)によりキャラクタに反映される能力情報を補正する反映量補正処理を実行する(S105)。その後、反映手段59は、キャラクタに能力情報を反映させる(S106)。
一方、端末装置3での操作が非反映操作であった場合には(S103でNO)、ステップS104に移行することなく処理を終了する。また、端末装置3にて反映操作も非反映操作も行われずに受付期間が終了した場合には(S67でYES)、ステップS102に移行することなく処理を終了する。
以上のように、本構成では、ユーザによって操作が行われた受付期間の数が多くなるほど、すなわち、ユーザが現実世界の実在イベントを継続的に視聴しながら本ゲームを継続的にプレイするほど、キャラクタへの能力情報反映の度合いが大きくなる。この構成は、現実世界の野球の試合等の実在イベントの全体を通して、本ゲームを継続的にプレイさせる方向にユーザを導く。そして、野球の試合の開始当初から継続してプレイしているユーザにとっては、試合が進むにつれてキャラクタへの能力情報反映の度合いが継時的に大きくなるので、ゲームの面白さも継時的に増す。これにより、より興趣性の高いゲームを実現できる。
次に、反映手段59による前記反映処理が実行されるためには、端末装置3にて所定のイベント登録操作を必要とし、このイベント登録操作が所定のタイミング(例えば現実世界の野球の試合開始時間)までに行われなかった場合には、上述の反映量補正処理によるメリットを享受できない構成について説明する。この構成のゲームサーバ1は、端末装置3にてイベント登録操作が行われた場合に、当該操作の情報を受信して、当該端末装置3に対するイベント登録処理を実行するイベント登録手段を備える。このイベント登録手段の例としては、前述の応援対象登録手段58(図4参照)が挙げられる。イベント登録操作の例としては、図15の画面での応援チームの選択操作があるが、これに限定されるものではない。例えば、図示しないイベント参加ボタンを押す等の操作であってもよく、連動育成モードのイベントに参加しようとするユーザの意思を確認できる任意の操作を、イベント登録操作とすることができる。
そして、所定のタイミングまでにイベント登録処理が実行された場合のみ、反映手段59が能力反映処理を実行する場合に反映量補正処理を実行し、所定のタイミングを経過してからイベント登録処理が実行された場合には、反映手段59が反映処理を実行する場合に反映量補正処理を実行しないようにする。ここで、所定のタイミングまでの例としては、現実世界の野球の試合の開始まで、試合開始から5分経過まで、最初のイニング終了まで等の任意のタイミングを設定することができる。本構成により、操作がなされた受付期間の数が多くなるほど反映量を増大する反映量補正処理のメリットを得るために、所定のタイミングまでにイベント登録を行おうという動機付けをユーザに与えることができる。これにより、多くのユーザが野球の試合(実在イベント)の初期段階から本ゲームのプレイを楽しむように仕向けることが可能となり、ゲームの活性化を図ることができる。
次に、上記の構成の変形例について説明する。ユーザによっては止むを得ず所定のタイミングを経過した後にイベント登録をして、本ゲームのプレイを開始する場合もある。そこで、所定のタイミングまでにイベント登録処理が実行されなかった場合であっても、反映量補正処理が実行されるようにする。但し、反映手段59は、所定のタイミングまでにイベント登録処理が実行された場合より、所定のタイミングを経過してからイベント登録処理が実行された場合の方が、反映量補正処理におけるキャラクタへの反映量を小さくする。
例えば、所定のタイミングまでにイベント登録処理が実行された場合の補正係数a3は上式(5)にて算出する一方、所定のタイミングを経過してからイベント登録処理が実行された場合の補正係数a3は、下式(9)に示すNの関数により算出することとする。
a3=f(N)=1+0.05×(N−1) ・・・(9)
これにより、所定のタイミングまでにイベント登録処理が実行された場合には、操作情報を受信した受付期間の数Nが1つ増加する毎に反映量を10%ずつ増加させるのに対し、所定のタイミングを経過してからイベント登録処理が実行された場合には、Nが1つ増加する毎に増加する反映量を5%に抑える。
本構成においても、反映量補正処理による最大限のメリットを得るために、所定のタイミングまでにイベント登録を行おうという動機付けをユーザに与えることができる。これにより、多くのユーザが実在イベントの初期段階から本ゲームのプレイを楽しむように仕向けることが可能となり、ゲームの活性化を図ることができる。
〔他の実施の形態〕
上述の実施の形態では、図12A等に示すように、「単打」の現実事象に対して「+10」の能力情報を対応させるといったように、1つの現実事象に1つの能力情報を対応させた関係情報の例を示したがこれに限定されない。例えば、キャラクタの能力として、複数の個別能力が設けられている場合には、図38に例示するように、「単打」の現実事象に対して、パワー「+10」、ミート「+20」、走力「+10」、守備「+5」を対応させるといったように、1つの現実事象に対応する能力情報として、個別能力毎に内容(値)を異ならせた関係情報を適用してもよい。
また、上述の実施の形態では、現実世界で発生する現実事象に応じた能力情報をキャラクタに反映させる例について説明したが、これに限定されるものではなく、能力情報以外の属性情報をキャラクタに反映させてもよい。例えば、キャラクタの体力、大きさ(身長、体重等)、形態、顔の表情などの属性情報を、キャラクタに反映させる構成であってもよい。
また、上述の実施の形態では、初期状態キャラクタ記憶制御手段51i、所有選手カード記憶制御手段51c(キャラクタ記憶制御手段)を、ゲームサーバ1が備えている構成について説明したが、これに限定されない。すなわち、初期状態キャラクタや各ユーザが所有するキャラクタの情報は、各ユーザの端末装置3にて記憶制御することも可能である。よって、初期状態キャラクタ記憶制御手段51i、所有選手カード記憶制御手段51cを、端末装置3側が具備するシステム構成にしてもよい。
また、各種情報を記憶装置に記憶する記憶制御機能を有する構成(初期状態キャラクタ記憶制御手段51i、所有選手カード記憶制御手段51c、関係情報記憶制御手段57など)に関し、記憶装置そのものについては当該構成に含まれないので、ゲーム管理装置(またはゲームシステム)の内外を問わず、どこに設置されていてもよい。例えば、記憶装置は、ゲームサーバ1が有するRAM13や補助記憶装置14、データベースサーバ2、端末装置3が有するRAM33や補助記憶装置39、あるいはゲーム管理装置や端末装置3とは別構成のファイルサーバ等であってもよい。
また、上述の実施の形態では、現実事象受付手段55が、キーボードやマウス等の入力装置17を介して現実事象を受け付けたり、他のサーバからの情報を受信することによって現実事象を受け付けたりする構成について説明したが、これに限定されるものではない。例えば、現実世界を撮像等した映像データを画像処理により解析し、現実事象を自動認識することが可能な場合には、画像処理により現実事象を自動受け付けする構成も含まれる。クイズゲームを例に挙げると、現実世界のテレビ番組でタレント(実在物)がクイズに正解する(または不正解)という現実事象について、番組の映像内に正解か不正解かの情報が文字等により必ず表示される場合、番組の映像データ(テレビジョン信号等)を画像処理により解析すれば、現実事象を自動認識できる。
また、上述の実施の形態では、ゲーム実行プログラムがゲームサーバ1側に実装されており、各ユーザの端末装置3における入力操作に応じて、ゲームサーバ1がゲーム進行のための演算処理やデータ処理を実行し、その実行結果を反映させた画面データを端末装置3へ送信することによって、ゲームが進行するゲームシステムへの適用例について説明した。これはいわゆるクライアントサーバ型のゲームシステムであるが、これに限定されるものではない。例えば、ゲームサーバ1が、ユーザの仲間等に関するゲーム情報を管理し、ゲーム内で交流等のゲームサービスをユーザに提供する一方、ゲームを進行させるゲーム実行処理については、基本的にはユーザの端末装置側にて行われるゲームシステムにも適用できる。
すなわち、ゲーム実行プログラムの一部または全部をユーザの端末装置側にダウンロードまたはインストールし、端末装置においてもゲーム実行処理が行われるようなゲームシステムにも適用できる。例えば、ユーザの端末装置が、インターネット通信、無線LAN通信、所定の周波数帯(例えば2.4GHzの周波数帯)を用いた近距離無線通信、または有線LAN通信などにより他のユーザの端末装置とピア・ツー・ピア接続し、ピア・ツー・ピア型のゲームを実行することも可能である。
よって、ユーザの端末装置としては、ゲームサーバ(ゲーム管理装置)に接続してゲームサービスの提供を受けることができる様々なものが適用でき、前述の携帯電話端末、スマートフォン、PHS端末、携帯情報端末(PDA)、パーソナルコンピュータ、タブレット型コンピュータ以外にも、ネットワーク接続機能を有している家庭用ビデオゲーム装置(家庭用ビデオゲーム機を家庭用テレビジョンに接続することによって構成されるゲーム装置)や、携帯型のゲーム専用装置なども適用可能である。
また、サーバ装置が現実事象の情報を端末装置へ送信するだけであり、現実事象の情報を受信した端末装置が、図4、図30または図35に示したゲーム情報管理手段51、ゲーム進行手段52、操作受付手段56、関係情報記憶制御手段57、応援対象登録手段58、反映手段59、キャラクタ登録手段60、対象キャラクタ登録手段61等と同様の機能を有する構成とすることができる。このゲームシステムを、図39および図40を参照して以下に説明する。なお、既出の図面において示した構成と同様の構成については同一の部材番号を付し、その説明を省略する。
図39に示すように、本ゲームシステムは、サーバ装置200と、端末装置300(ゲーム装置)とを含む。サーバ装置200は、機能的には、前記現実事象受付手段55と、現実事象に関する情報を端末装置300に送信する送信手段201とを含んでいる。なお、サーバ装置200のハード構成は、図2に示したゲームサーバ1のハード構成と同様である。
また、端末装置300は、図40に示すように、機能的には、受信手段301、ゲーム情報管理手段351、ゲーム進行手段352、操作受付手段356、関係情報記憶制御手段357、応援対象登録手段358、反映手段359、キャラクタ登録手段360、対象キャラクタ登録手段361等を含んでいる。なお、端末装置300のハード構成は、図3に示した端末装置3のハード構成と同様である。
受信手段301は、サーバ装置200の送信手段201から送信された現実事象に関する情報を受信する機能を有する。また、各手段356、357、358、359、360、361は、図4、図30または図35に示した各手段56、57、58、59、60、61と基本的には同様の機能を有する。すなわち、端末装置300の各手段356、357、358、359、360、361は、端末装置300での操作に応じた処理を実行するのに対し、ゲームサーバ1の各手段56、57、58、59、60、61は、ゲームサーバ1と端末装置3との間で通信を行いながら処理を実行するという違いはあるものの、それ以外の機能・構成は同様である。このサーバ装置200と端末装置300とを含むゲームシステムは、図1に示すゲームサーバ1と端末装置3とを含むゲームシステムと同様の効果を奏する。
また、本実施の形態に係るコンピュータ読み取り可能なプログラムは、ハードディスク、光ディスク(CD−ROM、DVD−ROM等)、フレキシブルディスク、半導体メモリ等のコンピュータ読み取り可能な各種記録媒体に記録され、当該記録媒体から読み出されてゲーム管理装置または端末装置のCPUにより実行される。また、プログラムをゲーム管理装置または端末装置に提供する手段は、前述した記録媒体に限定されるものではなく、インターネット等の通信ネットワークを介して行うこともできる。
(1)本発明の一局面によるゲーム管理装置は、端末装置と通信し、ゲームの管理を行うゲーム管理装置であって、ユーザが所有するキャラクタの情報を記憶装置に記憶するキャラクタ記憶制御手段と、現実世界で発生する現実事象に関する情報を受け付ける現実事象受付手段と、前記現実事象に対して所定の受付期間を設定し、当該受付期間中における前記端末装置での操作に関する操作情報を受け付ける操作受付手段と、前記現実事象に対応する前記端末装置での操作と、当該操作に基づく前記キャラクタに反映させる属性情報との関係情報を予め記憶装置に記憶する関係情報記憶制御手段と、前記受付期間中に前記操作情報を受信することにより、前記関係情報に基づいて取得した前記属性情報を、ユーザが所有する前記キャラクタに反映させる反映処理を実行する反映手段と、を備える。
この構成のゲーム管理装置は、各ユーザの端末装置と通信を行うことができる、例えばサーバなどの情報処理装置により構成することができ、各種ゲーム、例えばオンラインゲームやソーシャルゲーム等の管理を行う。
本ゲーム管理装置は、ユーザが所有するキャラクタの情報を記憶装置に記憶するキャラクタ記憶制御手段を備える。なお、記憶装置そのものについては本構成には含まれないので、ゲーム管理装置の内外を問わず、どこに設置されていてもよい。ユーザが所有するキャラクタとは、ユーザがゲーム内で入手し、ゲーム中に使用したり収集したりしている手持ちのキャラクタである。
そして、本構成では、以下に示すように、端末装置でのユーザの操作により、現実世界で発生する現実事象に連動させて、キャラクタの属性を変更する(現実事象に応じた属性情報を反映させる)ことを可能とする。ここで、属性としては、キャラクタの能力、体力、大きさ(身長、体重等)、形態、顔の表情などを含む。例えば、能力の属性情報をキャラクタに反映させてキャラクタの育成を可能とする。
すなわち、本ゲーム管理装置は、現実世界で発生する現実事象に関する情報を受け付ける現実事象受付手段を備える。つまり、現実事象受付手段は、現実事象に関する情報をゲーム管理装置に取り込む機能を有する。ここで、現実世界で発生する現実事象としては、例えば、野球、サッカー、テニス、アメリカンフットボール、バスケットボール、バレーボール等の各種試合中に得点またはポイントが入るという事象がある。その他の例としては、競馬やレーシングカー等の各種レースで順位が決定するという事象がある。また、テレビ・ラジオ・インターネット・ケーブル・衛星などを使用した放送番組でクイズに回答するタレントや有名人がクイズに正解するという事象もある。これらはほんの一例であり、現実世界で発生する様々な事象を現実事象とすることができる。なお、現実事象に関する情報については、例えば現実事象を観察している人によってゲーム管理装置に直接的に入力またはネットワーク等を介して提供されるものであってもよいし、現実事象に関する情報を販売等している会社等のサーバから提供を受けた情報であってもよい。野球を例にあげると、実在選手がヒットを打った等の情報を、1球毎に提供するような情報提供サーバが存在するので、そのようなサーバの提供情報を利用して、現実事象に関する情報をゲーム管理装置に取り込むこともできる。また、現実事象に関する情報は、現実事象の画像や音声等を自動的に分析することによって取得される情報であってもよい。
そして、操作受付手段は、現実事象受付手段によって受け付けられた現実事象に対して、所定の受付期間を設定し、当該受付期間中における端末装置での操作に関する操作情報を受け付ける。例えば、現実世界の野球の試合で発生する現実事象(ヒット等)に対して受付期間を設定する場合について説明する。操作受付手段は、ヒット等の現実事象が発生する毎に、当該現実事象に対する受付期間を設定してもよいし、イニング中に発生したヒット等の現実事象に対しては、そのイニングの終了後にまとめて受付期間を設定してもよい。あるいは、野球の試合開始から所定時間(例えば15分)経過する毎に、その間に発生した現実事象に対してまとめて受付期間を設定してもよい。また、受付期間は、例えば、1分間、3分間、5分間等の所定長の期間としてもよいし、次の現実事象が発生するまで、次のイニングが終了するまで等としてもよい。ユーザは、現実事象に応じた属性情報をキャラクタに反映させるためには、この受付期間中に、端末装置にて所定の操作を行わなければならない。
また、本ゲーム管理装置は、現実事象に対応する端末装置での操作と、当該操作に基づくキャラクタに反映させる属性情報との関係情報を、予め記憶装置に記憶する関係情報記憶制御手段を備える。現実世界の野球の試合を例に挙げると、例えば、「単打」という現実事象に対応する端末装置での反映操作(属性情報を反映させるための操作)により「+20」の能力をキャラクタに反映させるという属性情報や、「本塁打」という現実事象に対応する端末装置での反映操作により「+100」の能力をキャラクタに反映させるという属性情報等が、関係情報として記憶されている。
そして、反映手段は、前記受付期間中に前記操作情報を受信することにより、前記関係情報に基づいて取得した現実事象に応じた属性情報を、前記キャラクタに反映させる反映処理を実行する。現実世界の野球の試合を例に挙げると、イニング終了直後に設けられる受付期間中に、ユーザが端末装置で現実事象を反映させるための反映操作(例えば、端末装置の画面に表示された反映ボタンを押す操作)を行えば、当該イニングで発生した現実事象(ヒット等)に応じた属性情報がキャラクタに反映される。一方、受付期間中に端末装置にて必要な反映操作が行われなかった場合には、そのイニングで発生した現実事象に応じた属性情報がキャラクタに反映されることはない。
以上のように、本構成では、現実世界で発生する現実事象に応じた属性情報を、ユーザの意思(操作)を介して、ユーザの所有するキャラクタに反映させることができる。ユーザは、現実世界の野球場等の現実事象が発生する場所に足を運んで、またはテレビ、ラジオ、インターネット等で現実事象をリアルタイムで視聴しながら、自分の端末装置で所定の反映操作をして、キャラクタに現実事象に応じた属性情報を反映させるゲームプレイ(例えば属性情報として能力を反映させる場合、キャラクタの育成)を楽しむ。この場合、現実世界で発生する現実事象(単打、本塁打等)によって、キャラクタに反映される属性情報も大きく異なるとともに、現実事象に対して設けられる受付期間中にユーザが反映操作を行わなければ、折角の属性情報反映の機会を逸することになるので、ユーザは、臨場感と緊張感を持って、現実世界の実在イベント(野球の試合等)を視聴しながらゲームをプレイすることができる。これにより、現実世界で発生する現実事象と連動させた、臨場感と緊張感を備えたプレイが可能な興趣性の高いゲームを実現できる。
(2)上記の構成において、前記現実事象は、前記キャラクタの属性を変化させることを可能とするゲーム中でのタイミングを規定する基準事象を含み、前記操作受付手段は、前記基準事象が発生したとき、当該基準事象の1つ前の基準事象後に発生した現実事象に対する前記受付期間を開始することが望ましい。
この構成によれば、現実事象受付手段によってゲーム管理装置に取り込まれる、現実世界で発生する現実事象には、基準事象が含まれる。操作受付手段は、前記基準事象が発生したとき、当該基準事象の1つ前の基準事象後に発生した現実事象に対する前記受付期間を開始する。ここで、基準事象は、キャラクタの属性を変化させることを可能とするゲーム中でのタイミングを規定するものであり、換言すれば、受付期間の開始タイミングを規定する基準の事象である。現実世界で発生する任意の現実事象を基準事象とすることができる。任意の現実事象の全部を基準事象としてもよいし、現実事象の一部を基準事象としてもよい。
例えば、現実世界の野球の試合でのヒット、四死球、犠打、盗塁等を現実事象とし、それら全てを基準事象とした場合、個々の現実事象が発生する毎に、個々の現実事象に対して受付期間が設定される。例えばヒット(=基準事象)が発生したとき、当該基準事象の1つ前の基準事象後に発生した現実事象とは、当該ヒットだけであり、操作受付手段は、当該ヒットの発生後に、当該ヒットに対して受付期間を開始する。
その他の例としては、個々の現実事象(ヒット等)が発生してもすぐに受付期間を開始するのではなく、イニング終了を待って、前イニング終了後に発生した現実事象に対してまとめて受付期間を設定する場合、イニング終了という現実事象が基準事象となる。例えば、第3イニング終了(=基準事象)が発生したとき、当該基準事象の1つ前の基準事象(第2イニング終了)後に発生した現実事象として、例えば、ヒットや盗塁等があった場合、操作受付手段は、当該ヒットや盗塁等に対して受付期間を開始する。要するに、第3イニング中に発生した個々の現実事象に対する受付は、すべてイニング終了時から開始するのである。
なお、本構成は、前述の通り、受付期間の開始のタイミングを規定するものであって、受付期間自体の長さ、換言すれば、受付期間の終了のタイミングについては様々な態様を取り得る。例えば、受付期間の終了タイミングを、受付期間の開始から1分間後、3分間後、5分間後等としてもよいし、次の現実事象が発生するまでとしてもよい。あるいは、次のイニング開始までとしてもよい。
このように、現実事象を基準事象の発生によって区切って、受付期間を設けるので、何を基準事象とするかにより、例えば野球のイニング中に何度も受付期間を発生させたり、イニング終了毎に受付期間を発生させたりすることができ、受付期間設定の頻度を変えることができる。
受付期間を発生させる基準事象が現実世界で発生した場合、それを視聴しているユーザが受付期間の開始を理解し、属性情報の反映機会を逸しないように、受付期間内に操作を行うことになる。もしも現実世界の実在イベント(野球の試合等)の開始から所定時間(例えば15分)経過する毎に、その間に発生した現実事象に対してまとめて受付期間を設定するといったように、基準事象を用いないで受付期間を開始する場合、実在イベントの開始時間さえ分かっていれば、実在イベントを視聴せずとも受付期間の開始(すなわち、反映操作のタイミング)が分かってしまう。これに対して、実在イベントの開始後、いつ発生するか分からない基準事象を基準にして受付期間を開始することにより、実際に実在イベントを視聴していなければ反映操作のタイミングをつかむことが出来ない。前述のように、本ゲーム管理装置は、現実世界の実在イベントを視聴しながら臨場感と緊張感を持ってプレイすることができるゲーム環境をユーザに提供するが、本構成はこのゲームの楽しみ方を最大限に生かせるよう、現実世界の実在イベントをリアルタイムで視聴しながらゲームをプレイする方向にユーザを導くことができる。
(3)上記の(1)または(2)の構成において、前記反映手段は、前記反映処理を実行する場合に、前記受付期間中における前記操作情報を受信するタイミングが遅いほど、前記関係情報に基づいて取得した前記属性情報の前記キャラクタへの反映度を低くすることが望ましい。
この構成によれば、ゲーム管理装置が端末装置での操作を受け付けている受付期間中における操作のタイミングが遅くなるほど、キャラクタへの属性情報の反映度は低く抑えられる。ここで、野球の試合で1イニング終了後に、次のイニング終了までの受付期間が設けられるとともに、当該1イニング中に発生したヒット等の現実事象に応じた属性情報として、「+100」の反映情報が取得された場合を想定して具体例を示す。例えば、ユーザによる反映操作が受付期間の開始から1分以内に行われた場合には「+100」の能力がキャラクタへ反映されるが、反映操作のタイミングが1分経過後から2分以内であった場合は「+80」、2分経過後から3分以内であった場合には「+60」、・・・というように、反映操作のタイミングが受付期間の開始から遅くなるほど反映度が低下する。もちろん、ユーザによる反映操作が行われることなく受付期間を経過してしまった場合には、そのイニングに関するキャラクタの成長はない。なお、この例では1分毎に段階的に反映度を低下させているが、受付期間開始からの経過時間に応じて連続的に反映度を低下させてもよい。
本構成により、受付期間が設定される毎に高い反映度でキャラクタに属性情報を反映させるには、受付期間の開始(その契機となる基準事象が発生したこと等)をユーザが的確に認識し、受付期間の開始直後に反映操作を行う必要がある。そのためには、現実世界の実在イベントをリアルタイムで実際に視聴することが必要であり、それをせずに適当なタイミングで反映操作を行っても、キャラクタを効率よく成長等させることは困難である。前述のように、本ゲーム管理装置は、現実世界の実在イベントを視聴しながら臨場感と緊張感を持ってプレイすることができるゲーム環境をユーザに提供するが、本構成はこのゲームの楽しみ方を最大限に生かせるよう、現実世界の実在イベントをリアルタイムで視聴しながらゲームをプレイする方向に、より強くユーザを導くことができる。
(4)上記の(1)ないし(3)の何れかの構成において、前記関係情報には、前記キャラクタにゲーム上有利となる属性情報を反映させるための現実事象に対応する前記端末装置での操作と、当該操作に基づくゲーム上有利となる属性情報との対応関係と、前記キャラクタにゲーム上不利となる属性情報を反映させるための現実事象に対応する前記端末装置での操作と、当該操作に基づくゲーム上不利となる属性情報との対応関係と、が含まれていることが望ましい。
この構成によれば、関係情報にはゲーム上有利となる属性情報だけではなくゲーム上不利となる属性情報も含まれている。ゲーム上不利となる属性情報を反映させるための現実事象(野球を例に挙げると、守備エラー等)が発生した場合、ユーザの反映操作によりキャラクタにゲーム上不利となる属性情報(例えばマイナスの能力値)が反映されることもある。
このように、ゲーム上不利となる属性情報を含む構成において、現実世界で実際にゲーム上不利となる属性情報を反映させるための現実事象が発生した場合、ユーザは、受付期間中にあえて反映操作を行わず、キャラクタへのゲーム上不利となる属性情報の反映を回避するということも可能である。そのためには、現実世界の実在イベントをリアルタイムで実際に視聴することが必要であり、それをせずにユーザが反映操作を行った場合、ゲーム上不利となる属性情報を反映させてしまうこともあり、キャラクタを効率よく成長等させることは困難である。また、野球の試合を例に挙げると、例えばイニング終了後に受付期間が設けられるとしても、イニング終了だけに注目するのではなく、野球の試合を、リアルタイムで継続的に視聴していないと、ゲーム上不利となる属性情報を反映させる現実事象(守備エラー等)が発生していないかを確認できない。
前述のように、本ゲーム管理装置は、現実世界の実在イベントを視聴しながら臨場感と緊張感を持ってプレイすることができるゲーム環境をユーザに提供するが、ゲーム上不利となる属性情報を含めたことでより緊張感を高めるとともに、現実世界の実在イベントをリアルタイムで視聴しながらゲームをプレイする方向に、より強くユーザを導くことができる。
(5)上記の(1)ないし(4)の何れかの構成において、前記現実事象は、複数の人、複数の動物または複数のグループが競い合うことにより発生するものであり、前記端末装置にて行われた、前記複数の人、複数の動物または複数のグループの中から反映対象を選択する操作に関する操作情報に基づき、当該反映対象を登録する反映対象登録手段をさらに備え、前記反映手段は、前記反映対象登録手段に登録されている前記反映対象についての現実事象に応じた前記属性情報を、前記関係情報に基づいて取得し、取得した当該属性情報を、前記キャラクタに反映させることが望ましい。
この構成において、ゲームの対象となる現実世界の実在イベントは、複数の人が競い合うもの(2人のテニス選手がシングルマッチで対戦するテニスの試合等)、複数の動物が競い合うもの(複数の馬による競馬レース等)、または複数のグループが競い合うもの(2つの野球チームが対戦する野球の試合等)である。そして、次に示すように、ユーザは、反映対象を登録することができ、登録した反映対象の現実世界での活躍に応じた属性情報を、キャラクタに反映させることができる。例えば、現実世界で2つの野球チームAとBが対戦する野球の試合を例に挙げると、ユーザは、自分が応援したい又はより活躍すると予想する側の野球チームを、反映対象として選択することができる。ここで、ユーザが端末装置にて、野球チームAを反映対象として選択する操作を行った場合を想定すると、この操作情報を受信したゲーム管理装置では、反映対象登録手段が野球チームAを反映対象として登録する。この場合、反映手段は、反映処理を実行するに際し、反映対象の野球チームAについての現実事象(野球チームAの選手のヒット等)に応じた属性情報を、関係情報に基づいて取得してキャラクタに反映させる。一方、野球チームBについての現実事象(野球チームBの選手のヒット等)が発生しても、野球チームBは反映対象ではないため、キャラクタの属性に影響を及ぼすことはない。
このように、本構成では、複数のグループ等が競い合う実在イベント中に発生する現実事象の中で、ユーザ自らが選択した反映対象についての現実事象のみがキャラクタの属性に影響を及ぼす。よって、現実世界の実在イベント(野球の試合等)の視聴中において、ユーザが自ら選んだ反映対象(野球チーム等)の応援にも力が入るので、ゲームを楽しむと同時に、野球の試合等の実在イベントもより楽しめるようになる。これが、現実世界と連動させてキャラクタの属性を変化させるゲーム性をより一層高めることに繋がり、興趣性の高いゲームを実現することができる。
(6)上記の(5)の構成において、前記現実事象は、複数のメンバから構成される複数のグループが競い合うことにより発生するものであり、前記反映対象登録手段は、前記端末装置にて行われた、前記反映対象のグループを選択する操作に関する操作情報に基づき、選択されたグループを対象グループとして登録する対象グループ登録手段と、前記端末装置にて行われた、前記対象グループ中の少なくとも1のメンバを前記反映対象として選択する操作に関する操作情報に基づき、選択されたメンバを対象メンバとして登録する対象メンバ登録手段と、を含み、前記反映手段は、前記対象グループ登録手段に登録されている対象グループについての現実事象に応じた前記属性情報を、前記関係情報に基づいて取得し、取得した当該属性情報を、前記キャラクタに反映させるとともに、当該対象グループについての現実事象が前記対象メンバ登録手段に登録されている対象メンバについての現実事象であった場合には、当該対象メンバが反映対象として登録されていない通常のメンバであった場合よりも、当該属性情報を前記キャラクタへより大きく反映させることが望ましい。
この構成において、ゲームの対象となる現実世界の実在イベントは、複数の選手から構成されるグループが複数参加して競い合うイベント(2つの野球チームが対戦する野球の試合等)である。そして、ユーザは、反映対象のグループ(対象グループ)を選択するだけではなく、対象グループ中の少なくとも1のメンバも、反映対象として選択することができる。
ここで、現実世界で2つの野球チームAとBが対戦する野球の試合を例に挙げて説明する。ユーザは、自分が応援したい又は活躍すると予想する野球チーム(対象グループ)と、当該野球チーム内の実在選手(対象メンバ)を選択することができる。例えば、ユーザが端末装置にて、野球チームAを対象グループ、野球チームA内の実在選手Aを対象メンバとして選択する操作を行った場合を想定すると、この操作の情報を受信したゲーム管理装置では、対象グループ登録手段が野球チームAを対象グループとして登録するとともに、対象メンバ登録手段が実在選手Aを対象メンバとして登録する。そして、反映手段は、反映処理を実行するに際し、対象グループ登録手段に登録されている野球チームAについての現実事象に応じた属性情報を関係情報に基づいて取得し、取得した当該属性情報をキャラクタに反映させる。このとき、反映手段は、対象グループについての現実事象が対象メンバ登録手段に登録されている実在選手Aについての現実事象であった場合には、実在選手Aが反映対象として登録されていない通常のメンバであった場合よりも、属性情報をキャラクタへより大きく反映させる。一例を挙げると、野球チームAの実在選手が本塁打を打ってキャラクタに「+100」の能力が属性情報として反映されるところ、本塁打を打ったのが対象メンバである実在選手Aであった場合には、その2倍の「+200」の能力がキャラクタに反映される。
このように、本構成では、ユーザが自ら選んだ対象グループの現実世界での活躍に応じた属性情報がキャラクタに反映されるだけでなく、自らが選択した対象メンバが現実世界で活躍すれば、属性情報をキャラクタへより大きく反映させることができる。よって、例えば、ユーザが登録した対象グループ全体としては不調であったとしても、ユーザが登録した対象メンバが活躍(例えば4打数4安打)すれば、キャラクタの大きな成長等が見込める。また、対象グループも対象メンバも活躍すれば、キャラクタのかなり大きな成長等も可能となる。これにより、現実世界で繰り広げられる野球の試合等の視聴中のユーザの応援も白熱し、ゲームを楽しむと同時に、野球の試合等の実在イベントもより一層楽しめるようになる。これが、現実世界と連動させてキャラクタの属性を変化させるゲーム性をさらに高めることに繋がり、興趣性の高いゲームを実現することができる。
(7)上記の(1)ないし(6)の何れかの構成において、ゲーム管理装置は、ユーザの端末装置にて行われた、当該ユーザが所有する複数のキャラクタの中から属性情報を反映させる対象キャラクタを選択する操作に関する操作情報に基づき、選択された対象キャラクタを登録する対象キャラクタ登録手段をさらに備えることが望ましい。そして、前記反映手段は、前記対象キャラクタ登録手段に登録されている前記対象キャラクタに対して、前記反映処理を実行することが望ましい。
この構成によれば、ユーザは、自分が所有する複数のキャラクタの中から、属性情報の反映させる対象キャラクタを任意に選択することができる。ユーザが端末装置にて対象キャラクタを選択する操作を行えば、この操作の情報を受信したゲーム管理装置では、対象キャラクタ登録手段がユーザによって選択された対象キャラクタを登録する。そして、反映手段は、対象キャラクタ登録手段に登録されている対象キャラクタに対して、前記反映処理を実行する。本構成により、ユーザが、手持ちキャラクタの属性を分析・検討して、所望のキャラクタを対象キャラクタとして選択するということが可能となり、ゲーム性を高めることができる。その一例を挙げると、野球ゲームにおいてユーザが投手、捕手、一塁手、・・・等の各ポジションのキャラクタを所有しており、現実事象に応じた能力値の属性情報がキャラクタに反映される場合、ユーザは、例えば能力的に最も低いポジションのキャラクタを分析し、そのキャラクタを対象キャラクタとすることにより、自分のチームのボトムアップを図る等の戦略を立てることが可能となる。
(8)上記の(1)ないし(4)の何れかの構成において、前記現実事象は、n(nは2以上の整数)の実在物を含む複数の実在物により発生するものであり、
前記反映手段は、前記nの実在物とユーザが所有するnのキャラクタとをそれぞれ一対一で対応付けて、前記nの実在物のそれぞれについての前記現実事象に応じた前記属性情報を、前記関係情報に基づいてそれぞれ取得し、取得した当該属性情報を、各実在物に対応付けているキャラクタにそれぞれ反映させることが望ましい。
この構成では、nの実在物を含む複数の実在物によって現実事象が発生するような現実世界の実在イベントがゲームの対象となる。ここで、実在物とは、現実世界の人または動物を意味する。実在物の具体例を挙げると、野球、サッカー、アメリカンフットボール、バスケット等の各種スポーツの実在選手、テレビ・ラジオ・インターネット・ケーブル・衛星などを使用した放送番組でクイズに回答するタレントや有名人、競馬のレースに出走する競走馬等が該当する。例えば、打順1番〜9番の9人の実在選手(実在物)を含む野球の試合がゲームの対象となる。
そして、反映手段は、現実世界のnの実在物とユーザが所有するnのキャラクタとをそれぞれ一対一で対応付け、n人の実在物のそれぞれについての現実事象に応じた能力情報を、各実在物に対応付けているキャラクタにそれぞれ反映させる。例えば、現実世界の野球の試合に連動する野球ゲームを例に挙げると、現実世界の野球チームの打順1番〜9番の実在選手の個々の活躍(現実事象)を、ユーザの反映操作を介して、ユーザのゲーム内オーダのキャラクタ(打順1番〜9番のキャラクタ)にそれぞれ反映させることができる。この例の場合、ユーザは、現実世界の野球チームの打順1番〜9番の実在選手の活躍を予想し、例えば打順1番および2番の実在選手が大活躍すると予想したならば、ゲーム内オーダの1番および2番に属性情報(能力情報等)を大きく反映させたいキャラクタを配するといった策を立てることも可能となる。
このように、現実世界のnの実在物とユーザが所有するnのキャラクタとをそれぞれ一対一で対応付けて、ユーザの意思(操作)を介してnのキャラクタの属性を変更可能とすることにより、ゲーム性を高めることができる。
(9)本発明の他の一局面によるゲームシステムは、ゲームの管理を行うゲーム管理装置と、当該ゲーム管理装置との間で通信を行う端末装置と、を含むゲームシステムであって、前記ゲーム管理装置または前記端末装置が、ユーザが所有するキャラクタの情報を記憶装置に記憶するキャラクタ記憶制御手段を備える。そして、前記ゲーム管理装置が、現実世界で発生する現実事象に関する情報を受け付ける現実事象受付手段と、前記現実事象に対して所定の受付期間を設定し、当該受付期間中における前記端末装置での操作に関する操作情報を受け付ける操作受付手段と、前記現実事象に対応する前記端末装置での操作と、当該操作に基づく前記キャラクタに反映させる属性情報との関係情報を予め記憶装置に記憶する関係情報記憶制御手段と、前記受付期間中に前記操作情報を受信することにより、前記関係情報に基づいて取得した前記属性情報を、ユーザが所有する前記キャラクタに反映させる反映処理を実行する反映手段と、を備える。
(10)本発明の更に他の一局面によるゲームシステムは、サーバ装置と、端末装置と、を含むゲームシステムであって、前記サーバ装置は、現実世界で発生する現実事象に関する情報を受け付ける現実事象受付手段と、前記現実事象に関する情報を前記端末装置に送信する送信手段と、を備える。そして、前記端末装置は、ユーザが所有するキャラクタの情報を記憶装置に記憶するキャラクタ記憶制御手段と、前記送信手段によって送信された前記現実事象に関する情報を受信する受信手段と、前記現実事象に対して所定の受付期間を設定し、当該受付期間中に所定の操作を受け付ける操作受付手段と、前記現実事象に対応する操作と、当該操作に基づく前記キャラクタに反映させる属性情報との関係情報を予め記憶装置に記憶する関係情報記憶制御手段と、前記受付期間中の前記所定の操作に応じて、前記関係情報に基づいて取得した前記属性情報を、ユーザが所有する前記キャラクタに反映させる反映処理を実行する反映手段と、を備える。
(11)本発明の更に他の一局面によるゲーム管理方法は、端末装置と通信し、ゲームの管理を行うコンピュータにおけるゲーム管理方法であって、コンピュータが、ユーザが所有するキャラクタの情報を記憶装置に記憶するキャラクタ記憶制御ステップと、コンピュータが、現実世界で発生する現実事象に関する情報を受け付ける現実事象受付ステップと、コンピュータが、前記現実事象に対して所定の受付期間を設定し、当該受付期間中における前記端末装置での操作に関する操作情報を受け付ける操作受付ステップと、コンピュータが、前記現実事象に対応する前記端末装置での操作と、当該操作に基づく前記キャラクタに反映させる属性情報との関係情報を予め記憶装置に記憶する関係情報記憶制御ステップと、コンピュータが、前記受付期間中に前記操作情報を受信することにより、前記関係情報に基づいて取得した前記属性情報を、ユーザが所有する前記キャラクタに反映させる反映処理を実行する反映ステップと、を備える。
(12)本発明の更に他の一局面によるプログラムは、コンピュータを、端末装置と通信し、ゲームの管理を行うゲーム管理装置として動作させるためのプログラムであって、前記コンピュータを、ユーザが所有するキャラクタの情報を記憶装置に記憶するキャラクタ記憶制御手段、現実世界で発生する現実事象に関する情報を受け付ける現実事象受付手段、前記現実事象に対して所定の受付期間を設定し、当該受付期間中における前記端末装置での操作に関する操作情報を受け付ける操作受付手段、前記現実事象に対応する前記端末装置での操作と、当該操作に基づく前記キャラクタに反映させる属性情報との関係情報を予め記憶装置に記憶する関係情報記憶制御手段、前記受付期間中に前記操作情報を受信することにより、前記関係情報に基づいて取得した前記属性情報を、ユーザが所有する前記キャラクタに反映させる反映処理を実行する反映手段、として機能させるためのプログラムである。