JP2024047381A - 情報処理装置、情報処理方法および情報処理プログラム - Google Patents

Abstract

【課題】ゲームを操作する順番になったユーザが当該順番に行うべき操作を代行する操作を、当該ユーザと異なるユーザが操作する端末から受け付け可能な情報処理装置、情報処理方法および情報処理プログラムを提供する。【解決手段】情報処理装置は、指示受付部と操作受付部とを備える。指示受付部は、ゲームを操作する順番になった第１ユーザが操作する第１端末から、第１ユーザが当該順番に行うべき操作の代行を依頼する指示を受け付ける。操作受付部は、第１ユーザと異なる第２ユーザに対して当該順番における操作権限を付与し、操作権限が付与された第２ユーザが操作する第２端末から、代行する操作を受け付ける。【選択図】図４

Description

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

従来、オンラインゲーム等のゲームにおいて、ユーザ（プレイヤ）が、所有している複数のキャラクタの中から選択したキャラクタでデッキを編成し、編成したデッキを用いてクエストをクリアすることで、新たなキャラクタやアイテムを入手することができるゲームが知られている。クエストは、複数のユーザにより共同で実行することができる（以下、マルチプレイという）。

マルチプレイでは、各ユーザは、デッキを編成する複数のキャラクタのうち、自身に割り当てられたキャラクタを操作する。例えば、デッキはキャラクタＡ～Ｄから編成されており、キャラクタＡはユーザＵ１に割り当てられ、キャラクタＢ～Ｄは、それぞれ他のユーザＵ２～Ｕ４に割り当てられていると仮定する。この場合、ユーザＵ１がキャラクタＡを操作し終わった後、ユーザＵ２がキャラクタＢを操作し、次にユーザＵ３がキャラクタＣを操作するといったように、デッキを編成するキャラクタＡ～Ｄを、各ユーザが順番に操作していく。

特許文献１には、プレイヤが対戦相手とバトルを行うゲームにおいて、プレイヤとは異なる他プレイヤがバトルに参加した場合に、他プレイヤの攻撃力をアップさせる効果をバトルに設定し、そのバトルに設定されている効果に関連する情報を、バトルに参加可能な他プレイヤが使用する端末に表示させることが記載されている。

特開２０１９－１４８７８２号公報

しかしながら、デッキを編成するキャラクタを各ユーザが順番に操作していく従来技術においては、ゲームを操作する順番になったユーザが当該順番に行うべき操作を代行する操作を、当該ユーザと異なるユーザが操作する端末から受け付けることができないという問題があった。

本発明の目的は、ゲームを操作する順番になったユーザが当該順番に行うべき操作を代行する操作を、当該ユーザと異なるユーザが操作する端末から受け付け可能な情報処理装置、情報処理方法および情報処理プログラムを提供することである。

本発明に係る情報処理装置は、
指示受付部と操作受付部とを備え、
前記指示受付部は、ゲームを操作する順番になった第１ユーザが操作する第１端末から、前記第１ユーザが前記順番に行うべき操作の代行を依頼する指示を受け付け、
前記操作受付部は、前記第１ユーザと異なる第２ユーザに対して前記順番における操作権限を付与し、前記操作権限が付与された前記第２ユーザが操作する第２端末から、代行する操作を受け付ける。

本発明によれば、ゲームを操作する順番になったユーザが当該順番に行うべき操作を代行する操作を、当該ユーザと異なるユーザが操作する端末から受け付けることができる。

本実施形態におけるゲームシステムの構成を示す図である。 本実施形態におけるサーバのハードウェア構成を示すブロック図である。 本実施形態におけるユーザ端末のハードウェア構成を示すブロック図である。 本実施形態におけるサーバの機能構成例を示すブロック図である。 ユーザ端末の表示部に表示されるゲームプレイ画面の一例である。 ユーザ端末の表示部に表示されるゲームプレイ画面の一例である。 ユーザ端末の表示部に表示されるゲームプレイ画面の一例である。 ユーザ端末の表示部に表示されるゲームプレイ画面の一例である。 ユーザ端末の表示部に表示されるゲームプレイ画面の一例である。 ユーザ端末の表示部に表示されるゲームプレイ画面の一例である。 ユーザ端末の表示部に表示されるゲームプレイ画面の一例である。 ユーザ端末の表示部に表示されるゲームプレイ画面の一例である。 サーバが行う処理の一例を示すフローチャートである。

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

（ゲームシステム１の構成）
図１は、本実施形態におけるゲームシステム１の構成を示す。図１に示すゲームシステム１は、サーバ１０（ゲームサーバ）と、複数のユーザ端末２０（ユーザ端末２０ａ、ユーザ端末２０ｂ、ユーザ端末２０ｃ、ユーザ端末２０ｄ）とを備える。サーバ１０およびユーザ端末２０は、インターネット、イントラネット、無線ＬＡＮまたは移動通信等の通信回線５を介して互いに通信可能に接続されている。なお、サーバ１０は、本発明の「情報処理装置」として機能する。

本実施形態において、ユーザ端末２０ａ、ユーザ端末２０ｂ、ユーザ端末２０ｃ、ユーザ端末２０ｄを使用するユーザをそれぞれユーザＵ１、ユーザＵ２、ユーザＵ３、ユーザＵ４とする。ユーザＵ１、ユーザＵ２、ユーザＵ３、ユーザＵ４をそれぞれ区別する必要がない場合は、ユーザＵ１、ユーザＵ２、ユーザＵ３、ユーザＵ４をそれぞれユーザＵと表現する。

また、ユーザ端末２０ａ、ユーザ端末２０ｂ、ユーザ端末２０ｃ、ユーザ端末２０ｄをそれぞれ区別する必要がない場合は、ユーザ端末２０ａ、ユーザ端末２０ｂ、ユーザ端末２０ｃ、ユーザ端末２０ｄをそれぞれユーザ端末２０と表現する。

なお、ゲームシステム１が備えるユーザ端末２０の数は４つに限られず、少なくとも１つ以上のユーザ端末２０を備えていれば良い。

ユーザ端末２０は、例えばスマートフォンやタブレット端末等の情報処理端末であり、ユーザＵにゲームを提供する。ユーザＵは、ユーザ端末２０を操作することによって、ゲームにログインして当該ゲームを実行することができる。ユーザ端末２０は、例えば携帯電話機、パーソナルコンピュータ（ＰＣ）、ノートＰＣ、携帯情報端末（ＰＤＡ:Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、家庭用ゲーム機器等、どのような端末が用いられても良い。ユーザ端末２０は、ＧＰＳ(Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ)等を用いて検出した自身の位置をサーバ１０に通知するようにしても良い。

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

（ゲーム概要）
次に、ゲームシステム１が提供するゲームの概要を説明する。ゲームシステム１が提供するゲームでは、ユーザＵは、所有している複数のキャラクタの中から選択したキャラクタでデッキを編成し、編成したデッキを用いてクエストをクリアすることで、新たなキャラクタやアイテムを入手することができる。

ユーザＵは、入手した複数のキャラクタを合成することでより強いキャラクタに成長させたり、アイテムを用いてキャラクタの属性を強化したりすることで、より難易度の高いクエストに挑戦することができる。

ここで、クエストとは、予め定められた一定の条件を満たすことでクリア可能な課題を意味する用語である。クエストは、一般的には、探索、課題およびミッションと呼ばれることもある。クエストに参加したユーザＵは、当該一定の条件を満たすことでクエストをクリアすることができ、クエストをクリアすると、ユーザＵにクリア報酬が付与されたり、本ゲームのストーリーが進行したりする。

デッキとは、複数のキャラクタを組み合わせたグループを意味する用語である。ユーザＵは、クエストを実行する際、当該クエストをクリアするために適した能力を持つキャラクタを選択してデッキを編成してクエストを実行する。本実施形態では、ユーザＵがクエスト等を「実行」することを、「クエストプレイ」と称しても良い。敵キャラクタとのバトル（戦闘）時においては、ユーザＵのキャラクタが先攻、敵キャラクタが後攻になり、１回ずつ交替で攻撃を行っていく（ターン制）。

本実施形態のゲームは、複数のユーザＵが各々のユーザ端末２０を操作して共同してプレイすることが可能なマルチプレイゲームである。すなわち、ユーザＵは、単独プレイ（ソロプレイ）することは勿論、他のユーザＵと共に共通のクエストを同時にプレイする所謂マルチプレイ（共同プレイともいう）も可能である。マルチプレイでは、各ユーザＵは、デッキを編成する複数のキャラクタのうち、自身に割り当てられたキャラクタを操作する。

