特表 2024-546606 仮想シーンのデータ処理方法およびその装置、電子機器、並びにコンピュータプログラム

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-12-26

(54)【発明の名称】仮想シーンのデータ処理方法およびその装置、電子機器、並びにコンピュータプログラム

(51)【国際特許分類】

   A63F 13/358 20140101AFI20241219BHJP

   A63F 13/355 20140101ALI20241219BHJP

   A63F 13/52 20140101ALI20241219BHJP

   A63F 13/77 20140101ALI20241219BHJP

【ＦＩ】

A63F13/358

A63F13/355

A63F13/52

A63F13/77

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024531229

(86)(22)【出願日】2022-11-17

(85)【翻訳文提出日】2024-06-06

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

(87)【国際公開番号】W WO2023155513

(87)【国際公開日】2023-08-24

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

(32)【優先日】2022-02-18

(33)【優先権主張国・地域又は機関】CN

(81)【指定国・地域】

(71)【出願人】

【識別番号】517392436

【氏名又は名称】▲騰▼▲訊▼科技（深▲セン▼）有限公司

【氏名又は名称原語表記】ＴＥＮＣＥＮＴ ＴＥＣＨＮＯＬＯＧＹ （ＳＨＥＮＺＨＥＮ） ＣＯＭＰＡＮＹ ＬＩＭＩＴＥＤ

【住所又は居所原語表記】３５／Ｆ，Ｔｅｎｃｅｎｔ Ｂｕｉｌｄｉｎｇ，Ｋｅｊｉｚｈｏｎｇｙｉ Ｒｏａｄ，Ｍｉｄｗｅｓｔ Ｄｉｓｔｒｉｃｔ ｏｆ Ｈｉ－ｔｅｃｈ Ｐａｒｋ，Ｎａｎｓｈａｎ Ｄｉｓｔｒｉｃｔ， Ｓｈｅｎｚｈｅｎ，Ｇｕａｎｇｄｏｎｇ ５１８０５７，ＣＨＩＮＡ

(74)【代理人】

【識別番号】100107766

【弁理士】

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

(74)【代理人】

【識別番号】100229448

【弁理士】

【氏名又は名称】中槇 利明

(72)【発明者】

【氏名】▲張▼嘉明

(72)【発明者】

【氏名】王▲亜▼昌

(57)【要約】

本願は、クラウド分野のゲーム技術に関する、仮想シーンのデータ処理方法およびその装置、電子機器、コンピュータ可読記憶媒体、並びにコンピュータプログラム製品を提供し、前記方法は、複数のクライアントを複数のシングルラウンド対局にアクセスさせるステップと、静的リソースに対応する静的リソースマスクを複数のクライアントにそれぞれ割り当てるステップであって、複数のクライアントにそれぞれ割り当てられた静的リソースマスクは同じである、ステップと、動的リソースに対応する動的リソースマスクを複数のクライアントにそれぞれ割り当てるステップと、静的リソースに対応する静的リソースマスクを複数のクライアントにそれぞれ割り当てることに応答して、複数のシングルラウンド対局間で静的リソースを共有するステップと、動的リソースに対応する動的リソースマスクを複数のクライアントにそれぞれ割り当てることに応答して、異なるシングルラウンド対局間で動的リソースを分離するステップと、を含む。
【選択図】図３Ａ

【特許請求の範囲】

【請求項1】

サーバによって実行される、仮想シーンのデータ処理方法であって、
複数のクライアントを複数のシングルラウンド対局にアクセスさせるステップであって、前記複数のシングルラウンド対局は、サービスプロセスを共有し、前記サービスプロセスは、前記仮想シーンの静的リソースと動的リソースを含む、ステップと、
前記静的リソースに対応する静的リソースマスクを前記複数のクライアントにそれぞれ割り当てるステップであって、前記複数のクライアントにそれぞれ割り当てられた前記静的リソースマスクは同じである、ステップと、
前記動的リソースに対応する動的リソースマスクを前記複数のクライアントにそれぞれ割り当てるステップであって、同じ前記シングルラウンド対局にアクセスする前記クライアントに割り当てられた前記動的リソースマスクは同じであり、異なる前記シングルラウンド対局にアクセスする前記クライアントに割り当てられた前記動的リソースマスクは異なる、ステップと、
前記静的リソースに対応する静的リソースマスクを前記複数のクライアントにそれぞれ割り当てることに基づいて、前記複数のシングルラウンド対局間で前記静的リソースを共有するステップと、
前記動的リソースに対応する動的リソースマスクを前記複数のクライアントにそれぞれ割り当てることに基づいて、異なる前記シングルラウンド対局間で前記動的リソースを分離するステップと、
を含む、
仮想シーンのデータ処理方法。

【請求項2】

前記複数のクライアントを複数のシングルラウンド対局にアクセスさせるステップは、
複数のクライアントが前記サービスプロセスに接続されることに応答して、複数のシングルラウンド対局を実行し、前記複数のクライアントに対局開始命令を送信するステップを含み、前記対局開始命令は、前記複数のクライアントが前記複数のシングルラウンド対局に接続するために使用され、
各前記クライアントは、１つの前記シングルラウンド対局に接続され、各前記シングルラウンド対局へのアクセスの数は、対局開始閾値以上であり且つ対局閉鎖閾値以下である、
請求項１に記載の仮想シーンのデータ処理方法。

【請求項3】

前記複数のクライアントが前記サービスプロセスに接続されることに応答して、複数のシングルラウンド対局を実行し、前記複数のクライアントに対局開始命令を送信するステップは、
複数のクライアントが前記サービスプロセスに接続され、且つ前記複数のクライアントの数量が前記対局開始閾値以上であることに応答して、１番目のシングルラウンド対局を実行し始め、第１数量のクライアントに対局開始命令を送信するステップであって、前記対局開始命令は、前記第１数量のクライアントが前記１番目のシングルラウンド対局にアクセスするために使用される、ステップと、
ｔを漸増させて逐次代入することによって、以下の処理を実行するステップと、を含み、
ここで、１≦ｔ≦Ｔであり、Ｔは、前記サービスプロセスが実行できる前記シングルラウンド対局の数量の上限であり、前記処理は、
ｔ番目の前記シングルラウンド対局にアクセスした前記クライアントの数量が対局閉鎖閾値と等しく、且つ１番目からｔ番目の前記シングルラウンド対局にアクセスしていない前記クライアントの数量が前記対局開始閾値以上であることに応答して、ｔ＋１番目のシングルラウンド対局を実行し始め、１番目からｔ番目の前記シングルラウンド対局にアクセスしていない前記クライアントの少なくとも一部を前記ｔ＋１番目のシングルラウンド対局にアクセスさせるステップと、を含む、
請求項２に記載の仮想シーンのデータ処理方法。

【請求項4】

前記静的リソースに対応する静的リソースマスクを前記複数のクライアントにそれぞれ割り当てるステップは、
０値の静的リソースマスクを前記複数のクライアントにそれぞれ割り当てるステップを含み、
前記動的リソースに対応する動的リソースマスクを前記複数のクライアントにそれぞれ割り当てるステップは、
ｍを漸増させて逐次代入することによって、以下の処理を実行するステップと、を含み、
ｍの範囲は、１≦ｍ≦Ｍであり、Ｍは、前記サービスプロセスが実行できる前記シングルラウンド対局の数量の上限であり、前記処理は、
ｍ値の動的リソースマスクをｍ番目の前記シングルラウンド対局にアクセスしたクライアントに割り当てるステップを含む、
請求項１に記載の仮想シーンのデータ処理方法。

【請求項5】

前記分離は、視野的分離を含み、
前記動的リソースに対応する動的リソースマスクを複数のクライアントにそれぞれ割り当てることに基づいて、異なる前記シングルラウンド対局間で前記動的リソースを分離するステップは、
前記複数のクライアントのうちの第１クライアントから送信された動的リソース更新要求を受信するステップであって、前記動的リソース更新要求は、前記動的リソースに対する前記第１クライアントの操作情報と、前記第１クライアントに割り当てられた動的リソースマスクを搬送する、ステップと、
前記操作情報に基づいて前記動的リソースを更新し、更新後の動的リソースを取得するステップと、
前記第１クライアントに割り当てられた動的リソースマスクに基づいて、前記第１クライアントと同じ前記シングルラウンド対局にアクセスし且つ同じ視野範囲を持つ少なくとも１つの第２クライアントを決定するステップと、
前記第１クライアントおよび前記少なくとも１つの第２クライアントに前記更新後の動的リソースを送信するステップと、を含む、
請求項１に記載の仮想シーンのデータ処理方法。

【請求項6】

前記仮想シーンが前記複数のクライアントに一度に完全に表示できる場合、前記第１クライアントに割り当てられた動的リソースマスクに基づいて、前記第１クライアントと同じ前記シングルラウンド対局にアクセスし且つ同じ視野範囲を持つ少なくとも１つの第２クライアントを決定するステップは、
前記第１クライアントに割り当てられた動的リソースマスクに基づいて、前記複数のクライアントから、前記第１クライアントと同じ前記動的リソースマスクが割り当られた少なくとも１つのクライアントを前記第２クライアントとして照会するステップを含む、
請求項５に記載の仮想シーンのデータ処理方法。

【請求項7】

前記仮想シーンの一部が前記複数のクライアントに一度に表示される場合、前記第１クライアントに割り当てられた動的リソースマスクに基づいて、前記第１クライアントと同じ前記シングルラウンド対局にアクセスし且つ同じ視野範囲を持つ少なくとも１つの第２クライアントを決定するステップは、
前記第１クライアントに割り当てられた動的リソースマスクに基づいて、前記複数のクライアントから、前記第１クライアントと同じ前記動的リソースマスクが割り当られた少なくとも１つのクライアントを照会するステップと、
前記第１クライアントに現在表示されている動的リソースと、前記少なくとも１つのクライアントのそれぞれに対応する動的リソースとの間の仮想シーンにおける距離を決定するステップと、
前記距離が視野距離閾値より小さい少なくとも１つのクライアントを前記第２クライアントとするステップと、を含む、
請求項５に記載の仮想シーンのデータ処理方法。

【請求項8】

当該仮想シーンのデータ処理方法は、
前記複数のクライアントのうち、前記第１クライアントと同じ前記シングルラウンド対局にアクセスする前記第２クライアントが存在しない場合、前記第１クライアントに前記更新後の動的リソースを送信するステップと、
前記複数のクライアントのうち、前記第１クライアントと同じ前記シングルラウンド対局にアクセスする少なくとも１つのクライアントが存在し、且つ前記少なくとも１つのクライアントと前記第１クライアントの前記視野範囲が異なる場合、前記第１クライアントに前記更新後の動的リソースを送信するステップと、をさらに含む、
請求項５に記載の仮想シーンのデータ処理方法。

【請求項9】

前記分離は、物理的分離を含み、
前記動的リソースに対応する動的リソースマスクを前記複数のクライアントにそれぞれ割り当てることに基づいて、異なる前記シングルラウンド対局間で前記動的リソースを分離するステップは、
第１クライアントの視野範囲内の前記動的リソースの前記仮想シーンにおける位置が、第２クライアントの視野範囲内の前記動的リソースの前記仮想シーンにおける位置と重なる場合、前記第１クライアントと前記第２クライアントにそれぞれ割り当てられた前記動的リソースマスクに基づいて、前記第１クライアントと前記第２クライアントがアクセスしたシングルラウンド対局間の関係を決定するステップであって、
前記第１クライアントと前記第２クライアントは、前記複数のクライアントのうちのいずれか２つである、ステップと、
前記関係が、前記第１クライアントと前記第２クライアントがアクセスした前記シングルラウンド対局が互いに異なる前記シングルラウンド対局であることを示す場合、前記第１クライアントと前記第２クライアントのそれぞれに対応する前記動的リソースに対して物理的分離を実行するステップと、を含み、
前記物理的分離は、前記第１クライアントの視野範囲内の前記動的リソースと、前記第２クライアントの視野範囲内の前記動的リソースに対して、同じ横軸座標、縦軸座標および垂直軸座標を割り当てるために使用される、
請求項１に記載の仮想シーンのデータ処理方法。

【請求項10】

当該仮想シーンのデータ処理方法は、
前記第１クライアントに対応する物理的分離された動的リソースを前記第１クライアントに送信するステップと、
前記第２クライアントに対応する物理的分離された動的リソースを前記第２クライアントに送信するステップと、をさらに含む、
請求項９に記載の仮想シーンのデータ処理方法。

【請求項11】

前記第１クライアントと前記第２クライアントにそれぞれ割り当てられた前記動的リソースマスクに基づいて、前記第１クライアントと前記第２クライアントがアクセスしたシングルラウンド対局間の関係を決定するステップは、
前記第１クライアントと前記第２クライアントにそれぞれ割り当てられた前記動的リソースマスクが同じである場合、前記第１クライアントと前記第２クライアントが同じ前記シングルラウンド対局にアクセスしたと決定するステップと、
前記第１クライアントと前記第２クライアントにそれぞれ割り当てられた前記動的リソースマスクが異なる場合、前記第１クライアントと前記第２クライアントが異なる前記シングルラウンド対局にアクセスしたと決定するステップと、を含む、
請求項９に記載の仮想シーンのデータ処理方法。

【請求項12】

