|
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. |