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

Description

本発明は、プレーヤ端末と通信接続されるサーバシステムに関する。

複数のプレーヤが同時に通信回線に接続して相互にデータ通信可能なゲーム装置を使ってゲームプレイをする、いわゆるオンラインマルチプレイゲームでは、複数のプレーヤが共同してゲームを進行させるのが一般的である。そして、多くのオンラインマルチプレイゲームでは、プレーヤが一緒にプレイして気の合う他プレーヤを任意に「フレンドリスト」に登録して、次回以降のマッチングでまた一緒にプレイできるような工夫がなされている。

そして、フレンドリストを利用してゲームの興趣を高めるさまざまな工夫が考案されてきた。例えば、フレンドリストに登録されているプレーヤ間でゲーム内で取得したアイテムの譲渡を可能とする技術が知られている（例えば、特許文献１参照）。

特開２０１１−１１０１３９公報

しかしながら、フレンドリストへの登録にプレーヤ同士の相互承認が必要な場合、どちらか一方のプレーヤの承認入力がなされないと登録が成立しないため、完了までにどの位の時間がかかるか分らない。

本発明は、フレンドリストといったプレーヤの登録リストへの登録に当たり相手の承認を不要して他プレーヤのことを自分のリストに気楽に登録可能とすること、さらには、こういった登録リストを用いてプレーヤ同士の繋がり関係を判定し、その繋がり関係を利用した新しいゲームを実現すること、を目的とする。

上述した課題を解決するための第１の発明は、プレーヤ端末と通信接続されるサーバシステムであって、自プレーヤがお気に入りとして登録した他プレーヤの第１種リスト（例えば、図１０の第１種アカウントリスト５２５）と、自プレーヤのことをお気に入りとして登録している他プレーヤの第２種リスト（例えば、図１０第２種アカウントリスト５２６）とを、各プレーヤについて管理するリスト管理手段（例えば、図９のサーバ処理部２００ｓ、ゲーム管理部２１０、アカウントリスト管理部２１１、図１６のステップＳ１６，Ｓ７２，Ｓ１１４）と、
第１プレーヤのゲームに第２プレーヤに係るキャラクタを登場させて当該ゲームを進行制御するゲーム進行制御手段（例えば、図９のサーバ処理部２００ｓ、ゲーム管理部２１０、ゲーム進行制御部２２０、図１７のステップＳ１５６，Ｓ２１０〜Ｓ２１６、Ｓ２３４）と、を備え、
前記ゲーム進行制御手段は、ゲーム進行に利用する所定のパラメータの値を、前記第２プレーヤが、前記第１プレーヤの前記第１種リスト及び前記第２種リストそれぞれに登録されているか否かの組み合わせに応じた値に設定するパラメータ設定手段（例えば、図９のゲーム進行制御部２２０、パラメータ設定部２２２、図２１のステップＳ１８６、ステップＳ１９４）を有し、当該変更されたパラメータの値を用いて前記ゲームを進行制御するサーバシステムである。

第２の発明は、前記パラメータ設定手段が、前記キャラクタに係るパラメータの値を、前記組み合わせに応じた値に設定する、第１の発明のサーバシステムである。

また、第３の発明は、プレーヤ端末と通信接続されるサーバシステムであって、自プレーヤがお気に入りとして登録した他プレーヤの第１種リストと、自プレーヤのことをお気に入りとして登録している他プレーヤの第２種リストとを、各プレーヤについて管理するリスト管理手段と、第１プレーヤのゲームに第２プレーヤに係るキャラクタを登場させて当該ゲームを進行制御するゲーム進行制御手段と、を備え、前記ゲーム進行制御手段は、ゲーム進行の報酬に係るパラメータの値を、前記第２プレーヤが、前記第１プレーヤの前記第１種リスト及び前記第２種リストそれぞれに登録されているか否かの組み合わせに応じた値に設定する（例えば、図２２のステップＳ２９６）パラメータ設定手段を有する、サーバシステムである。

第１〜第３の発明によれば、プレーヤ毎に自身がお気に入り登録した第１種リストと、自身をお気に入り登録してくれている他プレーヤの第２種リストとを管理できる。そして、第１のプレーヤのゲームに、第２のプレーヤ（他プレーヤ）が使用するキャラクタを登場させることができる。このとき、ゲーム進行に関するパラメータを、第２プレーヤが第１プレーヤの第１種リスト及び第２種リストに登録されているか否かの組み合わせに応じた値に設定することができる。つまり、プレーヤ間の互いのリストへの登録状況によってプレーヤ同士の繋がり関係が明らかとなり、その繋がり関係のあり方（例えば、一方的に相手を登録、双方が互いに登録など）に応じてゲーム進行に影響を与えることができる。

なお、設定される「ゲーム進行に関するパラメータ」は、ゲーム内容に応じて適宜設定可能である。例えば、第２の発明のように、第２プレーヤが使用するキャラクタを登場させる際に適用される当該キャラクタの能力としてもよい。また、ＮＰＣ（non player character）の配置位置や配置数、配置条件、配置時に適用される能力パラメータ値、ゲームステージの分岐、ＢＧＭの種類、背景画像、内部抽選の当選確率、などを適宜選択・設定することができる。さらには、第３の発明のようにゲームでの報酬、より具体的には、例えば敵を倒したときに得られる経験値、倒した敵がドロップするアイテムの種類や頻度などとしてもよい。

登録関係に基づく設定のあり方に着目すれば、第４の発明として、前記リスト管理手段は、自プレーヤと他プレーヤとが相互にお気に入りとして登録している第３種リストを各プレーヤについて更に管理し、前記パラメータ設定手段が、前記第２プレーヤが前記第１プレーヤの前記第３種リストに登録されている場合に、前記第１プレーヤの前記第１種リスト或いは前記第２種リストに登録されている場合に比べてゲーム上有利になる値に前記パラメータを設定する（例えば、図２１のステップＳ１９４）、第１〜第３の何れかの発明のサーバシステムを構成可能である。

さらには、第５の発明として、前記パラメータ設定手段が、前記第２プレーヤが前記第１プレーヤの前記第１種リストに登録されているが前記第２種リストに登録されていない場合に、当該第１種リスト及び当該第２種リストの双方に登録されていない場合よりもゲーム上有利となる値であり、且つ、前記第３種リストに登録されている場合よりも不利となる値に前記パラメータを設定する第４の発明のサーバシステムを構成することができる。

また、ゲーム進行そのものに着目すれば、第６の発明として、プレーヤ端末と通信接続されるサーバシステムであって、自プレーヤがお気に入りとして登録した他プレーヤの第１種リストと、自プレーヤのことをお気に入りとして登録している他プレーヤの第２種リストとを各プレーヤについて管理するリスト管理手段と、第１プレーヤのゲームに第２プレーヤに係るキャラクタを登場させて当該ゲームを進行制御するゲーム進行制御手段と、を備え、前記ゲーム進行制御手段は、前記第２プレーヤが、前記第１プレーヤの前記第１種リスト及び前記第２種リストそれぞれに登録されているか否かの組み合わせに応じてゲーム進行を変更制御する（例えば、図２２のステップＳ２６６，Ｓ２９６）、サーバシステムを構成することができる。

また、リストの登録解除に着目すれば、第７の発明として、前記リスト管理手段は、一のプレーヤの前記第１種リストに登録されたプレーヤ（登録解除要請プレーヤ）からの登録解除要請に応じて、当該登録を解除する登録解除手段（例えば、図９の登録解除制御部２１２、図１６のステップＳ１１４）を有する、第１〜第６の何れかの発明のサーバシステムを構成することができる。

さらには、第８の発明として、前記登録解除手段は、前記一のプレーヤの前記第２種リストに前記登録解除要請プレーヤが登録されていない場合には、前記登録解除要請プレーヤからの登録解除要請に応じた解除を実行せず、登録されている場合に、前記登録解除要請プレーヤからの登録解除要請に応じた解除を実行する、第７の発明のサーバシステムを構成することができる。

また、プレーヤの個人情報の扱いに配慮するならば、第９の発明として、一のプレーヤの個人情報を前記プレーヤ端末で公開するためのデータを提供する手段であって、当該個人情報には、当該一のプレーヤの前記第１種リストに登録されているプレーヤの識別情報を含めず、前記第２種リストに登録されているプレーヤの識別情報を含める個人情報提供手段（例えば、図９の個人情報提供部２２４、図１５の公開用個人情報５８２、図１６のステップＳ８）、を更に備えた第１〜第８の何れかの発明のサーバシステムを構成することができる。

ゲームシステムの構成の一例を示す図。 プレーヤ端末の構成例を示す図。 プレーヤ間のお気に入り関係について説明するための概念図。 メッセージ掲示画面の例を示す図。 関係一覧画面の例を示す図。 同行メンバーを選択する過程におけるプレーヤ間のお気に入り関係の利用について説明する概念図。 同行メンバー選択画面の例を示す図。 プレーヤ間のお気に入り関係の第２利用形態を説明するための概念図。 サーバシステムの機能構成例を示す機能ブロック図。 アカウントデータのデータ構成の一例を示す図。 プレイデータのデータ構成の一例を示す図。 同行メンバー候補リストのデータ構成の一例を示す図。 メッセージ履歴マスターデータのデータ構成の一例を示す図。 プレーヤ端末の機能構成例を示す機能ブロック図。 表示用メッセージデータのデータ構成の一例を示す図。 サーバシステム１１００及びプレーヤ端末１５００における主たる処理の流れを説明するためのフローチャート。 図１６よりつづくフローチャート。 お気に入り関係設定処理の流れを説明するためのフローチャート。 お気に入り解除処理の流れを説明するためのフローチャート。 サポータ解除処理の流れを説明するためのフローチャート。 同行メンバー候補選択処理の流れを説明するためのフローチャート。 ゲーム処理の流れを説明するためのフローチャート。 プレーヤ端末の機能構成の変形例を示す機能ブロック図。 サーバシステムの機能構成の変形例を示す機能ブロック図。 サーバシステムの機能構成の変形例を示す機能ブロック図。 同行メンバー候補選択処理の変形例の流れを説明するためのフローチャート。

〔第１実施形態〕
本発明を適用した第１実施形態として、アクションＲＰＧ（role-playing game）タイプのオンラインゲームの例について説明する。なお、ゲームのタイプやジャンルは適宜変更可能である。

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

サーバシステム１１００は、単数又は複数のサーバシステムや記憶装置等を含んで構成され、ＳＮＳ（ソーシャルネットワーキングサービス）等の会員登録制のコミュニティ型ウェブサイトを運営するための各種サービスを実現する。具体的には、会員登録を済ませたプレーヤにはそれぞれ固有のアカウント（ハンドルネームと読み替えることもできる）を発給し、各登録プレーヤに係る情報はアカウントデータ５２０で一元的に管理する。そして、アカウントデータ５２０に基づいて当該ウェブサイトにおける様々なサービスを提供する。本実施形態のオンラインゲームも、登録プレーヤへのサービスの一環として提供・実現される。各プレーヤ２（２ａ，２ｂ，２ｃ，…）は、それぞれのプレーヤ端末１５００（１５００ａ，１５００ｂ，１５００ｃ，…）を使用し、サーバシステム１１００にアクセスし、それぞれの主人公キャラクタ４（４ａ，４ｂ，４ｃ，…）を使用してオンラインゲームを楽しむ。なお、主人公キャラクタ４（４ａ，４ｂ，４ｃ，…）は、予め用意されている種類のキャラクタの中からプレーヤが選択して決定する。

