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.
Details
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
Even when rolling back to the earliest release, v0.5
, this error
still shows up.
Might be worth coming back to just for the sake of completeness, but I
don't think I'll be using it for my case.
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.
Details
Not sure what's causing it: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?
The git history is a nightmare of branches and merges, so I'm just
gonna assume this is a problem with matchbox
and not my machine, and
hope it gets fixed by the time I come back to it later.
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.
Details
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
2024-02-01   5 min