Jump to content
  • Advertisement
Sign in to follow this  

Handling Client Input in the Authoritative Server Model

This topic is 2891 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts


I'm trying to develop a fast-paced multiplayer action game, and have reached some conceptual difficulties that I would like to discuss, regarding how the server handles input from client players. For my networking model, I am using the "dumb client/authoritative server" model, primarily focusing on the techniques discussed by the Valve Source multiplayer articles found on-line (and linked to in the forum FAQ). Note that I would like to be able to have players use "listen servers" to set up and host games (on the internet or locally) rather than using dedicated servers. At this time, my difficulties can be split into two general questions.

My previous experience has been with single-player games, in which the main game loop repeates over and over. Each loop, the game takes player input, performs "game physics" calculations (based on the world state, AI decisions, and player input), and then renders the graphics. I find that the physics calculations tend to comprise the bulk of the total computational work. Hence, doubling the number of "game physics" calculations can easily have the effect of cutting the frame rate in half.

To be clear, "game physics" tends to comprise mostly of collision detection sweep tests (for moving objects and projectiles) and line intersection tests (for instantaneous bullets). The details of my algorithms are beyond the scope of this post, but it's helpful to have a basic understanding of what happens: All objects figure out which other game objects may *potentially* collide with it during the next frame (usually using spatial partitioning, among other techniques), and sweep tests are performed. All objects are moved forward up to the time of the first collision, using their velocities. Then any of the objects involved in that first collision are re-tested (using sweep tests) with objects that they may still *potentially* collide with, as the previous collision may have altered velocities, necessitating new sweep tests. All of the objects are then moved forward to the time of the second collision, the necessary objects are re-tested for collisions, and so forth, until everything has had a chance to move forward up to the duration of the last frame.

Let's move on to multiplayer games specifically:

A) It's my understanding that input is handled in the following way:

1.) Client keyboard captures the most recent frame's input and sends it to the server.
2.) Server receives client input (which refers to a frame in the past now, due to latency).
3.) Server calculates how old the received client input is, and rewinds its view of the world by that amount of time. Using the newly received input (and any other input it had previously received), it performs "game physics" calculations up to the current server time (potentially many frames forward), to update the positions of all objects to the most accurate possible, based on what it knows of client inputs.

Now the problem is that, in any given frame, the server generally is going to have to run "game physics" for a length of time equal to several "frames-worth." If latency is consistent for each client, then the client with the largest latency will determine how long a duration of "game physics" will have to be simulated for, each frame.

The Valve article suggests using interpolation, with intervals of 50 ms, to keep things looking smooth on the client-side. This suggests a minimum frame rate of 20 FPS. If we can expect a round-trip latency of up to 300 ms, then client input will be received 150 ms after the fact. This means, each frame, when the server receives client input that is 150 ms old, it will have to rewind its view of the world back to the point it was at 3 frames ago, and then recalculate "game physics" up to the current server time. While we can limit such recalculations to tests between objects that might *potentially* collide with this player with newly-received input (and not repeat such tests for other players who could not possibly have interacted with them anyway), that's still a lot of recalculating. Especially when you have a ripple effect, when another player (who we have received input for) is affected by the new tests - this player must then recalculate all of HIS collisions up to the current server time as well (and any new collisions result in more players having to then recalculate, etc.).

What's worrisome to me is that it will then have to recalculate "game physics" for 3 frames' worth of action - and be done in the time that one of my single-player games would have used to calculate only 1 frame's worth of action. I fear a race condition here - that the server will spend so much time calculating collision tests, that it will not achieve an acceptable framerate.

How should I handle this situation? Is my understanding of the "authoritative server" algorithms incorrect? Or is it just understood that such servers are generally run on machines that are FAR more powerful than consumers' PCs, to avoid the above race condition, making the use of a listening server generally unfeasible?

B) How do I handle the case of a client whose frame rate is greater than the server's frame rate, when it comes to input? I think it's understood that a client shouldn't limit its frame rate to that of the server's. Instead, interpolation should be used to create a smoothly moving word on the client's screen, at as fast a frame rate as the client's machine allows.

But in this case, the client will be generating multiple frames' worth of inputs for each "frame" that's run on the server (50 ms, above). How will the server handle multiple inputs per-frame from multiple clients - each with potentially different lengths of time for which that input was valid (i.e., Player A held "down" for the first 15 ms, "down" for the second 15 ms, and "up" for the next 15 ms, while Player B held "down" for the first 25 ms and then "right" for the next 25 ms)? The more inputs it receives, the longer it will take to calculate "game physics," contributing to the race condition above.

Is it acceptable (or even widely practiced) to cap input-capturing on the client to the server's frame rate, while allowing the client to render at as fast a frame-rate as it can? So a client can be rendering at 60 FPS, but only testing the keyboard every 50 ms (at 20 FPS), since that's what the server is running? I guess I don't see why not, but I would welcome your opinions and thoughts.

Share this post

Link to post
Share on other sites
A) I don't think your idea of the server model is flawed. The server will have to run several iterations of the game-physics in the timespan of one physics frame. You should arrange for your physics to be simple enough to allow that to happen, but in FPS games it generally isn't an issue.
If you tried to implement a half-life style authoritive server-model in a realistic driving game with actual spring/damper simulation you would surely fail miserably due to the amount of calculations necessary to replay the physics-frames when old client input arrives. That's one of the reasons why driving games always look jerky and unrealistic in online-play.

B) Are you aware that the physics frame rate is decoupled from the graphics frame rate? Even if the client views the world at 200 fps the client will only send his input 25 times a second over the network.
Think of your game as a turn based game. In each turn each player must issue commands and there are 25 turns each second. Since waiting for everyone to submit his commands for each turn is boring in an action-heavy game (old games used to do this) the server progresses the game even when a few commands for the last few turns are still pending for some players, but it will account for them once they arrive. The clients are then allowed to interpolate between the turns to enhance the visual appearance of the game.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!