特許 6689986 ゲーム内のキャラクタの移動制御方法、サーバ及びクライアント

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

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

(11)【特許番号】6689986

(24)【登録日】2020年4月10日

(45)【発行日】2020年4月28日

(54)【発明の名称】ゲーム内のキャラクタの移動制御方法、サーバ及びクライアント

(51)【国際特許分類】

   A63F 13/358 20140101AFI20200421BHJP

   A63F 13/55 20140101ALI20200421BHJP

   G06F 13/00 20060101ALI20200421BHJP

【ＦＩ】

   A63F13/358

   A63F13/55

   G06F13/00 650R

【請求項の数】16

【全頁数】27

(21)【出願番号】特願2018-533637(P2018-533637)

(86)(22)【出願日】2017年4月7日

(65)【公表番号】特表2019-508084(P2019-508084A)

(43)【公表日】2019年3月28日

(86)【国際出願番号】CN2017079734

(87)【国際公開番号】WO2017174028

(87)【国際公開日】20171012

【審査請求日】2018年6月25日

(31)【優先権主張番号】201610219234.4

(32)【優先日】2016年4月8日

(33)【優先権主張国】CN

(73)【特許権者】

【識別番号】514187420

【氏名又は名称】テンセント・テクノロジー・（シェンジェン）・カンパニー・リミテッド

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】ジャン，ジェンシン

(72)【発明者】

【氏名】クイウ，ビン

【審査官】 奈良田 新一

(56)【参考文献】

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

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

【文献】 中国特許出願公開第１０３７０１９１８（ＣＮ，Ａ）

【文献】 中国特許出願公開第１０２７６９６１６（ＣＮ，Ａ）

【文献】 中国特許出願公開第１０２３８７１３２（ＣＮ，Ａ）

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

【文献】 李弘基，ネットワークゲームの遅延と取り組み，ＳｏｆｔｗａｒｅＤｅｓｉｇｎ，日本，株式会社 技術評論社，２０１１年 ４月１８日，通巻312号，第50-59頁

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

Ａ６３Ｆ ９／２４，１３／００−１３／９８

Ｇ０６Ｆ １３／００

Ｈ０４Ｌ ２９／００−２９／１４

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

【請求項1】

ゲーム内でキャラクタの移動を制御するための方法であって、
サーバにより、第１のクライアントにより送信された移動要求データパケットを受信するステップであり、前記サーバは、同じゲームシナリオにおいて前記第１のクライアント上のキャラクタの移動及び第２のクライアント上のキャラクタの移動を管理するように構成されるステップと、
前記サーバにより、前記移動要求データパケットに従ってターゲットクライアントが前記第１のクライアントであるか前記第２のクライアントであるかを決定するステップであり、前記ターゲットクライアント上のキャラクタは、移動が前記第１のクライアントにより制御される必要のあるキャラクタであるステップと、
前記サーバにより、前記ターゲットクライアントの移動識別子を更新し、次に、前記ターゲットクライアントの前記更新された移動識別子を前記第１のクライアント及び前記第２のクライアントにブロードキャストするステップと
を含む方法。

【請求項2】

前記サーバにより、前記移動要求データパケットに従ってターゲットクライアントが前記第１のクライアントであるか前記第２のクライアントであるかを決定することは、
前記第１のクライアントが前記第１のクライアント上の現在のキャラクタの移動を制御するときに、前記移動要求データパケットが前記第１のクライアントの現在の移動識別子を搬送する場合、前記サーバにより、前記ターゲットクライアントが前記第１のクライアントであると決定すること、又は
前記移動要求データパケットが、前記第１のクライアントにより前記第２のクライアント上の前記キャラクタの移動を制御するための要求を搬送する場合、前記サーバにより、前記ターゲットクライアントが前記第２のクライアントであると決定すること
を含む、請求項１に記載の方法。

【請求項3】

前記サーバにより、前記移動要求データパケットに従ってターゲットクライアントが前記第１のクライアントであるか前記第２のクライアントであるかを決定した後に、
前記ターゲットクライアントが前記第１のクライアントであるときに、前記サーバにより、前記第１のクライアントの前記現在の移動識別子に従って、前記第１のクライアント上の前記現在のキャラクタの移動が前記サーバ内に設定されたズレ許容条件を満たすか否かを決定するステップと、
前記第１のクライアント上の前記現在のキャラクタの移動が前記ズレ許容条件を満たさない場合、前記サーバにより、前記第１のクライアントの前記現在の移動識別子を更新し、移動拒否命令を前記第１のクライアントに送信するステップであり、前記移動拒否命令は、前記第１のクライアントの前記更新された移動識別子を搬送するステップと
を更に含む、請求項２に記載の方法。

【請求項4】

前記サーバにより、前記ターゲットクライアントの移動識別子を更新することは、
前記ターゲットクライアントが前記第２のクライアントであるときに、前記サーバにより、前記サーバのローカル同期リストから前記第２のクライアントの記録された移動識別子を取得することと、
前記サーバにより、前記サーバ内に設定されたズレ許容条件に従って、前記第２のクライアントの前記記録された移動識別子を更新し、前記第２のクライアントの前記更新された移動識別子を保存することと
を含む、請求項２に記載の方法。

【請求項5】

前記サーバにより、前記ターゲットクライアントの前記更新された移動識別子を前記第１のクライアント及び前記第２のクライアントにブロードキャストした後に、前記第２のクライアントにより送信された移動要求データパケットを受信するステップであり、前記第２のクライアントにより送信された前記移動要求データパケットは、前記第２のクライアントが前記第２のクライアント上の現在のキャラクタの移動を制御するときに、前記第２のクライアントの現在の移動識別子を搬送するステップと、
前記サーバにより、前記第２のクライアントの前記現在の移動識別子に従って、前記第２のクライアント上の前記現在のキャラクタの移動が前記サーバ内に設定された前記ズレ許容条件を満たすか否かを決定するステップと、
前記第２のクライアント上の前記現在のキャラクタの移動が前記ズレ許容条件を満たさない場合、前記サーバにより、前記第２のクライアントにより送信された前記移動要求データパケットをフィルタ除去し、移動拒否命令を前記第２のクライアントに送信するステップと
を更に含む、請求項４に記載の方法。

【請求項6】

ゲーム内でキャラクタの移動を制御するための方法であって、
第１のクライアントにより、移動要求データパケットをサーバに送信し、前記サーバにより、前記移動要求データパケットに従ってターゲットクライアントが前記第１のクライアントであるか第２のクライアントであるかを決定するステップであり、前記ターゲットクライアント上のキャラクタは、移動が前記第１のクライアントにより制御される必要のあるキャラクタであるステップと、
前記第１のクライアントにより、前記サーバにより送信された前記ターゲットクライアントの更新された移動識別子を受信するステップと、
前記第１のクライアントにより、前記ターゲットクライアントの前記受信した更新された移動識別子に従って、前記ターゲットクライアント上のキャラクタの移動を表示するステップと
を含む方法。

【請求項7】

前記第１のクライアントにより、移動要求データパケットをサーバに送信することは、
前記第１のクライアントにより、前記第１のクライアント上の現在のキャラクタの移動に対する制御を決定し、前記第１のクライアントにより、前記第１のクライアントの現在の移動識別子を搬送する前記移動要求データパケットを前記サーバに送信すること、又は
前記第１のクライアントにより、同じゲームシナリオにおいて前記第２のクライアント上のキャラクタの移動に対する制御を決定し、前記第１のクライアントにより、制御要求を搬送する前記移動要求データパケットを前記サーバに送信すること
を含む、請求項６に記載の方法。

【請求項8】

前記第１のクライアントにより、前記第１のクライアントの現在の移動識別子を搬送する前記移動要求データパケットを前記サーバに送信することは、
前記第１のクライアントにより、前記サーバにより送信された前記ターゲットクライアントの前記更新された移動識別子を受信する前に、前記第１のクライアントの前記現在の移動識別子を搬送する前記移動要求データパケットを複数回繰り返し送信すること
を含む、請求項７に記載の方法。

【請求項9】

第１のクライアントにより送信された移動要求データパケットを受信するように構成された受信モジュールであり、サーバは、同じゲームシナリオにおいて前記第１のクライアント上のキャラクタの移動及び第２のクライアント上のキャラクタの移動を管理するように構成される受信モジュールと、
前記移動要求データパケットに従ってターゲットクライアントが前記第１のクライアントであるか前記第２のクライアントであるかを決定するように構成されたターゲットクライアント決定モジュールであり、前記ターゲットクライアント上のキャラクタは、移動が前記第１のクライアントにより制御される必要のあるキャラクタであるターゲットクライアント決定モジュールと、
前記ターゲットクライアントの移動識別子を更新するように構成された移動識別子処理モジュールであり、次に、前記サーバが前記ターゲットクライアントの前記更新された移動識別子を前記第１のクライアント及び前記第２のクライアントにブロードキャストする移動識別子処理モジュールと
を含むサーバ。

【請求項10】

前記ターゲットクライアント決定モジュールは、前記第１のクライアントが前記第１のクライアント上の現在のキャラクタの移動を制御するときに、前記移動要求データパケットが前記第１のクライアントの現在の移動識別子を搬送する場合、前記ターゲットクライアントが前記第１のクライアントであると決定するか、或いは前記移動要求データパケットが、前記第１のクライアントにより前記第２のクライアント上の前記キャラクタの移動を制御するための要求を搬送する場合、前記ターゲットクライアントが前記第２のクライアントであると決定するように構成される、請求項９に記載のサーバ。

【請求項11】

前記サーバは、第１の移動決定モジュールを更に含み、
前記第１の移動決定モジュールは、前記ターゲットクライアント決定モジュールが、前記移動要求データパケットに従って前記ターゲットクライアントが前記第１のクライアントであるか前記第２のクライアントであるかを決定した後に、前記ターゲットクライアントが前記第１のクライアントであるときに、前記第１のクライアントの前記現在の移動識別子に従って、前記第１のクライアント上の前記現在のキャラクタの移動が前記サーバ内に設定されたズレ許容条件を満たすか否かを決定するように構成され、
前記移動識別子処理モジュールは、前記第１のクライアント上の前記現在のキャラクタの移動が前記ズレ許容条件を満たさない場合、前記第１のクライアントの前記現在の移動識別子を更新し、移動拒否命令を前記第１のクライアントに送信するように更に構成され、前記移動拒否命令は、前記第１のクライアントの前記更新された移動識別子を搬送する、請求項１０に記載のサーバ。

