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.

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?

Here's an example of me pinging my router:

  smokinn@ubuntu:~$ ping 192.168.1.1
  PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
  64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=1.24 ms
  64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=1.21 ms
  64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=75.4 ms
  64 bytes from 192.168.1.1: icmp_req=4 ttl=64 time=1.26 ms
  64 bytes from 192.168.1.1: icmp_req=5 ttl=64 time=1.18 ms
  64 bytes from 192.168.1.1: icmp_req=6 ttl=64 time=1.21 ms
  64 bytes from 192.168.1.1: icmp_req=7 ttl=64 time=1.20 ms
  64 bytes from 192.168.1.1: icmp_req=8 ttl=64 time=1.28 ms
  64 bytes from 192.168.1.1: icmp_req=9 ttl=64 time=1.28 ms
  64 bytes from 192.168.1.1: icmp_req=10 ttl=64 time=1.23 ms
  64 bytes from 192.168.1.1: icmp_req=11 ttl=64 time=1.23 ms
  64 bytes from 192.168.1.1: icmp_req=12 ttl=64 time=1.24 ms
  64 bytes from 192.168.1.1: icmp_req=13 ttl=64 time=1.19 ms
  64 bytes from 192.168.1.1: icmp_req=14 ttl=64 time=1.22 ms
  64 bytes from 192.168.1.1: icmp_req=15 ttl=64 time=101 ms
  64 bytes from 192.168.1.1: icmp_req=16 ttl=64 time=1.31 ms
  64 bytes from 192.168.1.1: icmp_req=17 ttl=64 time=1.69 ms

Notice number 3 and 15. I'm not yet sure why exactly it does this, I haven't had time to investigate fully and honestly it's a minor problem since I don't really play games so it's pretty low on my priority list but I suspect it's either bufferbloat or a driver issue.

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.

> 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?

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

If the game doesn't optimize down the total data it sends, then it's constantly filling the buffers, so there's no waiting for buffers to fill which can reduce ping times.

I think op means games that aren't wasteful, i.e. they send a smaller amount of information with less redundance.

To be fair, modern games throw around a lot more data every frame, games such as the Battlefield series[1] would not have been feasible without client-side prediction.

[1]http://en.wikipedia.org/wiki/Battlefield_(series)

How do you know that's true? I'm not saying you're wrong, I'm genuinely curious.

Older games built on the Quake{1,2,3} engines use hardly any network bandwidth. Most Bad Company 2 games have only 32 players, which is hardly bigger than Quake1. What's going on that's so much more bandwidth intensive?

Way more dynamic objects (vehicles, destructible environments) with a much larger playable area (more room for more objects). Usually objects further from the player are updated less frequently (to deal with the sheer volume of objects) but may still be visible to the player, client-side prediction comes in handy here.

Also the need for more detailed positional/vector data for much more complex physics simulation, which also requires both a higher resolution of updates to function realistically. Additionally, fast moving vehicles with more delicate control/handling, such as fighter aircraft, also a require higher resolution of updates so that you can actually fly them without crashing due to the feedback loop of perceiving jerky/delayed movement and input response. Prediction can help to smooth this out.

Additionally modern games use things like physically simulated projectiles (think bullet drop[1]) with collisions calculated using mesh-based collisions instead of simple hitboxes, over much longer distances, so there is a need for prediction as timing is more of a factor. Quake 1, 2 and 3[2] use the 'hitscan' method[3] of calculating whether a bullet hits its target, which is instant and calculates a linear trajectory, which has the side effect of making it easier for players to adjust to lag (basically any difference between the player firing and the hit registering is network lag, and should be more or less consistent).

Finally, two slightly different issues that have become apparent in recent years are automatic match-making and local servers (ie, the game running on one player's console). Auto matchmaking is often fairly shitty, meaning that (on average) players end up playing on servers to which they have a higher ping time than if they had chosen the server from a server browser (something that is sadly becoming rare in today's games). The phenomena of local servers, on the other hand, puts pressure on the total available throughput, rather than ping time, as the player that is hosting likely has more limited outgoing bandwidth than a dedicated server might.

[1]http://en.wikipedia.org/wiki/External_ballistics#Bullet_drop

[2] only for some weapons, a rare exception for the time

[3]http://en.wikipedia.org/wiki/Hitscan

Couldn't you synchronize the beginning states of the game on all computers (including their pseudo-random number generator states), and then the only data you'd need to pass around is user input (keypresses, mouse movements, and the exact times--at least down to the frame--at which they occurred)? Given the initial state, the PRNG data, and the user input, games are completely deterministic, aren't they?

It seems that could pose a security risk to extremely savvy users (as the game state includes things they shouldn't be able to see, like the opponent's units in Starcraft, and one might be able to make a program to inspect the state of the running game client), but I can imagine encryption and obfuscation dealing with that sort of problem with very little overhead.

