JP5979401B1 - プログラム及び情報処理装置 - Google Patents

Abstract

【課題】ユーザ数の拡大を阻害せずにユーザに対して好適にプレイ機会を与えることのできるプログラム及び情報処理装置を提供する。【解決手段】第１のユーザが少なくとも含まれるグループを構成するためのグループ作成要求を第１の端末から受信する処理、第１の端末と所定の端末間関係を満たす第２の端末に対して、第２のユーザがグループに参加することを可能とするグループ情報１２２０を送信する第１の送信処理、第１のユーザと第３の端末を操作する第３のユーザとが所定のユーザ間関係を満たしている場合に、第３の端末に、第３のユーザがグループに参加することを可能とするグループ情報１２２０を送信する第２の送信処理、第２の端末と第３の端末の少なくとも一方からグループへの参加要求を受信した場合に、参加要求を送信した端末に係るユーザと第１のユーザとを含むグループを構成する処理、を実行させる。【選択図】図６

Description

本発明に係るいくつかの態様は、プログラム及び情報処理装置に関する。

近年、例えばいわゆるスマートフォンやタブレット型端末等の携帯型端末にインストールされたゲームアプリケーション（以下、アプリケーションをアプリとも呼ぶ。）をユーザが操作し、当該ゲームアプリがサーバと適宜通信することによりゲームが進行するオンラインゲームを提供するゲームシステムが広く知られている。このようなゲームの中には、複数のユーザが協力或いは対戦するものもある。この場合、同時にプレイするユーザをマッチングする必要があるが、このユーザのマッチングの際に、携帯型端末から取得する位置情報を利用することも考えられる（例えば、特許文献１参照）。マッチングの際に位置情報を用いることにより、マッチング可能な相手を近くのユーザに限定すると、ゲームをプレイしたいユーザは近くにいる友人を誘わざるを得ない。これにより、ゲームサービスの提供者側は、当該ゲームのユーザ数の拡大を図ることができる。

特許第５５８４８６１号

しかしながら、このように位置情報に基づくマッチングのみを行う場合には、従前よりゲームをプレイしているユーザにとっては、マッチングされるユーザ数が限定され、結果としてプレイする機会が限定されるという課題がある。

本発明のいくつかの態様は前述の課題に鑑みてなされたものであり、ユーザ数の拡大を阻害せずにユーザに対して好適にプレイ機会を与えることのできるプログラム及び情報処理装置を提供することを目的とする。

本発明に係るプログラムは、第１の端末を操作する第１のユーザが少なくとも含まれるグループを構成するためのグループ作成要求を前記第１の端末から受信する処理と、前記グループ作成要求を受信した後、前記第１の端末と所定の端末間関係を満たす第２の端末に対して、当該第２の端末を操作する第２のユーザが前記グループに参加することを可能とするグループ情報を送信する第１の送信処理と、前記第１のユーザと第３の端末を操作する第３のユーザとが予め登録された所定のユーザ間関係を満たしている場合に、前記グループ作成要求を受信した後、前記第３のユーザが操作する前記第３の端末に、前記第３のユーザが前記グループに参加することを可能とするグループ情報を送信する第２の送信処理と、前記第２の端末と前記第３の端末の少なくとも一方から前記グループへの参加要求を受信した場合に、当該参加要求を送信した端末に係るユーザと前記第１のユーザとを含む前記グループを構成する処理と、前記グループとしてプレイするゲームを制御する処理とを情報処理装置に実行させるためのプログラムである。

なお、本発明において、「部」や「手段」、「装置」、「システム」とは、単に物理的手段を意味するものではなく、その「部」や「手段」、「装置」、「システム」が有する機能をソフトウェアによって実現する場合も含む。また、１つの「部」や「手段」、「装置」、「システム」が有する機能が２つ以上の物理的手段や装置により実現されても、２つ以上の「部」や「手段」、「装置」、「システム」の機能が１つの物理的手段や装置により実現されても良い。

本発明によれば、ユーザ数の拡大を阻害せずにユーザに対して好適にプレイ機会を与えることのできるプログラム及び情報処理装置を提供することができる。

実施形態に係る情報処理装置であるゲーム制御サーバを含むゲームシステムの構成例を示す図である。 実施形態に係るゲームシステムにおいて表示される表示画面の具体例を示す図である。 実施形態に係るゲームシステムにおいて表示される表示画面の具体例を示す図である。 実施形態に係るゲームシステムにおいて表示される表示画面の具体例を示す図である。 実施形態に係るゲームシステムにおいて表示される表示画面の具体例を示す図である。 実施形態に係るゲーム制御サーバの機能構成の具体例を示す図である。 実施形態に係るゲーム制御サーバが管理するユーザ情報の具体例を示す図である。 実施形態に係るゲームシステムにおいて表示される表示画面の具体例を示す図である。 実施形態に係るゲーム制御サーバが管理するグループ情報の具体例を示す図である。 実施形態に係るゲーム制御サーバの処理の流れの具体例を示すフローチャートである。 実施形態に係るゲーム制御サーバの処理の流れの具体例を示すフローチャートである。 実施形態に係るゲーム制御サーバの処理の流れの具体例を示すフローチャートである。 実施形態に係るゲーム制御サーバの処理の流れの具体例を示すフローチャートである。 実施形態に係るゲーム制御サーバのハードウェア構成の具体例を示す図である。

以下、図面を参照して本発明の実施形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。即ち、本発明は、その趣旨を逸脱しない範囲で種々変形して実施することができる。また、以下の図面の記載において、同一または類似の部分には同一または類似の符号を付して表している。図面は模式的なものであり、必ずしも実際の寸法や比率等とは一致しない。図面相互間においても互いの寸法の関係や比率が異なる部分が含まれていることがある。

図１乃至図１４は、実施形態を説明するための図である。以下、これらの図を参照しながら、以下の流れに沿って実施形態を説明する。まず、「１」で実施形態に係るゲームシステムの概要を説明する。続いて「２」で情報処理装置であるゲーム制御サーバの機能構成を説明し、「３」でゲーム制御サーバの処理の流れを説明する。「４」では、ゲーム制御サーバを実装可能なハードウェア構成の具体例を説明する。最後に、「５」以降で、本実施形態に係る効果などを説明する。

（１． 概要）
（１．１． ゲームシステムの概要）
まず、図１を参照しながら、実施形態に係るゲームシステム１の構成及び処理の概要を説明する。ゲームシステム１は、例えばゲーム運営会社により管理されるゲーム制御サーバ（情報処理装置）１０と、課金サーバ２０と、各ユーザの携帯型端末３０Ａ、３０Ｂ乃至３０Ｎ（以下、総称して携帯型端末３０とも呼ぶ。）とを含む。ゲーム制御サーバ１０と、課金サーバ２０と、携帯型端末３０とは、それぞれネットワークＮを介して有線又は無線により、相互に通信可能である。本ゲームシステム１において、ユーザは携帯型端末３０にインストールされたゲームアプリケーション（以下、アプリケーションをアプリとも呼ぶ。）を用いて、オンラインゲームをプレイすることができる。ゲーム制御サーバ１０は、携帯型端末３０と逐次通信することにより、当該携帯型端末３０にインストールされたゲームアプリのゲームの進行を逐次制御する。

ゲーム制御サーバ１０は、先述の通り、携帯型端末３０との間でコマンドを通信することにより、当該携帯型端末３０にインストールされたゲームアプリ上でのゲームの進行を制御する。また、ゲーム制御サーバ１０はゲームの実行及び進行に必要な各種データを管理すると共に、それらのデータを携帯型端末３０に配信可能である。

課金サーバ２０は、携帯型端末３０又はゲーム制御サーバ１０からの要求に応じて、ゲーム内での課金処理を行うサーバである。課金によりユーザは、例えばゲーム内で提供される何らかのアイテムを取得するための抽選（以下、「ガチャ」とも呼ぶ。）を引いたり、或いはゲームを進行する際に必要となるパラメータ（以下、「スタミナ」とも呼ぶ。）を回復させたりするための媒体（アイテム）を取得することが可能となる。

携帯型端末３０は、先述の通りゲームアプリがインストールされており、当該ゲームアプリを実行することにより、ユーザはゲームをプレイすることができる。ゲームアプリが実行されると、携帯型端末３０はネットワークＮを介してゲーム制御サーバ１０や課金サーバ２０に接続し、オンラインゲームサービスをユーザに提供することが可能となる。携帯型端末３０は、例えばいわゆるスマートフォンと呼ばれる携帯電話や、タブレット型端末、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、パーソナルコンピュータ、ゲーム機等により実現することができる。

ネットワークＮは、先述の通りゲーム制御サーバ１０、課金サーバ２０、及び携帯型端末３０を相互に通信可能に接続する。ネットワークＮは、例えばインターネット等により実現することができ、内部に無線ＬＡＮのアクセスポイントや携帯電話の基地局等を含むことができる。

（１．２． オンラインゲームの概要）
ここで、ゲームシステム１において提供されるオンラインゲームは、例えば、複数のユーザ間で戦ったり、或いは複数のユーザが協力して敵と戦ったりする対戦型ゲームであることが考えられる。ここでは、ゲームシステム１が提供するオンラインゲームが、複数のユーザが協力して、コンピュータが制御する敵と戦うことのできるゲームである場合を中心に説明する。

複数のユーザで協力して敵と戦う場合には、一緒にプレイするユーザのマッチングを図る必要がある。例えば４人のキャラクタにより、いわゆるクエストと呼ばれるミニゲームにおいてコンピュータが制御する敵と戦う場合には、最大４名のユーザをマッチングし、グループを作る必要がある。ここでは、ホストとなるユーザがクエストをプレイするためのグループ（以下、「ルーム」とも呼ぶ。）を作り、ゲストとなる他のユーザが当該グループに加入することによりマッチングを図る場合を例に説明する。

なお、以下の説明では、４人のキャラクタが協力して、コンピュータが制御する敵と戦うことができる場合を中心に説明する。しかしながらオンラインゲームの形態はこれに限られるものではなく、３人以下又は５人以上のキャラクタが協力して戦うことができるようにしても良い。また、各ユーザがコンピュータにより制御される敵に対して協力して戦わずとも、各ユーザが操作するプレイヤキャラクタ間で戦えるようにしても良い。

（１．２．１． クエスト表示画面２００）
図２に、ホストとなるユーザの携帯型端末３０のディスプレイに表示される画面の具体例を示す。図２は、ホストとなるユーザがクエストでプレイする際に表示されるクエスト表示画面２００の具体例を示す図である。

図２のクエスト表示画面２００は、ユーザ情報表示領域２１０と、クエスト情報表示領域２２０とを含む。ユーザ情報表示領域２１０には、当該ゲーム中におけるユーザの各種情報が示される。図２の例では、ユーザがゲーム中で使用するプレイヤ名情報２１１、レベル情報２１３、ゲーム中での経験値に関する経験値情報２１５、及びプレイヤがミニゲームを使用する際に消費するスタミナに関するスタミナ情報２１７等が、ユーザ情報表示領域２１０に提示されている。