より具体的には、サーバシステム１１００は、本体装置１１０１と、キーボード１１０６と、タッチパネル１１０８と、ストレージ１１４０とを備える。本体装置１１０１には、制御基板１１５０が搭載されている。制御基板１１５０には、ＣＰＵ（Central Processing Unit）１１５１やＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）などの各種マイクロプロセッサ、ＡＳＩＣ（Application Specific Integrated Circuit）、ＶＲＡＭやＲＡＭ，ＲＯＭ等の各種ＩＣメモリ１１５２、通信装置１１５３が搭載されている。

サーバシステム１１００は、本実施形態のゲームに関する機能としては、アカウント登録やプレーヤキャラクタの初期設定、及びログイン／ログアウトに関係する処理を担うアカウント管理機能と、ログインしてゲームに参加中のプレーヤ端末１５００へゲームを実行するのに必要なデータを随時管理・配信するゲーム管理機能と、を有する。
図示の例では、サーバシステム１１００は単体として記しているが、サーバシステム１１００には複数のブレードサーバを搭載し、アカウント管理機能及びゲーム管理機能を分担して担い、相互に内部バスを介してデータ通信可能に接続された構成であっても良い。或いは、離れた場所に設置された独立した複数のサーバを通信回線Ｎを介してデータ通信させることで、全体としてサーバシステム１１００として機能させる構成であっても良い。

図２は、プレーヤ端末１５００の構成例を示す正面外観図である。プレーヤ端末１５００は、プレーヤが使用するコンピュータであり電子装置（電子機器）である。例えば、スマートフォンや、携帯型ゲーム装置、据置型家庭用ゲーム装置、据置型家庭用ゲーム装置のゲームコントローラ、業務用ゲーム装置、パソコン、タブレット型コンピュータ、などにより実現される。そして、通信回線Ｎに接続してサーバシステム１１００にアクセスすることができる。

本実施形態におけるプレーヤ端末１５００は、方向入力キー１５０２と、ボタンスイッチ１５０４と、画像表示デバイス兼接触位置入力デバイスとして機能するタッチパネル１５０６と、スピーカ１５１０と、内蔵バッテリー１５０９と、マイク１５１２と、制御基板１５５０と、コンピュータ読み出し可能な情報記憶媒体であるメモリカード１５４０からデータを読み書きできるメモリカード読取装置１５４２と、を備える。その他、図示されていない電源ボタン、音量調節ボタン等が設けられている。

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

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

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

［お気に入り関係について］
図３は、本実施形態におけるプレーヤ間の繋がりについて説明するための概念図である。本実施形態のオンラインゲームでは、プレーヤ間の繋がりとして、他プレーヤを「お気に入り」に登録することができる。以降、「お気に入り関係」と呼ぶこととする。本実施形態のお気に入り関係は、プレーヤ間相互のお気に入りの登録関係に応じて、関係種別「第１種」「第２種」「第３種」「無し」の４つある。

あるプレーヤが他プレーヤをお気に入りに登録した場合のお気に入り関係を関係種別「第１種」とし、他プレーヤは関係種別「第１種」とする。
逆に、あるプレーヤが他プレーヤからお気に入りに登録された場合のお気に入り関係を関係種別「第２種」とし、他プレーヤは関係種別「第２種」とする。

具体的には、図３（１）に示すように、第１のプレーヤ２（２ａ）と第２のプレーヤ２（２ｂ）がいるとする。前述のように、サーバ１１００にはそれぞれのアカウントデータ５２０（５２０ａ，５２０ｂ）が記憶・管理されている。第１のプレーヤ２（２ａ）が、自分のプレーヤ端末１５００で、第２のプレーヤ２（２ｂ）のアカウントを指定して「お気に入り登録操作」をすると、サーバシステム１１００はこれを受信し、第１のプレーヤ２（２ａ）のアカウントデータ５２０（５２０ａ）の第１種アカウントリスト５２５に、指定されたアカウント「ユーザＢ」を登録する。そして、「お気に入りに登録される側」となった第２のプレーヤ２（２ｂ）のアカウントデータ５２０（５２０ｂ）の第２種アカウントリスト５２６には、お気に入り登録操作した第１のプレーヤ２（２ａ）のアカウント「ユーザＡ」を登録する。「お気に入りに登録する側」の第１のプレーヤ２（２ａ）からすれば、一方的にお気に入りに登録しただけで「お気に入りに登録される側」からの承認がなくともお気に入り関係が成立する。

この関係で言うと、互いのプレーヤのお気に入り関係の組み合わせは、第１のプレーヤ２（２ａ）から見れば第２のプレーヤ２（２ｂ）は関係種別「第１種」にあたり、逆の第２のプレーヤ２（２ｂ）からすれば第１のプレーヤ２（２ａ）は関係種別「第２種」にあたる。
よって、自分の第１種アカウントリスト５２５に登録されている他プレーヤの第１アカウントリスト５２５に、自分が登録されていない場合のアカウントのリストが、第２種アカウントリスト５２６と言える。

当然、一方的な「お気に入り登録」は、第２のプレーヤ２（２ｂ）から第１のプレーヤ２（２ａ）を指定して行うことも可能である。そして、図３（２）に示すように、既に第１のプレーヤ２（２ａ）が第２のプレーヤ２（２ｂ）を「お気に入り登録」している状態で、逆に第２のプレーヤ２（２ｂ）が第１のプレーヤ２（２ａ）を指定してお気に入り登録操作をすると、相互に登録し合う関係種別「第３種」が成立し「第１種」「第２種」から置き換わる。

具体的には、図３（１）の状態から、第２のプレーヤ２（２ｂ）により第１のプレーヤ２（２ａ）を指定してお気に入り登録であるサポート宣言が行われると、サーバシステム１１００は、第２のプレーヤ２（２ｂ）のアカウントデータ５２０（５２０ｂ）の第１種アカウントリスト５２５にアカウント「ユーザＡ」を登録するが、第２種アカウントリスト５２６にも同じ「ユーザＡ」が登録されていれば、関係種別「第３種」の成立条件を満たすと判定して、第１アカウントリスト５２５及び第２種アカウントリスト５２６から当該アカウントを削除して、代わりに第３種アカウントリスト５２７に登録する。つまり、アカウント「ユーザＡ」の登録種別を変更する。

同様のことは、第１のプレーヤ２（２ａ）についても行われる。すなわち、サーバシステム１１００は、第１のプレーヤ２（２ａ）のアカウントデータ５２０（５２０ａ）の第２種アカウントリスト５２６にアカウント「ユーザＢ」を登録するが、第１種アカウントリスト５２５にも同じ「ユーザＢ」が登録されていれば、関係種別「第３種」の成立条件が満たされたと見なされ、第１アカウントリスト５２５及び第２種アカウントリスト５２６から当該アカウントを削除して、第３種アカウントリスト５２７に登録する。

図３（２）の関係で言うと、第１のプレーヤ２（２ａ）から見れば第２のプレーヤ２（２ｂ）も、第２のプレーヤ２（２ｂ）から見た第１のプレーヤ２（２ａ）もともに関係種別「第３種」にあたる。よって、自分の第１種アカウントリスト５２５に登録されている他プレーヤの第１アカウントリスト５２５に、自分も登録されている組み合わせ、双方が互いに登録し合っている組み合わせとなるアカウントのリストが、第３種アカウントリスト５２７と言える。

そして、図３（１）の関係でも図３（２）の関係でもなく、第１のプレーヤ２（２ａ）と第２のプレーヤ２（２ｂ）の双方ともに互いをお気に入り登録していない場合、すなわち、いずれのアカウントリストにも互いのアカウントが登録されていない場合、関係種別「無し」となる。

本実施形態では、プレーヤ同士が知り合う仕組みとして、ゲーム内にメッセージ掲示板が用意されており、例えば図４に示すように、プレーヤ端末１５００でメッセージ掲示画面Ｗ２を表示させることができる。メッセージ掲示画面Ｗ２では、投稿順に個別メッセージ表示部２０が表示される。一つの個別メッセージ表示部２０には、当該メッセージを投稿したプレーヤ（投稿主プレーヤ）が使用する主人公キャラクタ４の容姿を示すキャラクタアイコン５と、投稿主プレーヤのアカウント等が含まれるメッセージテキスト２３とが含まれる。

更に、メッセージ掲示画面Ｗ２を見ているプレーヤ（プレーヤ端末１５００から見れば自機を使用するプレーヤ。以降「自プレーヤ」と呼称する。）から見た投稿主プレーヤの関係を示す各種アイコンが、それぞれの個別メッセージ表示部２０に付属表示される。

具体的には、自プレーヤは自アカウントリストに個別メッセージ表示部２０のメッセージの投稿主プレーヤをお気に入り登録していなければ、「お気に入り登録操作」をするための登録操作アイコン１０が表示される。プレーヤが、登録操作アイコン１０をタッチ操作すると、プレーヤ端末１５００は、対応するメッセージの投稿主プレーヤのアカウントを指定して「登録リクエスト」をサーバシステム１１００へ送信する。

もし、メッセージの投稿主プレーヤを既にお気に入り登録している場合には、つまり当該メッセージの投稿主プレーヤが既に関係種別「第１種」である場合には、第１種関係アイコン１１が表示される。そして、もしメッセージの投稿主プレーヤが自プレーヤをお気に入り登録している場合には第２種関係アイコン１２が表示される。

よって、登録操作アイコン１０のみが付属表示されていれば、当該個別メッセージ表示部２０のメッセージの投稿主プレーヤとプレーヤとの間には、何もお気に入り関係が成立していないことになる。つまり関係種別「なし」であることがわかる。
もし、第１種関係アイコン１１のみが付属表示されていれば、メッセージの投稿主プレーヤは自プレーヤから見て関係種別「第１種」のお気に入り関係にあることになる。
登録操作アイコン１０と第２種関係アイコン１２とが付属表示されていれば、メッセージの投稿主プレーヤは関係種別「第２種」のお気に入り関係にあることになる。
そして、第１種関係アイコン１１と第２種関係アイコン１２との両方が付属表示されていれば、メッセージの投稿主プレーヤは関係種別「第３種」のお気に入り関係にあることになる。

なお、メッセージテキスト２３には、当該メッセージの投稿主プレーヤに関する個人情報（例えば、投稿主プレーヤが別途登録したプロフィールと、投稿主プレーヤの第２種アカウントリスト５２６に登録されているアカウントを示すサポータ一覧など）を表示させるとしてもよい。あるいは、ポップアップ表示２５にて追加表示するとしてよい。

