JP2023068318A - 情報処理装置、情報処理方法及びプログラム - Google Patents

Abstract

【課題】グループを指定したマルチプレイの募集が無駄になることを抑制すること。【解決手段】複数のユーザが共同でゲームを行うマルチプレイを募集するグループの指定を第１ユーザから受け付ける画面に、前記マルチプレイの成立のし易さに関する情報をグループごとに表示させる表示制御部と、前記第１ユーザが指定した少なくとも１のグループに所属する第２ユーザに対して、前記マルチプレイの募集を行う募集制御部と、を有する情報処理装置を提供する。【選択図】図３

Description

本発明は、情報処理装置、情報処理方法及びプログラムに関する。

デッキと呼ばれる、複数のキャラクタから構成されるチームを用いて、クエストをクリアしていくゲームが知られている。また、複数のユーザが共同で１つのクエストをプレイするマルチプレイと呼ばれるゲーム方式が知られている。例えば、特許文献１には、ユーザが所持するプレイヤキャラクタを用いてクエストを実行するゲームが開示されている。

特開２０２０－０４４３２０号公報

マルチプレイでゲームをプレイする場合、ホスト役のユーザが、マルチプレイに参加するゲストユーザを募ることが一般的である。ここで、マルチプレイを行う際、ユーザの熟練度やプレイ目的などが類似しているユーザ同士でマルチプレイを行う方が、チーム内での連携が取りやすくなることから望ましい。そこで、類似するユーザ間で予めグループを組んでおき、グループ内のユーザでマルチプレイを行うことが考えられる。

しかしながら、グループを組んだ場合、活発に活動をしているグループ（例えばゲームをプレイしているユーザが多いグループ）と、活発に活動していないグループ（例えばゲームをプレイしているユーザが少ないグループ）が生じ得る。そのため、ホスト役のユーザが、マルチプレイに参加するゲストユーザを募る場合において、活発な活動がなされていないグループでゲストユーザを募ってしまうと、ゲストユーザからの応募が無くマルチプレイが成立しないことが考えられる。

そこで、本発明は、マルチプレイの募集が無駄になることを抑制することを可能とする技術を提供することを目的とする。

本発明の一態様に係る情報処理装置は、複数のユーザが共同でゲームを行うマルチプレイを募集するグループの指定を第１ユーザから受け付ける画面に、前記マルチプレイの成立のし易さに関する情報をグループごとに表示させる表示制御部と、前記第１ユーザが指定した少なくとも１のグループに所属する第２ユーザに対して、前記マルチプレイの募集を行う募集制御部と、を有する。

本発明によれば、マルチプレイの募集が無駄になることを抑制することを可能とする技術を提供することができる。

本実施形態に係るゲームシステムのシステム構成の一例を示す図。 ゲームサーバ及び端末のハードウェア構成の一例を示す図。 ゲームサーバの機能ブロック構成の一例を示す図。 端末の機能ブロック構成の一例を示す図。 ユーザ管理ＤＢ及びユーザグループ管理ＤＢの一例を示す図。 所有キャラクタ管理ＤＢの一例を示す図。 ユーザがユーザグループを作成する際の処理手順の一例を示すフローチャート。 ユーザがユーザグループに参加する際の処理手順の一例を示すフローチャート。 ユーザグループに参加する際の画面表示例を示す図。 ユーザグループ内でマルチプレイを行う際の処理手順の一例を示すフローチャート。 マルチプレイを募集する際の画面例を示す図。 マルチプレイに参加する際の画面例を示す図。

添付図面を参照して、本発明の実施形態について説明する。なお、各図において、同一の符号を付したものは、同一又は同様の構成を有する。

＜システム構成＞
図１は、本実施形態に係るゲームシステム１のシステム構成の一例を示す図である。図１に示すゲームシステム１は、ゲームサーバ１０（ゲーム装置）と、複数の端末２０とを備える。ゲームサーバ１０及び端末２０は、インターネット、イントラネット、無線ＬＡＮ又は移動通信等の通信ネットワークＮを介して互いに通信可能に接続されている。

ゲームサーバ１０は、例えば、プレイヤに関する各種情報を管理したり、ゲームの一部の処理を実行したりする等、端末２０がゲームを提供する上でその一部の機能を担う装置である。ゲームサーバ１０は、１又は複数の情報処理装置から構成されていてもよいし、仮想的なサーバ（クラウドサーバ等）を用いて構成されていてもよい。

端末２０は、ゲームをプレイヤに提供する情報処理装置であり、プレイヤは、端末２０を操作することで本実施形態に係るゲームを実行することができる。端末２０は、例えば、携帯電話（スマートフォンを含む）、タブレット、パーソナルコンピュータ、アーケードゲーム装置、又は、コンシューマゲーム装置等のコンピュータである。端末２０は、ＧＰＳ(Global Positioning System)等を用いて検出した自身の位置をゲームサーバ１０に通知する。

＜ゲーム概要＞
続いて、本実施形態に係るゲームシステム１が提供するゲームの概要を説明する。ゲームシステム１が提供するゲームでは、ユーザ（プレイヤと称してもよい）は、ユーザが所持している複数のゲーム媒体の中から選択したゲーム媒体でデッキを編成し、編成したデッキを用いてクエストをクリアすることで、新たなゲーム媒体やアイテムを入手することができる。また、ユーザは、入手した複数のゲーム媒体を合成することでより強いキャラクタを生成したり、アイテムを用いてゲーム媒体の属性を強化したりすることで、より難易度の高いクエストに挑戦することができる。ゲーム媒体は、ゲームオブジェクトと称してもよい。また、ゲーム媒体は、キャラクタやゲームカード等であってもよい。

クエストとは、予め定められた一定の条件を満たすことでクリア可能な課題を意味する用語である。クエストは、一般的には、探索、課題及びミッションと呼ばれることもある。クエストをプレイするユーザは、当該一定の条件を満たすことでクエストをクリアすることができ、クエストをクリアすると、ユーザに報酬が与えられたり、ゲームのストーリーが進行したりする。なお、本実施形態では、ゲームの中で様々なクエストが提供されることを想定しているが、本実施形態がこれに限定されるものではない。本実施形態における「クエスト」の用語は、ゲームそのものを意味してもよい。

デッキとは、複数のゲーム媒体を組み合わせたチームを意味する用語である。ユーザは、クエストを実行する際、当該クエストをクリアするために適した能力を持つゲーム媒体を選択してデッキを編成してクエストをプレイする。ゲームサーバ１０には、ユーザが編成した複数のデッキを記憶しておくことができ、ユーザは、記憶された複数のデッキの中から一のデッキを選択してクエストをプレイすることが可能である。本実施形態では、ユーザがクエストをプレイすることを、クエストを実行すると称してもよい。また、本実施形態では、クエストをプレイすることを、ゲームをプレイする、若しくは、ゲームを実行すると称してもよい。

クエストは、複数のユーザが共同でプレイすることができる。以下、クエストを複数のユーザが共同でプレイすることを「マルチプレイ」と言う。マルチプレイは、共同プレイと呼ばれてもよい。一方、ユーザ単独でクエストをプレイすることを、シングルプレイと称してもよい。マルチプレイでは、各ユーザは、デッキを編成する複数のキャラクタのうち、自身に割り当てられたキャラクタを操作することができる。例えば、キャラクタＡ～Ｄから編成されるデッキについて、キャラクタＡはユーザＡ（自ユーザ）に割り当てられ、キャラクタＢ～Ｄは、それぞれ他のユーザＢ～Ｄに割り当てられていると仮定する。この場合、ユーザＡがキャラクタＡを操作し終わった後、ユーザＢがキャラクタＢを操作し、次にユーザＣがキャラクタＣを操作するといったように、デッキを編成するキャラクタを、各ユーザが順番に操作していく。マルチプレイを募集するユーザは、ホスト又はホストユーザと呼ばれてもよい。一方、ホストが募集するマルチプレイに参加するユーザは、ゲスト又はゲストユーザと呼ばれてもよい。マルチプレイを募集することは、マルチプレイへの参加を募集する、マルチプレイを招集する、マルチプレイを募る等と読み替えてもよい。

マルチプレイでは、デッキを編成する複数のキャラクタは、ホストユーザが所持するキャラクタで構成されてもよいし、ホスト及びゲストユーザの各々が、自身が所持するキャラクタの中から選択したキャラクタで構成されてもよい。

本実施形態では、ユーザは、グループ（以下、「ユーザグループ」と言う。）に参加することができる。各ユーザは、１以上のユーザグループを作成することができる。また、各ユーザは、１以上のユーザグループに参加することができる。ユーザグループを作成するユーザは、作成ユーザやグループオーナーなどと呼ばれてもよい。作成されたユーザグループに参加するユーザは、参加ユーザなどと呼ばれてもよい。以下の説明において、作成ユーザ及び参加ユーザを特に区別しない場合、ユーザグループに所属するユーザ又は所属ユーザなどと呼ぶ。

