JP2020022892A - サーバシステム及びプログラム - Google Patents

Abstract

【課題】 団体に所属するプレーヤを除名するための新たな仕組みの提案。【解決手段】 複数のプレーヤ２（２ａ、２ｂ、…）でギルドを構成する。ギルドには所属プレーヤが遵守するべきプレイ規範としての「ギルドルール」を設定できる。プレーヤ２の行動は記憶されており、所属するギルドルールに違反していないか審査される。ギルドルールに違反したプレーヤ２ｃは自動的に所属するギルドから除名される。除名が自動化されるので、除名する側のプレーヤに心的な負担が生じない。【選択図】 図４

Description

本発明は、各プレーヤのプレーヤ端末が通信接続可能に構成され、複数のプレーヤが所属可能な団体を設定して当該団体を管理するサーバシステム等に関する。

マルチプレーヤタイプのゲームでは、複数のプレーヤで「チーム」や「パーティ」「ギルド」などと呼ばれる団体を登録し、団体単位でプレイする所謂チームプレイが可能なものが知られている。団体登録してのマルチプレイは仲間意識を抱きやすく、共通の目標を協力して達成する醍醐味もひとしおであり、人気の秘訣となっている。

しかし、団体登録にもデメリットがあることが認識されている。例えば、現実世界で友達同士であるプレーヤ同士がその関係のままゲーム世界でも団体を構成する場合は問題ないが、ほとんどお互いを知らないプレーヤ同士で団体を構成する場合は、プレイスタイルの違いによってお互いの連係がとれず、互いに不本意なチームプレイを強いられる事態も起こり得る。例えば、みんなでまとまって積極的に攻撃を仕掛けることでスピード感を持ってゲームを進めるスタイルを好むプレーヤが集まった団体に、気が向いた時にだけ攻撃するといったのんびりと攻略することを好むプレーヤが加わった場合、当該プレーヤが他のプレーヤの足を引っ張ってしまうケースが一例である。こうした場合、プレイスタイルの異なるプレーヤを除名処分として団体を抜けてもらうのが良策であるが、除名権を有するプレーヤ（例えば、チームリーダや、ギルドマスターと呼ばれる団体代表プレーヤ）に心的な負担をかけることになる。

そうした問題を解決するべく、例えば、特許文献１では、団体に所属していながら長期にわたって団体でのプレイに参加していない疎遠なプレーヤの所属を、他の所属プレーヤの多数決で解除可能にする技術が開示されている。

特開２００２−３２５９７５号公報

特許文献１に開示された技術でも、除名する側のプレーヤの心的負担をずいぶん軽減できるがまだ十分とはいえない。また、除名のためにプレーヤ自身が介在する必要がある点は変わっておらず、除名されたプレーヤに、仲間はずれ的に理不尽な除名を受けたとの印象をもたれる余地が残り得た。

本発明はこうした問題を解決するために考案されたものであり、除名する側のプレーヤの心的負担を少なくした、団体に所属するプレーヤを除名するための技術的な新たな仕組みを提供することを目的とする。望ましくは更に、除名される側のプレーヤも納得し易い除名の仕組みを実現し、除名される側の心的負荷を軽減することを目指す。

上述した課題を解決するための第１の発明は、各プレーヤのプレーヤ端末が通信接続可能に構成され、複数のプレーヤが所属可能な団体（例えば、図３のギルド）を設定して当該団体を管理するサーバシステムであって、当該団体に所属した場合に守るべきプレイ規範のルール（例えば、図４，５のギルドルール）を設定するルール設定手段（例えば、図７のサーバ処理部２００ｓ、ゲーム管理部２１０、ギルドルール設定部２２２、図１３のギルドルール設定データ６５０、図１５のステップＳ２６）と、
当該団体に所属する所属プレーヤのプレイ履歴と前記ルールとを比較して、当該所属プレーヤがルール違反に該当するか否かを審査する審査手段（例えば、図７のサーバ処理部２００ｓ、ゲーム管理部２１０、審査部２３０、図１７のステップＳ２０４）と、
前記審査手段によりルール違反と判断された場合に、当該所属プレーヤの当該団体への所属を解除する解除手段（例えば、図７のサーバ処理部２００ｓ、ゲーム管理部２１０、自動除名制御部２３４、図１７のステップＳ２１０、Ｓ２１４）と、
を備えたサーバシステムである。

本発明によれば、ギルドの所属プレーヤが守るべきルールを設定しておいて、ルールに違反した者の団体所属を自動的に解除し、団体から除名することができる。除名が自動化されていることから、除名する際にプレーヤが介在する必要がなく、除名することへの心的負担もなくなる。また、ルールに則って除名されるので、除名される側も納得しやすい。

第２の発明は、前記プレーヤ端末から当該団体への所属依頼を受け付けた場合に、当該プレーヤ端末のプレーヤを当該団体の所属プレーヤとして登録する所属登録手段（例えば、図７のサーバ処理部２００ｓ、ゲーム管理部２１０、ギルド所属登録部２２６、図１５のステップＳ１０６〜Ｓ１０８）、を更に備えた第１の発明のサーバシステムである。

また、第３の発明は、前記ルール設定手段により設定されたルールを含む当該団体の紹介情報を前記プレーヤ端末に送信する紹介情報送信手段（例えば、図７のサーバ処理部２００ｓ、ゲーム管理部２１０、ギルド情報提供制御部２２４、図１５のステップＳ１００〜Ｓ１０４）、を更に備えた第２の発明のサーバシステムである。

また、第４の発明は、前記所属登録手段が、前記紹介情報送信手段により送信された前記紹介情報が前記プレーヤ端末で表示された場合にのみ、当該紹介情報に係る団体への所属依頼を受け付け可能とする制御を行う、第３の発明のサーバシステムである。

第２〜第４の発明によれば、団体への所属依頼をする前に、所属を希望する団体に設定されたルールを確認することができる。ルールの内容を知った上で所属依頼をし、そのルールを違反したという理由で除名されるため、除名に納得し易く、除名された理由にあれこれ無用な思いを巡らせる必要もなく、心的負荷を負うことが無い。

第５の発明は、前記ルール設定手段が、当該団体の代表プレーヤの選択操作に従って複数のルール要素の中からルール要素を選択して前記ルールを設定する、第１〜第４の何れかの発明のサーバシステムである。

第５の発明によれば、ルールの設定権を代表プレーヤに与えることで、ルールの内容の公平性を担保できる。また、ルールの内容を複数のルール要素を組み合わせて構成できるので簡単にルールを設定することができる。

第６の発明は、前記複数のルール要素には数値条件を含むルール要素が含まれ、前記ルール設定手段は、前記代表プレーヤの指示操作によって、数値条件を含むルール要素の当該数値条件を設定する、第５の発明のサーバシステムである。

第６の発明によれば、同じルール要素であっても違反審査に係る数値条件も設定可能となるので、ルールの客観性および多様なルール作りを簡単に実現することができる。

第７の発明は、前記ルール設定手段が、当該団体に係るゲームパラメータに基づいて、複数の前記ルール要素の中から、前記ルールとして設定可能なルール要素の候補を抽出する、第１〜第６の何れかの発明のサーバシステムである。

第７の発明によれば、団体に係るゲームパラメータに応じて適切なルール要素を候補として抽出することで、例えば初心者ばかりの団体なのに上級者向けルールが設定されてしまう事態を未然に防ぐ事が可能となる。

第８の発明は、前記ルール設定手段が、当該団体の所属プレーヤの投票によって、前記ルールを設定変更する手段を有する、第１〜第７の何れかの発明のサーバシステムである。

第８の発明によれば、ルールを所属メンバーの合意に基づいて設定することができる。

第９の発明は、前記審査手段が、当該ルール違反に該当する前の警告状況に該当するか否かを審査する手段を有し、前記警告状況に該当すると判断された場合に、当該所属プレーヤのプレーヤ端末に警告通知を行う警告通知手段（例えば、図７のサーバ処理部２００ｓ、ゲーム管理部２１０、警告通知制御部２３２、図１７のステップＳ２０６）を更に備えた、第１〜第８の何れかの発明のサーバシステムである。

第９の発明によれば、自動的に除名される前に警告をすることができる。よって、本人が気づかぬうちに意図せずルール違反状態になってしまっている場合に、自主的にこれを改善し除名を逃れる機会を与えることができる。

第１０の発明は、前記所属プレーヤが前記ルール違反に該当すると判断された数が所定の数値条件を満たした場合に、当該団体を公表する制御を行う公表制御手段（例えば、図７の公表制御部２５２、図１７のステップＳ２２０）を更に備えた、第９の発明のサーバシステムである。

第１０の発明によれば、ルール違反者の数が多すぎる団体など、違反者数が特徴的な団体を抽出して公表することができる。

第１１の発明は、前記団体の所属プレーヤのプレーヤ端末が、所与のマルチプレイゲームをプレイ可能に構成されており、前記ルール設定手段は、前記マルチプレイゲームにおける貢献度を前記ルール要素として前記ルールを設定する、第５又は第６の何れかの発明のサーバシステムである。

第１１の発明によれば、チームプレイにおけるチームへの貢献の度合をルールの要素に含めることができる。よって、団体に所属していながら個人主義的なプレイをする傾向のあるプレーヤを除名できるルールが構成できるようになる。

第１２の発明は、前記ルール設定手段が、前記マルチプレイゲームにおける参加度を前記ルール要素として前記ルールを設定する、第１１の発明のサーバシステムである。

第１２の発明によれば、所属プレーヤが団体としてのプレイに参加している程度をルールの要素に含めることができる。よって、所謂“さぼり”の多いプレーヤを除名できるルールが設定可能になる。

