We had a tough time getting our GOTV relays smooth. Unlike match making servers, SoStronk servers run a standard 128 tickrate. This results in smoother and more accurate game play for gamers and thus is of paramount importance to SoStronk. We started off with a modest target. We wanted our GOTV relays to be on part with the official standard, […]
We had a tough time getting our GOTV relays smooth. Unlike match making servers, SoStronk servers run a standard 128 tickrate. This results in smoother and more accurate game play for gamers and thus is of paramount importance to SoStronk.
We started off with a modest target. We wanted our GOTV relays to be on part with the official standard, which is 16. This translates to setting the
tv_snapshotrate server variable to 16.
However, even after doing that the GOTV relays used to report a tickrate of 128/128 to the gamers connected. This was misleading and causing a lot of confusion to people as they though we were serving out GOTV at 128 tick.
Too Much Bandwidth
While it is reasonably easy to support 128 tick servers where 10 players are actively playing, its a entirely different ball game to support a 128 tick GOTV relay for a lot more watchers. A tick is a regular event in the game engine which is used to do all routine activities and calculations involving the players in the game. This includes doing math to calculate bullet trajectories, etc. As a result, a 128 tick GOTV (where 128 events are transmitted out every second) vs a 16 tick one means a 8x bandwidth penalty. That shoots up really fast as the number of watchers goes up and not really sustainable on the long run.
Devil is in the detail
After much experimentation (which included recording demos at various combination of server tickrate, server min cmdrate and tv_snapshotrate and comparing the raw sizes) we figured out that the
tv_snapshotrate variable actually works as advertised and that the rates displayed at the connected clients were actually wrong. Lets look at how the bug works.
There are a couple of variables at play here:
- sv_mincmdrate / sv_minupdaterate
- cl_cmdrate / cl_minupdaterate
To ensure fair play and to prevent rate hacking, we set our
sv_minupdaterate to 128 and the
sv_client_cmdrate_difference to 0. This prevents the gamers from being to change their
cl_updaterate around (this can be used to get an unfair advantage over your opponents). However, the value displayed in the screens of gamers is essentially the max of all the values mentioned above.
So , in the official matchmaking servers, because the
sv_minupdaterate are set to 10, a value of 16 (i.e. the
tv_snapshotrate) shows up because it is higher than 10.
However, in our servers, the value 128 shows up because the
sv_mincmdrate (which is 128) is higher than 16 (which is
tv_snapshotrate). Simple once you figure it out right?
Getting it smooth
We still had a problem of our GOTV being very framy (gamers will understand the term) at 16 tick. I mean, if matchmaking GOTV is super smooth with 16 tick, should our GOTV also not be smooth? Well, apparently not.
After some experimentation we figured that with 128 tick servers, a
tv_snapshotrate of 16 is not enough to render a smooth GOTV. Setting it to 32 instantly fixed the jerkiness for spectators.
Figuring all this out from zero documentation was bit of a chore. But fun non-the-less once its all said and done. Hurray for smoother 32 tick GOTV and demos.
You must log in to post a comment.