(57)【特許請求の範囲】
【請求項１】
クライアント／サーバベースのバーチャル環境を提供する装置であって、前記バーチャル環境は１つ以上のエンティティを含むように構成されており、バーチャル環境内の各エンティティが、少なくとも、前記バーチャル環境内におけるエンティティの動作を規定しているルールを提供するルールエンティティモデル、エンティティの動的な特徴に関する記述を提供するダイナミックエンティティモデル、およびエンティティのユーザ表示に関する記述を提供する視覚エンティティモデルによって表され、前記エンティティモデルの各々が相互に独立しており、前記装置が、
バーチャル環境内の動作を規定しているルールの所定の組にしたがってエンティティの概念モデルを提供するルールモデルマネージャと、バーチャル環境内のエンティティの少なくとも1つのダイナミックモデルを提供する少なくとも１つのダイナミックモデルマネージャとを備えるサーバー装置と、
各クライアントが視覚モデルマネージャを備えていて、各クライアントがバーチャル環境内のエンティティの少なくとも１つのモデルを提供する少なくとも１つのクライアントと、
前記ルールモデルマネージャと、前記少なくとも1つのダイナミックモデルマネージャと、前記少なくとも１つの視覚モデルマネージャとの間でメッセージを伝送する通信装置と、を含む装置。
【請求項２】
サーバ装置は、複数のダイナミックモデルマネージャを備えるように構成されており、前記複数のダイナミックモデルマネージャは、複数の独立サーバに分散させられている請求項１記載の装置。
【請求項３】
前記少なくとも１つのダイナミックモデルマネージャが、複数のサーバ上で実行している1組の分散形ダイナミックモデルマネージャを構成し、中央環境マネージャがルールモデルマネージャから前記1組の分散形ダイナミックモデルマネージャへのメッセージのルーティングを管理するように構成されている請求項１または２に記載の装置。
【請求項４】
前記少なくとも1つのダイナミックモデルマネージャが複数のゾーンマネージャを含み、各ゾーンマネージャが、ゾーンマネージャと関係しているバーチャル環境のゾーン内に存在する少なくとも１つのエンティティのダイナミックモデルを提供するように構成されている請求項１ないし３の何れか1項記載の装置。
【請求項５】
前記少なくとも１つのクライアントが、クライアントのゾーンを表わすゾーンマネージャ、およびクライアントのゾーンを取り囲む複数のゾーンを表わすゾーンマネージャへの接続を設定するように構成されている請求項４記載の装置。
【請求項６】
前記少なくとも１つのダイナミックモデルマネージャが、バーチャル環境のエンティティの少なくとも１つのダイナミックモデルにマルチキャストアドレスを提供する請求項１ないし５の何れか1項記載の装置。
【請求項７】
クライアント／サーバベースのバーチャル環境におけるサーバ装置であって、バーチャル環境内の各エンティティは、前記バーチャル環境内におけるエンティティの動作を規定しているルールを提供するルールエンティティモデル、エンティティの動的な特徴に関する記述を提供するダイナミックエンティティモデル、およびエンティティのユーザ表示に関する記述を提供する視覚エンティティモデルによって表わされ、サーバ装置は、
バーチャル環境内のエンティティの概念エンティティモデルを提供するルールエンティティモデルマネージャと、
バーチャル環境内のエンティティの少なくとも1つのダイナミックエンティティモデルを提供する少なくとも１つのダイナミックモデルマネージャと、
前記ルールエンティティモデルマネージャと前記少なくとも１つのダイナミックモデルマネージャとからのメッセージの送信、および少なくとも１つの視覚モデルマネージャからのメッセージの受信を可能にするように構成されている通信装置とを備え、
少なくとも１つのクライアント装置は前記少なくとも１つの視覚モデルマネージャを備え、各視覚モデルマネージャは視覚エンティティモデルを提供する、サーバ装置。
【請求項８】
クライアント／サーバベースのバーチャル環境におけるクライアント装置であって、バーチャル環境内の各エンティティが、前記バーチャル環境内におけるエンティティの動作を規定しているルールを提供するルールエンティティモデル、エンティティの動的な特徴に関する記述を提供するダイナミックエンティティモデル、およびエンティティのユーザ表示に関する記述を提供する視覚エンティティモデルによって表わされ、クライアント装置は、
バーチャル環境内のエンティティの少なくとも1つの視覚エンティティモデルを提供する視覚モデルマネージャと、
前記少なくとも１つの視覚モデルマネージャからのメッセージの送信と、ルールエンティティモデルマネージャおよび少なくとも１つのダイナミックモデルマネージャからのメッセージの受信とを可能にする通信装置とを備え、
サーバ装置は前記ルールエンティティモデルマネージャおよび前記少なくとも１つのダイナミックモデルマネージャを備え、前記ルールエンティティモデルマネージャはルールエンティティモデルを提供し、前記少なくとも１つのダイナミックモデルマネージャはダイナミックエンティティモデルを提供するように構成されている、クライアント装置。
【発明の詳細な説明】
【０００１】
発明の属する技術分野
本発明は分散形バーチャル環境に関する。
【０００２】
従来の技術
コンピュータおよびビデオゲームは、最初のパーソナルコンピュータおよびホームビデオゲームコンソールが１９７０年代の後期に出現して以来、人気の娯楽であった。最後の２、３年でこれらのゲームの性質は２つの技術領域の発展により著しく変化した。
【０００３】
第１に、コンピュータ能力の向上により、複雑な３次元のバーチャル環境をモデル化して、表示できるようになったことである。これらの環境ではプレーヤはバーチャル世界を移動し、その中のエンティティと対話することができる。
【０００４】
第２に、コンピュータネットワークの使用および可用性における広範な成長（例えば、ＬＡＮとインターネットとの組み合せ）は、マルチプレーヤ機能を自負する多くのゲームに導入された。
【０００５】
これらの２つの発展を一緒に採用することにより、多くのゲームは共有バーチャル環境（ＶＥ）に基づくことになり、プレーヤはグループごとに競争（例えば、互いに撃ち合ったり、宝捜しをしたり、など）または協力（例えば、探検をしたり、またはパズルを解いたり、実務問題を解決したりする、など）することができるようになった。
【０００６】
共有のＶＥを伝達する際に、次のような多数の主要な問題を取扱わなければならない。
【０００７】
共有ＶＥにおける今日の一般的な構成では、各クライアントに共有環境のローカルコピーを置いている。プレーヤはローカルコピーと対話して、これらの対話を他のクライアントまたはサーバへ同報通信する。例えばドアを開くスイッチを各クライアントにおいてオブジェクトとしてモデル化してもよい。これは状態（スイッチ位置）および振る舞い（トグルされたときにアニメーション化して、別のオブジェクトにドアを開くように命令する）をもつ。状態と振る舞いの両方が各クライアント上に保持されている。ユーザがスイッチを作動するとき、スイッチは関連する振る舞いをローカルに実行するだけでなく、他のクライアントのスイッチの全ての場合に対して、他のクライアントが同じ振る舞いを実行するように命令するメッセージを送る。環境の変更をネットワーク全体に伝搬するには時間がかかるので、2人のプレーヤが衝突する動作（例えば、両者が同じオブジェクトをピックアップすること）をとることが可能である。このタイプの問題を解決して各プレーヤによって見られる環境が本質的に同じであることを確実することは、‘一貫性(consistency)’の維持として知られている。
【０００８】
情報がクライアント間で伝搬するのにかかる時間は‘待ち時間(latency)’として知られており、信頼でき、一貫した環境を維持しようとするときにキー要素である。長いまたは可変の待ち時間のために、全てのクライアント間の共通の共有されるビューを維持することが困難になることがある。
【０００９】
プレーヤが存在しないときにＶＥの状態を持続し、プレーヤがゲームを辞めて、その状態をリセットせずに再び加わる場合、これは‘持続性(persistent)’環境であると言われる。持続性環境は通常、（1以上の）サーバがＶＥの状態を記憶することを要求する。
【００１０】
理想的に‘スケーラブルな’ＶＥは、ＶＥ内のプレーヤ数が理論的な制限値をもたずに増加できる環境である（すなわち、システムの構成要素の何れも潜在的な動作のボトルネックにならない）。
【００１１】
一貫性、待ち時間、持続性、およびスケーラブルであることの上述の問題点は一般的には、ゲーミングＶＥとノン−ゲーミングＶＥの両方にあてはまる。多数の付加的な問題、例えばバランス、再使用、保全性、および拡張能力は、とくにゲーミング環境において重要である。
【００１２】
非共有で、非持続性のＶＥ（例えばプレーヤの技能が向上すると、プレーヤが直面する問題はより困難になることがある）を注意深く制御して、バランスのとれたゲームをプレーヤに伝えることができる。対照的に、持続性環境では、数ヶ月にわたって数百のプレーヤがこの持続性環境に影響を与えて展開する。したがって設計者が、プレーヤがゲームセッション期間中に出会う人およびものを制御することは非常に困難である。ダイナミックに新しい振る舞いをもつオブジェクトをに導入するか、オブジェクトの既存の振る舞いを修正して、全てのユーザが楽しむことができる‘バランスのとれた’ゲームを維持することが必要である。
【００１３】
多くのゲームは共通の特徴およびオブジェクト（例えば、プレーヤによって発射することができるミサイル、ドアを動作するスイッチ、および特定のオブジェクトにおいて一定の振る舞いをトリガする圧力パッド、など）を共有する。加えて、多くの大当たりしたゲームには、オリジナルの話の筋および技術に基づいて生成された続編がある。したがって特定の構成要素間で共通の構成要素を‘再使用(reuse)’または実行する(carry)能力は非常に有効である。
【００１４】
持続性ゲーミング環境を継続するのに、プレーヤはシステムが公正なプレーを保証する、したがってシステムは‘完全(integrity)’であると言われることを信じなければならない。他のプレーヤが発覚を恐れずに不正を行なうことができるとするとゲームに参加したいプレーヤはほとんどいないであろう。
【００１５】
プレーヤが戻りたいと思い続けられる持続性環境を生成するには、環境が拡張および向上できることが重要である。ユーザのコミュニティを構築するとき、‘拡張能力(extensibility)’はそれらを保持する手段を提供する。
【００１６】
既存の分散形ＶＥ応用ゲームでは、一体構成部分としてではなく付加的な特徴として含めた成果のネットワーキングを備える単一プレーヤ用ゲームから受け継いだ展開をそれらに与える傾向があった。したがって一般的なゲームは各クライアントにグラフィックスおよびゲームプレイに関係する振る舞いの両方を用意して、このプレーヤの入力を全ての他のクライアントへ同報通信して他のクライアントと同期化することによって上述のように動作するものである。この解決案は、（各クライアントのネットワークロードが全ての追加のクライアントにおいて増加する場合は）スケーラビリティ、（最後のクライアントが離れるときに環境状態が失われる場合は）持続性を欠いている。
【００１７】
より精巧な構成は特定の（すなわち、そのゲームタイトルに独特の）単一の中央サーバを追加して、環境状態を用意し、同報通信するか、または環境への変化を調停する。これは持続性環境を用意することができるが、単一の中央集中形サーバはスケーラビリティを除外している。これは、クライアント数が増加するとき、サーバネットワークのトラヒックロードおよびプロセスロードの両方が増加し、最も強力なサーバでさえもボトルネックになってしまうからであるという事実による。
【００１８】
これらの解決案の両方は、クライアントにおけるゲームエンジンだけでなく、グラフィックスエンジンも置く傾向がある。これは有効構成（各クライアントは各ゲームタイトルに対して効果的に注文製とされる）を用意するという潜在性をもつ一方で、ゲームルールのレリースバージョンについての一定の制約に対してゲームプレイの超過時間のバランスをとることを制限する。さらにゲームルールをクライアント構成と密接に関係付けることによって、これは構成要素の再使用を制限する。
【００１９】
ＶＥアーキテクチャのより精巧な例は、多数の学術的および軍事的解決案から幾らか明らかにされている。
【００２０】
学術的または軍事的システムのＶＥフィールドにおける研究の主要な焦点は、適切なネットワークアーキテクチャにスケーラビリティを伝える能力であった。
【００２１】
既知の解決案は次のような技術を含む。
【００２２】
マルチキャストネットワークアドレスはバーチャル環境内の規定領域と関係付けることができる。この領域内の変更はこのアドレスを介して同報通信され、この領域に関心のあるクライアントは更新を受取るアドレスを聞き取る。したがって特定のクライアントに対するネットワークトラヒックは、完全な環境においてではなく、アバター(avatar、化身の意、バーチャルリアリティの慣用語)のローカルエリア内のエンティティ数に対して増加する。このような解決案は、Michaeal R Macadoniaによる文献（“A Network Software Architecture for large Scale Virtual Environments”, Presence Vol.3 No.4 1994）に記載されている。
【００２３】
その代わりに、マルチキャストネットワークアドレスは環境内で個々のエンティティと関係付けられ、次にこのエンティティを使用して、エンティティの状態（位置または方向、など）を送ることができる。ユーザがエンティティの範囲（範囲は視覚または音声の何れかを認識するときに定められる）内にくるとき、ユーザは関係するネットワークアドレスを聞き始め、現在のエンティティ状態を受取る。このような解決案はChrist Greenhalgh およびSteve Benfordによる文献（“MASSIVE: a Virtual Reality system for Teleconferencing”, ACM Transaction on Computer Human Interfaces, 1995）に記載されている。
【００２４】
これらの解決案の両方は、簡単な環境状態のサーバを使用して一貫性および持続性を与えることにより向上する。しかしながらこれらの既知の解決案ではゲーミング、すなわちバランス、再使用、および保全性に直接に関係する問題を取扱わない。
【００２５】
発明が解決しようとする課題
本発明の第１の態様にしたがって、クライアント／サーバ応用バーチャル環境を用意する装置であって、バーチャル環境内の各エンティティがエンティティの複数の関係するモデルとして表わされ、前記複数のモデルのそれぞれがエンティティの特定の態様に関係していて：バーチャル環境内のエンティティの概念モデル（コンセプチュアルモデル）を用意するようにされているサーバで実行するルールモデルのマネージャ；少なくとも１つのサーバ実行ダイナミックモデルマネージャであって、各ダイナミックモデルマネージャはバーチャル環境内でエンティティの少なくとも1つを用意するようにされているとする；少なくとも１つのクライアント−このクライアントまたは各クライアントはバーチャル環境内でエンティティの少なくとも１つの視覚モデルを用意するようにされているとする；およびルールモデルマネージャと、前記少なくとも1つのダイナミックモデルマネージャと、前記少なくとも１つのクライアントとの間でメッセージを送って、一貫性を保証する通信チャンネルを含む装置を提供する。
【００２６】
ダイナミックモデルと概念モデルとを分離することは、バランスをとり、ゲームをはるかにより簡単に拡張する。複雑な力学（ダイナミックス）は他のところで処理されるので、ゲームの設計者は、ゲームプレイおよびゲーム内容にかなり焦点を合わせた概念モデルを使用して作業する。概念モデルに対する修正および追加には、ダイナミックモデルまたは視覚モデルの変更を含まない。したがってゲーム設計者は、共有のＶＥを維持するのに必要な振る舞いおよび状態の分散にではなく、ゲームプレイに関連する問題に焦点を合わせることができる。
【００２７】
ダイナミック／概念／視覚の分離により構成要素の再使用も促進している。ＶＥに要求されるダイナミックモデル化は、ゲームのタイプとは無関係に公正な一貫性がある。例えば、プレーヤが中世の地下ろうを探検していても、または現代のオフィス街を探検していても、依然としてオブジェクトは捨てられ、ドロップされ、衝突されることがある。
【００２８】
したがって既存のゲームを変更することが簡単なだけでなく、新しい組の概念の表示を用意することによって完全に新しいゲームを送ることが簡単である。
【００２９】
ダイナミック／概念／視覚の分離によりＶＥの管理に対する異なる技術的な構成を使用することができる。集中的なダイナミックモデリングにおいて、修正が頻繁でなく、速度が限界であるときは、コンパイルされた言語（例えば、Ｃ＋＋）が望ましい。融通が利き、頻繁に変更される概念モデルでは、翻訳された言語（例えば、ジャバ(Java)）がより適している。対照的に、このタイプの処理を分割せずに、速度または融通性の何れかを犠牲にしなければならない。
【００３０】
ゲーム規則の多くを概念モデルに埋め込み、サーバに記憶することにより、各クライアントからの上流トラヒック要求を低減するのを助ける。クライアントの動作が、環境に対して多数のダイナミックな変更を行なうとき（例えば、多数のオブジェクトを押し退けるドアを開くこと）、クライアントは単一の高レベル要求のみをルールモデルマネージャへ送る。これは、ルールモデルマネージャおよびダイナミックモデルマネージャの両方によって多数のダイナミックな状態変更へマップされる。
【００３１】
概念モデル（例えば、ゲームルール）およびダイナミックモデルの両方の組み合せは、装置の保全性と一貫性の両方を確実にする。クライアントは概念モデルまたはダイナミックモデルの何れかによって承認された後で、ＶＥに対する変更を行なうことができるだけである。したがってプレーヤは全てに対する公正なプレーを保証される。環境の保全性がコードバグを利用するユーザによってブリーチされるとき、関連するサーバコードを固定することができる。これはユーザを信用して、必要なときにクライアントパッチをインストールする必要を避ける。
【００３２】
本発明の別の態様によって、クライアント／サーバ応用バーチャル環境におけるサーバ装置であって、バーチャル環境内の各エンティティはエンティティの複数のモデルとして表示され、前記複数のモデルのぞれぞれがエンティティの特定の態様に関係していて：少なくとも１つのクライアント、このクライアントまたは各クライアントはバーチャル環境内でエンティティの概念モデルを用意するようにされているサーバ実行ルールモデルマネージャ；少なくとも１つのサーバ実行ルールモデルマネージャ−このマネージャまたは各ダイナミックマネージャはバーチャル環境内のエンティティの少なくとも1つのダイナミックモデルを用意するようにされている；およびルールモデルマネージャと前記少なくとも１つのダイナミックモデルマネージャとの間でメッセージを送る通信チャンネルを含むサーバ装置を提供する。
【００３３】
本発明のさらに別の態様にしたがって、クライアント／（または）サーバ応用バーチャル環境におけるクライアント装置であって、バーチャル環境内の各エンティティが、複数の関係するエンティティモデルとして表わされ、前記複数のモデルのそれぞれがエンティティの特定の態様に関係していて：少なくとも1つのクライアントであって、このクライアントまたは各クライアントはバーチャル環境内のエンティティの少なくとも1つの視覚モデルを用意するようにされている；および前記少なくとも1つのクライアントと、バーチャル環境内でエンティティの概念モデルを用意するようにされているサーバ実行ルールモデルマネージャと、少なくとも1つのサーバ実行ダイナミックモデルマネージャであって、このマネージャまたは各ダイナミックモデルマネージャはバーチャル環境内のエンティティの少なくとも1つのダイナミックモデルを用意するようにされているマネージャとの間でメッセージを送る通信チャンネルを含むクライアント装置を提供する。
【００３４】
本発明のさらに別の態様にしたがって、クライアント／サーバ応用バーチャル環境を用意する方法であって、バーチャル環境内の各エンティティは複数の関係するエンティティモデルとして表わされ、前記複数のモデルのそれぞれはエンティティの特定の態様に関係していて：エンティティの概念モデルと、エンティティのダイナミックモデルと、エンティティの視覚モデルとを用意すること；サーバ実行ルールモデルマネージャ上にエンティティの概念モデルを記憶し、サーバ実行ダイナミックモデルマネージャ上にエンティティのダイナミックモデルを記憶すること；少なくとも１つのクライアント上に視覚モデルのエンティティを記憶すること；およびルールモデルマネージャと、ダイナミックモデルマネージャと、前記少なくとも１つのクライアントとの間でメッセージを送ることを含む方法を提供する。
【００３５】
ここで本発明の特定の実施形態を例示的に添付の図面を参照して記載することにする。
【００３６】
発明の実施の形態
既に記載したように、バーチャル環境（ＶＥ）のフィールドにおいて、いわゆるクライアント／サーバアーキテクチャの使用はよく知られている。バーチャル環境（ＶＥ）をモデル化するときにオブジェクト指向（ＯＯ）技術を使用することもよく知られている。
【００３７】
図１に関して、バーチャル環境（ＶＥ）内の３つエンティティは別個に表わされているが、オブジェクト10、12、14は関係していて、各オブジェクトはエンティティの異なる態様のモデルを用意している。このやり方では各オブジェクトは所定のやり方で完全なエンティティを表わしている。
【００３８】
概念表示オブジェクト(Conceptual Representative Object)10はゲームプレイの特定の特徴に関係してＶＥ内のエンティティを記載する。異なるオブジェクトの対話における所望の対話はゲームのルールおよびゴールを生成する。
【００３９】
例示的にゲーム内の銃は、銃に独特の振る舞いおよび状態を使って銃概念オブジェクトとして概念的に表わすことができる。典型的な状態は“残りの弾丸数”を含み、振る舞いは“引き金を引いて、弾丸を発射する”ことを含んでもよい。しかしながら銃の概念は銃の視覚モデル（例えば、リスト多角形(list polygon)、または組織マップ(texture map)、など）あるいは銃のダイナミックスモデル（例えば位置、方向、速度、または量、など）を含まない。
【００４０】
ダイナミック表示オブジェクト(Dynamic Representative Object)12はＶＥ内のエンティティの物理的な特徴、例えば移動、スピン、衝突、などを記載する。ダイナミック表示オブジェクト12によって保持されている典型的な状態は、エンティティの位置、方向、重さ、衝突ボリューム、または速度、などであってもよい。ダイナミック表示オブジェクトに関係する典型的な振る舞いは、捨てられるか、ドロップされるか、またはそれが衝突する、などのときにどのようにエンティティが移動するかである。概念的に異なるエンティティ（例えば、銃およびペン）は同じタイプのダイナミック表示オブジェクト12と関係付けることができるが、異なる最初の状態のパラメータをもつことができる（例えば、銃およびペンは概念的に異なる一方で、それらは捨てられるかまたはドロップされるときに類似のやり方で振る舞うことになる）。
【００４１】
視覚表示オブジェクト14はエンティティのユーザ表示を与える。これは状態情報、およびクライアントにおいてエンティティを与えすことを要求される振る舞いを含む。視覚表示オブジェクト14によって保持される典型的な状態情報は形状または組織マップの地理的記述、使用されるサウンド、などであってもよい。ダイナミックな振る舞い（例えば、ドアを開く）は視覚的に表わされなければならないので、視覚オブジェクトタイプとダイナミックオブジェクトタイプとの間には密接な相関関係がある。しかしながら、例えばドアのダイナミックモデル12は、ドアが開くときに、他のエンティティと正しく衝突することを保証する場合、視覚モデル14はそれが蝶番を回すときに正しく与えるように保証することになる。
【００４２】
視覚表示オブジェクト14は、エンティティの実行が求められるようにすることができる1組の動作を指示することによってエンティティに対するユーザインターフェイスを与え（例えば、ドアを“開く”またはレバーを“引く”、など）。これらの動作は、それぞれダイナミックおよび概念表示オブジェクト12、10によって判断され、ユーザからこれらの２つの表示オブジェクトの何れかに対する要求に対して直接に動作マップを実行するように要求する。例えばＶＥにおいて銃は、（ダイナミック表示オブジェクト12への要求によって）移動されるか、または（概念表示オブジェクト10への要求によって）発射することができる。
【００４３】
単一のエンティティタイプは３つの異なるオブジェクト10、12、14の組み合せによって表わされるが、各エンティティにおいて３つの独特のタイプのオブジェクトは必ずしも必要ではない。２つのエンティティは概念的に異なるが、それらは両方とも同じタイプのダイナミック表示オブジェクト12によってモデル化され、同じタイプの視覚表示オブジェクト14によって与えることができる。
【００４４】
例えば剣は、3つの組み合せ（トリプレット）“剣の概念、一般エンティティダイナミック、一般エンティティ視覚”を使用して表わすことができる。同様に銃を“銃の概念、一般エンティティダイナミック、一般エンティティ視覚”を使用してモデル化することもできる。この原理はより複雑なダイナミック管理を要求するエンティティに拡張されるが、最早精巧な視覚を与えるものではない。例えばスイングドアは3つの組み合せ“ドア概念、スイングドアダイナミック、アニメーション化したエンティティ視覚”によって表わされる。
【００４５】
このエンティティの３つの組み合せ10、12、14はエンティティタイプを規定するが、エンティティをモデル化するために生成された表示オブジェクト数を記載していない。ＶＥ内に存在する各エンティティについて、単一の概念表示オブジェクト10および単一のダイナミック表示オブジェクト12が生成される。しかしながら視覚表示オブジェクト14は、エンティティを視覚化することができる各クライアントに対して例示または生成されなければならないことが明らかになるであろう。したがってエンティティタイプは３つの組み合せ“概念タイプ、ダイナミックタイプ、視覚タイプ”によって定められる。エンティティの例は、“概念例（コンセプチュアルインスタンス）、ダイナミック例（インスタンス）、視覚例（ビジュアルインスタンス）、視覚例（ビジュアルインスタンス）、…”によって定義することができる。
【００４６】
図２は、図１に関係して記載されたように表わされるエンティティを含むＶＥを生成するクライアント／サーバネットワークアーキテクチャの１つの実施形態を示す。
【００４７】
クライアント／サーバネットワークは、サーバ実行ルールマネージャ20およびサーバ実行ダイナミックマネージャ22とを含む。ルールマネージャ20は概念表示オブジェクト10を管理および記憶し、ダイナミックマネージャはダイナミック表示オブジェクト12を管理および記憶する。通信チャンネルまたは接続21はルールマネージャ20とダイナミックマネージャ22との間に用意される。通信チャンネルは、ルールマネージャ20とダイナミックマネージャ22との間で信号によってメッセージを送る。
【００４８】
クライアント／サーバネットワークはさらにクライアント24を含み、各クライアントは視覚表示オブジェクト14を管理および記憶する。通信チャンネル23が用意され、クライアント24と、ルールマネージャ20と、ダイナミックマネージャ22との間で信号によってメッセージを送る。
【００４９】
したがってクライアント24はダイナミック変更要求（例えば（いわゆるアバターによって表わされる）ユーザの移動）をダイナミックマネージャ（ＤＭ）22へ送り、要求（すなわち、ドアｘを開きなさい）に関係するより高いレベルのゲームをルールマネージャ（ＲＭ）20へ送る。ＤＭ22は環境への変化を確認し、環境状態を更新し、クライアント24への変更を同報通信する。ＲＭ20はゲーム状態を変更し、おそらくはネットワーク通信21を介してＤＭ22を使用して要求を位置付ける（例えば速度ｘをエンティティｙへ追加する）ことによって要求に応答する。
【００５０】
各クライアント／サーバ素子は、次に記載するように、ハードウエア／ソフトウエアを使用することができる。
【００５１】
ルールマネージャ20はマルチプロセッサＵＮＩＸワークステーションまたはコンピュータによって用意されているサーバ上で走行する。ワークステーションはＵＮＩＸオペレーティングシステム内のＪａｖａバーチャル機械を走行する。（Ｊａｖａ構成はSun Microsystemsから販売されている）。Ｊａｖａがもっとも明らかで簡単なオブジェクト指向（ＯＯ）プログラミング言語の１つであり、ＪａｖａはＲＭ20を実行するのに適しており、ゲーム規則を変更するとき、実行時間中に新しいオブジェクトをリンク／変換する能力は最大の融通性を与える。ＵＮＩＸマシンは高性能のマルチスレッドＪａｖａコードを提供し、単一のＲＭ20が各ＶＥを制御し、複数のプロセッサを使用することによって性能を向上する能力が有益である。
【００５２】
ダイナミックスマネージャ22は、マルチプロセッサＵＮＩＸワークステーションまたはコンピュータによって与えられるサーバ上を走行する。ＶＥのダイナミックスの管理はコンピュータ処理上集中的であるが、理想的には衝突の計算を処理する非常に高い浮動少数点機能をもつ、高性能のマルチプロセッサシステムが要求される。速度限界を除いて修正は頻繁ではないので、コンパイルされた言語、例えばＣ＋＋が望ましい。
【００５３】
各クライアント24は、カスタマレベルゲームプラットフォームを用意することができ、３次元グラフィックスおよびネットワーキングを支援するコンピュータ上で実行することができる。
【００５４】
上述の各ワークステーションまたはコンピュータは従来の構成をもち、通信チャンネル、キーボード、中央処理ユニット、ハードディスクメモリ、ランダムアクセスメモリ（ＲＡＭ）、および読み取り専用メモリ（ＲＯＭ）を接続するための入力および出力ポートを含む。各コンピュータにおいてオペレーティングシステムおよびアプリケーションプログラムはメモリにロードされる。サーバとして機能する各コンピュータでは、アプリケーションプログラムはサーバ機能を与えるプログラムを含む。同様に、クライアントとして機能する各コンピュータにおいて、アプリケーションプログラムはクライアント機能を用意しているプログラムを含む。ルールマネージャ20およびダイナミックマネージャ22は、各サーバ上を走行しているソフトウエアプロセスとして実行される。概念表示オブジェクト、ダイナミック表示オブジェクト12、およびバーチャル表示オブジェクト14のそれぞれは、各コンピュータのメモリ内に保持されるソフトウエアモジュールである。
【００５５】
ルールマネージャ20およびダイナミックスマネージャ22を用意するサーバは、高バンド幅／少待ち時間チャンネル21、例えばＦＤＤＩまたはＡＴＭ上を、ＴＣＰ／ＩＰプロトコルスタックを使用して互いに通信する。クライアント接続23は潜在的に低バンド幅であるが、一定の待ち時間およびバンド幅を提供する。例えばＰＰＰ（二地点間プロトコル）を使用してＰＳＴＮ（公衆交換通信ネットワーク）のダイヤルインシステム上をＩＰ（インターネットプロトコル）が走行することが適している。アーキテクチャはさらに、ダウンストリーム容量がアップストリーム容量よりも大きいとき、ＡＤＳＬ（非対称ディジタル加入者ライン）によって用意されるような、非同期クライアントネットワーク23に非常に適している。
【００５６】
図３は各クライアント、ルールマネージャ20、およびダイナミックスマネージャ22間の対話を管理する例を示している。
【００５７】
実行される実施形態は、システム内の各エンティティを表わすのに独特の識別子を使用し、とくに所定のドアエンティティタイプは‘ドア概念、スライディングドアダイナミック、およびスライディングドア視覚’として表わすことができると仮定する。さらに実行される実施形態では、同じオブジェクトの表示エンティティ間で、‘＜destination entity＞、＜request＞、＜…optional data…＞’の形態をとる例示的なメッセージフォーマットを使用して、シーケンス形式の確実なメッセージ転送を行なう。各視覚表示オブジェクト14上でユーザが実行できる特定の組の動作は定められる。
【００５８】
図３の例では、ルールマネージャ20はドア概念ブジェクト10ａの例（インスタンス）をもち、ダイナミックスマネージャ22はスライディングドアダイナミックオブジェクト12ａの例をもち、クライアント24は各スライディングドア視覚オブジェクト14ａの例をもつ。各オブジェクトは同じ識別ドアｉｄ（識別子）を割り当てられることになる。
【００５９】
図３の例示的な段階を参照する。
【００６０】
（ｉ）第１のクライアント24のユーザはグラフィカルユーザインターフェイス（ＧＵＩ）を使用して、クライアントにおいて示されたスライディングドア視覚オブジェクト14ａに関して許可されている動作リストから動作‘開放(open)’を選択する。
【００６１】
スライディングドア視覚オブジェクト14ａはＲＭ20へ送られるメッセージ‘＜door id＞＜client action＞＜open, from user X＞’を構成する。ＲＭは、メッセージの先に立つ独特の識別子を使用して、到来するメッセージ（１）をドアエンティティの例、すなわちドア概念オブジェクト10ａに伝える。ドア概念ブジェクト10ａは要求を処理し、内部ゲーム論理を使用して、ユーザＸが実際にドアを開放できるか否かを判断する。
【００６２】
（ii）ユーザＸがドアを開くことができ、ドア概念オブジェクト10ａがメッセージ‘＜door id＞、＜open＞’を形成し、（２）をＤＭ22へ送ると仮定する。
【００６３】
ＤＭは、メッセージの先に立つ独特の識別子を使用して、到来するメッセージ（２）をドアエンティティのそのバージョンへ伝える。スライディングドアダイナミックオブジェクト12ａは、‘＜door id＞＜open＞＜to position…,over time…＞’の形態で視覚表示オブジェクト14ａに対するメッセージを構成する。
【００６４】
（iii）このメッセージ（３）は関連する視覚表示オブジェクト14ａの例をもつ全てのクライアント24へ送られる。ダイナミック表示オブジェクト12ａは、所定の時間中にドアを開き、一方で他のダイナミック表示オブジェクトとの衝突を検査する。ＤＭ22からメッセージ（３）を受取る各クライアント24はそれをエンティティの例、すなわちスライディングドア視覚オブジェクト14ａへルート設定する。
【００６５】
オブジェクト14ａは、メッセージ内に示される位置および時間データを使用して、ドア開放を適切な視覚効果を使用してアニメーション化する。
【００６６】
ダイナミック表示オブジェクト12ａが、ドアの衝突または破壊によって生じる可能性の高い予測される状況から変動（バリエーション）を検出するとすると、クライアント24に対する新しいメッセージを生成して、‘＜door id＞、＜stop opening＞、＜at position…＞’の形態の視覚表示オブジェクト14ａを更新する。
【００６７】
効果的な構成を与えるためには、上述のＡＳＣＩＩストリングではなく、メッセージフォーマットが非常に最適化されることに注意すべきである。例示的に、概念／ダイナミック／視覚表示オブジェクトは規定され、番号を与えられた組の要求をもつとすると、メッセージヘッダは1対の番号になる。第1の番号、すなわちエンティティｉｄは到来メッセージが正しい表示オブジェクトをルート設定されるようにする。第２の番号、すなわち要求は表示オブジェクト上の関連する方法が呼ばれるようにする。これは、メッセージ内に供給される追加データをアンパック（開封）し、単一のサーバ上で要求される要求を実行するが、所望のレベルのスケーラビリティを達成する可能性は低い。ＶＥにおいて生成されるネットワークトラヒックの大半は環境のダイナミックスに関係している。したがって単一のサーバでは通信のボトルネックを直ぐに生成することができる。その代わりにＶＥのダイナミックス管理を実行して、処理ロードおよびダウンストリームネットワークトラヒックの両方におけるスケーラビリティを各クライアントへ用意することができる。したがってダイナミックス管理は多数のＤＭ、したがって多数のサーバ間で効果的に拡げられる。
【００６８】
図４は、この解決案に基づく本発明の好ましい第２の実施形態を示す。
【００６９】
図1の実施形態にしたがってサーバエンドにはルールマネージャ（ＲＭ）20が用意されている。いくつかのダイナミックマネージャ（ＲＭ）22ａ、22ｂ、22ｃはいわゆるワールドマネージャ（ＷＭ）26と一緒に用意されている。ダイナミックス環境モデルは分散形であるが、これは環境の概念モデルに不可視である。ワールドマネージャ26はルート設定を用意して、ルールマネージャ20が、ＶＥ内のダイナミック表示オブジェクトの位置を追跡する必要なく、メッセージをダイナミックマネージャ22に直接に送ることができるようにする。
【００７０】
ＲＭ、ＷＭ、およびＤＭ間の適切な通信は、ＲＭ20とＷＭ26との間およびＷＭ26とＤＭ22との間の各ネットワーク接続21によって与えられる。
【００７１】
別のネットワーク接続23は、それぞれが視覚表示オブジェクトを記憶している1以上のクライアント24との通信を可能にする。
【００７２】
多数のＤＭ22ａ、22ｂ、22ｃが必要とされる一方で、ＲＭ20は単一のプロセスとして依然として実行されねばならない。これはＶＥ内の適切な位置とは無関係に、概念モデルがオブジェクト間で複雑なカップリングをもつようにすることが望ましい。例えば、ゲームのパズルは環境全体に分散された一連のレバー、ボタン、および圧力パッドの使用を含むことができる。対照的にダイナミックの対話は、それが行なわれるＶＥ領域に制限される。
【００７３】
ロードおよびトラヒックがダイナミックの対話と関係するものよりもはるかに小さいので、単一のサーバ上で概念マネージャを実行することが可能である。例示的に移動アバターは２０の位置更新メッセージを生成することができ、一方でユーザによって実行される動作（例えばスイッチをパチッと入れる、またはドアを開く、などは比較的に頻繁ではなく、性質上反復的でない）。
【００７４】
ＷＭ26の機能は、ＶＥのダイナミックモデルを実行する分散形環境およびＶＥの概念モデル用の分散されていない環境が与えられるとき、ＤＭ22とＲＭ20との間のルート設定層を用意することである。
【００７５】
ＲＭ20はＶＥ内の各エンティティに対して概念表示オブジェクト10をもつ。各概念表示オブジェクトは、エンティティ（すなわち、銃またはドア、など）の概念識別子を表示するが、ＶＥ内のエンティティの位置の知識をもたない。整合用ダイナミック表示オブジェクト12が分散形ダイナミックモデル内にある場所も分からない。このやり方ではエンティティがＶＥ内を移動するときに、ＲＭ20はトラヒックをロードされない。
【００７６】
ＷＭ26は、ダイナミック表示オブジェクト12のＶＥ内における正確な位置は分からないが、それが分散形ダイナミックモデル内で現在記憶または例示されているところは、比較的に大まかなレベルで分かる。各ダイナミック表示オブジェクトは、分散形ダイナミック環境内の位置に関する十分な情報をＷＭ26に与えて、ＷＭがメッセージを（ＲＭ20に記憶されている）エンティティと関係する概念表示オブジェクト10から（関連するＤＭ22に記憶されている）ダイナミック表示オブジェクト12へルート設定できるようにする。この情報のフォーマットはダイナミックモデル化システムの構成に依存している。
【００７７】
各ＤＭはＶＥ内のそれに割り当てられた各エンティティに対してダイナミック表示オブジェクト12を記憶する。エンティティはＶＥ内にあるときは関連するＤＭは正確に分かるが、エンティティが表わしているのが何れの概念であるかが分からない。記憶された状態は、環境のダイナミックな物理的モデルを生成するのに必要とされる情報を表わす。
【００７８】
各クライアント24は、プレーヤのアバターの（視覚的または聴覚的）範囲内の各エンティティに対する視覚表示オブジェクト14を記憶する。記憶された状態は各エンティティを与えるのに要求される情報および概念またはダイナミック表示オブジェクトに要求するのに必要とされる情報を用意する。
【００７９】
各クライアント／サーバ要素は、上述の実施形態に関して既に示したようにハードウエア／ソフトウエアを使用するが、次のことを追加する。複数のマルチプロセッサＵＮＩＸワークステーションを使用して、多数のダイナミックスマネージャを実行することができる。ワールドマネージャ26は一般的なＵＮＩＸワークステーション上で実行することができる。適度に高速で効果的なＵＮＩＸ構成はメッセージのルート設定を用意するのに十分である。
【００８０】
図５は、マネージャ20、22、24、26間の各通信チャンネルを示す。
【００８１】
一般的に図5に示したマネージャ間通信チャンネルは次のように使用することができる：
（１）視覚表示オブジェクト14が、クライアント24におけるプレーヤから対応する概念オブジェクト10へ要求（例えばドア“を開きなさい”またはレバー“を引きなさい”）を送ることと、
（２）概念表示オブジェクト10が要求の結果（例えば“開放”要求に対して“ドアをロックしなさい”）に対してプレーヤにフィードバックを送ることと、
（３）視覚オブジェクト14がダイナミック表示オブジェクト12への要求（例えば“ｘ、ｙ、ｙ要求へのエンティティ移動”）を送ることと、
（４）ダイナミック表示オブジェクト12がシーン（例えば“現在ｘ、ｙ、ｚのエンティティ位置”または“角度ｘにおけるドアヒンジ”）を与えるのに必要とされる情報に関して視覚表示オブジェクト14を更新することと、
（５）概念表示オブジェクト10が、ＷＭ26に依存してダイナミック表示オブジェクト12へ要求（例えば“角度ｘまでドアを回して開ける(twist door open to angle x)”）を送って、各ダイナミック表示オブジェクトを見付けることと、
（６）ダイナミック表示オブジェクト12は、重大なダイナミックイベントの概念表示オブジェクト10を知らせる。重大であると考えられることは概念表示オブジェクト10によって判断され、ダイナミック表示オブジェクトへセンサを付加することによってイベントを選択する（例えば、ガラス板概念オブジェクトは衝突センサをそのダイナミックに相当する一般アイテムダイナミックオブジェクトへ追加する）。したがってエンティティが確定するとき、対応する表示オブジェクトが知らされ（６）、その結果を処理することができる。
（７）ＷＭは概念表示オブジェクト10（５）から各ダイナミック表示オブジェクト12（７）への要求（例えば、“角度ｘまでドアを回して開ける”）をルート設定する。
（８）ダイナミック表示オブジェクト12はそれらへのメッセージ送信手段を登録する。このチャンネルは、単一のＤＭが使用される簡単なスケールできないアーキテクチャ(non-scalable architecture)において必要ない。
【００８２】
全ての通信チャンネルは確実でなければならない。しかしながらチャンネル（３）および（４）は、適切なクラスのメッセージに対して有益な不確実なデータ流で補充してもよい。第１の環境は、頻繁に繰り返され、独立した時間シーケンスであるデータを含むメッセージに関係していてもよい。例えば各更新が連続する更新シーケンスの一部であるとき、ＶＥの長期間の一貫性に影響を与えずに、時折ドロップしてもよい。第２の環境は重大でなく、ＶＥに対してパーマネントな状態変更を行なわないメッセージに関係していてもよい。例えば手を振るかまたは瞬きするようにアバターに命令するメッセージメッセージを考えることができる。
【００８３】
上述で概略的に示したダイナミックモデルは、環境（全てのダイナミック表示オブジェクトの状態の和として定められる）のダイナミック状態の記憶を含むことと、クライアント24に必要な視覚表示オブジェクト14を構築するのに要求される最初の情報を与えることと、時間にしたがってダイナミック表示オブジェクトの状態（例えばダイナミック表示オブジェクトの速度は繰り返し計算される新しい値を必要とすることがある）および視覚表示オブジェクトおよび概念表示オブジェクトに対する要求される状態更新の分散（例えば移動するダイナミック表示オブジェクトがその位置を更新するとき、対応する視覚表示オブジェクトは新しい位置を知らされて、シーンを正確に与えることを確実にする必要がある）を更新することとを含む多数のタスクについての責務がある。
【００８４】
したがってダイナミックモデルの設計は少なくとも3つのキー領域に対処しなければならない。第１のキー領域は初期状態の伝達の検討である。接続する際に、クライアントは現在のダイナミック状態の視覚表示を与えられることが必要である。全てが独特の状態（位置、方向、視覚的記述、など）をもつ潜在的に数千のエンティティを備えていること、この最初の状態のダウンロードは低バンド幅リンク（例えばＰＳＴＮでは第２のモデム当り２８．８キロビット）上で長いプロセスであってもよい。したがって好ましい設計はこの最初のダウンロード期間を最小にすることを試行すべきである。
【００８５】
第２のキー領域は状態更新の分散の検討である。クライアントは、更新が現在のダイナミック状態の正確な記述を視覚的に表わすことを確実にする必要がある。しかしながら、状態（移動、回転、および衝突、など）を頻繁に更新している多数のダイナミック表示オブジェクトを備えていると、これは多数の情報交換を生成することができるようになる。したがって好ましい設計ではさらに、各クライアントに伝えられる状態更新量を最小にすることを試行する。
【００８６】
アドレスに対する第３のキー領域は、状態更新の検討である。必要なダイナミック状態更新のコンピュータ処理は、コンピュータ処理上非常に値段が高くなることがあり、ダイナミックモデル内に表示されるエンティティ数に対する潜在的な制限を表わす。したがって好ましい設計では多数のプロセッサ間でこのロードを分散することを試行する。
【００８７】
これらの問題に対処する提案されたアーキテクチャを図6に示した。
【００８８】
ルールマネージャ20および少なくとも1つのクライアント24は、本発明の先行する実施形態に関係する通りに与えられる。
【００８９】
ワールドマネージャ26は図４に関係して記載されたのと同様に与えられるが、1以上のダイナミックマネージャ22は持続性オブジェクトメモリ29と関係する1以上のゾーンマネージャ28として用意される。
【００９０】
以前のように、ルールマネージャ20は環境内に種々の概念表示オブジェクト10に対する処理時間を生成、記憶、および用意する。同様にクライアント24は、関心のある関係するアバター領域内に全ての視覚表示オブジェクト14に対する処理時間を生成し、記憶し、用意する。
【００９１】
ワールドマネージャは要求されるようにゾーンマネージャ28を生成し、ゾーンマネージャ28を閉じることとスタートアップすることと同期化し、ロード管理を行なう一方で、概念表示オブジェクト14からダイナミック表示オブジェクト12へメッセージをルート設定する。
【００９２】
各ゾーンマネージャ28は特定の割り当てられたゾーン内に全てのダイナミック表示オブジェクト12に対する処理時間を生成し、記憶し、用意する。各ゾーンマネージャはワールドマネージャ26によって生成され、ダイナミック動作でゾーンを管理し、割り当てられたゾーン内のダイナミックな動作が止まると、閉じられる。持続性オブジェクトメモリ29は閉じられたゾーン（例えばゾーンマネージャが割り当てられていないゾーン）内にダイナミック表示オブジェクト12に記憶機能を用意する。
【００９３】
したがってバーチャル環境は、ゾーンとして示されている多数の所定量へ分割されると考えてもよい。ゾーンはオーバーラップしないが、環境の全体量を含むようなやり方でレイアウトされる。したがって環境内の選択されたポイントは１つでしかも1つのみのゾーンに常に属することになる。
【００９４】
全てのダイナミック表示オブジェクト12は、瞬間的にちょうどよいときに単一の割り当てられたゾーンをもっている。ダイナミック表示オブジェクトが置かれる実際のゾーンはＶＥ内のその位置から判断される。ゾーンの状態はゾーン内の全てのダイナミック表示オブジェクト12の和として規定される。環境の状態はそのゾーンの全ての情態の和として規定される。
【００９５】
ゾーンの形状は全てのゾーンが正規化され、かつで同一であるか、または環境それ自体の設計にほぼ基づいていてもよい。例えば環境の簡単な細分化は水平方向面上では正方形のグリッドを単にオーバレイし、各ゾーンが垂直方向に無限に延長すると特定してもよい。より複雑な解決案ではその内容に基づいてバーチャル環境を細分化して、通路の容量は１つのゾーンを形成し、一方で隣接する空間の容量は別のゾーンを形成する。
【００９６】
図７は、（上から見た）小さい環境を細分化する際の２つの変形例を示す。
【００９７】
図７Ａは６つのゾーン70を示し、ゾーン１にダイナミック表示オブジェクト12（ａ）、ゾーン４に12（ｂ）、ゾーン２に12（ｃ）、ゾーン３に12（ｄ）、およびゾーン５に12（ｅ）を配置している。ダイナミック表示オブジェクト10の容量はゾーン境界線（例えば、図７Ａ内の（ｂ））にオーバーラップすることができ、元のダイナミック表示オブジェクトで常に1つのゾーン（例えば図７Ａ内のゾーン４）へ独特に属することができる。
【００９８】
図７Ｂはダイナミック表示オブジェクト10が同じ位置にある同じ環境を示しているが、4つのゾーンは細分化されている。図７Ｂではダイナミック表示オブジェクト（ａ）および（ｂ）をゾーン1に、（ｃ）および（ｄ）をゾーン３に、（ｅ）をゾーン４に置いている。
【００９９】
この様式でゾーン70およびゾーンマネージャ28を使用して上述で概略的に示した問題に可能な解決案を提供できることは明らかである。
【０１００】
例えばコンピュータ処理のロードを分散する問題はゾーンごとにゾーンにおけるダイナミック状態を維持および更新することによって解決される。上述に示した各ゾーンはゾーン管理と呼ばれるプロセスと関係付けられる。ソーンマネージャはダイナミックモデルへの時間に関係する状態変更を生成し（例えば、オブジェクトの位置および速度を更新する）、ダイナミックモデルへの変更を有効なものとし（例えば、視覚または概念表示オブジェクトからダイナミック表示オブジェクトへ移動する要求が有効であり、ダイナミック表示オブジェクトのボリュームが衝突の際にオーバーラップしないことを保証する）、ダイナミックモデルへの変更を分散する（例えば、上述の２つのイベントの何れかの後で新しいダイナミック状態で関連するクライアントを更新する）ことに責任を負うことになる。
【０１０１】
多数のゾーンマネージャ間でコンピュータ処理ロードを分割すると、環境サイズの複雑さを使用可能なプロセッサ数を増加することによって大きさ設定できるようにする。隣り合うゾーンは密接に結合して、境界の状態は正確に処理されなければならない（ダイナミック表示オブジェクトはゾーン境界を横切って移動し、ゾーン境界の近くに位置付けられる）が、隣り合っていないゾーン間では結合する必要はない。したがって環境がどのような大きさであっても、各ゾーンマネージャにおけるロードは局所化された領域のダイナミックモデル化要求に比例する（すなわち、その割り当てられたゾーン内のダイナミック表示オブジェクトは直ぐ隣のゾーンを加える）。
【０１０２】
さらにゾーンを使用することにより、最初に接続を行ない、接続期間中に各クライアントへ送られるネットワークトラヒック量を低減するのを助ける。これはクライアントが、関心のある領域がアバターを中心とすることを検討することによって達成される。関心のあるこの領域内でクライアントは全てのダイナミック表示オブジェクトの最初の状態と、全てのダイナミック表示オブジェクトへの状態更新の両方を必要とする。関心のあるこの領域の外では最初の状態または状態更新の何れも要求されない。
【０１０３】
例えばアバターが跳ねているボールの隣に位置しているとすると、アバターのクライアントはボールの初期位置と、視覚表示オブジェクトを介してボールのダイナミック動作を正しく表示することになるときのそれぞれの新しい位置とを正しく告げられる必要がある。実際には、クライアントはボールの位置を時折更新させるだけであり、更新の間で、位置をローカルに予測することができる。跳ねているボールがアバターからはるかに離れてしまい、このボールがクライアントの視覚範囲にないときは、最初の状態または状態更新が必要となる。プレーヤはボールに気付かないままであるので、クライアントは同様になる。
【０１０４】
環境のゾーン分割において、クライアントの関心のある領域72はゾーン70の領域として定義され、この領域ではそのアバターが直接に取り囲んでいる全ゾーンの領域に加えられたものとなる。図８ではこれを、垂直方向に無限に延長する正方形ゾーンの簡単なゾーン区分方法を使用する環境において記載している。
【０１０５】
各ゾーン70は関係する状態（その中のダイナミック表示オブジェクトの状態）、およびネットワークトラヒックの関係する量（ダイナミック表示オブジェクトへの変更を記述するメッセージ）をもつ。各クライアント24におけるバーチャル環境の完全なモデルを維持することは、全てのゾーンの状態および関係するネットワークトラヒックを各クライアントへ送ることを要求することになる。しかしながら関心のあるアバター領域72を使用することによって、各クライアントについての要求はそのアバターにとってローカルなゾーンの状態および関係するトラヒックに限定することができる。したがってクライアントへのネットワークリンク23上に置かれたロードは、クライアントのアバターにとってローカルな環境72内の動作に比例することになるが、環境の全体的な大きさまたは複雑さに比例しない。
【０１０６】
アバターのダイナミック表示オブジェクト（例えば図８のＡによって表わすことができる）を生成する際に、関心のある取り囲んでいる領域72におけるゾーン内の最初の状態をアバターと関係するクライアントへ送ることができる。次にクライアントはこれらの領域を“シャドウイング(shadowing)”していると呼ばれ、ダイナミック状態が変更するとき、関係するゾーンマネージャはクライアントに知らせる。クライアントのアバターＡがゾーン境界74を横切るとき、新しいゾーン76が関心のある領域72へ到来する。次にクライアントは新しいゾーンの最初の状態を受取り、図９に示したようにこれらのゾーンにシャドウイングを始める。アバターがゾーン境界から離れるとき、アバターは、関心のある領域72の外に今では位置しているゾーン78のシャドウイングを止める。
【０１０７】
効果的なネットワーク使用に関して、このシャドウイングの停止は、ゾーン境界74を横切って直ぐには行われてはならないことが重要である。シャドウイングを停止することによって、クライアントはゾーン70内の状態変更が分からなくなるので、再接続するとき完全な状態を取り出さなくては（フェッチしなくては）いけない。シャドウイングを直ちに停止した状態でゾーン境界74上で往復(oscillate)しているアバターは、ゾーン状態の記述を繰り返し送るようにする。対照的に、シャドウイングが直ちにドロップされないときは、最初の状態を不必要に取り出すことは拡大した関心のある領域72を犠牲にして避けられる。
【０１０８】
ゾーンシャドウイングというこの解決案は、クライアントが特定の表示オブジェクトに対するダイナミックな更新を必要とするかを判断する際に非常に効果的であることに注意すべきである。ダイナミック表示オブジェクト12が視覚表示オブジェクト14に対する状態変更を分散する必要があるときは必ず、ダイナミック表示オブジェクトはそれが現在置かれているゾーンをシャドウイングしている全てのクライアント24にメッセージを送る。これらのクライアントはシャドウイング状態のおかげで、視覚表示オブジェクト14の例をもち、情報を要求することになる。
【０１０９】
クライアント24のバーチャル環境への最初の接続では、ダウンロードされる状態情報量は、プレーヤのアバターを取り囲んでいる関心のある領域72内のゾーン状態にまで低減される。これにかかる時間はアバターの即座のローカリティ内のダイナミック表示数に比例する。しかしながら、これはワールド（世界）の実際の大きさすなわちダイナミック表示の全体数には比例しないことになる。
【０１１０】
（図１０に示したように）環境のダイナミック表示オブジェクトは多数のゾーンマネージャ28間で分散されるので、ルールマネージャ20から適切なゾーンマネージャ28へのルート設定メッセージ手段を用意することが必要である。ダイナミックオブジェクトが環境内を、したがってゾーンからゾーンへ移動するときに、ルールマネージャはダイナミック状態変更に気付いていないので、ルールマネージャは、どのゾーンマネージャ上で特定のダイナミック表示オブジェクトが現在存在しているかを判断できない。
【０１１１】
必要なルート設定はワールドマネージャ26によって実行され、ワールドマネージャ26は全てのダイナミック表示オブジェクト12のゾーン位置を追跡する。生成後またはゾーン境界74を渡った後の何れかで、各ダイナミック表示オブジェクトが新しいゾーン70へ移動するときには、関連するゾーンマネージャ28はワールドマネージャに現在のゾーンの識別子を知らせる。位置追跡レベルは（ゾーンの大きさに依存して）非常に粗いので、ゾーンマネージャ28はワールドマネージャ26における超過ロードを表わしてはならない。
【０１１２】
ゾーン70をスタートした後で（プロセスは上述でより詳しく記載することにする）、図１０に記載したように、ワールドマネージャ26は関連するゾーンマネージャへの向けたネットワーク接続21を設定する。特定のダイナミック表示オブジェクトへのメッセージを受取るとき、ワールドマネージャはダイナミック表示オブジェクトの現在の位置を調べて、メッセージを適切なゾーンマネージャ28へ送る。次にゾーンマネージャは適切なダイナミック表示オブジェクト12への引渡しを取り扱う。
【０１１３】
もしダイナミック表示オブジェクトが、ワールドマネージャ26がそれにメッセージを伝えることを試行するのと同時にゾーン70を去りつつあるとすると、このメッセージは表示オブジェクトがゾーンを切り替えた後にゾーンマネージャに到達できることに注意すべきである。この場合にゾーンマネージャは“失われた”というメッセージを戻すことができ、ワールドマネージャはメッセージの新しい位置へのルート設定を取扱う。
【０１１４】
各ゾーンマネージャ28は、図１１に示したように全ての隣り合うゾーンマネージャ28への接続30を維持するようにされている。ゾーンマネージャ28間のこれらの接続により、ダイナミック表示オブジェクトはゾーンマネージャ28がゾーン境界を横切るとき、ゾーンマネージャ間で処理されることを可能にする。この状況ではダイナミック表示オブジェクトはゾーンマネージャの規定の管理領域の外側の位置に移動することを要求するという状況では、要求は適切な隣り合うゾーンマネージャへ委任される。要求を完了できるとき（すなわち、要求される位置が衝突を発生しないとき）は、ダイナミック表示オブジェクトの状態は新しいゾーンマネージャへ送られ、新バージョンのダイナミック表示オブジェクトの状態が生成され、そこに記憶される。この状況において、元のゾーンマネージャがワールドマネージャに、それがまだ実行されていないときには、送信先ゾーンをスタートするように要求することが必要なことに注意すべきであり、プロセスは再び下記でより詳しく記載する。
【０１１５】
ゾーンの相互接続30も、衝突検出およびゾーン境界の正しい処理を確実にすることを要求される。図１２は、２つのダイナミック表示オブジェクトＡおよびＢが隣り合うゾーンにおいて衝突し、異なるゾーンマネージャに記憶されるときに発生する問題を示す。何れのゾーンマネージャも他のダイナミック状態に気付かないときには、この衝突は探知されない。したがって各ゾーンマネージャはその全ての隣り合うゾーンのダイナミック状態に“シャドウを付ける”。これは隣り合うゾーンにおいて全てのダイナミック表示オブジェクトのシャドウバージョンを記憶する各ゾーンマネージャ28によって達成される。これらのシャドウバージョンは衝突検出用に使用可能であるが、そのダイナミック状態に対する更新を生成する責任はない。“マスタ”ダイナミック表示オブジェクト（すなわち、それを生成したゾーンマネージャに割り当てられたゾーン内の１つ）がダイナミック状態を変更するとき、対応する視覚表示オブジェクトとシャドウダイナミック表示オブジェクトとの両方に知らせる。ゾーンマネージャは指定されたゾーンのマスタであると呼ばれ、一方で隣り合うゾーンのダイナミック状態にシャドウを付ける。
【０１１６】
このマスタ／シャドウ方法は、図１２に応用されたときゾーン１のゾーンマネージャはＡのマスタおよびＢのシャドウであって、ゾーン２のゾーンマネージャ28はＢのマスタおよびＡのシャドウであることを意味している。Ａ（マスタ）はダイナミック状態を更新するので、ゾーン間ネットワーク接続30（図１１参照）を使用して、ゾーン２のゾーンマネージャ上でＡ（シャドウ）に知らせる。したがってＢ（マスタ）はＡ（シャドウ）と衝突状況を検出し、適切に再結合する。同様に、Ａ（マスタ）はＢとの衝突を検出することができ、Ｂ（シャドウ）のローカルなインストールのおかげと感謝する。
【０１１７】
環境内でゾーンマネージャ28を各ゾーンに同時に与えることを実現する可能性は低い。１０００×１０００ゾーンのグリッドへ分割される環境は、システムのスタートアップ時にゾーンごとにマネージャ上に生成されるときに、１，０００，０００のゾーンマネージャが必要となる。ゾーンマネージャが多数の機械上で分散されるときでも、これはオペレーティングシステム上で支援できないオーバーヘッドを表わす。
【０１１８】
デフォルトによって、バーチャル環境の全てのゾーン70が設計され、システムのスタートアップ時に閉じられ、ゾーンマネージャは割り当てられず、最初のダイナミック表示の状態が持続性オブジェクトメモリ29内に置かれる（ゾーンによってグループ化される）。ワールドマネージャ26はスタートアップ時にこの持続性メモリ29をスキャンして、全てのダイナミック表示の位置を判断する。したがってワールドマネージャ26が概念表示からダイナミック表示への最初のルート設定を行なうことを可能にする。
【０１１９】
ゾーンがスタートされる（すなわち、ゾーンマネージャ28に割り当てられる）のは次のときである：
１）概念表示オブジェクト10が閉じられたゾーン（すなわちゾーンが割り当てられていないゾーン）においてメッセージをダイナミック表示オブジェクト12へ送る必要があるとき；
２）概念表示オブジェクト10がメッセージを特定のゾーン70へ送る必要があり、ゾーンが現在閉じられているとき。概念表示10が環境内の特定の位置において対応するダイナミック表示を生成する必要があるときに必要である；または、
３）隣り合うゾーン70上のダイナミック表示オブジェクト12が現在閉じられているゾーンへ移動したい、例えばアバターがスタートゾーンから閉ゾーンへゾーン境界74を横切ってボールを投げるゾーンへ移動したいときである。
【０１２０】
上述のケース１および２は、ルールマネージャ20にルート設定するときに、ワールドマネージャ26によって検出することができる。ケース２は単に、要求されるゾーンが実行中である（すなわち、スタートした）ときにチェックし、必要であればスタートし、次にメッセージをそれに送ることによって取扱われる。ケース１はワールドマネージャ26が要求されたダイナミックオブジェクト（持続性オブジェクトメモリ29に記憶されている）の現在のゾーンをルックアップし、まだ実行していないときに、そのゾーンをスタートし、メッセージを送ることを要求する。
【０１２１】
ケース３は異なるやり方で取り扱い、ゾーンマネージャを実行して、隣り合うゾーンの一方を要求し始めることに依存する。ゾーンマネージャは、ダイナミック表示オブジェクトが現在閉じているゾーンへ移動する必要があることを検出すると、ワールドマネージャに要求を送る。ワールドマネージャは生成処理を行ない、元のゾーンマネージャは、スタートするときに、新しいゾーンマネージャから接続を受取る。
【０１２２】
ゾーンマネージャ28に対するスタートアッププロセスを次に示す：
・ワールドマネージャ26からゾーンマネージャ28へネットワーク接続を設定する。
・ワールドマネージャから割り当てられたゾーン識別子を受取り、持続性オブジェクトメモリ29からゾーンの現在の状態を抽出する。
・抽出された状態記述から割り当てられたゾーン内に全てのダイナミック表示オブジェクトを生成する。
・隣り合うゾーンの識別子を受取り、現在スタートしたこれらの隣り合うゾーンにおいて、ネットワーク接続を設定するのに適したアドレスを受取る。
・スタートしていない全ての隣り合うゾーンにおいて、持続性メモリから現在の状態を抽出し、これを使用して、シャドウのダイナミック表示を生成する。
・スタートした全ての隣り合うゾーンにおいて、それらを接続して、その現在の状態を受取り、これを使用して、シャドウのダイナミック表示オブジェクトを生成する。
・全ての関連するクライアント24（すなわち、ローカルエリア内にアバターをもつ全てのクライアント）を接続する。
ワールドマネージャ26にゾーンのスタートアップが完了したことを知らせる。
【０１２３】
ゾーンマネージャをスタートするとき、ワールドマネージャ26は全ての隣り合うゾーンマネージャが閉じているかまたは開いていることを保証する。隣り合うゾーンが一緒にスタートするかまたは閉じることを許可されるとき、ゾーン間接続を形成し、持続性メモリ29からの状況にアクセスすることに関連した望ましくない状態が展開する。
【０１２４】
ワールドマネージャ26は有効なサーバ間でゾーンマネージャの生成を分散することによって粗いロードバランスを実行することができる。この分散は、新しいゾーンマネージャプロセスを生成する最も低いプロセスロードをもつサーバを選択することに基づくことができる。その代わりにゾーン間の地理的関係のようなデータは、ゾーンマネージャの要素とすることができ、例えば隣り合うゾーンを取り扱うゾーンマネージャは同じサーバ上に保持されて、ゾーン間の通信遅延を最小にする。
【０１２５】
このロードバランシングの例示的構成を図１３に示した。ルールマネージャ20、ワールドマネージャ26、および持続性オブジェクトメモリ29は第1のサーバ40上に保持されている。さらに2つのゾーンマネージャが局所的に保持されている。第２のサーバ42は4つのゾーンマネージャ28を保持し、第３のサーバ44は3つのゾーンマネージャ28を保持している。各サーバには、新しいゾーンマネージャプロセスを生成し（すなわち、開いたり閉じたりすること）、特定のサーバに関する平均プロセッサロードをワールドマネージャ26へ報告する責務を負うマザープロセッサ46が保持されている。新しいゾーンマネージャ28を生成するとき、ワールドマネージャは有効なマザーに照会して、最小にロードされたものを判断することができる。次にワールドマネージャは適切なマザーに対してゾーンマネージャを生成する責務を委任し、それを子として生成する。
【０１２６】
ゾーンマネージャの生成が無制限に継続することが許可されるとき、多数のプロセスを維持するオペレーティングシステムのオーバーヘッドが大きくなり過ぎる。したがってゾーンを閉じて、その状態を持続性メモリに戻すことができるときを検出できることが好ましい。ゾーンが閉じられるときの基準は次の要素に依存する：
モデル化された環境タイプ；
ゾーンマネージャを支援するプロセッサの予備の処理容量；
ゾーン内で最後に動作が行われてから経過した時間量。
【０１２７】
データに最近アクセスしたとき、直ぐその後でアクセスされる可能性が高く、さらにそれに近いデータにもアクセスされる可能性が高い。同様にＶＥの１つの領域内で動作が行われると、直ぐに再び同じ領域内で動作されることと、隣り合う領域で動作されることとがある。
【０１２８】
ゾーンが閉じられるときの基準は；すなわちゾーンがダイナミックに決定されるという性質になるときに閉じることができることを規定するのがより簡単である。したがってゾーンのダイナミックな記述において関心のあるクライアントまたはマネージャがその現在の状態からゾーンの将来の状態を予測でき、ゾーンマネージャがその役割を最早もたなくなる。この状況において、ゾーンマネージャ28はその現在の状態を持続性メモリへ戻して、終了することができる。
【０１２９】
ゾーンがダイナミックに決定されるという性質であると考えられることを妨げる条件には：位置および方向がクライアント（例えばアバター）の制御のもとにあるダイナミック表示オブジェクトの存在を含む。この状況ではクライアントがダイナミック状態にすることを試行する変更、および制約されていない動作（例えば捨てられたアイテム(thrown item)）におけるダイナミック表示オブジェクトの存在が、ゾーンマネージャによって確認され、さらにおそらくは同報通信されることが必要である。この場合にダイナミック表示オブジェクトの将来の位置は、ゾーンマネージャによって実行される衝突計算に依存する。
【０１３０】
最後の条件は、ゾーンが動作中のダイナミック表示をもつ一方でゾーンが閉じることを除外しないことに注意すべきである。例えば2つの定点間で継続的に往復するダイナミック表示がダイナミックに決定されるという性質である（制約された動作である）とき、その視覚表示またはクライアントがその動作の予測を取扱うことができるときに閉じることができる。
【０１３１】
ゾーンが閉じることができ、閉じるべきであると判断されるとき、ゾーンマネージャは次のシーケンスを行なう：
・ワールドマネージャ26からそれを閉じることができるといった確認を得る。ゾーンの隣の何れかが現在スターとしているかまたは閉じているときに拒否される。
・各隣り合うゾーンマネージャ28からゾーン間ネットワークリンク30を閉じることが有効であるといった確認を得る。これは隣り合うゾーンマネージャが、閉じることを試行するゾーンへ移動しようとするダイナミック表示オブジェクトをもつときに拒否されることがある。
・全てのダイナミック表示オブジェクトの状態を持続性オブジェクトメモリ29へ書き込んで、終了する。
【０１３２】
閉シーケンスの任意の段階が失敗するとき、ゾーンマネージャ28はシーケンスを歪ませず、閉じたネットワーク接続30に再接続し、接触を失った隣り合うゾーンマネージャ28のダイナミック状態を取り出し、ワールドマネージャを使用して閉じた動作を取り消す。
【０１３３】
クライアントは十分な情報を与えられて、関心のあるアバター領域内に必要な視覚表示オブジェクトの全てを生成することが必要である。これを行なうために、ネットワーク接続23はクライアント24と関心のある領域72内の全ての実行中のゾーンマネージャ28との間に形成されなければならない。これらの接続を形成する責務は、ゾーンマネージャ28またはクライアント24、それ自体の何れかに割り当てることができる。
【０１３４】
ゾーンマネージャによるクライアントに対する解決案。この解決案ではクライアントのネットワークアドレスが各アバターのダイナミック表示オブジェクトの状態の一部として得られると仮定する。ゾーンマネージャ28は（マスタまたはシャドウバージョンの何れか）アバターを生成すると、アバターからクライアントアドレスを抽出し、クライアントへ接続する。次にゾーンマネージャ28は必要な状態情報を伝えて、クライアントが全ての必要な視覚表示オブジェクトを生成し、必要に応じてこの状態を更新できるようにする。したがってクライアントはこのゾーンへの接続を終了することができ、これは普通はアバターが隣り合わないゾーンへ移動したときに実行される。
【０１３５】
この解決案におけるクライアント接続を形成する例を図１４に示した。
１）図１４Ａではゾーン２、６、および８は実行中であり、ゾーンの残りは閉じられている。アバターＡはゾーン5へ導かれる。
２）クライアント24からのアバターのダイナミック表示オブジェクトを生成するメッセージによって、ワールドマネージャ26はゾーン５のためにゾーンマネージャ28をスタートする。これによりアバターのダイナミック表示オブジェクトＡのマスターバージョンを生成し（図１４Ｂ参照）、隣り合うゾーン２および６を区別して、シャドウバージョンを生成する。（ゾーン２、６、および５用の）３つのゾーンマネージャの全ては、アバターの導入を探知するとき、アバターと関係するクライアント24から接続を外して、現在の状態を与える。関心のあるアバター領域72は、さらにゾーン１、９、および１０を含み、したがってクライアント24はこれらのゾーンの現在の状態の記述を要求する。これらは、この機能を実行する指定のゾーンマネージャをもたないので、タスクはダイナミック表示オブジェクトのマスターバージョンを生成するゾーンマネージャへ委任される。したがってこの場合にゾーンマネージャ５はゾーン１、９、および１０の現在の状態をクライアントへ与える。これはゾーンのシャドウイングを実行するために現在の状態記述を既に取り出していることになるので、ゾーンマネージャ５は持続性オブジェクトメモリ内に置かれた状態にアクセスする必要がないことに注意すべきである。
３）図１４Ｃでは、プレーヤはアバターＡをゾーン6へ移動している。これにより、ゾーンマネージャ５および６はアバターＡのダイナミック表示に対するマスタ／シャドウの責務を交換する。ここでは関心のあるアバターの領域はゾーン３、７、および１１を含む。これらは閉じたゾーンであるので、ダイナミック表示のマスタになるとき、ゾーンマネージャ６は現在の状態を与えることになる。
４）図１４Ｄでは、プレーヤはアバターＡをゾーン７へ移動している。ゾーン７は閉じられているので、マスタダイナミックオブジェクトをゾーン７へ移動することを試行するとき、ゾーンマネージャ６はワールドマネージャ28にゾーン７をスタートすることを要求する。ゾーンマネージャ７上にマスタダイナミック表示オブジェクトを生成するとき、シャドウバージョンもゾーンマネージャ８上に生成されることになる。次にこれらの両方のゾーンマネージャは、アバター内に埋め込まれたネットワークアドレスを使用して、クライアント24から接続を外す。ゾーンマネージャ８は現在の状態をクライアントへ伝え、ゾーンマネージャ７はゾーン４および12の状態記述を与える。クライアントは既にこれをゾーンマネージャ６から与えられているので、それ自体の状態記述を与えないことになる。クライアントが、そのアバターがゾーン６／７の境界から十分に離れていると判断するとき、ゾーン５への接続をドロップして、関係する状態を削除する。
【０１３６】
上述の記述は最適化されていない解決案を仮定していることに注意すべきである。種々の改良を行なって、クライアントへ送られる情報量を低減することができ、例えばクライアントにおいてゾーン状態をキャッシュして、クライアントのキャッシュされた状態が実際の状態と異なるときに更新するだけである。これは閉じられたまま、したがって変更されないゾーン状態のダウンロードを反復することを妨げる。さらにゾーン境界を横切るダイナミック表示オブジェクトの移動を最適化できるように改良する。例えばアバターが閉じたゾーンへ入ると予期されるときを予測し、前もってワールドマネージャ26に適したゾーンをスタートする要求を出すことができる。
【０１３７】
上述の解決案の代わりの案では、ゾーンマネージャがクライアントがそれらに接続されることを確実にする責務をとるとき、責務をクライアント、それら自体に移す。これは、アバターの概念表示オブジェクトがダイナミック表示オブジェクトを生成するとき、ダイナミック表示オブジェクトが記憶されているゾーンマネージャのアドレスをクライアントへ知らせることを要求する。次にクライアントはこのゾーンマネージャに接続して、ゾーンマネージャが供給するもの：すなわち全ての閉じた隣り合うゾーンの状態、および全ての実行中の隣り合うゾーンに対するゾーンマネージャのアドレスを要求する。次にクライアントは関心のある領域72内に全ての実行中のゾーンマネージャへの接続を形成することができる。ダイナミック表示オブジェクトがゾーン間を移動するので、プロセスは反復され、クライアントは関心のある領域内の全てのゾーンマネージャへの接続を維持する。
【０１３８】
この解決案の長所はクライアントが関心のある固定領域に制限されていないことである。実効バンド幅、環境内の動作、および環境のタイプに依存して、クライアントはゾーンマネージャ接続数を変化させることによって関心のある領域を拡大するかまたはそれと契約することを望む。対照的に代わりの解決案では、ゾーンマネージャはクライアントへの接続を形成して、関心のある領域をアバターが現在隣り合っているゾーンと結合しているゾーンへ固定する。しかしながらゾーンマネージャに接続の責務を置くことによって、（関係する遅延、およびこれが必要とするバンド幅使用に関する）ゾーンのスタートした／閉じた状態のクライアントの照会が避けられる。クライアントへの接続は、ゾーンマネージャがアバターの存在を検出するとき自動的に行われれる。
【０１３９】
図６に示したアーキテクチャの1つの可能な向上は、マルチキャストアドレスを各ゾーンマネージャ28、したがって各実行中のゾーンと関係付けることである。各クライアントは、ゾーンマネージャとの接続を形成するとき、関係するマルチキャストアドレスへも接続する。これにより、ゾーンマネージャ上にロードを位置付けずにクライアント間で一時的な視覚効果が伝えられる。例えば挨拶をするときにアバターに手を振らせることは視覚効果の１つであり、ＶＥの状態に永久的な変化を与えない。この動作を実行する命令は、アバターの現在のゾーンと関係するマルチキャストアドレスを介して分散できる。これは、その関心のある領域がアバターのゾーンに囲まれている全てのクライアントが、命令を受取ることを保証する。次に各クライアントにおけるアバターの視覚表示オブジェクトは手を振る視覚効果を実行する。
【０１４０】
さらにマルチキャストアドレスを用意して、ゾーンマネージャに対する不確実な分散機構を用意する。既に記載したゾーンマネージャのクライアントへの接続23は全て、クライアントが初期状態の正確な記述を受取ることを確実に保証すると仮定される。しかしながら性質上反復する状態更新は（例えば、移動オブジェクトの位置更新）は確実なやり方で伝えられる必要はない。最後の更新が確実に伝えられ、視覚表示オブジェクトが一定の予測および補間を与えるとき、中間の更新を失うことは問題とならない。
【０１４１】
実行すると、ゾーンマネージャ28は次の責任を負う：
・それらに伝えられるダイナミック状態に対する更新を要求するネットワーク接続のリストを維持する。このリストはダイナミック表示オブジェクト（ゾーンマネージャによって生成される）によって使用され、その状態への変更を分散する。このリストは、関心のある領域がゾーンと交差して、ゾーンマネージャが隣り合うゾーンに割り当てられるクライアントから構成される。
・（ワールドマネージャ26を介してルート設定されて）ルールマネージャ20内の概念表示オブジェクト10から適切なダイナミック表示オブジェクト12へメッセージを伝える。
・視覚表示14から適切なダイナミック表示オブジェクト12へメッセージ（例えば、アバター位置を更新する）を伝える。
・全ての隣り合うゾーンのダイナミック状態のシャドウイングを用意する。
・ダイナミック表示オブジェクトに対する衝突検出機能を用意して、それらが新しい位置の妥当性を試験できるようにする。
・それらに要求するダイナミックオブジェクトに対して処理時間スライスを用意する。例えば、環境内で跳ねているボールは規則的にその位置を再計算して、衝突に対して新しい位置を試験することが必要である。
・例示的な交差ゾーン境界として、ゾーンマネージャ間でダイナミック表示オブジェクトのハンドオーバを同期化する。
・ゾーンを閉じる実効条件に対してゾーン状態をモニタする。
【図面の簡単な説明】
【図１】  ＶＥのエンティティを表わす図。
【図２】  本発明の第１のネットワークアーキテクチャを表わす図。
【図３】  図１のアーキテクチャの素子間のメッセージングの対話を示す図。
【図４】  第２のネットワークアーキテクチャを表わす図。
【図５】  ＶＥマネージャ間の通信チャンネルを表わす図。
【図６】  本発明の第３の実施形態を表わす図。
【図７】  バーチャル環境をゾーンに細分した２つの例を示す図（図７Ａおよび７Ｂ）。
【図８】  所定のゾーンにおける関心のある領域を示す図。
【図９】  関心のある領域の移動を示す図。
【図１０】  図６に示した構成においてワールドマネージャをゾーンマネージャ接続に接続した図。
【図１１】  ゾーンマネージャ相互接続の例を示す図。
【図１２】  ゾーンの境界線における２つのダイナミック表示オブジェクト間の衝突を示す図。
【図１３】  本発明の別の実施形態を示す図。
【図１４】    本発明の実施形態にしたがうゾーンマネージクライアント接続を形成する例を示す模式図（図１４Ａ、１４Ｂ、１４Ｃ、および１４Ｄ）。
【図１】
0004354634.tif 000002
【図２】
0004354634.tif 000003
【図３】
0004354634.tif 000004
【図４】
0004354634.tif 000005
【図５】
0004354634.tif 000006
【図６】
0004354634.tif 000007
【図７】
0004354634.tif 000008
【図８】
0004354634.tif 000009
【図９】
0004354634.tif 000010
【図１０】
0004354634.tif 000011
【図１１】
0004354634.tif 000012
【図１２】
0004354634.tif 000013
【図１３】
0004354634.tif 000014
【図１４】
0004354634.tif 000015