Bevy netcode

bevy_simple_networking

Seems like a good place to start. From my cursory view of its code, it seems like a very thin wrapper on top of the networking tools in the standard library. On top of that, the library handles connections and timeouts and stuff, but not much more. Not sure exactly what the use case is, but the most complex example is a chat system. Trying it out, it was very rudimentary (which was to be expected, given the name), and seems like it would require a lot of work to use this for synchronizing game state.

bevy_spicy_networking

One of the top search results. Based on the readme, it seems pretty similar to bevy_simple_networking. Both have online chat as the primary example, and seem intentionally minimal in what they abstract. bevy_spicy_networking uses TCP instead of UDP, which I think is a strange choice.

When I tried to run the examples, the library itself compiles, but the examples don't.

error[E0597]: `desc_set` does not live long enough
    --> /home/jaxter/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-core-0.7.1/src/device/mod.rs:1529:26
     |
1516 |         let mut desc_set = desc_sets.pop().unwrap();
     |             ------------ binding `desc_set` declared here
...
1529 |                     set: desc_set.raw_mut(),
     |                          ^^^^^^^^ borrowed value does not live long enough
...
1549 |     }
     |     -
     |     |
     |     `desc_set` dropped here while still borrowed
     |     borrow might be used here, when `write_map` is dropped and runs the `Drop` code for type `BTreeMap`
     |
     = note: values in a scope are dropped in the opposite order they are defined
For more information about this error, try `rustc --explain E0597`.
error: could not compile `wgpu-core` (lib) due to previous error

naia

At time of writing, this one is the only one recommended on the Bevy website, but according to someone in the Bevy Discord channel (which should absolutely be a persistent searchable forum instead), Bevy doesn't actually have any networking libraries that it formally recommends.

Unexpectedly and near-unusably high latency (around 1 second) turns out there's a configuration for conditioning the network set in naia/demos/bevy/shared/src/protocols.rs, set by default to poor_condition(), which has 400ms latency (one-way). Setting this to good_condition() results in a much more usable latency.

matchbox

I believe it's not suitable for my case because it's p2p, but it seems cool, and would be fun to try out in the future for a game with fewer players, and would likely result in even lower latency (at the cost of greatly increasing the bandwidth).

I wanted to try it out anyway, but there was a dependency issue that I didn't feel like figuring out.

error: failed to select a version for the requirement `indexmap = "^2.0"` (locked to 2.1.0)
candidate versions found which didn't match: 2.0.2, 2.0.1, 2.0.0, ...
location searched: crates.io index
required by package `petgraph v0.6.4`
    ... which satisfies dependency `petgraph = "^0.6"` (locked to 0.6.4) of package `bevy_utils v0.12.1`
    ... which satisfies dependency `bevy_utils = "^0.12.1"` (locked to 0.12.1) of package `bevy_internal v0.12.1`
    ... which satisfies dependency `bevy_internal = "^0.12.1"` (locked to 0.12.1) of package `bevy v0.12.1`
    ... which satisfies dependency `bevy = "^0.12"` (locked to 0.12.1) of package `bevy_ggrs_example v0.7.0 (/home/jaxter/git/not_mine/matchbox/examples/bevy_ggrs)`
perhaps a crate was updated and forgotten to be re-vendored?

lightyear

This is one of the more recent crates, so I didn't have super high expectations for it.

Unfortunately, I couldn't compile it, and the error message is suspiciously similar to the one for matchbox, which makes me think it's something to do with my machine, or with indexmap.

was a PEBCAK issue, works great and im using it now.

error: failed to select a version for the requirement `indexmap = "^2.1"`
candidate versions found which didn't match: 2.0.2, 2.0.1, 2.0.0, ...
location searched: crates.io index
required by package `metrics-tracing-context v0.15.0`
    ... which satisfies dependency `metrics-tracing-context = "^0.15"` of package `lightyear v0.6.1 (/home/jaxter/git/not_mine/lightyear/lightyear)`
perhaps a crate was updated and forgotten to be re-vendored

bevy_simplenet

info: syncing channel updates for 'nightly-2023-12-18-x86_64-unknown-linux-gnu'

😬

Examples seem to work though, and latency is reasonable. Like with naia, I'm willing to use this, but I'd prefer to avoid nightly, so I'm going to try something else first.

bevy-rtc

Example works, very low latency.

Replicon

This is the library I was most excited about (particularly because it describes itself as a "high-level networking crate"), and it hasn't disappointed so far.

• The example runs, which puts it at at least second place of the 5 crates I've tested so far.
• There are a few weird stuttering artifacts in the simple box example, but that's consistent with the statement in the readme saying that they don't do any prediction or interpolation (it even recommends the bevy_replicon_snap crate for interpolation!)
• The near instant latency is a refreshing thing to see compared to naia's 1 second latency. Even though I've only tested it on the local network, I'm very hopeful that this will at least be usable.

I was initially intending to try to implement my game with at least 2 or 3 different libraries, but after going through all the examples, it seemed like just picking one and using it would make the most sense. The one I chose was Replicon, and my main reason for picking it was just kinda vibes.

I've documented my process adding Replicon to an existing game in this blog post

All pages