当該仮想シーンのデータ処理方法は、
前記関係が、前記第１クライアントと前記第２クライアントがアクセスした前記シングルラウンド対局が同じ前記シングルラウンド対局であることを示す場合、前記第１クライアントの視野範囲内の前記動的リソースと、前記第２クライアントの視野範囲内の前記動的リソースに対して、同じ横軸座標と縦軸座標、および異なる垂直軸座標を割り当てるステップをさらに含む、
請求項９に記載の仮想シーンのデータ処理方法。

【請求項13】

前記静的リソースに対応する静的リソースマスクを前記複数のクライアントにそれぞれ割り当てることに基づいて、前記複数のシングルラウンド対局間で前記静的リソースを共有するステップは、
前記複数のクライアントのうちのいずれか１つの前記クライアントから送信された静的リソース要求を受信するステップであって、前記静的リソース要求は、前記静的リソースマスクを搬送する、ステップと、
前記静的リソース要求で搬送される前記静的リソースマスクに基づいて、前記複数のクライアントのうちの他のクライアントに同じ前記静的リソースマスクが割り当てられたことが照会され、前記複数のクライアントが前記静的リソースを共有していると決定し、前記複数のクライアントのうちのいずれか１つの前記クライアントに同じ前記静的リソースを送信するステップと、を含む、
請求項１に記載の仮想シーンのデータ処理方法。

【請求項14】

端末機器によって実行される、仮想シーンのデータ処理方法であって、
前記端末機器の第１クライアントを介して、サーバのサービスプロセスに接続し、前記サーバから送信された対局開始命令に応答して、前記サーバが複数のクライアントのために作成した複数のシングルラウンド対局のうちの１つのシングルラウンド対局にアクセスするステップであって、前記複数のシングルラウンド対局は、前記サービスプロセスを共有し、前記サービスプロセスは、前記仮想シーンの静的リソースと動的リソースを含み、前記複数のクライアントは、前記第１クライアントを含む、ステップと、
前記サーバが前記静的リソースに関して送信した静的リソースマスクを受信するステップであって、前記サーバが異なるクライアントに送信した前記静的リソースマスクは同じである、ステップと、
前記サーバが前記動的リソースに関して送信した動的リソースマスクを受信するステップであって、前記サーバが、同じ前記シングルラウンド対局にアクセスする前記クライアントに送信した前記動的リソースマスクは同じであり、且つ異なる前記シングルラウンド対局にアクセスする前記クライアントに送信した前記動的リソースマスクは異なる、ステップと、を含み、
前記静的リソースマスクは、前記複数のシングルラウンド対局間で前記静的リソースを共有するために使用され、前記動的リソースマスクは、異なる前記シングルラウンド対局間で前記動的リソースを分離するために使用される、
仮想シーンのデータ処理方法。

【請求項15】

前記分離は、視野的分離を含み、当該仮想シーンのデータ処理方法は、
前記サーバに動的リソース更新要求を送信するステップであって、前記動的リソース更新要求は、前記動的リソースに対する前記第１クライアントの操作情報と、前記第１クライアントに割り当てられた動的リソースマスクを搬送する、ステップと、
前記サーバから送信された更新後の動的リソースを受信するステップと、をさらに含み、
前記サーバは、前記第１クライアントと同じ前記シングルラウンド対局にアクセスし且つ同じ視野範囲を持つ少なくとも１つのクライアントと、前記第１クライアントに前記更新後の動的リソースをそれぞれ送信する、
請求項１４に記載の仮想シーンのデータ処理方法。

【請求項16】

前記分離は、物理的分離を含み、前記サーバに動的リソース更新要求を送信した後、当該仮想シーンのデータ処理方法は、
前記サーバが前記第１クライアントの視野範囲内の前記動的リソースに対して割り当てた横軸座標、縦軸座標および垂直軸座標を受信するステップをさらに含み、
前記第１クライアントの視野範囲内の前記動的リソースの前記仮想シーンにおける位置が、第２クライアントの視野範囲内の前記動的リソースの前記仮想シーンにおける位置と重なっており、且つ前記第１クライアントと前記第２クライアントがアクセスした前記シングルラウンド対局が互いに異なる前記シングルラウンド対局である場合、前記第１クライアントの視野範囲内の前記動的リソースと、前記第２クライアントの視野範囲内の前記動的リソースは、前記サーバによって、同じ前記横軸座標、前記縦軸座標および前記垂直軸座標が割り当てられる、
請求項１５に記載の仮想シーンのデータ処理方法。

【請求項17】

仮想シーンのデータ処理装置であって、
複数のクライアントを複数のシングルラウンド対局にアクセスさせるように構成されるアクセスモジュールであって、前記複数のシングルラウンド対局は、サービスプロセスを共有し、前記サービスプロセスは、前記仮想シーンの静的リソースと動的リソースを含む、アクセスモジュールと、
前記静的リソースに対応する静的リソースマスクを前記複数のクライアントにそれぞれ割り当てるように構成される第１割り当てモジュールであって、前記複数のクライアントにそれぞれ割り当てられた前記静的リソースマスクは同じである、第１割り当てモジュールと、
前記動的リソースに対応する動的リソースマスクを前記複数のクライアントにそれぞれ割り当てるように構成される第２割り当てモジュールであって、同じ前記シングルラウンド対局にアクセスする前記クライアントに割り当てられた前記動的リソースマスクは同じであり、異なる前記シングルラウンド対局にアクセスする前記クライアントに割り当てられた前記動的リソースマスクは異なる、第２割り当てモジュールと、
前記静的リソースに対応する静的リソースマスクを前記複数のクライアントにそれぞれ割り当てることに基づいて、前記複数のシングルラウンド対局間で前記静的リソースを共有するように構成される共有モジュールと、
前記動的リソースに対応する動的リソースマスクを前記複数のクライアントにそれぞれ割り当てることに基づいて、異なる前記シングルラウンド対局間で前記動的リソースを分離するように構成される分離モジュールと、を備える、
仮想シーンのデータ処理装置。

【請求項18】

電子機器であって、
実行可能命令を記憶するように構成されるメモリと、
前記メモリに記憶された実行可能命令またはコンピュータプログラムを実行することにより、請求項１ないし１６のいずれか一項に記載の仮想シーンのデータ処理方法を実現するように構成されるプロセッサと、を備える、
電子機器。

【請求項19】

コンピュータに、請求項１ないし１６のいずれか一項に記載の仮想シーンのデータ処理方法を実行させるための、コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

（関連出願への相互参照）
本願は、２０２２年０２月１８日に中国特許局に提出された、出願番号が２０２２１０１５２３０１．０である中国特許出願に基づいて提出されるものであり、当該中国特許出願の優先権を主張し、当該中国特許出願のすべての内容が参照により本願に組み込まれている。

【0002】

（技術分野）
本願は、クラウド技術分野に関し、特に、仮想シーンのデータ処理方法およびその装置、電子機器、並びにコンピュータプログラムに関するものである。

【背景技術】

【0003】

ゲーム技術の発展に伴い、サーバは同時に多数のゲームクライアントにリソースサービスを提供する必要があるようになり、異なるゲームクライアントは、異なるゲームのシングルラウンド対局にアクセスし、サービスプロセスは、各シングルラウンド対局のゲームクライアントにリソースサービスを提供する。

【0004】

関連技術では、各ゲームのシングルラウンド対局は、対応する１つのサービスプロセスを起動する必要があり、異なるシングルラウンド対局に対応するサービスプロセスは異なるため、異なるシングルラウンド対局間の動的リソースの分離が実現される。そうすると、サービスプロセスの数は、ゲームシングルラウンド対局の数と等しいため、多数のゲームシングルラウンド対局がそれに対応して同じ数のサービスプロセスを起動し、静的リソースによって占有されるメモリのサイズはサービスプロセスの数と正の相関を有するため、サービスプロセスの数が急増すると、静的リソースのメモリ占有量が大幅に増加し、サーバで大量のデータ冗長が発生する。

【0005】

サーバ内のデータ冗長を効果的に減少する方法については、関連技術ではまだ効果的な解決策がない。

【発明の概要】

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

【0006】

本願実施例は、異なるシングルラウンド対局間での動的リソースの分離と静的リソースの共有を実現することにより、サーバのデータ冗長を減少することができる、仮想シーンのデータ処理方法およびその装置、電子機器、コンピュータ可読記憶媒体、並びにコンピュータプログラム製品を提供する。

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

【0007】

本願実施例の技術的解決策は、以下のように実現される。

【0008】

本願実施例は、サーバによって実行される、仮想シーンのデータ処理方法を提供し、方法は、
複数のクライアントを複数のシングルラウンド対局にアクセスさせるステップであって、複数のシングルラウンド対局は、サービスプロセスを共有し、サービスプロセスは、仮想シーンの静的リソースと動的リソースを含む、ステップと、
静的リソースに対応する静的リソースマスクを複数のクライアントにそれぞれ割り当てるステップであって、複数のクライアントにそれぞれ割り当てられた静的リソースマスクは同じである、ステップと、
動的リソースに対応する動的リソースマスクを複数のクライアントにそれぞれ割り当てるステップであって、同じシングルラウンド対局にアクセスするクライアントに割り当てられた動的リソースマスクは同じであり、異なるシングルラウンド対局にアクセスするクライアントに割り当てられた動的リソースマスクは異なる、ステップと、
静的リソースに対応する静的リソースマスクを複数のクライアントにそれぞれ割り当てることに基づいて、複数のシングルラウンド対局間で静的リソースを共有するステップと、
動的リソースに対応する動的リソースマスクを複数のクライアントにそれぞれ割り当てることに基づいて、異なるシングルラウンド対局間で動的リソースを分離するステップと、を含む。

【0009】

本願実施例は、端末機器によって実行される、仮想シーンのデータ処理方法を提供し、方法は、
端末機器の第１クライアントを介して、サーバのサービスプロセスに接続し、サーバから送信された対局開始命令に応答して、サーバが複数のクライアントのために作成した複数のシングルラウンド対局のうちの１つのシングルラウンド対局にアクセスするステップであって、複数のシングルラウンド対局は、サービスプロセスを共有し、サービスプロセスは、仮想シーンの静的リソースと動的リソースを含み、複数のクライアントは、第１クライアントを含む、ステップと、
サーバが静的リソースに関して送信した静的リソースマスクを受信するステップであって、サーバが異なるクライアントに送信した静的リソースマスクは同じである、ステップと、
サーバが動的リソースに関して送信した動的リソースマスクを受信するステップであって、サーバが、同じシングルラウンド対局にアクセスするクライアントに送信した動的リソースマスクは同じであり、且つ異なるシングルラウンド対局にアクセスするクライアントに送信した動的リソースマスクは異なる、ステップと、を含み、
ここで、静的リソースマスクは、複数のシングルラウンド対局間で静的リソースを共有するために使用され、動的リソースマスクは、異なるシングルラウンド対局間で動的リソースを分離するために使用される。

【0010】

本願実施例は、仮想シーンのデータ処理装置を提供し、装置は、
複数のクライアントを複数のシングルラウンド対局にアクセスさせるように構成されるアクセスモジュールであって、複数のシングルラウンド対局は、サービスプロセスを共有し、サービスプロセスは、仮想シーンの静的リソースと動的リソースを含む、アクセスモジュールと、
静的リソースに対応する静的リソースマスクを複数のクライアントにそれぞれ割り当てるように構成される第１割り当てモジュールであって、複数のクライアントにそれぞれ割り当てられた静的リソースマスクは同じである、第１割り当てモジュールと、
動的リソースに対応する動的リソースマスクを複数のクライアントにそれぞれ割り当てるように構成される第２割り当てモジュールであって、同じシングルラウンド対局にアクセスするクライアントに割り当てられた動的リソースマスクは同じであり、異なるシングルラウンド対局にアクセスするクライアントに割り当てられた動的リソースマスクは異なる、第２割り当てモジュールと、
静的リソースに対応する静的リソースマスクを複数のクライアントにそれぞれ割り当てることに基づいて、複数のシングルラウンド対局間で静的リソースを共有するように構成される共有モジュールと、
動的リソースに対応する動的リソースマスクを複数のクライアントにそれぞれ割り当てることに基づいて、異なるシングルラウンド対局間で動的リソースを分離するように構成される分離モジュールと、を備える。

【0011】

本願実施例は、仮想シーンのデータ処理装置を提供し、装置は、
端末機器の第１クライアントを介して、サーバのサービスプロセスに接続し、サーバから送信された対局開始命令に応答して、サーバが複数のクライアントのために作成した複数のシングルラウンド対局のうちの１つのシングルラウンド対局にアクセスするように構成されるアクセスモジュールであって、複数のシングルラウンド対局は、サービスプロセスを共有し、サービスプロセスは、仮想シーンの静的リソースと動的リソースを含み、複数のクライアントは、第１クライアントを含む、アクセスモジュールと、
サーバが静的リソースに関して送信した静的リソースマスクを受信するように構成される第１受信モジュールであって、サーバが異なるクライアントに送信した静的リソースマスクは同じである、第１受信モジュールと、
サーバが動的リソースに関して送信した動的リソースマスクを受信するように構成される第２受信モジュールであって、サーバが、同じシングルラウンド対局にアクセスするクライアントに送信した動的リソースマスクは同じであり、且つ異なるシングルラウンド対局にアクセスするクライアントに送信した動的リソースマスクは異なる、第２受信モジュールと、を備え、
ここで、静的リソースマスクは、複数のシングルラウンド対局間で静的リソースを共有するために使用され、動的リソースマスクは、異なるシングルラウンド対局間で動的リソースを分離するために使用される。

【0012】

