JP2013208271A - サーバシステム - 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）、ＶＲＡＭやＲＡＭ，ＲＯＭ等の各種ＩＣメモリ１５５２を搭載する。

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

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

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

尚、本実施形態のユーザ端末１５００は、ゲームプレイに係る操作入力指示信号をサーバシステム１１００に送信する際、ＧＰＳモジュール１５５４で取得した位置情報を一緒に送信することができる。

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

メッセージ交換は、ログインしているユーザ間でのショートメール等のメッセージの送受をサポートするサービスであり、例えばプッシュ通知などにより実現される。そして、ユーザはメッセージのやりとりを通じて気の合った他ユーザを所定の登録手続きによって「フレンド」として登録する機能を提供する。以降、一のユーザにより「フレンド」として登録された関係ユーザを「フレンドユーザ」と呼ぶ。図１の例では、ユーザ２（２ａ）は、他のユーザ２（２ｂ，２ｃ，２ｄ，２ｅ，・・・）をフレンドユーザとして登録している。

また、ユーザは、所定のゲーム利用登録をすることで、複数のゲームの中から任意のゲームを好きな時に好きな時間だけ遊ぶことが可能である。本実施形態で説明するゲームはその一つに含まれる。

［非同期のゲーム間でのフレンドＮＰＣの出現についての説明］
図３は、本実施形態のゲームの概要について説明する図である。本実施形態のゲームは、シングルプレイ型のオンラインＲＰＧ（ロールプレイングゲーム）である。各ユーザ２（２ａ、２ｂ）は、同じゲーム世界の設定であるが相互には非同期で、互いに独立したゲーム空間内で自身のプレーヤキャラクタ４（４ａ，４ｂ）を操作してシングルプレイする。マルチプレイ型オンラインＲＰＧのように、両プレーヤが同じゲーム空間を共有することはない。よって、図３の例では、ユーザ端末１５００（１５００ａ）のゲーム画面Ｗ２と、ユーザ端末１５００（１５００ｂ）のゲーム画面Ｗ４とでは異なる内容が示されている。

本実施形態のオンラインＲＰＧでは、いわゆる雑魚キャラに相当する敵戦闘員ＮＰＣ（ノンプレーヤキャラクタ）８と、所定エリアに進入すると現れる敵ボスＮＰＣ６とが登場する。
プレーヤキャラクタ４（４ａ、４ｂ）と、敵ＮＰＣにはそれぞれライフポイントが設定され、相手の攻撃を受けるとダメージ量に応じてライフポイントが減らされる。それぞれのライフポイントはゲーム画面中にライフポイントゲージ５，７，９として表示される。そして、ライフポイントが「０」になると、そのキャラクタは死亡・撃破扱いとなる。

ライフポイントに関しては、プレーヤキャラクタ４（４ａ、４ｂ）と敵戦闘員ＮＰＣ８については、ゲームプレイ毎にライフポイントが管理されており、異なるゲーム間では干渉されない。ユーザ２（２ａ）のゲーム世界に敵戦闘員ＮＰＣ８が登場しても、それらはそのゲーム世界のみで有効であり、ユーザ２（２ｂ）の世界でダメージを受けてもその影響は受けない。

一方、敵ボスＮＰＣ６については、ゲーム世界を跨いでライフポイントが管理される。すなわち、非同期のゲームで、別々のゲームプレイに登場するものの、管理されるライフポイントは共通である。従って、ユーザ２（２ａ）が敵ボスＮＰＣ６を攻撃してダメージを与えると、仮にユーザ２（２ｂ）が非同期であるがやはり敵ボスＮＰＣ６と戦っている場合、当該ユーザ２（２ｂ）のゲーム世界の敵ボスＮＰＣ６のライフポイントには、先のユーザ２（２ａ）が与えたダメージの影響が現れる。つまり、敵ボスＮＰＣ６と遭遇している間は、間接的に他ゲーム世界と影響を与え合うが、敵ボスＮＰＣ６が現れていないゲーム世界は互いに独立している。

そして、この敵ボスＮＰＣ６を倒すと、通常では得られない特典がユーザに与えられるので、敵ボスＮＰＣ６の攻略はユーザの憧れである。しかし、敵ボスＮＰＣ６は、ライフポイントの自動回復の能力を有する設定であり、一定時間が経過する毎にライフポイントが所定量回復される。結果、ユーザが一人で敵ボスＮＰＣ６に戦いを挑んでダメージを与えてもライフポイントの回復により帳消しとなり得るため、一人で戦っても攻略できない可能性が極めて高い。敵ボスＮＰＣ６の攻略には、複数のユーザがほぼ同時刻に戦う連係が必要である。しかし、公知のＳＮＳゲームでは、ユーザ間のゲームは非同期であるから、連係をとるためには、別途、互いにメールを出し合う等の必要がある。しかし、本実施形態のゲームでは、この欠点を補うべく、非同期のゲーム間でのフレンドＮＰＣの出現機能を備える。

図４は、本実施形態における非同期のゲーム間でのフレンドＮＰＣの出現について説明する概念図である。あるユーザ２（２ａ）がゲームプレイしていときに、当該ユーザのフレンドユーザで、同時刻にプレイしていると判定されるフレンドユーザ２（２ｂ，２ｃ，２ｄ，２ｅ・・・）から、対象とするフレンドユーザ２（２ｂ）が適当数選択される。勿論、一人でも良いし全員でも良い。

そして、選択されたフレンドユーザ２（２ｂ）が使用するオリジナルのプレーヤキャラクタ４（４ｂ）をベースとして、フレンドＮＰＣ１２が生成される。
フレンドＮＰＣ１２は、基本的にはそのフレンドユーザ２（２ｂ）のプレーヤキャラクタ４（４ｂ）と同じ外観を有するが、フレンドユーザ２（２ｂ）のゲーム状況に応じた表示形態の変化が与えられる。表示形態の変化としては、例えば、着衣等のアイテムの色の違い、キャラクタのボディやアイテムの明滅、色相の周期変化、輪郭線の色違いなどである。また、フレンドＮＰＣ１２には、出現頻度と出現確率とが設定される。

出現頻度は、フレンドＮＰＣ１２がユーザ２（２ａ）のゲーム世界に登場する機会を定義する。図４の例では、ユーザ２（２ａ）のプレーヤキャラクタ４（４ａ）が戦闘中である場合と、ゲーム世界内で訪れることのできる街にいる場合と、が出現の機会とされる。出現頻度の設定方法は適宜変更可能であり、例えば、「１分に１回」や「戦闘３回につき１回」、「画面切替５回に１回」といった設定方法も可能である。出現確率は、個別の出現機会において実際に出現する確率を定義する。出現頻度及び／又は出現確率によって、出現の度合が設定されるとも言える。

