Client-side prediction jitter

Hello everyone,

I just changed my game to implement the CharacterController from DOTS Samples and am using the netcode package to handle the multiplayer sync.

My issue:
It looks like the client side prediction isn’t working properly. When i try to move the local player he starts to jitter.

My remarks:
When I put the latency to something like 80ms , the character starts to jitter in place for 80ms (until snapshots arrives) then he starts to move and jitter.
It looks like the prediction is overridden by something.

Thanks!

has anyone faced this issue ?

Hey,

I need a little more information to understand what is going on.
There may some problem with prediction for many reasons: mi-spredictioni in primes, if you set intepolaton as smoothing method in the physics object (there is bug, fixed in later version) and other causes.
Can you post a small video/gif or describe a little more?

1 Like

I will post a video and a mini reproduction project.
I will try to do this for the next 24 hours.

thank you!

hello again :slight_smile:
i just uploaded a video and mini reproduction project.

Reproduction Project: (1mb size)
https://drive.google.com/file/d/1sGN6KuYEq2gPW33XxaBr6A6KpOwrUPYX/view?usp=sharing

Video Netcode Jitter:

https://www.youtube.com/watch?v=q1SAXYIosf8

to me, it looks like prediction is being overridden by snapshots.

Hey! Sorry, I didn’t take a loot yet. will come back soon

1 Like

So, I looked into your sample. The problem is your current setup.
You are not using predicted physics. However, you are moving the client inside the FixedStep group. That break the
“clien-side prediction”.

The FixedStep group runs differently on client and server. In particular:

  • on the server is running every frame (because the server run at fixed time step).
  • on the client it may or not running for the given frame (because it is not using a fixed step update). Also there is client-side rollback to take into consideration.

The internal character controller state is not completely stateless either. The CurrentRotationAngle in particular is not replicated but it is affecting where you are moving toward (but it is no rollback).
Also the calculated velocity is not replicated. As well as other states

So, to make this work, with this current setup (no physics prediction on the client) the first thing to do is move the character controller to be part of the PredictionSytemGroup. You should probably start replicating the CharacterControllerInternalData:

  • the CurrentRotationAngle
  • the PhysicVelocity

I would also increase the translation quantization to 1000.

By doing this the motion jittery should be fixed. There are other issue though: you then need to split the job scheduling for the DeferredImpulse in another system that run in the FixedStepUpdate group.

I saw you wrote the BufferInterpolatedCharacterControllerMotionSystem that override the interpolation buffer. Unless your physics entity is kinematic and interpolated (and it is not because it is configure to be static) that would do nothing.

The best approach for this controller though is to setup the character to be kinematic, run the system using predicted physics (so both client and server run the physics update in the prediction loop) and move the character not inside the CharacterController but just calculating the velocity and moving it via PhysicsVelocity (that already handle all the impulses and collision etc).

With current public NetCode 0.51 you can do that but requires some changes in the controller (some places) and also forcing the kinematic flag to be always true (because it is reset as part of the physics prediction loop to true for simulated ghosts entities).

We will have a character controller example (for the next big release) that uses that exact same controller (modified as necessary), that showcase how to do it.

1 Like

Do u mean character controller example specifically for dots netcode that is modified from character controller example from dots physics sample?

One more question I would like to ask. If I understand correctly, character controller example from dots physics sample is not raycast based character controller. Is that higher performance to change to use raycast based character controller?

The one in physics sample is the one that is actually used by this demo (pretty much). And it is ray/shape-cast based.

We are still thinking which controller to use honestly, so plans may change.

ill try to give it a second shot and see if it fixes it.
Thanks !