本願実施例は、電子機器を提供し、電子機器は、
実行可能命令を記憶するように構成されるメモリと、
メモリに記憶された実行可能命令を実行することにより、本願の実施例による仮想シーンのデータ処理方法を実現するように構成されるプロセッサと、を備える。

【0013】

本願実施例は、プロセッサに、本願実施例による仮想シーンのデータ処理方法を実行させるための実行可能命令が記憶された、コンピュータ可読記憶媒体を提供する。

【0014】

本願実施例は、コンピュータ可読記憶媒体に記憶されたコンピュータ命令を含む、コンピュータプログラム製品またはコンピュータプログラムを提供する。コンピュータ機器のプロセッサは、コンピュータ可読記憶媒体から当該コンピュータ命令を読み取って実行することによって、当該コンピュータ機器に本願実施例に記載の仮想シーンのデータ処理方法を実行させる。

【発明の効果】

【0015】

本願実施例は、以下の有益な効果を有する。

【0016】

複数のクライアントを複数のシングルラウンド対局にアクセスさせるときに、複数のシングルラウンド対局が１つのサービスプロセスを共有するようにし、異なるシングルラウンド対局のクライアントに、対応する静的リソースマスクと動的リソースマスクを割り当てることにより、複数のシングルラウンド対局間での静的リソースの共有と動的リソースの分離を実現し、これにより、サービスプロセスの数が大幅に減少し、静的リソースによって占有されるメモリのサイズはサービスプロセスの数と正の相関があるため、サービスプロセスの数を大幅に削減することで、静的リソースのメモリ容量の占有量を大幅に減少させることができ、これにより、サーバのデータ冗長を効果的に減少させることができる。

【図面の簡単な説明】

【0017】

【図1】本願実施例による仮想シーンのデータ処理システム１００のアーキテクチャの概略図である。

【図2A】本願実施例によるサーバ２００の例示的な構造図である。

【図2B】本願実施例による端末機器４００－１の例示的な構造図である。

【図3A】本願実施例による仮想シーンのデータ処理方法の例示的なフローチャートである。

【図3B】本願実施例による仮想シーンのデータ処理方法の例示的なフローチャートである。

【図3C】本願実施例による仮想シーンのデータ処理方法の例示的なフローチャートである。

【図3D】本願実施例による仮想シーンのデータ処理方法の例示的なフローチャートである。

【図3E】本願実施例による仮想シーンのデータ処理方法の例示的なフローチャートである。

【図3F】本願実施例による仮想シーンのデータ処理方法の例示的なフローチャートである。

【図3G】本願実施例による仮想シーンのデータ処理方法の例示的なフローチャートである。

【図4A】本願実施例による仮想シーンのデータ処理方法の原理の概略図である。

【図4B】本願実施例による仮想シーンのデータ処理方法の原理の概略図である。

【図4C】本願実施例による仮想シーンのデータ処理方法の原理の概略図である。

【図4D】本願実施例による仮想シーンのデータ処理方法の原理の概略図である。

【図5A】本願実施例による仮想シーンのデータ処理方法の効果の概略図である。

【図5B】本願実施例による仮想シーンのデータ処理方法の効果の概略図である。

【図5C】本願実施例による仮想シーンのデータ処理方法の効果の概略図である。

【図5D】本願実施例による仮想シーンのデータ処理方法の効果の概略図である。

【図5E】本願実施例による仮想シーンのデータ処理方法の効果の概略図である。

【図5F】本願実施例による仮想シーンのデータ処理方法の効果の概略図である。

【図5G】本願実施例による仮想シーンのデータ処理方法の効果の概略図である。

【図5H】本願実施例による仮想シーンのデータ処理方法の効果の概略図である。

【図5I】本願実施例による仮想シーンのデータ処理方法の効果の概略図である。

【図5J】本願実施例による仮想シーンのデータ処理方法の効果の概略図である。

【図5K】本願実施例による仮想シーンのデータ処理方法の例示的なフローチャートである。

【図5L】本願実施例による仮想シーンのデータ処理方法の例示的なフローチャートである。

【図5M】本願実施例による仮想シーンのデータ処理方法の例示的なフローチャートである。

【図5N】本願実施例による仮想シーンのデータ処理方法の原理の概略図である。

【図5O】本願実施例による仮想シーンのデータ処理方法の例示的なフローチャートである。

【図5P】関連技術による原理の概略図である。

【図5Q】本願実施例による仮想シーンのデータ処理方法の原理の概略図である。

【図5R】関連技術による原理の概略図である。

【図5S】関連技術による原理の概略図である。

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

【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】

いくつかの実施例において、上記のステップ１０３は、次の方式で実現することができる。ｍ番目のシングルラウンド対局にアクセスするクライアントにｍ値（ｍの範囲は、

m

であり、Ｍは、サービスプロセスが実行できるシングルラウンド対局の数量の上限である）の動的リソースマスクを割り当てる。

【0085】

ここで、同じシングルラウンド対局にアクセスするクライアントに割り当てられた動的リソースマスクは同じであり、異なるシングルラウンド対局にアクセスするクライアントに割り当てられた動的リソースマスクは異なる。

【0086】

一例として、図４Ａを参照すると、１番目のシングルラウンド対局４２にアクセスするクライアント４２１およびクライアント４２２に１値の動的リソースマスクを割り当て、２番目のシングルラウンド対局４３にアクセスするクライアント４３１およびクライアント４３２に２値の動的リソースマスクを割り当て、３番目のシングルラウンド対局４４にアクセスするクライアント４４１およびクライアント４４２に３値の動的リソースマスクを割り当てる。

【0087】

一例として、図４Ｂを参照すると、１番目のシングルラウンド対局４６にアクセスするクライアント４６１、クライアント４６２およびクライアント４６３に１値の動的リソースマスクを割り当て、２番目のシングルラウンド対局４７にアクセスするクライアント４７１、クライアント４７２およびクライアント４７３に２値の動的リソースマスクを割り当て、３番目のシングルラウンド対局４８にアクセスするクライアント４８１およびクライアント４８２に３値の動的リソースマスクを割り当てる。

【0088】

ステップ１０４において、静的リソースに対応する静的リソースマスクを複数のクライアントにそれぞれ割り当てることに基づいて、複数のシングルラウンド対局間で静的リソースを共有する。

【0089】

いくつかの実施例において、複数のクライアントにそれぞれ割り当てられた静的リソースに対応する静的リソースマスクが同じであるため、同じ静的リソースマスクを用いて、異なるシングルラウンド対局間で静的リソースを共有することができる。異なるシングルラウンド対局におけるクライアントは、同じ静的リソースを共有しており、即ち、サービスプロセスによって各クライアントに送信された静的リソースは同じである。

【0090】

このように、静的リソースに対応する同じ静的リソースマスクを各クライアントに割り当てることにより、サービスプロセスによって各クライアントに送信された静的リソースが同じであるようにし、それにより、異なるシングルラウンド対局間のすべてのクライアントが同じ静的リソースを共有するようにし、静的リソースの冗長ロードを効果的に回避することができる。

【0091】

いくつかの実施例において、図３Ｂを参照すると、図３Ｂは、本願実施例による仮想シーンのデータ処理方法の例示的なフローチャートである。図３Ａに示すステップ１０４は、図３Ｂに示すステップ１０４１ないしステップ１０４２を介して実現することができ、以下では、図３Ｂに示すステップ１０４１ないしステップ１０４２を参照して説明する。

【0092】

ステップ１０４１において、複数のクライアントのうちのいずれか１つのクライアントから送信された静的リソース要求を受信する。

【0093】

一例として、図４Ａを参照すると、サービスプロセス４１は、複数のクライアントのうちのクライアント４２１から送信された静的リソース要求を受信し、ここで、静的リソース要求は、静的リソースマスクを搬送する。

【0094】

一例として、図４Ｂを参照すると、サービスプロセス４５は、複数のクライアントのうちのクライアント４７１から送信された静的リソース要求を受信し、ここで、静的リソース要求は、静的リソースマスクを搬送する。

【0095】

ステップ１０４２において、静的リソース要求で搬送される静的リソースマスクに基づいて、複数のクライアントのうちの他のクライアントに同じ静的リソースマスクが割り当てられたことが照会され、複数のクライアントが静的リソースを共有していると決定し、複数のクライアントのうちのいずれか１つのクライアントに同じ静的リソースを送信する。

【0096】

一例として、図４Ａを参照すると、サービスプロセス４１は、クライアント４２１から送信された静的リソース要求で搬送される静的リソースマスクに基づいて、クライアント４２２、クライアント４３１、クライアント４３２、クライアント４４１およびクライアント４４２に割り当てられた静的リソースマスクが、クライアント４２１から送信された静的リソース要求で搬送される静的リソースマスクと同じであることが照会され、クライアント４２１、クライアント４２２、クライアント４３１、クライアント４３２、クライアント４４１およびクライアント４４２のうちのいずれか１つのクライアントに同じ静的リソースを送信すると決定し、それにより、異なるシングルラウンド対局間の複数のクライアントの静的リソースの共有を実現し、静的リソースのメモリ容量の占有量を節約する。

【0097】

ステップ１０５において、動的リソースに対応する動的リソースマスクを複数のクライアントにそれぞれ割り当てることに基づいて、異なるシングルラウンド対局間で動的リソースを分離する。

【0098】

ここで、分離は、物理的分離と視野的分離を含む。物理的分離は、任意の２つの異なるシングルラウンド対局のクライアントの視野範囲内の動的リソースに対して、同じ横軸座標、縦軸座標および垂直軸座標を割り当てるために使用される。視野的分離は、異なるシングルラウンド対局の２つのクライアントの動的リソースが相互に見えないようにするために使用される。

【0099】

いくつかの実施例において、図３Ｂを参照すると、図３Ｂは、本願実施例による仮想シーンのデータ処理方法の例示的なフローチャートである。図３Ａに示すステップ１０５は、図３Ｂに示すステップ１０５１ないしステップ１０５３を介して実現することができ、以下では、図３Ｂに示すステップ１０５１ないしステップ１０５３を参照して説明する。

【0100】

ステップ１０５１において、複数のクライアントのうちの第１クライアントから送信された動的リソース更新要求を受信する。

【0101】

ここで、動的リソース更新要求には、動的リソースに対する第１クライアントの操作情報と、第１クライアントに割り当てられた動的リソースマスクが搬送される。

【0102】

一例として、図４Ａを参照すると、サービスプロセス４１は、複数のクライアントのうちの第１クライアント４３１から送信された動的リソース更新要求を受信し、動的リソース更新要求には、動的リソースに対する第１クライアント４３１の操作情報が搬送され、例えば、動的リソースが仮想弾丸である場合、第１クライアント４３１は、仮想射撃アイテムをトリガして仮想弾丸を発射するというユーザの制御操作に応答して、動的リソース（仮想弾丸）に対する第１クライアント４３１の操作情報を決定し、動的リソースに対する操作情報に基づいて、動的リソース更新要求を生成し、ここで、制御操作は、仮想射撃アイテムをトリガして仮想弾丸を発射するために使用される。このように、サービスプロセス４１によって受信された動的リソース更新要求には、動的リソースに対する第１クライアント４３１の操作情報と、第１クライアント４３１に割り当てられた動的リソースマスクが搬送される。

【0103】

一例として、図４Ｂを参照すると、サービスプロセス４５は、複数のクライアントのうちの第１クライアント４７２から送信された動的リソース更新要求を受信し、動的リソース更新要求には、動的リソースに対する第１クライアント４７２の操作情報が搬送され、例えば、動的リソースがプレイヤによって制御されるキャラクタである場合、第１クライアント４３１は、キャラクタに対するプレイヤの制御操作に応答して、動的リソース（キャラクタ）に対する第１クライアント４３１の操作情報（例えば、キャラクタが位置を移動するようにトリガする）を決定し、動的リソースに対する操作情報に基づいて、動的リソース更新要求を生成し、ここで、制御操作は、キャラクタの状態を変更するために使用される（例えば、キャラクタを移動させる）。このように、サービスプロセス４５によって受信された動的リソース更新要求には、動的リソースに対する第１クライアント４３１の操作情報と、第１クライアント４３１に割り当てられた動的リソースマスクが搬送される。

【0104】

ステップ１０５２において、操作情報に基づいて、動的リソースを更新して、更新後の動的リソースを取得する。

【0105】

一例として、図４Ａを参照すると、動的リソースがプレイヤによって制御されるキャラクタである場合、第１クライアント４３１は、キャラクタに対するプレイヤの制御操作に応答して、キャラクタの状態を変更し（例えば、キャラクタを移動させる）、動的リソース（キャラクタ）に対する第１クライアント４３１の操作情報（例えば、キャラクタを移動させる）を決定し、操作情報（キャラクタを移動させる）に基づいて、動的リソース（キャラクタ）を更新して、更新後の動的リソースを取得し、更新前のキャラクタと比較して、更新後のキャラクタの位置座標が変更される。

【0106】

一例として、図４Ａを参照すると、動的リソースが仮想弾丸である場合、第１クライアント４３１は、仮想射撃アイテムをトリガして仮想弾丸を発射するというユーザの制御操作に応答して、動的リソース（仮想弾丸）に対する第１クライアント４３１の操作情報（例えば、仮想弾丸を発射する）を決定し、操作情報（仮想弾丸の発射）に基づいて、動的リソース（仮想弾丸）を更新して、更新後の動的リソースを取得し、更新前の仮想弾丸と比較して、更新後の仮想弾丸の位置座標および発射状態が変更され、ここで、制御操作は、仮想弾丸の状態を変更するために使用される（例えば、未発射状態から発射状態に調整する）。

