Netcode Interview - with Yahn Bernier
(senior software engineer at Valve).

Interviewer: Ninja

( Editors Note: The great Netcode debate continues, but this time we get Valve's opinions on the Netcode. GameSurge has had a couple of articles, of differing opinions, the original and the rebuttal. As well, we have opened up a special mailbag just for reader comments on the two articles. You can find comments on the first netcode article here, and comments on the rebuttal here.

This interview was written by Ninja, a staff member here at Gamesurge, who handles all public relations for us. Ninja, on behalf of Gamesurge, contacted Valve to get their opinions on the two netcode articles, and was fortunate enough to end up interviewing Yahn Bernier, senior software engineer at Valve. We wish to thank Mr Bernier for taking the time to answer some questions, and to Valve themselves. - shiva - )

1. Once and for all, for people who don’t know, how does the netcode work?

There are a bunch of aspects to the netcode (player physics consistency fixes, bandwidth optimizations, fragmentation/reassembly functionality, decoupling server and client frame rate, interpolation of player positions, handling packet loss, removing the need for fps_modem/fps_lan settings, etc.). All of these things are part of the “netcode” in a broad sense. With that said, what I think you are probably asking about is how the weapons fire and how hits are determined.

These features are actually totally separate (and user controllable). The first feature is something I would term “client-side weapon firing prediction.” What this refers to is the instantaneous set of effects that occur when the fire button is pressed. These effects are all done client-side if client-side weapon firing prediction is enabled (cl_lw is 1). The effects include: starting the weapon firing animation, showing any muzzle flash, creating any ejected shells, drawing decals and bullet puffs at the impact spot on the wall of the level, starting the weapon firing sound, etc. However, the actual determination of whether the shot (for hit-scan weapons at least) hit another player is now and always has been done at the server.

This brings up the second feature, which I would call “server-side hit computation and lag compensation.” As noted above, the server is the final arbiter of what and where a shot hits. The client does not send any kind of message saying “I hit player 2” or any such thing. Instead, the server’s logic is pretty much as it always has been. The server receives movements, view angles, and button states from each client. It applies them, and, if the fire button is pressed, it performs any necessary traces to determine which player(s) are hit by the shot, if any. If a player is hit, then the server sends down blood decals and blood particles to the client to show the effects of the shot (or even gibs the player). The wrinkle here is that, if the server is allowing lag compensation (sv_unlag 1) and if the firing player is requesting lag compensation (cl_lc 1 – note that the player must also be predicting weapon firing client-side, too, or cl_lc is ignored), then the server is able to backward reconcile player positions for the other players in the world and determine if, in fact, the player who pressed fire could and would have hit the target in his or her crosshairs. We often refer to this as an “inverse causality” model – it has certain paradoxes, but after a lot of thinking, we concluded that they are less severe than the regular inconsistencies of the old style network models. We believe that firing skill should be a factor of aiming and pressing fire, not predicting instantaneous latency and leading your shots. It still takes skill to hit your targets and the low ping player still has the decided advantage.

2. What is your response to people who claim that the new netcode only caters to high-ping, slower players, while causing low-ping players to have a disadvantage?

I strongly disagree. The low ping player still does and always will have the advantage. Certainly, when a high pinger fires, lag compensation might move a low pinger backward in time and let that player be hit where he or she otherwise wouldn’t have been hit. However, the much more likely scenario is that the low pinger will see the high pinger, press fire, and his or her fire message will get to the server well ahead of the high pinger. The low pinger will always be able to do this and, assuming the low pinger is decently skilled, the low pinger will be able to win out in any kind of duel/race-to-fire condition. In a lot of ways, I think that this update has meant that there are a lot of low ping players who have had to increase there skill levels a whole bunch in a short period of time.

3. Some have even gone so far as to call the patch a technological step backwards, because more people are getting broadband internet and suffering from the supposed disadvantage.

I’d have to disagree with this one, too. First of all, the update includes tons of new network functionality, and this comment/criticism is really directed at one single aspect: lag compensation. Broadband has not saturated very heavily into the US market yet (less than 5% was the last figure I read). This is almost always true when you go outside of the United States – where a lot of our players reside. Not to mention that broadband helps more with bandwidth than latency reduction (yes, having a faster pipe does lower latency somewhat, but the speed of light is still the real limitation). We believe that even if the world were 100% on broadband, that lag compensation is still a technology that is necessary to provide a smoother experience. I think for the vast majority of players, especially modem players, the update is nothing short of amazing for them.