I’m pretty sure the car uses dead reckoning. So you position in the car is static (the last place you where), but the car is moving at speed and will continue even if you disconnect.
Sure, but I’m talking about the control you have over the car when in the car. During the start of this battle pass season there was immense server issues, which I guessed was the tick rate dropping to super low values due to some bad code. During a few games where the servers degraded in this way, moving would be extremely slow on the ground as it kept pushing you back (since the server isn’t processing your ‘move forward’ commands as often) but getting in a car gave back free movement since I assume it’s a direct broadcast that doesn’t hit the game loop and doesn’t have any position-correcting sanity checks running.
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.
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.
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.
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.
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.
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!
I mean it’s what I do professionally as well. I haven’t been doing it nearly 16 years, but have been at it near 10. What I was explaining with cars and vehicles is extrapolation on servers can be accurately done because of dead reckoning. The video explains why determinism in you physics isn’t necessary, but that your packets and inputs need to be. That’s the purpose of jitter buffers and input buffers on the server. Because the server has your last input, and you’re in a car, it can simulate the car in a predictable way.
