JP6080371B2 - サーバシステム - Google Patents

Description

本発明は、ゲームに係る各プレーヤのパラメータを管理し、各プレーヤのプレーヤ端末と通信を行ってゲームを進行制御するサーバシステムに関する。

ゲームでは、ゲーム進行状況を記述する様々なパラメータが用意され、ゲームの進行に応じてそれらが適宜変更される。そうしたパラメータは基本的にそのゲーム内でのみ利用可能であり、そのゲーム内での状況変化に応じてのみ変更される。例えば、何らかのアイテムを使用するとパラメータが変更される場合でも、その効果範囲はそのゲーム内に限られている（例えば、特許文献１参照）。

特開２０１０−２３３６５４号公報

近年のＳＮＳ（Social Networking Service）などコミュニティ型のウェブサイトでは、サービスの一環として複数のゲームを用意して、ユーザが任意にゲームを選択してプレイできるようになっており、こうしたゲームはＳＮＳゲーム或いはソーシャルゲームなどと呼ばれている。しかし、ＳＮＳゲームであっても、ユーザによっては、お気に入りのゲームを一つ見つけると、そのゲームをとことんやり込むケースが見受けられる。ゲームサプライヤーの立場からすると、他にも楽しいゲームがあって是非プレイしてみて欲しいところである。
他方、こうしたＳＮＳゲームにおいても、ゲーム同士は連動することが無く、パラメータの変更はそのゲーム内に限られていた。

本発明は、上述した技術背景及び課題に鑑みてなされたものであり、一のゲームを継続的にプレイしているプレーヤを、他のゲームのプレイに誘うことを可能とする技術を提供することを目的とする。なお、本発明の課題は、ＳＮＳゲームに限られるわけではないのは勿論である。

上述した課題を解決するための第１の形態は、第１のゲームに係る各プレーヤの第１のパラメータを管理し、各プレーヤのプレーヤ端末と通信を行って第１のゲームを進行制御するサーバシステムであって、
一のプレーヤの前記第１のパラメータを変更する処理を発動させる所与の発動条件を満たしたことを検出する発動検出手段（例えば、図４のサーバ処理部２００ｓ、第１ゲーム管理サーバ制御部２１０、発動検出部２２０、図７のステップＳ５０）と、
前記発動検出手段の検出がなされた場合に、前記一のプレーヤの前記第１のパラメータを変更する制御を行う第１の変更制御手段（例えば、図４のサーバ処理部２００ｓ、第１ゲーム管理サーバ制御部２１０、パラメータ向上制御部２２６、図７のステップＳ５４）と、
第２のゲームに係る各プレーヤの第２のパラメータを管理し、各プレーヤのプレーヤ端末と通信を行って第２のゲームを進行制御する第２のサーバシステム（例えば、図４のサーバ処理部２００ｓ、第２ゲーム管理サーバ制御部２４０）と所定の通信を行い、当該第２のサーバシステムに対して、前記発動検出手段の検出がなされた場合に、前記一のプレーヤの前記第２のパラメータを変更させる制御を行う第２の変更制御手段（例えば、図４のサーバ処理部２００ｓ、第１ゲーム管理サーバ制御部２１０、波及制御部２２８、図７のステップＳ６０）と、を備えたサーバシステム（例えば、図１のサーバシステム１１００、第１ゲーム管理サーバシステム１１１５）である。

第１の形態によれば、第１のゲームのパラメータを変更するのに伴い、第２のゲームでもパラメータが変更されるといったパラメータの変更の波及が起こる。プレーヤにとってみれば、第１のゲームの結果に応じて、第２のゲームでどのような影響が生じたか興味が湧く。結果、プレーヤを第２のゲームのプレイへ誘うことができる。

第２の形態は、前記発動検出手段が、前記第１のパラメータを変更させる所与のアイテムの使用指示操作入力がなされたことを前記発動条件として検出する、第１の形態のサーバシステムである。

第２の形態によれば、第１の形態と同様の効果が得られるとともに、ゲーム内でのアイテムの使用を発動条件とすることができる。つまり、第２のゲームへの波及が生じる条件が分りやすくなる。また、プレーヤにとってみれば、アイテムを使用することへのお得感が増すので、アイテムの購入や使用を促進できる。勿論、アイテムを使ったならば、その影響が第２のゲームでどう現れるかが気になるところであり、更にプレーヤを第２のゲームへ誘うこととなる。

第３の形態は、前記第１のゲームにおける行動の指示操作入力がなされる毎に消費し、時間経過又は前記アイテムの使用により回復する各プレーヤの行動パラメータ（例えば、図６の残ＡＰ５４４）を前記第１のパラメータとして管理する行動パラメータ管理手段（例えば、図４のサーバ処理部２００ｓ、第１ゲーム管理サーバ制御部２１０、プレイデータ管理部２１４、行動パラメータ管理部２１６、図７のステップＳ４２〜Ｓ４４）を更に備え、
前記第２のサーバシステムは、前記第２のゲームにおける行動の指示操作入力がなされる毎に消費し、時間経過により回復する各プレーヤの行動パラメータを前記第２のパラメータとして管理し、
前記第１の変更制御手段は、前記アイテムの使用指示操作入力がなされた場合に、前記一のプレーヤの前記行動パラメータを所与の回復量分回復させる手段（例えば、図４のサーバ処理部２００ｓ、第１ゲーム管理サーバ制御部２１０、パラメータ向上制御部２２６、図７のステップＳ５４）を有し、
前記第２の変更制御手段は、前記アイテムの使用指示操作入力がなされた場合に、前記一のプレーヤの前記第２のゲームに係る前記行動パラメータを変更させる手段（例えば、図４のサーバ処理部２００ｓ、第１ゲーム管理サーバ制御部２１０、波及制御部２２８、図７のステップＳ５８）を有する、第２の形態のサーバシステムである。

第３の形態によれば、第２の形態と同様の効果が得られるとともに、パラメータを消費して行動選択できる行動パラメータ制（行動ポイント制と呼ぶ場合もある）とし、発動条件とされるアイテムを使用すると第１のゲームにおける行動パラメータを回復させることができる。そして、それに応じて第２のゲームにおける行動パラメータを変更させることができる。

第４の形態は、前記第１の変更制御手段が、前記発動検出手段の検出がなされた場合に、前記一プレーヤの前記第１のパラメータを所与の期間一時的に変更する、第１又は第２の形態のサーバシステムである。

第４の形態によれば、第１又は第２の形態と同様の効果が得られるとともに、パラメータの変更を一時的なものにできる。

第５の形態は、前記第１の変更制御手段により前記第１のパラメータが変更されている際に、その旨を前記一のプレーヤのプレーヤ端末に通知する変更通知手段（例えば、図３の変更通知表示Ｗ１２，図４のサーバ処理部２００ｓ、第１ゲーム管理サーバ制御部２１０、通知制御部２３６、図７のステップＳ５６）を更に備えた、第４の形態のサーバシステムである。

第５の形態によれば、第４の形態と同様の効果が得られるとともに、第１のパラメータが変更されていることをプレーヤに通知できる。

第６の形態は、前記第２の変更制御手段が、前記一のプレーヤの前記第２のパラメータを所与の期間一時的に変更させる一時変更手段（例えば、図４のサーバ処理部２００ｓ、第１ゲーム管理サーバ制御部２１０、図１４のステップＳ５３，Ｓ６６〜Ｓ６８）を有する、第１〜第５の何れかの形態のサーバシステムである。

第６の形態によれば、第１〜第５の形態の何れかと同様の効果が得られるとともに、第２ゲームでの第２パラメータの変更を一時的なものにできる。

第７の形態は、前記第２の変更制御手段が、前記第１の変更制御手段による前記第１のパラメータの変更幅よりも小さい変更幅で前記第２のパラメータを変更させる変更幅調整手段（例えば、図４の向上幅調整部２３０、図７のステップＳ５８）を有する、第１〜第６の何れかの形態のサーバシステムである。

第７の形態によれば、第１〜第６の形態の何れかと同様の効果が得られるとともに、第２ゲームでのパラメータの変更幅を第１ゲームでのパラメータの変更幅より小さくできる。

第８の形態は、各プレーヤの前記第１のゲームにおけるレベル、経験値、仮想マネー及び所与のアイテムを出現させる出現確率のうちの少なくとも１つを含むプレイデータを管理するプレイデータ管理手段（例えば、図４のサーバ処理部２００ｓ、第１ゲーム管理サーバ制御部２１０、プレイデータ管理部２１４、図７のステップＳ４２）と、
前記第２のサーバシステムから前記一のプレーヤの前記第２のゲームにおけるプレイデータを取得する第２ゲームデータ取得手段（例えば、図４のサーバ処理部２００ｓ、第１ゲーム管理サーバ制御部２１０、第２ゲームデータ取得制御部２２２、図７のステップＳ５８）、を更に備え、
前記変更幅調整手段は、前記プレイデータ管理手段で管理されている前記一のプレーヤに係るプレイデータと、前記第２ゲームデータ取得手段により取得されたプレイデータとの差を用いて、前記第２のパラメータの変更幅を決定するプレイデータ基準変更幅決定手段（例えば、図４のサーバ処理部２００ｓ、第１ゲーム管理サーバ制御部２１０、プレイデータ基準変更幅決定部２３２、図７のステップＳ５８）を有する、第７の形態のサーバシステムである。