【請求項12】

前記移動識別子処理モジュールは、
前記ターゲットクライアントが前記第２のクライアントであるときに、前記サーバのローカル同期リストから前記第２のクライアントの記録された移動識別子を取得するように構成された移動識別子読み取りモジュールと、
前記サーバ内に設定されたズレ許容条件に従って、前記第２のクライアントの前記記録された移動識別子を更新し、前記第２のクライアントの前記更新された移動識別子を保存するように構成された移動識別子更新モジュールと
を含む、請求項１０に記載のサーバ。

【請求項13】

前記サーバは、第２の移動決定モジュールと、データパケットフィルタ除去モジュールとを更に含み、
前記受信モジュールは、前記移動識別子処理モジュールが前記ターゲットクライアントの前記更新された移動識別子を前記第１のクライアント及び前記第２のクライアントにブロードキャストした後に、前記第２のクライアントにより送信された移動要求データパケットを受信するように更に構成され、前記第２のクライアントにより送信された前記移動要求データパケットは、前記第２のクライアントが前記第２のクライアント上の現在のキャラクタの移動を制御するときに、前記第２のクライアントの現在の移動識別子を搬送し、
前記第２の移動決定モジュールは、前記第２のクライアントの前記現在の移動識別子に従って、前記第２のクライアント上の前記現在のキャラクタの移動が前記サーバ内に設定された前記ズレ許容条件を満たすか否かを決定するように構成され、
前記データパケットフィルタ除去モジュールは、前記第２のクライアント上の前記現在のキャラクタの移動が前記ズレ許容条件を満たさない場合、前記第２のクライアントにより送信された前記移動要求データパケットをフィルタ除去し、移動拒否命令を前記第２のクライアントに送信するように構成される、請求項１２に記載のサーバ。

【請求項14】

第１のクライアントであるクライアントであり、前記第１のクライアント及び第２のクライアントは同じゲームシナリオにあるクライアントであって、
移動要求データパケットをサーバに送信するように構成された送信モジュールであり、前記サーバが、前記移動要求データパケットに従ってターゲットクライアントが前記第１のクライアントであるか第２のクライアントであるかを決定し、前記ターゲットクライアント上のキャラクタは、移動が前記第１のクライアントにより制御される必要のあるキャラクタである送信モジュールと、
前記サーバにより送信された前記ターゲットクライアントの更新された移動識別子を受信するように構成された受信モジュールと、
前記ターゲットクライアントの前記受信した更新された移動識別子に従って、前記ターゲットクライアント上のキャラクタの移動を表示するように構成された表示モジュールと
を含むクライアント。

【請求項15】

前記送信モジュールは、前記第１のクライアントが前記第１のクライアント上の現在のキャラクタの移動に対する制御を決定したときに、前記第１のクライアントの現在の移動識別子を搬送する前記移動要求データパケットを前記サーバに送信するか、或いは
前記第１のクライアントが同じゲームシナリオにおいて前記第２のクライアント上のキャラクタの移動に対する制御を決定したときに、制御要求を搬送する前記移動要求データパケットを前記サーバに送信するように構成される、請求項１４に記載のクライアント。

【請求項16】

前記送信モジュールは、前記サーバにより送信された前記ターゲットクライアントの前記更新された移動識別子を受信する前に、前記第１のクライアントの前記現在の移動識別子を搬送する前記移動要求データパケットを複数回繰り返し送信するように構成される、請求項１５に記載のクライアント。

【発明の詳細な説明】

【技術分野】

【0001】

［関連出願］
この出願は、2016年4月8日に中国特許庁に出願された「METHOD FOR CONTROLLING CHARACTER MOVEMENT IN GAME, SERVER, AND CLIENT」という名称の中国特許出願第201610219234.4号の優先権を主張し、その全内容を参照により援用する。

【0002】

［技術分野］
この出願は、コンピュータ技術の分野に関し、特にゲーム内でキャラクタの移動を制御するための方法、サーバ及びクライアントに関する。

【背景技術】

【0003】

データパケットがネットワークにおいて送信されるときに、通常では遅延が発生する。したがって、サーバ（server）とクライアント（client）とを含む構成に基づいて、どのようにオンラインゲームのための同期を実現するかは、非常に困難な問題になっている。クライアント上のキャラクタの移動は、クライアントの操作ユーザにより制御される。クライアントがユーザにより送信されたローカル命令にスムーズに応答することが確保されるときに、適時の同期は有効には確保できない。デバイスが同じローカルエリアネットワーク内にあっても、送信遅延は、いくつかの誤操作を生じる可能性がある。この問題を解決するために、既存の技術では、オンラインゲームのための推測航法（dead reckoning）アルゴリズムが設計されている。

【0004】

マルチプレイヤオンラインバトルアリーナ（multiplayer online battle arena, MOBA）ゲームでは、ほとんどのクライアントは、通常のネットワーク遅延が存在するときにプレイヤの全てがスタンドアローンゲームをする体験と同様の体験を有するように、移動制御のための望ましい解決策を備える必要がある。例えば、MOBAゲームの5v5モードでは、各クライアントがサーバと相互作用する必要がある。ネットワーク遅延のため、１つのクライアントにより取得された他の９個のクライアントの第三者データパケットは遅延する。遅延は、具体的には上りリンク又は下りリンクネットワーク送信時間に反映される。例えば、方向変更、転回又は停止のような移動に関する操作は、操作を実行するプレイヤの視角と他のプレイヤの視角との間に差を生じる可能性がある。

【0005】

既存の技術において提供されるdead reckoningアルゴリズムを用いて、移動経路が同期できる。移動ネットワーク環境では、如何なる小さい移動（例えば、移動コンパスがクライアント上でタッチされるだけである）についても、移動要求が送信される。クライアントの間でほとんど相互作用が存在しないときに、ゲーム体験は比較的望ましい。しかし、複数の入力が複数の出力を生成し且つ出力が相互に影響するときに、データパケット数が必然的に増加し、各クライアントにおけるジッタも増加する。したがって、キャラクタのゆがみ又は瞬時移動が複数のゲームクライアント上で発生する可能性があり、ゲーム体験を低下させる。

【発明の概要】

【0006】

この出願の実施例は、クライアント上のキャラクタの移動によって生じるジッタを低減し、それにより、ゲーム体験を改善するための、ゲーム内でキャラクタの移動を制御するための方法、サーバ及びクライアントを提供する。

【0007】

前述の技術的課題を解決するために、本発明の実施例は以下の技術的解決策を提供する。

【0008】

第１の態様によれば、この出願の実施例は、ゲーム内でキャラクタの移動を制御するための方法を提供し、
サーバにより、第１のクライアントにより送信された移動要求データパケットを受信するステップであり、サーバは、同じゲームシナリオにおいて第１のクライアント上のキャラクタの移動及び第２のクライアント上のキャラクタの移動を管理するように構成されるステップと、
サーバにより、移動要求データパケットに従ってターゲットクライアントが第１のクライアントであるか第２のクライアントであるかを決定するステップであり、ターゲットクライアント上のキャラクタは、移動が第１のクライアントにより制御される必要のあるキャラクタであるステップと、
サーバにより、ターゲットクライアントの移動識別子を更新し、次に、ターゲットクライアントの更新された移動識別子を第１のクライアント及び第２のクライアントにブロードキャストするステップと
を含む。

【0009】

第２の態様によれば、この出願の実施例は、ゲーム内でキャラクタの移動を制御するための方法を更に提供し、
第１のクライアントにより、移動要求データパケットをサーバに送信し、サーバにより、移動要求データパケットに従ってターゲットクライアントが第１のクライアントであるか第２のクライアントであるかを決定するステップであり、ターゲットクライアント上のキャラクタは、移動が第１のクライアントにより制御される必要のあるキャラクタであるステップと、
第１のクライアントにより、サーバにより送信されたターゲットクライアントの更新された移動識別子を受信するステップと、
第１のクライアントにより、ターゲットクライアントの受信した更新された移動識別子に従って、ターゲットクライアント上のキャラクタの移動を表示するステップと
を含む。

【0010】

第３の態様によれば、この出願の実施例は、サーバを更に提供し、
第１のクライアントにより送信された移動要求データパケットを受信するように構成された受信モジュールであり、サーバは、同じゲームシナリオにおいて第１のクライアント上のキャラクタの移動及び第２のクライアント上のキャラクタの移動を管理するように構成される受信モジュールと、
移動要求データパケットに従ってターゲットクライアントが第１のクライアントであるか第２のクライアントであるかを決定するように構成されたターゲットクライアント決定モジュールであり、ターゲットクライアント上のキャラクタは、移動が第１のクライアントにより制御される必要のあるキャラクタであるターゲットクライアント決定モジュールと、
ターゲットクライアントの移動識別子を更新するように構成された移動識別子処理モジュールであり、次に、サーバがターゲットクライアントの更新された移動識別子を第１のクライアント及び第２のクライアントにブロードキャストする移動識別子処理モジュールと
を含む。

【0011】

第４の態様によれば、この出願の実施例は、クライアントを更に提供し、クライアントは第１のクライアントであり、第１のクライアント及び第２のクライアントは同じゲームシナリオにあり、第１のクライアントは、
移動要求データパケットをサーバに送信するように構成された送信モジュールであり、サーバは、移動要求データパケットに従ってターゲットクライアントが第１のクライアントであるか第２のクライアントであるかを決定し、ターゲットクライアント上のキャラクタは、移動が第１のクライアントにより制御される必要のあるキャラクタである送信モジュールと、
サーバにより送信されたターゲットクライアントの更新された移動識別子を受信するように構成された受信モジュールと、
ターゲットクライアントの受信した更新された移動識別子に従って、ターゲットクライアント上のキャラクタの移動を表示するように構成された表示モジュールと
を含む。

