特許 5753330 情報処理装置、及び、ゲームプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】5753330

(24)【登録日】2015年5月29日

(45)【発行日】2015年7月22日

(54)【発明の名称】情報処理装置、及び、ゲームプログラム

(51)【国際特許分類】

   A63F 13/847 20140101AFI20150702BHJP

【ＦＩ】

   A63F13/847

【請求項の数】7

【全頁数】25

(21)【出願番号】特願2015-48863(P2015-48863)

(22)【出願日】2015年3月11日

【審査請求日】2015年4月2日

【早期審査対象出願】

(73)【特許権者】

【識別番号】599115217

【氏名又は名称】株式会社 ディー・エヌ・エー

(74)【代理人】

【識別番号】100156605

【弁理士】

【氏名又は名称】山田 彰彦

(72)【発明者】

【氏名】上谷 祐次亮

(72)【発明者】

【氏名】島田 洋輝

(72)【発明者】

【氏名】冨井 武史

【審査官】 鈴木 崇雅

(56)【参考文献】

【文献】 特開２０１４−１８８３３１（ＪＰ，Ａ）

【文献】 「ＢＯＲＤＥＲ ＢＲＥＡＫ Ｍｏｂｉｌｅ 疾風のガンフロント」，アプリＦａｎ，株式会社コスミック出版，２０１３年 ６月１０日，第１巻 第３号，第２８−３２頁

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ａ６３Ｆ １３／００−９８

(57)【特許請求の範囲】

【請求項1】

共通の対戦相手である共通エネミーキャラクターが対応付けられた複数プレイヤーのうち、いずれかのプレイヤーが前記共通エネミーキャラクターに対する攻撃操作を行なった後に、異なる他のプレイヤーが前記共通エネミーキャラクターに対する攻撃操作を行なう度に、前記共通エネミーキャラクターに対する連続攻撃ポイントを増加させるポイント変動処理部と、
前記共通エネミーキャラクターに対する連続攻撃ポイントが増大するほど、前記共通エネミーキャラクターとの対戦で複数プレイヤーがより有利になるように制御するゲーム進行処理部と、
前記共通エネミーキャラクターが対応付けられた依頼元となるプレイヤーからの応援依頼を受ける依頼先となるプレイヤーを、異なる他の共通エネミーキャラクターが対応付けられた複数プレイヤーの中から決定する依頼先決定処理部と、
を備え、
前記ポイント変動処理部は、決定された前記依頼先となるプレイヤーのうち、いずれかのプレイヤーが自己に対応付けられた前記他の共通エネミーキャラクターに対する攻撃操作を行なった際に、前記依頼元となるプレイヤーに対応付けられた前記共通エネミーキャラクターに対する連続攻撃ポイントを増加させる、
ことを特徴とする情報処理装置。

【請求項2】

請求項１に記載の情報処理装置であって、
前記ゲーム進行処理部は、決定された前記依頼先となるプレイヤーが前記他の共通エネミーキャラクターに対する攻撃操作を行なった際に、当該依頼先となるプレイヤーに対して報酬を付与する、
ことを特徴とする情報処理装置。

【請求項3】

請求項１又は２に記載の情報処理装置であって、
前記依頼先決定処理部は、
前記共通エネミーキャラクターが対応付けられた複数プレイヤーのうち、依頼元となるプレイヤーが応援依頼するための操作を行なった際に、前記他の共通エネミーキャラクターが対応付けられた複数プレイヤーの中から、依頼先となるプレイヤーを決定するものであり、
前記共通エネミーキャラクターが対応付けられた複数プレイヤーのうち、依頼元となる一のプレイヤーが応援依頼するための操作を行なってから一定期間が経過する前に、依頼元となる他のプレイヤーが応援依頼するための操作を行なった際に、前記他の共通エネミーキャラクターが対応付けられた複数プレイヤーの中から、依頼先となるプレイヤーを決定しない、
ことを特徴とする情報処理装置。

【請求項4】

請求項１乃至３のいずれかに記載の情報処理装置であって、
それぞれに対応付けられた前記共通エネミーキャラクターとの対戦を、互いに競い合う相手となる複数プレイヤーをマッチングするマッチング処理部と、
を備え、
前記依頼先決定処理部は、前記依頼元となるプレイヤーと競い合う相手となる複数プレイヤーの中から、依頼先となるプレイヤーを決定しない、
ことを特徴とする情報処理装置。

【請求項5】

請求項１乃至４のいずれかに記載の情報処理装置であって、
前記ポイント変動処理部は、
前記共通エネミーキャラクターが対応付けられた依頼元となるプレイヤーが、前記共通エネミーキャラクターに対する攻撃操作を行なうことができない場合であっても、
前記依頼先となるプレイヤーが前記他の共通エネミーキャラクターに対する攻撃操作を行なった際には、前記依頼元となるプレイヤーに対応付けられた前記共通エネミーキャラクターに対する連続攻撃ポイントを増加させる、
ことを特徴とする情報処理装置。

【請求項6】

請求項１乃至５のいずれかに記載の情報処理装置であって、
前記ポイント変動処理部は、前記他の共通エネミーキャラクターが対応付けられた複数プレイヤーのうち、前記依頼先となるプレイヤーが前記他の共通エネミーキャラクターに対する攻撃操作を行なった際に、前記他の共通エネミーキャラクターに対する連続攻撃ポイントを増加させると共に、前記依頼元となるプレイヤーに対応付けられた前記共通エネミーキャラクターに対する連続攻撃ポイントを増加させる、
ことを特徴とする情報処理装置。

【請求項7】

コンピューターに、
共通の対戦相手である共通エネミーキャラクターが対応付けられた複数プレイヤーのうち、いずれかのプレイヤーが前記共通エネミーキャラクターに対する攻撃操作を行なった後に、異なる他のプレイヤーが前記共通エネミーキャラクターに対する攻撃操作を行なう度に、前記共通エネミーキャラクターに対する連続攻撃ポイントを増加させるポイント変動処理と、
前記共通エネミーキャラクターに対する連続攻撃ポイントが増大するほど、前記共通エネミーキャラクターとの対戦で複数プレイヤーがより有利になるように制御するゲーム進行処理と、
前記共通エネミーキャラクターが対応付けられた依頼元となるプレイヤーからの応援依頼を受ける依頼先となるプレイヤーを、異なる他の共通エネミーキャラクターが対応付けられた複数プレイヤーの中から決定する依頼先決定処理と、
を実行させるゲームプログラムであって、
前記ポイント変動処理は、決定された前記依頼先となるプレイヤーのうち、いずれかのプレイヤーが自己に対応付けられた前記他の共通エネミーキャラクターに対する攻撃操作を行なった際に、前記依頼元となるプレイヤーに対応付けられた前記共通エネミーキャラクターに対する連続攻撃ポイントを増加させる、
ことを特徴とするゲームプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

多人数参加型の対戦ゲームに参加した複数プレイヤーのそれぞれが、共通の対戦相手である共通エネミーキャラクターと対戦できるように制御すると共に、共通エネミーキャラクターとの対戦に参加している或るプレイヤーが、他のプレイヤー（例えば、フレンドプレイヤー）に対して応援依頼を行なうと、その依頼を受けた他のプレイヤーが参戦できるように制御するゲームシステムが知られている（たとえば、特許文献１）。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特許第５２２０９３７号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

このようなゲームシステムでは、例えば、依頼元となる或るプレイヤーが共通エネミーキャラクターに対して攻撃を行なった後、依頼先となる他のプレイヤーが共通エネミーキャラクターに対して続けて攻撃を行なう等、共通エネミーキャラクターに対する攻撃が次々と行われることによって連続攻撃ポイントを増加させ、その連続攻撃ポイントの大きさに応じた攻撃を行なえるように制御することも可能である。そして、連続攻撃ポイントを増大させて攻撃を行なうことができれば、共通エネミーキャラクターとの対戦を有利に進めることができるようになる。
しかし、依頼先となる他のプレイヤーが参戦できない状況にあるときには、共通エネミーキャラクターに対する連続攻撃が途絶えてしまい、連続攻撃ポイントを増やすことができなくってしまう虞がある。このように連続攻撃ポイントを増やせなければ、共通エネミーキャラクターとの対戦を有利に進めることができなくなってしまうため、プレイヤーのプレイ意欲を減退させる要因となる。
本発明は、このような事情に鑑みてなされたものであり、その目的とするところは、プレイヤーのプレイ意欲を向上させ、多人数参加型ゲームを活性化させることにある。

【課題を解決するための手段】

【0005】

