OnLive Gaming Service Gets Lukewarm Approval

Vigile writes "When the OnLive cloud-based gaming service was first announced back in March of 2009, it was met with equal parts excitement and controversy. While the idea of playing games on just about any kind of hardware thanks to remote rendering and streaming video was interesting, the larger issue remained of how OnLive planned to solve the latency problem. With the closed beta currently underway, PC Perspective put the OnLive gaming service to the test by comparing the user experiences of the OnLive-based games to the experiences with the same locally installed titles. The end result appears to be that while slower input-dependent games like Burnout: Paradise worked pretty well, games that require a fast twitch-based input scheme like UT3 did not."

Comments

Yet another infomation-free summary...

[Anonymous Coward]

The guy logged in using credentials 'borrowed' from an authorised beta tester, from more than twice the recommended distance from the server, acknowledged multiple high latency (due to distance) notifications, and the best he could do is damn the service with faint praise.

Re:Yet another infomation-free summary...

[Anonymous Coward]

". After all, playing on the internet isn't as quick as a "LAN frag fest", and yet the vast majority of gamers, even of twitch-heavy games, are playing on the internet, not on LANs."

With tons of client side prediction and faking trying very very hard to hide the client-server lag.

With OnLive, you can't do that - it just sends some inputs and gets some video back.

I mean, this could work under optimal, super fast network connections, but I'm pretty sure ensuring you have such a connection would be so expensive that this is a solution to a problem that doesn't exist - it is always cheaper to spend the money on client side hardware instead. I'm sure stupid venture capitalists will keep pumping money into this with idiotic projections how bazillion people will pay X dollars per month or hour or whatever that will somehow cover those network infrastructure costs.

I doubt it will and few years from now OnLive goes bust taking a big pile of money with it, but hey, you never know... can't do impossible stuff without trying.

I just don't see this working

[jbb999]

The major problem isn't overall latency, it's little spikes of latency on an otherwise good line. A moment of 100ms lag on an otherwise good line doesn't matter for online games because of client prediction and at worst it's a tiny moment where the controls don't seem responsive. It's not a problem for normal video because they can buffer 250ms or 500ms or 1000ms of video without any problem. But on this they can't do any significant buffering or the latency will be too much to play.And even 100ms of sudden latency will cause the picture to lag or freeze or jump. It might only happen occasionally but I suspect people won't put up with it. And they can't do anything about it either, even if your ISP is only 10% loaded on its lines and routers, there will be times when all that 10% send packets at the same moment and they get queued in a router somewhere, just for a tiny time but tiny little amounts of jitter like this are normal and expected and to be honest I think will be the downfall of this project because there is no real way to deal with them. But I guess we'll see :)

Re:Duuuuuh

[Svartalf]

Actually...it's doable technically with only a very, very small number of subscribers.

Latency and bandwidth will kill the whole thing.

You have to use peak values per customer in your figuring for it to even remotely work the way they portrayed this.

Given this:

1.5Mbits/s for the feed per user for SD experience with OnLive.

You can serve roughly as an absolute maximum :

30 users on a T3.
103 users on an OC-3.
404 users on an OC-12.
1658 users on an OC-48.

You can expect about $250-500k/mo recurring costs on that OC-48. As another observation, you will likely need to serve 2/3rds to 3/4ths of those numbers to keep the latency usable because as you fill the pipe to capacity, traffic will be subject to the congestion algorithms in the routers and machines at both ends of the pipe. Now, some will state that they'll place the stuff at the ISP's end of things... Then the ISP gets the joy of this same level of connectivity- and they're bitching about "freeloaders" and "bandwidth problems" right now.

OnLive is snake oil trying to be sold to the game industry as a solution to their "control" problem. It's an alternate DRM play. And it can NEVER work in our lifetime. You can't field enough bandwidth cheaply enough to accomplish it.