第１３の発明は、当該団体の所属プレーヤのうちの所与の人数が前記審査手段によりルール違反と判断された場合に、前記代表プレーヤの当該団体への所属を解除する代表プレーヤ解除手段（例えば、図７のサーバ処理部２００ｓ、ゲーム管理部２１０、ギルドマスター強制解任部２５０、図１７のステップＳ２３０〜Ｓ２３４）、を更に備えた第１〜第１２の何れかの発明のサーバシステムである。

第１３の発明によれば、ルールの設定者である代表プレーヤが不適当である場合に当該代表プレーヤを解任することができる。

第１４の発明は、前記審査手段によりルール違反の対象とされていない期間及び／又は人数に基づいて、前記所属プレーヤに所与のボーナスを付与する処理を実行するボーナス付与手段（例えば、図７のサーバ処理部２００ｓ、ゲーム管理部２１０、除名ゼロ期間基準ボーナス付与部２４４、図１７のステップＳ２１８）、を更に備えた第１〜第１３の何れかの発明のサーバシステムである。

第１４の発明によれば、所属プレーヤのルールを遵守しようとする気持ちに対してボーナスを付与することができる。

第１５の発明は、各プレーヤのプレーヤ端末が通信接続可能に構成されたコンピュータシステムに、複数のプレーヤが所属可能な団体を設定して当該団体を管理させるためのプログラムであって、当該団体に所属した場合に守るべきプレイ規範のルールを設定するルール設定手段、当該団体に所属する所属プレーヤのプレイ履歴と前記ルールとを比較して、当該所属プレーヤがルール違反に該当するか否かを審査する審査手段、前記審査手段によりルール違反と判断された場合に、当該所属プレーヤの当該団体への所属を解除する解除手段、として機能させるためのプログラムである。

第１５の発明によれば、コンピュータシステムに第１の発明と同じ作用効果を発揮させることができる。

ゲームシステムの構成の一例を示す図。 プレーヤ端末の構成例を示す正面外観図。 ゲーム内容について説明するための図。 ギルド別のルールの設定について説明する図。 ギルドルール設定画面の例を示す図。 参加申し込み画面の例を示す図。 サーバシステムの機能構成例を示す機能ブロック図。 サーバ記憶部が記憶するプログラムやデータの例を示す図。 ゲームステージ初期設定データのデータ構成例を示す図。 ルール要素定義データのデータ構成例を示す図。 ユーザ登録データのデータ構成例を示す図。 プレーヤチーム編成データのデータ構成例を示す図。 ギルド編成データのデータ構成例を示す図。 プレイデータのデータ構成例を示す図。 サーバシステムによる主たる処理の流れについて説明するためのフローチャート。 図１５より続くフローチャート。 図１６より続くフローチャート。 ギルドルール設定処理の流れを説明するためのフローチャート。

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

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

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

そして、本実施形態のゲームに関する機能として、アカウント登録やログイン／ログアウトに関係する処理を担うアカウント管理機能と、プレーヤ端末１５００にてゲームをプレイするのに必要なデータを随時管理・配信するゲーム管理機能と、を有する。ゲーム内で利用できるアイテム等（アイテムやキャラクタなど）をオンラインショッピングで提供するオンラインショッピング管理機能を更に有するとしてもよい。

図１の例では、サーバシステム１１００は単体として記されているがこれに限らない。たとえば、サーバシステム１１００が複数のブレードサーバを有して構成され、アカウント管理機能やゲーム管理機能などを別々のブレードサーバに分担させ、相互に内部バスを介してデータ通信可能に接続する構成であってもよい。或いは、通信回線Ｎを介して離れた場所に設置された独立した複数のサーバをデータ通信させることで、全体としてサーバシステム１１００として機能させる構成であってもよい。

なお、サーバシステム１１００は通信回線Ｎを通じて、プレーヤ端末１５００以外の装置とも通信をすることができる。例えば、課金処理を担う外部サーバと通信することもできる。

図２は、プレーヤ端末１５００の構成例を示す正面外観図である。
プレーヤ端末１５００は、通信回線Ｎに接続してサーバシステム１１００にアクセスすることができるコンピュータであり電子装置（電子機器）である。本実施形態のプレーヤ端末１５００はいわゆるスマートフォンとして分類される小型コンピュータを想定しているが、携帯型ゲーム装置、据置型家庭用ゲーム装置、据置型家庭用ゲーム装置のゲームコントローラ、業務用ゲーム装置、パソコン、タブレット型コンピュータ、腕時計型やメガネ型等のウェアラブルコンピュータ、などに分類される装置で実現してもよい。

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

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

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

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

［ゲーム内容の説明］
図３は、本実施形態のゲーム内容について説明するための図である。
本実施形態のゲームは、マルチプレイオンラインゲームに分類されるＲＰＧ（ロールプレイングゲーム）であって、プレーヤ２（２ａ、２ｂ、２ｃ、…）は複数人で「ギルド」を構成し、ギルド単位でゲームステージを攻略して遊ぶ。
ここで言う「ギルド」とは、ゲーム世界での団体の呼び名であって、その他の呼び名、例えば「パーティ」「同盟」「チーム」「軍団」「組」等であっても良い。図示の例では、３名で１つのギルドを構成しているが構成人数は問わない。

ゲーム画面例Ｗ２に示すように、ゲームステージには、例えばプレーヤ単独では到底倒せない強力な敵キャラクタ６（ＮＰＣ：ノンプレーヤキャラクタ）が設定されていて宝を守っている。同じギルドに所属するプレーヤ２（２ａ，２ｂ，２ｃ）は、それぞれプレーヤ端末１５００（１５００ａ，１５００ｂ，１５００ｃ）を使い、それぞれが設定したプレーヤチーム３（３ａ，３ｂ，３ｃ）を操作して敵キャラクタ６と交戦し、これを排除して宝を獲得することを目指す。ゲームステージの内容は、これに限らず、他のギルドと対戦するなどでもよい。

１つのプレーヤチーム３は、１体以上のプレーヤキャラクタ４で構成され、アイテムを適宜装備して自由に編成することができる。ゲーム内容によってはプレーヤチーム３を「デッキ」と呼んでもよい。図２の例では、１チーム２体のプレーヤキャラクタ４で構成しているが、構成数は適宜設定可能である。また、プレーヤチーム３を構成するプレーヤキャラクタ４の一部はＮＰＣ（ノンプレーヤキャラクタ）とする構成も可能である。

図４は、本実施形態におけるギルド別のルールの設定について説明する図である。
本実施形態では、ギルド別に、当該ギルドに所属するプレーヤ２が守るべきプレイ規範である「ギルドルール」を設定することができる。そして、ゲームシステム上、各プレーヤの行動は記録されており、それを元に所属ギルドのギルドルールに違反している状態が自動的に検出される。

もし、ギルドルールに違反している状態が検出されると、該当するプレーヤ（図４の例ではプレーヤ２ｃ）のプレーヤ端末１５００ｃにて警告が発せられる。それでもなお違反が検出され続けると、当該プレーヤは自動的に当該ギルドへの所属を解除される。すなわち、ギルドから除名される。

従来のギルドシステムをサポートするマルチプレイオンラインゲームでは、ギルドマスター（ギルドの代表者。大抵はギルドの設立プレーヤがなる。）の権限によって手動でメンバーの除名を行う仕組みである。しかし、この場合、ギルドマスターに心的な負担を強いることになるが、本実施形態のギルドシステムでは除名は自動的に実行されるのでその心的負担は無くなる。

本実施形態においては、ギルドマスターが、ギルドルールを設定・編集することができる。
図５はギルドルール設定画面Ｗ４の例を示す図である。ギルドルール設定画面Ｗ４には、ギルド名入力欄２１と、ギルドマスターアカウント入力欄２２と、ギルドルール編集用のパスワードを入力する編集用パスワード入力欄２３と、ルール要素メニュー２４と、ギルドルール設定欄２５と、適用期間設定欄２６と、設定完了操作アイコン２７と、キャンセル操作アイコン２８とが表示される。

ギルドルールは、単数又は複数のルール要素で構成することができる。ルール要素メニュー２４には、選択可能なルール要素別にルール要素パネル３０（３０ａ，３０ｂ，…）がスクロール表示される。ギルドマスターは、ルール要素メニュー２４に表示されているルール要素パネル３０（３０ａ，３０ｂ，…）をギルドルール設定欄２５へドラッグ・アンド・ドロップ操作することで、当該パネルに記されたルール要素をギルドルールに含めさせることができる。逆に、ギルドルール設定欄２５に表示されているルール要素パネル３０を欄外にドラッグ・アンド・ドロップ操作することで当該パネルのルール要素をギルドルールから抹消することができる。図５の例は、ルール要素パネル３０ａ及びルール要素パネル３０ｂをギルドルールに含める様に設定した状態に相当する。

ルール要素には、当該ルール要素に違反していることを検出するための数値条件となる規程値を設定する項目があり、数値条件の値を設定するためのプルダウンメニュー表示アイコン３１が付属する。そして、このプルダウンメニュー表示アイコン３１で数値条件の値を指示操作して設定すると、設定された数値が数値条件表示部３２に表示される。

また、ルール要素には大きく「絶対ルール」と「加点ルール」の２区分がある。各ルール要素パネル３０には、区分表示３３が含まれており、表示されている区分の識別を頼りにギルドルールに含めるか否かを判断することができる。

絶対ルールは、それ単独でも違反すると自動的に除名が行われるルール要素である。

加点ルールは、違反する毎に違反点数が加算され、合計が所与の上限値に達すると自動的に除名が行われるルール要素である。ギルドルール設定欄２５に加点ルールのルール要素パネル３０が含まれる場合、当該設定欄には違反点上限値設定欄３４が出現し、プルダウンメニュー表示アイコン３１で上限値の指示操作をして設定することができるようになる。

設定完了操作アイコン２７をタッチ操作すれば、ギルドルール設定欄２５で定義されたルール要素で構成されたギルドルールが登録される。キャンセル操作アイコン２８をタッチ操作すれば、それまでの作業内容は破棄され作業前の状態に復元されて、ギルドルール設定画面Ｗ４が閉じられる。