【0012】

前述の技術的解決策から、この出願の実施例は以下の利点を有することが認識できる。

【0013】

この出願の実施例では、第１のクライアントは、移動要求データパケットをサーバに送信し、サーバは、移動要求データパケットに従ってターゲットクライアントが第１のクライアントであるか第２のクライアントであるかを決定し、次に、サーバは、ターゲットクライアントの移動識別子を更新し、サーバは、ターゲットクライアントの更新された移動識別子を第１のクライアント及び第２のクライアントにブロードキャストする。ターゲットクライアントを決定した後に、サーバは、ターゲットクライアントの移動識別子を更新してブロードキャストしてもよく、第１のクライアント及び第２のクライアントの双方は、サーバのブロードキャストを用いてターゲットクライアントの移動識別子を取得できる。したがって、第１のクライアントは、サーバにより更新された移動識別子に従って、ターゲットクライアント上のキャラクタの移動を表示する必要があり、それにより、ターゲットクライアント上のキャラクタの移動は、ターゲットクライアントの移動識別子に対してサーバにより実行された更新に従って表示される。第１のクライアントは、サーバにより更新された移動識別子が取得された後にのみ、ターゲットクライアント上のキャラクタの移動を表示し、それにより、クライアント上のキャラクタの移動によって生じるジッタを低減し、それにより、ゲーム体験を改善する。

【図面の簡単な説明】

【0014】

この出願の実施例の技術的解決策をより明確に説明するために、以下に、実施例を説明するために必要な添付図面について簡単に紹介する。明らかに、以下の説明における添付図面は、この出願のいくつかの実施例のみを示しており、当業者は、依然としてこれらの添付図面から他の図面を導き得る。

【図1】この出願の実施例に従ってゲーム内でキャラクタの移動を制御するための方法の概略ブロックフローチャートである。

【図2】この出願の実施例に従ってゲーム内でキャラクタの移動を制御するための他の方法の概略ブロックフローチャートである。

【図3a】この出願の実施例によるクライアントのシーケンス番号の間の同期の適用シナリオの概略図である。

【図3b】この出願の実施例によるクライアントのシーケンス番号の間の同期の他の適用シナリオの概略図である。

【図4】この出願の実施例に従ってシーケンス番号が同期されないときのゲーム場面の概略図である。

【図5】この出願の実施例に従ってシーケンス番号が同期された後のゲーム場面の概略図である。

【図6a】この出願の実施例によるサーバの概略構造組成図である。

【図6b】この出願の実施例による他のサーバの概略構造組成図である。

【図6c】この出願の実施例による移動識別子処理モジュールの概略構造組成図である。

【図6d】この出願の実施例による他のサーバの概略構造組成図である。

【図7】この出願の実施例によるクライアントの概略構造組成図である。

【図8】この出願の実施例に従ってゲーム内でキャラクタの移動を制御するための方法をサーバに適用する概略構造組成図である。

【図9】この出願の実施例に従ってゲーム内でキャラクタの移動を制御するための方法を端末に適用する概略構造組成図である。

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

【0015】

この出願の実施例は、クライアント上のキャラクタの移動によって生じるジッタを低減し、それにより、ゲーム体験を改善するための、ゲーム内でキャラクタの移動を制御するための方法、サーバ及びクライアントを提供する。

【0016】

この出願の目的、特徴及び利点をより分かりやすくするために、以下に、この出願の実施例における添付図面を参照して、この出願の実施例における技術的解決策を明確且つ完全に説明する。明らかに、説明する実施例は、実施例の全部ではなく、この出願の実施例の一部のみである。この出願の実施例に基づいて当業者により取得される全ての他の実施例は、この出願の保護範囲内に入るものとする。

【0017】

この出願の明細書及び特許請求の範囲において、「含む」、「有する」という用語及びこれらのいずれかの変形は、非排他的な包含をカバーすることを意図し、それにより、一連のユニットを含むプロセス、方法、システム、プロダクト又はデバイスに関して、プロセス、方法、システム、プロダクト又はデバイスはこのようなユニットを含むだけでなく、明確に指定されていないユニット又はプロセス、方法、プロダクト若しくはデバイスに固有のユニットも含む。

【0018】

詳細な説明がそれぞれ以下に提供される。

【0019】

この出願におけるゲーム内でキャラクタの移動を制御するための方法の実施例は、プレイヤが操作を用いてクライアント上のキャラクタの移動を制御するシナリオに具体的に適用されてもよい。図１を参照すると、図１は、この出願の実施例に従ってゲーム内でキャラクタの移動を制御するための方法を示す。方法は以下のステップを含んでもよい。

【0020】

101：サーバは、第１のクライアントにより送信された移動要求データパケットを受信し、サーバは、同じゲームシナリオにおいて第１のクライアント上のキャラクタの移動及び第２のクライアント上のキャラクタの移動を管理するように構成される。

【0021】

この出願のこの実施例では、通信接続は、サーバと第１のクライアントとの間且つサーバと第２のクライアントとの間にそれぞれ確立される。サーバは、各クライアント上のキャラクタの移動を制御するように構成される。この出願のこの実施例では、サーバが同じゲームシナリオにおいて２つのクライアント（すなわち、第１のクライアント及び第２のクライアント）を管理することが、例示的な説明の例として使用されるが、これは限定されるものではない。この出願のこの実施例におけるサーバは、代替としてより多くのクライアントを管理してもよい。例えば、サーバは、同じゲームシナリオにある第１のクライアント、第２のクライアント及び第３のクライアントと通信接続してもよい。サーバがクライアント上のキャラクタの移動を制御する方式は、この出願のこの実施例における２つのクライアントとサーバとの間の相互作用プロセスと同様であり、この出願の後の実施例における複数の適用シナリオの説明に参照が行われてもよい。

【0022】

この出願のこの実施例では、第１のクライアントが移動要求を送信するための送信エンドとして使用されることが、詳細な説明の例として使用されるが、これは限定されるものではない。この出願のこの実施例では、第２のクライアントもまた、移動要求を送信するための送信エンドとして使用できる。まず、移動が制御される必要のあるキャラクタを決定した後に、第１のクライアントは、移動要求データパケットを生成し、第１のクライアントとサーバとの間の通信接続を用いて移動要求データパケットを送信する。サーバは、第１のクライアントから移動要求データパケットを受信できる。

【0023】

102：サーバは、移動要求データパケットに従ってターゲットクライアントが第１のクライアントであるか第２のクライアントであるかを決定し、ターゲットクライアント上のキャラクタは、移動が第１のクライアントにより制御される必要のあるキャラクタである。

【0024】

この出願のこの実施例では、移動要求データパケットを受信した後に、サーバは、移動要求データパケット内で搬送される要求内容に従って、同じゲームシナリオにおけるクライアント上のキャラクタの中で、移動が第１のクライアントにより制御される必要のあるキャラクタを決定する。同じゲームシナリオにおいて、移動が第１のクライアントにより制御される必要のあるキャラクタのクライアントは、ターゲットクライアントと呼ばれる。サーバが第１のクライアント上のキャラクタの移動及び第２のクライアント上のキャラクタの移動を管理する場合、ターゲットクライアントは、第１のクライアント又は第２のクライアントでもよい。サーバは、受信した移動要求データパケットに従ってクライアントの中でターゲットクライアントを決定してもよい。

【0025】

例えば、この出願のいくつかの実施例では、ステップ102において、サーバにより、移動要求データパケットに従ってターゲットクライアントが第１のクライアントであるか第２のクライアントであるかを決定することは、以下のステップを具体的に含んでもよい。

【0026】

A1：第１のクライアントが第１のクライアント上の現在のキャラクタの移動を制御するときに、移動要求データパケットが第１のクライアントの現在の移動識別子を搬送する場合、サーバは、ターゲットクライアントが第１のクライアントであると決定するか、或いは
A2：移動要求データパケットが、第１のクライアントにより第２のクライアント上のキャラクタの移動を制御するための要求を搬送する場合、サーバは、ターゲットクライアントが第２のクライアントであると決定する。

【0027】

この出願の前述の実施例のステップA1において、第１のクライアントが第１のクライアント上のキャラクタの移動を制御する必要がある場合、例えば、第１のクライアントが移動コンパスを用いて第１のクライアント上のキャラクタを前進させるように制御する場合、第１のクライアントは、第１のクライアントの現在の移動識別子が移動要求データパケット内で搬送されることを可能にしてもよい。したがって、サーバは、移動要求データパケット内で搬送される第１のクライアントの現在の移動識別子に従って、第１のクライアントにより今回制御されるターゲットが第１のクライアント上のキャラクタであると決定してもよい。すなわち、この場合、サーバは、ターゲットクライアントが第１のクライアントであると決定する。ステップA2に示すシナリオにおいて、ステップA2とステップA1との違いは、第１のクライアントが第１のクライアント上のキャラクタの移動を制御でき、また、同じゲームシナリオにおいて他のクライアント上のキャラクタの移動も制御できる点である。例えば、第１のクライアント上のキャラクタは、攻撃を行う必要があり、攻撃された対象は、第２のクライアント上のキャラクタである。この場合、第１のクライアントの現在の制御動作は、第２のクライアントを制御することである。第１のクライアントにより送信された移動要求データパケットは、第２のクライアントを制御するための要求を搬送してもよい。すなわち、この場合、サーバは、移動要求データパケット内で搬送される制御要求に従って、第１のクライアントにより今回制御されるターゲットが第２のクライアントであると決定できる。前述の例に従って、第１のクライアントは、第１のクライアント上のキャラクタの移動を制御してもよく、或いは他のクライアント上のキャラクタの移動を制御してもよい。異なる実現シナリオにおいて、サーバは、移動要求データパケットを解析することにより、ターゲットクライアントを決定してもよい。

【0028】

この出願のいくつかの実施例では、ステップ102において、サーバにより、移動要求データパケットに従ってターゲットクライアントが第１のクライアントであるか第２のクライアントであるかを決定した後に、この出願のこの実施例に従ってゲーム内でキャラクタの移動を制御するための方法において、ステップ103がその後に実行されてもよく、或いは以下のステップが実行されてもよい。

