Server Architecture: A Noobs Guide

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.

Outline

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:

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:

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.

Conclusion

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 krgamestudios.com, and follow me on twitter @KRGameStudios.