JP7036970B1 - 情報処理プログラム、情報処理方法および情報処理システム - Google Patents

Abstract

【課題】課題は操作性を向上させる情報処理プログラムを提供することである。【解決手段】情報処理プログラムは、プレイ中のゲーム画面を表示し、複数種別の招待ゲームのいずれかへの参加を招待する招待情報を外部装置から複数受信可能であり、受信した招待情報に対応し、招待ゲームに関するゲーム情報の一部を識別可能な報知画像を、プレイ中のゲーム画面の表示を維持した状態で表示し、複数の招待情報を受信した場合に、招待情報ごとに報知画像を表示し、報知画像を選択するプレイヤの操作が入力された場合に、報知画像よりも詳細なゲーム情報、および、招待ゲームへの参加操作を受け付ける操作部を少なくとも含む所定画像を、プレイ中のゲーム画面を識別可能な状態で表示し、操作部に対して参加操作が入力された場合に、招待ゲームに参加するための処理を、コンピュータに実行させる。【選択図】図６

Description

本発明は、情報処理プログラム、情報処理方法および情報処理システムに関する。

従来、複数のプレイヤが参加可能な通信ゲーム（以下、マルチプレイという）が知られている。マルチプレイでは、ゲームの参加希望者をマッチングする必要がある。例えば、特許文献１には、ホストプレイヤがルームを作成すると、ゲームをプレイ中の他のプレイヤに招待情報が送信されるゲームシステムが提案されている。

このゲームシステムによれば、招待情報を受信したプレイヤのゲーム画面に、招待情報の受信を知らせるマークが強調表示される。このマークをプレイヤがタップすると、招待されたゲームの詳細情報が表示される。

特許第６６３４５３４号

上記のゲームシステムによれば、招待情報を受信したプレイヤの操作が煩雑になる場合がある。そのため、更なる操作性の向上が希求されている。

本発明は、操作性を向上することが可能な情報処理プログラム、情報処理方法および情報処理システムを提供することを目的としている。

上記課題を解決するために、情報処理プログラムは、プレイ中のゲーム画面を表示する表示制御部と、複数種別の招待ゲームのいずれかへの参加を招待する招待情報を外部装置から複数受信し得る受信部と、受信した招待情報に対応し、招待ゲームに関するゲーム情報の一部を識別可能な報知画像を、プレイ中のゲーム画面の表示を維持した状態で表示し、複数の招待情報を受信した場合に、招待情報ごとに報知画像を表示する報知部と、報知画像を選択するプレイヤの操作が入力された場合に、報知画像よりも詳細なゲーム情報、および、招待ゲームへの参加操作を受け付ける操作部を少なくとも含む所定画像を、プレイ中のゲーム画面を識別可能な状態で表示する所定画像表示部と、操作部に対して参加操作が入力された場合に、招待ゲームに参加するための処理を実行する処理部と、してコンピュータを機能させ、報知部は、報知画像の表示開始から所定時間が経過すると、報知画像を非表示とし、招待情報を受信した後、新たな招待情報を受信した場合、新たに受信した招待情報に対応する報知画像に加えて、相対的に先に受信した招待情報に対応する報知画像を表示する。
上記課題を解決するために、情報処理プログラムは、プレイ中のゲーム画面を表示する表示制御部と、複数種別の招待ゲームのいずれかへの参加を招待する招待情報を外部装置から複数受信し得る受信部と、受信した招待情報を上限数の範囲内で保持する保持部と、受信した招待情報に対応し、招待ゲームに関するゲーム情報の一部を識別可能な報知画像を、プレイ中のゲーム画面の表示を維持した状態で表示し、複数の招待情報を受信した場合に、招待情報ごとに報知画像を表示する報知部と、報知画像を選択するプレイヤの操作が入力された場合に、報知画像よりも詳細なゲーム情報と、該招待ゲームへの参加操作および保持している招待情報の削除操作を受け付ける操作部とを少なくとも含む所定画像を、プレイ中のゲーム画面を識別可能な状態で表示する所定画像表示部と、操作部に対して参加操作が入力された場合に、招待ゲームに参加するための処理を実行する処理部と、操作部に対して削除操作が入力された場合に、削除操作が入力された操作部を含む所定画像に対応する招待情報を削除する削除部と、してコンピュータを機能させる。

また、所定画像表示部は、参加操作を少なくとも含む所定操作の入力に基づいて、所定画像を非表示としてもよい。

また、招待ゲームは、複数のプレイヤそれぞれのプレイヤ端末が通信接続されて実行されてもよく、ゲーム情報には、招待ゲームの種別、および、参加するプレイヤに関する情報の少なくともいずれかが含まれてもよい。

また、複数の報知画像が表示される場合、複数の報知画像それぞれに対応する招待ゲームは、互いに種別が異なってもよい。

上記課題を解決するために、情報処理方法は、プレイ中のゲーム画面を表示するステップと、複数種別の招待ゲームのいずれかへの参加を招待する招待情報を外部装置から複数受信し得るステップと、受信した招待情報に対応し、招待ゲームに関するゲーム情報の一部を識別可能な報知画像を、プレイ中のゲーム画面の表示を維持した状態で表示し、複数の招待情報を受信した場合に、招待情報ごとに報知画像を表示するステップと、報知画像を選択するプレイヤの操作が入力された場合に、報知画像よりも詳細なゲーム情報、および、招待ゲームへの参加操作を受け付ける操作部を少なくとも含む所定画像を、プレイ中のゲーム画面を識別可能な状態で表示するステップと、操作部に対して参加操作が入力された場合に、招待ゲームに参加するための処理を実行するステップと、を含み、報知画像を表示するステップでは、報知画像の表示開始から所定時間が経過すると、報知画像を非表示とし、招待情報を受信した後、新たな招待情報を受信した場合、新たに受信した招待情報に対応する報知画像に加えて、相対的に先に受信した招待情報に対応する報知画像を表示する。
上記課題を解決するために、情報処理方法は、プレイ中のゲーム画面を表示するステップと、複数種別の招待ゲームのいずれかへの参加を招待する招待情報を外部装置から複数受信し得るステップと、受信した招待情報を上限数の範囲内で保持するステップと、受信した招待情報に対応し、招待ゲームに関するゲーム情報の一部を識別可能な報知画像を、プレイ中のゲーム画面の表示を維持した状態で表示し、複数の招待情報を受信した場合に、招待情報ごとに報知画像を表示するステップと、報知画像を選択するプレイヤの操作が入力された場合に、報知画像よりも詳細なゲーム情報と、該招待ゲームへの参加操作および保持している招待情報の削除操作を受け付ける操作部とを少なくとも含む所定画像を、プレイ中のゲーム画面を識別可能な状態で表示するステップと、操作部に対して参加操作が入力された場合に、招待ゲームに参加するための処理を実行するステップと、操作部に対して削除操作が入力された場合に、削除操作が入力された操作部を含む所定画像に対応する招待情報を削除するステップと、を含む。

