In technical terms, the service offered by MakenaTechnologies 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:
- Distributed OBjects, or dobs, can manifest in the world and participate in MetaVerse physics by, for example, colliding with other dobs.
- Paper OBjects, or pobs, exist only in an avatar’s inventory and are used to represent ownership rights over dobs and other “legal” functions.
As well as these “first class” objects with oids, the following “second class” objects manifest in-world:
- Avatar accoutrements such as clothing and hair. These can only manifest when worn by an avatar.
- Add-on kits such as furniture and structures can only manifest when placed in a zone such as a FunZone, house or PortaZone.
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:
- The planet-sized MetaVerse is divided along geographic lines into a large number of much smaller sectors. Each sector is associated with exactly one SimulationHost called an ihost (“internal” host); ihosts run on server machines at MakenaTechnologies. An ihost hosts thobs for all dobs currently located in the sector, and some thobs for dobs in nearby sectors.
- Every currently connected subscriber’s ThereClient contains a SimulationHost called a uhost (“user” host) which hosts thobs for all dobs “visible” to the subscriber’s avatar. The visibility of a dob to a particular avatar is determined by another set of “view” servers.
- The ihost corresponding to the sector you are standing in,
- Possibly, ihosts corresponding to some neighbouring sectors,
- The uhost running as part of your ThereClient,
- The uhosts running as part of the ThereClients of anyone whose avatar can “see” the buggy.
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.