自プレーヤは、自身が誰をお気に入り登録しているのか、また誰が自身をお気に入り登録してくれているかを、例えば図５に示すような関係一覧画面Ｗ４で知ることができる。関係一覧画面Ｗ４は、プレーヤ端末１５００で所定操作をすることで表示される。

関係一覧画面Ｗ４には、第１種関係表示部３０と、第２種関係表示部３２とが含まれる。前者には、自プレーヤから見て関係種別「第１種」に該当する他プレーヤが使用する主人公キャラクタ４のキャラクタアイコン５が表示される。後者には、関係種別「第２種」に該当する他プレーヤが使用する主人公キャラクタ４のキャラクタアイコン５が表示される。

そして、関係一覧画面Ｗ４には、関係種別「第１種」の登録を解除するお気に入り解除操作アイコン３５と、関係種別「第２種」の登録を解除するサポータ解除操作アイコン３６とが表示される。

第１種関係表示部３０に表示されているキャラクタアイコン５を選択操作した状態で、お気に入り解除操作アイコン３５をタッチ操作すると、プレーヤ端末１５００はサーバシステム１１００へ選択操作されたキャラクタアイコン５に対応する情報（例えば、アカウント）とともに「お気に入り登録解除リクエスト」を送信する。サーバシステム１１００は、これを受信すると、指定されたアカウントに対するプレーヤのお気に入り登録を解除する。指定されたアカウントが自プレーヤの第１種アカウントリスト５２５から削除されるのは勿論、お気に入り登録していた相手の第２種アカウントリスト５２６や第３種アカウントリスト５２７から自プレーヤのアカウントが登録抹消される。

また、第２種関係表示部３２に表示されているキャラクタアイコン５を選択操作した状態で、サポータ解除操作アイコン３６をタッチ操作すると、プレーヤ端末１５００はサーバシステム１１００へ選択操作されたキャラクタアイコン５に対応する情報とともに「サポータ解除リクエスト」を送信する。サーバシステム１１００は、これを受信すると、時プレーヤの第２種アカウントリスト５２６や第３種アカウントリスト５２７から指定されたアカウントを削除するとともに、自プレーヤをお気に入り登録している側の他プレーヤの第１種アカウントリスト５２５や第３種アカウントリスト５２７から自プレーヤのアカウントを登録抹消する。なお、「お気に入り登録解除」「サポータ解除」の何れの場合も、お気に入りに登録される側のプレーヤによる承認は必要とされない。

［お気に入り関係の利用形態］
次に、プレーヤ間のお気に入り関係の利用について説明する。
プレーヤ間のお気に入り関係の第１利用形態として、本実施形態では、プレーヤは、関係種別「第１種」〜「第３種」の他プレーヤが使用する主人公キャラクタ４を、プレーヤキャラクタ（自プレーヤの主人公キャラクタ４）の味方ＮＰＣ（non player character）として同行させることができる。以降、この味方ＮＰＣを「同行メンバー」と呼称する。なお、選択できる同行メンバーの数は適宜設定可能であるが、理解を容易にするために本実施形態では「１体」とする。

図６は、同行メンバーを選択する過程におけるプレーヤ間のお気に入り関係の利用について説明する概念図である。自プレーヤ２（２ａ）のプレーヤキャラクタ４（４ａ）に同行できるキャラクタ、すなわち「同行メンバー候補」を選ぶにあたり、他プレーヤ２（２ｂ，２ｃ，２ｄ，２ｅ）のそれぞれの主人公キャラクタ４（４ｂ，４ｃ，４ｄ，４ｅ）が同行メンバー候補となるか否かについて示している。なお、図中、他プレーヤ２については、それぞれ黒太矢印の時間軸中の白帯で示された期間において実際に本実施形態と同じオンラインゲームをプレイしていたとされる。つまり、白帯の右端が最新アクセス日時となる。

同行メンバー候補は、「アクティブ」と認定される他プレーヤ２が使用する主人公キャラクタ４の中から選択される。ここで言う「アクティブ」とは、そのプレーヤが今まさにオンラインの状態であることは勿論、疑似的にオンラインと見なす状態であってもよい。
本実施形態では、他プレーヤ２のプレーヤ端末１５００が最後にサーバシステム１１００と通信した日時（最新アクセス日時）と現在日時又は自プレーヤのプレーヤ端末１５００が最後にサーバシステム１１００と通信した日時との時間差が、自プレーヤ２（２ａ）から見た当該他プレーヤの関係種別に応じたアクティブ認定時間差Ｔｎ（ｎ＝０，１，２，３）以下であれば、当該他プレーヤは「アクティブ」と認定される。

具体的には、他プレーヤ２（２ｂ）は関係種別「第３種」なのでアクティブ認定時間差Ｔ３が適用され、別の他プレーヤ２（２ｃ）は関係種別「第２種」なのでアクティブ認定時間差Ｔ２が適用される。さらに別の他プレーヤ２（２ｄ）は関係種別「第１種」なのでアクティブ認定時間差Ｔ１が適用される。さらに別の他プレーヤ２（２ｅ）は関係種別「なし」なのでアクティブ認定時間差Ｔ０が適用される。そして、アクティブ認定時間差Ｔｎ（ｎ＝０，１，２，３）は、Ｔ３＞Ｔ１＞Ｔ２＞Ｔ０の関係で設定されている。

上から３段目までの他プレーヤ２（２ｂ，２ｃ，２ｄ）は、今現在ではオンライン状態にはない。しかし、それぞれの最新アクセス日時と現在日時との時間差は、それぞれに適用されるアクティブ認定時間差Ｔｎ（ｎ＝０，１，２，３）以下であり、ともに「アクティブ」と認定される。最下段の他プレーヤ２（２ｅ）は、最上段の他プレーヤ２（２ｂ）と同じ期間ゲームプレイをしていたことになる。しかし、適用されるアクティブ認定時間差Ｔｎ（ｎ＝０，１，２，３）の関係で、当該他プレーヤ２（２ｅ）は「アクティブ」とは認定されないことになる。

図６の例では、他プレーヤは４人しか例示していないが、実際にはもっと多数の他プレーヤが認定対象となる。アクティブ認定時間差Ｔｎ（ｎ＝０，１，２，３）が、Ｔ３＞Ｔ１＞Ｔ２＞Ｔ０の関係で設定されていることで、実質的に、関係種別「第３種」の他プレーヤの主人公キャラクタ４が、他の関係種別よりも同行メンバー候補として選択される可能性が高くなるように工夫されている。次いで関係種別「第１種」が選択される可能性が高く、以下、関係種別「第２種」「なし」の順につづく。

なお、本実施形態ではアクティブ認定時間差Ｔｎ（ｎ＝０，１，２，３）は固定値としているが、対象となる他プレーヤ２（２ｂ，２ｃ，２ｄ，２ｅ）に係る情報を変数とする関数で可変に設定するとしてもよい。
例えば、対象とする他プレーヤ２の主人公キャラクタ４の強さを示す能力パラメータの値（例えば、キャラクタのレベル、経験値、攻撃力）や、強さを間接的に推測できるプレイ実行履歴（例えば、累積プレイ時間、プレイしているステージ番号、プレイ頻度）などを変数とし、認定対象とする他プレーヤの主人公キャラクタが強い又は強いと推測されるほど、アクティブ認定時間差Ｔｎ（ｎ＝０，１，２，３）がより短くなるように関数を設定することができる。この構成の場合、自プレーヤ２（２ａ）がゲームを始めたばかりの初心者で、プレイできる初期のステージのボスキャラクタもそれほど強くないのに、強力な同行メンバーが選択され、同行メンバーの一撃でステージクリアとなってしまうと言った具合にゲームバランスが崩れる事態を抑制することができる。

さて、実際に自プレーヤ２（２ａ）の同行メンバーとされるキャラクタは、本実施形態ではゲーム開始前にプレーヤによって上述のようにして選択された同行メンバー候補の中から選択される。具体的には、図７に示すように、プレーヤ端末１５００ではゲーム開始前手続きとして、同行メンバー選択画面Ｗ６が表示され、当該画面にて同行メンバー候補となった他プレーヤ２の主人公キャラクタ４のキャラクタアイコン５が選択可能に一覧表示される。

当該一覧で表示されるキャラクタアイコン５は、関係種別「第３種」＞「第１種」＞「第２種」＞「なし」の優先順位で表示されるものとする。図の例では、表示位置が上ほど優先順位が高いものとする。そして、当該画面では、キャラクタアイコン５には、そのキャラクタを使用する他プレーヤと自プレーヤとのお気に入り関係を示す第１種関係アイコン１１や第２種関係アイコン１２が付属表示され、実際に同行するキャラクタを選択するうえでの判断材料とされる。

図７の例において、他プレーヤ２（２ｂ）が使用する主人公キャラクタ４（４ｂ）のキャラクタアイコン５（５ｂ）が選択操作されたとする。すると、ゲーム画面Ｗ８に示すように、他プレーヤ２（２ｂ）が使用する主人公キャラクタ４（４ｂ）がプレーヤキャラクタ４（４ａ）の味方ＮＰＣとしてゲーム中に登場し、敵キャラクタ６と一緒に戦う。

図８は、本実施形態におけるプレーヤ間のお気に入り関係の第２利用形態を説明するための概念図である。プレーヤ間のお気に入り関係の第２利用形態として、本実施形態では、同行メンバーを主人公キャラクタ４とする他プレーヤ２との関係種別に基づいてゲーム進行制御を可変する。

例えば、本実施形態のオンラインゲームはアクションＲＰＧタイプなので、お気に入り関係に基づいて同行メンバーの能力を可変することができる。
より具体的には、図８（１）に示すように、関係種別「第３種」のプレーヤ２（２ｂ）の主人公キャラクタ４（４ｂ）が同行メンバーとなっている例である。この場合、味方ＮＰＣである同行メンバーの能力を、オリジナルの主人公キャラクタ４（４ｂ）の能力より向上させる。他の関係種別についても同様に能力の変更が行われるものとし、能力の変更量に着目すれば、変更後の能力の高い順に関係種別「第３種」＞「第１種」＞「第２種」＞「なし」とされる。例えば、図８（２）に示すように、関係種別「第２種」のプレーヤ２（２ｃ）の主人公キャラクタ４（４ｃ）が同行メンバーとなっている場合には、同行メンバーの能力を、オリジナルの主人公キャラクタ４（４ｃ）の能力と同じとすることができる。さらに、関係種別「なし」ではオリジナルの主人公キャラクタ４の能力を低下させるとしてもよい。

また、プレーヤがゲーム進行に伴い獲得するものにお気に入り関係に基づいて差を付けることができる。例えば、図８（１）のケースと図８（２）のケースとで、遭遇した敵キャラクタを倒してプレーヤキャラクタ４（４ａ）に与えられる「経験値」を比較すると、前者の方が後者よりも多く設定されている。他の関係種別についても同様に行われるものとし、獲得量などに表されるプレーヤに利する度合いに着目すれば、高い順に関係種別「第３種」＞「第１種」＞「第２種」＞「なし」とされる。勿論、経験値以外にも、敵キャラクタがドロップするアイテムの数や内容、レアアイテムの出現確率、攻撃回避などの内部抽選処理の当選確率、同行メンバーの行動上限数、などを適宜設定することができる。勿論、差がつけられるのはこれらに限らず、ゲーム内容等に応じて適宜設定可能である。

