JP2020120862A - 情報処理プログラム、サーバ装置および情報処理システム - Google Patents

Abstract

【課題】通信ゲームにおいて、より適切なプレイヤを抽出する。【解決手段】情報処理プログラムは、予め設定された更新条件にしたがって、プレイヤごとの優先度情報を更新するプレイヤ情報更新部１４０ａと、プレイヤ端末から要求情報を受信すると、少なくとも、優先度情報に基づき、複数のプレイヤ端末を、招待情報を受信可能な抽出端末に設定し得る端末設定部１４４ａと、招待情報を受信し、かつ、所定の参加情報が送信されたいずれか１または複数の抽出端末と、要求情報を送信したプレイヤ端末との通信ゲームを実行するゲーム実行部１４６ａと、してコンピュータを機能させる。【選択図】図２７

Description

本発明は、情報処理プログラム、サーバ装置および情報処理システムに関する。

従来、複数のプレイヤが参加可能な通信ゲーム（以下、マルチプレイという）が知られている。マルチプレイでは、ゲームの参加希望者をマッチングする必要がある。例えば、特許文献１には、先行プレイヤのゲームのプレイ中に、他のプレイヤ（後続プレイヤ）からの対戦の申し込みを受け付けるゲームシステムが提案されている。

このゲームシステムによれば、先行プレイヤのゲーム画面上に、対戦の申し込みを知らせる画像が表示される。そして、先行プレイヤが申し込みを受ける操作を行うと、先行プレイヤのプレイ中のゲーム終了を待って、マルチプレイが開始される。

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

上記のように、ゲームの参加希望者をマッチングするゲームシステムにおいては、より適切なプレイヤを抽出することができる技術の開発が望まれている。

本発明は、より適切なプレイヤを抽出可能な情報処理プログラム、サーバ装置および情報処理システムを提供することを目的としている。

上記課題を解決するために、情報処理プログラムは、予め設定された更新条件にしたがって、プレイヤごとの優先度情報を更新する更新部と、プレイヤ端末から要求情報を受信すると、少なくとも、優先度情報に基づき、複数のプレイヤ端末を、招待情報を受信可能な抽出端末に設定し得る設定部と、招待情報を受信し、かつ、所定の参加情報が送信されたいずれか１または複数の抽出端末と、要求情報を送信したプレイヤ端末との通信ゲームを実行するゲーム実行部と、してコンピュータを機能させる。

また、更新部は、通信ゲーム中の所定の結果に基づいて、優先度情報を更新してもよい。

また、更新部は、招待情報の受信後に抽出端末から受信した情報に基づいて、優先度情報を更新してもよい。

また、設定部は、少なくとも、優先度情報、および、プレイヤ端末におけるゲームのプレイ状況に基づいて、抽出端末を設定してもよい。

また、設定部は、通信ゲームが実行されたプレイヤ端末について、少なくとも、通信ゲームの終了後、第１の時間が経過するまでは、抽出端末に設定しないとしてもよい。

また、設定部は、招待情報の受信後、通信ゲームへの参加拒否を示す拒否情報が送信されたプレイヤ端末について、少なくとも、第２の時間が経過するまでは、抽出端末に設定しないとしてもよい。

上記課題を解決するために、上記の情報処理プログラムが記憶された記憶媒体を含むサーバ装置が提供されてもよい。

上記課題を解決するために、情報処理システムは、予め設定された更新条件にしたがって、プレイヤごとの優先度情報を更新する更新部と、プレイヤ端末の操作部における要求操作の入力により、要求情報を送信する要求情報送信部と、プレイヤ端末から要求情報を受信すると、少なくとも、優先度情報に基づき、複数のプレイヤ端末を、招待情報を受信可能な抽出端末に設定し得る設定部と、抽出端末において、招待情報を受信し得る受信部と、招待情報を受信した抽出端末のうち、所定の参加操作の入力に基づいて参加情報が送信されたいずれか１または複数の抽出端末と、要求情報を送信したプレイヤ端末との通信ゲームを実行するゲーム実行部と、を備える。

本発明によれば、より適切なプレイヤを抽出することができる。

図１は、情報処理システムの概略的な構成を示した説明図である。 図２Ａは、プレイヤ端末のハードウェアの構成を説明する図である。図２Ｂは、サーバのハードウェアの構成を説明する図である。 図３Ａは、パーティ編成画面の一例を示す図である。図３Ｂは、情報確認画面の一例を説明する図である。図３Ｃは、クエスト画面におけるバトルゲーム選択ページの一例を示す図である。図３Ｄは、クエスト画面におけるプレイ内容選択ページの一例を説明する図である。 図４Ａは、シングルプレイ選択時のプレイ内容選択ページの一例を説明する図である。図４Ｂは、バトル画面の一例を説明する図である。図４Ｃは、リザルト画面の一例を説明する図である。 図５Ａは、マルチプレイ選択時のプレイ内容選択ページの一例を説明する図である。図５Ｂは、ルーム選択ページの一例を説明する図である。図５Ｃは、対象者選択ページの一例を説明する図である。図５Ｄは、ルーム詳細ページの一例を説明する図である。 図６Ａは、通常画面における招待情報の受信の報知の一例を説明する図である。図６Ｂは、バトル画面における招待情報の受信の報知の一例を説明する図である。図６Ｃは、招待情報ダイアログの一例を説明する図である。図６Ｄは、保留操作後の画面の一例を説明する図である。 図７Ａは、拒否操作前の画面の一例を説明する図である。図７Ｂは、拒否操作後の画面の一例を説明する図である。図７Ｃは、参加操作前の画面の一例を説明する図である。図７Ｄは、参加操作後の画面の一例を説明する図である。 図８Ａは、通常画面における案内情報の受信の報知態様の一例を説明する図である。図８Ｂは、案内情報ダイアログの一例を説明する図である。図８Ｃは、非表示操作後の画面の一例を説明する図である。図８Ｄは、閲覧操作後の画面の一例を説明する図である。 図９Ａは、優先ポイントを説明する図である。図９Ｂは、優先ポイントの更新条件を説明する図である。 図１０は、リスト更新処理を説明する第１の図である。 図１１は、リスト更新処理を説明する第２の図である。 図１２は、リスト更新処理を説明する第３の図である。 図１３は、リスト更新処理を説明する第４の図である。 図１４Ａは、プレイヤ端末のプレイ状態を説明する図である。図１４Ｂは、招待情報の受信確認のタイミングを説明する図である。 図１５は、プレイヤ端末およびサーバの基本的な処理を説明するシーケンス図である。 図１６は、マルチプレイが実行される場合のプレイヤ端末およびサーバの処理を説明するシーケンス図である。 図１７は、マルチプレイに参加できない場合のプレイヤ端末およびサーバの処理を説明するシーケンス図である。 図１８は、マルチプレイの参加を拒否した場合のプレイヤ端末およびサーバの処理を説明するシーケンス図である。 図１９は、プレイヤ端末におけるメモリの構成およびコンピュータとしての機能を説明する図である。 図２０は、プレイヤ端末における端末側ゲーム処理の一例を説明するフローチャートである。 図２１は、プレイヤ端末におけるルーム作成関連処理の一例を説明するフローチャートである。 図２２は、プレイヤ端末における招待情報受信処理の一例を説明するフローチャートである。 図２３は、プレイヤ端末における招待情報確認処理の一例を説明するフローチャートである。 図２４は、プレイヤ端末における招待情報受信後処理の一例を説明する第１のフローチャートである。 図２５は、プレイヤ端末における招待情報受信後処理の一例を説明する第２のフローチャートである。 図２６は、プレイヤ端末におけるマルチプレイ終了処理の一例を説明するフローチャートである。 図２７は、サーバにおけるメモリの構成およびコンピュータとしての機能を説明する図である。 図２８は、サーバにおけるサーバ側ゲーム処理の一例を説明するフローチャートである。 図２９は、サーバにおける要求情報受信処理の一例を説明するフローチャートである。 図３０は、サーバにおける情報更新処理の一例を説明するフローチャートである。 図３１は、サーバにおけるマルチプレイ終了処理の一例を説明するフローチャートである。 図３２は、サーバにおける並び替え処理の一例を説明するフローチャートである。 図３３は、プレイヤ端末における変形例の招待情報受信処理の一例を説明するフローチャートである。 図３４は、プレイヤ端末における第２の実施形態のメモリの構成およびコンピュータとしての機能を説明する図である。 図３５は、サーバにおける第２の実施形態のメモリの構成およびコンピュータとしての機能を説明する図である。 図３６Ａは、第２の実施形態におけるプレイヤ端末およびサーバの処理を説明する第１のシーケンス図である。図３６Ｂは、第２の実施形態におけるプレイヤ端末およびサーバの処理を説明する第２のシーケンス図である。図３６Ｃは、第２の実施形態におけるプレイヤ端末およびサーバの処理を説明する第３のシーケンス図である。

以下に添付図面を参照しながら、本発明の実施形態の一態様について詳細に説明する。かかる実施形態に示す寸法、材料、その他具体的な数値等は、理解を容易とするための例示にすぎず、特に断る場合を除き、本発明を限定するものではない。なお、本明細書および図面において、実質的に同一の機能、構成を有する要素については、同一の符号を付することにより重複説明を省略し、また本発明に直接関係のない要素は図示を省略する。

（情報処理システムＳの全体の構成）
図１は、情報処理システムＳの概略的な構成を示した説明図である。情報処理システムＳは、プレイヤ端末１と、サーバ１００と、通信基地局２００ａを有する通信ネットワーク２００とを含む、所謂クライアントサーバシステムである。

プレイヤ端末１は、通信ネットワーク２００を介してサーバ１００との通信を確立することができる。プレイヤ端末１は、サーバ１００と無線もしくは有線による通信接続が可能な電子機器を広く含む。プレイヤ端末１としては、例えば、スマートフォン、携帯電話、タブレット装置、パーソナルコンピュータ、ゲーム機器等が挙げられる。本実施形態では、プレイヤ端末１として、スマートフォンが用いられる場合について説明する。

サーバ１００は、複数のプレイヤ端末１と通信接続される。サーバ１００は、ゲームをプレイするプレイヤごとに各種の情報（プレイヤ情報）を蓄積する。また、サーバ１００は、プレイヤ端末１から入力される操作に基づき、蓄積された情報の更新と、ゲームの進行制御とを行う。

通信基地局２００ａは、通信ネットワーク２００と接続され、プレイヤ端末１と無線による情報の送受信を行う。通信ネットワーク２００は、携帯電話網、インターネット網、ＬＡＮ(Local Area Network)、専用回線等で構成され、プレイヤ端末１とサーバ１００との無線もしくは有線による通信接続を実現する。

本実施形態の情報処理システムＳは、プレイヤ端末１およびサーバ１００がゲーム装置Ｇとして機能する。プレイヤ端末１およびサーバ１００には、それぞれゲームの進行制御の役割分担がなされており、プレイヤ端末１とサーバ１００との協働によって、ゲームが進行可能となる。

（プレイヤ端末１およびサーバ１００のハードウェアの構成）
図２Ａは、プレイヤ端末１のハードウェアの構成を説明する図である。また、図２Ｂは、サーバ１００のハードウェアの構成を説明する図である。図２Ａに示すように、プレイヤ端末１は、ＣＰＵ(Central Processing Unit)１０、メモリ１２、バス１４、入出力インタフェース１６、記憶部１８、通信部２０、入力部２２、出力部２４を含んで構成される。

また、図２Ｂに示すように、サーバ１００は、ＣＰＵ１１０、メモリ１１２、バス１１４、入出力インタフェース１１６、記憶部１１８、通信部１２０、入力部１２２、出力部１２４を含んで構成される。

なお、サーバ１００のＣＰＵ１１０、メモリ１１２、バス１１４、入出力インタフェース１１６、記憶部１１８、通信部１２０、入力部１２２、出力部１２４の構成および機能は、それぞれ、プレイヤ端末１のＣＰＵ１０、メモリ１２、バス１４、入出力インタフェース１６、記憶部１８、通信部２０、入力部２２、出力部２４と実質的に同じである。したがって、以下では、プレイヤ端末１のハードウェアの構成について説明し、サーバ１００については説明を省略する。

ＣＰＵ１０は、メモリ１２に記憶されたプログラムを動作させ、ゲームの進行を制御する。メモリ１２は、ＲＯＭ(Read Only Memory)またはＲＡＭ(Random Access Memory)で構成され、ゲームの進行制御に必要となるプログラムおよび各種のデータを記憶する。メモリ１２は、バス１４を介してＣＰＵ１０に接続されている。

バス１４には、入出力インタフェース１６が接続される。入出力インタフェース１６には、記憶部１８、通信部２０、入力部２２、出力部２４が接続されている。

記憶部１８は、ＤＲＡＭ(Dynamic Random Access Memory)等の半導体メモリで構成され、各種プログラムおよびデータを記憶する。プレイヤ端末１においては、記憶部１８に記憶されたプログラムおよびデータが、ＣＰＵ１０によってメモリ１２（ＲＡＭ）にロードされる。

通信部２０は、通信基地局２００ａと無線により通信接続され、通信ネットワーク２００を介して、サーバ１００との間で各種データおよびプログラムといった情報の送受信を行う。プレイヤ端末１においては、サーバ１００から受信したプログラム等が、メモリ１２または記憶部１８に格納される。

入力部２２は、例えば、プレイヤの操作が入力される（操作を受け付ける）タッチパネル、ボタン、キーボード、マウス、十字キー、アナログコントローラ等で構成される。また、入力部２２は、プレイヤ端末１に設けられた、あるいは、プレイヤ端末１に接続（外付け）された専用のコントローラであってもよい。さらには、入力部２２は、プレイヤ端末１の傾きや移動を検知する加速度センサ、または、プレイヤの音声を検知するマイクで構成されてもよい。すなわち、入力部２２は、プレイヤの意思を、識別可能に入力させることができる装置を広く含む。

出力部２４は、ディスプレイ装置およびスピーカを含んで構成される。なお、出力部２４は、プレイヤ端末１に接続（外付け）される機器でもよい。本実施形態では、プレイヤ端末１が、出力部２４としてディスプレイ２６を備え、入力部２２として、ディスプレイ２６に重畳して設けられるタッチパネルを備えている。

（ゲーム内容）
次に、本実施形態の情報処理システムＳ（ゲーム装置Ｇ）により提供されるゲームの内容について、一例を用いて説明する。本実施形態では、味方キャラクタが敵キャラクタと対戦する所謂バトルゲームが提供される。具体的には、本実施形態のゲームでは、複数の味方キャラクタが提供される。プレイヤは、提供される味方キャラクタの中から複数（ここでは３体）を選択してパーティを編成する。また、プレイヤは、敵キャラクタや難易度が異なる複数種類のバトルゲームをプレイすることができる。バトルゲームでは、パーティに編成された味方キャラクタをプレイヤが操作し、敵キャラクタを倒して報酬を獲得することが目的となる。

図３Ａは、パーティ編成画面の一例を示す図である。図３Ｂは、情報確認画面の一例を説明する図である。図３Ｃは、クエスト画面におけるバトルゲーム選択ページの一例を示す図である。図３Ｄは、クエスト画面におけるプレイ内容選択ページの一例を説明する図である。プレイヤ端末１のディスプレイ２６には、図３Ａ、図３Ｂ、図３Ｃ、図３Ｄに示すようなゲーム画面が表示される。本実施形態では、ゲーム画面が、通常画面とバトル画面とに大別される。

通常画面は、主に、プレイヤが各種の設定、情報の確認を行うための画面である。一方、バトル画面は、バトルゲームの開始から終了までの間、ディスプレイ２６に表示されている画面である。ここでは、バトル画面以外の全ての画面が通常画面となる。通常画面は、不図示のホーム画面と、図３Ａに示すパーティ編成画面と、図３Ｂに示す情報確認画面と、図３Ｃおよび図３Ｄに示すクエスト画面の４つの画面に大別される。

なお、パーティ編成画面およびクエスト画面は複数のページで構成されており、プレイヤの操作によりページが切り替わる。通常画面では、ディスプレイ２６の上部にヘッダ表示領域３０が設けられる。ヘッダ表示領域３０には、プレイヤのスタミナを示すスタミナ表示バー３２が表示される。

なお、スタミナは、バトルゲームをプレイするために必要なパラメータである。本実施形態では、複数種類のバトルゲームが設けられており、各バトルゲームには、プレイに必要なスタミナの消費値が設定されている。プレイヤは、スタミナを消費してバトルゲームをプレイすることになるため、スタミナが不足している場合には、バトルゲームをプレイすることができない。

詳しい説明は省略するが、プレイヤは、バトルゲームで勝利すると、プレイヤ経験値として所定値を獲得することができる。そして、プレイヤ経験値が一定値に到達するごとに、プレイヤレベルが上昇する。プレイヤレベルには、スタミナの上限値が設定されており、プレイヤレベルが上昇するにつれて、スタミナの上限値も高くなる。スタミナは、上限値の範囲内で、一定時間（例えば５分）おきに所定値（例えば１ポイント）だけ回復する。スタミナ表示バー３２は、スタミナの上限値に対して、現在のスタミナの残量が視覚的に把握できるように表示される。

また、ヘッダ表示領域３０の左端には、通知画像３４が表示される。詳しくは後述するが、通知画像３４は、バトルゲームの招待情報、または、イベントの案内情報の受信をプレイヤに報知するものである。招待情報および案内情報のいずれも受信していない状態では、通知画像３４が非報知態様で表示されている。なお、非報知態様の通知画像３４は、全体的に色が薄く表示されている。これに対して、招待情報または案内情報の少なくともいずれかを受信した状態では、通知画像３４が報知態様で表示される。報知態様の通知画像３４は、非報知態様よりも目立つ色で強調表示されている。

