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

Description

本発明は、第１プレイヤにより操作される第１端末と、第２プレイヤにより操作される第２端末と、当該第１端末および第２端末と接続可能なサーバとを含む情報処理システムに関し、より特定的には、予めプレイが制限されている所定のゲーム要素に関して、他のプレイヤに協力要請を行い、その承諾を得て当該制限を解除する処理が実行可能な情報処理システムに関する。

従来から、他のプレイヤからの応援依頼に応じることで報酬を得ることができる処理が知られている（例えば、特許文献１）。このような処理では、第１のプレイヤが第２のプレイヤに応援依頼を行い、第２のプレイヤがこれに応じて応援参加した場合、第２のプレイヤに所定の報酬が付与される。

特許第５４９９１３６号公報

上記の処理では、第１のプレイヤに応援依頼された第２のプレイヤは、応援（例えばバトル）に参加するだけで報酬を得ることができるものであったが、この報酬付与の方法は単純なものであり、改良の余地があった。

それ故に、本発明の目的は、協力してくれたプレイヤに対する報酬について、多彩な与え方が可能な情報処理システム等を提供することである。

上記目的を達成するために、例えば以下のような構成例が挙げられる。

構成例の一例は、第１ユーザにより操作される第１端末と、第２ユーザにより操作される第２端末と、当該第１端末および当該第２端末と接続可能なサーバとを含む情報処理システムであって、第１端末は、協力要請送信手段、制限解除手段、ゲーム要素実行手段とを備える。第２端末は、承諾送信手段を備える。サーバは、報酬付与手段を備える。協力要請送信手段は、第１プレイヤによるプレイが予め制限されている所定のゲーム要素に関する協力要請をサーバに送信する。承諾送信手段は、第２プレイヤの操作に基づいて、協力要請に対する承諾をサーバに送信する。制限解除手段は、承諾を受信した場合に、所定のゲーム要素にかかる制限を解除し、実行可能な状態とする。ゲーム要素実行手段は、第１プレイヤの操作に基づき、制限が解除された所定のゲーム要素を実行する。報酬付与手段は、制限が解除された所定のゲーム要素の実行に関する所定の条件が満たされている場合に、第１の報酬を第２プレイヤに付与し、当該所定の条件が満たされていないときには、第２の報酬を当該第２のプレイヤに付与する。
なお、上記「ゲーム要素」とは、例えば、ゲーム内で実行される処理・機能であって、ボーナスステージ、ボスステージ、隠しステージのような「○○ステージ」等と呼ばれるものや、クエストやミッション等と呼ばれるもの、所定のアイテム、技、スキル、魔法等と呼ばれるものを意図する。換言すれば、何らかの形で「開始」されるものや、何らかの形で「使用」されるような処理・機能を意図する。

上記構成例によれば、第１プレイヤからの協力要請に対して第２プレイヤからの承諾があった場合に解除される所定のゲーム要素の実行に関する所定の条件を満たしたか否かにより、第２プレイヤに第１報酬を付与したり、第２報酬を付与したりすることになる。したがって、第１プレイヤからの協力要請に応えた第２プレイヤに対する報酬の与え方に幅を持たせることができる。

他の構成例として、報酬付与手段は、第１の報酬として第２の報酬とは異なる内容の報酬を第２プレイヤに付与するようにしてもよい。更に、第１の報酬として第２の報酬よりも高い価値の報酬を第２プレイヤに付与するようにしてもよい。

上記構成例によれば、さらに第２プレイヤへの報酬の与え方に幅を持たせることができる。

他の構成例として、第１端末は、制限が解除された後のゲーム要素の実行に関する関連データをサーバに送信する関連データ送信手段をさらに備えていてもよい。そして、報酬付与手段は、制限が解除された所定のゲーム要素が実行されたことを示すデータを関連データとして受信した場合に、所定の条件が満たされていると判定して第１の報酬を第２プレイヤに付与し、制限が解除された所定のゲーム要素が実行されたことを示すデータを受信しなかったときには、当該所定の条件は満たされていないと判定して第２の報酬を第２プレイヤに付与するようにしてもよい。

上記構成例によれば、第２プレイヤからの承諾を得た第１プレイヤが、その後ゲーム要素を実行したのかしなかったのかに応じて、第２プレイヤへの報酬内容を変化させることができ、第２プレイヤへの報酬の与え方に幅を持たせることができる。

他の構成例として、情報処理システムは、ゲーム要素実行手段による所定のゲーム要素の実行が終了した場合に、当該所定のゲーム要素の実行を再度制限する第１再制限手段を更に備えるようにしてもよい。

上記構成例によれば、第１プレイヤが、制限されているゲーム要素の実行を希望するとき、その都度、第２プレイヤの協力を求める必要性を生じさせることができる。これにより、プレイヤ間のコミュニケーションの活性化を図ることができる。

他の構成例として、情報処理システムは、制限解除手段によって所定のゲーム要素にかかる制限を解除し、実行可能な状態となった後、所定の期間が経過した場合には、当該所定のゲーム要素の実行を再度制限する第２再制限手段をさらに備えていてもよい。

上記構成例によれば、一旦制限を解除した後、ゲーム要素を実行しなかった場合、例えばその翌日になると再度制限がかかり、再度第２のプレイヤの協力が必要な状態となる。これにより、第２のプレイヤの協力が必要となる機会を増やし、コミュニケーションの活性化を図ることができる。

他の構成例として、制限解除手段は、一定期間毎に第１の回数分、所定のゲーム要素にかかる制限の解除が可能であるように構成してもよい。

上記構成例によれば、例えば１日１回だけ、第２プレイヤの協力を得てゲーム要素の実行を可能とする、ということが実現できる。このような回数制限を設けることで、協力要請を積極的に活用させることへの動機付けを提供することができ、プレイヤ間のコミュニケーションの活性化を図ることができる。

他の構成例として、制限解除手段は、協力要請に対する複数の第２プレイヤからの承諾を受信した場合に、所定のゲーム要素にかかる制限を解除するよう構成してもよい。

上記構成例によれば、複数の第２プレイヤの協力を得る必要性を生じさせることができ、より多くのプレイヤとのコミュニケーションを促進させることができる。

他の構成例として、情報処理システムは、第１プレイヤを識別する第１識別情報と、第２プレイヤを識別する第２識別情報とを関連づけて記憶部に記憶する記憶手段をさらに備えていてもよく、協力要請送信手段は、第１プレイヤに関連づけられている第２プレイヤに対して協力要請を送信するようにしてもよい。

上記構成例によれば、例えば、第１プレイヤは、いわゆる「フレンド」を登録しておき、このフレンドに対して協力を要請することを可能とする。これにより、特定のプレイヤ同士のコミュニケーションの活性化を図ることができる。

他の構成例として、協力要請送信手段は、第１プレイヤに関連づけられている複数の第２プレイヤに対して協力要請を送信するようにしてもよい。

上記構成例によれば、第１プレイヤは複数のフレンドに対して協力要請を送ることができ、より多くの特定プレイヤ同士間のコミュニケーションの活性化を図ることができる。

他の構成例として、協力要請送信手段は、第１プレイヤから協力要請を送信する操作を受け付けたとき、その都度、複数の第２プレイヤのいずれか１人を指定させて、当該指定にかかる第２プレイヤに協力要請を送信するような構成としてもよい。

上記構成例によれば、協力要請の際に、１人毎に協力要請先の第２プレイヤを指定するため、特定のプレイヤとのコミュニケーションを促進させることができる。

他の構成例として、情報処理システムは、第１プレイヤの操作に基づいて所定のアイテムの使用が指示されたことを判別するアイテム使用判別手段を更に備えていてもよい。そして、制限解除手段は、所定のアイテムが使用された場合は、承諾の受信の有無にかかわらず、所定のゲーム要素にかかる制限を解除し、実行可能な状態とするようにしてもよい。

上記構成例によれば、所定アイテムを使用することで、承諾の有無に関わらずゲーム要素の実行が可能となるため、ゲーム要素を実行する方法に多様性を持たせることができる。すなわち、第１プレイヤに、制限されているゲーム要素を実行するための複数の選択肢を提供することができる。

他の構成例として、アイテム使用判別手段で判別される所定のアイテムは、課金アイテムであってもよい。

上記構成例によれば、課金アイテムにより制限が解除されるゲーム要素の実行を、第１プレイヤによる協力要請に対する第２プレイヤの承諾でも解除して行うことができることになるため、プレイヤ間のコミュニケーションの促進を図ることができる。

他の構成例として、情報処理システムは、ゲーム要素実行手段によるゲーム要素の実行が終了した場合に、当該ゲーム要素の実行を再度制限するゲーム要素実行再制限手段をさらに備え、制限解除手段は、一定期間毎に第２の回数分、課金アイテムの使用による所定のゲーム要素にかかる制限の解除が可能であるように構成してもよい。

上記構成例によれば、課金アイテムを利用する場合のゲーム要素を実行する方法に多様性を持たせることができる。

他の構成例として、情報処理システムは、当該ゲーム要素の実行結果に応じて、第１プレイヤに所定のアイテムを付与するアイテム付与手段をさらに備えていてもよい。

上記構成例によれば、所定のアイテムを入手するために、他のプレイヤに協力要請する必要性を生じさせることができる。これにより、プレイヤ間のコミュニケーションの活性化を図ることもできる。

本実施形態によれば、他のプレイヤの協力が必要となるゲームにおいて、協力したプレイヤに対する報酬の与え方に幅をもたせることができ、プレイヤ間のコミュニケーションの促進やゲームの興趣性の向上を図ることができる。

