It’s a crate for server-authoritative networking.
We worked closely with the author of bevy_bundlication on this release to provide better abstractions for third party plugins on top of replicon. Here are some highlights:
Previously, users registered a component for replication and it was replicated if its entity was marked for replication. But this approach is quite limited. Now users can define replication rules similar to queries:
app.replicate_group::<(Transform, Player)>() // `Transform` and `Player` components will be replicated only if both present on an entity.
And it’s possible to specialize ser/de for such groups. For example, replicate Transform in one way for players and in another way for static objects.
Groups with more components take priority by default (but it’s configurable). So it’s also possible to have app.replicate::<Transform>(), but if Player component is present, (Transform, Player) will take precedence.
In the next release we planning to support With and Without to let define something like this: app.replicate_group::<(A, B), Without<C>>().
Also check out 📦bevy_bundlication which is now an abstraction over replicon that provides a bundle-like API for defining replication groups.
Custom replication functions was also heavily reworked:
- Public API no longer requires any
unsafe. - Deserialization and writing now defined separately. This allows rollback crates to define their logic without touching user-defined ser/de functions.
- Writing now based on markers for more flexibility.
- Users can customize deserialization in-place.
The author of bevy_bundlication also developing input queue and rollback plugins, but they require an API for disabling entities from Bevy. If you are interested in this or have other suggestions how to achieve it, feel free to comment on this issue.