
Latency Compensating Methods in Client/Server Games - zemanel
http://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization
======
staunch
I still like the original Quake1 networking code (NetQuake) the best, which
has zero prediction. It feels extremely stable and responsive. There's no
warping/jello feel at all.

Most broadband connections (in the US) are really quite low latency and free
from packet loss, especially to servers that are nearby (~800 miles).

Most cable/DSL connections will see 20-40 msec ping times to nearby servers.
No prediction is necessary (or wanted) in that case, but you can still feel it
a bit on all modern games.

~~~
smokinn
No, broadband connections are starting to have major latency issues and it's
only going to get worse in the short term.

Check out this earlier discussion on bufferbloat:
<http://news.ycombinator.com/item?id=2002992>

Basically, if you have a broadband connection, a wireless card and a wireless
N router expect bizarre latency spikes. The reason you get those unpredictable
spikes is because of the unnecessarily big buffers at every step down the
line.

~~~
cma
Explain why large buffers in and of themselves would matter? The only relation
I could see there would be if they were flush-on-fill, or constant rate in,
constant rate out (like the audio buffer in a receiver). Aside from those
cases, if the new bigger buffers are actually always being utilized near the
new bigger sizes, then a smaller buffer scenario would just mean you'd get
more packet loss and even more latency, right?

~~~
smokinn
It's indeed because they're flush on fill.

Games that don't optimize and use more data on the wire actually feel more
responsive than games that are wasteful with data.

~~~
ericflo
> Games that don't optimize and use more data on the wire actually feel more
> responsive than games that are wasteful with data.

I re-read this three times and still can't parse what you're trying to say.
Mind clarifying?

~~~
ijuhygtfhyuj
Flush on full means the data is only sent when the buffer is full. If the
buffer is large and you have an optimized game that minimizes the amount of
data sent then the buffer takes longer to fill up and packets are sent less
often.

Older games that send more data may get quicker response if your throughput is
high but your packets are large

------
light3
There was something cool you could do in older version of counterstrike, you
can tweak the ex_interp parameter from 1.0 to something lower like 0.5, in
this way you have to aim 'behind' where the person was and hit. The advantage
of this is with sniper rifles, when someone moving through a narrow gap the
time is so short that your response time is not fast enough to click the
instant they move through. But with ex_interp you can fire after they've gone
through and still hit, not so fun for the target though, they get to safety
then die :D

------
logophobia
People actually "cheat" using lag compensation. There are players that induce
lag on their system so they can shoot at players on a "snapshot" of the game.
Very hard to detect. Usually when you see people with 500ms ping at the top of
the scoreboard, you know it's probably someone who uses this method. It has
its disadvantages, mainly that opponents are hard to track (they "jump" on
each sync). So it's usually snipers that do this from a distance.

------
coderdude
This is a pretty dated article -- 2001 -- but the basic concepts still hold
up. I came across this a few months ago when I wanted to write some net code
for a canvas game project I was tinkering on. This resource helped.

~~~
zemanel
would you think it would be required to implement client-side prediction, lag
compensation (normalization) and etc on a simple tron-like multiplayer game?

~~~
extension
It doesn't matter per se how simple the game is. If the game mechanics are
sensitive to temporal latency between players then the game can benefit from
these methods.

However, I don't see how a light-cycles game could use any kind of prediction
or lag comp. Since players can change direction instantaneously and at
arbitrary times, there is nothing that can be predicted. And any kind of lag
comp would appear as obvious breaches of the game rules.

~~~
coderdude
See <http://www.gamedev.net/reference/articles/article1370.asp> for an
explanation of what I meant when I suggested he use lag compensation.

There is a lag to tell the server when you want to move and a lag when the
server tells the other player where you moved, so the lag compensation is for
the server to guess where you thought the other player was when you made your
move. This is used extensively in Counter-Strike, and I think it has its uses
here.

~~~
extension
How would that be used in light cycles? Would you see your opponent's trail
jump around as the client prediction is corrected? Would the game let you pass
through your opponent's trail if you couldn't see it at the time?

Lag comp takes advantage of the independence of your gaming experience and
your opponent's. It effectively hides inconsistencies in places you aren't
paying attention to, like where your opponent is aiming. In light cycles, your
actions and consequences are much more tightly coupled to those of your
opponents. There is nowhere to hide the inconsistency.

~~~
coderdude
Don't get me wrong, I understand the stark contrast between CS and this style
of gameplay.

>>Would you see your opponent's trail jump around as the client prediction is
corrected?

The prediction in this game would only be which direction the opponents are
moving in. Between packets the client would continue moving opponents in their
last known direction. Once the client knows better it must change the game
state to the player. If that means one opponent moved several game units in
one direction and must be moved back those several units and then turned in a
different direction then that is what must happen, and yes it will be jarring
to the player, but this happens all the time in online gameplay.

>>Lag comp takes advantage of the independence of your gaming experience and
your opponent's. It effectively hides inconsistencies in places you aren't
paying attention to, like where your opponent is aiming.

