I am working on a game where you have a train and inside a train is a lever that players can use to start or stop the train. Once you switch the lever to start position, the train will start accelerating until it reaches max speed, or until it gets to 0 speed if you switch the lever to ‘stop’ position.
My question is, should I replicate only this state change (Start, Stop) or the actual train position, since I calculate train position by using custom velocity logic (I am not using physic for this) and I am not sure if this can lead to desynchronization (clients don’t have the exact same train position locally).
Hope this question was clear enough and thanks in advance!
There isn’t really a way to ensure that every client’s train is at the same position without replicating. But I would suggest to pass the state change via reliable RPC, and replicate the train’s position and velocity from the server to the clients.
An example for why I say there’s no way to ensure that the trains positions are the same at all times only with the state change:
You use a reliable RPC from the server to all clients saying the train lever is down, the train may start. P1 & P2 receive this call at exactly the same time, and the trains are perfectly in sync.
P2’s brother starts up a netflix stream, and P1 puts the lever up. Since P2’s network now has more traffic, the call for lever up takes 0.4ms longer to get to P2 than P1.
As a result of this, the train on P2’s client travels at max speed for 0.4ms longer, and therefore travels further.
This is a pretty unnoticeable difference, but imagine there’s a lightning strike, or the router randomly crashes, or there’s an outage even just for a couple seconds. Now P2’s train has travelled much further, with no way to sync them back together.
As a rule I would say to always use a reliable RPC for important state changes, and replication for everything else. I say this because it’s important to remember that replication will always send the most recent up to date information, and won’t stack messages to ensure that everything gets to all the clients. In the case of reliable RPC’s, the server will send a message for an event, and continue to send that message until they receive a confirmation that the client has received it. After which the server will send any messages that stacked up behind that message.
What you don’t want to happen (and what could happen if you simply replicated the state of the lever):
P1 flips the lever to open → immediately flips it back to closed → after 0.1 seconds flips it back open.
There is a non zero chance that P2 misses the replication of the lever being closed, if they got the message that the lever was open and then experienced some packet loss for a tenth of a second. This would result in the train on P2’s client reaching max speed 0.1 seconds faster than P1. Resulting in desynch
Thanks a lot for the detailed answer, I really appreciate it. I never though about connection interrupts/lags so this is really helping me a lot.
I still have a question tho - does this mean that the best way to do this is to replicate train’s position constantly, right? By replicating the train, I guess you meant to say that I should tick the train’s actor as ‘replicated’ right?
Also, is there a way to simulate these interruptions or delays inside the editor itself?
Replicating the train actors would be my suggestion yeah.
As for simulating the lag, I’ve not done that myself but a quick search found this configuration panel in UE4 (and I can only imagine it still exists in UE5)
So if you want to see yourself the difference between non replicated and replicated results this would be a great way to see it!
Problem with using RPCs for important state changes is the client will not be aware of this new state if they were not ‘relevant’ at the time of the RPC. This can lead to an incorrect state.
For example, if the player just joined, they will not know of the previous state. Also, if the player was too far away from the train (to the point they were no longer ‘relevant’), when they do get back close to the train, its state will be out of date.