プレイヤ名情報２１１は、オンラインゲーム中で各ユーザを識別するためにユーザ自身がつけるプレイヤ名であり、ユーザが設定した任意の文字列（図２の例では「ユーザＸ」）により構成される。オンラインゲームでプレイする各ユーザは、例えば後述のグループマッチング等の際に、当該プレイヤ名情報２１１により、他のユーザを識別することができる。

レベル情報２１３は、ゲーム内でのユーザのランクを示す。例えば、経験値情報２１５で示されるゲーム内の経験値が増加し、各レベル毎に設定された一定の閾値に達するとユーザのレベルが上昇する。

経験値情報２１５は、ユーザのゲーム内での経験値、及び次のレベルに達するために必要な閾値となる経験値であり、図２の例では、経験値が「＊＊／＊＊＊」という「／」で区切られた数値の表記、及び割合を示す棒グラフとして示される。例えば、ユーザが当該オンラインゲームにおいてミニゲームであるクエストをクリアすると、それに応じてユーザに対して所定の経験値が付与される。前述のとおり、経験値情報２１５で示される経験値が所定の閾値に達すると、レベル情報２１３で示されるユーザのレベルが上昇する。

スタミナ情報２１７は、ユーザがクエストでプレイする際に消費するパラメータであるスタミナに関する情報である。より具体的には、スタミナ情報２１７では、ユーザが現在保有するスタミナ、及びユーザが通常時に最大有することのできるスタミナの上限値の情報が「＊＊／＊＊」という「／」で区切られた数値の表記、及び割合を示す棒グラフとして示される。スタミナは、例えば一定時間ごとに１ずつ回復するように構成され、ユーザのレベルに応じた上限値までスタミナを溜めることが可能である。オンラインゲーム内のミニゲームである各クエストには、プレイする際に必要となる消費スタミナ値が設定されている。図２の画面例では、消費クエスト情報２２１において、消費スタミナ値が「５」であることが示されている。ユーザは、スタミナ情報２１７で示される保有スタミナ値が、クエストに設定された消費スタミナ値以上でない限り、当該クエストでプレイすることはできない。つまり、ユーザは、クエストを連続して無制限にプレイできないようになっている。

クエスト情報表示領域２２０は、ユーザがプレイするために選択したクエストの詳細を示すための領域である。図２の例では、クエスト情報表示領域２２０には、クエストの名称（「＊＊＊＊＊＊＊＊」）、クエストの難易度、クエストをプレイする際に必要な消費クエスト情報２２１、出現モンスターの情報、ユーザがクリアした回数（「０」）、ユーザがクリアしたタイムの最小値、及びユーザのフレンドとして登録されている他のユーザがクリアしたタイムの最小値等の情報が示される。

更に、クエスト情報表示領域２２０には、ソロプレイボタン２２３と、マルチプレイボタン２２５とがそれぞれ選択可能に表示されている。ユーザがソロプレイボタン２２３を選択すると、ユーザはクエスト表示画面２００に紐付けられるクエストを、ユーザ１人でプレイすることができる。その際には、例えばユーザがゲーム内で保有するメインキャラクタ１体及びサブキャラクタ２体で構成されるユーザの３体のキャラクタと、当該ユーザが助っ人として選択した他のユーザのメインキャラクタのパラメータが設定されたキャラクタ１体の計４体のキャラクタから構成されるパーティにより、ユーザはクエストをプレイすることができる。

一方、マルチプレイボタン２２５を選択するとユーザは他のユーザとグループ（ルーム）を構成し、自身のキャラクタ及び他のユーザが操作するキャラクタを含む４体のキャラクタにより、クエストでプレイすることができる。その際、ユーザ間でグループを構成するためのマッチングを行う必要がある。そこで、図３に示すルーム表示画面３００が表示される。

なお前述のとおり、ユーザはクエストをソロプレイ又はマルチプレイのいずれによってもプレイすることが可能であるが、マルチプレイによりプレイした方が、ユーザはクリア後に高い報酬（例えばゲーム内金銭（ゴールド）、経験値、獲得アイテム等を報酬に含むことができる）を獲得することができる。これは、ユーザにとっては、ソロプレイよりもマルチプレイでプレイする動機付けとなるため、当該オンラインゲームを運営するゲーム運営会社にとってはユーザ数の拡大を図ることが可能となる。

（１．２．２． ルーム表示画面３００）
本実施形態において、グループ（ルーム）は最大４名のユーザにより構成される。グループにゲストとして参加することのできるユーザは、原則としてホストとしてグループを構成しようとしているユーザの位置の近くにいるユーザに限られる。具体的には、ゲーム制御サーバ１０は、たとえばユーザが操作する携帯型端末３０からＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）等による位置情報を取得した上で、当該位置から一定範囲以内にあるという端末間関係をもつ携帯型端末３０を操作するユーザを「ユーザの位置の近くにいるユーザ」と判定する。その上でゲーム制御サーバ１０は、そのユーザをマッチング中のグループに加入（参加）可能とすることができる。このようにグループにゲストとして参加可能なユーザを、ホストとなるユーザの近くにいるユーザのみに限定することにより、顔見知り以外とマルチプレイをすることは困難になるため、マルチプレイによりクエストをプレイしたいユーザは、近くにいる友人を誘わざるを得ない状況となる。この結果、オンラインゲームの提供者側には、ユーザ数の拡大を図ることができるメリットが生まれる。

しかしながら、このように位置情報に応じた端末間の関係に基づくマッチングのみを行う場合には、従前よりゲームをプレイしているユーザにとっては、マッチングされるユーザ数が限定され、結果としてプレイする機会が限定されてしまうという課題がある。例えば、ユーザが過疎地域に旅行すると、周辺に同じゲームをプレイしているユーザや誘うことのできる友人がおらず、結果としてゲームでプレイすることができないという状況になる。

そこで本実施形態に係るゲームシステム１では、位置情報によるマッチングに加え、ユーザが実世界において実際に交流があるとして登録されているユーザ（以下、「リアフレ」（リアルフレンドの略）とも呼ぶ。）については、位置に関わらずマッチング対象とする。これにより、例えばユーザが１人旅行などして周囲に友人がいないような状況となったとしても、リアフレとして登録されているユーザと、マルチプレイを楽しむことができる。また、「フレンド」についてはユーザと実世界において直接交流がなくとも登録可能であるところ、本実施形態のように遠距離マッチングの対象をリアフレとして登録されているユーザに限定することで、ゲーム運営会社は位置情報による限定したマッチングシステムを通じたユーザ数の拡大を図ることができる。

なお、本実施形態におけるゲームシステム１では、上述の通り、マッチング可能なユーザを、各ユーザが操作する携帯型端末３０の距離が一定範囲内にあるという端末間関係を持つユーザと、例えば「リアフレ」として登録したユーザ間関係を持つユーザとに限定している。ここで、マッチングの際に利用可能な端末間の関係は、例えば、２台の携帯型端末３０間の相対的な位置関係であって、それが判別可能なものであれば良い。従って、例えば近距離無線通信等による端末間の通信等により互いの端末が近くにいることが判別できるか否かも、端末間の関係ということができる。

また、マッチングの際に利用可能なユーザ間の関係は、例えば、前述のようにユーザが「フレンド」や「リアフレ」として登録した等、ゲーム制御サーバ１０側で判別可能なユーザ間の関係性である。よって、例えば、ユーザが明示的に登録した関係性でなくとも、頻繁に一緒にプレイしている場合等も、両ユーザ間に何らかの関係性があると判別することも考えられる。

先述の通り、クエストをプレイする際には、クエスト毎に定められた値のスタミナを消費する。よって、マルチプレイによりクエストをプレイする際には、どのユーザのスタミナをどのように消費させるかが問題となる。本実施形態では、クエストをプレイした際に、当該クエストに対して定められた数値のスタミナをホストユーザが保有するスタミナから消費させる場合を中心に説明する。換言すると、ゲストとしてグループに参加してクエストをプレイしたユーザのスタミナは消費させない。

以下、図２のクエスト表示画面２００においてユーザがマルチプレイボタン２２５を選択した場合に表示されるルーム表示画面３００の具体例を図３を参照しながら説明する。図３は、ルームと呼ばれるグループを構成する際に表示されるルーム表示画面３００の具体例を示す図である。ルーム表示画面３００は、ユーザ情報表示領域２１０、参加プレイヤ情報表示領域３１０Ａ乃至３１０Ｄ（以下、総称して参加プレイヤ情報表示領域３１０とも呼ぶ。）と、取消ボタン３２０、及びクエスト開始ボタン３３０を含む。
ユーザ情報表示領域２１０については図２に示したクエスト表示画面２００に含まれていたものと同様である。

参加プレイヤ情報表示領域３１０は、当該グループ（ルーム）への参加状況を示すための領域である。ルーム表示画面３００の例では、ホストとしてグループを構成しようとしている「ユーザＸ」のプレイヤキャラクタとなるメインキャラクタに関する情報が参加プレイヤ情報表示領域３１０Ａに示されている。より具体的には、参加プレイヤ情報表示領域３１０Ａには、「ユーザＸ」の使用するキャラクタの画像、レベル、各種パラメータ（総合力／ＨＰ／攻撃力）、使用する武器の属性（図３の例ではハンマーが図示されている）等が示されている。

前述のとおり、本実施形態におけるオンラインゲームのマルチプレイでは、最大４名のユーザによりクエストをプレイすることができる。ルーム表示画面３００の例では、参加プレイヤ情報表示領域３１０Ｂ乃至３１０Ｄは「参加受付中」となっており、「マッチングは近くにいる人又はリアフレとのみおこないます」と記載されている。つまり、このグループには、ホストである「ユーザＸ」以外にはまだ誰も参加していない。また、当該グループには、ホストである「ユーザＸ」の近傍にいるユーザ、又は当該「ユーザＸ」と「リアフレ」として登録されているユーザが参加可能である。もし参加可能な他のユーザがゲストとして当該グループに参加した場合には、当該他のユーザのプレイヤキャラクタとなるメインキャラクタの情報が順次参加プレイヤ情報表示領域３１０Ｂ乃至３１０Ｄに表示される。

当該「ユーザＸ」がホストとなるグループに他のユーザが参加する際に、当該他のユーザの携帯型端末３０のディスプレイ上に表示される表示画面については、図４を参照しながら後述する。

取消ボタン３２０は、ユーザが当該グループによるマルチプレイを行わない場合に選択されるユーザインタフェースである。もしグループのホストであるユーザ（図３の例では「ユーザＸ」）が取消ボタン３２０を選択すると、当該グループは解散となる。すなわち、既にグループにゲストとして参加していた他のユーザについても、そのグループへの加入状態が解除される。

また、もしグループのゲストであるユーザが取消ボタン３２０を選択すると、他のユーザのグループへの参加が維持されたまま、そのユーザのみがグループのメンバから外れる。すなわちルーム表示画面３００上から、当該取消ボタン３２０を押したユーザのキャラクタが表示されなくなる。