The problem with your scheme is that to update frame X correctly, I have to have all input for frame X, which is now 200ms ago. Meanwhile, I need to be presenting something to the user now. Prediction is basically a way to deal with the fact that you can't do what you're describing.

Also, don't underestimate your users. Encryption is irrelevant, they'll hack into your program's process space and read the stuff after you decrypt it, and obfuscation is at best problematic for the same reason. For a AAA-class game, assume all users have access to all data on the client at all times and you'll not be far wrong. Sort of how like in the encryption world we just assume that the attacker knows the algorithm already.

never trust the client. but let it do its thing and set it straight if it tries to stray.

Wrong perspective. If you ship too much information down to the client the user will use it to know things they shouldn't. Google "wallhack". The stream up to the server will bear no overt traces of cheating.

wallhack is something you can't get around, a user can always control how their graphics are displayed, hence you can't trust them. You either accept this or change the game.

You can make it harder to do (Blizzard's Warden, Valve's VAC) but people will get around any technical barrier you put up.

Fog of War (maphack) would be a more apt example, you only send the client what it is possible for them to see. Speed hacks are another that can be stopped, the client asks the server if it can move X units, the server responds with how many units the client moved.

I guess this is one of those "in theory, theory and practice are the same, in practice, they are not" kind of things. I don't know of any triple-A game engine that works that way, and it's not for a lack of smart people working on it. I'm sure that could work for a sufficiently simple game engine, however.

RTS often use that approach combined with check sums. They then resend world state when they don't match. However, FPS that use a little state prediction become much more complicated.

Ideally, FPS would run two versions of the game world, what happened, and what the players see, with more information being sent about what happened close to the player helping the version that players see be more accurate. And continuous updating of the version players see based on predictions from the "real" version of the game world. But, getting that working would be extremely demanding and reduce the games ability to do physics in real time etc.

PS: Game developers may be smart, but as a rule they have less experience than you might think. Short burn out cycles keep the industry from evolving.

Thanks for taking the time reply in such detail. Now I'm even more curious about the topic!

Are you actually certain that Quake1 didn't use prediction? I mean, there's this entire part of the Quake source code devoted to it:

http://www.fabiensanglard.net/quakeSource/quakeSourcePredict...

I believe this prediction code wasn't included in the original Quake. It was added later in QuakeWorld which was some sort of multiplayer enhancement for Quake. Please correct me if I'm wrong.

Edit: My bad, this code IS for QuakeWorld. As far as I'm concerned I have no evidence to put forth that the original commenter is wrong in his assessment.

---

You may be right. I'm genuinely asking the guy if he knows one way or the other, as I do not know but certainly am curious. I mean, no lag compensation in the days of dialup? Seems like id/John Carmack would have know better even at that stage. But then again, it could just as easily be that they didn't realize the need for that tech in the beginning.

Internet play wasn't important when Quake was released. Serious gaming was pretty much LAN only, and Quake was the epitome of serious gaming. At the time the graphics and 3d environments alone were the big selling point.

I remember playing that first version over a modem, and indeed there was no client prediction at all. Not just shooting, but every single thing. You press forward, wait 300ms before anything happens, you switch weapons, wait 300ms. Even basic things like running and timing a jump over a small gap were extraordinarily difficult. But it was still kind of fun for the novelty of it, at least until somebody on a T1 or ISDN joined at which point you simply died before you even saw the enemy (ie. you saw them before you saw yourself die, but by then you had in fact already died on the server).

There was no prediction in NetQuake. The main reason for QuakeWorld was the addition of client-side prediction. It was pretty controversial and many people stayed with NetQuake.

Even back then many people (including id software) had ISDN, T1s, or college connections that had the kind of latency most people have today.

This was also in the days when LAN parties and LAN events were much more popular.

Qwest has interleave on for DSL which means my first hop is easily over 40 ms so a minimum ping of 60-80 is rather likely for me.

I don't know if the same holds true for their fiber but I'm sure interleave is common among DSL providers. Cable also suffers from neighborhood overselling where in peak hours people get ping times in like 200-600 ms when they are likely to play.

I don't know if this problem will be fixed soon but I think prediction is still necessary (or more so required) for a large population.

This may just be limited to American broadband services though, and I'm sure larger cities may have less of a problem.

Sure, when everybody has connections of 20-40ms this prediction is not much of a feature. But back in the days when everybody were on modem connections with 120ms latency, this was important. It means you don't have to physically aim 'in front' of where the target is moving towards, this may not be an issue with automatic or AOE weapons, but if you're trying to use a sniper rifle this can be pretty hard.

quake3+cpma or quakelive (which uses cpma netcode) are better - very good at low latencies while also being very good up to 100 ms (which makes competitive intercontinental matches a realistic possibility - if you're not rat already).