なお、ルール要素メニュー２４に表示されるルール要素は、必ずしも要素別である必要はなく、複数のルール要素のセット、更には規程値や違反点上限値も予め定められた状態のセットがパッケージされたものを含めることができる。本実施形態では、これを「プリセットルールパッケージ」と呼ぶ。
また、ギルドルールは、ルール要素を全く含んでいない状態、すなわち実質的なルール無しの状態でもよい。ギルドを設定した当初はこれに該当するので、ギルドマスターが適宜ギルドルール設定画面Ｗ４を呼び出してルール要素を内包するギルドルールを設定することができる。勿論、設定後にも任意に編集・改訂することができる。

ギルドルールの内容は、プレーヤに適宜開示される。
例えば、図６は、ギルドへの参加申し込み手続き、すなわちギルドへの所属依頼をするための参加申し込み画面Ｗ６の例を示す図である。参加申し込み画面Ｗ６には、ギルドメンバーを募集しているギルドの代表情報をスクロール表示するギルド情報表示部４０と、ギルド情報表示部４０で選択されているギルドの紹介コメント表示部４２と、ギルド情報表示部４０で選択されているギルドのギルドルールをスクロール表示するギルドルール開示部４４と、参加申し込み手続きの実行操作を入力する所属依頼操作アイコン４６と、キャンセル操作アイコン４８とが含まれる。

どこかのギルドへの所属を考えているプレーヤは、所定操作で参加申し込み画面Ｗ６を表示させ、先ずはギルド情報表示部４０で表示される代表情報を頼りに、気になるギルドを選択する。そして、紹介コメント表示部４２とギルドルール開示部４４を参照して、希望するギルドのイメージに合致すれば、所属依頼操作アイコン４６を操作して、参加申し込み手続きを実行させる。

このように、参加申し込み画面Ｗ６では、所属を希望するギルドのギルドルールを予め知ることができる。よって、プレーヤは自分が遵守するべきルールを納得した上で、ギルドへ所属することができる。

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

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

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

そして、本実施形態のサーバ処理部２００ｓは、アカウント管理部２０１と、ゲーム管理部２１０と、画像生成部２７２ｓと、通信制御部２７４ｓとを含む。

アカウント管理部２０１は、ユーザ登録手続きに係る処理と、ログインに関する処理とを行う。すなわち、登録手続きを経たユーザすなわちプレーヤに対して固有のアカウントを発給し、ユーザ登録データ６００（図８参照）をサーバ記憶部５００ｓに記憶させてその管理を行う。

ゲーム管理部２１０は、ゲームの実行に関する各種処理を実行する。
本実施形態では、所有オブジェクト管理部２１４と、プレーヤチーム編成部２１６と、ギルド設立部２２０と、ギルドルール設定部２２２と、ギルド情報提供制御部２２４と、ギルド所属登録部２２６と、審査部２３０と、警告通知制御部２３２と、自動除名制御部２３４と、除名履歴記憶制御部２３６と、ゲーム進行制御部２４０と、ルール内容基準ボーナス付与部２４２と、除名ゼロ期間基準ボーナス付与部２４４と、プレイ履歴記憶制御部２４６と、ギルドマスター強制解任部２５０と、公表制御部２５２と、を有する。

所有オブジェクト管理部２１４は、プレーヤが入手したオブジェクトをプレーヤのアカウントと対応づけて管理する。本実施形態では、プレーヤキャラクタ４（４ａ，４ｂ，…：図３参照）や、プレーヤキャラクタ４に装備させることのできるアイテムなどのオブジェクトが存在するが、ゲーム内容に応じてオブジェクトの種類や内容は適宜設定することができる。

プレーヤチーム編成部２１６は、プレーヤチーム３（図３参照）の編成に係る制御を行う。例えば、プレーヤ端末１５００にて所定のチーム編成操作の入力を検出すると、プレーヤが所有するオブジェクトの一覧をプレーヤ端末１５００にて表示させて、プレーヤキャラクタ４とするオブジェクトの選択操作を受け付ける。また、同時にオブジェクトの一覧から装備させるアイテムの設定操作も受け付ける。そして、それらの操作入力の結果に応じて、プレーヤアカウントと対応づけてプレーヤチーム３の編成情報を記憶制御する。

ギルド設立部２２０は、ギルドの設定に関する制御を行う。例えば、プレーヤ端末１５００にて所定のギルド設立操作が入力されたのを検出すると、ギルド名と、ギルドマスターアカウントと、ギルドルール設定時の認証に必要な編集用パスワードと、ギルドの紹介コメントなどの情報を入力する画面をプレーヤ端末１５００にて表示させる。そして、当該画面での入力結果に応じて、新たなギルドを設定登録する。

ギルドルール設定部２２２は、ギルドルールの設定に関する制御を行う。本実施形態ではギルドルール設定画面Ｗ４（図５参照）をプレーヤ端末１５００にて表示させ、ギルド名と対応づけて当該画面での入力結果に応じたギルドルールの定義データを生成・登録制御する。また、本実施形態では、数値条件を含む加点ルールにカテゴリされるルール要素がギルドルールに設定される場合には、その数値条件の指示操作に応じてその値を設定することができる。

ギルド情報提供制御部２２４は、ギルドルールを含むギルドに関する各種情報をプレーヤに提供する制御を行う。本実施形態では、プレーヤ端末１５００に参加申し込み画面Ｗ６（図６参照）を表示させるために必要な情報に、ギルドルールを含むギルドに関する各種情報を含めて送信制御することで、その一部を実現する。

ギルド所属登録部２２６は、プレーヤ端末１５００からギルドへの参加申し込みのリクエスト、すなわち所属依頼を受け付けた場合に、当該プレーヤ端末のプレーヤを希望するギルドへの所属プレーヤとして登録する手続きに関する制御を行う。

審査部２３０は、ギルド毎に、当該ギルドに所属する所属プレーヤのプレイ履歴と当該ギルドのギルドルールとを比較して、当該所属プレーヤがルール違反に該当するか否かを審査する。換言すると、所属プレーヤの違反状態を検出する。
本実施形態のギルドルールは、単独又は複数のルール要素で構成されるので、審査部２３０は、ルール要素それぞれの適否に基づいて、所属プレーヤがルール違反に該当するか否かを審査することになる。

警告通知制御部２３２は、審査部２３０による審査結果に応じて、該当するプレーヤのプレーヤ端末１５００にて警告通知を行わせる制御をする。本実施形態では、ルール違反に該当する場合と、ルール違反に該当する前の警告条件（例えば、加点ルール別の数値条件の９０％に到達）を満たす場合とにおいて警告通知を行うように制御する。

自動除名制御部２３４は、審査部２３０によりルール違反と判断されたプレーヤを、所属するギルドから強制的に且つ自動的に除名処理する。つまり、違反と判断された所属プレーヤの団体への所属を自動的に解除する。

除名履歴記憶制御部２３６は、自動除名制御部２３４により自動的に除名された履歴をギルド毎に記憶・管理する制御を行う。

ゲーム進行制御部２４０は、ゲームの進行制御を行う。
本実施形態では、ゲーム世界に用意されたチャットルームなどの所定の集合場所にギルドメンバーを集め、プレイするゲームステージをギルドマスターが選択操作すると、選択されたゲームステージで、ギルドマスターを含む集まったギルドメンバーがマルチプレイオンラインＲＰＧに参加してゲームを行う。ゲーム進行制御部２４０は、このゲーム進行を制御する。

ルール内容基準ボーナス付与部２４２は、ゲーム進行制御の対象とされるギルドのギルドルールが所定条件を満たす場合に、当該ギルドに有利なようにボーナスを付与する制御を行う。
ここで言う「所定条件」は適宜設定可能であるが、本実施形態ではギルドルールの設定が厳格であることを意味する所定の厳格条件を満たす場合を意味する。「厳格条件」は、例えば、ルール内容が厳しくなるように設定した“プリセットルールパッケージ”がギルドルールに設定されている場合や、加点ルールに属するルール要素別に数値条件の閾値を用意しておいて当該閾値を超えるルール要素の数が所定数に達した場合、加点ルールに属するルール要素１つ当たりの違反点上限値が基準値未満である場合、などとすることができる。

そして、例えばゲームステージに伴い付与されるアイテム等の種類を選択する抽選処理において、基準以上のレアリティが設定されたアイテムの当選確率を上げたり、ギルドメンバーのプレーヤキャラクタ４の能力パラメータ値を一次的に向上させるなどのボーナスを付与する。

除名ゼロ期間基準ボーナス付与部２４４は、除名履歴記憶制御部２３６により記録される除名履歴に基づいて、除名者がゼロの連続期間の日数に応じてギルド又はギルドメンバーにボーナスを付与する。
具体的には、連続期間の日数に段階的な基準（例えば、３０日、９０日、１２０日、…）を設け、より長期であるほどプレーヤに有利なボーナスを付与する。ボーナスの内容は、ボーナスアイテムの付与や、アイテムの有料抽選の抽選権の付与、隠しゲームステージへの挑戦権、広く豪華なチャットルームの使用権、など、ゲーム内容に応じて適宜設定可能である。また、ボーナスの付与対象は、ギルド全体や、ギルドメンバー個別としてもよいし、ギルドマスターに限って付与するとしてもよい。
なお、除名ゼロは、違反ゼロに置き換えることができる。すなわち、審査部２３０によりルール違反の判定がされない期間に応じてボーナスを付与する構成とすることもできる。または、基準数は「ゼロ」に限らず「２名未満」と言った具合に少数からなる幅を設定することもできる。

プレイ履歴記憶制御部２４６は、プレーヤ毎のプレイ履歴の記録・管理に係る制御を行う。

