JP2020502684A - リソース要求処理方法及び装置 - Google Patents

Abstract

本願は、リソース要求処理方法及び装置を開示し、サーバの不十分な演算能力によるスタッタリング問題を軽減させることに用いられる。該方法は、各仮想対象の現在の可視範囲内のインタラクティブ仮想対象の密度に基づいて、アクセスしている仮想対象を複数の密度レベルに分割するステップ（２０１）と、各密度レベルに１つのリソース要求割当額を割り当てるステップ（２０２）と、所定の時間内に、ある密度レベル内の仮想対象により送信されたリソース要求を受信する時、該密度レベルに対応するリソース要求割当額が所定の割当額閾値より大きいか否かを判断するステップ（２０３）と、大きい場合、該リソース要求を処理し、該密度レベルに対応するリソース要求割当額から所定の数値を引くステップ（２０４）と、以下である場合、該リソース要求を拒絶するステップ（２０５）と、を含む。該方法及び装置は、リソース要求割当額が所定の割当額閾値の以下である場合、該密度レベル内の仮想対象により送信されたリソース要求の処理を拒絶し、それにより、ＣＰＵの処理が過荷重にならないので、サーバの不十分な演算能力によるスタッタリング問題を軽減させることができる。

Description

本願は、２０１７年４月１８日に中国特許庁に出願された、出願番号が２０１７１０２５３２５３．３で、発明の名称が「リソース要求処理方法及び装置」である中国特許出願の優先権を主張し、その全文を引用により本願に組み込む。

本願の実施例はゲーム分野に関し、特にリソース要求処理方法及び装置に関する。

大規模多人数同時参加型オンラインロールプレイングゲーム（Ｍａｓｓｉｖｅ Ｍｕｌｔｉｐｌａｙｅｒ Ｏｎｌｉｎｅ Ｒｏｌｅ−Ｐｌａｙｉｎｇ Ｇａｍｅ：ｍｍｏｒｐｇと略称）とは、サーバで実行されている仮想世界で、プレイヤーが１つのキャラクターを演じてユーザーグループを作成し、大規模なユーザーグループのコミュニケーションに参加することができるゲームを指す。

次世代のインタラクティブ性の高いアクションネットワークゲームは、現代のコンピューティングシステムの強力な計算処理能力及びネットワーク伝送能力に基づく大規模多人数同時参加型オンラインロールプレイングゲームであり、それは、高品質の戦闘表現、リズムの速い戦闘体験、複雑な戦闘詳細、及び戦闘過程中のプレイヤー同士の高頻度のインタラクティブ機能をプレイヤーに提供することができる。このようなゲームでは一回の戦闘技能の実施によるコンピューティングシステムの性能オーバーヘッド及びネットワークにおけるラフィック圧力は典型、伝統的なｍｍｏｒｐｇよりも遥かに高い。

次世代のインタラクティブ性の高いアクションネットワークゲームの技能の表現詳細、速い戦闘リズム及び高インタラクティブの流暢さはゲームのコア的な体験及び競争における優位性の１つであり、しかし、技能表現詳細の増加、戦闘リズムの加速、及び高インタラクティブの発生により、サーバのコンピューティングオーバーヘッドが大幅に増加し、それにより、大規模な同時戦闘で、サーバの不十分な演算能力によりスタッタリング問題を引き起こす。

本願の実施例はリソース要求処理方法及び装置を提供し、サーバの不十分な演算能力によるスタッタリング問題を軽減させることができる。

第１態様、本願の実施例はリソース要求処理方法を提供し、該方法は、
各仮想対象の現在の可視範囲内のインタラクティブ仮想対象の密度に基づいて、アクセスしている仮想対象を複数の密度レベルに分割し、密度レベルの高低は仮想対象の密度の大きさに正比例するステップと、
各密度レベルに１つのリソース要求割当額を割り当てるステップであって、各密度レベルに対応するリソース要求割当額は、第１所定の時間内に、許可される、該密度レベル内の仮想対象により送信されたリソース要求を処理する数であるステップと、
第１所定の時間内に、第１密度レベル内の仮想対象により送信されたリソース要求を受信する時、第１密度レベルに対応するリソース要求割当額が所定の割当額閾値より大きいと確定した場合、リソース要求を処理し、第１密度レベルに対応するリソース要求割当額から所定の数値を引き、第１密度レベルに対応するリソース要求割当額が所定の割当額閾値の以下であると確定した場合、リソース要求を拒絶するステップと、を含む。

第２態様、本願の実施例はリソース要求処理装置を提供し、該装置は、１つ又は複数のプロセッサと、プロクラムユニットを記憶する１つ又は複数のメモリとを含み、前記プロセッサにより実行される前記プログラムユニットは、
各仮想対象の現在の可視範囲内のインタラクティブ仮想対象の密度に基づいて、アクセスしている仮想対象を複数の密度レベルに分割するように構成され、密度レベルの高低は仮想対象の密度の大きさに正比例する密度レベル分割ユニットと、
各密度レベルに１つのリソース要求割当額を割り当てるように構成され、各密度レベルに対応するリソース要求割当額は、第１所定の時間内に、許可される、該密度レベル内の仮想対象により送信されたリソース要求を処理する数である割当額割当ユニットと、
第１密度レベル内の仮想対象により送信されたリソース要求を受信するように構成されるリソース要求受信ユニットと、
第１所定の時間内に、受信ユニットが第１密度レベル内の仮想対象により送信されたリソース要求を受信する時、第１密度レベルに対応するリソース要求割当額が所定の割当額閾値より大きいと確定した場合、リソース要求を処理し、第１密度レベルに対応するリソース要求割当額から所定の数値を引き、第１密度レベルに対応するリソース要求割当額が所定の割当額閾値の以下であると確定した場合、リソース要求を拒絶するように構成されるリソース要求処理ユニットと、を含む。

第３態様、本願の実施例は、実行する時に本願の実施例の方法を実行するように構成されるコンピュータプログラムが記憶されている記憶媒体を提供する。

第４態様、本願の実施例は、コンピュータプログラムが記憶されているメモリと、前記コンピュータプログラムによって本願の実施例の方法を実行するように構成されるプロセッサとを含む電子装置を提供する。

以上の技術案から分かるように、本願の実施例は以下の利点を有する。

本願の実施例では、各仮想対象の現在の可視範囲内のインタラクティブ仮想対象の密度に基づいて、アクセスしている仮想対象を複数の密度レベルに分割し、各密度レベルに１つのリソース要求割当額を割り当て、所定の時間内に、ある密度レベル内の仮想対象により送信されたリソース要求を受信する時、該密度レベルに対応するリソース要求割当額が所定の割当額閾値より大きいと確定した場合、受信した該リソース要求を処理し、該密度レベルに対応するリソース要求割当額から所定の数値を引き、前記所定の割当額閾値の以下であると確定した場合、該リソース要求を拒絶する。本願の実施例は仮想対象に対して密度レベルの分割を行い、各密度レベルにリソース要求割当額を割り当て、リソース要求割当額が所定の割当額閾値の以下である場合、該密度レベル内の仮想対象により送信されたリソース要求の処理を拒絶し、それにより、中央処理装置（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ：ＣＰＵと略称）の処理が過荷重にならないので、サーバの不十分な演算能力によるスタッタリング問題を軽減させることができる。