第８の形態によれば、第７の形態と同様の効果が得られるとともに、第１のゲームと第２のゲームとのプレイデータの差で第２パラメータの変更幅を変えることができる。

第９の形態は、各プレーヤのプレイ日時を管理するプレイ日時管理手段（例えば、図４のサーバ処理部２００ｓ、第１ゲーム管理サーバ制御部２１０、プレイ日時管理部２１８）と、
前記第２のサーバシステムから前記一のプレーヤのプレイ日時のデータを取得する第２ゲームプレイ日時取得手段（例えば、図４のサーバ処理部２００ｓ、第１ゲーム管理サーバ制御部２１０、第２ゲームプレイ日時取得制御部２２４、図７のステップＳ５８）と、を更に備え、
前記変更幅調整手段は、前記プレイ日時管理手段で管理されている前記一のプレーヤのプレイ日時と、前記第２ゲームプレイ日時取得手段により取得されたプレイ日時とに基づいて、前記第１のゲームと前記第２のゲームのプレイ頻度の差を求め、当該プレイ頻度の差を用いて、前記第２のパラメータの変更幅を決定するプレイ頻度基準変更幅決定手段（例えば、図４のサーバ処理部２００ｓ、第１ゲーム管理サーバ制御部２１０、プレイ頻度基準変更幅決定部２３４、図７のステップＳ５８）を有する、第７又は第８の形態のサーバシステムである。

第９の形態によれば、第７又は第８の形態の何れかと同様の効果が得られるとともに、第１のゲームと第２のゲームのプレイ頻度の差で第２パラメータの変更幅を変えることができる。

第１０の形態は、前記発動条件を満たすことで前記一のプレーヤの前記第２のパラメータが変更される旨を前記一のプレーヤのプレーヤ端末に表示させる通知制御手段（例えば、図３の変更通知表示Ｗ１２、図４のサーバ処理部２００ｓ、第１ゲーム管理サーバ制御部２１０、通知制御部２３６、図７のステップＳ５６）を更に備えた第１〜第９の何れかの形態のサーバシステムである。

第１０の形態によれば、第１〜第９の形態の何れかと同様の効果が得られるとともに、プレーヤへ第２ゲームでのパラメータが変更される旨の通知をすることができる。

第１１の形態は、第２のゲームに係る各プレーヤの第２のパラメータを管理し、各プレーヤのプレーヤ端末と通信を行って第２のゲームを進行制御するサーバシステムであって、
第１〜第１０の何れかの形態のサーバシステムの前記第２の変更制御手段の制御に従って、前記一のプレーヤの前記第２のパラメータを変更する受動実行手段（例えば、図３の変更通知表示Ｗ１２、図４のサーバ処理部２００ｓ、第１ゲーム管理サーバ制御部２１０、受動実行制御部２３８、図８の受動実行処理）を更に備えたサーバシステムである。

第１１の形態によれば、第１〜第１０の形態の何れかと同様の効果が得られる。

第１実施形態におけるゲームシステムの構成の一例を示す図。 ユーザ端末構成例を示す図。 第１実施形態における非同期の異ゲーム間におけるパラメータ変更の波及について説明するための図。 第１実施形態におけるサーバシステムの機能構成の一例を示す機能ブロック図。 第１実施形態におけるサーバ記憶部が記憶する情報の構成例を示すブロック図。 プレイデータのデータ構成の一例を示す図。 第１実施形態における非同期の異ゲーム間におけるパラメータ変更の波及に係る処理の流れについて説明するためのフローチャート。 受動実行処理の流れを説明するためのフローチャート。 第２実施形態における非同期の異ゲーム間におけるパラメータ変更の波及について説明するための図。 第２実施形態における非同期の異ゲーム間におけるパラメータ変更の波及について説明するための図。 第２実施形態におけるサーバシステムの機能構成の一例を示す機能ブロック図。 第２実施形態における非同期の異ゲーム間におけるパラメータ変更の波及に係る処理の流れについて説明するためのフローチャート。 能動波及制御処理の流れを説明するためのフローチャート。 非同期の異ゲーム間におけるパラメータ変更の波及に係る処理の変形例における処理の流れについて説明するためのフローチャート。

〔第１実施形態〕
本発明を適用した第１実施形態として、登録ユーザに第１ゲームと第２ゲームを提供する例について説明する。

［システムの構成の説明］
図１は、本実施形態におけるゲームシステムの構成の一例を示す図である。本実施形態のゲームシステムは、通信回線１に接続することのできるサーバシステム１１００と、ゲームのプレーヤ２（２ａ，２ｂ，２ｃ，・・・）毎に用意されるユーザ端末１５００（１５００ａ，１５００ｂ，１５００ｃ，・・・）により構成される。

通信回線１は、データ通信が可能な通信路を意味する。すなわち、通信回線１とは、直接接続のための専用線（専用ケーブル）やイーサネット（登録商標）等によるＬＡＮ（Local Area Network）の他、電話通信網やケーブル網、インターネット等の通信網を含む意味であり、また、通信方法については有線／無線を問わない。

サーバシステム１１００は、単数又は複数のサーバシステムや記憶装置等を含んで構成され、コミュニティ型ウェブサイトや、オンラインゲームを運営するための各種サービスを提供し、ゲーム実行に必要なプレイデータの管理や、クライアントプログラム及び各種データ等を配信することができる。

本実施形態では、サーバシステム１１００は、筐体１１０２と、キーボード１１０６と、タッチパネル１１０８と、ストレージ１１４０とを備える。筐体１１０２には、複数のブレードサーバ１１０４が内蔵されている。

ブレードサーバ１１０４は、例えば、（１）ユーザ登録やプレーヤキャラクタの初期設定、及びログイン／ログアウトに関係する処理を担うアカウント管理サーバシステム１１１０と、（２）ログインしてオンラインゲームに参加中のユーザ端末１５００へゲームを実行するのに必要なデータを随時管理・配信するゲーム管理サーバシステム１１１４と、を有して構成される。ゲーム管理サーバシステム１１１４は、ゲーム種類毎に第１ゲーム管理サーバシステム１１１５、第２ゲーム管理サーバシステム１１１６、・・・と言った具合に設けられており、互いにサーバシステム１１００の内部回線を通じてデータ通信可能に接続されている。

尚、ブレードサーバ１１０４を構成するそれぞれのサーバは、通信回線１を介してデータ通信可能な独立したサーバシステムとして実現しても良い。例えば、第１ゲーム管理サーバシステム１１１５と第２ゲーム管理サーバシステム１１１６を、独立した第１ゲーム管理サーバシステム１１１７と第２ゲーム管理サーバシステム１１１８としたシステム構成でも良い。

ユーザ端末１５００は、ユーザそれぞれに１台ずつ用意されるコンピュータであり、電子装置である。例えば、スマートフォンや、携帯型ゲーム装置、据置型家庭用ゲーム装置、業務用ゲーム装置、パソコン、タブレット型コンピュータなどにより実現される。そして、通信回線１に接続し、サーバシステム１１００にアクセスすることができる。

図２は、ユーザ端末１５００の構成例を示す図であって、（１）正面外観図、（２）背面外観図である。本実施形態におけるユーザ端末１５００は、方向入力キー１５０２と、ホームキー１５０４と、画像表示デバイス兼接触位置入力デバイスとして機能するタッチパネル１５０６と、スピーカ１５１０と、マイク１５１２と、ＧＰＳ（Global Positioning System）アンテナ１５１４と、ＣＣＤカメラモジュール１５１６と、制御基板１５５０と、コンピュータ読み出し可能な情報記憶媒体であるメモリカード１５４０からデータを読み書きできるメモリカード読取装置１５４２と、を備える。その他、図示されていない内蔵バッテリーや電源ボタン、音量調節ボタン等が設けられている。

ＣＣＤカメラモジュール１５１６は、オートフォーカス機構と、ＣＣＤイメージセンサと、イメージ信号生成チップとを搭載したモジュールであって、ユーザ端末１５００の背面側を撮影できるように配置されている。尚、イメージセンサ素子はＣＣＤに限らない。

制御基板１５５０は、ＣＰＵ（Central Processing Unit）１５５１やＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）などの各種マイクロプロセッサ、ＡＳＩＣ（Application Specific Integrated Circuit）、ＶＲＡＭやＲＡＭ，ＲＯＭ等の各種ＩＣメモリ１５５２を搭載する。

そして、制御基板１５５０には、携帯電話基地局や無線ＬＡＮ基地局などと無線接続するための無線通信モジュール１５５３と、ＧＰＳモジュール１５５４と、電子コンパス１５５５と、３軸ジャイロ１５５６と、３軸加速度センサ１５５７とが搭載されている。
その他、タッチパネル１５０６のドライバ回路、方向入力キー１５０２及びホームキー１５０４からの信号を受信する回路、スピーカ１５１０へ音声信号を出力する出力アンプ回路、マイク１５１２で集音した音声の信号を生成する入力信号生成回路、メモリカード読取装置１５４２への信号入出力回路といった所謂Ｉ／Ｆ回路（インターフェース回路）、等が搭載されている。これら制御基板１５５０に搭載されている各要素は、それぞれバス回路などを介して電気的に接続され、データの読み書きや信号の送受信が可能に接続されている。

