Sending a players mouse movement to the server in an FPS

Question

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.

Answer 1

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.

Answer 2

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

EDIT

Have a look at QuakeWorld and Quake3Arena source code

Answer 3

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.