JP2022089072A - 情報処理システム、情報処理方法、情報処理プログラム - Google Patents

Abstract

【課題】複数のユーザと特定の対戦相手との間の対戦ゲームパートを有するゲームに関して、処理負荷を適切に分散させる。【解決手段】複数のユーザと特定の対戦相手との間の対戦ゲームパートを設定するゲームパート設定部と、対戦ゲームパートの進行に基づいて、特定の対戦相手に対応付けられる第１パラメータの値を更新する第１更新部と、対戦ゲームパートの進行に基づいて、特定の対戦相手に対応付けられる第２パラメータの値を更新する第２更新部と、を備え、第１更新部は、第２更新部により更新された第２パラメータの値に基づいて、第２更新部よりも少ない更新頻度で第１パラメータの値を更新する、情報処理システムが開示される。【選択図】図９

Description

本開示は、情報処理システム、情報処理方法、情報処理プログラムに関する。

複数のユーザがグループとなって特定の対戦相手（コンピュータ制御される敵キャラクタ）と対戦する対戦ゲームパート（例えば、レイドと称される対戦ゲームパート）を有するゲームに適用可能な情報処理技術が知られている。

特開２０２０－１６２７７３公報

上記のようなレイド又はその類の対戦ゲームパートでは、複数のユーザの数が膨大となると、特定の対戦相手のＨＰ（ＨｉｔＰｏｉｎｔ）の値を更新するための処理負荷が高まりやすい。

そこで、１つの側面では、本発明は、複数のユーザと特定の対戦相手との間の対戦ゲームパートを有するゲームに関して、処理負荷を適切に分散させることを目的とする。

１つの側面では、複数のユーザと特定の対戦相手との間の対戦ゲームパートを設定するゲームパート設定部と、
前記対戦ゲームパートの進行に基づいて、前記特定の対戦相手に対応付けられる第１パラメータの値を更新する第１更新部と、
前記対戦ゲームパートの進行に基づいて、前記特定の対戦相手に対応付けられる第２パラメータの値を更新する第２更新部と、を備え、
前記第１更新部は、前記第２更新部により更新された前記第２パラメータの値に基づいて、前記第２更新部よりも少ない更新頻度で前記第１パラメータの値を更新する、情報処理システムが提供される。

１つの側面では、本発明によれば、複数のユーザと特定の対戦相手との間の対戦ゲームパートを有するゲームに関して、処理負荷を適切に分散させることが可能となる。

本発明の一実施形態に係るゲームシステムのブロック図である。 比較例によるレイドゲームパートの概念の説明図である。 本実施形態によるレイドゲームパートの概念の説明図である。 比較例によるレイドゲームパートでの処理負荷の説明図である。 本実施形態によるレイドゲームパートでの処理負荷の説明図である。 ユーザ情報の一例を示す図である。 ゲーム媒体に関する情報の一例を示す図である。 ボスキャラ情報の一例を示す図である。 サーバ装置により実現される各種機能のうちの、レイドゲームパートに関連した機能の説明図である。 ゲームデータ記憶部内のゲームデータの説明図である。 小ボスバトルパートに係るゲーム画像の一例を示す図である。 小ボスバトルパートの終了に伴う大ボスのＨＰの値の更新を示すゲーム画像の一例を示す図である。 各ユーザからの小ボスバトルパートの設定要求に係る処理の一例を示す概略的なフローチャートである。 図１３の選択用画像生成処理（ステップＳ１１０４）の処理の一例を示す概略的なフローチャートである。 図１３の選択用画像生成処理（ステップＳ１１０４）の処理の他の一例を示す概略的なフローチャートである。 小ボスバトルパートにおける減算指示生成処理の一例を示す概略的なフローチャートである。 大ボスバトルパートにおけるＨＰ減算処理の一例を示す概略的なフローチャートである。

以下、添付図面を参照しながら各実施形態について詳細に説明する。なお、本明細書において、用語“対応付け”又はそのたぐいに関して、「ＡとＢとが対応付けられている」とは、ＡとＢとが直接的に対応付けられているのみならず、ＡとＢとがＣ等を介して対応付けられている態様を含む概念である。

（ゲームシステムの概要）
図１を参照して、本発明の一実施形態に係るゲームシステム１の概要について説明する。ゲームシステム１は、サーバ装置１０と、１つ以上の端末装置２０（ユーザ端末の一例）と、を備える。図１では簡便のため、３つの端末装置２０を図示しているが、端末装置２０の数は２つ以上であればよい。

サーバ装置１０は、例えばゲーム運営者が管理するサーバ等の情報処理装置である。端末装置２０は、例えば携帯電話、スマートフォン、タブレット端末、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、ヘッドマウントディスプレイ、又はゲーム機等の、ユーザによって使用される情報処理装置である。端末装置２０は、本実施形態に係るゲームのアプリケーションを実行可能である。ゲームのアプリケーションは、ネットワーク３０を介して所定のアプリケーション配信サーバから端末装置２０に受信されてもよく、あるいは端末装置２０に備えられた記憶装置又は端末装置２０が読取可能なメモリカード等の記憶媒体に予め記憶されていてもよい。サーバ装置１０及び端末装置２０は、ネットワーク３０を介して通信可能に接続される。例えば、サーバ装置１０及び端末装置２０が協働して、ゲームに関する多様な処理を実行する。

なお、ネットワーク３０は、無線通信網や、インターネット、ＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、有線ネットワーク、又はこれらの任意の組み合わせ等を含んでよい。
（ゲームの概要）
本実施形態に係るゲームの概要について説明する。本実施形態に係るゲームは、１つ以上のゲームパートを含む。１つ以上のゲームパートのうち少なくとも１つのゲームパートは、ゲーム媒体を用いて実行されてもよい。

ゲーム媒体は、ゲームに使用される電子データであり、例えば、カード、アイテム、ポイント、仮想通貨、チケット、キャラクタ、アバタ、パラメータ等、任意の媒体を含む。また、ゲーム媒体は、ユーザによってゲーム内で取得、所有、使用、管理、交換、合成、強化、売却、廃棄、又は贈与等され得る電子データであるが、ゲーム媒体の利用態様は本明細書で明示されるものに限られない。なお、ゲーム媒体は、レベル情報、ステータス情報、パラメータ情報（体力値及び攻撃力等）又は能力情報（スキル、アビリティ、呪文、ジョブ等）のような、ゲーム関連情報であってもよい。

以下、特に明示した場合を除き、「ユーザが所有するゲーム媒体」とは、当該ユーザを一意に識別可能なユーザＩＤに所有ゲーム媒体として対応付けられたゲーム媒体を示す。また、「ゲーム媒体をユーザに付与する」とは、ゲーム媒体を所有ゲーム媒体としてユーザＩＤに対応付けることを示す。また、「ユーザが所有するゲーム媒体を破棄する」とは、ユーザＩＤと所有ゲーム媒体との対応付けを解消することを示す。また、「ユーザが所有するゲーム媒体を消費する」とは、ユーザＩＤと所有ゲーム媒体との対応付けの解消に応じて、何らかの効果又は影響をゲーム内で発生させ得ることを示す。また、「ユーザが所有するゲーム媒体を売却する」とは、ユーザＩＤと所有ゲーム媒体との対応付けを解消し、且つ、ユーザＩＤに他のゲーム媒体（例えば、仮想通貨又はアイテム等）を所有ゲーム媒体として対応付けることを示す。

ゲームパートは、ゲーム内でユーザがプレイ可能なコンテンツであって、例えばクエスト、ミッション、ミニゲーム、ゲーム媒体の育成、強化、及び合成、ゲーム媒体入手イベント、仮想空間の探索イベント、並びに対戦相手（例えば、他のユーザ、敵キャラクタ、及び敵の建物等）との対戦イベント等を含んでよい。

１つ以上のゲームパートには、シングルプレイ用のゲームパートと、マルチプレイ用のゲームパートと、が含まれてもよい。シングルプレイ用のゲームパートは、例えば、１人のユーザが使用する１つの端末装置２０に対するユーザ操作に基づいて実行されるゲームパート（例えば、一人用のゲームパート）を含んでもよい。一方、マルチプレイ用のゲームパートは、例えば、２人以上のユーザがそれぞれ使用する２つ以上の端末装置２０に対するユーザ操作に基づいて実行される、当該２人以上のユーザに共通のゲームパート（例えば、複数人用のゲームパート）を含んでもよい。２人以上のユーザに共通のゲームパートは、例えば、当該ゲームパートの進行処理の少なくとも一部及び処理結果の少なくとも一部が、当該２人以上のユーザに対して共通して適用されるゲームパートを含んでもよい。例えば、２つ以上の端末装置２０が協働して、又は２つ以上の端末装置２０とサーバ装置１０とが協働して、マルチプレイ用のゲームパートを実行する。

本実施形態では、１つ以上のゲームパートには、マルチプレイ用のゲームパートの１つとして、レイドゲームパートを含む。レイドゲームパートは、複数のユーザがグループとなって特定の対戦相手（以下、「大ボスｍ１」と称する）と対戦する対戦ゲームパートである。大ボスｍ１は、レイドボス等と称される非常に強力なキャラクタであって、例えばＮＰＣ（Ｎｏｎ－Ｐｌａｙｅｒ Ｃｈａｒａｃｔｅｒ）等の自動的に操作されるゲーム媒体である。ただし、変形例では、大ボスｍ１は、所定のプレイヤにより手動で操作されてもよい。この場合、大ボスｍ１は、ある一定期間だけ、所定のプレイヤにより手動で操作されてもよいし、全期間にわたって、所定のプレイヤにより手動で操作されてもよい。

図２は、比較例によるレイドゲームパートの概念の説明図であり、図３は、本実施形態によるレイドゲームパートの概念の説明図である。

比較例によるレイドゲームパートは、図２に概念的に示すように、非常に強い大ボスｍ１を、各ユーザの第１ゲーム媒体ｍ０が協力して倒す仕様であり、各ユーザの第１ゲーム媒体ｍ０は、大ボスｍ１に対して直接的に攻撃を加える。なお、各ユーザの端末装置２０には、大ボスｍ１と自身の第１ゲーム媒体ｍ０との対戦ゲームパートが実行される。各ユーザは、端末装置２０を介して第１ゲーム媒体ｍ０を操作するので、攻撃タイミング等はまちまちでありうる。このような、レイドゲームパートでは、大ボスｍ１に係るＨＰの値を更新するための処理負荷が、ユーザ数（端末装置２０の数）が膨大となると、高まりやすい。

これに対して、本実施形態によるレイドゲームパートは、図３に概念的に示すように、大ボスｍ１の“分身”である小ボスｍ２が、大ボスｍ１の代わりに、各ユーザからの攻撃を受ける。小ボスｍ２は、大ボスｍ１と同じく、例えばＮＰＣ等の自動的に操作されるゲーム媒体である。ただし、変形例では、小ボスｍ２は、所定のプレイヤにより手動で操作されてもよい。例えば、複数の小ボスｍ２のうちの一部は、所定のプレイヤにより手動で操作されてもよいし、ある一定期間だけ、１つ以上の小ボスｍ２が、所定のプレイヤにより手動で操作されてもよい。なお、各ユーザの端末装置２０には、それぞれの小ボスｍ２と自身の第１ゲーム媒体ｍ０との対戦ゲームパートが実行される。各ユーザは、端末装置２０を介して第１ゲーム媒体ｍ０を操作する。小ボスｍ２が各ユーザの第１ゲーム媒体ｍ０からの攻撃により倒されると、その小ボスｍ２の割当分だけのＨＰの値が、大ボスｍ１のＨＰの値から減算される。すなわち、大ボスに小ボスｍ２のＨＰが対応付けられる。このようにして、各ユーザは、小ボスｍ２への攻撃を介して、大ボスｍ１のＨＰの値を減らすことができる。なお、小ボスｍ２は、大ボスｍ１のＨＰの値が０になるまで、倒されても次々に出現する。すなわち、小ボスｍ２は、大ボスｍ１のＨＰの値が最終的に０になることができる数、用意される。このようにして、大ボスｍ１の分身としての小ボスｍ２の概念を導入することで、大ボスｍ１に係るＨＰの値を更新するための処理負荷を低減できる。

図４は、図２に示した比較例によるレイドゲームパートでの処理負荷の説明図であり、図５は、本実施形態によるレイドゲームパートでの処理負荷の説明図である。

図４及び図５では、横軸に時間を取り、各処理のタイミングが模式的に示されている。図４及び図５において、矢印Ａ１から矢印Ａ４は、各ユーザからの攻撃タイミングを模式的に表し、区間Ｐ１～Ｐ４、Ｑ１、Ｑ２は、対応する処理タイミングを模式的に表す。

図４に示す比較例によるレイドゲームパートでは、区間Ｐ１～Ｐ４は、各ユーザからの攻撃（矢印Ａ１から矢印Ａ４参照）にそれぞれ応答して、大ボスｍ１のＨＰの値を減算する処理に対応する。なお、大ボスｍ１のＨＰの値を減算する処理は、各ユーザの端末装置２０における大ボスｍ１のＨＰ表示を更新するための処理も含む場合がある。

このように、図４に示す比較例によるレイドゲームパートでは、各ユーザからの攻撃（矢印Ａ１から矢印Ａ４参照）ごとに、大ボスｍ１のＨＰの値を減算する処理が発生する。例えば、４回分の攻撃に対して、大ボスｍ１のＨＰの値を減算する処理は、４回実行される。

これに対して、図５に示す本実施形態によるレイドゲームパートでは、比較例の場合と同じ各ユーザからの攻撃（矢印Ａ１から矢印Ａ４参照）が発生したとき、それぞれ応答して、小ボスに係るＨＰ減算処理と、大ボスｍ１に係るＨＰ減算処理とが発生する。具体的には、図５において、セクション５０１は、一の小ボスｍ２に係るＨＰ減算処理を表し、セクション５０２は、他の一の小ボスｍ２に係るＨＰ減算処理を表し、セクション６００は、大ボスｍ１に係るＨＰ減算処理を表す。

図５に示す本実施形態によるレイドゲームパートでは、比較例の場合とは異なり、各ユーザからの攻撃（矢印Ａ１から矢印Ａ４参照）ごとに、大ボスｍ１のＨＰの値を減算する処理が発生することはない。例えば、４回分の攻撃に対して、大ボスｍ１に係るＨＰ減算処理は、区間Ｑ１、Ｑ２の２回実行される（矢印Ａ１０、Ａ２０参照）。

このようにして、本実施形態によれば、大ボスｍ１が各ユーザから攻撃（矢印Ａ１から矢印Ａ４参照）を受ける頻度よりも少ない頻度（矢印Ａ１０、Ａ２０参照）で、大ボスｍ１に係るＨＰ減算処理を実行できる。これにより、レイドゲームパートにおける大ボスｍ１に係るＨＰ減算処理の負荷を低減できる。換言すると、本実施形態によれば、小ボスｍ２に係るＨＰ減算処理を介して、大ボスｍ１に係るＨＰ減算処理を実現できるので、処理負荷が分散され、その結果、レイドゲームパートにおける大ボスｍ１に係るＨＰ減算処理の負荷を低減できる。

