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

Abstract

【課題】非同期のゲームにおいて、ユーザ同士が互いの存在を感じられるようにして、ユーザ間のコミュニケーションの活性化や連帯感の向上を図る。
【解決手段】第１ゲームで一のプレーヤがＡＰ回復アイテムを使用するなどプレーヤにとってメリットのある進行状況変化を検出すると、第１ゲームにおいて行動ポイントＡＰが回復するなどのパラメータの向上が行われる。加えて、当該プレーヤのフレンドユーザの第２ゲームでも行動ポイントＡＰが回復するなどのパラメータの向上（波及制御）が行われる。そして、そのことが発動通知表示Ｗ１２により第１ゲームのプレーヤのユーザ端末１５００にて通知される。
【選択図】図３

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 (11)

1. 各プレーヤのプレーヤ端末から送信される操作入力に従って、各プレーヤに係るゲーム進行を非同期に制御するサーバシステムであって、
   各プレーヤそれぞれのパラメータを管理するパラメータ管理手段と、
   各プレーヤそれぞれについて、当該プレーヤに関係する関係プレーヤを記憶する関係プレーヤ記憶手段と、
   一のプレーヤの前記パラメータを変更する処理を発動させる所与の発動条件を満たしたことを検出する発動検出手段と、
   前記発動検出手段の検出がなされた場合に、前記一のプレーヤの前記パラメータを変更するパラメータ変更制御手段と、
   前記発動検出手段の検出がなされた場合に、前記一のプレーヤの関係プレーヤの前記パラメータを変更する波及制御を実行する波及制御手段と、
   を備えたサーバシステム。
2. 前記発動検出手段は、前記一のプレーヤの前記パラメータを変更させる所与のアイテムの使用或いは所与の動作の実行の指示操作入力がなされたことを前記発動条件として検出する、
   請求項１に記載のサーバシステム。
3. 前記発動検出手段は、前記一のプレーヤに係るゲーム進行が所与の条件を満たしたことを前記発動条件として検出する、
   請求項１に記載のサーバシステム。
4. 前記波及制御手段は、前記パラメータ変更制御手段による前記パラメータの変更幅よりも小さい変更幅で前記一のプレーヤの関係プレーヤの前記パラメータを変更する制御を前記波及制御として実行する変更幅調整手段を有する、
   請求項１〜３の何れか一項に記載のサーバシステム。
5. 前記波及制御手段は、前記発動検出手段の検出がなされた後、前記一のプレーヤの関係プレーヤがログインした際に、当該関係プレーヤの前記パラメータを変更し、
   前記変更幅調整手段は、前記発動検出手段の検出がなされてから、前記一のプレーヤの関係プレーヤがログインするまでの時間経過に応じて、当該関係プレーヤの前記パラメータを変更する変更幅を調整する、
   請求項４に記載のサーバシステム。
6. 各プレーヤそれぞれについて、当該プレーヤと当該プレーヤの関係プレーヤとの友好度を記憶する友好度記憶手段を更に備え、
   前記変更幅調整手段は、前記一のプレーヤの関係プレーヤの前記パラメータの変更幅を、当該一のプレーヤとの友好度を用いて変更する、
   請求項４又は５に記載のサーバシステム。
7. 前記変更幅調整手段は、前記一のプレーヤの関係プレーヤの人数を用いて、当該関係プレーヤの前記パラメータの変更幅を変更する手段を有する、
   請求項４〜６の何れか一項に記載のサーバシステム。
8. 前記波及制御手段は、前記発動検出手段の検出がなされた場合に、前記一のプレーヤの関係プレーヤの前記パラメータを所与の期間一時的に変更する時限制御手段を有する、
   請求項１〜７の何れか一項に記載のサーバシステム。
9. 各プレーヤそれぞれについて、当該プレーヤと当該プレーヤの関係プレーヤとの友好度を記憶する友好度記憶手段を更に備え、
   前記時限制御手段は、前記一のプレーヤの関係プレーヤの前記パラメータを変更する時限を、前記一のプレーヤとの友好度を用いて変更する、
   請求項８に記載のサーバシステム。
10. 前記一のプレーヤの関係プレーヤのうち、前記波及制御手段による波及制御の対象とする関係プレーヤ（以下「波及先プレーヤ」という。）を選択する波及先選択手段を更に備え、
    前記波及制御手段は、前記波及先選択手段により選択された波及先プレーヤの前記パラメータを対象に前記波及制御を実行する、
    請求項１〜９の何れか一項に記載のサーバシステム。
11. 各プレーヤそれぞれについて、当該プレーヤと当該プレーヤの関係プレーヤとの友好度を記憶する友好度記憶手段を更に備え、
    前記波及先選択手段は、前記一のプレーヤと当該関係プレーヤとの友好度を用いて、波及先プレーヤを選択する、
    請求項１０に記載のサーバシステム。

Images