以下、本発明の一実施の形態に係るゲーム管理装置、ゲーム管理方法及びプログラムについて、図面を参照しながら説明する。
〔ゲームシステムの概要〕
本発明の一実施の形態に係るゲーム管理装置が組み込まれたゲームシステムの構成例を、図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を介して仲間になることを承認するという、両プレイヤ間においてなされる仲間申請とその承認の操作が挙げられる。2人のプレイヤ間で仲間関係が成立した場合、ゲームサーバ1は当該2人のプレイヤの識別情報(プレイヤID)を関係付けてデータベースサーバ2に登録する。そして、ゲームサーバ1は、各プレイヤを中心とする仲間グループに所属する仲間関係にある仲間プレイヤの情報をデータベースサーバ2に記憶して、プレイヤ毎の仲間管理を行う。この仲間申請、その承認およびゲームサーバ1による仲間管理の詳細については後述する。
そして、本実施の形態のゲームサーバ1は、仲間申請をしたプレイヤおよび当該仲間申請を承認したプレイヤの2人のプレイヤ間での仲間関係の成立時に、当該2人のプレイヤ間のレベル関係を含む所定条件に基づいて仲間期間を設定するようになっている。また、ゲームサーバ1は、仲間関係が成立した2人のプレイヤに対して設定された仲間期間の終了により、原則的に、当該2人のプレイヤの仲間関係を自動的に解除するという特徴的な構成を有する。
この本実施の形態の特徴的な構成によって、プレイヤは、心理的にも行い難い仲間解除の操作を行うことなく、仲間期間の終了により仲間関係の解除が可能となる。特に、プレイヤ間で仲間関係が成立したときに仲間期間が設定されるので、例えば自分より下位レベルのプレイヤから仲間申請を受けたような場合でも、これを積極的に承諾して試しに仲間になり、仲間期間中に自分が望むような交流等ができる相手かどうかを見るといったことが可能となる。よって、プレイヤは、例えば仲間になってからあまり交流のない下位レベルの仲間プレイヤに対しては、仲間期間の終了により仲間関係を断ち、改めて、自分の好みの新たな仲間を探すことができる。したがって、プレイヤが、あまり交流のない下位レベルの仲間プレイヤを何人も抱え、自分好みの仲間のグループ構成になっていない状態で実質的に仲間が固定されてしまうことへの不満を解消できる。
もっとも、プレイヤが仲間関係を継続したい相手については、仲間関係を継続するための所定の操作(例えば、仲間期間中における仲間継続申請、または仲間期間終了後における仲間復活申請など)をすれば、仲間関係を継続することができる。あるいは、仲間期間中に2人のプレイヤ間で所定の交流が行われることにより、仲間期間が自動延長される構成により、所定の交流を続けている2人のプレイヤ間では、仲間関係が自動的に継続されるようにすることができる。
上記のように、本ゲームサーバ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に接続されている図示しないサーバとの通信も制御するようになっている。例えば、ゲームサーバ1をSNSに組み込んだシステム構成とした場合、ゲームサーバ1の通信制御部15は、SNSサーバとの間の通信を制御する。
入出力制御部16は、データベースサーバ2と通信可能に接続されており、CPU11がデータベースサーバ2に対してデータ(レコード)の読み書きを実行するときの入出力制御を行うデータベースインタフェースである。
データベースサーバ2は、ゲームサーバ1が管理する各プレイヤのゲーム情報を記憶する領域を有する記憶装置として、例えばRAID(Redundant Arrays of Inexpensive Disks)構成の大容量ハードディスク装置を具備する。このデータベースサーバ2は、例えば、各プレイヤを一意に識別する識別情報(プレイヤID)と対応付けて、各プレイヤの各種ゲーム情報(プレイヤ名、レベル、ゲーム内ポイント、所持アイテムなど)を記憶するリレーショナルデータベース、オブジェクトデータベース又はオブジェクト関係データベース等として構築することができる。
本実施の形態では、ゲーム管理装置がゲームサーバ1およびデータベースサーバ2から構成される例を示すが、これに限定されるものではない。例えば、ゲームサーバ1にデータベースサーバ2の機能を持たせて、ゲーム管理装置をゲームサーバ1のみで構成することもできる。また、ゲームサーバ1の有する各機能を複数のサーバに分散して持たせて、ゲームサーバ1を複数台のサーバとして構成することもできる。例えば、プレイヤが端末装置3を操作してゲームサーバ1へアクセスした場合に、当該プレイヤが正規のプレイヤかどうかを判別する認証機能を有する認証サーバを、ゲームサーバ1のメインサーバとは別に設け、メインサーバと認証サーバとでゲームサーバ1を構成してもよい。他の構成例としては、プレイヤが課金対象のアイテムをゲーム内で購入した場合に課金管理を行う課金管理サーバを、ゲームサーバ1のメインサーバ等とは別に設け、メインサーバ、認証サーバおよび課金管理サーバによりゲームサーバ1を構成してもよい。
また、本ゲームサービスを利用するプレイヤ数が数十万人、数百万人、あるいはそれ以上となると、多数のプレイヤの端末装置3からの巨大なアクセスにも耐え得るサーバシステムの構築が求められるため、ネットワーク4上に複数のゲームサーバ1を設けて冗長化(多重化)を図ることにより、負荷分散型のシステム構成としてもよい。この場合、複数のゲームサーバ1間の負荷を調整するためのロードバランサを設けることが望ましい。
次に、本実施の形態に係るゲームサーバ1にアクセスしてゲームサービスの提供を受けるプレイヤの端末装置3の構成を説明する。
〔端末装置の構成〕
プレイヤが操作する端末装置3としては、上述のように携帯電話端末やスマートフォンをはじめとして、ウェブサイト閲覧機能を有する様々な端末を適用できるが、本実施の形態では、携帯電話端末を例示してその構成を説明する。なお、携帯電話端末以外の端末装置3についても、ウェブサイト閲覧機能を用いてゲーム画面を表示したり、ゲームを実行するための入力操作を行うといった、ゲームをプレイする上で必要となる基本的な構成は、携帯電話端末と同様である。
ウェブサイト閲覧機能等を有する携帯電話端末は、フィーチャーフォン(Feature phone)やスマートフォン(smartphone)とも呼称され、図3にその構成例を示している。同図に示すように、端末装置3は、主に、CPU31と、主記憶装置としてのROM32及びRAM33と、画像処理部34と、表示部35と、サウンド処理部36と、音声入力部37と、音声出力部38と、補助記憶装置39と、操作入力部40と、通信制御部41とを備えており、構成要素31〜34、36および39〜41はバスライン42を介して相互に接続されている。なお、バスライン42と各構成要素との間には必要に応じてインタフェース回路が介在しているが、ここではインタフェース回路の図示を省略している。
CPU31は、ウェブブラウザを含む各種プログラムの命令を解釈して実行し、端末装置3全体の制御を行う。ROM32には、端末装置3の基本的な動作制御に必要なプログラム等が記憶されている。また、RAM33には、ROM32または補助記憶装置39からロードされた各種プログラムやデータが記憶され、CPU31に対する作業領域を確保する。HTML等で記述されたゲーム画面データを表示するウェブブラウザは、ROM32または補助記憶装置39に記憶されており、RAM33にロードされてCPU31によって実行される。また、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインソフトウェアを、ウェブブラウザと共にROM32または補助記憶装置39に記憶していてもよい。
画像処理部34は、CPU31からの画像表示命令に基づいて表示部35を駆動し、当該表示部35の画面に画像を表示させる。表示部35には、液晶ディスプレイヤ有機LE(Electro-Luminescence)ディスプレイ等の既知の種々の表示装置が適用できる。
サウンド処理部36は、音声入力部37から音声が入力されたときにアナログ音声信号をデジタル音声信号に変換するとともに、CPU31からの発音指示に基づいてアナログ音声信号を生成して音声出力部38に出力する。音声入力部37は、端末装置3に内蔵されたマイクロフォンからなり、電話通信する場合や録音を行う場合などに用いられる。音声出力部38は、電話通信時の受話スピーカおよび電話着信音やゲーム実行時の効果音などを出力するスピーカからなる。
補助記憶装置39は、各種プログラムやデータ等を格納する記憶装置である。補助記憶装置39としては、携帯電話端末の内部メモリとして、例えばフラッシュメモリドライブ等を用いることができ、また、携帯電話端末の外部メモリとして、例えばメモリカードリーダライタ等を用いることができる。
操作入力部40は、プレイヤの操作入力を受け入れて当該操作入力に対応した入力信号を、バスライン42を介してCPU31に出力するものである。操作入力部40の例としては、端末装置3の本体に設けられた方向指示ボタン、決定ボタン、英数文字等入力ボタンなどの物理的ボタンがある。また、表示部35の画面にタッチパネル(接触入力式のインタフェース)を搭載することによって表示部35をいわゆるタッチスクリーンとして構成している端末装置3の場合、当該タッチパネルも操作入力部40となる。
通信制御部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を備えている。これらの各手段51〜59は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。
ゲーム情報管理手段51は、各プレイヤのゲーム情報をデータベースサーバ2に蓄積して管理する。ゲーム情報管理手段51で管理されるゲーム情報の項目は、本ゲームサーバ1がプレイヤに提供するゲームサービスの内容によって異なる。
本ゲームサーバ1によって提供されるゲームの例としては、野球、サッカー、ゴルフなどの各種スポーツを題材としたスポーツゲーム、戦闘を題材とした戦闘ゲーム、音楽シミュレーションゲーム、その他種々のロールプレイングゲーム・育成ゲーム・シミュレーションゲームといったように、ゲーム形式・ジャンルを問わず様々なゲームを挙げることができる。その一例として、本実施の形態では、ゲームサーバ1がゲームサービスとして野球ゲームを提供する場合について、以下に説明する。
本実施の形態では、プレイヤがゲーム内において選手キャラクタを所有し、当該選手キャラクタを用いてゲーム内で他のプレイヤと試合(対戦)を行うことができる野球ゲームを例に挙げる。プレイヤが所有する選手キャラクタは、当該選手キャラクタの形態を端末装置3の画面上で視認可能としたカード形式とすることができる。すなわち、選手キャラクタは、デジタル選手カードとしてゲームサーバ1で管理されるとともに、プレイヤの端末装置3の画面に表示される。図13には、プレイヤの端末装置3の画面に表示される選手カード71を例示しており、選手キャラクタの形態およびカードのレア度(希少価値の高さを☆の多さで示したもの)などを表記したデジタル選手カードとして画面上に表示される。プレイヤは、ゲームを進行させながら選手カードを集め、自分だけのオリジナルチームを結成し、他のプレイヤと対戦してランキングを競うことができる。また、プレイヤは、集めた選手カード同士を合成することによって選手カード(選手キャラクタ)の能力を向上させる(すなわち、選手を育成する)ことができ、より強いチーム作りを目指してゲームを楽しむことができるようになっている。
このような野球ゲームにおいて、各プレイヤのゲーム情報を管理するゲーム情報管理手段51は、図5に示すように、プレイヤ情報記憶手段51a、レベル情報記憶手段51b(ゲームレベル記憶手段)、所有選手カード記憶手段51c、所有ポイント記憶手段51d、所有コイン記憶手段51e、所有アイテム記憶手段51f、試合結果記憶手段51gおよびランキング記憶手段51hなどを備えている。図7には、ゲーム情報管理手段51の各記憶手段51a〜51hがデータベースサーバ2に記憶して管理する、各プレイヤのゲーム情報の一例(この例ではプレイヤID=“000001”の1人分のゲーム情報)を示している。
プレイヤ情報記憶手段51aは、各プレイヤを一意に識別するプレイヤIDと対応付けて、ログインID、パスワード、プレイヤ名(ゲーム内で使用するニックネーム等)、チーム名等の各プレイヤに関するプレイヤ情報を、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。ここで、ログインIDおよびパスワードは、各プレイヤが端末装置3を操作してゲームサーバ1にアクセスしたときのログイン認証に用いられる。プレイヤ名およびチーム名は、プレイヤがゲームサービスを受けるための会員登録をした際や、ゲームを初めて実行した際に、プレイヤが自ら設定した任意の情報である。プレイヤ名およびチーム名は、必要に応じてゲーム画面に表示される。
レベル情報記憶手段51bは、プレイヤIDと対応付けて、ゲームレベルとしてのプレイヤのレベルや所属リーグのレベル等のレベル情報を、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。本野球ゲームでは、例えば、プレイヤがゲームを進行させることにより経験値が蓄積され、当該経験値が一定量に達することによりプレイヤのレベルがアップするようになっている。また、本野球ゲームでは、例えば、複数の異なるレベルのリーグが存在し、各プレイヤのチームが何れかのリーグに所属して、同リーグの他のプレイヤのチームと自動で試合(リーグ戦)を行うようになっている。また、このリーグ戦の成績に応じて、異なるリーグに所属するプレイヤのチーム同士の入替戦が自動で実行され、プレイヤのチームが所属するリーグレベルが変化するようになっている。レベル情報記憶手段51bは、このプレイヤのレベルや所属リーグのレベルを、プレイヤIDと対応付けて記憶する。
所有選手カード記憶手段51cは、プレイヤIDと対応付けて、ゲーム内でプレイヤが獲得して所有している選手カードの情報を、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。この選手カードの情報の例としては、選手カードを一意に識別するための識別情報(選手カードID)、選手の能力の高さを示す能力値およびレギュラー選手フラグなどがある。
図7では、3つの能力項目(能力1〜3)に対して選手の能力値を設定できる例を示している。能力項目の例としては、選手カードが野手の場合は、能力1〜3を「打撃」、「走力」、「守備」等とすることができ、また選手カードが投手の場合は、能力1〜3を「球威」、「制球」、「変化」等とすることができる。能力項目はこの例に限らず、増減可能である。レギュラー選手フラグとは、プレイヤが所有している選手カードのうち、他のプレイヤのチームとの試合に出場するレギュラー選手(チームオーダーに組み込まれた選手)であるか、それともレギュラー選手以外の控え選手であるかを判別するフラグであり、これが「1」のときレギュラー選手の選手カードとして登録されていることを示す。プレイヤは、端末装置3を操作することにより、所有している選手カードからレギュラー選手を選択したり、チームオーダーを設定したりすることができるようになっている。
また、データベースサーバ2には、選手カードIDと対応付けられて、選手カードの画像データ、選手名、ポジション、所属球団、能力値(合成により強化されていない初期値)などが記憶された選手カードデータベースが存在し、ゲーム情報管理手段51は、所有選手カード記憶手段51cが記憶している選手カードIDに基づいて、当該選手カードIDに対応する選手カードの画像データ等を取得できるようになっている。
所有ポイント記憶手段51dは、プレイヤIDと対応付けて、ゲーム内でプレイヤが所有している各種ポイント(ポイントに準ずる値などを含む)を、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。本ゲームにおいては、様々なゲームモードが存在し、ゲームモードに応じて様々なポイントを獲得したり、獲得したポイントを使用したりできるようになっている。
図7に示すように、ポイントの例としては、上述の経験値の他、行動力ポイント、運営コスト、強化ポイント、交流ポイントなどがある。行動力ポイントは、当該行動力ポイントを消費しながら選手カードを探索して選手をスカウトするという「スカウトモード」で使用される。運営コストは、他のプレイヤを指定して個別対戦の試合を行う「試合モード」で使用されるものであり、試合を運営する場合に必要なコスト(ポイント)という位置付けで、当該個別対戦を行うことにより消費される。例えば、ゲーム中に消費されて減った行動力ポイントや運営コストは、時間の経過により回復する(例えば、3分経過する毎に1ポイントずつ回復する)ようにしたり、前記経験値が一定量に達してプレイヤのレベルがアップすることにより回復するようにしたりできる。
また、前記の強化ポイントは、プレイヤが所有する選手カード同士を合成することによって選手カードの能力を向上させる「強化モード」で使用されるものであり、当該合成を行うことにより消費される。この強化ポイントは、例えばスカウトモードの実行や試合モードの実行等によって獲得できるようにすることができる。
また、前記交流ポイントは、プレイヤが他のプレイヤ(特に仲間プレイヤ)と挨拶等の交流を行うことによって獲得できるポイントである。交流の具体例等の詳細については後述する。この交流ポイントは、例えば、ゲームサーバ1が管理している全ての選手カードの中から乱数等に基づく抽選で所定枚数(例えば1枚)の選手カードを獲得できる「抽選モード」で使用可能であり、所定の交流ポイントにつき1回の選手カード抽選を受けることができる。
所有コイン記憶手段51eは、プレイヤIDと対応付けて、ゲーム内でプレイヤが所有しているコイン(前記ポイントとは別のゲーム内通貨)を、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。このコインは、例えば、課金対象のアイテムを獲得する等の際に必要となるものである。
所有アイテム記憶手段51fは、プレイヤIDと対応付けて、ゲーム内でプレイヤが獲得したアイテムを、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。図7に示すように、アイテムの例としては、回復アイテム、パズルカードのピース、フェイクカードなどがある。回復アイテムは、ゲーム中に消費して減った前述の行動力ポイントおよび/または運営コストを、時間の経過を待たずに一瞬で最大値まで回復させるアイテムである。例えば、回復アイテムは、前記コインを消費して購入したり、ゲーム内で所定のボーナス条件を満たしたりすることにより獲得できる。
パズルカードのピースは、所定数のピース(例えばP1〜P6の6つのピース)を全部集めてパズルカードを完成させることで強力な(能力値の高い)選手カードを入手することができるアイテムである。例えば、パズルカードのピースは、前記スカウトモードの実行時に乱数等に基づく抽選で当選した場合に獲得でき、また前記試合モードで他のプレイヤが所有しているピースを狙って対戦して勝利した場合に、当該対戦相手のプレイヤから奪取できるようになっている。
フェイクカードは、前記パズルカードのピースにセットしておくことにより、前記試合モードの対戦で他のプレイヤに負けても、狙われたピースを一度だけ奪取されないようにできるアイテムである。例えば、フェイクカードは、前記コインを消費して購入したり、ゲーム内で所定のボーナス条件を満たしたりすることにより獲得できる。
試合結果記憶手段51gは、プレイヤIDと対応付けて、プレイヤのチームが他のプレイヤのチームと対戦した試合を一意に特定するための試合IDを、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。ここで、試合IDにより一意に特定される試合は、プレイヤが対戦相手を指定して行う個別対戦の試合、およびゲームサーバ1により自動で行われるリーグ戦の試合を含む。
また、データベースサーバ2は、試合IDと対応付けられて、試合日時(現実世界の試合開始または終了の時間)、勝利したチームのプレイヤID、敗北したチームのプレイヤID、対戦スコア、勝利投手キャラクタ、敗戦投手キャラクタ、本塁打を打った選手キャラクタ、試合寸評情報などの試合結果に関する情報が記憶された試合データベースを備えている。そして、ゲーム情報管理手段51は、試合結果記憶手段51gが記憶している試合IDに基づいて、当該試合IDに対応する試合結果に関する情報を、試合データベースから取得できるようになっている。
ランキング記憶手段51hは、プレイヤIDと対応付けて、前記リーグ戦や入れ替え戦におけるプレイヤのチームの勝利数および敗戦数、ならびに勝利数・敗戦数に基づく所属リーグ内の順位などのランキング情報を、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。例えば、リーグ戦が現実世界における月曜日〜金曜日の各日の所定時間に所定の試合数(例えば各日12試合)自動的に行われ、また、入れ替え戦が現実世界における土曜日および日曜日の所定時間に所定の試合数(例えば各日12試合)自動的に行われるものとする。この場合、図7に示すように、ランキング記憶手段51hは、現実世界の月曜日〜日曜日の各日についてのランキング情報を記憶し、毎週、ランキング情報を最新の情報に更新する。
次に、図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のウェブブラウザのプラグインによって動作するスクリプト(プログラム)が埋め込まれていてもよい。ゲームサーバ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を備えている。図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人である。
本実施の形態の野球ゲームでは、仲間をつくることによって、後述の仲間成立ポイント付与手段59により、仲間関係になった両プレイヤにボーナスポイントが付与される(例えば、前記行動力ポイントや運営コストの最大値を所定ポイントだけ増加させることができる)。また、仲間プレイヤと協力して試合をしたり、仲間同士で選手カードのプレゼントや応援を行ったりすることで、ゲームを有利に進めることができるゲーム仕様となっている。このようにゲーム内で仲間をつくることによるメリットをプレイヤに付与することにより、仲間を作ることを促進している。
但し、各プレイヤが他のプレイヤと仲間関係を構築することができる仲間数には上限を設定することができる。仲間数の上限としては、各プレイヤに共通の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は、プレイヤの端末装置3から、他のプレイヤ(特に、仲間プレイヤ)に対して所定の交流を行う情報を受信し、受信した情報に基づいて、当該プレイヤから当該他のプレイヤに対しての交流処理を実行する機能を備えている。図6に示すように、本実施の形態の交流手段55は、挨拶手段55a、メッセージ伝達手段55b、メッセージ記憶部55c、プレゼント手段55d、対戦協力手段55eおよび交流履歴記憶手段55f等を具備する。
挨拶手段55aは、各プレイヤの端末装置3から送信された他のプレイヤ宛の挨拶情報を受信して、当該他のプレイヤへ挨拶情報を伝達する機能を有する。また、メッセージ伝達手段55bは、各プレイヤの端末装置3から送信された他のプレイヤ宛のメッセージを受信するとともに、当該メッセージを当該他のプレイヤへ伝達する機能を有する。このメッセージ伝達手段55bは、メッセージ記憶部55cを備えている。
図12には、メッセージ記憶部55cがデータベースサーバ2に記憶して管理する、受信メッセージに関する情報の一例を示している。このメッセージ記憶部55cは、メッセージを受け取った受信側プレイヤのプレイヤIDと対応付けて、送信元のプレイヤID、メッセージの内容、送信日時などのメッセージに関する情報を、受信側のプレイヤのプレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。また、各メッセージに関する情報には、各メッセージを一意に識別するためのメッセージIDが付加されている。図12の例では、プレイヤID=“000002”の受信側プレイヤ1人分の受信メッセージに関する情報を示しており、当該プレイヤは、プレイヤID=“000001”のプレイヤから「プレゼントありがとう!」、プレイヤID=“000038”のプレイヤから「おはよう!今週のイベント頑張ろう!」、プレイヤID=“000145”のプレイヤから「今週もよろしく!」というメッセージをそれぞれ受け取っている。
ここで、プレイヤが、自分の仲間プレイヤに対して、挨拶したりメッセージを送ったりする操作の一例を説明する。例えば、プレイヤが端末装置3を操作してメイン画面中の「仲間リスト」ボタンを選択すれば、端末装置3から仲間リスト要求がゲームサーバ1へ送信される。ゲームサーバ1は、プレイヤの端末装置3からこの要求を受信して、当該プレイヤの仲間リストを表示させる情報を端末装置3へ送信する。これにより端末装置3には、例えば図14に示すような仲間リスト画面が表示される。この仲間リスト画面には、プレイヤと仲間関係にある仲間プレイヤの情報がリストアップされて表示される。なお、画面に表示しきれない仲間プレイヤの情報については、画面をスクロールするまたは仲間リストの2ページ目以降をゲームサーバ1にリクエストして別画面として表示することができる。
この仲間リスト画面内にはリストアップされた仲間プレイヤ毎の情報表示領域が設けられており、各情報表示領域には、仲間プレイヤのゲーム情報81(プレイヤ名、チーム名、プレイヤのレベル、仲間の人数、所属リーグのレベル等)、当該プレイヤの分身的なキャラクタであるアバター82、当該プレイヤが所有するリーダーの選手カード83などとともに、挨拶ボタン84というオブジェクトも表示される。そして、プレイヤがこの挨拶ボタン84を選択操作することで、自分の仲間プレイヤに対してゲーム内で仮想的に挨拶することができるようになっている。例えば、プレイヤAが仲間プレイヤBの挨拶ボタン84を選択操作した場合、端末装置3から挨拶情報が送信され、この挨拶情報を受信した挨拶手段55aが、仲間プレイヤBの端末装置3へプレイヤAから挨拶があったことを伝達する。
ここで、挨拶とは、上記のようにゲーム内で仮想的に行うことができる簡易的な交流の総称であり、エール(応援)を送る、ガッツ(やる気)を送る、ウインクする、微笑む、手を振る等、別の表現を用いた簡易的な交流も含まれる。プレイヤは、仲間プレイヤに挨拶だけすることもできるが、以下に説明するように、挨拶と同時にメッセージを送ることもできる。
プレイヤの端末装置3における操作により挨拶ボタン84が選択された場合、当該操作が端末装置3からゲームサーバ1へ伝えられる。その後、ゲームサーバ1からは、例えば図15に示すメッセージ入力画面のデータが端末装置3へ送信され、端末装置3に当該メッセージ入力画面が表示される。このメッセージ入力画面には、例えば、仲間プレイヤ(図15の例ではプレイヤB)に対して挨拶した旨を示す文章等が表示されるとともに、メッセージ入力領域85および送信ボタン86というオブジェクトも表示される。そして、プレイヤは、端末装置3を操作してメッセージ入力領域85に任意のメッセージを入力し、送信ボタン86を選択することによって、端末装置3からは仲間プレイヤ宛のメッセージがゲームサーバ1へ送信される。図15では「プレゼントありがとう」というメッセージをプレイヤが入力した例を示している。なお、データベースサーバ2における記憶容量を考慮して、メッセージ入力領域85に入力できる文字に制限(例えば全角30文字以内)を設けてもよい。
なお、メッセージ入力画面には、仲間プレイヤ(この例ではプレイヤB)のページへ遷移するためのハイパーリンク87が表示されており、このリンクを選択することにより当該仲間プレイヤのゲーム情報の詳細が記載されたページを表示できる。また、メッセージ入力画面には、仲間リストへ遷移するためのハイパーリンク88やメイン画面へ遷移するためのハイパーリンク89なども表示されており、これらのリンクを選択することにより仲間リストやメイン画面に戻れるようになっている。
このメッセージ入力画面でのプレイヤの操作により端末装置3からメッセージが送信された場合、ゲームサーバ1では、メッセージ伝達手段55bのメッセージ記憶部55cが、端末装置3から受信した仲間プレイヤ宛のメッセージを、当該仲間プレイヤのプレイヤIDと対応させてデータベースサーバ2に記憶する(図12参照)。そして、当該仲間プレイヤの端末装置3がゲームサーバ1へアクセスしたとき、ゲームサーバ1のメッセージ伝達手段55bは、メッセージ、送信元のプレイヤ名、送信時間等を表示させる画面データを端末装置3に送信する。これにより、この画面データを受信したプレイヤの端末装置3にはメッセージ等が表示され、他の仲間から受け取ったメッセージを画面で確認できるようになっている。
このように、本実施の形態のゲームシステムでは、前記図14および図15に例示するようなコミュニケーションツールを使用して、仲間同士が何時でもコミュニケーションをとることができるようになっている。
前記図14および図15の例では、プレイヤの仲間に対してメッセージを送る例を説明したが、仲間関係にはない他のプレイヤに対しても、挨拶したりメッセージを送ったりすることもできる。例えば、仲間候補リストにリストアップされた仲間ではない他のプレイヤに対して、仲間の場合と同様の操作により、挨拶やメッセージを送ることも可能である。
プレゼント手段55dは、各プレイヤの端末装置3から送信された他のプレイヤ宛のプレゼントの情報を受信して、当該他のプレイヤへプレゼントを届ける機能を有する。プレゼントの対象としては、プレイヤがゲーム内で所有している選手カードや各種アイテムなどが挙げられる。
対戦協力手段55eは、プレイヤ(プレイヤAとする)の端末装置3から、仲間プレイヤに対して対戦協力を要請する情報を受信し、プレイヤAのキャラクタ(複数のキャラクタからなるグループやチームでもよい)が他のキャラクタと対戦するときに、仲間プレイヤのキャラクタ(例えば、リーダーの選手カード)を、「助っ人」としてプレイヤA側に加担させて対戦協力を実行する機能を有する。このように、仲間プレイヤのキャラクタが助っ人としてプレイヤA側に加担して対戦協力することにより、プレイヤA側の戦力が向上するので、当該対戦協力がない場合に比べて、プレイヤAの対戦が有利になる。
なお、プレイヤのキャラクタが他のキャラクタと対戦する場合の「他のキャラクタ」とは、他のプレイヤのキャラクタ(複数のキャラクタからなるグループやチームでもよい)又はゲームサーバ1のCPUが用意したキャラクタ(例えば、各ステージの最後に登場するボスキャラクタ等)のいずれであってもよい。
プレイヤが端末装置3を操作して、助っ人にしたい仲間プレイヤのキャラクタ(または仲間プレイヤ)を選択すれば、端末装置3からは、選択された仲間プレイヤのキャラクタ(または仲間プレイヤ)の情報を含む対戦協力要請情報がゲームサーバ1へ送信される。そして、ゲームサーバ1の対戦協力手段55eは、プレイヤの端末装置3から送信された対戦協力要請情報を受信して、当該プレイヤが選択した仲間プレイヤのキャラクタを助っ人として受け付ける。
図16Aに、対戦モードにおけるゲーム画面の一例を示している。このゲーム画面には、プレイヤが指定した対戦相手のチーム(敵軍)の情報91およびプレイヤのチーム(自軍)の情報92が表示される。対戦相手のチーム(敵軍)の情報91としては、例えば、対戦相手のプレイヤ名、アバター、選手カード、戦力に関する情報などが表示される。また、プレイヤのチーム(自軍)の情報92としては、当該プレイヤのプレイヤ名、アバター、選手カード、戦力に関する情報などが表示される。さらに、このゲーム画面の助っ人表示領域93には、助っ人として自軍に協力するキャラクタ等の情報が表示されるようになっている。このゲーム画面は、ゲームサーバ1のゲーム画面生成手段52bにより生成されるとともに、ゲーム画面送信手段52cによりプレイヤの端末装置3へ送信されるものであり、端末装置3の表示部35に表示される。
また、助っ人表示領域93には、「助っ人を呼ぶ」ボタン93a(またはハイパーリンクが設定された文字列等)が表示され、任意の仲間のキャラクタを助っ人として要請できるようになっている。プレイヤが「助っ人を呼ぶ」ボタン93aを選択することにより、例えば図16Bに示す助っ人選択画面に遷移する。この助っ人選択画面には、プレイヤと仲間関係にある仲間プレイヤおよび当該仲間プレイヤが有するキャラクタ(選手カード)がリストアップされて表示される。なお、画面に表示しきれない情報については、画面をスクロールするまたは助っ人選択画面の2ページ目以降をゲームサーバ1にリクエストして別画面として表示することができる。
この助っ人選択画面内にはリストアップされた仲間プレイヤ毎の情報表示領域が設けられており、各情報表示領域には、仲間プレイヤの名前94a、仲間プレイヤのアバター94b、仲間プレイヤが有する選手カード94c、選手名94d、当該選手カードの情報(選手カードに設定されているレベルや攻撃力等)94eなどが表示される。図16Bでは、仲間プレイヤが有する複数の選手カードのうち、リーダーとして設定されている選手カードを助っ人のキャラクタとして選択可能な例を示している。これに限らず、例えば、エース投手や4番打者として設定されている選手カードなどの代表的なキャラクタを、仲間の助っ人として選択可能としてもよい。そして、プレイヤが端末装置3を操作して、例えば仲間プレイヤの名前94aに設定されたハイパーリンク表示部分を選択することにより、助っ人にしたい仲間のキャラクタを選択できるようになっている。
例えば、図16Bの助っ人選択画面において、プレイヤAが端末装置3を操作して仲間プレイヤBのキャラクタを助っ人として選択した場合、図16Cに例示するゲーム画面に遷移し、助っ人表示領域93には、プレイヤBの選手カード95が助っ人として表示される。また、助っ人表示領域93には、対戦協力する仲間プレイヤのアバターや対戦協力による戦力アップ情報等も併せて表示される。図16Cの画面例では、対戦協力による戦力アップ情報として「攻撃力+200」が表示されている。本形態においては、助っ人として選択されたプレイヤ側の承認は不要であり、プレイヤAは相手の意図を気にすることなく任意に選択できる。
なお、プレイヤが仲間の助っ人を選択すれば、ゲームサーバ1において当該仲間の助っ人の情報を当該プレイヤのプレイヤIDと対応付けてデータベースサーバ2(記憶装置)に記憶する。よって、プレイヤが仲間の助っ人を選択する操作を行えば、次回の対戦においても、前回選択した仲間のキャラクタが助っ人として設定されるようにすることができる。また、仲間のキャラクタが助っ人として設定されているとき、助っ人表示領域93には、「助っ人を変更する」ボタン96(またはハイパーリンクが設定された文字列等)が表示されるようになっている。プレイヤがこのボタン96を選択することにより、図16Bの助っ人選択画面に遷移し、助っ人にしたい仲間のキャラクタを選択し直すことができるようになっている。
図16Aまたは図16Cの対戦モードの画面において、プレイヤが「対戦開始」ボタン97を選択する操作を行うことにより、プレイヤの端末装置3からは対戦コマンドがゲームサーバ1へ送信され、ゲームサーバ1において対戦処理が実行される。そして、助っ人表示領域93に仲間のキャラクタが助っ人として表示されているときに「対戦開始」ボタン97を選択する操作が行われることにより、対戦コマンドと併せて仲間プレイヤに対して対戦協力を要請する情報が、端末装置3からゲームサーバ1に送信される。この場合、仲間プレイヤのキャラクタを助っ人としてプレイヤ側に加担させる対戦協力が実行されることになる。
なお、交流手段55が実行する交流処理の対象となる交流は、上述の挨拶、メッセージの送信、プレゼント、協力対戦の助っ人依頼に限定されるものではなく、仲間のプレイヤ同士で行われる様々な交流を含めることができる。交流のその他の例としては、合同練習などがある。合同練習とは、交流の一種であり、プレイヤがゲーム内で仮想的に仲間プレイヤとともに行う練習である。合同練習を希望するプレイヤは、仲間プレイヤを指定して合同練習を申込み、当該仲間プレイヤが所定期間内に(例えば、申込みがあったその日のうちに)ゲームにアクセス(ログイン)した場合に合同練習が成立する。また、交流のその他の例としては、チャットなどの、プレイヤ同士がリアルタイムで行うことができる交流もある。チャットの場合、2人または3人以上のプレイヤの端末装置3において、文字情報(チャットメッセージ)等を交換しあってリアルタイムでコミュニケーションを図ることができる。
つぎに、交流履歴記憶手段55fについて説明する。交流履歴記憶手段55fは、各プレイヤの交流履歴をデータベースサーバ2(記憶装置)に記憶する。交流手段55において、プレイヤから他のプレイヤに対しての交流処理が実行されたとき、交流履歴記憶手段55fは、交流履歴として、例えば図17に示すように、交流情報ID、交流をしたプレイヤID、交流相手のプレイヤID、交流種別、交流処理実行時の時間情報等を記憶する。交流種別とは、挨拶、メッセージ、プレゼント、対戦協力、合同練習、チャット等の、具体的な交流の内容を示すものである。交流処理実行時の時間情報としては、年、月、日、時、分、秒等の時間情報を記憶するが、ここで記憶する時間の単位は任意に設定できる。
なお、この交流履歴記憶手段55fにより記憶される情報は、後述する延長手段61において延長の条件を満たすか否かの判断にも使用される。延長の条件としては、交流回数、交流時間、または交流回数及び交流時間が規定される。ここで、延長の条件として交流時間を含む所定条件が規定される場合には、例えばプレイヤ同士がリアルタイムで行うことができるチャット等の交流について、プレイヤ間の交流時間の情報も、交流履歴記憶手段55fにより記憶される。プレイヤ間の交流時間の情報としては、例えば、チャット開始時間およびチャット終了時間の情報であってもよいし、チャット開始から終了までの時間の長さの情報であってもよい。ゲームサーバ1は、例えばCPU11の内部時計に基づく計時によりプレイヤ間の交流時間を計時することができる。
次に、仲間期間設定手段56について説明する。仲間期間設定手段56は、仲間申請をしたプレイヤ(第1のプレイヤ)および当該仲間申請を承認したプレイヤ(第2のプレイヤ)の2人のプレイヤ間での仲間関係の成立時に、第1のプレイヤのゲームレベルと第2のプレイヤのゲームレベルとの関係を含む所定条件に基づいて、仲間期間を設定する機能を有する。仲間期間が終了すれば、原則、2人の仲間関係は自動的に解除されることになる。
ここで、仲間期間を決定するために用いられる「ゲームレベル」とは、プレイヤのゲームの進行度合い、熟練度、力量等を直接的または間接的に示す指標情報である。このゲームレベルとしては、(a)プレイヤ自身のレベル、(b)プレイヤのゲーム内の所有物のレベル(所有物の例:キャラクタ、キャラクタの集合体であるグループ・チーム・ユニット、アイテム等)、(c)プレイヤのゲーム内の所有物の数・所有物の能力値等から算出される値、(d)プレイヤが達成したステージのレベルや現在所属しているリーグのレベル、等を挙げることができる。
前記(a)の具体例としては、プレイヤがゲームを進行させて経験値を蓄積することによりレベルアップするゲームにおけるプレイヤのレベルがある。また、前記(b)の具体例としては、プレイヤが所有するキャラクタを練習モード、試合モード、育成モード、合成モード等で使用することによりキャラクタの強化・レベルアップを図るゲームにおけるキャラクタのレベルがある。ここで、キャラクタのレベルとは、キャラクタの成長度合い、能力の高さ、強さ等を表す値であればよく、キャラクタの能力値であってもよい。
また、前記(c)の具体例としては、プレイヤがゲームを進行させることによりキャラクタやアイテムを取得するゲームにおいて、プレイヤが所有するキャラクタやアイテムの数の多さを評価する値がある。例えば、プレイヤが所有する所定の能力値以上のキャラクタ(選手カード)の数をプレイヤのゲームレベルとすることができる。
また、前記(d)の具体例としては、ゲーム内にレベル(難易度)の異なる複数のステージが設けられており、1つのステージをクリアしたら1つ難易度の高い別のステージに進むようなゲームにおけるプレイヤが達成したステージのレベルがある。また、前記(d)の他の具体例としては、プレイヤがリーグ戦で上位の成績を獲得することによって、よりレベルの高いリーグに所属できるようなゲームにおける現在所属しているリーグのレベルがある。
本実施の形態では、仲間期間を決定するために用いられるゲームレベルとして、前記(a)プレイヤ自身のレベルを適用した例について以下に説明する。
仲間期間設定手段56は、仲間申請をした第1のプレイヤとそれを承認した第2のプレイヤとのレベル関係を含む所定条件に基づいて仲間期間を決定するのであるが、その例を次に説明する。仲間期間設定手段56は、第1のプレイヤよりもゲームレベルが高い第2のプレイヤが仲間申請を承認した場合に設定する仲間期間を、第1のプレイヤとゲームレベルが同じ又は第1のプレイヤよりもゲームレベルが低い第2のプレイヤが仲間申請を承認した場合に設定する仲間期間よりも短くする。その具体例としては、仲間申請をした第1のプレイヤのレベルをL1、それを承認した第2のプレイヤのレベルをL2とした場合、仲間期間設定手段56は、L1<L2のときには5日、L1=L2のときには7日、L1>L2のときには10日の仲間期間とする。なお、仲間期間の日数はこれらに限定されるものではなく、例えばL1<L2のときには1週間、L1=L2のときには2週間、L1>L2のときには3週間とするなど、任意の期間を設定できる。
L1<L2の場合とは、第1のプレイヤよりもゲームレベルが高い第2のプレイヤが仲間申請を承認した場合である。この場合は、承認した第2のプレイヤにとって、自分よりも下位レベルのプレイヤ(即ち、対戦協力等の貢献度の低いプレイヤ)と仲間になるのであるから、自分が望むような交流等ができない仲間であった場合には短期間で仲間関係を解消したいと希望することが多い。そこで、L1=L2の場合(同レベル間で仲間成立)またはL1>L2の場合よりも仲間期間を短くしている。
一方、L1>L2の場合とは、第1のプレイヤよりもゲームレベルが低い第2のプレイヤが仲間申請を承認した場合である。この場合は、承認した第2のプレイヤにとって、自分よりも上位レベルのプレイヤ(即ち、対戦協力等の貢献度の高いプレイヤ)と仲間になるのであるから、L1=L2またはL1<L2の場合よりも仲間関係を長く継続したいと希望することが多い。そこで、L1=L2またはL1<L2の場合よりも仲間期間を長くしている。
上記のように、仲間申請を承認した側が申請した側よりも上位レベルであるか否かによって仲間期間を変えることにより、承認した側のプレイヤの希望に沿った適切な仲間期間の設定が可能となる。このように、仲間申請をした側のプレイヤではなく、仲間申請を承認した側のプレイヤからみた適切な仲間期間の設定を行う理由は、次の通りである。すなわち、仲間申請をした側のプレイヤにとっては、相手のプレイヤのレベルにかかわらずその相手と仲間になりたいと考えて仲間申請しているはずである。一方、仲間申請を受けたプレイヤにとっては、それを拒否することもできるが、下位プレイヤからの申請だからといって無碍に断れずにその申請を承認してしまい、後で後悔することも従来は多かった。そこで、仲間申請を承認した側のプレイヤからみた適切な仲間期間の設定を行うのである。
次に、仲間期間設定手段56による仲間期間決定処理の他の例を説明する。仲間期間設定手段56は、仲間関係が成立したプレイヤ間のレベル差に応じて、仲間期間を設定するようになっている。以下、仲間申請をした第1のプレイヤのレベルをL1、それを承認した第2のプレイヤのレベルをL2、L1とL2との差をレベル差Dとして説明を続ける。また、図18には、レベル差Dと仲間期間との関係を表すテーブルを例示している。このテーブルの情報は、ゲームサーバ1の記憶手段(RAM13または補助記憶装置14等)に記憶されており、仲間期間設定手段56による処理中に参照される。
まず、仲間申請した第1のプレイヤよりもレベルが高い第2のプレイヤが仲間申請を承認した場合を考える(L1<L2の場合)。この場合、図18に例示するテーブルに示すように、仲間期間設定手段56は、レベル差Dが大きいほど、仲間期間を段階的に短く設定する。図18のテーブルの例では、レベル差Dが1〜9のとき7日、10〜29のとき6日、30〜49のとき5日、50〜69のとき4日、70〜99のとき3日、100以上のとき2日に設定される。なお、仲間期間の日数はこれらに限定されるものではなく、レベル差Dが大きいほど仲間期間が短くなるという条件を満たせば、任意の期間を設定できる。
このように、仲間申請した第1のプレイヤよりもレベルが高い第2のプレイヤが仲間申請を承認した場合は、承認した第2のプレイヤにとって、自分よりも下位レベルの第1のプレイヤとのレベル差Dが大きいほど、第1のプレイヤから受ける対戦協力等による貢献の程度は小さくなる。そこで、この場合には、レベル差Dが大きいほど仲間期間を短く設定することにより、承認した第2のプレイヤにとって望ましい仲間期間の設定を実現しているのである。
次に、仲間申請した第1のプレイヤよりもレベルが低い第2のプレイヤが仲間申請を承認した場合を考える(L1>L2の場合)。この場合、図18に例示するテーブルに示すように、仲間期間設定手段56は、レベル差Dが大きいほど、仲間期間を段階的に長く設定する。図18のテーブルの例では、レベル差Dが1〜9のとき7日、10〜29のとき8日、30〜49のとき9日、50〜69のとき10日、70〜99のとき11日、100以上のとき12日に設定される。なお、仲間期間の日数はこれらに限定されるものではなく、レベル差Dが大きいほど仲間期間が長くなるという条件を満たせば、任意の期間を設定できる。
このように、仲間申請した第1のプレイヤよりもレベルが低い第2のプレイヤが仲間申請を承認した場合は、承認した第2のプレイヤにとって、自分よりも上位レベルの第1のプレイヤとのレベル差Dが大きいほど、第1のプレイヤから受ける対戦協力等による貢献の程度は大きくなる。そこで、この場合には、レベル差Dが大きいほど仲間期間を長く設定することにより、承認した第2のプレイヤにとって有利な仲間期間の設定を実現しているのである。
また、仲間申請した第1のプレイヤとそれを承認した第2のプレイヤのレベルが同じ場合(L1=L2の場合)、図18に例示するように、仲間期間設定手段56は、仲間期間を7日に設定する。
仲間期間設定手段56は、仲間関係が成立した2人のプレイヤに対して設定した仲間期間をデータベースサーバ2(記憶装置)に記憶する仲間期間記憶手段56aを備えている。図11に、仲間期間記憶手段56aが記憶する仲間期間の例を示している。仲間期間記憶手段56aは、仲間情報IDと対応づけて、仲間期間(期間の長さ)および仲間期間終了予定時間等を記憶する。ここで、仲間期間終了予定時間とは、仲間期間の最終時刻にあたる現実世界の時間情報であり、年、月、日、時、分、秒等の時間が記憶される。ここで時間の単位は任意に設定できる。本実施の形態では、仲間期間記憶手段56aが、仲間期間終了予定時間として、仲間期間の最終時刻にあたる現実世界の日付(年月日)を記憶する例を示す。また、仲間期間記憶手段56aが、仲間情報IDと対応づけて、仲間期間が設定された日時や仲間関係が成立した日時等の時間情報を併せて記憶してもよい。
次に、仲間関係解除手段57について説明する。仲間関係解除手段57は、仲間関係が成立している2人のプレイヤに対して設定された仲間期間の終了により、当該2人のプレイヤの仲間関係を自動的に解除する機能を有する。ここで、自動的に解除するとは、プレイヤによる自主的な解除操作がなくとも、ゲームサーバ1側で仲間関係の解除処理を実行することを意味する。仲間関係解除手段57は、データベースサーバ2に登録されている図8に示す仲間情報のうち、仲間関係が解除された仲間情報に該当する情報に解除フラグを付加したり当該情報を削除したりすることにより、仲間関係の解除処理を実行する。
次に、仲間期間報知手段58について説明する。プレイヤは、端末装置3に表示される仲間リスト等の画面で、自分の仲間プレイヤとの間に設定されている仲間期間がいつまでなのかを確認できるようになっている。これを実現するために、仲間期間報知手段58は、仲間期間記憶手段56aに記憶されている仲間期間の情報を読み出し、プレイヤと仲間プレイヤとの間に設定されている仲間期間を表示させるための情報を、当該プレイヤの端末装置3へ送信し、プレイヤに仲間期間を報知する機能を有する。すなわち、仲間期間報知手段58は、仲間期間を含む画面データをプレイヤの端末装置3へ送信して、端末装置3の画面に仲間期間を表示させる制御を行う。
仲間期間を含む画面の例としては、図14に示すような仲間リスト画面が挙げられる。仲間リスト画面には、リストアップされた各仲間との間に設定されている仲間期間を表示するための仲間期間表示領域80が設けられている。
図14には、仲間期間表示領域80に、仲間期間の終了予定日(1/17まで等)が表示される画面例を示している。なお、仲間期間表示領域80に表示される仲間期間の情報は、仲間期間の終了予定日に限定されるものではなく、仲間期間の終了予定時間(年、月、日、時、分、秒等の任意の単位の時間情報)としてもよい。あるいは、例えば仲間期間の残日数(あと10日間等)や残時間(あと20時間10分15秒等)が仲間期間表示領域80に表示されるようにしてもよい。
次に、仲間成立ポイント付与手段59について説明する。仲間成立ポイント付与手段59は、2人のプレイヤ間で仲間関係が成立したときに、ボーナスとして当該2人のプレイヤに所定の仲間成立ポイントを付与する機能を有する。本実施の形態では、仲間成立ポイント付与手段59が、仲間関係が成立した2人のプレイヤに、3ポイントずつ仲間成立ポイントを付与するようになっている。例えば、仲間成立ポイントは、上述の行動力ポイントまたは運営コストの最大値を高めるポイントとして利用できるようになっている。仲間関係が成立した2人のプレイヤに仲間成立ポイントが付与されたことにより、ゲーム情報管理手段51の所有ポイント記憶手段51dが記憶している当該2人のポイントが更新される。
また、本実施の形態では、2人のプレイヤに設定されている仲間期間の終了により自動的に仲間関係が解除された場合には、仲間成立ポイントの増減を回避するため、仲間関係成立時に当該2人のプレイヤに対して付与された仲間成立ポイントと同じポイントがゲーム情報管理手段51により削減されるようになっている。
なお、プレイヤは、仲間期間の終了を待たずに仲間関係を自主的に解除することも可能である。プレイヤが仲間関係を自主的に解除した場合、解除した側のプレイヤにはペナルティとして仲間関係成立時に付与されたポイント(例えば3ポイント)より多いポイント(例えば5ポイント)が削減されるようにしてもよい。この場合、解除された側のプレイヤは、仲間関係成立時に付与されたポイントと同じポイントが削減されるようにしてもよい。もっとも、プレイヤが仲間関係を自主的に解除した場合であっても、仲間期間の終了により自動的に仲間関係が解除された場合と同様に、仲間関係成立時に付与されたポイントと同じポイントが削減されるようにしてもよい。
〔ゲームシステムの動作〕
上記の構成において、本発明の実施の形態に係るゲームシステムの動作例を、図19のフローチャートを参照しながら以下に説明する。図19は、プレイヤが端末装置3を操作してゲームサーバ1にアクセスしてゲームサービスを受けるときの、端末装置3およびゲームサーバ1の処理の流れを示すものである。
プレイヤがゲームサービスを受ける場合、先ず、端末装置3の操作入力部40を操作してウェブブラウザを起動する(S11)。その後、プレイヤは、ゲームサーバ1が管理するゲームサイトにアクセスする操作を行い、これにより、端末装置3からゲームサーバ1へアクセスリクエストが送信される(S12)。このとき、ゲームサーバ1は、端末装置3からのアクセスに対するログイン認証を行い(S21)、ゲームサービスの利用登録がなされているプレイヤからのアクセスであることを確認する。その後、ゲームサーバ1は、HTML等で記述されたメイン画面データを端末装置3に送信する(S22)。なお、メイン画面とは別のトップ画面がある場合は、まずトップ画面を送信してもよい。そして、メイン画面データを受信した端末装置3では、ウェブブラウザが当該データを解釈し、メイン画面を表示部35に表示させる(S13)。
図13に例示するように、メイン画面には、プレイヤのチーム名70、プレイヤが所有する選手カードの中からリーダーとして選択された選手カード71の画像、プレイヤのゲーム情報72(プレイヤのレベル、行動力ポイント、運営コスト、強化ポイント、交流ポイント、所有する選手カードの数、仲間人数など)が表示される。また、スカウト、オーダー、強化、抽選、試合の各モードを選択するためのボタン群73なども表示される。さらに、このメイン画面には、端末装置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にアクセスしたときに画面で確認することができる。
〔ゲーム管理装置の動作〕
次に、本発明の実施の形態に係るゲーム管理装置のより詳細な動作例を、図20ないし図23のフローチャートを参照しながら説明する。図20は、ある1人のプレイヤを対象としたゲームサーバ1の処理の流れを示すものであり、ゲームサーバ1が管理している各々のプレイヤに対して同様の処理が行われる。
図20に示すように、ゲームサーバ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の処理が繰り返されることで、ゲームが進行していく。
次に、図21ないし図23を参照して、ゲームサーバ1における仲間期間設定および仲間解除処理について説明する。図21ないし図23のフローチャートは、仲間関係が成立したある2人のプレイヤを対象としたゲームサーバ1の処理の流れを示すものであり、ゲームサーバ1が管理している全ての仲間同士のペアに対して同様の処理が行われることになる。
図21に示すように、第1のプレイヤから仲間申請を受けた第2のプレイヤがそれを承認することによって、2人のプレイヤ間で仲間関係が成立した場合(S51でYES)、仲間期間設定手段56が、第1のプレイヤのレベルと第2のプレイヤのレベルとの関係を含む所定条件に基づいて仲間期間を決定する(S52)。
このS52の仲間期間決定処理の一例を、図22に示す。図22中において、仲間申請をした第1のプレイヤのレベルをL1、それを承認した第2のプレイヤのレベルをL2として表している。仲間期間設定手段56は、L1<L2のとき(S61でYES)、仲間期間を5日とする(S62)。また、仲間期間設定手段56は、L1>L2のとき(S61でNOおよびS63でYES)、仲間期間を10日とする(S64)。また、仲間期間設定手段56は、L1=L2のとき(S61でNOおよびS63でNO)、仲間期間を7日とする(S65)。
図21のS52の仲間期間決定処理の他の例を、図23に示す。仲間期間設定手段56は、仲間申請をした第1のプレイヤのレベルL1と、それを承認した第2のプレイヤのレベルL2との差であるレベル差Dを算出する(S71)。そして、仲間期間設定手段56は、L1<L2のとき(S72でYES)、レベル差Dが大きいほど仲間期間を短くする(S73)。例えば、図18に例示するテーブルを参照し、レベル差Dに応じた仲間期間(L1<L2の場合)を取得する。また、仲間期間設定手段56は、L1>L2のとき(S72でNOおよびS74でYES)、レベル差Dが大きいほど仲間期間を長くする(S75)。例えば、図18に例示するテーブルを参照し、レベル差Dに応じた仲間期間(L1>L2の場合)を取得する。また、仲間期間設定手段56は、L1=L2のとき(S72でNOおよびS74でNO)、仲間期間を7日とする(S76)。
図21に戻って説明を続けると、仲間期間設定手段56は、上記のように仲間関係成立時に決定した仲間期間を、第1のプレイヤおよび第2のプレイヤに対して設定する(S53)。例えば、仲間期間設定手段56は、図11に示すように、仲間関係が成立している2人のプレイヤを関係付けた仲間情報と対応付けて、仲間期間を記憶する。
その後、仲間関係が成立している2人のプレイヤに設定された仲間期間が終了した場合(S54でYES)、仲間関係解除手段57は、当該2人のプレイヤの仲間関係を自動的に解除する(S55)。例えば、仲間関係解除手段57は、データベースサーバ2に登録されている2人の仲間情報に解除フラグを付加することにより、仲間関係の解除処理を実行する。
その後、ゲームサーバ1は、仲間関係が解除された2人のプレイヤの端末装置3に対して、仲間関係が解除された旨を報知するための情報(解除の旨を含む画面データ等)を送信し、当該2人のプレイヤに仲間関係が解除されたことを報知する(S56)。報知の例としては、ゲーム画面の中に仲間関係が解除された旨を表示することの他に、音声による報知や画面表示と音声とを併用した報知も考えられる。音声による報知は、ゲームサーバ1からプレイヤの端末装置3へ送信する画面データ(HTMLデータ等)に音声データを含ませることにより実現できる。なお、ゲームサーバ1が、仲間関係が解除されたことを報知するためには、プレイヤの端末装置3がゲームサーバ1にアクセスしている必要がある。よって、ゲームサーバ1は、S55の仲間関係の解除処理を実行した後、仲間関係が解除された各プレイヤの端末装置3がゲームサーバ1に最初にアクセスしたときに、S56の報知処理を実行することになる。
次に、仲間期間設定手段56が、仲間関係が成立した2人のプレイヤ間のレベル差に応じて仲間期間を設定する構成において、仲間期間中にレベル差が変動した場合に、変動後のレベル差に応じた仲間期間に再設定する構成について説明する。ここでは、図18に示すテーブルに基づいて、仲間期間設定手段56がプレイヤ間のレベル差に応じた仲間期間を設定する場合を例に挙げて説明する。
図24に示すように、ゲームサーバ1は、レベル差記憶手段60を備えている。このレベル差記憶手段60は、仲間期間設定時(再設定時を含む)における、仲間申請した第1のプレイヤのレベルL1とそれを承認した第2のプレイヤのレベルL2との差であるレベル差を、データベースサーバ2(記憶装置)に記憶する機能を有する。例えば、図25Aに示すように、レベル差記憶手段60は、両プレイヤの仲間情報を一意に示す仲間情報IDと対応付けて、仲間期間設定時のプレイヤ間のレベル差を記憶するようになっている。この例では、レベル差をL1−L2として算出し、L1>L2のときのレベル差はプラスの値、L1<L2のときのレベル差はマイナスの値として管理できるようにしている。このレベル差記憶手段60は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。
そして、仲間期間設定手段56は、仲間期間中のプレイヤ間のレベル差が、レベル差記憶手段60に記憶されている仲間期間設定時におけるレベル差から変動した場合に、変動後のレベル差に応じて仲間期間を再設定する機能を有する。この仲間期間の再設定処理について、図26のフローチャートを参照しながら以下に説明する。なお、既出のフローチャートにおいて示したステップと同様のステップについては同一のステップ番号を付し、詳細な説明を省略する(以降のフローチャートにおいても同様である)。
仲間期間設定手段56が仲間関係成立時に2人のプレイヤに対して仲間期間を設定した場合(S101でYES)、レベル差記憶手段60が仲間期間設定時におけるプレイヤ間のレベル差を記憶する(S102)。
その後、仲間期間設定手段56は、仲間期間中に(S103でNO)、少なくとも一方のプレイヤのレベルが変化することによりプレイヤ間のレベル差の変動を検出した場合(S104でYES)、変動後のレベル差に応じて仲間期間の再設定の必要性を判断する(S105)。すなわち、図18に示すテーブルに基づいて取得した変動後のレベル差に応じた仲間期間が、仲間期間設定時における仲間期間から変化しているか否かを判断する。具体例を挙げると、仲間成立時において、仲間申請したプレイヤのレベルL1が30であり、それを承認したプレイヤのレベルL2が57であったとする。よって、図25Aの仲間情報ID=“20”に示すように、プレイヤ間のレベル差−27(=30−57)に応じた仲間期間として6日が設定されたとする。その後、仲間期間中に、承認した側のプレイヤのレベルL2が1つ向上して58になり、プレイヤ間のレベル差が−28になっても、図18のテーブルに基づけば、L1<L2の場合、レベル差が10〜29の範囲では仲間期間は6日のままであることから、仲間期間の再設定の必要性はないことになる。例えば、仲間期間中にレベル差が−30になった場合、図18のテーブルに基づけば、変動後のレベル差に応じた仲間期間は5日になり、仲間期間を再設定する必要性が生じる。
仲間期間の再設定が必要である場合(S105でYES)、仲間期間設定手段56は、変動後のレベル差に応じた仲間期間を再設定する(S106)。例えば、図25Aに示す仲間情報ID=“20”の仲間期間および仲間期間終了予定時間を、図25Bに示す情報に更新する。すなわち、仲間期間設定手段56は、データベースサーバ2に記憶している仲間期間を、6日から5日に短縮し、それに伴って仲間期間終了予定時間も1日早くする(11/1/10から11/1/9へ更新する)。
上記では、再設定された仲間期間が元の期間よりも短くなる例を示したが、当然、再設定された仲間期間が元の期間よりも長くなる場合もある。仲間期間の再設定が実行されたときは、S102に戻って、レベル差記憶手段60が再設定時におけるプレイヤ間のレベル差を記憶(更新)する。
なお、仲間期間が終了した場合は(S103でYES)、仲間関係解除手段57により仲間関係が自動的に解除され(S55)、仲間関係が解除されたことが2人のプレイヤの端末装置3に報知される(S56)。
このように、プレイヤ間のレベル差に応じて適切な仲間期間を設定した後、その仲間期間中にプレイヤ間のレベル差が変動した場合、変動後のレベル差に応じた仲間期間に再設定することにより、仲間期間設定後のプレイヤ間のレベル差変動に追従した適切な仲間期間の調整を実現できる。
以上のように、本実施の形態では、2人のプレイヤ間での仲間関係の成立時に仲間期間を設定し、仲間期間の終了により、原則的に、当該2人のプレイヤの仲間関係を自動的に解除するようになっている。これにより、例えば、下位レベルのプレイヤからの仲間申請を承認して仲間になっても、仲間になった時点で仲間期間が設定されるので、プレイヤは、心理的にも行い難い仲間解除の操作をすることなく、仲間期間の終了により仲間関係の解除が可能となる。そして、プレイヤは、仲間関係の成立から仲間期間の終了までの間に、相手との交流の程度等から判断して仲間関係を継続すべきかどうかを判断することができる。そして、仲間関係を継続したいと思うような相手であれば、例えば、仲間期間終了後に改めて仲間申請を行う等の所定の操作をして仲間関係を継続すればよい。
すなわち、仲間関係成立時に設定される仲間期間をお試し期間として捉えて、例えば自分より下位レベルのプレイヤから仲間申請を受けたような場合でも、これを積極的に承諾して試しに仲間になり、仲間期間終了までに自分が望むような交流等ができる相手かどうかを検討することも可能となる。
また、各プレイヤが他のプレイヤと仲間関係を構築することができる仲間数に上限が設定されているゲームにおいて、プレイヤの仲間数が上限に達していた場合でも、仲間期間終了に伴う仲間関係の自動解除により、上限までに余裕ができる。すなわち、仲間数が一旦上限まで達したプレイヤであっても、従来のように実質的に仲間が固定された状態に陥ることはなく、他のプレイヤと新たな仲間関係を構築するための機会が与えられる。
そして、プレイヤは、仲間期間中に交流が持てなかった下位レベルのプレイヤとは、自動解除された仲間関係を終え、再度、仲間申請や承認をしたりすることはないと考えられる。その一方、プレイヤが望むような相手(上位レベルのプレイヤや楽しく交流が持てるようなプレイヤ)とは、仲間関係を継続するために、再度、仲間申請や承認等の操作をすることが考えられる。よって、本実施の形態の構成により、仲間関係成立による仲間期間設定と、仲間期間終了による仲間関係の自動解除と、を繰り返しながら、プレイヤの好むような仲間グループの構成に収束されていく環境が整えられる。したがって、プレイヤが、あまり交流のない下位レベルの仲間プレイヤを何人も抱え、自分好みの仲間のグループ構成になっていない状態で実質的に仲間が固定されてしまうことへの不満を解消できる。
特に、仲間数に上限が設定されているゲームの場合、従来では、比較的レベルの高いプレイヤが、あまり交流のない下位レベルの仲間を何人も抱えた状態で仲間数が上限まで達し、仲間が固定されてしまうことが多かった。これに対し、本ゲームサーバ1を適用した場合、仲間数に上限が設定されているゲームであっても、他のプレイヤと新たな仲間関係を構築し易すい環境がプレイヤに提供されるので、継続的に新たな仲間との交流を楽しめるようになる。よって、長期間にわたりゲームを継続しても、ゲームに対するマンネリ感が発生しにくい。
ところで、上述のように、仲間期間の終了により仲間関係が解除されても、プレイヤが仲間関係を継続したい相手については、仲間関係を継続するための所定の操作をすれば、仲間関係を継続することができる。仲間関係解除後の操作としては、過去の仲間に対する再度の仲間申請(これを「仲間復活申請」と呼称する)がある。以下に、この仲間復活申請を容易に行うことができる構成について説明する。
図27に示すように、本実施の形態のゲームサーバ1(ゲーム管理装置)は、図4または図24に示した各手段に加えて、仲間履歴送信手段101および仲間復活申請手段102をさらに備えている。これらの手段101および102は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。
図27に示すゲームサーバ1の仲間情報記憶手段54aは、仲間関係成立中の2人のプレイヤを関係付けた仲間情報を記憶するとともに、当該2人の仲間関係が解除された後も、当該2人のプレイヤを関係付けた過去の仲間情報を保持する。例えば、図28に示すように、仲間情報記憶手段54aは、仲間関係が解除された2人の仲間情報に、仲間解除フラグを立てて、過去の仲間情報として保持するようになっている。図28の例では、仲間解除フラグとして“1”が設定されている仲間情報が過去の仲間情報であり、仲間解除フラグが“0”の仲間情報が現在成立中の仲間情報である。
仲間履歴送信手段101は、プレイヤが操作する端末装置3からの要求に応じて、仲間情報記憶手段54aに記憶されている当該プレイヤの過去の仲間情報を読み出し、当該プレイヤと過去に仲間関係にあった過去の仲間プレイヤを表示させるための情報を当該端末装置3へ送信する機能を有する。
例えば、プレイヤが端末装置3を操作してメイン画面中の「過去の仲間リスト」ボタンを選択すれば、端末装置3から過去の仲間リスト要求がゲームサーバ1へ送信される。仲間履歴送信手段101は、プレイヤの端末装置3からこの要求を受信して、当該プレイヤの過去の仲間リストを表示させる情報(過去の仲間リストの画面データ)を端末装置3へ送信する。仲間履歴送信手段101が送信した情報を受信した端末装置3には、例えば図29に示すような過去の仲間リスト画面が表示される。この過去の仲間リスト画面には、プレイヤと過去に仲間関係にあった仲間プレイヤの情報がリストアップされて表示される。なお、画面に表示しきれない過去の仲間プレイヤの情報については、画面をスクロールするまたはリストの2ページ目以降をゲームサーバ1にリクエストして別画面として表示することができる。
この過去の仲間リスト画面内には、リストアップされた過去の仲間プレイヤ毎の情報表示領域が設けられており、各情報表示領域には、過去の仲間プレイヤの現在のゲーム情報201(プレイヤ名、チーム名、プレイヤのレベル、仲間の人数、所属リーグのレベル等)、当該プレイヤの分身的なキャラクタであるアバター202、当該プレイヤが所有するリーダーの選手カード203などとともに、復活申請ボタン204というオブジェクトも表示される。そして、プレイヤが仲間関係を復活させたい過去の仲間プレイヤの復活申請ボタン204を選択する操作を行うことにより、当該操作の情報が端末装置3からゲームサーバ1へと送信される。この操作の情報をプレイヤの端末装置3から受信した仲間復活申請手段102は、当該プレイヤから選択された過去の仲間プレイヤへの仲間関係復活の申請処理を実行するようになっている。
図31には、仲間復活申請を管理するための記憶情報の一例を示している。仲間関係復活の申請処理を実行する仲間復活申請手段102は、図31に例示するように、仲間情報を管理するための仲間情報IDと対応づけて、復活申請をしたプレイヤのプレイヤIDをデータベースサーバ2に登録する。図31における仲間情報ID=“1”の例では、プレイヤID=“000001”のプレイヤAが復活申請した例を示している。そして、仲間復活申請手段102は、申請相手の過去の仲間プレイヤBの端末装置3に対して、プレイヤAから復活申請があったことを表示させるための情報を送信する。なお、この送信は、プレイヤAが復活申請をした後、過去の仲間プレイヤBの端末装置3がゲームサーバ1に最初にアクセスしたときに行われる。
仲間復活申請手段102が送信した情報を受信した過去の仲間プレイヤBの端末装置3では、例えば、図30に示すような承認・拒否選択画面が表示される。この画面には、仲間復活申請をしたプレイヤAの現在のゲーム情報211(プレイヤ名、チーム名、プレイヤのレベル、仲間の人数、所属リーグのレベル等)、当該プレイヤのアバター212、当該プレイヤが所有するリーダーの選手カード213などとともに、承認ボタン214、拒否ボタン215というオブジェクトも表示される。ここで、拒否ボタン215を選択することにより、仲間関係の復活を拒否することもできる。一方、プレイヤBがプレイヤAとの仲間関係の復活を承認する場合、承認ボタン214を選択する操作を行うことにより、当該操作の情報がプレイヤBの端末装置3からゲームサーバ1へと送信される。この操作の情報を受信したゲームサーバ1の仲間管理手段54は、プレイヤBからの承認を受け付け、仲間関係復活処理を実行するようになっている。
仲間関係復活処理を実行する仲間管理手段54は、例えば図31に示すように、仲間情報を管理するための仲間情報IDと対応づけて記憶されている仲間解除フラグを“0”に設定する(図31中の仲間情報ID=“22”を参照)。また、このとき、復活承認したプレイヤのプレイヤIDおよび仲間関係の復活時間(復活日等)の情報を併せてデータベースサーバ2に記憶していてもよい。
上記のようにして仲間関係の復活により、再度、仲間関係が成立した場合、改めて仲間期間設定手段56により仲間期間が設定されることになる。すなわち、仲間期間設定手段56は、仲間復活申請をしたプレイヤ(第1のプレイヤ)および当該仲間復活申請を承認したプレイヤ(第2のプレイヤ)の2人のプレイヤ間での仲間関係の成立時に、第1のプレイヤのゲームレベルと第2のプレイヤのゲームレベルとの関係を含む所定条件に基づいて仲間期間を決定し、当該2人のプレイヤに対して仲間期間を設定するのである。
2人のプレイヤ間で上記のようにして仲間関係が復活した場合、初めて仲間関係が成立した場合よりも、当該2人のプレイヤは仲間関係の継続を望んでいる可能性が高い。そこで、仲間期間設定手段56は、申請した第1のプレイヤとそれを承認した第2のプレイヤとのレベル関係の条件が同じであれば、復活により仲間関係が成立した場合の仲間期間を、初めて仲間関係が成立した場合の仲間期間よりも長くすることが望ましい。例えば、2人のプレイヤのレベル関係に基づいて、初めて仲間関係が成立した場合の仲間期間が5日間に設定されるのであれば、同じレベル関係の条件で復活により仲間関係が成立した場合には、仲間期間が前記の2倍の10日間に設定されようにする。
また、仲間期間設定手段56は、申請した第1のプレイヤとそれを承認した第2のプレイヤとのレベル関係の条件が同じであれば、仲間関係復活の回数が多い程、仲間期間をより長く設定することが望ましい。
また、仲間関係の復活を何度も繰り返しているプレイヤ同士は、仲間関係が自動的に解除されることを望んでいない可能性が極めて高いと考えられる。そこで、仲間期間設定手段56は、所定回数以上(例えば3回以上)、仲間関係の復活が実行された2人のプレイヤについては、仲間期間を設定しない(または、仲間期間を無制限とする)ことが望ましい。
上記のように、仲間期間の終了後において仲間関係の復帰申請を行う場合の他に、仲間期間中に仲間関係の継続申請を行うことによって、仲間関係再構築の予約を可能とし、仲間期間の終了と同時に仲間期間が再度設定されるようにすることも可能である。以下に、この仲間継続申請を容易に行うことができる構成について説明する。
図32に示すように、本実施の形態のゲームサーバ1(ゲーム管理装置)は、図4に示した各手段51〜59に加えて、仲間継続申請手段110をさらに備えている。この手段110は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。
例えば、プレイヤが端末装置3を操作してメイン画面中の「仲間リスト」ボタンを選択すれば、ゲームサーバ1からは、図33に示すような仲間リスト画面のデータが送られてくる。この仲間リスト画面には、リストアップされた仲間プレイヤ毎の情報表示領域が設けられており、仲間期間表示領域80、仲間プレイヤのゲーム情報81、アバター82、選手カード83などとともに、継続申請ボタン220というオブジェクトも表示される。そして、プレイヤが、仲間関係を継続させたい仲間プレイヤに対応した継続申請ボタン220を選択する操作を行うことにより、当該操作の情報が端末装置3からゲームサーバ1へと送信される。この操作の情報をプレイヤの端末装置3から受信した仲間継続申請手段110は、当該プレイヤから選択された仲間プレイヤへの仲間関係継続の申請処理を実行するようになっている。
図34には、仲間継続申請を管理するための記憶情報の一例を示している。仲間関係継続の申請処理を実行する仲間継続申請手段110は、図34に例示するように、仲間情報を一意に識別する仲間情報IDと対応づけて、継続申請をしたプレイヤのプレイヤIDをデータベースサーバ2に登録する。図34における仲間情報ID=“1”の例では、プレイヤID=“000001”のプレイヤAが継続申請した例を示している。そして、仲間継続申請手段110は、申請相手の仲間プレイヤBの端末装置3に対して、プレイヤAから継続申請があったことを表示させるための情報を送信する。なお、この送信は、プレイヤAが継続申請をした後、仲間プレイヤBの端末装置3がゲームサーバ1に最初にアクセスしたときに行われる。
仲間継続申請手段110が送信した情報を受信した仲間プレイヤBの端末装置3では、例えば図30と同様の承認・拒否選択画面が表示される。ここで、プレイヤBがプレイヤAとの仲間関係の継続を承認する操作を行うことにより、当該操作の情報がプレイヤBの端末装置3からゲームサーバ1へと送信される。この操作の情報を受信したゲームサーバ1の仲間管理手段54は、プレイヤBからの承認を受け付け、仲間関係継続処理を実行するようになっている。
仲間関係継続処理を実行する仲間管理手段54は、例えば図34に示すように、仲間情報を管理するための仲間情報IDと対応づけて記憶されている継続フラグを“1”に設定する(図34中の仲間情報ID=“22”を参照)。また、このとき、継続承認したプレイヤのプレイヤIDの情報を併せてデータベースサーバ2に記憶していてもよい。
上記のようにして仲間関係の継続が成立した場合、図33に例示するように、仲間リスト画面には、継続申請ボタン220に代えて「継続成立」のステータス221が表示される。なお、継続申請後、相手から承認が得られていない場合には、「継続申請中」等のステータス221が表示され、相手から継続申請を受けているが未だ承認していない場合には、「継続承認未」等のステータス221が表示される。
また、仲間関係の継続が成立している場合、仲間管理手段54は、仲間期間の終了と同時に、仲間関係を復活させることになるとともに、仲間期間設定手段56が、仲間期間を再度設定することになる。すなわち、仲間期間設定手段56は、仲間継続申請をしたプレイヤ(第1のプレイヤ)および当該仲間継続申請を承認したプレイヤ(第2のプレイヤ)の2人のプレイヤ間での仲間関係の継続が成立した場合、第1のプレイヤのゲームレベルと第2のプレイヤのゲームレベルとの関係を含む所定条件に基づいて仲間期間を決定し、当該2人のプレイヤに対して仲間期間を設定するのである。
上記のようにして仲間期間中に仲間継続申請およびその承認の操作を行うことにより、ブランク期間を作ることなく、仲間関係を継続することができるようになる。
ところで、上記のような仲間復活申請や仲間継続申請のような操作をプレイヤが行うことなく、仲間関係を継続できるようにする構成について、以下に説明する。
〔ゲーム管理装置の他の構成例〕
ゲーム管理装置の他の構成例を、図35の機能ブロック図を参照しながら説明する。なお、既出の図面において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。本実施の形態のゲームサーバ1(ゲーム管理装置)は、図4に示した各手段51〜59に加えて、延長手段61をさらに備えている。この延長手段61は、仲間期間が設定されている2人のプレイヤの少なくとも一方から相手のプレイヤに対して、仲間期間が終了するまでに「所定回数」、「所定時間」、または「所定回数及び所定時間」の交流処理が実行された場合に、当該仲間期間を延長する機能を有する。この延長手段61は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。
仲間になったプレイヤ間で交流が持たれないということは、お互いに相手への関心が希薄であると考えられる。一方、仲間同士で交流を行っている場合には、プレイヤが仲間関係の維持を望んでいる可能性が高いと考えられる。そこで、仲間期間が終了するまでに条件を満たす交流があった場合に、仲間期間を自動的に延長し、仲間関係が継続されるようにするのである。
そして、延長手段61は、仲間期間が延長された2人のプレイヤの少なくとも一方から相手のプレイヤに対して、延長された仲間期間が終了するまでに「所定回数」、「所定時間」、または「所定回数及び所定時間」の交流処理が実行される毎に、仲間期間を延長することを繰り返すようになっている。これにより、条件を満たす交流を継続的に行っている仲間同士については、仲間期間の自動延長が繰り返されることにより仲間関係が継続して維持される。
また、2人のプレイヤの少なくとも一方から相手のプレイヤに対して「所定回数」、「所定時間」、または「所定回数及び所定時間」の交流があったことを、延長の条件とする。この条件を満たす形態には、いずれか一方から相手に対して「所定回数」、「所定時間」、または「所定回数及び所定時間」の交流があれば条件を満たすとする形態と、両者とも互いに相手に対して「所定回数」、「所定時間」、または「所定回数及び所定時間」の交流を行うことを条件とする形態とを含む。何れの形態を延長の条件として設定してもよい。特に、従来の課題であるところの、上位レベルのプレイヤにとって、仲間のプレイヤのレベルが自分よりも低い場合に、ゲームにおける協力対戦等について不公平感が生じていたということをより積極的に解消するために、少なくとも下位レベルのプレイヤが上位レベルのプレイヤに対して、「所定回数」、「所定時間」、または「所定回数及び所定時間」の交流を行うことを条件とすることが望ましい。
延長の対象となる交流については、前述の挨拶、メッセージの送信、プレゼント、協力対戦の助っ人依頼、合同練習、チャットなど、仲間のプレイヤ同士で行われる様々な交流を含めることができる。また、挨拶は延長の対象とはせず、メッセージの送信、プレゼント、協力対戦の助っ人依頼、合同練習、チャットのみを延長の対象とするといったように、ゲーム内に用意された複数の交流から一部の交流のみを延長の対象としてもよい。
延長の条件に関しては、「所定回数」、「所定時間」、または「所定回数及び所定時間」の何れの条件を満たす交流が行われたことを延長の条件としてもよい。挨拶、メッセージの送信、プレゼント、協力対戦の助っ人依頼、チャット等の全ての交流については、これらの交流が「所定回数」行われたことを延長の条件とすることができる。また、チャット等の、プレイヤ同士がリアルタイムで行うような交流については、「所定時間」の交流が行われたことを延長の条件としたり、「所定回数及び所定時間」の交流が行われたことを延長の条件としたりすることができる。また、挨拶等の交流およびチャット等の交流を含む様々な交流が可能なゲームについては、「所定回数」、「所定時間」、または「所定回数及び所定時間」の何れを延長の条件としてもよい。
ここで、仲間期間が終了するまでに「所定回数」の交流処理が実行されたことを延長の条件とする場合、「所定回数」として任意の回数を設定可能である。例えば、この所定回数を1回としてもよいし、2回以上の複数回としてもよい。また、仲間期間が終了するまでに「所定時間」の交流が行われたことを延長の条件とする場合、「所定時間」として例えば5分、10分、30分、または1時間等、任意の時間を設定可能である。また、仲間期間が終了するまでに「所定回数及び所定時間」の交流が行われたことを延長の条件とする場合、例えば3回および10分、2回および15分等、任意の回数および時間を設定可能である。
なお、本実施の形態においては、仲間期間が終了するまでに「所定回数」の交流が行われたことを延長の条件とする形態を例に挙げて、以下の説明を続ける。
相対的にゲームレベルが低いプレイヤから相手のプレイヤに対して交流処理が実行される場合の所定回数N1は、相対的にゲームレベルが高いプレイヤから相手のプレイヤに対して交流処理が実行される場合の所定回数N2よりも多い設定とすることが望ましい。一例としては、前記所定回数N1を3回とし、前記所定回数N2を2回とする。そして、いずれか一方から相手に対して前記所定回数の交流があれば延長条件を満たすものとする。または、両者とも互いに相手に対して前記所定回数の交流があれば延長条件を満たすものとする。
この構成によれば、レベルの異なる2人のプレイヤが仲間になった場合、下位レベルのプレイヤは上位レベルのプレイヤとの仲間関係を維持するためには、上位レベルのプレイヤよりも多くの回数の交流を必要とする。よって、上位レベルのプレイヤは、下位レベルのプレイヤとの仲間関係を終了させ易くなることから、自分好みの仲間グループをより構築し易くなる。
また、延長手段61が、プレイヤ間のレベル差に応じて延長の条件を満たすための交流の所定回数を設定する構成としてもよい。この場合、相対的にゲームレベルが低いプレイヤから相手のプレイヤに対して交流処理が実行される場合の所定回数N1を、両プレイヤ間のレベル差Dが大きいほど多い設定とすることが望ましい。一例としては、レベル差Dが29以下であれば所定回数N1を3回、レベル差Dが30〜69であれば所定回数N1を4回、レベル差Dが70〜99であれば所定回数N1を5回、レベル差Dが100以上であれば所定回数N1を6回とする。これにより、下位レベルのプレイヤは上位レベルのプレイヤとのレベル差が大きいほど、仲間関係を維持するために多くの回数の交流を必要とする。よって、上位レベルのプレイヤにとっては、レベルが離れた下位レベルのプレイヤほど仲間関係を終了させ易くなる。
逆に、相対的にゲームレベルが高いプレイヤから相手のプレイヤに対して交流処理が実行される場合の所定回数N2を、両プレイヤ間のレベル差が大きいほど少ない設定としてもよい。一例としては、レベル差Dが29以下であれば所定回数N2を3回、レベル差Dが30〜69であれば所定回数N2を2回、レベル差Dが70以上であれば所定回数N2を1回とする。これにより、上位レベルのプレイヤから下位レベルのプレイヤへ交流を行なうのであれば、レベル差が大きいほど少ない回数の交流で仲間関係を容易に維持できるようになる。
上記のように、延長手段61がプレイヤ間のレベル差に応じて延長の条件を満たすための交流の所定回数を設定する構成において、延長手段61がプレイヤ間のレベル差の変動を検出したとき、変動後のレベル差に応じた所定回数に再設定するようにしてもよい。これにより、プレイヤ間のレベル差変動に追従して、延長の条件を満たすための交流の所定回数を適切に調整することができる。
ここで、延長手段61が延長する期間の長さについては、一定の期間とすることができる。延長期間の長さを一定期間とする場合、例えば、1週間、10日間、2週間等、任意の期間を設定可能である。なお、延長の期間の長さは一定期間に限定されるものではない。例えば、延長が行われる毎にランダムに延長の期間を決定してもよい。また、交流回数によって延長の期間を変動させる(交流回数が多いほど延長の期間を長く設定する)構成であってもよい。あるいは、仲間期間設定手段56がプレイヤ間のレベル差に基づいて決定した仲間期間(仲間期間記憶手段56aが記憶している仲間期間)と同じ期間を、延長手段61が延長の期間として設定してもよい。
あるいは、延長手段61が延長処理を実行するときのプレイヤ間のレベル差に基づいて、延長の期間を設定する構成にすることもできる。例えば、図18に例示したプレイヤ間のレベル差と仲間期間との関係を表すテーブルを、プレイヤ間のレベル差と延長の期間との関係を表すテーブルとして援用(または共用)し、延長処理実行時のプレイヤ間のレベル差に応じた延長の期間を、当該テーブルに基づいて取得するようにする。もちろん、プレイヤ間のレベル差と延長の期間との関係を表す専用のテーブルを別途用意して、ゲームサーバ1の記憶手段(RAM13または補助記憶装置14等)に記憶しておいてもよい。この構成の場合、延長処理が実行される毎に、その都度、延長処理実行時のプレイヤ間のレベル差に基づいた適切な延長の期間を設定することができる。
また、延長手段61が延長処理実行時のプレイヤ間のレベル差に基づいて、延長の期間を設定する構成において、延長手段61がプレイヤ間のレベル差の変動を検出したとき、変動後のレベル差に応じた延長の期間に再設定するようにしてもよい。これにより、プレイヤ間のレベル差変動に追従して、延長の期間を適切に調整することができる。
延長手段61による延長処理の実行は、データベースサーバ2に記憶されている仲間期間の情報を、延長後の情報に更新する等により行うことができる。例えば、延長手段61は、図36に示すように、仲間期間記憶手段56aが記憶仲間情報IDと対応づけて記憶している仲間期間終了予定時間を、延長後の日付に更新することにより、延長処理を実行する。このとき、仲間情報IDと対応づけて、延長処理実行時の時間情報として仲間期間を延長した日等を併せて記憶する。延長処理実行時の時間情報としては、年、月、日、時、分、秒等の時間情報を記憶するが、ここで記憶する時間の単位は任意に設定できる。また、延長された仲間期間の情報管理のために、仲間情報IDと対応づけて、延長フラグを設定するようにしてもよい。
延長手段61による処理形態の1つとしては、仲間期間の途中で延長条件を満たす毎に、仲間期間の延長処理を実行する形態がある。この形態の延長処理について、図37を参照して、以下に説明する。なお、図37およびそれ以降のフローチャートは、仲間関係にある2人のプレイヤを対象としたゲームサーバ1の処理の流れを示すものであり、ゲームサーバ1が管理している全ての仲間同士のペアに対して同様の処理が行われることになる。
図37に示すように、延長手段61は、2人のプレイヤに設定された仲間期間が終了する前に(S81でNO)、交流に関する延長条件が達成されたか否かを判定する(S82)。例えば、この判定は、図36に示す仲間期間の情報(仲間期間終了予定時間等)、および図17に示すプレイヤの交流履歴の情報に基づいて行うことができる。すなわち、データベースサーバ2には、各プレイヤの交流履歴が記憶されているので、仲間期間が設定されてから仲間期間が終了するまでに(または、仲間期間が延長されてから延長された仲間期間が終了するまでに)、延長条件として定められた所定回数の交流をプレイヤが行った状態を検出可能である。
交流に関する延長条件が達成された場合(S82でYES)、延長手段61は、仲間期間の延長処理を実行する(S83)。例えば、図36に示す仲間期間終了予定時間を、延長後の日付に更新する。このとき、延長処理実行時の時間情報を記憶(または更新)する。
ここで、具体的な延長例を挙げる。1月1日に設定された仲間期間が例えば7日間(1月7日まで)であり、3日目の1月3日に交流の延長条件が達成された場合、1月3日の時点で例えば7日間の延長が発生し、仲間期間の終了日は1月7日(現終了日)から7日後の1月14日になる。よって、1月3日の時点での仲間期間の残期間(残日数)は11日間になる。例えば、その後、1月6日に交流の延長条件が再度達成された場合、1月6日の時点で7日間の追加延長が発生し、仲間期間の終了日は1月14日(現終了日)から7日後の1月21日になる。よって、1月6日の時点での仲間期間の残期間は17日間になる。
この延長例の場合、交流に関する延長条件が連続して早期に達成されると、仲間期間の残期間は増加する傾向にある。例えば、短期間に多数の交流を行って仲間期間の残期間が急激に増加した場合を考えると、その後交流が長期間途絶えた場合でも、仲間関係が長期間維持されることになる。そこで、仲間期間の残期間に上限を設けてもよい。例えば、仲間期間の残期間の上限を30日に設定すれば、30日以上交流に関する延長条件が満たされなければ、仲間期間は終了してしまう。よって、仲間関係を維持するためには、最長30日の期間以内に交流に関する延長条件を満たすことが必要となり、長期間交流が途絶えているのに仲間関係が維持されることを回避できる。
そこで、S83の後、延長手段61は、仲間期間の残期間が上限を超えている場合(S84でYES)、仲間期間の残期間を上限に制限する(S85)。すなわち、図36に示す仲間期間終了予定時間を、仲間期間の残期間の上限に合致する日付に更新する。
延長後の仲間期間の残期間が上限を超えていない場合(S84でNO)、または仲間期間の残期間を上限に制限した後(S85)、S81に戻り、以降、仲間期間が終了するまでS81〜S85の処理が繰り返される。
ここで、他の具体的な延長例を挙げる。1月1日に設定された仲間期間が例えば7日間(1月7日まで)であり、3日目の1月3日に交流の延長条件が達成された場合、1月3日の時点で例えば7日間の延長が発生するのであるが、仲間期間の終了日は1月3日(延長発生日)から7日後の1月10日になる。よって、1月3日の時点での仲間期間の残期間は7日になる。例えば、その後、1月6日に交流の延長条件が再度達成された場合、1月6日の時点で7日間の再延長が発生し、仲間期間の終了日は1月6日(延長発生日)から7日後の1月13日になる。よって、1月6日の時点での仲間期間の残期間は7日になる。この延長例では、仲間期間の残期間は最大でも延長期間(この例では7日間)となるので、仲間期間の残期間に上限を設ける必要はない。仲間期間の残期間に上限を設けない場合は、前記S84およびS85の処理を省くことができる。
また、交流に関する延長条件を満たすことなく仲間期間が終了した場合(S81でYES)、仲間関係解除手段57により仲間関係が自動的に解除され(S55)、仲間関係が解除されたことが2人のプレイヤの端末装置3に報知される(S56)。このS55およびS56の詳細は、図21において説明したとおりである。
このように、仲間関係にある2人のプレイヤに対して設定された仲間期間は、交流に関する所定の延長条件を満たす毎に延長される。そして、前述の仲間期間報知手段58は、仲間期間(延長された場合、延長後の仲間期間)を表示させるための情報を、プレイヤの端末装置3へ送信し、プレイヤに仲間期間を報知する機能を有する。よって、各プレイヤは、図14に例示する仲間リスト画面で、自分の各仲間プレイヤとの間に設定されている仲間期間(延長後の仲間期間)がいつまでなのかを確認できるようになっている。そして、プレイヤは、仲間関係を終了させたくない仲間プレイヤについては、仲間リストで確認した仲間期間が終了するまでに延長条件を満たす交流を行うことにより、仲間関係を継続できる。このように、プレイヤの端末装置3に表示される仲間リスト画面に仲間期間(延長後の仲間期間)の情報を含めることにより、プレイヤ自身による仲間管理を容易にすることができる。
延長手段61による処理形態としては、仲間期間の終了時刻に延長条件を満たしているか否かを判定し、延長条件を満たしている場合に仲間期間の延長処理を実行する形態もある。換言すれば、設定されている仲間期間の全期間の経過を待って延長の要否を判定し、延長処理を実行する形態である。この形態の延長処理について、図38を参照して、以下に説明する。
延長手段61は、2人のプレイヤに設定された仲間期間の終了時刻になったときに(S91でYES)、交流に関する延長条件が達成されたか否かを判定する(S92)。このS92の処理は、前述のS82と同様の処理である。
交流に関する延長条件を満たしている場合(S92でYES)、延長手段61は、仲間期間の延長処理を実行する(S93)。一方、交流に関する延長条件を満たしていない場合(S93でYES)、仲間期間の終了に伴い、仲間関係解除手段57により仲間関係が自動的に解除され(S55)、仲間関係が解除されたことが2人のプレイヤの端末装置3に報知される(S56)。
上記のように、本実施の形態の構成では、プレイヤが仲間復活申請や仲間継続申請のような特別な操作を行うことなく、ゲーム内で仲間同士が延長条件を満たす交流を楽しむだけで自動的に仲間期間が延長され、仲間関係を継続できるようになっている。特に、ソーシャルゲーム等のプレイヤの操作の容易化・簡素化が強く求められるゲームサービスを提供する場合には、特別な操作を要することなく仲間関係を継続できる本構成が好適である。
一方、延長条件を満たすような交流が行われなかった場合、お互いの関心が希薄であり、交流を楽しめるような仲間同士ではなかったということが考えられる。この場合、仲間期間が延長されることなく仲間期間の終了により仲間関係が自動的に解除されるので、やはり仲間解除のための特別な操作は不要である。
また、本実施の形態では、仲間期間の延長の概念を、仲間との交流を楽しむというソーシャル要素を取り入れたゲームに導入したことにより、現実世界の仲間関係(対人関係)に近い関係を、ゲーム内で仮想的に実現できる。すなわち、現実世界では、仲間(知り合い)になってから継続的に交流が保たれていればその仲間関係は維持されるが、一旦仲間になっても、その後、あまり交流が持たれなかった場合には、両者が親密な関係を構築できないまま仲間関係は自然消滅する。そして、本実施の形態では、交流が持たれたときの仲間関係の維持を仲間期間の延長およびその繰り返しにより実現し、交流が持たれなかった場合の仲間関係の自然消滅を、仲間期間の延長がなされないまま仲間期間が終了することによる仲間関係の自動解消により実現している。
一方、従来では、仲間関係を解除する操作が必要である等の理由により、全く交流がない又は殆ど交流がない仲間であっても、仲間として維持しているケースが殆どであり、現実世界の仲間関係とゲーム内の仲間関係とは大きく乖離しているのが現状である。
本実施の形態の構成を適用したゲームでは、プレイヤが仲間と交流を持ちながら普通にゲームをプレイしてさえいれば、実際に交流を楽しんでいる仲間で構成された仲間グループが自然に構築されることになる。
ところで、延長手段61による仲間期間の延長が何度も繰り返されているプレイヤ同士は、仲間関係が自動的に解除されることを望んでいない可能性が高いと考えられる。そこで、延長手段61は、仲間期間が終了するまでに所定回数(または所定回数以上)の交流があった場合に仲間期間を延長する延長処理に加え、仲間期間の延長処理自体が所定回数以上(例えば3回以上)実行された2人のプレイヤに対しては、仲間期間を無制限にする(換言すれば、仲間期間を無期限に延長する)ことが望ましい。但し、下位のプレイヤが上位のプレイヤに対して一方的に交流を行った結果として仲間期間の延長処理が所定回数以上実行された場合までを含めて、仲間期間を無制限にすると、上位プレイヤから不満が出る可能性もある。そこで、この場合、2人のプレイヤの両方とも互いに相手に対して所定回数(または所定回数以上)の交流を行うことを延長の条件とすることが望ましい。両方とも互いに相手に対して所定回数以上の交流があった場合に仲間期間の延長処理が実行され、この延長処理が所定回数以上繰り返されるということは、お互いに継続的に仲間関係を維持したいと考えていることが想定されるためである。
なお、2人のプレイヤの仲間期間を無制限にするということは、仲間関係が自動的に解除されることがない状態にするという観点から、2人のプレイヤに仲間期間を設けないことと実質的に同じである。よって、2人のプレイヤの仲間期間を無制限にすることには、2人のプレイヤの仲間期間の設定を解除することも含まれる。
次に、仲間関係が成立している2人に親密度というパラメータを設定し、親密度の値に応じて延長時の仲間期間を調整する構成について説明する。親密度とは、仲間関係が成立している2人のプレイヤの親密さを示すものであり、2人の友好度合い、友情の深さ、絆の深さ等として表現することもできる。
図35に示すように、ゲームサーバ1は、親密度付与手段62および補正手段63を備えている。これらの手段62および63は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。
親密度付与手段62は、交流手段55により仲間関係が成立している2人のプレイヤ間で交流処理が実行された場合に、当該2人のプレイヤに対して親密度を付与する機能を有する。本実施の形態の親密度付与手段62は、2人のプレイヤ間で交流処理が実行される毎に、所定値(例えば1ポイント)の親密度を付与するようになっている。なお、交流の内容により付与する親密度の値を変えてもよい。例えば、挨拶は1ポイント、メッセージ送信は2ポイント、プレゼントおよび対戦協力は3ポイント等としてもよい。また、本実施の形態では、2人の親密度の値に応じて、例えば5段階のランクが設けられている。例えば、親密度が0〜24ポイントで知り合いランク、25〜49ポイントで友人ランク、50〜74ポイントで親友ランク、75〜99ポイントで相棒ランク、100ポイント以上で盟友ランクとなる。
親密度付与手段62は、親密度記憶手段62aを備えている。この親密度記憶手段62aは、例えば図39に示すように、仲間情報を一意に識別する仲間情報IDと対応づけて、2人のプレイヤに付与された親密度の値データベースサーバ2に記憶している。また、親密度のランクも併せて記憶していてもよい。
仲間同士の2人のプレイヤが交流を重ねた結果として、2人の親密度の値が高くなることから、親密度の値が高いほど、お互いに仲間関係の維持を望んでいると考えられる。そこで、親密度の値が高いほど、延長処理における仲間期間を長く設定することにより、親密度に応じた適切な仲間期間を設定することができる。
そこで、補正手段63は、2人のプレイヤの親密度の値が高いほど、延長手段61により延長される仲間期間(延長期間)が長くなるように補正する機能を有する。一例を挙げると、2人のプレイヤの親密度の値が知り合いランクのときに延長される仲間期間の長さをn(日)とした場合、友人ランクではn×1.5、親友ランクではn×2.0、相棒ランクではn×2.5、盟友ランクではn×3.0の期間補正を行う。
また、補正手段63は、2人のプレイヤの親密度の値が閾値以上の場合(例えば、100ポイント以上の盟友ランクに達している場合)、仲間期間を無期限に設定(すなわち仲間期間をなくす)ようにしてもよい。これは、2人のプレイヤの親密度の値が閾値以上まで高まった場合には、もはや何れのプレイヤも仲間関係の解除を望んでいない可能性が極めて高いと考えられるからである。
この親密度の値に応じて延長時の仲間期間を補正する処理について、図40を参照して以下に説明する。
2人のプレイヤに設定された仲間期間が終了する前に(S81でNO)、交流に関する延長条件が達成された場合(S82でYES)、2人のプレイヤの親密度の値が閾値以上か否かが判定される(S111)。ここで、親密度の値が閾値以上の場合(S111でYES)、補正手段63は、仲間期間を無期限に設定する(S112)。また、親密度の値が閾値未満の場合(S111でNO)、補正手段63は、親密度の値に応じて延長手段61により延長される仲間期間(延長期間)を補正する(S113)。すなわち、補正手段63は、親密度の値が高いほど、延長期間が長くなるように補正する。S113の後、延長手段61は、補正手段63により補正された延長期間により仲間期間を延長する(S114)。また、S114の後は前記S81に戻り、仲間期間が終了するか又は親密度が閾値以上になるまでループ処理(S81、S82、S111〜S114)を繰り返す。
なお、仲間期間が終了した場合は(S81でYES)、仲間関係解除手段57により仲間関係が自動的に解除され(S55)、仲間関係が解除されたことが2人のプレイヤの端末装置3に報知される(S56)。
〔他の実施の形態〕
上述の実施の形態では、各プレイヤが他のプレイヤと仲間関係を構築することができる仲間数に上限が設定されているゲームを例に挙げて説明したが、本発明の実施の形態に係るゲーム管理装置、ゲーム管理方法及びプログラムは、仲間数に上限のないゲームにも適用することができる。
また、上述の実施の形態では、ゲーム実行プログラムがゲームサーバ1側に実装されており、各プレイヤの端末装置3における入力操作に応じて、ゲームサーバ1がゲーム進行のための演算処理やデータ処理を実行し、その実行結果を反映させた画面データを端末装置3へ送信することによって、ゲームが進行するゲームシステムへの適用例について説明した。これはいわゆるクライアントサーバ型のゲームシステムであるが、これに限定されるものではない。例えば、ゲームサーバ1が、プレイヤの仲間情報を含むゲーム情報を管理し、ゲーム内での仲間管理等のゲームサービスをプレイヤに提供する一方、ゲームを進行させるゲーム実行処理については、基本的にはプレイヤの端末装置側にて行われるゲームシステムにも本発明の実施の形態に係るゲーム管理装置、ゲーム管理方法及びプログラムを適用できる。
すなわち、ゲーム実行プログラムの一部または全部をプレイヤの端末装置側にダウンロードまたはインストールし、端末装置においてもゲーム実行処理が行われるようなゲームシステムにも適用できる。例えば、プレイヤの端末装置が、インターネット通信、無線LAN通信、所定の周波数帯(例えば2.4GHzの周波数帯)を用いた近距離無線通信、または有線LAN通信などにより他のプレイヤの端末装置とピア・ツー・ピア接続し、ピア・ツー・ピア型のゲームを実行することも可能である。
よって、プレイヤの端末装置としては、ゲームサーバ(ゲーム管理装置)に接続して仲間管理等のゲームサービスの提供を受けることができる様々なものが適用でき、前述の携帯電話端末、スマートフォン、PHS端末、携帯情報端末(PDA)、パーソナルコンピュータ、タブレット型コンピュータ以外にも、ネットワーク接続機能を有している家庭用ビデオゲーム装置(家庭用ビデオゲーム機を家庭用テレビジョンに接続することによって構成されるゲーム装置)や、携帯型のゲーム専用装置なども適用可能である。
また、本実施の形態に係るコンピュータ読み取り可能なプログラムは、ハードディスク、光ディスク(CD−ROM、DVD−ROM等)、フレキシブルディスク、半導体メモリ等のコンピュータ読み取り可能な各種記録媒体に記録され、当該記録媒体から読み出されてゲームサーバ1のCPU11により実行される。また、プログラムをゲームサーバ1に提供する手段は、前述した記録媒体に限定されるものではなく、インターネット等の通信ネットワークを介して行うこともできる。