【0029】

B1：ターゲットクライアントが第１のクライアントであるときに、サーバは、第１のクライアントの現在の移動識別子に従って、第１のクライアント上の現在のキャラクタの移動がサーバ内に設定されたズレ許容条件を満たすか否かを決定する。

【0030】

B2：第１のクライアント上の現在の移動がズレ許容条件を満たさない場合、サーバは、第１のクライアントの現在の移動識別子を更新し、移動拒否命令を第１のクライアントに送信し、移動拒否命令は、第１のクライアントの更新された移動識別子を搬送する。

【0031】

この出願の前述の実施例のステップB1において、ターゲットクライアントが第１のクライアントである適用シナリオが記載されている。ズレ許容条件は、サーバ内に設定される。ズレ許容条件は、サーバがクライアントにより生成されたズレを許容できる条件である。ズレ許容条件は、具体的な適用シナリオに従ってサーバにより設定される。第１のクライアントの現在の移動動作は、ズレ許容条件を用いて決定でき、第１のクライアントの現在の移動動作がサーバの許容限度を超えているか否かを決定する。例えば、第１のクライアントにより送信された移動要求データパケット内で搬送される第１のクライアントの現在の移動識別子は、キャラクタの移動のために第１のクライアントにより設定された現在のシーケンス番号でもよく、サーバ内に設定されたズレ許容条件は、サーバ内に予め設定された許容シーケンス番号閾値でもよい。第１のクライアントの現在のシーケンス番号が許容シーケンス番号閾値を超えるか否かを決定することにより、第１のクライアント上の現在のキャラクタの移動がズレ許容条件を満たすか否かが決定できる。他の例では、第１のクライアントの現在の移動識別子は、代替として、キャラクタの移動のために第１のクライアントにより設定された現在の移動トークンでもよく、サーバ内に設定されたズレ許容条件は、サーバ内に予め設定された許容トークン番号でもよい。第１のクライアントの現在の移動トークンが許容トークン番号と同じであるか否かを決定することにより、第１のクライアント上の現在の移動がズレ許容条件を満たすか否かが決定できる。第１のクライアント上の現在の移動がズレ許容条件を満たさない場合、サーバは、第１のクライアントの現在の移動識別子を更新し、移動拒否命令を第１のクライアントに送信してもよく、移動拒否命令は、第１のクライアントの更新された移動識別子を搬送する。サーバは、第１のクライアント上の現在のキャラクタの移動がズレ許容条件を満たさない、すなわち、第１のクライアント上の現在のキャラクタの移動がサーバにより受け付けないと決定し、サーバは、移動拒否命令を送信し、それにより、第１のクライアント上の現在のキャラクタの移動を拒否してもよい。第１のクライアント上の現在のキャラクタの移動は、第２のクライアントのような他のクライアントに表示されず、それにより、第１のクライアント上の現在のキャラクタの移動により生じる第２のクライアントとの移動の衝突を回避する。

【0032】

103：サーバは、ターゲットクライアントの移動識別子を更新し、次に、ターゲットクライアントの更新された移動識別子を第１のクライアント及び第２のクライアントにブロードキャストする。

【0033】

この出願のこの実施例では、ターゲットクライアントを決定した後に、サーバは、ターゲットクライアントの移動識別子を更新する。この出願のこの実施例では、サーバは、各クライアントにより制御されるキャラクタの移動識別子を設定する。サーバは、ローカル同期リストをローカルで管理してもよく、ローカル同期リストを用いて各クライアント上のキャラクタの移動を管理する。サーバは、クライアント上のキャラクタの移動を制御する当事者であり、クライアントの移動識別子を更新することにより、クライアント上のキャラクタの移動が有効であることを示す。この出願のこの実施例では、サーバは、ターゲットクライアントの移動識別子を更新し、それにより、サーバがターゲットクライアント上のキャラクタの移動を承認したことを示す。次に、サーバは、ターゲットクライアントの移動識別子を更新し、ターゲットクライアントの更新された移動識別子を取得する。次に、サーバは、ブロードキャストメッセージを用いてターゲットクライアントの更新された移動識別子を複数のクライアント（この例では第１のクライアント及び第２のクライアント）に送信する。ブロードキャストメッセージを受信したクライアントは、ターゲットクライアントの更新された移動識別子を受信することにより、ターゲットクライアント上のキャラクタの移動を表示する。この出願のこの実施例では、クライアント上のキャラクタの移動を制御する権利は、サーバにおいて設定される。サーバは、各クライアント上のキャラクタの移動を管理でき、それにより、既存技術においてサーバがデータパケットのネットワーク転送デバイスとしてのみ機能するという状況を変更する。したがって、クライアント上のキャラクタの移動は、サーバが移動識別子を更新するか否かに依存し、それにより、各クライアントは、ターゲットクライアント上のキャラクタの移動を適切に表示し、それにより、既存技術において複数のクライアントの複数の入力が複数の出力を生成し且つ出力が相互に影響するときに生成されるジッタを低減し、キャラクタのゆがみ又は瞬間移動が複数のゲームクライアント上で発生することを回避し、クライアントに表示されるキャラクタのゆがみ又は瞬間移動を有効に軽減し、ユーザのゲーム体験を改善する。

【0034】

この出願のいくつかの実施例では、ステップ103において、サーバにより、ターゲットクライアントの移動識別子を更新することは、以下のステップを具体的に含んでもよい。

【0035】

C1：サーバは、移動要求データパケットから第１のクライアントの現在の移動識別子を取得する。

【0036】

C2：サーバは、第１のクライアントの現在の移動識別子を更新し、第１のクライアントの更新された移動識別子を保存する。

【0037】

ターゲットクライアントが第１のクライアントであるときに、サーバは、移動要求データパケットから第１のクライアントの現在の移動識別子を取得してもよく、第１のクライアントの現在の移動識別子を更新し、サーバが第１のクライアント上のキャラクタの移動を承認したことを示してもよい。サーバは、第１のクライアントの更新された移動識別子をローカル同期リストに保存する。第１のクライアントの更新された移動識別子は、第１のクライアント上の次のキャラクタの移動がサーバにより受け付けられるか否かを決定するための基礎として使用されてもよい。

【0038】

この出願のいくつかの実施例では、前述の実施例において、ターゲットクライアントが第１のクライアントであるときに移動識別子を更新するための方式が記載されている。以下に、ターゲットクライアントが第２のクライアントであるときに移動識別子を更新するための方式を紹介する。具体的には、ステップ103において、サーバにより、ターゲットクライアントの移動識別子を更新することは、以下のステップを具体的に含んでもよい。

【0039】

D1：ターゲットクライアントが第２のクライアントであるときに、サーバは、サーバのローカル同期リストから第２のクライアント上の記録された移動識別子を取得する。

【0040】

D2：サーバは、サーバ内に設定されたズレ許容条件に従って、第２のクライアントの記録された移動識別子を更新し、第２のクライアントの更新された移動識別子を保存する。

【0041】

この出願の前述の実施例のステップD1において、ターゲットクライアントが第２のクライアントである適用シナリオが記載されている。サーバはローカル同期リストを保存する。異なるクライアントについて、各クライアントの記録された移動識別子がローカル同期リストに保存される。第１のクライアントが第２のクライアント上のキャラクタの移動を制御するシナリオでは、サーバは、まず、第２のクライアントの記録された移動識別子を取得してもよい。ズレ許容条件もまたサーバ内に設定される。ズレ許容条件は、サーバがクライアントにより生成されたズレを許容できる条件である。ズレ許容条件は、具体的な適用シナリオに従ってサーバにより設定される。キャラクタが第１のクライアントにより制御されるときの第２のクライアント上のキャラクタの移動動作は、ズレ許容条件に従って決定でき、第２のクライアント上のキャラクタの現在の移動動作がサーバの許容限度を超えているか否かを決定し、それにより、サーバは、どのように第２のクライアントの記録された移動識別子を更新するかを決定できる。例えば、サーバにより取得された、第２のクライアントの記録された移動識別子は、キャラクタの移動のために第２のクライアントにより設定された現在のシーケンス番号でもよく、サーバ内に設定されたズレ許容条件は、サーバ内に予め設定された許容シーケンス番号閾値でもよい。第２のクライアントの現在のシーケンス番号が許容シーケンス番号閾値を超えるか否かを決定することにより、第２のクライアント上の現在のキャラクタの移動がズレ許容条件を満たすか否かが決定できる。他の例では、第２のクライアントの記録された移動識別子は、代替として、キャラクタの移動のために第２のクライアントにより設定された現在の移動トークンでもよく、サーバ内に設定されたズレ許容条件は、サーバ内に予め設定された許容トークン番号でもよい。第２のクライアントの現在の移動トークンが許容トークン番号と同じであるか否かを決定することにより、第２のクライアント上の現在のキャラクタの移動がズレ許容条件を満たすか否かが決定できる。

【0042】

さらに、この適用において、ステップD1及びD2が実行される他の実施例では、ゲーム内でキャラクタの移動を制御するための方法において、以下のステップが更に実行されてもよい。

【0043】

E1：サーバは、ターゲットクライアントの更新された移動識別子を第１のクライアント及び第２のクライアントにブロードキャストした後に、第２のクライアントにより送信された移動要求データパケットを受信し、第２のクライアントにより送信された移動要求データパケットは、第２のクライアントが第２のクライアント上の現在のキャラクタの移動を制御するときに、第２のクライアントの現在の移動識別子を搬送する。

【0044】

E2：サーバは、第２のクライアントの現在の移動識別子に従って、第２のクライアント上の現在のキャラクタの移動がサーバ内に設定されたズレ許容条件を満たすか否かを決定する。

【0045】

E3：第２のクライアント上の現在のキャラクタの移動がズレ許容条件を満たさない場合、サーバは、第２のクライアントにより送信された移動要求データパケットをフィルタ除去し、移動拒否命令を第２のクライアントに送信する。

【0046】

