Continuing from yesterday… I’ve discovered several very interesting articles on lag compensation in real-time environments. The first is from the author of the Unlagged! mod for Q3A, the second a discussion of lag compensation network transmission protocols in the Source engine, and the third is a higher-level conceptual discussion of lag comp. in terms of client/server synchronization, by Valve Software.
Unlagged proposes a pretty simple addition to normal dead-reckoned non-delayed broadcasting, by using historical data to check for weapons hits. This method produces a result that is fair to sending clients, but may seem inexplicable to receiving clients. A client aims for his enemy, pulls the trigger, and hits, but from the victim’s perspective he may have dodged the shot. Clearly, this is a good first step but not the whole thing.
Valve’s documents were much more interesting. They proposed having the client-server simulation as usual - but have the client render a fixed timestep behind the server. That way lag compensation discrepancies can have time to blend and interpolate before being presented to the user, and that clients do more interpolation than extrapolation, which is always good for everyone.
Extrapolation involves predicting the movement of objects in the future. While this is generally accurate, if the player is moving erratically it can actually be quite far off. In the Source implementation the only thing that is extrapolated is the player’s own movements, which by all accounts is fairly accurate. All other movement, including other players, is interpolated between already-known data, hence why the entire engine renders 100 ms behind the actual simulation.
I put together a little diagram with a test scenario and ran it through my head. This works rather well:
No comments:
Post a Comment