This is part 2 in a series.

The source engine netcode is a little squirrelly. It always has been and it always  will be. One of the questions I am bombarded with is ‘How do I fix XYZ to make the game run better?’ In order to make the universe a slightly better place, I’m going to try and help all of you.

Articles in this series will include:

1. The basics of how source netcode works
2. How the source engine compensates for an imperfect environment (You Are Here)
   
3. Understanding the Netgraph
4. Optimization Guide
5. Everything else advanced and so far not covered

An Imperfect World

As I mentioned in part 1, the environment in which servers operate is not perfect. Server resources, bandwidth limitation, connection diversity,  player location vs server location, etc all contribute to an environment which is less than ideal. Accordingly, methods to compensate for these imperfections are necessary.

Source makes use of three main compensation methods: Interpolation, Input Prediction, and Lag Compensation. Throughout the rest of the article, I will be discussing the theory and practical implementation of the aforementioned.

Interpolation

The first method of compensation is entity interpolation, it also happens to be the hardest to understand. If you can make it through this section, the next two will be a piece of cake.

Servers send clients and clients send servers snapshots of their action at a rate of Xsnapshots/second. In a perfect world, this rate would be Infinitysnapshots/second. Considering we don’t live in a perfect world, it’s usually between 66-100snapshots/second. Thus, if the game engine were to only display  the received snapshots, then motion would appear jagged and choppy. In order to compensate for this problem, the source engine makes use of interpolation.

In its basic form: Interpolation is the server looking at snapshots A and C and creating a certain number of B snapshots so motion is smooth and continuous.

More advanced: The source engine goes back in time to interpolate. To understand this, you need to realize that Client Time with the server and Rendering time is offset depending on the interpolation value.

You receive a frame at client time A and then later at time C, the engine then goes back in time to just before time A and renders all the frames in between A and C. Thus your render time is usually between 10-100ms behind your client time.

Here’s an example directly from the Source Developer Wiki

The last snapshot received on the client was at tick 344 or 10.30 seconds. The client time continues to increase based on this snapshot and the client frame rate. If a new video frame is rendered, the rendering time is the current client time 10.32 minus the view interpolation delay of 0.1 seconds. This would be 10.22 in our example and all entities and their animations are interpolated using the correct fraction between snapshot 340 and 342.

So, interpolation will cause a render delay of Xmilliseconds (often 100).

For anyone who has followed me thus far, you may be wondering what happens if the packet containing frame A or frame C is dropped. Well, by default the game uses 3 packets for interpolation. That way, one packet may be dropped without issue. If more than one packet in a row is dropped, the engine will make use of Extrapolation - it takes a look at the two most recent packets and tries to make linear sense of the action between them.

That covers interpolation. Congratulations.

Practical Interp Commands

There are very few now. The old inerp system assumed a certain delay time and packet time, which was rarely used. Accordingly, problems were created by it. Ever since the interp update to the netcode, there has been very little reason to adjust interp settings as the game does a much better job of dynamically setting them for you.

Besides, most servers restrict manual configuration of the interp settings. So, if you’re one of those people who understands this enough to configure it yourself, you’re still probably out of luck.

Prediction

Next we have input prediction. Much, much easier to understand than interpolation.

Consider a player with 100ms latency (lag). Every time they input a command such as +FORWARD there is a 100ms delay from the time the user makes that command to the time the server receives it. Combine that with the added latency of the  server sending a new ’snapshot’ to all the players and you end up with a problem. All player input would be very delayed - it would start after you pressed the key and end after you let off.

To solve this problem, source uses prediction. Which is just as simple as it sounds. Using the same rules the server would use to process your commands, the game instantly predicts the results of your actions. Then that is sent to the server.

In effect, your position is ‘predicted.’ You are in effect sending the future to the server.

This is not an exact science, however, and there are occasional errors. Sometimes the server predicts your future position incorrectly. When this happens, errors are smoothed out over time via the cl_smooth command. Without this smoothing, the game would be very jerky every time an error occurred.

Keep in mind that prediction only works for you. You only predict your position, not other players’ positions.

Practial Prediction Commands

Same thing as interp. cl_smooth 0 used to make a lot of sense. After the netcode update, leaving things default does a much better job.

Lag Compensation

Lag is the basic ‘problem’ of all multiplayer games. You make an action and the server does not receive that action instantly. Rather, there is a latency period from the time you made the action and the time the server receives it. During this time, the server is still calculating the world. What you see happening is not what is really happening.

To action compensate for this problem, the source engine makes use of lag compensation. It keeps track of all player actions for 1 second and uses the following equation to estimate the time at when an took place.

Command Execution Time = Current Server Time - Packet Round-Trip-Time - Client View Interpolation

A fairly simple equation. It is flawed however. It is flawed because the server must make the decision based on client packets of action rather than just accepting client result packets.

This would explain why you may be hit by a bullet after you have ducked behind cover. The server estimated that you were still on the attacker’s screen at the  time the shot was fired. Sometimes this is the case, sometimes it is not.

• Why the room for error?
• Why calculate on the server rather than on the client?
• Why introduce the room for error, rather than make use of pixel perfect precision?

The answer to all of the above is the possibility to alter the packets. All clients must be assumed ‘clean’ for the aforementioned to make sense. Any hacking or abuse of the system would be very easy.

So, we must deal with inconsistencies and paradoxes of lag. Paradoxes created due to low packet speeds. Paradoxes avoidable in the real world due to light (the packets) traveling infinitely faster than our in-game packets.

Practical Lag Comp Commands

There aren’t any. You are entirely up to the mercy of the game engine on this one. This used to be a bad thing. If any of you remember the old lag comp videos, the lag comp engine when source was first released was horrible. There was a serious delay between rendered player position and actual player position.

Good news, that has been more or less taken care of. Huzzah!

There you have it!

That’s all for today folks. Hopefully it was a bit easier reading in comparison to yesterday.

Tomorrow should get even better. Expect a comprehensive look at the netgraph. The best and worst thing to ever happen to source.