IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ グリー株式会社の特許一覧

特許7378744情報処理システム、情報処理方法、情報処理プログラム
<>
  • 特許-情報処理システム、情報処理方法、情報処理プログラム 図1
  • 特許-情報処理システム、情報処理方法、情報処理プログラム 図2
  • 特許-情報処理システム、情報処理方法、情報処理プログラム 図3
  • 特許-情報処理システム、情報処理方法、情報処理プログラム 図4
  • 特許-情報処理システム、情報処理方法、情報処理プログラム 図5
  • 特許-情報処理システム、情報処理方法、情報処理プログラム 図6
  • 特許-情報処理システム、情報処理方法、情報処理プログラム 図7
  • 特許-情報処理システム、情報処理方法、情報処理プログラム 図8
  • 特許-情報処理システム、情報処理方法、情報処理プログラム 図9
  • 特許-情報処理システム、情報処理方法、情報処理プログラム 図10
  • 特許-情報処理システム、情報処理方法、情報処理プログラム 図11
  • 特許-情報処理システム、情報処理方法、情報処理プログラム 図12
  • 特許-情報処理システム、情報処理方法、情報処理プログラム 図13
  • 特許-情報処理システム、情報処理方法、情報処理プログラム 図14A
  • 特許-情報処理システム、情報処理方法、情報処理プログラム 図14B
  • 特許-情報処理システム、情報処理方法、情報処理プログラム 図15
  • 特許-情報処理システム、情報処理方法、情報処理プログラム 図16
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-11-06
(45)【発行日】2023-11-14
(54)【発明の名称】情報処理システム、情報処理方法、情報処理プログラム
(51)【国際特許分類】
   A63F 13/58 20140101AFI20231107BHJP
   A63F 13/45 20140101ALI20231107BHJP
   A63F 13/847 20140101ALI20231107BHJP