ＧＰＳモジュール１５５４は、ＧＰＳアンテナ１５１４とともにＧＰＳを利用した位置情報を取得する手段を構成する。ＧＰＳモジュール１５５４は、ＧＰＳアンテナ１５１４で受信したＧＰＳ衛星３からの信号に基づいて、所定時間毎（例えば、１秒毎）に、位置情報（例えば、緯度・経度）及びその他の情報（絶対時間）を、制御基板１５５０で演算処理可能なデータとして出力する。尚、測位に利用するシステムはＧＰＳに限らない。その他の衛星測位システムでも良いし、衛星を用いない測位システムを用いることもできる。後者の例としては、例えば、無線通信モジュール１５５３が無線接続できる携帯電話基地局からの信号に基づいて三角測量の原理で測位して、位置情報を取得するとしても良い。

制御基板１５５０は、サーバシステム１１００から取得したゲームクライアントプログラムやデータをＩＣメモリ１５５２に一時記憶する。そして、プログラムを実行して演算処理を実行し、方向入力キー１５０２やホームキー１５０４、タッチパネル１５０６からの操作入力に応じてユーザ端末１５００の各部を制御して、オンラインＲＰＧを実行する。尚、本実施形態では、ユーザ端末１５００は必要なプログラムや各種設定データをサーバシステム１１００から取得する構成としているが、別途入手したメモリカード１５４０から読み出す構成としても良い。

［異なるゲーム間での波及効果についての説明］
本実施形態では、ユーザはサーバシステム１１００が提供するサービスを利用するには、所定の手続きを行ってユーザアカウントを取得する必要がある。取得したユーザアカウントと対応づけられるパスワードをもってログインすることで、登録ユーザ間でのメッセージ交換や、フレンドユーザの登録、ゲームプレイなどのサービスが利用可能となる。

メッセージ交換は、ログインしているユーザ間でのショートメール等のメッセージの送受をサポートするサービスである。そして、ユーザはメッセージのやりとりを通じて気の合った他ユーザを所定の登録手続きによって「フレンド」として登録する機能を提供する。

また、ユーザは、所定のゲーム利用登録をすることで、複数のゲームの中から任意のゲームを好きな時に遊ぶことが可能である。例えば、とあるユーザは、第１ゲームと第２ゲームとを利用登録しているとする。そして、本実施形態では、第１ゲームのゲーム進行状況に応じて、第２ゲームで使用されるパラメータを変更し、異ゲーム間におけるパラメータ変更の波及を実現することができる。

図３は、本実施形態における非同期の異ゲーム間におけるパラメータ変更の波及について説明するための図である。
本実施形態では、第１ゲームをプレイしている際に、ゲーム進行状況が所定の発動条件を満たすと、第２ゲームをプレイする場合に適用されるパラメータが、プレーヤにとって有利な方向に変更される。

発動条件としては、例えば、所定アイテムの使用・入手・購入、所定ステージの攻略、所定のＮＰＣ（ノンプレーヤキャラクタ）の撃破などを適宜設定することができる。また、可変されるパラメータも適宜設定可能である。

より具体的には、本実施形態では、第１ゲームと第２ゲームでは、共にプレーヤキャラクタの行動に関するパラメータとして行動ポイント（ＡＰ：Action Point）が与えられるものとする。行動ポイントＡＰは、プレーヤキャラクタが何らかの行動をとる際に消費されるポイントであって、行動の種類によって消費されるポイントが異なる。例えば、移動なら２ポイント消費、攻撃なら４ポイント消費、アイテム使用なら１ポイント消費、・・・と言った具合である。行動ポイントＡＰは、時間とともに自動的に回復するが、所定のＡＰ回復アイテムの使用により瞬時に回復を図ることもできる。

例えば、ゲーム画面Ｗ２には、最新の行動ポイントＡＰの最大値と現在の残ＡＰ値を示す行動ポイントメータ４が表示される。ちなみに、図３の例では網掛けされたマスが残ＡＰ値を示している。

プレーヤが第１ゲームにおいて、このＡＰ回復アイテムの使用指示操作入力をしたならば（ゲーム画面Ｗ４参照）、当該アイテムの直接的な効果として、第１ゲームに係るプレイデータ５４０に含まれる残ＡＰ５４４が加算され行動ポイントＡＰが回復される（図の例では「１」から「１０」まで回復）。

また、第１ゲームのゲーム画面には、発動条件を満たしたことを通知する変更通知表示Ｗ１２が表示される（ゲーム画面Ｗ６参照）。当該通知表示では、第２ゲームのタイトルと、プレーヤが得られるメリットとして第２ゲームにおける行動ポイントＡＰが変更されることが通知される。

そして、同じプレーヤの第２ゲームに係るプレイデータ５４０の残ＡＰ５４４を回復させる（図３の例では「２」から「７」まで回復）。同じプレーヤが、第１ゲームのプレイを中止して第２ゲームをプレイすると、前回プレイ終了した時点では行動ポイントＡＰが「２」であったところが「７」まで回復していることとなる（ゲーム画面Ｗ８参照））。

プレーヤにとってみれば、第１ゲームでのＡＰ回復アイテムの使用の波及として、第２ゲームにおける行動ポイントＡＰの回復という特典が得られることになり、プレーヤに第２ゲームでのプレイを促すことができる。

尚、発動条件や、発動条件が満たされた時に第１ゲームで変更されるパラメータ（第１パラメータ）、波及の効果として第２ゲームで変更されるパラメータ（第２パラメータ）は適宜設定可能である。例えば、発動条件を、効力に制限時間があるアイテム（例えば、第１の所与時間だけ移動速度が増加するアイテムなど）とすることもできる。その場合には、第１ゲームでは、当然当該アイテムの使用に伴い第１の所与時間の間だけ対応する第１パラメータ（例えば、移動力、回復力など）を向上し、時間経過すると向上前の状態に戻すように制御すると良い。その際、変更通知表示Ｗ１２は第１パラメータが変更されている期間のみ表示されるようにする。なお、変更通知は、パラメータが変更されている期間表示され続けてもよいし、パラメータが変更されている期間の開始時のみ表示されるようにしてもよい。そして、第２ゲームにおいても同じアイテム効果が適用さることとし、同じように第２の所与時間（第１ゲームにおける第１の所与時間と異なるとしても可）の間、対応する第２パラメータが向上され、時間経過すると向上前の状態に戻すように制御する構成とすれば良い。勿論、第２パラメータを第１パラメータと異なる種類とすることもできる。より具体的には、第１の所与時間を「１０分」とするならば、プレーヤはその１０分の間に第１ゲームを終了して第２ゲームのプレイを始めれば、第２ゲームにおいて第２パラメータの変更の恩恵を得ることができる。この時、第２の所与時間を「１５分」と言った具合に、第１の所与時間にプレイするゲームの切換えに要すると想定される時間を加算した時間を設定すると好適である。

また、第２ゲームにおける発動条件に該当するアイテムの効果、具体的には第２ゲームに適用されるパラメータの向上幅は、基本的には第１ゲームと同様又は劣るものとする。
具体的には、ＡＰ回復アイテムであれば、第１ゲームでは１０ポイント回復するところを、第２ゲームでは８ポイントといった具合に、第１ゲームでの効果よりも低減させる。この例では向上幅は第１ゲームよりも２０％ダウンさせる。制限時間のあるアイテムならば、第１ゲームなら１００秒間効果が持続するが、第２ゲームならば５０秒間（向上幅が第１ゲームより５０％ダウン）だけ効果が持続する等とすると良い。

更には、第２ゲームに適用されるパラメータの向上幅を、ゲーム進行状況に応じて決定することもできる。本実施形態では、第１ゲームと第２ゲームそれぞれのプレイデータ５４０に格納される同じ種類のパラメータ（例えば、プレーヤレベル、経験値、仮想マネー残高、プレイ日時、アイテムを出現させる出現確率など）の値を比較し、差に応じて決定することもできる。
例えば、第１ゲームのプレーヤレベルと、第２ゲームのプレーヤレベルとを比較して、差が大きいほど適用される効果度合を低くする。或いは単純に第２ゲームのプレーヤレベルが小さい（低い）程効果度合をより低くするとしても良い。こうすることで、異なるゲーム間でゲームの進捗度合や、プレーヤの習熟度、ゲームの「やり込み」度合に差があっても、一方のゲームのパラメータがゲームバランスを崩すほど過度に変更されないようにできる。

尚、本実施形態では、第１パラメータの変更と、第２パラメータの変更は、共に対象とするパラメータがプレーヤにとって有利となるように、つまり向上方向へ変更する構成としているが、ゲーム内容やゲームバランスを考慮して、一方又は両方ともプレーヤが不利となるように変更する構成とすることも可能である。

［機能ブロックの説明］
次に、本実施形態を実現するための機能構成について説明する。
図４は、本実施形態におけるサーバシステム１１００の機能構成の一例を示す機能ブロック図である。サーバシステム１１００は、操作入力部１００ｓと、サーバ処理部２００ｓと、画像表示部３６０ｓと、通信部３７０ｓと、サーバ記憶部５００ｓとを備える。

