I would say a physics rewind would make events more fair. My script isn’t there yet. But you are P2P so there isn’t one authority on there are many authorities over the physics state.
So his claims about Godot physics are true, but if we take the happy path of network quality. All we need to do is make sure the remote instance of the physics state is accurate. We already have velocity rotation and position. All we need is the accelerations and those are driven from user input.
Now when network quality drops… what can go wrong? Since each peer is the authority their local physics state and is true to them. How do we resolve issues where, let’s say, two players want to occupy in the same location?
What I think will happen would be resolved by one or the other peers physics engine. And it won’t look pretty and in order to resolve this fairly becomes a very complex. But I don’t think a rewind feature works for p2p network, because rewind relies on the fact that only one physics state is the truth.
But in the end it’s always going to be a game of compromises. I don’t think I have ever played a multiplayer game where there wasn’t some level of frustration over fairness when network quality is low.
I would say I’m a seasoned noob when it comes to net code. Seasoned because I do code for a living. And I want to learn net code from the ground up by developing a system for myself. But I don’t want to force you down this path. And I don’t know if I can take you further since I’m going another direction with my project.
But to answer your question, yes try sending the input over the physics syncer. Im pretty sure it will help. even if it doesn’t work out fully in all network situations, you won’t need to scrap any input/processing code refactor; and it will come handy to have it separated if you want to develop a CPU player, AI actor!