いずれにせよ、お気に入り関係の第２利用形態では、関係種別「第３種」＞「第１種」＞「第２種」＞「なし」の順に、よりプレーヤにとって有利となるようにゲームパラメータの設定が行われる。なお、ゲーム内容に応じてはこの関係が逆に設定してもよい。例えば、プレーヤが不利となる量／程度の大きさを、関係種別「第３種」＜「第１種」＜「第２種」＜「なし」の順に設定してもよい。

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

操作入力部１００ｓは、サーバの管理のための各種操作を入力するための手段である。図１のキーボード１１０６がこれに該当する。

サーバ処理部２００ｓは、例えばＣＰＵやＧＰＵ等のマイクロプロセッサや、ＡＳＩＣ（特定用途向け集積回路）、ＩＣメモリなどの電子部品によって実現され、操作入力部１００ｓやサーバ記憶部５００ｓを含む各機能部との間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部１００ｓからの操作入力信号、プレーヤ端末１５００から受信したデータに基づいて各種の演算処理を実行して、サーバシステム１１００の動作を統合的に制御する。
そして、本実施形態のサーバ処理部２００ｓは、アカウント管理部２０２と、ゲーム管理部２１０と、計時部２３２と、画像生成部２６０ｓと、通信制御部２７０ｓとを含む。

アカウント管理部２０２は、会員登録手続きに係る処理を行う。登録手続きを経たプレーヤへ固有のアカウントを発給し、アカウントデータ５２０を生成してその管理を行う。また、ログインに関する処理を実行する。

そして、本実施形態のアカウント管理部２０２は、通信日時管理部２０３を有する。
通信日時管理部２０３は、対応するアカウントのプレーヤ端末１５００との通信日時をログイン履歴５２３ａに格納し管理する。

ゲーム管理部２１０は、本実施形態のゲームプレイに係る各種処理を実行する。
本実施形態では、アカウントリスト管理部２１１と、同行メンバー候補検索部２１３と、リスト表示制御部２１４と、ゲーム進行制御部２２０とを含む。

アカウントリスト管理部２１１は、プレーヤ毎に用意されたリスト（お気に入りとして登録する他プレーヤのアカウントを格納するリスト；図３の第１種アカウントリスト５２５，第２種アカウントリスト５２６，第３種アカウントリスト５２７）を管理する。

本実施形態では、アカウントリスト管理部２１１は、登録解除制御部２１２を有する。
登録解除制御部２１２は、自プレーヤからの登録解除要請、例えば図５のお気に入り解除操作アイコン３５や、サポータ解除操作アイコン３６の操作入力に応じてお気に入り登録済みのアカウントを、相手の承認無しに抹消して登録解除することができる。その際、登録削除される側のプレーヤの第３種アカウントリスト５２７に登録を削除要請する側のプレーヤが登録されていない場合には登録解除要請に応じた解除を実行せず、登録されている場合に登録解除要請に応じた解除を実行する。

同行メンバー候補検索部２１３は、同行メンバー候補を選択するために、プレーヤと同時又は近時にプレイしているとみなされる他プレーヤを検索する。
具体的には、「プレーヤと同時又は近時にプレイしているとみなされる」つまり「アクティブ」と認定されるための時間条件をお気に入り関係に応じて変更して（図６のアクティブ認定時間差Ｔｎ（ｎ＝０，１，２，３，））、当該時間条件を満たすプレーヤを検索する。

リスト表示制御部２１４は、プレーヤ端末１５００にて同行メンバー候補の一覧を表示させる制御を行う。本実施形態では、表示に上限数が設けられており、関係種別に応じた優先順位で同行メンバー候補を選択してリストを表示する。優先順位は、高い方から順に関係種別「第３種」「第１種」「第２種」「無し」と設定されている。つまり、プレーヤ間のお気に入り関係がより深いと思われる関係ほど優先的に表示させる。

ゲーム進行制御部２２０は、自プレーヤの第１種アカウントリスト５２５，第２種アカウントリスト５２６，第３種アカウントリスト５２７に登録されている他プレーヤに係るキャラクタ（主人公キャラクタ４）を、自プレーヤのゲーム内に登場させてゲームを進行させる。そして、本実施形態のゲーム進行制御部２２０は、パラメータ設定部２２２と、個人情報提供部２２４とを有する。

パラメータ設定部２２２は、ゲーム進行に利用する所定のパラメータの値を、プレーヤに係るお気に入り関係に基づいて設定する。具体的には、本実施形態では同行メンバーの能力を自プレーヤと当該同行メンバーを主人公キャラクタ４とする他プレーヤ２との関係種別に基づいて設定することができる（図８）。また、敵キャラクタの能力や出現頻度を、同行メンバーの関係種別が、関係種別「第３種」＞「第１種」＞「第２種」＞「なし」の順にプレーヤに利するように設定することができる。

個人情報提供部２２４は、プレーヤ端末１５００でアカウントの個人情報を公開するためのデータを提供する制御を行う。本実施形態では、公開可能な個人情報には、アカウントのプロフィールと、関係種別「第２種」に登録されているアカウントは含めるが、関係種別「第１種」および「第３種」は含めない。

計時部２３２は、システムクロックを利用して日時や経過時間などの計時に係る処理を実行する。

画像生成部２６０ｓは、サーバシステム１１００の保守に関する画像を生成し、画像表示部３６０ｓへ出力することができる。また、本実施形態では、ゲーム空間画像などプレーヤ端末１５００で表示させる各種画像の生成処理も実行することができる。

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

通信制御部２７０ｓは、データ通信に係るデータ処理を実行し、通信部３７０ｓを介して外部装置とのデータのやりとりを実現する。

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

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

そして、本実施形態のサーバ記憶部５００ｓは、サーバシステムプログラム５０３と、アカウント管理プログラム５０４と、ゲーム管理プログラム５０５と、配信用ゲームクライアントプログラム５０６と、を予め記憶する。また、データとしては、ゲーム初期設定データ５１０とを予め記憶する。また、会員登録やゲーム進行に応じて生成・管理されるデータとして、アカウントデータ５２０と、プレイデータ５４０と、メッセージ履歴マスターデータ５７０とを記憶する。また、その他、タイマやカウンタ、各種フラグなどの情報を適宜記憶することができる。

サーバシステムプログラム５０３は、サーバ処理部２００ｓが読み出して実行することでサーバシステム１１００にコンピュータとして必要な基本的な入出力機能を実現する為のシステムプログラムである。

アカウント管理プログラム５０４は、サーバ処理部２００ｓが読み出して実行することで、アカウント管理部２０２とゲーム管理部２１０としての機能を実現させるためのプログラムである。

ゲーム管理プログラム５０５は、サーバ処理部２００ｓが読み出して実行することで、ゲーム管理部２１０としての機能を実現させるためのプログラムである。

配信用ゲームクライアントプログラム５０６は、プレーヤ端末１５００へ提供されるゲームクライアントプログラム５０２（図１４参照）のオリジナルである。

ゲーム初期設定データ５１０は、ゲーム実行に必要な各種初期設定データを格納する。本実施形態では、ゲームの舞台となるゲーム空間と、主人公キャラクタ４や敵キャラクタ６等に関する初期設定データを格納する。
ゲーム空間については、仮想３次元空間に配置される背景オブジェクトのモデルデータやテクスチャデータ、配置位置座標等を格納する。
主人公キャラクタ４に関しては、プレーヤが自分が使用するキャラクタとすることのできる全てのキャラクタ種類それぞれについて、当該キャラクタを表示・動作させるためのデータ、例えばキャラクタオブジェクトのモデルデータや、モーションデータ、キャラクタアイコン５（図４）などを格納する。
敵キャラクタ６に関しては、種類毎に、当該敵キャラクタを表示・動作させるためのデータ、例えばキャラクタオブジェクトのモデルデータや、モーションデータ、出現条件や出現位置、出現数、初期能力パラメータ値（ＨＰ、攻撃力、防御力など）といったデータを格納する。

アカウントデータ５２０は、アカウント管理部２０２により、会員登録したプレーヤ毎に用意される。例えば図１０に示すように、１つのアカウントデータ５２０は、アカウント５２１と、プロフィールデータ５２２と、プレイ履歴データ５２３と、第１種アカウントリスト５２５と、第２種アカウントリスト５２６と、第３種アカウントリスト５２７とを含む。

プレイ履歴データ５２３は、対応するプレーヤの過去のゲームプレイに係る履歴を格納する。例えば、過去のログイン／ログアウトの日時が時系列に格納されるログイン履歴５２３ａと、セーブデータ５２３ｂとを含む。

セーブデータ５２３ｂは、前回のゲーム終了時点におけるゲーム進行状況を記述するデータである。セーブ時点におけるプレーヤキャラクタの各種能力パラメータ値を格納するプレーヤキャラクタステータスデータ５２３ｃを含む。

図９に戻り、プレイデータ５４０は、アカウント別にプレイ中のゲームの進行状況を示す各種パラメータ値を格納する。
例えば、図１１に示すように、アカウント５４１と、プレーヤキャラクタステータスデータ５４２と、同行メンバー候補リスト５５０と、同行メンバーステータスデータ５６０と、同行メンバー行動回数５６２と、関係種別５６４とを含む。

同行メンバー候補リスト５５０は、同行メンバー候補に関する情報を格納する。例えば、図１２に示すように、候補毎に、プレーヤのアカウント５５１と、当該アカウントのプレーヤの主人公キャラクタ４の種類を示すキャラクタ種類５５３と、能力パラメータ値セット５５５と、自プレーヤから見た当該候補を使用する他プレーヤの関係種別５５７と、キャラクタアイコン５５９とを対応付けて格納する。

図１１に戻って、同行メンバーステータスデータ５６０は、同行メンバー候補リスト５５０から選択された真の同行メンバーとなったキャラクタの状態を記述する各種データを格納する。基本的には、プレーヤキャラクタステータスデータ５４２と同じような内容であるが、同行メンバー行動回数５６２と関係種別５６４とを含む。

同行メンバー行動回数５６２は、プレーヤが同行メンバーに何らかの行動（例えば、攻撃、プレーヤキャラクタの回復など）をすると、その都度回数が「１」加算される。初期値は「０」とされ、基本的には同行メンバー行動回数５６２が「１」になると、当該同行メンバーはゲーム終了まで行動できない仕様である。しかし、ゲームプレイ中に所定のアイテムを使用したり、所定の魔法を作動させるなどの所与の同行キャラクタ行動回復条件を満たすと、同行メンバー行動回数５６２がリセットされる構成としてもよい。

関係種別５６４は、真の同行メンバーとして選択されたキャラクタの同行メンバー候補リスト５５０における関係種別５５７のコピーである。

