Page 1 of 1

Prediction and Physics

Posted: Fri Oct 19, 2018 8:09 am
by PhilipArthurMoore
Hello
i am doing a multi player game.
Client use client prediction to move player.
Client will send a message( contains: pressed time T, sequence number N ) to server after every frame if player keep input( example: right key )
Server will move entity by equation: entity.Position += pressed time T * velocity, but i check if velocity.X > 3 m/s, entity on server can move through other entity( example: wall )

Code: Select all


player = new Box(new Vector3(-7, 1, 1), 1, 2, 1, 1);
Space.Add(player);

wall = new Box(new Vector3(0, 0f, 0), 5f, 5, 5, 0);
Space.Add(wall);

public override void Update(float dt)
{
 	player.Position += new Vector3(3, 0, 0) * dt;
 	base.Update(dt);        
}      

can anyone give me some idea to solve the problem?
Thanks

Re: Prediction and Physics

Posted: Fri Oct 19, 2018 9:33 pm
by Norbo
Setting the Position or Orientation properties of an entity is a form of teleportation. There is no velocity associated with the movement, so collision detection and contact constraints can't stop it. At best, penetration recovery will gradually correct the error, but this will be very squishy compared to proper velocity based collisions.

Typically, clientside prediction doesn't involve integrating unvalidated client input. Instead, the server is fully authoritative and never performs any kind of 'correction'. Instead, the clients locally simulate forward based on current user input. If the server sends the client information that interferes with the client's prediction, it's up to the client to rewind and resimulate from the point of interference. Note that this isn't cheap for a fully physical simulation.

Re: Prediction and Physics

Posted: Sat Oct 20, 2018 1:41 am
by PhilipArthurMoore
thanks Norbo,
so what will is kind of "correction"? if it is client, so cheater can move player through wall and server can't correct that move because server use bepu physic to check collsion and prevent entity move through wall.
in this case server is difficult to use move player by using velocity ( it is good to bepu check collsion ) because server dont know time client move player.
So server use equation: entity.Position += pressed time input ( which client send to server ) * velocity

Re: Prediction and Physics

Posted: Sat Oct 20, 2018 10:11 pm
by Norbo
Sorry, I'm having trouble understanding the details of the question.

If you are asking about how this form of clientside prediction works, it typically involves:
1) The client sends a steady stream of input packets to the server at a high rate.
2) The client predicts the result of those inputs while waiting for the server's response. The prediction is strictly for the sake of clientside responsiveness and have no impact on the 'true' state of the simulation. The true state is defined entirely by the server.
3) The server takes into account the stream of inputs while updating its simulation. The serverside simulation never directly adjusts object positions according to user input- instead, it simulates every frame of gameplay logic so there are no discontinuities. The server then sends out authoritative state updates based on the result of the simulation to all clients.
4) When a state update from the server arrives on the client, the client adjusts its view of the world to match. Since the message from the server represents a simulation state that appears to be in the past from the perspective of the client (due to the client's prediction), the client must resimulate from the server-provided authoritative state to a new predicted state again.

This isn't the only way to do things, of course. This particular approach avoids a wide class of cheats and maintains reasonably good clientside responsiveness, but costs a significant amount of computation on the client during corrections. For physically difficult simulations, it can become too expensive.

If you haven't already read them, I'd recommend scanning through all of the relevant gafferongames articles.

Re: Prediction and Physics

Posted: Sun Oct 21, 2018 2:22 am
by PhilipArthurMoore
thanks Norbo,
i understand client-side prediction model.
So if frame rate is 60 fps on client, frame rate is 10 fps on server
if client move entity to right 1/60 second, how to server excute move Entity to right 1/60 second?
it is reason server use equation: entity.Position += 1/60 second * speed, and this will be difficult to detect collision with other entity.

Re: Prediction and Physics

Posted: Sun Oct 21, 2018 9:13 pm
by Norbo
One option would be to combine the six substep inputs into a single representative update. This is approximate, but it'll be better than just teleporting things.

Updating the physics at a higher rate would also be much more reliable. In fact, it's unlikely that a 10hz update rate will produce usable results for any nontrivial simulation. 30hz is about the lower bound in most cases, and 50+ is preferred. Some very sensitive simulations may require 120hz or higher.

Notably, updating the physics at a certain rate does not imply that all logic must run at the same rate. For example, in each 10hz gameplay tick you could take 6 substeps of 1/60f duration each.

Re: Prediction and Physics

Posted: Mon Oct 22, 2018 1:09 pm
by PhilipArthurMoore
so if my client have not a fixed fps( because time step at Unity is not fixed, it is based process on Update function ), can i use Space.Update() for both server and client?
Example:

Client

Code: Select all

long number = 10;
while(true)
{
	Space.Update();
	Thread.sleep(number );// if it is Unity, number is not fixed
}
Server

Code: Select all

while(true)
{
	Space.Update();
	Thread.sleep(33);// number "33" can be fixed, 
}

Re: Prediction and Physics

Posted: Mon Oct 22, 2018 8:59 pm
by Norbo
You can use Space.Update on both, yes; just be careful about the amount of integrated time. Each parameterless Space.Update call performs a time step equal to Space.TimeStepSettings.TimeStepDuration, so you'll need to take a number of time steps equal to the accumulated time divided by the time step duration. Note that the TimeStepDuration can be changed, but doing so every frame can lead to instability.

Further, be careful about using Thread.Sleep. Not only is the resolution very poor due to the default OS timeslicing duration, simply sleeping by the target time between updates ignores the time taken by the actual update process.

Edit:
I'd also recommend the gafferongames article on fixed timestepping: https://gafferongames.com/post/fix_your_timestep/

Re: Prediction and Physics

Posted: Tue Oct 23, 2018 4:55 am
by PhilipArthurMoore
thanks Norbo,
Thread.sleep is which i only demo about loop in game.
When i use Space.Update() with same time setting at client and server, i dont care about frame rate more.
Client run 1 frame with 10 fps, so it simulate same with server run 1 frame with 33 fps.
So move of entity can be synchronized at both client and server