Antes de ponerme a escribir sobre OnLive, me veo en la obligación de recomendaros la lectura del articulo de Richard Leadbetter en Eurogamer, que está en castellano y es fácil de entender. Si no os da miedo el inglés, entonces mejor os leís los articulos de Adam Martin y Jake Simpson.

Si hace unos años en la GDC la obsesión era el WoW-killer, que fue sustituido por el Second Life-killer al año siguiente, una de las obsesiones recientes de la industria es encontrar “el YouTube de los videojuegos“. El nuevo aspirante a este título es OnLive, un servicio que propone utilizar clientes ligeros para descargar vídeo en streaming de un juego next-gen ejecutándose en sus servidores y enviando las pulsaciones de tecla y movimientos de ratón (o de un pad) al servidor para que este los procese. El enfoque parece simple pero, si algo tan simple no se ha realizado hasta ahora, posiblemente haya algún muy buen motivo. O varios.

El primer problema técnico que OnLive tiene que solventar es el lag entre que pulsas una tecla y ves la reacción. En el blog de Mick West hay un diagrama que muestra la secuencia de eventos que transcurre entre que pulsas el boton “disparar” y ves al personaje del juego “disparar” o entre que mueves el ratón a la derecha y el arma del juego se mueve hacia ese lado. Entre cada uno de los estados del diagrama, el tiempo que trascurre se mide en milesimas de segundo.

En OnLive, tenemos un terminal “tonto” que, en el mejor de los casos, lee nuestra entrada a un ratio equivalente a 500 FPS. El cacharrito (o nuestro PC), tiene que codificar la entrada y enviarla al servidor a traves de Internet. Aquí nos encontramos con el problema, en el mundo real, los pings se miden en las decenas de milisegundos. Adam Martin tiene calculado que el ping entre Nueva York y Londres sería de unos 20ms (la luz tardaría unos 6 ms, así que me parece razonable). El otro día, en el Left 4 Dead mi ping era de unos 60 ms, jugando en un servidor ubicado en España. Esto significa que, en el mundo de las ideas, la respuesta a un paquete tardaría 120 ms. Eso sin tener en cuenta el la latencia que introduce la captura y compresión del video y la transferencia de un frame completo de video. No es lo mismo transferir un simple paquete de ACK (lo equivalente a un “recibido”) que un frame de video.

Juntando todo esto, llegamos al resultado “teórico” que, en el mejor caso, el tiempo que transcurre entre que aprieto un botón y veo la reacción es, como mínimo, de 12 ms, más cercano a los 40ms y donde 120ms no es ninguna tontería. En el caso de apretar un botón igual no parece muy importante (a menos que sea un juego tirando a rápido), pero apuntar puede llegar a ser muy incomodo con esos tiempos.

Hay que tener en cuenta que muchos videojuegos hoy en día implementan controles con inercia, así que una diferencia de ms puede suponer irse por el barranquillo. Y, aquí llega mi principal problema con OnLive, este servicio no tiene control sobre el modelo de juego. Desde hace bastante tiempo, los shooter utilizan técnicas de predicción para dar una respuesta más rápida y ágil al jugador, ya que cada jugador extrapola la posición de sus oponentes (o compañeros) controlados por jugadores utilizando su estado actual. El truco está en que, si la predicción era errónea, pueden colocar al jugador en el estado correcto. Pero OnLive no tiene control de “rebobinar”. Si fallas un salto por un fallo, has muerto. Si tu freno llega tarde y te ahostias, se acabó la carrera. Second Life tiene un sistema de control parecido, bajadlo y probadlo y decidme si jugaríais a un Tony Hawk o un Prince of Persia con esa “responsividad”. Y ya descartamos los juegos musicales, que en los últimos han empezado a añadir una opción para calibrar el lag de audio-video de tu sistema, así que haceros una idea de lo precisos que necesitan ser.

Otro problema que se encuentra OnLive es que, igual que la predicción no sirve, tampoco lo hace el buffering. El servidor no puede mandarte unos cuantos frames futuros, porque tu necesitas ver siempre el más recientes. Y no puedes guardarte unos cuantos por si hay un corte en la red, como hace YouTube. No vas a bajarte toda una partida y luego reproducirla, sino que tienes que estar siempre viendo el último fotograma. Así que la unica opción que tiene el servicio es escupir vídeo todo lo comprimido que pueda y lo más rápido que pueda procesarlo el cliente. Quizás en secuencias no interactivas si se podría meter un proceso de precarga, pero tal como está montado, no parece que el servicio tenga control sobre la ejecución de los títulos.

Técnicamente, el servicio me parece, en el mejor de los casos, muy optimista. Aun reduciendo mucho la calidad del video para hacerlo accesible a conexiones no tan rápidas, hay todo un tema de infraestructura y de configuración de la red que dificulta una buena experiencia de juego haciendo uso de un cliente tonto.

Otro tipo de problemas me los plantea en el plano de negocio. Blizzard tiene una infraestructura enorme de servidores para almacenar la posición y el inventario de sus jugadores. OnLive necesita un PC en condiciones para cada usuario simultaneo que quieran soportar. Cada uno de estos ordenadores tiene unas necesidades de ventilación y de consumo energético bastante mayores que las de un servidor dedicado. El servicio debería estar preparado para soportar picos de uso. En el caso de World of Warcraft, se estima que los servidores más poblados rondan los 15.000 usuarios y el máximo que podían aguantar eran 5000 simultáneos. Suponiendo este ratio 1:3. 15.000 usuarios deberían cubrir 5000 PCs de gama alta. Suponiendo 1000$ por estación, cada uno de esos usuarios debería gastar de media 300$. En este calculo no se tiene en cuenta los costes de operaciones (electricidad, mantenimiento, el espacio que ocupan esos PCs, etc.), los márgenes que se llevarían los desarrolladores del propio juego y el beneficio para la empresa.

¿Vale la pena pagar 300$ por la experiencia de juego de OnLive? En mi opinión, no. El alquiler de títulos o la comprad de juegos por episodios es un modelo de negocio muy interesante y que creo que se explorará en la próxima generación de consolas, aprovechándose del disco duro y de la conexión a Internet de estas.

A mi OnLive me ha recordado más a la Phantom que a YouTube, por muy veteranos de Silicon Valley que sean sus fundadores (como curiosidad Perlman es el visionario detras de las WebTV, esos aparatitos para navegar por Internet en la tele que son tan populares). No lo descarto por apego a los juegos físicos o porque me fastidie no “poseer” el juego, la critico porque veo que tiene problemas que evidentes y no parece que los responsables den una respuesta clara. Nos tocará esperar hasta la beta abierta para ver si OnLive convence a los jugadores, personalmente me muestro escéptico, por mucha demo que hayan enseñado en el GDC, ya que siempre hay que tener en cuenta el factor del Turco (o el servidor debajo de la mesa).