なお、図４及び図５では、各ユーザから大ボスｍ１が攻撃を受けたときの、大ボスｍ１に係るＨＰ減算処理に関するものであるが、大ボスｍ１からの攻撃を各ユーザに係る第１ゲーム媒体ｍ０に与えるときの処理等についても同様である。例えば、第１ゲーム媒体ｍ０ごとに大ボスｍ１から攻撃を直接的に与える場合、一の攻撃あたり第１ゲーム媒体ｍ０の数分だけ、第１ゲーム媒体ｍ０のＨＰの値を減らすための処理が発生しうる。これに対して、大ボスｍ１が攻撃を複数の小ボスｍ２を介して複数の第１ゲーム媒体ｍ０に与えることで、レイドゲームパートにおける大ボスｍ１に係る処理の負荷を低減できる。この場合、複数の小ボスｍ２は、大ボスｍ１の攻撃をそのまま実現してもよいし、大ボスｍ１の攻撃を、小ボスｍ２の数分だけ分割した攻撃を実現してもよい。あるいは、各小ボスｍ２の攻撃は、大ボスｍ１の攻撃をトリガとせずに、それぞれ独自に実現されてもよい。この場合、大ボスｍ１の直接的な攻撃に係る処理を無くすことができる。あるいは、大ボスｍ１の攻撃という概念はなく、各小ボスｍ２の攻撃がそれぞれ独自に実現されてもよい。

次に、図１を再度参照しつつ、図６以降を参照して、本実施形態によるゲームシステム１を、より詳細に説明する。

（サーバ装置の構成）
サーバ装置１０の構成について具体的に説明する。サーバ装置１０は、サーバコンピュータにより構成される。サーバ装置１０は、複数台のサーバコンピュータにより協動して実現されてもよい。また、サーバ装置１０は、Ｗｅｂサーバを含んでよい。この場合、後述する端末装置２０の機能の一部は、Ｗｅｂサーバから受領したＨＴＭＬ文書やそれに付随する各種プログラム（Ｊａｖａｓｃｒｉｐｔ）をブラウザが処理することによって実現されてもよい。

サーバ装置１０は、サーバ通信部１１と、サーバ記憶部１２と、サーバ制御部１３と、を備える。

サーバ通信部１１は、外部装置と無線又は有線によって通信し、情報の送受信を行うインタフェースを含む。サーバ通信部１１は、例えば無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）通信モジュール又は有線ＬＡＮ通信モジュール等を含んでもよい。サーバ通信部１１は、ネットワーク３０を介して、端末装置２０との間で情報を送受信可能である。

サーバ記憶部１２は、例えば一次記憶装置及び二次記憶装置を含む。例えばサーバ記憶部１２は、半導体メモリ、磁気メモリ、又は光メモリ等を含んでもよい。サーバ記憶部１２は、ゲームの処理に用いられる種々の情報及びプログラムを記憶する。サーバ記憶部１２に記憶された情報及びプログラムの少なくとも一部が、端末装置２０との間で共有及び同期されてもよい。以下、サーバ記憶部１２が記憶する情報の例について具体的に説明する。
（ユーザに関する情報）
サーバ記憶部１２（ユーザ情報記憶部の一例）は、複数のユーザそれぞれに関する情報（「ユーザ情報」とも称する）を記憶する。図６を参照して、ユーザ情報について説明する。図６は、２人のユーザそれぞれに関する情報を示す。ユーザ情報は、当該ユーザに固有の種々の情報を含む。例えば、ユーザ情報は、ユーザＩＤと、ユーザ名と、ランクと、所有ゲーム媒体に関する情報と、使用ゲーム媒体に関する情報と、フレンド情報とを含む。ユーザ情報において、複数のユーザそれぞれと、所有ゲーム媒体に関する情報及び使用ゲーム媒体に関する情報と、フレンド情報とが対応付けられている。

ユーザＩＤは、ユーザを一意に識別可能な情報である。以下、ユーザＩＤを単にユーザともいう。

ユーザ名は、ユーザの名前を示す情報である。ユーザ名は、ユーザＩＤとは異なり、ユーザを一意に識別可能でなくてもよい。ユーザ名は、端末装置２０に対するユーザ操作に応じて任意に決定及び変更が可能であってもよい。

ランクは、ゲームに関するユーザの熟練度を示すパラメータである。本実施形態において、ランクの値は、ユーザによるゲームのプレイに応じて増加してもよい。ランクが高いほど、ゲームに関するユーザの熟練度が高い。

所有ゲーム媒体に関する情報は、ユーザがゲーム内で所有するゲーム媒体（所有ゲーム媒体）に固有の種々の情報を含む。ゲーム媒体がユーザに取得された場合、当該ゲーム媒体は、所有ゲーム媒体としてユーザに対応付けられる。所有ゲーム媒体に関する情報の詳細については後述する。

使用ゲーム媒体に関する情報は、対戦ゲームパート（例えばレイドゲームパート）においてユーザに使用させるゲーム媒体（第１ゲーム媒体）を示す情報である。第１ゲーム媒体は、所有ゲーム媒体のうちから選択される。

フレンド情報は、フレンド関係にあるユーザＩＤを表す。例えば、ユーザＡが、ユーザＢ、Ｃとフレンド関係である場合、ユーザＡに対応付けられたフレンド情報は、ユーザＢ、ＣのユーザＩＤを含む。なお、フレンド関係は、フレンド申請等を介して実現される。このように、フレンド情報は、ユーザとの間で一方向的又は双方向的に関連付けられた他のユーザのユーザＩＤを含む。なお、フレンド関係にあるユーザ同士は、例えばゲームシステム１上でメッセージの送受信等のコミュニケーションが可能であってもよい。なお、ユーザ情報において、フレンド情報に代えて又は加えて、所属するギルドやパーティを示す情報が含められてもよい。

ユーザ情報の内容は、上述したものに限られない。例えば、ユーザ情報は、ユーザがゲーム内で保有する所定のポイントを示す情報を更に含んでもよい。当該ポイントは、ユーザがゲームパートをプレイするために消費される。ゲームパートごとに、当該ポイントの消費量が異なってもよい。当該ポイントは、例えば時間経過に応じて、又は所定のゲーム媒体の使用に応じて、増加してもよい。

ここで、図７を参照して、上述した所有ゲーム媒体に関する情報の一例について詳細に説明する。図７は、１人のユーザに対応付けられた２つの所有ゲーム媒体に関する情報を示す。例えば、各所有ゲーム媒体に関する情報は、ゲーム媒体ＩＤと、ゲーム媒体名と、レアリティと、レベルと、コストと、ＨＰの初期値と、攻撃力と、回復力と、ゲーム機能に関する情報と、を含む。

ゲーム媒体ＩＤは、ゲーム媒体を一意に識別可能な情報である。ゲーム媒体ＩＤは、予めサーバ記憶部１２に記憶されてもよい。あるいは、ゲーム媒体ＩＤは、ゲーム媒体をユーザに取得させるときに、サーバ装置１０によって決定されてもよい。

ゲーム媒体名は、ゲーム媒体の名前を示す情報である。ゲーム媒体名は、ゲーム媒体ＩＤとは異なり、ゲーム媒体を一意に識別可能でなくてもよい。なお、ゲーム媒体名は、ゲーム媒体を取得したユーザによるゲームのプレイに応じて変化してもよい。

レアリティは、ゲーム媒体の希少度（希少価値）を示す情報である。

レベルは、ゲーム媒体の成長度を示す情報である。例えば、レベルの値が大きいほど、ゲーム媒体の成長度が大きい。レベルの値は、ユーザによるゲームのプレイに応じて増加してもよい。また、第１ゲーム媒体に係るレベルは、第１ゲーム媒体ごとに上限レベルが設定されてよい。この場合、第１ゲーム媒体の上限レベルは、例えばレアリティが高いほど高くなる態様で設定されてよい。また、第１ゲーム媒体の上限レベルは、特定の強化（例えば限界突破）により引き上げ可能とされてもよい。

コストは、対戦ゲームパートに使用するデッキを決定する際に用いられるパラメータである。例えば、各第１ゲーム媒体のコストの合計値が所定の上限ＨＰを超えない範囲で、最大５つの第１ゲーム媒体が１つのデッキに包含可能であってもよい。この場合、当該上限ＨＰは、例えばユーザのランクの増加に応じて増加してもよい。

ＨＰは、対戦ゲームパートにおけるユーザの勝敗を決定するために用いられるパラメータである。例えば、デッキを構成して対戦ゲームパートが実現される場合、デッキに含まれるすべての第１ゲーム媒体のＨＰの初期値の合計と、所定の上限ＨＰのうちの、いずれか小さい方が、対戦ゲームパートの開始時におけるデッキに係るＨＰの初期値として用いられる。対戦ゲームパートの実行中に、例えば対戦相手の攻撃によってユーザにダメージが与えられると、当該ダメージの量だけＨＰの値が減少する。対戦ゲームパートの実行中に、例えば回復アイテムが取得されると、ＨＰの値が増加する。ＨＰの値が所定値以上減少すると、ユーザの敗北と判定される。所定値は、ＨＰの初期値に対応する。この場合、ＨＰの値が０まで減少すると、ユーザの敗北と判定される。従って、各第１ゲーム媒体のＨＰの初期値が大きいほどユーザに有利である。レベルの増加に応じて、ＨＰの初期値が増加してもよい。

攻撃力は、例えばゲーム媒体の攻撃によって対戦相手に与えるダメージ量に寄与する情報である。攻撃力の値が大きくなるほど、対戦相手に与えるダメージ量が大きくなる。従って、ゲーム媒体の攻撃力が大きいほどユーザに有利である。レベルの増加に応じて、攻撃力が増加してもよい。

回復力は、対戦ゲームパートの実行中に用いられるパラメータである。例えば、デッキを構成して対戦ゲームパートが実現される場合、デッキに含まれるすべての第１ゲーム媒体の回復力の合計が用いられる。対戦ゲームパートの実行中に、例えば回復アイテムが取得されると、ユーザの回復力が増加する。回復力の値が大きくなるほど、ＨＰの値の増加量が大きくなる。従って、デッキに含まれる各第１ゲーム媒体の回復力が大きいほどユーザに有利である。レベルの増加に応じて、回復力が増加してもよい。

ゲーム機能に関する情報は、ゲーム媒体に対応付けられたゲーム機能の情報を含む。ゲーム機能は、ゲーム媒体に対応付けられた特別な機能（スキルやアビリティ）であってよい。また、１つのゲーム媒体に任意の数のゲーム機能が対応付けられてもよい。ゲーム機能が発揮されると、例えば対戦ゲームパートにおいて所定のゲーム効果が発生し得る。ゲーム効果の内容は、任意に定められてもよい。例えば、対戦相手に、通常の攻撃よりも大きなダメージを与えるゲーム効果が存在してもよいし、対戦相手の攻撃を弱くするゲーム効果が存在してもよい。発生したゲーム効果が、所定の期間に亘って継続してもよい。

ゲーム機能に関する情報の内容は、上述したものに限られない。例えばゲーム機能に関する情報は、当該ゲーム機能のレベル及び経験値を更に含んでもよい。例えば、ユーザが所有する所定のゲーム媒体を消費することによって、ゲーム機能の経験値が増加してもよい。また、ゲーム媒体ＩＤに対応付けられる各種情報は、図７を参照して上述したものに限られず、任意である。
（対戦相手であるゲーム媒体に関する情報）
図１に示すサーバ記憶部１２は、対戦ゲームパートにおける対戦相手であるゲーム媒体（例えば、ＮＰＣ）に関する情報（以下、「ボスキャラ情報」とも称する）を記憶する。

ここで、図８を参照して、上述したボスキャラ情報の一例について詳細に説明する。本実施形態では、ボスキャラ情報は、大ボスｍ１とその小ボスｍ２に関する情報を含む。図８は、２つの大ボスｍ１に関する情報を示す。例えば、各大ボスｍ１に関する情報は、ゲーム媒体ＩＤ（第１識別子の一例）と、ゲーム媒体名と、属性と、ＨＰの初期値と、攻撃力と、回復力と、ゲーム機能に関する情報と、を含む。ゲーム媒体ＩＤ、ゲーム媒体名、ＨＰの初期値、攻撃力等は、上述した所有ゲーム媒体に関する情報と同様であるため、説明は省略する。ただし、大ボスｍ１は非常に強力であるので、ＨＰの初期値や攻撃力等は非常に大きい。これは、小ボスｍ２についても同様である。属性は、大ボスｍ１であることを示す情報である。小ボスｍ２に関する情報は、ゲーム媒体ＩＤ（第２識別子の一例）と、ゲーム媒体名と、属性と、ＨＰの初期値と、攻撃力と、回復力と、ゲーム機能に関する情報と、を含む。この場合、属性は、小ボスｍ２であることを示すとともに、どの大ボスｍ１に対する小ボスｍ２であるかを示す情報（すなわち、大ボスｍ１のゲーム媒体ＩＤと小ボスｍ２のゲーム媒体ＩＤとを対応付ける情報）である。例えば、図８に示す例では、ゲーム媒体ＩＤ“Ｗ０１”の小ボスｍ２は、ゲーム媒体ＩＤ“Ｖ０１”の大ボスｍ１の分身として機能する小ボスｍ２である。なお、一の大ボスｍ１の分身として機能する小ボスｍ２に対応付けられるＨＰの初期値は、当該一の大ボスｍ１に対応付けられるＨＰの初期値よりも有意に小さい。例えば、一の大ボスｍ１の分身として機能する小ボスｍ２に対応付けられるＨＰの初期値は、当該一の大ボスｍ１に対応付けられるＨＰの初期値の、１／１０００以下であってもよいし、それよりも小さくてもよい。ただし、後述するように、小ボスｍ２に対応付けられるＨＰの初期値は、適宜変化する態様で、設定されてもよい。他方、小ボスｍ２の攻撃力、回復力、及びゲーム機能に関する情報の少なくともいずれかは、大ボスｍ１の攻撃力、回復力、及びゲーム機能に関する情報と同じであってもよい。

また、ボスキャラ情報は、図８に示すように、ゲーム媒体ＩＤに、描画用情報が対応付けられてよい。描画用情報は、対応付けられたゲーム媒体ＩＤに係るゲーム媒体を描画するために情報であり、描画用情報が同じであれば、描画されるゲーム媒体も基本的に同じ見た目（姿や形）となる。本実施形態では、一の大ボスｍ１に対応付けられる描画用情報は、当該一の大ボスｍ１の分身である小ボスｍ２に対応付けられる描画用情報と同じであるものとする。従って、大ボスｍ１と小ボスｍ２は、ゲーム画像上では同じに見える。ただし、小ボスｍ２は、大ボスｍ１よりも小さいサイズで描画されてもよい。この場合、小ボスｍ２が、大ボスｍ１の“分身”であることをユーザに示唆できる。ただし、変形例では、一の大ボスｍ１に対応付けられる描画用情報と、当該一の大ボスｍ１の分身である小ボスｍ２に対応付けられる描画用情報とは、互いに連想できる関係で僅かな相違が設定されてもよい。