また、通常画面では、ディスプレイ２６の下部にメニューバー３６が表示される。メニューバー３６には、プレイヤが操作（タップ）可能な複数の操作部が設けられる。ここでは、操作部の一例として、メニューバー３６に、「Ｈｏｍｅ」と記されたホーム画面選択部３６ａ、「Ｐａｒｔｙ」と記されたパーティ編成画面選択部３６ｂ、「Ｑｕｅｓｔ」と記されたクエスト画面選択部３６ｃ、「Ｉｎｆｏ」と記された情報確認画面選択部３６ｄが設けられている。

ホーム画面選択部３６ａがタップされると、ホーム画面がディスプレイ２６に表示される。また、パーティ編成画面選択部３６ｂがタップされると、図３Ａに示すパーティ編成画面がディスプレイ２６に表示される。同様に、情報確認画面選択部３６ｄがタップされると、図３Ｂに示す情報確認画面がディスプレイ２６に表示され、クエスト画面選択部３６ｃがタップされると、図３Ｃに示すクエスト画面（バトルゲーム選択ページ）がディスプレイ２６に表示される。

上記したように、通常画面は４つの画面に大別されている。メニューバー３６においては、ディスプレイ２６に表示中の画面が識別できるように、各画面に対応する操作部が強調表示される。なお、通常画面内でページが遷移する場合、あるいは、異なる通常画面に遷移する場合には、スタミナ表示バー３２、通知画像３４およびメニューバー３６が表示されたままとなる。つまり、通常画面の画面遷移では、ヘッダ表示領域３０およびメニューバー３６以外の画像が切り替わる。

図３Ａに示すパーティ編成画面では、プレイヤが所持している全ての味方キャラクタが表示される。プレイヤは、表示されている味方キャラクタから、３体の味方キャラクタを選択して、１つのパーティを編成することができる。ここでは、最大で６つのパーティを編成して記憶させることができる。各味方キャラクタには、経験値およびレベルが対応付けて記憶されている。経験値は、後述するバトルゲームで勝利した場合、あるいは、所定のアイテムを使用した場合に上昇する。レベルは、経験値に対応して設定され、経験値が所定値に達するたびにレベルが上昇する。なお、各味方キャラクタには、レベルの上限値が設定されており、上限値の範囲内でのみレベルが上昇する。

また、味方キャラクタには、レベルに応じて、ライフポイント、攻撃力、防御力等の戦闘力のベース値が設定されている。プレイヤは、味方キャラクタの戦闘力が高くなるほど、バトルゲームを有利に進行することができる。また、味方キャラクタに設定される各ベース値は、レベルが高くなるほど上昇する。

さらに、パーティ編成画面において、プレイヤは、パーティに組み込んだ味方キャラクタに対して、武器や防具の装備品を装備させる（設定する）ことができる。各装備品には、攻撃力および防御力等に対する加算値が設定されている。装備品を装備させると、上記のベース値に、各装備品の加算値が加算され、味方キャラクタの戦闘力を高めることができる。

図３Ｂに示す情報確認画面では、プレイヤに関するプレイヤ情報が表示される。プレイヤ情報としては、例えば、プレイヤ名、プレイヤ経験値、プレイヤレベル、プレイヤランク、保有キャラ数（プレイヤが保持している味方キャラクタの数）、フォロワ数、相互フォロワ数が表示される。なお、本実施形態において、フォロワとは、プレイヤが、所謂お気に入り、あるいは戦友として設定した他のプレイヤを示している。また、本実施形態において、相互フォロワとは、互いにフォロワに設定された状態にあるプレイヤを示している。

図３Ｃに示すクエスト画面のバトルゲーム選択ページでは、提供されているバトルゲームの種類、すなわち、バトルゲーム名が記された選択タブ３８が複数表示される。ここでは、１０種類のバトルゲームが提供されており、１０個の選択タブ３８が表示されている。なお、各バトルゲームには、それぞれ開放条件が設定されている。開放条件としては、例えば、プレイヤ経験値、プレイヤレベル、プレイヤランクが所定値以上であること、他の所定のバトルゲームをクリアしていること等が挙げられる。

プレイヤは、開放条件を満たしているバトルゲームのみをプレイすることができる。そのため、バトルゲーム選択ページでは、開放条件を満たしていないバトルゲームの選択タブ３８には、図示のように、鍵付き表示がなされている。また、開放条件を満たしているバトルゲームの選択タブ３８のみが、プレイヤの操作（タップ）を受け付ける。

バトルゲーム選択ページにおいて、選択タブ３８がタップされると、図３Ｄに示すプレイ内容選択ページが表示される。このプレイ内容選択ページでは、パーティ編成画面で編成したパーティの中から、バトルゲームに用いるパーティを選択することができる。また、本実施形態では、プレイ種別として、一人でバトルゲームをプレイするシングルプレイと、通信により他のプレイヤと協力してバトルゲームをプレイするマルチプレイとが設けられている。プレイ内容選択ページには、シングルプレイタブ４０ａおよびマルチプレイタブ４０ｂが表示される。

図４Ａは、シングルプレイ選択時のプレイ内容選択ページの一例を説明する図である。図４Ｂは、バトル画面の一例を説明する図である。図４Ｃは、リザルト画面の一例を説明する図である。図４Ａに示すように、バトルゲームの種類、および、バトルゲームで利用するパーティが選択された状態で、シングルプレイタブ４０ａが操作されると、シングルプレイが開始される。なお、以下では、バトルゲームで用いられるパーティに含まれる味方キャラクタ、すなわち、バトルゲームにおいてプレイヤが操作する味方キャラクタを「プレイヤキャラ」と呼ぶ。バトルゲームでは、プレイヤがプレイヤ端末１の入力部２２を操作して、プレイヤキャラを動作させる。

バトルゲーム中は、図４Ｂに示すように、バトル画面が表示される。バトル画面では、プレイヤキャラと敵キャラクタとがディスプレイ２６に表示される。プレイヤキャラは、プレイヤの操作に応じて動作し、敵キャラクタにダメージを与えたり、敵キャラクタからダメージを受けたりする。また、敵キャラクタは、コンピュータ制御により動作し、プレイヤキャラにダメージを与えたり、プレイヤキャラからダメージを受けたりする。

敵キャラクタにダメージポイントが付与されると、敵キャラクタのライフポイントからダメージポイントが減算される。同様に、プレイヤキャラにダメージポイントが付与されると、プレイヤキャラのライフポイントからダメージポイントが減算される。敵キャラクタのライフポイントが０になるとプレイヤの勝利となり、全てのプレイヤキャラのライフポイントが０になると、プレイヤの敗北となる。

ここで、バトル画面では、図４Ｂに示すように、通常画面で表示されるメニューバー３６が非表示となる。また、ヘッダ表示領域３０においては、スタミナ表示バー３２が非表示となり、プレイヤキャラごとのライフポイントが表示される。さらに、バトル画面においては、ヘッダ表示領域３０に操作タブ４２が表示される。操作タブ４２の表示位置は、ヘッダ表示領域３０のうち、通常画面において通知画像３４の少なくとも一部が表示される位置と同じである。

バトルゲーム中に操作タブ４２がタップされると、バトルゲームが中断される。このとき、ディスプレイ２６には、不図示の中断画面がバトル画面に重畳表示される。中断画面にはリタイア操作部および再開操作部が設けられ、プレイヤは、これらの操作部をタップすることで、バトルゲームのリタイア（終了）または再開を選択することができる。

バトルゲームが正常に終了（正常終了）すると、図４Ｃに示すように、リザルト画面がディスプレイ２６に表示される。本実施形態において、バトルゲームの正常終了には、リタイアによる途中終了、バトルゲームにおいて勝利が確定する勝利終了、バトルゲームにおいて敗北が確定する敗北終了の３つの終了パターンが含まれる。図４Ｃには、一例として、勝利終了時のリザルト画面を示しているが、リザルト画面は、終了パターンごとに異なる。

リザルト画面には、「閉じる」と記された終了操作部４４が表示され、この終了操作部４４がタップされると、ディスプレイ２６の表示が、バトル画面から通常画面に切り替わる。つまり、リザルト画面は、バトル画面の一部である。なお、リザルト画面から切り替わる通常画面は、バトル画面に切り替わる直前に表示されていた画面でもよいし、ホーム画面等、所定の画面であってもよい。このように、リザルト画面の表示終了に伴い、バトルゲームが終了することとなる。

図５Ａは、マルチプレイ選択時のプレイ内容選択ページの一例を説明する図である。図５Ｂは、ルーム選択ページの一例を説明する図である。図５Ｃは、対象者選択ページの一例を説明する図である。図５Ｄは、ルーム詳細ページの一例を説明する図である。図５Ａに示すように、バトルゲームの種類、および、バトルゲームで利用するパーティが選択された状態で、マルチプレイタブ４０ｂがタップされたとする。

この場合、図５Ｂに示すように、クエスト画面のルーム選択ページが表示される。ルーム選択ページでは、「ルーム作成」と記されたルーム作成タブ４６が表示される。本実施形態において、「ルーム」とは、マルチプレイに参加する全てのプレイヤが情報を共有する場を示しており、マルチプレイを行うためにサーバ１００で確保される領域を指す場合もある。

プレイヤは、マルチプレイを行う際に、ルーム作成タブ４６をタップ（要求操作を入力）することで、自身でルームを作成することができる。なお、以下では、マルチプレイにおいてルームを作成したプレイヤをホストプレイヤと呼ぶ。また、他のプレイヤが作成したルームに入室したプレイヤをゲストプレイヤと呼ぶ。

ルーム作成タブ４６がタップされると、図５Ｃに示すように、クエスト画面の対象者選択ページが表示される。対象者選択ページでは、「フォロワ」と記されたフォロワタブ４８ａと、「相互フォロワ」と記された相互フォロワタブ４８ｂと、「ランダム」と記されたランダムタブ４８ｃとが表示される。ルームを作成するプレイヤは、対象者選択ページにおいて、自身が作成したルームに招待する対象者（ゲストプレイヤ）を選択することができる。

具体的には、フォロワタブ４８ａが操作されると、ルームを作成するプレイヤによってフォロワに設定されているプレイヤが、招待情報を受信可能な対象者に設定される。なお、本実施形態において、招待情報は、対象者として設定されたプレイヤのみが受信可能であり、対象者に設定されないプレイヤが招待情報を受信することはない。また、詳しくは後述するが、対象者は、一定の条件を満たさない限り、招待情報を受信することはない。したがって、対象者とは、あくまでも招待情報を受信する権利を得たプレイヤと言える。

相互フォロワタブ４８ｂが操作されると、ルームを作成するプレイヤによって相互フォロワに設定されているプレイヤが対象者に設定される。一方、ランダムタブ４８ｃが操作されると、サーバ１００に登録されている全てのプレイヤの中から対象者が設定される。対象者に設定されたプレイヤのプレイヤ端末１は、サーバ１００と通信を行った際に、招待情報を受信する。招待情報を受信した対象者は、ルームに入室するか否か、すなわち、マルチプレイに参加するか否かを決定することができる。このように、ルームへの入室は、招待情報を受信したプレイヤに限られる。

例えば、図５Ｃに示すように、ランダムタブ４８ｃがタップされると、図５Ｄに示すように、クエスト画面のルーム詳細ページが表示される。ルーム詳細ページでは、ホストプレイヤが選択したパーティを示すパーティ情報を含む種々の情報（ルーム情報）が表示される。また、ホストプレイヤのルーム詳細ページには、「準備完了」と記された開始タブ５０が表示される。ホストプレイヤが開始タブ５０をタップすると、マルチプレイが開始される。

図６Ａは、通常画面における招待情報の受信の報知の一例を説明する図である。図６Ｂは、バトル画面における招待情報の受信の報知の一例を説明する図である。図６Ｃは、招待情報ダイアログ５２の一例を説明する図である。図６Ｄは、保留操作後の画面の一例を説明する図である。例えば、図６Ａに示すように、対象者のプレイヤ端末１において、ディスプレイ２６に情報確認画面が表示されているとする。この状態で、プレイヤ端末１が招待情報を受信すると、図示のように、ヘッダ表示領域３０において、通知画像３４が非報知態様から報知態様に切り替わる。

また、図６Ｂに示すように、対象者のプレイヤ端末１において、ディスプレイ２６にバトル画面が表示されているとする。上記したように、バトル画面では、通常、ヘッダ表示領域３０に操作タブ４２が表示されている（図４Ｂ参照）が、プレイヤ端末１が招待情報を受信すると、図示のように、操作タブ４２が、報知態様の通知画像３４に切り替わる。

報知態様で表示されている通知画像３４がタップされると、図６Ｃに示すように、招待情報ダイアログ５２が表示（開封）される。招待情報ダイアログ５２は、通知画像３４がタップされたときに表示されている画面に重畳表示される。また、バトルゲーム中に通知画像３４がタップされた場合には、操作タブ４２がタップされた場合と同様にバトルゲームが中断され、中断時のバトル画面に重畳して招待情報ダイアログ５２が表示される。

招待情報ダイアログ５２には、クエスト情報として、例えば、ホストプレイヤのプレイヤランクやプレイヤ名、マルチプレイでプレイされるバトルゲームの種類等の情報が表示される。また、招待情報ダイアログ５２には、「参加する」と記された参加タブ５２ａ、「参加しない」と記された拒否タブ５２ｂ、および、「とじる」と記された保留タブ５２ｃが設けられている。

参加タブ５２ａは、マルチプレイへの参加、すなわち、招待されたルームへの入室を希望する参加操作を受け付ける。また、拒否タブ５２ｂは、マルチプレイへの参加を拒否する拒否操作を受け付ける。また、保留タブ５２ｃは、マルチプレイに参加するか否かを保留扱いとする保留操作を受け付ける。

例えば、招待情報ダイアログ５２の開封後に保留タブ５２ｃがタップされ、保留操作が入力されたとする。保留操作が入力されると、図６Ｄに示すように、招待情報ダイアログ５２が閉じられる（非表示となる）。ただし、保留操作が入力された場合、通知画像３４は、報知態様のまま表示され続ける。なお、バトルゲーム中に招待情報ダイアログ５２が表示された状態で、保留操作が入力されると、招待情報ダイアログ５２が閉じられるのと同時に、バトルゲームが再開される。この場合にも、通知画像３４は、報知態様のまま表示され続ける。

図７Ａは、拒否操作前の画面の一例を説明する図である。図７Ｂは、拒否操作後の画面の一例を説明する図である。図７Ａに示すように、招待情報ダイアログ５２の開封後に拒否タブ５２ｂがタップされ、拒否操作が入力されたとする。拒否操作が入力されると、図７Ｂに示すように、招待情報ダイアログ５２が閉じられる（非表示となる）のと同時に、通知画像３４が非報知態様に切り替わる。

なお、バトルゲーム中に招待情報ダイアログ５２が表示された状態で、拒否操作が入力された場合には、招待情報ダイアログ５２が閉じられるのと同時に、バトルゲームが再開される。この場合、ヘッダ表示領域３０においては、通知画像３４が非表示となり、操作タブ４２が表示される。

図７Ｃは、参加操作前の画面の一例を説明する図である。図７Ｄは、参加操作後の画面の一例を説明する図である。図７Ｃに示すように、招待情報ダイアログ５２の開封後に参加タブ５２ａがタップされ、参加操作が入力されたとする。参加操作が入力されると、対象者のプレイヤ端末１からサーバ１００に参加情報が送信される。サーバ１００では、参加情報が入力されると、招待されたルームへの入室可否が判定される。

具体的には、招待されたルームにおいて、マルチプレイが既に開始されている場合（プレイ中）、上限数のゲストプレイヤがルームに入室している場合（満室）、ルームが消滅している場合（解散）には、ルームへの入室が不可能であると判定される。この場合には、プレイヤ端末１のディスプレイ２６に、ルームへの入室が不可能であることを知らせる不図示のダイアログ（入室不可画面）が表示される。

これに対して、サーバ１００において、ルームへの入室が可能であると判定されたとする。この場合、参加情報を送信した対象者のプレイヤ情報がルームに追加され、ルーム情報が更新される。このように、参加操作が行われてルームに入室できた場合には、対象者がゲストプレイヤとして設定される。そして、ルーム情報が更新されると、ホストプレイヤおよび全てのゲストプレイヤが、更新されたルーム情報を受信する。

このとき、ゲストプレイヤのプレイヤ端末１（以下、「ゲスト端末」と呼ぶ）には、図７Ｄに示すように、ルーム詳細ページが表示される。更新されたルーム情報により、ホストプレイヤのプレイヤ情報と、全てのゲストプレイヤのプレイヤ情報とが、ルーム詳細ページに表示される。なお、上記したように、ホストプレイヤのプレイヤ端末１（以下、「ホスト端末」と呼ぶ）に表示されるルーム詳細ページには、開始タブ５０が設けられている。一方で、図７Ｄに示すように、ゲスト端末に表示されるルーム詳細ページには、開始タブ５０が設けられていない。したがって、マルチプレイを開始することができるのは、ホストプレイヤのみとなる。

なお、ゲスト端末に表示されるルーム詳細ページには、ルームから退室する操作を受け付ける操作部が設けられていない。つまり、ゲストプレイヤは、入室したルームから正式に退室することができない。これにより、ゲストプレイヤが入退室を繰り返す事態が抑制され、マルチプレイの早期開始が実現される。ただし、ゲストプレイヤが退室できるように、ゲスト端末のルーム詳細ページに退室用の操作部が設けられてもよい。また、ホスト端末に表示されるルーム詳細ページには、ルームを意図的に解散するための操作部が設けられてもよい。

