I am in the process of creating a flying pawn with the following characteristics:
- Physics enabled
- No gravity
- Security is not the biggest issue (e.g. run code on client and let server replicate to others)
My current implementation is basically a custom version of the character movement code, which also replicates rotation. Basically the client sends its movement to the server and if it does not deviate too much the server will accept this input. This works decent, but we get stuttering when flying on the client when playing over LAN (or simulating lag). This stuttering occurs when just flying in an open world, without collisions. I didn’t implement any smooth functions yet, but i am wondering if there are better ways to do physics based replication, since it seems that at high flying speeds (5000 unreal units/s) its nearly impossible to get correctly…
I noticed this solution by Rama: [Video] Player-Controlled Replicating Physics Movement, Simulating Physics! - C++ - Epic Developer Community Forums!
I doubt this will work for a flying game where the current position is really important and has to be very accurate on all clients.
Thanks in advance!
The forums may be a better bet to get an answer to this one as there are different approaches with different pros/cons… There is no perfect solution and this isn’t something ue4 does ‘out of the box’ well (high velocities, small changes in orientation - the opposite of typical FPS movement).
If you have derived from UCharacterMovementComponent the stuttering at high velocities will be due to server supplied corrections from the INetworkPrediction interface, more detail at Understanding Networked Movement in the Character Movement Component for Unreal Engine | Unreal Engine 5.2 Documentation
There are many very subtle things a play here eg. variable packet delivery time, clients running at different frame rates etc. etc.
I have done a fully custom movement component (for cars) based on UMovementComponent where non local clients actually display where they were a fixed time step ago (eg. 200ms). This system used projective velocity blending to interpolate historical state and so was rock solid as long as packets arrived before the fixed replay delay (fall back to snapping).
This causes as many problems as it solves:
*It is client authoritative (if position is, then everything else is)
*Player to player collision becomes a huge issue requiring custom code
*Reconcilliation code must be written for specific events to see what actually happened (eg. track check points - who got there first)
Thanks for your answer. I wrote a complete movement component using some ideas of character movement as a base. The advantage i have is that collissions are not that important, which makes physics based simulation more about correctly showing the position of an airplane without stuttering. For now this works fine under decent lag (ping 100 and lower). Its hard to prevent stuttering in any other case.
I’ve just started doing the exact same thing, making a flying pawn Descent style that is multiplayer.
This may be of use just to get a better understanding in general for multiplayer programming.