ユーザグループを作成するユーザは、作成するユーザグループに任意のタグを付与することができる。また、ユーザグループに参加したいユーザは、ユーザグループに付与されたタグを検索することで、参加したいユーザグループを発見することができる。タグは、ゲーム運営者等により予め定められたタグ及び／又は任意の文字列等を含んでいてもよい。

ユーザグループには、どのようなユーザも参加可能であるが、本実施形態では、ゲームに対する経験の程度、趣向若しくはゲームプレイの目的等が共通しているユーザ同士がグループを組むことを想定している。例えば、イベントクエストＡが提供されている期間に、「クエストＡをクリアしたい」という内容のタグが付与されたユーザグループが作成され、クエストＡをクリアしたいユーザが当該ユーザグループに参加して、クエストＡのクリアを目指すという利用方法が想定される。また、「レベル５０以上のヘビーユーザ限定」というタグが付与されたユーザグループには、レベル５０以上であるユーザが参加することが想定される。

本実施形態では、ユーザは、自身が所属するユーザグループ（つまり、自身が作成したユーザグループ又は自身が参加しているユーザグループ）を指定してマルチプレイの募集を行うことができる。ユーザグループを指定してマルチプレイを募集する場合、指定されたユーザグループに所属するユーザのみが、当該マルチプレイに参加することができる。これにより、経験の程度、趣向若しくはプレイの目的等が共通しているユーザ同士でマルチプレイを行うことが容易になる。

また、ゲームサーバ１０は、ユーザグループを指定してマルチプレイの募集を行う画面に、「マルチプレイの成立のし易さに関する情報」をユーザグループごとに表示させる。マルチプレイは、当然ながら、参加を希望するユーザが現れないと成立しない。従って、ユーザは、当該情報を参照し、マルチプレイが成立し易いと思われるユーザグループを指定してマルチプレイを募集することができる。これにより、マルチプレイが成立せず、マルチプレイの募集が無駄になってしまうことを抑制することができる。

＜ハードウェア構成＞
図２は、ゲームサーバ１０及び端末２０のハードウェア構成の一例を示す図である。ゲームサーバ１０及び端末２０は、ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphical Processing Unit）等のプロセッサ１１、メモリ、ＨＤＤ（Hard Disk Drive）及び／又はＳＳＤ（Solid State Drive）等の記憶装置１２、有線又は無線通信を行う通信ＩＦ（Interface）１３、入力操作を受け付ける入力デバイス１４、及び情報の出力を行う出力デバイス１５を有する。入力デバイス１４は、例えば、キーボード、タッチパネル、マウス及び／又はマイク等である。出力デバイス１５は、例えば、ディスプレイ、タッチパネル及び／又はスピーカ等である。

＜機能ブロック構成＞
（ゲームサーバ）
図３は、ゲームサーバ１０の機能ブロック構成の一例を示す図である。ゲームサーバ１０は、記憶部１００と、制御部１０１とを含む。記憶部１００は、ゲームサーバ１０が備える記憶装置１２を用いて実現することができる。また、制御部１０１は、ゲームサーバ１０のプロセッサ１１が、記憶装置１２に記憶されたプログラムを実行することにより実現することができる。また、当該プログラムは、記憶媒体に格納することができる。当該プログラムを格納した記憶媒体は、コンピュータ読み取り可能な非一時的な記憶媒体（Non-transitory computer readable medium）であってもよい。非一時的な記憶媒体は特に限定されないが、例えば、ＵＳＢメモリ又はＣＤ－ＲＯＭ等の記憶媒体であってもよい。

記憶部１００は、ゲームサーバ１０がゲームを実行するために必要なゲームデータを記憶する。ゲームデータには、各種のデータベースが含まれる。

制御部１０１は、ゲームの実行に関する各種の処理を行う。例えば、ユーザにより指定されたクエストを実行する処理、ユーザに報酬を付与する処理等を行う。また、制御部１１１は、表示制御部１０２、グループ制御部１０３及び募集制御部１０４を含む。制御部１０１は、ゲーム実行部や実行部などと呼ばれてもよい。

表示制御部１０２は、ゲームに関する各種の画面を端末２０のディスプレイに表示させる。例えば、表示制御部１０２は、マルチプレイを募集するユーザグループの指定をホストユーザから受け付ける画面に、マルチプレイの成立のし易さに関する情報をユーザグループごとに表示させる。なお、ホストユーザを、「第１ユーザ」と称してもよい。

グループ制御部１０３は、ユーザグループの作成及び管理等を行う。例えば、グループ制御部１０３は、ユーザからの指示を受けてユーザグループを新たに作成する処理、及び、ユーザからユーザグループへの参加依頼を受け付けた場合に、当該ユーザと当該ユーザグループとを対応づけて管理する処理等を行う。

募集制御部１０４は、マルチプレイの募集に関する各種の処理を行う。募集制御部１０４は、例えば、ホストユーザ（第１ユーザ）が指定した少なくとも１のグループに所属するユーザに対して、マルチプレイの募集を行う。ホストユーザが指定したグループに所属するユーザを、「募集対象ユーザ」や「第２ユーザ」と称してもよい。マルチプレイの募集を行うとは、募集対象ユーザに対して、マルチプレイへの参加依頼を通知することと、募集対象ユーザからマルチプレイへの参加を受け付けることを含んでいてもよい。

また、募集制御部１０４は、ホストユーザ（第１ユーザ）が指定した複数のグループの各々に所属する募集対象ユーザに対して、マルチプレイの募集を行うようにしてもよい。

表示制御部１０２は、グループ制御部１０３及び募集制御部１０４の一部であってもよい。例えば、ユーザグループに関連する各種処理のうち画面表示に関する処理については表示制御部１０２が行い、データベースへのアクセスなど、画面表示以外の処理についてはグループ制御部１０３が行うこととしてもよい。同様に、マルチプレイの募集に関する各種処理のうち画面表示に関する処理については表示制御部１０２が行い、データベースへのアクセスや、参加ユーザ募集中のマルチプレイの管理など、画面表示以外の処理については募集制御部１０４が行うこととしてもよい。しかしながら、これに限定されず、表示制御部１０２は、グループ制御部１０３及び募集制御部１０４の一部ではなく個別の機能ブロックであってもよい。

（端末）
図４は、端末２０の機能ブロック構成の一例を示す図である。端末２０は、記憶部２００と、通信部２０１と、ＵＩ（User Interface）部２０２と、制御部２０３とを含む。記憶部２００は、端末２０が備える記憶装置１２を用いて実現することができる。また、通信部２０１と、ＵＩ部２０２と、制御部２０３とは、端末２０のプロセッサ１１が、記憶装置１２に記憶されたプログラムを実行することにより実現することができる。また、当該プログラムは、記憶媒体に格納することができる。当該プログラムを格納した記憶媒体は、コンピュータ読み取り可能な非一時的な記憶媒体であってもよい。非一時的な記憶媒体は特に限定されないが、例えば、ＵＳＢメモリ又はＣＤ－ＲＯＭ等の記憶媒体であってもよい。

記憶部２００は、制御部２０３がゲームを実行するために必要なゲームデータを記憶する。ゲームデータには、画像データ、ゲームシナリオ等が格納される。

通信部２０１は、通信ＩＦ１３を用いてゲームサーバ１０との間で各種の通信を行う機能を有する。

ＵＩ部２０２は、ユーザから各種の入力を受け付ける処理と、ディスプレイに各種のゲーム画面を表示させる機能とを有する。また、ＵＩ部２０２は、ゲームサーバ１０の指示に従い、端末２０の出力デバイス１５（ディスプレイ）にゲーム画面を表示する。

制御部２０３は、ゲームサーバ１０と連携することで、ゲームを実行するために必要な各種の機能を提供する。例えば、制御部２０３は、ゲーム画面に描画するための各種の情報（アイコン画像データ、テキストデータ等）をゲームサーバ１０から取得する機能等を提供する。

以上説明した機能ブロック構成について、ゲームサーバ１０に含まれる記憶部１００と、制御部１０１と、表示制御部１０２と、グループ制御部１０３と、募集制御部１０４とのうち全部又は一部を、端末２０の記憶部２００又は制御部２０３に備える構成とするようにしてもよい。すなわち、本実施形態に係る各種処理は、ゲームサーバ１０で実行してもよいし、端末２０で実行してもよいし、ゲームサーバ１０及び端末２０が連携して実行してもよい。

＜処理手順＞
続いて、ゲームシステム１が行う具体的な処理手順を説明する。以下の説明では、デッキの編成に用いられる「ゲーム媒体」及びクエストクリア時に入手できる「ゲーム媒体」は、それぞれキャラクタであるものとして説明する。

