JP2020099731A

JP2020099731A - ゲームシステム、及びプログラム

Info

Publication number: JP2020099731A
Application number: JP2020041772A
Authority: JP
Inventors: 雅明小池; Masaaki Koike
Original assignee: Konami Digital Entertainment Co Ltd
Current assignee: Konami Digital Entertainment Co Ltd
Priority date: 2017-06-09
Filing date: 2020-03-11
Publication date: 2020-07-02
Anticipated expiration: 2037-06-09
Also published as: JP7486781B2

Abstract

【課題】チーム対戦型のアクションゲームにおいて、チーム内の協力の機会をより多くすること。【解決手段】ゲームシステムは、チームに属するユーザ情報により識別されるユーザ毎の操作に基づいて、チーム内で共通のフィールド内でユーザ情報毎に関連付けられたキャラクタを活動させるキャラクタ制御部と、第１状態のキャラクタについて所定の第１条件が満たされることを条件として該キャラクタを第１状態よりも能力が低下した第２状態に遷移させ、第２状態のキャラクタについて所定の第２条件が満たされることを条件として該キャラクタの活動が制限される第３状態に遷移させるキャラクタ状態制御部と、第２状態のキャラクタを、該キャラクタと同じチームに属する他のキャラクタに基づいて第１状態に復活させる復活制御部と、キャラクタ制御部によりキャラクタが活動した結果に基づいて、チームの勝敗を判定する勝敗判定部と、を備える。【選択図】図７

Description

本発明は、ゲームシステム、及びプログラムに関する。

複数のユーザのそれぞれが操作するキャラクタが敵キャラクタと戦闘しながらゲームを進行させるアクションゲームがある（例えば、特許文献１）。例えば、チーム対戦型の場合には、チームメンバーの協力が戦闘を有利に進めるための重要な要素となっている。一般的に、ユーザが操作するキャラクタが対戦相手からの攻撃によりダメージを受けて死亡すると、一定時間対戦に参加できなかったり、次の対戦まで参加できなかったり、或いは、対戦相手に多くのポイントが付与されるなど、当該ユーザとしてもチームとしても大きな代償を払うことになる。そのため、チームメンバーのキャラクタが死亡に至らないようにチーム内で協力してプレイを行うこととなる。

特開２０１０−２０７４０４号公報

しかしながら、チーム内で協力したとしても、チームメンバーのキャラクタが１体も死亡に至らずにプレイを続けていけるとは限らない。自分が操作しているキャラクタが死亡すると、そのユーザは、一定時間チームに貢献できなくなり、モチベーションが低下してしまうことがあった。

本発明のいくつかの態様は、チーム対戦型のアクションゲームにおいて、チーム内の協力の機会がより多いゲームシステム、及びプログラムを提供することを目的の一つとする。

また、本発明の他の態様は、後述する実施形態に記載した作用効果を奏することを可能にするゲームシステム、及びプログラムを提供することを目的の一つとする。

上述した課題を解決するために、本発明の一態様は、チームに属するユーザ情報により識別されるユーザ毎の操作に基づいて、前記チーム内で共通のフィールド内で前記ユーザ情報毎に関連付けられたキャラクタを活動させるキャラクタ制御部と、第１状態の前記キャラクタについて所定の第１条件が満たされることを条件として該キャラクタを前記第１状態よりも能力が低下した第２状態に遷移させ、前記第２状態の前記キャラクタについて所定の第２条件が満たされることを条件として該キャラクタの活動が制限される第３状態に遷移させるキャラクタ状態制御部と、前記第２状態の前記キャラクタを、該キャラクタと同じチームに属する他の前記キャラクタに基づいて前記第１状態に復活させる復活制御部と、前記キャラクタ制御部により前記キャラクタが活動した結果に基づいて、前記チームの勝敗を判定する勝敗判定部と、を備えるゲームシステムである。

また、本発明の一態様は、コンピュータを、上記のゲームシステムとして機能させるためのプログラムである。

第１の実施形態に係るフィールドの一例を示す図。第１の実施形態に係る通常部屋におけるプレイ画面の一例を示す図。第１の実施形態に係るボス部屋におけるプレイ画面の一例を示す図。第１の実施形態に係るゲームシステムの構成の一例を示すブロック図。第１の実施形態に係るゲーム装置のハードウェア構成の一例を示す図。第１の実施形態に係るゲームサーバのハードウェア構成の一例を示す図。第１の実施形態に係るゲーム装置及びゲームサーバの構成の一例を示すブロック図。第１の実施形態に係る占拠判定処理の一例を示すフローチャート。第１の実施形態に係る勝敗判定処理の第一例を示すフローチャート。第１の実施形態に係る勝敗判定処理の第二例を示すフローチャート。第１の実施形態に係る部屋占拠時に付与されるポイントの一例を示す図。第１の実施形態に係る占拠済みの部屋数とボーナス係数の設定の一例を示す図。第２の実施形態に係る通常ＮＰＣの出現方法の設定例を示す図。第３の実施形態に係る通常ＮＰＣとボスＮＰＣとの処理の違いを示す図。第４の実施形態に係る対戦プレイにおけるカウントダウン処理の一例を示すフローチャート。第５の実施形態に係るプレイヤキャラクタの状態毎の見た目の一例を示す図。第５の実施形態に係るキャラクタ制御部の詳細構成の一例を示すブロック図。第５の実施形態に係る状態遷移処理の一例を示すフローチャート。第６の実施形態に係る宝箱アイテムの表示例を示す図。第６の実施形態に係る通常アイテムの表示例を示す図。第６の実施形態に係る報酬付与処理の一例を示すフローチャート。第７の実施形態に係るプレイ画面におけるエフェクトの表示例を示す図。第７の実施形態に係るエフェクトの設定情報の一例を示す図。

[第１の実施形態]
以下、本発明の第１の実施形態について、図面を参照して説明する。

〔ゲームの概要〕
まず、本実施形態に係るゲームの一例について、その概要を説明する。例えば、本実施形態に係るゲームは、複数のユーザのそれぞれが操作するキャラクタ（以下、「プレイヤキャラクタ」ともいう）が敵キャラクタと戦闘しながらゲームを進行させるアクションゲームであり、ここではチーム対戦モードを例にして説明する。チーム数は、２チームであってもよいし、３チーム以上であってもよいが、ここでは、２チームによる対戦（即ち、１チーム対１チームの対戦）の場合を例に説明する。チーム毎に複数のユーザのそれぞれに操作されるプレイヤキャラクタが存在するため、多人数対多人数の対戦となる。

ユーザは、ゲームのプレイを開始すると、対戦前に自チームおよび対戦チームを決定する。自チームに参加するユーザを決定するメンバーマッチングが行われた後、対戦相手のチームのメンバーマッチングが行われる。例えば、１チームは４名であり、４名対４名の対戦となる。なお、１チームの人数は他の人数であってもよい。自チームのマッチングは、サーバ装置によるその場限りのランダムマッチングと、ユーザ同士で結成したチームによるマッチングが存在する。対戦相手はサーバ装置によるランダムマッチングとなる。なお、チーム対戦に参加するには、ゲームにおいて設定されている特定のポイントやチケット等のアイテムを消費して参加する仕様としてもよい。

キャラクタとは、ゲームに登場する人物、動物、物体（例えば、乗り物）などである。チームのメンバーマッチングが行われた後、ユーザは、自身が操作するプレイヤキャラクタを選択する。例えば、プレイヤキャラクタは、ゲームをプレイするユーザの操作対象となる戦士（人物）である。ユーザが操作するプレイヤキャラクタは、１体であってもよいし、組（パーティ）の形態をとった２体以上であってもよい。２体以上の場合には、いずれか１体に切り替えながらプレイを行うことができる。本実施形態では、ユーザ毎に操作されるプレイヤキャラクタは、それぞれ１体であるものとして説明する。

プレイヤキャラクタには、能力を示す指標として、ＨＰ（ＨｉｔＰｏｉｎｔ）、ＭＰ（ＭａｇｉｃＰｏｉｎｔ）、攻撃力、防御力、などのようなユーザのプレイ内容に影響するパラメータが関連付けられている。ＨＰは、体力や生命力を示す値であり、ゲームの継続の可否を判定するためのポイントとなるパラメータである。このＨＰは、敵からの攻撃により減少し、所定値以下（例えば、「０」）になるとゲームの継続が不可となる。ＭＰは、プレイヤキャラクタが特殊能力や特殊武器などのアイテムを使用する際に消費する値である。攻撃力及び防御力のそれぞれは、プレイヤキャラクタの攻撃に関する能力及び防御に関する能力を示す値である。攻撃力は、攻撃対象へのダメージの大きさを示すパラメータであり、攻撃対象のＨＰの減少量に関係する。防御力は、攻撃を受けた際のダメージに対する耐性を示すパラメータであり、ＨＰの減少量の低減に関係する。例えば、攻撃力及び防御力は、プレイヤキャラクタの能力としてプレイヤキャラクタ毎に個別に設定されている。一方、ＨＰ及びＭＰは、プレイヤキャラクタを操作するユーザに関連付けられている。なお、ＨＰ及びＭＰは、プレイヤキャラクタに関連付けられていてもよい。

なお、プレイヤキャラクタに帯同する帯同キャラクタを選択可能な仕様としてもよい。帯同キャラクタは、プレイヤキャラクタに代わって、または協力して敵キャラクタを倒したり、プレイヤキャラクタのＨＰを回復させるなど、ユーザのプレイをサポートする。例えば、帯同キャラクタは、ユーザの操作によらずＡＩ（人工知能）によって自律的に行動するキャラクタである。帯同キャラクタとして選択可能なキャラクタには、複数の種類のキャラクタがあり、どのキャラクタを帯同させるかによって、その効果が異なる。

また、プレイヤキャラクタにアイテムを装備することで、プレイヤキャラクタの能力を向上させることができる。アイテムは、複数のカテゴリに分類されている。例えば、アイテムは、「武器」、「防具」、及び「特殊武器」の３つのカテゴリに分類されている。プレイヤキャラクタの能力とは、プレイヤキャラクタの攻撃力、防御力などのパラメータや、特殊武器を所持することで特殊な攻撃を行うことができることなどである。なお、カテゴリの種類や分類数は任意に定めることができる。

具体的には、「武器」は、プレイヤキャラクタの攻撃力などパラメータを向上させるアイテムである。「防具」は、プレイヤキャラクタの防御力などパラメータを向上させる装備アイテムである。「特殊武器」は、所定の時間が経つと爆発を起こすような大きなダメージを与える攻撃が可能なアイテムである。例えば、これらのアイテムは、抽選や所定のイベントをクリアすることでユーザが取得することができる。

また、プレイヤキャラクタ、またはプレイヤキャラクタに装備可能なアイテムのそれぞれには、個々の能力の特徴を示す特性が設定されており、その特性の組み合わせによって攻撃の種類や威力が変わる。そのため、プレイヤキャラクタ、またはプレイヤキャラクタに装備するアイテムによって、戦略を考える必要がある。また、対戦相手のキャラクタまたは装備されるアイテムにも同様に特性があり、対戦相手のキャラクタの組み合わせによる相性によっても優劣が生じるため、戦略を考える必要がある。特性とは、例えば、キャラクタの行動に関する能力（攻撃力等）や、行動に影響を与える能力（回復スキル等）である。具体的には、例えば特性としては、「攻撃力が高い」、「回復スキルを持っている」、「投てき武器により高い場所が攻撃可能」、「特定の属性のキャラクタに大ダメージを与えられる」、「移動速度が早い」、「遠方の敵を攻撃可能」、「広範囲にダメージを与えることが可能」等がある。

次に、図１を参照して、ゲーム空間において対戦が行われるフィールドについて説明する。図１は、本実施形態に係るフィールドの一例を示す図である。図示するフィールドＦＬＤでは、青チームと赤チームとの対戦が行われる。フィールドＦＬＤは、両チームに共通の複数の領域として、「スタート部屋」、「通常部屋」、「通路」、及び「ボス部屋」の４種類の「部屋（領域）」を有している。

スタート部屋は、各チームのそれぞれに存在する。図示する例では、スタート部屋ＢＳが青チームのスタート部屋であり、スタート部屋ＲＳが赤チームのスタート部屋である。
対戦プレイの開始時には、各チームのプレイヤキャラクタは、各チームのスタート部屋からスタートする。ＨＰが０となって再スタート（リスポーン）する場合もこのスタート部屋から再開されることとなる。

通常部屋は、各チームが占拠する対象となる部屋である。図示する例では、部屋Ａ、部屋Ｂ、及び部屋Ｃが、対戦プレイの開始時に初期状態として青チームが占拠している部屋である。一方、部屋Ｄ、部屋Ｅ、及び部屋Ｆが、対戦プレイの開始時に初期状態として赤チームが占拠している部屋である。通常部屋には、占拠している側の陣営のＮＰＣ（ノンプレイヤキャラクタ）が存在している。ＮＰＣは、ユーザの操作を必要としないキャラクタであり、コンピュータが実行するゲーム処理によって制御されるキャラクタである。以下では、通常部屋に存在するＮＰＣのことを「通常ＮＰＣ」ともいう。通常ＮＰＣは、青チームと赤チームのうち占拠している方のチームに対応しており、対戦相手のチームのプレイヤキャラクタからの攻撃に対して占拠している側の陣営のキャラクタとして対抗する。例えば、通常部屋において通常ＮＰＣが討伐されると、討伐した側のチームが、この通常部屋を占拠することとなる。一方、通常部屋において通常ＮＰＣの討伐に失敗した場合には、討伐した側のチームによる占拠が失敗に終わり、元々占拠しているチームがそのままこの通常部屋を占拠することとなる。

通路は、占拠の対象とならない部屋であり、別の部屋（ここでは、初期状態で相手チームが占拠している部屋）へ移動するための領域である。

ボス部屋は、ボスキャラクタが出現する部屋であり、占拠の対象となる部屋である。ボスキャラクタは、ＮＰＣであるが、通常ＮＰＣ違って、いずれかの陣営のキャラクタではない。よって、ボス部屋は、対戦プレイの開始時の初期状態では、いずれのチームに占拠されていない状態である。以下では、このボス部屋に存在するＮＰＣのことを「ボスＮＰＣ」ともいう。ボスＮＰＣは、通常ＮＰＣに比べて高い攻撃力や防御力を有し、いずれのチームからも攻撃可能なキャラクタである。例えば、ボスＮＰＣが討伐された時に、より多くのダメージをボスＮＰＣに与えた側のチームがボス部屋を占拠することとなる。

対戦プレイが行われるフィールドには種類があり、フィールドごとに部屋の配置が異なるが、ここでは一例として、対戦するチームそれぞれへの平等性の観点から左右対称等の部屋の配置となっている。図示するフィールドＦＬＤでは、青チームの部屋が左側、赤チームの部屋が右側に配置されており、各部屋が左右対称の関係に配置されている。各部屋は、隣接する部屋との間に扉ＤＲが設けられている。この扉ＤＲを通じて隣接する部屋との往来が可能である。具体的には、青チームのスタート部屋ＢＳからは部屋Ａへ、部屋Ａからは部屋Ｂへ、部屋Ｂからは部屋Ｃとボス部屋へ、部屋Ｃからは通路を介して赤チームの部屋Ｆへ、と扉ＤＲを介して通じている。一方、赤チームのスタート部屋ＲＳからは部屋Ｄへ、部屋Ｄからは部屋Ｅへ、部屋Ｅからは部屋Ｆとボス部屋へ、部屋Ｆからは通路を介して青チームの部屋Ｃへと、と扉ＤＲを介して通じている。両チームのプレイヤキャラクタは、このフィールドＦＬＤ内は共通の領域であり、制限なく往来することができる。なお、スタート部屋のみ対戦相手のチームのプレイヤキャラクタが入れないようにしてもよい。

次に、ゲームの基本的なルールについて説明する。制限時間（例えば３分）内に占拠した部屋の数が多いチームが勝利となる。例えば、各チームの各プレイヤキャラクタが各ユーザの操作に応じてフィールド内を移動して、戦闘を行いながら部屋を占拠していく。制限時間終了時により多くの部屋を占拠しているチームが勝利と判定される。以下に、部屋の占拠について詳しく説明する。

通常部屋では、対戦するチーム（青チーム、赤チーム）によって占拠による部屋の奪い合いが行われる。青チームが占拠している通常部屋には青チーム側の通常ＮＰＣが存在しており、その部屋の中に入ってくる赤チーム側のプレイヤキャラクタに対して攻撃を行う。この通常ＮＰＣは赤チーム側のプレイヤキャラクタによって攻撃可能である。互いの攻撃によって当たり判定が行われ、当たりの度合い（的中度合い、攻撃力など）によって、被攻撃側にダメージが与えられ、被攻撃側のＨＰが減少する。逆に、この通常部屋では、青チーム側のプレイヤキャラクタからは通常ＮＰＣに対して攻撃できず（攻撃しても当たり判定がない）、また通常ＮＰＣは青チーム側のプレイヤキャラクタには攻撃しない。

通常部屋において、通常ＮＰＣの討伐状況が予め設定された所定の占拠条件を満たした場合、攻撃したチームがその通常部屋を占拠することができる。通常ＮＰＣの討伐状況とは、その通常部屋に出現している通常ＮＰＣの数である。所定の占拠条件は、例えば、その部屋に存在する通常ＮＰＣのすべてが討伐される（ＨＰが「０」になる）ことである（即ち、通常ＮＰＣの数が０になること）。赤チーム側のプレイヤキャラクタによってその部屋に存在する通常ＮＰＣのすべてが討伐されると、その部屋は赤チーム側の占拠となる。

通常部屋が赤チームに占拠されると、その部屋には赤チーム側の通常ＮＰＣが出現する。出現した赤チーム側の通常ＮＰＣは、青チーム側のプレイヤキャラクタから攻撃可能となる。この状態では、赤チーム側のプレイヤキャラクタからは通常ＮＰＣに対して攻撃できず（攻撃しても当たり判定がない）、また通常ＮＰＣは赤チーム側のプレイヤキャラクタには攻撃しない。青チーム側のプレイヤキャラクタによってその部屋に存在するすべての通常ＮＰＣが討伐されるとその部屋は再び青チーム側が占拠したことになる。これを繰り返しながら両チームは、通常部屋を占拠しあうこととなる。このように、一つの通常部屋は、いずれかのチームに占拠された状態となっており、同時に両チームの通常ＮＰＣが混在することはない。

なお、通常部屋における上記所定の占拠条件は、その部屋に存在する通常ＮＰＣのすべてが討伐される（ＨＰが「０」になる）ことに限られるものではなく、他の条件としてもよい。例えば、所定の占拠条件は、その部屋に存在する通常ＮＰＣの数が所定数以下（例えば、２体以下）になること、または、その部屋に存在する通常ＮＰＣの討伐した数が所定数以上（例えば、１０体以上）になることとしてもよい。

また、通常部屋で対戦プレイ中のプレイ画面では、プレイ画面の下部が占拠している側のチームの色に変更される。これにより、対戦プレイ中の部屋がどちらのチームに占拠されているのかが視認し易くなる。
図２は、通常部屋におけるプレイ画面の一例を示す図である。図示するプレイ画面Ｇ１０には、通常部屋の中の様子が表示される。プレイ画面Ｇ１０の下側の領域ＦＬは、この部屋の床に相当する領域である。この領域ＦＬが、青チームによって占拠されているときには青色（または青系統の色）となり、赤チームによって占拠されているときには赤色（または赤系統の色）となる。なお、この占拠している側のチームの色に変更される領域は、プレイ画面中の他の領域としてもよい。

また、プレイ画面Ｇ１０の上部にはフィールド内の地図ＭＡが表示される。また、地図ＭＡ内には、この対戦プレイ中の部屋の場所を示す位置マークＰＳが表示される。また、符号ＮＰ１〜３はこの部屋に存在する通常ＮＰＣを示しており、符号Ｐ１は通常ＮＰＣを討伐しようとするプレイヤキャラクタを示している。なお、この図では、プレイヤキャラクタが１体のみであるが、同じチームの他のプレイヤキャラクタや、対戦相手のチームのプレイヤキャラクタ等が複数存在してもよい。

基本的には、プレイヤキャラクタには移動の制限はなく、どこの部屋にも移動することが可能である。部屋はある程度の広さがあり、各ユーザの操作に応じて、各プレイヤキャラクタが部屋の中も自由に移動できる。

ボス部屋では、ボスＮＰＣが出現する。ボスＮＰＣは、いずれの陣営でもない。即ち、ボスＮＰＣは、いずれか一つのチームに対応しているのではなく、いずれのチームに対しても攻撃をし、いずれのチームからも攻撃が可能である。ボスＮＰＣが討伐された時に、より多くのダメージをボスＮＰＣに与えた側のチームがボス部屋を占拠することとなる。ボス部屋では、１回の対戦でボスＮＰＣが１回のみ出現する。このため、ボス部屋は、一方のチームに一度占拠されると、その後他方のチームが占拠し返すことはできず、対戦終了まで占拠したチーム（陣営）が変わることがない。即ち、ボス部屋を占拠するチャンスは、１つのフィールドの対戦中で１回のみとなる。なお、フィールド内に、複数のボス部屋があってもよいが、各ボス部屋での対戦中に１回だけボスが出現することになる。

図３は、ボス部屋におけるプレイ画面の一例を示す図である。図示するプレイ画面Ｇ２０には、ボス部屋の中の様子が表示される。通常部屋のプレイ画面Ｇ１０と違って対戦プレイ中は占拠されていない状態であるため、占拠状況を示す表示（チーム色の表示）は行われない。また、符号ＢＮＰはこの部屋に存在するボスＮＰＣを示しており、符号ＰＢ１、ＰＢ２は、ボスＮＰＣを討伐しようとする青チームのプレイヤキャラクタを示しており、符号ＰＲ１、ＰＲ２は、同じくボスＮＰＣを討伐しようとする赤チームのプレイヤキャラクタを示している。ボスＮＰＣは、通常ＮＰＣに比較して、ＨＰ、攻撃力、防御力などが高く、討伐するためにより多くの攻撃が必要となる。そのため、ボス部屋にボスＮＰＣが出現し対戦が開始されると、ボス部屋を占拠するために各チームのプレイヤキャラクタがボス部屋に集まり、各チームがより多くのダメージをボスＮＰＣに与えられるように協力して攻撃を行うことになる。ボス部屋は、占拠のし返しができないため、ボス部屋を占拠することによって少なくとも１つの部屋の占拠が確定し、通常部屋の占拠以上に対戦の戦況に有利に働く。なお、ボス部屋を占拠することによって、占拠した側のプレイヤキャラクタのパラメータが有利な方向に変更されてもよい（例えば、ＨＰの回復等）。また、ボス部屋の占拠が通常部屋の占拠の所定倍数分に相当するようにしてもよい。

〔システム構成〕
次に、本実施形態に係るゲームシステム１のシステム構成について説明する。図４は、本実施形態に係るゲームシステム１の構成の一例を示すブロック図である。ゲームシステム１は、ゲーム装置１０−１と、ゲーム装置１０−２と、ゲーム装置１０−３、・・・と、ゲームサーバ３０とのコンピュータ装置を備えており、これらのコンピュータ装置はネットワークＮＷを介して接続される。ゲーム装置１０−１と、ゲーム装置１０−２と、ゲーム装置１０−３とは同様の構成であるため、特に区別しない場合には、「−１」、「−２」等の記載を省略してゲーム装置１０として説明する。ここでは３台のゲーム装置１０を図示しているが、任意の台数のゲーム装置１０がゲームサーバ３０に接続されてもよい。

ゲームサーバ３０は、ゲーム装置１０においてプレイ可能なゲームを提供するサーバ装置である。例えば、ゲームサーバ３０は、ゲーム装置１０においてプレイ可能なゲームの制御プログラム（ゲーム制御プログラム）を、ゲーム装置１０からダウンロード可能に提供する。また、ゲームサーバ３０は、ゲーム装置１０においてプレイされるゲームに必要な各種設定情報及び履歴情報などを記憶するとともに、必要に応じてゲーム装置１０に送信する。また、ゲームサーバ３０は、ゲーム装置１０においてプレイされるゲームの処理のうち、サーバ側で実行する必要がある処理を実行する。なお、ゲーム装置１０がダウンロードするゲーム制御プログラムは、ゲームサーバ３０に限らず、他のダウンロード可能なサーバ装置に記憶されていてもよい。また、ゲーム制御プログラムは、ＤＶＤ−ＲＯＭ、ＣＤ−ＲＯＭ、メモリカード等の記憶媒体によってゲーム装置１０に提供されてもよい。

ゲーム装置１０は、ゲームサーバ３０から提供されるゲーム制御プログラムを実行する。例えば、ゲーム装置１０は、ユーザが利用するコンピュータ装置であり、家庭用の据え置き型ゲーム機、携帯型ゲーム機、ゲームセンター等に設置されているアーケードゲーム機、ＰＣ（ＰｅｒｓｏｎａｌＣｏｍｐｕｔｅｒ）、タブレットＰＣ、スマートフォンやフィーチャーフォン等の携帯電話機、携帯情報端末（ＰＤＡ：ＰｅｒｓｏｎａｌＤｉｇｉｔａｌＡｓｓｉｓｔａｎｔ）等が適用できる。本実施形態では、ゲーム装置１０は携帯型ゲーム機であるとして説明する。

ネットワークＮＷは、例えば、インターネットや、携帯電話網、ＰＨＳ（ＰｅｒｓｏｎａｌＨａｎｄｙ−ｐｈｏｎｅＳｙｓｔｅｍ）網、ＶＰＮ（ＶｉｒｔｕａｌＰｒｉｖａｔｅＮｅｔｗｏｒｋ）網、専用通信回線網、ＷＡＮ（ＷｉｄｅＡｒｅａＮｅｔｗｏｒｋ）、ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）、ＰＳＴＮ（ＰｕｂｌｉｃＳｗｉｔｃｈｅｄＴｅｌｅｐｈｏｎｅＮｅｔｗｏｒｋ；公衆交換電話網）など、またはこれらの組み合わせによって構成される通信ネットワークである。