ギルドマスター強制解任部２５０は、所定のギルドルール管理不適格を意味する不適格条件を満たす場合に、ギルドマスターを強制的に解任する。
具体的には、「不適格条件」は、例えば、除名履歴記憶制御部２３６により管理される除名履歴において所定のサンプリング期間（例えば、過去２週間）の除名者総数や、当該除名者総数のギルドメンバー数当たりの比率が所定の上限値に達した場合とすることができる。また、審査部２３０にて一度のステージプレイで違反と判定されたギルドメンバー数が所定の基準値以上に達した場合とすることもできる。また、ギルドマスターのプレイ頻度が基準値以下である場合も含めることができる。勿論、これら以外の内容も適宜含めることができる。

公表制御部２５２は、所属プレーヤがルール違反に該当すると判断された数が所定の数値条件を満たした場合に、当該団体を公表する制御を行う。本実施形態では、その時点でプレイ中の全てのゲーム画面内にテキストメッセージ形式で団体名を表示させるとしてもよい。
勿論、これ以外の方法で公表するとしてもよい。例えば、プレーヤ毎に登録している電子メールアドレスに、団体名を含むメールを送信するとしてもよいし、参加申し込み画面Ｗ６（図６参照）のギルド情報表示部４０にて、該当するギルド名を特別な表示形態で表示させたり、注意を促す特別なバッジをギルド名に添付表示させるとしてもよい。

画像生成部２７２ｓは、サーバシステム１１００の保守に関する画像等を生成し、画像表示部３７２ｓへ出力することができる。

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

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

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

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

図８は、本実施形態におけるサーバ記憶部５００ｓが記憶するプログラムやデータの例を示す図である。サーバ記憶部５００ｓは、サーバシステムプログラム５０１と、アカウント管理プログラム５０３と、ゲーム管理プログラム５０５と、プレーヤ端末１５００へ配信するための配信用ゲームプログラム５０７とを予め記憶する。
また、ゲームステージ初期設定データ５１０と、キャラクタ初期設定データ５３０と、アイテム初期設定データ５４０と、ルール要素定義データ５５０と、ユーザ登録データ６００と、ギルド編成データ６４０と、プレイデータ７００と、を記憶する。その他、タイマやカウンタ、各種フラグなどの情報を適宜記憶できる。

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

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

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

配信用ゲームプログラム５０７は、プレーヤ端末１５００へ複製して提供されるゲームプログラムのオリジナルである。
ゲームプログラムは、例えば、専用のプログラムとして実現してもよい。あるいは、本実施形態のゲームをウェブゲームとして実現するならば、ウェブブラウザをベースとしてＨＴＭＬとともにＪａｖａ（登録商標）やＣＳＳ（Cascading Style Sheets）等を利用して能動的に画面表示を制御するウェブ技術や、Adobe（登録商標） Flashなどのプラグインを用いて実現できる。勿論、その他の方法でもかまわない。

プレーヤ端末１５００は提供されたゲームプログラムを実行することにより、１）操作入力に応じてサーバシステム１１００へゲームをプレイするための各種リクエスト情報を送信する機能と、２）サーバシステム１１００から受信したデータに基づいて端末上でゲームの進行制御をする機能と、３）サーバシステム１１００から受信したデータに基づいてゲームプレイ画面や各種設定入力画面（本実施形態では、ギルドルール設定画面Ｗ４（図５参照）や参加申し込み画面Ｗ６（図６参照））などをタッチパネル１５０６に表示させる機能と、４）操作入力に応じた信号をサーバシステム１１００へ送信する制御を実現できる。つまり、プレーヤ端末１５００をマンマシンインターフェースの装置にする機能を実現できる。

ゲームステージ初期設定データ５１０は、ゲームステージ毎に用意され、当該ゲームステージをプレイするのに必要な各種初期設定データを格納している。
例えば、図９に示すように、ステージＩＤ５１１と、難易度５１３と、敵キャラクタ６を特定するための敵キャラクタＩＤ５１５と、敵キャラクタ属性５１７と、相性データ５２０とを含む。その他、１）ゲームの舞台となるゲーム空間を構成・表示するための背景オブジェクトの初期設定データや、２）敵キャラクタ６の出現条件・出現数・出現位置・行動パターンなどを定義するデータ、３）敵キャラクタ６がドロップするオブジェクトの候補とするオブジェクトＩＤリスト、等を含む。勿論、ゲーム内容に応じてこれら以外の初期設定データも適宜含めることができる。

敵キャラクタ属性５１７は、敵キャラクタ６のゲーム内における能力の特徴を表す分類である。本実施形態では、火・水・木の３つの要素が三竦みの関係で設定されている。キャラクタ属性は、プレーヤキャラクタ４として設定できるキャラクタオブジェクトにもそれぞれ割り当てられている。また、同様の属性は、プレーヤキャラクタ４が装備することのできるアイテムにもアイテム属性として設定されている。

相性データ５２０は、当該ゲームステージを攻略するためのアドバイスやヒントに相当する。
例えば、プレーヤキャラクタ４に装備させるべきアイテムを示す推奨アイテムＩＤリスト５２１と、プレーヤキャラクタ４とされるキャラクタが備えるべきキャラクタ属性を示す推奨キャラクタ属性５２３と、プレーヤチーム３における推奨キャラクタ属性５２３が示すキャラクタ属性を有したプレーヤキャラクタ４の占有率の下限値を示す推奨キャラクタ属性占有率５２５、などを含む。勿論、これら以外のデータも適宜格納することができる。

図８に戻って、キャラクタ初期設定データ５３０は、ゲームに登場するキャラクタのオブジェクト毎に用意され、当該キャラクタの初期状態を定義する。１つのキャラクタ初期設定データ５３０は、例えば、キャラクタＩＤと、キャラクタ属性と、初期能力パラメータ値リストと、を含む。その他、当該キャラクタを画面に表示させ、動作させるためのモデルデータやテクスチャデータ、モーションデータなどが適宜含まれているものとする。

アイテム初期設定データ５４０は、ゲームに登場するアイテムとなるオブジェクト毎に用意され、当該アイテムの初期状態を定義する。プレーヤキャラクタ４に装備させることのできる武器などのアイテムも対象となる。１つのアイテム初期設定データ５４０は、例えば、アイテムＩＤと、アイテム属性と、初期能力パラメータ値リストと、を含む。アイテム属性は、キャラクタ属性に準じる分類である。その他、当該アイテムを画面に表示させ、動作させるためのデータなどが適宜含まれているものとする。

ルール要素定義データ５５０は、ギルドルールを構成することのできるルール要素を定義する。例えば、図１０に示すように、手動設定用ルール要素データ５５１と、禁止用語リスト５５７と、プリセットルールパッケージデータ５５８とを含む。

手動設定用ルール要素データ５５１は、ギルドマスターが手動で個別に選択可能なルール要素を定義する。例えば、ルールＩＤ５５２と対応づけて、「絶対ルール」又は「加点ルール」の何れかの区分５５３と、規範内容５５４と、違反点５５５とを格納する。勿論、これら以外のデータも適宜対応づけて格納することができる。

禁止用語リスト５５７は、ゲーム内のチャットで使用が禁止される用語の候補を定義する。

プリセットルールパッケージデータ５５８は、それぞれ当該パッケージの識別情報であるルールＩＤと、当該パッケージを構成するルール要素を示す構成ルールＩＤリストと、当該パッケージを構成するルール要素毎の数値条件の設定値を示す構成ルール要素別数値条件値リストと、違反点上限値とを格納する。勿論、これら以外のデータも適宜格納することができる。

本実施形態では、ギルドルールの内容の厳しさに応じて、ハード、スタンダード、イージーの３種類のプリセットルールパッケージデータ５５８が用意されていることとするが、これら以外にもギルドの行動スタイルを体現する別のタイプのパッケージを用意してもよい。

図８に戻って、ユーザ登録データ６００は、プレーヤ登録されたユーザ毎に用意され、当該プレーヤに紐付けされる各種データを格納する。
１つのユーザ登録データ６００は、例えば図１１に示すように、プレーヤアカウント６０１と、連絡用の電子メールアドレス６０３と、所属ギルド名６０５と、課金履歴データ６０７と、ゲームプレイ別のプレイ履歴データ６１０と、所有キャラクタＩＤリスト６２０と、所有アイテムＩＤリスト６２２と、プレーヤチーム編成データ６３０と、を格納する。勿論、これら以外のデータも適宜格納することができる。

プレイ履歴データ６１０は、当該プレーヤのゲームに係る過去の行動記録であって、ギルドに参加してのプレイ毎に生成される。
１つのプレイ履歴データ６１０は、ログイン日時６１１と、ゲームステージでのプレイの内容を格納するステージプレイログ６１３とを含む。ステージプレイログ６１３は、例えば、プレイしたゲームステージを示すステージＩＤ６１３ａと、所属ギルド名６１３ｂと、味方貢献度６１３ｃと、敵貢献度６１３ｄと、ダメージ占有率６１３ｅと、チャット発言履歴６１３ｆとを含む。勿論、これら以外のデータも適宜格納することができる。

味方貢献度６１３ｃは、ゲームステージ攻略に当該プレーヤが貢献した度合を示す指標値である。例えば、参加したギルドメンバー全員で敵キャラクタ６に与えた全ダメージにおける当該プレーヤが与えたダメージの比率や、他ギルドメンバーをサポートした回数（例えば、回復呪文や回復アイテムの使用の回数）、などを求め、それらを変数とする所定の関数で算出する。具体的な算出方法は、公知技術を適宜応用することができる。

敵貢献度６１３ｄは、ゲームステージ攻略を阻害する行為の程度を示す指標である。サッカーゲームで言えば、オウンゴールに相当する行為の程度を示すことになる。例えば、参加した敵キャラクタ６を間違ってサポートした回数（例えば、間違って味方に攻撃してしまった回数）を求め、それらを変数とする所定の関数で算出する。具体的な算出方法は、公知技術を適宜応用することができる。

