# CS 2 "sub-tick" rate

The new update for Counter-Strike have just been announced and I found myself particularly intrigued by the "sub-tick" rate feature. The launch trailer video suggests that the refresh rates will be (almost?) continuous, despite being a digital machine (???).

So I'm curious about exactly what is a "sub-tick" rate and as to how they are accomplishing this. Is it simply a matter of having an extremely high tick-rate or is it really something "beyond the tick rate"? Is this going to affect the servers, are they going to need a full overhaul, or everything can be done with a improved code logic?

I am aware that certain answers may may require an understanding of the project's internal workings, but don't have much knowledge on this topic and this announcement made me very impressed, so any information will be greatly appreciated. Thanks in advance!

• We really wont know until some people crack open the netcode to see. My personal opinion would be that they are dodging the question of the tickrate by saying that but its mostly marketing
– Fredy31
Mar 22 at 23:18

I've built a game engine before, so I can answer this to some extent.

In the real world, the world's state changes all the time. In a computer, that's not possible. The computer needs time, albeit very little, to compute the next state of a game world. The game world's state obviously can't change during that time.

Whenever the computer calculates the next state of the world, we call this a "tick".

There are two main ways to tick:

• Fixed timestep: Here, we define how often the computer should tick in a specific amount of time. Whenever the computer can tick, we calculate how much time passed since the last potential tick, and add that time to a so-called "accumulator". Once the accumulator is large enough, we let the computer tick and remove the appropriate amount of time from the accumulator. For example, if we want the computer to tick 60 times per second, we'll wait until the accumulator has grown to at least 1/60 of a second (16.666 ms), and remove that amount of time from the accumulator.

• Variable timestep: Here, the computer ticks whenever it can.

Fortunately, calculating the next state of the world is easy, regardless of how we tick. If you think of time as a "turn", then a character that moves 1 tile per turn will have moved 5 tiles after 5 turns, and 0.1 tiles after 0.1 turns.

But while the variable timestep may seem superior at first glance, it's actually much harder to deal with when you need consistent behavior. Consider the following illustrations taken from How to make your game run at 60fps by Tyler Glaiel:

Above, we have a jump simulated at a fixed timestep. No matter how fast or slow your PC is, it will always simulate this same jump the same way. Here, the foot approaches the box from above, resulting in the character landing on top of it. The same is not true for variable timesteps, as the illustration below shows:

Here, the computer wasn't fast enough to simulate every "step" of the jump, and so the foot approaches the box from its side. This means the character collides with the box and will land next to it instead.

If two players make the exact same move, you obviously don't want two different outcomes. This is why simulations that affect gameplay are usually done with fixed timesteps.

So I'm curious about exactly what is a "sub-tick" rate

The way I understand it, it's a partial tick that happens right before a regular tick.

Without this feature, whenever a player shoots, the shot will be resolved in the next tick: The world's state will advance by a fixed timestep, and the shot will be resolved to see if it hits. Between the time of the shot and the time of the next update, the enemy player may have moved enough to avoid the shot. As a result, a shot that should've hit will have missed instead.

If I were to implement this feature, I would attach a timestamp to the shot. This would allow the server to calculate the position of the players at the moment of the shot, to see if it hits. Once the sub-tick is over, the server would perform its regular tick, updating the position of the players among other things.

The sub-tick should not change the world's state beyond "something was hit by the shot", otherwise the simulation could become inconsistent. For example, a player somewhere could succeed in a jump that should've normally failed.

Is this going to affect the servers, are they going to need a full overhaul, or everything can be done with a improved code logic?

One way or another, this is definitely going to affect the servers.

Even if Valve wants to leave the current server software untouched, the sub-tick feature alone will require an update. The servers will need to perform partial ticks before regular ones.

A feature like that could require a full overhaul, but doesn't have to. It will most likely affect at least one core components of the software, however.

• What I'm understanding is that the difference would be that when someone shoots something it checks 'Would that have hit at x timestamp' instead of 'would it hit on the moment of the tick'
– Fredy31
Mar 23 at 15:01
• @Fredy31, yes, basically that's what it means. I suppose I wrote too much (yet again). Mar 23 at 17:08
• @Fredy31, Although it would put the events in the correct order and time, wouldn't that make the player unable to perform actions during the inter-tick period?
– Lipe
Mar 23 at 19:31
• @Lipe, it all depends on the exact implementation, but for the simplest one you would definitely disallow player actions other than shooting. If you allowed players to jump on sub-ticks, you'd have to simulate every step of the jump on sub-ticks. This means you'd have to simulate unrelated objects at the same subtick, so you can check for collisions. In short, a single sub-tick jump would double the effort required for collision detection. If handled poorly, your performance will suffer a lot. Mar 23 at 20:26