図５は、本実施形態に係るゲーム装置１０のハードウェア構成の一例を示す図である。ゲーム装置１０は、例えば、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）１１と、通信部１２と、入力部１３と、表示部１４と、記憶部１５とを備え、ネットワークＮＷを介して接続されたゲームサーバ３０や他の装置等と通信部１２を介して通信を行う。これらの構成要素は、バス（Ｂｕｓ）を介して相互に通信可能に接続されている。ＣＰＵ１１は、記憶部１５に記憶された各種プログラムを実行し、ゲーム装置１０の各部を制御する。

通信部１２は、ＣＰＵ１１による制御に基づいて、ネットワークＮＷを介してゲームサーバ３０や他の装置等と通信を行う。
入力部１３は、ユーザの操作が入力される複数の操作ボタンを含んで構成されており、入力された操作情報をＣＰＵ１１へ出力する。なお、入力部１３は、ディスプレイと一体に構成されたタッチパネル、複数の操作ボタンが設けられたコントローラ、キーボードやマウス、タッチパッドや、音声により各種の指示が入力されるマイクロホンなど、その他の入力装置であってもよい。
表示部１４は、画像やテキスト等の情報を表示するディスプレイであり、例えば、液晶ディスプレイパネル、有機ＥＬ（ＥｌｅｃｔｒｏＬｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイパネルなどを含んで構成される。例えば、表示部１４には、ゲームのプレイ画像が表示される。

記憶部１５は、例えば、ＨＤＤ（ＨａｒｄＤｉｓｋＤｒｉｖｅ）やＳＳＤ（ＳｏｌｉｄＳｔａｔｅＤｒｉｖｅ）、ＥＥＰＲＯＭ（ＥｌｅｃｔｒｉｃａｌｌｙＥｒａｓａｂｌｅＰｒｏｇｒａｍｍａｂｌｅＲｅａｄ-ＯｎｌｙＭｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ-ＯｎｌｙＭｅｍｏｒｙ）、ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）などを含み、ゲーム装置１０が処理する各種情報や画像、プログラム（ゲーム制御プログラムを含む）等を記憶する。なお、記憶部１５は、ゲーム装置１０に内蔵されるものに限らず、ＵＳＢ等のデジタル入出力ポート等によって接続された外付け型の記憶装置でもよい。また、ゲーム装置１０は、不図示のスピーカ、音声出力端子、カメラ、ジャイロセンサ、ＧＰＳ（ＧｌｏｂａｌＰｏｓｉｔｉｏｎｉｎｇＳｙｓｔｅｍ）受信モジュールなどのハードウェア構成を含んで構成されてもよい。

図６は、本実施形態に係るゲームサーバ３０のハードウェア構成の一例を示す図である。ゲームサーバ３０は、例えば、ＣＰＵ３１と、通信部３２と、入力部３３と、記憶部３５とを備え、ネットワークＮＷを介して接続された複数のゲーム装置１０や他の装置等と通信部３２を介して通信を行う。これらの構成要素は、バス（Ｂｕｓ）を介して相互に通信可能に接続されている。ＣＰＵ３１は、記憶部３５に記憶されたゲーム制御プログラムを実行し、複数のゲーム装置１０でプレイ可能なゲームを提供する。

通信部３２は、ＣＰＵ３１による制御に基づいて、ネットワークＮＷを介して複数のゲーム装置１０や他の装置と通信を行う。
入力部３３は、例えば、キーボードやマウス、タッチパッドや、音声により各種の指示が入力されるマイクロホンなど、その他の入力装置である。

記憶部３５は、例えば、ＨＤＤ、ＥＥＰＲＯＭ、ＲＡＭなどを含み、ゲーム制御プログラム、アプリケーションプログラム、ゲームに必要な各種設定情報及び履歴情報などを記憶する。なお、記憶部３５は、ゲームサーバ３０に内蔵されるものに限らず、ＵＳＢ等のデジタル入出力ポート等によって接続された外付け型の記憶装置でもよい。また、記憶部３５は、ゲームサーバ３０とは物理的に離れた外部の記憶装置であってもよく、ゲームサーバ３０とネットワークＮＷを介して接続されてもよい。また、ゲームサーバ３０は、不図示の表示部、スピーカ、音声出力端子などのハードウェア構成を含んで構成されてもよい。

〔機能構成〕
次に、図７を参照して、ゲームシステム１が備えるゲーム装置１０及びゲームサーバ３０の機能構成について説明する。図７は、本実施形態に係るゲームシステム１が備えるゲーム装置１０及びゲームサーバ３０の構成の一例を示すブロック図である。

〔ゲーム装置１０の機能構成〕
まず、ゲーム装置１０の構成について説明する。
ゲーム装置１０は、記憶部１５に記憶されているゲーム制御プログラムをＣＰＵ１１が実行することにより実現される機能構成として、ゲーム制御部１１０を備えている。ゲーム制御部１１０は、ゲームのプレイ処理を制御する。例えば、ゲーム制御部１１０は、サーバ制御情報取得部１１１と、キャラクタ制御部１１２と、通常ＮＰＣ制御部１１３と、対戦制御部１１４と、表示制御部１１５とを備えている。

サーバ制御情報取得部１１１は、ゲーム処理に関するデータをゲームサーバ３０から通信部１２を介して取得する。例えば、サーバ制御情報取得部１１１は、ユーザが選択可能なプレイヤキャラクタに関するデータ、該プレイヤキャラクタに装備可能に所持しているアイテムに関するデータなどを取得する。また、サーバ制御情報取得部１１１は、ゲームサーバ３０によって実行されたゲーム処理の処理結果に基づくデータ、及び他のゲーム装置１０で実行されたゲーム処理の処理結果に基づくデータをゲームサーバ３０から通信部１２を介して取得する。

キャラクタ制御部１１２は、入力部１３に対するユーザの操作に基づいて、フィールドＦＬＤ内でのプレイヤキャラクタの活動を制御する。活動とは、移動や動きの総称である。動きとは、攻撃、防御、アイテムの取得などに伴う動作（モーション）である。また、キャラクタ制御部１１２は、対戦プレイにおいて、攻撃したり攻撃されたりすることに応じて、ＨＰ及びＭＰの値を変更する。また、キャラクタ制御部１１２は、プレイヤキャラクタの制御情報（位置や動きの情報や、ＨＰ及びＭＰの値など）を、通信部１２を介してゲームサーバ３０へ送信する。

通常ＮＰＣ制御部１１３は、各通常部屋における通常ＮＰＣを制御する。例えば、通常ＮＰＣ制御部１１３は、各通常部屋において、当該部屋を占拠している陣営の通常ＮＰＣ（占拠しているチームに対応する通常ＮＰＣ）を出現させ、対戦相手のチームのプレイヤキャラクタに対する攻撃を行うなど通常ＮＰＣの活動を制御する。

対戦制御部１１４は、対戦プレイにおける対戦のルールの適用、攻撃による当たり判定、当たり判定結果に基づくダメージ量やダメージの種類の決定などを行う。例えば、対戦制御部１１４は、通常ＮＰＣ制御部１１３により制御される通常ＮＰＣと、キャラクタ制御部１１２により制御されるプレイヤキャラクタとの対戦において、対戦のルールの適用、攻撃による当たり判定、当たり判定結果に基づくダメージ量やダメージの種類の決定などを行う。対戦のルールとは、例えば、通常ＮＰＣへの攻撃が、通常ＮＰＣとは異なる陣営（チーム）のプレイヤキャラクタからは可能であるが、同じ陣営（チーム）のプレイヤキャラクタからは出来ないことなどである。なお、対戦制御部１１４は、通常ＮＰＣに対して同じ陣営（チーム）のプレイヤキャラクタからの攻撃を制限してもよいし、攻撃自体は制限せずに当たり判定を行なわないようにしてもよい。

また、対戦制御部１１４は、プレイヤキャラクタから通常ＮＰＣへの攻撃の当たり判定の判定結果またはダメージ量やダメージの種類を示す情報を通信部１２を介してゲームサーバ３０へ送信する。例えば、ゲームサーバ３０は、この当たり判定の判定結果またはダメージ量やダメージの種類を示す情報に基づいて、通常ＮＰＣのＨＰの値を変更する。一方、対戦制御部１１４は、通常ＮＰＣからプレイヤキャラクタへの攻撃の当たり判定の判定結果またはダメージ量やダメージの種類を示す情報を、キャラクタ制御部１１２に出力する。例えば、キャラクタ制御部１１２は、この当たり判定の判定結果またはダメージ量やダメージの種類を示す情報に基づいて、プレイヤキャラクタのＨＰの値を変更する。

また、ボス部屋における対戦プレイでは、対戦制御部１１４は、ゲームサーバ３０により制御されるボスＮＰＣと、キャラクタ制御部１１２により制御されるプレイヤキャラクタとの対戦において、攻撃による当たり判定、当たり判定結果に基づくダメージ量やダメージの種類の決定などを行う。また、対戦制御部１１４は、プレイヤキャラクタからボスＮＰＣへの攻撃の当たり判定の判定結果またはダメージ量やダメージの種類を示す情報を通信部１２を介してゲームサーバ３０へ送信する。例えば、ゲームサーバ３０は、この当たり判定の判定結果またはダメージ量やダメージの種類を示す情報に基づいて、ボスＮＰＣのＨＰの値を変更する。一方、対戦制御部１１４は、ボスＮＰＣからプレイヤキャラクタへの攻撃の当たり判定の判定結果またはダメージ量やダメージの種類を示す情報を、キャラクタ制御部１１２に出力する。例えば、キャラクタ制御部１１２は、この当たり判定の判定結果またはダメージ量やダメージの種類を示す情報に基づいて、プレイヤキャラクタのＨＰの値を変更する。

表示制御部１１５は、ゲーム画面として表示させるゲーム画像を生成して、表示部１４に表示させる。例えば、表示制御部１１５は、キャラクタ制御部１１２による制御結果、及びサーバ制御情報取得部１１１が取得したゲームサーバ３０によって実行されたゲーム処理に基づくデータや他のゲーム装置１０で実行されたゲーム処理に基づくデータに基づいて、フィールド内の各部屋の様子や、各チームのプレイヤキャラクタ、通常ＮＰＣ、ボスＮＰＣ、及び各キャラクタの攻撃に対応するエフェクト（効果）などの表示画像を生成して、表示部１４にプレイ画面として表示させる（例えば、図２及び図３のプレイ画面参照）。

〔ゲームサーバ３０の機能構成〕
次に、ゲームサーバ３０の構成について説明する。
ゲームサーバ３０は、記憶部３５に記憶されているプログラムをＣＰＵ３１が実行することにより実現される機能構成として、サーバ制御部３１０を備えている。例えば、サーバ制御部３１０は、記憶部３５に記憶されているゲームに関するデータ（例えば、キャラクタ及びアイテムに関するデータ）を、通信部３２を介してゲーム装置１０へ送信する。また、サーバ制御部３１０は、各ゲーム装置１０におけるユーザの操作に基づいて制御されるプレイヤキャラクタの制御情報を、通信部３２を介して各ゲーム装置１０から取得する。そして、サーバ制御部３１０は、各ゲーム装置１０から取得した各プレイヤキャラクタの制御情報を、取得したゲーム装置１０以外のゲーム装置１０へ送信する。これにより、共通のフィールド内で複数ユーザが操作するプレイヤキャラクタの画像が、各ゲーム装置１０のプレイ画面に表示可能となる。また、サーバ制御部３１０は、各ゲーム装置１０に対して共通で処理を行うボスＮＰＣの制御や、部屋の占拠判定及びチームの勝利判定などのサーバ装置側で必要な処理を実行する。以下、ゲームサーバ３０の構成について詳しく説明する。

まず、ゲームサーバ３０の記憶部３５に記憶されているデータについて説明する。例えば、記憶部３５は、ユーザデータ記憶部３５１と、チームデータ記憶部３５２と、キャラクタデータ記憶部３５３と、アイテムデータ記憶部３５４と、所持データ記憶部３５５とを備えている。

ユーザデータ記憶部３５１には、ゲームをプレイするユーザ（プレイヤ）に関するユーザデータが記憶される。ユーザデータには、ユーザＩＤ、ユーザ名、レベル、ＨＰ、ＭＰ、プレイヤキャラクタデータ、装備アイテム等が関連付けられている。ユーザＩＤは、ユーザの識別情報である。ユーザ名は、ゲーム内で表示されるユーザの名称である。レベルは、ユーザのプレイによるゲーム進行度合いに応じて増加する値である。ＨＰ及びＭＰには、ユーザが操作するプレイヤキャラクタのＨＰ及びＭＰの値が格納される。プレイヤキャラクタデータには、ユーザが選択したプレイヤキャラクタのキャラクタＩＤと、そのプレイヤキャラクタの攻撃力及び防御力などのキャラクタパラメータが格納される。装備アイテムには、ユーザが設定した装備アイテムを示す情報（例えば、アイテムＩＤ）が関連付けられる。これらのデータは、ゲーム装置１０の記憶部１５にも記憶されている。

チームデータ記憶部３５２には、チームに属するユーザ情報（例えば、ユーザＩＤ）や各チームによる部屋の占拠状況、または勝敗履歴などチームに関するチームデータが記憶される。例えば、チームデータには、チームＩＤ（チームの識別情報）、そのチームのユーザＩＤ、占拠している部屋を示す情報（部屋の識別情報、部屋ＩＤ）、勝敗履歴などが関連付けられている。

キャラクタデータ記憶部３５３には、ユーザがプレイヤキャラクタとして選択可能なキャラクタデータや、通常ＮＰＣ及びボスＮＰＣに関するキャラクタデータが記憶されている。キャラクタデータには、キャラクタＩＤ、キャラクタ名、属性、特性、キャラクタパラメータなどが関連付けられている。キャラクタＩＤは、キャラクタの識別情報である。キャラクタ名は、キャラクタの名称である。属性には、「火」、「水」、「木」、「闇」、「聖」などがあり、各キャラクタにはいずれかの属性が設定されている。「火」、「水」、「木」は、互いに優劣関係にある。例えば、「火」の属性より「水」の属性の方が優位であり、「水」の属性より「木」の属性の方が優位であり、「木」の属性より「火」の属性の方が優位である。なお、「闇」及び「聖」は、特別な能力を有する攻撃や防御を示す情報である。特性は、前述したように各キャラクタ個々の能力の特徴を示すものであり、「攻撃力が高い」、「回復スキルを持っている」、「投てき武器により高い場所が攻撃可能」、「特定の属性のキャラクタに大ダメージを与えられる」、「移動速度が早い」、「遠方の敵を攻撃可能」、「広範囲にダメージを与えることが可能」等である。キャラクタパラメータは、キャラクタの攻撃力及び防御力などである。なお、通常ＮＰＣ及びボスＮＰＣには、各ＮＰＣの能力（攻撃力や防御力など）に対応するレベルが設定されている。

アイテムデータ記憶部３５４には、プレイヤキャラクタに装備可能なアイテムに関するアイテムデータが記憶される。アイテムデータには、アイテムＩＤ、アイテム名、カテゴリ、属性、及びアイテムパラメータが関連付けられている。アイテムＩＤは、アイテムの識別情報である。アイテム名は、アイテムの名称である。カテゴリには、各アイテムのカテゴリ（例えば、「武器」、「防具」、「特殊武器」のいずれか）が格納される。属性には、各アイテムに設定されている属性（「火」、「水」、「木」、「闇」、「聖」のいずれか）が格納される。アイテムパラメータには、各アイテムの攻撃力、防御力、ＨＰ、ＭＰなどの値が設定されており、アイテムを装備することでプレイヤキャラクタの攻撃力、防御力、ＨＰ、ＭＰなどが強化（値が上昇）される。なお、アイテムには、特定のキャラクタにのみ装備可能な専用アイテムがあってもよく、専用アイテムを示す情報もアイテムデータに含まれてもよい。

所持データ記憶部３５５には、ユーザが所持しているアイテムの所持データが記憶される。例えば、所持データには、ユーザが抽選や特定のイベントをクリアすることで取得したアイテムに関するデータ（例えば、アイテムＩＤ）が、ユーザＩＤと関連付けられて格納される。ユーザは、この所持データに格納されているアイテムの中から、プレイヤキャラクタに装備するアイテムを選択することができる。

次に、サーバ制御部３１０の機能構成について説明する。例えば図７に示すように、サーバ制御部３１０は、端末制御情報取得部３１１と、ボスＮＰＣ制御部３１２と、通常ＮＰＣ状態同期部３１３と、プレイヤキャラクタ同期部３１４と、占拠判定部３１５と、勝敗判定部３１６と、報酬付与部３１７とを備えている。

端末制御情報取得部３１１は、各ゲーム装置１０で実行されたゲーム処理に基づく各種情報を、通信部３２を介して各ゲーム装置１０から取得する。例えば、端末制御情報取得部３１１は、プレイヤキャラクタの制御情報（位置などの活動に関する情報や、ＨＰ及びＭＰの値など）を各ゲーム装置１０から取得する。また、端末制御情報取得部３１１は、対戦プレイによる通常ＮＰＣ及びボスＮＰＣの当たり判定の判定結果またはダメージ量やダメージの種類を示す情報を、各ゲーム装置１０から取得する。

ボスＮＰＣ制御部３１２は、ボス部屋におけるボスＮＰＣを制御する。例えば、ボスＮＰＣ制御部３１２は、ボス部屋にボスＮＰＣを出現させ、出現させたボスＮＰＣの移動、各プレイヤキャラクタへの攻撃、及び各プレイヤキャラクタからの攻撃に応じたＨＰの値の変更などを制御する。なお、ボスＮＰＣ制御部３１２は、各ゲーム装置１０から取得する、プレイヤキャラクタからボスＮＰＣへの攻撃の当たり判定の判定結果またはダメージ量やダメージの種類を示す情報に基づいて、ボスＮＰＣのＨＰの値を変更する。ボスＮＰＣのＨＰの値が「０」になると、ボスＮＰＣ制御部３１２は、ボスＮＰＣを消滅（死亡）させる。また、ボスＮＰＣ制御部３１２は、ボスＮＰＣの制御情報（位置や動きの情報や、ＨＰの値など）を、通信部３２を介して各ゲーム装置１０へ送信する。

通常ＮＰＣ状態同期部３１３は、各ゲーム装置１０で制御される通常ＮＰＣの状態が同じになるように同期させる。例えば、通常ＮＰＣ状態同期部３１３は、通常ＮＰＣの出現数及び出現タイミングを制御する。具体的には、通常ＮＰＣ状態同期部３１３は、通常ＮＰＣを出現させる際に、その旨を示す指示情報を各ゲーム装置１０に送信する。各ゲーム装置１０は、その指示情報に応じて通常ＮＰＣを出現させる。これにより、各ゲーム装置１０で出現する通常ＮＰＣのタイミングと数がおおよそ同じとなり、共通性が保たれる。

また、通常ＮＰＣ状態同期部３１３は、各ゲーム装置１０から取得する、プレイヤキャラクタから通常ＮＰＣへの攻撃の当たり判定の判定結果またはダメージ量やダメージの種類を示す情報に基づいて、通常ＮＰＣのＨＰの値を変更する。また、通常ＮＰＣ制御部１１３は、ＨＰの値が「０」になった通常ＮＰＣを消滅（死亡）させる。そして、通常ＮＰＣ状態同期部３１３は、通常ＮＰＣのＨＰの値を示す情報を随時各ゲーム装置１０に送信するとともに、通常ＮＰＣが消滅（死亡）した場合、その旨を示す情報を、各ゲーム装置１０に送信する。各ゲーム装置１０は、これらの情報に基づいて通常ＮＰＣのＨＰの値や状態を制御する。

プレイヤキャラクタ同期部３１４は、各ゲーム装置１０で制御されるプレイヤキャラクタの位置や状態が同じになるように同期させる。例えば、プレイヤキャラクタ同期部３１４は、各ゲーム装置１０から取得するプレイヤキャラクタの位置を示す情報に基づいて、各プレイヤキャラクタが各ゲーム装置１０で同じ位置に表示されるように制御する。具体的には、プレイヤキャラクタ同期部３１４は、各ゲーム装置１０から取得するプレイヤキャラクタの位置を示す情報を各ゲーム装置１０へ送信する。各ゲーム装置１０は、この各ゲーム装置１０における各プレイヤキャラクタの位置を示す情報に基づいてプレイヤキャラクタの位置を制御する。これにより、各ゲーム装置１０の各プレイヤキャラクタが各ゲーム装置１０で同じ位置に表示されるようになる。また、プレイヤキャラクタ同期部３１４は、各ゲーム装置１０から取得するプレイヤキャラクタの状態を示す情報に基づいて、各プレイヤキャラクタのＨＰ残量が同じに表示されるように制御するとともに、消滅（死亡）したプレイヤキャラクタは他のゲーム装置１０でも消滅（死亡）するように制御する。具体的には、プレイヤキャラクタ同期部３１４は、各ゲーム装置１０から取得するプレイヤキャラクタの状態を示す情報を各ゲーム装置１０へ送信する。各ゲーム装置１０は、この各ゲーム装置１０における各プレイヤキャラクタの状態を示す情報に基づいてプレイヤキャラクタの状態を制御する。

占拠判定部３１５は、ユーザの操作結果に基づいて所定の占拠条件を満たしたか否かに基づいて、その通常部屋をいずれのチームの占拠とするか（即ち、いずれのチームに関連付けるか否か）を判定する。例えば、占拠判定部３１５は、通常部屋において通常ＮＰＣの討伐状況が所定の占拠条件を満たした場合、その通常部屋をいずれのチームの占拠とするか（即ち、いずれのチームに関連付けるか否か）を判定する。

例えば、占拠判定部３１５は、青チームに関連付けられた通常部屋において、赤チームのユーザの操作結果（通常ＮＰＣの討伐状況）により所定の占拠条件が満たされた場合、その通常部屋を赤チームの占拠とする。この場合、占拠判定部３１５は、チームデータ記憶部３５２に記憶されているチームデータにおいて、赤チーム（赤チームのチームＩＤ）に、その通常部屋（部屋ＩＤ）を関連付ける。なお、占拠判定部３１５は、チームデータ記憶部３５２に記憶されているチームデータにおいて、赤チームに属するユーザ情報（ユーザＩＤ）に対してその通常部屋（部屋ＩＤ）を関連付けてもよい。

図８は、本実施形態に係る部屋の占拠を判定する占拠判定処理の一例を示すフローチャートである。通常部屋での対戦が開始されると、占拠判定部３１５は、ユーザの操作結果に基づいて所定の占拠条件（例えば、その部屋の通常ＮＰＣが全滅）を満たしたか否かを判定する（ステップＳ１００）。所定の占拠条件が満たされていないと判定された場合（ＮＯ）、占拠判定部３１５は、再びステップＳ１００の処理を実行する。一方、所定の占拠条件が満たされたと判定された場合（ＹＥＳ）、占拠判定部３１５は、所定の占拠条件を満たしたチームによる占拠として、チームデータ記憶部３５２に記憶されているチームデータを更新する（ステップＳ１０２）。

勝敗判定部３１６は、占拠判定部３１５による判定結果に基づいて、複数のチームによる対戦の勝敗を判定する。例えば、勝敗判定部３１６は、占拠判定部３１５による判定結果により、青チームと赤チームのそれぞれが占拠している部屋の数（即ち、青チームと赤チームのそれぞれに関連付けられた部屋の数）に基づいて、青チームと赤チームによる対戦の勝敗を判定する。例えば、勝敗判定部３１６は、占拠している部屋の数が多い方のチームを勝ち（勝利）と判定し、占拠している部屋の数が少ない方のチームを負け（敗北）と判定する。

また、勝敗判定には引き分けが含まれてもよい。例えば、勝敗判定部３１６は、各チームの占拠している部屋の数が同数の場合、引き分けと判定してもよい。また、勝敗判定部３１６は、各チームの占拠している部屋の数が同数の場合、占拠している部屋の種類を考慮に入れて、一方のチームを勝ちと判定し、他方のチームを負けと判定してもよい。例えば、勝敗判定部３１６は、ボス部屋を占拠したチームを勝ちと判定してもよいし、通常部屋の占拠よりもボス部屋の占拠の方が勝利に寄与する割合を高くしてもよい。

図９は、本実施形態に係る勝敗判定処理の一例を示すフローチャートである。対戦プレイが開始されると、勝敗判定部３１６は、計時を開始する（ステップＳ１1０）。計時はカウントアップでもカウントダウンでもよい。次に、勝敗判定部３１６は、計時した時間に基づいて制限時間が終了したか否かを判定する（ステップＳ１１２）。制限時間が終了していないと判定された場合（ＮＯ）、勝敗判定部３１６は、再びステップＳ１１０の処理を実行する。一方、制限時間が終了したと判定された場合（ＹＥＳ）、勝敗判定部３１６は、各チームのそれぞれが占拠している部屋の数に基づいて勝敗を判定する（ステップＳ１１４）。

なお、勝敗判定部３１６は、占拠判定部３１５による判定結果に加えて、報酬付与部３１７により各チームまたは該チームに属するユーザ情報により識別されるユーザに対して付与されたポイントを考慮して勝敗を判定してもよい。例えば、勝敗判定部３１６は、各チームの占拠している部屋の数が同数の場合、各チームに付与されたポイントに基づいて勝敗を判定してもよい。