上記課題を解決するための本発明の主たる発明は、
共通の対戦相手である共通エネミーキャラクターが対応付けられた複数プレイヤーのうち、いずれかのプレイヤーが前記共通エネミーキャラクターに対する攻撃操作を行なった後に、異なる他のプレイヤーが前記共通エネミーキャラクターに対する攻撃操作を行なう度に、前記共通エネミーキャラクターに対する連続攻撃ポイントを増加させるポイント変動処理部と、
前記共通エネミーキャラクターに対する連続攻撃ポイントが増大するほど、前記共通エネミーキャラクターとの対戦で複数プレイヤーがより有利になるように制御するゲーム進行処理部と、
前記共通エネミーキャラクターが対応付けられた依頼元となるプレイヤーからの応援依頼を受ける依頼先となるプレイヤーを、異なる他の共通エネミーキャラクターが対応付けられた複数プレイヤーの中から決定する依頼先決定処理部と、
を備え、
前記ポイント変動処理部は、決定された前記依頼先となるプレイヤーのうち、いずれかのプレイヤーが自己に対応付けられた前記他の共通エネミーキャラクターに対する攻撃操作を行なった際に、前記依頼元となるプレイヤーに対応付けられた前記共通エネミーキャラクターに対する連続攻撃ポイントを増加させる、
ことを特徴とする情報処理装置である。
本発明の他の特徴については、本明細書及び添付図面の記載により明らかにする。

【図面の簡単な説明】

【0006】

【図1】ゲームシステム１の全体構成例を示す図である。

【図2】サーバー装置１０の機能上の構成を示すブロック図である。

【図3】キャラクター情報のデータ構造例を示す図である。

【図4】プレイヤー情報のデータ構造例を示す図である。

【図5】所有キャラクター情報のデータ構造例を示す図である。

【図6】チーム情報のデータ構造例を示す図である。

【図7】攻撃ログ情報のデータ構造例を示す図である。

【図8】依頼ログ情報のデータ構造例を示す図である。

【図9】依頼先情報のデータ構造例を示す図である。

【図10】マッチング情報のデータ構造例を示す図である。

【図11】プレイヤー端末２０の機能上の構成を示すブロック図である。

【図12】ゲームシステムの動作例を説明するフローチャートである。

【図13】対戦ゲーム画面５０の一例を示す図である。

【図14】対戦処理を説明するフローチャートである。

【図15】ポイント変動処理を説明するフローチャートである。

【図16】依頼先決定処理を説明するフローチャートである。

【図17】対戦ゲーム画面６０の一例を示す図である。

【発明を実施するための形態】

【0007】

本明細書及び添付図面の記載により、少なくとも以下の事項が明らかとなる。
即ち、共通の対戦相手である共通エネミーキャラクターが対応付けられた複数プレイヤーのうち、いずれかのプレイヤーが前記共通エネミーキャラクターに対する攻撃操作を行なった後に、異なる他のプレイヤーが前記共通エネミーキャラクターに対する攻撃操作を行なう度に、前記共通エネミーキャラクターに対する連続攻撃ポイントを増加させるポイント変動処理部と、
前記共通エネミーキャラクターに対する連続攻撃ポイントが増大するほど、前記共通エネミーキャラクターとの対戦で複数プレイヤーがより有利になるように制御するゲーム進行処理部と、
前記共通エネミーキャラクターが対応付けられた依頼元となるプレイヤーからの応援依頼を受ける依頼先となるプレイヤーを、異なる他の共通エネミーキャラクターが対応付けられた複数プレイヤーの中から決定する依頼先決定処理部と、
を備え、
前記ポイント変動処理部は、決定された前記依頼先となるプレイヤーのうち、いずれかのプレイヤーが自己に対応付けられた前記他の共通エネミーキャラクターに対する攻撃操作を行なった際に、前記依頼元となるプレイヤーに対応付けられた前記共通エネミーキャラクターに対する連続攻撃ポイントを増加させる、
ことを特徴とする情報処理装置である。
このような情報処理装置によれば、依頼元となるプレイヤーは、同じ共通エネミーキャラクターが対応付けられた複数プレイヤーが参戦できない状況にあっても、異なる他の共通エネミーキャラクターが対応付けられた複数プレイヤーに対して応援依頼を行なうことで、自己の共通エネミーキャラクターに対する連続攻撃ポイントの増大を期待できる。また、依頼先となるプレイヤーは、依頼元となるプレイヤーに対応付けられた共通エネミーキャラクターではなく、自己に対応付けられた前記他の共通エネミーキャラクターに対する攻撃を行なうことで、依頼元となるプレイヤーに対応付けられた共通エネミーキャラクターに対する連続攻撃ポイントの増大に無理なく貢献できる。その結果、連続攻撃ポイントを簡単に増やせるようになるため、プレイヤーのプレイ意欲を向上させることができ、ひいては多人数参加型ゲームを活性化させることが可能となる。

【0008】

かかる情報処理装置であって、前記ゲーム進行処理部は、決定された前記依頼先となるプレイヤーが前記他の共通エネミーキャラクターに対する攻撃操作を行なった際に、当該依頼先となるプレイヤーに対して報酬を付与する、こととしてもよい。
このような情報処理装置によれば、依頼先となるプレイヤーは、依頼元となるプレイヤーに対応付けられた共通エネミーキャラクターではなく、自己に対応付けられた前記他の共通エネミーキャラクターに対する攻撃を行なうことで、報酬を得ることができるため、依頼元となるプレイヤーに対応付けられた共通エネミーキャラクターに対する連続攻撃ポイントの増大に積極的に貢献するようになる。その結果、多人数参加型ゲームをより一層活性化させることが可能となる。

【0009】

かかる情報処理装置であって、前記依頼先決定処理部は、
前記共通エネミーキャラクターが対応付けられた複数プレイヤーのうち、依頼元となるプレイヤーが応援依頼するための操作を行なった際に、前記他の共通エネミーキャラクターが対応付けられた複数プレイヤーの中から、依頼先となるプレイヤーを決定するものであり、
前記共通エネミーキャラクターが対応付けられた複数プレイヤーのうち、依頼元となる一のプレイヤーが応援依頼するための操作を行なってから一定期間が経過する前に、依頼元となる他のプレイヤーが応援依頼するための操作を行なった際に、前記他の共通エネミーキャラクターが対応付けられた複数プレイヤーの中から、依頼先となるプレイヤーを決定しない、こととしてもよい。
このような情報処理装置によれば、制限なく応援依頼を行なえないようにすることで、連続攻撃ポイントが過剰に増大しないように抑制することができる。

【0010】

かかる情報処理装置であって、それぞれに対応付けられた前記共通エネミーキャラクターとの対戦を、互いに競い合う相手となる複数プレイヤーをマッチングするマッチング処理部と、を備え、
前記依頼先決定処理部は、前記依頼元となるプレイヤーと競い合う相手となる複数プレイヤーの中から、依頼先となるプレイヤーを決定しない、こととしてもよい。
このような情報処理装置によれば、マッチングされた複数プレイヤー同士が、互いに競い合う相手側に対して応援を依頼したり、互いに競い合う相手側から依頼を受けたりしないように抑制することができる。

【0011】

かかる情報処理装置であって、前記ポイント変動処理部は、前記共通エネミーキャラクターが対応付けられた依頼元となるプレイヤーが、前記共通エネミーキャラクターに対する攻撃操作を行なうことができない場合であっても、前記依頼先となるプレイヤーが前記他の共通エネミーキャラクターに対する攻撃操作を行なった際には、前記依頼元となるプレイヤーに対応付けられた前記共通エネミーキャラクターに対する連続攻撃ポイントを増加させる、こととしてもよい。
このような情報処理装置によれば、依頼元となるプレイヤーが攻撃操作を行なうことができなくても（例えば、サブキャラクターへの攻撃が優先され、メインキャラクター（ボス）に攻撃ができない等）、依頼先となるプレイヤーが攻撃操作を行なえば、連続攻撃ポイントを増加させることができる。その結果、応援依頼が積極的に行われるようになるため、多人数参加型ゲームをより一層活性化させることが可能となる。

【0012】

かかる情報処理装置であって、前記ポイント変動処理部は、前記他の共通エネミーキャラクターが対応付けられた複数プレイヤーのうち、前記依頼先となるプレイヤーが前記他の共通エネミーキャラクターに対する攻撃操作を行なった際に、前記他の共通エネミーキャラクターに対する連続攻撃ポイントを増加させると共に、前記依頼元となるプレイヤーに対応付けられた前記共通エネミーキャラクターに対する連続攻撃ポイントを増加させる、こととしてもよい。
このような情報処理装置によれば、依頼先となるプレイヤーは、自己に対応付けられた他の共通エネミーキャラクターに対する攻撃操作を行なうことで、依頼元となるプレイヤーに対応付けられた共通エネミーキャラクターに対する連続攻撃ポイントの増大に貢献できると共に、自己に対応付けられた他の共通エネミーキャラクターに対する連続攻撃ポイントの増大にも貢献できる。

【0013】