例えば、デッキはキャラクタＡ～Ｄから編成されており、キャラクタＡはユーザＵ１に割り当てられ、キャラクタＢ～Ｄは、それぞれ他のユーザＵ２～Ｕ４に割り当てられていると仮定する。この場合、ユーザＵ１がキャラクタＡを操作し終わった後、ユーザＵ２がキャラクタＢを操作し、次にユーザＵ３がキャラクタＣを操作するといったように、デッキを編成するキャラクタＡ～Ｄを、各ユーザＵが順番に操作していく（ターン性）。

このマルチプレイでは、特定のクエストに対してマルチプレイを主催して仲間を募集するユーザＵ（以下、ホストユーザという）と、その募集に応募してマルチプレイに参加するユーザＵ（以下、ゲストユーザという）とにより、共同関係が形成され、プレイの進行がマルチプレイを行うユーザＵ（ホストユーザ、ゲストユーザ）間で同期される。なお、ユーザＵ（ホストユーザ）は、メッセージアプリを介し、他のユーザＵ（ゲストユーザ候補）に対して招待メッセージを送ることによって、当該他のユーザＵをマルチプレイに直接誘うこともできる。

マルチプレイは、各ユーザＵのユーザ端末２０の通信機能を通じて行われる。一例としては、あるゲストユーザが、マルチプレイを主催して仲間を募集するホストユーザとのマッチング要求を行い、その要求に応じて表示された１以上のホストユーザを確認する。そして、ゲストユーザは、所望のホストユーザが募集するマルチプレイに対して参加の申込を行い、ホストユーザがその申込を許可すると、ゲストユーザとホストユーザとの間にマルチプレイ用の通信経路が確立される。なお、マルチプレイの申込資格は、特に限定されず、任意に設定することができる。例えば、申込みを行うゲストユーザから所定距離の範囲内に居るホストユーザの募集に対して申込を行うことができるとしても良いし、あるユーザＵと交友関係がある他のユーザＵであって、ユーザＵ同士で互いに承認したフレンド（ゲストユーザ）が申込を行うことができるとしても良い。

その後、マルチプレイに要する各種データの送受信が、公知の通信方式にしたがって実施される。このときのデータは、サーバ１０を介したクライアント・サーバ方式であっても良く、サーバ１０を介さないＰ２Ｐ（ピア・ツー・ピア）方式であっても良い。また、マルチプレイの様式は、完全同期型および非同期型に分類されるが、何れの様式を採用しても良い。

なお、マルチプレイゲームには、複数のユーザＵが協力する協力プレイゲーム、および、ユーザＵ同士が対戦する対戦ゲームが含まれるが、何れのタイプであっても良い。また、一回のマルチプレイにおけるユーザＵ数の上限（最大プレイ人数）については、特に限定されず任意の数に設定しても良いが、例えば最大で４人程度に設定するのが良い。

本実施形態では、マルチプレイにおけるクエストの実行時（一例としては、敵キャラクタとのバトル時）、例えばゲーム仕様に詳しくなかったり、キャラクタの操作に不慣れであったりするために攻撃の仕方に困ったユーザＵは、自身の順番（所定の期間、ターン）に行うべき操作の代行を、マルチプレイに参加している他のユーザＵに依頼することができる。その依頼後の所定時間（例えば、１０秒間）内に、操作の代行依頼が他のユーザＵに受け入れられた場合、最も早く受け入れた他のユーザＵに対して上記順番における操作権限が付与される。その結果、他のユーザＵは、操作権限が付与された上記順番において、代行する操作を行うことができる。なお、所定時間内に操作の代行依頼が他のユーザＵに受け入れられなかった場合には、操作の代行を依頼したユーザＵ自身で上記順番における操作を行うこととなる。

代行する操作を行った他のユーザに対しては、代行に関連付けられた報酬が付与される。報酬は、ゲーム内でユーザＵが利用可能なオブジェクトであり、例えばキャラクタおよびアイテム等が該当する。なお、報酬として付与されるアイテムには、ゲーム内通貨が含まれ、ゲーム内通貨には、ゲーム内で所定のイベントを実施するために必要なゲーム内通貨が含まれ、ゲーム内通貨を用いて実施できるイベントには、キャラクタ等を入手することができる抽選イベントが含まれる。

（サーバ１０のハードウェア構成）
図２は、本実施形態におけるサーバ１０のハードウェア構成を示すブロック図である。図２に示すように、サーバ１０は、制御部１１、記憶部１２、通信部１３、操作入力部１４およびモニタ１５を備えて構成される。

制御部１１は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、マイクロプロセッサ、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）等であり、サーバ１０の全体の動作を制御する。

記憶部１２の一部は、例えば、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）やＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等で構成されており、制御部１１による各種プログラムに基づく処理の実行時のワークエリア等として用いられる。

また、記憶部１２の一部は、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）等の不揮発性メモリまたはＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）であり、各種データおよび制御部１１の処理に利用されるプログラム等を保存する。記憶部１２は、各種情報および処理結果等を記録しておくための１以上のテーブル等を含むデータベースを保持することが可能である。

記憶部１２に記憶されるプログラムは、例えば、サーバ１０の基本的な機能を実現するためのＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）、各種ハードウェアを制御するためのドライバ、各種機能を実現するためのプログラム等であって、本発明の「情報処理プログラム」として機能するプログラムを含む。

通信部１３は、例えばＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃｏｎｔｒｏｌｌｅｒ）であり、通信回線５に接続する機能を有する。なお、通信部１３は、ＮＩＣに代えて、またはＮＩＣと共に、無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）に接続する機能、無線ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）に接続する機能、例えばＢｌｕｅｔｏｏｔｈ（登録商標）等の近距離の無線通信、および赤外線通信等を可能とする機能を有しても良い。サーバ１０は、通信回線５を介してユーザ端末２０等と接続され、ユーザ端末２０等との間で各種データの送受信を行うことができる。

操作入力部１４は、キーボードおよびマウス等で構成され、サーバ１０を使用するユーザによる各種操作の入力を受け付ける。モニタ１５は、例えば液晶ディスプレイ装置等であり、各種画像を表示する。

制御部１１、記憶部１２、通信部１３、操作入力部１４およびモニタ１５は、システムバス１６を介して相互に電気的に接続されている。したがって、制御部１１は、記憶部１２へのアクセス、モニタ１５に対する画像の表示、ユーザによる操作入力部１４に対する操作状態の把握、および通信部１３を介した各種通信網やユーザ端末２０へのアクセス等を行うことができる。

（ユーザ端末２０のハードウェア構成）
図３は、本実施形態におけるユーザ端末２０のハードウェア構成を示すブロック図である。図３に示すように、ユーザ端末２０は、制御部２１、記憶部２２、通信部２３、表示部２４、スピーカ２５、マイク２６、カメラ２７および操作ボタン２８等を備えて構成される。なお、ユーザ端末２０は、振動部やその他のセンサを有する端末であっても良い。

制御部２１は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、マイクロプロセッサ、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）等であり、ユーザ端末２０の全体の動作を制御する。

記憶部２２の一部は、例えば、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）やＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等で構成されており、制御部２１による各種プログラムに基づく処理の実行時のワークエリア等として用いられる。

また、記憶部２２の一部は、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）等の不揮発性メモリまたはＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）であり、各種データおよび制御部２１の処理に利用されるプログラム等を保存する。記憶部２２は、各種情報および処理結果等を記録しておくための１以上のテーブル等を含むデータベースを保持することが可能である。

記憶部２２に記憶されるプログラムは、例えば、ユーザ端末２０の基本的な機能を実現するためのＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）、各種ハードウェアを制御するためのドライバ、各種機能を実現するためのプログラム等を含む。

通信部２３は、例えばＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃｏｎｔｒｏｌｌｅｒ）であり、通信回線５に接続する機能を有する。なお、通信部２３は、ＮＩＣに代えて、またはＮＩＣと共に、無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）に接続する機能、無線ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）に接続する機能、例えばＢｌｕｅｔｏｏｔｈ（登録商標）等の近距離の無線通信、および赤外線通信等を可能とする機能を有しても良い。ユーザ端末２０は、通信回線５を介してサーバ１０や他のユーザ端末２０等と接続され、サーバ１０や他のユーザ端末２０等との間で各種データの送受信を行うことができる。

