New Service Aims To Replace Consoles With Cloud Gaming

ThinSkin writes "Imagine playing bleeding-edge games, yet never again upgrading your hardware. That's the ambitious goal of OnLive's Internet delivered gaming service. Using cloud computing, OnLive's goal is to 'make all modern games playable on any system,' thanks in large part to OnLive's remote servers that do all the heavy lifting. With a fast enough Internet connection, gamers can effectively stream and play games using a PC, Mac, or a 'MicroConsole,' 'a dedicated gaming client provided by OnLive that includes a game controller.' Without ever having to worry about costly hardware upgrades or the cost of a next-gen console, gamers can expect to fork over about $50 yearly just for the service. If this thing takes off, this can spell trouble for gaming consoles down the road, especially if already-established services like Steam and Impulse join the fray."

Comments

Caps

[Spad]

It's all fun and games (no pun intended) until you've been playing for a couple of hours and used up the whole of your monthly bandwidth allowance.

I know that some people have the option of truely unlimited service, but an awful lot don't and that puts this service out of their reach.

Re:Caps

[Moryath]

Hmmm.

Anyone else reminded of The Phantom?

Re:Caps

[poetmatt]

No manner of compression will make up for the attempt to do this live. I think a 50MB/above connection might be realistic to keep things smooth, especially in high action scenes with lots of pixels changing every single frame.

I could see: part of things being handled client side and part on the server side but then we just head back to online gaming.

However, even a fiber optics line I'd have my doubts. That is, unless you want to play on a 640x480 screen all day or assume that your internet provider wouldn't packet shape this stuff down to a crawl below VOIP, as someone said a few replies down.

Where I could see this working is in a LAN environment, make some kind of "xbox360server" to host all the games as basically virtual machines across a lan, etc. However, that obviously isn't cloud in the same sense.

Re:Caps

[Anonymous Coward]

You seem to be assuming that this service will stream VIDEO to your unit, but with TFA not being too clear on the subject, my guess is that they will stream just 'polygons' to their 'netconsole', which then displays them as video frames. The bandwith needed should be far smaller.

The biggest difference with mmorpgs is that mmorpg servers send program data to the client, who then does most of the calculations -the hard work- and displays the results.

Also, many slashdotters seem to assume that mmorpgs require a huge bandwith. I think that's wrong. As a well known example WoW was quite playable using a 512 Kb DSL connection.

As other posters have said before, the biggest problem with On-Live's approach is the lag, which is inherent to the Internets, and will continue so for the foreseeable future. Most mmorpg clients use lots of code and processing power just to minimize the effects of lag in the gameplay, with mixed fortunes (Go to Dalaran and ask anyone :)

Re:Caps

[SanityInAnarchy]

However, even a fiber optics line I'd have my doubts.

Doing some quick calculations:

The highest number I've gotten for Blu-Ray maximum bandwidth is 54 megabits per second. I've seen torrents much smaller that still looked good.

Assuming uncapped, that's actually doable. Fiber is typically 100 mbits per second, and I'm sure some places offer gigabit.

However, encoding time is on the order of hours or days, and is certainly not live. So the real problem is latency -- take 50 ms from your LCD monitor, plus whatever a wireless controller ads, plus the latency between you and their servers, plus the lag for them to render, capture, and encode, then decode back at the client... that's easily getting up to 200 ms, which I'd consider unplayable.

Also, unless the $50/year includes games, it makes little economic sense, either. These systems are designed to last some four years or so. A Wii can be had for $160, according to a quick Google; this would be $200. A Wii can work when your Internet is down, or when your internet is not fiber. And a Wii actually has games already -- not as many as its competitors, but some.

Where I could see this working is in a LAN environment

Not really. LANs are typically 100 mbits, or if you're willing to spend money on a good switch, gigabit. Same situation as fiber.

The only advantage of a LAN is, with a good switch, you aren't using everyone else's bandwidth, but if you're proposing this:

make some kind of "xbox360server" to host all the games as basically virtual machines across a lan,

That's still likely to be a single port, which means now everyone on the LAN is limited to a combined 100 mbits for their video. It means the concept of a LAN party just got very, very impractical.

And WTF would be the point, if it's a console anyway? In what way is that "xbox360server" better than a real Xbox 360?

As for their "no piracy" claim, as a consumer, that doesn't make me want to sign up for the service. That makes me want to go far away, into the open arms of indie developers, who typically ship with reduced or no DRM.

Re:Caps

[SanityInAnarchy]

Also worth mentioning: Even assuming you've got a magical encoding machine which only adds a few milliseconds to the latency, there's the simple fact that most video streamed over the Internet is done through a relatively large buffer.

In fact, Flash audio and video (Youtube and friends) seems to just download as much of the video as it can, as fast as it can, and start playing once it thinks it has enough.