図１は本願の実施例の典型的な次世代のインタラクティブ性の高いアクションネットワークゲームの技能実施ロジック特性の例である。 図２は本願の実施例のリソース要求処理方法のフローチャートである。 図３は本願の実施例の低密度領域におけるプレイヤーの典型的な行動モードの模式図である。 図４は本願の実施例の高密度領域におけるプレイヤーの典型的な行動モードの模式図である。 図５は本願の実施例のリソース要求割当額の割り当て模式図である。 図６は本願の実施例のリソース要求割当額の使用模式図である。 図７は本願の実施例のリソース要求処理装置の機能モジュールの構造模式図である。 図８は本願の実施例のサーバのハードウェアの構造模式図である。 図９は本願の実施例の電子装置のハードウェアの構造模式図である。

以下、図面を参照しながら、本願の実施例をさらに詳細に説明する。

典型的な次世代のインタラクティブ性の高いアクションネットワークゲームの技能実施ロジックは、図１に示される。プレイヤーは時刻Ｔ０に１つの技能ｓｐｅｌｌＡを実施し、該技能は段階１〜段階１５という１５個の段階を有し、しかも目標ｔ１〜目標６０という６０個の目標を命中する。ｂｕｆｆＡが存在し、ｂｕｆｆは、アクティブなエンティティに存在する、一定の時効性を有するインタラクティブデータであり、ｂｕｆｆは仮想世界の時間の経過に伴って変化し、アクティブなエンティティ以外の仮想世界の物体と論理的なインタラクティブが生じる。ｂｕｆｆＡが技能実施者に存在する場合、該ｂｕｆｆによって技能実施者は効果Ａを有し、ｅｆｆｅｃｔＡのロジックについては、１つのｂｕｆｆＢが存在し、時刻Ｔ１の前に、ｓｐｅｌｌＡの段階Ｘに命中された目標に対して、該目標のｂｕｆｆＢの段階Ｂに対応するロジックの実行が完了した場合、ｓｐｅｌｌＡの段階Ｘの後の段階のロジックをｓｐｅｌｌＢのロジックに置き換える。

図１から分かるように、ｍｍｏｒｐｇサーバにおいて、ゲームシーンが変わると、シーン内のプレイヤーの行動が変わり、実行するロジックプロセスが著しく変化する。これにより、ｍｍｏｒｐｇサーバは、性能ホットスポットが転々とする特徴があり、性能ホットスポットが転々とするのは、異なる時間及び実行シーンに、同一ソフトウェアモジュールの性能ホットスポットが変化するという現象を指す。それにより、システムホットスポットがアルゴリズム最適化を行うポリシーを見つけることは困難である。

また、プレイヤー１人の技能実施の計算タスクに対して、時間軸と相関の高い、複数の段階を有するステートマシンであり、各段階の計算は前段階の計算結果に依存する必要があり、それにより、計算依存関係の分解を行いにくい。プレイヤー同士は強いデータ依存性を有するので、データ依存関係の分解を行いにくく、従って、並列化処理を行いにくい。

本願の実施例は、ｍｍｏｒｐｇプレイヤーの多人数の同一スクリーンでの対戦の実際ニーズ及び行動特徴を配慮した上で、プレイヤーの集まり密度分布に基づいて、現行の実際サーバの物理的な性能境界範囲内に、サーバの計算能力分布の特徴を組み合わせて、多人数の同一スクリーンでの戦闘の技能実施遅延をスムーズにし、プレイヤーの全体的な技能スループットを向上させ、サーバに計算能力の雪崩効果が発生するのを防止する。

この雪崩効果とは、サーバの負荷が物理的な限界に達すると、サーバ内部のエラーイベント処理に余計の処理圧力が発生し、それと同時にクライアント側がエラー後の再要求ポリシーの実行を開始することによって、余計の処理要求が発生し、それにより、サーバの実際の処理能力が著しく低下し、スタッタリングの問題が発生することを指す。

いずれにしても物理サーバの性能は一定の時期内に境界があるが、プレイヤーからの同一スクリーンでの戦闘人数のニーズ及び戦闘品質の向上ニーズは上限がなく、また、ｍｍｏｒｐｇ多人数の同一スクリーンでの戦闘アプリケーションシーンの計算モデル特徴により、計算ユニットの数を拡張して全体的な処理能力を直線的に向上させにくいので、サーバはすべての戦闘要求の演算処理作動をリアルタイムで、ロスレスに完了するのを客観的に確保することができない。

しかし、ｍｍｏｒｐｇ多人数の同一スクリーンでの戦闘の製品ニーズは、プレイヤーが体験できる戦闘品質をできるだけ高くすることであり、サーバが実際に成功に処理できる戦闘効果の数をできるだけ高くするわけではない。プレイヤーの生物学的反応時間及び特に複雑なシーンにおける情報に対する選択性無視という生理学的特徴があるので、プレイヤーの実際の体験を確保する前提で、サーバの実際の演算負荷を大幅に低減させることができる。

図２は本願の実施例のリソース要求処理方法のフローチャートである。

ゲーム過程で、各プレイヤーは対応する可視範囲を有し、可視範囲は、プレイヤーの現在の画面、即ち、ゲームアプリケーションプログラムにより提供されるプレイヤーの全体地図で所在する領域として理解できる。

可視範囲内のプレイヤーの数が少ない場合、プレイヤーは低密度領域に位置し、このとき、プレイヤーは力量が伯仲している１人又は少数の敵と対戦し、プレイヤーの典型的な行動モードは図３に示され、プレイヤーにより行われたすべての攻撃は対応するフィードバックを受けることができる。このプレイヤーの行動モード下で、プレイヤーはリアルタイムの戦闘フィードバック及び時間軸に非常に敏感で、アップリンク要求の頻度も比較的低頻度で戦略的である。プレイヤーは、攻撃を決定してから、目標対象を攻撃し、目標対象が攻撃を受けるたびに、非常に敏感であり、毎回の攻撃のフィードバックに関心を持っている。

可視範囲内のプレイヤーの数（画面内の敵の数）が数百レベルに達する場合、プレイヤーは高密度領域に位置し、プレイヤーの行動モード及び関心点は著しく変化し、プレイヤーの行動モードは図４に示されるものになり、プレイヤーからの攻撃が受信するフィードバックより多くなる。

人体が短時間内に大量の情報を処理できないので、実際には、高密度領域に位置するプレイヤーは、リアルタイムの精確な論理立つ戦闘フィードバック及び時間軸に敏感ではなく、また、プレイヤーは高頻度で要求を繰り返し送信するため、１つの要求がタイムリーに応答されたか否かを判別することができず、従って、毎回の攻撃のフィードバックに注目しない。

また、サーバの処理演算という観点からいうと、１つの技能が処理する必要がある演算負荷は、技能が攻撃できる目標の数の増加に伴って増加する。従って、密集した群集に位置するプレイヤーが実施する技能は、疎な群集に位置するプレイヤーが実施する同じ技能より、性能オーバーヘッドがはるかに高くなる。

以上の低密度領域のプレイヤー及び高密度領域のプレイヤーの特性に基づいて、本願の実施例は以下の処理を行う。

