JP7083979B2 - ゲームを提供するプログラム、方法、装置およびシステム - Google Patents

Description

本発明は、ゲームを提供するプログラム、方法、装置およびシステムに関する。

複数のユーザが各々の操作するキャラクタを１つの領域内において対戦させるオンラインの対戦ゲームが知られている。通常、この種の対戦ゲームでは、同時に対戦するキャラクタ数に応じて、対戦を行う領域の広さを変える必要がある。この領域の広さが適切でなく、キャラクタが過密になると、ゲームの状況が理解し辛くなり、逆に、キャラクタが過疎になると、対戦が間延びする等、ゲームのプレイ感覚や進行に悪影響を与える。そのため、できる限りキャラクタの数に応じた領域の広さを確保するのが好ましい。

しかしながら、同時に対戦するキャラクタの数が例えば１００体といった多数である場合には、キャラクタの過密・過疎の発生を防止するのが困難である。すなわち、キャラクタの数が多い場合には、対戦を行わせる領域を広くする必要があるが、領域を広くすると、どうしてもキャラクタが過密になる部分と、過疎になる部分が生じる可能性が高まる。そして、過疎な部分では、キャラクタが対戦相手が現れるのを長時間待たされる問題が発生する。

特開２００６－１６６９３３号公報

対戦ゲームの分野に関しては、対戦までの待ち時間を減らすことを目的とした技術が開示されている。例えば特許文献１では、麻雀のトーナメント戦において、早く終了した者同士で次の回戦のマッチングを行うことにより回戦の間の待ち時間を減らしている。しかし、この特許文献１の技術は、トーナメント戦には適用可能であるが、多数のキャラクタ同士が対戦するようなゲームには適用することができない問題がある。

この発明は、以上の事情に鑑みてなされたものであり、その目的は、複数のキャラクタにより進めるゲームにおいてキャラクタの数の調整を可能にし、かつ、キャラクタの過疎・過密の問題を解決することにある。

本発明の一態様であるプログラムは、複数のキャラクタにより進行するゲームにおいて、コンピュータを、複数の領域のいずれかの領域において、前記ゲームに係るキャラクタを当該キャラクタに対応付けられた端末から取得される操作情報に基づいて制御する第１制御部と、前記複数の領域における前記キャラクタの状況に基づいて、前記複数の領域における１の領域と他の領域とを連結する第２制御部として機能させることを特徴とする。

本発明の一態様であるゲーム装置は、複数のキャラクタによりゲームを進行させるゲーム装置において、複数の領域のいずれかの領域において、前記ゲームに係るキャラクタを当該キャラクタに対応付けられた端末から取得される操作情報に基づいて制御する第１制御部と、前記複数の領域における前記キャラクタの状況に基づいて、前記複数の領域における１の領域と他の領域とを連結する第２制御部とを有することを特徴とする。

本発明の一態様であるゲームシステムは、複数のキャラクタによりゲームを進行させるゲームシステムにおいて、複数のユーザにより操作される複数の端末と、前記複数のユーザによる前記複数の端末に対する操作情報を受信するサーバとを有し、前記サーバが、複数の領域のいずれかの領域において、前記ゲームに係るキャラクタを当該キャラクタに対応付けられた端末から取得される操作情報に基づいて制御する第１制御部と、前記複数の領域における前記キャラクタの状況に基づいて、前記複数の領域における１の領域と他の領域とを連結する第２制御部とを有することを特徴とする。

本発明の一態様であるゲーム制御方法は、複数のキャラクタによりゲームを進行させる方法において、コンピュータが、複数の領域のいずれかの領域において、前記ゲームに係るキャラクタを当該キャラクタに対応付けられた端末から取得される操作情報に基づいて制御する第１制御と、前記複数の領域における前記キャラクタの状況に基づいて、前記複数の領域における１の領域と他の領域とを連結する第２制御とを実行することを特徴とする。

本発明の一実施形態であるゲームシステムの構成を示すブロック図である。 同ゲームシステムにおけるクラウドサーバの構成を示すブロック図である。 同ゲームシステムにおける端末の構成を示すブロック図である。 同ゲームシステムにおいて提供するフィールドの例を示す図である。 同ゲームシステムにおいて提供するフィールドの例を示す図である。 同ゲームシステムにおいて連結対象となるフィールドの例を示す図である。 同ゲームシステムにおいて連結されたフィールドの例を示す図である。 同クラウドサーバの機能構成を示すブロック図である。 同クラウドサーバが管理するユーザ情報テーブルを示す図である。 同クラウドサーバが管理するフィールド情報テーブルを示す図である。 同クラウドサーバが管理する連結テーブルを示す図である。 同クラウドサーバにおける連結制御部および移動制御部の処理を示すタイムチャートである。 同クラウドサーバが実行するサーバプログラムのメインフローを示すフローチャートである。 同サーバプログラムの実行により端末に表示される待機画面を示す図である。 同サーバプログラムにおけるフィールド内処理を示すフローチャートである。 同フィールド内処理におけるフィールド消滅制御を示すフローチャートである。 同フィールド消滅制御において端末に表示されるフィールドの画像を示す図である。 同実施形態の変形例であるゲームシステムの構成を示すブロック図である。 同実施形態の変形例であるゲームシステムの構成を示すブロック図である。 同実施形態の変形例において端末に表示されるフィールドの画像の例を示す図である。 同実施形態の変形例において端末に表示されるフィールドの画像の例を示す図である。 同実施形態の変形例におけるフィールドの連結の態様を示す図である。

以下、本発明を実施するための形態について図面を参照して説明する。なお、各図において、各部の寸法及び縮尺は、実際のものと適宜に異ならせてある。また、以下に述べる実施の形態は、本発明の好適な具体例であるから、技術的に好ましい種々の限定が付されているが、本発明の範囲は、以下の説明において特に本発明を限定する旨の記載がない限り、これらの形態に限られるものではない。

［Ａ．実施形態］
［１．ゲームシステムのハードウェア構成］
図１は、本発明の一実施形態であるゲームシステム１のハードウェア構成を示すブロック図である。このゲームシステム１は、クラウドサーバ１０と、このクラウドサーバ１０にインターネット等のネットワークＮＷを介して接続される複数の端末３０－１～３０－Ｍ（Ｍは２以上の整数）とを含む。クラウドサーバ１０は、端末３０－１～３０－Ｍを操作するユーザに対してゲームを提供するサーバである。端末３０－１～３０－Ｍは、ゲームを進行させるユーザが操作する端末である。なお、以下において、端末３０－１～３０－Ｍを区別する必要がない場合は、端末３０と総称する。

図２はクラウドサーバ１０の構成例を示すブロック図である。図２において、制御部１１と、記憶部１２と、通信部１３は、クラウドサーバ１０が提供する仮想的なコンピュータリソースである。制御部１１は、演算処理を行う手段であり、ＣＰＵ（Central Processing Unit）に相当する。記憶部１２は、ＲＡＭ（Random Access Memory）等の揮発性メモリと、ハードディスク等の不揮発性メモリとを含む。揮発性メモリは、制御部１１の作業領域として機能する。不揮発性メモリには、ユーザにゲームを提供するアプリケーションプログラムであるサーバプログラムＰＧｓ等の各種の情報が記憶される。

図３は端末３０の構成例を示すブロック図である。この例において、端末３０は、パーソナルコンピュータであり、端末３０の各部を制御する制御部３１と、各種情報を記憶する記憶部３２と、端末３０の外部に存在する外部装置との通信を行うための通信部３３と、端末３０のユーザの操作を受け付けるための操作部３４と、各種画像を表示する表示部３５とを備える。なお、端末３０は、スマートフォン、タブレット等の携帯電子機器であってもよい。また、端末３０は、店舗据置き型業務用機であってもよい。記憶部１２は、揮発性メモリと、不揮発性メモリとを含む。揮発性メモリは、制御部３１の作業領域として機能する。不揮発性メモリには、ゲームの状況を示す画像を表示部３５に表示し、ゲームを進行させる操作情報をユーザから受け取るアプリケーションプログラムである端末プログラムＰＧｔ等の各種の情報が記憶される。

［２．ゲームの概要］
本実施形態においてクラウドサーバ１０は、複数の端末３０を操作する複数のユーザに対し、複数のキャラクタが対戦する対戦ゲームを提供する。この対戦ゲームにおいて、爆弾などのトラップによって倒されたキャラクタは退場となり、最後まで生き残ったキャラクタが勝利となる。本実施形態では、例えば１００体等、多数のキャラクタが同時に対戦可能なゲームを提供する。

本実施形態では、１００体のキャラクタに対応するような大きな１つの領域を設けずに、複数の小領域を対戦の場として提供する。以下、この小領域をフィールドという。このフィールド内で限られた数のキャラクタによる対戦を行わせることで、キャラクタの過密や過疎を防ぐ。さらに各フィールドは周期的に互いに往来可能とすることで、１つの大きな領域の一部においてプレイする感覚をユーザに与えつつ大人数で行うプレイ感覚をもユーザに与える。

図４は本実施形態において提供されるフィールドの一例であるフィールドＦＤを示す図である。図４に示すフィールドＦＤ内には４つのキャラクタＣが所在している。これらのキャラクタＣは、キャラクタＣごとに別々のユーザの端末３０から取得される操作情報により制御される。フィールドＦＤの状況は各キャラクタＣに対する操作情報の送信元である端末３０の画面に表示される。ユーザは、端末３０の画面に表示されたフィールドＦＤの状況を把握しつつキャラクタＣに対する操作情報を送信し、キャラクタＣをフィールドＦＤ内の他のキャラクタＣと対戦させる。

フィールドＦＤには、キャラクタＣが移動不可能な場所であるブロックがある。このブロックには、ソフトブロックＳＢとハードブロックＨＢがある。ソフトブロックＳＢは、爆弾等のアイテムにより破壊し消滅させると移動可能になる。これに対し、ハードブロックＨＢは消滅させることができない。すなわち、ハードブロックＨＢは、どのようにしてもキャラクタＣを移動させることができない部分となる。フィールドＦＤでは、ハードブロックＨＢがその外周を覆うように配置され、フィールドＦＤの外部との境界を構成している。基本的にはそのフィールドＦＤの外へキャラクタＣを移動させることができないようになっている。そのため、ユーザはこのフィールドＦＤ内でキャラクタＣを他のキャラクタＣと対戦させざるを得ない。

図４に示す例では、１人のユーザから見ると、最初は対戦相手は３人しか見えないことになるが、実際にはこのようなフィールドＦＤが複数同時に生成され、別のフィールドＦＤには別のユーザのキャラクタＣが配置されることになり、合計１００体のキャラクタＣは同時に対戦を行っている。１つのフィールドに４つキャラクタが配置されるとするならば、このようなフィールドＦＤが２５フィールド（＝１００／４）同時に存在することになる。

本実施形態では、対戦開始の際に、複数のフィールドに均等な数のキャラクタを配置することで、キャラクタの過密、過疎状態を回避する。

しかし、このような態様だけでは単に小さな対戦が複数あるだけであり、１００人のユーザ間の対戦にはならない。１００人のユーザ間の対戦を行うためには、各ユーザのキャラクタをフィールドの枠を超えて対戦させる仕組みが必要になる。本実施形態では、ゲートの開閉制御とフィールドの連結制御により、この仕組みを実現する。

まず、ゲートの開閉制御について説明する。図４において、フィールドＦＤの境界をなす各辺には、キャラクタの移動可否を制御するゲートＧが設けられている。図４に示すように、ゲートＧが閉じた状態では、ゲートＧのある部分は移動不可である。この場合、キャラクタＣはゲートＧの先へも移動することができない。それとは逆に、図５では、ゲートＧが開いた状態となっている。この状態において、キャラクタＣはゲートＧを介して隣のフィールドＦＤへ移動可能となる。本実施形態では、定期的にゲートＧの開閉を繰り返す。例えばゲートＧが閉じた状態を３０秒間継続し、次にゲートが開いた状態を５秒間継続し、再びゲートが閉じた状態を３０秒間継続する、という具合にゲートの開閉を定期的に繰り返す。

次にフィールドの連結制御について説明する。図６には、３つのフィールドＦＤ１～ＦＤ３が示されている。実際にはもっと数多くのフィールドが存在することになるが、説明の簡略化のため、ここではフィールドを３つとして説明する。

図６ではフィールドＦＤ１～ＦＤ３は連結されていない。本実施形態では、各ゲートＧが閉状態となっている期間内に、１のフィールドと他のフィールドとを連結する。この例では、フィールドＦＤ１の境界の一部である右辺およびこの右辺にあるゲートＧと、フィールドＦＤ２の境界の一部である左辺およびこの左辺にあるゲートＧとを共有させることによりフィールドＦＤ１およびＦＤ２を連結する。また、この例では、フィールドＦＤ１の境界の一部である下辺およびこの下辺にあるゲートＧと、フィールドＦＤ３の境界の一部である上辺およびこの上辺にあるゲートＧとを共有させることによりフィールドＦＤ１およびＦＤ３を連結する。そして、ゲートを開くタイミングになると、フィールド間の連結部にあるゲートＧを開状態にする。

