There has been a lot of talk about Onlive.com and their stellar presentation at GDC. Instead of discussing the intracacies of their technical limitations, the business model, etc – I’ll start by sending you to Dave Perry’s accurate depiction of my thoughts on the matter. I will instead start with an alternate present time scenario for kicks:
The year is 2009, Microsoft never entered the graphics acceleration fray with Direct Draw and instead adopted Open GL (I know, lol). Open GL over the years gets many extensions driven by the games industry and Microsoft’s foray into it. A lot of work is done to maintain a steady state in video memory so that new data flushes were required less often (extensions for animation, culling and scene graphing) – due to the fact that the curve of memory costs increased far faster than the cost of bandwidth (due to buss switching and such, see also DMA channel 0, etc). This focus on throughput optimization leads to a revelation and a very different form of OpenGL ES. An Onlive-like service shows up (they’re not the first to do this by far), and instead of pushing HD pixels compressed, they’re pushing standardized commands filtered by a recognition of what the output device is. The television manufacturers or the cable/dsl boxes add in a graphics card to turn the commands into video. Phones are able to run the same way, with pixel resolution handled by the phones – so yes, hook up a bluetooth gaming pad to your phone and play Team Fortress 2 on it. Now the problem is flipped on its head – throughput is no longer quite the factor is was and now memory is the issue (one in which we are currently excelling at progressing). Also, the business is a distributed issue now: ISPs provide graphics hardware in their black boxes (which has a planned obsolescence – a cherish business model), and partner with gaming companies, as they’d still likely want to house servers in their NOCs due to latency. Now you don’t have on large company providing the ’service’ (Historically, systems like Onlive which require absolute adoption and ‘cannot fail’ have been trumped by systems which allow failure to happen iteratively and distribute the cost of such failure).
Ok, so enough fantasy – that scenario obviously didn’t happen (and I could even point out a good many reasons why) – but it’s fun to speculate. The base issue is an optimization one. For anything digital it tends to be: Memory – Processing – Throughput – Latency, with the last one generally intertwined with the previous three, so you could for simplicity sake boil it down to Memory – Processing – Throughput. Much like other optimization triangles (Cheap – Good – Fast), the optimization patterns are typically: ‘pick 2′ or ‘pick 1′. My above scenario was based on a Throughput optimization as historically it has the worst progression curve. This optimization triangle is very interesting because we’re constantly playing with it. The thin-client/thick-client ‘wiggle’ in history has been a product of this. Back in the 70s when memory and processing were expensive, thin clients (terminals) were the norm. In the 90s there was a huge shift from processing to memory (with more caches, etc) as the price of memory plummetted.
Now the issues are less technical and more political – Trust, Social Capital, Privacy, Security, Availability. The problem with the thin client isn’t really a technical issue so much anymore – it’s an issue of trust. To describe the thin/thick issue another way, there’s the war between Distribution and Centralization. Except that issue is largely gone – even our Centralization is distributed at this point. Our centralized data isn’t often stored on a single server – and in the future (or present depending on the service), it isn’t processed on a single server either.
A possible dream for the future (in ARG game form!) is my next post (seperated so this isn’t a TL;DR).
[...] About « Onlive and onwards [...]