rapier VS ggpo

Ok, so this uses https://rapier.rs/ which is very cool

Rapier, alongside https://nalgebra.org/ (which it uses underneath) has seriously good documentation and some advanced features like cross-platform determinism (something made hard by the way floating point differs between platforms)

Code examples: see examples2d, examples3d-f64 and examples3d directories

What are the pros and cons compared to something like Rapier? When should one use Bevy XPBD instead of Rapier, or vice versa?

Still using Rust in a browser-based multiplayer party game I'm working on! I'm using Actix Web for the backend and rapier2d to handle my game's physics. I'm looking to make some more connections amongst the developer / gaming community through my game down the line.

I have noticed that Rapier 0.17 contains a RopeJoint struct, which constrains maximum distance between two dynamic bodies. It doesn't seem to have found its way into bevy_rapier3d yet so I haven't understood whether it supports (half of) my use case, and looking at the code (https://github.com/dimforge/rapier/blob/master/src/dynamics/joint/rope_joint.rs) I really cannot see how it is actually implemented and how I could extend it to also set a minimum distance, but this may be a place to start.

I was also frustrated with the kcc, so I opened a PR that fixes most of my issues: https://github.com/dimforge/rapier/pull/446

Likewise, see the js bindings of Rapier.

Maybe check out how Rapier does it. Rapier is likely the most advanced physics engine in Rust. (Though Embark Studios is doing some crazy stuff with ML physics.)

As mentioned in the top comment, rollback and client side prediction is key. One of the more robust and popular libraries that do this specifically for fighting games is GGPO. When it was opened sourced a few years ago it was a fairly big deal as games that used it felt great. Larger studios have their own libraries but the concept is the same. Its worth a look through if you want to implement something on your own.

I just did a quick Google so I don't know the exact details, but I think Max said Idol Shodown is running GGPO which, as far as I can tell, is open source.

will reply here also in case anyone else wanted an answer. You could use the original C++ library with C++ or any language that interops with C++ (e.g. C#), so that's there for ya if you need

Sure thing bud. I guess we'll just keep pretending like Code Mystics, the same people that did the KI netcode, haven't partnered with SNK because SNK realized their shit sucks and they needed external assistance. We'll pretend like the source code for GGPO is hidden away in the recesses of Tony Cannon's mind or that it isn't open and free for anyone to use or that it doesn't have Japanese documentation. We'll pretend like MikeZ didn't implement a version of GGPO in Skullgirls in 2012.

GGPO is a common implementation and it's all open source if anyone wants to get into the nitty-gritty: https://github.com/pond3r/ggpo

Backroll-rs is a brand new networking library based on GGPO dedicated to peer-to-peer Rollback Netcode, for use in fighting games, platform fighters, and other games with less than 8 players that require low latency. We are looking for programmers familiar with Rust to help finish this project. We are 80% of the way completed with this project, but we need more unit tests and debugging to fully finish it.

This doesn't work in the comparison to shooters. Shooters operate through a server, while fighting games are peer-to-peer. They only require a server for matchmaking purposes. Doing the peer-to-peer part actually puts fighting game devs at an advantage compared to other genres, as there's libraries and documentation for those libraries to either plug and play a rollback solution or build one buy looking at existing source code complete with solid documentation.

GGPO doesn't really solve the biggest problem with SFV's netcode, which is client timesync. It does have code in there to handle it by slowing down the client that's ahead and allowing the client that's behind to catch up, but that doesn't fix the fact that one client consistently gets ahead in the first place, and also means the faster client will see more stuttering or slowdown.