So I have a server-client model FPS set up. It uses udp to send data between the two with the server having a constant tick rate of 100 ticks per second (It updates movement 100 times a second) on the server with the client doing update of its key states etc 30 times a second and for keys the system works well. But now my question is how would I send the mouse movement to the server as this in not an on/off system is is constantly changing.

So my question is how do you send the movement of the mouse to the server. Do you send the direction and speed that the mouse is moving each update and interpolate it or something else. The problem I can see with interpolating something like a mouse is that in an FPS it is required to be very accurate and interpolating is literally guessing. Any advice would be appreciated.

The other problem that I see is that to get a direction vector of a mouse you would have to wait for enough movement to get the vector.

Another idea has come to me and that is just sending the direction that the client thinks its looking when it shoots.

Any advice would be much appreciated.

  • \$\begingroup\$ lag on internet can be anywhere between 10ms (very rare!) 50ms (good!) and up to 150ms (or more)... so more than 6 updates per seconds works mostly only if your server is also on the player's pc... \$\endgroup\$ Sep 21, 2016 at 22:19

3 Answers 3


Translate mouse input to rotation on the client-side. Then send the new view direction to the server, not raw mouse input.

  1. Usually there is more than one way to change the players view direction (keybindings, for example). When you just handle direction updates you don't have to handle this as a separate case on the server (not a particularly important reason, but a reason nevertheless).
  2. Mouse position updates are changes, not absolute values. That means a single lost packet causes the view-direction on client and server to become asynchronous. You said you are using UDP, so you always need to keep the possibility of lost or out-of-order packets in mind.
  3. ...unless you enforce server authority on view direction. Then your players will get annoying input lag (when you have no prediction) or unexplained mouse jumps (when you have prediction).
  4. In most first-person games the player is allowed to turn as fast as their mouse allows. So there is no reason to handle this server-sided anyway.

When you are worried about too many direction updates using too much bandwidth, reduce the update rate in situations where it does not matter and increase it in situations where it does. When the player is just standing around, you only need very infrequent mouse updates because their view direction is mostly cosmetic for the other players. When the player is shooting, you want a mouse update on every tick so you can accurately represent their aiming.

  • \$\begingroup\$ please note that on a classic WASD + mouse look input mode, the mouse movement is not required by the server in order to simulate the game. Only WASD has to sent (and direction of any firing action of course, only when it happens) \$\endgroup\$ Nov 18, 2016 at 10:21
  • \$\begingroup\$ @GianlucaGhettini But then how would the other clients know in which direction another client is facing when that client is turning around, but neither moving or shooting? \$\endgroup\$
    – Philipp
    Nov 18, 2016 at 13:34
  • \$\begingroup\$ what I meant is that the mouselook is not required for advancing the game state so is not vital to have it acknowledged and or sent at a super fast rate. Prediction is not require on player mouselook. Player position and actions are vital and need to be sent as fast as possible and as reliable as possible \$\endgroup\$ Nov 18, 2016 at 13:37

First, mouse look doesn't require to be sent as the player direction is not affected. You need to send out your position (speed, momentum, whatever) and your actions (fire, duck whatever)

Quake does like this. Prediction could be useful but at an expense of some paradox to be resolved at client/server site


Have a look at QuakeWorld and Quake3Arena source code


Would you happen to be using a socket server? Or what kind of networking system Do you use? Having a stream of floats going over the network should not cause an issue, if you use a setting on that rpc like transmission set to "reliable" (if you have this kind of system) that can cause the packet buffer to overflow on the server and cause overhead. if this can handle some list packets you should be just fine using a system like this.

  • 2
    \$\begingroup\$ To ask for clarification or additional details, it's better to build up a bit of reputation first so you can post a comment. You should also brush up on the terminology, as some of the questions you ask are already answered in the post above - for instance, the asker specifically says they're using UDP, which is not "reliable" in the way that TCP is. \$\endgroup\$
    – DMGregory
    Apr 10, 2016 at 15:48

You must log in to answer this question.

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