This reminds me of the work John Carmack did when he was writing QuakeWorld, which in 1996 was quite playable on a 56k modem! He started off predicting 300ms of lag on the client side, but it was too glitchy when the correction came in. He landed on a more conservative strategy, and his writeup is a touchstone of Computer Science lore for me:
I wonder if you could design a game around this by drawing BOTH the predicted motion and a ghost image of the last known verified server position of players, and then deliberately introduce 500ms of latency. The gameplay would then be about tricking your opponents into thinking you were going somewhere you're not.
This depends entirely upon where you're connecting to, and from. For example, I can't connect to us-east-1 servers with under 50ms of latency, because I'm out in the rural west, and my connections run a thousand miles south before getting on a good east/west backbone. Spikes are not uncommon.
> we have realtime games with lag compensation that make that connection instant
When the prediction algorithms are correct. When they're not, you start seeing some uncanny behavior that you can't predict or compensate for (dead-on shots missing, actions being rolled back, etc).
Are you teaching game networking to Glenn Fiedler? You probably learnt it from him, or someone who read his articles!
Now seriously: client side prediction is not magic and it always introduces its own problems, like getting killed after getting into cover (especially in low TTK shooters) or the opposite: bullets not registering when if they hit in your screen.
Client side prediction is sleight of hand. It will never replace actually perfect network conditions and will still feel better the lower your latency is.
Client-side prediction does a very good job of hiding the network latency. Granted a lot of games run their servers at lowish ticks/sec (people do complain though) which is 30ms worst case at 32tps.
You mean the networks in particular that you use? There's a lot of varied network equipment out there. Glenn wrote this article at least 8 years ago and for the types of games he works on (realtime 64-player online FPSes), I'm sure TCP still wouldn't work as well as a UDP solution.
> The trick is to hide the lag with animations
That's an understatement. A significant amount of work needs to be done with client-side prediction in order to give the appearance of playing in real time consistently with other players.
> I think google, facebook, and world of warcraft use tcp for their real time apps
Which real time apps are you referring to? In the context of this article, Glenn is talking about soft realtime systems (30 hz updates or more). There aren't any user-facing apps from facebook or google that I'm aware of that I would call "real time". For WoW, timing is less critical than an FPS and obviously TCP works well for them.
Yup, as someone who wrote action networked games when I was in gamedev this is pretty on point. You're not going to get any chance at latency correction so jitter(which tends to be bursty) on the connection is going to really hurt you.
I remember reading a lot by John Carmack about network latency for when Quake went online. It seems like cloud based apps (especially games) could learn a lot from network game designers.
This is something I've read in networked game literature: players react far better to consistent and high latency than to inconsistent and low latency, even if the averages are lower in the latter case. (It might even have been a John Carmack article).
lag/latency most likely due to combination of high/increasing traffic plus imperfect arch/code. but traffic is a Very Good Problem to have for a game, especially if his revenue comes from advertising, and is passive.
if I were him I'd focus first on identifying & fixing his bottlenecks, and consult a cheatsheet list like this to see if he's overlooked anything:
The server is located in France and it's all TCP (because WebSockets) so the lag might get pretty bad. Like you say, client-side prediction would help a lot with hiding that. Right now I'm just doing some interpolation on the position (no extrapolation at all) so any latency > 200ms becomes quite noticeable.
If you're, say, playing a competitive FPS with a team (e.g. Counter Strike), you will obsess about game mechanics and latency and input lag, because after 10 hours proficiency you'll be able to notice if you're getting packet loss, if your spouse is using all the bandwidth and your crappy router with bufferbloat adds additional latency.
If you really are sending packets every 20ms then that is the equivalent of 50fps - I suspect that if you log out how often you are getting packets from the server you'll find that you are not actually getting packets at that rate, or the jitter on the packets is unacceptable.
Client side prediction doesn't have to be very clever. You can get good results with very simple algorithms.
I'm not an expert in games, but even my simple code worked pretty well.
From what I remember I was sending user inputs from the client side every 0.2 seconds - and from the server once I had the client prediction in place I could get away with very slow updates from the server and still have the illusion of 60fps.
I also go to a game developer meetup. This developer was actually delaying all of the players, so that 40ms was their typical latency, no matter what. The developer had done some research with his multiplayer game, and concluded that most people didn't notice under 40ms round trip.
Some of the hardcore FPS players in the group could definitely tell!
This comment doesn't really show a great understanding of the problems that gamers experience when it comes to latency.
Distance / the speed of light has nothing to do with it. If you're in the US connecting to a US game server, neither you nor the game developers have control over what path the internet will choose to send your traffic there.
Your packets could be blocked by other packets being sent first. You could experience packet loss, which will create a rubber banding effect in game. You could experience a variation in packet delivery time, which makes it hard for client-side prediction to work effectively.
These issues frustrate gamers to the point where they'll stop playing if it's bad enough. Lag is hated by games and developers, so this problem is super worth solving. Imagine what it'd be worth to Epic Games to reduce their player churn by just 0.1% monthly... probably millions! This is a big market.
If you read up on Network Next, they solve this problem by sending your traffic on private networks where you do have more control over delivery and consistency, rather than public networks where you don't.
I'm really excited to see Network Next improve gameplay, and it's 100% not a non-starter.
Client side prediction would help a lot. Online racing games seem to easily handle 300ms latencies.
I fully realize that the difference between virtual racing games and real live humans in hunks of metal is massive. I'm just saying that work on dealing with latency in situations which are more predictable and have larger margins for error than high precision operations have been worked on ever since QuakeWorld.
reply