ダメージ占有率６１３ｅは、敵キャラクタ６からギルドメンバー全員の全プレーヤキャラクタ４が受けたダメージの合計に占める当該プレーヤのプレーヤキャラクタ４のダメージの割合である。

所有キャラクタＩＤリスト６２０は、当該プレーヤが所有するキャラクタの識別情報のリストである。
所有アイテムＩＤリスト６２２は、当該プレーヤが所有するアイテムの識別情報のリストである。

プレーヤチーム編成データ６３０は、プレーヤチーム３（図３参照）の構成を定義する各種データを格納するマスターデータである。例えば図１２に示すように、キャラクタＩＤ６３１と対応づけて、キャラクタ属性６３２と、キャラクタレベル６３３と、最新の能力パラメータ値６３４と、装備中のアイテムを示す装備アイテムＩＤリスト６３５とを格納する。勿論、これら以外のデータも適宜対応づけて格納することができる。

図８に戻って、ギルド編成データ６４０は、ギルド毎に用意された当該ギルドに関係する各種データを格納する。１つのギルド編成データ６４０は、例えば図１３に示すように、ギルド名６４１と、設立日時６４３と、ギルドマスターアカウント６４５と、ギルド紹介コメントデータ６４７と、編集用パスワード６４９と、ギルドルール設定データ６５０と、メンバーデータ６６０と、ステージプレイ日時リスト６７０と、除名履歴データ６７２と、を含む。勿論、これら以外のデータも適宜格納することができる。

ギルドルール設定データ６５０は、ギルドルールを定義するデータであって、適用期間６５１別に用意される。１つのギルドルール設定データ６５０は、ギルドルールを構成するルール要素を示す構成ルールＩＤ６５３と数値条件値６５５とを対応付けて格納し、また違反点上限値６５７を格納する。勿論、これら以外のデータも適宜格納することができる。

メンバーデータ６６０は、ギルドメンバー毎に用意される。１つのメンバーデータ６６０は、プレーヤアカウント６６１と、プレーヤチーム編成データ（写）６６２と、違反点合計６６３と、平均参加率６６４と、不参加履歴６６５と、チャット発言履歴６６６と、警告履歴６６７とを格納する。勿論、これら以外のデータも適宜格納することができる。

プレーヤチーム編成データ（写）６６２は、プレーヤアカウント６６１の示すユーザ登録データ６００（図１１参照）のプレーヤチーム編成データ６３０のコピーである。

違反点合計６６３は、当該プレーヤがギルドルールを構成するルール要素のうち、加点ルールに区分されるルールに違反して付与された違反点の積算値である。ギルドメンバー登録時は「０」である。所定期間経過毎に「０」にリセットされる構成としてもよい。

不参加履歴６６５は、当該プレーヤがギルドとしてのプレイに参加しなかった日時のリストである。具体的には、ギルドメンバー登録時は「記録無し」である。ギルドマスターによるステージプレイの開始操作時点において、当該プレーヤのプレーヤキャラクタ４が、ギルドマスターのプレーヤキャラクタ４から所定範囲内にいない場合に不参加と看做され、その日時が追加記憶される。

チャット発言履歴６６６は、ステージプレイ中のチャットの発言内容の履歴である。

警告履歴６６７には、当該プレーヤのプレーヤ端末１５００にてルール違反に関する警告が成された毎に、日時と、違反となったルール要素または違反状態となりそうなルール要素のルールＩＤが対応づけて格納される。

ステージプレイ日時リスト６７０は、ギルドとしてゲームプレイしたゲームステージＩＤとプレイ日時とを対応づけて格納する。

除名履歴データ６７２は、当該ギルドの所属登録の自動解除、すなわち自動除名が実行された日時、除名されたプレーヤアカウントを格納する。

図８に戻って、プレイデータ７００は、ギルドとしてのゲームプレイ毎に用意され、当該ゲームプレイの進行状況を記述する各種データを格納する。
図１４に１つのプレイデータ７００の構成例を示す。本実施形態のプレイデータ７００は、自動付与される固有のプレイＩＤ７０１と、ギルド名７０３と、プレイするゲームステージを示すステージＩＤ７０５と、ギルド名７０３の示すギルドのメンバーのうち実際にステージプレイに参加したギルドメンバーを示す参加ギルドメンバーＩＤリスト７０９と、を格納する。また、プレイデータ７００は、味方ステータスデータ７１０と、敵ステータスデータ７１２と、違反審査用データ７２０とを含む。勿論、これら以外のデータも適宜格納することができる。

味方ステータスデータ７１０は、今回のステージプレイに参加しているギルドメンバーのプレーヤキャラクタ４（図３参照）毎に用意されて、当該プレーヤキャラクタの最新状況を記述するデータを格納する。例えば、キャラクタＩＤと、最新のパラメータ値リスト（ＨＰや、攻撃力、防御力、経験値、装備しているアイテムの残数など）とを格納する。勿論、これら以外のデータ、例えば位置座標や、モーション制御用のデータなども適宜格納することができる。

敵ステータスデータ７１２は、敵キャラクタ６（図３参照）毎に用意され、当該敵キャラクタの最新状態を記述するデータを格納する。

違反審査用データ７２０は、ギルドルールの違反を審査するために必要となる情報を格納する。例えば、ダメージ履歴データ７２１と、回復履歴データ７２３と、発言履歴データ７２５とを含む。勿論、これら以外にもルール要素の内容設定に対応したその他のデータも適宜格納することができる。

ダメージ履歴データ７２１は、プレーヤキャラクタ４または敵キャラクタ６がダメージを受ける毎に生成され、ダメージ発生の日時や、ダメージを受けたキャラクタＩＤ、ダメージを与えたキャラクタＩＤ、ダメージ量などを格納する。

回復履歴データ７２３は、プレーヤキャラクタ４または敵キャラクタ６のダメージが回復された場合に生成され、ダメージ回復の日時や、ダメージ回復を受けたキャラクタＩＤ、ダメージ回復を発現させキャラクタＩＤ、回復量などを格納する。

発言履歴データ７２５は、ステージプレイ中にテキストチャット機能で発言が行われるごとに生成され、発言の日時や、発言したプレーヤＩＤ、発言内容（テキストデータ）などを格納する。

ダメージ履歴データ７２１と、回復履歴データ７２３と、発言履歴データ７２５は、当該ステージプレイにおけるプレイ履歴である。特に、ダメージ履歴データ７２１と回復履歴データ７２３は、各ギルドメンバーの味方への貢献度（味方を有利にする行動の回数や程度）と、敵への貢献度（敵を有利（換言すると味方を不利）にする行動の回数や程度）とを判定する材料とされる。

また、本実施形態のゲームはＲＰＧなので、プレイデータ７００には、プレーヤキャラクタ４の敵キャラクタ６の位置座標、プレイ中に各プレーヤが取得したオブジェクトのリスト、プレーヤキャラクタ４や敵キャラクタ６の動作制御データなどが格納される。勿論、ゲームの内容に応じてその他のデータも適宜格納することができる。

［処理の流れの説明］
図１５〜図１７は、本実施形態のサーバシステム１１００による主たる処理の流れについて説明するためのフローチャートである。
ここで説明する処理の流れの前提として、サーバ処理部２００ｓがサーバシステムプログラム５０１を実行した状態で、アカウント管理プログラム５０３およびゲーム管理プログラム５０５を読み出して実行している。

また、プレーヤ端末１５００が配信用ゲームプログラム５０７の複製をダウンロードして実行し、サーバシステム１１００と接続してプレーヤアカウントを使ってログインしているものとする。ログインに伴い、各プレーヤのユーザ登録データ６００には新たなプレイ履歴データ６１０（図１１参照）が追加される。但し、この時点ではギルドでのステージプレイには至っていないので、生成されたばかりのプレイ履歴データ６１０にはステージプレイログ６１３は格納されていない。

サーバシステム１１００のサーバ処理部２００ｓは、先ずログインしているプレーヤのプレーヤ端末１５００にて所定のトップ画面を表示させる（ステップＳ２）。
トップ画面にはゲームの準備やゲームプレイに関する様々な操作入力をするためのアイコンが表示されており、プレーヤ端末１５００は操作されたアイコンに応じた種類のリクエスト信号をサーバシステム１１００へ送信する。サーバシステム１１００は、受信したリクエスト信号の種類からプレーヤ端末１５００にてなされた操作入力を検出することができる。

さて、サーバシステム１１００のサーバ処理部２００ｓは、プレーヤ端末１５００にて購入キャラクタおよび購入アイテムの登録操作が入力されたことを検出すると（ステップＳ４のＹＥＳ）、プレーヤ端末１５００にて新規登録するキャラクタやアイテムのＩＤを入力するための入力画面を表示させる（ステップＳ６）。

具体的には、プレーヤがオンラインショッピングや実店舗などで購入したオブジェクトのオブジェクトＩＤを当該入力画面で入力すると、プレーヤ端末１５００は入力結果をサーバシステム１１００へ送信する。サーバシステム１１００のサーバ処理部２００ｓは、入力されたオブジェクトＩＤを、所有キャラクタＩＤリスト６２０又は所有アイテムＩＤリスト６２２に追加登録する。なお、ゲーム内でオブジェクトを購入した場合には、自動的に登録することとする。

次に、サーバシステム１１００のサーバ処理部２００ｓは、プレーヤ端末１５００にてプレーヤチーム編成操作が入力されたことを検出すると（ステップＳ１０のＹＥＳ）、プレーヤチーム編成処理を実行する（ステップＳ１２）。
例えば、プレーヤ端末１５００にて所有キャラクタＩＤリスト６２０（図１１参照）に登録されているキャラクタの一覧を、それぞれのキャラクタ属性の情報表示を付属させて選択可能に表示する。そして、選択操作されたキャラクタをプレーヤキャラクタ４とする。また、所有アイテムＩＤリスト６２２に登録されているアイテムの一覧をそれぞれのアイテム属性の情報表示を付属させて選択可能に表示して、選択操作されたアイテムをプレーヤキャラクタ４に装備させる。ここで設定するプレーヤキャラクタ４の数は、所定のプレーヤチーム３の編成数上限までとする。そして、編成操作の結果に応じてプレーヤチーム編成データ６３０を更新する。