ここで、ゲームサーバ１０の記憶部１００は、各ユーザのゲームデータを管理するユーザ管理ＤＢ（Data Base）１００ａ、ユーザグループに関するデータを管理するユーザグループ管理ＤＢ１００ｂ、及び、各ユーザが所有するキャラクタに関するデータを管理する所有キャラクタ管理ＤＢ１００ｃを格納する。

図５は、ユーザ管理ＤＢ１００ａ及びユーザグループ管理ＤＢ１００ｂの一例を示す図である。ユーザ管理ＤＢ１００ａは、例えば、ユーザを一意に識別する識別子（ユーザＩＤ）、ゲーム内でユーザ名として使用されるニックネーム、ユーザと所定の関係（例えば友達関係）を有する他のユーザを示すフレンド登録リスト、ユーザが利用する端末２０の位置（例えば現在位置）を示す位置情報、ユーザの経験値、レベル、スタミナ、及び、ユーザが所持するポイントの数の各種パラメータ、ユーザが所持するアイテム、及び、ゲームへのログイン状況などを対応づけて格納する。オンラインは、ユーザがゲームにログインしていることを意味し、オフラインは、ユーザがゲームにログインしていないことを示す。

ユーザグループ管理ＤＢ１００ｂは、ユーザグループを一意に識別する識別子（ユーザグループＩＤ）、ユーザグループを作成したユーザの識別子（ユーザＩＤ）、ユーザグループの名称を示すユーザグループ名、ユーザグループに参加しているユーザの識別子（参加ユーザ）、ユーザグループに対応づけられるタグ、及び、ユーザグループ内で現在行われている若しくは過去に行われたマルチプレイに関する実行履歴を対応づけて格納する。

タグは、例えば、予め定められた複数のカテゴリの中から選択された１以上のカテゴリや、任意の文字列であるキーワードが含まれていてもよい。カテゴリ名は、例えば、期間限定でプレイ可能なクエストの名称や、ゲーム内で用いられている用語など、ゲームをプレイするユーザの興味がありそうな内容であってもよい。

マルチプレイの実行履歴は、マルチプレイが実行中であるのか若しくは既に終了しているのかを示す情報、参加ユーザのユーザＩＤ、プレイ中のクエスト又はプレイしたクエストを識別する情報（クエストの識別子等）、及び、クエストの実行日時（クエスト開始時刻及び終了時刻等）等を格納する。

図６は、所有キャラクタ管理ＤＢ１００ｃの一例を示す図である。所有キャラクタ管理ＤＢ１００ｃは、ユーザを一意に識別する識別子（ユーザＩＤ）、キャラクタを一意に識別する識別子（キャラクタＩＤ）、キャラクタの強さを示す各種パラメータ（レベル、ラック（運）、ＨＰ（ヒットポイント）、攻撃力、スピード等）等が格納される。MAXは、パラメータ値が上限値であることを示す。ここで、キャラクタのパラメータは、値が大きいほど、キャラクタが強力であることを意味するものであり、同一のキャラクタを合成することで増加させることが可能であってもよい。つまり、キャラクタを繰り返し合成するほど、より強力なキャラクタを生成することが可能であってもよい。なお、同一のキャラクタとは、例えば、少なくともキャラクタの識別子若しくはキャラクタの名称が同一であるキャラクタを意味してもよい。つまり、キャラクタＩＤやキャラクタ名称が同一であれば、パラメータ値が異なっていても同一のキャラクタであるとみなされてもよい。

（ユーザグループの作成）
図７は、ユーザがユーザグループを作成する際の処理手順の一例を示すフローチャートである。

ステップＳ１０で、グループ制御部１０３は、ユーザグループの作成を希望するユーザから、新規ユーザグループの作成指示を受け付ける。ステップＳ１１で、グループ制御部１０３は、ユーザに対し、新規ユーザグループの作成を許可するか否かを判定する。例えば、ユーザ毎に作成可能なユーザグループ数の上限が定められている場合、グループ制御部１０３は、上限を超える数のユーザグループの作成を許容しないようにしてもよい。

ステップＳ１２で、グループ制御部１０３は、ユーザグループの作成を許可する場合、新規ユーザグループを作成し、ユーザグループ管理ＤＢ１００ｂに新たなレコードを登録する。ステップＳ１３で、グループ制御部１０３は、ユーザグループの作成を許可しない場合、グループ制御部１０３は、ユーザに対し、ユーザグループの作成をすることができないことを通知し、処理を終了する。

（ユーザグループへの参加）
図８は、ユーザがユーザグループに参加する際の処理手順の一例を示すフローチャートである。

ステップＳ２０で、グループ制御部１０３は、ユーザからユーザグループの検索条件を含む、検索要求を受付けると、ユーザグループ管理ＤＢ１００ｂにアクセスし、検索条件に合致するユーザグループに関するデータ（ユーザグループ名、所属ユーザ数等）を取得する。検索条件には、ユーザが指定又は入力したタグが含まれている。

ステップＳ２１で、表示制御部１０２は、取得したユーザグループに関するデータを、ユーザが指定可能なユーザグループの一覧として、端末２０の画面に表示させる。また、グループ制御部１０３は、画面に表示された、ユーザが指定可能なユーザグループの一覧の中から、ユーザが参加を希望するユーザグループの指定を受け付ける。

ステップＳ２２で、グループ制御部１０３は、ユーザグループ管理ＤＢ１００ｂにアクセスし、指定されたユーザグループのレコードの「参加ユーザ」に、ユーザを追加する。

図９は、ユーザグループに参加する際の画面表示例を示す図である。検索タグ一覧画面Ｍ１００で、検索するタグが指定されると、グループ制御部１０３は、ユーザグループ管理ＤＢ１００ｂの「タグ」を検索し、指定されたタグを含む１以上のユーザグループを抽出する。抽出されたユーザグループは、ユーザグループ一覧画面Ｍ１０１に表示される。ユーザグループ一覧画面Ｍ１０１には、所属しているユーザの人数、所属可能なユーザの上限数、ユーザグループ名及びタグ（カテゴリ及びキーワード）等が、ユーザグループごとに並べて表示される。検索タグ一覧画面Ｍ１００には、検索するタグが予め表示されているが、検索するタグを示す任意の文字列が入力可能であってもよい。

続いて、ユーザグループ一覧画面Ｍ１０１で、ユーザが参加したいユーザグループが選択されると、ユーザグループ詳細画面Ｍ１０２に遷移する。ユーザグループ詳細画面Ｍ１０２には、ユーザグループを作成したユーザ、ユーザグループに参加しているユーザの詳細等が表示される。ユーザグループ詳細画面Ｍ１０２で「はい」が押下されると、グループ制御部１０３は、ユーザグループ管理ＤＢ１００ｂの「参加ユーザ」にユーザを追加する。

（ユーザグループ内でのマルチプレイ）
図１０は、ユーザグループ内でマルチプレイを行う際の処理手順の一例を示すフローチャートである。ステップＳ３０で、募集制御部１０４は、マルチプレイを募集するユーザ（すなわちホストユーザ）から、マルチプレイでプレイするクエストの指定を受け付ける。ステップＳ３１で、募集制御部１０４は、ホストユーザから、マルチプレイを募集するユーザグループの指定を受け付ける。

ステップＳ３２で、募集制御部１０４は、ユーザグループ管理ＤＢ１００ｂを参照し、指定されたユーザグループに所属するユーザ（すなわち募集対象ユーザ）を抽出する。具体的には、募集制御部１０４は、ユーザグループ管理ＤＢ１００ｂにおける指定されたユーザグループのレコードの「作成ユーザ」及び「参加ユーザ」に格納されているユーザのうち、ホストユーザ以外のユーザを、募集対象ユーザとして抽出する。続いて、募集制御部１０４は、抽出した募集対象ユーザに対し、マルチプレイに参加するユーザを募集中である旨の通知を行う。マルチプレイを募集中である旨の通知は、例えば、募集対象ユーザの端末２０に表示される「参加ユーザ募集リスト」画面等に、ユーザグループ名やホストユーザのユーザ名等を表示させることで行われてもよい。

ステップＳ３３で、募集制御部１０４は、募集対象ユーザのうち１以上のユーザ（つまりゲストユーザ）から、マルチプレイへの参加要求があった場合、ステップＳ３４に進む。一方、募集制御部１０４は、募集対象ユーザから、マルチプレイへの参加要求が無かった場合、ステップＳ３５に進む。募集制御部１０４は、ステップＳ３１の処理手順でホストユーザからユーザグループの指定を受け付けてから所定時間経過するまでの間、マルチプレイへの参加要求が無かった場合、ステップＳ３５に進むようにしてもよい。

ステップＳ３４で、制御部１０１は、ホストユーザ及びゲストユーザによるマルチプレイで、クエストを実行する。