表示部２４は、タッチパネルディスプレイ等であり、画像等を表示し、ユーザＵによる操作を受け付けることが可能である。

スピーカ２５は、制御部２１の制御を受けて各種の音を出力する。マイク２６は、制御部２１の制御を受けて各種の音を入力する。カメラ２７は、制御部２１の制御を受けて被写体を撮像する。

操作ボタン２８は、ユーザ端末２０の例えば側面等に設けられ、ユーザ端末２０を起動または停止させるための電源ボタンや、スピーカ２５から出力される音のボリューム（音量）を調整するためのボタン等である。

制御部２１、記憶部２２、通信部２３、表示部２４、スピーカ２５、マイク２６、カメラ２７および操作ボタン２８は、システムバス２９を介して相互に電気的に接続されている。したがって、制御部２１は、記憶部２２へのアクセス、表示部２４に対する画像の表示、ユーザＵによるタッチパネルディスプレイ（表示部２４）や操作ボタン２８に対する操作状態の把握、マイク２６への音の入力、スピーカ２５からの音の出力、カメラ２７に対する制御、および通信部２３を介した各種通信網、サーバ１０や他のユーザ端末２０等へのアクセス等を行うことができる。

図４は、本実施形態におけるサーバ１０が備える制御部１１の機能構成例を示すブロック図である。図４に示すように、制御部１１は、機能構成として、受付部１１ａ、ゲームプレイ制御部１１ｂ、指示受付部１１ｃ、操作受付部１１ｄおよび表示制御部１１ｅを備える。なお、一般的にサーバ１０の制御部１１は、上記以外にも種々の機能を有しているが、ここでは、本実施形態におけるゲームシステム１において特徴的な機能のみを説明することとし、その他の既知の機能等については図示および説明を省略する。

受付部１１ａは、ユーザ端末２０の表示部２４に対する第１ユーザ（例えば、ユーザＵ１）の操作を介して、第１ユーザから、ゲーム内価値（例えば、スタミナ、オーブ）を消費することによってプレイ可能なゲーム（クエスト）のプレイ要求（一例としては、複数のユーザ（例えば、ユーザＵ１、ユーザＵ２、ユーザＵ３、ユーザＵ４）によるゲームのマルチプレイ要求）を受け付ける。

ゲームプレイ制御部１１ｂは、受付部１１ａによりゲームのプレイ要求が受け付けられた場合、第１ユーザ（例えば、ユーザＵ１）を含む複数のユーザ（例えば、ユーザＵ１、ユーザＵ２、ユーザＵ３、ユーザＵ４）が参加可能なマルチプレイゲームのプレイ（一例としては、マルチプレイ）を制御する。

指示受付部１１ｃは、ゲームを操作する順番(ターン、順番がランダムに変化する場合も含む)になった第１ユーザ（例えば、ユーザＵ１）が操作する第１端末（例えば、ユーザ端末２０ａ）から、第１ユーザが上記順番に行うべき操作の代行を依頼する指示を受け付ける。なお、指示受付部１１ｃは、ゲームを操作する順番になる前に、第１ユーザ（例えば、ユーザＵ１）が操作する第１端末（例えば、ユーザ端末２０ａ）から、第１ユーザが上記順番に行うべき操作の代行を依頼する指示を受け付けても良い。

指示受付部１１ｃは、第１ユーザ（例えば、ユーザＵ１）が行うべき操作の代行が可能な（つまり、現在、自身がゲームを操作する順番でない）複数の候補ユーザ（例えば、ユーザＵ２、ユーザＵ３、ユーザＵ４）の中から第１ユーザにより選択された候補ユーザである第２ユーザ（例えば、ユーザＵ２）に代行する操作を依頼する指示を受け付ける。

指示受付部１１ｃは、複数の候補ユーザ（例えば、ユーザＵ２、ユーザＵ３、ユーザＵ４）の中の何れかを選択する指示を第１ユーザ（例えば、ユーザＵ１）から受け付けた後、第１ユーザに選択された候補ユーザ（例えば、ユーザＵ３）に代行の依頼が受け入れられなかった場合、選択された候補ユーザを除いた他の候補ユーザ（例えば、ユーザＵ２、ユーザＵ４）の中から第１ユーザにより選択された候補ユーザである第２ユーザ（例えば、ユーザＵ２）に、代行する操作を依頼する指示を受け付ける。

操作受付部１１ｄは、第１ユーザ（例えば、ユーザＵ１）に選択された第２ユーザ（例えば、ユーザＵ２）によって代行の依頼が受け入れられた場合、第２ユーザ（例えば、ユーザＵ２）に対して上記順番における操作権限を付与する。また、操作受付部１１ｄは、指示受付部１１ｃにより代行を依頼する指示が受け付けられた後、代行の依頼を自発的に受け入れた候補ユーザが存在する場合、代行の依頼を受け入れた候補ユーザである第２ユーザ（例えば、ユーザＵ２）に対して上記順番における操作権限を付与する。そして、操作受付部１１ｄは、操作権限が付与された第２ユーザが操作する第２端末（例えば、ユーザ端末２０ｂ）から、代行する操作を受け付ける。

表示制御部１１ｅは、操作の代行を依頼する指示が指示受付部１１ｃにより受け付けられた場合、第１ユーザ（例えば、ユーザＵ１）が操作する第１端末（例えば、ユーザ端末２０ａ）に対して、所定条件を満たす候補ユーザと、所定条件を満たさない候補ユーザとを識別可能に表示させる。ここで、所定条件とは、代行する操作の成功率が高い、現在プレイ中のクエストをクリアした経験がある、ユーザランクが高い（現在プレイ中のクエストをクリアした経験があるユーザが存在しない場合）、代行する操作の権限を付与されることが可能である等である。なお、代行する操作の権限を有する各候補ユーザ（例えば、ユーザＵ２、ユーザＵ３、ユーザＵ４）には、代行する操作を行うことが可能な回数に上限が設けられていても良い。その理由は、例えば連続して、上手い候補ユーザに代行する操作を行わせると、現在プレイ中のクエストの難易度が必要以上に低下してしまうためである。

表示制御部１１ｅは、操作権限が第２ユーザ（例えば、ユーザＵ２）に付与される前と、第２ユーザに付与された後との間で、上記順番において操作対象のキャラクタ（本発明の「オブジェクト」に対応）の表示態様を異ならせる。例えば、表示制御部１１ｅは、第１ユーザ（例えば、ユーザＵ１）がゲームを操作する順番において第１ユーザに第１キャラクタの操作権限がある場合に第１キャラクタを第１表示態様で表示させ、第１ユーザが代行の依頼を行って操作権限が第２ユーザに付与された場合、第１キャラクタを第２表示態様（例えば、第１表示態様より目立つ表示態様）で表示させる。なお、第２表示態様は、操作権限が付与された第２ユーザ（例えば、ユーザＵ２、ユーザＵ３、ユーザＵ４）毎に異ならせても良い。この場合、操作権限が付与された第２ユーザがユーザＵ２である場合、ユーザＵ２に対応する色（例えば、青色）で第１キャラクタを表示させ、操作権限が付与された第２ユーザがユーザＵ３である場合、ユーザＵ３に対応する色（例えば、黄色）で第１キャラクタを表示させても良い。

表示制御部１１ｅは、操作権限が第２ユーザに付与される前と、第２ユーザに付与された後との間で、上記順番において操作対象でないキャラクタ（オブジェクト）の表示態様を異ならせる。

表示制御部１１ｅは、代行する操作の依頼先の候補ユーザ（例えば、ユーザＵ２、ユーザＵ３またはユーザＵ４）を選択するのに参考になる参考情報を表示させる。参考情報は、ゲームのプレイが上手く代行する操作の成功率が高いユーザＵや、現在プレイ中のクエストを過去にクリアした経験を有するユーザＵや、マルチプレイゲームに参加している複数のユーザＵの中で最もユーザランクが高いユーザＵ等に関連する情報である。なお、参考情報は、各候補ユーザ（例えば、ユーザＵ２、ユーザＵ３ユーザＵ４）による過去の代行履歴に関する情報（例えば、代行する操作の成功率、代行する操作に対していいねボタン（図示せず）を選択したユーザの数を示すいいね数）であっても良い。また、表示制御部１１ｅは、ユーザ端末２０毎に、表示させる参考情報の内容を異ならせても良い。また、参考情報としては、例えば代行の依頼を候補ユーザが自発的に受け入れやすくする観点から、どのユーザＵがゲームのプレイが下手なのか、どのユーザＵがお勧めできないのかといったネガティブな内容より、どのユーザＵがゲームのプレイが上手いのか、どのユーザＵが現在プレイ中のクエストを過去にクリアした経験を有するのか、どのユーザＵが他のユーザＵからお勧めされているのかといったポジティブな内容とした方が望ましい。