クエスト開始ボタン３３０は、当該グループに参加しているメンバでホストであるユーザがクエストを開始する際に選択されるユーザインタフェースである。本実施形態において、各クエストは４人のキャラクタでプレイすることになっているため、例えば２名のユーザ（ホスト及びゲスト１名ずつ）しかグループに参加していない状態でホストであるユーザがクエスト開始ボタン３３０を選択した際には、ホストであるユーザの有するメインキャラクタ１体及びサブキャラクタ１体、及びゲストであるユーザの有するメインキャラクタ１体及びサブキャラクタ１体でクエストをプレイすることになる。また、３名のユーザ（ホスト及びゲスト１名ずつ）しかグループに参加していない状態でホストであるユーザがクエスト開始ボタン３３０を選択した際には、ホストであるユーザの有するメインキャラクタ１体及びサブキャラクタ１体、及びゲストである２名のユーザがそれぞれ有するメインキャラクタ１体ずつでクエストをプレイすることになる。もし４人のユーザがグループに参加した状態でホストであるユーザがクエスト開始ボタン３３０を選択した際には、全ユーザ４名の有するメインキャラクタ１体ずつで構成される４体のキャラクタでクエストをプレイする。

なお、マルチプレイは複数のユーザで構成されるグループ（ルーム）によりプレイするモードであるため、１名以上のゲストとなるユーザがグループに参加していない場合には、クエスト開始ボタン３３０は選択不可状態となる。ホストであるユーザを含む２名以上のユーザがグループに参加すると、クエスト開始ボタン３３０は選択可能なアクティブ状態となる。

（１．２．３． ルーム選択画面４００）
続いて、図４を参照しながら、ホストであるユーザが構成しようとするグループ（ルーム）に、他のユーザがゲストとして参加したい場合に表示される、グループ選択のための表示画面の具体例を図４を参照しながら説明する。図４は、ユーザがグループに参加する際に表示されるルーム選択画面４００の具体例を示す図である。ルーム選択画面４００は、ユーザ情報表示領域２１０、ルーム情報表示領域４１０Ａ乃至４１０Ｃ（以下、総称してルーム情報表示領域４１０と呼ぶ。）、及びスクロールバー４２０を含む。

ユーザ情報表示領域２１０については、対象とするユーザに違いはあるものの、内容は図２に示したクエスト表示画面２００及び図３に示したルーム表示画面３００に含まれていたものと同様である。図４の例では、プレイヤ名情報２１１に示されるユーザのプレイヤ名は「プレイヤＰ」であり、レベル情報２１３に示される当該ユーザのレベルは「Ｌｖ１０」である。

各ルーム情報表示領域４１０は、ホストとなるユーザが構成しようとするグループの情報をそれぞれ選択可能に示している。ユーザがルーム選択画面４００において複数あるルーム情報表示領域４１０の中の１を選択すると、選択されたルーム情報表示領域４１０に対応するグループに当該ユーザが操作するプレイヤキャラクタがゲストとして参加することになる。その際に当該ユーザの操作する携帯型端末３０のディスプレイには、新たに参加したユーザを参加プレイヤ情報表示領域３１０に含む形で、図３に示したルーム表示画面３００と同様の構成を持つ表示画面が表示される。
ルーム情報表示領域４１０は、ホスト情報表示領域４１１と、クエスト情報４１５と、ステータス情報４１７とを含む。

ホスト情報表示領域４１１は、グループ（ルーム）をホストとして構成しようとしているユーザの情報を示している。ホスト情報表示領域４１１には、ホストとなるユーザのプレイヤキャラクタの画像、プレイヤ名、パラメータ（図４の例ではレベル及び総合力）等が含まれる。更に、ルーム情報表示領域４１０には、ユーザと、ホスト情報表示領域４１１に示されるホストユーザとのユーザ間の関係を示すようにしても良い。ルーム情報表示領域４１０Ａ及び４１０Ｂの例では、ユーザと、ホスト情報表示領域４１１に示されるホストユーザとの関係が「リアフレ」であることが、ユーザ関係情報４１３として示されている。本実施形態において、各ユーザ間の関係としては「リアフレ」の他「フレンド」もあり得るため、ユーザ関係情報４１３には「フレンド」である旨を表示しても良い。これによりユーザは、「リアフレ」又は「フレンド」であるユーザがホストとなっているグループを識別及び選択しやすくなる。なお、本実施形態においては、前述のとおりマルチプレイをプレイする際にグループとしてマッチング可能なユーザは、位置的に近傍にいるユーザ又はリアルフレンドとして登録されているユーザに限られる。よって、もしユーザ関係情報４１３に「フレンド」の表記がなされた場合には、当該「フレンド」として表記されているホストユーザは、ゲストとして参加しようとしているユーザの近くにいることを意味する。

なお、図４に示すようにルーム選択画面４００においては、複数のルーム情報表示領域４１０がリスト上に表示される。ここで、例えば「リアフレ」として登録されたユーザがホストとなっているグループや「フレンド」として登録されたユーザがホストとなっているグループに係るルーム情報表示領域４１０を上部に表示するようにしても良い。これにより、「リアフレ」や「フレンド」として登録した他のユーザのグループを検索しやすくなる。

クエスト情報４１５は、各グループがプレイしようとしているクエストの情報を示す。例えば、クエストの名称（ルーム情報表示領域４１０Ａの例では「＊＊＊＊＊＊＊＊」）、及び難易度（ルーム情報表示領域４１０Ａの例では「初級」）等をクエスト情報４１５に含むことができる。

ステータス情報４１７は、当該グループへのメンバの参加状況を示す。ルーム情報表示領域４１０Ａの例では、４名参加可能なグループに対し、現時点で１名しか参加していないことを示している。

スクロールバー４２０は、ルーム選択画面４００上に示されるルーム情報表示領域４１０のリスト中の、ルーム選択画面４００に表示される領域をスムーズに移動させるためにユーザが操作可能なユーザインタフェースである。ユーザがスクロールバー４２０を操作することにより、当該ユーザはリストに含まれる多数のルーム情報表示領域４１０を確認し、それらの中から希望するルーム情報表示領域４１０を選択することが可能となる。

（１．２．４． クエスト結果表示画面５００）
本実施形態におけるオンラインゲームのように、マッチングされた複数のユーザにより、オンラインゲーム中のクエストをプレイ（マルチプレイ）するものがある（例えば、非特許文献である＜株式会社セガホールディングス、“［公式］モンスターギア｜モンギア(SEGA)”、［ｏｎｌｉｎｅ］、［平成２７年６月１２日検索］、インターネット〈ＵＲＬ：https://monstergear.sega-net.com/〉＞参照）。非特許文献で示されるオンラインゲームでは、クエストをプレイする際に必要となるパラメータ（スタミナ）を、マッチングにより形成されたグループを構成する複数のユーザのうち１のユーザのみから消費させ、他のユーザのスタミナを消費させないようにすることにより、ユーザがマルチプレイによりプレイする動機付けとしている。

ここで、オンラインゲーム中のミニゲームであるクエストを、ユーザが何度も繰返しプレイしたい（周回したい）と考える場合がある。例えば、クエストをクリアすることで一定の確率で所定の報酬を得られる場合に、その報酬を得られるまでそのクエストを繰り返す場合や、クエストをクリアすると高い報酬が得られるために、その報酬をできるだけたくさん得る目的でクエストを繰り返す場合等である。

ここで、非特許文献で示されるオンラインゲームでは、マルチプレイによりクエストをプレイすると、グループを解散するようになっている。よって、マルチプレイによりクエストをプレイしたユーザが、同じメンバで同じクエストを連続的にプレイしたいと考える場合であっても、例えばホストとなるユーザが再度グループを構成し、ゲストとなるユーザがそのグループを検索し、ゲストとなるユーザがそのグループに参加した上でクエストをチャレンジしなければならない。すなわち、マルチプレイによりクエストを再チャレンジする操作が煩雑であった。

そこで本実施形態においては、マルチプレイによるクエストの再チャレンジに係る煩雑性を抑制することのできるプログラム及び情報処理装置を提供する。以下、この点について詳細に説明する。

「１．２．３．」までで説明してきたような流れでグループを構成した複数のユーザによりクエストをプレイし、当該クエストが終了すると、図５に具体例を示すクエスト結果表示画面５００が表示される。図５は、マルチプレイによるクエストプレイ後に表示されるクエスト結果表示画面５００の具体例を示す図である。クエスト結果表示画面５００は、クエスト結果表示領域５１０、再チャレンジボタン５２０、及び終了ボタン５３０を含む。

クエスト結果表示領域５１０には、ユーザがクエストをプレイした結果を示す情報が示される。図５の例では、クエスト結果表示領域５１０には、プレイしたクエストの名称（「＊＊＊＊＊＊＊＊」）、ユーザがクリアに要した時間、当該ユーザのフレンドとして登録されている他のユーザが同じクエストをクリアするのに要した時間のベストタイム、ユーザがクエストクリアにより獲得したゲーム内のパラメータ及びアイテム（ゴールド、経験値、装備、素材）等の情報が含まれる。

再チャレンジボタン５２０は、現在グループを構成する同じメンバで同じクエストのマルチプレイを希望する場合にユーザが選択するユーザインタフェースである。また、終了ボタン５３０は、現在グループを構成する同じメンバでの同じクエストのマルチプレイを希望しない場合にユーザが選択するユーザインタフェースである。

もし、現在グループを構成する全ユーザが再チャレンジボタン５２０を選択した場合には、全く同じメンバ構成の周回用（再チャレンジ用）のグループが再構成される。これにより、ユーザの操作する携帯型端末３０のディスプレイ上では、図３に具体例を示したルーム表示画面３００の表示に遷移し（但し、当該全ユーザの情報が、それぞれ参加プレイヤ情報表示領域３１０に表示される）、全く同じメンバでの再チャレンジが可能となる。

また、もしホストであるユーザを含む一部のユーザが再チャレンジボタン５２０を選択し、他のゲストであるユーザが終了ボタン５３０を選択した場合には、再チャレンジボタン５２０を選択したユーザのみでグループを構成するルーム表示画面３００が、それらのユーザの携帯型端末３０のディスプレイ上に表示される。すなわち、再チャレンジボタン５２０を選択したユーザのみが参加するグループで、再度同じクエストをプレイすることが可能となる。なお、当該グループには、新たに参加する他のユーザを加える事も考えられる。
一方、ホストであるユーザが終了ボタン５３０を選択した場合には、他のユーザも含めてグループを解散すれば良い。

しかしながら、これに限られるものではなく、ホストであるユーザが終了ボタン５３０を押した場合には、従来ゲストとしてグループに参加していたいずれかのユーザをホストとして、従来ゲストであったユーザのみで新たに同じクエストをプレイするためのグループを構成しても良い。また、ホストであるかゲストであるかに関わらず、いずれかのユーザが終了ボタン５３０を選択した段階で、当該ルームメンバからなるグループを解散することも考えられる。もしくは、再チャレンジボタン５２０を押したユーザの中で、ホストとなるユーザを順に入れ替えていくことも考えられる。

このような構成とすることにより、マルチプレイによりクエストを周回したいとユーザが考える場合には、グループを再構成するための操作を行うことなく（例えば図２や図４に具体例を示したクエスト表示画面２００やルーム選択画面４００を再度ユーザの携帯型端末３０に表示させることなく）、クエストをプレイすることができる。つまり、マルチプレイによるクエストの再チャレンジに係る煩雑性を抑制することが可能である。

