Testing Google Stadia [video]
youtube.com
youtube.com
Stadia should, theoretically, be like playing an online multiplayer game with no lag compensation. Your inputs are received and processed, and the output is sent back at the network delay; this is going to be at best three to four frames late (60 ms on a good day, with 16 ms per frame at 60 FPS). Unless you run multiple instances of the game at the background and do input prediction at different modes (much like CPU branch prediction, I suppose), you will encounter this significant lag. Even with prediction, the experience just cannot be smooth.
I can see a lot of games to be playable with Stadia.
However anything competitive PvP is a no-no. Playing TF2 I could tell whats is server ping with accuracy of around 30ms by using projectile weapons. Adding best case scenario 60ms is a big deal.
Stadia simply can't ever compete with local setups. Currently multiplayer game will play with your local input and then resolve any inconsistencies on server side (this is the reason you were 'killed' when clearly behind a wall). While the resolution of the local input might differ to server the responsiveness feeling of local input is part of good play experience.
There are corner cases for some games (RDR2 - all actions have long unskippable animation) or game play style racing games (input lag is hidden by the 'responsiveness of a car').
All that said, its still very impressive how low they got. I was expecting no less then 100ms.
Nevertheless something like Stadia could probably catch on easily for things like mobas and mmos that don't rely as much on every single frame getting to the screen asap. Assuming the economics work out, that is
1) It's only Stadia users against each other;
2) People who are directly connected to the Google machine still have an advantage over the Stadia players.
The first is... OK. You'll be fine, the playerbase will be tiny and you won't be able to play with your non-Stadia friends.
The drawback for the second one is a little less obvious, but the result is that the Stadia users will not benefit from the client-side lag compensation measures that Source (TF2's engine) implements. Most people in this thread miss the fact that in multiplayer games you're always ahead of where the server thinks you are, because you're playing on your timeline, and the server perceives you at RTT/2 behind. When you think you perform an action, the server travels back in time to determine whether how it played out (as opposed to actually executing your actions in what is relatively RTT/2 later).
What is visible and perceivable is the lag effect and it is constant and unavoidable.
The client - server differences are handled differently depending on the game. AFAIK there is a trend of 'attacker' advantage ie client input is more favored when resolving delta, incentivizing active play vs camping. In that case Stadia fares worse then local.
Trading kills can theoretically happen, but it's like lightning. If it's happening a lot there's something wrong. My guess is the fuzzy calculations in the earlier mentioned games err on the side of killing everyone.
IDK the techniques Stadia is actually using but MS has a prediction and local warping method. Consider that when moving or turning in a fps, in most frames you're making the same input as the previous one. A statistical model, noticing walls and enemies etc can do better. So if lag is n frames, they predict what your input would be pver those n, and send the result.
Misprediction is still common, so they do local warping: locally transform the last received frame in accordance with the local input. Zoom for forward, pan left/right for turn etc. I think this would look a little like a stablized video, but it's only for a max of a few frames, so not as bad.
The issue is that the stabilisation is not just for a maximum of a few frames, because you're always behind by the amount of frames stabilised/processed/corrected. This would lead to the stabilised video feeling as long as you're moving... which happens rather often when playing games.
Ignoring that, I see what you mean that it's ongoing. But it resets every time a new frame is received, whereas a stablized video never resets from the start.
To illustrate, consider a video with the camera spinning on an axis into the image (like a barrel roll; so the image rotates in 2D). To prevent the subject of the video from rotating, each image must be rotated in the opposite direction. You'd see the frame of the image rotating.
Whereas, with warping, the orientation of the image would reset to level with each actual frame recieved. So the amount of rotation would be limited to a few frames worth - not spinning around 2pi like the stablized video.
Presently, the only defense for Stadia right now is that your average gamer probably won't give a crap if the game feels a bit laggy. We only recently had the stupid ongoing debate with console developers and publishers trying to convince people that 24-30FPS is the maximum that humans can perceive. Luckily that ended with eSports players going for 144Hz monitors and showing that there is an obvious (i.e. noticeable) improvement in reaction times and responsiveness. Hopefully people are convinced that cloud gaming latency does affect the way you play your game, and how much better it feels when you're playing on your own hardware; weaker or stronger it might be than the Stadia server farms.
Of course, there is.
>and even though I was asking people who both tried and watched it they all said that it was not noticeable. I had a hard time believing it, and still can't...
Network latency is highly context-dependent. In the right environment, it could be minuscule. Online multiplayer has been with us for decades now, and in general works very well (even with FPS, RTS, and fighting games, all of which require a high rate of actions) so it is something that can be mitigated. In an online multiplayer game, your local state is updated quickly and the server state catches up (or uses some prediction heuristic) or rolls back client state. I'm sure there are some strategies to mitigate with pure cloud games...
Having said that, a purely server-side streaming solution wastes the processing power of the client, with even a typical phone being a pretty powerful device. Maybe there is a hybrid approach lurking in here somewhere, where some processing is done on the client, and heavy rendering is still done on the server. This lightens the server load and improves latency.
It’s really not noticeable (unless of course you hit a latency spike, which was pretty rare.). It of course requires a fast, stable internet connection. But the reality is that we don’t really perceive a 60ms lag as anything. Or at e very least it’s fast enough that our brain compensates for kt
Also, they found that to get the best performance from it, it sucked down in the region of 20gb per hour of data. Which is a lot for countries with capped internet allowances.
Also I suspect this is not something that will sit on any CDNs due to the specialist nature so this is going to transit much further than the ISP's edge.
Equally, because you know so much about the scene, there are many more opportunities to do smart video compression - however, those would be extremely difficult to take advantage of.
Ultimately they could cache textures, models etc. on the client system and only transmit data about the players' locations and inputs. Then the codec would render the game on the client... hey wait.
They could potentially implement something similar to Retroarch's runahead feature, but I suppose it would requires support from the game itself and more infrastructure so probably not feasible...
The upside is using it on a mobile device but to me this doesn't add value, as the network connection outside my house is either a high-latency 3G connection or someone else's unreliable WiFi. And with Remote Play on the PS4 I have similar capabilities.
Yes. The problem with Stadia is Google. Google hates hardware and they pretty much half-ass everything that is even an inch outside of their core competency.
There is something exciting about cloud-gaming, even in the present state ... but to make it a success it would have required Google to make better deals with content providers (maybe turn it into a true Netflix-for-games), and potentially pour some significant resources to subsidize it. For example, they could make the controller/hardware really cheap, subsidize content-provider licenses (so games are available via an Xbox-pass type service, or are half the price of their PS4/Xbox counterparts), or, god-forbid, invest in first-party studios to create original games. But that's not the Google way.
You make it sound like their core products are good.
Search is worse than in 2009.
Ads has been useless for me for years, even when I tried to help..!
Anyone here who buys Google ads, expect to be fleeced for nothing:
There exist ads I want (events, local) , but I never see them.
On the contrary: for years I've seen irrelevant but probably very expensive ads that aren't even remotely interesting but rather insulting.
To be fair, the internet is worse as a whole. Google is at war with SEO and bad actors.
This is not to reduce how bad/evil their ad model has become.
And I don't have any confidence in Stadia being around for the long term. If I buy a game on Steam I'm fairly confident I'll still be able to play it in a decade. If I bought a game on Stadia I wouldn't be confident in the service still existing two years from now.
https://danluu.com/keyboard-latency/
Corporate networks vary.
It’s such a generalisation that it’s easy to argue both for and against.
I can say that the majority of corporate networks will have a higher latency to internet resources than an equivalent home network.
Why?
Well, NAT adds latency, the more there is in the lookup table the longer it will take, even with a beefy cpu on the firewall/NAT device. More complex firewall rules too, will impede. If there is any IPS (intrusion prevention service) on the line then that may add some latency. Then there’s simply the hops that your network traffic would have to take to even hit the border.
Not counting things like QoS rules that need to be evaluated to de-prioritise things like VOIP (which stadia, if it’s streaming using UDP, might even look like to a dumb router).
Most corps also do not just let traffic outbound, if there’s any R&D or risk of leaking then there’s a lot of filtration rules on the line and often that is centralised. I work for a global company and our internet traffic exits the corp network more than 200km from where I’m sitting.
That's why I specified "this specific" corporate network.
>You would need a corporate network that idiotically sent things over the wire to a corporate office on another continent.
There are much more plausible scenarios than that, like packet inspections and side-effects of attempting to MITM any SSL packets.
On the other hand, I got Stadia a couple of days ago, and although graphics work very well, input lag is unbearable. Some streaming users will experience input lag because their Internet connections cannot handle it, but that is not my case.
It's sad because I live in Dublin. Google has servers here. Shadow's servers are in the Netherlands. I'm very disappointed at the level of incompetence that Google displayed on this release. They have enough data centres, money and quality network connections to pull this off properly, yet they didn't. Shadow, a small French company streaming remote Windows PCs, did a much better job running standard Windows games that are not purposefully made to be streamed.
Games do non-trivial amount of processing with relaxed latency requirements: physics, cloth, many particle systems, fluid dynamics, some other VFX like weather / time of day, many parts of gameplay logic. Even some parts of rendering pipeline don’t require low latency, e.g. camera frustum culling doesn’t. Many of these things even run on CPUs as opposed to GPUs, and cloud providers have a lot of idle CPU and RAM resources.
Such a hybrid engine might be OK offloading half of the code to the cloud, while still using local GPU for rendering and dynamic lighting, using assets streamed from server and cached locally. This still requires a reasonably fast local machine, but hopefully less so compared to current game engines.
Very expensive to develop and run, though. Also it may consume even more download bandwidth compared to the streaming video they have now.
I've used it for Prey 2 (finished) and The Witcher 3 (in progress) and I'm really happy with it. It's still in closed beta (although I think it's available commercially somewhere in Asia(?)), but it's a no frills product that does exactly what it says.
There's no platform play, though (like the Stadia integration with youtube and special Stadia dev framework etc), but that's an advantage to some.
And at many places, if it's not a city, you still (in 2019) have to deal with ISPs which offer not much more.
You, my friend, just made a trillion VC megadollars.