図１０は、部屋の占拠だけでなくポイントも考慮した勝敗判定処理の一例を示すフローチャートである。対戦プレイが開始されると、勝敗判定部３１６は、計時を開始する（ステップＳ１２０）。計時はカウントアップでもカウントダウンでもよい。次に、勝敗判定部３１６は、計時した時間に基づいて制限時間が終了したか否かを判定する（ステップＳ１２２）。制限時間が終了していないと判定された場合（ＮＯ）、勝敗判定部３１６は、再びステップＳ１２０の処理を実行する。一方、制限時間が終了したと判定された場合（ＹＥＳ）、勝敗判定部３１６は、各チームのそれぞれが占拠している部屋の数と付与されたポイントとに基づいて勝敗を判定する（ステップＳ１２４）。

なお、勝敗判定部３１６は、各チームの占拠している部屋の数が同数の場合のみポイントも考慮した勝敗判定を行なってもよいし、各チームの占拠している部屋の数が異なる場合もポイントも考慮した勝敗判定を行なってもよい。

（ポイントの付与）
次に、ポイントの付与について説明する。報酬付与部３１７は、「部屋占拠」、「ＮＰＣの討伐」、「アシスト」などによって、チームまたはそのチームのユーザに対してポイントを付与する。以下、順に説明する。

・「部屋占拠」によるポイント付与
報酬付与部３１７は、部屋を占拠したチーム（またはそのチームのユーザ）に対してポイントを付与する。つまり、対戦相手チームが占拠している通常部屋に存在している通常ＮＰＣがすべて討伐され、その部屋に通常ＮＰＣが存在しない状態となると、該討伐した側のチームの占拠となり、そのチームにポイント（例えば、３０００ポイントなど）が付与される。具体的には、報酬付与部３１７は、チームデータ記憶部３５２に記憶されているチームデータにおいて、占拠判定部３１５により部屋（部屋ＩＤ）に関連付けられたチーム（チームＩＤ）またはそのチームに属するユーザ情報（ユーザＩＤ）に、部屋の占拠に応じて付与するポイントを関連付ける。例えばこのポイントは、付与される度に加算されていく。

なお、部屋によって付与されるポイントが異なってもよい。例えば、報酬付与部３１７は、部屋を占拠したチームに対して、その部屋に応じたポイントを付与してもよい。例えば、部屋にはレベル（部屋レベル）が設定されており、報酬付与部３１７は、部屋を占拠したチームに対して、占拠した部屋の部屋レベルに応じたポイントを付与してもよい。

例えば、部屋レベルは、占拠される度にレベルが一つ上がる。レベルが上がると出現する通常ＮＰＣのレベルも上がり、占拠の難易度が高くなる。また、部屋レベルが上がると、出現する通常ＮＰＣが別の種類の高いレベルを有する通常ＮＰＣになってもよい。例えば、報酬付与部３１７は、部屋レベルが高いほど占拠された時に付与するポイントを高くする。即ち、報酬付与部３１７は、同一の部屋において所定の占拠条件が満たされる度に、付与するポイントを増加させてもよい。なお、部屋毎にポイントの初期値（例えば、部屋レベルがレベル１の時に占拠された場合の付与ポイント）が設定されている。

図１１は、部屋占拠時に付与されるポイントの一例を示す図である。この図では、通常部屋Ａ（部屋Ａ）と通常部屋Ｂ（部屋Ｂ）について、各部屋レベルと占拠時のポイントとの関係を示している。図示する例では、通常部屋Ａは、部屋レベルがレベル１（Ｌｖ１）、レベル２（Ｌｖ２）、レベル３（Ｌｖ３）、レベル４（Ｌｖ４）、レベル５（Ｌｖ５）のそれぞれの場合について、占拠時のポイントが２０００ｐｔ（ｐｏｉｎｔ）、３０００ｐｔ、４５００ｐｔ、６０００ｐｔ、７５００ｐｔに設定されている。通常部屋Ｂは、部屋レベルがレベル１（Ｌｖ１）、レベル２（Ｌｖ２）、レベル３（Ｌｖ３）、レベル４（Ｌｖ４）、レベル５（Ｌｖ５）のそれぞれの場合について、占拠時のポイントが３０００ｐｔ、４５００ｐｔ、６０００ｐｔ、７５００ｐｔ、９０００ｐｔに設定されている。

また、報酬付与部３１７は、チームが占拠している部屋が多いほど、そのチームに付与するポイントを増加させてもよい。例えば、報酬付与部３１７は、部屋が占拠された時点において、その部屋を占拠したチームが他に占拠している部屋の数に応じてボーナスポイントを付与してもよい。例えば、占拠済みの部屋数に応じたボーナス係数が設定されており、そのボーナス係数に応じたボーナスポイントが付与される。

図１２は、占拠済みの部屋数とボーナス係数の設定の一例を示す図である。図示する例では、占拠済みの部屋数（占拠済部屋数）が０、１、２、３、４、５のそれぞれの場合について、ボーナス係数が１．００倍、１．０５倍、１．１０倍、１．１５倍、１．２０倍、１．２５倍に設定されている。例えば、占拠済みの部屋数に応じて、図１１に示すポイントにボーナス係数を乗じたポイントが付与される。即ち、報酬付与部３１７は、占拠した時点で同じチームの占拠済みの部屋の数が多いほど高いポイントを付与する。

このようにすることで、同じ時間帯に同じチームのユーザが一気に攻めることでより多くのポイントを得ることができるため、時間帯による戦略性をユーザに考えさせることができる。

なお、部屋に応じたポイントとは、部屋レベル（占拠の難易度）に応じたポイントに限られるものではなく、例えば、部屋の大きさ（広さ）などに応じたポイントであってもよい。例えば、報酬付与部３１７は、占拠した部屋が大きい（広い）ほど付与するポイントを高くしてもよい。

・「ＮＰＣの討伐」によるポイント付与
報酬付与部３１７は、討伐（ＨＰを０にする）した対戦相手チームの通常ＮＰＣの種類に応じてポイントを付与する。複数のユーザの操作に基づいて討伐した場合には、討伐時に与えたダメージに応じた割合でポイントが割り振られる。例えば、通常ＮＰＣにはレベルが設定されており、レベルに応じたポイントが設定されている。
また、ボスＮＰＣにもレベルが設定されており、ボスＮＰＣを討伐すると次回の出現時には討伐したボスＮＰＣよりレベルの高いボスＮＰＣが出現する。レベルが高いボスＮＰＣほど討伐時に付与されるポイントが高くなる。ボスＮＰＣの討伐により付与されるポイントは、通常ＮＰＣの討伐により付与されるポイントに比較して高いため、ボス出現中は両方のチームがボス部屋に集まって討伐することになる。ボスＮＰＣは通常ＮＰＣとは異なり両方のチームから攻撃可能なため、両方のチームでダメージを与えた場合には、討伐時にダメージ量に応じて各チームにポイントが割り振られる。

・「アシスト」によるポイント付与
報酬付与部３１７は、同じチームのユーザが操作するプレイヤキャラクタの攻撃力をアップ（バフ）、または対戦相手チームの通常ＮＰＣの防御力をダウン（デバフ）させることにより、予め設定されたポイント（例えば、５０ポイントなど）を付与する。

（部屋占拠時ボーナス）
報酬付与部３１７は、部屋が占拠されると、占拠したチームに対してボーナスとして有利な効果が発生（例えば、ランダムに発生）させてもよい。例えば、報酬付与部３１７は、通常部屋に存在する最後の通常ＮＰＣが討伐されると、上記の有利な効果を発生させる。有利な効果とは、例えば、占拠した部屋に強力な仲間の通常ＮＰＣが出現する、占拠した部屋に出現する仲間の通常ＮＰＣの数が増える、自チームの全プレイヤキャラクタの攻撃力がアップ（バフ）する、などである。このように、報酬付与部３１７は、チームが占拠した部屋では、そのチームのユーザに対して該ユーザの操作に基づくプレイの進行に有利な効果を発生させてもよい。

〔第１の実施形態のまとめ〕
以上説明してきたように、本実施形態に係るゲームシステム１は、キャラクタ制御部１１２（キャラクタ移動部の一例）と、占拠判定部３１５（領域判定部の一例）と、勝敗判定部３１６とを備えている。キャラクタ制御部１１２は、複数のチームのそれぞれに属するユーザ情報（例えば、ユーザＩＤ）により識別されるユーザ毎の操作に基づいて、複数のチームに共通の複数の部屋（領域の一例）を有するフィールド内でユーザ情報毎に関連付けられたプレイヤキャラクタ（キャラクタの一例）を移動させる。占拠判定部３１５は、ユーザの操作結果が所定の占拠条件（所定の条件の一例）を満たしたか否かに基づいて、部屋（領域の一例）をいずれのチームに関連付けるか否か（例えば、いずれのチームの占拠とするか）を判定する。勝敗判定部３１６は、占拠判定部３１５による判定結果に基づいて、複数のチームによる対戦の勝敗を判定する。

これにより、ゲームシステム１は、各ユーザが操作することによりフィールド内でプレイヤキャラクタを移動させるチーム対戦型のアクションゲームにおいて、部屋（領域の一例）を占拠しあうことで勝敗を決するという新たな楽しみを提供することができる。例えば、従来のチーム対戦型のアクションゲームでは、どちらのチームがより多くの対戦相手（敵）のキャラクタを討伐するか、或いは最終的な目的地にどちらのチームが先に到達するかなどによって勝敗が決するといったものが多かったため、ゲームの進行途中でどちらのチームが優勢であるかがリアルタイムで分かり難いことがあったが、本実施形態では、常に部屋の占拠数でどちらのチームが優勢であるかが分かるため、緊張感が途切れることなくユーザにプレイさせることができる。また、１体１の対戦で領域を取り合うゲームと比較した場合、本実施形態ではチーム対戦であることから、チームとしての協力プレイや、敵味方の両方に複数のプレイヤキャラクタが登場することなどから、より戦略性の高いゲームを提供することができる。

例えば、ゲームシステム１は、部屋（領域の一例）においてＮＰＣ（通常ＮＰＣまたはボスＮＰＣ）を制御する通常ＮＰＣ制御部１１３またはボスＮＰＣ制御部３１２（ＮＰＣ制御部の一例）を備えている。そして、占拠判定部３１５（領域判定部の一例）は、部屋においてＮＰＣ（通常ＮＰＣまたはボスＮＰＣ）の討伐状況が所定の占拠条件を満たした場合、部屋をいずれのチームに関連付けるか否かを判定する。

これにより、ゲームシステム１は、フィールド内の複数の部屋のそれぞれに出現する通常ＮＰＣまたはボスＮＰＣを討伐することで、それぞれの部屋を占拠することができるため、各チームの対戦相手を同じ条件とすることができ、公平性を保つことができる。

例えば、通常ＮＰＣの討伐状況は、通常部屋（領域の一例）において出現している通常ＮＰＣの数である。所定の占拠条件は、例えば、その部屋に存在する通常ＮＰＣのすべてが討伐される（ＨＰが「０」になる）ことである（即ち、通常ＮＰＣの数が０になること）。なお、通常部屋における上記所定の占拠条件は、その部屋に存在する通常ＮＰＣのすべてが討伐される（ＨＰが「０」になる）ことに限られるものではなく、他の条件としてもよい。例えば、所定の占拠条件は、その部屋に存在する通常ＮＰＣの数が所定数以下（例えば、２体以下）になること、または、その部屋に存在する通常ＮＰＣの討伐した数が所定数以上（例えば、１０体以上）になることとしてもよい。また、ボス部屋の場合、上記所定の占拠条件は、ボスＮＰＣが討伐される（ＨＰが「０」になる）こととなる。

これにより、ゲームシステム１は、通常部屋に出現している通常ＮＰＣの数が所定の占拠条件を満たすことで（例えば、通常ＮＰＣの数が０になることで）、その通常部屋を占拠することができるため、占拠条件が分かりやすい。また、チームメンバーと協力することで早く占拠できるため、ユーザがチームで戦っている一体感を得ることができる。

例えば、通常部屋（領域の一例）における通常ＮＰＣ（ＮＰＣの一例）は、複数のチームのうちのいずれか一つのチームに対応している。これにより、ゲームシステム１は、対戦相手がＮＰＣでありながら、対戦相手のチームと戦っているのと同様の状況とすることができ、ユーザがチーム対戦であることを実感しながらプレイ可能とすることができる。

なお、ＮＰＣとの対戦に代えて、それぞれの部屋で、チーム同士のプレイヤキャラクタの対戦が行われるようにしてもよい。例えば、対戦相手のチームのプレイヤキャラクタを討伐することによって占拠できるようにしてもよい。

また、勝敗判定部３１６は、占拠判定部３１５（領域判定部の一例）による判定結果により複数のチームのそれぞれに関連付けられた部屋（領域の一例）の数に基づいて、複数のチームによる対戦の勝敗を判定する。これにより、ゲームシステム１は、部屋の占拠数でチームの勝敗が決するため、ユーザにとって対戦中の状況も対戦が終了したときの結果も分かりやすい。また、ゲームシステム１は、対戦するフィールド内に占拠すべき部屋が複数あるため、どの部屋を占拠すべきか等戦略の幅を広げることができる。

また、ゲームシステム１は、占拠判定部３１５（領域判定部の一例）により部屋（領域の一例）が関連付けられたチームまたは該チームに属するユーザ情報により識別されるユーザに対してポイントを付与する報酬付与部３１７を備えている。これにより、ゲームシステム１は、部屋を占拠したチームまたはチームのユーザに対してポイントを付与するため、占拠状況だけでない楽しみを付加することができる。例えば、ゲームシステム１は、ユーザ毎にポイントを付与する場合、チーム同士の対戦に加えて、チーム内のユーザ同士でも競い合える楽しみをユーザに与えることができる。

例えば、報酬付与部３１７は、占拠判定部３１５（領域判定部の一例）により部屋（領域の一例）が関連付けられたチームまたは該チームに属するユーザ情報により識別されるユーザに対して、部屋に応じたポイントを付与する。例えば、報酬付与部３１７は、部屋レベルに応じたポイントを付与する。

これにより、ゲームシステム１は、占拠した部屋（例えば、部屋レベル）によって付与されるポイントが異なるため、例えば、難易度の低い部屋を数多く占拠しようと試みるか、或いは、難易度の高い部屋を数は少なくとも占拠しようとするかといったことをチームの戦略として選択可能となるため、戦略性の高いゲームを提供できる。

また、占拠判定部３１５（領域判定部の一例）は、複数のチームのいずれかのチームに関連付けられた部屋（領域の一例）において他のチームに属するユーザ情報により識別されるユーザの操作結果により所定の占拠条件が満たされた場合、該部屋を該他のチームまたは該他のチームに属するユーザ情報に対して関連付ける。そして、報酬付与部３１７は、同一の部屋において所定の占拠条件が満たされる度に、付与するポイントを増加させる。即ち、報酬付与部３１７は、同一の部屋において所定の占拠条件が満たされる度に、付与する報酬の価値を高くする。報酬の価値とは、例えば、報酬の量（例えば、ポイントの量）である。なお、報酬の価値は、勝敗判定に影響する度合い（例えば、ポイントの高低や、ポイントが勝敗に影響する度合い等）であってもよい。また、報酬の価値は、自チームの攻撃力がアップする量や、対戦相手チームの防御力がダウンする量といった対戦における有利さの度合いであってもよい。

これにより、ゲームシステム１は、同一の部屋をチーム同士で占拠しあうことで占拠したときに付与されるポイントが高くなるため、各チームのユーザに対して繰り返し対戦する意欲を高めることができ、白熱したゲーム展開が期待できる。

報酬付与部３１７は、占拠判定部３１５（領域判定部の一例）によりチームに関連付けられた部屋（領域の一例）が多いほど、該チームに領域が関連付けられた際に付与するポイントを増加させる。これにより、ゲームシステム１は、部屋を占拠すればする程、優位にゲームを進められるようにすることができる。

なお、勝敗判定部３１６は、占拠判定部３１５（領域判定部の一例）による複数の部屋（領域の一例）のそれぞれに対する判定結果と、報酬付与部３１７により各チームまたは該チームに属するユーザ情報により識別されるユーザに対して付与されたポイントとに基づいて、複数のチームによる対戦の勝敗を判定する。これにより、ゲームシステム１は、部屋の占拠だけでなくポイントの取得も勝敗に影響することから、どの領域を占拠するかによって勝敗が左右されるため、戦略性の高いゲームを提供できる。

なお、報酬付与部３１７は、ポイントの付与に限らず、アイテム、仮想通貨などを報酬として付与してもよい。

また、報酬付与部３１７は、占拠判定部３１５（領域判定部の一例）によりチームに関連付けられた部屋（領域の一例）において、該チームに属するユーザ情報により識別されるユーザに対して該ユーザの操作に基づくプレイの進行に有利な効果を発生させてもよい。有利な効果とは、例えば、占拠した部屋に強力な仲間の通常ＮＰＣが出現する、占拠した部屋に出現する仲間の通常ＮＰＣの数が増える、自チームの全プレイヤキャラクタの攻撃力がアップ（バフ）する、などである。これにより、ゲームシステム１は、部屋を占拠すればする程、優位にゲームを進められるようにすることができる。

上記プレイヤキャラクタ（キャラクタの一例）のそれぞれには、ユーザの操作に基づくプレイの進行に影響する特性が設定されている。これにより、ゲームシステム１は、プレイヤキャラクタの特性によって攻撃の種類や威力が変わるとともに、対戦相手の特性との組み合わせによる相性によっても優劣が生じるため、戦略性の高いゲームを提供できる。

［第２の実施形態］
次に、本発明の第２の実施形態について説明する。本実施形態に係るゲームシステム１の基本的な構成は、第１の実施形態と同様であるので、本実施形態において特徴的な処理について説明する。本実施形態では、通常部屋に出現する通常ＮＰＣの出現方法の一例について説明する。通常部屋に存在する通常ＮＰＣの種類や初期数は部屋毎に設定されている。プレイヤキャラクタが通常ＮＰＣを倒しても所定時間（例えば１０秒）経過するごとに１体ずつ復活（出現）する。通常ＮＰＣは、初期数になるまで復活する。つまり、通常部屋毎に設定された初期数が、その部屋に存在する通常ＮＰＣの上限数となる。即ち、通常ＮＰＣ制御部１１３は、通常部屋に所定の時間間隔で通常ＮＰＣを出現させる。また、通常ＮＰＣ制御部１１３は、通常部屋において、同時に出現中となる通常ＮＰＣが予め設定された上限数となるまでは、所定の時間間隔で出現させる。

このように、通常ＮＰＣは討伐されても復活してくるため、一人で通常ＮＰＣを倒すよりはチームで協力して一つの部屋を一気に攻めて討伐した方が効率的に部屋を占拠できることになる。通常ＮＰＣの復活の時間は、部屋毎、かつ部屋レベル毎に決められており、部屋レベルが高いほど復活までの時間も短くなり、占拠の難易度が上がる。

図１３は、通常ＮＰＣの出現方法の設定例を示す図である。図示する例は、通常部屋Ａ（部屋Ａ）及び通常部屋Ｂ（部屋Ｂ）について、出現する通常ＮＰＣ（出現ＮＰＣ）と、初期数と、復活する際の出現時間（時間間隔）とが、部屋レベルごとに設定されている。通常部屋Ａでは、出現する通常ＮＰＣがキャラクタＡであり、部屋レベルが高い程、初期数が多くなり、復活する際の出現時間（時間間隔）が短くなるため、占拠の難易度が上がる。

一方、通常部屋Ｂでは、レベル１（Ｌｖ１）からレベル３（Ｌｖ３）までは出現する通常ＮＰＣがキャラクタＢであるが、レベル４（Ｌｖ４）及びレベル５（Ｌｖ５）では、出現する通常ＮＰＣにキャラクタＣが追加される。このように、通常ＮＰＣは一つの部屋に複数の種類が存在してもよい。その場合、通常ＮＰＣの種類毎に初期数及び復活する際の出現時間（時間間隔）が設定されてもよい。この通常部屋Ｂでは、キャラクタＢ及びキャラクタＣのそれぞれについて、初期数及び復活する際の出現時間（時間間隔）が設定されており、部屋レベルが高い程、それぞれの初期数が多くなり、それぞれの復活する際の出現時間（時間間隔）は短くなる。このように、通常部屋Ｂも部屋レベルが高い程、占拠の難易度が上がる。

〔第２の実施形態のまとめ〕
以上説明したように、本実施形態に係るゲームシステム１において、キャラクタ制御部１１２（キャラクタ移動部の一例）は、チームに属するユーザ情報により識別されるユーザ毎の操作に基づいて、そのチーム内で共通の領域を有するフィールド（ＦＬＤ）内でユーザ情報毎に関連付けられたキャラクタを移動させる。通常ＮＰＣ制御部１１３（ＮＰＣ制御部の一例）は、通常部屋（領域の一例）に所定の時間間隔で通常ＮＰＣ（ＮＰＣの一例）を出現させる。また、占拠判定部３１５（領域判定部の一例）は、通常部屋において通常ＮＰＣの討伐状況が所定の条件を満たした場合、その通常部屋をチームに関連付けるか否かを判定する。勝敗判定部３１６は、占拠判定部３１５によりチームに関連付けられた通常部屋に基づいて、チームの勝敗を判定する。

これにより、ゲームシステム１は、通常ＮＰＣが討伐されても所定の時間間隔で復活するため、通常部屋の占拠が一人では簡単にはできないようにし、チームでより協力したプレイを必要にすることができる。よって、ゲームシステム１は、チーム戦の意識の高いゲームを提供できる。

これにより、ゲームシステム１は、通常部屋に所定の時間間隔で出現する通常ＮＰＣの数が所定の占拠条件を満たすことで（例えば、通常ＮＰＣの数が０になることで）、その通常部屋を占拠することができるため、占拠条件が分かりやすい。また、チームメンバーと協力することで早く占拠できるため、ユーザがチームで戦っている一体感を得ることができる。

通常ＮＰＣ制御部１１３は、通常部屋（領域の一例）において、同時に出現中となる通常ＮＰＣ（ＮＰＣの一例）が予め設定された上限数となるまでは、所定の時間間隔で出現させる。予め設定された上限数とは、例えば、通常部屋に最初に存在する（出現する）通常ＮＰＣの初期数である。これにより、ゲームシステム１は、通常部屋に最初に存在する（出現する）通常ＮＰＣの初期数までは討伐されても復活してくるため、通常部屋の占拠が一人では簡単にはできないようにし、チームで協力したプレイを必要にすることができる。よって、ゲームシステム１は、チーム戦の意識の高いゲームを提供できる。

通常ＮＰＣ制御部１１３は、フィールド内に通常部屋（領域の一例）が複数ある場合、複数の通常部屋毎に、通常ＮＰＣ（ＮＰＣの一例）を出現させる時間間隔、または同時に出現中となる通常ＮＰＣの上限数を制御する。これにより、ゲームシステム１は、部屋毎に占拠の難易度を設定することができる。

通常ＮＰＣ制御部１１３は、同一の通常部屋（領域の一例）において所定の占拠条件（所定の条件の一例）が満たされる度に、該通常部屋において通常ＮＰＣ（ＮＰＣの一例）を出現させる時間間隔を減少、または通常ＮＰＣを同時に出現可能な上限数を増加させる。これにより、ゲームシステム１は、同一の部屋をチーム同士で占拠しあうことでその部屋を占拠する難易度が高くなるため、よりチームで協力したプレイが必要となり、白熱したゲーム展開が期待できる。

なお、本実施形態では、通常部屋に最初に初期数の通常ＮＰＣが存在し、通常ＮＰＣが討伐されても初期数までは所定の時間間隔で復活可能な例を説明したが、通常部屋には最初に通常ＮＰＣが存在せず、所定の時間間隔で予め設定された上限数まで出現または復活するようにしてもよい。

［第３の実施形態］
次に、本発明の第３の実施形態について説明する。本実施形態に係るゲームシステム１の基本的な構成は、第１の実施形態と同様であるので、本実施形態において特徴的な処理について説明する。本実施形態では、複数のゲーム装置１０で多人数対戦を行うオンラインゲームで発生し得るタイムラグによる影響を抑制する処理について説明する。従来から、オンラインのアクションゲームなどリアルタイム性のあるゲームでは、プレイヤキャラクタやＮＰＣに関する管理（ＨＰの値やマップ上の位置、攻撃の発動状態等）はサーバ（あるいはサーバと同等機能を有するホスト端末）によって一元管理されるのが一般的である。各端末からの操作情報がサーバに集約され処理結果が、各端末に返され、それに基づいて各端末は描画等の処理を行う。

ここで、同じＮＰＣに対してほぼ同時刻に別々の端末から討伐可能な攻撃力で攻撃した場合、攻撃した端末のいずれからも攻撃したように見えるが、結果としてはいずれか一つの端末でしか討伐したことにならない。討伐できなかった端末のユーザは、攻撃したはずなのに討伐できなかったという祖語が起こり得る。端末から攻撃した情報を送り、サーバで処理し、処理結果を再び端末へ送信する間のタイムラグが通信によって起こるためである。特にモバイル端末のような必ずしも安定した通信環境が確保できないような端末である場合や、サーバが国外にあるなど物理的に遠方にあるような場合には、このような問題が顕著になることがある。

そこで第１の実施形態で説明したように、ゲームシステム１では、通常ＮＰＣには陣営（チーム）の設定があり、いずれかのチームからしか攻撃することができない仕様となっている。例えば、青チームのユーザが操作するゲーム装置１０の対戦制御部１１４は、青チームのユーザの操作に基づいて、青チームから赤チーム陣営の通常ＮＰＣへの攻撃を制御するとともに、青チームから青チーム陣営の通常ＮＰＣへの攻撃を制限する。一方、赤チームのユーザが操作するゲーム装置１０の対戦制御部１１４は、赤チームのユーザの操作に基づいて、赤チームから青チーム陣営の通常ＮＰＣへの攻撃を制御するとともに、赤チームから赤チーム陣営の通常ＮＰＣへの攻撃を制限する。ここで、攻撃の制限とは、例えば、攻撃できないこと、または攻撃しても当たり判定がないことなどである。