２０１において、各仮想対象の現在の可視範囲内のインタラクティブ仮想対象の密度に基づいて、アクセスしている仮想対象を複数の密度レベルに分割する。

本願の実施例の仮想対象とは、ゲームアプリケーションプログラムに仮想する対象を指し、ゲーム仮想世界のアクティブなエンティティであり、各仮想対象はゲームアプリケーションプログラムの１つの登録ユーザーに対応し、即ち、１つのプレイヤーに対応する。

アクセスしている仮想対象を複数の密度レベルに分割する過程は、具体的には、

各仮想対象の現在の可視範囲内のインタラクティブ仮想対象の密度を取得し、密度が同一の数値区間に属する仮想対象を同一の密度レベルに分割する。

即ち、各仮想対象に対して、該仮想対象のゲームアプリケーションプログラムにより提供される地図での位置を取得し、その位置に基づいて該仮想対象の可視範囲を取得し、該仮想対象の可視範囲は、該プレイヤーが現在の画面で見える領域である。該領域内のインタラクティブ仮想対象の総数を計算し、ここでのインタラクティブ仮想対象は、該仮想対象の可視範囲内の該仮想対象以外の他の仮想対象であり、即ち、該仮想対象に対応するプレイヤーの現在の画面内の敵の数を計算し、具体的には、仮想対象がブロードキャストイベントを生成することにより周囲のインタラクティブ仮想対象の数を取得する。

その後、総数が同一の数値区間に属する仮想対象を同一の密度レベルに分割する。数値区間は、所定の数値区間であってもよく、現在のオンライン仮想対象の総数に基づいてリアルタイムに設定されてもよい。

例えば、３つの数値区間が予め設定されるとされ、それぞれ、［１−２０］、［２１−１００］及び［１０１−∞］であり、それぞれ対応する密度レベルはレベル１（低密度レベル）、レベル２（中密度レベル）及びレベル３（高密度レベル）であり、密度レベルの高低は仮想対象の密度の大きさに正比例する。

例えば、仮想対象１の現在の可視範囲内のインタラクティブ仮想対象の総数は１０で、仮想対象２の現在の可視範囲内のインタラクティブ仮想対象の総数は５で、仮想対象３の現在の可視範囲内のインタラクティブ仮想対象の総数は２００で、仮想対象４の現在の可視範囲内のインタラクティブ仮想対象の総数は３０で、仮想対象５の現在の可視範囲内のインタラクティブ仮想対象の総数は６０であるとされる。仮想対象１及び仮想対象２は数値区間［１−２０］に属し、密度レベル１に分割され、仮想対象４及び仮想対象５は数値区間［２１−１００］に属し、密度レベル２に分割され、仮想対象３は数値区間［１０１−∞］に属し、密度レベル３に分割される。

ゲームアプリケーションプログラムのオンライン仮想対象はＭ個の密度レベルに分割され、密度レベルｍに位置する仮想対象はＡＣＴＯＲｍと記される。例えば、密度レベル１、密度レベル２、密度レベル３、密度レベル４に位置する仮想対象はそれぞれＡＣＴＯＲｍ１、ＡＣＴＯＲｍ２、ＡＣＴＯＲｍ３、ＡＣＴＯＲｍ４と記される。

各仮想対象が分割された密度レベルは、仮想対象の位置する領域のインタラクティブ仮想対象の密集度に伴ってリアルタイムに変化する。

２０２、各密度レベルに１つのリソース要求割当額を割り当てる。

本願の実施例のリソース要求は、仮想対象がゲーム過程でサーバに送信するゲーム技能要求であってもよい。仮想対象がサーバにゲーム技能要求を送信するのは、ゲーム技能を実施するためであり、ゲーム技能とは、ネットワークゲームの仮想世界の仮想対象の行動モードを指し、仮想対象は技能を実施することにより、自分及び目標に対して一連の効果を発生させることができる。

また、本願の実施例のリソース要求は、仮想対象がゲーム過程でサーバに送信するゲームゲイン要求等の他の要求であってもよく、例えば、道具を用い、地図に表示するゲイン効果を取得する。

ゲームアプリケーションプログラムのオンライン仮想対象をＭ個の密度レベルに分割した後、各密度レベルに１つの初期リソース要求割当額を割り当てる。各密度レベルに対応する初期リソース要求割当額は、第１所定の時間ｔ内に、許可される、該密度レベル内の仮想対象により送信されたリソース要求を処理する数であり、即ち、同一の密度レベル内の仮想対象は、第１所定の時間ｔ内に、１つのリソース要求割当額を共有する。

図５に示すように、密度レベルＡＣＴＯＲｍ１、ＡＣＴＯＲｍ２、ＡＣＴＯＲｍ３、ＡＣＴＯＲｍ４にそれぞれ割り当てられる初期リソース要求割当額は、Ｎ１、Ｎ２、Ｎ３、Ｎ４である。Ｎ１＝５００である場合、許可されるＡＣＴＯＲｍ１内の仮想対象がサーバに送信するリソース要求の数が５００回であると示される。

なお、各密度レベルに同じ初期リソース要求割当額を割り当てもよく、例えば、Ｎ１、Ｎ２、Ｎ３、Ｎ４の数値は同じであってもよい。

好ましくは、各密度レベルに初期リソース要求割当額を割り当てる時、具体的には、サーバＣＰＵの現在の負荷（即ち、ＣＰＵの使用率）に基づいて割り当て、リソース要求割当額の大きさはＣＰＵの現在の負荷と反比例し、ＣＰＵの負荷の向上に伴って、リソース要求割当額が徐々に低減する。ＣＰＵの現在の負荷が高い場合、各密度レベルに割り当てられるリソース要求割当額は小さく、ＣＰＵの現在の負荷が低い場合、各密度レベルに割り当てられるリソース要求割当額は大きい。

従って、ＣＰＵの負荷の向上に伴って、全体的な性能オーバーヘッドをより大幅に低減させる。ＣＰＵの負荷が非常に高く、所定の過負荷閾値を超える時、例えば、ＣＰＵの使用率が９０％を超える時、リソース要求割当額を大幅に低減させ、それにより、雪崩の発生による後続体験の連続性の劣化を防止する。

図５を参照し、例えば、毎回初期に割り当てられるリソース要求割当額Ｎ１、Ｎ２、Ｎ３、Ｎ４の数値は同じであるとされる。ＣＰＵの使用率が０％−３０％である場合、Ｎ１、Ｎ２、Ｎ３、Ｎ４はそれぞれ５００回に設定され、ＣＰＵの使用率が３１−６０％である場合、Ｎ１、Ｎ２、Ｎ３、Ｎ４はそれぞれ４００回に設定され、ＣＰＵの使用率が６１％−９０％である場合、Ｎ１、Ｎ２、Ｎ３、Ｎ４はそれぞれ３００回に設定され、ＣＰＵの使用率が９１％−１００％である場合、Ｎ１、Ｎ２、Ｎ３、Ｎ４はそれぞれ１００回に設定される。

サーバがある密度レベル内の仮想キャラクターにより送信されたリソース要求を処理すると、該密度レベルに対応するリソース要求割当額から所定の数値を引く。

好ましくは、所定の数値は１である。