サーバは、第２のクライアントの更新された移動識別子を第１のクライアント及び第２のクライアントにブロードキャストする。第２のクライアントがまた、第２のクライアントの更新された移動識別子を受信する前に、移動要求データパケットをサーバに送信した場合、サーバは、移動要求データパケットから第２のクライアントの現在の移動識別子を取得してもよく、次に、第２のクライアント上の現在のキャラクタの移動がサーバ内に設定されたズレ許容条件を満たすか否かを決定する。具体的な決定方式についてステップB1及びB2における詳細な説明に参照が行われてもよい。第２のクライアント上の現在のキャラクタの移動がズレ許容条件を満たさないと決定されたときに、これは、サーバが第２のクライアント上のキャラクタの移動を受け付けないことを示す。サーバは、第２のクライアントにより送信された移動要求パケットをフィルタ除去し、移動拒否命令を第２のクライアントに送信し、それにより、第２のクライアント上の現在の移動は、第１のクライアントのような第三者クライアントに表示されず、それにより、第２のクライアント上の現在のキャラクタの移動により生じる第１のクライアントとの移動の衝突を回避する。

【0047】

前述の実施例において行われたこの出願の説明から、第１のクライアントは、移動要求データパケットをサーバに送信し、サーバは、移動要求データパケットに従ってターゲットクライアントが第１のクライアントであるか第２のクライアントであるかを決定し、次に、サーバは、ターゲットクライアントの移動識別子を更新し、サーバは、ターゲットクライアントの更新された移動識別子を第１のクライアント及び第２のクライアントにブロードキャストすることが習得できる。ターゲットクライアントを決定した後に、サーバは、ターゲットクライアントの移動識別子を更新してブロードキャストしてもよく、第１のクライアント及び第２のクライアントの双方は、サーバのブロードキャストを用いてターゲットクライアントの移動識別子を取得できる。したがって、第１のクライアントは、サーバにより更新された移動識別子に従って、ターゲットクライアント上のキャラクタの移動を表示する必要があり、それにより、ターゲットクライアント上のキャラクタの移動は、ターゲットクライアントの移動識別子に対してサーバにより実行された更新に従って表示される。第１のクライアントは、サーバにより更新された移動識別子が取得された後にのみ、ターゲットクライアント上のキャラクタの移動を表示し、それにより、クライアント上のキャラクタの移動によって生じるジッタを低減し、それにより、ゲーム体験を改善する。

【0048】

前述の実施例では、サーバの角度から、この出願において提供されるゲーム内でキャラクタの移動を制御するための方法に対して詳細な説明が行われている。以下に、クライアント（例えば、第１のクライアント）の角度から、この出願において提供されるゲーム内でキャラクタの移動を制御するための方法を説明する。図２を参照すると、図２は、この出願の実施例に従ってゲーム内でキャラクタの移動を制御するための方法を示す。方法は以下のステップを含んでもよい。

【0049】

201：第１のクライアントは、移動要求データパケットをサーバに送信し、サーバは、移動要求データパケットに従ってターゲットクライアントが第１のクライアントであるか第２のクライアントであるかを決定し、ターゲットクライアント上のキャラクタは、移動が第１のクライアントにより制御される必要のあるキャラクタである。

【0050】

この出願の前述の実施例では、サーバが同じゲームシナリオにおいて２つのクライアント（すなわち、第１のクライアント及び第２のクライアント）を管理することが、例示的な説明の例として使用される。クライアントの角度から、詳細な説明が以下で行われるが、これは限定されるものではない。この出願のこの実施例では、サーバは、代替としてより多くのクライアントを管理してもよい。例えば、サーバは、同じゲームシナリオにある第１のクライアント、第２のクライアント及び第３のクライアントと通信接続してもよい。サーバが第２のクライアント及び第３のクライアント上のキャラクタの移動を制御する方式は、この出願のこの実施例における第１のクライアントとサーバとの間の相互作用プロセスと同様であり、この出願の後の実施例における複数の適用シナリオの説明に参照が行われてもよい。

【0051】

まず、移動が制御される必要のあるキャラクタを決定した後に、第１のクライアントは、移動要求データパケットを生成し、第１のクライアントとサーバとの間の通信接続を用いて移動要求データパケットを送信する。具体的には、第１のクライアントにより、移動要求データパケットをサーバに送信することは、以下のステップを含んでもよい。

【0052】

F1：第１のクライアントは、第１のクライアント上の現在のキャラクタの移動に対する制御を決定し、第１のクライアントの現在の移動識別子を搬送する移動要求データパケットをサーバに送信するか、或いは
F2：第１のクライアントは、同じゲームシナリオにおいて第２のクライアント上のキャラクタの移動に対する制御を決定し、制御要求を搬送する移動要求データパケットをサーバに送信する。

【0053】

この出願の前述の実施例のステップF1において、第１のクライアントが第１のクライアント上のキャラクタの移動動作を制御する必要がある場合、例えば、第１のクライアントが移動コンパスを用いて第１のクライアント上のキャラクタを前進させるように制御する場合、第１のクライアントは、第１のクライアントの現在の移動識別子が移動要求データパケット内で搬送されることを可能にしてもよい。ステップF2に示すシナリオにおいて、ステップF2とステップF1との違いは、第１のクライアントが第１のクライアント上のキャラクタの移動を制御でき、また、同じゲームシナリオにおいて他のクライアント上のキャラクタの移動も制御できる点である。例えば、第１のクライアント上のキャラクタは、攻撃を行う必要があり、攻撃された対象は、第２のクライアント上のキャラクタである。この場合、第１のクライアントの現在の制御動作は、第２のクライアントを制御することである。第１のクライアントにより送信された移動要求データパケットは、第２のクライアントを制御するための要求を搬送してもよい。

【0054】

この出願のいくつかの実施例では、ステップF1において、第１のクライアントにより、第１のクライアントの現在の移動識別子を搬送する移動要求データパケットをサーバに送信することは、具体的には以下の通りである。

【0055】

F11：第１のクライアントは、サーバにより送信されたターゲットクライアントの更新された移動識別子を受信する前に、第１のクライアントの現在の移動識別子を搬送する移動要求データパケットを複数回繰り返し送信する。

【0056】

サーバは、第１のクライアントにより送信された移動要求データパケットに応答してもよく、ターゲットクライアントの更新された移動識別子を第１のクライアントにブロードキャストしてもよい。ネットワーク遅延を考慮して、第１のクライアントは、第１のクライアントの現在の移動識別子を搬送する移動要求データパケットを複数回繰り返し送信してもよく、毎回送信される移動要求データパケットは、第１のクライアントの同じ現在の移動識別子を搬送する。第１のクライアントにより複数回繰り返し実行される送信について、サーバは、毎回送信に応答してもよく、毎回の第１のクライアントへの応答としての移動通知データパケットは、サーバにより更新された第１のクライアントの移動識別子を搬送し、それにより、第１のクライアントと同じゲームシナリオにおける第２のクライアントは、適時に第１のクライアントの最新の移動識別子を取得でき、第２のクライアントは、サーバにより送信された第１のクライアントの最新の移動識別子に従って、第１のクライアント上のキャラクタの移動を表示する。

【0057】

202：第１のクライアントは、サーバにより送信されたターゲットクライアントの更新された移動識別子を受信する。

【0058】

この出願のこの実施例では、サーバがターゲットクライアントの更新された移動識別子を生成した後に、サーバは、ターゲットクライアントの更新された移動識別子をブロードキャストし始める。第１のクライアントは、サーバとの通信接続を用いてターゲットクライアントの更新された移動識別子を受信する。

【0059】

203：第１のクライアントは、ターゲットクライアントの受信した更新された移動識別子に従って、ターゲットクライアント上のキャラクタの移動を表示する。

【0060】

この出願のこの実施例では、ターゲットクライアントの異なる実現方式について、第１のクライアントは、ターゲットクライアントの移動識別子に対してサーバにより実行された更新の状態に従って、ターゲットクライアント上のキャラクタの移動を表示してもよい。第１のクライアントがサーバによりブロードキャストされたターゲットクライアントの更新された移動識別子を受信しない場合、第１のクライアントは、ターゲットクライアント上のキャラクタの移動に応答しない。したがって、クライアント上のキャラクタの移動は、サーバが移動識別子を更新するか否かに依存し、それにより、各クライアントは、ターゲットクライアント上のキャラクタの移動を適切に表示し、それにより、既存技術において複数のクライアントの複数の入力が複数の出力を生成し且つ出力が相互に影響するときに生成されるジッタを低減し、キャラクタのゆがみ又は瞬時移動が複数のゲームクライアント上で発生することを回避し、クライアントに表示されるキャラクタのゆがみ又は瞬時移動を有効に軽減し、ユーザのゲーム体験を改善する。

【0061】

前述の実施例において行われたこの出願の説明から、第１のクライアントは、移動要求データパケットをサーバに送信し、サーバは、移動要求データパケットに従ってターゲットクライアントが第１のクライアントであるか第２のクライアントであるかを決定し、次に、サーバは、ターゲットクライアントの移動識別子を更新し、サーバは、ターゲットクライアントの更新された移動識別子を第１のクライアント及び第２のクライアントにブロードキャストすることが習得できる。ターゲットクライアントを決定した後に、サーバは、ターゲットクライアントの移動識別子を更新してブロードキャストしてもよく、第１のクライアント及び第２のクライアントの双方は、サーバのブロードキャストを用いてターゲットクライアントの移動識別子を取得できる。したがって、第１のクライアントは、サーバにより更新された移動識別子に従って、ターゲットクライアント上のキャラクタの移動を表示する必要があり、それにより、ターゲットクライアント上のキャラクタの移動は、ターゲットクライアントの移動識別子に対してサーバにより実行された更新に従って表示される。第１のクライアントは、サーバにより更新された移動識別子が取得された後にのみ、ターゲットクライアント上のキャラクタの移動を表示し、それにより、クライアント上のキャラクタの移動によって生じるジッタを低減し、それにより、ゲーム体験を改善する。

【0062】

