Most competitive games go well above 10Hz ticks, OW does it, CSGO does it (I don't really know the tick-rates of other games but when it matters, so no comment there, but there is an important area for it).

OW just has a restricted rate option for low bandwidth connections (added when they went from 23 -> 61 Hz).

So that might be the case for LAN games, generally internet tends to stay lower. Valve for instance recommends 13Hz[1] for Source(CSGO):

> // 60 for updaterate is LAN ONLY use 13 for internet

> // 20 is default but will cut the maxplayers you can handle in 1/2

> // for SRCDS Servers use 30 - you might be able to use 20

> // sv_maxupdaterate 60

> sv_maxupdaterate 13

Like I said, depending on how good your potential-vis code is you may be able to go higher but you risk saturating your client links and most game netcode doesn't handle congestion nicely. My info is a little out of date(2-3 years) but back then we had to keep data rates below 20kb/sec(and ideally 10kb/sec) if you wanted low jitter across the link.

[1] https://support.steampowered.com/kb_article.php?ref=5386-HMJ...

This information is very much outdated. (Windows XP is referenced in it)

CSGO matchmaking servers (run at 64 ticks) force you to use cl_updaterate 64.

Even in CS 1.6 days, most leagues and servers enforced updaterate 100 and rate 20000. Nearly every player could handle it. And those who couldn't, well, bad luck for them. Playing with 100ms+ is no fun for anybody.

Like I said in the root, talking generally 10-12Hz is really common because you need to handle dropped packets cleanly.

I don't know about the CS 1.6 days, I used to play a ton of early cs and was an admin on one of the most popular Frontline Force servers. We ran tick rate of 12 if I recall correctly.

It is mainly because PUBGs network code sucks. You can see the effects here [0]

Unless you had dial-up users, a tickrate of 12 is very bad and not fun. I don't know if you had hardware restrictions, but tickrate is independent of updaterate that is sent to the clients. By enforcing a low tickrate you maintain a very old snapshot of the world on your server (83 ms), which makes clients interpolate more.

[0] https://www.youtube.com/watch?v=u0dWDFDUF8s

CS(:GO) would be completely unplayable at any update rate below 50. Especially with the necessary interpolation, you would end up with delays of over 100-200ms+ at an update rate around 10. Most weapons in the game could even fire more than one shot in that time.

Strong disagree for the recommended tick rate for csgo. I played a decent amount of competitive cs, from 1.3 all the way to csgo. Lots of competitive server hosts will go up to 120 (ESEA comes to mind) , and the difference between 120 and 60 is certainly noticeable. Going down to 13 would be almost unplayable.

>So that might be the case for LAN games

Overwatch has a 63Hz tick rate over the internet.

And they handle congestion cleanly[1] which is one of the things I predicated you need if you didn't do 10-13Hz(along with smarter vis sets).

Every game is going to be unique and gameplay structure has a huge impact on your data rate. We had games back in '97 like Subspace[1] that handled hundreds of players in the days of dial-up and 200ms+ pings. Generally if your data rate per-link goes above 10kb/sec you'll start to see degradation of jitter across your userbase. There's smart ways to handle that but if you want to do a fixed-tick you run up against that limit really quickly.

[edit]

Other games will do smart things to keep skill high and tick rates low. CS(but not CS:Go that I know of) used to famously rewind time based on your latency so your view of the world was accurate, but lead to fun behaviors like rubberbanding as you got shot around a corner(due to movement speed slowing down at that past point in time and the game having to reconcile it with the current timestamp).

[1] http://www.eurogamer.net/articles/2016-08-12-looks-like-bliz...

[2] https://en.wikipedia.org/wiki/SubSpace_(video_game)

Man Subspace/Continuum was such a great game. I do recall issues with packet loss, but in general the game functioned really well even on my 33.6kbps modem with hundreds of players and pretty frenetic gameplay. It's not until you mentioned it that I realize how amazing that feat is.

Oh yeah, I love to hold up Subspace as a perfect example of why games is so cross-discipline driven. For networked games building design about predicting where someone will be means that frame-to-frame latency almost doesn't matter. The Newtonian physics of that game plays into it perfectly leading to a something that works over primitive modems. Even FPS games to a large degree are about predicting/leading the positions of the other players.

Compare that to say, fighting games which are very reactionary and very hard to run over any latent connection without some seriously complicated netcode involving time rewinding.

CS:GO (and all other source games) do the same lag compensation as CS did (though it's horrifically buggy, but it was pretty messed up in 1.6 as well). People seriously underestimate how impossible it is to play fast-paced games without it - you wouldn't be able to hit a HS on a moving player in CS:GO even with ~30ms ping without leading your shot if that wasn't there.

It's also not actually why you rubberband - that's just caused by your own latency (moving while already dead). It does mean you can get hit after moving behind a wall though.

Only PUBG and Fortnite have such shitty tickrates.

What do you mean by "game network servers tick the network"? Like data going server -> client ?