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

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

▶ 株式会社コナミデジタルエンタテインメントの特許一覧

(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022118270
(43)【公開日】2022-08-12
(54)【発明の名称】ゲームシステム、及びプログラム
(51)【国際特許分類】
   A63F 13/847 20140101AFI20220804BHJP
   A63F 13/55 20140101ALI20220804BHJP
   A63F 13/58 20140101ALI20220804BHJP
   A63F 13/45 20140101ALI20220804BHJP
【FI】
A63F13/847
A63F13/55
A63F13/58
A63F13/45
【審査請求】有
【請求項の数】1
【出願形態】OL
(21)【出願番号】P 2022102896
(22)【出願日】2022-06-27
(62)【分割の表示】P 2020041772の分割
【原出願日】2017-06-09
(71)【出願人】
【識別番号】506113602
【氏名又は名称】株式会社コナミデジタルエンタテインメント
(72)【発明者】
【氏名】小池 雅明
(57)【要約】
【課題】チーム対戦型のアクションゲームにおいて、チーム内の協力の機会をより多くすること。
【解決手段】ゲームシステムは、チームに属するユーザ情報により識別されるユーザ毎の操作に基づいて、チーム内で共通のフィールド内でユーザ情報毎に関連付けられたキャラクタを活動させるキャラクタ制御部と、第1状態のキャラクタについて所定の第1条件が満たされることを条件として該キャラクタを第1状態よりも能力が低下した第2状態に遷移させ、第2状態のキャラクタについて所定の第2条件が満たされることを条件として該キャラクタの活動が制限される第3状態に遷移させるキャラクタ状態制御部と、第2状態のキャラクタを、該キャラクタと同じチームに属する他のキャラクタに基づいて第1状態に復活させる復活制御部と、キャラクタ制御部によりキャラクタが活動した結果に基づいて、チームの勝敗を判定する勝敗判定部と、を備える。
【選択図】図7
【特許請求の範囲】
【請求項1】
チームに属するユーザ情報により識別されるユーザ毎の操作に基づいて、前記チーム内に共通のフィールド内で前記ユーザ情報毎に関連付けられたキャラクタを活動させるキャラクタ制御部と、
第1状態の前記キャラクタについて所定の第1条件が満たされることを条件として該キャラクタを前記第1状態よりも能力が低下した第2状態に遷移させ、前記第2状態の前記キャラクタについて所定の第2条件が満たされることを条件として該キャラクタの活動が制限される第3状態に遷移させるキャラクタ状態制御部と、
前記第2状態の前記キャラクタを、該キャラクタと同じチームに属する他の前記キャラクタに基づいて前記第1状態に復活させる復活制御部と、
前記キャラクタ制御部により前記キャラクタが活動した結果に基づいて、前記チームの勝敗を判定する勝敗判定部と、
を備えるゲームシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ゲームシステム、及びプログラムに関する。
【背景技術】
【0002】
複数のユーザのそれぞれが操作するキャラクタが敵キャラクタと戦闘しながらゲームを進行させるアクションゲームがある(例えば、特許文献1)。例えば、チーム対戦型の場合には、チームメンバーの協力が戦闘を有利に進めるための重要な要素となっている。一般的に、ユーザが操作するキャラクタが対戦相手からの攻撃によりダメージを受けて死亡すると、一定時間対戦に参加できなかったり、次の対戦まで参加できなかったり、或いは、対戦相手に多くのポイントが付与されるなど、当該ユーザとしてもチームとしても大きな代償を払うことになる。そのため、チームメンバーのキャラクタが死亡に至らないようにチーム内で協力してプレイを行うこととなる。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2010-207404号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、チーム内で協力したとしても、チームメンバーのキャラクタが1体も死亡に至らずにプレイを続けていけるとは限らない。自分が操作しているキャラクタが死亡すると、そのユーザは、一定時間チームに貢献できなくなり、モチベーションが低下してしまうことがあった。
【0005】
本発明のいくつかの態様は、チーム対戦型のアクションゲームにおいて、チーム内の協力の機会がより多いゲームシステム、及びプログラムを提供することを目的の一つとする。
【0006】
また、本発明の他の態様は、後述する実施形態に記載した作用効果を奏することを可能にするゲームシステム、及びプログラムを提供することを目的の一つとする。
【課題を解決するための手段】
【0007】
上述した課題を解決するために、本発明の一態様は、チームに属するユーザ情報により識別されるユーザ毎の操作に基づいて、前記チーム内で共通のフィールド内で前記ユーザ情報毎に関連付けられたキャラクタを活動させるキャラクタ制御部と、第1状態の前記キャラクタについて所定の第1条件が満たされることを条件として該キャラクタを前記第1状態よりも能力が低下した第2状態に遷移させ、前記第2状態の前記キャラクタについて所定の第2条件が満たされることを条件として該キャラクタの活動が制限される第3状態に遷移させるキャラクタ状態制御部と、前記第2状態の前記キャラクタを、該キャラクタと同じチームに属する他の前記キャラクタに基づいて前記第1状態に復活させる復活制御部と、前記キャラクタ制御部により前記キャラクタが活動した結果に基づいて、前記チームの勝敗を判定する勝敗判定部と、を備えるゲームシステムである。
【0008】
また、本発明の一態様は、コンピュータを、上記のゲームシステムとして機能させるためのプログラムである。
【図面の簡単な説明】
【0009】
図1】第1の実施形態に係るフィールドの一例を示す図。
図2】第1の実施形態に係る通常部屋におけるプレイ画面の一例を示す図。
図3】第1の実施形態に係るボス部屋におけるプレイ画面の一例を示す図。
図4】第1の実施形態に係るゲームシステムの構成の一例を示すブロック図。
図5】第1の実施形態に係るゲーム装置のハードウェア構成の一例を示す図。
図6】第1の実施形態に係るゲームサーバのハードウェア構成の一例を示す図。
図7】第1の実施形態に係るゲーム装置及びゲームサーバの構成の一例を示すブロック図。
図8】第1の実施形態に係る占拠判定処理の一例を示すフローチャート。
図9】第1の実施形態に係る勝敗判定処理の第一例を示すフローチャート。
図10】第1の実施形態に係る勝敗判定処理の第二例を示すフローチャート。
図11】第1の実施形態に係る部屋占拠時に付与されるポイントの一例を示す図。
図12】第1の実施形態に係る占拠済みの部屋数とボーナス係数の設定の一例を示す図。
図13】第2の実施形態に係る通常NPCの出現方法の設定例を示す図。
図14】第3の実施形態に係る通常NPCとボスNPCとの処理の違いを示す図。
図15】第4の実施形態に係る対戦プレイにおけるカウントダウン処理の一例を示すフローチャート。
図16】第5の実施形態に係るプレイヤキャラクタの状態毎の見た目の一例を示す図。
図17】第5の実施形態に係るキャラクタ制御部の詳細構成の一例を示すブロック図。
図18】第5の実施形態に係る状態遷移処理の一例を示すフローチャート。
図19】第6の実施形態に係る宝箱アイテムの表示例を示す図。
図20】第6の実施形態に係る通常アイテムの表示例を示す図。
図21】第6の実施形態に係る報酬付与処理の一例を示すフローチャート。
図22】第7の実施形態に係るプレイ画面におけるエフェクトの表示例を示す図。
図23】第7の実施形態に係るエフェクトの設定情報の一例を示す図。
【発明を実施するための形態】
【0010】
[第1の実施形態]
以下、本発明の第1の実施形態について、図面を参照して説明する。
【0011】
〔ゲームの概要〕
まず、本実施形態に係るゲームの一例について、その概要を説明する。例えば、本実施形態に係るゲームは、複数のユーザのそれぞれが操作するキャラクタ(以下、「プレイヤキャラクタ」ともいう)が敵キャラクタと戦闘しながらゲームを進行させるアクションゲームであり、ここではチーム対戦モードを例にして説明する。チーム数は、2チームであってもよいし、3チーム以上であってもよいが、ここでは、2チームによる対戦(即ち、1チーム対1チームの対戦)の場合を例に説明する。チーム毎に複数のユーザのそれぞれに操作されるプレイヤキャラクタが存在するため、多人数対多人数の対戦となる。
【0012】
ユーザは、ゲームのプレイを開始すると、対戦前に自チームおよび対戦チームを決定する。自チームに参加するユーザを決定するメンバーマッチングが行われた後、対戦相手のチームのメンバーマッチングが行われる。例えば、1チームは4名であり、4名対4名の対戦となる。なお、1チームの人数は他の人数であってもよい。自チームのマッチングは、サーバ装置によるその場限りのランダムマッチングと、ユーザ同士で結成したチームによるマッチングが存在する。対戦相手はサーバ装置によるランダムマッチングとなる。なお、チーム対戦に参加するには、ゲームにおいて設定されている特定のポイントやチケット等のアイテムを消費して参加する仕様としてもよい。
【0013】
キャラクタとは、ゲームに登場する人物、動物、物体(例えば、乗り物)などである。チームのメンバーマッチングが行われた後、ユーザは、自身が操作するプレイヤキャラクタを選択する。例えば、プレイヤキャラクタは、ゲームをプレイするユーザの操作対象となる戦士(人物)である。ユーザが操作するプレイヤキャラクタは、1体であってもよいし、組(パーティ)の形態をとった2体以上であってもよい。2体以上の場合には、いずれか1体に切り替えながらプレイを行うことができる。本実施形態では、ユーザ毎に操作されるプレイヤキャラクタは、それぞれ1体であるものとして説明する。
【0014】
プレイヤキャラクタには、能力を示す指標として、HP(Hit Point)、MP(Magic Point)、攻撃力、防御力、などのようなユーザのプレイ内容に影響するパラメータが関連付けられている。HPは、体力や生命力を示す値であり、ゲームの継続の可否を判定するためのポイントとなるパラメータである。このHPは、敵からの攻撃により減少し、所定値以下(例えば、「0」)になるとゲームの継続が不可となる。MPは、プレイヤキャラクタが特殊能力や特殊武器などのアイテムを使用する際に消費する値である。攻撃力及び防御力のそれぞれは、プレイヤキャラクタの攻撃に関する能力及び防御に関する能力を示す値である。攻撃力は、攻撃対象へのダメージの大きさを示すパラメータであり、攻撃対象のHPの減少量に関係する。防御力は、攻撃を受けた際のダメージに対する耐性を示すパラメータであり、HPの減少量の低減に関係する。例えば、攻撃力及び防御力は、プレイヤキャラクタの能力としてプレイヤキャラクタ毎に個別に設定されている。一方、HP及びMPは、プレイヤキャラクタを操作するユーザに関連付けられている。なお、HP及びMPは、プレイヤキャラクタに関連付けられていてもよい。
【0015】
なお、プレイヤキャラクタに帯同する帯同キャラクタを選択可能な仕様としてもよい。帯同キャラクタは、プレイヤキャラクタに代わって、または協力して敵キャラクタを倒したり、プレイヤキャラクタのHPを回復させるなど、ユーザのプレイをサポートする。例えば、帯同キャラクタは、ユーザの操作によらずAI(人工知能)によって自律的に行動するキャラクタである。帯同キャラクタとして選択可能なキャラクタには、複数の種類のキャラクタがあり、どのキャラクタを帯同させるかによって、その効果が異なる。
【0016】
また、プレイヤキャラクタにアイテムを装備することで、プレイヤキャラクタの能力を向上させることができる。アイテムは、複数のカテゴリに分類されている。例えば、アイテムは、「武器」、「防具」、及び「特殊武器」の3つのカテゴリに分類されている。プレイヤキャラクタの能力とは、プレイヤキャラクタの攻撃力、防御力などのパラメータや、特殊武器を所持することで特殊な攻撃を行うことができることなどである。なお、カテゴリの種類や分類数は任意に定めることができる。
【0017】
具体的には、「武器」は、プレイヤキャラクタの攻撃力などパラメータを向上させるアイテムである。「防具」は、プレイヤキャラクタの防御力などパラメータを向上させる装備アイテムである。「特殊武器」は、所定の時間が経つと爆発を起こすような大きなダメージを与える攻撃が可能なアイテムである。例えば、これらのアイテムは、抽選や所定のイベントをクリアすることでユーザが取得することができる。
【0018】
また、プレイヤキャラクタ、またはプレイヤキャラクタに装備可能なアイテムのそれぞれには、個々の能力の特徴を示す特性が設定されており、その特性の組み合わせによって攻撃の種類や威力が変わる。そのため、プレイヤキャラクタ、またはプレイヤキャラクタに装備するアイテムによって、戦略を考える必要がある。また、対戦相手のキャラクタまたは装備されるアイテムにも同様に特性があり、対戦相手のキャラクタの組み合わせによる相性によっても優劣が生じるため、戦略を考える必要がある。特性とは、例えば、キャラクタの行動に関する能力(攻撃力等)や、行動に影響を与える能力(回復スキル等)である。具体的には、例えば特性としては、「攻撃力が高い」、「回復スキルを持っている」、「投てき武器により高い場所が攻撃可能」、「特定の属性のキャラクタに大ダメージを与えられる」、「移動速度が早い」、「遠方の敵を攻撃可能」、「広範囲にダメージを与えることが可能」等がある。
【0019】
次に、図1を参照して、ゲーム空間において対戦が行われるフィールドについて説明する。図1は、本実施形態に係るフィールドの一例を示す図である。図示するフィールドFLDでは、青チームと赤チームとの対戦が行われる。フィールドFLDは、両チームに共通の複数の領域として、「スタート部屋」、「通常部屋」、「通路」、及び「ボス部屋」の4種類の「部屋(領域)」を有している。
【0020】
スタート部屋は、各チームのそれぞれに存在する。図示する例では、スタート部屋BSが青チームのスタート部屋であり、スタート部屋RSが赤チームのスタート部屋である。対戦プレイの開始時には、各チームのプレイヤキャラクタは、各チームのスタート部屋からスタートする。HPが0となって再スタート(リスポーン)する場合もこのスタート部屋から再開されることとなる。
【0021】
通常部屋は、各チームが占拠する対象となる部屋である。図示する例では、部屋A、部屋B、及び部屋Cが、対戦プレイの開始時に初期状態として青チームが占拠している部屋である。一方、部屋D、部屋E、及び部屋Fが、対戦プレイの開始時に初期状態として赤チームが占拠している部屋である。通常部屋には、占拠している側の陣営のNPC(ノンプレイヤキャラクタ)が存在している。NPCは、ユーザの操作を必要としないキャラクタであり、コンピュータが実行するゲーム処理によって制御されるキャラクタである。以下では、通常部屋に存在するNPCのことを「通常NPC」ともいう。通常NPCは、青チームと赤チームのうち占拠している方のチームに対応しており、対戦相手のチームのプレイヤキャラクタからの攻撃に対して占拠している側の陣営のキャラクタとして対抗する。例えば、通常部屋において通常NPCが討伐されると、討伐した側のチームが、この通常部屋を占拠することとなる。一方、通常部屋において通常NPCの討伐に失敗した場合には、討伐した側のチームによる占拠が失敗に終わり、元々占拠しているチームがそのままこの通常部屋を占拠することとなる。
【0022】
通路は、占拠の対象とならない部屋であり、別の部屋(ここでは、初期状態で相手チームが占拠している部屋)へ移動するための領域である。
【0023】
ボス部屋は、ボスキャラクタが出現する部屋であり、占拠の対象となる部屋である。ボスキャラクタは、NPCであるが、通常NPC違って、いずれかの陣営のキャラクタではない。よって、ボス部屋は、対戦プレイの開始時の初期状態では、いずれのチームに占拠されていない状態である。以下では、このボス部屋に存在するNPCのことを「ボスNPC」ともいう。ボスNPCは、通常NPCに比べて高い攻撃力や防御力を有し、いずれのチームからも攻撃可能なキャラクタである。例えば、ボスNPCが討伐された時に、より多くのダメージをボスNPCに与えた側のチームがボス部屋を占拠することとなる。
【0024】
対戦プレイが行われるフィールドには種類があり、フィールドごとに部屋の配置が異なるが、ここでは一例として、対戦するチームそれぞれへの平等性の観点から左右対称等の部屋の配置となっている。図示するフィールドFLDでは、青チームの部屋が左側、赤チームの部屋が右側に配置されており、各部屋が左右対称の関係に配置されている。各部屋は、隣接する部屋との間に扉DRが設けられている。この扉DRを通じて隣接する部屋との往来が可能である。具体的には、青チームのスタート部屋BSからは部屋Aへ、部屋Aからは部屋Bへ、部屋Bからは部屋Cとボス部屋へ、部屋Cからは通路を介して赤チームの部屋Fへ、と扉DRを介して通じている。一方、赤チームのスタート部屋RSからは部屋Dへ、部屋Dからは部屋Eへ、部屋Eからは部屋Fとボス部屋へ、部屋Fからは通路を介して青チームの部屋Cへと、と扉DRを介して通じている。両チームのプレイヤキャラクタは、このフィールドFLD内は共通の領域であり、制限なく往来することができる。なお、スタート部屋のみ対戦相手のチームのプレイヤキャラクタが入れないようにしてもよい。
【0025】
次に、ゲームの基本的なルールについて説明する。制限時間(例えば3分)内に占拠した部屋の数が多いチームが勝利となる。例えば、各チームの各プレイヤキャラクタが各ユーザの操作に応じてフィールド内を移動して、戦闘を行いながら部屋を占拠していく。制限時間終了時により多くの部屋を占拠しているチームが勝利と判定される。以下に、部屋の占拠について詳しく説明する。
【0026】
通常部屋では、対戦するチーム(青チーム、赤チーム)によって占拠による部屋の奪い合いが行われる。青チームが占拠している通常部屋には青チーム側の通常NPCが存在しており、その部屋の中に入ってくる赤チーム側のプレイヤキャラクタに対して攻撃を行う。この通常NPCは赤チーム側のプレイヤキャラクタによって攻撃可能である。互いの攻撃によって当たり判定が行われ、当たりの度合い(的中度合い、攻撃力など)によって、被攻撃側にダメージが与えられ、被攻撃側のHPが減少する。逆に、この通常部屋では、青チーム側のプレイヤキャラクタからは通常NPCに対して攻撃できず(攻撃しても当たり判定がない)、また通常NPCは青チーム側のプレイヤキャラクタには攻撃しない。
【0027】
通常部屋において、通常NPCの討伐状況が予め設定された所定の占拠条件を満たした場合、攻撃したチームがその通常部屋を占拠することができる。通常NPCの討伐状況とは、その通常部屋に出現している通常NPCの数である。所定の占拠条件は、例えば、その部屋に存在する通常NPCのすべてが討伐される(HPが「0」になる)ことである(即ち、通常NPCの数が0になること)。赤チーム側のプレイヤキャラクタによってその部屋に存在する通常NPCのすべてが討伐されると、その部屋は赤チーム側の占拠となる。
【0028】
通常部屋が赤チームに占拠されると、その部屋には赤チーム側の通常NPCが出現する。出現した赤チーム側の通常NPCは、青チーム側のプレイヤキャラクタから攻撃可能となる。この状態では、赤チーム側のプレイヤキャラクタからは通常NPCに対して攻撃できず(攻撃しても当たり判定がない)、また通常NPCは赤チーム側のプレイヤキャラクタには攻撃しない。青チーム側のプレイヤキャラクタによってその部屋に存在するすべての通常NPCが討伐されるとその部屋は再び青チーム側が占拠したことになる。これを繰り返しながら両チームは、通常部屋を占拠しあうこととなる。このように、一つの通常部屋は、いずれかのチームに占拠された状態となっており、同時に両チームの通常NPCが混在することはない。
【0029】
なお、通常部屋における上記所定の占拠条件は、その部屋に存在する通常NPCのすべてが討伐される(HPが「0」になる)ことに限られるものではなく、他の条件としてもよい。例えば、所定の占拠条件は、その部屋に存在する通常NPCの数が所定数以下(例えば、2体以下)になること、または、その部屋に存在する通常NPCの討伐した数が所定数以上(例えば、10体以上)になることとしてもよい。
【0030】
また、通常部屋で対戦プレイ中のプレイ画面では、プレイ画面の下部が占拠している側のチームの色に変更される。これにより、対戦プレイ中の部屋がどちらのチームに占拠されているのかが視認し易くなる。
図2は、通常部屋におけるプレイ画面の一例を示す図である。図示するプレイ画面G10には、通常部屋の中の様子が表示される。プレイ画面G10の下側の領域FLは、この部屋の床に相当する領域である。この領域FLが、青チームによって占拠されているときには青色(または青系統の色)となり、赤チームによって占拠されているときには赤色(または赤系統の色)となる。なお、この占拠している側のチームの色に変更される領域は、プレイ画面中の他の領域としてもよい。
【0031】
また、プレイ画面G10の上部にはフィールド内の地図MAが表示される。また、地図MA内には、この対戦プレイ中の部屋の場所を示す位置マークPSが表示される。また、符号NP1~3はこの部屋に存在する通常NPCを示しており、符号P1は通常NPCを討伐しようとするプレイヤキャラクタを示している。なお、この図では、プレイヤキャラクタが1体のみであるが、同じチームの他のプレイヤキャラクタや、対戦相手のチームのプレイヤキャラクタ等が複数存在してもよい。
【0032】
基本的には、プレイヤキャラクタには移動の制限はなく、どこの部屋にも移動することが可能である。部屋はある程度の広さがあり、各ユーザの操作に応じて、各プレイヤキャラクタが部屋の中も自由に移動できる。
【0033】
ボス部屋では、ボスNPCが出現する。ボスNPCは、いずれの陣営でもない。即ち、ボスNPCは、いずれか一つのチームに対応しているのではなく、いずれのチームに対しても攻撃をし、いずれのチームからも攻撃が可能である。ボスNPCが討伐された時に、より多くのダメージをボスNPCに与えた側のチームがボス部屋を占拠することとなる。ボス部屋では、1回の対戦でボスNPCが1回のみ出現する。このため、ボス部屋は、一方のチームに一度占拠されると、その後他方のチームが占拠し返すことはできず、対戦終了まで占拠したチーム(陣営)が変わることがない。即ち、ボス部屋を占拠するチャンスは、1つのフィールドの対戦中で1回のみとなる。なお、フィールド内に、複数のボス部屋があってもよいが、各ボス部屋での対戦中に1回だけボスが出現することになる。
【0034】
図3は、ボス部屋におけるプレイ画面の一例を示す図である。図示するプレイ画面G20には、ボス部屋の中の様子が表示される。通常部屋のプレイ画面G10と違って対戦プレイ中は占拠されていない状態であるため、占拠状況を示す表示(チーム色の表示)は行われない。また、符号BNPはこの部屋に存在するボスNPCを示しており、符号PB1、PB2は、ボスNPCを討伐しようとする青チームのプレイヤキャラクタを示しており、符号PR1、PR2は、同じくボスNPCを討伐しようとする赤チームのプレイヤキャラクタを示している。ボスNPCは、通常NPCに比較して、HP、攻撃力、防御力などが高く、討伐するためにより多くの攻撃が必要となる。そのため、ボス部屋にボスNPCが出現し対戦が開始されると、ボス部屋を占拠するために各チームのプレイヤキャラクタがボス部屋に集まり、各チームがより多くのダメージをボスNPCに与えられるように協力して攻撃を行うことになる。ボス部屋は、占拠のし返しができないため、ボス部屋を占拠することによって少なくとも1つの部屋の占拠が確定し、通常部屋の占拠以上に対戦の戦況に有利に働く。なお、ボス部屋を占拠することによって、占拠した側のプレイヤキャラクタのパラメータが有利な方向に変更されてもよい(例えば、HPの回復等)。また、ボス部屋の占拠が通常部屋の占拠の所定倍数分に相当するようにしてもよい。
【0035】
〔システム構成〕
次に、本実施形態に係るゲームシステム1のシステム構成について説明する。図4は、本実施形態に係るゲームシステム1の構成の一例を示すブロック図である。ゲームシステム1は、ゲーム装置10-1と、ゲーム装置10-2と、ゲーム装置10-3、・・・と、ゲームサーバ30とのコンピュータ装置を備えており、これらのコンピュータ装置はネットワークNWを介して接続される。ゲーム装置10-1と、ゲーム装置10-2と、ゲーム装置10-3とは同様の構成であるため、特に区別しない場合には、「-1」、「-2」等の記載を省略してゲーム装置10として説明する。ここでは3台のゲーム装置10を図示しているが、任意の台数のゲーム装置10がゲームサーバ30に接続されてもよい。
【0036】
ゲームサーバ30は、ゲーム装置10においてプレイ可能なゲームを提供するサーバ装置である。例えば、ゲームサーバ30は、ゲーム装置10においてプレイ可能なゲームの制御プログラム(ゲーム制御プログラム)を、ゲーム装置10からダウンロード可能に提供する。また、ゲームサーバ30は、ゲーム装置10においてプレイされるゲームに必要な各種設定情報及び履歴情報などを記憶するとともに、必要に応じてゲーム装置10に送信する。また、ゲームサーバ30は、ゲーム装置10においてプレイされるゲームの処理のうち、サーバ側で実行する必要がある処理を実行する。なお、ゲーム装置10がダウンロードするゲーム制御プログラムは、ゲームサーバ30に限らず、他のダウンロード可能なサーバ装置に記憶されていてもよい。また、ゲーム制御プログラムは、DVD-ROM、CD-ROM、メモリカード等の記憶媒体によってゲーム装置10に提供されてもよい。
【0037】
ゲーム装置10は、ゲームサーバ30から提供されるゲーム制御プログラムを実行する。例えば、ゲーム装置10は、ユーザが利用するコンピュータ装置であり、家庭用の据え置き型ゲーム機、携帯型ゲーム機、ゲームセンター等に設置されているアーケードゲーム機、PC(Personal Computer)、タブレットPC、スマートフォンやフィーチャーフォン等の携帯電話機、携帯情報端末(PDA:Personal Digital Assistant)等が適用できる。本実施形態では、ゲーム装置10は携帯型ゲーム機であるとして説明する。
【0038】
ネットワークNWは、例えば、インターネットや、携帯電話網、PHS(Personal Handy-phone System)網、VPN(Virtual Private Network)網、専用通信回線網、WAN(Wide Area Network)、LAN(Local Area Network)、PSTN(Public
Switched Telephone Network;公衆交換電話網)など、またはこれらの組み合わせによって構成される通信ネットワークである。
【0039】
図5は、本実施形態に係るゲーム装置10のハードウェア構成の一例を示す図である。ゲーム装置10は、例えば、CPU(Central Processing Unit)11と、通信部12と、入力部13と、表示部14と、記憶部15とを備え、ネットワークNWを介して接続されたゲームサーバ30や他の装置等と通信部12を介して通信を行う。これらの構成要素は、バス(Bus)を介して相互に通信可能に接続されている。CPU11は、記憶部15に記憶された各種プログラムを実行し、ゲーム装置10の各部を制御する。
【0040】
通信部12は、CPU11による制御に基づいて、ネットワークNWを介してゲームサーバ30や他の装置等と通信を行う。
入力部13は、ユーザの操作が入力される複数の操作ボタンを含んで構成されており、入力された操作情報をCPU11へ出力する。なお、入力部13は、ディスプレイと一体に構成されたタッチパネル、複数の操作ボタンが設けられたコントローラ、キーボードやマウス、タッチパッドや、音声により各種の指示が入力されるマイクロホンなど、その他の入力装置であってもよい。
表示部14は、画像やテキスト等の情報を表示するディスプレイであり、例えば、液晶ディスプレイパネル、有機EL(ElectroLuminescence)ディスプレイパネルなどを含んで構成される。例えば、表示部14には、ゲームのプレイ画像が表示される。
【0041】
記憶部15は、例えば、HDD(Hard Disk Drive)やSSD(Solid State Drive)、EEPROM(Electrically Erasable Programmable Read-Only Memory)、ROM(Read-Only Memory)、RAM(Random Access Memory)などを含み、ゲーム装置10が処理する各種情報や画像、プログラム(ゲーム制御プログラムを含む)等を記憶する。なお、記憶部15は、ゲーム装置10に内蔵されるものに限らず、USB等のデジタル入出力ポート等によって接続された外付け型の記憶装置でもよい。また、ゲーム装置10は、不図示のスピーカ、音声出力端子、カメラ、ジャイロセンサ、GPS(Global Positioning System)受信モジュールなどのハードウェア構成を含んで構成されてもよい。
【0042】
図6は、本実施形態に係るゲームサーバ30のハードウェア構成の一例を示す図である。ゲームサーバ30は、例えば、CPU31と、通信部32と、入力部33と、記憶部35とを備え、ネットワークNWを介して接続された複数のゲーム装置10や他の装置等と通信部32を介して通信を行う。これらの構成要素は、バス(Bus)を介して相互に通信可能に接続されている。CPU31は、記憶部35に記憶されたゲーム制御プログラムを実行し、複数のゲーム装置10でプレイ可能なゲームを提供する。
【0043】
通信部32は、CPU31による制御に基づいて、ネットワークNWを介して複数のゲーム装置10や他の装置と通信を行う。
入力部33は、例えば、キーボードやマウス、タッチパッドや、音声により各種の指示が入力されるマイクロホンなど、その他の入力装置である。
【0044】
記憶部35は、例えば、HDD、EEPROM、RAMなどを含み、ゲーム制御プログラム、アプリケーションプログラム、ゲームに必要な各種設定情報及び履歴情報などを記憶する。なお、記憶部35は、ゲームサーバ30に内蔵されるものに限らず、USB等のデジタル入出力ポート等によって接続された外付け型の記憶装置でもよい。また、記憶部35は、ゲームサーバ30とは物理的に離れた外部の記憶装置であってもよく、ゲームサーバ30とネットワークNWを介して接続されてもよい。また、ゲームサーバ30は、不図示の表示部、スピーカ、音声出力端子などのハードウェア構成を含んで構成されてもよい。
【0045】
〔機能構成〕
次に、図7を参照して、ゲームシステム1が備えるゲーム装置10及びゲームサーバ30の機能構成について説明する。図7は、本実施形態に係るゲームシステム1が備えるゲーム装置10及びゲームサーバ30の構成の一例を示すブロック図である。
【0046】
〔ゲーム装置10の機能構成〕
まず、ゲーム装置10の構成について説明する。
ゲーム装置10は、記憶部15に記憶されているゲーム制御プログラムをCPU11が実行することにより実現される機能構成として、ゲーム制御部110を備えている。ゲーム制御部110は、ゲームのプレイ処理を制御する。例えば、ゲーム制御部110は、サーバ制御情報取得部111と、キャラクタ制御部112と、通常NPC制御部113と、対戦制御部114と、表示制御部115とを備えている。
【0047】
サーバ制御情報取得部111は、ゲーム処理に関するデータをゲームサーバ30から通信部12を介して取得する。例えば、サーバ制御情報取得部111は、ユーザが選択可能なプレイヤキャラクタに関するデータ、該プレイヤキャラクタに装備可能に所持しているアイテムに関するデータなどを取得する。また、サーバ制御情報取得部111は、ゲームサーバ30によって実行されたゲーム処理の処理結果に基づくデータ、及び他のゲーム装置10で実行されたゲーム処理の処理結果に基づくデータをゲームサーバ30から通信部12を介して取得する。
【0048】
キャラクタ制御部112は、入力部13に対するユーザの操作に基づいて、フィールドFLD内でのプレイヤキャラクタの活動を制御する。活動とは、移動や動きの総称である。動きとは、攻撃、防御、アイテムの取得などに伴う動作(モーション)である。また、キャラクタ制御部112は、対戦プレイにおいて、攻撃したり攻撃されたりすることに応じて、HP及びMPの値を変更する。また、キャラクタ制御部112は、プレイヤキャラクタの制御情報(位置や動きの情報や、HP及びMPの値など)を、通信部12を介してゲームサーバ30へ送信する。
【0049】
通常NPC制御部113は、各通常部屋における通常NPCを制御する。例えば、通常NPC制御部113は、各通常部屋において、当該部屋を占拠している陣営の通常NPC(占拠しているチームに対応する通常NPC)を出現させ、対戦相手のチームのプレイヤキャラクタに対する攻撃を行うなど通常NPCの活動を制御する。
【0050】
対戦制御部114は、対戦プレイにおける対戦のルールの適用、攻撃による当たり判定、当たり判定結果に基づくダメージ量やダメージの種類の決定などを行う。例えば、対戦制御部114は、通常NPC制御部113により制御される通常NPCと、キャラクタ制御部112により制御されるプレイヤキャラクタとの対戦において、対戦のルールの適用、攻撃による当たり判定、当たり判定結果に基づくダメージ量やダメージの種類の決定などを行う。対戦のルールとは、例えば、通常NPCへの攻撃が、通常NPCとは異なる陣営(チーム)のプレイヤキャラクタからは可能であるが、同じ陣営(チーム)のプレイヤキャラクタからは出来ないことなどである。なお、対戦制御部114は、通常NPCに対して同じ陣営(チーム)のプレイヤキャラクタからの攻撃を制限してもよいし、攻撃自体は制限せずに当たり判定を行なわないようにしてもよい。
【0051】
また、対戦制御部114は、プレイヤキャラクタから通常NPCへの攻撃の当たり判定の判定結果またはダメージ量やダメージの種類を示す情報を通信部12を介してゲームサーバ30へ送信する。例えば、ゲームサーバ30は、この当たり判定の判定結果またはダメージ量やダメージの種類を示す情報に基づいて、通常NPCのHPの値を変更する。一方、対戦制御部114は、通常NPCからプレイヤキャラクタへの攻撃の当たり判定の判定結果またはダメージ量やダメージの種類を示す情報を、キャラクタ制御部112に出力する。例えば、キャラクタ制御部112は、この当たり判定の判定結果またはダメージ量やダメージの種類を示す情報に基づいて、プレイヤキャラクタのHPの値を変更する。
【0052】
また、ボス部屋における対戦プレイでは、対戦制御部114は、ゲームサーバ30により制御されるボスNPCと、キャラクタ制御部112により制御されるプレイヤキャラクタとの対戦において、攻撃による当たり判定、当たり判定結果に基づくダメージ量やダメージの種類の決定などを行う。また、対戦制御部114は、プレイヤキャラクタからボスNPCへの攻撃の当たり判定の判定結果またはダメージ量やダメージの種類を示す情報を通信部12を介してゲームサーバ30へ送信する。例えば、ゲームサーバ30は、この当たり判定の判定結果またはダメージ量やダメージの種類を示す情報に基づいて、ボスNPCのHPの値を変更する。一方、対戦制御部114は、ボスNPCからプレイヤキャラクタへの攻撃の当たり判定の判定結果またはダメージ量やダメージの種類を示す情報を、キャラクタ制御部112に出力する。例えば、キャラクタ制御部112は、この当たり判定の判定結果またはダメージ量やダメージの種類を示す情報に基づいて、プレイヤキャラクタのHPの値を変更する。
【0053】
表示制御部115は、ゲーム画面として表示させるゲーム画像を生成して、表示部14に表示させる。例えば、表示制御部115は、キャラクタ制御部112による制御結果、及びサーバ制御情報取得部111が取得したゲームサーバ30によって実行されたゲーム処理に基づくデータや他のゲーム装置10で実行されたゲーム処理に基づくデータに基づいて、フィールド内の各部屋の様子や、各チームのプレイヤキャラクタ、通常NPC、ボスNPC、及び各キャラクタの攻撃に対応するエフェクト(効果)などの表示画像を生成して、表示部14にプレイ画面として表示させる(例えば、図2及び図3のプレイ画面参照)。
【0054】
〔ゲームサーバ30の機能構成〕
次に、ゲームサーバ30の構成について説明する。
ゲームサーバ30は、記憶部35に記憶されているプログラムをCPU31が実行することにより実現される機能構成として、サーバ制御部310を備えている。例えば、サーバ制御部310は、記憶部35に記憶されているゲームに関するデータ(例えば、キャラクタ及びアイテムに関するデータ)を、通信部32を介してゲーム装置10へ送信する。また、サーバ制御部310は、各ゲーム装置10におけるユーザの操作に基づいて制御されるプレイヤキャラクタの制御情報を、通信部32を介して各ゲーム装置10から取得する。そして、サーバ制御部310は、各ゲーム装置10から取得した各プレイヤキャラクタの制御情報を、取得したゲーム装置10以外のゲーム装置10へ送信する。これにより、共通のフィールド内で複数ユーザが操作するプレイヤキャラクタの画像が、各ゲーム装置10のプレイ画面に表示可能となる。また、サーバ制御部310は、各ゲーム装置10に対して共通で処理を行うボスNPCの制御や、部屋の占拠判定及びチームの勝利判定などのサーバ装置側で必要な処理を実行する。以下、ゲームサーバ30の構成について詳しく説明する。
【0055】
まず、ゲームサーバ30の記憶部35に記憶されているデータについて説明する。例えば、記憶部35は、ユーザデータ記憶部351と、チームデータ記憶部352と、キャラクタデータ記憶部353と、アイテムデータ記憶部354と、所持データ記憶部355とを備えている。
【0056】
ユーザデータ記憶部351には、ゲームをプレイするユーザ(プレイヤ)に関するユーザデータが記憶される。ユーザデータには、ユーザID、ユーザ名、レベル、HP、MP、プレイヤキャラクタデータ、装備アイテム等が関連付けられている。ユーザIDは、ユーザの識別情報である。ユーザ名は、ゲーム内で表示されるユーザの名称である。レベルは、ユーザのプレイによるゲーム進行度合いに応じて増加する値である。HP及びMPには、ユーザが操作するプレイヤキャラクタのHP及びMPの値が格納される。プレイヤキャラクタデータには、ユーザが選択したプレイヤキャラクタのキャラクタIDと、そのプレイヤキャラクタの攻撃力及び防御力などのキャラクタパラメータが格納される。装備アイテムには、ユーザが設定した装備アイテムを示す情報(例えば、アイテムID)が関連付けられる。これらのデータは、ゲーム装置10の記憶部15にも記憶されている。
【0057】
チームデータ記憶部352には、チームに属するユーザ情報(例えば、ユーザID)や各チームによる部屋の占拠状況、または勝敗履歴などチームに関するチームデータが記憶される。例えば、チームデータには、チームID(チームの識別情報)、そのチームのユーザID、占拠している部屋を示す情報(部屋の識別情報、部屋ID)、勝敗履歴などが関連付けられている。
【0058】
キャラクタデータ記憶部353には、ユーザがプレイヤキャラクタとして選択可能なキャラクタデータや、通常NPC及びボスNPCに関するキャラクタデータが記憶されている。キャラクタデータには、キャラクタID、キャラクタ名、属性、特性、キャラクタパラメータなどが関連付けられている。キャラクタIDは、キャラクタの識別情報である。キャラクタ名は、キャラクタの名称である。属性には、「火」、「水」、「木」、「闇」、「聖」などがあり、各キャラクタにはいずれかの属性が設定されている。「火」、「水」、「木」は、互いに優劣関係にある。例えば、「火」の属性より「水」の属性の方が優位であり、「水」の属性より「木」の属性の方が優位であり、「木」の属性より「火」の属性の方が優位である。なお、「闇」及び「聖」は、特別な能力を有する攻撃や防御を示す情報である。特性は、前述したように各キャラクタ個々の能力の特徴を示すものであり、「攻撃力が高い」、「回復スキルを持っている」、「投てき武器により高い場所が攻撃可能」、「特定の属性のキャラクタに大ダメージを与えられる」、「移動速度が早い」、「遠方の敵を攻撃可能」、「広範囲にダメージを与えることが可能」等である。キャラクタパラメータは、キャラクタの攻撃力及び防御力などである。なお、通常NPC及びボスNPCには、各NPCの能力(攻撃力や防御力など)に対応するレベルが設定されている。
【0059】
アイテムデータ記憶部354には、プレイヤキャラクタに装備可能なアイテムに関するアイテムデータが記憶される。アイテムデータには、アイテムID、アイテム名、カテゴリ、属性、及びアイテムパラメータが関連付けられている。アイテムIDは、アイテムの識別情報である。アイテム名は、アイテムの名称である。カテゴリには、各アイテムのカテゴリ(例えば、「武器」、「防具」、「特殊武器」のいずれか)が格納される。属性には、各アイテムに設定されている属性(「火」、「水」、「木」、「闇」、「聖」のいずれか)が格納される。アイテムパラメータには、各アイテムの攻撃力、防御力、HP、MPなどの値が設定されており、アイテムを装備することでプレイヤキャラクタの攻撃力、防御力、HP、MPなどが強化(値が上昇)される。なお、アイテムには、特定のキャラクタにのみ装備可能な専用アイテムがあってもよく、専用アイテムを示す情報もアイテムデータに含まれてもよい。
【0060】
所持データ記憶部355には、ユーザが所持しているアイテムの所持データが記憶される。例えば、所持データには、ユーザが抽選や特定のイベントをクリアすることで取得したアイテムに関するデータ(例えば、アイテムID)が、ユーザIDと関連付けられて格納される。ユーザは、この所持データに格納されているアイテムの中から、プレイヤキャラクタに装備するアイテムを選択することができる。
【0061】
次に、サーバ制御部310の機能構成について説明する。例えば図7に示すように、サーバ制御部310は、端末制御情報取得部311と、ボスNPC制御部312と、通常NPC状態同期部313と、プレイヤキャラクタ同期部314と、占拠判定部315と、勝敗判定部316と、報酬付与部317とを備えている。
【0062】
端末制御情報取得部311は、各ゲーム装置10で実行されたゲーム処理に基づく各種情報を、通信部32を介して各ゲーム装置10から取得する。例えば、端末制御情報取得部311は、プレイヤキャラクタの制御情報(位置などの活動に関する情報や、HP及びMPの値など)を各ゲーム装置10から取得する。また、端末制御情報取得部311は、対戦プレイによる通常NPC及びボスNPCの当たり判定の判定結果またはダメージ量やダメージの種類を示す情報を、各ゲーム装置10から取得する。
【0063】
ボスNPC制御部312は、ボス部屋におけるボスNPCを制御する。例えば、ボスNPC制御部312は、ボス部屋にボスNPCを出現させ、出現させたボスNPCの移動、各プレイヤキャラクタへの攻撃、及び各プレイヤキャラクタからの攻撃に応じたHPの値の変更などを制御する。なお、ボスNPC制御部312は、各ゲーム装置10から取得する、プレイヤキャラクタからボスNPCへの攻撃の当たり判定の判定結果またはダメージ量やダメージの種類を示す情報に基づいて、ボスNPCのHPの値を変更する。ボスNPCのHPの値が「0」になると、ボスNPC制御部312は、ボスNPCを消滅(死亡)させる。また、ボスNPC制御部312は、ボスNPCの制御情報(位置や動きの情報や、HPの値など)を、通信部32を介して各ゲーム装置10へ送信する。
【0064】
通常NPC状態同期部313は、各ゲーム装置10で制御される通常NPCの状態が同じになるように同期させる。例えば、通常NPC状態同期部313は、通常NPCの出現数及び出現タイミングを制御する。具体的には、通常NPC状態同期部313は、通常NPCを出現させる際に、その旨を示す指示情報を各ゲーム装置10に送信する。各ゲーム装置10は、その指示情報に応じて通常NPCを出現させる。これにより、各ゲーム装置10で出現する通常NPCのタイミングと数がおおよそ同じとなり、共通性が保たれる。
【0065】
また、通常NPC状態同期部313は、各ゲーム装置10から取得する、プレイヤキャラクタから通常NPCへの攻撃の当たり判定の判定結果またはダメージ量やダメージの種類を示す情報に基づいて、通常NPCのHPの値を変更する。また、通常NPC制御部113は、HPの値が「0」になった通常NPCを消滅(死亡)させる。そして、通常NPC状態同期部313は、通常NPCのHPの値を示す情報を随時各ゲーム装置10に送信するとともに、通常NPCが消滅(死亡)した場合、その旨を示す情報を、各ゲーム装置10に送信する。各ゲーム装置10は、これらの情報に基づいて通常NPCのHPの値や状態を制御する。
【0066】
プレイヤキャラクタ同期部314は、各ゲーム装置10で制御されるプレイヤキャラクタの位置や状態が同じになるように同期させる。例えば、プレイヤキャラクタ同期部314は、各ゲーム装置10から取得するプレイヤキャラクタの位置を示す情報に基づいて、各プレイヤキャラクタが各ゲーム装置10で同じ位置に表示されるように制御する。具体的には、プレイヤキャラクタ同期部314は、各ゲーム装置10から取得するプレイヤキャラクタの位置を示す情報を各ゲーム装置10へ送信する。各ゲーム装置10は、この各ゲーム装置10における各プレイヤキャラクタの位置を示す情報に基づいてプレイヤキャラクタの位置を制御する。これにより、各ゲーム装置10の各プレイヤキャラクタが各ゲーム装置10で同じ位置に表示されるようになる。また、プレイヤキャラクタ同期部314は、各ゲーム装置10から取得するプレイヤキャラクタの状態を示す情報に基づいて、各プレイヤキャラクタのHP残量が同じに表示されるように制御するとともに、消滅(死亡)したプレイヤキャラクタは他のゲーム装置10でも消滅(死亡)するように制御する。具体的には、プレイヤキャラクタ同期部314は、各ゲーム装置10から取得するプレイヤキャラクタの状態を示す情報を各ゲーム装置10へ送信する。各ゲーム装置10は、この各ゲーム装置10における各プレイヤキャラクタの状態を示す情報に基づいてプレイヤキャラクタの状態を制御する。
【0067】
占拠判定部315は、ユーザの操作結果に基づいて所定の占拠条件を満たしたか否かに基づいて、その通常部屋をいずれのチームの占拠とするか(即ち、いずれのチームに関連付けるか否か)を判定する。例えば、占拠判定部315は、通常部屋において通常NPCの討伐状況が所定の占拠条件を満たした場合、その通常部屋をいずれのチームの占拠とするか(即ち、いずれのチームに関連付けるか否か)を判定する。
【0068】
例えば、占拠判定部315は、青チームに関連付けられた通常部屋において、赤チームのユーザの操作結果(通常NPCの討伐状況)により所定の占拠条件が満たされた場合、その通常部屋を赤チームの占拠とする。この場合、占拠判定部315は、チームデータ記憶部352に記憶されているチームデータにおいて、赤チーム(赤チームのチームID)に、その通常部屋(部屋ID)を関連付ける。なお、占拠判定部315は、チームデータ記憶部352に記憶されているチームデータにおいて、赤チームに属するユーザ情報(ユーザID)に対してその通常部屋(部屋ID)を関連付けてもよい。
【0069】
図8は、本実施形態に係る部屋の占拠を判定する占拠判定処理の一例を示すフローチャートである。通常部屋での対戦が開始されると、占拠判定部315は、ユーザの操作結果に基づいて所定の占拠条件(例えば、その部屋の通常NPCが全滅)を満たしたか否かを判定する(ステップS100)。所定の占拠条件が満たされていないと判定された場合(NO)、占拠判定部315は、再びステップS100の処理を実行する。一方、所定の占拠条件が満たされたと判定された場合(YES)、占拠判定部315は、所定の占拠条件を満たしたチームによる占拠として、チームデータ記憶部352に記憶されているチームデータを更新する(ステップS102)。
【0070】
勝敗判定部316は、占拠判定部315による判定結果に基づいて、複数のチームによる対戦の勝敗を判定する。例えば、勝敗判定部316は、占拠判定部315による判定結果により、青チームと赤チームのそれぞれが占拠している部屋の数(即ち、青チームと赤チームのそれぞれに関連付けられた部屋の数)に基づいて、青チームと赤チームによる対戦の勝敗を判定する。例えば、勝敗判定部316は、占拠している部屋の数が多い方のチームを勝ち(勝利)と判定し、占拠している部屋の数が少ない方のチームを負け(敗北)と判定する。
【0071】
また、勝敗判定には引き分けが含まれてもよい。例えば、勝敗判定部316は、各チームの占拠している部屋の数が同数の場合、引き分けと判定してもよい。また、勝敗判定部316は、各チームの占拠している部屋の数が同数の場合、占拠している部屋の種類を考慮に入れて、一方のチームを勝ちと判定し、他方のチームを負けと判定してもよい。例えば、勝敗判定部316は、ボス部屋を占拠したチームを勝ちと判定してもよいし、通常部屋の占拠よりもボス部屋の占拠の方が勝利に寄与する割合を高くしてもよい。
【0072】
図9は、本実施形態に係る勝敗判定処理の一例を示すフローチャートである。対戦プレイが開始されると、勝敗判定部316は、計時を開始する(ステップS110)。計時はカウントアップでもカウントダウンでもよい。次に、勝敗判定部316は、計時した時間に基づいて制限時間が終了したか否かを判定する(ステップS112)。制限時間が終了していないと判定された場合(NO)、勝敗判定部316は、再びステップS110の処理を実行する。一方、制限時間が終了したと判定された場合(YES)、勝敗判定部316は、各チームのそれぞれが占拠している部屋の数に基づいて勝敗を判定する(ステップS114)。
【0073】
なお、勝敗判定部316は、占拠判定部315による判定結果に加えて、報酬付与部317により各チームまたは該チームに属するユーザ情報により識別されるユーザに対して付与されたポイントを考慮して勝敗を判定してもよい。例えば、勝敗判定部316は、各チームの占拠している部屋の数が同数の場合、各チームに付与されたポイントに基づいて勝敗を判定してもよい。
【0074】
図10は、部屋の占拠だけでなくポイントも考慮した勝敗判定処理の一例を示すフローチャートである。対戦プレイが開始されると、勝敗判定部316は、計時を開始する(ステップS120)。計時はカウントアップでもカウントダウンでもよい。次に、勝敗判定部316は、計時した時間に基づいて制限時間が終了したか否かを判定する(ステップS122)。制限時間が終了していないと判定された場合(NO)、勝敗判定部316は、再びステップS120の処理を実行する。一方、制限時間が終了したと判定された場合(YES)、勝敗判定部316は、各チームのそれぞれが占拠している部屋の数と付与されたポイントとに基づいて勝敗を判定する(ステップS124)。
【0075】
なお、勝敗判定部316は、各チームの占拠している部屋の数が同数の場合のみポイントも考慮した勝敗判定を行なってもよいし、各チームの占拠している部屋の数が異なる場合もポイントも考慮した勝敗判定を行なってもよい。
【0076】
(ポイントの付与)
次に、ポイントの付与について説明する。報酬付与部317は、「部屋占拠」、「NPCの討伐」、「アシスト」などによって、チームまたはそのチームのユーザに対してポイントを付与する。以下、順に説明する。
【0077】
・「部屋占拠」によるポイント付与
報酬付与部317は、部屋を占拠したチーム(またはそのチームのユーザ)に対してポイントを付与する。つまり、対戦相手チームが占拠している通常部屋に存在している通常NPCがすべて討伐され、その部屋に通常NPCが存在しない状態となると、該討伐した側のチームの占拠となり、そのチームにポイント(例えば、3000ポイントなど)が付与される。具体的には、報酬付与部317は、チームデータ記憶部352に記憶されているチームデータにおいて、占拠判定部315により部屋(部屋ID)に関連付けられたチーム(チームID)またはそのチームに属するユーザ情報(ユーザID)に、部屋の占拠に応じて付与するポイントを関連付ける。例えばこのポイントは、付与される度に加算されていく。
【0078】
なお、部屋によって付与されるポイントが異なってもよい。例えば、報酬付与部317は、部屋を占拠したチームに対して、その部屋に応じたポイントを付与してもよい。例えば、部屋にはレベル(部屋レベル)が設定されており、報酬付与部317は、部屋を占拠したチームに対して、占拠した部屋の部屋レベルに応じたポイントを付与してもよい。
【0079】
例えば、部屋レベルは、占拠される度にレベルが一つ上がる。レベルが上がると出現する通常NPCのレベルも上がり、占拠の難易度が高くなる。また、部屋レベルが上がると、出現する通常NPCが別の種類の高いレベルを有する通常NPCになってもよい。例えば、報酬付与部317は、部屋レベルが高いほど占拠された時に付与するポイントを高くする。即ち、報酬付与部317は、同一の部屋において所定の占拠条件が満たされる度に、付与するポイントを増加させてもよい。なお、部屋毎にポイントの初期値(例えば、部屋レベルがレベル1の時に占拠された場合の付与ポイント)が設定されている。
【0080】
図11は、部屋占拠時に付与されるポイントの一例を示す図である。この図では、通常部屋A(部屋A)と通常部屋B(部屋B)について、各部屋レベルと占拠時のポイントとの関係を示している。図示する例では、通常部屋Aは、部屋レベルがレベル1(Lv1)、レベル2(Lv2)、レベル3(Lv3)、レベル4(Lv4)、レベル5(Lv5)のそれぞれの場合について、占拠時のポイントが2000pt(point)、3000pt、4500pt、6000pt、7500ptに設定されている。通常部屋Bは、部屋レベルがレベル1(Lv1)、レベル2(Lv2)、レベル3(Lv3)、レベル4(Lv4)、レベル5(Lv5)のそれぞれの場合について、占拠時のポイントが3000pt、4500pt、6000pt、7500pt、9000ptに設定されている。
【0081】
また、報酬付与部317は、チームが占拠している部屋が多いほど、そのチームに付与するポイントを増加させてもよい。例えば、報酬付与部317は、部屋が占拠された時点において、その部屋を占拠したチームが他に占拠している部屋の数に応じてボーナスポイントを付与してもよい。例えば、占拠済みの部屋数に応じたボーナス係数が設定されており、そのボーナス係数に応じたボーナスポイントが付与される。
【0082】
図12は、占拠済みの部屋数とボーナス係数の設定の一例を示す図である。図示する例では、占拠済みの部屋数(占拠済部屋数)が0、1、2、3、4、5のそれぞれの場合について、ボーナス係数が1.00倍、1.05倍、1.10倍、1.15倍、1.20倍、1.25倍に設定されている。例えば、占拠済みの部屋数に応じて、図11に示すポイントにボーナス係数を乗じたポイントが付与される。即ち、報酬付与部317は、占拠した時点で同じチームの占拠済みの部屋の数が多いほど高いポイントを付与する。
【0083】
このようにすることで、同じ時間帯に同じチームのユーザが一気に攻めることでより多くのポイントを得ることができるため、時間帯による戦略性をユーザに考えさせることができる。
【0084】
なお、部屋に応じたポイントとは、部屋レベル(占拠の難易度)に応じたポイントに限られるものではなく、例えば、部屋の大きさ(広さ)などに応じたポイントであってもよい。例えば、報酬付与部317は、占拠した部屋が大きい(広い)ほど付与するポイントを高くしてもよい。
【0085】
・「NPCの討伐」によるポイント付与
報酬付与部317は、討伐(HPを0にする)した対戦相手チームの通常NPCの種類に応じてポイントを付与する。複数のユーザの操作に基づいて討伐した場合には、討伐時に与えたダメージに応じた割合でポイントが割り振られる。例えば、通常NPCにはレベルが設定されており、レベルに応じたポイントが設定されている。
また、ボスNPCにもレベルが設定されており、ボスNPCを討伐すると次回の出現時には討伐したボスNPCよりレベルの高いボスNPCが出現する。レベルが高いボスNPCほど討伐時に付与されるポイントが高くなる。ボスNPCの討伐により付与されるポイントは、通常NPCの討伐により付与されるポイントに比較して高いため、ボス出現中は両方のチームがボス部屋に集まって討伐することになる。ボスNPCは通常NPCとは異なり両方のチームから攻撃可能なため、両方のチームでダメージを与えた場合には、討伐時にダメージ量に応じて各チームにポイントが割り振られる。
【0086】
・「アシスト」によるポイント付与
報酬付与部317は、同じチームのユーザが操作するプレイヤキャラクタの攻撃力をアップ(バフ)、または対戦相手チームの通常NPCの防御力をダウン(デバフ)させることにより、予め設定されたポイント(例えば、50ポイントなど)を付与する。
【0087】
(部屋占拠時ボーナス)
報酬付与部317は、部屋が占拠されると、占拠したチームに対してボーナスとして有利な効果が発生(例えば、ランダムに発生)させてもよい。例えば、報酬付与部317は、通常部屋に存在する最後の通常NPCが討伐されると、上記の有利な効果を発生させる。有利な効果とは、例えば、占拠した部屋に強力な仲間の通常NPCが出現する、占拠した部屋に出現する仲間の通常NPCの数が増える、自チームの全プレイヤキャラクタの攻撃力がアップ(バフ)する、などである。このように、報酬付与部317は、チームが占拠した部屋では、そのチームのユーザに対して該ユーザの操作に基づくプレイの進行に有利な効果を発生させてもよい。
【0088】
〔第1の実施形態のまとめ〕
以上説明してきたように、本実施形態に係るゲームシステム1は、キャラクタ制御部112(キャラクタ移動部の一例)と、占拠判定部315(領域判定部の一例)と、勝敗判定部316とを備えている。キャラクタ制御部112は、複数のチームのそれぞれに属するユーザ情報(例えば、ユーザID)により識別されるユーザ毎の操作に基づいて、複数のチームに共通の複数の部屋(領域の一例)を有するフィールド内でユーザ情報毎に関連付けられたプレイヤキャラクタ(キャラクタの一例)を移動させる。占拠判定部315は、ユーザの操作結果が所定の占拠条件(所定の条件の一例)を満たしたか否かに基づいて、部屋(領域の一例)をいずれのチームに関連付けるか否か(例えば、いずれのチームの占拠とするか)を判定する。勝敗判定部316は、占拠判定部315による判定結果に基づいて、複数のチームによる対戦の勝敗を判定する。
【0089】
これにより、ゲームシステム1は、各ユーザが操作することによりフィールド内でプレイヤキャラクタを移動させるチーム対戦型のアクションゲームにおいて、部屋(領域の一例)を占拠しあうことで勝敗を決するという新たな楽しみを提供することができる。例えば、従来のチーム対戦型のアクションゲームでは、どちらのチームがより多くの対戦相手(敵)のキャラクタを討伐するか、或いは最終的な目的地にどちらのチームが先に到達するかなどによって勝敗が決するといったものが多かったため、ゲームの進行途中でどちらのチームが優勢であるかがリアルタイムで分かり難いことがあったが、本実施形態では、常に部屋の占拠数でどちらのチームが優勢であるかが分かるため、緊張感が途切れることなくユーザにプレイさせることができる。また、1体1の対戦で領域を取り合うゲームと比較した場合、本実施形態ではチーム対戦であることから、チームとしての協力プレイや、敵味方の両方に複数のプレイヤキャラクタが登場することなどから、より戦略性の高いゲームを提供することができる。
【0090】
例えば、ゲームシステム1は、部屋(領域の一例)においてNPC(通常NPCまたはボスNPC)を制御する通常NPC制御部113またはボスNPC制御部312(NPC制御部の一例)を備えている。そして、占拠判定部315(領域判定部の一例)は、部屋においてNPC(通常NPCまたはボスNPC)の討伐状況が所定の占拠条件を満たした場合、部屋をいずれのチームに関連付けるか否かを判定する。
【0091】
これにより、ゲームシステム1は、フィールド内の複数の部屋のそれぞれに出現する通常NPCまたはボスNPCを討伐することで、それぞれの部屋を占拠することができるため、各チームの対戦相手を同じ条件とすることができ、公平性を保つことができる。
【0092】
例えば、通常NPCの討伐状況は、通常部屋(領域の一例)において出現している通常NPCの数である。所定の占拠条件は、例えば、その部屋に存在する通常NPCのすべてが討伐される(HPが「0」になる)ことである(即ち、通常NPCの数が0になること)。なお、通常部屋における上記所定の占拠条件は、その部屋に存在する通常NPCのすべてが討伐される(HPが「0」になる)ことに限られるものではなく、他の条件としてもよい。例えば、所定の占拠条件は、その部屋に存在する通常NPCの数が所定数以下(例えば、2体以下)になること、または、その部屋に存在する通常NPCの討伐した数が所定数以上(例えば、10体以上)になることとしてもよい。また、ボス部屋の場合、上記所定の占拠条件は、ボスNPCが討伐される(HPが「0」になる)こととなる。
【0093】
これにより、ゲームシステム1は、通常部屋に出現している通常NPCの数が所定の占拠条件を満たすことで(例えば、通常NPCの数が0になることで)、その通常部屋を占拠することができるため、占拠条件が分かりやすい。また、チームメンバーと協力することで早く占拠できるため、ユーザがチームで戦っている一体感を得ることができる。
【0094】
例えば、通常部屋(領域の一例)における通常NPC(NPCの一例)は、複数のチームのうちのいずれか一つのチームに対応している。これにより、ゲームシステム1は、対戦相手がNPCでありながら、対戦相手のチームと戦っているのと同様の状況とすることができ、ユーザがチーム対戦であることを実感しながらプレイ可能とすることができる。
【0095】
なお、NPCとの対戦に代えて、それぞれの部屋で、チーム同士のプレイヤキャラクタの対戦が行われるようにしてもよい。例えば、対戦相手のチームのプレイヤキャラクタを討伐することによって占拠できるようにしてもよい。
【0096】
また、勝敗判定部316は、占拠判定部315(領域判定部の一例)による判定結果により複数のチームのそれぞれに関連付けられた部屋(領域の一例)の数に基づいて、複数のチームによる対戦の勝敗を判定する。これにより、ゲームシステム1は、部屋の占拠数でチームの勝敗が決するため、ユーザにとって対戦中の状況も対戦が終了したときの結果も分かりやすい。また、ゲームシステム1は、対戦するフィールド内に占拠すべき部屋が複数あるため、どの部屋を占拠すべきか等戦略の幅を広げることができる。
【0097】
また、ゲームシステム1は、占拠判定部315(領域判定部の一例)により部屋(領域の一例)が関連付けられたチームまたは該チームに属するユーザ情報により識別されるユーザに対してポイントを付与する報酬付与部317を備えている。これにより、ゲームシステム1は、部屋を占拠したチームまたはチームのユーザに対してポイントを付与するため、占拠状況だけでない楽しみを付加することができる。例えば、ゲームシステム1は、ユーザ毎にポイントを付与する場合、チーム同士の対戦に加えて、チーム内のユーザ同士でも競い合える楽しみをユーザに与えることができる。
【0098】
例えば、報酬付与部317は、占拠判定部315(領域判定部の一例)により部屋(領域の一例)が関連付けられたチームまたは該チームに属するユーザ情報により識別されるユーザに対して、部屋に応じたポイントを付与する。例えば、報酬付与部317は、部屋レベルに応じたポイントを付与する。
【0099】
これにより、ゲームシステム1は、占拠した部屋(例えば、部屋レベル)によって付与されるポイントが異なるため、例えば、難易度の低い部屋を数多く占拠しようと試みるか、或いは、難易度の高い部屋を数は少なくとも占拠しようとするかといったことをチームの戦略として選択可能となるため、戦略性の高いゲームを提供できる。
【0100】
また、占拠判定部315(領域判定部の一例)は、複数のチームのいずれかのチームに関連付けられた部屋(領域の一例)において他のチームに属するユーザ情報により識別されるユーザの操作結果により所定の占拠条件が満たされた場合、該部屋を該他のチームまたは該他のチームに属するユーザ情報に対して関連付ける。そして、報酬付与部317は、同一の部屋において所定の占拠条件が満たされる度に、付与するポイントを増加させる。即ち、報酬付与部317は、同一の部屋において所定の占拠条件が満たされる度に、付与する報酬の価値を高くする。報酬の価値とは、例えば、報酬の量(例えば、ポイントの量)である。なお、報酬の価値は、勝敗判定に影響する度合い(例えば、ポイントの高低や、ポイントが勝敗に影響する度合い等)であってもよい。また、報酬の価値は、自チームの攻撃力がアップする量や、対戦相手チームの防御力がダウンする量といった対戦における有利さの度合いであってもよい。
【0101】
これにより、ゲームシステム1は、同一の部屋をチーム同士で占拠しあうことで占拠したときに付与されるポイントが高くなるため、各チームのユーザに対して繰り返し対戦する意欲を高めることができ、白熱したゲーム展開が期待できる。
【0102】
報酬付与部317は、占拠判定部315(領域判定部の一例)によりチームに関連付けられた部屋(領域の一例)が多いほど、該チームに領域が関連付けられた際に付与するポイントを増加させる。これにより、ゲームシステム1は、部屋を占拠すればする程、優位にゲームを進められるようにすることができる。
【0103】
なお、勝敗判定部316は、占拠判定部315(領域判定部の一例)による複数の部屋(領域の一例)のそれぞれに対する判定結果と、報酬付与部317により各チームまたは該チームに属するユーザ情報により識別されるユーザに対して付与されたポイントとに基づいて、複数のチームによる対戦の勝敗を判定する。これにより、ゲームシステム1は、部屋の占拠だけでなくポイントの取得も勝敗に影響することから、どの領域を占拠するかによって勝敗が左右されるため、戦略性の高いゲームを提供できる。
【0104】
なお、報酬付与部317は、ポイントの付与に限らず、アイテム、仮想通貨などを報酬として付与してもよい。
【0105】
また、報酬付与部317は、占拠判定部315(領域判定部の一例)によりチームに関連付けられた部屋(領域の一例)において、該チームに属するユーザ情報により識別されるユーザに対して該ユーザの操作に基づくプレイの進行に有利な効果を発生させてもよい。有利な効果とは、例えば、占拠した部屋に強力な仲間の通常NPCが出現する、占拠した部屋に出現する仲間の通常NPCの数が増える、自チームの全プレイヤキャラクタの攻撃力がアップ(バフ)する、などである。これにより、ゲームシステム1は、部屋を占拠すればする程、優位にゲームを進められるようにすることができる。
【0106】
上記プレイヤキャラクタ(キャラクタの一例)のそれぞれには、ユーザの操作に基づくプレイの進行に影響する特性が設定されている。これにより、ゲームシステム1は、プレイヤキャラクタの特性によって攻撃の種類や威力が変わるとともに、対戦相手の特性との組み合わせによる相性によっても優劣が生じるため、戦略性の高いゲームを提供できる。
【0107】
[第2の実施形態]
次に、本発明の第2の実施形態について説明する。本実施形態に係るゲームシステム1の基本的な構成は、第1の実施形態と同様であるので、本実施形態において特徴的な処理について説明する。本実施形態では、通常部屋に出現する通常NPCの出現方法の一例について説明する。通常部屋に存在する通常NPCの種類や初期数は部屋毎に設定されている。プレイヤキャラクタが通常NPCを倒しても所定時間(例えば10秒)経過するごとに1体ずつ復活(出現)する。通常NPCは、初期数になるまで復活する。つまり、通常部屋毎に設定された初期数が、その部屋に存在する通常NPCの上限数となる。即ち、通常NPC制御部113は、通常部屋に所定の時間間隔で通常NPCを出現させる。また、通常NPC制御部113は、通常部屋において、同時に出現中となる通常NPCが予め設定された上限数となるまでは、所定の時間間隔で出現させる。
【0108】
このように、通常NPCは討伐されても復活してくるため、一人で通常NPCを倒すよりはチームで協力して一つの部屋を一気に攻めて討伐した方が効率的に部屋を占拠できることになる。通常NPCの復活の時間は、部屋毎、かつ部屋レベル毎に決められており、部屋レベルが高いほど復活までの時間も短くなり、占拠の難易度が上がる。
【0109】
図13は、通常NPCの出現方法の設定例を示す図である。図示する例は、通常部屋A(部屋A)及び通常部屋B(部屋B)について、出現する通常NPC(出現NPC)と、初期数と、復活する際の出現時間(時間間隔)とが、部屋レベルごとに設定されている。通常部屋Aでは、出現する通常NPCがキャラクタAであり、部屋レベルが高い程、初期数が多くなり、復活する際の出現時間(時間間隔)が短くなるため、占拠の難易度が上がる。
【0110】
一方、通常部屋Bでは、レベル1(Lv1)からレベル3(Lv3)までは出現する通常NPCがキャラクタBであるが、レベル4(Lv4)及びレベル5(Lv5)では、出現する通常NPCにキャラクタCが追加される。このように、通常NPCは一つの部屋に複数の種類が存在してもよい。その場合、通常NPCの種類毎に初期数及び復活する際の出現時間(時間間隔)が設定されてもよい。この通常部屋Bでは、キャラクタB及びキャラクタCのそれぞれについて、初期数及び復活する際の出現時間(時間間隔)が設定されており、部屋レベルが高い程、それぞれの初期数が多くなり、それぞれの復活する際の出現時間(時間間隔)は短くなる。このように、通常部屋Bも部屋レベルが高い程、占拠の難易度が上がる。
【0111】
〔第2の実施形態のまとめ〕
以上説明したように、本実施形態に係るゲームシステム1において、キャラクタ制御部112(キャラクタ移動部の一例)は、チームに属するユーザ情報により識別されるユーザ毎の操作に基づいて、そのチーム内で共通の領域を有するフィールド(FLD)内でユーザ情報毎に関連付けられたキャラクタを移動させる。通常NPC制御部113(NPC制御部の一例)は、通常部屋(領域の一例)に所定の時間間隔で通常NPC(NPCの一例)を出現させる。また、占拠判定部315(領域判定部の一例)は、通常部屋において通常NPCの討伐状況が所定の条件を満たした場合、その通常部屋をチームに関連付けるか否かを判定する。勝敗判定部316は、占拠判定部315によりチームに関連付けられた通常部屋に基づいて、チームの勝敗を判定する。
【0112】
これにより、ゲームシステム1は、通常NPCが討伐されても所定の時間間隔で復活するため、通常部屋の占拠が一人では簡単にはできないようにし、チームでより協力したプレイを必要にすることができる。よって、ゲームシステム1は、チーム戦の意識の高いゲームを提供できる。
【0113】
例えば、通常NPCの討伐状況は、通常部屋(領域の一例)において出現している通常NPCの数である。所定の占拠条件は、例えば、その部屋に存在する通常NPCのすべてが討伐される(HPが「0」になる)ことである(即ち、通常NPCの数が0になること)。なお、通常部屋における上記所定の占拠条件は、その部屋に存在する通常NPCのすべてが討伐される(HPが「0」になる)ことに限られるものではなく、他の条件としてもよい。例えば、所定の占拠条件は、その部屋に存在する通常NPCの数が所定数以下(例えば、2体以下)になること、または、その部屋に存在する通常NPCの討伐した数が所定数以上(例えば、10体以上)になることとしてもよい。また、ボス部屋の場合、上記所定の占拠条件は、ボスNPCが討伐される(HPが「0」になる)こととなる。
【0114】
これにより、ゲームシステム1は、通常部屋に所定の時間間隔で出現する通常NPCの数が所定の占拠条件を満たすことで(例えば、通常NPCの数が0になることで)、その通常部屋を占拠することができるため、占拠条件が分かりやすい。また、チームメンバーと協力することで早く占拠できるため、ユーザがチームで戦っている一体感を得ることができる。
【0115】
通常NPC制御部113は、通常部屋(領域の一例)において、同時に出現中となる通常NPC(NPCの一例)が予め設定された上限数となるまでは、所定の時間間隔で出現させる。予め設定された上限数とは、例えば、通常部屋に最初に存在する(出現する)通常NPCの初期数である。これにより、ゲームシステム1は、通常部屋に最初に存在する(出現する)通常NPCの初期数までは討伐されても復活してくるため、通常部屋の占拠が一人では簡単にはできないようにし、チームで協力したプレイを必要にすることができる。よって、ゲームシステム1は、チーム戦の意識の高いゲームを提供できる。
【0116】
通常NPC制御部113は、フィールド内に通常部屋(領域の一例)が複数ある場合、複数の通常部屋毎に、通常NPC(NPCの一例)を出現させる時間間隔、または同時に出現中となる通常NPCの上限数を制御する。これにより、ゲームシステム1は、部屋毎に占拠の難易度を設定することができる。
【0117】
通常NPC制御部113は、同一の通常部屋(領域の一例)において所定の占拠条件(所定の条件の一例)が満たされる度に、該通常部屋において通常NPC(NPCの一例)を出現させる時間間隔を減少、または通常NPCを同時に出現可能な上限数を増加させる。これにより、ゲームシステム1は、同一の部屋をチーム同士で占拠しあうことでその部屋を占拠する難易度が高くなるため、よりチームで協力したプレイが必要となり、白熱したゲーム展開が期待できる。
【0118】
なお、本実施形態では、通常部屋に最初に初期数の通常NPCが存在し、通常NPCが討伐されても初期数までは所定の時間間隔で復活可能な例を説明したが、通常部屋には最初に通常NPCが存在せず、所定の時間間隔で予め設定された上限数まで出現または復活するようにしてもよい。
【0119】
[第3の実施形態]
次に、本発明の第3の実施形態について説明する。本実施形態に係るゲームシステム1の基本的な構成は、第1の実施形態と同様であるので、本実施形態において特徴的な処理について説明する。本実施形態では、複数のゲーム装置10で多人数対戦を行うオンラインゲームで発生し得るタイムラグによる影響を抑制する処理について説明する。従来から、オンラインのアクションゲームなどリアルタイム性のあるゲームでは、プレイヤキャラクタやNPCに関する管理(HPの値やマップ上の位置、攻撃の発動状態等)はサーバ(あるいはサーバと同等機能を有するホスト端末)によって一元管理されるのが一般的である。各端末からの操作情報がサーバに集約され処理結果が、各端末に返され、それに基づいて各端末は描画等の処理を行う。
【0120】
ここで、同じNPCに対してほぼ同時刻に別々の端末から討伐可能な攻撃力で攻撃した場合、攻撃した端末のいずれからも攻撃したように見えるが、結果としてはいずれか一つの端末でしか討伐したことにならない。討伐できなかった端末のユーザは、攻撃したはずなのに討伐できなかったという祖語が起こり得る。端末から攻撃した情報を送り、サーバで処理し、処理結果を再び端末へ送信する間のタイムラグが通信によって起こるためである。特にモバイル端末のような必ずしも安定した通信環境が確保できないような端末である場合や、サーバが国外にあるなど物理的に遠方にあるような場合には、このような問題が顕著になることがある。
【0121】
そこで第1の実施形態で説明したように、ゲームシステム1では、通常NPCには陣営(チーム)の設定があり、いずれかのチームからしか攻撃することができない仕様となっている。例えば、青チームのユーザが操作するゲーム装置10の対戦制御部114は、青チームのユーザの操作に基づいて、青チームから赤チーム陣営の通常NPCへの攻撃を制御するとともに、青チームから青チーム陣営の通常NPCへの攻撃を制限する。一方、赤チームのユーザが操作するゲーム装置10の対戦制御部114は、赤チームのユーザの操作に基づいて、赤チームから青チーム陣営の通常NPCへの攻撃を制御するとともに、赤チームから赤チーム陣営の通常NPCへの攻撃を制限する。ここで、攻撃の制限とは、例えば、攻撃できないこと、または攻撃しても当たり判定がないことなどである。
【0122】
これにより、攻撃したはずなのに討伐できなかったという祖語を緩和することができる。例えば、通常NPCは青チーム及び赤チームの双方から攻撃されることがないため、チーム間での上記のような祖語は起こらないことになる。ただし、チーム内のプレイヤキャラクタ同士では上記のような祖語は起こり得ることになるが、チーム対戦型のゲームであるため、対戦相手同士で起こるより影響は少ない。
【0123】
また、ボスNPCは、両陣営双方(例えば、青チーム及び赤チームの双方)から攻撃可能であるため、攻撃したはずなのに討伐できなかったという祖語が起こり得ることになる。しかしながら、そもそもボスNPCは、通常NPCに比較して、HP、攻撃力、防御力などが高く設定されており、両チームからの多人数の攻撃によって討伐されるものである。そのため、討伐時(最後のとどめ)の攻撃に祖語は起こり得るものの、それまでの両チームからの攻撃に関してはその順番が入れ替わる可能性はあるが、大きな祖語とはなり得ない。また、従来のゲームでは、ボスNPCの討伐(最後のとどめ)によってボーナスポイントが付与されるという仕様もあるが、このようなボーナスポイントを本実施形態では付与しないことにより、上記の祖語によるゲームの勝敗への影響を最小限にすることができる。
【0124】
また、ゲームシステム1では、対戦相手となるプレイヤキャラクタ同士の攻撃に関しても攻撃を制限している。例えば、対戦制御部114は、プレイヤキャラクタから通常NPCへの攻撃によってその通常NPCへ与えるダメージに比較して、該プレイヤキャラクタから他のチームのプレイヤキャラクタへの攻撃によって該他のチームのプレイヤキャラクタへ与えるダメージが小さくなるように制限する。つまり、プレイヤキャラクタ同士で直接攻撃等の対戦を行うことによるメリットを少なくし、プレイヤキャラクタ同士での対戦の動機となる要因を減らしている。具体的には、対戦相手のプレイヤキャラクタに対しては一応は攻撃が可能であるが、その場合のダメージが通常NPCの場合のダメージより小さい値、例えば最小値(例えば、1ポイント)に制限される。なお、対戦相手のプレイヤキャラタに対する攻撃によるダメージは、「0」(ダメージなし)であってもよい。
【0125】
なお、対戦制御部114は、プレイヤキャラクタから対戦相手のプレイヤキャラクタへの攻撃によって、その対戦相手のプレイヤキャラクタの活動を制限させてもよい。活動の制限とは、例えば、特定の行動(移動、攻撃等)を不可とすること、特定の動作の速度を制限すること(例えば、移動速度を遅くすること)、特定の攻撃を制限すること(例えば、攻撃力を低下させること)、または活動に範囲を制限すること(移動可能範囲が狭くなること)などである。例えば、対戦制御部114は、プレイヤキャラクタから対戦相手のプレイヤキャラクタへの攻撃によって、その対戦相手のプレイヤキャラクタへダメージ(例えば、最小値)を与えることに加えて、または代えて、一定時間(例えば2秒)その対戦相手のプレイヤキャラクタの動きを止めてもよい。これにより、対戦相手のプレイヤキャラクタを攻撃する場合、ダメージを与えるより動きを止めることが目的となる。
【0126】
以下に、通常NPCとボスNPCとの処理の違いについて整理する。通常NPCは一方のチームのプレイヤキャラクタからしか攻撃できないのに対して、ボスNPCはいずれのチームのプレイヤキャラクタから攻撃が可能となっている。そのため、両者の処理は、位置、動き、状態などについて、各ゲーム装置10で同じになるように制御する同期処理となるか、或いはゲーム装置10毎に制御する非同期処理となるかが異なる。
【0127】
図14は、通常NPCとボスNPCとの処理の違いを示す図である。通常NPCの処理では、通常NPCのフィールド内の位置、通常NPCの動き(モーション)、攻撃によるエフェクトの表示、及び攻撃による当たり判定についての処理が非同期処理(即ち、ゲーム装置10毎の制御)となり、ダメージによって変化するHP残量や、消滅(死亡)などの状態異常についての処理が、各ゲーム装置10で同じになるように同期処理となる。一方、ボスNPCの処理では、ボスNPCのフィールド内の位置、ボスNPCの動き(モーション)、攻撃によるエフェクトの表示、ダメージによって変化するHP残量、及び消滅(死亡)などの状態異常についての処理が同期処理となり、攻撃による当たり判定が非同期処理となる。なお、プレイヤキャラクタの位置については、同期処理となる。同期処理となる部分は、ゲームサーバ30で管理され、非同期処理となる部分は、ゲーム装置10で管理される。
【0128】
つまり、通常NPCのフィールド内の位置や動き(モーション)、攻撃(技)を発動した場合の効果(エフェクト)など基本的にはリアルタイム性の高いアクションは各ゲーム装置10(端末側)で管理し、討伐した情報やダメージ量に関する情報のみをゲームサーバ30(サーバ側)で管理している。よって、通常NPCは、部屋の中の位置がゲーム装置10毎に異なることも有り得る。これに対しボスNPCのフィールド内の位置等はゲームサーバ30(サーバ側)で管理されている。そのため、ボスNPCの位置は、各ゲーム装置10でタイムラグはあるものの基本的には違いがない。
【0129】
例えば、仮にボスNPCのフィールド内の位置を非同期としてしまうと、同じボスNPCと対戦する各チームのプレイヤキャラクタとの位置関係の祖語が顕著になる。例えば、対戦相手のプレイヤキャラクタを攻撃して動きを封じて足止めをし、ボスNPCに近づけないようにしていたつもりが、対戦相手のプレイヤキャラクタのゲーム装置10ではボスNPCが近い位置にいて攻撃可能となっている、といったような各チームの戦略に関する部分で整合性が取れなくなってしまう。このようなことを防ぐため、いずれのチームからも攻撃可能なボスNPCについては、フィールド内の位置等に関して同期処理が行われる。
【0130】
〔第3の実施形態のまとめ〕
以上説明したように、本実施形態に係るゲームシステム1において、通常NPC制御部113(第1NPC制御部の一例)は、フィールド内で通常NPC(第1のNPCの一例)を制御する。また、対戦制御部114は、複数のチームのうち青チーム(第1のチームの一例)に属するユーザ情報により識別されるユーザの操作に基づいて、青チームから赤チーム陣営の通常NPC(例えば、第1のNPCの一例)への攻撃を制御する。一方、対戦制御部114は、複数のチームのうち赤チーム(第2のチームの一例)から赤チーム陣営の通常NPCへの攻撃を制限する。
【0131】
これにより、ゲームシステム1は、通常NPCに対してはいずれかのチームからしか攻撃することができないため(例えば、青チーム及び赤チームの双方から攻撃できないため)、オンラインゲームにおいて発生し得る、攻撃したはずなのに討伐できなかったという祖語が起きないように抑制することができる。即ち、ゲームシステム1は、オンラインゲームで発生し得るタイムラグによる影響を抑制することができる。
【0132】
対戦制御部114は、青チーム(第1のチームの一例)に属するユーザ情報により識別されるユーザの操作に基づいて、赤チーム(第2のチームの一例)に属するユーザ情報により識別されるユーザ毎の操作に基づいて活動するプレイヤキャラクタ(第2のキャラクタの一例)への攻撃を制御する場合、青チーム(第1のチームの一例)への攻撃によって赤チーム陣営の通常NPC(例えば、第1のNPCの一例)へ与えるダメージ(影響の一例)に比較して、赤チームのプレイヤキャラクタ(第2のキャラクタの一例)への攻撃によって、その赤チームのプレイヤキャラクタへ与えるダメージが小さくなるように制限する。なお、対戦制御部114は、赤チームから青チームのプレイヤキャラクタへ攻撃の場合も同様に、青チームのプレイヤキャラクタへ与える影響が小さくなるように制限する。
【0133】
これにより、ゲームシステム1は、プレイヤキャラクタ同士の対戦では、攻撃したはずなのに討伐できなかったという祖語が発生し得るが、攻撃によるダメージを極端に小さくすることで、プレイヤキャラクタ同士の対戦を行うことによるメリットを少なくし、プレイヤキャラクタ同士での対戦の動機となる要因を減らすことができるため、上記の齟齬による影響を抑制することができる。
【0134】
また、対戦制御部114は、青チーム(第1のチームの一例)から赤チームのプレイヤキャラクタ(第2のキャラクタの一例)への攻撃によって、その赤チームのプレイヤキャラクタの活動を制限させてもよい。同様に、対戦制御部114は、赤チームから青チームのプレイヤキャラクタへの攻撃によって、その青チームのプレイヤキャラクタの活動を制限させてもよい。
【0135】
これにより、ゲームシステム1は、プレイヤキャラクタ同士の対戦では、対戦相手のプレイヤキャラクタにダメージを与えるより動きを止めることが目的となるため、攻撃したはずなのに討伐できなかったという祖語が起きるのを抑制できる。
【0136】
また、ゲームシステム1は、通常NPC制御部113(第1NPC制御部の一例)を備える複数のゲーム装置10(端末装置の一例)と、複数のゲーム装置10と通信接続されるゲームサーバ30(サーバ装置の一例)とを備えている。そして、通常NPC制御部113は、フィールド内で通常NPC(第1のNPCの一例)の位置を、複数のゲーム装置10毎に制御する。即ち、複数のゲーム装置10のそれぞれの通常NPC制御部113が、複数のゲーム装置10毎にフィールド内で通常NPCを制御する。
【0137】
これにより、ゲームシステム1は、通常NPCのフィールド内の位置や動き(モーション)、攻撃(技)を発動した場合の効果(エフェクト)など基本的にはリアルタイム性の高いアクションは各ゲーム装置10(端末側)で管理するため、通信によるタイムラグによる影響が生じないように抑制することができる。
【0138】
また、ゲームサーバ30(サーバ装置の一例)は、フィールド内でボスNPC(第2のNPCの一例)を制御するボスNPC制御部312(第2NPC制御部の一例)を備えている。対戦制御部114は、青チーム(第1のチームの一例)に属するユーザ情報により識別されるユーザの操作に基づいて、青チームからボスNPCへの攻撃を制御する。同様に、対戦制御部114は、赤チーム(第2のチームの一例)に属するユーザ情報により識別されるユーザの操作に基づいて、赤チームからボスNPCへの攻撃を制御する。そして、ボスNPC制御部312は、フィールド内でボスNPCの位置を、複数のゲーム装置10(端末装置の一例)で同じ位置になるように制御する。
【0139】
これにより、ゲームシステム1は、両陣営双方(例えば、青チーム及び赤チームの双方)から攻撃されるボスNPCについては、各ゲーム装置10で攻撃対象の位置が同じになるように同期することができるため、同一攻撃対象に対する複数ユーザの戦闘において整合性を確保できる。
【0140】
ボスNPC(第2のNPCの一例)を討伐するには、通常NPC(第1のNPCの一例)を討伐するのに比較して多くの攻撃を要する。例えば、ボスNPCは、通常NPCよりHPが高く設定されている。なお、ボスNPCは、通常NPCより防御力が高く設定されていてもよい。また、プレイヤキャラクタが通常NPCを攻撃する際の攻撃力よりボスNPCを攻撃する際の攻撃力が低下してもよい。
【0141】
これにより、ゲームシステム1は、討伐時(最後のとどめ)の攻撃については、攻撃したはずなのに討伐できなかったという祖語が起こり得るものの、それまでの両チームからの攻撃に関してはその順番が入れ替わってとしても大きな祖語とはなり得ないため、討伐するまでの攻撃全体として上記の齟齬による影響を少なくすることができる。
【0142】
[第4の実施形態]
次に、本発明の第4の実施形態について説明する。本実施形態に係るゲームシステム1の基本的な構成は、第1の実施形態と同様であるので、本実施形態において特徴的な処理について説明する。第1の実施形態では、ゲームの基本的なルールとして、制限時間(例えば3分)内に占拠した部屋の数が多いチームが勝利となることについて説明したが、対戦相手との実力差によっては、制限時間を待たずして戦況の優劣が明確となり実質的に勝敗が決着してしまうような場合がある。このような場合、制限時間までプレイを継続しなければならないと、そのプレイ時間がユーザにとって無駄な時間に感じることがある。そこで、本実施形態では、例外的に対戦プレイによる勝敗が制限時間前に決定される例について説明する。
【0143】
本実施形態では、勝敗判定部316は、各チームによる部屋の占拠状況(即ち、複数の部屋(通常部屋、ボス部屋など)のチームへの関連付け状況)に基づいて、制限時間に達する前であっても、チームの勝敗を確定することがある。例えば、勝敗判定部316は、各チームによる部屋の占拠状況が予め設定された状況になった場合、該状況が所定時間(例えば、30秒)維持されたことを条件として、制限時間に達する前であってもチームの勝敗を確定する。予め設定された部屋の占拠状況とは、例えば、占拠可能な部屋のすべてを一方のチームが占拠した状況である。この場合、勝敗判定部316は、一方のチームがすべての部屋を占拠した状況が所定時間(例えば、30秒)維持されると、制限時間に達する前であってもチームの勝敗を確定する。具体的には、勝敗判定部316は、全部屋を占拠したチームの勝利とする。つまり、勝敗判定部316は、各チームによる部屋の占拠状況に基づいて、チーム間に実力差があって制限時間を待たずして戦況の優劣が明確なった場合には、所謂コールドゲームの様に、制限時間前に勝敗を確定して対戦プレイを終了する。
【0144】
また、チームの勝敗を確定する条件となる上記所定時間を示す情報が、対戦プレイのプレイ画像が表示されるプレイ画面に表示されてもよい。例えば、表示制御部115は、一方のチームがすべての部屋を占拠した状況になると、上記所定時間(例えば、30秒)となるまでの時間を示す情報として上記所定時間までのカウントダウン表示を開始する。そして、表示制御部115は、一方のチームがすべての部屋を占拠した状況が維持されている間はカウントダウン表示を継続し、上記所定時間が経過した場合(カウントダウンが0秒になった場合)、または上記所定時間が経過する前に他方のチームに1部屋以上占拠し返された場合、カウントダウン表示を終了する。なお、プレイ画面に表示される上記所定時間(例えば、30秒)となるまでの時間を示す情報は、カウントダウン表示(残時間)であってもよいし、カウントアップ表示(経過時間)であってもよい。
【0145】
また、勝敗判定部316は、一方のチームがすべての部屋を占拠した状況となった後、該状況を所定時間(例えば、30秒)維持できずに他方のチームに1部屋以上占拠し返された場合、再び、上記一方のチームが占拠可能な部屋のすべてを占拠した状況となると、チームの勝敗を確定する条件となる上記所定時間を短縮(例えば、30秒から15秒に短縮)してもよい。つまり、勝敗判定部316は、いずれかのチームにより全部屋が占拠された状況が繰り返し生じた場合、全部屋が占拠された回数に応じて、チームの勝敗を確定する条件となる上記所定時間を短縮してもよい。
【0146】
このように全部屋が占拠された回数が増すほど上記所定時間が短くなる。この全部屋占拠の回数は、チーム毎にカウントされる回数である。つまり、同じチームによって全部屋占拠されることが繰り返されると、その度に上記所定時間が短縮される。例えば、最初に青チームが全部屋占拠して30秒のカウントが終了する前にこの全部屋占拠の維持に失敗し、再び青チームが全部屋占拠した場合には15秒のカウントとなるが、青チームではなく赤チームが初めて全部屋占拠した場合には15秒ではなく30秒のカウントとなる。このカウントダウンによって全部屋占拠された側のチームに巻き返しのチャンスとなる時間を与えているのは、何らかの要因で一気に攻められて実力を出せずに対戦が終了してしまうような不合理をなくすためである。
【0147】
なお、制限時間に達するまでの残時間(対戦の残り時間)が上記所定時間以下である場合には全部屋占拠してもカウントダウン表示はされない。これは、例えば対戦の残り時間が20秒の時に一方のチームが全部屋占拠した場合、30秒のカウントダウンを開始してもカウントダウンが「0」になる前に制限時間により対戦が終了してしまうため、カウントダウン表示を行う意味がないためである。
【0148】
次に、上述した対戦プレイにおいていずれかのチームにより全部屋が占拠された際にカウントダウンを行うカウントダウン処理の動作について説明する。
図15は、本実施形態に係る対戦プレイにおけるカウントダウン処理の一例を示すフローチャートである。
【0149】
対戦プレイが開始されると、占拠判定部315は、部屋が占拠されたか否かを判定する(ステップS200)。部屋が占拠されていないと判定された場合(NO)、占拠判定部315は、ステップS200の処理に戻し、部屋が占拠されたか否かを判定する。一方、部屋が占拠されたと判定された場合(YES)、占拠判定部315は、いずれかのチームにより全部屋が占拠されたか否かを判定する(ステップS202)。
【0150】
いずれかのチームにより全部屋が占拠されていないと判定された場合(NO)、占拠判定部315は、ステップS200の処理に戻し、部屋が占拠されたか否かを判定する。一方、いずれかのチームにより全部屋が占拠されたと判定された場合(YES)、占拠判定部315は、そのチームにより全部屋が占拠された回数を判定する(ステップS204)。
【0151】
そのチームにより全部屋が占拠された回数が初回(1回目)と判定された場合、勝敗判定部316は、制限時間の残り時間(対戦の残り時間)が30秒以上あるか否かと判定する(ステップS206)。残り時間が30秒未満であると判定された場合(NO)、勝敗判定部316は、カウントダウンを行わないで、ステップS200の処理に戻す。これにより、制限時間になるまで対戦プレイが継続される。一方、残り時間が30秒以上であると判定された場合(YES)、勝敗判定部316は、30秒のカウントダウンを開始する(ステップS208)。
【0152】
次に、占拠判定部315は、部屋が占拠されたか(占拠し返されたか)否かを判定する(ステップS210)。即ち、占拠判定部315は、全部屋が占拠されている状態が維持されているか否かを判定する。カウントダウンが「0」になる前に一つでも部屋が占拠し返された(全部屋占拠が維持されなかった)と判定された場合(YES)、勝敗判定部316は、カウントダウンを途中で終了し、ステップS200の処理に戻す。これにより、通常の対戦プレイに戻る。一方、部屋が占拠されていない(全部屋占拠が維持されている)と判定された場合(NO)、勝敗判定部316は、カウントダウンが「0」になったか否かを判定する(ステップS212)。カウントダウンが「0」になっていないと判定された場合(NO)、勝敗判定部316は、ステップS210の処理に戻しカウントダウンを継続する。一方、カウントダウンが「0」になったと判定された場合(YES)、勝敗判定部316は、全部屋占拠したチームの勝利(コールドゲーム)とし、その時点で対戦プレイを終了する。
【0153】
一方、ステップS210において、30秒経過する前に全部屋占拠が維持されなかったと判定されたことにより、30秒のカウントダウンが途中で終了して通常の対戦プレイに戻った後、この状態で再び前回全占拠した側のチームが全部屋占拠すると、ステップS204においてそのチームにより全部屋が占拠された回数が2回目と判定される。2回目のカウントダウンは15秒となり初回よりは短くなる。勝敗判定部316は、制限時間の残り時間(対戦の残り時間)が15秒以上あるか否かと判定する(ステップS214)。残り時間が15秒未満であると判定された場合(NO)、勝敗判定部316は、カウントダウンを行わないで、ステップS200の処理に戻す。これにより、制限時間になるまで対戦プレイが継続される。一方、残り時間が15秒以上であると判定された場合(YES)、勝敗判定部316は、15秒のカウントダウンを開始する(ステップS216)。
【0154】
次に、占拠判定部315は、部屋が占拠されたか(占拠し返されたか)否かを判定する(ステップS218)。即ち、占拠判定部315は、全部屋が占拠されている状態が維持されているか否かを判定する。カウントダウンが「0」になる前に一つでも部屋が占拠し返された(全部屋占拠が維持されなかった)と判定された場合(YES)、勝敗判定部316は、カウントダウンを途中で終了し、ステップS200の処理に戻す。これにより、通常の対戦プレイに戻る。一方、部屋が占拠されていない(全部屋占拠が維持されている)と判定された場合(NO)、勝敗判定部316は、カウントダウンが「0」になったか否かを判定する(ステップS220)。カウントダウンが「0」になっていないと判定された場合(NO)、勝敗判定部316は、ステップS218の処理に戻しカウントダウンを継続する。一方、カウントダウンが「0」になったと判定された場合(YES)、勝敗判定部316は、全部屋占拠したチームの勝利(コールドゲーム)とし、その時点で対戦プレイを終了する。
【0155】
一方、ステップS218において、15秒経過する前に全部屋占拠が維持されなかったと判定されたことにより、15秒のカウントダウンが途中で終了して通常の対戦プレイに戻った後、この状態で再び前回全占拠した側のチームが全部屋占拠すると、ステップS204においてそのチームにより全部屋が占拠された回数が3回目と判定される。同一チームによる3回目の全部屋占拠の場合には、勝敗判定部316は、カウントダウンをしないで、その時点で全部屋占拠したチームの勝利(コールドゲーム)とし、対戦プレイを終了する。
【0156】
〔第4の実施形態のまとめ〕
以上説明したように、本実施形態に係るゲームシステム1において、占拠判定部315(領域判定部の一例)は、チームに属するユーザ情報により識別されるユーザの操作結果が所定の条件を満たしたか否かに基づいて、フィールド内の複数の部屋(領域の一例)のそれぞれをチームに関連付けるか否か(例えば、いずれのチームの占拠とするか)を判定する。勝敗判定部316は、予め設定された制限時間内における占拠判定部315による判定結果に基づいて、チームの勝敗を判定するとともに、各チームによる部屋の占拠状況(複数の領域のチームへの関連付け状況の一例)に基づいて、制限時間に達する前であってもチームの勝敗を確定する。
【0157】
これにより、ゲームシステム1は、チームを構成する複数のユーザがそれぞれのキャラクタを操作して敵キャラクタと戦闘するアクションゲームにおいて、制限時間を待たずして戦況の優劣が明確となり実質的に勝敗が決着してしまうような場合に、その時点で勝敗を確定して終了するため、ユーザにとって無駄なプレイ時間が生じることを抑制できる。
【0158】
また、勝敗判定部316は、各チームによる部屋の占拠状況(複数の領域のチームへの関連付け状況の一例)が予め設定された状況になった場合、該状況が所定時間維持されたことを条件として、制限時間に達する前であってもチームの勝敗を確定する。例えば、予め設定された部屋の占拠状況とは、占拠可能な部屋のすべてを一方のチームが占拠した状況(全部屋占拠)である。
【0159】
これにより、ゲームシステム1は、一方のチームによって全部屋占拠されたとしても、占拠された側のチームに巻き返しのチャンスとなる時間を与えることができる。よって、ゲームシステム1は、何らかの要因で一気に攻められて実力を出せずに対戦が終了してしまうような不合理が生じてしまことを抑制できる。
【0160】
なお、予め設定された部屋の占拠状況は、一方のチームが占拠した部屋の数と他方のチームが占拠した数との差が所定数以上となった状況としてもよいし、フィールド内の占拠可能な部屋のうち所定割合以上または所定数以上を一方のチームが占拠した状況としてもよい。また、予め設定された部屋の占拠状況は、一方のチームが他方のチームが占拠している部屋を占拠し返した割合や数に基づく状況であってもよい。
【0161】
また、本実施形態では、各チームによる部屋の占拠状況が予め設定された状況(例えば、全部屋占拠)になった場合、該状況が所定時間維持されたことを条件として、制限時間に達する前であってもチームの勝敗を確定する例を説明したが、占拠された側のチームに巻き返しのチャンスとなる時間を与えない場合、各チームによる部屋の占拠状況が予め設定された状況(例えば、全部屋占拠)になったことのみを条件として、制限時間に達する前であってもチームの勝敗を確定してもよい。
【0162】
また、勝敗判定部316は、各チームによる部屋の占拠状況(複数の領域のチームへの関連付け状況の一例)が予め設定された状況になった回数に応じて、上記所定時間を短縮する。これにより、ゲームシステム1は、全部屋占拠が繰り返された場合には、1回目の全部屋占拠のときよりも該チームが優勢であることがより確実と考えられるため、占拠された側のチームの巻き返しのチャンスとなる時間を短くし、全部屋占拠した側のチームのユーザにとって無駄なプレイ時間が生じることを抑制することができる。
【0163】
例えば、複数のチームによる対戦の場合、上記回数は、チーム毎にカウント(計数)される。これにより、ゲームシステム1は、一方のチームによる全部屋占拠した後に、他方のチームが全部屋占拠し返した場合には、戦況の優劣が明確になっていないと考えられるため、各チームに対して平等に巻き返しのチャンスとなる時間を与えることができる。
【0164】
また、表示制御部115は、各チームによる部屋の占拠状況(複数の領域のチームへの関連付け状況の一例)が予め設定された状況になった場合、上記所定時間となるまでの時間を示す情報を表示させる。これにより、ゲームシステム1は、対戦プレイ中のユーザに勝敗が確定するまでの時間をカウントダウンなどで提示するため、緊張感を高めることができる。また、ゲームシステム1は、勝敗が確定するまでの残り時間をユーザが把握し易くなるため、残り時間で何をするべきかの戦略をユーザが考え易くすることができる。
【0165】
表示制御部115は、各チームによる部屋の占拠状況(複数の領域のチームへの関連付け状況の一例)が予め設定された状況になった場合、制限時間に達するまでの残時間と上記所定時間とに基づいて、上記所定時間となるまでの時間を示す情報を表示させるか否かを判定する。例えば、表示制御部115は、制限時間に達するまでの残時間(対戦の残り時間)が上記所定時間以下である場合には全部屋占拠しても上記所定時間となるまでの時間を示す情報の表示(カウントダウン表示)を行わない。これにより、ゲームシステム1は、対戦の残り時間がカウントダウンの時間よりも短い場合にはカウントダウンを開始してもカウントダウンが「0」になる前に制限時間により対戦が終了してしまうため、意味のないカウントダウン表示を行わないようにすることができる。
【0166】
また、キャラクタ制御部112(キャラクタ移動部の一例)は、チームに属するユーザ情報により識別されるユーザ毎の操作に基づいて、ユーザに共通の複数の領域を有するフィールド内でユーザ情報毎に関連付けられたキャラクタを移動させる。これにより、ゲームシステム1は、制限時間を待たずして戦況の優劣が明確となり実質的に勝敗が決着してしまうような場合に、その時点で勝敗を確定して終了するため、ユーザが無駄にフィールド内でキャラクタを移動させる時間が生じることを抑制できる。
【0167】
[第5の実施形態]
次に、本発明の第5の実施形態について説明する。本実施形態に係るゲームシステム1の基本的な構成は、第1の実施形態と同様であるので、本実施形態において特徴的な処理について説明する。
【0168】
プレイヤキャラクタは攻撃を受けて死亡すると、スタート部屋から再スタートすることになる。死亡した場合、再スタートまで一定時間操作が不可となり活動が制限される(勝敗判定に関わるペナルティ)。そのため、できる限り死亡しないことがチームが勝つための条件の一つとなる。本実施形態では、プレイヤキャラクタが死亡する前段階としてチームメンバーによって復活させることが可能な仮死状態があることについて説明する。
【0169】
プレイヤキャラクタは、通常NPCやボスNPCなどから攻撃によりダメージを受けてHPが「0」になると、まず仮死状態となる。この時点ではプレイヤキャラクタは死亡していない。仮死状態でさらに所定値のダメージを受けると死亡状態となる。例えば、プレイヤキャラクタは、仮死状態となるとHPの値が若干戻り(例えば、「10」)、さらに攻撃を受けて再びHPが「0」になると死亡状態となる。仮死状態のプレイヤキャラクタは、同じチームのプレイヤキャラクタに基づいて仮死状態から通常状態に復活することができる。つまり、一旦HPが「0」になっても即死亡状態になるのではなく、復活のチャンスが与えられる。通常状態とは、出現してから仮死状態に至る前までの少なくともユーザの操作に基づいて移動可能な状態である。例えば、同じチームのプレイヤキャラクタが仮死状態となったプレイヤキャラクタに近づくと、プレイ画面上の仮死状態となったプレイヤキャラクタの近傍に、仮死状態となったプレイヤキャラクタを復活させる操作を受け付ける操作子として復活アイコンが表示される。この復活アイコンに対して操作がされると、仮死状態だったプレイヤキャラクタが通常状態に戻り、HPの値も復活する。このように、同じチームのメンバー(仲間)との協力により、チーム内で死亡してしまいそうなプレイヤキャラクタを、完全に死亡状態となってしまう前に助けることができる。
【0170】
プレイヤキャラクタは、仮死状態になると通常状態に比較して著しく能力が低下する。例えば、プレイヤキャラクタは、仮死状態になると攻撃力、防御力、及びHP等のパラメータが著しく低下する(仮死状態専用パラメータになる)。また、仮死状態になると、プレイヤキャラクタに設定されたスキル(対戦相手に大ダメージを与える攻撃やHPの回復など)が使用できなくなる。また、仮死状態になると、プレイヤキャラクタの移動速度やジャンプ力が通常状態より低下する。つまり、仮死状態は、死亡状態ではないが、通常状態より能力(攻撃力、防御力、及びHP等のパラメータ)が低下した状態であって、それによって、プレイヤキャラクタの活動が通常状態より制限される状態である。例えば、仮死状態のプレイヤキャラクタは、少しは動くことも戦うこともできるが、攻撃してもほとんどダメージを与えることができない。
【0171】
一方、死亡状態は、プレイヤキャラクタの活動が制限された状態(例えば、操作が全くできない状態)であって、且つ同じチームの他のプレイヤキャラクタによって通常状態に復活することが不可能な状態である。なお、死亡状態は、死亡してゲームオーバーとなる状態ではなく、引き続きゲームは進行し、一定時間操作が不可となる状態である。
【0172】
また、仮死状態になるとプレイ画面に表示される見た目も変化する。図16は、プレイヤキャラクタの状態毎の見た目の一例を示す図である。図示するように、通常状態では、見た目が人間である戦士のキャラクタであるが、仮死状態になると見た目が骸骨になる。また、死亡状態になると消滅する。例えば、ゲーム装置10-1においてユーザの操作に基づいて活動するプレイヤキャラクタが仮死状態である場合、ゲーム装置10-1の表示制御部115は、該仮死状態のプレイヤキャラクタを通常状態のプレイヤキャラクタと識別可能な表示態様で表示させる。また、ゲーム装置10-1においてユーザの操作に基づいて活動するプレイヤキャラクタが仮死状態である場合、ゲーム装置10-2の表示制御部115は、該仮死状態のプレイヤキャラクタをゲーム装置10-2において通常状態のプレイヤキャラクタと識別可能な表示態様で表示させる。
【0173】
なお、図16では、プレイヤキャラクタが通常状態から仮死状態になると、見た目が骸骨の表示態様に変更される例を示したが、このように表示内容そのものが変更されてもよいが、表示内容そのものは変更されなくてもよい。例えば、プレイヤキャラクタが通常状態から仮死状態になると、プレイ画面に表示されるプレイヤキャラクタの大きさが変更されてもよいし、点滅表示に変更されてもよいし、色または透過度が変更されてもよい。
【0174】
仮死状態になったプレイヤキャラクタは、攻撃力等が低下するため、戦果を上げることがほとんどできなくなり、また、防御力も低くなるため、少ないダメージで死亡状態になり易くなる。つまり、戦略的には一刻も早く仮死状態から脱する必要がある。そこで、同じチームのプレイヤキャラクタを、仮死状態になったプレイヤキャラクタの近く移動させることにより、仮死状態になったプレイヤキャラクタを通常状態に復活させることができる。よって、ゲームシステム1は、チーム内の協力の機会がより多いゲームを提供できる。
【0175】
図17は、本実施形態に係るキャラクタ制御部112の詳細構成の一例を示すブロック図である。図示するキャラクタ制御部112は、キャラクタ状態制御部1121と、復活制御部1122とを備えている。キャラクタ状態制御部1121は、通常状態のプレイヤキャラクタのHPが「0」になると、該プレイヤキャラクタを仮死状態に遷移させる。また、キャラクタ状態制御部1121は、仮死状態のプレイヤキャラクタがさらに攻撃を受けて、一時的に若干値が戻ったHPが再び「0」になると、該プレイヤキャラクタを死亡状態に遷移させる。
【0176】
復活制御部1122は、仮死状態のプレイヤキャラクタを、該プレイヤキャラクタと同じチームに属する他のプレイヤキャラクタに基づいて通常状態に復活させる。例えば、復活制御部1122は、仮死状態のプレイヤキャラクタを、該プレイヤキャラクタと同じチームに属する通常状態のプレイヤキャラクタとの位置関係に基づいて、通常状態に復活させる。具体的には、復活制御部1122は、仮死状態のプレイヤキャラクタに同じチームに属する通常状態のプレイヤキャラクタが近づいた場合、該仮死状態のプレイヤキャラクタを通常状態に復活させる操作を受け付ける復活アイコンを、プレイ画面に表示させるように指示する。そして、復活制御部1122は、復活アイコンに対して操作がされると、仮死状態だったプレイヤキャラクタをその場所で通常状態に戻し、HPの値も(例えば、初期値に)復活させる。
【0177】
一方、復活制御部1122は、死亡状態のプレイヤキャラクタを、死亡状態になってから所定時間(例えば、10秒)が経過することによって通常状態に遷移させる。例えば、復活制御部1122は、死亡状態のプレイヤキャラクタを通常状態に遷移させる場合、該プレイヤキャラクタのスタート部屋に配置する。つまり、プレイヤキャラクタが死亡すると、一定時間操作が不可となり、その後、スタート部屋からの再スタートとなる。
【0178】
次に、キャラクタ制御部112がプレイヤキャラクタの状態遷移を制御する状態遷移処理の動作について説明する。図18は、本実施形態に係る状態遷移処理の一例を示すフローチャートである。
【0179】
対戦プレイが開始されると、キャラクタ制御部112は、通常状態のプレイヤキャラクタを、該プレイヤキャラクタのチームのスタート部屋に配置する。このとき、プレイヤキャラクタのHPは初期値(例えば「1000」)である(ステップS300)。このプレイヤキャラクタは、ユーザの操作に基づいて、フィールド内を移動し各部屋で対戦相手(例えば、通常NPCやボスNPCなど)と戦闘を行う。
【0180】
キャラクタ制御部112は、通常状態のプレイヤキャラクタのHPが「0」になった否かを判定する(ステップS302)。HPが「0」になっていないと判定された場合(NO)、キャラクタ制御部112は、そのプレイヤキャラクタを通常状態のままとし、ステップS302の処理を再び行う。一方、HPが「0」になったと判定された場合(YES)、キャラクタ制御部112は、その通常状態のプレイヤキャラクタを仮死状態に遷移させる。また、キャラクタ制御部112は、そのプレイヤキャラクタのHPの値を若干(例えば、「10」に)戻す(ステップS304)。
【0181】
また、キャラクタ制御部112は、仮死状態のプレイヤキャラクタのHPが「0」になった否かを判定する(ステップS306)。HPが「0」になったと判定された場合(YES)、キャラクタ制御部112は、その仮死状態のプレイヤキャラクタを死亡状態に遷移させる(ステップS308)。そして、キャラクタ制御部112は、死亡状態に遷移してから所定時間が経過した後、ステップS300の処理に戻す(ステップS310)。そして、死亡状態から通常状態(例えば、HPは初期値(例えば「1000」))に戻したプレイヤキャラクタをスタート部屋に配置する(ステップS300)。これにより、死亡したプレイヤキャラクタは、一定時間操作が不可となった後、スタート部屋から再スタートとなる。
【0182】
一方、ステップS306においてHPが「0」になっていないと判定された場合(NO)、キャラクタ制御部112は、復活アイコンの表示条件を満たしたか否かを判定する(ステップS312)。復活アイコンの表示条件とは、仮死状態のプレイヤキャラクタに、同じチームの通常状態のキャラクタが近づくことである。例えば、キャラクタ制御部112は、仮死状態のプレイヤキャラクタに、同じチームの通常状態のキャラクタが所定の距離内に近づいたと判定した場合(例えば、仮死状態のプレイヤキャラクタに同じチームの通常状態のキャラクタが触れる位置関係になった場合、或いはプレイ画面上で重なる位置関係になった場合)、復活アイコンの表示条件を満たしたと判定する。
【0183】
復活アイコンの表示条件が満たされていないと判定された場合(NO)、キャラクタ制御部112は、ステップS306の処理に戻し、その仮死状態のプレイヤキャラクタのHPが「0」になった否かを判定する。一方、復活アイコンの表示条件が満たされたと判定された場合(YES)、キャラクタ制御部112は、復活アイコンの表示を表示制御部115に指示する。これにより、表示制御部115は、プレイ画面において、その仮死状態のプレイヤキャラクタの近傍に復活アイコンを表示させる(ステップS314)。
【0184】
次に、キャラクタ制御部112は、入力部13に対するユーザの操作に基づいて、復活アイコンに対する操作がされたか否かを判定する(ステップS316)。復活アイコンに対する操作がされていないと判定された場合(NO)、キャラクタ制御部112は、ステップS306に処理を戻す。復活アイコンに対する操作がされる前に仮死状態のプレイヤキャラクタのHPが「0」になった場合には死亡状態に遷移する。また、仮死状態のプレイヤキャラクタのHPが「0」になる前は、一旦復活アイコンの表示条件が満たされたと判定されて表示された復活アイコンは、表示が継続される。
【0185】
一方、復活アイコンに対する操作がされたと判定された場合(YES)、キャラクタ制御部112は、その仮死状態のプレイヤキャラクタを通常状態(例えば、HPは初期値(例えば「1000」))に復活させる(ステップS318)。
【0186】
〔第5の実施形態のまとめ〕
以上説明したように、本実施形態に係るゲームシステム1において、キャラクタ制御部112は、チームに属するユーザ情報により識別されるユーザ毎の操作に基づいて、チーム内に共通のフィールド内でユーザ情報毎に関連付けられたキャラクタを活動させる。例えば、キャラクタ制御部112は、キャラクタ状態制御部1121と、復活制御部1122とを備えている。キャラクタ状態制御部1121は、通常状態(第1状態の一例)のプレイヤキャラクタについてHPが「0」になること(所定の第1条件が満たされることの一例)を条件として該プレイヤキャラクタを通常状態よりも能力が低下した仮死状態(第2状態の一例)に遷移させる。また、キャラクタ状態制御部1121は、仮死状態のプレイヤキャラクタについて再びHPが「0」になること(所定の第2条件が満たされることの一例)を条件として該プレイヤキャラクタの活動が制限される死亡状態(第3状態の一例)に遷移させる。復活制御部1122は、仮死状態のプレイヤキャラクタを、該プレイヤキャラクタと同じチームに属する他のプレイヤキャラクタに基づいて通常状態に復活させる。勝敗判定部316は、キャラクタ制御部112によりプレイヤキャラクタが活動した結果に基づいて、チームの勝敗を判定する。例えば、勝敗判定部316は、プレイヤキャラクタが活動した結果(戦闘の結果)に基づく各チームの部屋の占拠状況に基づいて、チームの勝敗を判定する。
【0187】
これにより、ゲームシステム1は、プレイヤキャラクタが攻撃を受けてHPが「0」になっても即死亡とはならず、同じチームの協力による復活のチャンスを与えることができる。よって、ゲームシステム1は、チーム対戦型のアクションゲームにおいて、チーム内の協力の機会をより多くすることができる。
【0188】
なお、本実施形態の適用は、部屋を占拠し合う対戦プレイに限られるものではない。例えば、対戦相手を討伐し合う対戦プレイの場合には、勝敗判定部316は、プレイヤキャラクタが活動した結果(戦闘の結果)に基づく各チームの討伐状況に基づいて、チームの勝敗を判定してもよい。
【0189】
また、復活制御部1122は、仮死状態(第2状態の一例)のプレイヤキャラクタを、該プレイヤキャラクタと同じチームに属する通常状態(第1状態の一例)のプレイヤキャラクタとの位置関係に基づいて、通常状態に復活させる。例えば、復活制御部1122は、仮死状態のプレイヤキャラクタに、同じチームの通常状態のキャラクタが所定の距離内に近づいたと判定した場合(例えば、仮死状態のプレイヤキャラクタに同じチームの通常状態のキャラクタが触れる位置関係になった場合、或いはプレイ画面上で重なる位置関係になった場合)、仮死状態のプレイヤキャラクタを通常状態に復活させる。
【0190】
これにより、ゲームシステム1は、仮死状態のプレイヤキャラクタを復活させるには、その仮死状態のプレイヤキャラクタがいる場所に同じチームの他のプレイヤキャラクタが移動することが必要になるため、チームメンバーが協力して救出する感覚を与えることができる。
【0191】
なお、仮死状態のプレイヤキャラクタを復活させる方法は、仮死状態のプレイヤキャラクタと同じチームの通常状態のプレイヤキャラクタとの位置関係に基づく方法に限られるものではない。例えば、仮死状態のプレイヤキャラクタを復活させる方法は、同じチームの通常状態のプレイヤキャラクタが特定のアイテムを使用することであってもよい。特定のアイテムとは、例えば、仮死状態のプレイヤキャラクタを復活させる効果を有する復活アイテムである。また、仮死状態のプレイヤキャラクタを復活させる方法は、同じチームの通常状態のプレイヤキャラクタが特定の場所に行くことであってもよい。特定の場所とは、例えば、復活させるための祈り部屋である。例えば、同じチームのユーザの操作によって、そのユーザの通常状態のプレイヤキャラクタが祈り部屋に行くこと、または祈り部屋に行って部屋の中で祈る動作を行うことで、仮死状態のプレイヤキャラクタが復活してもよい。
【0192】
通常状態(第1状態の一例)よりも能力が低下した仮死状態(第2状態の一例)とは、プレイヤキャラクタの活動が制限された状態であることが含まれる。これにより、ゲームシステム1は、プレイヤキャラクタを仮死状態に遷移させた場合、そのプレイヤキャラクタの活動が通常状態より制限されるため、対戦プレイにおいてチームの戦力が低下することから、その仮死状態のプレイヤキャラクタを復活させる動機付けをチームメンバーに与えることができる。
【0193】
通常状態(第1状態の一例)よりも能力が低下した仮死状態(第2状態の一例)とは、通常状態よりもプレイヤキャラクタに関連付けられているパラメータの値が、プレイヤキャラクタの能力が低下する値に変更された状態であることが含まれる。これにより、ゲームシステム1は、プレイヤキャラクタを仮死状態に遷移させた場合、そのプレイヤキャラクタの攻撃力、防御力、及びHPなどのパラメータの値が通常状態より低下するため、対戦プレイにおいてチームの戦力が低下することから、その仮死状態のプレイヤキャラクタを復活させる動機付けをチームメンバーに与えることができる。
【0194】
一方、死亡状態(第3状態の一例)とは、プレイヤキャラクタの活動が制限された状態であって、且つプレイヤキャラクタと同じチームに属する他のプレイヤキャラクタに基づいて通常状態(第1状態の一例)に復活することが不可能な状態であることが含まれる。これにより、ゲームシステム1は、プレイヤキャラクタが死亡すると、チーム内の協力では復活不可能となるため、仮死状態のうちになんとか復活させられるようにチーム内で協力する動機付けを与えることができる。
【0195】
なお、死亡状態(第3状態の一例)は、通常状態(第1状態の一例)への復活が不可能な状態としてもよい。この場合、ユーザは、自身が操作するプレイヤキャラクタが死亡すると、その後、引き続き行われている対戦プレイには参加できなくなり(即ち、そのユーザはゲームオーバーとなり)、例えばプレイ画面を見ているだけとなる。これにより、ゲームシステム1は、プレイヤキャラクタが死亡すると、チーム内の協力では復活不可能となるだけでなく、その後対戦プレイに参加できないため、仮死状態のうちになんとか復活させられるようにチーム内で協力する動機付けを与えることができる。
【0196】
復活制御部1122は、死亡状態(第3状態の一例)のプレイヤキャラクタを、死亡状態になってから所定時間が経過することによって通常状態(第1状態の一例)に遷移させる。これにより、ゲームシステム1は、プレイヤキャラクタが死亡してもゲームオーバーとなるのではなく引き続きプレイは進行し、一定時間操作が不可となった後に再スタートとなるため、再び対戦プレイに参加してチームに貢献することができる。また、ゲームシステム1は、プレイヤキャラクタが死亡するとそのプレイヤキャラクタに対して一定時間操作ができなくなるため、仮死状態のうちになんとか復活させられるようにチーム内で協力する動機付けを与えることができる。
【0197】
なお、復活制御部1122は、死亡状態のプレイヤキャラクタを、死亡状態になってから所定時間が経過することによって仮死状態(第2状態の一例)に遷移させてもよい。この場合、ゲームシステム1は、プレイヤキャラクタが死亡するとそのプレイヤキャラクタに対して一定時間操作ができなくなる上に、さらに仮死状態から救う必要があるため、チーム内での協力をより必要なゲーム仕様とすることができる。
【0198】
また、復活制御部1122は、死亡状態(第3状態の一例)のプレイヤキャラクタを通常状態(第1状態の一例)または仮死状態(第2状態の一例)に遷移させる場合、遷移させたプレイヤキャラクタをフィールド内の所定の場所に配置する。例えば、復活制御部1122は、死亡状態のプレイヤキャラクタを通常状態に遷移させる場合、該プレイヤキャラクタのスタート部屋に配置する。これにより、ゲームシステム1は、一旦死亡したプレイヤキャラクタをスタート部屋からの再スタートさせることで、一定時間操作が不可という時間的なペナルティに加えて、場所的なペナルティも与えることができる。
【0199】
なお、復活制御部1122は、死亡状態のプレイヤキャラクタを仮死状態(第2状態の一例)に遷移させる場合、遷移させたプレイヤキャラクタをフィールド内の該プレイヤキャラクタが死亡した場所に配置してもよいし、該プレイヤキャラクタのスタート部屋に配置してもよい。例えば、死亡状態から仮死状態に復活したプレイヤキャラクタが死亡した場所に配置される場合、通常状態に復活するためにはさらにチームメンバーの協力が必要になる反面、場所的なペナルティは免除される。一方、死亡状態から仮死状態に復活したプレイヤキャラクタがスタート部屋に配置される場合、通常状態に復活するためにはさらにチームメンバーの協力が必要になるとともに、場所的なペナルティも課せられる。これにより、ゲームシステム1は、プレイヤキャラクタが死亡したときのペナルティの度合いを変えることができる。
【0200】
なお、復活制御部1122は、仮死状態(第2の状態の一例)から通常状態(第1状態の一例)に復活させる回数を制限してもよい。例えば、復活制御部1122は、1回の対戦プレイにおいて、仮死状態から復活可能な回数に制限(例えば3回)を設けてもよい。この回数を超えては復活できないようにしてもよいし、この回数を越えた場合には特定のアイテムを消費しなければ復活できないようにしてもよい。これにより、ゲームシステム1は、いくらでも復活できることによってプレイの難易度が低下しすぎてしまったり、チーム間の実力差が反映されなくなってしまうことがないように抑制することができる。
【0201】
また、表示制御部115は、ゲーム装置10-1(第1の端末装置の一例)においてユーザの操作に基づいて活動するプレイヤキャラクタが仮死状態(第2の状態の一例)である場合、該プレイヤキャラクタをゲーム装置10-2(第2の端末装置の一例)において通常状態(第1の状態の一例)のプレイヤキャラクタと識別可能な表示態様で表示させる。なお、このときの表示制御部115は、ゲーム装置10-2の表示制御部115の処理となる。これにより、ゲームシステム1は、仮死状態になったプレイヤキャラクタを通常状態のプレイヤキャラクタに対して容易に区別できるように、プレイ画面に表示させることができる。
【0202】
なお、プレイヤキャラクタが死亡した場合、一定時間操作が不可という時間的なペナルティ、及びスタート場所から再スタートという場所的なペナルティに加えて、または代えて、報酬付与部317に付与される所定のポイントが減点されてもよい。
【0203】
[第6の実施形態]
次に、本発明の第6の実施形態について説明する。本実施形態に係るゲームシステム1の基本的な構成は、第1の実施形態と同様であるので、本実施形態において特徴的な処理について説明する。本実施形態では、フィールド内で取得可能なアイテムについて説明する。
【0204】
フィールド内には、ユーザがプレイヤキャラクタを操作することにより取得可能なアイテムが配置されている。配置されているアイテムには、通常アイテムと宝箱アイテムとの2種類のアイテムある。通常アイテムは、アイテムの種類が識別可能な表示態様で表示される。一方、宝箱アイテムは、取得する前は何のアイテムが入手できるかが不明な表示態様で表示されており、取得時に入手アイテムが判明する。両アイテムとも、それが配置されている場所にプレイヤキャラクタを移動させることで取得することができる。例えば、報酬付与部317は、プレイヤキャラクタと宝箱アイテムまたは通常アイテムとの位置関係に基づいて、それぞれに対応するアイテムを報酬として付与する。取得したアイテムはパラメータを回復させるアイテムの様にその場で消費されるものと、対戦が終了した時に取得が確定するものがある。対戦が終了した時に取得が確定するアイテムの場合、対戦に敗北した場合には取得不可としてもよい。
【0205】
〔宝箱アイテムの仕様〕
宝箱アイテムは、フィールド内の予め設定された複数の場所にそれぞれ配置されている。図19は、宝箱アイテムの表示例を示す図である。図示するように、宝箱アイテムは箱を表すオブジェクトを示す表示態様で表示されており、取得できる中身のアイテムは取得するまで分からない。つまり、表示制御部115は、フィールド内に配置された宝箱アイテムをアイテムの種類(報酬内容)が識別不可能な表示態様で表示させる。中身は予め決められていてもよいし、取得時に抽選によって決定されてもよい。あるユーザがプレイヤキャラクタを操作して宝箱アイテムを取得した場合、そのユーザのみではなく同じチームのユーザ全員にアイテムが付与される。例えば、報酬付与部317は、フィールド内に配置された宝箱アイテムを取得する操作がいずれかのユーザにより行われた場合、同じチームに属するユーザ情報により識別される各ユーザに対してユーザ毎に選択されたアイテムを報酬として付与する。なお、対戦相手チームのユーザには付与されない。そのため、フィールド内に存在する複数の宝箱アイテムをチーム内のユーザで分担して取得することで、対戦相手チームよりアイテムを多く取得することを目指す戦略も有り得る。
【0206】
また、宝箱アイテムの配置情報は、チーム毎に関連付けられているが、この配置情報によって特定される宝箱アイテムの配置位置は共通である。よって、どのユーザに対しても、フィールド内の同じ場所に宝箱アイテムが配置される。また、各宝箱アイテムが取得済みであるか或いは未取得であるかの情報は、チーム毎に異なる。つまり、宝箱アイテムは、チーム内の複数のユーザで重複して取得することはできず、いずれかのユーザが一度取得した宝箱アイテムは、チーム内の他のユーザは取得不可となる。例えば、報酬付与部317は、いずれかのユーザの操作により取得済みとなった宝箱アイテムを、同じチームに属するユーザ情報により識別されるいずれのユーザに対しても取得対象から除外する。つまり、報酬付与部317は、チーム毎に関連付けられている宝箱アイテムの配置情報に含まれる「取得済みであるか或いは未取得であるかの情報」が「取得済み」となったチームについては、そのチーム内の他のユーザが取得不可となるように、そのチームに属するユーザ情報により識別されるいずれのユーザに対しても取得対象から除外するように制御する。
【0207】
なお、宝箱アイテムの配置情報は、ユーザ情報毎に関連付けられてもよい。宝箱アイテムの配置情報がユーザ情報毎に関連付けられている場合、この配置情報によって特定される宝箱アイテムの配置位置は全ユーザに対して共通である。また、ユーザ情報毎に関連付けられている各宝箱アイテムが取得済みであるか或いは未取得であるかの情報は、チーム毎に共通である。これにより、どのユーザに対しても、フィールド内の同じ場所に宝箱アイテムが配置され、各宝箱アイテムが取得済みであるか或いは未取得であるかの情報がチーム毎に管理される。
【0208】
宝箱アイテムを取得すると、同じチームのユーザ全員にアイテムが付与されるが、同じ宝箱アイテムでも付与される中身はユーザ毎に異なる。例えば、中身はランダムに決まるため、価値の高いアイテムが付与されるユーザがいれば、価値の低いアイテムが付与されるユーザもいることになる。例えば、表示制御部115は、報酬付与部317がチームに属するユーザ情報により識別される各ユーザに付与したユーザ毎のアイテムの種類を表示させる。つまり、同じチーム内のユーザに付与されたアイテムを示す情報は、プレイ画面に表示され、チーム内のコミュニケーションのきっかけの一つとなる。
【0209】
なお、宝箱アイテムにより取得されるアイテムは、プレイヤキャラクタに装備可能なアイテムなどのように通常アイテムにはないアイテムもあり、通常アイテムより比較的価値の高いアイテムであることが多い。
【0210】
〔通常アイテムの仕様〕
通常アイテムも、フィールド内の予め設定された複数の場所にそれぞれ配置されている。全ての種類の通常アイテムは、宝箱アイテムより多く配置されており、宝箱アイテムよりも高い確率で遭遇する。例えば、表示制御部115は、フィールド内に配置された通常アイテムをアイテムの種類(報酬内容)が識別可能な表示態様で表示させる。図20は、通常アイテムの表示例を示す図である。図示する通常アイテムは、HPを回復する「にく」アイテムであり、肉を表すオブジェクトを示す表示態様で表示されている。このように、通常アイテムは、宝箱アイテムとは異なり、取得前からそのアイテムが識別可能である。なお、通常アイテムは、HPを回復するアイテムなどのように、その場で消費されるアイテムが多い。よって、ユーザは、通常アイテムを見つけた場合、そのとき必要であれば取得してもよいが、そのとき必要なければ取得せずに、後で必要になったときに取得してもよい。
【0211】
通常アイテムの配置情報は、ユーザ毎に設定されているため、他のユーザには影響しない。例えば、あるユーザが取得した通常アイテムは、チームに関係なく他のユーザも取得可能である。つまり、報酬付与部317は、フィールド内に配置された通常アイテムを取得する操作がいずれかのユーザにより行われた場合、該ユーザに対してその通常アイテムを付与するとともに、その通常アイテムを取得する操作が他のユーザにより行われた場合、該他のユーザに対してその通常アイテムを付与する。
【0212】
また、フィールド内に配置された通常アイテムの配置情報はユーザ情報毎に関連付けられているが、ユーザ情報毎に関連付けられた配置情報によって特定される通常アイテムの配置位置は共通である。また、ユーザ情報毎に関連付けられた配置情報によって特定される通常アイテムの種類(報酬内容)も共通である。よって、どのユーザに対しても、フィールド内の同じ場所に同じ種類の通常アイテムが配置される。一方、各通常アイテムが取得済みであるか或いは未取得であるかの情報は、ユーザ毎に異なる。これにより、いつどこで通常アイテムを取得するか(例えば、HPを回復させるか)などの戦略はユーザ毎に立てられることになる。
【0213】
なお、上記では通常アイテムの配置情報は、ユーザ情報毎に関連付けられているものとしたが、チーム毎に関連付けられてもよい。その場合、チーム内で必要なアイテムを必要なユーザが使用する戦略を、チーム単位で立てることができるようになる。
【0214】
次に、通常アイテム及び宝箱アイテムによる報酬付与処理の動作について説明する。図21は、本実施形態に係る報酬付与処理の一例を示すフローチャートである。
【0215】
報酬付与部317は、入力部13に対するユーザの操作に基づいてアイテムが取得されると(ステップS400)、取得されたアイテムが通常アイテムであるか、または宝箱アイテムであるかを判定する(ステップS402)。取得されたアイテムが通常アイテムであると判定された場合、報酬付与部317は、その通常アイテムをユーザに付与する(ステップS404)。
【0216】
一方、取得されたアイテムが宝箱アイテムであると判定された場合、報酬付与部317は、宝箱アイテムに関連付けられた複数のアイテムからユーザ毎に付与するアイテムを抽選(ランダ抽選)する(ステップS406)。そして、報酬付与部317は、抽選結果に基づいて、ユーザ毎に抽選されたアイテムを付与する(ステップS408)。また、報酬付与部317は、ユーザ毎に付与したアイテムを示す情報の表示を表示制御部115に指示する。これにより、表示制御部115は、プレイ画面において、ユーザ毎に付与したアイテムを示す情報を表示させる(ステップS410)。
【0217】
〔第6の実施形態のまとめ〕
以上説明したように、本実施形態に係るゲームシステム1において、キャラクタ制御部112は、チームに属するユーザ情報により識別されるユーザ毎の操作に基づいて、チーム内に共通のフィールド内で、ユーザ情報毎に関連付けられたキャラクタを移動させる。報酬付与部317は、フィールド内に配置された宝箱アイテム(第1オブジェクトの一例)を取得する操作がいずれかのユーザにより行われた場合、同じチームに属するユーザ情報により識別される各ユーザに対してユーザ毎に選択されたアイテム(報酬の一例)を付与する。
【0218】
これにより、ゲームシステム1は、フィールド内に存在する複数の宝箱アイテムをチーム内のユーザで分担して取得することができるため、チーム対戦型のアクションゲームにおいて、チーム内の協力の機会をより多くすることができる。
【0219】
表示制御部115(第1表示制御部の一例)は、報酬付与部317がチームに属するユーザ情報により識別される各ユーザに付与したユーザ毎のアイテムの種類(報酬の内容の一例)を表示させる。これにより、ゲームシステム1は、チーム内の各ユーザに付与されたアイテムの種類が分かるので、チーム内のコミュニケーションのきっかけにすることができる。
【0220】
また、表示制御部115(第1表示制御部の一例)は、フィールド内に配置された宝箱アイテム(第1オブジェクトの一例)をアイテムの種類(報酬の内容の一例)が識別不可能な表示態様で表示させる。これにより、ゲームシステム1は、宝箱アイテムを取得した後に、付与されるアイテムの種類が分かること、即ち付与されるアイテムが取得前に分からないことを示唆するとともに、分からないことにより、取得する際の期待感を高めることができる。
【0221】
一方、表示制御部115(第2表示制御部の一例)は、フィールド内に配置された通常アイテム(第2オブジェクトの一例)をアイテムの種類(報酬の内容の一例)が識別可能な表示態様で表示させる。これにより、ゲームシステム1は、付与されるアイテムの種類をユーザが事前に確認した上で通常アイテムを取得可能にできる。例えば、通常アイテムは、HPを回復するアイテムなどのように、その場で消費されるアイテムが多い。そのため、ユーザは、付与されるアイテムの種類を事前に確認した上で、必要に応じて通常アイテムを取得するか否かを判断できる。
【0222】
報酬付与部317は、プレイヤキャラクタと宝箱アイテム(第1オブジェクトの一例)との位置関係に基づいてアイテム(報酬の一例)を付与する。例えば、報酬付与部317は、宝箱アイテムが配置されている場所にプレイヤキャラクタを移動させることでアイテムを付与する。これにより、ゲームシステム1は、フィールド内に存在する複数の宝箱アイテムのそれぞれに対してチーム内のユーザが分担して移動させることで、効率よくユーザがアイテムを取得することができる。
【0223】
報酬付与部317は、いずれかのユーザの操作により取得済みとなった宝箱アイテム(第1オブジェクトの一例)を、同じチームに属するユーザ情報により識別されるいずれのユーザに対しても取得対象から除外する。これにより、ゲームシステム1は、同じチーム内の複数のユーザで宝箱アイテムを重複して取得することができないため、価値の高いアイテムをユーザに付与しすぎないようにすることができる。
【0224】
なお、報酬付与部317は、いずれかのユーザの操作により取得済みとなった宝箱アイテム(第1オブジェクトの一例)を、チームに関係なくいずれのユーザに対しても取得対象から除外してもよい。この場合、宝箱アイテムは、一方のチームが取得すると、他方のチームは取得できなくなるため、よりチーム間の競争を激しくすることができる。
【0225】
フィールド内には、宝箱アイテム(第1オブジェクトの一例)と異なる通常アイテム(第2オブジェクトの一例)が配置されている。報酬付与部317は、フィールド内に配置された通常アイテムを取得する操作がいずれかのユーザにより行われた場合、該ユーザに対して報酬を付与するとともに、該通常アイテムを取得する操作が他のユーザにより行われた場合、該他のユーザに対して報酬を付与する。
【0226】
これにより、ゲームシステム1は、あるユーザが取得した通常アイテムがチームに関係なく他のユーザも取得可能であるため、どのユーザに対しても平等に通常アイテムの取得の機会を与えることができる。また、ゲームシステム1は、いつどこで通常アイテムを取得するか(例えば、HPを回復させるか)などの戦略をユーザ毎に立てられるようにすることができる。
【0227】
フィールド内に配置された通常アイテム(第2オブジェクトの一例)の配置情報はユーザ情報毎に関連付けられており、ユーザ情報毎に関連付けられた配置情報によって特定される通常アイテムの配置位置が共通である。これにより、ゲームシステム1は、どのユーザに対してもフィールド内の同じ場所に通常アイテムを配置するため、どのユーザに対しても平等に通常アイテムの取得の機会を与えることができる。
【0228】
ユーザ情報毎に関連付けられた配置情報によって特定される通常アイテム(第2オブジェクトの一例)の報酬内容が共通である。これにより、ゲームシステム1は、どのユーザに対してもフィールド内の同じ場所に同じ種類の通常アイテムを配置するため、どのユーザに対しても平等に通常アイテムの取得の機会を与えることができる。
【0229】
[第7の実施形態]
次に、本発明の第7の実施形態について説明する。本実施形態に係るゲームシステム1の基本的な構成は、第1の実施形態と同様であるので、本実施形態において特徴的な処理について説明する。本実施形態では、対戦プレイ中にプレイ画面表示されるエフェクト(効果)の処理について説明する。
【0230】
対戦で利用されるプレイヤキャラクタは、プレイヤキャラクタに基づく特性(プレイヤキャラクタ特性またはプレイヤキャラクタが装備している装備アイテムの特性等)によって、遠方の敵を攻撃可能であったり、広範囲にダメージを与えることが可能であったり、その効果は様々である。プレイヤキャラクタが攻撃したときに、その攻撃に応じたエフェクトがプレイ画面に表示される。エフェクトとは攻撃の特性などに対応する効果をビジュアル化した表示画像(映像)である。図22は、プレイ画面におけるエフェクトの表示例を示す図である。図示する例では、赤チームのプレイヤキャラクタPR1の攻撃によるエフェクトEF1の表示例と、青チームのプレイヤキャラクタPB1の攻撃によるエフェクトEF2の表示例とを示している。
【0231】
一般的にこのようなエフェクトの表示を行う場合、その表示態様を短時間で連続的に変化させたり、また、半透明にする処理等を多用するため、処理負荷が高くなる傾向がある。そのため、多数のプレイヤキャラクタが同時に表示されるような場面では、すべてのプレイヤキャラクタのエフェクトを表示することが難しい場合がある。例えば、処理負荷が高くなる(例えばCPU使用率が100%を超える)と、描画処理の遅延やコマ落ちなどが発生し、著しく操作感を損なうことになる。また、処理負荷が問題なくとも多数のエフェクトが表示されるとエフェクトにより敵の状況などが見づらくなりゲームの進行が把握しづらくなることも起こり得る。そのため、本実施形態では、表示するエフェクトの数などに制限を設け、優先度(優先設定)に基づいてエフェクトの表示を行う。例えば、表示制御部115は、予め設定された優先度に基づいて、エフェクトの表示に制限を設ける。なお、優先設定は共通ではなく、ユーザ情報毎に設けられてもよい。
【0232】
例えば、優先度として、表示制御部115が表示処理を実行するゲーム装置10(即ち、自ゲーム装置)で操作するプレイヤキャラクタのエフェクトの表示が、他のゲーム装置10で操作するプレイヤキャラクタのエフェクトの表示より優先されるように設定されている。つまり、表示制御部115は、表示処理を実行するゲーム装置10以外のゲーム装置10で操作されるプレイヤキャラクタのエフェクトの表示を制限する。これは、ゲーム装置10で操作するユーザの操作感を確保することを目的として、該ユーザが操作するプレイヤキャラクタのエフェクトの優先度を高くしている。
【0233】
また、優先度は、プレイヤキャラクタの特性や装備アイテムの特性に基づいてエフェクトの表示が制限されるように設定されてもよい。例えば、プレイヤキャラクタのレアリティ(希少度)または装備アイテムのレアリティに基づいてエフェクトの表示が制限されてもよい。具体的には、表示制御部115は、プレイヤキャラクタまたは装備アイテムのレアリティが高いほどエフェクトの表示を優先してもよい。
【0234】
また、優先度は、プレイヤキャラクタまたは装備アイテムに設定されている期間限定効果に基づく特性に基づいてエフェクトの表示が制限されるように設定されてもよい。期間限定効果とは、限定期間のみ特別な効果が得られるものである。例えば、プレイヤキャラクタや装備アイテムには属性が設定されており、曜日等によって特定の属性のプレイヤキャラクタや装備アイテムの能力が、期間限定効果として高くなる。また、新しくゲームに追加されたキャラクタや装備アイテムは、期間限定効果として、追加後10日間など一定期間能力が通常より高く設定される。例えば、表示制御部115は、期間限定効果に基づく特性が設定されているプレイヤキャラクタまたは装備アイテムのエフェクトの表示を、その限定期間については優先してもよい。
【0235】
また、他ユーザが操作するプレイヤキャラクタの装備アイテムのうち、自ユーザが所持しているアイテム(或いは、所持したことがあるアイテム)のエフェクトの表示の優先度を下げてもよい。なお、他ユーザが操作するプレイヤキャラクタの装備アイテムのうち、自ユーザが操作するプレイヤキャラクタが装備しているアイテム(或いは、装備したことがあるアイテム)のエフェクトの表示の優先度を下げてもよい。つまり、ユーザが既に知っているアイテムのエフェクトは、該ユーザに知らせる必要度が低いため、優先度を下げてもよい。なお、各ユーザが所持しているアイテム(プレイヤキャラクタに装備可能なアイテム)の情報や装備アイテムとして使用したことがあるアイテムの情報は、アイテムの所持履歴もしくは使用履歴として、ユーザデータ記憶部351に記憶されている。
【0236】
また、自ユーザが所持しているキャラクタ(或いは、所持したことがあるキャラクタ)と同じ種類のキャラクタを他ユーザがプレイヤキャラクタとして操作する場合、その他ユーザが操作するプレイヤキャラクタのエフェクトの表示の優先度を下げてもよい。なお、自ユーザが操作しているキャラクタ(或いは、操作したことがあるキャラクタ)と同じ種類のキャラクタを他ユーザがプレイヤキャラクタとして操作する場合、その他ユーザが操作するプレイヤキャラクタのエフェクトの表示の優先度を下げてもよい。つまり、ユーザが既に知っているキャラクタのエフェクトは、該ユーザに知らせる必要度が低いため、優先度を下げてもよい。なお、各ユーザが所持しているキャラクタ(プレイヤキャラクタとして操作可能なキャラクタ)の情報やプレイヤキャラクタとして操作したことがあるキャラクタの情報は、キャラクタの所持履歴もしくは使用履歴として、ユーザデータ記憶部351に記憶されている。
【0237】
例えば、表示制御部115は、表示処理を実行するゲーム装置10(即ち、該表示制御部115を備える自ゲーム装置10)でユーザの操作可能なプレイヤキャラクタの所持履歴もしくは使用履歴、または該プレイヤキャラクタに装備可能なアイテムの所持履歴もしくは使用履歴に基づいて、該ゲーム装置10以外のゲーム装置10(他のゲーム装置10)で操作されるプレイヤキャラクタのエフェクトの表示を制限してもよい。
【0238】
次に、表示制御部115がエフェクトの表示に制限を設ける場合の具体例について説明する。例えば、表示制御部115は、自身が表示処理を実行するゲーム装置10(即ち、該表示制御部115を備える自ゲーム装置10)の処理負荷に基づいて、上述した優先度を考慮してエフェクトの表示に制限を設ける。具体的には、表示制御部115は、自ゲーム装置10における現在の処理負荷(CPUの使用率)に基づいて表示可能なエフェクトの数を算出し、その数以下に表示するエフェクトの数を制限してもよい。この算出したエフェクトの数を、複数のユーザの攻撃により同時に表示させる必要があるエフェクトの数が越えた場合、表示制御部115は、上述した優先度に従ってエフェクトの表示を制限してもよい。
【0239】
また、エフェクト毎に処理負荷が大きく異なるような場合には、表示制御部115は、自ゲーム装置10における現在の処理負荷(CPUの使用率)とエフェクト毎の処理負荷とに基づいて、表示可能なエフェクトを選択して表示させてもよい。例えば、エフェクト毎の処理負荷を示す設定情報が予めアイテムデータ記憶部354に記憶されており、その設定情報に基づいて、優先して表示されるエフェクトが決まってもよい。
【0240】
図23は、エフェクトの設定情報の一例を示す図である。図示するエフェクトの設定情報は、装備アイテムのエフェクト表示に関係する設定情報の一例を示しており、装備アイテムと、処理負荷と、レアリティ(希少度)と、特別効果期間とが関連付けられている。装備アイテムは、その装備アイテムのアイテムIDである。処理負荷は、その装備アイテムによるエフェクトの表示に必要なCPUの処理負荷である。レアリティ(希少度)は、その装備アイテムに設定されているレアリティ(希少度)である。例えば、レアリティ(希少度)は、高い順にSSレアリティ、Sレアリティ、レアリティとなっており、そのうちのいずれかが各装備アイテムに設定されている。特別効果期間は、期間限定で特別な効果が得られる装備アイテムの場合に、その特別な効果が得られる期間が設定されている。
【0241】
表示制御部115は、自ゲーム装置10においてエフェクトを表示したときに、処理負荷が100%未満となるように、必要に応じてエフェクトの表示を制限する。例えば、表示制御部115は、エフェクトの表示を制限する場合、レアリティ(希少度)の高い装備アイテムを優先してもよいし、特別効果期間中にある装備アイテムを優先してもよい。なお、表示制御部115は、処理負荷が98%未満や95%未満などなるようにエフェクトの表示を制限してもよい。
【0242】
なお、表示制御部115は、エフェクトの表示を制限する場合、表示するエフェクトの数の制限ではなく、表示する内容を制限してもよい。例えば、優先度の低いエフェクトに関しては、処理負荷の低いエフェクト(例えば、特別なビジュアルを用いない汎用的なエフェクト)に変更してもよい。
【0243】
〔第7の実施形態のまとめ〕
以上説明したように、本実施形態に係るゲームシステム1の表示制御部115は、チーム内に共通のフィールド内で、チームに属するユーザ情報により識別されるユーザ毎に操作されるプレイヤキャラクタと、該プレイヤキャラクタの対戦相手とが対戦するゲームにおいて、ユーザ毎に操作されるプレイヤキャラクタのそれぞれに関連付けられた特性に基づくエフェクト(効果)を表示させる表示処理を実行する。また、表示制御部115は、予め設定された優先度に基づいて、上記エフェクトの表示に制限を設ける。
【0244】
これにより、ゲームシステム1は、優先度に基づいてエフェクトの表示に制限を設けるため、複数のプレイヤキャラクタによるエフェクト表示を適切に制御することができる。
【0245】
例えば、表示制御部115は、上記表示処理を実行するゲーム装置10の処理負荷に基づいて、エフェクト(効果)の表示に制限を設ける。これにより、ゲームシステム1は、ゲーム装置10の処理負荷がオーバーしないように(過負荷とならないように)処理負荷を低減しつつ、優先度の高いエフェクトは表示させるため、複数のプレイヤキャラクタによるエフェクト表示を適切に制御することができる。
【0246】
また、表示制御部115は、上記表示処理を実行するゲーム装置10(即ち、該表示制御部115を備えたゲーム装置10)以外のゲーム装置10(即ち、他のゲーム装置10)で操作されるプレイヤキャラクタのエフェクト(効果)の表示を制限する。これにより、ゲームシステム1は、ユーザ自身が操作するプレイヤキャラクタのエフェクトを該ユーザが操作するゲーム装置10で優先的に表示させるため、ゲーム装置10で操作するユーザの操作感を確保することができる。
【0247】
また、表示制御部115は、上記表示処理を実行するゲーム装置10(即ち、該表示制御部115を備えたゲーム装置10)でユーザの操作可能なプレイヤキャラクタの所持履歴もしくは使用履歴、または該プレイヤキャラクタに装備可能なアイテムの所持履歴もしくは使用履歴に基づいて、該ゲーム装置10以外のゲーム装置10(即ち、他のゲーム装置10)で操作されるプレイヤキャラクタのエフェクト(効果)の表示を制限する。これにより、ゲームシステム1は、ユーザが既に知っているキャラクタやアイテムであるか否かによってエフェクトの表示の優先度を設定できるため、ユーザに知らせる必要度が低いエフェクトの表示よりも、ユーザに知らせる必要度が高いエフェクト(ユーザが未だ見たことがないエフェクト)の表示を優先して表示させることができる。
【0248】
また、表示制御部115は、ユーザ毎に操作されるプレイヤキャラクタのそれぞれに関連付けられた特性に基づいて予め設定された優先度に基づいて、エフェクト(効果)の表示に制限を設ける、これにより、ゲームシステム1は、プレイヤキャラクタの特性によってエフェクトの表示の優先度を設定できるため、優先度を高く設定した特性のプレイヤキャラクタを目立たせることでき、ユーザに対してその特性のキャラクタの入手意欲を起こすことができる。
【0249】
例えば、ユーザ毎のプレイヤキャラクタのそれぞれに関連付けられた特性は、それぞれのプレイヤキャラクタに関連付けられたアイテムに基づく特性である。これにより、ゲームシステム1は、装備アイテムの特性によってエフェクトの表示の優先度を設定できるため、優先度を高く設定した特性の装備アイテムを目立たせることでき、ユーザに対してその特性のアイテムの入手意欲を起こすことができる。
【0250】
なお、ユーザ毎のプレイヤキャラクタのそれぞれに関連付けられた特性は、それぞれのプレイヤキャラクタまたはそれぞれのプレイヤキャラクタに関連付けられたアイテムのレアリティ(希少度)に基づく特性であってもよい。これにより、ゲームシステム1は、プレイヤキャラクタのレアリティまたは装備アイテムのレアリティが高いほど、そのエフェクトの表示を優先することができる。よって、例えば見たこともない希少価値の高そうな武器やキャラクタを目立たせることでき、ユーザに対してそれらの武器やキャラクタの入手意欲を起こすことができる。
【0251】
また、ユーザ毎のプレイヤキャラクタのそれぞれに関連付けられた特性は、それぞれのプレイヤキャラクタまたはそれぞれのプレイヤキャラクタに関連付けられたアイテムに設定されている期間限定効果に基づく特性であってもよい。これにより、ゲームシステム1は、特別な効果が得られる限定期間では、その特別な効果のエフェクトの表示を優先することができる。よって、例えば期間限定で効果のある武器やキャラクタを目立たせることでき、ユーザに対してそれらの武器やキャラクタの入手意欲を起こすことができる。
【0252】
[変形例]
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成は上述の実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。例えば、上述の第1~7の実施形態において説明した各構成は、任意に組み合わせることができる。
【0253】
なお、上記実施形態では、青チームと赤チームとの1対1のチーム対戦の例を説明したが、これに限られるものではなく、3チーム以上の対戦であってもよい。3チーム以上の対戦の場合には、自陣営(チーム)の通常NPCは、自チーム以外の全てのチームのプレイヤキャラクタから攻撃が可能である。例えば、最も多くの通常NPCを討伐したチーム、または最も多くのダメージを通常NPCに与えたチームが、その通常部屋を占拠するチームとなってもよい。また、自陣営(チーム)以外の陣営毎に攻撃対象となる通常NPCが設定されてもよい。
【0254】
また、上記実施形態では、チーム対戦型の例を説明したが、これに限られるものではなく、一つのチームが敵のNPCと対戦し、NPCを討伐する度に、領域やステージを順にクリアしていくゲームに適用してもよい。その場合、例えば、報酬付与部317は、フィールド内の同一の領域(例えば、部屋)において所定の条件が満たされる度に、付与するポイントを増加させてもよい。即ち、報酬付与部317は、同一の部屋において所定の占拠条件が満たされる度に、付与する報酬の価値を高くしてもよい。また、通常NPC制御部113は、フィールド内の同一の領域(例えば、部屋)において所定の条件が満たされる度に、該領域においてNPC(例えば、通常NPC)を出現させる時間間隔を減少、またはNPC(例えば、通常NPC)を同時に出現可能な上限数を増加させてもよい。
【0255】
また、上述のゲーム制御部110、またはサーバ制御部310の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによりゲーム制御部110、またはサーバ制御部310としての処理の一部または全部を行ってもよい。ここで、「記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行する」とは、コンピュータシステムにプログラムをインストールすることを含む。ここでいう「コンピュータシステム」とは、OSや周辺機器等のハードウェアを含むものとする。また、「コンピュータシステム」は、インターネットやWAN、LAN、専用回線等の通信回線を含むネットワークを介して接続された複数のコンピュータ装置を含んでもよい。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ROM、CD-ROM等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。このように、プログラムを記憶した記録媒体は、CD-ROM等の非一過性の記録媒体であってもよい。また、記録媒体には、当該プログラムを配信するために配信サーバからアクセス可能な内部または外部に設けられた記録媒体も含まれる。配信サーバの記録媒体に記憶されるプログラムのコードは、端末装置で実行可能な形式のプログラムのコードと異なるものでもよい。すなわち、配信サーバからダウンロードされて端末装置で実行可能な形でインストールができるものであれば、配信サーバで記憶される形式は問わない。なお、プログラムを複数に分割し、それぞれ異なるタイミングでダウンロードした後に端末装置で合体される構成や、分割されたプログラムのそれぞれを配信する配信サーバが異なっていてもよい。さらに「コンピュータ読み取り可能な記録媒体」とは、ネットワークを介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ(RAM)のように、一定時間プログラムを保持しているものも含むものとする。また、上記プログラムは、上述した機能の一部を実現するためのものであってもよい。さらに、上述した機能をコンピュータシステムに既に記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル(差分プログラム)であってもよい。
【0256】
また、上述のゲーム制御部110、またはサーバ制御部310の一部または全部を、LSI(Large Scale Integration)等の集積回路として実現してもよい。上述した各機能は個別にプロセッサ化してもよいし、一部、または全部を集積してプロセッサ化してもよい。また、集積回路化の手法はLSIに限らず専用回路、または汎用プロセッサで実現してもよい。また、半導体技術の進歩によりLSIに代替する集積回路化の技術が出現した場合、当該技術による集積回路を用いてもよい。
【0257】
また、上述のゲーム制御部110の一部の構成を、サーバ制御部310が備えてもよい。例えば、ゲームサーバ30がゲーム処理の大部分を担い、ゲーム装置10は、ゲームサーバ30が実行するゲーム処理に基づくゲーム画像の表示とユーザの操作の入力とを担う構成としてもよい。
【0258】
[付記]
以上の記載から本発明は例えば以下のように把握される。なお、本発明の理解を容易にするために添付図面の参照符号を便宜的に括弧書きにて付記するが、それにより本発明が図示の態様に限定されるものではない。
【0259】
(付記A1)本発明の一態様に係るゲームシステム(1)は、複数のチームのそれぞれに属するユーザ情報により識別されるユーザ毎の操作に基づいて、前記複数のチームに共通の複数の領域(例えば、部屋)を有するフィールド(FLD)内で前記ユーザ情報毎に関連付けられたキャラクタ(P1)を移動させるキャラクタ移動部(112)と、前記ユーザの操作結果が所定の条件(例えば、所定の占拠条件)を満たしたか否かに基づいて、前記領域をいずれのチームに関連付けるか否か(例えば、いずれのチームの占拠とするか)を判定する領域判定部(315、S100)と、前記領域判定部による判定結果に基づいて、前記複数のチームによる対戦の勝敗を判定する勝敗判定部(316、S114)と、を備える。
【0260】
付記A1の構成によれば、ゲームシステムは、各ユーザが操作することによりフィールド内でプレイヤキャラクタを移動させるチーム対戦型のアクションゲームにおいて、領域(例えば、部屋)を占拠しあうことで勝敗を決するという新たな楽しみを提供することができる。例えば、このゲームシステムは、常に領域の占拠数でどちらのチームが優勢であるかが分かるため、緊張感が途切れることなくユーザにプレイさせることができる。また、1体1の対戦で領域を取り合うゲームと比較した場合、このゲームシステムは、チーム対戦であることから、チームとしての協力プレイや、敵味方の両方に複数のプレイヤキャラクタが登場することなどから、より戦略性の高いゲームを提供することができる。
【0261】
(付記A2)また、本発明の一態様は、付記A1に記載のゲームシステムであって、前記領域においてNPC(ノンプレイヤキャラクタ)を制御するNPC制御部(113,312)、を備え、前記領域判定部は、前記領域において前記NPCの討伐状況が前記所定の条件を満たした場合、前記領域をいずれのチームに関連付けるか否かを判定する。
【0262】
付記A2の構成によれば、ゲームシステムは、フィールド内の複数の領域(例えば、部屋)のそれぞれに出現するNPC(例えば、通常NPCまたはボスNPC)を討伐することで、それぞれの領域を占拠することができるため、各チームの対戦相手を同じ条件とすることができ、公平性を保つことができる。
【0263】
(付記A3)また、本発明の一態様は、付記A2に記載のゲームシステムであって、前記領域における前記NPCは、前記複数のチームのうちのいずれか一つのチームに対応している。
【0264】
付記A3の構成によれば、ゲームシステムは、対戦相手がNPCでありながら、対戦相手のチームと戦っているのと同様の状況とすることができ、ユーザがチーム対戦であることを実感しながらプレイ可能とすることができる。
【0265】
(付記A4)また、本発明の一態様は、付記A1から付記A3のいずれか一に記載のゲームシステムであって、前記勝敗判定部は、前記領域判定部による判定結果により前記複数のチームのそれぞれに関連付けられた前記領域の数に基づいて、前記複数のチームによる対戦の勝敗を判定する。
【0266】
付記A4の構成によれば、ゲームシステムは、領域(例えば、部屋)の占拠数でチームの勝敗が決するため、ユーザにとって対戦中の状況も対戦が終了したときの結果も分かりやすい。
【0267】
(付記A5)また、本発明の一態様は、付記A1から付記A4のいずれか一に記載のゲームシステムであって、前記領域判定部により前記領域が関連付けられたチームまたは該チームに属するユーザ情報により識別されるユーザに対してポイントを付与する報酬付与部(317)、を備える。
【0268】
付記A5の構成によれば、ゲームシステムは、領域(例えば、部屋)を占拠したチームまたはチームのユーザに対してポイントを付与するため、占拠状況だけでない楽しみを付加することができる。例えば、ゲームシステムは、ユーザ毎にポイントを付与する場合、チーム同士の対戦に加えて、チーム内のユーザ同士でも競い合える楽しみをユーザに与えることができる。
【0269】
(付記A6)また、本発明の一態様は、付記A5に記載のゲームシステムであって、前記報酬付与部は、前記領域判定部により前記領域が関連付けられたチームまたは該チームに属するユーザ情報により識別されるユーザに対して、前記領域に応じたポイントを付与する。
【0270】
付記A6の構成によれば、ゲームシステムは、占拠した領域(例えば、部屋)によって付与されるポイントが異なるため、例えば、難易度の低い領域を数多く占拠しようと試みるか、或いは、難易度の高い領域を数は少なくとも占拠しようとするかといったことをチームの戦略として選択可能となるため、戦略性の高いゲームを提供できる。
【0271】
(付記A7)また、本発明の一態様は、付記A5または付記A6に記載のゲームシステムであって、前記領域判定部は、前記複数のチームのいずれかのチームに関連付けられた前記領域において他のチームに属するユーザ情報により識別されるユーザの操作結果により前記所定の条件が満たされた場合、前記領域を該他のチームまたは該他のチームに属するユーザ情報に対して関連付け、前記報酬付与部は、同一の前記領域において前記所定の条件が満たされる度に、付与するポイントを増加させる。
【0272】
付記A7の構成によれば、ゲームシステムは、同一の領域(例えば、部屋)をチーム同士で占拠しあうことで占拠したときに付与されるポイントが高くなるため、各チームのユーザに対して繰り返し対戦する意欲を高めることができ、白熱したゲーム展開が期待できる。
【0273】
(付記A8)また、本発明の一態様は、付記A5から付記A7のいずれか一に記載のゲームシステムであって、前記報酬付与部は、前記領域判定部によりチームに関連付けられた領域が多いほど、該チームに領域が関連付けられた際に付与するポイントを増加させる。
【0274】
付記A8の構成によれば、ゲームシステムは、領域(例えば、部屋)を占拠すればする程、優位にゲームを進められるようにすることができる。
【0275】
(付記A9)また、本発明の一態様は、付記A5から付記A8のいずれか一に記載のゲームシステムであって、前記勝敗判定部は、前記領域判定部による前記複数の領域のそれぞれに対する判定結果と、前記報酬付与部により各チームまたは該チームに属するユーザ情報により識別されるユーザに対して付与されたポイントとに基づいて、前記複数のチームによる対戦の勝敗を判定する。
【0276】
付記A9の構成によれば、ゲームシステムは、領域(例えば、部屋)の占拠だけでなくポイントの取得も勝敗に影響することから、どの領域を占拠するかによって勝敗が左右されるため、戦略性の高いゲームを提供できる。
【0277】
(付記A10)また、本発明の一態様は、付記A5から付記A9のいずれか一に記載のゲームシステムであって、前記報酬付与部は、前記領域判定部によりチームに関連付けられた前記領域において、該チームに属するユーザ情報により識別されるユーザに対して該ユーザの操作に基づくプレイの進行に有利な効果を発生させる。
【0278】
付記A10の構成によれば、ゲームシステムは、領域(例えば、部屋)を占拠すればする程、優位にゲームを進められるようにすることができる。
【0279】
(付記A11)また、本発明の一態様は、付記A1から付記A10のいずれか一に記載のゲームシステムであって、前記キャラクタのそれぞれには、前記ユーザの操作に基づくプレイの進行に影響する特性が設定されている。
【0280】
付記A11の構成によれば、ゲームシステムは、キャラクタの特性によって攻撃の種類や威力が変わるとともに、対戦相手の特性との組み合わせによる相性によっても優劣が生じるため、戦略性の高いゲームを提供できる。
【0281】
(付記A12)また、本発明の一態様は、コンピュータを、付記A1から付記A11のいずれか一に記載のゲームシステムとして機能させるためのプログラム。
【0282】
付記A12の構成によれば、プログラムは、各ユーザが操作することによりフィールド内でプレイヤキャラクタを移動させるチーム対戦型のアクションゲームにおいて、領域(例えば、部屋)を占拠しあうことで勝敗を決するという新たな楽しみを提供することができる。
【0283】
(付記B1)また、本発明の一態様に係るゲームシステム(1)は、チームに属するユーザ情報により識別されるユーザ毎の操作に基づいて、前記チーム内で共通の領域を有するフィールド(FLD)内で前記ユーザ情報毎に関連付けられたキャラクタを移動させるキャラクタ移動部(112)と、前記領域に所定の時間間隔でNPC(ノンプレイヤキャラクタ)を出現させるNPC制御部(113)と、前記領域において前記NPCの討伐状況が所定の条件を満たした場合、前記領域を前記チームに関連付けるか否かを判定する領域判定部(315)と、前記領域判定部により前記チームに関連付けられた領域に基づいて、前記チームの勝敗を判定する勝敗判定部(316)と、を備える。
【0284】
付記B1の構成によれば、ゲームシステムは、NPC(例えば、通常NPC)が討伐されても所定の時間間隔で復活するため、領域(例えば、通常部屋)の占拠が一人では簡単にはできないようにし、チームでより協力したプレイを必要にすることができる。よって、ゲームシステムは、チーム戦の意識の高いゲームを提供できる。
【0285】
(付記B2)また、本発明の一態様は、付記B1に記載のゲームシステムであって、前記NPCの討伐状況は、前記領域において出現している前記NPCの数である。
【0286】
付記B2の構成によれば、ゲームシステムは、領域(例えば、通常部屋)に所定の時間間隔で出現するNPC(例えば、通常NPC)の数が所定の条件を満たすことで(例えば、通常NPCの数が0になることで)、その領域を占拠することができるため、占拠できる条件が分かりやすい。また、チームメンバーと協力することで早く占拠できるため、ユーザがチームで戦っている一体感を得ることができる。
【0287】
(付記B3)また、本発明の一態様は、付記B1または付記B2に記載のゲームシステムであって、前記NPC制御部は、前記領域において、同時に出現中となる前記NPCが予め設定された上限数となるまでは、所定の時間間隔で出現させる。
【0288】
付記B3の構成によれば、ゲームシステムは、領域(例えば、通常部屋)に最初に存在する(出現する)NPC(例えば、通常NPC)の初期数までは討伐されても復活してくるため、その領域の占拠が一人では簡単にはできないようにし、チームで協力したプレイを必要にすることができる。よって、ゲームシステム1は、チーム戦の意識の高いゲームを提供できる。
【0289】
(付記B4)また、本発明の一態様は、付記B1から付記B3のいずれか一に記載のゲームシステムであって、前記NPC制御部は、前記フィールド内に前記領域が複数ある場合、複数の前記領域毎に、前記NPCを出現させる時間間隔、または同時に出現中となる前記NPCの上限数を制御する。
【0290】
付記B4の構成によれば、ゲームシステムは、領域(例えば、通常部屋)毎に占拠の難易度を設定することができる。
【0291】
(付記B5)また、本発明の一態様は、付記B1から付記B4のいずれか一に記載のゲームシステムであって、前記NPC制御部は、同一の前記領域において前記所定の条件が満たされる度に、該領域において前記NPCを出現させる時間間隔を減少、または前記NPCを同時に出現可能な上限数を増加させる。
【0292】
付記B5の構成によれば、ゲームシステムは、同一の領域(例えば、通常部屋)をチーム同士で占拠しあうことでその領域を占拠する難易度が高くなるため、よりチームで協力したプレイが必要となり、白熱したゲーム展開が期待できる。
【0293】
(付記B6)また、本発明の一態様は、付記B1から付記B5のいずれか一に記載のゲームシステムであって、前記領域判定部により前記領域が関連付けられたチームに報酬を付与する報酬付与部(317)、を備える。
【0294】
付記B6の構成によれば、ゲームシステムは、ゲームシステム1は、領域(例えば、通常部屋)を占拠したチームまたはチームのユーザに対してポイントを付与するため、占拠状況だけでない楽しみを付加することができる。例えば、ゲームシステム1は、ユーザ毎にポイントを付与する場合、チーム同士の対戦に加えて、チーム内のユーザ同士でも競い合える楽しみをユーザに与えることができる。
【0295】
(付記B7)また、本発明の一態様は、付記B6に記載のゲームシステムであって、前記報酬付与部は、同一の前記領域において前記所定の条件が満たされる度に、付与する報酬の価値を高くする。
【0296】
付記B7の構成によれば、ゲームシステムは、同一の領域(例えば、通常部屋)をチーム同士で占拠しあうことで占拠したときに付与されるポイントが高くなるため、各チームのユーザに対して繰り返し対戦する意欲を高めることができ、白熱したゲーム展開が期待できる。
【0297】
(付記B8)また、本発明の一態様は、コンピュータを、付記B1から付記B7のいずれか一に記載のゲームシステムとして機能させるためのプログラム。
【0298】
付記B8の構成によれば、プログラムは、NPC(例えば、通常NPC)が討伐されても所定の時間間隔で復活するため、領域(例えば、通常部屋)の占拠が一人では簡単にはできないようにし、チームでより協力したプレイを必要にすることができる。よって、プログラムは、チーム戦の意識の高いゲームを提供できる。
【0299】
(付記C1)また、本発明の一態様に係るゲームシステム(1)は、複数のチームのそれぞれに属するユーザ情報により識別されるユーザ毎の操作に基づいて、前記複数のチームに共通のフィールド(FLD)内で前記ユーザ毎の第1のキャラクタを活動させるキャラクタ制御部(112)と、前記フィールド内で第1のNPC(ノンプレイヤキャラクタ)を制御する第1NPC制御部(113)と、前記複数のチームのうち第1のチームに属するユーザ情報により識別されるユーザの操作に基づいて、前記第1のチームから前記第1のNPCへの攻撃を制御するとともに、前記複数のチームのうち前記第1のチーム以外の第2のチームから前記第1のNPCへの攻撃を制限する対戦制御部(114)と、を備える。
【0300】
付記C1の構成によれば、ゲームシステムは、第1のNPC(例えば、通常NPC)に対してはいずれかのチームからしか攻撃することができないため(例えば、青チーム及び赤チームの双方から攻撃できないため)、オンラインゲームにおいて発生し得る、攻撃したはずなのに討伐できなかったという祖語が起きないように抑制することができる。即ち、ゲームシステムは、オンラインゲームで発生し得るタイムラグによる影響を抑制することができる。
【0301】
(付記C2)また、本発明の一態様は、付記C1に記載のゲームシステムであって、前記対戦制御部は、前記第1のチームに属するユーザ情報により識別されるユーザの操作に基づいて、前記第2のチームに属するユーザ情報により識別されるユーザ毎の操作に基づいて活動する第2のキャラクタへの攻撃を制御する場合、前記第1のNPCへの攻撃によって前記第1のNPCへ与える影響に比較して、前記第2のキャラクタへの攻撃によって前記第2のキャラクタへ与える影響が小さくなるように制限する。
【0302】
付記C2の構成によれば、ゲームシステムは、ユーザが操作するキャラクタ同士の対戦では、攻撃したはずなのに討伐できなかったという祖語が発生し得るが、攻撃によるダメージを極端に小さくすることで、上記キャラクタ同士の対戦を行うことによるメリットを少なくし、上記キャラクタ同士での対戦の動機となる要因を減らすことができるため、上記の齟齬による影響を抑制することができる。
【0303】
(付記C3)また、本発明の一態様は、付記C2に記載のゲームシステムであって、前記対戦制御部は、前記第2のキャラクタへの攻撃によって前記第2のキャラクタの活動を制限させる。
【0304】
付記C3の構成によれば、ゲームシステムは、ユーザが操作するキャラクタ同士の対戦では、対戦相手のキャラクタにダメージを与えるより動きを止めることが目的となるため、攻撃したはずなのに討伐できなかったという祖語が起きるのを抑制できる。
【0305】
(付記C4)また、本発明の一態様は、付記C1から付記C3のいずれか一に記載のゲームシステムであって、前記第1NPC制御部を備える複数の端末装置(10)と、前記端末装置と通信接続されるサーバ装置(30)と、を備え、前記第1NPC制御部は、前記フィールド内で前記第1のNPCの位置を、前記複数の端末装置毎に制御する。
【0306】
付記C4の構成によれば、ゲームシステムは、第1のNPC(例えば、通常NPC)のフィールド内の位置や動き(モーション)、攻撃(技)を発動した場合の効果(エフェクト)など基本的にはリアルタイム性の高いアクションは各ゲーム装置(端末側)で管理するため、通信によるタイムラグによる影響が生じないように抑制することができる。
【0307】
(付記C5)また、本発明の一態様は、付記C4に記載のゲームシステムであって、前記サーバ装置は、前記フィールド内で前記第1のNPCとは異なる第2のNPCを制御する第2NPC制御部(312)を備え、前記対戦制御部は、前記第1のチームに属するユーザ情報により識別されるユーザの操作に基づいて、前記第1のチームから前記第2のNPCへの攻撃を制御するとともに、前記第2のチームに属するユーザ情報により識別されるユーザの操作に基づいて、前記第2のチームから前記第2のNPCへの攻撃を制御し、前記第2NPC制御部は、前記フィールド内で前記第2のNPCの位置を、複数の前記端末装置で同じ位置になるように制御する。
【0308】
付記C5の構成によれば、ゲームシステムは、両陣営双方(例えば、青チーム及び赤チームの双方)から攻撃される第2のNPC(例えば、ボスNPC)については、各ゲーム装置で攻撃対象の位置が同じになるように同期することができるため、同一攻撃対象に対する複数ユーザの戦闘において整合性を確保できる。
【0309】
(付記C6)また、本発明の一態様は、付記C5に記載のゲームシステムであって、前記第2のNPCを討伐するには、前記第1のNPCを討伐するのに比較して多くの攻撃を要する。
【0310】
付記C6の構成によれば、ゲームシステムは、討伐時(最後のとどめ)の攻撃については、攻撃したはずなのに討伐できなかったという祖語が起こり得るものの、それまでの両チームからの攻撃に関してはその順番が入れ替わってとしても大きな祖語とはなり得ないため、討伐するまでの攻撃全体として上記の齟齬による影響を少なくすることができる。
【0311】
(付記C7)また、本発明の一態様は、コンピュータを、付記C1から付記C6のいずれか一に記載のゲームシステムとして機能させるためのプログラム。
【0312】
付記C7の構成によれば、プログラムは、第1のNPC(例えば、通常NPC)に対してはいずれかのチームからしか攻撃することができないため(例えば、青チーム及び赤チームの双方から攻撃できないため)、オンラインゲームにおいて発生し得る、攻撃したはずなのに討伐できなかったという祖語が起きないように抑制することができる。即ち、プログラムは、オンラインゲームで発生し得るタイムラグによる影響を抑制することができる。
【0313】
(付記D1)また、本発明の一態様に係るゲームシステム(1)は、チームに属するユーザ情報により識別されるユーザの操作結果が所定の条件を満たしたか否かに基づいて、フィールド(FLD)内の複数の領域のそれぞれを前記チームに関連付けるか否か(例えば、いずれのチームの占拠とするか)を判定する領域判定部(315、S100)と、予め設定された制限時間内における前記領域判定部による判定結果に基づいて、前記チームの勝敗を判定する勝敗判定部(316、S114)と、を備え、前記勝敗判定部は、前記複数の領域の前記チームへの関連付け状況に基づいて、前記制限時間に達する前であっても前記チームの勝敗を確定する(S204~S220)。
【0314】
付記D1の構成によれば、ゲームシステムは、チームを構成する複数のユーザがそれぞれのキャラクタを操作して敵キャラクタと戦闘するアクションゲームにおいて、制限時間を待たずして戦況の優劣が明確となり実質的に勝敗が決着してしまうような場合に、その時点で勝敗を確定して終了するため、ユーザにとって無駄なプレイ時間が生じることを抑制できる。
【0315】
(付記D2)また、本発明の一態様は、付記D1に記載のゲームシステムであって、前記勝敗判定部は、前記複数の領域の前記チームへの関連付け状況が予め設定された状況になった場合(例えば、一方のチームによって全部屋占拠された場合)、該状況が所定時間維持されたことを条件として、前記制限時間に達する前であっても前記チームの勝敗を確定する(S204~S220)。
【0316】
付記D2の構成によれば、ゲームシステムは、複数の領域のチームへの関連付け状況が予め設定された状況になった(例えば、一方のチームによって全部屋占拠された)としても、占拠された側のチームに巻き返しのチャンスとなる時間を与えることができる。よって、ゲームシステムは、何らかの要因で一気に攻められて実力を出せずに対戦が終了してしまうような不合理が生じてしまことを抑制できる。
【0317】
(付記D3)また、本発明の一態様は、付記D2に記載のゲームシステムであって、前記勝敗判定部は、前記複数の領域の前記チームへの関連付け状況が予め設定された状況になった回数に応じて、前記所定時間を短縮する(S204、S216)。
【0318】
付記D3の構成によれば、ゲームシステムは、例えば、全部屋占拠が繰り返された場合には、1回目の全部屋占拠のときよりも該チームが優勢であることがより確実と考えられるため、占拠された側のチームの巻き返しのチャンスとなる時間を短くし、全部屋占拠した側のチームのユーザにとって無駄なプレイ時間が生じることを抑制することができる。
【0319】
(付記D4)また、本発明の一態様は、付記D3に記載のゲームシステムであって、複数の前記チームによる対戦の場合、前記回数は、チーム毎に計数される。
【0320】
付記D4の構成によれば、ゲームシステムは、例えば一方のチームによる全部屋占拠した後に、他方のチームが全部屋占拠し返した場合には、戦況の優劣が明確になっていないと考えられるため、各チームに対して平等に巻き返しのチャンスとなる時間を与えることができる。
【0321】
(付記D5)また、本発明の一態様は、付記D2から付記D4のいずれか一に記載のゲームシステムであって、前記複数の領域の前記チームへの関連付け状況が予め設定された状況になった場合、前記所定時間となるまでの時間を示す情報を表示させる表示制御部(115)、を備える。
【0322】
付記D5の構成によれば、ゲームシステムは、対戦プレイ中のユーザに勝敗が確定するまでの時間をカウントダウンなどで提示するため、緊張感を高めることができる。また、ゲームシステムは、勝敗が確定するまでの残り時間をユーザが把握し易くなるため、残り時間で何をするべきかの戦略をユーザが考え易くすることができる。
【0323】
(付記D6)また、本発明の一態様は、付記D2から付記D5のいずれか一に記載のゲームシステムであって、前記表示制御部は、前記複数の領域の前記チームへの関連付け状況が予め設定された状況になった場合、前記制限時間に達するまでの残時間と前記所定時間とに基づいて、前記所定時間となるまでの時間を示す情報を表示させるか否かを判定する(S206、S214)。
【0324】
付記D6の構成によれば、ゲームシステムは、対戦の残り時間がカウントダウンの時間よりも短い場合にはカウントダウンを開始してもカウントダウンが「0」になる前に制限時間により対戦が終了してしまうため、意味のないカウントダウン表示を行わないようにすることができる。
【0325】
(付記D7)また、本発明の一態様は、付記D1から付記D6のいずれか一に記載のゲームシステムであって、前記チームに属するユーザ情報により識別されるユーザ毎の操作に基づいて、前記ユーザに共通の複数の領域を有するフィールド内で前記ユーザ情報毎に関連付けられたキャラクタを移動させるキャラクタ移動部(112)、を備える。
【0326】
付記D7の構成によれば、ゲームシステムは、制限時間を待たずして戦況の優劣が明確となり実質的に勝敗が決着してしまうような場合に、その時点で勝敗を確定して終了するため、ユーザが無駄にフィールド内でキャラクタを移動させる時間が生じることを抑制できる。
【0327】
(付記D8)また、本発明の一態様は、コンピュータを、付記D1から付記D7のいずれか一に記載のゲームシステムとして機能させるためのプログラム。
【0328】
付記D8の構成によれば、プログラムは、チームを構成する複数のユーザがそれぞれのキャラクタを操作して敵キャラクタと戦闘するアクションゲームにおいて、制限時間を待たずして戦況の優劣が明確となり実質的に勝敗が決着してしまうような場合に、その時点で勝敗を確定して終了するため、ユーザにとって無駄なプレイ時間が生じることを抑制できる。
【0329】
(付記E1)また、本発明の一態様に係るゲームシステム(1)は、チームに属するユーザ情報により識別されるユーザ毎の操作に基づいて、前記チーム内で共通のフィールド(FLD)内で前記ユーザ情報毎に関連付けられたキャラクタを活動させるキャラクタ制御部(112)と、第1状態(例えば、通常状態)の前記キャラクタについて所定の第1条件が満たされることを条件として該キャラクタを前記第1状態よりも能力が低下した第2状態(例えば、仮死状態)に遷移させ、前記第2状態の前記キャラクタについて所定の第2条件が満たされることを条件として該キャラクタの活動が制限される第3状態(例えば、死亡状態)に遷移させるキャラクタ状態制御部(1121、S304、S312)と、前記第2状態の前記キャラクタを、該キャラクタと同じチームに属する他の前記キャラクタに基づいて前記第1状態に復活させる復活制御部(1122、S312)と、前記キャラクタ制御部により前記キャラクタが活動した結果に基づいて、前記チームの勝敗を判定する勝敗判定部(316、S114)と、を備える。
【0330】
付記E1の構成によれば、ゲームシステムは、第1状態(例えば、通常状態)のキャラクタが攻撃を受けて第3状態(例えば、死亡状態)になる前に、同じチームの協力による復活のチャンスがある第2状態(例えば、仮死状態)にすることができる。よって、ゲームシステムは、チーム対戦型のアクションゲームにおいて、チーム内の協力の機会をより多くすることができる。
【0331】
(付記E2)また、本発明の一態様は、付記E1に記載のゲームシステムであって、前記復活制御部は、前記第3状態(例えば、死亡状態)の前記キャラクタを、前記第3状態になってから所定時間が経過することによって前記第1状態(例えば、通常状態)または第2状態(例えば、仮死状態)に遷移させる。
【0332】
付記E2の構成によれば、ゲームシステムは、キャラクタが第3状態(例えば、死亡状態)になってもゲームオーバーとなるのではなく引き続きプレイは進行し、一定時間操作が不可となった後に再スタートとなるため、再び対戦プレイに参加してチームに貢献することができる。また、ゲームシステムは、キャラクタが第3状態(例えば、死亡状態)になるとそのキャラクタに対して一定時間操作ができなくなるため、仮死状態のうちになんとか復活させられるようにチーム内で協力する動機付けを与えることができる。
【0333】
(付記E3)また、本発明の一態様は、付記E2に記載のゲームシステムであって、前記復活制御部は、前記第3状態(例えば、死亡状態)の前記キャラクタを前記第1状態(例えば、通常状態)または前記第2状態(例えば、仮死状態)に遷移させる場合、遷移させた前記キャラクタをフィールド内の所定の場所に配置する。
【0334】
付記E3の構成によれば、ゲームシステムは、一旦第3状態(例えば、死亡状態)になったキャラクタをスタート部屋からの再スタートさせることで、一定時間操作が不可という時間的なペナルティに加えて、場所的なペナルティも与えることができる。
【0335】
(付記E4)また、本発明の一態様は、付記E1から付記E3のいずれか一に記載のゲームシステムであって、前記復活制御部は、前記第2状態(例えば、仮死状態)の前記キャラクタを、該キャラクタと同じチームに属する他の前記第1状態(例えば、通常状態)の前記キャラクタとの位置関係に基づいて、前記第1状態に復活させる。
【0336】
付記E4の構成によれば、ゲームシステムは、仮死状態のキャラクタを復活させるには、その仮死状態のキャラクタがいる場所に同じチームの他のキャラクタが移動することが必要になるため、チームメンバーが協力して救出する感覚を与えることができる。
【0337】
(付記E5)また、本発明の一態様は、付記E1から付記E4のいずれか一に記載のゲームシステムであって、前記第3状態(例えば、死亡状態)とは、前記キャラクタの活動が制限された状態であって、且つ前記キャラクタと同じチームに属する他の前記キャラクタに基づいて前記第1状態(例えば、通常状態)に復活することが不可能な状態であることが含まれる。
【0338】
付記E5の構成によれば、ゲームシステムは、キャラクタが第3状態(例えば、死亡状態)になると、チーム内の協力では復活不可能となるため、第2状態(例えば、仮死状態)のうちになんとか復活させられるようにチーム内で協力する動機付けを与えることができる。
【0339】
(付記E6)また、本発明の一態様は、付記E5に記載のゲームシステムであって、前記第1状態(例えば、通常状態)よりも能力が低下した前記第2状態(例えば、仮死状態)とは、前記キャラクタの活動が制限された状態であることが含まれる。
【0340】
付記E6の構成によれば、ゲームシステムは、キャラクタを第2状態(例えば、仮死状態)に遷移させた場合、そのキャラクタの活動が第1状態(例えば、通常状態)より制限されるため、対戦プレイにおいてチームの戦力が低下することから、その第2状態のプレイヤキャラクタを復活させる動機付けをチームメンバーに与えることができる。
【0341】
(付記E7)また、本発明の一態様は、付記E1から付記E5のいずれか一に記載のゲームシステムであって、前記第1状態(例えば、通常状態)よりも能力が低下したと前記第2状態(例えば、仮死状態)とは、前記第1状態(例えば、通常状態)よりも前記キャラクタに関連付けられているパラメータの値が前記キャラクタの能力が低下する値に変更された状態であることが含まれる。
【0342】
付記E7の構成によれば、ゲームシステムは、キャラクタを第2状態(例えば、仮死状態)に遷移させた場合、そのキャラクタの攻撃力、防御力、及びHPなどのパラメータの値が第1状態(例えば、通常状態)より低下するため、対戦プレイにおいてチームの戦力が低下することから、その第2状態(例えば、仮死状態)のキャラクタを復活させる動機付けをチームメンバーに与えることができる。
【0343】
(付記E8)また、本発明の一態様は、付記E1から付記E7のいずれか一に記載のゲームシステムであって、前記復活制御部は、前記第2状態(例えば、仮死状態)から前記第1状態(例えば、通常状態)に復活させる回数を制限する。
【0344】
付記E8の構成によれば、ゲームシステムは、いくらでも復活できることによってプレイの難易度が低下しすぎてしまったり、チーム間の実力差が反映されなくなってしまうことがないように抑制することができる。
【0345】
(付記E9)また、本発明の一態様は、付記E1から付記E8のいずれか一に記載のゲームシステムであって、第1の端末装置においてユーザの操作に基づいて活動する前記キャラクタが前記第2状態(例えば、仮死状態)である場合、該キャラクタを第2の端末装置において前記第1状態(例えば、通常状態)の前記キャラクタと識別可能な表示態様で表示させる表示制御部(115)、を備える。
【0346】
付記E9の構成によれば、ゲームシステムは、第2状態(例えば、仮死状態)になったキャラクタを第1状態(例えば、通常状態)のキャラクタに対して容易に区別できるように、プレイ画面に表示させることができる。
【0347】
(付記E10)また、本発明の一態様は、コンピュータを、付記E1から付記E9のいずれか一に記載のゲームシステムとして機能させるためのプログラム。
【0348】
付記E10の構成によれば、プログラムは、第1状態(例えば、通常状態)のキャラクタが攻撃を受けて第3状態(例えば、死亡状態)になる前に、同じチームの協力による復活のチャンスがある第2状態(例えば、仮死状態)にすることができる。よって、プログラムは、チーム対戦型のアクションゲームにおいて、チーム内の協力の機会をより多くすることができる。
【0349】
(付記F1)また、本発明の一態様に係るゲームシステム(1)は、チームに属するユーザ情報により識別されるユーザ毎の操作に基づいて、前記チーム内で共通のフィールド(FLD)内を、前記ユーザ情報毎に関連付けられたキャラクタを移動させるキャラクタ移動部(112)と、前記フィールド内に配置された第1オブジェクト(例えば、宝箱アイテム)を取得する操作がいずれかの前記ユーザにより行われた場合、前記チームに属するユーザ情報により識別される各ユーザに対してユーザ毎に選択された報酬(例えば、アイテム)を付与する報酬付与部(317、S408)と、を備える。
【0350】
付記F1の構成によれば、ゲームシステムは、フィールド内に存在する複数の第1オブジェクト(例えば、宝箱アイテム)をチーム内のユーザで分担して取得することができるため、チーム対戦型のアクションゲームにおいて、チーム内の協力の機会をより多くすることができる。
【0351】
(付記F2)また、本発明の一態様は、付記F1に記載のゲームシステムであって、前記報酬付与部が前記チームに属するユーザ情報により識別される各ユーザに付与したユーザ毎の報酬の内容(例えば、アイテムの種類)を表示させる第1表示制御部(115、S410)、を備える。
【0352】
付記F2の構成によれば、ゲームシステムは、チーム内の各ユーザに付与された報酬の内容が分かるので、チーム内のコミュニケーションのきっかけにすることができる。
【0353】
(付記F3)また、本発明の一態様は、付記F2に記載のゲームシステムであって、前記第1表示制御部は、前記フィールド内に配置された前記第1オブジェクト(例えば、宝箱アイテム)を報酬内容(例えば、アイテムの種類)が識別不可能な表示態様で表示させる。
【0354】
付記F3の構成によれば、ゲームシステムは、第1オブジェクト(例えば、宝箱アイテム)を取得した後に報酬内容が分かること、即ち報酬内容が取得前に分からないことを示唆するとともに、分からないことにより、取得する際の期待感を高めることができる。
【0355】
(付記F4)また、本発明の一態様は、付記F1から付記F3のいずれか一に記載のゲームシステムであって、前記報酬付与部は、前記キャラクタと第1オブジェクト(例えば、宝箱アイテム)との位置関係に基づいて前記報酬(例えば、アイテム)を付与する。
【0356】
付記F4の構成によれば、ゲームシステムは、フィールド内に存在する複数の第1オブジェクト(例えば、宝箱アイテム)のそれぞれに対してチーム内のユーザが分担して移動させることで、効率よくユーザが報酬(例えば、アイテム)を取得することができる。
【0357】
(付記F5)また、本発明の一態様は、付記F1から付記F4のいずれか一に記載のゲームシステムであって、前記報酬付与部は、いずれかの前記ユーザの操作により取得済みとなった前記第1オブジェクトを、前記チームに属するユーザ情報により識別されるいずれのユーザに対しても取得対象から除外する。
【0358】
付記F5の構成によれば、ゲームシステムは、同じチーム内の複数のユーザで第1オブジェクト(例えば、宝箱アイテム)を重複して取得することができないため、価値の高い報酬(例えば、アイテム)をユーザに付与しすぎないようにすることができる。
【0359】
(付記F6)また、本発明の一態様は、付記F1から付記F5のいずれか一に記載のゲームシステムであって、前記フィールド内には、前記第1オブジェクトと異なる第2オブジェクト(例えば、通常アイテム)が配置されており、前記報酬付与部は、前記フィールド内に配置された第2オブジェクトを取得する操作がいずれかの前記ユーザにより行われた場合、該ユーザに対して報酬(例えば、アイテム)を付与するとともに、該第2オブジェクト(例えば、通常アイテム)を取得する操作が他の前記ユーザにより行われた場合、該他の前記ユーザに対して報酬(例えば、アイテム)を付与する(S404)。
【0360】
付記F6の構成によれば、ゲームシステムは、あるユーザが取得した第2オブジェクト(例えば、通常アイテム)がチームに関係なく他のユーザも取得可能であるため、どのユーザに対しても平等に第2オブジェクトの取得の機会を与えることができる。また、ゲームシステム1は、いつどこで第2オブジェクトを取得するか(例えば、HPを回復させるか)などの戦略をユーザ毎に立てられるようにすることができる。
【0361】
(付記F7)また、本発明の一態様は、付記F6のいずれか一に記載のゲームシステムであって、前記フィールド内に配置された前記第2オブジェクト(例えば、通常アイテム)の配置情報は前記ユーザ情報毎に関連付けられており、前記ユーザ情報毎に関連付けられた配置情報によって特定される前記第2オブジェクトの配置位置が共通である。
【0362】
付記F7の構成によれば、ゲームシステムは、どのユーザに対してもフィールド内の同じ場所に第2オブジェクト(例えば、通常アイテム)を配置するため、どのユーザに対しても平等に第2オブジェクトの取得の機会を与えることができる。
【0363】
(付記F8)また、本発明の一態様は、付記F7のいずれか一に記載のゲームシステムであって、前記ユーザ情報毎に関連付けられた配置情報によって特定される前記第2オブジェクトの報酬内容が共通である。
【0364】
付記F8の構成によれば、ゲームシステムは、どのユーザに対してもフィールド内の同じ場所に同じ種類の第2オブジェクト(例えば、通常アイテム)を配置するため、どのユーザに対しても平等に第2オブジェクトの取得の機会を与えることができる。
【0365】
(付記F9)また、本発明の一態様は、付記F6または付記F7に記載のゲームシステムであって、前記フィールド内に配置された前記第2オブジェクト(例えば、通常アイテム)を報酬内容(例えば、アイテムの種類)が識別可能な表示態様で表示させる第2表示制御部(115)、を備える。
【0366】
付記F9の構成によれば、ゲームシステムは、付与される報酬の内容をユーザが事前に確認した上で第2オブジェクト(例えば、通常アイテム)を取得可能にできる。例えば、第2オブジェクトは、HPを回復するアイテムなどのように、その場で消費されるものが多い。そのため、ユーザは、付与される報酬の内容を事前に確認した上で、必要に応じて第2オブジェクトを取得するか否かを判断できる。
【0367】
(付記F10)また、本発明の一態様は、コンピュータを、付記F1から付記F3のいずれか一に記載のゲームシステムとして機能させるためのプログラム。
【0368】
付記F10の構成によれば、プログラムは、フィールド内に存在する複数の第1オブジェクト(例えば、宝箱アイテム)をチーム内のユーザで分担して取得することができるため、チーム対戦型のアクションゲームにおいて、チーム内の協力の機会をより多くすることができる。
【0369】
(付記G1)また、本発明の一態様に係るゲームシステム(1)は、チーム内に共通のフィールド(FLD)内で、前記チームに属するユーザ情報により識別されるユーザ毎に操作されるキャラクタと、該キャラクタの対戦相手とが対戦するゲームにおいて、前記ユーザ毎に操作されるキャラクタのそれぞれに関連付けられた特性に基づく効果を表示させる表示処理を実行する表示制御部(115)、を備え、前記表示制御部は、予め設定された優先度に基づいて、前記効果の表示に制限を設ける。
【0370】
付記G1の構成によれば、ゲームシステムは、優先度に基づいてエフェクト(効果)の表示に制限を設けるため、複数のキャラクタによるエフェクト表示を適切に制御することができる。
【0371】
(付記G2)また、本発明の一態様は、付記G1に記載のゲームシステムであって、前記表示制御部を備えた端末装置(10)と、前記端末装置と通信接続されるサーバ装置(30)と、を備え、前記表示制御部は、前記表示処理を実行する端末装置の処理負荷に基づいて、前記効果の表示に制限を設ける。
【0372】
付記G2の構成によれば、ゲームシステムは、端末装置の処理負荷がオーバーしないように(過負荷とならないように)処理負荷を低減しつつ、優先度の高いエフェクト(効果)は表示させるため、複数のキャラクタによるエフェクト表示を適切に制御することができる。
【0373】
(付記G3)また、本発明の一態様は、付記G1または付記G2に記載のゲームシステムであって、前記端末装置を複数備え、前記表示制御部は、前記表示処理を実行する端末装置以外の端末装置で操作されるキャラクタの前記効果の表示を制限する。
【0374】
付記G3の構成によれば、ゲームシステムは、ユーザ自身が操作するキャラクタのエフェクト(効果)を該ユーザが操作する端末装置で優先的に表示させるため、端末装置で操作するユーザの操作感を確保することができる。
【0375】
(付記G4)また、本発明の一態様は、付記G3に記載のゲームシステムであって、前記表示制御部は、前記表示処理を実行する端末装置で前記ユーザの操作可能なキャラクタの所持履歴もしくは使用履歴、または該キャラクタに装備可能なアイテムの所持履歴もしくは使用履歴に基づいて、該端末装置以外の端末装置で操作されるキャラクタの前記効果の表示を制限する。
【0376】
付記G4の構成によれば、ゲームシステムは、ユーザが既に知っているキャラクタやアイテムであるか否かによってエフェクト(効果)の表示の優先度を設定できるため、ユーザに知らせる必要度が低いエフェクトの表示よりも、ユーザに知らせる必要度が高いエフェクト(ユーザが未だ見たことがないエフェクト)の表示を優先して表示させることができる。
【0377】
(付記G5)また、本発明の一態様は、付記G1から付記G4のいずれか一に記載のゲームシステムであって、前記表示制御部は、前記ユーザ毎に操作されるキャラクタのそれぞれに関連付けられた特性に基づいて予め設定された優先度に基づいて、前記効果の表示を制限を設ける。
【0378】
付記G5の構成によれば、ゲームシステムは、プレイヤキャラクタの特性によってエフェクト(効果)の表示の優先度を設定できるため、優先度を高く設定した特性のプレイヤキャラクタを目立たせることでき、ユーザに対してその特性のキャラクタの入手意欲を起こすことができる。
【0379】
(付記G6)また、本発明の一態様は、付記G1から付記G5のいずれか一に記載のゲームシステムであって、前記ユーザ毎のキャラクタのそれぞれに関連付けられた特性は、それぞれのキャラクタに関連付けられたアイテムに基づく。
【0380】
付記G6の構成によれば、ゲームシステムは、装備アイテムの特性によってエフェクト(効果)の表示の優先度を設定できるため、優先度を高く設定した特性の装備アイテムを目立たせることでき、ユーザに対してその特性のアイテムの入手意欲を起こすことができる。
【0381】
(付記G7)また、本発明の一態様は、付記G1から付記G5のいずれか一に記載のゲームシステムであって、前記ユーザ毎のキャラクタのそれぞれに関連付けられた特性は、それぞれのキャラクタまたはそれぞれのキャラクタに関連付けられたアイテムの希少度に基づく。
【0382】
付記G7の構成によれば、ゲームシステムは、キャラクタのレアリティまたはアイテムのレアリティが高いほど、そのエフェクトの表示を優先することができる。よって、例えば見たこともない希少価値の高そうな武器やキャラクタを目立たせることでき、ユーザに対してそれらの武器やキャラクタの入手意欲を起こすことができる。
【0383】
(付記G8)また、本発明の一態様は、付記G1から付記G5のいずれか一に記載のゲームシステムであって、前記ユーザ毎のキャラクタのそれぞれに関連付けられた特性は、それぞれのキャラクタまたはそれぞれのキャラクタに関連付けられたアイテムに設定されている期間限定効果に基づく。
【0384】
付記G8の構成によれば、ゲームシステムは、特別な効果が得られる限定期間では、その特別な効果のエフェクトの表示を優先することができる。よって、例えば期間限定で効果のある武器やキャラクタを目立たせることでき、ユーザに対してそれらの武器やキャラクタの入手意欲を起こすことができる。
【0385】
(付記G9)また、本発明の一態様は、コンピュータを、付記G1から付記G8のいずれか一に記載のゲームシステムとして機能させるためのプログラム。
【0386】
付記G9の構成によれば、プログラムは、優先度に基づいてエフェクト(効果)の表示に制限を設けるため、複数のキャラクタによるエフェクト表示を適切に制御することができる。
【符号の説明】
【0387】
1 ゲームシステム、10 ゲーム装置、11 CPU、12 通信部、13 入力部、14 表示部、15 記憶部、30 ゲームサーバ、31 CPU、32 通信部、35 記憶部、110 ゲーム制御部、111 サーバ制御情報取得部、112 キャラクタ制御部、113 通常NPC制御部、114 対戦制御部、115 表示制御部、310 サーバ制御部、311 端末制御情報取得部、312 ボスNPC制御部、313 通常NPC状態同期部、314 プレイヤキャラクタ同期部、315 占拠判定部、316 勝敗判定部、317 報酬付与部、351 ユーザデータ記憶部、352 チームデータ記憶部、353 キャラクタデータ記憶部、354 アイテムデータ記憶部、355
所持データ記憶部
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23