特許 5815901 ゲーム管理方法及びゲーム管理システム

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

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

(11)【特許番号】5815901

(24)【登録日】2015年10月2日

(45)【発行日】2015年11月17日

(54)【発明の名称】ゲーム管理方法及びゲーム管理システム

(51)【国際特許分類】

   A63F 13/358 20140101AFI20151029BHJP

   A63F 13/48 20140101ALI20151029BHJP

   A63F 13/30 20140101ALI20151029BHJP

   A63F 13/795 20140101ALI20151029BHJP

【ＦＩ】

   A63F13/358

   A63F13/48

   A63F13/30

   A63F13/795

【請求項の数】6

【全頁数】16

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

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

(62)【分割の表示】特願2014-167478(P2014-167478)の分割

【原出願日】2014年1月30日

(65)【公開番号】特開2015-144841(P2015-144841A)

(43)【公開日】2015年8月13日

【審査請求日】2015年3月19日

【早期審査対象出願】

(73)【特許権者】

【識別番号】504437801

【氏名又は名称】グリー株式会社

(74)【代理人】

【識別番号】100105957

【弁理士】

【氏名又は名称】恩田 誠

(74)【代理人】

【識別番号】100068755

【弁理士】

【氏名又は名称】恩田 博宣

(72)【発明者】

【氏名】古本 友彦

(72)【発明者】

【氏名】永井 雅人

【審査官】 櫻井 茂樹

(56)【参考文献】

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

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

【文献】 特表２００４−５２３３２６（ＪＰ，Ａ）

【文献】 特許第４２７５１３６（ＪＰ，Ｂ２）

【文献】 特表２００７−５１８５４２（ＪＰ，Ａ）

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

【文献】 中嶋 謙互，オンラインゲームを支える技術 −壮大なプレイ空間の舞台裏，株式会社技術評論社，２０１１年 ４月２５日，初版第１刷，P.128-129,174,410

【文献】 金田 裕剛（外４名），ネットワークゲームの再利用を可能にする通信接続形態切替機構の実装と評価，電子情報通信学会技術研究報告，日本，社団法人電子情報通信学会，２００５年 ２月２５日，Vol.104,No.692，P.293-298

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

Ａ６３Ｆ１３／００〜１３／９８、９／２４

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

【請求項1】

複数のユーザ端末に接続され、ゲーム進行を管理する制御部と、
前記ユーザ端末における遅延時間を記録する記憶部とを備えたゲーム管理システムを用いて、ゲームを管理する方法であって、
前記制御部は、
グループでゲームを行なう各ユーザ端末における遅延時間を取得して前記記憶部に記録し、
前記記憶部に記録された遅延時間の最大値よりも大きいオフセットを決定し、
前記オフセットを各ユーザ端末に通知し、
前記ユーザ端末は、前記オフセットから前記ユーザ端末の遅延時間を差し引いてスタート時間を算出し、前記スタート時間経過後にゲームを開始することを特徴とするゲーム管理方法。

【請求項2】

前記ゲーム管理システムは、ゲーム種別に対応して、前記ユーザ端末からのリクエスト実行の可否を判定するための閾値を記憶し、
前記制御部は、更に、ゲームを行なうゲーム種別に基づいて、前記閾値を決定することを特徴とする請求項１に記載のゲーム管理方法。

【請求項3】

前記制御部は、更に、前記記憶部に記録された遅延時間の分散状況を算出し、
前記分散状況に基づいて、前記閾値を決定することを特徴とする請求項２に記載のゲーム管理方法。

【請求項4】

前記制御部は、更に、グループでゲームを行なうゲーム参加人数を算出し、
前記ゲーム参加人数に基づいて、前記閾値を決定することを特徴とする請求項２又は３に記載のゲーム管理方法。

【請求項5】

前記制御部は、更に、ゲーム参加希望者のクライアントから遅延時間を取得し、前記記憶部に記録し、
前記記憶部に記録されている最新の遅延時間に基づいて、同一ゲームを行なうグループを決定することを特徴とする請求項１〜４の何れか１項に記載のゲーム管理方法。

【請求項6】

複数のユーザ端末に接続され、ゲーム進行を管理する制御部と、
前記ユーザ端末における遅延時間を記録する記憶部とを備えたゲーム管理システムであって、
前記制御部は、
グループでゲームを行なう各ユーザ端末における遅延時間を取得して前記記憶部に記録し、
前記記憶部に記録された遅延時間の最大値よりも大きいオフセットを決定し、
前記オフセットを各ユーザ端末に通知し、
前記ユーザ端末は、前記オフセットから前記ユーザ端末の遅延時間を差し引いてスタート時間を算出し、前記スタート時間経過後にゲームを開始することを特徴とするゲーム管理システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、通信状態が異なる複数のコンピュータ端末において、ゲーム進行を管理するためのゲーム管理方法及びゲーム管理システムに関する。

【背景技術】

【0002】

今日、スマートフォン等のコンピュータ端末を利用するユーザに対して、各種オンラインゲーム等のアプリケーションソフトが提供されている。このようなコンピュータ端末は、インターネットなどのネットワークを介して、他のコンピュータ端末と接続することにより、互いに離れているプレイヤとゲームの対戦を楽しむことができる。

【0003】

