(57)【特許請求の範囲】
【請求項１】
複数のプレイヤー端末とネットワークを介して接続されるサーバー装置であって、
グループ数の初期上限値、及び、グループの定員数に対する所属人数の割合であるグループ所属率の上限値よりも小さい初期閾値を記憶する記憶部と、
グループ数の前記初期上限値に基づいて、前記初期閾値のグループ所属率が設定された複数のグループをゲーム開始時に作成するグループ作成部と、
ゲーム開始後に前記プレイヤー端末からグループへの参加要求があったときに、
全てのグループのグループ所属率が前記初期閾値に達するまでは、当該プレイヤー端末を利用するプレイヤーを、グループ所属率が前記初期閾値に達していないグループに所属させ、全てのグループのグループ所属率が前記初期閾値に達した後は、当該プレイヤー端末を利用するプレイヤーを、グループ所属率が上限値に達していないグループに所属させるプレイヤー配属部と、
を備えたことを特徴とするサーバー装置。
【請求項２】
請求項１に記載のサーバー装置であって、
全てのグループのグループ所属率が上限値に達した後に、グループ数の上限値を前記初期上限値から変動させる上限値変動部と、
グループ数の変動後の上限値に基づいて、新たな前記グループを追加作成するグループ追加作成部と、を備え、
前記プレイヤー配属部は、
全てのグループのグループ所属率が上限値に達した後は、当該プレイヤー端末を利用するプレイヤーを、追加作成された新たなグループに所属させる、
ことを特徴とするサーバー装置。
【請求項３】
請求項２に記載のサーバー装置であって、
複数のグループのそれぞれについて、グループ単位で設定されたミッションを各グループに所属する各プレイヤーにそれぞれ与えてゲームを進行させるゲーム処理部と、
グループ全体についてミッションの成功率を算出する算出部と、
算出された前記成功率に基づいて、グループ所属率の閾値を前記初期閾値から変動させる閾値変動部と、を備え、
前記グループ追加作成部は、変動後の閾値のグループ所属率が設定された新たなグループを追加作成する、
ことを特徴とするサーバー装置。
【請求項４】
請求項２に記載のサーバー装置であって、
前記記憶部は、グループの初期定員数を記憶し、
複数のグループのそれぞれについて、グループ単位で設定されたミッションを各グループに所属する各プレイヤーにそれぞれ与えてゲームを進行させるゲーム処理部と、
グループ全体についてミッションの成功率を算出する算出部と、
算出された前記成功率に基づいて、グループの定員数を初期定員数から変動させる定員数変動部と、を備え、
前記グループ追加作成部は、変動後の定員数が設定された新たなグループを追加作成する、
ことを特徴とするサーバー装置。
【請求項５】
請求項３又は４に記載のサーバー装置であって、
前記ゲーム処理部は、前記算出部によって算出された前記成功率に基づいて、グループ単位で設定された前記ミッションの難易度を変更する、
ことを特徴とするサーバー装置。
【請求項６】
複数のプレイヤー端末とネットワークを介して接続されるサーバー装置に、
グループ数の初期上限値、及び、グループの定員数に対する所属人数の割合であるグループ所属率の上限値よりも小さい初期閾値を記憶部に記録する処理と、
グループ数の前記初期上限値に基づいて、前記初期閾値のグループ所属率が設定された複数のグループをゲーム開始時に作成するグループ作成処理と、
ゲーム開始後に前記プレイヤー端末からグループへの参加要求があったときに、
全てのグループのグループ所属率が前記初期閾値に達するまでは、当該プレイヤー端末を利用するプレイヤーを、グループ所属率が前記初期閾値に達していないグループに所属させ、全てのグループのグループ所属率が前記初期閾値に達した後は、当該プレイヤー端末を利用するプレイヤーを、グループ所属率が上限値に達していないグループに所属させるプレイヤー配属処理と、
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバー装置、及び、プログラムに関する。
【背景技術】
【０００２】
複数のプレイヤー端末とネットワークを介して接続されるサーバー装置であって、プレイヤー端末からエントリーを事前に受け付けた後、エントリーしたプレイヤーのレベルに応じたグループ分けを行い、グループ分けされたグループ内で対戦ゲームを行なわせるサーバー装置が知られている（たとえば、特許文献１）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００３−１３５８５４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
このようにゲーム開始前にエントリーを行った上でプレイヤーをいずれかのグループに所属させる場合は、ゲーム参加人数を予め把握することができる。
これに対して、事前にエントリーを行うことなく、ゲーム開始後に任意のタイミングでサーバーにアクセスしたプレイヤーをいずれかのグループに所属させる場合には、アクセス数を予測することができないため、ゲーム参加人数を予め把握することができない。そのため、アクセスした順番にプレイヤーを或るグループに所属させ、或るグループが定員に達すると次のグループを作成してプレイヤーを所属させていた。
しかしながら、このような手順によってプレイヤーをグループに配属すると、すぐにグループが定員に達してしまうため、グループ人数が多いほどミッションを達成し易くなることで、ゲーム難易度を低下させるおそれがあった。
本発明は、このような事情に鑑みてなされたものであり、その目的とするところは、各グループの人数を適切にコントロールすることにより、グループごとのゲーム難易度をバランス良く調整することにある。
【課題を解決するための手段】
【０００５】
上記課題を解決するための本発明の主たる発明は、
複数のプレイヤー端末とネットワークを介して接続されるサーバー装置であって、
グループ数の初期上限値、及び、グループの定員数に対する所属人数の割合であるグループ所属率の上限値よりも小さい初期閾値を記憶する記憶部と、
グループ数の前記初期上限値に基づいて、前記初期閾値のグループ所属率が設定された複数のグループをゲーム開始時に作成するグループ作成部と、
ゲーム開始後に前記プレイヤー端末からグループへの参加要求があったときに、
全てのグループのグループ所属率が前記初期閾値に達するまでは、当該プレイヤー端末を利用するプレイヤーを、グループ所属率が前記初期閾値に達していないグループに所属させ、全てのグループのグループ所属率が前記初期閾値に達した後は、当該プレイヤー端末を利用するプレイヤーを、グループ所属率が上限値に達していないグループに所属させるプレイヤー配属部と、
を備えたことを特徴とするサーバー装置である。
本発明の他の特徴については、本明細書及び添付図面の記載により明らかにする。
【発明の効果】
【０００６】
本発明によれば、各グループの人数を適切にコントロールすることにより、グループごとのゲーム難易度をバランス良く調整することができる。
【図面の簡単な説明】
【０００７】
【図１】ゲームシステム１の全体構成例を示す図である。
【図２】サーバー装置１０の機能上の構成を示すブロック図である。
【図３】プレイヤー端末２０の機能上の構成を示すブロック図である。
【図４】キャラクター情報のデータ構造例を示す図である。
【図５】プレイヤー情報のデータ構造例を示す図である。
【図６】所有キャラクター情報のデータ構造例を示す図である。
【図７】フィールド情報のデータ構造例を示す図である。
【図８】ゲーム結果情報のデータ構造例を示す図である。
【図９】対戦情報のデータ構造例を示す図である。
【図１０】プレイヤーをフィールドに配属するときの概要手順（その１）について説明する図である。
【図１１】プレイヤーをフィールドに配属するときの概要手順（その２）について説明する図である。
【図１２】プレイヤーをフィールドに配属するときの概要手順（その３）について説明する図である。
【図１３】ゲームシステム１の動作例を説明するためのフローチャートである。
【図１４】プレイヤー配属処理を説明するためのフローチャートである。
【発明を実施するための形態】
【０００８】
本明細書及び添付図面の記載により、少なくとも以下の事項が明らかとなる。
即ち、複数のプレイヤー端末とネットワークを介して接続されるサーバー装置であって、
グループ数の初期上限値、及び、グループの定員数に対する所属人数の割合であるグループ所属率の上限値よりも小さい初期閾値を記憶する記憶部と、
グループ数の前記初期上限値に基づいて、前記初期閾値のグループ所属率が設定された複数のグループをゲーム開始時に作成するグループ作成部と、
ゲーム開始後に前記プレイヤー端末からグループへの参加要求があったときに、
全てのグループのグループ所属率が前記初期閾値に達するまでは、当該プレイヤー端末を利用するプレイヤーを、グループ所属率が前記初期閾値に達していないグループに所属させ、全てのグループのグループ所属率が前記初期閾値に達した後は、当該プレイヤー端末を利用するプレイヤーを、グループ所属率が上限値に達していないグループに所属させるプレイヤー配属部と、
を備えたことを特徴とするサーバー装置である。
このようなサーバー装置によれば、ゲーム開始後にプレイヤーからグループへの参加要求があった場合であっても、各グループの人数を適切にコントロールすることにより、グループごとのゲーム難易度をバランス良く調整することが可能となる。
【０００９】
また、かかるサーバー装置であって、
全てのグループのグループ所属率が上限値に達した後に、グループ数の上限値を前記初期上限値から変動させる上限値変動部と、
グループ数の変動後の上限値に基づいて、新たな前記グループを追加作成するグループ追加作成部と、を備え、
前記プレイヤー配属部は、
全てのグループのグループ所属率が上限値に達した後は、当該プレイヤー端末を利用するプレイヤーを、追加作成された新たなグループに所属させる、こととしてもよい。
このようなサーバー装置によれば、全てのグループのグループ所属率が上限値に達した後も、引き続き、各グループの人数を適切にコントロールすることにより、グループごとのゲーム難易度をバランス良く調整することが可能となる。
【００１０】
また、かかるサーバー装置であって、
複数のグループのそれぞれについて、グループ単位で設定されたミッションを各グループに所属する各プレイヤーにそれぞれ与えてゲームを進行させるゲーム処理部と、
グループ全体についてミッションの成功率を算出する算出部と、
算出された前記成功率に基づいて、グループ所属率の閾値を前記初期閾値から変動させる閾値変動部と、を備え、
前記グループ追加作成部は、変動後の閾値のグループ所属率が設定された新たなグループを追加作成する、こととしてもよい。
このようなサーバー装置によれば、ミッションの成功率に応じて、各グループの人数を適切にコントロールすることが可能となる。
【００１１】
また、かかるサーバー装置であって、
前記記憶部は、グループの初期定員数を記憶し、
複数のグループのそれぞれについて、グループ単位で設定されたミッションを各グループに所属する各プレイヤーにそれぞれ与えてゲームを進行させるゲーム処理部と、
グループ全体についてミッションの成功率を算出する算出部と、
算出された前記成功率に基づいて、グループの定員数を初期定員数から変動させる定員数変動部と、を備え、
前記グループ追加作成部は、変動後の定員数が設定された新たなグループを追加作成する、こととしてもよい。
このようなサーバー装置によれば、ミッションの成功率に応じて、各グループの人数を適切にコントロールすることが可能となる。
【００１２】
また、かかるサーバー装置であって、
前記ゲーム処理部は、前記算出部によって算出された前記成功率に基づいて、グループ単位で設定された前記ミッションの難易度を変更する、こととしてもよい。
このようなサーバー装置によれば、ミッションの成功率に応じて、グループ間のゲームバランスをコントロールすることが可能となる。
【００１３】
次に、複数のプレイヤー端末とネットワークを介して接続されるサーバー装置に、
グループ数の初期上限値、及び、グループの定員数に対する所属人数の割合であるグループ所属率の上限値よりも小さい初期閾値を記憶部に記録する処理と、
グループ数の前記初期上限値に基づいて、前記初期閾値のグループ所属率が設定された複数のグループをゲーム開始時に作成するグループ作成処理と、
ゲーム開始後に前記プレイヤー端末からグループへの参加要求があったときに、
全てのグループのグループ所属率が前記初期閾値に達するまでは、当該プレイヤー端末を利用するプレイヤーを、グループ所属率が前記初期閾値に達していないグループに所属させ、全てのグループのグループ所属率が前記初期閾値に達した後は、当該プレイヤー端末を利用するプレイヤーを、グループ所属率が上限値に達していないグループに所属させるプレイヤー配属処理と、
を実行させるためのプログラムである。
このようなプログラムによれば、各グループの人数を適切にコントロールすることにより、グループごとのゲーム難易度をバランス良く調整することが可能となる。
【００１４】
＝＝＝実施の形態＝＝＝
＜＜ゲームシステム１の構成について＞＞
図１は、本実施形態に係るゲームシステム１の全体構成の一例を示す図である。ゲームシステム１は、ネットワーク２（例えば、インターネット等）を介してゲームに関する各種サービスをプレイヤーに提供するものであり、サーバー装置１０と、複数のプレイヤー端末２０と、を含んで構成される。
【００１５】
＜＜サーバー装置１０の構成について＞＞
図２は、本実施形態に係るサーバー装置１０の機能上の構成を示すブロック図である。サーバー装置１０は、システム管理者等がゲームサービスを運営・管理する際に利用する情報処理装置（例えば、ワークステーションやパーソナルコンピューター等）であり、プレイヤー端末２０から各種のコマンド（リクエスト）を受信すると、プレイヤー端末２０上で動作可能なゲームプログラムや、プレイヤー端末２０の規格に合わせたマークアップ言語（ＨＴＭＬ等）で作成されたＷｅｂページ（ゲーム画像等）を配信（レスポンス）することができる。このサーバー装置１０は、制御部１１と、データ記憶部１２と、入力部１３と、表示部１４と、通信部１５と、を有している。
【００１６】
制御部１１は、各部間のデータの受け渡しを行うと共に、サーバー装置１０全体の制御を行うものであり、ＣＰＵ（Central Processing Unit）が所定のメモリに格納されたプログラムを実行することによって実現される。本実施形態の制御部１１は、グループ作成部１１１、プレイヤー配属部１１２、上限値変動部１１３、グループ追加作成部１１４、ゲーム処理部１１５、算出部１１６、定員数変動部１１７、閾値変動部１１８を備えている。
【００１７】
グループ作成部１１１は、ゲーム開始時に初期条件に基づいてグループを作成する処理を実行する機能を有している。本実施形態におけるグループ作成部１１１は、グループ数の初期上限値に基づいて、初期閾値のグループ所属率が設定された複数のグループをゲーム開始時に作成する。
【００１８】
プレイヤー配属部１１２は、グループにプレイヤーを所属する処理を実行する機能を有している。本実施形態におけるプレイヤー配属部１１２は、ゲーム開始後にプレイヤー端末２０からグループへの参加要求があったときに、当該プレイヤー端末を利用するプレイヤーを、複数のグループのうちのいずれかに配属する。
【００１９】
上限値変動部１１３は、グループ数の上限値を変動させる処理を実行する機能を有している。本実施形態における上限変動部１１３は、全てのグループのグループ所属率が上限値に達した後に、グループ数の上限値を初期上限値から変動させる。
【００２０】
グループ追加作成部１１４は、グループ作成部１１１が作成した複数のグループの他に追加して新たなグループを作成する処理を実行する機能を有している。本実施形態におけるグループ追加作成部１１４は、上限変動部１１３によってグループ数の上限値が変動したことに応じて、新たなグループを追加作成する。
【００２１】
ゲーム処理部１１５は、ゲームに関する処理を実行する機能を有している。本実施形態におけるゲーム処理部１１５は、複数のグループの各々について、グループ単位で設定されたミッションを各グループに所属する各プレイヤーにそれぞれ与えてゲームを進行させる。
【００２２】
算出部１１６は、グループ全体についてミッションの成功率を算出する等、各種数値の算出処理を実行する機能を有している。成功率は、グループ全体のミッション実行回数（各グループのミッション実行回数を合計した数値）に対するグループ全体のミッション成功回数（各グループのミッション成功回数を合計した数値）の割合で求めることができる。本実施形態では、算出部１１６は、所定時間ごとに（例えば１時間ごとに）、各フィールドのミッション成功率を算出して、図８に示すゲーム結果情報の更新を行う。また、算出部１１６は、プレイヤー端末２０からのアクセスがある度に、各フィールドの収容率を算出して、図７に示すフィールド情報の更新も行う。
【００２３】
定員数変動部１１７は、グループの定員数を変動させる処理を実行する機能を有している。本実施形態における定員数変動部１１７は、算出部１１６によって算出された成功率に基づいて、グループの定員数を初期定員数から変動させる。
【００２４】
閾値変動部１１８は、グループ所属率の閾値を変動させる処理を実行する機能を有している。本実施形態における閾値変動部１１８は、算出部１１６によって算出された成功率に基づいて、グループ所属率の閾値を初期閾値から変動させる。
【００２５】
記憶部１２は、システムプログラムが記憶された読み取り専用の記憶領域であるＲＯＭ（Read Only Memory）と、制御部１１による演算処理のワーク領域として使用される書き換え可能な記憶領域であるＲＡＭ（Random Access Memory）とを有しており、例えば、フラッシュメモリやハードディスク等の不揮発性記憶装置によって実現される。本実施形態の記憶部１２は、キャラクターに関する情報であるキャラクター情報と、プレイヤーに関する情報であるプレイヤー情報と、フィールドに関する情報であるフィールド情報と、ゲーム結果に関する情報であるゲーム結果情報を、少なくとも記憶している。なお、これら各情報については追って詳述する。また、記憶部１２は、フィールド数（グループ数）の初期上限値、収容率（グループ所属率）の上限値（１００％）よりも小さい初期閾値（例えば「５０％」）、及び、フィールドの初期定員数（例えば「１００人」）を記憶する。
【００２６】
入力部１３は、システム管理者等が各種データ（例えば、キャラクター情報等）を入力するためのものであり、例えば、キーボードやマウス等によって実現される。
【００２７】
表示部１４は、制御部１１からの指令に基づいてシステム管理者用の操作画面を表示するためのものであり、例えば、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）等によって実現される。
【００２８】
通信部１５は、プレイヤー端末２０との間で通信を行うためのものであり、プレイヤー端末２０から送信される各種データや信号を受信する受信部としての機能と、制御部１１の指令に応じて各種データや信号をプレイヤー端末２０へ送信する送信部として機能とを有している。通信部１５は、例えば、ＮＩＣ（Network Interface Card）等によって実現される。
【００２９】
＜＜プレイヤー端末２０の構成について＞＞
図３は、プレイヤー端末２０の機能上の構成を示すブロック図である。本実施形態のプレイヤー端末２０は、ゲームをプレイする際にプレイヤーが利用する情報処理装置（例えば、携帯電話端末、スマートフォン、タブレット型端末等）であり、サーバー装置１０に対してゲームに関する各種情報（ゲームプログラムやＷｅｂページ等）の配信要求を行うことができる。プレイヤー端末２０は、プレイヤーにＷｅｂページを閲覧させるためのＷｅｂブラウザ機能を有しているため、サーバー装置１０から配信されたＷｅｂページ（ゲーム画面等）を表示することができる。このプレイヤー端末２０は、端末制御部２１と、端末記憶部２２と、端末入力部２３と、端末表示部２４と、端末通信部２５と、を有している。
【００３０】
端末制御部２１は、各部間のデータの受け渡しを行うととともに、プレイヤー端末２０全体の制御を行うものであり、ＣＰＵ（Central Processing Unit）が所定のメモリに格納されたプログラムを実行することによって実現される。なお、本実施形態の端末制御部２１は、端末表示部２４に表示されるゲーム画面の表示態様を制御する画面表示制御部としても機能する。端末記憶部２２は、バスを介して端末制御部２１に接続され、端末制御部２１からの指令に応じて記憶されているデータを参照、読み出し、書き換える処理が行われる。この端末記憶部２２は、例えば、フラッシュメモリやハードディスク等によって実現される。端末入力部２３は、プレイヤーが各種操作（ゲーム操作等）を行うためのものであり、例えば、操作ボタン、タッチパネル等によって実現される。端末表示部２４は、端末制御部２１からの指令によりゲーム画面を表示するためのものであり、たとえば、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）等によって実現される。端末通信部２５は、ネットワーク２を介してサーバー装置１０と各種情報の送受信を行うための送受信部として機能するものであり、例えば、ＮＩＣ（Network Interface Card）等によって実現される。
【００３１】
＜＜データ構造について＞＞
図４は、サーバー装置１０の記憶部１２に記憶されるキャラクター情報のデータ構造例を示す図である。このキャラクター情報は、キャラクターＩＤ、キャラクター名、レアリティ、初期攻撃力、初期防御力、初期体力等の項目（フィールド）を有している。キャラクターＩＤは、キャラクターを識別する識別情報である。キャラクター名は、キャラクターの表示名を示す情報である。レアリティは、キャラクターの希少度を示すパラメーターである。本実施形態においては、４段階のレアリティ（「コモン」→「アンコモン」→「レア」→「スーパーレア」）がキャラクターに設定されている。キャラクターの初期攻撃力、初期防御力、初期体力は、キャラクターに最初に設定された能力値を示すパラメーターである。なお、このレアリティは４段階に限られるものではない。また、各レアリティの名称も上記の名称と異なる名称を採用しても良い。
【００３２】
図５は、サーバー装置１０の記憶部１２に記憶されるプレイヤー情報のデータ構造例を示す図である。このプレイヤー情報は、プレイヤーＩＤ、プレイヤー名、所有キャラクター情報等の項目を有している。プレイヤーＩＤは、プレイヤーを識別する識別情報である。プレイヤー名は、プレイヤーの表示名を示す情報である。所有キャラクター情報は、プレイヤーが所有するキャラクターを示す情報である。
【００３３】
図６は、所有キャラクター情報のデータ構造例を示す図である。この所有キャラクター情報は、キャラクターＩＤ、キャラクターのレベル、攻撃力、防御力、体力、獲得日時等の項目を有している。キャラクターＩＤは、プレイヤーが所有するキャラクターを識別する識別情報である。キャラクターのレベル、攻撃力、防御力、体力は、プレイヤーが所有するキャラクターに設定された現在の能力値を示すパラメーターである。これら各種パラメーターは、ゲームの進行に応じて更新される。獲得日時は、プレイヤーがキャラクターを獲得した日時を示す情報である。
【００３４】
図７は、サーバー装置１０の記憶部１２に記憶されるフィールド情報のデータ構造例を示す図である。このフィールド情報は、インデックス、フィールド名（フィールドＦｉ）、最大収容人数、収容人数、収容率、プレイヤーＩＤ等の項目を有している。インデックスは、フィールドを指定するための通し番号である。フィールド名（フィールドＦｉ）は、フィールドの表示名を示す情報である。最大収容人数は、グループの定員数を示す情報、つまり、フィールドに収容できるプレイヤーの最大人数を示す情報である。収容人数は、現時点でグループに配属されているプレイヤーの人数（所属人数）を示す情報、つまり、現時点でフィールドに収容されているプレイヤーの人数を示す情報である。収容率は、グループ所属率の一例であって、グループの定員数に対する所属人数の割合、つまり、最大収容人数に対する収容人数の割合を示す情報である。プレイヤーＩＤは、フィールドに配属されたプレイヤーを識別する識別情報である。
【００３５】
図８は、サーバー装置１０の記憶部１２に記憶されるゲーム結果情報のデータ構造例を示す図である。このゲーム結果情報は、データ取得日時、対戦情報、ミッションの成功率等の項目を有している。データ取得日時は、データが取得された日時を示す情報である。本実施形態では、１時間ごとにデータが取得される。対戦情報は、対戦に関する情報である。ミッションの成功率は、フィールド全体の対戦実行回数（各フィールドにおける対戦実行回数を合計した数値）に対するフィールド全体の勝利数（各フィールドにおける勝利数を合計した数値）の割合を示す情報である。
【００３６】
図９は、対戦情報のデータ構造例を示す図である。この対戦情報は、各フィールドにおける対戦結果についての履歴情報であって、フィールド名（フィールドＦｉ）、敵キャラクター、対戦結果等の項目を有している。フィールド名（フィールドＦｉ）は、フィールドの表示名を示す情報である。敵キャラクターは、フィールドに出現した敵キャラクターを識別する情報である。対戦結果は、対戦ゲームで勝利したこと又は敗北したことを示す勝敗情報である。
【００３７】
＜＜ゲームの概要について＞＞
ここでは、本実施形態のゲームシステム１によって提供されるゲームの概要について説明する。このゲームシステム１では、ゲームキャラクターが対応付けられた電子的なゲームカード（以下、「キャラクター」とも呼ぶ）を用いて行う各種ゲームが提供される。
【００３８】
＜対戦ゲーム＞
本実施形態におけるゲームシステム１では、複数のプレイヤーが協力して共通の敵キャラクターを倒すことをミッション（課題）とする対戦ゲームが提供される。
この対戦ゲームでは、対戦場となる複数のフィールドが設定されている。各フィールドには、対戦相手となる敵キャラクターが設定されている。プレイヤーは、対戦ゲームの開催期間中に、この対戦ゲームへの参加を要求すると、複数のフィールドのうちのいずれかに配属される。同じフィールドに配属されたプレイヤー同士はグルーピングされることになり、このフィールドに出現する共通の敵キャラクターを倒すことが、このグループに所属するプレイヤーのミッションとなる。
共通の敵キャラクターとの対戦は、グループ内の各プレイヤーがそれぞれ行う。この際、プレイヤーは、自らが所有する複数のキャラクターの中から選択したプレイヤーキャラクターを用いて、共通の敵キャラクターとの対戦を行う。
これらのキャラクター同士による対戦では、ゲーム処理部１１５により、図６に示す所有キャラクター情報、及び、図３に示すキャラクター情報が参照され、プレイヤーキャラクターに設定された各種パラメーター（攻撃力、防御力、体力等）、及び、共通の敵キャラクターに設定された各種パラメーター（初期攻撃力、初期防御力、初期体力等）に基づいて、勝敗が決定される。
【００３９】
＜プレイヤーの配属＞
本実施形態におけるゲームシステム１では、対戦ゲームに参加するプレイヤーは、複数のフィールドのうちのいずれかに配属される。
以下では、プレイヤーをフィールドに配属するときの概要手順について、図１０乃至図１２を用いて説明する。ここでは、各フィールドの定員数は「１００人」、収容率の初期閾値は「５０％」（収容率の上限値は「１００％」）、フィールド数の初期上限値は「１０」であるものとして説明する。
【００４０】
（第１の配属パターン）
図１０は、単位時間あたり４８０人のプレイヤーから対戦ゲームへの参加を要求するアクセスがあった場合に、プレイヤーをフィールドに配属するときの概要手順について説明する図である。図１０に示すように、フィールド数の初期上限値は「１０」であるため、１０個のフィールド（フィールドＦ１〜フィールドＦ１０）が作成される。
対戦ゲームの開始後に、この対戦ゲームへの参加を要求するアクセスがあると、アクセスした順番にプレイヤーをフィールドに配属する。具体的には、先ず、１番目から５０番目までにアクセスしたプレイヤーを（５０人）、フィールドＦ１に配属する。次に、フィールドＦ１の収容率が初期閾値の５０％に達したため、５１番目から１００番目までにアクセスしたプレイヤーを（５０人）、次のフィールドＦ２に配属する。同様にして、４０１番目から４５０番目までにアクセスしたプレイヤーを（５０人）、フィールドＦ９に配属する。そして、フィールドＦ９の収容率が初期閾値の５０％に達したため、４５１番目から４８０番目までにアクセスしたプレイヤーを（３０人）、次のフィールドＦ１０に配属する。
このように、全てのフィールドの収容率が初期閾値である５０％に達していないときは、アクセスしたプレイヤーを収容率が初期閾値の５０％に達するまで１つのフィールドに配属する手順を、フィールドＦ１からフィールドＦ１０まで順番に繰り返し行う。
【００４１】
（第２の配属パターン）
図１１は、単位時間あたり７００人のプレイヤーから対戦ゲームへの参加を要求するアクセスがあった場合に、プレイヤーをフィールドに配属するときの概要手順について説明する図である。図１１の上図に示すように、フィールド数の初期上限値は「１０」であるため、１０個のフィールド（フィールドＦ１〜Ｆ１０）が作成される。
対戦ゲームの開催期間中に、この対戦ゲームへの参加を要求するアクセスがあると、アクセスした順番にプレイヤーをフィールドに配属する。具体的には、先ず、図１１の上図に示すように、全てのフィールドの収容率が５０％に達するまでは、図１０に示す第１の配属パターンと同様の手順により、１番目から５００番目までにアクセスしたプレイヤー（５００人）をフィールドＦ１からフィールドＦ１０まで順番に配属する。次に、図１１の下図に示すように、全てのフィールドの収容率が５０％に達した後は、以下のようにして配属する。
すなわち、５０１番目にアクセスしたプレイヤーを（１人）フィールドＦ１に配属し、５０２番目にアクセスしたプレイヤーを（１人）をフィールドＦ２に配属し、同様にして、５０９番目にアクセスしたプレイヤーを（１人）をフィールドＦ９に配属し、５１０番目にアクセスしたプレイヤーを（１人）をフィールドＦ１０に配属する。この手順を繰り返し行なうことにより、５０１、５１１、５２１、・・・、６９１番目にアクセスしたプレイヤーを、フィールドＦ１に配属する。５０２、５１２、５２２、・・・、６９２番目にアクセスしたプレイヤーを、フィールドＦ２に配属する。同様にして、５０９、５１９、５２９、・・・、６９９番目にアクセスしたプレイヤーを、フィールドＦ９に配属する。５１０、５２０、５３０、・・・、７００番目にアクセスしたプレイヤーを、フィールドＦ１０に配属する。
このように、全てのフィールドの収容率が初期閾値である５０％に達した後であって、全てのフィールドの収容率が上限値である１００％に達していないときは、全てのフィールドの収容率が１００％に達するまで、アクセスしたプレイヤーを、フィールドＦ１からフィールドＦ１０まで１人ずつ順番に配属する手順を繰り返し行う。
【００４２】
（第３の配属パターン）
図１２は、単位時間あたり１０１０人のプレイヤーから対戦ゲームへの参加を要求するアクセスがあった場合に、プレイヤーをフィールドに配属するときの概要手順について説明する図である。先ず、図１２の上図に示すように、全てのフィールドの収容率が５０％に達するまでは、図１０に示す第１の配属パターンと同様の手順により、１番目から５００番目までにアクセスしたプレイヤー（５００人）をフィールドＦ１からフィールドＦ１０まで順番に配属する。そして、全てのフィールドの収容率が１００％に達するまでは、図１１に示す第２の配属パターンと同様の手順により、５０１番目から１０００番目までにアクセスしたプレイヤー（１０００人）をフィールドＦ１からフィールドＦ１０まで順番に配属する。次に、図１２の下図に示すように、全てのフィールドの収容率が１００％に達した後は、以下のようにして配属する。
すなわち、フィールド数の上限値を初期上限値である１０を１１に変動させる。つまり、図１２の下図に示すように、フィールド数の上限値は１１となったため、１１個目のフィールド（フィールドＦ１１）を新たに追加作成する。そして、１００１番目から１０１０番目にアクセスしたプレイヤーを（１０人）フィールドＦ１１に配属する。
このように、全てのフィールドの収容率が上限値である１００％に達した後は、新たなフィールドＦ１１を追加作成する。そして、アクセスしたプレイヤーを、新たなフィールドＦ１１の収容率が初期閾値である５０％に達するまで配属する。
【００４３】
ここで従来では、アクセスしたプレイヤーを収容率が上限値の１００％に達するまで１つのフィールドに配属する手順を、フィールドＦ１からフィールドＦ１０まで順番に繰り返し行なっていた。しかしながら、このような手順によってプレイヤーをグループに配属すると、すぐにグループが定員に達してしまうため、各フィールドに出現した敵キャラクターは、最大人数のプレイヤーから攻撃を受けることになり、簡単に倒される場合が多かった（ゲーム難易度の低下）。
そこで、本実施形態に係る発明では、各フィールドに対して収容率の初期閾値（例えば５０％）を設定することにより、すぐにグループが定員に達しないようにグループ人数をコントロールしている。
また、このようにグループ人数をコントロールすると、グループが定員に達するまでの時間をコントロールすることになる。例えば、１分間に１０人のアクセスがある場合を想定すると、最初のフィールドＦ１が定員に達するまでの時間について、以下のような差異が生じる。
従来のように、アクセスしたプレイヤーを収容率が上限値の１００％に達するまで１つのフィールドに配属する手順を、フィールドＦ１からフィールドＦ１０まで順番に繰り返し行なう場合、１０分でフィールドＦ１が定員（１００人）に到達することになる。
その一方で、上述した第１の配属パターンの手順では、５分ごとに５０人がフィールドＦ１からフィールドＦ１０まで配属され（５０分）、以後、１分ごとに各フィールドにプレイヤーが追加されると、９１分でフィールドＦ１が定員（１００人）に到達することになる。これにより、最初のフィールドＦ１が定員に達するまでの時間を遅らせることができるため、フィールドに出現した敵キャラクターを倒し難くすることが可能となる（ゲーム難易度の上昇）。
【００４４】
＜＜ゲームシステム１の動作について＞＞
図１３は、本実施形態にかかるゲームシステム１の動作例を説明するためのフローチャートである。ここでは、フィールドＦｉの定員数を「１００人」、収容率（グループ所属率）の初期閾値を「５０％」（収容率の上限値は「１００％」）、フィールド数の初期上限値を「１０」として説明する。
【００４５】
先ず、サーバー装置１０は、対戦ゲームを開始した後に、プレイヤー端末２０からアクセス（フィールドへの参加要求）があるか否かを判定する（Ｓ１０１）。アクセスがあったときは（Ｓ１０１：ＹＥＳ）、ステップ１０２へ進む。
【００４６】
次に、サーバー装置１０は、プレイヤー端末２０からのアクセス（フィールドへの参加要求）を受け付けると、プレイヤー配属処理を実行する（Ｓ１０２）。すなわち、プレイヤー配属部１１２は、グループ作成部１１１がゲーム開始時にグループ数の初期上限値に基づき作成した１０個のフィールド（グループ）のいずれかに、プレイヤー端末２０を利用してアクセスしたプレイヤーを配属する。
【００４７】
図１４は、プレイヤー配属処理を説明するためのフローチャートである。
先ず、インデックスｉの初期設定（ｉ＝０）を行なう（Ｓ２０１）。このインデックスｉは、フィールド名（フィールドＦｉ）に対応している。本実施形態では、フィールド数の初期上限値が「１０」であるため、フィールドＦ１〜フィールドＦ１０がゲーム開始時に作成され、インデックスｉの最大値（ＭＡＸ）は「１０」に初期設定される。
【００４８】
次いで、インデックスｉを１つインクリメント（ｉ＝ｉ＋１）して（Ｓ２０２）、フィールドＦｉが消滅したか否かがプレイヤー配属部１１２によって判定される（Ｓ２０３）。フィールドＦｉの消滅とは、フィールドＦｉがグループ作成部１１１によって作成されてから所定時間（たとえば１時間）が経過したことにより、フィールドＦｉを消去する設定を行うこと、若しくは、フィールドＦｉに出現した敵キャラクターを倒してミッションをクリアーしたことにより、フィールドＦｉを消去する設定を行うことである。この際、グルーピングされていた各プレイヤーもグループ解除される。
【００４９】
そして、フィールドＦｉが消滅していないと判定された場合は（Ｓ２０３：ＮＯ）、ステップ２０４へ進む。その一方で、フィールドＦｉが消滅したと判定された場合は（Ｓ２０３：ＹＥＳ）、ステップＳ２０２に戻ってインデックスｉを１つインクリメントし、それ以降の処理を繰り返す。
【００５０】
次に、ステップＳ２０４では、フィールドＦｉの収容率が５０％に到達したか否かがプレイヤー配属部１１２によって判定される。例えば、インデックスｉ＝１のとき、最初のフィールドＦ１の収容率が５０％に到達したか否かが判定される。
【００５１】
そして、フィールドＦｉの収容率が５０％に到達していないと判定された場合は（Ｓ２０４：ＮＯ）、そのフィールドＦｉに対し、プレイヤー端末２０を利用してアクセスしたプレイヤーを配属する（Ｓ２０５）。その一方で、フィールドＦｉの収容率が５０％に到達したと判定された場合は（Ｓ２０４：ＹＥＳ）、ステップ２０６へ進む。
【００５２】
次に、ステップＳ２０６では、インデックスｉが最大値（ＭＡＸ＝１０）と一致するか否かを判定する。一致する場合は（Ｓ２０６：ＹＥＳ）、すべてのフィールドの収容率が５０％に達したことになるため（図１１の上図を参照）、プレイヤー端末２０を利用してアクセスしたプレイヤーを、フィールドＦ１からフィールドＦ１０まで１人ずつ順番に配属する（Ｓ２０７、図１１の下図を参照）。その一方で、一致しない場合には（Ｓ２０６：ＮＯ）、フィールドの収容率が５０％に達していないフィールドがまだ残っているので、ステップＳ２０２に戻ってインデックスｉを１つインクリメントし、それ以降の処理を繰り返す（図１０を参照）。
【００５３】
図１３に戻り、サーバー装置１０は、このようにしてプレイヤー配属処理が行われると、フィールドＦ１〜フィールドＦｍａｘ（ここでは、フィールドＦｍａｘ＝フィールドＦ１０）までの収容率が１００％に到達したか否かを判定する（Ｓ１０３）。フィールドＦ１〜フィールドＦｍａｘまでの収容率が１００％に到達していないと判定された場合には（Ｓ１０３：ＮＯ）、この処理を終了する。その一方で、フィールドＦ１〜フィールドＦｍａｘまでの収容率が１００％に到達したと判定された場合は（Ｓ１０３：ＹＥＳ）、フィールド総数の再設定が行われる（Ｓ１０４）。すなわち、上限変動部１１３は、フィールド数の上限値を初期上限値「１０」から「１１」に変動させて（ＭＡＸ＝ＭＡＸ＋１）、記憶部１２に更新記録する。
【００５４】
次に、サーバー装置１０は、フィールドＦｍａｘを新たに作成する（Ｓ１０５）。すなわち、グループ追加作成部１１４は、上限変動部１１３によってフィールド数の上限値が変動したことに応じて、新たなフィールドＦｍａｘ（ここでは、フィールドＦｍａｘ＝フィールドＦ１１）を追加作成する（図１２の下図を参照）。
【００５５】
＜収容率の閾値について＞
ここで、サーバー装置１０は、新たなフィールドＦ１１が追加作成されると、このフィールドＦ１１に対して収容率の閾値を設定する。本実施形態では、全てのフィールドにおけるミッションの成功率に基づき、収容率の閾値を決定している。
例えば、ミッションの成功率が上昇しているときは、新たなフィールドＦ１１の収容率の閾値を初期閾値（５０％）よりも低く設定する。逆に、ミッションの成功率が低下しているときには、新たなフィールドＦ１１の収容率の閾値を初期閾値（５０％）よりも高く設定する。つまり、今回のフィールドが追加されるまでの傾向として、敵キャラクターが倒され易い傾向にあるときには、フィールド人数が少なくなるようにコントロールすることで、これ以降のゲーム難易度を上昇させ、逆に、敵キャラクターが倒され難い傾向にあるときには、フィールド人数が多くなるようにコントロールすることで、これ以降のゲーム難易度を低下させる。
【００５６】
具体的には、サーバー装置１０における算出部１１６は、１時間ごとに、各フィールドにおけるミッションの結果を取得し、フィールド全体におけるミッションの成功率を算出して、図８に示すゲーム結果情報の更新を行う。すなわち、算出部１１６は、各フィールドＦ１〜Ｆ１０におけるミッション実行回数（敵キャラクターとの対戦回数）を合計した数値から、フィールド全体のミッション実行回数を求める。そして、算出部１１６は、各フィールドＦ１〜Ｆ１０におけるミッション成功回数（敵キャラクターとの対戦で勝利した回数）を合計した数値から、フィールド全体のミッション成功回数を求める。そして、算出部１１６は、フィールド全体のミッション実行回数に対するフィールド全体のミッション成功回数の割合を求め、フィールド全体のミッションの成功率を決定する。
【００５７】
次に、サーバー装置１０における閾値変動部１１８は、図８に示すゲーム結果情報を参照し、新たなフィールドＦ１１が追加作成される日時に最も近いデータ取得日時のミッション成功率を取得する。そして、閾値変動部１１８は、取得したミッション成功率が基準値（例えば、７０％〜７５％）より高いか否かを判定し、その判定結果に基づき、追加作成されたフィールドＦ１１の収容率の閾値を変動させて、記憶部１２に更新記録する。具体的には、閾値変動部１１８は、その判定結果により、ミッションの成功率が基準値よりも高い場合には（ゲーム難易度が低下している状態では）、新たなフィールドＦ１１の収容率の閾値を初期閾値（５０％）よりも低く設定する。ミッションの成功率が基準値よりも低い場合には（ゲーム難易度が上昇している状態では）、新たなフィールドＦ１１の収容率の閾値を初期閾値（５０％）よりも高く設定する。また、ミッションの成功率が基準値であれば、新たなフィールドＦ１１の収容率の閾値を初期閾値（５０％）のままで設定する。
【００５８】
以上のとおり、本実施形態に係るゲームシステム１によれば、対戦ゲーム開始後、対戦ゲームへの参加を希望するプレイヤーから任意のタイミングでアクセスがあった場合に、そのアクセスしたプレイヤーを、対戦ゲームを行うための複数のフィールドのうちのいずれかに配属する。各フィールドには、収容率の初期閾値（例えば５０％）が設定されているため、すぐにフィールドが定員に達しないようにグループ人数をコントロールしている。そして、各フィールドが定員に達すると、新たなフィールドが追加作成される。新たなフィールドには、全フィールドのミッションの成功率に基づき決定された収容率の閾値が設定される。そのため、敵キャラクターが倒され易い傾向にあるのか、それとも倒され難い傾向にあるのか等、対戦状況に応じて各フィールドの人数が適切にコントロールされるため、フィールドごとのゲーム難易度をバランス良く調整することが可能となる。
【００５９】
＝＝＝その他の実施形態＝＝＝
上記の実施の形態は、本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更、改良され得ると共に、本発明にはその等価物も含まれる。特に、以下に述べる実施形態であっても、本発明に含まれるものである。
【００６０】
＜フィールドの定員数＞
上記の本実施形態では、新たなフィールドＦｍａｘ（フィールドＦ１１）が追加作成された際に、フィールド全体のミッション成功率に基づき、新たなフィールドＦｍａｘの定員数を初期定員数から変動させても良い。例えば、定員変動部１１７は、図８に示すゲーム結果情報を参照し、新たなフィールドＦ１１が追加作成される日時に最も近いデータ取得日時のミッション成功率を取得する。そして、定員変動部１１７は、取得したミッション成功率が基準値（例えば、７０％〜７５％）より高いか否かを判定し、その判定結果に基づき、追加作成されたフィールドＦ１１の定員数を初期定員数（例えば「１００人」）から変動させて、記憶部１２に更新記録しても良い。具体的には、定員変動部１１７は、その判定結果により、ミッションの成功率が基準値よりも高い場合には、新たなフィールドＦ１１の定員数を初期定員数（１００人）よりも低く設定する。ミッションの成功率が基準値よりも低い場合には、新たなフィールドＦ１１の定員数を初期定員数（１００人）よりも高く設定する。また、ミッションの成功率が基準値であれば、新たなフィールドＦ１１の定員数を初期定員数（１００人）のままで設定する。
【００６１】
＜対戦ゲームの難易度＞
上記の本実施形態では、グループ全体のミッション成功率に基づき、グループ単位で設定されたミッションの難易度を変化させても良い。例えば、ゲーム処理部１１５は、算出部１１６によって算出されたフィールド全体のミッション成功率に基づいて、各フィールドに出現する敵キャラクターの強さ（攻撃力等の能力パラメーター）を変化させても良い。つまり、ミッションの成功率が上昇しているときは、敵キャラクターの能力パラメーターを上昇（敵キャラクターを強くする）させ、逆に、ミッションの成功率が低下しているときには、敵キャラクターの能力パラメーターを低下（敵キャラクターを弱くする）させても良い。
【００６２】
＜サーバー装置＞
上記の本実施形態では、サーバー装置の一例として１台のサーバー装置１０を備えたゲームシステム１を例に挙げて説明したが、これに限らず、サーバー装置の一例として複数台のサーバー装置１０を備えたゲームシステム１としてもよい。すなわち、複数台のサーバー装置１０がネットワーク２を介して接続され、各サーバー装置１０が各種処理を分散して行うようにしてもよい。なお、サーバー装置１０はプロセッサー及びメモリを備えるコンピューターの一例である。
【００６３】
＜情報処理装置＞
上記の本実施形態におけるゲームシステム１では、ゲームプログラムに基づきサーバー装置１０及びプレイヤー端末２０を協働させて各種情報処理を実行する場合を例に挙げて説明したが、これに限定されるものではなく、情報処理装置としてのプレイヤー端末２０単体、または、サーバー装置１０単体が、ゲームプログラムに基づき上記の各種情報処理を実行するようにしてもよい。
また、情報処理装置としての機能の一部をプレイヤー端末２０が担う構成としてもよい。この場合には、サーバー装置１０及びプレイヤー端末２０が情報処理装置を構成する。
なお、情報処理装置はプロセッサー及びメモリを備えるコンピューターの一例である。
【符号の説明】
【００６４】
１  ゲームシステム、２  ネットワーク、１０  サーバー装置、１１  制御部、１２  データ記憶部、１３  入力部、１４  表示部、１５  通信部、２０  プレイヤー端末、２１  端末制御部、２２  端末記憶部、２３  端末入力部、２４  端末表示部、２５  端末通信部、１１１  グループ作成部、１１２  プレイヤー配属部、１１３  上限値変動部、１１４  グループ追加作成部、１１５  ゲーム処理部、１１６  算出部、１１７  定員数変動部、１１８  閾値変動部
【図１】
0005869544.tif 000002
【図２】
0005869544.tif 000003
【図３】
0005869544.tif 000004
【図４】
0005869544.tif 000005
【図５】
0005869544.tif 000006
【図６】
0005869544.tif 000007
【図７】
0005869544.tif 000008
【図８】
0005869544.tif 000009
【図９】
0005869544.tif 000010
【図１０】
0005869544.tif 000011
【図１１】
0005869544.tif 000012
【図１２】
0005869544.tif 000013
【図１３】
0005869544.tif 000014
【図１４】
0005869544.tif 000015