   synchronizing and applying events
  I am not a noob I read the whole faq already.Lets forget about the packet loss, our of order and packets duplicated for a while and talk only about the game latancy and game's events.I know how to set the client prediction, and client correction system.But i have not saw anything how the game events like ( such hitting something, or punching something) are sincronized, are they applyed right away in the server side or are they delayed untill both clients has sent their input in such x game tick time?how are the events sincronized when the client side has client predition?For example, if client 1 has a latancy of 80 game ticks and client 2 a latancy of 20 game ticks, and if there is an interation with both players,  the server will always correct/position the client 1 . The client with the less game latancy will overload the other client's events.See this graph.[Edited by - Sneftel on May 11, 2009 12:52:29 PM]
  You may want to look into how it's done in the Source Engine. Basically what they do is that they keep a record of where a player's hit boxes have been located historically. Then when a player fires a shot, the server, knowing the latency of that player, calculates the position of the target's hit box at the time the player fired.For example, say that client 1 has a latency of 80 ms, and client 2 has a latency of 120 ms. Client 2 is moving at a constant pace. At t=0, client 1 sees client 2 and fires. It takes 80 ms for the packet to reach the server, so at t=80 the server starts to process it. Now, knowing that client 1's latency is 80ms, it can calculate the position of the target (client 2) by rewinding the simulation by that amount. In the rewinded state it fires the shot, and if client 2 is hit then damage is dealt.   ;Quote:Original post by WindryderYou may want to look into how it's done in the Source Engine. Basically what they do is that they keep a record of where a player's hit boxes have been located historically. Then when a player fires a shot, the server, knowing the latency of that player, calculates the position of the target's hit box at the time the player fired.For example, say that client 1 has a latency of 80 ms, and client 2 has a latency of 120 ms. Client 2 is moving at a constant pace. At t=0, client 1 sees client 2 and fires. It takes 80 ms for the packet to reach the server, so at t=80 the server starts to process it. Now, knowing that client 1's latency is 80ms, it can calculate the position of the target (client 2) by rewinding the simulation by that amount. In the rewinded state it fires the shot, and if client 2 is hit then damage is dealt.So after, the rewinded state is applyed, what the server will do when the packet of client 2 is arrived at t= 120?  It will out of sinc!   ignore it and send an correction?if yes then it is the same thing i was doing.The question of my post is how the servers will handle the correction after recieving the input of the target client in your example the input of the client's 2 at time 120 ms?   ;  Sorry, I clearly didn't fully understand your question. I still think you should read that article on Source networking though, it's rather informative.Anyway, depending on the complexity of the interactions it might be possible to simply ignore what happened first. For example, if the "actions" are merely shots being fired, your players are unlikely to notice that their shots sometimes hit last even though they fired first. Then there are of course situations where ignoring order is unacceptable. If that is the case, maybe you can deque such requests in a small buffer and keep them there for, say, 100 ms (if response time is not vital)? Every 100 ms, you examine the buffer's contents and determine which action to perform first based on the latencies of the senders.   ;  Depending on the type of game one way to do what you're doing is lock stepping.  Syncing 1500 ArchersAt least, I'm pretty sure this is what is commonly referred to as lock stepping.  The article will explain it better than I ever could, but as a quick synopsis, it pretty much works on the concept that all events happen on all the machines at the same time, but the events are going to happen on a predetermined delay (usually one or two round-trip lengths of the largest ping).Downside is that you're at the mercy of the largest ping, and the sim needs to be wholly deterministic.  This (according to the article) is one of the hardest parts to debug. (Oh, they don't really go into this, but you can do client side prediction with this, but you need to remember the state of the game during the next to-be-processed client-step, and then reload, re-sim, and correct - or rewind if you will)Mostly used for RTS's, but games like Crackdown are known to use it.  I'm also convinced this is also how Street Fighter IV does their sync as well (but I have no proof, so don't quote me on that :P );Quote:if client 1 has a latancy of 80 game ticks and client 2 a latancy of 20 game ticks, and if there is an interation with both players, the server will always correct/position the client 1The basic take-away from this realization is: "Latency sucks." That's why the term "LPB" came about. If there was no advantage to having a low ping, they wouldn't need to be called out.Network game design is as much about the art of hiding latency and temporary divergence, as it is about shuffling bits between point A and point B in an efficient manner. Often, you end up having to intertwine marshaling, AI, physics and rendering all into the networking approach to deliver a high-quality experience.