出現頻度及び出現確率は、フレンドユーザ２（２ｂ）のユーザ登録情報や、ユーザ２（２ａ）やフレンドユーザ２（２ｂ）のゲーム進行状況、現在位置などに係る各種パラメータを用いて決定することができる。その際、フレンドユーザ２（２ｂ）がよりユーザ２（２ａ）と親密である（友好度が高い）ほど、またフレンドユーザ２（２ｂ）がよりゲームをプレイしているほど、またフレンドユーザ２（２ｂ）がよりユーザ２（２ａ）に近い場所でプレイしているほど、機会が多くなるように、また出現確率が高くなるように設定される。

具体的には、例えば、参照するユーザ登録情報としては、年齢、居住地などを利用し、ユーザ２（２ａ）とフレンドユーザ２（２ｂ）の年齢が近いほど出現頻度や出現確率を高めに設定することができる。
また、ユーザ２（２ａ）又はフレンドユーザ２（２ｂ）のオンラインショッピング等の課金額や利用頻度、フレンド登録数が高いほど出現頻度や出現確率を高めに設定するとしても良い。
またユーザ２（２ａ）とフレンドユーザ２（２ｂ）とのチャット頻度等から決定される友好度が高いほど出現頻度や出現確率を高めことができる。
また、ユーザ２（２ａ）又はフレンドユーザ２（２ｂ）の総プレイ時間やプレーヤレベルなどのやりこみ度合が高いほど出現頻度や出現確率を高めに設定するとしても良い。
また、現実世界におけるユーザ２（２ａ）がゲームプレイしている場所と、フレンドユーザ２（２ｂ）がゲームプレイしている場所の位置座標が近いほど出現頻度や出現確率を高く設定するとしても良い。

本実施形態では、フレンドユーザ２（２ｂ）の操作入力指示信号の受信間隔が短いほど（すなわち、より積極的にゲームプレイしていると判断できる場合や、確実にゲームプレイしていると判断できる場合）に、出現頻度を高く設定する。また、出現確率は、友好度が高いほど高く１次設定し、更にユーザ２（２ａ）のゲーム進行状況に応じて１次出現確率を変更して最終的に適用される最終出現確率を設定する。１次出現確率のゲーム進行状況に応じた変更は、例えば、敵ボスＮＰＣ６が出現中の場合や、ユーザ２（２ａ）のプレーヤキャラクタ４（４ａ）のライフポイントの残量の全量に対する割合が基準値より低い場合、など危機度合が高いほど、高出現確率となるように変更する。

こうして設定されたフレンドＮＰＣ１２は、本実施形態では、ユーザ２（２ａ）のゲーム世界にユーザ２（２ａ）のゲーム進行を有利にする役どころ、例えば戦闘中の救援役として登場するように制御される。勿論、登場のさせ方は、ゲーム内容やゲームバランスに応じて適宜変更可能であり、単なるエキストラとして登場させても良い。

また、フレンドＮＰＣ１２を登場させる際、フレンドユーザ２（２ｂ）のゲーム進行状況を示す状況表示体１４や、フレンドユーザ２（２ｂ）のユーザアカウントを示すフレンド名表示１６が付加表示される。
状況表示体１４は、適宜設定可能であるが、例えば戦闘相手の識別可能な表示体（図４の例では、敵ボスＮＰＣ６との戦闘中を意味する「ＢＦ：Boss Fight）」の文字が示された表示体）や、連続プレイ時間を示す表示体などが可能である。

こうしたフレンドＮＰＣ１２の出現により、ユーザ２（２ａ）は、フレンドユーザ２（２ｂ）が現在ゲームプレイ中であることを知ることができる。よって、非同期のゲームにおいて、ユーザ同士が互いの存在を感じられるようになり、例えばゲームプレイ後に、「今日はずいぶん積極的に戦っていたね！マップのどの辺りまわったの？」と言った具合に、ユーザ間のコミュニケーションのきっかけ作りができる。

また、フレンドユーザ２（２ｂ）が、ゲームプレイしていること、特に敵ボスＮＰＣ６と対戦中であることを知ることができると、図５に示すように、ユーザ２（２ａ）は、これを機に自身のプレーヤキャラクタ４（４ａ）も敵ボスＮＰＣ６の出現エリアに進入してボス戦を開始し、実質的なフレンドユーザ２（２ｂ）との連係プレイが可能となる。
ユーザ２（２ａ）のゲーム画面Ｗ８での敵ボスＮＰＣ６（６ａ）と、フレンドユーザ２（２ｂ）のゲーム画面Ｗ１０での敵ボスＮＰＣ６（６ｂ）とでは、行動が非同期であるが、前述のようにライフポイントは非同期ゲーム間で共通の扱いである。よって、連係により、敵ボスＮＰＣ６のライフポイントを自動回復よりも早く削り、ライフポイントを「０」にして、単独では実現が困難だった敵ボスＮＰＣ６（６ａ，６ｂ）の撃破及びし得なかった特典付与を受けることが可能となる。
当然、このボス戦も格好の話題となり、ユーザ間のコミュニケーション活性化と連帯感向上の一助となる。

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

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

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

そして、本実施形態のサーバ処理部２００ｓは、ユーザ登録情報管理部２０２と、ログイン処理部２０４と、ゲーム管理サーバ制御部２１０と、端末位置情報取得制御部２３６と、画像生成部２６０ｓと、通信制御部２７０ｓとを備える。尚、プレイ可能なゲームの種類に応じてゲーム管理サーバ制御部の数を適宜加減することができる。

ユーザ登録情報管理部２０２は、ユーザアカウントの新規発行、パスワードの登録など各種ユーザ情報の取得・登録管理に関する処理を実行する。尚、ユーザ登録情報管理部２０２は、公知のコミュニティ型のウェブサイトやオンラインゲームにおけるユーザ登録関連技術を適宜応用することで実現できる。そして、本実施形態のユーザ登録情報管理部２０２は、フレンドリスト管理部２０３を含み、フレンドユーザ（プレーヤに関係する関係プレーヤ）の登録・抹消に関する処理を実行する。

ログイン処理部２０４は、通信接続したユーザ端末１５００からのリクエストに応じて所謂ログインを制御する。当該処理部は、公知のコミュニティ型のウェブサイトやオンラインゲームにおけるログイン制御技術を適宜利用することで実現できる。図１の例では、アカウント管理サーバ１１１０がユーザ登録情報管理部２０２と、ログイン処理部２０４とを担う。