次に、コンピューターに、
共通の対戦相手である共通エネミーキャラクターが対応付けられた複数プレイヤーのうち、いずれかのプレイヤーが前記共通エネミーキャラクターに対する攻撃操作を行なった後に、異なる他のプレイヤーが前記共通エネミーキャラクターに対する攻撃操作を行なう度に、前記共通エネミーキャラクターに対する連続攻撃ポイントを増加させるポイント変動処理と、
前記共通エネミーキャラクターに対する連続攻撃ポイントが増大するほど、前記共通エネミーキャラクターとの対戦で複数プレイヤーがより有利になるように制御するゲーム進行処理と、
前記共通エネミーキャラクターが対応付けられた依頼元となるプレイヤーからの応援依頼を受ける依頼先となるプレイヤーを、異なる他の共通エネミーキャラクターが対応付けられた複数プレイヤーの中から決定する依頼先決定処理と、
を実行させるゲームプログラムであって、
前記ポイント変動処理は、決定された前記依頼先となるプレイヤーのうち、いずれかのプレイヤーが自己に対応付けられた前記他の共通エネミーキャラクターに対する攻撃操作を行なった際に、前記依頼元となるプレイヤーに対応付けられた前記共通エネミーキャラクターに対する連続攻撃ポイントを増加させる、
ことを特徴とするゲームプログラムである。
このようなゲームプログラムによれば、プレイヤーのプレイ意欲を向上させ、多人数参加型ゲームを活性化させることができる。

【0014】

＝＝＝実施形態＝＝＝
＜＜ゲームシステム１の構成について＞＞
図１は、ゲームシステム１の全体構成の一例を示す図である。ゲームシステム１は、ネットワーク２（例えば、インターネット等）を介してゲームに関する各種サービスをプレイヤーに提供するものであり、サーバー装置１０と、複数のプレイヤー端末２０と、を含んで構成される。

【0015】

本実施形態に係るゲームシステム１は、ゲームコンテンツの一例としてのキャラクターカード（以下、単に「キャラクター」とも呼ぶ）を用いて行なうキャラクター対戦を、プレイヤーに提供することができる。

【0016】

本実施形態に係るキャラクター対戦は、複数プレイヤーのそれぞれが所有するプレイヤーキャラクターを、共通の対戦相手である共通エネミーキャラクターと対戦させるゲームである。各プレイヤーは、少人数（例えば、１０人）で構成されるいずれかのチームに所属する。各チームに対し、チーム毎に出現する共通エネミーキャラクターとの対戦を競い合う相手チームがマッチングされる。マッチングされたチーム同士により、相手チームよりも多くのスコアを獲得することを目的とするチーム対戦が行われる。

【0017】

本実施形態に係るキャラクター対戦において、チーム内の各プレイヤーは、共通エネミーキャラクターへの攻撃を次々と行なうことにより、共通エネミーキャラクターに対する連続攻撃ポイントを増やすことができる。連続攻撃ポイントを増大させて攻撃を行なうことで、共通エネミーキャラクターとの対戦を有利に進めることができる。また、チーム内の各プレイヤーは、共通エネミーキャラクターに対する連続攻撃が途絶えてしまう虞がある場合等に、他のチームに所属するプレイヤーに対して応援依頼を行なうことができる。応援依頼を受けた他のチームに所属するプレイヤー（依頼先のプレイヤー）は、自分が対戦している共通エネミーキャラクターに対して攻撃を行なうことで、依頼元のプレイヤーが対戦している共通エネミーキャラクターに対する連続攻撃ポイントを増やすことができる。

【0018】

＜＜サーバー装置１０の構成について＞＞
図２は、サーバー装置１０の機能上の構成を示すブロック図である。サーバー装置１０は、システム管理者等が各種サービスを運営・管理する際に利用する情報処理装置（例えば、ワークステーションやパーソナルコンピューター等）である。サーバー装置１０は、プレイヤー端末２０から各種のコマンド（リクエスト）を受信すると、プレイヤー端末２０上で動作可能なゲームプログラム・各種データや、プレイヤー端末２０の規格に合わせたマークアップ言語（ＨＴＭＬ等）で作成されたＷｅｂページ（ゲーム画面等）を送信（レスポンス）する。サーバー装置１０は、制御部１１と、記憶部１２と、入力部１３と、表示部１４と、通信部１５と、を有する。

【0019】

制御部１１は、各部間のデータの受け渡しを行うと共に、サーバー装置１０全体の制御を行うものであり、ＣＰＵ（Central Processing Unit）が所定のメモリに格納されたプログラムを実行することによって実現される。本実施形態の制御部１１は、少なくとも、ゲーム進行処理部１１１、マッチング処理部１１２、ポイント変動処理部１１３、依頼先決定処理部１１４、画面データ生成処理部１１５を備える。

【0020】

ゲーム進行処理部１１１は、ゲームプログラムに従って対戦ゲームを進行させる処理を実行する機能を有している。本実施形態におけるゲーム進行処理部１１１は、プレイヤーの操作入力を受け付けると、共通エネミーキャラクターに対する攻撃をプレイヤーキャラクターに行なわせることにより、キャラクター対戦を進行させる。またゲーム進行処理部１１１は、共通エネミーキャラクターに対する連続攻撃ポイントが増大するほど、その共通エネミーキャラクターとの対戦でチームがより有利になるように制御する。

【0021】

マッチング処理部１１２は、マッチングに関する各種処理を実行する機能を有している。本実施形態におけるマッチング処理部１１２は、チーム対戦にエントリーされた複数プレイヤーのそれぞれをいずれかのチームに所属させ、互いに競い合う相手チームをマッチングする。すなわち、チーム対戦を互いに競い合う相手となる複数プレイヤー同士がマッチングされることになる。

【0022】

ポイント変動処理部１１３は、連続対戦ポイントの変動に関する各種処理を実行する機能を有している。本実施形態におけるポイント変動処理部１１３は、共通エネミーキャラクターに対する攻撃がチーム内の複数プレイヤー（つまり、共通エネミーキャラクターが対応付けられた複数プレイヤー）によって連続的に行われる度に、共通エネミーキャラクターに対する連続攻撃ポイントを増加させる。またポイント変動処理部１１３は、応援依頼を受けた他のチームのプレイヤー（つまり、異なる他の共通エネミーキャラクターが対応付けられた依頼先のプレイヤー）によって、その異なる他の共通エネミーキャラクターに対する攻撃が行われると、依頼元のプレイヤーが対戦している共通エネミーキャラクターに対する連続攻撃ポイントを増加させる。その一方で、ポイント変動処理部１１３は、共通エネミーキャラクターに対する連続攻撃ポイントをリセットする等、所定条件に基づき連続攻撃ポイントを減少させる。

【0023】

依頼先決定処理部１１４は、依頼元のプレイヤーによる応援依頼が受け付けたときに、依頼先のプレイヤーを決定する処理を実行する機能を有している。本実施形態における依頼先決定処理部１１４は、依頼元となるプレイヤーに対応付けられた共通エネミーキャラクターとは異なる他の共通エネミーキャラクターが対応付けられた複数プレイヤーの中から（つまり、他のチームに所属する複数プレイヤーの中から）、依頼先となる１又は複数のプレイヤーを決定する。

【0024】

画面データ生成部１１５は、ゲーム画面をプレイヤー端末２０に表示させるための画面データを生成する処理を実行する機能を有している。本実施形態における画面データ生成部１１５は、ゲーム画面に対応する画面データとしてＨＴＭＬデータを生成する。

【0025】

記憶部１２は、システムプログラムが記憶された読み取り専用の記憶領域であるＲＯＭ（Read Only Memory）と、制御部１１による演算処理のワーク領域として使用される書き換え可能な記憶領域であるＲＡＭ（Random Access Memory）とを有しており、例えば、フラッシュメモリやハードディスク等の不揮発性記憶装置によって実現される。本実施形態における記憶部１２は、少なくともキャラクター情報、プレイヤー情報、チーム情報、及びマッチング情報を記憶する。なお、これら各種情報については追って詳述する。

【0026】

入力部１３は、システム管理者等がゲームサービスに関する各種データ（例えば、キャラクター情報等）を入力するためのものであり、例えば、キーボードやマウス等によって実現される。

【0027】

表示部１４は、制御部１１からの指令に基づいてシステム管理者用の操作画面を表示するためのものであり、例えば、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）等によって実現される。

【0028】

通信部１５は、プレイヤー端末２０との間で通信を行うためのものであり、プレイヤー端末２０から送信される各種データや信号を受信する受信部としての機能と、制御部１１の指令に応じて各種データや信号をプレイヤー端末２０へ送信する送信部として機能とを有している。通信部１５は、例えば、ＮＩＣ（Network Interface Card）等によって実現される。

【0029】

図３は、キャラクター情報のデータ構造例を示す図である。このキャラクター情報には、キャラクターＩＤに対応付けて、少なくとも、キャラクター名、キャラクター画像、レアリティ、スキル、及び、最大攻撃力、最大防御力、最大体力、初期攻撃力、初期防御力、初期体力等の能力パラメーターが設定されている。

【0030】