表示制御部１１ｅは、第１ユーザ（例えば、ユーザＵ１）が操作する第１端末（例えば、ユーザ端末２０ａ）には、代行する操作の依頼先として推奨する上記参考情報を表示させ、第１ユーザ以外のユーザ（例えば、ユーザＵ２、ユーザＵ３、ユーザＵ４）が操作する端末（例えば、ユーザ端末２０ｂ、ユーザ端末２０ｃ、ユーザ端末２０ｄ）には上記参考情報を表示させない。

表示制御部１１ｅは、代行する操作が可能な複数の候補ユーザ（例えば、ユーザＵ２、ユーザＵ３、ユーザＵ４）のうち、他の候補ユーザ（例えば、ユーザＵ４）から依頼を受け入れることが推奨されている候補ユーザ（例えば、ユーザＵ２）が操作する端末（ユーザ端末２０ｂ）に、代行の依頼を受け入れることが推奨されている旨を示す情報を表示させる。

図５～図１２は、マルチプレイにおけるクエストの実行時（一例としては、敵キャラクタとのバトル時）、ユーザ端末２０の表示部２４に表示されるゲームプレイ画面の一例を示す図である。以下で説明する各画面は、サーバ１０からユーザ端末２０に送信されたゲーム画面表示データに基づいて表示される。

図５に示すように、ゲームプレイ画面には、敵キャラクタに対応する敵キャラクタ画像３０、ユーザＵ１～Ｕ４にそれぞれ割り当てられているキャラクタＡ～Ｄに対応するキャラクタ画像３１～３４、ユーザＵ１～Ｕ４にそれぞれ対応するユーザ画像４０～４３、代行依頼ボタン５０および依頼受け入れボタン５２等が表示されている。代行依頼ボタン５０は、ユーザＵが、自身の順番に行うべき操作の代行を、マルチプレイに参加している他のユーザＵに依頼するために押下可能なボタン（操作キー）である。依頼受け入れボタン５２は、ユーザＵが、マルチプレイに参加している他のユーザＵにより行われた代行の依頼を受け入れるために押下可能なボタンである。なお、代行依頼ボタン５０は、ゲームプレイを通常通りプレイしている最中や自分が操作の順番ではなく他のユーザＵが操作している順番の表示画面においては表示されないようにして良い。代行依頼ボタン５０の押下等の代行依頼のトリガーは、ユーザＵが他のユーザＵのアイコンやプレイ中の画面の所定の位置を一定時間タップするなどの所定の操作に応じて起動するようにしても良い。そうすることで、ゲームプレイの画面を代行依頼の画面によって小さく表示されるのを防止することができる。

図６は、ユーザＵ１が、自身の順番に行うべき操作の代行を他のユーザＵ２～Ｕ４に依頼するために代行依頼ボタン５０を押下した場合、ユーザ端末２０の表示部２４に表示されるゲームプレイ画面の一例を示す図である。図６に示すように、ユーザＵ１に対応するユーザ画像４０の上方位置には、ユーザＵ１が代行依頼ボタン５０を押下した旨を示す情報（一例として、「代行依頼」の文字列情報）が表示され、ユーザＵ１に割り当てられているキャラクタＡに対応するキャラクタ画像３１の下方位置には、現在キャラクタＡの操作権限がユーザＵ１に付与されている旨を示す情報（一例としては、「ユーザＵ１」の文字列情報）が表示される。マルチプレイに参加している他のユーザＵ２～Ｕ４は、図６に示すゲームプレイ画面を参照することによって、ユーザＵ１が、自身の順番に行うべき操作の代行を他のユーザＵ２～Ｕ４に依頼した旨を把握することができる。

図７は、ユーザＵ１が、ユーザＵ１が行うべき操作の代行が可能な（つまり、現在、自身がゲームを操作する順番でない）複数の候補ユーザ（ユーザＵ２、ユーザＵ３、ユーザＵ４）の中からユーザＵ２を選択した場合、ユーザＵ１（選択者）およびユーザＵ２（被選択者）が操作するユーザ端末２０ａ、ユーザ端末２０ｂの表示部２４に表示されるゲームプレイ画面の一例を示す図である。なお、ユーザＵ１は、例えばユーザＵ２に対応するユーザ画像４１を押下することによって、複数の候補ユーザ（ユーザＵ２、ユーザＵ３、ユーザＵ４）の中からユーザＵ２を代行依頼先として選択することができる。

図７に示すように、ユーザＵ２に対応するユーザ画像４１の上方位置には、複数の候補ユーザ（ユーザＵ２、ユーザＵ３、ユーザＵ４）の中からユーザＵ２が選択（指名）された旨を示す情報（一例としては、「指名」の文字列情報）が表示される。ユーザＵ２は、図７に示すゲームプレイ画面を参照することによって、複数の候補ユーザ（ユーザＵ２、ユーザＵ３、ユーザＵ４）の中から自身がユーザＵ１により代行依頼先として選択された旨を把握することができる。

図８は、ユーザＵ１が、ユーザＵ１が行うべき操作の代行が可能な（つまり、現在、自身がゲームを操作する順番でない）複数の候補ユーザ（ユーザＵ２、ユーザＵ３、ユーザＵ４）の何れかを選択する前において、ユーザＵ１が操作するユーザ端末２０ａの表示部２４に表示されるゲームプレイ画面の一例を示す図である。図８に示すように、所定条件を満たす候補ユーザ（ユーザＵ２、ユーザＵ４）と、所定条件を満たさない候補ユーザ（ユーザＵ２、ユーザＵ４）とが識別可能に表示される。

一例としては、ユーザＵ２、ユーザＵ４に対応するユーザ画像４１、４３の上方位置には、所定条件を満たす旨を示す情報（一例としては、「条件充足」の文字列情報）が表示される。その一方、所定条件を満たさないユーザＵ３に対応するユーザ画像４２の上方位置には、所定条件を満たす旨を示す情報が表示されない。なお、所定条件とは、上記したように、代行する操作の成功率が高い、現在プレイ中のクエストをクリアした経験がある、ユーザランクが高い（現在プレイ中のクエストをクリアした経験があるユーザが存在しない場合）、代行する操作の権限を付与されることが可能である等である。ユーザＵ１は、図８に示すゲームプレイ画面を参照することによって、ユーザＵ１が自身の順番に行うべき操作の代行依頼先として、複数の候補ユーザ（ユーザＵ２、ユーザＵ３、ユーザＵ４）の何れを選択するかについて好適な判断を行うことができる。

図９は、ユーザＵ２が、ユーザＵ１により行われた代行の依頼を受け入れるために依頼受け入れボタン５２を押下した場合、ユーザ端末２０の表示部２４に表示されるゲームプレイ画面の一例を示す図である。図９に示すように、ユーザＵ２に対応するユーザ画像４１の上方位置には、ユーザＵ２が代行の依頼を受け入れた旨を示す情報（一例としては、「代行受け入れ」の文字列情報）が表示され、ユーザＵ１に割り当てられているキャラクタＡに対応するキャラクタ画像３１の下方位置には、キャラクタＡについて操作権限が付与されたユーザＵ２が代行する操作を行う旨を示す情報（一例としては、「ユーザＵ２」の文字列情報）が表示される。また、ユーザＵ２に割り当てられているキャラクタＢに対応するキャラクタ画像３２の表示色がグレーに変更され、キャラクタ画像３２の下方位置には、キャラクタＢが現在の順番の操作対象外である旨を示す情報（一例としては、「操作対象外」の文字列情報）が表示される。つまり、表示制御部１１ｅは、操作権限がユーザＵ２に付与される前と、ユーザＵに付与された後との間で、本来ユーザＵ１が操作を行うべき順番において操作対象のキャラクタＡの表示態様を異ならせる。また、表示制御部１１ｅは、操作権限がユーザＵ２に付与される前と、ユーザＵ２に付与された後との間で、上記順番において操作対象でないキャラクタＢの表示態様を異ならせる。