図７はフィールド間の連結が行われ、連結部のゲートＧが開状態とされた後のフィールドＦＤ１～ＦＤ３を示す図である。図７の状態では、フィールドＦＤ１およびＦＤ２間と、フィールドＦＤ１およびＦＤ３間のキャラクタＣの往来が可能である。このようにキャラクタＣを往来可能とすることで、１つのフィールド内で敵キャラクタを倒しきったキャラクタＣなどは別のフィールドへ移動し、新たなキャラクタＣと対戦を行うことが可能となる。本実施形態では、ゲートＧの開閉切り換えのタイミングはすべてのフィールドＦＤで同じであるため、キャラクタＣはゲートＧが開いたタイミングでフィールドＦＤを往来可能となる。

フィールドＦＤ内のハードブロックＨＢ、ソフトブロックＳＢの配置は、複数のフィールド間で異なっている。フィールドＦＤのサイズは、同じであってもよく、フィールド間で異なってもよい。本実施形態では、説明を簡単にするため、各フィールドＦＤのサイズは同じであるものとする。

キャラクタＣを操作するユーザの端末３０には、キャラクタＣが所在する１つのフィールドＦＤが画面いっぱいに表示されるため、画面に他のフィールドＦＤは表示されない。このため、ユーザは、キャラクタＣの移動先のフィールドＦＤの状況をキャラクタＣが移動して初めて知ることになる。

対戦ゲームが進行すると、キャラクタ数が減ってゆき、キャラクタＣが所在するフィールドＦＤも減って行く。そこで、本実施形態では、キャラクタ数が所定数以下になった場合、あるいはキャラクタＣが所在するフィールド数が所定数以下になった場合に、残存しているキャラクタＣを１つのフィールドＦＤに集め、最終決戦を行わせる。
以上が本実施形態により提供されるゲームの概要である。

［３．クラウドサーバの機能構成］
図８は制御部１１がサーバプログラムＰＧｓを実行することにより実現される諸機能を示すブロック図である。なお、図８では、制御部１１の諸機能の理解を容易にするため、記憶部１２と記憶部１２に記憶される各種の情報が制御部１１とともに示されている。本実施形態において、サーバプログラムＰＧｓは、制御部１１をユーザ情報管理部１１００、マッチング部１２００、ゲーム進行処理部１３００、フィールド管理部１４００およびＡＶ処理部１５００として機能させる。

ユーザ情報管理部１１００は、対戦ゲームに参加するユーザのユーザ情報を管理する手段である。ユーザ情報管理部１１００は、対戦ゲームの参加者を募集し、参加者のユーザ情報を記憶部１２内のユーザ情報テーブル２１００に登録する。このユーザ情報テーブル２１００の内容はゲームの進行に応じて更新される。

図９はユーザ情報テーブル２１００を例示する図である。ユーザ情報テーブル２１００は、対戦ゲームに参加する各ユーザのユーザ情報によって構成されている。図９に示すように、１人のユーザのユーザ情報は、当該ユーザのユーザＩＤと、当該ユーザが操作する端末３０の端末ＩＤと、当該端末３０からの操作情報により制御されるキャラクタに関するキャラクタ情報と、当該キャラクタのフィールド移動履歴の各情報を含む。

ここで、キャラクタ情報は、当該キャラクタのキャラクタＩＤと、当該ユーザのスキルレベルと、当該キャラクタの所持する爆弾数および銃弾数と、当該キャラクタが対戦ゲームにおいて獲得したポイントと、当該キャラクタのフィールド内位置と、当該キャラクタの生死の各情報を含む。フィールド内位置は、当該キャラクタが所在するフィールドにおける当該キャラクタの所在位置のＸ座標値およびＹ座標値により表現される。

このＸ座標値およびＹ座標値は、図４においてフィールドＦＤとともに示されたＸ軸方向およびＹ軸方向の各座標値である。ここで、Ｘ軸は、端末３０の画面にフィールドＦＤが表示された状態においてフィールドＦＤの水平方向を示す軸であり、Ｙ軸はフィールドＦＤの垂直方向を示す軸である。

フィールド移動履歴は、当該キャラクタＣが現在所在するフィールドＦＤを示す現フィールドＩＤと、そのフィールドＦＤに所在する前に所在したフィールドＦＤを示す前フィールドＩＤとを含む。

図８において、マッチング部１２００は、ゲームに参加する複数のユーザを所定数のグループに分けるマッチングを行う手段である。マッチング部１２００は、グループ間で所属するキャラクタ数が均等になるようにマッチングを行う。各グループに帰属させるキャラクタはランダムに選択される。

ゲーム進行処理部１３００は、複数のフィールド（本発明における「領域」の一例）に所在する各キャラクタを当該キャラクタに対応した端末３０から取得される操作情報に基づいて制御する第１制御部に相当するものである。さらに詳述すると、ゲーム進行処理部１３００は、マッチング部１２００がマッチングを実行することにより得られたゲーム参加者の各グループについてフィールドＦＤを各々生成する。そして、ゲーム進行処理部１３００は、各グループに対応したフィールドＦＤに対し、各グループの参加者に対応したキャラクタＣを配置し、各フィールドＦＤの状態を示すフィールド情報テーブル２２００を記憶部１２内に生成する。

図１０はフィールド情報テーブル２２００の一例を示す図である。フィールドＩＤは、フィールド情報テーブル２２００が示すフィールドＦＤを特定するＩＤである。

ハードブロック情報は、フィールドＦＤ内に配置されたハードブロックＨＢを示す情報である。図４に例示するようにフィールドＦＤ内に複数のハードブロックＨＢが配置されている場合、フィールド情報テーブル２２００には、それらのハードブロックＨＢに対応した複数のハードブロック情報が含まれる。各ハードブロック情報は、フィールドＦＤ内におけるハードブロックＨＢの代表位置（例えば中心位置）を示す位置情報を含む。

ソフトブロック情報は、フィールドＦＤ内に配置されたソフトブロックＳＢを示す情報である。図４に例示するようにフィールドＦＤ内に複数のソフトブロックＳＢが配置されている場合、フィールド情報テーブル２２００には、それらのソフトブロックＳＢに対応した複数のソフトブロック情報が含まれる。各ソフトブロック情報は、ハードブロック情報と同様な位置情報の他、有無情報を含む。この有無情報は、ソフトブロック情報が示すソフトブロックＳＢがフィールドＦＤ内に存在しているか否かを示す情報である。この有無情報を設けたのは、ソフトブロックＳＢは、ハードブロックＨＢと異なり、爆弾等による攻撃により消失することがあるからである。

ゲート情報は、フィールドＦＤに設けられたゲートＧの状態を示す情報である。このゲート情報は、フィールドＦＤ内における当該ゲートＧの代表位置（例えば中心位置）を示す位置情報と、当該ゲートＧが開いているか閉まっているかを示す開閉情報とを含む。

また、ゲート情報は、キャラクタ入場数と、キャラクタ退場数とを含む。キャラクタ入場数は、当該ゲートＧが開状態となった後、他のフィールドＦＤから当該ゲートＧを介して当該フィールドＦＤに入場したキャラクタＣの数である。また、キャラクタ退場数は、当該ゲートＧが開状態となった後、当該フィールドＦＤから当該ゲートＧを介して他のフィールドＦＤに退場したキャラクタＣの数である。

また、ゲート情報は、オプションとして、制限情報を含む場合がある。この制限情報は、当該ゲートＧが開状態であっても当該ゲートＧを介した特定の態様のキャラクタＣの移動を制限することを指示するものであり、必要に応じてフィールド管理部１４００により設定される。

キャラクタ情報は、フィールドＦＤ内に所在するキャラクタＣを示す情報であり、当該キャラクタＣを特定するキャラクタＩＤと、当該キャラクタＣのフィールドＦＤ内での代表位置（例えば中心位置）を示す位置情報を含む。フィールドＦＤ内に複数のキャラクタＣが所在する場合、フィールド情報テーブル２２００にはそれらのキャラクタＣに対応した複数のキャラクタ情報が含まれる。

フィールド内キャラクタ数は、当該フィールドＦＤ内に所在するキャラクタＣの総数である。このフィールド内キャラクタ数は、フィールド情報テーブル２２００内にあるキャラクタ情報の数と一致する。

爆発情報は、キャラクタＣによってフィールドＦＤ内に爆弾が仕掛けられた場合に設定される情報である。この爆発情報は、フィールドＦＤ内において爆弾が仕掛けられた位置を示す位置情報と、仕掛けられた爆弾の爆発予定時刻と、攻撃者ＩＤとを含む。攻撃者ＩＤは、爆弾を仕掛けたキャラクタＣのキャラクタＩＤである。

発砲情報は、キャラクタＣが銃を発砲した場合に設定される情報である。この発砲情報は、発砲が行われたフィールドＦＤ内の位置を示す位置情報と、発砲方向と、攻撃者ＩＤとを含む。攻撃者ＩＤは、発砲を行ったキャラクタＣのキャラクタＩＤである。

音声指示情報は、爆弾の爆発音、銃の発砲音等の各種の音声の発生を指示する情報である。この音声指示情報は、発生する音声の種類を示す音声ＩＤと、音声の継続時間を示す情報を含む。例えば爆弾が爆発した場合に、爆発音を示す音声ＩＤと、爆発音の継続時間を示す情報を含む音声指示情報がフィールド情報テーブル２２００に書き込まれる。後述するＡＶ処理部１５００内のＡＶ生成部１５１０は、フィールド情報テーブル２２００を読み込み、このフィールド情報テーブル２２００内の音声指示情報に従って爆発音等の音声信号を発生する。この音声信号の発生が行われることにより、フィールド情報テーブル２２００内の音声指示情報は削除される。

プレッシャフラグは、キャラクタをフィールドから追い出すためにプレッシャブロックの駆動を開始する際にＯＮとされるフラグである。タイマは、プレッシャブロックの駆動開始から所定時間が経過したときにタイムアウトとなる計時手段である。プレッシャブロック情報は、フィールドからキャラクタを追い出すために駆動されるプレッシャブロックに関する情報である。本実施形態において、キャラクタＣはプレッシャブロックと衝突することにより消滅し、対戦から離脱する。プレッシャブロック情報はフィールド内におけるプレッシャブロックの位置を示す位置情報を含む。

なお、爆発情報、発砲情報、音声指示情報およびプレッシャブロック情報は、ゲームが開始された後に発生する情報であり、初期状態においてはフィールド情報テーブル２２００に含まれていない。
以上がフィールド情報テーブル２２００の内容である。

図８において、ゲーム進行処理部１３００は、このようなフィールド情報テーブル２２００を各フィールドについて生成すると、各フィールドに各々対応した複数のフィールド内処理部１３１０を起動し、さらに振り分け部１３２０を起動する。

振り分け部１３２０は、ある端末ＩＤを有する端末３０から操作情報が取得された場合に、ユーザ情報テーブル２１００を参照することにより、その端末ＩＤに対応付けられたキャラクタＩＤと、現フィールドＩＤとを求める。そして、振り分け部１３２０は、現フィールドＩＤが示すフィールドに対応したフィールド内処理部１３１０に対し、その操作情報とキャラクタＩＤを振り分ける。

フィールド内処理部１３１０は、振り分け部１３２０から与えられる操作情報およびキャラクタＩＤに基づいて、操作情報の発生元である端末３０に対応付けられたキャラクタＣを制御する。このキャラクタＣの制御によりフィールドＦＤの状態またはキャラクタＣの状態が変化した場合、フィールド内処理部１３１０は、この状態の変化をフィールド情報テーブル２２００およびユーザ情報テーブル２１００に反映させる。なお、フィールド内処理部１３１０が行う処理の詳細については、説明の重複を避けるため、ゲームシステム１の動作説明において詳細を明らかにする。

フィールド管理部１４００は、複数のフィールドＦＤ（本発明における「領域」の一例）におけるキャラクタＣの状況に基づいて、複数のフィールドＦＤにおける１のフィールドＦＤと他のフィールドＦＤとを連結する第２制御部の一例である。フィールド管理部１４００は、複数のフィールドＦＤ間のキャラクタの移動可否を制御する手段である。フィールド管理部１４００は、連結制御部１４１０と、移動制御部１４２０とを含む。

連結制御部１４１０は、各フィールドＦＤの境界の一部を共有させることにより１のフィールドＦＤと他のフィールドＦＤとを連結する。本実施形態において、複数のフィールドＦＤの境界にはキャラクタＣを移動させるためのゲートＧが設けられている。連結される２つのフィールドＦＤは、各々の境界の一部と、その一部に設けられたゲートＧを共有する。

本実施形態において、連結制御部１４１０は、複数のフィールドＦＤの各々におけるキャラクタＣの数、具体的には複数のフィールド情報テーブル２２００に各々含まれるフィールド内キャラクタ数に基づいて、互いに連結するフィールドを決定する。

