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: ?