本実施形態の一例である情報処理システムの全体像を示す模式図 スマートデバイス１０２の構成の一例を示すブロック図 サーバ１０１の構成の一例を示すブロック図 本実施形態のゲームの画面例 本実施形態のゲームの画面例 本実施形態のゲームの画面例 本実施形態のゲームの画面例 サーバ１０１のメモリ１２３に格納されるプログラムおよびデータの一例 プレイ状況データ２１５の構成の一例 送信済み要請データ２２４のデータ構成の一例 受信要請データ２２５のデータ構成の一例 承諾済みデータ２２６のデータ構成の一例 スマートデバイス１０２のメモリ１１３に格納されるプログラムおよびデータの一例 本実施形態にかかる情報処理の詳細を示すフローチャート ボーナスステージ設定処理の詳細を示すフローチャート 承諾チェック処理の詳細を示すフローチャート 選択画面処理の詳細を示すフローチャート 協力要請処理の詳細を示すフローチャート 協力要請処理の詳細を示すフローチャート チケット使用処理の詳細を示すフローチャート ボーナスステージプレイ処理の詳細を示すフローチャート 協力要請確認処理の詳細を示すフローチャート 協力要請の更新処理の詳細を示すフローチャート 報酬付与処理の詳細を示すフローチャート

以下、本発明の一実施形態について説明する。図１は、本実施形態に係る情報処理システムの全体像を示す模式図である。本実施形態の情報処理システム１００は、サーバ１０１と、複数の端末１０２とを含んでいる。本実施形態では、端末１０２の一例として、スマートデバイスを想定する。本実施形態では、スマートデバイス１０２の一例としては、スマートフォンやタブレット機等の携帯型の情報処理端末を想定するが、据え置き型のスマートデバイスの場合でも本実施形態の処理は適用できる。サーバ１０１と、スマートデバイス１０２とは、インターネット１０３を介して通信可能に構成されている。

本実施形態では、このような構成で、情報処理が実行されるが、以下では、当該情報処理の一例として、ゲーム処理を例として説明する。具体的には、スマートデバイス上にゲームプログラムがインストールされ、サーバ１０１と適宜通信を行いながら実行されるゲーム処理である。なお、本実施形態にかかるゲーム処理では、プレイヤのプレイ状況を示すデータ自体はサーバ１０１に保存される形態を採っている。このプレイ状況を示すデータは、例えばそのプレイヤが操作するプレイヤキャラクタの情報及び所持アイテム等を示すデータであり、一例として、後述するプレイヤデータ２１３である。例えば、ゲーム開始時に、サーバ１０１へのログイン処理が行われ、プレイヤのプレイ状況を示すデータがサーバ１０１からスマートデバイス１０２上に取得され、これを用いてゲーム処理が実行される。

［サーバのハードウェア構成］
次に、上記サーバ１０１のハードウェア構成について説明する。図３は、サーバ１０１の機能ブロック図である。サーバ１０１は、プロセッサ部１２１と、メモリ１２３と、通信部１２４とを少なくとも備えている。プロセッサ部１２１は、サーバ１０１を制御するための各種プログラムを実行する。メモリ１２３には、プロセッサ部１２１によって実行される各種プログラムおよび利用される各種データが格納される。通信部１２４は、有線、または無線通信によってネットワークと接続し、上記スマートデバイス１０２または他のサーバ（図示せず）との間で所定のデータを送受信する。

［スマートデバイスのハードウェア構成］
次に、上記システムにおける各ハードウェアの構成について説明する。図２は、スマートデバイス１０２の機能ブロック図である。図２において、スマートデバイス１０２は、プロセッサ部１１１と、メモリ１１３と、通信部１１４と、操作部１１５と、表示部１１６とを備えている。プロセッサ部１１１は、後述する情報処理を実行したり、スマートデバイス１０２の全体的な動作を制御したりするためのシステムプログラム（図示せず）を実行することで、スマートデバイス１０２の動作を制御する。なお、プロセッサ部１１１は、単一のプロセッサを搭載してもよいし、複数のプロセッサを搭載するようにしてもよい。メモリ１１３は、プロセッサ部１１１によって実行される各種プログラムおよび当該プログラムで利用される各種データが格納される。メモリ１１３は、例えば、フラッシュＥＥＰＲＯＭやハードディスク装置である。通信部１１４は、有線、または無線通信によってネットワークと接続し、上記サーバ１０１との間で所定のデータを送受信する。操操作部１１５は、例えば、ユーザからの操作を受け付けるための入力装置である。表示部１１６は、典型的には液晶表示装置である。なお、本実施形態に係る処理では、操作部１１５及び表示部１１６として、液晶画面と一体化したタッチパネルを想定する。他の実施形態では、操作部１１５として、タッチパネル以外の所定のポインティングデバイスを用いてもよい。

［本実施形態の情報処理の概要］
次に、本実施形態で実行される情報処理の概要について説明する。上記のように、本実施形態では、ゲーム処理を例に説明する。以下で説明する処理は、主に、いわゆる「フレンド」に協力要請を行い、協力要請に応じてくれたプレイヤに対して報酬を付与する処理に関するものである。

なお、以下の説明では、協力要請を他のプレイヤに送る側プレイヤのことを「要請元プレイヤ」と呼び、あるプレイヤからの協力要請を受けた側プレイヤのことを「被要請プレイヤ」と呼ぶ。

まず、本実施形態で想定するゲームでは、他のプレイヤの協力を得られないと、進行あるいは利用することができないようなゲーム要素が用意されている。このようなゲーム要素の一例として、本実施形態では、複数人のプレイヤの協力が得られなければ入場することができない「ボーナスステージ」を例として説明する。

例えば、プレイヤキャラクタがボーナスステージの入り口に移動すると、協力要請画面が表示される。要請元プレイヤは、この画面を操作して、他のプレイヤに「協力要請」を送信することができる。

協力要請を受けた被要請プレイヤは、この協力要請に対して、「承諾」を行うことができる。承諾しない場合は、返答はせずにそのまま放置する。換言すれば、被要請プレイヤは、承諾を行い得る立場にあるプレイヤとも言える。また、要請元プレイヤは、承諾を受ける立場にあるプレイヤと言える。

自分の出した協力要請に対して、被要請プレイヤからの承諾が所定数以上集まると、上記ボーナスステージの入場制限が解除される。これにより、要請元プレイヤは、当該ボーナスステージに入場できる。換言すれば、入場する権利を得ることができる。すなわち、ボーナスステージをプレイすることが可能となる。

ここで、本実施形態では、上記協力要請に対して承諾を行った被要請プレイヤに、その承諾を行ったことに対する報酬を付与する。このとき、本実施形態では、一律に同じ報酬を付与するのではなく、承諾を受けた要請元プレイヤがその後に取った行動に応じて、その報酬内容を変化させる処理を行うものである。具体的には、本実施形態では、報酬として、上記承諾を行った被要請プレイヤに仮想通貨を付与する。本実施形態では、仮想通貨の一例として、ゲーム内通貨を付与する。より具体的には、本実施形態では、「ベル」と呼ばれるゲーム内通貨を付与する。当該「ベル」は、ゲーム内において、家具や衣服などのアイテムを購入するために用いられる。もちろん、「ベル」は一例であり、他の実施形態にかかるゲームにおいては、ゲーム内容に応じて他の名称のゲーム内通貨を用いてもよいことは言うまでもない。

具体的な付与の一例を示すと、被要請プレイヤからの承諾を受けた要請元プレイヤが、その後上記ボーナスステージに入場した場合は、承諾を行った被要請プレイヤには１００ベルが付与される。一方、承諾を受けた要請元プレイヤが、結局はボーナスステージに入場しなかった場合は、承諾を行った被要請プレイヤにはより少ない額である５０ベルが付与される。つまり、承諾を受けた要請元プレイヤが、実際にボーナスステージをプレイしたか否かによって、承諾を行った被要請プレイヤに付与する報酬額を変化させている。なお、ボーナスステージをプレイしなかった場合としては、例えば、５人分の承諾が必要なところ、４人分しか集まらなかった場合が考えられる。あるいは、所定数の承諾が得られたものの、時間の都合等で、結局はボーナスステージをプレイしなかった場合、等が考えられる。

このように、ある要請元プレイヤからの協力要請に対して承諾を行った被要請プレイヤが得られる報酬内容を、当該承諾を受けた要請元プレイヤのその後の行動に応じて変化させることができる。これにより、報酬の与え方に幅を持たせることができる。

なお、上記のような他のプレイヤの協力を得られないと、進行あるいは利用することができないようなゲーム要素につき、本実施形態では、ゲームクリアのためには必須ではない、オプション的なものを想定している。つまり、ゲームクリアに必須ではないが、それを利用することでゲームを有利に進めることが可能な要素の一部について、上記のような所定数の他プレイヤの協力が必要という制限を設定する場合を想定している。但し、他の実施形態では、ゲームを先に進めるために必須的な要素を制限対象としてもよい。例えば、ゲームクリアまで一本道的なステージ構成であるゲームにおける、次のステージの開放条件として、複数人の他のプレイヤの協力を要求するようにしてもよい。

［より具体的なゲーム処理の概要］
次に、より具体的な説明として、上記ボーナスステージを例とした本実施形態におけるゲーム処理の概要を説明する。

まず、本実施形態で想定するゲームは、様々な仮想キャラクタが生活している仮想ゲーム世界内で、プレイヤキャラクタとして仮想的に生活するゲームである。例えば、様々な素材アイテムを集めて自分の家を建てたり、庭を整備したりできる。また、ネットワークを経由して、他のプレイヤとの交流を図ることもできる。例えば、他のプレイヤの「家」に遊びに行くこと等ができる。また、一部の他のプレイヤについては、「フレンド」として自身のフレンドリストに登録することも可能である。また、上記のような協力要請を他のプレイヤに送ることもできる。

上記ボーナスステージは、仮想ゲーム世界内の所定の場所に配置されている。本実施形態では、このボーナスステージは、例えば、「鉱山」をモチーフとしたステージである。プレイヤは、当該ボーナスステージに入場し、所定の操作を行うことで、ゲーム内で用いられる「素材アイテム」を入手することができる。また、この素材アイテムには複数の種類がある。例えば、「鉄」、「銀」、「金」、「石炭」、等の複数種の素材が用意されている。この素材アイテムを用いて、プレイヤは所定のアイテム等を作成すること等が可能である。

本実施形態では、初期状態としては、このボーナスステージの入り口が、大きな岩でふさがれている状態となっている。つまり、そのままでは入場することができず、この岩を移動させるために、他のプレイヤの協力を求める、というものである。なお、本実施形態では、一例として５人のプレイヤの協力が必要であるものとする。

