2 replaced http://gamedev.stackexchange.com/ with https://gamedev.stackexchange.com/
source | link

I understand that in a snapshot-based network replication system the server holds onto N full snapshots and uses incoming ACK'd data from the clients to construct delta snapshots. This makes sense. What I have not seen a lot of information about is how the client uses that delta compressed snapshot to apply the changes.

Does the client store N snapshots so that it can reconstitute the delta compression against the reference it claims to have, or does it simply have one snapshot state of accumulated deltas? I imagine the former being correct, but the latter being less memory.

I've read http://gamedev.stackexchange.com/questions/87553/how-would-a-game-state-snapshot-system-be-implemented-for-networked-real-time-gaHow would a game-state snapshot system be implemented for networked real-time games? and and other answers, looked at Fabien's post, and read a couple of articles by Valve, but I am still unclear.

Any thoughts on this?

I understand that in a snapshot-based network replication system the server holds onto N full snapshots and uses incoming ACK'd data from the clients to construct delta snapshots. This makes sense. What I have not seen a lot of information about is how the client uses that delta compressed snapshot to apply the changes.

Does the client store N snapshots so that it can reconstitute the delta compression against the reference it claims to have, or does it simply have one snapshot state of accumulated deltas? I imagine the former being correct, but the latter being less memory.

I've read http://gamedev.stackexchange.com/questions/87553/how-would-a-game-state-snapshot-system-be-implemented-for-networked-real-time-ga and and other answers, looked at Fabien's post, and read a couple of articles by Valve, but I am still unclear.

Any thoughts on this?

I understand that in a snapshot-based network replication system the server holds onto N full snapshots and uses incoming ACK'd data from the clients to construct delta snapshots. This makes sense. What I have not seen a lot of information about is how the client uses that delta compressed snapshot to apply the changes.

Does the client store N snapshots so that it can reconstitute the delta compression against the reference it claims to have, or does it simply have one snapshot state of accumulated deltas? I imagine the former being correct, but the latter being less memory.

I've read How would a game-state snapshot system be implemented for networked real-time games? and and other answers, looked at Fabien's post, and read a couple of articles by Valve, but I am still unclear.

Any thoughts on this?

1
source | link

In snapshot-based networked game does client store N snapshots as well?

I understand that in a snapshot-based network replication system the server holds onto N full snapshots and uses incoming ACK'd data from the clients to construct delta snapshots. This makes sense. What I have not seen a lot of information about is how the client uses that delta compressed snapshot to apply the changes.

Does the client store N snapshots so that it can reconstitute the delta compression against the reference it claims to have, or does it simply have one snapshot state of accumulated deltas? I imagine the former being correct, but the latter being less memory.

I've read http://gamedev.stackexchange.com/questions/87553/how-would-a-game-state-snapshot-system-be-implemented-for-networked-real-time-ga and and other answers, looked at Fabien's post, and read a couple of articles by Valve, but I am still unclear.

Any thoughts on this?