Is this a viable architecture for lag compensation?

Question

In some games/engines (such as Source), the server compensates for latency by applying player inputs in the past. Whenever the server receives a player's input for a frame, it rewinds the game to the frame that input was intended for, applies the player input, then simulates the game again up to the current time. The server needs to do several times as much game-logic computation as the clients, as each frame can be simulated many times - so it seems like this would not scale well to many clients or processing-intensive games.

However, we can turn this around. If the client input for a particular frame always arrives before the server simulates that frame, then the server never needs to rewind - it only ever simulates each frame once.

In order for a player's input to reach the server before the frame that the player entered it on, the client needs to run in advance of the server. If a particular client has a latency of 250 ms, then it must simulate tick 51388 at least 250ms before the server simulates tick 51388.

Therefore, the client must be predicting the game state several ticks in advance. Every time the client receives an update from the server, the client rewinds the game, applies the update, and fast-forwards up to the current time.

If n is the number of clients, then the clients each do O(n) extra work per tick to support lag compensation, instead of the server doing O(n^(2)) extra work per tick (assuming the game state size scales as O(n)).

I don't know of any games that actually do this. What are the problems with this approach?

Answer 1

You want the server doing lag compensation because that's its job. In a multiplayer environment, the client is in charge of graphics, and movement lag compensation (smoothness of movement). The server is in charge of physics, computations between players and objects, as well as lag compensation(assurance of accuracy).

In the end, the server still has to verify the accuracy of your aim on whoever you shot.

With the client prediction you have, you can't guarantee the enemy will be in your sights when you fire because the client predicted where everyone was and when you shoot, your assuming your aim is accurate entirely on the clients prediction. Just like a crazy driver on the freeway, you cant accurately predict they were going to cut off the big rig and get sandwiched.

in a more technical form, each time you fire, the client sends a timestamp of when you fired, not the tick you were on. The server looks back at the tick closest to that timestamp and determines if you were accurate. This is why you die a second after you ducked behind the wall in battlefield. The enemy shot while you were standing, and the round hit you, but the server verifies and tells all players.

Answer 2

If you shift the work to the clients, they have to do even more work than the server does.

They will have to rewind the same way as each client sends their input to each clients and the rewinding will be done on double the latency (250ms (clientA->server) + 250ms (server->clientB)) as inputs are relayed over to the other clients through the server.

The idea of having the server do all the work and send the solution over is so that clients with cheap PCs and consoles can still play the game and that the one with the least lag, the best internet connection, will process things with the least lag for the other players as possible to not penalize everyone over the entire clientA->Server->clientB ping-pong.

Answer 3

In addition to the other answers about the extra work it presents, I will make two other points:

1. As the game developer, you likely have control over the servers you're running. This means you can ensure your server meets the requirements necessary to run your game. Even if you let others run your server on their own machines, it's easy to say that they need to match certain requirements. The requirements of a game server are expected to be high. Meanwhile, you don't have control of the client machines, and the more machines you can target the better, so it's best to reduce the amount of computation that clients need to perform. Server requirements are expected to be high, but players expect you to work to decrease their technical requirements.
2. Split-responsibilities. Similar to OOP's Single-Responsibility Principle or the reason for splitting up the responsibilities in a framework like MVC or Entity-Component-System, it's important to decide what is responsible for what and maintain that. Specifically, what I would point out is that client input can never be trusted, the server needs to validate everything. So if the server would need to validate the input, which can only be done by rewinding anyway, then you're just doing the same calculations anyway. Ultimately, it's best to have the client do as few computations as possible and let the server handle the majority of the work on things like physics.

Lag compensation, like physics and player interactions, is ultimately the server's responsibility.