I am working on my first project on UE5 and i am facing an issue with movement on the server.
My movement logic works, but when lauching multiplayer, the movement observed by the client are really bad. I tried to read and watch a lot of documentation but still cannot figure what is happening
Here is a video of what happening
Moving an actor on the server is clean, but the movement seen from the client is laggy.
Moving an actor on the client is laggy and the movement is “ok” on the server
Actors are replicated and have movement replication on, they are spawned by gamemode at the loading and aren’t possessed by anyone
The server is setup with an average latency but even without latency, the issue is here.
Short answer, you can’t do movement like this (for multiplayer).
There are several reasons why setting location and sending that to the server won’t work
Your server RPCs (if not set to reliable) are not guaranteed to arrive in the order they got sent or to arrive at all. (setting to reliable isn’t a good fix either as these are very expensive)
You need a proper roll-back mechanism in case there was an error so you don’t experience strong rubberbanding.
Unreal Engine already has a built-in CMC that handles movement for multiplayer by default.
You might want to check it out to learn more about the issues (I listed above) and apply those principles to your own logic.
What you could do is:
(this is just a very silly example for the sake of giving you an idea)
Continuously send your cursor position to the server including an incrementing timestamp/replication id so you can discard RPC’s that didn’t arrive in order.
Calculate the new location server-side and replicate it down to the clients
Let the clients interpolate towards the received location to not appear jittery/snappy
Clients and Servers send packets to each other at set rates. Processing and then snapping to the new location. Adding interpolation will smooth out the movement.
Preferably you’d just move the actor and pass the end location to the server. It would “attempt” the same move and either confirm or deny.
Confirmation would have it interpolate from old to new.
Failure would send an RPC (owning client) and snap the actor back to original location and give you a chance to move again.
Deterministically you shouldn’t have many failures (Corrections).
This is pretty much what i understood from documentations, i will try to do things directly on the server to see if it smooth things out, otherwise, i will only send the end location, it won’t look and feel as good as i would like but this is acceptable.