上記課題を解決するために、情報処理システムは、プレイヤ端末と外部装置とが通信接続される情報処理システムであって、プレイヤ端末は、プレイ中のゲーム画面を表示する表示制御部と、複数種別の招待ゲームのいずれかへの参加を招待する招待情報を外部装置から複数受信し得る受信部と、受信した招待情報に対応し、招待ゲームに関するゲーム情報の一部を識別可能な報知画像を、プレイ中のゲーム画面の表示を維持した状態で表示し、複数の招待情報を受信した場合に、招待情報ごとに報知画像を表示する報知部と、報知画像を選択するプレイヤの操作が入力された場合に、報知画像よりも詳細なゲーム情報、および、招待ゲームへの参加操作を受け付ける操作部を少なくとも含む所定画像を、プレイ中のゲーム画面を識別可能な状態で表示する所定画像表示部と、操作部に対して参加操作が入力された場合に、招待ゲームに参加するための処理を実行する処理部と、を備え、報知部は、報知画像の表示開始から所定時間が経過すると、報知画像を非表示とし、招待情報を受信した後、新たな招待情報を受信した場合、新たに受信した招待情報に対応する報知画像に加えて、相対的に先に受信した招待情報に対応する報知画像を表示する。
上記課題を解決するために、情報処理システムは、プレイヤ端末と外部装置とが通信接続される情報処理システムであって、プレイヤ端末は、プレイ中のゲーム画面を表示する表示制御部と、複数種別の招待ゲームのいずれかへの参加を招待する招待情報を外部装置から複数受信し得る受信部と、受信した招待情報を上限数の範囲内で保持する保持部と、受信した招待情報に対応し、招待ゲームに関するゲーム情報の一部を識別可能な報知画像を、プレイ中のゲーム画面の表示を維持した状態で表示し、複数の招待情報を受信した場合に、招待情報ごとに報知画像を表示する報知部と、報知画像を選択するプレイヤの操作が入力された場合に、報知画像よりも詳細なゲーム情報と、該招待ゲームへの参加操作および保持している招待情報の削除操作を受け付ける操作部とを少なくとも含む所定画像を、プレイ中のゲーム画面を識別可能な状態で表示する所定画像表示部と、操作部に対して参加操作が入力された場合に、招待ゲームに参加するための処理を実行する処理部と、操作部に対して削除操作が入力された場合に、削除操作が入力された操作部を含む所定画像に対応する招待情報を削除する削除部と、を備える。

本発明によれば、操作性を向上することが可能となる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

また、ディスプレイ２６には、サムネイル表示領域５２が設けられている。サムネイル表示領域５２は、ディスプレイ２６の左端の上方であって、通知画像３４の近傍に設けられている。より詳細には、サムネイル表示領域５２は、通知画像３４の下方に設けられている。サムネイル表示領域５２は、通常、何も表示されておらず、プレイヤが識別することができない。

そして、プレイヤ端末１が新たに招待情報を受信した場合には、サムネイル表示領域５２にサムネイル画像５２ａが表示される。サムネイル画像５２ａは、バトルゲームの種別ごとに設けられており、例えば、ホストプレイヤが選択したバトルゲーム、すなわち、招待されたバトルゲームの種別に対応するサムネイル画像５２ａがサムネイル表示領域５２に表示される。

つまり、新たに招待情報を受信すると、受信した招待情報に対応するサムネイル画像５２ａが、サムネイル表示領域５２に表示されることとなる。ここでは、サムネイル画像５２ａに、バトルゲームの敵キャラクタが表示されている。プレイヤは、サムネイル画像５２ａに表示される敵キャラクタによって、招待されたバトルゲームの種別を把握することができる。

なお、サムネイル画像５２ａの表示内容は特に限定されるものではない。例えば、バトルゲームの種別ごとに設定された名称が表示されてもよい。あるいは、ゲーム全体を通して、バトルゲームの種別ごとに識別マークが設定されている場合には、識別マークがサムネイル画像５２ａに表示されてもよい。このように、サムネイル画像５２ａによって、招待されたバトルゲームの種別を識別可能とすることが望ましい。

ただし、サムネイル画像５２ａは、バトルゲームの種別を識別可能な態様に限らない。例えば、サムネイル画像５２ａは、招待された対象者が、フォロワ、相互フォロワ、ランダムのいずれであるのかを識別可能に構成されてもよい。あるいは、サムネイル画像５２ａは、ホストプレイヤの名称、レベル等、ホストプレイヤに関する何らかの情報を識別可能に構成されてもよい。いずれにしても、サムネイル画像５２ａは、招待情報に対応したものが表示されればよく、その表示態様や、プレイヤが識別できる情報は特に限定されない。

なお、サムネイル表示領域５２は、通常画面およびバトル画面において、種々のゲーム画像が表示される表示領域内に設けられている。また、サムネイル画像５２ａは、プレイ中のゲーム画面の表示を維持した状態で表示される。つまり、サムネイル画像５２ａは、プレイ中のゲーム画面に重畳表示される。ただし、サムネイル画像５２ａには透過率が設定されており、プレイヤは、サムネイル画像５２ａが表示された状態でも、サムネイル画像５２ａを透過してプレイ中のゲーム画面を視認することが可能となっている。

また、サムネイル画像５２ａは、所定時間（例えば１０秒）が経過すると、サムネイル表示領域５２から自動的に消去されて非表示となる。つまり、サムネイル画像５２ａは、新たに招待情報を受信してから、所定時間のみ表示される。ただし、サムネイル画像５２ａが非表示となった後も、通知画像３４は報知態様で表示されている。したがって、プレイヤは、サムネイル画像５２ａが非表示となった後も、招待情報を受信した状態であることを把握することができる。

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

また、バトル画面の表示中においても、新たに招待情報を受信した場合には、通常画面の表示中と同様に、サムネイル表示領域５２にサムネイル画像５２ａが表示される。なお、ここでは、通常画面とバトル画面とで、サムネイル表示領域５２の位置が共通であることとするが、通常画面とバトル画面とで、サムネイル表示領域５２の位置が異なってもよい。

また、サムネイル画像５２ａは、通常画面とバトル画面とで共通である。ただし、通常画面とバトル画面とで、それぞれ異なるサムネイル画像５２ａが設けられており、同一の招待情報を受信したとしても、表示中の画面によって、異なるサムネイル画像５２ａが表示されてもよい。一例として、通常画面で表示されるサムネイル画像５２ａは、バトル画面で表示されるサムネイル画像５２ａよりも、多くの情報が記されていてもよい。また、他の例としては、通常画面で表示されるサムネイル画像５２ａは、バトル画面で表示されるサムネイル画像５２ａよりも、表示面積が大きく、プレイヤが気付きやすくてもよい。

バトル画面の表示中、すなわち、バトルゲーム中は、プレイヤの操作が頻繁に要求される。また、バトルゲームの内容によっては、プレイヤの操作タイミングが重要となることもある。一方で、通常画面の表示中については、プレイヤの操作タイミングが重要ではない。したがって、バトル画面の表示中は、通常画面の表示中に比べて、サムネイル画像５２ａが表示されたときに、プレイヤが即座に反応しにくい場合や、詳細な情報を把握することが難しい場合が多くある。したがって、上記のように、バトル画面で表示されるサムネイル画像５２ａが、通常画面で表示されるサムネイル画像５２ａよりも簡素であれば、プレイヤに鬱陶しさを与えるおそれが低減される。

なお、一度非表示となったサムネイル画像５２ａが再表示された場合、招待情報が削除されるまで、サムネイル画像５２ａの表示が継続してもよい。

ここで、本実施形態では、プレイヤ端末１は、招待情報をサーバ１００から複数受信し得る。ここでは、プレイヤ端末１が、最大で３つの招待情報を同時に保持することができる。図６Ｂには、プレイヤ端末１が、３つの招待情報を受信した状態を示している。例えば、プレイヤ端末１が、２つの招待情報を保持した状態で、新たに３つ目の招待情報を受信したとする。

この場合、新たに受信した招待情報に対応するサムネイル画像５２ａに加えて、先に受信した招待情報に対応するサムネイル画像５２ａも同時に表示される。このように、複数の招待情報を受信した場合には、招待情報ごとにサムネイル画像５２ａが表示される。これにより、プレイヤは、招待情報の受信数と、どのようなバトルゲームに招待されているのかを容易に把握することができる。