ゲーム管理サーバ制御部２１０は、本実施形態のゲームの進行制御並びにユーザ端末１５００にてゲーム画像等を表示させるのに必要な処理を実行する。すなわち、常時機能している状態にあって、ユーザ端末１５００からゲーム開始リクエストを受けると新たな個別プレイデータ５４０（図７、図８参照）を生成して、個別にゲーム進行制御することができる。

ゲーム管理サーバ制御部２１０は、プレイデータ管理部２１４と、同時プレイ判定部２２０と、フレンドＮＰＣ出現制御部２２４と、ゲーム進行制御部２３４とを含む。

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

プレイ日時管理部２１８は、プレーヤのプレイ日時に関する情報の取得・管理をする。具体的には、ゲームプレイに関する情報、例えば、ログイン、ログアウト、ゲームプレイに係る操作入力指示信号をユーザ端末１５００から受信すると、その時の日時をアクセス日時とし、受信した操作入力指示信号と、それと一緒に受信したユーザ端末１５００の端末位置座標とを対応づけてサーバ記憶部５００ｓに記憶させて管理する。

同時プレイ判定部２２０は、プレイ日時管理部２１８により管理されているプレイ日時を用いて、一のプレーヤのプレイ中に、当該一のプレーヤのフレンドユーザ（関係プレーヤ）がプレイしているか否かを判定する。
本実施形態では、アクセス日時基準判定部２２２を有し、操作入力指示信号をユーザ端末１５００から受信したアクセス日時を用いて、フレンドプレーヤがプレイしているか否かを判定することができる。

フレンドＮＰＣ出現制御部２２４は、非同期のゲーム間でのフレンドＮＰＣ１２（図４参照）の出現に関する制御を行う。すなわち、図４を参照して説明した機能を実現するための処理を実行することができる。そして、本実施形態では、出現頻度設定部２２６と、出現確率設定部２２８と、出現条件判定部２２９と、キャラクタ表示形態変更部２３０と、付加表示制御部２３２とを有する。

出現頻度設定部２２６は、フレンドＮＰＣ１２の出現頻度を設定することができる。本実施形態では、少なくとも一のプレーヤの関係プレーヤの最新の前記アクセス日時からの経過時間が経過するに従って、フレンドＮＰＣの出現頻度を低下させるように設定することができる。

出現確率設定部２２８は、フレンドＮＰＣ１２の出現確率を設定することができる。本実施形態では、一のプレーヤとその一のプレーヤの関係プレーヤとの友好度に応じて、関係プレーヤに関するフレンドＮＰＣ１２の出現確率を変更することができる。また、同時プレイ判定部２２０により一のプレーヤのプレイ中に、一のプレーヤのフレンドユーザ（関係プレーヤ）がプレイしていないと判定された場合には、稀に前記フレンドＮＰＣ１２を出現させる確率として定められた所与の低出現確率に出現確率を設定することができる。勿論、出現確率をフレンドユーザのゲーム状況に応じて変更する構成も可能である。

出現条件判定部２２９は、フレンドＮＰＣ１２を出現させる条件が整ったかを判定する。本実施形態では、出現頻度で定義された出現の機会が到来したかを判定し、更に出現確率を見たすかを判定し、且つ一のプレーヤの関係プレーヤの位置とが所定の位置条件を満たすかを判定する。そして、この３条件を満たした場合にフレンドＮＰＣ１２を出現させる条件が整ったと判定する。尚、これらの判定のうち幾つかを省略した構成も可能である。

キャラクタ表示形態変更部２３０は、一のプレーヤのフレンドプレーヤ（関係プレーヤ）のゲーム状況に応じて、フレンドＮＰＣ１２の表示形態を変更する。

付加表示制御部２３２は、状況表示体１４及びフレンド名表示１６（図４参照）の表示制御を行う。

ゲーム進行制御部２３４は、ゲーム進行に関する各種処理を実行する。
例えば、ゲーム空間の設定、当該ゲーム空間へのキャラクタ等のオブジェクトの配置、プレーヤキャラクタを撮影する仮想カメラの制御、ＮＰＣの自動動作制御、イベント発生の抽選処理、攻撃ヒット判定及びダメージ判定、ダメージの反映を含むキャラクタのパラメータ変更に関する処理、ゲーム終了条件の判定、各種タイマーやカウンタの管理などを行うことができる。本実施形態では、特定ＮＰＣ（本実施形態では敵ボスＮＰＣ６）が出現している場合に、非同期の他ゲームと共通で管理される当該特定ＮＰＣのパラメータを参照・変更することができる。

端末位置情報取得制御部２３６は、ユーザ端末１５００で測定される位置情報を取得するための制御を行い、プレーヤ位置取得手段として機能する。

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

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

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

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

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

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

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

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

ゲーム空間初期設定データ５０８は、ゲーム空間を構築するために必要な背景オブジェクトのモデルデータやテクスチャデータ、配置位置情報等を含む。また、天球に適用される背景画像データなども適宜含めることができる。

キャラクタ初期設定データ５１０は、ゲームに登場するプレーヤキャラクタやＮＰＣを表示・動作させるための各種データを格納する。例えば、キャラクタのモデルデータ、テクスチャデータ、モーションデータ、付属アイテムのモデルデータ等を格納する。また、キャラクタのライフポイントや各種能力パラメータ値の初期設定値を格納する。

キャラクタ表示形態設定データ５１２は、プレーヤキャラクタ４の表示形態をゲーム進行状況に応じて変更するためのデータを格納する。例えば、プレーヤキャラクタ４（４ａ，４ｂ）として選択可能なキャラクタ種類毎に、ゲーム進行状況別の表示形態の定義情報を格納する。ゲーム進行状況としては、敵ボスＮＰＣ６の出現の有無、ライフポイントの残り割合、ゲーム画面内に出現している敵戦闘員ＮＰＣ８の数、連続プレイ時間などを適宜設定できる。また、表示形態の定義としては、カラーを変更するキャラクタの特定部位を指定するための指定情報と、カラーを変更するためのカラー値や色相設定データ、明滅パターンなどを設定することができる。

状況表示体設定データ５１４は、ゲーム進行状況毎の状況表示体１４を定義する。
ゲームプレイ中端末リスト５１６は、ゲームをプレイしているユーザ端末１５００のリストデータであって、各端末毎のユーザアカウントや、ＩＰアドレスなどを対応づけて格納する。

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

ログイン履歴データ５２４は、ログイン、ログアウトの日時等の履歴である。
フレンドリスト５２５は、フレンドとして登録されている他ユーザに係る情報を格納する。例えば、フレンドユーザのユーザアカウント５２５ａと、友好度５２５ｂと、チャット履歴データ５２５ｃとを対応づけて格納する。