図６に示す例では、フィールドＦＤ１内のキャラクタ数が２、フィールドＦＤ２内のキャラクタ数が６、フィールドＦＤ３内のキャラクタ数が７となっている。この場合、キャラクタ数がもっとも少ないのはフィールドＦＤ１である。このフィールドＦＤ１の連結先をできるだけキャラクタ数の多いフィールドとすれば、連結先からのキャラクタの流入により、各フィールドのキャラクタの過密、過疎が緩和される可能性が高くなる。この例ではフィールドＦＤ３が最も多いため、フィールドＦＤ１をフィールドＦＤ３と連結させればキャラクタＣの過密、過疎が緩和される可能性が高くなることになる。

また、そのような連結先の数を多くすることで、過密、過疎がさらに緩和される可能性が高くなる。例えば、フィールドＦＤ２もフィールドＦＤ１よりキャラクタ数が多い。そのため、フィールドＦＤ３に加えてフィールドＦＤ２もフィールドＦＤ１と連結させれば、さらにキャラクタＣの過密、過疎が緩和される可能性が高くなる。

そこで、フィールドＦＤ１～ＦＤ３が図７に示すように連結されることとなる。この例では、キャラクタ数が少ないフィールドを基準にキャラクタ数の多いフィールドを連結させることを考えたが、逆でも良い。すなわち、キャラクタ数の多いフィールドを基準にキャラクタ数の少ないフィールドを連結させるようにしてもよい。

本実施形態において、連結制御部１４１０は、以上のような連結制御を実行するために、連結テーブル２３００を生成し、その管理を行う。図１１は、図７に示すようにフィールドＦＤ１、ＦＤ２およびＦＤ３を連結した直後における連結テーブル２３００を例示する図である。

図１１において、０００１、０００２および０００３は、図７におけるフィールドＦＤ１、ＦＤ２およびＦＤ３のフィールドＩＤである。図７では、フィールドＦＤ１、ＦＤ２およびＦＤ３内におけるキャラクタ数は２、６および７であるため、連結テーブル２３００においてフィールドＩＤである０００１、０００２および０００３に対応付けられたキャラクタ数は、２、６および７となっている。

また、連結テーブル２３００では、フィールドＩＤ＝０００１のフィールドＦＤ１が、連結部である右辺において、フィールドＩＤ＝０００２のフィールドＦＤ２と連結され、連結部である下辺において、フィールドＩＤ＝０００３のフィールドＦＤ３と連結されていることが示されている。また、連結テーブル２３００では、フィールドＩＤ＝０００２のフィールドＦＤ２が、連結部である左辺において、フィールドＩＤ＝０００１のフィールドＦＤ１と連結されていることが示されている。また、連結テーブル２３００では、フィールドＩＤ＝０００３のフィールドＦＤ３が、連結部である上辺において、フィールドＩＤ＝０００１のフィールドＦＤ１と連結されていることが示されている。

本実施形態では、連結テーブル２３００の各フィールドに対応したキャラクタ数に各フィールド情報テーブル２２００のフィールド内キャラクタ数が反映されるようになっている。連結制御部１４１０は、連結制御のタイミングにおいて、連結テーブル２３００に示された各フィールドのキャラクタ数に基づいて、連結するフィールドの組を決定する。

連結制御部１４１０は、以上のようなフィールドの連結制御の他、キャラクタの移動促進制御を行う。さらに詳述すると、連結制御部１４１０は、キャラクタＣが所在するフィールドＦＤのフィールド情報テーブル２２００を常時監視する。そして、フィールド内キャラクタ数が所定数以下の状態が所定時間以上継続したフィールドＦＤを発見すると、連結制御部１４１０は、当該フィールドＦＤに対応したフィールド内処理部１３１０に対し、不利益付与指令を送る。この不利益付与指令は、フィールドＦＤ内に所在するキャラクタＣに対して、プレッシャブロックによる攻撃という不利益を与えて、フィールドＦＤから追い出す旨の指令である。

移動制御部１４２０は、移動制御タイミングにおいて、各ゲートを介したキャラクタの移動の可否の制御を行う手段である。移動制御タイミングには、連結される２つのフィールド間の境界にあるゲートの開閉制御を行う開閉制御タイミングと、フィールド間の特定の態様の移動を制限する制限情報の設定を行う制限情報設定タイミングが含まれる。

図１２は移動制御部１４２０および連結制御部１４１０の制御の態様を示すタイムチャートである。図１２に示すように、移動制御部１４２０は、開閉制御タイミングにおいてゲートの開閉を切り換え、ゲートＧを開き、ゲートＧを介したキャラクタＣの移動を可とする第１期間と、ゲートＧを閉じ、ゲートＧを介したキャラクタＣの移動を不可とする第２期間を交互に繰り返す。そして、移動制御部１４２０は、第１期間において、各フィールドＦＤの連結部となっている辺のゲートＧを開く。連結制御部１４１０は、第２期間内における第１期間の少し前のタイミングにおいて上述した連結の制御を行う。

また、移動制御部１４２０は、制限情報設定タイミングにおいて、ゲートＧを介してキャラクタＣが特定の態様で移動することを制限する制限情報を必要に応じて生成し、各フィールド情報テーブル２２００内のゲート情報に対して設定する。この移動制限の対象には例えば次のようなものがある。

制限対象１：１のフィールドから他のフィールドへ移動したキャラクタＣが再び１のフィールドに戻る。
この制限対象１は、キャラクタＣが強敵との対戦を回避するために同じ２つのフィールド間を往復する移動態様を想定している。移動制御部１４２０は、例えばゲームが白熱する中盤の制限情報設定タイミングにおいて、制限対象の種別として制限対象１を指定する制限情報を全てのフィールド情報テーブル２２００の全てのゲート情報に設定する。

制限対象２：スキルレベルが所定値以上であるユーザのキャラクタＣがゲートＧを通過する。
スキルレベルが所定値以上であるユーザのキャラクタＣは、他のキャラクタＣを倒してフィールド内キャラクタ数を減らすのに貢献する。そこで、移動制御部１４２０は、例えばゲームが白熱する中盤の制限情報設定タイミングにおいて、制限対象の種別として制限対象２を指定する制限情報を全てのフィールド情報テーブル２２００の全てのゲート情報に設定する。

制限対象３：１つのフィールドＦＤに設けられた全てのゲートＧから退場したキャラクタ数（すなわち、キャラクタ退場数の総和）が所定数以上となった後のゲート通過。
この制限対象３の移動を許すと、キャラクタが過疎なフィールドが発生する。そこで、移動制御部１４２０は、例えば定期的な制限情報設定タイミングにおいて、制限対象の種別として制限対象３を指定する制限情報を全てのフィールド情報テーブル２２００の全てのゲート情報に設定する。

制限対象４：連結されたフィールド間の特定方向の移動（すなわち、一方通行）。
キャラクタＣが過密になる可能性のあるフィールドがある場合、そのようなフィールドからキャラクタＣが退場することは好ましいが、そのようなフィールドにキャラクタＣが入場することは好ましくない。そこで、キャラクタＣが過密になる可能性のあるフィールドのキャラクタ数を減らすために、この制限対象４に対応した制限情報が設定される。

この場合の制限情報の設定制御には、２つの態様が考えられる。第１の態様において、移動制御部１４２０は、フィールド内キャラクタ数が所定数以上であるフィールドへのキャラクタＣの移動を制限する制限情報を設定する。すなわち、移動制御部１４２０は、例えば定期的な制限情報設定タイミングにおいて、次のように制限情報の設定を行う。まず、移動制御部１４２０は、全てのフィールド情報テーブル２２００を参照することにより、フィールド内キャラクタ数が所定数以上であるフィールドＩＤを求める。次に移動制御部１４２０は、連結テーブル２３００を参照することにより、このフィールドＩＤに対応付けられた連結部と連結先フィールドＩＤを求める。そして、移動制御部１４２０は、連結先フィールドＩＤに対応したフィールド情報テーブル２２００において連結部に対応したゲートのゲート情報に対し、当該ゲートを介した退場を禁止する制限情報を設定する。

第２の態様において、移動制御部１４２０は、１つのフィールドＦＤに設けられた全てのゲートＧから入場したキャラクタ数（すなわち、キャラクタ入場数の総和）が所定数以上となった後のゲート通過を制限する制限情報を設定する。
この第２の態様において、移動制御部１４２０は、例えば定期的な制限情報設定タイミングにおいて、次のように制限情報の設定を行う。まず、移動制御部１４２０は、全てのフィールド情報テーブル２２００を参照することにより、キャラクタ入場数の総和が所定数以上であるフィールドＩＤを求める。これ以降の処理は、第１の態様の制限情報の設定処理と同様である。この第１の態様による制限情報の設定処理と、第２の態様による制限情報の設定処理は、いずれか一方のみを実施してもよく、両者を実施してもよい。両者を実施する場合、両者の制限情報設定タイミングをずらしてもよい。

制限対象４の具体例として、フィールド内キャラクタ数が著しく少ないフィールドへのキャラクタの移動がある。フィールド内キャラクタ数が著しく少ないフィールドは、残存するキャラクタＣが退場すれば、フィールド内キャラクタ数が０となり、消滅する可能性がある。そのようなフィールドに他のフィールドからキャラクタが入場するのは好ましくない。そこで、移動制御部１４２０は、例えば定期的な制限情報設定タイミングにおいて、全てのフィールド情報テーブル２２００を参照することにより、フィールド内キャラクタ数が所定数以下であるフィールドＩＤを求める。これ以降の処理は、キャラクタＣが過密になる可能性のあるフィールドのキャラクタ数を減らすための制限情報の設定処理と同様である。

また、制限対象４の具体例として、１のフィールドのフィールド内キャラクタ数Ｎａよりも連結先フィールドのフィールド内キャラクタ数Ｎｂの方が多く、両フィールド内キャラクタ数の隔たりの程度、例えばＮｂ－ＮａまたはＮｂ／Ｎａが所定の閾値を越えている場合の連結先フィールドへの移動がある。このような移動を認めると、両フィールド間のフィールド内キャラクタ数の隔たりが益々広がるからである。

この移動制限を行うため、移動制御部１４２０は、例えば定期的な制限情報設定タイミングにおいて、連結テーブル２３００を参照し、フィールドＩＤに対応付けられたフィールド情報テーブル２２００内のフィールド内キャラクタ数と連結先フィールドＩＤに対応付けられたフィールド情報テーブル２２００内のフィールド内キャラクタ数とを比較する。そして、移動制御部１４２０は、フィールドＩＤに対応付けられたフィールド情報テーブル２２００内のフィールド内キャラクタ数Ｎａよりも連結先フィールドＩＤに対応付けられたフィールド情報テーブル２２００内のフィールド内キャラクタ数Ｎｂの方が多く、かつ、両フィールド内キャラクタ数の隔たりの程度が閾値よりも大きいか否かを判断する。この判断結果が「ＹＥＳ」である場合、移動制御部１４２０は、フィールドＩＤに対応したフィールド情報テーブル２２００において、上記判断結果が「ＹＥＳ」となった連結先ＩＤに対応したゲートのゲート情報に対し、当該ゲートを介した退場を禁止する制限情報を設定する。

ＡＶ処理部１５００は、ゲームの進行状況を示す画像および音声を生成してゲームの参加者の端末３０に提供する手段である。このＡＶ処理部１５００は、ゲームの参加者の端末３０に対応付けられた複数のＡＶ生成部１５１０を含む。各ＡＶ生成部１５１０は、各々に対応した端末３０に対応したキャラクタの所在するフィールドのフィールド情報テーブル２２００を記憶部１２から読み出し、当該フィールドの状況を示す画像を生成して当該端末３０に送信する。また、フィールド情報テーブル２２００内に音声指示情報が含まれる場合、ＡＶ生成部１５１０は、その音声指示情報の音声ＩＤに対応した音声を音声指示情報が指示する継続時間だけ発生して端末３０に送信する。音声の発生を行うと、ＡＶ生成部１５１０は、フィールド情報テーブル２２００内の当該音声指示情報を削除する。
以上がクラウドサーバ１０の機能構成である。

［４．ゲームシステムの動作］
図１３は本実施形態におけるサーバプログラムＰＧｓのメインフローを示すフローチャートである。制御部１１がサーバプログラムＰＧｓの実行を開始すると、まず、ユーザ情報管理部１１００が対戦ゲームの参加者を募集する（ステップＳ１００）。

具体的には、ユーザ情報管理部１１００は、クラウドサーバ１０が提供するサイトにアクセスしている端末３０に対し、対戦ゲームへの参加を促す案内画像を送信し、端末３０の表示部３５に表示させる。対戦ゲームへの参加を希望するユーザは、端末３０の操作部３４を操作することにより参加申込を行う。この参加申込が行われると、端末３０の制御部３１は、端末３０を識別する端末ＩＤとともに参加申込情報を通信部３３によりクラウドサーバ１０に送信する。