図１に示すサーバ制御部１３は、１つ以上のプロセッサを含む。プロセッサは、特定のプログラムを読み込むことにより特定の機能を実現する汎用プロセッサ、及び特定の処理に特化した専用プロセッサを含んでもよい。サーバ制御部１３は、サーバ装置１０全体の動作を制御する。

サーバ制御部１３は、ゲームの処理に用いられる種々の情報及びプログラムを、サーバ記憶部１２に記憶する。ゲームの処理に用いられる情報には、上述したユーザ情報、及びボスキャラ情報等が含まれてもよい。

サーバ制御部１３は、サーバ通信部１１を介して情報の送受信を行う。例えば、サーバ制御部１３は、サーバ記憶部１２に記憶された情報の少なくとも一部を端末装置２０へ送信してもよい。このようにして、サーバ記憶部１２に記憶された情報と端末装置２０に記憶された情報が共有及び同期される。情報の共有及び同期を行うタイミングは、例えばサーバ記憶部１２に新たな情報が記憶されたタイミング、及びサーバ記憶部１２に記憶された情報が更新されたタイミングを含み得るが、任意に定められてもよい。

サーバ制御部１３は、端末装置２０と協働して、ゲームを実行する。例えば、サーバ制御部１３は、１つ以上の端末装置２０と協働して、対戦ゲームパート（例えばレイドゲームパート）を実行する。
（端末装置の構成）
端末装置２０の構成について具体的に説明する。図１に示すように、端末装置２０は、端末通信部２１と、端末記憶部２２と、表示部２３と、入力部２４と、端末制御部２５とを備える。

端末通信部２１は、外部装置と無線又は有線によって通信し、情報の送受信を行うインタフェースを含む。端末通信部２１は、例えばＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）（登録商標）等のモバイル通信規格に対応する無線通信モジュール、無線ＬＡＮ通信モジュール、又は有線ＬＡＮ通信モジュール等を含んでもよい。端末通信部２１は、ネットワーク３０を介して、サーバ装置１０との間で情報を送受信可能である。

端末記憶部２２は、例えば一次記憶装置及び二次記憶装置を含む。例えば端末記憶部２２は、半導体メモリ、磁気メモリ、又は光メモリ等を含んでもよい。端末記憶部２２は、サーバ装置１０から受信する、ゲームの処理に用いられる種々の情報及びプログラムを記憶する。ゲームの処理に用いられる情報及びプログラムは、端末通信部２１を介して外部装置から取得されてもよい。例えば、ゲームのアプリケーションプログラムが、所定のアプリケーション配信サーバから取得されてもよい。以下、アプリケーションプログラムを、単にアプリケーションともいう。また例えば、上述したユーザ情報及び対戦相手であるゲーム媒体に関する情報等の一部又は全部が、サーバ装置１０から取得されてもよい。

表示部２３は、例えば液晶ディスプレイ又は有機ＥＬ（Ｅｌｅｃｔｒｏ－Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ等の表示デバイスを含む。表示部２３は、多様な画像（例えば各種のゲーム画像）を表示可能である。

入力部２４は、例えば表示部２３と一体的に設けられたタッチパネルを含む入力インタフェースを含む。入力部２４は、端末装置２０に対するユーザ入力を受付可能である。また、入力部２４は、物理キーを含んでもよいし、マウス等のようなポインティングデバイスをはじめとする任意の入力インタフェースを更に含んでもよい。

端末制御部２５は、１つ以上のプロセッサを含む。端末制御部２５は、端末装置２０全体の動作を制御する。

端末制御部２５は、端末通信部２１を介して情報の送受信を行う。例えば、端末制御部２５は、ゲームの処理に用いられる種々の情報及びプログラムを、サーバ装置１０及び他の外部サーバの少なくとも一方から受信する。端末制御部２５は、受信された情報及びプログラムを、端末記憶部２２に記憶する。

端末制御部２５は、ユーザ操作に応じてゲームのアプリケーションを起動する。端末制御部２５は、サーバ装置１０と協働して、ゲームを実行する。例えば、端末制御部２５は、ゲームに用いられる種々のゲーム画像を表示部２３に表示させる。ゲーム画像には、例えばユーザ操作を検出するＧＵＩ（Ｇｒａｐｈｉｃ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）が重畳表示されてもよい。端末制御部２５は、入力部２４を介して、ゲーム画像を表示する画面に対するユーザ操作を検出可能である。
（レイドゲームパートに関連した構成）
次に、主に図９以降を参照して、レイドゲームパートに関連した構成について説明する。以下では、レイドゲームパートに関連したサーバ装置１０が、情報処理システムの一例を実現するが、後述するように、特定の一の端末装置２０の各要素（図１参照）が、情報処理システムの一例を実現してもよいし、複数の端末装置２０が、協動して情報処理システムの一例を実現してもよい。また、サーバ装置１０と１つ以上の端末装置２０が、協動して情報処理システムの一例を実現してもよい。

図９は、サーバ装置１０により実現される各種機能のうちの、レイドゲームパートに関連した機能の説明図である。なお、以下で説明するサーバ装置１０の機能の一部又は全部は、適宜、端末装置２０により実現されてもよい。図１０は、ゲームデータ記憶部１６０内のゲームデータの説明図である。なお、図１０等の表において、「＊＊＊」は何らかの情報が格納されている状態を表し、「・・・」は同様の繰り返しを表す。

サーバ装置１０は、ゲームパート設定部１５０と、参加管理部１５１と、小ボスバトル設定部１５２（第２パラメータ設定部の一例）と、大ボス関連処理部１５３と、小ボスバトル処理部１５４と、救援要請処理部１５５と、ゲーム状態管理部１５６と、同時プレイ検出部１５７（第３判定部の一例）と、画像生成部１５８と、報酬付与部１５９と、ゲームデータ記憶部１６０とを含む。

なお、ゲームパート設定部１５０から報酬付与部１５９は、図１に示したサーバ制御部１３により実現できる。また、ゲームパート設定部１５０から報酬付与部１５９のうちの、端末装置２０との通信を行う機能部は、図１に示したサーバ制御部１３とともにサーバ通信部１１により実現できる。また、ゲームデータ記憶部１６０は、図１に示したサーバ記憶部１２により実現できる。

ゲームパート設定部１５０は、レイドゲームパート（及びそれに伴い、当該レイドゲームパートに含まれる大ボスバトルパート等）を設定する。なお、以下で、「ゲームパートを設定する」処理とは、当該ゲームパートを、ユーザが参加可能又はプレイ可能な状態にする処理を指す。

例えば、ゲームパート設定部１５０は、期間限定で、レイドゲームパートを設定してもよい。この場合、例えば、何月何日何時からレイドゲームパートに係るイベントが開催される旨の告知が実行されてもよい。あるいは、ゲームパート設定部１５０は、ランダムなタイミングで、又は、所定の設定条件が成立したときに、レイドゲームパートを設定してもよい。

レイドゲームパートは、１つ以上の大ボスバトルパートを含む。一のレイドゲームパートが複数の大ボスバトルパートを含む場合、複数の大ボスバトルパートは、同時に並列的に進行してもよいし、１つずつ順次、進行してもよい。大ボスバトルパートのそれぞれは、１人以上のユーザに係る第１ゲーム媒体ｍ０が小ボスｍ２と対戦する小ボスバトルパートを含む。小ボスバトルパートは、後述するように、複数並列的に進行することができる。レイドゲームパートにおいては、後述するように、小ボスバトルパートが次々に設定されていく。

本実施形態では、一例として、一のレイドゲームパートにおいて、大ボスバトルパートは、複数設定される。複数の大ボスバトルパートのそれぞれには、一の大ボスｍ１が対応付けられる。複数の大ボスバトルパートのそれぞれに対応付けられる大ボスｍ１は、互いに異なってもよい。この場合、ゲームパート設定部１５０は、一の大ボスバトルパートが終了すると、次の一の大ボスバトルパートを設定するといった具合に、予定されている複数の大ボスバトルパートを、順次設定してもよい。なお、複数の大ボスバトルパートのそれぞれは、ランダムに選択されてもよいし、一回のレイドゲームパートあたりの大ボスバトルパートの数も可変であってよい。また、複数の大ボスバトルパート間には、他のゲームパートが介在してもよい。また、レイドゲームパートに参加中のユーザは、途中でアウトゲームをプレイできる仕様であってもよい。例えば、レイドゲームパートに参加中のユーザは、大ボスバトルパート間の空き時間を利用して、第１ゲーム媒体ｍ０の強化や育成等を行ってもよい。あるいは、レイドゲームパートに参加中のユーザは、大ボスバトルパートの進行を一時的に停止（中断）して、第１ゲーム媒体ｍ０の強化や育成等を行ってもよい。

レイドゲームパートは、一旦、進行が開始されると、最後の大ボスバトルパートが終了するまで継続される。以下では、レイドゲームパートの進行中とは、レイドゲームパートの進行が開始した時点から、すべての大ボスｍ１のＨＰの値が０になった時点までを指す。

参加管理部１５１は、レイドゲームパートへのユーザの参加状況を更新／管理する。レイドゲームパートへのユーザの参加は、レイドゲームパートの進行中であればいつでも可能とされてよい。レイドゲームパートへのユーザの参加方法は、任意である。例えば端末装置２０上のゲーム画像に設定されてよい参加ボタン（図示せず）が操作されると、参加要求がサーバ装置１０に送信される。なお、参加ボタンには、大ボスｍ１を表す表示が、当該大ボスｍ１に係る描画用情報（図８参照）により描画されてもよい。

この場合、参加管理部１５１は、このような参加要求に基づいて、対応するユーザの、レイドゲームパートへの参加状態を実現する。例えば、参加管理部１５１は、レイドゲームパートに参加したユーザに係る端末装置２０上のゲーム画像を、ロビー画像を含むゲーム画像へと移行させる。また、レイドゲームパートに一旦参加したユーザは、レイドゲームパートの進行中であればいつでも退出可能とされてよい。レイドゲームパートからのユーザの退出方法は、任意である。例えば端末装置２０上のゲーム画像に設定されてよい退出ボタン（図示せず）が操作されると、退出要求がサーバ装置１０に送信される。この場合、参加管理部１５１は、このような退出要求に基づいて、対応するユーザの退出を実現する。

参加管理部１５１は、参加状況が変化するごとに、ゲームデータ記憶部１６０内のゲームデータを更新する。図１０には、ゲームデータ記憶部１６０内のゲームデータのうちの、参加状況データ９００の一例が示されている。参加状況データ９００は、ユーザＩＤごとに、参加ステータスを含む。例えば、参加ステータスは、「対戦中」、「待機中」、「退出中」等を含んでよい。なお、「待機中」は、参加しているがロビー画像が表示されている状態等に対応し、「退出中」は、ログインしているがレイドゲームパートに参加していない状態に対応してよい。

また、参加状況データ９００は、ユーザＩＤごとに、小ボスｍ２の討伐数を含んでよい。小ボスｍ２の討伐数は、後述する小ボスバトルパートにおいて倒した小ボスｍ２の数である。また、参加状況データ９００は、ユーザＩＤごとに、大ボスｍ１の討伐数を含んでよい。大ボスｍ１の討伐数は、大ボスバトルパートにおいて倒した大ボスｍ１の数である。

小ボスバトル設定部１５２は、各ユーザ（端末装置２０）からの設定要求に応答して、小ボスバトルパートを設定する。小ボスバトルパートは、１人以上のユーザに係る第１ゲーム媒体ｍ０が小ボスｍ２と対戦するゲームパートである。ユーザによる小ボスバトルパートの設定方法は、任意である。例えば端末装置２０上のロビー画像に設定されてよいプレイボタン（図示せず）がユーザにより操作されると、端末装置２０から設定要求がサーバ装置１０に送信される。この場合、小ボスバトル設定部１５２は、このような設定要求に基づいて、対応するユーザに対応付ける小ボスバトルパートを設定する。なお、プレイボタンには、小ボスｍ２を表す表示が、当該小ボスｍ２に係る描画用情報（図８参照）により描画されてもよい。また、設定要求の送信（すなわち小ボスバトルパートのプレイ）は、所定のゲーム媒体（例えばユーザがゲーム内で保有する所定のポイント）の消費を伴ってもよい。

小ボスバトル設定部１５２は、多様な態様で、小ボスバトルパートを設定できる。例えば、小ボスバトル設定部１５２は、常に一定の設定態様で、小ボスバトルパートを設定してもよい。この場合、小ボスバトル設定部１５２は、一のユーザに一の小ボスバトルパートが対応付けられる態様で、一のユーザごとに小ボスバトルパートを設定してもよい。また、この場合、小ボスバトル設定部１５２は、一のユーザからの設定要求に応じて、一のユーザに対応付けられる一の小ボスバトルパートを、即座に設定してもよい。

あるいは、小ボスバトル設定部１５２は、所定数Ｎ１のユーザごとに、所定数Ｎ１のユーザに一の小ボスバトルパートが対応付けられる態様で、小ボスバトルパートを設定してもよい。この場合、所定数Ｎ１は、一定であってもよいし、可変であってよい。例えば、所定数Ｎ１は、参加中のユーザ数が多くなるほど、大きい数に設定されてもよい。この場合、小ボスバトル設定部１５２は、所定数Ｎ１のユーザからの設定要求が溜まった時点で、当該所定数Ｎ１のユーザからの設定要求に応じて、所定数Ｎ１のユーザに対応付けられる一の小ボスバトルパートを、設定してもよい。あるいは、小ボスバトル設定部１５２は、所定数Ｎ１のユーザに一の小ボスバトルパートが対応付けられるまで、各ユーザからの設定要求に応じて、各ユーザに同じ一の小ボスバトルパートを対応付けてもよい。この場合、一の小ボスバトルパートが設定されると、その後、所定数Ｎ１のユーザが当該一の小ボスバトルパートに対応付けられるまで、設定要求を新たに送信する各ユーザは、当該一の小ボスバトルパートに途中から参加する形態となる。

また、小ボスバトル設定部１５２は、所定数Ｎ１よりも有意に多い数Ｎ２のユーザからの設定要求が溜まった時点で、当該数Ｎ２のユーザからの設定要求に応じて、所定数Ｎ１のユーザごとに、各小ボスバトルパートを設定してもよい。この場合、数Ｎ２のユーザのうちの複数のグループ（所定数Ｎ１のユーザごとのグループ）への分け方は、ランダムであってもよい。あるいは、小ボスバトル設定部１５２は、所定関係を有する複数のユーザに同一の小ボスバトルパートを対応付けてもよい。所定関係は、任意であり、ユーザ情報等に基づいて判定されてもよいし、他の情報に基づいて判定されてもよい。例えば、小ボスバトル設定部１５２は、ユーザ情報に含まれるフレンド情報に基づいて、フレンド関係にあるユーザに同一の小ボスバトルパートを対応付けてもよい。あるいは、同様の観点から、小ボスバトル設定部１５２は、各ユーザの所属するギルドやパーティを示す情報に基づいて、同一のギルドやパーティに属するユーザに同一の小ボスバトルパートを対応付けてもよい。このような場合、グループ内の複数のユーザ間の連帯感や連携度合いを高めることができる。なお、この場合も、所定関係を有する複数のユーザのうちの一部が小ボスバトルパートに途中から参加する形態が実現されてもよい。