ここで、本実施形態では、上記の協力要請は、不特定多数の他のプレイヤではなく、「フレンド」として登録されている他のプレイヤに対してのみ送ることができるよう構成されている。つまり、フレンドのみが被要請プレイヤになり得る。これは、ある程度親しい間柄に協力要請を送るほうが、承諾が得られやすいであろうという理由による。また、プレイヤ間のコミュニケーションの活性化という側面もある。具体的には、本実施形態では、ボーナスステージを利用することで、ゲームを有利に進めることが可能であるといえるが、このボーナスステージのプレイのためには、フレンドの協力が必要となっている。そして、フレンドの数が多いほど、所定数の承諾の獲得が期待できるといえる。このことから、フレンドをたくさん作ることが、ゲームを有利に進めることに繋がり、フレンドを増やすことへの動機付けともなる。その結果、プレイヤ間のコミュニケーションの活性化が期待できることから、フレンドのみに協力要請可能な構成としている。

本実施形態では、上記ボーナスステージの入り口にプレイヤキャラクタを移動させた場合、図４に示すような選択画面が表示部１１６に表示される。図４では、ステージに入るためにはフレンドの協力が必要な旨の説明文１５１と、２つの選択肢画像１５２Ａおよび１５２Ｂが表示されている。選択肢画像１５２Ａは、プレイヤがフレンドに協力要請したい場合に選ぶ選択肢である。選択肢画像１５２Ｂは、「チケット」を使う場合の選択肢である。この「チケット」については、後述する。

図４の画面においてプレイヤが選択肢画像１５２Ａを選択する操作、例えばタップ操作を行うと、図５に示すような、フレンドに協力を要請するための画面が表示される。この画面では、複数のフレンドバナー１５４が一覧形式で表示されている。プレイヤが、いずれかのフレンドバナー１５４を選択操作すると、図６に示すように、協力要請の送信確認のための画面が表示される。図６では、協力要請することを示すボタン画像１５６と、前の画面に戻るためのボタン画像１５７とが示されている。そして、ボタン画像１５６をプレイヤが選択すれば、当該選択したフレンド宛てに協力要請が送信される。なお、以下では、協力要請を受けたフレンドのことを「被要請フレンド」と呼ぶ。

なお、本実施形態では、協力要請の送信は、フレンド一人ずつ指定して送信確認を行う構成を採っている。他の実施形態では、複数のフレンドを一度に指定して、一斉に協力要請を送信するような構成としてもよい。本実施形態のような構成であれば、一人一人確認しながらの操作となるため、協力要請を間違って送信してしまうことを防ぐことが可能な点で有利である。

また、更に他の実施形態では、フレンドを指定せずに協力要請を送信可能なように構成しても良い。例えば、協力要請用のボタンを表示しておき、当該ボタンがタップされれば、ランダムで選択されたフレンドに協力要請が送信されるような構成としてもよい。また、例えば、協力要請用のボタンがタップされれば、フレンド全員に一括で協力要請が送信されるような構成としてもよい。

また、本実施形態では、５人の協力が必要な場合の例であるが、協力要請自体は、５人以上の他のプレイヤに対して送ることもできる。なお、送信可能な上限値は必ずしも設定する必要はないが、本実施形態では、上限値として最大２０人まで協力要請が送ることができるものとする。

上記協力要請に対して、５人以上の承諾が得られれば、上記ボーナスステージへの入場が可能となる。この後、要請元プレイヤが当該ボーナスステージに入場し、所定の操作を行うことで、上述した各種の素材アイテムを入手することができる。そして、要請元プレイヤが当該ボーナスステージに入場した場合は、上記承諾を行った被要請フレンドに対して、１００ベルが付与されることになる。ここで、本実施形態では、承諾を行った被要請フレンド全員に１００ベルを付与する。つまり、５人の協力が必要なところ、協力要請自体は１０人のフレンドに送り、そのうち９人から承諾が得られた場合は、この承諾を行った９人に対して、１００ベルが付与される。なお、他の実施形態では、承諾を行った全員ではなく、例えば先着順で付与するようにしても良い。上記の例で言うと、先着５人だけに１００ベルを付与するようにしてもよい。

一方、ボーナスステージに入場しなかった場合、上記のように、承諾を行った被要請フレンドに対してそれぞれ５０ベルが付与される。報酬額は、ボーナスステージに入場した場合よりも少ないものとなっている。また、この場合も、承諾を行った被要請フレンド全員に付与される。なお、上記のような先着順で報酬を付与する実施形態の場合であれば、先着に間に合わなかったプレイヤには、より少ない額となる５０ベルを付与するようにしてもよい。あるいは、先着順に間に合った場合よりは少ないが、ボーナスステージに入場しなかった場合よりは多い額となる、例えば７０ベルを付与するようにしてもよい。

また、本実施形態では、一旦ボーナスステージに入場してプレイし、ボーナスステージのプレイが終了すると、再度上記の入場制限がかけられる。つまり、一旦制限を解除すれば、その後は自由に入れるというものではなく、入場を希望する都度、所定数のフレンドの承諾が必要な構成となっている。

ところで、本実施形態では、上記協力要請でボーナスステージに入場できる回数に制限を設けている。具体的には、１日に１度しか、協力要請による入場ができない構成としている。更に、ボーナスステージでは上記のように各種素材アイテムが入手可能だが、一定の時間周期で、入手可能な素材アイテムが変更されるような構成ともしている。具体的には、３時間を１周期として、その周期において入手できる素材アイテムを変更させている。例えば第１周期では、「鉄」と「銅」が入手でき、第２周期では、「金」と「銀」が入手できる、等である。そのため、例えば、上記被要請フレンドから承諾が所定数集まり、ボーナスステージの入場制限が解除されても、すぐには入場せず、自分の欲しい素材が出現する周期が到来するのを待ってから入場する、ということも可能となっている。

ここで、上記協力要請を出してから、必要数の承諾が揃うまでには、基本的にはタイムラグが発生するといえるそのため、上記ボーナスステージの入手アイテムの変更周期や１日１度の制限を考慮して、欲しい素材の入手のために、あらかじめ早めに協力要請を出しておく等で、協力要請という行動に戦略性を持たせることもでき、ゲームの興趣性を高めている。

また、上記１日１度の入場という制限に関連するが、本実施形態では、１日に１度（例えば１６：００に）、協力要請の「リセット」も行われる。例えば、１６：００にリセットされる場合を想定すると、プレイヤＡが、９：００のタイミングで１０人のフレンドに協力要請を出した場合、１６：００までに少なくとも５人の承諾が得られなかったときは、１６：００のタイミングでこの協力要請は一旦リセットされる。そのため、プレイヤＡは、１６:００以降に再度協力要請をやり直す必要があるまた、例えば、フレンドの承諾は必要数得られて、ボーナスステージがプレイ可能な状態ではあるが、まだプレイしていないまま１６：００が到来した場合も、この承諾についてリセットされる。なお、この点については、プレイヤの利便性の観点から、入場可能な状態はリセットされないようにしても良い。

また、詳細は後述するが、上記報酬の付与タイミングは、本実施形態では、上記協力要請の「リセット」のタイミングに併せて行われる。つまり、その日の分の協力要請を精算するための日次処理として、上記協力要請のリセットや報酬付与の処理が行われる。

次に、上記で言及した「チケット」に関して説明する。当該チケットは、これを利用することで、フレンドの承諾の有無にかかわらず、上記ボーナスステージをプレイ可能とするアイテムである。例えば、フレンドからの上記承諾が必要数集まっていない、あるいはそもそも協力要請していない場合でも、ボーナスステージのプレイを可能とするアイテムである。なお、本実施形態では、当該チケットは、いわゆる「課金アイテム」であり、所定の購入・決済処理を経ることで入手可能なアイテムである。他の実施形態では、このようなチケットの代わりに、課金アイテムではない所定のアイテムを用いるようにしてもよい。

上記チケットの利用に由来するボーナスステージのプレイの形態として、本実施形態では、当該チケットを消費することで、ボーナスステージのプレイを即時に可能とする形態を例として説明する００７０。上記図４において、選択肢画像１５２Ｂをプレイヤが選択したときは、図７に示すような、チケット利用の確認画面が表示される。図７では、２０枚のチケットが必要であることが示されている。プレイヤがボタン画像１５８を選択した場合は、２０枚のチケットが消費されて、上記ボーナスステージのプレイが即時に開始される。プレイヤがボタン画像１５９を選択した場合は、チケットは消費されず、前の画面に戻ることになる。

ここで、チケットの利用回数に関して説明する。本実施形態では、上記のように、３時間を１周期として、入手可能アイテムを変更させているが、この１周期において１度だけチケット消費によるボーナスステージのプレイが可能である。例えば、第１周期においてチケット利用によるボーナスステージのプレイが行われた場合は、次の第２周期が来るまでは、チケット利用によるボーナスステージのプレイはできない。換言すれば、チケット利用によるボーナスステージのプレイは、１日に最大で８回可能なものとなっている。

なお、本実施形態では、ボーナスステージへの入場は、その入場制限の解除方法がチケット利用の場合であってもフレンドの承諾による場合であっても、１周期に１度だけ可能であるものとする。例えば、第１周期において、チケット利用によるボーナスステージのプレイが行われた場合は、同じ第１周期中は、フレンドの承諾を必要数得ていた場合であっても、ボーナスステージには入場できない。フレンド承諾による入場を行うには、次の周期を待つ必要がある。

上記のように、本実施形態では、チケットを利用することで、１日に最大で８回、ボーナスステージのプレイが可能となっている。また、１日に１回だけ、フレンドの協力を集めることでもボーナスステージのプレイが可能となっている。そのため、フレンドの協力を集めることができれば、１回分のチケット利用を節約することが可能である。このことから、本実施形態は、このような節約のためにも、フレンドをたくさん作るということへのプレイヤのモチベーションを高め、プレイヤ間のコミュニケーションの活性化を図ることも可能となっている。

