The thing you're missing is that the point of client-side simulation and lag compensation is simply one of UX. It makes the game playable.

> Cloud gaming substitutes reconciling these n+1 simulations with some input latency for each player.

You're just pitching the naive networking model that every developer starts with (because it's trivial) until they realize how horrendous it is to wait 100ms on every single input.

Also, it's not "some input latency", it's the full latency of the entire round trip. From input to server (40ms) and then video to client (40ms) just to see how an action you did 80ms ago panned out.

You've eliminated none of the trade-offs, just exchanged one frustration (dying even though you shot someone before they shot you) with another (watching a delayed video feed of them shooting you while you wait for your input to cross the network).

There's a reason why client simulation is ubiquitous. Btw, lag compensation is really hard and nobody would want to do it if they could get away with the naive networking model.

A lot of people have a much better latency than 40ms.

There is more to latency than just the ping to the server.

The raw controller input latency / controller polling rate.

The time it takes for your packet to get to the server.

The number of packets per second you're sending to the serve (e.g. 100pps).

The server processing time per frame.

The server frame rate.

The time it takes for the packet to get back.

The frame rate of the client machine.

Whether Vsync is enabled (more latency).

The time it takes to transfer a frame of rgb data to the monitor.

The monitor frame rate and processing time per frame.

The pixel response time of the pixels on the monitor.

If we're doing cloud gaming. we also need to add latency stages for encoding and decoding video and how long it takes to download each frame of video.

By simulating everything client side you remove a ton of stages in this latency pipeline.

This is actually one of the selling points Google brought up at the original Stadia announcement: you can't pirate or cheat in Stadia games since it's just an interactive video feed.

Of course, most people who play games don't like that - including myself.

You definitely can cheat with Stadia, the earliest public Overwatch aimbots were just AutoHotKey scripts that detected pixels on screen and would adjust your aim so as to not make you look like an obvious cheater.

The MMO programmer in me fantasizes about making yet another MAG-like (ps3-era shooter with upto 128 players) game. That kind of thing would be so much cleaner to do on a completely server-side platform.

However, a large game like that would need a large budget to back it. Without Stadia being more popular I don't see anyone throwing all their eggs in that basket. Because it could only run on Stadia and nowhere else.

One way to mitigate risk would have been to build for both Luna (Amazon) and Stadia. But neither are very popular, and one is Windows-only while the other is Linux-only. So my risk would actually double, not mitigate since I have to develop for two platforms.

I'm ignoring xCloud since it's just a bunch of Xboxes and no thanks.

For smaller, mid-size/indie studios which are not building a massively multiplayer game, I just don't see the up side of making a Stadia-only game. They wouldn't be trivially portable to other platforms and players have learnt to live with network latencies.

So, unless a Google-owned studio does it, I don't see truly cloud-first multiplayer game happening. Assuming that's what you meant by "cloud first".

OTOH Ubisoft does ship their games on Stadia and I'd be curious to know if the experience in, for example, The Division 2 is any better. Even if the game doesn't scale the number of players in an instance, they should still get some benefit of being on Stadia. It doesn't seem to be a very popular mode in the game's subreddit though.

You know that PlanetSide still exist right? It's has it's flaws, but it quite playable even while being heavily client-sided. Also hardest issue for FPS games are aimbots and not even Stadia can solve this.

The recently released 'Outcasters' is the closest thing we've got to what you describe so far. I read an interview [0] recently by the devs describing their experience making the game on Stadia.

[0] https://www.thegamer.com/outcasters-interview/

How is this functionally different than any other game server dealing with player game states? Players would get even more warping and inexplicable behaviour as their state differed from the server state. You would just as likely get the same warping in Among Us as the game arbitrates the various players' states.

The conceit here is that rendering happens server-side, so visible game-state latency is replaced by input latency.

Many RTS games have already done this in a traditional client rendered setup with deterministic lockstep (e.g. [1]). The basic idea is to have an input at time t which has a fixed delay until t + x. During [t, t+x] everyone syncs what actions they will take, and so everyone renders the exact same state. Of course, if this sync fails then the game will stutter for everyone, unlike in the stadia case, and it has pros and cons for various types of game. It was largely rejected for action games in the past. The trick is you need to specify the minimum latency that everyone must get under for it to run smooth. In the server-rendering case you would be locked to the renderer's region and would have people with better internet having a strong advantage.

If you're interesting in this sort of thing, check out [2] which goes into depth on how to synchronise game simulations in a bunch of different ways.

[1] https://www.gamasutra.com/view/feature/131503/1500_archers_o...

[2] https://www.youtube.com/watch?v=Z9X4lysFr64