なお、図示は省略するが、非報知態様で表示されている通知画像３４をタップすると、招待情報が存在しない旨を報知するダイアログが表示される。上記したように、拒否操作がなされると、通知画像３４が非報知態様に切り替わるため、拒否操作の入力後、すぐに通知画像３４が操作されたとしても、招待情報が存在しない旨の報知がなされる。つまり、対象者は、一度参加を拒否したマルチプレイについては、参加することができない。

一方で、上記の保留操作がなされた場合には、招待情報ダイアログ５２が閉じられた後も、通知画像３４が報知態様で表示されている。したがって、保留操作を行った後に、再度、通知画像３４がタップされると、招待情報ダイアログ５２が再表示され、対象者は、招待されたマルチプレイに対して参加操作を入力することができる。ただし、上記したように、招待されたルームが、プレイ中、満室、消滅となっている場合には、ルームへの入室が不可能であると判定され、ルームへの入室が不可能であることを知らせるダイアログが表示される。

図８Ａは、通常画面における案内情報の受信の報知態様の一例を説明する図である。図８Ｂは、案内情報ダイアログ５４の一例を説明する図である。図８Ｃは、非表示操作後の画面の一例を説明する図である。図８Ｄは、閲覧操作後の画面の一例を説明する図である。本実施形態では、プレイヤ端末１がイベントの案内情報を受信する。案内情報は、運営者によってサーバ１００にセットされ、プレイヤ端末１は、サーバ１００と通信を行った際に、サーバ１００から案内情報を受信する。

案内情報の受信は、招待情報の受信と同様、通知画像３４によってプレイヤに報知される。例えば、図８Ａに示すように、ディスプレイ２６に情報確認画面が表示されている状態で案内情報を受信すると、通知画像３４が報知態様に切り替わる。この状態で通知画像３４がタップされると、図８Ｂに示すように、案内情報ダイアログ５４が表示（開封）される。案内情報ダイアログ５４は、通知画像３４がタップされたときに表示されている画面に重畳表示される。また、バトルゲーム中に通知画像３４がタップされた場合には、バトルゲームが中断され、中断時のバトル画面に重畳して案内情報ダイアログ５４が表示される。

案内情報ダイアログ５４には、例えば、定期的に開催されるクエストに関する情報が表示される。また、案内情報ダイアログ５４には、「とじる」と記された非表示タブ５４ａと、「イベントへ」と記された閲覧タブ５４ｂとが設けられている。非表示タブ５４ａは、案内情報ダイアログ５４の表示を終了させる非表示操作を受け付ける。また、閲覧タブ５４ｂは、イベント情報を閲覧する閲覧操作を受け付ける。

例えば、案内情報ダイアログ５４の開封後に非表示タブ５４ａがタップされ、非表示操作が入力されたとする。非表示操作が入力されると、図８Ｃに示すように、案内情報ダイアログ５４が閉じられる（非表示となる）。ただし、非表示操作が入力された場合、通知画像３４は、報知態様のまま表示され続ける。なお、バトルゲーム中に案内情報ダイアログ５４が表示された状態で、非表示操作が入力されると、案内情報ダイアログ５４が閉じられるのと同時に、バトルゲームが再開される。この場合にも、通知画像３４は、報知態様のまま表示され続ける。ただし、非表示タブ５４ａから非表示操作が入力された場合、通知画像３４は、報知態様から非報知態様に切り替わってもよい。

一方、案内情報ダイアログ５４の開封後に閲覧タブ５４ｂがタップされ、閲覧操作が入力されたとする。閲覧操作が入力されると、図８Ｄに示すように、参加可能なイベント情報が記されたイベント案内画面が表示される。詳しい説明は省略するが、イベント案内画面では、プレイヤの操作入力が可能であり、入力された操作により、イベントへの参加が可能となる。なお、イベント案内画面が表示されると、通知画像３４は、非報知態様に切り替わる。

以上のように、通知画像３４は、招待情報および案内情報の２種類の情報について、その受信を報知する。ここでは、受信した情報の種別に拘わらず、共通の報知態様で通知画像３４が表示される。なお、招待情報および案内情報の双方を受信している場合において、報知態様で表示されている通知画像３４がタップされたとする。この場合、ディスプレイ２６には、招待情報ダイアログ５２が表示される。つまり、招待情報（招待情報ダイアログ５２）は、案内情報（案内情報ダイアログ５４）よりも優先的に表示される。

ただし、招待情報および案内情報の双方を受信している場合に、案内情報（案内情報ダイアログ５４）が、招待情報（招待情報ダイアログ５２）よりも優先的に表示されてもよい。あるいは、案内情報（案内情報ダイアログ５４）と、招待情報（招待情報ダイアログ５２）とが同時に表示されてもよい。さらには、通知画像３４は、招待情報の受信のみを報知してもよい。また、通知画像３４は、招待情報の受信と、案内情報の受信とを識別可能に報知してもよい。なお、ここでは、プレイヤ端末１が案内情報を受信することとしたが、案内情報は必須ではない。

ここで、本実施形態では、ホストプレイヤが対象者を招待し、対象者がゲストプレイヤとしてルームに入室することで、はじめて複数のプレイヤでマルチプレイを実行することができる。また、マルチプレイを開始する権限は、ホストプレイヤにのみ与えられている。そのため、ゲストプレイヤがルームに入室し、マルチプレイを開始できる状態になっているにも拘わらず、ホストプレイヤが開始タブ５０を操作せずに放置すると、マルチプレイがいつまでも開始されず、ゲストプレイヤにストレスが与えられてしまう。そこで、本実施形態では、ホストプレイヤによる放置を減少させるべく、サーバ１００における対象者の抽出と、プレイヤ端末１における招待情報の受信ならびに報知とが次のようになされている。以下では、まず、サーバ１００における対象者の抽出方法について説明し、その後、プレイヤ端末１における招待情報の受信ならびに報知方法について説明する。

（対象者の抽出方法）
図９Ａは、優先ポイントを説明する図である。図９Ｂは、優先ポイントの更新条件を説明する図である。サーバ１００は、プレイヤ情報をプレイヤ（プレイヤＩＤ）ごとに記憶する。プレイヤ情報には、例えば、プレイヤ経験値、プレイヤレベル、プレイヤランク、保有キャラクタ、フォロワ、相互フォロワ、パーティ情報等、ゲームをプレイするために必要な種々の情報が含まれる。

また、プレイヤ情報には、招待情報を受信する対象者を抽出するための情報として、優先度情報が含まれる。サーバ１００は、優先度情報を含むプレイヤ情報をプレイヤごとに記憶部１１８に蓄積し、予め設定された更新条件にしたがって優先度情報を更新する。

本実施形態では、優先度情報として、優先ポイントが設けられている。図９Ａに示すように、優先ポイントは、最大値が９９９ポイント、最小値が０ポイントに設定されており、０から９９９の範囲で更新される。また、優先ポイントには、初期値として１００ポイントが設定されており、所定の更新条件が成立すると、優先ポイントが初期値に更新される。

ルームを作成する際に、ランダムタブ４８ｃがタップされた場合、サーバ１００では、全プレイヤの中から、招待情報を受信可能な対象者をランダムに抽出する。このとき、サーバ１００は、優先ポイントが高いプレイヤを優先的に対象者に設定する。したがって、優先ポイントが高いプレイヤほど、招待情報を受信しやすくなる。

優先ポイントの更新条件は、図９Ｂに示すように設定されている。具体的には、対象者として招待情報を受信した場合には、当該対象者の優先ポイントが「４」減算される。また、対象者が招待情報を受信した後、通知画像３４をタップして招待情報ダイアログ５２を開封した場合には、当該対象者の優先ポイントが「１」加算される。

また、対象者が招待情報ダイアログ５２の参加タブ５２ａをタップして参加操作を行ったものの、マルチプレイに参加できなかった場合には、当該対象者の優先ポイントが「４」加算される。なお、マルチプレイに参加できない場合としては、プレイ中または満室によりルームに入室できない場合と、ルームに入室した後、マルチプレイの開始前にルームが解散した場合とがある。ここでは、マルチプレイに参加できなかった場合に、対象者の優先ポイントが加算されることとしたが、これに代えて、例えば、ルームに入室できなかった場合に、対象者の優先ポイントが加算されてもよい。

また、マルチプレイによるバトルゲームが正常に終了（リタイアによる途中終了、勝利終了および敗北終了を含む）したとする。このとき、バトルゲームの終了時におけるゲストプレイヤの優先ポイントが、初期値よりも大きい場合には、当該ゲストプレイヤの優先ポイントが初期値にリセットされる。

また、ホストプレイヤとしてルームを作成した場合には、当該ホストプレイヤの優先ポイントが「４」減算される。また、このとき、ランダムタブ４８ｃをタップして、招待情報を受信する対象者をランダムに抽出した場合には、ホストプレイヤの優先ポイントが「１」加算される。また、マルチプレイが開始された場合には、ホストプレイヤの優先ポイントが「１」加算される。

さらに、マルチプレイによるバトルゲームが勝利終了もしくは敗北終了となった場合において、敵キャラクタに与えたダメージ（以下、「与ダメージ」と呼ぶ）が、全ダメージの２０％以上の全てのプレイヤについて、優先ポイントが「３」加算される。

上記の更新条件によれば、例えば、対象者が、マルチプレイに参加しようとしたものの参加できなかった場合には、招待情報の受信（−４）、招待情報の開封（＋１）、マルチプレイに参加不可（＋４）により、招待情報の受信前を基準として、優先ポイントが「１」上昇する。これにより、マルチプレイに参加しようとしたものの、参加できなかったプレイヤが、招待情報を受信しやすくなる。また、優先ポイントが初期値を上回った状態で、マルチプレイによるバトルゲームが正常に終了すると、初期値にリセットされる。これにより、多くのプレイヤに対して、招待情報を受信する機会が平等に付与される。

また、マルチプレイに参加したゲストプレイヤにおいて、与ダメージが全ダメージの２０％以上になれば、招待情報の受信（−４）、招待情報の開封（＋１）、与ダメージが２０％以上（＋３）により、マルチプレイの参加前を基準として、優先ポイントはプラスマイナスゼロとなる。一方で、与ダメージが全ダメージの２０％未満のゲストプレイヤは、招待情報の受信（−４）、および、招待情報の開封（＋１）により、マルチプレイの参加前を基準として、優先ポイントが「３」減算される。つまり、マルチプレイにおいて非協力的なゲストプレイヤは、優先度が低くなり、対象者に設定されにくくなる。このように、通信ゲーム中のゲーム結果に基づいて優先ポイントを変化させることにより、協力的なプレイヤが相対的に対象者に設定されやすくなる。

また、ホストプレイヤは、ルームを作成した時点で優先ポイントが「４」減算されるが、マルチプレイを開始し、与ダメージが全ダメージの２０％以上となれば、優先ポイントが減少することはない。具体的には、対象者をランダムに抽出した場合には、ルーム作成（−４）、対象者をランダムに抽出（＋１）、マルチプレイ開始（＋１）、与ダメージが２０％以上（＋３）により、ルームの作成前を基準として、優先ポイントが「１」上昇する。また、対象者をフォロワまたは相互フォロワに設定した場合には、ルーム作成（−４）、マルチプレイ開始（＋１）、与ダメージが２０％以上（＋３）により、ルームの作成前を基準として、優先ポイントはプラスマイナスゼロとなる。これにより、ホストプレイヤとして、適切にマルチプレイを開始し、かつ、協力的にプレイした場合には、優良なプレイヤであると考えられ、ゲストプレイヤとしてマルチプレイに参加する機会も確保される。

一方で、ルームを作成したものの、マルチプレイを開始しなかった場合には、例えば、ルーム作成（−４）、および、対象者をランダムに抽出（＋１）により、ルームの作成前を基準として、優先ポイントが「３」減少する。また、ホストプレイヤの与ダメージが全ダメージの２０％未満である場合にも、例えば、ルーム作成（−４）、対象者をランダムに抽出（＋１）、マルチプレイ開始（＋１）により、ルームの作成前を基準として、優先ポイントが「２」減少する。これにより、ルームを放置したり、意図的にルームを解散したりするプレイヤや、非協力的なプレイヤは、ゲストプレイヤとしてマルチプレイに参加しにくくなる。

以上のように更新条件が設定された本実施形態によれば、協力的あるいは優良と思われるプレイヤに招待情報が届きやすくなり、適切なマッチングを実現することができる。以下では、全プレイヤの中から対象者を設定する際のサーバ１００の処理について説明する。

（サーバ１００のリスト更新処理）
図１０は、リスト更新処理を説明する第１の図である。サーバ１００の記憶部１１８には、プレイヤごとにプレイヤ情報を記憶するプレイヤ情報記憶部１６０（図２７参照）が設けられている。サーバ１００では、プレイヤ端末１と通信が行われるたびに、プレイヤ情報記憶部１６０におけるプレイヤ情報を更新するプレイヤ情報更新処理が行われる。また、記憶部１１８には、抽出リストが設けられている。サーバ１００では、プレイヤ情報記憶部１６０のプレイヤ情報に基づいて、抽出リストを更新するリスト更新処理が常時行われている。

例えば、記憶部１１８に設けられる抽出リストでは、図１０に示すように、アドレスが付された多数の記憶領域のそれぞれに、プレイヤ（プレイヤＩＤ）、招待情報（ルームナンバー）、状況フラグおよびウエイトタイムがセットされる。なお、図１０に示す抽出リスト、および、抽出リストにセットされる情報は一例に過ぎない。例えば、抽出リストにセットされる情報として、優先ポイントおよびプレイヤランクは必須ではなく、抽出リストにセットされる情報は適宜設計可能である。また、図１０において、アドレスに記した番号は優先順位に対応しており、番号が小さい記憶領域ほど、優先順位が高くなる。

また、抽出リストは、プレイヤランクごとに設けられている。例えば、プレイヤランクが１〜１０のプレイヤがリストアップされる抽出リスト、プレイヤランクが１１〜２０のプレイヤがリストアップされる抽出リストといった具合に、複数の抽出リストが設けられている。ここでは、プレイヤランクが１１〜２０のプレイヤがリストアップされる抽出リストを用いて説明する。

抽出リストにおいては、優先ポイントが高いプレイヤほど、優先順位の高いアドレスが付された記憶領域にリストアップされる。例えば、プレイヤランクが１１〜２０のプレイヤの中で、「１６５」の優先ポイントが最高値であったとする。また、優先ポイントが最高値のプレイヤが５人いたとする。この場合、優先ポイントが「１６５」のプレイヤのプレイヤ情報が、アドレス１から５の記憶領域にセットされる。なお、優先ポイントが等しいプレイヤが複数存在する場合には、所定の条件にしたがってアドレス（優先順位）が決定される。このように、リスト更新処理では、プレイヤ情報記憶部１６０のプレイヤ情報に基づき、優先ポイントが高いプレイヤから順に、抽出リストにリストアップする処理が行われる。

図１１は、リスト更新処理を説明する第２の図である。例えば、いずれかのプレイヤ端末１において、ルームの作成、および、招待情報の送付を要求する要求情報が送信されたとする。なお、要求情報は、フォロワタブ４８ａ、相互フォロワタブ４８ｂ、ランダムタブ４８ｃごとに識別可能に設けられている。サーバ１００では、要求情報を受信すると、ルームを作成、設定するルーム設定処理が行われる。このとき、受信した要求情報が、ランダムタブ４８ｃ用の要求情報であった場合、リスト更新処理において、次のようにして対象者が設定される。

すなわち、図１１に示すように、招待情報は、優先順位の高いアドレスが付された記憶領域から順に、所定数（ここでは１００個）の記憶領域までセットされる。ただし、招待情報がセットされる記憶領域は、状況フラグに基づいて決定される。

具体的には、状況フラグは、招待情報の受信状況を識別するものであり、ここでは、「設定可」、「受信可」、「受信不可」、「受信済」の４つの受信状況に識別される。受信状況の「設定可」は、招待情報の設定が可能であることを示している。記憶領域において、状況フラグが記憶される領域がブランクの場合（状況フラグがオフの場合）、受信状況が「設定可」となる。また、受信状況の「受信可」は、対象者に設定されたプレイヤ端末１（以下、「対象者端末」と呼ぶ）から受信確認があった場合に、設定されている招待情報の受信を許可することを示している。また、受信状況の「受信不可」は、対象者端末から受信確認があった場合に、設定されている招待情報の受信を制限することを示している。また、受信状況の「受信済」は、対象者端末が招待情報を受信したことを示している。

サーバ１００は、優先順位の高いアドレスが付された記憶領域から、受信状況が「設定可」、すなわち、状況フラグがブランクの記憶領域を順に検索して招待情報を設定する。例えば、図１０に示す状態では、アドレス１〜１００の全ての記憶領域において状況フラグがブランクである。この状態において、プレイヤランクが１１〜２０のプレイヤのプレイヤ端末１から、ランダムタブ４８ｃ用の要求情報を受信すると、図１１に示すように、アドレス１〜１００の記憶領域に招待情報がセットされる。

また、招待情報がセットされた記憶領域には、状況フラグがセットされる。このとき、招待情報がセットされた記憶領域のうち、優先ポイントが最高の記憶領域には、「受信可」を示す状況フラグがセットされる。また、招待情報がセットされたその他の記憶領域には、「受信不可」を示す状況フラグがセットされる。さらに、「受信不可」の状況フラグがセットされた記憶領域には、それぞれウエイトタイムが設定される。

このウエイトタイムは、受信状況を「受信不可」から「受信可」に切り替えるまでの時間である。つまり、「受信不可」の状況フラグが設定された場合、ウエイトタイムが経過したところで、状況フラグが「受信可」に切り替わる。各記憶領域は、優先ポイントごとにグループ化され、同一グループに分類される記憶領域には、同一のウエイトタイムが設定される。また、ウエイトタイムは、優先ポイントが相対的に低いグループよりも、優先ポイントが相対的に高いグループの方が短く設定される。

