4 ms·

just XOR-ing doesn't cut it. The client might receive the state out of order, some updates might be missing completely - all of this must be handled somehow

golergka 8y ago
This is usually handled on a lower layer - you only use this algorithm if you can assume the updates are guaranteed and ordered. This of course means using more costly network protocols (either TCP or something custom on top of UDP), but for most game systems it's good enough, since they don't get updated that often. And for objects positions you combine the two: have reliable object state synchronized via guaranteed and ordered protocol a couple times per second, but also have UDP updates on top of it, while keeping the "reliable" copy to use for compression with the next reliable update.
- radiospiel 8y ago
  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?

golergka 8y ago

This is usually handled on a lower layer - you only use this algorithm if you can assume the updates are guaranteed and ordered. This of course means using more costly network protocols (either TCP or something custom on top of UDP), but for most game systems it's good enough, since they don't get updated that often. And for objects positions you combine the two: have reliable object state synchronized via guaranteed and ordered protocol a couple times per second, but also have UDP updates on top of it, while keeping the "reliable" copy to use for compression with the next reliable update.

radiospiel 8y ago
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?