I’m still researching netcode solutions and leaning towards Fishnet, but I have a question before investing some time.
I want to network physics (already a rough start). I have two physics simulations:
Internal Unity physX (rigidbodies)
Obi Rope (a particle based physics engine that is stable for rolling back/syncing properties)
How smooth and accurate is the rigidbody sync and lag compensation for Fishnet for a fast, physics-fighting game?
(I lied, two questions)
How confident can I use Fishnet to serialize and pass the rope particle data back and forth (sync)? In PUN I would use something like the IPunObservable interface to sync the particle data.
My other research led me to NGO and Photon Fusion. Fusion’s business model is not for me (CCU-based scale). NGO is hard to tell what state it’s in based on the frequent updates which is a good thing but causes resources to get outdated quickly 
Here are the particles visualized:
This is something you need to test and experience for yourself. I mean if someone said “very smooth” and may or may not add a caveat “for networked physics” you will be none the wiser.
Your game depends on it so you HAVE to test it! 
I always caution against doing networked physics as this is incredibly challenging, if not next to impossible without custom physics.
Most recently someone was approaching the Chained Together game with the idea that the chain is networked physics, when this game (and most others) is likely only applying the physics (here: chain) after the fact. This is the post, you can see what happens to the chain.
Your setup is similar, even though Obi uses a different type of simulation so it may behave more stable. The rope motion will still be affected by latency which can cause huge discrepancies between clients.
If you can design your game to work with regular, predictable motion but apply the physics after the fact in a way that the physics behaviour matches well with the gameplay, then this route of going forward is by far the best option.
1 Like
Thanks for the insight and references! this will help a lot and that is a solid idea. There is room to play on how it should be done.
I was going to have the actual simulated balloon/rope be invisible with server auth adjustments and then a visible actor interpolating through the corrections of the invisible simulations.
This redundancy has proven to be solid for physics games but like you said, this kind of stuff needs to be tested due to the nuances.
Speaking of physics, I even prototyped a rope with Unity Physics (ECS version) and job-ified it. Performance is so much better with Unity Physics now BUT I realized the engine isn’t fully deterministic like it stated (or I misinterpreted) and making Burst deterministic isnt actively being worked on so I would have the same troubles with networking using it It being stateless has potential to keep entities states for rollback but that is a decent amount of work for tech that was just released prod ready.
(I didn’t have time to learn ECS graphics to generate a mesh around the particles but concept is there)