MMORPG Client/Server Coding

Question

How are the UDP and TCP protocols used in MMORPG client/server communication?

For example:

Does the client broadcast (player position, etc) via UDP to the server? or vice versa?

Or is it more like using TCP where the Client requests that the server move the player. The server receives the request, moves the player and sends back to the client that the player is now at position xyz?

The chat channels must be implemented using TCP?

Are there any good articles/books on this? I've found bits and pieces but it seems the real meat and potatoes are won from experience.

Answer 1

Half of your question (transport layer protocols used) could be answered by installing wireshark and looking at the traffic.

Answer 2

I don't know any details other than observations as a player, but most game most definitely do not wait for a server reply to move a character, that would kill the user experience unless it was turn-based. What looks like happens is the movement is done client-side and sent to the server which then sends those messages to other players. At least in WoW, if a player is lagging you may see them still moving forward then magically appear at another location later, which says to me that the client receives more than location data, but also that they are moving and the direction they were moving and then extrapolates the movement in absence of further data.

Answer 3

Your best bet is probably to take a look at Planeshift's networking code, it's an open source MMO. I believe it's the most developed on the scene(last I checked).

Answer 4

A lot of games use UDP for movement related activities--so, like, when you are walking, chances are, a bunch of UDP requests are being sent. The server still ultimately controls whether that's valid, but you don't necessarily care whether every single packet gets to the server. This is why a lot of game clients also use some kind of prediction mechanism.

In terms of your second mention, yes, it's very common for all control to be managed by the server. You don't want clients to be broadcasting anything to the server; you should do error and input handling server side to prevent people from hacking. You might also limit input per second.

Anyway, a combination of UDP and TCP would be appropriate--you just need to ask yourself, "Do I want reliability or speed?"

Answer 5

There are many different possible implementations, but for the most part, they'll look like this. This pattern is repeated with almost any action in the game world.

1. The client communicates to the server that the player wants to move.
2. The client displays the player moving according to what it thinks should happen.
3. The server validates that the move is something that could happen, given the location of the player.
4. The server updates the client as to where the player is as far as the server is concerned.
5. The client updates the players position to reflect the server's worldstate.

Answer 6

You may be interested in Project Darkstar. It's an open source MMO framework.

Answer 7

You can't rely on the client to pass in truthful information. Someone will hack the protocol and cheat. Encrypting the data won't stop this - just make it a little harder to do.

The client should only send in requests for movements etc and the server needs to sanity check the requests to make sure that they don't violate the game rules. The server should only send data back that the client absolutely needs - you can't rely on the client to get a chunk of world data and just filter out everything that the player can't currently observe. Someone will get hold of the extra information and exploit it.

If the game needs to be 'real-time' then the client needs to assume that the server will allow the movement requests and update the display accordingly - and roll-back the movement if the server corrects it later. Under most conditions the client and server will agree and everything will flow smoothly. They won't agree when the client is attempting to cheat (which is their fault anyway) - or the client is lagging badly due to a poor connection (not much you can do about that).

Answer 8

I don't think there's a brief single answer to this question, it's quite wide in its scope. Still, a few points:

• There's no need to "broadcast" just because you're using UDP. UDP is point-to-point most of the time, in my experience.
• It's perfectly possible to do your own "secure" communications over UDP, you don't have to use TCP. It's not magical, just ... clever and intricate. :) But for the most part, as you imply, TCP is not suitable for real-time-ish communications in games.
• There are ways to make TCP more suitable, search for "Nagle algorithm" for instance.
• You can do chat over UDP, if you've already rolled your own lossless transport protocol on top of it. Many games to this.

There have been articles about networking in Gamasutra, but I don't have any links handy right now. Not ever sure if they're still openly available, sorry.

Answer 9

I think you can learn a lot from reading how others have implemented these types of systems. In that vain, may I point you to the work of Tim Sweeney and The Croquet Consortium

1. Unrea Networking Architecture
2. The Croquet Project

Tim Sweeney's papers transformed the way I thought about programming. I can't recommend them enough.