クラウドサーバ１０は、対戦ゲームへの参加資格のあるユーザのユーザＩＤと、当該ユーザが操作する端末の端末ＩＤと、当該ユーザのスキルレベル等の各関連情報とを対応付けたデータベースを保有している。クラウドサーバ１０の通信部１３が参加申込情報を端末ＩＤとともに受信すると、ユーザ情報管理部１１００は、データベースを参照することにより、端末ＩＤに対応付けられたユーザＩＤを特定し、端末ＩＤ、ユーザＩＤおよび他の関連情報をユーザ情報としてユーザ情報テーブル２１００に登録する。

次にユーザ情報管理部１１００は、ゲームの開始が可能になったか否かを判断する（ステップＳ１０２）。ゲームの参加申込者が定員に到達せず、かつ、募集開始からの経過時間が所定の募集時間に満たない場合、ステップＳ１０２の判断結果は「ＮＯ」となり、ユーザ情報管理部１１００は、処理をステップＳ１００に戻す。この間、参加申し込みをした端末３０の表示部３５には図１４に示す案内画像が表示される。

ゲームの参加申込者が定員（この例では１００人）に到達し、あるいは募集開始からの経過時間が所定の募集時間に到達すると、ステップＳ１０２の判断結果が「ＹＥＳ」となり、処理はステップＳ１０４に進む。

次にステップＳ１０４に進むと、マッチング部１２００は、マッチングを実行する。具体的には、マッチング部１２００は、ゲームの参加申込者を所定数のグループに分ける。１つのグループの各参加者は、各々のキャラクタを同じフィールド内において動作させる。マッチング部１２００は、このグループ分けにおいて、各グループのゲームの参加者数が均等になるように、ゲームの参加者を各グループにランダムに割り当てる。例えば１００名の参加者を募集し、２５グループに分ける場合、各グループの参加者人数は４人となる。ここで、募集開始からの経過時間が所定の募集時間に到達することにより、ステップＳ１０２の判断結果が「ＹＥＳ」となった場合には、参加者人数が４人に満たないグループが生じる。この場合、当該グループには欠員が生じることになるが、ゲームではこの欠員に対応したＮＰＣ（Non Playable Character）を使用することで、グループ間の公平性を担保する。

マッチング（ステップＳ１０４）が終了すると、ゲーム進行処理部１３００は初期設定を行う（ステップＳ１０６）。この初期設定において、ゲーム進行処理部１３００は、マッチング（ステップＳ１０４）により得られたゲーム参加者の各グループについてフィールドを各々生成し、各グループに対応したフィールドに対し、各グループの参加者に対応したキャラクタを配置し、各フィールドの状態を示すフィールド情報テーブル２２００を記憶部１２内に生成する。

ここで、あるフィールドに対応したフィールド情報テーブル２２００は、当該フィールドのフィールドＩＤと、当該フィールド内に所在するキャラクタＣのキャラクタＩＤと位置情報を含む（図１０参照）。ゲーム進行処理部１３００は、このフィールド情報テーブル２２００内のキャラクタＣの位置情報をユーザ情報テーブル２１００内の当該キャラクタＣのキャラクタＩＤに対応付けられたフィールド内位置に反映させ、当該フィールドのフィールドＩＤ（すなわち、フィールド情報テーブル２２００内のフィールドＩＤ）を当該キャラクタＣのキャラクタＩＤに対応付けられた現フィールドＩＤに反映させる。

そして、ゲーム進行処理部１３００は、現在時刻を０に初期化し、生成した各フィールドに対応した複数のフィールド内処理部１３１０と、振り分け部１３２０を起動する。以後、クラウドサーバ１０では、１単位時間を要してステップＳ１１０～Ｓ１７０を実行する処理が繰り返される。

ステップＳ１１０では、ゲーム進行処理部１３００が現在時刻を１単位時間だけ進める。この現在時刻は、対戦ゲームの開始時刻（具体的にはステップＳ１０６の完了時刻）を基準とした相対時刻である。本実施形態では、ステップＳ１６０において各フィールドの状況を示す画像を生成して端末３０に送信する。従って、１単位時間は、端末３０の画面に表示されるフィールドの画像がちらついて見辛くならないように十分に短い時間にすることが好ましい。

次にステップＳ１１２に進むと、通信部１３により端末３０から取得された操作情報を振り分け部１３２０が取り込み、操作情報の振り分けを行う。具体的には、振り分け部１３２０は、ユーザ情報テーブル２１００を参照することにより、操作情報の送信元である端末３０の端末ＩＤに対応付けられたキャラクタＩＤと現フィールドＩＤを求める。そして、振り分け部１３２０は、現フィールドＩＤが示すフィールドに対応したフィールド内処理部１３１０に対し、取得した操作情報とキャラクタＩＤとを振り分ける。振り分け部１３２０は、この処理を、取得した全ての操作情報について実行する。

次にステップＳ１１４に進むと、ゲーム進行処理部１３００では、全てのフィールドに対応した複数のフィールド内処理部１３１０がフィールド内処理を実行する。クラウドサーバ１０が提供する複数のＣＰＵを制御部１１が含む場合、それらのＣＰＵの分散処理により複数のフィールド内処理の並列実行を実現してもよい。

図１５は１つのフィールド内処理の処理内容を示すフローチャートである。まず、フィールド内処理部１３１０は振り分け部１３２０から振り分けられた操作情報がキャラクタＣの移動を指示するものであるか否かを判断する（ステップＳ２００）。ここで、操作情報が例えば左右上下の各方向の矢印キーの操作情報である場合、ステップＳ２００の判断結果は「ＹＥＳ」となり、そうでない場合には、判断結果が「ＮＯ」となる。

ステップＳ２００の判断結果が「ＹＥＳ」である場合、処理はステップＳ２０２に進み、「ＮＯ」である場合には、処理はステップＳ２３０に進む。

次にステップＳ２０２に進むと、フィールド内処理部１３１０は、操作情報がゲートの通過を指示するものであるか否かを判断する。具体的には、フィールド内処理部１３１０は、当該フィールド内処理部１３１０に対応したフィールド情報テーブル２２００を参照することにより、操作情報とともに振り分けられたキャラクタＩＤに対応付けられた位置情報を求める。そして、フィールド内処理部１３１０は、この位置情報が示す位置から操作情報が示す方向にキャラクタＣを移動させた場合に、キャラクタＣがフィールド情報テーブル２２００内のいずれかのゲート情報の位置情報が示す位置にあるゲートＧを通過するか否かを判断する。この判断結果が「ＹＥＳ」であれば、ステップＳ２０２の判断結果は「ＹＥＳ」となり、「ＮＯ」であれば、ステップＳ２０２の判断結果は「ＮＯ」となる。

ステップＳ２０２の判断結果が「ＹＥＳ」である場合、処理はステップＳ２２０に進む。一方、ステップＳ２０２の判断結果が「ＮＯ」である場合、すなわち、操作情報がフィールド内のキャラクタＣの移動を指示している場合、処理はステップＳ２１０に進む。

次にステップＳ２１０に進むと、フィールド内処理部１３１０は、操作情報により指示されたキャラクタＣの移動が可能か否かを判断する。具体的にはフィールド内処理部１３１０は、フィールド情報テーブル２２００内のキャラクタ情報、ハードブロック情報およびソフトブロック情報を参照する。そして、フィールド内処理部１３１０は、操作情報とともに振り分けられたキャラクタＩＤに対応付けられたキャラクタ情報の位置情報が示す位置から操作情報に従ってキャラクタＣを移動させた場合に、キャラクタＣがハードブロックＨＢまたはソフトブロックＳＢに衝突しないかどうかを判断する。衝突が発生しない場合、ステップＳ２１０の判断結果が「ＹＥＳ」となってステップＳ２１２に進み、衝突が発生する場合、ステップＳ２１０の判断結果が「ＮＯ」となってステップＳ２１４に進む。

次にステップＳ２１２に進むと、フィールド内処理部１３１０は、キャラクタＣを操作情報に従って移動させる。具体的には、フィールド内処理部１３１０は、操作情報とともに振り分けられたキャラクタＩＤに対応付けられたキャラクタ情報の位置情報を操作情報に従って変化させる。また、フィールド内処理部１３１０は、ユーザ情報テーブル２１００において、当該キャラクタＩＤに対応付けられたフィールド内位置に、操作情報に基づいて変更した後の位置情報を反映させる。そして、処理はステップＳ２３０に進む。

ステップＳ２１０からステップＳ２１４に進んだ場合、フィールド内処理部１３１０は、キャラクタＣの移動を拒否する。すなわち、すなわち、キャラクタＣを移動させる操作情報に対して反応しない。そして、処理はステップＳ２３０に進む。

上述したステップＳ２０２の判断結果が「ＹＥＳ」となる場合、すなわち、操作情報がゲートの通過を指示するものである場合の動作は次のようになる。まず、フィールド内処理部１３１０は、フィールド情報テーブル２２００内の通過対象であるゲートのゲート情報における開閉情報が開状態を示しているか否かを判断する（ステップＳ２２０）。この判断結果が「ＮＯ」である場合、フィールド内処理部１３１０は、キャラクタＣの移動を拒否し（ステップＳ２２８）、処理をステップＳ２３０に進める。

ステップＳ２２０の判断結果が「ＹＥＳ」である場合、フィールド内処理部１３１０は、通過対象のゲートのゲート情報が制限情報を含むか否かを判断する（ステップＳ２２２）。この判断結果が「ＮＯ」である場合、フィールド内処理部１３１０は、キャラクタ移動を実行し（ステップＳ２２６）、処理をステップＳ２３０に進める。

ステップＳ２２２の判断結果が「ＹＥＳ」である場合、フィールド内処理部１３１０は、操作情報が示すキャラクタＣの移動がゲート情報に含まれる制限情報が示す制限対象に当たるか否かを判断する（ステップＳ２２４）。ここで、ゲート情報に複数の制限情報が含まれている場合、フィールド内処理部１３１０は、キャラクタＣの移動がそれらのうちのいずれかの制限情報が示す制限対象に当たるか否かを判断する。この判断結果が「ＹＥＳ」である場合、フィールド内処理部１３１０は、キャラクタＣの移動を拒否し（ステップＳ２２８）、処理をステップＳ２３０に進める。一方、ステップＳ２２４の判断結果が「ＮＯ」である場合、フィールド内処理部１３１０は、キャラクタ移動を実行し（ステップＳ２２６）、処理をステップＳ２３０に進める。

ここで、ステップＳ２２４の判断について、具体例を挙げて説明する。通過対象であるゲートのゲート情報が制限対象１を示す制限情報を含む場合、フィールド内処理部１３１０は、ユーザ情報テーブル２１００において、当該ゲートを通過しようとするキャラクタＣのキャラクタＩＤに対応付けられた前フィールドＩＤを参照する。そして、フィールド内処理部１３１０は、連結テーブル２３００を参照し、キャラクタＣが現在所在するフィールドの通過対象のゲートの連結先フィールドＩＤを求める。そして、フィールド内処理部１３１０は、この連結先フィールドＩＤがユーザ情報テーブル２１００における当該キャラクタＣの前フィールドＩＤと一致するか否かにより、操作情報の指示する移動が制限対象１に該当するか否かを判断する。

また、通過対象であるゲートのゲート情報が制限対象２を示す制限情報を含む場合、フィールド内処理部１３１０は、ユーザ情報テーブル２１００を参照し、当該ゲートを通過しようとするキャラクタＣのキャラクタＩＤに対応付けられたスキルレベルが所定値以上か否かを判断する。フィールド内処理部１３１０は、この判断結果が「ＹＥＳ」か否かにより、操作情報の示す移動が制限対象２に該当するか否かを判断する。

通過対象であるゲートのゲート情報が制限対象３を示す制限情報を含む場合、フィールド内処理部１３１０は、フィールド情報テーブル２２００内の全てのゲート情報のキャラクタ退場数の総和を求め、この総和が所定数以上か否かにより、操作情報の示す移動が制限対象３に該当するか否かを判断する。

制限対象４を制限する各制限情報は、特定のゲートを介した退場を禁止する情報を含む。通過対象であるゲートのゲート情報がこのような制限情報を含む場合、操作情報が示す移動は禁止される。

次にステップＳ２２６のキャラクタ移動の詳細について説明する。ステップＳ２２６において、フィールド内処理部１３１０は、操作情報に従って、キャラクタＩＤが示すキャラクタＣを現在のフィールドＦＤからゲートＧを介して他のフィールドＦＤに移動させる。

具体的には、フィールド内処理部１３１０は、連結テーブル２３００において、通過対象であるゲートＧを連結部とし、この連結部に対応した連結先フィールドＩＤを求める。そして、フィールド内処理部１３１０は、この連結先フィールドＩＤに対応したフィールド内処理部１３１０に対して、当該ゲートＧを通過するキャラクタのキャラクタＩＤを含む移動通知を送信する。

