Server Architecture: A Noobs Guide

My thoughts on the architecture of multiplayer games, especially my own.

This is reposted from my side blog KR Game Studios, where I post longform articles. I've edited it for grammar and clarity.

Let me just start of by saying that I have no professional experience with server development, or game development in general. Regardless, I have learned a lot through studying open source games (Mana), and by making my own (Tortuga, WIP). So, I’m going to outline here a number of possible ways that I could structure the game at some point in the future.


My goal for Tortuga is to allow people to set up their own private servers, which they can mod, administer and handle however they please. As long as a modded server interacts correctly with an unmodified client, I don’t care how drastic the changes are (within reason; there are security related issues addressed below).

In addition to this, I will be running the vanilla version of the server as well, to provide a central game server where people can play without having to worry about mods and such. This approach, although I’m sure is not new, is inspired by Minecraft’s older multiplayer systems (or more accurately, “How I would manage Minecraft better”).

Server and Client

(I miss MS Visio)

This is the current state of the game. The server administrator initiates the game server, the clients connect to that server, and everything goes through that game server. This is the simplest option since it negates complex networking, and supports private servers fairly easily. The only downside is that the clients (and therefore players) need to know the IP address of the server beforehand.

LAN clients are easily managed via broadcast requests and responses; the clients essentially “shouts out” for a server, and the servers (if any) on that LAN respond with their connection data. Anybody with networking experience should know what I’m talking about, but I’m outlining this process because…

Server, Client and Catalogue

The “Catalogue Server” is a central repository of addresses for any publicly or privately run games. Instead of requiring the game server’s address, the server automatically sends this information to the catalogue, which in turn makes it available to any clients looking for a game. This makes the login process easier on the end user, and mimics more professional designs.

I’ve considered this design for a long time, and I’m hoping that I could implement it eventually. All I really need to do is repurpose the old “shout out” (broadcast) systems to point directly at the catalogue. 

This does, however, present some new problems. Firstly, the catalogue server is a critical failure point for the network. If it became the target of a DDOS attack, the entire network would be brought offline.

Secondly, server rental. To ensure that the catalogue is available at all times, I would need to rent permanent server space to host it, as well as an easy-to-understand web address. For somebody who is developing this game on a $0 budget, funds are a serious issue.

Finally, and most importantly, account security. I understand the basics behind password security, salts, hashes, and other such vulnerabilities, and I also understand that I shouldn’t be handling this myself. There’s always the option of using a 3rd party login system (like Facebook Connect Steam intergration) or a prebuilt library for this, but I want to ensure that security cannot be breached at all. The advantage of this system, however, is that I can separate the accounts from the game servers by rolling them into the catalogue server (or creating a separate account server, see below).

Account Server, Game Server and Chat Server

(The picture is too messy to be of any use ;_;)

The open source MMO project that I linked to above, The Mana Project, in addition to having well over 10 years of work and dozens of professionals behind them, have also separated their accounts system from their main game server, thereby allowing players to login while keeping the login data physically separated from the game servers.

As I’ve said, I only barely understand most of the security related concerns, so I won’t post about them here. The experimental build of Tortuga currently sends two separate messages to the monolithic game server: join and login. The first connects the client and is handled by the game server's internal client manager (catchy name, no?) while the login message carries the actual username (and potentially, the password), and is handled by the account manager.

If I were to implement a separate account server, the protocol would look something like this:

  1. Join account server (as a client)
  2. Send username, password (hashed) to the account server
  3. Receive the login token
  4. Disconnect from the account server
  5. Join the game server, with the login token
  6. The game server verifies the login token with the account server

I’m fairly sure I’ve paraphrased this from The Mana Project’s own documentation, but I believe this is the best design, regardless. The problem is, though, that this is also the most complex option.

When I wrote this heading, I figured the chat server could be separate, but instead I’d rather roll the chat system into the game server (it makes distance-based speech easier, but that’s a post for another time).

Other Possibilities

There are other possibilities for networking and security in this game, so I’ll briefly outline them here:

  • Mixing both the catalogue and account server patterns
  • Reducing the game to a peer-to-peer pattern, thus avoiding any servers
  • Avoiding any password systems (making user accounts inherently vulnerable, or persistence between sessions impossible)
  • Storing character data locally
  • Utilizing a 3rd party engine, to handle all of this for me (BigWorldTech?)

This blog post hasn’t even addressed vertical or horizontal scaling of any kind, mostly because the game in it’s current state doesn’t really support either.


There is only one major conclusion that I can come to from reading and writing this post: I am in over my head, and I don’t know enough about server architecture. I knew this from the start, but at least now I know what I know, and what I don’t.

Thank you for your time.

You can find the latest version of Tortuga (or donate) at my website, and follow me on twitter @KRGameStudios.

Latest Jobs

IO Interactive

Hybrid (Malmö, Sweden)
Gameplay Director (Project Fantasy)

Arizona State University

Los Angeles, CA, USA
Assistant Professor of XR Technologies

IO Interactive

Hybrid (Copenhagen, Denmark)
Animation Tech Programmer

Purdue University

West Lafayette, IN, USA
Assistant Professor in Game Design and Development
More Jobs   


Explore the
Advertise with
Follow us

Game Developer Job Board

Game Developer


Explore the

Game Developer Job Board

Browse open positions across the game industry or recruit new talent for your studio

Advertise with

Game Developer

Engage game professionals and drive sales using an array of Game Developer media solutions to meet your objectives.

Learn More
Follow us


Follow us @gamedevdotcom to stay up-to-date with the latest news & insider information about events & more