ステップＳ３５で、募集制御部１０４は、マルチプレイが成立しなかったと判断し、マルチプレイの募集を中止して処理を終了する。このとき、募集制御部１０４（表示制御部１０２）は、募集対象ユーザの端末２０に表示される、「参加ユーザ募集リスト」画面等から、ユーザグループ名やホストユーザのユーザ名等を削除してもよい。また、募集制御部１０４は、マルチプレイが成立しなかったことを示す情報やマルチプレイが成立しなかったと判断した日時等を、ユーザグループ管理ＤＢ１００ｂの「マルチプレイ実行履歴」に格納するようにしてもよい。

図１１は、マルチプレイを募集する際の画面例を示す図である。クエスト選択画面Ｍ２００で、ホストユーザによりクエストが選択されると、マルチプレイの募集方法を指定する画面Ｍ２０１に遷移する。画面Ｍ２０１では、マルチプレイの募集方法として、物理的位置が近いフレンド関係にあるユーザを対象に募集する方法、ソーシャルネットワークサービスを介した募集方法及びユーザグループを指定した募集方法のうち１つを選択することができる。ホストユーザが、ユーザグループを指定した募集を行うために、「ユーザグループ」ボタンを押下すると、ユーザグループ指定画面Ｍ２０２に遷移する。ユーザグループ指定画面Ｍ２０２は、マルチプレイを募集するユーザグループの指定を受け付ける画面であり、指定可能なユーザグループが一覧表示される。ユーザグループ指定画面Ｍ２０２で、ホストユーザによりユーザグループが選択されると、ゲストユーザ参加状態画面Ｍ２０３に遷移する。ゲストユーザ参加状態画面Ｍ２０３には、募集対象ユーザのうち参加要求があったユーザ（ゲストユーザ）が一覧表示される。図１１の例では、ホストユーザ（aaa）が募集したマルチプレイに対し、募集対象ユーザからの参加要求がまだ無い状態を示している。募集対象ユーザからの参加要求が１以上あった後、ホストユーザが「スタート」ボタンを押下すると、マルチプレイが開始される。

ここで、ユーザグループ指定画面Ｍ２０２には、「マルチプレイの成立のし易さに関する情報」が、ユーザグループごとに表示される。例えば、図１１の例では、マルチプレイの成立のし易さに関する情報として、ユーザグループの中で最後にマルチプレイが終了してからの経過時間が表示されている。グループＡの場合、「経過時間：４８時間前」と表示されていることから、２日間マルチプレイが行われていないことを示している。一方、グループＢは、５分前にマルチプレイが行われていたことを示している。この場合、ホストユーザは、グループＡよりもグループＢ又はＣを対象にマルチプレイを募集した方が、マルチプレイが成立し易いと判断することができる。

図１２は、マルチプレイに参加する際の画面例を示す図である。募集対象ユーザの端末２０に表示されるゲーム画面Ｍ３００で、「マルチプレイ参加」ボタンが押下されると、参加ユーザを募集しているマルチプレイを一覧表示するマルチプレイ募集一覧画面Ｍ３０１に遷移する。マルチプレイ募集一覧画面Ｍ３０１には、ユーザグループを指定したマルチプレイの募集と、物理的位置が近いフレンド関係にあるユーザからのマルチプレイの募集と、ソーシャルネットワークサービスを介したマルチプレイの募集とが、それぞれ区別されて表示される。マルチプレイ募集一覧画面Ｍ３０１に表示される、ユーザグループを指定したマルチプレイの募集は、募集対象ユーザが所属しているユーザグループで、マルチプレイの募集が行われている場合に表示される。ユーザは、一覧の中から参加したいマルチプレイを指定することで、マルチプレイに参加することができる。もし、ゲーム画面Ｍ３００で「マルチ参加」ボタンが押下された場合において、参加可能なマルチプレイの募集が存在しない場合、画面Ｍ３０２に示すように、マルチプレイの募集が存在しないことを示すメッセージが表示される。

＜マルチプレイの成立のし易さに関する情報について＞
続いて、マルチプレイの成立のし易さに関する情報について複数の表示例を説明する。以下で説明する表示例は、任意に組み合わせることが可能である。

（表示例１）
表示制御部１０２は、ホストユーザからマルチプレイを募集する対象のクエスト（ゲーム）の選択を受け付けた場合に、マルチプレイの成立のし易さに関する情報として、当該選択されたクエストで入手可能なキャラクタの所持条件を満たさないユーザに関する情報を、ユーザグループごとに表示するようにしてもよい。当該選択されたクエストで入手可能なキャラクタは、例えば、当該クエストをクリアした際に、マルチプレイをした各ユーザに付与されるキャラクタであってもよい。

また、「所持条件」は、選択されたクエストで入手可能なキャラクタであって所定状態を満たしたキャラクタを所持していることであってもよい。所定状態は、例えば、同一のキャラクタを合成することで増加する所定パラメータ値が最大値であることであってもよい。

つまり、表示制御部１０２は、マルチプレイの成立のし易さに関する情報として、グループに所属する各ユーザのうち、ホストユーザが選択したクエストで入手可能なキャラクタであって、かつ、所定パラメータ値が最大値であるキャラクタを所持していないユーザの人数を、グループ毎に表示するようにしてもよい。

例えば、マルチプレイを募集するユーザＸが選択したクエストＡで入手可能なキャラクタのキャラクタ名は、キャラクタＡであると仮定する。また、ユーザＸが所属しているグループ１には、ユーザＸ以外に１０ユーザが所属しており、所定パラメータ値が最大値（ＭＡＸ）であるキャラクタＡを所持しているユーザが３ユーザ存在すると仮定する。また、ユーザＸが所属しているグループ２には、ユーザＸ以外に１３ユーザが所属しており、所定パラメータ値が最大値であるキャラクタＡを所持しているユーザが１０ユーザ存在すると仮定する。

この場合、表示制御部１０２は、ユーザＸの画面（例えば図１１のＭ２０２）に表示するマルチプレイの成立のし易さに関する情報として、グループ１については「ＭＡＸキャラ所持：７ユーザ」などと表示し、グループ２については「ＭＡＸキャラ所持：３ユーザ」などと表示するようにしてもよい。

パラメータ値が最大であるキャラクタを既に所持しているユーザは、当該キャラクタを入手して合成を行う必要がないことから、マルチプレイを希望しない可能性が高い。一方、パラメータ値が最大であるキャラクタを所持していないユーザは、合成素材として当該キャラクタを入手するためにマルチプレイへの参加を希望する可能性が高い。従って、ユーザＸは、所定パラメータ値が最大値であるキャラクタを所持していないユーザの人数が多いユーザグループを指定して、マルチプレイを募集した方が、マルチプレイが成立し易いと判断することができる。

また、他の例として、上記「所持条件」は、選択されたクエストで入手可能なキャラクタを所定数所持していることであってもよい。所定数は、例えば、同一のキャラクタを合成することで増加する所定パラメータ値を最大値にするために必要なキャラクタ数であってもよい。

つまり、表示制御部１０２は、マルチプレイの成立のし易さに関する情報として、グループに所属する各ユーザのうち、ホストユーザが選択したクエストで入手可能なキャラクタであって、かつ、当該キャラクタを所定数所持していないユーザの人数を、グループ毎に表示するようにしてもよい。

例えば、同一のキャラクタを合成することで、所定パラメータ値が１ずつ増加すると仮定する。また、所定パラメータ値の最小値は１であり最大値は９９であると仮定する。また、クエストをクリアした際に付与されるキャラクタの所定パラメータ値は１（つまり最小値）であると仮定する。この場合、キャラクタを９９体合成すると、所定パラメータ値を最大値にすることができる。従って、「所定数」は９９であってもよい。

マルチプレイを募集しているクエストで入手可能なキャラクタを所定数所持しているユーザは、当該キャラクタを合成することで、パラメータ値を最大にすることができることから、マルチプレイへの参加を希望しない可能性が高い。一方、マルチプレイを募集しているクエストで入手可能なキャラクタを所定数所持していないユーザは、更にキャラクタを集めるために、マルチプレイへの参加を希望する可能性が高い。従って、ユーザＸは、マルチプレイで入手可能なキャラクタを所定数所持していないユーザの人数が多いユーザグループを指定して、マルチプレイを募集した方が、マルチプレイが成立し易いと判断することができる。

また、上記「所定数」は１であってもよい。ゲームには、キャラクタの合成をせずに、単に多くのキャラクタを収集することを目的としてプレイするユーザが存在する。このようなユーザは、マルチプレイでプレイするクエストで入手可能なキャラクタを既に所持していると、当該クエストをプレイする必要がないことからマルチプレイへの参加を希望しない可能性が高い。そのため、「所定数」を１にすると、クエストで入手可能なキャラクタを１体も所持していないユーザの数が、ユーザグループごとに表示されることになる。従って、ユーザＸは、マルチプレイで入手可能なキャラクタを所持していないユーザの人数が多いユーザグループを指定して、マルチプレイを募集した方が、マルチプレイが成立し易いと判断することができる。