例えば図１１において、操作情報およびキャラクタＩＤが振り分けられたフィールド内処理部１３１０が、フィールドＩＤ＝０００１のフィールドに対応しているものとする。ここで、操作情報が当該フィールドの右辺に設けられたゲートの通過を指示している場合、連結先フィールドＩＤは０００２となる。そこで、フィールド内処理部１３１０は、フィールドＩＤ＝０００２に対応したフィールド内処理部１３１０にキャラクタＩＤを含む移動通知を送る。なお、この移動通知を受信したフィールド内処理部１３１０の動作については後述する。

また、フィールド内処理部１３１０は、ゲートＧを通過したキャラクタＣに対応したキャラクタ情報を当該フィールド内処理部１３１０に対応したフィールド情報テーブル２２００から抹消する。また、フィールド内処理部１３１０は、フィールド情報テーブル２２００において、キャラクタＣが通過したゲートのゲート情報におけるキャラクタ退場数を１だけ増加させ、フィールド内キャラクタ数を１だけ減少させる。

次にステップＳ２３０に進むと、フィールド内処理部１３１０は、操作情報が攻撃操作を指示しているか否かを判断する。攻撃操作とは、例えばキャラクタＣに爆弾を仕掛けさせる操作、キャラクタＣに銃を発砲させる操作等である。ステップＳ２３０の判断結果が「ＹＥＳ」である場合、処理はステップＳ２３２に進み、「ＮＯ」である場合、処理はステップＳ２４０に進む。

次にステップＳ２３２に進むと、フィールド内処理部１３１０は、スケジュール設定を実行する。例えば、あるキャラクタＣが爆弾を仕掛けることを操作情報が指示している場合、フィールド内処理部１３１０は、位置情報と、爆発予定時刻と、攻撃者ＩＤとを含む爆発情報をフィールド情報テーブル２２００内に生成する。ここで、攻撃者ＩＤは、爆弾を仕掛けるキャラクタＣのキャラクタＩＤ、すなわち、操作情報とともに当該フィールド内処理部１３１０に振り分けられたキャラクタＩＤである。また、位置情報はフィールド情報テーブル２２００内において当該キャラクタＩＤを含むキャラクタ情報内の位置情報である。爆発予定時刻は現在時刻に対して所定の遅延時間を加えた時刻である。なお、この遅延時間を操作情報により指定するようにしてもよい。

また、例えば、あるキャラクタＣによる銃の発砲およびその発砲方向を操作情報が指示している場合、フィールド内処理部１３１０は、位置情報と、発砲方向と、発砲予定時刻と、攻撃者ＩＤとを含む発砲情報をフィールド情報テーブル２２００内に生成する。攻撃者ＩＤは、発砲するキャラクタＣのキャラクタＩＤ、すなわち、操作情報とともに当該フィールド内処理部１３１０に振り分けられたキャラクタＩＤである。また、位置情報は、発砲位置を示す情報であり、フィールド情報テーブル２２００内において当該キャラクタＩＤを含むキャラクタ情報内の位置情報が用いられる。発砲方向は、操作情報により指示される情報であり、上下左右のいずれかの方向を示す。発砲予定時刻は、現在時刻に対して、ある遅延時間を加えた時刻である。好ましい態様では、この遅延時間は、ユーザ情報テーブル２１００において、攻撃者ＩＤ（キャラクタＩＤ）に対応付けられたスキルレベルに依存し、スキルレベルが高くなる程、短時間となる。

次にステップＳ２４０に進むと、フィールド内処理部１３１０は、振り分け部１３２０から振り分けられた操作情報の中に未処理の操作情報が残っているか否かを判断する。この判断結果が「ＹＥＳ」である場合、フィールド内処理部１３１０は、未処理の操作情報について、上述したステップＳ２００以降の処理を実行する。

振り分け部１３２０から振り分けられた全ての操作情報についてステップＳ２００～Ｓ２４０の処理が実行され、ステップＳ２４０の判断結果が「ＮＯ」になると、処理はステップＳ２５０に進む。このステップＳ２５０において、フィールド内処理部１３１０は、他のフィールド内処理部１３１０がステップＳ２２６において送信した移動通知を受け取ったか否かを判断する。この判断結果が「ＹＥＳ」である場合、処理はステップＳ２５２に進み、「ＮＯ」である場合、処理はステップＳ２６０に進む。

次にステップＳ２５２に進むと、フィールド内処理部１３１０は、他のフィールド内処理部１３１０から受信した移動通知に基づいて、キャラクタ移動を実行する。具体的には、フィールド内処理部１３１０は、連結テーブル２３００内の当該フィールド内処理部１３１０に対応したフィールドＩＤに関連する情報を参照することにより、移動通知の送信元に対応したフィールドＩＤが連結先フィールドＩＤとなっている連結部を求め、この連結部に相当するゲートをキャラクタＣの入場口とする。そして、当該フィールド内処理部１３１０は、移動通知に含まれるキャラクタＩＤに対応したキャラクタＣをこの入場口から入場させ、この入場したキャラクタＣのキャラクタ情報を当該フィールド内処理部１３１０に対応したフィールド情報テーブル２２００内に生成する。

例えば図１１において、移動通知を受け取ったフィールド内処理部１３１０がフィールドＩＤ＝０００２に対応し、移動通知の送信元であるフィールド内処理部１３１０がフィールドＩＤ＝０００１に対応していたとする。

この場合、連結テーブル２３００によると、フィールドＩＤ＝０００２のフィールドでは、左辺である連結部（ゲート）に連結先フィールドＩＤ＝０００１のフィールドが連結されている。従って、移動通知を受け取ったフィールド内処理部１３１０は、フィールドの左辺にあるゲートＧをキャラクタＣの入場口とする。そして、フィールド内処理部１３１０は、フィールド情報テーブル２２００において、入場口であるゲートＧのゲート情報に含まれる位置情報が示す位置から所定距離だけフィールド内に進入した位置の位置情報を求め、キャラクタＣのキャラクタＩＤとこの位置情報を含むキャラクタ情報をフィールド情報テーブル２２００内に生成する。

また、移動通知を受け取ったフィールド内処理部１３１０は、フィールド情報テーブル２２００において、キャラクタＣが入場したゲートのゲート情報に含まれるキャラクタ入場数を１だけ増加させ、フィールド内キャラクタ数を１だけ増加させる。さらに、フィールド内処理部１３１０は、あるキャラクタＩＤに対応したキャラクタ情報をフィールド情報テーブル２２００内に生成した場合に、ユーザ情報テーブル２１００内の当該キャラクタＩＤに対応したフィールド内位置に当該キャラクタ情報の位置情報を反映させる。また、フィールド内処理部１３１０は、あるキャラクタＩＤを含む移動通知の受信した場合に、ユーザ情報テーブル２１００において、当該キャラクタＩＤに対応した現フィールドＩＤに当該フィールド内処理部１３１０に対応したフィールドＩＤを反映させ、前フィールドＩＤに移動通知の送信元に対応したフィールドＩＤを反映させる。

次にステップＳ２６０に進むと、フィールド内処理部１３１０は、スケジュールがあるか否か、すなわち、フィールド情報テーブル２２００内に、現在時刻を爆発予定時刻あるいは発砲予定時刻とする爆発情報あるいは発砲情報があるか否かを判断する。この判断結果が「ＮＯ」である場合、処理はステップＳ２７０に進み、「ＹＥＳ」である場合、処理はステップＳ２６２に進む。

次にステップＳ２６２に進むと、フィールド内処理部１３１０は、スケジュールを実行する。例えば爆発予定時刻が現在時刻である爆発情報がある場合、フィールド内処理部１３１０は、その爆発情報に含まれる位置情報が示す位置から上下左右の各方向に爆風を発生させる。また、フィールド内処理部１３１０は、爆発音の発生を指示する音声指示情報をフィールド情報テーブル２２００内に書き込む。

フィールド情報テーブル２２００内のいずれかのソフトブロック情報の位置情報が爆風の進路上にあり、ソフトブロックＳＢが爆風を受けた場合、フィールド内処理部１３１０は、そのソフトブロック情報における有無情報を無に対応した情報にする。

フィールド情報テーブル２２００内のいずれかのキャラクタ情報の位置情報が爆風の進路上にあり、キャラクタＣが爆風を受けた場合、フィールド内処理部１３１０は、そのキャラクタＣを対戦から離脱させる。具体的には、フィールド内処理部１３１０は、爆風を受けたキャラクタＣのキャラクタ情報をフィールド情報テーブル２２００から抹消し、フィールド情報テーブル２２００内のフィールド内キャラクタ数を１だけ減らす。また、フィールド内処理部１３１０は、ユーザ情報テーブル２１００において、爆風を受けたキャラクタＣに対応した生死情報を死に対応した情報にする。また、フィールド内処理部１３１０は、ある攻撃者ＩＤを含む爆発情報に従って爆発を行わせ、その爆風によりキャラクタＣを対戦から離脱させた場合、フィールド内処理部１３１０は、ユーザ情報テーブル２１００において、その攻撃者ＩＤ（キャラクタＩＤ）に対応付けられたポイントを所定量増加させる。

また、例えば発砲予定時刻が現在時刻である発砲情報がある場合、フィールド内処理部１３１０は、その発砲情報に含まれる位置情報が示す位置から操作情報により指定された発砲方向に銃弾を飛ばす。また、フィールド内処理部１３１０は、発砲音の発生を指示する音声指示情報をフィールド情報テーブル２２００内に書き込む。

フィールド情報テーブル２２００内のいずれかのキャラクタ情報の位置情報が銃弾の進路上にあり、キャラクタＣが被弾した場合、フィールド内処理部１３１０は、そのキャラクタＣを対戦から離脱させる。この場合のフィールド内処理部１３１０の処理は、キャラクタＣが爆風を受けた場合の処理と同様である。フィールド内処理部１３１０は、爆弾情報に基づく爆発、あるいは発砲情報に基づく発砲を実行した場合、当該爆発情報あるいは当該発砲情報をフィールド情報テーブル２２００から抹消する。

次にステップＳ２７０に進むと、フィールド内処理部１３１０は、フィールド消滅制御を実行する。このフィールド消滅制御が終了すると、フィールド内処理は終了し、処理は図１３のステップＳ１２０に進む。

図１６は図１５のステップＳ２７０において実行されるフィールド消滅制御の処理内容を示すフローチャートである。まず、フィールド内処理部１３１０は、フィールド情報テーブル２２００内のフィールド内キャラクタ数が０か否かを判断する（ステップＳ３００）。この判断結果が「ＹＥＳ」である場合、処理はステップＳ３１６に進み、「ＮＯ」である場合、処理はステップＳ３０２に進む。

次にステップＳ３０２に進むと、フィールド内処理部１３１０は、不利益付与指令を受け取ったか否かを判断する。この判断結果が「ＹＥＳ」である場合、処理はステップＳ３０４に進み、「ＮＯ」である場合、処理はステップＳ３０６に進む。

次にステップＳ３０４に進むと、フィールド内処理部１３１０は、フィールド情報テーブル２２００内のプレッシャフラグをＯＮとし、タイマによる計時を開始する。そして、処理はステップＳ３０６に進む。

次にステップＳ３０６に進むと、フィールド内処理部１３１０は、プレッシャフラグがＯＮであるか否かを判断する。この判断結果が「ＹＥＳ」である場合、処理はステップＳ３０８に進み、「ＮＯ」である場合、フィールド消滅制御は終了する。

次にステップＳ３０８に進むと、フィールド内処理部１３１０は、プレッシャブロックの駆動および残り時間の表示の処理を行う。図１７はこのステップＳ３０６の処理および後述するＡＶ処理（図１３のステップＳ１６０）によりユーザに提供されるフィールドの画像を示すものである。

ステップＳ３０８では、プレッシャブロックＰＢを所定距離ずつ所定方向に移動させる駆動制御が行われる。具体的には、フィールド情報テーブル２２００内のプレッシャブロック情報における位置情報を所定量ずつ変化させる。プレッシャブロックＰＢがキャラクタＣに衝突すると、キャラクタＣは消滅し、対戦から離脱される。従って、キャラクタＣは、消滅から逃れるために、プレッシャブロックＰＢを避けつつ、他のフィールドＦＤに移動する必要がある。

また、ステップＳ３０８では、フィールド情報テーブル２２００内のタイマのタイマ値に基づき、図１７に例示するように、残り時間の表示が行われる。この残り時間は、フィールドＦＤが消滅するまでの残り時間である。キャラクタＣは、消滅から逃れるために、この残り時間内に現在のフィールドＦＤを脱出する必要がある。

次にステップＳ３１０に進むと、フィールド内処理部１３１０は、フィールド情報テーブル２２００内のプレッシャブロック情報の位置情報とキャラクタ情報の位置情報に基づき、いずれかのプレッシャブロックＰＢがいずれかのキャラクタＣと衝突したか否かを判断する。この判断結果が「ＹＥＳ」である場合、処理はステップＳ３１２に進み、「ＮＯ」である場合、処理はステップＳ３１４に進む。

