4 ms·

Google has a growing track record of ambitious half-measure projects. Game streaming is very appealing to me on paper for competitive games. Compared to the t

Google has a growing track record of ambitious half-measure projects. Game streaming is very appealing to me on paper for competitive games. Compared to the traditional dedicated server scenario, cloud multiplayer gaming could nearly halve the player to player latency.

smileybarry 7y ago
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.
- willis936 7y ago
  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.
  - tmpz22 7y ago
    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.
    - willis936 7y ago
      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.
      - tmpz22 7y ago
        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.
    - imtringued 7y ago
      >You're being downvoted because what you're suggesting is fundamentally impossible and not at all how game netcode works. In theory you wouldn't have netcode. You would just have "splitscreen" multiplayer where each player only sees their own display.
      - smileybarry 7y ago
        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.
  - lmm 7y ago
    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.
TeMPOraL 7y ago
Wait, how is adding more servers into the mix going to reduce latency?
- willis936 7y ago
  I shoot. It takes 15 ms to show up on my screen. My shot then takes 50 ms to make it to a server, which then takes another 50 ms to be sent to an opponent. What the opponent sees and what I see are off by 100 ms. If all inputs were handled by the server then everyone would agree on what they see, but delayed by their latency to the server. Interpolation is exactly that. It has significant error and is a serious threat to low time-to-kill competitive games.
  - clarry 7y ago
    > If all inputs were handled by the server then everyone would agree on what they see You can already have that; no need for streaming. For example, original Quake handles all input on the server and movement feels kinda like skating on ice with the latency. You can feel the latency when you shoot; your gun doesn't actually fire until the server acknowledges it. I've played Quake online somewhat recently, and I absolutely hate how it feels. I can't imagine anyone wanting to play like that. There's a damn good reason why newer engines added client side prediction, even if it makes different players' view of the game inconsistent. Unreal Tournament, up to UT2004, (maybe later -- I'm not familiar enough with newer ones) are similar. I think they added prediction for player's movement at some point, and that alone makes it feel much better, but jump pads (and such) are still unpredicted, shooting still has latency (I can't recall the details; it's possible that your firing animation/sound is instant but actual projectile only appears on your screen once the server acknowledges it). It's great when you're playing with <20ms ping but it absolutely sucks to have little to no prediction with higher ping. I much prefer unlagged Quake 3 engine games, where hitscan weapons hit what you see on your screen (they're latency compensated on the server). Otoh some people argue for Unreal because everything's synchronized and you don't see the ugly side effects of prediction, like getting shot right after you leap into safety behind a corner. Notice that interpolation and prediction are two different things! Interpolation actually increases latency; I turn it low or off in Quake 3. The result is that everyone's movement is jerky (they update when the server sends an update; higher packet rate is better). If you enable interpolation, then their location is going to be interpolated between two most recent updates.
asdff 7y ago
I beta tested googles streaming on aco and it had more latency than online games have now. It's great for single player games, but isn't nearly there for competitive. Imagine playing a competitive game and the textures drop to 144p randomly, and I was testing this software on a fiber connection.
- willis936 7y ago
  I don’t think any service is where it needs to be. Most importantly the servers running the game clients are not the same ones hosting the game servers.

smileybarry 7y ago

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.

willis936 7y ago
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.
- tmpz22 7y ago
  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.
  - willis936 7y ago
    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.
    - tmpz22 7y ago
      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.
  - imtringued 7y ago
    >You're being downvoted because what you're suggesting is fundamentally impossible and not at all how game netcode works. In theory you wouldn't have netcode. You would just have "splitscreen" multiplayer where each player only sees their own display.
    - smileybarry 7y ago
      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.
- lmm 7y ago
  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.

TeMPOraL 7y ago

Wait, how is adding more servers into the mix going to reduce latency?

willis936 7y ago
I shoot. It takes 15 ms to show up on my screen. My shot then takes 50 ms to make it to a server, which then takes another 50 ms to be sent to an opponent. What the opponent sees and what I see are off by 100 ms. If all inputs were handled by the server then everyone would agree on what they see, but delayed by their latency to the server. Interpolation is exactly that. It has significant error and is a serious threat to low time-to-kill competitive games.
- clarry 7y ago
  > If all inputs were handled by the server then everyone would agree on what they see You can already have that; no need for streaming. For example, original Quake handles all input on the server and movement feels kinda like skating on ice with the latency. You can feel the latency when you shoot; your gun doesn't actually fire until the server acknowledges it. I've played Quake online somewhat recently, and I absolutely hate how it feels. I can't imagine anyone wanting to play like that. There's a damn good reason why newer engines added client side prediction, even if it makes different players' view of the game inconsistent. Unreal Tournament, up to UT2004, (maybe later -- I'm not familiar enough with newer ones) are similar. I think they added prediction for player's movement at some point, and that alone makes it feel much better, but jump pads (and such) are still unpredicted, shooting still has latency (I can't recall the details; it's possible that your firing animation/sound is instant but actual projectile only appears on your screen once the server acknowledges it). It's great when you're playing with <20ms ping but it absolutely sucks to have little to no prediction with higher ping. I much prefer unlagged Quake 3 engine games, where hitscan weapons hit what you see on your screen (they're latency compensated on the server). Otoh some people argue for Unreal because everything's synchronized and you don't see the ugly side effects of prediction, like getting shot right after you leap into safety behind a corner. Notice that interpolation and prediction are two different things! Interpolation actually increases latency; I turn it low or off in Quake 3. The result is that everyone's movement is jerky (they update when the server sends an update; higher packet rate is better). If you enable interpolation, then their location is going to be interpolated between two most recent updates.

asdff 7y ago

I beta tested googles streaming on aco and it had more latency than online games have now. It's great for single player games, but isn't nearly there for competitive. Imagine playing a competitive game and the textures drop to 144p randomly, and I was testing this software on a fiber connection.

willis936 7y ago
I don’t think any service is where it needs to be. Most importantly the servers running the game clients are not the same ones hosting the game servers.