[GDC09] If you followed yesterday’s coverage, you should know that Onlive is a startup that is trying to deliver gaming over the web. In essence, you would be remote-controlling a gaming PC located in OnLive’s datacenter, as if you were using a super-fast remote desktop or VNC application. There’s a lot of excitement but also skepticism around this approach, so we decided to try it for ourselves at GDC 09.
Of course, this was a demo in a (somewhat) controlled environment, but it gives us some interesting pointers and we can now talk about the following topics: Latency, image quality, deployment methods, business model.
Latency is one of the big issues when it comes to remote gaming. Your client has to send input commands, that are processed to render the next frame which is then sent back to you. This induces a lag time and lag is bad for gaming, although not games are equally affected by it. We’ve tested a couple of games like Crysis, and Lego Batman. With Crysis, latency was high enough to annoy any FPS player. I’ve been told that the Crysis server was having issues, but still, that’s what I saw today. Crysis’ frame rate wasn’t sky high. I’m eyeballing it towards 24fps. However, Lego Batman which is a much simpler game ran at more than 30fps (possibly 40-45) and that’s good. A simple test that we did was to move the mouse cursor: even something that simple is fast but a bit jittery. You would not be able to draw something for example.
If you wonder, the server for this demo is located in Santa Clara which is about 50 miles from the show. To make its service work, OnLive has to be close to their customers. I’ve been told that a datacenter should be within 1500 miles from the customers, although we’ll have to see how this pans out. Additional latency from WiFi networks make it improbable that this would be a good fit. Forget about wireless broadband where latency is just horrible.
Image quality was OK, but you can notice immediately that there’s compression involved. To be fair, that would not prevent me from using the service, but it is definitely not as sharp as a direct connection. To play in 720p, you need a 5Mbps connection. At 480p only 1.5Mbps is required. These numbers mean 5Mbps of *real and measurable* download speed. Head to dslreports.com/stest to see how fast your connection is. OnLive is using their own “low-latency” compression scheme and while they did not elaborate on what that means, we suspect that they can’t use many “previous” (and even less “next”) frames to compress the images. Conclusion: could be better, but this is not a roadblock.
Deployment is fairly straightforward: you can either use a very thin client (their box is minuscule) or a computer with an application. I tried it on a Mac laptop, but a PC works as well and this could be very much work anywhere as it is not a demanding application for the client. The limiting factor is the wired internet connection.
Business Model: Onlive does not talk about this too much, but the idea is that they will be an infrastructure and service company working to provide game publishers with a new business venue. They will have to build datacenters and you can bet that big cities will be the first targets. Down the line they might cut a deal with cable operators to be embedded into the cable box and so on… there are possibilities.
Assuming that the tech really works (I’ll be 100% sure when I’ll try from home), the real question is whether or not they can scale it in an efficient and cost-effective way.
Developers: Each game needs a bit more work to interface with OnLive’s service.
Conclusion: The technology is interesting and as demoed, it’s “good enough” to generate some end-user interest. There are too many unknowns like pricing, game library etc… that make it hard to determine the financial success of this venture, but so far OnLive is is our view much better positioned than Otoy, another company that aims to deliver games over the web, although in a slightly different form. Check out our photo gallery.
Filed in . Read more about Cloud Gaming, GDC and Onlive.