4 ms·
> The idea is that the diffs are idempotent and will take the client to the latest state, as long as we can trust the last ack value. So if it's a diff from 3 t
by dxhdr 4y ago
> The idea is that the diffs are idempotent and will take the client to the latest state, as long as we can trust the last ack value. So if it's a diff from 3 to 6, the client could apply that diff in tick 3, 4, 5 or 6, and the final result would be the same.
Can you elaborate or give an example of how this works?
- Matheus28 4y agoImagine the following changes each tick: 1: x = 1 2: x = 2 3: x = 3, y = 5 4: x = 4 5: x = 5 6: x = 6 7: x = 7, y = 1 Diff from 2 to 4 would be "x = 4, y = 5". Diff from 3 to 6 is "x = 6", which will always be correct to apply as long as client is already on ticks 3~6. But if you apply at tick 2, you lose that "y = 5" part. This can't happen in a bug-free code because the server will only send diffs from the latest ticks it knows for sure the client has (because the client sends acks)
- dxhdr 4y agoCool thanks, that makes sense! In my head I was thinking the diff from 2 to 4 would be something like "x += 2, y += 5", and 3 to 6 would be "x += 3, y += 0"... which of course wouldn't be idempotent and wouldn't allow you to apply the update to different client states.
- Matheus28 4y agoYou can extend it to practical use by imagining these terms as: entity[123].active = true entity[123].x = 4 entity[123].y = 8 Then later... entity[123].active = false And with special rules such that if `active = false`, no other properties of the entity needs to be encoded. And if `active = true` is decoded, it sets all properties to their default value. Then you get a fairly simple way to transmit an entity system. Of course you'd want to encode these properties in a much smarter way for efficiency. But the basic idea is there