4 ms·

I’m saying a car is easier to predict because of dead reckoning. With less frequent updates your actions still feel fluid because the cars momentum can’t change

I’m saying a car is easier to predict because of dead reckoning. With less frequent updates your actions still feel fluid because the cars momentum can’t change a whole lot between updates. Say you’re driving a car in a straight line, there’s very good odds that in .25 seconds you’ll still be going straight so your predicted line will be very close to the real line. With players you can’t guarantee that, they could zig zag, turn around, jump, etc much more likely to change and require prediction reconciliation.

meheleventyone 5y ago
Cars and vehicles in general are actually much harder because player simulation is much simpler, usually not happening in some middleware physics engine and is much more bounded in terms of the accelerations and speeds involved. Straightforward extrapolation as with dead reckoning does poorly with both cases. Then once you’ve mastered the art of getting cars not looking wonky you have to deal with collisions between them when they’re moving at speeds where typical gameplay latencies make it easy for discrepancies between clients to cause mispredictions which result in complete misses or large interpenetrations that physics engines have a bad time with.
- jbluepolarbear 5y ago
  Collision between 2 vehicles is a nightmare to make look good. But I haven’t had issues with extrapolating vehicles, it’s generally much easier to predict and reconcile than players.
  - meheleventyone 5y ago
    The problem with extrapolation is that you’re always predicting into the future so any state change you don’t predict causes a reconciliation which ends up looking bad. So even if you send the full physics state regularly any non-determinism in the physics engine (hello PhysX), any change in the control state and so on results in misprediction and reconciliation. This always ends up looking wrong, particularly for rigidbody driven things and in particular when mispredictions errors are large like fast moving vehicles.
    - jbluepolarbear 5y ago
      Disagree on this, if you’re getting constant updates and you smooth to the real position from the predicted position while continuing to predict you’ll have a very smooth non jittery movement. Determinism isn’t even required because you’re getting authoritative states from the server. This overview of Call of Duty explains why what you say isn’t the case. https://youtu.be/tCpYV4k_izE https://youtu.be/tCpYV4k_izE
      - meheleventyone 5y ago
        Interpolating between the extrapolated position and the position sent by the server will still cause ugly discontinuities and they will get worse as the user in questions connection gets worse. In particular it helps with linear motion but angular motion if anything ends up feeling weirder. This is much more visible with fast vehicles where discontinuities ruin the feeling that they have weight than with players. That CoD video explains what you do instead with the client buffering segment. You show other clients in the past even from the point of view of the latest data you received so you can interpolate so get no discontinuities at the expense of a slightly wrong view of the universe. Your client is one round trip ahead and the other clients are one round trip plus whatever delay behind. Which is where things like peekers advantage come from. Similarly they state exactly what I’ve said that extrapolation ends up making the game unplayable and again a input buffer on the server is the solution. The concern there is how much you buffer as it impacts latency quite heavily. So their system is dynamic based on the quality of the client connection. Note also in this case that extrapolation is only done in the server which is not responsible for the visual result and is done based on client input data which is usually sent at a much higher rate than the server sends state about other players back. Consequently the visual discontinuities will be hidden by the interpolation on the clients and will be small as mispredictions are expected to be caught quickly and the players are relatively speaking slow moving. It’s interesting they still need to stop extrapolating and fall back on buffering in the worst case. The reason determinism is needed is that the client is only sending their input so in order to work out where they are from only that information it must play back deterministically on both client and server. The same series of inputs must result in the same movement otherwise they’d end up in different positions. It’s also very useful because you can then rollback and replay movement if a missed input frame arrives. Rather than demonstrating your point it refutes it pretty handily and is a pretty good lay explanation of the considerations when writing networked gameplay systems. Believe it or not this has been my bread and butter for the past sixteen years!
Jasper_ 5y ago
> Say you’re driving a car in a straight line Pretty much every real game map is going to have hills or elevation changes. You're really never driving in a straight line.
- jbluepolarbear 5y ago
  It was an example, even in uneven terrain the concept stands. Momentum is continued along a deterministic path.

meheleventyone 5y ago

Cars and vehicles in general are actually much harder because player simulation is much simpler, usually not happening in some middleware physics engine and is much more bounded in terms of the accelerations and speeds involved. Straightforward extrapolation as with dead reckoning does poorly with both cases. Then once you’ve mastered the art of getting cars not looking wonky you have to deal with collisions between them when they’re moving at speeds where typical gameplay latencies make it easy for discrepancies between clients to cause mispredictions which result in complete misses or large interpenetrations that physics engines have a bad time with.

jbluepolarbear 5y ago
Collision between 2 vehicles is a nightmare to make look good. But I haven’t had issues with extrapolating vehicles, it’s generally much easier to predict and reconcile than players.
- meheleventyone 5y ago
  The problem with extrapolation is that you’re always predicting into the future so any state change you don’t predict causes a reconciliation which ends up looking bad. So even if you send the full physics state regularly any non-determinism in the physics engine (hello PhysX), any change in the control state and so on results in misprediction and reconciliation. This always ends up looking wrong, particularly for rigidbody driven things and in particular when mispredictions errors are large like fast moving vehicles.
  - jbluepolarbear 5y ago
    Disagree on this, if you’re getting constant updates and you smooth to the real position from the predicted position while continuing to predict you’ll have a very smooth non jittery movement. Determinism isn’t even required because you’re getting authoritative states from the server. This overview of Call of Duty explains why what you say isn’t the case. https://youtu.be/tCpYV4k_izE https://youtu.be/tCpYV4k_izE
    - meheleventyone 5y ago
      Interpolating between the extrapolated position and the position sent by the server will still cause ugly discontinuities and they will get worse as the user in questions connection gets worse. In particular it helps with linear motion but angular motion if anything ends up feeling weirder. This is much more visible with fast vehicles where discontinuities ruin the feeling that they have weight than with players. That CoD video explains what you do instead with the client buffering segment. You show other clients in the past even from the point of view of the latest data you received so you can interpolate so get no discontinuities at the expense of a slightly wrong view of the universe. Your client is one round trip ahead and the other clients are one round trip plus whatever delay behind. Which is where things like peekers advantage come from. Similarly they state exactly what I’ve said that extrapolation ends up making the game unplayable and again a input buffer on the server is the solution. The concern there is how much you buffer as it impacts latency quite heavily. So their system is dynamic based on the quality of the client connection. Note also in this case that extrapolation is only done in the server which is not responsible for the visual result and is done based on client input data which is usually sent at a much higher rate than the server sends state about other players back. Consequently the visual discontinuities will be hidden by the interpolation on the clients and will be small as mispredictions are expected to be caught quickly and the players are relatively speaking slow moving. It’s interesting they still need to stop extrapolating and fall back on buffering in the worst case. The reason determinism is needed is that the client is only sending their input so in order to work out where they are from only that information it must play back deterministically on both client and server. The same series of inputs must result in the same movement otherwise they’d end up in different positions. It’s also very useful because you can then rollback and replay movement if a missed input frame arrives. Rather than demonstrating your point it refutes it pretty handily and is a pretty good lay explanation of the considerations when writing networked gameplay systems. Believe it or not this has been my bread and butter for the past sixteen years!

Jasper_ 5y ago

> Say you’re driving a car in a straight line Pretty much every real game map is going to have hills or elevation changes. You're really never driving in a straight line.

jbluepolarbear 5y ago
It was an example, even in uneven terrain the concept stands. Momentum is continued along a deterministic path.