ユーザＵ２は、図９に示すゲームプレイ画面を参照することによって、現在の順番において代行する操作の対象であるキャラクタＡと、ユーザＵ２に割り当てられているものの現在の順番において操作対象外であるキャラクタＢとを識別して把握することができる。なお、キャラクタＢは、表示されなくても良い。また、ユーザＵ２が、ユーザＵ１により行われた代行の依頼を受け入れるため、依頼受け入れボタン５２の代わりに、ユーザＵ１に割り当てられているキャラクタＡに対応するキャラクタ画像３１、または、ユーザＵ１に対応するユーザ画像４０を押下しても良い。

図１０は、ユーザＵ１が、自身の順番に行うべき操作の代行を他のユーザＵ２～Ｕ４に依頼するために代行依頼ボタン５０を押下した場合、ユーザＵ１が操作するユーザ端末２０ａの表示部２４に表示されるゲームプレイ画面の一例を示す図である。図１０に示すように、ユーザＵ２に対応するユーザ画像４１の上方位置には、代行する操作の依頼先の候補ユーザ（ユーザＵ２、ユーザＵ３、ユーザＵ４）を選択するのに参考になる参考情報として、代行する操作の依頼先としてゲームシステム１が例えば過去の代行履歴に基づいてユーザＵ２を推奨している旨を示す情報（一例としては、「システム推奨」の文字列情報）と、代行する操作の依頼先としてユーザＵ４がユーザＵ２を推奨している旨を示す情報（一例としては、「ユーザＵ４推奨」の文字列情報）とが表示される。

ユーザＵ１は、図１０に示すゲームプレイ画面を参照することによって、代行する操作の依頼先としてゲームシステム１およびユーザＵ４がユーザＵ２を推奨している旨を把握し、ユーザＵ１が行うべき操作の代行依頼先として、複数の候補ユーザ（ユーザＵ２、ユーザＵ３、ユーザＵ４）の何れを選択するかについて好適な判断を行うことができる。なお、ユーザＵ４は、ユーザＵ２に対応するユーザ画像４１を押下することによって、代行する操作の依頼先としてユーザＵ２を推奨することができる。そのため、代行依頼をしているユーザＵ以外でマルチプレイをしているユーザＵの画面には、代行依頼先として推奨するユーザＵを募集する旨の表示を出しても良い。その画面を見ることで、ユーザＵは、推奨を出すきっかけを作ることができる。また、ゲームプレイの速やかな進行を進めるために、推奨を受け付けているユーザＵの画面に推奨を受け付け可能な時間や、その時間のカウントダウンを表示しても良い。なお、所定のゲームプレイヤとしてのランクや現在、プレイ中のクエストに対するクリア履歴の有無等に応じて、代行依頼先として推奨を可能なユーザＵと推奨ができないユーザＵと切り分けるようにしても良い。そうすることで、質の低い推奨情報を受け付けないようにすることができる。

図１１は、ユーザＵ１が、自身の順番に行うべき操作の代行を他のユーザＵ２～Ｕ４に依頼するために代行依頼ボタン５０を押下した場合、ユーザＵ２が操作するユーザ端末２０ｂの表示部２４に表示されるゲームプレイ画面の一例を示す図である。図１１に示すように、ユーザＵ２に対応するユーザ画像４１の上方位置には、代行する操作の依頼先の候補ユーザ（ユーザＵ２、ユーザＵ３、ユーザＵ４）を選択するのに参考になる参考情報として、代行する操作の依頼先としてユーザＵ４がユーザＵ２を推奨している旨を示す情報（一例としては、「ユーザＵ４推奨」の文字列情報）とが表示される。ユーザＵ２は、図１１に示すゲームプレイ画面を参照することによって、代行の依頼を自発的に受け入れる動機を得ることができる。

図１２は、ユーザＵ１が、自身の順番に行うべき操作の代行を他のユーザＵ２～Ｕ４に依頼するために代行依頼ボタン５０を押下した場合、ユーザＵ３が操作するユーザ端末２０ｃの表示部２４に表示されるゲームプレイ画面の一例を示す図である。図１２に示すように、ユーザＵ２に対応するユーザ画像４１の上方位置には、図１０、１１と異なり、代行する操作の依頼先の候補ユーザ（ユーザＵ２、ユーザＵ３、ユーザＵ４）を選択するのに参考になる参考情報は表示されない。これにより、代行する操作の依頼先としてどのユーザＵが推奨されているかについてユーザＵ３は把握することができず、ユーザＵ４がユーザＵ２を推奨している、つまり操作が下手だと思われていること等により自身は推奨されていないことを知って、不快な感情をユーザＵ３に不必要に抱かせることを防止することができる。

図１３は、本実施形態において、サーバ１０が行う処理（本発明の「情報処理方法」に対応）の一例を示すフローチャートである。

まず、受付部１１ａは、ユーザ端末２０の表示部２４に対する第１ユーザ（例えば、ユーザＵ１）の操作を介して、第１ユーザから、ゲーム内価値を消費することによってプレイ可能なゲーム（クエスト）のプレイ要求、一例としては、複数のユーザ（例えば、ユーザＵ１、ユーザＵ２、ユーザＵ３、ユーザＵ４）によるゲームのマルチプレイ要求を受け付ける（ステップＳ１００）。

次に、ゲームプレイ制御部１１ｂは、第１ユーザ（例えば、ユーザＵ１）を含む複数のユーザ（例えば、ユーザＵ１、ユーザＵ２、ユーザＵ３、ユーザＵ４）が参加可能なマルチプレイゲームのプレイ（一例としては、マルチプレイ）の制御を開始する（ステップＳ１１０）。

次に、指示受付部１１ｃは、ゲームを操作する順番になった第１ユーザ（例えば、ユーザＵ１）が操作する第１端末（例えば、ユーザ端末２０ａ）から、第１ユーザが上記順番に行うべき操作の代行を依頼する指示を受け付けたか否かについて判定する（ステップＳ１２０）。判定の結果、代行を依頼する指示が受け付けられていない場合（ステップＳ１２０、ＮＯ）、処理はステップＳ１２０の前に戻る。

一方、代行を依頼する指示が受け付けられた場合（ステップＳ１２０、ＹＥＳ）、操作受付部１１ｄは、第１ユーザが行うべき操作の代行が可能な（つまり、現在、自身がゲームを操作する順番でない）複数の候補ユーザ（例えば、ユーザＵ２、ユーザＵ３、ユーザＵ４）のうち、所定時間（例えば、１０秒間）以内に代行の依頼を自発的に受け入れた候補ユーザが存在するか否かについて判定する（ステップＳ１３０）。なお、表示制御部１１ｅは、代行の依頼が候補ユーザに自発的に受け入れられていない間、所定時間（例えば、１０秒間）の残り時間をカウントダウン形式で表示させても良い。

判定の結果、代行の依頼を受け入れた候補ユーザが存在する場合（ステップＳ１３０、ＹＥＳ）、操作受付部１１ｄは、代行の依頼を受け入れた候補ユーザである第２ユーザ（例えば、ユーザＵ２）に対して上記順番における操作権限を付与する（ステップＳ１７０）。

一方、代行の依頼を受け入れた候補ユーザが存在しない場合（ステップＳ１３０、ＮＯ
）、指示受付部１１ｃは、複数の候補ユーザ（例えば、ユーザＵ２、ユーザＵ３、ユーザＵ４）の中の何れかを選択する指示を第１ユーザ（例えば、ユーザＵ１）から受け付ける（ステップＳ１４０）。なお、所定時間以内に代行の依頼を自発的に受け入れた候補ユーザが存在しない場合、操作受付部１１ｄは、ゲームプレイ制御部１１ｂ（非ユーザ）に対して上記順番における操作権限を付与し、ゲームプレイ制御部１１ｂから代行する操作を自動的に受け付けても良い。

次に、指示受付部１１ｃは、第１ユーザ（例えば、ユーザＵ１）に選択された候補ユーザである第２ユーザ（例えば、ユーザＵ２）に代行する操作を依頼する指示を受け付ける（ステップＳ１５０）。