なお、フレンドの協力を集める場合のボーナスステージのプレイについて、１日に１度だけという例で説明しているが、もちろん、他の実施形態では、これに限らず、１日に２回以上プレイ可能なように構成しても良い。

［本実施形態のゲーム処理の詳細］
次に、図８〜図２４を参照して、本実施形態のゲーム処理についてより詳細に説明する。

［使用データについて］
まず、本ゲーム処理にて用いられる各種データに関して説明する。図８は、サーバ１０１のメモリ１２３に格納されるプログラムおよびデータの一例を示している。メモリ１２３には、サーバ側プログラム２１１、プレイヤデータベース２１２等が格納される。

サーバ側プログラム２１１は、本実施形態に係るゲーム処理においてサーバ側が担当する各種機能をサーバ１０１に実行させるためのプログラムである。

プレイヤデータベース２１２は、本実施形態にかかるゲームの各プレイヤについての情報を記憶したデータベースであり、複数のプレイヤデータ２１３で構成されている。各プレイヤデータ２１３には、アカウントデータ２１４、プレイ状況データ２１５等が含まれている。

アカウントデータ２１４は、各プレイヤのアカウントに関する情報であり、各プレイヤを識別するための情報でもある。サーバ１０１へのログイン処理等にも用いられる。

プレイ状況データ２１５は、各プレイヤのゲームのプレイ状況等を示す情報である。図９に、プレイ状況データ２１５の構成の一例を示す。プレイ状況データ２１５には、所持チケット枚数２２１、ベル枚数２２２、フレンドリスト２２３、送信済み要請データ２２４、受信要請データ２２５、承諾済みデータ２２６、ロック状態フラグ２２７、チケット使用フラグ２２８、協力使用フラグ２２９、等が含まれている。

所持チケット枚数２２１は、上記チケットの所持数を示すデータである。ベル枚数２２２は、上記ベルの所持数を示すデータである。フレンドリスト２２３は、そのプレイヤが「フレンド」として登録している他のプレイヤを示すためのデータである。例えば、自身のプレイヤＩＤとフレンドのプレイヤＩＤとが対応づけられて記憶されている。

送信済み要請データ２２４は、送信済みの協力要請を示すデータである。換言すれば、被要請フレンドを識別するためのデータである。図１０に、当該送信済み要請データ２２４のデータ構成の一例を示す。送信済み要請データ２２４は、要請番号２５１、フレンドＩＤ２５２、承諾フラグ２５３を含むテーブル形式のデータである。要請番号２５１は、送信した協力要請を一意に識別するための番号である。フレンドＩＤ２５２は、送信先のフレンド、すなわち被要請フレンドを識別するための情報である。承諾フラグ２５３は、自身が協力要請を送った被要請フレンドが、その要請に対して承諾を行ったか否かを示すフラグである。初期値はオフであり、上記承諾が行われたとき、オンに設定される。

図９に戻り、受信要請データ２２５は、他のプレイヤから自分宛に送られてきた協力要請を示すデータである。つまり、自分が被要請プレイヤ側になっている関係であることを示すデータともいえる。図１１に、当該受信要請データ２２５のデータ構成の一例を示す。受信要請データ２２５は、受信番号２６１、フレンドＩＤ２６２、要請番号２６３を含むテーブル形式のデータである。受信番号２６１は、受信した協力要請を一意に識別するための番号である。フレンドＩＤ２６２は、協力要請を送ってきたフレンド（以下、要請元フレンド）を識別するための情報である。要請番号２６３は、当該要請元フレンド側での識別に用いられる要請番号である。すなわち、当該要請元フレンドのデータにおける上記送信済み要請データ２２４の要請番号２５１に対応するものである。

図９に戻り、承諾済みデータ２２６は、上記要請元フレンドからの協力要請に対して自分が承諾したものを記録しておくためのデータである。主に、上記報酬付与の対象になるか否かの判別のために用いられる。図１２に、当該承諾済みデータ２２６のデータ構成の一例を示す。承諾済みデータ２２６は、承諾番号２７１、フレンドＩＤ２７２、結果情報２７３を含むテーブル形式のデータである。承諾番号２７１は、自身が行った承諾を一意に識別するための番号である。フレンドＩＤ２７２は、自身が承諾を行った要請元フレンドを識別するための情報である。結果情報２７３は、自身が承諾を行った要請元プレイヤが、その後のボーナスステージをプレイしたか否か等を示す情報である。本実施形態では、ボーナスステージがプレイされた場合に、そのことを示す情報が結果情報２７３として記録される。逆に、プレイされなかった場合は、この結果情報２７３は空のデータとなる。なお、他の実施形態では、結果情報２７３は、ボーナスステージのプレイ状況をより細かく示すデータであってもよい。例えば、最終スコア、取得したアイテムの情報、倒した敵の数等を示すデータであってもよい。つまり、承諾を受けた側のプレイヤのその後のボーナスステージのプレイ状況を示すデータであれば、どのような情報を用いてもよい。

なお、本実施形態では、１日に１度しか協力要請を利用できない構成となっているため不要ではあるが、他の実施形態において、同じフレンドから複数の協力要請が送られてくるような構成である場合は、どの協力要請に対して承諾を行ったのかを判別するため、当該承諾済みデータ２２６に、上記受信要請データ２２５の場合と同様の要請番号を更に持たせるような構成としてもよい。

図９に戻り、ロック状態フラグ２２７は、上記ボーナスステージの入場制限がかかっているか否かを示すためのフラグである。オフであれば、入場制限はかかっておらず、ボーナスステージがプレイ可能であることを示す。オンの時は、入場制限がかかっており、上記フレンドの協力、あるいは、チケットの利用が必要な状態であることを示す、デフォルトではオンに設定される。

チケット使用フラグ２２８は、上記ボーナスステージの各周期において、上記チケットが使用されたか否かを示すためのフラグである。オンの時は、チケットが使用されたことを示す。協力使用フラグ２２９は、上記のフレンドの協力によってボーナスステージのプレイが行われたか否かを示すためのフラグであり、オンの時は、フレンドの協力を得てボーナスステージがプレイされたことを示す。なお、所定数のフレンドの協力が得られ、ボーナスステージのプレイが可能な状態ではあるが、まだプレイしていない状態の時は、当該フラグはオフのままである。実際にボーナスステージをプレイしたことで、オンに設定されるものである。

次に、スマートデバイス側のデータに関して説明する。図１３は、スマートデバイス１０２のメモリ１１３に格納されるプログラムおよびデータの一例を示している。メモリ１１３には、クライアント側プログラム２８１、操作データ２８２、オブジェクトデータ２８３等が格納される。

クライアント側プログラム２８１は、本実施形態に係るゲーム処理においてスマートデバイス側が担当する各種機能をスマートデバイス１０２に実行させるためのプログラムである。

操作データ２８２は、操作部１１５に対して行われた各種操作内容を示すデータである。本実施形態では、操作部１１５としてのタッチパネルへの入力の有無、タッチ座標等を示すデータや、図示しない各種ボタンの押下状態等を示すデータが含まれている。

オブジェクトデータ２８３は、ゲーム世界を構成する各種オブジェクトやステージを定義したデータである。例えば、ボーナスステージを構成する各種マップオブジェクト等を示すデータ等が含まれる。

その他、メモリ１２３には、ゲーム処理に必要な各種データも適宜格納される。

［スマートデバイスにおける主な処理］
次に、図１４のフローチャートを参照して、本実施形態にかかるゲーム処理の詳細を説明する。なお、ここでは、主に上記ボーナスステージに関する処理について説明し、その他のゲーム処理の説明については割愛する。また、以下の処理は、基本的には、スマートデバイス１０２のプロセッサ部１１１が主体である場合を例に説明する。他の実施形態では、以下の処理の一部をサーバ１０１において実行し、その結果をスマートデバイス１０２における処理に反映するようにしてもよい。例えば、スマートデバイス１０２では、操作データの取得とサーバへの送信、各種画像音声処理を中心に行い、当該操作データに基づいたゲーム処理、例えば仮想ゲーム空間内でのプレイヤオブジェクトの移動または各種の判定処理等はサーバ１０１で行い、その実行結果をスマートデバイス１０２に送るようにしてもよい。

ゲーム処理が開始されると、まず、ステップＳ１で、ボーナスステージ設定処理が実行される。これは主に、上記の周期毎に、入手可能アイテムの設定を変更するための処理である。図１５は、当該ボーナスステージ設定処理の詳細を示すフローチャートである。図１５において、まず、ステップＳ２１で、スマートデバイス１０２のプロセッサ部１１１は、前回にボーナスステージの設定変更を行ってから３時間が経過したか否かを判定する。当該判定の結果、まだ３時間経過していないときは（ステップＳ２１でＮＯ）、当該処理は終了する。一方、３時間経過していたときは（ステップＳ２１でＹＥＳ）、ステップＳ２２で、プロセッサ部１１１は、チケット使用フラグ２２８をオフに設定するための処理を実行する。具体的には、プロセッサ部１１１は、サーバ１０１に対して、チケット使用フラグ２２８をオフに設定する旨の指示を送信する。これを受けて、サーバ１０１側で、チケット使用フラグ２２８をオフに設定する処理が適宜実行される。この処理は、各周期で１度だけ利用できるチケットの使用状態をリセットするものである。

なお、ボーナスステージの設定変更タイミングの判定については、上記のような前回変更時からの時間経過で判定する他、例えば、現在時刻が所定時刻であるか否かで判定するようにしても良い。例えば、３時間毎に設定変更する場合は、設定変更時刻が、０時、３時、６時、９時・・・のように、３時間間隔の時刻となることが予めわかっていることになる。そのため、現在時刻がこのような設定変更時刻であるか否かを判定するようにしてもよい。

次に、ステップＳ２３で、プロセッサ部１１１は、その周期で入手可能な素材アイテムを設定する処理を実行する。例えば、各周期において入手可能な素材アイテムを定義したテーブルデータ（図示せず）を参照し、これに基づいてボーナスステージの設定を行う。以上で、ボーナスステージ設定処理は終了する。

