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

81–90 of 136 posts

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

#81

Post by wyldberry »

Havoc wrote: post #66

You can mess with the code all day long, but you're not getting away from raw latency. The modern matchmaking approach groups people by skill not latency, so you get a pretty wild mix of latency. It feels nothing like the old regional servers. Sure the skill mix was varied, but at least you got your ass handed to you in crisp <10ms by actual skill. Now it's all getting knife noscoped around a corner by a guy that rub…

Good thing they thought of that. Disclaimer: I was at Riot During some of the Valorant dev cycle and the stated goal in this tech blog [0] was a huge goal (keeping latency This was only really doable because Riot has invested significantly in buying dark fiber and peering at major locations worldwide [1][2]

[0] - https://technology.riotgames.com/news/peeking-valorants-netc... [1] - https://technology.riotgames.com/news/fixing-internet-real-t... [2] - https://technology.riotgames.com/news/fixing-internet-real-t...

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

#82

Post by Thaxll »

Sohcahtoa82 wrote: post #65
Thaxll wrote: post #42

Earlier quoted context omitted.

You'll never get a modern FPS gameserver with good performance written in a GC language. Erlang is also pretty slow, it's Python like performance. Very far from C#, Go and Java. The other reason is that the client and the server have to be written in the same language.

> The other reason is that the client and the server have to be written in the same language. This isn't true at all . Sure, it can help to have both client and server built using the same engine or framework, but it's not a hard requirement. Heck, the fact that you can have browser-based games when the server is written in Python is proof enough that they don't need to be the same language.

Browser game don't need performance, I'm talking about AAA online games here, which 99% are built in c++ and the rest in c#.

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

#83

Post by dfltr »

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…

> I assume there'd be a big single rectangular bounding box or sphere, and only once a projectile is in that range, then animations occur.

Now that's a fun one to think about. Hitscan attacks are just vectors right? So would there be some perf benefit to doing that initial intersection check with a less-detailed hitbox, then running the higher res animated check if the initial one reports back as "Yeah, this one could potentially intersect"? Or is the check itself expensive enough that it's faster to just run it once at full resolution?

Either way, this stuff is engineering catnip.

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

#84

Post by ZeWaka »

Thev00d00 wrote: post #6
mmmeff wrote: post #2

Take notes, Valve.

Sub tick is probably more accurate overall but I do think the cs2 animation netcode is crap and hides a lot of the positives. Hopefully moving to Animgraph 2 will help that, who knows

The partially-implemented animgraph2 heroes in Deadlock are looking pretty good and hits feel accurate in-game.

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

#85

Post by maplant »

dfltr wrote: post #83
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…

> I assume there'd be a big single rectangular bounding box or sphere, and only once a projectile is in that range, then animations occur. Now that's a fun one to think about. Hitscan attacks are just vectors right? So would there be some perf benefit to doing that initial intersection check with a less-detailed hitbox, then running the higher res animated check if the initial one reports back as "Yeah, this one coul…

This is the basis for basically every physics engine in some form of another. Collision is divided into the "broad phase" pruning step that typically uses the bounding box of an object and a "narrow phase" collision detection step that uses the more detailed collision primitives

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

#86

Post by [deleted] »

uyzstvqs wrote: post #73

Counter-Strike: Global Offensive was also able to handle 128 TPS just fine. They just chose to never implement it in official matchmaking (64 TPS). It did work very smoothly on community servers. Counter-Strike 2 implements a controversial "sub tick" system on top of 64 TPS. It is not comparable to actual 128 TPS, and often worse than standard 64 TPS in practice.

[deleted]

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

#87

Post by furyofantares »

Thaxll wrote: post #79
bakugo wrote: post #69

Earlier quoted context omitted.

Nowadays it's more like 20 players and 80 bots, so a lot less networking stuff going on, and the bot AI is so basic that I doubt it has a significant impact on server performance unless it's very badly implemented.

AI is more expensive than a regular player.

In my experience you can do reasonable bots cheaper than sending network updates to a regular player. Thats just straight up, but you can also tick their logic way less than every update if you want. Even more way-less if nobody is near them or spectating them.

Also some stuff you might want to calculate for them to use to make decisions can be shared among all bots.

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

#88

Post by aftbit »

whalesalad wrote: post #12

I wonder if any game servers are implemented in Erlang?

I've been told that Erlang is somewhat popular for matchmaking servers. It ran the Call of Duty matchmaking at one point. Not the actual game servers though - those are almost certainly C++ for perf reasons.

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

#89

Post by array_key_first »

mikhmha wrote: post #45
seivan wrote: post #14

Earlier quoted context omitted.

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.

In the case of Call of Duty: Black Ops 1. Thee matchmaking + leaderboards system was implemented by DemonWare (3rd party) in Erlang. Erlang actually has good enough performance for many types of multiplayer games. Though you are correct that it may not cut it for fast paced twitch shooters. Well...I'm not exactly sure about that. You can offload lots of expensive physics computations to NIF's. In my game the most exp…

The biggest hurdle to a game server written entire on the BEAM is the GC. GC pauses just take too much time, and when you need to get out (for example) 120 updates per second, you can't afford it. Even offloading stuff to C or C++ does not save you, because you either have to use the GC, do a copy, or both.

Game servers typically use very cheap memory allocation techniques like arenas and utilize DOD. It's not uncommon for a game server simulation to be just a bunch of arrays that you grow, never shrink, and then reset at the end of the game.

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

#90

Post by ghshephard »

They bury/obscure a quite important detail in this article:

| We were still running on the older Intel Xeon E5 processors, ...

| Moving to the more modern Xeon Scalable processors showed major performance gains for our server application

But - I was unable to find any mention in the article as to what processors they were actually comparing in their before/after.

Post reply on HN