TechnicalOverview

ThereWiki | RecentChanges | Preferences

In technical terms, the service offered by ThereInc is access to a MetaVerse or simulated universe. At present the MetaVerse consists of PlanetThereia, some surrounding space and a very large number of simulated objects including avatars for service subscribers. Access to the MetaVerse is gained through the ThereClient, an application that runs on a subscriber's personal computer.

There are two major classes of object in the MetaVerse:

Each dob and pob has a unique Object IDentifier or oid. The oid for a dob is referred to as a doid; that for a pob is referred to as a poid.

As well as these "first class" objects with oids, the following "second class" objects manifest in-world:

The second-class objects have no oids of their own; instead, the avatar owning such an object posesses a pob giving rights to make use of a copy of the object, for example to wear an item of clothing or to place an item of furniture in a zone.

The MetaVerse simulation is performed by a distributed network of SimulationHosts, each of which runs identical simulation algorithms on a set of THere OBjects, or thobs. Each thob represents a particular dob manifested in the Metaverse, and is identified by the dob's doid. Although there will only ever be one dob with a particular doid, there may be any number of SimulationHosts each containing a thob for the same dob, and all these thobs will share the same doid. This happens because at any given time a number of different SimulationHosts will be simulating overlapping collections of dobs due to the way that the simulation of the whole MetaVerse is decomposed and replicated:

For example, if you take a buggy out of inventory so that it appears in-world, a thob for that dob will be created on:

All of the SimulationHosts perform the same algorithms on the set of thobs they contain. However, they may all be working on different sets of thobs and of course some of them (the uhosts) are untrusted. The SimulationHosts may therefore disagree over time about, for example, the position of the buggy. These conflicts are resolved by designating exactly one of the thobs for each dob as the sob (Server OBject); the sob is always authoritative and in the case of a conflict, the other thobs (called clobs, or CLient OBjects) will defer to the sob.

For example, if you walk through the space occupied by an obstacle that is invisible to you because it has not "loaded" to your ThereClient, your uhost calculates you at a position beyond the object. The ihost for the sector you are in knows about the obstacle and calculates that your avatar will stop when it reaches it. In this case, the thob in the ihost is the sob, while that in your uhost is a clob. Visually, you will observe your avatar walking past the (invisible) obstacle and then being "rubber banded" back when the clob's state is updated to match the sob.

When a dob moves from one sector to another, a hand-over process is performed during which the thob in the new sector becomes the sob, while the thob in the old sector becomes a clob. At present, thobs hosted by uhosts are always clobs and never sobs.


ThereWiki | RecentChanges | Preferences
This page is read-only | View other revisions
Last edited April 10, 2004 7:51 am by IanYoung (diff)
Search: