Hi Everybody, Firstly, something I am not sure about delta-compression: In Delta compression only the state of those objects, that have changed, will be send in the game-state message. OK, but what does "have changed" mean? In a game, the position of players almost always changes. So I think, an object is marked for "has changed" if the input from which it is driven changes (if the player presses or removes some kind of move button). Correct? I realize, that in FPS with not much Physic, this is not really a problem. But in this game there is supposed to be much physic with realistic collision response! OK, now I want to do delta compression for the game-states send from the server to the client on do client-side prediction. The client recives a game state. If it would not be delta-compressed, it would just set the state and pre-caclulates the game physic by the ping time. But now the state is delta compressed, what is to do with those objects that are not whithin the game state message? - Just leave them as they are, not including them in the prediction? This would lead to the pronlem that the new state might lead to some different collisions than what has been predicted so far. - Take the current state, backward predict by "Ping" and than forward predict with all the other objects? Mmh... how would I do the "backward prediction"? I would have to rewind the whole physic simulation, you might agree that that is not easy! - Take the last state send by the server and forward predict until the moment in time, all other objects are syncronized to? But that can a) be a very long time (imagin a player just standing around) and b) inaccurate because the rest of the world is beeing forward predicted with this object. How do deal with this? Any Input? Thanks! (I hope I made clear what my problem is, if this is not understandable, tell me).

Hi,
the article is great, I know it and have learned a lot from it ... but I am afraid it does not answer my question :(

If position is the only quantity you're transmitting, then you won't gain much from this kind of delta compression.

However, there's also current input state (turning, strafing, running, etc), current heading, current velocity, and other player data. Not all of these will change every packet.

Also, the "delta compared to what" question is answered by "delta from the last packet for which an ack was received from the client." This means that a server needs to keep an old state around to base state off of, another old state for attempting to get a newer baseline through, and the current state for sending. It also means that the client has to keep a number of states in copy, only pruning from the back when it receives a delta packet based on a newer packet from the server. Finally, it means that the packet header from the server must contain the ID of the packet it's basing its delta off of.

If you are reading my article on networked physics, please look at my presentation and source code "Zen of Networked Physics" -- its actually much more accurate and up to date, as i wrote it *after* the article

as a result, the article contains some errors, but the source code is a perfect working implementation

it even does some very basic delta compression, look in the source and presentation for "important moves", this is a fancy name for delta compression, effectively,

http://www.gaffer.org/downloads/NetworkedPhysics.zip

cheers all

also, to the original poster ...

to summarize the whole source and presentation, i would say that it shows how to apply all the standard tricks from fps shooter netcode to a *real* physics simulation - i hope this is what you looking for, please check it out, if you have any questions, just reply in this thread and i'll help you out

cheers man

OK, I admit, I did not look into the source code. I will do that and come back if I have questions!
Thanks a lot!!!
Nathan