これにより、攻撃したはずなのに討伐できなかったという祖語を緩和することができる。例えば、通常ＮＰＣは青チーム及び赤チームの双方から攻撃されることがないため、チーム間での上記のような祖語は起こらないことになる。ただし、チーム内のプレイヤキャラクタ同士では上記のような祖語は起こり得ることになるが、チーム対戦型のゲームであるため、対戦相手同士で起こるより影響は少ない。

また、ボスＮＰＣは、両陣営双方（例えば、青チーム及び赤チームの双方）から攻撃可能であるため、攻撃したはずなのに討伐できなかったという祖語が起こり得ることになる。しかしながら、そもそもボスＮＰＣは、通常ＮＰＣに比較して、ＨＰ、攻撃力、防御力などが高く設定されており、両チームからの多人数の攻撃によって討伐されるものである。そのため、討伐時（最後のとどめ）の攻撃に祖語は起こり得るものの、それまでの両チームからの攻撃に関してはその順番が入れ替わる可能性はあるが、大きな祖語とはなり得ない。また、従来のゲームでは、ボスＮＰＣの討伐（最後のとどめ）によってボーナスポイントが付与されるという仕様もあるが、このようなボーナスポイントを本実施形態では付与しないことにより、上記の祖語によるゲームの勝敗への影響を最小限にすることができる。

また、ゲームシステム１では、対戦相手となるプレイヤキャラクタ同士の攻撃に関しても攻撃を制限している。例えば、対戦制御部１１４は、プレイヤキャラクタから通常ＮＰＣへの攻撃によってその通常ＮＰＣへ与えるダメージに比較して、該プレイヤキャラクタから他のチームのプレイヤキャラクタへの攻撃によって該他のチームのプレイヤキャラクタへ与えるダメージが小さくなるように制限する。つまり、プレイヤキャラクタ同士で直接攻撃等の対戦を行うことによるメリットを少なくし、プレイヤキャラクタ同士での対戦の動機となる要因を減らしている。具体的には、対戦相手のプレイヤキャラクタに対しては一応は攻撃が可能であるが、その場合のダメージが通常ＮＰＣの場合のダメージより小さい値、例えば最小値（例えば、１ポイント）に制限される。なお、対戦相手のプレイヤキャラタに対する攻撃によるダメージは、「０」（ダメージなし）であってもよい。

なお、対戦制御部１１４は、プレイヤキャラクタから対戦相手のプレイヤキャラクタへの攻撃によって、その対戦相手のプレイヤキャラクタの活動を制限させてもよい。活動の制限とは、例えば、特定の行動（移動、攻撃等）を不可とすること、特定の動作の速度を制限すること（例えば、移動速度を遅くすること）、特定の攻撃を制限すること（例えば、攻撃力を低下させること）、または活動に範囲を制限すること（移動可能範囲が狭くなること）などである。例えば、対戦制御部１１４は、プレイヤキャラクタから対戦相手のプレイヤキャラクタへの攻撃によって、その対戦相手のプレイヤキャラクタへダメージ（例えば、最小値）を与えることに加えて、または代えて、一定時間（例えば２秒）その対戦相手のプレイヤキャラクタの動きを止めてもよい。これにより、対戦相手のプレイヤキャラクタを攻撃する場合、ダメージを与えるより動きを止めることが目的となる。

以下に、通常ＮＰＣとボスＮＰＣとの処理の違いについて整理する。通常ＮＰＣは一方のチームのプレイヤキャラクタからしか攻撃できないのに対して、ボスＮＰＣはいずれのチームのプレイヤキャラクタから攻撃が可能となっている。そのため、両者の処理は、位置、動き、状態などについて、各ゲーム装置１０で同じになるように制御する同期処理となるか、或いはゲーム装置１０毎に制御する非同期処理となるかが異なる。

図１４は、通常ＮＰＣとボスＮＰＣとの処理の違いを示す図である。通常ＮＰＣの処理では、通常ＮＰＣのフィールド内の位置、通常ＮＰＣの動き（モーション）、攻撃によるエフェクトの表示、及び攻撃による当たり判定についての処理が非同期処理（即ち、ゲーム装置１０毎の制御）となり、ダメージによって変化するＨＰ残量や、消滅（死亡）などの状態異常についての処理が、各ゲーム装置１０で同じになるように同期処理となる。一方、ボスＮＰＣの処理では、ボスＮＰＣのフィールド内の位置、ボスＮＰＣの動き（モーション）、攻撃によるエフェクトの表示、ダメージによって変化するＨＰ残量、及び消滅（死亡）などの状態異常についての処理が同期処理となり、攻撃による当たり判定が非同期処理となる。なお、プレイヤキャラクタの位置については、同期処理となる。同期処理となる部分は、ゲームサーバ３０で管理され、非同期処理となる部分は、ゲーム装置１０で管理される。

つまり、通常ＮＰＣのフィールド内の位置や動き（モーション）、攻撃（技）を発動した場合の効果（エフェクト）など基本的にはリアルタイム性の高いアクションは各ゲーム装置１０（端末側）で管理し、討伐した情報やダメージ量に関する情報のみをゲームサーバ３０（サーバ側）で管理している。よって、通常ＮＰＣは、部屋の中の位置がゲーム装置１０毎に異なることも有り得る。これに対しボスＮＰＣのフィールド内の位置等はゲームサーバ３０（サーバ側）で管理されている。そのため、ボスＮＰＣの位置は、各ゲーム装置１０でタイムラグはあるものの基本的には違いがない。

例えば、仮にボスＮＰＣのフィールド内の位置を非同期としてしまうと、同じボスＮＰＣと対戦する各チームのプレイヤキャラクタとの位置関係の祖語が顕著になる。例えば、対戦相手のプレイヤキャラクタを攻撃して動きを封じて足止めをし、ボスＮＰＣに近づけないようにしていたつもりが、対戦相手のプレイヤキャラクタのゲーム装置１０ではボスＮＰＣが近い位置にいて攻撃可能となっている、といったような各チームの戦略に関する部分で整合性が取れなくなってしまう。このようなことを防ぐため、いずれのチームからも攻撃可能なボスＮＰＣについては、フィールド内の位置等に関して同期処理が行われる。

〔第３の実施形態のまとめ〕
以上説明したように、本実施形態に係るゲームシステム１において、通常ＮＰＣ制御部１１３（第１ＮＰＣ制御部の一例）は、フィールド内で通常ＮＰＣ（第１のＮＰＣの一例）を制御する。また、対戦制御部１１４は、複数のチームのうち青チーム（第１のチームの一例）に属するユーザ情報により識別されるユーザの操作に基づいて、青チームから赤チーム陣営の通常ＮＰＣ（例えば、第１のＮＰＣの一例）への攻撃を制御する。一方、対戦制御部１１４は、複数のチームのうち赤チーム（第２のチームの一例）から赤チーム陣営の通常ＮＰＣへの攻撃を制限する。

これにより、ゲームシステム１は、通常ＮＰＣに対してはいずれかのチームからしか攻撃することができないため（例えば、青チーム及び赤チームの双方から攻撃できないため）、オンラインゲームにおいて発生し得る、攻撃したはずなのに討伐できなかったという祖語が起きないように抑制することができる。即ち、ゲームシステム１は、オンラインゲームで発生し得るタイムラグによる影響を抑制することができる。

対戦制御部１１４は、青チーム（第１のチームの一例）に属するユーザ情報により識別されるユーザの操作に基づいて、赤チーム（第２のチームの一例）に属するユーザ情報により識別されるユーザ毎の操作に基づいて活動するプレイヤキャラクタ（第２のキャラクタの一例）への攻撃を制御する場合、青チーム（第１のチームの一例）への攻撃によって赤チーム陣営の通常ＮＰＣ（例えば、第１のＮＰＣの一例）へ与えるダメージ（影響の一例）に比較して、赤チームのプレイヤキャラクタ（第２のキャラクタの一例）への攻撃によって、その赤チームのプレイヤキャラクタへ与えるダメージが小さくなるように制限する。なお、対戦制御部１１４は、赤チームから青チームのプレイヤキャラクタへ攻撃の場合も同様に、青チームのプレイヤキャラクタへ与える影響が小さくなるように制限する。

これにより、ゲームシステム１は、プレイヤキャラクタ同士の対戦では、攻撃したはずなのに討伐できなかったという祖語が発生し得るが、攻撃によるダメージを極端に小さくすることで、プレイヤキャラクタ同士の対戦を行うことによるメリットを少なくし、プレイヤキャラクタ同士での対戦の動機となる要因を減らすことができるため、上記の齟齬による影響を抑制することができる。

また、対戦制御部１１４は、青チーム（第１のチームの一例）から赤チームのプレイヤキャラクタ（第２のキャラクタの一例）への攻撃によって、その赤チームのプレイヤキャラクタの活動を制限させてもよい。同様に、対戦制御部１１４は、赤チームから青チームのプレイヤキャラクタへの攻撃によって、その青チームのプレイヤキャラクタの活動を制限させてもよい。

これにより、ゲームシステム１は、プレイヤキャラクタ同士の対戦では、対戦相手のプレイヤキャラクタにダメージを与えるより動きを止めることが目的となるため、攻撃したはずなのに討伐できなかったという祖語が起きるのを抑制できる。

また、ゲームシステム１は、通常ＮＰＣ制御部１１３（第１ＮＰＣ制御部の一例）を備える複数のゲーム装置１０（端末装置の一例）と、複数のゲーム装置１０と通信接続されるゲームサーバ３０（サーバ装置の一例）とを備えている。そして、通常ＮＰＣ制御部１１３は、フィールド内で通常ＮＰＣ（第１のＮＰＣの一例）の位置を、複数のゲーム装置１０毎に制御する。即ち、複数のゲーム装置１０のそれぞれの通常ＮＰＣ制御部１１３が、複数のゲーム装置１０毎にフィールド内で通常ＮＰＣを制御する。

これにより、ゲームシステム１は、通常ＮＰＣのフィールド内の位置や動き（モーション）、攻撃（技）を発動した場合の効果（エフェクト）など基本的にはリアルタイム性の高いアクションは各ゲーム装置１０（端末側）で管理するため、通信によるタイムラグによる影響が生じないように抑制することができる。

また、ゲームサーバ３０（サーバ装置の一例）は、フィールド内でボスＮＰＣ（第２のＮＰＣの一例）を制御するボスＮＰＣ制御部３１２（第２ＮＰＣ制御部の一例）を備えている。対戦制御部１１４は、青チーム（第１のチームの一例）に属するユーザ情報により識別されるユーザの操作に基づいて、青チームからボスＮＰＣへの攻撃を制御する。同様に、対戦制御部１１４は、赤チーム（第２のチームの一例）に属するユーザ情報により識別されるユーザの操作に基づいて、赤チームからボスＮＰＣへの攻撃を制御する。そして、ボスＮＰＣ制御部３１２は、フィールド内でボスＮＰＣの位置を、複数のゲーム装置１０（端末装置の一例）で同じ位置になるように制御する。

これにより、ゲームシステム１は、両陣営双方（例えば、青チーム及び赤チームの双方）から攻撃されるボスＮＰＣについては、各ゲーム装置１０で攻撃対象の位置が同じになるように同期することができるため、同一攻撃対象に対する複数ユーザの戦闘において整合性を確保できる。

ボスＮＰＣ（第２のＮＰＣの一例）を討伐するには、通常ＮＰＣ（第１のＮＰＣの一例）を討伐するのに比較して多くの攻撃を要する。例えば、ボスＮＰＣは、通常ＮＰＣよりＨＰが高く設定されている。なお、ボスＮＰＣは、通常ＮＰＣより防御力が高く設定されていてもよい。また、プレイヤキャラクタが通常ＮＰＣを攻撃する際の攻撃力よりボスＮＰＣを攻撃する際の攻撃力が低下してもよい。

これにより、ゲームシステム１は、討伐時（最後のとどめ）の攻撃については、攻撃したはずなのに討伐できなかったという祖語が起こり得るものの、それまでの両チームからの攻撃に関してはその順番が入れ替わってとしても大きな祖語とはなり得ないため、討伐するまでの攻撃全体として上記の齟齬による影響を少なくすることができる。

［第４の実施形態］
次に、本発明の第４の実施形態について説明する。本実施形態に係るゲームシステム１の基本的な構成は、第１の実施形態と同様であるので、本実施形態において特徴的な処理について説明する。第１の実施形態では、ゲームの基本的なルールとして、制限時間（例えば３分）内に占拠した部屋の数が多いチームが勝利となることについて説明したが、対戦相手との実力差によっては、制限時間を待たずして戦況の優劣が明確となり実質的に勝敗が決着してしまうような場合がある。このような場合、制限時間までプレイを継続しなければならないと、そのプレイ時間がユーザにとって無駄な時間に感じることがある。そこで、本実施形態では、例外的に対戦プレイによる勝敗が制限時間前に決定される例について説明する。

本実施形態では、勝敗判定部３１６は、各チームによる部屋の占拠状況（即ち、複数の部屋（通常部屋、ボス部屋など）のチームへの関連付け状況）に基づいて、制限時間に達する前であっても、チームの勝敗を確定することがある。例えば、勝敗判定部３１６は、各チームによる部屋の占拠状況が予め設定された状況になった場合、該状況が所定時間（例えば、３０秒）維持されたことを条件として、制限時間に達する前であってもチームの勝敗を確定する。予め設定された部屋の占拠状況とは、例えば、占拠可能な部屋のすべてを一方のチームが占拠した状況である。この場合、勝敗判定部３１６は、一方のチームがすべての部屋を占拠した状況が所定時間（例えば、３０秒）維持されると、制限時間に達する前であってもチームの勝敗を確定する。具体的には、勝敗判定部３１６は、全部屋を占拠したチームの勝利とする。つまり、勝敗判定部３１６は、各チームによる部屋の占拠状況に基づいて、チーム間に実力差があって制限時間を待たずして戦況の優劣が明確なった場合には、所謂コールドゲームの様に、制限時間前に勝敗を確定して対戦プレイを終了する。

また、チームの勝敗を確定する条件となる上記所定時間を示す情報が、対戦プレイのプレイ画像が表示されるプレイ画面に表示されてもよい。例えば、表示制御部１１５は、一方のチームがすべての部屋を占拠した状況になると、上記所定時間（例えば、３０秒）となるまでの時間を示す情報として上記所定時間までのカウントダウン表示を開始する。そして、表示制御部１１５は、一方のチームがすべての部屋を占拠した状況が維持されている間はカウントダウン表示を継続し、上記所定時間が経過した場合（カウントダウンが０秒になった場合）、または上記所定時間が経過する前に他方のチームに１部屋以上占拠し返された場合、カウントダウン表示を終了する。なお、プレイ画面に表示される上記所定時間（例えば、３０秒）となるまでの時間を示す情報は、カウントダウン表示（残時間）であってもよいし、カウントアップ表示（経過時間）であってもよい。

また、勝敗判定部３１６は、一方のチームがすべての部屋を占拠した状況となった後、該状況を所定時間（例えば、３０秒）維持できずに他方のチームに１部屋以上占拠し返された場合、再び、上記一方のチームが占拠可能な部屋のすべてを占拠した状況となると、チームの勝敗を確定する条件となる上記所定時間を短縮（例えば、３０秒から１５秒に短縮）してもよい。つまり、勝敗判定部３１６は、いずれかのチームにより全部屋が占拠された状況が繰り返し生じた場合、全部屋が占拠された回数に応じて、チームの勝敗を確定する条件となる上記所定時間を短縮してもよい。

このように全部屋が占拠された回数が増すほど上記所定時間が短くなる。この全部屋占拠の回数は、チーム毎にカウントされる回数である。つまり、同じチームによって全部屋占拠されることが繰り返されると、その度に上記所定時間が短縮される。例えば、最初に青チームが全部屋占拠して３０秒のカウントが終了する前にこの全部屋占拠の維持に失敗し、再び青チームが全部屋占拠した場合には１５秒のカウントとなるが、青チームではなく赤チームが初めて全部屋占拠した場合には１５秒ではなく３０秒のカウントとなる。このカウントダウンによって全部屋占拠された側のチームに巻き返しのチャンスとなる時間を与えているのは、何らかの要因で一気に攻められて実力を出せずに対戦が終了してしまうような不合理をなくすためである。

なお、制限時間に達するまでの残時間（対戦の残り時間）が上記所定時間以下である場合には全部屋占拠してもカウントダウン表示はされない。これは、例えば対戦の残り時間が２０秒の時に一方のチームが全部屋占拠した場合、３０秒のカウントダウンを開始してもカウントダウンが「０」になる前に制限時間により対戦が終了してしまうため、カウントダウン表示を行う意味がないためである。

次に、上述した対戦プレイにおいていずれかのチームにより全部屋が占拠された際にカウントダウンを行うカウントダウン処理の動作について説明する。
図１５は、本実施形態に係る対戦プレイにおけるカウントダウン処理の一例を示すフローチャートである。

対戦プレイが開始されると、占拠判定部３１５は、部屋が占拠されたか否かを判定する（ステップＳ２００）。部屋が占拠されていないと判定された場合（ＮＯ）、占拠判定部３１５は、ステップＳ２００の処理に戻し、部屋が占拠されたか否かを判定する。一方、部屋が占拠されたと判定された場合（ＹＥＳ）、占拠判定部３１５は、いずれかのチームにより全部屋が占拠されたか否かを判定する（ステップＳ２０２）。

いずれかのチームにより全部屋が占拠されていないと判定された場合（ＮＯ）、占拠判定部３１５は、ステップＳ２００の処理に戻し、部屋が占拠されたか否かを判定する。一方、いずれかのチームにより全部屋が占拠されたと判定された場合（ＹＥＳ）、占拠判定部３１５は、そのチームにより全部屋が占拠された回数を判定する（ステップＳ２０４）。

そのチームにより全部屋が占拠された回数が初回（１回目）と判定された場合、勝敗判定部３１６は、制限時間の残り時間（対戦の残り時間）が３０秒以上あるか否かと判定する（ステップＳ２０６）。残り時間が３０秒未満であると判定された場合（ＮＯ）、勝敗判定部３１６は、カウントダウンを行わないで、ステップＳ２００の処理に戻す。これにより、制限時間になるまで対戦プレイが継続される。一方、残り時間が３０秒以上であると判定された場合（ＹＥＳ）、勝敗判定部３１６は、３０秒のカウントダウンを開始する（ステップＳ２０８）。

次に、占拠判定部３１５は、部屋が占拠されたか（占拠し返されたか）否かを判定する（ステップＳ２１０）。即ち、占拠判定部３１５は、全部屋が占拠されている状態が維持されているか否かを判定する。カウントダウンが「０」になる前に一つでも部屋が占拠し返された（全部屋占拠が維持されなかった）と判定された場合（ＹＥＳ）、勝敗判定部３１６は、カウントダウンを途中で終了し、ステップＳ２００の処理に戻す。これにより、通常の対戦プレイに戻る。一方、部屋が占拠されていない（全部屋占拠が維持されている）と判定された場合（ＮＯ）、勝敗判定部３１６は、カウントダウンが「０」になったか否かを判定する（ステップＳ２１２）。カウントダウンが「０」になっていないと判定された場合（ＮＯ）、勝敗判定部３１６は、ステップＳ２１０の処理に戻しカウントダウンを継続する。一方、カウントダウンが「０」になったと判定された場合（ＹＥＳ）、勝敗判定部３１６は、全部屋占拠したチームの勝利（コールドゲーム）とし、その時点で対戦プレイを終了する。

一方、ステップＳ２１０において、３０秒経過する前に全部屋占拠が維持されなかったと判定されたことにより、３０秒のカウントダウンが途中で終了して通常の対戦プレイに戻った後、この状態で再び前回全占拠した側のチームが全部屋占拠すると、ステップＳ２０４においてそのチームにより全部屋が占拠された回数が２回目と判定される。２回目のカウントダウンは１５秒となり初回よりは短くなる。勝敗判定部３１６は、制限時間の残り時間（対戦の残り時間）が１５秒以上あるか否かと判定する（ステップＳ２１４）。残り時間が１５秒未満であると判定された場合（ＮＯ）、勝敗判定部３１６は、カウントダウンを行わないで、ステップＳ２００の処理に戻す。これにより、制限時間になるまで対戦プレイが継続される。一方、残り時間が１５秒以上であると判定された場合（ＹＥＳ）、勝敗判定部３１６は、１５秒のカウントダウンを開始する（ステップＳ２１６）。

次に、占拠判定部３１５は、部屋が占拠されたか（占拠し返されたか）否かを判定する（ステップＳ２１８）。即ち、占拠判定部３１５は、全部屋が占拠されている状態が維持されているか否かを判定する。カウントダウンが「０」になる前に一つでも部屋が占拠し返された（全部屋占拠が維持されなかった）と判定された場合（ＹＥＳ）、勝敗判定部３１６は、カウントダウンを途中で終了し、ステップＳ２００の処理に戻す。これにより、通常の対戦プレイに戻る。一方、部屋が占拠されていない（全部屋占拠が維持されている）と判定された場合（ＮＯ）、勝敗判定部３１６は、カウントダウンが「０」になったか否かを判定する（ステップＳ２２０）。カウントダウンが「０」になっていないと判定された場合（ＮＯ）、勝敗判定部３１６は、ステップＳ２１８の処理に戻しカウントダウンを継続する。一方、カウントダウンが「０」になったと判定された場合（ＹＥＳ）、勝敗判定部３１６は、全部屋占拠したチームの勝利（コールドゲーム）とし、その時点で対戦プレイを終了する。

一方、ステップＳ２１８において、１５秒経過する前に全部屋占拠が維持されなかったと判定されたことにより、１５秒のカウントダウンが途中で終了して通常の対戦プレイに戻った後、この状態で再び前回全占拠した側のチームが全部屋占拠すると、ステップＳ２０４においてそのチームにより全部屋が占拠された回数が３回目と判定される。同一チームによる３回目の全部屋占拠の場合には、勝敗判定部３１６は、カウントダウンをしないで、その時点で全部屋占拠したチームの勝利（コールドゲーム）とし、対戦プレイを終了する。

〔第４の実施形態のまとめ〕
以上説明したように、本実施形態に係るゲームシステム１において、占拠判定部３１５（領域判定部の一例）は、チームに属するユーザ情報により識別されるユーザの操作結果が所定の条件を満たしたか否かに基づいて、フィールド内の複数の部屋（領域の一例）のそれぞれをチームに関連付けるか否か（例えば、いずれのチームの占拠とするか）を判定する。勝敗判定部３１６は、予め設定された制限時間内における占拠判定部３１５による判定結果に基づいて、チームの勝敗を判定するとともに、各チームによる部屋の占拠状況（複数の領域のチームへの関連付け状況の一例）に基づいて、制限時間に達する前であってもチームの勝敗を確定する。

これにより、ゲームシステム１は、チームを構成する複数のユーザがそれぞれのキャラクタを操作して敵キャラクタと戦闘するアクションゲームにおいて、制限時間を待たずして戦況の優劣が明確となり実質的に勝敗が決着してしまうような場合に、その時点で勝敗を確定して終了するため、ユーザにとって無駄なプレイ時間が生じることを抑制できる。

また、勝敗判定部３１６は、各チームによる部屋の占拠状況（複数の領域のチームへの関連付け状況の一例）が予め設定された状況になった場合、該状況が所定時間維持されたことを条件として、制限時間に達する前であってもチームの勝敗を確定する。例えば、予め設定された部屋の占拠状況とは、占拠可能な部屋のすべてを一方のチームが占拠した状況（全部屋占拠）である。

これにより、ゲームシステム１は、一方のチームによって全部屋占拠されたとしても、占拠された側のチームに巻き返しのチャンスとなる時間を与えることができる。よって、ゲームシステム１は、何らかの要因で一気に攻められて実力を出せずに対戦が終了してしまうような不合理が生じてしまことを抑制できる。

なお、予め設定された部屋の占拠状況は、一方のチームが占拠した部屋の数と他方のチームが占拠した数との差が所定数以上となった状況としてもよいし、フィールド内の占拠可能な部屋のうち所定割合以上または所定数以上を一方のチームが占拠した状況としてもよい。また、予め設定された部屋の占拠状況は、一方のチームが他方のチームが占拠している部屋を占拠し返した割合や数に基づく状況であってもよい。

また、本実施形態では、各チームによる部屋の占拠状況が予め設定された状況（例えば、全部屋占拠）になった場合、該状況が所定時間維持されたことを条件として、制限時間に達する前であってもチームの勝敗を確定する例を説明したが、占拠された側のチームに巻き返しのチャンスとなる時間を与えない場合、各チームによる部屋の占拠状況が予め設定された状況（例えば、全部屋占拠）になったことのみを条件として、制限時間に達する前であってもチームの勝敗を確定してもよい。

また、勝敗判定部３１６は、各チームによる部屋の占拠状況（複数の領域のチームへの関連付け状況の一例）が予め設定された状況になった回数に応じて、上記所定時間を短縮する。これにより、ゲームシステム１は、全部屋占拠が繰り返された場合には、１回目の全部屋占拠のときよりも該チームが優勢であることがより確実と考えられるため、占拠された側のチームの巻き返しのチャンスとなる時間を短くし、全部屋占拠した側のチームのユーザにとって無駄なプレイ時間が生じることを抑制することができる。

例えば、複数のチームによる対戦の場合、上記回数は、チーム毎にカウント（計数）される。これにより、ゲームシステム１は、一方のチームによる全部屋占拠した後に、他方のチームが全部屋占拠し返した場合には、戦況の優劣が明確になっていないと考えられるため、各チームに対して平等に巻き返しのチャンスとなる時間を与えることができる。

また、表示制御部１１５は、各チームによる部屋の占拠状況（複数の領域のチームへの関連付け状況の一例）が予め設定された状況になった場合、上記所定時間となるまでの時間を示す情報を表示させる。これにより、ゲームシステム１は、対戦プレイ中のユーザに勝敗が確定するまでの時間をカウントダウンなどで提示するため、緊張感を高めることができる。また、ゲームシステム１は、勝敗が確定するまでの残り時間をユーザが把握し易くなるため、残り時間で何をするべきかの戦略をユーザが考え易くすることができる。