２０３、第１所定の時間内に、第１密度レベル内の仮想対象により送信されたリソース要求を受信する時、第１密度レベルに対応するリソース要求割当額が所定の割当額閾値より大きいか否かを判断する。

本願の実施例の第１密度レベルは分割された複数の密度レベルのうちのある密度レベルである。

第１密度レベル内の仮想キャラクターにより送信されたリソース要求を受信する時、先ず第１密度レベルに対応するリソース要求割当額が所定の割当額閾値より大きいか否かを判断し、該所定の割当額閾値は０であってもよい。

所定の割当額閾値より大きい場合、ステップ２０４を実行し、所定の割当額閾値より小さい場合、ステップ２０５を実行する。

２０４、第１密度レベルに対応するリソース要求割当額が所定の割当額閾値より大きい場合、リソース要求を処理し、第１密度レベルに対応するリソース要求割当額から所定の数値を引く。

所定の割当額閾値より大きい場合、受信した第１密度レベル内の仮想キャラクターにより送信されたリソース要求を処理し、該密度レベルに対応するリソース要求割当額から所定の数値、例えば、１を引く。

２０５、第１密度レベルに対応するリソース要求割当額が所定の割当額閾値の以下である場合、リソース要求を拒絶する。

第１密度レベル内の仮想キャラクターにより送信されたリソース要求を処理するたびに、該密度レベルに対応するリソース要求割当額から所定の数値を引き、第１密度レベルに対応するリソース要求割当額が所定の割当額閾値の以下となる場合、該密度レベルに対応するリソース要求割当額が使い果たされたか、又は最低値に達したため、リソース要求を処理できなくなると示し、それで、受信した第１密度レベル内の仮想キャラクターにより送信されたリソース要求を拒絶する。

好ましくは、上記ステップ２０３で、第１所定の時間内に、第１密度レベル内の仮想対象により送信されたリソース要求を受信する時、

前記第１密度レベルに対応するリソース要求割当額が前記所定の割当額閾値より大きいと確定した場合、前記リソース要求を処理し、前記第１密度レベルに対応するリソース要求割当額から所定の数値を引き、

前記第１密度レベルに対応するリソース要求割当額が前記所定の割当額閾値の以下であると確定した場合、前記リソース要求を拒絶するという操作を直接実行してもよい。

本願の実施例は仮想対象に対して密度レベルの分割を行い、各密度レベルにリソース要求割当額を割り当て、リソース要求割当額が所定の割当額閾値の以下である場合、該密度レベル内の仮想対象により送信されたリソース要求の処理を拒絶し、それにより、ＣＰＵの処理が過荷重にならないので、サーバの不十分な演算能力によるスタッタリング問題を軽減させることができる。

さらに、低密度領域（即ち、密度レベルが低い）のプレイヤーの技能の精度要求が高いため、体験に対する感度も高い。同時に、低密度領域におけるプレイヤーが実施する技能は命中する目標の数が少なく、技能自体のオーバーヘッドも小さく、従って、本願の実施例はリソース要求を低密度領域のプレイヤーに優先的に割り当て、それにより、物理的リソースが限られる場合、体験に敏感なプレイヤーのリソース要求を優先的に確保する。

従って、第１密度レベル内の仮想キャラクターのリソース要求割当額が所定の割当額閾値より小さい場合、第１密度レベルより高い密度レベルのリソース要求割当額を用いることができる。

このとき、第１所定の時間ｔ内に、第１密度レベル内の仮想対象により送信されたリソース要求を受信する時、先ず第１密度レベルに対応するリソース要求割当額が所定の割当額閾値より大きいか否かを判断し、大きくない場合、即ち、所定の割当額閾値の以下である場合、密度レベルが第１密度レベルより高い他の密度レベルのそれぞれに対応するリソース要求割当額がいずれも所定の割当額閾値より小さいか否かを判断し続け、いずれも小さい場合のみ、受信した該リソース要求を拒絶する。

密度レベルが第１密度レベルより高いある密度レベル（第２密度レベル）には使用可能なリソース要求割当額がある場合、即ち、第２密度レベルに対応するリソース要求割当額が所定の割当額閾値より大きい場合、第２密度レベルのリソース要求割当額を用いて該リソース要求を処理し、第２密度レベルに対応するリソース要求割当額から所定の数値を引く。

好ましくは、第１密度レベル内の仮想対象により送信されたリソース要求を受信する時、第１密度レベルに対応するリソース要求割当額が所定の割当額閾値の以下であると確定し、且つ密度レベルが前記第１密度レベルより高い他の密度レベルのそれぞれに対応するリソース要求割当額がいずれも前記所定の割当額閾値より小さいと確定した場合、該リソース要求を拒絶する。

好ましくは、自体の密度レベルより高い他の密度レベルのリソース要求割当額を用いる時、先ず自体の密度レベルより１つのレベル高い密度レベルのリソース要求割当額を取得し、使用可能なリソース要求割当額がある（即ち、該密度レベルに対応するリソース要求割当額が所定の割当額閾値より大きい）場合、それを用い、ない場合、自体の密度レベルより２つのレベル高い密度レベルのリソース要求割当額を取得し続け、使用可能なリソース要求割当額がある場合、それを用い、ない場合、次のより高い密度レベルに使用可能なリソース要求割当額があるか否かを判断し続ける。

図６に示すように、ｍ１＜ｍ２＜ｍ３＜ｍ４とされると、ＡＣＴＯＲｍ１はＡＣＴＯＲｍ２、ＡＣＴＯＲｍ３、ＡＣＴＯＲｍ４のリソース要求割当額を用い、ＡＣＴＯＲｍ２はＡＣＴＯＲｍ３、ＡＣＴＯＲｍ４のリソース要求割当額を用い、ＡＣＴＯＲｍ３はＡＣＴＯＲｍ４のリソース要求割当額を用いることができる。

例えば、所定の割当額閾値が０で、リソース要求が技能要求で、技能要求を１回処理するたびに引く所定の数値が１であるとされる。ＡＣＴＯＲｍ１に対応するＮ１が０より大きい場合、ＡＣＴＯＲｍ１内のプレイヤーの技能要求を受信する時、該技能要求を処理し、Ｎ１から１を引く。Ｎ１が０となる場合、ＡＣＴＯＲｍ１内のプレイヤーの技能要求を受信する時、ＡＣＴＯＲｍ２に対応するＮ２が０より大きいか否かを判断し、０より大きいと、受信したＡＣＴＯＲｍ１内のプレイヤーの該技能要求を処理し、０より小さいと、ＡＣＴＯＲｍ３に対応するＮ３が０より大きいか否かを判断する……。順に処理し、ＡＣＴＯＲｍ２、ＡＣＴＯＲｍ３、ＡＣＴＯＲｍ４のそれぞれに対応するＮ２、Ｎ３、Ｎ４がいずれも０に等しい場合、該技能要求を拒絶する。

このような低密度レベルのプレイヤーが高密度レベルのプレイヤーのリソース要求割当額を用いる方式によって、物理的リソースが限られる場合、体験に敏感なプレイヤーの技能実施を優先的に確保することができる。同時に、このようにして、平均の観点からは、サーバが処理できる技能要求の数は多い。

