Hey guys,
in this months article we show you our client-server architecture in Project Aleron and give you valuable tips for networking in games 😉
Table of Contents
Our Client-Server Architecture
Project Aleron’s Client-Server architecture consists of a Loginserver, a Database, a number of Gameservers und a lot of clients.
At startup the Gameservers connect to the Loginserver. This way the Loginserver is always aware of which Gameservers are online right now.
New clients connect to the Loginserver to sign in. The Loginserver checks the account name and password in the database and sends a list of Gameservers to the client. The user selects a Gameserver to connect to. The Loginserver informs the Gameserver that this user is allowed to connect. At a later development stage we want to remove this signal by using the kerberos protokoll.
The client connects to the Gameserver and disconnects from the Loginserver. The Gameserver loads the users family and characters and places them in the world.
After completing the login procedure, a client is only connected to one Gameserver and the Loginserver is not needed anymore. Every Gameserver is independent of the others; families and characters are bound to the Gameserver they are created on.
Networking Tips
Here we have a list of networking tips that apply to any type of game.
Some of them are basically rules for our development.
This list is not complete, so feel free to tell us if we are missing something 😉
“Networking multiplayer introduces 99 problems!”
Networking introduces problems like latency, disconnects and reconnects. Many developers underestimate these problems and the increase in development time that comes with multiplayer. In general, multiplayer increases a game’s complexity by a factor of 10+.
If Project Aleron were a single player game, we would be MUCH farther in development. 😀
“Never add networking to a single-player game.”
Multiplayer in general is not a “feature” you can add later. Networking multiplayer requires fundamentally different data structures than single player games. As such you must decide whether your game will include multiplayer during pre-production.
For example this is most surely why the developers of Don’t Starve could not simply release a “multiplayer patch”, but rather developed a multiplayer version of the game, Don’t Starve Together.
“Never trust the client!”
If you can cheat in a multiplayer game, they probably trusted the client somewhere. Always question what the client sends you. Never accept any user input without evaluating it. If the player sends a request to use the skill Fireball, have the server check if he can use the skill first.
In Project Aleron the client can only send Requests to do things, whereby the server is the one to decide if the action is executed.
When we do use client-side checks, we repeat the check on the server-side. These redundant client-side checks reduce bandwidth.
“Only tell the client what it needs.”
This is an extension of “Never trust the client!”.
One simple cheating method is to display hidden information. This does not apply to Project Aleron because all players will play with full information during combat.
For RTS games this means not sending information about units in the fog of war.
If the client has information about hidden units, a simple cheat can display them.
In games such as first person shooters , not sending information about enemies that are hiding sounds really complicated or even impossible.
“Realtime networking? Read Valves Article on lag compensation.”
If you are developing a realtime game with networking multiplayer you will have great trouble with latency. Luckily Valve released an awesome article on how to solve this problem.
“Peer to Peer is not viable!”
We have heard the opposite from many developers but sorry, they are all wrong. First of all the normal networking including latency, disconnection and reconnection in peer to peer is harder to implement.
Secondly, you only have clients in peer to peer and you have noone that you can trust. Also If one player lags within a peer to peer match, the entire match will become laggy. When developing a competitive game, this will ruin the experience for your high end players.
Also it is not realistic to migrate a game from peer to peer to client-server architecture later on. This would require a rewrite of the game.
Closing Words
We hope you learned something helpful about networking today!
If you want to add something we missed or ask us as question,
we would love to read it in the comment section below. 🙂
Authors: Sergej Tihonov, Eike Wulff and Benjamin Justice