図１１に示す例では、優先ポイントが「１６４」のグループは、ウエイトタイムが５秒に設定され、優先ポイントが「１６３」のグループは、ウエイトタイムが１０秒に設定される。このように、ウエイトタイムは、優先ポイントが高いほど短くなり、優先ポイントが低くなるにつれて長くなる。

図１２は、リスト更新処理を説明する第３の図である。図１１に示すようにして招待情報、状況フラグおよびウエイトタイムがセットされた後、例えば、５秒が経過したとする。上記したように、アドレス６〜９９の記憶領域は、ウエイトタイムが５秒に設定されている。このウエイトタイムである５秒が経過すると、図１２に示すように、アドレス６〜９９の記憶領域の状況フラグが「受信可」に切り替わる。なお、アドレス１００の記憶領域には、当初、ウエイトタイムとして１０秒が設定されたため、受信状況は「受信不可」のままであり、ウエイトタイムが５秒に更新されている。

上記したように、受信状況が「受信不可」の場合には、招待情報がセットされているものの、プレイヤ端末１が招待情報を受信することができない。すなわち、招待情報がセットされている状態で、プレイヤ端末１から受信確認がなされたとしても、プレイヤ端末１が招待情報を受信することはない。このように、サーバ１００は、招待情報をセットすることで対象者を設定した際に、優先ポイントが高いプレイヤほど、早期に招待情報を受信できるようにしている。これにより、優先順位の高いプレイヤほど、マルチプレイに参加しやすくなる。

また、上記の状態で、新たに他のプレイヤ端末１から、ランダムタブ４８ｃ用の要求情報が送信されたとする。この場合、図１２に示すように、アドレス１０１〜２００の記憶領域に招待情報がセットされる。なお、アドレス１０１〜２００の記憶領域は、いずれも優先ポイントが１６３である。したがって、ここでは、アドレス１０１〜２００の記憶領域の全てにおいて、「受信可」の状況フラグが設定されている。

図１３は、リスト更新処理を説明する第４の図である。例えば、図１２に示す状態で、アドレス１およびアドレス３の記憶領域において対象者に設定された対象者端末から、招待情報の受信確認がなされたとする。この場合、両プレイヤの対象者端末は、記憶領域にセットされた招待情報を受信する。サーバ１００は、招待情報が受信されると、図１３の上図に示すように、状況フラグを「受信可」から「受信済」に切り替える。

また、上記のように、対象者が招待情報を受信すると、対象者の優先ポイントが「４」減算される。サーバ１００は、アドレス１およびアドレス３の記憶領域において、優先ポイントを「１６１」に更新する。その後、サーバ１００は、優先ポイントに基づいてソート処理を行う。このソート処理の結果、アドレス１およびアドレス３の記憶領域に記憶されていた情報は、図１３の下図に示すように、優先順位が低いアドレス（記憶領域）に移されることとなる。

なお、詳しくは後述するが、フォロワタブ４８ａ用の要求情報が送信された場合には、フォロワに設定されているプレイヤの記憶領域に招待情報がセットされる。また、相互フォロワタブ４８ｂ用の要求情報が送信された場合には、相互フォロワに設定されているプレイヤの記憶領域に招待情報がセットされる。

上記のリスト更新処理によれば、マルチプレイへの参加意欲が高いプレイヤが、招待情報を受信しやすくなる。参加意欲の高いプレイヤが招待情報を受信することで、マルチプレイを開始するまでの時間が短縮される。

さらに、本実施形態では、プレイヤ端末１におけるゲームのプレイ状況に応じて招待情報が受信される。具体的には、プレイヤがバトルゲーム（シングルプレイ）をプレイしている場合や、ゲームをプレイするために画面を注視していると考えられる状況下で、招待情報の受信が報知される。すなわち、プレイヤ端末１においては、マルチプレイへの参加意欲が高く、招待に対する応答性が高いと考えられる状況下で、招待情報の受信の報知がなされる。これにより、マルチプレイに参加するプレイヤが集まるまでの時間が短縮され、マルチプレイを開始するまでの時間を短縮することができる。

（プレイヤ端末１のプレイ状態）
図１４Ａは、プレイヤ端末１のプレイ状態を説明する図である。図１４Ｂは、招待情報の受信確認のタイミングを説明する図である。プレイヤ端末１は、ゲームのプレイ状況、および、招待情報の受信状況に基づいて、プレイ状態を更新する。図１４Ａに示すように、プレイヤ端末１で管理されるプレイ状態は、受け取り可能状態、未開封状態、開封済状態、参加状態、受け取り不可状態の５つである。つまり、プレイヤ端末１では、プレイ状態が、上記５つのプレイ状態のいずれかに設定される。プレイヤ端末１は、設定されているプレイ状態に基づいて、招待情報の受信に係る処理を実行する。

各プレイ状態には、招待情報の受信可否が対応付けられている。プレイヤ端末１は、プレイ状態が受け取り可能状態もしくは未開封状態に設定されている場合、サーバ１００から招待情報を受信し得る。つまり、プレイ状態のうち、受け取り可能状態および未開封状態は、招待情報の受信が許可された許可状態と言える。一方、プレイヤ端末１は、プレイ状態が開封済状態、参加状態、受け取り不可状態に設定されている場合、サーバ１００から招待情報を受信することはない。つまり、プレイ状態のうち、開封済状態、参加状態、受け取り不可状態は、招待情報の受信が不可能な不可能状態と言える。

例えば、サーバ１００において、プレイヤが対象者に設定され、当該プレイヤに対する招待情報がサーバ１００にセットされたとする。このとき、プレイヤ端末１において、プレイ状態が受け取り可能状態または未開封状態に設定されていれば、プレイヤ端末１がサーバ１００から招待情報を受信する。一方で、招待情報がサーバ１００にセットされていても、プレイ状態が開封済状態、参加状態、受け取り不可状態に設定されていれば、プレイヤ端末１はサーバ１００から招待情報を受信しない。換言すれば、プレイヤ端末１は、プレイ状態が開封済状態、参加状態、受け取り不可状態に設定されている場合、招待情報の受信確認を実行しない。

なお、詳しい説明は省略するが、プレイ状態が許可状態であっても、セットされた招待情報によっては、プレイヤ端末１が招待情報を受信しないことがある。例えば、ゲストプレイヤとしてバトルゲームのマルチプレイに参加した場合、このバトルゲームと同一種別のバトルゲームへの招待情報は、参加したマルチプレイの終了後、６０分間は受信しない。このように、プレイ状態が許可状態である場合、原則的には、招待情報を受信可能であるが、招待情報の内容によっては、一部の招待情報の受信が制限されてもよい。

図１４Ａに示すように、上記の各プレイ状態には、それぞれ設定条件が設けられている。プレイヤ端末１は、設定条件の成立有無を判定し、その判定結果に基づいてプレイ状態を設定する。受け取り可能状態には、招待情報を未受信であること、マルチプレイのルームに入室していないこと、後述する受け取り不可状態の設定条件が成立しないことが、設定条件として設けられている。未開封状態には、招待情報を受信していること、および、招待情報ダイアログ５２が未開封であることが、設定条件として設けられている。

開封済状態には、招待情報ダイアログ５２が表示中であること、および、保留操作が入力（招待情報ダイアログ５２の保留タブ５２ｃがタップ）されたことが、設定条件として設けられている。参加状態には、マルチプレイのルームに入室中であることが設定条件として設けられている。受け取り不可状態には、マルチプレイの正常終了から５分が経過していないこと、拒否操作から所定時間が経過していないことが、設定条件として設けられている。なお、３０分以内に拒否操作が２回入力された場合、２回目の拒否操作から６０分間、受け取り不可状態に維持され、その他の場合には、拒否操作から５分間、受け取り不可状態に維持される。

プレイヤ端末１は、プレイ状態が許可状態に設定されている場合、サーバ１００に対して招待情報の受信確認を行う。このとき、自身に対する招待情報がセットされていれば、プレイヤ端末１が、セットされている招待情報を受信する。つまり、招待情報の受信は、招待情報の受信確認を契機として行われる。したがって、厳密には、プレイ状態ごとに、招待情報の受信確認の可否が予め設定されていると言える。

上記したように、サーバ１００では、マルチプレイへの参加意欲が高いプレイヤが対象者に設定される。しかしながら、こうした参加意欲の高いプレイヤであっても、プレイヤ端末１におけるゲームのプレイ状況によっては、マルチプレイに即座に参加できないこともある。例えば、短時間の移動中や、マルチプレイを終了した直後等には、マルチプレイへの参加意欲が低下する。このように、マルチプレイへの参加意欲が低い状態でマルチプレイに参加すると、協力的なプレイがなされない可能性がある。

本実施形態では、プレイヤ端末１におけるゲームのプレイ状況に応じて招待情報が受信される。すなわち、サーバ１００において、招待情報がセットされていたとしても、プレイヤ端末１におけるゲームのプレイ状況によっては、招待情報を受信しない。つまり、マルチプレイに参加しない可能性が高い場合には、そもそもプレイヤ端末１が招待情報を受信しないようにしている。これにより、参加意欲が低下しているプレイヤがマルチプレイに参加する可能性が低減される。また、マルチプレイに参加できない状態で招待情報を何度も受信することがないため、プレイヤに鬱陶しさを感じさせないようにすることができる。

ここで、プレイヤ端末１における招待情報の受信確認は、図１４Ｂに示すように行われる。すなわち、プレイヤ端末１のディスプレイ２６にバトル画面が表示されている場合、１５秒間隔で招待情報の受信確認が行われる。ただし、ディスプレイ２６において、通常画面（バトル画面以外の画面）からバトル画面に遷移した場合、画面遷移後、最初に招待情報の受信確認を行うタイミングは、１〜１５秒の間で抽選によりランダムに決定される。

また、プレイヤ端末１のディスプレイ２６に通常画面（バトル画面以外の画面）が表示されている場合、１０秒間隔で招待情報の受信確認が行われる。ただし、ディスプレイ２６において、バトル画面から通常画面に遷移した場合、通常画面が他の通常画面に遷移した場合、通常画面内でページが遷移した場合には、画面遷移後、最初に招待情報の受信確認を行うタイミングは、１〜１０秒の間で抽選によりランダムに決定される。

上記のように、画面遷移後、最初に招待情報の受信確認を行うタイミングをランダムに決定することで、招待情報を受信するためだけに画面を遷移させるといったプレイヤの操作を防止することができる。これにより、サーバ１００との不必要な通信が抑制され、サーバ１００の負荷が軽減される。

また、バトル画面の表示中は、通常画面の表示中よりも、招待情報の受信確認の間隔が長く設定されている。これにより、招待情報の受信を目的とする不必要なバトルゲームの実行が抑制され、サーバ１００の負荷増大を抑制することができる。

次に、上記のマルチプレイを実行するためのプレイヤ端末１およびサーバ１００の通信処理について説明する。なお、ここでは、ゲームを進行するための基本的な通信処理、ならびに、マルチプレイに関する主な通信処理の一例について説明し、その他の処理については説明を省略する。

（プレイヤ端末１とサーバ１００との通信処理）
図１５は、プレイヤ端末１およびサーバ１００の基本的な処理を説明するシーケンス図である。なお、以下の説明では、ホスト端末、ゲスト端末および対象者端末を区別しない場合には、プレイヤ端末１における処理をＰｎ（ｎは任意の整数）と示す。また、サーバ１００における処理をＳｎ（ｎは任意の整数）と示す。プレイヤ端末１においてプレイヤがゲームアプリケーションを起動すると（Ｐ１）、プレイヤ端末１からサーバ１００にログイン情報が送信される。サーバ１００は、ログイン情報を受信すると、プレイヤ端末１を特定してログイン処理を行う（Ｓ１）。ここでは、サーバ１００は、特定したプレイヤ端末１に対応するプレイヤ情報を、プレイヤ端末１が記憶部１１８からダウンロード可能にする。

また、プレイヤ端末１は、プレイ状態が許可状態である場合、所定時間おきに招待情報の受信確認を行う（Ｐ２）。ここでは、プレイヤ端末１が、受信確認情報をサーバ１００に送信する。サーバ１００は、受信確認情報を受信すると、抽出リストにおいて、プレイヤ端末１の招待情報の有無を検索する（Ｓ２）。このとき、招待情報がセットされており、かつ、受信状況が「受信可」に設定されていれば、プレイヤ端末１が招待情報を受信する。プレイヤ端末１は、招待情報を受信すると、通知画像３４を報知態様で表示させ、招待情報を受信した旨を報知する（Ｐ３）。

また、プレイヤ端末１において、プレイ内容選択ページ（図４Ａ参照）からシングルプレイタブ４０ａがタップされ、シングルプレイの開始操作がなされたとする（Ｐ４）。この場合、プレイヤ端末１からサーバ１００に開始情報が送信される。なお、この開始情報には、プレイヤが選択したパーティ情報、バトルゲームの種別情報等が含まれる。サーバ１００では、開始情報の入力により、バトルゲームを開始するために必要となるバトルゲーム開始処理が行われる（Ｓ３）。ここでは、例えば、バトルゲームを進行するためのメモリ１１２の領域を確保し、プレイヤ端末１から入力された情報を記憶したり、所定のプログラムを記憶部１１８からメモリ１１２に読み出したりする。また、サーバ１００は、プレイヤ端末１が、バトルゲームの実行に必要なデータを受信できるようにセットする。

そして、プレイヤ端末１においても、バトルゲームを開始するために必要となるバトルゲーム開始処理が行われる（Ｐ５）。ここでは、例えば、バトルゲームを進行するためのメモリ１２の領域を確保し、ゲームプレイ情報を記憶したり、サーバ１００からダウンロードしたプログラムおよび画像データをメモリ１２に記憶したりする。なお、バトルゲームに必要となるプログラム等は、記憶部１８からメモリ１２に読み出してもよい。

上記のようにしてバトルゲームの準備が完了すると、プレイヤ端末１およびサーバ１００の双方において、シングルプレイによるバトルゲームを制御するためのバトルゲーム制御処理が同時並行して行われる（Ｐ６、Ｓ４）。このバトルゲーム制御処理では、各種情報を更新する更新処理が、フレーム単位で繰り返し実行される。なお、フレーム数は特に限定されるものではなく、例えば、１秒間のフレーム数は３０〜６０である。したがって、バトルゲーム中は、プレイヤ端末１およびサーバ１００において、約１６ｍｓ（ミリ秒）〜３３ｍｓごとに情報の更新が行われている。

また、更新処理では、プレイヤ端末１とサーバ１００との間で、更新情報の送受信が行われている。ここでは、更新処理および更新情報の送受信がフレーム単位で実行されるが、更新処理および更新情報の送受信は、フレーム単位よりも短い周期あるいは長い周期で行われてもよい。また、シングルプレイによるバトルゲーム中も、プレイヤ端末１における招待情報の受信確認（Ｐ７）、サーバ１００における招待情報の検索（Ｓ５）、プレイヤ端末１における招待情報の受信の報知（Ｐ８）が定期的に実行され得る。そして、バトルゲームの終了条件が成立すると、プレイヤ端末１およびサーバ１００のそれぞれにおいて、バトルゲームを終了させる終了処理が行われる（Ｐ９、Ｓ６）。プレイヤ端末１の終了処理（Ｐ９）では、例えば、リザルト画面がディスプレイ２６に表示される。また、サーバ１００の終了処理（Ｓ６）では、例えば、バトルゲームで獲得したアイテム、プレイヤ経験値、キャラクタの経験値等、各種のプレイヤ情報が更新される。

図１６は、マルチプレイが実行される場合のプレイヤ端末１およびサーバ１００の処理を説明するシーケンス図である。なお、以下の説明では、ホスト端末における処理をＨＰｎ（ｎは任意の整数）と示し、対象者端末およびゲスト端末における処理をＧＰｎ（ｎは任意の整数）と示す。

プレイヤ端末１（ホスト端末）において、ルーム作成タブ４６がタップされ、要求操作が入力されたとする（ＨＰ１０）。要求操作が入力されると、プレイヤ端末１（ホスト端末）は、サーバ１００に対して、ルームの作成、および、招待情報の送付を要求する要求情報を送信する。なお、要求情報には、プレイヤが選択したパーティに係る情報、バトルゲームの種別を示す情報、タップされた操作部を示す情報等が含まれる。

サーバ１００は、要求情報を受信すると、プレイヤ情報記憶部１６０において、優先ポイントを更新するポイント更新処理（図中、ＵＰＤＡＴＥと示す）を行う。ここでは、要求情報を送信したホストプレイヤの優先ポイントが「４」減算される。また、詳しくは後述するが、プレイヤ情報記憶部１６０においてポイント更新処理が行われると、抽出リストの優先ポイントも、プレイヤ情報記憶部１６０と同様に更新される。また、抽出リストにおいては、更新された優先ポイントに基づいてソート処理が行われる。

また、サーバ１００は、要求情報を受信すると、ルームを作成、設定するルーム設定処理を行う（Ｓ１０）。ここでは、マルチプレイを実行するための処理領域、すなわち、ルームが確保され、このルームに、要求情報に含まれる各種の情報が記憶される。また、作成したルームのルームナンバーが設定される。ホスト端末は、ルーム設定処理で設定されたルーム設定情報を受信し、ディスプレイ２６にルーム詳細ページを表示する（ＨＰ１１）。

また、サーバ１００は、対象者を設定する（Ｓ１１）。ここでは、招待情報、状況フラグ、ウエイトカウンタのカウンタ値が抽出リストにセットされ、対象者の設定が行われる。その後、対象者端末が招待情報の受信確認を行うと（ＧＰ１０）、受信確認情報がサーバ１００に送信される。サーバ１００は、受信確認情報を受信すると、対象者に招待情報がセットされているかを検索する（Ｓ１２）。ここでは、招待情報がセットされているため、サーバ１００が、対象者の受信状況（状況フラグ）を「受信済」に更新する。また、サーバ１００は、ポイント更新処理を行い、招待情報を受信した対象者の優先ポイントを「４」減算する。