操作入力部１００ｓは、サーバオペレータによって為された各種の操作入力（プレーヤキャラクタの行動の指示操作入力を含む）に応じて操作入力信号をサーバ処理部２００ｓに出力する。例えば、キーボードや、タッチパネル、マウス、トラックパッドなどによって実現できる。図１ではキーボード１１０６やタッチパネル１１０８がこれに該当する。

サーバ処理部２００ｓは、例えばＣＰＵやＧＰＵ等のマイクロプロセッサや、ＡＳＩＣ、ＩＣメモリなどの電子部品によって実現される。サーバ処理部２００ｓは、各機能部との間でデータの入出力制御を行い、所定のプログラムやデータ、操作入力部１００ｓからの操作入力信号や、通信部３７０ｓを介して外部からアクセスしてきた外部装置（他コンピュータ）等からのリクエストに応じて各種の演算処理を実行して、サーバシステム１１００の動作を制御する。図１ではブレードサーバ１１０４、より具体的にはその制御基板がこれに該当する。

そして、本実施形態のサーバ処理部２００ｓは、ユーザ登録情報管理部２０２と、ログイン処理部２０４と、第１ゲーム管理サーバ制御部２１０と、第２ゲーム管理サーバ制御部２４０と、画像生成部２６０ｓと、通信制御部２７０ｓとを備える。

ユーザ登録情報管理部２０２は、ユーザアカウントの新規発行、パスワードの登録など各種ユーザ情報の取得・登録管理に関する処理を実行する。尚、ユーザ登録情報管理部２０２は、公知のオンラインゲームにおけるユーザ登録関連技術を適宜応用することで実現できる。ログイン処理部２０４は、通信接続したユーザ端末１５００からのリクエストに応じて所謂ログインを制御する。当該処理部は、公知のオンラインゲームにおけるログイン制御技術を適宜利用することで実現できる。ちなみに、図１の例では、アカウント管理サーバ１１１０がユーザ登録情報管理部２０２と、ログイン処理部２０４とを担う。

第１ゲーム管理サーバ制御部２１０及び第２ゲーム管理サーバ制御部２４０は、それぞれ第１ゲーム、第２ゲームの進行制御並びにユーザ端末１５００にてゲーム画像等を表示させるのに必要な処理を実行する。すなわち、常時機能している状態にあって、ユーザ端末１５００からゲーム開始リクエストを受けると新たなプレイデータ５４０を生成して、個別にゲーム進行制御することができる。そして、これら両制御部は、ゲーム内容が異なるだけで基本的には同じ構成を有する。以降、両ゲーム管理サーバ制御部を代表して、第１ゲーム管理サーバ制御部２１０について説明する。

第１ゲーム管理サーバ制御部２１０は、プレイデータ管理部２１４と、発動検出部２２０と、第２ゲームデータ取得制御部２２２と、第２ゲームプレイ日時取得制御部２２４と、パラメータ向上制御部２２６と、波及制御部２２８と、通知制御部２３６と、受動実行制御部２３８とを含む。

プレイデータ管理部２１４は、当該ゲーム管理サーバ制御部で進行制御するゲームの進行状況を記述するデータ、所謂プレイデータを管理する。本実施形態では更に、行動パラメータ管理部２１６と、プレイ日時管理部２１８とを含む。

行動パラメータ管理部２１６は、プレーヤキャラクタの行動パラメータを管理する。本実施形態では、ゲームにおける行動の指示操作入力がなされる毎に行動ポイントＡＰを行動種類に応じた値だけ減算し消費する。また、時間経過又はＡＰ回復アイテムの使用により加算・回復させる。

プレイ日時管理部２１８は、プレーヤのプレイ日時を管理する。具体的には、プレイ開始日時と、プレイ終了日時とを対応づけ記憶・管理するための制御をする。１回１回のプレイ毎にログインがなされる形態であれば、１回１回のプレイされた（ログインされた）日時をプレーヤ毎に対応づけて記憶・管理する。

発動検出部２２０は、一のプレーヤの第１のパラメータを向上させる処理を発動させる所与の発動条件を満たしたことを検出する。本実施形態では、少なくとＡＰ回復アイテムの使用指示操作入力がなされたことを発動条件として検出する

第２ゲームデータ取得制御部２２２は、第２ゲームのゲーム進行を管理するサーバシステムから、第１ゲームをプレイしているプレーヤと、同じプレーヤの第２のゲームにおけるプレイデータを取得するための制御を行う。

第２ゲームプレイ日時取得制御部２２４は、第２ゲームのゲーム進行を管理するサーバシステム（第２サーバシステム）から、第１ゲームをプレイしているプレーヤと、同じ第２ゲームに関するプレイ日時のデータを取得するための制御を行う。

パラメータ向上制御部２２６は、発動検出部２２０による検出がなされた場合に、プレーヤの第１パラメータを変更させる第１の変更制御部である。本実施形態では、第１パラメータとして行動ポイントＡＰを設定し、ＡＰ回復アイテムの使用指示操作入力がなされた場合に、所与の回復量分だけプレーヤの行動ポイントＡＰに加算・回復させる。
尚、第１パラメータは、ゲーム内容に応じて適宜設定可能である。例えば、攻撃力や防御力といった戦闘に関する能力パラメータ値、ゲーム内又はゲーム開始前の抽選に適用される当選確率（アイテムの出現率などがこれに含まれる）、プレーヤキャラクタの好感度や経験値、成長度数などをゲーム内容に応じて設定できる。そして、設定したパラメータの意味するところに応じて向上させるように、つまりはプレーヤにとって利するように処理すると良い。例えば、第１パラメータを能力パラメータや当選確率とした場合には、発動検出部２２０の検出がなされた場合に、それらのパラメータを所与の期間一時的に向上させると良い。

波及制御部２２８は、プレーヤの第２ゲームに係る第２パラメータを変更させる制御を行う第２の変更制御部であって、他ゲームへの波及に関する処理を実行する。本実施形態では、第２ゲームに係る各プレーヤの第２パラメータを管理するとともに第２ゲームを進行制御するサーバシステム（第２サーバシステム）に対して、発動検出部２２０の検出がなされた場合に、第１ゲームのプレーヤの第２パラメータを向上させるように、つまりはプレーヤにとって利するように変更させる波及制御を実行する。
本実施形態では、第１ゲームを制御する第１ゲーム管理サーバシステム１１１５と、第２ゲーム管理サーバシステム１１１６は同じサーバシステム１１００内に設けられているので、第１ゲームのユーザと同じユーザアカウントに紐付けされる第２ゲームのプレイデータの第２パラメータを変更する。そして、本実施形態では、第２パラメータとして、行動ポイントＡＰを設定し、第１ゲームにおける行動ポイントＡＰのアイテムによる回復が第２ゲームにおける行動ポイントＡＰにも波及するように第２パラメータを変更させる。

尚、第２パラメータは、第１パラメータと同じ種類に限らず異なる種類を設定することができるのは勿論である。そして、第２パラメータの変更は、その設定により適宜設定できる。例えば、第２パラメータを能力パラメータ値や当選確率（アイテムの出現率などがこれに含まれる）とした場合には、それらのパラメータを所与の期間一時的に向上させるように変更すると良い。

もし、第１ゲーム管理サーバシステム１１１５と第２ゲーム管理サーバシステム１１１６が互いに独立したサーバシステムの場合には、外部からシステムを制御できる共通のＡＰＩ（Application Program Interface）いわゆる外部ＡＰＩを実装させ、当該ＡＰＩを用いて外部から第２パラメータを変更可能にすると良い。

そして、本実施形態の波及制御部２２８は、向上幅調整部２３０を含む。
向上幅調整部２３０は、第２パラメータの向上幅すなわち変更幅を、パラメータ向上制御部２２６による第１パラメータの向上幅よりも原則として小さい向上幅とする。更には、向上幅調整部２３０は、プレイデータ基準変更幅決定部２３２と、プレイ頻度基準変更幅決定部２３４とを含む。

プレイデータ基準変更幅決定部２３２は、第２ゲームのプレイデータに基づいて向上幅（変更幅）を決定する。本実施形態では、同一プレーヤに係り第１ゲームのプレイデータと、第２ゲームデータ取得制御部２２２により取得された同一プレーヤに係る第２ゲームのプレイデータとの差を用いて第２パラメータの変更幅を決定する。

プレイ頻度基準変更幅決定部２３４は、第２ゲームのプレイ日時の履歴に基づいて向上幅（変更幅）を決定する。本実施形態では、プレイ日時管理部２１８で管理されているプレイ日時と、第２ゲームプレイ日時取得制御部２２４の制御により取得された第２ゲームに係るプレイ日時とに基づいて、第１ゲームと第２ゲームとのプレイ頻度の差を求め、当該プレイ頻度の差を用いて、第２のパラメータの向上幅すなわち変更幅を決定する。具体的には、例えば、第１ゲームよりも第２ゲームのプレイ頻度が低いほど向上幅を小さくする。或いは、第２ゲームのプレイ頻度の方が高ければ、向上幅を低くしない又は若干高くするとしても良い。