また、他の条件として、上記「所持条件」は、選択されたクエストで入手可能なキャラクタであって、ユーザが既に所持している当該キャラクタを全て合成すると、当該キャラクタの所定パラメータ値が最大値になることであってもよい。

つまり、表示制御部１０２は、マルチプレイの成立のし易さに関する情報として、グループに所属する各ユーザのうち、ホストユーザが選択したクエストで入手可能なキャラクタであって、かつ、各ユーザが既に所持している当該キャラクタを全て合成しても所定パラメータ値が最大値である当該キャラクタを生成することができないユーザの人数を、グループ毎に表示するようにしてもよい。

既に所持しているキャラクタを合成することで、パラメータ値が最大であるキャラクタを生成可能なユーザは、当該キャラクタを追加で入手する必要がないことから、マルチプレイを希望しない可能性が高い。一方、既に所持しているキャラクタを合成しても、パラメータ値が最大であるキャラクタを生成できないユーザは、当該キャラクタを更に入手するために、マルチプレイへの参加を希望する可能性が高い。従って、ユーザＸは、所既に所持しているキャラクタを合成しても、パラメータ値が最大であるキャラクタを生成できないユーザの人数が多いユーザグループを指定して、マルチプレイを募集した方が、マルチプレイが成立し易いと判断することができる。

以上説明した表示例１によれば、クエストが指定された後で、ユーザグループを指定してマルチプレイの募集が行われることから、クエストに関する情報をマルチプレイの募集に利用することが可能になる。

（表示例２）
表示制御部１０２は、ホストユーザ（第１ユーザ）からマルチプレイを募集する対象のクエスト（ゲーム）の選択を受け付けた場合に、マルチプレイの成立のし易さに関する情報として、当該選択されたクエストの参加条件を満たすユーザに関する情報をユーザグループごとに表示するようにしてもよい。クエストの参加条件は、どのような条件であってもよいが、例えば、ユーザのパラメータ（例えばレベル、経験値等）が所定値以上であることであってもよいし、若しくは、所有しているキャラクタのパラメータが所定値以上であることであってもよい。

例えば、クエストの参加条件が、レベル５０以上のユーザであるとの条件であった場合、レベル５０であるユーザが多く所属しているユーザグループの方が、レベル５０であるユーザが殆ど所属していないユーザグループよりも、マルチプレイへの参加を希望するユーザが多い可能性が高い。従って、ユーザは、参加条件を満たすユーザが多いユーザグループを指定して、マルチプレイを募集した方が、マルチプレイが成立し易いと判断することができる。

（表示例３）
表示制御部１０２は、ホストユーザ（第１ユーザ）からマルチプレイを募集する対象のクエスト（ゲーム）の選択を受け付けた場合に、マルチプレイの成立のし易さに関する情報として、当該選択されたクエストのクリア条件を満たすユーザに関する情報をユーザグループごとに表示するようにしてもよい。クエストのクリア条件は、クエストをクリア可能なユーザのレベルの最低値であり、ゲーム管理者等によりクエスト毎に予め設定されていてもよい。例えば、ユーザのパラメータ（例えばレベル、経験値等）が所定値以上であることであってもよいし、若しくは、デッキを構成するキャラクタのパラメータが所定値以上であることであってもよい。

例えば、クエストのクリア条件が、レベル５０以上に設定されていた場合、レベル５０未満のユーザは、クエストをクリアすることは困難であると判断し、マルチプレイに参加しない可能性がある。すなわち、レベル５０であるユーザが多く所属しているユーザグループの方が、レベル５０であるユーザが殆ど所属していないユーザグループよりも、マルチプレイへの参加を希望するユーザが多い可能性が高い。従って、ユーザは、クリア条件を満たすユーザが多いユーザグループを指定して、マルチプレイを募集した方が、マルチプレイが成立し易いと判断することができる。

（表示例４）
表示制御部１０２は、ホストユーザ（第１ユーザ）からマルチプレイを募集する対象のクエスト（ゲーム）の選択を受け付けた場合に、マルチプレイの成立のし易さに関する情報として、当該選択されたクエストのクリア条件を満たさないユーザに関する情報をユーザグループごとに表示するようにしてもよい。クエストのクリア条件は、表示例３と同一であるため説明を省略する。

例えば、クエストのクリア条件が、レベル５０以上に設定されていた場合、レベル５０未満のユーザは、クエストのクリアが困難と判断し、マルチプレイに参加しない可能性がある。しかしながら、ホストユーザのレベルが５０以上であった場合、レベル５０未満のユーザは、ホストユーザのヘルプがあればクエストをクリアできると考えて、マルチプレイに参加する可能性がある。従って、ユーザは、クリア条件を満たさないユーザが多いユーザグループを指定して、マルチプレイを募集した方が、マルチプレイが成立し易いと判断することができる。

（表示例５）
表示制御部１０２は、マルチプレイの成立のし易さに関する情報として、過去に、ホストユーザ（第１ユーザ）とマルチプレイをしたユーザに関する情報をユーザグループごとに表示するようにしてもよい。当該情報は、ユーザグループに所属するユーザのうち、ホストユーザ（第１ユーザ）とマルチプレイをしたユーザの人数であってもよい。

例えば、マルチプレイを募集するユーザＸと過去にマルチプレイをしたユーザの数は、グループ１には、ユーザＸ以外に５ユーザ存在し、グループ２には存在しないと仮定する。この場合、ユーザＸと過去にマルチプレイをしたユーザが多いユーザグループの方が、ーザＸと過去にマルチプレイをしたユーザが少ないユーザグループと比較して、今後も一緒にマルチプレイに参加してくれるユーザが多いと考えられる。従って、ユーザは、当該ユーザとマルチプレイをしたことがあるユーザが多いユーザグループを指定して、マルチプレイを募集した方が、マルチプレイが成立し易いと判断することができる。

（表示例６）
表示制御部１０２は、マルチプレイの成立のし易さに関する情報として、ユーザグループ内でマルチプレイが行われる頻度、ユーザグループにおいて直近で行われたマルチプレイが終了した時刻からの経過時間、若しくは、ユーザグループ内でマルチプレイが行われた履歴を、ユーザグループごとに表示するようにしてもよい。ユーザグループ内でマルチプレイが行われる頻度は、例えば、過去所定期間内にマルチプレイが行われた回数であってもよい。例えば、過去所定期間が２４時間に設定されている場合、表示制御部１０２は、現在時刻から２４時間前までにマルチプレイが行われた回数を、ユーザグループごとに表示するようにしてもよい。マルチプレイが行われた履歴は、直近で行われたマルチプレイに関する情報（開始時刻、終了時刻、ゲストユーザの数等）が所定回数分（例えば１～３回前など）含まれるものであってもよい。
高頻度でマルチプレイを行っているユーザグループの方が、マルチプレイを行う頻度が低いユーザグループよりも、マルチプレイへの参加を希望するユーザが多い可能性が高い。また、直近でマルチプレイが行われてからの経過時間が短いユーザグループの方が、長時間経過しているユーザグループよりも、マルチプレイへの参加を希望するユーザが多い可能性が高い。従って、ユーザは、マルチプレイを行う頻度が高い若しくは直近でマルチプレイが行われてからの経過時間が短い等のユーザグループを指定して、マルチプレイを募集した方が、マルチプレイが成立し易いと判断することができる。

（表示例７）
表示制御部１０２は、マルチプレイの成立のし易さに関する情報として、オンラインであるユーザ数（つまり、ゲームにログインしているユーザ数）又はオンラインであるユーザの割合（ユーザグループに所属する全ユーザのうちオンラインであるユーザの割合）を、ユーザグループごとに表示するようにしてもよい。オンラインであるユーザは、少なくとも端末２０を操作してゲーム画面を開いていると思われることから、オンラインであるユーザが多いユーザグループは、オンラインであるユーザが少ないユーザグループよりも、マルチプレイに参加するユーザが多いと考えられる。従って、ユーザは、ログインしているユーザが多いユーザグループを指定して、マルチプレイを募集した方が、マルチプレイが成立し易いと判断することができる。

