Video Game Design and Development

Online (www.onlive.com) announced a new service at this years GDC.  The service allows users to connect to a remote “cloud” of servers that process a video game’s logic and your input.  They send back a high-definition stream of the video and sound, allowing you to play very complex and resource intense games on simple machine (like a netbook or their tiny little “console”).

This is big news for the industry!  It could prevent piracy, lower the cost of console hardware, and maybe even lower the cost of games (we will ignore the fact that you don’t own the game anymore for now)… But, many of the blogs and articles I have ready are saying it just can’t be done.  Much of the concern is that it is not viably possible to send compressed video through the interwebs to your computer.  I think it is highly possible.  I think they have figured out a way to do it.  And, I think it is one way it can be achieved (less the fancy compression algorithms).

During the GDC 2009 talk presented by the Onlive executives, I noticed a small, but important statement.  It mentioned that the way video was processed for movies is vastly different from the way videos are processed for movies.  This got me thinking, “What is different between the way they are processed and how does this affect they way you compress and deliver to two?”  Interesting question, but I did not give it much conscious thought, until it hit me this morning. 

Video compression for movie files is (basically) taking a series of pictures (like jpegs) and laying them in sequence.  You run some fancy computer magic (compression algorithms) to allow for the best possible viewing matching the optimal file size.  There is a map between each frame of the video and what sound should be playing at that point in time.  Think of it like those “old” film strips that were/are used in theatres and schools.  You have a predetermined “reel” of information to be delivered.  It has to be converted for the computer (digitized) and made into a usable (often small) compressed (think zip file) format.  That file is then delivered as quickly as possible to a computer over the internet, de-compressed, and then processed for display on your screen.

I can’t say this is the way that Onlive (or other services using cloud computing for video games) are doing it, but this is where I would start… Games don’t have to be processed the same way.  You take input from the user (key presses or controller presses) and send it to the computer (their cloud in this instance).  They take the input and process it on a virtualized server (think single computer that plays the game using your input) and get the results that are ready to be displayed to your screen and heard from your speakers.  This differs from movie files, because you only need one screen at any given time.  Virtually all of the video cards (those amazing beasts that tranform computer information into what you view on the screen now) take the same information and plaster it to your screen.  They all work about the same, which means they all have a similar format (just a guess).  No real need to take a series of pictures, just a quick snap shot of the stream to be piped to your monitor.  Just take the change in pixel colors for the monitor and make it happen.  There is no need to process an entire picture for the monitor anymore.  (Hopefully more plainly:) Don’t process a pictuer (jpeg) only process what the monitor will output and send the (presumably) smaller data set. Do the same for the sound (not matching to a single frame of a video - just sending the sound cards output).  They compress the raw data for the monitor and sound card and send it.

I am not saying this is how it is done.  I am not even pretending that I know this would work.  But, if I were trying to pipe the info, this is where I would start.  I am probably wrong with my train of thought, but if I am not, it might help explain why this technology is not only possible, but viable.