なお、ここでは、新たな招待情報を受信した際に、既に受信済みの招待情報に対応するサムネイル画像５２ａが表示されることとした。ただし、新たな招待情報を受信した場合に、新たな招待情報に対応するサムネイル画像５２ａのみが表示されてもよい。

図６Ｃは、図６Ｂに示すバトル画面の表示中に、通知画像３４またはサムネイル画像５２ａがタップされた状態を示している。つまり、図６Ｂに示す状態で通知画像３４またはサムネイル画像５２ａがタップされると、図６Ｃに示す状態に画面が遷移する。図６Ｃに示すように、バトル画面の表示中に通知画像３４またはサムネイル画像５２ａがタップされると、操作タブ４２がタップされた場合と同様にバトルゲームが中断される。このとき、中断時のバトル画面が停止表示されるとともに、ディスプレイ２６の全体が暗くなる。また、バトル画面の停止表示状態では、通知画像３４が操作タブ４２に切り替わり、中断時のバトル画面に重畳して招待情報画像５４が表示される。

招待情報画像５４は、サムネイル画像５２ａごとに、すなわち、招待情報ごとに表示される。したがって、ここでは、３つの招待情報を受信しているため、招待情報画像５４が３つ表示されている。招待情報画像５４は、ゲーム情報表示部５４ａおよび操作部５４ｂを含む。ゲーム情報表示部５４ａには、招待情報に含まれる情報の一部または全部が表示される。具体的には、ゲーム情報表示部５４ａには、バトルゲームの種別が、当該バトルゲームに登場する敵キャラクタの画像（図中、左側のキャラクタ画像）によって示される。

なお、ここでは、ゲーム情報表示部５４ａに表示される敵キャラクタの画像、すなわち、バトルゲームの種別を示す画像は、サムネイル画像５２ａに示される画像と同じである。また、ゲーム情報表示部５４ａには、バトルゲームの難易度を示す情報（図中、「上級」または「中級」と示す）が表示される。例えば、バトルゲームは、敵キャラクタが異なる複数の種別に分類されており、各種別のバトルゲームは、さらに、難易度を異にする複数のゲームモードに分類されている。したがって、ゲーム情報表示部５４ａには、バトルゲームの種別とともに、バトルゲームの難易度が表示されていることとなる。

さらに、ゲーム情報表示部５４ａには、バトルゲームに参加する味方キャラクタの画像（図中、右側のキャラクタ画像）が表示される。ここでは、バトルゲームに参加する味方キャラクタのうち、ホストプレイヤが選択した味方キャラクタが表示されている。このように、招待情報画像５４のゲーム情報表示部５４ａには、サムネイル画像５２ａに対応するバトルゲームに関するゲーム情報が表示される。

ゲーム情報表示部５４ａには、サムネイル画像５２ａによって示される情報よりも詳細な情報が表示される。具体的には、プレイヤは、サムネイル画像５２ａによって、バトルゲームの種別のみを把握することができる。一方で、プレイヤは、ゲーム情報表示部５４ａによって、バトルゲームの種別、バトルゲームの難易度、バトルゲームに参加する一部の味方キャラクタの種別、ホストプレイヤに関する情報等を把握することができる。

操作部５４ｂには、「削除」と記された削除タブ、および、「参加」と記された参加タブが設けられる。削除タブは、招待情報を削除する削除操作を受け付け、参加タブは、招待されたバトルゲームに参加するための参加操作を受け付ける。操作部５４ｂは、対応するゲーム情報表示部５４ａが識別可能に表示される。削除タブがタップされると、対応する招待情報がプレイヤ端末１から削除され、招待情報画像５４が非表示となる。

例えば、図６Ｃに示すように、上段、中段、下段の３つの操作部５４ｂのうち、上段の操作部５４ｂの削除タブがタップされたとする。この場合、上段の招待情報画像５４に対応する招待情報が削除されるとともに、上段の招待情報画像５４が非表示となる。ただし、この場合には、中段および下段の招待情報画像５４は表示されたままとなる。

また、参加タブがタップされて参加操作が入力された場合には、招待されたバトルゲームに参加するための処理が実行される。具体的には、参加操作が入力されると、対象者のプレイヤ端末１からサーバ１００に参加情報が送信される。サーバ１００では、参加情報が入力されると、招待されたルームへの入室可否が判定される。

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

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

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

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

上記のように、操作部５４ｂの参加タブへの参加操作の入力によって、招待されたバトルゲームに参加した場合、より詳細には、招待されたルームに入室した場合には、プレイヤ端末１から全ての招待情報が削除される。

一方で、ルームに入室できなかった場合には、ルームに入室できない旨が報知された後、元のゲーム画面が表示される。このとき、プレイヤが選択した招待情報が削除されるとともに、参加タブがタップされた招待情報画像５４が非表示となる。ただし、この場合には、他の招待情報は消去されないため、プレイヤが選択していない招待情報に対応する招待情報画像５４は表示可能である。

なお、図６Ｃに示すように、招待情報画像５４が表示された状態で、招待情報画像５４以外の領域がタップされると、中断されたバトルゲームが再開される。この場合には、招待情報画像５４が非表示となり、図６Ｂに示すようにバトル画面が表示される。ただし、バトルゲームが中断した後に再開された場合には、サムネイル画像５２ａが非表示となる。

なお、上記したように、サムネイル画像５２ａは、招待情報を受信してから１０秒間、表示されたままとなり、１０秒が経過すると、自動的に非表示となる。また、サムネイル画像５２ａの表示中に、通知画像３４またはサムネイル画像５２ａがタップされて招待情報画像５４が表示された場合にも、サムネイル画像５２ａが非表示となる。

例えば、招待情報を受信してサムネイル画像５２ａが表示された直後に、通知画像３４またはサムネイル画像５２ａがタップされて招待情報画像５４が表示されたとする。その後、すぐにバトルゲームが再開されたときに、招待情報を受信してから１０秒が経過していなければ、サムネイル画像５２ａが表示されるとしてもよい。あるいは、招待情報画像５４が表示された後、バトルゲームが再開された場合には、バトルゲームの再開から所定時間だけサムネイル画像５２ａが表示されるとしてもよい。さらには、招待情報画像５４が表示される際に、サムネイル画像５２ａが同時に表示されていてもよい。

なお、上記したように、バトルゲーム中に招待情報を受信した場合、通知画像３４が報知態様で表示されるとともに、サムネイル画像５２ａがバトル画面に重畳して表示される。サムネイル画像５２ａは、１０秒が経過すると非表示となるが、通知画像３４は報知態様で表示されたままとなる。このように、サムネイル画像５２ａが非表示となった後に、報知態様で表示されている通知画像３４がタップされた場合にも、上記と同様、図６Ｃに示すように、中断時のバトル画面に重畳して招待情報画像５４が表示される。

また、図６Ｃに示す状態で、操作タブ４２がタップされると、図６Ｄに示すように、ポーズ画面が表示される。ポーズ画面では、中断時のバトル画面に重畳してポーズダイアログ５６が表示される。ポーズダイアログ５６には、中断しているバトルゲームに関する情報が表示される。また、ポーズダイアログ５６には、操作タブ４２が設けられている。ポーズダイアログ５６の表示中に操作タブ４２がタップされると、ポーズダイアログ５６がディスプレイ２６の左側に向けてフレームアウトし、バトルゲームが再開される。

なお、招待情報を受信していない状態では、バトル画面の表示中、ディスプレイ２６の左上に操作タブ４２が表示されている。このときに操作タブ４２がタップされた場合には、バトルゲームの中断時に、上記したとおり、リタイア操作部および再開操作部が設けられた中断画面が表示される。このように、バトルゲーム中に操作タブ４２がタップされた場合には中断画面が表示され、バトルゲームの中断後、招待情報画像５４の表示中に、操作タブ４２またはゲーム情報表示部５４ａがタップされた場合には、中断画面と異なるポーズ画面が表示される。