対象者端末は、招待情報を受信すると、通知画像３４を報知態様で表示させ、招待情報を受信した旨を報知する（ＧＰ１１）。また、対象者端末は、プレイ状態を受け取り可能状態から未開封状態に更新する（ＧＰ１２）。その後、対象者が通知画像３４をタップし、招待情報ダイアログ５２が開封されると（ＧＰ１３）、サーバ１００に開封情報が送信される。サーバ１００は、開封情報を受信すると、ポイント更新処理を行う。ここでは、対象者の優先ポイントが「１」加算される。また、対象者端末では、プレイ状態が開封済状態に更新される（ＧＰ１４）。

その後、対象者端末において、招待情報ダイアログ５２の参加タブ５２ａがタップされると、対象者端末からサーバ１００に参加情報が送信される（ＧＰ１５）。なお、参加情報には、対象者が設定したパーティに係る情報等が含まれる。サーバ１００は、参加情報を受信すると、ルームへの入室が可能かを判定し、ルームへの入室が可能であれば、ルーム情報を更新する（Ｓ１３）。ここでは、サーバ１００は、更新したルーム情報（ルーム更新情報）が、ホスト端末および対象者端末によって受信されるようにセットされる。

なお、図１６では、１つの対象者端末（ゲスト端末）のみが示されているが、１つのルームに対して、複数の対象者端末（ゲスト端末）で同一の処理が行われている。したがって、いずれかの対象者端末がルームに入室した場合には、ルームに入室している全てのプレイヤのプレイヤ端末１が、ルーム更新情報を受信することとなる。

ホスト端末は、サーバ１００からルーム更新情報を受信すると、ルーム詳細ページを更新表示する（ＨＰ１２）。また、対象者端末も、ルーム更新情報を受信する。なお、ここでは、ルーム更新情報の受信後のプレイヤ端末１（対象者端末）を、ゲスト端末と呼ぶ。ゲスト端末では、ルーム更新情報を受信すると、プレイ状態を参加状態に更新し（ＧＰ１６）、ディスプレイ２６にルーム詳細ページを表示する（ＧＰ１７）。

その後、ホスト端末において、ルーム詳細ページの開始タブ５０がタップされ、マルチプレイの開始操作が入力されると（ＨＰ１３）、開始情報がサーバ１００に送信される。サーバ１００では、開始情報の入力により、ポイント更新処理が行われる。ここでは、ホストプレイヤの優先ポイントが「１」加算される。

そして、ホスト端末、サーバ１００、ゲスト端末では、それぞれ上記のバトルゲーム開始処理（不図示）が行われ、その後、マルチプレイを制御するためのマルチプレイ制御処理が同時並行して行われる（ＨＰ１４、Ｓ１４、ＧＰ１８）。このマルチプレイ制御処理では、各種情報を更新する更新処理が、フレーム単位で繰り返し実行される。この更新処理では、ホスト端末、ゲスト端末およびサーバ１００の間で、更新情報の送受信が行われている。そして、バトルゲームの終了条件が成立すると、ホスト端末、ゲスト端末およびサーバ１００のそれぞれにおいて、バトルゲームを終了させる終了処理が行われる（ＨＰ１５、Ｓ１５、ＧＰ１９）。

サーバ１００は、マルチプレイの終了時に、マルチプレイに参加したプレイヤごとに、全ダメージ中の与ダメージを算出する（Ｓ１６）。そして、算出した与ダメージに基づいて、ポイント更新処理を行う。ここでは、与ダメージが全ダメージの２０％以上のプレイヤについて、優先ポイントが「３」加算される。一方、ゲスト端末においては、マルチプレイの終了時に、プレイ状態が受け取り不可状態に更新される（ＧＰ２０）。その後、ゲスト端末では、所定時間が経過すると、プレイ状態が受け取り可能状態に更新される（ＧＰ２１）。

図１７は、マルチプレイに参加できない場合のプレイヤ端末１およびサーバ１００の処理を説明するシーケンス図である。なお、図１７において、対象者端末から参加情報が入力されるまでの処理については、図１６と同じであるため、説明を省略する。上記したように、サーバ１００は、参加情報を受信すると、ルームへの入室が可能かを判定する。このとき、ルームへの入室が不可能であれば、サーバ１００は、ルームへの入室が不可能であることを示す参加不可能情報をセットする。また、このとき、サーバ１００は、ポイント更新処理を行い、対象者の優先ポイントを「４」加算する。

対象者端末は、参加不可能情報を受信すると、所定の入室不可画面をディスプレイ２６に表示する（ＧＰ２２）。また、対象者のプレイヤ端末１は、プレイ状態を受け取り可能状態に更新する（ＧＰ２３）。

図１８は、マルチプレイの参加を拒否した場合のプレイヤ端末１およびサーバ１００の処理を説明するシーケンス図である。なお、図１８において、対象者端末から拒否情報が入力されるまでの処理については、図１６と同じであるため、説明を省略する。対象者端末において、招待情報ダイアログ５２の拒否タブ５２ｂがタップされると、対象者端末からサーバ１００に拒否情報が送信される（ＧＰ２４）。また、対象者端末では、プレイ状態が受け取り不可状態に更新される（ＧＰ２５）。

なお、本実施形態では、拒否情報を受信しても、サーバ１００は特段の処理を行わないものとする。ただし、拒否情報を受信した場合に、サーバ１００は、対象者の優先ポイントを減算してもよいし、受信状況（状況フラグ）等、抽出リストを更新してもよい。

次に、プレイヤ端末１の機能的構成、ならびに、プレイヤ端末１における具体的な処理について説明する。なお、以下では、招待情報に係る構成および処理について説明し、招待情報と関係のない構成および処理については説明を省略する。

（プレイヤ端末１の機能的構成）
図１９は、プレイヤ端末１におけるメモリ１２の構成およびコンピュータとしての機能を説明する図である。メモリ１２には、プログラム記憶領域１２ａ、および、データ記憶領域１２ｂが設けられている。ＣＰＵ１０は、マルチプレイの開始時に、あるいは、マルチプレイの開始前に予め、端末側ゲーム制御用プログラム（モジュール）をプログラム記憶領域１２ａに記憶する。

端末側ゲーム制御用プログラムには、ゲーム実行プログラム６０、バトルゲーム実行プログラム６２、要求情報送信プログラム６４、プレイ状態更新プログラム６６、招待情報受信プログラム６８、招待情報報知プログラム７０、操作許可プログラム７２、計時プログラム７４が含まれる。なお、図１９に列挙したプログラムは一例であり、端末側ゲーム制御用プログラムには、この他にも多数のプログラムが設けられている。

データ記憶領域１２ｂには、データを記憶する記憶部として、ゲーム情報記憶部８０、プレイ状態記憶部８２、招待情報記憶部８４が設けられている。なお、上記の各記憶部は一例であり、データ記憶領域１２ｂには、この他にも多数の記憶部が設けられている。

ＣＰＵ１０は、プログラム記憶領域１２ａに記憶された各プログラムを動作させ、データ記憶領域１２ｂの各記憶部のデータを更新する。そして、ＣＰＵ１０は、プログラム記憶領域１２ａに記憶された各プログラムを動作させることで、プレイヤ端末１（コンピュータ）を、端末側ゲーム制御部１Ａとして機能させる。端末側ゲーム制御部１Ａは、ゲーム実行部６０ａ、バトルゲーム実行部６２ａ、要求情報送信部６４ａ、プレイ状態更新部６６ａ、招待情報受信部６８ａ、招待情報報知部７０ａ、操作許可部７２ａ、計時部７４ａを含む。

具体的には、ＣＰＵ１０は、ゲーム実行プログラム６０を動作させ、コンピュータをゲーム実行部６０ａとして機能させる。同様に、ＣＰＵ１０は、バトルゲーム実行プログラム６２、要求情報送信プログラム６４、プレイ状態更新プログラム６６、招待情報受信プログラム６８、招待情報報知プログラム７０、操作許可プログラム７２を動作させ、それぞれバトルゲーム実行部６２ａ、要求情報送信部６４ａ、プレイ状態更新部６６ａ、招待情報受信部６８ａ、招待情報報知部７０ａ、操作許可部７２ａ、計時部７４ａとして機能させる。

ゲーム実行部６０ａは、プレイヤの操作に基づき、例えば、パーティの編成、味方キャラクタの強化等、バトルゲーム以外のゲームの進行を制御する。ゲーム実行部６０ａは、プレイヤ端末１に操作が入力されるたびに、操作に対応する情報をサーバ１００に送信する。また、ゲーム実行部６０ａは、ゲームに係る情報（ゲーム情報）が更新された場合には、ゲーム情報記憶部８０の情報を更新する。

バトルゲーム実行部６２ａは、バトルゲームを実行するための全ての制御を担う。例えば、バトルゲーム実行部６２ａは、プレイヤ端末１に入力される操作に基づいてサーバ１００に情報を送信し、また、サーバ１００から種々の情報を受信する。また、バトルゲーム実行部６２ａは、プレイヤ端末１に入力される操作、および、サーバ１００から受信する情報に基づき、バトル画面を更新する。すなわち、バトルゲーム実行部６２ａは、所定の開始条件が成立すると、シングルプレイ、もしくは、他のプレイヤ端末１とのマルチプレイを実行する。また、バトルゲーム実行部６２ａは、バトルゲームが正常に終了した場合、ゲーム情報記憶部８０の情報を更新する。

要求情報送信部６４ａは、フォロワタブ４８ａ、相互フォロワタブ４８ｂ、ランダムタブ４８ｃのいずれかの操作部がタップされると、操作部に対応する要求信号をサーバ１００に送信する。

プレイ状態更新部６６ａは、招待情報の受信状況、および、ゲームのプレイ状況に基づいて、プレイ状態記憶部８２のプレイ状態を更新する。

招待情報受信部６８ａは、プレイ状態が許可状態である場合に、ディスプレイ２６に表示されている画面ごとに設定されたタイミングで、招待情報の受信確認を行う。具体的には、招待情報受信部６８ａは、サーバ１００に受信確認情報を送信し、また、サーバ１００にセットされている招待情報を受信して、招待情報記憶部８４に記憶する。

招待情報報知部７０ａは、招待情報記憶部８４における招待情報の記憶有無、すなわち、招待情報を受信しているか否かに基づいて、通知画像３４を報知態様または非報知態様に切り替える。

操作許可部７２ａは、通知画像３４がタップされた場合に招待情報ダイアログ５２を表示し、プレイヤの参加操作、拒否操作、保留操作の入力を可能とする。具体的には、報知態様で表示されている通知画像３４がタップされた場合に、受信した招待情報に対応するルームが存在しているかをサーバ１００に確認する。ルームが存在している場合、操作許可部７２ａは、ディスプレイ２６に招待情報ダイアログ５２（図６Ｃ、図７Ａ、図７Ｃ）を表示する。つまり、参加タブ５２ａ、拒否タブ５２ｂ、保留タブ５２ｃをタップ可能に表示することで、マルチプレイへの参加を希望する参加操作、マルチプレイへの参加を拒否するための拒否操作、マルチプレイへの参加を保留状態とする保留操作の入力を可能とする。

計時部７４ａは、後述する禁止時間、受信待機時間、拒否時間をそれぞれ計時する。

（プレイヤ端末１の具体的な処理）
図２０は、プレイヤ端末１における端末側ゲーム処理の一例を説明するフローチャートである。端末側ゲーム処理では、ゲーム実行部６０ａが、ゲーム進行処理を行い、バトルゲーム以外のゲームの進行を制御する（Ｐ１００）。また、バトルゲーム実行部６２ａが、シングルプレイまたはマルチプレイによるバトルゲームを実行するための制御を行う（Ｐ１０１）。また、端末側ゲーム制御部１Ａは、端末側ゲーム処理において、ルーム作成関連処理（Ｐ１１０）、招待情報受信処理（Ｐ１２０）、招待情報受信後処理（Ｐ１３０）、マルチプレイ終了処理（Ｐ１４０）を実行する。

図２１は、プレイヤ端末１におけるルーム作成関連処理の一例を説明するフローチャートである。ディスプレイ２６にクエスト画面が表示されている場合（Ｐ１１０−１のＹＥＳ）に、ルーム作成タブ４６がタップされて要求操作が入力されると（Ｐ１１０−２のＹＥＳ）、要求情報送信部６４ａが要求情報をサーバ１００に送信する（Ｐ１１０−３）。このとき、端末側ゲーム制御部１Ａは、ディスプレイ２６に所定の待機画面を表示する（Ｐ１１０−４）。

また、端末側ゲーム制御部１Ａは、ルーム設定情報を受信すると（Ｐ１１０−５のＹＥＳ）、ディスプレイ２６にルーム詳細ページを表示する（Ｐ１１０−６）。また、端末側ゲーム制御部１Ａは、ルーム更新情報を受信すると（Ｐ１１０−７のＹＥＳ）、受信したルーム更新情報に基づいて、ルーム詳細ページの表示を更新する（Ｐ１１０−８）。

また、開始タブ５０がタップされて開始操作が入力されると（Ｐ１１０−９のＹＥＳ）、端末側ゲーム制御部１Ａは、開始情報をサーバ１００に送信し（Ｐ１１０−１０）、マルチプレイが開始されるまで待機する（Ｐ１１０−１１）。なお、マルチプレイが開始可能となると、上記のバトルゲーム実行処理（Ｐ１０１）において、マルチプレイによるバトルゲームの制御がなされる。

図２２は、プレイヤ端末１における招待情報受信処理の一例を説明するフローチャートである。ディスプレイ２６の画面が遷移すると（Ｐ１２０−１のＹＥＳ）、計時部７４ａは、ディスプレイ２６に表示中の画面を確認し（Ｐ１２０−７）、初期カウンタ値を抽選で決定する（Ｐ１２０−８）。なお、初期カウンタ値は、招待情報の受信確認の間隔を示すものである。ここでは、通常画面が表示されていれば、１〜１０秒のいずれかに相当する値が初期カウンタ値として決定され、バトル画面が表示されていれば、１〜１５秒のいずれかに相当する値が初期カウンタ値として決定される。計時部７４ａは、決定した初期カウンタ値を、データ記憶領域１２ｂの所定の記憶部（初期値記憶部）に記憶し、また、受信待機カウンタにセットする（Ｐ１２０−９）。

また、ディスプレイ２６の画面が遷移しておらず（Ｐ１２０−１のＮＯ）、招待情報記憶部８４に記憶されているプレイ状態が、受け取り不可状態である場合（Ｐ１２０−２のＮＯ、Ｐ１２０−３のＹＥＳ）、計時部７４ａは、禁止時間カウンタのカウンタ値をデクリメントする（Ｐ１２０−４）。なお、詳しくは後述するが、拒否操作がなされると、禁止時間カウンタに所定のカウンタ値がセットされる。つまり、禁止時間カウンタは、拒否操作が入力されてからの経過時間を計時するものである。禁止時間カウンタのカウンタ値が０に更新された場合（Ｐ１２０−５のＹＥＳ）、プレイ状態更新部６６ａが、プレイ状態記憶部８２のプレイ状態を受け取り可能状態に更新する（Ｐ１２０−６）。

これにより、拒否操作がなされてから所定時間が経過するまでの間、プレイ状態が受け取り不可状態に維持される。そして、拒否操作がなされてから所定時間が経過すると、プレイ状態が受け取り可能状態に切り替わる。なお、プレイ状態が受け取り可能状態に切り替わった場合には、上記と同様に、ディスプレイ２６に表示中の画面に基づいて、初期カウンタ値が決定され、受信待機カウンタにセットされる（Ｐ１２０−７からＰ１２０−９）。

また、ディスプレイ２６の画面が遷移しておらず（Ｐ１２０−１のＮＯ）、招待情報記憶部８４に記憶されているプレイ状態が、受け取り可能状態または未開封状態である場合（Ｐ１２０−２のＹＥＳ）、計時部７４ａは、受信待機カウンタのカウンタ値をデクリメントする（Ｐ１２０−１０）。そして、計時部７４ａは、受信待機カウンタのカウンタ値が０になると（Ｐ１２０−１１のＹＥＳ）、初期値記憶部に記憶されている初期カウンタ値を、受信待機カウンタに再度セットする。また、招待情報受信部６８ａは、招待情報確認処理（Ｐ１２１）を実行する。

図２３は、プレイヤ端末１における招待情報確認処理の一例を説明するフローチャートである。招待情報受信部６８ａは、受信確認情報をサーバ１００に送信する（Ｐ１２１−１）。招待情報受信部６８ａは、受信可能（未受信）な招待情報がサーバ１００にセットされている場合（Ｐ１２１−２のＹＥＳ）、サーバ１００にセットされている招待情報を受信し、招待情報記憶部８４に記憶する（Ｐ１２１−３）。また、招待情報受信部６８ａは、プレイ状態記憶部８２のプレイ状態を未開封状態に更新する（Ｐ１２１−４）。また、招待情報報知部７０ａは、ヘッダ表示領域３０において、通知画像３４を報知態様で表示する（Ｐ１２１−５）。

図２４は、プレイヤ端末１における招待情報受信後処理の一例を説明する第１のフローチャートである。図２５は、プレイヤ端末１における招待情報受信後処理の一例を説明する第２のフローチャートである。招待情報記憶部８４に招待情報が記憶されている状態（Ｐ１３０−１のＹＥＳ）で通知画像３４がタップされると（Ｐ１３０−２のＹＥＳ）、招待情報受信部６８ａは、ディスプレイ２６に招待情報ダイアログ５２を表示する（Ｐ１３０−３）。このとき、プレイ状態が未開封状態であれば（Ｐ１３０−４のＹＥＳ）、招待情報受信部６８ａが開封情報をサーバ１００に送信する（Ｐ１３０−５）。また、プレイ状態更新部６６ａは、プレイ状態を開封済状態に更新する（Ｐ１３０−６）。