個別プレイデータ５４０は、ゲームとプレーヤ（ゲームをプレイするユーザ）の組み合わせ毎に用意され、当該ゲームの進行状況を記述する各種データを格納する。
例えば図８に示すように、
（１）プレーヤ（ゲームをプレイするユーザ）の識別情報であるユーザアカウント５４１と、
（２）ゲームＩＤ５４２と、
（３）ゲーム成績等に応じて自動的に設定されるプレーヤレベル５４４と、
（４）オンラインショッピングサービスを利用してゲーム世界で使用できるアイテムを購入するための仮想マネー残高やその履歴などを格納する課金履歴５４６と、
（５）プレーヤキャラクタのゲーム内世界での位置座標を示すゲーム世界内位置座標５４８と、
（６）プレーヤキャラクタ４の種類や外観の設定情報を格納するプレーヤキャラクタ設定データ５４９と、
（７）プレイ日時履歴５５０と、
（８）ライフポイント５６０と、
（９）所持アイテムリスト５６２と、
（１０）能力パラメータ値テーブル５６４と、
（１１）フレンドＮＰＣステータスデータ５７０と、
（１２）敵戦闘員ＮＰＣステータスデータ５８０と、
（１３）敵ボスＮＰＣステータスデータ５８２と、
を格納する。勿論、その他のタイマー値や、各種フラグなどのゲーム進行制御に必要な各種情報を格納することができる。

プレイ日時履歴５５０は、ユーザ端末１５００から操作指示入力信号を受信した日時であるアクセス日時５５２と対応づけて、操作入力指示信号５５４と、ユーザ端末１５００の位置情報である端末位置座標５５６とを対応づけて格納する。

フレンドＮＰＣステータスデータ５７０は、フレンドＮＰＣ１２毎に用意され、当該ＮＰＣを表示し、動作制御するために必要な各種情報を格納する。例えば、当該フレンドＮＰＣの元になったプレーヤキャラクタを使用するフレンドユーザのユーザアカウントであるフレンドユーザアカウント５７２と、フレンドＮＰＣ１２を表示させるためのモデルデータや表示形態を定義する情報を含むフレンドＮＰＣ設定データ５７４と、出現頻度５７６と、出現確率５７８とを格納する。

敵戦闘員ＮＰＣステータスデータ５８０は、敵戦闘員ＮＰＣ８を個別に制御するための各種データを格納する。
敵ボスＮＰＣステータスデータ５８２は、敵ボスＮＰＣ６の位置座標と、動作制御に関する情報を格納する。ここには、敵ボスＮＰＣ６のライフポイントのデータは含まれない。

図７に戻り、共通プレイデータ６００は、非同期のゲームに共通して登場し、パラメータ管理が共通する特定キャラクタのデータを格納する。例えば、図９に示すように、敵ボスＮＰＣ６毎に、共通キャラクタステータスデータ６０２が用意される。一つの共通キャラクタステータスデータ６０２には、ボスキャラＩＤ６０４と、ライフポイント６０８と、ダメージ功績データ６１０とが含まれる。

ライフポイント６０８は、非同期のゲーム間で共通するライフポイントの残り値を格納する。

ダメージ功績データ６１０は、当該キャラクタに与えたダメージに関する情報として、ダメージが発生したダメージ日時６１２と、ダメージ量６１４と、当該ダメージを与えたゲームのプレーヤのユーザアカウントである功績者ユーザアカウント６１６とを対応づけて格納する。

［処理の流れの説明］
次に、フレンドＮＰＣ１２の出現に係るサーバシステムの処理の流れについて説明する。尚、プレーヤは既にユーザアカウントを取得し、何人かの関係ユーザをフレンド登録しているものとする。尚、フレンドリストへのフレンドユーザの登録／抹消は公知技術を適宜利用可能なので、ここでの説明は省略する。

図１０〜図１１は、フレンドＮＰＣの出現に係るサーバシステムの処理の流れについて説明するためのフローチャートである。ゲーム管理サーバ制御部２１０は、ユーザ端末１５００からゲーム開始リクエストを受信すると（ステップＳ２のＹＥＳ）、当該ユーザ端末１５００をゲームプレイ中端末リスト５１６に登録し、個別プレイデータ５４０のプレイ日時履歴５５０を更新する（ステップＳ４）。

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

次に、ゲーム管理サーバ制御部２１０は、プレイ中のゲーム毎にループＡを実行する（ステップＳ２０〜Ｓ２３４：図１１）。
ループＡでは、先ずユーザ端末１５００から操作入力指示信号を受信したならば（ステップＳ２２のＹＥＳ）、プレイ日時履歴５５０を更新する（ステップＳ２４）。尚、操作入力指示信号の受信にともない、ユーザ端末１５００からは最新の位置情報も受信するものとする。

次に、ゲーム管理サーバ制御部２１０は、ループＡの処理対象のゲームをプレイするユーザのフレンドユーザ毎にループＢを実行する（ステップＳ３０〜Ｓ１３８）。
ループＢでは、ゲーム管理サーバ制御部２１０は先ず、フレンドユーザプレイ判定処理を実行する（ステップＳ３６）。
図１２は、本実施形態におけるフレンドユーザプレイ判定処理の流れを説明するためのフローチャートである。同処理において、ゲーム管理サーバ制御部２１０は、直近のアクセス日時５５２の時間間隔を算出し（ステップＳ５０）、当該時間間隔が所定のプレイ継続判定基準値（例えば、１０秒）未満である場合には（ステップＳ５２のＹＥＳ）、ループＢの処理対象のフレンドユーザはプレイ中であると判定し（ステップＳ５４）、フレンドユーザプレイ判定処理を終了する。もし、時間間隔が所定のプレイ継続判定基準値以上であれば（ステップＳ５２のＮＯ）、プレイしていないと判定して（ステップＳ５６）、フレンドユーザプレイ判定処理を終了する。

図１０のフローチャートに戻って、ループＢの処理対象のフレンドユーザがプレイ中であると判定された場合（ステップＳ９４のＹＥＳ）、ゲーム管理サーバ制御部２１０は、フレンドＮＰＣステータスデータ５７０（図８参照）を設定する（ステップＳ９６）。この時、フレンドＮＰＣ設定データ５７４には、ループＢの処理対象のフレンドユーザの個別プレイデータ５４０のプレーヤキャラクタ設定データ５４９の複製情報を格納する。

