Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Valorant's 128-Tick Servers (2020)

technology.riotgames.com

Post reply on HN
Print view View original

11–20 of 136 posts

Re: Valorant's 128-Tick Servers (2020)

#11

Post by Hikikomori »

deathanatos wrote: post #7

128 ticks per second servers. (And lo, suddenly the article's thesis is inherently clear.) A "tick", or an update, is a single step forward in the game's state. UPS (as I'll call it from here) or tick rate is the frequency of those. So, 128 ticks/s == 128 updates per sec. That's a high number. For comparison, Factorio is 60 UPS, and Minecraft is 20 UPS. At first I imagined an FPS's state would be considerably smaller…

Client update was measured to be 73, not quite matching the 128 server tick and update rate. Maybe it changed in the last 5 years. CSGO private servers also ran with 128 tick rate.

https://www.youtube.com/watch?v=ftC1Rpi8mtg

Re: Valorant's 128-Tick Servers (2020)

#13

Post by Hikikomori »

actionfromafar wrote: post #9
deathanatos wrote: post #7

128 ticks per second servers. (And lo, suddenly the article's thesis is inherently clear.) A "tick", or an update, is a single step forward in the game's state. UPS (as I'll call it from here) or tick rate is the frequency of those. So, 128 ticks/s == 128 updates per sec. That's a high number. For comparison, Factorio is 60 UPS, and Minecraft is 20 UPS. At first I imagined an FPS's state would be considerably smaller…

And Fortnite is allegedly 30 ticks per second.

And a few more players.

Re: Valorant's 128-Tick Servers (2020)

#14

Post by seivan »

whalesalad wrote: post #12

I wonder if any game servers are implemented in Erlang?

Network connection, lobby, matchmaking, leaderboards or even chats, yes. But the actual simulation, probably not for fast paced twitchy shooter.

Also not just for performance reasons, I wouldn’t call BeamVM hard realtime, but also for code. Your game server would usually be the client but headless (without rendering). Helps with reuse and architecture.

Re: Valorant's 128-Tick Servers (2020)

#16

Post by Tiberium »

fngjdflmdflg wrote: post #8
mmmeff wrote: post #2

Take notes, Valve.

This is from 2020. Valve wanted to be smart and invented a new "subtick" system in 2023 which isn't as good as 128 tick. To make things worse, CS is a paid game, not free like Valorant, and makes probably much more money. They seemingly just don't care enough about the problem to solve it correctly. That or there is more work to be done on subtick to make it work better than 128.

Nowadays Counter Strike 2 is free to play, although a paid prime upgrade is almost required if you want to play decent matches with less cheaters. FACEIT requires prime status too.

https://help.steampowered.com/en/faqs/view/4D81-BB44-4F5C-9B...

Re: Valorant's 128-Tick Servers (2020)

#17

Post by seivan »

fngjdflmdflg wrote: post #8
mmmeff wrote: post #2

Take notes, Valve.

This is from 2020. Valve wanted to be smart and invented a new "subtick" system in 2023 which isn't as good as 128 tick. To make things worse, CS is a paid game, not free like Valorant, and makes probably much more money. They seemingly just don't care enough about the problem to solve it correctly. That or there is more work to be done on subtick to make it work better than 128.

CS hasn’t been a paid game since it was a mod for HL back when you needed cd-key for online, which predates Steam.

Re: Valorant's 128-Tick Servers (2020)

#18

Post by Ellipsis753 »

jauntywundrkind wrote: post #5

> In VALORANT’s case, .5ms is a meaningful chunk of our 2.34ms budget. You could process nearly a 1/4th of a frame in that time! There’s 0% chance that any of the game server’s memory is still going to be hot in cache. This feels like an unideal architectural choice, if this is the case!? Sounds like each game server is independent. I wonder if anyone has more shared state multi-hosting? Warm up a service process, th…

It does sound like each server is its own process. I think you're correct that it would be a little faster if all games shared a single process. That said, then if one crashed it'd bring the rest down.

This is one of those things that might take weeks just to _test_. Personally I suspect the speedup by merging them would be pretty minor, so I think they've made the right choice just keeping them separate.

I've found context switching to be surprisingly cheap when you only have a few hundred threads. But ultimately, no way to know for sure without testing it. A lot of optimization is just vibes and hypothesize.

Post reply on HN