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.
This really sounds very interesting and attractive. Being able to get in so many battles with so many people, getting access to a big in-game market to really be able to buy the stuff you need, because many virtual in-game products are incredibly exagerated, but maybe they have to be, so you will be forced to buy nuggets (?????).
Anyhow, I like more the design of the-west 2.0 than the-west 1.0, with two exceptions … the tutorial is so harsh in v2.0 than in v1.0; it is way to viral/violent the way it is put in your face after creating a new user on a world, without being able to put a pause to it.
Also … all those (what ever they are named) they are blocking so much in seeing clearly the map. Shoud be only a down taskbar, with all the options there and also that shoud have an option to hide it; I really do not care to see my avatar so big all the time just to keep me for seeing the map with all the jobs, towns etc. … don’t le me start about the “missions jurnal” … it should contain also a list with only all the jobs/items needed to be done/get in finishing the quests/missions. By summing things up, it could mean a little space occupied on the main space (over the map) of the game.
I would most certainly apprechiate an update regarding the fort battle formula.
The current situation, where players don’t buy any of the new stuff since the are worthless, due to the lack of use of trading/setting traps, is not profitable. Neither for you, nor for us.
Please, release the formula on normal worlds, or set a release date at least.
Otherwise, a lot of players on my server won’t buy the soccer stuff, for example.