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:

enter image description here

  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?


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.

  • \$\begingroup\$ so when I will have a world with 100 chunks I will have 100 instancess of monolit server instead of just 100 instances of server that just process physics \$\endgroup\$ – SET Sep 10 '16 at 9:30
  • \$\begingroup\$ @SET Having a server that just processes physics would be a needlessly complex thing to have for any game. \$\endgroup\$ – Joe Feb 24 '19 at 17:57

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.

  • \$\begingroup\$ Yes the gameserver still have to communicate with few stream servers but this is not the same as communicate with thousands of clients. I can add as many stream servers as I want supporting thousands and thousands of connections. Without them, handling all client connections on main server, I would have connection limit as how many connections one server can handle. Also this make game server being visible from internet and thus - being vulnerable for any kind of attacks. Also streaming servers can make some calculations to decide what data should be sent to specific client. \$\endgroup\$ – SET Sep 9 '16 at 13:01
  • \$\begingroup\$ but you right, I'm very concerned with creating few layers which would create latency. I should made some tests to measure this. Also I'm not sure that keeping streaming servers in sync with game server would be an easy task *( \$\endgroup\$ – SET Sep 9 '16 at 13:03

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.

  • \$\begingroup\$ Yes I do need server side physics. The question its will I have any benefits from separating physics processing on standalone servers? \$\endgroup\$ – SET Sep 9 '16 at 15:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for?Browse other questions tagged or ask your own question.