また、小ボスバトル設定部１５２は、大ボス関連処理部１５３の処理負荷に応じて、所定数Ｎ１を動的に変化させてもよい。例えば、所定数Ｎ１が大きいほど、一定人数あたりの小ボスバトルパートの数が小さくなり、それ故に、大ボス関連処理部１５３の処理負荷が小さくなる傾向がある。従って、小ボスバトル設定部１５２は、大ボス関連処理部１５３の処理負荷が比較的高い場合に、所定数Ｎ１を増加させてもよい。なお、大ボス関連処理部１５３の処理負荷は、大ボス関連処理部１５３の稼働状態等に基づいて判断されてもよい。

例えば、小ボスバトル設定部１５２は、ゲームデータ記憶部１６０内の参加状況データ（図１０の参加状況データ９００参照）に基づいて、参加ステータスが「対戦中」であるユーザの数が閾値を超えた場合に、２人以上のユーザごとに、一の小ボスバトルパートが対応付けられる態様で、小ボスバトルパートを設定してもよい。この場合、閾値は、大ボス関連処理部１５３の処理負荷と、大ボス関連処理部１５３を実現するハードウェア構成の能力との関係に応じて適合されてよい。

大ボス関連処理部１５３は、大ボスバトルパートに関連する各種処理を行う。例えば、大ボス関連処理部１５３は、大ボスバトルパートの進行に基づいて、大ボスｍ１のＨＰの値を更新する。本実施形態では、大ボス関連処理部１５３は、小ボスバトルパートが終了するごとに、大ボスｍ１のＨＰの値を更新する。

本実施形態では、大ボスバトルパートは、一旦、進行が開始されると、当該大ボスバトルパートに対応付けられる大ボスｍ１のＨＰの値が、その初期値（第１初期値の一例）から第１所定値α１以上減少して０になると、当該大ボスｍ１が倒されることで終了する。第１所定値α１は、任意であるが、本実施形態では、一の大ボスｍ１に係る第１所定値α１は、当該大ボスｍ１のＨＰの初期値である。ただし、変形例では、第１所定値α１は、大ボスｍ１のＨＰの初期値の所定割合（例えば９０％）に対応する値であってもよい。この場合、大ボスバトルパートは、一旦、進行が開始されると、当該大ボスバトルパートに対応付けられる大ボスｍ１のＨＰの値が、その初期値に対して所定割合以上減少すると、当該大ボスｍ１が倒されることで終了する。

また、本実施形態では、一のレイドゲームパートは、複数の大ボスバトルパートが順次実行される態様で、複数の大ボスバトルパートを含む。また、本実施形態では、一の大ボスバトルパートは、他の終了条件が満たされた場合も終了してよい。例えば、一の大ボスバトルパートは、開始後の経過時間が所定時間ΔＴ３を超えると、大ボスｍ１が倒されることなく終了してよい（すなわち大ボスｍ１が勝利）。

図９に示す例では、大ボス関連処理部１５３は、第１設定部１５３１と、第１更新部１５３２と、第１判定部１５３３とを含む。

第１設定部１５３１は、ゲームパート設定部１５０により一の大ボスバトルパートが設定されると、当該一の大ボスバトルパートに対応付けられる大ボスｍ１を設定する。例えば、第１設定部１５３１は、図８に示したボスキャラ情報に基づいて、大ボスバトルパートごとに、一の大ボスｍ１を対応付ける。この場合、第１設定部１５３１は、好ましくは、順次設定される大ボスバトルパートのうちの、後の大ボスバトルパートになるにつれて、対応付けられる大ボスｍ１のＨＰの初期値が前回値（直前の大ボスバトルパートに係る大ボスｍ１のＨＰの初期値）以上になるように、大ボスバトルパートごとに、一の大ボスｍ１を対応付ける。例えば、各大ボスバトルパートに対応付けられる大ボスｍ１は、予め規定されていてもよい（例えば運営側で規定してもよい）。この場合、第１設定部１５３１は、大ボスバトルパートごとに、予め規定された大ボスｍ１を設定する。

なお、上述したように、本実施形態では、各大ボスｍ１には、予めＨＰの初期値が対応付けられている（図８参照）。従って、第１設定部１５３１が、一の大ボスバトルパートに対応付けられる大ボスｍ１を設定すると、それに伴い当該一の大ボスバトルパートには、当該一の大ボスバトルパートの大ボスｍ１のＨＰの初期値が対応付けられることになる。なお、変形例では、大ボスｍ１のＨＰの初期値は、大ボスバトルパートが設定される際に、適宜、補正等されてもよい。

第１更新部１５３２は、レイドゲームパートにおける大ボスバトルパートの進行に基づいて、大ボスｍ１に対応付けられるＨＰ（第１パラメータの一例）の値（残りの値）を更新する。

本実施形態では、図３及び図５を参照して上述したように、第１更新部１５３２は、小ボスバトルパートが終了するごとに（すなわち、小ボスｍ２が倒されるごとに）、大ボスｍ１のＨＰの値を更新する。これにより、上述したように、大ボスｍ１に係るＨＰ減算処理の頻度を効果的に低減できる。

例えば、小ボスｍ２が倒されることで小ボスバトルパートが終了した場合、第１更新部１５３２は、当該小ボスｍ２のＨＰの初期値分だけ、大ボスｍ１のＨＰの値から減算することで、大ボスｍ１のＨＰの値を更新する。ただし、変形例では、第１更新部１５３２は、当該小ボスｍ２のＨＰの初期値に所定係数Ｋ１を乗じた値だけ、大ボスｍ１のＨＰの値から減算することで、大ボスｍ１のＨＰの値を更新してもよい。所定係数Ｋ１は、任意であり、可変値であってもよい。

他方、小ボスｍ２が倒されことなく小ボスバトルパートが終了した場合（例えばユーザの第１ゲーム媒体ｍ０が倒された場合や、途中で小ボスバトルパートが中断した場合等）、第１更新部１５３２は、大ボスｍ１のＨＰの値を更新しなくてもよい。あるいは、第１更新部１５３２は、そのときの小ボスｍ２のＨＰの減少分だけ、大ボスｍ１のＨＰの値から減算することで、大ボスｍ１のＨＰの値を更新してもよい。

第１判定部１５３３は、第１更新部１５３２により更新されたＨＰの値が０になったか否かを判定する。第１判定部１５３３は、第１更新部１５３２により更新されたＨＰの値が０になったと判定すると、今回の大ボスバトルパートを終了させるための処理を指示する。なお、今回の大ボスバトルパートが最後の大ボスバトルパートである場合は、第１判定部１５３３は、今回のレイドゲームパートを終了させるための処理を指示する。

ところで、本実施形態では、上述したように、第１更新部１５３２は、小ボスバトルパートが終了するごとに、大ボスｍ１に対応付けられるＨＰの値を更新するので、大ボスバトルパートが終了するタイミングは、一の小ボスバトルパートの終了タイミングに対応する。従って、ある一の小ボスバトルパートの終了に伴って大ボスバトルパートが終了する場合は、その時点で進行中でありうる他の小ボスバトルパートも強制的に終了される。この場合、大ボスｍ１が倒されたことにより他の小ボスバトルパートが終了されたことを表す情報が、当該他の小ボスバトルパートに対応付けられているユーザにわかるように、通知されてもよい。例えば、第１更新部１５３２により更新されたＨＰの値が０になった場合に小ボスバトルパートが１つ以上の端末装置２０で進行されている場合、当該１つ以上の端末装置２０におけるゲーム画像において小ボスｍ２が退散する様子が描画され、ついで、大ボスｍ１が敗北する様子が描画されてよい。あるいは、各端末装置２０におけるゲーム画像において、大ボスｍ１が敗北する様子が割り込みにより描画されてもよい。また、大ボスｍ１に対応付けられるＨＰの値を０にするために必要とされる小ボスｍ２が設定される場合は、大ボスバトルパートが終了する時点で、当該大ボスに関連付けられた小ボスバトルパートもすべて終了していてもよい。

小ボスバトル処理部１５４は、小ボスバトルパートに関連する各種処理を行う。例えば、小ボスバトル処理部１５４は、大ボスバトルパートの進行（及びそれに伴う１つ以上の小ボスバトルパートの進行）に基づいて、小ボスｍ２のＨＰの値を更新する。この際、小ボスバトル処理部１５４は、小ボスバトルパートごとに機能する。

本実施形態では、小ボスバトルパートは、対応する小ボスｍ２のＨＰの値が、その初期値（第２初期値の一例）から第２所定値α２以上減少して０になると、小ボスｍ２が倒されることで終了する。第２所定値α２は、任意であるが、本実施形態では、一の小ボスｍ２（又は一の小ボスバトルパート）に係る第２所定値α２は、当該小ボスｍ２のＨＰの初期値である。この場合、小ボスバトルパートは、小ボスｍ２のＨＰの値が０になると終了する。ただし、変形例では、第２所定値α２は、小ボスｍ２のＨＰの初期値の所定割合（例えば９０％）に対応する値であってもよい。この場合、一の子ボスバトルパートは、一旦、進行が開始されると、当該小ボスバトルパートに対応付けられる小ボスｍ２のＨＰの値が、その初期値に対して所定割合以上減少すると、小ボスｍ２が倒されることで終了する。

また、本実施形態では、小ボスバトルパートは、他の終了条件が満たされた場合も終了してもよい。例えば、小ボスバトルパートは、ユーザの第１ゲーム媒体ｍ０のＨＰの値が０になると、小ボスｍ２が倒されることなく終了してよい（すなわち小ボスｍ２が勝利）。ただし、この場合、同ユーザが再度、同小ボスバトルパートを最初から又は途中からプレイ（再挑戦）可能な仕様であってもよい。

図９に示す例では、小ボスバトル処理部１５４は、第２設定部１５４１と、第２更新部１５４２と、第２判定部１５４３とを含む。

第２設定部１５４１は、小ボスバトル設定部１５２により一の小ボスバトルパートが設定されると、当該一の小ボスバトルパートに小ボスｍ２を対応付ける。これにより、一の小ボスバトルパートに対応付けられている１人以上のユーザに、当該一の小ボスバトルパートに対応付けられた小ボスｍ２が、対応付けられることになる。換言すると、一のユーザに小ボスｍ２（又はそのＨＰの初期値）を対応付けることと、当該一のユーザに小ボスバトルパートに対応付けることとは、実質的に同義である。

本実施形態では、第２設定部１５４１は、図８に示したボスキャラ情報に基づいて、一の大ボスバトルパートにおける小ボスバトルパートには、当該一の大ボスバトルパートに対応付けられる大ボスｍ１の分身である小ボスｍ２を対応付ける。これにより、大ボスｍ１と小ボスｍ２との関係（すなわち小ボスｍ２が大ボスｍ１の分身である関係）がユーザにとって分かりやすくなる。

なお、上述したように、本実施形態では、各小ボスｍ２には、予めＨＰの初期値が対応付けられている（図８参照）。従って、第２設定部１５４１が、一の小ボスバトルパートに対応付けられる小ボスｍ２を設定すると、当該一の小ボスバトルパートには、当該小ボスｍ２のＨＰの初期値が対応付けられることになる。

ここで、変形例では、第２設定部１５４１は、一の小ボスバトルパートに対応付けられる小ボスｍ２に関して、そのＨＰの初期値を適宜変更してもよい。例えば、第２設定部１５４１は、図８に示すようなボスキャラ情報で規定されるＨＰの初期値に対して、適宜増減した初期値を設定してもよい。この場合、当該小ボスｍ２に対応付けられた描画用情報は、変更されないので、見た目は影響せず、ＨＰの初期値だけが変更される。なお、ＨＰの初期値に代えて又は加えて、図８に示すようなボスキャラ情報で規定される攻撃力や回復力についても変更されてもよい。

具体的には、第２設定部１５４１は、一の小ボスバトルパートが対応付けられる一人以上のユーザに係るユーザ情報に基づいて、当該一の小ボスバトルパートに対応付けられる小ボスｍ２のＨＰの初期値を設定してもよい。この場合、第２設定部１５４１は、一の小ボスバトルパートが対応付けられるユーザの第１ゲーム媒体のレベルやＨＰの初期値等が高いほど、小ボスｍ２のＨＰの初期値が高くなる態様で、小ボスｍ２のＨＰの初期値を設定してもよい。この場合、ユーザ情報に基づくユーザのレベル帯に応じてあらかじめ複数の小ボスｍ２のＨＰの初期値を設定しておき、レベルに応じた初期値を設定してもよい。これにより、各ユーザのレベルに応じたＨＰの初期値を有する小ボスｍ２を、各ユーザに対応付けられる小ボスバトルパートに対応付けることができる。

また、第２設定部１５４１は、一の小ボスバトルパートに複数のユーザが対応付けられる場合は、一の小ボスバトルパートに一のユーザが対応付けられる場合よりも大きいＨＰの初期値を有する小ボスｍ２を、当該一の小ボスバトルパートに対応付けてもよい。第２設定部１５４１は、一の小ボスバトルパートに複数のユーザが対応付けられる場合は、それぞれのユーザに係るユーザ情報に基づいて、当該一の小ボスバトルパートに対応付けられる小ボスｍ２のＨＰの初期値を設定してもよい。この場合、第２設定部１５４１は、一の小ボスバトルパートが対応付けられる各ユーザの第１ゲーム媒体のレベルやＨＰの初期値等の平均値や合計値が高いほど、小ボスｍ２のＨＰの初期値が高くなる態様で、小ボスｍ２のＨＰの初期値を設定してもよい。これにより、複数のユーザのレベルに応じたＨＰの初期値を有する小ボスｍ２を、複数のユーザに対応付けられる各小ボスバトルパートに対応付けることができる。

また、第２設定部１５４１は、一の小ボスバトルパートに対応付ける小ボスｍ２のＨＰの初期値を、当該小ボスｍ２に係る大ボスｍ１のＨＰの初期値に基づいて設定してもよい。例えば、一の大ボスｍ１の分身として機能する小ボスｍ２に対応付けられるＨＰの初期値は、当該一の大ボスｍ１に対応付けられるＨＰの初期値の、１／Ｍであってもよい。ここで、Ｍは、例えば１０００以上の大きい数である。この場合、一の小ボスｍ２のＨＰの初期値は、当該一の小ボスｍ２に係る大ボスｍ１のＨＰの初期値が大きいほど大きくなる。これにより、大ボスｍ１の強さに応じた強さの小ボスｍ２を設定できるので、大ボスｍ１と小ボスｍ２との関係が、大ボスｍ１の強さに連動するという一貫性をもたせることができる。

