News, and the latest updates.
Stories from the past...
Got a item of interest? Here's the place to go.
Your opinion always counts on how we can make GameSurge
Comments on our features, by you, the viewers.
Tweaks, reviews and a handy driver index highlight our newest section
Looking to buy one of the hottest games? We have it covered.
Get a advanced look at the games of tomorrow.
Find out more about the people behind your favorite game.
Need Help? We have a very large selection of walkthroughs now up.
A special section featuring the best in artwork and
The written word, by staff and viewers.
A bi-monthly column contributed by Mark H Walker, an independant writer in the Gaming community.
Pictures from around the web.
Our current hosting plans and features.
Who we are, what we do, our policies and job positions.
The Sony PlayStation, and beyond...
The Dreamcast resource, and more. Home of the DC Technical pages.
(senior software engineer at Valve).
( 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
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
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.
On to page 2: Addressing these issues and the future -->
Zalman: ZM-DS4F Headphones
An affordable, ultra-portable headphone set.