また先述の通り、本実施形態においては、クエストをマルチプレイによりプレイする際には、当該クエストに割り当てられた分の消費スタミナを、グループ内の１名（例えばホスト）のユーザの保有するスタミナから消費させる。ここで、同じメンバでクエストを周回する際に、スタミナを消費させるユーザを決定するステップを入れても良い。スタミナを消費させるユーザの決定方法としては複数考えられるが、例えば、クエストをプレイする度に、まずはホストとなるユーザのスタミナを消費させ、ホストとなるユーザのスタミナがクエストをプレイする際に必要な消費スタミナを下回った場合には、グループに参加している他のユーザからスタミナを消費させるユーザを決定することが考えられる。また、最も保有スタミナ数の多いユーザからスタミナを消費させても良い。或いは、全ユーザの有するスタミナを平均的に消費させたり、クエストに挑戦する際にスタミナを消費させるユーザをユーザ側に選択させたりすることも考えられる。このように実装することで、最大、全ユーザの保有するスタミナの合計値を、クエストを１回プレイするのに必要な消費スタミナの数値で除算した回数まで、同じメンバでクエストを周回することが可能となる。

或いは、前述のとおり、ユーザがレベルアップした際にはスタミナは全回復するため、クエストをクリアするとレベルアップすると考えられるユーザを特定した上で、当該ユーザの保有スタミナを消費させることも考えられる。

（２． 機能構成）
以下、図６を参照しながら、本実施形態に係るゲーム制御サーバ１０の機能構成を説明する。図６は、ゲーム制御サーバ１０の機能構成の具体例を示す機能ブロック図である。ゲーム制御サーバ１０は、通信部１１００と、データベース（ＤＢ）１２００と、ユーザ情報管理部１３００と、グループ管理部１４００と、クエスト制御部１５００とを含む。

通信部１１００は、例えばユーザの操作する携帯型端末３０や課金サーバ２０等とネットワークＮを介して通信する。例えば、ルームと呼ばれるグループを形成するためにホストとなるユーザによる作成要求や、当該グループへのゲストとなるユーザによる参加要求などは、通信部１１００が携帯型端末３０から受信する。また、ゲストとなるユーザが参加可能なグループに関する情報などは、通信部１１００が携帯型端末３０へ送信する。
ＤＢ１２００は、ユーザ情報１２１０、グループ情報１２２０、及びクエスト情報１２３０を含む各種情報を管理する。

ユーザ情報１２１０は、ゲーム制御サーバ１０が提供するオンラインゲームの各ユーザに係る情報である。図７に、ユーザ情報１２１０の具体例を示す。図７の例では、各行はそれぞれ１人のユーザに対応する。各ユーザ情報１２１０には、ユーザＩＤ、ユーザ名、レベルやスタミナ等の各種パラメータ、ユーザがフレンドやリアルフレンド等として登録しているユーザ関係情報等が含まれる。

ユーザＩＤは、各ユーザを識別するためにゲーム制御サーバ１０側で各ユーザに割り当てる識別子である。図７の例では「ｕｓｅｒ００１」「ｕｓｅｒ００２」等の識別子が欠くユーザに割り当てられている。

ユーザ名は、各ユーザが自身でつけることのできるオンラインゲーム中で使用する名前であり、任意の文字列により構成される。図７の例では、「ユーザＸ」「プレイヤＰ」等の文字列がユーザ名として登録されている。

レベルやスタミナ等の各種パラメータは、ユーザがオンラインゲーム中でのステータス等を示す値である。例えばレベルは、ゲーム内でクエスト等をクリアすることにより割り当てられる経験値が、各レベル毎に割り当てられた閾値を上回ると上昇する値である。

スタミナは、ユーザがクエストをプレイする際に消費するパラメータである。ユーザがクエストをプレイする際には、当該クエストに対して予め設定された消費スタミナ分、ユーザが保有するスタミナから消費される。これによりユーザは、クエストを無制限に連続してプレイすることはできない。スタミナは、例えば一定時間ごとに所定数分が増加する等、時間経過に応じて回復する他、レベル上昇時にはスタミナが全回復するようになっている。またユーザは、課金等の手段により入手できる媒体を消費することによりスタミナを回復させることもできる。本実施形態において、マルチプレイにおいては、ルームと呼ばれるグループを構成する複数のユーザのうち１人分のユーザのスタミナのみが減少するようになっている。よって、マルチプレイによれば、ソロプレイの時よりもクエストをプレイできる回数が増える。これによりユーザがマルチプレイによりプレイする動機付けとすることができる。

ユーザ関係情報は、各ユーザが「フレンド」や「リアルフレンド」として登録したユーザ間の情報を示す。図７の例では、「フレンド」や「リアルフレンド」として登録されたユーザの識別子が、それぞれ「フレンド」「リアルフレンド」の項目で管理されている。以下、「フレンド」及び「リアルフレンド」について説明する。なお、本実施形態においては、「フレンド」や「リアルフレンド」として登録したユーザの情報としてユーザＩＤを用いているがこの限りではない。例えば、ユーザが使用する端末ＩＤ、ゲーム内で同一な名称の使用を禁止する場合におけるユーザ名など、ユーザに対して一意に割り当てられたものをユーザの識別子に用いることができる。

例えばユーザがソロプレイによりクエストをプレイする際には、当該ユーザの保有するキャラクタ３体に加え、他のユーザのパラメータを利用したキャラクタ１体を「助っ人」として選択可能である。ユーザは、助っ人と共にクエストをプレイすると、そのクリア後に、当該助っ人として選択した他のユーザに対し、「フレンド」となる申請を送ることができる。当該他のユーザが当該申請を承認すれば、当該２人のユーザは互いに「フレンド」であるものとして登録される。つまり、「フレンド」については実世界における関係の有無に関わらず登録可能であり、「フレンド」になるためには位置情報を使用することなく登録することができる。「フレンド」として登録していると、ユーザがソロプレイによりクエストに挑戦する際に、助っ人として選択可能なユーザのリストで上位になる。すなわちユーザは、強いパラメータを有する他のユーザを「フレンド」として登録しておけば、当該ユーザを「助っ人」に選びやすくなるというメリットが有る。更に、ユーザが「フレンド」として登録している他のユーザと共にクエストをプレイした場合には、クエストのクリアに伴い、通常時よりも高い報酬を得ることができる。

「リアルフレンド」は、実世界において交流があるものとしてユーザに登録された他のユーザに係る情報である。リアルフレンドとしての登録方法の具体例を、以下図８を参照しながら説明する。

リアルフレンドとしてお互いに登録したい２人のユーザは、携帯型端末３０を操作し、図８に具体例を示すリアルフレンド登録画面８００をディスプレイに表示させる。リアルフレンド登録画面８００には、ユーザ情報表示領域２１０に加え、タップ領域８１０が表示される。タップ領域８１０には「『リアルフレンド』になりたいお友達と同時に画面をタップ！」という、２人のユーザの同時操作を促す文章が示されている。リアルフレンドとしてお互いに登録したい両ユーザは、当該リアルフレンド登録画面８００において、タップ領域８１０を同時にタップする。またこれと併せて携帯型端末３０のゲームアプリは、現在位置情報をＧＰＳから取得する。ゲームアプリは、ユーザにタップ領域８１０がタップされると、現在時刻情報及び現在位置情報を含む、リアルフレンド登録要求をゲーム制御サーバ１０へと送信する。ゲーム制御サーバ１０は、当該リアルフレンド登録要求を受信すると、現在時刻情報で示される時刻が一定範囲内であり、かつ取得された現在位置情報で示される位置が一定範囲内にあるリアルフレンド登録要求のペアの有無を探す。その結果、時刻及び位置が近似するリアルフレンド登録要求が２つあれば、ゲーム制御サーバ１０は当該２つの携帯型端末３０に対し、リアルフレンドの登録可否を問い合わせる。これを受けて両ユーザの携帯型端末３０は、リアルフレンドとしての登録を承諾するか否かを確認するための「承諾」ボタンを配置した表示画面をディスプレイに表示する。その結果、両ユーザ双方の承諾を得られた場合にのみ、ゲーム制御サーバ１０は両ユーザのユーザ情報１２１０に両者がリアルフレンドであるとして登録する。

このように、本実施形態に係るゲームシステム１においては、近似する時刻に、互いに近い位置にある２つの携帯型端末に所定の操作が行われたことに応じて、それらの携帯型端末３０に係るユーザをリアルフレンドとして登録する。このような操作は、両ユーザが時間と場所を示し合わせて行わなければならないため、これらのユーザは実世界において交流があるものと考えられる。このような「リアルフレンド」の登録制度を設け、実世界におけるユーザの交流を促すことにより、本ゲームシステム１で提供されるオンラインゲームにおいては、ユーザ数の増加を図ることができる。

なお、図８のリアルフレンド登録画面８００の例ではタップ操作によりリアルフレンドの登録要求を行うようにしているがこれに限られるものではない。例えば所定のパターンのなぞり操作を行ったり、或いは携帯型端末３０を振ったりする等の操作により、携帯型端末３０はゲーム制御サーバ１０に対してリアルフレンドの登録要求を行うことも考えられる。また、位置情報を使って、所定の範囲内に位置する端末同士でマッチングして一緒にオンラインゲームをプレイした後に、申請・承認の過程を経てリアルフレンドを登録することも考えられる。

「リアルフレンド」として登録していると、ユーザがソロプレイによりクエストに挑戦する際に、「助っ人」として選択可能なユーザのリストで、他のユーザや「フレンド」として登録されているユーザよりも上位になる。更に、ユーザが「リアルフレンド」として登録している他のユーザと共にクエストをプレイした場合には、クエストのクリアに伴い、通常時や「フレンド」として登録されている場合よりも高い報酬を得ることができる。更に本実施形態においては、「リアルフレンド」として登録されているユーザについては、たとえプレイ時に両ユーザが近傍におらずとも、マルチプレイによりプレイすることが可能となる。

再び図６に戻り、ＤＢ１２００はグループ情報１２２０を管理する。当該グループ情報１２２０は、例えばホストとなるユーザがマルチプレイを選択した際に作成される各グループの情報である。図９にグループ情報１２２０の具体例を示す。図９の例では、各行はそれぞれ１つのグループ（ルーム）に対応する。ホストとなるユーザがマルチプレイを選択し、携帯型端末３０がゲーム制御サーバ１０に対してルーム作成要求を送信すると、ゲーム制御サーバ１０はゲーム制御サーバ１０は新たなグループ情報１２２０を作成する。また、各ユーザがグループによるマルチプレイによりクエストをクリアした際には、ゲーム制御サーバ１０は、当該グループを解散し、グループ情報１２２０を削除する。しかしながら、ユーザが例えば図５に示したクエスト結果表示画面５００において、ユーザが再チャレンジボタン５２０を選択した場合には、グループに参加していたユーザの内、再チャレンジボタン５２０を選択したユーザのみを含む新たなグループに係るグループ情報１２２０が作成される。

各グループ情報１２２０には、ルームＩＤ、ホストユーザ情報、及びゲストユーザ情報が含まれる。
ルームＩＤは各グループを識別するために割り当てられる識別子である。
ホストユーザ情報は、各グループのホストとなるユーザに関する情報である。ホストユーザ情報には、ユーザを識別するためのユーザＩＤやユーザ名のほか、レベルや総合力等の各種パラメータを含むことができる。また、ホストユーザ情報には、ホストの現在位置情報を含むことができる。

