[vojant]

This is really cool, after watching this demo I wonder how the future of gaming might look like, e.g. we could pay subscription for a game and remote machine to run game on. This way even with cheap laptop we could play AAA games remotely. No more issues with hardware, drivers fps.

[jaymzcampbell]

This is very much what OnLive where doing a few years back - I had a subscription for a while but never used it as much to justify it. They would have some problems from time to time but for a casual gamer like myself that only had an ancient and linux-only laptop it worked surprisingly well.

They're since defunct, Sony picked up their assets end of April this year (https://en.wikipedia.org/wiki/OnLive).

[bduerst]

It's essentially thin client gaming, right?

With the roll out of more fiber networks, this could be a reality (assuming you still had enough host locations to reduce latency).

[vojant]

I have never using OnLive, did they support playing via browser? Browser solution is key to this as almost every device support modern browsers capable of ruining OP solution.

[xmodem]

They had Windows and OSX apps, as well as an iOS app. Onlive started in a time before browsers had the features needed to make this possible.

[WorldWideWayne]

The browser is the key to what? Doing stuff in the browser?

It's certainly not the key to getting a game on every device. I can't think of one browser game that people play on their devices. Even Words with Friends, the simplest 2D game you could think of, is not used from a browser - most people run the native app for that.

[vojant]

>It's certainly not the key to getting a game on every device. I can't think of one browser game that people play on their devices. Even Words with Friends, the simplest 2D game you could think of, is not used from a browser - most people run the native app for that.

Because of performance, but streaming games solve this problem. Full screen browser wouldn't be any different than native game client.

[tomf64]

You may have seen this before, but if not it would probably interest you: http://lg.io/2015/07/05/revised-and-much-faster-run-your-own...

[vojant]

Yes I have seen this one, but it wasn't browser based. Somehow browser based solution looks much better.

[tomf64]

It definitely does! The main point of interest for me would be instant cross-platform support, although it's nice to not have to install a client too.

[icebraining]

OnLive has been offering that service for five years (they got acquired a few months ago by Sony).

[ekianjo]

Are you sure? I thought Sony bought Gaikai, which is basically similar to OnLive - but a competitor service.

[paulhodge]

Sony did buy Gaikai, and they have been using their technology in a few PS4 services.

OnLive had a pretty aggressive trove of patents, and when OL finally shut down, Sony bought their patents. So the company wasn't really acquired, it was just a fire sale.

[icebraining]

From onlive.com: "Sony has acquired important parts of OnLive. Due to the sale, all OnLive services were discontinued as of April 30, 2015."

[ekianjo]

Got it. Wonder what happened to Gaikai then.

[sosborn]

Acquired by Sony in 2012.

[ekianjo]

As mentioned above, I'm well aware of that. I am wondering why they needed OnLine since they already had Gaikai.

[ekianjo]

> .g. we could pay subscription for a game and remote machine to run game on

the latency of in-home streaming is far inferior to out-of-home streaming. Unless the server is just next door to where you live.

[grecy]

For now, yes.

Think 5-10-15 years when everyone has gigabit+ fiber to the home.

[dtech]

Latency != Bandwidth.

Latency is much harder to reduce than it is to increase bandwidth.

At a certain point you're also limited by the speed of light, round-trip latency for halfway accross the world cannot be physically less than ~200ms (unless our knowledge of physics advances and SoL is no longer a limit)

[MichaelGG]

I think it was Microsoft that proposed an approach. They'd modify games to continually speculatively execute and render every user input. So that might be they render you beginning to run left/right/forward/back as well as jumping and shooting. When you actually change the input, a local device can switch streams and start speculatively executing all over again.

It probably works best if the game engine cooperates. But that's not necessary. You can just split processes on the OS and run each different bit of user input in a different process with no cooperation from the process. (Though I admit this might be tricky on current hardware and heavy games.) Given enough compute and bandwidth, you could do this continually.

In theory, with unlimited compute/bw this means you can have local latency (just the cost of input/stream switching) because you could speculatively execute every possible input to the game, all the time, out to the latency duration. In practise, it'll probably prune things based on the likely inputs and only speculate a bit out. This is probably enough to provide a smooth experience for most users that aren't playing competitively.

If you think about a game as a mapping from a limited set of user inputs to a 2D image, some optimizations start coming out, I suppose.

[dtech]

Interesting approach!

But that sounds almost impossibly computationally expensive for 3D games and the like. Furthermore most game inputs aren't discrete but continuous, making the problem even hearder.

Do you have a link to the paper?

[MichaelGG]

http://research.microsoft.com/apps/pubs/?id=226843

"able to mask up to 250ms of network latency"

They tested with Doom 3 and Fable 3. I don't recall the specifics but I'm gonna guess that the actions people take are really quite limited, so with a bit of work you can probably guess what they're going to do enough to make things playable.

[mikeash]

Technically you can get it down to 85ms without going beyond any known physics, you just need to figure out a way to transmit information through the Earth rather than around it.

So the next big breakthrough in data transmission will be neutrino rays....

[frozenport]

>>unless our knowledge of physics advances and SoL is no longer a limit

The latency of the human mind is around the same. There are lots of tricks like predicting the future game state that can result in a better user experience.

[dtech]

UI Response time is at most 100 ms [1], as anything more that is very noticeable laggy.

Actual perception times are much lower than that, about 13ms [2]. You can see the difference for yourself by looking at a 30FPS (33ms) and 60FPS (16ms) video [3], and the effect is much greater when you're actually providing the inputs.

[1]: https://stackoverflow.com/questions/536300/what-is-the-short... [2]: https://newsoffice.mit.edu/2014/in-the-blink-of-an-eye-0116 [3]: http://www.30vs60fps.com/

[bnegreve]

> round-trip latency for halfway accross the world cannot be physically less than ~200ms

Yes, but people have been playing online games for a while now and latency was always there. I don't see why it would sudunly become a problem.

They'll just choose the closest server (i.e. the one that is not accros the globe) as they always did.

Whether the service is "rendering", "web" or anything else doesn't make a difference wrt. latency.

[dtech]

With local rendering, when you shoot a bullet you see the bullet shoot after local hardware latency (~50ms) and get a confirmed kill after local hardware latency + round-trip time (say ~50ms).

If the rendering is distant, the time until you will see that bullet shoot becomes 100ms instead of 50ms.

[bnegreve]

As long as the enemy player is remote, the enemy player position (and thus confirming a kill) will inevitably be delayed by the network latency (whether rendering is local or distant). That won't change.

The only thing that will change with remote rendering is that your own moves are also going to be delayed, which is certenly anoying I agree. But, on the positive side, this ensures consistancy between the view and the model, that is: you won't try to shoot at a player that is not actually where you're seeing him. That happens a lot with local rendering.

[ekianjo]

It's been 10 years I hear that Gigabit fiber is coming everywhere. It's taking way long that they say, and it still does not resolve the latency issue if you are far from the server.

[theg2]

Light can only travel so fast and the routing and network congestion is a far bigger obstacle than bandwidth.

[soggypretzels]

The limiting factor is going to be the speed of light rather than the bandwidth.

[Polecat]

If we can somehow eliminate input lag.

[vojant]

Of course for some games it is a problem, but not for every game. Also I hope in the future latency problem will be solved e.g. but placing more DC around the world.

[kbenson]

I'm not sure it's entirely solvable for some games, given the extra constraints imposed by remote processing. Gamasutra had a nice article[1] about responsiveness a and lag few years backthat wasn't addressing this problem specifically, but does put it in perspective a bit.

1: http://www.gamasutra.com/view/feature/3725/measuring_respons...