また、第１所定の時間ｔを経過した後、各密度レベルに１つのリソース要求割当額を改めて割り当てる。該第１所定の時間ｔは、サーバの演算能力及びゲームアプリケーションプログラム自体の技能頻度設計に基づいて調整できる。

好ましくは、多い追加の性能オーバーヘッドを発生させない前提下で、第１所定の時間ｔをできるだけ短くする。このように、参加率の高いプレイヤーにとって、大規模な混戦時のボタン押し頻度も高く、図３に対応すると、攻撃線の密度が高い。初期リソース要求割当額のリフレッシュ頻度が高いと、参加率の高いプレイヤーがリソース要求フィードバックを得る確率は参加率の低いプレイヤーより大きくなり、それにより、物理的リソースが限られる場合、リソースを参加率の高いプレイヤーにできるだけ割り当てるという目的を達成する。

ゲームアプリケーションプログラムでは、ゲーム技能は連続攻撃技能を含み、連続攻撃技能とは、アクションゲームにおいて仮想対象が複数の技能を組み合わせて連続的に実施する行動モードを指し、速度が高く、さわやかなゲーム体験をもたらすことができる。

確率の問題のため、一部の仮想キャラクターが第２所定の時間内にリソース要求のフィードバックを取得できない場合、連続技能の実施が中断してしまう。

従って、本願の実施例はタイムアウト保護方法を増加する。目標仮想対象により第２所定の時間内に送信されたリソース要求がいずれも拒絶されたと検出した場合、前記目標仮想対象により送信されたリソース要求を次回受信する時、前記目標仮想対象により送信された該リソース要求を処理する。

リソース要求が技能要求である場合、あるプレイヤーが第２所定の時間Ｔ内に技能実施要求を取得しないと、該プレイヤーの体験に影響を与えないように、該プレイヤーに１つの技能実施要求割当額を直接割り当てる。

ＣＰＵの負荷が所定の負荷閾値より小さい場合、該所定の負荷閾値は、ＣＰＵの負荷が過負荷から遠く離れることを示し、例えば、該所定の負荷閾値が２０％とされ、ＣＰＵの負荷が２０％より小さい場合、第２所定の時間Ｔを、予め設定された、許可される連続２回リソース要求送信の間隔時間より小さく設定する。

リソース要求が技能要求である場合、リソース要求が連続して２回送信されることを許可する該所定の間隔時間は、ゲームの通常の連続技能実施の間隔時間であり、それにより、プレイヤーは連続攻撃技能を実施でき、連続的な基本ゲーム体験を確保する。

ＣＰＵの負荷が過負荷ラインに接近し又は達する場合、瞬間に第２所定の時間Ｔの値を大幅に向上させ、雪崩効果の発生を防止し、できるだけ短時間内にサーバを低い負荷状態に回復させ、それにより、プレイヤーの体験に影響を与える時間を短くし、長時間のスタッタリング状況の発生を回避する。

以上の技術案から分かるように、

一方では、本願の実施例は、プレイヤーの集まり密度分布及び密度分布のないプレイヤーの行動特徴に基づいて、ＣＰＵの計算能力分布の特徴を組み合わせて、多人数の同一スクリーンでの戦闘の技能実施遅延をスムーズにし、プレイヤーの全体的な技能スループットを向上させる。

他方では、本願の実施例は、プレイヤーの混戦時の行動特徴に基づいて、低密度レベル内のプレイヤーが高密度レベル内のプレイヤーの技能要求割当額を用いる方式によって、高体験感度のプレイヤーの技能実施を適応的に優先し、それにより、プレイヤー群集の全体的なゲーム体験を大幅に向上させる。

さらに、本願の実施例は、第１所定の時間ｔのリフレッシュ頻度を向上させることによって、技能割当額を高頻度で動的に割り当てることができ、それにより、参加率の高いプレイヤーの体験を適応的で優先的に確保することができ、ボタン押し頻度の高い高参加率のプレイヤーが技能要求割当額をより高い確率で用い、それにより参加率の高いプレイヤーの体験を優先的に確保することができる。

また、本願の実施例は、長時間に技能要求割当額を取得できないプレイヤーに技能要求割当額を直接割り当てることができ、それにより、プレイヤーの基本的なゲーム体験を確保することができる。

以上、本願の実施例のリソース要求処理方法を説明したが、以下、機能モジュールの観点から本願の実施例のリソース要求処理装置を説明する。

本願の実施例のリソース要求処理装置は、具体的には上記図２〜図６に説明された方法実施例の機能を実現する。前記機能はハードウェアにより実現されてもよく、ハードウェアが対応するソフトウェアプログラムを実行することにより実現されてもよい。ハードウェア及びソフトウェアは上記機能に対応する１つ又は複数のユニットモジュールを含み、前記ユニットモジュールはソフトウェア及び／又はハードウェアであってもよい。好ましくは、本願の実施例のリソース要求処理装置は１つ又は複数のプロセッサと、プロクラムユニットを記憶する１つ又は複数のメモリとを含み、プロセッサにより実行されるプログラムユニットは、密度レベル分割ユニット、割当額割当ユニット、リソース要求受信ユニット、リソース要求処理ユニットを含む。

図７に示すように、本願の実施例のリソース要求処理装置は、
各仮想対象の現在の可視範囲内のインタラクティブ仮想対象の密度に基づいて、アクセスしている仮想対象を複数の密度レベルに分割するように構成され、密度レベルの高低は仮想対象の密度の大きさに正比例する密度レベル分割ユニット７０１と、
各密度レベルに１つのリソース要求割当額を割り当てるように構成され、各密度レベルに対応するリソース要求割当額は、第１所定の時間内に、許可される、該密度レベル内の仮想対象により送信されたリソース要求を処理する数である割当額割当ユニット７０２と、
第１密度レベル内の仮想対象により送信されたリソース要求を受信するように構成されるリソース要求受信ユニット７０３と、
第１所定の時間内に、前記受信ユニットが第１密度レベル内の仮想対象により送信されたリソース要求を受信する時、前記第１密度レベルに対応するリソース要求割当額が所定の割当額閾値より大きいか否かを判断し、前記第１密度レベルに対応するリソース要求割当額が前記所定の割当額閾値より大きい場合、前記リソース要求を処理し、前記第１密度レベルに対応するリソース要求割当額から所定の数値を引き、前記第１密度レベルに対応するリソース要求割当額が前記所定の割当額閾値の以下である場合、前記リソース要求を拒絶するように構成されるリソース要求処理ユニット７０４と、を含む。

好ましくは、上記リソース要求処理ユニット７０４はさらに、第１所定の時間内に、前記受信ユニットが第１密度レベル内の仮想対象により送信されたリソース要求を受信する時、前記第１密度レベルに対応するリソース要求割当額が前記所定の割当額閾値より大きいと確定した場合、前記リソース要求を処理し、前記第１密度レベルに対応するリソース要求割当額から所定の数値を引き、前記第１密度レベルに対応するリソース要求割当額が前記所定の割当額閾値の以下であると確定した場合、前記リソース要求を拒絶するように構成される。

いくつかの具体的な実施例では、リソース要求処理ユニット７０４はさらに、第１密度レベルに対応するリソース要求割当額が所定の割当額閾値の以下である場合、密度レベルが第１密度レベルより高い他の密度レベルのそれぞれに対応するリソース要求割当額がいずれも所定の割当額閾値より小さいか否かを判断し、いずれも小さい場合、リソース要求を拒絶するように構成される。

