#bevy-networking #bevy-replicon #client-server #bevy #networking

bevy_replicon_repair

Extends bevy_replicon with client-state repair for reconnects

14 releases (breaking)

new 0.11.0 Dec 3, 2024
0.10.0 Sep 4, 2024
0.9.0 Jul 4, 2024
0.6.0 Feb 23, 2024

#913 in Game dev

Download history 110/week @ 2024-08-30 28/week @ 2024-09-06 8/week @ 2024-09-13 10/week @ 2024-09-20 9/week @ 2024-09-27 6/week @ 2024-10-04 4/week @ 2024-10-11 5/week @ 2024-11-01 2/week @ 2024-11-08 1/week @ 2024-11-15 137/week @ 2024-11-29

141 downloads per month
Used in bevy_replicon_attributes

MIT/Apache

39KB
450 lines

Bevy Replicon Repair

This crate extends bevy_replicon with client reconnect handling so that client replication state will persist across a reconnect.

Without this crate, you need to manually clean up all bevy_replicon replicated entities on a client when the client disconnects, since those entities will be replicated as new entities on reconnect.

Reconnect handling

This crate is not an all-in-one solution to reconnect handling. Client and server events (direct messages) can fail if sent at or after a disconnect. This means after a disconnect, any client with state tied to server events (or tied to the expectation that client-sent events arrived on the server) may have stale state. Typically you want the server to send 'initialization' messages to a client that has just connected, to transmit anything the client won't receive from replication.

In terms of client architecture, you generally want to trap the client in a loading screen while waiting for all initialization (or reinitialization) state to arrive, so the user can't interact with an incomplete world. You can use change detection on ServerInitTick to detect when the server's first replication message arrives, and you can manually track the arrival of expected initialization messages.

Note that renet does not support automatic reconnects. To reconnect a client you need to acquire a completely new connect token from the server/backend then recreate the renet client and transport resources.

Usage

Registering components for replication

We wrapped bevy_replicon's component-registration API AppRuleExt in our own app extension AppReplicationRepairExt.

The wrapped API lets you define a custom 'component-removal function' which will be called on client entities after the first server replication message following a reconnect. That function should remove any replication-registered components that failed to replicate after reconnecting. We provide a default function repair_component that behaves how you would expect.

Here is an example using default component-registration:

#[derive(Component)]
struct Health(usize);

fn setup_replication(app: &mut App)
{
    // bevy_replicon equivalent: `app.replicate::<Health>();`
    app.replicate_repair::<Health>();
}

Note that if you have a component that was already registered with bevy_replicon's API, you can add replication repair with add_replication_repair_fn.

The bevy_replicon component ParentSync is registered for repair by default if ParentSyncPlugin is present.

Client

Clients must include the ClientPlugin.

The client plugin includes a cleanup_prespawns option for users of bevy_replicon's client entity pre-mapping functionality. See the documentation for more details.

fn setup_client(app: &mut App)
{
    setup_replication(app);  //replicate Health
    app.insert_plugins(ClientPlugin{ cleanup_prespawns: true });
}

Server

Servers must include the ServerPlugin.

fn setup_server(app: &mut App)
{
    setup_replication(app);  //replicate Health
    app.insert_plugins(ServerPlugin);
}

bevy_replicon compatability

bevy_replicon bevy_replicon_repair
0.29 0.11 - master
0.27 0.9 - 0.10
0.26 0.8
0.25 0.7
0.23 0.5
0.21 0.4
0.19 0.1 - 0.3

Dependencies

~57–93MB
~1.5M SLoC