次にステップＳ３１２に進むと、フィールド内処理部１３１０は、プレッシャブロックＰＢと衝突したキャラクタＣを抹消する。具体的には、フィールド情報テーブル２２００内において、プレッシャブロックＰＢと衝突したキャラクタＣのキャラクタ情報を抹消し、フィールド内キャラクタ数を１だけ少なくし、ユーザ情報テーブル２１００における当該キャラクタに対応した生死情報を死に対応した情報にする。

次にステップＳ３１４に進むと、フィールド内処理部１３１０は、フィールド情報テーブル２２００内のタイマがタイムアウトしたか否かを判断する。この判断結果が「ＹＥＳ」である場合、処理はステップＳ３１６に進み、「ＮＯ」の場合、フィールド消滅制御は終了となる。

フィールド内キャラクタ数が０となり、あるいはタイマのタイムアウトにより処理がステップＳ３１６に進むと、フィールド内処理部１３１０は、フィールドを消滅させる。具体的には、フィールド内処理部１３１０は、消滅するフィールドのフィールドＩＤをフィールド管理部１４００に送り、当該フィールドに対応したフィールド情報テーブルを抹消する。そして、フィールド消滅制御は終了する。フィールド消滅制御が終了すると、処理は図１５のフィールド内処理を介して図１３のメインフローに戻る。

図１３において、ステップＳ１２０に進むと、フィールド管理部１４００は、現在時刻が図１２に例示された連結制御のタイミングであるか否かを判断する。この判断結果が「ＹＥＳ」である場合、処理はステップＳ１２２に進み、「ＮＯ」である場合、処理はステップＳ１３０に進む。

ステップＳ１２２に進むと、連結制御部１４１０が連結制御を実行する。さらに詳述すると、連結制御部１４１０は、キャラクタＣが所在する全てのフィールドのフィールド情報テーブル２２００内のフィールド内キャラクタ数に基づいて、互いに連結するフィールドを決定し、図１１に例示する連結テーブル２３００を生成する。具体的には、連結制御部１４１０は、互いに連結されたフィールド間のフィールド内キャラクタ数の差分が所定数以上となるように、連結するフィールドの組を決定する。連結制御（ステップＳ１２２）が終了すると、処理はステップＳ１３０に進む。

次にステップＳ１３０に進むと、フィールド管理部１４００は、現在時刻が移動制御タイミングか否かを判断する。上述した通り、移動制御タイミングは、ゲートの開閉制御を行う開閉制御タイミングと、制限情報の設定を行う制限情報設定タイミングを含む。ステップＳ１３０の判断結果が「ＹＥＳ」である場合、処理はステップＳ１３２に進み、「ＮＯ」である場合、処理はステップＳ１４０に進む。

次にステップＳ１３２に進むと、移動制御部１４２０は、移動制御を実行する。この移動制御において、移動制御部１４２０は、現在時刻の前の期間が第１期間であった場合、第１期間から第２期間への切り換えを実行し、現在時刻の前の期間が第２期間であった場合、第２期間から第１期間への切り換えを実行する。ゲートの通過を可とする第１期間を開始する場合、移動制御部１４２０は、キャラクタＣが所在する全てのフィールドのフィールド情報テーブル２２００に含まれるゲート情報のうち連結テーブル２３００において連結部とされているゲートのゲート情報における開閉情報を開に対応した情報にする。また、ゲートの通過を不可とする第２期間を開始する場合、移動制御部１４２０は、キャラクタＣが所在する全てのフィールドのフィールド情報テーブル２２００に含まれるゲート情報の開閉情報を閉に対応した情報にする。

また、移動制御部１４２０は、制限情報設定タイミングにおいて、必要に応じて、上述した制限対象１～４に対応した制限情報の設定を行う。このようにすることで、以後、制限対象１～４に該当するフィールド間のキャラクタの移動が拒否される。

次にステップＳ１４０に進むと、連結制御部１４１０は、キャラクタの移動促進制御を行う。さらに詳述すると、連結制御部１４１０は、キャラクタＣが所在するフィールドのフィールド情報テーブル２２００のフィールド内キャラクタ数を参照する。そして、フィールド内キャラクタ数が所定数以下の状態が所定時間以上継続したフィールドがある場合に、当該フィールドに対応したフィールド内処理部１３１０に不利益付与指令を送る。この不利益付与指令を受け取ったフィールド内処理部１３１０の動作は上述した通りである。

次にステップＳ１５０に進むと、フィールド管理部１４００は、消滅対応制御を実行する。さらに詳述すると、フィールド管理部１４００は、消滅したフィールドのフィールドＩＤをフィールド内処理部１３１０から受け取った場合に、そのフィールドＩＤを連結制御部１４１０および移動制御部１４２０に送る。

連結制御部１４１０は、このフィールドＩＤを次回の連結制御（ステップＳ１２２）のタイミングまで保持し、次回の連結制御ではこのフィールドＩＤに対応したフィールドを連結の対象から外す。

また、移動制御部１４２０は、連結テーブル２３００において、消滅したフィールドのフィールドＩＤを連結先フィールドＩＤとするフィールドＩＤ、すなわち、消滅したフィールドに連結されたフィールドのフィールドＩＤを求める。そして、移動制御部１４２０は、このフィールドＩＤに対応したフィールド情報テーブル２２００において、当該連結先フィールドＩＤに対応した連結部（すなわち、消滅したフィールドに連結された連結部）に該当するゲートのゲート情報における開閉情報を閉状態に対応した情報にする。これにより消滅したフィールドへのキャラクタＣの移動を回避することができる。

次にステップＳ１６０に進むと、ＡＶ処理部１５００では、ゲームの参加者の端末３０に対応付けられた複数のＡＶ生成部１５１０が画像および音声の生成を実行する。具体的には、各ＡＶ生成部１５１０は、ユーザ情報テーブル２１００を参照することにより、各々に対応した端末３０の端末ＩＤに対応付けられたキャラクタＩＤと現フィールドＩＤとを求め、現フィールドＩＤに対応するフィールド情報テーブル２２００を記憶部１２から読み出す。そして、ＡＶ生成部１５１０は、読み出したフィールド情報テーブル２２００に基づいて、フィールド内のハードブロックＨＢ、ソフトブロックＳＢ、キャラクタＣ、爆弾、銃弾、プレッシャブロック、残り時間等の状況を示す画像を生成し、当該ＡＶ生成部１５１０に対応した端末３０に送信する。ＡＶ生成部１５１０は、読み出したフィールド情報テーブル２２００が音声指示情報を含む場合、音声指示情報に従って音声を生成し、当該ＡＶ生成部１５１０に対応した端末３０に送信する。

次にステップＳ１７０に進むと、ゲーム進行処理部１３００は、例えばゲームにおいて残存している総キャラクタ数に基づいて、最終局面への移行をすべきか否かを判断する。ここで、総キャラクタ数は、例えばキャラクタが所在する全てのフィールドのフィールド情報テーブル２２００におけるフィールド内キャラクタ数の総和として求めることが可能である。なお、ステップＳ１５０の判断では、このような総キャラクタ数の代わりに、キャラクタが所在するフィールド数を用いてもよい。

ステップＳ１７０の判断結果が「ＮＯ」である場合、ゲーム進行処理部１３００は、処理をステップＳ１１０に戻し、時刻を１単位時間だけ進めて、ステップＳ１１２～Ｓ１６０の各処理を実行させる。

ステップＳ１７０の判断結果が「ＹＥＳ」になると、ゲーム進行処理部１３００は、処理をステップＳ１７２に進め、最終局面処理を実行する。すなわち、ゲーム進行処理部１３００は、残存している全てのキャラクタＣを１つのフィールドに集め、対戦を行わせる。対戦において、１つのキャラクタＣのみが生き残ると、対戦ゲームは終了となる。

［５．実施形態の効果］
以上説明したように、本実施形態によれば、複数のキャラクタＣにより進行するゲームを提供するクラウドサーバ１０において、複数のフィールドＦＤのいずれかのフィールドＦＤにおいて、ゲームに係るキャラクタＣを当該キャラクタＣに対応付けられた端末３０から取得される操作情報に基づいて制御するゲーム進行処理部１３００と、複数のフィールドにおけるキャラクタＣの状況に基づいて、複数のフィールドにおける１の領域と他の領域とを連結するフィールド管理部１４００とを設けたので、多数のキャラクタＣによる対戦ゲーム等を実現し、かつ、キャラクタＣの過疎・過密の発生を防止することができる。また、ユーザには、広い領域の中の一部の領域において、他のキャラクタとの対戦等を行っている感覚を与えることができる。

また、連結制御部１４１０は、複数のフィールドの各々におけるキャラクタの数に基づいて、互いに連結する領域を決定するので、キャラクタの過疎・過密を効果的に解消することができる。

また、連結制御部１４１０は、１のフィールドに所在するキャラクタの数が所定数以下である場合に、当該キャラクタに対して不利益を与えるので、当該キャラクタに他のフィールドへの移動を促し、少ない数のキャラクタが同じフィールド内に止まるのを防止することができる。

また、移動制御部１４２０は、連結されたフィールド間のキャラクタの移動を可とする第１期間とフィールド間のキャラクタの移動を不可とする第２期間を交互に発生するので、第１期間においてフィールド間のキャラクタの移動を行わせ、第２期間において同一フィールド内で各キャラクタを対戦させることができる。

また、連結制御部１４１０は、第１期間と時間的関連性を有するタイミングにおいて、互いに連結する領域を切り換える処理を繰り返すので、第２期間内のゲームの進行により変化した各フィールドのキャラクタ数に応じて、互いに連結するフィールドを適切に決定することができる。

また、移動制御部１４２０は、１のフィールドのフィールド内キャラクタ数が所定数以上である場合あるいはキャラクタ入場数の総和が所定数以上である場合に、他のフィールドから当該１のフィールドへのキャラクタの移動を制限するので、１のフィールドにおける過密なキャラクタがさらに過密になるのを防止することができる。

また、移動制御部１４２０は、互いに連結された２つのフィールドの一方から他方へのキャラクタの通過を許可し、他方から一方へのキャラクタの通過を禁止することが可能であるので、必要に応じて、２つのフィールド間の一方通行化を行うことができる。

また、移動制御部１４２０は、互いに連結された２つのフィールドの一方から他方へ通過したキャラクタが他方から一方へ戻るのを禁止することができるので、キャラクタが強敵を回避して同じ２つのフィールド間の往復移動を行うのを防止することができる。

［Ｂ．変形例］
以上の形態は多様に変形され得る。具体的な変形の態様を以下に例示する。以下の例示から任意に選択された２以上の態様は、相互に矛盾しない範囲内で適宜に併合され得る。なお、以下に例示する変形例において作用や機能が実施形態と同等である要素については、以上の説明で参照した符号を流用して各々の詳細な説明を適宜に省略する。

［変形例１］
図１８は上記実施形態の一変形例であるゲームシステム１ａの構成を示すブロック図である。このゲームシステム１ａは、モバイルゲームを中心に最も普及しているゲームシステムである。端末３０ａ－１～３０ａ－Ｍは、スマートフォン等のモバイル端末である。このゲームシステム１ａでは、ゲームサーバ１０ａがユーザ情報管理部１１００、マッチング部１２００、ゲーム進行処理部１３００ａ、フィールド管理部１４００の各処理を実行する。端末３０ａは、ゲーム進行処理部１３００ｂと、ＡＶ処理部１５００と、ユーザに対する画像および音声の出力と操作情報の受付を行う入出力部１６００の各処理を実行する。

ゲーム進行処理部１３００ｂが行う処理は、上記実施形態のゲーム進行処理部１３００が行う処理の一部の処理である。一部の処理とは、上記実施形態のフィールド内処理部１３１０により行われたキャラクタＣの移動、爆弾の爆発までの時間の計測等である。ゲーム進行処理部１３００ａは、上記実施形態のゲーム進行処理部１３００が行った処理からゲーム進行処理部１３００ｂの処理を除いた処理を実行する。例えばゲーム進行処理部１３００ａは、端末３０ａのゲーム進行処理部１３００ｂからキャラクタＣの移動等に関する通知を受け、この通知に基づいてフィールド情報テーブル２２００を更新する。

端末３０ａのＡＶ処理部１５００は、ゲームサーバ１０ａが管理するフィールド情報テーブル２２００を参照することにより、当該端末３０ａに対応付けられたキャラクタＣが所在するフィールドＦＤの画像を生成してユーザに提供する。

ゲームサーバ１０ａのフィールド管理部１４００は、上記実施形態と同様、フィールド間の連結制御、ゲートを介したフィールド間のキャラクタの移動制御を行う。