ただし、バトルゲーム中に操作タブ４２がタップされた場合と、招待情報画像５４の表示中に操作タブ４２がタップされた場合とで、共通の画面が表示されてもよい。また、ポーズダイアログ５６に、リタイア操作部および再開操作部が設けられてもよい。

上記のように、招待情報画像５４には、招待されたバトルゲームの詳細な情報が表示されることから、招待情報画像５４の表示は、招待情報の開封と言える。すなわち、報知態様の通知画像３４もしくはサムネイル画像５２ａのタップにより、招待情報が開封されることとなる。一方で、サムネイル画像５２ａが表示された時点では、招待情報が開封されたことにならない。

また、招待情報画像５４の表示後に、操作部５４ｂがタップされることなく、バトルゲームが再開された場合、あるいは、ポーズ画面が表示された場合には、招待情報が保持されたままとなっている。つまり、招待情報画像５４の表示後に、招待情報を削除せずに画面を遷移させる操作は保留操作となり、保留操作が入力された場合には、招待されたバトルゲームへの参加が保留された保留状態となる。

次に、サーバ１００における対象者の抽出方法について説明し、その後、プレイヤ端末１における招待情報の受信ならびに報知方法について説明する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

具体的には、状況フラグは、招待情報の受信状況を識別するものであり、ここでは、「受信１」、「受信２」、「受信３」、「設定可」、「受信可」、「受信不可」、の６つの受信状況に識別される。受信状況の「受信１」、「受信２」、「受信３」は、対象者端末が招待情報を受信したことを示している。より詳細には、「受信１」は、１つの招待情報を受信した状態であることを示しており、「受信２」は、２つの招待情報を受信した状態であることを示しており、「受信３」は、３つの招待情報を受信した状態であることを示している。

上記したように、１のプレイヤ端末１は、最大で３つの招待情報を受信、保持することが可能である。したがって、受信状況の「受信１」、「受信２」は、新たな招待情報の設定が可能であることを示している。一方で、受信状況の「受信３」は、新たな招待情報の設定が不可能であることを示している。

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

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

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

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

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

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

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

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

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

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

なお、サーバ１００では、プレイヤ端末１ごとに、招待情報の受信数を計数している。そして、上記したように、状況フラグの「受信１」、「受信２」のプレイヤ端末１は、さらに招待情報を受信することができる。例えば、状況フラグが「受信１」のプレイヤ端末１に、新たに招待情報がセットされると、状況フラグが「受信可」または「受信不可」に更新される。その後、新たにセットされた招待情報が受信されると、招待情報の受信数が「２」に更新されるとともに、状況フラグが「受信２」に更新される。

また、プレイヤ端末１において、招待情報を受信した後、操作部５４ｂの削除タブがタップされると、削除情報がサーバ１００に送信される。サーバ１００では、削除情報を受信すると、削除情報を送信したプレイヤ端末１にセットされた招待情報を削除する。また、マルチプレイが終了した場合や、ルームが消滅した場合等、招待情報が無効になった場合にも、招待情報が削除される。

そして、招待情報が削除された場合には、招待情報の受信数が「１」減算される。例えば、状況フラグが「受信２」のプレイヤ端末１から削除情報を受信した場合には、状況フラグが「受信１」に更新される。また、状況フラグが「受信１」のプレイヤ端末１から削除情報を受信した場合には、状況フラグがブランクに更新される。

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

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

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

（プレイヤ端末１のプレイ状態）
図１２Ａは、プレイヤ端末１のプレイ状態を説明する図である。図１２Ｂは、招待情報の受信確認のタイミングを説明する図である。プレイヤ端末１は、ゲームのプレイ状況、および、招待情報の受信状況に基づいて、プレイ状態を更新する。なお、プレイヤ端末１には、後述する第１状態記憶部８２、第２状態記憶部８４および第３状態記憶部８６の３つの状態記憶部が設けられている。

プレイヤ端末１では、招待情報を受信すると、３つの状態記憶部のうちのいずれか１つが、受信した招待情報に割り当てられる。プレイヤ端末１では、割り当てられた状態記憶部に招待情報が記憶される。また、各状態記憶部には、プレイ状態が記憶される。そして、各状態記憶部では、招待情報が割り当てられているか否か等に基づいて、それぞれ別個にプレイ状態が更新される。

なお、上記したように、サムネイル表示領域５２には、最大で３つのサムネイル画像５２ａが表示される。換言すれば、サムネイル表示領域５２には、サムネイル画像５２ａが表示される３つの表示位置が定められている。３つの状態記憶部には、それぞれサムネイル表示領域５２のうち、サムネイル画像５２ａが表示されるいずれか１つの表示位置が対応付けられている。

例えば、第１状態記憶部８２には、サムネイル表示領域５２のうち最も上方の第１表示位置が対応付けられている。また、第２状態記憶部８４には、サムネイル表示領域５２のうち中央の第２表示位置が対応付けられている。また、第３状態記憶部８６には、サムネイル表示領域５２のうち最も下方の第３表示位置が対応付けられている。仮に、招待情報を受信した際に、この招待情報に対して第１状態記憶部８２が割り当てられた場合には、第１表示位置にサムネイル画像５２ａが表示されることとなる。

図１２Ａに示すように、プレイヤ端末１において、各状態記憶部で管理されるプレイ状態は、受け取り可能状態、未開封状態、開封済状態、参加状態の４つである。つまり、状態記憶部では、プレイ状態が、上記４つのプレイ状態のいずれかに設定される。プレイヤ端末１は、設定されているプレイ状態に基づいて、招待情報の受信に係る処理が実行される。

各プレイ状態には、状態記憶部に新たな招待情報の割り当ての可否が対応付けられている。プレイ状態が受け取り可能状態に設定されている状態記憶部がある場合、プレイヤ端末１は、サーバ１００から招待情報を受信し得る。つまり、プレイ状態のうち、受け取り可能状態は、新たな招待情報の割り当てが許可された許可状態と言える。

一方、プレイ状態が未開封状態、開封済状態、参加状態に設定されている状態記憶部には、招待情報が割り当てられることはない。つまり、プレイ状態のうち、未開封状態、開封済状態および参加状態は、招待情報の割り当てが不可能な不可能状態と言える。

したがって、３つの状態記憶部の全てにおいて、プレイ状態が未開封状態、開封済状態および参加状態のいずれかである場合、プレイヤ端末１は、招待情報の受信が不可能となる。一方で、３つの状態記憶部のうち、少なくとも１つの状態記憶部において、プレイ状態が受け取り可能状態である場合、プレイヤ端末１は、招待情報の受信が可能となる。

例えば、サーバ１００において、プレイヤが対象者に設定され、当該プレイヤに対する招待情報がサーバ１００にセットされたとする。このとき、プレイヤ端末１において、プレイ状態が受け取り可能状態に設定されている状態記憶部があれば、プレイヤ端末１がサーバ１００から招待情報を受信する。

一方で、招待情報がサーバ１００にセットされていても、全ての状態記憶部において、プレイ状態が未開封状態、開封済状態もしくは参加状態に設定されていれば、プレイヤ端末１はサーバ１００から招待情報を受信しない。換言すれば、プレイヤ端末１は、全ての状態記憶部においてプレイ状態が未開封状態、開封済状態および参加状態のいずれかに設定されている場合、招待情報の受信確認を実行しない。