また、招待情報記憶部８４に招待情報が記憶されており、招待情報ダイアログ５２が表示されている状態で、参加タブ５２ａがタップされて参加操作が入力されると（Ｐ１３０−１のＹＥＳ、Ｐ１３０−２のＮＯ、Ｐ１３０−７のＹＥＳ、Ｐ１３０−８のＹＥＳ）、招待情報受信部６８ａは、サーバ１００に参加情報を送信する（Ｐ１３０−９）。その後、招待情報受信部６８ａは、ルーム更新情報または参加不可能情報を受信するまで待機する（Ｐ１３０−１０）。そして、サーバ１００からルーム更新情報を受信した場合（Ｐ１３０−１１のＹＥＳ）、プレイ状態更新部６６ａが、プレイ状態を参加状態に更新し（Ｐ１３０−１２）、招待情報受信部６８ａが、ディスプレイ２６にルーム詳細ページを表示する（Ｐ１３０−１３）。また、ここでは、招待情報受信部６８ａが、通知画像３４を非表示態様に切り替える。

これに対して、サーバ１００から参加不可能情報を受信した場合（Ｐ１３０−１１のＮＯ）、招待情報受信部６８ａは、ディスプレイ２６に入室不可画面を表示し（Ｐ１３０−１４）、招待情報記憶部８４から招待情報を消去する（Ｐ１３０−１５）。また、招待情報報知部７０ａは、通知画像３４を、報知態様から非報知態様に切り替える（Ｐ１３０−１６）。さらに、プレイ状態更新部６６ａは、プレイ状態記憶部８２のプレイ状態を、受け取り可能状態に更新する（Ｐ１３０−１７）。

また、招待情報記憶部８４に招待情報が記憶されており、招待情報ダイアログ５２が表示されている状態で、拒否タブ５２ｂがタップされて拒否操作が入力されると（Ｐ１３０−１のＹＥＳ、Ｐ１３０−２のＮＯ、Ｐ１３０−７のＹＥＳ、Ｐ１３０−８のＮＯ、図２５のＰ１３０−１８のＹＥＳ）、招待情報受信部６８ａは、招待情報ダイアログ５２の表示を終了する（Ｐ１３０−１９）。また、招待情報報知部７０ａは、報知態様の通知画像３４の表示を終了させ、非報知態様の通知画像３４、または、操作タブ４２を表示する（Ｐ１３０−２０）。

さらに、招待情報受信部６８ａは、招待情報記憶部８４から招待情報を消去し（Ｐ１３０−２１）、プレイ状態更新部６６ａが、プレイ状態を受け取り不可状態に更新する（Ｐ１３０−２２）。また、招待情報受信部６８ａは、サーバ１００に拒否情報を送信する（Ｐ１３０−２３）。また、計時部７４ａは、拒否時間カウンタのカウンタ値が０であるかを判定する（Ｐ１３０−２４）。なお、拒否時間カウンタは、拒否操作が入力されてからの経過時間を計時するものである。詳しい説明は省略するが、拒否時間カウンタにセットされたカウンタ値は、端末側ゲーム処理が実行されるたびにデクリメントされる。ここでは、拒否操作が入力されてから３０分が経過すると、拒否時間カウンタのカウンタ値が０になる。

拒否時間カウンタのカウンタ値が０である場合（Ｐ１３０−２４のＹＥＳ）、すなわち、最後に拒否操作が入力されてから３０分が経過している場合、計時部７４ａは、禁止時間カウンタに、５分に相当するカウンタ値をセットする（Ｐ１３０−２５）。また、拒否時間カウンタのカウンタ値が０ではない場合（Ｐ１３０−２４のＮＯ）、すなわち、最後に拒否操作が入力されてから３０分が経過していない場合、計時部７４ａは、禁止時間カウンタに、６０分に相当するカウンタ値をセットする（Ｐ１３０−２６）。また、計時部７４ａは、禁止時間カウンタに５分または６０分のカウンタ値をセットした後、拒否時間カウンタに、３０分に相当するカウンタ値をセットする（Ｐ１３０−２７）。

上記の処理によれば、操作許可部７２ａが、招待情報の受信の報知時もしくは報知後に、招待情報ダイアログ５２を表示することで（Ｐ１３０−３）、マルチプレイへの参加を拒否するための拒否操作の入力を可能とする。そして、拒否操作の入力後、５分（第２の時間）または６０分（第２の時間）に亘り、プレイ状態が受け取り不可状態に維持され、５分または６０分が経過すると、プレイ状態が受け取り可能状態に更新される（Ｐ１２０−６）。また、３０分以内に拒否操作が２回なされた場合、２回目の拒否操作後は、６０分間、招待情報が受信されなくなる。

また、招待情報記憶部８４に招待情報が記憶されており、招待情報ダイアログ５２が表示されている状態で、保留タブ５２ｃがタップされて保留操作が入力されると（Ｐ１３０−１のＹＥＳ、Ｐ１３０−２のＮＯ、Ｐ１３０−７のＹＥＳ、Ｐ１３０−８のＮＯ、Ｐ１３０−１８のＮＯ、Ｐ１３０−２８のＹＥＳ）、招待情報受信部６８ａは、招待情報ダイアログ５２の表示を終了する（Ｐ１３０−２９）。

図２６は、プレイヤ端末１におけるマルチプレイ終了処理の一例を説明するフローチャートである。マルチプレイが終了すると（Ｐ１４０−１のＹＥＳ）、招待情報受信部６８ａは、ディスプレイ２６にリザルト画面を表示する（Ｐ１４０−２）。このとき、ゲストプレイヤとしてマルチプレイに参加した場合（Ｐ１４０−３のＹＥＳ）、招待情報受信部６８ａは、招待情報記憶部８４から招待情報を消去する（Ｐ１４０−４）。また、プレイ状態更新部６６ａは、プレイ状態を受け取り不可状態に更新し（Ｐ１４０−５）、招待情報受信部６８ａが、禁止時間カウンタに５分に相当するカウンタ値をセットする（Ｐ１４０−６）。このマルチプレイ終了処理によれば、ゲストプレイヤとして参加したマルチプレイの終了後、５分（第１の時間）に亘り、プレイ状態が受け取り不可状態に維持される。

次に、サーバ１００の機能的構成、ならびに、サーバ１００における具体的な処理について説明する。なお、以下では、招待情報を受信可能な対象者の設定に関する構成および処理について説明し、その他の構成および処理については説明を省略する。

（サーバ１００の機能的構成）
図２７は、サーバ１００におけるメモリ１１２の構成およびコンピュータとしての機能を説明する図である。メモリ１１２には、プログラム記憶領域１１２ａ、および、データ記憶領域１１２ｂが設けられている。ＣＰＵ１１０は、マルチプレイの開始時に、あるいは、マルチプレイの開始前に予め、サーバ側ゲーム制御用プログラム（モジュール）をプログラム記憶領域１１２ａに記憶する。

サーバ側ゲーム制御用プログラムには、プレイヤ情報更新プログラム１４０、リスト更新プログラム１４２、端末設定プログラム１４４、ゲーム実行プログラム１４６が含まれる。なお、図２７に列挙したプログラムは一例であり、サーバ側ゲーム制御用プログラムには、この他にも多数のプログラムが設けられている。

データ記憶領域１１２ｂには、データを記憶する記憶部として、プレイヤ情報記憶部１６０、抽出リスト記憶部１６２、ゲーム情報記憶部１６４、ルーム情報記憶部１６６が設けられている。なお、上記の各記憶部は一例であり、データ記憶領域１１２ｂには、この他にも多数の記憶部が設けられている。

ＣＰＵ１１０は、プログラム記憶領域１１２ａに記憶された各プログラムを動作させ、データ記憶領域１１２ｂの各記憶部のデータを更新する。そして、ＣＰＵ１１０は、プログラム記憶領域１１２ａに記憶された各プログラムを動作させることで、サーバ１００（コンピュータ）を、サーバ側ゲーム制御部１００Ａとして機能させる。サーバ側ゲーム制御部１００Ａは、プレイヤ情報更新部１４０ａ、リスト更新部１４２ａ、端末設定部１４４ａ、ゲーム実行部１４６ａを含む。

具体的には、ＣＰＵ１１０は、プレイヤ情報更新プログラム１４０を動作させ、コンピュータをプレイヤ情報更新部１４０ａとして機能させる。同様に、ＣＰＵ１１０は、リスト更新プログラム１４２、端末設定プログラム１４４、ゲーム実行プログラム１４６を動作させ、それぞれリスト更新部１４２ａ、端末設定部１４４ａ、ゲーム実行部１４６ａとして機能させる。

プレイヤ情報更新部１４０ａは、プレイヤ端末１と通信がなされるたびに、プレイヤ情報記憶部１６０に蓄積されているプレイヤごとのプレイヤ情報を更新する。また、プレイヤ情報更新部１４０ａは、プレイヤ情報記憶部１６０において優先ポイントを更新するポイント更新処理を行う。

リスト更新部１４２ａは、抽出リスト記憶部１６２に記憶されている抽出リストを、プレイヤ情報記憶部１６０に記憶されているプレイヤ情報（優先ポイント）に基づいて更新する。例えば、リスト更新部１４２ａは、プレイヤの情報が記憶される記憶領域を入れ替えるソート処理を実行する。また、リスト更新部１４２ａは、抽出リストの招待情報、状況フラグ、ウエイトカウンタを更新する。

端末設定部１４４ａは、要求情報の入力に基づき、招待情報、状況フラグ、ウエイトカウンタのカウンタ値を抽出リストにセットする。すなわち、端末設定部１４４ａは、抽出リストにおいて、対象者を設定する。

ゲーム実行部１４６ａは、プレイヤ端末１から入力される情報に基づき、バトルゲームを含む全てのゲームの進行を制御する。また、ゲーム実行部１４６ａは、ゲーム中に更新される各種の情報をゲーム情報記憶部１６４に記憶する。ここでは、ゲーム実行部１４６ａは、マルチプレイにおいて、敵キャラクタに与えたダメージをプレイヤごとにゲーム情報記憶部１６４に記憶する。ただし、ゲーム情報記憶部１６４に記憶される情報はこれに限らず、ゲームの内容に基づいて適宜設定可能である。

（サーバ１００の具体的な処理）
図２８は、サーバ１００におけるサーバ側ゲーム処理の一例を説明するフローチャートである。サーバ側ゲーム処理では、ゲーム実行部１４６ａが、バトルゲームを実行するためのバトルゲーム実行処理を行う（Ｓ１００）。また、プレイヤ情報更新部１４０ａは、プレイヤ端末１から入力された情報に基づいて、プレイヤ情報記憶部１６０のプレイヤ情報を更新する。また、サーバ側ゲーム制御部１００Ａは、サーバ側ゲーム処理において、要求情報受信処理（Ｓ１１０）、情報更新処理（Ｓ１２０）、マルチプレイ終了処理（Ｐ１３０）、並び替え処理（Ｓ１４０）を実行する。

図２９は、サーバ１００における要求情報受信処理の一例を説明するフローチャートである。ルームに招待する対象者としてフォロワが選択された場合、すなわち、フォロワタブ４８ａ用の要求情報を受信した場合（Ｓ１１０−１のＹＥＳ、Ｓ１１０−２のＹＥＳ）、端末設定部１４４ａが、抽出リストにおいて、フォロワの記憶領域に、招待情報、状況フラグ、ウエイトカウンタのカウンタ値（以下、「招待情報等」と呼ぶ）をセットする（Ｓ１１０−３）。

ルームに招待する対象者として相互フォロワが選択された場合、すなわち、相互フォロワタブ４８ｂ用の要求情報を受信した場合（Ｓ１１０−１のＹＥＳ、Ｓ１１０−２のＮＯ、Ｓ１１０−４のＹＥＳ）、端末設定部１４４ａが、抽出リストにおいて、相互フォロワの記憶領域に、招待情報等をセットする（Ｓ１１０−５）。

なお、フォロワまたは相互フォロワに招待情報をセットする場合、ウエイトカウンタのカウンタ値のセットは必須ではない。つまり、フォロワまたは相互フォロワが対象者に設定される場合には、全ての対象者が、同時に招待情報を受信し得る状況としてもよい。また、ランダムに対象者が設定される場合と同様に、優先ポイントに基づいて、ウエイトカウンタのカウンタ値が設定されてもよい。

ルームに招待する対象者をランダムに抽出することが選択された場合、すなわち、ランダムタブ４８ｃ用の要求情報を受信した場合（Ｓ１１０−１のＹＥＳ、Ｓ１１０−２のＮＯ、Ｓ１１０−４のＮＯ）、端末設定部１４４ａが、抽出リストにおいて、受信状況が「設定可」、すなわち、状況フラグがブランクの上位１００名の記憶領域に、招待情報等をセットする（Ｓ１１０−６）。

また、対象者がランダムに設定された場合、プレイヤ情報更新部１４０ａは、プレイヤ情報記憶部１６０において、ホストプレイヤの優先ポイントを「１」加算する（Ｓ１１０−８）。また、要求情報を受信した場合（Ｓ１１０−１のＹＥＳ）、サーバ側ゲーム制御部１００Ａは、ルームを設定するルーム設定処理を行う（Ｓ１１０−８）。ここでは、ルーム情報記憶部１６６に、ルーム（所定の記憶領域）を設定し、要求情報に基づいて、ホストプレイヤに係る情報をルームに記憶する。また、ここでは、サーバ側ゲーム制御部１００Ａは、ルーム情報を、ホスト端末が受信可能にセットする。さらに、プレイヤ情報更新部１４０ａは、要求情報の種別に拘わらず、プレイヤ情報記憶部１６０において、ホストプレイヤの優先ポイントを「４」減算する（Ｓ１１０−９）。

図３０は、サーバ１００における情報更新処理の一例を説明するフローチャートである。プレイヤ端末１から受信確認情報を受信すると（Ｓ１２０−１のＹＥＳ）、サーバ側ゲーム制御部１００Ａは、抽出リストを検索し、このプレイヤ端末１に対する招待情報がセットされているかを検索する（Ｓ１２０−２）。このとき、招待情報がセットされており（Ｓ１２０−３のＹＥＳ）、受信状況（状況フラグ）が「受信可」に設定されていれば（Ｓ１２０−４のＹＥＳ）、サーバ側ゲーム制御部１００Ａは招待情報出力処理を行う（Ｓ１２０−５）ここでは、招待情報が、受信確認情報を送信したプレイヤ端末１によって受信可能にセットされる。

また、プレイヤ情報更新部１４０ａは、プレイヤ情報記憶部１６０に記憶されている対象者の優先ポイントを「４」減算する（Ｓ１２０−６）。また、リスト更新部１４２ａは、抽出リストにおいて、対象者端末の受信状況（状況フラグ）を「受信済」に更新する。

また、プレイヤ端末１（対象者端末）から開封情報を受信すると（Ｓ１２０−８のＹＥＳ）、プレイヤ情報更新部１４０ａが、プレイヤ情報記憶部１６０に記憶されている対象者の優先ポイントを「１」加算する（Ｓ１２０−９）。

また、プレイヤ端末１（対象者端末）から参加情報を受信した場合（Ｓ１２０−１０のＹＥＳ）、ルームに入室可能であれば（Ｓ１２０−１１のＹＥＳ）、サーバ側ゲーム制御部１００Ａが、ルーム情報記憶部１６６のルーム情報を更新する（Ｓ１２０−１２）。また、サーバ側ゲーム制御部１００Ａは、ルーム更新情報出力処理を行う。ここでは、サーバ側ゲーム制御部１００Ａは、ルーム更新情報を、ホスト端末および全てのゲスト端末（参加情報を送信した対象者端末を含む）が受信可能にセットする（Ｓ１２０−１３）。

一方、ルームに入室できなければ（Ｓ１２０−１１のＮＯ）、プレイヤ情報更新部１４０ａが、プレイヤ情報記憶部１６０において、参加情報を送信した対象者の優先ポイントを「４」加算する（Ｓ１２０−１４）。また、サーバ側ゲーム制御部１００Ａは、この対象者が参加不可能情報を受信可能にセットする（Ｓ１２０−１５）。

また、ホスト端末から開始情報を受信すると（Ｓ１２０−１６のＹＥＳ）、プレイヤ情報更新部１４０ａは、プレイヤ情報記憶部１６０において、ホストプレイヤの優先ポイントを「１」加算する（Ｓ１２０−１７）。そして、サーバ側ゲーム制御部１００Ａは、マルチプレイによるバトルゲームを開始するためのバトルゲーム開始処理を実行する（Ｓ１２０−１８）。

図３１は、サーバ１００におけるマルチプレイ終了処理の一例を説明するフローチャートである。バトルゲーム実行処理（Ｓ１００）において、マルチプレイが途中終了（リタイア）以外で正常終了した場合（Ｓ１３０−１のＹＥＳ、Ｓ１３０−２のＮＯ）、サーバ側ゲーム制御部１００Ａは、与ダメージが全体の２０％以上のプレイヤを特定する（Ｓ１３０−３）。なお、バトルゲーム実行処理（Ｓ１００）では、マルチプレイの実行時に、ゲーム情報記憶部１６４にプレイヤごとの与ダメージを記憶している。

プレイヤ情報更新部１４０ａは、プレイヤ情報記憶部１６０において、特定したプレイヤの優先ポイントを「３」加算する（Ｓ１３０−４）。また、プレイヤ情報更新部１４０ａは、マルチプレイの終了時に、優先ポイントが初期値を上回っている全てのプレイヤの優先ポイントを初期値にリセット（１００にセット）する（Ｓ１３０−５）。

