以下、本発明の一実施の形態に係るゲーム管理装置、ゲームシステム、ゲーム管理方法及びプログラムについて、図面を参照しながら説明する。
〔ゲームシステムの概要〕
本発明の一実施の形態に係るゲーム管理装置が組み込まれたゲームシステムの構成例を、図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に対してゲームサービスの利用登録を行う必要がある。また、既にゲームサービスに登録済みのユーザは、未登録者に対して新規のゲームサービス登録を招待することができるようになっている。ここで、各ユーザに対して「新たなユーザをゲームに招待しょう」という動機付けを与えるため、新規のゲームサービス登録を招待された側の被招待ユーザ(第2のユーザ)がゲームサービスに登録した場合、ゲームサービス登録を招待した側の招待ユーザ(第1のユーザ)には、招待特典が付与されるようになっている。
そして、本実施の形態のゲームサーバ1は、被招待ユーザがゲームサービスに登録したときに1回だけ招待ユーザに所定のポイントを付与するといったありふれた招待特典の供与処理を行うのではなく、以下に説明するようにゲームサービスへ招待した側(招待ユーザ)と招待された側(被招待ユーザ)との継続的な関係性を生かした斬新で魅力的な招待特典を招待ユーザに供与するものである。
すなわち、本実施の形態のゲームサーバ1は、招待ユーザから新規のゲームサービス登録を招待された被招待ユーザがゲームサービスに登録したとき、招待ユーザと被招待ユーザとを関係付けた情報を記憶装置に記憶し、被招待ユーザのゲームサービスへの登録後においても、両者の関係を継続的に管理する。例えば、招待成功(被招待ユーザのゲームサービスへの登録)を契機として招待ユーザが「先輩」、被招待ユーザが「後輩」となり、このような両者の関係性を継続的にゲームサーバ1が管理する。そして、本ゲームサーバ1は、被招待ユーザがゲームサービスに登録した後、招待ユーザに対して、被招待ユーザのゲームへのアクセスまたはゲーム進行状況に応じて、招待特典を付与するという特徴的な構成を有する。例えば、被招待ユーザがゲームサーバ1へアクセス(ログイン)しているときに、取得できるゲーム上の経験値が通常よりも大きくなったり、ゲーム内で発動されたミッションの達成またはイベントの進行が通常よりも早くなったりする招待特典が招待ユーザに付与される。あるいは所定の希少度以上のアイテムが貰えるという招待特典が招待ユーザに付与される。本ゲームサーバ1により供与される招待特典のより詳細な説明については後述する。
この本実施の形態の特徴的な構成によって、招待ユーザにとっては、招待成功後(被招待ユーザのゲームサービスへの登録後)において、被招待ユーザのゲームへのアクセスまたはゲーム進行状況に応じた招待特典を継続的に享受できるので、招待成功時に1回だけポイントが付与される従来の特典よりも魅力的な招待特典となっている。このような従来にはない斬新で魅力的な招待特典をユーザに提供することができるので、ユーザに対して新たなユーザをゲームに招待しようという強い動機付けを与えることができる。
また、招待ユーザに付与される招待特典は、被招待ユーザのゲームへのアクセスまたはゲーム進行状況に応じたものとなっている。例えば、被招待ユーザがゲームサーバ1へアクセス(ログイン)しているときに、取得できるゲーム上の経験値が通常よりも大きくなるという招待特典の場合、被招待ユーザがより多くゲームサーバ1へアクセスしてくれることにより、招待ユーザがより大きな特典を享受できる。よって、招待ユーザは、被招待ユーザにより多くアクセスしてもらうように、「アクセス頑張ろう」、「一緒にアクセスしよう」等のメッセージを送ってコミュニケーションをとることが期待でき、ゲームコミュニティの活性化が図られる。
また、本実施の形態のゲームサーバ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に接続されている図示しないサーバとの通信も制御するようになっている。例えば、図7に示すように、ゲームサーバ1をSNSに組み込んだシステム構成とした場合、ゲームサーバ1の通信制御部15は、SNSサーバ101との間の通信を制御する。
入出力制御部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、およびメッセージ伝達手段61を備えている。これらの各手段51〜61は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。
ゲーム情報管理手段51は、各ユーザのゲーム情報をデータベースサーバ2に蓄積して管理する。ゲーム情報管理手段51で管理されるゲーム情報の項目は、本ゲームサーバ1がユーザに提供するゲームサービスの内容によって異なる。
本ゲームサーバ1によって提供されるゲームの例としては、野球、サッカー、ゴルフなどの各種スポーツを題材としたスポーツゲーム、戦闘を題材とした戦闘ゲーム、音楽シミュレーションゲーム、その他種々のロールプレイングゲーム・育成ゲーム・シミュレーションゲームといったように、ゲーム形式・ジャンルを問わず様々なゲームを挙げることができる。その一例として、本実施の形態では、ゲームサーバ1がゲームサービスとして野球ゲームを提供する場合について、以下に説明する。
本実施の形態では、ユーザがゲーム内において選手キャラクタを所有し、当該選手キャラクタを用いてゲーム内で他のユーザと試合(対戦)を行うことができる野球ゲームを例に挙げる。ユーザが所有する選手キャラクタは、当該選手キャラクタの形態を端末装置3の画面上で視認可能としたカード形式とすることができる。すなわち、選手キャラクタは、デジタル選手カードとしてゲームサーバ1で管理されるとともに、ユーザの端末装置3の画面に表示される。図10には、ユーザの端末装置3の画面に表示される選手カード71を例示しており、当該画面上で、選手カード71は、選手キャラクタの形態を表したデジタル選手カードとして表示されている。ユーザは、ゲームを進行させながら選手カードを集め、自分だけのオリジナルチームを結成し、他のユーザと対戦してランキングを競うことができる。また、ユーザは、集めた選手カード同士を合成することによって選手カード(選手キャラクタ)の能力を向上させる(すなわち、選手を育成する)ことができ、より強いチーム作りを目指してゲームを楽しむことができるようになっている。
このような野球ゲームにおいて、各ユーザのゲーム情報を管理するゲーム情報管理手段51は、図5に示すように、ユーザ情報記憶制御部51a、レベル情報記憶制御部51b、所有選手カード記憶制御部51c、所有ポイント記憶制御部51d、所有コイン記憶制御部51e、所有アイテム記憶制御部51f、試合結果記憶制御部51g、ランキング記憶制御部51hおよび特典情報記憶制御部51iなどを備えている。図6には、ゲーム情報管理手段51の各記憶制御部51a〜51iがデータベースサーバ2に記憶して管理する、各ユーザのゲーム情報の一例(この例ではユーザID=“000001”の1人分のゲーム情報)を示している。
ユーザ情報記憶制御部51aは、各ユーザを一意に識別するユーザIDと対応付けて、ログインID、パスワード、ユーザ名(ゲーム内で使用するニックネーム等)、チーム名等の各ユーザに関するユーザ情報を、ユーザID毎にデータベースサーバ2の所定の記憶領域に記憶する。ここで、ログインIDおよびパスワードは、各ユーザが端末装置3を操作してゲームサーバ1にアクセスしたときのログイン認証に用いられる。ユーザ名およびチーム名は、ユーザがゲームサービスを受けるための利用登録をした際や、ゲームを初めて実行した際に、ユーザが自ら設定した任意の情報である。ユーザ名およびチーム名は、必要に応じてゲーム画面に表示される。
レベル情報記憶制御部51bは、ユーザIDと対応付けて、ユーザのゲームのレベルや所属リーグのレベル等のレベル情報を、ユーザID毎にデータベースサーバ2の所定の記憶領域に記憶する。本野球ゲームでは、例えば、ユーザがゲームを進行させることにより経験値が蓄積され、当該経験値が一定量に達することによりユーザのゲームのレベルがアップするようになっている。また、本野球ゲームでは、例えば、複数の異なるレベルのリーグが存在し、各ユーザのチームが何れかのリーグに所属して、同リーグの他のユーザのチームと自動で試合(リーグ戦)を行うようになっている。また、このリーグ戦の成績に応じて、異なるリーグに所属するユーザのチーム同士の入替戦が自動で実行され、ユーザのチームが所属するリーグレベルが変化するようになっている。なお、ユーザのチームがリーグ戦に参加するには、ユーザが端末装置3でエントリー操作を行ってもよいし、当該エントリー操作がなくともゲームサーバ1が自動的に各ユーザのチームをリーグ戦に参加させるようにしてもよい。レベル情報記憶制御部51bは、各ユーザのゲームのレベルや所属リーグのレベルを、ユーザIDと対応付けて記憶する。
所有選手カード記憶制御部51cは、ユーザIDと対応付けて、ゲーム内でユーザが獲得して所有している選手カードの情報を、ユーザID毎にデータベースサーバ2の所定の記憶領域に記憶する。この選手カードの情報の例としては、選手カードを一意に識別するための識別情報(選手カードID)、選手の能力の高さを示す能力値およびレギュラー選手フラグなどがある。
図6では、3つの能力項目(能力1〜3)に対して選手の能力値を設定できる例を示している。能力項目の例としては、選手カードが野手の場合は、能力1〜3を「打撃」、「走力」、「守備」等とすることができ、また選手カードが投手の場合は、能力1〜3を「球威」、「制球」、「変化」等とすることができる。能力項目はこの例に限らず、増減可能である。例えば、全ての選手カードに対して、「攻撃力」および「防御力(または守備力)」の2つの能力項目を設け、当該2つの能力項目に対して能力値を設定するようにしてもよい。
レギュラー選手フラグとは、ユーザが所有している選手カードのうち、他のユーザのチームとの試合に出場するレギュラー選手(チームオーダーに組み込まれた選手)であるか、それともレギュラー選手以外の控え選手であるかを判別するフラグであり、これが「1」のときレギュラー選手の選手カードとして登録されていることを示す。ユーザは、端末装置3を操作することにより、所有している選手カードからレギュラー選手を選択したり、チームオーダを設定したりすることができるようになっている。
また各選手カード(キャラクタ)には、その他にも、後述する調子、体力、選手レベルなどの各種パラメータが設定される。所有選手カード記憶制御部51cは、これらの各選手カードのパラメータの情報も、ユーザIDと対応付けて、データベースサーバ2に記憶する。
また、データベースサーバ2には、選手カードIDと対応付けられて、選手カードの画像データ、選手名、ポジション、所属球団、能力値(合成により強化されていない初期値)などが記憶された選手カードデータベースが存在し、ゲーム情報管理手段51は、所有選手カード記憶制御部51cが記憶している選手カードIDに基づいて、当該選手カードIDに対応する選手カードの画像データ等を取得できるようになっている。
所有ポイント記憶制御部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により一意に特定される試合は、ユーザが対戦相手を指定して行う個別対戦の試合、および前記リーグ戦の試合を含む。
また、データベースサーバ2は、試合IDと対応付けられて、試合日時(現実世界の試合開始または終了の時間)、勝利したチームのユーザID、敗北したチームのユーザID、対戦スコア、勝利投手キャラクタ、敗戦投手キャラクタ、本塁打を打った選手キャラクタ、試合寸評情報などの試合結果に関する情報が記憶された試合データベースを備えている。そして、ゲーム情報管理手段51は、試合結果記憶制御部51gが記憶している試合IDに基づいて、当該試合IDに対応する試合結果に関する情報を、試合データベースから取得できるようになっている。
ランキング記憶制御部51hは、ユーザIDと対応付けて、前記リーグ戦におけるユーザのチームの勝利数および敗戦数、ならびに勝利数・敗戦数に基づく所属リーグ内の順位などのランキング情報を、ユーザID毎にデータベースサーバ2の所定の記憶領域に記憶する。
特典情報記憶制御部51iは、ユーザIDと対応付けて、ユーザに付与された特典に関する情報を、ユーザID毎にデータベースサーバ2の所定の記憶領域に記憶する。本実施の形態における特典には、被招待ユーザがゲームサービスに新規登録することにより招待ユーザに付与される招待特典および被招待ユーザに付与される新規招待登録特典が含まれる。ここで特典の付与とは、特典の付与前と比較してゲーム上有利な状態(メリット発生状態)にすることであり、図6では、後述するパラメータの値が1段階向上するという招待特典がユーザに付与された例を示している。この特典の詳細は後述する。
次に、図4に示すゲーム進行手段52について説明する。ゲーム進行手段52は、ユーザによる端末装置3に対する操作に応じてゲームを実行し、当該実行結果に応じたゲーム画面データを生成してこれを端末装置3に送信し、端末装置3にユーザの操作に応じたゲーム画面を表示させることによってゲームを進行させる機能を有する。図4に示すように、このゲーム進行手段52は、ゲーム実行手段52aと、ゲーム画面生成手段52bと、ゲーム画面送信手段52cとを備えている。
ユーザの端末装置3のウェブブラウザによってゲーム画面が表示されているとき、ユーザがゲーム画面上の選択可能なボタンオブジェクトやハイパーリンクを選択する操作を行った場合、当該操作に応じたゲーム画面のリクエストが端末装置3のウェブブラウザによってゲームサーバ1へ送信される。このリクエストを受信したゲームサーバ1では、ゲーム実行手段52aが、当該リクエストに応じてユーザのゲーム情報を読み出して演算やデータ処理を行うことによってゲームを実行する。
例えば、対戦モードで他のユーザのチームと対戦するという操作がユーザによって行われた場合を例に挙げると、ゲーム実行手段52aは、対戦を行う両ユーザのユーザIDに対応した両チームの選手カード情報(試合に出場するレギュラー選手の選手カード情報)をデータベースサーバ2から読み出す。そして、ゲーム実行手段52aは、両チームの選手カードの能力値等に基づいて、勝敗を決定する演算を行う。この勝敗決定の演算の例としては、単純に両チームの選手カードの能力値の合計が高い方を勝利チームとしてもよいし、能力値の合計が高い方のチームが勝利する確率を高くして勝利チームを確率演算により求めてもよい。また、ゲーム実行手段52aは、勝敗を決定する演算の前に、チームを構成する選手カードの組み合わせに基づいて、勝敗に影響を与える様々な効果演出を発生させるか否かを決定する演算を行ってもよい。
ゲーム画面生成手段52bは、ゲーム実行手段52aによる実行結果に応じて、例えばHTMLデータからなるゲーム画面データを生成する。HTMLデータには、データベースサーバ2から読み出された選手カード等の画像データを含めてもよい。また、HTMLデータには、端末装置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)を利用した認証を行ってもよい。すなわち、ユーザが携帯電話端末を操作して会員登録した際に、当該携帯電話端末から送信されてくるデータに含まれる個体識別番号または契約者固有IDをゲームサーバ1が取得し、ログインIDおよびパスワードとともに、当該個体識別番号または契約者固有IDもユーザIDと対応付けてデータベースサーバ2に記憶しておくのである。そして、認証手段53は、携帯電話端末からアクセス要求を受けた際には、個体識別番号または契約者固有IDが登録済みであるか否かを判断してログイン認証を行う。これにより、ゲームサーバ1へのアクセス時には、ユーザはログインIDおよびパスワードの入力を省略してログインすることが可能となる。
また、ユーザがゲームサーバ1にアクセスする度にログインIDおよびパスワードを入力する手間を省略できる別の方法としては、HTTP cookieの情報(以下、Cookieと称する)を利用する方法もある。すなわち、ユーザが端末装置3を操作して会員登録した際に、ゲームサーバ1がログインIDおよびパスワードに対応した個体識別情報を発行してデータベースサーバ2へ登録するとともに、当該個体識別情報をCookieとして端末装置3へ送信する。このとき、端末装置3のブラウザは、受信したCookieを端末装置3内へ記憶する。次回からのゲームサーバ1へのアクセスの際には、端末装置3のブラウザがページ閲覧要求とともにCookieをゲームサーバ1へ送信するので、認証手段53は、携帯電話端末からアクセス要求を受けた際には、Cookieの個体識別番号が登録済みであるか否かを判断してログイン認証を行うことができる。
次に、アクセス管理手段54について説明する。アクセス管理手段54は、各ユーザのゲームサーバ1へのアクセスの情報を、データベースサーバ2(記憶装置)に記憶してユーザ毎のアクセスを管理する。このアクセス管理手段54は、アクセス情報記憶制御部54aを備えている。アクセス情報記憶制御部54aが記憶するアクセスの情報の例としては、各ユーザのアクセス履歴(アクセス開始日時およびアクセス終了日時)、現実世界の1日のアクセス回数、現実世界の各日のアクセスの有無等の情報が挙げられる。アクセス管理手段54は、各ユーザがゲームサーバ1にアクセス中(ログイン中)であるか否かのアクセス状態も管理する。
次に、招待処理手段55について説明する。招待処理手段55は、ゲームサービスに登録しているユーザ(招待ユーザ)が端末装置3を操作して、未登録者(被招待ユーザ)をゲームサービスに招待する操作入力を行った場合に、当該未登録者の端末装置3に対して招待メッセージを送信する機能を有する。
ここで、本実施の形態のゲームサーバ1およびデータベースサーバ2をSNSのシステムに組み込むことによって、SNSのサービスの一つとしてソーシャルゲームサービスを提供するゲームシステムとした場合の招待処理手段55の処理について、図7を参照しながら以下に説明する。
図7に示すように、ゲームサーバ1は、SNSサーバ101と通信可能に接続されている。また、SNSサーバ101は、SNSデータベースサーバ102にSNS会員情報等を格納してSNSシステムの動作を制御する。このSNSデータベースサーバ102は、会員データベース102aおよび友達データベース102bを含んでいる。会員データベース102aには、例えば、会員ID、パスワード、氏名、ニックネーム、住所、電話番号、メールアドレス、生年月日、性別、職業、プロフィール等のSNS会員情報が記憶されている。また、友達データベース102bには、SNSの会員同士の友達関係の情報(相互に友達登録を行った会員IDの組み合わせ情報)が記憶されている。このようなSNSのシステムにおいて、ゲームサービスに登録するには、先ずSNSの会員に登録していることが必要である。よって、ゲームサービスに登録しているユーザは、SNSの会員でもある。このようなSNSのシステムにおいて、ゲームサーバ1は、SNSサーバ101を介して、SNSの会員同士の友達関係の情報を入手することができる。
例えば、ユーザの端末装置3の表示部35に表示されるゲームのメイン画面内には、「友達を招待する」ボタンが設けられている。この「友達を招待する」ボタンがユーザにより選択された場合、ゲームサーバ1は、SNSサーバ101を介して、当該ユーザと友達関係にあるSNSの会員の情報を入手する。そして、ゲームサーバ1の招待処理手段55が、このユーザと友達関係にあるSNSの会員であって、且つ、ゲームサービス未登録者をリストアップした招待対象者リスト画面を作成し、当該画面のデータをユーザの端末装置3へ送信する。これにより、ユーザの端末装置3の表示部35には、招待対象者リスト画面が表示される。
ここで、ユーザが招待対象者リストの中から招待を行う友達関係のSNSの会員を選択して「招待する」ボタンを押すと、ゲームサーバ1の招待処理手段55は、招待された友達関係のSNSの会員(被招待ユーザ)の端末装置3へ招待メッセージを送信する。この招待メッセージには、ゲームサーバ1が管理する新規登録ページのURLのハイパーリンクが含まれている。また、このURLには、例えば、招待ユーザの情報(ユーザID)も含まれている。例えば、招待ユーザのユーザID=“000001”の場合、URLは、「http://・・・invite_user_id=000001・・・」等となる。よって、被招待ユーザが招待メッセージ中のURLを選択する操作を行うことによって、ゲームサーバ1は、招待ユーザを認識することができる。その後、被招待ユーザがゲームサービスに新規登録する操作を行えば、ゲームサーバ1の関係管理手段56が、招待ユーザと被招待ユーザとを関係付けた情報を記憶装置に記憶する。
上記の説明では、ユーザと友達関係にあるSNSの会員をゲームに招待する例について説明したが、次に示すように、ユーザがSNSの会員ではない知り合いをゲームに招待することも可能である。すなわち、ユーザがゲームに招待したい知り合いのメールアドレスをゲームサーバ1に通知する操作を行う。これにより、ゲームサーバ1は、知り合いのメールアドレス宛に招待メッセージを送信することができる。この招待メッセージには、SNSの会員登録およびゲームサービスへの新規登録を行うためのページのURLのハイパーリンクが含まれている。また、上記と同様に、このURLには、招待ユーザの情報(ユーザID)も含まれており、被招待ユーザが招待メッセージ中のURLを選択する操作を行うことによって、ゲームサーバ1は、招待ユーザを認識することができるようになっている。
また、上記の説明では、ゲームサーバ1およびデータベースサーバ2をSNSのシステムに組み込んだ場合におけるゲームへの招待について説明したが、ゲームサーバ1およびデータベースサーバ2をSNSのシステムに組み込まずに、独立したゲームシステムとして構築した場合であっても、次のようにしてゲームへの招待が可能である。すなわち、前述の場合と同様に、ユーザがゲームに招待したい知り合いのメールアドレスをゲームサーバ1に通知する操作を行い、ゲームサーバ1が、知り合いのメールアドレス宛に招待メッセージを送信する。この招待メッセージには、ゲームサーバ1が管理する新規登録ページのURLのハイパーリンクが含まれており、当該URLには招待ユーザの情報が含まれているので、被招待ユーザが招待メッセージ中のURLを選択する操作を行うことによって、ゲームサーバ1は、招待ユーザを認識することができる。
なお、被招待ユーザがゲームサービスへ新規登録する画面中に、招待ユーザの情報(招待ユーザのユーザID等)を直接入力することができる欄を設け、当該欄に入力された情報により、ゲームサーバ1が招待ユーザを認識するようにしてもよい。
次に、関係管理手段56について説明する。関係管理手段56は、ゲームサービスに登録しているユーザであってゲームサービス登録を招待した招待ユーザから新規のゲームサービス登録を招待された被招待ユーザがゲームサービスに登録したとき、招待ユーザと被招待ユーザとを関係付けた情報を記憶装置(データベースサーバ2等)に記憶して両者の関係を管理する機能を有する。この関係管理手段56は、招待関係記憶制御部56aを備えている。
図8には、招待関係記憶制御部56aがデータベースサーバ2に記憶して管理する、招待ユーザと被招待ユーザとを関係付けた招待関係情報の一例を示している。本実施の形態では、招待ユーザから新規のゲームサービス登録を招待された被招待ユーザがゲームサービスに登録したとき、招待ユーザが「先輩」、被招待ユーザが「後輩」となり、両ユーザの関係を先輩・後輩として関係管理手段56が管理するようになっている。招待関係記憶制御部56aは、先輩となる招待ユーザのユーザIDと関係付けて、後輩となる被招待ユーザのユーザIDをデータベースサーバ2の所定の記憶領域に記憶する。図8には、ユーザID=“000001”のユーザが、3人のユーザ(ユーザID=“517850”、“518215”、“520113”)の招待に成功し、ユーザID=“000001”のユーザが先輩となり、招待された当該3人のユーザが後輩になった例を示している。また、図8には、ユーザID=“000005”の招待ユーザ(先輩)と、ユーザID=“519367”の被招待ユーザ(後輩)との関係、およびユーザID=“000012”の招待ユーザ(先輩)と、ユーザID=“521501”、“521786”の2人の被招待ユーザ(後輩)との関係も例示している。以下、適宜、招待ユーザを「先輩」、被招待ユーザを「後輩」と呼称する。
次に、特典付与手段57について説明する。特典付与手段57は、招待ユーザから新規のゲームサービス登録を招待された被招待ユーザがゲームサービスに登録した後、招待ユーザと被招待ユーザとの関係性を生かした特典を付与する機能を有する。この特典付与手段57は、招待特典付与部57aおよび新規招待登録特典付与部57bを備えている。
招待特典付与部57aは、被招待ユーザがゲームサービスに登録した後、招待ユーザ(先輩)に対して、被招待ユーザ(後輩)のゲームへのアクセスまたはゲーム進行状況に応じて、ゲーム上有利になる特典や所定の希少度以上のゲームのアイテムを付与する特典等を招待特典として付与する。ここで、ゲームへのアクセスとは、ゲームサービスを提供するゲームサーバ1へのアクセス(ログイン)を意味する。後輩のゲームへのアクセスに応じて招待特典を付与するとは、後輩がゲームへアクセス中であること、後輩がゲームへアクセスした事実があること、または後輩のゲームへのアクセス回数やアクセス日数などに応じて、招待特典を付与することをいう。例えば、後輩がゲームへアクセス中(ログイン中)であるときに、先輩に招待特典のメリットを与える構成とすることができる。また、新規登録後の後輩のゲームへの累積アクセス回数が基準回数に達したときに、先輩に招待特典のメリットを与える構成とすることができる。また、新規登録後の後輩のゲームへの累積アクセス日数が基準日数に達したときに、先輩に招待特典のメリットを与える構成とすることができる。
一例を挙げると、後輩の累積アクセス日数が3日になった時点で200ポイント、6日になった時点で500ポイント、9日になった時点で1000ポイントというように、後輩のゲームへの累積アクセス日数が所定日数に達する毎に、先輩にポイントを付与する。ポイントに代えてアイテムやその他の特典を付与してもよい。また、付与するポイント等の特典は、累積アクセス日数(または累積アクセス回数)が増加するほど大きくすることが望ましい。この場合、先輩は、後輩により多くゲームにアクセスしてもらうように、「アクセス頑張ろう」等のメッセージを送ってコミュニケーションをとることが期待でき、ゲームコミュニティの活性化が図られる。
なお、後輩の累積アクセス日数が基準日数に達するまでにあまりに長い期間を要する(例えば後輩の累積アクセス日数が3日に達するまでに3か月かかる)場合には、先輩にポイント等が付与されないように、招待特典付与のための期限を設け、期限までに累積アクセス日数が基準日数に達する必要があるようにしてもよい。例えば、新規登録から2週間以内という期限までに後輩の累積アクセス日数が3日になれば先輩に200ポイントが付与され、当該期限までに後輩の累積アクセス日数が6日になれば先輩に500ポイントが付与される等とすることができる。このように、新規登録から所定期間以内という期限を設けて、その間の後輩の累積アクセス日数に応じて招待特典を大きくする構成も可能である。あるいは、新規登録から所定期間毎(例えば2週間毎)に、その間の後輩の累積アクセス日数を調べて、累積アクセス日数が多いほど招待特典を大きくする構成も可能である。
また、後輩のゲーム進行状況とは、後輩がゲームをプレイすることによりゲームを進行させた結果としての後輩のゲームのレベル、後輩が所有するキャラクタの能力、後輩のチームの戦力などの状況をいう。例えば、新規登録後における後輩のゲームのレベルが基準値に達したときに、先輩に招待特典のメリットを与える構成とすることができる。また、新規登録後における後輩のキャラクタの能力値(後輩の所有するキャラクタが複数ある場合、それらの最大値、平均値、または合計値等)が基準値に達したとき、先輩に招待特典のメリットを与える構成とすることができる。また、新規登録後における後輩のチームの戦力値が基準値に達したとき、先輩に招待特典のメリットを与える構成とすることができる。
一例を挙げると、後輩のゲームのレベルが「5」になった時点で200ポイント、「10」になった時点で500ポイント、「15」になった時点で1000ポイントというように、後輩のゲームのレベルが所定レベルだけアップする毎に、先輩にポイントを付与する。ポイントに代えてアイテムやその他の特典を付与してもよい。また、付与するポイント等の特典は、ゲームレベルが増加するほど大きくすることが望ましい。この場合、先輩は、後輩にレベルアップを促すために、「レベルアップ頑張ろう」等のメッセージを送ってコミュニケーションをとることが期待でき、ゲームコミュニティの活性化が図られる。同様に、後輩が所有するキャラクタの能力値や後輩のチームの戦力値が所定値だけアップする毎に、先輩にポイントやアイテム等の特典を付与する構成とすることもできる。
新規招待登録特典付与部57bは、被招待ユーザがゲームサービスに登録した後、被招待ユーザ(後輩)に対して、招待ユーザ(先輩)のゲームへのアクセスまたはゲーム進行状況に応じて、ゲーム上有利になるように新規招待登録特典を付与する。ここで、先輩のゲームへのアクセスとは、先輩がゲームへアクセス中であること、先輩がゲームへアクセスした事実があること、先輩のゲームへのアクセス回数やアクセス日数などをいい、先輩のゲーム進行状況とは、先輩がゲームをプレイすることによりゲームを進行させた結果としての先輩のゲームのレベル、先輩が所有するキャラクタの能力、先輩のチームの戦力などの状況をいう。
例えば、先輩がゲームへアクセス中(ログイン中)であるときに、後輩に新規招待登録特典のメリットを与える構成とすることができる。また、後輩の新規登録後における先輩のゲームへの累積アクセス回数が所定回数に達したときに、後輩に新規招待登録特典のメリットを与える構成とすることができる。また、後輩の新規登録後における先輩のゲームへの累積アクセス日数が所定日数に達したときに、後輩に新規招待登録特典のメリットを与える構成とすることができる。これらの場合、後輩は、先輩により多くゲームにアクセスしてもらうように、「アクセス頑張りましょう」等のメッセージを送ってコミュニケーションをとることが期待でき、ゲームコミュニティの活性化が図られる。
また、後輩の新規登録後における先輩のゲームのレベルが所定レベルだけ向上したときに、後輩に新規招待登録特典のメリットを与える構成とすることができる。また、後輩の新規登録後における先輩のキャラクタの能力値が所定値だけ向上したとき(先輩の所有するキャラクタが複数ある場合、能力向上分の最大値、平均値、または合計値等が所定値に達したとき)、後輩に新規招待登録特典のメリットを与える構成とすることができる。また、後輩の新規登録後における先輩のチームの戦力値が所定値だけ向上したとき、後輩に新規招待登録特典のメリットを与える構成とすることができる。これらの場合、後輩は、先輩にレベルアップや戦力アップを促すために、「レベルアップ頑張ろう」等のメッセージを送ってコミュニケーションをとることが期待でき、ゲームコミュニティの活性化が図られる。
ここで、先輩に付与される特典(招待特典)および後輩に付与される特典(新規招待登録特典)の内容について、より詳細に説明する。これらの特典は、当該特典が付与されなかった場合と比較してゲーム上有利になるものであればよく、ゲームの種類や内容に応じて様々な特典が考えられる。あるいは、招待特典または新規招待登録特典は、ゲーム上有利になるものではないが、所定の希少度以上のゲームのアイテムを付与するものであってもよい。
本実施の形態の野球ゲームにおける特典の一例としては、他のユーザのチームと対戦する対戦モードにおいて、対戦n回分(例えば対戦3回分)だけ有利になるというゲーム上のメリットを挙げることができる。対戦n回分のゲーム運びを有利にする方法としては、ユーザのチームの戦力を対戦n回分だけ向上させる方法が考えられる。
ここで、特典によってユーザのチームの戦力を向上させる場合にも、幾つかの方法がある。対戦モードにおいては、ユーザが所有している選手カードの中から試合に出場するレギュラー選手の選手カードが選択されて対戦することになる(例えば、ユーザは、所有している選手カードの中から予め試合に出場するレギュラー選手のカードを選択しておき、当該レギュラー選手のカードでチームオーダを組んで対戦する)。よって、当然ながら、通常は、ユーザの手持ち選手カード以外を自己チームの戦力とすることはできない。
しかし、特典によりチームの戦力を向上させる場合、ユーザの仲間全員の手持ちカードすべての中で、最強の選手カード(最も能力値が高い選手カード)1枚が、自動的に当該ユーザのレギュラー選手のカードの1枚と入れ替わるようにする。この場合、ゲームサーバ1のゲーム進行手段52が、特典対象の対戦の実行時に、自動的に上述の選手カードの入れ替え処理を行うことになる。なお、ユーザの仲間については後述する。もし、ユーザの仲間全員の手持ちカードの中で最強の選手カードを当該ユーザ自らが所有していた場合、当該最強の選手カードよりも能力値が高い助っ人選手カード(ゲームサーバ1が用意する特別な選手カード)1枚が、自動的に当該ユーザのレギュラー選手のカードの1枚と入れ替わるようにしてもよい。
特典によってユーザのチーム戦力を向上させる他の方法としては、対戦モードにおいて試合に出場するレギュラー選手の選手カードの一部または全部の能力値を、所定の割合(または所定の値)だけ向上させるという方法もある。この場合、ゲームサーバ1のゲーム進行手段52が、特典対象の対戦の実行時に、特典を受けたユーザのチームの選手カードの能力値を向上させる処理を行なうことになる。
また、対戦n回分のゲーム運びを有利にする他の方法としては、特典が付与されたユーザのチームが勝利する確率を対戦n回分だけ向上させる(よって、対戦相手のユーザのチームが勝利する確率をその分低下させる)方法も考えられる。例えば、対戦する両ユーザのチームの能力が同一であったとすると、何れのユーザにも特典が付与されていなければ、両チームの勝利確率はともに50%であるが、一方のユーザに特典が付与されている対戦においては、特典が付与されたユーザXのチームの勝利確率を例えば10%向上させて60%とする一方、その対戦相手のユーザYのチームの勝利確率を10%低下させて40%として、ユーザXの方がユーザYよりも勝利確率の面で有利な状態にする。
その他の特典の例としては、次のようなものがある。すなわち、ゲーム中に消費されて減った体力ポイントなどのポイントは、例えば3分経過する毎に1ポイントずつ回復するようになっているが、このポイント回復時間を短縮する(例えば、2分経過する毎に1ポイントずつ回復するようにする)ことが考えられる。この特典が付与される場合、特典情報記憶制御部51iが記憶しているユーザの特典情報として、ポイント回復時間が短縮される有効期間の情報が記憶される。これにより、ゲームサーバ1のゲーム情報管理手段51が、特典が有効な期間(例えば、ユーザが特典の通知を受けてから24時間以内)において、ポイント回復時間を通常時よりも短縮する処理を行うことになる。
また、前述の抽選獲得モードにおいて、レアカード(通常の選手カードよりも抽選確率が低く、希少価値が高い選手カード)が抽選される確率を所定回数(例えば1回)だけ上昇させるという特典も考えられる。この特典が付与される場合、特典情報記憶制御部51iが記憶しているユーザの特典情報として、抽選確率を上昇させる回数が記憶される。そして、ゲームサーバ1のゲーム進行手段52が、特典対象の抽選実行時に、レアカードの抽選確率を一時的に高める処理を行うことになる。
また、抽選獲得モードにおいて、通常は選手カードの抽選を実行するのにポイント(前記交流ポイント等)を必要とするが、所定回数(例えば1回)だけ無料で(すなわちポイントの消費なしに)、選手カードの抽選を受けることができるという特典も考えられる。この特典が付与される場合、特典情報記憶制御部51iが記憶しているユーザの特典情報として、無料(無ポイント)で選手カードの抽選を受けることができる回数が記憶される。
また、ゲームサーバ1が乱数等により抽選で選んだ選手カードを、所定枚数(例えば1枚)だけユーザに付与するという特典も考えられる。ゲームサーバ1が選んだ選手カードを特典としてユーザに付与する場合、ゲーム情報管理手段51の所有選手カード記憶制御部51cが記憶している選手カードIDに、特典として付与される選手カードIDが追加される。
また、前述の体力ポイント、攻撃コスト、パワーポイント、交流ポイントなどのゲーム内で使用される各種ポイントを、所定ポイント分だけユーザに付与するという特典も考えられる。さらには、前述の回復アイテムやフェイクカードなどのゲーム内で使用される各種アイテムを、所定数だけユーザに付与するという特典も考えられる。ゲーム内で使用されるポイントまたはアイテムを特典として付与する場合、特典付与手段57は、ゲーム情報管理手段51の所有ポイント記憶制御部51dまたは所有アイテム記憶制御部51fが記憶している、ユーザの所有ポイントまたはアイテムの所有数を、所定数だけ増加させるようにゲーム情報を変更する。
また、ユーザがゲームをプレイする中で取得できるゲーム上の経験値が通常よりも大きくなるという特典も考えられる。この場合、ゲームサーバ1のゲーム進行手段52が、ユーザによるコマンドボタン操作時に、当該ユーザが獲得する経験値を通常よりも大きくする処理を行なうことになる。さらには、ゲーム内で発動されたミッションの達成またはイベントの進行が通常よりも早くなるという特典も考えられる。この場合、ゲームサーバ1のゲーム進行手段52が、ユーザによるコマンドボタン操作時に、当該ユーザのミッションの達成率またはイベントの進行率を通常よりも高くする処理を行なうことになる。
さらに、以下に示すパラメータ設定手段58が設定する値を上昇させることにより、先輩または後輩に特典を付与する形態もある。
パラメータ設定手段58は、各ユーザの端末装置3に対して、複数段階の値(例えば0〜5の6段階の値)を有する調子のパラメータの何れか一つの値を設定する機能を有する。このパラメータの複数段階の値は、パラメータ表示画像としての複数の調子マークに対応している。調子マークは、ゲームをプレイしているユーザまたは当該ユーザのキャラクタの調子の良さ(または体調の良さ)を疑似的に表示する画像である。図9には、データベースサーバ2の所定領域に記憶されているパラメータの値と調子マークとの対応関係を例示している。図9の例では、調子のパラメータには0〜5の6段階の値(0=不調、1=普通、2=好調、3=かなり好調、4=絶好調、5=最好調)が設定されており、値が大きいほど調子がよい状態を示す。
パラメータ設定手段58によるパラメータの設定方法には様々な方法が考えられる。例えば、ユーザの端末装置3がゲームサーバ1にアクセスする毎に、乱数によりランダムにパラメータの値を設定するようにしてもよい。あるいは、連続してゲームサーバ1にアクセスする日数が多くなるほど、パラメータの値を高く設定するようにしてもよい。
また、パラメータ設定手段58は、ユーザの端末装置3がゲームサーバ1にアクセスしていないときにも、当該ユーザの端末装置3に対してパラメータの値を設定可能である。例えば、ユーザの端末装置3がゲームサーバ1にアクセスしているか否かにかかわらず、毎日、現実世界の所定時刻(例えば午前0時)に、各ユーザに適用するパラメータの値を乱数等に基づいて設定するようにしてもよい。
ゲーム画面送信手段52cは、パラメータ設定手段58が設定した値に対応した調子マークを含むゲーム画面をユーザの端末装置3へ送信するようになっている。これにより、ユーザの端末装置3には、調子マークを含むゲーム画面が表示され、ユーザは調子マークを視認して現在の調子の良さを認識することになる。
また、ゲーム進行手段52は、パラメータ設定手段58が設定した値が高いユーザほど、ゲーム上有利になる程度が大きくなるように当該ユーザのゲーム進行を制御するようになっている。例えば、ゲーム進行手段52は、パラメータ設定手段58が設定した値が高いほど、ユーザがゲームをプレイする中で取得できるゲーム上の経験値がより多くなるようにゲーム進行を制御する。また、ゲーム進行手段52は、パラメータ設定手段58が設定した値が高いほど、ゲーム内で発動されたミッションの達成またはイベントの進行がより早くなるようにゲーム進行を制御する。また、ゲーム進行手段52は、パラメータ設定手段58が設定した値が高いほど、前述の抽選獲得モードにおいて、レアカードやレアアイテムが抽選される確率がより向上するように制御する。
そして、招待特典付与部57aは、後輩がゲームにアクセスしているとき、先輩の端末装置3に対してパラメータ設定手段58が設定した値を上昇させる。これにより、例えば、後輩がゲームにアクセスしているとき、先輩の端末装置3に対して設定されたパラメータの値が所定値(例えば1つ)だけ上昇するようになっている。パラメータの値が上昇すれば、ゲーム上有利になる程度が大きくなるので、招待特典付与部57aは、パラメータの値の上昇という形態を介して先輩に招待特典を付与することができる。
また、複数のユーザの招待に成功したことにより先輩に後輩が複数いる場合(すなわち、招待ユーザが招待した複数の被招待ユーザがゲームサービスに登録している場合)、招待特典付与部57aは、ゲームにアクセスしている後輩の人数が多いほど、先輩の端末装置3に対してパラメータ設定手段58が設定した値を、より大きく上昇させることが望ましい。例えば、招待特典付与部57aは、ゲームにアクセスしている後輩の人数がn人の場合、パラメータの値をn段階上昇させるようになっている。例えば、先輩の端末装置3に対してパラメータ設定手段58が設定した値が「1=普通」であり、ゲームにアクセスしている後輩の人数が3人のときは、パラメータの値を3段階上昇させて、「4=絶好調」にする。なお、上昇させたパラメータの値が最大値(5=最好調)を超える場合は、最大値となる。
また、複数の後輩がいる先輩の場合、招待特典付与部57aは、ゲームにアクセスしている後輩の人数にパラメータの値を対応させてもよい。例えば、ゲームにアクセスしている後輩の人数1人〜5人と、パラメータの値1〜5とを対応させる。すなわち、ゲームにアクセスしている後輩が1人でもいる場合は、パラメータの最低値「0=不調」が選択されることはなく、ゲームにアクセスしている後輩の人数が多いほど、パラメータの値が大きくなる。なお、パラメータの値の最大値が「5=最好調」であるため、ゲームにアクセスしている後輩の人数が6人以上の場合は、パラメータの最大値「5=最好調」を対応させる。
また、複数の後輩がいる先輩の場合、招待特典付与部57aは、全ての後輩がゲームにアクセスしているとき、先輩の端末装置3に対してパラメータ設定手段58が設定した値を、全ての後輩がゲームにアクセスしていない場合と比較して大幅に上昇させてもよい。例えば、全ての後輩がゲームにアクセスしているとき、先輩の端末装置3に対して設定されたパラメータの値が最大値「5=最好調」まで上昇するようにすることができる。
また、新規招待登録特典付与部57bは、先輩がゲームにアクセスしているとき、後輩の端末装置3に対してパラメータ設定手段58が設定した値を上昇させる。これにより、先輩がゲームにアクセスしているとき、後輩の端末装置3に対して設定されたパラメータの値が所定値(例えば2つ)だけ上昇するようになっている。あるいは、先輩がゲームにアクセスしているとき、後輩の端末装置3に対して設定されたパラメータの値が最大値「5=最好調」まで上昇するようにしてもよい。パラメータの値が上昇すれば、ゲーム上有利になる程度が大きくなるので、新規招待登録特典付与部57bは、パラメータの値の上昇という形態を介して後輩に新規招待登録特典を付与することができる。
ところで、後輩がゲームサービスに登録した後、当該後輩のゲーム進行に伴って変化する、後輩に関するゲーム上の値が所定値に達した後は、招待特典付与部57aが先輩に対して当該後輩を招待したことによる招待特典の付与処理を実行しないようにすることが望ましい。これは、後記するとおり、特典を無期限に付与することを回避することで、新たな招待を行う意欲を喚起するためである。ここで、「後輩のゲーム進行に伴って変化する、後輩に関するゲーム上の値」とは、後輩のゲームのレベルの値、後輩の所有するキャラクタの能力値、後輩のチームの戦力値、後輩が到達しているゲーム内のステージの難易度の値などをいう。
例えば、後輩のゲームのレベルは、後輩がゲームをプレイして経験値を取得することにより上昇するものであり、後輩が実際にゲームをプレイしなければ所定値に達しない。同様に、後輩の所有するキャラクタの能力値や後輩のチームの戦力値なども、後輩が実際にゲームをプレイしてキャラクタの育成やチーム戦力向上を図らなければ所定値に達しないものである。また、ゲーム内に難易度の異なる複数のステージが設けられており、1つのステージをクリアしたら1つ難易度の高い別のステージに進むようなゲームの場合、後輩が実際にゲームをプレイしてステージをクリアしなければ所定の難易度に達しない。すなわち、「後輩のゲーム進行に伴って変化するゲーム上の値」とは、新規登録の後輩がある程度ゲームをプレイしたタイミングを示す指標となるものである。
一例を挙げると、「後輩のゲーム進行に伴って変化する、後輩に関するゲーム上の値」を後輩のゲームのレベルとしたとき、後輩のゲームのレベルが初心者レベルを突破した値(例えばレベル15)に達した後においては、招待特典付与部57aが先輩に対して招待特典の付与処理を実行しないようにすることができる。
上記のように後輩がある程度ゲームをプレイすることによって「後輩のゲーム進行に伴って変化する、後輩に関するゲーム上の値」が所定値に達した後において、先輩に対する招待特典の付与を中止することにより、ユーザに対して新たなユーザの招待を促すことができる。すなわち、ユーザが先輩として招待特典を無期限に受け続けることができる場合、既に受けている魅力的な招待特典に満足しているユーザは、新たなユーザの招待に積極的にならないことも考えられる。一方、ユーザが一定の招待特典を享受したタイミングで特典の付与を中止することによって、再度、魅力的な招待特典を受けたいという気持ちがユーザに働き、もう一度新たなユーザをゲームに招待しようという強い動機付けをユーザに与えることができるのである。
本実施の形態では、先輩が招待特典を享受できる期間を現実世界の実時間ではなく、「後輩のゲーム進行に伴って変化する、後輩に関するゲーム上の値が所定値に達するまで」としている。これは以下の理由による。本実施の形態において、先輩に付与される招待特典は、後輩のゲームアクセスまたはゲーム進行状況に応じたものとなっている。よって、もし先輩が招待特典を享受できる期間を現実世界の実時間とした場合は、仮に後輩がゲームサービスに新規登録した後、一度もゲームにアクセスせず(ゲームを全く進行させず)又はゲームアクセスが僅かである場合、その間、先輩は招待特典を全く享受できない又は僅かしか享受できないにもかかわらず、上記の現実世界の実時間が経過してしまえば、それ以降、招待特典を享受できる機会は失われる。これに対して、先輩が招待特典を享受できる期間を「後輩のゲーム進行に伴って変化する、後輩に関するゲーム上の値が所定値に達するまで」とすることにより、現実世界の実時間によらず、後輩がある程度ゲームをプレイして先輩が特典によるメリットを実感できるまで招待特典の付与期間が確保されることになる。
また、後輩がゲームサービスに登録した後、「当該後輩のゲーム進行に伴って変化する、後輩に関するゲーム上の値」が所定値に達した後は、新規招待登録特典付与部57bが後輩に対して新規招待登録特典の付与処理を実行しないようにすることが望ましい。一例を挙げると、後輩のゲームのレベルが初心者レベルを突破した値(例えばレベル15)に達した後においては、新規招待登録特典付与部57bが、当該後輩に対して新規招待登録特典の付与処理を実行しないようにする。
上記のように後輩がある程度ゲームをプレイすることによって「後輩のゲーム進行に伴って変化する、後輩に関するゲーム上の値」が所定値に達した後において、後輩に対する新規招待登録特典の付与を中止することにより、ユーザに対して新たなユーザの招待を促すことができる。すなわち、ユーザが後輩として新規招待登録特典を無期限に受け続けることができる場合、既に受けている魅力的な新規招待登録特典に満足しているユーザは、自らが新たなユーザを招待して招待特典を受けようとする気持ちが希薄になることも考えられる。一方、ユーザが一定の新規招待登録特典を享受したタイミングで特典の付与を中止することによって、新規招待登録特典と同様の内容の招待特典を受けたいという気持ちがユーザに働き、今度は自分が新たなユーザをゲームに招待しようという強い動機付けをユーザに与えることができるのである。
次に、報知手段59について説明する。報知手段59は、特典(招待特典または新規招待登録特典)が付与されたユーザの端末装置3に対して、特典が付与されている旨を報知する機能を有する。報知手段59による特典の報知の例を、図10および図11に示している。図10は、招待特典が付与された先輩の端末装置3の表示部35に表示されるゲームのメイン画面の一例を示すものである。また、図11は、新規招待登録特典が付与された後輩の端末装置3の表示部35に表示されるゲームのメイン画面の一例を示すものである。
ゲームサーバ1における特典付与処理後に、ユーザがゲームのメイン画面を表示させる操作をしたとき、ゲームサーバ1の報知手段59からは、図10または図11に示すメイン画面を表示させる画面データが端末装置3へ送信されてくる。このメイン画面には、ユーザが所有する選手カードの中から4番打者およびエース投手として選択された選手カード71、ユーザのゲーム情報72、調子マーク73などが表示されるとともに、特典通知情報74も表示される。なお、メイン画面の詳細については、後述する。
図10に示すように、先輩の端末装置3のメイン画面に表示される特典通知情報74は、例えば「後輩2人アクセス中につき調子2段階アップ!」というような、招待特典が付与されていることが分かる内容である。この例において、先輩が特典通知情報74の中の「後輩2人」の部分に設けられたハイパーリンク75を選択する操作を行うことにより、ゲームサーバ1からは、アクセスしている後輩2人の名前等の情報を表示する画面データが先輩の端末装置3へ送信され、アクセスしている後輩2人の情報を確認することができるようになっている。
また、図11に示すように、後輩の端末装置3のメイン画面に表示される特典通知情報74は、例えば「先輩アクセス中につき調子MAX!」」というような、新規招待登録特典が付与されていることが分かる内容である。この例において、後輩が特典通知情報74の中の「先輩」の部分に設けられたハイパーリンク76を選択する操作を行うことにより、ゲームサーバ1からは、先輩の名前等の情報を表示する画面データが後輩の端末装置3へ送信され、先輩の情報を確認することができるようになっている。
このように報知手段59は、メイン画面等に特典の発生情報を表示させてユーザへの報知を行うので、前記のゲーム画面生成手段52bおよびゲーム画面送信手段52cと協働して当該報知の処理を行うようになっている。
次に、図4に示す仲間管理手段60について説明する。仲間管理手段60は、各ユーザを中心とするグループに所属する仲間関係にある仲間ユーザの情報をデータベースサーバ2(記憶装置)に記憶してユーザ毎の仲間管理を行う機能を有する。なお、ここでいうグループとは、あくまで1ユーザの視点から見た自分の仲間の集団を示しており、これらの集団を構成する各ユーザがこの集団のみに所属するわけではない。各ユーザもまた、個々に自分を中心とする「仲間」のグループを有している。この仲間管理手段60は、仲間情報記憶制御部60aを備えている。
図12(a)には、仲間情報記憶制御部60aがデータベースサーバ2に記憶して管理する、各ユーザの仲間に関する情報の一例を示している。仲間情報記憶制御部60aは、ユーザIDと対応付けて、仲間の制限数の情報、すでに仲間の関係になっている仲間ユーザのユーザID、仲間申請中のユーザのユーザID、および仲間申請を受けているが未承認のユーザのユーザIDなどの仲間に関する情報を、ユーザID毎にデータベースサーバ2の所定の記憶領域に記憶する。図12(a)の例では、ユーザID=“000001”のユーザ1人分の仲間に関する情報を示しており、仲間制限数は20人、当該ユーザの仲間ユーザは10人、仲間申請中のユーザは1人、仲間申請を受けているが未承認のユーザは0人である。
本実施の形態の野球ゲームでは、仲間をつくることによって、仲間の関係になった両ユーザにボーナスポイントが付与される(例えば、前記体力ポイントや攻撃コストの最大値を所定ポイントだけ増加させることができる)。また、仲間のユーザと協力して試合をしたり、仲間同士で選手カードのプレゼントや応援を行ったりすることで、ゲームを有利に進めることができるゲーム仕様となっている。このようにゲーム内で仲間をつくることによるメリットをユーザに付与することにより、仲間を作ることを促進している。但し、各ユーザには、ゲームの進行度合いに応じた仲間の制限数(仲間をつくることができる上限人数)が設定されており、仲間情報記憶制御部60aがユーザIDと対応付けて仲間の制限数を記憶している。例えば、仲間の制限数は、ユーザのゲームのレベルが高くなるほど大きくなるように設定される。これにより、ユーザは、より多くの仲間を作ってゲームを有利にするために、ゲームを継続的に進めてレベルアップを図ろうとする動機付けを与えられることになる。
本実施の形態において、2人のユーザが仲間関係になるには、2つの形態が用意されている。第1の形態としては、2人のユーザ間においてなされる仲間申請とその承認の操作によるものである。この場合、両ユーザの何れか一方が、他方のユーザに対してゲームサーバ1を介して仲間申請を行う。この仲間申請の操作例としては、先ず、仲間を作ろうとするユーザが、端末装置3の画面上に仲間候補の対象者をリストアップする操作を行う。このユーザによる操作に応じて、ゲームサーバ1が仲間候補の対象者をリストアップした画面データを送信することにより、複数の仲間候補がリストアップされた画面がユーザの端末装置3に表示される。ここで、ユーザは、画面上にリストアップされた対象者のゲームのレベルや所属リーグレベル等を確認し、仲間にしたいユーザを選択して仲間申請の操作を行う。
例えば、ユーザID=“000001”のユーザAが、ユーザID=“000002”のユーザBに対して仲間申請の操作を行った場合を考える。図12(a)に示すように、この操作に応じてゲームサーバ1の仲間情報記憶制御部60aは、仲間申請を行ったユーザAのゲーム情報として、当該ユーザAのユーザID=“000001”と対応付けて、被申請者であるユーザBのユーザID=“000002”を、「申請中のユーザID」として記憶する。
さらに、図13(a)に示すように、仲間情報記憶制御部60aは、被申請者であるユーザBのゲーム情報として、当該ユーザBのユーザID=“000002”と対応付けて、仲間申請を行ったユーザAのユーザID=“000001”を、「未承認のユーザID」として記憶する。そして、ゲームサーバ1は、その後、ユーザBの端末装置3がゲームサーバ1にログインしたときに、ユーザAから仲間申請があった旨を通知する。
そして、仲間申請を受けたユーザBは、ゲームサーバ1から受信したユーザAのユーザレベルや所属リーグレベル等の情報を、端末装置3の画面上で確認し、仲間として承認するか拒否するかを選択する操作を行う。ここで、ユーザBが仲間として承認する操作を行った場合、この操作に応じてゲームサーバ1の仲間管理手段60は、ユーザAとユーザBとの仲間関係を成立させ、両ユーザA・Bを仲間登録する。すなわち、図12(b)に示すように、ユーザAのゲーム情報として、当該ユーザAのユーザID=“000001”と対応付けて、ユーザBのユーザID=“000002”を、「仲間ユーザID」として記憶し、「申請中のユーザID」からユーザBのユーザIDを削除する。
さらに、図13(b)に示すように、仲間情報記憶制御部60aは、ユーザBのユーザID=“000002”と対応付けて、ユーザAのユーザID=“000001”を、「仲間ユーザID」として記憶し、「未承認のユーザID」からユーザAのユーザIDを削除する。そして、ゲームサーバ1は、その後、ユーザAの端末装置3がゲームサーバ1にログインしたときに、ユーザBから仲間の承認があった旨を通知する。
2人のユーザが仲間関係になる第2の形態としては、招待ユーザから新規のゲームサービス登録を招待された被招待ユーザがゲームサービスに登録したとき、ゲームサーバ1の仲間管理手段60が、自動的に招待ユーザ(先輩)と被招待ユーザ(後輩)とを仲間として登録するというものである。すなわち、本実施の形態では、招待ユーザと被招待ユーザとは、先輩と後輩という関係(主に特典付与処理に用いられる関係)だけでなく、仲間関係も構築されることになる。上述のようにユーザのゲームのレベルに応じて仲間の制限数が設定されているので、通常は仲間の制限数を超えて仲間をつくることはできないのであるが、招待を契機として招待ユーザと被招待ユーザとが仲間登録されるときは、仲間の制限数を超えるときでも仲間登録が行われるようにしてもよい。
次に、図4に示すメッセージ伝達手段61について説明する。
メッセージ伝達手段61は、各ユーザの端末装置3から送信された他のユーザ宛のメッセージを受信するとともに、当該メッセージを当該他のユーザへ伝達する機能を有する。このメッセージ伝達手段61は、メッセージ記憶制御部61aを備えている。
図14には、メッセージ記憶制御部61aがデータベースサーバ2に記憶して管理する、受信メッセージに関する情報の一例を示している。このメッセージ記憶制御部61aは、メッセージを受け取った受信側ユーザのユーザIDと対応付けて、送信元のユーザID、メッセージの内容、送信日時などのメッセージに関する情報を、受信側のユーザのユーザID毎にデータベースサーバ2の所定の記憶領域に記憶する。図14の例では、ユーザID=“000002”の受信側ユーザ1人分の受信メッセージに関する情報を示しており、当該ユーザは、ユーザID=“000001”のユーザから「アクセス頑張ろう!」、ユーザID=“000038”のユーザから「おはようございます!今週はアクセス頑張りましょう!」、ユーザID=“000145”のユーザから「今週もよろしく!」というメッセージをそれぞれ受け取っている。
ここで、ユーザが自分の仲間ユーザに対してメッセージを送る操作の一例を説明する。図15(a)には、ゲームサーバ1から送信された画面データに基づいて、ユーザの端末装置3に表示される仲間リスト画面の一例を示している。この仲間リスト画面は、例えばユーザが端末装置3を操作してメイン画面中の「仲間メニュー」を選択することによって表示される画面である。この仲間リスト画面には、ユーザと仲間関係にある仲間ユーザの情報がリストアップされて表示される。なお、画面に表示しきれない仲間ユーザの情報については、画面をスクロールするまたは仲間リストの2ページ目以降をゲームサーバ1にリクエストして別画面として表示することができる。
この仲間リスト画面内にはリストアップされた仲間ユーザ毎の情報表示領域が設けられており、各情報表示領域には、仲間ユーザが自分の先輩であれば「先輩」、仲間ユーザが自分の後輩であれば「後輩」の旨を表示する関係表示オブジェクト80が表示される。図15(a)の例では、ユーザXが「後輩」である旨を関係表示オブジェクト85で示している。また、仲間ユーザ毎の情報表示領域には、仲間ユーザのゲーム情報81(ユーザ名、ゲームのレベル、仲間の人数、所有する選手カードの数を表す部員数等)、当該ユーザの分身的なキャラクタであるアバター82、当該ユーザの所有する4番打者の選手カード83などとともに、応援ボタン84というオブジェクトも表示される。
そして、ユーザがこの応援ボタン84を選択することで、自分の仲間ユーザを応援することができるようになっている。例えば、ユーザが応援ボタン84を押して仲間ユーザを応援すると、当該ユーザに所定の交流ポイントが付与されるとともに、当該ユーザと当該仲間ユーザとの友情度が向上するようになっている。また、ユーザは、仲間ユーザを応援するだけでなく、以下に説明するように、さらにメッセージも送ることができる。
ユーザの端末装置3における操作により応援ボタン84が選択された場合、当該操作が端末装置3からゲームサーバ1へ伝えられる。その後、ゲームサーバ1からは、例えば図15(b)に示すメッセージ入力画面のデータが端末装置3へ送信され、端末装置3に当該メッセージ入力画面が表示される。このメッセージ入力画面には、例えば、仲間ユーザ(図15(b)の例では後輩にあたるユーザX)に対して応援を行った旨を示す文章等が表示されるとともに、メッセージ入力領域85および送信ボタン86というオブジェクトも表示される。そして、ユーザは、端末装置3を操作してメッセージ入力領域85に任意のメッセージを入力し、送信ボタン86を選択することによって、端末装置3からは仲間ユーザ宛のメッセージがゲームサーバ1へ送信される。図15(b)では「アクセス頑張ろう!」というメッセージをユーザが入力した例を示している。なお、データベースサーバ2における記憶容量を考慮して、メッセージ入力領域85に入力できる文字に制限(例えば全角30文字以内)を設けてもよい。
また、メッセージ入力画面には、仲間ユーザ(この例ではユーザX)のページへ遷移するためのハイパーリンク87が表示されており、このリンクを選択することにより当該仲間ユーザのゲーム情報の詳細が記載されたページを表示できる。また、メッセージ入力画面には、仲間リストへ遷移するためのハイパーリンク88やメイン画面へ遷移するためのハイパーリンク89なども表示されており、これらのリンクを選択することにより仲間リストやメイン画面に戻れるようになっている。
このメッセージ入力画面でのユーザの操作により端末装置3からメッセージが送信された場合、ゲームサーバ1では、メッセージ伝達手段61のメッセージ記憶制御部61aが、端末装置3から受信した仲間ユーザ宛のメッセージを、当該仲間ユーザのユーザIDと対応させてデータベースサーバ2に記憶する(図13参照)。そして、当該仲間ユーザの端末装置3がゲームサーバ1へアクセスしたとき、ゲームサーバ1のメッセージ伝達手段61は、メッセージ、送信元のユーザ名、送信時間等を表示させる画面データを端末装置3に送信する。これにより、この画面データを受信したユーザの端末装置3にはメッセージ等が表示され、他の仲間から受け取ったメッセージを画面で確認できるようになっている。
このように、本実施の形態のゲームシステムでは、前記図15(a)(b)に例示するようなコミュニケーションツールを使用して、仲間同士が何時でもコミュニケーションをとることができるようになっている。当然ながら、先輩と後輩とが前記のコミュニケーションツールを使用して、互いにメッセージのやり取りをすることも可能である。
前記図15(a)(b)の例では、ユーザの仲間に対してメッセージを送る例を説明したが、仲間関係にはない他のユーザに対しても、応援を行ったりメッセージを送ったりすることができる。例えば、図示しない仲間候補リスト画面にリストアップされた仲間ではない他のユーザに対して、仲間の場合と同様の操作により、応援やメッセージを送ることが可能である。
ところで、上記の説明では、アクセス管理手段54が管理している各ユーザのアクセス情報、関係管理手段56が管理している先輩・後輩の関係情報、仲間管理手段60が管理している各ユーザの仲間情報、およびメッセージ伝達手段61が管理しているメッセージに関する情報は、便宜上、ゲーム情報管理手段51が管理している各種情報とは区別して記載しているが、これらの情報は何れもゲームサーバ1が管理するゲーム情報に含まれるものである。
〔ゲームシステムの動作〕
上記の構成において、本発明の実施の形態に係るゲームシステムの動作例を、図16のフローチャートを参照しながら以下に説明する。図16は、ユーザが端末装置3を操作してゲームサーバ1にアクセスしてゲームサービスを受けるときの、端末装置3およびゲームサーバ1の処理の流れを示すものである。
ユーザがゲームサービスを受ける場合、先ず、端末装置3の操作入力部40を操作してウェブブラウザを起動する(S11)。その後、ユーザは、ゲームサーバ1が管理するゲームサイトにアクセスする操作を行い、これにより、端末装置3からゲームサーバ1へアクセスリクエストが送信される(S12)。このとき、ゲームサーバ1は、端末装置3からのアクセスに対するログイン認証を行い(S21)、ゲームサービスの利用登録がなされているユーザからのアクセスであることを確認する。その後、ゲームサーバ1は、HTML等で記述されたメイン画面データを端末装置3に送信する(S22)。そして、メイン画面データを受信した端末装置3では、ウェブブラウザが当該データを解釈し、メイン画面を表示部35に表示させる(S13)。
図10に例示するように、メイン画面には、ユーザが所有する選手カードの中から4番打者およびエース投手として選択された選手カード71、ユーザのゲーム情報72(ゲームのレベル、体力ポイント、攻撃ポイント、部員数、パワーポイント、交流ポイント等)、調子マーク73などが表示される。また、ユーザに特典が付与されている場合は、上述の特典通知情報74なども表示される。さらに、このメイン画面には、端末装置3の方向キー等を操作して画面をスクロールさせることによって、図示しないゲームモードの選択ボタン、各種メニューボタン、仲間の動き情報、他のユーザからのメッセージなど、様々なオブジェクトや情報が表示されるようになっている。
ここでユーザが、画面に表示されている選択可能なボタン等のオブジェクトやハイパーリンクを選択する操作をすると、当該操作に応じた画面のリクエストが端末装置3からゲームサーバ1へ送信される(S14)。このリクエストを受信したゲームサーバ1は、ユーザの操作に応じた演算処理やデータ処理を行ってゲームを実行し(S23)、実行結果を反映させたゲーム画面データを端末装置3へ送信する(S24)。そして、画面データを受信した端末装置3では、ウェブブラウザが当該データを解釈し、ゲーム画面を表示部35に表示させる(S15)。HTMLデータ等からなる画面データにウェブブラウザのプラグインによって動作するスクリプト(プログラム)が埋め込まれている場合、ウェブブラウザにおいて当該スクリプトが実行され、端末装置3には動きのあるゲーム画面が表示される。
以降は、ユーザの端末装置3においては前記のS14およびS15が繰り返され、ゲームサーバ1においては前記のS23およびS24が繰り返され、これにより、端末装置3の画面に表示されている選択可能なボタン等をユーザが選択する度に、端末装置3のゲーム画面が次々と切り替わり、ゲームを進行させることができる。
その後、ユーザが端末装置3を操作してゲーム画面を閉じた場合(S16)、ゲームサーバ1はログアウト処理を行う(S25)。例えば、ユーザがウェブブラウザを閉じた場合、ゲームサーバ1はセッションタイムアウト後にログアウト処理を行う。
ところで、本ゲームシステムにおいては、ユーザがゲームサーバ1からログアウトした場合であっても、ゲームサーバ1側で当該ユーザのゲーム情報を読み出してゲームを進行させることができる。例えば、ログアウトしているユーザのチームに対して、ログインしている他のユーザが対戦(個別対戦)を仕掛けてくることもあり、ゲームサーバ1のゲーム進行手段52は、ユーザがログインしているか否かに依らずに、各ユーザのゲーム情報をデータベースサーバ2から読み出して対戦を実行し、その実行結果を反映させて各ユーザのゲーム情報を更新する。また、リーグ戦モードでは、ユーザによる端末装置3の操作なしに、ゲームサーバ1のゲーム進行手段52が、各ユーザのゲーム情報をデータベースサーバ2から読み出して、自動でリーグ戦の試合を実行する。このように、ユーザがゲームサーバ1からログアウトしているときに実行された対戦の結果は、その後、ユーザがゲームサーバ1にアクセスしたときに画面で確認することができる。
〔ゲーム管理装置の動作〕
次に、本発明の実施の形態に係るゲーム管理装置のより詳細な動作例を、図17ないし図23のフローチャートを参照しながら説明する。図17は、ある一人のユーザを対象としたゲームサーバ1の処理の流れを示すものであり、ゲームサーバ1が管理している各々のユーザに対して同様の処理が行われる。
図17に示すように、ゲームサーバ1の認証手段53は、ユーザの端末装置3からアクセス要求を受けたとき(S31でYES)、端末装置3から送信されてきたログインID・パスワード、または携帯電話端末の個体識別番号等に基づいて、アクセスを許可するか否かを判断するログイン認証を行う(S32)。ここで、アクセスを許可しない場合(S32でNO)、ゲームサーバ1は、端末装置3にゲームサービスの利用登録を促す画面データを送信する(S33)。一方、アクセスを許可する場合(S32でYES)、アクセス管理手段54がユーザのアクセス情報を記憶する(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の処理が繰り返されることで、ゲームが進行していく。
次に、図18のフローチャートを参照して、あるユーザがゲームサービスに新規登録したときのゲームサーバ1の処理について説明する。
ユーザがゲームサービスに新規登録する場合、ログインID(任意の英数文字やメールアドレス等)およびパスワード等を含む新規登録の申請データをゲームサーバ1に送信することになる。ゲームサーバ1は、ユーザの端末装置3から新規登録の申請データを受信したとき(S71でYES)、当該ユーザのゲーム情報を管理する領域をデータベースサーバ2内に確保して、当該ユーザに対する新規登録処理を行う(S72)。そして、ゲームサーバ1は、新規登録のユーザが、他のユーザから招待を受けているか否かを判断する(S73)。例えば、ユーザが、招待メッセージ中における招待ユーザの情報が含まれたURLを選択して新規登録の申請をした場合、ゲームサーバ1は、当該ユーザが招待ユーザから招待を受けていると判断することができる。
新規登録のユーザが、他のユーザから招待を受けていない場合(S73でNO)、ゲームサーバ1は、S74に移行することなく処理を終了する。一方、新規登録のユーザが、他のユーザから招待を受けている場合(S73でYES)、ゲームサーバ1の関係管理手段56は、招待をした側の招待ユーザと、招待をされた側の被招待ユーザ(新規登録のユーザ)とを関係付けた情報をデータベースサーバ2に記憶して両者の関係を管理する(S74)。本実施の形態では、図8に例示するように、招待ユーザを先輩、被招待ユーザを後輩として、後輩の新規登録後の両者の関係が管理されることになる。
さらに、本実施の形態では、仲間管理手段60により、先輩と後輩とが互いに仲間として登録されるようになっている(S75)。この仲間の関係は、招待ユーザと被招待ユーザとの区別がない両者対等な関係である。なお特典(招待特典または新規招待登録特典)の付与に直接的に用いられる関係情報は、招待ユーザと被招待ユーザとの区別がある先輩・後輩の関係であるため、この仲間登録の処理(S75)は、省略することも可能である。
その後、ゲームサーバ1の報知手段59は、後輩となった被招待ユーザの端末装置3に対して、新規招待登録特典の内容等を示す画面データを送信し、被招待ユーザに新規招待登録特典が受けられることとなった旨を報知する(S76)。図24に、新規招待登録特典の内容を示す画面例を示している。この画面例では、(1)先輩がゲームにアクセスしているとき、調子マークがMAXになる(パラメータの値が最大になる)、(2)先輩のレベルが5つ上がる毎にレアアイテムが獲得できる、という新規招待登録特典の内容を後輩に報知している。
また、招待ユーザの端末装置3からゲームサーバ1へのアクセスがあれば(S77でYES)、報知手段59は、先輩となった招待ユーザの端末装置3に対して、招待特典の内容等を示す画面データを送信し、招待ユーザに招待特典が受けられることとなった旨を報知する(S78)。図25に、招待特典の内容を示す画面例を示している。この画面例では、(1)後輩がゲームにアクセスしているとき、調子マークがアップする(パラメータ設定手段58が設定したパラメータの値が上昇する)、(2)後輩のレベルが5つ上がる毎にレアアイテムが獲得できる、という招待特典の内容を先輩に報知している。
次に、図19のフローチャートを参照して、ゲームサーバ1における招待特典付与処理の一例について説明する。同図は、先輩のゲーム中において、後輩がゲームにアクセスしているとき、先輩の端末装置3に対してパラメータ設定手段58が設定した調子のパラメータの値が上昇するという招待特典の付与処理を例示するものである。
ゲームサーバ1は、ゲーム中のユーザに、当該ユーザが招待をした後輩が存在するか否かを判断する(S81)。さらに、ゲームサーバ1は、ゲーム中のユーザに後輩が存在する場合(S81でYES)、当該後輩がゲームにアクセス中であるか否かを判断する(S82)。ここで、ゲーム中のユーザに後輩が存在しない場合(S81でNO)、または後輩が存在する場合であっても当該後輩がゲームにアクセスしていない場合(S82でNO)、ゲームサーバ1は、当該ユーザの端末装置3に対してパラメータ設定手段58が設定したパラメータの値を適用し(S83)、当該値に対応した調子マークをゲーム画面に表示させる(S84)。すなわち、ゲームサーバ1は、パラメータ設定手段58が設定したパラメータの値に対応した調子マークを含むゲーム画面を、ユーザの端末装置3に送信する。
一方、後輩がゲームにアクセス中である場合(S82でYES)、招待特典付与部57aは、アクセス中の後輩の人数nを取得する(S85)。そして、招待特典付与部57aは、先輩の端末装置3に対してパラメータ設定手段58が設定した調子のパラメータの値をn段階上昇させる(S86)。この例では、アクセス中の後輩の人数とパラメータの値の上昇段数とを一致させているが、これに限定されない。例えば、後輩のアクセス人数によらず、後輩が1人でもアクセスしているときはパラメータの値を所定値(例えば1つ)だけ上昇させるようにしてもよい。
ユーザのゲーム中において、ゲーム進行手段52は、調子のパラメータの値が高いほど、ゲーム上有利になる程度が大きくなるようにゲーム進行を制御するようになっている。例えば、パラメータの値が高いほど、ゲーム中に取得できる経験値をより多くしたり、ゲーム内で発動されたミッションの達成またはイベントの進行をより早くしたり、レアカードやレアアイテムが抽選される確率をより高めたりする。よって、S86により先輩の端末装置3に対するパラメータの値が上昇すれば、ゲーム上有利になる程度が大きくなり、招待特典を付与した状態となる。
また、S86でパラメータの値を上昇させたことに伴い、ゲームサーバ1は、当該値に対応した調子マークを、先輩の端末装置3のゲーム画面に反映させる(S87)。そして、ゲームサーバ1の報知手段59は、図10に例示するように、ゲーム画面に特典通知情報74を含ませて、招待特典により調子マークが良い方に変更されている旨を先輩に報知する(S88)。これにより、先輩は、招待特典が付与されている状態を認識できる。
ユーザのゲーム中において(S89でYES)、前記S81〜S88の処理が繰り返し実行され、ユーザがゲームを終了してログアウトしたとき(S89でNO)、処理は終了となる。
図19に例示した招待特典を受ける先輩にとっては、自分がゲームをプレイするときに後輩がゲームにアクセスしてくれる回数が多いほど、招待特典のメリットをより多く享受できる。よって、先輩は、後輩に対して、「アクセス頑張ろう」、「一緒にアクセスしよう」等のメッセージを送ってコミュニケーションをとることが期待でき、ゲームコミュニティの活性化に繋がる。
次に、図20のフローチャートを参照して、ゲームサーバ1における招待特典付与処理の他の例について説明する。同図は、後輩のゲーム進行状況を示すゲームのレベルが基準値に到達したとき、先輩に招待特典を付与する処理を例示するものである。
ゲームサーバ1は、ゲーム中(ゲームにアクセス中)のユーザが他のユーザの後輩であるか否かを判断する(S91)。アクセス中のユーザが後輩として他のユーザと関係付けられていない場合(S91でNO)、当該ユーザに対しては以降の処理が行われることなく終了となる。一方、アクセス中のユーザが後輩であり(S91でYES)、後輩のゲーム中に(S92でYES)、後輩のゲームのレベルが向上した場合(S93でYES)、当該レベルが基準値に到達したか否かが判定される(S94)。ここで、後輩のゲームのレベルが基準値に到達することなく(S94でNO)後輩がゲームを終了した場合(S92でNO)、以降の処理が行われることなく終了となる。
一方、後輩のゲームのレベルが基準値に到達した場合(S94でYES)、ゲームサーバ1の招待特典付与部57aは、当該後輩を招待した先輩のユーザに招待特典を付与する(S95)。例えば、前記基準値をレベル5、10、15に設定している場合、後輩のゲームのレベルが5、10、15の何れかに達したとき、先輩に招待特典が付与されることになる。このとき先輩に付与される招待特典は、前述のとおり特典の付与前と比較してゲーム上有利となるものであればよく、ポイントやアイテムの付与に限らず様々な特典を適用できる。
その後、招待特典が付与された先輩の端末装置3からゲームサーバ1へのアクセスがあれば(S96でYES)、報知手段59は、当該先輩の端末装置3に対して、招待特典が付与された旨を示す画面データを送信し、先輩に特典の付与を報知する(S97)。
図20に例示した招待特典を受ける先輩にとっては、後輩がゲームのレベルを向上させることによって当該特典のメリットを享受できる。よって、先輩は、後輩に対して、「レベルアップ頑張ろう」等のメッセージを送ってコミュニケーションをとることが期待でき、ゲームコミュニティの活性化に繋がる。
前記図20のフローチャートでは、S93およびS94において後輩のゲームのレベルが基準値に到達した状況を判断し、先輩に招待特典を付与する例を説明したが、次のように判断の基準を変更してもよい。すなわち、後輩のゲームのレベルに代えて、後輩のゲーム進行状況を示す他の値(後輩が所有するキャラクタの能力値や後輩のチームの戦力値など)を判断基準とし、これらの値が基準値に到達したときに、先輩に招待特典を付与してもよい。あるいは、後輩のゲームのレベルに代えて、後輩のゲームへのアクセス回数やアクセス日数などの、後輩のゲームアクセスを示す値を判断基準とし、これらの値が基準値に到達したときに、先輩に招待特典を付与してもよい。
以上のように、本実施の形態では、招待ユーザから新規のゲームサービス登録を招待された被招待ユーザがゲームサービスに登録したとき、関係管理手段58が招待ユーザと被招待ユーザとを関係付けた情報(先輩・後輩の情報)を記憶装置に記憶して両者の関係を管理する。そして、被招待ユーザがゲームサービスに登録した後、招待ユーザ(先輩)に対して、被招待ユーザ(後輩)のゲームアクセスまたはゲーム進行状況に応じて、招待特典が付与されるようになっている。これにより、先輩にとっては、後輩の新規登録後において、後輩のゲームアクセスまたはゲーム進行状況に応じた招待特典を継続的に享受できるので、招待成功時に1回だけポイントが付与される従来の特典よりも魅力的な招待特典となっている。このようなゲームサービスへ招待した側(招待ユーザ)と招待された側(被招待ユーザ)との継続的な関係性を生かした斬新で魅力的な招待特典をユーザに提供することにより、ユーザに対して新たなユーザをゲームに招待しようという強い動機付けを与えることができる。
次に、図21のフローチャートを参照して、ゲームサーバ1における新規招待登録特典付与処理の一例について説明する。同図は、後輩のゲーム中において、先輩がゲームにアクセスしているとき、後輩の端末装置3に対してパラメータ設定手段58が設定したパラメータの値が上昇するという新規招待登録特典の付与処理を例示するものである。
ゲームサーバ1は、ゲーム中のユーザに招待をした先輩が存在するか否かを判断する(S101)。さらに、ゲームサーバ1は、ゲーム中のユーザに先輩が存在する場合(S101でYES)、当該先輩がゲームにアクセス中であるか否かを判断する(S102)。ここで、ゲーム中のユーザに先輩が存在しない場合(S101でNO)、または先輩が存在する場合であっても当該先輩がゲームにアクセスしていない場合(S102でNO)、ゲームサーバ1は、当該ユーザの端末装置3に対してパラメータ設定手段58が設定したパラメータの値を適用し(S103)、当該値に対応した調子マークをゲーム画面に表示させる(S104)。すなわち、ゲームサーバ1は、パラメータ設定手段58が設定したパラメータの値に対応した調子マークを含むゲーム画面を、ユーザの端末装置3に送信する。
一方、先輩がゲームにアクセス中である場合(S102でYES)、新規招待登録特典付与部57bは、後輩の端末装置3に対してパラメータ設定手段58が設定したパラメータの値を最大値「5=最好調」まで上昇させる(S105)。この例では、パラメータの値を最大値まで上昇させているが、これに限定されない。例えば、後輩の端末装置3に対するパラメータの値を所定値(例えば2つ)だけ上昇させるようにしてもよい。S105により後輩の端末装置3に対するパラメータの値が上昇すれば、ゲーム上有利になる程度が大きくなり、新規招待登録特典を付与した状態となる。
また、S105でパラメータの値を上昇させたことに伴い、ゲームサーバ1は、当該値に対応した調子マークを、後輩の端末装置3のゲーム画面に反映させる(S106)。そして、ゲームサーバ1の報知手段59は、図11に例示するように、ゲーム画面に特典通知情報74を含ませて、新規招待登録特典により調子マークが良い方に変更されている旨を後輩に報知する(S107)。これにより、後輩は、新規招待登録特典が付与されている状態を認識できる。
ユーザのゲーム中において(S108でYES)、前記S101〜S107の処理が繰り返し実行され、ユーザがゲームを終了してログアウトしたとき(S108でNO)、処理は終了となる。
図21に例示した新規招待登録特典を受ける後輩にとっては、自分がゲームをプレイするときに先輩がゲームにアクセスしてくれる回数が多いほど、新規招待登録特典のメリットをより多く享受できる。よって、後輩は、先輩に対して、「一緒にアクセスしましょう」等のメッセージを送ってコミュニケーションをとることが期待でき、ゲームコミュニティの活性化に繋がる。
次に、図22のフローチャートを参照して、ゲームサーバ1における新規招待登録特典付与処理の他の例について説明する。同図は、後輩がゲームサービスに新規登録した後における先輩のゲームのレベルの向上分が基準値に到達したとき、後輩に新規招待登録特典を付与する処理を例示するものである。
ゲームサーバ1は、ゲーム中(ゲームにアクセス中)のユーザが他のユーザの先輩であるか否かを判断する(S111)。アクセス中のユーザが先輩として他のユーザと関係付けられていない場合(S111でNO)、当該ユーザに対しては以降の処理が行われることなく終了となる。一方、アクセス中のユーザが先輩であり(S111でYES)、先輩のゲーム中に(S112でYES)、先輩のゲームのレベルが向上した場合(S113でYES)、後輩がゲームサービスに新規登録した後における先輩のゲームのレベルの向上分が基準値に到達したか否かが判定される(S114)。ここで、先輩のゲームのレベルの向上分が基準値に到達することなく(S114でNO)、先輩がゲームを終了した場合(S112でNO)、以降の処理が行われることなく終了となる。
一方、先輩のゲームのレベルの向上分が基準値に到達した場合(S114でYES)、ゲームサーバ1の新規招待登録特典付与部57bは、当該先輩に招待された後輩のユーザに新規招待登録特典を付与する(S115)。例えば、前記基準値を5、10、15に設定している場合、先輩のゲームのレベルの向上分が5、10、15の何れかに達したとき、後輩に新規招待登録特典が付与されることになる。一例を挙げると、後輩がゲームサービスに新規登録したときの先輩のゲームのレベルが「25」であった場合、先輩のゲームのレベルが「30」、「35」、「40」に達したとき、それぞれ後輩に新規招待登録特典が付与されることになる。このとき後輩に付与される新規招待登録特典は、前述のとおり特典の付与前と比較してゲーム上有利となるもの等であればよく、ポイントやアイテムの付与に限らず様々な特典を適用できる。
その後、新規招待登録特典が付与された後輩の端末装置3からゲームサーバ1へのアクセスがあれば(S116でYES)、報知手段59は、当該後輩の端末装置3に対して、新規招待登録特典が付与された旨を示す画面データを送信し、後輩に特典の付与を報知する(S117)。
図22に例示した新規招待登録特典を受ける後輩にとっては、先輩がゲームのレベルを向上させることによって当該特典のメリットを享受できる。よって、後輩は、先輩に対して、「レベルアップ頑張りましょう」等のメッセージを送ってコミュニケーションをとることが期待でき、ゲームコミュニティの活性化に繋がる。
前記図22のフローチャートでは、S113およびS114において先輩のゲームのレベルの向上分が基準値に到達した状況を判断し、後輩に新規招待登録特典を付与する例を説明したが、次のように判断の基準を変更してもよい。すなわち、先輩のゲームのレベルの向上分に代えて、先輩のゲーム進行状況を示す他の値(先輩が所有するキャラクタの能力値や先輩のチームの戦力値など)の向上分を判断基準とし、これらの値の向上分が基準値に到達したときに、後輩に新規招待登録特典を付与してもよい。あるいは、先輩のゲームのレベルの向上分に代えて、先輩のゲームアクセスを示す値(先輩のゲームへのアクセス回数やアクセス日数など)を判断基準とし、これらの値が基準値に到達したときに、後輩に新規招待登録特典を付与してもよい。
以上のように、本実施の形態では、招待を受けた後輩がゲームサービスに登録した後、当該後輩に対して、先輩のゲームアクセスまたはゲーム進行状況に応じて、ゲーム上有利になる新規招待登録特典が付与されるようになっている。これにより、後輩にとっては、ゲームサービスへの新規登録後に、先輩のゲームアクセスまたはゲーム進行状況に応じた新規招待登録特典を継続的に享受できるので、新規登録時に1回だけポイントが付与される従来の特典よりも魅力的な特典となっている。このようなゲームサービスへ招待した側(招待ユーザ)と招待された側(被招待ユーザ)との継続的な関係性を生かした斬新で魅力的な新規招待登録特典をユーザに提供することにより、当該ユーザに対して是非ゲームに新規登録してみようという強い動機付けを与えることができる。
次に、図23のフローチャートを参照して、ゲームサーバ1における特典(招待特典、新規招待登録特典)を終了させる処理の一例について説明する。
ゲームサーバ1は、ゲーム中(ゲームにアクセス中)のユーザが後輩であるか否かを判断する(S121)。アクセス中のユーザが後輩でない場合(S121でNO)、当該ユーザに対しては以降の処理が行われることなく終了となる。一方、アクセス中のユーザが後輩であり(S121でYES)、後輩のゲーム中において(S122でYES)、後輩のゲームのレベルが向上した場合(S123でYES)、当該レベルが所定値(例えば初心者レベルを突破したレベル15)に到達したか否かが判定される(S124)。ここで、後輩のゲームのレベルが所定値に到達することなく(S124でNO)、後輩がゲームを終了した場合(S122でNO)、以降の処理が行われることなく終了となる。
一方、後輩のゲームのレベルが所定値に到達した場合(S124でYES)、ゲームサーバ1は、当該後輩に対して卒業報酬としてレアアイテムやポイント等を付与する(S125)。また、ゲームサーバ1の招待特典付与部57aは、後輩を招待した先輩に対して、最後の招待特典としてレアアイテムやポイント等を付与する(S126)。そして、ゲームサーバ1の特典付与手段57は、先輩に対する招待特典を終了する(S127)とともに、後輩に対する新規招待登録特典を終了する(S128)。これにより、特典付与手段57は、これ以降、先輩および後輩の何れに対しても、特典(招待特典、新規招待登録特典)の付与処理を実行しない。なお、S125およびS126は、ゲームの仕様によっては省略してもよい。
その後、ゲームサーバ1の報知手段59は、後輩の端末装置3に対して、卒業報酬が付与された旨および新規招待登録特典が終了した旨を示す画面データを送信し、これらの旨を後輩に報知する(S129)。また、先輩の端末装置3からゲームサーバ1へのアクセスがあれば(S130でYES)、報知手段59は、先輩の端末装置3に対して、最後の招待特典が付与された旨および招待特典が終了した旨を示す画面データを送信し、これらの旨を先輩に報知する(S131)。
なお、図23の例では、招待特典および新規招待登録特典の終了タイミングを一致させているが、両特典の終了タイミングを異ならせてもよい。例えば、後輩のゲームのレベルが20に到達したときに先輩に対する招待特典を終了し、後輩のゲームのレベルが15に到達したときに、当該後輩に対する新規招待登録特典を終了するようにしてもよい。
また、図23の例では、後輩のゲームのレベルが所定値に到達したことを判断し、特典を終了する例を説明したが、次のように判断の基準を変更してもよい。すなわち、後輩のゲームのレベルに代えて、後輩のゲーム進行に伴って変化するゲーム上の他の値(後輩の所有するキャラクタの能力値、後輩のチームの戦力値、後輩のゲーム内のステージの難易度の値など)を判断基準とし、これらの値が所定値に到達したときに、特典を終了するようにしてもよい。
以上のように、本実施の形態では、後輩のゲーム進行に伴って変化する、後輩に関するゲーム上の値が所定値に達した後は、特典の付与処理を実行しないようになっている。これにより、ユーザに対して新たなユーザの招待を促すことができる。すなわち、ユーザが一定の特典を享受したタイミングで特典の付与を終了することによって、再度、魅力的な特典を受けたいという気持ちがユーザに働き、新たなユーザをゲームに招待しようという強い動機付けをユーザに与えることができる。
〔ゲーム管理装置の他の構成例〕
以下に、被招待ユーザがゲームサービスに新規登録した後における招待ユーザ(先輩)と被招待ユーザ(後輩)との継続的な関係性を生かした「対戦協力」を実現する構成を、図26の機能ブロック図を参照しながら説明する。なお、既出の図面(図1〜図25)において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。
本実施の形態のゲームサーバ1(ゲーム管理装置)は、図4に示した各手段51〜61に加えて、対戦協力管理手段62および対戦協力受付手段63をさらに備えている。これらの手段62・63は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。
対戦協力管理手段62は、招待ユーザ(先輩)のキャラクタが他のキャラクタと対戦するときに、被招待ユーザ(後輩)のキャラクタを、自動的に「助っ人」として招待ユーザ側に加担させ、対戦協力させる機能を有する。すなわち、後輩がゲームサービスに新規登録した後は、後輩を紹介した先輩と当該後輩との間に上下関係が構築され、後輩のキャラクタは自動的に「助っ人」として先輩のキャラクタに対戦協力するようになっている。後輩のキャラクタが助っ人として先輩側に加担して対戦協力することにより、先輩側の戦力が向上するので、当該対戦協力がない場合に比べて、先輩の対戦が有利になる。
なお、先輩のキャラクタが他のキャラクタと対戦する場合の「他のキャラクタ」とは、他のユーザのキャラクタ又はゲームサーバ1のCPUが用意したキャラクタ(例えば、各ステージの最後に登場するボスキャラクタ等)のいずれであってもよい。
通常、あるユーザが仲間に対戦協力を求める場合、端末装置3を操作して、助っ人の協力要請を行う必要がある。これに対して、本実施の形態では、先輩による助っ人の協力要請の操作は不要であり、ゲームサーバ1の関係管理手段58が管理している先輩・後輩の関係情報に基づいて、対戦協力管理手段62が後輩のキャラクタを自動的に先輩側に加担させ、対戦協力を実現する。本ゲームサーバ1では、仲間関係とは別に、招待成功後に先輩・後輩の関係をデータベースサーバ2に登録して両者の継続的な関係を管理しているので、後輩のキャラクタを自動的に先輩側に加担させる対戦協力が可能となる。
ところで、対戦に協力できる仲間のキャラクタ(助っ人)の数には上限を設けることが望ましい。これは、助っ人の数が多くなりすぎると、対戦相手との戦力差が大きくなり過ぎて、対戦を行う両者の戦力バランスが極端に崩れてしまうことを防止するためである。対戦モードにおいて他のユーザのキャラクタと対戦する場合には、対戦に協力できる仲間の助っ人の数を、例えば「1」とすることができる。また、ゲームサーバ1のCPUが用意したキャラクタ(ボスキャラクタ等)と対戦する場合には、対戦に協力できる仲間の助っ人の数を、例えば「2」とすることができる。ここで、例えば、先輩が招待した後輩が1人または2人以上いる場合、自動的に先輩側に協力する後輩のキャラクタによって限られた数の助っ人枠の一部または全部が埋められてしまうことにならないように、本実施の形態では以下に示す構成をとっている。
すなわち、上述のように自動的に実行される後輩のキャラクタによる対戦協力とは別に、ユーザが任意に対戦協力を要請することができる所定数(第1規定数)の仲間の助っ人枠を確保する。換言すれば、自動的に後輩のキャラクタが助っ人となる「後輩の助っ人枠」と、ユーザの任意で、好きな仲間ユーザのキャラクタを助っ人とすることができる「仲間の助っ人枠」という2つの異なる助っ人枠が、用意されているのである。後輩の助っ人枠は、後輩の招待に成功した先輩だけに与えられる招待専用の特別な助っ人枠である。
そして、本ゲームサーバ1は、自動的に実行される後輩のキャラクタによる対戦協力とは別に、対戦協力を要請することができる第1規定数以下の仲間ユーザのキャラクタの選択(または第1規定数以下の仲間ユーザの選択)を、ユーザの端末装置3における操作により受け付ける対戦協力受付手段63を備えている。ユーザが端末装置3を操作して、助っ人にしたい仲間ユーザのキャラクタ(または仲間ユーザ)を選択すれば、端末装置3からは、選択された仲間ユーザのキャラクタ(または仲間ユーザ)の情報を含む対戦協力要請情報がゲームサーバ1へ送信される。そして、ゲームサーバ1の対戦協力受付手段63は、ユーザの端末装置3から送信された対戦協力要請情報を受信して、当該ユーザが選択した仲間ユーザのキャラクタを助っ人として受け付ける。
図27に、対戦モードにおけるゲーム画面の一例を示している。このゲーム画面には、ユーザが指定した対戦相手のチーム(敵軍)の情報81およびユーザのチーム(自軍)の情報82が表示される。対戦相手のチーム(敵軍)の情報81としては、例えば、対戦相手のユーザ名、アバター、選手カード、戦力に関する情報などが表示される。また、ユーザのチーム(自軍)の情報82としては、当該ユーザのユーザ名、アバター、選手カード、戦力に関する情報などが表示される。さらに、このゲーム画面の助っ人表示領域83には、助っ人として自軍に協力するキャラクタ等の情報が表示されるようになっている。このゲーム画面は、ゲームサーバ1のゲーム画面生成手段52bにより生成されるとともに、ゲーム画面送信手段52cによりユーザの端末装置3へ送信されるものであり、端末装置3の表示部35に表示される。
図27に示すように、後輩を有するユーザAがユーザYを指定して対戦を仕掛ける場合、対戦協力管理手段62がユーザAの後輩のキャラクタを自動的に助っ人とするので、助っ人表示領域83には、後輩(この例ではユーザX)のキャラクタである選手カード84が自動的に表示される。図27では、後輩が有する複数の選手カードのうち、4番打者として設定されている選手カードが自動的に助っ人のキャラクタとして設定される例を示している。これに限らず、例えば、エース投手として設定されている選手カードやリーダー(キャプテン)として設定されている選手カードなどの代表的なキャラクタを、後輩の助っ人のキャラクタとしてもよい。また、助っ人表示領域83には、対戦協力する後輩のアバターや対戦協力による戦力アップ情報も併せて表示される。図27の画面例では、対戦協力による戦力アップ情報として「攻撃力+100」が表示されている。
また、助っ人表示領域83には、「仲間から助っ人を呼ぶ」ボタン85(またはハイパーリンク)が表示され、後輩の助っ人に加えて、任意の仲間のキャラクタを仲間の助っ人として要請できるようになっている。ここでは、仲間の助っ人枠を「1」として以下に説明する。ユーザが「仲間から助っ人を呼ぶ」ボタン85を選択することにより、例えば図28に示す助っ人選択画面に遷移する。この助っ人選択画面には、ユーザと仲間関係にある仲間ユーザおよび当該仲間ユーザが有するキャラクタ(選手カード)がリストアップされて表示される。なお、画面に表示しきれない情報については、画面をスクロールするまたは助っ人選択画面の2ページ目以降をゲームサーバ1にリクエストして別画面として表示することができる。
この助っ人選択画面内にはリストアップされた仲間ユーザ毎の情報表示領域が設けられており、各情報表示領域には、仲間ユーザの名前91、仲間ユーザのアバター92、仲間ユーザが有する4番打者の選手カード93、選手名94、当該選手カードの情報(選手カードに設定されているレベルや攻撃力等)95などが表示される。図28では、仲間ユーザが有する複数の選手カードのうち、4番打者として設定されている選手カードを助っ人のキャラクタとして選択可能な例を示している。これに限らず、例えば、エース投手やリーダーとして設定されている選手カードなどの代表的なキャラクタを、仲間の助っ人として選択可能としてもよい。そして、ユーザが端末装置3を操作して、例えば選手名94に設定されたハイパーリンクを選択することにより、助っ人にしたい仲間のキャラクタを選択できるようになっている。
例えば、図28の助っ人選択画面において、ユーザAが端末装置3を操作して仲間ユーザBのキャラクタを助っ人として選択した場合、図29に例示するゲーム画面に遷移し、助っ人表示領域83には、後輩の助っ人に加えて、ユーザBの選手カード86が仲間の助っ人として追加される。
なお、ユーザが仲間の助っ人を選択すれば、ゲームサーバ1において当該仲間の助っ人の情報を当該ユーザのユーザIDと対応付けてデータベースサーバ2(記憶装置)に記憶する。よって、ユーザが仲間の助っ人を選択する操作を行えば、次回の対戦においても、前回選択した仲間のキャラクタが助っ人として設定されるようになっている。また、仲間のキャラクタが助っ人として設定されているとき、助っ人表示領域83には、「仲間の助っ人を変更する」ボタン87(またはハイパーリンク)が表示されるようになっている。ユーザがこのボタン87を選択することにより、図28の助っ人選択画面に遷移し、助っ人にしたい仲間のキャラクタを選択し直すことができるようになっている。
図27または図29の対戦モードの画面において、ユーザが「対戦開始」ボタン88を選択する操作を行うことにより、ユーザの端末装置3からは対戦コマンドがゲームサーバ1へ送信され、ゲームサーバ1において対戦処理が実行される。
次に、図30のフローチャートを参照しながら、ゲームサーバ1における対戦処理の一例を説明する。
対戦モードにおいて他のユーザのチームと対戦する操作(前述の「対戦開始」ボタン88の選択操作)が、ユーザによって行われた場合、当該ユーザの端末装置3からは対戦コマンドがゲームサーバ1へ送信される。ゲームサーバ1は、ユーザの端末装置3から対戦コマンドを受信したとき(S131でYES)、当該ユーザが招待した後輩が存在するか否かを判断する(S132)。ユーザに後輩が存在する場合(S132でYES)、対戦協力管理手段62は、当該後輩のキャラクタ(4番打者の選手カード等)を自動的に助っ人として当該ユーザ側に加担させる(S133)。一方、ユーザに後輩が存在しない場合(S132でNO)、S133の処理が実行されることなくS134に移行する。
次に、ユーザにより仲間の助っ人が選択されているか否かが判断される(S134)。すなわち、対戦協力受付手段63が助っ人として受け付けた、ユーザにより任意に選択された仲間ユーザのキャラクタが、データベースサーバ2に記憶されているか否かが判断される。ここで、仲間の助っ人が選択されている場合(S134でYES)、対戦協力管理手段62は、当該仲間のキャラクタ(4番打者の選手カード等)を助っ人として当該ユーザ側に加担させる(S135)。一方、仲間の助っ人が選択されていない場合(S134でNO)、S135の処理が実行されることなくS136に移行する。
その後、ゲーム実行手段52aは、助っ人を加味した対戦を実行する(S136)。すなわち、ゲーム実行手段52aは、対戦を行う両ユーザのユーザIDに対応した両チームの選手カード情報(試合に出場するレギュラー選手の選手カード情報)をデータベースサーバ2から読み出す。さらに、助っ人として対戦協力する後輩の選手カードおよび/または仲間の選手カードが存在する場合、助っ人となる選手カード情報もデータベースサーバ2から読み出す。例えば、ゲーム実行手段52aは、対戦を仕掛けたユーザ側のチーム(自軍)の選手カードの能力値の合計に、助っ人となる選手カードの能力値を加算して、当該ユーザのチーム戦力(攻撃力)を算出する。また、ゲーム実行手段52aは、対戦相手のチーム(敵軍)の選手カードの能力値を合計して、当該対戦相手のチーム戦力(守備力)を算出する。そして、ゲーム実行手段52aは、両チームのチーム戦力に基づいて、勝敗を決定する演算を行う。この勝敗決定の演算の例としては、両チームの戦力が高い方を勝利チームとしてもよいし、戦力の高い方のチームが勝利する確率を、戦力の低い方のチームが勝利する確率よりも高くして、勝利チームを確率演算により求めてもよい。
その後、ゲームサーバ1のゲーム情報管理手段51は、対戦結果を対戦した両ユーザのゲーム情報に反映すべく、両ユーザのゲーム情報を更新する(S137)。さらに、ゲームサーバ1のゲーム画面生成手段52bは、対戦結果を表示するゲーム画面データを生成する(S138)。そして、ゲーム画面送信手段52cは、ゲーム画面生成手段52bにより生成されたゲーム画面データを、ユーザの端末装置3へ送信する(S139)。
以上のように、本実施の形態では、招待した後輩が存在する招待ユーザ(先輩)が対戦を行う場合、後輩のキャラクタが助っ人として自動的に先輩側に加担して対戦協力するので、先輩は、対戦協力要請の操作をすることなく対戦が有利になる。特に、ソーシャルゲーム等のユーザによる操作の容易化・簡略化が強く求められるゲームサービスには、ユーザの操作を不要とした本構成のメリット発生が好適である。このように、招待成功後において招待ユーザ(先輩)と被招待ユーザ(後輩)との継続的な関係性を生かした対戦協力のメリットをユーザに提供することにより、ユーザに対して新たなユーザをゲームに招待しようという強い動機付けを与えることができる。
また、本実施の形態では、自動的に実行される後輩のキャラクタによる対戦協力とは別に、ユーザが任意に対戦協力を要請することができる所定数(第1規定数)の仲間の助っ人枠を確保している。よって、限られた数の仲間の助っ人枠の一部または全部が自動的に先輩側に協力する後輩のキャラクタによって埋められてしまうことがなく、先輩は、後輩のキャラクタ以外にも、好きな仲間ユーザのキャラクタを助っ人にできる。
本構成により、誰も招待をしていない通常のユーザには、仲間の助っ人枠だけが与えられる一方、招待した後輩が存在する招待ユーザ(先輩)には、仲間の助っ人枠だけでなく、後輩の助っ人枠が追加で与えられる。このように助っ人枠が増えることによって、先輩の対戦は通常のユーザよりも有利になる。この後輩の助っ人枠は、招待に成功したユーザだけに与えられる特別な助っ人枠であり、ユーザに対して新たなユーザをゲームに招待しようという強い動機付けを与えることができる。
ところで、先輩側に加担して対戦協力できる後輩の人数については、次に説明するように無制限に認めてもよいし、制限を設けてもよい。上述のように、後輩の助っ人枠は、後輩の招待に成功した先輩だけに与えられる招待専用の特別な助っ人枠であり、招待ユーザに付与される特典の一つである。そこで、複数の後輩の招待に成功すれば、後輩の人数に合わせて後輩の助っ人枠が無制限に増加するようにして、複数の後輩の招待に成功したユーザが大きなメリットを享受できるようにしてもよい。
一方で、後輩の助っ人枠を無制限に認めた場合、対戦相手との戦力差が大きくなり過ぎて、対戦を行う両者の戦力バランスが極端に崩れてしまう可能性もでてくる。そこで、先輩側に加担して対戦協力できる後輩の人数を、規定数(第2規定数)以下に限定してもよい。この場合、先輩が招待した第2規定数を超える複数の後輩がゲームサービスに登録されているときには、対戦協力管理手段62が、複数の後輩の中からより能力値の高いキャラクタを有する第2規定数の後輩を選択し、選択した第2規定数の後輩のキャラクタを先輩側に自動的に加担させるようにすることが望ましい。これにより、後輩の助っ人枠に一定の上限を設けながらも、上限(第2規定数)を超える複数の後輩が存在する場合には、能力値の高いキャラクタを有する後輩から順番に第2規定数の後輩が自動的に選択されて、上限内で最強の後輩のキャラクタが自動的に先輩の対戦に協力するようにできる。
図31のフローチャートには、先輩側に加担して対戦協力できる後輩の人数に上限を設けた場合におけるゲームサーバ1の対戦処理の一例を示している。図31に示す対戦処理は、前記した図30のフローチャートにおいて、S132とS133との間に、S141およびS142のステップを挿入することにより実現できる。図31には、先輩側に加担して対戦協力できる後輩の上限人数(第2規定数)を2人とした例を示している。なお、図31のフローチャートにおいて、図30のフローチャートと同様のステップについては同一のステップ番号を付し、適宜その説明を省略する。
対戦を仕掛けたユーザに後輩が存在する場合(S132でYES)、後輩の人数が上限である2人を超えているか否かが判断される(S141)。ここで、後輩の人数が2人を超えている場合(S141でYES)、対戦協力管理手段62が、複数の後輩の中からより能力値の高いキャラクタを有する2人の後輩を選択する(S142)。この場合、対戦協力管理手段62は、選択した2人の後輩のキャラクタを助っ人として、対戦を仕掛けたユーザ側に加担させる(S133)。
一方、後輩の人数が2人以下であった場合(S141でNO)、前記S142における後輩の選択処理を経ることなく、対戦協力管理手段62が、後輩全員のキャラクタを助っ人として、対戦を仕掛けたユーザ側に加担させる(S133)。S134以降のステップは、図30のフローチャートで示したステップと同様である。
このように、後輩の助っ人枠に一定の上限を設けたことにより、対戦を行う両者の戦力バランスが極端に崩れることを回避できる。さらに、後輩の人数が上限を超える場合にも、上限内で最強の後輩のキャラクタが自動的に助っ人として対戦協力する構成としているので、ユーザにとってはより多くの後輩を招待するメリットも享受できる。
ところで、前述の説明では、先輩のキャラクタが他のキャラクタと対戦するときに、後輩のキャラクタを、自動的に「助っ人」として先輩側に加担させ、対戦協力させる構成について説明したが、先輩と後輩を逆にして、先輩が後輩の対戦に協力する構成も可能である。すなわち、対戦協力管理手段62は、被招待ユーザ(後輩)のキャラクタが他のキャラクタと対戦するときに、招待ユーザ(先輩)のキャラクタを、自動的に「助っ人」として被招待ユーザ側に加担させ、対戦協力させてもよい。この場合、先輩のキャラクタが助っ人として自動的に後輩側に加担して対戦協力することにより、後輩側の戦力が向上するので、当該対戦協力がない場合に比べて、後輩の対戦が有利になる。
また、前述の場合と同様に、先輩のキャラクタによる自動対戦協力とは別に、後輩が任意に対戦協力を要請することができる所定数の仲間の助っ人枠を確保することが望ましい。すなわち、自動的に先輩のキャラクタが助っ人となる「先輩の助っ人枠」と、ユーザの任意で、好きな仲間ユーザのキャラクタを助っ人とすることができる「仲間の助っ人枠」という2つの異なる助っ人枠を用意する。先輩の助っ人枠は、招待を受けてゲームに新規登録を行った後輩にだけに与えられる招待専用の特別な助っ人枠である。
〔他の実施の形態〕
上述の実施の形態では、図19のフローチャートを参照して、被招待ユーザ(後輩)がゲームにアクセスしている最中に、招待ユーザ(先輩)の端末装置3に対してパラメータ設定手段58が設定した値を上昇させるという招待特典について説明したが、被招待ユーザがゲームへのアクセスを終了した場合であっても、以下に説明するように招待ユーザに招待特典を付与する構成としてもよい。
すなわち、特典付与手段57は、被招待ユーザがゲームへのアクセスを終了した場合であっても、当該被招待ユーザのゲームへのアクセス開始から所定時間以内は、招待ユーザの端末装置3に対してパラメータ設定手段58が設定した値を上昇させるという招待特典を、招待ユーザに対して付与する構成とする。この構成は、被招待ユーザがゲームへアクセスしたという事実を重視して、被招待ユーザがゲームにアクセスしている最中だけでなく、被招待ユーザがゲームへのアクセスを終了した後においても、招待特典の享受期間を設けることができるようにしたものである。
前記招待特典を享受できる期間である「被招待ユーザのゲームへのアクセス開始から所定時間以内」に関し、例えば、前記所定時間を8時間、12時間、24時間等、任意の時間長さに設定可能である。あるいは、前記所定時間を、「被招待ユーザのゲームへのアクセス開始時刻から当該アクセス開始時刻が属する日の最終時刻(24時)までの時間」としてもよく、この場合、被招待ユーザがゲームへのアクセスを開始してから終日、招待ユーザが招待特典を享受できる期間となる。
前記の構成の場合、被招待ユーザが一旦ゲームにアクセスすれば、当該被招待ユーザによるゲームへのアクセス継続時間の長さにかかわらず、当該被招待ユーザのゲームへのアクセス開始から所定時間(例えば、12時間)以内であれば、招待ユーザの端末装置3に対してパラメータ設定手段58が設定したパラメータの値が上昇するという招待特典を、招待ユーザが享受できる。例えば、被招待ユーザが一旦ゲームにアクセスして直ぐに終了した場合であっても、その後、数時間あるいは終日、招待ユーザが前記の招待特典を享受できる状態とすることができる。
前記の構成において、ゲームサーバ1のアクセス管理手段54は、被招待ユーザのゲームへのアクセス開始時間を取得し、このアクセス開始時間を当該被招待ユーザのユーザIDと対応付けてデータベースサーバ2(記憶装置)の所定領域に記憶している。そして、被招待ユーザのゲームへのアクセス開始から所定時間以内に、当該被招待ユーザを招待した招待ユーザがゲームにアクセスしてゲームをプレイすれば、特典付与手段57が、当該招待ユーザの端末装置3に対してパラメータ設定手段58が設定した値を上昇させるので、被招待ユーザがゲームへのアクセスを終了している場合であっても、当該招待ユーザは招待特典を享受できる。
このように、被招待ユーザのゲームへのアクセスに応じて付与される招待特典の享受期間を、被招待ユーザがゲームへのアクセスを終了した後にまで拡大することにより、より魅力的な招待特典をユーザに提供することができる。これにより、ユーザに対して新たなユーザをゲームに招待しようという強い動機付けを与えることができ、ゲームサービスに登録するユーザの効果的な増加が図られ、ゲームサービスをより活性化させることができる。
また、前記招待特典と同様に、被招待ユーザ(後輩)に対して付与される新規招待登録特典においても、招待ユーザ(先輩)がゲームへのアクセスを終了した場合であっても、被招待ユーザに新規招待登録特典を付与する構成としてもよい。すなわち、特典付与手段57は、招待ユーザ(先輩)がゲームへのアクセスを終了した場合であっても、当該招待ユーザのゲームへのアクセス開始から所定時間以内は、被招待ユーザ(後輩)の端末装置3に対してパラメータ設定手段58が設定した値を上昇させるという新規招待登録特典を、被招待ユーザに対して付与する構成とすることができる。
また、上述の実施の形態では、招待ユーザから新規のゲームサービス登録を招待された被招待ユーザがゲームサービスに登録したとき、招待ユーザが「先輩」、被招待ユーザが「後輩」となり、両ユーザの関係をゲーム内で疑似的に「先輩・後輩」として関係管理手段56が管理するようになっているがこれに限定されるものではない。例えば、招待ユーザと被招待ユーザとの関係を、「親・子」、「兄・弟」、「姉・妹」、「上司・部下」、「先生・生徒」などの関係として管理してもよい。あるいは、関係管理手段56は、招待ユーザと被招待ユーザとの関係に、先輩・後輩などの特別な名称を付すことなく両ユーザの関係を管理してもよい。
また、上述の実施の形態では、特典付与手段57が、招待ユーザに特典を付与する招待特典付与部57aと、被招待ユーザに特典を付与する新規招待登録特典付与部57bとを両方とも備えている構成について説明したが、これに限定されるものではなく、特典付与手段57が招待特典付与部57aのみを備え、新規招待登録特典付与部57bを備えていない構成とすることもできる。
また、上述の実施の形態では、ゲーム実行プログラムがゲームサーバ1側に実装されており、各ユーザの端末装置3における入力操作に応じて、ゲームサーバ1がゲーム進行のための演算処理やデータ処理を実行し、その実行結果を反映させた画面データを端末装置3へ送信することによって、ゲームが進行するゲームシステムへの適用例について説明したが、これに限定されるものではない。例えば、ゲームサーバ1が、招待ユーザと被招待ユーザとの関係情報、ユーザのキャラクタ情報、所有アイテム情報、仲間情報、メッセージ情報などのゲーム情報を管理し、ゲーム内でのユーザ間のメッセージのやり取りや特典付与等のゲームサービスをユーザに提供する一方、ゲームを進行させるゲーム実行処理の一部または全部については、基本的にはユーザの端末装置側にて行われるゲームシステムにも本発明を適用できる。
すなわち、ゲーム実行プログラムの一部または全部をユーザの端末装置側にダウンロードまたはインストールし、端末装置においてもゲーム実行処理が行われるようなゲームシステムにも本発明を適用できる。例えば、ユーザの端末装置が、インターネット通信、無線LAN通信、所定の周波数帯(例えば2.4GHzの周波数帯)を用いた近距離無線通信、または有線LAN通信などにより他のユーザの端末装置とピア・ツー・ピア接続し、ピア・ツー・ピア型のゲームを実行することも可能である。
よって、ユーザの端末装置としては、ネットワーク経由でゲームサーバ(ゲーム管理装置)に接続してゲームサービスの提供を受けることができる様々なものが適用でき、前述の携帯電話端末、PHS端末、携帯情報端末(PDA)、スマートフォン、パーソナルコンピュータ、タブレット型コンピュータ以外にも、ネットワーク接続機能を有している家庭用ビデオゲーム装置(家庭用ビデオゲーム機を家庭用テレビジョンに接続することによって構成されるゲーム装置)、携帯型のゲーム専用装置、双方向の通信機能を備えた多機能型テレビジョン受像機(いわゆるスマートテレビ)なども適用可能である。
〔他の実施の形態〕
前述の各実施の形態では、新規のゲームサービス登録を招待した招待ユーザである「第1のユーザ」と、その招待に応じて新規にゲームサービスに登録した被招待ユーザ「第2のユーザ」とを関係付けて、両ユーザが関係付けられた後、「第1のユーザ」に対して、「第2のユーザ」のゲームへのアクセスまたはゲーム進行状況に応じて特典を付与する構成等について説明した。これに限らず、図32に示すように、ゲーム管理装置(ゲームサーバ1、データベースサーバ2)が、第1のユーザから所定の招待(ゲームへの招待等)または申請(仲間の申請等)を受けた第2のユーザが当該招待または申請に応じたとき、第1のユーザと第2のユーザとを関係付けた情報を記憶装置(データベースサーバ2等)に記憶して両者の関係を管理する関係管理手段56と、当該関係管理手段56によって第1のユーザと第2のユーザとが関係付けられた後、第1のユーザに対して、第2のユーザのゲームへのアクセスまたはゲーム進行状況に応じて、特典を付与する特典付与手段57と、を備えている構成であればよい。これにより、第1のユーザに対して、第2のユーザと関係を築こう(新たなユーザをゲームに招待したり、仲間関係を構築したりしよう)という強い動機付けを与えることができ、ゲームサービスを活性化させることができる。
以下には、主に、「第1のユーザ」が第2のユーザに対して仲間の申請をしたユーザであり、「第2のユーザ」が第1のユーザからの仲間の申請を承認したユーザである例について説明する。なお、既出の図面において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。
本実施の形態においては、関係管理手段56が前述の仲間管理手段60の機能を有し、ユーザ同士の仲間関係を管理する。そして、関係管理手段56が、仲間関係にある2人のユーザについて、仲間申請をした第1のユーザと、それを承認した第2のユーザとを明確に区別して管理する。図33には、関係管理手段56がデータベースサーバ2に記憶して管理する、仲間申請をした第1のユーザと、それを承認した第2のユーザとを関係付けた仲間関係情報の一例を示している。ここでは、第1のユーザから仲間申請を受けた第2のユーザが、その申請を承認したとき、第2のユーザが第1のユーザを応援する「応援団」、第1のユーザが「応援される者」となり、両ユーザの関係を関係管理手段56が管理するようになっている。このように、仲間関係を表すために、ゲーム内で「応援団」等の任意の呼称を用いてもよい。以下には、第1のユーザが第2のユーザに仲間申請をして仲間を作ることを、自分を応援してくれる仲間である「応援団」を獲得することとする例を説明する。
第1のユーザが、第2のユーザに対して、自分の応援団になってくれるよう申請を行い、それが第2のユーザによって承認されると、関係管理手段56は、応援される第1のユーザのユーザIDと関係付けて、応援団となる第2のユーザのユーザIDをデータベースサーバ2の所定の記憶領域に記憶する。図33の例では、申請したユーザID=“000001”のユーザAと、それを承認したユーザID=“000002”のユーザBとの2人のユーザを関係付けた仲間情報が、データベースサーバ2に登録されている。これにより、ユーザAは、自分を応援してくれる仲間ユーザBを、応援団として獲得したことになる。
また、各ユーザは複数の応援団を獲得することも可能である。図33の例では、ユーザAは、ユーザBだけではなく、ユーザID=“000003”のユーザCおよび“000004”のユーザDからも、申請に対する承認を得て自分の応援団にしている。
なお、ユーザBは、ユーザAの応援団であるが、ユーザB自身もまた自分の応援団を持っている。図33の例では、ユーザBは、ユーザAおよびユーザID=“000005”のユーザEを自分の応援団としている。
各ユーザが獲得できる応援団の数(第1のユーザが応援団になってくれるよう申請できる数)には上限を設定することができる。この上限としては、各ユーザに共通の1つの上限(例えば、50団体)を設けることができる。あるいは、後述するように、各ユーザのゲームの進行度合いに応じて、獲得できる応援団の数が所定範囲(例えば1〜50の範囲)で変動するようにしてもよい。
本実施の形態の仲間関係にあっては、申請をした第1のユーザとそれを承認した第2のユーザとが対等な関係ではなく、第2のユーザは第1のユーザの応援団にはなるが、第1のユーザは第2のユーザの応援団ではない。例えば、ユーザAの申請をユーザBが承認しただけでは、ユーザBがユーザAの応援団にはなるが、ユーザAがユーザBの応援団になるという相互関係にはならない。この場合、ユーザAがユーザBの応援団になるためには、今度はユーザBがユーザAに自分の応援団になってくれるよう申請を行い、それをユーザAが承認することが必要である。
第1のユーザが、第2のユーザに対して、自分の応援団になってくれるよう申請を行うときの操作は、前述の仲間申請を行うときの操作と基本的には同じである。但し、ゲームサーバ1は、2人のユーザが相互に相手の応援団になり易くするため、各ユーザが応援団になってくれるよう申請を行う場合に、以下に説明するような処理を行う。
本実施の形態のゲームのメイン画面(ユーザのマイページ)の一例を図34に示す。なお、加速度センサを搭載しているスマートフォン等の端末装置3では、ユーザが端末装置3を傾けることで自動的に縦表示・横表示の切替えが行われる。図34は、横表示の画面例である。ここでは、説明の都合上、横表示としているが、内容や文字が確認できる状態であれば、縦表示でも良いのはもちろんである。また、例えばPCやタブレット型端末等のように比較的、表示部35が大きい場合には、図34のような画面をそのまま表示できるので縦横を変更する必要もない。後記する図35についても同じである。このメイン画面には、ユーザのゲーム情報151(ユーザの写真またはアバター、ユーザのレベルなど)、各種モードを選択するためのボタン群152、ユーザがチームオーダとして設定している選手カード153、現在実行中の操作の説明や各種お知らせを表示するテキスト表示領域154、応援団を確認するための「応援団」ボタン155などが表示される。ここで、ユーザが「応援団」ボタン155を選択すれば、図35の応援団画面に遷移し、自分の「応援団」等を閲覧できるようになっている。また、この応援団画面には、自分の応援団を募集するための「応援団募集」ボタン172が設けられている。
自分の応援団を獲得しようとするユーザAは、自分の端末装置3を操作して、前記「応援団募集」ボタン172を選択する入力を行う。ゲームサーバ1は、ユーザAによる前記入力に関する情報に応じて、応援団候補のユーザを抽出する処理を実行する。この抽出処理において、ゲームサーバ1は、ユーザAが抽出対象ユーザの応援団になっているが、その抽出対象ユーザがユーザAの応援団ではないような抽出対象ユーザ(ただし、獲得できる応援団の数が上限に達しているユーザを除く)を、最優先に抽出する。この抽出処理は、データベースサーバ2に記憶されている図33の仲間関係情報に基づいて実行される。上記のような抽出対象ユーザが優先的に抽出された場合、ゲームサーバ1は、図36に示すように、ユーザAが応援団になっているユーザであることを報知する情報181を含む応援団候補リストの画面データを生成し、ユーザAの端末装置3に送信する。これにより、ユーザAは、すでに自分が応援団になっている相手に対して、応援団になってくれるように申請することが可能となる。
また、ゲームサーバ1は、獲得できる応援団の数が上限に達していないユーザ(すなわち、応援団の申請枠に空きのあるユーザ)を、応援団の数が上限に達しているユーザよりも優先的に抽出し、応援団候補リストに含める。なお、応援団候補リストに表示できる人数よりも対象となるユーザの方が多い場合には、その中からランダムに抽出したユーザを応援団候補リストに含める。このように、応援団の申請枠に空きのあるユーザ(例えばユーザGとする)を優先的に応援団候補リストに表示することにより、ユーザAが当該ユーザGに応援団になってくれるように申請すれば、その後、ユーザGからも申請枠の空きを利用してユーザAに対して応援団になってくれるように申請することができる。このようにして、2人のユーザが相互に相手の応援団になり易くしている。
ユーザAが応援団候補リストの中から、応援団になって欲しいユーザを一人選択すれば、図示しない申請画面に遷移し、選択したユーザに対して、自分の応援団になってくれるよう申請できるようになっている。この申請に際し、ユーザAが任意のメッセージを入力すれば、申請とともにメッセージが相手ユーザに届けられる。ユーザAから申請を受けたユーザ(ユーザFとする)の端末装置3には、ゲームサーバ1から送信された、ユーザAからの申請を承認するか否かを確認するための図示しない確認画面が表示される。申請者であるユーザAが既にユーザFの応援団である場合には、その旨を報知する情報が上記確認画面に表示されることが望ましい。ここでユーザFがユーザAの応援団になることを承認する入力操作を行えば、ゲームサーバ1の関係管理手段56がユーザAを「応援される者(第1のユーザ)」、ユーザFを「応援団(第2のユーザ)」としてデータベースサーバ2に登録し、その後も両者の関係を継続的に管理する。
そして、本実施の形態の特典付与手段57は、前述の各実施の形態の「先輩(第1のユーザ)」と「後輩(第2のユーザ)」との関係を、「応援される者(第1のユーザ)」と「応援団(第2のユーザ)」とに置き換えて、前述の各実施の形態と同様に、第1のユーザに対して、第2のユーザのゲームへのアクセスまたはゲーム進行状況に応じて、様々な特典を付与する。
ここで、図37に、本実施の形態のゲーム管理装置(ゲームサーバ1、データベースサーバ2)の好ましい主要な機能的構成例を示す。ゲーム管理装置は、主に、関係管理手段56、初期値記憶制御手段201、進行度合い算出手段202、特典付与手段57を備えている。
関係管理手段56は、前述のとおり、第1のユーザから所定の招待または申請を受けた第2のユーザが当該招待または申請に応じたとき、第1のユーザと第2のユーザとを関係付けた情報を記憶装置(データベースサーバ2等)に記憶して両者の関係を管理する。前述の実施の形態では、新規のゲームサービス登録を招待した招待ユーザ(第1のユーザ)を「先輩」、その招待に応じて新規にゲームサービスに登録した被招待ユーザ(第2のユーザ)を「後輩」として関係付けたが、本実施の形態では、前記招待ユーザ(第1のユーザ)を「応援される者」、前記被招待ユーザ(第2のユーザ)を応援団の上級職である「後援会」と呼称するものとする。よって、第1のユーザは、前述の仲間申請により「応援団」を獲得したり、ゲームへの招待により「後援会」を獲得したりすることができる。
初期値記憶制御手段201は、関係管理手段56によって第1のユーザと第2のユーザとが関係付けられたときの、当該第2のユーザのゲーム進行状況を示す進行パラメータの値を、初期値として記憶装置(データベースサーバ2等)に記憶する機能を有する。ここで、「第2のユーザの進行パラメータ」とは、第2ユーザ(応援団または後援会)のゲーム進行状況を示すものであり、第2のユーザのゲーム進行に伴って変化する、第2のユーザに関するゲーム上の種々のパラメータを含めることができる。例えば、第2のユーザのゲームのレベルを進行パラメータとすることができる。このゲームのレベルは、ゲームを進行させることにより獲得する経験値が所定値に達する毎に1ずつレベルアップするものであってもよいし、ゲーム内の対戦を行ってその勝利数が所定数に達する毎に1ずつレベルアップするものであってもよい。また、ユーザのゲームのレベルが大きくなるほど、レベルアップのために必要な経験値または勝利数が大きくなるようにしてもよい。
第2のユーザの進行パラメータの他の例としては、第2のユーザの所有するキャラクタのレベル又は能力値、第2のユーザのチームの戦力値、第2のユーザが到達しているゲーム内のステージの難易度の値などであってもよい。あるいは、第2のユーザのゲーム進行状況を示すパラメータであれば、これら以外の値であってもよい。これにより、例えば、第2のユーザが第1のユーザの仲間(応援団)の申請に承認して、第2のユーザが第1のユーザの応援団として関係付けられた時点における第2のユーザのゲームのレベルが、初期値として記憶される。
本実施の形態では第2のユーザの進行パラメータを、第2のユーザのゲームのレベルとする例について説明する。図38には、初期値記憶制御手段201がデータベースサーバ2の所定領域に記憶している第2のユーザのレベルの初期値の情報を例示する。同図に示すように、第1のユーザと第2のユーザとを関係付けた情報に対応付けて、両者が関係付けられた時点における第2のユーザのレベルの初期値が記憶されている。
進行度合い算出手段202は、関係管理手段56によって第1のユーザと第2のユーザとが関係付けられてからの、当該第2のユーザのゲーム上の進行度合いを、初期値記憶制御手段201によって記憶されている初期値からのゲームのレベル(進行パラメータ)の変化の差分として算出する機能を有する。例えば、第2のユーザが第1のユーザの応援団(または後援会)として関係付けられた時点における第2のユーザのゲームのレベル(初期値)をL2initial、第2ユーザのゲームのレベルの現在値をL2current、第2のユーザのゲーム上の進行度合いをP2とした場合、P2は、
P2=L2current−L2initial+a ・・・(1)
として算出できる。上式(1)中のaは定数であり、任意の数値(例えば、0、1等)をaとすることができる。本実施の形態ではa=1とする。以下、本実施の形態では、第1のユーザの応援団になった第2のユーザのゲーム上の進行度合いP2を、第2のユーザの「応援団レベル」と呼称する。
具体例を挙げると、第1のユーザAの応援団になった時点における第2のユーザBのレベル(初期値)がL2initial=Lv5であったとする。この時点では、第2のユーザBの応援団レベルP2は、1(P2=5−5+1)である。その後、第2のユーザBがゲームをプレイすることにより現在のレベルL2currentがLv24になった場合、第2のユーザBの応援団レベルP2は、24−5+1=20となる。
そして、本実施の形態の特典付与手段57は、第1のユーザに対して、前記進行度合い算出手段202によって算出された第2のユーザゲーム上の進行度合い(第1のユーザに対する応援団レベル)に応じて、特典を付与する機能を有する。ここで、第1のユーザに対して付与される特典としては、前述した様々な特典が適用できる。
本実施の形態では、特典付与手段57が、次に示す特徴的で魅力的な特典を第1のユーザに対して付与する。すなわち、特典付与手段57は、ゲーム内で対戦相手と対戦を行うゲームモードにおいて、第1のユーザが対戦を行う毎に、進行度合い算出手段202によって算出された第2のユーザの応援団レベルに応じたポイントまたはアイテムを、第1のユーザに対して付与する。
一例を挙げると、第2のユーザBの第1のユーザAに対する応援団レベルP2が20の場合、第1のユーザAが対戦を実行する毎に、第1のユーザに20ポイントが特典として付与される。このポイントは、例えばゲーム内に仮想的に設けられたショップでアイテム等を入手するときに使用できる。また、第1のユーザAが第2のユーザBだけではなく、第2のユーザC、D、…を自分の応援団としている場合は、第1のユーザAが対戦を実行する毎に、各第2のユーザB、C、D、…の第1のユーザAに対する応援団レベルを加算した分のポイントが第1のユーザAに付与される。
たとえば、ある第1のユーザに関係づけられた第2のユーザが50人存在するものとし、全ての第2のユーザの第1のユーザに対する応援団レベルが100であり、第1のユーザが1日6回の対戦(試合)を実行するものと仮定すれば、1日に30,000ポイント(50人×100×6試合)が第1のユーザに付与されることになる。このように、応援団による対戦毎の特典は合算されるため、応援団の数が多いほど、また、各々の応援団の応援団レベルが大きいほど、対戦時に第1のユーザが毎回受け取れる特典はより大きなものとなる。
このように、本構成では、第1のユーザが対戦を実行する毎に、自分の応援団である第2のユーザの応援団レベル(ゲーム上の進行度合い又は成長度合い)に応じたポイント等が当該第1のユーザに付与され続けるという魅力的な特典により、第1のユーザに対して、多くの第2のユーザと関係を築いて第2のユーザのゲーム進行を促進させようという強い動機付けを与えることができる。
なお、第1のユーザが対戦を実行する場合、第1のユーザが所有する権利アイテムまたは所定のゲーム内ポイントを必要とし、権利アイテム等の所有量に応じて対戦回数に制限がかかるようにしてもよい。本実施の形態では、1日1回以上ゲームにアクセスした各ユーザには、1日に所定枚数(例えば6枚)の「試合チケット」というアイテムがゲームサーバ1から配布される。この「試合チケット」は、1枚につき1回の対戦を行うことができる権利アイテムである。対戦に使用された「試合チケット」はユーザの手持ちからなくなる。ユーザがゲームにアクセスしない日は、前記6枚の「試合チケット」を入手できない。ユーザは、対戦毎に獲得できる特典を得るためには、毎日、ゲームにアクセスして「試合チケット」を入手する必要がある。これにより、ユーザに対して、毎日ゲームにアクセスしようとする動機付けを与えることができる。なお、ここでは、1日を期間の単位とする例を示したが、所定期間(例えば12時間)に所定回以上(2回以上であってもよい)ゲームにアクセスした各ユーザに、所定期間につき所定枚数の試合チケット(権利アイテム)を付与する構成としてもよい。
また、本実施の形態では、第1のユーザの応援団になった第2のユーザ(第1のユーザの仲間申請を承認したユーザ)に対して、応援団になったときに、報酬として所定枚数(例えば1枚)の「試合チケット」が付与されるようになっている。また、第1のユーザの後援会になった第2のユーザ(第1のユーザによってゲームに招待されたユーザ)に対して、後援会になったときに、報酬として所定枚数(例えば6枚)の「試合チケット」が付与されるようになっている。このように、応援団または後援会になることに一定のメリットを与えることにより、各ユーザが積極的に他のユーザの応援団または後援会になる動機付けを与えている。応援団になったときの報酬は、「試合チケット」以外であってもよい。なお、後述のように、応援団または後援会という関係は解消されることもある。あるユーザの応援団(または後援会)になったときに報酬として試合チケット等を受けとったユーザは、その後、関係が解消されて再度、同一のユーザの応援団(または後援会)になったとしても、報酬を受けとることはできない。
なお、「試合チケット」は、ゲーム内の対戦中に所定条件を満たしたとき(例えばユーザのチームのキャラクタが本塁打を打ったとき)に獲得できたり、対戦以外のゲームモードをプレイすることにより獲得できたりしてもよい。あるいは、課金対象のアイテムを入手するための前述のコインを使用して「試合チケット」を購入できるようにしてもよい。
なお、前述の例では、第1のユーザAの応援団になった時点における第2のユーザBの応援団レベルP2は「1」であり、第2のユーザBが応援団になってから成長(レベルアップ)していない場合であっても、第1のユーザAには第2のユーザBの応援団レベル=1に応じた「1ポイント」が特典として付与される。これに限定されず、第2のユーザBが第1のユーザAの応援団になってから成長していない場合には、第1のユーザAには第2のユーザBを応援団とする特典が付与されないようにしてもよい。例えば、上式(1)の定数a=0とした場合、第1のユーザAの応援団になった時点では、L2initial=L2currentであるため、第2のユーザBの応援団レベルP2は、P2=L2current−L2initial+0=0である。このように、応援団になったときの応援団レベルを「1」ではなく「0」にすることにより、第2のユーザBが第1のユーザAの応援団になってから成長していない場合には、第1のユーザAには第2のユーザBを応援団とする特典が付与されないようにすることができる。
次に、本実施の形態のゲーム管理装置の動作について説明する。先ず、図39のフローチャートを参照して、第1のユーザAが第2のユーザBに対して自分の応援団になってくれるよう申請したときのゲームサーバ1の処理例について説明する。
ゲームサーバ1は、第1のユーザAの端末装置3において行われる、第2のユーザBに対して応援団になってくれるよう申請する入力操作に応じて(S151でYES)、当該申請を第2のユーザBの端末装置3に通知する(S152)。その後、第2のユーザBが、第1のユーザAからの申請を承認したか拒否したかによって処理が分かれる(S153)。ここで、第2のユーザBが第1のユーザAの申請を承認した場合、ゲームサーバ1の関係管理手段56は、第1のユーザAと第2のユーザBとを関係付けた情報をデータベースサーバ2に記憶して両者の関係を管理する(S154)。本実施の形態では、図33に例示するように、第1のユーザAを応援される者、第2のユーザBを応援団として、両者の仲間関係が管理されることになる。
その後、ゲームサーバ1は、応援団となった第2のユーザBの端末装置3に対して、第1のユーザAの応援団になった旨、および報酬として「対戦チケット」が1枚付与された旨を報知する(S155)。
また、第1のユーザAの端末装置3からゲームサーバ1へのアクセスがあれば(S156でYES)、ゲームサーバ1の前述の報知手段59は、第2のユーザBが応援団になった旨、及びそれによって対戦毎に第2のユーザBの応援団レベルに応じた特典が受けられることとなった旨を報知する(S157)。
一方、ステップS153において、第2のユーザBが第1のユーザAの申請を拒否した場合、S156に移行し、第1のユーザAの端末装置3からゲームサーバ1へのアクセスがあれば(S156でYES)、ゲームサーバ1は、第2のユーザBが応援団になることを拒否した旨を報知する(S157)。
次に、図40のフローチャートを参照して、ゲームサーバ1における応援団による特典の付与処理の一例について説明する。同図は、ユーザが対戦を実行する毎に、自分の応援団の応援団レベルに応じたポイントが得られるという特典についての付与処理を例示するものである。
各ユーザは、自分の所有する任意の選手カード(キャラクタ)を所定枚数一軍に登録し、自分のチームを結成する。そして、各ユーザは、自分のチームを指揮する監督として、他のユーザのチームと対戦(本実施の形態では野球の試合)を行うことができる。
例えばユーザAが上記の対戦を行った場合(S161でYES)、ゲームサーバ1は、図33に例示する情報に基づいて、当該ユーザAに対応付けられた応援団(応援団としての第2のユーザ)が存在するか否かを判断する(S162)。ここで、ユーザAの応援団が存在する場合(S162でYES)、ゲームサーバ1の進行度合い算出手段201は、ユーザAの各応援団の応援団レベル(ゲーム上の進行度合い)を算出する(S163)。すなわち、進行度合い算出手段201は、上式(1)に従って、第1のユーザAの各応援団である第2のユーザが、第1のユーザAの応援団になったときのゲームのレベル(初期値)からのレベルの変化の差分を応援団レベルとして算出する。
その後、ゲームサーバ1の特典付与手段57は、第1のユーザAの応援団の応援団レベルと同じだけのポイントを第1のユーザAに付与する(S164)。なお、第1のユーザAに複数の応援団が存在する場合、各応援団の応援団レベルを合算したポイントが第1のユーザAに付与される。この図40のフローチャートの特典付与処理は、ユーザが対戦を行えば毎回実行される。
一方、ステップS162においてユーザAに応援団が存在しない場合(S162でNO)、特典付与処理が実行されることなく処理を終える。
なお、上記の説明では、応援団による特典について説明したが、後援会は応援団よりも特典効果の高い(第1のユーザに付与されるポイント等が大きい)仲間であり、応援団と同様に扱うことができる。すなわち、後援会は、通常の応援団よりも特典が大きくなる特別な応援団である。例えば、第1のユーザに応援団が存在する場合、その応援団の応援団レベル×1のポイントが第1のユーザに付与されるが、第1のユーザに後援会(=特典が大きくなる応援団)が存在する場合、その後援会の応援団レベル×5のポイントが第1のユーザに付与される。よって、ゲームサーバ1による特典付与処理は、後援会の場合だけ特典のポイントを5倍にするのみで、それ例外の処理は応援団と同様である。
なお、後援会は、第1のユーザの招待に応じてゲームに新規登録した第2のユーザであるため、後援会になったときの第2のユーザのゲームレベルの初期値は「Lv1」である。よって、初期値からのゲームレベルの変化の差分であるゲーム上の進行度合い(応援団レベル)は、後援会の場合、現在のゲームレベルと等しいことになる。
以上のように、本実施の形態のゲーム管理装置は、図37に示すように、主に、関係管理手段56、初期値記憶制御手段201、進行度合い算出手段202、特典付与手段57を備えている構成である。これにより、第1のユーザにとっては、第1のユーザと第2のユーザとが関係付けられた後において、第2のユーザのゲーム上の進行度合い(応援団レベル)に応じた特典を継続的に享受できるので、例えば仲間になったときや招待成功時に1回だけポイントが付与される従来の特典よりも魅力的な特典となっている。このような従来にはない斬新で魅力的な特典をユーザに提供することができるので、第1のユーザに対して、第2のユーザと関係を築こう(新たなユーザと仲間関係を構築したり、ゲームに招待したりしよう)という強い動機付けを与えることができる。これにより、ゲームサービスを活性化させることができる。
また、第1のユーザに付与される特典は、第1のユーザと第2のユーザとが関係付けられてからの、第2のユーザのゲーム上の進行度合い(応援団レベル)に応じたものとなっているので、第1のユーザは、第2のユーザのゲーム進行を促進させるために、第2のユーザとコミュニケーションをとる動機付けを与えられることになる。これによりゲームコミュニティの活性化が図られる。
各ユーザは自分の応援団等を図35に例示する応援団画面で確認することができる。図35に示すように、応援団画面には、「自分の応援団」ボタン161、「応援している仲間」ボタン162および「後援会」ボタン163が設けられている。「自分の応援団」ボタン161を選択すれば、現在、自分の応援団となっている第2のユーザの一覧が表示される。また、「応援している仲間」ボタン162を選択すれば、現在、自分が応援団になって応援している仲間の一覧が表示される。また、「後援会」ボタン163を選択すれば、現在、自分の後援会となっている第2のユーザの一覧が表示される。図35は、「自分の応援団」ボタン161が選択されている場合の画面例である。この画面には、各応援団の情報表示領域164が設けられる。この情報表示領域164には、応援団として応援してくれる第2のユーザのアバター(または写真)165、代表的な選手カード166、ユーザ名167、ゲームレベルの初期値168、ゲームレベルの現在値169、応援団レベル170および後述する応援団員数171などが表示される。なお、画面に表示しきれない応援団の情報については、画面スクロール等の操作により表示させることができる。
各ユーザは、上記の応援団画面で各応援団の応援団レベルを確認し、応援団レベルが低いユーザに対しては、例えば、「レベルアップ頑張ろう」等のメッセージを送ってゲーム進行を促進させるように働きかけることができる。
次に、各ユーザのゲームレベル(ゲーム進行状況を示す進行パラメータ)に応じて、各ユーザが獲得できる応援団の数を可変する構成について説明する。図41に示すように、この構成のゲーム管理装置は、図37に示す各手段に加えて、応援団数管理手段203(仲間数管理手段)を備えている。
応援団数管理手段203は、第1のユーザのゲームのレベル(ゲーム進行状況を示す進行パラメータ)が大きいほど、当該第1のユーザが応援団(仲間)になってくれるよう申請をすることができる数を増加させる機能を有する。例えば、ユーザのゲームのレベルが「Lv1」のとき、応援団の申請は1人だけしかできないこととする。その後、ユーザのゲームのレベルが「1」上昇する毎に、応援団の申請ができる数を1ずつ増やす。なお、ユーザのゲームのレベルの最大値をLv50とした場合、応援団数の最大値も50となる。これは一例であり、例えば、ユーザのゲームのレベルが「2」上昇する毎に、応援団の申請ができる数を1ずつ増やしたり、ユーザのゲームのレベルが「1」上昇する毎に、応援団の申請ができる数を2ずつ増やしたりしても良い。
第1のユーザを応援してくれる応援団が多いほど、第1のユーザは、多くの特典を獲得できる。よって、より多くの応援団を作るべく、各ユーザに積極的にゲームをするよう動機付ける(各ユーザのゲーム進行を促進させる)ことができる。
なお、ユーザが獲得できる応援団の数を決定するための「ゲーム進行状況を示す進行パラメータ」は、ユーザのゲームのレベルに限らず、前述のように、ユーザの所有するキャラクタのレベルやユーザが到達しているゲーム内のステージの難易度等であってもよい。
次に、ゲーム内でユーザ同士が対戦を行う場合に、一方のユーザを応援する全ての応援団の応援団レベルの合計値と、他方のユーザを応援する全ての応援団の応援団レベルの合計値との比較結果に応じて戦力を可変する構成について説明する。
本実施の形態では、応援団レベル=応援団員数とし、応援団の応援団レベルが大きくなるとその応援団に所属する応援団員数も多くなるというゲーム内の演出を行うようになっている。例えば、図35に示すように、ユーザAの応援団であるユーザBの応援団レベルが20の場合、その応援団(ユーザB)の応援団員は20人である。また、ユーザAの他の応援団であるユーザCの応援団レベルが10の場合、その応援団(ユーザC)の応援団員は10人である。よって、ユーザAを応援する全ての応援団の応援団レベル(=応援団員数)の合計値とは、そのユーザAを応援する応援団員総数のこととなる。
そして、ユーザAが他のユーザと対戦を行う場合に、ユーザAの応援団総数が対戦相手ユーザの応援団員総数よりも大きい場合、対戦相手よりも大きな応援を受けて「盛り上がり効果」が発生するものとする。この「盛り上がり効果」とは、対戦時にユーザAにとって有利な効果を発生させるものであり、対戦時のユーザAの戦力を現戦力よりも向上させる(または、対戦相手ユーザの戦力を現戦力よりも低下させる)ものである。
図42に示すように、これを実現するゲーム管理装置は、図37に示す各手段に加えて、合計算出手段204、比較手段205および戦力可変手段206を備えている。
合計算出手段204は、第1ユーザに対して関係付けられている全ての第2のユーザ(応援団)のゲーム上の進行度合い(応援団レベル)の合計値を算出する機能を有する。例えば、第1のユーザAに対して、第2のユーザB、C、D、…が「応援団」として関係付けられているものとする。そして、第2のユーザB、C、D、…のそれぞれのゲーム上の進行度合いである応援団レベルをP2(B)、P2(C)、P2(D)、…とした場合、合計算出手段204は、合計値Ptotal=P2(B)+P2(C)+P2(D)+…を算出する。上記のように、応援団レベル=応援団員数とする演出を行う場合には、前記合計値が応援団員総数となる。
比較手段205は、対戦を行う両ユーザを別個の第1のユーザとし、合計算出手段204によって算出された両ユーザのそれぞれの前記合計値(応援団員総数)を比較する機能を有する。例えば、第1のユーザAには応援団として第2のユーザB、C、D、…が関係付けられ、第1のユーザQには応援団として第2のユーザR、S、T、…が関係付けられているものとする。そして、第1のユーザAと第1のユーザQとが対戦する場合、第1のユーザAに対して関係づけられている全ての第2のユーザB、C、D、…の応援団員数の合計値Ptotal(A)と、第1のユーザQに対して関係づけられている全ての第2のユーザR、S、T、…の応援団員数の合計値Ptotal(Q)とが比較される。
戦力可変手段206は、比較手段205による比較の結果に基づいて、両ユーザのうちの前記合計値(応援団員総数)の大きい方のユーザの対戦時の戦力を現戦力よりも向上させる、又は両ユーザのうちの前記合計値の小さい方のユーザの対戦時の戦力を現戦力よりも低下させる機能を有する。ここで、「戦力を現戦力よりも向上させる」の例としては、応援団員総数の大きい方のユーザのチームを構成する各選手カード(キャラクタ)の戦力に関係するパラメータ(調子、能力等)を、現在値よりも所定量だけ向上させることが挙げられる。各選手カードには前述した6段階の調子のパラメータの何れかが設定されており、戦力可変手段206は、例えば、応援団員総数の大きい方のユーザのチームを構成する全選手カードの調子を所定段階(例えば1段階)ずつ上げる。あるいは、応援団員総数の小さい方のユーザのチームを構成する全選手カードの調子を所定段階(例えば1段階)ずつ下げることにより、相対的に、応援団員総数の大きい方のユーザが有利になるようにしてもよい。
ここで、対戦を行う両ユーザの応援団員総数に応じて戦力を可変する処理の一例を、図43のフローチャートを参照しながら説明する。
例えばユーザAのチームとユーザQのチームとが対戦を行う場合(S171でYES)、ゲームサーバ1は、図33に例示する情報に基づいて、当該ユーザAまたはユーザQの少なくとも一方に対応付けられた応援団(応援団としての第2のユーザ)が存在するか否かを判断する(S172)。ここで、ユーザAまたはユーザQに応援団が存在する場合(S172でYES)、ゲームサーバ1の合計算出手段204は、ユーザAの応援団員総数およびユーザQの応援団員総数をそれぞれ算出する(S173)。その後、比較手段205は、ユーザAの応援団員総数とユーザQの応援団員総数とを比較し(S174)、戦力可変手段206は、その比較結果に基づき、応援団員総数の大きい方のユーザのチームの全選手カードの調子を1段階ずつ上げる(S175)。なお、対戦を行う両ユーザのうち、一方のユーザには応援団が存在するが、他方のユーザには応援団が存在しない場合、応援団が存在しない方の応援団員総数は0となるので、当然のことながら応援団が存在する方のユーザが応援団員総数の大きい方のユーザとなる。
このようにして戦力が可変された後、対戦ゲームが実行されることになる。例えば、AI(Artificial Intelligence)プログラムにより、両チームの選手カードの能力、調子等のパラメータに基づいて、野球の試合のシミュレーションが実行される。前述のように、端末装置3にゲーム実行プログラムの一部または全部をダウンロードまたはインストールし、端末装置3側でゲーム実行処理を行い、各選手カードのキャラクタが3Dの動画で画面に表示されるようにしてもよい。
一方、ステップS172においてユーザAおよびユーザQの何れにも応援団が全く存在しない場合(S172でNO)、戦力可変処理が実行されることなく図43の処理を終え、その後に対戦ゲームが実行されることになる。
以上のように、本実施の形態のゲーム管理装置は、図42に示すように、合計算出手段204、比較手段205および戦力可変手段206を備えている構成である。これにより、対戦を行う両ユーザのゲームのレベル(進行度、習熟度)が同じであっても、よりゲームプレイに熱心でゲーム上の進行度合いが大きい第2のユーザ(応援団)を集めた方が、対戦を有利に進めることができるという興趣性の高いゲームを実現できる。
次に、応援団の解散(第1のユーザと第2のユーザとの関係の解消)について説明する。本実施の形態では、他のユーザの応援団になっているユーザが所定期間(例えば1か月間)、ゲームへアクセス(ログイン)しなければ、応援団は自然解散となる。図44に示すように、これを実現する本実施の形態のゲーム管理装置は、図37に示す各手段に加えて、アクセス情報記憶制御部54a(アクセス情報記憶制御手段)および関係解消手段207を備えている。
アクセス情報記憶制御部54aは、前述のとおり、ユーザのゲームへのアクセス情報を記憶装置(データベースサーバ2等)に記憶する機能を有する。
関係解消手段207は、アクセス情報記憶制御部54aに記憶されているアクセス情報に基づいて、第2のユーザが、所定期間、ゲームへアクセスしていないと判断したときに、第1のユーザと第2のユーザとの関係付けを解消する(応援団を解散する)機能を有する。ここで、「所定期間」は、2週間、1か月間、2か月間等、任意の期間とすることができる。本実施の形態では「所定期間」を1か月間として以下の説明を続ける。
ここで、図45のフローチャートを参照して、応援団を自然解散させる動作の一例について説明する。ゲームサーバ1は、アクセス情報記憶制御部54aに記憶されている各ユーザのアクセス情報に基づいて、1か月間(またはそれ以上の期間)、ゲームにアクセス(ログイン)していないユーザが存在するか否かを判断する(S181)。ここで、1か月間ゲームにアクセスしていないユーザが存在する場合(S181でYES)、ゲームサーバ1は、当該ユーザが応援団(第2のユーザ)として関係付けられている第1のユーザを全て抽出する(S182)。この抽出処理は、データベースサーバ2に記憶されている図33の仲間関係情報に基づいて実行できる。その後、ゲームサーバ1は、ステップS182において抽出された第1のユーザと、1か月間ゲームにアクセスしていない第2のユーザとの関係を自動的に解消することにより、応援団を自然解散させる(S183)。
従って、第1のユーザAが自分の応援団である第2のユーザB、C、D、…との関係を維持したい場合には、第2のユーザB、C、D、…が定期的にゲームへアクセスするように、第2のユーザB、C、D、…へ働きかける(例えば、普段より第2のユーザB、C、D、…とコミュニケーションをとってゲームアクセスを呼び掛ける)ことが必要である。
但し、たとえ第1のユーザAが第2のユーザB、C、D、…にゲームへアクセスするように働きかけても、中には殆どゲームにアクセスしてくれない第2のユーザもいる。第1のユーザAに付与される特典は、第2のユーザB、C、D、…のゲーム上の進行度合いに応じたものであるため、1か月間あるいはそれ以上、ゲームへアクセスしていないような第2のユーザは、ゲーム上の進行度合いも小さいはずであり、第1のユーザAにとってはあまり魅力的ではない応援団(第2のユーザ)と考えられる。よって、そのような第2のユーザとの関係が上述のように自動的に解消されることは、第1のユーザAにとって、むしろ望ましいと考えられる。
特に、第1のユーザAが獲得できる応援団の数が自分のゲームのレベルによって制限されている構成においては、1か月間以上ゲームにアクセスしていない第2のユーザが自分の応援団であることは、限られた数の応援団の枠を無駄に使用してしまうことになる。よって、そのような第2のユーザとの関係が自動的に解消されて、応援団の枠に空きができることは、ゲームを積極的にプレイする新たな第2のユーザを応援団として招き入れる機会が作れるようになるため、第1のユーザAにとっては望ましいと言える。
ところで、ゲームのレベルがまったく上がらないなど、ゲームに対して非アクティブな第2のユーザを自分の応援団に持った第1のユーザは、1か月という期間を待たずにその応援団を自主的に解散させ、新たなユーザを応援団として獲得したいと考えることもあり得る。そこで、応援団の自然解散とは別に、第1のユーザ自身の意思により、応援団を解散させることができるオプションを設けてもよい。この場合、第1のユーザは、自主的に解散させたい応援団である第2のユーザに、所定のポイントまたはアイテムを支払うことを要する。すなわち、応援団を自主的に解散させる場合には、その代価(ポイント等)の支払を求めるというペナルティ的要素を含めることにより、第1のユーザが自分の応援団を安易に解散させることのないようにしている。例えば、第1のユーザは、自主的に解散させたい応援団の応援団レベル×10ポイントを、当該応援団である第2のユーザに対して支払うことにより、第2のユーザに関係解消の承認を得ることなく、応援団を解散させることができるものとする。
なお、ユーザAとその応援団であるユーザBとの関係が解消された後、ユーザAが再びユーザBを応援団とすることもできる。但し、この場合は、ユーザBの応援団レベルは「1」からのスタートとなる。
前述のように後援会は、応援団よりも特典効果の高い仲間であり、基本的には応援団と同様に扱うことができる。よって、応援団と同じく、後援会である第2のユーザが、所定期間(例えば1か月間)、ゲームへアクセスしていない場合、第1のユーザと第2のユーザとの関係付けが解消される(後援会の自然解散)。また、ユーザは、相手に代価を支払うことにより自主的に後援会を解散することもできる。
なお、後援会には、応援団にはない招待特典を設けても良い。例えば、第1のユーザの後援会である第2のユーザのゲームのレベルに応じて、当該第1のユーザのゲーム中に招待特典である「激励会」というレアイベントを発生させる。このレアイベントについて以下に説明する。
第1のユーザの後援会である第2のユーザのゲームのレベルが基準値(例えば、20、40、60、80、100のそれぞれの値)に達した場合、その翌日、第1のユーザのゲームへのログイン時に、招待特典である「激励会」が発生する。「激励会」とは、第1のユーザを激励する会が催されるということを仮想的に演出するもので、具体的には、「激励会」が発生した日に、第1のユーザがゲームにアクセスすると、画面に「激励会発生!」といった表示が行われる。この「激励会」が発生すると、第1のユーザが一軍に登録している全ての選手キャラクタ(選手カード)の調子および体力がすべて回復する。この「激励会」という特典は、図20に示した招待特典のバリエーションに相当する。
ここで、選手キャラクタの調子が回復するとは、選手キャラクタに設定されている前述の調子のパラメータが最も高い値(5=最好調)になることをいう。これにより、第1のユーザのチームの戦力が高まる。また、選手キャラクタの体力が回復するとは、選手キャラクタに設定されている体力のパラメータが最大値になることをいう。ここで、選手キャラクタの体力とは、ゲーム内の特訓モードで選手キャラクタを特訓させることにより消費されるパラメータである。特訓モードでは、選手キャラクタの体力を消費して選手キャラクタの経験値を高め、経験値が所定値になれば選手レベル(選手キャラクタの能力の高さを表すパラメータ)が向上する。
さらに、「激励会」が発生すると、所定期間(例えば1日間)、第1のユーザが一軍に登録している全ての選手キャラクタの選手レベルが所定段階(例えば2段階)上昇した状態となり、対戦に勝ち易い状態となる。「激励会」により選手キャラクタの選手レベルが上昇している期間中は、選手レベルを表示する色を通常時と異ならせたり、選手キャラクタ自体の表示状態(色、輝度、顔の表情等)を通常時と異ならせたりすることにより、「激励会」発生中の状態をユーザに分かり易く報知する。
なお、「激励会」の効果を受けた選手キャラクタについては、その効果発生中において、特訓モードで選手レベルを向上させることはできない。これは、「激励会」の効果によって選手キャラクタの選手レベルが、一時的に向上した通常とは違う特別な状態になっているからである。同様に、選手キャラクタの選手レベルを変化させるゲームモードがある場合、「激励会」の効果を受けた選手キャラクタを当該ゲームモードで使用できないようにすることが望ましい。例えば、ユーザが同一の選手キャラクタを複数所有している場合、それらを合体させて選手キャラクタの選手レベルを向上させることができるゲームモードもその対象となる。
〔他の実施の形態〕
各種情報を記憶装置に記憶する記憶制御機能を有する構成(アクセス情報記憶制御部54a、招待関係記憶制御部56a、仲間情報記憶制御部60a、初期値記憶制御手段201など)に関し、記憶装置そのものについては当該構成に含まれないので、ゲーム管理装置(またはゲームシステム)の内外を問わず、どこに設置されていてもよい。例えば、記憶装置は、ゲームサーバ1が有するRAM13や補助記憶装置14、データベースサーバ2、端末装置3が有するRAM33や補助記憶装置39、あるいはゲーム管理装置や端末装置とは別構成のファイルサーバ(オンラインストレージ)等であってもよい。
サーバ(ゲームサーバ1、データベースサーバ2)と端末装置とは互いに通信して各種データの送受が可能であり、共にCPU、ROM、RAM、補助記憶装置、通信制御部等を備えた情報処理装置(コンピュータ)であって、同様のハード構成を有する。よって、サーバと端末装置とを含むゲームシステムにおいて、上述の各実施の形態で説明したゲーム管理装置が具備する各手段は、サーバ又は端末装置のいずれか一方が備えていればよい。すなわち、ゲーム管理装置は、互いに通信して各種データの送受を行うサーバおよび端末装置に設けられる構成とすることができ、前述の実施の形態と同様の作用効果を奏する。
また、前述の各実施の形態で説明した各構成は、適宜組み合わせて適用することができる。
また、本実施の形態に係るコンピュータ読み取り可能なプログラムは、ハードディスク、光ディスク(CD−ROM、DVD−ROM等)、フレキシブルディスク、半導体メモリ等のコンピュータ読み取り可能な各種記録媒体に記録され、当該記録媒体から読み出されてゲームサーバ1のCPU11により実行される。また、プログラムをゲームサーバ1または端末装置3に提供する手段は、前述した記録媒体に限定されるものではなく、インターネット等の通信ネットワークを介して行うこともできる。