3 ms·

The OP states: "When it’s time to send an update to the state, XOR it against the previous state, .. and send it." and this is not going to work if the previous

The OP states: "When it’s time to send an update to the state, XOR it against the previous state, .. and send it." and this is not going to work if the previous state just isn't there. It would be easy to fix: add a base-version number to the update. If the client doesn't know about the base-version it knows it must not update its state, but rather fetch a full state again or something. Your suggestion "make sure there is a safe base version available and then send a diff against that" makes a lot more sense.

Atrix256 8y ago
See step 1 of the 3 step bulleted list, but yeah, it generalizes to 2 steps with a shared initialization value. Maybe worth noting that if your world has some known starting state (eg after map load), it might be worth the client and server using that as the implicit initial state, even when a client joins a game in progress.
noonat 8y ago
A common solution is to have the server track which state frames that the clients have acknowledged receiving. The server can then delta compress from that client’s frame, for each client. It’s a bit more costly on the server side, as it means you need to maintain state frames back to the oldest acknowledged frame across all clients, but it guarantees you will be sending a packet a client can understand. Usually this is combined with some sort of limit which kicks a client off as timed out if its acknowledged frame strays too far from the most recent one.
golergka 8y ago
> It would be easy to fix: add a base-version number to the update. If the client doesn't know about the base-version it knows it must not update its state, but rather fetch a full state again or something. And after this, you're already half-way to TCP. Why not just use TCP for these updates anyway instead of running your own implementation?

3 ms·

The OP states: "When it’s time to send an update to the state, XOR it against the previous state, .. and send it." and this is not going to work if the previous

by radiospiel 8y ago

Atrix256 8y ago
See step 1 of the 3 step bulleted list, but yeah, it generalizes to 2 steps with a shared initialization value. Maybe worth noting that if your world has some known starting state (eg after map load), it might be worth the client and server using that as the implicit initial state, even when a client joins a game in progress.
noonat 8y ago
A common solution is to have the server track which state frames that the clients have acknowledged receiving. The server can then delta compress from that client’s frame, for each client. It’s a bit more costly on the server side, as it means you need to maintain state frames back to the oldest acknowledged frame across all clients, but it guarantees you will be sending a packet a client can understand. Usually this is combined with some sort of limit which kicks a client off as timed out if its acknowledged frame strays too far from the most recent one.
golergka 8y ago
> It would be easy to fix: add a base-version number to the update. If the client doesn't know about the base-version it knows it must not update its state, but rather fetch a full state again or something. And after this, you're already half-way to TCP. Why not just use TCP for these updates anyway instead of running your own implementation?