次いで、サーバ処理部２００ｓは、当該プレーヤの所属ギルド名６０５（図１１参照）の示すギルド編成データ６４０（図１３参照）を検索し、当該プレーヤのメンバーデータ６６０のプレーヤチーム編成データ（写）６６２へ、プレーヤチーム編成データ６３０の内容をコピーして更新する（ステップＳ１４）。

次に、サーバシステム１１００のサーバ処理部２００ｓは、プレーヤ端末１５００にて新規ギルドの設立操作が入力されたことを検出すると（ステップＳ２０のＹＥＳ）、ギルド設立処理を実行する（ステップＳ２２）。
すなわち、新しいギルド編成データ６４０を生成する。この時、ギルドマスターアカウント６４５は、当該プレーヤのプレーヤアカウントとされる。また、ギルド紹介コメントデータ６４７と、編集用パスワード６４９とをプレーヤに入力させる。当該ギルドは設立したばかりなので、ギルドルール設定データ６５０も“未定”の状態であり、メンバーデータ６６０も格納されていない。除名履歴データ６７２も“履歴無し”の状態とされる。

ギルド設立処理を終えた場合、あるいはプレーヤ端末１５００にてギルドルール設定操作が入力されたことを検出すると（ステップＳ２４のＹＥＳ）、サーバ処理部２００ｓはギルドルール設定処理を実行する（ステップＳ２６）。

図１８は、本実施形態におけるギルドルール設定処理の流れを説明するためのフローチャートである。同処理に於いて、サーバ処理部２００ｓは、プレーヤ端末１５００にてギルドルール設定画面Ｗ４（図５参照）を表示させる（ステップＳ５０）。

プレーヤ端末１５００は、ギルドルール設定画面Ｗ４への操作入力結果を逐次サーバシステム１１００へ送信する。
サーバシステム１１００のサーバ処理部２００ｓは、ギルド名入力欄２１、ギルドマスターアカウント入力欄２２、編集用パスワード入力欄２３へのそれぞれの入力結果を、該当するギルド編成データ６４０（図１３参照）に格納されているギルド名６４１、ギルドマスターアカウント６４５、編集用パスワード６４９とそれぞれ照合して、設定権の認証をする（ステップＳ５２）。

設定権が認証されることを前提として説明を続けると、サーバ処理部２００ｓは、次に、ギルドルール設定データ６５０を参照してギルドルール設定欄２５に現在のギルドルールの内容を表示させる（ステップＳ５４）。

次いで、ルール要素定義データ５５０（図１０参照）を参照して、ルール要素メニュー２４にルール要素別のルール要素パネル３０（３０ａ，３０ｂ，…）を選択操作可能に表示させる（ステップＳ５６）。
当該ステップにおいて、本実施形態ではルール要素定義データ５５０の全てのルート要素を表示するが、適宜表示するルール要素を絞る構成としてもよい。
例えば、構成するルールＩＤ５５２が異なる手動設定用ルール要素データ５５１を異なる適用条件毎に複数用意しておいて、設定対象のギルドに該当する適用条件の手動設定用ルール要素データ５５１に含まれるルール要素を表示させる構成も可能である。ここで言う「適用条件」の内容は適宜設定可能であるが、ゲームへの熟練度合いで分けると好ましい。例えば、ギルドマスター又はギルドマスターを含むギルドメンバー全員のキャラクタレベル６３３（図１２参照）の平均が所定の上級者レベル条件を満たす場合と満たさない場合と言った具合である。

あるいは、ギルドマスターが所定の初心者条件を満たす場合（例えば、プレイ履歴データ６１０（図１１参照）の数が規定値未満など）やギルドの設立日時６４３から所定期間は、プリセットルールパッケージデータ５５８のみ表示することとし、初心者条件を満たさなくなった場合および所定期間を超えると、プリセットルールパッケージデータ５５８は表示せずに手動設定用ルール要素データ５５１のルール要素を表示させるとしてもよい。

プレーヤ端末１５００にてギルドルールを構成するルール要素の設定操作や設定解除操作を検出すると、サーバ処理部２００ｓは当該操作入力に応じてギルドルールを構成するルール要素をギルドルール設定データ６５０へ追加する処理、または削除する処理を行う（ステップＳ５８）。なお、追加又は削除に当たっては、後述する設定の復元のために適宜設定変更履歴を記憶するものとする。

もし、プリセットルールパッケージがギルドルールに追加されたならば（ステップＳ６０のＹＥＳ）、サーバ処理部２００ｓは、ギルドルール設定データ６５０に設定済みの手動設定用のルール要素を全て設定解除し（ステップＳ６２）、違反点上限値６５７を追加されたプリセットルールパッケージに格納されている違反点上限値の値に更新する（ステップＳ６４）。

もし、手動設定用のルール要素がギルドルールに追加されたならば（ステップＳ７０のＹＥＳ）、サーバ処理部２００ｓは、ギルドルール設定データ６５０に設定済みのプリセットルールパッケージを設定解除し（ステップＳ７２）、当該追加されたルール要素の数値条件値６５５を、プルダウンメニューを用いた指示操作入力に応じて設定する（ステップＳ７４）。同様に、違反点上限値６５７を、プルダウンメニューを用いた指示操作入力に応じて（ステップＳ７６）。

そして、プレーヤ端末１５００にて所定の設定完了操作の入力が検出されると（ステップＳ８０のＹＥＳ）、サーバ処理部２００ｓはギルドルール設定処理を終了する。
もし、プレーヤ端末１５００にて所定のキャンセル操作の入力が検出されると（ステップＳ８２のＹＥＳ）、サーバ処理部２００ｓはギルドルール設定データ６５０を元の状態に復元して（ステップＳ８４）、ギルドルール設定処理を終了する。

図１５のフローチャートに戻って、次に、プレーヤ端末１５００にて所定の参加申し込み操作の入力が検出されると（ステップＳ１００のＹＥＳ）、サーバ処理部２００ｓは、プレーヤ端末１５００にてギルド参加申し込み画面Ｗ６（図６参照）を表示させる（ステップＳ１０２）。
例えば、ギルド編成データ６４０を参照して、所定のメンバー募集条件（例えば、所属メンバーの合計が規程値未満など）を満たすギルドを抽出して、抽出したギルドの代表情報（例えば、ギルド名６４１、ギルドメンバー数、ギルドメンバーのキャラクタレベル６３３（図１２参照）の平均レベルなど）を抽出または算出して、ギルド情報表示部４０に表示させる。

そして、ギルド情報表示部４０でのギルドの選択操作に応じて、選択されたギルドのギルド紹介コメントデータ６４７の内容を紹介コメント表示部４２に表示させ、ギルドルール設定データ６５０を参照してギルドルール開示部４４にその内容を表示させる（ステップＳ１０４）。

参加申し込み画面Ｗ６（図６参照）を表示させた状態で、プレーヤ端末１５００にて所属依頼操作の入力が検出されると（ステップＳ１０６のＹＥＳ）、サーバ処理部２００ｓは、ギルド情報表示部４０で選択されたギルドへの所属登録処理を実行する（ステップＳ１０８）。当該処理においては、申し込み先のギルドのギルドマスターの承認を得るなどのステップを適宜含めることができる。

図１６のフローチャートに移って、プレーヤ端末１５００にて所定のステージ情報開示操作の入力が検出されると（ステップＳ１３０のＹＥＳ）、サーバ処理部２００ｓはゲームステージ初期設定データ５１０（図９参照）を参照して、ゲームステージ別に、敵キャラクタＩＤ５１５と、敵キャラクタ属性５１７と、相性データ５２０とをプレーヤ端末１５００にて表示させる（ステップＳ１３２）。
プレーヤは、この表示を見ることで、次に自身が所属するギルドが挑戦するゲームステージの攻略に適したプレーヤチーム３の編成をすることが可能となる。より具体的には、敵キャラクタ６との相性を考慮したキャラクタ属性のキャラクタをプレーヤキャラクタ４に設定し、相性を考慮したアイテムを装備させることができる。

本実施形態のゲームでは、ギルドマスターがギルドメンバーを集めてから所定のステージプレイ開始操作を入力して、ギルドとしてのプレイを開始する。これを「ステージプレイ」と呼ぶ。

ギルドマスターのプレーヤ端末１５００にてステージプレイ開始操作の入力を検出すると（ステップＳ１４０のＹＥＳ）、サーバシステム１１００のサーバ処理部２００ｓは、プレイデータ７００（図１４参照）を生成し、ステージ選択処理と、参加メンバーの判定処理とを実行する（ステップＳ１４２）。

具体的には、ギルドマスターのプレーヤ端末１５００にて、プレイするゲームステージの選択画面を表示させ、選択結果に応じてステージＩＤ７０５を設定する。そして、ステージプレイ開始操作入力時点で、ログインしているギルドメンバーのＩＤを、参加ギルドメンバーＩＤリスト７０９に設定する。逆説的に言えば、当該リストに登録されていない所属メンバーは、不参加ということになる。

次に、サーバ処理部２００ｓは、ステージＩＤ７０５の示すゲームステージ初期設定データ５１０（図９参照）を参照して、当該ゲームステージにて、参加メンバーのプレーヤキャラクタ４が登場するマルチプレイオンラインＲＰＧの進行制御を開始する（ステップＳ１４４）。
これに伴い、参加メンバー各々のプレーヤ端末１５００での操作入力に応じて対応するプレーヤキャラクタ４を動作させる制御や、敵キャラクタ６の自動制御、味方ステータスデータ７１０や敵ステータスデータ７１２の逐次更新、テキストチャット制御、違反審査用データ７２０の逐次生成制御、などが開始される。