この出願のこの実施例の前述の解決策のより良い理解及び実現のために、対応する適用シナリオを使用することにより、具体的な説明が以下で行われる。この出願のこの実施例は、移動識別子を更新することにより、現在のマルチプレイヤオンラインモバイルゲームにおける第三者の制御によって生じる移動の衝突を低減し、より良いゲーム体験を確保することを意図する。モバイルゲームにおけるMOBAゲームについて、移動表示が望ましく最適化される。移動識別子が具体的にシーケンス番号同期を用いて更新されることを例として使用することにより、例示的な説明が以下に行われる。キャラクタの移動は、シーケンス番号スライディングウィンドウを用いて制御される。図３ａを参照すると、図３ａは、この出願の実施例によるクライアントのシーケンス番号の間の同期の適用シナリオの概略図である。移動シーケンス番号の同期を例として使用することにより、説明が行われる。ここでは、シーケンス番号における異常のみを説明し、ネットワーク遅延のような状況は無視される。この実施例は、シーケンス番号の同期を説明することを意図しており、主に以下のステップを含む。

【0063】

サーバ及びクライアントのそれぞれは、シーケンス番号同期情報を保存し、サーバ内に設定された許容シーケンス番号閾値はN-1であることが仮定される。クライアントとサーバとの間のシーケンス番号の差がN未満である場合、移動要求データパケットが受け付けられ、サーバは、移動要求データパケットに応答する。

【0064】

クライアント1上のキャラクタが移動する必要がある場合、移動要求データパケットはサーバに送信される。移動シーケンス番号は0として初期化される。移動要求データパケット内で搬送される現在のシーケンス番号seqは0である。クライアント上の各移動操作は、シーケンス番号に対応する。移動要求データパケットを受信した後に、サーバは、移動されるべきキャラクタがクライアント1上のキャラクタであると決定する。サーバは、受信した移動要求データパケット内で搬送されるシーケンス番号と、ローカルシーケンス番号とを比較し、サーバとクライアントとの間のシーケンス番号の差が許容シーケンス番号閾値内であると検出される。サーバは、クライアント1の現在のシーケンス番号seqを1として更新し、次に、クライアントの移動パケットをブロードキャストする。v5vゲームを例として使用すると、サーバは、移動通知データパケットを１０個のクライアントにブロードキャストする必要がある。移動通知データパケット内で搬送されるシーケンス番号seqは1である。サーバは、移動通知データパケットをクライアント1にブロードキャストする。クライアント1は、受信した移動通知データパケットに従ってサーバがこの要求を承認したことを習得する。

【0065】

サーバにより送信された移動通知データパケットを受信する前に、クライアント1は、移動要求データパケットを複数回送信する。移動要求データパケット内で搬送される現在のシーケンス番号seqは0である。サーバは、クライアント1の各要求に対応する移動通知データパケットを返信する。移動通知データパケット内で搬送されるシーケンス番号は次第に増加する。N個のサイクルの後に、クライアント1がサーバにより送信された対応する移動通知データパケットをまだ受信しておらず、ローカルシーケンス番号を更新していないことが仮定され、クライアントは、ローカルシーケンス番号を保持し、シーケンス番号は、サーバが正確な応答を行う毎に更新される。クライアント1が第Nのデータパケットを送信したときに、更新されたシーケンス番号は依然として0である。この時点で、サーバは、サーバとクライアントとの間のシーケンス番号の差がNであることを検出し、これは、許容シーケンス番号ズレより大きい。したがって、サーバは、新たなシーケンス番号（seq=N+1）をクライアント1に通知し、サーバは、シーケンス番号をクライアント1に独立して送信する。クライアント1が新たなシーケンス番号に従って移動要求データパケットを送信した後に、サーバは、移動通知データパケットを再びブロードキャストする。

【0066】

図３ｂを参照すると、図３ｂは、この出願の実施例によるクライアントのシーケンス番号の同期の他の適用シナリオの概略図である。移動シーケンス番号の同期を例として使用することにより、説明が行われる。クライアント1がクライアント2上のキャラクタを一時停止（halt）させるように制御する適用シナリオを例として使用して、この実施例は以下のステップを主に含む。

【0067】

図３ｂにおいて、クライアント2上のキャラクタの移動は、シーケンス番号及び一意停止効果以外の他の効果により影響されないことが仮定される。一時停止は、ゲームにおいて或るプレイヤが他のプレイヤの移動を一時停止させることを意味する。まず、或る操作のため、クライアント1は、クライアント2上のキャラクタを一時停止させる必要がある。この場合、クライアント1は、一時停止要求をサーバに送信する。クライアント1により送信された一時停止要求を受信した後に、サーバは、状況環境をローカルで検査する。クライアント1がアイデンティティ認証を通過した後に、サーバは、ローカル同期リストからクライアント2の記録されたシーケンス番号Nを取得する。クライアントの記録されたシーケンス番号Nを2Nまで増加させた後に、サーバは、一時停止通知をクライアント1及びクライアント2にブロードキャストする。一時停止通知内で搬送される更新されたシーケンス番号seqは2Nである。新たなシーケンス番号は、クライアント1及びクライアント2で同期される。新たなシーケンス番号を受信する前に、クライアント2は、古いシーケンス番号をサーバに送信し続ける。この時点で、サーバは、シーケンス番号のズレがシーケンス番号許容閾値を既に超えていることを検出し、クライアント2の移動要求データパケットを直接フィルタ除去し、それにより、クライアント2上のキャラクタの移動が他のクライアント上で有効でないことを確保し、すなわち、クライアント1に表示されたクライアント2上のキャラクタは移動しない。例えば、クライアント1上のキャラクタがクライアント2上のキャラクタを一時停止させるように制御するためのスキルを使用した場合、サーバは、クライアント2の移動要求をフィルタ除去し、それにより、サーバがクライアント2の移動要求に応答しないため、クライアント2が移動できないことを確保する。図４及び図５を参照すると、図４は、この出願の実施例に従ってシーケンス番号が同期されないときのゲーム場面の概略図であり、図５は、この出願の実施例に従ってシーケンス番号が同期された後のゲーム場面の概略図である。図４に示すように、シーケンス番号の同期が実行されていない場合、Crystal Maidenが他のキャラクタを一時停止させるためのスキルを使用した場合、他のキャラクタは、或る距離だけ前進し続ける。すなわち、プレイヤがCrystal Maidenを制御したクライアントのスキルは、十分な表現力がない。図５に示すように、この出願のこの実施例において提供されるシーケンス番号の同期が実行された後に、キャラクタの移動及びスキルの演出は比較的望ましい。Crystal Maidenにより一時停止された後に、他のキャラクタの一時停止はより表現力がある。他のキャラクタのための移動要求データパケットは、サーバによりブロードキャストされないため、プレイヤがCrystal Maidenを制御したクライアントは、他のキャラクタが一時停止されることを示す。この出願において提供される前述の解決策を用いて、ネットワークの行き詰まり、第三者クライアント上の移動の遅延、及び第三者クライアント上のキャラクタのゆがみ又は瞬時移動が望ましく解決され、それにより、通常のネットワーク遅延が存在するときに、各クライアントにおけるプレイヤの望ましいゲーム体験が確保される。

【0068】

説明を容易にするために、前述の方法の実施例は一連の動作の組み合わせとして記載されている点に留意すべきである。しかし、この出願に従っていくつかのステップは他のシーケンスで実行されてもよく或いは同時に実行されてもよいため、当業者は、この出願が記載の動作のシーケンスに限定されないことを理解するべきである。さらに、当業者はまた、この明細書に記載の全ての実施例は好ましい実施例であり、関係する動作及びモジュールがこの出願において必ずしも必要であるとは限らないことも認識すべきである。

【0069】

この出願の実施例における前述の解決策をより良く実現するために、以下に、前述の解決策を実現するように構成された関係する装置を更に提供する。

【0070】

図６ａを参照すると、この出願の実施例において提供されるサーバ600は、受信モジュール601と、ターゲットクライアント決定モジュール602と、移動識別子処理モジュール603とを含んでもよい。

【0071】

受信モジュール601は、第１のクライアントにより送信された移動要求データパケットを受信するように構成され、サーバは、同じゲームシナリオにおいて第１のクライアント上のキャラクタの移動及び第２のクライアント上のキャラクタの移動を管理するように構成される。

【0072】

ターゲットクライアント決定モジュール602は、移動要求データパケットに従ってターゲットクライアントが第１のクライアントであるか第２のクライアントであるかを決定するように構成され、ターゲットクライアント上のキャラクタは、移動が第１のクライアントにより制御される必要のあるキャラクタである。

【0073】

移動識別子処理モジュール603は、ターゲットクライアントの移動識別子を更新するように構成され、次に、サーバがターゲットクライアントの更新された移動識別子を第１のクライアント及び第２のクライアントにブロードキャストする。

【0074】

この出願のいくつかの実施例では、ターゲットクライアント決定モジュール602は、第１のクライアントが第１のクライアント上の現在のキャラクタの移動を制御するときに、移動要求データパケットが第１のクライアントの現在の移動識別子を搬送する場合、ターゲットクライアントが第１のクライアントであると決定するか、或いは移動要求データパケットが、第１のクライアントにより第２のクライアント上のキャラクタの移動を制御するための要求を搬送する場合、ターゲットクライアントが第２のクライアントであると決定するように具体的に構成される。

【0075】

この出願のいくつかの実施例では、図６ｂを参照すると、サーバ600は、第１の移動決定モジュール604を更に含む。

【0076】

第１の移動決定モジュール604は、ターゲットクライアント決定モジュール602が、移動要求データパケットに従ってターゲットクライアントが第１のクライアントであるか第２のクライアントであるかを決定した後に、ターゲットクライアントが第１のクライアントであるときに、第１のクライアントの現在の移動識別子に従って、第１のクライアント上の現在のキャラクタの移動がサーバ内に設定されたズレ許容条件を満たすか否かを決定するように構成される。

【0077】

移動識別子処理モジュール603は、第１のクライアント上の現在の移動がズレ許容条件を満たさない場合、第１のクライアントの現在の移動識別子を更新し、移動拒否命令を第１のクライアントに送信するように更に構成され、移動拒否命令は、第１のクライアントの更新された移動識別子を搬送する。

【0078】

