[Dev Blog] Server Tick Rates

In a previous post I wrote about the naive authoritative server solution I implemented for my fledgling multiplayer game. I have the server set up so that all incoming commands (requests, really) from the client are processed and responded to in real-time. While this method works for the small number of simultaneously connected clients I can test at any given time, it doesn’t scale well for larger numbers of clients. For instance, during player movement the client sends commands repeatedly while the arrow keys are held down. With a handful of connected clients the server can easily respond to every client as their commands are accepted, but as the number of clients increases, the amount of data being sent back and forth can completely saturate the connection. The solution is to limit the rate at which the server responds to commands.

Most servers of multiplayer games have what is called a tick rate – the rate at which a server sends updates to a connected client. The faster the tick rate, the more updates a client receives and as a result the client’s representation of the game state is closer to the state on the server. The type of game you’re making generally dictates the tick rate. Fast-paced action games that require fast reflexes and precision like first person shooters will require a higher tick rate so the client can react faster to changes in state. Slower-paced games like role playing games can get away with a lower tick rate, especially if combat is turn-based. For my game, since I’m using Node.js, I can implement the tick rate using the setInterval method. It will likely look something like:

In addition to updating clients, the server will have a separate rate for simulating the game world. Generally the game world will be simulated and updated at a faster rate than client updates. If I’m trying to target a frame rate of 60fps, the server has to complete its processing per update call in roughly 16 milliseconds (16 milliseconds per frame means 16 * 60 = 960 milliseconds to process 60 frames). For the simulation update I’ll have a similar set up as above but with an interval of 16.

Leave a Reply

Your email address will not be published. Required fields are marked *