This is an automated posting from the Dev Blog. Click here to view the full post.
It has been a little bit quiet around here but that silence should be broken today! As we have been secretly working on the Multiplayers Instance whenever we had spare time, the hard labour finally paid off and first results are on their way. I won’t show you anything fancy today, I’m sorry, but maybe it’s interesting nonetheless. Today I’ll talk about the stuff you normally don’t see but is crucial to everyone – the server architecture.
Independence Day
What we wanted to achieve is independence. Independence from location, independence from servers, independence from worlds. Well, the game has to run *somewhere* on *some server*, but we wanted to lift the restriction that games from world 1 can only run on the servers of world 1. It’s a common problem that one server has spare resources while others are busy, slowing everything down on their world. Adding the in-development feature MPIs to those might slow things down even more during peak hours, having a negative impact on the normal gameflow. As a result, we had been thinking about splitting the MPI systems into three parts: a world server, manager server and battle server – each with different tasks.
World server
This one basically is the player’s gate to the MPI system in general. It serves you everything you need: the client to connect to other parts of the system, a list of available games, allows you to create games and forwards you to the battle server where the actual game will take place.
Battle server
The battle server is the heart of the MPI in terms of game logic. It handles all the instance specifc data, lets you attack other players or move to another cell on the grid. Everything that is related to the game itself is communicated between the battle server and you, the player directly. As previously said, you will be forwarded to a dedicated server as soon as you create and start a game.
Manager server
All the data needs to be kept somewhere, and that is the manager server’s responsibility. It knows who is playing from where, in what game and on which battle server, who is currently queued and searching for a game and who just lost an instance.
What I briefly described in words can also be nicely illustrated with the help of a picture:
A Workflow Example
A client (player) connects to its world server, tells the world server that it want to create a new instance which the world server then tells the manager server, which then will create a gamelobby for the instance. From that point on, other clients can see the newly created game and join in. If the number of players are sufficient, the host (the client who created the game) can start the game. Again, the world server forwards the information to the manager server. Now the manager has to decide on a free battle server to host the game on. After it found one with a low load, it tells the chosen battle server to create the game and forward all information needed to connect to the battle server back to the world server who then pushes the answer back to its clients. On recieving the information, the clients finally connect to the battle server and the game can start. As soon as it finishes, the battle server will inform the manager that it’s over along with the actual game result and if any rewards are set for the given result, the manager will push the data back to the world server who will grant the players their deserved rewards. Rinse and repeat.
The Idea Behind
The interesting part of this architecture is: while it’s technically possible to run everything on one actual hardware-server (and that’s how we start rolling out the MPIs), it’s designed to be split among different ones. While each world will have its own world server, there is no need to have a manager server and battle server for each world. The world servers can connect to any configured manager which can forward games to any battle server the manager server knows about. In the end, it’s specifically designed to let each world server from the same market connect to one, and only one for the complete market, manager server. And if it’s only one manager server, there is one big queue, one big list of available games. Every player would be thrown into the same pot and players from different worlds could play together … or against – world vs. world, anyone?
I’m sorry – you’re thinking too small.
It has been a little bit quiet around here but that silence should be broken today! As we have been secretly working on the Multiplayers Instance whenever we had spare time, the hard labour finally paid off and first results are on their way. I won’t show you anything fancy today, I’m sorry, but maybe it’s interesting nonetheless. Today I’ll talk about the stuff you normally don’t see but is crucial to everyone – the server architecture.
Independence Day
What we wanted to achieve is independence. Independence from location, independence from servers, independence from worlds. Well, the game has to run *somewhere* on *some server*, but we wanted to lift the restriction that games from world 1 can only run on the servers of world 1. It’s a common problem that one server has spare resources while others are busy, slowing everything down on their world. Adding the in-development feature MPIs to those might slow things down even more during peak hours, having a negative impact on the normal gameflow. As a result, we had been thinking about splitting the MPI systems into three parts: a world server, manager server and battle server – each with different tasks.
World server
This one basically is the player’s gate to the MPI system in general. It serves you everything you need: the client to connect to other parts of the system, a list of available games, allows you to create games and forwards you to the battle server where the actual game will take place.
Battle server
The battle server is the heart of the MPI in terms of game logic. It handles all the instance specifc data, lets you attack other players or move to another cell on the grid. Everything that is related to the game itself is communicated between the battle server and you, the player directly. As previously said, you will be forwarded to a dedicated server as soon as you create and start a game.
Manager server
All the data needs to be kept somewhere, and that is the manager server’s responsibility. It knows who is playing from where, in what game and on which battle server, who is currently queued and searching for a game and who just lost an instance.
What I briefly described in words can also be nicely illustrated with the help of a picture:
A Workflow Example
A client (player) connects to its world server, tells the world server that it want to create a new instance which the world server then tells the manager server, which then will create a gamelobby for the instance. From that point on, other clients can see the newly created game and join in. If the number of players are sufficient, the host (the client who created the game) can start the game. Again, the world server forwards the information to the manager server. Now the manager has to decide on a free battle server to host the game on. After it found one with a low load, it tells the chosen battle server to create the game and forward all information needed to connect to the battle server back to the world server who then pushes the answer back to its clients. On recieving the information, the clients finally connect to the battle server and the game can start. As soon as it finishes, the battle server will inform the manager that it’s over along with the actual game result and if any rewards are set for the given result, the manager will push the data back to the world server who will grant the players their deserved rewards. Rinse and repeat.
The Idea Behind
The interesting part of this architecture is: while it’s technically possible to run everything on one actual hardware-server (and that’s how we start rolling out the MPIs), it’s designed to be split among different ones. While each world will have its own world server, there is no need to have a manager server and battle server for each world. The world servers can connect to any configured manager which can forward games to any battle server the manager server knows about. In the end, it’s specifically designed to let each world server from the same market connect to one, and only one for the complete market, manager server. And if it’s only one manager server, there is one big queue, one big list of available games. Every player would be thrown into the same pot and players from different worlds could play together … or against – world vs. world, anyone?
I’m sorry – you’re thinking too small.