I am using this repo as my base. I made some changes (e.g. removed position from command and not resending already send inputs), but principle is the same.
Everything important is in this file.
Also i decreased fixedTimeStep to 0.02f and set networkSendRate to 0.04-6f (i’m not decided yet).
Inputs send to server are capped by sbyte (see CharacterInput), so there is no need to validate them.
inputHorizontal = (sbyte)(value * 127);
Here are my problems:
If client increases input send rate he will move faster than he should.
If client decreases input rate (or packets get delayed) player can get stuck in air while gravity should drag him down.
So my first idea was to queue inputs from client and execute them in FixedUpdate function.
Also when no inputs are in queue server would execute empty input for gravity/environment.
As you can guess queue start growing fast and inputs from client were not processed because of delayed inputs (network simulator).
Also i got ideas about player’s system time etc., but that feels gimmicky and unreliable.
How to properly validate client inputs on authoritative server without losing prediction? Thanks
Well, i see two main issues here. First this does not really represent the actual Q3 network implementation. It’s true that input is send out in packets and the server has to take all the input into account. However it makes no sense to drive the actual movement by each packet. An input packet should just update the input state on the server. The server movement simulation would run independently.
This implementation you’ve linked is not authoritative as the client actually dictates his movement. This actually has little to do with Q3. In Q3 you don’t simulate anything on the client. You don’t move on the client and you don’t do any movement collision detection on the client. Q3 works with complete snapshots of the world state which includes the position of all “movable/changable things” in your surrounding. That includes the position of all players in view, even your own. You actually do not run on your PC, You just send you desired velocity to the server and the actual movement is done on the server. The clients just receive snapshots of the server state and then interpolate between the last two snapshots. So in general the simulation on the client simulation “lags behind”. However since all commands get a timestamp the server can backtrace any actions that were raised in the past.
If a player has a slow connection it’s possible that he hit and kill another player right before he goes around a corner. Due to the delay it might “feel” like the hit player was hit through the wall because he might die a few ms later. But the simulation is done on the server and the shot command might just have been late. It’s never the less a legit hit since every player sees snapshots from the server.
The actual code to make that work properly is quite complicated.
ps: I once was connected to a Q3 server with a ping of 2 sec! If i press forward it takes 2 sec until i start running. So there’s no clientside prediction. Q3 does extrapolation if the stream of snapshots is late / has dropped packets but only for a matter of some ms (100ms i think). If it takes longer you’re actually “stuck” at the last extrapolated position. This also happens when you’re connetion is interrupted.
As additional warning: He said it’s
q revisited implementation of Quake 3
networking principe
This can cause trouble because the Q3 source is published under the GPL. If he really only reimplemented the “principle” without actually looking at the source it should be ok. However it’s always a rist using things that might come from GPL code.
So i ended up queuing inputs on server and playing them in 0.02f interval.
When input queue is empty last input is replayed as “prediction”, also i don’t increment inputState so delayed inputs can be used. It’s not perfect, but good enough to worry about other stuff.