これらの変更幅決定部は、プレイデータ５４０に含まれるプレーヤレベルやプレイ回数、或いはプレイ日時など、プレイ習熟度やプレイ進捗度を推し量るパラメータを比較し、第１ゲームに比べて第２ゲームでのプレイ習熟度やプレイ進捗度が低い場合には変更幅を、プレイ習熟度やプレイ進捗度が同程度又は第２ゲームの方が高い場合に比べて小さくする。

通知制御部２３６は、発動条件を満たしたことで、第１ゲームに係る第１パラメータが変更されたことと、プレーヤの第２ゲームに係る第２パラメータ（本実施形態では、第２ゲームでの行動ポイントＡＰ）が変更される旨をプレーヤのユーザ端末１５００に表示させる制御を行う。更に本実施形態では、変更通知表示Ｗ１２（図３参照）を表示させる。

受動実行制御部２３８は、他サーバシステムからの波及制御に従って、他サーバシステムでプレイ中のプレーヤと同一ユーザアカウントに係る第２パラメータを変更する。

画像生成部２６０ｓは、例えば、ＧＰＵ（Graphics Processing Unit）、デジタルシグナルプロセッサ（ＤＳＰ）などのプロセッサ、ビデオ信号ＩＣ、ビデオコーデックなどのプログラム、フレームバッファ等の描画フレーム用ＩＣメモリ、テクスチャデータの展開用に使用されるＩＣメモリ等によって実現される。画像生成部２６０ｓは、サーバ処理部２００ｓによる処理結果に基づいて１フレーム時間（例えば１／６０秒）で１枚の画面を生成し、生成した画面の画像信号を画像表示部３６０ｓに出力する。

画像表示部３６０ｓは、画像生成部２６０ｓから入力される画像信号に基づいて各種画像を表示する。例えば、フラットパネルディスプレイ、ブラウン管（ＣＲＴ）、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。本実施形態では、図１のタッチパネル１１０８がこれに該当する。

通信制御部２７０ｓは、データ通信に係るデータ処理を実行し、通信部３７０ｓを介して外部装置とのデータのやりとりを実現する。
これに関連する通信部３７０ｓは、通信回線１と接続して通信を実現する。例えば、無線通信機、モデム、ＴＡ（ターミナルアダプタ）、有線用の通信ケーブルのジャックや制御回路等によって実現される。

サーバ記憶部５００ｓは、サーバ処理部２００ｓに諸機能を実現させるためのプログラムやデータを記憶する。また、サーバ処理部２００ｓの作業領域として用いられ、各種プログラムに従って実行した演算結果や、ユーザ端末１５００から受信した情報等を一時的に記憶する。こうした機能は、例えばＲＡＭやＲＯＭなどのＩＣメモリ、ハードディスク等の磁気ディスク、ＣＤ−ＲＯＭやＤＶＤなどの光学ディスクなどによって実現される。図１では、ブレードサーバ１１０４に搭載されているＩＣメモリ等の情報記憶媒体や、ストレージ１１４０がこれに該当する。

図５は、本実施形態におけるサーバ記憶部５００ｓが記憶する情報の構成例を示す図である。本実施形態のサーバ記憶部５００ｓは、サーバシステムプログラム５０３と、ゲーム管理サーバプログラム５０５と、第１ゲームクライアントプログラム５０７と、第１ゲーム実行用データ５０９と、第２ゲームクライアントプログラム５１１と、第２ゲーム実行用データ５１３と、第１ゲームプレイ中端末リスト５１５と、第２ゲームプレイ中端末リスト５１７とを記憶する。また、ユーザ登録データ５２０と、プレイデータ５４０と、を記憶する。その他ゲームの管理や、フレンドログインボーナスの付与等に必要な、所定期間のカウント値、各種フラグなどを適宜記憶する。

サーバシステムプログラム５０３は、コンピュータにサーバとしての基本的な機能を実現させるためのプログラムである。サーバ処理部２００ｓに、ユーザ登録情報管理部２０２、ログイン処理部２０４、としての機能を実現させることもできる。

ゲーム管理サーバプログラム５０５は、サーバ処理部２００ｓに、ゲーム管理サーバ制御部（本実施形態では、第１ゲーム管理サーバ制御部２１０、第２ゲーム管理サーバ制御部２４０）としての機能を実現させるためのプログラムである。

第１ゲームクライアントプログラム５０７は、第１ゲームのプレイを希望するユーザ端末１５００に提供するクライアントプログラムの原本である。ユーザ端末１５００は、これをダウンロードして搭載する情報記憶媒体に記憶させて実行する。第１ゲームクライアントプログラム５０７は、専用のプログラムや、ウェブブラウサプログラム及びウェブブラウザプログラム上で動的な表示を実現するためのプラグインなどにより実現される。後者の構成は、オンラインゲームを所謂ブラウザゲームとして実現する場合に利用可能である。第２ゲームをユーザ端末１５００でプレイするための同様のプログラムが、第２ゲームクライアントプログラム５１１である。

第１ゲーム実行用データ５０９は、第１ゲームを実行するために必要な各種データを格納する。例えば、ゲームフィールドを設定するためのデータや、プレーヤキャラクタ及び敵キャラクタのモデルデータやモーションデータ、テクスチャデータ、キャラクタの初期能力パラメータ値、ゲーム中で使用可能なアイテムの設定データなどが含まれる。第２ゲームを実行するための同様のデータが、第２ゲーム実行用データ５１３である。

第１ゲームプレイ中端末リスト５１５と第２ゲームプレイ中端末リスト５１７は、それぞれ第１ゲーム、第２ゲームをプレイしているユーザ端末１５００のリストデータであって、各端末毎のユーザアカウントや、ＩＰアドレスなどを対応づけて格納する。

ユーザ登録データ５２０は、登録ユーザすなわちプレーヤ別に用意され、当該プレーヤに係わる各種情報を格納する。例えば、ログインするために必要なユーザアカウント５２２とパスワード５２３を格納する。また、ログイン履歴データ５２４と、フレンドリスト５２５と、プレイ登録済ゲームリスト５２６とを格納する。

ログイン履歴データ５２４は、ログイン、ログアウトの日時等の履歴である。
プレイ登録済ゲームリスト５２６は、同一ユーザアカウントでプレーヤ登録したゲームの識別情報を格納する。本実施形態では、第１ゲームと第２ゲームの識別情報が格納されていることになる。

プレイデータ５４０は、ゲームとプレーヤの組み合わせ毎に用意され、当該ゲームの進行状況を記述する各種データを格納する。
例えば図６に示すように、プレーヤの識別情報であるユーザアカウント５４１と、ゲームＩＤ５４２と、行動ポイントＡＰの残り値を格納する残ＡＰ５４４と、ゲーム成績等に応じて自動的に付与されるプレーヤレベル５４６と、プレーヤキャラクタが得たゲーム世界内での経験値５４８と、ゲーム世界で使用できるアイテムを購入するための仮想マネー残高５５０と、プレイした日時のデータを蓄積したプレイ日時履歴５５２と、所持アイテムリスト５５４と、ゲーム内又はゲーム開始前の抽選に適用される当選確率５５５と、プレーヤキャラクタの能力パラメータ値テーブル５５６と、を格納する。勿論、その他のタイマー値や、各種フラグなどのゲーム進行制御に必要な各種情報を格納することができる。

［処理の流れの説明］
次に、図７を参照しながら、第１ゲームを実行するサーバシステム（本実施形態では、第１ゲーム管理サーバシステム１１１５）における処理の流れについて説明する。尚、プレーヤは既にユーザアカウントを取得し、第１ゲームと第２ゲームのプレーヤ登録を済ませ、それぞれのゲームを何度となくプレイしたことがあるものとする。

第１ゲーム管理サーバ制御部２１０は、ユーザ端末１５００からゲーム開始リクエストを受信すると（ステップＳ２のＹＥＳ）、当該ユーザ端末１５００を第１ゲームプレイ中端末リスト５１５に登録し、プレイデータ５４０のプレイ日時履歴５５２を更新する（ステップＳ４）。

そして、もしリクエストしてきたユーザ端末１５００のプレーヤのユーザアカウントと一致する第１ゲームのプレイデータ５４０が無ければ（ステップＳ６のＮＯ）、第１ゲーム管理サーバ制御部２１０は新規に当該プレーヤのプレイデータ５４０を生成する（ステップＳ８）。

次に、第１ゲーム管理サーバ制御部２１０は、プレイ中のゲーム毎にループＡを実行する（ステップＳ４０〜Ｓ８４）。
ループＡでは、先ず操作入力に応じたゲーム進行制御を行う（ステップＳ４２）。上述のように、本実施形態は行動ポイント制なので、プレーヤキャラクタの行動にともない行動ポイントＡＰの消費が行われる。その一方で、所定単位時間の経過毎に行動ポイントＡＰの自動回復を行う（ステップＳ４４）。尚、ゲーム進行制御（ステップＳ４２）では、アイテムを購入する操作があればアイテム購入額だけ仮想マネー残高５５０を減算・更新し、敵キャラクタを倒すことができれば経験値５４８を高めることができる。

