!! IronicDemo Services Layout

Introduction

The service architecture behing and MMORPG is complex and daunting to the initiated. The terms may seem foreign the and the purposes of certain services easily confused. This document will explain our vision of the service architecture, the various services that make it up, the purpose of those services and how the user interacts with those services.

Service Architecture

Summary

The service architecture described here will be broken into several layers:
1. User Layer
1. Global Layer
1. Shard Layer
1. Server Layer

Each of these layers play a unique but very dependent part on the overall architecture. They work together to provide secure layers of functionality that work seamlessly together through messaging.

User Layer

The user layer is comprised three basic components of software:
1. Web Browser
1. Client
1. Admin Client

Web Browser

This component is the easier to explain. This component's target audience will be both players and administrators. This component is not maintained by Ironic Entertainment. It can be any W3C compliant web browser such as Internet Explorer, Firefox or Opera. It it used to communicate with the WAT (Web Admin Tool.)

Client

This will be the most commonly used software component. The target audience is the typical player. This is the way players interface with the game. It uses the LS (Login Service) to authenticate with the world and in turn the LS provides the client with the address and credentials necessary to connect to an FES (Front End Service,) which presents the core game world to the client. The client may also reference the MAPS (Media And Patching Service) to upgrade its binaries or download updated content.

Admin Client

This will be the most complicated User Layer component. It will combine the features and functionality of the Client with additional functionality aimed at Game Masters, Server Administrators and Content Developers.

Game Masters

It will allow GMs to ad-hoc update AI state and scripts, spawn mobs at-will, seize control of simulation objects (and impersonate them if they are performers) as well as manipulate player data (including, but not limited to, things like banning, making 'call notes' and adjusting certain statistics.) The ability of a GM to perform these functions will be governed by a simple ACL system. This will give us flexibility to gradually allow GMs control over the game world as we grow to trust them or train them in certain aspects.

Server Administrators

The Server Administrators will have the full rights of a fully enabled GM but will also be able to directly interact with the AS (Admin Service) to do things such as dynamically adjust SZS (Seamless Zone Service) zone boundaries, shutdown and start up services, change global access rights to an entire shard (for example turn an entire shard into an ADM only server while an issue is being troubleshot) and they will have a global view of the game inner workings.

Content Developers

The Content Developers will have a small subset of the overall GM roles and rights but will have functions specific to sandboxing to real-time test new content. A content developer will be able to join a server such as a development server and then spawn non-production simulation objects, their game rules and the media related to them. This will allow artists to see their work on a real server. It will also allow content developers and game rule editors to test new simulation objects without having to run their own local copy of a server, reducing testing time and allowing them to tweak their creation on the fly.

Global Layer

This layer is comprised of several components. It represents all components and services that are not unique to a piece of hardware or a logical game shard.
1. MAPS (Media And Patching Service)
1. WAT (Web Admin Tool)
1. LS (Login Service)
1. AS (Admin Service)

MAPS (Media And Patching Service)

This is a pretty simple and self-explanatory service component. When content developers and programmers are ready to release new binaries, libraries, configurations or content this data will be published in this server. When a client connects to a shard that shard (the WS, or Welcome Service) will provide upstream information about the version of that shard. The client must match that version or upgrade to that version. If the client is newer than that version it will be unable to connect to that shard.

WAT (Web Admin Tool)

The web admin tool has two audiences: players and administrators. The players will use this tool to do various account, character, guild and community related activities. Administrators will use it to work with the AS to manipulate servers, services and shards as well as to manage players and accounts.

LS (Login Service)

The LS is the server primarily involved authenticating users and determining what their access levels are. The LS maintains a global RDBMS called RDBMS-Users. This is where all account and user information is stored. Users are global and not specific to a shard, unlike the characters. The LS will act as a middle-man with the WS to determine what FES to connect a user to.

AS (Admin Service)

The AS is a pretty basic service component. It heavily uses a service in a much lower layer called the AES (Admin Executor Service.) The primary purpose of the AS is to replicate out administrative changes to the various services in the game. This can be things such as global configuration updates (such as broadcasting to all services a pertinent piece message) and service management duties. The primary purpose for the AS will be service management duties, which allows an administrator from a central location to startup and shutdown services. An example of this activity would be to shut down the RMS (Regional Management Service) and start it up on a new server. This activity, obviously, would encur an outage related to the functionality of this service until the new copy completed starting.

Shard Layer

The shard layer is the most complex layer and contains the most service components. Each shard has its own RDBMS to manage and maintain persistent world state as well as several services for managing world logic. The following are the service components relevent to this layer:
1. WS (Welcome Service)
1. FES (Front End Service)
1. SZS (Seamless Zone Service)
1. AIMS (AI Mini-Service)
1. RMS (Regional Management Service)

WS (Welcome Service)

TODO
The WS acts as a permissions test and a load balance for new clients connecting to a shard. It decides whether a user is ultimately allowed to connect to a shard, creates the cookie (credentials) that allow a client to connect to the shard and decides on an FES to connect that client to, based on various metrics such as user count and overall load.

FES (Front End Service)

TODO
The FES is where the core game logic happens. In reality the FES is a load manager and a message director for clients. It reduces the number of connections that the various clients need to manipulate the world and provides intelligent routing of messages.

SZS (Seamless Zone Service)

TODO
The SZS manages objects within a defined zone area and manages proxy stubs for clients in bordering zones. This allows us to divide up the world into several services and/or servers without the client noticing. This allows us to have much greater saturation of areas. Additionally the SZS will allow runtime adjustment of zone boundaries so that we can adjust the proximity based on things such as special events, new dungeons, etc.

AIMS (AI Mini-Service)

TODO
The AIMS is more of a "super client" than a service, hence the name 'mini-service.' It will act like hundreds or thousands of clients, separating AI from the game logic. There may be several of these depending on how intense the AI systems become and how many AI agents we deploy.

RMS (Regional Management Service)

TODO
The RMS manages regional information, data and logic. Examples of game logic involved in this would be managing weather systems, global (OOG) chat systems, etc.

Server Layer

There really only is one service component on the server layer: the Admin Executor Service (AES.)

AES (Admin Executor Service)

The primary purpose of this service is to replicate back any information or statistics of services running on a physical piece of hardware to the AS. The AS will also issue the AES startup and shutdown commands to manage the run-state of the various services that can run on the particular piece of physical hardware.

Component Processes

Client and Admin Client Login

_TODO

Service Layout Figure

• Draft Version of the Service Layout:

Service Layout Physical Figure

• A diagram of the physical layout of services and servers.:

-- Main.MattRaykowski - 27 Jul 2006