好ましくは、上記要求処理ユニット７０４はさらに、第１密度レベルに対応するリソース要求割当額が所定の割当額閾値の以下であり、且つ密度レベルが第１密度レベルより高い他の密度レベルのそれぞれに対応するリソース要求割当額がいずれも所定の割当額閾値より小さいと確定した場合、リソース要求を拒絶するように構成される。

いくつかの具体的な実施例では、リソース要求処理ユニット７０４はさらに、密度レベルが第１密度レベルより高い第２密度レベルに対応するリソース要求割当額が所定の割当額閾値より大きい場合、リソース要求を処理し、第２密度レベルに対応するリソース要求割当額から所定の数値を引くように構成される。

いくつかの具体的な実施例では、割当額割当ユニット７０２は、具体的には、ＣＰＵの現在の負荷に基づいて各密度レベルに１つのリソース要求割当額を割り当てるように構成され、リソース要求割当額の大きさはＣＰＵの現在の負荷の大きさと反比例する。

いくつかの具体的な実施例では、割当額割当ユニット７０２はさらに、第１所定の時間を経過した後、各密度レベルに１つのリソース要求割当額を改めて割り当てるように構成される。

いくつかの具体的な実施例では、リソース要求処理ユニット７０４はさらに、目標仮想対象により第２所定の時間内に送信されたリソース要求がいずれも拒絶されたと検出した場合、目標仮想対象により送信されたリソース要求を次回受信する時、目標仮想対象により送信された該リソース要求を処理するように構成される。

いくつかの具体的な実施例では、上記リソース要求処理装置は、ＣＰＵの負荷が所定の負荷閾値より小さい場合、第２所定の時間を、予め設定された、許可される連続２回リソース要求送信の間隔時間より小さく設定するように構成される設定ユニット７０５をさらに含む。

いくつかの具体的な実施例では、密度レベル分割ユニット７０１は、具体的には、各仮想対象の現在の可視範囲内のインタラクティブ仮想対象の密度を取得し、密度が同一の数値区間に属する仮想対象を同一の密度レベルに分割するように構成される。

図７に示される各機能ユニット間の情報インタラクティブは図２〜図６に説明された方法実施例を参照し、該リソース要求処理装置が問題を解決する実施形態及び有益な効果は上記図２〜図６に説明された方法実施例及び有益な効果を参照することができるので、ここで繰り返し説明しない。

実際の応用に、図７に示されるリソース要求処理装置が有する機能はサーバのプロセッサにより実行され得る。

図８は本願の実施例に係るサーバの構造模式図であり、該サーバ８００は、異なる構成又は性能により、大きく異なる可能性があり、１つ以上の中央処理装置（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔｓ：ＣＰＵと略称）８２２（例えば、１つ以上のプロセッサ）と、メモリ８３０とを含む。メモリ８３０には、１つ以上のアプリケーションプログラム８４２、データ８４４及び１つ以上のオペレーティングシステム８４１が記憶され、メモリ８３０に記憶されたプログラムは１つ以上のモジュール（図示せず）を含み、各モジュールはサーバに対する一連の命令操作を含む。好ましくは、メモリ８３０にはゲームアプリケーションプログラムが記憶されている。

中央処理装置８２２は、メモリ８３０と通信し、サーバ８００でメモリ８３０の一連の命令操作を実行する。好ましくは、中央処理装置８２２は前記メモリ８３０に記憶されているゲームアプリケーションプログラムを呼び出して上記図２〜図６に説明された技術案を実現する。

オペレーティングシステム８４１は、例えばＷｉｎｄｏｗｓ Ｓｅｒｖｅｒ(登録商標)、Ｍａｃ ＯＳ Ｘ(登録商標)、Ｕｎｉｘ(登録商標)、Ｌｉｎｕｘ(登録商標)、ＦｒｅｅＢＳＤ(登録商標)等々が挙げられる。

サーバ８００は、１つ以上の電源８２６、１つ以上の有線又は無線ネットワークインタフェース８５０、１つ以上の入出力インタフェース８５８をさらに含む。

本願の実施例の別の態様によれば、上記リソース要求処理方法を実行するための電子装置をさらに提供し、図９に示すように、該電子装置は、１つ又は複数（図９に１つのみが示されている）のプロセッサ９０１、メモリ９０３、及び伝送装置９０５を含み、図９に示すように、該電子装置は入出力装置９０７をさらに含む。

メモリ９０３は、本願の実施例のリソース要求処理方法及び装置に対応するプログラム命令／モジュールなどのコンピュータプログラム及びモジュールを記憶するように構成され、プロセッサ９０１は、メモリ９０３内に記憶されたソフトウェアプログラム及びモジュールを実行することにより、各種の機能アプリケーション及びデータ処理を実行し、即ち、上記データロード方法を実現するように構成される。メモリ９０３は、高速ランダムアクセスメモリを含んでもよく、１つ又は複数の磁気記憶装置、フラッシュメモリ、又は他の不揮発性固体メモリなどの不揮発性メモリを含んでもよい。いくつかの実例で、メモリ９０３は、ネットワークを介して端末に接続できる、プロセッサ９０１に対して遠隔に構成されるメモリをさらに含む。上記ネットワークの実例は、インターネット、イントラネット、ローカルエリアネットワーク、移動体通信ネットワーク及びそれらの組み合わせを含むが、それらに限定されない。

上記伝送装置９０５は、ネットワークを介してデータを送受信するように構成され、さらにプロセッサとメモリとのデータ伝送を行うように構成される。上記ネットワークの具体的な実例は有線ネットワーク及び無線ネットワークを含む。一実例では、伝送装置９０５は、ネットワークケーブルを介して他のネットワーク装置及びルータに接続されることによりインターネット又はローカルエリアネットワークと通信できるネットワークアダプタ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃｏｎｔｒｏｌｌｅｒ：ＮＩＣと略称）を含む。一実例では、伝送装置９０５は、無線方式でインターネットと通信するように構成される無線周波数（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ：ＲＦと略称）モジュールである。

好ましくは、メモリ９０３は、アプリケーションプログラムを記憶するように構成される。

プロセッサ９０１は、伝送装置９０５によってメモリ９０３に記憶されたアプリケーションプログラムを呼び出すことができる。プロセッサ９０１は、各仮想対象の現在の可視範囲内のインタラクティブ仮想対象の密度に基づいて、アクセスしている仮想対象を複数の密度レベルに分割し、密度レベルの高低は仮想対象の密度の大きさに正比例するステップと、各密度レベルに１つのリソース要求割当額を割り当てるステップであって、各密度レベルに対応するリソース要求割当額は、第１所定の時間内に、許可される、該密度レベル内の仮想対象により送信されたリソース要求を処理する数であるステップと、前記第１所定の時間内に、第１密度レベル内の仮想対象により送信されたリソース要求を受信する時、且つ前記第１密度レベルに対応するリソース要求割当額が前記所定の割当額閾値より大きいと確定した場合、前記リソース要求を処理し、前記第１密度レベルに対応するリソース要求割当額から所定の数値を引き、前記第１密度レベルに対応するリソース要求割当額が前記所定の割当額閾値の以下であると確定した場合、前記リソース要求を拒絶するステップと、を実行する。