（表示例８）
表示制御部１０２は、マルチプレイの成立のし易さに関する情報として、オンライン状態であり、かつ、任意のクエストをプレイ中ではないユーザの数を、ユーザグループごとに表示するようにしてもよい。「任意のクエスト」は、ホストユーザが選択したクエストに限らず、あらゆるクエストを含む意味である（以下の説明でも同様）。前述の通り、オンラインのユーザは、少なくとも端末２０を操作してゲーム画面を開いていると思われる。また、クエストをプレイ中ではないユーザは、すぐにマルチプレイに参加することが可能である。そのため、オンライン状態であり、かつ、クエストをプレイしていないユーザが多いユーザグループは、オンライン状態であるか、又は、クエストをプレイしていないユーザが少ないユーザグループよりも、マルチプレイに参加可能なユーザが多いと考えられる。従って、ユーザは、オンライン状態であり、かつ、クエストをプレイしていないユーザの数が多いユーザグループを指定して、マルチプレイを募集した方が、マルチプレイが成立し易いと判断することができる。

（表示例９）
表示制御部１０２は、マルチプレイの成立のし易さに関する情報として、ユーザグループに所属するユーザ同士で現在実行中のマルチプレイの数を、ユーザグループごとに表示するようにしてもよい。マルチプレイは、複数ユーザで実行するものであり、１人のユーザが同時に複数のマルチプレイに参加することはできない。そのため、マルチプレイが多く実行されているユーザグループは、実行中のマルチプレイが少ないユーザグループよりも、マルチプレイに参加可能なユーザが少ないと考えられる。従って、ユーザは、現在実行中のマルチプレイの数が少ないユーザグループを指定して、マルチプレイを募集した方が、マルチプレイが成立し易いと判断することができる。

（表示例１０）
表示制御部１０２は、ホストユーザ（第１ユーザ）からマルチプレイを募集する対象のクエスト（ゲーム）の選択を受け付けた場合に、マルチプレイの成立のし易さに関する情報として、当該クエストのクリアに有効なキャラクタを所持しているユーザの数を、ユーザグループごとに表示するようにしてもよい。「クエストのクリアに有効なキャラクタ」とは、デッキに組み込むことでクエストを有利に進めることが可能なキャラクタであり、例えば、クエストに対応づけられる属性と同一の属性を有するキャラクタ、クエストで登場する敵キャラクタのパラメータ値よりもパラメータ値が高いキャラクタ、クエストに出現する敵キャラクタに対して他の属性よりも多くのダメージを多く与えることが可能な属性を有するキャラクタなどであってもよい。クエストのクリアに有効なキャラクタを所持しているユーザは、当該クエストを容易にクリアできることから、マルチプレイに参加する可能性が高いと考えられる。従って、ユーザは、クエストのクリアに有効なキャラクタを所持しているユーザ数が多いユーザグループを指定して、マルチプレイを募集した方が、マルチプレイが成立し易いと判断することができる。

（表示例１１）
表示制御部１０２は、ホストユーザ（第１ユーザ）からマルチプレイを募集する対象のクエスト（ゲーム）の選択を受け付けた場合に、マルチプレイの成立のし易さに関する情報として、当該クエストを過去にクリアしたユーザの数を、ユーザグループごとに表示するようにしてもよい。当該クエストを過去にクリアしたことがあるユーザであれば、再度クエストにチャンレジする可能性がある。従って、ユーザは、クエストを過去にクリアしたユーザの数が多いユーザグループを指定して、マルチプレイを募集した方が、マルチプレイが成立し易いと判断することができる。

（表示例１２）
以上説明した各表示例に加えて、表示制御部１０２は、任意のクエストをプレイ中のユーザが所定割合以上であるグループについては、任意のクエストをプレイ中のユーザが所定割合以上であることを示す情報と、任意のクエストをプレイ中のユーザが所定割合未満になるまでの予測時間とを表示させるようにしてもよい。表示制御部１０２は、予め定められた１回のクエストの平均プレイ時間を用いて各クエストが終了する時刻を予測し、予測された各クエストが終了する時刻に基づいて、任意のクエストをプレイ中のユーザが所定割合未満になるまでの予測時間を計算するようにしてもよい。これにより、ユーザは、既にクエストをプレイ中のユーザが所定割合以上であるユーザグループ（つまり、マルチプレイが成立しにくいユーザグループ）を避けてマルチプレイを募集することが可能になる。また、ユーザは、クエストをプレイ中のユーザが所定割合以上であるユーザグループを指定したい場合であっても、クエストをプレイ中のユーザが所定割合未満になるまでの予測時間まで待機してからマルチプレイを募集することで、マルチプレイが成立しやすいようにコントロールすることが可能になる。

＜ユーザグループ指定画面について＞
次に、ホストユーザから、マルチプレイを募集するユーザグループの指定を受け付ける、ユーザグループ指定画面（例えば図１１のＭ２０２）について、複数の表示例を説明する。

（表示例Ａ）
表示制御部１０２は、ホストユーザ（第１ユーザ）が指定可能な、マルチプレイを募集するユーザグループとして、当該ホストユーザが所属するグループをユーザグループ指定画面に表示するようにしてもよい。例えば、ユーザＸが、ユーザグループ１、ユーザグループ２及びユーザグループ３に所属している場合、表示制御部１０２は、ユーザＸのユーザグループ指定画面に、ユーザグループ１、ユーザグループ２及びユーザグループ３を一覧表示してもよい。

（表示例Ｂ）
表示制御部１０２は、ホストユーザ（第１ユーザ）が所属するユーザグループに加えて、当該ホストユーザが所属していないグループのうち第１所定条件を満たすユーザグループを、ユーザグループ指定画面に表示するようにしてもよい。ホストユーザが所属していないグループのうち第１所定条件を満たすグループは、ユーザグループ指定画面に追加して表示するユーザグループであることから、以下の説明では「追加グループ」と呼ぶ。例えば、表示制御部１０２は、図１１のユーザグループ指定画面Ｍ２０２において、追加グループに該当するユーザグループのグループ名等を、ホストユーザが所属するユーザグループに加えて表示するようにしてもよい。

第１所定条件を満たすグループは、ユーザグループの活動状況を示す指標が所定値以上であるユーザグループであってもよい。当該指標は、値が大きいほど、ユーザグループが活動していることを示すこととしてもよい。

ユーザグループの活動状況を示す指標は、例えば、以下に示すＮｏ１～Ｎｏ４の指標のいずれかであってもよい。
Ｎｏ１．ユーザグループ内でマルチプレイが行われる頻度を示す指標。当該指標は、頻度が高いほど値が大きくなる。マルチプレイが行われる頻度は、表示例６の説明と同一でよい。

Ｎｏ２．ユーザグループ内でマルチプレイが最後に行われてからの経過時間を示す指標。経過時間が長いほど値が小さくなる。
Ｎｏ３．オンラインであるユーザの数又はユーザグループに所属するユーザのうちオンラインであるユーザの割合。
Ｎｏ４．オンライン状態であり、かつ、クエストをプレイ中ではないユーザの数、又は、ユーザグループに所属するユーザのうちオンライン状態であり、かつ、クエストをプレイ中ではないユーザの割合。

また、第１所定条件を満たすグループは、マルチプレイを募集すると、参加を希望するユーザが存在する可能性が高いユーザグループであってもよい。例えば、以下に示すＮｏ５～Ｎｏ１１までのユーザグループであってもよい。
Ｎｏ５．ホストユーザにより選択されたクエストで入手可能なキャラクタの所持条件を満たさないユーザの数が所定数以上、若しくは、ユーザグループに所属するユーザのうち、ホストユーザにより選択されたクエストで入手可能なキャラクタの所持条件を満たさないユーザの割合が所定割合以上であるユーザグループ。所持条件は、表示例１で説明した条件と同一でよい。

Ｎｏ６．ホストユーザにより選択されたクエストの参加条件を満たすユーザの数が所定数以上、若しくは、ユーザグループに所属するユーザのうち、ホストユーザにより選択されたクエストの参加条件を満たすユーザの割合が所定割合以上であるユーザグループ。参加条件は、表示例２で説明した条件と同一でよい。

Ｎｏ７．ホストユーザにより選択されたクエストのクリア条件を満たすユーザの数が所定数以上、若しくは、ユーザグループに所属するユーザのうち、ホストユーザにより選択されたクエストのクリア条件を満たすユーザの割合が所定割合以上であるユーザグループ。クリア条件は、表示例３で説明した条件と同一でよい。

Ｎｏ８．過去に、ホストユーザとマルチプレイをしたユーザの数が所定数以上、若しくは、ユーザグループに所属するユーザのうち、過去に、ホストユーザとマルチプレイをしたユーザの割合が所定割合以上であるユーザグループ。

Ｎｏ９．ユーザグループに所属するユーザ同士で現在実行中のマルチプレイの数が所定数以下であるユーザグループ。

Ｎｏ１０．ホストユーザにより選択されたクエストのクリアに有効なキャラクタを所持しているユーザの数が所定数以上、若しくは、ユーザグループに所属するユーザのうち、ホストユーザにより選択されたクエストのクリアに有効なキャラクタを所持しているユーザの割合が所定割合以上であるユーザグループ。クエストのクリアに有効なキャラクタは、表示例１０の説明と同一でよい。

