0
\$\begingroup\$

As I understand for a client server model, it's common practise to send input to the server and then the server applies the input to update the state of the game. The server then sends updates to clients regularly. The client in the meantime does prediction, before it receives the "true" state.

My question is how often to send input. Surely it should be sent every frame otherwise some input (during frames which are not sent) will not be processed by the server. Will this be too heavy for the network. What is common practise?

\$\endgroup\$
3
  • \$\begingroup\$ The common practice is that you try it in the best way that works for your game, and if it doesn't work, you fix it from there. \$\endgroup\$
    – Panda Pajama
    Commented Apr 28, 2013 at 13:58
  • \$\begingroup\$ What kind of game? This wil vary if you're doing a twitch action game vs a lockstep simulation game, for instance. For more action-y games, a good first read is gafferongames.com/networking-for-game-programmers \$\endgroup\$
    – Sean Middleditch
    Commented Apr 28, 2013 at 23:35
  • \$\begingroup\$ I have read that article. As for the game... I've just even experimenting.... But I was thinking more along the lines of fast paced action game \$\endgroup\$
    – user1107837
    Commented Apr 29, 2013 at 9:41

1 Answer 1

Reset to default
2
\$\begingroup\$

Sending data to the server can usually happen at a higher rate to data coming from the server.

That's because the main bandwidth restriction is usually on the server's outgoing connection to all the clients, and also because the client generally needs to send much less data that it receives.

However, this will vary based on what sort of game it is, and how the networking code is implemented.

If it doesn't get sent every frame, the client should accumulate all the data in a buffer and send it in a batch at whatever rate is appropriate. The main advantage of batching it up is to avoid the overhead from the UDP packet headers (~32 bytes each IIRC).

Also note that on most frames nothing will have changed for the client, so there's probably no need to send any data in that case.

\$\endgroup\$
2
  • \$\begingroup\$ Thanks. Very helpful. I did considers batching it up. I didn't consider the possibility of sending when nothing changed. Would it be a good idea to send input as it happens. Like when the user pressed/released a button \$\endgroup\$
    – user1107837
    Commented Apr 28, 2013 at 15:20
  • \$\begingroup\$ That is one option, but as I said it depends on the game. An RTS will probably implement things very differently to an FPS for example. \$\endgroup\$
    – Adam
    Commented Apr 28, 2013 at 22:58

You must log in to answer this question.

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