Replication priority

[UkoeHB]

In some games (mainly open-world games), it is useful to prioritize updating of some entities over others in order to manage bandwidth constraints.

Here is a sketch of how to integrate priority with bevy_replicon.

Sketch

Instead of true/false for client visibility, set a priority between 0 and 1.0. A priority below 0.01 means 'don't replicate', and a priority over 0.99 means 'always replicate'.

Add a global throttling resource that records a range of replication frequencies per-client: [min frequency, max frequency]. This range can be manually adjusted by users (we need to expose as many stats as possible about client acks/latency and bandwidth usage). We or someone can write a bevy_replicon_throttle crate that provides automatic frequency adjustments (hypothetically - I don't plan to write it).

• Example algorithm: on bandwidth throttle, lower the min frequency until a max range delta is reached, then start lowering the min and max frequencies such that their delta = max range delta * (max frequency / starting max frequency). If the min frequency reaches a minimum, stop lowering it and only lower the max frequency. If both reach the min frequency then ?? start throttling RepliconTick updates ?? (the problem is if frequencies are controlled per-client then we don't want to throttle non-slow clients)
• Note that we currently set replicon's resend time to 0 for the init channel. This can also theoretically be controlled (e.g. set up multiple update channels with different resend times, or make a PR to renet to dynamically control resend times).

In replication, always spawn and insert new components for entities that are visible (priority >= 0.01). Only update entities at a frequency computed from their priority mapped onto the [min freq, max freq] range.

Open question: how to map replication frequencies onto replicon TickPolicy?

• Manual: ?
• EveryFrame: ?
• MaxTickRate: ?

[UkoeHB]

This proposal supersedes #47. Inactivity throttling can be implemented on top of the priority interface.

#47 proposed throttling updates based on how old an update is. That way you can reduce the number of useless update packets that are sent (the most useful packets are the first ones sent). We can incorporate that here by adding a priority modifier based on how old is the newest component change on the entity that we are replicating.

[UkoeHB]

Note for later: bevy_replicon_attributes would incorporate this by assigning a priority modifier to client attributes. Then entity priority for a client would be computed from their visibility condition + client attribute priorities (AND: take average of branches that aren't NOT, OR: take first true branch, NOT: ignore this node; default to 1.0 priority [e.g. for an entity with condition not(A), all clients without A would have 1.0 priority on the entity]).