The problem is trading server latency for input latency, which is much worse. Most console gamers probably wouldn't mind it as much as they're used to TV latency, but the higher you go in competitive games, input/display latency becomes much more important. And if you count PC gamers it's much more of an uphill battle as display latency there is miniscule compared to consoles & televisions.
> Compared to the traditional dedicated server scenario, cloud multiplayer gaming could nearly halve the player to player latency.
There's still the network latency from your streaming edge to the game server, and yours to the streaming edge. You can just use the same optimized routing to reach the shared game server.
Improving routing or using multi-pathing solutions can achieve a similar result. Things like Haste, which offer optimized routes to supported games and shoot your packets across 4+ of them at once for redundancy, can cut your lag tremendously. Haste is a particularly good example because, at least from my packet capture, it looks like they're partnering with ISPs and putting their edge nodes in ISP datacenters.
The problem cloud gaming would solve is having all players be presented the same game state at the same time. No other topology I know of would have all clients agree on the game state at the same real-world time.
You're being downvoted because what you're suggesting is fundamentally impossible and not at all how game netcode works. You're also ignoring many other latency bottlenecks from controller input, monitor refresh rate, client CPU/GPU, server CPU/GPU, the network, and probably others I'm completely unaware of.
At best Google is handling most of the graphics rendering, but those graphics are still being encoded/decoded client side by different hardware. All the other bottlenecks also remain.
50-250ms latencies are game breaking in many contexts and game genres. Google does not sync these latencies between clients because that would also be game breaking. If you're interested in reading more on these topics checkout some of the gamedev literature for Doom and similar "early" FPS titles. They're filled with fascinating hacks for making clients seem like they are in sync when the truth is anything but.
That means one single machine is rendering the game for all players, and with modern game engines that can reliably scale to maybe 4 players. Even then, that would come at the cost of graphical fidelity compared to practically any other game on the market. (Some modern games get away with it because of distance from the TV obscuring interlaced rendering or checkerboard rendering)
Assuming you build on this by having some unsecured shared state, e.g.: hypervisor shared memory, and all clients rendering their own game -- that means you're now restricting gaming by geographic region. If you do that and segregate players by area, you would fragment the playerbase and eventually kill off the game as any loss of popularity snowballs.
Being downvoted? 0 points doesn’t seem like a largely unpopular opinion. I’m making a high level point. I am aware of the details that contribute to user experience, and latency specifically, but most of them are unnecessary, and even detract from a conversation at this level.
Why do you mention google’s implementation as if it was something I was suggesting would be suitable for competitive gaming? I am suggesting that total player-to-player latency is reduced if all clients and the server are combined into one system.
I find the HN silent-downvote frustrating (when the comment was adding to the discussion), so I tried to offer an explanation for it. I didn't know if you had 0 points or -10.
To the point though, I still think it's unrealistic to completely change game architectures in order for the client to be entirely "dumb". We need client logic for latency interpolation for most multiplayer games (and most games do have a strong multiplayer component even traditionally single player games like GTA).
And I think we've arrived at the elephant in the room: Google wants studios to rewrite their games for Stadia's latency models and that just ain't gonna happen for 100 different reasons, not least of which being that most studios are still on 10+ year old game engines.
With a central-server game all clients agree on the game state (it's the server's state). With a peer-to-peer game you need more complicated protocols, but you still fundamentally end up with all clients agreeing on the game state.
Suppose Player A in San Francisco and Player B in London see each other on their screens and both click the shoot button. Neither of them can know who shot first until a network roundtrip has happened between them - hell, if their timing was precise enough then under relativity it might be physically impossible to categorically state that one was before or after the other. So either each sees (on their own screen) that they have shot first and this is later contradicted for one of them, or neither of them sees their shot being made until after the network roundtrip has happened. That choice and that tradeoff has to be made, and I don't see that cloud gaming makes any difference: either you have latency for everything you do (and whether that latency is between a thin client communicating with the game server or a thick client communicating with another thick client is really neither here nor there), or you will see inconsistencies.
> Compared to the traditional dedicated server scenario, cloud multiplayer gaming could nearly halve the player to player latency.
There's still the network latency from your streaming edge to the game server, and yours to the streaming edge. You can just use the same optimized routing to reach the shared game server.
Improving routing or using multi-pathing solutions can achieve a similar result. Things like Haste, which offer optimized routes to supported games and shoot your packets across 4+ of them at once for redundancy, can cut your lag tremendously. Haste is a particularly good example because, at least from my packet capture, it looks like they're partnering with ISPs and putting their edge nodes in ISP datacenters.