Why do most games limit themselves with a tick rate in their networking? Isn't it better to make something like an even system where for example client A does something then the client sends related info to the server, and same for the server when something happens on it it sends a packet to the client, instead of using a tick rate and sending information only at some specific frequency. Is it cheaper/faster to send more data in a single packet or? And the same question goes for server tick rates, some servers limit themselves on specific tick rate frequencies, why do they do that? Why not just make a loop and run each tick after each other instead of having a gap between them or risking one tick to take longer than it should and causing bugs? What's the benefit of the tick rate approach for servers and for networking?
1 Answer
It's largely a matter of, what's the default assumption for a given segment of time in your game? Is it more likely that...
- absolutely nothing happens
- something happens
If it's more common that something happens than nothing, a regular server tick is a good way to go. For instance, in a multiplayer shooter game, players can change direction and fire off shots in fractions of a second, so there's stuff happening constantly. It makes sense to send regular, frequent updates to keep everyone appraised of the evolving situation, without excess overhead of trying to sleep through or skip timesteps in which nothing happens, since that's rarely if ever the case.
If it's more likely that nothing happens than something, then an event-based system is a good way to go. Many games with asynchronous multiplayer work this way, where the game state is only updated when one player logs in and takes their turn / actions, then sits idle until the next player needs to act. It might be minutes or hours, even days before the next event that affects a given player occurs, so doing a sub-second tick update throughout that span would be wasteful.
So, it all depends on what kind of game you're making, and what needs your server has to fulfill.
With regard to ensuring a regular tick frequency, for games that use it, I recommend checking out this earlier answer.
-
\$\begingroup\$ So basically in the games where something happens more often than nothing it would be better for performance to sometimes send empty packets than to sleep through that time? And the time between actions is very small so it woulnd't be effective to sleep through it? That makes sense. But what about server ticks, not the network but the loop in which server processes information, I've seen some servers and they limit their ticks. I guess it's to save on the server cpu. Because it would be running on 100% if there is no sleep. \$\endgroup\$– Warix3Aug 17, 2018 at 3:05
-
\$\begingroup\$ There's that aspect, and there's also consistency and fairness. You want the game to play the same way, always, under all load conditions, right? It shouldn't play one way under light load and a different way under heavy load. So setting the tick frequency to a fixed constant helps you ensure it stays the same across a wide range of loads. \$\endgroup\$– DMGregory ♦Aug 17, 2018 at 3:06