図１４に戻り、次に、ステップＳ２で、プロセッサ部１１１は、操作データ２８２を取得する。次に、ステップＳ３で、プロセッサ部１１１は、仮想ゲーム空間内においてプレイヤキャラクタがボーナスステージのある場所に移動したか否かを判定する。これは、仮想３次元空間内でプレイヤキャラクタを移動させるような場合の他、例えば、マップ画面においてボーナスステージの場所をタップするような操作も含まれる。当該判定の結果、ボーナスステージの場所に移動していない場合は（ステップＳ３でＮＯ）、ステップＳ８で、プロセッサ部１１１は、その他のゲーム処理を操作データ２８２に基づいて適宜実行する。

一方、上記ステップＳ３の判定の結果、プレイヤキャラクタがボーナスステージの場所に移動している場合は（ステップＳ３でＹＥＳ）、次に、ステップＳ４で承諾チェック処理が実行される。当該処理は、フレンドに送信した協力要請に対して承諾が行われたかを判定するための処理である。

図１６は、上記承諾チェック処理の詳細を示すフローチャートである。図１６において、まず、ステップＳ３１で、プロセッサ部１１１は、送信済み要請データ２２４をサーバ１０１から取得する。次に、ステップＳ３２で、協力要請を少なくとも１つは送信済みであるか否かを判定する。１つも送信していないときは（ステップＳ３２でＮＯ）、当該承諾チェック処理は終了する。少なくとも１つは送信済みであれば（ステップＳ３２でＹＥＳ）、ステップＳ３３で、プロセッサ部１１１は、承諾フラグ２５３を参照して、所定数以上の被要請フレンドによる承諾が行われたか否かを判定する。その結果、所定数の承諾がまだ行われていない場合は（ステップＳ３３でＮＯ）、当該承諾チェック処理は終了する。所定数以上の承諾が行われていれば（ステップＳ３３でＹＥＳ）、ステップＳ３４で、プロセッサ部１１１は、ロック状態フラグ２２７をオフに設定するための処理を実行する。具体的には、サーバ１０１に、ロック状態フラグ２２７をオフに設定させるための指示を送信する。これをうけて、サーバ１０１において、ロック状態フラグ２２７をオフに設定する処理が適宜実行される。なお、この時点で既にロック状態フラグ２２７がオフに設定済みであれば、当該処理はスキップしてもよい。また、他の実施形態では、このときに、ロック状態を解除するか否かをプレイヤに問い合わせるようにしてもよい。そして、この問い合わせに対してプレイヤからロック状態の解除指示を受けたときに、ロック状態フラグ２２７をオフに設定するための処理を実行するようにしても良い。以上で、承諾チェック処理は終了する。

図１４に戻り、次に、ステップＳ５で、プロセッサ部１１１は、ロック状態フラグ２２７をサーバ１０１から取得し、上記ボーナスステージのロックが解除されているか否かを判定する。その結果、まだ解除されていないときは（ステップＳ５でＮＯ）、ステップＳ６で、プロセッサ部１１１は、選択画面処理を実行する。この処理では、上述の協力要請を行うかチケットを使用するかの選択画面の表示処理等が実行される。

図１７は、上記選択画面処理の詳細を示すフローチャートである。まず、ステップＳ４１で、プロセッサ部１１１は、上記図４で示したような選択画面を生成して、表示部１１６に表示する。次に、ステップＳ４２で、プロセッサ部１１１は、操作データ２８２を取得し、ステップＳ４３で、当該操作データ２８２に基づいて、上記選択画面において協力要請の選択操作が行われたか否かを判定する。その結果、協力要請の選択が行われていた場合は（ステップＳ４３でＹＥＳ）、ステップＳ４４で、プロセッサ部１１１は、協力要請処理を実行する。

図１８は、当該協力要請処理の詳細を示すフローチャートである。まず、ステップＳ５１で、プロセッサ部１１１は、サーバ１０１から上記協力使用フラグ２２９を取得する。そして、当該協力使用フラグ２２９を参照して、当日分の「協力によるロック解除」が既に行われているか否かを判定する。当該判定の結果、既に行われていれば（ステップＳ５１でＹＥＳ）、ステップＳ５８で、プロセッサ部１１１は、その日はこれ以上の協力要請はできない旨等を表示する処理を実行し、協力要請処理を終了する。