なお、詳しい説明は省略するが、プレイ状態が許可状態であっても、セットされた招待情報によっては、プレイヤ端末１が招待情報を受信しないことがある。例えば、プレイヤが、操作部５４ｂの削除タブをタップして招待情報を削除したとする。換言すれば、プレイヤが、招待されたバトルゲームへの参加を拒否したとする。この場合、参加を拒否したバトルゲームと同一種別のバトルゲームへの参加を招待する招待情報については、削除情報を送信してから所定時間は受信しない。

このように、プレイヤが参加する可能性の低い招待情報を受信しないようにすることで、プレイヤに鬱陶しさを与えるおそれが低減される。以上のように、プレイ状態が許可状態である場合、原則的には、招待情報を受信可能であるが、招待情報の内容によっては、一部の招待情報の受信が制限されてもよい。

図１２Ａに示すように、上記の各プレイ状態には、それぞれ設定条件が設けられている。プレイヤ端末１は、設定条件の成立有無を判定し、その判定結果に基づいて、状態記憶部ごとにプレイ状態を設定する。

受け取り可能状態には、招待情報が記憶されていないこと、マルチプレイのルームに入室していないことが、設定条件として設けられている。

未開封状態には、招待情報が記憶されていること、および、招待情報画像５４が表示されておらず、招待情報が未開封であることが設定条件として設けられている。なお、招待情報には、有効時間が予め設定されている。招待情報を受信した後、有効時間が経過すると、プレイヤ端末１から招待情報が削除される。プレイ状態が未開封状態のまま、有効時間が経過すると、招待情報が削除され、プレイ状態が受け取り可能状態に更新される。

開封済状態には、招待情報が記憶されていること、および、招待情報画像５４が表示済みであることが、設定条件として設けられている。なお、開封済状態は、招待情報画像５４の表示中と、保留操作の入力後に招待情報画像５４が非表示となった状態とで設定される。保留操作とは、招待情報画像５４が表示された後に、操作部５４ｂの参加タブおよび削除タブが操作されずに、招待情報画像５４が非表示となる操作である。

なお、プレイ状態が未開封状態から開封済状態に更新された後であっても、参加タブおよび削除タブが操作されずに有効時間が経過した場合には、上記と同様に、招待情報が削除される。この場合、削除された招待情報が記憶されていた状態記憶部において、プレイ状態が開封済状態から受け取り可能状態に更新される。

参加状態には、マルチプレイのルームに入室中であることが設定条件として設けられている。

ここで、上記のプレイ状態は、状態記憶部ごとに更新されるが、参加状態は、３つの状態記憶部において共通で設定される。例えば、２つの招待情報を受信したものの、招待情報画像５４が表示されていない場合には、２つの状態記憶部においてプレイ状態が未開封状態となり、１つの状態記憶部においてプレイ状態が受け取り可能状態となる。

この状態で、報知態様の通知画像３４またはサムネイル画像５２ａがタップされると、２つの招待情報画像５４が表示され、２つの状態記憶部において、プレイ状態が開封済み状態に更新される。そして、いずれかの招待情報画像５４の操作部５４ｂに参加操作が入力され、マルチプレイのルームに入室したとする。この場合、３つの状態記憶部の全てにおいて、プレイ状態が参加状態に更新される。その後、マルチプレイが終了した場合には、３つの状態記憶部の全てにおいて、プレイ状態が受け取り可能状態に更新される。

このように、プレイ状態のうち、参加状態は、必ず、３つの状態記憶部の全てにおいて同時に設定される。一方で、３つの状態記憶部のプレイ状態が、参加状態でない場合には、３つの状態記憶部のプレイ状態が、受け取り可能状態、未開封状態、開封済状態のいずれかに設定されることとなる。

プレイヤ端末１は、少なくとも１つの状態記憶部のプレイ状態が許可状態に設定されている場合、すなわち、プレイ状態が受け取り可能状態に設定されている状態記憶部が１つでもある場合、サーバ１００に対して招待情報の受信確認を行う。このとき、自身に対する招待情報がセットされていれば、プレイヤ端末１が、セットされている招待情報を受信する。

そして、招待情報を受信した場合に、プレイ状態が受け取り可能状態に設定されている状態記憶部があれば、その状態記憶部が、受信した招待情報に割り当てられる。これにより、招待情報が割り当てられた状態記憶部は、プレイ状態が受け取り可能状態から未開封状態に更新される。

なお、３つの状態記憶部のうち、第１状態記憶部８２は、招待情報の割り当ての優先度が最も高く、第３状態記憶部８６は、招待情報の割り当ての優先度が最も低い。したがって、例えば、３つの状態記憶部において、プレイ状態が全て受け取り可能状態に設定されているときに招待情報を受信した場合には、第１状態記憶部８２に招待情報が割り当てられる。

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

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

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

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

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

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

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

また、プレイヤ端末１において、プレイ内容選択ページ（図４Ａ参照）からシングルプレイタブ４０ａがタップされ、シングルプレイの開始操作がなされたとする（Ｐ４）。この場合、プレイヤ端末１からサーバ１００に開始情報が送信される。なお、この開始情報には、プレイヤが選択したパーティ情報、バトルゲームの種別情報等が含まれる。サーバ１００では、開始情報の入力により、バトルゲームを開始するために必要となるバトルゲーム開始処理が行われる（Ｓ３）。

ここでは、例えば、バトルゲームを進行するためのメモリ１１２の領域を確保し、プレイヤ端末１から入力された情報を記憶したり、所定のプログラムを記憶部１１８からメモリ１１２に読み出したりする。また、サーバ１００は、プレイヤ端末１が、バトルゲームの実行に必要なデータを受信できるようにセットする。

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

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

また、更新処理では、プレイヤ端末１とサーバ１００との間で、更新情報の送受信が行われている。ここでは、更新処理および更新情報の送受信がフレーム単位で実行されるが、更新処理および更新情報の送受信は、フレーム単位よりも短い周期あるいは長い周期で行われてもよい。また、シングルプレイによるバトルゲーム中も、プレイヤ端末１における招待情報の受信確認（Ｐ７）、サーバ１００における招待情報の検索（Ｓ５）、プレイヤ端末１における招待情報の受信の報知（Ｐ８）が定期的に実行され得る。

そして、バトルゲームの終了条件が成立すると、プレイヤ端末１およびサーバ１００のそれぞれにおいて、バトルゲームを終了させる終了処理が行われる（Ｐ９、Ｓ６）。プレイヤ端末１の終了処理（Ｐ９）では、例えば、リザルト画面がディスプレイ２６に表示される。また、サーバ１００の終了処理（Ｓ６）では、例えば、バトルゲームで獲得したアイテム、プレイヤ経験値、キャラクタの経験値等、各種のプレイヤ情報が更新される。

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

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

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

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

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

対象者端末は、招待情報を受信すると、通知画像３４を報知態様で表示させるとともに、サムネイル画像５２ａを表示し、招待情報を受信した旨を報知する（ＧＰ１１）。また、対象者端末は、受信した招待情報に割り当てる状態記憶部を決定して、招待情報を記憶する。また、このとき、招待情報を記憶した状態記憶部のプレイ状態を未開封状態に更新する（ＧＰ１２）。その後、対象者が通知画像３４またはサムネイル画像５２ａをタップすると、対象者端末は、招待情報画像５４を表示する（ＧＰ１３）。また、招待情報画像５４が表示されると、サーバ１００に開封情報が送信される。サーバ１００は、開封情報を受信すると、ポイント更新処理を行う。ここでは、対象者の優先ポイントが「１」加算される。また、対象者端末では、招待情報が割り当てられた状態記憶部のプレイ状態が開封済状態に更新される（ＧＰ１４）。

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

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

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

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

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

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

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