また、第２設定部１５４１は、一の小ボスバトルパートに対応付ける小ボスｍ２のＨＰの初期値を、当該小ボスｍ２に係る大ボスｍ１のＨＰの値（第１更新部１５３２により更新された値）に基づいて設定してもよい。例えば、第２設定部１５４１は、小ボスバトル設定部１５２により一の小ボスバトルパートが設定されると、大ボスｍ１のＨＰの値（現在値）を、第１更新部１５３２から取得する。そして、第２設定部１５４１は、大ボスｍ１のＨＰの値に基づいて、当該一の小ボスバトルパートに対応付けられる小ボスｍ２のＨＰの初期値を決定する。この際、例えば、第２設定部１５４１は、大ボスｍ１のＨＰの値が大きいほど小ボスｍ２のＨＰの初期値が大きくなる態様で、小ボスｍ２のＨＰの初期値を決定してもよい。これにより、そのときの大ボスｍ１のＨＰの値に応じたＨＰの初期値の小ボスｍ２を設定できるので、ゲーム状況に合わせた小ボスｍ２のＨＰの初期値を設定できる。

また、第２設定部１５４１は、大ボス関連処理部１５３の処理負荷に応じて、小ボスｍ２のＨＰの初期値を変化させてもよい。例えば、小ボスｍ２のＨＰの初期値が大きいほど、小ボスバトルパートが終了する頻度が小さくなり、それ故に、大ボス関連処理部１５３の処理負荷が小さくなる傾向がある。従って、第２設定部１５４１は、大ボス関連処理部１５３の処理負荷が比較的高い場合に、小ボスｍ２のＨＰの初期値を増加させてもよい。なお、大ボス関連処理部１５３の処理負荷は、大ボス関連処理部１５３の稼働状態等に基づいて判断されてもよい。例えば、大ボス関連処理部１５３の処理負荷は、第１更新部１５３２による更新頻度に基づいて判断されてもよい。これは、第１更新部１５３２による更新頻度が高いほど、大ボス関連処理部１５３の処理負荷が高くなる傾向があるためである。

ここで、一の大ボスバトルパートにおいて、大ボスｍ１のＨＰの初期値＝第１所定値α１とし、小ボスｍ２のＨＰの初期値＝第２所定値α２とし、小ボスバトル設定部１５２が小ボスバトルパートをＮ３個設定するとき、小ボスｍ２のＨＰの初期値の合計値＝α２×Ｎ３である。このとき、所定の上限値をγとすると、大ボスｍ１を倒すことが可能となる場合、α１≦α２×Ｎ３≦γとなる。また、一の大ボスバトルパートあたりの小ボスバトルパートの数に対して、所定の上限数をＭ１とし、第２所定値α２を固定値とし、Ｍ２をα１≦Ｍ×α２を満たす最小の整数Ｍとしたとき、Ｍ２≦Ｎ３≦Ｍ１となる。この場合、Ｍ２個の小ボスバトルパートのすべてで小ボスｍ２が倒されると、当該一の大ボスバトルパートに係る大ボスｍ１が倒される。なお、このとき、Ｎ３－Ｍ個の小ボスバトルパートは、予備のゲームパートとなる。この場合、第２所定値α２を固定値としたとき、小ボスバトル設定部１５２は、第１所定値α１を第２所定値α２で割ることで得られる値よりも大きい数であって、所定の上限数Ｍ１を超えない数だけ、小ボスバトルパートを設定することになる。また、小ボスバトル設定部１５２は、一の大ボスバトルパートの進行中において、各ユーザに所定の上限数Ｍ３を超える数の小ボスバトルパートが対応付けられている状態が形成されないように、小ボスバトルパートを設定してもよい。この場合、所定の上限数Ｍ３は、上述した所定の上限数Ｍ１と同じであってもよいし、所定の上限数Ｍ１よりも小さくてもよい。

第２更新部１５４２は、各小ボスバトルパートの進行に基づいて、各小ボスｍ２に対応付けられるＨＰ（第２パラメータの一例）の値（残りの値）を更新する。第２更新部１５４２は、一の小ボスバトルパートにおいて、小ボスｍ２がユーザの第１ゲーム媒体ｍ０からの攻撃を受けると、当該攻撃に応じたＨＰの値だけ、当該小ボスｍ２のＨＰの値から減算することで、当該小ボスｍ２のＨＰの値を更新する。このようにして、第２更新部１５４２は、ユーザの第１ゲーム媒体ｍ０からの攻撃を受けるごとに、小ボスｍ２のＨＰの値を更新する。

また、第２更新部１５４２は、回復条件が成立した場合に、適宜、小ボスｍ２のＨＰの値を増加させることで、当該小ボスｍ２のＨＰの値を更新してもよい。

第２判定部１５４３は、第２更新部１５４２により更新されたＨＰの値が０になったか否かを判定する。第２判定部１５４３は、第２更新部１５４２により更新されたＨＰの値が０になったと判定すると、対応する小ボスバトルパートを終了させるための処理を指示する。この場合、対応する小ボスバトルパートが実行されている端末装置２０におけるゲーム画像において、小ボスｍ２が敗北する様子が描画されてよい。

ここで、一の小ボスバトルパートの進行に伴う小ボスバトル処理部１５４の動作について説明する。小ボスバトルパートが開始されると、小ボスバトル処理部１５４は、小ボスｍ２の行動ポイントを初期値（例えば、ゼロポイント）に定める。

小ボスバトルパートの実行中、例えば、第１期間と第２期間とが交互に繰り返し発生する。

第１期間は、例えば時間経過に応じて増加する小ボスｍ２の行動ポイントが、初期値（例えば、ゼロポイント）から上限値（例えば、１００ポイント）まで増加する期間である。具体的には、小ボスバトル処理部１５４は、小ボスｍ２の行動ポイントを時間経過に応じて増加させる処理（増加処理）を開始する。増加処理の開始タイミングが、第１期間の開始タイミングに相当する。小ボスバトル処理部１５４は、小ボスｍ２の行動ポイントが上限値（例えば、１００ポイント）に達すると、増加処理を終了する。増加処理の終了タイミングが、第１期間の終了タイミングに相当する。

第２期間は、第１期間の終了タイミングから、小ボスｍ２の行動ポイントが初期値にリセットされるタイミングまでの期間である。具体的には、第２期間が開始した後、小ボスバトル処理部１５４は、小ボスｍ２に所定の行動（例えば、ユーザに対する攻撃）を実行させる。なお、第１ゲーム媒体に行動（例えば、小ボスｍ２に対する攻撃）を実行させない場合、小ボスバトル処理部１５４は、例えば第２期間の開始直後に、小ボスｍ２に所定の行動を実行させてもよい。一方、第１ゲーム媒体に行動を実行させる場合、小ボスバトル処理部１５４は、第１ゲーム媒体による行動の終了を待ってから、小ボスｍ２に所定の行動を実行させてもよい。かかる場合、第１ゲーム媒体による行動が終了した後に、小ボスｍ２による行動が実行される。このようにして、第１期間と第２期間とが交互に繰り返し発生する。

なお、第１期間において、小ボスバトル処理部１５４は、仮想空間内に所定のアイテムを出現させてもよい。小ボスバトル処理部１５４は、第２ゲーム媒体によるアイテムの取得に応じて、第１ゲーム媒体の行動ポイントを増加させる。小ボスバトル処理部１５４は、第１ゲーム媒体の行動ポイントが所定の基準値以上である場合、当該第１ゲーム媒体に所定の行動（例えば、小ボスｍ２に対する攻撃）を実行させ、行動ポイントを当該基準値分だけ減少させる。小ボスバトル処理部１５４は、第１ゲーム媒体の行動ポイントが当該基準値未満となるまで、当該第１ゲーム媒体に行動を繰り返し実行させる。第１ゲーム媒体の行動ポイントが減少して当該基準値未満になると、第１ゲーム媒体による行動が終了する。

なお、小ボスバトルパートの進行の仕方や終了の仕方等は、多様でありえ、任意である。例えば、小ボスｍ２が複数登場してもよい。この場合、一の小ボスバトルパートには、複数の小ボスｍ２のＨＰの初期値が割り当てられてよい。また、小ボスｍ２よりも前に子分キャラクタが登場してもよい。この場合、一の小ボスバトルパートには、子分キャラクタのＨＰの初期値が追加的に割り当てられてよい。また、小ボスバトルパートにおいては、複数の第１ゲーム媒体からなるデッキと小ボスｍ２とが対戦してもよい。また、後述する救援要請がある場合、小ボスバトルパートにおいては、複数のユーザに係る第１ゲーム媒体ｍ０（又はそれらのデッキ）と小ボスｍ２とが対戦してもよい。また、小ボスバトルパートは、第２更新部１５４２により更新されたＨＰの値が０にならない場合でも、所定の終了条件が満たされた場合に、終了する仕様であってもよい。例えば、小ボスバトルパートは、ユーザの第１ゲーム媒体ｍ０による攻撃回数（ターン数）が所定数に達した場合に、終了してもよい。また、小ボスバトルパートは、アクティブタイムバトル以外にも、リアルタイムバトル等により実現されてもよい。

救援要請処理部１５５は、一のユーザ（端末装置２０）から救援要請を受信した場合に、当該一のユーザに対応付けられている小ボスバトルパートに、救援用のユーザを対応付けるための救援処理を実行する。救援要請処理部１５５は、任意の態様で、救援用のユーザを選択してもよい。例えば、救援要請処理部１５５は、参加ステータスが「待機中」であるユーザ群から、救援用のユーザを選択してもよい。あるいは、救援要請処理部１５５は、参加ステータスが「待機中」でありかつフレンド関係にあるユーザ群から、救援用のユーザを選択してもよい。なお、参加ステータスが「待機中」であるユーザ群に代えて又は加えて、参加ステータスが「対戦中」や「退出中」であるユーザ群を含めてもよい。また、救援要請処理部１５５は、救援用のユーザを１人だけ選択してもよいし、複数同時に選択してもよい。

救援要請処理部１５５は、救援用のユーザを選択すると、選択した救援用のユーザに対して、救援要請を送信する。救援要請を受けたユーザの端末装置２０のゲーム画像には、承諾ボタンが表示されてよい。この場合、救援要請を受けたユーザは、承諾ボタンを押す等により、端末装置２０を介して救援受諾をサーバ装置１０に送信できる。なお、承諾ボタンには、対応する小ボスバトルパートの小ボスｍ２が描画されていてもよい。

救援要請処理部１５５は、救援要請を送信した１人以上のユーザ（端末装置２０）から救援受諾を受信すると、救援受諾を行ったユーザに、救援要請を出したユーザに対応付けられている小ボスバトルパートを対応付ける。

ゲーム状態管理部１５６は、レイドゲームパートの進行に応じて、ゲーム状態を更新／管理する。ゲーム状態管理部１５６は、ゲーム状態が変化するごとに、ゲームデータ記憶部１６０内のゲームデータを更新する。

図１０には、ゲームデータ記憶部１６０内のゲームデータのうちの、ゲーム状態データ９０２の一例が示されている。ゲーム状態データ９０２は、図１０に示すように、バトルＩＤごとに、小ボスｍ２のゲーム媒体ＩＤ、ゲームステータス、対応付けユーザＩＤ、参加属性、結果、減算ＨＰ、同時プレイの有無、等を対応付けることで、生成されてもよい。

バトルＩＤは、個々の小ボスバトルパートを特定する識別子である。バトルＩＤは、小ボスバトル設定部１５２により小ボスバトルが設定されるごとに、設定される。なお、バトルＩＤは、予めサーバ記憶部１２に記憶されてもよいし、あるいは、小ボスバトル設定部１５２により小ボスバトルが設定されるときに、サーバ装置１０によって決定されてもよい。

小ボスｍ２のゲーム媒体ＩＤは、対応する小ボスバトルパートに対応付けられた小ボスｍ２のゲーム媒体ＩＤである。ゲームステータスは、「進行中」、「終了」等を含んでよい。対応付けユーザＩＤは、対応する小ボスバトルパートに対応付けられたユーザのユーザＩＤである。参加属性は、対応するユーザの設定要求（後述する新規の設定要求）により設定された小ボスバトルパート（「ホスト」と表記）であるか、他のユーザからの救援要請に応じて対応付けられた小ボスバトルパート（「救援」と表記）であるか、他のユーザがホストとなる小ボスバトルパートへの自主的な参加（援護）であるか等、を表す。結果は、対応する小ボスバトルパートの結果である。減算ＨＰは、対応する小ボスバトルパートにおいて小ボスｍ２のＨＰをどの程度減らしたかを表す。なお、一のユーザのみに対応付けられた小ボスバトルパートの場合、結果が“ユーザ勝利”であれば、減算ＨＰは、当該小ボスバトルパートに対応付けられた小ボスｍ２のＨＰの初期値に対応する。

同時プレイ検出部１５７は、２つ以上の小ボスバトルパートが対応付けられているユーザが存在するか否かを判定する。例えば、ゲーム状態管理部１５６は、ゲームデータ記憶部１６０内のゲームデータに基づいて、２つ以上の小ボスバトルパートが対応付けられているユーザが存在するか否かを判定できる。以下、このように、２つ以上の小ボスバトルパートが対応付けられているユーザを、「同時プレイユーザ」とも称する。同時プレイユーザには、上述したように、救援要請に対して救援受諾を行ったユーザがなりうる。なお、同時プレイユーザが発生しないゲーム仕様の場合は、同時プレイ検出部１５７は省略されてよい。

画像生成部１５８は、各ユーザに係る端末装置２０上に各種のゲーム画像を表示させるための表示用画像情報を生成する。

図１１は、小ボスバトルパートに係るゲーム画像の一例を示す図である。以下の図１１（及び後出の図１２）に関する説明において、小ボスｍ２とは、図１１に示すゲーム画像に係る小ボスバトルパートに対応付けられている小ボスｍ２を指し、大ボスｍ１とは、当該小ボスｍ２に係る大ボスｍ１を指す。

図１１では、小ボスバトルパートに係るゲーム画像Ｇ１１００は、ユーザの第１ゲーム媒体ｍ０に係るＨＰ表示（ゲージ）４５と、小ボスｍ２に係るＨＰ表示４８とを含む。小ボスｍ２に係るＨＰ表示４８は、上述した第２更新部１５４２により小ボスｍ２のＨＰの値が更新されるごとに、更新される。なお、図１１では、ＨＰ表示４５には、ユーザの第１ゲーム媒体ｍ０を表す画像部Ｇ１１００４が対応付けられ、ＨＰ表示４８には、小ボスｍ２を表す画像部Ｇ１１００３が対応付けられる。

また、図１１では、小ボスバトルパートに係るゲーム画像Ｇ１１００は、大ボスｍ１に対応付けられた描画用情報に基づき描画された画像部Ｇ１１００１と、ユーザの第１ゲーム媒体ｍ０に対応付けられた描画用情報に基づき描画された画像部Ｇ１１００２とを含む。上述のように、本実施形態では、大ボスｍ１を描画するための描画用情報は、その分身である小ボスｍ２を描画するための描画用情報と同じである。換言すると、大ボスｍ１と、その分身である小ボスｍ２とは、ゲーム画像上、区別できない。これにより、ユーザには、小ボスｍ２と戦っているにもかかわらず、大ボスｍ１と戦っているイメージを持ってもらうことができる。

図１２は、小ボスバトルパートの終了に伴う大ボスｍ１のＨＰの値の更新を示すゲーム画像の一例を示す図である。

