සංග්‍රාම - Distributed Coordination Architecture for MMOGs

Initial Project Proposal of "Sangraama"

Dept. of Computer Science & Engineering, University of Moratuwa

Sangraama

Distributed Coordination Architecture for MMOGs

Project Supervisors

Dr. Srinath Perera & Ms.Vishaka Nanayakkara

Project Members

Chandima Dileepa Rajaguru, Gihan Karunarathne, Amila Dissanayake, Denuwanthi De Silva

12/03/2013

1. Brief Idea

This project is on implementing improved/combined distributed coordination architecture for MMOGs (Massively Multiplayer Online Games).

2. Introduction

Massively Multiplayer Online Games have become very popular nowadays. Main facts about MMOGs are thousands of concurrent players and huge game world. The ‘Distributed’ aspect of these games is an interesting area for game developers. There are specific challenges in developing MMOGs. Effect of latency, performance, security and game cheating are some of the key challenges which should be addressed in MMOGs development.

There are several architectures used in MMOGs. Basic architectures in use are client-server and peer-to-peer. Client-Server architecture is more popular due to the ease of implementing. There are separate architectures to handle the ‘Distributed’ nature of these games too. Matrix, Colyseus, are some implementations done to overcome key challenges in MMOG.

Examples:

Matrix: Unique portions of the MMOG's map are assigned to different servers. There is one game server and one Matrix server associated with that unique region. Game server handles the game logic. If an event takes place in an intersected region, the Matrix server sends updates to the servers. Matrix Coordinator server keeps computing and updating the intersected regions in Matrix servers.[2]
Colyseus: Distributed architecture for interactive multiplayer games designed to achieve scalable and efficient state and logic partitioning that enables reasonably consistent, low-latency game-play in a widely distributed environment with no centralized management.[3]

Game State distribution is mostly handled using zoning (game world partitioning), instancing and replication (keeping duplicate objects in nodes and updating them). Sometimes, a combination of those methods is also used. It is all about finding an efficient distributed architecture.

We try to provide the developers the chance to experiment on developing games using different algorithms and architectures. Furthermore, we hope to provide performance analysis on different architectures and introduce optimal architectures.

During our project we focus on learning about the architecture already in use in MMOGs, and implement some of them that look promising. That will give us much better understanding about algorithms in use, and then we can try to improve/ combine those algorithms. There are lots of room to improve, specially learning from parallel programming paradigms.

3. Importance of the project

Through this project, we implement few promising architectures and evaluate key strengths and weaknesses of those architectures. The results of the observations will be useful for the future MMOG implementations which are more scalable, strong in performance and fault tolerant. One of the major outcomes of this project is an open source framework for the game developers that give an interface to develop similar MMOGs. By using this framework, developers do not have to bother about developing the lower level of the distributed coordination in MMOGs.

4. Project Objectives

Carry out literature survey on different architectures of MMOGs. Compare and contrast the identified architectures of MMOGs.
Implement few classical architectures and evaluate them in perspective of scalability and performance.
Optimize the implemented architectures and come up with a framework to handle the distributed coordination of MMOGs.

5. Scope

Project Scope is on distributed coordination architecture designed for MMOGs. In this project our initial focus is on the basic and classical architectures used to build MMOGs. We will research about the basic qualities of existing architectures such as performance and scalability. Then we will continue our research to optimize those classical architectures or design new architectures to support MMOGs. We will implement one or few architecture and evaluate the functionality in the perspective of scalability, performance and other qualities. We hope to research about existing algorithms used to handle distributed coordination and use them in more beneficial way to face the challenges in MMOGs development.

6. Deliverables

Initial Project Proposal
Project Website
Project Report
System Requirements Specification
Two Videos
Project Implementation (Framework for distributed coordination of MMOGs)
Research Publications

7. Assumptions/Limitations

MMOG architectures have both client-server and P2P (Peer to Peer) architectures. Even Though Client-Server based implementations can be found easily, P2P based implementations are quite rare and the algorithms used in are complex. There are no good implementations for DHT (Distributed Hash Table) in P2P. It takes approximately four years for a MMOG to be developed.[2]

The basic approach in most MMOGs is to divide the game world into regions. We have to focus on optimizing that approach, as it would be rather time consuming to come up with a completely new approach. Nevertheless, we will not abandon the chance for a completely new idea too.

HttpServlet init(ServletConfig) Method

When using HttpServlets, most people get confused of the usage of the 'init' method. There are two 'init' methods, that are associated with servlets: init() and init(ServletConfig). When we want to do some startup work, in the servlet we override 'init(ServletConfig)' method, in our servlet class, not the no-argument init() method. The no-argument init method is called from inside the init(ServletConfig) method itself.

Let's go through an example, which prints out 'HelloWorld!!', with the tomcat server startup.

package com.example.servlets;

import java.io.IOException;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

/**
 * Servlet implementation class InitServlet
 */
public class InitServlet extends HttpServlet {
    private static final long serialVersionUID = 1L;

    /**
     * @see HttpServlet#HttpServlet()
     */
    public InitServlet() {
        super();
    }

    public void init(ServletConfig config) throws ServletException {
        super.init(config);
        System.out.println("Hello World!!");
    }

    /**
     * @see HttpServlet#doGet(HttpServletRequest request, HttpServletResponse
     *      response)
     */
    protected void doGet(HttpServletRequest request,
            HttpServletResponse response) throws ServletException, IOException {    
    }

    /**
     * @see HttpServlet#doPost(HttpServletRequest request, HttpServletResponse
     *      response)
     */
    protected void doPost(HttpServletRequest request,
            HttpServletResponse response) throws ServletException, IOException {      
    }
}

In the above code we can see, the overridden init(ServletConfig) method, first calls to its' super class init method. After that, we can insert any code we need. Here I inserted

System.out.println("Hello World!!");

We can start the 'tomcat' server and see, the result as below

May 7, 2013 10:16:11 PM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk-amd64/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib/x86_64-linux-gnu/jni:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu:/usr/lib/jni:/lib:/usr/lib
May 7, 2013 10:16:11 PM org.apache.tomcat.util.digester.SetPropertiesRule begin
WARNING: [SetPropertiesRule]{Server/Service/Engine/Host/Context} Setting property 'source' to 'org.eclipse.jst.jee.server:ServletInit' did not find a matching property.
May 7, 2013 10:16:11 PM org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080
May 7, 2013 10:16:11 PM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 552 ms
May 7, 2013 10:16:11 PM org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
May 7, 2013 10:16:11 PM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.29
Hello World!!
May 7, 2013 10:16:11 PM org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
May 7, 2013 10:16:11 PM org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:8009
May 7, 2013 10:16:11 PM org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/13  config=null
May 7, 2013 10:16:11 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 267 ms

We can see, 'Hello World!!' is printed with the server startup, not after server start. Thus, we can use this init method, to do tasks like creating pre database connections.

Important Fact: Make sure you add, the servlet you created to the web description file (web.xml) with the load-on-startup tag. The init(ServletConfig) method, starts with the tomcat server, when this tag is mentioned in your web.xml.

For the above servelt it is like,

<servlet>
    <description></description>
    <display-name>InitServlet</display-name>
    <servlet-name>InitServlet</servlet-name>
    <servlet-class>com.example.servlets.InitServlet</servlet-class>
    <load-on-startup>2</load-on-startup>
  </servlet>
  <servlet-mapping>
    <servlet-name>InitServlet</servlet-name>
    <url-pattern>/InitServlet</url-pattern>
  </servlet-mapping>

This tag, indicates, the order which the servlets will be initialized. I used the value '2' as, I have another servelt to start before this, with the value '1'.