また、進行制御を開始すると、適用期間６５１が適合するギルドルール設定データ６５０（図１３参照）を抽出し、構成ルールＩＤ６５３が所定のルール内容を実現している場合に（ステップＳ１６０のＹＥＳ）、サーバ処理部２００ｓはルール内容基準ボーナス付与の制御を行う（ステップＳ１６２）。

具体的には、本実施形態では、所定のルールＩＤを有するプリセットルールパッケージ（例えば、非常に厳格なルール内容が設定されているパッケージ）がギルドルールに設定されている場合に“所定のルール内容を実現している”と判定する。ルール内容基準ボーナス付与の内容は適宜設定可能であるが、例えば、ステージプレイ中に出現するアイテムの出現率を向上させたり、出現するアイテムのレアリティを高めるなどが挙げられる。プレーヤキャラクタ４の攻撃力や防御力などの能力パラメータ値を向上させるなどでもよい。

ステージプレイが終了したならば（ステップＳ１７０）、サーバ処理部２００ｓは、参加メンバーそれぞれのユーザ登録データ６００（図１１参照）の最新のプレイ履歴データ６１０に、今回のステージプレイの結果に基づいてステージプレイログ６１３を格納する（ステップＳ１７４）。

具体的には、参加ステージＩＤ６１３ａには今回のステージＩＤ７０５を格納し、所属ギルド名６１３ｂは今回のギルド名７０３とする。味方貢献度６１３ｃおよび敵貢献度６１３ｄは、違反審査用データ７２０に格納されるデータを変数とする所定関数で算出される。味方貢献度６１３ｃおよび敵貢献度６１３ｄの算出については、適宜公知技術を応用できることができる。ダメージ占有率６１３ｅは、違反審査用データ７２０のダメージ履歴データ７２１を元に所定関数で算出される。チャット発言履歴６１３ｆは、違反審査用データ７２０の発言履歴データ７２５を元に、発言内容のテキストを抽出して決定される。
これで、当該参加メンバーのプレーヤについてルール違反の審査に係る行動履歴を、参加しているギルドとは関係なく蓄積されたことになる。

次いで、サーバ処理部２００ｓは、参加メンバーのプレーヤキャラクタ４のキャラクタレベル６３３（図１２参照）を今回のゲームプレイの結果に応じて更新する（ステップＳ１７６）。例えば、敵キャラクタ６に与えたダメージ量に応じた経験値（能力パラメータ値の１つ）を与え、蓄積された経験値に応じたレベルに更新する。

図１７のフローチャートに移って、次に、サーバ処理部２００ｓは今回のステージプレイの結果に応じてメンバーデータ６６０（図１３参照）のチャット発言履歴６６６と不参加履歴６６５を更新する（ステップＳ２０２）。

次いで、サーバシステム１１００のサーバ処理部２００ｓは、ギルドマスターを除くギルドメンバー別に、適用期間６５１が適合するギルドルール設定データ６５０に対する違反審査と、違反しているルール要素の違反点を違反点合計６６３へ加算する処理を行う（ステップＳ２０４）。

具体的には、審査対象とするギルドメンバーの最新のプレイ履歴データ６１０（図１１参照）および違反審査用データ７２０に含まれる情報と、適用期間６５１が適合するギルドルール設定データ６５０（図１３参照）の各構成ルールＩＤ６５３が示すルール要素の数値条件値６５５と比較して違反審査する。

より具体的には、例えば、図１０のルールＩＤ「ＧＲ１０１」のルール要素については、審査対象ギルドメンバーのメンバーデータ６６０の不参加履歴６６５と、ステージプレイ日時リスト６７０とを比較して連続不参加の回数を算出し、対応する数値条件値６５５と比較して審査する。

ルールＩＤ「ＧＲ１０２」のルール要素については、ギルドメンバー別に不参加履歴６６５と、ステージプレイ日時リスト６７０とを比較して各々のステージプレイへの参加率を求めて、そこからギルドメンバーの平均参加率を算出する。そして、この平均参加率と審査対象ギルドメンバーの参加率を比較して審査する。

ルールＩＤ「ＧＲ１０３」のルール要素については、審査対象ギルドメンバーのユーザ登録データ６００の最新のプレイ履歴データ６１０の味方貢献度６１３ｃと、対応する数値条件値６５５と比較して審査する。

ルールＩＤ「ＧＲ１０４」のルール要素については、審査対象ギルドメンバーのユーザ登録データ６００の最新のプレイ履歴データ６１０の敵貢献度６１３ｄと、対応する数値条件値６５５と比較して審査する。

ルールＩＤ「ＧＲ１０５」のルール要素については、審査対象ギルドメンバーのユーザ登録データ６００のプレーヤチーム編成データ６３０おキャラクタレベル６３３と、対応する数値条件値６５５と比較して審査する。

ルールＩＤ「ＧＲ１０６」のルール要素については、審査対象ギルドメンバーのユーザ登録データ６００の最新のプレイ履歴データ６１０のダメージ占有率６１３ｅと、対応する数値条件値６５５と比較して審査する。

ルールＩＤ「ＧＲ１０７」のルール要素については、ステージＩＤ７０５（図１４参照）が適合するゲームステージ初期設定データ５１０（図９参照）の相性データ５２０と、審査対象ギルドメンバーのプレーヤチーム３の編成内容とを比較して審査する。例えば、推奨キャラクタ属性５２３と推奨キャラクタ属性占有率５２５を、審査対象ギルドメンバーのユーザ登録データ６００のプレーヤチーム編成データ６３０のキャラクタ属性６３２が満たしているか審査する。また、プレーヤチーム編成データ６３０の装備アイテムＩＤリスト６３５に、推奨アイテムＩＤリスト５２１に登録されているアイテムが含まれているかで審査する。前者と後者の一方または両方が肯定の場合に、当該ルール要素は遵守されていると判断する。

ルールＩＤ「ＧＲ１０８」のルール要素については、審査対象ギルドメンバーのユーザ登録データ６００の最新のプレイ履歴データ６１０のチャット発言履歴６１３ｆと禁止用語リスト５５７（図１０参照）とを比較して審査する。

次に、サーバシステム１１００のサーバ処理部２００ｓは、ギルドルールを構成するルール要素の何れかにの数値条件値６５５に近接した、または到達したギルドメンバーに警告通知を行う（ステップＳ２０６）。例えば、該当するルール要素の内容とともに警告する文言をプレーヤ端末１５００にて表示させる。そして、当該ギルドメンバーに対応する警告履歴６６７（図１３参照）を更新する（ステップＳ２０８）。

次に、サーバ処理部２００ｓは、違反点合計６６３（図１３参照）が違反点上限値６５７に達したギルドメンバーの除名処理を行う（ステップＳ２１０）。具体的には、該当ギルドメンバーのメンバーデータ６６０を抹消し、当該プレーヤのユーザ登録データ６００の所属ギルド名６０５を“未参加”を示す値に変更する。そして、除名履歴データ６７２を更新する（ステップＳ２１２）。

次いで、サーバ処理部２００ｓは、ステップＳ２０４の審査結果に基づいて、ギルドルール設定データ６５０の構成ルールＩＤ６５３に含まれる「絶対ルール」に違反するギルドメンバーの除名処理を行う（ステップＳ２１４）。そして、除名履歴データ６７２を更新する（ステップＳ２１６）。

次いで、除名履歴データ６７２に基づいて、除名者ゼロの連続期間に応じてボーナスを付与する（ステップＳ２１８）。付与の対象は、ギルド全体でも良いし、ギルドメンバー全員でもよし、ギルドマスターのみでもよい。ボーナスの内容も適宜設定可能である。

次に、サーバ処理部２００ｓは、除名者数が不適当と考えられる所定基準値に達しているギルドを検索して、該当するギルド名を公表する制御を行う（ステップＳ２２０）。

次に、サーバ処理部２００ｓは、所定のギルドマスター不適格条件を満たしているギルドを抽出する（ステップＳ２３０）。ギルドマスター不適格条件は、ギルドマスターがギルドルールの設定を適切に設定・管理しないために、いたずらに除名者を量産している状態を示す内容とする。例えば、除名履歴データ６７２に基づいて所定期間の除名数が上限値に達している場合などとしてもよい。または、ステップＳ２０４の審査結果に基づいて、一度にギルドメンバーのうちの所定基準数以上の人数がルール違反と判断された場合などもギルドマスター不適格条件とすることができる。勿論、これらの両方を採用するとしてもよいし、これら以外の条件内容も適宜設定可能である。

そして、抽出されたギルドのギルドメンバーのユーザ登録データ６００の所属ギルド名６０５を“参加ギルド無し”を示す値に変更し（ステップＳ２３２）、抽出されたギルドの登録を抹消する（ステップＳ２３４）。つまり、ステップＳ２３２〜Ｓ２３４により実質的にギルドマスターを強制解任する。勿論、強制解任の内容はこれに限らず、例えば、ギルドマスターを何れかのギルドメンバーに置き換えて、ギルドマスターのメンバーデータ６６０を抹消するとしてもよい。

以上、本実施形態によれば、ギルド毎にギルド内で遵守されるべきルールを設定し、違反者を自動的にギルドの所属登録から解除して除名することができる。従来のように、ギルドマスターが手動で除名する仕様ではないので、ギルドマスターへの心的負担を軽減することができる。ギルド参加申し込みの際にはプレーヤが参加希望のギルドルールに目を通すことができる仕組みであり、更に事前警告の通知も行われる。その上でゲームのシステムとして自動除名が行われるので、除名されたプレーヤにしても納得が行く。