次に、第１ゲーム管理サーバ制御部２１０は、発動検出処理を実行する（ステップＳ５０）。本実施形態では、所定のアイテム使用（ＡＰ回復アイテム）を使用する操作入力を検出するが、発動条件の設定によって異なる。例えば、発動条件を特定キャラクタ（例えば、ダンジョンのボスキャラ）の攻略とするならば、当該特定キャラクタのライフポイントが「０」になったことを検出すれば良い。また、発動条件を所定のアイテムの入手とするならば、当該所定アイテムの取得を検出すれば良い。本実施形態のように、所定アイテムの使用、特に当該アイテムが仮想マネーによる購入対象となっている場合には、プレーヤに第１ゲームと第２ゲームとの両方でメリットが得られるのでお得感を与え得るので好適である。

そして、もし発動を検出したならば（ステップＳ５２のＹＥＳ）、第１ゲーム管理サーバ制御部２１０は、第１ゲームのプレーヤキャラクタの第１パラメータを向上させる（ステップＳ５４）。本実施形態では、行動ポイントＡＰを回復させる。もし、発動条件を特定キャラクタの攻略などアイテム以外に設定している場合には、代わりに適宜、経験値５４８を向上させるなどの処理を行うと良い。

次に、第１ゲーム管理サーバ制御部２１０は、プレーヤのユーザ端末１５００に、変更通知表示Ｗ１２（図３参照）を表示させる表示制御を実行する（ステップＳ５６）。これにより、プレーヤは、現在第１ゲームをプレイしているにも関わらず、第２ゲームに波及効果が生じたことが分かる。よって、プレーヤを、第２ゲームをプレイするように誘うことができる。

次に、第１ゲーム管理サーバ制御部２１０は、第２ゲームのパラメータの向上幅（変更幅）を決定する（ステップＳ５８）。
本実施形態では、現在第１ゲームで使用中のプレイデータ５４０と、プレーヤのユーザアカウント５４１と同一アカウントで且つゲームＩＤ５４２が「第２ゲーム」となるプレイデータ５４０とを参照して向上幅を決定する。
より具体的には、第１ゲーム管理サーバ制御部２１０は、第２ゲーム管理サーバ制御部２４０から第１ゲームのユーザアカウント５４１と同一アカウントで且つゲームＩＤ５４２が「第２ゲーム」のプレイデータ５４０を取得する。
そして、第１ゲームにおけるプレーヤレベル５４６と、第２ゲームにおけるプレーヤレベル５４６とを比較する。前者と後者とが同レベルと見なせる場合、又は前者の方が後者より大きい時には向上幅（変更幅）を所定の標準値とする。標準値は、ＡＰ回復アイテムの種類によるとしても良い。もし、後者の方が前者よりも大きい場合には、向上幅（変更幅）を、例えばプレーヤレベル５４６の値の差を変数とする関数によって、そのレベル差が大きい程向上幅が標準値より小さくなるように変更する。

更に、第１ゲームにおけるプレイ日時履歴５５２と、第２ゲームにおけるプレイ日時履歴５５２とから、第１ゲームのプレイ頻度と第２ゲームのプレイ頻度を求め、前者と後者とが同一と見なせる場合、又は前者の方が後者より頻度が高い場合には、プレーヤレベル５４６に基づいて決定した向上幅（変更幅）をそのままとする。もし、後者の方が前者よりも高い場合には、先に決定した向上幅（変更幅）を、小さくなるように変更する。

尚、上述のようなプレーヤレベル５４６やプレイ頻度に基づく向上値の設定に代えて次の方法を採用することもできる。すなわち、第２ゲームの内容に応じて予めプレーヤレベル５４６と向上幅とを対応づけたテーブルデータを用意しておいて、当該テーブルデータを参照して決定する構成としても良い。具体的には、例えば、第２ゲームのプレーヤレベル５４６がレベル「１」〜レベル「５」まで設定可能な仕様として、レベル「３」なら向上幅を標準値とし、レベルが下がる程標準値より小さい値を設定し、レベルが上がるにつれて標準値より大きい値を設定する。この場合、第１ゲームにおけるプレーヤの習熟度や進捗度、やり込み度合などに関わりなく、第２ゲームにおけるその時々のプレーヤレベルに応じた適当な向上幅を決定できる。

或いは、また別の選択肢として、第２ゲームのプレイ頻度が所定の希望頻度よりも低い場合には、向上幅（変更幅）を標準値より小さくし、第１ゲームのプレイ頻度と第２ゲームのプレイ頻度がともに希望頻度に達している場合には、標準値よりも大きくする、といった構成も可能である。更に別の選択肢としては、単に第１ゲームのプレーヤレベルの大小に比例して、第２ゲームのパラメータの向上幅を増減するとしても良い。

また、向上幅の決定に際して参照するプレイデータ５４０のデータは、プレーヤレベル５４６に限らず、経験値５４８や、仮想マネー残高５５０を用いることもできる。

さて、向上幅を決定したならば、第１ゲーム管理サーバ制御部２１０は、決定した向上幅を用いて波及制御処理を実行する（ステップＳ６０）。
すなわち、第２ゲーム管理サーバシステム１１１６を外部制御して、第２ゲームにおけるプレーヤと同じユーザアカウント５２２のプレイデータ５４０の残ＡＰ５４４に、先に決定した向上幅（変更幅）分を加算する。つまりは第２ゲームの行動ポイントＡＰを回復させる。波及先となる第２パラメータを行動ポイントＡＰ以外に設定している場合、例えば、能力パラメータを第２パラメータとしている場合には、当該ステップにおいて、能力パラメータ値テーブル５５６の該当値に、先に決定した向上幅（変更幅）分を加算することとする。

そして、第２ゲームのパラメータを変更したならば、第１ゲーム管理サーバ制御部２１０は、次にゲーム終了条件を満たすかを判定する（ステップＳ８０）。ゲーム終了の操作入力が有った場合、ユーザ端末１５００との通信が所定時間以上途絶した場合、ゲームのストーリの最後まで到達した場合など、にゲーム終了条件を満たすと判定する。
そして、もし満たしたならば（ステップＳ８０のＹＥＳ）、当該ユーザ端末１５００のプレを第１ゲームプレイ中端末リスト５１５から除外して（ステップＳ８２）、ループＡを終了する（ステップＳ８４）。

実行中の全てのゲームについてループＡを実行したならば、第１ゲーム管理サーバ２１０は、再びステップＳ２に戻る。

図８は、受動実行処理の流れを説明するためのフローチャートである。ここでは、第２ゲーム管理サーバ制御部２４０が受動実行処理を行うものとして説明する。
同処理では、第２ゲーム管理サーバ制御部２４０は、他ゲーム管理サーバシステム（この場合は、第１ゲーム管理サーバ制御部２１０、第１ゲーム管理サーバシステム１１１５）から波及制御のリクエストを受信した場合（ステップＳ５０のＹＥＳ）、他ゲーム管理サーバシステムからの制御に応じてパラメータを変更する（ステップＳ５２）。本実施形態では、残ＡＰ５４４に、指定された向上幅（変更幅）分を加算して行動ポイントＡＰを回復させる。

以上、本実施形態によれば、第１ゲームにおけるゲーム進行状況が、当該第１ゲームと非同期で同一プレーヤによりプレイされる第２ゲームのゲーム進行状況に波及するといった従来に無い機能を実現できる。
より具体的には、第１ゲームでＡＰ回復アイテムを使用するなどプレーヤにとってメリットのある進行状況変化を検出すると、第１ゲームにおいて行動ポイントＡＰが回復するなどのパラメータの向上が行われるとともに、第２ゲーム（この段階ではプレイされていない）でも行動ポイントＡＰが回復するなどのパラメータの向上方向への変更（波及制御）が行われる。そして、そのことがプレーヤのユーザ端末１５００にて通知される。よって、プレーヤに第１ゲームとは異なる第２ゲームでのプレイを誘うことができる。

しかも、波及効果を奏する要素をＡＰ回復アイテムなど仮想マネーによる購入の対象とすることで、プレーヤにお得感を与えることで、アイテム購入を促進できるとともに、より一層第２ゲームをやってみようかと思わせることができる。

また、第２ゲームのパラメータに波及効果があるといっても、第１ゲームにおけるパラメータ向上幅よりも第２ゲームにおけるパラメータ向上幅は、基本的には同じかそれより下回るように設定されるので、第２ゲームのゲームバランスをいたずらに崩すようなことは起こらない。

尚、本実施形態では、第１ゲームから第２ゲームへの波及について述べたが、第１ゲーム管理サーバ制御部２１０と第２ゲーム管理サーバ制御部２４０は、同じ機能構成を有しているので、第２ゲームから第１ゲームへの波及も可能である。すなわち、図７の処理フローの「第１ゲーム」と「第２ゲーム」を逆にして読み替えた処理を第２ゲーム管理サーバ制御部２４０が実行するとともに、第１ゲーム管理サーバ制御２１０は図８の処理を実行する。これにより、第２ゲームから第１ゲームへの波及がなされる。

また、本実施形態では波及先を第２ゲーム単独として説明したが、波及先に第３ゲームや第４ゲームと言った具合にその他のゲームを追加設定することもできる。もしも、波及先のゲーム数がプレーヤ登録済のゲーム数よりも少ない場合には、ユーザ登録データ５２０のプレイ登録済ゲームリスト５２６に登録済のゲームのうち第１ゲームを除くゲームの中から波及先とするゲームを抽選する処理を、例えばステップＳ４０（図７参照）の前に挿入すると好適である。

