Very simplistic TLDR now every action will be timestamped and when the server processes a tick it will play out the actions it receives in order and decide if any actions should be ignored, like for example if that player should have actually died before pulling the trigger.
I always thought that’s how CS:GO servers worked, but apparently not! It seems pretty obvious and a very good solution that solves all of the problems between 64 tick and 128 tick servers in the past. Valve just continues to be a pretty amazing innovator in the world of gaming, you love to see it!
But, Valve literally pick up and implement what Overwatch did and input buffering is not new as well since Rocket League used it for a long time, also partially thanks to Overwatch dev if you watch Psyonix’s GDC talk. So yeah, many game dev does innovate through out, and don’t credit everything when Valve implement what other did and maybe make other improvement along the way. That’s how everyone improve, by learning from each other.
Agreed, it’s a good system and is more accurate than 128tick, even though it’s not perfect. E.g. the client still only shows the muzzle flash on the next tick, so up to 16ms after the shot was actually fired [1]. This is probably one of the reasons some people can tell the difference between 64 and 128tick, as the game might feel more accurate, even though the hit registration isn’t in any meaningful way.
One of the drawbacks of this system is that the client effects and the actual actions are now separated. Before you click, the next tick would happen, your input would be collected from the OS, actioned, and the effects would be triggered. Now, you click, and it’s immediately recorded into a record with its location and direction with a timestamp, the next time a tick happens the effects play. This means the input might feel a bit different due to that separation. It is possible to shoot in between renderings. So you are essentially shooting blind. This is where input might feel weird.
In CSGO if you ever catch yourself clicking that millisecond before you render, knowing that your crosshair will be on the right exact pixel in the next frame you get, and thus getting a headshot, that will now miss.
I was pretty sceptical of sub tick but I found in CS2 I was saying “bullshit” way less often than in CSGO. I’d actually hit people I aimed at rather than apparently shooting their outline on the wall behind. I also found shooting while walking isn’t completely impossible as well now. Who knows might even get back into CS once it launches.
Why can’t we have the sub tick system implemented in 128 tick servers? I assume Valve wants 64 tick servers because it’s cheaper to host, but if you want a 128 tick serve, why not combine that with sub tick for even better accuracy of events.
The events that are sub tick (not all are) aren’t more precise with 128 tick, since they are already time stamped with the exact time.
128 tick still has advantages for game feel and things like peekers advantage. Altough the latter is mostly down to each player’s ping in the match.
The 4 reason’s I’ve gathered why Valve probably doesn’t want 128 tick servers are:
- server cost
- people with slow internet
- people with slow computers
- smoke lineups are different on 128 tick vs 64 tick
The last point is really annoying with CS:GO since I have to learn different smokes and have to remember for which tickrate they are. Since the physics are calculated tick by tick, it’s difficult to make smokes the same on different tickrates.
Why stop at 128 tick? Why not update the game state every millisecond? Or when any action is taken by any player (which is what the subtic thing sounds like)? Eliminating as much time delay between 1 player doing something and the other players being sent that data seems to be the way to go; so what’s preventing it from being done that way? Bandwidth? CPU speeds? What?
Why not update the game state every millisecond? Or when any action is taken by any player (which is what the subtic thing sounds like)?
Updating the game state every millisecond on the server would cost too much resources without a tangible benefit. 64 tick to 128 tick doubles the CPU usage while decreasing the time between each calculated game state (tick) by 8ms. Updating every 1ms (1000 tick) would have 16 times your CPU usage compared to 64 tick. E.g. if you currently have 320 fps you’d only have 20 fps.
[what’s] preventing it from being done that way? Bandwidth? CPU speeds?
Exactly. If people currently have a varying ping or packet loss, increasing the tick rate would male their experience worse. It would also be worse for anyone matched with those players. This is already the case with those players that have jittering movement.
I don’t understand anything from that video
A tick is like a snapshot of the game state, i.e. where each player is, what they are doing, where they are looking etc. The tick rate describes how often this game state is calculated by the server and sent back to the clients (our PC’s).
The main reason why CS:GO 128tick server are so much better than 64tick server is because in Global Offensive the server doesn’t know exactly when each player pressed a button. The server only knows the tick in which a button was pressed or a head was shot. This leads to a tiny bit of discrepancy between what you actually did and what the server thinks you did (e.g. you were on the head but the game thinks you missed since in a single tick the player moved out of your crosshair). 128tick makes this more accurate.
Btw. this is also the reason why we need jump throw binds for smokes, since the jump throw only works if both buttons are pressed in exactly the same tick. Not even pro players can do this consistently.
CS2 provides the server with the exact time at which you shot, at which time your crosshair was on the target and at time you pressed a button. This means the hit registration is exact and doesn’t happen only every 16ms or 8ms on 128tick servers. Thus CS2 64tick hitreg > CS:GO 128tick. But there’re other factors in play which decide how the game feels, which is why 128 tick still has (minor) advantages in CS2.
Hopefully that helped. If not, feel free to ask and I’ll explain as far as I know. This topic is still developing and there’s much misinformation floating around.
Buncha people think they know more about programming netcode than the developers.
This video explains how the netcode is better than some people falsely claim. It’s only at the end that they want 128 tick for Premier mode, but that’s not a good idea.
Another example of a video that debunks a video which claimed CS2 had an input lag problem. [1]