次に、指示受付部１１ｃは、第１ユー（例えば、ユーザＵ１）ザに選択された第２ユーザ（例えば、ユーザＵ２）によって、所定時間（例えば、１０秒間）以内に代行の依頼が受け入れられたか否かについて判定する（ステップＳ１６０）。判定の結果、代行の依頼が受け入れられなかった場合（ステップＳ１６０、ＮＯ）、サーバ１０は図１２に示す処理を終了する。この場合、操作受付部１１ｄは、第１ユーザ（例えば、ユーザＵ１）と異なるユーザに対して上記順番における操作権限を付与せず、操作可能時間（例えば、３０秒間）以内に第１ユーザが操作する第１端末（例えば、ユーザ端末２０ａ）から、上記順番に行うべき操作を受け付ける。操作可能時間以内に操作が受け付けられなかった場合、上記順番における操作はスキップされる。なお、操作可能時間は、操作の代行を依頼しなかった場合より例えば所定時間（１０秒間）だけ短くしても良い。

一方、代行の依頼が受け入れられた場合（ステップＳ１６０、ＹＥＳ）、操作受付部１１ｄは、代行の依頼が受け入れられた第２ユーザ（例えば、ユーザＵ２）に対して上記順番における操作権限を付与する（ステップＳ１７０）。最後に、操作受付部１１ｄは、操作権限が付与された第２ユーザ（例えば、ユーザＵ２）が操作する第２端末（例えば、ユーザ端末２０ｂ）から操作可能時間（例えば、３０秒間）以内に、代行する操作を受け付ける（ステップＳ１８０）。操作可能時間以内に操作が受け付けられなかった場合、上記順番における操作はスキップされる。ステップＳ１８０の処理が完了することによって、サーバ１０は図１３に示す処理を終了する。

なお、図１３に示すフローチャートにおいて、代行の依頼を受け入れた候補ユーザが存在しない場合（ステップＳ１３０、ＮＯ）、サーバ１０は図１２に示す処理を終了しても良い。この場合、操作受付部１１ｄは、第１ユーザ（例えば、ユーザＵ１）と異なるユーザに対して上記順番における操作権限を付与せず、操作可能時間（例えば、３０秒間）以内に第１ユーザが操作する第１端末（例えば、ユーザ端末２０ａ）から、上記順番に行うべき操作を受け付ける。

以上詳しく説明したように、本実施形態では、サーバ１０（情報処理装置）は、指示受付部１１ｃと操作受付部１１ｄとを備える。指示受付部１１ｃは、ゲームを操作する順番になった第１ユーザ（例えば、ユーザＵ１）が操作する第１端末（例えば、ユーザ端末２０ａ）から、第１ユーザが上記順番に行うべき操作の代行を依頼する指示を受け付ける。操作受付部１１ｄは、第１ユーザと異なる第２ユーザ（例えば、ユーザＵ２）に対して上記順番における操作権限を付与し、操作権限が付与された第２ユーザが操作する第２端末（例えば、ユーザ端末２０ｂ）から代行する操作を受け付ける。

このように構成した本実施形態によれば、ゲームを操作する順番になった第１ユーザ（例えば、ユーザＵ１）が当該順番に行うべき操作を代行する操作を、第１ユーザと異なる第２ユーザ（例えば、ユーザＵ２）が操作する第２端末（例えば、ユーザ端末２０ｂ）から受け付けることができる。

なお、上記実施形態において、指示受付部１１ｃは、現在のゲームのプレイ中に代行する操作の依頼を受け入れたユーザ（例えば、前回の代行ユーザ）と異なるユーザに対して代行する操作を依頼する指示を受け付けても良い。この場合、指示受付部１１ｃは、代行の依頼後に自身（操作の代行を依頼したユーザ）で１回は操作する、他の代行ユーザを間に挟む等の所定条件を満たした場合、現在のゲームのプレイ中に代行する操作の依頼を受け入れたユーザに対して代行する操作を再び依頼する指示を受け付けても良い。

また、上記実施形態において、操作受付部１１ｄは、第２ユーザ（例えば、ユーザＵ２）に代行の依頼が受け入れられた後、第２ユーザによる代行する操作が始まる前に、ゲームをプレイするユーザ（例えば、ユーザＵ１、ユーザＵ２）が操作する端末（例えば、ユーザ端末２０ａ、ユーザ端末２０ｂ）から第２ユーザの依頼の受け入れをキャンセルさせる操作（例えば、キャンセルボタンの押下操作、他のユーザに依頼し直すためのボタンの押下操作）を受け付けても良い。これにより、例えば、第２ユーザは、代行の依頼を誤って受け取った場合、所定の操作を行うことによって、依頼の受け入れをキャンセル（解除）させることができる。また、代行の依頼を行った第１ユーザ（例えば、ユーザＵ２）は、代行の依頼が例えばゲームのプレイが下手な第２ユーザに受け入れられた場合、所定の操作を行うことによって、第２ユーザによる依頼の受け入れをキャンセル（解除）させることができる。操作受付部１１ｄは、代行の依頼のキャンセル後に第２ユーザと異なる第３ユーザ（例えば、ユーザＵ３）に第１ユーザを代行する操作の依頼が受け入れられた場合、第３ユーザに操作権限を付与しても良い。

また、上記実施形態では、マルチプレイにおけるクエストの実行時（一例としては、敵キャラクタとのバトル時）、ユーザＵが、自身の順番に行うべき操作の代行を、マルチプレイに参加している他のユーザＵに依頼する例について説明したが、本発明はこれに限らない。例えば、ソロプレイにおけるクエストの実行時（一例としては、敵キャラクタとのバトル時）、ユーザＵが、敵キャラクタの順番でなく自身の順番に行うべき操作の代行を、クエストプレイを行っていない他のユーザＵに依頼しても良い。また、マルチプレイにおけるクエストの実行時（一例としては、敵キャラクタとのバトル時）、ユーザＵが、自身の順番に行うべき操作の代行を、マルチプレイに参加していない他のユーザ（例えば、マルチプレイゲームが実況されている場合にその実況を視聴しているユーザや、現在、ゲームにログインしておらず、ユーザＵとフレンド関係にあるユーザ等）に依頼しても良い。なお、ゲームを起動しているユーザＵには、代行依頼を受け付けたらゲームのアプリケーション上に通知を出し、ゲームを起動していないユーザＵにはメールやチャット等の代行依頼をしたいユーザに対応付いている別のコミュニケーションアプリから依頼を受け付けるようにしても良い。ゲームを起動していないユーザＵには、その依頼の通知にはゲームを起動したり、ゲーム空間や直接的に移動できるＵＲＬ等のリンクが張られるようにしても良い。

また、上記実施形態では、ゲームを操作する順番になった第１ユーザ（例えば、ユーザＵ１）が、当該順番に行うべき操作の代行を依頼し、その依頼が第２ユーザ（例えば、ユーザＵ２）に受け入れられた（つまり、代行の同意が得られた）場合、第２ユーザに対して上記順番における操作権限を付与する例について説明したが、本発明はこれに限らない。例えば、ゲームを操作する順番になった第１ユーザ（例えば、ユーザＵ１）が、当該順番に行うべき操作の代行を依頼し、その依頼が第２ユーザ（例えば、ユーザＵ２）に受け入れられるか否か（つまり、代行の同意が得られたか否か）に関係なく、第２ユーザに対して上記順番における操作権限を強制的に付与しても良い。このような構成は、所有している複数のキャラクタの中から選択したキャラクタでデッキを編成し、編成したデッキを用いてクエストをクリアするゲームに限らず、例えば各ユーザに対して順番にクイズの問題が出題され、順番になった各ユーザがそれに解答していくことで進行するクイズゲームにも適用することができる。

また、上記実施形態では、代行依頼、システム推奨、ユーザＵによる推奨、操作対象のオブジェクトの表示等を文字情報で示したが、各種その他の演出で通知するようにしても良い。例えば、振動、光る演出、音が出力される、画像が付加される、色が濃くなる、または薄くなる等の演出で通知するようにしても良い。

なお、上記実施形態では、何れも本発明を実施するにあたっての具体化の一例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその要旨、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。

＜まとめ＞
［汎用課題］
本発明の目的の１つは、ゲームを操作する順番になったユーザの操作の代行を、当該ユーザと異なるユーザが行えるようにすることである。

