Among the things announced this week in GDC were two developments in entirely different directions on a particular axis of games technology: first, the OnLive network of thin clients showing network-streamed video games rendered on a server cluster somewhere, and second, the Mozilla/Khronos Group initiative to develop an OpenGL-accelerated, JavaScript-programmed 3D canvas in a web browser. Both have one thing in common: make it possible to run 3D apps (games) on standard devices without prior installations. How they go about that goal is radically different. One of them will fail.
OnLive is not the first company to attempt their idea. It's a basic extension to the same theme that has been around since at least the inception of the X Window System and Sun NeWS in early 80s - graphical thin clients showing applications running somewhere in the network. Further, the idea was explored for 3D games in the late 90s by G-Cluster, which apparently is still around in Japan in some form or another. In my opinion, it's a misguided approach. Certainly there's value to server-side processing, even of graphics, but the final rendering just makes so much more sense to be done on the client even when all of the application logic is remote.
What kind of client? Well, anything that can run a high-performance VM for Java or JavaScript (ie, a modern browser), and has 3D acceleration functionalities built into the graphics pipeline. This includes basically every network-connected device from the cost of $200 upwards: all smart phones, all netbooks, all laptops, all games consoles, and so on. Some of those devices are still intentionally crippled by their manufacturers in terms of operating system support for the required features, and clearly the 3D Canvas development hasn't been finished yet. The hardware capabilities, however, are already deployed to hundreds of millions of consumers.
Ignoring that deployed base and trying to scale a server-side rendering solution to the same figures is just mad. And that's not even considering the framerate and responsiveness constraints that are inescapable simply because of the round-trip network latency of such a system: on a high-bandwidth wired network 10s of milliseconds (not everyone can be situated within a few kilometers of the server cluster), and on radio networks, 100s of ms. Developing high-framerate games under those circumstances is hard enough when you only need to deal within transmitting positional data and adjusting for lag and jitter in both ends - making the games playable when every action made by the player needs to go to the server and back before it shows up is practically speaking impossible.
(Update an hour later) I suppose I should acknowledge that clearly the OnLive approach does have certain benefits to it: no piracy, little hacking of the typical kinds, little opportunity to cheat, and no need for investing in PunkBuster-type technology in the game clients, since none of that is running locally. However, all that just simply will not matter when weighed against the enormous brunt of having to run all that rendering in the wrong end of the MMO network and ignoring the opportunities to disperse so much of the investment and energy requirements to the gamers.