図４は、プレイヤー情報のデータ構造例を示す図である。このプレイヤー情報には、プレイヤーＩＤに対応付けて、少なくとも、プレイヤー名、フレンドプレイヤーのプレイヤーＩＤ、バトルポイント、コイン／回数、ログイン情報、アクティブ情報、依頼状況、所有キャラクター情報が設定されている。バトルポイントは、プレイヤーが所持するポイント量を示すパラメーター情報であり、プレイヤーがキャラクター対戦を開始する際に消費される。コイン／回数のうち、上段のコインは、プレイヤーが所持するコイン枚数を示すパラメーター情報であり、報酬として付与される。下段の回数は、コインを獲得した回数（つまり報酬が付与された回数）を示す情報である。ログイン情報は、ゲームシステムへのログイン状態を示す情報である。アクティブ情報は、プレイヤーのアクティブ状態を示す情報である。アクティブとは、直近の５分以内にプレイヤーが攻撃を行なったことを意味する。依頼状況は、そのプレイヤーが他のプレイヤーから応援依頼を受けている状態であるか否かを示す情報である。

【0031】

図５は、所有キャラクター情報のデータ構造例を示す図である。所有キャラクター情報は、プレイヤーが所有するキャラクター（以下、「所有キャラクター」とも呼ぶ）に関する情報である。この所有キャラクター情報には、所有キャラクターのキャラクターＩＤに対応付けて、少なくとも、現時点におけるレベル、攻撃力、防御力、体力等の各種パラメーターが設定されている。

【0032】

図６は、チーム情報のデータ構造例を示す図である。このチーム情報には、チームＩＤに対応付けて、少なくとも、チーム名、所属プレイヤー、連続攻撃ポイント、相手チーム、エネミーキャラクター、獲得スコア、攻撃ログ情報、依頼ログ情報、依頼先情報が設定されている。所属プレイヤーは、チームに所属する各プレイヤーのプレイヤーＩＤを示す情報である。連続攻撃ポイントは、連続攻撃によって蓄積されたポイント量を示すパラメーター情報であり、各プレイヤーが攻撃を行なう度にポイント加算される。相手チームは、マッチングされた相手チームのチームＩＤを示す情報である。共通エネミーキャラクターは、チームに所属する複数プレイヤーのそれぞれに対応付けられた対戦相手となる共通のキャラクターである。共通エネミーキャラクターには、ボスキャラクターとしてのメインキャラクターの他に、そのメインキャラクターを護衛するサブキャラクターが含まれる場合がある。この場合は、サブキャラクターを倒さなければ、メインキャラクターに攻撃ができない。よって、プレイヤーが攻撃操作を行なうと、サブキャラクターへの攻撃が優先される。獲得スコアは、チームが獲得したスコア（各プレイヤーが獲得したスコアの合計）を示す情報である。攻撃ログ情報は、チーム内のプレイヤーが行った攻撃に関する記録情報である。依頼ログ情報は、チーム内のプレイヤーが行った応援依頼に関する記録情報である。依頼先情報は、依頼先となるプレイヤーに関する情報である。

【0033】

図７は、攻撃ログ情報のデータ構造例を示す図である。この攻撃ログ情報には、攻撃ログＩＤに対応付けて、少なくとも、チーム内で攻撃操作を行なったプレイヤーのプレイヤーＩＤ、攻撃日時が設定されている。攻撃日時は、プレイヤーが攻撃操作を行なった日時を示す情報である。

【0034】

図８は、依頼ログ情報のデータ構造例を示す図である。この依頼ログ情報には、依頼ログＩＤに対応付けて、少なくとも、チーム内で応援依頼操作を行なったプレイヤーのプレイヤーＩＤ、応援依頼日時が設定されている。応援依頼日時は、プレイヤーが応援依頼操作を行なった日時を示す情報である。

【0035】

図９は、依頼先情報のデータ構造例を示す図である。この依頼先情報には、応援依頼を受けた依頼先のプレイヤーのプレイヤーＩＤ、及び、そのプレイヤーが所属するチームのチームＩＤが設定されている。本実施形態では、１回の応援依頼がある度に、１０人の依頼先プレイヤーが設定される。

【0036】

図１０は、マッチング情報のデータ構造例を示す図である。マッチング情報は、マッチングされたチーム（複数プレイヤー）に関する情報である。このマッチング情報には、マッチングＩＤに対応付けて、互いに競い合う相手となる２つのチームのチームＩＤ（チームに所属する各プレイヤーのプレイヤーＩＤ）が設定されている。

【0037】

＜＜プレイヤー端末２０の構成について＞＞
図１１は、プレイヤー端末２０の機能上の構成を示すブロック図である。プレイヤー端末２０は、プレイヤーが所持し利用することができる情報処理装置（例えば、タブレット端末、携帯電話端末、スマートフォン等）である。プレイヤー端末２０は、Ｗｅｂブラウザ機能を有しているため、サーバー装置１０から送信されたＷｅｂページ（ゲーム画面等）を画面表示することができる。プレイヤー端末２０は、プレイヤー端末２０全体の制御を行う端末制御部２１と、各種データ・プログラムを記憶する端末記憶部２２と、プレイヤーが操作入力を行うための端末操作部２３と、ゲーム画面・操作画面を表示する端末表示部２４と、サーバー装置１０との間で情報通信を行う端末通信部２５を有している。

【0038】

＜＜ゲームシステム１の動作について＞＞
図１２は、本実施形態に係るゲームシステムの動作例を説明するためのフローチャートである。以下では、チームＡに所属するプレイヤーＸ１が利用するプレイヤー端末２０を「プレイヤー端末Ａ１」とし、同じチームＡに所属するプレイヤーＸ２が利用するプレイヤー端末２０を「プレイヤー端末Ａ２」とし、異なるチームＢに所属するプレイヤーＹ１が利用するプレイヤー端末２０を「プレイヤー端末Ｂ１」とする。また、チームＡ及びチームＢは、チーム対戦で互いに競い合う相手チームとしてマッチングされていないものとする。

【0039】

先ず始めに、プレイヤー端末Ａ１は、メニュー画面が端末表示部２４に表示されている際に、プレイヤーＸ１による選択操作により、チーム対戦を開始するための操作ボタンが指定されると、かかる操作情報に基づき対戦開始を要求するコマンド（対戦開始要求）を、サーバー装置１０に送信する（ステップＳ１０１）。

【0040】

次いで、サーバー装置１０は、プレイヤー端末Ａ１から送信された対戦開始要求を受信すると、そのプレイヤーＸ１に対戦プレイを行わせるための対戦ゲーム画面のデータを、画面データ生成部１１５に生成させる（ステップＳ１０２）。そして、サーバー装置１０は、画面データ生成部１１５によって生成された対戦ゲーム画面のデータを、ネットワークを介して要求元のプレイヤー端末Ａ１に送信する。

【0041】

次いで、プレイヤー端末Ａ１は、サーバー装置１０から送信された画面データを受信すると、この画面データを解析することにより、対戦ゲーム画面を端末表示部２４に表示させる（ステップＳ１０３）。

【0042】

図１３は、対戦ゲーム画面５０の一例を示す図である。この対戦ゲーム画面５０には、エネミーキャラクター表示領域５１、プレイヤーキャラクター表示領域５２、攻撃を行なうための操作ボタン５３、応援依頼を行なうための操作ボタン５４が含まれている。エネミーキャラクター表示領域５１には、図６に示すチーム情報に基づいて、チームＡに対応付けられた共通エネミーキャラクター（つまり、プレイヤーＸ１に対応付けられた共通エネミーキャラクター）として、メインキャラクターやそのメインキャラクターを護衛するサブキャラクターが表示される。ここでは、メインキャラクターとしての「ボスＡ」のみが表示されている。またエネミーキャラクター表示領域５１には、その「ボスＡ」に対する連続攻撃ポイントが表示される。プレイヤーキャラクター表示領域５２には、プレイヤーＸ１のプレイヤーキャラクター（「キャラクターＦ」）や、プレイヤーＸ１が所属するチームＡの獲得スコアが表示される。ここでは、プレイヤーＸ１によって攻撃を行なうための操作ボタン５３が選択されたものとして、以降の説明を続ける。

【0043】

次いで、プレイヤー端末Ａ１は、対戦ゲーム画面５０が端末表示部２４に表示されている際に、プレイヤーＸ１のゲーム操作によって操作ボタン５３が選択されると（攻撃操作）、共通エネミーキャラクター（「ボスＡ」）への攻撃を要求するコマンド（攻撃要求）を、サーバー装置１０に送信する（ステップＳ１０４）。

【0044】

次いで、サーバー装置１０は、プレイヤー端末Ａ１から送信された攻撃要求を受信すると、その「ボスＡ」に関する対戦処理を実行する（ステップＳ１０５）。以下、この対戦処理について具体的に説明する。

【0045】

図１４は、本実施形態に係る対戦処理を説明するためのフローチャートである。
先ず、サーバー装置１０は、プレイヤーＸ１のバトルポイントが不足しているか否かを判定する（ステップＳ２０１）。具体的には、ゲーム進行処理部１１１は、プレイヤー端末Ａ１からの攻撃要求と共に送信されたプレイヤーＩＤ等に基づき、図４に示すプレイヤー情報を参照して、プレイヤーＸ１の所有するバトルポイントが１ポイント以上であるか否かを判定する。バトルポイントが不足している場合（つまり、０ポイントである場合）に（ステップＳ２０１：ＹＥＳ）、この処理を終了する。このとき、ポイント不足を指摘する画面表示を行なう。その一方で、バトルポイントが不足していない場合（つまり、１ポイント以上である場合）には（ステップＳ２０１：ＮＯ）、次のステップＳ２０２の処理に進む。