〔第２実施形態〕
次に、本発明を適用した第２実施形態について説明する。
本実施形態は基本的には第１実施形態と同様の構成を有するが、第２ゲームのパラメータの変更を、第１ゲームを実行するプログラムによる機能の発現としてではなく、第２ゲームを実行するプログラムによる機能の発現として実現する点が異なる。尚、第１実施形態と同様の構成要素については同じ符合を付与して説明は省略するものとする。

図９と図１０は、本実施形態における非同期の異ゲーム間におけるパラメータ変更の波及について説明するための図である。
図９に示すように、本実施形態では、第１ゲームの進行制御をする第１ゲーム管理サーバ制御部２１０は、第１ゲーム内で波及効果を発動させるための発動条件が満たされた場合、プレーヤのプレイデータ５４０に発動履歴データ５６０を登録する。

発動履歴データ５６０は、例えば、発動条件ＩＤ５６２と、発動日時５６４とを含む。発動条件ＩＤ５６２は、例えば、発動要件とされるアイテムの種類や、倒すべきキャラクタＩＤなどである。本実施形態では、第１実施形態と同様にＡＰ回復アイテムとする。発動日時５６４は、発動条件を満たしたときの日時である。
本実施形態の第１ゲーム管理サーバ制御部２１０は、第１実施形態のそれのように、第２ゲームのゲームプレイデータ５４０のパラメータは変更しない。

一方、図１０に示すように、プレーヤが第１ゲームのプレイを終了して、第２ゲームのプレイを開始すると、第２ゲームを進行制御する第２ゲーム管理サーバ制御部２４０は、ゲーム開始とともに、第２ゲームのプレーヤと同じユーザアカウント５４１でゲームＩＤ５４２が「第１ゲーム」のプレイデータ５４０を参照する。当該プレイデータは、第１ゲーム管理サーバ制御部２１０から取得するとしても良い。

そして、該当するプレイデータ５４０に、発動履歴データ５６０が有れば、発動条件ＩＤ５６２に応じて、第２ゲームのパラメータを変更する。本実施形態では、残ＡＰ５４４を回復させる。すなわち、他ゲームへのパラメータの変更を波及させる波及制御を実現できる。

そして、第２ゲームのパラメータを変更する際、第２ゲーム管理サーバ制御部２４０は、第１ゲームの発動履歴データ５６０の発動日時５６４からの経過時間に応じてパラメータの変更量を可変する。
例えば、経過時間から所定の全波及発生基準時間（例えば３０分）以内であれば、発動条件ＩＤ５６２に応じた向上幅（変更幅）の１００％を、第２ゲームのパラメータ変更に適用する。もし、全波及発生基準時間を超過している場合には、超過分に応じて発動条件ＩＤ５６２に応じた向上幅（変更幅）を低減させて第２ゲームのパラメータ変更に適用する。更には、波及中止基準時間（例えば、２４時間）を超過した場合には、異ゲーム間のパラメータ変更の波及に関する処理をスキップし波及を無効とする。

図１１は、本実施形態におけるサーバシステム１１００の機能構成例を示す機能ブロック図である。本実施形態における機能構成は、基本的には第１実施形態と同様であるが、幾つかの差異がある。

先ず、本実施形態のプレイデータ管理部２１４は、発動履歴登録部２１９を含む。発動履歴登録部２１９は、発動検出部２２０により発動条件を満たしたことを検出した場合に、プレーヤのプレイデータ５４０に発動履歴データ５６０（図９参照）を登録する。

また、第１実施形態の第２ゲームデータ取得制御部２２２及び第２ゲームプレイ日時取得制御部２２４に代えて、これらに相当する他ゲームプレイデータ取得制御部２２５を有する。他ゲームプレイデータ取得制御部２２５は、他のゲーム（第２ゲーム管理サーバ制御部２４０にとっては第１ゲーム、第１ゲーム管理サーバ制御部２１０にとっては第２ゲーム）のプレイデータ５４０を取得或いは参照するための制御をする。

また、本実施形態では、第１実施形態の波及制御部２２８及び受動実行制御部２３８に代えて、能動波及制御部２２８Ｂを有する。
能動波及制御部２２８Ｂは、更に発動履歴検出部２２９を含む。能動波及制御部２２８Ｂは、発動履歴検出部２２９によって他ゲームプレイデータ取得制御部２２５により取得・参照可能となった同一プレーヤの他ゲームにおけるプレイデータ５４０から発動履歴データ５６０を検出する。そして、発動履歴データ５６０がある場合には、自ゲームのパラメータを向上幅調整部２３０で求めた向上幅の分だけ能動的に変更する。

加えて、本実施形態の向上幅調整部２３０は、他ゲームで発動条件を満たした時点からの経過時間に応じて、自ゲームのパラメータ変更に適用される向上幅（変更幅）を決定する経過時間基準変更幅決定部２３５を含む。
また、本実施形態では、受動実行制御部２３８は省略される。

尚、第２ゲーム管理サーバ制御部２４０が第１ゲーム管理サーバ制御部２１０と同様の機能構成を有するのは第１実施形態と同様である。

次に、本実施形態における第２ゲーム管理サーバ制御部２４０における処理の流れについて説明する。上述のように、第１ゲーム管理サーバ制御部２１０は第２ゲーム管理サーバ制御部２４０と同様の機能構成を有するので、ここで説明する処理の流れは、第１ゲーム管理サーバ制御部２１０における処理の流れと見ることもできる。

図１２は、本実施形態における第２ゲーム管理サーバ制御部２４０における処理の流れを説明するためのフローチャートである。基本的には、第１実施形態における処理の流れと同様であるが、ステップＳ４では、ゲーム開始リクエストをしてきたユーザ端末１５００を第２ゲームプレイ中端末リスト５１７（図５参照）に登録する。そして、本実施形態ではループＡを実行する前処理、すなわちゲーム開始前処理として、能動波及制御処理を実行する（ステップＳ１０）。

図１３は、能動波及制御処理の流れを説明するためのフローチャートである。
同処理において、第２ゲーム管理サーバ制御部２４０は先ず、ゲーム開始リクエストをしてきたユーザ端末１５００のプレーヤと同一ユーザアカウント５４１の他ゲーム（この場合第１ゲーム）のプレイデータ５４０を取得・参照し（ステップＳ１２）、参照先のプレイデータ５４０に発動履歴データ５６０が有るかを判定する（ステップＳ１４）。

もし、該当データがあれば（ステップＳ１４のＹＥＳ）、第２ゲーム管理サーバ制御部２４０は、その発動履歴データ５６０の発動日時５６４から現在までの経過時間を算出し、所定の波及中止基準時間を経過しているかを判定する（ステップＳ１６）。
そして、経過していなければ（ステップＳ１６のＮＯ）、第２ゲーム管理サーバ制御部２４０は、パラメータの向上幅（変更幅）を１次決定する（ステップＳ１８）。具体的には、自ゲームにおけるプレーヤレベル５４６や、経験値５４８、仮想マネー残高５５０、プレイ日時履歴５５２から求められるプレイ頻度、などに基づいて、それらが大きい程、大きい向上幅（変更幅）を決定する。

次いで、第２ゲーム管理サーバ制御部２４０は、発動履歴データ５６０の発動日時５６４からの経過時間に応じて先に１次決定した向上幅（変更幅）を補正して最終決定し（ステップＳ２０）、最終決定した向上幅（変更幅）だけ自ゲーム（この場合、第２ゲーム）のパラメータを変更する（ステップＳ２２）。本実施形態では、向上幅だけ自ゲームの残ＡＰ５４４を向上させる。
そして、能動波及制御処理を終了する。
尚、ステップＳ２２に伴って、パラメータが変更されている旨をプレーヤに通知する通知制御を行うとしても良い。この場合、パラメータの変更が時限付の場合には、パラメータが変更されている期間、当該通知を行うこととする。

また、図１２のフローチャートにおいて、本実施形態ではゲーム内で発動条件が満たしたと検出された場合、第１実施形態のステップＳ５８〜Ｓ６０に代えて、プレーヤのプレイ中のゲーム４０に発動履歴データ５６０を登録し（ステップＳ６２）、また既に存在する発動履歴データ５６０のうち、その発動日時５６４を起点として所定の保存期間を過ぎた発動履歴データ５６０を消去する（ステップＳ６４）。

〔変形例〕
以上、本発明を適用した２つの実施形態について説明したが、本発明の形態はこれらに限定されるものではなく、適宜構成要素の追加・省略・変更を施すことができる。

例えば、第２実施形態において、発動履歴データ５６０を、プレイデータ５４０内に格納する構成としているが、ユーザ登録データ５２０（図５参照）に格納する構成としても良い。その場合、能動波及制御処理（図１３参照）のステップＳ１２では、ユーザ登録データ５２０を参照するようにすると良い。

また、第２実施形態における発動履歴データ５６０を、第１実施形態に用いることで、波及制御部２２８を、プレーヤの第２のパラメータを所与の期間一時的に変更させる制御を実行する一時変更手段として機能させることができる。この構成は、第２ゲームにおけるパラメータの変更を、能力値やゲームに関連して適用される当選確率などを一時的に向上させるものと場合に好適である。

