以下、本発明の一実施の形態に係るゲーム管理装置、ゲーム管理方法及びプログラムについて、図面を参照しながら説明する。
〔ゲームシステムの概要〕
本発明の一実施の形態に係るゲーム管理装置が組み込まれたゲームシステムの構成例を、図1に示している。同図に示すように、このゲームシステムは、インターネットなどのネットワーク4上に設置されたゲームサーバ1と、当該ゲームサーバ1と通信可能に接続されたデータベースサーバ2と、ネットワーク4を介してゲームサーバ1と通信可能に接続できる各プレイヤの端末装置3とによって構成される。
本実施の形態のネットワーク4は、インターネットに限定されるものではなく、ゲームサーバ1と各プレイヤの端末装置3との間を通信可能に相互に接続できるものであれば、例えば、専用回線、公衆回線(電話回線、移動体通信回線等)、有線LAN(Local Area Network)、無線LAN等であってもよく、或いはインターネットとこれらを組み合わせたものであってもよい。
このゲームシステムの例において、本発明の一実施の形態に係るゲーム管理装置は、ゲームサーバ1およびデータベースサーバ2から構成される。ゲームサーバ1は、ゲームサービスを受ける各プレイヤの端末装置3からのネットワーク4を介したアクセスを受け付けて、各プレイヤのゲーム情報をデータベースサーバ2(記憶装置)に蓄積して管理し、各プレイヤにネットワーク4を介したゲームサービスを提供する。
本実施の形態では、ゲームサーバ1によるゲームサービスの提供の一形態として、各プレイヤの端末装置3に搭載されたウェブブラウザによってゲームがプレイできる、いわゆるブラウザゲームを提供する例について説明する。このブラウザゲームを提供するサービス形態では、プレイヤの端末装置3にゲーム専用のソフトウェアをダウンロード又はインストールする必要がなく、端末装置3をネットワーク4に接続できる環境であれば、プレイヤはどこでも気軽にゲームサーバ1から提供されるゲームサービスを楽しむことができる。
このゲームシステムでは、ブラウザゲーム用のプログラム(アプリケーションソフトウェア)がゲームサーバ1に実装されており、ゲームサーバ1が、各プレイヤの端末装置3における入力操作に応じてゲーム進行のための演算処理やデータ処理を実行する。そして、ゲームサーバ1は、演算処理等の実行結果に基づいてデータベースサーバ2内の各プレイヤのゲーム情報を更新するとともに、当該実行結果をプレイヤの端末装置3の画面に表示させるためのウェブページ情報(ゲーム画面データ)を各プレイヤの端末装置3に送信する。
各プレイヤの端末装置3には、ユーザーエージェントとしてウェブサイト閲覧機能を有するウェブブラウザが搭載されており、ゲームサーバ1から送信されたウェブページ情報を端末装置3の画面に表示することができるようになっている。この端末装置3としては、例えば、携帯電話端末、PHS(Personal Handy-phone System)端末、携帯情報端末(PDA:Personal Digital Assistant)、携帯電話と携帯情報端末とを融合させた携帯端末であるスマートフォン、パーソナルコンピュータまたはタブレット型コンピュータなど、ネットワーク4経由でゲームサーバ1に接続してゲームサービスの提供を受けることができる様々な端末が適用できる。
また、本実施の形態で提供されるゲームは、プレイヤが、ゲームサービスを受けている他のプレイヤとコミュニケーションをとりながらプレイすることができる、いわゆるソーシャルゲームの要素を有する。例えば、本実施の形態のゲームサーバ1およびデータベースサーバ2をソーシャルネットワーキングサービス(SNS)のシステムに組み込むことによって、SNSのサービスの一つとしてソーシャルゲームサービスを提供するゲームシステムとすることができる。このようにSNSのプラットフォーム上で動作するゲームシステムによりゲームサービスをプレイヤに提供することもできるが、ゲームサーバ1およびデータベースサーバ2をSNSのシステムに組み込まずに、独立したゲームシステムとして構築してもよい。
このゲームシステムにおいて、各プレイヤは、ゲームサービスを受けている一人又は複数の他のプレイヤと「仲間」という特別な関係を構築できる。そして、仲間を作ったプレイヤは、後述する様々なメリットを享受できる。あるプレイヤが他のプレイヤと仲間になるための一形態としては、両プレイヤの何れか一方が、他方のプレイヤに対してゲームサーバ1を介して仲間申請を行い、当該仲間申請を受けたプレイヤがゲームサーバ1を介して仲間になることを承認するという、両プレイヤ間においてなされる仲間申請とその承認の操作が挙げられる。そして、ゲームサーバ1は、各プレイヤを中心とする前記「仲間」というグループに所属する仲間プレイヤの情報を、データベースサーバ2に記憶して、プレイヤ毎の仲間管理を行っている。この仲間申請、その承認およびゲームサーバ1による仲間管理の詳細については後述する。
そして、本実施の形態のゲームサーバ1は、各プレイヤを中心とするグループに所属する仲間プレイヤのゲームサーバ1へのアクセス頻度に基づいて、グループの評価値をプレイヤ毎に算出するようになっている。ここで、グループの評価値とは、各プレイヤを中心とするグループに所属する仲間プレイヤのアクセス頻度の平均値や合計値、グループ内の最大値や最小値等を示すものである。また、各プレイヤのゲーム情報を管理しているゲームサーバ1は、各プレイヤのグループの評価値に基づいて、ゲーム上有利又は不利になるように各プレイヤのゲーム情報を変更するという特徴的な構成を有する。すなわち、ゲームサーバ1は、各プレイヤのグループの評価値と所定の基準値(第1基準値)とを比較し、評価値が所定の基準値より大きいプレイヤに対してゲーム上有利になるように当該プレイヤのゲーム情報を変更してメリットを発生させる。または、ゲームサーバ1は、各プレイヤのグループの評価値と所定の基準値(第2基準値)とを比較し、評価値が所定の基準値より小さいプレイヤに対してゲーム上不利になるように当該プレイヤのゲーム情報を変更してデメリットを発生させる。なお、グループの評価値の算出方法、基準値の決定方法、メリットやデメリットの具体例などについては後述する。
この本実施の形態の特徴的な構成によって、各プレイヤは、特典を得るために仲間全体のゲームへのアクセス(ゲームサーバ1へのアクセス)の頻度を高めようとして、仲間相互間のコミュニケーションをとる動機付けを与えられることになるため、ゲームコミュニティ全体の活性化を図ることができるようになるのである。ゲームコミュニティ全体の活性化は、興趣性の高いソーシャルゲーム等を実現する上で重要な要素であり、各プレイヤはゲーム内での仲間同士のつながりや交流を強め、延いてはゲームに対する関心と興味をより強める結果となる。よって、本ゲームシステムは、プレイヤにとって飽きのこない継続性を有するゲームサービスの提供を実現できるのである。
以下に、上記のようにゲームコミュニティ全体の活性化を図ることができる、本実施の形態に係るゲーム管理装置の構成の詳細を説明する。以下の説明では、グループの評価値として、各プレイヤを中心とするグループに所属する仲間プレイヤのアクセス頻度の平均値(以下、「仲間アクセス平均」と称する)を適用した例を中心に説明する。
〔ゲーム管理装置の構成〕
上述のように本実施の形態では、ゲーム管理装置は、ゲームサーバ1およびデータベースサーバ2から構成される。図2にゲームサーバ1のハード構成の一例を示している。同図に示すように、ゲームサーバ1は、主に、CPU(Central Processing Unit)11と、主記憶装置としてのROM(Read Only Memory)12及びRAM(Random Access Memory)13と、補助記憶装置14と、通信制御部15と、入出力制御部16とを備えており、これらはアドレスバス、データバス及びコントロールバス等を含むバスライン17を介して相互に接続されている。なお、バスライン17と各構成要素との間には必要に応じてインタフェース回路が介在しているが、ここではインタフェース回路の図示を省略している。
CPU11は、システムソフトウェアやゲームプログラム等のアプリケーションソフトウェアの命令を解釈して実行し、ゲームサーバ1全体の制御を行う。ROM12は、ゲーム管理装置1の基本的な動作制御に必要なプログラム等を記憶している。RAM13は、各種プログラム及びデータを記憶し、CPU11に対する作業領域を確保する。
補助記憶装置14は、ゲームプログラム等のアプリケーションソフトウェアや各種データ等を格納する記憶装置である。補助記憶装置14としては、例えばハードディスクドライブなどを用いることができる。ゲームサーバ1(コンピュータ)をゲーム管理装置として動作させるための本実施の形態のプログラムも、この補助記憶装置14に記憶されており、当該プログラムはゲームサーバ1の起動時に補助記憶装置14からバスライン17を介してRAM13へとロードされ、当該CPU11によって実行される。
通信制御部15は、ネットワーク4と接続される通信インタフェース15aを備え、ネットワーク4を介した各プレイヤの端末装置3との間の通信を制御する。また、通信制御部15は、ネットワーク4に接続されている図示しないサーバとの通信も制御するようになっている。例えば、ゲームサーバ1をSNSに組み込んだシステム構成とした場合、ゲームサーバ1の通信制御部15は、ネットワーク4を介した図示しない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、報知手段60およびメッセージ伝達手段61を備えている。これらの各手段51〜61は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。
ゲーム情報管理手段51は、各プレイヤのゲーム情報をデータベースサーバ2に蓄積して管理する。ゲーム情報管理手段51で管理されるゲーム情報の項目は、本ゲームサーバ1がプレイヤに提供するゲームサービスの内容によって異なる。
本ゲームサーバ1によって提供されるゲームの例としては、野球、サッカー、ゴルフなどの各種スポーツを題材としたスポーツゲーム、戦闘を題材とした戦闘ゲーム、音楽シミュレーションゲーム、その他種々のロールプレイングゲーム・育成ゲーム・シミュレーションゲームといったように、ゲーム形式・ジャンルを問わず様々なゲームを挙げることができる。その一例として、本実施の形態では、ゲームサーバ1がゲームサービスとして野球ゲームを提供する場合について、以下に説明する。
本実施の形態では、プレイヤがゲーム内において選手キャラクタを所有し、当該選手キャラクタを用いてゲーム内で他のプレイヤと試合(対戦)を行うことができる野球ゲームを例に挙げる。プレイヤが所有する選手キャラクタは、当該選手キャラクタの形態を端末装置3の画面上で視認可能としたカード形式とすることができる。すなわち、選手キャラクタは、デジタル選手カードとしてゲームサーバ1で管理されるとともに、プレイヤの端末装置3の画面に表示される。図11(a)には、プレイヤの端末装置3の画面に表示される選手カード71を例示しており、選手キャラクタの形態およびカードのレア度(希少価値の高さを☆の多さで示したもの)などを表記したデジタル選手カードとして画面上に表示される。プレイヤは、ゲームを進行させながら選手カードを集め、自分だけのオリジナルチームを結成し、他のプレイヤと対戦してランキングを競うことができる。また、プレイヤは、集めた選手カード同士を合成することによって選手カード(選手キャラクタ)の能力を向上させる(すなわち、選手を育成する)ことができ、より強いチーム作りを目指してゲームを楽しむことができるようになっている。
このような野球ゲームにおいて、各プレイヤのゲーム情報を管理するゲーム情報管理手段51は、図5に示すように、プレイヤ情報記憶部51a、レベル情報記憶部51b、所有選手カード記憶部51c、所有ポイント記憶部51d、所有コイン記憶部51e、所有アイテム記憶部51f、試合結果記憶部51g、ランキング記憶部51h、特典情報記憶部51iおよびデメリット情報記憶部51jなどを備えている。図6には、ゲーム情報管理手段51の各記憶部51a〜51jがデータベースサーバ2に記憶して管理する、各プレイヤのゲーム情報の一例(この例ではプレイヤID=“000001”の1人分のゲーム情報)を示している。
プレイヤ情報記憶部51aは、各プレイヤを一意に識別するプレイヤIDと対応付けて、ログインID、パスワード、プレイヤ名(ゲーム内で使用するニックネーム等)、チーム名等の各プレイヤに関するプレイヤ情報を、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。ここで、ログインIDおよびパスワードは、各プレイヤが端末装置3を操作してゲームサーバ1にアクセスしたときのログイン認証に用いられる。プレイヤ名およびチーム名は、プレイヤがゲームサービスを受けるための会員登録をした際や、ゲームを初めて実行した際に、プレイヤが自ら設定した任意の情報である。プレイヤ名およびチーム名は、必要に応じてゲーム画面に表示される。
レベル情報記憶部51bは、プレイヤIDと対応付けて、プレイヤのレベルや所属リーグのレベル等のレベル情報を、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。本野球ゲームでは、例えば、プレイヤがゲームを進行させることにより経験値が蓄積され、当該経験値が一定量に達することによりプレイヤのレベルがアップするようになっている。また、本野球ゲームでは、例えば、複数の異なるレベルのリーグが存在し、各プレイヤのチームが何れかのリーグに所属して、同リーグの他のプレイヤのチームと自動で試合(リーグ戦)を行うようになっている。また、このリーグ戦の成績に応じて、異なるリーグに所属するプレイヤのチーム同士の入替戦が自動で実行され、プレイヤのチームが所属するリーグレベルが変化するようになっている。レベル情報記憶部51bは、このプレイヤのレベルや所属リーグのレベルを、プレイヤIDと対応付けて記憶する。
所有選手カード記憶部51cは、プレイヤIDと対応付けて、ゲーム内でプレイヤが獲得して所有している選手カードの情報を、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。この選手カードの情報の例としては、選手カードを一意に識別するための識別情報(選手カードID)、選手の能力の高さを示す能力値およびレギュラー選手フラグなどがある。
図6では、3つの能力項目(能力1〜3)に対して選手の能力値を設定できる例を示している。能力項目の例としては、選手カードが野手の場合は、能力1〜3を「打撃」、「走力」、「守備」等とすることができ、また選手カードが投手の場合は、能力1〜3を「球威」、「制球」、「変化」等とすることができる。能力項目はこの例に限らず、増減可能である。レギュラー選手フラグとは、プレイヤが所有している選手カードのうち、他のプレイヤのチームとの試合に出場するレギュラー選手(チームオーダーに組み込まれた選手)であるか、それともレギュラー選手以外の控え選手であるかを判別するフラグであり、これが「1」のときレギュラー選手の選手カードとして登録されていることを示す。プレイヤは、端末装置3を操作することにより、所有している選手カードからレギュラー選手を選択したり、チームオーダーを設定したりすることができるようになっている。
また、データベースサーバ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により一意に特定される試合は、プレイヤが対戦相手を指定して行う個別対戦の試合、およびゲームサーバ1により自動で行われるリーグ戦の試合を含む。
また、データベースサーバ2は、試合IDと対応付けられて、試合日時(現実世界の試合開始または終了の時間)、勝利したチームのプレイヤID、敗北したチームのプレイヤID、対戦スコア、勝利投手キャラクタ、敗戦投手キャラクタ、本塁打を打った選手キャラクタ、試合寸評情報などの試合結果に関する情報が記憶された試合データベースを備えている。そして、ゲーム情報管理手段51は、試合結果記憶部51gが記憶している試合IDに基づいて、当該試合IDに対応する試合結果に関する情報を、試合データベースから取得できるようになっている。
ランキング記憶部51hは、プレイヤIDと対応付けて、前記リーグ戦や入れ替え戦におけるプレイヤのチームの勝利数および敗戦数、ならびに勝利数・敗戦数に基づく所属リーグ内の順位などのランキング情報を、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。例えば、リーグ戦が現実世界における月曜日〜金曜日の各日の所定時間に所定の試合数(例えば各日12試合)自動的に行われ、また、入れ替え戦が現実世界における土曜日および日曜日の所定時間に所定の試合数(例えば各日12試合)自動的に行われるものとする。この場合、図6に示すように、ランキング記憶部51hは、現実世界の月曜日〜日曜日の各日についてのランキング情報を記憶し、毎週、ランキング情報を最新の情報に更新する。
特典情報記憶部51iは、プレイヤIDと対応付けて、プレイヤに付与された特典に関する情報を、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。本実施の形態における特典は、仲間アクセス平均が基準値(第1基準値)を超えているプレイヤに対して付与される。ここで特典を付与するとは、特典の付与前と比較してゲーム上有利な状態(メリット発生状態)にすることであり、図6では、3回分の対戦が有利になるという特典がプレイヤに付与された例を示している。この特典の詳細は後述する。
デメリット情報記憶部51jは、プレイヤIDと対応付けて、プレイヤに与えられたデメリットに関する情報を、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。本実施の形態におけるデメリットは、仲間アクセス平均が基準値(第2基準値)より低いプレイヤに対して与えられる。ここでデメリットを与えるとは、デメリットが与えられる前と比較してゲーム上不利な状態にすることである。このデメリットの詳細も後述する。
次に、図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は、各プレイヤを中心とする仲間(グループ)に所属する仲間プレイヤの情報を、データベースサーバ2(記憶装置)に記憶して、プレイヤ毎の仲間管理を行う機能を有する。この仲間管理手段53は、仲間情報記憶部53aを備えている。
図7(a)には、仲間情報記憶部53aがデータベースサーバ2に記憶して管理する、各プレイヤの仲間に関する情報の一例を示している。仲間情報記憶部53aは、プレイヤIDと対応付けて、仲間の制限数の情報、すでに仲間の関係になっている仲間プレイヤのプレイヤID、仲間申請中のプレイヤのプレイヤID、および仲間申請を受けているが未承認のプレイヤのプレイヤIDなどの仲間に関する情報を、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。図7(a)の例では、プレイヤID=“000001”
のプレイヤ1人分の仲間に関する情報を示しており、仲間制限数は20人、当該プレイヤの仲間プレイヤは10人、仲間申請中のプレイヤは1人、仲間申請を受けているが未承認のプレイヤは0人である。
本実施の形態の野球ゲームでは、仲間をつくることによって、仲間の関係になった両プレイヤにボーナスポイントが付与される(例えば、前記行動力ポイントや運営コストの最大値を所定ポイントだけ増加させることができる)。また、仲間のプレイヤと協力して試合をしたり、仲間同士で選手カードのプレゼントや応援を行ったりすることで、ゲームを有利に進めることができるゲーム仕様となっている。このようにゲーム内で仲間をつくることによるメリットをプレイヤに付与することにより、仲間を作ることを促進している。但し、各プレイヤには、ゲームの進行度合いに応じた仲間の制限数(仲間をつくることができる上限人数)が設定されており、仲間情報記憶部53aがプレイヤIDと対応付けて仲間の制限数を記憶している。例えば、仲間の制限数は、プレイヤのレベルが高くなるほど大きくなるように設定される。これにより、プレイヤは、より多くの仲間を作ってゲームを有利にするために、ゲームを継続的に進めてレベルアップを図ろうとする動機付けを与えられることになる。
本実施の形態において、二人のプレイヤが仲間になるには、両プレイヤの何れか一方が、他方のプレイヤに対してゲームサーバ1を介して仲間申請を行う。この仲間申請の操作例としては、先ず、仲間を作ろうとするプレイヤが、端末装置3の画面上に仲間候補の対象者をリストアップする操作を行う。このプレイヤによる操作に応じて、ゲームサーバ1が仲間候補の対象者をリストアップした画面データを送信することにより、例えば、図26の画面例に示すように、複数の仲間候補がリストアップされた画面がプレイヤの端末装置3に表示される。ここで、プレイヤは、画面上にリストアップされた対象者のプレイヤレベルや所属リーグレベル等を確認し、仲間にしたいプレイヤを選択して仲間申請の操作を行う。なお、図26の仲間候補リスト画面の詳細は後述する。
例えば、プレイヤID=“000001”のプレイヤAが、プレイヤID=“000002”のプレイヤBに対して仲間申請の操作を行った場合を考える。図7(a)に示すように、この操作に応じてゲームサーバ1の仲間情報記憶部53aは、仲間申請を行ったプレイヤAのゲーム情報として、当該プレイヤAのプレイヤID=“000001”と対応付けて、被申請者であるプレイヤBのプレイヤID=“000002”を、「申請中のプレイヤID」として記憶する。
さらに、図8(a)に示すように、仲間情報記憶部53aは、被申請者であるプレイヤBのゲーム情報として、当該プレイヤBのプレイヤID=“000002”と対応付けて、仲間申請を行ったプレイヤAのプレイヤID=“000001”を、「未承認のプレイヤID」として記憶する。そして、ゲームサーバ1は、その後、プレイヤBの端末装置3がゲームサーバ1にログインしたときに、プレイヤAから仲間申請があった旨を通知する。
そして、仲間申請を受けたプレイヤBは、ゲームサーバ1から受信したプレイヤAのプレイヤレベルや所属リーグレベル等の情報を、端末装置3の画面上で確認し、仲間として承認するか拒否するかを選択する操作を行う。ここで、プレイヤBが仲間として承認する操作を行った場合、この操作に応じてゲームサーバ1の仲間管理手段53は、プレイヤAとプレイヤBとの仲間関係を成立させ、両プレイヤA・Bを仲間登録する。すなわち、図7(b)に示すように、プレイヤAのゲーム情報として、当該プレイヤAのプレイヤID=“000001”と対応付けて、プレイヤBのプレイヤID=“000002”を、「仲間プレイヤID」として記憶し、「申請中のプレイヤID」からプレイヤBのプレイヤIDを削除する。
さらに、図8(b)に示すように、仲間情報記憶部53aは、プレイヤBのプレイヤID=“000002”と対応付けて、プレイヤAのプレイヤID=“000001”を、「仲間プレイヤID」として記憶し、「未承認のプレイヤID」からプレイヤAのプレイヤIDを削除する。そして、ゲームサーバ1は、その後、プレイヤAの端末装置3がゲームサーバ1にログインしたときに、プレイヤBから仲間の承認があった旨を通知する。
次に、認証手段54について説明する。認証手段54は、ゲームサービスを受けようとするプレイヤが端末装置3を操作してゲームサーバ1にアクセス(ログイン)しようとした際、当該プレイヤのゲーム参加資格の有無を判断してログイン認証を行う。この認証の例としては、プレイヤIDと対応付けられたログインIDおよびパスワードに基づく認証がある。例えば、プレイヤが初めてゲームサービスを利用するときに、会員情報としてログインID(任意の英数文字やメールアドレス等)およびパスワードをゲームサーバ1に登録する。そして、次回からのゲームサーバ1へのログイン時には、プレイヤが端末装置3を操作してログインIDおよびパスワードをゲームサーバ1へ送信する。このとき、ゲームサーバ1の認証手段54が、プレイヤの端末装置3から受信したログインIDおよびパスワードの組み合わせが登録済みであるか否かを判断し、ログイン認証を行う。
また、SNSのシステムに本ゲームシステムを組み込む場合、SNSの会員登録情報(ログインIDおよびパスワード)をそのまま本ゲームシステムのゲームサービスを受けるための利用登録情報としてもよい。例えば、プレイヤの端末装置3がSNSサーバにログインしている状態で、ゲームサーバ1が管理するゲームサイトに最初にアクセスした際、SNSサーバからゲームサーバ1へ自動的にプレイヤのログインIDおよびパスワードが転送され、これによってプレイヤが改めてログインIDおよびパスワードを登録することなくゲームサービスの利用登録ができるようにしてもよい。
また、プレイヤがゲームサーバ1にアクセスする度にログインIDおよびパスワードを入力する手間を省略できるように、端末装置3である携帯電話端末の個体識別番号(電話番号とは別の携帯電話端末を一意に識別するための情報)、または契約者固有ID(携帯電話端末の契約者を一意に識別するための情報であって、機種変更を行っても契約者が同一である限りは変更されないID)を利用した認証を行ってもよい。すなわち、プレイヤが携帯電話端末を操作して会員登録した際に、当該携帯電話端末から送信されてくるデータに含まれる個体識別番号または契約者固有IDをゲームサーバ1が取得し、ログインIDおよびパスワードとともに、当該個体識別番号または契約者固有IDもプレイヤIDと対応付けてデータベースサーバ2に記憶しておくのである。そして、認証手段54は、携帯電話端末からアクセス要求を受けた際には、個体識別番号または契約者固有IDが登録済みであるか否かを判断してログイン認証を行う。これにより、ゲームサーバ1へのアクセス時には、プレイヤはログインIDおよびパスワードの入力を省略してログインすることが可能となる。
また、プレイヤがゲームサーバ1にアクセスする度にログインIDおよびパスワードを入力する手間を省略できる別の方法としては、HTTP cookieの情報(以下、Cookieと称する)を利用する方法もある。すなわち、プレイヤが端末装置3を操作して会員登録した際に、ゲームサーバ1がログインIDおよびパスワードに対応した個体識別情報を発行してデータベースサーバ2へ登録するとともに、当該個体識別情報をCookieとして端末装置3へ送信する。このとき、端末装置3のブラウザは、受信したCookieを端末装置3内へ記憶する。次回からのゲームサーバ1へのアクセスの際には、端末装置3のブラウザがページ閲覧要求とともにCookieをゲームサーバ1へ送信するので、認証手段54は、携帯電話端末からアクセス要求を受けた際には、Cookieの個体識別番号が登録済みであるか否かを判断してログイン認証を行うことができる。
次に、アクセス管理手段55について説明する。アクセス管理手段55は、各プレイヤのゲームサーバ1へのアクセスの情報を、データベースサーバ2(記憶装置)に記憶してプレイヤ毎のアクセス頻度を管理する。このアクセス管理手段55は、アクセス情報記憶部55aを備えている。アクセス情報記憶部55aが記憶するアクセスの情報の例としては、各プレイヤのアクセス履歴、現実世界の1日のアクセス回数、現実世界の各日のアクセスの有無等の情報が挙げられる。
図9(a)には、アクセス情報記憶部55aがデータベースサーバ2に記憶して管理する、各プレイヤのアクセス情報の一例を示している。アクセス情報記憶部55aは、プレイヤIDと対応付けて、現実世界における今週の月曜日〜日曜日の各日についてのプレイヤのアクセス回数、および現実世界における1週前〜n週前の各週についての当該プレイヤのアクセス平均を、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。なお、アクセス情報記憶部55aが記憶するアクセス情報は、図9(a)の例に限定されるものではなく、例えば、直近の所定期間(例えば30日間)の各日についてのプレイヤのアクセス回数であってもよい。このアクセス情報記憶部55aが記憶するアクセス情報の詳細については、後述する。
本実施の形態のアクセス平均算出手段56は、プレイヤがゲームサーバ1にアクセスする頻度の目処として、各プレイヤのゲームサーバ1へのアクセス頻度の平均値である「アクセス平均」を算出する。ここで、アクセス平均の算出方法は無数に存在し、例えば、アクセス平均を算出する際の期間(アクセス平均算出期間)については任意に設定することができる。
ただし、このアクセス平均算出手段56が算出する各プレイヤのアクセス平均は、仲間アクセス平均算出手段57が仲間アクセス平均を算出する際の基となる値であり、延いては特典またはデメリットの発生に影響を与える値であるため、これを考慮してアクセス平均算出期間を決定することが望ましい。そこで、本実施の形態では、アクセス平均算出手段56が、直近の所定期間(以下、アクセス平均算出期間と称する)、例えば、直近の7日間における各プレイヤのアクセス平均を算出し、さらに仲間アクセス平均算出手段57が、各プレイヤを中心とした仲間というグループを対象とした仲間アクセス平均を算出する。
アクセス平均算出期間を設定する場合に考慮すべき点は幾つかある。先ず、その期間の長さであるが、プレイヤの入れ替わり(ゲームサービスを受けるのを止めるプレイヤおよび新規参入のプレイヤ)は、常時発生するので、アクセス平均算出期間を数か月単位の比較的長い期間とした場合、当該期間内で発生するプレイヤの入れ替わりは多くなり易い。アクセス平均算出期間の途中でゲームサービスを開始または中止したプレイヤは、アクセス平均を算出する期間的条件を満たさないため、その算出対象から除外することが望ましいことから、アクセス平均算出期間を1か月以内の期間、より好ましくは5日間〜10日間程度に限定することで、期間的条件を満たさない算出対象の除外を低減できる。特に、ゲームサービスを開始した新規参入のプレイヤに対して、数か月間という長いアクセス平均算出期間が経過するまでアクセス平均の算出対象にならない(すなわち特典付与に何ら寄与しない)状態をつくるのは決して望ましくない。そこで、アクセス平均算出期間を1か月以内の期間とすることが好ましく、5日間〜10日間程度に限定することがより好ましい。
また、アクセス平均算出期間(アクセス平均を算出する際の母数)を1か月以内の期間、より好ましくは5日間〜10日間程度に限定すれば、例えば当該期間を3ヶ月とした場合のように、平均値の変化が乏しくなってしまい冗長感が生じるという事態も回避できる。
また、アクセス平均算出期間を「直近」の期間(例えば直近7日間)とすることで、プレイヤの日々のゲームサーバ1へのアクセスがアクセス平均に反映されることとなる。ここで、「直近」とは、ゲームサーバ1が仲間アクセス平均に基づいてプレイヤのゲーム情報を変更するタイミング(特典発生またはデメリット発生のタイミング)に対して直近という意味である。例えば、アクセス平均算出期間を同じ7日間とした場合でも、前日までの「直近」の7日間(7日前から1日前までの7日間)ではなく、例えば13日前から7日前までの7日間とした場合、すでに1週間前にはアクセス平均算出期間が終了しており、当該期間終了後のゲームサーバ1へのアクセスは、アクセス平均には反映されない。これに対して、アクセス平均算出期間を「直近」の所定期間とすれば、特典発生またはデメリット発生の有無の判断がなされる直前までの日々のアクセスが、アクセス平均の算出結果に反映されるので、常時、アクセス平均を上げようとする動機付けを与えられることになる。
以下、本実施の形態では、アクセス平均算出期間を直近の7日間とした例について説明する。また、仲間アクセス平均と基準値との比較の結果としてメリット(特典)が発生したか、デメリットが発生したかについては、曜日で確定した方がプレイヤにとっては分かり易い。そこで、本実施の形態では、前週の月曜日〜日曜日までの直近7日間の仲間アクセス平均と基準値との比較結果を、翌月曜日にプレイヤに報知する例について説明する。
図9(a)に示すように、アクセス管理手段55のアクセス情報記憶部55aは、プレイヤIDと対応付けて、現実世界における今週の月曜日〜日曜日の各日についてのプレイヤのアクセス回数を、プレイヤID毎に記憶している。すなわち、図9(a)の例では、月曜日〜日曜日の直近の7日間については、プレイヤが1日にゲームサーバ1に何回アクセスしたのかという「回数/日」でもってアクセス頻度が記憶される。
ここで、アクセス回数とは、プレイヤの端末装置3がゲームサーバ1に接続されていない状態(セッションが確立されていない状態)からゲームサーバ1にアクセスしてログインした回数である。よって、原則的にはログイン後におけるゲームを進行させるためのゲームサーバ1へのアクセスは、アクセス回数のカウントには含めない。ログイン後、ゲームを一旦終了してログオフしてから時間をおいて、再度、ゲームサーバ1にアクセスしてログインした場合は、アクセス回数としてカウントされる。
なお、ログイン時間が日付変更時間である午前0時より前であり、ログアウトの時間が午前0時を過ぎている場合、すなわち日付を跨いでゲームをプレイしている場合、日付変更時間を過ぎた後のゲームサーバ1へのアクセスは、ログイン中のアクセスであってもログインした日とは別の日のアクセスとみなしてアクセス回数をカウントしてもよい。
また、ゲームサーバ1において、ゲーム管理上の日付変更時間を、午前0時とは異なる時間に設定してもよい。例えば、ゲーム管理上の1日を午前3時から開始し、翌日の午前3時になるまでとし、毎日、午前3時にゲーム管理上の日付が変更されるようにしてもよい。
次に、アクセス平均算出期間を直近の7日間とした場合における、アクセス平均算出手段56によるアクセス平均の具体的な算出例を例示する。アクセス平均の算出方法としては様々な方法が考えられるが、ここでは、代表的な算出方法として、算出例(1)〜(3)について説明する。
算出例(1)は、単純に7日間のアクセス回数の合計を7日で割って、1日当たりのアクセス回数(回数/日)をアクセス平均として算出する。例えば、図10(a)に示すように、プレイヤAが月曜日〜日曜日の各日に、0回、1回、4回、1回、3回、5回、0回のアクセスを行った場合、当該プレイヤAのアクセス平均は、
(0+1+4+1+3+5+0)/7=2(回/日)
として算出できる。
算出例(2)では、1日に少なくとも1回でもゲームサーバ1にアクセスすれば、その日のカウントを「1」とする一方、一度もアクセスしなかった日はカウントを「0」とする。すなわち、1日に最低1回でもアクセスがあれば、アクセスがあったことを評価してカウントを「1」とするのである。そして、7日間のカウントの合計を7日で割って、1日当たりのカウント(カウント/日)をアクセス平均として算出する。この場合、7日間すべてについて1日1回以上のアクセスがあれば、アクセス平均=1となる。また、上述した図10(a)に示すプレイヤAの例では、当該プレイヤAのアクセス平均は、
(0+1+1+1+1+1+0)/7=0.71(カウント/日)
として算出できる。
算出例(2)の場合、直近の7日間のアクセス頻度情報としては、各日のアクセスの有無が分かればよく、図9(a)の例のように各日のプレイヤのアクセス回数を記憶する必要はない。すなわち、図9(c)に例示するように、アクセス情報記憶部55aは、プレイヤIDと対応付けて、現実世界における今週の月曜日〜日曜日の各日についてのプレイヤのアクセスの有無(有=“1”、無=“0”の1ビット情報)を、プレイヤID毎に記憶してもよい。この場合、アクセスの有無は1ビット情報として記憶できるので、アクセスの回数を複数ビットの数値として記憶するよりも記憶容量の削減を図ることができる。
算出例(3)は、上記の算出例(2)の変形例であり、1日に1回だけゲームサーバ1にアクセスした日と、1日に複数回アクセスした日とで、アクセス平均算出時の重みを変えた加重平均をとる。例えば、1日に1回だけアクセスした場合のカウントを「1」とし、1日に複数回アクセスした場合のカウントは1よりも大きくなるように重みを付け、各プレイヤのアクセス平均を算出する。重み付けの一例を示すと、ある日のアクセス回数をaとした場合、加重平均の重みwを、
w={1+(a−1)×0.1} ・・・(1)
とし、アクセス回数が多いほど重みが大きくなるようにすることができる。この加重平均による算出方法は、1日に最低1回でもアクセスがあれば、アクセスがあったことを高く評価してカウントを「1」とするとともに、1日に複数回のアクセスがあった場合はアクセスの多さも追加的に評価してカウントを1以上とするものである。上式(1)の重み付けの方法によると、1日に2回以上アクセスした場合、アクセスが1回増える毎に0.1ずつカウントが増加することになる。上述した図10(a)に示すプレイヤAの例では、当該プレイヤAのアクセス平均(加重平均)は、
(0+1+1.3+1+1.2+1.4+0)/7=0.84(カウント/日)
として算出できる。
なお、アクセス平均の算出方法は、上記の算出例(1)〜(3)に限定されるものではなく、例えば加重平均算出時の重みのつけ方を変更してもよい。
ここで、図10(a)〜(c)に示すプレイヤA、B、Cのゲームサーバ1へのアクセス実績の例に基づいて、算出例(1)〜(3)を考察する。
図10(a)のプレイヤAは、7日のうち1回以上アクセスをした日は5日であり、日によってアクセス回数はバラバラである。図10(b)のプレイヤBは、アクセス回数の合計についてはプレイヤAと同じ14回であるが、7日のうち1回以上アクセスをした日は3日だけであり、金曜日〜日曜日に集中的にアクセスしている。図10(c)のプレイヤCは、アクセス回数の合計についてはプレイヤA・Bよりも少ないが、7日間にわたってコンスタントに毎日1回ずつアクセスしている。このように、三者三様のアクセス態様であり、算出例(1)〜(3)のいずれの算出方法を採用するかによって、アクセス平均の算出結果も大きく異なっている。
例えば、ゲームサーバ1へのアクセス回数の多さに評価の重点を置く場合は、算出例(1)のアクセス平均の算出方法が適している。算出例(1)の算出方法では、プレイヤCのアクセス平均は、プレイヤA・Bのアクセス平均より低い。
一方で、単なるアクセス回数の多さよりも、平均算出期間内のコンスタントなアクセスに評価の重点を置く場合は、算出例(2)または(3)のアクセス平均の算出方法が適している。算出例(2)または(3)の算出方法では、プレイヤCのアクセス平均は、プレイヤA・Bのアクセス平均より高くなる。例えば、基本のゲーム料金は無料であり、一部のアイテム等の使用についてのみ課金する、いわゆるアイテム課金制を採用するゲームサービスの場合、アクセスの多さも重要ではあるが、ゲームサービスの利用者に継続的にサービスを利用してもらうことがより求められることであるので、コンスタントなアクセスに評価の重点を置く算出例(2)または(3)の方が適していると言える。特に、算出例(3)は、コンスタントなアクセスに評価の重点を置きながら、アクセス回数の多さをも評価の対象にした加重平均を採用しており、最も適している。
アクセス平均算出手段56は、毎週月曜日になると、アクセス情報記憶部55aが記憶している直近の月曜日〜日曜日のアクセス回数(図9(a)参照)に基づいて、上述のごとく各プレイヤのアクセス平均を算出する。この各プレイヤのアクセス平均の算出結果については、図9(b)に示すように、アクセス情報記憶部55aがプレイヤIDと対応付けて、1週前のアクセス平均としてデータベースサーバ2に記憶する。さらに、同図に示すように、アクセス情報記憶部55aは、今週の月曜日〜日曜日のアクセス回数を新たに記録できるようにするため、月曜日〜日曜日のアクセス回数の情報をリセットする(0にする)。
また、本実施の形態では、アクセス平均算出手段56が過去に算出したアクセス平均のデータについては、n週前までのデータが、アクセス情報記憶部55aにより記憶されている。すなわち、各プレイヤの1週前〜n週前までのアクセス頻度の情報が、週毎のアクセス平均として保存されている。
次に、仲間アクセス平均算出手段57について説明する。この仲間アクセス平均算出手段57は、アクセス平均算出手段56が算出した各プレイヤのアクセス平均の値を使用して、各プレイヤを中心とする仲間(グループ)の「仲間アクセス平均」をプレイヤ毎に算出する。この仲間アクセス平均の算出において使用される各プレイヤのアクセス平均の値は、仲間アクセス平均に基づいてプレイヤのゲーム情報が変更される(すなわち特典またはデメリットが発生する)直前までの所定期間(本実施の形態では直近の7日間)のアクセス平均の値である。すなわち、仲間アクセス平均算出手段57は、プレイヤのゲーム情報が変更される直前までの直近の7日間を対象として、仲間アクセス平均を算出する。
なお、仲間アクセス平均を算出するときの対象期間は、仲間アクセス平均に基づいてプレイヤのゲーム情報が変更される直前の期間(例えば直近の7日間)に限定されるものではなく、ゲーム情報が変更される直前ではない数日前の期間であってもよいが、ゲーム情報が変更される直前までの所定期間とすることにより、メリット又はデメリット発生の有無の判断がなされる直前までの日々のアクセスが、仲間アクセス平均の算出結果に反映されるので望ましい。
ここで、各プレイヤを中心とする仲間(グループ)には、当該中心となるプレイヤが含まれていることから、仲間アクセス平均についても、当該中心となるプレイヤのアクセス平均を含めて算出される。
なお、仲間を一人も作っていないプレイヤに関しては、当該プレイヤを中心とする仲間というグループ自体が存在しないため、仲間アクセス平均は算出されず、よって仲間アクセス平均に基づくメリット(特典)またはデメリットの発生もない。
次に、全体アクセス平均算出手段58について説明する。この全体アクセス平均算出手段58は、アクセス平均算出手段56が算出した各プレイヤのアクセス平均の値を使用して、ゲームサーバ1が提供するゲームサービスを受けている全プレイヤにおけるアクセス頻度の平均値である「全体アクセス平均」を算出する。本実施の形態では、この全体アクセス平均を、各プレイヤの仲間アクセス平均と比較される基準値(第1基準値および第2基準値)として使用する例について説明する。
ゲーム情報変更手段59は、仲間アクセス平均算出手段57が算出した仲間アクセス平均が、全体アクセス平均算出手段58が算出した全体アクセス平均(第1基準値)を超えているプレイヤに対して、ゲーム上有利になるように当該プレイヤのゲーム情報を変更して特典を付与する機能を有する。また、ゲーム情報変更手段59は、仲間アクセス平均が第2基準値としての全体アクセス平均より低いプレイヤに対して、ゲーム上不利になるように当該プレイヤのゲーム情報を変更してデメリットを生じさせる機能も有する。
このゲーム情報変更手段59は、各プレイヤの仲間アクセス平均と全体アクセス平均とを比較する比較部59aと、比較部59aの比較結果に基づいて特典発生の有無を判定する特典発生判定部59bと、比較部59aの比較結果に基づいてデメリット発生の有無を判定するデメリット発生判定部59cとを備えている。そして、ゲーム情報変更手段59は、特典発生判定部59bまたはデメリット発生判定部59cが特典またはデメリットを発生させると判定したプレイヤのゲーム情報(ゲーム情報管理手段51がデータベースサーバ2に記憶して管理しているゲーム情報)を、特典またはデメリットの内容に応じて変更する。
ここで、仲間アクセス平均が全体アクセス平均を超えているプレイヤに対して付与される特典について説明する。特典は、当該特典が付与されなかった場合と比較してゲーム上有利になるものであればよく、ゲームの種類や内容に応じて様々な特典が考えられる。
本実施の形態の野球ゲームにおける特典の一例としては、他のプレイヤのチームと対戦する対戦モードにおいて、対戦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回分の対戦が有利になるという特典をプレイヤに付与する場合、ゲーム情報変更手段59は、ゲーム情報管理手段51の特典情報記憶部51iが記憶しているプレイヤの特典に関する情報を変更する。図6の下部には、プレイヤID=“000001”のプレイヤに特典が付与された結果、当該プレイヤの特典情報として「対戦が有利になる回数=3」が記憶された例を示している。
その他の特典の例としては、次のようなものがある。すなわち、ゲーム中に消費されて減った行動力ポイントなどのポイントは、例えば3分経過する毎に1ポイントずつ回復するようになっているが、このポイント回復時間を短縮する(例えば、2分経過する毎に1ポイントずつ回復するようにする)ことが考えられる。この特典が付与される場合、特典情報記憶部51iが記憶しているプレイヤの特典情報として、ポイント回復時間が短縮される有効期間の情報が記憶される。これにより、ゲームサーバ1のゲーム情報管理手段51が、特典が有効な期間(例えば、プレイヤが特典の通知を受けてから24時間以内)において、ポイント回復時間を通常時よりも短縮する処理を行うことになる。
また、前述の選手抽選獲得モードにおいて、レアカード(通常の選手カードよりも抽選確率が低く、希少価値が高い選手カード)が抽選される確率を所定回数(例えば1回)だけ上昇させるという特典も考えられる。この特典が付与される場合、特典情報記憶部51iが記憶しているプレイヤの特典情報として、抽選確率を上昇させる回数が記憶される。そして、ゲームサーバ1のゲーム進行手段52が、特典対象の抽選実行時に、レアカードの抽選確率を一時的に高める処理を行うことになる。
また、選手抽選獲得モードにおいて、通常は選手カードの抽選を実行するのにポイント(前記エールポイント等)を必要とするが、所定回数(例えば1回)だけ無料で(すなわちポイントの消費なしに)、選手カードの抽選を受けることができるという特典も考えられる。この特典が付与される場合、特典情報記憶部51iが記憶しているプレイヤの特典情報として、無料(無ポイント)で選手カードの抽選を受けることができる回数が記憶される。
また、ゲームサーバ1が乱数等により抽選で選んだ選手カードを、所定枚数(例えば1枚)だけプレイヤに付与するという特典も考えられる。ゲームサーバ1が選んだ選手カードを特典としてプレイヤに付与する場合、ゲーム情報管理手段51の所有選手カード記憶部51cが記憶している選手カードIDに、特典として付与される選手カードIDが追加される。
また、前述の行動力ポイント、運営コスト、強化ポイント、エールポイントなどのゲーム内で使用される各種ポイントを、所定ポイント分だけプレイヤに付与するという特典も考えられる。さらには、前述の回復アイテムやフェイクカードなどのゲーム内で使用される各種アイテムを、所定数だけプレイヤに付与するという特典も考えられる。ゲーム内で使用されるポイントまたはアイテムを特典として付与する場合、ゲーム情報変更手段59は、ゲーム情報管理手段51の所有ポイント記憶部51dまたは所有アイテム記憶部51fが記憶している、プレイヤの所有ポイントまたはアイテムの所有数を、所定数だけ増加させるようにゲーム情報を変更する。
ところで、あまりに特典を大きくしてしまうと、本来ゲームを実行することで実現される選手カードの能力値の向上(すなわち選手の育成)等とのバランスが崩れる可能性もあるため、当該特典は、あくまでサブ的(副次的)な位置づけとして、プレイヤにとってある程度のお得感を与えるレベルとすることが好ましい。
次に、仲間アクセス平均が全体アクセス平均より低いプレイヤに対して与えられるデメリットについて説明する。このデメリットは、当該デメリットが付与されなかった場合と比較してゲーム上不利になるものであればよく、ゲームの種類や内容に応じて様々なものが考えられる。
本実施の形態の野球ゲームにおけるデメリットの一例としては、他のプレイヤのチームと対戦する対戦モードにおいて、対戦n回分(例えば対戦1回分)だけ、プレイヤのチームの戦力が低下するという対戦上のデメリットを挙げることができる。チーム戦力低下の例としては、プレイヤの所有する控え選手のカードで、且つ、能力値が所定値以下の選手カードn枚(例えば1枚)が、自動的に当該プレイヤのレギュラー選手のカードn枚と入れ替わるようにする。または、対戦モードにおいて試合に出場するレギュラー選手の選手カードの一部または全部の能力値を、所定の割合(または所定の値)だけ低下させることによって、チーム戦力を低下させてもよい。
例えば、チーム戦力の低下によりn回分の対戦が不利になるというデメリットがプレイヤに与えられる場合、ゲーム情報変更手段59は、ゲーム情報管理手段51の特典情報記憶部51iが記憶しているプレイヤのデメリットに関する情報を変更することになる。
図6の下部には、プレイヤID=“000001”のプレイヤのデメリットに関する情報を例示している。図6の例では、デメリットに関する情報として「対戦が不利になる回数=0」が記憶されており、当該プレイヤには、現在、デメリットは生じていない。
その他のデメリットの例としては、次のようなものがある。すなわち、ゲーム中に消費されて減った行動力ポイントなどのポイントは、例えば3分経過する毎に1ポイントずつ回復するようになっているが、このポイント回復時間を延長する(例えば、4分経過する毎に1ポイントずつ回復するようにする)というデメリットが考えられる。また、前述の選手抽選獲得モードにおいて、レアカードが抽選される確率を所定回数(例えば1回)だけ低下させる(すなわち、希少価値の低いノーマルカードが抽選される確率を向上させる)というデメリットも考えられる。また、前述の行動力ポイント、運営コスト、強化ポイント、エールポイントなどのゲーム内で使用される各種ポイントを、所定ポイント分だけ削減するというデメリットも考えられる。
なお、あまりにデメリットを大きくし過ぎると、プレイヤのゲームに対するモチベーションの低下を招来させることにもなり兼ねないことから、ゲーム内容に応じた適度なデメリットの設定が好ましい。
次に、報知手段60について説明する。この報知手段60は、特典が付与されたプレイヤの端末装置3に対して、仲間アクセス平均に基づいてゲーム上有利になった旨を報知する機能を有する。また、報知手段60は、デメリットが与えられたプレイヤの端末装置3に対して、仲間アクセス平均に基づいてゲーム上不利になった旨を報知する機能を有する。
プレイヤに特典またはデメリットが与えられた場合、ゲームサーバ1の報知手段60は、その旨をプレイヤに報知したか否かを管理する必要があるので、本実施の形態では、図6の下部に示す特典報知フラグおよびデメリット報知フラグによりこれを管理するようにしている。すなわち、本実施の形態において、プレイヤに特典等が付与される時間は、毎週月曜日の所定時間(例えば午前0時過ぎ)であり、当該時間にプレイヤの端末装置3がゲームサーバ1にアクセスしていない場合も多いと考えられる。ゲームサーバ1がプレイヤに特典またはデメリットの報知を行うのは、特典等の付与処理後にプレイヤの端末装置3がゲームサーバ1に最初にアクセスしたときであり、特典等の付与処理からその報知までにはある程度の時間差がある。そこで、ゲームサーバ1の報知手段60は、プレイヤに特典が付与されたとき、当該プレイヤのプレイヤIDと対応付けて特典報知フラグを「1」に設定し、これによって当該プレイヤに特典付与を報知する必要がある状態を管理する。そして、その後、特典報知フラグとして「1」がセットされているプレイヤの端末装置3からアクセスがあったとき、ゲームサーバ1は、当該プレイヤに特典が付与された旨を報知し、併せて特典報知フラグを「0」にする。また、プレイヤにデメリットが与えられたとき、報知手段60は、プレイヤIDと対応付けてデメリット報知フラグを「1」に設定し、以下、特典報知フラグの場合と同様の処理を行う。
報知手段60による特典の報知の例を、図11(a)(b)に示している。図11(a)は、特典が付与されたプレイヤの端末装置3の表示部35に表示されるゲームのメイン画面の一例を示すものである。ゲームサーバ1における特典付与処理後に、プレイヤの端末装置3が最初にゲームサーバ1にアクセスしたとき、ゲームサーバ1の報知手段60からは、図11(a)に示すメイン画面を表示させる画面データが端末装置3へ送信されてくる。このメイン画面には、プレイヤのチーム名70、プレイヤが所有する選手カードの中からリーダーとして選択された選手カード71およびプレイヤのゲーム情報72などが表示されるとともに、特典通知情報73も表示される。なお、メイン画面の詳細については、後述する。
図11(a)に示すように、端末装置3のメイン画面に表示される特典通知情報73は、例えば「先週の仲間アクセス平均が全体の平均を超えました!特典確認画面へ」というような、仲間アクセス平均に基づいて特典が付与されたことが分かる内容である。また、当該特典通知情報73にはハイパーリンクが設定されており(または、特典通知情報73の全体またはその一部が選択可能なボタン形式となっていてもよい)、プレイヤが画面上の特典通知情報73を選択可能になっている。
ここで、プレイヤが端末装置3を操作して特典通知情報73を選択する操作をすると、当該操作に応答して、ゲームサーバ1の報知手段60からは、図11(b)に示す特典確認画面を表示させる画面データが端末装置3へ送信されてくる。この特典確認画面には、例えば、プレイヤの仲間アクセス平均の値および全体クセス平均の値が表示されるとともに、「対戦3回分戦力アップ」というような具体的な特典が表示され、プレイヤは仲間アクセス平均に基づいて付与された特典の内容を確認することができる。また、この特典確認画面には、例えば「この調子で仲間のゲームアクセスを維持して来週も特典獲得を目指そう!」といった付加的メッセージも表示される。この特典確認画面において、例えば「メイン画面へ」ボタン74が選択されると、前記のメイン画面へ戻ることができる。
また、報知手段60によるデメリットの報知の例を、図12(a)(b)に示している。図12(a)は、デメリットが発生したプレイヤの端末装置3の表示部35に表示されるゲームのメイン画面の一例を示すものである。ゲームサーバ1におけるデメリット付与処理後に、プレイヤの端末装置3が最初にゲームサーバ1にアクセスしたとき、ゲームサーバ1の報知手段60からは、図12(a)に示すメイン画面を表示させる画面データが端末装置3へ送信されてくる。このメイン画面には、プレイヤのチーム名70、上述したリーダーの選手カード71、プレイヤのゲーム情報72とともに、デメリット通知情報75が表示される。
端末装置3のメイン画面に表示されるデメリット通知情報75は、例えば「先週は仲間のアクセス平均が全体の平均を下回りました!デメリット確認画面へ」というような、仲間アクセス平均が基準を満たさなかったためにデメリットが発生したことが分かる内容である。また、当該デメリット通知情報75にはハイパーリンクが設定されており(または、デメリット通知情報75の全体またはその一部が選択可能なボタン形式となっていてもよい)、プレイヤが画面上のデメリット通知情報75を選択可能になっている。
ここで、プレイヤが端末装置3を操作してデメリット通知情報75を選択する操作をすると、当該操作に応答して、ゲームサーバ1の報知手段60からは、図12(b)に示すデメリット確認画面を表示させる画面データが端末装置3へ送信されてくる。このデメリット確認画面には、例えば、プレイヤの仲間アクセス平均の値および全体クセス平均の値が表示されるとともに、「対戦1回分戦力ダウン」というような具体的なデメリットが表示され、プレイヤは仲間アクセス平均に基づいて生じたデメリットの内容を確認することができる。また、このデメリット確認画面には、例えば「仲間のゲームアクセスをもっと高めて来週こそは特典を獲得しよう!」といった付加的メッセージが表示される。このデメリット確認画面において、例えば「メイン画面へ」ボタン74が選択されると、前記のメイン画面へ戻ることができる。
このように本実施の形態では、ゲームサーバ1における特典付与またはデメリット付与の処理後に、プレイヤの端末装置3が最初にゲームサーバ1にアクセスしたとき、ゲームのメイン画面内に特典通知情報73またはデメリット通知情報75を含ませることによって、特典またはデメリットの発生を各プレイヤに報知するようになっている。メイン画面はゲームの開始時に必ず表示される基本画面であり、このメイン画面に特典通知情報73またはデメリット通知情報75を表示することにより、特典またはデメリットの発生を、プレイヤに的確に報知することができる。
また、このメイン画面にはその他のオブジェクトや情報も多く含まれるため、特典またはデメリットの詳細については、図11(b)または図12(b)に示す特典またはデメリット確認画面に遷移して確認できるようにしているが、これに限定されるものではない。例えば、ゲームサーバ1における特典付与またはデメリット付与の処理後に、プレイヤの端末装置3が最初にゲームサーバ1にアクセスしたとき、メイン画面よりも先に、図11(b)または図12(b)に示す特典またはデメリット確認画面がプレイヤの端末装置3の表示部35に表示されるようにし、当該確認画面でプレイヤが特典またはデメリットの発生を確認してから、プレイヤによる所定の操作によりメイン画面に遷移するようにしてもよい。
このように報知手段60は、メイン画面等に特典またはデメリットの発生情報を表示させてプレイヤへの報知を行うので、前記のゲーム画面生成手段52bおよびゲーム画面送信手段52cと協働して当該報知の処理を行うようになっている。
ところで、前記の報知手段60は省略することも可能である。例えば、ゲームの説明画面(メイン画面のヘルプメニュー等を選択することによって表示される画面)の中に「仲間がアクセスすればするほど嬉しいことが・・・」の様な暗示的な表示をするだけで、仲間アクセス平均に基づいてプレイヤに特典が付与されても、仲間アクセス平均に基づいてゲーム上有利になった旨を明確にプレイヤに報知しない構成とすることもできる。また、仲間アクセス平均に基づいてアイテム等の特典をプレイヤに付与していることを明示せずに、突然、ゲームサーバ1から(ゲーム運営側から)アイテム等をプレイヤへプレゼントするだけの構成も考えられる。ただし、仲間アクセス平均に基づいてゲーム上有利または不利になった旨を明確にプレイヤに報知することによって、プレイヤは、仲間アクセス平均を高めることの重要性を十分に認識し、仲間のアクセス頻度を高めるために仲間と積極的にコミュニケーションをとる動機付けを与えられることになるので、前記の報知手段60を具備することがより好ましい。
次に、メッセージ伝達手段61について説明する。メッセージ伝達手段61は、各プレイヤの端末装置3から送信された他のプレイヤ宛のメッセージを受信するとともに、当該メッセージを当該他のプレイヤへ伝達する機能を有する。このメッセージ伝達手段61は、メッセージ記憶部61aを備えている。
図13には、メッセージ記憶部61aがデータベースサーバ2に記憶して管理する、受信メッセージに関する情報の一例を示している。このメッセージ記憶部61aは、メッセージを受け取った受信側プレイヤのプレイヤIDと対応付けて、送信元のプレイヤID、メッセージの内容、送信日時などのメッセージに関する情報を、受信側のプレイヤのプレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。図13の例では、プレイヤID=“000002”
の受信側プレイヤ1人分の受信メッセージに関する情報を示しており、当該プレイヤは、プレイヤID=“000001”のプレイヤから「アクセス頑張ろう!」、プレイヤID=“000038”のプレイヤから「おはようございます!今週はアクセス頑張りましょう!」、プレイヤID=“000145”のプレイヤから「今週もよろしく!」というメッセージをそれぞれ受け取っている。
ここで、プレイヤが自分の仲間プレイヤに対してメッセージを送る操作の一例を説明する。図14(a)には、ゲームサーバ1から送信された画面データに基づいて、プレイヤの端末装置3に表示される仲間リスト画面の一例を示している。この仲間リスト画面は、例えばプレイヤが端末装置3を操作してメイン画面中の「仲間メニュー」を選択することによって表示される画面である。この仲間リスト画面には、プレイヤと仲間関係にある仲間プレイヤの情報がリストアップされて表示される。なお、画面に表示しきれない仲間プレイヤの情報については、画面をスクロールするまたは仲間リストの2ページ目以降をゲームサーバ1にリクエストして別画面として表示することができる。
この仲間リスト画面内にはリストアップされた仲間プレイヤ毎の情報表示領域が設けられており、各情報表示領域には、仲間プレイヤのゲーム情報81(プレイヤ名、チーム名、プレイヤのレベル、仲間の人数、所属リーグのレベル等)、当該プレイヤの分身的なキャラクタであるアバター82、当該プレイヤが所有するリーダーの選手カード83などとともに、エールボタン84というオブジェクトも表示される。そして、プレイヤがこのエールボタン84を選択することで、自分の仲間プレイヤに対してエール(応援)を送る(応援の意思表示をする)ことができるようになっている。プレイヤは、仲間プレイヤにエールのみを送ることもできるが、以下に説明するように、さらにメッセージも送ることができる。
プレイヤの端末装置3における操作によりエールボタン84が選択された場合、当該操作が端末装置3からゲームサーバ1へ伝えられる。その後、ゲームサーバ1からは、例えば図14(b)に示すメッセージ入力画面のデータが端末装置3へ送信され、端末装置3に当該メッセージ入力画面が表示される。このメッセージ入力画面には、例えば、仲間プレイヤ(図14(b)の例ではプレイヤB)に対してエールを送った旨を示す文章等が表示されるとともに、メッセージ入力領域85および送信ボタン86というオブジェクトも表示される。そして、プレイヤは、端末装置3を操作してメッセージ入力領域85に任意のメッセージを入力し、送信ボタン86を選択することによって、端末装置3からは仲間プレイヤ宛のメッセージがゲームサーバ1へ送信される。図14(b)では「アクセス頑張ろう!」というメッセージをプレイヤが入力した例を示している。なお、データベースサーバ2における記憶容量を考慮して、メッセージ入力領域85に入力できる文字に制限(例えば全角30文字以内)を設けてもよい。
なお、メッセージ入力画面には、仲間プレイヤ(この例ではプレイヤB)のページへ遷移するためのハイパーリンク87が表示されており、このリンクを選択することにより当該仲間プレイヤのゲーム情報の詳細が記載されたページを表示できる。また、メッセージ入力画面には、仲間リストへ遷移するためのハイパーリンク88やメイン画面へ遷移するためのハイパーリンク89なども表示されており、これらのリンクを選択することにより仲間リストやメイン画面に戻れるようになっている。
このメッセージ入力画面でのプレイヤの操作により端末装置3からメッセージが送信された場合、ゲームサーバ1では、メッセージ伝達手段61のメッセージ記憶部61aが、端末装置3から受信した仲間プレイヤ宛のメッセージを、当該仲間プレイヤのプレイヤIDと対応させてデータベースサーバ2に記憶する(図13参照)。そして、当該仲間プレイヤの端末装置3がゲームサーバ1へアクセスしたとき、ゲームサーバ1のメッセージ伝達手段61は、メッセージ、送信元のプレイヤ名、送信時間等を表示させる画面データを端末装置3に送信する。これにより、この画面データを受信したプレイヤの端末装置3にはメッセージ等が表示され、他の仲間から受け取ったメッセージを画面で確認できるようになっている。
このように、本実施の形態のゲームシステムでは、前記図14(a)(b)に例示するようなコミュニケーションツールを使用して、仲間同士が何時でもコミュニケーションをとることができるようになっている。
前記図14(a)(b)の例では、プレイヤの仲間に対してメッセージを送る例を説明したが、仲間関係にはない他のプレイヤに対しても、エールを送ったりメッセージを送ったりすることができる。例えば、後述する仲間候補リスト画面(図26参照)にリストアップされた仲間ではない他のプレイヤに対して、仲間の場合と同様の操作により、エールやメッセージを送ることが可能である。
ところで、上記の説明では、仲間管理手段53が管理している各プレイヤの仲間情報、アクセス管理手段55が管理している各プレイヤのアクセス情報、メッセージ伝達手段61が管理しているメッセージに関する情報は、便宜上、ゲーム情報管理手段51が管理している各種情報とは区別して記載しているが、これらの情報は何れもゲームサーバ1が管理するゲーム情報に含まれるものである。
〔ゲームシステムの動作〕
上記の構成において、本発明の実施の形態に係るゲームシステムの動作例を、図15のフローチャートを参照しながら以下に説明する。図15は、プレイヤが端末装置3を操作してゲームサーバ1にアクセスしてゲームサービスを受けるときの、端末装置3およびゲームサーバ1の処理の流れを示すものである。
プレイヤがゲームサービスを受ける場合、先ず、端末装置3の操作入力部40を操作してウェブブラウザを起動する(S11)。その後、プレイヤは、ゲームサーバ1が管理するゲームサイトにアクセスする操作を行い、これにより、端末装置3からゲームサーバ1へアクセスリクエストが送信される(S12)。このとき、ゲームサーバ1は、端末装置3からのアクセスに対するログイン認証を行い(S21)、ゲームサービスの利用登録がなされているプレイヤからのアクセスであることを確認する。その後、ゲームサーバ1は、HTML等で記述されたメイン画面データを端末装置3に送信する(S22)。そして、メイン画面データを受信した端末装置3では、ウェブブラウザが当該データを解釈し、メイン画面を表示部35に表示させる(S13)。
図11(a)に例示するように、メイン画面には、プレイヤのチーム名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にアクセスしたときに画面で確認することができる。
〔ゲーム管理装置の動作〕
次に、本発明の実施の形態に係るゲーム管理装置のより詳細な動作例を、図16および図17のフローチャートを参照しながら説明する。図16は、ある一人のプレイヤを対象としたゲームサーバ1の処理の流れを示すものであり、ゲームサーバ1が管理している各々のプレイヤに対して同様の処理が行われる。
図16に示すように、ゲームサーバ1の認証手段54は、プレイヤの端末装置3からアクセス要求を受けたとき(S31でYES)、端末装置3から送信されてきたログインID・パスワード、または携帯電話端末の個体識別番号等に基づいて、アクセスを許可するか否かを判断するログイン認証を行う(S32)。ここで、アクセスを許可しない場合(S32でNO)、ゲームサーバ1は、端末装置3にゲームサービスの利用登録を促す画面データを送信する(S33)。一方、アクセスを許可する場合(S32でYES)、アクセス管理手段55がプレイヤのアクセス情報を記憶する(S34)。例えば、図9(a)に示すように、アクセス管理手段55のアクセス情報記憶部53aが、プレイヤIDと対応付けて、プレイヤの当日のアクセス回数の情報を更新する(例えば、土曜日にアクセスがあったとき、土曜日のアクセス回数の値を1つ増加する)。
そして、ゲームサーバ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の処理が繰り返されることで、ゲームが進行していく。
次に、図17を参照して、ゲームサーバ1における仲間アクセス平均に基づく特典またはデメリット発生処理について説明する。上述のように、ここでは、前週の月曜日〜日曜日までの直近7日間の仲間アクセス平均と基準値である全体アクセス平均との比較結果を、翌月曜日にプレイヤに報知する例について説明する。
仲間アクセス平均に基づいた特典等の付与処理を行う所定時間(例えば、毎週月曜日の午前0時)になれば(S51でYES)、先ず、ゲームサーバ1のアクセス平均算出手段56が、各プレイヤのアクセス平均を算出する(S52)。本実施の形態では、アクセス管理手段55が記憶している前週の月曜日〜日曜日までの各日のアクセス回数に基づいて、アクセス平均算出手段56が、直近7日間のアクセス平均をプレイヤ毎に算出することになる。また、各プレイヤのアクセス平均の算出結果は、プレイヤIDと対応づけられてデータベースサーバ2に記憶される。ところで、ゲームサービスの利用開始から7日を経過していない新規参入のプレイヤについては、直近7日間のアクセス平均算出期間(平均算出時の時間的な母数の7日間)を満足しないため、アクセス平均算出の対象から除外することが望ましい。
その後、ゲームサーバ1の全体アクセス平均算出手段58は、アクセス平均算出手段56が算出した各プレイヤのアクセス平均に基づいて、全体アクセス平均AVAtを算出する(S53)。
その後、ゲームサーバ1は、各プレイヤを対象として、以下のS54〜S61の処理を行う。すなわち、以下のS54〜S61については、ある一人のプレイヤを対象としたゲームサーバ1の処理の流れを示すものであり、ゲームサーバ1が管理している各々のプレイヤに対して同様の処理が行われることになる。
S54において、ゲームサーバ1は、プレイヤに仲間が存在するか否かを判断する。ここで、プレイヤが一人も仲間を作っていなかった場合(S54でNO)、ゲームサーバ1は、当該プレイヤに対しては仲間アクセス平均AVAgの算出処理等をすることなく処理を終了する。一方、プレイヤに仲間が1人以上存在する場合(S54でYES)、ゲームサーバ1の仲間アクセス平均算出手段57は、仲間管理手段53が管理しているプレイヤの仲間情報およびアクセス平均算出手段56が算出した仲間プレイヤのアクセス平均に基づいて、当該プレイヤの仲間アクセス平均AVAgを算出する(S55)。
その後、比較部59aが、仲間アクセス平均AVAgと全体アクセス平均AVAtとを比較し、仲間アクセス平均AVAgの方が全体アクセス平均AVAtよりも大きいとき(S56でYES)、ゲーム情報変更手段59が、ゲーム上有利になるようにプレイヤのゲーム情報を変更し(S57)、これによって当該プレイヤに特典を付与する。例えば、チーム戦力の向上によりn回分の対戦が有利になるという特典をプレイヤに付与する場合、当該プレイヤのプレイヤIDに対応するゲーム情報(対戦が有利になる回数の情報)が変更されることになる。
一方、仲間アクセス平均AVAgの方が全体アクセス平均AVAtよりも小さいとき(S56でNOおよびS58でYES)、ゲーム情報変更手段59が、ゲーム上不利になるようにプレイヤのゲーム情報を変更し(S59)、これによって当該プレイヤにデメリットを発生させる。例えば、チーム戦力の低下によりn回分の対戦が不利になるというデメリットをプレイヤに対して生じさせる場合、当該プレイヤのプレイヤIDに対応するゲーム情報(対戦が不利になる回数の情報)が変更されることになる。
その後、プレイヤの端末装置3からゲームサーバ1へのアクセスがあれば(S60でYES)、報知手段60が、仲間アクセス平均AVAgに基づいてゲーム上有利になった旨(特典が付与された旨)、または仲間アクセス平均AVAgに基づいてゲーム上不利になった旨(デメリットが発生した旨)を、プレイヤの端末装置3に対して報知する(S61)。例えば、図11(a)または図12(a)に例示するように、ゲームのメイン画面内に特典通知情報73またはデメリット通知情報75を含ませることによって、特典またはデメリットの発生を各プレイヤに報知する。報知手段60による報知の例としては、ゲーム画面の中に特典またはデメリットの発生の旨を表示することの他に、音声による報知や画面表示と音声とを併用した報知も考えられる。音声による報知は、ゲームサーバ1からプレイヤの端末装置3へ送信する画面データ(HTMLデータ)に音声データを含ませることにより実現できる。
また、プレイヤの仲間アクセス平均AVAgと全体アクセス平均AVAtとの比較の結果、両者が同じ値であった場合(S56でNOおよびS58でNO)、ゲームサーバ1は、当該プレイヤに対しては特典もデメリットも発生させることなく前記S60に移行し、プレイヤの端末装置3からゲームサーバ1へのアクセスがあったときに、特典等が発生しなかった旨を報知する(S61)。
以上のように、本実施の形態では、仲間アクセス平均が全体アクセス平均(第1基準値)を超えているプレイヤに対してゲーム上有利になるという特典が付与される。すなわち、本実施の形態のゲームサービスにおいてプレイヤが特典を受けるためには、自分の努力以外に、仲間との協力により仲間アクセス平均を高める必要があることから、各プレイヤは、仲間アクセス平均を上げようとして、自己の仲間プレイヤとコミュニケーションをとる動機付けを与えられることになる。例えば、各プレイヤは、仲間に対して「アクセス頑張ろう!」のようなメッセージを送って、自己の仲間プレイヤとの間のコミュニティを盛り上げようとする。
このように、本実施の形態では、単に特典を受けることの面白さをプレイヤに提供するにとどまらず、仲間とのコミュニケーションをとる動機付けをプレイヤに与え、これにより、ゲームコミュニティ全体の活性化を図ることができる。この結果、各プレイヤはゲーム内での仲間同士のつながりや交流を強め、延いてはゲームに対する関心と興味をより強めることとなるので、プレイヤにとって飽きのこない継続性を有するゲームを実現できる。
また、本実施の形態では、仲間アクセス平均が全体アクセス平均(第2基準値)より低いプレイヤに対してゲーム上不利になるというデメリットが生じる。これにより、各プレイヤは、デメリットを回避するために仲間アクセス平均を出来るだけ上げようとして、自己の仲間プレイヤとコミュニケーションをとる動機付けを与えられることになるため、ゲームコミュニティ全体の活性化を図ることができる。
また、本実施の形態では、仲間アクセス平均と比較される基準値(第1基準値、第2基準値)を、全体アクセス平均としている。このように全体アクセス平均を特典付与またはデメリット発生の基準値(閾値)とすることにより、例えばゲームの人気が高まって全体アクセス平均がアップした場合には、それに伴って基準値も高くなる。この基準値を超えるために各プレイヤは、仲間アクセス平均を上げようとするので、各プレイヤの仲間アクセス平均の向上がさらなる全体アクセス平均の向上に繋がる。すなわち、仲間アクセス平均の向上→全体アクセス平均(基準値)の向上→仲間アクセス平均の向上→全体アクセス平均の向上・・・というように、全体のアクセス向上効果が期待できる。
特に、本実施の形態のように、前週の月曜日〜日曜日までの直近7日間の仲間アクセス平均と全体アクセス平均との比較結果を、翌月曜日にプレイヤに報知して、毎週、仲間アクセス平均に基づく特典を獲得し得るゲーム運用形態とすることにより、継続的に全体のアクセス頻度を高いレベルに維持できるようになる。
ところで、ゲームサーバ1においては、通常のゲーム進行の処理と並行して、仲間アクセス平均に基づいて特典またはデメリットを発生させるか否かを判断する処理を、各プレイヤ(各プレイヤID)に対して行うことになるので、ゲームサーバ1の負荷分散を考慮して、次のような対応をとることもできる。すなわち、全てのプレイヤに対して、一斉に当該処理を実行するのではなく、全てのプレイヤを複数のブロックに分割し、ブロックによって当該処理を実行する時間をずらし、時間的な処理分散を図る。例えば、ゲームサーバ1は、毎週月曜日の所定時間帯(例えば午前0時から1時までの1時間)の中で時分割の処理を行う。この場合であっても、特典またはデメリットが有効になる時間については、どのプレイヤに対しても同じタイミングとすべきであり、例えば、毎週月曜日の午前1時に特典またはデメリットが一斉に有効になるものとする。
また、上記では、アクセス平均算出手段56が、基本的にプレイヤの仲間全員を対象として仲間アクセス平均を算出する例を説明したが、次に示す非アクティブプレイヤを除外して仲間アクセス平均を算出する構成としてもよい。ここで言う非アクティブプレイヤとは、ゲームサーバ1に対してゲームサービスの利用登録はしているものの実態としては全くゲームプレイをしていないか、ゲームプレイが基準より少ないプレイヤを示すものであり、「ゲームサーバ1へのアクセスの頻度が閾値に満たないプレイヤ」と定義されるものである。例えば、アクセス頻度の閾値を「1回/月」(すなわち、直近の1か月間に1回のアクセス)とした場合、直近の1か月間に1度もゲームサーバ1へアクセスしていないプレイヤは、当該閾値の条件を満たさない非アクティブプレイヤとなる。
なお、アクセス頻度の閾値は、「1回/月」に限定されるものではなく、例えば、「2回/月」(直近の1か月間に2回のアクセス)、「1回/3週間」(直近の3週間に1回のアクセス)、「1回/20日」(直近の20日間に1回のアクセス)などのように、アクセス頻度を定める期間および当該期間中のアクセス回数を、任意に設定することができる。
このように非アクティブプレイヤを除外して仲間アクセス平均を算出する理由は、非アクティブプレイヤを仲間アクセス平均の算出対象に入れると、実態にそぐわない算出データとなることもあるためである。例えば、ゲームに熱中して多数の仲間(例えば30人程度の仲間)を作ったプレイヤであっても、たまたまその仲間の半数程度が非アクティブプレイヤであった場合、当該プレイヤの仲間アクセス平均が大きく低下してしまうことになるためである。
そこで、仲間アクセス平均算出手段56は、プレイヤの仲間の中からゲームサーバ1へのアクセス頻度が閾値に満たない非アクティブプレイヤを除外して、仲間アクセス平均をプレイヤ毎に算出する。ここで、プレイヤが非アクティブプレイヤであるか否かの判断は、アクセス管理手段55が管理している各プレイヤのアクセス頻度の情報に基づいて行われる。
本実施の形態では、図9(a)に例示するように、アクセス管理手段55のアクセス情報記憶部55aが、今週の月曜日〜日曜日の各日についてのプレイヤのアクセス回数とともに、1週前〜n週前の各週についての当該プレイヤのアクセス平均も、プレイヤID毎にデータベースサーバ2に記憶して管理している。すなわち、本実施の形態のアクセス管理手段55は、n週前までの各プレイヤのアクセス頻度の情報を管理しているのである。
ゲームサーバ1のCPU11は、このアクセス頻度の情報に基づいて、例えばアクセス頻度の閾値=「1回/3週間」を満たすか否かを判断する。すなわち、1週前〜3週前のアクセス平均の値が全て「0」であるプレイヤIDに対応するプレイヤが、当該アクセス頻度の閾値の条件を満たさない非アクティブプレイヤであると判断できる。一方、1週前〜3週前のアクセス平均の値の何れか1つでも「0」以外の値となっているプレイヤIDに対応するプレイヤは、直近の3週間以内に少なくとも1回以上、ゲームサーバ1へアクセスしたプレイヤであり、非アクティブプレイヤではないと判断できる。
また、非アクティブプレイヤの管理のために、図18に示すように、アクセス管理手段55のアクセス情報記憶部55aがプレイヤID毎に記憶して管理する情報として、各プレイヤの最終アクセス時刻やアクティブフラグを含めてもよい。プレイヤの最終アクセス時刻からは、プレイヤがゲームサーバ1へ一度もアクセスしていない期間の長さ(最終アクセス時刻から現在時刻までの期間)が分かるので、ゲームサーバ1のCPU11は、当該最終アクセス時刻に基づいて、アクセス頻度の閾値を満たさない非アクティブプレイヤか否かを判断することもできる。
また、前記アクティブフラグは、アクティブなプレイヤであるか非アクティブプレイヤであるかを示す1ビットの情報であって、このアクティブフラグが「1」のプレイヤはアクティブであり、当該フラグが「0」のプレイヤは非アクティブプレイヤである。アクセス管理手段55は、前述の非アクティブプレイヤか否かの判断に基づいてアクティブフラグを設定する。そして、仲間アクセス平均算出手段56は、このアクティブフラグを参照して仲間アクセス平均を算出する対象の仲間プレイヤを抽出し(すなわち、非アクティブプレイヤを除外し)、各プレイヤの仲間アクセス平均を算出することができる。
また、仲間アクセス平均を算出する場合だけではなく、全体アクセス平均を算出する場合にも、前記の非アクティブプレイヤを除外してもよい。
また、上記では、仲間アクセス平均と比較される基準値(第1基準値、第2基準値)を、各プレイヤのアクセス頻度によって変動する全体アクセス平均とした例について説明したが、これに限定されるものではなく、当該基準値を予め定められた固定値とすることもできる。例えば、この基準値を、固定値=0.6としてゲームを運用してもよい。
また、本実施の形態のゲームシステムは、ゲームサーバ1においてプレイヤのゲーム情報を管理してゲームを実行するので、基本的にゲーム実行プログラムはゲームサーバ1側に存在する。よって、ゲームサービスの運営者がゲームサーバ1側のゲーム実行プログラムを追加・変更することによって、全てのゲームサービスの利用者(プレイヤ)が追加・変更されたゲームサービスを受けることができる。このため、ゲームサーバ1側のゲーム実行プログラムを追加・変更して期間限定のゲーム内イベントを適宜開催し、プレイヤに色々なゲームサービスを提供することも容易にできる。そこで、「仲間アクセス平均」を利用して、期間限定のゲーム内イベントを開催し、特典としてプレイヤがレアアイテムやレアカード等を獲得できる(または獲得し易くなる)ようにしてもよい。この場合、イベント期間中は第1基準値を意図的に高めて、例えば第1基準値を固定値の0.8に設定するというように、ゲームサービス提供側のゲーム運用形態に応じて、全体アクセス平均以外の第1基準値を設定してもよい。なお、上記のような期間限定イベントを開催する場合は、イベント期間を、仲間アクセス平均を算出する期間と合致させてもよい。
このように基準値を予め定められた固定値とした場合、プレイヤにとっては、特典を獲得するための目標(基準値)が当初より明確化されることになる。
また、上記では、ゲームを有利にするか否かを判定するための第1基準値と、ゲームを不利にするか否かを判定するための第2基準値とが、同一の値(第1基準値=第2基準値=全体アクセス平均)とした例について説明したが、これに限定されるものではなく、第1基準値と第2基準値とを異なる値としてゲームを運用してもよい。
また、上記においては、各プレイヤの仲間アクセス平均に基づいて、メリット(特典)だけでなくデメリットも生じ得る例を説明したが、メリットは発生させてもデメリットは発生させない形態であってもよい。特に、上記のような仲間アクセス平均と比較される基準値を意図的に高めた期間限定イベントを開催する場合、デメリットを生じさせない運用が望ましいこともある。また、デメリットは発生させてもメリットは発生させない形態であってもよい。すなわち、メリットおよびデメリットの発生態様は、以下の(A)〜(D)が考えられる。
(A)「メリット発生」または「メリットもデメリットも発生しない」の何れか。
(B)「デメリット発生」または「メリットもデメリットも発生しない」の何れか。
(C)「メリット発生」または「デメリット発生」の何れか。
(D)「メリット発生」、「デメリット発生」または「メリットもデメリットも発生しない」の何れか。
上記の態様(A)の場合、例えば、「仲間アクセス平均>全体アクセス平均」のときのみメリット(特典)を発生させ、デメリットは発生させないようにする。また、上記の態様(B)の場合、例えば、「仲間アクセス平均<全体アクセス平均」のときのみデメリットを発生させ、メリットは発生させないようにする。また、上記の態様(C)の場合、例えば、「仲間アクセス平均≧全体アクセス平均」のときは特典を発生させ、「仲間アクセス平均<全体アクセス平均」のときはデメリットを発生させることにより、メリットまたはデメリットのいずれかが必ず発生するようにする。
また、図17のフローチャートに示した本実施の形態の態様(「仲間アクセス平均>全体アクセス平均」のときは特典発生、「仲間アクセス平均<全体アクセス平均」のときはデメリット発生、「仲間アクセス平均=全体アクセス平均」のときは何も発生しない)は、上記の態様(D)の一例である。態様(D)の他の例としては、プレイヤの仲間アクセス平均が全体アクセス平均から所定ポイント以上離れた場合に、メリットまたはデメリットが発生するようにする。具体的には、例えば全体アクセス平均=0.6とした場合、仲間アクセス平均が0.6から上下0.1ポイントを超えて離れた場合にメリットおよびデメリットが発生するようにし、メリットもデメリットも生じない範囲に幅を持たせる。すなわち、「仲間アクセス平均>0.7」のときは特典を発生させ、「仲間アクセス平均<0.5」のときはデメリットを発生させ、「0.5≧仲間アクセス平均≦0.7」のときは何も発生させないこととする。この場合、ゲームを有利にするか否かを判定するための第1基準値が0.7となる一方、ゲームを不利にするか否かを判定するための第2基準値が0.5となるので、第1基準値と第2基準値とが異なる値をとる一つの例である。
また、仲間アクセス平均が全体アクセス平均(第1基準値)を超えた全てのプレイヤに同一の特典(例えば、対戦3回分が有利になる特典)を付与する構成としてもよいが、仲間アクセス平均が高いほど(仲間アクセス平均と第1基準値との差が大きいほど)、より大きな特典を付与する構成とすることもできる。これを実現するゲームサーバ1(ゲーム管理装置)の要部の構成を、図19に示す。同図は、主にゲーム情報変更手段59の構成を示す機能ブロック図である。
ゲーム情報変更手段59は、仲間アクセス平均と全体アクセス平均とを比較する比較部59aの比較結果に基づいて特典発生判定部59bが特典の発生を判定した場合に、仲間アクセス平均と全体アクセス平均(第1基準値)との差に基づいて特典を決定する特典決定部90を備えている。この特典決定部90は、仲間アクセス平均と全体アクセス平均との差を算出する差算出部90aを備えており、算出した差が大きいほど特典が大きくなるように特典を決定する。この構成のゲームサーバ1の処理例を、図20のフローチャートに示す。
図20において、S51〜S56については、基本的には図17のフローチャートで説明した処理と同様の処理であり、その説明を省略する。ゲームサーバ1の比較部59aが、仲間アクセス平均AVAgと全体アクセス平均AVAtとを比較した結果、仲間アクセス平均AVAgの方が全体アクセス平均AVAtよりも大きいとき(S56でYES)、特典発生判定部59bが特典発生の判定をし、S70以降の特典決定部90による特典決定処理に移行する。
すなわち、ゲームサーバ1の特典決定部90は、先ず、仲間アクセス平均AVAgと全体アクセス平均AVAtとの差Diffを算出する(S70)。そして、この差Diffが例えば0.1以下のとき(S71でYES)、特典決定部90は、例えば対戦2回分有利の特典を決定し、プレイヤのゲーム情報を変更する(S72)。また、前記の差Diffが、例えば0.1より大きく且つ0.2以下のとき(S71でNO、S73でYES)、特典決定部90は、例えば対戦3回分有利の特典を決定し、プレイヤのゲーム情報を変更する(S74)。また、前記の差Diffが、例えば0.2より大きいとき(S73でNO)、特典決定部90は、例えば対戦4回分有利の特典を決定し、プレイヤのゲーム情報を変更する(S75)。なお、図20におけるS58〜S61については、基本的には図17のフローチャートで説明した処理と同様の処理であり、その説明を省略する。このルーチンによると、例えば全体アクセス平均が0.6であった場合、プレイヤの仲間アクセス平均と当該プレイヤに付与される特典との関係は以下のようになる。
0.6<仲間アクセス平均≦0.7 ・・・対戦2回分有利の特典
0.7<仲間アクセス平均≦0.8 ・・・対戦3回分有利の特典
0.8<仲間アクセス平均 ・・・対戦4回分有利の特典
図20では、対戦n回分有利になる特典を適用した例について説明したが、その他の特典においても同様に、仲間アクセス平均(グループの評価値)と全体アクセス平均等の基準値との差が大きいほど、より大きな特典を付与する構成を適用できる。例えば、ポイントやアイテムを付与する特典を適用する場合、仲間アクセス平均と基準値との差が大きいほど、付与するポイントやアイテムの数を増加させる。また、例えばレアアイテムやレアカードを抽選で獲得できる確率を所定回数だけ上昇させるという特典を適用する場合、仲間アクセス平均と基準値との差が大きいほど、レアアイテム等の抽選確率をより高くする、またはレアアイテム等の抽選確率が高くなる回数をより多くする。
このように、仲間アクセス平均(グループの評価値)に基づいて特典を付与する場合に、プレイヤの仲間アクセス平均が高いほどより大きな特典が得られる構成とすることにより、各プレイヤは、より大きな特典を得るために仲間アクセス平均をさらに上げようとして、仲間とのコミュニケーションをとる動機付けを与えられることになる。このため、ゲームコミュニティ全体の活性化をさらに向上させることができる。
また、上記と同様の考え方を、仲間アクセス平均が第2基準値(全体アクセス平均等)より低いプレイヤにデメリットを発生させる場合にも適用し、仲間アクセス平均が高いほど(仲間アクセス平均と第2基準値との差が小さいほど)、デメリットをより小さくする構成を採用することもできる。
ところで、仲間の人数(仲間アクセス平均を算出する際の母数)が少ないプレイヤの場合、仲間アクセス平均を比較的高くし易いと考えられる。すなわち、プレイヤ自身を含む仲間プレイヤが例えば3人だけの場合、当該プレイヤを除く2人の仲間プレイヤのアクセス頻度を高くすれば、仲間アクセス平均を高くすることができる。これに対し、プレイヤ自身を含む仲間プレイヤが例えば30人の場合、当該プレイヤを除く29人のアクセス頻度を高めなければ、仲間アクセス平均を高くすることができない。
上記の事情を考慮し、プレイヤに特典を付与する場合には、仲間プレイヤの人数が所定人数以上のプレイヤに対してのみ、仲間アクセス平均が高いほどより大きな特典が得られる構成を適用するものとし、仲間プレイヤの人数が所定人数に満たないプレイヤに対しては、仲間アクセス平均の大きさに依らず特典が同一となるようにしてもよい。この場合、仲間プレイヤの人数が所定人数未満のプレイヤに対して付与される特典は、仲間プレイヤの人数が所定人数以上のプレイヤに対して付与される特典のうちの最小の特典と同一又は当該最小の特典よりも小さく設定される。これを実現するゲームサーバ1(ゲーム管理装置)の要部の構成を、図21に示す。
図21は、主にゲーム情報変更手段59の構成を示す機能ブロック図である。このゲーム情報変更手段59は、仲間アクセス平均と全体アクセス平均とを比較する比較部59aの比較結果に基づいて特典発生判定部59bが特典の発生を判定した場合に、仲間アクセス平均と全体アクセス平均(第1基準値)との差およびプレイヤの仲間の人数に基づいて特典を決定する特典決定部91を備えている。この特典決定部91は、仲間管理手段53が管理するプレイヤの仲間人数が所定人数以上(例えば10人以上)の場合には、仲間アクセス平均と全体アクセス平均との差によって特典を変える一方、仲間人数が所定人数未満(例えば10人未満)の場合には仲間アクセス平均の大きさに依らず特典を同一とする。また、特典決定部91は、仲間アクセス平均と全体アクセス平均との差を算出する差算出部91aを備えており、算出した差が大きいほど特典が大きくなるように特典を決定する。この構成のゲームサーバ1の処理は、図22のフローチャートに示すように、前記図20のフローチャートに以下のS80およびS81のステップを付加することによって実現できる。
すなわち、ゲームサーバ1の比較部59aが、仲間アクセス平均AVAgと全体アクセス平均AVAtとを比較した結果、仲間アクセス平均AVAgの方が全体アクセス平均AVAtよりも大きいとき(S56でYES)、特典発生判定部59bが特典発生の判定をし、S80以降の特典決定部91による特典決定処理に移行する。
すなわち、ゲームサーバ1の特典決定部91は、先ず、プレイヤの仲間の人数が、例えば10人以上であるか否かを判断する(S80)。ここで、プレイヤの仲間の人数が10人以上であった場合(S80でYES)、プレイヤの仲間アクセス平均AVAgの高さに応じて対戦2回分〜4回分有利の特典が付与される前述のS70〜S75の処理に移行し、仲間アクセス平均AVAgが高いプレイヤほどより大きな特典が得られるようになっている。一方、プレイヤの仲間の人数が10人未満であった場合(S80でNO)、ゲーム情報変更手段59は、例えば対戦1回分有利になる特典を付与すべく、プレイヤのゲーム情報を変更する(S81)。すなわち、仲間の人数が10人未満のプレイヤに付与される特典は、仲間アクセス平均AVAgの大きさに依らず同一の特典(対戦1回分有利の特典のみ)となる。
このように、仲間プレイヤの人数が所定人数以上のプレイヤに対してのみ、仲間アクセス平均が高いほどより大きな特典が得られる構成を適用し、且つ、仲間プレイヤの人数が所定人数未満のプレイヤが獲得できる特典以上の特典を獲得できるようにすることにより、仲間を所定数以上作る方がより大きなメリットを受け易くなる。これにより、所定数以上の仲間を作ろうとする動機づけを各プレイヤに与えることができる。そして、各プレイヤには、所定数以上の仲間を作った上で、より大きな特典を得るために仲間アクセス平均を上げようとする気持ちが働くので、各プレイヤが多くの仲間とコミュニケーションを取り合う環境を推進できる。このため、ゲームコミュニティ全体の活性化をさらに向上させることができる。
また、仲間を多く作る方がより大きな特典を受け易くし、より多くの仲間がお互いにアクセス頻度を高め合う環境を推進するために、仲間の人数も加味して特典を決定してもよい。すなわち、プレイヤの仲間の人数が多いプレイヤほど、当該プレイヤに付与される特典も大きくなる構成としてもよい。これを実現するゲームサーバ1(ゲーム管理装置)の要部の構成を、図23に示す。
図23は、主にゲーム情報変更手段59の構成を示す機能ブロック図である。このゲーム情報変更手段59は、仲間アクセス平均と全体アクセス平均とを比較する比較部59aの比較結果に基づいて特典発生判定部59bが特典の発生を判定した場合に、プレイヤの仲間の人数に基づいて特典を決定する特典決定部92を備えている。この特典決定部92は、プレイヤの仲間の人数が多いほど特典が大きくなるように特典を決定する。この構成のゲームサーバ1の処理例を、図24のフローチャートに示す。
図24において、S51〜S56については、基本的には図17のフローチャートで説明した処理と同様の処理であり、その説明を省略する。ゲームサーバ1の比較部59aが、仲間アクセス平均AVAgと全体アクセス平均AVAtとを比較した結果、仲間アクセス平均AVAgの方が全体アクセス平均AVAtよりも大きいとき(S56でYES)、特典発生判定部59bが特典発生の判定をし、S91以降の特典決定部92による特典決定処理に移行する。
すなわち、ゲームサーバ1の特典決定部92は、プレイヤの仲間の人数が、例えば30人以上であるか否かを判断する(S91)。ここで、プレイヤの仲間の人数が30人以上であった場合(S91でYES)、特典決定部92は、例えば対戦4回分有利の特典を決定し、プレイヤのゲーム情報を変更する(S92)。また、仲間の人数が例えば20人以上且つ30人未満であった場合(S91でNO、S93でYES)、特典決定部92は、例えば対戦3回分有利の特典を決定し、プレイヤのゲーム情報を変更する(S94)。また、仲間の人数が例えば10人以上且つ20人未満であった場合(S93でNO、S95でYES)、特典決定部92は、例えば対戦2回分有利の特典を決定し、プレイヤのゲーム情報を変更する(S96)。また、仲間の人数が例えば10人未満であった場合(S95でNO)、特典決定部92は、例えば対戦1回分有利の特典を決定し、プレイヤのゲーム情報を変更する(S97)。なお、図24におけるS58〜S61については、基本的には図17のフローチャートで説明した処理と同様の処理であり、その説明を省略する。
このように、プレイヤに特典が付与される場合には、プレイヤの仲間の人数が多いほど付与される特典も大きくなる構成とすることにより、各プレイヤは、より大きな特典を得るために、積極的に多くの仲間を作ろうとする動機付けを与えられることになる。すなわち、各プレイヤには、多くの仲間を作った上で仲間アクセス平均を上げようとする気持ちが働くので、各プレイヤが多くの仲間とコミュニケーションを取り合う環境を推進できる。このため、ゲームコミュニティ全体の活性化をさらに向上させることができる。
また、上記と同様の考え方を、仲間アクセス平均が第2基準値(全体アクセス平均)より低いプレイヤにデメリットを発生させる場合にも適用し、プレイヤの仲間の人数が多いほど、デメリットをより小さくする構成を採用することもできる。
〔ゲーム管理装置の他の構成例〕
次に、ゲーム管理装置の他の構成例を、図25の機能ブロック図を参照しながら説明する。なお、既出の図面(図1〜図24)において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。本実施の形態のゲームサーバ1(ゲーム管理装置)は、図4に示した各手段51〜61に加えて、アクセス頻度表示制御手段100(表示制御手段)をさらに備えている。このアクセス頻度表示制御手段100は、アクセスを受け付けたプレイヤの端末装置3に、他のプレイヤのアクセス頻度の情報を含む画面データ(表示制御情報)を送信することによって、プレイヤの端末装置3の画面に、他のプレイヤのアクセス頻度を表示させる機能を有する。このアクセス頻度表示制御手段100は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。
本ゲームシステムにおいては、プレイヤの仲間アクセス平均に基づいて特典やデメリットが発生するので、プレイヤにとっては、これから仲間になるプレイヤや既に仲間になっているプレイヤのアクセス頻度の情報は重要である。そこで、本実施の形態のアクセス頻度表示制御手段100は、各プレイヤの便宜に供するための情報として、他のプレイヤのアクセス頻度の情報を、プレイヤの端末装置3の画面に表示させるようになっている。
ここで、他のプレイヤのアクセス頻度が表示される画面の例としては、図26に示すような仲間候補リスト画面が挙げられる。この仲間候補リスト画面は、仲間を作ろうとするプレイヤが、自己の端末装置3で仲間候補を検索するゲーム操作を行うことにより、ゲームサーバ1から送信されてくるゲーム画面の一つである。この仲間候補リスト画面には、ゲームサーバ1により抽出された、プレイヤとは未だ仲間関係にない複数のプレイヤが、仲間候補者としてリストアップされて表示される。なお、画面に表示しきれない仲間候補プレイヤの情報については、画面をスクロールして表示するか、または仲間候補リストの2ページ目以降をゲームサーバ1にリクエストして別画面として表示することができる。仲間候補リスト画面内には、リストアップされた仲間候補のプレイヤ毎の情報表示領域が設けられており、各情報表示領域には、仲間候補プレイヤのゲーム情報111(プレイヤ名、チーム名、プレイヤのレベル、仲間の人数、所属リーグのレベル等)、仲間候補プレイヤの分身的なキャラクタであるアバター112、仲間候補プレイヤが所有するリーダーの選手カード113等とともに、仲間候補プレイヤのアクセス頻度114が表示される。
プレイヤは、この仲間候補リスト画面でリストアップされた他のプレイヤの情報を確認し、仲間申請したいと思うプレイヤを見つけることになる。また、この仲間候補リスト画面で、例えばプレイヤ名のハイパーリンク111aを選択する操作がなされれば、ゲームサーバ1が当該操作に応答し、当該プレイヤ名のプレイヤについてのより詳細なゲーム情報(例えば、リーダーの選手カード113の能力値など)を表示する画面データを端末装置3へ送信する。この画面データには、仲間申請ボタンやエールボタン(またはそれらのハイパーリンク)も含まれており、プレイヤは端末装置3を操作して仲間申請やメッセージの送信ができるようになっている。
ここで、画面に表示されるアクセス頻度114の情報としては、例えば、アクセス平均算出手段56が算出したプレイヤのアクセス平均(例えば直近7日間のアクセス平均)の値とすることができる。本実施の形態では、図9(a)に例示するように、アクセス管理手段55のアクセス情報記憶部55aが、アクセス平均算出手段56により算出された1週前〜n週前の各週のアクセス平均を、プレイヤID毎に記憶しているので、この1週前のアクセス平均を画面に表示されるアクセス頻度114の情報としてもよい。または、1週前〜n週前の複数の週のアクセス平均を列挙して表示してもよい。
画面に表示されるアクセス頻度114の情報は、上記の例に限定されるものではなく、例えば、直近n日間のアクセス平均、先週のアクセス平均、先月のアクセス平均、直近n日間の合計アクセス回数、先週の合計アクセス回数、先月の合計アクセス回数など、プレイヤの過去のアクセス頻度が分かる情報であればよい。あるいは、アクセス頻度114の情報を多段階表示、例えばA〜Cの3段階(A:アクセスが多い、B:アクセスが普通、C:アクセスが少ない)で表示してもよい。
このように、本実施の形態では、プレイヤが仲間を作ろうとするときに端末装置3の表示部35に表示される仲間候補リスト画面において、リストアップされる各プレイヤの過去のアクセス頻度を表示する。これにより、プレイヤは、画面上で他のプレイヤのアクセス頻度を見て、仲間を作るときの一つの目安とすることができる。すなわち、本実施の形態では、仲間アクセス平均に基づく特典を得てゲームを有利に運ぶためには、仲間のアクセス頻度が高いことが望まれるので、アクセス頻度が仲間を作るときの一つの目安となるのである。
なお、仲間候補リスト画面には、アクセス頻度の情報以外にも、各プレイヤのレベルや能力を表す情報(プレイヤレベルや所属リーグのレベルなど)も併せて表示されるところ、上記の構成によれば、プレイヤは、他のプレイヤを仲間にするか否を判断する際に、当該プレイヤのレベルや能力等のみならず、アクセス頻度も考慮し、これらを総合的に判断して、仲間にしたい他のプレイヤを選ぶことができる。
また、仲間申請を受けたプレイヤにおいても、当該プレイヤの端末装置3の図示しない画面には、仲間申請をしたプレイヤの情報の一つとしてアクセス頻度が表示されるようになっており、当該アクセス頻度を、仲間申請を承認するか否かを判断する際の一つの目安とすることもできる。
他のプレイヤのアクセス頻度が表示される画面の他の例としては、図27に示すような仲間リスト画面が挙げられる。上述したように仲間リスト画面には、プレイヤと仲間関係にある仲間プレイヤの情報がリストアップされて表示される。この仲間リスト画面には、仲間プレイヤのゲーム情報81(プレイヤ名、チーム名、プレイヤのレベル、仲間の人数、所属リーグのレベル等)、アバター82、所有するリーダーの選手カード83、エールボタン84等とともに、当該仲間プレイヤのアクセス頻度114が表示される。このアクセス頻度114は、前述したとおり、プレイヤの過去のアクセス頻度が分かる情報であればよく、例えばプレイヤの先週のアクセス平均である。
このように、仲間リスト画面に仲間プレイヤのアクセス頻度114が表示されることにより、以下のような利用も可能になる。すなわち、例えば月曜日に、プレイヤに仲間アクセス平均と全体アクセス平均との比較結果(特典やデメリットの発生)が報知された結果、当該プレイヤの仲間アクセス平均が全体アクセス平均を下回っていたことが判明した場合、プレイヤは、その原因を画面上で確認することができる。つまり、仲間全員のアクセス頻度が低かったのか、それとも一部の仲間プレイヤだけがほとんどアクセスせず、足を引っ張ったのかの原因分析を、各仲間プレイヤのアクセス頻度114から容易に行うことができる。よって、例えば、一部の仲間プレイヤのアクセス頻度が低いことが原因で仲間アクセス平均が低かったことが判明した場合、プレイヤは、当該アクセス頻度が低い仲間に対し応援メッセージ等を送付し、次回以降、当該プレイヤのアクセス頻度を上げるように仕向けることができる。この結果、次回以降の仲間アクセス平均を効果的に上げることができる。
ここで、各仲間プレイヤのアクセス頻度114に基づく前記の原因分析をさらに容易化するために、アクセス頻度の低い方(または高い方)から順に仲間プレイヤの画面上の表示順序を並べかえるための表示順変更ボタン(その他の選択可能なオブジェクトであってもよい)を、プレイヤの端末装置3に表示してもよい。この表示順変更ボタンを選択する操作がプレイヤの端末装置3においてなされた場合、当該操作に応じてゲームサーバ1が、アクセス頻度の低い方(または高い方)から順に仲間プレイヤを並び替えた画面データを端末装置3へ送信する。この画面データを受信した端末装置3にはアクセス頻度順に並べられた仲間プレイヤが表示されるので、プレイヤは、アクセス頻度の低かった仲間プレイヤを迅速に把握でき、当該仲間プレイヤに対して即座に応援メッセージ等の送付ができるようになる。
〔ゲーム制御装置のさらに他の構成例〕
次に、ゲーム管理装置のさらに他の構成例を、図28の機能ブロック図を参照しながら説明する。なお、既出の図面(図1〜図27)において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。
本実施の形態では、プレイヤの仲間の一部または全部の仲間登録を、当該プレイヤの意思に基づいて解除することができるようになっているゲームシステムについて説明する。特典を得るためにはプレイヤの仲間アクセス平均が高いことが望まれるが、プレイヤが仲間登録を自由に解除できる場合、アクセス頻度の低い仲間プレイヤに応援メッセージを送って仲間のアクセス向上を目指すのではなく、アクセス頻度の低い仲間プレイヤの仲間登録を解除することによって仲間アクセス平均(グループの評価値)の向上を図ろうとする、本来の目的とはかけ離れた方法を採ろうとするプレイヤが出てくる可能性も考えられる。そこで、この対策として、本実施の形態では、以下に説明するように、プレイヤが仲間登録を解除した場合、当該解除から一定期間、本来得られる特典を小さくする又は特典そのものを付与され難くする構成を採用するものである。
図28に示すように、本実施の形態のゲームサーバ1(ゲーム管理装置)は、図4に示した各手段51〜61に加えて、特典付与調整手段121をさらに備えている。また、本実施の形態の仲間管理手段53は、仲間登録解除手段122をさらに備えている。前記の特典付与調整手段121および仲間登録解除手段122は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。
前記の仲間登録解除手段122は、各プレイヤから仲間登録の解除を受け付ける機能を有する。この仲間登録解除手段122の動作例を以下に示す。
例えば、プレイヤA(プレイヤID=“000001”)が端末装置3を操作し、仲間プレイヤB(プレイヤID=“000002”)の登録を解除する操作を行ったとき、当該操作に応じた通信データ(リクエスト)がゲームサーバ1へ送信される。この通信データを受信したゲームサーバ1では、仲間登録解除手段122が、プレイヤAおよびプレイヤB相互間の仲間登録を解除する。
すなわち、仲間情報記憶部53aが記憶している、図29(a)に例示するプレイヤ毎の仲間情報について、仲間登録解除手段122は、プレイヤAのプレイヤID=“000001”と対応づけて記憶されている仲間プレイヤIDの情報欄から、プレイヤBのプレイヤID=“000002”を削除する(同図中では、便宜上、二重取り消し線でこれを示している)。さらに、仲間登録解除手段122は、プレイヤAのプレイヤID=“000001”と対応づけて、仲間登録解除情報を記録する。ここで記録される仲間登録解除情報とは、解除相手であるプレイヤBのプレイヤID=“000002”、解除日及び解除者フラグの情報等である。解除者フラグとは、例えば仲間登録を解除した側を「1」、解除された側を「0」として、両者を区別するための情報である。図29(a)の例では、プレイヤAが仲間登録を解除した側であるため、解除者フラグ=1が設定されている。
さらに、図29(b)に示すように、仲間登録解除手段122は、プレイヤBのプレイヤID=“000002”と対応づけて記憶されている仲間プレイヤIDの情報記憶欄からも、プレイヤAのプレイヤID=“000001”を削除する(同図中では、便宜上、二重取り消し線でこれを示している)。さらに、仲間登録解除手段122は、プレイヤBのプレイヤID=“000002”と対応づけて、仲間登録解除情報を記録する。この場合に記録される仲間登録解除情報は、解除相手であるプレイヤAのプレイヤID=“000001”、解除日および解除者フラグ=0等の情報である。
ゲームサーバ1は、上記の仲間登録解除処理後、仲間登録を解除された側のプレイヤBの端末装置3がゲームサーバ1にアクセスしたとき、プレイヤAから仲間登録が解除された旨を通知する。また、ゲームサーバ1は、プレイヤによる仲間登録の解除が安易に行われないようにするために、仲間登録を解除した側のプレイヤAに対して、例えば所有ポイントを削減する等のペナルティを科してもよい。
次に、特典付与調整手段121について説明する。この特典付与調整手段121は、仲間登録の解除をしたプレイヤに対して、当該仲間登録の解除から所定期間、当該仲間登録の解除がない場合に比べて発生する特典を小さくする又は特典が付与され難くすることによって、特典の付与調整を行う機能を有する。この特典付与調整手段121を備えたゲームサーバ1の処理例を、図30のフローチャートに示す。
図30において、S51〜S55については、基本的には図17のフローチャートで説明した処理と同様の処理である。ゲームサーバ1は、全体アクセス平均AVAtの算出(S53)や仲間アクセス平均AVAgの算出(S55)の処理後、プレイヤが所定期間内、例えば直近の4週間以内に仲間登録の解除を行っているか否かを判断する(S100)。このS100の判断は、例えば図29(a)に示すように、仲間管理手段53が管理する各プレイヤの仲間登録解除情報(解除日及び解除者フラグ)に基づいて行うことができる。すなわち、4週間以内に仲間登録の解除を行っているプレイヤとは、当該プレイヤのプレイヤIDに対応付けられた仲間登録解除情報として、4週間以内の解除日および解除者フラグ=1の情報を有するプレイヤである。
プレイヤが4週間以内に仲間登録の解除を行っている場合(S100でYES)、特典付与調整手段121は、例えば、S53で算出された全体アクセス平均AVAtの値に0.1を加算した値を全体アクセス平均AVAtとみなし(S101)、以降の処理(S56〜S61)を行う。すなわち、仲間アクセス平均AVAgと比較される基準値である全体アクセス平均AVAtの値を、本来の算出値よりも高くすることにより、仲間登録を解除したプレイヤに対して特典が発生し難くしている(逆にデメリットが発生し易くしている)。一方、プレイヤが4週間以内に仲間登録の解除を行っていない場合(S100でNO)、前記S101に移行することなく、S56に移行する。すなわち、仲間アクセス平均AVAgと比較される基準値として、S53で算出された全体アクセス平均AVAtの値がそのまま使用され、特典の付与調整がされることはない。なお、以降の処理(S56〜S61)は、基本的には図17のフローチャートで説明した処理と同様の処理であり、その説明を省略する。
この図30に示した処理により、仲間登録の解除をしたプレイヤは、仲間登録の解除から4週間、仲間登録の解除がない場合に比べて特典が付与され難くなる。これにより、アクセス頻度の低い仲間プレイヤの仲間登録を解除することによって仲間アクセス平均を高めようとしても、仲間登録を解除したことによって、一定期間(この例では4週間)特典が得られ難くなる。よって、仲間アクセス平均を高めるために仲間登録を解除するといった、本来の目的とはかけ離れた行動をプレイヤがとることを効果的に抑制できる。
また、特典付与調整手段121を備えたゲームサーバ1の他の処理例を、図31のフローチャートを参照して、以下に説明する。
図31において、S51〜S57については、基本的には図17のフローチャートで説明した処理と同様の処理である。仲間アクセス平均AVAgと全体アクセス平均AVAtとを比較した結果、仲間アクセス平均AVAgの方が全体アクセス平均AVAtよりも大きいとき(S56でYES)、ゲーム情報変更手段59が、ゲーム上有利になるようにプレイヤのゲーム情報を変更し(S57)、これによって当該プレイヤに特典を付与する。例えば、対戦3回分有利の特典をプレイヤに付与する。そして、ゲームサーバ1の特典付与調整手段121は、プレイヤが所定期間内、例えば直近の4週間以内に仲間登録の解除を行っているか否かを判断する(S110)。ここで、プレイヤが4週間以内に仲間登録の解除を行っている場合(S110でYES)、特典付与調整手段121は、プレイヤに付与される特典を、前記S57で付与される特典(対戦3回分有利)よりも縮小して、例えば対戦1回分有利の特典へと調整する(S111)。なお、以降の処理(S58〜S61)は、基本的には図17のフローチャートで説明した処理と同様の処理であり、その説明を省略する。
この図31に示した処理により、仲間登録の解除をしたプレイヤは、仲間登録の解除から4週間、仲間登録の解除がない場合に比べて特典が縮小される。これにより、アクセス頻度の低い仲間プレイヤの仲間登録を解除することによって仲間アクセス平均を高めようとしても、仲間登録を解除したことによって、一定期間(この例では4週間)、本来得られるはずの特典よりも小さい特典しか得られなくなる。よって、仲間アクセス平均を高めるために仲間登録を解除するといった、本来の目的とはかけ離れた行動をプレイヤがとることを効果的に抑制できる。
なお、図30および図31に示した上記の例では、仲間登録の解除から4週間を、仲間登録を解除したペナルティの期間として、特典そのものを付与され難くする又は本来の特典よりも小さい特典を付与することにより特典の付与調整をしているが、これに限定されるものではなく、例えば、当該期間を1週間〜3週間程度に短縮してもよいし、逆に4週間よりも長く設定してもよく、任意の期間を設定可能である。
また、上記の例では、所定期間内に1人でも仲間登録の解除を行えば、特典付与調整手段121による特典の付与調整が行われる例について説明したが、これに限定されるものではなく、例えば、所定期間内にn人以上(例えば1週間以内に2人以上)の仲間登録を解除した場合にのみ特典の付与調整が行われるようにしてもよい。
ところで、プレイヤがアクセス頻度の低い仲間プレイヤに応援メッセージを送って仲間のアクセスを高める努力をしたにもかかわらず、当該仲間プレイヤのアクセス頻度が低いままであるため、やむなく仲間登録を解除する場合もあり得る。そこで、プレイヤが仲間登録を解除する場合でも、メッセージを所定回数送信したにも関わらずアクセス頻度が低いままの仲間プレイヤを仲間から外す場合と、そのようなメッセージの送信もなく仲間登録を解除する場合とでは、その効果を異ならせることが望ましい。
そこで、本実施の形態に係るゲームサーバ1の特典付与調整手段121は、仲間登録の解除をしたプレイヤが、当該仲間登録の解除前の所定期間中(例えば、解除前の2週間以内)に、解除対象の仲間プレイヤ宛に所定回数以上(例えば2回以上)のメッセージを送信している場合は、前記の特典の付与調整を行わないように構成されている。このように構成された典付与調整手段121を備えたゲームサーバ1の処理例を、図32のフローチャートに示す。
図32において、S51〜S55については、基本的には図17のフローチャートで説明した処理と同様の処理である。ゲームサーバ1は、全体アクセス平均AVAtの算出(S53)や仲間アクセス平均AVAgの算出(S55)の処理後、プレイヤが所定期間内、例えば直近の4週間以内に仲間登録の解除を行っているか否かを判断する(S120)。このS120の処理は、基本的に図30のS100と同様の処理である。ここで、プレイヤが4週間以内に仲間登録の解除を行っている場合(S120でYES)、特典付与調整手段121は、仲間登録の解除をしたプレイヤが、例えばその解除前の2週間以内に2回以上、解除対象の仲間プレイヤ宛にメッセージを送信しているか否かを判断する(S121)。
前記S121における判断には、仲間管理手段53の仲間情報記憶部53aが記憶している、例えば図29(a)に示す各プレイヤの仲間登録解除情報(各プレイヤのプレイヤIDと対応付けて記憶されている、解除相手プレイヤID、解除日及び解除者フラグ)、およびメッセージ伝達手段61のメッセージ記憶部61aが記憶している、例えば図13に示すメッセージに関する情報(受信側プレイヤのプレイヤIDと対応付けて記憶されている、送信元のプレイヤIDおよび送信日時などの情報)が用いられる。すなわち、プレイヤが仲間登録を解除した「解除対象の仲間プレイヤ」については、図29(a)に示す仲間登録解除情報の中の「解除相手プレイヤID」として特定できる。また、「解除前の2週間以内の期間」については、前記の仲間登録解除情報の中の「解除日」に基づいて特定できる。また、「解除対象の仲間プレイヤ宛に仲間登録を解除した側のプレイヤがメッセージを送信したか否か」については、図13に示す「受信側プレイヤID」を解除相手プレイヤIDとした場合における、「送信元プレイヤID」として、仲間登録の解除をした側のプレイヤのプレイヤIDが含まれているか否かを確認することにより判断できる。また、前記の「送信元プレイヤID」とともに「送信日時」の情報も併せて記憶されているので、仲間登録の解除をしたプレイヤから解除対象の仲間プレイヤへのメッセージが、解除前の2週間以内に送信されたものか否かが判断できる。
このS121において、仲間登録の解除をしたプレイヤが、その解除前2週間以内に2回以上、解除対象の仲間プレイヤ宛にメッセージを送信していなかった場合(S121でNO)、特典付与調整手段121は、例えば、S53で算出された全体アクセス平均AVAtの値に0.1を加算した値を全体アクセス平均AVAtとみなし(S122)、以降の処理(S56〜S61)を行う。すなわち、仲間アクセス平均AVAgと比較される基準値である全体アクセス平均AVAtの値を、本来の算出値よりも高くすることにより、仲間登録を解除したプレイヤに対して特典を発生し難くし、逆にデメリットを発生し易くしている。
一方、仲間登録の解除をしたプレイヤが、その解除前2週間以内に2回以上、解除対象の仲間プレイヤ宛にメッセージを送信していた場合(S121でYES)、ゲームサーバ1は、前記S122に移行することなく、S56に移行する。すなわち、仲間アクセス平均AVAgと比較される基準値として、S53で算出された全体アクセス平均AVAtがそのまま使用され、特典の付与調整がされることはない。また、プレイヤが4週間以内に仲間登録の解除を行っていない場合も(S120でNO)、前記S122を経由することなくS56に移行するので、特典の付与調整がされることはない。なお、以降の処理(S56〜S61)は、基本的には図17のフローチャートで説明した処理と同様の処理であり、その説明を省略する。
この図32に示した処理により、仲間登録の解除をしたプレイヤは、原則、仲間登録の解除から4週間、仲間登録の解除がない場合に比べて特典が付与され難くなるが、例外として仲間登録の解除前2週間以内に2回以上、解除対象の仲間プレイヤへメッセージを送信している場合は、特典が付与され難くなることはない。これにより、仲間登録を解除したプレイヤに対して、その解除前に応援メッセージを送って仲間のアクセスを高める努力をしたプレイヤが、特典の付与調整(特典を付与され難くする又は特典を小さくする処理)の対象となることを回避できる。よって、応援メッセージを仲間に送付して仲間のアクセスを高めようとすることもなく、仲間アクセス平均を高めるためにアクセス頻度の低い仲間プレイヤの仲間登録を解除するプレイヤのみを対象とした効果的な対策を講じることができ、そのような本来の目的とはかけ離れた行動をプレイヤがとることをより効果的に抑制できる。
なお、図32に示した例では、仲間登録の解除をしたプレイヤが、その解除前2週間以内に2回以上、解除対象の仲間プレイヤ宛にメッセージを送信していることを、特典の付与調整が行われない条件としているが、これに限定されるものではない。例えば、仲間登録解除前のメッセージの送信条件(特典の付与調整が行われないための条件)を、解除前1週間以内に1回以上に設定したり、あるいは解除前1か月以内に3回以上に設定したりしてもよく、仲間登録解除前の期間および当該期間中のメッセージ送信回数の条件については、任意に設定することができる。
〔他の実施の形態〕
上述の実施の形態では、グループの評価値として仲間アクセス平均を適用した例を説明したが、上述のようにグループの評価値はこれに限定されるものではなく、例えば、グループに所属する仲間プレイヤのアクセス頻度の合計値としてもよいし、グループに所属する仲間プレイヤの中のアクセス頻度の最大値または最小値としてもよい。グループの評価値を上記のような合計値、最大値または最小値とする場合、例えば、アクセス平均算出手段56が算出した各仲間プレイヤのアクセス平均を、アクセス頻度を示す値として用いて、グループ内の仲間プレイヤのアクセス平均の合計値、最大値または最小値を求めることによりグループの評価値を算出できる。
グループの評価値として上記の最大値または最小値を適用した場合、グループ内の一人のアクセス頻度がグループを代表する値となるのに対して、仲間アクセス平均または合計値をグループの評価値とした場合には、グループ内の全員のアクセス頻度が評価値として反映されることになることから、仲間アクセス平均または合計値をグループの評価値とする方が好ましいといえる。すなわち、グループの評価値をグループ内のアクセス頻度の最大値とした場合を考えると、グループ内にアクセス頻度の高くないプレイヤが多数存在したとしても、グループ内にアクセス頻度の高い仲間プレイヤが一人でも存在すれば、グループの評価値としては高くなってしまう。この場合、プレイヤは自分の仲間全体のアクセス頻度を高めようとするのではなく、普段よりアクセス頻度が比較的高い特定の仲間プレイヤ数人のみに対して応援アクセスを働きかけることによりグループの評価値を高めようとする可能性がある。これに対して、グループの評価値をグループ内のアクセス頻度の平均値(仲間アクセス平均)または合計値とすることにより、評価値を高めるためにはグループ内の多くの仲間プレイヤのアクセス頻度を高める必要が生じるので、プレイヤにグループ内の多くの仲間プレイヤとコミュニケーションを図ろうとする動機付けを与えることができる。
また、グループの評価値として上記の合計値を適用した場合、仲間の人数(グループの人数)が多くなるほど合計値も大きくなる傾向にあるので、グループ内の各仲間プレイヤのアクセス頻度としてはそれ程高くなくとも、グループの人数が多ければ、結果的にグループの評価値が高くなることもある。これに対して、グループの評価値をグループ内のアクセス頻度の平均値(仲間アクセス平均)とすることにより、グループ内の仲間プレイヤの人数等にかかわらずに仲間全員のアクセス頻度の高さが的確に評価値として反映されるので、仲間アクセス平均をグループの評価値とすることがより好ましいといえる。
また、グループの評価値として上記の合計値を適用する場合、グループに所属する仲間プレイヤの人数が多い程、評価値と比較される基準値(閾値)を高くすることが望ましい。これにより、単純に仲間の人数を増やしただけでは特典を獲得する(又はデメリットを回避する)ための条件を満たせなくなり、評価値を高めるためには仲間全体のアクセス頻度を高める必要が生じるので、プレイヤにグループ内の多くの仲間プレイヤとコミュニケーションを図ろうとする動機付けを与えることができる。
また、上述の実施の形態では、各プレイヤの仲間アクセス平均(グループの評価値)と比較される基準値を、全体アクセス平均算出手段58(全体平均算出手段)が算出する全体アクセス平均とした例について説明したが、ゲームサーバ1が管理している全グループを対象としたグループの評価値の平均値を、各プレイヤのグループの評価値と比較される基準値とすることもできる。この場合、ゲームサーバ1の全体平均算出手段が、全グループの評価値の合計をグループ数で割って全体の平均値を算出し、この算出値を基準値とするのである。ここで、ゲームサーバ1が管理している全グループとは、原則、仲間を作っている(すなわち仲間というグループが存在する)プレイヤを中心としたグループの全てをいい、仲間を1人以上作っているプレイヤの人数と同じ数だけグループが存在する。ただし、上述のようにグループの評価値算出の時間的な条件を満たさないプレイヤ(例えば、直近7日間を評価値算出の対象期間とした場合は、ゲームサービスの利用開始から7日を経過していない新規参入のプレイヤ等)を評価値の算出から除外したことによって、グループの評価値が算出できなかったプレイヤのグループについては、除外してもよい。
例えば、グループの評価値としてグループに所属する仲間プレイヤのアクセス頻度の合計値(以下、グループ合計値と称する)を適用した場合、全グループのグループ合計値の総計をグループ数で割った数値を基準値とし、当該基準値と各プレイヤのグループ合計値とを比較し、特典またはデメリットの発生の有無を判断することができる。グループの評価値として上述の平均値(仲間アクセス平均)、最大値、最小値等を適用した場合も同様である。
また、上述の実施の形態では、ゲーム実行プログラムがゲームサーバ1側に実装されており、各プレイヤの端末装置3における入力操作に応じて、ゲームサーバ1がゲーム進行のための演算処理やデータ処理を実行し、その実行結果を反映させた画面データを端末装置3へ送信することによって、ゲームが進行するゲームシステムへの適用例について説明したが、これに限定されるものではない。例えば、ゲームサーバ1が、プレイヤのアクセス情報、仲間情報、メッセージ情報、特典情報などのゲーム情報を管理し、ゲーム内でのプレイヤ間のメッセージのやり取りや特典付与等のゲームサービスをプレイヤに提供する一方、ゲームを進行させるゲーム実行処理については、基本的にはプレイヤの端末装置側にて行われるゲームシステムにも本発明を適用できる。
すなわち、ゲーム実行プログラムの一部または全部をプレイヤの端末装置側にダウンロードまたはインストールし、端末装置においてもゲーム実行処理が行われるようなゲームシステムにも本発明を適用できる。よって、プレイヤの端末装置としては、ネットワーク経由でゲームサーバ(ゲーム管理装置)に接続してゲームサービスの提供を受けることができる様々なものが適用でき、前述の携帯電話端末、PHS端末、携帯情報端末(PDA)、スマートフォン、パーソナルコンピュータ、タブレット型コンピュータ以外にも、ネットワーク接続機能を有している家庭用ビデオゲーム装置(家庭用ビデオゲーム機を家庭用テレビジョンに接続することによって構成されるゲーム装置)や、携帯型のゲーム専用装置なども適用可能である。
また、本実施の形態に係るコンピュータ読み取り可能なプログラムは、ハードディスク、光ディスク(CD−ROM、DVD−ROM等)、フレキシブルディスク、半導体メモリ等のコンピュータ読み取り可能な各種記録媒体に記録され、当該記録媒体から読み出されてゲームサーバ1のCPU11により実行される。また、プログラムをゲームサーバ1に提供する手段は、前述した記録媒体に限定されるものではなく、インターネット等の通信ネットワークを介して行うこともできる。