   Sending change or exact position?
  I've been reading how networking works in games, and have found several, specifically Quake 3, send the different over the net.  Is there an advantage to sending the change since a given time to what the latest position of everything is?Thanks.-Nick   
  If you send the change then your packets might be a little smaller. However consider what happens if a packet get dropped. As little as one dropped packet will result in the players being out of sync with each other, and this problem will become worse as the game progresses until it becomes unplayable   ;  I believe allowing the player to send its position opens the door to various cheats like teleporting. Its easier to check that position changes are valid than to check absolute positions. Better yet, let the client just send the commands entered. Thumbrule: never thrust the client application!@Vyper_uk: If player actions (including movement) are not sent over a TCP or TCP-like link (that guaranties that the packets will get there eventually), then the server and the client should check if they are still well sync to each other.   ;Quote:Original post by Vyper_ukHowever consider what happens if a packet get dropped. As little as one dropped packet will result in the players being out of sync with each other, and this problem will become worse as the game progresses until it becomes unplayableThis can be solved by having the client acknowledge received packets. The server then sends changes to a particular client based on its last acknowledged update. The client should timestamp each acknowledgement, and the update packets should include the timestamp of the last known acknowledgement. That way, if an acknowldegement gets lost, or the server sends an update before the  it has received the ack of the last update, the client can compare timestamps to know which state to base the update off of.;  My current architecture trusts nothing to the client.  All the client does is take input, and send the data using bitflags for buttons pressed to the server.  My question is of how the server sends data to the client.   ;Quote:Original post by nickwintersMy current architecture trusts nothing to the client.  All the client does is take input, and send the data using bitflags for buttons pressed to the server.  My question is of how the server sends data to the client.You can send positions directly on each update, or send only differences, but that requires a reliable connection, or you need a 'difference packet compared to packet number x' field, and if you keep a previous packet history on the client, you can decompress it. You might also consider sending full updates once in a while so hopelessly out of sync clients can catch up.Viktor;  When Quake 3 sends a "difference" it means that it sends the parts of the player struct that have changed; it does not mean it sends (pos-lastpos).So, if the player struct contains fields for pos, vel, health, ammo, and current weapon, then there would be five bits in the header, saying which of the fields are included in the packet. The baseline for comparision is the last acknowledged packet the client received. This is more described in the Forum FAQ.   