この態様によれば、画像処理を端末３０ａ側で行うので、ゲームサーバ１０ａは上記実施形態のクラウドサーバ１０のような強力なＡＶ処理部を必要としない。このため、上記実施形態と比べて、サーバが安価になる。

［変形例２］
図１９は上記実施形態の他の変形例であるゲームシステム１ｂの構成を示すブロック図である。このゲームシステム１ｂは、ＭＭＯ（Massively Multiplayer Online）ゲーム等のゲームシステムと同様な形態のシステムであり、ゲームの進行が端末主導で行われる。

図１９において、マッチングサーバ１０ｂは、上記実施形態のマッチング部１２００の処理のみを実行する。端末３０ｂ－１～３０ｂ－Ｍは、いずれか１台がホスト端末として機能し、他はスレーブ端末として機能する。ホスト端末は、上記実施形態のユーザ情報管理部１１００、ゲーム進行処理部１３００、フィールド管理部１４００およびＡＶ処理部１５００としての処理と、画像および音声の出力を行うとともにユーザから操作情報を受け取る入出力部１６００としての処理を実行する。スレーブ端末は、ＡＶ処理部１５００および入出力部１６００としての処理を実行する。スレーブ端末は、ホスト端末に対して操作情報を送信し、スレーブ端末に対応付けられたキャラクタの所在するフィールドのフィールド情報テーブル２２００をホスト端末から受け取る。スレーブ端末のＡＶ処理部１５００は、このフィールド情報テーブル２２００に基づいて、ユーザに提供する画像および音声を生成する。

この態様によれば、マッチングサーバの行う処理が格段と少なくなるので、サーバのコストが著しく低減される。

［変形例３］
連結制御部１４１０は、連結制御部１４１０により連結された各フィールドについて、当該フィールドの連結先のフィールドの状況を示す情報を生成してもよい。この態様において、連結制御部１４１０は、連結テーブル２３００に含まれる各フィールドＩＤについて、次の処理を実行する。

連結制御部１４１０は、連結テーブル２３００において、フィールドＩＤに対応した連結先フィールドＩＤと連結部を求める。そして、連結制御部１４１０は、連結先フィールドＩＤに対応したフィールド情報テーブル２２００を参照することにより、連結部に連結されたフィールド内に所在するキャラクタとその数を求める。そして、連結制御部１４１０は、連結部に連結されたフィールド内に所在するキャラクタとその数を連結部の位置に表示することを指示する表示指令をフィールド情報テーブル２２００に書き込むのである。

図２０はこのような連結制御部１４１０の処理が行われることにより端末３０に表示されるフィールドの画像を例示するものである。この例では、フィールドＦＤの下辺の連結部に当該フィールドの下側のフィールドにキャラクタが２体所在することと、それらのキャラクタの画像が表示されている。また、この例では、フィールドＦＤの右辺の連結部に当該フィールドＦＤの右側のフィールドにキャラクタが３体所在することと、それらのキャラクタの画像が表示されている。

フィールドＦＤ内のキャラクタを操作するユーザは、この表示を確認することにより、現在のフィールドＦＤの下側のフィールドまたは右側のフィールドにキャラクタを移動させるべきか否かを判断することができる。

なお、キャラクタとその数を表示するだけでなく、連結されたフィールドに所在するキャラクタが所持する爆弾、銃弾等のアイテムに関する情報、キャラクタを操作するユーザのスキルレベル、キャラクタが取得したポイント等を併せて表示するようにしてもよい。

［変形例４］
変形例３において、連結制御部１４１０は、連結されるフィールドに所在するキャラクタに関する情報をユーザに提供した。しかし、変形例４において、連結制御部１４１０は、キャラクタが所在するフィールドに連結されるフィールドの一部の画像、具体的には連結部よりの一部の画像をユーザに提供する。

具体的には、連結制御部１４１０は、連結テーブル２３００に含まれる各フィールドＩＤについて、次の処理を実行する。まず、連結制御部１４１０は、連結テーブル２３００において、フィールドＩＤに対応した連結先フィールドＩＤと連結部を求める。そして、連結制御部１４１０は、連結先フィールドＩＤに対応したフィールド情報テーブル２２００において連結部から所定距離内の位置情報を含む各情報（例えばハードブロック情報、ソフトブロック情報、キャラクタ情報等）を抽出し、この抽出情報を上記フィールドＩＤに対応したフィールド情報テーブル２２００に付加する。ＡＶ生成部１５１０は、フィールド情報テーブル２２００とこれに付加された抽出情報とに基づいて、ユーザに提供するフィールドの画像を生成するのである。

図２１はこの変形例４において端末３０に表示されるフィールドの画像を例示するものである。この例では、フィールドＦＤの下側のフィールドの連結部寄りの領域の画像と、右側のフィールドの連結部寄りの領域の画像が表示されている。この態様においても、ユーザは、この表示を確認することにより、現在のフィールドＦＤの下側のフィールドまたは右側のフィールドのいずれのフィールドにキャラクタを移動させるべきかを判断することができる。

［変形例５］
ユーザがゲームに参加するために操作する装置として、ゲーム機とこのゲーム機に接続された複数のコントローラを用いてもよい。この場合、コントローラが操作情報の発生元となるので、コントローラが上記実施形態における端末３０となる。ＡＶ処理部１５００は、１つのゲーム機に接続された各コントローラ（端末）に対応付けられた各キャラクタが所在する各フィールドの画像を生成し、これらの画像を合成してゲーム機に供給する。各コントローラを操作する各ユーザは、各コントローラが接続されたゲーム機の表示部を共用してコントローラを操作し、ゲームを進行させる。

［変形例６］
連結制御において参照するフィールド内キャラクタ数には、ＮＰＣの数を含めてもよく、含めなくてもよい。また、ＮＰＣについては、最初の連結制御が行われるまでの間に、他のフィールドに移動すると見せかけて消滅させてもよい。

［変形例７］
連結制御部１４１０が行う「連結」は、グループ内の全てのフィールドが同グループ内のいずれかのフィールドに連結された１つのグループを生じさせてもよい。しかし、「連結」は、１つのグループ内の全てのフィールドが同グループ内のいずれかのフィールドに連結されているが、他のグループ内のフィールドには連結されていない複数のフィールドを生じさせてもよい。

［変形例８］
連結制御部１４１０が行う「連結」には各種の態様が考えられる。例えば全フィールドをフィールド内キャラクタ数が閾値以上であるＡグループと閾値未満であるＢグループに分け、ＡグループのフィールドとＢグループのフィールドが隣り合い、かつ、隣り合うフィールド間のフィールド内キャラクタ数の差分が極力大きくなるように各フィールドを配列して各フィールドを連結する、といった方法が考えられる。

また、キャラクタで混んでいるフィールドには必ず空いている領域が連結され、空いているフィールドには必ず混んでいるフィールドが連結される、ということが約束されていると、ユーザによってはゲームの興趣性に欠けると感じる可能性がある。そこで、ある確率で、混んでいるフィールドに混んでいるフィールドを連結し、空いているフィールドに空いているフィールドを連結する、という方法も考えられる。

［変形例９］
上記実施形態では、フィールドＦＤの１つのゲートと、他の１つのフィールドＦＤの１つのゲートとを共有させることにより、１つのフィールドの一辺に１つのフィールドを連結した。しかし、連結の態様はこれに限定されるものではない。図２２に例示するように、フィールドＦＤａ、ＦＤｂおよびＦＤｃに各々の一辺に設けられた各ゲートを共有させることにより、フィールドＦＤａの一辺に２つのフィールドＦＤｂおよびＦＤｃを連結してもよい。この場合のキャラクタの移動に関して例えば次のような態様が考えられる。フィールドＦＤｂおよびＦＤｃからフィールドＦＤａとの連結部のゲートＧを介して退場するキャラクタは全てフィールドＦＤａに入場する。フィールドＦＤａからフィールドＦＤｂおよびＦＤｃとの連結部のゲートＧを介して退場するキャラクタはフィールドＦＤｂまたはＦＤｃのいずれかがランダムに入場先として選択される。

［変形例１０］
上記実施形態では、ゲートが開状態となる第１期間に合わせて連結制御を行ったが、この第１期間とは関係なく定期的に行っても良い。また、上記実施形態では、フィールドの境界に設けられた開状態のゲートを介してのみフィールド間のキャラクタの移動が可能であったが、フィールドの境界は常に移動可能とし、連結制御により１のフィールドから移動可能な他のフィールドを切り換えるようにしてもよい。

［変形例１１］
上記実施形態において、連結制御部１４１０は、１のフィールドに所在するキャラクタの数が所定数以下である場合に、当該キャラクタに不利益を与えることにより当該キャラクタに他のフィールドへの移動を促した。しかし、そのようにする代わりに、連結制御部１４１０は、１のフィールドに所在するキャラクタの数が所定数以下である場合に、当該キャラクタを強制的に他のフィールドに移動させてもよい。この場合の「移動」は、１のフィールドに連結されたフィールド以外の他のフィールドへの移動であってもよい。この態様においても、少ない数のキャラクタが同じフィールド内に止まるのを防止することができる。

［変形例１２］
互いに連結するフィールドを決定する際に参照するキャラクタ数として、フィールド内のライフ情報の総和を用いてもよい。対戦ゲームによっては、１回の敗北ではキャラクタが対戦から離脱せず、所定の複数回数の敗北によりキャラクタが対戦から離脱する場合がある。そこで、フィールド内に所在する各キャラクタについて、対戦から離脱するまでの残り敗北回数を示すライフ情報を求め、このライフ情報の総和をフィールドの連結制御に用いる。この態様においても、上記実施形態と同様な効果が得られる。

［変形例１３］
上記実施形態では、制限情報設定タイミングごとに設定する制限情報の種別を固定したが、各フィールドのフィールド内キャラクタ数の変化に応じて、設定する制限情報の種別を決定するようにしてもよい。例えば制限対象４に対応した制限を行っている場合において、制限対象４に該当する移動先である連結先フィールドのフィールドキャラクタ数が変化し、連結先フィールドへの移動を禁止する必要がなくなったとき、制限対象４に対応した制限情報を解除してもよい。あるいは、制限情報の設定を各フィールドのフィールド内キャラクタ数の変化に基づいて動的に変化させてもよい。例えば連結されたフィールドの全域におけるフィールド内キャラクタ数の分布に基づいて、フィールド内キャラクタ数が全域において均一となるようなキャラクタＣの流れを作る制限情報を設定してもよい。

［変形例１４］
上記実施形態では、キャラクタＣのゲートの通過が制限対象に該当する場合に、単にゲートの通過を拒否するのみであったが、例えば端末３０に表示される画面内において、開いているゲートを閉じる等、ゲートの通過が制限されていることを視覚的に理解できるようにしてもよい。あるいは移動制御部１４２０が定期的に連結テーブル２３００および全てのフィールド情報テーブル２２００を参照することにより、制限対象３または４に該当する移動が行われる可能性のあるゲートを求め、端末３０に表示される画面内において、該当するゲートを閉じる制御を行ってもよい。

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

［付記１］
この発明の一態様であるプログラムは、複数のキャラクタ（Ｃ）により進行するゲームにおいて、コンピュータ（１１）を、複数の領域（ＦＤ）のいずれかの領域において、前記ゲームに係るキャラクタ（Ｃ）を当該キャラクタに対応付けられた端末（３０）から取得される操作情報に基づいて制御する第１制御部（１３００）と、前記複数の領域における前記キャラクタの状況 に基づいて、前記複数の領域における１の領域と他の領域とを連結する第２制御部（１４００）として機能させる。

この態様によれば、多数のキャラクタ（Ｃ）によるゲームを実現し、かつ、キャラクタ（Ｃ）の過疎・過密の発生を防止することができる。また、ユーザには、広い領域の中の一部の領域において、他のキャラクタとゲームを行っている感覚を与えることができる。

「キャラクタの状況」とは、キャラクタに関連する情報であり、例えば、キャラクタの数であっても良い。また、例えば、キャラクタに関連付けられたパラメータの情報であっても良い。また、「連結」とは、１の領域と他の領域との間のキャラクタの移動を可能にする処理であり、例えば複数の領域の中から１の領域と他の領域とを選択し、選択した両領域を連続させる処理である。

［付記２］
付記１において、前記第２制御部（１４００）は、前記１の領域（ＦＤ）の境界の一部と前記他の領域（ＦＤ）の境界の一部とを互いに共有させることにより前記１の領域と前記他の領域とを連結する。
この態様によれば、境界の一部を互いに供給することで、フィールド同士の接続を不自然なものとすることを防ぐことができる。

［付記３］
付記１または２において、前記ゲームは、複数のキャラクタ間の対戦ゲームである。

［付記４］
付記３において、前記第１制御部（１３００）は、前記対戦ゲームにおいて他のキャラクタに敗北したキャラクタを前記対戦ゲームから離脱させる。
「対戦ゲームから離脱させる」とは、その対戦ゲームでの勝利の可能性を失わせることであり、その一例として、その対戦ゲームの進行に影響を与える権利を失わせることや、キャラクタの操作を不能にすることが挙げられる。