図３２は、サーバ１００における並び替え処理の一例を説明するフローチャートである。リスト更新部１４２ａは、抽出リスト記憶部１６２に記憶されている抽出リストの優先ポイントを、プレイヤ情報記憶部１６０に記憶されている優先ポイントに更新する（Ｓ１４０−１）。また、リスト更新部１４２ａは、抽出リストの優先ポイントに基づいて、優先順位を入れ替えるソート処理を行う（Ｓ１４０−２）。これにより、プレイヤの優先順位が、優先ポイントに基づいて更新されることとなる。

また、リスト更新部１４２ａは、抽出リストの情報を更新するリスト情報更新処理を行う（Ｓ１４０−３）。例えば、リスト更新部１４２ａは、ウエイトカウンタのカウンタ値を更新し、カウンタ値が０に更新された記憶領域について、状況フラグを「受信不可」から「受信可」に更新する。また、リスト更新部１４２ａは、招待情報を受信した対象者については、状況フラグを「受信可」から「受信済」に更新する。さらに、リスト更新部１４２ａは、マルチプレイが終了した場合、ルームが解散した場合、招待情報がセットされてから所定時間が経過した場合に、抽出リストから、招待情報、状況フラグ、ウエイトカウンタを更新する。

以上説明したように、プレイヤ端末１には、ホスト端末としてマルチプレイを実行するプログラムと、ゲスト端末としてマルチプレイを実行するプログラムとが設けられる。そして、プレイヤ端末１は、ルーム作成タブ４６（操作部）からの要求操作の入力により、サーバ１００に要求情報を送信する要求情報送信部６４ａとして機能する。なお、本実施形態では、外部装置としてサーバ１００が設けられ、複数のプレイヤ端末１は、外部装置であるサーバ１００を介して、マルチプレイを実行可能である。しかしながら、外部装置はサーバ１００に限らない。例えば、プレイヤ端末１が、サーバ１００の上記の機能を備えており、いずれかのプレイヤ端末１が、外部装置として機能してもよい。

また、プレイヤ端末１は、ゲームのプレイ状況に基づいてプレイ状態を更新するプレイ状態更新部６６ａ（状態更新部）として機能する。なお、本実施形態では、５つのプレイ状態が設けられているが、プレイ状態の数、プレイ状態の設定条件は一例に過ぎず、適宜設計可能である。例えば、プレイ状況（プレイ状態）には、ログイン状態が含まれ、ログインしているか否かでプレイ状態を異ならせてもよい。いずれにしても、プレイ状態は、招待情報を受信可能な許可状態と、招待情報を受信しない不許可状態とが設けられればよい。

また、本実施形態では、ゲームのプレイ状況と、招待情報の受信有無とに基づいてプレイ状態が設定、更新される。しかしながら、プレイ状態更新部６６ａは、少なくともゲームのプレイ状況に基づいて更新されればよい。

また、プレイヤ端末１は、プレイ状態が許可状態である場合に、サーバ１００（外部装置）から招待情報を受信し得る招待情報受信部６８ａ（受信部）として機能する。なお、本実施形態では、サーバ１００において招待情報がセットされ、プレイヤ端末１からの受信確認によって、プレイヤ端末１が招待情報を受信する。しかしながら、招待情報受信部６８ａが招待情報を受信する処理はこれに限らない。

例えば、サーバ１００において対象者に設定された場合、サーバ１００から対象者端末に対して招待情報を送信する。このとき、対象者端末のプレイ状態が許可状態であれば招待情報を受信し、プレイ状態が不可能状態であれば、招待情報の受信を拒否してもよい。いずれにしても、招待情報受信部６８ａは、プレイ状態が許可状態である場合に、サーバ１００（外部装置）から招待情報を受信すればよく、その処理または方法は限定されない。

また、プレイヤ端末１は、招待情報の受信を報知する招待情報報知部７０ａ（報知部）として機能する。本実施形態では、招待情報報知部７０ａが、通知画像３４の表示態様を切り替えることで、招待情報の受信を報知する。しかしながら、招待情報の受信を報知する方法はこれに限らない。例えば、招待情報の受信時もしくは受信後に、招待情報ダイアログ５２を強制的に表示することで、招待情報の受信を報知してもよい。いずれにしても、招待情報報知部７０ａは、招待情報の受信時もしくは受信後に、招待情報の受信を報知すればよく、報知の態様は適宜設計可能である。

また、プレイヤ端末１は、参加操作の入力を可能とする操作許可部７２ａとして機能する。本実施形態では、操作許可部７２ａは、招待情報ダイアログ５２に参加タブ５２ａ、拒否タブ５２ｂ、保留タブ５２ｃを設けることで、参加操作、拒否操作、保留操作の入力を可能とする。ただし、操作許可部７２ａは、参加操作、拒否操作、保留操作の入力を可能とすればよく、その方法または処理は適宜設計可能である。また、操作許可部７２ａは、少なくとも参加操作の入力を可能とすればよく、拒否操作および保留操作の受け付けは必須ではない。いずれにしても、操作許可部７２ａは、招待情報の受信の報知時もしくは報知後に、所定の参加操作の入力を可能とすればよい。

また、プレイヤ端末１は、他のプレイヤ端末１とのマルチプレイ（通信ゲーム）を実行するゲーム実行部６０ａとして機能する。なお、本実施形態におけるゲームの内容は一例に過ぎず、ゲームの内容は特に限定されるものではない。ゲームの内容は、例えば、アクションゲーム、ロールプレイングゲーム、レースゲーム等であってもよい。いずれにしても、複数のプレイヤ端末１で通信ゲームが実行可能であればよく、通信ゲームの内容は特に限定されない。したがって、通信ゲームの内容は、複数のプレイヤが協力するものでもよいし、複数のプレイヤが互いに対戦するものでもよい。いずれにしても、ゲーム実行部６０ａは、参加操作が入力され、所定の開始条件が成立すると、他のプレイヤ端末１との通信ゲームを実行するものを広く含む。

また、本実施形態では、招待情報を受信可能な状態と、招待情報の受信を報知可能な状態とが一致している。したがって、プレイヤ端末１は、招待情報を受信した場合、必ず、招待情報を受信した旨を即座に報知する。しかしながら、招待情報を受信可能な状態と、招待情報の受信を報知可能な状態とが異なってもよい。例えば、上記の５つのプレイ状態に基づいて、招待情報の受信確認がなされるものとする。また、プレイヤ端末１は、プレイ状態とは別に、報知可否状態を設定する報知可否状態設定部として機能する。報知可否状態としては、例えば、報知可能状態と報知不可能状態とが設けられる。

報知可否状態設定部は、例えば、ディスプレイ２６に表示中の画面遷移に基づいて、報知可否状態を切り替える。具体的には、報知可否状態設定部は、報知態様の通知画像３４、または、招待情報ダイアログ５２を表示してもよい画面に遷移すると、報知可否状態を報知可能状態に設定する。一方、報知可否状態設定部は、報知態様の通知画像３４、または、招待情報ダイアログ５２を表示してはいけない画面に遷移すると、報知可否状態を報知不可能状態に設定する。

そして、招待情報報知部７０ａは、招待情報を受信すると、報知可否状態を確認し、報知可能状態であれば、報知態様の通知画像３４、または、招待情報ダイアログ５２をディスプレイ２６に表示する。一方、招待情報を受信したときに、報知可否状態が報知不可能状態であれば、非報知態様の通知画像３４を表示したままとする。この場合、招待情報を受信していても、プレイヤには、招待情報の存在が知らされない。そして、招待情報報知部７０ａは、画面が遷移した場合等、所定のタイミングで、報知可否状態を確認し、報知可能状態であれば、その時点で、報知態様の通知画像３４、または、招待情報ダイアログ５２を表示する。

以上のように、招待情報の受信の可否が規定されたプレイ状態と、招待情報の受信報知の可否が規定された報知可否状態とが設けられてもよい。また、招待情報を受信可能な状態と、招待情報の受信を報知可能な状態とが異なってもよい。

さらには、プレイ状態は、招待情報の受信報知を規定するものであってもよい。すなわち、招待情報報知部７０ａは、招待情報の受信時もしくは受信後であって、プレイ状態が許可状態である場合に、招待情報の受信を報知してもよい。この変形例について、図を参照して説明する。

（変形例）
図３３は、プレイヤ端末１における変形例の招待情報受信処理の一例を説明するフローチャートである。この変形例の招待情報受信処理は、上記実施形態の招待情報受信処理に代えて実行される。なお、詳しい説明は省略するが、変形例の招待情報受信処理を実行する場合、上記実施形態の招待情報受信後処理およびマルチプレイ終了処理において、一部の処理が追加または変更される。

招待情報報知部７０ａは、ディスプレイ２６に表示中の画面が、招待情報の受信を報知可能な画面であるかを判定する（Ｐ１５０−１）。なお、招待情報の受信を報知可能であるか否かは、画面ごとに予め設定されている。招待情報の受信を報知不可能な画面に遷移した場合（Ｐ１５０−１のＮＯ）、プレイ状態更新部６６ａが、プレイ状態記憶部８２のプレイ状態を不可能状態にセットする（Ｐ１５０−２）。

一方、ディスプレイ２６に表示中の画面が、招待情報の受信を報知可能な画面である場合（Ｐ１５０−１のＹＥＳ）、プレイ状態更新部６６ａがプレイ状態を許可状態にセットする（Ｐ１５０−３）。このとき、未報知の（受信が報知されていない）招待情報が招待情報記憶部８４に記憶されていれば（Ｐ１５０−４のＹＥＳ）、招待情報報知部７０ａが、通知画像３４を報知態様で表示する（Ｐ１５０−５）。

また、招待情報受信部６８ａは、受信確認情報をサーバ１００に送信し（Ｐ１５０−６）、サーバ１００から情報を受信するまで待機する（Ｐ１５０−７）。招待情報を受信すると（Ｐ１５０−８のＹＥＳ）、受信した招待情報を招待情報記憶部８４に記憶する（Ｐ１５０−９）。このとき、プレイ状態が許可状態であれば（Ｐ１５０−１０のＹＥＳ）、招待情報報知部７０ａが、通知画像３４を報知態様で表示する（Ｐ１５０−１１）。

上記の変形例によれば、ゲームのプレイ状況（プレイ状態）とは無関係に、プレイヤ端末１が招待情報を受信する。そして、招待情報の受信時もしくは受信後であって、プレイ状態が許可状態である場合に、招待情報報知部７０ａが招待情報の受信を報知する。この変形例によっても、上記実施形態と同様の作用効果が実現される。

なお、上記実施形態では、プレイ状態更新部６６ａが、マルチプレイ（通信ゲーム）の終了後、５分（第１の時間）に亘り、プレイ状態を、招待情報の受信を不可能とする不可能状態とする。変形例においても、プレイ状態更新部６６ａが、マルチプレイ（通信ゲーム）の終了後、所定時間（第１の時間）に亘り、プレイ状態を、招待情報の受信の報知を不可能とする不可能状態としてもよい。

また、上記実施形態では、プレイ状態更新部６６ａが、拒否操作の入力後、５分（第２の時間）もしくは６０分（第２の時間）に亘り、プレイ状態を、招待情報の受信を不可能とする不可能状態とする。変形例においても、プレイ状態更新部６６ａが、拒否操作の入力後、所定時間（第２の時間）に亘り、プレイ状態を、招待情報の受信の報知を不可能とする不可能状態としてもよい。

また、サーバ１００は、所定のプレイヤ情報をプレイヤごとにプレイヤ情報記憶部１６０（記憶部）に蓄積し、また、予め設定された更新条件にしたがって、プレイヤごとの優先ポイント（優先度情報）を更新するプレイヤ情報更新部１４０ａ（蓄積部、更新部）として機能する。なお、優先ポイントの更新条件は適宜設計可能である。また、優先ポイントは、優先度情報の一例に過ぎない。例えば、ゲームのプレイ時間、プレイヤレベル、プレイヤランク、課金金額、さらには、これらの組み合わせが優先度情報として設定されてもよい。

なお、上記実施形態では、プレイヤ情報更新部１４０ａは、マルチプレイにおける与ダメージの割合に基づいて、優先ポイントを更新する。つまり、プレイヤ情報更新部１４０ａは、マルチプレイ（通信ゲーム）中の所定の結果に基づいて、優先ポイント（優先度情報）を更新する。この場合、例えば、与ダメージの割合ではなく、マルチプレイの終了時におけるプレイヤキャラの生存有無に基づいて優先ポイントが更新されてもよい。また、例えば、与ダメージに所定の係数を乗算したポイントが、優先ポイントに加減算されてもよい。いずれにしても、マルチプレイ（通信ゲーム）中の所定の結果に基づいて優先度情報が更新される場合、所定の結果は適宜設計可能である。ただし、優先ポイントの更新条件には、マルチプレイ中の結果は必須ではない。

また、上記実施形態では、プレイヤ情報更新部１４０ａは、招待情報の受信後に対象者端末（抽出端末）から受信した情報に基づいて、優先ポイント（優先度情報）を更新する。具体的には、参加情報が入力された場合（ただし、ルームに入室できない場合）、および、開封情報が入力された場合に、優先ポイントが更新される。ただし、プレイヤ情報更新部１４０ａは、例えば、招待情報の受信後は、優先ポイントを更新せずともよい。

また、サーバ１００は、プレイヤ端末１から要求情報を受信すると、少なくとも、優先ポイント（優先度情報）に基づき、複数のプレイヤ端末１を、招待情報を受信可能な対象者端末（抽出端末）に設定し得る端末設定部１４４ａ（設定部）として機能する。なお、上記実施形態では、端末設定部１４４ａは、フォロワまたは相互フォロワを対象者に設定することがある。つまり、端末設定部１４４ａは、優先ポイントに基づいて対象者を設定する場合と、優先ポイントとは無関係に対象者を設定する場合とがある。端末設定部１４４ａは、プレイヤごとに優先度情報が設定される場合において、少なくとも、優先度情報に基づいて、対象者端末を設定すればよい。

また、サーバ１００は、招待情報を受信し、かつ、所定の参加情報が送信されたいずれか１または複数の対象者端末（抽出端末）と、要求情報を送信したプレイヤ端末１（ホスト端末）とのマルチプレイ（通信ゲーム）を実行するゲーム実行部１４６ａとして機能する。なお、ゲーム実行部１４６ａが提供するゲームの内容は特に限定されない。

また、プレイヤ端末１およびサーバ１００における上記の役割分担は一例に過ぎない。上記実施形態および変形例では、プレイヤ端末１において、プレイ状態が記憶、更新されることとした。すなわち、上記実施形態および変形例では、プレイヤ端末１が、プレイ状態更新部６６ａ（状態更新部）として機能する。しかしながら、プレイ状態は、サーバ１００において記憶、更新されてもよい。

以下に、サーバ１００が、状態更新部（サーバ側状態更新部）として機能する第２の実施形態について説明する。なお、以下では、上記実施形態と同様の構成については、同一の符号を付し、その詳細な説明は省略する。

（第２の実施形態）
図３４は、プレイヤ端末１における第２の実施形態のメモリ１２の構成およびコンピュータとしての機能を説明する図である。第２の実施形態では、端末側ゲーム制御用プログラムに、上記の各プログラムに加えて、さらに、プレイ状態送信プログラム６７が含まれる。そして、ＣＰＵ１０は、プレイ状態送信プログラム６７を動作させ、プレイ状態送信部６７ａとして機能させる。

プレイ状態送信部６７ａは、プレイヤ端末１におけるプレイ状態（プレイ状態情報）をサーバ１００に送信する。なお、第２の実施形態では、プレイヤ端末１において、上記実施形態と同様に、プレイ状態の設定、更新がなされる。このとき、プレイ状態を設定する設定条件は、上記実施形態と同じでもよいし、異なってもよい。また、ここでは、プレイ状態記憶部８２にプレイ状態が記憶されることとするが、プレイヤ端末１において、プレイ状態の記憶、更新は必須ではない。いずれにしても、プレイ状態送信部６７ａが、プレイヤ端末１におけるプレイ状態をサーバ１００に送信すればよい。

また、プレイ状態送信部６７ａがプレイ状態情報を送信する条件は適宜設計可能である。例えば、プレイ状態送信部６７ａは、プレイ状態が変化した場合に、変化後のプレイ状態に対応するプレイ状態情報をサーバ１００に送信する。ただし、プレイ状態送信部６７ａは、一定時間おきに、現在設定されているプレイ状態に対応するプレイ状態情報をサーバ１００に送信してもよい。あるいは、プレイ状態送信部６７ａは、サーバ１００と通信を行うたびに、プレイ状態情報を送信してもよい。

また、第２の実施形態では、上記実施形態と同様に、プレイ状態として、「受け取り可能状態」、「未開封状態」、「開封済状態」、「参加状態」、「受け取り不可状態」の５つの状態が設けられるものとする（図１４Ａ参照）。したがって、プレイ状態送信部６７ａは、互いに識別可能な５種類のプレイ状態情報をサーバ１００に送信する。ただし、第２の実施形態において、プレイ状態は、上記実施形態と異なってもよい。例えば、プレイ状態として、図１４Ａに示す「許可状態」および「不可能状態」の２種類が設定されてもよい。

図３５は、サーバ１００における第２の実施形態のメモリ１１２の構成およびコンピュータとしての機能を説明する図である。第２の実施形態では、サーバ側ゲーム制御用プログラムに、上記の各プログラムに加えて、さらに、プレイ状態受信プログラム１４７、および、プレイ状態更新プログラム１４９が含まれる。そして、ＣＰＵ１１０は、プレイ状態受信プログラム１４７を動作させ、プレイ状態受信部１４７ａとして機能させる。また、ＣＰＵ１１０は、プレイ状態更新プログラム１４９を動作させ、プレイ状態更新部１４９ａとして機能させる。