次いで、ゲーム管理サーバ制御部２１０は、処理対象のフレンドユーザのプレイ日時履歴５５０を参照して、直近のアクセス日時５５２から現在までの経過時間を算出し（ステップＳ９８）、算出した経過時間に応じた出現頻度５７６（図８参照）を決定する（ステップＳ１００）。更に、ループＡの処理対象のゲームをプレイしているユーザのフレンドリスト５２５を参照して（図７参照）、当該ユーザとループＢの処理対象のフレンドユーザとの友好度５２５ｂに応じて出現確率５７８（図８参照）を１次設定する（ステップＳ１０２）。そして、当該ユーザのゲーム進行状況に応じてこの１次設定された出現確率を変更し、最終出現確率を決定し（ステップＳ１０４）、ループＢを終了する（ステップＳ１３８）。

一方、ループＢ処理対象のフレンドユーザが現在プレイ中でないと判定された場合には（ステップＳ９４のＮＯ）、ゲーム管理サーバ制御部２１０は出現確率５７８を所定の低確率値に設定し（ステップＳ１０６）、ループＢを終了する（ステップＳ１３８）。

ループＡの処理対象のフレンドユーザ全てについてループＢを実行したならば、図１１のフローチャートに移って、ゲーム管理サーバ制御部２１０は、次にループＡの処理対象のゲームをプレイしているユーザに係る全てのフレンドＮＰＣについて、具体的には個別プレイデータ５４０に格納されている全てのフレンドＮＰＣステータスデータ５７０についてループＣを実行する（ステップＳ１４０〜Ｓ１５６）。

ループＣでは、ゲーム管理サーバ制御部２１０は、処理対象フレンドＮＰＣの出現機会が到来したかを判定する（ステップＳ１４２）。具体的には、出現頻度５７６を満たすか否かを判定する（図８参照）。
もし、出現機会が到来していると判定した場合には（ステップＳ１４２のＹＥＳ）、ループＡの処理対象のゲームをプレイしているユーザのユーザ端末１５００の最新の端末位置座標５５６と、ループｃの処理対象のフレンドＮＰＣのフレンドユーザアカウント５７２（図８参照）の最新の端末位置座標５５６とを比較して、相対位置関係が所定の位置条件を満たすかを判定する（ステップＳ１４４）。所定の位置条件としては、例えば、１０キロメートルに相当する位置関係、あるいは同じ地名に相当する位置関係など適宜設定可能である。

もし、位置条件を満たしている場合には（ステップＳ１４４のＹＥＳ）、ゲーム管理サーバ制御部２１０は、キャラクタ表示形態設定データ５１２（図７参照）と、対応するフレンドユーザの個別プレイデータ５４０を参照して、ループＣの処理対象のフレンドＮＰＣ１２の表示形態を、対応するフレンドユーザのゲームのゲーム進行状況に応じた形態に変更する（ステップＳ１４６）

そして、出現確率５７８に従った出現可否の判定をする（ステップＳ１４８）。本実施形態では、出現確率５７８を当選確率とした抽選処理を行い、当選すれば出現許可と判定する。出現許可判定されたならば（ステップＳ１５０のＹＥＳ）、ループＣの処理対象のフレンドＮＰＣ１２をループＡの処理対象のゲームに登場させ（ステップＳ１５２）、更に当該フレンドＮＰＣに、対応するフレンドユーザのゲーム進行状況に応じた状況表示体１４とフレンド名表示１６とを付加表示し（ステップＳ１５４）、ループＣを終了する。

なお、そもそもループＣの処理対象のフレンドＮＰＣの出現機会のタイミングでない場合（ステップＳ１４２のＮＯ）、或いは、位置条件を満たさない場合（ステップＳ１４４のＮＯ）、或いは、出現可否の判定で出現不可と判定された場合（ステップＳ１５０のＮＯ）には、ステップＳ１５２〜Ｓ１５４はスキップされ、ループＣの処理対象のフレンドＮＰＣは出現しない。

ゲーム管理サーバ制御部２１０は、ループＡの処理対象のゲームをプレイしているユーザに係る全てのフレンドＮＰＣについてループＣを実行したならば、次にゲーム進行制御処理を実行する（ステップＳ１５８）。

図１３は、本実施形態におけるゲーム進行制御処理の流れを説明するためのフローチャートである。同処理において、ゲーム管理サーバ制御部２１０は先ず、直近の操作指示入力に応じて、ループＡの処理対象のゲームにおけるプレーヤキャラクタ４の動作を制御する（ステップＳ１７０）。

次に、そのプレーヤキャラクタ４が敵ボスＮＰＣ６が出現する所定発生域に進入している場合には（ステップＳ１７２のＹＥＳ）、敵ボスＮＰＣ６を出現させる（ステップＳ１７４）。

次に、ゲーム管理サーバ制御部２１０は、出現している全ＮＰＣの動作を自動制御し（ステップＳ１７６）、プレーヤキャラクタ４の行動とＮＰＣの行動とに基づいて、攻撃ヒット判定とダメージ判定処理をする（ステップＳ１７８）。ダメージ判定処理では、ダメージを受けるキャラクタと、ダメージ量を算出する。

ここでもし敵ボスＮＰＣ６にダメージが発生した場合（ステップＳ１８０のＹＥＳ）、ゲーム管理サーバ制御部２１０は、共通プレイデータ６００の敵ボスＮＰＣ６のダメージ功績データ６１０（図９参照）に、ループＡの処理対象のゲームのプレーヤのユーザアカウントを功績者ユーザアカウント６１６とする新しい履歴を追加登録する（ステップＳ１８２）。そして、ダメージ量だけ敵ボスＮＰＣ６のライフポイントを減らす（ステップＳ１８４）。

その結果、敵ボスＮＰＣ６のライフポイントが「０」に達した場合には（ステップＳ１８６のＹＥＳ）、ゲーム管理サーバ制御部２１０は敵ボスＮＰＣ６が撃破される演出をユーザ端末１５００にて表示させ（ステップＳ１８８）、ダメージ功績データ６１０に残っているループＡの処理対象のゲームのプレーヤの功績に応じた特典を付与する（ステップＳ１９）。

もし、ダメージ量だけ敵ボスＮＰＣ６のライフポイントを減らしても「０」に達しなければ（ステップＳ１８６のＮＯ）、ダメージ功績データ６１０から、直近から所定期間分を残して過去の履歴を抹消し（ステップＳ１９２）、敵ボスＮＰＣ６のライフポイントを所定の単位時間経過毎に所定量の自動回復を行う（ステップＳ１９４）。

次に、ステップＳ１７８のダメージ判定処理の結果、プレーヤキャラクタ４にダメージが発生した場合には（ステップＳ２００のＹＥＳ）、ゲーム管理サーバ制御部２１０は、ループＡの処理対象のゲームのプレーヤの個別プレイデータ５４０のライフポイント５６０をダメージ量分だけ減らす（ステップＳ２０２）。同様に、敵戦闘員ＮＰＣ８などのＮＰＣにダメージが発生した場合には（ステップＳ２０４のＹＥＳ）、ゲーム管理サーバ制御部２１０は個別プレイデータ５４０の敵戦闘員ＮＰＣステータスデータ５８０等に格納されているライフポイントを減らす（ステップＳ２０６）。そして、ライフポイントが「０」に達したＮＰＣの消滅処理を行って（ステップＳ２０８）、ゲーム進行制御処理を終了する。