対象者端末は、参加不可能情報を受信すると、入室不可画面をディスプレイ２６に表示するとともに、参加操作がなされた招待情報画像５４を非表示にする（ＧＰ２２）。また、対象者端末は、参加操作がなされた招待情報を削除するとともに、招待情報が削除された状態記憶部のプレイ状態を受け取り可能状態に更新する（ＧＰ２３）。

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

サーバ１００は、削除情報を受信すると、削除情報を送信した対象者端末の受信状況（状況フラグ）を更新する（Ｓ１７）。ここでは、招待情報の受信数が減算されるとともに、状況フラグが、例えば、「受信１」からブランクに更新されたり、「受信３」から「受信２」に更新されたりする。

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

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

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

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

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

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

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

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

つまり、ゲーム実行部６０ａおよびバトルゲーム実行部６２ａは、プレイ中のゲーム画面を表示する表示制御部として機能する。

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

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

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

つまり、招待情報受信部６８ａは、複数種別の招待ゲームのいずれかへの参加を招待する招待情報を外部装置から複数受信し得る受信部として機能する。

報知部７０ａは、招待情報を受信した場合に、報知態様の通知画像３４、および、サムネイル画像５２ａを表示する。また、報知部７０ａは、第１状態記憶部８２、第２状態記憶部８４、第３状態記憶部８６における招待情報の記憶有無、すなわち、招待情報を受信しているか否かに基づいて、通知画像３４を報知態様または非報知態様に切り替える。

つまり、報知部７０ａは、受信した招待情報に対応する報知画像としてのサムネイル画像５２ａを、プレイ中のゲーム画面の表示を維持した状態で表示する。また、報知部７０ａは、複数の招待情報を受信した場合に、招待情報ごとにサムネイル画像５２ａを表示する報知部として機能する。

招待情報画像表示部７２ａは、報知態様の通知画像３４またはサムネイル画像５２ａがタップされた場合に、招待情報画像５４を表示する。

つまり、招待情報画像表示部７２ａは、報知画像としてのサムネイル画像５２ａを選択するプレイヤの操作が入力された場合に、サムネイル画像５２ａに対応する招待ゲームに関するゲーム情報、および、招待ゲームへの参加操作を受け付ける操作部を少なくとも含む所定画像を表示する所定画像表示部として機能する。

処理部７４ａは、招待情報画像５４における操作部５４ｂの参加タブに対して参加操作が入力された場合に、招待ゲームに参加するための処理を実行する処理部として機能する。また、処理部７４ａは、招待情報画像５４における操作部５４ｂの削除タブに対して削除操作が入力された場合に、招待情報を削除し、削除情報をサーバ１００に送信する。

計時部７６ａは、招待情報の有効時間、および、削除操作が入力されてからの経過時間、画面が遷移してからの時間等を計時する。

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

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

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

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

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

また、第１状態記憶部８２、第２状態記憶部８４、第３状態記憶部８６のいずれかにおいて、プレイ状態が未開封状態または開封済状態である場合（Ｐ１２０－５のＹＥＳ）、計時部７６ａは、招待情報の有効時間を計時する有効時間カウンタのカウンタ値をデクリメントする（Ｐ１２０－６）。

なお、プレイ状態が未開封状態または開封済状態の状態記憶部が複数ある場合には、複数の状態記憶部に対して、Ｐ１２０－６からＰ１２０－８の処理が実行される。したがって、有効時間カウンタは、状態記憶部ごとに設けられている。有効時間カウンタのカウンタ値が０に更新された場合（Ｐ１２０－７のＹＥＳ）、プレイ状態更新部６６ａは、この有効時間カウンタに対応する状態記憶部において、招待情報を削除し、プレイ状態を受け取り可能状態に更新する（Ｐ１２０－８）。

また、図示は省略するが、Ｐ１２０－８においてプレイ状態が受け取り可能状態に更新されるまで、全ての状態記憶部において、プレイ状態が受け取り可能状態ではなかった場合には、上記と同様に、ディスプレイ２６に表示中の画面に基づいて、初期カウンタ値が決定され、受信待機カウンタにセットされる。

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

図２１は、プレイヤ端末１における招待情報確認処理の一例を説明するフローチャートである。招待情報受信部６８ａは、受信確認情報をサーバ１００に送信する（Ｐ１２１－１）。招待情報受信部６８ａは、受信可能（未受信）な招待情報がサーバ１００にセットされている場合（Ｐ１２１－２のＹＥＳ）、サーバ１００にセットされている招待情報を受信し、受信した招待情報を、第１状態記憶部８２、第２状態記憶部８４、第３状態記憶部８６のいずれかに記憶する（Ｐ１２１－３）。

なお、削除操作が入力されてから所定時間が経過していない場合、招待情報受信部６８ａは、削除された招待情報と同一種別のバトルゲームに係る招待情報を受信しない。したがって、この場合、招待情報受信部６８ａは、受信可能な招待情報がないものとして処理を行う。

ただし、招待情報受信部６８ａは、全ての招待情報を受信したうえで、削除操作が入力されてから所定時間が経過していない場合に、受信した招待情報が、削除された招待情報と同一種別であるかを判定してもよい。このとき、受信した招待情報が、削除された招待情報と同一種別であれば、招待情報を記憶せずに破棄してもよい。

また、プレイ状態更新部６６ａは、招待情報を記憶した状態記憶部のプレイ状態を未開封状態に更新する（Ｐ１２１－４）。また、計時部７６ａは、有効時間カウンタに所定値をセットする（Ｐ１２１－５）。また、報知部７０ａは、通知画像３４を報知態様で表示するとともに、サムネイル画像５２ａを表示する報知処理を実行する（Ｐ１２１－５）。なお、ここでは、計時部７６ａが、サムネイル画像５２ａの表示時間をタイマにセットする。詳しい説明は省略するが、ここでセットされたタイマは毎フレーム、デクリメントされ、タイマが０になると、サムネイル画像５２ａが非表示となる。

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

また、招待情報が記憶されており、招待情報画像５４が表示されている状態で、参加タブがタップされて参加操作が入力されると（Ｐ１３０－１のＹＥＳ、Ｐ１３０－２のＮＯ、Ｐ１３０－７のＹＥＳ、Ｐ１３０－８のＹＥＳ）、処理部７４ａは、サーバ１００に参加情報を送信する（Ｐ１３０－９）。

その後、処理部７４ａは、ルーム更新情報または参加不可能情報を受信するまで待機する（Ｐ１３０－１０）。そして、サーバ１００からルーム更新情報を受信した場合（Ｐ１３０－１１のＹＥＳ）、プレイ状態更新部６６ａが、プレイ状態を参加状態に更新する（Ｐ１３０－１２）。また、処理部７４ａは、ディスプレイ２６にルーム詳細ページを表示する（Ｐ１３０－１３）。また、ここでは、報知部７０ａが、通知画像３４を非表示態様に切り替え、招待情報画像表示部７２ａが、招待情報画像５４を非表示とする。

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

また、招待情報が記憶されており、招待情報画像５４が表示されている状態で、削除タブがタップされて削除操作が入力されると（Ｐ１３０－１のＹＥＳ、Ｐ１３０－２のＮＯ、Ｐ１３０－７のＹＥＳ、Ｐ１３０－８のＮＯ、図２３のＰ１３０－１８のＹＥＳ）、処理部７４ａは、状態記憶部から招待情報を削除し（Ｐ１３０－１９）、プレイ状態更新部６６ａが、プレイ状態を受け取り可能状態に更新する（Ｐ１３０－２０）。また、処理部７４ａは、サーバ１００に削除情報を送信する（Ｐ１３０－２１）。

