[andrewmcwatters]

You're referring to "leading the shot." This was common for games in the late 90s and early 2000s.

The problem is that leading the shot has two side effects: 1. what you shoot at in game isn't what you're hitting on the server, (you shot a player, but dirt kicked up from the ground several feet in front of them) and 2. some gameplay mechanics rely on accurate replication.

If you throw a grenade at a player and "lead the shot" maybe it sticks to them on the server. It kills them.

But on your side, it missed because you personally lag compensated, stuck to a vehicle, and now the vehicle blew up instead and flew off a cliff.

Now the game sends back updated entity positions and the vehicle and its occupants are back on the ground and everything just snapped for you.

You can rewind game state and make it not visible to players, then run hit calculations and do things like kill players and destroy objects without snapping.

Proper lag compensation implementations make it such that infrequently do you actually notice lag, even in exceptionally poor connection environments.

[kevinfat]

So consider a first person shooter with no rollback you're probably going to be aiming slightly ahead of the person to compensate for latency lag. And maybe you'll aim to the other side of the person if you think they changed direction before you saw it actually happen. Here because you feel the lag of your own movements you can take that into account in knowing how far ahead to shoot on the left side or the right side of your opponent.

With rollback if you guess they are going to continue moving in the same direction you just aim right on where you see them because of the prediction. If you think they are moving in the other direction you need to guess when they started moving in the other direction. That we are using rollback networking can't get rid of the need for you to guess this. To make that guess you'd like to know how far back they could have changed direction so you have some time interval in which to guess. From your perspective that time interval is based on the difference in time between the server's state now and the last server state you received. But my point is doesn't rollback make it impossible for you to know that while playing the game.

Whether you're using rollback or not you as the player need to know intuitively what is the time difference between the server's state and the latest server state received.

[andrewmcwatters]

No, I mean with lag compensation, you don't actually have to do that. The server calculates the difference between when you sent the input and its current game state, then performs some abstract lag compensation function, (this is usually moving all game objects back in time to where they were relative to when the command was sent) then replays game logic.

The side effect is that if anything of importance gameplay-wise did occur back in time, this abstract lag compensation function would reset just enough game state to make a difference.

In other games, the abstract lag compensation function might need to be something else, but for most purposes, I assume moving entities or actors back in spacetime is adequate. After the lag compensation function and game logic has completed, you call a second function, the inverse abstract lag compensation function. This is the equivalent, or should be, of the opposite operations performed in the first function. So, in this default case, moving all entities or actors back to where they were.

You wouldn't want to replay sounds for example, because you don't want to do anything that gets perceived by players, but the general idea is that lag compensation itself is "invisible" to players.

That is to say, if an enemy is moving on your screen in California, no matter how fast they're traveling, if you shot them from Phoenix or New York City, and sent that input back to the server in San Francisco, it should be calculated as damage applied, regardless of latency, up to a maximum latency tolerance such that players are not able to abuse lag compensation up to some upper temporal limit within reason.

For reference, the Source 1 stores player positions for up to a second.

[kevinfat]

On more thought I don't see how what you're saying is relevant to my point. The server needs to maintain the current state (which is based on the latest input it has received). No matter how you do the networking rollback or not you can't escape latency causing a problem in perceiving the wrong state on the clients. Thats why with rollback players sometimes see the enemy teleporting. The networking code cannot remove the need for the player to "lead the shot" in some sense.

[andrewmcwatters]

Correctly implemented lag compensation doesn’t result in players teleporting.

If a player drops packets for a while, they shouldn’t be teleported to a position once they start sending packets again. They’re sending input not positions.

When I say lag compensation removes latency-based leading-the-shot scenarios, I mean it, full stop. It’s completely removes this problem.

You’re describing teleporting which is caused by other malimplemented player movement and networking code.

[kevinfat]

That is wrong. Every description of rollback mentinos that. Replaying inputs after rolling back can result in a new state that is different from the client predictino which amounts to teleporting.

[andrewmcwatters]

No, it isn't. You're talking about a player-controlled object. But you're describing "leading the shot," which occurs when other objects teleport, which doesn't happen with lag compensation.

[kevinfat]

Ok interesting there is a lag compensation feature. I did not think of the server having something like that precisely because of what you mentioned it sounds like this is something the players can use to abuse or cheat with.