図１２では、大ボスｍ１のＨＰの値の更新を示すゲーム画像Ｇ１２００は、大ボスｍ１に係るＨＰ表示４９を含む。ＨＰ表示４９は、上述した第１更新部１５３２により大ボスｍ１のＨＰの値が更新されるごとに、更新される。なお、図１２では、ＨＰ表示４９には、大ボスｍ１を表す画像部Ｇ１２００１が対応付けられる。この場合、画像部Ｇ１２００１は、図１１に示した画像部Ｇ１１００３よりも大きく描画されてもよい。ＨＰ表示４９には、数値表示４９１が含められてもよい。これにより、大ボスｍ１のＨＰの値が一回の更新でわずかにしか減らない場合でも、わずかに減ったことをユーザに理解してもらうことができる。なお、数値表示４９１のオーダ（小数点何位までのかのオーダ）は、大ボスｍ１のＨＰの値の最小変化単位に応じて適宜設定されてよい。

このようにして、本実施形態では、画像生成部１５８は、大ボスｍ１のＨＰの値が第１更新部１５３２により更新されるごとに、大ボスｍ１に係る画像（図１２の画像部Ｇ１２００１参照）と、更新後の大ボスｍ１のＨＰの値を表す画像（図１２のＨＰ表示４９参照）とを表示させるための表示用画像情報（第１表示用画像情報の一例）を生成する。この場合、各端末装置２０は、当該表示用画像情報に基づいて、大ボスｍ１のＨＰの値が減らされたことを表す表示用画像（図１２のゲーム画像Ｇ１２００参照）を出力できる。

また、画像生成部１５８は、小ボスｍ２のＨＰの値が第２更新部１５４２により更新されるごとに、大ボスｍ１に係る画像（図１１の画像部Ｇ１１００１参照）と、更新後の小ボスｍ２のＨＰの値を表す画像（図１１のＨＰ表示４８）とを表示させるための表示用画像情報（第２表示用画像情報の一例）を生成する。この場合、各端末装置２０は、当該表示用画像情報に基づいて、小ボスｍ２のＨＰの値が減らされたことを表す表示用画像（図１１のゲーム画像Ｇ１１００参照）を出力できる。

このようにして、本実施形態では、画像生成部１５８は、小ボスｍ２のＨＰの値が第２更新部１５４２により更新されるごとに、図１１のようなゲーム画像Ｇ１１００を表示させるための表示用画像情報を生成する。そして、第２更新部１５４２により更新された小ボスｍ２のＨＰの値が０に至ると（すなわち小ボスｍ２が倒されると）、小ボスｍ２の敗北シーンが描画されるように表示用画像情報を生成する。この場合、対応する端末装置２０は、当該表示用画像情報に基づいて、小ボスｍ２が倒されたことを表す表示用画像（図示せず）を出力できる。

ここで、小ボスｍ２の敗北シーンと、大ボスｍ１の敗北シーンとで、倒されたゲーム媒体を同じ描画態様で描画すると、ユーザに混乱を生む可能性がある。従って、小ボスｍ２の敗北シーンでは、大ボスｍ１の“分身”である小ボスｍ２が倒されたことがわかりやすくなるように、大ボスｍ１を描画するための描画用情報に基づき描画されるゲーム媒体は、比較的小さいサイズで描画されてもよい。換言すると、大ボスｍ１を描画するための描画用情報に基づきゲーム媒体を比較的小さいサイズで描画することで、“小ボスｍ２”を描画してもよい。このようにして、所定の場合に、画像生成部１５８は、大ボスｍ１のＨＰの値に対応付けて大ボスｍ１に係るゲーム媒体を表示するときと、小ボスｍ２のＨＰの値に対応付けて小ボスｍ２に係るゲーム媒体を表示するときとで、異なる態様で対戦相手が描画されるように表示用画像情報を生成してもよい。なお、異なる態様は、サイズに代えて又は加えて、詳細な部分の描画が異なってもよい。

また、本実施形態では、画像生成部１５８は、大ボスｍ１のＨＰの値が第１更新部１５３２により更新されるごとに、図１２のようなゲーム画像Ｇ１２００を表示させるための表示用画像情報を生成する。そして、第１更新部１５３２により更新された大ボスｍ１のＨＰの値が０に至ると（すなわち大ボスｍ１が倒されると）、大ボスｍ１の敗北シーンが描画されるように表示用画像情報を生成する。この場合、各端末装置２０は、当該表示用画像情報に基づいて、大ボスｍ１が倒されたことを表す表示用画像（図示せず）を出力できる。

ここで、上述したように、小ボスｍ２の敗北シーンと、大ボスｍ１の敗北シートとで、倒されたゲーム媒体を同じ描画態様で描画すると、ユーザに混乱を生む可能性がある。従って、大ボスｍ１の敗北シーンでは、大ボスｍ１の“分身”である小ボスｍ２が倒されたときの敗北シートに対する相違がわかりやすくなるように、大ボスｍ１を描画するための描画用情報に基づき描画されるゲーム媒体は、比較的大きいサイズで描画されてもよい。換言すると、大ボスｍ１を描画するための描画用情報に基づきゲーム媒体を比較的大きいサイズで描画することで、“大ボスｍ１”を描画してもよい。

なお、画像生成部１５８は、同時プレイ検出部１５７におり、２つ以上の小ボスバトルパートが対応付けられているユーザが存在すると判定された場合、当該ユーザが、２つ以上の小ボスバトルパートのうちの、いずれか１つだけを選択できるような選択画像を含むゲーム画像を端末装置２０上に表示させるための表示用画像情報を生成してよい。この場合、ユーザは、例えば救援要請を受けた方の小ボスバトルパートを優先的にプレイする等、所望の選択を行うことができる。あるいは、ユーザは、自動モード等を利用することで、２つ以上の小ボスバトルパートを並列的に進行させることが可能であってもよい。これらの場合、第２更新部１５４２は、２つ以上の小ボスバトルパートが対応付けられているユーザからの入力（例えば、手動や自動による操作入力）に基づいて、２つ以上の小ボスｍ２のＨＰのそれぞれ又は一部の値を更新することになる。

なお、上述したように、図９に示しかつ上述したサーバ装置１０の機能の一部又は全部は、適宜、端末装置２０により実現されてもよい。例えば、端末装置２０に表示されるゲーム画像（図１１や図１２に示すようなゲーム画像）の少なくとも一部を、サーバ装置１０が生成したデータに基づいて端末装置２０に表示させるウェブ表示とし、ゲーム画像の少なくとも一部を、端末装置２０にインストールされているネイティブアプリケーションによって表示させるネイティブ表示としてもよい。

報酬付与部１５９は、レイドゲームパートに参加した各ユーザに報酬を付与する。報酬の付与方法は任意である。例えば、報酬付与部１５９は、小ボスバトルパートごとに、小ボスｍ２を倒した１人以上のユーザに特定の報酬を付与してもよいし、及び／又は、大ボスバトルパートごとに、大ボスｍ１を倒すことに貢献した各ユーザに特定の報酬を付与してもよい。また、報酬付与部１５９は、大ボスｍ１を倒した際の小ボスバトルパートをプレイした１人以上のユーザ（すなわち、大ボスｍ１に最後の一撃を加えた１人以上のユーザ）に、特別な報酬を付与してもよい。また、報酬付与部１５９は、レイドゲームパートが終了した後に、参加状況データ９００（図１０参照）等に基づいて、ランキング情報を生成してもよい。この場合、ランキング情報は、倒した小ボスｍ２の数（討伐数）が多い順にユーザＩＤがランキングされる態様で、生成されてもよい。

ところで、本実施形態では、上述したように、第１更新部１５３２は、第２更新部１５４２により更新された小ボスｍ２のＨＰの値に基づいて、第２更新部１５４２よりも少ない更新頻度で大ボスｍ１のＨＰの値を更新する。これにより、参加ステータスが“対戦中”であるユーザの数が膨大である場合でも、第１更新部１５３２の処理負荷を低減できる。他方、参加ステータスが“対戦中”であるユーザの数が膨大となると、第２更新部１５４２の全体としての処理負荷は増加する。

この点、本実施形態では、第２更新部１５４２は、小ボスバトルパートごとに独立して動作できるので、複数のサーバコンピュータ及び／又は複数のＣＰＵにより分散して実現することが容易である。この場合、第２更新部１５４２を実現するための処理部が、限られたハードウェアリソースに限定されてしまうことをなく、処理負荷を適切に分散できる。あるいは、第２更新部１５４２は、小ボスバトルパートごとに独立して動作できるので、端末装置２０により実現されてもよい。この場合も、第２更新部１５４２を実現するための処理部が、限られたハードウェアリソースに限定されてしまうことなく、処理負荷を適切に分散できる。このようにして、第２更新部１５４２は、第１更新部１５３２よりも多い数のコンピュータにより実現することができるので、処理負荷を適切に分散できる。

次に、図１３以降を参照して、サーバ装置１０におけるレイドゲームパートに関連した構成の動作例について説明する。

図１３は、各ユーザからの小ボスバトルパートの設定要求に係る処理の一例を示す概略的なフローチャートである。

ステップＳ１１０２では、サーバ装置１０は、小ボスバトルパートに係るロビー画像の生成要求をいずれかの端末装置２０（すなわちいずれかのユーザ）から受信したか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ１３０６に進み、それ以外の場合は、今回周期の処理をそのまま終了する。

ステップＳ１１０４では、サーバ装置１０は、ユーザがいくつかの小ボスバトルパートの中からプレイする小ボスバトルパートを選択するための選択用画像の生成処理（以下、「選択用画像生成処理」とも称する）を行う。すなわち、サーバ装置１０は、１つ以上の小ボスバトルパートのうちから、一の小ボスバトルパートをユーザが選択できるユーザインターフェース（選択用画像）（図示せず）を生成する。当該ユーザインターフェースは、今回受信したロビー画像の生成要求に係る要求元のユーザ（以下、単に「要求元のユーザ」とも称する）に係る端末装置２０に表示され、選択可能な１つ以上の小ボスバトルパートを表す選択ボタンを含んでよい。選択ボタンは、対応する小ボスバトルパートに係る情報（例えば現在のプレイ中のユーザ情報）等を含んでよい。ユーザが所望の選択ボタンを操作すると、対応する小ボスバトルパートに対する設定要求がサーバ装置１０に送信される。以下では、一例として、設定要求は、要求元のユーザ（自身）をホストとした新規の小ボスバトルパートの設定を要求する設定要求（以下、「新規の設定要求」とも称する）と、既に他のユーザをホストとして設定済の小ボスバトルパートへの参加を要求する設定要求（以下、「参加型の設定要求」とも称する）とを含むものとする。なお、変形例では、新規の設定要求は、他のユーザ（所定関係を有するユーザ）とともにグループに対する小ボスバトルパートの設定を要求する設定要求を含んでもよい。

ステップＳ１１０６では、サーバ装置１０は、ユーザによる選択ボタンの操作（すなわちユーザによる小ボスバトルパートの選択）があったか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ１１０８に進み、それ以外の場合は、ユーザによる選択ボタンの操作待ち状態となる。なお、当該操作待ち状態は、例えば一定の時間が経過した場合や、選択可能な１つ以上の小ボスバトルパートのうちのいずれかが終了した場合等、適宜終了する。また、操作待ち状態において、ステップＳ１１０４が定期的に実行されてよい。

ステップＳ１１０８では、サーバ装置１０は、今回のユーザによる選択ボタンの操作により受信した設定要求（新規の設定要求又は参加型の設定要求）を、処理待ちのキューに設定する。このようにして、処理待ちのキューに設定された設定要求（新規の設定要求又は参加型の設定要求）は、後述する小ボスバトルパートにおける減算指示生成処理（図１５）において処理される（ステップＳ１３０４やステップＳ１３２７Ａ等参照）。

図１４Ａは、図１３の選択用画像生成処理（ステップＳ１１０４）の処理の一例を示す概略的なフローチャートである。

ステップＳ１２００では、サーバ装置１０は、ゲームデータ記憶部１６０内のゲームデータ（図１０のゲーム状態データ９０２参照）に基づいて、ゲームステータスが“進行中”であるバトルＩＤを抽出する。

ステップＳ１２０２では、サーバ装置１０は、要求元のユーザと所定関係を有するユーザＩＤを抽出する。例えば、サーバ装置１０は、ユーザ情報に含まれるフレンド情報に基づいて、要求元のユーザとフレンド関係にあるユーザのユーザＩＤを抽出する。

ステップＳ１２０４では、サーバ装置１０は、ステップＳ１２００で抽出した各バトルＩＤに対応付けられているユーザＩＤ（図１０のゲーム状態データ９０２の対応付けユーザＩＤ参照）の中に、ステップＳ１２０２で抽出したユーザＩＤが含まれているか否かを判定する。すなわち、サーバ装置１０は、ステップＳ１２００で抽出した各バトルＩＤに係る小ボスバトルパートの中に、要求元のユーザと所定関係を有するユーザ（例えばフレンド関係にあるユーザ）がプレイしている小ボスバトルパートが存在するか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ１２０６に進み、それ以外の場合は、ステップＳ１２０８に進む。

ステップＳ１２０６では、サーバ装置１０は、要求元のユーザとフレンド関係にあるユーザがプレイしている１つ以上の小ボスバトルパートと、新たな小ボスバトルパートのうちから、いずれか１つをプレイ対象の小ボスバトルパートとして要求元のユーザが選択できる選択用画像を生成する。なお、この場合、サーバ装置１０は、ゲーム状態に基づいて、選択用画像における１つ以上の小ボスバトルパートに係る選択ボタンの配置を適宜設定してもよい。例えば、サーバ装置１０は、要求元のユーザとフレンド関係にあるユーザがプレイしている１つ以上の小ボスバトルパートのうちの、小ボスｍ２のＨＰの値が大きい順（又は小さい順）、第１ゲーム媒体ｍ０側のＨＰの値の小さい順（又は大きい順）、又は、小ボスバトルパートの持続時間が長い順（又は短い順）に、優先的に選択されやすいような配置で、１つ以上の小ボスバトルパートに係る選択ボタンの配置を設定してもよい。なお、変形例では、要求元のユーザと所定関係にあるユーザがプレイしている１つ以上の小ボスバトルパートに代えて又は加えて、他の条件を満たす小ボスバトルパートが抽出（選択用画像に配置）されてもよい。

ステップＳ１２０８では、サーバ装置１０は、新たな小ボスバトルパートをプレイ対象の小ボスバトルパートとして要求元のユーザが選択できる選択用画像を生成する。

ステップＳ１２２０では、サーバ装置１０は、ステップＳ１２０６又はステップＳ１２０８で生成した選択用画像を要求元のユーザの端末装置２０に表示させる。

このようにして図１４Ａに示す処理によれば、要求元のユーザは、所定関係を有するユーザがプレイ中である小ボスバトルパートか、自身がホストとなり新たに設定する小ボスバトルパートかを、選択してプレイできる。また、サーバ装置１０に次々に設定要求が送信されてくる場合に各ユーザを適応的に分散させることになるため、小ボスｍ２ごとの処理（第２更新部１５４２を実現するための処理部）の負荷を均すことができる。

