Relationships networking (#473)

Co-authored-by: UkoeHB <37489173+UkoeHB@users.noreply.github.com>

Author: Shatur

CHANGELOG.md

@@ -10,6 +10,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 ### Added
 
 - Support for `no_std`.
+- Relationships networking. Use `SyncRelatedAppExt::sync_related_entities<C>` to ensure that entities related by `C` are replicated in sync.
 - Seamless support for immutable components. For these components, replication is always applied via insertion.
 
 ### Changed

Cargo.toml

@@ -30,6 +30,9 @@ members = ["bevy_replicon_example_backend"]
 [dependencies]
 bevy = { version = "0.16.0-rc.5", default-features = false }
 log = "0.4" # Directly depend on `log` like other `no_std` Bevy crates, since `bevy_log` currently requires `std`.
+petgraph = { version = "0.8", default-features = false, features = [
+  "stable_graph",
+] }
 variadics_please = "1.0"
 typeid = "1.0"
 bytes = { version = "1.10", default-features = false }

src/lib.rs

@@ -209,6 +209,8 @@ This behavior is also configurable via [client markers](#client-markers).
 Some components depend on each other. For example, [`ChildOf`] and [`Children`]. You can enable
 replication only for [`ChildOf`] and [`Children`] will be updated automatically on insertion.
 
+You can also ensure that their mutations arrive in sync by using [`SyncRelatedAppExt::sync_related_entities`].
+
 ## Network events and triggers
 
 This replaces RPCs (remote procedure calls) in other engines and,
@@ -549,9 +551,9 @@ All events, inserts, removals and despawns will be applied to clients in the sam
 However, if you insert/mutate a component and immediately remove it, the client will only receive the removal because the component value
 won't exist in the [`World`] during the replication process. But removal followed by insertion will work as expected since we buffer removals.
 
-Entity component mutations are grouped by entity, and component groupings may be applied to clients in a different order than on the server.
+Entity component mutations may be applied to clients in a different order than on the server.
 For example, if two entities are spawned in tick 1 on the server and their components are mutated in tick 2,
-then the client is guaranteed to see the spawns at the same time, but the component mutations may appear in different client ticks.
+then the client is guaranteed to see the spawns at the same tick, but the component mutations may appear later (but not earlier).
 
 If a component is dependent on other data, mutations to the component will only be applied to the client when that data has arrived.
 So if your component references another entity, mutations to that component will only be applied when the referenced entity has been spawned on the client.
@@ -612,7 +614,8 @@ pub mod prelude {
                 server_trigger::{ServerTriggerAppExt, ServerTriggerExt},
             },
             replication::{
-                Replicated, command_markers::AppMarkerExt, replication_rules::AppRuleExt,
+                Replicated, command_markers::AppMarkerExt, related_entities::SyncRelatedAppExt,
+                replication_rules::AppRuleExt,
             },
         },
     };

src/server.rs

@@ -30,6 +30,7 @@ use crate::shared::{
     postcard_utils,
     replication::{
         client_ticks::{ClientTicks, EntityBuffer},
+        related_entities::RelatedEntities,
         replication_registry::{
             ReplicationRegistry, component_fns::ComponentFns, ctx::SerializeCtx,
             rule_fns::UntypedRuleFns,
@@ -249,6 +250,7 @@ pub(super) fn send_replication(
         &mut ClientTicks,
         Option<&mut ClientVisibility>,
     )>,
+    mut related_entities: ResMut<RelatedEntities>,
     mut removal_buffer: ResMut<RemovalBuffer>,
     mut entity_buffer: ResMut<EntityBuffer>,
     mut despawn_buffer: ResMut<DespawnBuffer>,
@@ -259,9 +261,12 @@ pub(super) fn send_replication(
     server_tick: Res<ServerTick>,
     time: Res<Time>,
 ) -> Result<()> {
-    for (_, mut mutations, mut updates, ..) in &mut clients {
+    related_entities.rebuild_graphs();
+
+    for (_, mut updates, mut mutations, ..) in &mut clients {
         updates.clear();
         mutations.clear();
+        mutations.resize_related(related_entities.graphs_count());
     }
 
     collect_mappings(&mut serialized, &mut clients)?;
@@ -272,6 +277,7 @@ pub(super) fn send_replication(
         &mut clients,
         &registry,
         &type_registry.read(),
+        &related_entities,
         &removal_buffer,
         &world,
         &change_tick,
@@ -471,6 +477,7 @@ fn collect_changes(
     )>,
     registry: &ReplicationRegistry,
     type_registry: &TypeRegistry,
+    related_entities: &RelatedEntities,
     removal_buffer: &RemovalBuffer,
     world: &ServerWorld,
     change_tick: &SystemChangeTick,
@@ -535,12 +542,13 @@ fn collect_changes(
                     {
                         if ticks.is_changed(tick, change_tick.this_run()) {
                             if !mutations.entity_added() {
+                                let graph_index = related_entities.graph_index(entity.id());
                                 let entity_range = write_entity_cached(
                                     &mut entity_range,
                                     serialized,
                                     entity.id(),
                                 )?;
-                                mutations.add_entity(entity.id(), entity_range);
+                                mutations.add_entity(entity.id(), graph_index, entity_range);
                             }
                             let component_range = write_component_cached(
                                 &mut component_range,