I am making a client server MMO style game. So far I have the framework set up so that the server and clients interact with each other in order to provide state updates. The server maintains the game state and periodically calculates the next state and then it every once in a while (every n milliseconds) it sends out the new state to all the clients. This new state is able to be viewed and reacted to on the client side by the user. These actions are then sent back to the server to be processed and sent out for the next update.
The obvious problem is that it takes time for these updates to travel between server and clients. If a client acts to attack an enemy, by the time that update has gotten back to the server, it's very possible the server has progressed the game state far enough that the enemy is no longer in the same spot, and out of range.
In order to combat this problem, I have been trying to come up with a good solution. I have looked at the follow, and it has helped some, but not completely: Mutli Player Game synchronization. I already came to the conclusion that instead of just transmitting the current state of the game, I can transmit other information such as direction (or target position for AI movement) and speed. From this, I have part of what is needed to 'guess', on the client side, what the actual state is (as the server sees it) by progressing the game state n milliseconds into the future.
The problem is determining the amount of time to progress the state, because it will depend on the lag time between server and client, which could vary considerably. Also, should I progress the game state to what it would currently be when the client views it (i.e. only account for the time it took the update to get to the client) or should I progress it far enough so that when its response is sent back to the server, it will be the correct state by then (account for both to and from journey).
Any suggestions?
To reiterate:
1) What is the best way to calculate the amount of time between send and receive?
2) Should I progress the client side state far enough to count for the entire round trip, or just the time it takes to get the data from the server to the client?
EDIT: What I have come up with so far
Since I already have many packets going back and forth between the clients and server, I do not want to add to that traffic if I have to. Currently, the clients send status update packets (UDP) to the server ~150 milliseconds (only if something has changed), and then these are receive and processed by the server. Currently, the server sends no response to these packets.
To start off, I will have the clients attempt to estimate their lag time. I will default it to something like 50 to 100 milliseconds. I am proposing that about every 2 seconds (per client) the server will immediately respond to one of these packets, sending back the packet index in a special timing update packet. If the client receives the timing packet, it will use the index to calculate how long ago this packet was sent, and then use the time between packets as the new lag time.
This should keep the clients reasonably up to date on their lag, with out too much excess network traffic.
Sound acceptable, or is there a better way? This still doesn't answer question two.
2) Should I progress the client side state far enough to count for the entire round trip, or just the time it takes to get the data from the server to the client?
Let's assume that the server sends the state at time T0, the client sees it in time T1, the player reacts in time T2, and the server obtains their answer in time T3, and processes it instantly. Here, the round trip delay is T1-T0 + T3-T2. In an ideal world, T0=T1 and T2=T3, and the only delay between the observing time and the processing of the player's action is the player's reaction time, i.e., T2-T1. In the real world it's T3-T0. So in order to simulate the ideal world you need to subtract the whole round trip delay:
T2-T1 = T3-T0 + (T1-T0 + T3-T2)
This means that a player on a slower network sees more advanced state the a player on a fast network. However, this is no advantage for them, since it takes longer till their reaction gets processed. Of course, it could get funny in case of two players sitting next to each other and using different speed networks. But this is quite improbable scenario, isn't it?
There's a problem with the whole procedure: You're extrapolating in the future and this may lead to nonsensical situations. Some of them, like diving into walls can be easily prevented, but those depending on player's interaction can not.1
Maybe you could turn your idea upside down: Instead of forecasting, try to evaluate player's action at the time T3 - (T1-T0 + T3-T2). If you determine that a character would be hit this way, reduce its hit points accordingly. This may be easier and more realistic then the original idea, or it may be worse, or not applicable at all. Just an idea.
1 Imagine two players running against each other. According to the extrapolating they pass each other on the right side. In fact, one of them changes their direction, and at the end they passes each other on the left side.
First off, just as an FYI, if you are worrying about delays of less than 1 second you are starting to get out of the realm of realistic lag for an MMO. The way all of the big MMOs handle this is by basically having two different "games" going at the same time - there is an underlying game engine which is handling all of the math, character states, applying the numerical changes, and then there is the graphical client.
The first "game," the math and calculations, are a lot closer conceptually to a traditional console game (like the old MUDs). Think in terms of messages passing back and forth, with a very high degree of ACID isolation. These messages worry a lot more about accuracy, but you should assume that these may take 1-2 seconds (or more) to be processed and updated. This is the "rules lawyer" that is ensuring that hit points are being calculated correctly, etc.
The second "game" is the graphical client. This client is really focused on maintaining the illusion that things are happening much more quickly than the first game, but also synchronizing the events that are coming in with the graphical appearance. This graphical client often just flat makes things up that aren't critical. This client is responsible for the 30 fps+ graphics. That's why a lot of these graphical clients use tricks like starting the attack animation when the user presses the button, but not actually resolving the animation until the first game gets around to resolving the attack.
I know this is a little off from the literal interpretation of your question, but once you get outside two machines sitting next to each other on a network 100ms is really optimistic...
One way to solve this kind of problem is running the game simulation on the client and the server.
So instead of simulating the world just on the server, do it on the client as well. Just send what the client did (for example "player hit monster") to the server. The server runs the same simulation and checks the events.
If they don't match (player cheating, lags), it sends a veto to the client and the action isn't recorded as successful on the server. This means all the other clients don't notice it (the server doesn't forward the action to the other clients).
That should be a pretty efficient way to handle the lag, especially if you have a lot of PvM battles (instead of PvP): Since the monster is a simulation, it doesn't matter if there is a long lag between the client and the server.
That said: Most networks are so fast that the lag should be in the area of a few milliseconds. That means you "just" have to make the server fast enough so it can respond withing, say, <100ms and the players won't notice.
来源：https://stackoverflow.com/questions/5690899/synchronizing-client-server-game-state