図９に戻って、メッセージ履歴マスターデータ５７０は、プレーヤが自由に投稿できる電子掲示板に投稿されたメッセージに関する情報を時系列に格納する。例えば、図１３に示すように、投稿毎に投稿日時５７１と、投稿主プレーヤのアカウントを示す投稿主アカウント５７３と、メッセージ内容５７５と、投稿主プレーヤが使用する主人公キャラクタのキャラクタアイコン５７７とを格納する。

［プレーヤ端末の機能構成の説明］
図１４は、本実施形態におけるプレーヤ端末１５００の機能構成の一例を示す機能ブロック図である。本実施形態のプレーヤ端末１５００は、操作入力部１００と、処理部２００と、音出力部３５０と、画像表示部３６０と、通信部３７０と、記憶部５００とを備える。

操作入力部１００は、自プレーヤによって為された各種の操作入力に応じて操作入力信号を処理部２００に出力する。例えば、プッシュスイッチや、ジョイスティック、タッチパッド、トラックボール、加速度センサ、ジャイロ、ＣＣＤモジュール、などによって実現できる。図２の方向入力キー１５０２や、ボタンスイッチ１５０４、タッチパネル１５０６がこれに該当する。

処理部２００は、例えばＣＰＵやＧＰＵ等のマイクロプロセッサや、ＡＳＩＣ（特定用途向け集積回路）、ＩＣメモリなどの電子部品によって実現され、操作入力部１００や記憶部５００を含む各機能部との間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部１００からの操作入力信号、サーバシステム１１００から受信した各種データに基づいて各種の演算処理を実行して、プレーヤ端末１５００の動作を制御する。図２の制御基板１５５０がこれに該当する。そして、本実施形態における処理部２００は、プレーヤ端末演算部２４０と、音生成部２５０と、画像生成部２６０と、通信制御部２７０とを備える。

プレーヤ端末演算部２４０は、当該コンピュータをゲームプレイのための端末として機能させるための各種演算処理を実行する。例えば、本実施形態のオンラインゲームをウェブゲームとして実現するならば、ウェブブラウザをベースとしてＨＴＭＬとともにＪａｖａ（登録商標）やＣＳＳ（Cascading Style Sheets）を利用して能動的に画面表示を制御するウェブ技術や、Adobe（登録商標） Flashなどのプラグインを用いて実現できる。勿論、その他の方法でもかまわない。
そして、プレーヤ端末演算部２４０は、操作信号送信制御部２４２と、ゲーム画面表示制御部２４４とを含み、適宜計時等のその他の機能に係る処理を行う。

操作信号送信制御部２４２は、操作入力部１００へ為された操作に応じて、各種データやリクエストをサーバシステム１１００へ送信するための処理を実行する。

ゲーム画面表示制御部２４４は、サーバシステム１１００から受信した各種データに基づいてゲーム画面を表示するための制御を行う。本実施形態では、ゲーム空間画像（例えば、３ＤＣＧなど）をサーバシステム１１００にて生成する構成とするが、ゲーム空間画像をプレーヤ端末１５００で生成する構成も可能である。その場合、ゲーム画面表示制御部２４４は、３ＤＣＧを生成するための仮想３次元空間に配置されたオブジェクトの制御を含むこととなる。

音生成部２５０は、例えばデジタルシグナルプロセッサ（ＤＳＰ）や、音声合成ＩＣなどのプロセッサ、音声ファイル再生可能なオーディオコーデック等によって実現され、ゲーム画面表示制御部２４４による処理結果に基づいてゲームに係る効果音やＢＧＭ、各種操作音の音信号を生成し、音出力部３５０に出力する。

音出力部３５０は、音生成部２５０から入力される音信号に基づいて効果音やＢＧＭ等を音出力する装置によって実現される。図２のスピーカ１５１０がこれに該当する。

画像生成部２６０は、例えば、ＧＰＵ、デジタルシグナルプロセッサ（ＤＳＰ）などのプロセッサ、ビデオ信号ＩＣ、ビデオコーデックなどのプログラム、フレームバッファ等の描画フレーム用ＩＣメモリ等によって実現される。画像生成部２６０は、ゲーム画面表示制御部２４４による処理結果に基づいて１フレーム時間（例えば１／６０秒）で１枚のゲーム画面の画像を生成し、生成したゲーム画面の画像信号を画像表示部３６０に出力する。そして、本実施形態では、サーバシステム１１００から受信したデータに基づいてゲーム画面の画像を生成することができる。また、ゲーム画面表示制御部２４４の制御に従って、ゲーム空間画像に各種情報表示体を合成することができる。もし、ゲーム空間画像の３ＤＣＧをサーバシステム１１００で生成せずプレーヤ端末１５００で生成する構成ではレンダリング処理を担うことができる。

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

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

記憶部５００は、処理部２００にプレーヤ端末１５００を統合的に制御させるための諸機能を実現するためのシステムプログラムや、ゲームプレイに必要なプログラム、各種データ等を記憶する。また、処理部２００の作業領域として用いられ、処理部２００が各種プログラムに従って実行した演算結果や操作入力部１００から入力される入力データ等を一時的に記憶する。こうした機能は、例えばＲＡＭやＲＯＭなどのＩＣメモリ、ハードディスク等の磁気ディスク、ＣＤ−ＲＯＭやＤＶＤなどの光学ディスクなどによって実現される。図２の制御基板１５５０が搭載するＩＣメモリ１５５２やメモリカード１５４０がこれに該当する。

本実施形態の記憶部５００は、システムプログラム５０１と、ゲームクライアントプログラム５０２とを記憶している。
システムプログラム５０１は、プレーヤ端末１５００のコンピュータとしての入出力の基本機能を実現するためのプログラムである。ゲームクライアントプログラム５０２は、処理部２００が読み出して実行することによってプレーヤ端末演算部２４０としての機能を実現させるためのアプリケーションソフトであるが、システムプログラム５０１の一部として組み込まれた構成であっても良い。ゲームクライアントプログラム５０２は、オンラインゲームを実現する技術手法に応じて専用のクライアントプログラムであっても良いし、ウェブブラウザプログラム及びインタラクティブな画像表示を実現するプラグインなどにより構成するとしても良い。

また、記憶部５００は、サーバシステム１１００から受信した、表示用メッセージデータ５８０と、同行メンバー候補リスト５９０とを一時的に記憶することができる。
勿論、記憶部５００には、その他、ゲーム進行状況を記述するためのデータ、計時のためのカウンタ、各種フラグなどを適宜記憶することができる。

表示用メッセージデータ５８０は、メッセージ掲示画面Ｗ２（図４）を表示する際に、サーバシステム１１００から取得するデータであって、メッセージ履歴マスターデータ５７０（図１３参照）の抜粋（例えば、最新の投稿から過去１０件分）である。
図１５に示すように、基本的にはメッセージ履歴マスターデータ５７０と同じデータ構成を有するが、メッセージ履歴マスターデータ５７０の内容に加えて、公開用個人情報５８２を対応づけて格納する。本実施形態では、メッセージ掲示画面Ｗ２（図４）にてメッセージテキスト２３をダブルタップすると、当該メッセージの投稿主アカウントに関する情報が表示される。公開用個人情報５８２は、そのとき開示される情報である。本実施形態では、公開用個人情報５８２に、投稿主アカウントのプロフィールデータ５２２と、第２種アカウントリスト５２６とが含めるが、第１種アカウントリスト５２５および第３種アカウントリスト５２７はこれに含めないことでプライバシーに配慮する。

図１４に戻って、同行メンバー候補リスト５９０は、同行メンバー選択画面Ｗ６（図７）を表示する際に、サーバシステム１１００から取得するデータであって、プレーヤのプレイデータ５４０に含まれる同行メンバー候補リスト５５０（図１１）の複製である。

なお、プレーヤ端末１５００にてメッセージ掲示画面Ｗ２や同行メンバー選択画面Ｗ６を表示させる手法によっては、表示用メッセージデータ５８０や同行メンバー候補リスト５９０が不要とされる場合もあり、その場合はこれらのデータを適宜省略することができる。

［処理の流れの説明］
次に、サーバシステム１１００及びプレーヤ端末１５００における処理の流れについて説明する。ここで説明する処理の流れは、サーバ処理部２００ｓがサーバシステムプログラム５０３を実行した状態で、アカウント管理プログラム５０４及びゲーム管理プログラム５０５を実行することにより実現される。また、プレーヤ端末１５００の処理部２００がシステムプログラム５０１を実行した状態で、ゲームクライアントプログラム５０２を実行することより実現される。なお、自プレーヤ（これからゲームプレイする本人）は既に会員登録を済ませ、自身が使用する主人公キャラクタ４を選択しているものとする。

図１６〜図１７は、サーバシステム１１００及びプレーヤ端末１５００における主たる処理の流れを説明するためのフローチャートである。
プレーヤ端末１５００で、ゲームクライアントプログラム５０２を起動させると、アカウントとパスワードの入力手続き処理が実行される。プレーヤが自身のアカウントとパスワードを入力すると、プレーヤ端末１５００は自動的にサーバシステム１１００へ入力されたアカウント及びパスワードを用いて認証手続きを実行する。

そして、認証が完了するとプレーヤ端末１５００ではホーム画面が表示される（ステップＳ２）。サーバシステム１１００が表示させるとしてもよいし、プレーヤ端末１５００側の制御で表示させるとしてもよい。いずれにしても、ホーム画面には、「メッセージ掲示画面の表示」や「関係一覧画面の表示」「同行メンバーの選択」「ゲーム開始」の何れかを選択操作可能なメニュー表示が含まれるものとする。なお、「ゲーム開始」には「新たに開始」と「セーブポイントから開始」の選択肢が含まれているものとする。

そして、ホーム画面にて「メッセージ掲示画面の表示」のメニューが選択操作されると（ステップＳ４のＹＥＳ）、プレーヤ端末１５００はサーバシステム１１００へメッセージ掲示画面表示リクエストを送信する（ステップＳ６）。
サーバシステム１１００は、これを受信するとメッセージ履歴データ５７０（図１３）を元にして表示用メッセージデータ５８０（図１５）を生成して、プレーヤ端末１５００へ送信する（ステップＳ８）。

プレーヤ端末１５００は、表示用メッセージデータ５８０を受信すると、これを一時的に記憶部５００へ記憶しメッセージ掲示画面Ｗ２を表示する（ステップＳ１０；図４）。
そして、同画面にて登録操作アイコン１０への操作を検出すると（ステップＳ１２のＹＥＳ）、プレーヤ端末１５００はサーバシステム１１００へ操作された登録操作アイコン１０が付属する個別メッセージ表示部２０の投稿主アカウント５７３（図１５）を指定する「登録リクエスト」を送信する（ステップＳ１４）。

サーバシステム１１００のサーバ処理部２００ｓは、「登録リクエスト」を受信すると、お気に入り登録操作入力（サポート宣言操作入力）を検出したとみなし、お気に入り関係設定処理を実行する（ステップＳ１６）。

