There's another way to look at this. The more data you send per packet, the more that can be reasonably interpolated by the client in between updates. Diffs also becomes impossible of course in cases where you're using UDP. So for instance imagine you're only sending visible targets to a player in updates, and then there is a brief stutter - you end up risking having a target magically warp onto the player's screen, which is obv undesirable. Pack in everybody's location (or at least maybe within some as the crow flies radius) and the client experience will break less frequently. Of course like you said though, now the bandwidth goes up.
I’ve written a diffing algorithm using UDP. You tell it to diff against a previous packet with an id. Every so often you send a full key frame packet so they always stay in sync and have full game state.
It works really well and cut my network traffic down by a whole couple orders of magnitude.
The trick is to figure out update grouping so you can create clean groups of things to send and diff on. Ultimately delta compression doesn’t even care what the data is, so modern net stacks do some really efficient compression in this way.
I’ve written a diffing algorithm using UDP. You tell it to diff against a previous packet with an id. Every so often you send a full key frame packet so they always stay in sync and have full game state.
Right. That's how video streams work, too. Every once in a while there's a complete frame, but most frames are diffs.
The key here though is that your server keeps the last N ticks of state (probably around 20) and calculates the diff for each player based on the last id they reported seeing. This way missing an update doesn't get you completely out of sync until the next full state sync, it just gets you a larger diff.
There is a useful intermediate approach, send more entities but use an importance algorithm to control how frequently each has their data sent. Clients keep knowledge of more entities this way, but bandwidth usage/frame can be kept stable.
Diffs aren't impossible over UDP. The client should be sending to the server which states it has locally, along with inputs. Then since the server has a (potentially non-exhaustive) list of recent states it knows the client has seen, it can choose to make a diff against the most recent of those and tell the client which state the diff is against. Then the client and server just need to keep a small buffer of pre-diff-encoded packets sent/received.
Another trade off with your approach of sending non-visible entities ahead of time is that it makes wall hacks possible.
Anyone aware of any conceptual way to “encrypt” the location data so it’s only usable if the player has line of sight? I doubt that’s easy/possible but don’t even know where to begin searching for research around topics like that.