しかしながら、通信ネットワークを介して接続する複数のコンピュータ端末間に通信遅延が生じる場合がある。そこで、各コンピュータ端末間で、データがほぼ同時に処理されるデータ処理方法が検討されている（例えば、特許文献１参照）。この文献に記載されたサーバ装置は、通信遅延を有するネットワークを介してコンピュータゲームの対戦が行なわれる場合、ゲーム開始前に、コンピュータ端末間の遅延時間を求める。そして、この遅延時間に基づいて、各コンピュータ端末がカウントする時間の同期を取る。そして、ゲーム進行中は、操作データ信号は、その発生から予め測定したコンピュータ端末間の遅延時間のうち最も長い遅延時間経過後に処理される。これにより、複数のコンピュータ端末において、同時に操作データ信号を処理する。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２００７−２６０４１０号公報（第１頁、図１）

【発明の概要】

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

【0005】

しかしながら、ゲーム中にクライアント端末の通信状況が変わる場合がある。この場合には、ゲーム進行の同期に支障が生じる可能性がある。
本発明は、上述した問題に鑑みてなされたものであり、その目的は、通信状態が異なる複数のコンピュータ端末において同期してゲームを行なうためのゲーム管理方法及びゲーム管理システムを提供することにある。

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

【0006】

上記課題を解決するゲーム管理システムは、複数のユーザ端末に接続され、ゲーム進行を管理する制御部と、前記ユーザ端末における遅延時間を記録する記憶部とを備える。そして、前記制御部は、グループでゲームを行なう各ユーザ端末における遅延時間を取得して前記記憶部に記録し、前記記憶部に記録された遅延時間の最大値よりも大きいオフセットを決定し、前記オフセットを各ユーザ端末に通知する。そして、前記ユーザ端末は、前記オフセットから前記ユーザ端末の遅延時間を差し引いてスタート時間を算出し、前記スタート時間経過後にゲームを開始する。これにより、ユーザ端末との通信状況に応じて、同期させたゲーム進行を管理することができる。

【0007】

上記ゲーム管理システムは、更に、ゲーム種別に対応して、前記ユーザ端末からのリクエスト実行の可否を判定するための閾値を記憶する。そして、前記制御部は、更に、ゲームを行なうゲーム種別に基づいて、前記閾値を決定することが好ましい。これにより、ゲーム種別に応じた同期状況（同期の厳格性）を考慮して、リクエストに対応することができる。

【0008】

上記ゲーム管理方法において、前記制御部は、更に、前記記憶部に記録された遅延時間の分散状況を算出し、前記分散状況に基づいて、前記閾値を決定することが好ましい。これにより、遅延時間の分散状況に応じて、効率的にゲーム進行を図ることができる。

【0009】

上記ゲーム管理方法において、前記制御部は、更に、グループでゲームを行なうゲーム参加人数を算出し、前記ゲーム参加人数に基づいて、前記閾値を決定することが好ましい。これにより、ゲーム参加人数の多少に応じて、効率的にゲーム進行を図ることができる。

【0010】

上記ゲーム管理方法において、前記制御部は、更に、ゲーム参加希望者のクライアントから遅延時間を取得し、前記記憶部に記録し、前記記憶部に記録されている最新の遅延時間に基づいて、同一ゲームを行なうグループを決定することが好ましい。これにより、遅延時間のばらつきを抑制し、効率的にゲーム進行の同期を図ることができる。

【発明の効果】

【0011】

本発明によれば、通信状態が異なる複数のコンピュータ端末においてゲーム進行を管理することができる。

【図面の簡単な説明】

【0012】

【図1】本実施形態のシステム概略図。

【図2】本実施形態の処理手順の説明図。

【図3】本実施形態の処理手順の説明図。

【図4】本実施形態の処理手順の説明図。

【図5】本実施形態のタイミングチャート。

【図6】本実施形態のタイミングチャート。

【図7】他の実施形態の処理手順の説明図。

【図8】他の実施形態の処理手順の説明図。

【図9】他の実施形態の処理手順の説明図。

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

【0013】

以下、ゲーム管理方法の一実施形態を図１〜図６に従って説明する。本実施形態は、複数のユーザ端末（クライアント）に対して、同期して進行するゲームコンテンツ（ロールプレイゲーム）を提供する場合を想定する。このゲーム進行は、時間経過とともにインクリメント（増加）されるステップ数により管理される。

【0014】

図１に示すように、本実施形態では、インターネット等のネットワークを介して接続された複数のユーザ端末１０、管理サーバ２０（ゲーム管理システム）を用いる。
ユーザ端末１０は、ゲームを行なうユーザが利用するコンピュータ端末（スマートフォン等の情報処理端末）である。ユーザ端末１０は、通信部、入力部や出力部（タッチパネルディスプレイ等）を備える。更に、ユーザ端末１０は、ＣＰＵ、ＲＡＭ及びＲＯＭ等からなる制御部（遅延処理部１１、ゲーム処理部１２）を備える。

【0015】

遅延処理部１１は、継続的に、管理サーバ２０との接続状態についてレイテンシ（データ転送等を要求してから、その結果が返送されるまでの遅延時間）を計測し、管理サーバ２０に送信する。本実施形態では、継続的な計測として、定期的な計測を行なう場合を想定するが、計測の時間間隔として、「不定期」や「連続的」を用いることが可能である。更に、このゲーム処理部１２は、管理サーバ２０に送信したレイテンシに関するデータを保持する。

【0016】

ゲーム処理部１２は、ゲームを行なうためのアプリケーションにより機能し、ゲーム進行を管理する。また、ゲーム処理部１２は、ユーザの操作によるリクエストを管理サーバ２０に送信したり、管理サーバ２０から取得した指示に基づいてイベントを実行したりする。

【0017】

