Comment my MMO client<>server movement handling.

Question

I'm working on a basic 2D flash MMO. The first alpha will contain the basics: players can move around. This is, I think, also the most important part to be highly optimized. As movement happens all the time and costs a lot of bandwidth.

This is how my current system works:

• All movement is calculated by the client
• When a client changes turning mode (turning left, not turning or turning right) this is being send to the server. The server then sends this new mode to all players that are near.
• Same thing happens for movement mode (moving forward or not moving, there is no moving backwards).
• Because of something (I think it's lag or delays between the client changes a mode and that new package actually being received by the clients that are near) the position of the other clients are not 100% accurate. So, every few seconds (I currently set it to 2) each client sends his current real position to the server, after which the server informs the near clients with the accurate position. Positions are checked with time-based range checks to avoid cheating.

Now, the problem is, that this "correction" (step 4) is actually so big that you see the other clients "warping" to the real location every 2 seconds. So, I have 2 questions:

1. Is my "algorithm" efficient, smart and good? Or do you suggest (minor or mayor) changes, or a completely different way of doing this?
2. How should I solve the problem where the correction is actually too big so that the near clients are warping to their corrected location every 2 seconds?

Answer 1

With your algorithm you won't avoid warping. This is due to latency and a lack of time synchronisation between clients and between the client and server (and not something you really want to keep track of... it's a nightmare to do well).

I'd probably go for something along the lines of:

• Every 0.5 seconds (or less) clients send their real position and velocity to the server
• Client extrapolates other players position using most recent position and velocity received in between updates.

This will be a heavier load on the server admittedly (about 4 times or more your current system) but it should provide better accuracy of the results. Until you have an actual game up and running and can test the performance and load as well, don't try and guess what needs optimising. Chances are that your common sense is wrong. You may also find that just changing to a binary format will reduce stress on your server too (i.e. make sure you use json or AMF). Still ensure that your received values are 'reasonable' though to avoid cheating of course.

Answer 2

One idea is that each client simulates what other clients would predict their player's position to be based on the last information it sent out about player velocity and position. The client only issues a position/velocity update when it detects that the actual position of the player deviates from the simulation substantially. That helps to restrict the bandwidth required.

When a client receives an update, instead of warping an object to the newest known location you can move it smoothly there. That would disguise the fact that warping is going on.

Check out the Multiplayer and Networking articles on gamedev.net

Answer 3

The answers in this link concern you (even though yours is a much smaller game, the problems are the same):

http://stackoverflow.com/questions/918033/how-does-the-half-life-2-multiplayer-protocol-work/

Answer 4

I maybe being a little paranoid and possible not needed for your app, but I would be worried about those nasty people out there that will take advantage of the "client" telling the server where they are in the game. I imagine that could be used to teleport, avoid creatures or traps etc. maybe some sort of check on the server that has a threshold to say they were at X before and now X+3 north is ok but X+150south is bad.