［付記１］に対応する課題
本発明の目的の１つは、ゲームを操作する順番になった第１ユーザが当該順番に行うべき操作を代行する操作を、第１ユーザと異なる第２ユーザが操作する端末から受け付けられるようにすることである。
［付記１］本実施形態に係る情報処理装置は、ゲームを操作する順番になった第１ユーザが操作する第１端末から、第１ユーザが上記順番に行うべき操作の代行を依頼する指示を受け付ける指示受付部と、第１ユーザと異なる第２ユーザに対して上記順番における操作権限を付与し、操作権限が付与された第２ユーザが操作する第２端末から、代行する操作を受け付ける操作受付部とを備える。
上記の情報処理装置によれば、ゲームを操作する順番になった第１ユーザが当該順番に行うべき操作を代行する操作を、第１ユーザと異なる第２ユーザが操作する端末から受け付けることができる。

［付記２］に対応する課題
本発明の目的の１つは、第１ユーザが、当該第１ユーザが行うべき操作の代行が可能な複数の候補ユーザの中から選択した候補ユーザである第２ユーザに、代行する操作を依頼できるようにすることである。
［付記２］指示受付部は、複数のユーザが参加可能なマルチプレイゲームにおいて、第１ユーザが行うべき操作の代行が可能な複数の候補ユーザの中から第１ユーザにより選択された候補ユーザである第２ユーザに、代行する操作を依頼する指示を受け付ける、付記１に記載の情報処理装置。
これにより、第１ユーザは、第１ユーザが行うべき操作の代行が可能な複数の候補ユーザの中から選択した候補ユーザである第２ユーザに、代行する操作を依頼することができる。

［付記３］に対応する課題
本発明の目的の１つは、選択した候補ユーザに代行の依頼が受け入れられなかった場合でも、第１ユーザが、選択された候補ユーザを除いた他の候補ユーザの中から選択した候補ユーザである第２ユーザに、代行する操作を依頼できるようにすることである。
［付記３］指示受付部は、複数の候補ユーザの中の何れかを選択する指示を第１ユーザから受け付けた後、第１ユーザに選択された候補ユーザに依頼が受け入れられなかった場合、選択された候補ユーザを除いた他の候補ユーザの中から第１ユーザにより選択された候補ユーザである第２ユーザに、代行する操作を依頼する指示を受け付ける、付記２に記載の情報処理装置。
これにより、第１ユーザは、選択した候補ユーザに代行の依頼が受け入れられなかった場合でも、選択された候補ユーザを除いた他の候補ユーザの中から選択した候補ユーザである第２ユーザに、代行する操作を依頼することができる。

［付記４］に対応する課題
本発明の目的の１つは、第１ユーザが、所定条件を満たす候補ユーザと、所定条件を満たさない候補ユーザとを理解した上で、代行する操作を依頼する候補ユーザを選択できるようにすることである。
［付記４］所定条件を満たす候補ユーザと、所定条件を満たさない候補ユーザとを識別可能に表示させる表示制御部をさらに備える、付記２に記載の情報処理装置。
これにより、第１ユーザは、所定条件を満たす候補ユーザと、所定条件を満たさない候補ユーザとを把握した上で、代行する操作を依頼する候補ユーザを選択することができる。

［付記５］に対応する課題
本発明の目的の１つは、第１ユーザが、代行する操作の権限を有する候補ユーザと、代行する操作の権限を有しない候補ユーザとを理解した上で、代行する操作を依頼する候補ユーザを選択できるようにすることである。
［付記５］表示制御部は、代行する操作の権限を有することによって所定条件を満たす候補ユーザと、代行する操作の権限を有しないことによって所定条件を満たさない候補ユーザとを識別可能に表示させる、付記４に記載の情報処理装置。
これにより、第１ユーザは、代行する操作の権限を有する候補ユーザと、代行する操作の権限を有しない候補ユーザとを把握した上で、代行する操作を依頼する候補ユーザを選択することができる。

［付記６］に対応する課題
本発明の目的の１つは、第１ユーザが、現在のゲームのプレイ中に代行する操作の依頼を受け入れたユーザと異なるユーザに対して、代行する操作を依頼できるようにすることである。
［付記６］指示受付部は、現在のゲームのプレイ中に代行する操作の依頼を受け入れたユーザと異なるユーザに対して、代行する操作を依頼する指示を受け付ける、付記１～５の何れか１項に記載の情報処理装置。
これにより、第１ユーザは、現在のゲームのプレイ中に代行する操作の依頼を受け入れたユーザと異なるユーザに対して、代行する操作を依頼することができる。

［付記７］に対応する課題
本発明の目的の１つは、第１ユーザが、所定条件を満たす場合、現在のゲームのプレイ中に代行する操作の依頼を受け入れたユーザに対して、代行する操作を依頼できるようにすることである。
［付記７］指示受付部は、所定条件を満たす場合、現在のゲームのプレイ中に代行する操作の依頼を受け入れたユーザに対して、代行する操作を依頼する指示を受け付ける、付記６に記載の情報処理装置。
これにより、第１ユーザは、所定条件を満たす場合、現在のゲームのプレイ中に代行する操作の依頼を受け入れたユーザに対して、代行する操作を依頼することができる。

［付記８］に対応する課題
本発明の目的の１つは、第１ユーザがゲームを操作する順番において操作対象であるオブジェクトを容易に把握できるようにすることである。
［付記８］表示制御部は、操作権限が第２ユーザに付与される前と、第２ユーザに付与された後との間で、上記順番において操作対象のオブジェクトの表示態様を異ならせる表示制御部をさらに備える、付記２に記載の情報処理装置。
これにより、第１ユーザがゲームを操作する順番において操作対象であるオブジェクトを容易に把握することができる。

［付記９］に対応する課題
本発明の目的の１つは、第１ユーザがゲームを操作する順番において操作対象でないオブジェクトを容易に把握できるようにすることである。
［付記９］表示制御部は、操作権限が第２ユーザに付与される前と、第２ユーザに付与された後との間で、上記順番において操作対象でないオブジェクトの表示態様を異ならせる、付記８に記載の情報処理装置。
これにより、第１ユーザがゲームを操作する順番において操作対象でないオブジェクトを容易に把握することができる。

［付記１０］に対応する課題
本発明の目的の１つは、第２ユーザに代行の依頼が受け入れられた後、第２ユーザによる代行する操作が始まる前に、ゲームをプレイするユーザが操作する端末から第２ユーザによる代行の依頼の受け入れをキャンセルできるようにすることである。
［付記１０］操作受付部は、第２ユーザに依頼が受け入れられた後、第２ユーザによる代行する操作が始まる前に、ゲームをプレイするユーザが操作する端末から第２ユーザの依頼の受け入れをキャンセルさせる操作を受け付ける、付記１～９の何れかに記載の情報処理装置。
これにより、第２ユーザに代行の依頼が受け入れられた後、第２ユーザによる代行する操作が始まる前に、ゲームをプレイするユーザが操作する端末から第２ユーザによる代行の依頼の受け入れをキャンセルさせることができる。

［付記１１］に対応する課題
本発明の目的の１つは、代行の依頼の受け入れがキャンセルされた後に第２ユーザと異なる第３ユーザに第１ユーザを代行する操作の依頼が受け入れられた場合、第３ユーザに操作権限を付与できるようにすることである。
［付記１１］操作受付部は、キャンセル後に第２ユーザと異なる第３ユーザに第１ユーザを代行する操作の依頼が受け入れられた場合、第３ユーザに操作権限を付与する、付記１０に記載の情報処理装置。
これにより、代行の依頼の受け入れがキャンセルされた後に第２ユーザと異なる第３ユーザに第１ユーザを代行する操作の依頼が受け入れられた場合、第３ユーザに操作権限を付与することができる。

［付記１２］に対応する課題
本発明の目的の１つは、第１ユーザが、参考情報を参照した上で、代行する操作を依頼する候補ユーザを選択できるようにすることである。
［付記１２］代行する操作の依頼先の候補ユーザを選択するのに参考になる参考情報を表示させる表示制御部をさらに備える、付記２に記載の情報処理装置。
これにより、第１ユーザは、参考情報を参照した上で、代行する操作を依頼する候補ユーザを選択することができる。

［付記１３］に対応する課題
本発明の目的の１つは、代行する操作の依頼先として推奨する参考情報を真に必要とする第１ユーザに絞って、当該参考情報を把握できるようにすることである。
［付記１３］表示制御部は、第１ユーザが操作する第１端末には、代行する操作の依頼先として推奨する参考情報を表示させ、第１ユーザ以外のユーザが操作する端末には参考情報を表示させない、付記１２に記載の情報処理装置。
これにより、代行する操作の依頼先として推奨する参考情報を真に必要とする第１ユーザに絞って、当該参考情報を把握させることができる。