ここで、現在位置情報は、各ユーザが操作する携帯型端末３０から取得される位置である。例えば、ユーザがクエストをプレイする際にマルチプレイを選択すると、グループ作成要求が当該携帯型端末３０からゲーム制御サーバ１０へと送信される。その際、携帯型端末３０はＧＰＳにより現在位置情報を取得し、その情報をグループ作成要求と共に送信する。ゲーム制御サーバ１０は、当該現在位置情報を、グループ情報１２２０に登録する。他のユーザがマルチプレイへのゲストとして参加する際には、当該他のユーザが参加可能な参加可能グループ情報をゲーム制御サーバ１０は当該他のユーザに係る携帯型端末３０へ送信する。その際、ゲーム制御サーバ１０は、当該他のユーザの携帯型端末３０から位置情報を取得した上で、当該位置とグループ情報１２２０に含まれるホストユーザ情報の現在位置が一定距離内にあるか否か、すなわち両携帯型端末３０が一定範囲内という端末間関係を満たすか否かを判断する。またゲーム制御サーバ１０は、当該他のユーザとホストユーザ情報で登録されている各ホストユーザが、ユーザ情報１２１０においてリアルフレンドと登録されているか否かを確認する。その結果、当該他のユーザとリアルフレンドとして登録されているユーザがホストとなっているグループ、或いは一定距離内にあると判断されるユーザがホストとなっているグループを、当該他のユーザが参加可能なグループとして判定できる。これによりゲーム制御サーバ１０は、ユーザがマルチプレイによりプレイ可能な相手を、限定することが可能である。

再び図６に戻り、ＤＢ１２００はクエスト情報１２３０を管理する。クエスト情報１２３０は、ユーザがオンラインゲーム中でプレイすることのできるミニゲームであるクエストに係る情報である。クエスト情報１２３０には、例えばクエスト名、難易度、プレイする際にユーザが消費する消費スタミナ量、出現モンスター、クリアした際に得ることのできる報酬等の情報を含むことができる。

ユーザ情報管理部１３００は、ユーザ情報１２１０を管理する。ユーザ情報管理部１３００は、ユーザ情報登録部１３１０、スタミナ情報管理部１３２０、及びユーザ関係情報登録部１３３０を含む。

ユーザ情報登録部１３１０は、ユーザが新規に携帯型端末３０にゲームアプリをインストールし、当該ゲームアプリを起動した旨を携帯型端末３０から受信した場合に、ＤＢ１２００に当該ユーザに係るユーザ情報１２１０を作成する。その際、ユーザ情報登録部１３１０は当該ユーザに識別のためのユーザＩＤを割り当てるほか、携帯型端末３０から、任意の文字列からなるユーザ名等の情報を受信し、当該情報をユーザ情報１２１０に登録する。

スタミナ情報管理部１３２０は、ユーザ情報１２１０に含まれるスタミナの値を管理する。例えば、ユーザが携帯型端末３０においてゲームアプリを起動すると、当該ゲームアプリは前回のアプリ終了時刻の情報をゲーム制御サーバ１０へ送信する。当該通知をゲーム制御サーバ１０の通信部１１００が受信すると、スタミナ情報管理部１３２０は当該ユーザの直近のアプリ終了時からの経過時間を計算する。スタミナ情報管理部１３２０は、ユーザ情報１２１０にスタミナ情報として登録された直近のスタミナの値に、当該経過時間に応じたスタミナを加算する。更にスタミナ情報管理部１３２０は、当該更新後のスタミナ値に係るスタミナ情報を携帯型端末３０へ送信する。アプリ起動後においても、スタミナ情報管理部１３２０はアプリ起動後の経過時間に応じて、逐次ユーザ情報１２１０に含まれるスタミナ値を更新し、必要に応じて携帯型端末３０との間でスタミナ更新について通信する。

また、スタミナ情報管理部１３２０は、ユーザがクエストのプレイを開始した旨の通知をクエスト制御部１５００より受けると、当該クエストに応じた消費スタミナの値分だけ、ユーザが保有するスタミナの値を減算する。このとき、特にユーザがマルチプレイによりゲームを行う場合には、スタミナ情報管理部１３２０は、グループを構成する複数のユーザのうち、例えばホストユーザの保有スタミナ値だけを減算し、ゲストユーザの保有スタミナ値は維持することができる。

ユーザ関係情報登録部１３３０は、ユーザ情報１２１０に含まれるユーザ関係情報を登録／更新する。より具体的には、例えば、ユーザが他のユーザを「助っ人」として選択した上でソロプレイによりクエストをプレイする場合を考える。このとき、ユーザがソロプレイをクリアすると、当該助っ人である他のユーザを「フレンド」とする申請を送るか否かの表示画面が携帯型端末３０のディスプレイ上に表示される。ユーザが「フレンド」の申請を行う旨の操作を行うと、ユーザ関係情報登録部１３３０は、当該フレンド申請を当該他のユーザの携帯型端末３０に対して送信する。その後、当該他のユーザがフレンド申請を承認すれば、ユーザ関係情報登録部１３３０は、両ユーザ間の関係が「フレンド」だとしてユーザ情報１２１０に登録する。つまり、「フレンド」については実世界における関係の有無に関わらず登録可能である。

また、ユーザ関係情報登録部１３３０は、「リアルフレンド」についてもユーザ情報１２１０に登録可能である。前述のとおり、ユーザが図８に示したリアルフレンド登録画面８００を携帯型端末３０のディスプレイを表示させた状態でタップすると、携帯型端末３０は現在時刻情報及び現在位置情報を含むリアルフレンド登録要求をゲーム制御サーバ１０へと送信する。当該リアルフレンド登録要求を受信したユーザ関係情報登録部１３３０は、現在時刻情報で示される時刻差が一定範囲内であり、かつ取得された位置が一定範囲内であるリアルフレンド登録要求のペアの有無を判定する。その結果、時刻及び位置が近似するリアルフレンド登録要求のペアがあれば、ユーザ関係情報登録部１３３０は、当該２つの携帯型端末に係る両ユーザ間の関係が「リアルフレンド」がとしてユーザ情報１２１０に登録する。

グループ管理部１４００は、グループ情報１２２０を管理する。グループ管理部１４００は、新規グループ作成部１４１０、参加可能グループ抽出部１４２０、グループ解散部１４３０、周回グループ作成部１４４０、及びスタミナ消費ユーザ決定部１４５０を含む。

新規グループ作成部１４１０は、ＤＢ１２００に逐次グループ情報１２２０を登録する。前述のとおり、図２に具体例を示したクエスト表示画面２００において、ユーザがマルチプレイボタン２２５を選択すると、携帯型端末３０はゲーム制御サーバ１０にルーム作成要求を送信する。新規グループ作成部１４１０は、当該ルーム作成要求を受信すると、当該要求を送信した携帯型端末３０に係るユーザをホストとして含む新たなグループ（ルーム）に係るグループ情報１２２０をＤＢ１２００に登録する。また新規グループ作成部１４１０は、新しいグループ（ルーム）を形成した旨を携帯型端末３０へ通知し、携帯型端末３０は図３に具体例を示したルーム表示画面３００を表示する。

参加可能グループ抽出部１４２０は、ゲストとなるユーザの携帯型端末３０から、参加可能なグループの問い合わせを受信した際に、当該携帯型端末３０に係るユーザが参加可能なグループをグループ情報１２２０から抽出し、それらの情報を参加可能グループ情報として携帯型端末３０に送信する。より具体的には、ユーザがゲストとしてグループに参加しようとする際には、当該ユーザに係る携帯型端末３０は、ＧＰＳ等から取得可能な現在位置情報と共に、参加可能グループを問い合わせる要求をゲーム制御サーバ１０へと送信する。参加可能グループ抽出部１４２０は、当該要求を受けて、受信した当該携帯型端末３０に係る現在位置情報で示される位置から所定範囲内にあるホストユーザに係るグループのグループ情報１２２０を抽出する。また参加可能グループ抽出部１４２０は、当該携帯型端末３０に係るユーザと、リアルフレンドとして登録されたユーザがホストユーザとなっているグループのグループ情報１２２０も抽出する。参加可能グループ抽出部１４２０は、このようにして抽出されたグループに係るグループ情報１２２０のリストを携帯型端末３０に送信する。これを受けて、携帯型端末３０は図４に具体例を示したルーム選択画面４００をディスプレイに表示する。
グループ解散部１４３０は、クエストをプレイし終わったグループに係るグループ情報１２２０をＤＢ１２００から削除する。

周回グループ作成部１４４０は、図５に示したクエスト結果表示画面５００において、ユーザが再チャレンジボタン５２０を押した際に、周回用の新たな新規ルーム（グループ）を形成する。例えば周回グループ作成部１４４０は、グループを構成していた各ユーザがクエスト結果表示画面５００において再チャレンジボタン５２０を選択したか終了ボタン５３０を選択したかに係るプレイ継続情報を受信し、再チャレンジボタン５２０を選択したユーザにより構成される周回用の新たな新規グループを形成すると共に、グループ解散部１４３０にグループを解散させる。これにより、例えば４人のグループを構築し、全ユーザが再チャレンジボタン５２０を選択すると、ユーザの携帯型端末３０のディスプレイ上では、グループの解散／再結成の操作を行うことなく、新たな周回用のグループを形成することが可能となる。このとき、例えばホストであったユーザが再チャレンジボタン５２０を選択せず、終了ボタン５３０を選択した場合には、周回グループ作成部１４４０は新たなグループを構築せずに、グループ解散部１４３０に元のグループを解散させても良い。

スタミナ消費ユーザ決定部１４５０は、周回グループ作成部１４４０が周回用の新たなグループを作成した際に、当該グループでクエストをプレイする際に必要となるスタミナを消費させるユーザを決定する。例えば、スタミナ消費ユーザ決定部１４５０は、ホストであるユーザからスタミナを消費させ、ホストであるユーザのスタミナが無くなった場合に他のユーザのスタミナを消費させるようにしても良い。或いは、スタミナ消費ユーザ決定部１４５０は、グループを構成する各ユーザのスタミナを順番に消費させるようにしても良いし、最も多くスタミナを保有するユーザからスタミナを消費させるようにしても良い。若しくは、グループを構成する各ユーザのスタミナを、例えば同数ずつ消費させるようにすることも考えられる。或いは、グループを構成する各ユーザの内、スタミナを消費させるユーザを、グループを構成するユーザに選択させるようにしても良い。

クエスト制御部１５００は、ユーザによるクエストプレイを制御する。クエスト制御部１５００は、クエスト開始制御部１５１０、及び報酬付与部１５２０を含む。