図１４Ｂは、図１３の選択用画像生成処理（ステップＳ１１０４）の処理の他の一例を示す概略的なフローチャートである。

図１４Ｂに示す処理は、図１４Ａに示した処理に対して、ステップＳ１２０４で判定結果が“ＹＥＳ”である場合にステップＳ１２１０が実行される点が異なる。以下では、異なる点を主に説明する。

ステップＳ１２１０では、サーバ装置１０は、要求元のユーザとフレンド関係にあるユーザがプレイしている１つ以上の小ボスバトルパートの数が、一定数を超えるか否かを判定する。一定数は、任意であるが、ユーザへ提示する選択候補として適切な数の上限値に対応してよい。判定結果が“ＹＥＳ”の場合、ステップＳ１２１２に進み、それ以外の場合は、ステップＳ１２１６に進む。なお、変形例では、要求元のユーザと所定関係にあるユーザがプレイしている１つ以上の小ボスバトルパートに代えて又は加えて、他の条件を満たす小ボスバトルパートが抽出されてもよい。この場合、サーバ装置１０は、これらを含む抽出されたすべての小ボスバトルパートの数が、一定数を超えるか否かを判定してよい。

ステップＳ１２１２では、サーバ装置１０は、要求元のユーザとフレンド関係にあるユーザがプレイしている１つ以上の小ボスバトルパートのうちから、一定数の小ボスバトルパートだけを抽出する。

この場合の抽出方法は、任意であるが、ゲーム状態が考慮されてもよい。例えば、サーバ装置１０は、要求元のユーザとフレンド関係にあるユーザがプレイしている１つ以上の小ボスバトルパートのうちの、小ボスｍ２のＨＰの値が大きい順（又は小さい順）、第１ゲーム媒体ｍ０側のＨＰの値の小さい順（又は大きい順）、小ボスバトルパートの持続時間が長い順（又は短い順）、他のユーザの参加人数が多い順（又は少ない順）、又は、他のユーザのレベル帯（例えば、ユーザ情報に基づくユーザのレベル帯）が高い順（又は低い順）に、若しくは、これらの２つ以上の組み合わせによる順序に従って、一定数の小ボスバトルパートを抽出してもよい。

ステップＳ１２１４では、サーバ装置１０は、ステップＳ１２１２で抽出した一定数の小ボスバトルパートと、新たな小ボスバトルパートのうちから、いずれか１つを要求元のユーザが選択できる選択用画像を生成する。

ステップＳ１２１６では、サーバ装置１０は、要求元のユーザとフレンド関係にあるユーザがプレイしている１つ以上の小ボスバトルパート（一定数以下のすべて）と、新たな小ボスバトルパートのうちから、いずれか１つをプレイ対象の小ボスバトルパートとして要求元のユーザが選択できる選択用画像を生成する。

このようにして図１４Ｂに示す処理によれば、所定関係を有するユーザがプレイ中である小ボスバトルパートの数が比較的多い場合には、抽出した一定数の小ボスバトルパートだけを、選択対象の小ボスバトルパートとして要求元のユーザに提示できる。

また、図１４Ｂに示す処理によれば、ゲーム状態に応じて、要求元のユーザに提示する一定数の小ボスバトルパートを抽出するので、処理不可の平均化を図ることも可能である。例えば、適宜、小ボスへの参加人数を偏らせたりすることにより、特定の小ボスが早く倒されやすくすることにより、各小ボスの倒されるであろうタイミングをずらすことで、大ボスｍ１のＨＰの値の更新タイミングをずらし、一時的な処理負荷の増大を防ぐことができる。

図１５は、小ボスバトルパートにおける減算指示生成処理の一例を示す概略的なフローチャートである。図１５に示す処理は、レイドゲームパートの進行中、所定周期ごとに繰り返し実行されてよい。

ステップＳ１３０２では、サーバ装置１０は、新たな小ボスバトルパートの設定状態を示す第１フラグＦ１が“０”であるか否かを判定する。第１フラグＦ１が“０”である場合は、新たな小ボスバトルパートの設定待ち状態に対応し、第１フラグＦ１が“１”である場合は、新たな小ボスバトルパートの設定済状態に対応する。第１フラグＦ１は、小ボスバトルパートごと（すなわちバトルＩＤごと）に設定される。判定結果が“ＹＥＳ”の場合、ステップＳ１３０４に進み、それ以外の場合は、ステップＳ１３１２に進む。

ステップＳ１３０４では、サーバ装置１０は、小ボスバトルパートに係る新規の設定要求をいずれかの端末装置２０（すなわちいずれかのユーザ）から受信したか否かを判定する。例えば、サーバ装置１０は、新規の設定要求が処理待ちのキュー（図１３のステップＳ１１０８参照）に存在するか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ１３０６に進み、それ以外の場合は、今回周期の処理をそのまま終了する。

ステップＳ１３０６では、サーバ装置１０は、ステップＳ１３０４で得た設定要求に応答して、今回のユーザ（今回の新規の設定要求を行ったユーザ）をホストとして、当該ユーザに対応付ける新たな小ボスバトルパートを設定する。なお、この場合、今回のユーザの参加ステータスは、“対戦中”に変更（更新）される。

ステップＳ１３０８では、サーバ装置１０は、第１フラグＦ１を“１”にセットする。

ステップＳ１３１０では、サーバ装置１０は、小ボスバトルパートに小ボスｍ２を対応付けて、当該小ボスバトルパートを開始する。

ステップＳ１３１２では、サーバ装置１０は、小ボスｍ２のＨＰの値の更新条件が満たされたか否かを判定する。小ボスｍ２のＨＰの値の更新条件は、例えば小ボスｍ２がユーザの第１ゲーム媒体ｍ０から攻撃を受けた場合等に満たされる。判定結果が“ＹＥＳ”の場合、ステップＳ１３１４に進み、それ以外の場合は、ステップＳ１３１６に進む。

ステップＳ１３１４では、サーバ装置１０は、小ボスｍ２のＨＰの値を更新する。

ステップＳ１３１６では、サーバ装置１０は、ユーザの第１ゲーム媒体ｍ０のＨＰの値の更新条件が満たされたか否かを判定する。ユーザの第１ゲーム媒体ｍ０のＨＰの値の更新条件は、例えユーザの第１ゲーム媒体ｍ０が小ボスｍ２から攻撃を受けた場合等に満たされる。判定結果が“ＹＥＳ”の場合、ステップＳ１３１８に進み、それ以外の場合は、ステップＳ１３２０に進む。

ステップＳ１３１８では、サーバ装置１０は、ユーザの第１ゲーム媒体ｍ０のＨＰの値を更新する。

ステップＳ１３２０では、サーバ装置１０は、今回のユーザから救援要請を受信したか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ１３２２に進み、それ以外の場合は、ステップＳ１３２３に進む。

ステップＳ１３２２では、サーバ装置１０は、救援要請を他のユーザに送信し、救援待ちタイマをセットする。救援待ちタイマは、所定時間ΔＴ１でタイムアウトするタイマである。

ステップＳ１３２３では、サーバ装置１０は、救援待ちタイマが計時中であるか否かを判定する。なお、救援待ちタイマは、計時開始から所定時間ΔＴ１が経過すると、タイムアウトして計時を終了する。判定結果が“ＹＥＳ”の場合、ステップＳ１３２４に進み、それ以外の場合（救援待ちタイマがタイムアウトしている場合、又は、救援待ちタイマが起動していない場合）は、ステップＳ１３２７Ａに進む。

ステップＳ１３２４では、サーバ装置１０は、救援要請に対する救援受諾を受信したか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ１３２６に進む。他方、判定結果が“ＮＯ”の場合は、ステップＳ１３２２と同様、今回周期の処理をそのまま終了する。この場合、所定時間ΔＴ１だけ、救援要請に対する救援受諾の受信待ち状態となる。

ステップＳ１３２６では、サーバ装置１０は、救援受諾を行った新たなユーザを、今回の小ボスバトルパートに対応付ける。すなわち、今回の小ボスバトルパートに対応付けられるユーザ群に、救援受諾を行った新たなユーザを追加する。この際、ゲームデータ記憶部１６０内のゲームデータ（図１０参照）が更新される。なお、この場合、救援受諾を行った新たなユーザの参加ステータスは、“対戦中”に変更（更新）され、また、参加ステータスは“救援”とされてよい。

ステップＳ１３２７Ａでは、サーバ装置１０は、小ボスバトルパートに係る設定要求であって、今回の小ボスバトルパートに対する参加型の設定要求をいずれかの端末装置２０（すなわちいずれかのユーザ）から受信したか否かを判定する。例えば、サーバ装置１０は、参加型の設定要求が処理待ちのキュー（図１３のステップＳ１１０８参照）に存在するか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ１３２７Ｂに進み、それ以外の場合は、ステップＳ１３２８に進む。

ステップＳ１３２７Ｂでは、サーバ装置１０は、参加型の設定要求を行った新たなユーザを、今回の小ボスバトルパートに対応付ける。すなわち、今回の小ボスバトルパートに対応付けられるユーザ群に、参加型の設定要求を行った新たなユーザを追加する。この際、ゲームデータ記憶部１６０内のゲームデータ（図１０参照）が更新される。なお、この場合、参加型の設定要求を行った新たなユーザの参加ステータスは、“対戦中”に変更（更新）され、また、参加ステータスは“援護”とされてよい。

ステップＳ１３２８では、サーバ装置１０は、小ボスバトルパートの終了条件が満たされたか否かを判定する。小ボスバトルパートの終了条件は、例えば、小ボスｍ２のＨＰの値及びユーザの第１ゲーム媒体ｍ０のＨＰの値のいずれかが０となった場合等に満たされる。判定結果が“ＹＥＳ”の場合、ステップＳ１３３２に進み、それ以外の場合は、ステップＳ１３３０に進む。

ステップＳ１３３０では、サーバ装置１０は、小ボスバトルパートを進行させて、今回周期の処理を終了する。

ステップＳ１３３２では、サーバ装置１０は、第１フラグＦ１を“０”にセットし、今回の小ボスバトルパートを終了させる処理を開始する。なお、この場合、今回のユーザの参加ステータスが“待機中”に変更（更新）される態様で、参加状況データ９００等が更新される。

ステップＳ１３３４では、サーバ装置１０は、今回の小ボスバトルパートの結果として、小ボスｍ２が倒されたか否かを判定する。すなわち、小ボスｍ２の討伐が成功したか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ１３３６に進み、それ以外の場合は、ステップＳ１３４０に進む。

ステップＳ１３３６では、サーバ装置１０は、小ボスｍ２のＨＰの初期値だけ、大ボスｍ１のＨＰを減算させるためのＨＰ減算指示を生成する。なお、小ボスｍ２のＨＰの初期値が固定である場合は、ＨＰ減算指示は、減算量（小ボスｍ２のＨＰの初期値）の情報を含まなくてもよい。

ステップＳ１３３８では、サーバ装置１０は、小ボスｍ２の敗北シーンが描画される終了画像を含むゲーム画像が、対応するユーザ（今回の小ボスバトルパートに対応付けられている１人以上のユーザ）の端末装置２０で表示されるように表示用画像情報を生成する。また、この場合、終了画像は、小ボスｍ２が敗北する（討伐される）ことで、大ボスｍ１のＨＰの値が更新される様子が描画されてよい。

ステップＳ１３４０では、サーバ装置１０は、小ボスｍ２の勝利シーンが描画される終了画像を含むゲーム画像が、対応するユーザの端末装置２０で表示されるように表示用画像情報を生成する。

このような図１５に示す処理は、小ボスバトルパートが設定されると、小ボスバトルパートごとに実行される。従って、複数の小ボスバトルパートが連続して設定されると、図１５に示す処理は、小ボスバトルパートごとに並列して実行される。そして、各小ボスバトルパートに係る図１５に示す処理は、小ボスｍ２が倒されて小ボスバトルパートが終了する場合は、ＨＰ減算指示を生成（ステップＳ１３３６）して終了する。従って、ＨＰ減算指示は、ランダムなタイミングで生成されうる。

図１６は、図１５に示した減算指示生成処理と並列に実行されるＨＰ減算処理であって、大ボスバトルパートにおけるＨＰ減算処理の一例を示す概略的なフローチャートである。図１６に示す処理は、レイドゲームパートの進行中、所定周期ごとに繰り返し実行されてよい。

ステップＳ１４０２では、サーバ装置１０は、新たな大ボスバトルパートの進行状態を示す第２フラグＦ２が“０”であるか否かを判定する。第２フラグＦ２が“０”である場合は、新たな大ボスバトルパートの開始待ち状態に対応し、第２フラグＦ２が“１”である場合は、新たな大ボスバトルパートの進行中状態に対応する。判定結果が“ＹＥＳ”の場合、ステップＳ１４０４に進み、それ以外の場合は、ステップＳ１４１２に進む。

ステップＳ１４０４では、サーバ装置１０は、新たな大ボスバトルパートの開始条件が満たされたか否かを判定する。新たな大ボスバトルパートの開始条件は、任意である。例えば、１つ目の大ボスバトルパートの開始条件は、所定時刻になった場合に満たされてよい。２つ目以降の大ボスバトルパートの開始条件は、前の大ボスバトルパートが終了してから所定時間ΔＴ２が経過した場合に満たされてよい。判定結果が“ＹＥＳ”の場合、ステップＳ１４０６に進み、それ以外の場合は、今回周期の処理をそのまま終了する。

ステップＳ１４０６では、サーバ装置１０は、第２フラグＦ２を“１”にセットする。

ステップＳ１４０８では、サーバ装置１０は、新たな大ボスバトルパートに大ボスｍ１を対応付けて、当該大ボスバトルパートを開始する。

ステップＳ１４１０では、サーバ装置１０は、ユーザからの設定要求（小ボスバトルパートに係る設定要求）の受け付けを開始するゲーム画像が各端末装置２０で表示されるように表示用画像情報を生成する。

ステップＳ１４１２では、サーバ装置１０は、図１５に示した減算指示生成処理によりＨＰ減算指示（ステップＳ１３３６）が生成されたか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ１４１４に進み、それ以外の場合は、今回周期の処理を終了する。

ステップＳ１４１４では、サーバ装置１０は、大ボスｍ１のＨＰの値を更新する。すなわち、サーバ装置１０は、ＨＰ減算指示に含まれる減算量（小ボスｍ２のＨＰの初期値）だけ、大ボスｍ１のＨＰの値を減らすことで、大ボスｍ１のＨＰの値を更新する。

ステップＳ１４１６では、サーバ装置１０は、今回の大ボスバトルパートの終了条件が満たされたか否かを判定する。大ボスバトルパートの終了条件は、例えば、大ボスｍ１のＨＰの値が０となった場合や、今回の大ボスバトルパートの持続時間が所定時間ΔＴ３を超えた場合等に満たされる。判定結果が“ＹＥＳ”の場合、ステップＳ１４１８に進み、それ以外の場合は、今回周期の処理をそのまま終了する。

ステップＳ１４１８では、サーバ装置１０は、第２フラグＦ２を“０”にセットし、今回の大ボスバトルパートを終了させる処理を開始する。この場合、現在進行中の小ボスバトルパート（小ボスｍ２のＨＰの値が０より大きい状態の小ボスバトルパート）が存在する場合は、当該小ボスバトルパートを終了させる指示を生成する。

