So I stated doing multiplayer in c++ and already got my movement working with network prediction (crouch, crawl, sprint). Now I started working on an Interaction system for doors etc. But everything I could find online wasn´t network predicted, so any Ideas how you could accomplish a Interaction system/door system already tryed for serveral days now but I can´t find an solution to it.
thx for any help!
Character movement network prediction is client-side prediction. You input a move, execute that move locally then send the server the move and the result. The server in turn executes the same move and compares its results to your results. If they differ the server sends a correction, otherwise it sends an ACK. This is fully covered in the Character Movement Component docs.
World interaction is usually server authoritative which requires the server to validate and init the action. Standard flow would be: the client attempts interaction. If valid it RPC’s the server to interact. The server in turn does so and determines its own results. If valid it inits the action such as setting a repnotify state on a door. The door class in turn executes its onrep function for the state… effectively opening or closing via timeline lerp.
The client could RPC to the server to interact, then set the door state on its copy, thus forcing the onrep function to execute immediately.
You’d have to write your own correction logic incase the server fails interaction. RPC owning client to force set the local state to match servers state. This would reset the door.
The problem that’s going to cause the most havoc is RPC’s being dropped.
For example you interact and locally open a door. Your outbound RPC (interact) never reaches the server. Now you’re stuck with an open door you cannot walk through. The server will correct the character movement once you penetrate the door locally. Effectively rubberbanding you back.
It’s my personal opinion that you let the server determine gameplay. Allowing clients to manipulate the game world in such ways increases desync between clients and allows for unfair advantages.
Lets say we have a two player scenario. Player A has a 30ms ping and Player B has a 150ms ping. The server is running at 30Hz (33.333ms tick interval).
Player A interacts with the door. It’ll take 15ms to get their packet to the server. 33.3333ms for the server to process and update the door state. 15ms for Player A to get the result and 75ms for player B to get the result.
Advantage here is Player A. His door will start opening 60ms before Player B’s.
This offset doesn’t matter because Player B still has the same exact delay for every one of Player A’s movements AND Vice Versa. Player A is seeing Player B’s movement further in the past.
Player A inputs movement: 15ms to server, 33.333ms for the server to process and send out update, 75ms for Player B to receive.
If you add client-side prediction to the door then player A has now gained another 48.3333ms against Player B (108.333ms total on door opening). He doesn’t have to wait for a response from the server to start moving through the door and spotting Player B.
If this was a shooter game then the increase in desync could have Player B being hit/dead before the door even opens on their client.