管理サーバ２０は、各ユーザ端末１０に対して、各種ゲームコンテンツを提供するサーバコンピュータである。
この管理サーバ２０は、ＣＰＵ、ＲＡＭ及びＲＯＭ等からなる制御部２１、ユーザ情報記憶部２２、接続状況記憶部２３、ゲーム情報記憶部２４を備える。制御部２１は、管理プログラムを実行することにより、ユーザ管理部２１１、遅延管理部２１２、ゲーム管理部２１３、進行管理部２１４として機能する。

【0018】

ユーザ管理部２１１は、ゲームを利用するユーザを管理する処理を実行する。
遅延管理部２１２は、各ユーザ端末１０との接続状況を管理する処理を実行する。具体的には、各ユーザ端末１０からレイテンシ情報を取得し、接続状態を判定する。更に、遅延管理部２１２は、レイテンシが大きく、ゲーム進行上の支障があるユーザ端末１０（クライアント異常）を判定するための閾値に関するデータを保持している。

【0019】

ゲーム管理部２１３は、各ユーザ端末１０におけるゲーム進行を管理する処理を実行する。本実施形態では、ゲーム管理部２１３は、各ユーザ端末１０に対するゲーム開始や、ユーザ端末１０におけるリクエストの取得、ゲーム進行において生じたイベントの通知等を行なう。ここでは、ゲーム開始からの経過時間（ステップ数）に基づいて、ゲーム進行を管理する。具体的には、ステップ数に基づいて、各クライアントのユーザ端末１０、管理サーバ２０のゲーム進行を同期させる。また、ゲーム管理部２１３は、管理サーバ２０におけるゲーム進行と矛盾するリクエストをユーザ端末１０から取得した場合には、不正行為として対応する。

【0020】

進行管理部２１４は、管理サーバ２０において、ゲーム進行を管理する処理を実行する。この進行管理部２１４は、この管理サーバ２０におけるゲーム進行と、各ユーザ端末１０におけるゲーム進行との同期を行なう。

【0021】

ユーザ情報記憶部２２には、ゲームを利用するユーザに関するユーザ情報が記録されている。このユーザ情報には、ユーザが登録された場合に記録される。ユーザ情報には、クライアントＩＤ、属性に関するデータが含まれる。

【0022】

クライアントＩＤデータ領域は、各ユーザを特定するための識別子に関するデータが記録されている。
属性データ領域には、このユーザの属性に関するデータが記録されている。この属性には、例えばユーザが属するグループやスキル、所有するアイテムに関する情報が含まれる。

【0023】

接続状況記憶部２３には、ユーザ端末１０との接続状況を管理するための接続管理情報が記録される。この接続管理情報は、ユーザ端末１０が管理サーバ２０に接続した場合に登録される。接続管理情報には、グループＩＤ、クライアントＩＤ、レイテンシ、ステータスに関するデータが含まれる。

【0024】

グループＩＤ領域には、同期してゲームを行なっているグループを特定するための識別子に関するデータが記録される。
クライアントＩＤデータ領域には、このグループでゲームを行なっている各ユーザ端末１０（クライアント）を特定するための識別子に関するデータが記録される。

【0025】

レイテンシデータ領域には、各クライアント（ユーザ端末１０）との接続状況（ここでは、レイテンシ）に関するデータが記録される。
ステータスデータ領域には、各クライアントから取得したリクエストの有効性を判定するための情報が記録される。本実施形態では、レイテンシが閾値より大きいクライアントに対しては、このデータ領域に異常フラグを記録する。異常フラグが記録されているクライアントのユーザ端末１０からのリクエストは無効とする。

【0026】

ゲーム情報記憶部２４には、ゲームの進行状況に関するゲーム管理情報が記録される。このゲーム管理情報は、ゲームを行なう場合に登録され、ゲーム中に更新される。ゲーム管理情報には、グループＩＤ、クライアントＩＤ、利用ゲーム、進捗状況に関するデータが含まれる。

【0027】

グループＩＤ領域には、各ユーザが属しているグループを特定するための識別子に関するデータが記録される。
クライアントＩＤデータ領域には、このグループでゲームを行なっている各ユーザ端末１０を特定するための識別子に関するデータが記録される。

【0028】

利用ゲームデータ領域には、このグループが利用しているゲームを特定するための識別子に関するデータが記録される。
進捗状況データ領域には、このゲームの進捗状況に関するデータが記録される。本実施形態では、ゲームの進行をカウントしたステップ数に対して、各クライアントにおけるイベント（例えば、オブジェクトの配置等の操作等）が記録される。

【0029】

以下、上記システム用いて、クライアントＡ〜Ｃのユーザ端末１０が、一つのグループとしてゲームを行なう場合のゲーム管理方法を説明する。
（レイテンシ管理処理）
まず、図２、図５を用いて、レイテンシ管理処理を説明する。レイテンシ管理処理では、ゲーム開始前から終了まで、各クライアントのレイテンシを管理する。

【0030】

まず、ユーザ端末１０は、定期的に、レイテンシ測定処理を実行する（ステップＳ１−１）。具体的には、ユーザ端末１０の遅延処理部１１は、管理サーバ２０に対して、定期的にＰｉｎｇを送信する。Ｐｉｎｇを受信した管理サーバ２０は、Ｐｉｎｇに対する応答を返信する。そして、遅延処理部１１は、Ｐｉｎｇ送信から返信までの所要時間に基づいて、ネットワークレイテンシ（遅延時間）を測定する。そして、遅延処理部１１は、測定してレイテンシを保持する。図５では、クライアントＡ〜Ｃが、それぞれ時刻ｔ１１〜ｔ１３において、レイテンシを測定するためのＰｉｎｇを送信する。