プロセッサ９０１はさらに、前記第１密度レベルに対応するリソース要求割当額が前記所定の割当額閾値の以下であり、且つ密度レベルが前記第１密度レベルより高い他の密度レベルのそれぞれに対応するリソース要求割当額がいずれも前記所定の割当額閾値より小さいと確定した場合、前記リソース要求を拒絶するステップを実行するように構成される。

プロセッサ９０１はさらに、密度レベルが前記第１密度レベルより高い第２密度レベルに対応するリソース要求割当額が前記所定の割当額閾値より大きい場合、前記リソース要求を処理し、前記第２密度レベルに対応するリソース要求割当額から前記所定の数値を引くステップを実行するように構成される。

プロセッサ９０１はさらに、ＣＰＵの現在の負荷に基づいて各密度レベルに１つのリソース要求割当額を割り当て、前記リソース要求割当額の大きさは前記ＣＰＵの現在の負荷の大きさと反比例するステップを実行するように構成される。

プロセッサ９０１はさらに、前記第１所定の時間を経過した後、各密度レベルに１つのリソース要求割当額を改めて割り当てるステップを実行するように構成される。

プロセッサ９０１はさらに、目標仮想対象により第２所定の時間内に送信されたリソース要求がいずれも拒絶されたと検出した場合、前記目標仮想対象により送信されたリソース要求を次回受信する時、前記目標仮想対象により送信された該リソース要求を処理するステップを実行するように構成される。

プロセッサ９０１はさらに、ＣＰＵの負荷が所定の負荷閾値より小さい場合、前記第２所定の時間を、予め設定された、許可される連続２回リソース要求送信の間隔時間より小さく設定するステップを実行するように構成される。

プロセッサ９０１はさらに、各仮想対象の現在の可視範囲内のインタラクティブ仮想対象の密度を取得するステップと、密度が同一の数値区間に属する仮想対象を同一の密度レベルに分割するステップとを実行するように構成される。

当業者であれば以下のことを理解することができる。図９に示される構造は例示であり、電子装置はスマートフォン（例えば、Ａｎｄｒｏｉｄ(登録商標)携帯電話、ｉＯＳ携帯電話等）、タブレットパソコン、パームトップパソコン及びモバイルインターネット装置（Ｍｏｂｉｌｅ Ｉｎｔｅｒｎｅｔ Ｄｅｖｉｃｅｓ：ＭＩＤと略称）、ＰＡＤ等の端末装置であってもよい。図９は上記電子装置の構造を限定しない。例えば、電子装置は図９に示されるものより多く又は少ない構成要素（例えば、ネットワークインタフェース、表示装置等）を含んでもよく、又は図９に示されるものと異なる構成を有してもよい。

当業者は、説明の便宜及び簡潔さのために、上記説明されたシステム、装置及びユニットの具体的な作動過程が、前述の方法実施例における対応する過程を参照することができ、ここで繰り返し説明しないことを明確に理解できる。

本願のいくつかの実施例では、開示されたシステム、装置及び方法は、他の方式で実現されてもよいことを理解されるべきである。例えば、上記説明された装置実施例は例示的なものに過ぎず、例えば、前記ユニットの分割は、ロジック機能の分割だけであり、実際の実現時に別の分割方法を有してもよく、例えば、複数のユニット又は構成要素を組み合わせてもよく、又は別のシステムに集積してもよく、又は一部の特徴を無視してもよく、又は実行しなくてもよい。また、図示又は検討される相互結合又は直接結合又は通信接続は、あるインタフェース、装置又はユニットを介した間接結合又は通信接続であってもよく、電気的、機械的又は他の形態のものであってもよい。

前記別々の部材として説明されるユニットは、物理的に分離されてもよく、物理的に分離されなくてもよく、ユニットとして示される部材は、物理ユニットであってもよく、物理ユニットでなくてもよく、即ち、１つの場所に位置してもよく、又は複数のネットワークユニットに分布してもよい。実際の需要に応じてそのうちの一部又は全部ユニットを選択して本実施例の技術案の目的を実現することができる。

また、本願の各実施例における各機能ユニットは１つの処理ユニットに集積されてもよく、各ユニットは単独で物理的に存在してもよく、２つ以上のユニットは１つのユニットに集積されてもよい。上記集成されるユニットはハードウェアの形態で実現されてもよく、ソフトウェア機能ユニットの形態で実現されてもよい。

前記集成されるユニットは、ソフトウェア機能ユニットの形態で実現され、独立した製品として販売又は使用される場合、コンピュータ可読記憶媒体に記憶されることができる。このような理解に基づき、本願の技術案、又は従来技術に寄与する部分、又は当該技術案の全部又は一部は、ソフトウェア製品の形態で実施することができ、当該コンピュータソフトウェア製品は１つの記憶媒体に記憶され、コンピュータ装置（パーソナルコンピュータ、サーバ、又はネットワーク装置等であってもよい）に本願の各実施例に記載の方法の全部又は一部のステップを実行させるための複数の指令を含む。前述の記憶媒体は、Ｕディスク、モバイルディスク、読み出し専用メモリ（ＲＯＭ：Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ランダムアクセスメモリ（ＲＡＭ：Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、磁気ディスク又は光ディスク等のプロクラムコードを記憶できる様々な媒体を含む。

以上のように、上記実施例は本願の技術案を説明するためのものに過ぎず、それを制限するためのものではなく、前述実施例を参照して本願を詳細に説明したが、当業者であれば、前述各実施例に記載された技術案を補正し、又はその一部の技術的特徴を均等置き換えることができ、それらの補正や置き換えによって、対応する技術案が本願各実施例の技術案の精神及び範囲から逸脱しないことを理解すべきである。

本願の実施例では、各仮想対象の現在の可視範囲内のインタラクティブ仮想対象の密度に基づいて、アクセスしている仮想対象を複数の密度レベルに分割し、各密度レベルに１つのリソース要求割当額を割り当て、所定の時間内に、ある密度レベル内の仮想対象により送信されたリソース要求を受信する時、且つ密度レベルに対応するリソース要求割当額が所定の割当額閾値より大きいと確定した場合、受信した該リソース要求を処理し、該密度レベルに対応するリソース要求割当額から所定の数値を引き、前記所定の割当額閾値の以下である場合、該リソース要求を拒絶する。本願の実施例は仮想対象に対して密度レベルの分割を行い、各密度レベルにリソース要求割当額を割り当て、リソース要求割当額が所定の割当額閾値の以下である場合、該密度レベル内の仮想対象により送信されたリソース要求の処理を拒絶し、それにより、ＣＰＵの処理が過荷重にならないので、サーバの不十分な演算能力によるスタッタリング問題を軽減させることができる。

７０１ 密度レベル分割ユニット
７０２ 割当額割当ユニット
７０３ リソース要求受信ユニット
７０４ リソース要求処理ユニット
７０５ 設定ユニット
８００ サーバ
８２２ 中央処理装置
８２６ 電源
８３０ メモリ
８４１ オペレーティングシステム
８４２ アプリケーションプログラム
８４４ データ
８５０ 有線又は無線ネットワークインタフェース
８５８ 入出力インタフェース
９０１ プロセッサ
９０３ メモリ
９０５ 伝送装置
９０７ 入出力装置