表示制御部１１５は、各チームによる部屋の占拠状況（複数の領域のチームへの関連付け状況の一例）が予め設定された状況になった場合、制限時間に達するまでの残時間と上記所定時間とに基づいて、上記所定時間となるまでの時間を示す情報を表示させるか否かを判定する。例えば、表示制御部１１５は、制限時間に達するまでの残時間（対戦の残り時間）が上記所定時間以下である場合には全部屋占拠しても上記所定時間となるまでの時間を示す情報の表示（カウントダウン表示）を行わない。これにより、ゲームシステム１は、対戦の残り時間がカウントダウンの時間よりも短い場合にはカウントダウンを開始してもカウントダウンが「０」になる前に制限時間により対戦が終了してしまうため、意味のないカウントダウン表示を行わないようにすることができる。

また、キャラクタ制御部１１２（キャラクタ移動部の一例）は、チームに属するユーザ情報により識別されるユーザ毎の操作に基づいて、ユーザに共通の複数の領域を有するフィールド内でユーザ情報毎に関連付けられたキャラクタを移動させる。これにより、ゲームシステム１は、制限時間を待たずして戦況の優劣が明確となり実質的に勝敗が決着してしまうような場合に、その時点で勝敗を確定して終了するため、ユーザが無駄にフィールド内でキャラクタを移動させる時間が生じることを抑制できる。

［第５の実施形態］
次に、本発明の第５の実施形態について説明する。本実施形態に係るゲームシステム１の基本的な構成は、第１の実施形態と同様であるので、本実施形態において特徴的な処理について説明する。

プレイヤキャラクタは攻撃を受けて死亡すると、スタート部屋から再スタートすることになる。死亡した場合、再スタートまで一定時間操作が不可となり活動が制限される（勝敗判定に関わるペナルティ）。そのため、できる限り死亡しないことがチームが勝つための条件の一つとなる。本実施形態では、プレイヤキャラクタが死亡する前段階としてチームメンバーによって復活させることが可能な仮死状態があることについて説明する。

プレイヤキャラクタは、通常ＮＰＣやボスＮＰＣなどから攻撃によりダメージを受けてＨＰが「０」になると、まず仮死状態となる。この時点ではプレイヤキャラクタは死亡していない。仮死状態でさらに所定値のダメージを受けると死亡状態となる。例えば、プレイヤキャラクタは、仮死状態となるとＨＰの値が若干戻り（例えば、「１０」）、さらに攻撃を受けて再びＨＰが「０」になると死亡状態となる。仮死状態のプレイヤキャラクタは、同じチームのプレイヤキャラクタに基づいて仮死状態から通常状態に復活することができる。つまり、一旦ＨＰが「０」になっても即死亡状態になるのではなく、復活のチャンスが与えられる。通常状態とは、出現してから仮死状態に至る前までの少なくともユーザの操作に基づいて移動可能な状態である。例えば、同じチームのプレイヤキャラクタが仮死状態となったプレイヤキャラクタに近づくと、プレイ画面上の仮死状態となったプレイヤキャラクタの近傍に、仮死状態となったプレイヤキャラクタを復活させる操作を受け付ける操作子として復活アイコンが表示される。この復活アイコンに対して操作がされると、仮死状態だったプレイヤキャラクタが通常状態に戻り、ＨＰの値も復活する。このように、同じチームのメンバー（仲間）との協力により、チーム内で死亡してしまいそうなプレイヤキャラクタを、完全に死亡状態となってしまう前に助けることができる。

プレイヤキャラクタは、仮死状態になると通常状態に比較して著しく能力が低下する。例えば、プレイヤキャラクタは、仮死状態になると攻撃力、防御力、及びＨＰ等のパラメータが著しく低下する（仮死状態専用パラメータになる）。また、仮死状態になると、プレイヤキャラクタに設定されたスキル（対戦相手に大ダメージを与える攻撃やＨＰの回復など）が使用できなくなる。また、仮死状態になると、プレイヤキャラクタの移動速度やジャンプ力が通常状態より低下する。つまり、仮死状態は、死亡状態ではないが、通常状態より能力（攻撃力、防御力、及びＨＰ等のパラメータ）が低下した状態であって、それによって、プレイヤキャラクタの活動が通常状態より制限される状態である。例えば、仮死状態のプレイヤキャラクタは、少しは動くことも戦うこともできるが、攻撃してもほとんどダメージを与えることができない。

一方、死亡状態は、プレイヤキャラクタの活動が制限された状態（例えば、操作が全くできない状態）であって、且つ同じチームの他のプレイヤキャラクタによって通常状態に復活することが不可能な状態である。なお、死亡状態は、死亡してゲームオーバーとなる状態ではなく、引き続きゲームは進行し、一定時間操作が不可となる状態である。

また、仮死状態になるとプレイ画面に表示される見た目も変化する。図１６は、プレイヤキャラクタの状態毎の見た目の一例を示す図である。図示するように、通常状態では、見た目が人間である戦士のキャラクタであるが、仮死状態になると見た目が骸骨になる。また、死亡状態になると消滅する。例えば、ゲーム装置１０−１においてユーザの操作に基づいて活動するプレイヤキャラクタが仮死状態である場合、ゲーム装置１０−１の表示制御部１１５は、該仮死状態のプレイヤキャラクタを通常状態のプレイヤキャラクタと識別可能な表示態様で表示させる。また、ゲーム装置１０−１においてユーザの操作に基づいて活動するプレイヤキャラクタが仮死状態である場合、ゲーム装置１０−２の表示制御部１１５は、該仮死状態のプレイヤキャラクタをゲーム装置１０−２において通常状態のプレイヤキャラクタと識別可能な表示態様で表示させる。

なお、図１６では、プレイヤキャラクタが通常状態から仮死状態になると、見た目が骸骨の表示態様に変更される例を示したが、このように表示内容そのものが変更されてもよいが、表示内容そのものは変更されなくてもよい。例えば、プレイヤキャラクタが通常状態から仮死状態になると、プレイ画面に表示されるプレイヤキャラクタの大きさが変更されてもよいし、点滅表示に変更されてもよいし、色または透過度が変更されてもよい。

仮死状態になったプレイヤキャラクタは、攻撃力等が低下するため、戦果を上げることがほとんどできなくなり、また、防御力も低くなるため、少ないダメージで死亡状態になり易くなる。つまり、戦略的には一刻も早く仮死状態から脱する必要がある。そこで、同じチームのプレイヤキャラクタを、仮死状態になったプレイヤキャラクタの近く移動させることにより、仮死状態になったプレイヤキャラクタを通常状態に復活させることができる。よって、ゲームシステム１は、チーム内の協力の機会がより多いゲームを提供できる。

図１７は、本実施形態に係るキャラクタ制御部１１２の詳細構成の一例を示すブロック図である。図示するキャラクタ制御部１１２は、キャラクタ状態制御部１１２１と、復活制御部１１２２とを備えている。キャラクタ状態制御部１１２１は、通常状態のプレイヤキャラクタのＨＰが「０」になると、該プレイヤキャラクタを仮死状態に遷移させる。また、キャラクタ状態制御部１１２１は、仮死状態のプレイヤキャラクタがさらに攻撃を受けて、一時的に若干値が戻ったＨＰが再び「０」になると、該プレイヤキャラクタを死亡状態に遷移させる。

復活制御部１１２２は、仮死状態のプレイヤキャラクタを、該プレイヤキャラクタと同じチームに属する他のプレイヤキャラクタに基づいて通常状態に復活させる。例えば、復活制御部１１２２は、仮死状態のプレイヤキャラクタを、該プレイヤキャラクタと同じチームに属する通常状態のプレイヤキャラクタとの位置関係に基づいて、通常状態に復活させる。具体的には、復活制御部１１２２は、仮死状態のプレイヤキャラクタに同じチームに属する通常状態のプレイヤキャラクタが近づいた場合、該仮死状態のプレイヤキャラクタを通常状態に復活させる操作を受け付ける復活アイコンを、プレイ画面に表示させるように指示する。そして、復活制御部１１２２は、復活アイコンに対して操作がされると、仮死状態だったプレイヤキャラクタをその場所で通常状態に戻し、ＨＰの値も（例えば、初期値に）復活させる。

一方、復活制御部１１２２は、死亡状態のプレイヤキャラクタを、死亡状態になってから所定時間（例えば、１０秒）が経過することによって通常状態に遷移させる。例えば、復活制御部１１２２は、死亡状態のプレイヤキャラクタを通常状態に遷移させる場合、該プレイヤキャラクタのスタート部屋に配置する。つまり、プレイヤキャラクタが死亡すると、一定時間操作が不可となり、その後、スタート部屋からの再スタートとなる。

次に、キャラクタ制御部１１２がプレイヤキャラクタの状態遷移を制御する状態遷移処理の動作について説明する。図１８は、本実施形態に係る状態遷移処理の一例を示すフローチャートである。

対戦プレイが開始されると、キャラクタ制御部１１２は、通常状態のプレイヤキャラクタを、該プレイヤキャラクタのチームのスタート部屋に配置する。このとき、プレイヤキャラクタのＨＰは初期値（例えば「１０００」）である（ステップＳ３００）。このプレイヤキャラクタは、ユーザの操作に基づいて、フィールド内を移動し各部屋で対戦相手（例えば、通常ＮＰＣやボスＮＰＣなど）と戦闘を行う。

キャラクタ制御部１１２は、通常状態のプレイヤキャラクタのＨＰが「０」になった否かを判定する（ステップＳ３０２）。ＨＰが「０」になっていないと判定された場合（ＮＯ）、キャラクタ制御部１１２は、そのプレイヤキャラクタを通常状態のままとし、ステップＳ３０２の処理を再び行う。一方、ＨＰが「０」になったと判定された場合（ＹＥＳ）、キャラクタ制御部１１２は、その通常状態のプレイヤキャラクタを仮死状態に遷移させる。また、キャラクタ制御部１１２は、そのプレイヤキャラクタのＨＰの値を若干（例えば、「１０」に）戻す（ステップＳ３０４）。

また、キャラクタ制御部１１２は、仮死状態のプレイヤキャラクタのＨＰが「０」になった否かを判定する（ステップＳ３０６）。ＨＰが「０」になったと判定された場合（ＹＥＳ）、キャラクタ制御部１１２は、その仮死状態のプレイヤキャラクタを死亡状態に遷移させる（ステップＳ３０８）。そして、キャラクタ制御部１１２は、死亡状態に遷移してから所定時間が経過した後、ステップＳ３００の処理に戻す（ステップＳ３１０）。そして、死亡状態から通常状態（例えば、ＨＰは初期値（例えば「１０００」））に戻したプレイヤキャラクタをスタート部屋に配置する（ステップＳ３００）。これにより、死亡したプレイヤキャラクタは、一定時間操作が不可となった後、スタート部屋から再スタートとなる。

一方、ステップＳ３０６においてＨＰが「０」になっていないと判定された場合（ＮＯ）、キャラクタ制御部１１２は、復活アイコンの表示条件を満たしたか否かを判定する（ステップＳ３１２）。復活アイコンの表示条件とは、仮死状態のプレイヤキャラクタに、同じチームの通常状態のキャラクタが近づくことである。例えば、キャラクタ制御部１１２は、仮死状態のプレイヤキャラクタに、同じチームの通常状態のキャラクタが所定の距離内に近づいたと判定した場合（例えば、仮死状態のプレイヤキャラクタに同じチームの通常状態のキャラクタが触れる位置関係になった場合、或いはプレイ画面上で重なる位置関係になった場合）、復活アイコンの表示条件を満たしたと判定する。

復活アイコンの表示条件が満たされていないと判定された場合（ＮＯ）、キャラクタ制御部１１２は、ステップＳ３０６の処理に戻し、その仮死状態のプレイヤキャラクタのＨＰが「０」になった否かを判定する。一方、復活アイコンの表示条件が満たされたと判定された場合（ＹＥＳ）、キャラクタ制御部１１２は、復活アイコンの表示を表示制御部１１５に指示する。これにより、表示制御部１１５は、プレイ画面において、その仮死状態のプレイヤキャラクタの近傍に復活アイコンを表示させる（ステップＳ３１４）。

次に、キャラクタ制御部１１２は、入力部１３に対するユーザの操作に基づいて、復活アイコンに対する操作がされたか否かを判定する（ステップＳ３１６）。復活アイコンに対する操作がされていないと判定された場合（ＮＯ）、キャラクタ制御部１１２は、ステップＳ３０６に処理を戻す。復活アイコンに対する操作がされる前に仮死状態のプレイヤキャラクタのＨＰが「０」になった場合には死亡状態に遷移する。また、仮死状態のプレイヤキャラクタのＨＰが「０」になる前は、一旦復活アイコンの表示条件が満たされたと判定されて表示された復活アイコンは、表示が継続される。

一方、復活アイコンに対する操作がされたと判定された場合（ＹＥＳ）、キャラクタ制御部１１２は、その仮死状態のプレイヤキャラクタを通常状態（例えば、ＨＰは初期値（例えば「１０００」））に復活させる（ステップＳ３１８）。

〔第５の実施形態のまとめ〕
以上説明したように、本実施形態に係るゲームシステム１において、キャラクタ制御部１１２は、チームに属するユーザ情報により識別されるユーザ毎の操作に基づいて、チーム内に共通のフィールド内でユーザ情報毎に関連付けられたキャラクタを活動させる。例えば、キャラクタ制御部１１２は、キャラクタ状態制御部１１２１と、復活制御部１１２２とを備えている。キャラクタ状態制御部１１２１は、通常状態（第１状態の一例）のプレイヤキャラクタについてＨＰが「０」になること（所定の第１条件が満たされることの一例）を条件として該プレイヤキャラクタを通常状態よりも能力が低下した仮死状態（第２状態の一例）に遷移させる。また、キャラクタ状態制御部１１２１は、仮死状態のプレイヤキャラクタについて再びＨＰが「０」になること（所定の第２条件が満たされることの一例）を条件として該プレイヤキャラクタの活動が制限される死亡状態（第３状態の一例）に遷移させる。復活制御部１１２２は、仮死状態のプレイヤキャラクタを、該プレイヤキャラクタと同じチームに属する他のプレイヤキャラクタに基づいて通常状態に復活させる。勝敗判定部３１６は、キャラクタ制御部１１２によりプレイヤキャラクタが活動した結果に基づいて、チームの勝敗を判定する。例えば、勝敗判定部３１６は、プレイヤキャラクタが活動した結果（戦闘の結果）に基づく各チームの部屋の占拠状況に基づいて、チームの勝敗を判定する。

これにより、ゲームシステム１は、プレイヤキャラクタが攻撃を受けてＨＰが「０」になっても即死亡とはならず、同じチームの協力による復活のチャンスを与えることができる。よって、ゲームシステム１は、チーム対戦型のアクションゲームにおいて、チーム内の協力の機会をより多くすることができる。

なお、本実施形態の適用は、部屋を占拠し合う対戦プレイに限られるものではない。例えば、対戦相手を討伐し合う対戦プレイの場合には、勝敗判定部３１６は、プレイヤキャラクタが活動した結果（戦闘の結果）に基づく各チームの討伐状況に基づいて、チームの勝敗を判定してもよい。

また、復活制御部１１２２は、仮死状態（第２状態の一例）のプレイヤキャラクタを、該プレイヤキャラクタと同じチームに属する通常状態（第１状態の一例）のプレイヤキャラクタとの位置関係に基づいて、通常状態に復活させる。例えば、復活制御部１１２２は、仮死状態のプレイヤキャラクタに、同じチームの通常状態のキャラクタが所定の距離内に近づいたと判定した場合（例えば、仮死状態のプレイヤキャラクタに同じチームの通常状態のキャラクタが触れる位置関係になった場合、或いはプレイ画面上で重なる位置関係になった場合）、仮死状態のプレイヤキャラクタを通常状態に復活させる。

これにより、ゲームシステム１は、仮死状態のプレイヤキャラクタを復活させるには、その仮死状態のプレイヤキャラクタがいる場所に同じチームの他のプレイヤキャラクタが移動することが必要になるため、チームメンバーが協力して救出する感覚を与えることができる。

なお、仮死状態のプレイヤキャラクタを復活させる方法は、仮死状態のプレイヤキャラクタと同じチームの通常状態のプレイヤキャラクタとの位置関係に基づく方法に限られるものではない。例えば、仮死状態のプレイヤキャラクタを復活させる方法は、同じチームの通常状態のプレイヤキャラクタが特定のアイテムを使用することであってもよい。特定のアイテムとは、例えば、仮死状態のプレイヤキャラクタを復活させる効果を有する復活アイテムである。また、仮死状態のプレイヤキャラクタを復活させる方法は、同じチームの通常状態のプレイヤキャラクタが特定の場所に行くことであってもよい。特定の場所とは、例えば、復活させるための祈り部屋である。例えば、同じチームのユーザの操作によって、そのユーザの通常状態のプレイヤキャラクタが祈り部屋に行くこと、または祈り部屋に行って部屋の中で祈る動作を行うことで、仮死状態のプレイヤキャラクタが復活してもよい。

通常状態（第１状態の一例）よりも能力が低下した仮死状態（第２状態の一例）とは、プレイヤキャラクタの活動が制限された状態であることが含まれる。これにより、ゲームシステム１は、プレイヤキャラクタを仮死状態に遷移させた場合、そのプレイヤキャラクタの活動が通常状態より制限されるため、対戦プレイにおいてチームの戦力が低下することから、その仮死状態のプレイヤキャラクタを復活させる動機付けをチームメンバーに与えることができる。

通常状態（第１状態の一例）よりも能力が低下した仮死状態（第２状態の一例）とは、通常状態よりもプレイヤキャラクタに関連付けられているパラメータの値が、プレイヤキャラクタの能力が低下する値に変更された状態であることが含まれる。これにより、ゲームシステム１は、プレイヤキャラクタを仮死状態に遷移させた場合、そのプレイヤキャラクタの攻撃力、防御力、及びＨＰなどのパラメータの値が通常状態より低下するため、対戦プレイにおいてチームの戦力が低下することから、その仮死状態のプレイヤキャラクタを復活させる動機付けをチームメンバーに与えることができる。

一方、死亡状態（第３状態の一例）とは、プレイヤキャラクタの活動が制限された状態であって、且つプレイヤキャラクタと同じチームに属する他のプレイヤキャラクタに基づいて通常状態（第１状態の一例）に復活することが不可能な状態であることが含まれる。これにより、ゲームシステム１は、プレイヤキャラクタが死亡すると、チーム内の協力では復活不可能となるため、仮死状態のうちになんとか復活させられるようにチーム内で協力する動機付けを与えることができる。

なお、死亡状態（第３状態の一例）は、通常状態（第１状態の一例）への復活が不可能な状態としてもよい。この場合、ユーザは、自身が操作するプレイヤキャラクタが死亡すると、その後、引き続き行われている対戦プレイには参加できなくなり（即ち、そのユーザはゲームオーバーとなり）、例えばプレイ画面を見ているだけとなる。これにより、ゲームシステム１は、プレイヤキャラクタが死亡すると、チーム内の協力では復活不可能となるだけでなく、その後対戦プレイに参加できないため、仮死状態のうちになんとか復活させられるようにチーム内で協力する動機付けを与えることができる。

復活制御部１１２２は、死亡状態（第３状態の一例）のプレイヤキャラクタを、死亡状態になってから所定時間が経過することによって通常状態（第１状態の一例）に遷移させる。これにより、ゲームシステム１は、プレイヤキャラクタが死亡してもゲームオーバーとなるのではなく引き続きプレイは進行し、一定時間操作が不可となった後に再スタートとなるため、再び対戦プレイに参加してチームに貢献することができる。また、ゲームシステム１は、プレイヤキャラクタが死亡するとそのプレイヤキャラクタに対して一定時間操作ができなくなるため、仮死状態のうちになんとか復活させられるようにチーム内で協力する動機付けを与えることができる。

なお、復活制御部１１２２は、死亡状態のプレイヤキャラクタを、死亡状態になってから所定時間が経過することによって仮死状態（第２状態の一例）に遷移させてもよい。この場合、ゲームシステム１は、プレイヤキャラクタが死亡するとそのプレイヤキャラクタに対して一定時間操作ができなくなる上に、さらに仮死状態から救う必要があるため、チーム内での協力をより必要なゲーム仕様とすることができる。

また、復活制御部１１２２は、死亡状態（第３状態の一例）のプレイヤキャラクタを通常状態（第１状態の一例）または仮死状態（第２状態の一例）に遷移させる場合、遷移させたプレイヤキャラクタをフィールド内の所定の場所に配置する。例えば、復活制御部１１２２は、死亡状態のプレイヤキャラクタを通常状態に遷移させる場合、該プレイヤキャラクタのスタート部屋に配置する。これにより、ゲームシステム１は、一旦死亡したプレイヤキャラクタをスタート部屋からの再スタートさせることで、一定時間操作が不可という時間的なペナルティに加えて、場所的なペナルティも与えることができる。

なお、復活制御部１１２２は、死亡状態のプレイヤキャラクタを仮死状態（第２状態の一例）に遷移させる場合、遷移させたプレイヤキャラクタをフィールド内の該プレイヤキャラクタが死亡した場所に配置してもよいし、該プレイヤキャラクタのスタート部屋に配置してもよい。例えば、死亡状態から仮死状態に復活したプレイヤキャラクタが死亡した場所に配置される場合、通常状態に復活するためにはさらにチームメンバーの協力が必要になる反面、場所的なペナルティは免除される。一方、死亡状態から仮死状態に復活したプレイヤキャラクタがスタート部屋に配置される場合、通常状態に復活するためにはさらにチームメンバーの協力が必要になるとともに、場所的なペナルティも課せられる。これにより、ゲームシステム１は、プレイヤキャラクタが死亡したときのペナルティの度合いを変えることができる。

なお、復活制御部１１２２は、仮死状態（第２の状態の一例）から通常状態（第１状態の一例）に復活させる回数を制限してもよい。例えば、復活制御部１１２２は、１回の対戦プレイにおいて、仮死状態から復活可能な回数に制限（例えば３回）を設けてもよい。この回数を超えては復活できないようにしてもよいし、この回数を越えた場合には特定のアイテムを消費しなければ復活できないようにしてもよい。これにより、ゲームシステム１は、いくらでも復活できることによってプレイの難易度が低下しすぎてしまったり、チーム間の実力差が反映されなくなってしまうことがないように抑制することができる。

また、表示制御部１１５は、ゲーム装置１０−１（第１の端末装置の一例）においてユーザの操作に基づいて活動するプレイヤキャラクタが仮死状態（第２の状態の一例）である場合、該プレイヤキャラクタをゲーム装置１０−２（第２の端末装置の一例）において通常状態（第１の状態の一例）のプレイヤキャラクタと識別可能な表示態様で表示させる。なお、このときの表示制御部１１５は、ゲーム装置１０−２の表示制御部１１５の処理となる。これにより、ゲームシステム１は、仮死状態になったプレイヤキャラクタを通常状態のプレイヤキャラクタに対して容易に区別できるように、プレイ画面に表示させることができる。

なお、プレイヤキャラクタが死亡した場合、一定時間操作が不可という時間的なペナルティ、及びスタート場所から再スタートという場所的なペナルティに加えて、または代えて、報酬付与部３１７に付与される所定のポイントが減点されてもよい。

［第６の実施形態］
次に、本発明の第６の実施形態について説明する。本実施形態に係るゲームシステム１の基本的な構成は、第１の実施形態と同様であるので、本実施形態において特徴的な処理について説明する。本実施形態では、フィールド内で取得可能なアイテムについて説明する。

フィールド内には、ユーザがプレイヤキャラクタを操作することにより取得可能なアイテムが配置されている。配置されているアイテムには、通常アイテムと宝箱アイテムとの２種類のアイテムある。通常アイテムは、アイテムの種類が識別可能な表示態様で表示される。一方、宝箱アイテムは、取得する前は何のアイテムが入手できるかが不明な表示態様で表示されており、取得時に入手アイテムが判明する。両アイテムとも、それが配置されている場所にプレイヤキャラクタを移動させることで取得することができる。例えば、報酬付与部３１７は、プレイヤキャラクタと宝箱アイテムまたは通常アイテムとの位置関係に基づいて、それぞれに対応するアイテムを報酬として付与する。取得したアイテムはパラメータを回復させるアイテムの様にその場で消費されるものと、対戦が終了した時に取得が確定するものがある。対戦が終了した時に取得が確定するアイテムの場合、対戦に敗北した場合には取得不可としてもよい。

〔宝箱アイテムの仕様〕
宝箱アイテムは、フィールド内の予め設定された複数の場所にそれぞれ配置されている。図１９は、宝箱アイテムの表示例を示す図である。図示するように、宝箱アイテムは箱を表すオブジェクトを示す表示態様で表示されており、取得できる中身のアイテムは取得するまで分からない。つまり、表示制御部１１５は、フィールド内に配置された宝箱アイテムをアイテムの種類（報酬内容）が識別不可能な表示態様で表示させる。中身は予め決められていてもよいし、取得時に抽選によって決定されてもよい。あるユーザがプレイヤキャラクタを操作して宝箱アイテムを取得した場合、そのユーザのみではなく同じチームのユーザ全員にアイテムが付与される。例えば、報酬付与部３１７は、フィールド内に配置された宝箱アイテムを取得する操作がいずれかのユーザにより行われた場合、同じチームに属するユーザ情報により識別される各ユーザに対してユーザ毎に選択されたアイテムを報酬として付与する。なお、対戦相手チームのユーザには付与されない。そのため、フィールド内に存在する複数の宝箱アイテムをチーム内のユーザで分担して取得することで、対戦相手チームよりアイテムを多く取得することを目指す戦略も有り得る。