また、ギルドルールは、複数のルール要素を選択して組み合わせできる上に、同じルール要素でも数値条件を自在に設定できるので、ギルドルールの設定は簡単でありながらも自由度の効いた多様な設定を実現している。また、ギルドルールは、当該ギルドに参加申し込みする際に事前にプレーヤが目を通すことができるため、結果としてプレイスタイルが似たプレーヤが自然と集まり、より良質なギルドを形成できる一助にすることができる。

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

［その１］
上記実施形態ではプレーヤ端末１５００は、スマートフォンとしての形態を有していたが、その他のコンピュータ、例えば電子機器の形態であってもよい。例えば、制御基板を搭載した装置本体と、当該装置本体と無線接続される複数台のタッチパネル搭載型ゲームコントローラとを備えた据え置き型家庭用ゲーム装置とすることもできる。当該構成の場合、装置本体を上記実施形態の制御基板１５５０相当とし、ゲームコントローラを無線通信式のタッチパネル１５０６と見立てればよい。

同様に、プレーヤ端末１５００をアーケードゲーム装置（業務用ゲーム装置）としての形態を有するとしてもよい。その場合、アーケードゲーム装置は、ゲームプレイリソース（例えば、上記実施形態におけるオブジェクト）に係るデータを担持するトレーディングカードからデータを読み取る装置を搭載し、所有登録するオブジェクトのオブジェクトＩＤをトレーディングカードから読み取るとしてもよい。

［その２］
また、上記実施形態では、ギルドの設立やギルドルールの設定、自動除名、ゲームの進行制御などの主たる機能をサーバシステム１１００にて実現し、プレーヤ端末１５００は操作入力とゲーム画面の表示のための端末とした構成であったが、それら主たる機能をサーバシステム１１００とプレーヤ端末１５００とで分散させる構成も可能である。当該構成を第１実施形態のゲームシステムに適用することができるのは勿論のこと、サーバシステム１１００を他のプレーヤ端末により実現するゲームシステムとしてプレーヤ端末間をピア・ツー・ピア接続する構成に適用することもできる。

［その３］
例えば、上記実施形態ではゲームとしてＲＰＧを例示したが、上記実施形態のギルドに相当する団体を設定・運用するゲームであれば、その他のジャンルのゲームでもよい。

［その４］
また、上記実施形態では、ギルドマスターだけがギルドルールの決定権を有する構成としたが、ギルドメンバーにも決定権の一部を与える構成も可能である。
例えば、ギルドルール設定部２２２が、ギルドメンバーの投票によって、ギルドルールを設定変更する手段を含む構成としてもよい。より具体的には、図１８のステップＳ８０にて、設定完了操作を検出した場合に、ギルドメンバー全員によるギルドルールが適切か否かの多数決の投票処理を行い、多数決で承認された場合にはギルドルールの設定をそのままとし、否決されたならばステップＳ８４と同様に設定を元に復元するとすればよい。なお、投票処理の方法は、適宜公知技術を用いることとする。

［その５］
また、上記実施形態では、公表制御部２５２（図７参照）が、除名者が極端に多いギルド名を公表して、新たにギルドに参加しようとするプレーヤに注意を促す効果を発現していた。しかし、反対に、長期にわたり除名者が基準値に満たない少数である場合に、褒め称える意味でギルド名を公表する機能を有するように構成してもよい。

２…プレーヤ
３…プレーヤチーム
４…プレーヤキャラクタ
２４…ルール要素メニュー
２５…ギルドルール設定欄
３０…ルール要素パネル
３２…数値条件表示部
３４…違反点上限値設定欄
４０…ギルド情報表示部
４４…ギルドルール開示部
２００ｓ…サーバ処理部
２１０…ゲーム管理部
２１６…プレーヤチーム編成部
２２２…ギルドルール設定部
２２４…ギルド情報提供制御部
２２６…ギルド所属登録部
２３０…審査部
２３２…警告通知制御部
２３４…自動除名制御部
２３６…除名履歴記憶制御部
２４０…ゲーム進行制御部
２４６…プレイ履歴記憶制御部
２５０…ギルドマスター強制解任部
２５２…公表制御部
５００ｓ…サーバ記憶部
５０５…ゲーム管理プログラム
５１０…ゲームステージ初期設定データ
５２０…相性データ
５２１…推奨アイテムＩＤリスト
５２３…推奨キャラクタ属性
５２５…推奨キャラクタ属性占有率
５５０…ルール要素定義データ
５５１…手動設定用ルール要素リスト
５５２…ルールＩＤ
５５４…規範内容
５５５…違反点
５５８…プリセットルールパッケージデータ
６００…ユーザ登録データ
６０１…プレーヤアカウント
６０５…所属ギルド名
６１０…プレイ履歴データ
６１３…ステージプレイログ
６１３ｃ…味方貢献度
６１３ｄ…敵貢献度
６１３ｅ…ダメージ占有率
６１３ｆ…チャット発言履歴
６３０…プレーヤチーム編成データ
６３２…キャラクタ属性
６３３…キャラクタレベル
６４０…ギルド編成データ
６４１…ギルド名
６５０…ギルドルール設定データ
６５３…構成ルールＩＤ
６５５…数値条件値
６５７…違反点上限値
６６０…メンバーデータ
６６３…違反点合計
６６４…平均参加率
６６５…不参加履歴
６６６…チャット発言履歴
６６７…警告履歴
６７０…ステージプレイ日時リスト
６７２…除名履歴データ
７００…プレイデータ
７０９…参加ギルドメンバーＩＤリスト
７２０…違反審査用データ
１１００…サーバシステム
１１５０…制御基板
Ｗ２…ギルドルール設定画面
Ｗ４…ギルドルール設定画面
Ｗ６…参加申し込み画面

Claims (15)

1. 各プレーヤのプレーヤ端末が通信接続可能に構成され、複数のプレーヤが所属可能な団体を設定して当該団体を管理するサーバシステムであって、
   当該団体に所属した場合に守るべきプレイ規範のルールを設定するルール設定手段と、
   当該団体に所属する所属プレーヤのプレイ履歴と前記ルールとを比較して、当該所属プレーヤがルール違反に該当するか否かを審査する審査手段と、
   前記審査手段によりルール違反と判断された場合に、当該所属プレーヤの当該団体への所属を解除する解除手段と、
   を備えたサーバシステム。
2. 前記プレーヤ端末から当該団体への所属依頼を受け付けた場合に、当該プレーヤ端末のプレーヤを当該団体の所属プレーヤとして登録する所属登録手段、
   を更に備えた請求項１に記載のサーバシステム。
3. 前記ルール設定手段により設定されたルールを含む当該団体の紹介情報を前記プレーヤ端末に送信する紹介情報送信手段、
   を更に備えた請求項２に記載のサーバシステム。
4. 前記所属登録手段は、前記紹介情報送信手段により送信された前記紹介情報が前記プレーヤ端末で表示された場合にのみ、当該紹介情報に係る団体への所属依頼を受け付け可能とする制御を行う、
   請求項３に記載のサーバシステム。
5. 前記ルール設定手段は、当該団体の代表プレーヤの選択操作に従って複数のルール要素の中からルール要素を選択して前記ルールを設定する、
   請求項１〜４の何れか一項に記載のサーバシステム。
6. 前記複数のルール要素には数値条件を含むルール要素が含まれ、
   前記ルール設定手段は、前記代表プレーヤの指示操作によって、数値条件を含むルール要素の当該数値条件を設定する、
   請求項５に記載のサーバシステム。
7. 前記ルール設定手段は、当該団体に係るゲームパラメータに基づいて、複数の前記ルール要素の中から、前記ルールとして設定可能なルール要素の候補を抽出する、
   請求項１〜６の何れか一項に記載のサーバシステム。
8. 前記ルール設定手段は、当該団体の所属プレーヤの投票によって、前記ルールを設定変更する手段を有する、
   請求項１〜７の何れか一項に記載のサーバシステム。
9. 前記審査手段は、当該ルール違反に該当する前の警告状況に該当するか否かを審査する手段を有し、
   前記警告状況に該当すると判断された場合に、当該所属プレーヤのプレーヤ端末に警告通知を行う警告通知手段を更に備えた、
   請求項１〜８の何れか一項に記載のサーバシステム。
10. 前記所属プレーヤが前記ルール違反に該当すると判断された数が所定の数値条件を満たした場合に、当該団体を公表する制御を行う公表制御手段を更に備えた、
    請求項９に記載のサーバシステム。
11. 前記団体の所属プレーヤのプレーヤ端末が、所与のマルチプレイゲームをプレイ可能に構成されており、
    前記ルール設定手段は、前記マルチプレイゲームにおける貢献度を前記ルール要素として前記ルールを設定する、
    請求項５又は６に記載のサーバシステム。
12. 前記ルール設定手段は、前記マルチプレイゲームにおける参加度を前記ルール要素として前記ルールを設定する、
    請求項１１に記載のサーバシステム。
13. 当該団体の所属プレーヤのうちの所与の人数が前記審査手段によりルール違反と判断された場合に、前記代表プレーヤの当該団体への所属を解除する代表プレーヤ解除手段、
    を更に備えた請求項１〜１２の何れか一項に記載のサーバシステム。
14. 前記審査手段によりルール違反の対象とされていない期間及び／又は人数に基づいて、前記所属プレーヤに所与のボーナスを付与する処理を実行するボーナス付与手段、
    を更に備えた請求項１〜１３の何れか一項に記載のサーバシステム。
15. 各プレーヤのプレーヤ端末が通信接続可能に構成されたコンピュータシステムに、複数のプレーヤが所属可能な団体を設定して当該団体を管理させるためのプログラムであって、
    当該団体に所属した場合に守るべきプレイ規範のルールを設定するルール設定手段、
    当該団体に所属する所属プレーヤのプレイ履歴と前記ルールとを比較して、当該所属プレーヤがルール違反に該当するか否かを審査する審査手段、
    前記審査手段によりルール違反と判断された場合に、当該所属プレーヤの当該団体への所属を解除する解除手段、
    として機能させるためのプログラム。

Images