【0107】

ステップ１０５３において、第１クライアントに割り当てられた動的リソースマスクに基づいて、第１クライアントと同じシングルラウンド対局にアクセスし且つ同じ視野範囲を持つ少なくとも１つの第２クライアントを決定する。

【0108】

一例として、視野範囲が同じであることは、同じシングルラウンド対局の２つのクライアントのキャラクタが相互に見えることを意味し、視野範囲が同じであることは、視野範囲が完全に同じであることであってもよいし、視野範囲の一部が同じであることであってもよい。図５Ｄを参照すると、図５Ｄは、本願実施例による仮想シーンのデータ処理方法の効果の概略図である。仮想キャラクタ８の視点から仮想キャラクタ７が観察できる場合、仮想キャラクタ７に対応するクライアントと仮想キャラクタ８に対応するクライアントの視野範囲は同じである。

【0109】

一例として、図４Ａを参照すると、第１クライアントに４３１割り当てられた動的リソースマスクに基づいて、第１クライアント４３１と同じシングルラウンド対局にアクセスするクライアント４３２を決定し、クライアント４３２の視野範囲が第１クライアント４３１の視野範囲と同じであるか否かを決定し、第１クライアント４３１とクライアント４３２の視野範囲が同じである場合、クライアント４３２を第２クライアントとして決定する。

【0110】

一例として、図４Ｂを参照すると、第１クライアントに４７２割り当てられた動的リソースマスクに基づいて、第１クライアント４７２と同じシングルラウンド対局にアクセスするクライアント４７１とクライアント４７３を決定し、クライアント４７１およびクライアント４７３の視野範囲が第１クライアント４７２の視野範囲と同じであるか否かを決定し、第１クライアント４７２の視野範囲が、クライアント４７３およびクライアント４７１の視野範囲と同じである場合、クライアント４７１およびクライアント４７３を第２クライアントとして決定する。

【0111】

いくつかの実施例において、仮想シーンが複数のクライアントで一度に完全に表示できる場合、上記のステップ１０５３は、次の方式で実現することができる。第１クライアントに割り当てられた動的リソースマスクに基づいて、複数のクライアントから、第１クライアントと同じ動的リソースマスクが割り当られた少なくとも１つのクライアントを第２クライアントとして照会する。

【0112】

このように、同じシングルラウンド対局にアクセスするクライアントの動的リソースマスクが同じであるため、第１クライアントに割り当てられた動的リソースマスクに基づいて、第１クライアントと同じ動的リソースマスクを持つターゲットクライアントを決定し、ターゲットクライアントを、第１クライアントと同じシングルラウンド対局にアクセスしたクライアントとして決定することができ、このように、動的リソースマスクを用いて、同じシングルラウンド対局にアクセスしたクライアントを照会することにより、後続での異なるシングルラウンド対局のクライアントの動的リソースの視野的分離と物理的分離が容易になる。

【0113】

いくつかの実施例において、仮想シーンの一部が複数のクライアントで一度に表示される場合、図３Ｄを参照すると、図３Ｄは、本願実施例による仮想シーンのデータ処理方法の例示的なフローチャートである。図３Ｂに示すステップ１０５３は、図３Ｄに示すステップ１０５３１ないしステップ１０５３３を介して実現することができ、以下では、図３Ｄに示すステップ１０５３１ないしステップ１０５３３を参照して説明する。

【0114】

ステップ１０５３１において、第１クライアントに割り当てられた動的リソースマスクに基づいて、複数のクライアンから、第１クライアントと同じ動的リソースマスクが割り当てられた少なくとも１つのクライアントを照会する。

【0115】

一例として、図４Ａを参照すると、サービスプロセス４１は、第１クライアント４３１に割り当てられた動的リソースマスクに基づいて、クライアント４２１、クライアント４２２、クライアント４３２、クライアント４４１およびクライアント４４２から、第１クライアント４３１と同じ動的リソースマスクが割り当てられたクライアント、例えば、クライアント４３２を照会する。

【0116】

一例として、図４Ｂを参照すると、サービスプロセス４５は、第１クライアント４７２に割り当てられた動的リソースマスクに基づいて、クライアント４６１、クライアント４６２、クライアント４６３、クライアント４７１、クライアント４７３、クライアント４８１およびクライアント４８２から、第１クライアント４７２と同じ動的リソースマスクが割り当てられたクライアント、例えば、クライアント４７１およびクライアント４７３を照会する。

【0117】

ステップ１０５３２において、第１クライアントに現在表示されている動的リソースと、少なくとも１つのクライアントのそれぞれに対応する動的リソースとの間の仮想シーンにおける距離を決定する。

【0118】

一例として、図５Ｄと図４Ａを参照すると、第１クライアント４３１に現在表示されている仮想キャラクタ７と、クライアント４３２に対応する仮想キャラクタ８との間の仮想シーンにおける距離、即ち、図５Ｄに示す仮想キャラクタ７と仮想キャラクタ８との間の仮想シーンにおける距離を決定し、ここで、距離とは、仮想シーンの２次元空間または３次元空間における長さを指す。

【0119】

一例として、図４Ｂを参照すると、第１クライアント４７２に現在表示されている動的リソースと、クライアント４７１に対応する動的リソースとの間の仮想シーンにおける距離、および第１クライアント４７２の現在表示されている動的リソースと、クライアント４７３に対応する動的リソースとの間の仮想シーンにおける距離を決定する。

【0120】

ステップ１０５３３において、距離が視野距離閾値より小さい少なくとも１つのクライアントを第２クライアントとする。

【0121】

いくつかの実施例において、視野距離閾値は、同じシングルラウンド対局の２つのクライアントに現在表示されている動的リソースが相互に見えないようにする最小距離である。同じシングルラウンド対局の２つのクライアントに現在表示されている動的リソース間の距離が視野距離閾値より小さい場合、同じシングルラウンド対局の２つのクライアントに現在表示されている動的リソースは、相互に見える。同じシングルラウンド対局の２つのクライアントに現在表示されている動的リソース間の距離が視野距離閾値以上である場合、同じシングルラウンド対局の２つのクライアントに現在表示されている動的リソースは、相互に見えない。

【0122】

一例として、図４Ａと図５Ｄを参照すると、照会された、第１クライアント４３１と同じ動的リソースマスクが割り当てられた少なくとも１つのクライアントがクライアント４３２である場合、第１クライアント４３１に現在表示されている仮想キャラクタ７と、クライアント４３２に現在表示されている仮想キャラクタ８との間の仮想シーンにおける距離が視野距離閾値より小さい場合、クライアント４３２を第２クライアントとして決定する。第１クライアント４３１に現在表示されている仮想キャラクタ７と、クライアント４３２に対応する仮想キャラクタ８との間の仮想シーンにおける距離が視野距離閾値以上である場合、クライアント４３２を第２クライアントとして決定しない。

【0123】

一例として、図４Ｂを参照すると、照会された、第１クライアント４７２と同じ動的リソースマスクが割り当てられた少なくとも１つのクライアントが、クライアント４７１およびクライアント４７３である場合、第１クライアント４７２に現在表示されている動的リソースとクライアント４７１に現在表示されている動的リソースとの間の仮想シーンにおける距離が視野距離閾値より小さい場合、クライアント４７１を第２クライアントとして決定する。第１クライアント４７２に現在表示されている動的リソースとクライアント４７３に現在表示されている動的リソースとの間の仮想シーンにおける距離が視野距離閾値より小さい場合、クライアント４７３を第２クライアントとして決定する。第１クライアント４７２に現在表示されている動的リソースとクライアント４７１に現在表示されている動的リソースとの間の仮想シーンにおける距離が視野距離閾値以上である場合、クライアント４７１を第２クライアントとして決定しない。第１クライアント４７２に現在表示されている動的リソースとクライアント４７３に現在表示されている動的リソースとの間の仮想シーンにおける距離が視野距離閾値以上である場合、クライアント４７３を第２クライアントとして決定しない。

【0124】

いくつかの実施例において、複数のクライアントのうち、第１クライアントと同じシングルラウンド対局にアクセスする第２クライアントが存在しない場合、第１クライアントに更新後の動的リソースを送信する。複数のクライアントのうち、第１クライアントと同じシングルラウンド対局にアクセスする少なくとも１つのクライアントが存在し、且つ少なくとも１つのクライアントと第１クライアントの視野範囲が異なる場合、第１クライアントに更新後の動的リソースを送信する。

【0125】

一例として、図４Ｃを参照すると、複数のクライアント（例えば、クライアント３１１、クライアント３１２、クライアント３１３、クライアント３２１、クライアント３２２、クライアント３２３）のうち、第１クライアント３３１と同じシングルラウンド対局（シングルラウンド対局３３）にアクセスする第２クライアントが存在しない場合、第１クライアント３３１に更新後の動的リソースを送信する。

【0126】

一例として、図４Ｂを参照すると、複数のクライアントのうち、第１クライアント４７２と同じシングルラウンド対局にアクセスする少なくとも１つのクライアント（クライアント４７１およびクライアント４７３）が存在せず、且つクライアント４７１およびクライアント４７３の視野範囲が第１クライアント４７２の視野範囲と異なる場合、第１クライアント４７２に更新後の動的リソースを送信する。

【0127】

このように、視野距離閾値と動的リソース閾値という２つの次元から、第１クライアントと同じシングルラウンド対局にアクセスし且つ視野範囲が同じである少なくとも１つの第２クライアントを決定し、条件を満たす第２クライアントが存在しない場合、更新後の動的リソースを第１クライアントのみに送信することで、第１クライアントと、第１クライアント以外のクライアントとの間での動的リソースの分離を実現する。

【0128】

ステップ１０５４において、第１クライアントおよび少なくとも１つの第２クライアントに更新後の動的リソースを送信する。

【0129】

このように、視野距離閾値と動的リソース閾値という２つの次元から、第１クライアントと同じシングルラウンド対局にアクセスし且つ視野範囲が同じである少なくとも１つの第２クライアントを決定することで、第１クライアントと第２クライアントとの間で動的リソースを共有し、第１クライアントと、第２クライアント以外のクライアントとの間での動的リソースの分離を実現する。

【0130】

いくつかの実施例において、図３Ｅを参照すると、図３Ｅは、本願実施例による仮想シーンのデータ処理方法の例示的なフローチャートである。図３Ａに示すステップ１０５は、図３Ｅに示すステップ１０５５ないしステップ１０５６を介して実現することができ、以下では、図３Ｅに示すステップ１０５５ないしステップ１０５６を参照して説明する。

【0131】

ステップ１０５５において、第１クライアントの視野範囲内の動的リソースの仮想シーンにおける位置が、第２クライアントの視野範囲内の動的リソースの仮想シーンにおける位置と重なる場合、第１クライアントと第２クライアントにそれぞれ割り当てられた動的リソースマスクに基づいて、第１クライアントと第２クライアントがそれぞれアクセスしたシングルラウンド対局間の関係を決定する。

【0132】

ここで、第１クライアントと第２クライアントは、複数のクライアントのうちのいずれか２つである。

【0133】

いくつかの実施例において、上記のステップ１０５５を実行する前に、次の方式で、第１クライアントの視野範囲内の動的リソースの仮想シーンにおける位置が、第２クライアントの視野範囲内の動的リソースの仮想シーンにおける位置と重なるか否かを決定することができる。複数のクライアントのうちの第１クライアントから送信された動的リソース更新要求を受信し、ここで、第１クライアントから送信された動的リソース更新要求には、動的リソースに対する第１クライアントの操作情報と、第１クライアントに割り当てられた動的リソースマスクが搬送され、複数のクライアントのうちの第２クライアントから送信された動的リソース更新要求を受信し、ここで、第２クライアントから送信された動的リソース更新要求には、動的リソースに対する第２クライアントの操作情報と、第２クライアントに割り当てられた動的リソースマスクが搬送され、動的リソースに対する第２クライアントの操作情報と、動的リソースに対する第１クライアントの操作情報に基づいて、第１クライアントの視野範囲内の動的リソースの仮想シーンにおける位置が、第２クライアントの視野範囲内の動的リソースの仮想シーンにおける位置がと重なるか否かを決定する。

【0134】

いくつかの実施例において、位置が重なることは、任意の２つのクライアントの視野範囲内の動的リソースの仮想シーンにおける２次元座標が同じであること、即ち、任意の２つのクライアントの視野範囲内の動的リソースが仮想シーン内で接することを意味する。

【0135】

いくつかの実施例において、第１クライアントと第２クライアントがそれぞれアクセスしたシングルラウンド対局間の関係は、第１クライアントと第２クライアントがそれぞれアクセスしたシングルラウンド対局が互いに異なるシングルラウンド対局であるか否かを示す。即ち、第１クライアントと第２クライアントがそれぞれアクセスしたシングルラウンド対局間の関係は、第１クライアントと第２クライアントがそれぞれアクセスしたシングルラウンド対局が同じシングルラウンド対局であることを示すことができ、第１クライアントと第２クライアントがそれぞれアクセスしたシングルラウンド対局間の関係は、第１クライアントと第２クライアントがそれぞれアクセスしたシングルラウンド対局が互いに異なるシングルラウンド対局であることを示すこともできる。

【0136】