この出願のいくつかの実施例では、図６ｃを参照すると、移動識別子処理モジュール603は、
ターゲットクライアントが第２のクライアントであるときに、サーバのローカル同期リストから第２のクライアントの記録された移動識別子を取得するように構成された移動識別子読み取りモジュール6031と、
サーバ内に設定されたズレ許容条件に従って、第２のクライアントの記録された移動識別子を更新し、第２のクライアントの更新された移動識別子を保存するように構成された移動識別子更新モジュール6032と
を含む。

【0079】

この出願のいくつかの実施例では、図６ｄを参照すると、図６ａと比べて、サーバ600は、第２の移動決定モジュール605と、データパケットフィルタ除去モジュール606とを更に含む。

【0080】

受信モジュール601は、移動識別子処理モジュール603がターゲットクライアントの更新された移動識別子を第１のクライアント及び第２のクライアントにブロードキャストした後に、第２のクライアントにより送信された移動要求データパケットを受信するように更に構成され、第２のクライアントにより送信された移動要求データパケットは、第２のクライアントが第２のクライアント上の現在のキャラクタの移動を制御するときに、第２のクライアントの現在の移動識別子を搬送する。

【0081】

第２の移動決定モジュール605は、第２のクライアントの現在の移動識別子に従って、第２のクライアント上の現在のキャラクタの移動がサーバ内に設定されたズレ許容条件を満たすか否かを決定するように構成される。

【0082】

データパケットフィルタ除去モジュール606は、第２のクライアント上の現在のキャラクタの移動がズレ許容条件を満たさない場合、第２のクライアントにより送信された移動要求データパケットをフィルタ除去し、移動拒否命令を第２のクライアントに送信するように構成される。

【0083】

前述の実施例において行われたこの出願の説明から、第１のクライアントは、移動要求データパケットをサーバに送信し、サーバは、移動要求データパケットに従って、キャラクタの移動が第１のクライアントにより制御される必要のあるターゲットクライアントが第１のクライアントであるか第２のクライアントであるかを決定し、次に、サーバは、ターゲットクライアントの移動識別子を更新し、サーバは、ターゲットクライアントの更新された移動識別子を第１のクライアント及び第２のクライアントにブロードキャストすることが習得できる。ターゲットクライアントを決定した後に、サーバは、ターゲットクライアントの移動識別子を更新してブロードキャストしてもよく、第１のクライアント及び第２のクライアントの双方は、サーバのブロードキャストを用いてターゲットクライアントの移動識別子を取得できる。したがって、第１のクライアントは、サーバにより更新された移動識別子に従って、ターゲットクライアント上のキャラクタの移動を表示する必要があり、それにより、ターゲットクライアント上のキャラクタの移動は、ターゲットクライアントの移動識別子に対してサーバにより実行された更新に従って表示される。第１のクライアントは、サーバにより更新された移動識別子が取得された後にのみ、ターゲットクライアント上のキャラクタの移動を表示し、それにより、クライアント上のキャラクタの移動によって生じるジッタを低減し、それにより、ゲーム体験を改善する。

【0084】

図７ａを参照すると、この出願の実施例は、クライアント700を提供する。クライアント700は、具体的には第１のクライアントである。第１のクライアント及び第２のクライアントは同じゲームシナリオにある。第１のクライアントは、送信モジュール701と、受信モジュール702と、表示モジュール703とを含む。

【0085】

送信モジュール701は、移動要求データパケットをサーバに送信するように構成され、サーバは、移動要求データパケットに従ってターゲットクライアントが第１のクライアントであるか第２のクライアントであるかを決定し、ターゲットクライアント上のキャラクタは、移動が第１のクライアントにより制御される必要のあるキャラクタである。

【0086】

受信モジュール702は、サーバにより送信されたターゲットクライアントの更新された移動識別子を受信するように構成される。

【0087】

表示モジュール703は、ターゲットクライアントの受信した更新された移動識別子に従って、ターゲットクライアント上のキャラクタの移動を表示するように構成される。

【0088】

この出願のいくつかの実施例では、送信モジュール701は、第１のクライアントが第１のクライアント上の現在のキャラクタの移動に対する制御を決定したときに、第１のクライアントの現在の移動識別子を搬送する移動要求データパケットをサーバに送信するか、或いは第１のクライアントが同じゲームシナリオにおいて第２のクライアント上のキャラクタの移動に対する制御を決定したときに、制御要求を搬送する移動要求データパケットをサーバに送信するように具体的に構成される。

【0089】

この出願のいくつかの実施例では、送信モジュール701は、サーバにより送信されたターゲットクライアントの更新された移動識別子を受信する前に、第１のクライアントの現在の移動識別子を搬送する移動要求データパケットを複数回繰り返し送信するように具体的に構成される。

【0090】

前述の実施例において行われたこの出願の説明から、第１のクライアントは、移動要求データパケットをサーバに送信し、サーバは、移動要求データパケットに従ってターゲットクライアントが第１のクライアントであるか第２のクライアントであるかを決定し、次に、サーバは、ターゲットクライアントの移動識別子を更新し、サーバは、ターゲットクライアントの更新された移動識別子を第１のクライアント及び第２のクライアントにブロードキャストすることが習得できる。ターゲットクライアントを決定した後に、サーバは、ターゲットクライアントの移動識別子を更新してブロードキャストしてもよく、第１のクライアント及び第２のクライアントの双方は、サーバのブロードキャストを用いてターゲットクライアントの移動識別子を取得できる。したがって、第１のクライアントは、サーバにより更新された移動識別子に従って、ターゲットクライアント上のキャラクタの移動を表示する必要があり、それにより、ターゲットクライアント上のキャラクタの移動は、ターゲットクライアントの移動識別子に対してサーバにより実行された更新に従って表示される。第１のクライアントは、サーバにより更新された移動識別子が取得された後にのみ、ターゲットクライアント上のキャラクタの移動を表示し、それにより、クライアント上のキャラクタの移動によって生じるジッタを低減し、それにより、ゲーム体験を改善する。

【0091】

図８は、この出願の実施例によるサーバの概略構成図である。サーバは、異なる構成又は性能のため大きく変化してもよく、１つ以上の中央処理装置（central processing unit, CPU）822（例えば、１つ以上のプロセッサ）と、メモリ832と、アプリケーションプログラム842又はデータ844を記憶する１つ以上の記憶媒体830（例えば、１つ以上の大容量記憶デバイス）とを含んでもよい。メモリ832及び記憶媒体830は、一時的又は永続的な記憶装置でもよい。記憶媒体830に記憶されたプログラムは、１つ以上のモジュール（図面に図示せず）を含んでもよく、各モジュールは、サーバのための一連の命令及び操作を含んでもよい。さらに、CPU822は、記憶媒体830と通信し、サーバ800上で記憶媒体830内の一連の命令及び操作を実行するように構成されてもよい。

【0092】

サーバ800は、１つ以上の電源826、１つ以上の有線若しくは無線ネットワークインタフェース850、１つ以上の出力／入力インタフェース858、及び／又は１つ以上のオペレーティングシステム841、例えば、Windows Server（登録商標）、Mac OS X（登録商標）、Unix（登録商標）、Linux（登録商標）若しくはFreeBSD（登録商標）を更に含んでもよい。

【0093】

前述の実施例において、サーバにより実行される、ゲーム内でキャラクタの移動を制御するための方法のステップは、図８に示すサーバ構成に基づいてもよい。

【0094】

この出願の実施例は、図９に示すような端末を更に提供し、説明の便宜上のため、この出願のこの実施例に関係する部分のみが示されている。開示されていない具体的な技術的詳細については、この出願の実施例の方法の部分を参照する。端末は、移動電話、タブレットコンピュータ、パーソナルデジタルアシスタント（personal digital assistant, PDA）、販売時点情報管理（point of sales, POS）及び車載コンピュータのようないずれかの端末デバイスでもよい。端末が移動電話であることが例として使用される。

【0095】

図９は、この出願の実施例による端末に関する移動電話の一部の構成のブロック図である。図９を参照すると、移動電話は、無線周波数（radio frequency, RF）回路99、メモリ920、入力ユニット930、表示ユニット940、センサ950、オーディオ回路960、ワイヤレスフィデリティ（wireless fidelity, WiFi）モジュール970、プロセッサ980及び電源990のようなコンポーネントを含む。当業者は、図９に示す移動電話の構成が移動電話への限定を構成せず、移動電話は図面に示すものより多くのコンポーネント又は少ないコンポーネントを含んでもよく、或いはいくつかのコンポーネントが組み合わされてもよく、或いは異なるコンポーネントの配置が使用されてもよいことを理解し得る。

【0096】

以下に、図９を参照して移動電話のコンポーネントを具体的に説明する。

【0097】

RF回路99は、情報受信及び送信プロセス又は呼プロセスの間に信号を受信及び送信するように構成されてもよい。具体的には、RF回路は、基地局から下りリンク情報を受信し、次に処理のために下りリンク情報をプロセッサ980に送信し、関係する上りリンクデータを基地局に送信する。一般的に、RF回路99は、アンテナ、少なくとも１つの増幅器、トランシーバ、カプラ、低雑音増幅器（low noise amplifier, LNA）及びデュプレクサを含むが、これらに限定されない。さらに、RF回路99はまた、無線通信を用いてネットワーク及び他のデバイスと通信してもよい。無線通信は、いずれかの通信標準又はプロトコルを使用してもよく、これは、グローバル・システム・フォー・モバイル・コミュニケーションズ（Global System for Mobile communications, GSM）、汎用パケット無線サービス（General Packet Radio Service, GPRS）、符号分割多元アクセス（Code Division Multiple Access, CDMA）、広帯域符号分割多元アクセス（Wideband Code Division Multiple Access, WCDMA）、ロングタームエボリューション（Long Term Evolution, LTE）、電子メール、ショートメッセージサービス（Short Messaging Service, SMS）等を含むが、これらに限定されない。

【0098】

