Multiplayer game servers architecture

Question

I'm trying to create MMORPG with huge world divided by chunks. I was thinking a lot about servers architecture. I don't want my main game server to have direct access from clients and I do want to have some abilities for load balancing and for expanding whole system.

Finally I came up with this architecture:

1. The Game Server - which store game state and trigger events and so on. This server does not communicate with clients. It will be connected to database to store game state from time to time.
2. Streaming Servers - servers that handle client connections and stream game state to them as far as players actions to server. I suppose them to work through UDP. With this approach I will have some benefits:
   • I can put then in different countries to lower pings.
   • I can have as many then as my budget allows me to. Adding more streaming servers would allow to handle more client online.
   • if something happens with one of streaming servers (due to hacker attacks or server hardware/software failure) this will not effect whole systems and other players experience. Players from this server can be routed to another.
3. Physics Servers - they would handle chunk physics and maybe some other heavy stuff. With adding new physics servers I can extend my system so that it would able to proceed more and more data, if needed.

What are the pitfalls of such an architecture? How good is it?

How would clients know to which streaming server they should connect? I suspect that here I should have one more - routing server that would do something like load balancing stuff and route user to one of the working streaming servers.

Would I have some problems with data synchronization?

Answer 1

No. Don't do it that way, it won't work.

• The latency is about as bad as any architecture can offer, due to the high number of hops.
• Scaling is incredibly poor due to a single game server.
• Complexity is very high, due to 3 server side layers which all operate at different times and need to extrapolate data from each other.

What you really need are multiple virtual game servers one per "chunk" of your world. Depending on load, you can move these virtual servers to a single machine, one machine per chunk, or anything in between.

Answer 2

When the purpose of those streaming servers is to reduce latency, then you might shoot yourself in the knee with that separation. Sure, the latency will be lower for everything the streaming servers can handle on their own. But how much will that really be?

Most player actions will need to be processed on the game-server or even the physics servers in your backend. The overall perceived latency between action and effect can only become worse through those layers of indirection.

It's also questionable if the stream server will even take much burden from the gameserver. The gameserver still needs to send updates to all the streamservers, and any input on a streamserver will need to be forwarded to the gameserver. You will only have a benefit when you can find gameplay features you can move to the streamserver which do not concern the gameserver. Possible things could be input validation (have the streamservers only forward input after validating that the player can actually do that right now) and visibility calculation (only forward events concerning game objects in sight-range).

Many MMORPG architectures rather try to scale horizontally than vertically. That means there is one server process which handles almost everything, but different servers are responsible for handling different zones of the game world. There is usually also one master-server which handles things which affect multiple zones and is used to tell players which zone-server to connect to.

Answer 3

Do you really need to have a physics server? The MMORPG architecture I have seen doesn't have any kind of formal physics server / code. Unless the characters will be dodge arrows and swords real-time. I guess you just have to look at what the game mechanics will be like and decide if you truly need a physics engine.