This is really simple and short, but it paves the way for a bug we encountered in SourceMod. What is a tickrate in Half-Life 2?
A game is like a film; it has “frames” and the number of frames per second determine the smoothness of the experience. Don’t confuse this with graphical FPS, which although related, is different. In Half-Life 2, a “frame” is a short burst of time where all entities, physics, client updates, and netcode are processed. By running frames at specific intervals, a game can simulate real time without using an extraordinary amount of CPU.
The default interval in Half-Life 2 is 15ms. That is, every 15ms, a frame is processed. The engine, in pseudocode, does this:
TIME = 0 WHILE TRUE RUN FRAME TIME = TIME + INTERVAL SLEEP END WHILE
In this manner, a global time value is updated to keep track of how many intervals have passed. The mod uses this time value to schedule all internal actions. The subtle note is that this time is not related to ‘real time’. Any number of actual clock seconds may pass in between that interval. For example, if you were to halt the game in a debugger, then resume it five minutes later, its internal time would be unaffected. It would pick up where it left off and continue as if nothing happened.
In Half-Life 2, mods are able to set their own tickrates. CS:S doubles the default interval, for a 30ms tickrate. You can also change the default tickrate with the -tickrate command line parameter. Any value over 10 will result in a new tickrate of 1.0/x seconds. For example, a tickrate of 100 will be 10ms, and a tickrate of 66 will be 15.15ms. Sometimes this is advantageous; for example, CS:S will have smoother gameplay on higher tickrates (“100 tick servers” are popular), though it will consume more CPU.
Simple reverse calculation: If the tick interval is 30ms, the number of ticks per second is 1/0.03.
Next week: A mis-conception in the ticking accuracy caused a flaw in both AMX Mod X and SourceMod’s timer systems.
Update 2007/12/09: CyberMind pointed out a typo in my math.