［付記５］
付記１～４において、前記第２制御部（１４００）は、前記複数の領域の各々におけるキャラクタの数に基づいて、互いに連結する領域を決定する。
この態様によれば、複数の領域の各々におけるキャラクタの数に基づいて、互いに連結する領域を決定するので、キャラクタの過疎・過密が解消されるように、適切に領域の連結を行うことができる。

「キャラクタの数」は、キャラクタの過疎・過密の程度を示す情報であり、複数の領域の広さが同じである場合は、各領域に所在するキャラクタの数、各領域の広さが異なる場合には、各領域の単位面積当たりのキャラクタ数である。「キャラクタの数」には、各領域に所在するキャラクタのライフ情報を反映させてもよい。

［付記６］
付記１～５において、前記第２制御部（１４００）は、１の領域に所在するキャラクタの数が所定数以下である場合に、当該キャラクタを他の領域に移動させる。
この態様によれば、所在するキャラクタ数の少ない領域からキャラクタを退場させ、当該領域を消滅させることが可能になる。
「他の領域」は、「１の領域」に連結された領域であってもよく、それ以外の領域であってもよい。

［付記７］
付記１～５において、前記第２制御部（１４００）は、１の領域に所在するキャラクタの数が所定数以下である場合に、当該キャラクタに対して不利益を与える。
この態様によれば、所在するキャラクタ数の少ない領域において、キャラクタに不利益を与えることによりキャラクタを退場させ、当該領域を消滅させることが可能になる。

「キャラクタに対して不利益を与える」とは、１の領域に連結された領域に比して、１の領域においてゲームを有利に進める妨げを増やすことである。例えば「キャラクタに不利益を与える」ことは、ゲームを有利に進める要素を減少させること、具体的には、キャラクタの所持アイテムを減らす等であってもよい。また、ゲームが対戦ゲームである場合、「キャラクタに不利益を与える」ことは、連結された領域に比して、対戦ゲームからの離脱の可能性を高くすることであってもよい。あるいは「キャラクタに不利益を与える」ことは、連結された領域にはない離脱要因を１の領域において発生することであってもよい。

［付記８］
付記１～７において、前記第２制御部（１４００）は、１の領域に所在するキャラクタの数が所定数以上である場合、他の領域から当該１の領域へのキャラクタの移動を制限する。
この態様によれば、キャラクタが過密な領域が発生するのを防止することができる。

［付記９］
付記１～８において、前記第２制御部（１４００）は、連結された領域間のキャラクタの移動を可とする第１期間と前記領域間のキャラクタの移動を不可とする第２期間を交互に発生する。
この態様によれば、第１期間において領域間のキャラクタの移動を行わせ、第２期間において同一領域内で各キャラクタにゲームを進行させることができる。

［付記１０］
付記９において、前記第２制御部（１４００）は、前記第１期間と時間的関連性を有するタイミングにおいて、互いに連結する領域を切り換える処理を繰り返す。
この態様によれば、第２期間内のゲームの進行により変化した各領域のキャラクタの状況に応じて、互いに連結する領域を適切に決定することができる。

［付記１１］
付記１～８において、前記第２制御部（１４００）は、時間間隔を空けて、互いに連結する領域を切り換える処理を繰り返す。
この態様によれば、互いに連結する領域を切り換える処理が繰り返されるので、各領域におけるキャラクタの状況の変化に適切に対応することができる。

［付記１２］
付記１～１１において、前記第２制御部（１４００）は、前記第２制御部により連結された各領域について、当該領域の連結先の領域の状況を示す情報を生成する。
この態様によれば、ユーザは、連結先の領域の状況を示す情報を確認することにより連結先の領域にキャラクタを移動させるべきか否かを判断することができる。

「連結先の領域の状況」とは、例えば、連結先の領域に所在するキャラクタに関する情報であり、「キャラクタに関する情報」とは、例えば、キャラクタの数であっても良いし、また例えば、キャラクタに関連付けられたパラメータに基づく情報であっても良い。また例えば、キャラクタの種類を識別可能な情報であっても良い。また、「連結先の領域の状況」とは、例えば、連結先の領域に所在するアイテムの情報であっても良い。「アイテムの情報」とは、例えば、アイテムの数に関する情報であっても良いし、また例えば、アイテムの種類を識別可能な情報であっても良い。ここで、「アイテム」とは、ユーザやキャラクタが利用可能なオブジェクトであり、利用することでゲームの進行に影響を与えるものであり、例えば、敵キャラクタを攻撃するための武器などである。

［付記１３］
付記１～１２において、前記第２制御部（１４００）は、互いに連結された２つの領域の一方から他方へのキャラクタの通過を許可し、他方から一方へのキャラクタの通過を禁止する。
この態様によれば、各領域のキャラクタの状況が好ましい状況になるように、領域間のキャラクタの移動を制限することができる。

［付記１４］
付記１～１２において、前記第２制御部（１４００）は、互いに連結された２つの領域の一方から他方へ通過したキャラクタが他方から一方へ戻るのを禁止する。
この態様によれば、例えば強敵との対戦を避けて、同じ２つの領域間を往復する等、ゲームの公正を損なうキャラクタの移動を禁止することができる。

［付記１５］
本発明の一態様によるゲーム装置（１０）は、複数のキャラクタ（Ｃ）によりゲームを進行させるゲーム装置において、複数の領域（ＦＤ）のいずれかの領域において、前記ゲームに係るキャラクタ（Ｃ）を当該キャラクタに対応付けられた端末（３０）から取得される操作情報に基づいて制御する第１制御部（１３００）と、前記複数の領域における前記キャラクタの状況に基づいて、前記複数の領域における１の領域と他の領域とを連結する第２制御部（１４００）とを有する。
この態様においても付記１と同様な効果が得られる。

［付記１６］
本発明の一態様によるゲームシステム（１）は、複数のキャラクタ（Ｃ）によりゲームを進行させるゲームシステムにおいて、複数のユーザにより操作される複数の端末（３０）と、前記複数のユーザによる前記複数の端末に対する操作情報を受信するサーバ（１０）とを有し、前記サーバが、複数の領域（ＦＤ）のいずれかの領域において、前記ゲームに係るキャラクタ（Ｃ）を当該キャラクタに対応付けられた端末（３０）から取得される操作情報に基づいて制御する第１制御部（１３００）と、前記複数の領域における前記キャラクタの状況に基づいて、前記複数の領域における１の領域と他の領域とを連結する第２制御部（１４００）とを有する。
この態様においても付記１と同様な効果が得られる。

［付記１７］
本発明の一態様によるゲーム制御方法は、複数のキャラクタ（Ｃ）によりゲームを進行させる方法において、コンピュータ（１１）が、複数の領域（ＦＤ）のいずれかの領域において、前記ゲームに係るキャラクタ（Ｃ）を当該キャラクタに対応付けられた端末（３０）から取得される操作情報に基づいて制御する第１制御（１３００）と、前記複数の領域における前記キャラクタの状況に基づいて、前記複数の領域における１の領域と他の領域とを連結する第２制御（１４００）とを実行する。
この態様においても付記１と同様な効果が得られる。

１…ゲームシステム、１０…クラウドサーバ、ＮＷ…ネットワーク、３０，３０－１～３０－Ｍ…端末、１１，３１…制御部、１２，３２…記憶部、１３，３３…通信部、３４…操作部、３５…表示部、ＰＧｓ…サーバプログラム、ＰＧｔ…端末プログラム、Ｃ…キャラクタ、ＦＤ，ＦＤ１，ＦＤ２，ＦＤ３…フィールド、Ｇ…ゲート、ＨＢ…ハードブロック、ＳＢ…ソフトブロック、１１００…ユーザ情報管理部、１２００…マッチング部、１３００…ゲーム進行処理部、１３１０…フィールド内処理部、１３２０…振り分け部、１４００…フィールド管理部、１４１０…連結制御部、１４２０…移動制御部、１５００…ＡＶ処理部、１５１０…ＡＶ生成部、２１００…ユーザ情報テーブル、２２００…フィールド情報テーブル、２３００…連結テーブル、ＰＢ…プレッシャブロック。

Claims (16)

1. 複数のキャラクタにより進行するゲームにおいて、
   コンピュータを、
   複数の領域のいずれかの領域において、前記ゲームに係るキャラクタを当該キャラクタに対応付けられた端末から取得される操作情報に基づいて制御する第１制御部と、
   前記複数の領域における前記キャラクタの状況に基づいて、前記複数の領域における１の領域と他の領域とを連結する第２制御部であって、前記複数の領域の各々におけるキャラクタの数に基づいて、互いに連結する領域を決定する第２制御部と
   して機能させることを特徴とするプログラム。
2. 前記第２制御部は、前記１の領域の境界の一部と前記他の領域の境界の一部とを互いに共有させることにより前記１の領域と前記他の領域とを連結することを特徴とする請求項１に記載のプログラム。
3. 前記ゲームは、複数のキャラクタ間の対戦ゲームであることを特徴とする請求項１または２に記載のプログラム。
4. 前記第１制御部は、前記対戦ゲームにおいて他のキャラクタに敗北したキャラクタを前記対戦ゲームから離脱させることを特徴とする請求項３に記載のプログラム。
5. 前記第２制御部は、１の領域に所在するキャラクタの数が所定数以下である場合に、当該キャラクタを他の領域に移動させることを特徴とする請求項１～４のいずれか１項に記載のプログラム。
6. 前記第２制御部は、１の領域に所在するキャラクタの数が所定数以下である場合に、当該キャラクタに対して不利益を与えることを特徴とする請求項１～４のいずれか１項に記載のプログラム。
7. 前記第２制御部は、１の領域に所在するキャラクタの数が所定数以上である場合、他の領域から当該１の領域へのキャラクタの移動を制限することを特徴とする請求項１～６のいずれか１項に記載のプログラム。
8. 前記第２制御部は、連結された領域間のキャラクタの移動を可とする第１期間と前記領域間のキャラクタの移動を不可とする第２期間を交互に発生することを特徴とする請求項１～７のいずれか１項に記載のプログラム。
9. 前記第２制御部は、前記第１期間と時間的関連性を有するタイミングにおいて、互いに連結する領域を切り換える処理を繰り返すことを特徴とする請求項８に記載のプログラム。
10. 前記第２制御部は、時間間隔を空けて、互いに連結する領域を切り換える処理を繰り返すことを特徴とする請求項１～７のいずれか１項に記載のプログラム。
11. 前記第２制御部は、前記第２制御部により連結された各領域について、当該領域の連結先の領域の状況を示す情報を生成することを特徴とする請求項１～１０のいずれか１項に記載のプログラム。
12. 前記第２制御部は、互いに連結された２つの領域の一方から他方へのキャラクタの通過を許可し、他方から一方へのキャラクタの通過を禁止することを特徴とする請求項１～１１のいずれか１項に記載のプログラム。
13. 前記第２制御部は、互いに連結された２つの領域の一方から他方へ通過したキャラクタが他方から一方へ戻るのを禁止することを特徴とする請求項１～１１のいずれか１項に記載のプログラム。
14. 複数のキャラクタによりゲームを進行させるゲーム装置において、
    複数の領域のいずれかの領域において、前記ゲームに係るキャラクタを当該キャラクタに対応付けられた端末から取得される操作情報に基づいて制御する第１制御部と、
    前記複数の領域における前記キャラクタの状況に基づいて、前記複数の領域における１の領域と他の領域とを連結する第２制御部であって、前記複数の領域の各々におけるキャラクタの数に基づいて、互いに連結する領域を決定する第２制御部と
    を有することを特徴とするゲーム装置。
15. 複数のキャラクタによりゲームを進行させるゲームシステムにおいて、
    複数のユーザにより操作される複数の端末と、
    前記複数のユーザによる前記複数の端末に対する操作情報を受信するサーバとを有し、
    前記サーバが、
    複数の領域のいずれかの領域において、前記ゲームに係るキャラクタを当該キャラクタに対応付けられた端末から取得される操作情報に基づいて制御する第１制御部と、
    前記複数の領域における前記キャラクタの状況に基づいて、前記複数の領域における１の領域と他の領域とを連結する第２制御部であって、前記複数の領域の各々におけるキャラクタの数に基づいて、互いに連結する領域を決定する第２制御部と
    を有することを特徴とするゲームシステム。
16. 複数のキャラクタによりゲームを進行させる方法において、
    コンピュータが、
    複数の領域のいずれかの領域において、前記ゲームに係るキャラクタを当該キャラクタに対応付けられた端末から取得される操作情報に基づいて制御する第１制御と、
    前記複数の領域における前記キャラクタの状況に基づいて、前記複数の領域における１の領域と他の領域とを連結する第２制御であって、前記複数の領域の各々におけるキャラクタの数に基づいて、互いに連結する領域を決定する第２制御と
    を実行することを特徴とするゲーム制御方法。
    

Images