PLATFORM ARCHITECTURE  

 Conceptually, there are two levels of architecture: the master server which can control accounts and world server details for multiple worlds, and individual game worlds. 

NETWORK ARCHITECTURE  The objects are: Client: A game created in Unity 3d that includes the Atavism System files. 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. The client uses it to find a desired world and connect to it. Master Database: database containing all users' login ID information, including billing and age data. Accessible only by the master server. World Server: a server that runs the world for a game. Has multiple plugins that allows features such as mobs, combat, inventory and more. World Database: stores the state of persistent objects in a world such as player characters. Content Database: stores content data for a game such as the mob templates, item templates, quests etc.  

LOGIN PROCESS  A user logs in to the Master Server and connects to a world server as follows: A user with the client logs in to the master server using his user name and password. The master server consults the Master 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. 

WORLD ARCHITECTURE  Once a user is logged in to the Master Server, he can enter any world for which he is authorized. Each gameworld runs on a suite of world servers.  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. 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.  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 Atavism Messaging System, a sophisticated publish/subscribe messaging system that enables loosely­coupled, reliable, communication among disparate services, regardless of their physical location. The Atavism Messaging System enables seamless handoff across physical servers, minimizing lag, zoning problems, and other network issues. Clients communicate with 

Atavism Proxy Servers using TCP or Reliable Data Protocol (RFC­908 and RFC­1151), an efficient yet highly­reliable network protocol. Game world geography 

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 scene. There is no visibility between instances. Moving between instances requires a loading screen. 

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. 

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. 

World Nodes  World Nodes are the physical manifestation of a concept, for example a boat that can contain things that are located and move relative to the boat.