いくつかの実施例において、上記のステップ１０５５において、第１クライアントと第２クライアントにそれぞれ割り当てられた動的リソースマスクに基づいて、第１クライアントと第２クライアントがそれぞれアクセスしたシングルラウンド対局間の関係を決定することは、次の方式で実現することができる。第１クライアントと第２クライアントにそれぞれ割り当てられた動的リソースマスクが同じである場合、第１クライアントと第２クライアントが同じシングルラウンド対局にアクセスしたと決定し、第１クライアントと第２クライアントにそれぞれ割り当てられた動的リソースマスクが異なる場合、第１クライアントと第２クライアントが互いに異なるシングルラウンド対局にアクセスすると決定する。

【0137】

一例として、図４Ａを参照すると、第１クライアントがシングルラウンド対局４２のクライアント４２１であり、第２クライアントがシングルラウンド対局４３のクライアント４３１である場合、即ち、第１クライアントと第２クライアントにそれぞれ割り当てられた動的リソースマスクが異なる場合、第１クライアントと第２クライアントが互いに異なるシングルラウンド対局にアクセスすると決定する。

【0138】

一例として、図４Ｃを参照すると、第１クライアントがシングルラウンド対局３３のクライアント３３１であり、第２クライアントがシングルラウンド対局３２のクライアント３２１である場合、即ち、第１クライアントと第２クライアントにそれぞれ割り当てられた動的リソースマスクが異なる場合、第１クライアントと第２クライアントが互いに異なるシングルラウンド対局にアクセスすると決定する。

【0139】

ステップ１０５６において、関係が、第１クライアントと第２クライアントがそれぞれアクセスしたシングルラウンド対局が互いに異なるシングルラウンド対局であることを示す場合、第１クライアントと第２クライアントのそれぞれに対応する動的リソースに対して物理的分離を実行する。

【0140】

ここで、物理的分離は、第１クライアントの視野範囲内の動的リソースおよび第２クライアントの視野範囲内の動的リソースに対して、同じ横軸座標、縦軸座標および垂直軸座標を割り当てるために使用される。

【0141】

一例として、図４Ａを参照すると、第１クライアントがシングルラウンド対局４２のクライアント４２１であり、第２クライアントがシングルラウンド対局４３のクライアント４３１である場合、関係は、第１クライアントと第２クライアントがそれぞれアクセスしたシングルラウンド対局が互いに異なるシングルラウンド対局であることを示し、第１クライアントと第２クライアントのそれぞれに対応する動的リソースに対して物理的分離を実行し、即ち、第１クライアントの視野範囲内の動的リソースおよび第２クライアントの視野範囲内の動的リソースに対して、同じ横軸座標、縦軸座標および垂直軸座標を割り当てる。第１クライアントと第２クライアントがそれぞれアクセスしたシングルラウンド対局が互いに異なるシングルラウンド対局であることは、第１クライアントと第２クライアントがネットワークにおいて関連しないことを示し、第１クライアントと第２クライアントがそれぞれアクセスしたシングルラウンド対局が同じシングルラウンド対局であることは、第１クライアントと第２クライアントがネットワークにおいて関連することを示す。

【0142】

一例として、図５Ｆを参照すると、仮想キャラクタ１１と仮想キャラクタ１２との間の物理的分離は、仮想キャラクタ１１と仮想キャラクタ１２が相互に見えず、互いに通過可能であることとして表現され、仮想キャラクタ１１と仮想キャラクタ１２に、同じ横軸座標、縦軸座標および垂直軸座標が割り当てられている。

【0143】

このように、第１クライアントの視野範囲内の動的リソースおよび第２クライアントの視野範囲内の動的リソースに、同じ横軸座標、縦軸座標および垂直軸座標を割り当てることにより、第１クライアントの視野範囲内の動的リソースが第２クライアントの視野範囲内の動的リソースと完全に重なるようにして、第１クライアントと第２クライアントのそれぞれに対応する動的リソース間の物理的分離を実現する。

【0144】

いくつかの実施例において、関係が、第１クライアントと第２クライアントがそれぞれアクセスしたシングルラウンド対局が同じシングルラウンド対局であることを示す場合、第１クライアントの視野範囲内の前記動的リソースおよび第２クライアントの視野範囲内の動的リソースに対して、同じ横軸座標と縦軸座標、および異なる垂直軸座標を割り当てる。

【0145】

一例として、図５Ｅを参照すると、仮想キャラクタ９と仮想キャラクタ１０との間で物理的分離を実行しないことは、仮想キャラクタ９と仮想キャラクタ１０が相互に見え且つ相互に通過不可能であることとして表現され、仮想キャラクタ９と仮想キャラクタ１０に、同じ横軸座標と縦軸座標、および異なる垂直軸座標が割り当てられている。

【0146】

いくつかの実施例において、第１クライアントと第２クライアントのそれぞれに対応する動的リソースに対して物理的分離を実行した後、さらに、第１クライアントに対応する物理的分離された動的リソースを第１クライアントに送信し、第２クライアントに対応する物理的分離された動的リソースを第２クライアントに送信することができる。

【0147】

一例として、図４Ａを参照すると、第１クライアントがクライアント４２１であり、第２クライアントがクライアント４３１である場合、クライアント４２１とクライアント４３１のそれぞれに対応する動的リソースに対して物理的分離を実行した後、さらに、クライアント４２１に対応する物理的分離された動的リソースをクライアント４２１に送信し、クライアント４３１に対応する物理的分離された動的リソースをクライアント４３１に送信することができる。

【0148】

一例として、図４Ｂを参照すると、第１クライアントがクライアント４６２であり、第２クライアントがクライアント４７１である場合、クライアント４６２とクライアント４７１のそれぞれに対応する動的リソースに対して物理的分離を実行した後、さらに、クライアント４６２に対応する物理的分離された動的リソースをクライアント４６２に送信し、クライアント４７１に対応する物理的分離された動的リソースをクライアント４７１に送信することができる。

【0149】

図３Ｆを参照すると、図３Ｆは、本願実施例による仮想シーンのデータ処理方法の例示的なフローチャートであり、図３Ｆに示すステップ２０１ないしステップ２１０を参照して説明し、ステップ２０１ないしステップ２１０の実行主体は、前述したサーバまたは端末機器であってもよい。

【0150】

ステップ２０１において、サーバは、複数のクライアントがサービスプロセスに接続されることに応答して、複数のシングルラウンド対局を実行する。

【0151】

ステップ２０２において、サーバは、複数のクライアントに対局開始命令を送信する。

【0152】

ステップ２０３において、サーバは、静的リソースに対応する静的リソースマスクを複数のクライアントにそれぞれ割り当てる。

【0153】

ステップ２０４において、サーバは、動的リソースに対応する動的リソースマスクを複数のクライアントにそれぞれ割り当てる。

【0154】

ステップ２０５において、サーバは、複数のクライアントのうちのいずれか１つのクライアントから送信された静的リソース要求を受信する。

【0155】

ステップ２０６において、サーバは、静的リソース要求で搬送される静的リソースマスクに基づいて、複数のクライアントのうちの他のクライアントに同じ静的リソースマスクが割り当てられたことが照会され、複数のクライアントが静的リソースを共有していると決定する。

【0156】

ステップ２０７において、サーバは、複数のクライアントのうちのいずれか１つのクライアントに同じ静的リソースを送信する。

【0157】

ステップ２０８において、サーバは、複数のクライアントのうちの第１クライアントから送信された動的リソース更新要求を受信する。

【0158】

ステップ２０９において、サーバは、操作情報に基づいて、動的リソースを更新して、更新後の動的リソースを取得する。

【0159】

ステップ２１０において、サーバは、第１クライアントおよび少なくとも１つの第２クライアントに更新後の動的リソースを送信する。

【0160】

いくつかの実施例において、図３Ｇを参照すると、図３Ｇは、本願実施例による仮想シーンのデータ処理方法の例示的なフローチャートであり、図３Ｇに示すステップ３０１ないしステップ３０３を参照して説明し、ステップ３０１ないしステップ３０３の実行主体は、前述した端末機器であってもよい。

【0161】

ステップ３０１において、端末機器の第１クライアントを介して、サーバのサービスプロセスに接続し、サーバから送信された対局開始命令に応答して、サーバが複数のクライアントのために作成した複数のシングルラウンド対局のうちの１つのシングルラウンド対局にアクセスする。

【0162】

いくつかの実施例において、複数のシングルラウンド対局は、サービスプロセスを共有することができ、サービスプロセスは、仮想シーンの静的リソースと動的リソースを含み、複数のクライアントは、第１クライアントを含む。

【0163】

ステップ３０２において、第１クライアントは、サーバが静的リソースに関して送信した静的リソースマスクを受信する。

【0164】

いくつかの実施例において、サーバが異なるクライアントに送信した静的リソースマスクは同じである。

【0165】

ステップ３０３において、第１クライアントは、サーバが動的リソースに関して送信した動的リソースマスクを受信する。

【0166】

いくつかの実施例において、サーバが、同じシングルラウンド対局にアクセスするクライアントに送信した動的リソースマスクは同じであり、且つ異なるシングルラウンド対局にアクセスするクライアントに送信した動的リソースマスクは異なる。

【0167】

ここで、静的リソースマスクは、複数のシングルラウンド対局間で静的リソースを共有するために使用され、動的リソースマスクは、異なるシングルラウンド対局間で動的リソースを分離するために使用される。

【0168】

いくつかの実施例において、分離は、視野的分離を含み、上記のステップ３０３を実行した後、次の方式で視野的分離を実現することができる。動的リソース更新要求をサーバに送信し、ここで、動的リソース更新要求には、動的リソースに対する第１クライアントの操作情報と、第１クライアントに割り当てられた動的リソースマスクが搬送され、サーバから送信された更新後の動的リソースを受信し、ここで、サーバは、第１クライアントと同じシングルラウンド対局にアクセスし且つ視野範囲が同じである少なくとも１つのクライアントと、第１クライアントに更新後の動的リソースをそれぞれ送信する。

【0169】

このように、サーバを介して、第１クライアントと同じシングルラウンド対局にアクセスし且つ視野範囲が同じである少なくとも１つのクライアントと、第１クライアントに更新後の動的リソースをそれぞれ送信することにより、第１クライアントと、第１クライアントと同じシングルラウンド対局にアクセスし且つ視野範囲が同じである少なくとも１つのクライアントとが相互に見えるようにし、第１クライアントと、第１クライアントと異なるシングルラウンド対局にアクセスするクライアントとが相互に見えないようにして、第１クライアントと、第１クライアントと異なるシングルラウンド対局にアクセスするクライアントとの間の視野的分離を実現する。

【0170】

いくつかの実施例において、分離は、物理的分離を含み、第１クライアントがサーバに動的リソース更新要求を送信した後、次の方式で物理的分離を実現することができる。サーバによって第１クライアントの視野範囲内の動的リソースに割り当てられた横軸座標、縦軸座標および垂直軸座標を受信し、ここで、第１クライアントの視野範囲内の動的リソースの仮想シーンにおける位置が、第２クライアントの視野範囲内の動的リソースの仮想シーンにおける位置と重なり、且つ第１クライアントと第２クライアントがそれぞれアクセスしたシングルラウンド対局が互いに異なるシングルラウンド対局である場合、サーバは、第１クライアントの視野範囲内の動的リソースおよび第２クライアントの視野範囲内の動的リソースに対して、同じ横軸座標、縦軸座標および垂直軸座標を割り当てる。

【0171】

このように、第１クライアントの視野範囲内の動的リソースの仮想シーンにおける位置が、第２クライアントの視野範囲内の動的リソースの仮想シーンにおける位置と重なっており、且つ第１クライアントと第２クライアントがそれぞれアクセスしたシングルラウンド対局が互いに異なるシングルラウンド対局である場合、サーバによって、第１クライアントの視野範囲内の動的リソースおよび第２クライアントの視野範囲内の動的リソースに対して、同じ横軸座標、縦軸座標および垂直軸座標を割り当てることにより、第１クライアントと第２クライアントとの間の物理的分離を実現する。

【0172】

このように、一方では、複数のクライアントを複数のシングルラウンド対局にアクセスさせ、これら複数のシングルラウンド対局が１つのサービスプロセスを共有することを実現し、それにより、サービスプロセスの数をゲームシングルラウンド対局の数より大幅に小さくし、即ち、サービスプロセスの数を大幅に減少させ、静的リソースによって占有されるメモリのサイズはサービスプロセスの数と正の相関があるため、サービスプロセスの数を大幅に削減することで、静的リソースのメモリ容量の占有量を大幅に減少させることができ、これにより、データ冗長を効果的に減少させることができる。もう一方では、複数のシングルラウンド対局が１つのサービスプロセスを共有するため、異なるシングルラウンド対局のクライアントに、対応する静的リソースマスクと動的リソースマスクを割り当てることにより、複数のシングルラウンド対局間での静的リソースの共有と動的リソースの分離を実現する。このようにして、サーバにおけるデータ冗長を効果的に減少させるとともに、異なるシングルラウンド対局間での動的リソースの分離と静的リソースの共有を実現することができる。

【0173】

図５Ｑを参照すると、図５Ｑは、本願実施例による仮想シーンのデータ処理方法の原理の概略図である。本願実施例による仮想シーンのデータ処理方法により、複数のシングルラウンド対局がプロセスを多重使用することを実現することができ、例えば、シングルラウンド対局０４、シングルラウンド対局０５およびシングルラウンド対局０６は、プロセス０１４を多重使用することができる。このように、複数のシングルラウンド対局が同じプロセスを多重使用することにより、次のような有益な効果を達成することができる。

【0174】