Ｎｏ１１．ホストユーザにより選択されたクエストを過去にクリアしたユーザの数が所定数以上、若しくは、ユーザグループに所属するユーザのうち、ホストユーザにより選択されたクエストを過去にクリアしたユーザの数が所定割合以上であるユーザグループ。

また、表示例Ｂにおける、第１所定条件を満たすグループは、ホストユーザが所属するユーザグループに付与されるタグと全部又は一部が同一であるタグが付与されたユーザグループであってもよい。
以上説明した表示例Ｂによれば、ホストユーザは、自身が所属しているユーザグループに加えて、自身が所属していないユーザグループのうち活発に活動しているユーザグループを、マルチプレイを募集するユーザグループとして指定することが可能になる。

（表示例Ｃ）
表示制御部１０２は、ホストユーザが所属するユーザグループにおけるマルチプレイの成立のし易さに関する情報が、第２所定条件を満たさない場合に、追加グループをユーザグループ指定画面に表示するようにしてもよい。より具体的には、表示制御部１０２は、ホストユーザが所属するユーザグループのうち少なくとも一部のユーザグループにおけるマルチプレイの成立のし易さに関する情報が、第２所定条件を満たさない場合に、追加グループをユーザグループ指定画面に表示するようにしてもよい。若しくは、表示制御部１０２は、ホストユーザが所属する全てのユーザグループにおけるマルチプレイの成立のし易さに関する情報が、第２所定条件を満たさない場合に、追加グループをユーザグループ指定画面に表示するようにしてもよい。

マルチプレイの成立のし易さに関する情報が第２所定条件を満たさない場合とは、ユーザグループの活動状況を示す指標が所定値未満であることであってもよい。この場合、ユーザグループの活動状況を示す指標は、表示例Ｂで説明したＮｏ１～Ｎｏ４の指標と同一でよい。

また、マルチプレイの成立のし易さに関する情報が第２所定条件を満たさない場合とは、マルチプレイを募集しても、参加を希望するユーザが存在する可能性が低い（つまりマルチプレイが成立しにくい）場合であってもよい。具体的には、以下に示すＮｏ１２～Ｎｏ１８の場合であってもよい。なお、Ｎｏ１２～Ｎｏ１８は、それぞれ、上述のＮｏ５～Ｎｏ１１に対応している。
Ｎｏ１２．ホストユーザにより選択されたクエストで入手可能なキャラクタの所持条件を満たさないユーザの数が所定数未満である場合、若しくは、ユーザグループに所属するユーザのうち、ホストユーザにより選択されたクエストで入手可能なキャラクタの所持条件を満たさないユーザの割合が所定割合未満である場合。所持条件は、表示例１で説明した条件と同一でよい。

Ｎｏ１３．ホストユーザにより選択されたクエストの参加条件を満たすユーザの数が所定数未満である場合、若しくは、ユーザグループに所属するユーザのうち、ホストユーザにより選択されたクエストの参加条件を満たすユーザの割合が所定割合未満である場合。参加条件は、表示例２で説明した条件と同一でよい。

Ｎｏ１４．ホストユーザにより選択されたクエストのクリア条件を満たすユーザの数が所定数未満である場合、若しくは、ユーザグループに所属するユーザのうち、ホストユーザにより選択されたクエストのクリア条件を満たすユーザの割合が所定割合未満である場合。クリア条件は、表示例３で説明した条件と同一でよい。

Ｎｏ１５．過去に、ホストユーザとマルチプレイをしたユーザの数が所定数未満である場合、若しくは、ユーザグループに所属するユーザのうち、過去に、ホストユーザとマルチプレイをしたユーザの割合が所定割合未満である場合。

Ｎｏ１６．ユーザグループに所属するユーザ同士で現在実行中のマルチプレイの数が所定数未満である場合。

Ｎｏ１７．ホストユーザにより選択されたクエストのクリアに有効なキャラクタを所持しているユーザの数が所定数未満である場合、若しくは、ユーザグループに所属するユーザのうち、ホストユーザにより選択されたクエストのクリアに有効なキャラクタを所持しているユーザの割合が所定割合未満である場合。クエストのクリアに有効なキャラクタは、表示例１０の説明と同一でよい。

Ｎｏ１８．ホストユーザにより選択されたクエストを過去にクリアしたユーザの数が所定数未満である場合、若しくは、ユーザグループに所属するユーザのうち、ホストユーザにより選択されたクエストを過去にクリアしたユーザの数が所定割合未満である場合。

また、表示例Ｃにおける追加グループは、ホストユーザが所属するユーザグループに付与されるタグと全部又は一部が同一であるタグが付与された他のユーザグループであってもよい。
以上説明した表示例Ｃによれば、ホストユーザは、自身が所属しているユーザグループが活発に活動していない場合、自身が所属していないユーザグループのうち活発に活動しているユーザグループを、マルチプレイを募集するユーザグループとして指定することが可能になる。

（表示例Ｄ）
表示制御部１０２は、募集対象ユーザ（第２ユーザ）に対して行われたマルチプレイの募集が成立しなかった場合、ホストユーザが募集対象として指定した少なくとも１のユーザグループとは異なる他のユーザグループを、ホストユーザが指定可能なマルチプレイを募集するグループとして追加表示するようにしてもよい。マルチプレイの募集が成立しなかった場合とは、例えば図１０のステップＳ３３で説明したように、ホストユーザからマルチプレイを募集するユーザグループの指定を受け付けてから所定時間経過するまで、マルチプレイへの参加要求が無かった場合であってもよい。また、上記他のユーザグループとは、表示例Ｂで説明した追加グループと同一であってもよい。

これにより、マルチプレイの募集が成立しなかった場合であっても、ホストユーザは、他のユーザグループを指定してマルチプレイの募集をすることが可能になる。また、マルチプレイの募集が成立しなかった場合であっても、ホストユーザは、マルチプレイの募集が成立する可能性の高い他のユーザグループを指定してマルチプレイの募集をすることが可能になる。

（表示例Ｅ）
表示制御部１０２は、ホストユーザが所属するグループにおけるマルチプレイの成立のし易さに関する情報が、第２所定条件を満たさない場合に、ホストユーザに対し、ホストユーザが所属するユーザグループを、当該ホストユーザが所属していないユーザグループのうち第１所定条件を満たすユーザグループ（すなわち、表示例Ｂで説明した追加グループと同義）に変更することを推奨する情報を、端末２０の画面に表示するようにしてもよい。また、マルチプレイの成立のし易さに関する情報が第２所定条件を満たさない場合は、表示例Ｃの説明と同一でよい。

例えば、表示制御部１０２は、図１２の画面Ｍ３０２の上に、現在所属しているユーザグループに加えて／変えて、追加グループに所属することを推奨するメッセージを表示するようにしてもよい。

これにより、ユーザは、マルチプレイが成立しにくいユーザグループから、マルチプレイが成立しやすいユーザグループに所属を変更することが可能になる。

＜まとめ＞
以上説明した実施形態によれば、ゲームサーバ１０は、ユーザがマルチプレイの募集をした際に、マルチプレイが成立しにくいユーザグループに対して募集をしてしまうことを抑制するようにした。これにより、マルチプレイの募集が無駄になることを抑制することを可能とする技術を提供することが可能になる。

以上説明した実施形態は、本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。実施形態で説明したフローチャート、シーケンス、実施形態が備える各要素並びにその配置、材料、条件、形状及びサイズ等は、例示したものに限定されるわけではなく適宜変更することができる。

＜付記＞
＜付記１＞
複数のユーザが共同でゲームを行うマルチプレイを募集するグループの指定を第１ユーザから受け付ける画面に、前記マルチプレイの成立のし易さに関する情報をグループごとに表示させる表示制御部と、
前記第１ユーザが指定した少なくとも１のグループに所属する第２ユーザに対して、前記マルチプレイの募集を行う募集制御部と、
を有する情報処理装置。
付記１によれば、グループを指定したマルチプレイの募集が無駄になることを抑制することが可能になる。

＜付記２＞
前記表示制御部は、前記第１ユーザからマルチプレイを募集する対象のゲームの選択を受け付けた場合に、選択されたゲームで入手可能なゲーム媒体の所持条件を満たさないユーザに関する情報をグループごとに表示する、
付記１に記載の情報処理装置。
付記２によれば、第１ユーザは、第１ユーザが選択したゲームで入手可能なゲーム媒体の所持条件を満たさないユーザに関する情報を、グループ毎に把握した上で、マルチプレイを募集するグループの指定を行うことが可能になる。

