[cromwellian]

It's an idea tried and failed many times over (GPU hosted games in the cloud, OnLive, GaiKai, etc). The round-trip lag from the time you press a button until the time you see a change on the screen is just unacceptable for most twitch oriented games. The JS/Web implementation doesn't change anything about the fundamentals. I don't know why Mozilla is bothering with this approach vs the Emscript/Asm.js which would fair much better (but still not likely to succeed for AAA games)

You have people complaining about touch-lag on Android devices, which is on the order of 100ms, and you're telling me you're going to send a packet with a controller movement, render a frame, compress a frame, ship it back, and display it with something <100ms? The demo shown is a non-interactive cut-scene, so no one's going to notice the input lag. OnLive, when latency was actually measured, came out around 150ms, totally unacceptable.

Th true test would be running something like CoD, BF4, or a SF2 tournament and get pro gamers to evaluate the system.

The AAA titles are never going to be run this like economically. I'm playing Battlefield 4 right now, a huge huge game that brings my current PC rig to its knees. Why would anyone want to suffer this with 150ms lag and compression artifacts?

[pandaman]

The failures that happened were of economical nature (OnLive) and if you call selling a ~50 people company for ~500M a failure (Gaikai) then I'd love to hear about your success.

Apart from finding a way to profit from this there are no big problems left to solve.

[cromwellian]

My idea of success is a service which works for gamers. The fact that someone flipped a company is irrelevant, there are lots of companies which turned out to be economic failures that were dumped on investors. The fact that it was an economic failure points to a) the fact that gamers didn't flock to it and b) that it wasn't profitable to run or scale

[pandaman]

There are more practical explanations of OnLive failure. Like the prices they had to pay for the content leading to a very modest library of titles.

Gaikai is going to roll out with PS4 and only then we can judge how well is it doing. It's definitely solved the content issue so we can see if your technical angle holds.

[codeboost]

Most multiplayer games are quite playable over the network. The difference is that the graphics are rendered locally and the world state is streamed over the network.

A fast enough pipe (100Mbps fiber is quite common and cheap here in Europe) could deliver good results, even if the whole world is rendered and then streamed as video.

[cromwellian]

Multiplayer games run with a synchronization/prediction model. Most are not run with a purely server-driven world-state. The entire game simulation code and logic runs locally and is sent to the server, the server than collects all the inputs and calculates differences to the world state and sends back the diffs with predictions based on latency. These diffs may differ from the local state, and so corrections are applied. In the majority of cases, the differences are minor enough that the player doesn't notice. When they are severe, the player notices hitbox inaccuracy or worse, rubberbanding as his actions are "snapped back".

So when you're playing an FPS and you press a button to shoot, the local game logic and physics computes and displays the result immediately (firing animation, sound start playing). A short delay later, the server confirms a kill.

Even with this fairly sophisticated model, you still want <50ms pings. Video streaming and running the entire game in the cloud just won't work for games that require rapid hand-eye coordination.

[gsnedders]

The throughput of the pipe isn't the problem, I don't think — it's the latency.

[ye]

150ms latency should be fine for almost anything that's not an FPS game.

Systems like onLive are capable of bringing high-end graphics to low powered devices like tablets, netbooks, and notebooks, phones even.

And keep in mind that 150ms will reduce as our technology gets better and more servers get deployed.

[lcedp]

I don't know. Working with shell is very uncomfy with 170 ms ping. (I use mosh which prints typed symbols right away not waiting for response from server, but other feedback such as commands output or cursor movement is still very unpleasant at that lag).

[riskable]

I agree with this. That's why I spent so much time optimizing Gate One's Terminal->HTML encoder. On my i7 laptop the round-trip time for keystroke->screen update hovers around 10-20ms on localhost (remember though: My laptop is processing both ends at the same time).

On actual server hardware that "baseline latency" is about 5-10ms. So for any given client connecting to Gate One the response time for keystrokes should be at most 10ms + whatever the connection latency is.

[lcedp]

I'm positively impressed with responsiveness of this html project, but 170 ms in my case is the shear distance to the server :)