191–200 of 577 posts
So, who wants to make a bet on how long this "experiment" will last? I'm thinking 2 years before Google gets tired of it and abandons it, and another year before it's taken behind the shed.
Earlier quoted context omitted.
I am a "gamer", I have a 2080Ti and I hope it's the last 1500$ gaming equipment I ever have to buy. It sits idle 95%+ of the time and it is tied to only one of the all the screens in my house. I want this to work.
Why is it tied to only 1 screen? You can use Steam or Nvidia Shield to stream to just about any screen or tablet in the house and it works great. My gaming system is headless and I play all my games streaming to one system or another.
I really hope the latency we've seen in the live demo was due to the venue's poor internet connection because otherwise this will make some games unplayable. They mentioned that Doom Eternal will be available and that it would be a good benchmark for the service's latency but I'm waiting to see some independent reviews to believe it. Also I don't really understand who's the target audience for this, I doubt people wh…
Latency: Project Stream has been in beta since January, and there are a lot of testimonials out there. Other than fighting games and fast pace shooters, the latency seems to be imperceptible, assuming a good connection. Target audience: Probably people who used to own consoles/gaming rigs, but no longer do for a variety of reasons. The fact that you can play anywhere and on any device (chromecast, phone, laptop), mak…
There are certainly games out there which would respond poorly to latency and jitter. Play Hollow Knight or Dark Souls, but randomly jitter your inputs by 10ms to 20ms here and there, and that would make it far more frustrating experience.
Its bad enough that those punishing games can kill you quickly with a single mistake. But when you're fighting the controller and the lag, its that much worse.
I think streaming would be definitely fine for games like RPGs, or slower-paced adventure games (ex: Skyrim). But this will never be acceptable for Cuphead, Overcooked, Hollow Knight, or Touhou (or Jamestown). I'm willing to be proven wrong of course, but I've generally felt that even TV-lag is enough to make me rage-quit some setups when playing these games...
And TV-lag is consistent. WiFi based internet lag is jittery by nature. The question of what to do with dropped packets or delayed packets is an important design choice, and I don't think there's a correct answer for these twitch games like Cuphead.
---------
Fighting game players are so crazy about latency that they don't even use local Bluetooth controllers (!!) The serious fighting game community will likely never accept something like this solution.
The more casual, but still relatively twitchy, "hard games" players (Cuphead) is what I'm curious about. Whether or not the latency is acceptable for that community.
Some may remember an earlier streaming game service, OnLive, that crashed and burned spectacularly: https://www.theverge.com/2012/8/28/3274739/onlive-report plus HN discussions here: https://hn.algolia.com/?query=onlive&sort=byPopularity&prefi... I saw the OnLive demo. It was very slick, and the concept seemed more than viable, it was inevitable.
OnLive was both before the Cloud era (where they manually had to maintain many points of presence that were near consumers and they didn't have the money to do it near what Google, Amazon and Microsoft are able to do) and before GPUs were really mainstream for in normal data center servers to the scale this type of service requires.
> the company had deployed thousands of servers that were sitting unused, and only ever had 1,600 concurrent users of the service worldwide
They were burning through all of their money because they highly overestimated the audience. That's one of the main problems the cloud was made to solve.
Some may remember an earlier streaming game service, OnLive, that crashed and burned spectacularly: https://www.theverge.com/2012/8/28/3274739/onlive-report plus HN discussions here: https://hn.algolia.com/?query=onlive&sort=byPopularity&prefi... I saw the OnLive demo. It was very slick, and the concept seemed more than viable, it was inevitable.
OnLive was both before the Cloud era (where they manually had to maintain many points of presence that were near consumers and they didn't have the money to do it near what Google, Amazon and Microsoft are able to do) and before GPUs were really mainstream for in normal data center servers to the scale this type of service requires.
Earlier quoted context omitted.
Yeah, but they control all of the platforms to make this work. With Android, Chrome, Chromecast, Youtube and GCP they have all of the pieces in place.
I wish anti-trust was a thing.
Earlier quoted context omitted.
This comment has gotten so predictable and tedious on this site; I really don't get it. Google launches products. Some of them fail. That's life. Depreciation schedules for cloud services are one thing. Consumer products are another.
I think if we added them up, probably the majority of Google products have failed, no? It’s unusual.
Earlier quoted context omitted.
And when all the clients and the server are sitting in the same DC? Now you can program your clients and server like they’re all on a LAN. And now you can trust the client. (The client, not the inputs.) Those are huge reductions in complexity. This makes delivering good multiplayer easier, not harder. But I do agree that input/display latency is going to be a thing. Results may be highly variable and you’ll probably…
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.
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.