【0031】

次に、ユーザ端末１０は、レイテンシ送信処理を実行する（ステップＳ１−２）。具体的には、ユーザ端末１０の遅延処理部１１は、管理サーバ２０に対して、レイテンシ情報を送信する。このレイテンシ情報には、ユーザ端末１０を特定する情報や、このユーザ端末１０において測定したレイテンシに関する情報を含める。図５では、クライアントＡ〜Ｃが、それぞれ時刻ｔ２１〜ｔ２３において、レイテンシ情報を送信する。そして、ユーザ端末１０は、次の測定タイミングで、レイテンシ測定処理（ステップＳ１−１）以降の処理を繰り返す。

【0032】

次に、管理サーバ２０の制御部２１は、レイテンシの取得処理を実行する（ステップＳ２−１）。具体的には、制御部２１の遅延管理部２１２は、ユーザ端末１０によって送信されたレイテンシ情報を取得する。

【0033】

次に、管理サーバ２０の制御部２１は、レイテンシの記録処理を実行する（ステップＳ２−２）。具体的には、制御部２１の遅延管理部２１２は、接続状況記憶部２３において、ユーザ端末１０のクライアントＩＤに関連付けてレイテンシを記録する。ここで、初めてレイテンシを取得した場合には、遅延管理部２１２は、グループＩＤ，クライアントＩＤに関連づけて、レイテンシを記録した接続状況管理情報を生成し、接続状況記憶部２３に登録する。一方、既に、このユーザ端末１０についての接続状況管理情報が接続状況記憶部２３に登録されている場合には、遅延管理部２１２は、この接続状況管理情報に最新のレイテンシを更新記録する。

【0034】

次に、管理サーバ２０の制御部２１は、クライアント異常かどうかについての判定処理を実行する（ステップＳ２−３）。具体的には、制御部２１の遅延管理部２１２は、ユーザ端末１０から取得したレイテンシと閾値とを比較する。レイテンシが閾値より大きい場合には、クライアント異常と判定する。

【0035】

クライアント異常でないと判定した場合（ステップＳ２−３において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、レイテンシ管理処理を終了する。
一方、クライアント異常と判定した場合（ステップＳ２−３において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、リクエスト無効化処理を実行する（ステップＳ２−４）。具体的には、制御部２１の遅延管理部２１２は、接続状況記憶部２３の接続状況管理情報に、ステータスとして異常フラグを記録し、レイテンシ管理処理を終了する。そして、ゲーム進行中において、ゲーム管理部２１３は、異常フラグが記録されたユーザ端末１０からのリクエストを無視する。

【0036】

（ゲーム開始時処理）
次に、図３、図５を用いて、ゲーム開始時処理を説明する。この処理は、ユーザ端末１０からゲームスタート要求を受信した場合（ゲーム開始時）に実行される。

【0037】

ここでは、まず、管理サーバ２０の制御部２１は、レイテンシの最大値の特定処理を実行する（ステップＳ３−１）。具体的には、制御部２１のゲーム管理部２１３は、接続状況記憶部２３から、同じグループＩＤが記録された接続状況管理情報を取得して、同じグループに属するユーザ端末１０のレイテンシを特定する。この場合、異常フラグが記録されているレイテンシを無視する。そして、ゲーム管理部２１３は、特定したレイテンシの中で最大値を特定する。本実施形態では、クライアントＡ〜Ｃのレイテンシは、それぞれ「５０ｍｓ」，「３０ｍｓ」，「２００ｍｓ」の場合を想定する。この場合、レイテンシの最大値は「２００ｍｓ」となる。

【0038】

次に、管理サーバ２０の制御部２１は、最大値より大きいオフセットの決定処理を実行する（ステップＳ３−２）。具体的には、制御部２１のゲーム管理部２１３は、レイテンシの最大値より大きいオフセット（猶予時間）を特定する。ここでは、最大値に対して所定値（例えば１．５）を乗算した値をオフセットとして決定する。具体的には、最大値（２００ｍｓ）に対して、オフセットとして「３００ｍｓ（＝２００＊１．５）」が算出される。なお、オフセットの算出は、ゲーム管理部２１３に予め保持させた算出方法であれば、上述の定数倍に限定されるものではない。

【0039】

次に、管理サーバ２０の制御部２１は、オフセットの通知処理を実行する（ステップＳ３−３）。具体的には、制御部２１のゲーム管理部２１３は、スタート時間情報をユーザ端末１０に送信する。このスタート時間情報には、決定したオフセットに関する情報を含める。

【0040】

次に、管理サーバ２０の制御部２１は、ゲーム開始処理を実行する（ステップＳ３−４）。具体的には、制御部２１の進行管理部２１４は、オフセット経過後に、管理サーバ２０におけるゲームを開始する。図５では、オフセット経過後の時刻ｔ４０において、ゲームを開始する。そして、進行管理部２１４は、一定時間毎にステップ数をインクリメントすることにより、ゲームを進行させる。

【0041】

一方、オフセットを受信したユーザ端末１０は、スタート待機処理を実行する（ステップＳ４−１）。具体的には、ユーザ端末１０のゲーム処理部１２は、管理サーバ２０から取得したオフセットから、遅延処理部１１が保持しているレイテンシを差し引いて、ゲームのスタート時間を算出する。例えば、クライアントＡ〜Ｃにおいては、それぞれ２５０ｍｓ〔＝３００−５０〕、２７０ｍｓ〔＝３００−３０〕、１００ｍｓ〔＝３００−２００〕がスタート時間となる。そして、ゲーム処理部１２は、このスタート時間を待機する。