ステップＳ１４２０では、サーバ装置１０は、大ボスｍ１の敗北シーンが描画される終了画像を含むゲーム画像が、各ユーザ（例えば、参加ステータスが「退出中」以外の各ユーザ）の端末装置２０で表示されるように表示用画像情報を生成する。

ステップＳ１４２２では、サーバ装置１０は、今回の大ボスバトルパートが、今回のレイドゲームパートの最後の大ボスバトルパートであるか否かを判定する。すなわち、今回のレイドゲームパートに対応付けられた大ボスｍ１が、最後の大ボスｍ１（いわゆる「ラスボス」）であるか否かを判定する。判定結果が“ＹＥＳ”の場合、ステップＳ１４２４に進み、それ以外の場合は、今回周期の処理をそのまま終了する。

ステップＳ１４２４では、サーバ装置１０は、今回のレイドゲームパートを終了させる。この場合、サーバ装置１０は、レイドゲームパートの終了画像を含むゲーム画像が、各ユーザ（例えば、参加ステータスが「待機中」及び「退出中」のすべてのユーザ）の端末装置２０で表示されるように表示用画像情報を生成してよい。

このような図１６に示す処理は、図１５に示した減算指示生成処理によりＨＰ減算指示が生成された場合（ステップＳ１４１２の“ＹＥＳ”）のみ、ステップＳ１４１４以降の実質的な処理を行うので、処理負荷を低減できる。すなわち、図１６に示す処理は、図１５に示した減算指示生成処理によるＨＰ減算指示の生成状況を監視しつつ、ＨＰ減算指示が生成された場合（ステップＳ１４１２の“ＹＥＳ”）のみ、ステップＳ１４１４以降の実質的な処理を行うことができる。これにより、上述したように、膨大なユーザがレイドゲームパートに参加するような状況下においても、大ボスｍ１のＨＰの値の更新頻度を低減して、処理負荷を低減できる。

以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

例えば、上述した実施形態では、一の小ボスバトルパートに対して一の小ボスｍ２が対応付けられているが、一の小ボスバトルパートに対して複数の小ボスｍ２が対応付けられてもよい。この場合、当該一の小ボスバトルパートが、当該複数の小ボスｍ２が倒されて終了すると、複数の小ボスｍ２のそれぞれのＨＰの初期値の合計が、大ボスｍ１のＨＰの値から減算されることで、大ボスｍ１のＨＰの値が更新されてよい。

また、上述した実施形態では、大ボスｍ１に第１パラメータとしてＨＰを対応付け、小ボスｍ２に第２パラメータとしてＨＰを対応付け、小ボスｍ２のＨＰの値が第２所定値α２以上減るごとに、大ボスｍ１のＨＰの値を減らしているが、これに限られない。例えば、第１パラメータ及び／又は第２パラメータは、ＨＰ以外のパラメータであってよい。具体的には、第１パラメータ及び第２パラメータは、所定の領域を制圧する際の制圧量であってもよい。この場合、小領域が“小ボス”と同様の態様で設定されてよく、小領域が制圧されるごとに、より大きい大領域（“大ボス”）の制圧が進む態様でゲームが進行されてもよい。また、第１パラメータ及び第２パラメータは、ポイントや点数であってもよい。この場合、ポイントや点数の獲得状況は、ユーザごとに更新されるが、全体の獲得ポイントや点数は、ユーザごとのポイントや点数の獲得が所定量（第２所定値α２に対応）以上となるごとに、更新されてもよい。

また、大ボスｍ１に第１パラメータとしてＨＰを対応付け、小ボスｍ２に、ポイントなどのＨＰ以外の第２パラメータを対応付け、小ボスｍ２に係る第２パラメータの値が第２所定値α２以上減るごとに、大ボスｍ１のＨＰの値を減らしてもよい。あるいは、大ボスｍ１と小ボスｍ２との関係と同様に、小ボスｍ２に対して１つ以上の孫ボスが設定されてもよく、一の小ボスｍ２に対応付けられたすべての孫ボスが倒されると、小ボスｍ２が倒される仕様とされてもよい。

また、上述した実施形態では、小ボスバトルパートに小ボスｍ２を対応付けているが、小ボスｍ２の概念を無くし、小ボスバトルパートに大ボスｍ１を対応付けてもよい。この場合、第２パラメータとして、第１ゲーム媒体ｍ０から大ボスｍ１への攻撃に応じて増加するポイントが設定され、ポイントが第２所定値α２以上変化した場合だけ、当該ポイントの変化分だけ大ボスｍ１のＨＰの値が減算されてもよい。なお、小ボスｍ２の概念を無くす構成は、これに限定されることなく、上述した各種の実施形態やその変形例においても、小ボスｍ２の概念が存在しない構成を実現できる。例えば、小領域が“小ボス”と同様の態様で設定され、小領域が制圧されるごとに、より大きい大領域（“大ボス”）の制圧が進む構成に関しては、小領域が存在せず、第２パラメータとして、制圧量に応じて増加するポイントが設定され、ポイントが第２所定値α２以上変化した場合だけ、当該ポイントの変化分だけ大領域の制圧状態が更新されてもよい。

１ ゲームシステム
１０ サーバ装置
１１ サーバ通信部
１２ サーバ記憶部
１３ サーバ制御部
２０ 端末装置
２１ 端末通信部
２２ 端末記憶部
２３ 表示部
２４ 入力部
２５ 端末制御部
３０ ネットワーク
１５０ ゲームパート設定部
１５１ 参加管理部
１５２ 小ボスバトル設定部
１５３ 大ボス関連処理部
１５３１ 第１設定部
１５３２ 第１更新部
１５３３ 第１判定部
１５４ 小ボスバトル処理部
１５４１ 第２設定部
１５４２ 第２更新部
１５４３ 第２判定部
１５５ 救援要請処理部
１５６ ゲーム状態管理部
１５７ 同時プレイ検出部
１５８ 画像生成部
１５９ 報酬付与部
１６０ ゲームデータ記憶部

Claims (24)

1. 複数のユーザと特定の対戦相手との間の対戦ゲームパートを設定するゲームパート設定部と、
   前記対戦ゲームパートの進行に基づいて、前記特定の対戦相手に対応付けられる第１パラメータの値を更新する第１更新部と、
   前記対戦ゲームパートの進行に基づいて、前記特定の対戦相手に対応付けられる第２パラメータの値を更新する第２更新部と、を備え、
   前記第１更新部は、前記第２更新部により更新された前記第２パラメータの値に基づいて、前記第２更新部よりも少ない更新頻度で前記第１パラメータの値を更新する、情報処理システム。
2. 前記第１パラメータの初期値である第１初期値と、固定値又は可変値である第１所定値とを設定する第１設定部と、
   前記第２パラメータの初期値である第２初期値と、前記第１所定値よりも小さい固定値又は可変値である第２所定値とを設定する第２設定部と、
   前記第１更新部により更新された前記第１パラメータの値が前記第１初期値に対して前記第１所定値以上変化したか否かを判定する第１判定部と、
   前記第２更新部により更新された前記第２パラメータの値が前記第２初期値に対して前記第２所定値以上変化したか否かを判定する第２判定部とを、更に備え、
   前記第１更新部は、前記第２判定部により前記第２パラメータの値が前記第２初期値に対して前記第２所定値以上変化したと判定された場合に、前記第２所定値に応じた値だけ前記第１パラメータの値を変化させることで、前記第１パラメータの値を更新する、請求項１に記載の情報処理システム。
3. 前記ゲームパート設定部は、前記第１判定部により前記第１パラメータの値が前記第１初期値に対して前記第１所定値以上変化したと判定されると、新たな前記特定の対戦相手に係る前記対戦ゲームパートを新たに設定し、
   前記第１設定部は、前記ゲームパート設定部により前記対戦ゲームパートが新たに設定されるごとに前記第１所定値が前回値以上となる態様で、前記第１所定値を設定する、請求項２に記載の情報処理システム。
4. 前記第２パラメータを複数設定する第２パラメータ設定部を更に備え、
   前記第２設定部、前記第２更新部及び前記第２判定部は、前記第２パラメータ設定部により設定される前記第２パラメータごとに機能し、
   前記第１更新部は、前記第２判定部によりいずれかの前記第２パラメータの値が前記第２初期値に対して前記第２所定値以上変化したと判定されるごとに、前記第１パラメータの値を更新する、請求項２又は３に記載の情報処理システム。
5. 前記第２パラメータ設定部は、１人以上のユーザごとに、前記１人以上のユーザに一の前記第２パラメータが対応付けられる態様で、前記第２パラメータを設定する、請求項４に記載の情報処理システム。
6. 前記第２パラメータ設定部は、前記複数のユーザのうちの、所定関係を有する２人以上のユーザに対して、一の前記第２パラメータを設定する、請求項５に記載の情報処理システム。
7. 前記第２パラメータ設定部は、常に、前記複数のユーザのそれぞれに対して、一の前記第２パラメータを設定する、請求項５又は６に記載の情報処理システム。
8. 前記対戦ゲームパートは、参加中の前記複数のユーザの構成が変化する態様で、新たなユーザの後からの参加及び参加中のユーザの途中からの退出が可能であり、
   前記対戦ゲームパートへのユーザの参加状況を更新する参加管理部を更に備え、
   前記第２パラメータ設定部は、前記参加状況に応じて、前記第２パラメータを設定する、請求項５又は６に記載の情報処理システム。
9. 前記第２パラメータ設定部は、前記第１判定部により、一の特定の対戦相手に対応付けられる前記第１パラメータの値が前記第１初期値に対して前記第１所定値以上変化したと判定されるまで、前記一の特定の対戦相手に対応付けられる前記第２パラメータを次々と新たに設定する、請求項８に記載の情報処理システム。
10. 前記第２パラメータ設定部は、設定した前記第２パラメータの数分の前記第２所定値の合計値が、前記第１所定値を超えるが、前記第１所定値よりも大きい所定の上限値を超えないように、前記第２パラメータを設定する、請求項９に記載の情報処理システム。
11. 前記第２所定値は、固定値であり、
    前記第２パラメータ設定部は、前記第１所定値を前記第２所定値で割ることで得られる値よりも大きい数であって、所定の上限数を超えない数だけ、前記第２パラメータを設定する、請求項９に記載の情報処理システム。
12. 前記第２パラメータ設定部は、各ユーザに所定の上限数を超える数の前記第２パラメータが対応付けられている状態が形成されないように、前記第２パラメータを設定する、請求項９に記載の情報処理システム。
13. 前記第２パラメータ設定部は、前記複数のユーザの数が閾値を超えた場合に、２人以上のユーザに対して、一の前記第２パラメータを新たに設定する、請求項９に記載の情報処理システム。
14. 前記第２パラメータ設定部は、一のユーザからの設定要求に応じて、前記一のユーザに対応付けられる前記第２パラメータを新たに設定する、又は、既に他のユーザに対応付けられて設定されている前記第２パラメータを前記一のユーザに更に対応付ける、請求項５、６、８から１３のうちのいずれか１項に記載の情報処理システム。
15. 前記第２パラメータ設定部により２つ以上の前記第２パラメータが一のユーザに対応付けられている場合に、前記第２更新部は、２つ以上の前記第２パラメータが対応付けられているユーザからの入力に基づいて、２つ以上の前記第２パラメータのそれぞれ又は一部の値を更新する、請求項４から１４のうちのいずれか１項に記載の情報処理システム。
16. ユーザ情報を記憶するユーザ情報記憶部を更に備え、
    前記第２設定部は、前記第２パラメータ設定部により前記第２パラメータが新たに設定される場合に、前記第２パラメータが対応付けるユーザに係る前記ユーザ情報に基づいて、前記ユーザ情報に応じて異なる前記第２所定値を設定する、請求項４から１５のうちのいずれか１項に記載の情報処理システム。
17. 前記第２設定部は、前記第１所定値、及び、前記第１更新部により更新された前記第１パラメータの値、のうちのいずれか一方の値に基づいて、前記いずれか一方の値に応じて前記第２所定値が変化する態様で前記第２所定値を設定する、請求項４から１６のうちのいずれか１項に記載の情報処理システム。
18. 前記第１更新部は、１つ以上のコンピュータにより実現され、
    前記第２更新部は、前記第１更新部よりも多い数のコンピュータにより実現される、請求項４から１７のうちのいずれか１項に記載の情報処理システム。
19. 各ユーザに係るユーザ端末に画像を表示させるための表示用画像情報を生成する画像生成部を更に備え、
    前記画像生成部は、前記第１パラメータの値が前記第１更新部により更新されるごとに、前記特定の対戦相手に係る画像と、更新後の前記第１パラメータの値を表す画像と表示させるための第１表示用画像情報を生成する、請求項２から１８のうちのいずれか１項に記載の情報処理システム。
20. 前記画像生成部は、前記第２パラメータの値が前記第２更新部により更新されるごとに、前記特定の対戦相手に係る画像と、更新後の前記第２パラメータの値を表す画像とを表示させるための第２表示用画像情報を生成する、請求項１９に記載の情報処理システム。
21. 前記画像生成部は、前記第１パラメータの値に対応付けて前記特定の対戦相手を表示するときと、前記第２パラメータの値に対応付けて前記特定の対戦相手を表示するときとで、異なる態様で前記特定の対戦相手が描画されるように前記表示用画像情報を生成する、請求項１９又は２０に記載の情報処理システム。
22. 前記画像生成部は、前記第１パラメータの値に対応付けて前記特定の対戦相手を表示する場合は、第１識別子に対応付けられたゲーム媒体が描画され、かつ、前記第２パラメータの値に対応付けて前記特定の対戦相手を表示する場合は、第２識別子に対応付けられたゲーム媒体が描画されるように前記表示用画像情報を生成する、請求項１９から２１のうちのいずれか１項に記載の情報処理システム。
23. 複数のユーザと特定の対戦相手との間の対戦ゲームパートを設定するゲームパート設定ステップと、
    前記対戦ゲームパートの進行に基づいて、前記特定の対戦相手に対応付けられる第１パラメータの値を更新する第１更新ステップと、
    前記対戦ゲームパートの進行に基づいて、前記特定の対戦相手に対応付けられる第２パラメータの値を更新する第２更新ステップと、を備え、
    前記第１更新ステップは、前記第２パラメータの値に基づいて、前記第２更新ステップよりも少ない更新頻度で前記第１パラメータの値を更新する、コンピュータにより実行される情報処理方法。
24. 複数のユーザと特定の対戦相手との間の対戦ゲームパートを設定するゲームパート設定処理と、
    前記対戦ゲームパートの進行に基づいて、前記特定の対戦相手に対応付けられる第１パラメータの値を更新する第１更新処理と、
    前記対戦ゲームパートの進行に基づいて、前記特定の対戦相手に対応付けられる第２パラメータの値を更新する第２更新処理と、
    をコンピュータに実行させ、
    前記第１更新処理は、前記第２パラメータの値に基づいて、前記第２更新処理よりも少ない更新頻度で前記第１パラメータの値を更新する、情報処理プログラム。

Images