図１１のフローチャートに戻って、次いで、ゲーム管理サーバ制御部２１０は、ゲーム終了条件を満たすかを判定する（ステップＳ２３０）。本実施形態では、ゲーム終了の操作入力が有った場合や、ユーザ端末１５００との通信が所定時間以上途絶した場合、ゲームのストーリの最後まで到達した場合、プレーヤキャラクタ４のライフポイントが「０」に達した場合、などにゲーム終了条件を満たすと判定する。

そして、ゲーム終了条件を満たしたならば（ステップＳ２３０のＹＥＳ）、当該ユーザ端末１５００をゲームプレイ中端末リスト５１６から登録解除して（ステップＳ２３２）、ループＡを終了する（ステップＳ２３４）。

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

以上、本実施形態によれば、ゲームプレイしているユーザ（プレーヤ）のフレンドユーザが同時刻にゲームプレイしている場合、当該フレンドユーザのプレーヤキャラクタをベースとしたフレンドＮＰＣをゲーム内に登場させることができる。ゲームプレイしているユーザは、このフレンドＮＰＣを見つけることで、そのゲームが本来非同期のゲームであっても、フレンドユーザの存在を感じられるようになる。

〔第２実施形態〕
次に、本発明を適用した第２実施形態について説明する。本実施形態は、基本的には第１実施形態と同様に実現できるが、パーティを編成してプレイするゲームで有る点と、フレンドＮＰＣの出現確率が、パーティを編成するメンバーの選択肢の中へ含まれる確率（出現率）として利用される点が異なる。尚、以降では、第１実施形態との差異について主に述べることとし、第１実施形態と同様の構成要素について同じ符合を付与して詳細な説明は省略することとする。

図１５は、本実施形態におけるサーバシステム１１００の機能構成例を示す機能ブロック図である。本実施形態の機能構成は、基本的には第１実施形態と同様であるが、フレンドＮＰＣ出現制御部２２４に代る機能ブロックとして、ゲーム管理サーバ制御部２１０は、出現キャラクタ選定制御部２１１を有する。

出現キャラクタ選定制御部２１１は、ゲームを開始しようとする一のユーザ（プレーヤ）以外のユーザ（プレーヤ）のキャラクタの中から、パーティメンバーのＮＰＣとして一のプレーヤのゲームに出現させるキャラクタを選定する制御をする。
そして、本実施形態では、候補キャラクタ選択制御部２１２と、選択確定部２１３と、を含み、第１実施形態の出現確率設定部２２８と、キャラクタ表示形態変更部２３０と、付加表示制御部２３２とを有する。

候補キャラクタ選択制御部２１２は、ゲームを開始しようとする一のユーザ（プレーヤ）以外のユーザ（プレーヤ）のキャラクタの中から、パーティメンバーのＮＰＣとして一のプレーヤのゲームに出現させるキャラクタの選定候補とする候補キャラクタを選択し、一のユーザ（プレーヤ）のユーザ端末１５００に選択可能に表示させる制御をする。当該ユーザ端末１５００から候補キャラクタの選択操作の信号が送信されることになるので、選択確定部２１３は、当該選択操作に応じて出現させるキャラクタを選択確定する。

図１６は、本実施形態における個別プレイデータ５４０のデータ構成例を示す図である。本実施形態のゲームはパーティを編成するゲームなので、本実施形態における個別プレイデータ５４０は、第１実施形態のフレンドＮＰＣステータスデータ５４０（図８参照）に代えて、パーティメンバーＮＰＣステータスデータ５８４を含む。当該ステータスデータには、パーティメンバーとして選択されたＮＰＣの状態と表示制御に必要な情報が格納される。

図１７は、本実施形態におけるサーバシステム１１００のフレンドＮＰＣの出現に係る処理の流れを説明するためのフローチャートである。
ゲーム管理サーバ制御部２１０は、ゲーム開始をリクエストしてきたユーザ端末１５００について、ゲーム開始の準備処理を実行する（ステップＳ１０）。

図１８は、本実施形態におけるゲーム開始準備処理の流れを説明するためのフローチャートである。同処理において、ゲーム管理サーバ制御部２１０は、先ず所定数の登録ユーザの個別プレイデータ５４０に含まれているプレーヤキャラクタ設定データ５４９を参照して、パーティ編成の候補キャラクタによる候補リストを編成する（ステップＳ３００）。

次いで、第１実施形態と同様にしてフレンドユーザプレイ判定処理を実行して、ゲーム開始準備の対象とされるユーザ（ゲーム開始準備ユーザ：プレーヤ）のフレンドユーザ毎に、現在ゲームをプレイ中か否かを判定する（ステップＳ３０２）。

そして、ゲーム管理サーバ制御部２１０は、ゲーム開始準備ユーザのフレンドユーザ中に、現在プレイ中のフレンドユーザがいる場合には（ステップＳ３０４のＹＥＳ）、出現確率設定処理を実行する（ステップＳ３０６）。

図１９は、本実施形態における出現確率設定処理の流れを説明するためのフローチャートである。同処理において、ゲーム管理サーバ制御部２１０は、フレンドユーザ毎にループＥを実行する（ステップＳ３１０〜Ｓ３３２）。
ループＥでは、処理対象フレンドユーザの出現確率算出ポイントをサーバ記憶部５００ｓに生成し、「０」に初期化する（ステップＳ３１２）。そして、処理対象フレンドユーザがプレイ中であれば（ステップＳ３１４のＹＥＳ）、ゲーム管理サーバ制御部２１０は、処理対象フレンドユーザとゲーム開始準備ユーザとの好感度５２５ｂ（図７参照）に応じたポイントを出現確率算出ポイントに加算する（ステップＳ３１６）。具体的には、好感度５２５ｂが高いほど加算するポイントを大きくすると良い。

次に、ゲーム管理サーバ制御部２１０は、処理対象フレンドユーザの直近のアクセス日時５５２（図１６参照）からの経過時間を算出し、当該経過時間が短い程大きいポイントを出現確率算出ポイントに加算する（ステップＳ３１８）。

次いで、ゲーム管理サーバ制御部２１０は、処理対象フレンドユーザの端末位置座標５５６と、ゲーム開始準備ユーザの端末位置座標５５６との位置差が小さいほど大きいポイントを出現確率算出ポイントに加算する（ステップＳ３２０）。