図１８は、本実施形態におけるお気に入り関係設定処理の流れを説明するためのフローチャートである。同処理に於いて、サーバシステム１１００のサーバ処理部２００ｓは、自プレーヤの第１種アカウントリスト５２５へ指定されたアカウントを登録し（ステップＳ４０）、指定されたアカウントの第２種アカウントリスト５２６へ自プレーヤのアカウントを登録する（ステップＳ４２）。

そして、指定されたアカウントと同一のアカウントが、既に自プレーヤの第２種アカウントリスト５２６に登録されている場合には、当該指定アカウントは関係種別「第３種」の成立条件を満たすと判断して（ステップＳ４４のＹＥＳ）、自プレーヤの第１種アカウントリスト５２５及び第２種アカウントリスト５２６から当該指定アカウントを削除して第３種アカウントリスト５２７に登録して登録変更する（ステップＳ４６）。そして、当該指定アカウントの第２種アカウントリスト５２６から第３種アカウントリスト５２７へ、自プレーヤのアカウントを移動して登録変更する（ステップＳ４８）。そして、お気に入り関係設定処理を終了する。

図１６のフローチャートに戻って、メッセージ掲示画面Ｗ２にて所定のホーム画面復帰操作の入力を検出したら（ステップＳ５８のＹＥＳ）、ステップＳ２に戻ってプレーヤ端末１５００はホーム画面を表示する。

なお、表示用メッセージデータ５８０には、プレーヤ端末１５００にてメッセージの投稿主に係る公開用個人情報５８２が含まれているので、メッセージ掲示画面Ｗ２のメッセージテキスト２３には、この公開用個人情報５８２の内容を含めるとしてもよい。あるいは、別途ポップアップ表示２５（図４）にて表示するとしてもよい。

もし、ホーム画面にて「関係一覧画面の表示」メニューが選択操作されると（ステップＳ６０のＹＥＳ）、プレーヤ端末１５００はサーバシステム１１００へ「関係確認リクエスト」を送信する（ステップＳ６２）。
サーバシステム１１００は、これを受信するとプレーヤのアカウントデータ５２０（図１０）から各種アカウントリストを読み出して返信する（ステップＳ６４）。プレーヤ端末１５００はこれらのリストを受信し、関係一覧画面Ｗ４（図５）を表示する（ステップＳ６６）。

そして、当該画面が表示されている状態で、第１種関係表示部３０に表示されているキャラクタアイコン５が選択操作されて、お気に入り解除操作アイコン３５の操作入力を検出すると、プレーヤ端末１５００はサーバシステム１１００へ選択操作されたキャラクタアイコン５に対応する情報（例えば、アカウント）とともに「お気に入り解除リクエスト」を送信し（ステップＳ７０）、サーバシステム１１００はこれを受信するとお気に入り解除処理を実行する（ステップＳ７２）。

図１９は、お気に入り解除処理の流れを説明するためのフローチャートである。同処理において、サーバシステム１１００のサーバ処理部２００ｓは、選択操作されたキャラクタアイコン５に対応するアカウント全てについて、各アカウントの第３種アカウントリスト５２７から第１種アカウントリスト５２５へ自プレーヤのアカウントを移動させて登録変更する（ステップＳ９０）。
そして、自プレーヤの第３種アカウントリスト５２７から、選択操作されたキャラクタアイコン５に対応する全アカウントを第２種アカウントリスト５２６へ移動して登録変更する（ステップＳ９２）。

次に、サーバシステム１１００は、選択操作されたキャラクタアイコン５に対応する全アカウントについて、各アカウントの第２種アカウントリスト５２６から自プレーヤのアカウントを削除する（ステップＳ９４）。
そして、自プレーヤの第１種アカウントリスト５２５から選択操作されたキャラクタアイコン５に対応する全アカウントを削除して（ステップＳ９６）、お気に入り解除処理を終了する。

図１６のフローチャートに戻って、関係一覧画面Ｗ４にて第２種関係表示部３２のキャラクタアイコン５が選択された状態で、且つサポータ解除操作アイコン３６（図５）の操作入力を検出した場合には（ステップＳ１１０のＹＥＳ）、プレーヤ端末１５００はサーバシステム１１００へ選択操作されたキャラクタアイコン５に対応する情報（例えば、アカウント）とともに「サポータ解除リクエスト」を送信し（ステップＳ１１２）、サーバシステム１１００はこれを受信するとサポータ解除処理を実行する（ステップＳ１１４）。

図２０は、サポータ解除処理の流れを説明するためのフローチャートである。
同処理において、サーバシステム１１００のサーバ処理部２００ｓは、選択操作されたキャラクタアイコン５に対応する全アカウントについて、ループＢを実行する（ステップＳ１２６〜Ｓ１３８）。

ループＢでは、まず当該ループの処理対象アカウントが、自プレーヤの第３種リスト５２７に登録されているかを判定する（ステップＳ１２８）。
もし、登録されていれば（ステップＳ１２８）、サーバ処理部２００sは、処理対象アカウント（他プレーヤ）の第３種アカウントリスト５２７から第１種アカウントリスト５２５へ自プレーヤのアカウントを移動させて登録変更し（ステップＳ１３０）、当該第１種アカウントリスト５２５から自プレーヤのアカウントを削除する（ステップＳ１３２）。

次に、処理対象アカウントを、自プレーヤの第３種アカウントリスト５２７から第１種アカウントリスト５２５へ移動して登録変更し（ステップＳ１３４）、当該第２種アカウントリスト５２６から処理対象アカウントを削除して（ステップＳ１３６）、ループＢを終了する（ステップＳ１３８）。

もし、ステップＳ１２８で、処理対象アカウントが自プレーヤの第３種アカウントリスト５２７に登録されていなければ（ステップＳ１２８のＮＯ）、サーバ処理部２００sは、ステップＳ１３０〜Ｓ１３６をスキップする。これにより、自分がサポート（お気に入り登録）していないからといって、自分のことをサポートしたい（お気に入り登録したい）という他プレーヤの行為を、自分から一方的に拒否できるようにしない、という仕組みを実現できる。

サポータの登録解除対象として自プレーヤが選択した全てのアカウントについてループＢを実行したならば、サーバ処理部２００sはサポータ解除処理を終了する。

なお、ステップＳ１３０〜Ｓ１３２を、処理対象アカウントの第３種アカウントリスト５２７から自プレーヤのアカウントを削除するステップに置き換えることができる。また、ステップＳ１３４〜Ｓ１３６を、自プレーヤの第３種アカウントリスト５２７から処理対象アカウントを削除するステップに置き換えることができる。

図１６のフローチャートに戻って、関係一覧画面Ｗ４にて所定のホーム画面復帰操作の入力を検出したら（ステップＳ１４８のＹＥＳ）、ステップＳ２に戻ってプレーヤ端末１５００はホーム画面を表示する。

図１７のフローチャートに移って、ホーム画面にて「同行メンバーの選択」メニューが選択操作されると（ステップＳ１５０のＹＥＳ）、プレーヤ端末１５００はサーバシステム１１００へ「同行メンバー選択リクエスト」を送信する（ステップＳ１５２）。
サーバシステム１１００は、これを受信すると自プレーヤの同行メンバー候補リスト５５０（図１２）の登録を全削除してリセットして（ステップＳ１５４）、同行メンバー選択処理を実行する（ステップＳ１５６）。

図２１は、本実施形態における同行メンバー選択処理の流れを説明するためのフローチャートである。同処理に於いて、サーバシステム１１００のサーバ処理部２００ｓは、関係種別「第３種」「第２種」「第１種」の順にループＥを実行する（ステップＳ１７８〜Ｓ１９８）。

ループＥでは、処理対象とする関係種別に係る自プレーヤのアカウントリスト（第１種アカウントリスト５２５，第２種アカウントリスト５２６，第３種アカウントリスト５２７）に登録されているアカウントについてループＦを実行する（ステップＳ１８０〜Ｓ１９６）。

ループＦでは、処理対象アカウントのプレイ履歴データ５２３のログイン履歴データ５２３ａ（図１０）を参照して、処理対象アカウントの最新アクセス日時と現在日時との時間差を算出する。
そして、算出した時間差がループＥの処理対象の関係種別に対応するアクティブ認定時間差Ｔｎ（ｎ＝１，２，３）未満であれば（ステップＳ１８２のＹＥＳ）、サーバ処理部２００ｓは、現時点においてループＦの処理対象アカウントのプレーヤを「アクティブ」と認定し、当該処理対象アカウントの主人公キャラクタをプレーヤの同行メンバー候補リス５５０（図１２）へ登録する（ステップＳ１９４）。この時、能力パラメータ値セット５５５には、処理対象アカウントのプレイ履歴データ５２３（図１０）のプレーヤキャラクタステータスデータ５２３ｃで示される主人公キャラクタのオリジナルの能力パラメータ値を、ループＥの処理対象の関係種別に応じて設定する。本実施形態では、関係種別「第３種」ならオリジナルの１２０％、「第１種」ならばオリジナルの１１０％、「第２種」ならばオリジナルのまま、とする。

ループＥの処理対象の関係種別に対応するアカウントリストに登録されているアカウント全てについてループＦを実行したならば、ループＥを終了する。
そして、関係種別「第３種」「第２種」「第１種」のすべての関係種別についてループＥを実行したならば、次に、サーバシステム１１００のサーバ処理部２００sは、同行メンバー候補リスト５５０に登録されている候補数をカウントする。

もし、同行メンバー候補数の合計が、所定の同行上限数に満たない場合には（ステップＳ２００のＹＥＳ）、自プレーヤの第１アカウントリスト５２５〜第３アカウントリスト５２７のいずれにも登録されていない他アカウント、つまり関係種別「なし」に相当する他プレーヤのアカウントから、同行上限数に不足する数だけアカウントをランダムに選択する。そして、選択されたアカウントの主人公キャラクタを同行メンバー候補リスト５５０へ新たに追加登録する（ステップＳ２０２）。このとき、能力パラメータ値セット５５５には、選択されたアカウントの主人公キャラクタのオリジナルの能力を減じた値（例えば、オリジナルの９０％）を設定し、関係種別５５７には「無し」を設定するものとする。
そして、サーバシステム１１００は同行メンバー候補選択処理を終了する。

図１７のフローチャートに戻って、サーバシステム１１００は、同行メンバー選択リスト５５０に基づいてプレーヤ端末１５００で同行メンバー選択画面Ｗ６（図７）を表示させる（ステップＳ２１２）。その際、キャラクタアイコン５を、関係種別「第３種」＞「第１種」＞「第２種」＞「なし」の優先順位でキャラクタアイコン５を配列するものとする。

そして、同画面にて何れかのキャラクタアイコン５が選択操作されると、プレーヤ端末１５００からサーバシステム１１００へ選択されたキャラクタアイコン５の情報が送信される（ステップＳ２１４）。

サーバシステム１１００は、これを受信すると同行メンバーを設定する（ステップＳ２１６）。具体的には、受信したキャラクタアイコン５の情報に対応する同行メンバー候補の能力パラメータ値セット５５５と関係種別５５７に基づいて、プレーヤのプレイデータ５４０（図１１）に同行メンバーステータスデータ５６０を生成する。なお、同行メンバー行動回数５６２はこの時「０」にリセットされる。