I'm not sure I actually agree with this statement. Client-side lag
compensation as far as I understand it (or at least how I'm describing it) is
to allow the client to predict what is going in-between server updates.
Server-side lag compensation takes into account the latency of each client and
attempts to give a fair assessment of each player's actions based on what they
must have been shown by the server at the time.

>>Would the game let you pass through your opponent's trail if you couldn't
see it at the time?

I suppose it depends on how long that trail existed. This is certainly a
difficult problem when it comes to a Tron/snakes/nibbles kind of game online.
I do see where you are coming from here with the difficulty of deciding who or
what should take precedence. That is the issue one will always have when
employing these techniques and I think it would require some bit of
experimentation to get right.

~~~
extension
By the conventional terminology (which could admittedly be less ambiguous)
"client prediction" is where the client shows the player a locally predicted
present game state inferred from stale authoritative information. The client
guesses what is actually happening right now based on what it knows was
happening some time in the past, as told by prior updates it received from the
server. This works if there is a lot of temporal continuity in the game, such
as there is when the laws of physics are obeyed. Sources of entropy, like
player input, can't be predicted and so that is where inconsistencies will
appear.

"Lag compensation" is where the server accounts for client latency when making
certain authoritative game logic decisions i.e. "did a bullet hit a target
y/n"? Essentially, it decouples the _when_ and the _where_ of the event. So a
target can be hit by a bullet _now_ but the hit took place _where_ the target
was some time in the past. Since that would generally feel ridiculous to the
player, it can only be done in very particular situations where the event is
mostly entropic and instantaneous, and therefore unpredictable (e.g. a player
firing a bullet with infinite velocity) _and_ where the inconsistency is
unlikely to be noticed (because you typically aren't paying much attention to
where other players are aiming).

The lag comp described on that page you linked to is only for player vs NPC,
where the NPC is totally predictable and therefor always appears in the same
place to all players. If you tried to lag comp a slow moving projectile with
player vs player then the projectile would have a curved path, following the
target around as they tried to dodge it. It would give a blatant unfair
advantage to lagged players.

I don't see any lag comp options for light cycles since your only real options
for bending the game rules are a) letting players pass through walls/crash
into walls that aren't there or b) moving players/walls around retroactively,
both of which will appear obvious and unfair.

------
quadhome
The client/server separation for prediction never made sense to me. The
article notes the trust and cheating aspect, where a client could lie about
whether a particular player was hit. But, since the authoritative information
about actions in the time sequence are transmitted to the server anyway, it
seems like the server could do post-game validation. If the game actions all
fit the rules, then the results are valid-- otherwise, the cheater(s) stick
out like sore thumbs.

Even a lagging validation could be done. Yeah, your cheat comes off, but
you're kicked out of the game and your team gets penalized.

~~~
potatolicious
That is indeed what happens. When you fire a shot, for the sake of player
feedback the client will determine if the hit was made, and render the game
accordingly.

The server can invalidate that result if it disagrees. This is why _very_
occasionally, in high-lag situations, you might shoot a layer, see blood, but
the player takes no damage.

In this case the validation is being done in real-time, and the prediction is
only ever performed for feedback-critical actions (shooting, movement,
reloading, etc).

~~~
quadhome
Then why not have the network self-organize into its lowest latency form with
the "server" acting as a trusted arbiter / validator?

~~~
potatolicious
This does happen in some games - the Halo series comes to mind. A player is
determined to be the "server" based on network conditions, and the plus side
of it is also that should the server drop, the game will only be momentarily
interrupted and you can select a new player to act as the server.

This doesn't work in all instances - most games using this mechanism are
fairly small in terms of player count, since the server is not of a guaranteed
performance level, the connection its on is probably a home-based broadband
connection at best, and it has to invest a lot of cycles into rendering the
game. For larger games (say, the Battlefield series) the hardware required
makes it such that the system is infeasible. Instead you have extremely beefy
hardware running dedicated servers - headless, non-rendering servers that can
throw every cycle it has into serving the game.

------
clemesha
I have a real-time, multiplayer online game (<http://TheWikiGame.com> \- built
with XMPP + Redis + Django), and I can say it's been one hell of a learning
experience.

The features you build and test on your local machine or private cloud
instance certainly behave differently when you have a bunch of people, with
totally different internet connection speeds, and game-play behaviors, all
using your app at once.

Ahh, the race conditions you never knew you had :-)

------
zemanel
ps.: the valve info came up on a thread about a web based game
<https://groups.google.com/forum/#!topic/nodejs/57Q-Qpg1jto>

------
snippyhollow
Quake 3 engine implements weapons prediction (very well)! back in the days,
every Quaker had his best snaps/cl_maxPackets values in his .cfg. :)

~~~
zandor
Yeah the id Tech 3 engine is still one of my favorite engines. Quake 3, Call
of Duty, Medal of Honour, Return to Castle Wolfenstein and Star Wars Jedi
Knight all ran on it.

Good times.