（１）メモリ占有量が削減する。複数のシングルラウンド対局が同じ静的リソースを共有することにより、静的リソースの冗長ロードが効果的に減少する。

【0175】

（２）ＣＰＵ負荷が軽減する。関連技術と比較して、プロセスの数が大幅に削減されるため、一方で、プロセスの物理的コンピューティングとレンダリングコンピューティングのオーバーヘッドを効果的に節約する。もう一方で、レベル３キャッシュミスを効果的に減少し、キャッシュのオーバーヘッドを減少する。

【0176】

（３）複数のシングルラウンド対局がプロセスをローリング多重使用する。プロセスサは、複数のシングルラウンド対局のローリング多重使用をポートし、これにより、大量のリソースのロードとアンロードの冗長化のオーバーヘッドを回避することができる。

【0177】

以下では、１つの実際のオンラインゲームの適用シナリオにおける本願実施例の例示的な適用について説明する。

【0178】

本願実施例は、次のような適用シナリオを有することができ、例えば、１つの実際のオンラインゲームの適用シナリオにおいて、図５Ａないし図５Ｄを参照すると、図５Ａないし図５Ｄは、本願実施例による仮想シーンのデータ処理方法の効果の概略図である。図５Ａを参照すると、図５Ａに示すオンラインゲームの仮想シーンでは、プレイヤＡによって制御される仮想キャラクタ１と、プレイヤＢによって制御される仮想キャラクタ２は、同じシングルラウンド対局に属し、プレイヤＣによって制御される仮想キャラクタ３は、仮想キャラクタ１および仮想キャラクタ２とは異なるシングルラウンド対局に属する。異なるシングルラウンド対局の仮想キャラクタは相互に見えず、例えば、仮想キャラクタ１にとっては、仮想キャラクタ３が見えるが、仮想キャラクタ２は見えず、仮想キャラクタ３にとっては、仮想キャラクタ１および仮想キャラクタ２は見えない。具体的には、図５Ｂを参照すると、図５Ｂに示す仮想キャラクタ４の視点での仮想シーンにおいて、仮想キャラクタ４にとっては、図５Ａに示す仮想キャラクタ１および仮想キャラクタ２は見えない。図５Ｃを参照すると、図５Ｃに示す仮想キャラクタ５の視点での仮想シーンにおいて、仮想キャラクタ５にとっては、仮想キャラクタ６が見えるが、図５Ａに示す仮想キャラクタ３は見えない。図５Ｄを参照すると、図５Ｄに示す仮想キャラクタ８の視点での仮想シーンにおいて、仮想キャラクタ８にとっては、仮想キャラクタ７が見えるが、図５Ａに示す仮想キャラクタ３は見えない。即ち、異なるシングルラウンド対局のキャラクタは、相互に見えず、同じシングルラウンド対局のキャラクタは相互に見える。本願実施例による仮想シーンのデータ処理方法により、異なるシングルラウンド対局のクライアントは、ネットワークサーバのサービスプロセスを共有し、サービスプロセスは、各シングルラウンド対局内の動的リソースに同じシングルラウンド対局マスク（即ち、前述した動的リソースマスク）を割り当て、異なるシングルラウンド対局内の動的リソースに異なるシングルラウンド対局マスクを割り当て、シングルラウンド対局マスクの割り当てにより、異なるシングルラウンド対局内の動的リソースの視野的分離と物理的分離を実現する。それにより、ネットワークサーバの収容空間が大幅にリリースされ、ネットワークサーバの収容能力が効果的に向上する。

【0179】

一例として、図５Ｅを参照すると、図５Ｅは、本願実施例による仮想シーンのデータ処理方法の効果の概略図である。仮想キャラクタ９のシングルラウンド対局マスク（即ち、前述した動的リソースマスク）と仮想キャラクタ１０のシングルラウンド対局マスクは同じであり、即ち、仮想キャラクタ９と仮想キャラクタ１０は、同じシングルラウンド対局に属し、仮想キャラクタ９と仮想キャラクタ１０の位置が重なる（２次元座標が同じである）場合、仮想キャラクタ９と仮想キャラクタ１０との間に物理的衝突が存在し、仮想キャラクタ９と仮想キャラクタ１０は、互いが存在すると判定し、空間上の表現としては、仮想キャラクタ９と仮想キャラクタ１０は、同じ２次元座標において上下に積み重ねられており、即ち、仮想キャラクタ９と仮想キャラクタ１０が同じ２次元座標にある場合、衝突が発生し、且つ互いに通過できず、即ち、同じシングルラウンド対局のキャラクタは、互いの存在を検知することができる。

【0180】

一例として、図５Ｆを参照すると、図５Ｆは、本願実施例による仮想シーンのデータ処理方法の効果の概略図である。仮想キャラクタ１１のシングルラウンド対局マスクと仮想キャラクタ１２のシングルラウンド対局マスクは異なり、即ち、仮想キャラクタ１１と仮想キャラクタ１２は、異なるシングルラウンド対局に属し、仮想キャラクタ１１と仮想キャラクタ１２の位置が重なる（２次元座標が同じである）場合、即ち、仮想キャラクタ１１と仮想キャラクタ１２との間に物理的衝突が存在せず、仮想キャラクタ１１と仮想キャラクタ１２は、互いが存在しないと判定し、空間上の表現としては、仮想キャラクタ１１と仮想キャラクタ１２は、同じ２次元座標で重なることができ、即ち、仮想キャラクタ１１と仮想キャラクタ１２が同じ２次元座標にある場合、衝突は起こらず、且つ互いに通過することができ、即ち、異なるシングルラウンド対局のキャラクタは、互いの存在を検知できない。

【0181】

図５Ｇないし図５Ｊを参照すると、図５Ｇないし図５Ｊは、本願実施例による仮想シーンのデータ処理方法の効果の概略図である。静的リソースとは、異なるクライアントによって共有されるリソースを指し、静的リソースは、異なるクライアントによって共有されることができる。オンラインゲームでは、静的リソースは、オンラインゲームにおいてインタラクション不可のリソースであり、即ち、ゲームプロセス中に状態が変更できないリソースであり、例えば、静的リソースは、図５Ｇに示すオンラインゲーム内の仮想建物建築５１であってもよく、静的リソースは、図５Ｈに示すオンラインゲーム内の仮想都市景観５２などであってもよい。動的リソースとは、異なるクライアントの異なるリソースを指し、動的リソースは、各クライアント専用にすることができる。オンラインゲームでは、動的リソースは、オンラインゲーム内のインタラクション可能なリソースであり、即ち、ゲームプロセス中に状態が変更できるリソースであり、例えば、動的リソースは、図５Ｉに示す、プレイヤによって制御される仮想キャラクタ５３であってもよく、動的リソースは、図５Ｊに示すオンラインゲーム内の仮想弾丸５４などであってもよい。

【0182】

このようにして、異なるシングルラウンド対局間のキャラクタは、視野上で互いに見えず、同じシングルラウンド対局内のキャラクタは、視野上で互いに見える。動的には、異なるシングルラウンド対局間のキャラクタは物理的に分離され、同じシングルラウンド対局のキャラクタは、物理的に存在すると決定される。即ち、同じシングルラウンド対局のキャラクタは、互いに検知することができ、異なるシングルラウンド対局のキャラクタは互いに検知できず、これにより、同じプロセスを多重使用して、複数のシングルラウンド対局を同時実行することを実現することができる。

【0183】

以下では、本願実施例による仮想シーンのデータ処理方法の具体的実施過程について説明する。

【0184】

まず、シングルラウンド対局マスク（即ち、前述した動的リソースマスクと静的リソースマスク）の具体的な生成方式について説明する。図５Ｋを参照すると、図５Ｋは、本願実施例による仮想シーンのデータ処理方法の例示的なフローチャートである。以下では、図５Ｋに示すステップ５０１ないしステップ５０９を参照して、シングルラウンド対局マスクの生成方式について説明する。

【0185】

ステップ５０１において、サーバプロセスは、初期化される。

【0186】

ステップ５０２において、第１クライアントは、プロセスに接続する。

【0187】

ステップ５０３において、第２クライアントは、プロセスに接続する。

【0188】

ステップ５０４において、サーバプロセスは、シングルラウンド対局マスクを生成する。

【0189】

いくつかの実施例において、各シングルラウンド対局の動的リソースのシングルラウンド対局マスク（即ち、前述した動的リソースマスク）は同じであり、異なるシングルラウンド対局の動的リソースのシングルラウンド対局マスクは異なる。即ち、１つのシングルラウンド対局のすべての動的リソースに対して同じシングルラウンド対局マスクが設定され、キャラクタは、動的リソースのサブセットである。

【0190】

各動的リソースのシングルラウンド対局マスクは、各動的リソースの変数に記録され、シングルラウンド対局マスクの最大値は２５６であってもよい。シングルラウンド対局マスクの生成ルールの関係式は、以下の通りであり得る。
（式１）
ｖｉｅｗ＿ｍａｓｋ＿ｉｄ＝ｂａｔｔｌｅ＿ｃｏｕｎｔ
ここで、ｖｉｅｗ＿ｍａｓｋ＿ｉｄは、動的リソースのシングルラウンド対局マスクを表し、ｂａｔｔｌｅ＿ｃｏｕｎｔは、プロセスによって作成されたシングルラウンド対局の数を表す。

【0191】

ステップ５０５において、サーバプロセスは、第２クライアントにシングルラウンド対局マスクを返信する。

【0192】

ステップ５０６において、サーバプロセスは、第１クライアントにシングルラウンド対局マスクを返信する。

【0193】

ステップ５０７において、サーバプロセスは、シングルラウンド対局を開始する。

【0194】

ここで、対局開始条件が満たされる場合、プロセスは、シングルラウンド対局を開始する。対局開始条件は、シングルラウンド対局のキャラクタ数が２以上であること、即ち、シングルラウンド対局のプレイヤ数がプレイヤ数の下限閾値以上であることであってもよく、プロセスは、クライアントに対局開始命令を発行して、第１シングルラウンド対局を開始する。第１シングルラウンド対局のシングルラウンド対局キャラクタ数がキャラクタ数の上限閾値に達した場合、次のシングルラウンド対局の開始を準備し、次のシングルラウンド対局が対局開始条件を満たした場合、次のシングルラウンド対局を開始する。

【0195】

ステップ５０８において、サーバプロセスは、第１クライアントに対局開始命令を発行する。

【0196】

ステップ５０９において、サーバプロセスは、第２クライアントに対局開始命令を発行する。

【0197】

図５Ｌを参照すると、図５Ｌは、本願実施例による仮想シーンのデータ処理方法の例示的なフローチャートである。以下では、図５Ｌに示すステップ５１０ないしステップ５１４を参照して、プロセス属性の同期方式について説明する。

【0198】

ステップ５１０において、サーバプロセスは、メインループに入る。

【0199】

一例として、プロセスがメインループに入った後、プロセスを進行させる。

【0200】

ステップ５１１において、サーバプロセスは、クライアントのアップリンクネットワークパケットを受信する。

【0201】

一例として、プロセスは、各クライアントからそれぞれ送信されたアップリンクネットワークパケットを受信し、アップリンクネットワークパケットには、動的リソースに対するクライアントの操作情報が搬送され、ここで、動的リソースに対するクライアントの操作情報は、仮想キャラクタに対する位置移動操作、仮想弾丸に対する射撃操作、仮想キャラクタスキルに対する解放操作などであってもよい。

【0202】

ステップ５１２において、サーバプロセスは、論理処理を実行する。

【0203】

一例として、プロセスは、アップリンクネットワークパケットを受信した後、収集した操作情報に対して論理計算を実行し、例えば、論理計算は、仮想キャラクタに対する位置移動操作に基づいて、異なる２つの仮想キャラクタが互いの視野範囲内にあるか否かを決定する。

【0204】

ステップ５１３において、サーバプロセスは、ネットワーク関連性計算を実行する。

【0205】

一例として、ネットワーク関連性計算は、視野範囲内の２つの仮想キャラクタがネットワーク関連性を有するか否かを判断すること、即ち、視野範囲内の２つの仮想キャラクタが同じシングルラウンド対局に属するか否かを判断することであり得る。

【0206】

一例として、図５Ｍを参照すると、図５Ｍは、本願実施例による仮想シーンのデータ処理方法の例示的なフローチャートである。以下では、図５Ｍに示すステップ５１３１ないしステップ５１３４を参照して、仮想キャラクタＡ（以下では、キャラクタＡと略称する）の観点から、ネットワーク関連性の計算過程について説明する。

【0207】

ステップ５１３１において、サーバプロセスは、キャラクタＡの視野範囲内の任意のリソースのシングルラウンド対局マスクが０であるか否かを判断する。

【0208】

一例として、キャラクタＡの視野範囲内の任意のリソースは、キャラクタＡの視野範囲内のすべての動的リソースと静的リソースを含む。プロセスは、キャラクタＡの視野範囲内のすべてのリソースをトラバースして、キャラクタＡの視野範囲内の任意のリソースのシングルラウンド対局マスクが０であるか否かを判断する。キャラクタＡの視野範囲内の任意のリソースのシングルラウンド対局マスクが０である場合、これは、シングルラウンド対局マスクが０であるリソースが静的リソースであることを意味し、静的リソースがすべてのシングルラウンド対局によって共有されるため、キャラクタＡがどのシングルラウンド対局に属しているかに関係なく、キャラクタＡは、すべての静的リソースとネットワーク関連性を有する。キャラクタＡの視野範囲内の任意のリソースのシングルラウンド対局マスクが０である場合、ステップ５１３３に移行し、キャラクタＡの視野範囲内の任意のリソースのシングルラウンド対局マスクが０ではない場合、ステップ５１３２に移行する。

