Client prediction

which approach I should take to make the remote client responds faster.
The case is I have a player object that is throwing an explosion to another client, on the local screen, the impulsion effect of the remote client is delayed, meanwhile on the remote client’s screen, it’s pretty much seems normal.

This is what happened currently in my script:

I have a I learned that I can use a simulator cloud to sync every client, and also one Coherence’s advice me to use client prediction without simulator (or client authoritative setup).

But I couldn’t quite find how to exactly do that client prediction with client authoritative setup. I mean, which variable I should enable client prediction on coherence config? I am interested to use this approach.

Thank you for your help!

Hi, thanks for taking the time to make a thread and add a video. A quick question before we dig in - is this using coherence Cloud or is it using a local replication server?

A coworker pointed out that it doesn’t appear that you’re running a local RS from your taskbar, so assuming you’re doing this over coherence Cloud, the “lag” you’re seeing from one client to another is expected and yes, client prediction or server simulation is one possible solution if you want to alleviate it.

My recommendation in terms of complexity is to do some simple client prediction:

  • You are already displaying the arc the bomb is going to throw in, meaning you have some sort of prediction of it’s path
  • At the moment of release, determine where and what it’s going to collide with and send this information to all clients, including a universal timestamp of when things will happen
  • All clients then perform the necessary explosions/effects

You can use the “prediction” toggle in coherence on the position of the players. You will need to write some code to reconcile the prediction and the actual data coming in, and you will need to play with the frequency of reconciliation to make sure things aren’t jittery. See Server-authoritative setup | Unity Multiplayer SDK Documentation | coherence

I will conclude with, although you are seeing both clients on the same machine and it’s very obvious, the amount of lag I’m seeing in the video may be playable between two players across the internet without an issue.

Oh, an important note about the above solution is that all of simulation should be happening on a single client - e.g. one client has authority over the objects and the other clients are predicting input and reconciling

Hi, we are currently using coherence cloud!

1 Like

does this means I could choose the rigidbody of the player object into “leave as is” or dynamic? So the local client could simulate the impulse of remote clients from the explosion locally then the remote client is reconciling?
or am I wrong. I still couldn’t quite understand about the simulating the remote client’s impulsion in local

Taking a step back from the thread happening in Discord - let’s start with your initial post.

Perhaps the delay seen when the impluse happens is due to interpolation.

Impulse generates instant force and motion, but our default interpolation will attempt to smooth out any instant movements.

Can you please try out different interpolation methods to see if anything gets you want you want?

Here are our docs on interpolation:

Actually i tried to set the interpolation to none, and it gets bit better in terms of latency. I could balance it out, but I still wonder about this sentence you have talked in discord

the remote client moving due to explosion should be a result of position sync. the explosion and how much they move should happen on the client with state authority.

so this means that sending command to other client to move (as the result from explosion impact) is bad, so how to move the other client by explosion in the most effective way? I have this script to move any entities with rigidbody, the explosion and animations are fine, but the movement of other client is delayed just like the first video, and this time there is no command at all.

also does this mean that the local client has to take the remote player’s authority for the movement caused by impulsion?

Ah, my reply there was assuming you were using a client prediction host/server setup, and I realized that wasn’t necessarily the case based on your initial video.

But, ultimately if interpolation settings are not getting you to where you like, then I think yes you can move towards server simulation as you mentioned in Discord.

I would follow the guide from the beginning for the Server-authoritative setup: https://docs.coherence.io/manual/authority/server-authoritative-setup

And see where that gets you.

In this setup, yes: one server or host has full input authority over all players, and rigid bodies and physics should be disabled for them on other clients. You can then use local client prediction and reconcile that with what you get from the server. You can continue to use commands as a prediction element to impulse players and reconcile that with the server’s data.

Thank you for the suggestion, we’ll implement the simulator.

Hey GhazyAzhar. I just want to add something that I happened to notice in the first code you posted. This is in addition to the suggestions Brit made, just something to help you understand more how to code these behaviours.

The “issue” I noticed is that in that code, you send a command to MessageTarget.All to activate the gameplay effect of detonating the bomb.
This is not wrong in itself, but… you also do a couple of things in there that only the authority should do.

Like for instance, calling Destroy on the object. You probably got some error message from coherence for that, because only the authority of the bomb should be destroying a network entity. By doing so, the entity will be automatically destroyed (by coherence) on all other connected clients.

The other thing you do is call ApplyExplosion() which in turn does a search for colliders, and applies a force. You can imagine that on every computer where the bomb explodes, all remote players will be (or, should be) kinematic rigidbodies. So when the bomb finds them and applies a force, nothing happens.

While the first produces an error in the console, the second is a harmless problem (just a bit of performance lost). However, I thought it could be useful to point these things out so you can understand better how to structure things for networking.

There is no 1 right way to structure these things, but it’s good to always keep in mind who’s the authority for an object and separate behaviour that the authority should run (like destruction, movement, etc), from the one the others should run (like particles, visuals, etc.)

On these topics, you could take a look at the pages I wrote for our Campfire demo.

They don’t cover your case exactly, but they can be inspiration.