プレイ状態受信部１４７ａは、プレイヤ端末１から送信されるプレイ状態（プレイ状態情報）を受信する。

プレイ状態更新部１４９ａは、プレイ状態受信部１４７ａが受信したプレイ状態情報に基づいて、プレイヤ端末１のプレイ状態を更新する。なお、プレイ状態は、プレイヤ情報記憶部１６０に記憶されてもよいし、抽出リスト記憶部１６２に記憶されてもよい。さらには、プレイヤ情報記憶部１６０および抽出リスト記憶部１６２とは別に、プレイヤ端末１ごとにプレイ状態を記憶する専用の記憶部がデータ記憶領域１１２ｂに設けられてもよい。第２の実施形態においては、一例として、プレイ状態更新部１４９ａが、プレイヤ端末１ごとのプレイ状態をプレイヤ情報記憶部１６０に記憶する場合について説明する。

また、第２の実施形態においても、リスト更新部１４２ａが、抽出リストの状況フラグをセットする。ただし、第２の実施形態では、「許可状態」、「不可能状態」、「受信可」、「受信不可」、「受信済」の５つの状況フラグが設けられる。このうち、「許可状態」および「不可能状態」は、上記実施形態の「設定可（ブランク）」に代えて設けられ、「受信可」、「受信不可」、「受信済」は、上記実施形態と同じである。リスト更新部１４２ａは、プレイヤ情報記憶部１６０に記憶されたプレイ状態、プレイヤ端末１から入力される操作情報、サーバ１００におけるゲームの実行、管理状況に基づいて、状況フラグを更新する。

リスト更新部１４２ａは、「受け取り可能状態」または「未開封状態」のプレイ状態がプレイヤ情報記憶部１６０に記憶されているプレイヤ端末１について、抽出リストの状況フラグを「許可状態」にセットする。また、リスト更新部１４２ａは、「開封済状態」、「参加状態」、「受け取り不可状態」のプレイ状態がプレイヤ情報記憶部１６０に記憶されているプレイヤ端末１について、抽出リストの状況フラグを「不可能状態」にセットする。

端末設定部１４４ａは、ランダムタブ４８ｃ用の要求情報を受信した場合、抽出リストにおいて、状況フラグが「許可状態」の上位１００名の記憶領域に、招待情報等をセットする。

以下に、第２の実施形態におけるプレイヤ端末１およびサーバ１００の処理の一例について説明する。

図３６Ａは、第２の実施形態におけるプレイヤ端末１およびサーバ１００の処理を説明する第１のシーケンス図である。プレイヤ端末１においてプレイ状態が更新されると（Ｐ２０１）、プレイ状態情報がサーバ１００に送信される。プレイ状態受信部１４７ａがプレイ状態情報を受信すると、プレイ状態更新部１４９ａが、プレイヤ情報記憶部１６０においてプレイ状態を更新する（Ｓ２０１）。また、リスト更新部１４２ａは、プレイヤ情報記憶部１６０に記憶されているプレイ状態に基づいて、抽出リストの状況フラグを更新する。

図３６Ｂは、第２の実施形態におけるプレイヤ端末１およびサーバ１００の処理を説明する第２のシーケンス図である。プレイヤ端末１およびサーバ１００において、マルチプレイによるバトルゲーム制御処理が終了すると（Ｐ２０５、Ｓ２０５）、プレイ状態更新部１４９ａが、プレイヤ情報記憶部１６０においてプレイ状態を「受け取り不可状態」に更新する（Ｓ２０６）。また、リスト更新部１４２ａは、マルチプレイに参加したプレイヤ（ホストプレイヤおよびゲストプレイヤの少なくとも一方）について、抽出リストの状況フラグを「不可能状態」に更新する（Ｓ２０７）。このとき、リスト更新部１４２ａは、ウエイトタイムとして第１の時間をウエイトカウンタにセットする（Ｓ２０８）。

図３６Ｃは、第２の実施形態におけるプレイヤ端末１およびサーバ１００の処理を説明する第３のシーケンス図である。プレイヤ端末１において拒否操作が入力されると（Ｐ２１０）、サーバ１００に拒否情報が送信される。拒否情報を受信すると、プレイ状態更新部１４９ａが、プレイヤ情報記憶部１６０においてプレイ状態を「受け取り不可状態」に更新する（Ｓ２１０）。また、リスト更新部１４２ａは、抽出リストの状況フラグを「不可能状態」に更新する（Ｓ２１１）。このとき、リスト更新部１４２ａは、ウエイトタイムとして第２の時間をウエイトカウンタにセットする（Ｓ２１２）。

なお、詳しい説明は省略するが、上記した第１の時間または第２の時間が経過すると、リスト情報更新処理（図３２参照）において、リスト更新部１４２ａが、プレイヤ情報記憶部１６０のプレイ状態を確認する。このとき、プレイ状態が「受け取り可能状態」または「未開封状態」であれば、リスト更新部１４２ａが、状況フラグを「許可状態」に更新する。一方、プレイ状態が「受け取り可能状態」および「未開封状態」のいずれでもなければ、状況フラグが「不可能状態」に維持される。

以上のように、第２の実施形態によれば、サーバ１００が、プレイ状態更新部１４９ａ（状態更新部）として機能する。プレイ状態更新部１４９ａは、プレイヤ端末１から受信する情報に基づいて、プレイヤ端末１のプレイ状態を更新する。そして、端末設定部１４４ａ（設定部）は、少なくとも、優先ポイント（優先度情報）、および、プレイヤ端末１におけるゲームのプレイ状況に基づいて、対象者端末（抽出端末）を設定する。

また、第２の実施形態では、端末設定部１４４ａ（設定部）は、マルチプレイ（通信ゲーム）が実行されたプレイヤ端末１について、少なくとも、通信ゲームの終了後、第１の時間が経過するまでは、対象者端末（抽出端末）に設定しない。また、端末設定部１４４ａ（設定部）は、招待情報の受信後、マルチプレイ（通信ゲーム）への参加拒否を示す拒否情報が送信されたプレイヤ端末１について、少なくとも、第２の時間が経過するまでは、対象者端末（抽出端末）に設定しない。

なお、第２の実施形態では、プレイヤ端末１からプレイ状態情報が送信される。しかしながら、プレイヤ端末１ではプレイ状態を管理せず、プレイヤ端末１から受信する情報に基づいて、サーバ１００のみが、プレイヤ端末１のプレイ状態を更新してもよい。また、上記の変形例は、第２の実施形態に適用することも可能である。

また、例えば、プレイ状態更新部１４９ａは、プレイ状況すなわちプレイ状態として、プレイヤ端末１のログイン状態を更新してもよい。そして、端末設定部１４４ａは、ログイン状態にあるプレイヤ端末１を対象者端末として設定可能であり、ログイン状態にないプレイヤ端末１は、対象者端末に設定しない。

なお、上記実施形態において、プレイヤ端末１においてプレイ状態が更新されるのに加えて、さらに、サーバ１００においても、プレイ状態として、ログイン状態を更新してもよい。この場合、プレイヤ端末１およびサーバ１００で管理されるプレイ状態と、サーバ１００で管理される優先度情報とに基づいて、対象者の設定が行われる。

以上のように、ゲームのプレイ状況、すなわち、プレイ状態は、プレイヤ端末１で管理されてもよいし、サーバ１００で管理されてもよいし、さらには、プレイヤ端末１およびサーバ１００の双方で管理されてもよい。ただし、プレイヤ端末１でプレイ状態を管理することで、サーバ１００の処理負荷が軽減される。一方、サーバ１００でプレイ状態を管理した場合には、招待情報を受信、または、招待情報の受信の報知を即座に実行可能なプレイヤ端末１を、サーバ１００が把握することができる。そのため、招待情報を受信、または、招待情報の受信の報知を即座に実行可能なプレイヤ端末１のみを、対象者端末に設定することができる。これにより、マルチプレイをより早期に開始することができる。

なお、上記各実施形態および変形例では、クライアントサーバシステムである情報処理システムＳが、上記の各情報処理を行う。しかしながら、上記実施形態および変形例におけるプレイヤ端末１のみが、ゲーム端末装置として設けられてもよい。ゲーム端末装置は、通信機能を備えていれば、スマートフォンに限らず、専用のゲーム機器であってもよい。また、上記実施形態および変形例におけるサーバ１００のみが、サーバ装置として設けられてもよい。

また、上記各実施形態および変形例におけるプログラムは、コンピュータが読み取り可能な記憶媒体に格納され、記憶媒体として提供されてもよい。さらには、この記憶媒体を含むゲーム端末装置またはサーバ装置として提供されてもよい。また、上記実施形態および変形例は、各機能およびフローチャートに示すステップを実現する情報処理方法としてもよい。

以上、添付図面を参照しながら実施形態の一態様について説明したが、本発明は上記実施形態および変形例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇において、各種の変形例または修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。

本発明は、情報処理プログラム、サーバ装置および情報処理システムに利用することができる。

４６ ルーム作成タブ（操作部）
６０ａ ゲーム実行部
６４ａ 要求情報送信部
６８ａ 招待情報受信部（受信部）
１００ サーバ
１４０ａ プレイヤ情報更新部（更新部）
１４４ａ 端末設定部（設定部）
１４６ａ ゲーム実行部
Ｓ 情報処理システム

上記課題を解決するために、情報処理プログラムは、複数のプレイヤが同時にプレイ可能な通信ゲームへの参加を招待する招待情報について、他のプレイヤ端末に受信させるように要求する要求情報を、いずれかのプレイヤ端末から受信すると、少なくとも、複数のプレイヤ端末の中で招待情報を受信可能な抽出端末に設定される優先度の高さを示す優先度情報に基づき、要求情報を送信したプレイヤ端末と異なる複数のプレイヤ端末を抽出端末に設定し、招待情報を確認する受信確認情報がサーバに送信された抽出端末に招待情報を受信させる、サーバに設けられた設定部と、サーバに設けられ、招待情報を受信した後、所定の参加情報がサーバに送信されたいずれか１または複数の抽出端末と、要求情報を送信したプレイヤ端末との通信ゲームを実行するゲーム実行部と、サーバに設けられ、少なくとも受信確認情報の送信後に招待情報を受信した抽出端末の優先度情報を更新し、優先度を下げる更新部と、してコンピュータを機能させる。

また、設定部は、優先度情報と異なる、プレイヤ端末におけるゲームのプレイ状況に基づいて、抽出端末を設定してもよい。

また、設定部は、招待情報の受信後、通信ゲームへの参加拒否を示す拒否情報がサーバに送信されたプレイヤ端末について、少なくとも、第２の時間が経過するまでは、抽出端末に設定しないとしてもよい。

上記課題を解決するために、情報処理システムは、プレイヤ端末に設けられ、複数のプレイヤが同時にプレイ可能な通信ゲームへの参加を招待する招待情報について、他のプレイヤ端末に受信させるように要求する要求情報をサーバに送信する要求情報送信部と、プレイヤ端末に設けられ、招待情報を確認する受信確認情報をサーバに送信する受信確認情報送信部と、サーバに設けられ、いずれかのプレイヤ端末から要求情報を受信すると、少なくとも、複数のプレイヤ端末の中で招待情報を受信可能な抽出端末に設定される優先度の高さを示す優先度情報に基づき、要求情報を送信したプレイヤ端末と異なる複数のプレイヤ端末を抽出端末に設定し、受信確認情報がサーバに送信された抽出端末に招待情報を受信させる設定部と、プレイヤ端末に設けられ、抽出端末としてサーバから招待情報を受信し得る受信部と、プレイヤ端末に設けられ、抽出端末として招待情報を受信した後、所定の参加操作の入力に基づいて参加情報をサーバに送信する参加情報送信部と、サーバに設けられ、参加情報が送信されたいずれか１または複数の抽出端末と、要求情報を送信したプレイヤ端末との通信ゲームを実行するゲーム実行部と、サーバに設けられ、少なくとも受信確認情報の送信後に招待情報を受信した抽出端末の優先度情報を更新し、優先度を下げる更新部と、を備える。

上記課題を解決するために、情報処理プログラムは、複数のプレイヤが同時にプレイ可能であって、プレイヤの操作によって敵キャラクタにダメージを付与可能な通信ゲームへの参加を招待する招待情報について、他のプレイヤ端末に受信させるように要求する要求情報を、いずれかのプレイヤ端末から受信すると、少なくとも、複数のプレイヤ端末の中で招待情報を受信可能な抽出端末に設定される優先度の高さを示す優先度情報に基づき、要求情報を送信したプレイヤ端末と異なる複数のプレイヤ端末を抽出端末に設定し、招待情報を確認する受信確認情報がサーバに送信された抽出端末に招待情報を受信させる、サーバに設けられた設定部と、サーバに設けられ、招待情報を受信した後、所定の参加情報がサーバに送信されたいずれか１または複数の抽出端末と、要求情報を送信したプレイヤ端末との通信ゲームを実行するゲーム実行部と、サーバに設けられ、少なくとも受信確認情報の送信後に招待情報を受信した抽出端末の優先度情報を更新し、優先度を下げるとともに、通信ゲームに参加したプレイヤ端末のうち、通信ゲームにおいて敵キャラクタに与えた全ダメージに占める与ダメージの割合が所定値以上のプレイヤ端末の優先度を上げる更新部と、してコンピュータを機能させる。

また、設定部は、招待情報の受信後、通信ゲームへの参加拒否を示す拒否情報がサーバに送信されたプレイヤ端末について、少なくとも、第２の時間が経過するまでは、抽出端末に設定せず、更新部は、拒否情報がサーバに送信されたプレイヤ端末の優先度を下げてもよい。

上記課題を解決するために、情報処理システムは、プレイヤ端末に設けられ、複数のプレイヤが同時にプレイ可能であって、プレイヤの操作によって敵キャラクタにダメージを付与可能な通信ゲームへの参加を招待する招待情報について、他のプレイヤ端末に受信させるように要求する要求情報をサーバに送信する要求情報送信部と、プレイヤ端末に設けられ、招待情報を確認する受信確認情報をサーバに送信する受信確認情報送信部と、サーバに設けられ、いずれかのプレイヤ端末から要求情報を受信すると、少なくとも、複数のプレイヤ端末の中で招待情報を受信可能な抽出端末に設定される優先度の高さを示す優先度情報に基づき、要求情報を送信したプレイヤ端末と異なる複数のプレイヤ端末を抽出端末に設定し、受信確認情報がサーバに送信された抽出端末に招待情報を受信させる設定部と、プレイヤ端末に設けられ、抽出端末としてサーバから招待情報を受信し得る受信部と、プレイヤ端末に設けられ、抽出端末として招待情報を受信した後、所定の参加操作の入力に基づいて参加情報をサーバに送信する参加情報送信部と、サーバに設けられ、参加情報が送信されたいずれか１または複数の抽出端末と、要求情報を送信したプレイヤ端末との通信ゲームを実行するゲーム実行部と、サーバに設けられ、少なくとも受信確認情報の送信後に招待情報を受信した抽出端末の優先度情報を更新し、優先度を下げるとともに、通信ゲームに参加したプレイヤ端末のうち、通信ゲームにおいて敵キャラクタに与えた全ダメージに占める与ダメージの割合が所定値以上のプレイヤ端末の優先度を上げる更新部と、を備える。

Claims (8)

1. 予め設定された更新条件にしたがって、プレイヤごとの優先度情報を更新する更新部と、
   プレイヤ端末から要求情報を受信すると、少なくとも、前記優先度情報に基づき、複数のプレイヤ端末を、招待情報を受信可能な抽出端末に設定し得る設定部と、
   前記招待情報を受信し、かつ、所定の参加情報が送信されたいずれか１または複数の抽出端末と、要求情報を送信したプレイヤ端末との通信ゲームを実行するゲーム実行部と、
   してコンピュータを機能させる情報処理プログラム。
2. 前記更新部は、通信ゲーム中の所定の結果に基づいて、前記優先度情報を更新する請求項１に記載の情報処理プログラム。
3. 前記更新部は、前記招待情報の受信後に抽出端末から受信した情報に基づいて、前記優先度情報を更新する請求項１または２に記載の情報処理プログラム。
4. 前記設定部は、少なくとも、前記優先度情報、および、プレイヤ端末におけるゲームのプレイ状況に基づいて、抽出端末を設定する請求項１から３のいずれか１項に記載の情報処理プログラム。
5. 前記設定部は、通信ゲームが実行されたプレイヤ端末について、少なくとも、通信ゲームの終了後、第１の時間が経過するまでは、抽出端末に設定しない請求項４に記載の情報処理プログラム。
6. 前記設定部は、前記招待情報の受信後、通信ゲームへの参加拒否を示す拒否情報が送信されたプレイヤ端末について、少なくとも、第２の時間が経過するまでは、抽出端末に設定しない請求項４または５に記載の情報処理プログラム。
7. 請求項１から６のいずれか１項に記載の情報処理プログラムが記憶された記憶媒体を含むサーバ装置。
8. 予め設定された更新条件にしたがって、プレイヤごとの優先度情報を更新する更新部と、
   プレイヤ端末の操作部における要求操作の入力により、要求情報を送信する要求情報送信部と、
   プレイヤ端末から前記要求情報を受信すると、少なくとも、前記優先度情報に基づき、複数のプレイヤ端末を、招待情報を受信可能な抽出端末に設定し得る設定部と、
   抽出端末において、前記招待情報を受信し得る受信部と、
   前記招待情報を受信した抽出端末のうち、所定の参加操作の入力に基づいて参加情報が送信されたいずれか１または複数の抽出端末と、前記要求情報を送信したプレイヤ端末との通信ゲームを実行するゲーム実行部と、
   を備える情報処理システム。

Images