［付記１４］に対応する課題
本発明の目的の１つは、他の候補ユーザから代行の依頼を受け入れることが推奨されている候補ユーザに対して、代行の依頼を受け入れることを促すことができるようにすることである。
［付記１４］表示制御部は、代行する操作が可能な複数の候補ユーザのうち、他の候補ユーザから依頼を受け入れることが推奨されている候補ユーザが操作する端末に、依頼を受け入れることが推奨されている旨を示す情報を表示させる、付記１２に記載の情報処理装置。
これにより、他の候補ユーザから代行の依頼を受け入れることが推奨されている候補ユーザに対して、代行の依頼を受け入れることを促すことができる。

［付記１５］に対応する課題
本発明の目的の１つは、ゲームを操作する順番になった第１ユーザが当該順番に行うべき操作を代行する操作を、第１ユーザと異なる第２ユーザが操作する端末から受け付けられるようにすることである。
［付記１５］本実施形態に係る情報処理方法は、プロセッサが、ゲームを操作する順番になった第１ユーザが操作する第１端末から、第１ユーザが上記順番に行うべき操作の代行を依頼する指示を受け付け、プロセッサが、第１ユーザと異なる第２ユーザに対して上記順番における操作権限を付与し、操作権限が付与された第２ユーザが操作する第２端末から、代行する操作を受け付ける。
上記の情報処理方法によれば、ゲームを操作する順番になった第１ユーザが当該順番に行うべき操作を代行する操作を、第１ユーザと異なる第２ユーザが操作する端末から受け付けることができる。

［付記１６］に対応する課題
本発明の目的の１つは、ゲームを操作する順番になった第１ユーザが当該順番に行うべき操作を代行する操作を、第１ユーザと異なる第２ユーザが操作する端末から受け付けられるようにすることである。
［付記１６］本実施形態に係る情報処理プログラムは、プロセッサに、ゲームを操作する順番になった第１ユーザが操作する第１端末から、第１ユーザが上記順番に行うべき操作の代行を依頼する指示を受け付け、第１ユーザと異なる第２ユーザに対して上記順番における操作権限を付与し、操作権限が付与された第２ユーザが操作する第２端末から、代行する操作を受け付ける、処理を実行させる。
上記の情報処理プログラムによれば、ゲームを操作する順番になった第１ユーザが当該順番に行うべき操作を代行する操作を、第１ユーザと異なる第２ユーザが操作する端末から受け付けることができる。

１：ゲームシステム、１０：サーバ、１１：制御部、１１ａ：受付部、１１ｂ：ゲームプレイ制御部、１１ｃ：指示受付部、１１ｄ：操作受付部、１１ｅ：表示制御部、１２：記憶部、１３：通信部、１４：操作入力部、１５：モニタ、１６：システムバス、２０，２０ａ，２０ｂ，２０ｃ：ユーザ端末、２１：制御部、２２：記憶部、２３：通信部、２４：表示部、２５：スピーカ、２６：マイク、２７：カメラ、２８：操作ボタン、２９：システムバス、３０：敵キャラクタ画像、３１，３２，３３，３４：キャラクタ画像、４０，４１，４２，４３：ユーザ画像、５０：代行依頼ボタン、５２：依頼受け入れボタン、Ｕ，Ｕ１，Ｕ２，Ｕ３，Ｕ４：ユーザ

Claims (16)

1. 指示受付部と操作受付部とを備え、
   前記指示受付部は、ゲームを操作する順番になった第１ユーザが操作する第１端末から、前記第１ユーザが前記順番に行うべき操作の代行を依頼する指示を受け付け、
   前記操作受付部は、前記第１ユーザと異なる第２ユーザに対して前記順番における操作権限を付与し、前記操作権限が付与された前記第２ユーザが操作する第２端末から、代行する操作を受け付ける、
   情報処理装置。
2. 前記指示受付部は、複数のユーザが参加可能なマルチプレイゲームにおいて、前記第１ユーザが行うべき操作の代行が可能な複数の候補ユーザの中から前記第１ユーザにより選択された候補ユーザである前記第２ユーザに、代行する操作を依頼する指示を受け付ける、
   請求項１に記載の情報処理装置。
3. 前記指示受付部は、前記複数の候補ユーザの中の何れかを選択する指示を前記第１ユーザから受け付けた後、前記第１ユーザに選択された候補ユーザに前記依頼が受け入れられなかった場合、選択された候補ユーザを除いた他の候補ユーザの中から前記第１ユーザにより選択された候補ユーザである前記第２ユーザに、代行する操作を依頼する指示を受け付ける、
   請求項２に記載の情報処理装置。
4. 表示制御部をさらに備え、
   前記表示制御部は、所定条件を満たす候補ユーザと、前記所定条件を満たさない候補ユーザとを識別可能に表示させる、
   請求項２に記載の情報処理装置。
5. 前記表示制御部は、代行する操作の権限を有することによって前記所定条件を満たす候補ユーザと、代行する操作の権限を有しないことによって前記所定条件を満たさない候補ユーザとを識別可能に表示させる、
   請求項４に記載の情報処理装置。
6. 前記指示受付部は、現在の前記ゲームのプレイ中に代行する操作の依頼を受け入れたユーザと異なるユーザに対して、代行する操作を依頼する指示を受け付ける、
   請求項１に記載の情報処理装置。
7. 前記指示受付部は、所定条件を満たす場合、現在の前記ゲームのプレイ中に代行する操作の依頼を受け入れたユーザに対して、代行する操作を依頼する指示を受け付ける、
   請求項６に記載の情報処理装置。
8. 表示制御部をさらに備え、
   前記表示制御部は、前記操作権限が前記第２ユーザに付与される前と、前記第２ユーザに付与された後との間で、前記順番において操作対象のオブジェクトの表示態様を異ならせる、
   請求項２に記載の情報処理装置。
9. 前記表示制御部は、前記操作権限が前記第２ユーザに付与される前と、前記第２ユーザに付与された後との間で、前記順番において操作対象でないオブジェクトの表示態様を異ならせる、
   請求項８に記載の情報処理装置。
10. 前記操作受付部は、前記第２ユーザに前記依頼が受け入れられた後、前記第２ユーザによる代行する操作が始まる前に、前記ゲームをプレイするユーザが操作する端末から前記第２ユーザの前記依頼の受け入れをキャンセルさせる操作を受け付ける、
    請求項１に記載の情報処理装置。
11. 前記操作受付部は、前記キャンセル後に前記第２ユーザと異なる第３ユーザに前記第１ユーザを代行する操作の依頼が受け入れられた場合、前記第３ユーザに前記操作権限を付与する、
    請求項１０に記載の情報処理装置。
12. 表示制御部をさらに備え、
    前記表示制御部は、代行する操作の依頼先の候補ユーザを選択するのに参考になる参考情報を表示させる、
    請求項２に記載の情報処理装置。
13. 前記表示制御部は、前記第１ユーザが操作する前記第１端末には、代行する操作の依頼先として推奨する前記参考情報を表示させ、前記第１ユーザ以外のユーザが操作する端末には前記参考情報を表示させない、
    請求項１２に記載の情報処理装置。
14. 前記表示制御部は、代行する操作が可能な複数の候補ユーザのうち、他の候補ユーザから前記依頼を受け入れることが推奨されている候補ユーザが操作する端末に、前記依頼を受け入れることが推奨されている旨を示す情報を表示させる、
    請求項１２に記載の情報処理装置。
15. プロセッサが、ゲームを操作する順番になった第１ユーザが操作する第１端末から、前記第１ユーザが前記順番に行うべき操作の代行を依頼する指示を受け付け、
    プロセッサが、前記第１ユーザと異なる第２ユーザに対して前記順番における操作権限を付与し、前記操作権限が付与された前記第２ユーザが操作する第２端末から、代行する操作を受け付ける、
    情報処理方法。
16. プロセッサに、
    ゲームを操作する順番になった第１ユーザが操作する第１端末から、前記第１ユーザが前記順番に行うべき操作の代行を依頼する指示を受け付け、
    前記第１ユーザと異なる第２ユーザに対して前記順番における操作権限を付与し、前記操作権限が付与された前記第２ユーザが操作する第２端末から、代行する操作を受け付ける、
    処理を実行させる情報処理プログラム。

Images