クエスト開始制御部１５１０は、例えば図２に具体例を示したクエスト表示画面２００においてユーザがソロプレイボタン２２３を選択し、助っ人となる他のユーザを選択すると、新たなクエストを開始させる。またクエスト開始制御部１５１０は、クエスト表示画面２００においてユーザがマルチプレイボタン２２５を選択し、ルーム表示画面３００においてクエスト開始ボタン３３０を選択すると、新たなクエストを開始させる。このとき、クエスト開始制御部１５１０はユーザ情報管理部１３００に、新たなクエストを開始した旨を伝える。当該通知を受けたスタミナ情報管理部１３２０は、当該クエストに対して割り当てられた消費スタミナの値だけ、ユーザ情報１２１０に格納されるスタミナを減らす。このとき、特にマルチプレイにおいては、スタミナ情報管理部１３２０は、スタミナ消費ユーザ決定部１４５０により決定されたユーザについて、スタミナの値を更新する。

報酬付与部１５２０は、クエスト終了時に、各ユーザに対して報酬を付与する。例えばユーザがクエストを成功裏にクリアした際には、報酬付与部１５２０はクリアしたユーザに、経験値やゴールド、アイテム（例えば装備や進化用の素材等を含む）等を付与することができる。このとき、例えばユーザがマルチプレイによりクエストをプレイしており、更にマルチプレイを戦ったグループにフレンド又はリアルフレンドが含まれている場合には、報酬付与部１５２０は、報酬を通常時よりも高く設定することができる。

（３． 処理の流れ）
以下、ゲーム制御サーバ１０の処理の流れを、図１０乃至図１３を参照しながら説明する。図１０乃至図１３は、本実施形態に係るゲーム制御サーバ１０の処理の流れを示すフローチャートである。

なお、後述の各処理ステップは、処理内容に矛盾を生じない範囲で、任意に順番を変更して若しくは並列に実行することができ、また、各処理ステップ間に他のステップを追加しても良い。更に、便宜上１つのステップとして記載されているステップは複数のステップに分けて実行することもでき、便宜上複数に分けて記載されているステップを１ステップとして実行することもできる。

（３．１． リアルフレンド登録処理）
まず、リアルフレンド登録に係る処理を図１０を参照しながら説明する。図１０は、ユーザ情報１２１０に、リアルフレンドとしてユーザ関係情報を登録する際の処理の流れを示すフローチャートである。

携帯型端末３０は、リアルフレンド登録画面８００においてユーザが所定の操作を行うと、携帯型端末３０の現在位置情報及び現在時刻情報を含むリアルフレンド登録要求をゲーム制御サーバ１０へと送信する。

ゲーム制御サーバ１０のユーザ関係情報登録部１３３０はリアルフレンド登録要求を携帯型端末３０から受信すると（Ｓ１００１のＹＥＳ）、当該リアルフレンド登録要求に含まれる現在位置情報及び現在時刻情報を抽出する（Ｓ１００３）。

続いてユーザ関係情報登録部１３３０は、他の携帯型端末３０から受信しているリアルフレンド登録要求を検索し、それらのリアルフレンド登録要求の中に、位置情報で示される位置及び時刻情報で示される時刻が近似するものがあるか否かを確認する（Ｓ１００５）。もし、位置情報で示される位置の間の距離が一定の閾値以下であり、且つリアルフレンド登録要求が送信された時刻の差異が一定閾値以下であるリアルフレンド登録要求のペアがあれば（Ｓ１００５のＹＥＳ）、ユーザ関係情報登録部１３３０は、それらのリアルフレンド登録要求を送信した携帯型端末３０に係るユーザの組をリアルフレンドであるものとしてユーザ情報１２１０に登録する（Ｓ１００７）。この際、ユーザ関係情報登録部１３３０は、リアルフレンドとしての登録前に、登録を承諾するか否かを問い合わせる要求を携帯型端末３０に送信することも考えられる。この場合、携帯型端末３０はリアルフレンドとして登録するか否かを、相手のユーザ名の情報など共に確認する画面をディスプレイに表示し、ユーザが承諾若しくは承諾しない旨を操作により選択できるようにすれば良い。その結果、リアルフレンドとしての登録の承諾が得られた旨の情報が両ユーザの携帯型端末３０から得られた場合には、ユーザ関係情報登録部１３３０は、両ユーザのユーザ間関係がリアルフレンドであるものとしてユーザ情報１２１０に登録することができる。

ユーザ関係情報登録部１３３０は、両ユーザ間の関係をリアルフレンドとして登録すると、登録した旨を携帯型端末３０へと通知する（Ｓ１００９）。携帯型端末３０は当該通知を受けて、リアルフレンドとして登録した旨、及びリアルフレンドとして登録されたユーザの情報をディスプレイに表示することで、ユーザにそれらの情報を伝える。

もしＳ１００５において、位置情報で示される位置の間の距離が一定の閾値以下であり、且つリアルフレンド登録要求が送信された時刻の差異が一定閾値以下であるリアルフレンド登録要求のペアが見つからなかった場合には、ユーザ関係情報登録部１３３０は、リアルフレンドとして登録すべきユーザが見つからなかった旨を携帯型端末３０へと通知する（Ｓ１０１１）。携帯型端末３０は当該通知を受けて、リアルフレンドの登録処理が失敗した旨をディスプレイに表示することで、ユーザにその旨を報知する。

（３．２． マルチプレイ開始処理）
続いて、マルチプレイによりクエストを開始する際の処理を、図１１及び図１２を参照しながら説明する。以下、ホストとなるユーザの処理、及びゲストとなるユーザの処理にそれぞれ分けて説明する。

（３．２．１． ホストユーザに対する処理）
まず、ホストとなるユーザに係るマルチプレイ開始時の処理を、図１１を参照しながら説明する。図１１は、ホストとなるユーザに係るマルチプレイ開始時に係るゲーム制御サーバ１０の処理の流れを示すフローチャートである。

図２に示したクエスト表示画面２００において、ユーザが何らかの操作を行った場合には、当該操作に応じた要求がゲーム制御サーバ１０へと送信される。もしソロプレイボタン２２３等、マルチプレイボタン２２５以外のボタンがユーザに選択され、当該選択に応じた要求を受信した場合には（Ｓ１１０１のＮＯ）、ゲーム制御サーバ１０は当該要求に応じた（すなわちユーザ操作に応じた）処理を行う（Ｓ１１０３）。

一方、ユーザがマルチプレイボタン２２５を選択した場合には、携帯型端末３０はグループ（ルーム）作成要求を、現在位置情報と共にゲーム制御サーバ１０へと送信する。ゲーム制御サーバ１０の新規グループ作成部１４１０は当該グループ作成要求を受信すると（Ｓ１１０１のＹＥＳ）、当該グループ作成要求に含まれる携帯型端末３０の現在位置情報を抽出する（Ｓ１１０５）。更に新規グループ作成部１４１０は、当該携帯型端末３０に係るユーザをホストとするグループ情報１２２０を作成し、ＤＢ１２００へ登録する（１１０７）。また新規グループ作成部１４１０は、携帯型端末３０へ、図３に具体例を示したルーム表示画面３００を表示するために必要なグループ情報１２２０を通知する（Ｓ１１０９）。

その後、他のユーザがゲストユーザとして当該グループに参加した場合には（Ｓ１１１１のＹＥＳ）、新規グループ作成部１４１０は新規参加ユーザをメンバとしてグループ情報１２２０へ登録する（Ｓ１１１３）。また新規グループ作成部１４１０は、当該更新されたグループ情報１２２０に基づくルーム表示画面３００を表示するために必要なグループ情報１２２０を携帯型端末３０へと送信する（Ｓ１１１５）。また、ゲストユーザの携帯型端末からグループから脱退する旨の要求を受信した場合にも（Ｓ１１１１ＹＥＳ）、新規グループ作成部１４１０は、当該ユーザに係る情報をグループ情報１２２０から削除する（Ｓ１１１３）。また新規グループ作成部１４１０は、当該更新されたグループ情報１２２０に基づくルーム表示画面３００を表示するために必要なグループ情報１２２０を携帯型端末３０へと送信する（Ｓ１１１５）。

ルーム表示画面３００において、ユーザがクエスト開始ボタン３３０を選択した場合には、携帯型端末３０はゲーム制御サーバ１０に対してクエスト開始要求を送信する。ゲーム制御サーバ１０は、当該クエスト開始要求を受信すると（Ｓ１１１７のＹＥＳ）、クエスト開始制御部１５１０は、クエスト情報１２３０を参照してクエストをプレイする際に必要となる消費スタミナ量を確認する（Ｓ１１１９）。またスタミナ消費ユーザ決定部１４５０は、グループを構成するユーザの内、いずれのユーザのスタミナを消費させるかを決定する（Ｓ１１２１）。スタミナ情報管理部１３２０は、当該スタミナ消費ユーザ決定部１４５０が決定したユーザの保有スタミナの値から、Ｓ１１１９で確認したクエストのプレイに必要となる消費スタミナの値を減少させるべく、ユーザ情報１２１０を更新する（Ｓ１１２３）。これらの処理が終わると、クエスト制御部１５００はクエストのプレイに係る制御を、携帯型端末３０と適宜通信しながら開始する（Ｓ１１２５）。

（３．３．２． ゲストユーザに対する処理）
続いて、ゲストとなるユーザに係るマルチプレイ開始時の処理を、図１２を参照しながら説明する。図１２は、ゲストとなるユーザに係るマルチプレイ開始時に係るゲーム制御サーバ１０の処理の流れを示すフローチャートである。

携帯型端末３０においてマルチプレイへのゲストとしての参加をする旨の操作入力がユーザからなされると、携帯型端末３０はゲーム制御サーバ１０に対して参加可能グループの問合せ要求を、ＧＰＳ等から取得される現在位置情報と共に送信する。

ゲーム制御サーバ１０は、当該参加可能グループの問合せ要求を携帯型端末３０から受信すると（Ｓ１２０１のＹＥＳ）、まず参加可能グループ抽出部１４２０は当該要求に含まれる位置情報を抽出する（Ｓ１２０３）。また参加可能グループ抽出部１４２０は、当該要求に係るユーザのユーザ情報１２１０を確認し、当該ユーザとリアルフレンドとして登録されているユーザの識別子を取得する（Ｓ１２０５）。

その上で参加可能グループ抽出部１４２０は、ゲストとして参加しようとしている当該ユーザの位置情報に係る位置から、ホストであるユーザの位置までの距離が一定範囲内にあるグループのグループ情報１２２０、及びゲストとして参加しようとしている当該ユーザとリアルフレンドとして登録されているユーザがホストとなっているグループのグループ情報１２２０を抽出する（Ｓ１２０７）。当該抽出が終わると、参加可能グループ抽出部１４２０は、それらの抽出されたグループ情報１２２０に係る情報を携帯型端末３０へと送信する（Ｓ１２０９）。これにより携帯型端末３０は、図４に具体例を示したルーム選択画面４００を表示することができる。

その後、ユーザが携帯型端末３０の表示するルーム選択画面４００においてルーム情報表示領域４１０を選択すると、グループ情報取得要求が携帯型端末３０からゲーム制御サーバ１０へと送信される。ゲーム制御サーバ１０の新規グループ作成部１４１０が当該グループ情報取得要求を受信すると（Ｓ１２１１のＹＥＳ）、新規グループ作成部１４１０は、当該ユーザをゲストとしてグループ情報１２２０に追加する（Ｓ１２１３）。当該処理は、図１１に示したＳ１１１３の処理に対応する。また新規グループ作成部１４１０は、当該更新されたグループ情報１２２０に基づくルーム表示画面３００を表示するために必要なグループ情報１２２０を、携帯型端末３０へと送信する（Ｓ１２１５）。当該処理は、図１１に示したＳ１１１５の処理に対応する。