【0209】

ステップ５１３２において、サーバプロセスは、キャラクタＡのシングルラウンド対局マスクが任意のリソースのシングルラウンド対局マスクと等しいか否かを判断する。

【0210】

一例として、キャラクタＡの視野範囲内の任意のリソースのシングルラウンド対局マスクが０でない場合、プロセスは、キャラクタＡのシングルラウンド対局マスクが、任意のリソースのシングルラウンド対局マスクと同じであるか否かを判断し、キャラクタＡのシングルラウンド対局マスクが、任意のリソースのシングルラウンド対局マスクと等しい場合、これは、リソースが属するシングルラウンド対局が、キャラクタＡが属するシングルラウンド対局と同じシングルラウンド対局であることを意味し、ステップ５１３３に移行する。キャラクタＡのシングルラウンド対局マスクが、任意のリソースのシングルラウンド対局マスクと異なる場合、リソースが属するシングルラウンド対局が、キャラクタＡが属するシングルラウンド対局と異なるシングルラウンド対局であることを意味し、ステップ５１３４に移行する。

【0211】

ステップ５１３３において、ネットワークが関連していると判定する。

【0212】

一例として、キャラクタＡの視野範囲内のリソースとキャラクタＡのネットワークが関連していると判断する。

【0213】

ステップ５１３４において、ネットワークが関連していないと判定する。

【0214】

一例として、キャラクタＡの視野範囲内のリソースとキャラクタＡのネットワークが関連していないと判断する。

【0215】

このように、シングルラウンド対局マスクに基づくネットワーク関連性の判定により、異なるシングルラウンド対局間の動的リソースの属性の非同期が実現され、それにより、シングルラウンド対局間の視野的分離が実現される。

【0216】

ステップ５１４において、サーバプロセスは、属性の同期を実行する。

【0217】

一例として、２つのキャラクタがネットワーク関連性を有する場合、プロセスは、互いの属性情報と動的リソースを相方のキャラクタに同期させる。

【0218】

図５Ｎを参照すると、図５Ｎは、本願実施例による仮想シーンのデータ処理方法の原理の概略図である。シングルラウンド対局の実行中に、プロセスにおいて、動的リソース間で衝突が発生する可能性があり、プロセスは、動的リソースＡと動的リソースＢとの間のシングルラウンド対局マスクが同じであるか否かを判断することにより、動的リソースＡと動的リソースＢとが衝突するか否かを判断する。動的リソースＡと動的リソースＢとの間のシングルラウンド対局マスクが同じである場合、動的リソースＡと動的リソースＢとの間で衝突が発生し、動的リソースＡと動的リソースＢとの間のシングルラウンド対局マスクが異なる場合、動的リソースＡと動的リソースＢとの間で衝突が発生しない。

【0219】

一例として、動的リソースＡがプレイヤによって制御される仮想キャラクタであり、動的リソースＢが仮想弾丸である場合、仮想弾丸が仮想キャラクタに向けて発射された場合、仮想キャラクタのシングルラウンド対局マスクが仮想弾丸のシングルラウンド対局マスクと同じであるか否かを判断し、仮想キャラクタと仮想弾丸とが衝突するか否かを判断する。仮想キャラクタのシングルラウンド対局マスクが仮想弾丸のシングルラウンド対局マスクと同じである場合、仮想キャラクタと仮想弾丸は同じシングルラウンド対局に属し、仮想弾丸がキャラクタに向けて発射された場合、仮想キャラクタと仮想弾丸とが衝突する。仮想キャラクタのシングルラウンド対局マスクが仮想弾丸のシングルラウンド対局マスクと異なる場合、仮想キャラクタは仮想弾丸と異なるシングルラウンド対局に属し、仮想弾丸が仮想キャラクタに発射された場合、仮想キャラクタと仮想弾丸は衝突しない。

【0220】

図５Ｏを参照すると、図５Ｏは、本願実施例による仮想シーンのデータ処理方法の例示的なフローチャートである。以下では、図５Ｏに示すステップ５２０ないしステップ５２３を参照して、キャラクタＡの観点から、衝突を計算するか否かを判断する過程について説明する。

【0221】

ステップ５２０において、サーバは、キャラクタＡの視野範囲内の任意のリソースのシングルラウンド対局マスクが０であるか否かを判断する。

【0222】

一例として、キャラクタＡの視野範囲内の任意のリソースのシングルラウンド対局マスクが０である場合、ステップ５２２に移行する。キャラクタＡの視野範囲内の任意のリソースのシングルラウンド対局マスクが０でない場合、ステップ５２１に移行する。シングルラウンド対局マスクが０であるリソースは静的リソースであり、静的リソースは、すべてのシングルラウンド対局によって共有されるため、任意の１つの静的リソースはすべて、他のリソース（他のリソースは、静的リソースであってもよいし動的リソースであってもよい）と衝突する可能性があるため、シングルラウンド対局マスクが０であるリソースはすべて、衝突を計算する必要がある。

【0223】

ステップ５２１において、サーバは、キャラクタＡのシングルラウンド対局マスクが任意のリソースのシングルラウンド対局マスクと同じであるか否かを判断する。

【0224】

一例として、キャラクタＡのシングルラウンド対局マスクが、任意のリソースのシングルラウンド対局マスクと等しい場合、ステップ５２２に移行する。キャラクタＡのシングルラウンド対局マスクが、任意のリソースのシングルラウンド対局マスクと異なる場合、ステップ５２３に移行する。

【0225】

ステップ５２２において、サーバは、キャラクタＡと任意のリソースとの間の衝突を計算する。

【0226】

ステップ５２３において、サーバは、キャラクタＡと任意のリソースとの間の衝突を計算しない。

【0227】

このように、シングルラウンド対局マスクを使用して衝突判定をフィルタリングすることにより、同じシングルラウンド対局内のプレイヤに対してのみ衝突計算を実行する必要があるため、シングルラウンド対局間の物理的分離が実現される。

【0228】

静的リソースによって占有されるメモリのサイズがプロセスの数と正の相関があるため、２つのプロセスによって占有される静的リソースは、１つのプロセスによって占有される静的リソースの２倍になる。複数のプロセスに同一の静的リソースが含まれる場合、静的リソースが繰り返しロードされるため、静的リソースが占めるメモリの増加につながる。本願実施例による仮想シーンのデータ処理方法により、複数のシングルラウンド対局がプロセスを多重使用することを実現でき、これにより、プロセスの数を節約し、静的リソースの多重使用を実現することができる。

【0229】

複数のシングルラウンド対局が、同じ静的リソースを共有するため、静的リソースの冗長記録が効果的に削減される。プロセスの数の削減により、プロセスの物理的計算とレンダリング計算のオーバーヘッドが節約される一方、レベル３キャッシュミス（Ｌ３ Ｃａｃｈｅ Ｍｉｓｓ）が大幅に減少し、キャッシュオーバーヘッドが効果的に低減される。プロセスは、複数のシングルラウンド対局のローリング多重使用をサポートするため、大量のリソースのロード、アンロード、および構築の冗長化オーバーヘッドを効果的に回避する。

【0230】

理解できることとして、本願の実施例では、静的リソースと動的リソースなどの関連データが言及されているが、本願の実施例が特定の製品や技術に適用される場合、ユーザの許可または同意が必要があり、関連データの収集、使用および処理は、関連する国や地域の関連する法律規制および標準を従うべきである。

【0231】

以下では、ソフトウェアモジュールとして実施される、本願実施例による仮想シーンのデータ処理装置２５５の例示的な構造について説明し続ける。いくつかの実施例において、図２Ａに示すように、メモリ２５０に記憶された仮想シーンのデータ処理装置２５５におけるソフトウェアモジュールは、複数のクライアントを複数のシングルラウンド対局にアクセスさせるように構成されるアクセスモジュール２５５１であって、複数のシングルラウンド対局は、サービスプロセスを共有し、サービスプロセスは、仮想シーンの静的リソースと動的リソースを含む、アクセスモジュール２５５１と、静的リソースに対応する静的リソースマスクを複数のクライアントにそれぞれ割り当てるように構成される第１割り当てモジュール２５５２であって、複数のクライアントにそれぞれ割り当てられた静的リソースマスクは同じである、第１割り当てモジュール２５５２と、動的リソースに対応する動的リソースマスクを複数のクライアントにそれぞれ割り当てるように構成される第２割り当てモジュール２５５３であって、同じシングルラウンド対局にアクセスするクライアントに割り当てられた動的リソースマスクは同じであり、異なるシングルラウンド対局にアクセスするクライアントに割り当てられた動的リソースマスクは異なる、第２割り当てモジュール２５５３と、静的リソースに対応する静的リソースマスクを複数のクライアントにそれぞれ割り当てることに基づいて、複数のシングルラウンド対局間で静的リソースを共有するように構成される共有モジュール２５５４と、動的リソースに対応する動的リソースマスクを複数のクライアントにそれぞれ割り当てることに応答して、異なるシングルラウンド対局間で動的リソースを分離するように構成される分離モジュール２５５５と、を含む。

【0232】

いくつかの実施例において、上記のアクセスモジュール２５５１はさらに、複数のクライアントがサービスプロセスに接続されることに応答して、複数のシングルラウンド対局を実行し、複数のクライアントに対局開始命令を送信するように構成され、ここで、対局開始命令は、複数のクライアントが複数のシングルラウンド対局に接続するために使用され、各クライアントは、１つのシングルラウンド対局に接続し、各シングルラウンド対局へのアクセスの数は、対局開始閾値以上且つ対局閉鎖閾値以下である。

【0233】

いくつかの実施例において、上記のアクセスモジュール２５５１はさらに、複数のクライアントがサービスプロセスに接続され、且つ複数のクライアントの数量が対局開始閾値以上であることに応答して、１番目のシングルラウンド対局を実行し始め、第１数量のクライアントに対局開始命令を送信し、対局開始命令は、第１数量のクライアントが１番目のシングルラウンド対局にアクセスするために使用され、ｔ（

であり、Ｔは、サービスプロセスが実行できるシングルラウンド対局の数量の上限である）を漸増させて逐次代入することによって、次の処理を実行するように構成され、前記処理は、ｔ番目のシングルラウンド対局にアクセスしたクライアントの数量が対局閉鎖閾値と等しく、且つ１番目からｔ番目のシングルラウンド対局にアクセスしていないクライアントの数量が対局開始閾値以上であることに応答して、ｔ＋１番目のシングルラウンド対局を実行し始め、１番目からｔ番目のシングルラウンド対局にアクセスしていないクライアントの少なくとも一部をｔ＋１番目のシングルラウンド対局にアクセスさせるステップを含む。

【0234】

いくつかの実施例において、上記の第１割り当てモジュール２５５２はさらに、０値の静的リソースマスクを複数のクライアントに割り当てるように構成される。上記の第２割り当てモジュール２５５２はさらに、ｍを漸増させて逐次代入することによって、次の処理を実行するように構成され、前記処理は、ｍ値（ｍの範囲は、

であり、Ｍは、サービスプロセスが実行できるシングルラウンド対局の数量の上限である）の動的リソースマスクをｍ番目のシングルラウンド対局にアクセスしたクライアントに割り当てるステップを含む。

【0235】

いくつかの実施例において、上記の分離は視野的分離を含み、上記の分離モジュール２５５５はさらに、複数のクライアントのうちの第１クライアントから送信された動的リソース更新要求を受信し、ここで、動的リソース更新要求には、動的リソースに対する第１クライアントの操作情報と、第１クライアントに割り当てられた動的リソースマスクが搬送され、操作情報に基づいて、動的リソースを更新して、更新後の動的リソースを取得し、第１クライアントに割り当てられた動的リソースマスクに基づいて、第１クライアントと同じシングルラウンド対局にアクセスし且つ視野範囲が同じである少なくとも１つの第２クライアントを決定し、第１クライアントおよび少なくとも１つの第２クライアントに更新後の動的リソースを送信するように構成される。

【0236】

いくつかの実施例において、仮想シーンが複数のクライアントで一度に完全に表示されることができる場合、上記の分離モジュール２５５５はさらに、第１クライアントに割り当てられた動的リソースマスクに基づいて、複数のクライアントから、第１クライアントと同じ動的リソースマスクが割り当られた少なくとも１つのクライアントを第２クライアントとして照会するように構成される。

【0237】

いくつかの実施例において、仮想シーンの一部が複数のクライアントに一度に表示される場合、上記の分離モジュール２５５５はさらに、第１クライアントに割り当てられた動的リソースマスクに基づいて、複数のクライアンから、第１クライアントと同じ動的リソースマスクが割り当てられた少なくとも１つのクライアントを照会し、第１クライアントに現在表示されている動的リソースと、少なくとも１つのクライアントのそれぞれに対応する動的リソースとの間の仮想シーンにおける距離を決定し、距離が視野距離閾値より小さい少なくとも１つのクライアントを第２クライアントとするように構成される。

【0238】

いくつかの実施例において、上記の仮想シーンのデータ処理装置２５５はさらに、複数のクライアントのうち、第１クライアントと同じシングルラウンド対局にアクセスする第２クライアントが存在しない場合、第１クライアントに更新後の動的リソースを送信し、複数のクライアントのうち、第１クライアントと同じシングルラウンド対局にアクセスする少なくとも１つのクライアントが存在し、且つ少なくとも１つのクライアントと第１クライアントの視野範囲が異なる場合、第１クライアントに更新後の動的リソースを送信するように構成される、第１送信モジュールを備える。

