Synchronizing Client-Server game state

Question

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.

Answer 1

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...