bevy_replicon

Crates.iobevy_replicon
lib.rsbevy_replicon
version
sourcesrc
created_at2023-03-28 23:09:26.920233
updated_at2024-12-02 00:45:57.339946
descriptionHigh level networking for the Bevy game engine
homepage
repositoryhttps://github.com/projectharmonia/bevy_replicon
max_upload_size
id823540
Cargo.toml error:TOML parse error at line 27, column 1 | 27 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include`
size0
Hennadii Chernyshchyk (Shatur)

documentation

README

Bevy Replicon

crates.io docs.rs codecov

Server-authoritative networking crate for the Bevy game engine.

Features

  • Automatic world replication.
  • Events-based messaging API.
  • Control over client visibility of entities and events.
  • Replication into scene to save server state.
  • Support for client and server both in one App and in separate.
  • Customizable serialization and deserialization even for types that don't implement serde traits (like Box<dyn Reflect>).
  • No builtin I/O, can be used with any messaging library. See messaging backends for already available integrations.
  • API focused on writing logic once that automatically works for singleplayer, client, server, and listen server (when server is also a player).
  • Extensible architecture. See related crates.

If you are new to networking, see glossary.

Goals

The purpose of the crate is to provide a minimal and fast core that can be extended with the necessary features to ensure smooth gameplay. Consider the following examples:

  • A slow paced centrally hosted game wants ECS-level replication, and maybe some interpolation on top.
  • A slightly faster paced game might care more about order and need a lockstep system.
  • A shooter needs client prediction for the player and interpolation for everything else.
  • A sports game, or an online game featuring mechanics more complex than most shooters, needs ECS-level replication with full rollback on the entire world.
  • A fighting game only needs to replicate some input events and needs rollback on top.

All of these examples also have drastically different optimization requirements. This is why modularity is essential. It also allows for more developers to be involved and for each to maintain what they use.

Check out related crates to extend the core functionality.

See also What kind of networking should X game use?.

Getting Started

Check out the quick start guide.

For examples navigate to messaging backends repositories because you will need I/O in order to run them.

Have any questions? Feel free to ask in the dedicated bevy_replicon channel in Bevy's Discord server.

Related Crates

[!WARNING] Ensure that your bevy_replicon version is compatible with the used crate according to semantic versioning.

Messaging backends

Helpers

  • bevy_bundlication - adds registration of replication groups using a bundle-like api.
  • bevy_replicon_attributes - adds ergonomic visibility control through client attributes and entity/event visibility conditions. An extension of this crate's raw client visibility API.

Interpolation and/or rollback

Miscellaneous

Unmaintained

  • bevy_timewarp - a rollback library that buffers component state. See this instruction about how to integrate.

Bevy compatibility

bevy bevy_replicon
0.15.0 0.29
0.14.0 0.27-0.28
0.13.0 0.23-0.26
0.12.1 0.18-0.22
0.11.0 0.6-0.17
0.10.1 0.2-0.6
0.10.0 0.1
Commit count: 543

cargo fmt