また、宝箱アイテムの配置情報は、チーム毎に関連付けられているが、この配置情報によって特定される宝箱アイテムの配置位置は共通である。よって、どのユーザに対しても、フィールド内の同じ場所に宝箱アイテムが配置される。また、各宝箱アイテムが取得済みであるか或いは未取得であるかの情報は、チーム毎に異なる。つまり、宝箱アイテムは、チーム内の複数のユーザで重複して取得することはできず、いずれかのユーザが一度取得した宝箱アイテムは、チーム内の他のユーザは取得不可となる。例えば、報酬付与部３１７は、いずれかのユーザの操作により取得済みとなった宝箱アイテムを、同じチームに属するユーザ情報により識別されるいずれのユーザに対しても取得対象から除外する。つまり、報酬付与部３１７は、チーム毎に関連付けられている宝箱アイテムの配置情報に含まれる「取得済みであるか或いは未取得であるかの情報」が「取得済み」となったチームについては、そのチーム内の他のユーザが取得不可となるように、そのチームに属するユーザ情報により識別されるいずれのユーザに対しても取得対象から除外するように制御する。

なお、宝箱アイテムの配置情報は、ユーザ情報毎に関連付けられてもよい。宝箱アイテムの配置情報がユーザ情報毎に関連付けられている場合、この配置情報によって特定される宝箱アイテムの配置位置は全ユーザに対して共通である。また、ユーザ情報毎に関連付けられている各宝箱アイテムが取得済みであるか或いは未取得であるかの情報は、チーム毎に共通である。これにより、どのユーザに対しても、フィールド内の同じ場所に宝箱アイテムが配置され、各宝箱アイテムが取得済みであるか或いは未取得であるかの情報がチーム毎に管理される。

宝箱アイテムを取得すると、同じチームのユーザ全員にアイテムが付与されるが、同じ宝箱アイテムでも付与される中身はユーザ毎に異なる。例えば、中身はランダムに決まるため、価値の高いアイテムが付与されるユーザがいれば、価値の低いアイテムが付与されるユーザもいることになる。例えば、表示制御部１１５は、報酬付与部３１７がチームに属するユーザ情報により識別される各ユーザに付与したユーザ毎のアイテムの種類を表示させる。つまり、同じチーム内のユーザに付与されたアイテムを示す情報は、プレイ画面に表示され、チーム内のコミュニケーションのきっかけの一つとなる。

なお、宝箱アイテムにより取得されるアイテムは、プレイヤキャラクタに装備可能なアイテムなどのように通常アイテムにはないアイテムもあり、通常アイテムより比較的価値の高いアイテムであることが多い。

〔通常アイテムの仕様〕
通常アイテムも、フィールド内の予め設定された複数の場所にそれぞれ配置されている。全ての種類の通常アイテムは、宝箱アイテムより多く配置されており、宝箱アイテムよりも高い確率で遭遇する。例えば、表示制御部１１５は、フィールド内に配置された通常アイテムをアイテムの種類（報酬内容）が識別可能な表示態様で表示させる。図２０は、通常アイテムの表示例を示す図である。図示する通常アイテムは、ＨＰを回復する「にく」アイテムであり、肉を表すオブジェクトを示す表示態様で表示されている。このように、通常アイテムは、宝箱アイテムとは異なり、取得前からそのアイテムが識別可能である。なお、通常アイテムは、ＨＰを回復するアイテムなどのように、その場で消費されるアイテムが多い。よって、ユーザは、通常アイテムを見つけた場合、そのとき必要であれば取得してもよいが、そのとき必要なければ取得せずに、後で必要になったときに取得してもよい。

通常アイテムの配置情報は、ユーザ毎に設定されているため、他のユーザには影響しない。例えば、あるユーザが取得した通常アイテムは、チームに関係なく他のユーザも取得可能である。つまり、報酬付与部３１７は、フィールド内に配置された通常アイテムを取得する操作がいずれかのユーザにより行われた場合、該ユーザに対してその通常アイテムを付与するとともに、その通常アイテムを取得する操作が他のユーザにより行われた場合、該他のユーザに対してその通常アイテムを付与する。

また、フィールド内に配置された通常アイテムの配置情報はユーザ情報毎に関連付けられているが、ユーザ情報毎に関連付けられた配置情報によって特定される通常アイテムの配置位置は共通である。また、ユーザ情報毎に関連付けられた配置情報によって特定される通常アイテムの種類（報酬内容）も共通である。よって、どのユーザに対しても、フィールド内の同じ場所に同じ種類の通常アイテムが配置される。一方、各通常アイテムが取得済みであるか或いは未取得であるかの情報は、ユーザ毎に異なる。これにより、いつどこで通常アイテムを取得するか（例えば、ＨＰを回復させるか）などの戦略はユーザ毎に立てられることになる。

なお、上記では通常アイテムの配置情報は、ユーザ情報毎に関連付けられているものとしたが、チーム毎に関連付けられてもよい。その場合、チーム内で必要なアイテムを必要なユーザが使用する戦略を、チーム単位で立てることができるようになる。

次に、通常アイテム及び宝箱アイテムによる報酬付与処理の動作について説明する。図２１は、本実施形態に係る報酬付与処理の一例を示すフローチャートである。

報酬付与部３１７は、入力部１３に対するユーザの操作に基づいてアイテムが取得されると（ステップＳ４００）、取得されたアイテムが通常アイテムであるか、または宝箱アイテムであるかを判定する（ステップＳ４０２）。取得されたアイテムが通常アイテムであると判定された場合、報酬付与部３１７は、その通常アイテムをユーザに付与する（ステップＳ４０４）。

一方、取得されたアイテムが宝箱アイテムであると判定された場合、報酬付与部３１７は、宝箱アイテムに関連付けられた複数のアイテムからユーザ毎に付与するアイテムを抽選（ランダ抽選）する（ステップＳ４０６）。そして、報酬付与部３１７は、抽選結果に基づいて、ユーザ毎に抽選されたアイテムを付与する（ステップＳ４０８）。また、報酬付与部３１７は、ユーザ毎に付与したアイテムを示す情報の表示を表示制御部１１５に指示する。これにより、表示制御部１１５は、プレイ画面において、ユーザ毎に付与したアイテムを示す情報を表示させる（ステップＳ４１０）。

〔第６の実施形態のまとめ〕
以上説明したように、本実施形態に係るゲームシステム１において、キャラクタ制御部１１２は、チームに属するユーザ情報により識別されるユーザ毎の操作に基づいて、チーム内に共通のフィールド内で、ユーザ情報毎に関連付けられたキャラクタを移動させる。報酬付与部３１７は、フィールド内に配置された宝箱アイテム（第１オブジェクトの一例）を取得する操作がいずれかのユーザにより行われた場合、同じチームに属するユーザ情報により識別される各ユーザに対してユーザ毎に選択されたアイテム（報酬の一例）を付与する。

これにより、ゲームシステム１は、フィールド内に存在する複数の宝箱アイテムをチーム内のユーザで分担して取得することができるため、チーム対戦型のアクションゲームにおいて、チーム内の協力の機会をより多くすることができる。

表示制御部１１５（第１表示制御部の一例）は、報酬付与部３１７がチームに属するユーザ情報により識別される各ユーザに付与したユーザ毎のアイテムの種類（報酬の内容の一例）を表示させる。これにより、ゲームシステム１は、チーム内の各ユーザに付与されたアイテムの種類が分かるので、チーム内のコミュニケーションのきっかけにすることができる。

また、表示制御部１１５（第１表示制御部の一例）は、フィールド内に配置された宝箱アイテム（第１オブジェクトの一例）をアイテムの種類（報酬の内容の一例）が識別不可能な表示態様で表示させる。これにより、ゲームシステム１は、宝箱アイテムを取得した後に、付与されるアイテムの種類が分かること、即ち付与されるアイテムが取得前に分からないことを示唆するとともに、分からないことにより、取得する際の期待感を高めることができる。

一方、表示制御部１１５（第２表示制御部の一例）は、フィールド内に配置された通常アイテム（第２オブジェクトの一例）をアイテムの種類（報酬の内容の一例）が識別可能な表示態様で表示させる。これにより、ゲームシステム１は、付与されるアイテムの種類をユーザが事前に確認した上で通常アイテムを取得可能にできる。例えば、通常アイテムは、ＨＰを回復するアイテムなどのように、その場で消費されるアイテムが多い。そのため、ユーザは、付与されるアイテムの種類を事前に確認した上で、必要に応じて通常アイテムを取得するか否かを判断できる。

報酬付与部３１７は、プレイヤキャラクタと宝箱アイテム（第１オブジェクトの一例）との位置関係に基づいてアイテム（報酬の一例）を付与する。例えば、報酬付与部３１７は、宝箱アイテムが配置されている場所にプレイヤキャラクタを移動させることでアイテムを付与する。これにより、ゲームシステム１は、フィールド内に存在する複数の宝箱アイテムのそれぞれに対してチーム内のユーザが分担して移動させることで、効率よくユーザがアイテムを取得することができる。

報酬付与部３１７は、いずれかのユーザの操作により取得済みとなった宝箱アイテム（第１オブジェクトの一例）を、同じチームに属するユーザ情報により識別されるいずれのユーザに対しても取得対象から除外する。これにより、ゲームシステム１は、同じチーム内の複数のユーザで宝箱アイテムを重複して取得することができないため、価値の高いアイテムをユーザに付与しすぎないようにすることができる。

なお、報酬付与部３１７は、いずれかのユーザの操作により取得済みとなった宝箱アイテム（第１オブジェクトの一例）を、チームに関係なくいずれのユーザに対しても取得対象から除外してもよい。この場合、宝箱アイテムは、一方のチームが取得すると、他方のチームは取得できなくなるため、よりチーム間の競争を激しくすることができる。

フィールド内には、宝箱アイテム（第１オブジェクトの一例）と異なる通常アイテム（第２オブジェクトの一例）が配置されている。報酬付与部３１７は、フィールド内に配置された通常アイテムを取得する操作がいずれかのユーザにより行われた場合、該ユーザに対して報酬を付与するとともに、該通常アイテムを取得する操作が他のユーザにより行われた場合、該他のユーザに対して報酬を付与する。

これにより、ゲームシステム１は、あるユーザが取得した通常アイテムがチームに関係なく他のユーザも取得可能であるため、どのユーザに対しても平等に通常アイテムの取得の機会を与えることができる。また、ゲームシステム１は、いつどこで通常アイテムを取得するか（例えば、ＨＰを回復させるか）などの戦略をユーザ毎に立てられるようにすることができる。

フィールド内に配置された通常アイテム（第２オブジェクトの一例）の配置情報はユーザ情報毎に関連付けられており、ユーザ情報毎に関連付けられた配置情報によって特定される通常アイテムの配置位置が共通である。これにより、ゲームシステム１は、どのユーザに対してもフィールド内の同じ場所に通常アイテムを配置するため、どのユーザに対しても平等に通常アイテムの取得の機会を与えることができる。

ユーザ情報毎に関連付けられた配置情報によって特定される通常アイテム（第２オブジェクトの一例）の報酬内容が共通である。これにより、ゲームシステム１は、どのユーザに対してもフィールド内の同じ場所に同じ種類の通常アイテムを配置するため、どのユーザに対しても平等に通常アイテムの取得の機会を与えることができる。

［第７の実施形態］
次に、本発明の第７の実施形態について説明する。本実施形態に係るゲームシステム１の基本的な構成は、第１の実施形態と同様であるので、本実施形態において特徴的な処理について説明する。本実施形態では、対戦プレイ中にプレイ画面表示されるエフェクト（効果）の処理について説明する。

対戦で利用されるプレイヤキャラクタは、プレイヤキャラクタに基づく特性（プレイヤキャラクタ特性またはプレイヤキャラクタが装備している装備アイテムの特性等）によって、遠方の敵を攻撃可能であったり、広範囲にダメージを与えることが可能であったり、その効果は様々である。プレイヤキャラクタが攻撃したときに、その攻撃に応じたエフェクトがプレイ画面に表示される。エフェクトとは攻撃の特性などに対応する効果をビジュアル化した表示画像（映像）である。図２２は、プレイ画面におけるエフェクトの表示例を示す図である。図示する例では、赤チームのプレイヤキャラクタＰＲ１の攻撃によるエフェクトＥＦ１の表示例と、青チームのプレイヤキャラクタＰＢ１の攻撃によるエフェクトＥＦ２の表示例とを示している。

一般的にこのようなエフェクトの表示を行う場合、その表示態様を短時間で連続的に変化させたり、また、半透明にする処理等を多用するため、処理負荷が高くなる傾向がある。そのため、多数のプレイヤキャラクタが同時に表示されるような場面では、すべてのプレイヤキャラクタのエフェクトを表示することが難しい場合がある。例えば、処理負荷が高くなる（例えばＣＰＵ使用率が１００％を超える）と、描画処理の遅延やコマ落ちなどが発生し、著しく操作感を損なうことになる。また、処理負荷が問題なくとも多数のエフェクトが表示されるとエフェクトにより敵の状況などが見づらくなりゲームの進行が把握しづらくなることも起こり得る。そのため、本実施形態では、表示するエフェクトの数などに制限を設け、優先度（優先設定）に基づいてエフェクトの表示を行う。例えば、表示制御部１１５は、予め設定された優先度に基づいて、エフェクトの表示に制限を設ける。なお、優先設定は共通ではなく、ユーザ情報毎に設けられてもよい。

例えば、優先度として、表示制御部１１５が表示処理を実行するゲーム装置１０（即ち、自ゲーム装置）で操作するプレイヤキャラクタのエフェクトの表示が、他のゲーム装置１０で操作するプレイヤキャラクタのエフェクトの表示より優先されるように設定されている。つまり、表示制御部１１５は、表示処理を実行するゲーム装置１０以外のゲーム装置１０で操作されるプレイヤキャラクタのエフェクトの表示を制限する。これは、ゲーム装置１０で操作するユーザの操作感を確保することを目的として、該ユーザが操作するプレイヤキャラクタのエフェクトの優先度を高くしている。

また、優先度は、プレイヤキャラクタの特性や装備アイテムの特性に基づいてエフェクトの表示が制限されるように設定されてもよい。例えば、プレイヤキャラクタのレアリティ（希少度）または装備アイテムのレアリティに基づいてエフェクトの表示が制限されてもよい。具体的には、表示制御部１１５は、プレイヤキャラクタまたは装備アイテムのレアリティが高いほどエフェクトの表示を優先してもよい。

また、優先度は、プレイヤキャラクタまたは装備アイテムに設定されている期間限定効果に基づく特性に基づいてエフェクトの表示が制限されるように設定されてもよい。期間限定効果とは、限定期間のみ特別な効果が得られるものである。例えば、プレイヤキャラクタや装備アイテムには属性が設定されており、曜日等によって特定の属性のプレイヤキャラクタや装備アイテムの能力が、期間限定効果として高くなる。また、新しくゲームに追加されたキャラクタや装備アイテムは、期間限定効果として、追加後１０日間など一定期間能力が通常より高く設定される。例えば、表示制御部１１５は、期間限定効果に基づく特性が設定されているプレイヤキャラクタまたは装備アイテムのエフェクトの表示を、その限定期間については優先してもよい。

また、他ユーザが操作するプレイヤキャラクタの装備アイテムのうち、自ユーザが所持しているアイテム（或いは、所持したことがあるアイテム）のエフェクトの表示の優先度を下げてもよい。なお、他ユーザが操作するプレイヤキャラクタの装備アイテムのうち、自ユーザが操作するプレイヤキャラクタが装備しているアイテム（或いは、装備したことがあるアイテム）のエフェクトの表示の優先度を下げてもよい。つまり、ユーザが既に知っているアイテムのエフェクトは、該ユーザに知らせる必要度が低いため、優先度を下げてもよい。なお、各ユーザが所持しているアイテム（プレイヤキャラクタに装備可能なアイテム）の情報や装備アイテムとして使用したことがあるアイテムの情報は、アイテムの所持履歴もしくは使用履歴として、ユーザデータ記憶部３５１に記憶されている。

また、自ユーザが所持しているキャラクタ（或いは、所持したことがあるキャラクタ）と同じ種類のキャラクタを他ユーザがプレイヤキャラクタとして操作する場合、その他ユーザが操作するプレイヤキャラクタのエフェクトの表示の優先度を下げてもよい。なお、自ユーザが操作しているキャラクタ（或いは、操作したことがあるキャラクタ）と同じ種類のキャラクタを他ユーザがプレイヤキャラクタとして操作する場合、その他ユーザが操作するプレイヤキャラクタのエフェクトの表示の優先度を下げてもよい。つまり、ユーザが既に知っているキャラクタのエフェクトは、該ユーザに知らせる必要度が低いため、優先度を下げてもよい。なお、各ユーザが所持しているキャラクタ（プレイヤキャラクタとして操作可能なキャラクタ）の情報やプレイヤキャラクタとして操作したことがあるキャラクタの情報は、キャラクタの所持履歴もしくは使用履歴として、ユーザデータ記憶部３５１に記憶されている。

例えば、表示制御部１１５は、表示処理を実行するゲーム装置１０（即ち、該表示制御部１１５を備える自ゲーム装置１０）でユーザの操作可能なプレイヤキャラクタの所持履歴もしくは使用履歴、または該プレイヤキャラクタに装備可能なアイテムの所持履歴もしくは使用履歴に基づいて、該ゲーム装置１０以外のゲーム装置１０（他のゲーム装置１０）で操作されるプレイヤキャラクタのエフェクトの表示を制限してもよい。

次に、表示制御部１１５がエフェクトの表示に制限を設ける場合の具体例について説明する。例えば、表示制御部１１５は、自身が表示処理を実行するゲーム装置１０（即ち、該表示制御部１１５を備える自ゲーム装置１０）の処理負荷に基づいて、上述した優先度を考慮してエフェクトの表示に制限を設ける。具体的には、表示制御部１１５は、自ゲーム装置１０における現在の処理負荷（ＣＰＵの使用率）に基づいて表示可能なエフェクトの数を算出し、その数以下に表示するエフェクトの数を制限してもよい。この算出したエフェクトの数を、複数のユーザの攻撃により同時に表示させる必要があるエフェクトの数が越えた場合、表示制御部１１５は、上述した優先度に従ってエフェクトの表示を制限してもよい。

また、エフェクト毎に処理負荷が大きく異なるような場合には、表示制御部１１５は、自ゲーム装置１０における現在の処理負荷（ＣＰＵの使用率）とエフェクト毎の処理負荷とに基づいて、表示可能なエフェクトを選択して表示させてもよい。例えば、エフェクト毎の処理負荷を示す設定情報が予めアイテムデータ記憶部３５４に記憶されており、その設定情報に基づいて、優先して表示されるエフェクトが決まってもよい。

図２３は、エフェクトの設定情報の一例を示す図である。図示するエフェクトの設定情報は、装備アイテムのエフェクト表示に関係する設定情報の一例を示しており、装備アイテムと、処理負荷と、レアリティ（希少度）と、特別効果期間とが関連付けられている。装備アイテムは、その装備アイテムのアイテムＩＤである。処理負荷は、その装備アイテムによるエフェクトの表示に必要なＣＰＵの処理負荷である。レアリティ（希少度）は、その装備アイテムに設定されているレアリティ（希少度）である。例えば、レアリティ（希少度）は、高い順にＳＳレアリティ、Ｓレアリティ、レアリティとなっており、そのうちのいずれかが各装備アイテムに設定されている。特別効果期間は、期間限定で特別な効果が得られる装備アイテムの場合に、その特別な効果が得られる期間が設定されている。

表示制御部１１５は、自ゲーム装置１０においてエフェクトを表示したときに、処理負荷が１００％未満となるように、必要に応じてエフェクトの表示を制限する。例えば、表示制御部１１５は、エフェクトの表示を制限する場合、レアリティ（希少度）の高い装備アイテムを優先してもよいし、特別効果期間中にある装備アイテムを優先してもよい。なお、表示制御部１１５は、処理負荷が９８％未満や９５％未満などなるようにエフェクトの表示を制限してもよい。

なお、表示制御部１１５は、エフェクトの表示を制限する場合、表示するエフェクトの数の制限ではなく、表示する内容を制限してもよい。例えば、優先度の低いエフェクトに関しては、処理負荷の低いエフェクト（例えば、特別なビジュアルを用いない汎用的なエフェクト）に変更してもよい。

〔第７の実施形態のまとめ〕
以上説明したように、本実施形態に係るゲームシステム１の表示制御部１１５は、チーム内に共通のフィールド内で、チームに属するユーザ情報により識別されるユーザ毎に操作されるプレイヤキャラクタと、該プレイヤキャラクタの対戦相手とが対戦するゲームにおいて、ユーザ毎に操作されるプレイヤキャラクタのそれぞれに関連付けられた特性に基づくエフェクト（効果）を表示させる表示処理を実行する。また、表示制御部１１５は、予め設定された優先度に基づいて、上記エフェクトの表示に制限を設ける。

これにより、ゲームシステム１は、優先度に基づいてエフェクトの表示に制限を設けるため、複数のプレイヤキャラクタによるエフェクト表示を適切に制御することができる。

例えば、表示制御部１１５は、上記表示処理を実行するゲーム装置１０の処理負荷に基づいて、エフェクト（効果）の表示に制限を設ける。これにより、ゲームシステム１は、ゲーム装置１０の処理負荷がオーバーしないように（過負荷とならないように）処理負荷を低減しつつ、優先度の高いエフェクトは表示させるため、複数のプレイヤキャラクタによるエフェクト表示を適切に制御することができる。

また、表示制御部１１５は、上記表示処理を実行するゲーム装置１０（即ち、該表示制御部１１５を備えたゲーム装置１０）以外のゲーム装置１０（即ち、他のゲーム装置１０）で操作されるプレイヤキャラクタのエフェクト（効果）の表示を制限する。これにより、ゲームシステム１は、ユーザ自身が操作するプレイヤキャラクタのエフェクトを該ユーザが操作するゲーム装置１０で優先的に表示させるため、ゲーム装置１０で操作するユーザの操作感を確保することができる。

また、表示制御部１１５は、上記表示処理を実行するゲーム装置１０（即ち、該表示制御部１１５を備えたゲーム装置１０）でユーザの操作可能なプレイヤキャラクタの所持履歴もしくは使用履歴、または該プレイヤキャラクタに装備可能なアイテムの所持履歴もしくは使用履歴に基づいて、該ゲーム装置１０以外のゲーム装置１０（即ち、他のゲーム装置１０）で操作されるプレイヤキャラクタのエフェクト（効果）の表示を制限する。これにより、ゲームシステム１は、ユーザが既に知っているキャラクタやアイテムであるか否かによってエフェクトの表示の優先度を設定できるため、ユーザに知らせる必要度が低いエフェクトの表示よりも、ユーザに知らせる必要度が高いエフェクト（ユーザが未だ見たことがないエフェクト）の表示を優先して表示させることができる。

また、表示制御部１１５は、ユーザ毎に操作されるプレイヤキャラクタのそれぞれに関連付けられた特性に基づいて予め設定された優先度に基づいて、エフェクト（効果）の表示に制限を設ける、これにより、ゲームシステム１は、プレイヤキャラクタの特性によってエフェクトの表示の優先度を設定できるため、優先度を高く設定した特性のプレイヤキャラクタを目立たせることでき、ユーザに対してその特性のキャラクタの入手意欲を起こすことができる。

例えば、ユーザ毎のプレイヤキャラクタのそれぞれに関連付けられた特性は、それぞれのプレイヤキャラクタに関連付けられたアイテムに基づく特性である。これにより、ゲームシステム１は、装備アイテムの特性によってエフェクトの表示の優先度を設定できるため、優先度を高く設定した特性の装備アイテムを目立たせることでき、ユーザに対してその特性のアイテムの入手意欲を起こすことができる。

なお、ユーザ毎のプレイヤキャラクタのそれぞれに関連付けられた特性は、それぞれのプレイヤキャラクタまたはそれぞれのプレイヤキャラクタに関連付けられたアイテムのレアリティ（希少度）に基づく特性であってもよい。これにより、ゲームシステム１は、プレイヤキャラクタのレアリティまたは装備アイテムのレアリティが高いほど、そのエフェクトの表示を優先することができる。よって、例えば見たこともない希少価値の高そうな武器やキャラクタを目立たせることでき、ユーザに対してそれらの武器やキャラクタの入手意欲を起こすことができる。

また、ユーザ毎のプレイヤキャラクタのそれぞれに関連付けられた特性は、それぞれのプレイヤキャラクタまたはそれぞれのプレイヤキャラクタに関連付けられたアイテムに設定されている期間限定効果に基づく特性であってもよい。これにより、ゲームシステム１は、特別な効果が得られる限定期間では、その特別な効果のエフェクトの表示を優先することができる。よって、例えば期間限定で効果のある武器やキャラクタを目立たせることでき、ユーザに対してそれらの武器やキャラクタの入手意欲を起こすことができる。

［変形例］
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成は上述の実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。例えば、上述の第１〜７の実施形態において説明した各構成は、任意に組み合わせることができる。

なお、上記実施形態では、青チームと赤チームとの１対１のチーム対戦の例を説明したが、これに限られるものではなく、３チーム以上の対戦であってもよい。３チーム以上の対戦の場合には、自陣営（チーム）の通常ＮＰＣは、自チーム以外の全てのチームのプレイヤキャラクタから攻撃が可能である。例えば、最も多くの通常ＮＰＣを討伐したチーム、または最も多くのダメージを通常ＮＰＣに与えたチームが、その通常部屋を占拠するチームとなってもよい。また、自陣営（チーム）以外の陣営毎に攻撃対象となる通常ＮＰＣが設定されてもよい。