ホーム画面にて「ゲーム開始」メニューの「新たに開始」と「セーブポイントから開始」の何れかの開始タイプの選択肢が選択操作されると（ステップＳ２３０のＹＥＳ）、プレーヤ端末１５００はサーバシステム１１００へ「ゲーム開始リクエスト」及び開始タイプの識別を送信する（ステップＳ２３２）。サーバシステム１１００は、これを受信するとゲーム処理を実行する（ステップＳ２３４）。プレーヤ端末１５００は、サーバシステム１１００からゲーム終了が通知されるまで、サーバシステム１１００から送信されるゲーム画面表示用のデータに基づいてゲーム画面を表示させ、操作入力信号をサーバシステム１１００へ送信する（ステップＳ２３６）。

図２２は、本実施形態におけるゲーム処理の流れを説明するためのフローチャートである。同処理において、サーバシステム１１００のサーバ処理部２００ｓは、先ずゲーム開始タイプが「セーブポイントから開始」であれば（ステップＳ２６０のＹＥＳ）、プレーヤのプレイ履歴データ５２３（図１０）のセーブデータ５２３ｂを読み出す（ステップＳ２６２）。そして、ゲーム進行制御を開始する（ステップＳ２６４）。
以降、ゲーム処理が終了するまで、サーバ処理部２００ｓは逐次ゲーム画面を生成処理して、ゲーム画面を表示させるためのデータをプレーヤ端末１５００へ送信し、プレーヤ端末１５００から操作入力信号を受信してプレーヤキャラクタや同行メンバーのキャラクタの動作を制御するものとする。

具体的には、サーバ処理部２００sは、お気に入り関係に応じたゲーム進行関連パラメータの変更処理を行う（ステップＳ２６６）。当該変更処理の具体例としては、所定の出現条件を満たした敵キャラクタ６をゲーム空間内に登場させる際に、新たに登場する敵キャラクタ６の能力パラメータ値は、同行メンバーの関係種別５６４に応じて設定する。より具体的には、関係種別「第３種」＞「第２種」＞「第１種」＞「無し」の順に能力が低くなるように、つまり「第３種」が最もプレーヤに利するように設定する。勿論、ゲーム内容に応じては逆に関係種別「第３種」の方が最も敵キャラクタ６の能力が高くなるように設定することができる。また、敵キャラクタ６の能力に限らず、出現確率を可変するとしてもよい。

次に、サーバ処理部２００sは、移動操作入力に応じてプレーヤキャラクタ（すなわちプレーヤの主人公キャラクタ４）及び同行メンバーを移動させ（ステップＳ２８０）、敵キャラクタの自動移動制御をする（ステップＳ２８２）。
次いで、プレーヤキャラクタと敵キャラクタとが遭遇すれば（ステップＳ２８４のＹＥＳ）、攻撃操作入力に応じてプレーヤキャラクタ及び同行メンバーの戦闘行動制御をし（ステップＳ２８６）、敵キャラクタの自動攻撃制御をする（ステップＳ２８８）。そして、攻撃判定とそのダメージの反映処理を行う（ステップＳ２９０）。

そして、遭遇した敵キャラクタを撃破できたならば（ステップＳ２９２のＹＥＳ）、サーバ処理部２００ｓは、当該敵キャラクタに応じた撃破ボーナスをプレーヤに付与する（ステップＳ２９４）。例えば、経験値、アイテムドロップなどである。

なお、ステップＳ２８０〜Ｓ２９４は、アクションＲＰＧを前提とした内容であり、ゲームジャンルやゲーム内容に応じて適宜変更可能である。

次に、サーバ処理部２００sは、関係種別対応処理を実行する（ステップＳ２９６）。
同処理は、同行メンバーの関係種別に応じてゲーム進行に変化を与える為の処理の一つである。ゲーム進行に与える変化の度合は、関係種別「第３種」＞「第１種」＞「第２種」＞「無し」の順に小さくなる。変化の内容はゲーム内容に応じて適宜設定可能である。
本実施形態では、アクションＲＰＧタイプのゲームなので、プレーヤに対して同行ボーナスとして経験値やアイテム、（ゲームによっては、ゲーム内通貨、ヒットポイント、マジックポイント、行動ポイントなどでもよい）を付与する。
そして、本実施形態では同行ボーナスを同行メンバーのアカウントにも付与する。具体的には、同行メンバーのアカウントのセーブデータ５２３ｂのうちボーナス対象となるパラメータ値を変更するとしてもよいし、同行ボーナスの内容を示す「同行ボーナスデータ」をプレイ履歴データ５２３に作成し、当該アカウントのプレーヤが次にゲームをプレイする際に、「同行ボーナスデータ」に従ってボーナスが付与されるパラメータ値を変更する構成としてもよい。

そして、関係種別対応処理を実行したならば、サーバ処理部２００sは、ゲーム終了条件を満たしているか判定する（ステップＳ２９８）。本実施形態では、プレーヤキャラクタのヒットポイントが「０」になった場合にはゲームオーバー、ボス敵キャラクタを撃破したらゲームクリアとして、ゲーム終了条件を満たすと判定する。

もし、ゲーム終了条件を満たさなければ（ステップＳ２９８のＮＯ）、ステップＳ２６６に戻ってゲーム進行が継続される。もし、ゲーム終了条件を満たせば（ステップＳ２９８のＹＥＳ）、ゲーム処理を終了する。

図１７のフローチャートに戻って、サーバシステム１１００はゲーム処理を終了したならば、ゲーム終了をプレーヤ端末１５００へ通知し（ステップＳ３１０）、今回のゲームプレイ結果をセーブして（ステップＳ３１２）、一連の処理を終了する。

以上、本実施形態によれば、プレーヤは、相手の承認無しに一方的に他プレーヤを自分の「お気に入り」として登録することができる。
これはプレーヤ相互に言えることであり、「一方的にお気に入り登録した」関係（第１種）、「一方的にお気に入り登録された」関係（第２種）、「双方が互いにお気に入り登録している」関係（第３種）、「双方がお気に入り登録していない」関係の４つの組み合わせのプレーヤ間の繋がりを形成することができる。さらには、お気に入りの登録解除も相手の登録が不要である。従って、プレーヤの気持ち次第で、軽い繋がり関係（関係種別「第１種」や「第２種」）のままとどめたり、より深い繋がり関係（関係種別「第３種」）とすることが自由であり、軽い気持ちで関係構築を始めることができる。従来よりも活発な繋がり関係の構築が期待できる。

そして、その繋がり関係に応じてゲーム進行に変化を与えることができる。
また、他プレーヤのアクティブ認定においても、その繋がり関係を利用することができる。

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

［その１］
例えば、上記実施形態では、プレーヤ毎に、他プレーヤを登録するリストとして、第１種アカウントリスト５２５と、第２種アカウントリスト５２６と、第３種アカウントリスト５２７とを用意したが、第２種アカウントリスト５２６および第３種アカウントリスト５２７を省略する構成も可能である。
その場合、関係種別を利用する都度、自プレーヤの第１アカウントリスト５２５と、他プレーヤの第１アカウントリスト５２５とを照合し、互いが相手のアカウントを登録しているか否かの組み合わせに応じた判定をするとしてもよい。
また、第３種アカウントリスト５２７を省略する構成も可能である。
その場合、関係種別を利用する都度、自プレーヤの第１アカウントリスト５２５と第２アカウントリスト５２５とを照合し、両方のアカウントリストに登録しているか否かの組合せに応じた判定をするとしてもよい。

［その２］
また、上記実施形態では、現在時刻との時間差を算出する基準を、各プレーヤのログイン履歴５２３ａに格納される最新アクセス日時としたがこれに限るものではない。逆説的には、アクセス認証時間差Ｔｎ（ｎ＝０，１，２，３）を固定値とせず可変してもよい。

例えば、一回のデータ通信でゲームプレイに必要なデータをある程度まとめてプレーヤ端末１５００へ提供し、プレーヤ端末１５００でのゲームプレイの進め具合に応じて提供されたデータを少しずつ使用・消化していく構成も考えられる。このような構成は、次回のデータ通信を要するまでの期間を稼ぐ構成、すなわちデータ通信の回数を少なくするように工夫された構成と言える。この場合には、最新アクセス日時または直近のログイン日時に、一回のデータ通信の後にゲームプレイが継続されていると見なされる「プレイ継続標準時間」を加えて補正日時を求め、現在時刻とこの補正日時との差とアクティブ認定時間差Ｔｎ（ｎ＝０，１，２，３）を比較する構成が可能である。逆に、アクティブ認定時間差Ｔｎ（ｎ＝０，１，２，３）に「プレイ継続標準時間」を加えて「補正アクティブ認定時間差」を求める構成としてもよい。

前者の構成をより具体的に述べると、例えば図２３に示すように、プレーヤ端末１５００のプレーヤ端末演算部２４０にプレイ継続時間算出部２４６を設ける。プレイ継続時間算出部２４６は、一回のデータ通信終了から次のデータ通信開始までの経過時間を計時し、これをプレイ継続時間５９２として記憶部５００に記憶させる。そして、ログインする毎にプレイ継続時間５９２をサーバシステム１１００へ送信する。

また、図２４に示すように、サーバシステム１１００に、プレイ継続時間受信制御部２０５と、プレイ継続標準時間算出部２１５とを設ける。プレイ継続時間受信制御部２０５は、ログインの都度、プレーヤ端末１５００からプレイ継続時間５９２を受信するように制御し、アカウントデータ５２０内（より望ましくはプレイ履歴データ５２３内）に、受信プレイ継続時間履歴５３０として、受信した時系列順に逐次格納させる。そして、プレイ継続標準時間算出部２１５は、この受信プレイ継続時間履歴５３０から平均値や中央値を算出し、これを当該プレーヤに係るプレイ継続標準時間５３２とし、アカウントデータ５２０に格納する。そして、サーバシステム１１００は、当該プレーヤのアカウントが他プレーヤにとっての同行メンバー選択の対象とされたときには、このプレイ継続標準時間５３２を最新アクセス日時または直近のログイン日時に加えて補正日時を求める。

後者の構成であれば、サーバシステム１１００にアカウント管理部２０２に補正アクティブ認定時間差算出部２１７を設け、アクセス認証時間差Ｔｎ（ｎ＝０，１，２，３）にプレイ継続標準時間統計５３２を加算して、当該「補正アクティブ認定時間差」と、最新アクセス日時から現在時刻までの時間差とを比較すればよい。

なお、プレイ継続標準時間算出部２１５は、サーバシステム１１００ではなくプレーヤ端末１５００に設けることとし、ログイン毎にプレーヤ端末１５００からサーバシステム１１００へプレイ継続標準時間を送信する構成としてもよい。

