4 ms·

Not op, but I think the biggest miss in cloud gaming is no one developing cloud first multiplayer games. Currently in any kind of client-server multiplayer gam

Not op, but I think the biggest miss in cloud gaming is no one developing cloud first multiplayer games. Currently in any kind of client-server multiplayer game out there you face n+1 game states (n is the number of players) and a lot of the art is in how to reconcile these. The n+1 is due to most games implementing some degree of client autonomy (e.g. in movement), and the reality of network round trips from each client causing everyone to be slightly out of sync. A concrete example of how this affects players is the experience of being shot after narrowly escaping behind cover in an FPS. Cloud gaming substitutes reconciling these n+1 simulations with some input latency for each player. I think this could produce some qualitatively better experiences for certain games. In particular, Fall Guys is a recent game that I think would play better as a cloud first experience. The interaction between players in Fall Guys is grabbing other players who are near to you. Due to the network latency many players have the experience of being grabbed by folks nowhere near them. A cloud first version of the game would eliminate this problem that simply can’t be solved otherwise.

LegitShady 6y ago
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.
- Inityx 6y ago
  The conceit here is that rendering happens server-side, so visible game-state latency is replaced by input latency.
  - ColFrancis 6y ago
    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_on_a_288_network_.php https://www.gamasutra.com/view/feature/131503/1500_archers_o... [2] https://www.youtube.com/watch?v=Z9X4lysFr64 https://www.youtube.com/watch?v=Z9X4lysFr64
muststopmyths 6y ago
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.
- SXX 6y ago
  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.
camel_Snake 6y ago
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/ https://www.thegamer.com/outcasters-interview/
kmeisthax 6y ago
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.
- jowsie 6y ago
  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.
hombre_fatal 6y ago
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.
- benhurmarcel 6y ago
  A lot of people have a much better latency than 40ms.
  - pinteresting 6y ago
    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.

LegitShady 6y ago

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.

Inityx 6y ago
The conceit here is that rendering happens server-side, so visible game-state latency is replaced by input latency.
- ColFrancis 6y ago
  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_on_a_288_network_.php https://www.gamasutra.com/view/feature/131503/1500_archers_o... [2] https://www.youtube.com/watch?v=Z9X4lysFr64 https://www.youtube.com/watch?v=Z9X4lysFr64

muststopmyths 6y ago

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.

SXX 6y ago
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.

camel_Snake 6y ago

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/ https://www.thegamer.com/outcasters-interview/

kmeisthax 6y ago

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.

jowsie 6y ago
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.

hombre_fatal 6y ago

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.

benhurmarcel 6y ago
A lot of people have a much better latency than 40ms.
- pinteresting 6y ago
  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.