【0046】

次に、サーバー装置１０は、プレイヤーＸ１のバトルポイントが不足していない場合には、その「ボスＡ」に与えるダメージを計算する（ステップＳ２０２）。具体的には、ゲーム進行処理部１１１は、図５に示す所有プレイヤー情報及び図３に示すキャラクター情報に基づいて、プレイヤーＸ１のプレイヤーキャラクター（「キャラクターＦ」）の攻撃力パラメーター及び共通エネミーキャラクター（「ボスＡ」）の防御力パラメーター等に基づき共通エネミーキャラクター（「ボスＡ」）へ与えるダメージを算出する。この際、ゲーム進行処理部１１１は、図６に示すチーム情報を参照して、共通エネミーキャラクター（「ボスＡ」）に対する連続攻撃ポイントの大きさに応じて、プレイヤーＸ１のプレイヤーキャラクター（「キャラクターＦ」）の攻撃力パラメーターを増大させる。例えば、連続攻撃ポイントが２５ポイントであるときに、プレイヤーキャラクターの攻撃力パラメーターを１．７５倍にし、連続攻撃ポイントが５０ポイントであるときに、プレイヤーキャラクターの攻撃力パラメーターを３．５倍にし、連続攻撃ポイントが１００ポイントであるときに、プレイヤーキャラクターの攻撃力パラメーターを７倍にする。このように、ゲーム進行処理部１１１は、共通エネミーキャラクター（「ボスＡ」）に対する連続攻撃ポイントが増大するほど、当該共通エネミーキャラクターとの対戦でより有利になるように制御する。

【0047】

次に、サーバー装置１０は、プレイヤーＸ１が「ボスＡ」を倒したか否かを判定する（ステップＳ２０３）。具体的には、ゲーム進行処理部１１１は、その算出されたダメージに基づいて、「ボスＡ」の体力パラメーターを所定値以下まで減少させることができれば、「ボスＡ」を倒したものと判定する。かかる判定が肯定された場合に（ステップＳ２０３：ＹＥＳ）、次のステップＳ２０４に進む。これに対し、かかる判定が否定された場合は（ステップＳ２０３：ＮＯ）、ステップＳ２０６の処理に進む。

【0048】

次に、ゲーム進行処理部１１１は、「ボスＡ」を倒したと判定された場合に、プレイヤーＸ１が獲得した獲得スコアを付与する（ステップＳ２０４）。この際、図６に示すチーム情報に設定された獲得スコアが更新される。

【0049】

次に、ゲーム進行処理部１１１は、次の対戦相手となる新たな共通エネミーキャラクター（新たなボス）を設定し、図６に示すチーム情報に設定された共通エネミーキャラクターを更新する（ステップＳ２０５）。

【0050】

次に、サーバー装置１０は、プレイヤーＸ１による攻撃が応援依頼を受けたプレイヤーによる攻撃であるか否かを判定する（ステップＳ２０６）。すなわち、ゲーム進行処理部１１１は、図４に示すプレイヤー情報に設定された依頼状況を参照することにより、プレイヤーＸ１による攻撃が応援依頼を受けたプレイヤーによる攻撃であるか否かを判定する。

【0051】

そして、ゲーム進行処理部１１１は、かかる判定が否定された場合は（ステップＳ２０６：ＮＯ）、この処理を終了する。その一方で、かかる判定が肯定された場合には（ステップＳ２０６：ＹＥＳ）、プレイヤーＸ１に対して報酬としてのコインを付与する（ステップＳ２０７）。この際、ゲーム進行処理部１１１は、図４に示すプレイヤー情報に設定されたコイン枚数を更新する。

【0052】

次いで、図１２に戻り、サーバー装置１０は、このようにして「ボスＡ」に関する対戦処理が行われると、ポイント変動処理を実行する（ステップＳ１０６）。以下、このポイント変動処理について具体的に説明する。

【0053】

図１５は、本実施形態に係るポイント変動処理を説明するためのフローチャートである。
先ず、サーバー装置１０は、プレイヤーＸ１による攻撃がボス以外への攻撃であるか否かを判定する（ステップＳ３０１）。すなわち、ポイント変動処理部１１３は、図６に示すチーム情報に基づいて、メインキャラクター及びサブキャラクターのうちのメインキャラクター以外（つまりサブキャラクター）への攻撃であるか否かを判定する。かかる判定が肯定された場合に（ステップＳ３０１：ＹＥＳ）、連続攻撃ポイントを変動させることなく、この処理を終了する。すなわち、仮に、プレイヤーＸ１に対応付けられた共通エネミーキャラクターとして「ボスＡ」以外にも、サブキャラクターが設定されている場合には、プレイヤーＸ１によって攻撃操作が行われると、優先的にサブキャラクターに対する攻撃が行われる。このようにサブキャラクターに対する攻撃が行われる場合には、「ボスＡ」に対する攻撃を行なうことができないので、「ボスＡ」に対する連続攻撃ポイントは変動しないことになる。これに対し、かかる判定が否定された場合には（ステップＳ３０１：ＮＯ）、次のステップＳ３０２の処理に進む。

【0054】

次に、サーバー装置１０は、ボスへの攻撃であると判定された場合に、プレイヤーＸ１による攻撃がボスへの初回攻撃であるか否かを判定する（ステップＳ３０２）。すなわち、ポイント変動処理部１１３は、図７に示す攻撃ログ情報に基づいて、プレイヤーＸ１による攻撃が初回攻撃であるか否かを判定する。かかる判定が肯定された場合に（ステップＳ３０２：ＹＥＳ）、ステップＳ３０８の処理に進む。これに対し、かかる判定が否定された場合には（ステップＳ３０２：ＮＯ）、次のステップＳ３０３の処理に進む。

【0055】

次に、サーバー装置１０は、ボスへの初回攻撃でないと判定された場合に、プレイヤーＸ１の攻撃によりボスが倒されたか否かを判定する（ステップＳ３０３）。すなわち、ポイント変動処理部１１３は、図１４のステップＳ２０３における判定結果に基づき、プレイヤーＸ１の攻撃によって「ボスＡ」が倒されたか否かを判定する。かかる判定が肯定された場合に（ステップＳ３０３：ＹＥＳ）、「ボスＡ」に対する連続攻撃ポイントをリセットした上で（ステップＳ３０４）、ステップＳ３０８の処理へ進む。これに対し、かかる判定が否定された場合には（ステップＳ３０３：ＮＯ）、ステップＳ３０５の処理に進む。

【0056】

次に、サーバー装置１０は、「ボスＡ」が倒されていないと判定された場合に、前回の攻撃操作を行なったプレイヤーと同じプレイヤーであるか否かを判定する（ステップＳ３０５）。すなわち、ポイント変動処理部１１３は、図７に示す攻撃ログ情報に基づいて、プレイヤーＸ１が前回の攻撃操作を行なったプレイヤーであるか否かを判定する。かかる判定が肯定された場合に（ステップＳ３０５：ＹＥＳ）、プレイヤーＸ１が単独で連続攻撃を行なったことになるため、「ボスＡ」に対する連続攻撃ポイントを変動させることなく、ステップＳ３０８の処理に進む。これに対し、かかる判定が否定された場合には（ステップＳ３０５：ＮＯ）、次のステップＳ３０６の処理に進む。

【0057】

次に、サーバー装置１０は、前回の攻撃操作を行なったプレイヤーと同じプレイヤーでないと判定された場合に、前回の攻撃操作が行われてから一定期間（例えば３０分）が経過したか否かを判定する（ステップＳ３０６）。すなわち、ポイント変動処理部１１３は、図７に示す攻撃ログ情報に基づいて、他のプレイヤーによって前回の攻撃操作が行われてからプレイヤーＸ１によって今回の攻撃操作が行われるまでに、３０分が経過しているか否かを判定する。かかる判定が肯定された場合に（ステップＳ３０６：ＹＥＳ）、時間経過によって連続攻撃が途絶えたものとみなし、「ボスＡ」に対する連続攻撃ポイントをリセットした上で（ステップＳ３０４）、ステップＳ３０７の処理へ進む。これに対し、かかる判定が否定された場合には（ステップＳ３０６：ＮＯ）、次のステップＳ３０７の処理に進む。

【0058】

次に、サーバー装置１０は、３０分が経過していないと判定された場合に、ボスに対する連続攻撃ポイントを増やす（ステップＳ３０７）。すなわち、ポイント変動処理部１１３は、プレイヤーＸ１による攻撃に対するポイント量を決定し、「ボスＡ」に対する連続攻撃ポイントに加算する。例えば、プイレヤーＸ１がボーナスタイムに攻撃操作を行なった場合には、通常のポイント量に対して２倍のポイント量を加算する。この際、ポイント変動処理部１１３は、図６に示すチーム情報に設定された連続攻撃ポイントの数量を更新する。

