Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualhplus0603

Posted 15 December 2012 - 07:02 PM

There are a few ways to do that.

First, change simulation engine :-)

If you can't do that, then try not simulating the client ahead, but instead waiting for the server round-trip. You may be able to allow the camera to swivel freely with the mouse, but hide movement behind acceleration latency.

If you can't do that, then, when you receive a correction in position/velocity, apply a delta position/velocity to your physics engine on the same step if the correction is small. Specifically, when you get a correction for "pos=10" when you had "pos=11" then apply an impulse to move the player backwards by 1 unit, rather than moving to the particular position.
If the correction is big, then snap the player and stop the client from giving commands until you've received a server snapshot that matches the client snapshot again. This means that big corrections suck for the player, but... big corrections suck! :-)

Even better behavior may be had by applying a correction based on the extrapolated position. Let's say you get "S=7, X=10, V=1.5" and now "C=12," then you can compare the players position now (say, X=20) to the extrapolated position for now (which is (12-7) * V + X, or 17.5) and apply a delta of (20 - 17.5).

#3hplus0603

Posted 15 December 2012 - 06:51 PM

There are a few ways to do that.

First, change simulation engine :-)

If you can't do that, then try not simulating the client ahead, but instead waiting for the server round-trip. You may be able to allow the camera to swivel freely with the mouse, but hide movement behind acceleration latency.

If you can't do that, then, when you receive a correction in position/velocity, apply a delta position/velocity to your physics engine on the same step if the correction is small. Specifically, when you get a correction for "pos=10" when you had "pos=11" then apply an impulse to move the player backwards by 1 unit, rather than moving to the particular position.
If the correction is big, then snap the player and stop the client from giving commands until you've received a server snapshot that matches the client snapshot again. This means that big corrections suck for the player, but... big corrections suck! :-)

Even better behavior may be had by applying a correction based on the extrapolated position. Let's say you get "S=7, X=10, V=1.5" and now "C=12," then you can compare the players position now (say, X=20) to the extrapolated position for now (which is (12-7) * V + X, or 17.5) and apply a delta of (20 - 17.5).

#2hplus0603

Posted 15 December 2012 - 06:51 PM

There are a few ways to do that.

First, change simulation engine :-)

If you can't do that, then try not simulating the client ahead, but instead waiting for the server round-trip. You may be able to allow the camera to swivel freely with the mouse, but hide movement behind acceleration latency.

If you can't do that, then, when you receive a correction in position/velocity, apply a delta position/velocity to your physics engine on the same step if the correction is small. Specifically, when you get a correction for "pos=10" when you had "pos=11" then apply an impulse to move the player backwards by 1 unit, rather than moving to the particular position.
If the correction is big, then snap the player and stop the client from giving commands until you've received a server snapshot that matches the client snapshot again. This means that big corrections suck for the player, but... big corrections suck! :-)

Even better behavior may be had by applying a correction based on the extrapolated position. Let's say you get "S=7, X=10, V=1.5" and now "C=12," then you can compare the players position now (say, X=20) to the extrapolated position for now (which is (12-7) * V + X, or 17.5) and apply a delta of (20 - 17.5).

#1hplus0603

Posted 15 December 2012 - 06:48 PM

There are a few ways to do that.

First, change simulation engine :-)

If you can't do that, then try not simulating the client ahead, but instead waiting for the server round-trip. You may be able to allow the camera to swivel freely with the mouse, but hide movement behind acceleration latency.

If you can't do that, then, when you receive a correction in position/velocity, apply a delta position/velocity to your physics engine on the same step if the correction is small.
If the correction is big, then snap the player and stop the client from giving commands until you've received a server snapshot that matches the client snapshot again. This means that big corrections suck for the player, but... big corrections suck! :-)

PARTNERS