（３．４． マルチプレイ周回に係る処理）
以下、マルチプレイによるクエスト終了時の処理を、図１３を参照しながら説明する。図１３は、マルチプレイヤよりクエストを終了した際の処理の流れを示すフローチャートである。

クエスト制御部１５００による制御の下、マルチプレイによるクエストが終了すると（Ｓ１３０１のＹＥＳ）、報酬付与部１５２０は、マルチプレイでプレイした各ユーザに対して報酬を付与し、ユーザ情報登録部１３１０は当該付与された情報に基づきユーザ情報１２１０を更新する（Ｓ１３０３）。また、報酬付与部１５２０は、各ユーザの携帯型端末３０に対して付与した報酬にかかる情報やクリアに要した時間等の情報を通知する（Ｓ１３０５）。携帯型端末３０は当該通知を受け、図５に具体例を示したクエスト結果表示画面５００をディスプレイに表示する。

クエスト結果表示画面５００には、前述のとおり、再チャレンジボタン５２０と終了ボタン５３０とが選択可能に配置される。ユーザが再チャレンジボタン５２０を選択した場合には、携帯型端末３０は、同一のクエストを同じグループにより再チャレンジする、すなわち周回すること示すプレイ継続情報をゲーム制御サーバ１０へ通知する。また、ユーザが終了ボタン５３０を選択した場合には、携帯型端末３０は、同一のクエストに係る周回を終了する旨のプレイ継続情報をゲーム制御サーバ１０へ通知する。

クエスト周回を終了する旨のプレイ継続情報を、ホストであるユーザを含む１以上のユーザの携帯型端末３０から受信した場合には（Ｓ１３０７のＮＯ）、グループ解散部１４３０はそれらのユーザが属していたグループに係るグループ情報１２２０をＤＢ１２００から削除する（Ｓ１３０９）。

一方、同一のクエストの同じグループにより再チャレンジする旨のプレイ継続情報を、ホストであるユーザを含む１以上のユーザの携帯型端末３０から受信した場合には（Ｓ１３１１のＹＥＳ）、まずグループ解散部１４３０が、それらのユーザが属していたグループに係るグループ情報１２２０をＤＢ１２００から削除する（Ｓ１３１１）。その上で周回グループ作成部１４４０は、再チャレンジを選択したユーザをメンバとする新たなグループを作成し、当該グループに係るグループ情報１２２０をＤＢ１２００へ登録する（Ｓ１３１３）。当該周回用のグループは、Ｓ１３１１で解散させたグループに所属していたユーザの内、少なくともホストであったユーザを含む１以上のユーザで構成される。また、周回グループ作成部１４４０は当該グループに係る情報を携帯型端末３０へと通知する（Ｓ１３１５）。

また、スタミナ消費ユーザ決定部１４５０は、作成した周回用のグループを構成するユーザのうち、いずれのユーザのスタミナを消費させるかを決定する（Ｓ１３１７）。当該スタミナの決定手法としては種々考えられるが、例えば、ホストであるユーザをスタミナ消費対象としても良い。或いは、ホストであるユーザのスタミナの残量が当該クエストのプレイに不足している場合には他のユーザからスタミナを消費させるようにしても良い。このとき、例えば最も保有スタミナの多いユーザを選択するようにしても良い。また、グループを構成する各ユーザから均等にスタミナを消費させても良いし、スタミナ消費対象を、ユーザからの指示に併せて変更することもできる。

なお、図１３では、クエストを周回するか否かの選択が、ホストであるユーザの判断に依存するようになっているがこれに限られるものではない。例えばホストがクエストの周回を終了すると判断した場合には、他の周回を続けるユーザのみで周回用のグループを作成してもよい。その際には、いずれのユーザを周回用のグループのホストとするかを決める必要があるが、それは例えば周回グループ作成部１４４０がユーザによる選択なしに決めても良いし、或いはユーザが誰をホストにするかを切り替えられるようにしても良い。

（４． ハードウェア構成）
次に、ゲーム制御サーバ１０を実現可能なハードウェア構成について図１４を参照しながら説明する。図１４は、実施形態に係るゲーム制御サーバ１０のハードウェア構成の具体例を示す図である。図１４に示すように、ゲーム制御サーバ１０は、制御部１０１と、通信インタフェース（Ｉ／Ｆ）部１０５と、記憶部１０７と、表示部１１３と、入力部１１５とを含み、各部はバスライン１１７を介して接続される。

制御部１０１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ。図示せず）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ。図示せず）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１０３等を含む。制御部１０１は、記憶部１０７に記憶される制御プログラム１０９を実行することにより、一般的な情報処理装置としての機能に加え、上述したオンラインゲームに係る処理を実現可能に構成される。例えば、図６を参照しながら説明した通信部１１００、ユーザ情報管理部１３００、グループ管理部１４００、及びクエスト制御部１５００は、ＲＡＭ１０３に一時記憶された上で、ＣＰＵ上で動作する制御プログラム１０９として実現可能である。

また、ＲＡＭ１０３は、制御プログラム１０９に含まれるコードの他、図６に示したユーザ情報１２１０、グループ情報１２２０、及びクエスト情報１２３０の一部又は全部を一時的に保持する。更にＲＡＭ１０３は、ＣＰＵが各種処理を実行する際のワークエリアとしても使用される。

通信Ｉ／Ｆ部１０５は、課金サーバ２０や携帯型端末３０を含む外部の装置との間で、有線又は無線によるネットワークＮを介したデータ通信を行うためのデバイスである。図６で示したユーザ情報管理部１３００、グループ管理部１４００、及びクエスト制御部１５００が携帯型端末３０との間でおこなう通信は、全て通信部１１００による制御のもと、通信Ｉ／Ｆ部１０５が行う。

記憶部１０７は、例えばＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）やフラッシュメモリ等の不揮発性の記憶媒体である。記憶部１０７は、一般的な情報処理装置としての機能を実現するためのオペレーションシステム（ＯＳ）やアプリケーション及びデータ（図施設）を記憶する。また記憶部１０７は、制御プログラム１０９及びＤＢ１２００を記憶する。

制御プログラム１０９は、上述のオンラインゲームに係る処理を行うためのプログラムであり、携帯型端末３０からの要求に基づいて、ゲームの進行を制御するためのプログラムである。前述のとおり、図６に示した通信部１１００、ユーザ情報管理部１３００、グループ管理部１４００、及びクエスト制御部１５００は、制御プログラム１０９に含まれる。

データベース１２００は、オンラインゲームに必要な各種データ、例えばユーザ情報１２１０、グループ情報１２２０、及びクエスト情報１２３０などを含むことができる。ＤＢ１２００に含まれる各種データは、必要に応じてＲＡＭ１０３などにロードされ、制御部１０１に含まれるＣＰＵから参照される。

表示部１１３は、管理者に情報を提示するためのディスプレイ装置である。表示部１１３の具体例としては、例えば液晶ディスプレイや有機ＥＬ（Ｅｌｅｃｔｒｏ−Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ等が挙げられる。入力部１１５は、管理者から入力を受け付けるためのデバイスである。入力部１１５の具体例としては、キーボードやマウス、タッチパネル等を挙げることができる。

なお、ゲーム制御サーバ１０は、表示部１１３及び入力部１１５を必ずしも備える必要はない。また表示部１１３及び入力部１１５は、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）やディスプレイポート等の各種インタフェースを介して外部からゲーム制御サーバ１０に接続されても良い。

（５． 本実施形態の効果）
以上説明したように、本実施形態に係るゲームシステム１では、マルチプレイによりクエストをプレイする際に、位置的に近くにいるユーザに加えて、友人関係（リアルフレンド）として例えば位置情報に基づいて登録されたユーザについては、マルチプレイの際のグループマッチングの対象として抽出される。これにより、無制限なマッチングを避けることにより友人関係を通じたユーザ数の拡大を果たしつつ、例えばユーザが過疎地域に旅行した際にマッチングされるユーザが極めて限定的になってしまう等の課題を避ける事ができる。

更に、本実施形態係るゲームシステム１では、同じメンバでマルチプレイによりクエストを連続周回したい際に、クエスト終了時に表示されるクエスト結果表示画面５００への操作のみで新たに周回用のグループが作成される。またクエストプレイの際に必要となるパラメータであるスタミナをどのように消費するかも決められる。これにより、クエストをクリアする度にグループを解散し、新たに作成する作業をユーザに行わせる必要がないため、周回に係るユーザ操作の煩雑性を低減することが可能である。

（６ 付記事項）
なお、上述の実施形態の構成は、組み合わせたり或いは一部の構成部分を入れ替えたりしてもよい。また、本発明の構成は上述の実施形態のみに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加えてもよい。

上述の実施形態では、位置に関係なくマッチング可能な対象を「リアルフレンド」であるユーザのみに限定としているが、これに限られない。例えば、「リアルフレンド」に比べて顔見知り以外にも範囲が拡大するという懸念はあるが、事前に関係性が構築されている「フレンド」にまで範囲を拡大することも考えられる。

また、上述の実施形態では、ＧＰＳ等による位置情報を取得することで「ユーザの位置の近くにいるユーザ」を判定する例を説明したがこれに限られない。例えば、端末間でＢｌｕｅｔｏｏｔｈ（登録商標）や赤外線通信などの近距離無線通信を介した情報のやり取りが行われた事を示す情報をサーバに送信したり、一方の端末の表示画面上に表示した識別コードの情報を、もう一方の端末が読み込んで、読み込んだ情報をサーバに送信したりすることで、複数の端末を操作するユーザ同士が近くにいると判定してもよい。

また、上述の実施形態では、ホストである「ユーザＸ」の近傍にいるユーザ又は当該「ユーザＸ」と「リアフレ」として登録されているユーザが参加可能となっている例を説明した。他の実施形態として、たとえば、「ユーザＸ」の近傍にいる又は当該「ユーザＸ」と「リアフレ」として登録されているという参加条件を満たす新たな「ユーザＹ」がルームに参加した場合に、「ユーザＹ」を基準に新たな参加条件を設定／追加することも考えられる。例えば、元からいた「ユーザＸ」に加えて新たに「ユーザＹ」がルームに参加した後は、当該ルームに参加可能な他のユーザの条件を、「ユーザＸまたはユーザＹのいずれか」の近傍にいる、又は「ユーザＸまたはユーザＹのいずれか」と「リアフレ」として登録されているという参加条件に変更することが考えられる。或いは、「ユーザＸまたはユーザＹ」の近傍にいるユーザ、又は「ユーザＸ」と「リアフレ」として登録されているユーザを、参加可能とすることも考えられる。さらに、以上のような参加条件の変更を、ルームの参加ユーザが増減する毎に実行してもよい。加えて、参加条件の変更の基準となる「ユーザＹ」となり得るユーザを、「ユーザＸ」のリアフレに限定してもよい。この場合、「ユーザＸ」の近傍にいるユーザがルームに参加した場合には参加条件は変更されず、「ユーザＸ」と「リアフレ」として登録されているユーザがルームに参加した場合には参加条件が変更される。