【0059】

次に、サーバー装置１０は、応援依頼を受けたプレイヤーによる攻撃操作であるか否かを判定する（ステップＳ３０８）。すなわち、ポイント変動処理部１１３は、図４に示すプレイヤー情報に設定された依頼状況を参照することにより、プレイヤーＸ１が応援依頼を受けたプレイヤーであるか否かを判定する。かかる判定が肯定された場合に（ステップＳ３０８：ＹＥＳ）、ポイント変動処理部１１３は、応援依頼を受けたプレイヤーによる攻撃に対するポイント量を決定し、依頼元のプレイヤーに対応付けられた他のボスに対する連続攻撃ポイントに加算する（ステップＳ３０９）。この際、ポイント変動処理部１１３は、依頼元のプレイヤーが所属する他のチームのチーム情報（図６参照）に設定された連続攻撃ポイントを更新する。これに対し、かかる判定が否定された場合には（ステップＳ３０８：ＮＯ）、連続攻撃ポイントを変動させることなく、この処理を終了する。

【0060】

次いで、図１２に戻り、サーバー装置１０は、このようにしてポイント変動処理が行われると、対戦結果を示す結果画面のデータを画面データ生成部１１５に生成させる（ステップＳ１０７）。そして、サーバー装置１０は、画面データ生成部１１５によって生成された結果画面のデータを、ネットワークを介して要求元のプレイヤー端末Ａ１に送信する。その後、プレイヤー端末Ａ１は、サーバー装置１０から送信された画面データを受信すると、この画面データを解析することにより、結果画面を端末表示部２４に表示させる（ステップＳ１０８）。

【0061】

引き続き、同じチームＡに所属するプレイヤーＸ２による攻撃操作が連続して行われた場合について説明する。

【0062】

その後、プレイヤー端末Ａ２は、メニュー画面が端末表示部２４に表示されている際に、プレイヤーＸ２による選択操作により、チーム対戦を開始するための操作ボタンが指定されると、かかる操作情報に基づき対戦開始を要求するコマンド（対戦開始要求）を、サーバー装置１０に送信する（ステップＳ１０９）。

【0063】

次いで、サーバー装置１０は、プレイヤー端末Ａ２から送信された対戦開始要求を受信すると、そのプレイヤーＸ２に対戦プレイを行わせるための対戦ゲーム画面のデータを、画面データ生成部１１５に生成させる（ステップＳ１１０）。そして、サーバー装置１０は、画面データ生成部１１５によって生成された対戦ゲーム画面のデータを、ネットワークを介して要求元のプレイヤー端末Ａ２に送信する。

【0064】

次いで、プレイヤー端末Ａ２は、サーバー装置１０から送信された画面データを受信すると、この画面データを解析することにより、対戦ゲーム画面を端末表示部２４に表示させる（ステップＳ１１１）。

【0065】

次いで、プレイヤー端末Ａ２は、図１３に示す対戦ゲーム画面５０が端末表示部２４に表示されている際に、プレイヤーＸ２のゲーム操作によって操作ボタン５３が選択されると（攻撃操作）、共通エネミーキャラクター（「ボスＡ」）への攻撃を要求するコマンド（攻撃要求）を、サーバー装置１０に送信する（ステップＳ１１２）。

【0066】

次いで、サーバー装置１０は、プレイヤー端末Ａ２から送信された攻撃要求を受信すると、その「ボスＡ」に関する対戦処理を実行する（ステップＳ１１３）。この対戦処理についての具体的な説明は、上述したとおりである。

【0067】

次いで、サーバー装置１０は、このようにして「ボスＡ」に関する対戦処理が行われると、ポイント変動処理を実行する（ステップＳ１１４）。このポイント変動処理についての具体的な説明は、上述したとおりである。ただし、図１５のステップＳ３０５の処理では、今回の攻撃操作を行なったプレイヤーＸ２は、前回の攻撃操作を行なったプレイヤーＸ１と異なるプレイヤーであるため、かかる判定は否定されることになる。そのため、図１５のステップＳ３０６の処理にて、プレイヤーＸ１によって前回の攻撃操作が行われてからプレイヤーＸ２によって今回の攻撃操作が行われるまでに３０分が経過していないと判定されれば、図１５のステップＳ３０７の処理では、「ボスＡ」に対する連続攻撃ポイントが加算されることになる。

【0068】

次いで、サーバー装置１０は、このようにしてポイント変動処理が行われると、対戦結果を示す結果画面のデータを画面データ生成部１１５に生成させる（ステップＳ１１５）。そして、サーバー装置１０は、画面データ生成部１１５によって生成された結果画面のデータを、ネットワークを介して要求元のプレイヤー端末Ａ２に送信する。その後、プレイヤー端末Ａ２は、サーバー装置１０から送信された画面データを受信すると、この画面データを解析することにより、結果画面を端末表示部２４に表示させる（ステップＳ１１６）。

【0069】

ここで、チームＡに所属するプレイヤーＸ１による応援依頼操作が行われた場合について説明する。

【0070】

引き続き、プレイヤー端末Ａ１は、図１３に示す対戦ゲーム画面５０が端末表示部２４に表示されている際に、プレイヤーＸ１のゲーム操作によって操作ボタン５４が選択されると（応援依頼操作）、応援依頼を要求するコマンド（応援依頼要求）を、サーバー装置１０に送信する（ステップＳ１１７）。

【0071】

次いで、サーバー装置１０は、プレイヤー端末Ａ１から送信された応援依頼要求を受信すると、依頼先決定処理を実行する（ステップＳ１１８）。以下、この依頼先決定処理について具体的に説明する。

【0072】

図１６は、本実施形態に係る依頼先決定処理を説明するためのフローチャートである。

【0073】

先ず、サーバー装置１０は、チーム内の他のプレイヤーによってすでに応援依頼操作が行われているか否かを判定する（ステップＳ４０１）。すなわち、依頼先決定処理部１１４は、図８に示す依頼ログ情報に基づいて、プレイヤーＸ１が応援依頼操作を行なう前に、プレイヤーＸ１が所属するチーム内の他のプレイヤーがすでに応援依頼操作を行なっているか否かを判定する。かかる判定が否定された場合に（ステップＳ４０１：ＮＯ）、ステップＳ４０４の処理に進む。その一方で、かかる判定が肯定された場合には（ステップＳ４０１：ＹＥＳ）、次のステップＳ４０２の処理に進む。

【0074】

次に、サーバー装置１０は、他のプレイヤーによってすでに応援依頼操作が行われていると判定された場合に、前回の応援依頼操作が行われてから一定期間（例えば５分）が経過したか否かを判定する（ステップＳ４０２）。すなわち、依頼先決定処理部１１４は、図８に示す依頼ログ情報に基づいて、他のプレイヤーによって前回の応援依頼操作が行われてからプレイヤーＸ１によって今回の応援依頼操作が行われるまでに、５分が経過しているか否かを判定する。かかる判定が肯定された場合に（ステップＳ４０２：ＹＥＳ）、ステップＳ４０４の処理に進む。その一方で、かかる判定が否定された場合には（ステップＳ４０２：ＮＯ）、次のステップＳ４０３の処理に進む。

【0075】

次に、サーバー装置１０は、５分が経過していないと判定された場合に、前回の応援依頼時に決定された依頼先のプレイヤーすべてが応援済みであるか否かを判定する（ステップＳ４０３）。すなわち、依頼先決定処理部１１４は、図９に示す依頼先情報を参照して、依頼先のプレイヤーすべてを特定する。そして、依頼先決定処理部１１４は、図４に示すプレイヤー情報に設定された依頼状況を参照することにより、各々の依頼先のプレイヤーが、応援依頼を受けている状態であるのか、又は、応援済みの状態であるかを判定する。かかる判定が否定された場合に（ステップＳ４０３：ＮＯ）、新たに依頼先のプレイヤーを決定することなく、この処理を終了する。その一方で、かかる判定が肯定された場合には（ステップＳ４０３：ＹＥＳ）、次のステップＳ４０４の処理に進む。

【0076】