【FI】
A63F13/58
A63F13/45
A63F13/847
【請求項の数】 15
(21)【出願番号】P 2022127631
(22)【出願日】2022-08-10
(62)【分割の表示】P 2020201306の分割
【原出願日】2020-12-03
(65)【公開番号】P2022163156
(43)【公開日】2022-10-25
【審査請求日】2022-09-01
(73)【特許権者】
【識別番号】504437801
【氏名又は名称】グリー株式会社
(74)【代理人】
【識別番号】110002871
【氏名又は名称】弁理士法人坂本国際特許商標事務所
(72)【発明者】
【氏名】吉本 誠也
(72)【発明者】
【氏名】倭 拓也
(72)【発明者】
【氏名】長 和樹
(72)【発明者】
【氏名】三上 智也
【審査官】安田 明央
(56)【参考文献】
【文献】特開2020-062315(JP,A)
【文献】特開2020-171788(JP,A)
【文献】国際公開第2020/053955(WO,A1)
【文献】レイドボス襲来 - 部分的過ぎる攻略,[online],2020年07月30日,インターネット: <URL:http://c21boost.blog.fc2.com/blog-entry-475.html>,[検索日2021.11.17]
【文献】ガーディアンレイド,[online],2020年09月23日,インターネット: <URL:https://pages.pmang.jp/lostark/posts/326>,[検索日2021.11.17]
(58)【調査した分野】(Int.Cl.,DB名)
A63F 13/00-13/98
A63F 9/24
(57)【特許請求の範囲】
【請求項1】
複数のユーザと特定の対戦相手との間の対戦ゲームパートを設定するゲームパート設定部と、
前記対戦ゲームパートの進行に基づいて、一の第1の特定の対戦相手に対応付けられる第1パラメータの値を更新する第1更新部と、
前記複数のユーザがそれぞれ1人以上のユーザからなる複数のグループに設定され、前記複数のグループのそれぞれが個々に一の第2の特定の対戦相手を対応付けられて並列的に対戦する場合、前記対戦ゲームパートの進行に基づいて、各グループについて、前記一の第2の特定の対戦相手に対応付けられる第2パラメータの値を更新する第2更新部と、を備え、
前記第1更新部は、前記第2更新部により更新された各グループに係る前記第2パラメータの値に基づいて、前記第2更新部よりも少ない更新頻度で前記第1パラメータの値を更新し、
一のグループに係る前記一の第2の特定の対戦相手が倒された場合、それに伴い前記第1更新部により更新された前記第1パラメータの値が所定の条件を満たしたと判定されるまで、前記一のグループは、次の一の第2の特定の対戦相手を対応付けられて対戦する、情報処理システム。
【請求項2】
前記所定の条件は、更新された前記第1パラメータの値が第1初期値に対して第1所定値以上変化したことを含む、請求項1に記載の情報処理システム。
【請求項3】
前記第2パラメータは、前記一のグループが前記次の一の第2の特定の対戦相手を対応付けられて対戦する場合、前記次の一の第2の特定の対戦相手に対応付けられるように新たに設定される、請求項1又は2に記載の情報処理システム。
【請求項4】
前記第2パラメータは、各グループに設定された前記1人以上のユーザごとに一の前記第2パラメータが対応付けられる態様で、設定される、請求項1から3のいずれか1項に記載の情報処理システム。
【請求項5】
前記対戦ゲームパートは、各グループについて、参加中の前記1人以上のユーザの構成が変化する態様で、新たなユーザの後からの参加及び参加中のユーザの途中からの退出が可能であり、
前記第2パラメータは、前記対戦ゲームパートへのユーザの参加状況に応じて、設定される、請求項1から4のいずれか1項に記載の情報処理システム。
【請求項6】
前記第1更新部は、各グループについて、前記第2パラメータの値が第2初期値に対して第2所定値以上変化したと判定されるごとに、前記第1パラメータの値を更新する、請求項2に記載の情報処理システム。
【請求項7】
前記第2パラメータは、各グループについて、設定した前記第2パラメータの数分の前記第2所定値の合計値が、前記第1所定値を超えるが、前記第1所定値よりも大きい所定の上限値を超えないように、設定される、請求項6に記載の情報処理システム。
【請求項8】
前記第2所定値は、各グループについて、固定値であり、
前記第2パラメータは、各グループについて、前記第1所定値を前記第2所定値で割ることで得られる値よりも大きい数であって、第1の所定の上限数を超えない数だけ、設定される、請求項6に記載の情報処理システム。
【請求項9】
前記第2パラメータが新たに設定される場合に、前記第2所定値は、前記第2パラメータが対応付けるユーザに係るユーザ情報に応じて異なるように設定される、請求項6に記載の情報処理システム。
【請求項10】
前記第2パラメータは、各グループに設定された前記1人以上のユーザごとに第2の所定の上限数を超える数の前記第2パラメータが対応付けられている状態が形成されないように、設定される、請求項1から9のいずれか1項に記載の情報処理システム。
【請求項11】
前記第2パラメータは、各グループについて、前記1人以上のユーザの数が閾値を超えた場合に、2人以上のユーザに対して、一の前記第2パラメータとして新たに設定される、請求項1から10のいずれか1項に記載の情報処理システム。
【請求項12】
前記第2パラメータは、各グループについて、一のユーザからの設定要求に応じて、前記一のユーザに対応付けられるように新たに設定される、又は、既に他のユーザに対応付けられて設定されている前記第2パラメータが前記一のユーザに更に対応付けられる、請求項1から11のうちのいずれか1項に記載の情報処理システム。
【請求項13】
前記複数のグループのうちの2つ以上のグループに参加することにより2つ以上の前記第2パラメータが一のユーザに対応付けられている場合に、前記第2更新部は、2つ以上の前記第2パラメータが対応付けられているユーザからの手動又は自動による操作入力に基づいて、2つ以上の前記第2パラメータのそれぞれ又は一部の値を更新する、請求項1から12のうちのいずれか1項に記載の情報処理システム。
【請求項14】
複数のユーザと特定の対戦相手との間の対戦ゲームパートを設定するゲームパート設定ステップと、
前記対戦ゲームパートの進行に基づいて、一の第1の特定の対戦相手に対応付けられる第1パラメータの値を更新する第1更新ステップと、
前記複数のユーザがそれぞれ1人以上のユーザからなる複数のグループに設定され、前記複数のグループのそれぞれが個々に一の第2の特定の対戦相手を対応付けられて並列的に対戦する場合、前記対戦ゲームパートの進行に基づいて、各グループについて、前記一の第2の特定の対戦相手に対応付けられる第2パラメータの値を更新する第2更新ステップと、を備え、
前記第1更新ステップは、前記第2更新ステップにおいて更新された各グループに係る前記第2パラメータの値に基づいて、前記第2更新ステップよりも少ない更新頻度で前記第1パラメータの値を更新し、
一のグループに係る前記一の第2の特定の対戦相手が倒された場合、それに伴い前記第1更新ステップにおいて更新された前記第1パラメータの値が所定の条件を満たしたと判定されるまで、前記一のグループは、次の一の第2の特定の対戦相手を対応付けられて対戦する、コンピュータにより実行される情報処理方法。
【請求項15】
複数のユーザと特定の対戦相手との間の対戦ゲームパートを設定するゲームパート設定処理と、
前記対戦ゲームパートの進行に基づいて、一の第1の特定の対戦相手に対応付けられる第1パラメータの値を更新する第1更新処理と、
前記複数のユーザがそれぞれ1人以上のユーザからなる複数のグループに設定され、前記複数のグループのそれぞれが個々に一の第2の特定の対戦相手を対応付けられて並列的に対戦する場合、前記対戦ゲームパートの進行に基づいて、各グループについて、前記一の第2の特定の対戦相手に対応付けられる第2パラメータの値を更新する第2更新処理と、をコンピュータに実行させ、
前記第1更新処理は、前記第2更新処理により更新された各グループに係る前記第2パラメータの値に基づいて、前記第2更新処理よりも少ない更新頻度で前記第1パラメータの値を更新し、
一のグループに係る前記一の第2の特定の対戦相手が倒された場合、それに伴い前記第1更新処理により更新された前記第1パラメータの値が所定の条件を満たしたと判定されるまで、前記一のグループは、次の一の第2の特定の対戦相手を対応付けられて対戦する、情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、情報処理システム、情報処理方法、情報処理プログラムに関する。
【背景技術】
【0002】
複数のユーザがグループとなって特定の対戦相手(コンピュータ制御される敵キャラクタ)と対戦する対戦ゲームパート(例えば、レイドと称される対戦ゲームパート)を有するゲームに適用可能な情報処理技術が知られている。
【先行技術文献】
【特許文献】
【0003】
【文献】特開2020-162773公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
上記のようなレイド又はその類の対戦ゲームパートでは、複数のユーザの数が膨大となると、特定の対戦相手のHP(HitPoint)の値を更新するための処理負荷が高まりやすい。
【0005】
そこで、1つの側面では、本発明は、複数のユーザと特定の対戦相手との間の対戦ゲームパートを有するゲームに関して、処理負荷を適切に分散させることを目的とする。
【課題を解決するための手段】
【0006】
1つの側面では、複数のユーザと特定の対戦相手との間の対戦ゲームパートを設定するゲームパート設定部と、
前記対戦ゲームパートの進行に基づいて、前記特定の対戦相手に対応付けられる第1パラメータの値を更新する第1更新部と、
前記対戦ゲームパートの進行に基づいて、前記特定の対戦相手に対応付けられる第2パラメータの値を更新する第2更新部と、を備え、
前記第1更新部は、前記第2更新部により更新された前記第2パラメータの値に基づいて、前記第2更新部よりも少ない更新頻度で前記第1パラメータの値を更新する、情報処理システムが提供される。
【発明の効果】
【0007】
1つの側面では、本発明によれば、複数のユーザと特定の対戦相手との間の対戦ゲームパートを有するゲームに関して、処理負荷を適切に分散させることが可能となる。
【図面の簡単な説明】
【0008】
図1】本発明の一実施形態に係るゲームシステムのブロック図である。
図2】比較例によるレイドゲームパートの概念の説明図である。
図3】本実施形態によるレイドゲームパートの概念の説明図である。
図4】比較例によるレイドゲームパートでの処理負荷の説明図である。
図5】本実施形態によるレイドゲームパートでの処理負荷の説明図である。
図6】ユーザ情報の一例を示す図である。
図7】ゲーム媒体に関する情報の一例を示す図である。
図8】ボスキャラ情報の一例を示す図である。
図9】サーバ装置により実現される各種機能のうちの、レイドゲームパートに関連した機能の説明図である。
図10】ゲームデータ記憶部内のゲームデータの説明図である。
図11】小ボスバトルパートに係るゲーム画像の一例を示す図である。
図12】小ボスバトルパートの終了に伴う大ボスのHPの値の更新を示すゲーム画像の一例を示す図である。
図13】各ユーザからの小ボスバトルパートの設定要求に係る処理の一例を示す概略的なフローチャートである。
図14A図13の選択用画像生成処理(ステップS1104)の処理の一例を示す概略的なフローチャートである。
図14B図13の選択用画像生成処理(ステップS1104)の処理の他の一例を示す概略的なフローチャートである。
図15】小ボスバトルパートにおける減算指示生成処理の一例を示す概略的なフローチャートである。
図16】大ボスバトルパートにおけるHP減算処理の一例を示す概略的なフローチャートである。
【発明を実施するための形態】
【0009】
以下、添付図面を参照しながら各実施形態について詳細に説明する。なお、本明細書において、用語“対応付け”又はそのたぐいに関して、「AとBとが対応付けられている」とは、AとBとが直接的に対応付けられているのみならず、AとBとがC等を介して対応付けられている態様を含む概念である。
【0010】
(ゲームシステムの概要)
図1を参照して、本発明の一実施形態に係るゲームシステム1の概要について説明する。ゲームシステム1は、サーバ装置10と、1つ以上の端末装置20(ユーザ端末の一例)と、を備える。図1では簡便のため、3つの端末装置20を図示しているが、端末装置20の数は2つ以上であればよい。
【0011】
サーバ装置10は、例えばゲーム運営者が管理するサーバ等の情報処理装置である。端末装置20は、例えば携帯電話、スマートフォン、タブレット端末、PC(Personal Computer)、ヘッドマウントディスプレイ、又はゲーム機等の、ユーザによって使用される情報処理装置である。端末装置20は、本実施形態に係るゲームのアプリケーションを実行可能である。ゲームのアプリケーションは、ネットワーク30を介して所定のアプリケーション配信サーバから端末装置20に受信されてもよく、あるいは端末装置20に備えられた記憶装置又は端末装置20が読取可能なメモリカード等の記憶媒体に予め記憶されていてもよい。サーバ装置10及び端末装置20は、ネットワーク30を介して通信可能に接続される。例えば、サーバ装置10及び端末装置20が協働して、ゲームに関する多様な処理を実行する。
【0012】
なお、ネットワーク30は、無線通信網や、インターネット、VPN(Virtual Private Network)、WAN(Wide Area Network)、有線ネットワーク、又はこれらの任意の組み合わせ等を含んでよい。
【0013】
(ゲームの概要)
本実施形態に係るゲームの概要について説明する。本実施形態に係るゲームは、1つ以上のゲームパートを含む。1つ以上のゲームパートのうち少なくとも1つのゲームパートは、ゲーム媒体を用いて実行されてもよい。
【0014】
ゲーム媒体は、ゲームに使用される電子データであり、例えば、カード、アイテム、ポイント、仮想通貨、チケット、キャラクタ、アバタ、パラメータ等、任意の媒体を含む。また、ゲーム媒体は、ユーザによってゲーム内で取得、所有、使用、管理、交換、合成、強化、売却、廃棄、又は贈与等され得る電子データであるが、ゲーム媒体の利用態様は本明細書で明示されるものに限られない。なお、ゲーム媒体は、レベル情報、ステータス情報、パラメータ情報(体力値及び攻撃力等)又は能力情報(スキル、アビリティ、呪文、ジョブ等)のような、ゲーム関連情報であってもよい。
【0015】
以下、特に明示した場合を除き、「ユーザが所有するゲーム媒体」とは、当該ユーザを一意に識別可能なユーザIDに所有ゲーム媒体として対応付けられたゲーム媒体を示す。また、「ゲーム媒体をユーザに付与する」とは、ゲーム媒体を所有ゲーム媒体としてユーザIDに対応付けることを示す。また、「ユーザが所有するゲーム媒体を破棄する」とは、ユーザIDと所有ゲーム媒体との対応付けを解消することを示す。また、「ユーザが所有するゲーム媒体を消費する」とは、ユーザIDと所有ゲーム媒体との対応付けの解消に応じて、何らかの効果又は影響をゲーム内で発生させ得ることを示す。また、「ユーザが所有するゲーム媒体を売却する」とは、ユーザIDと所有ゲーム媒体との対応付けを解消し、且つ、ユーザIDに他のゲーム媒体(例えば、仮想通貨又はアイテム等)を所有ゲーム媒体として対応付けることを示す。
【0016】
ゲームパートは、ゲーム内でユーザがプレイ可能なコンテンツであって、例えばクエスト、ミッション、ミニゲーム、ゲーム媒体の育成、強化、及び合成、ゲーム媒体入手イベント、仮想空間の探索イベント、並びに対戦相手(例えば、他のユーザ、敵キャラクタ、及び敵の建物等)との対戦イベント等を含んでよい。
【0017】
1つ以上のゲームパートには、シングルプレイ用のゲームパートと、マルチプレイ用のゲームパートと、が含まれてもよい。シングルプレイ用のゲームパートは、例えば、1人のユーザが使用する1つの端末装置20に対するユーザ操作に基づいて実行されるゲームパート(例えば、一人用のゲームパート)を含んでもよい。一方、マルチプレイ用のゲームパートは、例えば、2人以上のユーザがそれぞれ使用する2つ以上の端末装置20に対するユーザ操作に基づいて実行される、当該2人以上のユーザに共通のゲームパート(例えば、複数人用のゲームパート)を含んでもよい。2人以上のユーザに共通のゲームパートは、例えば、当該ゲームパートの進行処理の少なくとも一部及び処理結果の少なくとも一部が、当該2人以上のユーザに対して共通して適用されるゲームパートを含んでもよい。例えば、2つ以上の端末装置20が協働して、又は2つ以上の端末装置20とサーバ装置10とが協働して、マルチプレイ用のゲームパートを実行する。
【0018】
本実施形態では、1つ以上のゲームパートには、マルチプレイ用のゲームパートの1つとして、レイドゲームパートを含む。レイドゲームパートは、複数のユーザがグループとなって特定の対戦相手(以下、「大ボスm1」と称する)と対戦する対戦ゲームパートである。大ボスm1は、レイドボス等と称される非常に強力なキャラクタであって、例えばNPC(Non-Player Character)等の自動的に操作されるゲーム媒体である。ただし、変形例では、大ボスm1は、所定のプレイヤにより手動で操作されてもよい。この場合、大ボスm1は、ある一定期間だけ、所定のプレイヤにより手動で操作されてもよいし、全期間にわたって、所定のプレイヤにより手動で操作されてもよい。
【0019】
図2は、比較例によるレイドゲームパートの概念の説明図であり、図3は、本実施形態によるレイドゲームパートの概念の説明図である。
【0020】
比較例によるレイドゲームパートは、図2に概念的に示すように、非常に強い大ボスm1を、各ユーザの第1ゲーム媒体m0が協力して倒す仕様であり、各ユーザの第1ゲーム媒体m0は、大ボスm1に対して直接的に攻撃を加える。なお、各ユーザの端末装置20には、大ボスm1と自身の第1ゲーム媒体m0との対戦ゲームパートが実行される。各ユーザは、端末装置20を介して第1ゲーム媒体m0を操作するので、攻撃タイミング等はまちまちでありうる。このような、レイドゲームパートでは、大ボスm1に係るHPの値を更新するための処理負荷が、ユーザ数(端末装置20の数)が膨大となると、高まりやすい。
【0021】
これに対して、本実施形態によるレイドゲームパートは、図3に概念的に示すように、大ボスm1の“分身”である小ボスm2が、大ボスm1の代わりに、各ユーザからの攻撃を受ける。小ボスm2は、大ボスm1と同じく、例えばNPC等の自動的に操作されるゲーム媒体である。ただし、変形例では、小ボスm2は、所定のプレイヤにより手動で操作されてもよい。例えば、複数の小ボスm2のうちの一部は、所定のプレイヤにより手動で操作されてもよいし、ある一定期間だけ、1つ以上の小ボスm2が、所定のプレイヤにより手動で操作されてもよい。なお、各ユーザの端末装置20には、それぞれの小ボスm2と自身の第1ゲーム媒体m0との対戦ゲームパートが実行される。各ユーザは、端末装置20を介して第1ゲーム媒体m0を操作する。小ボスm2が各ユーザの第1ゲーム媒体m0からの攻撃により倒されると、その小ボスm2の割当分だけのHPの値が、大ボスm1のHPの値から減算される。すなわち、大ボスに小ボスm2のHPが対応付けられる。このようにして、各ユーザは、小ボスm2への攻撃を介して、大ボスm1のHPの値を減らすことができる。なお、小ボスm2は、大ボスm1のHPの値が0になるまで、倒されても次々に出現する。すなわち、小ボスm2は、大ボスm1のHPの値が最終的に0になることができる数、用意される。このようにして、大ボスm1の分身としての小ボスm2の概念を導入することで、大ボスm1に係るHPの値を更新するための処理負荷を低減できる。
【0022】
図4は、図2に示した比較例によるレイドゲームパートでの処理負荷の説明図であり、図5は、本実施形態によるレイドゲームパートでの処理負荷の説明図である。
【0023】
図4及び図5では、横軸に時間を取り、各処理のタイミングが模式的に示されている。図4及び図5において、矢印A1から矢印A4は、各ユーザからの攻撃タイミングを模式的に表し、区間P1~P4、Q1、Q2は、対応する処理タイミングを模式的に表す。
【0024】
図4に示す比較例によるレイドゲームパートでは、区間P1~P4は、各ユーザからの攻撃(矢印A1から矢印A4参照)にそれぞれ応答して、大ボスm1のHPの値を減算する処理に対応する。なお、大ボスm1のHPの値を減算する処理は、各ユーザの端末装置20における大ボスm1のHP表示を更新するための処理も含む場合がある。
【0025】
このように、図4に示す比較例によるレイドゲームパートでは、各ユーザからの攻撃(矢印A1から矢印A4参照)ごとに、大ボスm1のHPの値を減算する処理が発生する。例えば、4回分の攻撃に対して、大ボスm1のHPの値を減算する処理は、4回実行される。
【0026】
これに対して、図5に示す本実施形態によるレイドゲームパートでは、比較例の場合と同じ各ユーザからの攻撃(矢印A1から矢印A4参照)が発生したとき、それぞれ応答して、小ボスに係るHP減算処理と、大ボスm1に係るHP減算処理とが発生する。具体的には、図5において、セクション501は、一の小ボスm2に係るHP減算処理を表し、セクション502は、他の一の小ボスm2に係るHP減算処理を表し、セクション600は、大ボスm1に係るHP減算処理を表す。
【0027】
図5に示す本実施形態によるレイドゲームパートでは、比較例の場合とは異なり、各ユーザからの攻撃(矢印A1から矢印A4参照)ごとに、大ボスm1のHPの値を減算する処理が発生することはない。例えば、4回分の攻撃に対して、大ボスm1に係るHP減算処理は、区間Q1、Q2の2回実行される(矢印A10、A20参照)。
【0028】
このようにして、本実施形態によれば、大ボスm1が各ユーザから攻撃(矢印A1から矢印A4参照)を受ける頻度よりも少ない頻度(矢印A10、A20参照)で、大ボスm1に係るHP減算処理を実行できる。これにより、レイドゲームパートにおける大ボスm1に係るHP減算処理の負荷を低減できる。換言すると、本実施形態によれば、小ボスm2に係るHP減算処理を介して、大ボスm1に係るHP減算処理を実現できるので、処理負荷が分散され、その結果、レイドゲームパートにおける大ボスm1に係るHP減算処理の負荷を低減できる。
【0029】
なお、図4及び図5では、各ユーザから大ボスm1が攻撃を受けたときの、大ボスm1に係るHP減算処理に関するものであるが、大ボスm1からの攻撃を各ユーザに係る第1ゲーム媒体m0に与えるときの処理等についても同様である。例えば、第1ゲーム媒体m0ごとに大ボスm1から攻撃を直接的に与える場合、一の攻撃あたり第1ゲーム媒体m0の数分だけ、第1ゲーム媒体m0のHPの値を減らすための処理が発生しうる。これに対して、大ボスm1が攻撃を複数の小ボスm2を介して複数の第1ゲーム媒体m0に与えることで、レイドゲームパートにおける大ボスm1に係る処理の負荷を低減できる。この場合、複数の小ボスm2は、大ボスm1の攻撃をそのまま実現してもよいし、大ボスm1の攻撃を、小ボスm2の数分だけ分割した攻撃を実現してもよい。あるいは、各小ボスm2の攻撃は、大ボスm1の攻撃をトリガとせずに、それぞれ独自に実現されてもよい。この場合、大ボスm1の直接的な攻撃に係る処理を無くすことができる。あるいは、大ボスm1の攻撃という概念はなく、各小ボスm2の攻撃がそれぞれ独自に実現されてもよい。
【0030】
次に、図1を再度参照しつつ、図6以降を参照して、本実施形態によるゲームシステム1を、より詳細に説明する。
【0031】
(サーバ装置の構成)
サーバ装置10の構成について具体的に説明する。サーバ装置10は、サーバコンピュータにより構成される。サーバ装置10は、複数台のサーバコンピュータにより協動して実現されてもよい。また、サーバ装置10は、Webサーバを含んでよい。この場合、後述する端末装置20の機能の一部は、Webサーバから受領したHTML文書やそれに付随する各種プログラム(Javascript)をブラウザが処理することによって実現されてもよい。
【0032】
サーバ装置10は、サーバ通信部11と、サーバ記憶部12と、サーバ制御部13と、を備える。
【0033】
サーバ通信部11は、外部装置と無線又は有線によって通信し、情報の送受信を行うインタフェースを含む。サーバ通信部11は、例えば無線LAN(Local Area Network)通信モジュール又は有線LAN通信モジュール等を含んでもよい。サーバ通信部11は、ネットワーク30を介して、端末装置20との間で情報を送受信可能である。
【0034】
サーバ記憶部12は、例えば一次記憶装置及び二次記憶装置を含む。例えばサーバ記憶部12は、半導体メモリ、磁気メモリ、又は光メモリ等を含んでもよい。サーバ記憶部12は、ゲームの処理に用いられる種々の情報及びプログラムを記憶する。サーバ記憶部12に記憶された情報及びプログラムの少なくとも一部が、端末装置20との間で共有及び同期されてもよい。以下、サーバ記憶部12が記憶する情報の例について具体的に説明する。
【0035】
(ユーザに関する情報)
サーバ記憶部12(ユーザ情報記憶部の一例)は、複数のユーザそれぞれに関する情報(「ユーザ情報」とも称する)を記憶する。図6を参照して、ユーザ情報について説明する。図6は、2人のユーザそれぞれに関する情報を示す。ユーザ情報は、当該ユーザに固有の種々の情報を含む。例えば、ユーザ情報は、ユーザIDと、ユーザ名と、ランクと、所有ゲーム媒体に関する情報と、使用ゲーム媒体に関する情報と、フレンド情報とを含む。ユーザ情報において、複数のユーザそれぞれと、所有ゲーム媒体に関する情報及び使用ゲーム媒体に関する情報と、フレンド情報とが対応付けられている。
【0036】
ユーザIDは、ユーザを一意に識別可能な情報である。以下、ユーザIDを単にユーザともいう。
【0037】
ユーザ名は、ユーザの名前を示す情報である。ユーザ名は、ユーザIDとは異なり、ユーザを一意に識別可能でなくてもよい。ユーザ名は、端末装置20に対するユーザ操作に応じて任意に決定及び変更が可能であってもよい。
【0038】
ランクは、ゲームに関するユーザの熟練度を示すパラメータである。本実施形態において、ランクの値は、ユーザによるゲームのプレイに応じて増加してもよい。ランクが高いほど、ゲームに関するユーザの熟練度が高い。
【0039】
所有ゲーム媒体に関する情報は、ユーザがゲーム内で所有するゲーム媒体(所有ゲーム媒体)に固有の種々の情報を含む。ゲーム媒体がユーザに取得された場合、当該ゲーム媒体は、所有ゲーム媒体としてユーザに対応付けられる。所有ゲーム媒体に関する情報の詳細については後述する。
【0040】
使用ゲーム媒体に関する情報は、対戦ゲームパート(例えばレイドゲームパート)においてユーザに使用させるゲーム媒体(第1ゲーム媒体)を示す情報である。第1ゲーム媒体は、所有ゲーム媒体のうちから選択される。
【0041】
フレンド情報は、フレンド関係にあるユーザIDを表す。例えば、ユーザAが、ユーザB、Cとフレンド関係である場合、ユーザAに対応付けられたフレンド情報は、ユーザB、CのユーザIDを含む。なお、フレンド関係は、フレンド申請等を介して実現される。このように、フレンド情報は、ユーザとの間で一方向的又は双方向的に関連付けられた他のユーザのユーザIDを含む。なお、フレンド関係にあるユーザ同士は、例えばゲームシステム1上でメッセージの送受信等のコミュニケーションが可能であってもよい。なお、ユーザ情報において、フレンド情報に代えて又は加えて、所属するギルドやパーティを示す情報が含められてもよい。
【0042】
ユーザ情報の内容は、上述したものに限られない。例えば、ユーザ情報は、ユーザがゲーム内で保有する所定のポイントを示す情報を更に含んでもよい。当該ポイントは、ユーザがゲームパートをプレイするために消費される。ゲームパートごとに、当該ポイントの消費量が異なってもよい。当該ポイントは、例えば時間経過に応じて、又は所定のゲーム媒体の使用に応じて、増加してもよい。
【0043】
ここで、図7を参照して、上述した所有ゲーム媒体に関する情報の一例について詳細に説明する。図7は、1人のユーザに対応付けられた2つの所有ゲーム媒体に関する情報を示す。例えば、各所有ゲーム媒体に関する情報は、ゲーム媒体IDと、ゲーム媒体名と、レアリティと、レベルと、コストと、HPの初期値と、攻撃力と、回復力と、ゲーム機能に関する情報と、を含む。
【0044】
ゲーム媒体IDは、ゲーム媒体を一意に識別可能な情報である。ゲーム媒体IDは、予めサーバ記憶部12に記憶されてもよい。あるいは、ゲーム媒体IDは、ゲーム媒体をユーザに取得させるときに、サーバ装置10によって決定されてもよい。
【0045】
ゲーム媒体名は、ゲーム媒体の名前を示す情報である。ゲーム媒体名は、ゲーム媒体IDとは異なり、ゲーム媒体を一意に識別可能でなくてもよい。なお、ゲーム媒体名は、ゲーム媒体を取得したユーザによるゲームのプレイに応じて変化してもよい。
【0046】
レアリティは、ゲーム媒体の希少度(希少価値)を示す情報である。
【0047】
レベルは、ゲーム媒体の成長度を示す情報である。例えば、レベルの値が大きいほど、ゲーム媒体の成長度が大きい。レベルの値は、ユーザによるゲームのプレイに応じて増加してもよい。また、第1ゲーム媒体に係るレベルは、第1ゲーム媒体ごとに上限レベルが設定されてよい。この場合、第1ゲーム媒体の上限レベルは、例えばレアリティが高いほど高くなる態様で設定されてよい。また、第1ゲーム媒体の上限レベルは、特定の強化(例えば限界突破)により引き上げ可能とされてもよい。
【0048】
コストは、対戦ゲームパートに使用するデッキを決定する際に用いられるパラメータである。例えば、各第1ゲーム媒体のコストの合計値が所定の上限HPを超えない範囲で、最大5つの第1ゲーム媒体が1つのデッキに包含可能であってもよい。この場合、当該上限HPは、例えばユーザのランクの増加に応じて増加してもよい。
【0049】
HPは、対戦ゲームパートにおけるユーザの勝敗を決定するために用いられるパラメータである。例えば、デッキを構成して対戦ゲームパートが実現される場合、デッキに含まれるすべての第1ゲーム媒体のHPの初期値の合計と、所定の上限HPのうちの、いずれか小さい方が、対戦ゲームパートの開始時におけるデッキに係るHPの初期値として用いられる。対戦ゲームパートの実行中に、例えば対戦相手の攻撃によってユーザにダメージが与えられると、当該ダメージの量だけHPの値が減少する。対戦ゲームパートの実行中に、例えば回復アイテムが取得されると、HPの値が増加する。HPの値が所定値以上減少すると、ユーザの敗北と判定される。所定値は、HPの初期値に対応する。この場合、HPの値が0まで減少すると、ユーザの敗北と判定される。従って、各第1ゲーム媒体のHPの初期値が大きいほどユーザに有利である。レベルの増加に応じて、HPの初期値が増加してもよい。
【0050】
攻撃力は、例えばゲーム媒体の攻撃によって対戦相手に与えるダメージ量に寄与する情報である。攻撃力の値が大きくなるほど、対戦相手に与えるダメージ量が大きくなる。従って、ゲーム媒体の攻撃力が大きいほどユーザに有利である。レベルの増加に応じて、攻撃力が増加してもよい。
【0051】
回復力は、対戦ゲームパートの実行中に用いられるパラメータである。例えば、デッキを構成して対戦ゲームパートが実現される場合、デッキに含まれるすべての第1ゲーム媒体の回復力の合計が用いられる。対戦ゲームパートの実行中に、例えば回復アイテムが取得されると、ユーザの回復力が増加する。回復力の値が大きくなるほど、HPの値の増加量が大きくなる。従って、デッキに含まれる各第1ゲーム媒体の回復力が大きいほどユーザに有利である。レベルの増加に応じて、回復力が増加してもよい。
【0052】
ゲーム機能に関する情報は、ゲーム媒体に対応付けられたゲーム機能の情報を含む。ゲーム機能は、ゲーム媒体に対応付けられた特別な機能(スキルやアビリティ)であってよい。また、1つのゲーム媒体に任意の数のゲーム機能が対応付けられてもよい。ゲーム機能が発揮されると、例えば対戦ゲームパートにおいて所定のゲーム効果が発生し得る。ゲーム効果の内容は、任意に定められてもよい。例えば、対戦相手に、通常の攻撃よりも大きなダメージを与えるゲーム効果が存在してもよいし、対戦相手の攻撃を弱くするゲーム効果が存在してもよい。発生したゲーム効果が、所定の期間に亘って継続してもよい。
【0053】
ゲーム機能に関する情報の内容は、上述したものに限られない。例えばゲーム機能に関する情報は、当該ゲーム機能のレベル及び経験値を更に含んでもよい。例えば、ユーザが所有する所定のゲーム媒体を消費することによって、ゲーム機能の経験値が増加してもよい。また、ゲーム媒体IDに対応付けられる各種情報は、図7を参照して上述したものに限られず、任意である。
【0054】
(対戦相手であるゲーム媒体に関する情報)
図1に示すサーバ記憶部12は、対戦ゲームパートにおける対戦相手であるゲーム媒体(例えば、NPC)に関する情報(以下、「ボスキャラ情報」とも称する)を記憶する。
【0055】
ここで、図8を参照して、上述したボスキャラ情報の一例について詳細に説明する。本実施形態では、ボスキャラ情報は、大ボスm1とその小ボスm2に関する情報を含む。図8は、2つの大ボスm1に関する情報を示す。例えば、各大ボスm1に関する情報は、ゲーム媒体ID(第1識別子の一例)と、ゲーム媒体名と、属性と、HPの初期値と、攻撃力と、回復力と、ゲーム機能に関する情報と、を含む。ゲーム媒体ID、ゲーム媒体名、HPの初期値、攻撃力等は、上述した所有ゲーム媒体に関する情報と同様であるため、説明は省略する。ただし、大ボスm1は非常に強力であるので、HPの初期値や攻撃力等は非常に大きい。これは、小ボスm2についても同様である。属性は、大ボスm1であることを示す情報である。小ボスm2に関する情報は、ゲーム媒体ID(第2識別子の一例)と、ゲーム媒体名と、属性と、HPの初期値と、攻撃力と、回復力と、ゲーム機能に関する情報と、を含む。この場合、属性は、小ボスm2であることを示すとともに、どの大ボスm1に対する小ボスm2であるかを示す情報(すなわち、大ボスm1のゲーム媒体IDと小ボスm2のゲーム媒体IDとを対応付ける情報)である。例えば、図8に示す例では、ゲーム媒体ID“W01”の小ボスm2は、ゲーム媒体ID“V01”の大ボスm1の分身として機能する小ボスm2である。なお、一の大ボスm1の分身として機能する小ボスm2に対応付けられるHPの初期値は、当該一の大ボスm1に対応付けられるHPの初期値よりも有意に小さい。例えば、一の大ボスm1の分身として機能する小ボスm2に対応付けられるHPの初期値は、当該一の大ボスm1に対応付けられるHPの初期値の、1/1000以下であってもよいし、それよりも小さくてもよい。ただし、後述するように、小ボスm2に対応付けられるHPの初期値は、適宜変化する態様で、設定されてもよい。他方、小ボスm2の攻撃力、回復力、及びゲーム機能に関する情報の少なくともいずれかは、大ボスm1の攻撃力、回復力、及びゲーム機能に関する情報と同じであってもよい。
【0056】
また、ボスキャラ情報は、図8に示すように、ゲーム媒体IDに、描画用情報が対応付けられてよい。描画用情報は、対応付けられたゲーム媒体IDに係るゲーム媒体を描画するために情報であり、描画用情報が同じであれば、描画されるゲーム媒体も基本的に同じ見た目(姿や形)となる。本実施形態では、一の大ボスm1に対応付けられる描画用情報は、当該一の大ボスm1の分身である小ボスm2に対応付けられる描画用情報と同じであるものとする。従って、大ボスm1と小ボスm2は、ゲーム画像上では同じに見える。ただし、小ボスm2は、大ボスm1よりも小さいサイズで描画されてもよい。この場合、小ボスm2が、大ボスm1の“分身”であることをユーザに示唆できる。ただし、変形例では、一の大ボスm1に対応付けられる描画用情報と、当該一の大ボスm1の分身である小ボスm2に対応付けられる描画用情報とは、互いに連想できる関係で僅かな相違が設定されてもよい。
【0057】
図1に示すサーバ制御部13は、1つ以上のプロセッサを含む。プロセッサは、特定のプログラムを読み込むことにより特定の機能を実現する汎用プロセッサ、及び特定の処理に特化した専用プロセッサを含んでもよい。サーバ制御部13は、サーバ装置10全体の動作を制御する。
【0058】
サーバ制御部13は、ゲームの処理に用いられる種々の情報及びプログラムを、サーバ記憶部12に記憶する。ゲームの処理に用いられる情報には、上述したユーザ情報、及びボスキャラ情報等が含まれてもよい。
【0059】
サーバ制御部13は、サーバ通信部11を介して情報の送受信を行う。例えば、サーバ制御部13は、サーバ記憶部12に記憶された情報の少なくとも一部を端末装置20へ送信してもよい。このようにして、サーバ記憶部12に記憶された情報と端末装置20に記憶された情報が共有及び同期される。情報の共有及び同期を行うタイミングは、例えばサーバ記憶部12に新たな情報が記憶されたタイミング、及びサーバ記憶部12に記憶された情報が更新されたタイミングを含み得るが、任意に定められてもよい。
【0060】
サーバ制御部13は、端末装置20と協働して、ゲームを実行する。例えば、サーバ制御部13は、1つ以上の端末装置20と協働して、対戦ゲームパート(例えばレイドゲームパート)を実行する。
【0061】
(端末装置の構成)
端末装置20の構成について具体的に説明する。図1に示すように、端末装置20は、端末通信部21と、端末記憶部22と、表示部23と、入力部24と、端末制御部25とを備える。
【0062】
端末通信部21は、外部装置と無線又は有線によって通信し、情報の送受信を行うインタフェースを含む。端末通信部21は、例えばLTE(Long Term Evolution)(登録商標)等のモバイル通信規格に対応する無線通信モジュール、無線LAN通信モジュール、又は有線LAN通信モジュール等を含んでもよい。端末通信部21は、ネットワーク30を介して、サーバ装置10との間で情報を送受信可能である。
【0063】
端末記憶部22は、例えば一次記憶装置及び二次記憶装置を含む。例えば端末記憶部22は、半導体メモリ、磁気メモリ、又は光メモリ等を含んでもよい。端末記憶部22は、サーバ装置10から受信する、ゲームの処理に用いられる種々の情報及びプログラムを記憶する。ゲームの処理に用いられる情報及びプログラムは、端末通信部21を介して外部装置から取得されてもよい。例えば、ゲームのアプリケーションプログラムが、所定のアプリケーション配信サーバから取得されてもよい。以下、アプリケーションプログラムを、単にアプリケーションともいう。また例えば、上述したユーザ情報及び対戦相手であるゲーム媒体に関する情報等の一部又は全部が、サーバ装置10から取得されてもよい。
【0064】
表示部23は、例えば液晶ディスプレイ又は有機EL(Electro-Luminescence)ディスプレイ等の表示デバイスを含む。表示部23は、多様な画像(例えば各種のゲーム画像)を表示可能である。
【0065】
入力部24は、例えば表示部23と一体的に設けられたタッチパネルを含む入力インタフェースを含む。入力部24は、端末装置20に対するユーザ入力を受付可能である。また、入力部24は、物理キーを含んでもよいし、マウス等のようなポインティングデバイスをはじめとする任意の入力インタフェースを更に含んでもよい。
【0066】
端末制御部25は、1つ以上のプロセッサを含む。端末制御部25は、端末装置20全体の動作を制御する。
【0067】
端末制御部25は、端末通信部21を介して情報の送受信を行う。例えば、端末制御部25は、ゲームの処理に用いられる種々の情報及びプログラムを、サーバ装置10及び他の外部サーバの少なくとも一方から受信する。端末制御部25は、受信された情報及びプログラムを、端末記憶部22に記憶する。
【0068】
端末制御部25は、ユーザ操作に応じてゲームのアプリケーションを起動する。端末制御部25は、サーバ装置10と協働して、ゲームを実行する。例えば、端末制御部25は、ゲームに用いられる種々のゲーム画像を表示部23に表示させる。ゲーム画像には、例えばユーザ操作を検出するGUI(Graphic User Interface)が重畳表示されてもよい。端末制御部25は、入力部24を介して、ゲーム画像を表示する画面に対するユーザ操作を検出可能である。
【0069】
(レイドゲームパートに関連した構成)
次に、主に図9以降を参照して、レイドゲームパートに関連した構成について説明する。以下では、レイドゲームパートに関連したサーバ装置10が、情報処理システムの一例を実現するが、後述するように、特定の一の端末装置20の各要素(図1参照)が、情報処理システムの一例を実現してもよいし、複数の端末装置20が、協動して情報処理システムの一例を実現してもよい。また、サーバ装置10と1つ以上の端末装置20が、協動して情報処理システムの一例を実現してもよい。
【0070】
図9は、サーバ装置10により実現される各種機能のうちの、レイドゲームパートに関連した機能の説明図である。なお、以下で説明するサーバ装置10の機能の一部又は全部は、適宜、端末装置20により実現されてもよい。図10は、ゲームデータ記憶部160内のゲームデータの説明図である。なお、図10等の表において、「***」は何らかの情報が格納されている状態を表し、「・・・」は同様の繰り返しを表す。
【0071】
サーバ装置10は、ゲームパート設定部150と、参加管理部151と、小ボスバトル設定部152(第2パラメータ設定部の一例)と、大ボス関連処理部153と、小ボスバトル処理部154と、救援要請処理部155と、ゲーム状態管理部156と、同時プレイ検出部157(第3判定部の一例)と、画像生成部158と、報酬付与部159と、ゲームデータ記憶部160とを含む。
【0072】
なお、ゲームパート設定部150から報酬付与部159は、図1に示したサーバ制御部13により実現できる。また、ゲームパート設定部150から報酬付与部159のうちの、端末装置20との通信を行う機能部は、図1に示したサーバ制御部13とともにサーバ通信部11により実現できる。また、ゲームデータ記憶部160は、図1に示したサーバ記憶部12により実現できる。
【0073】
ゲームパート設定部150は、レイドゲームパート(及びそれに伴い、当該レイドゲームパートに含まれる大ボスバトルパート等)を設定する。なお、以下で、「ゲームパートを設定する」処理とは、当該ゲームパートを、ユーザが参加可能又はプレイ可能な状態にする処理を指す。
【0074】
例えば、ゲームパート設定部150は、期間限定で、レイドゲームパートを設定してもよい。この場合、例えば、何月何日何時からレイドゲームパートに係るイベントが開催される旨の告知が実行されてもよい。あるいは、ゲームパート設定部150は、ランダムなタイミングで、又は、所定の設定条件が成立したときに、レイドゲームパートを設定してもよい。
【0075】
レイドゲームパートは、1つ以上の大ボスバトルパートを含む。一のレイドゲームパートが複数の大ボスバトルパートを含む場合、複数の大ボスバトルパートは、同時に並列的に進行してもよいし、1つずつ順次、進行してもよい。大ボスバトルパートのそれぞれは、1人以上のユーザに係る第1ゲーム媒体m0が小ボスm2と対戦する小ボスバトルパートを含む。小ボスバトルパートは、後述するように、複数並列的に進行することができる。レイドゲームパートにおいては、後述するように、小ボスバトルパートが次々に設定されていく。
【0076】
本実施形態では、一例として、一のレイドゲームパートにおいて、大ボスバトルパートは、複数設定される。複数の大ボスバトルパートのそれぞれには、一の大ボスm1が対応付けられる。複数の大ボスバトルパートのそれぞれに対応付けられる大ボスm1は、互いに異なってもよい。この場合、ゲームパート設定部150は、一の大ボスバトルパートが終了すると、次の一の大ボスバトルパートを設定するといった具合に、予定されている複数の大ボスバトルパートを、順次設定してもよい。なお、複数の大ボスバトルパートのそれぞれは、ランダムに選択されてもよいし、一回のレイドゲームパートあたりの大ボスバトルパートの数も可変であってよい。また、複数の大ボスバトルパート間には、他のゲームパートが介在してもよい。また、レイドゲームパートに参加中のユーザは、途中でアウトゲームをプレイできる仕様であってもよい。例えば、レイドゲームパートに参加中のユーザは、大ボスバトルパート間の空き時間を利用して、第1ゲーム媒体m0の強化や育成等を行ってもよい。あるいは、レイドゲームパートに参加中のユーザは、大ボスバトルパートの進行を一時的に停止(中断)して、第1ゲーム媒体m0の強化や育成等を行ってもよい。
【0077】
レイドゲームパートは、一旦、進行が開始されると、最後の大ボスバトルパートが終了するまで継続される。以下では、レイドゲームパートの進行中とは、レイドゲームパートの進行が開始した時点から、すべての大ボスm1のHPの値が0になった時点までを指す。
【0078】
参加管理部151は、レイドゲームパートへのユーザの参加状況を更新/管理する。レイドゲームパートへのユーザの参加は、レイドゲームパートの進行中であればいつでも可能とされてよい。レイドゲームパートへのユーザの参加方法は、任意である。例えば端末装置20上のゲーム画像に設定されてよい参加ボタン(図示せず)が操作されると、参加要求がサーバ装置10に送信される。なお、参加ボタンには、大ボスm1を表す表示が、当該大ボスm1に係る描画用情報(図8参照)により描画されてもよい。
【0079】
この場合、参加管理部151は、このような参加要求に基づいて、対応するユーザの、レイドゲームパートへの参加状態を実現する。例えば、参加管理部151は、レイドゲームパートに参加したユーザに係る端末装置20上のゲーム画像を、ロビー画像を含むゲーム画像へと移行させる。また、レイドゲームパートに一旦参加したユーザは、レイドゲームパートの進行中であればいつでも退出可能とされてよい。レイドゲームパートからのユーザの退出方法は、任意である。例えば端末装置20上のゲーム画像に設定されてよい退出ボタン(図示せず)が操作されると、退出要求がサーバ装置10に送信される。この場合、参加管理部151は、このような退出要求に基づいて、対応するユーザの退出を実現する。
【0080】
参加管理部151は、参加状況が変化するごとに、ゲームデータ記憶部160内のゲームデータを更新する。図10には、ゲームデータ記憶部160内のゲームデータのうちの、参加状況データ900の一例が示されている。参加状況データ900は、ユーザIDごとに、参加ステータスを含む。例えば、参加ステータスは、「対戦中」、「待機中」、「退出中」等を含んでよい。なお、「待機中」は、参加しているがロビー画像が表示されている状態等に対応し、「退出中」は、ログインしているがレイドゲームパートに参加していない状態に対応してよい。
【0081】
また、参加状況データ900は、ユーザIDごとに、小ボスm2の討伐数を含んでよい。小ボスm2の討伐数は、後述する小ボスバトルパートにおいて倒した小ボスm2の数である。また、参加状況データ900は、ユーザIDごとに、大ボスm1の討伐数を含んでよい。大ボスm1の討伐数は、大ボスバトルパートにおいて倒した大ボスm1の数である。
【0082】
小ボスバトル設定部152は、各ユーザ(端末装置20)からの設定要求に応答して、小ボスバトルパートを設定する。小ボスバトルパートは、1人以上のユーザに係る第1ゲーム媒体m0が小ボスm2と対戦するゲームパートである。ユーザによる小ボスバトルパートの設定方法は、任意である。例えば端末装置20上のロビー画像に設定されてよいプレイボタン(図示せず)がユーザにより操作されると、端末装置20から設定要求がサーバ装置10に送信される。この場合、小ボスバトル設定部152は、このような設定要求に基づいて、対応するユーザに対応付ける小ボスバトルパートを設定する。なお、プレイボタンには、小ボスm2を表す表示が、当該小ボスm2に係る描画用情報(図8参照)により描画されてもよい。また、設定要求の送信(すなわち小ボスバトルパートのプレイ)は、所定のゲーム媒体(例えばユーザがゲーム内で保有する所定のポイント)の消費を伴ってもよい。
【0083】
小ボスバトル設定部152は、多様な態様で、小ボスバトルパートを設定できる。例えば、小ボスバトル設定部152は、常に一定の設定態様で、小ボスバトルパートを設定してもよい。この場合、小ボスバトル設定部152は、一のユーザに一の小ボスバトルパートが対応付けられる態様で、一のユーザごとに小ボスバトルパートを設定してもよい。また、この場合、小ボスバトル設定部152は、一のユーザからの設定要求に応じて、一のユーザに対応付けられる一の小ボスバトルパートを、即座に設定してもよい。
【0084】
あるいは、小ボスバトル設定部152は、所定数N1のユーザごとに、所定数N1のユーザに一の小ボスバトルパートが対応付けられる態様で、小ボスバトルパートを設定してもよい。この場合、所定数N1は、一定であってもよいし、可変であってよい。例えば、所定数N1は、参加中のユーザ数が多くなるほど、大きい数に設定されてもよい。この場合、小ボスバトル設定部152は、所定数N1のユーザからの設定要求が溜まった時点で、当該所定数N1のユーザからの設定要求に応じて、所定数N1のユーザに対応付けられる一の小ボスバトルパートを、設定してもよい。あるいは、小ボスバトル設定部152は、所定数N1のユーザに一の小ボスバトルパートが対応付けられるまで、各ユーザからの設定要求に応じて、各ユーザに同じ一の小ボスバトルパートを対応付けてもよい。この場合、一の小ボスバトルパートが設定されると、その後、所定数N1のユーザが当該一の小ボスバトルパートに対応付けられるまで、設定要求を新たに送信する各ユーザは、当該一の小ボスバトルパートに途中から参加する形態となる。
【0085】
また、小ボスバトル設定部152は、所定数N1よりも有意に多い数N2のユーザからの設定要求が溜まった時点で、当該数N2のユーザからの設定要求に応じて、所定数N1のユーザごとに、各小ボスバトルパートを設定してもよい。この場合、数N2のユーザのうちの複数のグループ(所定数N1のユーザごとのグループ)への分け方は、ランダムであってもよい。あるいは、小ボスバトル設定部152は、所定関係を有する複数のユーザに同一の小ボスバトルパートを対応付けてもよい。所定関係は、任意であり、ユーザ情報等に基づいて判定されてもよいし、他の情報に基づいて判定されてもよい。例えば、小ボスバトル設定部152は、ユーザ情報に含まれるフレンド情報に基づいて、フレンド関係にあるユーザに同一の小ボスバトルパートを対応付けてもよい。あるいは、同様の観点から、小ボスバトル設定部152は、各ユーザの所属するギルドやパーティを示す情報に基づいて、同一のギルドやパーティに属するユーザに同一の小ボスバトルパートを対応付けてもよい。このような場合、グループ内の複数のユーザ間の連帯感や連携度合いを高めることができる。なお、この場合も、所定関係を有する複数のユーザのうちの一部が小ボスバトルパートに途中から参加する形態が実現されてもよい。
【0086】
また、小ボスバトル設定部152は、大ボス関連処理部153の処理負荷に応じて、所定数N1を動的に変化させてもよい。例えば、所定数N1が大きいほど、一定人数あたりの小ボスバトルパートの数が小さくなり、それ故に、大ボス関連処理部153の処理負荷が小さくなる傾向がある。従って、小ボスバトル設定部152は、大ボス関連処理部153の処理負荷が比較的高い場合に、所定数N1を増加させてもよい。なお、大ボス関連処理部153の処理負荷は、大ボス関連処理部153の稼働状態等に基づいて判断されてもよい。
【0087】
例えば、小ボスバトル設定部152は、ゲームデータ記憶部160内の参加状況データ(図10の参加状況データ900参照)に基づいて、参加ステータスが「対戦中」であるユーザの数が閾値を超えた場合に、2人以上のユーザごとに、一の小ボスバトルパートが対応付けられる態様で、小ボスバトルパートを設定してもよい。この場合、閾値は、大ボス関連処理部153の処理負荷と、大ボス関連処理部153を実現するハードウェア構成の能力との関係に応じて適合されてよい。
【0088】
大ボス関連処理部153は、大ボスバトルパートに関連する各種処理を行う。例えば、大ボス関連処理部153は、大ボスバトルパートの進行に基づいて、大ボスm1のHPの値を更新する。本実施形態では、大ボス関連処理部153は、小ボスバトルパートが終了するごとに、大ボスm1のHPの値を更新する。
【0089】
本実施形態では、大ボスバトルパートは、一旦、進行が開始されると、当該大ボスバトルパートに対応付けられる大ボスm1のHPの値が、その初期値(第1初期値の一例)から第1所定値α1以上減少して0になると、当該大ボスm1が倒されることで終了する。第1所定値α1は、任意であるが、本実施形態では、一の大ボスm1に係る第1所定値α1は、当該大ボスm1のHPの初期値である。ただし、変形例では、第1所定値α1は、大ボスm1のHPの初期値の所定割合(例えば90%)に対応する値であってもよい。この場合、大ボスバトルパートは、一旦、進行が開始されると、当該大ボスバトルパートに対応付けられる大ボスm1のHPの値が、その初期値に対して所定割合以上減少すると、当該大ボスm1が倒されることで終了する。
【0090】
また、本実施形態では、一のレイドゲームパートは、複数の大ボスバトルパートが順次実行される態様で、複数の大ボスバトルパートを含む。また、本実施形態では、一の大ボスバトルパートは、他の終了条件が満たされた場合も終了してよい。例えば、一の大ボスバトルパートは、開始後の経過時間が所定時間ΔT3を超えると、大ボスm1が倒されることなく終了してよい(すなわち大ボスm1が勝利)。
【0091】
図9に示す例では、大ボス関連処理部153は、第1設定部1531と、第1更新部1532と、第1判定部1533とを含む。
【0092】
第1設定部1531は、ゲームパート設定部150により一の大ボスバトルパートが設定されると、当該一の大ボスバトルパートに対応付けられる大ボスm1を設定する。例えば、第1設定部1531は、図8に示したボスキャラ情報に基づいて、大ボスバトルパートごとに、一の大ボスm1を対応付ける。この場合、第1設定部1531は、好ましくは、順次設定される大ボスバトルパートのうちの、後の大ボスバトルパートになるにつれて、対応付けられる大ボスm1のHPの初期値が前回値(直前の大ボスバトルパートに係る大ボスm1のHPの初期値)以上になるように、大ボスバトルパートごとに、一の大ボスm1を対応付ける。例えば、各大ボスバトルパートに対応付けられる大ボスm1は、予め規定されていてもよい(例えば運営側で規定してもよい)。この場合、第1設定部1531は、大ボスバトルパートごとに、予め規定された大ボスm1を設定する。
【0093】
なお、上述したように、本実施形態では、各大ボスm1には、予めHPの初期値が対応付けられている(図8参照)。従って、第1設定部1531が、一の大ボスバトルパートに対応付けられる大ボスm1を設定すると、それに伴い当該一の大ボスバトルパートには、当該一の大ボスバトルパートの大ボスm1のHPの初期値が対応付けられることになる。なお、変形例では、大ボスm1のHPの初期値は、大ボスバトルパートが設定される際に、適宜、補正等されてもよい。
【0094】
第1更新部1532は、レイドゲームパートにおける大ボスバトルパートの進行に基づいて、大ボスm1に対応付けられるHP(第1パラメータの一例)の値(残りの値)を更新する。
【0095】
本実施形態では、図3及び図5を参照して上述したように、第1更新部1532は、小ボスバトルパートが終了するごとに(すなわち、小ボスm2が倒されるごとに)、大ボスm1のHPの値を更新する。これにより、上述したように、大ボスm1に係るHP減算処理の頻度を効果的に低減できる。
【0096】
例えば、小ボスm2が倒されることで小ボスバトルパートが終了した場合、第1更新部1532は、当該小ボスm2のHPの初期値分だけ、大ボスm1のHPの値から減算することで、大ボスm1のHPの値を更新する。ただし、変形例では、第1更新部1532は、当該小ボスm2のHPの初期値に所定係数K1を乗じた値だけ、大ボスm1のHPの値から減算することで、大ボスm1のHPの値を更新してもよい。所定係数K1は、任意であり、可変値であってもよい。
【0097】
他方、小ボスm2が倒されことなく小ボスバトルパートが終了した場合(例えばユーザの第1ゲーム媒体m0が倒された場合や、途中で小ボスバトルパートが中断した場合等)、第1更新部1532は、大ボスm1のHPの値を更新しなくてもよい。あるいは、第1更新部1532は、そのときの小ボスm2のHPの減少分だけ、大ボスm1のHPの値から減算することで、大ボスm1のHPの値を更新してもよい。
【0098】
第1判定部1533は、第1更新部1532により更新されたHPの値が0になったか否かを判定する。第1判定部1533は、第1更新部1532により更新されたHPの値が0になったと判定すると、今回の大ボスバトルパートを終了させるための処理を指示する。なお、今回の大ボスバトルパートが最後の大ボスバトルパートである場合は、第1判定部1533は、今回のレイドゲームパートを終了させるための処理を指示する。
【0099】
ところで、本実施形態では、上述したように、第1更新部1532は、小ボスバトルパートが終了するごとに、大ボスm1に対応付けられるHPの値を更新するので、大ボスバトルパートが終了するタイミングは、一の小ボスバトルパートの終了タイミングに対応する。従って、ある一の小ボスバトルパートの終了に伴って大ボスバトルパートが終了する場合は、その時点で進行中でありうる他の小ボスバトルパートも強制的に終了される。この場合、大ボスm1が倒されたことにより他の小ボスバトルパートが終了されたことを表す情報が、当該他の小ボスバトルパートに対応付けられているユーザにわかるように、通知されてもよい。例えば、第1更新部1532により更新されたHPの値が0になった場合に小ボスバトルパートが1つ以上の端末装置20で進行されている場合、当該1つ以上の端末装置20におけるゲーム画像において小ボスm2が退散する様子が描画され、ついで、大ボスm1が敗北する様子が描画されてよい。あるいは、各端末装置20におけるゲーム画像において、大ボスm1が敗北する様子が割り込みにより描画されてもよい。また、大ボスm1に対応付けられるHPの値を0にするために必要とされる小ボスm2が設定される場合は、大ボスバトルパートが終了する時点で、当該大ボスに関連付けられた小ボスバトルパートもすべて終了していてもよい。
【0100】
小ボスバトル処理部154は、小ボスバトルパートに関連する各種処理を行う。例えば、小ボスバトル処理部154は、大ボスバトルパートの進行(及びそれに伴う1つ以上の小ボスバトルパートの進行)に基づいて、小ボスm2のHPの値を更新する。この際、小ボスバトル処理部154は、小ボスバトルパートごとに機能する。
【0101】
本実施形態では、小ボスバトルパートは、対応する小ボスm2のHPの値が、その初期値(第2初期値の一例)から第2所定値α2以上減少して0になると、小ボスm2が倒されることで終了する。第2所定値α2は、任意であるが、本実施形態では、一の小ボスm2(又は一の小ボスバトルパート)に係る第2所定値α2は、当該小ボスm2のHPの初期値である。この場合、小ボスバトルパートは、小ボスm2のHPの値が0になると終了する。ただし、変形例では、第2所定値α2は、小ボスm2のHPの初期値の所定割合(例えば90%)に対応する値であってもよい。この場合、一の子ボスバトルパートは、一旦、進行が開始されると、当該小ボスバトルパートに対応付けられる小ボスm2のHPの値が、その初期値に対して所定割合以上減少すると、小ボスm2が倒されることで終了する。
【0102】
また、本実施形態では、小ボスバトルパートは、他の終了条件が満たされた場合も終了してもよい。例えば、小ボスバトルパートは、ユーザの第1ゲーム媒体m0のHPの値が0になると、小ボスm2が倒されることなく終了してよい(すなわち小ボスm2が勝利)。ただし、この場合、同ユーザが再度、同小ボスバトルパートを最初から又は途中からプレイ(再挑戦)可能な仕様であってもよい。
【0103】
図9に示す例では、小ボスバトル処理部154は、第2設定部1541と、第2更新部1542と、第2判定部1543とを含む。
【0104】
第2設定部1541は、小ボスバトル設定部152により一の小ボスバトルパートが設定されると、当該一の小ボスバトルパートに小ボスm2を対応付ける。これにより、一の小ボスバトルパートに対応付けられている1人以上のユーザに、当該一の小ボスバトルパートに対応付けられた小ボスm2が、対応付けられることになる。換言すると、一のユーザに小ボスm2(又はそのHPの初期値)を対応付けることと、当該一のユーザに小ボスバトルパートに対応付けることとは、実質的に同義である。
【0105】
本実施形態では、第2設定部1541は、図8に示したボスキャラ情報に基づいて、一の大ボスバトルパートにおける小ボスバトルパートには、当該一の大ボスバトルパートに対応付けられる大ボスm1の分身である小ボスm2を対応付ける。これにより、大ボスm1と小ボスm2との関係(すなわち小ボスm2が大ボスm1の分身である関係)がユーザにとって分かりやすくなる。
【0106】
なお、上述したように、本実施形態では、各小ボスm2には、予めHPの初期値が対応付けられている(図8参照)。従って、第2設定部1541が、一の小ボスバトルパートに対応付けられる小ボスm2を設定すると、当該一の小ボスバトルパートには、当該小ボスm2のHPの初期値が対応付けられることになる。
【0107】
ここで、変形例では、第2設定部1541は、一の小ボスバトルパートに対応付けられる小ボスm2に関して、そのHPの初期値を適宜変更してもよい。例えば、第2設定部1541は、図8に示すようなボスキャラ情報で規定されるHPの初期値に対して、適宜増減した初期値を設定してもよい。この場合、当該小ボスm2に対応付けられた描画用情報は、変更されないので、見た目は影響せず、HPの初期値だけが変更される。なお、HPの初期値に代えて又は加えて、図8に示すようなボスキャラ情報で規定される攻撃力や回復力についても変更されてもよい。
【0108】
具体的には、第2設定部1541は、一の小ボスバトルパートが対応付けられる一人以上のユーザに係るユーザ情報に基づいて、当該一の小ボスバトルパートに対応付けられる小ボスm2のHPの初期値を設定してもよい。この場合、第2設定部1541は、一の小ボスバトルパートが対応付けられるユーザの第1ゲーム媒体のレベルやHPの初期値等が高いほど、小ボスm2のHPの初期値が高くなる態様で、小ボスm2のHPの初期値を設定してもよい。この場合、ユーザ情報に基づくユーザのレベル帯に応じてあらかじめ複数の小ボスm2のHPの初期値を設定しておき、レベルに応じた初期値を設定してもよい。これにより、各ユーザのレベルに応じたHPの初期値を有する小ボスm2を、各ユーザに対応付けられる小ボスバトルパートに対応付けることができる。
【0109】
また、第2設定部1541は、一の小ボスバトルパートに複数のユーザが対応付けられる場合は、一の小ボスバトルパートに一のユーザが対応付けられる場合よりも大きいHPの初期値を有する小ボスm2を、当該一の小ボスバトルパートに対応付けてもよい。第2設定部1541は、一の小ボスバトルパートに複数のユーザが対応付けられる場合は、それぞれのユーザに係るユーザ情報に基づいて、当該一の小ボスバトルパートに対応付けられる小ボスm2のHPの初期値を設定してもよい。この場合、第2設定部1541は、一の小ボスバトルパートが対応付けられる各ユーザの第1ゲーム媒体のレベルやHPの初期値等の平均値や合計値が高いほど、小ボスm2のHPの初期値が高くなる態様で、小ボスm2のHPの初期値を設定してもよい。これにより、複数のユーザのレベルに応じたHPの初期値を有する小ボスm2を、複数のユーザに対応付けられる各小ボスバトルパートに対応付けることができる。
【0110】
また、第2設定部1541は、一の小ボスバトルパートに対応付ける小ボスm2のHPの初期値を、当該小ボスm2に係る大ボスm1のHPの初期値に基づいて設定してもよい。例えば、一の大ボスm1の分身として機能する小ボスm2に対応付けられるHPの初期値は、当該一の大ボスm1に対応付けられるHPの初期値の、1/Mであってもよい。ここで、Mは、例えば1000以上の大きい数である。この場合、一の小ボスm2のHPの初期値は、当該一の小ボスm2に係る大ボスm1のHPの初期値が大きいほど大きくなる。これにより、大ボスm1の強さに応じた強さの小ボスm2を設定できるので、大ボスm1と小ボスm2との関係が、大ボスm1の強さに連動するという一貫性をもたせることができる。
【0111】
また、第2設定部1541は、一の小ボスバトルパートに対応付ける小ボスm2のHPの初期値を、当該小ボスm2に係る大ボスm1のHPの値(第1更新部1532により更新された値)に基づいて設定してもよい。例えば、第2設定部1541は、小ボスバトル設定部152により一の小ボスバトルパートが設定されると、大ボスm1のHPの値(現在値)を、第1更新部1532から取得する。そして、第2設定部1541は、大ボスm1のHPの値に基づいて、当該一の小ボスバトルパートに対応付けられる小ボスm2のHPの初期値を決定する。この際、例えば、第2設定部1541は、大ボスm1のHPの値が大きいほど小ボスm2のHPの初期値が大きくなる態様で、小ボスm2のHPの初期値を決定してもよい。これにより、そのときの大ボスm1のHPの値に応じたHPの初期値の小ボスm2を設定できるので、ゲーム状況に合わせた小ボスm2のHPの初期値を設定できる。
【0112】
また、第2設定部1541は、大ボス関連処理部153の処理負荷に応じて、小ボスm2のHPの初期値を変化させてもよい。例えば、小ボスm2のHPの初期値が大きいほど、小ボスバトルパートが終了する頻度が小さくなり、それ故に、大ボス関連処理部153の処理負荷が小さくなる傾向がある。従って、第2設定部1541は、大ボス関連処理部153の処理負荷が比較的高い場合に、小ボスm2のHPの初期値を増加させてもよい。なお、大ボス関連処理部153の処理負荷は、大ボス関連処理部153の稼働状態等に基づいて判断されてもよい。例えば、大ボス関連処理部153の処理負荷は、第1更新部1532による更新頻度に基づいて判断されてもよい。これは、第1更新部1532による更新頻度が高いほど、大ボス関連処理部153の処理負荷が高くなる傾向があるためである。
【0113】
ここで、一の大ボスバトルパートにおいて、大ボスm1のHPの初期値=第1所定値α1とし、小ボスm2のHPの初期値=第2所定値α2とし、小ボスバトル設定部152が小ボスバトルパートをN3個設定するとき、小ボスm2のHPの初期値の合計値=α2×N3である。このとき、所定の上限値をγとすると、大ボスm1を倒すことが可能となる場合、α1≦α2×N3≦γとなる。また、一の大ボスバトルパートあたりの小ボスバトルパートの数に対して、所定の上限数をM1とし、第2所定値α2を固定値とし、M2をα1≦M×α2を満たす最小の整数Mとしたとき、M2≦N3≦M1となる。この場合、M2個の小ボスバトルパートのすべてで小ボスm2が倒されると、当該一の大ボスバトルパートに係る大ボスm1が倒される。なお、このとき、N3-M個の小ボスバトルパートは、予備のゲームパートとなる。この場合、第2所定値α2を固定値としたとき、小ボスバトル設定部152は、第1所定値α1を第2所定値α2で割ることで得られる値よりも大きい数であって、所定の上限数M1を超えない数だけ、小ボスバトルパートを設定することになる。また、小ボスバトル設定部152は、一の大ボスバトルパートの進行中において、各ユーザに所定の上限数M3を超える数の小ボスバトルパートが対応付けられている状態が形成されないように、小ボスバトルパートを設定してもよい。この場合、所定の上限数M3は、上述した所定の上限数M1と同じであってもよいし、所定の上限数M1よりも小さくてもよい。
【0114】
第2更新部1542は、各小ボスバトルパートの進行に基づいて、各小ボスm2に対応付けられるHP(第2パラメータの一例)の値(残りの値)を更新する。第2更新部1542は、一の小ボスバトルパートにおいて、小ボスm2がユーザの第1ゲーム媒体m0からの攻撃を受けると、当該攻撃に応じたHPの値だけ、当該小ボスm2のHPの値から減算することで、当該小ボスm2のHPの値を更新する。このようにして、第2更新部1542は、ユーザの第1ゲーム媒体m0からの攻撃を受けるごとに、小ボスm2のHPの値を更新する。
【0115】
また、第2更新部1542は、回復条件が成立した場合に、適宜、小ボスm2のHPの値を増加させることで、当該小ボスm2のHPの値を更新してもよい。
【0116】
第2判定部1543は、第2更新部1542により更新されたHPの値が0になったか否かを判定する。第2判定部1543は、第2更新部1542により更新されたHPの値が0になったと判定すると、対応する小ボスバトルパートを終了させるための処理を指示する。この場合、対応する小ボスバトルパートが実行されている端末装置20におけるゲーム画像において、小ボスm2が敗北する様子が描画されてよい。
【0117】
ここで、一の小ボスバトルパートの進行に伴う小ボスバトル処理部154の動作について説明する。小ボスバトルパートが開始されると、小ボスバトル処理部154は、小ボスm2の行動ポイントを初期値(例えば、ゼロポイント)に定める。
【0118】
小ボスバトルパートの実行中、例えば、第1期間と第2期間とが交互に繰り返し発生する。
【0119】
第1期間は、例えば時間経過に応じて増加する小ボスm2の行動ポイントが、初期値(例えば、ゼロポイント)から上限値(例えば、100ポイント)まで増加する期間である。具体的には、小ボスバトル処理部154は、小ボスm2の行動ポイントを時間経過に応じて増加させる処理(増加処理)を開始する。増加処理の開始タイミングが、第1期間の開始タイミングに相当する。小ボスバトル処理部154は、小ボスm2の行動ポイントが上限値(例えば、100ポイント)に達すると、増加処理を終了する。増加処理の終了タイミングが、第1期間の終了タイミングに相当する。
【0120】
第2期間は、第1期間の終了タイミングから、小ボスm2の行動ポイントが初期値にリセットされるタイミングまでの期間である。具体的には、第2期間が開始した後、小ボスバトル処理部154は、小ボスm2に所定の行動(例えば、ユーザに対する攻撃)を実行させる。なお、第1ゲーム媒体に行動(例えば、小ボスm2に対する攻撃)を実行させない場合、小ボスバトル処理部154は、例えば第2期間の開始直後に、小ボスm2に所定の行動を実行させてもよい。一方、第1ゲーム媒体に行動を実行させる場合、小ボスバトル処理部154は、第1ゲーム媒体による行動の終了を待ってから、小ボスm2に所定の行動を実行させてもよい。かかる場合、第1ゲーム媒体による行動が終了した後に、小ボスm2による行動が実行される。このようにして、第1期間と第2期間とが交互に繰り返し発生する。
【0121】
なお、第1期間において、小ボスバトル処理部154は、仮想空間内に所定のアイテムを出現させてもよい。小ボスバトル処理部154は、第2ゲーム媒体によるアイテムの取得に応じて、第1ゲーム媒体の行動ポイントを増加させる。小ボスバトル処理部154は、第1ゲーム媒体の行動ポイントが所定の基準値以上である場合、当該第1ゲーム媒体に所定の行動(例えば、小ボスm2に対する攻撃)を実行させ、行動ポイントを当該基準値分だけ減少させる。小ボスバトル処理部154は、第1ゲーム媒体の行動ポイントが当該基準値未満となるまで、当該第1ゲーム媒体に行動を繰り返し実行させる。第1ゲーム媒体の行動ポイントが減少して当該基準値未満になると、第1ゲーム媒体による行動が終了する。
【0122】
なお、小ボスバトルパートの進行の仕方や終了の仕方等は、多様でありえ、任意である。例えば、小ボスm2が複数登場してもよい。この場合、一の小ボスバトルパートには、複数の小ボスm2のHPの初期値が割り当てられてよい。また、小ボスm2よりも前に子分キャラクタが登場してもよい。この場合、一の小ボスバトルパートには、子分キャラクタのHPの初期値が追加的に割り当てられてよい。また、小ボスバトルパートにおいては、複数の第1ゲーム媒体からなるデッキと小ボスm2とが対戦してもよい。また、後述する救援要請がある場合、小ボスバトルパートにおいては、複数のユーザに係る第1ゲーム媒体m0(又はそれらのデッキ)と小ボスm2とが対戦してもよい。また、小ボスバトルパートは、第2更新部1542により更新されたHPの値が0にならない場合でも、所定の終了条件が満たされた場合に、終了する仕様であってもよい。例えば、小ボスバトルパートは、ユーザの第1ゲーム媒体m0による攻撃回数(ターン数)が所定数に達した場合に、終了してもよい。また、小ボスバトルパートは、アクティブタイムバトル以外にも、リアルタイムバトル等により実現されてもよい。
【0123】
救援要請処理部155は、一のユーザ(端末装置20)から救援要請を受信した場合に、当該一のユーザに対応付けられている小ボスバトルパートに、救援用のユーザを対応付けるための救援処理を実行する。救援要請処理部155は、任意の態様で、救援用のユーザを選択してもよい。例えば、救援要請処理部155は、参加ステータスが「待機中」であるユーザ群から、救援用のユーザを選択してもよい。あるいは、救援要請処理部155は、参加ステータスが「待機中」でありかつフレンド関係にあるユーザ群から、救援用のユーザを選択してもよい。なお、参加ステータスが「待機中」であるユーザ群に代えて又は加えて、参加ステータスが「対戦中」や「退出中」であるユーザ群を含めてもよい。また、救援要請処理部155は、救援用のユーザを1人だけ選択してもよいし、複数同時に選択してもよい。
【0124】
救援要請処理部155は、救援用のユーザを選択すると、選択した救援用のユーザに対して、救援要請を送信する。救援要請を受けたユーザの端末装置20のゲーム画像には、承諾ボタンが表示されてよい。この場合、救援要請を受けたユーザは、承諾ボタンを押す等により、端末装置20を介して救援受諾をサーバ装置10に送信できる。なお、承諾ボタンには、対応する小ボスバトルパートの小ボスm2が描画されていてもよい。
【0125】
救援要請処理部155は、救援要請を送信した1人以上のユーザ(端末装置20)から救援受諾を受信すると、救援受諾を行ったユーザに、救援要請を出したユーザに対応付けられている小ボスバトルパートを対応付ける。
【0126】
ゲーム状態管理部156は、レイドゲームパートの進行に応じて、ゲーム状態を更新/管理する。ゲーム状態管理部156は、ゲーム状態が変化するごとに、ゲームデータ記憶部160内のゲームデータを更新する。
【0127】
図10には、ゲームデータ記憶部160内のゲームデータのうちの、ゲーム状態データ902の一例が示されている。ゲーム状態データ902は、図10に示すように、バトルIDごとに、小ボスm2のゲーム媒体ID、ゲームステータス、対応付けユーザID、参加属性、結果、減算HP、同時プレイの有無、等を対応付けることで、生成されてもよい。
【0128】
バトルIDは、個々の小ボスバトルパートを特定する識別子である。バトルIDは、小ボスバトル設定部152により小ボスバトルが設定されるごとに、設定される。なお、バトルIDは、予めサーバ記憶部12に記憶されてもよいし、あるいは、小ボスバトル設定部152により小ボスバトルが設定されるときに、サーバ装置10によって決定されてもよい。
【0129】
小ボスm2のゲーム媒体IDは、対応する小ボスバトルパートに対応付けられた小ボスm2のゲーム媒体IDである。ゲームステータスは、「進行中」、「終了」等を含んでよい。対応付けユーザIDは、対応する小ボスバトルパートに対応付けられたユーザのユーザIDである。参加属性は、対応するユーザの設定要求(後述する新規の設定要求)により設定された小ボスバトルパート(「ホスト」と表記)であるか、他のユーザからの救援要請に応じて対応付けられた小ボスバトルパート(「救援」と表記)であるか、他のユーザがホストとなる小ボスバトルパートへの自主的な参加(援護)であるか等、を表す。結果は、対応する小ボスバトルパートの結果である。減算HPは、対応する小ボスバトルパートにおいて小ボスm2のHPをどの程度減らしたかを表す。なお、一のユーザのみに対応付けられた小ボスバトルパートの場合、結果が“ユーザ勝利”であれば、減算HPは、当該小ボスバトルパートに対応付けられた小ボスm2のHPの初期値に対応する。
【0130】
同時プレイ検出部157は、2つ以上の小ボスバトルパートが対応付けられているユーザが存在するか否かを判定する。例えば、ゲーム状態管理部156は、ゲームデータ記憶部160内のゲームデータに基づいて、2つ以上の小ボスバトルパートが対応付けられているユーザが存在するか否かを判定できる。以下、このように、2つ以上の小ボスバトルパートが対応付けられているユーザを、「同時プレイユーザ」とも称する。同時プレイユーザには、上述したように、救援要請に対して救援受諾を行ったユーザがなりうる。なお、同時プレイユーザが発生しないゲーム仕様の場合は、同時プレイ検出部157は省略されてよい。
【0131】
画像生成部158は、各ユーザに係る端末装置20上に各種のゲーム画像を表示させるための表示用画像情報を生成する。
【0132】
図11は、小ボスバトルパートに係るゲーム画像の一例を示す図である。以下の図11(及び後出の図12)に関する説明において、小ボスm2とは、図11に示すゲーム画像に係る小ボスバトルパートに対応付けられている小ボスm2を指し、大ボスm1とは、当該小ボスm2に係る大ボスm1を指す。
【0133】
図11では、小ボスバトルパートに係るゲーム画像G1100は、ユーザの第1ゲーム媒体m0に係るHP表示(ゲージ)45と、小ボスm2に係るHP表示48とを含む。小ボスm2に係るHP表示48は、上述した第2更新部1542により小ボスm2のHPの値が更新されるごとに、更新される。なお、図11では、HP表示45には、ユーザの第1ゲーム媒体m0を表す画像部G11004が対応付けられ、HP表示48には、小ボスm2を表す画像部G11003が対応付けられる。
【0134】
また、図11では、小ボスバトルパートに係るゲーム画像G1100は、大ボスm1に対応付けられた描画用情報に基づき描画された画像部G11001と、ユーザの第1ゲーム媒体m0に対応付けられた描画用情報に基づき描画された画像部G11002とを含む。上述のように、本実施形態では、大ボスm1を描画するための描画用情報は、その分身である小ボスm2を描画するための描画用情報と同じである。換言すると、大ボスm1と、その分身である小ボスm2とは、ゲーム画像上、区別できない。これにより、ユーザには、小ボスm2と戦っているにもかかわらず、大ボスm1と戦っているイメージを持ってもらうことができる。
【0135】
図12は、小ボスバトルパートの終了に伴う大ボスm1のHPの値の更新を示すゲーム画像の一例を示す図である。
【0136】
図12では、大ボスm1のHPの値の更新を示すゲーム画像G1200は、大ボスm1に係るHP表示49を含む。HP表示49は、上述した第1更新部1532により大ボスm1のHPの値が更新されるごとに、更新される。なお、図12では、HP表示49には、大ボスm1を表す画像部G12001が対応付けられる。この場合、画像部G12001は、図11に示した画像部G11003よりも大きく描画されてもよい。HP表示49には、数値表示491が含められてもよい。これにより、大ボスm1のHPの値が一回の更新でわずかにしか減らない場合でも、わずかに減ったことをユーザに理解してもらうことができる。なお、数値表示491のオーダ(小数点何位までのかのオーダ)は、大ボスm1のHPの値の最小変化単位に応じて適宜設定されてよい。
【0137】
このようにして、本実施形態では、画像生成部158は、大ボスm1のHPの値が第1更新部1532により更新されるごとに、大ボスm1に係る画像(図12の画像部G12001参照)と、更新後の大ボスm1のHPの値を表す画像(図12のHP表示49参照)とを表示させるための表示用画像情報(第1表示用画像情報の一例)を生成する。この場合、各端末装置20は、当該表示用画像情報に基づいて、大ボスm1のHPの値が減らされたことを表す表示用画像(図12のゲーム画像G1200参照)を出力できる。
【0138】
また、画像生成部158は、小ボスm2のHPの値が第2更新部1542により更新されるごとに、大ボスm1に係る画像(図11の画像部G11001参照)と、更新後の小ボスm2のHPの値を表す画像(図11のHP表示48)とを表示させるための表示用画像情報(第2表示用画像情報の一例)を生成する。この場合、各端末装置20は、当該表示用画像情報に基づいて、小ボスm2のHPの値が減らされたことを表す表示用画像(図11のゲーム画像G1100参照)を出力できる。
【0139】
このようにして、本実施形態では、画像生成部158は、小ボスm2のHPの値が第2更新部1542により更新されるごとに、図11のようなゲーム画像G1100を表示させるための表示用画像情報を生成する。そして、第2更新部1542により更新された小ボスm2のHPの値が0に至ると(すなわち小ボスm2が倒されると)、小ボスm2の敗北シーンが描画されるように表示用画像情報を生成する。この場合、対応する端末装置20は、当該表示用画像情報に基づいて、小ボスm2が倒されたことを表す表示用画像(図示せず)を出力できる。
【0140】
ここで、小ボスm2の敗北シーンと、大ボスm1の敗北シーンとで、倒されたゲーム媒体を同じ描画態様で描画すると、ユーザに混乱を生む可能性がある。従って、小ボスm2の敗北シーンでは、大ボスm1の“分身”である小ボスm2が倒されたことがわかりやすくなるように、大ボスm1を描画するための描画用情報に基づき描画されるゲーム媒体は、比較的小さいサイズで描画されてもよい。換言すると、大ボスm1を描画するための描画用情報に基づきゲーム媒体を比較的小さいサイズで描画することで、“小ボスm2”を描画してもよい。このようにして、所定の場合に、画像生成部158は、大ボスm1のHPの値に対応付けて大ボスm1に係るゲーム媒体を表示するときと、小ボスm2のHPの値に対応付けて小ボスm2に係るゲーム媒体を表示するときとで、異なる態様で対戦相手が描画されるように表示用画像情報を生成してもよい。なお、異なる態様は、サイズに代えて又は加えて、詳細な部分の描画が異なってもよい。
【0141】
また、本実施形態では、画像生成部158は、大ボスm1のHPの値が第1更新部1532により更新されるごとに、図12のようなゲーム画像G1200を表示させるための表示用画像情報を生成する。そして、第1更新部1532により更新された大ボスm1のHPの値が0に至ると(すなわち大ボスm1が倒されると)、大ボスm1の敗北シーンが描画されるように表示用画像情報を生成する。この場合、各端末装置20は、当該表示用画像情報に基づいて、大ボスm1が倒されたことを表す表示用画像(図示せず)を出力できる。
【0142】
ここで、上述したように、小ボスm2の敗北シーンと、大ボスm1の敗北シートとで、倒されたゲーム媒体を同じ描画態様で描画すると、ユーザに混乱を生む可能性がある。従って、大ボスm1の敗北シーンでは、大ボスm1の“分身”である小ボスm2が倒されたときの敗北シートに対する相違がわかりやすくなるように、大ボスm1を描画するための描画用情報に基づき描画されるゲーム媒体は、比較的大きいサイズで描画されてもよい。換言すると、大ボスm1を描画するための描画用情報に基づきゲーム媒体を比較的大きいサイズで描画することで、“大ボスm1”を描画してもよい。
【0143】
なお、画像生成部158は、同時プレイ検出部157におり、2つ以上の小ボスバトルパートが対応付けられているユーザが存在すると判定された場合、当該ユーザが、2つ以上の小ボスバトルパートのうちの、いずれか1つだけを選択できるような選択画像を含むゲーム画像を端末装置20上に表示させるための表示用画像情報を生成してよい。この場合、ユーザは、例えば救援要請を受けた方の小ボスバトルパートを優先的にプレイする等、所望の選択を行うことができる。あるいは、ユーザは、自動モード等を利用することで、2つ以上の小ボスバトルパートを並列的に進行させることが可能であってもよい。これらの場合、第2更新部1542は、2つ以上の小ボスバトルパートが対応付けられているユーザからの入力(例えば、手動や自動による操作入力)に基づいて、2つ以上の小ボスm2のHPのそれぞれ又は一部の値を更新することになる。
【0144】
なお、上述したように、図9に示しかつ上述したサーバ装置10の機能の一部又は全部は、適宜、端末装置20により実現されてもよい。例えば、端末装置20に表示されるゲーム画像(図11図12に示すようなゲーム画像)の少なくとも一部を、サーバ装置10が生成したデータに基づいて端末装置20に表示させるウェブ表示とし、ゲーム画像の少なくとも一部を、端末装置20にインストールされているネイティブアプリケーションによって表示させるネイティブ表示としてもよい。
【0145】
報酬付与部159は、レイドゲームパートに参加した各ユーザに報酬を付与する。報酬の付与方法は任意である。例えば、報酬付与部159は、小ボスバトルパートごとに、小ボスm2を倒した1人以上のユーザに特定の報酬を付与してもよいし、及び/又は、大ボスバトルパートごとに、大ボスm1を倒すことに貢献した各ユーザに特定の報酬を付与してもよい。また、報酬付与部159は、大ボスm1を倒した際の小ボスバトルパートをプレイした1人以上のユーザ(すなわち、大ボスm1に最後の一撃を加えた1人以上のユーザ)に、特別な報酬を付与してもよい。また、報酬付与部159は、レイドゲームパートが終了した後に、参加状況データ900(図10参照)等に基づいて、ランキング情報を生成してもよい。この場合、ランキング情報は、倒した小ボスm2の数(討伐数)が多い順にユーザIDがランキングされる態様で、生成されてもよい。
【0146】
ところで、本実施形態では、上述したように、第1更新部1532は、第2更新部1542により更新された小ボスm2のHPの値に基づいて、第2更新部1542よりも少ない更新頻度で大ボスm1のHPの値を更新する。これにより、参加ステータスが“対戦中”であるユーザの数が膨大である場合でも、第1更新部1532の処理負荷を低減できる。他方、参加ステータスが“対戦中”であるユーザの数が膨大となると、第2更新部1542の全体としての処理負荷は増加する。
【0147】
この点、本実施形態では、第2更新部1542は、小ボスバトルパートごとに独立して動作できるので、複数のサーバコンピュータ及び/又は複数のCPUにより分散して実現することが容易である。この場合、第2更新部1542を実現するための処理部が、限られたハードウェアリソースに限定されてしまうことをなく、処理負荷を適切に分散できる。あるいは、第2更新部1542は、小ボスバトルパートごとに独立して動作できるので、端末装置20により実現されてもよい。この場合も、第2更新部1542を実現するための処理部が、限られたハードウェアリソースに限定されてしまうことなく、処理負荷を適切に分散できる。このようにして、第2更新部1542は、第1更新部1532よりも多い数のコンピュータにより実現することができるので、処理負荷を適切に分散できる。
【0148】
次に、図13以降を参照して、サーバ装置10におけるレイドゲームパートに関連した構成の動作例について説明する。
【0149】
図13は、各ユーザからの小ボスバトルパートの設定要求に係る処理の一例を示す概略的なフローチャートである。
【0150】
ステップS1102では、サーバ装置10は、小ボスバトルパートに係るロビー画像の生成要求をいずれかの端末装置20(すなわちいずれかのユーザ)から受信したか否かを判定する。判定結果が“YES”の場合、ステップS1306に進み、それ以外の場合は、今回周期の処理をそのまま終了する。
【0151】
ステップS1104では、サーバ装置10は、ユーザがいくつかの小ボスバトルパートの中からプレイする小ボスバトルパートを選択するための選択用画像の生成処理(以下、「選択用画像生成処理」とも称する)を行う。すなわち、サーバ装置10は、1つ以上の小ボスバトルパートのうちから、一の小ボスバトルパートをユーザが選択できるユーザインターフェース(選択用画像)(図示せず)を生成する。当該ユーザインターフェースは、今回受信したロビー画像の生成要求に係る要求元のユーザ(以下、単に「要求元のユーザ」とも称する)に係る端末装置20に表示され、選択可能な1つ以上の小ボスバトルパートを表す選択ボタンを含んでよい。選択ボタンは、対応する小ボスバトルパートに係る情報(例えば現在のプレイ中のユーザ情報)等を含んでよい。ユーザが所望の選択ボタンを操作すると、対応する小ボスバトルパートに対する設定要求がサーバ装置10に送信される。以下では、一例として、設定要求は、要求元のユーザ(自身)をホストとした新規の小ボスバトルパートの設定を要求する設定要求(以下、「新規の設定要求」とも称する)と、既に他のユーザをホストとして設定済の小ボスバトルパートへの参加を要求する設定要求(以下、「参加型の設定要求」とも称する)とを含むものとする。なお、変形例では、新規の設定要求は、他のユーザ(所定関係を有するユーザ)とともにグループに対する小ボスバトルパートの設定を要求する設定要求を含んでもよい。
【0152】
ステップS1106では、サーバ装置10は、ユーザによる選択ボタンの操作(すなわちユーザによる小ボスバトルパートの選択)があったか否かを判定する。判定結果が“YES”の場合、ステップS1108に進み、それ以外の場合は、ユーザによる選択ボタンの操作待ち状態となる。なお、当該操作待ち状態は、例えば一定の時間が経過した場合や、選択可能な1つ以上の小ボスバトルパートのうちのいずれかが終了した場合等、適宜終了する。また、操作待ち状態において、ステップS1104が定期的に実行されてよい。
【0153】
ステップS1108では、サーバ装置10は、今回のユーザによる選択ボタンの操作により受信した設定要求(新規の設定要求又は参加型の設定要求)を、処理待ちのキューに設定する。このようにして、処理待ちのキューに設定された設定要求(新規の設定要求又は参加型の設定要求)は、後述する小ボスバトルパートにおける減算指示生成処理(図15)において処理される(ステップS1304やステップS1327A等参照)。
【0154】
図14Aは、図13の選択用画像生成処理(ステップS1104)の処理の一例を示す概略的なフローチャートである。
【0155】
ステップS1200では、サーバ装置10は、ゲームデータ記憶部160内のゲームデータ(図10のゲーム状態データ902参照)に基づいて、ゲームステータスが“進行中”であるバトルIDを抽出する。
【0156】
ステップS1202では、サーバ装置10は、要求元のユーザと所定関係を有するユーザIDを抽出する。例えば、サーバ装置10は、ユーザ情報に含まれるフレンド情報に基づいて、要求元のユーザとフレンド関係にあるユーザのユーザIDを抽出する。
【0157】
ステップS1204では、サーバ装置10は、ステップS1200で抽出した各バトルIDに対応付けられているユーザID(図10のゲーム状態データ902の対応付けユーザID参照)の中に、ステップS1202で抽出したユーザIDが含まれているか否かを判定する。すなわち、サーバ装置10は、ステップS1200で抽出した各バトルIDに係る小ボスバトルパートの中に、要求元のユーザと所定関係を有するユーザ(例えばフレンド関係にあるユーザ)がプレイしている小ボスバトルパートが存在するか否かを判定する。判定結果が“YES”の場合、ステップS1206に進み、それ以外の場合は、ステップS1208に進む。
【0158】
ステップS1206では、サーバ装置10は、要求元のユーザとフレンド関係にあるユーザがプレイしている1つ以上の小ボスバトルパートと、新たな小ボスバトルパートのうちから、いずれか1つをプレイ対象の小ボスバトルパートとして要求元のユーザが選択できる選択用画像を生成する。なお、この場合、サーバ装置10は、ゲーム状態に基づいて、選択用画像における1つ以上の小ボスバトルパートに係る選択ボタンの配置を適宜設定してもよい。例えば、サーバ装置10は、要求元のユーザとフレンド関係にあるユーザがプレイしている1つ以上の小ボスバトルパートのうちの、小ボスm2のHPの値が大きい順(又は小さい順)、第1ゲーム媒体m0側のHPの値の小さい順(又は大きい順)、又は、小ボスバトルパートの持続時間が長い順(又は短い順)に、優先的に選択されやすいような配置で、1つ以上の小ボスバトルパートに係る選択ボタンの配置を設定してもよい。なお、変形例では、要求元のユーザと所定関係にあるユーザがプレイしている1つ以上の小ボスバトルパートに代えて又は加えて、他の条件を満たす小ボスバトルパートが抽出(選択用画像に配置)されてもよい。
【0159】
ステップS1208では、サーバ装置10は、新たな小ボスバトルパートをプレイ対象の小ボスバトルパートとして要求元のユーザが選択できる選択用画像を生成する。
【0160】
ステップS1220では、サーバ装置10は、ステップS1206又はステップS1208で生成した選択用画像を要求元のユーザの端末装置20に表示させる。
【0161】
このようにして図14Aに示す処理によれば、要求元のユーザは、所定関係を有するユーザがプレイ中である小ボスバトルパートか、自身がホストとなり新たに設定する小ボスバトルパートかを、選択してプレイできる。また、サーバ装置10に次々に設定要求が送信されてくる場合に各ユーザを適応的に分散させることになるため、小ボスm2ごとの処理(第2更新部1542を実現するための処理部)の負荷を均すことができる。
【0162】
図14Bは、図13の選択用画像生成処理(ステップS1104)の処理の他の一例を示す概略的なフローチャートである。
【0163】
図14Bに示す処理は、図14Aに示した処理に対して、ステップS1204で判定結果が“YES”である場合にステップS1210が実行される点が異なる。以下では、異なる点を主に説明する。
【0164】
ステップS1210では、サーバ装置10は、要求元のユーザとフレンド関係にあるユーザがプレイしている1つ以上の小ボスバトルパートの数が、一定数を超えるか否かを判定する。一定数は、任意であるが、ユーザへ提示する選択候補として適切な数の上限値に対応してよい。判定結果が“YES”の場合、ステップS1212に進み、それ以外の場合は、ステップS1216に進む。なお、変形例では、要求元のユーザと所定関係にあるユーザがプレイしている1つ以上の小ボスバトルパートに代えて又は加えて、他の条件を満たす小ボスバトルパートが抽出されてもよい。この場合、サーバ装置10は、これらを含む抽出されたすべての小ボスバトルパートの数が、一定数を超えるか否かを判定してよい。
【0165】
ステップS1212では、サーバ装置10は、要求元のユーザとフレンド関係にあるユーザがプレイしている1つ以上の小ボスバトルパートのうちから、一定数の小ボスバトルパートだけを抽出する。
【0166】
この場合の抽出方法は、任意であるが、ゲーム状態が考慮されてもよい。例えば、サーバ装置10は、要求元のユーザとフレンド関係にあるユーザがプレイしている1つ以上の小ボスバトルパートのうちの、小ボスm2のHPの値が大きい順(又は小さい順)、第1ゲーム媒体m0側のHPの値の小さい順(又は大きい順)、小ボスバトルパートの持続時間が長い順(又は短い順)、他のユーザの参加人数が多い順(又は少ない順)、又は、他のユーザのレベル帯(例えば、ユーザ情報に基づくユーザのレベル帯)が高い順(又は低い順)に、若しくは、これらの2つ以上の組み合わせによる順序に従って、一定数の小ボスバトルパートを抽出してもよい。
【0167】
ステップS1214では、サーバ装置10は、ステップS1212で抽出した一定数の小ボスバトルパートと、新たな小ボスバトルパートのうちから、いずれか1つを要求元のユーザが選択できる選択用画像を生成する。
【0168】
ステップS1216では、サーバ装置10は、要求元のユーザとフレンド関係にあるユーザがプレイしている1つ以上の小ボスバトルパート(一定数以下のすべて)と、新たな小ボスバトルパートのうちから、いずれか1つをプレイ対象の小ボスバトルパートとして要求元のユーザが選択できる選択用画像を生成する。
【0169】
このようにして図14Bに示す処理によれば、所定関係を有するユーザがプレイ中である小ボスバトルパートの数が比較的多い場合には、抽出した一定数の小ボスバトルパートだけを、選択対象の小ボスバトルパートとして要求元のユーザに提示できる。
【0170】
また、図14Bに示す処理によれば、ゲーム状態に応じて、要求元のユーザに提示する一定数の小ボスバトルパートを抽出するので、処理不可の平均化を図ることも可能である。例えば、適宜、小ボスへの参加人数を偏らせたりすることにより、特定の小ボスが早く倒されやすくすることにより、各小ボスの倒されるであろうタイミングをずらすことで、大ボスm1のHPの値の更新タイミングをずらし、一時的な処理負荷の増大を防ぐことができる。
【0171】
図15は、小ボスバトルパートにおける減算指示生成処理の一例を示す概略的なフローチャートである。図15に示す処理は、レイドゲームパートの進行中、所定周期ごとに繰り返し実行されてよい。
【0172】
ステップS1302では、サーバ装置10は、新たな小ボスバトルパートの設定状態を示す第1フラグF1が“0”であるか否かを判定する。第1フラグF1が“0”である場合は、新たな小ボスバトルパートの設定待ち状態に対応し、第1フラグF1が“1”である場合は、新たな小ボスバトルパートの設定済状態に対応する。第1フラグF1は、小ボスバトルパートごと(すなわちバトルIDごと)に設定される。判定結果が“YES”の場合、ステップS1304に進み、それ以外の場合は、ステップS1312に進む。
【0173】
ステップS1304では、サーバ装置10は、小ボスバトルパートに係る新規の設定要求をいずれかの端末装置20(すなわちいずれかのユーザ)から受信したか否かを判定する。例えば、サーバ装置10は、新規の設定要求が処理待ちのキュー(図13のステップS1108参照)に存在するか否かを判定する。判定結果が“YES”の場合、ステップS1306に進み、それ以外の場合は、今回周期の処理をそのまま終了する。
【0174】
ステップS1306では、サーバ装置10は、ステップS1304で得た設定要求に応答して、今回のユーザ(今回の新規の設定要求を行ったユーザ)をホストとして、当該ユーザに対応付ける新たな小ボスバトルパートを設定する。なお、この場合、今回のユーザの参加ステータスは、“対戦中”に変更(更新)される。
【0175】
ステップS1308では、サーバ装置10は、第1フラグF1を“1”にセットする。
【0176】
ステップS1310では、サーバ装置10は、小ボスバトルパートに小ボスm2を対応付けて、当該小ボスバトルパートを開始する。
【0177】
ステップS1312では、サーバ装置10は、小ボスm2のHPの値の更新条件が満たされたか否かを判定する。小ボスm2のHPの値の更新条件は、例えば小ボスm2がユーザの第1ゲーム媒体m0から攻撃を受けた場合等に満たされる。判定結果が“YES”の場合、ステップS1314に進み、それ以外の場合は、ステップS1316に進む。
【0178】
ステップS1314では、サーバ装置10は、小ボスm2のHPの値を更新する。
【0179】
ステップS1316では、サーバ装置10は、ユーザの第1ゲーム媒体m0のHPの値の更新条件が満たされたか否かを判定する。ユーザの第1ゲーム媒体m0のHPの値の更新条件は、例えユーザの第1ゲーム媒体m0が小ボスm2から攻撃を受けた場合等に満たされる。判定結果が“YES”の場合、ステップS1318に進み、それ以外の場合は、ステップS1320に進む。
【0180】
ステップS1318では、サーバ装置10は、ユーザの第1ゲーム媒体m0のHPの値を更新する。
【0181】
ステップS1320では、サーバ装置10は、今回のユーザから救援要請を受信したか否かを判定する。判定結果が“YES”の場合、ステップS1322に進み、それ以外の場合は、ステップS1323に進む。
【0182】
ステップS1322では、サーバ装置10は、救援要請を他のユーザに送信し、救援待ちタイマをセットする。救援待ちタイマは、所定時間ΔT1でタイムアウトするタイマである。
【0183】
ステップS1323では、サーバ装置10は、救援待ちタイマが計時中であるか否かを判定する。なお、救援待ちタイマは、計時開始から所定時間ΔT1が経過すると、タイムアウトして計時を終了する。判定結果が“YES”の場合、ステップS1324に進み、それ以外の場合(救援待ちタイマがタイムアウトしている場合、又は、救援待ちタイマが起動していない場合)は、ステップS1327Aに進む。
【0184】
ステップS1324では、サーバ装置10は、救援要請に対する救援受諾を受信したか否かを判定する。判定結果が“YES”の場合、ステップS1326に進む。他方、判定結果が“NO”の場合は、ステップS1322と同様、今回周期の処理をそのまま終了する。この場合、所定時間ΔT1だけ、救援要請に対する救援受諾の受信待ち状態となる。
【0185】
ステップS1326では、サーバ装置10は、救援受諾を行った新たなユーザを、今回の小ボスバトルパートに対応付ける。すなわち、今回の小ボスバトルパートに対応付けられるユーザ群に、救援受諾を行った新たなユーザを追加する。この際、ゲームデータ記憶部160内のゲームデータ(図10参照)が更新される。なお、この場合、救援受諾を行った新たなユーザの参加ステータスは、“対戦中”に変更(更新)され、また、参加ステータスは“救援”とされてよい。
【0186】
ステップS1327Aでは、サーバ装置10は、小ボスバトルパートに係る設定要求であって、今回の小ボスバトルパートに対する参加型の設定要求をいずれかの端末装置20(すなわちいずれかのユーザ)から受信したか否かを判定する。例えば、サーバ装置10は、参加型の設定要求が処理待ちのキュー(図13のステップS1108参照)に存在するか否かを判定する。判定結果が“YES”の場合、ステップS1327Bに進み、それ以外の場合は、ステップS1328に進む。
【0187】
ステップS1327Bでは、サーバ装置10は、参加型の設定要求を行った新たなユーザを、今回の小ボスバトルパートに対応付ける。すなわち、今回の小ボスバトルパートに対応付けられるユーザ群に、参加型の設定要求を行った新たなユーザを追加する。この際、ゲームデータ記憶部160内のゲームデータ(図10参照)が更新される。なお、この場合、参加型の設定要求を行った新たなユーザの参加ステータスは、“対戦中”に変更(更新)され、また、参加ステータスは“援護”とされてよい。
【0188】
ステップS1328では、サーバ装置10は、小ボスバトルパートの終了条件が満たされたか否かを判定する。小ボスバトルパートの終了条件は、例えば、小ボスm2のHPの値及びユーザの第1ゲーム媒体m0のHPの値のいずれかが0となった場合等に満たされる。判定結果が“YES”の場合、ステップS1332に進み、それ以外の場合は、ステップS1330に進む。
【0189】
ステップS1330では、サーバ装置10は、小ボスバトルパートを進行させて、今回周期の処理を終了する。
【0190】
ステップS1332では、サーバ装置10は、第1フラグF1を“0”にセットし、今回の小ボスバトルパートを終了させる処理を開始する。なお、この場合、今回のユーザの参加ステータスが“待機中”に変更(更新)される態様で、参加状況データ900等が更新される。
【0191】
ステップS1334では、サーバ装置10は、今回の小ボスバトルパートの結果として、小ボスm2が倒されたか否かを判定する。すなわち、小ボスm2の討伐が成功したか否かを判定する。判定結果が“YES”の場合、ステップS1336に進み、それ以外の場合は、ステップS1340に進む。
【0192】
ステップS1336では、サーバ装置10は、小ボスm2のHPの初期値だけ、大ボスm1のHPを減算させるためのHP減算指示を生成する。なお、小ボスm2のHPの初期値が固定である場合は、HP減算指示は、減算量(小ボスm2のHPの初期値)の情報を含まなくてもよい。
【0193】
ステップS1338では、サーバ装置10は、小ボスm2の敗北シーンが描画される終了画像を含むゲーム画像が、対応するユーザ(今回の小ボスバトルパートに対応付けられている1人以上のユーザ)の端末装置20で表示されるように表示用画像情報を生成する。また、この場合、終了画像は、小ボスm2が敗北する(討伐される)ことで、大ボスm1のHPの値が更新される様子が描画されてよい。
【0194】
ステップS1340では、サーバ装置10は、小ボスm2の勝利シーンが描画される終了画像を含むゲーム画像が、対応するユーザの端末装置20で表示されるように表示用画像情報を生成する。
【0195】
このような図15に示す処理は、小ボスバトルパートが設定されると、小ボスバトルパートごとに実行される。従って、複数の小ボスバトルパートが連続して設定されると、図15に示す処理は、小ボスバトルパートごとに並列して実行される。そして、各小ボスバトルパートに係る図15に示す処理は、小ボスm2が倒されて小ボスバトルパートが終了する場合は、HP減算指示を生成(ステップS1336)して終了する。従って、HP減算指示は、ランダムなタイミングで生成されうる。
【0196】
図16は、図15に示した減算指示生成処理と並列に実行されるHP減算処理であって、大ボスバトルパートにおけるHP減算処理の一例を示す概略的なフローチャートである。図16に示す処理は、レイドゲームパートの進行中、所定周期ごとに繰り返し実行されてよい。
【0197】
ステップS1402では、サーバ装置10は、新たな大ボスバトルパートの進行状態を示す第2フラグF2が“0”であるか否かを判定する。第2フラグF2が“0”である場合は、新たな大ボスバトルパートの開始待ち状態に対応し、第2フラグF2が“1”である場合は、新たな大ボスバトルパートの進行中状態に対応する。判定結果が“YES”の場合、ステップS1404に進み、それ以外の場合は、ステップS1412に進む。
【0198】
ステップS1404では、サーバ装置10は、新たな大ボスバトルパートの開始条件が満たされたか否かを判定する。新たな大ボスバトルパートの開始条件は、任意である。例えば、1つ目の大ボスバトルパートの開始条件は、所定時刻になった場合に満たされてよい。2つ目以降の大ボスバトルパートの開始条件は、前の大ボスバトルパートが終了してから所定時間ΔT2が経過した場合に満たされてよい。判定結果が“YES”の場合、ステップS1406に進み、それ以外の場合は、今回周期の処理をそのまま終了する。
【0199】
ステップS1406では、サーバ装置10は、第2フラグF2を“1”にセットする。
【0200】
ステップS1408では、サーバ装置10は、新たな大ボスバトルパートに大ボスm1を対応付けて、当該大ボスバトルパートを開始する。
【0201】
ステップS1410では、サーバ装置10は、ユーザからの設定要求(小ボスバトルパートに係る設定要求)の受け付けを開始するゲーム画像が各端末装置20で表示されるように表示用画像情報を生成する。
【0202】
ステップS1412では、サーバ装置10は、図15に示した減算指示生成処理によりHP減算指示(ステップS1336)が生成されたか否かを判定する。判定結果が“YES”の場合、ステップS1414に進み、それ以外の場合は、今回周期の処理を終了する。
【0203】
ステップS1414では、サーバ装置10は、大ボスm1のHPの値を更新する。すなわち、サーバ装置10は、HP減算指示に含まれる減算量(小ボスm2のHPの初期値)だけ、大ボスm1のHPの値を減らすことで、大ボスm1のHPの値を更新する。
【0204】
ステップS1416では、サーバ装置10は、今回の大ボスバトルパートの終了条件が満たされたか否かを判定する。大ボスバトルパートの終了条件は、例えば、大ボスm1のHPの値が0となった場合や、今回の大ボスバトルパートの持続時間が所定時間ΔT3を超えた場合等に満たされる。判定結果が“YES”の場合、ステップS1418に進み、それ以外の場合は、今回周期の処理をそのまま終了する。
【0205】
ステップS1418では、サーバ装置10は、第2フラグF2を“0”にセットし、今回の大ボスバトルパートを終了させる処理を開始する。この場合、現在進行中の小ボスバトルパート(小ボスm2のHPの値が0より大きい状態の小ボスバトルパート)が存在する場合は、当該小ボスバトルパートを終了させる指示を生成する。
【0206】
ステップS1420では、サーバ装置10は、大ボスm1の敗北シーンが描画される終了画像を含むゲーム画像が、各ユーザ(例えば、参加ステータスが「退出中」以外の各ユーザ)の端末装置20で表示されるように表示用画像情報を生成する。
【0207】
ステップS1422では、サーバ装置10は、今回の大ボスバトルパートが、今回のレイドゲームパートの最後の大ボスバトルパートであるか否かを判定する。すなわち、今回のレイドゲームパートに対応付けられた大ボスm1が、最後の大ボスm1(いわゆる「ラスボス」)であるか否かを判定する。判定結果が“YES”の場合、ステップS1424に進み、それ以外の場合は、今回周期の処理をそのまま終了する。
【0208】
ステップS1424では、サーバ装置10は、今回のレイドゲームパートを終了させる。この場合、サーバ装置10は、レイドゲームパートの終了画像を含むゲーム画像が、各ユーザ(例えば、参加ステータスが「待機中」及び「退出中」のすべてのユーザ)の端末装置20で表示されるように表示用画像情報を生成してよい。
【0209】
このような図16に示す処理は、図15に示した減算指示生成処理によりHP減算指示が生成された場合(ステップS1412の“YES”)のみ、ステップS1414以降の実質的な処理を行うので、処理負荷を低減できる。すなわち、図16に示す処理は、図15に示した減算指示生成処理によるHP減算指示の生成状況を監視しつつ、HP減算指示が生成された場合(ステップS1412の“YES”)のみ、ステップS1414以降の実質的な処理を行うことができる。これにより、上述したように、膨大なユーザがレイドゲームパートに参加するような状況下においても、大ボスm1のHPの値の更新頻度を低減して、処理負荷を低減できる。
【0210】
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【0211】
例えば、上述した実施形態では、一の小ボスバトルパートに対して一の小ボスm2が対応付けられているが、一の小ボスバトルパートに対して複数の小ボスm2が対応付けられてもよい。この場合、当該一の小ボスバトルパートが、当該複数の小ボスm2が倒されて終了すると、複数の小ボスm2のそれぞれのHPの初期値の合計が、大ボスm1のHPの値から減算されることで、大ボスm1のHPの値が更新されてよい。
【0212】
また、上述した実施形態では、大ボスm1に第1パラメータとしてHPを対応付け、小ボスm2に第2パラメータとしてHPを対応付け、小ボスm2のHPの値が第2所定値α2以上減るごとに、大ボスm1のHPの値を減らしているが、これに限られない。例えば、第1パラメータ及び/又は第2パラメータは、HP以外のパラメータであってよい。具体的には、第1パラメータ及び第2パラメータは、所定の領域を制圧する際の制圧量であってもよい。この場合、小領域が“小ボス”と同様の態様で設定されてよく、小領域が制圧されるごとに、より大きい大領域(“大ボス”)の制圧が進む態様でゲームが進行されてもよい。また、第1パラメータ及び第2パラメータは、ポイントや点数であってもよい。この場合、ポイントや点数の獲得状況は、ユーザごとに更新されるが、全体の獲得ポイントや点数は、ユーザごとのポイントや点数の獲得が所定量(第2所定値α2に対応)以上となるごとに、更新されてもよい。
【0213】
また、大ボスm1に第1パラメータとしてHPを対応付け、小ボスm2に、ポイントなどのHP以外の第2パラメータを対応付け、小ボスm2に係る第2パラメータの値が第2所定値α2以上減るごとに、大ボスm1のHPの値を減らしてもよい。あるいは、大ボスm1と小ボスm2との関係と同様に、小ボスm2に対して1つ以上の孫ボスが設定されてもよく、一の小ボスm2に対応付けられたすべての孫ボスが倒されると、小ボスm2が倒される仕様とされてもよい。
【0214】
また、上述した実施形態では、小ボスバトルパートに小ボスm2を対応付けているが、小ボスm2の概念を無くし、小ボスバトルパートに大ボスm1を対応付けてもよい。この場合、第2パラメータとして、第1ゲーム媒体m0から大ボスm1への攻撃に応じて増加するポイントが設定され、ポイントが第2所定値α2以上変化した場合だけ、当該ポイントの変化分だけ大ボスm1のHPの値が減算されてもよい。なお、小ボスm2の概念を無くす構成は、これに限定されることなく、上述した各種の実施形態やその変形例においても、小ボスm2の概念が存在しない構成を実現できる。例えば、小領域が“小ボス”と同様の態様で設定され、小領域が制圧されるごとに、より大きい大領域(“大ボス”)の制圧が進む構成に関しては、小領域が存在せず、第2パラメータとして、制圧量に応じて増加するポイントが設定され、ポイントが第2所定値α2以上変化した場合だけ、当該ポイントの変化分だけ大領域の制圧状態が更新されてもよい。
【0215】
上記の実施例に関連して、以下に付記を示す。
[付記1]
複数のユーザと特定の対戦相手との間の対戦ゲームパートを設定するゲームパート設定部と、
前記対戦ゲームパートの進行に基づいて、前記特定の対戦相手に対応付けられる第1パラメータの値を更新する第1更新部と、
前記対戦ゲームパートの進行に基づいて、前記特定の対戦相手に対応付けられる第2パラメータの値を更新する第2更新部と、を備え、
前記第1更新部は、前記第2更新部により更新された前記第2パラメータの値に基づいて、前記第2更新部よりも少ない更新頻度で前記第1パラメータの値を更新する、情報処理システム。
[付記2]
前記第1パラメータの初期値である第1初期値と、固定値又は可変値である第1所定値とを設定する第1設定部と、
前記第2パラメータの初期値である第2初期値と、前記第1所定値よりも小さい固定値又は可変値である第2所定値とを設定する第2設定部と、
前記第1更新部により更新された前記第1パラメータの値が前記第1初期値に対して前記第1所定値以上変化したか否かを判定する第1判定部と、
前記第2更新部により更新された前記第2パラメータの値が前記第2初期値に対して前記第2所定値以上変化したか否かを判定する第2判定部とを、更に備え、
前記第1更新部は、前記第2判定部により前記第2パラメータの値が前記第2初期値に対して前記第2所定値以上変化したと判定された場合に、前記第2所定値に応じた値だけ前記第1パラメータの値を変化させることで、前記第1パラメータの値を更新する、付記1に記載の情報処理システム。
[付記3]
前記ゲームパート設定部は、前記第1判定部により前記第1パラメータの値が前記第1初期値に対して前記第1所定値以上変化したと判定されると、新たな前記特定の対戦相手に係る前記対戦ゲームパートを新たに設定し、
前記第1設定部は、前記ゲームパート設定部により前記対戦ゲームパートが新たに設定されるごとに前記第1所定値が前回値以上となる態様で、前記第1所定値を設定する、付記2に記載の情報処理システム。
[付記4]
前記第2パラメータを複数設定する第2パラメータ設定部を更に備え、
前記第2設定部、前記第2更新部及び前記第2判定部は、前記第2パラメータ設定部により設定される前記第2パラメータごとに機能し、
前記第1更新部は、前記第2判定部によりいずれかの前記第2パラメータの値が前記第2初期値に対して前記第2所定値以上変化したと判定されるごとに、前記第1パラメータの値を更新する、付記2又は3に記載の情報処理システム。
[付記5]
前記第2パラメータ設定部は、1人以上のユーザごとに、前記1人以上のユーザに一の前記第2パラメータが対応付けられる態様で、前記第2パラメータを設定する、付記4に記載の情報処理システム。
[付記6]
前記第2パラメータ設定部は、前記複数のユーザのうちの、所定関係を有する2人以上のユーザに対して、一の前記第2パラメータを設定する、付記5に記載の情報処理システム。
[付記7]
前記第2パラメータ設定部は、常に、前記複数のユーザのそれぞれに対して、一の前記第2パラメータを設定する、付記5又は6に記載の情報処理システム。
[付記8]
前記対戦ゲームパートは、参加中の前記複数のユーザの構成が変化する態様で、新たなユーザの後からの参加及び参加中のユーザの途中からの退出が可能であり、
前記対戦ゲームパートへのユーザの参加状況を更新する参加管理部を更に備え、
前記第2パラメータ設定部は、前記参加状況に応じて、前記第2パラメータを設定する、付記5又は6に記載の情報処理システム。
[付記9]
前記第2パラメータ設定部は、前記第1判定部により、一の特定の対戦相手に対応付けられる前記第1パラメータの値が前記第1初期値に対して前記第1所定値以上変化したと判定されるまで、前記一の特定の対戦相手に対応付けられる前記第2パラメータを次々と新たに設定する、付記8に記載の情報処理システム。
[付記10]
前記第2パラメータ設定部は、設定した前記第2パラメータの数分の前記第2所定値の合計値が、前記第1所定値を超えるが、前記第1所定値よりも大きい所定の上限値を超えないように、前記第2パラメータを設定する、付記9に記載の情報処理システム。
[付記11]
前記第2所定値は、固定値であり、
前記第2パラメータ設定部は、前記第1所定値を前記第2所定値で割ることで得られる値よりも大きい数であって、所定の上限数を超えない数だけ、前記第2パラメータを設定する、付記9に記載の情報処理システム。
[付記12]
前記第2パラメータ設定部は、各ユーザに所定の上限数を超える数の前記第2パラメータが対応付けられている状態が形成されないように、前記第2パラメータを設定する、付記9に記載の情報処理システム。
[付記13]
前記第2パラメータ設定部は、前記複数のユーザの数が閾値を超えた場合に、2人以上のユーザに対して、一の前記第2パラメータを新たに設定する、付記9に記載の情報処理システム。
[付記14]
前記第2パラメータ設定部は、一のユーザからの設定要求に応じて、前記一のユーザに対応付けられる前記第2パラメータを新たに設定する、又は、既に他のユーザに対応付けられて設定されている前記第2パラメータを前記一のユーザに更に対応付ける、付記5、6、8から13のうちのいずれか1項に記載の情報処理システム。
[付記15]
前記第2パラメータ設定部により2つ以上の前記第2パラメータが一のユーザに対応付けられている場合に、前記第2更新部は、2つ以上の前記第2パラメータが対応付けられているユーザからの入力に基づいて、2つ以上の前記第2パラメータのそれぞれ又は一部の値を更新する、付記4から14のうちのいずれか1項に記載の情報処理システム。
[付記16]
ユーザ情報を記憶するユーザ情報記憶部を更に備え、
前記第2設定部は、前記第2パラメータ設定部により前記第2パラメータが新たに設定される場合に、前記第2パラメータが対応付けるユーザに係る前記ユーザ情報に基づいて、前記ユーザ情報に応じて異なる前記第2所定値を設定する、付記4から15のうちのいずれか1項に記載の情報処理システム。
[付記17]
前記第2設定部は、前記第1所定値、及び、前記第1更新部により更新された前記第1パラメータの値、のうちのいずれか一方の値に基づいて、前記いずれか一方の値に応じて前記第2所定値が変化する態様で前記第2所定値を設定する、付記4から16のうちのいずれか1項に記載の情報処理システム。
[付記18]
前記第1更新部は、1つ以上のコンピュータにより実現され、
前記第2更新部は、前記第1更新部よりも多い数のコンピュータにより実現される、付記4から17のうちのいずれか1項に記載の情報処理システム。
[付記19]
各ユーザに係るユーザ端末に画像を表示させるための表示用画像情報を生成する画像生成部を更に備え、
前記画像生成部は、前記第1パラメータの値が前記第1更新部により更新されるごとに、前記特定の対戦相手に係る画像と、更新後の前記第1パラメータの値を表す画像と表示させるための第1表示用画像情報を生成する、付記2から18のうちのいずれか1項に記載の情報処理システム。
[付記20]
前記画像生成部は、前記第2パラメータの値が前記第2更新部により更新されるごとに、前記特定の対戦相手に係る画像と、更新後の前記第2パラメータの値を表す画像とを表示させるための第2表示用画像情報を生成する、付記19に記載の情報処理システム。
[付記21]
前記画像生成部は、前記第1パラメータの値に対応付けて前記特定の対戦相手を表示するときと、前記第2パラメータの値に対応付けて前記特定の対戦相手を表示するときとで、異なる態様で前記特定の対戦相手が描画されるように前記表示用画像情報を生成する、付記19又は20に記載の情報処理システム。
[付記22]
前記画像生成部は、前記第1パラメータの値に対応付けて前記特定の対戦相手を表示する場合は、第1識別子に対応付けられたゲーム媒体が描画され、かつ、前記第2パラメータの値に対応付けて前記特定の対戦相手を表示する場合は、第2識別子に対応付けられたゲーム媒体が描画されるように前記表示用画像情報を生成する、付記19から21のうちのいずれか1項に記載の情報処理システム。
[付記23]
複数のユーザと特定の対戦相手との間の対戦ゲームパートを設定するゲームパート設定ステップと、
前記対戦ゲームパートの進行に基づいて、前記特定の対戦相手に対応付けられる第1パラメータの値を更新する第1更新ステップと、
前記対戦ゲームパートの進行に基づいて、前記特定の対戦相手に対応付けられる第2パラメータの値を更新する第2更新ステップと、を備え、
前記第1更新ステップは、前記第2パラメータの値に基づいて、前記第2更新ステップよりも少ない更新頻度で前記第1パラメータの値を更新する、コンピュータにより実行される情報処理方法。
[付記24]
複数のユーザと特定の対戦相手との間の対戦ゲームパートを設定するゲームパート設定処理と、
前記対戦ゲームパートの進行に基づいて、前記特定の対戦相手に対応付けられる第1パラメータの値を更新する第1更新処理と、
前記対戦ゲームパートの進行に基づいて、前記特定の対戦相手に対応付けられる第2パラメータの値を更新する第2更新処理と、
をコンピュータに実行させ、
前記第1更新処理は、前記第2パラメータの値に基づいて、前記第2更新処理よりも少ない更新頻度で前記第1パラメータの値を更新する、情報処理プログラム。
【符号の説明】
【0216】
1 ゲームシステム
10 サーバ装置
11 サーバ通信部
12 サーバ記憶部
13 サーバ制御部
20 端末装置
21 端末通信部
22 端末記憶部
23 表示部
24 入力部
25 端末制御部
30 ネットワーク
150 ゲームパート設定部
151 参加管理部
152 小ボスバトル設定部
153 大ボス関連処理部
1531 第1設定部
1532 第1更新部
1533 第1判定部
154 小ボスバトル処理部
1541 第2設定部
1542 第2更新部
1543 第2判定部
155 救援要請処理部
156 ゲーム状態管理部
157 同時プレイ検出部
158 画像生成部
159 報酬付与部
160 ゲームデータ記憶部
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14A
図14B
図15
図16