＜付記３＞
前記表示制御部は、前記第１ユーザからマルチプレイを募集する対象のゲームの選択を受け付けた場合に、選択されたゲームの参加条件を満たすユーザに関する情報をグループごとに表示する、
付記１又は２に記載の情報処理装置。
付記３によれば、第１ユーザは、第１ユーザが選択したゲームの参加条件を満たすユーザに関する情報を、グループ毎に把握した上で、マルチプレイを募集するグループの指定を行うことが可能になる。

＜付記４＞
前記表示制御部は、過去に前記第１ユーザとマルチプレイをしたユーザに関する情報をグループごとに表示する、
付記１～３のいずれか一項に記載の情報処理装置。
付記４によれば、第１ユーザは、過去に第１ユーザとマルチプレイをしたユーザに関する情報をグループ毎に把握した上で、マルチプレイを募集するグループの指定を行うことが可能になる。

＜付記５＞
前記表示制御部は、前記第１ユーザが指定可能な前記マルチプレイを募集するグループとして、前記第１ユーザが所属するグループを前記画面に表示する、
付記１～４のいずれか一項に記載の情報処理装置。
付記５によれば、第１ユーザは、自身が所属するグループの中から、マルチプレイを募集するグループの指定を行うことが可能になる。

＜付記６＞
前記表示制御部は、前記第１ユーザが所属するグループに加えて、前記第１ユーザが所属していないグループのうち第１所定条件を満たす追加グループを前記画面に表示する、
付記５に記載の情報処理装置。
付記６によれば、第１ユーザは、自身が所属するグループ及び追加グループの中から、マルチプレイを募集するグループの指定を行うことが可能になる。

＜付記７＞
前記表示制御部は、前記第１ユーザが所属するグループにおける前記マルチプレイの成立のし易さに関する情報が、第２所定条件を満たさない場合に、前記追加グループを前記画面に表示する、
付記６に記載の情報処理装置。
付記７によれば、第１ユーザは、自身が所属するグループにおいて、マルチプレイの成立のし易さに関する情報が第２所定条件を満たさない場合に、追加グループの中から、マルチプレイを募集するグループの指定を行うことが可能になる。

＜付記８＞
前記表示制御部は、前記第２ユーザに対して行われた前記マルチプレイの募集が成立しなかった場合、前記少なくとも１のグループとは異なる他のグループを、前記第１ユーザが指定可能な前記マルチプレイを募集するグループとして表示する、
付記１～７のいずれか一項に記載の情報処理装置。
付記８によれば、第１ユーザは、マルチプレイの募集が成立しなかった場合、マルチプレイを募集したグループとは異なる他のグループの中から、マルチプレイを募集するグループの指定を行うことが可能になる。

＜付記９＞
前記募集制御部は、前記第１ユーザが指定した複数のグループの各々に所属する前記第２ユーザに対して、前記マルチプレイの募集を行う、
付記１～８のいずれか一項に記載の情報処理装置。
付記９によれば、第１ユーザは、複数のグループを指定して、マルチプレイの募集を行うことが可能になる。

＜付記１０＞
前記表示制御部は、前記第１ユーザが所属するグループにおける前記マルチプレイの成立のし易さに関する情報が、第２所定条件を満たさない場合に、前記第１ユーザに対し、前記第１ユーザが所属するグループを、前記第１ユーザが所属していないグループのうち第１所定条件を満たす追加グループに変更することを推奨する情報を前記画面に表示する、
付記１～９のいずれか一項に記載の情報処理装置。
付記１０によれば、第１ユーザは、自身が所属するグループにおいて、マルチプレイの成立のし易さに関する情報が第２所定条件を満たさない場合、所属グループを、自身が所属していない他のグループであって第１条件を満たすグループに変更することが可能になる。

＜付記１１＞
複数のユーザが共同でゲームを行うマルチプレイを募集するグループの指定を第１ユーザから受け付ける画面に、前記マルチプレイの成立のし易さに関する情報をグループごとに表示させるステップと、
前記第１ユーザが指定した少なくとも１のグループに所属する第２ユーザに対して、前記マルチプレイの募集を行うステップと、
を有する情報処理方法。
付記１１によれば、グループを指定したマルチプレイの募集が無駄になることを抑制することが可能になる。

＜付記１２＞
コンピュータが、複数のユーザが共同でゲームを行うマルチプレイを募集するグループの指定を第１ユーザから受け付ける画面に、前記マルチプレイの成立のし易さに関する情報をグループごとに表示させるステップと、
コンピュータが、前記第１ユーザが指定した少なくとも１のグループに所属する第２ユーザに対して、前記マルチプレイの募集を行うステップと、
をコンピュータに実行させるためのプログラム。
付記１２によれば、グループを指定したマルチプレイの募集が無駄になることを抑制することが可能になる。

１０…ゲームサーバ、１１…プロセッサ、１２…記憶装置、１３…通信ＩＦ、１４…入力デバイス、１５…出力デバイス、２０…端末、１００…記憶部、１００ａ…ユーザ管理ＤＢ、１００ｂ…ユーザグループ管理ＤＢ、１００ｃ…所有キャラクタ管理ＤＢ、１０１…制御部、１０２…表示制御部、１０３…グループ制御部、１０４…募集制御部、２００…記憶部、２０１…通信部、２０２…ＵＩ部、２０３…制御部

Claims (12)

1. 複数のユーザが共同でゲームを行うマルチプレイを募集するグループの指定を第１ユーザから受け付ける画面に、前記マルチプレイの成立のし易さに関する情報をグループごとに表示させる表示制御部と、
   前記第１ユーザが指定した少なくとも１のグループに所属する第２ユーザに対して、前記マルチプレイの募集を行う募集制御部と、
   を有する情報処理装置。
2. 前記表示制御部は、前記第１ユーザからマルチプレイを募集する対象のゲームの選択を受け付けた場合に、選択されたゲームで入手可能なゲーム媒体の所持条件を満たさないユーザに関する情報をグループごとに表示する、
   請求項１に記載の情報処理装置。
3. 前記表示制御部は、前記第１ユーザからマルチプレイを募集する対象のゲームの選択を受け付けた場合に、選択されたゲームの参加条件を満たすユーザに関する情報をグループごとに表示する、
   請求項１又は２に記載の情報処理装置。
4. 前記表示制御部は、過去に前記第１ユーザとマルチプレイをしたユーザに関する情報をグループごとに表示する、
   請求項１～３のいずれか一項に記載の情報処理装置。
5. 前記表示制御部は、前記第１ユーザが指定可能な前記マルチプレイを募集するグループとして、前記第１ユーザが所属するグループを前記画面に表示する、
   請求項１～４のいずれか一項に記載の情報処理装置。
6. 前記表示制御部は、前記第１ユーザが所属するグループに加えて、前記第１ユーザが所属していないグループのうち第１所定条件を満たす追加グループを前記画面に表示する、
   請求項５に記載の情報処理装置。
7. 前記表示制御部は、前記第１ユーザが所属するグループにおける前記マルチプレイの成立のし易さに関する情報が、第２所定条件を満たさない場合に、前記追加グループを前記画面に表示する、
   請求項６に記載の情報処理装置。
8. 前記表示制御部は、前記第２ユーザに対して行われた前記マルチプレイの募集が成立しなかった場合、前記少なくとも１のグループとは異なる他のグループを、前記第１ユーザが指定可能な前記マルチプレイを募集するグループとして表示する、
   請求項１～７のいずれか一項に記載の情報処理装置。
9. 前記募集制御部は、前記第１ユーザが指定した複数のグループの各々に所属する前記第２ユーザに対して、前記マルチプレイの募集を行う、
   請求項１～８のいずれか一項に記載の情報処理装置。
10. 前記表示制御部は、前記第１ユーザが所属するグループにおける前記マルチプレイの成立のし易さに関する情報が、第２所定条件を満たさない場合に、前記第１ユーザに対し、前記第１ユーザが所属するグループを、前記第１ユーザが所属していないグループのうち第１所定条件を満たす追加グループに変更することを推奨する情報を前記画面に表示する、
    請求項１～９のいずれか一項に記載の情報処理装置。
11. 複数のユーザが共同でゲームを行うマルチプレイを募集するグループの指定を第１ユーザから受け付ける画面に、前記マルチプレイの成立のし易さに関する情報をグループごとに表示させるステップと、
    前記第１ユーザが指定した少なくとも１のグループに所属する第２ユーザに対して、前記マルチプレイの募集を行うステップと、
    を有する情報処理方法。
12. コンピュータが、複数のユーザが共同でゲームを行うマルチプレイを募集するグループの指定を第１ユーザから受け付ける画面に、前記マルチプレイの成立のし易さに関する情報をグループごとに表示させるステップと、
    コンピュータが、前記第１ユーザが指定した少なくとも１のグループに所属する第２ユーザに対して、前記マルチプレイの募集を行うステップと、
    をコンピュータに実行させるためのプログラム。

Images