また、「プレイ継続標準時間」はその他の方法で求めてもよい。
例えばサーバシステム１１００が全プレーヤのログイン履歴５２３ａに基づいて連続プレイ時間（ログインからログアウトまでの時間差）の平均値を算出して、これを用いるとしてもよい。
あるいは、値が所定の低レベル以下になるとゲーム進行が不可能となり、時間経過に応じて所与の上限値まで回復するパラメータ（例えば、公知のソーシャルゲーム等で見られるプレーヤキャラクタの行動に応じて消費される「行動ポイント」「消費ポイント」）が各プレーヤに対応づけられており、他プレーヤの通信日時に、少なくとも当該他プレーヤの当該パラメータが所定値（例えば、プレーヤキャラクタを１回行動させるのに必要な最小値）まで回復する回復時間を加えた時間範囲に基づいて、時間条件を満たす他プレーヤを検索するとしてもよい。

［その３］
また、上記実施形態では、アクティブ認定の際に時間差を算出する方法を用いたが、時間帯に基づいてアクティブ認定する構成も可能である。
具体的には、図２５に示すように、同行メンバー候補検索部２１３にプレーヤのプレイ時間帯を判定するプレイ時間判定部２１９を設ける。そして、本実施形態における同行メンバー候補選択処理を、図２６に示すように変更すればよい。図２６の処理の流れは、基本的には第１実施形態における同行メンバー候補選択処理の流れと同様であるが、アクティブ認定に係るステップＳ１８２（図２１）に代えて、プレイ時間判定部２１９がステップＳ１９０〜Ｓ１９２を実行する。

すなわち、サーバシステム１１００のサーバ処理部２００sは、ループＦの処理対象のアカウントの受信プレイ継続時間履歴５３０（図２５）を参照して、過去所定期間における時間帯別のゲームプレイ確率を算出する（ステップＳ１９０）。「所定期間」は、例えば、１週間であったり、２ヶ月であったり適宜設定可能である。「時間帯」は、例えば０時間を基準に２４時間を２時間区切りにして設定されるが、時間帯の幅は適宜設定可能である。「プレイ確率」は、ゲームプレイをしていた確率（可能性）であり、例えば、０〜１の範囲で定められる。
そして、ループＥの処理対象の関係種別に応じたアクティブ認定時間差Ｔｎ（ｎ＝１，２，３）以内の時間帯におけるプレイ確率が所定の基準値以上であれば（ステップＳ１９２のＹＥＳ）、ステップＳ１９４を実行する。

この構成では、統計的にその時間帯においてプレーヤがゲームをする確率が高ければ、最新アクセス日時に関わらずアクティブ認定をすることができる。例えば、あるプレーヤにとってのお気に入りの他プレーヤが、ここ１週間たまたま仕事で忙しくてゲームプレイできなかったとすると、当該他プレーヤの最新アクセス日時は１週間前となり、関係種別「第３種」に対応するアクティブ認定時間差Ｔ３がいかに他の関係種別よりも大きくとも、１週間はカバーできないかもしれない。その場合、あるプレーヤはお気に入りの他プレーヤのキャラクタを同行メンバーとして利用できなくなる。しかし、時間帯及びプレイ確率に基づくアクティブ認定を行うと、仕事で忙しくなる以前のゲームプレイの傾向から、アクティブ認定されるので、そうした寂しい思いはしなくてすむようになる。

［その４］
関係種別に応じて、アクティブ認定時間差Ｔｎの長さや、同行メンバー選択画面Ｗ６でのアイコン表示の優先順位、同行メンバーとした場合の能力の変更量、ゲーム進行に伴い獲得するものの獲得量、等が順位づけされていることとして説明したが、その順位付けは一例であり、別の順位であってもよいのは勿論である。

２…プレーヤ
４…主人公キャラクタ
５…キャラクタアイコン
６…敵キャラクタ
１０…登録操作アイコン
１１…第１種関係アイコン
１２…第２種関係アイコン
３５…お気に入り解除操作アイコン
３７…サポータ解除操作アイコン
２００ｓ…サーバ処理部
２０２…アカウント管理部
２０３…通信日時管理部
２１０…ゲーム管理部
２１１…アカウントリスト管理部
２１２…登録解除制御部
２１３…同行メンバー候補検索部
２１４…リスト表示制御部
２１５…ゲーム進行制御部
２２２…パラメータ設定部
２２４…個人情報提供部
５００ｓ…サーバ記憶部
５０５…ゲーム管理プログラム
５０６…配信用ゲームクライアントプログラム
５２０…アカウントデータ
５２３…プレイ履歴データ
６５２３ａ…ログイン履歴
５２５…第１種アカウントリスト
５２６…第２種アカウントリスト
５２７…第３種アカウントリスト
５４０…プレイデータ
５５０…同行メンバー候補リスト
Ｗ２…メッセージ掲示画面
Ｗ４…関係一覧画面
Ｗ６…同行メンバー選択画面

Claims (9)

1. プレーヤ端末と通信接続されるサーバシステムであって、
   各プレーヤのプレーヤ端末との通信日時を管理する通信日時管理手段と、
   自プレーヤがお気に入りとして登録した他プレーヤの第１種リストと、自プレーヤのことをお気に入りとして登録している他プレーヤの第２種リストとを、各プレーヤについて管理するリスト管理手段と、
   第１プレーヤと同時又は近時にプレイしている第２プレーヤを検索するための時間条件を満たす他プレーヤを検索する検索手段と、
   前記第１プレーヤのゲームに、前記検索手段により検索された前記第２プレーヤに係るキャラクタを登場させて当該ゲームを進行制御するゲーム進行制御手段と、
   を備え、
   前記検索手段は、前記時間条件を、前記第１プレーヤの前記第１種リスト及び前記第２種リストに前記第２プレーヤが登録されているか否かの組み合わせに応じた時間条件に変更し、変更した時間条件を満たす前記第２プレーヤを、前記第２プレーヤの前記通信日時を用いて検索し、
   前記ゲーム進行制御手段は、ゲーム進行に利用する所定のパラメータの値を、前記第２プレーヤが、前記第１プレーヤの前記第１種リスト及び前記第２種リストそれぞれに登録されているか否かの組み合わせに応じた値に設定するパラメータ設定手段を有し、当該設定されたパラメータの値を用いて前記ゲームを進行制御する、
   サーバシステム。
2. プレーヤ端末と通信接続されるサーバシステムであって、
   各プレーヤのプレーヤ端末との通信日時を管理する通信日時管理手段と、
   自プレーヤがお気に入りとして登録した他プレーヤの第１種リストと、自プレーヤのことをお気に入りとして登録している他プレーヤの第２種リストとを、各プレーヤについて管理するリスト管理手段と、
   第１プレーヤと同時又は近時にプレイしている第２プレーヤを検索するための時間条件を満たす他プレーヤを検索する検索手段と、
   前記第１プレーヤのゲームに、前記検索手段により検索された前記第２プレーヤに係るキャラクタを登場させて当該ゲームを進行制御するゲーム進行制御手段と、
   を備え、
   前記検索手段は、前記時間条件を、前記第１プレーヤの前記第１種リスト及び前記第２種リストに前記第２プレーヤが登録されているか否かの組み合わせに応じた時間条件に変更し、変更した時間条件を満たす前記第２プレーヤを、前記第２プレーヤの前記通信日時を用いて検索し、
   前記ゲーム進行制御手段は、ゲーム進行の報酬に係るパラメータの値を、前記第２プレーヤが、前記第１プレーヤの前記第１種リスト及び前記第２種リストそれぞれに登録されているか否かの組み合わせに応じた値に設定するパラメータ設定手段を有する、
   サーバシステム。
3. プレーヤ端末と通信接続されるサーバシステムであって、
   各プレーヤのプレーヤ端末との通信日時を管理する通信日時管理手段と、
   自プレーヤがお気に入りとして登録した他プレーヤの第１種リストと、自プレーヤのことをお気に入りとして登録している他プレーヤの第２種リストとを、各プレーヤについて管理するリスト管理手段と、
   第１プレーヤと同時又は近時にプレイしている第２プレーヤを検索するための時間条件を満たす他プレーヤを検索する検索手段と、
   前記第１プレーヤのゲームに、前記検索手段により検索された前記第２プレーヤに係るキャラクタを登場させて当該ゲームを進行制御するゲーム進行制御手段と、
   を備え、
   前記検索手段は、前記時間条件を、前記第１プレーヤの前記第１種リスト及び前記第２種リストに前記第２プレーヤが登録されているか否かの組み合わせに応じた時間条件に変更し、変更した時間条件を満たす前記第２プレーヤを、前記第２プレーヤの前記通信日時を用いて検索し、
   前記ゲーム進行制御手段は、前記第２プレーヤが、前記第１プレーヤの前記第１種リスト及び前記第２種リストそれぞれに登録されているか否かの組み合わせに応じてゲーム進行を変更制御する、
   サーバシステム。
4. 前記検索手段は、前記第２プレーヤの通信日時に、少なくとも所与のプレイ継続標準時間を加えて補正日時を求め、当該補正日時が、前記変更した前記時間条件を満たす前記第２プレーヤを検索する、
   請求項１〜３の何れか一項に記載のサーバシステム。
5. 各プレーヤのプレーヤ端末からプレイ継続時間の情報を受信するプレイ継続時間情報受信手段と、
   前記第２プレーヤのプレーヤ端末から受信したプレイ継続時間の情報に基づいて、当該第２プレーヤの前記プレイ継続標準時間を判定する手段と、
   を更に備えた請求項４に記載のサーバシステム。
6. 値が所定の低レベル以下になるとゲーム進行が不可能となり、時間経過に応じて所与の上限値まで回復する時間経過回復パラメータが各プレーヤに対応づけられており、
   前記検索手段は、前記第２プレーヤの通信日時に、少なくとも当該第２プレーヤの前記時間経過回復パラメータが所定値まで回復する回復時間を加えた時間範囲に基づいて、前記変更した前記時間条件を満たす前記第２プレーヤを検索する、
   請求項１〜５の何れか一項に記載のサーバシステム。
7. 各プレーヤのプレイ時間帯を判定するプレイ時間帯判定手段を更に備え、
   前記検索手段は、前記第２プレーヤのプレイ時間帯を用いて前記時間条件を満たす前記第２プレーヤを検索する、
   請求項１〜３の何れか一項に記載のサーバシステム。
8. 前記リスト管理手段は、自プレーヤと他プレーヤとが相互にお気に入りとして登録している第３種リストを各プレーヤについて更に管理し、
   前記検索手段は、前記第２プレーヤが、前記第１プレーヤの前記第３種リストに登録されている場合には、前記第１プレーヤの前記第１種リスト或いは前記第２種リストのみに登録されている場合よりも広い時間範囲の条件に前記時間条件を変更する、
   請求項１〜７の何れか一項に記載のサーバシステム。
9. 前記検索手段は、前記第２プレーヤが、前記第１プレーヤの前記第１種リストに登録されているが前記第２種リストに登録されていない場合には、当該第１種リスト及び当該第２種リストの双方に登録されていない場合よりも広い時間範囲の条件に前記時間条件を変更する、
   請求項１〜８の何れか一項に記載のサーバシステム。

Images