【0042】

そして、スタート時間が経過した場合、ユーザ端末１０は、ゲーム開始処理を実行する（ステップＳ４−２）。具体的には、ユーザ端末１０のゲーム処理部１２は、ゲームを開始する。図５では、オフセット経過後の時刻ｔ４０において、クライアントＡ〜Ｃはゲームを開始する。そして、各ユーザ端末１０のゲーム処理部１２は、一定時間毎にステップ数をインクリメントすることにより、ゲームを進行させる。

【0043】

（リクエスト対応処理）
次に、図４を用いて、リクエスト対応処理を説明する。ここでは、クライアントＡのユーザ端末１０からリクエストを取得した場合を想定する。

【0044】

まず、ユーザ端末１０は、操作要求処理を実行する（ステップＳ５−１）。具体的には、ユーザ端末１０のゲーム処理部１２は、ユーザによる操作に基づいて、イベントを特定する。ここでは、イベントとして、オブジェクトの配置を想定する。この場合、クライアントＡのゲーム処理部１２は、クライアントＡにおけるレイテンシを考慮したステップ数を算出する。ここでは、クライアントＡにおける操作時のステップ数（ローカルステップ数）に対して、レイテンシをステップ単位時間で除算した値を加算した値（サーバステップ数）を算出する。そして、ゲーム処理部１２は、管理サーバ２０に対して、オブジェクト配置のリクエストを送信する。このリクエストには、オブジェクトの種類、配置位置、サーバステップ数に関するデータを含める。図６では、クライアントＡが、時刻ｔ５１において、オブジェクト配置のリクエストを送信する。

【0045】

次に、ユーザ端末１０は、イベントまでの時間差の擬装処理を実行する（ステップＳ５−２）。具体的には、ユーザ端末１０のゲーム処理部１２は、イベント準備中（オブジェクトの配置の準備中）を示すアニメーション等を出力する。

【0046】

リクエストを取得した管理サーバ２０の制御部２１は、操作の検知処理を実行する（ステップＳ６−１）。具体的には、制御部２１のゲーム管理部２１３は、クライアントＡのユーザ端末１０から、操作（オブジェクトの配置）についてのリクエストを取得する。

【0047】

次に、管理サーバ２０の制御部２１は、レイテンシの最大値の特定処理を実行する（ステップＳ６−２）。具体的には、制御部２１のゲーム管理部２１３は、接続状況記憶部２３において、同じグループＩＤが記録された接続状況管理情報を取得して、レイテンシの最大値を特定する。

【0048】

次に、管理サーバ２０の制御部２１は、レイテンシに基づいて指定ステップの決定処理を実行する（ステップＳ６−３）。具体的には、制御部２１のゲーム管理部２１３は、レイテンシの最大値に対してマージンを加算したイベント実施時刻を算出する。そして、ゲーム管理部２１３は、イベント実施時刻をステップ単位時間で除算して、オブジェクトの配置を実施するステップ数を算出する。

【0049】

次に、管理サーバ２０の制御部２１は、指定ステップの通知処理を実行する（ステップＳ６−４）。具体的には、制御部２１のゲーム管理部２１３は、クライアントＡ〜Ｃのユーザ端末１０に対して、イベント通知を行なう。このイベント通知には、イベント内容（クライアントＡにおけるオブジェクトの配置）、指定ステップ数に関するデータを含める。図６では、管理サーバ２０が、時刻ｔ６０において、イベント実施の指定ステップを通知する。

【0050】

次に、管理サーバ２０の制御部２１は、イベント待機処理を実行する（ステップＳ６−５）。具体的には、制御部２１の進行管理部２１４は、指定ステップになるまで、イベントを待機する。

【0051】

次に、管理サーバ２０の制御部２１は、イベント実施処理を実行する（ステップＳ６−６）。具体的には、制御部２１の進行管理部２１４は、指定ステップにおいて、管理サーバ２０のゲーム進行において、イベント（オブジェクトの配置）をゲーム情報記憶部２４に記録する。図６では、進行管理部２１４は、時刻ｔ７０において、オブジェクトの配置を実施する。

【0052】

イベント通知を受信したユーザ端末１０は、イベント待機処理を実行する（ステップＳ５−３）。具体的には、ユーザ端末１０のゲーム処理部１２は、管理サーバ２０から指定ステップになるまで、イベントを待機する。

【0053】

次に、ユーザ端末１０は、イベント実施処理を実行する（ステップＳ５−４）。具体的には、指定ステップが到来した場合、ユーザ端末１０のゲーム処理部１２は、擬装を終了し、オブジェクトの配置を実施する。

【0054】

また、クライアントＢ、クライアントＣのユーザ端末１０においても、ステップＳ５−３、Ｓ５−４と同様に、イベント待機処理（ステップＳ７−１）、イベント実施処理（ステップＳ７−２）を実行する。図６では、時刻ｔ７０において、クライアントＡ〜Ｃは、オブジェクトの配置を実施する。

【0055】

上記実施形態によれば、以下のような効果を得ることができる。
（１）上記実施形態では、ユーザ端末１０は、レイテンシ測定処理（ステップＳ１−１）、レイテンシ送信処理（ステップＳ１−２）を実行する。管理サーバ２０の制御部２１は、レイテンシの取得処理（ステップＳ２−１）、レイテンシの記録処理を実行する（ステップＳ２−２）。これにより、管理サーバ２０において、各クライアントにおける遅延状況を把握することができる。特に、この処理が定期的に実行されるため、サーバ・クライアント間の通信状況の変化にも対応することができる。

