Multiverse Platform Architecture

From Multiverse

Jump to: navigation, search

Multiverse Servers

Installing • Installing on Linux • Running • Troubleshooting • FAQ • Release Notes • Updating • JMX Monitoring & Mgmt.

Infrastructure

Platform Architecture • Registering a World • Proxy Server • Event Handling • World Manager • Voice Server

Messaging System

Perception Messaging • Using Extension Messages • Message Marshalling • Multi-subject Messaging • Message Catalog

Object Architecture

World Instancing • Server Object Search • Server Regions • Server Markers

Scalability and Performance

Overview • Scalability Testing

Reference

File Layout • Property File • Logging • API

1 Platform architecture
2 Game world geography
3 References

[edit]

Platform architecture

Conceptually, there are two levels of architecture: that of the Multiverse Network as a whole and the architecture for a single world. The Multiverse Network, Inc., provides the overall infrastructure for the network, while each independent game developer runs a customized world system.

[edit]

Network architecture

Figure 1 illustrates how a client logs in to the Multiverse Network, which enables the client to connect to a world server.

Fig. 1 - The Multiverse Network

The objects in this figure are:

Client: program that runs on the end-user's computer. It contains the graphics rendering engine that provides the 3D game experience within worlds in The Multiverse Network. It includes a user interface API that enables developers to provide a custom UI for their games. Also includes the update program that contacts world update servers.
Master server: centralized server that functions as a sort of dual DNS and LDAP server. Maintains all end-user account information and references to all worlds in the Multiverse. The client uses it to find a desired world and connect to it. The client also reconnects to the master server when a player-character moves from universe to universe.
Multiverse user database: master database containing all users' Multiverse login ID information, including billing and age data. Accessible only by the master server.

The master server and the Multiverse user database are controlled and operated by The Multiverse Network, Inc. Together, they control user access to the world servers that are owned and operated independently by game developers.

In a development configuration, you can bypass the master server and connect directly to your local world server. For multiuser testing and deployment to customers, you can register your world with Multiverse so users can connect to it through the master server.

[edit]

Login process

Fig. 2. - Login process

As illustrated in Figure 2, a user logs in to the Multiverse Network and connects to a world server as follows:

A user with the Multiverse client logs in to the master server using his Multiverse user name and password.
The master server consults the Multiverse user database that contains billing and age data for all users. After authentication, the master server returns a unique session ID token to the client. The session ID may have a certain authorization level, based on the user's age or other criteria.
The user (client) then requests a particular world from the master server.
If the client is authorized to connect to the requested world (based on the authorization level of the session ID), the master server returns a token that enables the client to connect to the desired world server.
Update server sends updates to the client, so the client has the latest assets and configuration data for the world.

[edit]

World architecture

Once a user is logged in to The Multiverse Network, he can enter any world for which he is authorized. Each gameworld runs on a suite of Multiverse servers. Figure 3 illustrates the Multiverse world archtitecture.

Fig. 3 - World architecture

The world-specific servers consist of:

Proxy Plug-in: handles communication between the client and all other services. Also handles login and character creation for a world.
World Manager Plug-in: controls a world's geography and what PCs and mobs are able to see.
Login Plug-in: character selection and creation
Message Domain Server: facilitates messaging among server processes.
Object Manager Plug-in: saves and retrieves permanent object data to and from the world database server. Communicates with the database using JDBC.
World Database: contains all of the world's persistent information. By default, this is a MySQL database, but can be any JDBC-compliant database. Note: This database is distinct from the Multiverse user database.
Other server plug-ins: handle gameplay and other world features. Each plug-in server can run independently on one or more physical servers and can include:
- Mob server: controls mobs and NPCs.
- Combat server: controls combat functions
- Inventory / trading server plug-in: controls objects and secure trading.
- Other custom plug-ins

You, the independent game developer, control and operate all the above servers. They can run on separate hardware platforms, if desired, for improved performance.

Not shown in the figure is the Multiverse update server that provides the Multiverse client with the latest software. The client always updates itself and its media asset repository before it attempts to log in to a world.

Figure 2 illustrates how a client connects and interacts with one world, with the process continuing from the previous figure:

With the login token returned by the master server in step 4, the client logs in to the world's login server.
Login server returns to the client a reference to the world proxy server. Henceforth, client interacts with the world via the proxy server.
Client loads world-specific meshes, materials, user interfaces, etc. from the assets.

The plug-in servers communicate using the Multiverse Messaging System, a sophisticated publish/subscribe messaging system that enables loosely-coupled, reliable, communication among disparate services, regardless of their physical location. The Multiverse Messaging System enables seamless handoff across physical servers, minimizing lag, zoning problems, and other network issues. Clients communicate with Multiverse Proxy Servers using TCP or Reliable Data Protocol (RFC-908 and RFC-1151), an efficient yet highly-reliable network protocol.

[edit]

Game world geography

Multiverse version 1.1 does not support "instance dungeons" (player-unique world instantiations). This feature will be available in the upcoming version 1.5.

[edit]

Instances

The world geography is broken up into one or more instances. An instance has a single contiguous geography (called a zone) defined by a single world file. There is no visibility between instances. Moving between instances requires a loading screen.

[edit]

Zones and regions

A Multiverse zone is the highest level concept of geography for the Multiverse system. A zone is defined by a three-dimensional grid of integers, with a one millimeter resolution. That is, the spacing of the points in the grid is one millimeter. Each axis of the grid goes from -2 billion to +2 billion. Thus, the size of a zone is a cube four thousand kilometers on a side.

Every zone:

Is a cube 4,000 km per side (64,000,000,000 km³)
Has its own coordinate system.
Can run on more than one server to distribute load.

[edit]

Regions

Zones are dynamically partitioned by a quad-tree. The topmost level of the quad-tree represents the entire zone, which is then divided into 4 equal sized regions by the quad-tree. The four new regions cumulatively cover the entire space of its parent node. As leaf-nodes (nodes that have no children) become populated by objects and users, the server will further subdivide regions using the same algorithm.

All objects are placed into the quad-tree to make it easier to find out what is near an object. This allows the server to consider only a subset of all objects it knows about when performing distance checks. For example, when a user moves around and comes close to an object, the server tells the client about the new object. Using the quad-tree nodes, the server compares the client's distance only with objects within the user's current quad-tree node and perhaps adjacent ones.

Although the quad-tree optimizes server performance, it doesn't solve the overall scaling issue. At some point the server can have more objects and users than it can handle. The server needs to off-load processing of a portion of its users to another server. To do this, the server chooses a node in its quad-tree and moves that whole branch off to another server. All objects and users are serialized and sent over to the new server. When a client moves into the transfered region, the server will hand-off the client to the new server. The parent server still runs all adjacent regions. The parent server will remain in communication with the sub-server and if the subregion become unpopulated, can trigger a re-integration. When a client is near an edge which is run by two different servers, it will get information about both regions from the parent server.

[edit]

Multiple instances/zones

When do you need a new instance (as opposed to a quad-tree region)? When you cannot fit your content into an existing instance, you need to create a new instance. This may happen in the following scenarios: your world is extremely big or the new area does not occupy the same space, as is with instanced dungeons, or if you enter a house that is bigger than its physical structure. Instances are also used to partition large player populations or create private spaces.

When a PC moves from one area to another, it is called instancing or zoning. The client will switch to a loading screen while it's loading the new zone. Game developers have to keep this in mind when designing gameplay. The client does not see or know about zones other than the one it is occupying.

[edit]