また、上記実施形態では、チーム対戦型の例を説明したが、これに限られるものではなく、一つのチームが敵のＮＰＣと対戦し、ＮＰＣを討伐する度に、領域やステージを順にクリアしていくゲームに適用してもよい。その場合、例えば、報酬付与部３１７は、フィールド内の同一の領域（例えば、部屋）において所定の条件が満たされる度に、付与するポイントを増加させてもよい。即ち、報酬付与部３１７は、同一の部屋において所定の占拠条件が満たされる度に、付与する報酬の価値を高くしてもよい。また、通常ＮＰＣ制御部１１３は、フィールド内の同一の領域（例えば、部屋）において所定の条件が満たされる度に、該領域においてＮＰＣ（例えば、通常ＮＰＣ）を出現させる時間間隔を減少、またはＮＰＣ（例えば、通常ＮＰＣ）を同時に出現可能な上限数を増加させてもよい。

また、上述のゲーム制御部１１０、またはサーバ制御部３１０の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによりゲーム制御部１１０、またはサーバ制御部３１０としての処理の一部または全部を行ってもよい。ここで、「記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行する」とは、コンピュータシステムにプログラムをインストールすることを含む。ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータシステム」は、インターネットやＷＡＮ、ＬＡＮ、専用回線等の通信回線を含むネットワークを介して接続された複数のコンピュータ装置を含んでもよい。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。このように、プログラムを記憶した記録媒体は、ＣＤ−ＲＯＭ等の非一過性の記録媒体であってもよい。また、記録媒体には、当該プログラムを配信するために配信サーバからアクセス可能な内部または外部に設けられた記録媒体も含まれる。配信サーバの記録媒体に記憶されるプログラムのコードは、端末装置で実行可能な形式のプログラムのコードと異なるものでもよい。すなわち、配信サーバからダウンロードされて端末装置で実行可能な形でインストールができるものであれば、配信サーバで記憶される形式は問わない。なお、プログラムを複数に分割し、それぞれ異なるタイミングでダウンロードした後に端末装置で合体される構成や、分割されたプログラムのそれぞれを配信する配信サーバが異なっていてもよい。さらに「コンピュータ読み取り可能な記録媒体」とは、ネットワークを介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。また、上記プログラムは、上述した機能の一部を実現するためのものであってもよい。さらに、上述した機能をコンピュータシステムに既に記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。

また、上述のゲーム制御部１１０、またはサーバ制御部３１０の一部または全部を、ＬＳＩ（ＬａｒｇｅＳｃａｌｅＩｎｔｅｇｒａｔｉｏｎ）等の集積回路として実現してもよい。上述した各機能は個別にプロセッサ化してもよいし、一部、または全部を集積してプロセッサ化してもよい。また、集積回路化の手法はＬＳＩに限らず専用回路、または汎用プロセッサで実現してもよい。また、半導体技術の進歩によりＬＳＩに代替する集積回路化の技術が出現した場合、当該技術による集積回路を用いてもよい。

また、上述のゲーム制御部１１０の一部の構成を、サーバ制御部３１０が備えてもよい。例えば、ゲームサーバ３０がゲーム処理の大部分を担い、ゲーム装置１０は、ゲームサーバ３０が実行するゲーム処理に基づくゲーム画像の表示とユーザの操作の入力とを担う構成としてもよい。

［付記］
以上の記載から本発明は例えば以下のように把握される。なお、本発明の理解を容易にするために添付図面の参照符号を便宜的に括弧書きにて付記するが、それにより本発明が図示の態様に限定されるものではない。

（付記Ａ１）本発明の一態様に係るゲームシステム（１）は、複数のチームのそれぞれに属するユーザ情報により識別されるユーザ毎の操作に基づいて、前記複数のチームに共通の複数の領域（例えば、部屋）を有するフィールド（ＦＬＤ）内で前記ユーザ情報毎に関連付けられたキャラクタ（Ｐ１）を移動させるキャラクタ移動部（１１２）と、前記ユーザの操作結果が所定の条件（例えば、所定の占拠条件）を満たしたか否かに基づいて、前記領域をいずれのチームに関連付けるか否か（例えば、いずれのチームの占拠とするか）を判定する領域判定部（３１５、Ｓ１００）と、前記領域判定部による判定結果に基づいて、前記複数のチームによる対戦の勝敗を判定する勝敗判定部（３１６、Ｓ１１４）と、を備える。

付記Ａ１の構成によれば、ゲームシステムは、各ユーザが操作することによりフィールド内でプレイヤキャラクタを移動させるチーム対戦型のアクションゲームにおいて、領域（例えば、部屋）を占拠しあうことで勝敗を決するという新たな楽しみを提供することができる。例えば、このゲームシステムは、常に領域の占拠数でどちらのチームが優勢であるかが分かるため、緊張感が途切れることなくユーザにプレイさせることができる。また、１体１の対戦で領域を取り合うゲームと比較した場合、このゲームシステムは、チーム対戦であることから、チームとしての協力プレイや、敵味方の両方に複数のプレイヤキャラクタが登場することなどから、より戦略性の高いゲームを提供することができる。

（付記Ａ２）また、本発明の一態様は、付記Ａ１に記載のゲームシステムであって、前記領域においてＮＰＣ（ノンプレイヤキャラクタ）を制御するＮＰＣ制御部（１１３，３１２）、を備え、前記領域判定部は、前記領域において前記ＮＰＣの討伐状況が前記所定の条件を満たした場合、前記領域をいずれのチームに関連付けるか否かを判定する。

付記Ａ２の構成によれば、ゲームシステムは、フィールド内の複数の領域（例えば、部屋）のそれぞれに出現するＮＰＣ（例えば、通常ＮＰＣまたはボスＮＰＣ）を討伐することで、それぞれの領域を占拠することができるため、各チームの対戦相手を同じ条件とすることができ、公平性を保つことができる。

（付記Ａ３）また、本発明の一態様は、付記Ａ２に記載のゲームシステムであって、前記領域における前記ＮＰＣは、前記複数のチームのうちのいずれか一つのチームに対応している。

付記Ａ３の構成によれば、ゲームシステムは、対戦相手がＮＰＣでありながら、対戦相手のチームと戦っているのと同様の状況とすることができ、ユーザがチーム対戦であることを実感しながらプレイ可能とすることができる。

（付記Ａ４）また、本発明の一態様は、付記Ａ１から付記Ａ３のいずれか一に記載のゲームシステムであって、前記勝敗判定部は、前記領域判定部による判定結果により前記複数のチームのそれぞれに関連付けられた前記領域の数に基づいて、前記複数のチームによる対戦の勝敗を判定する。

付記Ａ４の構成によれば、ゲームシステムは、領域（例えば、部屋）の占拠数でチームの勝敗が決するため、ユーザにとって対戦中の状況も対戦が終了したときの結果も分かりやすい。

（付記Ａ５）また、本発明の一態様は、付記Ａ１から付記Ａ４のいずれか一に記載のゲームシステムであって、前記領域判定部により前記領域が関連付けられたチームまたは該チームに属するユーザ情報により識別されるユーザに対してポイントを付与する報酬付与部（３１７）、を備える。

付記Ａ５の構成によれば、ゲームシステムは、領域（例えば、部屋）を占拠したチームまたはチームのユーザに対してポイントを付与するため、占拠状況だけでない楽しみを付加することができる。例えば、ゲームシステムは、ユーザ毎にポイントを付与する場合、チーム同士の対戦に加えて、チーム内のユーザ同士でも競い合える楽しみをユーザに与えることができる。

（付記Ａ６）また、本発明の一態様は、付記Ａ５に記載のゲームシステムであって、前記報酬付与部は、前記領域判定部により前記領域が関連付けられたチームまたは該チームに属するユーザ情報により識別されるユーザに対して、前記領域に応じたポイントを付与する。

付記Ａ６の構成によれば、ゲームシステムは、占拠した領域（例えば、部屋）によって付与されるポイントが異なるため、例えば、難易度の低い領域を数多く占拠しようと試みるか、或いは、難易度の高い領域を数は少なくとも占拠しようとするかといったことをチームの戦略として選択可能となるため、戦略性の高いゲームを提供できる。

（付記Ａ７）また、本発明の一態様は、付記Ａ５または付記Ａ６に記載のゲームシステムであって、前記領域判定部は、前記複数のチームのいずれかのチームに関連付けられた前記領域において他のチームに属するユーザ情報により識別されるユーザの操作結果により前記所定の条件が満たされた場合、前記領域を該他のチームまたは該他のチームに属するユーザ情報に対して関連付け、前記報酬付与部は、同一の前記領域において前記所定の条件が満たされる度に、付与するポイントを増加させる。

付記Ａ７の構成によれば、ゲームシステムは、同一の領域（例えば、部屋）をチーム同士で占拠しあうことで占拠したときに付与されるポイントが高くなるため、各チームのユーザに対して繰り返し対戦する意欲を高めることができ、白熱したゲーム展開が期待できる。

（付記Ａ８）また、本発明の一態様は、付記Ａ５から付記Ａ７のいずれか一に記載のゲームシステムであって、前記報酬付与部は、前記領域判定部によりチームに関連付けられた領域が多いほど、該チームに領域が関連付けられた際に付与するポイントを増加させる。

付記Ａ８の構成によれば、ゲームシステムは、領域（例えば、部屋）を占拠すればする程、優位にゲームを進められるようにすることができる。

（付記Ａ９）また、本発明の一態様は、付記Ａ５から付記Ａ８のいずれか一に記載のゲームシステムであって、前記勝敗判定部は、前記領域判定部による前記複数の領域のそれぞれに対する判定結果と、前記報酬付与部により各チームまたは該チームに属するユーザ情報により識別されるユーザに対して付与されたポイントとに基づいて、前記複数のチームによる対戦の勝敗を判定する。

付記Ａ９の構成によれば、ゲームシステムは、領域（例えば、部屋）の占拠だけでなくポイントの取得も勝敗に影響することから、どの領域を占拠するかによって勝敗が左右されるため、戦略性の高いゲームを提供できる。

（付記Ａ１０）また、本発明の一態様は、付記Ａ５から付記Ａ９のいずれか一に記載のゲームシステムであって、前記報酬付与部は、前記領域判定部によりチームに関連付けられた前記領域において、該チームに属するユーザ情報により識別されるユーザに対して該ユーザの操作に基づくプレイの進行に有利な効果を発生させる。

付記Ａ１０の構成によれば、ゲームシステムは、領域（例えば、部屋）を占拠すればする程、優位にゲームを進められるようにすることができる。

（付記Ａ１１）また、本発明の一態様は、付記Ａ１から付記Ａ１０のいずれか一に記載のゲームシステムであって、前記キャラクタのそれぞれには、前記ユーザの操作に基づくプレイの進行に影響する特性が設定されている。

付記Ａ１１の構成によれば、ゲームシステムは、キャラクタの特性によって攻撃の種類や威力が変わるとともに、対戦相手の特性との組み合わせによる相性によっても優劣が生じるため、戦略性の高いゲームを提供できる。

（付記Ａ１２）また、本発明の一態様は、コンピュータを、付記Ａ１から付記Ａ１１のいずれか一に記載のゲームシステムとして機能させるためのプログラム。

付記Ａ１２の構成によれば、プログラムは、各ユーザが操作することによりフィールド内でプレイヤキャラクタを移動させるチーム対戦型のアクションゲームにおいて、領域（例えば、部屋）を占拠しあうことで勝敗を決するという新たな楽しみを提供することができる。

（付記Ｂ１）また、本発明の一態様に係るゲームシステム（１）は、チームに属するユーザ情報により識別されるユーザ毎の操作に基づいて、前記チーム内で共通の領域を有するフィールド（ＦＬＤ）内で前記ユーザ情報毎に関連付けられたキャラクタを移動させるキャラクタ移動部（１１２）と、前記領域に所定の時間間隔でＮＰＣ（ノンプレイヤキャラクタ）を出現させるＮＰＣ制御部（１１３）と、前記領域において前記ＮＰＣの討伐状況が所定の条件を満たした場合、前記領域を前記チームに関連付けるか否かを判定する領域判定部（３１５）と、前記領域判定部により前記チームに関連付けられた領域に基づいて、前記チームの勝敗を判定する勝敗判定部（３１６）と、を備える。

付記Ｂ１の構成によれば、ゲームシステムは、ＮＰＣ（例えば、通常ＮＰＣ）が討伐されても所定の時間間隔で復活するため、領域（例えば、通常部屋）の占拠が一人では簡単にはできないようにし、チームでより協力したプレイを必要にすることができる。よって、ゲームシステムは、チーム戦の意識の高いゲームを提供できる。

（付記Ｂ２）また、本発明の一態様は、付記Ｂ１に記載のゲームシステムであって、前記ＮＰＣの討伐状況は、前記領域において出現している前記ＮＰＣの数である。

付記Ｂ２の構成によれば、ゲームシステムは、領域（例えば、通常部屋）に所定の時間間隔で出現するＮＰＣ（例えば、通常ＮＰＣ）の数が所定の条件を満たすことで（例えば、通常ＮＰＣの数が０になることで）、その領域を占拠することができるため、占拠できる条件が分かりやすい。また、チームメンバーと協力することで早く占拠できるため、ユーザがチームで戦っている一体感を得ることができる。

（付記Ｂ３）また、本発明の一態様は、付記Ｂ１または付記Ｂ２に記載のゲームシステムであって、前記ＮＰＣ制御部は、前記領域において、同時に出現中となる前記ＮＰＣが予め設定された上限数となるまでは、所定の時間間隔で出現させる。

付記Ｂ３の構成によれば、ゲームシステムは、領域（例えば、通常部屋）に最初に存在する（出現する）ＮＰＣ（例えば、通常ＮＰＣ）の初期数までは討伐されても復活してくるため、その領域の占拠が一人では簡単にはできないようにし、チームで協力したプレイを必要にすることができる。よって、ゲームシステム１は、チーム戦の意識の高いゲームを提供できる。

（付記Ｂ４）また、本発明の一態様は、付記Ｂ１から付記Ｂ３のいずれか一に記載のゲームシステムであって、前記ＮＰＣ制御部は、前記フィールド内に前記領域が複数ある場合、複数の前記領域毎に、前記ＮＰＣを出現させる時間間隔、または同時に出現中となる前記ＮＰＣの上限数を制御する。

付記Ｂ４の構成によれば、ゲームシステムは、領域（例えば、通常部屋）毎に占拠の難易度を設定することができる。

（付記Ｂ５）また、本発明の一態様は、付記Ｂ１から付記Ｂ４のいずれか一に記載のゲームシステムであって、前記ＮＰＣ制御部は、同一の前記領域において前記所定の条件が満たされる度に、該領域において前記ＮＰＣを出現させる時間間隔を減少、または前記ＮＰＣを同時に出現可能な上限数を増加させる。

付記Ｂ５の構成によれば、ゲームシステムは、同一の領域（例えば、通常部屋）をチーム同士で占拠しあうことでその領域を占拠する難易度が高くなるため、よりチームで協力したプレイが必要となり、白熱したゲーム展開が期待できる。

（付記Ｂ６）また、本発明の一態様は、付記Ｂ１から付記Ｂ５のいずれか一に記載のゲームシステムであって、前記領域判定部により前記領域が関連付けられたチームに報酬を付与する報酬付与部（３１７）、を備える。

付記Ｂ６の構成によれば、ゲームシステムは、ゲームシステム１は、領域（例えば、通常部屋）を占拠したチームまたはチームのユーザに対してポイントを付与するため、占拠状況だけでない楽しみを付加することができる。例えば、ゲームシステム１は、ユーザ毎にポイントを付与する場合、チーム同士の対戦に加えて、チーム内のユーザ同士でも競い合える楽しみをユーザに与えることができる。

（付記Ｂ７）また、本発明の一態様は、付記Ｂ６に記載のゲームシステムであって、前記報酬付与部は、同一の前記領域において前記所定の条件が満たされる度に、付与する報酬の価値を高くする。

付記Ｂ７の構成によれば、ゲームシステムは、同一の領域（例えば、通常部屋）をチーム同士で占拠しあうことで占拠したときに付与されるポイントが高くなるため、各チームのユーザに対して繰り返し対戦する意欲を高めることができ、白熱したゲーム展開が期待できる。

（付記Ｂ８）また、本発明の一態様は、コンピュータを、付記Ｂ１から付記Ｂ７のいずれか一に記載のゲームシステムとして機能させるためのプログラム。

付記Ｂ８の構成によれば、プログラムは、ＮＰＣ（例えば、通常ＮＰＣ）が討伐されても所定の時間間隔で復活するため、領域（例えば、通常部屋）の占拠が一人では簡単にはできないようにし、チームでより協力したプレイを必要にすることができる。よって、プログラムは、チーム戦の意識の高いゲームを提供できる。

（付記Ｃ１）また、本発明の一態様に係るゲームシステム（１）は、複数のチームのそれぞれに属するユーザ情報により識別されるユーザ毎の操作に基づいて、前記複数のチームに共通のフィールド（ＦＬＤ）内で前記ユーザ毎の第１のキャラクタを活動させるキャラクタ制御部（１１２）と、前記フィールド内で第１のＮＰＣ（ノンプレイヤキャラクタ）を制御する第１ＮＰＣ制御部（１１３）と、前記複数のチームのうち第１のチームに属するユーザ情報により識別されるユーザの操作に基づいて、前記第１のチームから前記第１のＮＰＣへの攻撃を制御するとともに、前記複数のチームのうち前記第１のチーム以外の第２のチームから前記第１のＮＰＣへの攻撃を制限する対戦制御部（１１４）と、を備える。

付記Ｃ１の構成によれば、ゲームシステムは、第１のＮＰＣ（例えば、通常ＮＰＣ）に対してはいずれかのチームからしか攻撃することができないため（例えば、青チーム及び赤チームの双方から攻撃できないため）、オンラインゲームにおいて発生し得る、攻撃したはずなのに討伐できなかったという祖語が起きないように抑制することができる。即ち、ゲームシステムは、オンラインゲームで発生し得るタイムラグによる影響を抑制することができる。

（付記Ｃ２）また、本発明の一態様は、付記Ｃ１に記載のゲームシステムであって、前記対戦制御部は、前記第１のチームに属するユーザ情報により識別されるユーザの操作に基づいて、前記第２のチームに属するユーザ情報により識別されるユーザ毎の操作に基づいて活動する第２のキャラクタへの攻撃を制御する場合、前記第１のＮＰＣへの攻撃によって前記第１のＮＰＣへ与える影響に比較して、前記第２のキャラクタへの攻撃によって前記第２のキャラクタへ与える影響が小さくなるように制限する。

付記Ｃ２の構成によれば、ゲームシステムは、ユーザが操作するキャラクタ同士の対戦では、攻撃したはずなのに討伐できなかったという祖語が発生し得るが、攻撃によるダメージを極端に小さくすることで、上記キャラクタ同士の対戦を行うことによるメリットを少なくし、上記キャラクタ同士での対戦の動機となる要因を減らすことができるため、上記の齟齬による影響を抑制することができる。

（付記Ｃ３）また、本発明の一態様は、付記Ｃ２に記載のゲームシステムであって、前記対戦制御部は、前記第２のキャラクタへの攻撃によって前記第２のキャラクタの活動を制限させる。

付記Ｃ３の構成によれば、ゲームシステムは、ユーザが操作するキャラクタ同士の対戦では、対戦相手のキャラクタにダメージを与えるより動きを止めることが目的となるため、攻撃したはずなのに討伐できなかったという祖語が起きるのを抑制できる。

（付記Ｃ４）また、本発明の一態様は、付記Ｃ１から付記Ｃ３のいずれか一に記載のゲームシステムであって、前記第１ＮＰＣ制御部を備える複数の端末装置（１０）と、前記端末装置と通信接続されるサーバ装置（３０）と、を備え、前記第１ＮＰＣ制御部は、前記フィールド内で前記第１のＮＰＣの位置を、前記複数の端末装置毎に制御する。

付記Ｃ４の構成によれば、ゲームシステムは、第１のＮＰＣ（例えば、通常ＮＰＣ）のフィールド内の位置や動き（モーション）、攻撃（技）を発動した場合の効果（エフェクト）など基本的にはリアルタイム性の高いアクションは各ゲーム装置（端末側）で管理するため、通信によるタイムラグによる影響が生じないように抑制することができる。

（付記Ｃ５）また、本発明の一態様は、付記Ｃ４に記載のゲームシステムであって、前記サーバ装置は、前記フィールド内で前記第１のＮＰＣとは異なる第２のＮＰＣを制御する第２ＮＰＣ制御部（３１２）を備え、前記対戦制御部は、前記第１のチームに属するユーザ情報により識別されるユーザの操作に基づいて、前記第１のチームから前記第２のＮＰＣへの攻撃を制御するとともに、前記第２のチームに属するユーザ情報により識別されるユーザの操作に基づいて、前記第２のチームから前記第２のＮＰＣへの攻撃を制御し、前記第２ＮＰＣ制御部は、前記フィールド内で前記第２のＮＰＣの位置を、複数の前記端末装置で同じ位置になるように制御する。

付記Ｃ５の構成によれば、ゲームシステムは、両陣営双方（例えば、青チーム及び赤チームの双方）から攻撃される第２のＮＰＣ（例えば、ボスＮＰＣ）については、各ゲーム装置で攻撃対象の位置が同じになるように同期することができるため、同一攻撃対象に対する複数ユーザの戦闘において整合性を確保できる。

（付記Ｃ６）また、本発明の一態様は、付記Ｃ５に記載のゲームシステムであって、前記第２のＮＰＣを討伐するには、前記第１のＮＰＣを討伐するのに比較して多くの攻撃を要する。

付記Ｃ６の構成によれば、ゲームシステムは、討伐時（最後のとどめ）の攻撃については、攻撃したはずなのに討伐できなかったという祖語が起こり得るものの、それまでの両チームからの攻撃に関してはその順番が入れ替わってとしても大きな祖語とはなり得ないため、討伐するまでの攻撃全体として上記の齟齬による影響を少なくすることができる。

（付記Ｃ７）また、本発明の一態様は、コンピュータを、付記Ｃ１から付記Ｃ６のいずれか一に記載のゲームシステムとして機能させるためのプログラム。

付記Ｃ７の構成によれば、プログラムは、第１のＮＰＣ（例えば、通常ＮＰＣ）に対してはいずれかのチームからしか攻撃することができないため（例えば、青チーム及び赤チームの双方から攻撃できないため）、オンラインゲームにおいて発生し得る、攻撃したはずなのに討伐できなかったという祖語が起きないように抑制することができる。即ち、プログラムは、オンラインゲームで発生し得るタイムラグによる影響を抑制することができる。

（付記Ｄ１）また、本発明の一態様に係るゲームシステム（１）は、チームに属するユーザ情報により識別されるユーザの操作結果が所定の条件を満たしたか否かに基づいて、フィールド（ＦＬＤ）内の複数の領域のそれぞれを前記チームに関連付けるか否か（例えば、いずれのチームの占拠とするか）を判定する領域判定部（３１５、Ｓ１００）と、予め設定された制限時間内における前記領域判定部による判定結果に基づいて、前記チームの勝敗を判定する勝敗判定部（３１６、Ｓ１１４）と、を備え、前記勝敗判定部は、前記複数の領域の前記チームへの関連付け状況に基づいて、前記制限時間に達する前であっても前記チームの勝敗を確定する（Ｓ２０４〜Ｓ２２０）。

付記Ｄ１の構成によれば、ゲームシステムは、チームを構成する複数のユーザがそれぞれのキャラクタを操作して敵キャラクタと戦闘するアクションゲームにおいて、制限時間を待たずして戦況の優劣が明確となり実質的に勝敗が決着してしまうような場合に、その時点で勝敗を確定して終了するため、ユーザにとって無駄なプレイ時間が生じることを抑制できる。

（付記Ｄ２）また、本発明の一態様は、付記Ｄ１に記載のゲームシステムであって、前記勝敗判定部は、前記複数の領域の前記チームへの関連付け状況が予め設定された状況になった場合（例えば、一方のチームによって全部屋占拠された場合）、該状況が所定時間維持されたことを条件として、前記制限時間に達する前であっても前記チームの勝敗を確定する（Ｓ２０４〜Ｓ２２０）。

付記Ｄ２の構成によれば、ゲームシステムは、複数の領域のチームへの関連付け状況が予め設定された状況になった（例えば、一方のチームによって全部屋占拠された）としても、占拠された側のチームに巻き返しのチャンスとなる時間を与えることができる。よって、ゲームシステムは、何らかの要因で一気に攻められて実力を出せずに対戦が終了してしまうような不合理が生じてしまことを抑制できる。

（付記Ｄ３）また、本発明の一態様は、付記Ｄ２に記載のゲームシステムであって、前記勝敗判定部は、前記複数の領域の前記チームへの関連付け状況が予め設定された状況になった回数に応じて、前記所定時間を短縮する（Ｓ２０４、Ｓ２１６）。

付記Ｄ３の構成によれば、ゲームシステムは、例えば、全部屋占拠が繰り返された場合には、１回目の全部屋占拠のときよりも該チームが優勢であることがより確実と考えられるため、占拠された側のチームの巻き返しのチャンスとなる時間を短くし、全部屋占拠した側のチームのユーザにとって無駄なプレイ時間が生じることを抑制することができる。

（付記Ｄ４）また、本発明の一態様は、付記Ｄ３に記載のゲームシステムであって、複数の前記チームによる対戦の場合、前記回数は、チーム毎に計数される。

付記Ｄ４の構成によれば、ゲームシステムは、例えば一方のチームによる全部屋占拠した後に、他方のチームが全部屋占拠し返した場合には、戦況の優劣が明確になっていないと考えられるため、各チームに対して平等に巻き返しのチャンスとなる時間を与えることができる。

（付記Ｄ５）また、本発明の一態様は、付記Ｄ２から付記Ｄ４のいずれか一に記載のゲームシステムであって、前記複数の領域の前記チームへの関連付け状況が予め設定された状況になった場合、前記所定時間となるまでの時間を示す情報を表示させる表示制御部（１１５）、を備える。