【0056】

（２）上記実施形態では、進行管理部２１４は、管理サーバ２０において、ゲーム進行を管理する処理を実行する。この進行管理部２１４は、管理サーバ２０におけるゲーム進行と、各ユーザ端末１０におけるゲーム進行との同期を行なう。また、ゲーム管理部２１３は、管理サーバ２０におけるゲーム進行と矛盾するリクエストをユーザ端末１０から取得した場合には、不正行為として対応する。これにより、管理サーバ２０においてゲーム進行を管理しているので、各クライアントでの不正行為を監視することができる。更に、ユーザ端末１０との通信障害が生じても、障害から復帰した場合、ゲームを継続することができる。

【0057】

（３）上記実施形態では、クライアント異常と判定した場合（ステップＳ２−３において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、リクエスト無効化処理を実行する（ステップＳ２−４）。これにより、ゲーム進行において、遅延が大きいクライアントの影響を抑制することができる。

【0058】

（４）上記実施形態では、管理サーバ２０の制御部２１は、レイテンシの最大値の特定処理（ステップＳ３−１）、最大値より大きいオフセットの決定処理（ステップＳ３−２）、オフセットの通知処理（ステップＳ３−３）を実行する。これにより、遅延が大きいクライアントにおいても、同時期にゲームを開始することができる。そして、各クライアントのユーザ端末１０、管理サーバ２０において、ゲーム進行の同期を図ることができる。

【0059】

（５）上記実施形態では、ユーザ端末１０は、操作要求処理を実行する（ステップＳ５−１）。この場合、ユーザ端末１０のゲーム処理部１２は、クライアントＡにおけるレイテンシを考慮したステップ数を算出する。これにより、管理サーバ２０のゲーム進行におけるステップ数を特定して、リクエストを行なうことができる。

【0060】

更に、ユーザ端末１０は、イベントまでの時間差の擬装処理を実行する（ステップＳ５−２）。これにより、クライアントにおける操作（オブジェクトの配置操作）からイベント実施（オブジェクトの配置）までの時間を確保することができる。

【0061】

（６）上記実施形態では、管理サーバ２０の制御部２１は、レイテンシの最大値の特定処理（ステップＳ６−２）、レイテンシに基づいて指定ステップの決定処理（ステップＳ６−３）、指定ステップの通知処理（ステップＳ６−４）を実行する。これにより、ゲームを行なっているグループの中に、遅延が大きいクライアントが含まれている場合にも、同時期にイベントを実行することができる。

【0062】

なお、上記実施形態は以下のように変更してもよい。
・上記実施形態では、管理サーバ２０の制御部２１は、レイテンシに基づいて指定ステップの決定処理を実行する（ステップＳ６−３）。ここで、レイテンシが大きい場合、他のユーザ端末１０における後続ステップでの操作に関するリクエストが、管理サーバ２０に先着することがある。この状況を考慮して、指定ステップを決定するようにしてもよい。

【0063】

図７を用いて、この場合のリクエスト対応処理を説明する。
この場合、管理サーバ２０の制御部２１は、ステップＳ６−１、Ｓ６−２と同様に、操作の検知処理（ステップＳ８−１）、レイテンシの最大値の特定処理（ステップＳ８−２）を実行する。

【0064】

次に、管理サーバ２０の制御部２１は、前後ステップの反転があるかどうかについての判定処理を実行する（ステップＳ８−３）。具体的には、制御部２１のゲーム管理部２１３は、リクエストに含まれるステップ数に基づいて、先に到着している後続ステップのリクエストがあるかどうかを確認する。先着リクエストに含まれるステップ数が、後着リクエストに含まれるステップ数が大きい場合には、前後ステップの反転があると判定する。

【0065】

前後ステップの反転がないと判定した場合（ステップＳ８−３において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、ステップＳ６−３と同様に、レイテンシに基づいて指定ステップの決定処理を実行する（ステップＳ８−４）。

【0066】

一方、前後ステップの反転があると判定した場合（ステップＳ８−３において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、先着リクエストに基づいて指定ステップの決定処理を実行する（ステップＳ８−５）。具体的には、制御部２１のゲーム管理部２１３は、先着リクエストにおける指定ステップよりも後のステップを指定する。ここでは、レイテンシの最大値に対してマージンを加算したイベント実施時刻を算出する。そして、ゲーム管理部２１３は、イベント実施時刻をステップ単位時間で除算して、イベント（オブジェクトの配置）を実施するステップ数を算出する。ここで、ゲーム管理部２１３は、算出したステップ数が先着リクエストにおける指定ステップよりも大きいかどうかを確認する。先着リクエストにおける指定ステップよりも小さい場合には、ゲーム管理部２１３は、先着リクエストにおける指定ステップに対して、レイテンシの最大値及びマージンに対応するステップ数を加算したステップ数を指定ステップ数として特定する。

【0067】

次に、管理サーバ２０の制御部２１は、ステップＳ６−４〜Ｓ６−６と同様に、指定ステップの通知処理（ステップＳ８−６）〜イベント実施処理（ステップＳ８−８）を実行する。

【0068】

これにより、レイテンシの違いにより、後続ステップ数におけるリクエストが先着した場合にも、リクエストの到着順番で対応することができる。なお、後着リクエストに対応した場合、ゲーム進行上、不都合が生じる場合には、後着リクエストを無視することも可能である。

【0069】

