Meru Virtual World Architecture

People:

Stanford: Daniel Horn, Ewen Cheslack-Postava, Tahir Azim, Behram Mistree, Philip Levis
Princeton: Mike Freedman

Introduction:

We believe that one of the next major application platforms will be 3-dimensional, online virtual worlds. Virtual worlds are shared, interactive spaces. Objects inhabit the space, have programmable behaviors, and can discover and communicate with other objects. Users commonly experience the world through an avatar and can interact with objects in the world, much as they would in the real world. Many currently deployed applications are virtual worlds: multiplayer online games such as World of Warcraft and social environments such as Second Life are popular examples. Other examples include environments for virtual collaboration, distance learning applications, and augmented reality.

Unfortunately the early evolution of virtual worlds has been ad hoc. They have completely independent constructions, share few architectural aspects, and offer little or no interoperability. Because these systems are designed for very specific applications, each suffers from at least one of poor scalability, centralized control, and a lack of extensibility.

The Meru Project is designing and implementing an architecture for the virtual worlds of the future. By learning how to build applications and services before they are subject to the short-term necessities of commercial development, we hope to avoid many of the complexities other application platforms, such as the Web, have encountered.

Virtual World Components:

Meru addresses the issues of scalability and federation by carefully separating the components of a virtual world. The core components of any virtual world system are the simulation of the world, the simulation of individual object behaviors, and the storage and distribution of the content of the world. The Meru architecture separates these concerns:
  • Object Host: handles simulation of individual objects: receiving messages, handling events, and simulating behavior using user-created scripts.
  • Space: handles inter-object behavior: it gives objects names in the world, helps objects discover the names of other objects they might be interested in, enables communication between objects, and might provide physical simulation such as rigid body physics.
  • Persistence Services: handle storing and serving the large, read-mostly data a virtual world needs, such as textures and meshes.

Space Architecture:

Currently we are focusing on the architecture of space servers. They provide four basic services:
  • Naming - the space is a communication medium for objects, so it must give them names they can use to refer to each other. In this sense, the space can be though of as an address space. We use a simple flat namespace and assign these identifiers randomly.
  • Discovery - in order to send messages, objects must have other objects' identifiers. The space must provide a way for objects to discover other object identifiers. Of course this mechanism should aim to return the identifiers of the most relevant objects to the querier.
  • Communication - the space acts as a communication medium and mediates all inter-object messages. It must provide routing of messages and possibly apply rules to restrict communication.
  • Physical Simulation - much physical simulation depends on the state of multiple objects, and is simplified by having a single authoritative simulator. The space may provide some form of physical simulation, ranging from simple collision detection and response to a complex rigid body simulation, depending on what the particular world calls for.
We are designing our space service to handle all of these scalably. Some specific challenges we face in designing and implementing the components that provide these services are:
  • Efficient and Scalable Discovery - most existing systems use a simple distance cut-off approach to discovery, where all objects within some radius will be returned. While it is known how to efficiently implement this approach when the radius is relatively small, the nature of the query requires the radius to be large to find the majority of objects that are important. Further, these systems return many objects that could be quickly discarded as irrelevant. We're looking into different types of queries that more efficiently find important objects, but can still be implemented efficiently and scalably.
  • Scalable Communication - without restrictions on communication, object messaging can very quickly overload the system, leading to poor service for everyone. We are investigating how we can control message queuing to provide physically plausible quality of service under load while making the best use of resources when not under load.
  • Load Balancing - interests naturally collect -- we know that interests often follow a Zipf distribution. This implies that as the world grows, the maximum load on a single space server using fixed size regions will increase. The resulting problems are already evident in most other systems that split their worlds into fixed sized regions: a few central hubs are overloaded or the number of participants is simply capped to avoid the problem. Instead, we are investigating ways to balance the load by dynamically segmenting the world, allowing loaded servers to split in order to double available bandwidth and compute power, and underloaded servers to merge so unused regions do not waste resources.

Publications:

[1] Daniel Horn, Ewen Cheslack-Postava, Tahir Azim, Michael J. Freedman, Philip Levis, "Scaling Virtual Worlds with a Physical Metaphor," IEEE Pervasive Computing, vol. 8, no. 3, pp. 50-54, July-Sept. 2009, doi:10.1109/MPRV.2009.54