一方、まだ当日分のロック解除が行われていない、すなわち、所定数以上の承諾がまだ得られていない場合は（ステップＳ５１でＮＯ）、ステップＳ５２で、プロセッサ部１１１は、協力要請の最大可能数まで既に送信済みか否かを判定する。その結果、既に最大数まで協力要請が送信済みであるときは(ステップＳ５２でＹＥＳ）、上記ステップＳ５８で、プロセッサ部１１１は、これ以上の協力要請はできない旨等を表示する。一方、まだ最大数まで送信していない場合は（ステップＳ５２でＮＯ）、ステップＳ５３で、プロセッサ部１１１は、フレンドリスト２２３をサーバ１０１から取得する。次に、ステップＳ５４で、プロセッサ部１１１は、上記送信済み要請データ２２４を参照して、協力要請送信済みのフレンド、すなわち、被要請フレンドを特定する。次に、ステップＳ５５で、プロセッサ部１１１は、上記図５で示したような協力要請用の画面を生成して表示部１１６に表示する。この際、既に協力要請送信済みの被要請フレンドについては、この画面に含まないように生成してもよい。あるいは、既に協力要請送信済みであることが判別できるよう、被要請フレンドの表示態様を変えた画面を生成してもよい。

次に、ステップＳ５６で、プロセッサ部１１１は、操作データ２８２を取得し、図１９のステップＳ５７で、協力要請の指示操作が行われたか否かを判定する。例えば、いずれかのフレンドをタップする操作が行われたか否かを判定する。当該判定の結果、協力要請操作が行われていた場合は（ステップＳ５７でＹＥＳ）、ステップＳ５９で、プロセッサ部１１１は、上記図６で示したような協力要請の送信確認画面を表示する。続くステップＳ６０で、プロセッサ部１１１は、操作データ２８２を取得し、ステップＳ６１で、この確認画面に対して送信する旨の操作が行われたか否かを判定する。送信操作が行われていれば（ステップＳ６１でＹＥＳ）、ステップＳ６２で、プロセッサ部１１１は、送信要請用のデータを生成し、サーバ１０１に送信する。当該データは、例えば、上記送信要請済みデータ２２４（上記図１０）から承諾フラグ２５３を除いたようなデータ構成である。更に、プロセッサ部１１１は、当該送信した内容に対応するデータを送信要請済みデータ２２４に追加する。すなわち、送信した要請番号２５１とフレンドＩＤ２５２を含み、承諾フラグ２５３には初期値としてオフを設定したレコードを新たに追加する。その後、ステップＳ６３で、プロセッサ部１１１は、上記確認画面を消去する処理を行う。そして、上記ステップＳ５２に戻り、処理を繰り返す。一方、上記ステップＳ６１の判定の結果、送信の操作が行われなかったときは（ステップＳ６１でＮＯ）、上記ステップＳ６２の処理は行われずに、ステップＳ６３の処理に進められる。

一方、上記ステップＳ５７の判定の結果、協力要請用の画面において協力要請の操作が行われなかった場合は（ステップＳ５７でＮＯ）、ステップＳ６４で、プロセッサ部１１１は、当該画面を終了させる操作が行われたか否かを判定し、行われていれば（ステップＳ６４でＹＥＳ）、ステップＳ６５で、当該画面を消去する処理を実行し、当該協力要請処理を終了する。終了操作が行われていない場合は（ステップＳ６４でＮＯ）、ステップＳ６６で、プロセッサ部１１１は、操作データ２８２に基づいたその他の処理を適宜実行する。例えば、画面スクロール処理等である。その後、上記ステップＳ５３の処理に戻る。以上で、協力要請処理は終了する。

図１７に戻り、上記ステップＳ４３の判定の結果、協力要請が選択されていない場合は（ステップＳ４３でＮＯ）、ステップＳ４５で、プロセッサ部１１１は、チケットを利用することが選択されたか否かを判定する。その結果、チケットの利用が選択されていれば（ステップＳ４５でＹＥＳ）、ステップＳ４６で、プロセッサ部１１１は、後述のチケット利用処理を実行する。チケットの利用が選択されていない場合は（ステップＳ４５でＮＯ）、ステップＳ４７で、プロセッサ部１１１は、操作データに基づいてその他のゲーム処理を実行する。例えば、当該選択画面を「閉じる」操作が行われていれば、当該画面を消去する処理が実行される。

図２０は、上記チケット使用処理の詳細を示すフローチャートである。まず、ステップＳ７１で、プロセッサ部１１１は、チケット使用フラグ２２８をサーバ１０１から取得し、今回の周期でチケットが既に使用されているか否かを判定する。その結果、既に使用されているときは（ステップＳ７１でＹＥＳ）、ステップＳ７６で、プロセッサ部１１１は、既にチケットを使用している旨を表示部１１６に表示する処理を実行する。例えば、次にチケットが利用可能となるまでの時間を知らせる表示である。そして、チケット利用処理を終了する。

一方、今回の周期ではまだチケットを使用していないときは（ステップＳ７１でＮＯ）、ステップＳ７２で、プロセッサ部１１１は、上記図７で示したようなチケットの利用確認画面を表示する。次に、ステップＳ７３で、操作データ２８２を取得し、ステップＳ７４で、その操作内容が、チケット利用指示であるか否かを判定する。その結果、チケット利用指示であれば（ステップＳ７４でＹＥＳ）、ステップＳ７５で、プロセッサ部１１１は、上記所持チケット枚数２２１から所定数を減算したうえで、ボーナスステージプレイ処理を実行する。チケット利用指示でない場合は（ステップＳ７４でＮＯ）、プロセッサ部１１１は、当該チケット利用画面を消去して、チケット利用処理を終了する。

図２１は、上記ボーナスステージプレイ処理の詳細を示すフローチャートである。図２１において、まず、ステップＳ８１で、プロセッサ部１１１はステージ準備処理を実行する。例えば、ボーナスステージがランダム生成型のダンジョンであれば、そのマップを生成する処理、その周期において取得可能な素材アイテムをボーナスステージ内に配置する処理等、ボーナスステージをプレイするための準備となる処理が適宜実行される。そして、準備が終われば、ボーナスステージのプレイに係るゲーム画面が表示される。

次に、ステップＳ８２で、プロセッサ部１１１は、操作データ２８２を取得し、ステップＳ８３で、当該操作データ２８２に基づき、ボーナスステージにかかるゲーム処理を実行する。例えば、プレイヤキャラクタの移動処理、各種素材アイテムの入手判定、各種ゲーム処理の結果を反映したゲーム画面の表示等が行われる。

次に、ステップＳ８４で、プロセッサ部１１１は、ボーナスステージのプレイが終了したか否かを判定する。例えば、ボーナスステージをクリアしたか、あるいは、途中でリタイアする操作が行われたか、等が判定される。当該判定の結果、まだ終了していない場合は（ステップＳ８４でＮＯ）、上記ステップＳ８２に戻り、ボーナスステージのプレイにかかる処理が繰り返される。終了した場合は（ステップＳ８４でＹＥＳ）、ステップＳ８５で、プロセッサ部１１１は、ボーナスステージの終了処理を実行する。具体的には、最終得点の計算等の処理、プレイの結果を示す画面表示の処理、ボーナスステージで入手できたアイテム等を確定してプレイヤに付与する処理、等が実行される。

次に、ステップＳ８６で、プロセッサ部１１１は、今回のボーナスステージのプレイが、チケット利用によるものであるか否かを判定する。チケット利用によるものである場合は（ステップＳ８６でＹＥＳ）、そのままボーナスステージプレイ処理は終了する。チケット利用によるものではいない場合は（ステップＳ８６でＮＯ）、フレンドの協力を得てプレイした場合に該当するため、以下の処理が実行される。まず、ステップＳ８７で、プロセッサ部１１１は、今回のボーナスステージのプレイ結果を示す結果データを生成する。本実施形態では、「ボーナスステージをプレイしたこと」を示す内容を結果データとして生成するが、他の実施形態では、ボーナスステージで得た得点や、ボーナスステージのプレイにおいて達成された所定の条件等を示すデータであってもよい。また、「ボーナスステージをプレイしなかったこと」を示すデータを結果データとして送信してもよい。例えば、上記協力要請がリセットされるタイミングに合わせるように「ボーナスステージをプレイしなかったこと」を示すデータを送信してもよい。具体的には、リセットが１６：００に行われる場合、その１分前の１５：５９の時点で、ボーナスステージがプレイされていない場合に、承諾を与えたフレンドに対して「ボーナスステージをプレイしなかったこと」を示すデータを送信してもよい。

次に、ステップＳ８８で、当該結果データを、協力要請に対して承諾を行ってくれた被要請フレンド宛てに送信するための処理が実行される。すなわち、上記送信済み要請データ２２４を参照し、承諾フラグ２５３がオンに設定されているフレンドを宛先として、上記結果データを送信する処理を実行する。これにより、上記承諾を行ってくれた被要請フレンドに対して、結局ボーナスステージをプレイしたのか否かを知らせることが可能となる。以上で、ボーナスステージプレイ処理は終了する。

図１４に戻り、次に、上記ステップＳ５でボーナスステージのロックが解除されていると判定された場合の処理（ステップＳ５でＹＥＳ）について説明する。この場合は、ステップＳ７で、プロセッサ部１１１は、ボーナスステージのプレイを開始する操作が行われたか否かを判定する。その結果、プレイ開始操作が行われていない場合は（ステップＳ７でＮＯ）、上記ステップＳ８の処理に進められる。一方、プレイ開始操作が行われた場合は（ステップＳ７でＹＥＳ）、ステップＳ９で、プロセッサ部１１１は、ボーナスステージプレイ処理を実行する。当該処理は、上述のステップＳ７５の処理を同様であるため、説明は割愛する。なお、当該ステップＳ９でのボーナスステージプレイ処理は、「フレンドの協力を得てプレイする」場合の処理であり、上記ステップＳ７５にかかるボーナスステージプレイ処理は、「チケット利用」した場合の処理である。ステップＳ９の処理が終われば、ステップＳ１０で、プロセッサ部１１１は、ロック状態フラグ２２７にオンを設定するための処理を実行する。すなわち、「フレンドの協力を得た」場合のボーナスステージのプレイが終われば、その入場についてのロックを再設定する。具体的には、プロセッサ部１１１は、サーバ１０１に対して、ロック状態フラグ２２７にオンを設定する旨の指示を送信する。これを受けて、サーバ１０１において、ロック状態フラグ２２７にオンを設定する処理が実行される。その後、上記ステップＳ１に戻り、処理が繰り返される。

以上、ゲーム処理の説明を終了する。

［協力要請確認処理］
次に、スマートデバイス１０２において実行される、要請元フレンドからの協力要請に対して「承諾する」ための処理について説明する。図２２は、このような処理の一例である協力要請確認処理の詳細を示すフローチャートである。当該処理は、ゲーム画面上で所定の操作を行うことで開始される処理である。例えば、「協力要請の確認」を示すボタンをタップする等である。

図２２において、まず、ステップＳ９１で、プロセッサ部１１１は、受信要請データ２２５をサーバ１０１から取得する。次に、ステップＳ９２で、プロセッサ部１１１は、届いている協力要請が一覧表示される画面（図示せず）を生成して表示する。プレイヤは、この画面に対して所定の操作を行うことで、協力要請毎に承諾を返すことが可能である。

次に、ステップＳ９３で、プロセッサ部１１１は、操作データ２８２を取得し、ステップＳ９４で、当該操作データ２８２に基づき、プレイヤが承諾しようとする協力要請を特定する。続くステップＳ９５で、プロセッサ部１１１は、当該特定した協力要請に対して、承諾したことを示すデータを生成し、当該協力要請元となる要請元フレンド宛てに送信する。また、承諾相手を示す情報を承諾済みデータ２２６に追加するための処理を実行する。具体的には、プロセッサ部１１１は、承諾番号２７１とフレンドＩＤ２７２とを対応づけたレコードを承諾済みデータ２２６に追加する旨の指示をサーバ１０１に送信する。これに応じて、サーバ１０１において、当該レコードを承諾済みデータ２２６に追加する処理が実行される。

次に、ステップＳ９６で、プロセッサ部１１１は、当該協力要請の確認画面を終了するか否かを判定し、まだ終了しない場合は（ステップＳ９６でＮＯ）、上記ステップＳ９１に戻り、処理が繰り返される。終了する場合は（ステップＳ９６でＹＥＳ）、当該協力要請確認処理は終了する。

なお、協力要請の確認については、上記のような専用の確認画面を用いる場合の他、例えば、協力要請の到着をリアルタイムで監視するようにし、届き次第、ポップアップ等で協力要請に対して承諾するか否かを問い合わせるような構成としてもよい。また、ゲームアプリ以外の、メールやＳＮＳ等のコミュニケーションツールを用いて協力要請を通知等する構成としてもよい。

また、承諾する場合だけでなく、承諾しない場合にも、その旨を明示的に返答するような構成としてもよい。例えば、上記ステップＳ９２において、協力要請が一覧表示される画面で所定の協力要請を選択すると、「承諾する」と「承諾しない」の２つの選択肢が表示されるようにする。そして、プレイヤが「承諾しない」ことを選択した場合、上記ステップＳ９５の処理として、「承諾しない」ことを示すデータを生成して、要請元フレンド宛てに送信する処理を実行するようにしてもよい。また、上記送信済み要請データ２２４の承諾フラグ２５３についても、当該「承諾しない」ことを示すデータを受信したことに応じて、当該フラグをオフに設定する処理を行うようにしても良い。

［サーバにおける処理］
次に、サーバ１０１において行われる主な処理について説明する。具体的には、あるプレイヤからの協力要請をリアルタイムに反映するための更新処理、および、上述したような報酬を付与するための処理について説明する。

［協力要請更新処理］
図２３は、上記協力要請の更新処理の詳細を示すフローチャートである。この処理では、上記協力要請または承諾をその相手に届けるための処理が実行される。図２３において、まず、ステップＳ１０１で、サーバ１０１のプロセッサ部１２１は、スマートデバイス１０２から送信されてくる協力要請用のデータの受信処理を実行する。次に、ステップＳ１０２で、プロセッサ部１２１は、受信した協力要請用のデータで指定されている要請先のプレイヤを識別する。そして、ステップＳ１０３で、プロセッサ部１２１は、識別したプレイヤの受信要請データ２２５に、当該協力要請用データで示される内容を追加する。すなわち、協力要請を送ってきたフレンドのフレンドＩＤ２６２と、その要請番号２６３とを新たに追加する処理が行われる。

次に、ステップＳ１０４で、プロセッサ部１２１は、スマートデバイス１０２から送信されてくる、上記承諾したことを示すデータを受信する。次に、ステップＳ１０５で、プロセッサ部１２１は、承諾が行われた要請元プレイヤの識別を行う。そして、ステップＳ１０６で、プロセッサ部１２１は、承諾が行われた要請元プレイヤの送信済み要請データ２２４の承諾フラグ２５３をオンに設定する。その後、ステップＳ１０１に戻り、処理が繰り返される。

なお、協力要請の受信に関して、上記のように、サーバ１０１において、協力要請が届いた場合は、メールやＳＮＳに送信する構成としてもよい。例えば、協力要請を受信した場合、サーバ１０１において、送信先のフレンドに関連づけられているメールアドレスやＳＮＳのアドレスに対して、協力要請が届いたことを示すメッセージを送信するような処理を行っても良い。そして、当該メッセージに対して承諾の旨が返答された場合に、承諾されたプレイヤに係る上記送信済み要請データ２２４の承諾フラグ２５３を更新するような処理としてもよい。

［報酬付与処理］
次に、上記報酬を付与するための処理について説明する。図２４は、サーバ１０１で実行される報酬付与処理の詳細を示すフローチャートである。まず、ステップＳ１１１で、サーバ１０１のプロセッサ部１２１は、上述したステップＳ８８の処理でスマートデバイス１０２から送信されてくる結果データの受信処理を実行する。更に、受信した結果データに基づき、各プレイヤの承諾済みデータ２２６の結果情報２７３を更新する。本実施形態では、上記承諾が行われた要請元プレイヤが当日中にボーナスステージをプレイしていれば、そのことを示す情報で結果情報２７３が更新されるが、プレイしていない場合は、結果データが届いていないため、更新されないことになる。換言すれば、このようなボーナスステージをプレイしたことを示すデータを「受信した」のか「受信しなかった」のかについて、１日１回（以下の処理の結果として）判定することになる。

次に、ステップＳ１１２で、プロセッサ部１２１は、日次処理の開始時間として予め設定されている時刻が到来したか否かを判定する。その結果、まだ到来していない場合は（ステップＳ１１２でＮＯ）、ステップＳ１１１に戻り、上記結果データの受信処理が繰り返される。

一方、日次処理の開始時刻が到来した場合は（ステップＳ１１２でＹＥＳ）、（日次処理として）協力に対する報酬を各プレイヤに付与するための処理を実行する。まず、ステップＳ１１３で、プロセッサ部１２１は、処理対象とするプレイヤ（以下、処理対象プレイヤ）を１人選択する。次に、ステップＳ１１４で、プロセッサ部１２１は、当該処理対象プレイヤの承諾済みデータ２２６を取得する。つまり、協力要請に対して承諾を行った要請元フレンドを抽出することになる。

次に、ステップＳ１１５で、プロセッサ部１２１は、上記承諾済みデータ２２６のうち、１つのレコードを選択する。次に、プロセッサ部１２１は、当該レコードの結果情報２７３を参照し、処理対象プレイヤが承諾を行った要請元フレンドが、結局ボーナスステージをプレイしたのか否かを判定する。その結果、ボーナスステージがプレイされていれば（ステップＳ１１６でＹＥＳ）、プロセッサ部１２１は、処理対象プレイヤにかかるベル枚数２２２に１００ベルを加算する。一方、ボーナスステージがプレイされていなかった場合は（ステップＳ１１６でＮＯ）、プロセッサ部１２１は、処理対象プレイヤにかかるベル枚数２２２に５０ベルを加算する。

次に、ステップＳ１１９で、プロセッサ部１２１は、承諾済みデータ２２６の全てのレコードを処理したか否かを判定し、まだ未処理のレコードが残っていれば（ステップＳ１１９でＮＯ）、ステップＳ１１５に戻り、処理を繰り返す。一方、全てのレコードを処理していれば（ステップＳ１１９でＹＥＳ）、次に、ステップＳ１２０で、プロセッサ部１２１は、全てのプレイヤについて上記のような処理を行ったか否かを判定し、まだ未処理のプレイヤが残っていれば（ステップＳ１２０でＮＯ）、ステップＳ１１３に戻り、次の処理対象プレイヤを選択して処理を繰り返す。全プレイヤを処理した場合は（ステップＳ１２０でＹＥＳ）、次に、ステップＳ１２１で、プロセッサ部１２１は、各プレイヤの、送信済み要請データ２２４と、受信要請データ２２５と、承諾済みデータ２２６とをクリアする処理を実行する。その後、上記ステップＳ１１１に戻り、処理が繰り返される。以上で、サーバ１０１における主な処理の説明を終了する。

このように、本実施形態では、協力要請に対して承諾した場合に、承諾された側である要請元プレイヤのその後のプレイ状況に応じて、被要請プレイヤが得られる報酬を変化させている。本実施形態では、ボーナスステージがプレイされれば、１００ベル、ボーナスステージがプレイされなくても、承諾した側のプレイヤは５０ベルを得ることが可能となっている。つまり、承諾するだけでも５０ベルは得られる。これにより、他のプレイヤに承諾を与えることへのインセンティブを働かせることができ、また、承諾を受ける側からしても、他のプレイヤからの協力を得られやすくなる。そのため、ゲーム内におけるプレイヤ間の交流を活性化させることが可能となる。

また、本実施形態では、ボーナスステージのプレイに際して、課金アイテムであるチケットの利用も可能としている。そのため、プレイヤがボーナスステージをプレイするための方法に幅を持たせることができる。また、フレンドの協力を利用することで、チケットの利用回数を減らすこともできる。そのため、より多くのフレンドを作成することへの動機付けをプレイヤに提供することもできる。

なお、付与される報酬について、上記実施形態ではゲーム内通貨であるベルの場合を例にしたが、これに限るものではない。例えば、ゲーム内で利用できるアイテムを付与するようにしてもよい。この場合も、承諾後のプレイヤの行動に応じて、その内容を異ならせるようにすればよい。例えば、報酬のアイテムに「レアリティ」を設けておく。そして、上記の例で言うと、要請元プレイヤがボーナスステージをプレイしなかった場合に、被要請プレイヤに付与されるアイテムよりも、ボーナスステージをプレイした場合に付与されるアイテムのほうが、よりレアリティが高いアイテムとなるようにしてもよい。すなわち、制限が解除されたゲーム要素が実行された場合に、より高い価値の報酬を付与するようにしてもよい。

また、付与される報酬は、他のゲームアプリでも利用可能な報酬であっても良い。例えば、他のゲームアプリ内でも利用可能である共通のゲーム内通貨であってもよいし、他のゲームアプリにおいても利用可能なアイテム類であってもよい。

また、報酬額の変化について、本実施形態の説明では、説明を簡略化するため、ボーナスステージをプレイしたか否かの２段階での変化を例に説明するが、他の実施形態では、より多段階に変化させてもよい。例えば、ボーナスステージをプレイしなかった場合は５０ベル、プレイはしたが、ボーナスステージのクリアはできなかった場合は６０ベル、ボーナスステージのクリアまでできた場合は８０ベル、ボーナスステージをクリアし、かつ、ボーナスステージのプレイにおいて所定の条件を達成していた場合は、１００ベル、というように、報酬額を細分化し、より多段階の報酬体系にしてもよい。

また、報酬内容を変化させる条件について、本実施形態では、ボーナスステージをプレイしたか否か、という条件を用いるが、他の実施形態では、この他の条件を利用するようにしても良い。例えば、ボーナスステージである特定のアイテムを取得したか否か、ある特定の敵キャラクタを倒したか否か、のような、ボーナスステージのプレイ中における所定の条件の達成を判定するようにしても良い。また、ターン制で進むゲーム等において、所定のターン数以内に上記のような条件を満たしたか、というような判定を行っても良い。また、その他、ボーナスステージの終了時に、所定の条件が満たされているか否か、という条件を利用してもよい。例えば、クリア時の最終得点が所定値以上であるか否か、等の条件を利用してもよい。また、その他、例えば、承諾を得られることによって、ゲーム内で所定の行動を行うための「行動ポイント」を得られるようなゲームにおいて、その「行動ポイント」を消費したか否かという条件を利用してもよい。

また、その他、上記承諾を受けたことに対して、要請元プレイヤ側が何らかのリアクションを返したか否か、を条件として利用しても良い。例えば、ボーナスステージのプレイ終了時に、承諾を行ってくれた被要請プレイヤに対して「ありがとう」等の返事を送信できるように構成する。そして、この返事が被要請プレイヤ側に届いているか否かを条件として利用しても良い。また、その他、協力要請を送った要請元プレイヤが、被要請プレイヤからの承諾を受けとったことを認識したことを条件としてもよい。例えば、被要請プレイヤからの承諾を受けたとき、何らかの形で要請元プレイヤに「通知」を行い、その通知に対して要請元プレイヤが「既読」をつけることを条件としても良い。

また、ロックされるゲーム要素についても、上記のような素材収集用のボーナスステージに限らない。例えば、ＲＰＧ等におけるいわゆる「ボス」キャラがいるボスステージを、上記ロック対象としてもよい。具体的には、「ボス」キャラに挑戦するために、所定数のフレンドの協力が必要である、という構成等を採用してもよい。また、ボスステージの他、各種クエストへの挑戦権を得るための条件として、フレンド等の他のプレイヤからの協力を必要とする構成としてもよい。また、その他、クエストのプレイ中に上記のような協力要請を行い、そのプレイ中に承諾を得ることができれば、いわゆる「隠しステージ」に進むことが可能となる構成としてもよい。更には、ゲーム中における「必殺技」の使用可能条件として、上記のような他プレイヤの協力を得ることが必要となる構成としてもよい。例えば、ボスキャラとの戦闘中に、他プレイヤに協力要請を送信し、これに対して承諾を所定数以上得ることができれば、「必殺技」が使用可能となるような構成を採用してもよい。また、必殺技に限らず、例えばそれを使用することで、プレイヤが有利になるような各種アイテム、技、スキル、魔法等を対象としても良い。

また、上記実施形態では、協力要請が可能な相手がフレンドである場合を例としたが、この他、例えばサーバ側で、フレンドに限らない所定数のプレイヤ、例えば、その時点でアクティブ状態であるユーザ等を抽出し、これを提示して、協力要請相手を選ばせるような構成でもよい。

また、上記チケットの利用態様として、必要承諾数に足りない分をチケットで補うという態様を採用してもよい。例えば、１人分の承諾をチケット１０枚で補うことも可能であるように構成しても良い。一例として、フレンドの承諾が５人分必要な場合であって、誰からの承諾を得られていない場合は、５人分の承諾を５０枚のチケットで補うことができる。また、同様の条件で４人分の承諾が集まっている場合は、残り１人分の承諾をチケット１０枚で補うことができるようにしてもよい。

なお、上記実施形態では、チケットを使用した場合は、ロックの有無にかかわらず即時にボーナスステージのプレイ処理が実行される構成を例示した。また、フレンドからの承諾が所定数集まったタイミングで、ロックが解除されるという構成を例示した。そのため、フレンドからの承諾によりロックが解除されている状態でチケットを使用した場合は、承諾によるロック解除の状態を維持しつつ、チケット使用によるボーナスステージのプレイが開示されることになる。このようなボーナスステージのロック解除タイミングに関しては、これに限らず、以下のような構成としても良い。

まず、上記チケットを使用したタイミングで、ボーナスステージのロックが解除されるようにしてもよい。上記の例では、チケット使用で即時にボーナスステージのプレイが開始される構成であったが、この場合は、ロックが解除されるだけであるため、ボーナスステージを実際にプレイ開始するタイミングをチケット使用時と異ならせることができる。

また、フレンドからの承諾が所定数得られた場合、および、チケットを使用した場合は、「ロック解除行使権」が得られるだけの構成としてもよい。つまり、チケットを用いてボーナスステージの「ロック解除行使権」を購入できるような構成としても良い。そして、当該権利を行使したタイミングで、ボーナスステージのロックを解除するような構成としてもよい。この場合は、承諾が集まったタイミングおよびチケットの使用タイミングと、「ロック解除行使権」の行使タイミングと、ボーナスステージのプレイを開始するタイミングをそれぞれ異ならせることができる。なお、この「ロック解除行使権」の利用回数については、上記チケットの利用回数と同様の処理を行うようにすればよい。また、チケット使用による「ロック解除行使権」と、フレンドからの承諾による「ロック解除行使権」が併存する状態においては、いずれの「ロック解除行使権」を行使するかをプレイヤに選択させる構成とすればよい。また、上記実施形態における協力要請の「リセット」との関係で、「ロック解除行使権」についても、行使しないままであれば、例えば１６：００に「ロック解除行使権」を失うようにしてもよい。

また、上記の例では、協力要請や承諾の送受信についてインターネット経由の通信の場合を例に挙げた。これに限らず、他の実施形態では、端末同士を有線または無線で直接的に接続するローカル通信を用いて協力要請や承諾の送受信が行われる構成としてもよい。

１０１ サーバ
１０２ スマートデバイス
１１１ プロセッサ部
１１３ メモリ
１１４ 通信部
１１５ 操作部
１１６ 表示部
１２１ プロセッサ部
１２３ メモリ
１２４ 通信部

Claims (18)

1. 第１プレイヤにより操作される第１端末と、第２プレイヤにより操作される第２端末と、当該第１端末および当該第２端末と接続可能なサーバとを含む情報処理システムであって、
   前記第１端末は、前記第１プレイヤによるプレイが予め制限されている所定のゲーム要素に関する協力要請を前記サーバに送信する協力要請送信手段を備え、
   前記第２端末は、前記第２プレイヤの操作に基づいて、前記協力要請に対する承諾を前記サーバに送信する承諾送信手段を備え、
   前記サーバは、前記承諾を受信した場合に、前記所定のゲーム要素にかかる制限を解除し、実行可能な状態とする制限解除手段を備え、
   前記第１端末は、
   前記第１プレイヤの操作に基づいて、制限が解除された前記所定のゲーム要素を実行するゲーム要素実行手段と、
   前記制限が解除された後の前記ゲーム要素が実行されたことを示すデータを前記サーバに送信する関連データ送信手段をさらに備え、
   前記サーバは、前記データを受信した場合には第１の報酬を前記第２プレイヤに付与し、当該データを所定のタイミングまでに受信しなかった場合には第２の報酬を当該第２プレイヤに付与する報酬付与手段をさらに備える、情報処理システム。
2. 前記ゲーム要素は、所定のゲームステージ等（クエスト、ミッションを含む）である、請求項１に記載の情報処理システム。
3. 前記報酬付与手段は、前記第１の報酬として前記第２の報酬とは異なる内容の報酬を前記第２プレイヤに付与する、請求項１に記載の情報処理システム。
4. 前記報酬付与手段は、前記第１の報酬として前記第２の報酬よりも高い価値の報酬を前記第２プレイヤに付与する、請求項３に記載の情報処理システム。
5. 前記情報処理システムは、前記ゲーム要素実行手段による前記所定のゲーム要素の実行が終了した場合に、当該所定のゲーム要素の実行を再度制限する第１再制限手段をさらに備える、請求項１から請求項４のいずれかに記載の情報処理システム。
6. 前記情報処理システムは、前記制限解除手段によって前記所定のゲーム要素にかかる制限を解除し、実行可能な状態となった後、所定の期間が経過した場合には、当該所定のゲーム要素の実行を再度制限する第２再制限手段をさらに備える、請求項１から請求項５のいずれかに記載の情報処理システム。
7. 前記制限解除手段は、一定期間毎に第１の回数分、前記所定のゲーム要素にかかる制限の解除が可能である、請求項６に記載の情報処理システム。
8. 前記制限解除手段は、前記協力要請に対する複数の第２プレイヤからの承諾を受信した場合に、前記所定のゲーム要素にかかる制限を解除する、請求項１から請求項７のいずれかに記載の情報処理システム。
9. 前記情報処理システムは、前記第１プレイヤを識別する第１識別情報と、前記第２プレ
   イヤを識別する第２識別情報とを関連づけて記憶部に記憶する記憶手段をさらに備え、
   前記協力要請送信手段は、前記第１プレイヤに関連づけられている前記第２プレイヤに対して前記協力要請を送信する、請求項１から請求項８のいずれかに記載の情報処理システム。
10. 前記協力要請送信手段は、前記第１プレイヤに関連づけられている複数の前記第２プレイヤに対して前記協力要請を送信する、請求項９に記載の情報処理システム。
11. 前記協力要請送信手段は、前記第１プレイヤから前記協力要請を送信する操作を受け付けたとき、その都度、前記複数の前記第２プレイヤのいずれか１人を指定させて、前記指定にかかる第２プレイヤに協力要請を送信する、請求項１０に記載の情報処理システム。
12. 前記情報処理システムは、前記第１プレイヤの操作に基づいて、所定のアイテムの使用が指示されたことを判別するアイテム使用判別手段をさらに備え、
    前記制限解除手段は、前記所定のアイテムが使用された場合は、前記承諾の受信の有無にかかわらず、前記所定のゲーム要素にかかる制限を解除し、実行可能な状態とする、請求項１から請求項１１のいずれかに記載の情報処理システム。
13. 前記アイテム使用判別手段で判別される前記所定のアイテムは、課金アイテムである、請求項１２に記載の情報処理システム。
14. 前記情報処理システムは、前記ゲーム要素実行手段による前記所定のゲーム要素の実行が終了した場合に、当該所定のゲーム要素の実行を再度制限するゲーム要素実行再制限手段をさらに備え、
    前記制限解除手段は、一定期間毎に第２の回数分、前記課金アイテムの使用による前記所定のゲーム要素にかかる制限の解除が可能である、請求項１３に記載の情報処理システム。
15. 前記情報処理システムは、前記所定のゲーム要素の実行結果に応じて、前記第１プレイヤに所定のアイテムを付与するアイテム付与手段をさらに備える、請求項１から請求項１３のいずれかに記載の情報処理システム。
16. 第１プレイヤにより操作される第１端末と、第２プレイヤにより操作される第２端末と、当該第１端末および第２端末と接続可能なサーバとを含む情報処理システムを制御するコンピュータが実行する情報処理方法であって、
    前記コンピュータは、
    前記第１端末に、前記第１プレイヤによるプレイが予め制限されている所定のゲーム要素に関する協力要請を前記サーバに送信させる協力要請送信ステップと、
    前記第２端末に、前記第２プレイヤの操作に基づいて、前記協力要請に対する承諾を前記サーバに送信させる承諾送信ステップと、
    前記第１端末で前記送信した協力要請に対する承諾を受信した場合、前記サーバに、当該承諾に基づいて前記所定のゲーム要素にかかる制限を解除し、実行可能な状態にさせる制限解除ステップと、
    前記第１端末に、
    前記第１プレイヤの操作に基づき、制限が解除された前記所定のゲーム要素を実行させるゲーム要素実行ステップと、
    前記制限が解除された後の前記ゲーム要素が実行されたことを示すデータを前記サーバに送信する関連データ送信ステップとを実行させ、
    前記サーバに、前記データを受信した場合には第１の報酬を前記第２プレイヤに付与させ、当該データを所定のタイミングまでに受信しなかった場合には第２の報酬を当該第２プレイヤに付与させる報酬付与ステップと、を実行させる、情報処理方法。
17. 第１プレイヤにより操作される第１端末および第２プレイヤにより操作される第２端末と接続可能なサーバのコンピュータに実行させる情報処理プログラムであって、
    前記コンピュータを
    前記第１端末から、前記第１プレイヤによるプレイが予め制限されている所定のゲーム要素に関する協力要請を受信する協力要請受信ステップと、
    前記第２端末から、前記第２プレイヤの操作に基づいた前記協力要請に対する承諾を受信する承諾受信ステップと、
    前記承諾を受信した場合に、当該承諾に基づいて前記所定のゲーム要素にかかる制限を解除し、実行可能な状態とする制限解除ステップと、
    制限が解除された前記所定のゲーム要素が実行されたことを示すデータを、前記制限が解除された後の前記ゲーム要素の実行に関する関連データとして受信した場合には第１の報酬を前記第２プレイヤに付与し、当該データを所定のタイミングまでに当該関連データとして受信しなかった場合には第２の報酬を当該第２プレイヤに付与する報酬付与ステップとを実行させるための、情報処理プログラム。
18. 第１プレイヤにより操作される第１端末および第２プレイヤにより操作される第２端末と接続可能なサーバ装置であって、
    前記第１端末から、前記第１プレイヤによるプレイが予め制限されている所定のゲーム要素に関する協力要請を受信する協力要請受信手段と、
    前記第２端末から、前記第２プレイヤの操作に基づいた前記協力要請に対する承諾を受信する承諾受信手段と、
    前記承諾を受信した場合に、当該承諾に基づいて前記所定のゲーム要素にかかる制限を解除し、実行可能な状態とする制限解除手段と、
    制限が解除された前記所定のゲーム要素が実行されたことを示すデータを受信した場合には第１の報酬を前記第２プレイヤに付与し、当該データを所定のタイミングまでに受信しなかった場合には第２の報酬を当該第２プレイヤに付与する報酬付与手段を備える、サーバ装置。

Images