The joystick and display device are just the clients now. You have the same problem just moved around a bit. Without the benefit of being able to use techniques to hide latency, such as client side prediction.

No, the client is still the client. It's still a big bunch of stateful code, but now it's running on the LAN with the server and can't have its bits fiddled by the customer. All that code where the server fastidiously checks the client's untrusted state updates goes away, replaced by a much simpler layer that sanity checks the inputs. All that code where the server has to rewind and replay inputs to deal with late-arriving client state updates goes away (assuming your game isn't cross-DC). All that code where the server is protecting clients from other clients, sending down corrections and fixing up the world so it maintains some semblance of causal order, goes away.

At my day job I'm working on a AAA multiplayer game, and making a properly server-authoritative game with significant client-to-server latency mitigation imposes serious costs in dev time and complexity and security review process. And now, at least in theory, they mostly disappear.

The input/display lag problem is different from what we have now. It's new. We don't, of course, compensate for lag from input to client. (Between client and server, yes, but that's actually a different beast.) And yes, you won't be able to do much about it. You'll be relying on Google to keep your latencies down. They said they're deploying to 7500 nodes, so there's hope. Time will tell. I'm hopeful a lot of people will be reporting single-to-low-double-digit latencies.

But this is much, much more than just moving around the same problem.

Sorry but I just don't see it.

I'm used to designing systems and games that work in 100ms+ latent environments since that's what you see in production(or try mobile where it can be 2-5x that).

We were doing 250ms ping times back in '99 with games like SubSpace and the like where you had a predictive game model/design. Yes you lose the overhead of designing for latency because it just won't fundamentally work in those scenarios.

I agree that it will all hinge on what kinds of latencies we see. If Google can produce the same kinds of latencies it does to 8.8.8.8, it's definitely got a shot. Mobile's an even bigger challenge, but I've seen wire-competitive latencies from 5G, so I think there's hope there too.

This does, however, leave VR high and dry. Wonder if they have any ideas about that angle.

Getting a consistent latency to their edge servers is going to be tricky.

Wifi for instance is completely out. All it takes is someone turning on the wrong blender/micowave/power adapter and just the smallest bit of RF pollution will put you into unusable territory. Gets harder as your population density rises.

You can already see this with in-house streaming today. I can stream Netflix but my local LAN XBOne streaming is pretty unusable for things like Monster Hunter.

As your population density lowers the chance of you having the sub-30ms latency w/ 0% loss decreases significantly.

Like I said in the root, they'll able to get this to work for non-action(~200ms window) singleplayer titles, the idea that you could use this for multiplayer is laughable.

I'm seeing anecdotes elsewhere in this thread that wifi worked very well for some testers.

Will it be a worse experience than a 2080 Ti on your desktop? Sure. But will Stadia be good enough to win over the expense and hassle of the alternative? Maybe!

Regarding your last point, I'm not sure Id would stake their reputation on delivering a game that is going to be "laughable" on Stadia. They might know something we don't.

We'll see how it works out.

>And when all the clients and the server are sitting in the same DC?

But what do you do when they don't? This can happen in multiplayer games with low population or during "bad times".

You might have less trouble because latency is more predictable, but you still need the whole rewind stuff.

I predict a lot of game teams developing new IP for Stadia will impose a single-DC-match requirement, because the time/complexity tradeoff of implementing all that stuff won't be considered worth it. Then, if their game fails, maybe they'll blame that decision. :-)