This means it's possible for your connection to drop out completely for a second, or just vary by the amounts Internet traffic typically does, and so long as it comes back in time, your video will just keep playing.

This applies even to most sane "live" broadcasts.

Trying to do it actually live, within a few milliseconds, is completely different. The slightest blip in connectivity, which a sufficiently buffered stream would skip right over, is going to be catastrophic here.

And just in case it wasn't obvious: Buffers inherently add latency, proportional to their size. Add a buffer that can handle even half a second of connection trouble, and you've just added half a second between the time the player says "turn left", and the time they see the camera turn left.

I mention all of this because I suspect that the reason you'd think this is a good idea is, you've got a Roku, or you've used YouTube, or even Skype, and you've concluded that the Internet is now fast enough to do video. Maybe, but I don't think it's fast enough to do the kind of high quality, live, low-latency video demanded by a gamer.

No thanks

[Macthorpe]

Instead of normal online game lag, you have lag between you actually pressing a button and the game responding at the server.

Even a tiny amount in this situation would make the game 'feel' unresponsive.

Re:No thanks

[Wovel]

Except that is not what it says... It says the server will do the lifting to a thin client. The server is not just streaming binaries to be rendered on the client, the server is receiving input from and return video to be displayed on the client.

I think Amazon sells crowbars to remove your foot from your mouth.

Re:No thanks

[toad3k]

This doesn't sound as stupid to me. Obviously this wouldn't work well for something like an fps, but for something like an rpg, a casual game, a turn based game, some rts's? It would work fine. Secondly there is hardly any upfront cost. Essentially the hardware on your end would be 40 bucks including the controller. That is an amazingly low barrier to entry, considering you might have access to dozens or hundreds of games right off the bat. There will also never be any issues of backwards compatibility, every game will be playable for as long as the company feels like supporting it. There's no cheating, no red rings of death. The only real barrier right now is bandwidth, but for how long?

I've been predicting this would happen eventually, much to the derision of others, but I didn't expect to see plans for another five years maybe.

Re:No thanks

[poot_rootbeer]

It says the server will do the lifting to a thin client. The server is not just streaming binaries to be rendered on the client, the server is receiving input from and return video to be displayed on the client.

A game console with all the responsiveness and graphical horsepower of an X11 terminal? How can it fail!!!

This is really bad news for Nintendo.

Re:No thanks

[orkybash]

every game will be playable for as long as the company feels like supporting it.

You say this like it's a good thing.

Image bandwidth

[yakumo.unr]

How does cloud computing solve the CPU-GPU bandwidth issues of modern games? Gamers still want to see the game, and at ultra high rez & IQ.

No No No!

[godfra]

Fuck the cloud! I don't want all my gaming delivered down the pipe as a metered "service". I like owning hardware, and having the ability to play games without being hooked up to a subscriber model.

Internet gaming is often subject to ISP drop-outs and traffic shaping. Why would I willingly embrace single-player gaming in the same poor environment?

With new "Low-latency HD Video"

[e2d2]

I love how their network diagram in that article states "Low-latency HD video". As if it's a new technology. Wow, you have low-latency! I didn't even know that was out.

This is a pipe dream until they can prove this works. I want to see physical tests, not PR.

Re:Graphics bottleneck...

[TheRaven64]

Depends on how dumb the front end is. Remote OpenGL is quite usable. OpenGL inherently has a client-server architecture. In the most common use, the server is on the graphics card and the client is on the CPU, but you can put the server on a different machine (and a lot of people do) and still get good performance. I ran GLQuake over a (shared) 10Mb/s network a few years ago and it performed quite well. This would work okay on the kind of asymmetric link you get at home, because you're pulling down lots of data (textures, geometry, and so on) but only sending up simple events (mouse moved, key pressed). If the client is just an X server supporting AIGLX with a decent local GPU, then this is feasible. The 'microconsole' could just be a simple *NIX system running X.org and a simple local app for connecting. X.org already runs on OS X and Windows, and so the same code could be used on all platforms.

READ TEH ARTICLES MUCH??

[relguj9]

You seem to be assuming that this service will stream VIDEO to your unit, but with TFA not being too clear on the subject

Actually, the article is quite clear:

The secret sauce to making OnLive work is its proprietary, on-the-fly video compression capability. As you're playing the game, the outgoing frame buffers are compressed as a video stream and sent to your local client. Perlman estimates that servers need to be within 1,000 miles of a client, at a maximum, to maintain latencies low enough to ensure playability. User data, such as inputs and commands, will be sent back over the Internet, but those usually consist of fairly small data packets.

Of course, a broadband connection is required. For standard definition (480p) resolutions, users will need a minimum of 1.5 megabits/sec. A 5 megabits/sec connection will support high definition (720P or 1080i) connections. Initially, the service won't support 1080p or higher resolutions, but that may come later.