【0239】

いくつかの実施例において、分離は物理的分離を含み、上記の分離モジュール２５５５はさらに、第１クライアントの視野範囲内の動的リソースの仮想シーンにおける位置が、第２クライアントの視野範囲内の動的リソースの仮想シーンにおける位置と重なる場合、第１クライアントと第２クライアントにそれぞれ割り当てられた動的リソースマスクに基づいて、第１クライアントと第２クライアントがそれぞれアクセスしたシングルラウンド対局間の関係を決定し、ここで、第１クライアントと第２クライアントは、複数のクライアントのうちのいずれか２つであり、関係が、第１クライアントと第２クライアントがそれぞれアクセスしたシングルラウンド対局が互いに異なるシングルラウンド対局であることを示す場合、第１クライアントと第２クライアントのそれぞれに対応する動的リソースに対して物理的分離を実行するように構成され、ここで、物理的分離は、第１クライアントの視野範囲内の動的リソースおよび第２クライアントの視野範囲内の動的リソースに対して、同じ横軸座標、縦軸座標および垂直軸座標を割り当てるために使用される。

【0240】

いくつかの実施例において、上記の仮想シーンのデータ処理装置２５５はさらに、第１クライアントに対応する物理的分離された動的リソースを第１クライアントに送信し、第２クライアントに対応する物理的分離された動的リソースを第２クライアントに送信するように構成される、第２送信モジュールを備える。

【0241】

いくつかの実施例において、上記の分離モジュール２５５５はさらに、第１クライアントと第２クライアントにそれぞれ割り当てられた動的リソースマスクが同じである場合、第１クライアントと第２クライアントが同じシングルラウンド対局にアクセスしたと決定し、第１クライアントと第２クライアントにそれぞれ割り当てられた動的リソースマスクが異なる場合、第１クライアントと第２クライアントが異なるシングルラウンド対局にアクセスしたと決定するように構成される。

【0242】

いくつかの実施例において、上記の仮想シーンのデータ処理装置２５５はさらに、関係が、第１クライアントと第２クライアントがそれぞれアクセスしたシングルラウンド対局が同じシングルラウンド対局であることを示す場合、第１クライアントの視野範囲内の前記動的リソースおよび第２クライアントの視野範囲内の動的リソースに対して、同じ横軸座標と縦軸座標、および異なる垂直軸座標を割り当てるように構成される、第３割り当てモジュールを備える。

【0243】

いくつかの実施例において、上記の共有モジュール２５５４はさらに、複数のクライアントのうちのいずれか１つのクライアントから送信された静的リソース要求を受信し、ここで、静的リソース要求には、静的リソースマスクが搬送され、静的リソース要求で搬送される静的リソースマスクに基づいて、複数のクライアントのうちの他のクライアントに同じ静的リソースマスクが割り当てられたことが照会され、複数のクライアントが静的リソースを共有していると決定し、複数のクライアントのうちのいずれか１つのクライアントに同じ静的リソースを送信するように構成される。

【0244】

以下では、ソフトウェアモジュールとして実施される、本願実施例による仮想シーンのデータ処理装置２５５の例示的な構造について説明し続ける。いくつかの実施例において、図２Ｂに示すように、メモリ４５０に記憶された仮想シーンのデータ処理装置４５５におけるソフトウェアモジュールは、端末機器の第１クライアントを介して、サーバのサービスプロセスに接続し、サーバから送信された対局開始命令に応答して、サーバが複数のクライアントのために作成した複数のシングルラウンド対局のうちの１つのシングルラウンド対局にアクセスするように構成されるアクセスモジュール４５５１であって、複数のシングルラウンド対局は、サービスプロセスを共有し、サービスプロセスは、仮想シーンの静的リソースと動的リソースを含み、複数のクライアントは第１クライアントを含む、アクセスモジュール４５５１と、サーバが静的リソースに関して送信した静的リソースマスクを受信するように構成される第１受信モジュール４５５２であって、サーバが異なるクライアントに送信した静的リソースマスクは同じである、第１受信モジュール４５５２と、サーバが動的リソースに関して送信した動的リソースマスクを受信するように構成される第２受信モジュール４５５３であって、サーバが、同じシングルラウンド対局にアクセスするクライアントに送信した動的リソースマスクは同じであり、且つ異なるシングルラウンド対局にアクセスするクライアントに送信した動的リソースマスクは異なり、ここで、静的リソースマスクは、複数のシングルラウンド対局間で静的リソースを共有するために使用され、動的リソースマスクは、異なるシングルラウンド対局間で動的リソースを分離するために使用される、第２受信モジュール４５５３と、を含む。

【0245】

いくつかの実施例において、分離は視野的分離を含み、上記の仮想シーンのデータ処理装置４５５はさらに、動的リソース更新要求をサーバに送信するように構成される要求モジュールであって、動的リソース更新要求には、動的リソースに対する第１クライアントの操作情報と、第１クライアントに割り当てられた動的リソースマスクが搬送される、要求モジュールと、サーバから送信された更新後の動的リソースを受信するように構成される第３受信モジュールと、を備え、ここで、サーバは、第１クライアントと同じシングルラウンド対局にアクセスし且つ視野範囲が同じである少なくとも１つのクライアントと、第１クライアントに更新後の動的リソースをそれぞれ送信する。

【0246】

いくつかの実施例において、分離は物理的分離を含み、上記の仮想シーンのデータ処理装置４５５はさらに、サーバによって第１クライアントの視野範囲内の動的リソースに割り当てられた横軸座標、縦軸座標および垂直軸座標を受信するように構成される第４受信モジュールを備え、ここで、第１クライアントの視野範囲内の動的リソースの仮想シーンにおける位置が、第２クライアントの視野範囲内の動的リソースの仮想シーンにおける位置が重なり、且つ第１クライアントと第２クライアントがそれぞれアクセスしたシングルラウンド対局が互いに異なるシングルラウンド対局である場合、サーバは、第１クライアントの視野範囲内の動的リソースおよび第２クライアントの視野範囲内の動的リソースに対して、同じ横軸座標、縦軸座標および垂直軸座標を割り当てる。

【0247】

本願実施例は、コンピュータ可読記憶媒体に記憶されたコンピュータ命令を含む、コンピュータプログラム製品またはコンピュータプログラムを提供する。コンピュータ機器のプロセッサは、コンピュータ可読記憶媒体から当該コンピュータ命令を読み取って実行することによって、当該コンピュータ機器に本願実施例に記載の仮想シーンのデータ処理方法を実行させる。

【0248】

本願の実施例は、実行可能命令が記憶されたコンピュータ可読記憶媒体を提供し、実行可能命令がプロセッサによって実行されるときに、プロセッサに、本願の実施例による仮想シーンのデータ処理方法、例えば、図３Ａに示す仮想シーンのデータ処理方法を実行させる。

【0249】

いくつかの実施例において、コンピュータ可読記憶媒体は、ＦＲＡＭ（登録商標）、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、磁気表面メモリ、光ディスク、またはＣＤ－ＲＯＭなどのメモリであってもよいし、上記のメモリの１つまたは任意の組み合わせを含む様々なデバイスであってもよい。

【0250】

いくつかの実施例において、実行可能命令は、プログラム、ソフトウェア、ソフトウェアモジュール、スクリプトまたはコードの形を採用することができ、任意の形のプログラミング言語（コンパイラ型言語または解釈言語、あるいは宣言形言語または手続き型言語を含む）で記述され、独立したプログラムとして展開されるかまたはモジュール、コンポーネント、サブルーチンまたはコンピューティング環境での使用に適した他のユニットとして展開されるなど、任意の形で展開されてもよい。

【0251】

一例として、実行可能命令は、ファイルシステム内のファイルに対応してもよいが必ずしもそうではなく、他のプログラムまたはデータを保存するファイルの一部に記憶されることができ、例えば、ハイパーテキストマークアップ言語（ＨＴＭＬ：Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ドキュメント内の１つまたは複数のスクリプトに記憶されるか、議論されたプログラムの単一のファイルに記憶されるか、または、複数の共同ファイル（例えば、１つまたは複数のモジュール、サブプログラムまたはコード部分を記憶するファイル）に記憶されてもよい。

【0252】

一例として、実行可能命令は、１つのコンピュータ機器で実行されるように展開されてもよいし、または同じ場所にある複数のコンピュータ機器で実行されるように展開されてもよいし、または、複数の場所に分散し且つ通信ネットワークによって相互接続された複数のコンピュータ機器で実行されるように展開されてもよい。

【0253】

まとめると、本願実施例は、以下の有益な効果を有する。

【0254】

（１）一方では、複数のクライアントを複数のシングルラウンド対局にアクセスさせ、これらの複数のシングルラウンド対局が１つのサービスプロセスを共有することを実現し、それにより、サービスプロセスの数をゲームシングルラウンド対局の数より大幅に小さくし、即ち、サービスプロセスの数を大幅に減少させ、静的リソースによって占有されるメモリのサイズはサービスプロセスの数と正の相関があるため、サービスプロセスの数を大幅に削減することで、静的リソースのメモリ容量の占有量を大幅に減少させることができ、これにより、データ冗長を効果的に減少させることができる。もう一方では、複数のシングルラウンド対局が１つのサービスプロセスを共有するため、異なるシングルラウンド対局のクライアントに、対応する静的リソースマスクと動的リソースマスクを割り当てることにより、複数のシングルラウンド対局間での静的リソースの共有と動的リソースの分離を実現する。このようにして、サーバにおけるデータ冗長を効果的に減少させるとともに、異なるシングルラウンド対局間での動的リソースの分離と静的リソースの共有を実現することができる。

【0255】

（２）対局開始閾値と対局閉鎖閾値を設定することにより、複数のクライアントが複数のシングルラウンド対局にアクセスするとき、各シングルラウンド対局に一定数のクライアントがアクセスするようにし、それにより、複数のクライアントを複数のシングルラウンド対局に接続させることを実現し、複数のクライアントを複数のシングルラウンド対局にアクセスさせ、複数のシングルラウンド対局が１つのサービスプロセスを共有することにより、サービスプロセスの数をゲームシングルラウンド対局の数より大幅に小さくし、即ち、サービスプロセスの数を大幅に減少させ、静的リソースによって占有されるメモリのサイズはサービスプロセスの数と正の相関があるため、サービスプロセスの数を大幅に削減することで、静的リソースのメモリ容量の占有量を大幅に減少させることができ、これにより、サーバにおけるデータ冗長を効果的に減少させることができる。

【0256】

（３）静的リソースに対応する同じ静的リソースマスクを各クライアントに割り当てることにより、サービスプロセスによって各クライアントに送信された静的リソースが同じであるようにし、それにより、異なるシングルラウンド対局間のすべてのクライアントが同じ静的リソースを共有するようにし、静的リソースの冗長ロードを効果的に回避することができる。

【0257】

（４）同じシングルラウンド対局にアクセスするクライアントの動的リソースマスクが同じであるため、第１クライアントに割り当てられた動的リソースマスクに基づいて、第１クライアントと同じ動的リソースマスクを持つターゲットクライアントを決定し、ターゲットクライアントを、第１クライアントと同じシングルラウンド対局にアクセスしたクライアントとして決定することができ、このように、動的リソースマスクを用いて、同じシングルラウンド対局にアクセスしたクライアントを照会することにより、後続での異なるシングルラウンド対局のクライアントの動的リソースの視野的分離と物理的分離が容易になる。

【0258】

（５）視野距離閾値と動的リソース閾値という２つの次元から、第１クライアントと同じシングルラウンド対局にアクセスし且つ視野範囲が同じである少なくとも１つの第２クライアントを決定することで、第１クライアントと第２クライアントとの間で動的リソースを共有し、第１クライアントと、第２クライアント以外のクライアントとの間での動的リソースの分離を実現する。

【0259】

（６）視野距離閾値と動的リソース閾値という２つの次元から、第１クライアントと同じシングルラウンド対局にアクセスし且つ視野範囲が同じである少なくとも１つの第２クライアントを決定し、条件を満たす第２クライアントが存在しない場合、更新後の動的リソースを第１クライアントのみに送信することで、第１クライアントと、第１クライアント以外のクライアントとの間での動的リソースの分離を実現する。

【0260】

（７）第１クライアントの視野範囲内の動的リソースおよび第２クライアントの視野範囲内の動的リソースに、同じ横軸座標、縦軸座標および垂直軸座標を割り当てることにより、第１クライアントの視野範囲内の動的リソースが第２クライアントの視野範囲内の動的リソースと完全に重なるようにして、第１クライアントと第２クライアントのそれぞれに対応する動的リソース間の物理的分離を実現する。

【0261】

上記は、本願の実施例に過ぎず、本願の保護範囲を限定することを意図するものではない。本願の趣旨および範囲内で行われるあらゆる修正、同等置換、改善などは、すべて本願の保護範囲に含まれるものとする。

【図1】

【図2A】

【図2B】

【図3A】

【図3B】

【図3C】

【図3D】

【図3E】

【図3F】

【図3G】

【図4A】

【図4B】

【図4C】

【図4D】

【図5A】

【図5B】

【図5C】

【図5D】

【図5E】

【図5F】

【図5G】

【図5H】

【図5I】

【図5J】

【図5K】

【図5L】

【図5M】

【図5N】

【図5O】

【図5P】

【図5Q】

【図5R】

【図5S】

【国際調査報告】