次に、サーバー装置１０は、第１条件に従って依頼先となるプレイヤーを抽出する（ステップＳ４０４）。第１条件は、依頼元のプレイヤーと関係を持つプレイヤーであること、アクティブなプレイヤーであること、依頼元のプレイヤーと同じチームに所属するプレイヤーでないこと、及び、競い合う相手チームに所属するプレイヤーでないこと、のすべてに該当することである。具体的には、依頼先決定処理部１１４は、図４に示すプレイヤー情報を参照することにより、プレイヤーＸ１のフレンドプレイヤーを抽出する。次に、依頼先決定処理部１１４は、図４に示すプレイヤー情報を参照することにより、その抽出されたフレンドプレイヤーの中で、アクティブであるフレンドプレイヤーを抽出する。そして、依頼先決定処理部１１４は、図６に示すチーム情報を参照することにより、その抽出されたアクティブであるフレンドプレイヤーの中で、プレイヤーＸ１と同じチームに所属していないプレイヤーを抽出する。さらに、依頼先決定処理部１１４は、その抽出されたアクティブである別チームのフレンドプレイヤーの中で、図１０に示すマッチング情報を参照することにより、プレイヤーＸ１の所属するチームの相手チームに所属していないプレイヤーを抽出する。そして、依頼先決定処理部１１４は、この時点で１０人以上のプレイヤーが抽出された場合には、図４に示すプレイヤー情報を参照して、応援依頼を受けて攻撃を行なったことによってコインを獲得できた回数（報酬が付与された回数）が少ないプレイヤーから順番に、１０人のプレイヤーを依頼先のプレイヤーとして選出する。なお、図７に示す攻撃ログ情報を参照して、攻撃回数が少ないプレイヤーから順番に、１０人のプレイヤーを依頼先のプレイヤーとして選出しても良い。

【0077】

次に、サーバー装置１０は、第１条件に従って依頼先となるプレイヤーを決定できたか否かを判定する（ステップＳ４０５）。すなわち、依頼先決定処理部１１４は、上述したステップＳ４０４の処理によって１０人のプレイヤーを選出できたか否かを判定する。１０人のプレイヤーを選出できた場合は（ステップＳ４０５：ＹＥＳ）、この処理を終了する。その一方で、１０人のプレイヤーを選出できなかった場合には（ステップＳ４０５：ＮＯ）、次のステップ４０６の処理に進む。

【0078】

次に、サーバー装置１０は、１０人のプレイヤーを選出できなかった場合に、第２条件に従って依頼先となるプレイヤーを抽出する（ステップＳ４０６）。第２条件は、依頼元のプレイヤーと関係を持たないプレイヤーであること、アクティブなプレイヤーであること、依頼元のプレイヤーと同じチームに所属するプレイヤーでないこと、及び、競い合う相手チームに所属するプレイヤーでないこと、のすべてに該当することである。すなわち、依頼先決定処理部１１４は、上述したステップＳ４０４と同様にして、１０人の依頼先のプレイヤーに達するように不足分のプレイヤーを選出する。

【0079】

次に、サーバー装置１０は、第２条件に従って依頼先となるプレイヤーを決定できたか否かを判定する（ステップＳ４０７）。すなわち、依頼先決定処理部１１４は、上述したステップＳ４０６の処理により、不足分を補うことで１０人のプレイヤーを選出できたか否かを判定する。かかる判定が肯定された場合は（ステップＳ４０７：ＹＥＳ）、この処理を終了する。その一方で、かかる判定が否定された場合には（ステップＳ４０７：ＮＯ）、次のステップ４０８の処理に進む。

【0080】

次に、サーバー装置１０は、不足分を補っても１０人のプレイヤーを選出できなかった場合に、第３条件に従って依頼先となるプレイヤーを抽出する（ステップＳ４０８）。第３条件は、依頼元のプレイヤーと関係を持つプレイヤーであること、非アクティブなプレイヤーであること、依頼元のプレイヤーと同じチームに所属するプレイヤーでないこと、及び、競い合う相手チームに所属するプレイヤーでないこと、のすべてに該当することである。すなわち、依頼先決定処理部１１４は、上述したステップＳ４０４と同様にして、１０人の依頼先のプレイヤーに達するように不足分のプレイヤーを選出する。

【0081】

次に、サーバー装置１０は、第３条件に従って依頼先となるプレイヤーを決定できたか否かを判定する（ステップＳ４０９）。すなわち、依頼先決定処理部１１４は、上述したステップＳ４０８の処理により、不足分を補うことで１０人のプレイヤーを選出できたか否かを判定する。かかる判定が肯定された場合は（ステップＳ４０９：ＹＥＳ）、この処理を終了する。その一方で、かかる判定が否定された場合には（ステップＳ４０９：ＮＯ）、次のステップＳ４１０の処理に進む。

【0082】

次に、サーバー装置１０は、不足分を補っても１０人のプレイヤーを選出できなかった場合に、第４条件に従って依頼先となるプレイヤーを抽出する（ステップＳ４１０）。第４条件は、依頼元のプレイヤーと関係を持たないプレイヤーであること、非アクティブなプレイヤーであること、依頼元のプレイヤーと同じチームに所属するプレイヤーでないこと、及び、競い合う相手チームに所属するプレイヤーでないこと、のすべてに該当することである。すなわち、依頼先決定処理部１１４は、上述したステップＳ４０４と同様にして、１０人の依頼先のプレイヤーに達するように不足分のプレイヤーを選出する。

【0083】

次に、サーバー装置１０は、第４条件に従って依頼先となるプレイヤーを決定できたか否かを判定する（ステップＳ４１１）。すなわち、依頼先決定処理部１１４は、上述したステップＳ４１０の処理により、不足分を補うことで１０人のプレイヤーを選出できたか否かを判定する。かかる判定が肯定された場合は（ステップＳ４１１：ＹＥＳ）、この処理を終了する。その一方で、かかる判定が否定された場合には（ステップＳ４１１：ＮＯ）、上述したステップＳ４０４の処理に戻り、それ以降の処理を繰り返し行う。なお、ステップＳ４１１の処理における判定が否定された場合には、この処理を終了し、応援依頼が失敗に終わったものとみなしても良い。

【0084】

このようにして依頼先となる１０人のプレイヤーが選出されると、チームＡの依頼先情報（図９参照）が更新される。

【0085】

以下では、このようにしてチームＡに所属するプレイヤーＸ１による応援依頼操作が行われた結果、異なるチームＢに所属するプレイヤーＹ１が依頼先のプレイヤーとして決定された場合について説明する。

【0086】

その後、プレイヤー端末Ｂ１は、メニュー画面が端末表示部２４に表示されている際に、プレイヤーＹ１による選択操作により、チーム対戦を開始するための操作ボタンが指定されると、かかる操作情報に基づき対戦開始を要求するコマンド（対戦開始要求）を、サーバー装置１０に送信する（ステップＳ１１９）。

【0087】

次いで、サーバー装置１０は、プレイヤー端末Ｂ１から送信された対戦開始要求を受信すると、そのプレイヤーＹ１に対戦プレイを行わせるための対戦ゲーム画面のデータを、画面データ生成部１１５に生成させる（ステップＳ１２０）。そして、サーバー装置１０は、画面データ生成部１１５によって生成された対戦ゲーム画面のデータを、ネットワークを介して要求元のプレイヤー端末Ｂ１に送信する。

【0088】

次いで、プレイヤー端末Ｂ１は、サーバー装置１０から送信された画面データを受信すると、この画面データを解析することにより、対戦ゲーム画面を端末表示部２４に表示させる（ステップＳ１２１）。

【0089】

図１７は、対戦ゲーム画面６０の一例を示す図である。この対戦ゲーム画面６０には、エネミーキャラクター表示領域６１、プレイヤーキャラクター表示領域６２、攻撃を行なうための操作ボタン６３、応援依頼を行なうための操作ボタン６４が含まれている。エネミーキャラクター表示領域６１には、メインキャラクターとしての「ボスＢ」が表示されている。またエネミーキャラクター表示領域６１には、その「ボスＢ」に対する連続攻撃ポイントが表示される。プレイヤーキャラクター表示領域６２には、プレイヤーＹ１のプレイヤーキャラクター（「キャラクターＣ」）が表示されている。操作ボタン６３には、プレイヤーＹ１が依頼先のプレイヤーとして決定されているため、応援依頼を受けたことを示す表示がなされている。依頼先となるプレイヤーＹ１は、操作ボタン６３を押すことで、「ボスＢ」への攻撃を行なうと共に、依頼元となるプレイヤーＸ１を応援したことになる。

【0090】

次いで、プレイヤー端末Ｂ１は、図１７に示す対戦ゲーム画面６０が端末表示部２４に表示されている際に、プレイヤーＹ１のゲーム操作によって操作ボタン６３が選択されると（攻撃操作）、共通エネミーキャラクター（「ボスＢ」）への攻撃を要求するコマンド（攻撃要求）を、サーバー装置１０に送信する（ステップＳ１２２）。

【0091】

次いで、サーバー装置１０は、プレイヤー端末Ｂ１から送信された攻撃要求を受信すると、その「ボスＢ」に関する対戦処理を実行する（ステップＳ１２３）。この対戦処理についての具体的な説明は、上述したとおりである。ただし、図１４のステップＳ２０６の処理では、今回の攻撃操作を行なったプレイヤーＹ１は、応援依頼を受けたプレイヤーであるため、かかる判定は肯定されることになる。そのため、図１４のステップＳ２０７の処理では、プレイヤーＹ１には報酬としてのコインが付与されることになる。

【0092】