次いで、ゲーム管理サーバ制御部２１０は、処理対象フレンドユーザのゲーム進行状況に応じたポイントを出現確率算出ポイントに加算する（ステップＳ３２２）。例えば、敵ボスＮＰＣ６と交戦中ならば１０ポイント、敵戦闘員ＮＰＣ８の出現数が所定基準を超えたら５ポイント、ライフポイント５６０が５０％を下回っていたら５ポイントなど、適宜設定可能である。或いは、能力パラメータ値テーブル５６４の値が高い程高いポイントを加算するとしても良い。

次に、ゲーム管理サーバ制御部２１０は、ゲーム開始準備ユーザのゲーム進行状況に応じたポイントを出現確率算出ポイントに加算する（ステップＳ３２４）。

次いで、これまで様々に加算された処理対象フレンドユーザの出現確率算出ポイントの値が大きい程、高確率となるように出現確率を決定し（ステップＳ３３０）、ループＥを終了する（ステップＳ３３２）。
尚、処理対象フレンドユーザが現在プレイ中でなければ（ステップＳ３１４のＮＯ）、出現確率算出ポイントは「０」のままとなり、ステップＳ３３０では極めて低い出現確率が設定されることになる。

そして、ゲーム開始準備ユーザの全てのフレンドユーザについてループＥを実行したならば、出現確率設定処理を終了する。

図１８のフローチャートに戻って、ゲーム管理サーバ制御部２１０は次に、フレンドユーザ毎に設定された出現確率を適用して個別に抽選処理を実行して、当該フレンドユーザを出現させるか否かを判定し（ステップＳ３５０）、ステップＳ３００で編成された候補リストのキャラクタを、出現判定されたフレンドユーザのプレーヤキャラクタに置き換える（ステップＳ３５６）。

次に、ゲーム管理サーバ制御部２１０は、候補リストをゲーム開始準備ユーザのユーザ端末１５００で選択可能に表示させる制御をする（ステップＳ３５８）。尚、候補リストには、キャラクタのグラフィックスとともに、当該キャラクタをプレーヤキャラクタとするユーザアカウントを併せて表示させる。

ゲーム開始準備ユーザは、この候補リスト中にフレンドユーザを見つけることができれば、当該フレンドユーザが現在プレイ中であることを知ることができる。そして、そのフレンドユーザのキャラクタをパーティメンバーとして選択すれば、非同期のゲーム間であるが、フレンドユーザとともにプレイしているような連帯感を感じることができる。

さて、ユーザ端末１５００は、ゲーム開始準備ユーザによるパーティを編成するキャラクタの選択操作を検出すると、選択操作信号をサーバシステム１１００へ送信する。
そこで、ゲーム管理サーバ制御部２１０は、選択操作信号を受信したならば（ステップＳ３５８のＹＥＳ）、選択されたキャラクタをパーティメンバーＮＰＣステータスデータ５８４に設定する（ステップＳ３６０）。この際、ゲーム管理サーバ制御部２１０は、新たに設定するパーティメンバーＮＰＣの表示形態を、第１実施形態と同様にキャラクタ表示形態変更部２３０を機能させて決定し、付加表示制御部２３２を機能させて状況表示体１４やフレンド名表示１６といった付加表示体（図４参照）を選択・付加することとする。
そして、ゲーム開始準備ユーザのユーザ端末１５００からパーティメンバーの決定操作を受信したならば（ステップＳ３６２のＹＥＳ）、ゲーム開始準備処理を終了する。

図１７のフローチャートに戻って、ループＡではゲーム開始準備処理で選択されたパーティメンバーＮＰＣが、ループＡ処理対象ゲームをプレイするユーザのプレーヤキャラクタともにパーティを編成してゲーム世界に登場することになる。

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

例えば、上記実施形態ではオンラインＲＰＧを例示したが、ゲームジャンルはその他のジャンルでも構わない。

また、ステップＳ１０４（図１０参照）において、ループＡの処理対象のゲームのゲーム進行状況に応じて最終出現確率を決定したが、ループＢの処理対象のフレンドユーザのゲーム進行状況に応じて決定するとしても良い。
また、ステップＳ１０６などのステップを適宜省略することができる。

また、上記実施形態のフレンドユーザプレイ判定処理を、図１４に示すフレンドユーザプレイ判定処理Ｂに置き換えることができる。同処理では、ゲーム管理サーバ制御部２１０は、先ずループＢの処理対象のフレンドユーザのプレイ日時履歴５５０の過去の履歴を統計処理して、過去の傾向から現在時刻においてプレイしている確率（可能性）を算出する（ステップＳ７０）。そして、算出した確率が所定のプレイ判定基準確率に達している場合には（ステップＳ７２のＹＥＳ）、ループＢの処理対象のフレンドユーザはプレイ中であると判定（推定）し（ステップＳ７４）、フレンドユーザプレイ判定処理Ｂを終了する。もし、達していなければ（ステップＳ７２のＮＯ）、プレイしていないと判定して（ステップＳ７６）、フレンドユーザプレイ判定処理Ｂを終了する。

２（２ａ）…ユーザ
２（２ｂ）…フレンドユーザ
４…プレーヤキャラクタ
６…敵ボスＮＰＣ
１２…フレンドＮＰＣ
１４…付加表示体
１６…フレンド名表示
２００ｓ…サーバ処理部
２０２…ユーザ登録情報管理部
２０３…フレンドリスト管理部
２１０…ゲーム管理サーバ制御部
２１１…出現キャラクタ選定制御部
２１２…候補キャラクタ選択制御部
２１３…選択確定部
２１４…プレイデータ管理部
２１８…プレイ日時管理部
２２０…同時プレイ判定部
２２２…アクセス日時基準判定部
２２４…フレンドＮＰＣ出現制御部
２２６…出現頻度設定部
２２８…出現確率設定部
２２９…出現条件判定部
２３０…キャラクタ表示形態変更部
２３２…付加表示制御部
２３４…ゲーム進行制御部
２３６…端末位置情報取得制御部
５００ｓ…サーバ記憶部
５０３…サーバシステムプログラム
５０５…ゲーム管理サーバプログラム
５０７…ゲームクライアントプログラム
５０８…ゲーム空間初期設定データ
５１０…キャラクタ初期設定データ
５１２…キャラクタ表示形態設定データ
５１４…状況表示体設定データ
５１６…ゲームプレイ中端末リスト
５２０…ユーザ登録データ
５２２…ユーザアカウント
５２５…フレンドリスト
５２５ｂ…友好度
５４０…個別プレイデータ
５４９…プレーヤキャラクタ設定データ
５５０…プレイ日時履歴
５５２…アクセス日時
５５４…操作入力指示信号
５５６…端末位置座標
５６０…ライフポイント
５７０…フレンドＮＰＣステータスデータ
５７２…フレンドユーザアカウント
５７４…フレンドＮＰＣ設定データ
５７６…出現頻度
５７８…出現確率
５８０…敵戦闘員ＮＰＣステータスデータ
５８２…敵ボスＮＰＣステータスデータ
５８４…パーティメンバーＮＰＣステータスデータ
６００…共通プレイデータ
６０２…共通キャラクタステータスデータ
６０４…ボスキャラＩＤ
６０８…ライフポイント
６１０…ダメージ功績データ
６１２…ダメージ日時
６１４…ダメージ量
６１６…功績者ユーザアカウント
１１００…サーバシステム
１１０４…ブレードサーバ
１５００…ユーザ端末

