The idea is that, unlike many existing gaming systems, objects in the world have true persistence and true state (though entities keep their state in the entity server, not the world). It also has to glean consensus from the physics engines rendering the scene (which the world server can't quite fully trust), to determine the proper physics which is occuring. The world server mantains the position (or current state vector) of objects in the world. Generally worlds are broken internally into Scenes. The world server provides the state machine and status for all entities in the world. But, there's nothing much more useless than blockchains that aren't shared amoung several organizations. The idea is also to keep blockchain journals for logging. In any case the Kudo server has grown into a generalized secure bookkeeping system which includes cryptography certifications, authentication and authorization. In a way it is a type of cryptocurrency that is not intended to be traded, but that a group sharing a blockchain could agree that a given user owned a given kudo. The idea for Kudos originally was for awards given in games, like the player's level, or certifications of skill. This is similar to running javascript or webassembly sandboxed in the web browser. EmissariesĮmissary is a name I chose for well structured, digitally signed, webassembly sandboxed components from the worlds, entities and avatars (and perhaps kudo servers), which run in the browser.
Eventually it might even possible to have have the browser run on a cluster of computers. They communicate in various ways, via gRPC, but also with mutexes and there is consideration for the caches to operate with shared memory or memory-mapped files. The code for these is directly in this solution as. There are a handfull of potential side components are emissary servers, mesh engine, and image and mesh caches.
It also will make more of these if the user is in more than one world-scene at a time (like multiple tabs in chrome). Then there are a fleet of processes, handling mostly the emissaries from the various world components (the world itself, entities, and the control of the avatar). There's a main visualization component of the browser itself (running Unity, possibly connected to a VR HMD). The browser is designed to act somewhat like the multi-process nature of Chrome. net solution hosts all of the code that is not in the browser (and some libraries that will be used by the browser).
0 kommentar(er)