また、招待情報画像表示部７２ａは、削除された招待情報に対応する招待情報画像５４の表示を終了する（Ｐ１３０－２２）。また、処理部７４ａは、削除操作が入力されてからの経過時間を計時する削除カウンタに所定時間をセットする（Ｐ１３０－２３）。なお、ここでセットされた削除カウンタのカウンタ値は、０になるまで、毎フレーム、デクリメントされる。この削除カウンタのカウンタ値が０でない場合には、上記のＰ１２１－２において、受信可能な招待情報が、削除された招待情報と同一種別であるかが判定される。

また、招待情報が記憶されており、招待情報画像５４が表示されている状態で、保留操作が入力されると（Ｐ１３０－１のＹＥＳ、Ｐ１３０－２のＮＯ、Ｐ１３０－７のＹＥＳ、Ｐ１３０－８のＮＯ、Ｐ１３０－１８のＮＯ、Ｐ１３０－２８のＹＥＳ）、招待情報画像表示部７２ａは、招待情報画像５４の表示を終了する（Ｐ１３０－２９）。

図２４は、プレイヤ端末１におけるマルチプレイ終了処理の一例を説明するフローチャートである。マルチプレイが終了すると（Ｐ１４０－１のＹＥＳ）、バトルゲーム実行部６２ａは、ディスプレイ２６にリザルト画面を表示する（Ｐ１４０－２）。このとき、ゲストプレイヤとしてマルチプレイに参加した場合（Ｐ１４０－３のＹＥＳ）、招待情報受信部６８ａは、全ての状態記憶部から招待情報を消去する（Ｐ１４０－４）。また、プレイ状態更新部６６ａは、全ての状態記憶部において、プレイ状態を受け取り可能状態に更新する（Ｐ１４０－５）。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上記実施形態で説明した技術的事項は、あらゆるゲーム分野に適用可能である。したがって、例えば、サムネイル画像５２ａおよび招待情報画像５４が表示されるゲーム画面の表示内容は特に限定されない。

また、上記実施形態では、マルチプレイのバトルゲームについて、参加の招待がなされる場合について説明した。つまり、上記実施形態の招待ゲームは、複数のプレイヤそれぞれのプレイヤ端末１が通信接続されて実行される。しかしながら、参加の招待がなされる招待ゲームの内容は特に限定されるものではない。例えば、招待ゲームは、招待されたプレイヤが一人でクエストに挑戦する内容であってもよい。

また、上記実施形態では、外部装置としてサーバ１００が設けられ、複数のプレイヤ端末１は、外部装置であるサーバ１００を介して、マルチプレイを実行可能である。しかしながら、外部装置はサーバ１００に限らない。例えば、プレイヤ端末１が、サーバ１００の上記の機能を備えており、いずれかのプレイヤ端末１が、外部装置として機能してもよい。

また、上記実施形態では、報知画像としてサムネイル画像５２ａが表示されることとした。ただし、報知画像の表示態様はこれに限らない。受信した招待情報に対応し、招待ゲームに関するゲーム情報の一部を識別可能な報知画像が、プレイ中のゲーム画面の表示を維持した状態で表示されればよい。また、報知画像は、複数の招待情報を受信した場合に、招待情報ごとに表示されればよい。

また、上記実施形態では、サムネイル画像５２ａがタップされた場合に、全ての招待情報に対応する招待情報画像５４が表示されることとした。しかしながら、例えば、タップされたサムネイル画像５２ａに対応する招待情報画像５４のみが表示されてもよい。また、上記実施形態では、報知画像を選択する操作が入力された場合に表示される所定画像の一例として、招待情報画像５４について説明した。ただし、所定画像は、報知画像を選択するプレイヤの操作が入力された場合に、報知画像よりも詳細なゲーム情報、および、招待ゲームへの参加操作を受け付ける操作部を少なくとも含み、プレイ中のゲーム画面の表示を維持した状態で表示されればよく、具体的な表示内容は限定されない。

また、上記実施形態では、招待情報画像５４の表示時に、ディスプレイ２６の全体が暗くなった状態で、中断時のバトル画面が停止表示される。ただし、招待情報画像５４が表示されるときのゲーム画面の表示状態はこれに限らない。例えば、招待情報画像５４が表示されるときのゲーム画面は、ゲーム進行中、または、操作タブ４２がタップされた際の一時停止状態と同じでもよい。いずれにしても、招待情報画像５４は、プレイ中のゲーム画面を識別可能な状態で表示されればよい。

また、上記実施形態では、操作部５４ｂの参加タブがタップされた場合に、処理部７４ａが、参加情報を送信する等、招待ゲームに参加するために必要な処理を実行することとした。ただし、参加操作が入力された場合に実行する処理はこれに限らない。例えば、処理部７４ａは、参加情報を送信する前に、招待ゲームに参加するためのキャラクタやパーティを選択するための画面を表示させてもよい。

また、上記実施形態では、参加操作の入力、削除操作の入力、および、保留操作に基づいて、招待情報画像５４が非表示となることとした。ただし、招待情報画像５４を非表示とする操作はこれに限らない。いずれにしても、参加操作を少なくとも含む所定操作の入力に基づいて、招待情報画像５４が非表示となればよい。

また、上記実施形態において、状態記憶部に記憶されている招待情報と、バトルゲームの種別が同一の招待情報については、受信しないとしてもよい。つまり、プレイヤ端末１は、複数の招待情報を保持することができるが、同時に保持することができる招待情報は、招待ゲームの種別が互いに異なるものに限られてもよい。また、プレイヤ端末１において、同時に保持することができる招待情報は、招待ゲームの種別が互いに異なるものに限るとした場合、招待情報は全て受信したうえで、サムネイル画像５２ａおよび招待情報画像５４を非表示としてもよい。

このように、同時に保持することができる招待情報は、招待ゲームの種別が互いに異なるものに限られる場合、複数の報知画像それぞれに対応する招待ゲームは、互いに種別が異なるものとなる。

また、上記実施形態において、例えば、招待ゲームの種別が同一の招待情報を複数保持している場合には、これら複数の招待情報のうち、いずれか１つの招待情報に対応するサムネイル画像５２ａのみが表示されてもよい。このようにすれば、複数の報知画像が表示される場合、複数の報知画像それぞれに対応する招待ゲームは、互いに種別が異なるものとなる。これにより、同一種別の招待ゲームばかりが表示されることがなくなり、プレイヤの選択の幅を広げることが可能となる。

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

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

１ プレイヤ端末
５２ａ サムネイル画像
５４ 招待情報画像
５４ａ ゲーム情報表示部
５４ｂ 操作部
６０ａ ゲーム実行部
６２ａ バトルゲーム実行部
６８ａ 招待情報受信部
７０ａ 報知部
７２ａ 招待情報画像表示部
７４ａ 処理部
１００ サーバ

Claims (9)

1. プレイ中のゲーム画面を表示する表示制御部と、
   複数種別の招待ゲームのいずれかへの参加を招待する招待情報を外部装置から複数受信し得る受信部と、
   受信した前記招待情報に対応し、前記招待ゲームに関するゲーム情報の一部を識別可能な報知画像を、プレイ中の前記ゲーム画面の表示を維持した状態で表示し、複数の前記招待情報を受信した場合に、前記招待情報ごとに前記報知画像を表示する報知部と、
   前記報知画像を選択するプレイヤの操作が入力された場合に、前記報知画像よりも詳細な前記ゲーム情報、および、該招待ゲームへの参加操作を受け付ける操作部を少なくとも含む所定画像を、プレイ中の前記ゲーム画面を識別可能な状態で表示する所定画像表示部と、
   前記操作部に対して前記参加操作が入力された場合に、前記招待ゲームに参加するための処理を実行する処理部と、
   してコンピュータを機能させ、
   前記報知部は、
   前記報知画像の表示開始から所定時間が経過すると、前記報知画像を非表示とし、
   前記招待情報を受信した後、新たな前記招待情報を受信した場合、新たに受信した前記招待情報に対応する前記報知画像に加えて、相対的に先に受信した前記招待情報に対応する前記報知画像を表示する、
   情報処理プログラム。