付記Ｄ５の構成によれば、ゲームシステムは、対戦プレイ中のユーザに勝敗が確定するまでの時間をカウントダウンなどで提示するため、緊張感を高めることができる。また、ゲームシステムは、勝敗が確定するまでの残り時間をユーザが把握し易くなるため、残り時間で何をするべきかの戦略をユーザが考え易くすることができる。

（付記Ｄ６）また、本発明の一態様は、付記Ｄ２から付記Ｄ５のいずれか一に記載のゲームシステムであって、前記表示制御部は、前記複数の領域の前記チームへの関連付け状況が予め設定された状況になった場合、前記制限時間に達するまでの残時間と前記所定時間とに基づいて、前記所定時間となるまでの時間を示す情報を表示させるか否かを判定する（Ｓ２０６、Ｓ２１４）。

付記Ｄ６の構成によれば、ゲームシステムは、対戦の残り時間がカウントダウンの時間よりも短い場合にはカウントダウンを開始してもカウントダウンが「０」になる前に制限時間により対戦が終了してしまうため、意味のないカウントダウン表示を行わないようにすることができる。

（付記Ｄ７）また、本発明の一態様は、付記Ｄ１から付記Ｄ６のいずれか一に記載のゲームシステムであって、前記チームに属するユーザ情報により識別されるユーザ毎の操作に基づいて、前記ユーザに共通の複数の領域を有するフィールド内で前記ユーザ情報毎に関連付けられたキャラクタを移動させるキャラクタ移動部（１１２）、を備える。

付記Ｄ７の構成によれば、ゲームシステムは、制限時間を待たずして戦況の優劣が明確となり実質的に勝敗が決着してしまうような場合に、その時点で勝敗を確定して終了するため、ユーザが無駄にフィールド内でキャラクタを移動させる時間が生じることを抑制できる。

（付記Ｄ８）また、本発明の一態様は、コンピュータを、付記Ｄ１から付記Ｄ７のいずれか一に記載のゲームシステムとして機能させるためのプログラム。

付記Ｄ８の構成によれば、プログラムは、チームを構成する複数のユーザがそれぞれのキャラクタを操作して敵キャラクタと戦闘するアクションゲームにおいて、制限時間を待たずして戦況の優劣が明確となり実質的に勝敗が決着してしまうような場合に、その時点で勝敗を確定して終了するため、ユーザにとって無駄なプレイ時間が生じることを抑制できる。

（付記Ｅ１）また、本発明の一態様に係るゲームシステム（１）は、チームに属するユーザ情報により識別されるユーザ毎の操作に基づいて、前記チーム内で共通のフィールド（ＦＬＤ）内で前記ユーザ情報毎に関連付けられたキャラクタを活動させるキャラクタ制御部（１１２）と、第１状態（例えば、通常状態）の前記キャラクタについて所定の第１条件が満たされることを条件として該キャラクタを前記第１状態よりも能力が低下した第２状態（例えば、仮死状態）に遷移させ、前記第２状態の前記キャラクタについて所定の第２条件が満たされることを条件として該キャラクタの活動が制限される第３状態（例えば、死亡状態）に遷移させるキャラクタ状態制御部（１１２１、Ｓ３０４、Ｓ３１２）と、前記第２状態の前記キャラクタを、該キャラクタと同じチームに属する他の前記キャラクタに基づいて前記第１状態に復活させる復活制御部（１１２２、Ｓ３１２）と、前記キャラクタ制御部により前記キャラクタが活動した結果に基づいて、前記チームの勝敗を判定する勝敗判定部（３１６、Ｓ１１４）と、を備える。

付記Ｅ１の構成によれば、ゲームシステムは、第１状態（例えば、通常状態）のキャラクタが攻撃を受けて第３状態（例えば、死亡状態）になる前に、同じチームの協力による復活のチャンスがある第２状態（例えば、仮死状態）にすることができる。よって、ゲームシステムは、チーム対戦型のアクションゲームにおいて、チーム内の協力の機会をより多くすることができる。

（付記Ｅ２）また、本発明の一態様は、付記Ｅ１に記載のゲームシステムであって、前記復活制御部は、前記第３状態（例えば、死亡状態）の前記キャラクタを、前記第３状態になってから所定時間が経過することによって前記第１状態（例えば、通常状態）または第２状態（例えば、仮死状態）に遷移させる。

付記Ｅ２の構成によれば、ゲームシステムは、キャラクタが第３状態（例えば、死亡状態）になってもゲームオーバーとなるのではなく引き続きプレイは進行し、一定時間操作が不可となった後に再スタートとなるため、再び対戦プレイに参加してチームに貢献することができる。また、ゲームシステムは、キャラクタが第３状態（例えば、死亡状態）になるとそのキャラクタに対して一定時間操作ができなくなるため、仮死状態のうちになんとか復活させられるようにチーム内で協力する動機付けを与えることができる。

（付記Ｅ３）また、本発明の一態様は、付記Ｅ２に記載のゲームシステムであって、前記復活制御部は、前記第３状態（例えば、死亡状態）の前記キャラクタを前記第１状態（例えば、通常状態）または前記第２状態（例えば、仮死状態）に遷移させる場合、遷移させた前記キャラクタをフィールド内の所定の場所に配置する。

付記Ｅ３の構成によれば、ゲームシステムは、一旦第３状態（例えば、死亡状態）になったキャラクタをスタート部屋からの再スタートさせることで、一定時間操作が不可という時間的なペナルティに加えて、場所的なペナルティも与えることができる。

（付記Ｅ４）また、本発明の一態様は、付記Ｅ１から付記Ｅ３のいずれか一に記載のゲームシステムであって、前記復活制御部は、前記第２状態（例えば、仮死状態）の前記キャラクタを、該キャラクタと同じチームに属する他の前記第１状態（例えば、通常状態）の前記キャラクタとの位置関係に基づいて、前記第１状態に復活させる。

付記Ｅ４の構成によれば、ゲームシステムは、仮死状態のキャラクタを復活させるには、その仮死状態のキャラクタがいる場所に同じチームの他のキャラクタが移動することが必要になるため、チームメンバーが協力して救出する感覚を与えることができる。

（付記Ｅ５）また、本発明の一態様は、付記Ｅ１から付記Ｅ４のいずれか一に記載のゲームシステムであって、前記第３状態（例えば、死亡状態）とは、前記キャラクタの活動が制限された状態であって、且つ前記キャラクタと同じチームに属する他の前記キャラクタに基づいて前記第１状態（例えば、通常状態）に復活することが不可能な状態であることが含まれる。

付記Ｅ５の構成によれば、ゲームシステムは、キャラクタが第３状態（例えば、死亡状態）になると、チーム内の協力では復活不可能となるため、第２状態（例えば、仮死状態）のうちになんとか復活させられるようにチーム内で協力する動機付けを与えることができる。

（付記Ｅ６）また、本発明の一態様は、付記Ｅ５に記載のゲームシステムであって、前記第１状態（例えば、通常状態）よりも能力が低下した前記第２状態（例えば、仮死状態）とは、前記キャラクタの活動が制限された状態であることが含まれる。

付記Ｅ６の構成によれば、ゲームシステムは、キャラクタを第２状態（例えば、仮死状態）に遷移させた場合、そのキャラクタの活動が第１状態（例えば、通常状態）より制限されるため、対戦プレイにおいてチームの戦力が低下することから、その第２状態のプレイヤキャラクタを復活させる動機付けをチームメンバーに与えることができる。

（付記Ｅ７）また、本発明の一態様は、付記Ｅ１から付記Ｅ５のいずれか一に記載のゲームシステムであって、前記第１状態（例えば、通常状態）よりも能力が低下したと前記第２状態（例えば、仮死状態）とは、前記第１状態（例えば、通常状態）よりも前記キャラクタに関連付けられているパラメータの値が前記キャラクタの能力が低下する値に変更された状態であることが含まれる。

付記Ｅ７の構成によれば、ゲームシステムは、キャラクタを第２状態（例えば、仮死状態）に遷移させた場合、そのキャラクタの攻撃力、防御力、及びＨＰなどのパラメータの値が第１状態（例えば、通常状態）より低下するため、対戦プレイにおいてチームの戦力が低下することから、その第２状態（例えば、仮死状態）のキャラクタを復活させる動機付けをチームメンバーに与えることができる。

（付記Ｅ８）また、本発明の一態様は、付記Ｅ１から付記Ｅ７のいずれか一に記載のゲームシステムであって、前記復活制御部は、前記第２状態（例えば、仮死状態）から前記第１状態（例えば、通常状態）に復活させる回数を制限する。

付記Ｅ８の構成によれば、ゲームシステムは、いくらでも復活できることによってプレイの難易度が低下しすぎてしまったり、チーム間の実力差が反映されなくなってしまうことがないように抑制することができる。

（付記Ｅ９）また、本発明の一態様は、付記Ｅ１から付記Ｅ８のいずれか一に記載のゲームシステムであって、第１の端末装置においてユーザの操作に基づいて活動する前記キャラクタが前記第２状態（例えば、仮死状態）である場合、該キャラクタを第２の端末装置において前記第１状態（例えば、通常状態）の前記キャラクタと識別可能な表示態様で表示させる表示制御部（１１５）、を備える。

付記Ｅ９の構成によれば、ゲームシステムは、第２状態（例えば、仮死状態）になったキャラクタを第１状態（例えば、通常状態）のキャラクタに対して容易に区別できるように、プレイ画面に表示させることができる。

（付記Ｅ１０）また、本発明の一態様は、コンピュータを、付記Ｅ１から付記Ｅ９のいずれか一に記載のゲームシステムとして機能させるためのプログラム。

付記Ｅ１０の構成によれば、プログラムは、第１状態（例えば、通常状態）のキャラクタが攻撃を受けて第３状態（例えば、死亡状態）になる前に、同じチームの協力による復活のチャンスがある第２状態（例えば、仮死状態）にすることができる。よって、プログラムは、チーム対戦型のアクションゲームにおいて、チーム内の協力の機会をより多くすることができる。

（付記Ｆ１）また、本発明の一態様に係るゲームシステム（１）は、チームに属するユーザ情報により識別されるユーザ毎の操作に基づいて、前記チーム内で共通のフィールド（ＦＬＤ）内を、前記ユーザ情報毎に関連付けられたキャラクタを移動させるキャラクタ移動部（１１２）と、前記フィールド内に配置された第１オブジェクト（例えば、宝箱アイテム）を取得する操作がいずれかの前記ユーザにより行われた場合、前記チームに属するユーザ情報により識別される各ユーザに対してユーザ毎に選択された報酬（例えば、アイテム）を付与する報酬付与部（３１７、Ｓ４０８）と、を備える。

付記Ｆ１の構成によれば、ゲームシステムは、フィールド内に存在する複数の第１オブジェクト（例えば、宝箱アイテム）をチーム内のユーザで分担して取得することができるため、チーム対戦型のアクションゲームにおいて、チーム内の協力の機会をより多くすることができる。

（付記Ｆ２）また、本発明の一態様は、付記Ｆ１に記載のゲームシステムであって、前記報酬付与部が前記チームに属するユーザ情報により識別される各ユーザに付与したユーザ毎の報酬の内容（例えば、アイテムの種類）を表示させる第１表示制御部（１１５、Ｓ４１０）、を備える。

付記Ｆ２の構成によれば、ゲームシステムは、チーム内の各ユーザに付与された報酬の内容が分かるので、チーム内のコミュニケーションのきっかけにすることができる。

（付記Ｆ３）また、本発明の一態様は、付記Ｆ２に記載のゲームシステムであって、前記第１表示制御部は、前記フィールド内に配置された前記第１オブジェクト（例えば、宝箱アイテム）を報酬内容（例えば、アイテムの種類）が識別不可能な表示態様で表示させる。

付記Ｆ３の構成によれば、ゲームシステムは、第１オブジェクト（例えば、宝箱アイテム）を取得した後に報酬内容が分かること、即ち報酬内容が取得前に分からないことを示唆するとともに、分からないことにより、取得する際の期待感を高めることができる。

（付記Ｆ４）また、本発明の一態様は、付記Ｆ１から付記Ｆ３のいずれか一に記載のゲームシステムであって、前記報酬付与部は、前記キャラクタと第１オブジェクト（例えば、宝箱アイテム）との位置関係に基づいて前記報酬（例えば、アイテム）を付与する。

付記Ｆ４の構成によれば、ゲームシステムは、フィールド内に存在する複数の第１オブジェクト（例えば、宝箱アイテム）のそれぞれに対してチーム内のユーザが分担して移動させることで、効率よくユーザが報酬（例えば、アイテム）を取得することができる。

（付記Ｆ５）また、本発明の一態様は、付記Ｆ１から付記Ｆ４のいずれか一に記載のゲームシステムであって、前記報酬付与部は、いずれかの前記ユーザの操作により取得済みとなった前記第１オブジェクトを、前記チームに属するユーザ情報により識別されるいずれのユーザに対しても取得対象から除外する。

付記Ｆ５の構成によれば、ゲームシステムは、同じチーム内の複数のユーザで第１オブジェクト（例えば、宝箱アイテム）を重複して取得することができないため、価値の高い報酬（例えば、アイテム）をユーザに付与しすぎないようにすることができる。

（付記Ｆ６）また、本発明の一態様は、付記Ｆ１から付記Ｆ５のいずれか一に記載のゲームシステムであって、前記フィールド内には、前記第１オブジェクトと異なる第２オブジェクト（例えば、通常アイテム）が配置されており、前記報酬付与部は、前記フィールド内に配置された第２オブジェクトを取得する操作がいずれかの前記ユーザにより行われた場合、該ユーザに対して報酬（例えば、アイテム）を付与するとともに、該第２オブジェクト（例えば、通常アイテム）を取得する操作が他の前記ユーザにより行われた場合、該他の前記ユーザに対して報酬（例えば、アイテム）を付与する（Ｓ４０４）。

付記Ｆ６の構成によれば、ゲームシステムは、あるユーザが取得した第２オブジェクト（例えば、通常アイテム）がチームに関係なく他のユーザも取得可能であるため、どのユーザに対しても平等に第２オブジェクトの取得の機会を与えることができる。また、ゲームシステム１は、いつどこで第２オブジェクトを取得するか（例えば、ＨＰを回復させるか）などの戦略をユーザ毎に立てられるようにすることができる。

（付記Ｆ７）また、本発明の一態様は、付記Ｆ６のいずれか一に記載のゲームシステムであって、前記フィールド内に配置された前記第２オブジェクト（例えば、通常アイテム）の配置情報は前記ユーザ情報毎に関連付けられており、前記ユーザ情報毎に関連付けられた配置情報によって特定される前記第２オブジェクトの配置位置が共通である。

付記Ｆ７の構成によれば、ゲームシステムは、どのユーザに対してもフィールド内の同じ場所に第２オブジェクト（例えば、通常アイテム）を配置するため、どのユーザに対しても平等に第２オブジェクトの取得の機会を与えることができる。

（付記Ｆ８）また、本発明の一態様は、付記Ｆ７のいずれか一に記載のゲームシステムであって、前記ユーザ情報毎に関連付けられた配置情報によって特定される前記第２オブジェクトの報酬内容が共通である。

付記Ｆ８の構成によれば、ゲームシステムは、どのユーザに対してもフィールド内の同じ場所に同じ種類の第２オブジェクト（例えば、通常アイテム）を配置するため、どのユーザに対しても平等に第２オブジェクトの取得の機会を与えることができる。

（付記Ｆ９）また、本発明の一態様は、付記Ｆ６または付記Ｆ７に記載のゲームシステムであって、前記フィールド内に配置された前記第２オブジェクト（例えば、通常アイテム）を報酬内容（例えば、アイテムの種類）が識別可能な表示態様で表示させる第２表示制御部（１１５）、を備える。

付記Ｆ９の構成によれば、ゲームシステムは、付与される報酬の内容をユーザが事前に確認した上で第２オブジェクト（例えば、通常アイテム）を取得可能にできる。例えば、第２オブジェクトは、ＨＰを回復するアイテムなどのように、その場で消費されるものが多い。そのため、ユーザは、付与される報酬の内容を事前に確認した上で、必要に応じて第２オブジェクトを取得するか否かを判断できる。

（付記Ｆ１０）また、本発明の一態様は、コンピュータを、付記Ｆ１から付記Ｆ３のいずれか一に記載のゲームシステムとして機能させるためのプログラム。

付記Ｆ１０の構成によれば、プログラムは、フィールド内に存在する複数の第１オブジェクト（例えば、宝箱アイテム）をチーム内のユーザで分担して取得することができるため、チーム対戦型のアクションゲームにおいて、チーム内の協力の機会をより多くすることができる。

（付記Ｇ１）また、本発明の一態様に係るゲームシステム（１）は、チーム内に共通のフィールド（ＦＬＤ）内で、前記チームに属するユーザ情報により識別されるユーザ毎に操作されるキャラクタと、該キャラクタの対戦相手とが対戦するゲームにおいて、前記ユーザ毎に操作されるキャラクタのそれぞれに関連付けられた特性に基づく効果を表示させる表示処理を実行する表示制御部（１１５）、を備え、前記表示制御部は、予め設定された優先度に基づいて、前記効果の表示に制限を設ける。

付記Ｇ１の構成によれば、ゲームシステムは、優先度に基づいてエフェクト（効果）の表示に制限を設けるため、複数のキャラクタによるエフェクト表示を適切に制御することができる。

（付記Ｇ２）また、本発明の一態様は、付記Ｇ１に記載のゲームシステムであって、前記表示制御部を備えた端末装置（１０）と、前記端末装置と通信接続されるサーバ装置（３０）と、を備え、前記表示制御部は、前記表示処理を実行する端末装置の処理負荷に基づいて、前記効果の表示に制限を設ける。

付記Ｇ２の構成によれば、ゲームシステムは、端末装置の処理負荷がオーバーしないように（過負荷とならないように）処理負荷を低減しつつ、優先度の高いエフェクト（効果）は表示させるため、複数のキャラクタによるエフェクト表示を適切に制御することができる。

（付記Ｇ３）また、本発明の一態様は、付記Ｇ１または付記Ｇ２に記載のゲームシステムであって、前記端末装置を複数備え、前記表示制御部は、前記表示処理を実行する端末装置以外の端末装置で操作されるキャラクタの前記効果の表示を制限する。

付記Ｇ３の構成によれば、ゲームシステムは、ユーザ自身が操作するキャラクタのエフェクト（効果）を該ユーザが操作する端末装置で優先的に表示させるため、端末装置で操作するユーザの操作感を確保することができる。

（付記Ｇ４）また、本発明の一態様は、付記Ｇ３に記載のゲームシステムであって、前記表示制御部は、前記表示処理を実行する端末装置で前記ユーザの操作可能なキャラクタの所持履歴もしくは使用履歴、または該キャラクタに装備可能なアイテムの所持履歴もしくは使用履歴に基づいて、該端末装置以外の端末装置で操作されるキャラクタの前記効果の表示を制限する。

付記Ｇ４の構成によれば、ゲームシステムは、ユーザが既に知っているキャラクタやアイテムであるか否かによってエフェクト（効果）の表示の優先度を設定できるため、ユーザに知らせる必要度が低いエフェクトの表示よりも、ユーザに知らせる必要度が高いエフェクト（ユーザが未だ見たことがないエフェクト）の表示を優先して表示させることができる。

（付記Ｇ５）また、本発明の一態様は、付記Ｇ１から付記Ｇ４のいずれか一に記載のゲームシステムであって、前記表示制御部は、前記ユーザ毎に操作されるキャラクタのそれぞれに関連付けられた特性に基づいて予め設定された優先度に基づいて、前記効果の表示を制限を設ける。

付記Ｇ５の構成によれば、ゲームシステムは、プレイヤキャラクタの特性によってエフェクト（効果）の表示の優先度を設定できるため、優先度を高く設定した特性のプレイヤキャラクタを目立たせることでき、ユーザに対してその特性のキャラクタの入手意欲を起こすことができる。

（付記Ｇ６）また、本発明の一態様は、付記Ｇ１から付記Ｇ５のいずれか一に記載のゲームシステムであって、前記ユーザ毎のキャラクタのそれぞれに関連付けられた特性は、それぞれのキャラクタに関連付けられたアイテムに基づく。

付記Ｇ６の構成によれば、ゲームシステムは、装備アイテムの特性によってエフェクト（効果）の表示の優先度を設定できるため、優先度を高く設定した特性の装備アイテムを目立たせることでき、ユーザに対してその特性のアイテムの入手意欲を起こすことができる。

（付記Ｇ７）また、本発明の一態様は、付記Ｇ１から付記Ｇ５のいずれか一に記載のゲームシステムであって、前記ユーザ毎のキャラクタのそれぞれに関連付けられた特性は、それぞれのキャラクタまたはそれぞれのキャラクタに関連付けられたアイテムの希少度に基づく。

付記Ｇ７の構成によれば、ゲームシステムは、キャラクタのレアリティまたはアイテムのレアリティが高いほど、そのエフェクトの表示を優先することができる。よって、例えば見たこともない希少価値の高そうな武器やキャラクタを目立たせることでき、ユーザに対してそれらの武器やキャラクタの入手意欲を起こすことができる。

（付記Ｇ８）また、本発明の一態様は、付記Ｇ１から付記Ｇ５のいずれか一に記載のゲームシステムであって、前記ユーザ毎のキャラクタのそれぞれに関連付けられた特性は、それぞれのキャラクタまたはそれぞれのキャラクタに関連付けられたアイテムに設定されている期間限定効果に基づく。

付記Ｇ８の構成によれば、ゲームシステムは、特別な効果が得られる限定期間では、その特別な効果のエフェクトの表示を優先することができる。よって、例えば期間限定で効果のある武器やキャラクタを目立たせることでき、ユーザに対してそれらの武器やキャラクタの入手意欲を起こすことができる。

（付記Ｇ９）また、本発明の一態様は、コンピュータを、付記Ｇ１から付記Ｇ８のいずれか一に記載のゲームシステムとして機能させるためのプログラム。

付記Ｇ９の構成によれば、プログラムは、優先度に基づいてエフェクト（効果）の表示に制限を設けるため、複数のキャラクタによるエフェクト表示を適切に制御することができる。

１ゲームシステム、１０ゲーム装置、１１ＣＰＵ、１２通信部、１３入力部、１４表示部、１５記憶部、３０ゲームサーバ、３１ＣＰＵ、３２通信部、３５記憶部、１１０ゲーム制御部、１１１サーバ制御情報取得部、１１２キャラクタ制御部、１１３通常ＮＰＣ制御部、１１４対戦制御部、１１５表示制御部、３１０サーバ制御部、３１１端末制御情報取得部、３１２ボスＮＰＣ制御部、３１３通常ＮＰＣ状態同期部、３１４プレイヤキャラクタ同期部、３１５占拠判定部、３１６勝敗判定部、３１７報酬付与部、３５１ユーザデータ記憶部、３５２チームデータ記憶部、３５３キャラクタデータ記憶部、３５４アイテムデータ記憶部、３５５所持データ記憶部

Claims

チームに属するユーザ情報により識別されるユーザ毎の操作に基づいて、前記チーム内に共通のフィールド内で前記ユーザ情報毎に関連付けられたキャラクタを活動させるキャラクタ制御部と、
第１状態の前記キャラクタについて所定の第１条件が満たされることを条件として該キャラクタを前記第１状態よりも能力が低下した第２状態に遷移させ、前記第２状態の前記キャラクタについて所定の第２条件が満たされることを条件として該キャラクタの活動が制限される第３状態に遷移させるキャラクタ状態制御部と、
前記第２状態の前記キャラクタを、該キャラクタと同じチームに属する他の前記キャラクタに基づいて前記第１状態に復活させる復活制御部と、
前記キャラクタ制御部により前記キャラクタが活動した結果に基づいて、前記チームの勝敗を判定する勝敗判定部と、
を備えるゲームシステム。
前記復活制御部は、
前記第３状態の前記キャラクタを、前記第３状態になってから所定時間が経過することによって前記第１状態または前記第２状態に遷移させる、
請求項１に記載のゲームシステム。
前記復活制御部は、
前記第３状態の前記キャラクタを前記第１状態または前記第２状態に遷移させる場合、遷移させた前記キャラクタをフィールド内の所定の場所に配置する、
請求項２に記載のゲームシステム。
前記復活制御部は、
前記第２状態の前記キャラクタを、該キャラクタと同じチームに属する前記第１状態の前記キャラクタとの位置関係に基づいて、前記第１状態に復活させる、
請求項１から請求項３のいずれか一項に記載のゲームシステム。
前記第３状態とは、前記キャラクタの活動が制限された状態であって、且つ前記キャラクタと同じチームに属する他の前記キャラクタに基づいて前記第１状態に復活することが不可能な状態であることが含まれる、
請求項１から請求項４のいずれか一項に記載のゲームシステム。
前記第１状態よりも能力が低下した前記第２状態とは、前記キャラクタの活動が制限された状態であることが含まれる、
請求項５に記載のゲームシステム。
前記第１状態よりも能力が低下した前記第２状態とは、前記第１状態よりも前記キャラクタに関連付けられているパラメータの値が前記キャラクタの能力が低下する値に変更された状態であることが含まれる、
請求項１から請求項５のいずれか一項に記載のゲームシステム。
前記復活制御部は、
前記第２状態から前記第１状態に復活させる回数を制限する、
請求項１から請求項７のいずれか一項に記載のゲームシステム。
第１の端末装置においてユーザの操作に基づいて活動する前記キャラクタが前記第２状態である場合、該キャラクタを第２の端末装置において前記第１状態の前記キャラクタと識別可能な表示態様で表示させる表示制御部、
を備える請求項１から請求項８のいずれか一項に記載のゲームシステム。
コンピュータを、請求項１から請求項９のいずれか一項に記載のゲームシステムとして機能させるためのプログラム。