具体的には、図１４のフローチャートに示すように、第１実施形態の処理の流れをベースとして、ステップＳ５２に次いで、第１ゲーム管理サーバ制御部２１０が、発動履歴データ５６０を登録する（ステップＳ５３）。そして、ステップＳ５８に次いで、第１実施形態のステップＳ６０に代えて、登録されている発動履歴データ５６０に対応するように波及制御を実行することとする（ステップＳ６６）。具体的には、そのとき発動履歴データ５６０が有れば、能力値やゲームに関連して適用される当選確率などを向上させ、発動履歴データ５６０の発動日時５６４から一定時間が経過していれば、向上させていた能力値や当選確率などを初期値に戻す。そして、第１ゲーム管理サーバ制御部２１０は、発動日時５６４から一定期間を過ぎた発動履歴データ５６０を消去することで（ステップＳ６８）、次のループＡの処理タイミングでは発動から一定時間過ぎると第２パラメータ（この場合、能力値や当選確率など）は変更されなくなる。

４…行動ポイントメータ
２００ｓ…サーバ処理部
２１０…第１ゲーム管理サーバ制御部
２１４…プレイデータ管理部
２１６…行動パラメータ管理部
２１８…プレイ日時管理部
２１９…発動履歴登録部
２２０…発動検出部
２２２…第２ゲームデータ取得制御部
２２４…第２ゲームプレイ日時取得制御部
２２５…他ゲームプレイデータ取得制御部
２２６…パラメータ向上制御部
２２８…波及制御部
２２８Ｂ…能動波及制御部
２２９…発動履歴検出部
２３０…向上幅調整部
２３２…プレイデータ基準変更幅決定部
２３４…プレイ頻度基準変更幅決定部
２３５…経過時間基準変更幅決定部
２３６…通知制御部
２３８…受動実行制御部
２４０…第２ゲーム管理サーバ制御部
５００ｓ…サーバ記憶部
５０３…サーバシステムプログラム
５０５…ゲーム管理サーバプログラム
５０７…第１ゲームクライアントプログラム
５０９…第１ゲーム実行用データ
５１１…第２ゲームクライアントプログラム
５１３…第２ゲーム実行用データ
５１５…第１ゲームプレイ中端末リスト
５１７…第２ゲームプレイ中端末リスト
５２０…ユーザ登録データ
５２２…ユーザアカウント
５２４…ログイン履歴データ
５２６…プレイ登録済ゲームリスト
５４０…ゲームプレイデータ
５４０…プレイデータ
５４１…ユーザアカウント
５４２…ゲームＩＤ
５４４…残ＡＰ
５６０…発動履歴データ
５６４…発動日時
１１００…サーバシステム
１１０４…ブレードサーバ
１１１０…アカウント管理サーバシステム
１１１４…ゲーム管理サーバシステム
１１１５…第１ゲーム管理サーバシステム
１１１６…第２ゲーム管理サーバシステム
１５００…ユーザ端末
１５４０…メモリカード
１５４２…メモリカード読取装置
１５５０…制御基板
１５５３…無線通信モジュール
Ｗ２〜Ｗ８…ゲーム画面
Ｗ１２…変更通知表示

Claims (8)

1. 第１のゲームに係る各プレーヤの第１のパラメータを管理し、各プレーヤのプレーヤ端末と通信を行って第１のゲームを進行制御するサーバシステムであって、
   前記第１のゲームにおける行動の指示がなされる毎に消費し、時間経過又は前記アイテムの使用により回復する各プレーヤの行動パラメータを前記第１のパラメータとして管理する行動パラメータ管理手段と、
   一のプレーヤの前記第１のパラメータを変更する処理を発動させる所与の発動条件を満たしたことを検出する発動検出手段と、
   前記発動検出手段の検出がなされた場合に、前記一のプレーヤの前記第１のパラメータを変更する制御を行う第１の変更制御手段と、
   第２のゲームに係る各プレーヤの第２のパラメータを管理し、各プレーヤのプレーヤ端末と通信を行って第２のゲームを進行制御する第２のサーバシステムと所定の通信を行い、当該第２のサーバシステムに対して、前記発動検出手段の検出がなされた場合に、前記一のプレーヤの前記第２のパラメータを変更させる制御を行う第２の変更制御手段と、
   を備え、
   前記第２のサーバシステムは、前記第２のゲームにおける行動の指示がなされる毎に消費し、時間経過により回復する各プレーヤの行動パラメータを前記第２のパラメータとして管理し、
   前記第１の変更制御手段は、前記アイテムの使用指示がなされた場合に、前記一のプレーヤの前記行動パラメータを所与の回復量分回復させる手段を有し、
   前記第２の変更制御手段は、前記アイテムの使用指示がなされた場合に、前記一のプレーヤの前記第２のゲームに係る前記行動パラメータを変更させる手段を有する、
   サーバシステム。
2. 前記第１の変更制御手段は、前記発動検出手段の検出がなされた場合に、前記一プレーヤの前記第１のパラメータを所与の期間一時的に変更する、
   請求項１に記載のサーバシステム。
3. 前記第１の変更制御手段により前記第１のパラメータが変更されている際に、その旨を前記一のプレーヤのプレーヤ端末に通知する変更通知手段を更に備えた、
   請求項２に記載のサーバシステム。
4. 前記第２の変更制御手段は、前記一のプレーヤの前記第２のパラメータを所与の期間一時的に変更させる一時変更手段を有する、
   請求項１〜３の何れか一項に記載のサーバシステム。
5. 第１のゲームに係る各プレーヤの第１のパラメータを管理し、各プレーヤのプレーヤ端末と通信を行って第１のゲームを進行制御するサーバシステムであって、
   一のプレーヤの前記第１のパラメータを変更する処理を発動させる所与の発動条件を満たしたことを検出する発動検出手段と、
   前記発動検出手段の検出がなされた場合に、前記一のプレーヤの前記第１のパラメータを変更する制御を行う第１の変更制御手段と、
   第２のゲームに係る各プレーヤの第２のパラメータを管理し、各プレーヤのプレーヤ端末と通信を行って第２のゲームを進行制御する第２のサーバシステムと所定の通信を行い、当該第２のサーバシステムに対して、前記発動検出手段の検出がなされた場合に、前記一のプレーヤの前記第２のパラメータを変更させる制御を行う第２の変更制御手段と、
   各プレーヤの前記第１のゲームにおけるレベル、経験値、仮想マネー及び所与のアイテムを出現させる出現確率のうちの少なくとも１つを含むプレイデータを管理するプレイデータ管理手段と、
   前記第２のサーバシステムから前記一のプレーヤの前記第２のゲームにおけるプレイデータを取得する第２ゲームデータ取得手段と、
   を備え、
   前記第２の変更制御手段は、前記プレイデータ管理手段で管理されている前記一のプレーヤに係るプレイデータと、前記第２ゲームデータ取得手段により取得されたプレイデータとの差を用いて、前記第２のパラメータの変更幅を決定し、当該決定した変更幅で前記第２のパラメータを変更させる変更幅調整手段を有する、
   サーバシステム。
6. 第１のゲームに係る各プレーヤの第１のパラメータを管理し、各プレーヤのプレーヤ端末と通信を行って第１のゲームを進行制御するサーバシステムであって、
   一のプレーヤの前記第１のパラメータを変更する処理を発動させる所与の発動条件を満たしたことを検出する発動検出手段と、
   前記発動検出手段の検出がなされた場合に、前記一のプレーヤの前記第１のパラメータを変更する制御を行う第１の変更制御手段と、
   第２のゲームに係る各プレーヤの第２のパラメータを管理し、各プレーヤのプレーヤ端末と通信を行って第２のゲームを進行制御する第２のサーバシステムと所定の通信を行い、当該第２のサーバシステムに対して、前記発動検出手段の検出がなされた場合に、前記一のプレーヤの前記第２のパラメータを変更させる制御を行う第２の変更制御手段と、
   各プレーヤのプレイ日時を管理するプレイ日時管理手段と、
   前記第２のサーバシステムから前記一のプレーヤのプレイ日時のデータを取得する第２ゲームプレイ日時取得手段と、
   を備え、
   前記第２の変更制御手段は、前記プレイ日時管理手段で管理されている前記一のプレーヤのプレイ日時と、前記第２ゲームプレイ日時取得手段により取得されたプレイ日時とに基づいて、前記第１のゲームと前記第２のゲームのプレイ頻度の差を求め、当該プレイ頻度の差を用いて、前記第２のパラメータの変更幅を決定し、当該決定した変更幅で前記第２のパラメータを変更させる変更幅調整手段を有する、
   サーバシステム。
7. 前記発動条件を満たすことで前記一のプレーヤの前記第２のパラメータが変更される旨を前記一のプレーヤのプレーヤ端末に表示させる通知制御手段を更に備えた請求項１〜６の何れか一項に記載のサーバシステム。
8. 第２のゲームに係る各プレーヤの第２のパラメータを管理し、各プレーヤのプレーヤ端末と通信を行って第２のゲームを進行制御するサーバシステムであって、
   請求項１〜７の何れか一項に記載のサーバシステムの前記第２の変更制御手段の制御に従って、前記一のプレーヤの前記第２のパラメータを変更する受動実行手段を更に備えたサーバシステム。

Images