Dedicated Game Server

About Me

Name Rohan Prinja

Email rohan.prinja@…, rohan_prinja@…

University Indian Institute of Technology, Bombay

IRC rohanprinja

Phone +91 9619019345

Timezone UTC +5:30

Proposal Details


  • Each game server runs a unique PySoy game.
  • Players are either normal players or admins. Every player, admin or not, has a JID.
  • The server maintains a list of JIDs corresponding to admins and uses this to enforce authorization.
  • Players can chat with each other (via XMPP), request to join the game, and leave the game. Game population limits can be set by admins to avoid lag. A player requesting to join an overloaded game may be denied or queued.
  • Admins can forcibly kick players from a game temporarily, or ban them permanently for breaking the rules. Permabans can be implemented by having a banlist that is editable by the admins. Each item on the banlist is a static IP. (possible extension: in some countries - for example, India - dynamic IPs are the norm, so this approach isn't useful. What to do then?)
  • Admins also use XMPP for viewing the player lists, chatting amongst themselves and instructing the server to kick/ban players.

Server Design

Summary of the server design - I propose a singly threaded server that runs a PySoy game in a nonblocking process. Communication between players-and-players and admins-and-server happens through XMPP. Everyone has a JID that uniquely identifies them.

Pseudocode for the server designs is given below. I've tried to take into account issues such as game overloading and player banning.

def intialize_server():
    read and store admin JIDs
    loop indefinitely

def start_game(game_info):
    store game information in data structure
    fork self, run game in forked process

def close_game():
    save game history / log statistics
    kill child process to end game
    clean up after child process

def game_info(): return game information (population limits)

def list_players(game_id): return list of player JIDs

def register_player(player_id, player_name):
    check if player_name is an already taken username
    if not:
        add player to server
        store mapping of player's JID to username

def add_player(player_id):
    obtain static IP from player_id (JID)
    check banlist for player's IP
    if not in banlist:
        if game is overloaded:
            # decide whether to outright deny player or queue them
            if queue size < QUEUE_LIMIT:
                add player to queue
                inform player that the game is overloaded (via XMPP)
            add player to game
            update game player list
        reject player request
        send player notification (via XMPP)

def kick_player(player_id, kick_message=''):
    current_players = list_players(game_id)
    search for player_id in current_players
    if present in list:
        remove player from game
        send player kick_message
        update game player list

def ban_player(player_id):
    if player_id not already in banlist:
        add player_id to banlist
        send player_id a notification informing them of the ban

def unban_player(player_id):
    if player_id in banlist:
        remove player_id from banlist
        send player_id a notification informing them of the unban

def disconnect_player(player_id):
    # fundamentally the same as kick_player(), except that in this case
    # the player is voluntarily leaving the game
    # maybe use the same function for both?

def username_to_jid(player_name): return player JID

def jid_to_username(player_id): return player username

For the queue implementation, I plan to use a simple queue with a limit. The queue limit is part of the game information that is specified when launching the game.


The above server design is a mockup of the server program. To begin with, the server launches by reading the list of admins. When a game is to be run on the server, the start_game function is called. The server forks itself and the child process execs the PySoy game. This is done in a nonblocking way so the parent server process can start handling requests. Each one of the above functions is handled by the server, as the child process is simply running a game. Functions for creating and shutting down games are handled by the server admins, and functions such as disconnecting and banning players are handled by the game admins.

Every game has some initialization information, including:

  1. Game population limit
  2. Game queueing limit
  3. Game admin list (by default, this is the same as the admin list for the server itself but it can be changed)
  4. Banlist (by default, empty, but can be initialized with a list of player JIDs)

There need not be a distinction at all between game and server admins, this is just an added convenience I am proposing.

Apart from this, the server also maintains information about the game as it runs, including

  1. Connected players
  2. Game uptime (such a feature would be useful mostly for 'event' games that will run for a few hours or days only)
  3. Game queue
  4. Username to JID mapping

The admins of a game have the following administrative powers:

  1. Kicking a player (temporary ban)
  2. Permanent ban
  3. Reverse permanent ban

Player Usernames

To a server, a player is identified uniquely by their Jabber ID. But players will of course wish to select their own usernames while playing. So the server needs to store a mapping of player usernames to JIDs. In chat, the usernames be displayed. Admins will have access to not only the username but also the JIDs whereas ordinary players cannot see each other's JIDs.


Unless explicitly disabled, every game run on our dedicated game server has a chat room. Players logged on to a game can chat with each other via XMPP.


Prep Work / Research

From my operating systems course in college I have a basic understanding of forking, blocking and nonblocking processes and working with parent-child processes. I will need to familiarize myself with XMPP and server design. Specifically, I will look into:

  1. Understanding the XMPP protocol, including how to use and manage JIDs.
  2. How to set up XMPP on a server
  3. Setting up chat using XMPP

Completed by Midterm

  1. A server able to run a PySoy game in a separate nonblocking child process.
  2. Player signup, login, logout.
  3. Basic admin functionality (start game, shut down game).

Completed by Final Evaluation

  1. Full admin functionality (including banning and temporary disconnection)
  2. Player-to-player public and private chat.
  3. Queueing to cap the server load.