・上記実施形態では、ユーザ端末１０との接続状況を管理するための接続管理情報が記録される。接続管理情報には、グループＩＤ、クライアントＩＤ、レイテンシ、ステータスに関するデータが記録される。そして、各クライアントのレイテンシの最大値を用いて、ゲーム開始時刻や指定ステップを決定する。同期のために用いるレイテンシは、最大値に限定されるものではない。例えば、クライアント毎に、レイテンシ履歴を記録し、所定期間のレイテンシの平均値を用いるようにしてもよい。この場合には、平均値の最大値を用いて、同期を行なう。

【0070】

また、変動幅を一定値以下に抑えたような値を算出するようにしてもよい。この場合には、レイテンシ履歴に基づいて、統計的にレイテンシが含まれる値を用いる。例えば、レイテンシの平均値に対して標準偏差を加算した偏差値を用いる。この偏差値の最大値により、同期を行なう。

【0071】

・上記実施形態では、ユーザ端末１０は、レイテンシ測定処理を実行する（ステップＳ１−１）。そして、ユーザ端末１０は、レイテンシ送信処理を実行する（ステップＳ１−２）。これに代えて、管理サーバ２０において、レイテンシを測定するようにしてもよい。この場合には、制御部２１の遅延管理部２１２が、各クライアントのユーザ端末１０に対して、Ｐｉｎｇを送信して、レイテンシを計測する。そして、遅延管理部２１２は、各クライアントのユーザ端末１０に対して、それぞれのレイテンシを送信する。

【0072】

・上記実施形態では、定期的にＰｉｎｇを送信することにより、レイテンシ測定処理を実行する（ステップＳ１−１）。レイテンシ測定のタイミングはこれに限定されるものではない。ここで、レイテンシ測定間隔を、ゲーム種類によって、変更してもよい。この場合には、遅延管理部２１２に、ゲーム種類に対応させて、レイテンシ測定間隔を記録したタイミング情報を保持させておく。そして、遅延管理部２１２は、利用するゲーム種類に対応したレイテンシ測定間隔を特定し、このレイテンシ測定間隔を用いて、レイテンシ測定処理を実行する。ゲーム種別によっては、ゲーム進行における同期の意義は異なる。例えば、厳格に同期が必要なゲームもあれば、同期の必要性が緩やかなゲームもある。そこで、ゲーム種別に応じた同期状況（同期の厳格性）を考慮して、リクエストに対応することができる。
更に、ゲームの画面に応じて、レイテンシ測定間隔を変更するようにしてもよい。この場合には、ゲーム進行のステップ数に関連付けて、レイテンシ測定間隔を記録しておく。

【0073】

また、レイテンシ測定間隔を、レイテンシの分散状況によって変更してもよい。この場合には、遅延管理部２１２に、同じグループに属するユーザ端末１０のレイテンシの履歴を特定し、レイテンシの分布を算出する。そして、レイテンシの変化が少ない場合（変化幅が基準値以下の場合）には、レイテンシ測定間隔を大きくする。一方、レイテンシの変化が大きい場合（変化幅が基準値を超えている場合）には、レイテンシ測定間隔を小さくする。これにより、レイテンシの分散状況に応じて、レイテンシ評価の処理負担と正確性とのバランスを考慮して、ゲーム進行を図ることができる。

【0074】

また、レイテンシ測定間隔を、グループへの参加人数によって変更してもよい。この場合には、遅延管理部２１２に、参加人数に対応させて、レイテンシ測定間隔を記録したタイミング情報を保持させておく。そして、遅延管理部２１２は、利用するゲーム種類に対応したレイテンシ測定間隔を特定し、このレイテンシ測定間隔を用いて、レイテンシ測定処理を実行する。これにより、ゲーム参加人数の多少に応じて、効率的にゲーム進行を図ることができる。

【0075】

・上記実施形態では、クライアント異常と判定した場合（ステップＳ２−３において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、リクエスト無効化処理を実行する（ステップＳ２−４）。クライアント異常を判定するための閾値を変更可能としてもよい。この場合には、ここで、閾値をゲーム種類によって変更してもよい。この場合には、ゲーム管理部２１３に、ゲーム種類に対応させて、閾値を記録した閾値情報を保持させておく。そして、ゲーム管理部２１３は、利用するゲーム種類に対応した閾値を特定し、この閾値を用いて、リクエスト無効化処理を実行する。ゲーム種別によっては、ゲーム進行における同期の意義は異なるが、ゲーム種別に応じた同期状況（同期の厳格性）を考慮して、リクエストに対応することができる。
更に、ゲームの画面に応じて、閾値を変更するようにしてもよい。この場合には、ゲーム進行のステップ数に関連付けて、閾値を記録しておく。

【0076】

また、閾値を、レイテンシの分散状況によって変更してもよい。この場合には、ゲーム管理部２１３に、同じグループに属するユーザ端末１０のレイテンシの履歴を特定し、レイテンシの分布を算出する。そして、レイテンシの変化が少ない場合（変化幅が基準値以下の場合）には、閾値を大きくする。一方、レイテンシの変化が大きい場合（変化幅が基準値を超えている場合）には、閾値を小さくする。これにより、レイテンシの分散状況に応じてレイテンシの許容範囲を変更して、ゲーム進行を図ることができる。

【0077】

また、閾値を、グループにおけるゲーム参加人数によって変更してもよい。この場合には、ゲーム管理部２１３に、参加人数に対応させて、閾値を記録したタイミング情報を保持させておく。そして、ゲーム管理部２１３は、利用するゲーム種類に対応した閾値を特定し、この閾値を用いて、リクエスト無効化処理を実行する。この場合、ゲーム参加人数が多い場合には、閾値を上げて、許容範囲を広げる。これにより、ゲーム参加人数の多少に応じて、効率的にゲーム進行を図ることができる。

