Why do MMORPGs still use multiple servers?

Question

MMORPGs, some MOBAs like League of Legends or even StarCraft 2 usually force you to pick a server. Usually they are US, EU and SEA, in MMORPGs many per location. I can see that that was necessary a few years ago, but now with the advent of AWS and similar offerings that allow you to seamlessly scale your "server-power", why are there still separate servers?

My train of thought is like this (using Star Wars: The Old Republic as an example): - You are always on one planet, an isolated "instance" from other planets. - If there are too many people on one planet, SW:TOR creates a new instance of the world and puts players in there. - If you leave the world / switch instances you have a loading-screen

So why can't the game create an instance for this planet. This instance (and only this one) has your current data in its database and manages x players. As soon as x-50 players are on this instance, a new server will fire up and new people will spawn on that instance. The 50 spots are reserved for switching to your group, etc.

There could be an instance for all three major regions to keep the latency low, but it would allow you to still play with other players from i.e. SEA if you can live with a 140ms delay (which is still nothing imho).

Whenever you switch an instance or travel to another world, your current server gives all your data to the next server, making sure you don't need one big centralized database. You could still have one that gets updates periodically for analysis purposes.

When you log off or the servers loses connection, the data could then be transferred into a massive database that is optimized for storing the data. The instance servers can then be optimized for high throughput.

Is there any particular reason this will not work? Are there other problems I am missing?

Answer 1

MMORPGs, some MOBAs like League of Legends or even StarCraft 2 usually force you to pick a server. Usually they are US, EU and SEA, in MMORPGs many per location. I can see that that was necessary a few years ago, but now with the advent of AWS and similar offerings that allow you to seamlessly scale your "server-power", why are there still separate servers?

AWS is not as obvious a solution as it seems. It can be expensive, in some cases more so than using in-house data centers (for a publisher the cost of these may be amortized across multiple products, for example). Additionally, there could be concern about storing sensitive binaries and logs on hardware outside of one's control. Finally, actual computation power is not always the reason for segregating the "server" population in MMOs.

My train of thought is like this (using Star Wars: The Old Republic as an example): - You are always on one planet, an isolated "instance" from other planets. - If there are too many people on one planet, SW:TOR creates a new instance of the world and puts players in there. - If you leave the world / switch instances you have a loading-screen

Guild Wars 2, in fact, does something very similar to this. Maps are simulated by individual server processes, and overflow instances are created as needed based on the map population cap and some heuristics for the performance of the map.

Guild Wars 2 has two major data centers, one in the US and one in Europe -- there is some cross-chatter between those data centers (primarily for the trading post and commerce systems) but in general they exist in that configuration so players in Germany, France, et cetera don't have to suffer the higher latency to the US game servers. Within the data center players are sorted into "home worlds" (or "shards" in vernacular terms); but one of the reasons this is done is to minimize the number of players that a client can see and need reported to them. The client side aspect of that problem won't be solved by scaling out to more server hardware. The server-side combinatorial explosion of additional reporting paths might be, but not cheaply (and consequently it tends not to be worth it since the client-side performance is still a problem).

Is there any particular reason this will not work? Are there other problems I am missing?

You're missing quite a few things, but they're mostly details (and I won't explain how we handle them anyhow since they're considered trade secrets) not relevant to such a high-level, overview-type of question. I think the biggest flaw in your proposal is trying to hand off player data to the new server when a player transfers. That is a complex problem that won't scale well, it is probably better in practice to actually have that player data on a centralized system of servers. It's quite doable if you don't use those databases and the primary runtime record store for the data.

Answer 2

Mostly it's about latency.

Firstly, having a server geographically near to you cuts down on latency. If the server is on the other side of the world then you'll see more latency than if the server is just a few hops away.

Secondly, services like AWS are not designed for real-time work. They're designed for high throughput at the expense of a bit of latency. If your web page takes 250ms longer than usual to load on one occasion, nobody cares, but if your game takes 250ms longer than usual to process a message, gameplay can be seriously affected. This is why MMOs are almost always hosted on dedicated hardware.

But it's also about game design. If you make it seem like everybody is in the same world but have to split a zone when it gets too full, people get frustrated that they can't find their friends in the designated meeting spots. This sort of problem would extend to guilds, mass PvP battles, etc. Players are used to instances these days but there are certain areas that are expected to be shared. If you have completely separate servers then at least there are no surprises here.

Finally, there are other technological issues to consider. Even if each instance is fairly isolated from the others, there are usually still various services that need to communicate across them. Cross-server communication is difficult to do well in real time software and has led to various exploits and bugs on MMOs in the past. In particular handing off authoritative player data from one to the other is risky. Therefore developers often err on the side of caution and have clearly delineated boundaries between servers, reducing the amount of traffic that needs to cross them.

Answer 3

actually I believe the answer is not network or architecture related but rather game related, usually in this type of games there are events, and these events are timed according to the most comfortable timeframes for the people who play on the server, and that is usually related to the timezone where people live, hence EU and US, etc.

Another reason is to create a separation between worlds so that if there's a group that's too strong they won't mess up the game for everyone playing, and you can always move to a world less "challenging".

On the server CPU capability side, although today's machines are quite strong, there's always a limit to what one machine can handle, and so creating a separation between worlds is necessary to protect the game from overloading, and let people choose which world they want to play in so they can play with their friends. Scaling horizontally is not just a matter of having machines, you need your application to be able to work in a horizontally scaled architecture, and that's not so easy when you have thousands of "actions" going on concurrently with possible influence on each other, and need to synchronize everything. I think it would be very difficult to do that across several machines.

Answer 4

What's wrong with auto-instancing? When a location gets too populated, you just put the 1000 players into 10 different instances.

The problem with that is that online games are all about the community. Imagine you arranged a meeting with people you met before, and when you are all there at the given time you don't see each other because you are all in different instances? That's annoying and it breaks immersion.

How can this be prevented? It could be done by putting each players in the same instance at all times, so that when you meet another player once, you can be sure to meet this player again when you are both in the same location. You will never meet those players who are assigned to other instances.

But what when you want to meet someone from outside the game? Like a real-life friend you invited to play the game with you? In order to allow that to happen, you would need the ability to choose the instance when creating your character. Like from a list of instances with easy to memorize names. Unfortunately, the name "instance" seems confusing to the average user. They aren't used to that word. Wouldn't it be better to use a term they are used to? A term like... Server?