Claims (13)

1. 各プレーヤのプレーヤ端末と所定の通信を行って各プレーヤに係るゲーム進行を非同期で制御するとともに、当該非同期のゲームにおいてプレーヤ同士の共同プレイが可能なゲームイベントの発生及び進行を制御するサーバシステムであって、
   各プレーヤのプレイ日時を管理するプレイ日時管理手段と、
   各プレーヤそれぞれについて、当該プレーヤに関係する関係プレーヤを記憶する関係プレーヤ記憶手段と、
   前記プレイ日時管理手段により管理されているプレイ日時を用いて、一のプレーヤのプレイ中に、当該一のプレーヤの関係プレーヤがプレイしているか否かを判定する同時プレイ判定手段と、
   前記同時プレイ判定手段により肯定判定された場合に、その旨を示すための所与のキャラクタを、前記一のプレーヤのゲームに出現させる制御を行うキャラクタ出現制御手段と、
   を備えたサーバシステム。
2. 前記非同期のゲームは、プレーヤ端末から受信した操作入力指示信号に基づきゲーム進行を制御して、対応するゲーム画像のデータを当該プレーヤ端末に送信する処理を繰り返し実行することで進行するゲームであり、
   前記プレイ日時管理手段は、プレーヤ端末から前記操作入力指示信号を受信したアクセス日時を少なくとも前記プレイ日時に含めて管理し、
   前記同時プレイ判定手段は、前記アクセス日時を用いて、前記一のプレーヤのプレイ中に、当該一のプレーヤの関係プレーヤがプレイしているか否かを判定するアクセス日時基準判定手段を有する、
   請求項１に記載のサーバシステム。
3. 前記アクセス日時基準判定手段は、前記一のプレーヤの関係プレーヤの最新の前記アクセス日時からの経過時間が、継続してプレイしていると判定する条件である所与のプレイ継続判定時間条件を満たすか否かを判定する手段を有する、
   請求項２に記載のサーバシステム。
4. 前記キャラクタ出現制御手段は、
   前記同時プレイ判定手段により肯定判定された場合に、前記一のプレーヤのプレイ中に前記所与のキャラクタを繰り返し出現させる手段と、
   前記一のプレーヤの関係プレーヤの最新の前記アクセス日時からの経過時間が経過するに従って、前記所与のキャラクタの出現頻度を低下させる手段と、
   を有する、
   請求項２又は３に記載のサーバシステム。
5. 前記アクセス日時基準判定手段は、前記一のプレーヤの関係プレーヤの過去の前記アクセス日時を用いて、前記一のプレーヤのプレイ中に、当該関係プレーヤがプレイする可能性を判定する手段を有する、
   請求項２〜４の何れか一項に記載のサーバシステム。
6. 前記キャラクタ出現制御手段は、前記一のプレーヤの関係プレーヤのゲーム状況に応じて、前記所与のキャラクタの表示形態を変更する表示形態変更手段を有する、
   請求項１〜５の何れか一項に記載のサーバシステム。
7. 前記キャラクタ出現制御手段は、
   前記所与のキャラクタを出現させるか否かを所与の出現確率で決定する手段と、
   前記出現確率を変更する出現確率変更手段と、
   を有する、
   請求項１〜６の何れか一項に記載のサーバシステム。
8. 前記出現確率変更手段は、前記一のプレーヤのゲーム状況に応じて前記出現確率を変更する手段を有する、
   請求項７に記載のサーバシステム。
9. 各プレーヤそれぞれについて、当該プレーヤと当該プレーヤの関係プレーヤとの友好度を記憶する友好度記憶手段を更に備え、
   前記出現確率変更手段は、前記一のプレーヤと、前記一のプレーヤの関係プレーヤとの友好度に応じて前記出現確率を変更する手段を有する、
   請求項７又は８に記載のサーバシステム。
10. 前記出現確率変更手段は、前記同時プレイ判定手段により否定判定された場合には、稀に前記所与のキャラクタを出現させる確率である所与の低出現確率に前記出現確率を設定する手段を有する、
    請求項７〜９の何れか一項に記載のサーバシステム。
11. 前記プレーヤ端末は現在位置取得機能を有しており、
    各プレーヤの前記プレーヤ端末からプレーヤの現在位置を取得するプレーヤ位置取得手段と、
    前記プレーヤ位置取得手段により取得されたプレーヤ位置を用いて、前記一のプレーヤの位置と、当該一のプレーヤの関係プレーヤの位置とが所定の位置条件を満たすか否かを判定する位置条件判定手段と、
    を更に備え、
    前記キャラクタ出現制御手段は、前記同時プレイ判定手段により肯定判定され、且つ、前記位置条件判定手段により肯定判定された場合に、前記所与のキャラクタを出現させる制御を行う、
    請求項１〜９の何れか一項に記載のサーバシステム。
12. 前記一のプレーヤ以外のプレーヤのキャラクタの中から、前記一のプレーヤのゲームに出現させるキャラクタを選定する出現キャラクタ選定手段を更に備え、
    前記キャラクタ出現制御手段は、前記出現キャラクタ選定手段により選定されたキャラクタを前記一のプレーヤのゲームに出現させる制御を行う手段を有する、
    請求項１〜３の何れか一項に記載のサーバシステム。
13. 前記出現キャラクタ選定手段は、
    前記一のプレーヤ以外のプレーヤのキャラクタの中から、選定候補とする候補キャラクタを選択する候補キャラクタ選択手段と、
    前記候補キャラクタの中から、前記一のプレーヤのゲームに出現させるキャラクタを選定する手段と、
    を有し、
    前記候補キャラクタ選択手段は、前記プレイ日時管理手段により管理されているプレイ日時を用いて、一のプレーヤのプレイ中にプレイしているプレーヤのキャラクタを前記候補キャラクタとして選択する確率を上げる手段を有する、
    請求項１２に記載のサーバシステム。

Images