Claims (17)

1. リソース要求処理方法であって、
   各仮想対象の現在の可視範囲内のインタラクティブ仮想対象の密度に基づいて、アクセスしている仮想対象を複数の密度レベルに分割するステップであって、密度レベルの高低は仮想対象の密度の大きさに正比例する、ステップと、
   各密度レベルに１つのリソース要求割当額を割り当てるステップであって、各密度レベルに対応するリソース要求割当額は、第１所定の時間内に、許可される、該密度レベル内の仮想対象により送信されたリソース要求を処理する数である、ステップと、
   前記第１所定の時間内に、第１密度レベル内の仮想対象により送信されたリソース要求を受信する時、前記第１密度レベルに対応するリソース要求割当額が所定の割当額閾値より大きいと確定した場合、前記リソース要求を処理し、前記第１密度レベルに対応するリソース要求割当額から所定の数値を引き、前記第１密度レベルに対応するリソース要求割当額が前記所定の割当額閾値の以下であると確定した場合、前記リソース要求を拒絶するステップと、
   を含む、リソース要求処理方法。
2. 前記方法は、
   前記第１密度レベルに対応するリソース要求割当額が前記所定の割当額閾値の以下であり、且つ密度レベルが前記第１密度レベルより高い他の密度レベルのそれぞれに対応するリソース要求割当額がいずれも前記所定の割当額閾値より小さいと確定した場合、前記リソース要求を拒絶するステップをさらに含む、請求項１に記載の方法。
3. 前記方法は、
   密度レベルが前記第１密度レベルより高い第２密度レベルに対応するリソース要求割当額が前記所定の割当額閾値より大きい場合、前記リソース要求を処理し、前記第２密度レベルに対応するリソース要求割当額から前記所定の数値を引くステップをさらに含む、請求項２に記載の方法。
4. 前記各密度レベルに１つのリソース要求割当額を割り当てるステップは、
   ＣＰＵの現在の負荷に基づいて各密度レベルに１つのリソース要求割当額を割り当てるステップであって、前記リソース要求割当額の大きさは前記ＣＰＵの現在の負荷の大きさと反比例するステップを含む、請求項１に記載の方法。
5. 前記方法は、
   前記第１所定の時間を経過した後、各密度レベルに１つのリソース要求割当額を改めて割り当てるステップをさらに含む、請求項１から４のいずれか１項に記載の方法。
6. 前記方法は、
   目標仮想対象により第２所定の時間内に送信されたリソース要求がいずれも拒絶されたと検出した場合、前記目標仮想対象により送信されたリソース要求を次回受信する時、前記目標仮想対象により送信された該リソース要求を処理するステップをさらに含む、請求項１から４のいずれか１項に記載の方法。
7. 前記方法は、
   ＣＰＵの負荷が所定の負荷閾値より小さい場合、前記第２所定の時間を、予め設定された、許可される連続２回リソース要求送信の間隔時間より小さく設定するステップをさらに含む、請求項６に記載の方法。
8. 前記各仮想対象の現在の可視範囲内のインタラクティブ仮想対象の密度に基づいて、アクセスしている仮想対象を複数の密度レベルに分割するステップは、
   各仮想対象の現在の可視範囲内のインタラクティブ仮想対象の密度を取得するステップと、
   密度が同一の数値区間に属する仮想対象を同一の密度レベルに分割するステップと、を含む、請求項１から４のいずれか１項に記載の方法。
9. リソース要求処理装置であって、１つ又は複数のプロセッサと、プログラムユニットを記憶する１つ又は複数のメモリとを含み、前記プロセッサにより実行される前記プログラムユニットは、
   各仮想対象の現在の可視範囲内のインタラクティブ仮想対象の密度に基づいて、アクセスしている仮想対象を複数の密度レベルに分割するように構成される密度レベル分割ユニットであって、密度レベルの高低は仮想対象の密度の大きさに正比例する密度レベル分割ユニットと、
   各密度レベルに１つのリソース要求割当額を割り当てるように構成される割当額割当ユニットであって、各密度レベルに対応するリソース要求割当額は、第１所定の時間内に、許可される、該密度レベル内の仮想対象により送信されたリソース要求を処理する数である割当額割当ユニットと、
   第１密度レベル内の仮想対象により送信されたリソース要求を受信するように構成されるリソース要求受信ユニットと、
   第１所定の時間内に、前記受信ユニットが第１密度レベル内の仮想対象により送信されたリソース要求を受信する時、前記第１密度レベルに対応するリソース要求割当額が前記所定の割当額閾値より大きいと確定した場合、前記リソース要求を処理し、前記第１密度レベルに対応するリソース要求割当額から所定の数値を引き、前記第１密度レベルに対応するリソース要求割当額が前記所定の割当額閾値の以下であると確定した場合、前記リソース要求を拒絶するように構成されるリソース要求処理ユニットと、
   を含む、リソース要求処理装置。
10. 前記リソース要求処理ユニットはさらに、前記第１密度レベルに対応するリソース要求割当額が前記所定の割当額閾値の以下であり、且つ密度レベルが前記第１密度レベルより高い他の密度レベルのそれぞれに対応するリソース要求割当額がいずれも前記所定の割当額閾値より小さいと確定した場合、前記リソース要求を拒絶するように構成される、請求項９に記載の装置。
11. 前記リソース要求処理ユニットはさらに、密度レベルが前記第１密度レベルより高い第２密度レベルに対応するリソース要求割当額が前記所定の割当額閾値より大きい場合、前記リソース要求を処理し、前記第２密度レベルに対応するリソース要求割当額から前記所定の数値を引くように構成される、請求項１０に記載の装置。
12. 前記割当額割当ユニットは、具体的には、ＣＰＵの現在の負荷に基づいて各密度レベルに１つのリソース要求割当額を割り当てるように構成され、前記リソース要求割当額の大きさは前記ＣＰＵの現在の負荷の大きさと反比例する、請求項９に記載の装置。
13. 前記割当額割当ユニットはさらに、前記第１所定の時間を経過した後、各密度レベルに１つのリソース要求割当額を改めて割り当てるように構成される、請求項９から１２のいずれか１項に記載の装置。
14. 前記リソース要求処理ユニットはさらに、目標仮想対象により第２所定の時間内に送信されたリソース要求がいずれも拒絶されたと検出した場合、前記目標仮想対象により送信されたリソース要求を次回受信する時、前記目標仮想対象により送信された該リソース要求を処理するように構成される、請求項９から１２のいずれか１項に記載の装置。
15. 前記装置は、
    ＣＰＵの負荷が所定の負荷閾値より小さい場合、前記第２所定の時間を、予め設定された、許可される連続２回リソース要求送信の間隔時間より小さく設定するように構成される設定ユニットをさらに含む、請求項１４に記載の装置。
16. 実行する時に前記請求項１から８のいずれか１項に記載の方法を実行するように構成されるコンピュータプログラムが記憶されている記憶媒体。
17. コンピュータプログラムが記憶されているメモリと、前記コンピュータプログラムによって前記請求項１から８のいずれか１項に記載の方法を実行するように構成されるプロセッサとを含む、電子装置。