メモリ920は、ソフトウェアプログラム及びモジュールを記憶するように構成されてもよい。プロセッサ980は、移動電話の様々な機能アプリケーション及びデータ処理を実現するために、メモリ920に記憶されたソフトウェアプログラム及びモジュールを実行する。メモリ920は、プログラム記憶エリア及びデータ記憶エリアを主に含んでもよい。プログラム記憶エリアは、オペレーティングシステム、少なくとも１つの機能（音声再生機能及び画像表示機能等）により要求されるアプリケーションプログラム等を記憶してもよい。データ記憶エリアは、移動電話の使用に従って生成されたデータ（オーディオデータ及びアドレス帳等）等を記憶してもよい。さらに、メモリ920は、高速ランダムアクセスメモリを含んでもよく、また、少なくとも１つの磁気ディスク記憶デバイス、フラッシュメモリのような不揮発性メモリ、又は他の揮発性ソリッドステート記憶デバイスを含んでもよい。

【0099】

入力ユニット930は、入力された数字又は文字情報を受信し、移動電話のユーザ設定及び機能制御に関するキー信号入力を生成するように構成されてもよい。具体的には、入力ユニット930は、タッチパネル931及び他の入力デバイス932を含んでもよい。タッチパネル931は、タッチスクリーンとも呼ばれてもよく、タッチパネル上又はタッチパネル近くのユーザのタッチ操作（指又はタッチペンのようないずれか適切な物又はアタッチメントを使用することによるタッチパネル931上又はタッチパネル931近くのユーザの操作等）を収集し、予め設定されたプログラムに従って対応する接続装置を駆動してもよい。任意選択で、タッチパネル931は、２つの部分、すなわち、タッチ検出装置及びタッチコントローラを含んでもよい。タッチ検出装置は、ユーザのタッチ位置を検出し、タッチ操作により生成された信号を検出し、信号をタッチコントローラに転送する。タッチコントローラは、タッチ検出装置からタッチ情報を受信し、タッチ情報をタッチ点座標に変換し、タッチ点座標をプロセッサ980に送信する。さらに、タッチコントローラは、プロセッサ980から送信されたコマンドを受信して実行できる。さらに、タッチパネル931は、抵抗性、容量性、赤外線又は面音波のタイプのタッチパネルでもよい。タッチパネル931に加えて、入力ユニット930は、他の入力デバイス932を更に含んでもよい。具体的には、他の入力デバイス932は、物理キーボード、機能キー（例えば、音量制御キー又は切り替えキー）、トラックボール、マウス及びジョイスティックのうち１つ以上を含んでもよいが、これらに限定されない。

【0100】

表示ユニット940は、ユーザにより入力された情報又はユーザに提供される情報と、移動電話の様々なメニューとを表示するように構成されてもよい。表示ユニット940は、表示パネル941を含んでもよい。任意選択で、表示パネル941は、液晶ディスプレイ（liquid crystal display, LCD）、有機発光ダイオード（organic light-emitting diode, OLED）等を使用することにより構成されてもよい。さらに、タッチパネル931は、表示パネル941をカバーしてもよい。タッチパネル931上又はタッチパネル931近くのタッチ操作を検出した後に、タッチパネル931は、タッチ操作をプロセッサ980に転送し、それにより、タッチイベントのタイプを決定する。次に、プロセッサ980は、タッチイベントのタイプに従って、表示パネル941上に対応する視覚出力を提供する。図９では、タッチパネル931及び表示パネル941は、移動電話の入力及び出力機能を実現するための２つの別々の部分として使用されているが、いくつかの実施例では、タッチパネル931及び表示パネル941は、移動電話の入力及び出力機能を実現するために統合されてもよい。

【0101】

移動電話は、光センサ、動きセンサ及び他のセンサのような少なくとも１つのセンサ950を更に含んでもよい。具体的には、光センサは、周辺光センサと近接センサとを含んでもよい。周辺光センサは、周辺光の明るさに基づいて表示パネル941の輝度を調整してもよい。移動電話が耳の近くに移動したときに、近接センサは、表示パネル941及び／又はバックライトをオフにしてもよい。１つの種類の動きセンサとして、加速度センサは、様々な方向（一般的には３つの軸）における加速度の大きさを検出し、静止しているときに重力の大きさ及び方向を検出してもよく、移動電話の姿勢を認識するアプリケーション（例えば、横方向と縦方向との間の切り替え、関係するゲーム及び磁力計姿勢較正）、振動の認識に関する機能（歩数計及び打楽器等）等に適用されてもよい。ジャイロスコープ、気圧計、湿度計、温度計及び赤外線センサのような移動電話内に構成されてもよい他のセンサについて、ここでは更に説明しない。

【0102】

オーディオ回路960、スピーカ961及びマイクロフォン962は、ユーザと移動電話との間のオーディオインタフェースを提供してもよい。オーディオ回路960は、受信したオーディオデータを電気信号に変換し、電気信号をスピーカ961に送信してもよい。スピーカ961は、出力のために電気信号を音信号に変換する。他方、マイクロフォン962は、収集された音信号を電気信号に変換する。オーディオ回路960は、電気信号を受信し、電気信号をオーディオデータに変換し、処理のためにオーディオデータをプロセッサ980に出力する。次に、プロセッサ980は、RF回路99を使用することによりオーディオデータを、例えば他の移動電話に送信するか、或いは更なる処理のためにオーディオデータをメモリ920に出力する。

【0103】

WiFiは、短距離無線送信技術である。移動電話は、WiFiモジュール970を使用することにより、ユーザが電子メールを受信及び送信すること、ウェブページをブラウズすること、ストリーミングメディアにアクセスすること等を支援してもよく、これは、ユーザのための無線ブロードバンドインターネットアクセスを提供する。図９は、WiFiモジュール970を示しているが、WiFiモジュール970は、移動電話の必要なコンポーネントではなく、必要に応じて、WiFiモジュール970は、本開示の本質の範囲が変更されない限り省略されてもよいことが理解され得る。

【0104】

プロセッサ980は、移動電話の制御センタであり、様々なインタフェース及びラインを使用することにより移動電話の様々な部分に接続される。メモリ920に記憶されたソフトウェアプログラム及び／又はモジュールを実行又は動作し、メモリ920に記憶されたデータを呼び出すことにより、プロセッサ980は、移動電話の様々な機能及びデータ処理を実行し、それにより、移動電話の全体の監視を実行する。任意選択で、プロセッサ980は、１つ以上の処理ユニットを含んでもよい。好ましくは、プロセッサ980は、アプリケーションプロセッサ及びモデムプロセッサを統合してもよい。アプリケーションプロセッサは、主にオペレーティングシステム、ユーザインタフェース、アプリケーション等を処理する。モデムプロセッサは、主に無線通信を処理する。前述のモデムプロセッサは、プロセッサ980に統合されなくてもよいことが理解され得る。

【0105】

移動電話は、コンポーネントへの電力を提供する電源990（バッテリ等）を更に含む。好ましくは、電源は、電源管理システムを使用することにより論理的にプロセッサ980に接続されてもよく、それにより、電源管理システムを使用することにより、充電、放電及び電力消費管理のような機能を実現する。

【0106】

図示しないが、移動電話は、カメラ、ブルートゥースモジュール等を更に含んでもよく、これは、ここでは更に説明しない。

【0107】

この出願のこの実施例では、端末に含まれるプロセッサ980は、端末により実行される、ゲーム内でキャラクタの移動を制御するための方法の前述の手順の実行を制御する機能を更に有する。

【0108】

記載の装置の実施例は単なる例示である点に更に留意すべきである。別々の部分として記載したユニットは、物理的に分離されてもよく或いは分離されなくてもよく、ユニットとして表示される部分は、物理的なユニットでもよく或いは物理的なユニットでなくてもよく、１つの場所に位置してもよく、或いは複数のネットワークユニットに分散されてもよい。モジュールの一部又は全部は、実施例の解決策の目的を達成するために、実際のニーズに従って選択されてもよい。さらに、この出願により提供される装置の実施例の添付図面において、モジュールの間の接続関係は、モジュールが互いに通信接続を有することを示し、これは、具体的には１つ以上の通信バス又は信号ケーブルとして実現されてもよい。当業者は、創造的取り組みなしにこの出願の実施例を理解して実現し得る。

【0109】

実施例の前述の説明に基づいて、当業者は、この出願が必要なユニバーサルハードウェアに加えてソフトウェアにより実現されてもよく、或いは専用集積回路、専用CPU、専用メモリ、専用コンポーネント等を含む専用ハードウェアのみにより実現されてもよいことを明確に理解し得る。一般的に、コンピュータプログラムにより実行可能な如何なる機能も、対応するハードウェアを使用することにより容易に実現可能である。さらに、同じ機能を達成するために使用される具体的なハードウェア構成は様々な形式、例えば、アナログ回路、デジタル回路、専用回路等の形式になってもよい。さらに、この出願について、ソフトウェアプログラムの実現がほとんどの場合により良い実現方式である。このことに基づいて、この出願の技術的解決策又は既存技術に貢献する部分は、ソフトウェアプロダクトの形式で実質的に具現できる。コンピュータソフトウェアプロダクトは、読み取り可能記憶媒体、例えば、コンピュータのフロッピーディスク、USBフラッシュドライブ、取り外し可能ハードディスク、読み取り専用メモリ（read-only memory, ROM）、ランダムアクセスメモリ（random access memory, RAM）、磁気ディスク又は光ディスクに記憶され、コンピュータデバイス（例えば、パーソナルコンピュータ、サーバ又はネットワークデバイス）に対してこの出願の実施例による方法を実行するように命令するために使用されるいくつかの命令を含む。

【0110】

結論として、前述の実施例は、単にこの出願の技術的解決策を説明することを意図するものであり、本発明を限定するためのものではない。この出願について前述の実施例を参照して詳細に説明したが、当業者は、この出願の実施例の技術的解決策の真意及び範囲を逸脱することなく、依然として前述の実施例に記載の技術的解決策に変更を行ってもよく、或いはそのいくつかの技術的特徴に等価置換を行ってもよいことを理解するべきである。

【図1】

【図2】

【図3a】

【図3b】

【図4】

【図5】

【図6a】

【図6b】

【図6c】

【図6d】

【図7】

【図8】

【図9】