以下、本発明の一実施の形態に係るゲーム管理装置、ゲーム管理方法及びプログラムについて、図面を参照しながら説明する。
〔ゲームシステムの概要〕
本発明の一実施の形態に係るゲーム管理装置が組み込まれたゲームシステムの構成例を、図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日(24時間)に限定されるものではなく、例えば現実世界の半日(12時間)や2日等であってもよく、任意の期間を設定可能である。また、連続した規定期間数(単位期間の連続数)も任意に設定可能である。例えば、単位期間を現実世界の1日とするとともに、連続した規定期間数を10とした場合、10日間の連続アクセスを達成したプレイヤに、連続アクセス達成特典を付与する。また、例えば、半日を単位期間とするとともに、連続した規定期間数を10とした場合、一日のうち午前(0時から12時まで)と午後(12時から24時まで)に最低1回ずつゲームサーバ1へアクセスすることを5日間連続して達成したプレイヤに、連続アクセス達成特典を付与する。
以下に示す実施の形態では、単位期間を現実世界の1日とするとともに、連続した規定期間数を5とし、5日間の連続アクセスを達成したプレイヤに連続アクセス達成特典を付与する例について説明する。
本ゲームサーバ1は、本来、5日間の連続アクセスを達成しなければプレイヤに付与されないはずの特典を、ある条件下であれば、5日間の連続アクセスを達成できなかったプレイヤにも付与する。すなわち、本ゲームサーバ1は、連続した5日間の中にアクセスの欠落日(欠落単位期間)が存在することによりプレイヤが5日間の連続アクセスを達成できなかった場合であっても、当該プレイヤの仲間が所定の応援アクセス条件を満たしているとき、当該欠落日がないものとして(すなわち、当該欠落日にもプレイヤがゲームにアクセスしたとみなして)、5日間連続アクセスの特典を付与するという特徴的な構成を有する。具体例としては、プレイヤが何かの用で1日、ゲームサーバ1にアクセスできなかったとしても、当該プレイヤの仲間が応援アクセス条件(例えば、アクセスできなかった欠落日と同じ日に仲間の80%以上がゲームサーバ1にアクセスしているという条件)を満たしていれば、当該1日の欠落日をないものとし、この欠落日の埋め合わせを含めて5日間の連続アクセスを達成しているならば、当該プレイヤには連続アクセスの特典が付与されるのである。なお、プレイヤの仲間の応援アクセス条件、特典の具体例などについては後述する。
この本実施の形態の特徴的な構成によって、プレイヤの仲間が応援アクセス条件を満たすような高いアクセス頻度を維持してくれることによりプレイヤ自身にメリットがあり、逆にプレイヤ自身も高いアクセス頻度を維持すれば他の仲間を間接的に支援できることになる。これにより、各プレイヤは、仲間同士でお互いにアクセス頻度を高めようという意識付け、動機付けを与えられることになる。そして、各プレイヤは、仲間全体のゲームへのアクセス(ゲームサーバ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を備えている。これらの各手段51〜59は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。
ゲーム情報管理手段51は、各プレイヤのゲーム情報をデータベースサーバ2に蓄積して管理する。ゲーム情報管理手段51で管理されるゲーム情報の項目は、本ゲームサーバ1がプレイヤに提供するゲームサービスの内容によって異なる。
本ゲームサーバ1によって提供されるゲームの例としては、野球、サッカー、ゴルフなどの各種スポーツを題材としたスポーツゲーム、戦闘を題材とした戦闘ゲーム、音楽シミュレーションゲーム、その他種々のロールプレイングゲーム・育成ゲーム・シミュレーションゲームといったように、ゲーム形式・ジャンルを問わず様々なゲームを挙げることができる。その一例として、本実施の形態では、ゲームサーバ1がゲームサービスとして野球ゲームを提供する場合について、以下に説明する。
本実施の形態では、プレイヤがゲーム内において選手キャラクタを所有し、当該選手キャラクタを用いてゲーム内で他のプレイヤと試合(対戦)を行うことができる野球ゲームを例に挙げる。プレイヤが所有する選手キャラクタは、当該選手キャラクタの形態を端末装置3の画面上で視認可能としたカード形式とすることができる。すなわち、選手キャラクタは、デジタル選手カードとしてゲームサーバ1で管理されるとともに、プレイヤの端末装置3の画面に表示される。図10(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の所定の記憶領域に記憶する。本実施の形態における特典は、上述のように5日間連続アクセスを達成したプレイヤに対して付与される。ここで特典を付与するとは、特典の付与前と比較してゲーム上有利な状態(メリット発生状態)にすることであり、図6では、ボーナスポイント(この例では200ポイント分の強化ポイント)が特典としてプレイヤに付与された例を示している。この特典の詳細は後述する。
次に、図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(記憶装置)に記憶して、プレイヤ毎の仲間管理を行う機能を有する。なお、ここでいうグループとは、あくまで1プレイヤの視点から見た自分の仲間の集団を示しており、これらの集団を構成する各プレイヤがこの集団のみに所属するわけではない。各プレイヤもまた、個々に自分を中心とする「仲間」のグループを有している。この仲間管理手段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(記憶装置)に記憶してプレイヤ毎のアクセスを管理する。ここで、アクセスの情報とは、各プレイヤのアクセス履歴(アクセスの日時等)、現実世界の1日のアクセス回数、現実世界の各日のアクセスの有無等の情報である。
このアクセス管理手段55は、所定の単位期間毎のゲームサーバ1へのアクセスの有無をプレイヤ毎に管理する機能を有する。この所定の単位期間毎のアクセスの有無の管理情報は、連続した規定期間数の単位期間の全てについてアクセスを行った連続アクセス達成のプレイヤに対して連続アクセス特典を付与する連続アクセス特典付与手段57における連続アクセス達成の判定に用いられる。本実施の形態では、アクセス管理手段55が所定の単位期間毎のアクセスの有無をプレイヤ毎に管理するようにしているが、アクセス管理手段55では各プレイヤのアクセスの日時等のみを記憶したアクセス管理にとどめ、連続アクセス特典付与手段57にて所定の単位期間毎のアクセスの有無を判断するようにしてもよい。
以下の説明では、本実施の形態のアクセス管理手段55が、現実世界における1日を単位期間とし、各日のゲームサーバ1へのアクセスの有無(1日に少なくとも1回以上のアクセスを行なったか否か)を、プレイヤ毎に管理する例について説明する。
図9(a)には、アクセス情報記憶部55aがデータベースサーバ2に記憶して管理する、各プレイヤのアクセス情報の一例を示している。アクセス情報記憶部55aは、プレイヤIDと対応付けて、現実世界における本日、1日前、2日前、3日前、4日前、・・・、n日前(本実施の形態の場合、nは5以上の自然数)の各日についてのゲームサーバ1へのアクセスの有無(単位期間内アクセスを達成したか否か)を示す情報を、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。この情報が「1」の場合、1日に最低1回はゲームサーバ1へのアクセスがあったことを示す一方、この情報が「0」の場合、1日に1回もゲームサーバ1へのアクセスがなかったことを示している。本実施の形態の例では5日間連続アクセスにより特典が付与されるので、少なくとも前日までの直近5日間のアクセスの有無を示す情報が記憶されていればよい。
なお、アクセス情報記憶部55aが記憶するアクセス情報は、図9(a)の例に限定されるものではなく、例えば、図9(b)に示すように、現実世界における本日、1日前、2日前、・・・n日前の各日についてのゲームサーバ1へのアクセス回数であってもよい。このアクセス回数の情報は、当該情報が「0」であるか否かにより、単位期間内アクセス(本実施の形態では1日に最低1回のアクセス)を達成したか否かを管理するための情報となる。
また、アクセス情報記憶部55aは、プレイヤIDと対応付けて、プレイヤの仲間が応援アクセス条件を満たしたか否かを示す情報を、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。この情報は、後述する仲間応援アクセス判定手段56による判定結果を示す情報である。
さらに、アクセス情報記憶部55aは、プレイヤIDと対応付けて、プレイヤがゲームサーバ1へアクセスした連続日数である連続アクセス日数も、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。この連続アクセス日数は、プレイヤがゲームサーバ1へアクセスした日、およびアクセスしたとみなされた日(プレイヤがアクセスしなかった欠落日と同じ日にプレイヤの仲間が応援アクセス条件を満たしたことによってアクセスしたとみなされた日)の連続日数をカウントしたものである。この連続アクセス日数は、プレイヤによる連続アクセス(アクセスしたとみなされた場合を含む)が途絶えたとき、および5日間の連続アクセス達成によりプレイヤに特典が付与されたときに初期化(リセット)される。
連続5日間のうち埋め合わせ可能な欠落日を例えば1日のみとした場合、1日目の欠落日に対する応援アクセス条件が満たされたことによって連続アクセスの継続状態が維持されたとしても、その後2日目の欠落日が確定したとき、前記の連続アクセス日数は初期化される。すなわち、埋め合わせ可能な欠落日をn日とした場合、(n+1)日目の欠落日が確定したときには、その時点で連続アクセスが途切れることになり、連続アクセス日数が初期化される。
埋め合わせ可能な欠落日の日数については、任意に設定することができる。ただし、埋め合わせ可能な欠落日を多く許容し過ぎると、プレイヤ自身が実際にはあまりゲームサーバ1へアクセスしていなくとも、欠落日が埋め合わされて連続アクセス達成特典を獲得してしまう可能性もあることから、埋め合わせ可能な欠落日には上限を設けることが望ましい。本実施の形態では、先ず、埋め合わせ可能な欠落日を1日に限定した例について、以下に説明し、埋め合わせ可能な欠落日を複数許容する場合については後述する。
次に、仲間応援アクセス判定手段56について説明する。仲間応援アクセス判定手段56は、連続した5日間のうちゲームサーバ1へアクセスをしなかった欠落日が存在するプレイヤについて、当該プレイヤの仲間プレイヤが所定の応援アクセス条件を満たしているか否かを判定する機能を有する。
ここで、応援アクセス条件としては、様々な任意の条件を設定可能である。応援アクセス条件の一例としては、「欠落日と同一の日に、ゲームサーバ1に1回以上アクセスをした仲間プレイヤの当該仲間プレイヤ全体に占める割合が、閾値以上」とすることができる。プレイヤ自身を含む仲間プレイヤがx人、欠落日と同一の日に、ゲームサーバ1に1回以上アクセスをした仲間プレイヤの人数をy人、閾値をzとすると、「y/x≧z」が応援アクセス条件となる。例えば閾値を0.8(百分率で80%)とした場合、プレイヤ自身を含む10人の仲間のうち、8人以上の仲間プレイヤがゲームサーバ1にアクセスしていれば、この応援アクセス条件を満たす。
ここで、前述のように仲間プレイヤとは、各プレイヤを中心とする仲間というグループに所属するプレイヤであり、基本的にはグループの中心をなすプレイヤ自身も仲間プレイヤに含まれる。ただし、プレイヤ自身は欠落日にはアクセスしていないので、当該プレイヤを仲間プレイヤから除外し、欠落日と同一の日にアクセスした仲間プレイヤの割合を算出してもよい。すなわち、「y/(x−1)≧z」を応援アクセス条件としてもよい。
仲間の人数が多いときは、「y/x≧z」または「y/(x−1)≧z」の何れを応援アクセス条件としても大きな違いはないが、仲間の人数が少なくなればその違いが顕著になる。例えば、プレイヤ自身を含む仲間プレイヤxが4人で閾値z=0.8とした場合を考えると、「y/x≧z」を条件としたとき、プレイヤ自身はアクセスしていないので、他の仲間プレイヤ3人が全員アクセスしたとしても、y/x=3/4=0.75となって条件を満たさないことになる。一方、「y/(x−1)≧z」を条件としたとき、プレイヤ自身を除く3人がアクセスすればy/(x−1)=3/3=1.00となって条件を満たしてしまう。すなわち、「y/x≧z」を条件としたとき、プレイヤ自身を含む仲間プレイヤxが4人以下であれば決して条件を満たすことはない一方、「y/(x−1)≧z」を条件としたときには、xが4人以下のときにも僅かな人数の仲間プレイヤのアクセスによって容易に条件を満たすこととなる。「y/x≧z」を条件とすることにより、応援アクセス条件を満たすためにはまず仲間プレイヤxの人数を5人以上にしなければならず、プレイヤは仲間を少なくとも5人以上は作ろうとする動機付けを与えられることになる。また、「y/x≧z」を条件とすることにより、仲間の人数が少ないときに条件を容易に満たせる状態を回避できる。よって、「y/(x−1)≧z」よりも「y/x≧z」を応援アクセス条件とする方が望ましいと言える。
応援アクセス条件の他の例としては、「欠落日と同一の日に、ゲームサーバ1に1回以上アクセスをした仲間プレイヤの人数が、閾値(例えば10人)以上」とすることができる。この応援アクセス条件の場合、プレイヤの仲間の合計人数がそもそも閾値に満たない場合には、当該条件を満たすことはない。よって、プレイヤは応援アクセス条件を満たすように、仲間を少なくとも閾値(例えば10人)以上は作ろうとする動機付けを与えられることになる。また、仲間を多く作る方が応援アクセス条件を満たしやすくなるため、プレイヤは応援アクセス条件をより満たし易くするため、より多くの仲間を作ろうとする動機付けを与えられることになる。なお、応援アクセス条件のさらに他の例については後述する。
仲間応援アクセス判定手段56による応援アクセス条件を満たすか否かの判定処理は、プレイヤによるその日のアクセスの有無が確定する午後12時(24時)以降、すなわちプレイヤの欠落日の翌日の所定時間に行われる。例えば、欠落日の翌日の0時に、仲間応援アクセス判定手段56による判定処理が行われる。
また、仲間応援アクセス判定手段56による判定結果は、図9(a)に示すように、プレイヤの仲間が応援アクセス条件を満たしたか否かを示す1ビットの情報として、当該プレイヤのプレイヤIDと対応付けて記憶される。この情報が「1」の場合、プレイヤの仲間が応援アクセス条件を満たしたことを示す一方、この情報が「0」の場合、当該応援アクセス条件を満たさなかったことを示している。なお、本実施の形態では、連続5日間のうち埋め合わせ可能な欠落日を1日のみとしているので、1日目の欠落日に対してのみ仲間応援アクセス判定手段56による判定処理が行われ、2日目の欠落日に対しては当該判定処理はなされない。プレイヤがアクセスした日(欠落日ではない日)や、欠落日が2日目に該当する場合のように、仲間応援アクセス判定手段56による判定処理が行われない場合も、当該情報は「0」となる。
仲間応援アクセス判定手段56による判定の結果、プレイヤの仲間が応援アクセス条件を満たしている場合、プレイヤによるゲームサーバ1への連続アクセスは継続しているとみなされ、図9(a)に示す「連続アクセス日数」が1つインクリメントされることになる。
次に、連続アクセス特典付与手段57について説明する。連続アクセス特典付与手段57は、5日間の連続アクセスを達成したプレイヤに対して、ゲーム上有利になるように当該プレイヤのゲーム情報を変更して連続アクセス達成特典を付与する機能を有する。さらに、連続アクセス特典付与手段57は、連続5日間の中にゲームサーバ1にアクセスしなかった欠落日が存在するプレイヤについても、当該プレイヤの仲間プレイヤが応援アクセス条件を満たしていると仲間応援アクセス判定手段56が判定した場合には、連続アクセス達成特典を付与するようになっている。
この連続アクセス特典付与手段57は、アクセス情報記憶部55aが記憶する図9(a)の連続アクセス日数の情報に基づいて、プレイヤに連続アクセス達成特典を付与するか否かを判定する特典発生判定部57aを備えている。そして、連続アクセス特典付与手段57は、特典発生判定部57aが連続アクセス達成特典を発生させると判定したプレイヤのゲーム情報(ゲーム情報管理手段51がデータベースサーバ2に記憶して管理しているゲーム情報)を、当該特典の内容に応じて変更する。
ここで、連続アクセス特典付与手段57がプレイヤに付与する連続アクセス達成特典について説明する。この連続アクセス達成特典は、当該特典が付与されなかった場合と比較してゲーム上有利になるものであればよく、ゲームの種類や内容に応じて様々な特典が考えられる。
本実施の形態の野球ゲームにおける連続アクセス達成特典の一例としては、前述の行動力ポイント、運営コスト、強化ポイント、エールポイントなどのプレイヤがゲームを進行させる上で必要となる各種ポイントを、所定ポイント分だけボーナスポイントとしてプレイヤに付与するという特典が挙げられる。このようなボーナスポイントを特典として付与する場合、連続アクセス特典付与手段57は、ゲーム情報管理手段51の特典情報記憶部51iが記憶しているプレイヤの特典に関する情報を、当該ボーナスポイントの内容に合わせて変更する。図6の下部には、プレイヤID=“000001”のプレイヤに特典(ボーナスポイント)が付与された結果、当該プレイヤの特典情報として「強化ポイント=+200」が記憶された例を示している。さらに、連続アクセス特典付与手段57は、ゲーム情報管理手段51の所有ポイント記憶部51dが記憶しているプレイヤの所有ポイントを、ボーナスポイント分だけ増加させるようにゲーム情報を変更する。
連続アクセス達成特典の他の例としては、前述の回復アイテムやフェイクカードなどのゲーム内で有利に使用される各種アイテムを、所定数(例えば3つ)だけプレイヤに付与するという特典も考えられる。ゲーム内で使用されるアイテムを特典として付与する場合、連続アクセス特典付与手段57は、ゲーム情報管理手段51の特典情報記憶部51iが記憶しているプレイヤの特典に関する情報を、当該特典の内容に合わせて変更するとともに、所有アイテム記憶部51fが記憶しているアイテムの所有数を、所定数だけ増加させるようにゲーム情報を変更する。
その他の連続アクセス達成特典の例としては、次のようなものがある。すなわち、ゲーム中に消費されて減った行動力ポイントなどのポイントは、例えば3分経過する毎に1ポイントずつ回復するようになっているが、このポイント回復時間を短縮する(例えば、2分経過する毎に1ポイントずつ回復するようにする)ことが考えられる。この特典が付与される場合、特典情報記憶部51iが記憶しているプレイヤの特典情報として、ポイント回復時間が短縮される有効期間の情報が記憶される。これにより、ゲームサーバ1のゲーム情報管理手段51が、特典が有効な期間(例えば、プレイヤが特典の通知を受けてから24時間以内)において、ポイント回復時間を通常時よりも短縮する処理を行うことになる。
また、前述の選手抽選獲得モードにおいて、レアカード(通常の選手カードよりも抽選確率が低く、希少価値が高い選手カード)が抽選される確率を所定回数(例えば1回)だけ上昇させるという特典も考えられる。この特典が付与される場合、特典情報記憶部51iが記憶しているプレイヤの特典情報として、抽選確率を上昇させる回数が記憶される。そして、ゲームサーバ1のゲーム進行手段52が、特典対象の抽選実行時に、レアカードの抽選確率を一時的に高める処理を行うことになる。
また、選手抽選獲得モードにおいて、通常は選手カードの抽選を実行するのにポイント(前記エールポイント等)を必要とするが、所定回数(例えば1回)だけ無料で(すなわちポイントの消費なしに)、選手カードの抽選を受けることができるという特典も考えられる。この特典が付与される場合、特典情報記憶部51iが記憶しているプレイヤの特典情報として、無料(無ポイント)で選手カードの抽選を受けることができる回数が記憶される。
また、ゲームサーバ1が乱数等により抽選で選んだ選手カードを、所定枚数(例えば1枚)だけプレイヤに付与するという特典も考えられる。ゲームサーバ1が選んだ選手カードを特典としてプレイヤに付与する場合、連続アクセス特典付与手段57は、ゲーム情報管理手段51の特典情報記憶部51iが記憶しているプレイヤの特典に関する情報を、当該特典の内容に合わせて変更するとともに、所有選手カード記憶部51cが記憶している選手カードIDに、特典として付与される選手カードIDを追加する。
また、他のプレイヤのチームと対戦する対戦モードにおいて、対戦n回分(例えば対戦3回分)だけ有利になるというゲーム上のメリットをプレイヤに付与するという特典も考えられる。対戦n回分のゲーム運びを有利にする方法としては、プレイヤのチームの戦力を対戦n回分だけ向上させる方法が考えられる。
ここで、特典によってプレイヤのチームの戦力を向上させる場合にも、幾つかの方法がある。対戦モードにおいては、プレイヤが所有している選手カードの中から試合に出場するレギュラー選手の選手カードが選択されて対戦することになる(例えば、プレイヤは、所有している選手カードの中から予め試合に出場するレギュラー選手のカードを選択しておき、当該レギュラー選手のカードでチームオーダーを組んで対戦する)。よって、当然ながら、通常は、プレイヤの手持ち選手カード以外を自己チームの戦力とすることはできない。
しかし、特典によりチームの戦力を向上させる場合、プレイヤの仲間全員の手持ちカードすべての中で、最強の選手カード(最も能力値が高い選手カード)1枚が、自動的に当該プレイヤのレギュラー選手のカードの1枚と入れ替わるようにする。この場合、ゲームサーバ1のゲーム進行手段52が、特典対象の対戦の実行時に、自動的に上述の選手カードの入れ替え処理を行うことになる。なお、プレイヤの仲間全員の手持ちカードの中で最強の選手カードを当該プレイヤ自らが所有していた場合、当該最強の選手カードよりも能力値が高い助っ人選手カード(ゲームサーバ1が用意する特別な選手カード)1枚が、自動的に当該プレイヤのレギュラー選手のカードの1枚と入れ替わるようにしてもよい。
特典によってプレイヤのチーム戦力を向上させる他の方法としては、対戦モードにおいて試合に出場するレギュラー選手の選手カードの一部または全部の能力値を、所定の割合(または所定の値)だけ向上させるという方法もある。この場合、ゲームサーバ1のゲーム進行手段52が、特典対象の対戦の実行時に、特典を受けたプレイヤのチームの選手カードの能力値を向上させる処理を行なうことになる。
また、対戦n回分のゲーム運びを有利にする他の方法としては、特典が付与されたプレイヤのチームが勝利する確率を対戦n回分だけ向上させる(よって、対戦相手のプレイヤのチームが勝利する確率をその分低下させる)方法も考えられる。例えば、対戦する両プレイヤのチームの能力が同一であったとすると、何れのプレイヤにも特典が付与されていなければ、両チームの勝利確率はともに50%であるが、一方のプレイヤに特典が付与されている対戦においては、特典が付与されたプレイヤXのチームの勝利確率を例えば10%向上させて60%とする一方、その対戦相手のプレイヤYのチームの勝利確率を10%低下させて40%として、プレイヤXの方がプレイヤYよりも勝利確率の面で有利な状態にする。
上述のようにチーム戦力の向上または勝利確率の向上等により対戦n回分が有利になるという特典をプレイヤに付与する場合、ゲーム情報管理手段51の特典情報記憶部51iが記憶しているプレイヤの特典情報として、対戦が有利になる回数が記憶される。
ところで、あまりに特典を大きくしてしまうと、本来ゲームを実行することで実現される選手カードの能力値の向上(すなわち選手の育成)等とのバランスが崩れる可能性もあるため、当該特典は、あくまでサブ的(副次的)な位置づけとして、プレイヤにとってある程度のお得感を与えるレベルとすることが好ましい。
次に、報知手段58について説明する。この報知手段58は、連続アクセス達成特典が付与されたプレイヤの端末装置3に対して、特典が発生した旨を報知する機能を有する。本実施の形態においては、連続アクセス達成特典が発生するタイミングが大きく分けて2つあり、報知手段58による特典の報知処理も、以下に示すように特典の発生タイミングに応じて若干異なる。
連続アクセス達成特典が発生するタイミングの1つは、連続アクセスが達成される最終日(本実施の形態では5日目)にプレイヤがゲームサーバ1にアクセスしたことによって、連続アクセスが達成されたときである。この場合、プレイヤの端末装置3がゲームサーバ1と通信可能に接続されたログイン状態において連続アクセス達成特典が発生するので、報知手段58は、特典の発生後、直ちに特典が発生した旨をプレイヤの端末装置3に報知することができる。
連続アクセス達成特典が発生するもう一つのタイミングは、連続アクセスが達成される最終日(本実施の形態では5日目)にプレイヤがゲームサーバ1にアクセスしなかった(すなわち、当該最終日が欠落日になった)が、当該プレイヤの仲間プレイヤが応援アクセス条件を満たしたことによって連続アクセスが達成されたものとみなされたときである。この場合、プレイヤの端末装置3がゲームサーバ1と通信可能に接続されていない状態において連続アクセス達成特典が発生するので、報知手段58は、特典の発生後、直ちに特典が発生した旨をプレイヤの端末装置3に報知することができないため、特典が発生した旨をプレイヤに報知したか否かを管理する必要が生じる。そこで、本実施の形態では、図6の下部に示す特典報知フラグによりこれを管理するようにしている。
すなわち、連続アクセスが達成される最終日に仲間プレイヤが応援アクセス条件を満たしたことによって連続アクセスが達成されたものとみなされた場合、報知手段58がプレイヤに特典の報知を行うのは、特典の付与処理後にプレイヤの端末装置3がゲームサーバ1に最初にアクセスしたときであり、特典の付与処理からその報知までにはある程度の時間差がある。そこで、ゲームサーバ1の報知手段58は、プレイヤに特典が付与されたとき、当該プレイヤのプレイヤIDと対応付けて図6に示す特典報知フラグを「1」に設定し、これによって当該プレイヤに特典付与を報知する必要がある状態を管理する。そして、その後、特典報知フラグとして「1」がセットされているプレイヤの端末装置3からゲームサーバ1へのアクセスがあったとき、報知手段58は、当該プレイヤに特典が付与された旨を報知し、併せて特典報知フラグを「0」にする。
報知手段58による特典の報知の例を、図10(a)(b)に示している。図10(a)は、特典が付与されたプレイヤの端末装置3の表示部35に表示されるゲームのメイン画面の一例を示すものである。ゲームサーバ1における特典付与処理後に、ゲームサーバ1の報知手段58からは、図10(a)に示すメイン画面を表示させる画面データが、プレイヤの端末装置3へ送信される。このメイン画面には、プレイヤのチーム名70、プレイヤが所有する選手カードの中からリーダーとして選択された選手カード71およびプレイヤのゲーム情報72などが表示されるとともに、特典通知情報73も表示される。なお、メイン画面の詳細については、後述する。
図10(a)に示すように、端末装置3のメイン画面に表示される特典通知情報73は、例えば「5日間連続アクセス達成!特典確認画面へ」というような、連続アクセス達成特典が付与されたことが分かる内容である。また、当該特典通知情報73にはハイパーリンクが設定されており(または、特典通知情報73の全体またはその一部が選択可能なボタン形式となっていてもよい)、プレイヤが画面上の特典通知情報73を選択可能になっている。
ここで、プレイヤが端末装置3を操作して特典通知情報73を選択する操作をすると、当該操作に応答して、ゲームサーバ1の報知手段58からは、図10(b)に示す特典確認画面を表示させる画面データが端末装置3へ送信されてくる。この特典確認画面には、例えば、「連続アクセス達成ボーナス」という表示とともに、「強化ポイント +200ポイント」というような具体的な特典が表示され、プレイヤは連続アクセス達成特典の内容を確認することができる。また、仲間プレイヤが応援アクセス条件を満たしたことによって連続アクセス達成特典が付与された場合には、例えば「アクセスしなかった日が1日ありましたが、仲間の応援アクセスによって5日間連続アクセスを達成できました!」といった内容の文章も、併せて特典確認画面に表示される。これにより、プレイヤは、仲間の応援アクセスにより連続アクセス達成特典が獲得できたことを明確に認識でき、仲間の存在を強く意識する。
また、図10(b)に示すように、特典確認画面に「受け取る」ボタン74を表示させ、プレイヤによって当該ボタン74が選択されることによって、疑似的にプレゼント(ボーナスポイント)を受け取ることができるようにしてもよい。この場合、「受け取る」ボタン74が選択されたときに特典としてのボーナスポイントが有効になるようにしてもよい。この特典確認画面において、例えば「メイン画面へ」ボタン75が選択されると、前記のメイン画面へ戻ることができるようになっている。
このように本実施の形態では、ゲームサーバ1からプレイヤの端末装置3に送信されるゲームのメイン画面データ内に特典通知情報73を含ませることによって、特典の発生を各プレイヤに報知するようになっている。メイン画面はゲームの開始時に必ず表示される基本画面であり、このメイン画面内に特典通知情報73が表示されるようにすることにより、特典の発生を、プレイヤに的確に報知することができる。
また、このメイン画面にはその他のオブジェクトや情報も多く含まれるため、特典の詳細については、図10(b)に示す特典確認画面に遷移して確認できるようにしているが、これに限定されるものではない。例えば、プレイヤの端末装置3がゲームサーバ1にアクセスしたとき、メイン画面よりも先に、図10(b)に示す特典確認画面がプレイヤの端末装置3の表示部35に表示されるようにし、当該確認画面でプレイヤが連続アクセス達成特典の発生を確認してから、プレイヤによる所定の操作によりメイン画面に遷移するようにしてもよい。
このように報知手段58は、メイン画面等に特典の発生情報を表示させてプレイヤへの報知を行うので、前記のゲーム画面生成手段52bおよびゲーム画面送信手段52cと協働して当該報知の処理を行うようになっている。
また、報知手段58は、プレイヤがアクセスを欠落した日の経過後(すなわち欠落日の確定後)、当該プレイヤの仲間プレイヤが応援アクセス条件を満たしていると仲間応援アクセス判定手段56が判定した場合、プレイヤの仲間プレイヤが応援アクセス条件を満たしたことによって連続アクセスが継続している旨をプレイヤの端末装置3に対して報知する機能を有する。報知手段58がこの報知処理を行うのは、仲間応援アクセス判定手段56が応援アクセス条件を満たしていると判定した後、プレイヤの端末装置3がゲームサーバ1に最初にアクセスしたときであり、仲間応援アクセス判定手段56による判定から報知手段58による報知までにはある程度の時間差がある。そこで、ゲームサーバ1の報知手段58は、仲間応援アクセス判定手段56が応援アクセス条件を満たしていると判定したとき、当該プレイヤのプレイヤIDと対応付けて、図9(a)に示す連続アクセス継続報知フラグ(同図では継続報知フラグと省略記載)を「1」に設定し、これによって当該プレイヤに連続アクセスが継続している旨を報知する必要がある状態を管理する。そして、アクセスを欠落した日の翌日中に、連続アクセス継続報知フラグとして「1」がセットされているプレイヤの端末装置3からゲームサーバ1へのアクセスがあったとき、報知手段58は、当該プレイヤに、仲間プレイヤが応援アクセス条件を満たしたことによって連続アクセスが継続している旨を報知し、併せて連続アクセス継続報知フラグを「0」にする。
なお、仲間プレイヤの応援アクセスにより連続アクセスが一旦は継続した状態になったものの、アクセスを欠落した日の翌日中にプレイヤがゲームサーバ1にアクセスしなかったために、結局、連続アクセスが途切れてしまった場合、報知手段58による連続アクセス継続中の報知は行われることはない。よって、連続アクセスが途切れたときも、連続アクセス継続報知フラグが「0」に設定されることになる。但し、このように連続アクセスが途切れた場合であっても、ゲームサーバ1の報知手段58は、仲間プレイヤが応援アクセス条件を満たした事実についてはプレイヤの端末装置3へ報知するようにしてもよい。
報知手段58による連続アクセス継続中の旨の報知例を、図11(a)(b)に示している。図11(a)は、ゲームのメイン画面中に連続アクセス継続中の旨を表示してプレイヤに報知する例を示すものである。プレイヤが連続アクセスを欠落した日の翌日において、仲間応援アクセス判定手段56が仲間による応援アクセス条件を満たしていると判定した後、プレイヤの端末装置3がゲームサーバ1に最初にアクセスしたとき、ゲームサーバ1の報知手段58からは、図11(a)に示すメイン画面を表示させる画面データが、プレイヤの端末装置3へ送信される。このメイン画面には、前述のプレイヤのチーム名70、選手カード71、ゲーム情報72などが表示されるとともに、連続アクセス継続通知情報76も表示される。この連続アクセス継続通知情報76は、例えば「仲間の応援アクセスにより連続アクセス継続中!残り2日の連続アクセスで特典獲得!」というような、仲間プレイヤが応援アクセス条件を満たしたことによって連続アクセスが途切れることなく継続していることが分かる内容である。
これにより、プレイヤは、ゲームサーバ1へアクセスできなかった翌日に、仲間プレイヤの応援アクセスにより連続アクセスが継続している事実を認識できる。よって、プレイヤは、仲間の存在を強く意識するとともに、以降も連続的にゲームサーバ1にアクセスして連続アクセス達成特典を獲得しようとする意識が強く働く。このため、プレイヤによる継続的なゲームサーバ1へのアクセスを、効果的に促すことができる。
図11(b)は、ゲームのメイン画面以外の画面中に連続アクセス継続中の旨を表示してプレイヤに報知する例を示すものである。プレイヤが連続アクセスを欠落した日の翌日に、プレイヤの端末装置3がゲームサーバ1に最初にアクセスしたとき、ゲームサーバ1の報知手段58からは、例えばメイン画面よりも前に、図11(b)に示す画面データが、プレイヤの端末装置3へ送信される。この画面では、昨日(欠落日と同じ日)の仲間のゲームへのアクセス実績および応援アクセス条件を満たした旨が表示される。図11(b)では、「昨日、仲間10人中8人がゲームにアクセスしました。応援アクセス条件(仲間の8割以上のアクセス)をクリア!」という仲間のアクセス実績等の表示例を示している。また、この画面には、図11(a)と同様の連続アクセス継続通知情報76が表示され、仲間プレイヤが応援アクセス条件を満たしたことによって連続アクセスが途切れることなく継続している旨がプレイヤに報知される。図11(b)の画面において、例えば「メイン画面へ」ボタン75がプレイヤにより選択されると、ゲームサーバ1からメイン画面データがプレイヤの端末装置3へ送信され、端末装置3の画面がメイン画面へと遷移する。
次に、メッセージ伝達手段59について説明する。メッセージ伝達手段59は、各プレイヤの端末装置3から送信された他のプレイヤ宛のメッセージを受信するとともに、当該メッセージを当該他のプレイヤへ伝達する機能を有する。このメッセージ伝達手段59は、メッセージ記憶部59aを備えている。
図12には、メッセージ記憶部59aがデータベースサーバ2に記憶して管理する、受信メッセージに関する情報の一例を示している。このメッセージ記憶部59aは、メッセージを受け取った受信側プレイヤのプレイヤIDと対応付けて、送信元のプレイヤID、メッセージの内容、送信日時などのメッセージに関する情報を、受信側のプレイヤのプレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。図12の例では、プレイヤID=“000002”の受信側プレイヤ1人分の受信メッセージに関する情報を示しており、当該プレイヤは、プレイヤID=“000001”のプレイヤから「アクセス頑張ろう!」、プレイヤID=“000038”のプレイヤから「明日はアクセスできないので応援アクセスお願いします!」、プレイヤID=“000145”のプレイヤから「今週もよろしく!」というメッセージをそれぞれ受け取っている。
ここで、プレイヤが自分の仲間プレイヤに対してメッセージを送る操作の一例を説明する。図13(a)には、ゲームサーバ1から送信された画面データに基づいて、プレイヤの端末装置3に表示される仲間リスト画面の一例を示している。この仲間リスト画面は、例えばプレイヤが端末装置3を操作してメイン画面中の「仲間メニュー」を選択することによって表示される画面である。この仲間リスト画面には、プレイヤと仲間関係にある仲間プレイヤの情報がリストアップされて表示される。なお、画面に表示しきれない仲間プレイヤの情報については、画面をスクロールするまたは仲間リストの2ページ目以降をゲームサーバ1にリクエストして別画面として表示することができる。
この仲間リスト画面内にはリストアップされた仲間プレイヤ毎の情報表示領域が設けられており、各情報表示領域には、仲間プレイヤのゲーム情報81(プレイヤ名、チーム名、プレイヤのレベル、仲間の人数、所属リーグのレベル等)、当該プレイヤの分身的なキャラクタであるアバター82、当該プレイヤが所有するリーダーの選手カード83などとともに、エールボタン84というオブジェクトも表示される。そして、プレイヤがこのエールボタン84を選択することで、自分の仲間プレイヤに対してエール(応援)を送る(応援の意思表示をする)ことができるようになっている。プレイヤは、仲間プレイヤにエールのみを送ることもできるが、以下に説明するように、さらにメッセージも送ることができる。
プレイヤの端末装置3における操作によりエールボタン84が選択された場合、当該操作が端末装置3からゲームサーバ1へ伝えられる。その後、ゲームサーバ1からは、例えば図13(b)に示すメッセージ入力画面のデータが端末装置3へ送信され、端末装置3に当該メッセージ入力画面が表示される。このメッセージ入力画面には、例えば、仲間プレイヤ(図13(b)の例ではプレイヤB)に対してエールを送った旨を示す文章等が表示されるとともに、メッセージ入力領域85および送信ボタン86というオブジェクトも表示される。そして、プレイヤは、端末装置3を操作してメッセージ入力領域85に任意のメッセージを入力し、送信ボタン86を選択することによって、端末装置3からは仲間プレイヤ宛のメッセージがゲームサーバ1へ送信される。図13(b)では「アクセス頑張ろう!」というメッセージをプレイヤが入力した例を示している。なお、データベースサーバ2における記憶容量を考慮して、メッセージ入力領域85に入力できる文字に制限(例えば全角30文字以内)を設けてもよい。
なお、メッセージ入力画面には、仲間プレイヤ(この例ではプレイヤB)のページへ遷移するためのハイパーリンク87が表示されており、このリンクを選択することにより当該仲間プレイヤのゲーム情報の詳細が記載されたページを表示できる。また、メッセージ入力画面には、仲間リストへ遷移するためのハイパーリンク88やメイン画面へ遷移するためのハイパーリンク89なども表示されており、これらのリンクを選択することにより仲間リストやメイン画面に戻れるようになっている。
このメッセージ入力画面でのプレイヤの操作により端末装置3からメッセージが送信された場合、ゲームサーバ1では、メッセージ伝達手段59のメッセージ記憶部59aが、端末装置3から受信した仲間プレイヤ宛のメッセージを、当該仲間プレイヤのプレイヤIDと対応させてデータベースサーバ2に記憶する(図12参照)。そして、当該仲間プレイヤの端末装置3がゲームサーバ1へアクセスしたとき、ゲームサーバ1のメッセージ伝達手段59は、メッセージ、送信元のプレイヤ名、送信時間等を表示させる画面データを端末装置3に送信する。これにより、この画面データを受信したプレイヤの端末装置3にはメッセージ等が表示され、他の仲間から受け取ったメッセージを画面で確認できるようになっている。
このように、本実施の形態のゲームシステムでは、前記図13(a)(b)に例示するようなコミュニケーションツールを使用して、仲間同士が何時でもコミュニケーションをとることができるようになっている。
前記図13(a)(b)の例では、プレイヤの仲間に対してメッセージを送る例を説明したが、仲間関係にはない他のプレイヤに対しても、エールを送ったりメッセージを送ったりすることができる。例えば、後述する仲間候補リスト画面(図31参照)にリストアップされた仲間ではない他のプレイヤに対して、仲間の場合と同様の操作により、エールやメッセージを送ることが可能である。
ところで、上記の説明では、仲間管理手段53が管理している各プレイヤの仲間情報、アクセス管理手段55が管理している各プレイヤのアクセス情報、メッセージ伝達手段59が管理しているメッセージに関する情報は、便宜上、ゲーム情報管理手段51が管理している各種情報とは区別して記載しているが、これらの情報は何れもゲームサーバ1が管理するゲーム情報に含まれるものである。
〔ゲームシステムの動作〕
上記の構成において、本発明の実施の形態に係るゲームシステムの動作例を、図14のフローチャートを参照しながら以下に説明する。図14は、プレイヤが端末装置3を操作してゲームサーバ1にアクセスしてゲームサービスを受けるときの、端末装置3およびゲームサーバ1の処理の基本的な流れを示すものである。
プレイヤがゲームサービスを受ける場合、先ず、端末装置3の操作入力部40を操作してウェブブラウザを起動する(S11)。その後、プレイヤは、ゲームサーバ1が管理するゲームサイトにアクセスする操作を行い、これにより、端末装置3からゲームサーバ1へアクセスリクエストが送信される(S12)。このとき、ゲームサーバ1は、端末装置3からのアクセスに対するログイン認証を行い(S21)、ゲームサービスの利用登録がなされているプレイヤからのアクセスであることを確認する。その後、ゲームサーバ1は、HTML等で記述されたメイン画面データを端末装置3に送信する(S22)。そして、メイン画面データを受信した端末装置3では、ウェブブラウザが当該データを解釈し、メイン画面を表示部35に表示させる(S13)。
図10(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にアクセスしたときに画面で確認することができる。
〔ゲーム管理装置の動作〕
次に、本発明の実施の形態に係るゲーム管理装置のより詳細な動作例を、図15ないし図17のフローチャートを参照しながら説明する。図15ないし図17は、ある一人のプレイヤを対象としたゲームサーバ1の処理の流れを示すものであり、ゲームサーバ1が管理している各々のプレイヤに対して同様の処理が行われる。
図15のフローチャートは、現実世界の1日(単位期間)が終了する度に実行される処理を例示するものであり、例えば毎日午前0時に処理が開始される。この処理の開始時間になれば(S31でYES)、プレイヤが前日にゲームサーバ1へ少なくとも1回以上アクセスしたか否かが判断される(S32)。この判断は、図9(a)に示すアクセス情報(1日前のアクセスの有無を示す情報)に基づいて行うことができる。
プレイヤが前日にゲームサーバ1へアクセスしていなかった場合(S32でNO)、この前日のアクセスの欠落が、連続5日間の途中で生じたアクセス欠落日の1日目に該当するか否かが判断される(S33)。本実施の形態では、連続5日間のうち埋め合わせ可能な欠落日を1日のみとしているので、もしも前日のアクセスの欠落が2日目の欠落日であった場合には(S33でNO)、プレイヤのゲームサーバ1への連続アクセスは途絶えたことになり、S40に移行して図9(a)に示す連続アクセス日数が「0日」に初期化される。
前日のアクセスの欠落が、連続5日間の途中で生じたアクセス欠落日の1日目であった場合(S33でYES)、プレイヤの仲間が応援アクセス条件を満たしているか否かの判定処理(S34およびS35)に移行する。図15では、「欠落日と同一の日に、ゲームサーバ1に1回以上アクセスをした仲間プレイヤの当該仲間プレイヤ全体に占める割合が0.8以上」を応援アクセス条件とした例について示している。S34において、前日(すなわち欠落日と同一の日)に、ゲームサーバ1に1回以上アクセスをした仲間プレイヤの当該仲間プレイヤ全体に占める割合Rを算出する。その後、S35において、算出された割合Rが0.8以上という応援アクセス条件を満たすか否かが判定される。
前記の応援アクセス条件を満たしていない場合(S35でNO)、プレイヤの連続アクセスは途絶えたことになり、S40に移行して連続アクセス日数が「0日」に初期化される。一方、前記の応援アクセス条件を満たしている場合(S35でYES)、ゲームサーバ1は、プレイヤが前日にゲームサーバ1へアクセスしたとみなし、連続アクセス継続処理を行う(S36)。この連続アクセス継続処理の具体的な処理例としては、図9(a)に示すプレイヤのアクセス情報を次のように設定・変更することである。すなわち、ゲームサーバ1は、応援アクセス条件を満たしたか否かを示す情報(1日前の情報)を「1」に設定し、連続アクセス日数のカウントを1つ増加させ、連続アクセス継続報知フラグを「1」に設定する。
その後、5日間の連続アクセスを達成したか否かが判断される(S37)。前日が連続5日間の最終日であった場合、プレイヤの仲間が応援アクセス条件を満たしたことによって、プレイヤが連続アクセスを達成する(S37でYES)。この場合、連続アクセス特典付与手段57は、ゲーム上有利になるようにプレイヤのゲーム情報を変更して連続アクセス達成特典を付与する(S38)。例えば、所定の強化ポイントをボーナスポイントとしてプレイヤに付与する場合、当該プレイヤのプレイヤIDに対応するゲーム情報(図6に例示するプレイヤの特典情報および強化ポイントの情報)が変更されることになる。この連続アクセス達成特典の付与処理後、ゲームサーバ1は、図6に示す特典報知フラグを「1」に設定するとともに(S39)、図9(a)に示す連続アクセス日数を「0日」に初期化する(S40)。
一方、前日が連続5日間の最終日でなかった場合は、この時点では未だ5日間の連続アクセスが達成されていないので(S37でNO)、連続アクセス達成特典の付与処理が行われることなく図15のルーチンを終了する。
このように、本実施の形態では、プレイヤがゲームサーバ1へアクセスできなかった欠落日が存在しても、プレイヤの仲間が応援アクセス条件を満たすことによって、プレイヤの連続アクセスが継続される。
次に、図16のフローチャートを参照しながら、プレイヤがゲームサーバ1へアクセスした場合におけるゲーム管理装置(ゲームサーバ1)の動作について説明する。ゲームサーバ1の認証手段54は、プレイヤの端末装置3からアクセス要求を受けたとき(S51でYES)、端末装置3から送信されてきたログインID・パスワード、または携帯電話端末の個体識別番号等に基づいて、アクセスを許可するか否かを判断するログイン認証を行う(S52)。ここで、認証手段54がアクセスを許可しない場合(S52でNO)、ゲームサーバ1は、端末装置3にゲームサービスの利用登録を促す画面データを送信する(S53)。
一方、認証手段54がアクセスを許可する場合(S52でYES)、アクセス管理手段55がプレイヤのアクセス情報を記憶する(S54)。例えば、図9(a)に示すように、アクセス管理手段55のアクセス情報記憶部53aが、プレイヤIDと対応付けて、プレイヤの当日のアクセス情報を更新する(すなわち、アクセスの有無を表す情報ビットを「1」に設定する)。さらに、ゲームサーバ1のアクセス管理手段55は、図9(a)に示す連続アクセス日数のカウントを1つ増加させる(S55)。
その後、連続アクセス日数が5日に達しているか否かが判断される(S56)。ここで、プレイヤの連続アクセス日数が5日に達している場合(S56でYES)、連続アクセス特典付与手段57が、ゲーム上有利になるように当該プレイヤのゲーム情報を変更して連続アクセス達成特典を付与する(S57)。この連続アクセス達成特典の付与処理後は、図9(a)に示す連続アクセス日数が「0日」に初期化される(S58)。そして、報知手段58が、連続アクセス達成特典が付与された旨をプレイヤに報知するための画面データを生成する(S59)。例えば、図10(a)に示すように、ゲームのメイン画面内に特典通知情報73を含ませた画面データが生成される。その後、ゲームサーバ1は、特典通知情報73を含んだメイン画面データをプレイヤの端末装置3へ送信する(S60)。これにより、プレイヤの端末装置3には、図10(a)に例示されるような特典通知情報73を含んだメイン画面が表示されるので、プレイヤは、連続アクセス達成特典を獲得したことを認識できる。
一方、プレイヤの連続アクセス日数が5日に達していない場合(S56でNO)、特典報知フラグが「1」に設定されているか否かが判断される(S61)。すなわち、本実施の形態では、上述のように、連続5日間の最終日にゲームサーバ1へアクセスできなかったプレイヤの仲間が応援アクセス条件を満たしたことによって、当該プレイヤが連続アクセスを達成することもあり、この場合、特典報知フラグが「1」に設定されている。よって、特典報知フラグが「1」に設定されている場合(S61でYES)、前記S59に移行して、連続アクセス達成特典が付与された旨をプレイヤに報知するための画面データが生成されることになる(S59)。なお、S61経由でS59が実行された場合は、フローチャートには図示していないが特典報知フラグが「0」に設定されることになる。その後、ゲームサーバ1は、例えば図10(a)に示す特典通知情報73を含んだメイン画面データをプレイヤの端末装置3へ送信する(S60)。これにより、プレイヤの端末装置3には、特典通知情報73を含んだメイン画面が表示されるので、プレイヤは、連続5日間の最終日にゲームサーバ1にアクセスできなかったにもかかわらず、仲間の応援アクセスにより連続アクセス達成特典を獲得したことを認識できる。
また、S61において特典報知フラグが「1」に設定されていない場合には、連続アクセス継続報知フラグが「1」に設定されているか否かが判断される(S62)。すなわち、本実施の形態では、上述のように、プレイヤがゲームサーバ1へアクセスできなかった欠落日が存在しても、プレイヤの仲間が応援アクセス条件を満たすことによって、プレイヤの連続アクセスが継続され、この場合、連続アクセス継続報知フラグが「1」に設定されている。よって、連続アクセス継続報知フラグが「1」に設定されている場合(S62でYES)、プレイヤの仲間プレイヤが応援アクセス条件を満たしたことによって連続アクセスが継続している旨を報知するための画面データが、報知手段58によって生成されることになる(S63)。例えば、図11(a)に示すように、ゲームのメイン画面内に連続アクセス継続通知情報76を含ませた画面データが生成される。その後、ゲームサーバ1は、連続アクセス継続通知情報76を含んだメイン画面データをプレイヤの端末装置3へ送信する(S60)。これにより、プレイヤの端末装置3には、連続アクセス継続通知情報76を含んだメイン画面が表示されるので、プレイヤは、前日にゲームサーバ1にアクセスできなかったにもかかわらず、仲間の応援アクセスにより連続アクセスが継続していることを認識できる。
一方、特典報知フラグおよび連続アクセス継続報知フラグの何れもが「1」でない場合(S61およびS62でNO)、ゲームサーバ1は、通常のメイン画面データをプレイヤの端末装置3へ送信する(S60)。
そして、ゲームサーバ1は、メイン画面データの送信後はゲーム進行処理を実行する(S64)。このゲームサーバ1におけるゲーム進行処理を、図17のフローチャートを参照しながら、以下に説明する。
図17に示すように、ゲームサーバ1は、プレイヤの端末装置3から送信されてくるプレイヤのゲーム操作に応じた画面リクエストを受信したとき(S71でYES)、ゲーム実行手段52aが、当該画面リクエストに応じた演算処理やデータ処理を行ってゲームを実行する(S72)。
その後、ゲームサーバ1は、ゲームの実行によりプレイヤのゲーム情報を更新する必要があるか否かを判断し(S73)、更新の必要がある場合(S73でYES)、データベースサーバ2に記憶されているプレイヤのゲーム情報を更新する(S74)。例えば、プレイヤのゲーム操作が他のプレイヤとの個別対戦を行う操作であった場合、当該対戦が実行された結果、試合結果の情報、運営コスト、強化ポイント、アイテム等のプレイヤのゲーム情報が更新されることになる。一方、例えば、プレイヤのゲーム操作がリーグ戦の結果確認の操作であった場合、当該操作に応じたゲームの実行処理としてはリーグ戦の結果情報をデータベースサーバ2から読み出すデータ処理だけであって、当該処理の前後でプレイヤのゲーム情報に変化はなく、よってプレイヤのゲーム情報を更新する必要はない(S73でNO)。
その後、ゲーム画面生成手段52bがゲームの実行結果を反映させたゲーム画面データを生成し(S75)、ゲーム画面送信手段52cが当該ゲーム画面データをプレイヤの端末装置3へ送信する(S76)。その後、プレイヤの端末装置3がログアウトしたか否かが判断され(S77)、端末装置3がログアウトするまで、前記S71〜S76の処理が繰り返されることで、ゲームが進行していく。
以上のように、本実施の形態では、連続5日間(連続した規定期間数の単位期間)の中にアクセスの欠落日(欠落単位期間)が存在するプレイヤであっても、当該プレイヤの仲間が所定の応援アクセス条件を満たすことによって、当該プレイヤに連続アクセス達成特典が付与される。よって、プレイヤが何かの用でゲームサーバ1にアクセスできなかった場合でも、プレイヤの仲間が応援アクセス条件を満たすような高いアクセス頻度を維持してくれることにより、連続アクセス達成特典を獲得できるというメリットが生じる。また、プレイヤ自身も高いアクセス頻度を維持すれば、他の仲間がアクセスを欠落したときの応援アクセス条件の達成に貢献することができ、間接的に他の仲間を支援できることにもなる。これにより、各プレイヤは、仲間同士でお互いにアクセス頻度を高め合おうという意識付け、動機付けを与えられることになる。よって、各プレイヤは、仲間全体のゲームサーバ1へのアクセス頻度を高めようとして、自己の仲間プレイヤとコミュニケーションをとる動機付けを与えられることになる。例えば、各プレイヤは、仲間に対して「アクセス頑張ろう!」のようなメッセージを送って、自己の仲間プレイヤとの間のコミュニティを盛り上げようとする。
このように、本実施の形態では、単に特典を受けることの面白さをプレイヤに提供するにとどまらず、仲間同士でお互いにアクセス頻度を高め合おうという動機付けおよび仲間とコミュニケーションをとろうとする動機付けをプレイヤに与え、これにより、ゲームコミュニティ全体の活性化を図ることができる。この結果、各プレイヤはゲーム内での仲間同士のつながりや交流を強め、延いてはゲームに対する関心と興味をより強めることとなるので、プレイヤにとって飽きのこない継続性を有するゲームを実現できる。
また、本実施の形態では、アクセスの欠落日(欠落単位期間)と同じ日(同一の単位期間内)に、少なくとも1回のアクセスを行なった仲間プレイヤ(単位期間内アクセスを達成した仲間プレイヤ)の人数または仲間プレイヤ全体に占める割合が、閾値を超えることを応援アクセス条件としている。この場合、プレイヤは、欠落日の当日に仲間による応援アクセス条件が満たされるように、何かの用で欠落日となりそうな日(アクセスができそうにない日)を予め他の仲間に連絡しておくことができる。例えば、プレイヤは、仲間に対して「明日はアクセスできないので応援アクセスお願いします!」のようなメッセージを送って、応援アクセスを事前依頼することができる。このように、応援アクセスを事前依頼することにより仲間との間のコミュニティが盛り上がる。また、応援アクセスを事前依頼した日に、実際に仲間が応援アクセス条件を満たしてくれることにより、仲間意識が高まって仲間同士のつながりがより強くなり、プレイヤはゲームに対する関心と興味をより一層強くする。
ところで、上記の説明では、連続5日間のうち埋め合わせ可能な欠落日を1日のみとする例を示したが、埋め合わせ可能な欠落日を2日以上とすることもできる。但し、上述のように、連続アクセス達成特典は、本来、プレイヤ自身がゲームサーバ1へ連続アクセスして獲得できるものであることから、埋め合わせ可能な欠落日をあまり多く許容し過ぎない方がよい。よって、埋め合わせ可能な欠落日には上限を設けることが望ましく、例えば、埋め合わせ可能な欠落日を最大2日とし、3日以上の埋め合わせは不可とする。
埋め合わせ可能な欠落日を最大2日とした場合、欠落日の1日目を埋め合わせするための応援アクセス条件と、欠落日の2日目を埋め合わせするための応援アクセス条件とを同じ条件とすることも可能である。その一方で、複数の欠落日に対する埋め合わせが容易になされることを回避するため、欠落日の1日目(第1欠落単位期間)より欠落日の2日目(第2欠落単位期間)の方が、応援アクセス条件を満たし難い条件に設定することが望ましい。例えば、欠落日の1日目を埋め合わせするための応援アクセス条件を「欠落日と同一の日に、ゲームサーバ1に1回以上アクセスをした仲間プレイヤの当該仲間プレイヤ全体に占める割合Rが0.8以上であること」とし、欠落日の2日目を埋め合わせするための応援アクセス条件を「前記割合Rが0.9以上であること(または、欠落日と同一の日に、アクセスを欠落したプレイヤ以外の仲間全員がゲームサーバ1に1回以上アクセスしていること)」とし、欠落日の2日目は1日目よりかなり厳しい条件とする。このように欠落日の2日目を1日目より厳しい応援アクセス条件とした場合のゲームサーバ1の動作を、図18のフローチャートを参照しながら、以下に説明する。なお、図15に示したフローチャートと同様の処理については、同一のステップ番号を付して、適宜その説明を省略する。
処理の開始時間になれば(S31でYES)、プレイヤが前日にゲームサーバ1へ少なくとも1回以上アクセスしたか否かが判断され(S32)、プレイヤが前日にアクセスしていなかった場合(S32でNO)、この前日のアクセスの欠落が、連続5日間の途中で生じたアクセス欠落日の3日目に該当するか否かが判断される(S81)。ここで、前日のアクセスの欠落が3日目であった場合には(S81でYES)、プレイヤのゲームサーバ1への連続アクセスは途絶えたことになり、S40に移行して連続アクセス日数が「0日」に初期化される。
前日のアクセスの欠落が、連続5日間の途中で生じたアクセス欠落日の3日目でなかった場合、すなわち1日目または2日目の欠落日であった場合(S81でNO)、プレイヤの仲間が応援アクセス条件を満たしているか否かの判定処理(S34以降の処理)に移行する。S34では、前日(すなわち欠落日と同一の日)に、ゲームサーバ1に1回以上アクセスをした仲間プレイヤの当該仲間プレイヤ全体に占める割合Rを算出する。その後、S82において、欠落日が1日目か否かによって、応援アクセス条件を異ならせる分岐処理が行われる。欠落日が1日目の場合(S82でYES)、算出された割合Rが0.8以上という応援アクセス条件を満たしているか否かが判定される(S35)。一方、欠落日が1日目ではなく2日目の場合(S82でNO)、1日目より厳しい応援アクセス条件となるように、算出された割合Rが例えば0.9以上であるか否かが判定される(S83)。ここで応援アクセス条件を満たしている場合(S35またはS83でYES)、ゲームサーバ1は、プレイヤが前日にゲームサーバ1へアクセスしたとみなし、連続アクセス継続処理を行う(S36)。一方、応援アクセス条件を満たしていない場合(S35またはS83でNO)、プレイヤの連続アクセスは途絶えたことになり、S40に移行して連続アクセス日数が「0日」に初期化される。なお、S37〜S39は、基本的には図15のフローチャートで説明した処理と同様の処理である。
このように、欠落日の1日目より2日目の方が厳しい応援アクセス条件を適用することにより、複数の欠落日に対する埋め合わせが容易になされることを回避する。また、2日目の厳しい応援アクセス条件を満たしたプレイヤに対して、複数の欠落日に対する埋め合わせを許容することによって、厳しい条件を達成するために仲間同士でお互いにアクセス頻度を一層高めようという意識付け、動機付けをプレイヤに与えることができる。
また、欠落日の埋め合わせを3日以上許容する場合も、時系列的に後に生じた欠落日(第2欠落単位期間)の方が、それより前に生じた欠落日(第1欠落単位期間)よりも厳しい応援アクセス条件を適用することが望ましい。
また、上記では、各プレイヤが任意の日に5日間の連続アクセスを達成すれば、連続アクセス達成特典が付与される例について説明したが、次のような期間限定のゲーム内イベントにおいて連続アクセス達成特典が付与されるようにしてもよい。
すなわち、本実施の形態のゲームシステムは、ゲームサーバ1においてプレイヤのゲーム情報を管理してゲームを実行するので、基本的にゲーム実行プログラムはゲームサーバ1側に存在する。よって、ゲームサービスの運営者がゲームサーバ1側のゲーム実行プログラムを追加・変更することによって、全てのゲームサービスの利用者(プレイヤ)が追加・変更されたゲームサービスを受けることができる。このため、ゲームサーバ1側のゲーム実行プログラムを追加・変更して期間限定のゲーム内イベントを適宜開催し、プレイヤに色々なゲームサービスを提供することも容易にできる。そこで、例えば、毎月1日〜5日の5日間や毎月第1週の月曜日〜日曜日の7日間をマンスリーイベント期間としたり、クリスマスの週の7日間をクリスマスイベント期間としたりして、当該イベント期間中の連続アクセスの達成者に特典を付与するというゲームサービスを提供することもできる。特に期間限定のイベントを開催する場合、通常時に獲得できる連続アクセス達成特典よりも大きな特典をプレイヤが獲得できるようにすることも多いので、アクセスの欠落日を埋め合わせすることができる応援アクセス条件も、特典の大きさに応じて厳しくしてもよい。
〔ゲーム管理装置の他の構成例〕
次に、前述の応援アクセス条件とは異なる条件を適用したゲーム管理装置の構成例を、図19の機能ブロック図を参照しながら説明する。なお、既出の図面(図1〜図18)において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。本実施の形態で説明する応援アクセス条件とは、連続5日(連続した規定期間数の単位期間)の中に欠落日(欠落単位期間)が存在するプレイヤの仲間というグループの評価値が、閾値を超えることである。このグループの評価値は、アクセス頻度に基づいて算出されるものであり、本実施の形態では、グループの評価値として、仲間のアクセスの頻度の平均値である仲間アクセス平均を適用した例について、以下に説明する。
本実施の形態のゲームサーバ1(ゲーム管理装置)は、図4に示した各手段51〜55・57〜59に加えて、アクセス平均算出手段60および仲間アクセス平均算出手段61(評価値算出手段)をさらに備えている。また、本ゲームサーバ1は、図4に示した仲間応援アクセス判定手段56に代えて、仲間応援アクセス判定手段156を備えている。アクセス平均算出手段60、仲間アクセス平均算出手段61および仲間応援アクセス判定手段156は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。
アクセス平均算出手段60は、プレイヤがゲームサーバ1にアクセスする頻度の目処として、各プレイヤのゲームサーバ1へのアクセス頻度の平均値である「アクセス平均」を算出する。ここで、アクセス平均の算出方法は無数に存在し、例えば、アクセス平均を算出する際の期間(以下、アクセス平均算出期間と称する)については任意に設定することができる。
ただし、このアクセス平均算出手段60が算出する各プレイヤのアクセス平均は、仲間アクセス平均算出手段61が仲間アクセス平均を算出する際の基となる値であり、延いては応援アクセス条件に影響を与える値であるため、これを考慮してアクセス平均算出期間を決定することが望ましい。そこで、本実施の形態では、プレイヤがアクセスできなかった欠落日(欠落単位期間)の直前の所定期間(例えば欠落日の前日までの7日間)をアクセス平均算出期間とする。そして、このアクセス平均算出期間中におけるアクセス平均を、アクセス平均算出手段60がプレイヤの仲間プレイヤのそれぞれについて算出し、さらに仲間アクセス平均算出手段61が、当該プレイヤを中心とした仲間というグループを対象とした仲間アクセス平均を算出する。
アクセス平均算出期間を設定する場合に考慮すべき点は幾つかある。先ず、その期間の長さであるが、プレイヤの入れ替わり(ゲームサービスを受けるのを止めるプレイヤおよび新規参入のプレイヤ)は、常時発生するので、アクセス平均算出期間を数か月単位の比較的長い期間とした場合、当該期間内で発生するプレイヤの入れ替わりは多くなり易い。アクセス平均算出期間の途中でゲームサービスを開始または中止したプレイヤは、アクセス平均を算出する期間的条件を満たさないため、その算出対象から除外することが望ましいことから、アクセス平均算出期間を1か月以内の期間、より好ましくは5日間〜10日間程度に限定することで、期間的条件を満たさない算出対象の除外を低減できる。特に、ゲームサービスを開始した新規参入のプレイヤに対して、数か月間という長いアクセス平均算出期間が経過するまでアクセス平均の算出対象にならない(すなわち応援アクセス条件に何ら寄与しない)状態をつくるのは決して望ましくない。そこで、アクセス平均算出期間を1か月以内の期間とすることが好ましく、5日間〜10日間程度に限定することがより好ましい。
また、アクセス平均算出期間(アクセス平均を算出する際の母数)を1か月以内の期間、より好ましくは5日間〜10日間程度に限定すれば、例えば当該期間を3ヶ月とした場合のように、平均値の変化が乏しくなってしまい冗長感が生じるという事態も回避できる。
また、アクセス平均算出期間を「欠落日直前」の所定期間(例えば欠落日の前日までの7日間)とすることで、プレイヤの日々のゲームサーバ1へのアクセスがアクセス平均に反映されることとなる。例えば、アクセス平均算出期間を同じ7日間とした場合でも、欠落日の前日までの7日間(7日前から1日前までの7日間)ではなく、例えば先月の1日から7日までの7日間とした場合、欠落日の数週間前にはアクセス平均算出期間が終了しており、当該期間終了後のゲームサーバ1へのアクセスは、アクセス平均には反映されない。これに対して、アクセス平均算出期間を「欠落日直前」の所定期間とすれば、応援アクセス条件達成の有無の判断がなされる前日までの日々のアクセスが、アクセス平均の算出結果に反映されるので、プレイヤは、常時、アクセス平均を上げようとする動機付けを与えられることになる。
以下、本実施の形態では、アクセス平均算出期間を、欠落日の前日までの7日間とした例について説明する。
図9(a)に示すように、アクセス管理手段55のアクセス情報記憶部55a(アクセス頻度記憶手段)は、プレイヤIDと対応付けて、現実世界におけるn日前までの各日についてのプレイヤのアクセスの有無(有=“1”、無=“0”の1ビット情報)を、アクセス頻度を表す情報としてプレイヤID毎に記憶している。あるいは、図9(b)に示すように、アクセス管理手段55のアクセス情報記憶部55aは、プレイヤIDと対応付けて、現実世界におけるn日前までの各日についてのアクセス回数を、アクセス頻度を表す情報としてプレイヤID毎に記憶している。
ここで、アクセス回数とは、プレイヤの端末装置3がゲームサーバ1に接続されていない状態(セッションが確立されていない状態)からゲームサーバ1にアクセスしてログインした回数である。よって、原則的にはログイン後におけるゲームを進行させるためのゲームサーバ1へのアクセスは、アクセス回数のカウントには含めない。ログイン後、ゲームを一旦終了してログオフしてから時間をおいて、再度、ゲームサーバ1にアクセスしてログインした場合は、アクセス回数としてカウントされる。
なお、ログイン時間が日付変更時間である午前0時より前であり、ログアウトの時間が午前0時を過ぎている場合、すなわち日付を跨いでゲームをプレイしている場合、日付変更時間を過ぎた後のゲームサーバ1へのアクセスは、ログイン中のアクセスであってもログインした日とは別の日のアクセスとみなしてアクセス回数をカウントしてもよい。
また、ゲームサーバ1において、ゲーム管理上の日付変更時間を、午前0時とは異なる時間に設定してもよい。例えば、ゲーム管理上の1日を午前3時から開始し、翌日の午前3時になるまでとし、毎日、午前3時にゲーム管理上の日付が変更されるようにしてもよい。
次に、アクセス平均算出期間を欠落日の前日までの7日間とした場合における、アクセス平均算出手段60によるアクセス平均の具体的な算出例を例示する。アクセス平均の算出方法としては様々な方法が考えられるが、ここでは、代表的な算出方法として、算出例(1)〜(3)について説明する。
算出例(1)は、単純に7日間のアクセス回数の合計を7日で割って、1日当たりのアクセス回数(回数/日)をアクセス平均として算出する。例えば、図20(a)に示すように、プレイヤAが欠落日の1日前〜7日前の各日に、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日間のアクセス頻度情報としては、各日のアクセスの有無が分かればよく、アクセスの有無は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)に限定されるものではなく、例えば加重平均算出時の重みのつけ方を変更してもよい。
ここで、図20(a)〜(c)に示すプレイヤA、B、Cのゲームサーバ1へのアクセス実績の例に基づいて、算出例(1)〜(3)を考察する。
図20(a)のプレイヤAは、7日のうち1回以上アクセスをした日は5日であり、日によってアクセス回数はバラバラである。図20(b)のプレイヤBは、アクセス回数の合計についてはプレイヤAと同じ14回であるが、7日のうち1回以上アクセスをした日は3日だけであり、金曜日〜日曜日に集中的にアクセスしている。図20(c)のプレイヤCは、アクセス回数の合計についてはプレイヤA・Bよりも少ないが、7日間にわたってコンスタントに毎日1回ずつアクセスしている。このように、三者三様のアクセス態様であり、算出例(1)〜(3)のいずれの算出方法を採用するかによって、アクセス平均の算出結果も大きく異なっている。
例えば、ゲームサーバ1へのアクセス回数の多さに評価の重点を置く場合は、算出例(1)のアクセス平均の算出方法が適している。算出例(1)の算出方法では、プレイヤCのアクセス平均は、プレイヤA・Bのアクセス平均より低い。
一方で、単なるアクセス回数の多さよりも、平均算出期間内のコンスタントなアクセスに評価の重点を置く場合は、算出例(2)または(3)のアクセス平均の算出方法が適している。算出例(2)または(3)の算出方法では、プレイヤCのアクセス平均は、プレイヤA・Bのアクセス平均より高くなる。例えば、基本のゲーム料金は無料であり、一部のアイテム等の使用についてのみ課金する、いわゆるアイテム課金制を採用するゲームサービスの場合、アクセスの多さも重要ではあるが、ゲームサービスの利用者に継続的にサービスを利用してもらうことがより求められることであるので、コンスタントなアクセスに評価の重点を置く算出例(2)または(3)の方が適していると言える。特に、算出例(3)は、コンスタントなアクセスに評価の重点を置きながら、アクセス回数の多さをも評価の対象にした加重平均を採用しており、最も適している。
アクセス平均算出手段60は、アクセスを欠落したプレイヤの仲間プレイヤのそれぞれについて、上述のごとくアクセス平均を算出する。そして、算出された各仲間プレイヤのアクセス平均に基づいて、仲間アクセス平均算出手段61が、仲間というグループの評価値である仲間アクセス平均を算出する。
ここで、各プレイヤを中心とする仲間(グループ)には、当該中心となるプレイヤが含まれていることから、仲間アクセス平均についても、当該中心となるプレイヤ(アクセスを欠落したプレイヤ本人)のアクセス平均を含めて算出してもよいし、当該中心となるプレイヤ以外の仲間のアクセス平均に基づいて、仲間アクセス平均を算出してもよい。
なお、仲間を一人も作っていないプレイヤに関しては、当該プレイヤを中心とする仲間というグループ自体が存在しないため、仲間アクセス平均は算出されず、よって応援アクセス条件を満たすか否かの判定も行われない。
また、上記では、アクセス平均算出手段60が、基本的にプレイヤの仲間全員を対象として仲間アクセス平均を算出する例を説明したが、次に示す非アクティブプレイヤを除外して仲間アクセス平均を算出する構成としてもよい。ここで言う非アクティブプレイヤとは、ゲームサーバ1に対してゲームサービスの利用登録はしているものの実態としては全くゲームプレイをしていないか、ゲームプレイが基準より少ないプレイヤを示すものであり、「ゲームサーバ1へのアクセスの頻度が閾値に満たないプレイヤ」と定義されるものである。例えば、アクセス頻度の閾値を「1回/月」(すなわち、直近の1か月間に1回のアクセス)とした場合、直近の1か月間に1度もゲームサーバ1へアクセスしていないプレイヤは、当該閾値の条件を満たさない非アクティブプレイヤとなる。
なお、アクセス頻度の閾値は、「1回/月」に限定されるものではなく、例えば、「2回/月」(直近の1か月間に2回のアクセス)、「1回/3週間」(直近の3週間に1回のアクセス)、「1回/20日」(直近の20日間に1回のアクセス)などのように、アクセス頻度を定める期間および当該期間中のアクセス回数を、任意に設定することができる。
このように非アクティブプレイヤを除外して仲間アクセス平均を算出する理由は、非アクティブプレイヤを仲間アクセス平均の算出対象に入れると、実態にそぐわない算出データとなることもあるためである。例えば、ゲームに熱中して多数の仲間(例えば30人程度の仲間)を作ったプレイヤであっても、たまたまその仲間の半数程度が非アクティブプレイヤであった場合、当該プレイヤの仲間アクセス平均が大きく低下してしまうことになるためである。
そこで、仲間アクセス平均算出手段60は、プレイヤの仲間の中からゲームサーバ1へのアクセス頻度が閾値に満たない非アクティブプレイヤを除外して、仲間アクセス平均をプレイヤ毎に算出する。ここで、プレイヤが非アクティブプレイヤであるか否かの判断は、アクセス管理手段55が管理している各プレイヤのアクセス頻度の情報に基づいて行われる。
本実施の形態では、図9(a)または(b)に例示するように、アクセス管理手段55のアクセス情報記憶部55aが、アクセス頻度を管理するためのアクセス情報として、n日前までのアクセスの有無またはアクセス回数を、プレイヤID毎にデータベースサーバ2に記憶して管理している。ゲームサーバ1のCPU11は、このアクセス情報に基づいて、例えばアクセス頻度の閾値=「1回/月(30日)」を満たすか否かを判断する。すなわち、本日から30日前までのアクセスの有無またはアクセス回数の情報が全て「0」であるプレイヤIDに対応するプレイヤが、当該アクセス頻度の閾値の条件を満たさない非アクティブプレイヤであると判断できる。一方、本日から30日前までのアクセスの有無またはアクセス回数の情報の何れか1つでも「0」以外の値となっているプレイヤIDに対応するプレイヤは、直近の30日以内に少なくとも1回以上、ゲームサーバ1へアクセスしたプレイヤであり、非アクティブプレイヤではないと判断できる。
また、非アクティブプレイヤの管理のために、図9(c)に示すように、アクセス管理手段55のアクセス情報記憶部55aがプレイヤID毎に記憶して管理する情報として、各プレイヤの最終アクセス時刻やアクティブフラグを含めてもよい。プレイヤの最終アクセス時刻からは、プレイヤがゲームサーバ1へ一度もアクセスしていない期間の長さ(最終アクセス時刻から現在時刻までの期間)が分かるので、ゲームサーバ1のCPU11は、当該最終アクセス時刻に基づいて、アクセス頻度の閾値を満たさない非アクティブプレイヤか否かを判断することもできる。
また、前記アクティブフラグは、アクティブなプレイヤであるか非アクティブプレイヤであるかを示す1ビットの情報であって、このアクティブフラグが「1」のプレイヤはアクティブであり、当該フラグが「0」のプレイヤは非アクティブプレイヤである。アクセス管理手段55は、前述の非アクティブプレイヤか否かの判断に基づいてアクティブフラグを設定する。そして、仲間アクセス平均算出手段60は、このアクティブフラグを参照して仲間アクセス平均を算出する対象の仲間プレイヤを抽出し(すなわち、非アクティブプレイヤを除外し)、各プレイヤの仲間アクセス平均を算出することができる。
本実施の形態の仲間応援アクセス判定手段156は、仲間アクセス平均算出手段61が算出した仲間アクセス平均と所定の閾値とを比較し、仲間アクセス平均が閾値(例えば0.8)を超えている場合に応援アクセス条件を満たしていると判定する。
仲間アクセス平均と比較される閾値は、固定値とすることもできるが、次のように全体のアクセス頻度に応じて変動する値としてもよい。すなわち、ゲームサービスを受けている全プレイヤを対象としたアクセス頻度の平均値である全体アクセス平均を算出し、当該全体アクセス平均に所定値(例えば0.2)を加算した値を閾値とする。例えば、算出された全体アクセス平均が0.6であった場合、閾値は0.8(=0.6+0.2)となる。ここで、全体アクセス平均は、前記アクセス平均算出手段60が算出する各プレイヤのアクセス平均の値を用いることができる。全体アクセス平均を算出する場合、アクセス平均算出手段60は、全プレイヤを対象として前述した各プレイヤのアクセス平均の値を算出することになる。なお、全体アクセス平均を算出するに際しては、アクセス平均算出期間の途中でゲームサービスを開始または中止したプレイヤは、アクセス平均を算出する期間的条件を満たさないため、その算出対象から除外することが望ましい。また、前述の非アクティブプレイヤも全体アクセス平均の算出対象から除外してもよい。
本実施の形態のゲームサーバ1の処理例を、図21のフローチャートに示す。なお、図15または図18に示したフローチャートと同様の処理については、同一のステップ番号を付して、適宜その説明を省略する。
S31、S32およびS81については図18と同様の処理である。プレイヤによる前日のアクセスの欠落が、連続5日間の途中で生じたアクセス欠落日の3日目でなかった場合、すなわち1日目または2日目の欠落日であった場合(S81でNO)、当該プレイヤの仲間が応援アクセス条件を満たしているか否かの判定処理(S91以降の処理)に移行する。S91では、アクセス平均算出手段60が、欠落日の前日までの7日間のアクセス平均を、アクセスを欠落したプレイヤの仲間プレイヤのそれぞれについて算出する。その後、仲間アクセス平均算出手段61が、アクセス平均算出手段60により算出された各仲間プレイヤのアクセス平均に基づいて、アクセスを欠落したプレイヤの仲間アクセス平均AVAを算出する(S92)。その後、S82において、欠落日が1日目か否かによって、応援アクセス条件を異ならせる分岐処理が行われる。
欠落日が1日目の場合(S82でYES)、算出された仲間アクセス平均AVAが、例えば0.8以上という応援アクセス条件を満たしているか否かが判定される(S93)。一方、欠落日が1日目ではなく2日目の場合(S82でNO)、1日目より厳しい応援アクセス条件となるように、算出された仲間アクセス平均AVAが、例えば0.9以上であるか否かが判定される(S94)。ここで応援アクセス条件を満たしている場合(S93またはS94でYES)、ゲームサーバ1は、プレイヤが前日にゲームサーバ1へアクセスしたとみなし、連続アクセス継続処理を行う(S36)。一方、応援アクセス条件を満たしていない場合(S93またはS94でNO)、プレイヤの連続アクセスは途絶えたことになり、S40に移行して連続アクセス日数が「0日」に初期化される。なお、S37〜S39は、基本的には図15のフローチャートで説明した処理と同様の処理である。
図21のフローチャートでは、埋め合わせ可能な欠落日を最大2日とした例を示したが、埋め合わせ可能な欠落日を1日のみまたは3日以上としてもよい。
上記では、連続5日の中に欠落日が存在するプレイヤの仲間というグループの評価値として仲間アクセス平均を適用した例を説明したが、グループの評価値はこれに限定されない。例えば、グループの評価値を仲間プレイヤのアクセス頻度の合計値としてもよいし、仲間プレイヤの中のアクセス頻度の最大値または最小値としてもよい。グループの評価値を上記のような合計値、最大値または最小値とする場合、例えば、アクセス平均算出手段60が算出した各仲間プレイヤのアクセス平均を、アクセス頻度を示す値として用いて、グループ内の仲間プレイヤのアクセス平均の合計値、最大値または最小値を求めることができる。
グループの評価値として上記の最大値または最小値を適用した場合、グループ内の一人のアクセス頻度がグループを代表する値となるのに対して、仲間アクセス平均または合計値をグループの評価値とした場合には、グループ内の全員のアクセス頻度が評価値として反映されることになることから、仲間アクセス平均または合計値をグループの評価値とする方が好ましいといえる。すなわち、グループの評価値をグループ内のアクセス頻度の最大値とした場合を考えると、グループ内にアクセス頻度の高くないプレイヤが多数存在したとしても、グループ内にアクセス頻度の高い仲間プレイヤが一人でも存在すれば、グループの評価値としては高くなってしまう。この場合、プレイヤは自分の仲間全体のアクセス頻度を高めようとするのではなく、普段よりアクセス頻度が比較的高い特定の仲間プレイヤ数人のみに対して応援アクセスを働きかけることによりグループの評価値を高めようとする可能性がある。これに対して、グループの評価値をグループ内のアクセス頻度の平均値(仲間アクセス平均)または合計値とすることにより、評価値を高めるためにはグループ内の多くの仲間プレイヤのアクセス頻度を高める必要が生じるので、プレイヤにグループ内の多くの仲間プレイヤとコミュニケーションを図ろうとする動機付けを与えることができる。
また、グループの評価値として上記の合計値を適用した場合、仲間の人数(グループの人数)が多くなるほど合計値も大きくなる傾向にあるので、グループ内の各仲間プレイヤのアクセス頻度としてはそれ程高くなくとも、グループの人数が多ければ、結果的にグループの評価値が高くなることもある。これに対して、グループの評価値をグループ内のアクセス頻度の平均値(仲間アクセス平均)とすることにより、グループ内の仲間プレイヤの人数等にかかわらずに仲間全員のアクセス頻度の高さが的確に評価値として反映されるので、仲間アクセス平均をグループの評価値とすることがより好ましいといえる。
また、グループの評価値として上記の合計値を適用する場合、グループに所属する仲間プレイヤの人数が多い程、評価値と比較される基準値(閾値)を高くすることが望ましい。これにより、単純に仲間の人数を増やしただけでは応援アクセス条件を満たせなくなり、評価値を高めるためには仲間全体のアクセス頻度を高める必要が生じるので、プレイヤにグループ内の多くの仲間プレイヤとコミュニケーションを図ろうとする動機付けを与えることができる。
以上のように、本実施の形態のゲームサーバ1は、欠落日(欠落単位期間)が存在するプレイヤの仲間プレイヤのアクセス頻度に基づいて、当該プレイヤを中心とするグループの評価値を算出する評価値算出手段を備えており、当該評価値が閾値を超えることを応援アクセス条件としている。このような応援アクセス条件にすることにより、プレイヤの仲間プレイヤが応援アクセス条件を満たすためには、仲間プレイヤのアクセスの頻度を高めることによってグループの評価値を上げる必要がある。よって、各プレイヤは、グループに所属する仲間プレイヤのアクセスの頻度を高めようとして、自己の仲間プレイヤと積極的にコミュニケーションをとる動機付けを与えられることになる。これにより、ゲームコミュニティ全体の活性化を図ることができる。
また、欠落日(欠落単位期間)の直前の所定期間中のグループの評価値(仲間アクセス平均等)が閾値を超えることを応援アクセス条件とすることにより、仲間が応援アクセス条件を満たすためには、欠落日当日の仲間のアクセスではなく、欠落日の直前の所定期間中の仲間のアクセス頻度を高める必要がある。よって、各プレイヤは、応援アクセス条件を満たすために、平素から仲間同士でお互いにアクセス頻度を高めようという意識付け、動機付けを与えられることになる。
〔ゲーム管理装置の他の構成例〕
次に、ゲーム管理装置の他の構成例を、図22の機能ブロック図を参照しながら説明する。なお、既出の図面(図1〜図21)において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。
上述のように、本ゲームシステムでは、プレイヤがゲームサーバ1にアクセスできない日(欠落日)があっても、仲間プレイヤが応援アクセス条件を満たしてくれることにより、欠落日が埋め合わせされて連続アクセス達成特典を獲得できるようになっている。そこで、プレイヤは、予めゲームサーバ1にアクセスできない予定がわかっている場合、自己の仲間にアクセス不可能予定日を通知し、応援アクセス条件を満たしてくれるように仲間に応援アクセスを事前に依頼することもできる。前記の図4または図19に例示した構成のゲームサーバ1は、メッセージ伝達手段59を具備しているので、プレイヤは、当該メッセージ伝達手段59を介して、自己の仲間にアクセス不可能予定日等を記したメッセージを送ることができる。しかしながら、仲間の人数が多い場合には、アクセス不可能予定日等を記したメッセージを、プレイヤの仲間一人ひとりに送信するには時間と労力を要することになる。そこで、本実施の形態のゲームシステムは、プレイヤがアクセス不可能予定日の情報をゲームサーバ1へ1回だけ送信すれば、ゲームサーバ1が当該プレイヤの仲間全員に、アクセス不可能予定日の情報を伝達する構成について説明する。本構成は、前記の図4または図19に例示した何れのゲームサーバ1にも、あるいは後述するゲームサーバ1にも適用できるが、以下には図4のゲームサーバ1に本構成を適用した例について説明する。
図22に示すように、本実施の形態のゲームサーバ1(ゲーム管理装置)は、図4に示した各手段51〜59に加えて、予定日伝達手段62(アクセス不可能予定日伝達手段)をさらに備えている。この予定日伝達手段62は、アクセスができない日程が予め分かっているプレイヤの端末装置3から送信されたアクセス不可能予定日の情報を受信するとともに、当該アクセス不可能予定日の情報を当該プレイヤの仲間プレイヤ全員の端末装置3へ送信し、当該アクセス不可能予定日を当該仲間プレイヤ全員へ伝達する機能を有する。この予定日伝達手段62は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。
この予定日伝達手段62は、予定日情報記憶部62aを備えている。図23には、予定日情報記憶部62aがデータベースサーバ2に記憶して管理する、予定日情報の一例を示している。この予定日情報記憶部62aは、プレイヤIDと対応付けて、アクセス不可能予定日の送信情報および受信情報を、プレイヤID毎にデータベースサーバ2の所定の記憶領域に記憶する。アクセス不可能予定日の送信情報は、プレイヤの端末装置3から送信された情報であって、図23の例では、プレイヤが自己の仲間プレイヤに通知する「アクセス不可能予定日」に加えて、仲間プレイヤ宛の「メッセージ内容」の情報が含まれている。また、アクセス不可能予定日の受信情報としては、予定日送信側のプレイヤIDが記憶されるようになっている。予定日受信側のプレイヤIDと対応づけて、予定日送信側のプレイヤIDを記憶しておけば、当該予定日送信側のプレイヤIDと対応付けて記憶されている予定日送信情報(「アクセス不可能予定日」および「メッセージ内容」)を読み出すことができる。よって、アクセス不可能予定日の受信情報としては、予定日送信側のプレイヤIDのみを記憶しておくだけでよい。
図23の例では、プレイヤID=“000001”のプレイヤ1人分の予定日情報を示しており、当該プレイヤは、アクセス不可能予定日=“2011/1/15”を、「応援アクセスお願いします!」というメッセージとともに、自己の仲間プレイヤ全員に送信している。また、プレイヤID=“000001”のプレイヤは、プレイヤID=“000002”およびプレイヤID=“000110”の2人の仲間プレイヤから、アクセス不可能予定日の情報を受け取っている。これら2人の仲間プレイヤから受け取った具体的な予定日情報(「アクセス不可能予定日」および「メッセージ内容」)は、当該2人の仲間プレイヤのプレイヤIDと対応付けて記憶されている予定日送信情報を参照して取得できる。
ここで、プレイヤが自分の仲間プレイヤに対してアクセス不可能予定日を通知する操作の一例を説明する。図24には、ゲームサーバ1から送信された画面データに基づいて、プレイヤの端末装置3に表示される「アクセス不可能予定日通知画面」の一例を示している。この画面は、例えばプレイヤが端末装置3を操作してメイン画面中の「アクセス不可能予定日通知メニュー」を選択することによって表示される画面である。このアクセス不可能予定日通知画面には、アクセス不可能予定日の入力を、プレイヤが簡単に行うことができる入力領域201が設けられている。
この入力領域201の例としては、プルダウンメニュー(プルダウンリスト)がある。当該入力領域201にカーソルを合わせて端末装置3の決定ボタンを押せば、図24に例示するように、「明日」、「2日後」、・・・「5日後」の選択項目の一覧リストが垂れ下がって表示されるようにする。この例では、明日〜5日後までのアクセス不可能予定日を選択入力できるようにしているが、これに限定されるものではなく、n日後(nは正の整数)まで選択入力できるようにしてもよい。また、「明日」等ではなく、具体的な「日付(月日)」を選択項目として表示してもよい。入力領域201の他の例としては、明日〜n日後までの複数の選択項目をラジオボタンとともにリスト表示しておき、選択項目の1つをラジオボタンにより選択入力できるようにしてもよい。あるいは、プレイヤが、アクセス不可能予定日の日付を、直接テキスト形式で入力領域201に入力できるようにしてもよい。
また、このアクセス不可能予定日通知画面には、メッセージ入力領域202および送信ボタン203というオブジェクトも表示される。そして、プレイヤは、端末装置3を操作してメッセージ入力領域203に任意のメッセージを入力し、送信ボタン203を選択することによって、端末装置3からは全ての仲間宛のメッセージが、アクセス不可能予定日の情報とともにゲームサーバ1へ送信される。図24では「応援アクセスお願いします!」というメッセージをプレイヤが入力した例を示している。なお、データベースサーバ2における記憶容量を考慮して、メッセージ入力領域202に入力できる文字に制限(例えば全角30文字以内)を設けてもよい。なお、プレイヤが、入力領域201にアクセス不可能予定日を入力し、メッセージ入力領域202にはメッセージを入力することなく送信ボタン203を押した場合は、アクセス不可能予定日のみが仲間全員に伝達されることになる。また、アクセス不可能予定日通知画面には、仲間リスト画面へ遷移するためのハイパーリンク204やメイン画面へ遷移するためのハイパーリンク205などを表示してもよい。
このアクセス不可能予定日通知画面でのプレイヤの操作により端末装置3からアクセス不可能予定日等の情報が送信された場合、ゲームサーバ1では、予定日伝達手段62の予定日情報記憶部62aが、プレイヤの端末装置3から受信した情報(「アクセス不可能予定日」および「メッセージ内容」)を、当該プレイヤのプレイヤIDと対応付けてデータベースサーバ2に記憶する(図23参照)。さらに、予定日情報記憶部62aは、予定日を送信したプレイヤの仲間プレイヤの全員を対象として、各仲間プレイヤのプレイヤIDと対応付けて、予定日送信側のプレイヤIDを記憶する(図23参照)。
そして、予定日の通知を受けた仲間プレイヤの端末装置3がゲームサーバ1へアクセスしたとき、ゲームサーバ1の予定日伝達手段62は、予定日送信側のプレイヤIDと対応付けて記憶されている「アクセス不可能予定日」および「メッセージ内容」等を表示させる画面データを、当該仲間プレイヤの端末装置3に送信する。これにより、この画面データを受信したプレイヤの端末装置3には、例えば図25に示す仲間の情報画面が表示され、プレイヤは、他の仲間のアクセス不可能予定日等を画面で確認できるようになっている。この仲間の情報画面は、ゲームのメイン画面の一部として、またはメイン画面にリンクした別画面として、端末装置3の表示部35に表示される画面である。図25の画面例では、仲間からの応援アクセス依頼情報として、アクセス不可能予定日を送信したプレイヤのアバター206、プレイヤ名207、アクセス不可能予定日208およびメッセージ209が表示されている。なお、画面に表示しきれない仲間の情報については、画面をスクロールすることにより表示することができる。また、この仲間の応援アクセス依頼情報は、アクセス不可能予定日が経過するまで、応援アクセス依頼を受けた仲間プレイヤの端末装置3の画面にて確認できるようになっている。
このように、本実施の形態のゲームシステムでは、図24に例示するようなコミュニケーションツールを使用して、プレイヤが簡単な操作によって、アクセス不可能予定日を仲間に通知できるようになっている。そして、本実施の形態では、プレイヤは、アクセス不可能予定日をゲームサーバ1へ1回だけ送信する操作を行うだけで、自己の仲間全員にアクセス不可能予定日やオリジナルメッセージを送信することが可能であり、プレイヤ側の操作の容易化が図られている。特に、ソーシャルゲーム等のプレイヤの操作の容易化が強く求められるゲームサービスには、本実施の形態の構成が好適である。
ところで、応援アクセス条件を満たしているか否かの判定は、1日に一度もゲームサーバ1へアクセスしなかった(単位期間内アクセスを達成できなかった)プレイヤに対して、アクセスの欠落が生じる度に行われる処理である。ゲームサーバ1が管理しているゲームサービス利用登録者数が多くなるほど、アクセスの欠落を生じるプレイヤの数も多くなるため、ゲームサーバ1の処理負荷は大きくなる。例えば100万人のゲームサービス利用登録者のうちの約1割にアクセスの欠落が生じただけでも、10万人程度のプレイヤに対して応援アクセス条件を満たしているか否かの判定処理が実行されることになる。そして、この応援アクセス条件を満たしているか否かの判定処理は、プレイヤがゲームサーバ1にゲーム実行を要求して行われる処理ではなく、プレイヤがゲームサーバ1へアクセスしなかったという消極的な事実に対して行われる処理でもあることから、できるだけゲームサーバ1の処理負荷を軽減して実行したい処理でもある。
そこで、図22に示す仲間応援アクセス判定手段56は、プレイヤが予定日伝達手段62によって仲間プレイヤへアクセス不可能予定日を事前に伝達した上で当該アクセス不可能予定日と同じ日にアクセスをしなかった場合に限り、当該プレイヤの仲間プレイヤが応援アクセス条件を満たしているか否かを判定するようにしてもよい。すなわち、仲間プレイヤへのアクセス不可能予定日の事前通知を、応援アクセス条件を満たしているか否かの判定を受けるための必須条件とするのである。これを前記図15のフローチャートの処理に適用した場合を例示すると、図26のフローチャートに示すようになる。
すなわち、現実世界の1日(単位期間)の終了後の処理の開始時間になれば(S31でYES)、先ず、前日が、プレイヤから仲間プレイヤへ事前通知されたアクセス不可能予定日であるか否かが判断される(S101)。そして、前日がアクセス不可能予定日であった場合(S101でYES)、応援アクセス条件を満たしているか否かの判定処理(S34およびS35)を含むS32〜S40のルーチンに移行する。一方、前日がアクセス不可能予定日でなかった場合(S101でNO)、応援アクセス条件を満たしているか否かの判定処理を含むルーチンに移行することなく、図26のフローチャートの処理を終了する。
このように、プレイヤによるアクセス不可能予定日の事前通知を、応援アクセス条件を満たしているか否かの判定処理を実行するための条件とすることにより、ゲームサーバ1は、アクセス不可能予定日に限定して、応援アクセス条件を満たしているか否かの判定処理や、当該条件を満たしている場合のその後の処理を行うため、ゲームサーバ1の処理負担を大幅に軽減できる。
また、プレイヤにとっては、仲間プレイヤへアクセス不可能予定日を事前に通知していない日に、ゲームサーバ1へアクセスをしなかった場合、応援アクセス条件を満たしているか否かの判定を受けられず、よって欠落日の埋め合わせがされることはない。よって、各プレイヤは、アクセスできそうにない日が予定されている場合、仲間に対して積極的にアクセス不可能予定日を通知して応援アクセスの事前依頼を行うようになり、これによって仲間同士のコミュニケーションの活性化が図れる。
〔ゲーム管理装置の他の構成例〕
次に、ゲーム管理装置の他の構成例を、図27の機能ブロック図を参照しながら説明する。なお、既出の図面(図1〜図26)において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。
本実施の形態では、仲間の応援アクセスによりプレイヤに連続アクセス達成特典が付与された場合、この応援アクセスに寄与した仲間にも、何らかのメリットが与えられるようにする構成について説明する。本構成は、前記の図4、図19または図22に例示した何れのゲームサーバ1にも、あるいは後述するゲームサーバ1にも適用できるが、以下には図4のゲームサーバ1に本構成を適用した例について説明する。
図27に示すように、本実施の形態のゲームサーバ1(ゲーム管理装置)は、図4に示した各手段51〜59に加えて、応援アクセス特典付与手段63をさらに備えている。この応援アクセス特典付与手段63は、欠落日(欠落単位期間)が存在するプレイヤの仲間プレイヤが応援アクセス条件を満たすことによって連続アクセス達成特典が付与されたプレイヤの仲間プレイヤであって、当該応援アクセス条件を満たすアクセスを行った仲間プレイヤに対して、ゲーム上有利になるように当該仲間プレイヤのゲーム情報を変更して応援アクセス特典を付与する機能を有する。この応援アクセス特典付与手段63は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。
ここで、応援アクセスに寄与した仲間プレイヤに付与される応援アクセス特典とは、当該特典が付与されなかった場合と比較してゲーム上有利になるものであればよく、連続アクセス達成特典と同様に、ゲームの種類や内容に応じて様々な特典を適用できる。ただし、特典の大きさ(メリットの程度)については、連続アクセス達成プレイヤに対して付与される連続アクセス達成特典よりも、連続アクセス達成の一助となった仲間プレイヤに対して付与される応援アクセス特典の方が、小さな特典とすることが望ましい。例えば、連続アクセス達成特典が200ポイント分の強化ポイントであった場合、応援アクセス特典は50〜100ポイント分の強化ポイントとする。また、例えば、連続アクセス達成特典を回復アイテム3つとするのに対して、応援アクセス特典をフェイクカード1つとする等、連続アクセス達成特典と応援アクセス特典とで特典の種類を変えてもよい。
次に、図28のフローチャートを参照しながら、本実施の形態のゲーム管理装置(ゲームサーバ1)の動作について説明する。図28は、ある一人のプレイヤを中心とした仲間というグループに対して実行される処理の流れを示すものであり、ゲームサーバ1が管理している各々のプレイヤを中心としたグループに対して同様の処理が行われる。
あるプレイヤに連続アクセス達成特典が付与された場合(S111)、当該プレイヤが欠落日の埋め合わせなしに連続アクセスを達成したのか、それともアクセスの欠落日があったにもかかわらず仲間の応援アクセスにより欠落日が埋め合わされたことによって連続アクセスを達成したのかが判断される(S112)。この判断は、プレイヤIDと対応付けて記憶されている図9(a)に例示するアクセス情報(日々のアクセスの有無および応援アクセス条件達成を示す情報)に基づいて行うことができる。
ここで、プレイヤが欠落日の埋め合わせなしに連続アクセスを達成していた場合(S112でNO)、当該プレイヤの仲間プレイヤに応援アクセス特典を付与する処理を行うことなく図28に示すルーチンを終了する。一方、欠落日が埋め合わされたことによってプレイヤが連続アクセスを達成していた場合(S112でYES)、ゲームサーバ1の応援アクセス特典付与手段63は、欠落日の埋め合わせに寄与した仲間プレイヤ、すなわち応援アクセス条件を満たすアクセスを行った仲間プレイヤを抽出する(S113)。
このS113における仲間プレイヤの抽出処理は、応援アクセス条件が「欠落日と同じ日にゲームサーバ1へアクセスした仲間プレイヤの人数または当該仲間プレイヤ全体に占める割合が、閾値を超えること」であった場合、次のようにして実現できる。すなわち、応援アクセス条件が満たされた欠落日と同じ日に、ゲームサーバ1へアクセスした仲間プレイヤを、プレイヤIDと対応付けて記憶されている図9(a)に例示するアクセス情報(日々のアクセスの有無の情報)に基づいて抽出する。
また、応援アクセス条件が「欠落日が存在するプレイヤの仲間というグループの評価値が、閾値を超えること」であった場合、S113の抽出処理は次のようにして実現できる。例えばグループの評価値が仲間アクセス平均であり、閾値が0.8であった場合、アクセス平均が0.8以上の仲間プレイヤを抽出する。
また、グループの評価値が仲間プレイヤのアクセス頻度の合計値の場合、アクセス頻度が0ではない仲間プレイヤが応援アクセス条件を満たすために寄与したことになるので、アクセス頻度が0でない仲間プレイヤを全て抽出してもよい。但し、アクセス頻度の高さによって寄与の程度は大きく異なるので、アクセス頻度が高い仲間プレイヤほど、応援アクセス特典を高くする構成にしてもよい。また、その寄与の程度が極めて低いアクセス頻度が所定の値以下の仲間プレイヤについては、S113の抽出の対象から除外してもよい。
また、グループの評価値が「グループ内のアクセス頻度の最大値」であった場合、当該最大値の仲間プレイヤのみを抽出する。この場合、抽出される仲間プレイヤは一人だけあり、その寄与の程度は大きいことから、他の応援アクセス条件のときに比べて応援アクセス特典を大きくしてもよい。また、グループの評価値が「グループ内のアクセス頻度の最小値」であった場合、全ての仲間プレイヤが応援アクセス条件を満たすために寄与したことになるので、仲間プレイヤを全て抽出してもよい。
S113の後、応援アクセス特典付与手段63は、ゲーム上有利になるように、抽出した仲間プレイヤのゲーム情報を変更して応援アクセス特典を付与する(S114)。例えば、所定の強化ポイントを応援アクセス特典として仲間プレイヤに付与する場合、当該仲間プレイヤのプレイヤIDに対応するゲーム情報(図6に例示するプレイヤの強化ポイントの情報)が変更されることになる。
応援アクセス特典が付与されたプレイヤに対しては、当該特典の付与後にプレイヤの端末装置3がゲームサーバ1に最初にアクセスしたとき、ゲームサーバ1より当該特典が付与された旨を報知する画面データが、プレイヤの端末装置3へ送信される。これにより、プレイヤは、自分の応援アクセスによって仲間が連続アクセス達成特典を獲得したこと、およびそれによって自分にも応援アクセス特典が付与されたことを認識できる。
以上のように、欠落日が存在するプレイヤの仲間プレイヤが応援アクセス条件を満たすことによって当該プレイヤに連続アクセス達成特典が付与された場合、応援アクセスに寄与した仲間プレイヤにも応援アクセス特典を付与することにより、各プレイヤは、仲間の応援アクセスを積極的に行おうとする意識付け、動機付けが与えられることになる。
次に、プレイヤを中心とする仲間というグループの中に、連続アクセス達成特典を獲得した仲間プレイヤが所定の人数以上または所定の割合以上いる場合、当該プレイヤにさらなるメリットが与えられるようにする構成について説明する。本構成は、前記の図4、図19または図22に例示した何れのゲームサーバ1にも、あるいは後述するゲームサーバ1にも適用できるが、以下には図4のゲームサーバ1に本構成を適用した例について説明する。
図27に示すように、本実施の形態のゲームサーバ1(ゲーム管理装置)は、図4に示した各手段51〜59に加えて、仲間特典付与手段64をさらに備えている。この仲間特典付与手段64は、プレイヤを中心とする仲間というグループの中に連続アクセス達成特典が付与された仲間プレイヤが所定の人数以上または所定の割合以上いる当該プレイヤに対して、ゲーム上有利になるように当該プレイヤのゲーム情報を変更して仲間特典を付与する機能を有する。この仲間特典付与手段64は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。
ここで、各プレイヤを中心とするグループ内の連続アクセス達成特典が付与された仲間プレイヤの人数または割合を求めるに際しては、当該中心となるプレイヤを含めてもよいし、当該中心となるプレイヤを除外してもよい。なお、仲間を一人も作っていないプレイヤに関しては、当該プレイヤを中心とする仲間というグループ自体が存在しないため、仲間特典が付与されることはない。
ここで、仲間特典とは、当該特典が付与されなかった場合と比較してゲーム上有利になるものであればよく、連続アクセス達成特典と同様に、ゲームの種類や内容に応じて様々な特典を適用できる。この仲間特典は、自己の仲間グループ内に連続アクセス達成特典を獲得した仲間プレイヤが所定の人数以上または所定の割合以上いる必要がある達成難易度の高い特典であるため、その特典の大きさ(メリットの程度)については、連続アクセス達成プレイヤに対して付与される連続アクセス達成特典と同程度またはそれよりも大きい特典とすることもできる。例えば、連続アクセス達成特典が200ポイント分の強化ポイントであった場合、仲間特典は200〜300ポイント分の強化ポイントとする。また、例えば、連続アクセス達成特典を200ポイント分の強化ポイントとするのに対して、仲間特典を回復アイテム3つとする等、連続アクセス達成特典と仲間特典とで特典の種類を変えてもよい。
この仲間特典を適用する例としては、前述の期間限定のゲーム内イベントにおいて適用することができる。すなわち、当該イベント期間中の連続アクセスの達成者に対して連続アクセス達成特典を付与するとともに、当該イベント期間中にグループ内に連続アクセス達成特典を獲得した仲間プレイヤが所定の人数以上または所定の割合以上いるプレイヤに対して仲間特典を付与する。
また、前記の期間限定のゲーム内イベントを開催していない通常時においても、所定の期間(例えば毎週月曜日から日曜日)を定めて、当該期間中にグループ内に連続アクセス達成特典を獲得した仲間プレイヤが所定の人数以上または所定の割合以上いるプレイヤに対して、仲間特典を付与してもよい。
次に、図29のフローチャートを参照しながら、本実施の形態のゲーム管理装置(ゲームサーバ1)の動作について説明する。図29は、ある一人のプレイヤに対して実行される処理の流れを示すものであり、ゲームサーバ1が管理している各々のプレイヤに対して同様の処理が行われる。
仲間特典を付与するか否かを判定する所定の期間が終了すると(S121)、ゲームサーバ1は、プレイヤに仲間が存在するか否かを判断する(S122)。ここで、プレイヤが一人も仲間を作っていなかった場合(S122でNO)、ゲームサーバ1は、当該プレイヤに対しては仲間特典を付与するか否かの判定を行うことなく処理を終了する。一方、プレイヤに仲間が存在する場合(S122でYES)、ゲームサーバ1の仲間特典付与手段64は、仲間管理手段53が管理しているプレイヤの仲間情報および連続アクセス特典付与手段57が連続アクセス達成特典をプレイヤに付与した情報(図6に例示する特典情報)に基づいて、プレイヤを中心とするグループ内の連続アクセス達成特典が付与された仲間プレイヤの人数または割合を求める(S123)。なお、図29では、仲間プレイヤの人数Nを求める例を示している。
その後、仲間特典付与手段64は、S123で求めた人数Nが所定の閾値(図29では閾値を10とした例を示している)以上であるか否かを判定する。ここで、人数Nが閾値より小さい場合は(S124でNO)、プレイヤに仲間特典が付与されることなく終了する。一方、人数Nが閾値以上の場合(S124でYES)、仲間特典付与手段64は、ゲーム上有利になるようにプレイヤのゲーム情報を変更して、仲間特典を付与する(S125)。例えば、所定の強化ポイントを仲間特典としてプレイヤに付与する場合、当該プレイヤのプレイヤIDに対応するゲーム情報(図6に例示するプレイヤの強化ポイントの情報)が変更されることになる。
仲間特典が付与されたプレイヤに対しては、当該特典の付与後にプレイヤの端末装置3がゲームサーバ1に最初にアクセスしたとき、ゲームサーバ1より当該特典が付与された旨を報知する画面データが、プレイヤの端末装置3へ送信される。これにより、プレイヤは、自己の仲間グループの中に連続アクセス達成特典を獲得した仲間プレイヤが閾値以上いたことにより、仲間特典が付与されたことを認識できる。
以上のように、本実施の形態では、プレイヤを中心とする仲間というグループの中に、連続アクセス達成特典を獲得した仲間プレイヤが所定の人数以上または所定の割合以上いる場合、当該プレイヤに仲間特典が付与されるという構成である。この構成が「応援アクセスによる欠落日の埋め合わせによって仲間が連続アクセス達成特典を獲得し易くなる」という構成と相俟って、各プレイヤには、自己の仲間の多くが連続アクセス達成特典を獲得できるようにアクセス頻度を高めようとする意識付け、動機付けが与えられることになる。すなわち、連続アクセス達成特典だけではなく、さらに仲間特典を獲得するチャンスがあり、自分が連続アクセス達成特典を獲得するためだけでなく、多くの仲間プレイヤが連続アクセス達成特典を獲得できるようにするために、プレイヤはゲームサーバ1へのアクセス頻度を高めようとする動機付けが与えられる。また、連続アクセスが途中で途絶えて連続アクセス達成特典を獲得できなくなったプレイヤにとっても、自己の仲間プレイヤの多くが連続アクセス達成特典を獲得すれば仲間特典を獲得するチャンスがある。よって、応援アクセスにより多くの仲間プレイヤが連続アクセス達成特典を獲得できるようにするために、プレイヤはゲームサーバ1へのアクセス頻度を高めようとする動機付けが与えられる。
〔ゲーム管理装置の他の構成例〕
次に、ゲーム管理装置の他の構成例を、図30の機能ブロック図を参照しながら説明する。なお、既出の図面(図1〜図29)において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。本実施の形態の構成は、前記の図4、図19、図22または図27に例示した何れのゲームサーバ1にも、あるいは後述するゲームサーバ1にも適用できるが、以下には図4のゲームサーバ1に本構成を適用した例について説明する。
図30に示すように、本実施の形態のゲームサーバ1(ゲーム管理装置)は、図4に示した各手段51〜59に加えて、アクセス頻度表示制御手段100(表示制御手段)をさらに備えている。このアクセス頻度表示制御手段100は、アクセスを受け付けたプレイヤの端末装置3に、他のプレイヤのアクセス頻度の情報を含む画面データ(表示制御情報)を送信することによって、プレイヤの端末装置3の画面に、他のプレイヤのアクセス頻度を表示させる機能を有する。このアクセス頻度表示制御手段100は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。
本ゲームシステムにおいては、アクセスの欠落が生じたときに、プレイヤの仲間による応援アクセスの如何によって欠落日の埋め合わせがなされるか否かが決まるので、プレイヤにとっては、これから仲間になるプレイヤや既に仲間になっているプレイヤのアクセス頻度の情報は重要である。そこで、本実施の形態のアクセス頻度表示制御手段100は、各プレイヤの便宜に供するための情報として、他のプレイヤのアクセス頻度の情報を、プレイヤの端末装置3の画面に表示させるようになっている。
ここで、他のプレイヤのアクセス頻度が表示される画面の例としては、図31に示すような仲間候補リスト画面が挙げられる。この仲間候補リスト画面は、仲間を作ろうとするプレイヤが、自己の端末装置3で仲間候補を検索するゲーム操作を行うことにより、ゲームサーバ1から送信されてくるゲーム画面の一つである。この仲間候補リスト画面には、ゲームサーバ1により抽出された、プレイヤとは未だ仲間関係にない複数のプレイヤが、仲間候補者としてリストアップされて表示される。なお、画面に表示しきれない仲間候補プレイヤの情報については、画面をスクロールして表示するか、または仲間候補リストの2ページ目以降をゲームサーバ1にリクエストして別画面として表示することができる。仲間候補リスト画面内には、リストアップされた仲間候補のプレイヤ毎の情報表示領域が設けられており、各情報表示領域には、仲間候補プレイヤのゲーム情報111(プレイヤ名、チーム名、プレイヤのレベル、仲間の人数、所属リーグのレベル等)、仲間候補プレイヤの分身的なキャラクタであるアバター112、仲間候補プレイヤが所有するリーダーの選手カード113等とともに、仲間候補プレイヤのアクセス頻度114が表示される。
プレイヤは、この仲間候補リスト画面でリストアップされた他のプレイヤの情報を確認し、仲間申請したいと思うプレイヤを見つけることになる。また、この仲間候補リスト画面で、例えばプレイヤ名のハイパーリンク111aを選択する操作がなされれば、ゲームサーバ1が当該操作に応答し、当該プレイヤ名のプレイヤについてのより詳細なゲーム情報(例えば、リーダーの選手カード113の能力値など)を表示する画面データを端末装置3へ送信する。この画面データには、仲間申請ボタンやエールボタン(またはそれらのハイパーリンク)も含まれており、プレイヤは端末装置3を操作して仲間申請やメッセージの送信ができるようになっている。
ここで、画面に表示されるアクセス頻度114の情報としては、例えば、所定期間中のプレイヤのアクセス平均(例えば直近7日間のアクセス平均)の値とすることができる。本実施の形態では、図9(a)または(b)に例示するように、アクセス管理手段55のアクセス情報記憶部55aが、n日前までのアクセスの有無またはアクセス回数の情報を、プレイヤID毎に記憶しているので、この情報より直近n日間のアクセス平均を算出し、算出したアクセス平均を画面に表示されるアクセス頻度114の情報とすることができる。
画面に表示されるアクセス頻度114の情報は、直近n日間のアクセス平均に限定されるものではなく、例えば、先週のアクセス平均、先月のアクセス平均、直近n日間の合計アクセス回数、先週の合計アクセス回数、先月の合計アクセス回数など、プレイヤの過去のアクセス頻度が分かる情報であればよい。あるいは、アクセス頻度114の情報を多段階表示、例えばA〜Cの3段階(A:アクセスが多い、B:アクセスが普通、C:アクセスが少ない)で表示してもよい。
このように、本実施の形態では、プレイヤが仲間を作ろうとするときに端末装置3の表示部35に表示される仲間候補リスト画面において、リストアップされる各プレイヤの過去のアクセス頻度を表示する。これにより、プレイヤは、画面上で他のプレイヤのアクセス頻度を見て、仲間を作るときの一つの目安とすることができる。すなわち、本実施の形態では、アクセスの欠落が生じた際に仲間による応援アクセス条件を満たすためには、仲間のアクセス頻度が高いことが望まれるので、アクセス頻度が仲間を作るときの一つの目安となるのである。
なお、仲間候補リスト画面には、アクセス頻度の情報以外にも、各プレイヤのレベルや能力を表す情報(プレイヤレベルや所属リーグのレベルなど)も併せて表示されるところ、上記の構成によれば、プレイヤは、他のプレイヤを仲間にするか否を判断する際に、当該プレイヤのレベルや能力等のみならず、アクセス頻度も考慮し、これらを総合的に判断して、仲間にしたい他のプレイヤを選ぶことができる。
また、仲間申請を受けたプレイヤにおいても、当該プレイヤの端末装置3の図示しない画面には、仲間申請をしたプレイヤの情報の一つとしてアクセス頻度が表示されるようになっており、当該アクセス頻度を、仲間申請を承認するか否かを判断する際の一つの目安とすることもできる。
他のプレイヤのアクセス頻度が表示される画面の他の例としては、図32に示すような仲間リスト画面が挙げられる。上述したように仲間リスト画面には、プレイヤと仲間関係にある仲間プレイヤの情報がリストアップされて表示される。この仲間リスト画面には、仲間プレイヤのゲーム情報81(プレイヤ名、チーム名、プレイヤのレベル、仲間の人数、所属リーグのレベル等)、アバター82、所有するリーダーの選手カード83、エールボタン84等とともに、当該仲間プレイヤのアクセス頻度114が表示される。このアクセス頻度114は、前述したとおり、プレイヤの過去のアクセス頻度が分かる情報であればよく、例えばプレイヤの直近n日間のアクセス平均等である。
このように、仲間リスト画面に仲間プレイヤのアクセス頻度114が表示されることにより、次のような利用も可能になる。すなわち、アクセスを欠落したときに仲間が応援アクセス条件を満たしてくれるように、常日頃から自己のグループに所属する仲間プレイヤ全体のアクセス頻度を高めておくことが望ましい。そこで、仲間リスト画面に表示されたアクセス頻度114に基づいて、アクセス頻度が低い仲間プレイヤを把握し、当該仲間プレイヤに対し応援メッセージ等を送信してアクセス頻度を上げるように仕向けることにより、効率的にグループ全体のアクセス頻度を高めることができる。
ここで、各仲間プレイヤのアクセス頻度114の把握をさらに容易化するために、アクセス頻度の低い方(または高い方)から順に仲間プレイヤの画面上の表示順序を並べかえるための表示順変更ボタン(その他の選択可能なオブジェクトであってもよい)を、プレイヤの端末装置3に表示してもよい。この表示順変更ボタンを選択する操作がプレイヤの端末装置3においてなされた場合、当該操作に応じてゲームサーバ1が、アクセス頻度の低い方(または高い方)から順に仲間プレイヤを並び替えた画面データを端末装置3へ送信する。この画面データを受信した端末装置3にはアクセス頻度順に並べられた仲間プレイヤが表示されるので、プレイヤは、アクセス頻度の低かった仲間プレイヤを迅速に把握でき、当該仲間プレイヤに対して即座に応援メッセージ等の送信ができるようになる。
〔ゲーム管理装置の他の構成例〕
次に、ゲーム管理装置のさらに他の構成例を、図33の機能ブロック図を参照しながら説明する。なお、既出の図面(図1〜図32)において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。
本実施の形態では、プレイヤの仲間の一部または全部の仲間登録を、当該プレイヤの意思に基づいて解除することができるようになっているゲームシステムについて説明する。プレイヤがアクセスを欠落したときに、その欠落日の埋め合わせの可能性を高める(仲間プレイヤが応援アクセス条件を満たす可能性を高める)ためには、自己のグループ内の仲間プレイヤのアクセス頻度が高いことが望まれるが、プレイヤが仲間登録を自由に解除できる場合、次のような事態も考えられる。すなわち、アクセス頻度の低い仲間プレイヤに応援メッセージを送ってアクセス頻度を高めようとするのではなく、アクセス頻度の低い仲間プレイヤの仲間登録を解除することによって欠落日の埋め合わせの可能性を高めようとする、本来の目的とはかけ離れた方法を採ろうとするプレイヤが出てくる可能性も考えられる。そこで、この対策として、本実施の形態では、以下に説明するように、プレイヤが仲間登録を解除した場合、当該解除から一定期間、応援アクセス条件を厳しくすることによって連続アクセス達成特典が付与され難くする、又は本来得られる連続アクセス達成特典を小さくする構成を採用するものである。この構成は、前記の図4、図19、図22、図27または図30に例示した何れのゲームサーバ1にも適用できるが、以下には図4のゲームサーバ1に本構成を適用した例について説明する。
図33に示すように、本実施の形態のゲームサーバ1(ゲーム管理装置)は、図4に示した各手段51〜59に加えて、特典付与調整手段121をさらに備えている。また、本実施の形態の仲間管理手段53は、仲間登録解除手段122をさらに備えている。前記の特典付与調整手段121および仲間登録解除手段122は、ゲームサーバ1のCPU11が本実施の形態に係るプログラムを実行することにより実現されるものである。
前記の仲間登録解除手段122は、各プレイヤから仲間登録の解除を受け付ける機能を有する。この仲間登録解除手段122の動作例を以下に示す。
例えば、プレイヤA(プレイヤID=“000001”)が端末装置3を操作し、仲間プレイヤB(プレイヤID=“000002”)の登録を解除する操作を行ったとき、当該操作に応じた通信データ(リクエスト)がゲームサーバ1へ送信される。この通信データを受信したゲームサーバ1では、仲間登録解除手段122が、プレイヤAおよびプレイヤB相互間の仲間登録を解除する。
すなわち、仲間情報記憶部53aが記憶している、図34(a)に例示するプレイヤ毎の仲間情報について、仲間登録解除手段122は、プレイヤAのプレイヤID=“000001”と対応づけて記憶されている仲間プレイヤIDの情報欄から、プレイヤBのプレイヤID=“000002”を削除する(同図中では、便宜上、二重取り消し線でこれを示している)。さらに、仲間登録解除手段122は、プレイヤAのプレイヤID=“000001”と対応づけて、仲間登録解除情報を記録する。ここで記録される仲間登録解除情報とは、解除相手であるプレイヤBのプレイヤID=“000002”、解除日及び解除者フラグの情報等である。解除者フラグとは、例えば仲間登録を解除した側を「1」、解除された側を「0」として、両者を区別するための情報である。図34(a)の例では、プレイヤAが仲間登録を解除した側であるため、解除者フラグ=1が設定されている。
さらに、図34(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の処理例を、図35のフローチャートに示す。
図35において、S31〜S34については、基本的には図15のフローチャートで説明した処理と同様の処理である。S34の後、プレイヤが所定期間内、例えば直近の4週間以内に仲間登録の解除を行っているか否かが判断される(S130)。このS130の判断は、例えば図34(a)に示すように、仲間管理手段53が管理する各プレイヤの仲間登録解除情報(解除日及び解除者フラグ)に基づいて行うことができる。すなわち、4週間以内に仲間登録の解除を行っているプレイヤとは、当該プレイヤのプレイヤIDに対応付けられた仲間登録解除情報として、4週間以内の解除日および解除者フラグ=1の情報を有するプレイヤである。
プレイヤが4週間以内に仲間登録の解除を行っていない場合(S130でNO)、S34で算出された割合Rが例えば0.8以上という応援アクセス条件を満たしているか否かが判定される(S35)。一方、プレイヤが4週間以内に仲間登録の解除を行っている場合(S130でYES)、前記S35より厳しい応援アクセス条件となるように、S34で算出された割合Rが例えば0.9以上であるか否かが判定される(S131)。すなわち、特典付与調整手段121は、プレイヤが4週間以内に仲間登録の解除を行っている場合における応援アクセス条件の閾値を、その解除を行っていない場合よりも高く設定することによって、仲間登録を解除したプレイヤに対して欠落日の埋め合わせの困難性を高めている。なお、以降の処理(S36〜S40)は、基本的には図15のフローチャートで説明した処理と同様の処理であり、その説明を省略する。
この図35に例示した処理により、仲間登録の解除をしたプレイヤは、仲間登録の解除から4週間、仲間登録の解除がない場合に比べて、応援アクセス条件が厳しくなる。これにより、アクセス頻度の低い仲間プレイヤの仲間登録を解除することによって欠落日の埋め合わせの可能性を高めようとしても、仲間登録を解除したことによって、一定期間(この例では4週間)応援アクセス条件が厳しくなり、結果的にアクセスを欠落したときに連続アクセス達成特典を獲得し難くなる。よって、欠落日の埋め合わせの可能性を高めるために仲間登録を解除するといった、本来の目的とはかけ離れた行動をプレイヤがとることを効果的に抑制できる。
また、特典付与調整手段121を備えたゲームサーバ1の他の処理例を、図36のフローチャートを参照して、以下に説明する。
図36において、S51〜S57については、基本的には図16のフローチャートで説明した処理と同様の処理である。プレイヤの連続アクセス日数が5日に達している場合(S56でYES)、連続アクセス特典付与手段57が、ゲーム上有利になるように当該プレイヤのゲーム情報を変更して連続アクセス達成特典を付与する(S57)。例えば、200ポイント分の強化ポイントがボーナスポイントとしてプレイヤに付与される。
その後、当該プレイヤが欠落日の埋め合わせなしに連続アクセスを達成したのか、それともアクセスの欠落日があったにもかかわらず仲間の応援アクセスにより欠落日が埋め合わされたことによって連続アクセスを達成したのかが判断される(S141)。ここで、欠落日が埋め合わされたことによってプレイヤが連続アクセスを達成していた場合(S141でYES)、特典付与調整手段121は、プレイヤが所定期間内、例えば直近の4週間以内に仲間登録の解除を行っているか否かを判断する(S142)。ここで、プレイヤが4週間以内に仲間登録の解除を行っている場合(S142でYES)、特典付与調整手段121は、プレイヤに付与される連続アクセス達成特典を、前記S57で付与される特典(200強化ポイント)よりも縮小して、例えば100強化ポイントへと調整する(S143)。なお、以降の処理(S58〜S64)は、基本的には図16のフローチャートで説明した処理と同様の処理であり、その説明を省略する。
この図36に示した処理により、仲間登録の解除をしたプレイヤは、仲間登録の解除から4週間、仲間登録の解除がない場合に比べて、欠落日が埋め合わされたことによって獲得した連続アクセス達成特典が縮小される。これにより、アクセス頻度の低い仲間プレイヤの仲間登録を解除することによって欠落日の埋め合わせの可能性を高めようとしても、仲間登録を解除したことによって、一定期間(この例では4週間)、本来得られるはずの連続アクセス達成特典よりも小さい特典しか得られなくなる。よって、欠落日の埋め合わせの可能性を高めるために仲間登録を解除するといった、本来の目的とはかけ離れた行動をプレイヤがとることを効果的に抑制できる。
なお、図35および図36に示した上記の例では、仲間登録の解除から4週間を、仲間登録を解除したペナルティの期間として、連続アクセス達成特典そのものを付与され難くする又は本来の連続アクセス達成特典よりも小さい特典を付与することにより特典の付与調整をしているが、これに限定されるものではなく、例えば、当該期間を1週間〜3週間程度に短縮してもよいし、逆に4週間よりも長く設定してもよく、任意の期間を設定可能である。
また、上記の例では、所定期間内に1人でも仲間登録の解除を行えば、特典付与調整手段121による連続アクセス達成特典の付与調整が行われる例について説明したが、これに限定されるものではなく、例えば、所定期間内にn人以上(例えば1週間以内に2人以上)の仲間登録を解除した場合にのみ特典の付与調整が行われるようにしてもよい。
ところで、プレイヤがアクセス頻度の低い仲間プレイヤに応援メッセージを送って仲間のアクセスを高める努力をしたにもかかわらず、当該仲間プレイヤのアクセス頻度が低いままであるため、やむなく仲間登録を解除する場合もあり得る。そこで、プレイヤが仲間登録を解除する場合でも、メッセージを所定回数送信したにも関わらずアクセス頻度が低いままの仲間プレイヤを仲間から外す場合と、そのようなメッセージの送信もなく仲間登録を解除する場合とでは、その効果を異ならせることが望ましい。
そこで、本実施の形態に係るゲームサーバ1の特典付与調整手段121は、仲間登録の解除をしたプレイヤが、当該仲間登録の解除前の所定期間中(例えば、解除前の2週間以内)に、解除対象の仲間プレイヤ宛に所定回数以上(例えば2回以上)のメッセージを送信している場合は、前記の特典の付与調整を行わないように構成されている。このように構成された典付与調整手段121を備えたゲームサーバ1の処理例を、図37のフローチャートに示す。
図37において、S31〜S34については、基本的には図15のフローチャートで説明した処理と同様の処理である。S34の後、プレイヤが所定期間内、例えば直近の4週間以内に仲間登録の解除を行っているか否かが判断される(S150)。このS150の処理は、基本的に図35のS130と同様の処理である。ここで、プレイヤが4週間以内に仲間登録の解除を行っていない場合(S150でNO)、S34で算出された割合Rが例えば0.8以上という応援アクセス条件を満たしているか否かが判定されることになる(S35)。
一方、プレイヤが4週間以内に仲間登録の解除を行っている場合(S150でYES)、特典付与調整手段121は、仲間登録の解除をしたプレイヤが、例えばその解除前の2週間以内に2回以上、解除対象の仲間プレイヤ宛にメッセージを送信しているか否かを判断する(S151)。
前記S151における判断には、仲間管理手段53の仲間情報記憶部53aが記憶している、例えば図34(a)に示す各プレイヤの仲間登録解除情報(各プレイヤのプレイヤIDと対応付けて記憶されている、解除相手プレイヤID、解除日及び解除者フラグ)、およびメッセージ伝達手段59のメッセージ記憶部59aが記憶している、例えば図12に示すメッセージに関する情報(受信側プレイヤのプレイヤIDと対応付けて記憶されている、送信元のプレイヤIDおよび送信日時などの情報)が用いられる。すなわち、プレイヤが仲間登録を解除した「解除対象の仲間プレイヤ」については、図34(a)に示す仲間登録解除情報の中の「解除相手プレイヤID」として特定できる。また、「解除前の2週間以内の期間」については、前記の仲間登録解除情報の中の「解除日」に基づいて特定できる。また、「解除対象の仲間プレイヤ宛に仲間登録を解除した側のプレイヤがメッセージを送信したか否か」については、図12に示す「受信側プレイヤID」を解除相手プレイヤIDとした場合における、「送信元プレイヤID」として、仲間登録の解除をした側のプレイヤのプレイヤIDが含まれているか否かを確認することにより判断できる。また、前記の「送信元プレイヤID」とともに「送信日時」の情報も併せて記憶されているので、仲間登録の解除をしたプレイヤから解除対象の仲間プレイヤへのメッセージが、解除前の2週間以内に送信されたものか否かが判断できる。
このS151において、仲間登録の解除をしたプレイヤが、その解除前2週間以内に2回以上、解除対象の仲間プレイヤ宛にメッセージを送信していなかった場合(S151でNO)、前記S35より厳しい応援アクセス条件となるように、S34で算出された割合Rが例えば0.9以上であるか否かが判定される(S131)。すなわち、特典付与調整手段121は、応援アクセス条件の閾値を、S35における閾値(0.8)よりも高い値(0.9)に設定することによって、仲間登録を解除したプレイヤであって、その解除前2週間以内に2回以上、解除対象の仲間プレイヤ宛にメッセージを送信していないプレイヤに対して、応援アクセス条件を厳しくして連続アクセス達成特典を発生し難くしている。
一方、仲間登録の解除をしたプレイヤが、その解除前2週間以内に2回以上、解除対象の仲間プレイヤ宛にメッセージを送信していた場合(S151でYES)、前記S131に移行することなく、前記S35に移行する。すなわち、応援アクセス条件の閾値として0.8が使用され、特典の付与調整がされることはない。なお、以降の処理(S36〜S40)は、基本的には図15のフローチャートで説明した処理と同様の処理であり、その説明を省略する。
この図37に示した処理により、仲間登録の解除をしたプレイヤは、原則、仲間登録の解除から4週間、仲間登録の解除がない場合に比べて、応援アクセス条件が厳しくなって連続アクセス達成特典が付与され難くなるが、例外として仲間登録の解除前2週間以内に2回以上、解除対象の仲間プレイヤへメッセージを送信している場合は、応援アクセス条件が厳しくなることはない。これにより、仲間登録を解除したプレイヤに対して、その解除前に応援メッセージを送って仲間のアクセスを高める努力をしたプレイヤが、特典の付与調整(連続アクセス達成特典を付与され難くする又は当該特典を小さくする処理)の対象となることを回避できる。よって、応援メッセージを仲間に送信して仲間のアクセスを高めようとすることもなく、欠落日の埋め合わせの可能性を高めるためにアクセス頻度の低い仲間プレイヤの仲間登録を解除するプレイヤのみを対象とした効果的な対策を講じることができ、そのような本来の目的とはかけ離れた行動をプレイヤがとることをより効果的に抑制できる。
なお、図37に示した例では、仲間登録の解除をしたプレイヤが、その解除前2週間以内に2回以上、解除対象の仲間プレイヤ宛にメッセージを送信していることを、特典の付与調整が行われない条件としているが、これに限定されるものではない。例えば、仲間登録解除前のメッセージの送信条件(特典の付与調整が行われないための条件)を、解除前1週間以内に1回以上に設定したり、あるいは解除前1か月以内に3回以上に設定したりしてもよく、仲間登録解除前の期間および当該期間中のメッセージ送信回数の条件については、任意に設定することができる。
〔他の実施の形態〕
上述の実施の形態では、ゲーム実行プログラムがゲームサーバ1側に実装されており、各プレイヤの端末装置3における入力操作に応じて、ゲームサーバ1がゲーム進行のための演算処理やデータ処理を実行し、その実行結果を反映させた画面データを端末装置3へ送信することによって、ゲームが進行するゲームシステムへの適用例について説明したが、これに限定されるものではない。例えば、ゲームサーバ1が、プレイヤのアクセス情報、仲間情報、メッセージ情報、特典情報などのゲーム情報を管理し、ゲーム内でのプレイヤ間のメッセージのやり取りや特典付与等のゲームサービスをプレイヤに提供する一方、ゲームを進行させるゲーム実行処理については、基本的にはプレイヤの端末装置側にて行われるゲームシステムにも本発明を適用できる。
すなわち、ゲーム実行プログラムの一部または全部をプレイヤの端末装置側にダウンロードまたはインストールし、端末装置においてもゲーム実行処理が行われるようなゲームシステムにも本発明を適用できる。よって、プレイヤの端末装置としては、ネットワーク経由でゲームサーバ(ゲーム管理装置)に接続してゲームサービスの提供を受けることができる様々なものが適用でき、前述の携帯電話端末、PHS端末、携帯情報端末(PDA)、スマートフォン、パーソナルコンピュータ、タブレット型コンピュータ以外にも、ネットワーク接続機能を有している家庭用ビデオゲーム装置(家庭用ビデオゲーム機を家庭用テレビジョンに接続することによって構成されるゲーム装置)や、携帯型のゲーム専用装置なども適用可能である。
また、本実施の形態に係るコンピュータ読み取り可能なプログラムは、ハードディスク、光ディスク(CD−ROM、DVD−ROM等)、フレキシブルディスク、半導体メモリ等のコンピュータ読み取り可能な各種記録媒体に記録され、当該記録媒体から読み出されてゲームサーバ1のCPU11により実行される。また、プログラムをゲームサーバ1に提供する手段は、前述した記録媒体に限定されるものではなく、インターネット等の通信ネットワークを介して行うこともできる。