In the VAIL VR discord I often see people complain about various network conditions and just blame it on ping, to the point where people are blaming frame drops on ping. This annoys me slightly so I've decided to bite the bullet and write some frontend code to visualize what the different network conditions actually does to your gameplay.
Lets take a step back
As this will be shared in the VAIL VR discord whenever someone who don't know how games networking works start to complain and blame ping, or when people complain to the devs saying "just magically fix netcode"¹,
I need to consider that they probably aren't massive networking nerds. So lets go through some basic stuff:
Your position isn't magically sent smooth to all the other players for performance reasons. It is instead sent as individual position "ticks" at a fixed tick rate²
The local player is smooth as we know what the position is every frame. This is different for the remote, which is the local player but from the perspective of another player, so this will only be updated once per tick.
Vail runs at 60³ ticks per second, which does look fine enough in the ideal conditions we have right now. But unfortunately data doesn't magically instantly transport to anywhere in the world, so we have things like ping and packetloss.
In VAIL the ping number that is shown on the scoreboard is not as simple as it seems. This is referring to RTT (the round trip time) which is how long it takes for a message to go from you -> the game server -> you again. RTT generally isn't too useful when dealing with games, especially movement as the messages goes from you -> the game server, but doesn't require sending a acknowledgement for receiving it back. How long it takes for a message to go from you -> the game server is referred to as latency. In these visualizations we are visualizing messages going from you -> the game server -> another player. We will be referring to this as end to end latency (E2E latency). To keep things simple we will be assuming all latency is symmetric (you -> the game server and the game server -> you having the same latency). If you want to plug in actual metrics from a game, you can use this to find out what your E2E latency should be.
If you would rather use some preset values, you get around40ms
E2E latency for EU only matches, and for the more common example of 2 EU players on NA servers would be around 120ms
E2E latency.
Anyways latency isn't just a "static" time, there is also jitter which is a part of your latency which is random. My super simplified version of jitter just does which isn't perfect, but it should be accurate enough for these visualizations.
It's quite hard to get some good reference numbers for jitter as this is something that doesn't show in game in VAIL, however I would guess a normal game for me would be around 30ms jitter. Remember that jitter is both from you -> the game server and the game server -> other players. All these things makes the game experience worse, but how would adding smoothing impact these?
This hides the ticks and jitter pretty well and allows you to use a lot lower tick rate while still maintaining smooth gameplay. This has it's own issues like making the positions delayed, but this is worth it for smooth gameplay. My smoothing implementation is quite simple and probably not as sophisticated as the one used by VAIL and other games.
My implementation also supports extrapolation⁴ continuing estimating the position past what we know, which may work well in environments with higher packet loss. This is however not used by games like VAIL as they "prefer what you see be tightly coupled to the raw data/updates"⁵. These are the most important networking concepts that can cause issues when playing games. There are some other like bandwidth that are also important, however they can be pretty easily emulated by just increasing packetloss and E2E latency as tick rate goes up.
Alright, let's get into how this affects gameplay
Jigglepeeking
Jigglepeeking is when you peek in and out from behind a wall quickly to get some shots in before unpeeking before the enemy is able to see you. This works really well on low-tickrate games, but isn't as effective on high tickrate games.
The player is invisible here from the remote perspective as the player is ticked when the player is behind cover and not when they are outside cover. So the reason "jigglepeeking doesn't work in VAIL" is because it has a really high tickrate.
Ping swinging
Ping swinging is where you swing around a corner where you know the enemy is in view so that you can use your ping to kill them before they can even see you. Ping swinging is a pretty useful way to get a trade as in VAIL it trusts both clients when they say they killed the enemy.
Footnotes
- cough cough
- Tick rate is how many times a specific action should be ran. Minecraft for example does all its game logic 20 times per second.
- VAIL's tickrate confirmed by aoud
- Extrapolation explained by WikiPedia
- Why VAIL doesn't use extrapolation