2
\$\begingroup\$

I am working on a authoritative client/server game, looking to both Valve and Gaffer to understand the concept.

Currently, the server simulates at 20 ticks a second. The inputs received from the client is buffered and only processed during one of these ticks. However, if a client sends input at a faster rate, say 60 times a second, that client will move about 3x faster than regular clients.

A solution to this would be to have the server combine/unify the inputs in the buffer and process this input once, instead of processing the buffered inputs individually.

Now, given the latter solution, a client with a send rate of 20 could be subject to network jitter, which could cause the server to receive 2 or more inputs at the same time. This would cause the server to combine/unify the inputs, when they should actually be processed individually.

So my question is, how should the server handle inputs to prevent more inputs from being processed than necessary, while not skipping inputs that arrive at the same time?

I hope I make sense, if not just tell me to elaborate :)

\$\endgroup\$
4
  • \$\begingroup\$ If the client sends inputs at a faster rate then it is a hacked or broken client, isn't it? \$\endgroup\$
    – user253751
    Nov 5, 2016 at 4:49
  • \$\begingroup\$ Yes it could be and I want to make sure that doesn't effect the simulation. \$\endgroup\$
    – Jpst
    Nov 5, 2016 at 5:12
  • \$\begingroup\$ If someone is using a hacked or broken client then the most obvious solution is "kick them off the server". \$\endgroup\$
    – user253751
    Nov 5, 2016 at 6:14
  • \$\begingroup\$ The first priority should be to prevent the client from breaking the simulation. Otherwise, consider the case where each client is allowed to send inputs at different rates. \$\endgroup\$
    – Jpst
    Nov 5, 2016 at 6:19

2 Answers 2

2
\$\begingroup\$

A simple solution i found, is to keep track of how many server ticks have gone without processing input from the client. This amount is then decremented for each subsequently processed input.

This allows for multiple inputs to be processed at each server-tick, but no more than the tick-rate.

Im still open for other ideas, but for now, this is what i'll stick with.

\$\endgroup\$
0
\$\begingroup\$

I'm not sure why so many people seem to have so much trouble with this. The server simulates 20 ticks per second. End of story.

Clients are expected to roughly send inputs at about that rate, probably slower (since you do not normally generate 20 events every second). But, whatever... the server still simulates 20 ticks.

That means none more and none less than if your client sends 60 inputs per second (or 240 inputs?), they will queue up and when the server processes its next tick, it will ignore all but the last commands received (you can as well only process the first few received, but it usually is more desirable to ignore old commands rather than new ones).

The server will process exactly the number of commands per tick per client that you allow. Not one more.

If a client continuously sends high volumes of updates, not just as a matter of a short burst (this may actually happen sporadically), the server may simply disconnect the client and flag the user as possible cheater...

\$\endgroup\$
1
  • \$\begingroup\$ This doesn't work for games where inputSampleRate (i.e. FPS usually) > tickRate when there are non-continuous actions in the input (e.g. a fire weapon command). If you discard old inputs and only look at the newest one, the weapon may not fire. You need to be smarter about combining the inputs, or process them all in a way that doesn't allow over-utilizing the clock space (e.g. Valve sends "msec" w/ user commands for how long button was held in frame time, you can use this to accurately recreate input server-side and also to ensure that sum of msecs of all commands does not exceed tickRate). \$\endgroup\$
    – Dan
    Jun 5, 2022 at 19:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .