I failed to build multiplayer pong in Rust

P2P multiplayer games with rollback networking *and* physics are hard to build in the Bevy ecosystem today. This video dives into what makes it difficult and what parts work out of the box.

[MrBrannfjell]

I think a common way used by many MMORPG games, is to simulate the world on the server (along with its physics), not only just validating actions. That way the client is primarily a screen to view what is being broadcasted to it, and an "action requester" to request actions to be taken by the entities you have permission to on the server.
This way, you only need a bare minimum of client side predictions to predict wether or not your requested actions are granted and what you should do. Everything else is parsing and presenting data recieved from the server.

[dport]

I've tried many times to get networking + physics working and it's always a struggle. Many networking crates out there seem promising but always have some weird quirks and/or are unmaintained. Similarly I've had the kind of physics issues you describe. In general it also feels quite hard to hook everything up. Glad to see you're looking into this stuff, your examples and vids are always super helpful!

[MuscleTeamOfficial]

This is one of those videos that I didn't know I wanted. Fun to hear you deep dive into these multiplayer game problems.

[EdwardBeech]

Awesome video- I went down this rabbithole trying to use Bevy to make multiplayer version of Asteroids that ran in the browser and using WebSockets

I got it working but not really smoothly and then sort of gave up once the invisible part of the iceberg of the problem became apparent

[ballingt]

Thanks for sharing your experience here! I've been playing with writing my own physics in Rust to use in browsers but had been hoping to look into libraries later — really helpful to know this will be tricky.

[TheRedAstro]

I've been struggling to build a network multiplayer with bevy + rapier for quite some time now and always felt the need to pretty much rewrite the basic components of physics and networking (I'm writing my own client / server with lobby management right now, for instance). I thought that this was due to my lack of understanding of the crates available in the ecosystem (which is true), but it seems though that we also don't have very mature solutions for deterministic multiplayer architectures as of now. Great video, thanks for sharing your experience.

[osoznayka]

I am using Rapier for 2 month already for my game and I am totally exhausted.
The way that rapier uses it's own world is completely wrong for bevy.
I can not remove Collider from entity in system => bevy_rapier just don't see this, it watch for Changed<Collider>.
I can not change from RigidBody::Dynamic <=> RigidBody::Fixed/Kinematic in system, it leads to potetially error phone state in the future.
I can not use PostUpdate for system and remove some entity inside the system => rapier in next frame will fail.
And some other small issues...

I will definitely try XPBD, thanks for suggestion! I thought that only one maintaneable physics library is rapier.

[WomboBraker]

fuck, i've been dreaming of building a physics based multiplayer simulation game with bevy.

[MattBolt]

You’re not really going to find out of box solutions for these problems, as I would’ve been out of the job a long time ago. Even in more complex games, you don’t really need a full physics simulation rollback. I do find it interesting that you assumed deploying a server too much to take on, but jumped straight into prediction and rollback. Start with basic p2p hard synchronization, and then improve on that.

[tenthlegionstudios]

Great video. This is definitely a course I would pay for once you get it up and running. I have gone down the multiplayer rabbit hole multiple times - very complex problem with physics. I still have only ever managed turn based games. I have been messing around with using wasm on v8 cloudflare workers on the edge for finding lobbies, keeping connections etc... Especially for small projects where you can have a small DB on the edge and could keep the entire server game logic there. I would also pay for a course going deeper into turn based games :) . Keep up the great content!

[MorninCupofHate]

The best way to achieve this would still be an authoritative server/client setup. It can all be done in P2P with only a low power low bandwidth matchmaking server in between. Prediction/rollback is also extremely easy to implement, as long as you can manually tick the physics engine.
In game networking, people like to make a huge fuss about "physics determinism", but it hardly matters as long as they're visually very close. It doesn't matter if one computer calculates floats differently from the other, because rollback completely takes care of any discrepancies.

Prediction will ensure that both players feel like they're the host. If you do it right, it should be very hard to tell.

[seancribbs]

Love the shoutout to the Fallacies of Distributed Computing.

[eptic-c]

I mean, if you implement server reconciliation you can always come back to the right path if the physics break, but you would have to consider one of the peers the source of truth

[sirdorius]

12:06 Have a great Rust of the of the day!

[felixandreas]

Doesn't solve any of the problems mentioned, but it might make server development easier: Have you tried the new spacetimedb or maybe even integrated it with Bevy? Rust + game-dev seem to be first class citizens and realtime updates + persistent state + type safe rpcs seem to be very nice too. Since the server modules are also written in Rust, it might be possible to run the source-of-truth simulation on the server and reuse the same code on the client ...

[AndrewBrownK]

so many good looking crates! I guess the only right choice is to build my own lol

[RogerValor]

I totally disagree, that p2p is better for learning. In fact, I find it better to learn server client immediately, as I find it is better to eat the bigger frog in this case first;

I find your choices are trying to go the easy path here, and by that extension, landing in the actually more complicated issues of networking.

it might be easier to start with mmo full sync, go over to simple fps sync, then go for prediction and layed back integration, and only finally in the end touch the hot sauce of rollback networking.

[Holobrine]

The latency between clients producing discrepancies reminds me of how gyroscopes have drift in robotics use cases, and they solve that problem by also using magnetometers and accelerometers (with slower measurement rates) and Kalman filters, and combining them into a sensor called the IMU. Maybe some inspiration can be taken here.

Also, what if for events like collisions, it’s acceptable to wait for the server or consensus, but otherwise local simulation suffices for free motion? You could wait for the server if a possible collision is within an error tolerance, and receive occasional physics state corrections so the local simulation doesn’t drift off too much.

[alexpyattaev]

rollback and ECS do not mix well. or you need two different worlds, one for rollback etc and one for graphics.