[jephir]

> As a player (and a programmer -- but mostly a player), I'm concerned about the articles conclusions about the value of prediction, and the recommendation to avoid position popping by applying smoothing -- to quote the article, "it ruins the virtual reality of the game".

I agree, predicting remote objects causes more problems than it solves. Any remote player input that affects the object causes noticeable position popping when the local client receives the update.

The Source engine has a better solution - instead of trying to predict remote objects, delay rendering by 100ms and interpolate the received updates. This makes the position updates appear smooth without any stuttering. However, now the client lags 100ms behind the server.

The server has to "undo" this lag when the player wants to execute a request (like shooting). It does this by rewinding the world state by 100ms + client ping when executing the request. This makes it so that a client's actions appear to execute without any lag on their view (i.e. they don't have to shoot ahead of their target).

This causes some temporal anomalies, for example, players can shoot you around corners because they see your position 100ms in the past. However, most players seem to prefer this over having to constantly shoot ahead of their targets to compensate for prediction errors.

[Dove]

That's one way of doing it! I suppose it all comes down to what your players expect.

Mine viscerally hate lag, whether they can see it or not -- but especially if they can't. I think if I built 100ms of lag into the client, I'd have a mutiny on my hands. ;)

But I do remember having a pleasant experience in TF2. Source probably is a good source of inspiration, those Valve guys know their stuff. :)

[Dove]

A further thought: this is another of the fundamental tradeoffs in doing this sort of design work.

In a laggy environment, you can either have dodging work 100% correctly client side, if you dodged it, it didn't hit you, no questions asked . . . or you can have aiming work that way, if you hit it, you hit it, no questions asked.

You can have one or the other. You cannot have both. (And in a server-based setup, you generally get neither).

And I think which you choose (or which you choose to emphasize, if you give both up) will depend on what sort of game it is. In an aiming-heavy, mostly fast-weapon or instant-hit FPS (like maybe DOOM), you should pick aiming. In slow-weapon, slow-ship, combat-flight-maneuver-oriented Descent, the original developers correctly picked dodging.

Which highlights something else: When doing netcode for an FPS, your engineering decisions are game design decisions. Never overlook that.

[lotharbot]

> "When doing netcode for an FPS, your engineering decisions are game design decisions."

Of particular note: your engineering decisions directly affect which tactics are viable and to what degree. Can you wait for the last instant to dodge, or do you need to dodge a shot well before it reaches you? Can you kill a laggy player before they have a chance to react, or can they dodge your shots long after they appeared to hit? Can a player with a better internet connection control an area simply by virtue of their shots taking effect sooner (destroying an opponent, or at least wrecking their aim, before their shot gets counted as having fired)?

This came up in the Descent series with a change to the networking model between Descent 2 and 3. The top competitive communities didn't consider Descent 3 to be "real Descent" because the move to client-server (as well as physics changes) changed the gamescape so drastically.

[Disclosure: I'm married to Dove, and we have been playing Descent together for 16 years.]

[graedus]

Great thoughts in this tread, thanks.

In Battlefield 3 and 4, DICE chose to implement the latter option (aiming and hit detection are clientside, no questions asked). The tradeoff - and I'm sure you'd agree there is always a tradeoff no matter how we deal with latency - is that as the person being shot at, you'll frequently die some fraction of a second after getting behind solid cover, because you weren't behind cover just yet on your opponent's screen when he shot you.

This is certainly frustrating and frequently complained about, but I think it's the lesser of various evils for these particular games.