【0078】

・上記実施形態では、ユーザ端末１０は、ゲーム開始処理を実行する（ステップＳ４−２）。ここでは、ゲームに参加する各クライアントのユーザ端末１０において、同時期にゲームを開始し、ゲーム進行のステップ数の同期を行なう。ここで、ゲーム進行途中で、ステップ数の同期を図るようにしてもよい。この場合には、管理サーバ２０において、途中調整処理を実行する。この場合には、ゲーム管理部２１３に、同期の要否を判定するための閾値（遅延ステップ数）に関するデータを保持させておく。

【0079】

図８を用いて、途中調整処理を説明する。
ここでは、まず、ユーザ端末１０は、定期的に、ステップ数の送信処理を実行する（ステップＳ９−１）。具体的には、ユーザ端末１０のゲーム処理部１２は、管理サーバ２０に対して、定期的に現在ステップ数を送信する。

【0080】

この場合、管理サーバ２０の制御部２１は、ステップ数の取得処理を実行する（ステップＳ９−２）。具体的には、制御部２１のゲーム管理部２１３は、各クライアントのユーザ端末１０から、定期的に現在ステップ数を取得する。

【0081】

次に、管理サーバ２０の制御部２１は、レイテンシに基づいてステップ数の補正処理を実行する（ステップＳ９−３）。具体的には、制御部２１のゲーム管理部２１３は、現在ステップ数を取得したユーザ端末１０におけるレイテンシを、接続状況記憶部２３から取得する。次に、ゲーム管理部２１３は、レイテンシをステップ単位時間で除算した値を加算した値（遅延ステップ数）を算出する。そして、ゲーム管理部２１３は、現在ステップ数に遅延ステップ数を加算したローカルステップ数を算出する。

【0082】

次に、管理サーバ２０の制御部２１は、差分が閾値以上かどうかについての判定処理を実行する（ステップＳ９−４）。具体的には、制御部２１のゲーム管理部２１３は、ユーザ端末１０から取得した現在ステップ数を取得したときのサーバステップ数と、ローカルステップ数との差分を算出する。そして、ゲーム管理部２１３は、差分と閾値とを比較する。

【0083】

差分が閾値より小さいと判定した場合（ステップＳ９−４において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、途中調整処理を終了する。
一方、差分が閾値以上と判定した場合（ステップＳ９−４において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、レイテンシに基づいて現在ステップ数の補正処理を実行する（ステップＳ９−５）。具体的には、制御部２１のゲーム管理部２１３は、現在のサーバステップ数に対して、遅延ステップ数を加算した修正ステップ数を算出する。

【0084】

次に、管理サーバ２０の制御部２１は、同期指示処理を実行する（ステップＳ９−６）。具体的には、制御部２１のゲーム管理部２１３は、同期指示を、ステップ数を取得したユーザ端末１０に対して送信する。この同期指示には、修正ステップ数に関するデータを含める。

【0085】

そして、同期指示を取得したユーザ端末１０は、同期処理を実行する（ステップＳ９−７）。具体的には、ユーザ端末１０のゲーム処理部１２は、ゲーム進行を、管理サーバ２０から取得した修正ステップ数までスキップする。これにより、管理サーバ２０におけるゲーム進行と、クライアントにおけるゲーム進行とにズレが生じている場合にも、両者の同期を図ることができる。

【0086】

・上記実施形態では、クライアントＡ〜Ｃのユーザ端末１０が一つのグループとしてゲームを行なう場合を想定した。ここで、レイテンシを考慮してグループを生成するようにしてもよい。ここでは、レイテンシが所定範囲内に含まれるクライアントをまとめたグループを構成するグループ化処理を行なう。

【0087】

図９を用いて、グループ化処理を説明する。
ここでは、まず、管理サーバ２０の制御部２１は、参加希望者のレイテンシの取得処理を実行する（ステップＳ１０−１）。具体的には、制御部２１のゲーム管理部２１３は、ゲーム参加希望のクライアントのレイテンシを、ユーザ端末１０から取得する。

【0088】

次に、管理サーバ２０の制御部２１は、レイテンシの近いクライアントでグループ作成処理を実行する（ステップＳ１０−２）。具体的には、制御部２１のゲーム管理部２１３は、取得したレイテンシが所定範囲内に含まれるクライアントを特定する。そして、ゲーム管理部２１３は、特定したクライアントをゲーム情報記憶部２４に、グループとして登録する。

【0089】

次に、管理サーバ２０の制御部２１は、図３に示すゲーム開始時処理を実行する（ステップＳ１０−３）。
これにより、レイテンシの違いが少ないクライアントによりゲームを行なうことができるので、ゲーム進行の同期が容易となる。

【0090】

なお、ここで、ユーザの属性（ゲームスキルやレベル等）を考慮して、グループ作成を行なってもよい。この場合には、管理サーバ２０の制御部２１は、ユーザ情報記憶部２２に記録された属性に基づいて、共通するユーザ（グループ候補）を特定する。そして、管理サーバ２０の制御部２１は、グループ候補のユーザにおいて、グループ化処理を実行し、レイテンシの近いクライアントでグループ作成を行なう。

【符号の説明】

【0091】

１０…ユーザ端末、１１…遅延処理部、１２…ゲーム処理部、２０…管理サーバ、２１…制御部、２１１…ユーザ管理部、２１２…遅延管理部、２１３…ゲーム管理部、２１４…進行管理部、２２…ユーザ情報記憶部、２３…接続状況記憶部、２４…ゲーム情報記憶部。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】