2. プレイ中のゲーム画面を表示する表示制御部と、
   複数種別の招待ゲームのいずれかへの参加を招待する招待情報を外部装置から複数受信し得る受信部と、
   受信した前記招待情報を上限数の範囲内で保持する保持部と、
   受信した前記招待情報に対応し、前記招待ゲームに関するゲーム情報の一部を識別可能な報知画像を、プレイ中の前記ゲーム画面の表示を維持した状態で表示し、複数の前記招待情報を受信した場合に、前記招待情報ごとに前記報知画像を表示する報知部と、
   前記報知画像を選択するプレイヤの操作が入力された場合に、前記報知画像よりも詳細な前記ゲーム情報と、該招待ゲームへの参加操作および保持している前記招待情報の削除操作を受け付ける操作部とを少なくとも含む所定画像を、プレイ中の前記ゲーム画面を識別可能な状態で表示する所定画像表示部と、
   前記操作部に対して前記参加操作が入力された場合に、前記招待ゲームに参加するための処理を実行する処理部と、
   前記操作部に対して前記削除操作が入力された場合に、前記削除操作が入力された前記操作部を含む前記所定画像に対応する前記招待情報を削除する削除部と、
   してコンピュータを機能させる、
   情報処理プログラム。
3. 前記所定画像表示部は、
   前記参加操作を少なくとも含む所定操作の入力に基づいて、前記所定画像を非表示とする、
   請求項１または２に記載の情報処理プログラム。
4. 前記招待ゲームは、複数のプレイヤそれぞれのプレイヤ端末が通信接続されて実行され、
   前記ゲーム情報には、前記招待ゲームの種別、および、参加するプレイヤに関する情報の少なくともいずれかが含まれる、
   請求項１から３のいずれか１項に記載の情報処理プログラム。
5. 複数の前記報知画像が表示される場合、複数の前記報知画像それぞれに対応する前記招待ゲームは、互いに種別が異なる、
   請求項１から４のいずれか１項に記載の情報処理プログラム。
6. プレイ中のゲーム画面を表示するステップと、
   複数種別の招待ゲームのいずれかへの参加を招待する招待情報を外部装置から複数受信し得るステップと、
   受信した前記招待情報に対応し、前記招待ゲームに関するゲーム情報の一部を識別可能な報知画像を、プレイ中の前記ゲーム画面の表示を維持した状態で表示し、複数の前記招待情報を受信した場合に、前記招待情報ごとに前記報知画像を表示するステップと、
   前記報知画像を選択するプレイヤの操作が入力された場合に、前記報知画像よりも詳細な前記ゲーム情報、および、該招待ゲームへの参加操作を受け付ける操作部を少なくとも含む所定画像を、プレイ中の前記ゲーム画面を識別可能な状態で表示するステップと、
   前記操作部に対して前記参加操作が入力された場合に、前記招待ゲームに参加するための処理を実行するステップと、
   を含み、
   前記報知画像を表示するステップでは、
   前記報知画像の表示開始から所定時間が経過すると、前記報知画像を非表示とし、
   前記招待情報を受信した後、新たな前記招待情報を受信した場合、新たに受信した前記招待情報に対応する前記報知画像に加えて、相対的に先に受信した前記招待情報に対応する前記報知画像を表示する、
   情報処理方法。
7. プレイ中のゲーム画面を表示するステップと、
   複数種別の招待ゲームのいずれかへの参加を招待する招待情報を外部装置から複数受信し得るステップと、
   受信した前記招待情報を上限数の範囲内で保持するステップと、
   受信した前記招待情報に対応し、前記招待ゲームに関するゲーム情報の一部を識別可能な報知画像を、プレイ中の前記ゲーム画面の表示を維持した状態で表示し、複数の前記招待情報を受信した場合に、前記招待情報ごとに前記報知画像を表示するステップと、
   前記報知画像を選択するプレイヤの操作が入力された場合に、前記報知画像よりも詳細な前記ゲーム情報と、該招待ゲームへの参加操作および保持している前記招待情報の削除操作を受け付ける操作部とを少なくとも含む所定画像を、プレイ中の前記ゲーム画面を識別可能な状態で表示するステップと、
   前記操作部に対して前記参加操作が入力された場合に、前記招待ゲームに参加するための処理を実行するステップと、
   前記操作部に対して前記削除操作が入力された場合に、前記削除操作が入力された前記操作部を含む前記所定画像に対応する前記招待情報を削除するステップと、
   を含む情報処理方法。
8. プレイヤ端末と外部装置とが通信接続される情報処理システムであって、
   前記プレイヤ端末は、
   プレイ中のゲーム画面を表示する表示制御部と、
   複数種別の招待ゲームのいずれかへの参加を招待する招待情報を前記外部装置から複数受信し得る受信部と、
   受信した前記招待情報に対応し、前記招待ゲームに関するゲーム情報の一部を識別可能な報知画像を、プレイ中の前記ゲーム画面の表示を維持した状態で表示し、複数の前記招待情報を受信した場合に、前記招待情報ごとに前記報知画像を表示する報知部と、
   前記報知画像を選択するプレイヤの操作が入力された場合に、前記報知画像よりも詳細な前記ゲーム情報、および、該招待ゲームへの参加操作を受け付ける操作部を少なくとも含む所定画像を、プレイ中の前記ゲーム画面を識別可能な状態で表示する所定画像表示部と、
   前記操作部に対して前記参加操作が入力された場合に、前記招待ゲームに参加するための処理を実行する処理部と、
   を備え、
   前記報知部は、
   前記報知画像の表示開始から所定時間が経過すると、前記報知画像を非表示とし、
   前記招待情報を受信した後、新たな前記招待情報を受信した場合、新たに受信した前記招待情報に対応する前記報知画像に加えて、相対的に先に受信した前記招待情報に対応する前記報知画像を表示する、
   情報処理システム。
9. プレイヤ端末と外部装置とが通信接続される情報処理システムであって、
   前記プレイヤ端末は、
   プレイ中のゲーム画面を表示する表示制御部と、
   複数種別の招待ゲームのいずれかへの参加を招待する招待情報を外部装置から複数受信し得る受信部と、
   受信した前記招待情報を上限数の範囲内で保持する保持部と、
   受信した前記招待情報に対応し、前記招待ゲームに関するゲーム情報の一部を識別可能な報知画像を、プレイ中の前記ゲーム画面の表示を維持した状態で表示し、複数の前記招待情報を受信した場合に、前記招待情報ごとに前記報知画像を表示する報知部と、
   前記報知画像を選択するプレイヤの操作が入力された場合に、前記報知画像よりも詳細な前記ゲーム情報と、該招待ゲームへの参加操作および保持している前記招待情報の削除操作を受け付ける操作部とを少なくとも含む所定画像を、プレイ中の前記ゲーム画面を識別可能な状態で表示する所定画像表示部と、
   前記操作部に対して前記参加操作が入力された場合に、前記招待ゲームに参加するための処理を実行する処理部と、
   前記操作部に対して前記削除操作が入力された場合に、前記削除操作が入力された前記操作部を含む前記所定画像に対応する前記招待情報を削除する削除部と、
   を備える情報処理システム。

Images