また、上述の実施形態では、ホストである「ユーザＸ」の近傍にいるユーザ又は当該「ユーザＸ」と「リアフレ」として登録されているユーザが常に参加可能となっている例を説明した。他の実施形態として、「ユーザＸ」の近傍にいるユーザと「リアフレ」として登録されているユーザの、それぞれの参加可能状態を変更できるようにしても良い。例えば、「ユーザＸ」の近傍にいるユーザの人数と閾値を比較して、「リアフレ」であるユーザとマッチングできるかどうかを決めることができる。より具体的には、「ユーザＸ」の近傍にいるユーザが一定数以上の場合に、「リアフレ」であるユーザのルームへの参加を禁止する。これにより、ルーム作成時に現実に顔を合わせているユーザが近くにいる場合には、近くにいるユーザを優先してグループを作成することができる。

また、上述の実施形態では、マルチプレイを戦ったグループにフレンド又はリアルフレンドが含まれている場合には、報酬付与部１５２０は、報酬を通常時よりも高く設定する例を説明した。他の実施形態として、フレンド又はリアルフレンドの中でも特定の条件を満たすユーザが含まれているか否かで、異なる報酬を設定することができる。例えば、ホストである「ユーザＸ」の「リアルフレンド」として登録されており、且つ「ユーザＸ」の近傍にいるユーザに対しては、「ユーザＸ」の「リアルフレンド」でありながら「ユーザＸ」の近傍にいないユーザに比べて高い報酬を付与することができる。また、「ユーザＸ」の「リアルフレンド」であるユーザが、「ユーザＸ」から遠距離にいる状態でマルチプレイを行った後に、当該ユーザが「ユーザＸ」の近傍にいる状態でマルチプレイを行った場合には通常の報酬とは別の特典を付与することも考えられる。さらにこの時、「ユーザＸ」から遠距離にいる状態でマルチプレイを行った回数の多さや、前回「ユーザＸ」の近傍にいる状態でマルチプレイを行なってから経過した期間の長さによって、特典の数を増やしたり、特典をより価値の高いものにしたりすることもできる。

なお、上述の実施形態の一部又は全部は、以下の付記のようにも記載されうる。しかしながら、以下には限られない。また、本発明のプログラムは、上述の実施形態で説明した各動作を、コンピュータに実行させるプログラムであれば良い。

（付記１）
ゲームのプレイに応じて消費されるパラメータをユーザ毎に管理する処理と、
複数の端末を操作する複数のユーザが第１のグループとしてプレイするゲームを制御する処理と、
前記ゲームのプレイに応じて、前記第１のグループを構成する前記複数のユーザのうち、少なくとも一部のユーザに係る前記パラメータを減らす処理と、
前記ゲームの終了後、前記複数のユーザのそれぞれが同一の前記ゲームの再度のプレイを希望するか否かに関するプレイ継続情報を前記複数の端末から受信する処理と、
前記プレイ継続情報に基づき、前記複数のユーザのうち前記ゲームを再度プレイする１以上のユーザにより構成される第２のグループのグループ情報を、当該１以上のユーザの操作する各端末に送信する送信処理と、
前記第２のグループとして前記ゲームをプレイする際に、前記第２のグループを構成するユーザのうち、いずれのユーザに係る前記パラメータを減らすかを決める決定処理と
を情報処理装置に実行させるためのプログラム。

（付記２）
前記第１のグループを構成するためのグループ作成要求を第１のユーザに係る第１の端末から受信する処理
を更に前記情報処理装置に実行させ、
前記送信処理において、前記ゲームの再度のプレイを希望する旨の前記プレイ継続情報を少なくとも前記第１の端末から受信した場合に、前記第２のグループのグループ情報を少なくとも前記第１の端末に送信する、
付記１記載のプログラム。

（付記３）
前記決定処理において、前記第２のグループに含まれる前記第１のユーザに係るパラメータを減らすことを決める、
付記２記載のプログラム。

（付記４）
前記決定処理において、前記第２のグループを構成するユーザに係る端末の少なくともいずれかからの要求又は前記複数のユーザが保有するパラメータ状態の少なくとも一方に応じて、前記パラメータを減らすユーザを決定する、
付記１又は付記２のいずれか１項記載のプログラム。

（付記５）
ゲームのプレイに応じて消費されるパラメータをユーザ毎に管理する手段と、
複数の端末を操作する複数のユーザが第１のグループとしてプレイするゲームを制御する手段と、
前記ゲームのプレイに応じて、前記第１のグループを構成する前記複数のユーザのうち、少なくとも一部のユーザに係る前記パラメータを減らす手段と、
前記ゲームの終了後、前記複数のユーザのそれぞれが同一の前記ゲームの再度のプレイを希望するか否かに関するプレイ継続情報を前記複数の端末から受信する手段と、
前記プレイ継続情報に基づき、前記複数のユーザのうち前記ゲームを再度プレイする１以上のユーザにより構成される第２のグループのグループ情報を、当該１以上のユーザの操作する各端末に送信する手段と、
前記第２のグループとして前記ゲームをプレイする際に、前記第２のグループを構成するユーザのうち、いずれのユーザに係る前記パラメータを減らすかを決める手段と
を備える情報処理装置。

１ ：ゲームシステム
１０ ：ゲーム制御サーバ
２０ ：課金サーバ
３０ ：携帯型端末
１０１ ：制御部
１０３ ：ＲＡＭ
１０５ ：通信インタフェース部
１０７ ：記憶部
１０９ ：制御プログラム
１１３ ：表示部
１１５ ：入力部
１１７ ：バスライン
２００ ：クエスト表示画面
２１０ ：ユーザ情報表示領域
２１１ ：プレイヤ名情報
２１３ ：レベル情報
２１５ ：経験値情報
２１７ ：スタミナ情報
２２０ ：クエスト情報表示領域
２２１ ：消費クエスト情報
２２３ ：ソロプレイボタン
２２５ ：マルチプレイボタン
３００ ：ルーム表示画面
３１０ ：参加プレイヤ情報表示領域
３２０ ：取消ボタン
３３０ ：クエスト開始ボタン
４００ ：ルーム選択画面
４１０ ：ルーム情報表示領域
４１１ ：ホスト情報表示領域
４１３ ：ユーザ関係情報
４１５ ：クエスト情報
４１７ ：ステータス情報
４２０ ：スクロールバー
５００ ：クエスト結果表示画面
５１０ ：クエスト結果表示領域
５２０ ：再チャレンジボタン
５３０ ：終了ボタン
８００ ：リアルフレンド登録画面
８１０ ：タップ領域
１１００ ：通信部
１２００ ：データベース
１２１０ ：ユーザ情報
１２２０ ：グループ情報
１２３０ ：クエスト情報
１３００ ：ユーザ情報管理部
１３１０ ：ユーザ情報登録部
１３２０ ：スタミナ情報管理部
１３３０ ：ユーザ関係情報登録部
１４００ ：グループ管理部
１４１０ ：新規グループ作成部
１４２０ ：参加可能グループ抽出部
１４３０ ：グループ解散部
１４４０ ：周回グループ作成部
１４５０ ：スタミナ消費ユーザ決定部
１５００ ：クエスト制御部
１５１０ ：クエスト開始制御部
１５２０ ：報酬付与部
Ｎ ：ネットワーク

Claims (6)

1. 第１の端末を操作する第１のユーザが少なくとも含まれるグループを構成するためのグループ作成要求を前記第１の端末から受信する処理と、
   前記グループ作成要求を受信した後、前記第１の端末と所定の端末間関係を満たす第２の端末に対して、当該第２の端末を操作する第２のユーザが前記グループに参加することを可能とするグループ情報を送信する第１の送信処理と、
   前記第１のユーザと第３の端末を操作する第３のユーザとが予め登録された所定のユーザ間関係を満たしている場合に、前記グループ作成要求を受信した後、前記第３のユーザが操作する前記第３の端末に、前記第３のユーザが前記グループに参加することを可能とするグループ情報を送信する第２の送信処理と、
   前記第２の端末と前記第３の端末の少なくとも一方から前記グループへの参加要求を受信した場合に、当該参加要求を送信した端末に係るユーザと前記第１のユーザとを含む前記グループを構成する処理と、
   前記参加要求を送信した端末と前記端末間関係を満たす第４の端末に対して、当該第４の端末を操作する第４のユーザが前記グループに参加することを可能とするグループ情報を送信する第３の送信処理と
   前記グループとしてプレイするゲームを制御する処理と
   を情報処理装置に実行させるためのプログラム。
2. 前記第１の送信処理において、前記第１の端末及び前記第２の端末が所定範囲内に位置する前記端末間関係を満たしている場合に、前記第２のユーザが前記グループに参加することを可能とする前記グループ情報を前記第２の端末に送信する、
   請求項１記載のプログラム。
3. 前記第１の端末及び前記第３の端末にて所定の操作が行われ、且つ、当該所定の操作が行われた際に前記第１の端末及び前記第３の端末が所定範囲内に位置する場合に、前記第１のユーザ及び前記第３のユーザを、前記ユーザ間関係を満たしているものとして登録する登録処理
   を更に情報処理装置に実行させるための請求項１又は請求項２のいずれか１項記載のプログラム。
4. 前記１のユーザ及び前記第３のユーザが前記グループとして前記ゲームをプレイし、前記第１のユーザ及び前記第３のユーザが前記ユーザ間関係を満たしているものとして登録されている場合に、当該ゲーム内容に応じて与えられる報酬を、前記ユーザ間関係を満たしているものとして登録されていない場合に与えられる報酬よりも高く設定する、
   請求項１乃至請求項３のいずれか１項記載のプログラム。
5. 前記グループを構成する処理の後に、
   前記参加要求を送信した端末に係るユーザと第５の端末を操作する第５のユーザとが前記ユーザ間関係を満たしている場合に、前記第５のユーザが操作する前記第５の端末に、前記第５のユーザが前記グループに参加することを可能とするグループ情報を送信する第４の送信処理
   を更に情報処理装置に実行させるための請求項１又は請求項４のいずれか１項記載のプログラム。
6. 第１の端末を操作する第１のユーザが少なくとも含まれるグループを構成するためのグループ作成要求を前記第１の端末から受信する手段と、
   前記グループ作成要求を受信した後、前記第１の端末と所定の端末間関係を満たす第２の端末に対して、当該第２の端末を操作する第２のユーザが前記グループに参加することを可能とするグループ情報を送信する手段と、
   前記第１のユーザと第３の端末を操作する第３のユーザとが予め登録された所定のユーザ間関係を満たしている場合に、前記グループ作成要求を受信した後、前記第３のユーザが操作する前記第３の端末に、前記第３のユーザが前記グループに参加することを可能とするグループ情報を送信する手段と、
   前記第２の端末と前記第３の端末の少なくとも一方から前記グループへの参加要求を受信した場合に、当該参加要求を送信した端末に係るユーザと前記第１のユーザとを含む前記グループを構成する手段と、
   前記参加要求を送信した端末と前記端末間関係を満たす第４の端末に対して、当該第４の端末を操作する第４のユーザが前記グループに参加することを可能とするグループ情報を送信する手段と、
   前記グループとしてプレイするゲームを制御する手段と
   を備える情報処理装置。

Images