   sync issues
  Hey,The game I'm working on is a real-time multiplayer flash game. It uses smart fox server to allow clients to communicate. The game does not run on the server, but rather on the clients and the server just serves as a form of communication between the players. This works for the most part, however I am having sync issues and need to get them worked out. I want to redo the sync system and here is what I am thinking:-One player "hosts" game.-Player logs in their game timers sync up-Whenever a keystroke or action is performed that action is sent through the host to all other players-When an event is received by another player it is placed into a queue-When the game time on the local machine hits the time stamp specified on the event in the queue the event fires-After the event fires the game timer stops and does not start back up until another event is receivedWill I have any problems with this? I figured I'd stop the game timer between events because otherwise if an event is received and the local game timer is already past the time stamp, what would I do? And also, concerning overclocked machines... their game timer will be running faster than normal. How will this effect syncing?Thanks   
  There are two models of sync:1) You queue commands, and they don't take effect until everybody has had time to see them. This means that you run one one-way latency behind the global game time on your machine, and the command latency for you is two one-way latencies (one round-trip time), plus some fudge. This is often used in games where "twitch" doesn't matter so much -- RTS games, board games, even racing games.If time comes for game tick N, and you don't have commands from everyone for tick N yet, you suspend the game clock until you do. This means that everyone sends their commands for tick N to everyone else, even if the commands are "no command this turn."2) You locally make actions take effect immediately, and show everyone forward extrapolated the best you can based on previously received data. Some arbitrator then breaks ties in the case of competition (two players racing for a health pack on the ground). The game UI is written to emit requests ("pick up the health pack and play a sound") immediately, and tell everyone else what happened. If two players race for a health pack, they may both think they got it. This may not be a big deal in some game designs. This mechanism is nice for FPS games, because it avoids any perceptible latency.What real games end up doing is to run the user interface as 2), but put important decisions (who got the health pack?) on an arbitrator/server, so the actual game action from the pickup request is delayed compared to the pick-up UI. This is a hybrid of 1) and 2).