次いで、サーバー装置１０は、このようにして「ボスＢ」に関する対戦処理が行われると、ポイント変動処理を実行する（ステップＳ１２４）。このポイント変動処理についての具体的な説明は、上述したとおりである。ただし、図１５のステップＳ３０８の処理では、今回の攻撃操作を行なったプレイヤーＹ１は、応援依頼を受けたプレイヤーであるため、かかる判定は肯定されることになる。そのため、図１５のステップＳ３０７の処理にて、「ボスＢ」に対する連続攻撃ポイントが加算されると共に、図１５のステップＳ３０９の処理では、依頼元のプレイヤーＸ１が対戦する「ボスＡ」に対する連続攻撃ポイントが加算されることになる。このことにより、仮に、チームＡに対して「ボスＡ」の他にもサブキャラクターが出現した場合、依頼元のプレイヤーＸ１が攻撃操作を行なっても、サブキャラクターへの攻撃が優先されるため、「ボスＡ」に対する攻撃操作を行なうことができず、「ボスＡ」に対する連続攻撃ポイントを増やすことができない。しかし、依頼先のプレイヤーＹ１が「ボスＢ」に対する攻撃操作を行なうことで、プレイヤーＸ１が「ボスＡ」に対する攻撃操作を行なうことなく、「ボスＡ」に対する連続攻撃ポイントを増やすことが可能となる。

【0093】

次いで、サーバー装置１０は、このようにしてポイント変動処理が行われると、対戦結果を示す結果画面のデータを画面データ生成部１１５に生成させる（ステップＳ１２５）。そして、サーバー装置１０は、画面データ生成部１１５によって生成された結果画面のデータを、ネットワークを介して要求元のプレイヤー端末Ｂ１に送信する。その後、プレイヤー端末Ｂ１は、サーバー装置１０から送信された画面データを受信すると、この画面データを解析することにより、結果画面を端末表示部２４に表示させる（ステップＳ１２６）。

【0094】

以上のとおり、本実施形態に係るゲームシステム１によれば、依頼元となるプレイヤーＸ１は、同じ「ボスＡ」が対応付けられた複数プレイヤー（チームＡに所属するプレイヤー）が参戦できない状況にあっても、異なる他のボス（例えば「ボスＢ」）が対応付けられた複数プレイヤー（例えばチームＢに所属するプレイヤーＹ１）に対して応援依頼を行なうことで、自己の「ボスＡ」に対する連続攻撃ポイントの増大が期待できる。また、依頼先となるプレイヤーＹ１は、依頼元となるプレイヤーＸ１に対応付けられた「ボスＡ」ではなく、自己に対応付けられた他の「ボスＢ」に対する攻撃を行なうことで、依頼元となるプレイヤーＸ１に対応付けられた「ボスＡ」に対する連続攻撃ポイントの増大に無理なく貢献できる。その結果、連続攻撃ポイントを簡単に増やせるようになるため、プレイ意欲を向上させることができ、ひいては多人数参加型の対戦ゲームを活性化させることが可能となる。

【0095】

＝＝＝その他の実施形態＝＝＝
上記の実施の形態は、本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更、改良され得ると共に、本発明にはその等価物も含まれる。特に、以下に述べる実施形態であっても、本発明に含まれるものである。

【0096】

＜連続攻撃ポイントの変動＞
上記の本実施形態では、連続攻撃ポイントを増大させる場合を例に挙げて説明したが、連続攻撃ポイントを減少させても良い。例えば、マッチングによってチームＡとチームＣが互いに競い合う相手チームとして設定された場合に、チームＣのプレイヤー、又は、チームＣのプレイヤーから応援依頼を受けたプレイヤーが、自己に対応付けられた共通エネミーキャラクターに攻撃する度に、チームＡのプレイヤーが対戦する共通エネミーキャラクターに対する連続攻撃ポイントを減少させても良い。これにより、相手チームの連続攻撃ポイントの増大を妨害できるため、チーム対戦を活性化させることが可能となる。

【0097】

また上記の実施形態では、図１５に示すように、依頼先のプレイヤーＹ１が「ボスＢ」に対する攻撃操作を行なうことで、依頼元のプレイヤーＸ１が攻撃を行なう「ボスＡ」に対する連続攻撃ポイントを増やす共に、自己の攻撃する「ボスＢ」に対する連続攻撃ポイントをも増やすことができる場合を例に挙げて説明したが、依頼元のプレイヤーＸ１が攻撃を行なう「ボスＡ」に対する連続攻撃ポイントのみを増やしても良い。この他にも、依頼先のプレイヤーＹ１が「ボスＢ」に攻撃を行なって勝利した場合に、「ボスＡ」に対する連続攻撃ポイントを特別加算しても良い。

【0098】

＜依頼先決定＞
上記の本実施形態では、図１６に示すように、第１条件から第４条件に適合するプレイヤーを抽出する場合を例に挙げて説明したが、本発明はこれに限定されるものではない。例えば、依頼先決定処理部１１４は、条件に合う複数プレイヤーを抽出するのではなく、予め設定された複数プレイヤーを依頼先となるプレイヤーに決定しても良い。

【0099】

＜応援依頼＞
上記の本実施形態では、依頼元のプレイヤーが応援依頼操作を行なうことによって、依頼先となるプレイヤーを決定する依頼先決定処理が実行される場合を例に挙げて説明したが、プレイヤーの操作によらず、自動的に応援依頼を行なえるようにしても良い。具体的には、依頼先決定処理部１１４は、対戦開始後における所定のタイミングで、依頼先となるプレイヤーを自動的に決定しても良い。また、依頼先決定処理部１１４は、所定条件が成立したと判定したときに（例えば、チーム内の半数以上のプレイヤーが非アクティブの状態であると判定したときに）、依頼先となるプレイヤーを自動的に決定しても良い。

【0100】

＜ゲームコンテンツ＞
上記の本実施形態では、キャラクターカードを例に挙げて説明したが、本発明はこれに限定されるものではない。例えば、ゲームコンテンツは、電子的なゲームデータであれば良く、キャラクター自体、フィギュア、ゲームで使用される道具・アビリティ等のアイテムなどであっても良い。

【0101】

＜サーバー装置＞
上記の本実施形態では、サーバー装置の一例として１台のサーバー装置１０を備えたゲームシステム１を例に挙げて説明したが、これに限らず、サーバー装置の一例として複数台のサーバー装置１０を備えたゲームシステム１としても良い。すなわち、複数台のサーバー装置１０がネットワーク２を介して接続され、各サーバー装置１０が各種処理を分散して行うようにしても良い。なお、サーバー装置１０はコンピューターの一例である。

【0102】

＜情報処理装置＞
上記の本実施形態におけるゲームシステム１では、ゲームプログラムに基づきサーバー装置１０及びプレイヤー端末２０を協働させて各種情報処理を実行する場合を例に挙げて説明したが、これに限定されるものではなく、情報処理装置としてのプレイヤー端末２０単体、または、サーバー装置１０単体が、ゲームプログラムに基づき上記の各種情報処理を実行するようにしても良い。
また、情報処理装置としての機能の一部をプレイヤー端末２０が担う構成としても良い。この場合には、サーバー装置１０及びプレイヤー端末２０が情報処理装置を構成する。
なお、情報処理装置はプロセッサー及びメモリを備えるコンピューターの一例である。

【符号の説明】

【0103】

１ ゲームシステム、２ ネットワーク、１０ サーバー装置、１１ 制御部、１２ 記憶部、１３ 入力部、１４ 表示部、１５ 通信部、２０ プレイヤー端末、２１ 端末制御部、２２ 端末記憶部、２３ 端末入力部、２４ 端末表示部、２５ 端末通信部、５０ 対戦ゲーム画面、５１ エネミーキャラクター表示領域、５２ プレイヤーキャラクター表示領域、５３ 操作ボタン、５４ 操作ボタン、６０ 対戦ゲーム画面、６１ エネミーキャラクター表示領域、６２ プレイヤーキャラクター表示領域、６３ 操作ボタン、６４ 操作ボタン、１１１ ゲーム進行処理部、１１２ マッチング処理部、１１３ ポイント変動処理部、１１４ 依頼先決定処理部、１１５ 画面データ生成処理部

【要約】

【課題】多人数参加型ゲームを活性化させる。
【解決手段】本発明に係る情報処理装置は、共通エネミーキャラクターが対応付けられた複数プレイヤーによる攻撃が連続的に行われる度に、共通エネミーキャラクターに対する連続攻撃ポイントを増加させるポイント変動処理部と、共通エネミーキャラクターに対する連続攻撃ポイントが増大するほど、共通エネミーキャラクターとの対戦がより有利になるように制御するゲーム進行処理部と、共通エネミーキャラクターが対応付けられた依頼元のプレイヤーからの応援依頼を受ける依頼先のプレイヤーを決定する依頼先決定処理部と、を備える。ポイント変動処理部は、依頼先のプレイヤーが自己に対応付けられた他の共通エネミーキャラクターに対する攻撃を行なうと、依頼元のプレイヤーに対応付けられた共通エネミーキャラクターに対する連続攻撃ポイントを増加させる。
【選択図】図１

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】