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.<p>Most broadband connections (in the US) are really quite low latency and free from packet loss, especially to servers that are nearby (~800 miles).<p>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.
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
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.
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.
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.<p>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.
I have a real-time, multiplayer online game (<a href="http://TheWikiGame.com" rel="nofollow">http://TheWikiGame.com</a> - built with XMPP + Redis + Django), and I can say it's been one hell of a learning experience.<p>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.<p>Ahh, the race conditions you never knew you had :-)
ps.: the valve info came up on a thread about a web based game <a href="https://groups.google.com/forum/#!topic/nodejs/57Q-Qpg1jto" rel="nofollow">https://groups.google.com/forum/#!topic/nodejs/57Q-Qpg1jto</a>